Proiectarea arhitecturala

Este etapa in care se construieste solutia problemei. Rezultatul este un model fizic al viitorului
sistem, care este descris in Documentul de Proiectare Arhitecturala.
Cerintele din documentul Cerintelor Software sunt alocate unor componente ale viitorului sistem.
Rezulta un set de subsisteme/componente interconectate. Arhitectura software rezulta printr-un
proces iterativ de descompunere a cerintelor.
Documentul de proiectare arhitecturala trebuie sa specifice rolul fiecarei componente, cerintele
care i-au fost alocate, interfata de comunicare cu celelalte componente ale sistemului.
In etapa de proiectare arhitecturala se intocmeste Planul Testelor de Integrare.
1. Procesul: obtinerea modelului de proiectare arhitecturala
1. Abordare descendenta:

Se pleaca de la specificatia cerintelor software: S

Se descompune setul cerintelor, S, in subseturi relativ independente, S1, S2,

Fiecare subset de cerinte, Si, este alocat unui subsistem al arhitecturii

software: SA1, SA2...

Fiecare subset de cerinte Si este descompus in subseturi mai simple, Si1, Si2, .. care sunt
alocate unor subsisteme ale subsistemului SAi: SAi1, SAi2,..

Descompunerea modelului de proiectare arhitecturala se opreste atunci cand nivelul sau de

detaliu permite:

continuarea dezvoltarii in paralel de catre mai multi membrii ai echipei de dezvoltare,

planificarea activitatilor urmatoare ale procesului de dezvoltare (pana la livrare),

estimarea resurselor umane necesare si a costurilor.

Rezultatul este o structura ierarhica alcatuita din subsisteme interconectate, fiecare subsistem
fiind descompus pana la nivel de module.

Un modul de proiectare poate fi: modul functional (functie, procedura), clasa, componenta, in
functie de metoda de proiectare folosita: functionala sau orientat obiect.

2. Abordare ascendenta

Centrata pe reutilizare

Se pleaca de la un set de module existente : module functionale sau clase

Se cauta o descompunere a cerintelor in subseturi care pot fi implementate folosind

componentele existente
3. Abordare hibrida
Se pleaca de la setul de cerinte software, care se descompune iterativ, dar in procesul de
descompunere se urmareste definirea de module care pot fi implementate folosind module
existente.
2. Modelul de proiectare athitecturala

Este o structura ierarhica alcatuita din subsisteme interconectate, fiecare subsistem fiind
alcatuit dintr-un set de module interconectate sau din alte subsisteme, s.a.m.d.

Modelul poate fi reprezentat prin :

diagrame de componente si diagrame de distributie combinate cu diagrame de componente
diagrame de clase, in care relatiile ierarhice se bazeaza pe generalizare si specializare
diagrame de structura, in cazul unei descompuneri functionale : descompunerea iterativa a
functiilor pe care trebuie sa le implementeze sistemul

Diagrama de structura

Nodurile arborelui sunt module functionale.

Arcele reprezinta relatiile de apel intre module.

Sagetile indica fluxul datelor

Pentru fiecare modul al arhitecturii software se scrie o specificatie:
Fiecare modul este specificat prin:

Identificatorul(unic) si tipul sau (clasa, functie, fisier, program)

Scopul sau cerintele software pe care le implementeaza
Componenetele subordonate: modulele apelate/ obiectele utilizate/ fisierele unei baze de date
Interfata componentei: fluxul datelor si al controlului
Dependentele sale: conditii care trebuie sa fie satisfacute inainte sau dupa executia sa, operatii
interzise in timpul executiei componentei
Prelucrarea interna a componentei, la nivelul cel mai coborat in limbaj natural
Structurile de date interne
Planul testelor de integrare precizeaza ordinea in care vor fi integrate modulele in subsisteme si
apoi subsistemele pana la nivel de sistem precum si testele care vor fi efectuate la integrare.
3. Calitatile unei arhitecturi software

adaptabilitatea: usurinta de modificare si intretinere

eficienta: utilizarea eficienta (la minimum) a resursele disponibile

usurinta intelegerii
Principii de modularizare:

Modulele trebuie sa fie simple si cat mai independente unul de altul:

o O modificare a unui modul are influenta minima asupra altor componente
o O schimbare mica a cerintelor nu conduce la modificari majore ale arhitecturii software (gruparea
cerintelor corelate in acelasi modul)
o Efectul unei conditii de eroare este izolat in modulul are a generat-o
o Un modul poate fi inteles ca o entitate de sine-statatoare

Modulele trebuie sa ascunda modul de implementare a functiilor descrise de interfata lor,

de ex. cum sunt memorate datele cu care lucreaza (tablou, lista, arbore, in memorie sau intr-un
fisier)
Reguli de proiectare a modulelor:

Minimizarea cuplarii intre module:

Minimizarea numarului de elemente prin care comunica modulele;

Evitarea cuplarii prin structuri de date

Evitarea cuplarii prin variabile steag (cuplarea prin control)

Evitarea cuplarii prin date globale

Maximizarea coeziunii interne a fiecarei componente: elementele grupate intr-o componenta

trebuie sa fie corelate, de ex. sa contribuie la aceeasi prelucrare

Restrangerea numarului de module apelate (fan-out) de un modul:

Maximizarea numarului de module care utilizeaza un modul (fan-in) incurajaza re-utilizarea

Fan-in mare: un numar mare de module depind de el
Fan-out mare: modulul depinde de multe module

Factorizare: functionalitatile comune sunt definite in module reutlizabile.

Documentul de proiectare arhitecturala (ADD)

Sablonul documentului in standardele ESA:

Proiectarea de detaliu

Se efectueaza la nivelul modulelor definite in proiectarea arhitecturala.

Poate avea loc in paralel, pentru diferite module.

Detaliaza modelul de proiectare arhitecturala:

pot fi definite module de nivel mai coborat

se detaliza componenta claselor: atributele si functiile membre

se aleg biblioteci utilizate in implementare

se incurajeaza reutilizarea

sunt descrisi algoritmii

SABLOANE DE PROIECTARE (Design Patterns)

Scopul sabloanelor de proiectare este de a asista rezolvarea unor probleme similare cu unele
deja intalnite si rezolvate anterior. Ele ajuta la crearea unui limbaj comun pentru comunicarea
experientei despre aceste probleme si solutiile lor.
Un sablon de proiectare descrie o problema care se intalneste in mod repetat in proiectarea
programelor si solutia generala pentru problema respectiva, astfel incat sa poata fi utilizata
oricand dar nu in acelasi mod de fiecare data. Solutia este exprimata folosind clase si obiecte.
Atat descrierea problemei cat si a solutiei sunt abstracte astfel incat sa poata fi folosite in multe
situatii diferite.
In general, un sablon are 4 elemente esentiale:

