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 hibridaSe 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: o Minimizarea numarului de elemente prin care comunica modulele;

o Evitarea cuplarii prin structuri de date

o Evitarea cuplarii prin variabile “steag” (cuplarea prin control)

o 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:

o pot fi definite module de nivel mai coborat

o se detaliza componenta claselor: atributele si functiile membre

o se aleg biblioteci utilizate in implementare

o se incurajeaza reutilizarea

o 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: < 6 mai multe inseamna ca o clasa “face” prea mult

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: >1

9. Numarul de rapoarte problem / clasa: 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 execuţia programului pentru un set de date de intrare convenabil ales, pentru

a verifica dacă rezultatul obţinut este corect.

Un caz de test este un set de date de intrare împreună cu datele de ieşire pe care programul ar

trebui să le producă. Cazurile de test se aleg astfel încât să fie puse în evidenţă, dacă este

posibil, situaţiile de funcţionare necorespunzătoare.

Testarea este activitatea de concepţie a cazurilor de test, de execuţie a testelor şi de evaluare

a rezultatelor testelor, în diferite etape ale ciclului de viaţă al programelor.

Testarea î n vederea verific ă rii programului foloseşte date de test alese de participanţii la

procesul de dezvoltare a programului. Ea este efectuată la mai multe nivele: la nivel de unitate

funcţională, de modul, de subsistem, de sistem.

Testarea î n vederea valid ă rii programului , numită şi testare de acceptare, are drept scop

stabilirea faptului că programul satisface cerinţele viitorilor utilizatori. Ea se efectuează în

mediul în care urmează să funcţioneze 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ă

prezenţa 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 aceeaşi interfaţă cu modulul testat şi realizează în mod

simplificat funcţia sa.

Cazurile de apel ale modulului testat de către 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 fişier sau furnizate de testor într-o manieră interactivă.

2.2. Testele de integrareSunt dedicate verificării interacţiunilor dintre module, grupuri de module, subsisteme, până 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". Numărul 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 configuraţiilor.

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ă căci toate erorile

apar în acelaşi 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, până când este asamblat întregul sistem.

Metoda necesită implementarea câte unui modul "driver" pentru fiecare modul al programului (şi

nici un modul "ciot").

Avantajele test ă rii de jos î n sus

Nu sunt necesare module ciot. Modulele driver se implementează mult mai uşor decât modulele

ciot. Există chiar instrumente care produc automat module driver.

Dezavantajele test ă rii de jos î n sus

1. Programul pe baza căruia se efectuează validarea cerinţelor este disponibil numai după

testarea ultimului modul.

2. Corectarea erorilor descoperite pe parcursul integrării necesită repetarea procesului de

proiectare, codificare şi testare a modulelor. Principalele erori de proiectare sunt descoperite de

abia la sfârşit, când 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 obţinut prin integrarea

modulului principal şi a modulelor direct apelate de el, etc. Metoda presupune implementarea

unui singur modul "driver" (pentru modulul principal) şi a câte unui modul "ciot" pentru fiecare alt

modul al programului.

Integrarea descendentă poate avea loc pe parcursul unei implementări 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 măsură 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 test ă rii de sus î n jos

1. Erorile de proiectare sunt descoperite timpuriu, la inceputul procesului de integrare, atunci

când sunt testate modulele principale ale programului. Aceste erori fiind corectate la început,

se evită reproiectarea şi reimplementarea majorităţii componentelor de nivel mai coborât, aşa

cum se întâmplă când erorile respective sunt descoperite la sfârşitul 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 său

există dintr-o faza timpurie a dezvoltării şi deci se poate exersa cu el în vederea validării

cerinţelor; acest aspect este de asemenea, foarte important în privinţa costului dezvoltării

sistemului.

Dezavantajele test ă rii de sus î n jos

1. Este necesar să se implementeze câte un modul "ciot" pentru fiecare modul al programului,

cu excepţia modulului principal.

2. Este dificil de simulat prin module "ciot" componente complexe şi componente care conţin în

interfaţă structuri de date.