1.

Un nume prin care poate fi referit. Prin atribuirea de nume sabloanelor de proiectare se

creaza un vocabular de proiectare, un limbaj comun de comunicare si documentare. Alegerea

numelui este importanta deoarece el devine parte din vocabularul de proiectare.

2.

Descrierea problemei. Se explica problema si contextul in care apare, cand trebuie

aplicat sablonul.

3.

Descrierea solutiei. Sunt descrise elementele care compun proiectul, relatiile dintre ele,

responsabilitatile si colaborarile.

4.

Consecintele aplicarii sablonului. Descrierea consecintelor este critica pentru evaluarea

alternativelor de proiectare, intelegerea costurilor si a beneficiilor aplicarii unui sablon.

Un sablon de proiectare descrie de asemenea problemele de implementare ale

sablonului si un exemplu de implementare a sablonului in unul sau mai multe limbaje de
programare.
Sabloanele de proiectare pot fi generale sau specifice unui domeniu.

Descrierea sabloanelor de proiectare

1.

Numele sablonului si clasificarea.

2.

Intentia: O scurta definitie care raspunde la urmatoarele intrebari:

Ce realizeaza sablonul

Care este scopul sau

Ce problema de proiectare adreseaza

3.

Alte nume prin care este cunoscut, daca exista.

4.

Motivatia. Este descris un scenariu care ilustreaza o problema de proiectare si

cum este rezolvata problema de clasele si obiectele sablonului.

5.

Aplicabilitatea. Sunt descrise situatiile in care poate fi aplicat sablonul si cum

pot fi recunoscute aceste situatii.

6.

Structura. Este reprezentata grafic prin diagrame de clase si de interactiune

folosind o notatie cum ar fi UML.

7.

Participanti: clasele si obiectele care fac parte din sablonul de proiectare si

responsabilitatile lor.
8.

Colaborari: cum colaboreaza participantii pentru a-si indeplini responsabilitatile.

9.

Consecintele: care sunt compromisurile si rezultatele utilizarii sablonului.

10.

Implementare. Se precizeaza daca trebuie avute in vedere anumite tehnici de

implementare si care sunt aspectele dependente de limbajul de implementare.

11.

Exemplu de cod.

12.

Sabloane corelate. Se specifica alte sabloane de proiectare corelate cu cel

descris, care sunt diferentele, cu care alte sabloane ar trebui utilizat acesta.

Metrici ale proiectarii OO

1. Dimensiunea medie a unei metode (LOC):

< 24 LOC pentru programe C++

2. Numarul mediu de metode/clasa:

< 20
medii mai mari indica prea multa responsabilitate in putine clase
3. Numarul mediu de variabile instanta (atribute) / clasa:
mai multe inseamna ca o clasa face prea mult

<6

4. Nivelul clasei in ierarhia de clase (Depth of Inheritance Tree):

< 6,
incepand de la radacina sau de la clasele bibliotecii de dezvoltare
5. Numarul de relatii subsistem/ subsistem:

< valoarea metricii 6

6. Numarul de relatii clasa/ clasa in fiecare subsistem:

trebuie sa fie relativ mare coeziune mare a claselor din acelasi subsistem
daca o clasa dintr-un subsistem nu interactioneaza cu multe alte clase
din subsistem ar trebui plasata in alt subsistem
7. Utilizarea variabilelor instanta:
daca grupuri de metode dintr-o clasa utilizeaza seturi diferite de variabile instanta
clasa ar putea fi divizata in mai multe clase
8. Numarul mediu de linii comentariu / metoda:
9. Numarul de rapoarte problem / clasa:

>1

mic

10. Numarul de reutilizari ale unei clase:

daca o clasa nu este reutilizata in diferite aplicatii (mai ales o clasa abstracta)
ar putea fi necesar sa fie reproiectata
11. Numarul de clase si metode la care s-a renuntat:
ar trebui sa fie relativ constant pe durata dezvoltarii
dezvoltarea incrementala in spiritul proiectarii iterative OO

1.TESTAREA PROGRAMELOR
Un test const n execuia programului pentru un set de date de intrare convenabil ales, pentru
a verifica dac rezultatul obinut este corect.

Un caz de test este un set de date de intrare mpreun cu datele de ieire pe care programul ar
trebui s le produc. Cazurile de test se aleg astfel nct s fie puse n eviden, dac este
posibil, situaiile de funcionare necorespunztoare.
Testarea este activitatea de concepie a cazurilor de test, de execuie a testelor i de evaluare a
rezultatelor testelor, n diferite etape ale ciclului de via al programelor.
Testarea n vederea verificrii programului folosete date de test alese de participanii la
procesul de dezvoltare a programului. Ea este efectuat la mai multe nivele: la nivel de unitate
funcional, de modul, de subsistem, de sistem.
Testarea n vederea validrii programului, numit i testare de acceptare, are drept scop
stabilirea faptului c programul satisface cerinele viitorilor utilizatori. Ea se efectueaz n
mediul n care urmeaz s funcioneze programul, deci folosindu-se date reale. Prin testarea de
acceptare pot fi descoperite i erori, deci se efectueaz i o verificare a programului.
2. Testarea pe parcursul ciclului de via al unui program.
2.1. Testele "unitare"
Testarea unui modul este realizat de programatorul care implementeaz modulul. Toate
celelalte teste sunt efectuate, de persoane care nu au participat la dezvoltarea programului.
Scopul testarii unui modul este de a se stabili ca modulul este o implementare corecta a
specificatiei sale (conforma cu specificatia sa).
In cursul testarii unui modul, modulul este tratat ca o entitate independent, care nu necesit
prezena altor componente ale programului. Testarea izolat a unui modul ridic dou probleme:
-

simularea modulelor apelate de cel testat;

simularea modulelor apelante.

Modulele prin care se simuleaz modulele apelate de modulul testat se numesc module "ciot"
(n englez, "stub") . Un modul "ciot" are aceeai interfa cu modulul testat i realizeaz n mod
simplificat funcia sa.
Cazurile de apel ale modulului testat de ctre celelalte module ale programului sunt
simulate n cadrul unui "modul driver". Modulul driver apeleaz modulul testat furnizndu-i ca
date de intrare datele de test ale modulului. Datele de test pot fi generate de modulul driver, pot
fi preluate dintr-un fiier sau furnizate de testor ntr-o manier interactiv.

2.2. Testele de integrare

Sunt dedicate verificrii interaciunilor dintre module, grupuri de module, subsisteme, pn la
nivel de sistem. Exist mai multe metode de realizare a testelor de integrare.
Testele de integrare presupun, ca i testele unitare, realizarea de module "ciot" i module
"driver". Numrul de module "driver" i de module "ciot" necesare n testele de integrare
depinde de ordinea n care sunt testate modulele (metoda de integrare). Testele de integrare
necesit de asemenea instrumente de gestiune a versiunilor i a configuraiilor.
2.2.1. Metoda "big-bang"
Sunt integrate ntr-un program executabil toate modulele existente la un moment dat. Modulele
driver" i "ciot" necesare sunt de asemenea integrate. Metoda este periculoas cci toate erorile
apar n acelai timp i localizarea lor este dificil.
2.2.2. Integrare progresiva
Metodele de integrare progresiv sunt mult mai eficiente. In fiecare moment se adaug
ansamblului de module integrate numai un singur modul. Astfel, erorile care apar la un test
provin din modulul care a fost ultimul integrat.
2.2.2.1. Integrarea ascendent ("de jos n sus")
Se ncepe prin testarea modulelor care nu apeleaz alte module, apoi se adaug progresiv
module care apeleaz numai modulele deja testate, pn cnd este asamblat ntregul sistem.
Metoda necesit implementarea cte unui modul "driver" pentru fiecare modul al programului (i
nici un modul "ciot").
Avantajele testrii de jos n sus
Nu sunt necesare module ciot. Modulele driver se implementeaz mult mai uor dect modulele
ciot. Exist chiar instrumente care produc automat module driver.
Dezavantajele testrii de jos n sus
1. Programul pe baza cruia se efectueaz validarea cerinelor este disponibil numai dup
testarea ultimului modul.
2. Corectarea erorilor descoperite pe parcursul integrrii necesit repetarea procesului de
proiectare, codificare i testare a modulelor. Principalele erori de proiectare sunt descoperite de
abia la sfrit, cnd sunt testate modulele principale ale programului. ceea ce, n general,
conduce la reproiectare i reimplementare.
2.2.2.2. Integrarea descendent ("de sus n jos")

Se ncepe prin testarea modulului principal, apoi se testeaz programul obinut prin integrarea
modulului principal i a modulelor direct apelate de el, etc. Metoda presupune implementarea
unui singur modul "driver" (pentru modulul principal) i a cte unui modul "ciot" pentru fiecare alt
modul al programului.
Integrarea descendent poate avea loc pe parcursul unei implementri descendente a
programului. Modulul principal este testat imediat ce a fost implementat, moment n care nu au
fost nc implementate modulele apelate de el. De aceea, pentru testare este necesar s se
implementeze module "ciot". In continuare, pe msur ce se implementeaz modulele de pe
nivelul ierarhic inferior, se trece la testarea lor folosind alte module ciot, .a.m.d. In fiecare pas
este nlocuit un singur modul "ciot" cu cel real.
Avantajele testrii de sus n jos
1. Erorile de proiectare sunt descoperite timpuriu, la inceputul procesului de integrare, atunci
cnd sunt testate modulele principale ale programului. Aceste erori fiind corectate la nceput,
se evit reproiectarea i reimplementarea majoritii componentelor de nivel mai cobort, aa
cum se ntmpl cnd erorile respective sunt descoperite la sfritul procesului de integrare.
2. Programul obtinut este mai fiabil caci principalele module sunt cel mai mult testate.
3. Prin testarea modulelor de nivel superior se poate considera c sistemul n ansamblul su
exist dintr-o faza timpurie a dezvoltrii i deci se poate exersa cu el n vederea validrii
cerinelor; acest aspect este de asemenea, foarte important n privina costului dezvoltrii
sistemului.
Dezavantajele testrii de sus n jos
1. Este necesar s se implementeze cte un modul "ciot" pentru fiecare modul al programului,
cu excepia modulului principal.
2. Este dificil de simulat prin module "ciot" componente complexe i componente care conin n
interfa structuri de date.
3. n testarea componentelor de pe primele nivele, care de regul nu afieaz rezultate, este
necesar s se introduc instruciuni de afiare, care apoi sunt extrase, ceea ce presupune o
nou testare a modulelor.
Aceste dezavantaje pot fi reduse aplicand tehnici hibride, de exemplu, folosind n locul
unor module "ciot", direct modulele reale testate. Integrarea nu trebuie sa fie strict
descendenta. De exemplu, experienta arata ca este foarte util sa se nceapa prin integrarea
modulelor de interfa utilizator. Aceasta permite continuarea integrrii n condiii mai bune de
observare a comportrii programului.

2.3. Testele de sistem

Acestea sunt teste ale sistemului de programe i echipamente complet. Sistemul este instalat i
apoi testat n mediul su real de funcionare. Sunt teste de conformitate cu specificaia
cerintelor de sistem (software) :

teste functionale, prin care se verifica satisfacerea cerintelor functionale

teste prin care se verifica satisfacerea cerintelor ne-functionale :de performan, de

fiabilitate, de securitate, etc.

Adesea, testele de sistem ocup cel mai mult timp din ntreaga perioad de testare.
2.4. Testele de acceptare (validare)
Sunt teste de conformitate cu produsul solicitat, conform contractului cu clientul (->Specificatia
cerintelor utilizatorilor). Aceste teste sunt uneori conduse de client.
Pentru unele produse software, testarea de acceptare are loc n dou etape:
1.Testarea alfa: se efectueaz folosindu-se specificaia cerinelor utilizatorilor, pn cnd cele
dou pri cad de acord c programul este o reprezentare satisfctoare a cerinelor.
2.Testarea beta: programul este distribuit unor utilizatori selecionai, realizndu-se astfel
testarea lui n condiii reale de utilizare.
2.5. Testele regresive.
Se numesc astfel testele executate dup corectarea erorilor, pentru a se
verifica dac n cursul corectrii nu au fost introduse alte erori. Aceste teste sunt efectuate de
regul n timpul ntreinerii. Pentru uurarea lor este necesar s se arhiveze toate testele
efectuate n timpul dezvoltrii programului, ceea ce permite, n plus, verificarea automat a
rezultatelor testelor regresive
3. Determinarea cazurilor de test
Testarea unui modul, a unui subsistem sau chiar a ntregului program presupune stabilirea unui
set de cazuri de test.
Un caz de test cuprinde:
- un set de date de intrare;
- funcia / funciile exersate prin datele respective;

- rezultatele (datele de ieire) ateptate;