3. În testarea componentelor de pe primele nivele, care de regulă nu afişează rezultate, este

necesar să se introducă instrucţiuni de afişare, 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 integrării în condiţii mai bune de

observare a comportării programului.

2.3. Testele de sistem

Acestea sunt teste ale sistemului de programe şi echipamente complet. Sistemul este instalat şi

apoi testat în mediul său real de funcţionare. Sunt teste de conformitate cu specificaţia

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 specificaţia cerinţelor utilizatorilor, până când cele

două părţi cad de acord că programul este o reprezentare satisfăcătoare a cerinţelor.

2.Testarea beta: programul este distribuit unor utilizatori selecţionaţi, realizându-se astfel

testarea lui în condiţii reale de utilizare.

2.5. Testele regresive.

Se numesc astfel testele executate după corectarea erorilor, pentru a se

verifica dacă în cursul corectării nu au fost introduse alte erori. Aceste teste sunt efectuate de

regulă în timpul întreţinerii. Pentru uşurarea lor este necesar să se arhiveze toate testele

efectuate în timpul dezvoltării programului, ceea ce permite, în plus, verificarea automată a

rezultatelor testelor regresive

3. Determinarea cazurilor de testTestarea 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;

- funcţia / funcţiile exersate prin datele respective;

- rezultatele (datele de ieşire) aşteptate;

În principiu (teoretic) testarea ar trebui să fie exhaustivă, adică să asigure exersarea tuturor

căilor 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 r ă spunsul programului

atât la intr ă ri valide cât ş i la intr ă ri nevalide .

Sunt două metode de generare a cazurilor de test:

1. Cazurile de test se determin ă pe baza specifica ţ iei componentei testate, fără cunoaşterea

realizării ei; acest tip de testare se numeşte testare “cutie neagra”

2. Cazurile de test se determin ă prin analiza codului componentei testate . Acest tip de testare

se mai numeşte şi testare “cutie transparentă”, sau testare structural ă .

3.1. Testarea “cutie neagr ă ”. Cazurile de test trebuie să asigure următoarele verificări:

- reacţia componentei testate la intrări valide;

- reacţia componentei la intrări nevalide;

- existenţa efectelor laterale la execuţia componentei, adică a unor efecte care nu rezultă din

specificaţie;

- performanţele 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 plecând de la specificaţii 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 partiţionând atât datele de intrare cât şi cele de ieşire într-un număr

finit de clase de echivalenţă. Se grupează într-o aceeaşi clasă datele care, conform specificaţiei,

conduc la o aceeaşi comportare a programului.

O dată stabilite clasele de echivalenţă ale datelor de intrare, se alege câte un eşantion (de date

de test) din fiecare clasă.

Alte cazuri de test se aleg astfel încât la folosirea lor să se obţină eşantioane din clasele de

echivalenţă ale datelor de ieşire (din interiorul si de la frontierele lor).

In alegerea datelor de test trebuie să se elimine redundanţele rezultate din considerarea atât a

claselor de echivalenţă de intrare cât şi a celor de ieşire.

Unele programe tratează datele de intrare în mod secvenţial. În aceste cazuri se pot detecta

erori în program testându-l cu diverse combinaţii ale intrărilor în secvenţă. Metoda de

partiţionare în clase de echivalenţă nu ajută în alegerea unor astfel de combinaţii. Numarul de

combinaţii posibile este foarte mare chiar şi pentru programe mici. De aceea nu pot fi efectuate

teste pentru toate combinaţiile. în aceste cazuri este esenţială experienţa celui care alcătuieşte

setul de cazuri de test. Testarea "cutie neagră" este favorizată de existenţa unei specificaţii

formale a componentei testate.

In alegerea cazurilor de test s-au folosit următoarele euristici:

programele de căutare prezintă erori atunci când elementul căutat este primul sau ultimul in

structura de date;

de multe ori programatorii neglijează situaţiile în care colecţia prelucrată în program are un

număr de elemente neobişnuit, de exemplu zero sau unu;

uneori, programele de căutare se comportă diferit în cazurile: număr de elemente din colecţie