n principiu (teoretic) testarea ar trebui s fie exhaustiv, adic s asigure exersarea tuturor
cilor posibile din program. Adesea o astfel de testare este imposibil, de aceea trebuie s se
opteze pentru anumite cazuri de test. Prin acestea trebuie s se verifice rspunsul programului
att la intrri valide ct i la intrri nevalide.
Sunt dou metode de generare a cazurilor de test:
1. Cazurile de test se determin pe baza specificaiei componentei testate, fr cunoaterea
realizrii ei; acest tip de testare se numete testare cutie neagra
2. Cazurile de test se determin prin analiza codului componentei testate. Acest tip de testare
se mai numete i testare cutie transparent, sau testare structural.
3.1. Testarea cutie neagr.
Cazurile de test trebuie s asigure urmtoarele verificri:
- reacia componentei testate la intrri valide;
- reacia componentei la intrri nevalide;
- existena efectelor laterale la execuia componentei, adic a unor efecte care nu rezult din
specificaie;
- performanele componentei (dac sunt specificate).
Deoarece n marea majoritate a cazurilor testarea nu poate fi efectuat pentru toate seturile de
date de intrare (testare exhaustiv), n alegerea datelor de test plecnd de la specificaii se
aplic unele metode fundamentate teoretic precum i o serie de euristici.
Alegerea cazurilor de test folosind clasele de echivalen
Cazurile de test pot fi alese partiionnd att datele de intrare ct i cele de ieire ntr-un numr
finit de clase de echivalen. Se grupeaz ntr-o aceeai clas datele care, conform specificaiei,
conduc la o aceeai comportare a programului.
O dat stabilite clasele de echivalen ale datelor de intrare, se alege cte un eantion (de date
de test) din fiecare clas.
Alte cazuri de test se aleg astfel nct la folosirea lor s se obin eantioane din clasele de
echivalen ale datelor de ieire (din interiorul si de la frontierele lor).
In alegerea datelor de test trebuie s se elimine redundanele rezultate din considerarea att a
claselor de echivalen de intrare ct i a celor de ieire.

Unele programe trateaz datele de intrare n mod secvenial. n aceste cazuri se pot detecta
erori n program testndu-l cu diverse combinaii ale intrrilor n secven. Metoda de
partiionare n clase de echivalen nu ajut n alegerea unor astfel de combinaii. Numarul de
combinaii posibile este foarte mare chiar i pentru programe mici. De aceea nu pot fi efectuate
teste pentru toate combinaiile. n aceste cazuri este esenial experiena celui care alctuiete
setul de cazuri de test. Testarea "cutie neagr" este favorizat de existena unei specificaii
formale a componentei testate.
In alegerea cazurilor de test s-au folosit urmtoarele euristici:
programele de cutare prezint erori atunci cnd elementul cutat este primul sau ultimul in
structura de date;
de multe ori programatorii neglijeaz situaiile n care colecia prelucrat n program are un
numr de elemente neobinuit, de exemplu zero sau unu;
uneori, programele de cutare se comport diferit n cazurile: numr de elemente din colecie
par, respectiv numr de elemente din colecie impar; de aceea sunt testate ambele situaii
Concluzii:
1. Setul de cazuri de test a fost determinat numai pe baza specifica iei componentei i a unor
euristici (este vorba de experiena celui care efectueaz testele), deci fr s se cunoasc
structura intern a componentei, care este tratat ca o cutie neagr. Eventuala examinare a
codului surs nu urmrete analiza fluxului datelor i a cilor de execuie, ci doar identificarea
variabilelor globale cu care componenta interacioneaz.
2. Clasele de echivalen se determin pe baza specificaiei.
3. Se aleg drept cazuri de test eantioane din fiecare clas de echivalen a datelor de intrare.
Experiena arat c cele mai utile date de test sunt acelea aflate la frontierele claselor de
echivalen.
4. Cazurile de test alese verific componenta doar pentru un numr limitat de eantioane din
clasele de echivalen ale datelor de intrare; faptul c din testare a rezultat c ea funcioneaz
corect pentru un membru al unei clase nu este o garanie c va funciona corect pentru orice
membru al clasei.
5. Se determin de asemenea clasele de echivalen ale datelor de ieire i se aleg pentru
testare datele de intrare care conduc la date de ieire aflate la frontierele acestor clase.

6. Partiionarea n clase de echivalen nu ajut la depistarea erorilor datorate secvenierii

datelor de intrare. In aceste cazuri este util experiena programatorului. Reprezentarea
comportrii programului printr-o diagram de stri-tranziii poate fi folositoare n determinarea
secvenelor de date de intrare de utlizat n testarea programului.
Testele cutie neagr, numite i teste funcionale sunt utile nu numai pentru testarea
programului. Ele pot fi utilizate (ca teste statice) pentru verificarea unei specificaii intermediare
fa de o specificaie de nivel superior.
Slbiciunile testelor funcionale:
-

Nu este suficient s se verifice c programul satisface corect toate funciile specificate;

unele proprieti interne, nespecificate, ca de exemplu timpul de rspuns, nu sunt verificate;

-

Programul este testat pentru ceea ce trebuie s fac conform specificaiilor i nu i pentru

ceea ce face n plus, de exemplu pentru ca implementarea s fie mai eficient sau pentru a
facilita reutilizarea;
-

In absena unui standard n privina specificaiilor formale, tehnicile de testare functional

sunt eterogene
3.2 Testarea structural
Acest tip de testare se bazeaz pe analiza fluxului controlului la nivelul componentei
testate. Principalul instrument folosit n analiz este graful program sau graful de control.
Acesta este un graf orientat, ale crui noduri sunt de dou tipuri: noduri care corespund
blocurilor de instruciuni indivizibile maximale i noduri care corespund instruciunilor de
decizie. Blocurile de instruciuni indivizibile maximale sunt poriuni liniare maximale de
instruciuni care se execut ntotdeauna n aceeai secven. Fiecare bloc are un singur punct
de intrare i un singur punct de ieire. Arcele reprezint transferul controlului ntre
blocurile/instruciunile componentei program.
Graful program are un nod unic de intrare i un nod unic de ieire. Dac exist mai multe
puncte de intrare sau mai multe puncte de ieire, acestea trebuie s fie unite ntr-unul
singur(care se adaug suplimentar). Nodul de intrare are gradul de intrare zero, iar cel de ieire
are gradul de ieire zero.
Se consider cile care ncep cu nodul de intrare i se termin cu nodul de ieire. Testarea
structural const n execuia componentei testate pentru date de intrare alese astfel nct s
fie parcurse unele dintre aceste ci. Nu este necesar, i n general este imposibil, s se

execute toate cile de la intrare la ieire ale unui program sau ale unei componente program.
Prezena ciclurilor conduce la un numr foarte mare (deseori infinit) de ci. De asemenea,
anumite ci sunt ne-executabile.
Testele structurale favorizeaz evidenierea urmtoarelor tipuri de erori logice:
1. Ci absente n graful program - ca urmare a ignorrii unor condiii
(de exemplu: test de mprire la zero);
2. Selectarea unei ci necorespunztoare - datorit exprimrii
incorecte (de multe ori incomplete) a unei condiii;
3.

Aciune necorespunztoare sau absent(de exemplu: calculul unei valori cu o metod

incorect, neatribuirea unei valori unei anumite variabile, apelul unei proceduri cu o list de
argumente incorect etc.).
Dintre acestea, cel mai simplu de depistat sunt erorile de tip 3. Pentru descoperirea lor este
suficient s se asigure execuia tuturor instruciunilor programului.
Alegerea cilor de testat are loc pe baza unor criterii de acoperire a grafului de control. Dintre
acestea cele mai cunoscute sunt:
Execuia tuturor instruciunilor
Cazurile de test se aleg astfel nct s se asigure execuia tuturor instruciunilor
componentei testate. Acesta este un criteriu de testare minimal. El nu este ntotdeauna
satisfctor.
Traversarea tuturor arcelor
Cazurile de test se aleg astfel nct s se asigure traversarea fiecrui arc al grafului
program cel puin pe o cale. Pe baza acestui criteriu se va putea verifica dac transferul
controlului este corect pentru valoarea FALSE a condiiei, n exemplul de mai sus. In acelai
timp, criteriul nu impune traversarea mai mult de o dat a unui ciclu. Anumite erori apar numai
atunci cnd un ciclu este traversat de mai multe ori.
Traversarea tuturor cilor
Pe baza acestui criteriu ar trebui ca testele s asigure traversarea tuturor cilor
componentei testate. Pentru majoritatea programelor nu se poate aplica acest criteriu,
deoarece numrul de ci de execuie este infinit. Criteriul poate fi restricionat, de exemplu
asigurnd traversarea tuturor cilor cu o lungime mai mic sau egal cu o constant dat.

Problema alegerii cazurilor de test const din trei subprobleme distincte:

-

selectarea cilor de testat;

alegerea datelor de test pentru execuia fiecrei ci selectate;

determinarea rezultatelor care trebuie s se obin la fiecare test.

In continuare prezentm o metod de alegere a datelor de test pe baza criteriului traversrii

tuturor arcelor grafului de control. Metoda presupune parcurgerea urmtoarelor etape:
1. Se determin setul cilor de testat, C, astfel nct:
a)

c C este o cale de la nodul de intrare la nodul de iesire;

b)

fiecare arc din graful de control este cuprins ntr-o cale c C

lung (c) = minima

cC
2. Se determin predicatul fiecrei ci, c C, Rc(I), unde
c)

I = (i1, i2, , in) este vectorul variabilelor de intrare;

3. Pentru fiecare Rc(I), c C, se determin un set de atribuiri Xc pentru
variabilele de intrare care satisfac predicatul cii:
Rc(Xc) = true
Atunci setul datelor de test este:
DT = { Xc | c C, Xc DI, Rc(Xc) = true },
n
unde DI = X Dik iar Dik este domeniul de valori al variabilei de intrare ik.
k=1
4. Pentru fiecare Xc DT, se determina valorile corecte ale variabilelor de iesire
Slabiciunile testelor structurale sunt:
-

testele selectionate depind numai de structura programului; ele trebuie recalculate la fiecare

modificare; nu pot fi reutilizate eficient de la o versiune la alta

-

testele selecionate acoper cazurile legate de ceea ce face componenta testat i nu de

ceea ce trebuie s fac; astfel, dac un caz particular a fost uitat in faza de implementare,
testul structural nu releva aceasta deficien; el trebuie deci completat cu testul funcional. Mai
exact trebuie s se nceap cu testarea funcional care se completez cu testarea structural.

Testele statistice
Testele statistice se efectueaza in timpul testarii de sistem.
Se numesc astfel testele n care datele de test se aleg aleator, dup o lege de probabilitate
care poate fi:
-

uniform pe domeniul datelor de intrare al programului testat- aceste teste se mai numesc

teste statistice uniforme;

-

similar cu distribuia datelor de intrare estimate pentru exploatarea programului aceste

teste se mai numesc teste statistice operaionale.

Rezultatele experimentale ale testelor statistice uniforme sunt inegale. Ele nu acoper cile
care corespund tratrii excepiilor. De aceea trebuie completate cu teste folosind date de
intrare n afara domeniului intrrilor.
Testele statistice operaionale sunt n general teste de fiabilitate. Prin ele nu se urmrete n
general descoperirea de erori ci mai ales comportarea programului n timp. Cderile observate
n timpul acestor teste permit estimarea masurilor de fiabilitate, cum ar fi MTBF (Mean Time
Between Failures).
Verificarea si validarea Software
Prin aceste activitati se verifica daca software-ul satisface specificatiile sale, in timpul fiecarei
faze a ciclului sau de dezvoltare.
Se realizeaza:

Verificand ca fiecare articol software indeplineste cerintele specificate;

Verificand fiecare articol software inainte de a fi utilizat ca intrare pentru o alta

activitate;

Asigurand ca fiecare articol software este verificat, pe cat posibil, de o persoana

diferita de aceea care l-a produs;

Asigurand ca efortul de verificare si validare este adecvat pentru ca fiecare articol

software sa fie operational.

Verificarea inseamna:

Actul de a stabili si documenta faptul ca articolele, procesele, serviciile sau

documentele sunt in conformitate cu cerintele specificate. (sunt produsele in conformitate cu

cerintele lor specificate? )
Validarea este, conform definitiei din ANSI/IEEE:

Procesul de a evalua un sistem sau o componenta in timpul sau la sfarsitul procesului

de dezvoltare pentru a determina daca satisface cerintele specificate. (sunt produsele in

conformitate cu cerintele clientului?)

Activitatile de verificare includ:

Revizii (Reviews). O revizie este o intrunire in care este prezentat un document pentru
comentare sau aprobare. Tipurile de revizii sunt: Revizii tehnice, Prezentari (Walkthroughs),
Inspectii, Audit-uri

Urmarire (tracing): se definesc relatii intre produse ale procesului de dezvoltare, de

exemplu dintre o cerinta software si cerinte utilizator.

Demonstratii formale: pot fi aplicate pentru anumite aspecte ale sistemului daca se

folosesc metode formale pentru analiza si proiectare.

Testare: nu poate demonstra absenta erorilor ci doar prezenta lor.

Activitatile de verificare pe parcursul Ciclului de Viata

Documentul de cerinte sotware este verificat fata de documentul de cerinte utilizator, conform
sectiunii SR din planul de verificare si validare.
1. Revizii

O revizie este o intrunire in timpul careia un produs sau set de produse este prezentat