par, respectiv număr de elemente din colecţie impar; de aceea sunt testate ambele situaţii

Concluzii:

1. Setul de cazuri de test a fost determinat numai pe baza specifica ţ iei componentei ş i a unor

euristici (este vorba de experien ţ a celui care efectueaz ă testele) , deci fără să se cunoască

structura internă a componentei, care este tratată ca o “cutie neagră”. Eventuala examinare a

codului sursă nu urmăreşte analiza fluxului datelor şi a căilor de execuţie, ci doar identificarea

variabilelor globale cu care componenta interacţionează.

2. Clasele de echivalen ţă se determin ă pe baza specifica ţ iei .

3. Se aleg drept cazuri de test eşantioane din fiecare clasă de echivalenţă a datelor de intrare.

Experien ţ a 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 număr limitat de eşantioane din

clasele de echivalenţă ale datelor de intrare; faptul că din testare a rezultat că ea funcţionează

corect pentru un membru al unei clase nu este o garanţie că va funcţiona corect pentru orice

membru al clasei.

5. Se determină de asemenea clasele de echivalenţă ale datelor de ieşire şi se aleg pentru

testare datele de intrare care conduc la date de ieşire aflate la frontierele acestor clase.

6. Partiţionarea în clase de echivalenţă nu ajută la depistarea erorilor datorate secvenţierii

datelor de intrare. In aceste cazuri este utilă experienţa programatorului. Reprezentarea

comportării programului printr-o diagramă de stări-tranziţii poate fi folositoare în determinarea

secvenţelor de date de intrare de utlizat în testarea programului.

Testele “cutie neagră”, numite şi teste funcţionale sunt utile nu numai pentru testarea

programului. Ele pot fi utilizate (ca teste statice) pentru verificarea unei specificaţii intermediare

faţă de o specificaţie de nivel superior.

“Slăbiciunile” testelor funcţionale:

- Nu este suficient să se verifice că programul satisface corect toate funcţiile specificate;

unele proprietăţi interne, nespecificate, ca de exemplu timpul de răspuns, nu sunt verificate;

- Programul este testat pentru “ceea ce trebuie să facă” conform specificaţiilor şi nu şi pentru

ceea ce face în plus, de exemplu pentru ca implementarea să fie mai eficientă sau pentru a

facilita reutilizarea;

- In absenţa unui standard în privinţa specificaţiilor 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 cărui noduri sunt de două tipuri: noduri care corespund

“blocurilor de instrucţiuni indivizibile maximale” şi noduri care corespund instrucţiunilor de

decizie. Blocurile de instrucţiuni indivizibile maximale sunt porţiuni liniare maximale de

instrucţiuni care se execută întotdeauna în aceeaşi secvenţă. Fiecare bloc are un singur punct

de intrare şi un singur punct de ieşire. Arcele reprezintă transferul controlului între

blocurile/instrucţiunile componentei program.

Graful program are un nod unic de intrare şi un nod unic de ieşire. Dacă există mai multe

puncte de intrare sau mai multe puncte de ieşire, acestea trebuie să fie unite într-unul

singur(care se adaugă suplimentar). Nodul de intrare are gradul de intrare zero, iar cel de ieşire

are gradul de ieşire zero.

Se consideră căile care încep cu nodul de intrare şi se termină cu nodul de ieşire. Testarea

structurală constă în execuţia componentei testate pentru date de intrare alese astfel încât să

fie parcurse unele dintre aceste căi. Nu este necesar, şi în general este imposibil, să se

execute toate căile de la intrare la ieşire ale unui program sau ale unei componente program.

Prezenţa ciclurilor conduce la un număr foarte mare (deseori infinit) de căi. De asemenea,

anumite căi sunt ne-executabile.

Testele structurale favorizează evidenţierea următoarelor tipuri de erori logice:

1. Căi absente î n graful program - ca urmare a ignorării unor condiţii

(de exemplu: test de împărţire la zero);

2. Selectarea unei căi necorespunzătoare - datorită exprimării

incorecte (de multe ori incomplete) a unei condiţii;