personalului care participa la proiect, managerilor, utilizatorilor, clientilor sau altor persoane
interesate, pentru comentarii sau aprobare.
o

Reviziile formale au obiective specifice si reguli de procedura explicite. Prin ele se

cauta identificarea defectelor si a discrepantelor software fata de specificatii, planuri si

standarde.
o

Reviziile neformale nu au proceduri predefinite.

Sunt uzuale trei tipuri de revizii formale:

Revizii

tehnice
Prezentari

(walkthroughs)
Audituri.

Inspectiile software reprezinta o alternativa mai riguroasa a Prezentarilor si sunt foarte

recomandate pentru software cu cerinte stringente de fiabilitate, securitate si siguranta.

1.1. Revizii tehnice
O revizie tehnica evalueaza documente pentru a verifica progresul conform planului.

Obiectivul unei revizii este de a asigura ca:

Articolele revizuite sunt conforme cu specificatiile facute in fazele anterioare,

Ele au fost produse in conformitate cu standardele prevazute,

Fiecare modificare a fost implementata corect si afecteaza numai acele parti

identificate prin specificatia modificarii.

Componenta echipei de revizie difera in functie de faza din ciclul de viata in acre are loc

revizia. Astfel, din echipa pot face parte: Utilizatori, Conducatori de proiect, Ingineri software,
Membri ai achipei de asigurare a calitatii, Experti independenti
Inainte de intrunire:
o

Fiecare membru al echipei studiaza documentele revizuite si inregistreaza fiecare

problema intalnita. Inregistrarea este transmisa autorului documentului revizuit.

o

Autorul studiaza problemele care i-au fost transmise si intocmeste un raspuns care

este transmis conducatorului echipei de revizie.

o

Acesta le clasifica in: majore, minore, de editare.

In timpul intrunirii:
Se discuta fiecare problema transmisa si se stabileste starea sa:
o

Inchisa: a fost rezolvata

De actualizat: documentul va fi actualizat (modificat)

Actiune: cu specificarea pers resp si data pana la care documentul tre completat

Rejectare: problema este inchisa fara actualizare sau actiune

Fiecare intrunire se termina prin:

o

O decizie, daca este necesara o noua intrunire

Posibil, o autorizare de a se trece la faza urmatoare

Intocmirea unui raport in care sunt inscrise rezultatele intrunirii

1.2. Prezentari (Walkthroughs)

O prezentare este o varianta de revizie tehnica in care autorul documentului revizuit

participa la intrunire.
Inainte de intrunire
o

Membrii echipei studiaza documentul revizuit

In timpul intrunirii
o

Autorul prezinta documentul revizuit: aceasta este principala diferenta fata de o

revizie tehnica, unde in timpul intrunirii se discuta doar problemele semnalate

o

Toate erorile, schimbarile si imbunatatirile sugerate sunt inregistrate, impreuna cu

actiunile definite in timpul intrunirii.

Obiectivul unei prezentari este de a evalua un element software specific (adica un document
sau modul sursa).
o

Se cauta identificarea defectelor si se considera solutiile posibile.

Spre deosebire de celelalte forme de revizie, prezentarile au si un obiectiv secundar, de

a educa si a rezolva probleme de stil.

1.3. Audituri
Un audit este o revizie independenta efectuata de un grup extern (persoane care nu fac parte
din echipa de dezvoltare).

Obiectivul unui audit este de a verifica faptul ca produsele si procesele software sunt in
conformitate cu standardele, specificatiile si procedurile stabilite.

Verificarile audit pot fi de rutina sau nu.

o

Exemple de audituri de rutina sunt cele fizice si functionale efectuate inainte de livrarea

unui software

Audituri ne-uzuale pot fi initiate de clientul care primeste software-ul sau de echipa de

management sau de asigurare a calitatii din organizatia care produce software-ul.

1.4. Inspectari

Inspectiile software pot fi utilizate pentru detectarea defectelor in proiectul de detaliu inainte
de codare si in cod inainte de testare

Pot fi de asemenea folosite pentru a verifica proiectarea cazurilor de test si a procedurilor de

testare

Sunt eficiente. Pot fi detectate peste 50% din numarul total de defecte introduse in timpul
dezvoltarii

Sunt economice deoarece reduc numarul de defecte si costul eliminarii lor.

Se deosebesc de Parcurgeri prin:

Repetarea procesului pana la atingerea unui nivel de defecte acceptabil
Analiza rezultatelor procesului si transmiterea lor inapoi pentru imbunatatirea produsului
Evitarea discutarii solutiilor in timpul intrunirii si concentrarea pe gasirea defectelor
Verificarea faptului ca defectele au fost corectate si nu au fost introduse alte defecte
2.Urmarie
Urmarirea consta in stabilirea unei relatii intre doua sau mai multe produse ale procesului de
dezvoltare. De exemplu, o relatie intre o cerinta data si elementul din proiect care
implementeaza cerinta.
Urmarirea se face in doua sensuri: Inainte, Inapoi
Urmarirea Inainte cere ca fiecare intrare a unei faze sa fie in relatie cu o iesire a fazei.
Se realizeaza cu ajutorul unei matrici in care se reprezinta corespondenta dintre intrari si iesiri.
Pot rezulta intrari lipsa sau posibile duplicate-intrari care corespund la mai multe iesiri.
Urmarirea Inapoi cere ca fiecare iesire a unei faze sa fie in relatie cu o intrare a fazei
respective.
Iesirile care nu au o relatie cu intrarile sunt un semn de eroare, exceptand cazurile in care
intrarile sunt incomplete.
Pe parcursul ciclului de viata software este necesar sa se urmareasca:
Cerintele utilizator fata de Cerintele software si invers;
Cerintele software fata de descrierea componentelor de proiectare si invers;

 Testele unitare fata de modulele proiectului de detaliu si invers;

Testele de integrare fata de unitatile arhitecturale si invers;
Testele sistem fata de Cerintele software si invers;
Testele de acceptare fata de Cerintele utilizator si invers.
Pentru ca urmarirea sa fie posibila toate cerintele si componentele trebuie sa fie
identificabile conform unei conventii.
3. Demonstratii formale
Incearca sa demonstreze prin mijloace matematice faptul ca un software este corect.
Testele demonstreaza empiric faptul ca intrari specifice conduc la rezultate specifice.
Demonstratiile formale demonstreaza logic faptul ca toate intrarile care indeplinesc preconditii
definite produc iesiri care satisfac postconditii definite
Tehnicile de demonstrare formala sunt adesea dificil de justificat datorita efortului suplimentar,
adaugat activitatilor de verificare mentionate mai inainte. In mod ideal, celelalte activitati de
verificare nu ar mai fi necesare in cazul demonstratiilor formale, daca instrumentele de verificare
utilizate in demonstratii sunt sigure!!
Dificultatea exprimarii intr-o forma matematica a cerintelor software si a proiectului au impiedicat
aplicarea pe scara larga a acestor tehnici. Metodele formale s-au bucurat de un interes mai larg si
au avut succes in specificarea si verificarea protocoalelor de comunicatie si a sistemelor de
securitate.