3. Acţiune necorespunzătoare 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 execuţia tuturor instrucţiunilor programului.

Alegerea căilor de testat are loc pe baza unor “criterii de acoperire” a grafului de control. Dintre

acestea cele mai cunoscute sunt:

Execuţia tuturor instrucţiunilor

Cazurile de test se aleg astfel încât să se asigure execuţia tuturor instrucţiunilor

componentei testate. Acesta este un criteriu de testare minimal. El nu este întotdeauna

satisfăcător.

Traversarea tuturor arcelor

Cazurile de test se aleg astfel încât să se asigure traversarea fiecărui arc al grafului

program cel puţin pe o cale. Pe baza acestui criteriu se va putea verifica dacă transferul

controlului este corect pentru valoarea FALSE a condiţiei, în exemplul de mai sus. In acelaşi

timp, criteriul nu impune traversarea mai mult de o dată a unui ciclu. Anumite erori apar numai

atunci când un ciclu este traversat de mai multe ori.

Traversarea tuturor căilor

Pe baza acestui criteriu ar trebui ca testele să asigure traversarea tuturor căilor

componentei testate. Pentru majoritatea programelor nu se poate aplica acest criteriu,

deoarece numărul de căi de execuţie este infinit. Criteriul poate fi restricţionat, de exemplu

asigurând traversarea tuturor căilor cu o lungime mai mică sau egală cu o constantă dată.

Problema alegerii cazurilor de test constă din trei subprobleme distincte:

- selectarea căilor de testat;

- alegerea datelor de test pentru execuţia fiecărei căi selectate;

- determinarea rezultatelor care trebuie să se obţină la fiecare test.

In continuare prezentăm o metodă de alegere a datelor de test pe baza criteriului traversării

tuturor arcelor grafului de control. Metoda presupune parcurgerea următoarelor etape:

1. Se determină setul căilor de testat, C, astfel încât:

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

c) lung (c) = minima c C

2. Se determină predicatul fiecărei căi, c C, Rc(I), unde

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 căii:

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=14. 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 selecţionate 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 funcţional. Mai

exact trebuie să se înceapă cu testarea funcţională 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 distribuţia datelor de intrare estimate pentru exploatarea programului – aceste

teste se mai numesc teste statistice operaţionale.

Rezultatele experimentale ale testelor statistice uniforme sunt inegale. Ele nu acoperă căile

care corespund tratării excepţiilor. De aceea trebuie completate cu teste folosind date de

intrare în afara domeniului intrărilor.

Testele statistice operaţionale sunt în general teste de fiabilitate. Prin ele nu se urmăreşte în

general descoperirea de erori ci mai ales comportarea programului în timp. Căderile 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:

o Articolele revizuite sunt conforme cu specificatiile facute in fazele anterioare,

o Ele au fost produse in conformitate cu standardele prevazute,

o 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

o De actualizat: documentul va fi actualizat (modificat)

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

o Rejectare: problema este inchisa fara actualizare sau actiune

Fiecare intrunire se termina prin:

o O decizie, daca este necesara o noua intrunire

o Posibil, o autorizare de a se trece la faza urmatoare

o 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.

o 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

o 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.UrmarieUrmarirea 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 calităţii   : Ansamblul activităţilor care trebuie întreprinse pentru ca un produs să fie de calitate Ce acoperă un Sistem de Asigurare a Calităţii:

a) Activităţile propriuzise de inginerie

- analiza;

- proiectarea (concepţia);

- codificarea

- testarea (metode şi instrumente)

b) Reviziile aplicate la fiecare pas al proiectului

c) Strategiile de testare

d) Controlul documentaţiei software şi a ţinerii ei la zi

e) Compatibilitatea cu standardele (dacă este cazul)

f) Mecanismele de măsurare şi raportare (pentru a avea o măsură cantitativă a

calităţii)

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 totalaComplexitatea 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 .. + ivnunde iv1, iv2, ivn sunt complexitatile de proiectare ale modulelor din ansamblu.

5. Complexitatea integrariiComplexitatea 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