CALITATEA PRODUSELOR SOFTWARE

Calitatea unui produs este uneori definita ca totalitatea caracteristicilor sale prin care el satisface
o serie de necesitati definite sau impuse.
Calitatea unui produs software este data de capacitatea sa de a putea fi utilizat eficient, efectiv
si confortabil, de catre un set de utilizatori, pentru un set de scopuri, in conditii specificate .
Calitatea ceruta pentru un produs software trebuie sa fie definita in documentul de definitie a
cerintelor software (SRD). De asemenea, trebuie specificate definitiile atributelor de calitate,
metodele de masurare si criteriile de acceptare pentru atribute.

1. Caracteristici de calitate ale produselor software

Incercarile de standardizare a terminologiei referitoare la calitatea produselor
software au condus la standardul ISO 9126 (InformationTechnology-Software Product
Quality, Part 1: Quality Model, 1998). Standardul contine definitii in special pentru
produsul final.
Sunt definite 6 caracteristici de calitate, impartite in 21 de subcaracteristici.
1) Functionalitatea: realizarea scopului de baza pentru care a fost realizat produsul
Oportunitatea: prezenta unui set de functii adecate pentru tascuri specificate
Precizia: furnizarea unor rezultate sau efecte corecte sau agreate
Interoperabilitatea: capacitatea produsului de a interactiona cu sisteme specificate
Securitatea: capacitatea de a preveni accesul neautorizat, accidental sau
deliberat, la programe sau date
Conformitatea: adeziunea la standarde, conventii, legi si protocoale
2) Fiabilitatea: capacitatea produsului de a-si mentine nivelul de performanta, in
conditii definite, pentru o perioada de timp definita.
Maturitatea: atribut bazat pe frecventa caderilor datorate greselilor in software
Toleranta la defecte (robustetea): capacitatea de a-si mentine un nivel de
perfomanta specificat in cazuri de caderi software sau intrari neasteptate
Restabilirea dupa caderi: capacitatea si efortul necesar pentru restabilirea nivelului
de performanta, recuperarea datelor afectate, dupa posibile caderi
Conformitatea
3) Utilizabilitatea: efortul necesar pentru utilizarea sa de catre un set de utilizatori
definit
Usurinta de intelegere: efortul solicitat unui utilizator de a recunoaste conceptul logic si
aplicabilitatea sa
Usurinta de invatare : efortul solicitat unui utilizator de a invata aplicatia, operarea, intrarile si
iesirile
Operabilitatea: usurinta de operare si de control de catre utilizatori
Puterea de atractie: capacitatea produsului de a fi atragator pentru utilizatori
Conformitatea

4) Eficienta: relatia intre nivelul de performanta al produsului si cantitatea de resurse utilizate, in

conditii definite
Timp la executie: viteza de raspuns, timpi de prelucrare, rata iesirilor
Utilizarea resurselor: cantitatea de resurse utilizate si durata utilizarii pentru realizarea
functiilor sale
Conformitatea
5) Usurinta de intretinere: efortul necesar pentru efectuarea modificarilor, inclusiv
corectii, imbunatatiri sau adaptari ale produsului la schimbari ale mediului de
functionare, a cerintelor si schimbarilor functionale
Usurinta de analiza: efortul necesar pentru diagnoza defectelor, a cauzelor caderilor, pentru
identificarea partilor care trebuie sa fie modificate
Usurinta de modificare: efortul necesar pentru inlaturarea defectelor sau schimbari
Stabilitatea: riscul efectelor neasteptate in urma modificarilor
Usurinta de testare: efortul necesar pentru a valida produsul modificat
Conformitatea
6) Portabilitatea: capacitatea produsului de a fi transferat de la o organizatie sau
platforma software/hardware la o alta
Adaptabilitatea: capacitatea de adaptare la diferite medii specificate
Usurinta de instalare: efortul necesar pentru instalarea produsului intr-un mediu specificat
Co-existenta: capacitatea de a co-exista cu alte produse independente in acelasi mediu
Oportunitatea si efortul necesar pentru a folosi produsul in locul altui produs intr-un mediu
particular

Conformitatea

Tipuri speciale de sisteme si cerintele de calitate

Exista multe cerinte de calitate particulare care se incadreaza sau nu in cele din ISO 9126.
Caracteristici de calitate software care afecteaza procesul de inginerie software
Stilul codului
Reutilizabilitatea codului
Modularitatea codului si independenta modulelor

2. Asigurarea calitatii produselor software

Rolul activitatilor de asigurare a calitatii software este de a stabili ca produsele si procedurile
sunt in conformitate cu standardele si planurile.
In proiectele mici asigurarea calitatii poate fi efectuata de echipa de dezvoltare, dar in
proiectele mari trebuie sa fie realizata de o echipa speciala.
Activitatile de asigurare a calitatii sunt documentate in Planul de Asigurare a Calitatii (Software
Quality Assurance Plan (SQAP).
Prin activitatile de asigurare a calitatii se urmareste:
Concordanta planurilor cu standardele

Realizarea proceselor in concordanta cu planurile

Implementarea produselor in concordanta cu planurile

Verificarea si validarea produsului software sunt de asemenea activitati de sigurare a

calitatii.
Ce este un sistem de asigurare a calitii :Ansamblul activitilor care trebuie
ntreprinse pentru ca un produs s fie de calitate
Ce acoper un Sistem de Asigurare a Calitii:
a) Activitile propriuzise de inginerie
- analiza;
- proiectarea (concepia);
- codificarea
- testarea (metode i instrumente)
b) Reviziile aplicate la fiecare pas al proiectului
c) Strategiile de testare
d) Controlul documentaiei software i a inerii ei la zi
e) Compatibilitatea cu standardele (dac este cazul)
f) Mecanismele de msurare i raportare (pentru a avea o msur cantitativ a
calitii)
Metrici de complexitate
1. Complexitatea ciclomatica
Utilizeaza Graful de Control al programului. Ipoteza: dificultatea de intelegere a unui program
este in mare masura determinata de complexitatea grafului fluxului de control

 Este o masura a dificultatii de testare a modulelor si a fiabilitatii la nivel de modul.

Complexitatea unei entitati este determinata de relatiile dintre partile sale.
Partile unui modul software sunt instructiunile sale. Relatiile dintre ele se bazeaza pe trei
structuri:
Secventa: bloc maximal indivizibil de instructiuni care se executa intotdeauna in aceeasi
ordine
Selectia (conditia)
Iteratia (ciclul). Iteratia poate fi simulata prin salt la o conditie.
Complexitatea ciclomatica este definita pentru un modul pe baza grafului de control al modulului.
McCabe defineste complexitatea ciclomatica a unui graf de control astfel:
v=e-n+2
unde:
e
este numarul de arce (edges);
n
este numarul de noduri.
Pentru o secventa, v=1. Este necesara o singura executie de test pentru a executa fiecare
instructiune din secventa.
Fiecare salt adaugat la un modul creste complexitatea sa cu 1 si necesita o executie de test
suplimentara pentru testarea sa.
Deci, complexiatea ciclomatica a unui modul da numarul minim de executii de test ale unui
modul, pentru acoperirea tuturor arcelor.

Grafuri de control

Grafuri de control pentru structurile de control ale

Programarii structurate

Instructiunile de decizie cu mai multe predicate trebuie sa fie separate in predicate simple inainte
de masurarea complexitatii ciclomatice. De exemplu, decizia if(A.and.B.andC)then.. trebuie
separata in 3 decizii simple.

Metoda de testare structurala: complexitatea ciclomatica a unui modul sa fie limitata la 10.

Studiile arata ca erorile se concentreaza in module cu complexitati mai mari ca aceasta limita.

In timpul proiectarii de detaliu limitarea trebuie sa fie la 7, deoarece complexitatea creste

intotdeauna in timpul codarii. Modulele care depasesc aceasta limita trebuie sa fie reproiectate.
2. Complexitatea ciclomatica totala
Complexitatea ciclomatica totala a unui program se obtine insumand complexitatile ciclomatice
ale modulelor sale.

Este exprimata prin formula: v = e - n + 2p

unde p este numarul de module.
e este numarul de arce din toate modulele
n este numarul de noduri din toate modulele
O formula echivalenta este: v = v1+v2+..+vp
unde v1, v2, , vp sunt complexitatile ciclomatice ale celor p module.
Combinand mai multe module intr-unul singur va rezulta un modul cu o complexitate
ciclomatica mai mare decat a modulelor combinate dar mai mica decat complexitatea totala.
Descompunerea unui modul in module mai mici creste complexitatea totala dar reduce
complexitatea la nivelul fiecarui modul.
3. Complexitatea proiectarii modulelor
Complexitatea proiectarii unui modul, notata de McCabe cu iv, masoara efectul individual al unui
modul asupra proiectului programului.
Complexitatea proiectarii unui modul este evaluata plecand de la graful de control al modulului si
marcand nodurile care contin apeluri de module externe.
Graful de control este apoi redus dupa urmatoarele reguli:
1. nodurile marcate nu pot fi eliminate;
2. nodurile nemarcate care nu contin decizii sunt eliminate;
3. arcele care intorc controlul la inceputul unui ciclu care contine numai noduri
nemarcate sunt eliminate
4. arcele care unesc nodul de start al unei instructiuni case cu nodul de sf sunt eliminate daca
nici una dintre celelalte ramificatii ale instructiunii case nu contin noduri marcate.

 Complexitatea proiectarii modulului este complexitatea ciclomatica a grafului redus

(iv = e-n+2)
Complexitatea proiectarii modulului ignora caile acoperite in testarea modulului, care nu contin

apeluri de module externe. Caile ramase sunt necesare pentru a testa interfetele modulului.
4. Complexitatea proiectarii unui ansamblu de module
S0 = iv1 + iv2 .. + ivn
unde iv1, iv2, ivn sunt complexitatile de proiectare ale modulelor din ansamblu.
5. Complexitatea integrarii
Complexitatea integrarii unui ansamblu de N module, notata de McCabe cu S1,
Este definita astfel:S1 = S 0 - N + 1

Complexitatea integrarii a N module care nu contin ramificatii este deci 1.

Formal, complexitatea integrarii necesita masurarea complexitatii proiectarii

fiecarui modul.

In timpul proiectarii arhitecturale, de regula, nu este disponibil graful fluxului de

control al fiecarui modul. Totusi, ar trebui sa fie disponibila suficienta informatie
pentru a defini complexitatea proiectarii fiecarui modul, chiar fara a cunoaste
logica modulelor.

Figura urmatoare reda o diagrama de structura prin care se ilustreaza cum trebuie evaluata S1
cunoscand doar conditiile de apel ale fiecarei componente, adica fluxul controlului.
Dreptunghiurile corespund componentelor de proiectare iar sagetile marcheaza fluxul
controlului. Prin romb se indica un transfer al controlului conditional:
componenta

a apeleaza fie componenta b fie componenta c

componenta

b apeleaza secvential componenta d si componenta e

componenta

c apeleaza una dintre componentele e, f, g sau nici una

Complexitatea integrarii modulelor reprezentate in diagrama de structura este 5.

Estimarea complexitatii integrarii folosind diagrama de structura

6. Alte metrici ale proiectarii

Numarul de parametri

Determina puterea cuplarii intre module.

Intelegerea modulelor cu un numar mare de parametri cere mai mult timp si efort.

Modificarea modulelor cu un numar mare de parametri poate avea efecte asupra altor
module.

Numarul de module apelate estimeaza complexitatea intretinerii

Pentru un modul:
Fan-in: numarul de module care il apeleaza

Fan-out: cate module sunt apelate de el

Fan-in mare: un numar mare de module depind de el

Fan-out mare: modulul depinde de multe module

Cuplarea prin date
Fie tripletul (p,X,q), unde:
o p si q sunt module
o X este o variabila accesibila din p si q
Cuplarea potentiala prin date:
o X este declarata in ambele, dar nu se verifica accesul la ea
o Reflecta posibilitatea ca p si q sa comunice prin variabila X
Cuplarea prin date utilizate
o p si q utilizeaza X.
o Mai greu de determinat decat cuplarea potentiala. Necesita mai multa informatie
despre logica interna a modulului.
Cuplarea prin date efectiva
o p atribuie o valoare lui X si q o refera.
o Cel mai greu de determinat, dar indica un flux de informatie de la p la q.
Metrici ale coeziunii
Se construieste graful de flux pentru un modul
o Pentru fiecare nod, se inregistreaza variabilele referite in instructiunile din
nod
Se determina cat de multe cai independente ale modulului trec prin fiecare
nod
o Un modul are coeziune mare daca cea mai mare parte a variabilelor sunt
utilizate pe majoritatea cailor
o Cea mai mare coeziune: toate caile independente utilizeaza toate
variabilele din modul