Tehnici de dezvoltare a produselor software bazate pe metode orientate obiect (elemente de inginerie software)

Complexitatea activitatilor desfasurate intr-o organizatie, progresele inregistrate in domeniul tehnicii de calcul si mai ales in domeniul limbajelor de programare, au determinat aparitia si dezvoltarea Ingineriei Software (Software Engineering). Privita ca un cumul de metode si tehnici bazate pe realizari din domeniul IT, permite trece de la o dezvoltare a produselor ad-hoc si imprevizibila, la o dezvoltare structurata, constructiva si sistematica, cu scopul de a produce in mod industrial aplicatii software de cea mai buna calitate.

Termenul a fost adoptat in 1968 la NATO Software Engineering Conference, tinuta la Garmisch, Germania. Include cunostinte, instrumente si metode pentru definirea cererilor, pentru specificarea, construirea si intretinerea programelor

Dintre definitii mentionam:

F. L. Bauer (prima definitie data ingineriei software):

Ingineria programarii este stabilirea si utilizarea de principii ingineresti solide pentru a obtine in mod economic programe sigure si care functioneaza eficient pe masini de calcul reale

IEEE Standard Glossary of Software Engineering Technology (1983):

Ingineria software reprezinta abordarea sistematica a dezvoltarii, functionarii, intretinerii si retragerii din functiune a programelor

Acest domeniu:

▪▪▪ are ca scop dezvoltarea metodelor, instrumentelor si tehnicilor ce pot asigura un proces de producere software controlat, rezultatul fiind aplicatii software performante si fiabile.

▪▪▪ este legat de tehnologii si practici apartinand stiintei calculatoarelor, managementului proiectelor, ingineriei, proiectarii interfetelor si altor domenii

este in relatie cu alte discipline de inginerie: inginerie de sistem si gestiune de proiecte, siguranta si fiabilitatea sistemelor.

▪▪▪ se preocupa de procedeele de construire software, astfel incat sa fie indeplinite urmatoarelor criterii:

▪ sistemul creat raspunde nevoilor utilizatorilor

▪ calitatea corespunde contractului de service initial

▪ costurile raman in limitele prevazute initial

▪ intarzierile raman in limitele prevazute initial

Tema: Prezentati si comentati citeva definitii/caracteristici ale ingineriei software.

Principalele ramuri ale ingineriei software acopera:

▪ tehnicile de specificare

▪ tehnicile de conceptie

▪ tehnicile de validare/verificare

▪ gestiunea proiectelor

▪ aspectele socio-economice ale proiectelor de dezvoltare a produselor software.

1 Tehnici de specificare

In ingineria produselor software, prin specificare intelegem o descriere a unor caracteristici ale produsului final (un program sau o aplicatie formata dintr-un sistem de programe) care trebuie sa fie realizate in mod obligatoriu de catre proiectant (programator) pentru ca produsul sa poata fi acceptat si utilizat de beneficiarul sau.

Dezvoltarea produselor (aplicatiilor) software complexe este insa un proces care se desfasoara in etape succesive (fazele ciclului de viata a produsului), in fiecare dintre aceste etape, scopul si instrumentele de descriere a specificatiilor fiind diferite. Vorbim astfel despre diferite tehnici de specificare, caracteristice fiecarei faze de dezvoltare a produselor software complexe:

▪ tehnici de specificare a cerintelor sau a exigentelor functionale si nefunctionale (eficacitate, dimensiuni, siguranta in functionare etc.) ale utilizatorului fata de produsul software; se aplica in faza de analiza a cerintelor si se exprima, in general, in limbaj natural;

▪ tehnici de specificare a sistemului; se aplica in faza de analiza de sistem si se refera la natura functiilor oferite, comportamentul dorit si datele necesare pentru realizarea functiilor produsului software;

▪ tehnici de specificare a arhitecturii sistemului; se aplica in faza de conceptie generala si definesc modulele de arhitectura ale produsului software care urmeaza sa fie realizat;

▪ tehnici de specificare tehnica (sau de detaliu); se aplica in faza de proiectare detaliata a modulelor, programelor si structurilor de date care compun produsul software.

In teoria ingineriei software se regasesc mai multe criterii de apreciere a eficientei tehnicilor de specificare. Astfel, spre exemplu, tehnicile de specificare trebuie sa permita realizarea unor specificatii (documentatii) clare, neambigue si suficient de inteligibile pentru utilizator ca si pentru diversele categorii de specialisti implicati in dezvoltarea produsului. De asemenea, pentru a fi utile, specificatiile trebuie sa fie coerente (adica sa nu contina contradictii) si complete. Completitudinea poate fi vazuta in doua moduri: completitudine interna, cu semnificatia ca toate conceptele utilizate sunt clar specificate, si completitudine externa in sensul ca acopera in intregime realitatea descrisa. Aceasta forma este insa dificil de satisfacut in practica, pentru ca nu pot sau ar dura prea mult sa fie sesizate si anticipate toate detaliile domeniului in care se incadreaza sistemul proiectat. Din acest motiv, aplicarea tehnicilor de specificare trebuie sa fie iterativa, adica sa permita testarea si reluarea, pentru eventuale completari, a pachetelor de specificatii caracteristice fiecarei faze a ciclului de dezvoltare.

In teoria ingineriei software sunt recunoscute doua criterii de clasificare a specificatiilor:

▪ prin formalismul utilizat:

. specificatii informal - exprimate, in general, in limbaj natural;

. specificatii semiformale - prezentate in general in forme grafice, avand un inteles mai mult sau mai putin precis;

. specificatii formale - a caror sintaxa si semantica sunt definite in mod formal printr-un aparat matematic adecvat

▪ prin caracteristicile descrise:

. specificatii declarative - descriu doar proprietatile produsului, necesare pentru a raspunde cerintelor utilizatorului;

. specificatii operationale - descriu comportamentul produsului in raport cu cerintele utilizatorului si care sunt descrise printr-un model care poate fi simulat pe o cale oarecare.

In fiecare faza a ciclului de viata a unui produs software, prin construirea specificatiilor se realizeaza un anumit nivel (conceptual, logic, fizic etc.) al unui model complet al produsului final. In elaborarea modelului pot interveni diverse categorii de specialisti, reprezentand diferite puncte de vedere (utilizator, proiectant, programator etc.). Se pot folosi limbaje de modelare diferite, mai mult sau mai putin formale. Prin urmare, modelele se pot dezvolta in paralel si in forme diferite in diferite faze, devenind, deseori, incomplete si incoerente. Introducerea unor instrumente (limbaje) de specificare semiformala are ca scop sa lase libertatea fiecarei categorii de specialisti implicati in dezvoltarea unui proiect, sa isi exprime punctul de vedere specific asupra acelei parti a problemei care le revine spre rezolvare, insa folosind instrumente de reprezentare comune (standardizate), in general de tip grafic, astfel incat, sub aspect declarativ, modelul sa fie unitar si sa permita o dezvoltare iterativa. Sunt cunoscute diverse tehnici (SADT), metode (Merise) sau limbaje (UML) de specificare, insa ceea ce ramane invariant este faptul ca aplicarea lor este legata de fazele de dezvoltare a produselor software.

1.1 Tipuri de specificare

▪ Specificarea informala (in limbaj natural)

. permite comunicarea intre nespecialisti;

. nu impune reguli sau conventii de structurare si este lipsita de precizie,

fiind, prin urmare, dificil de analizat.

▪ Specificarea semiformala

Un exemplu tipic de aplicare a tehnicilor de specificare semiformala, utilizate in practica proiectarii produselor software, este specificarea structurii datelor cu ajutorul diagramei (modelului) EA (Entitate-Asociere). Astfel, acest tip de specificare reprezinta o tehnica semiformala si declarativa, bazata pe un model (Peter Chen, 1976), avand urmatoarele caracteristici:

. modelul nu este normalizat, fiind deschis fata de alte metode de reprezentare care aduc elemente specifice fara a denatura modelul, cum ar fi agregarea si mostenirea intre entitati, precum si restrictiile suplimentare intre date, preluate din UML;

. modelul permite specificarea structurilor de date si a relatiilor dintre elementele de date care compun structurile reprezentate;

. reprezentarea este necesara, in special, pentru sistemele care utilizeaza

un volum mare de date, intre care exista interconexiune logica.

▪ Specificarea formala

Exista numeroase tehnici formale si declarative, bazate pe aparate matematice (teoria multimilor, logica clasica, logicile neclasice (cum ar fi logicile temporale) etc. Sunt utilizate pentru specificarea tipurilor de date abstracte, dar pot fi generalizate pentru a permite specificarea unor sisteme complete (ex: limbajul "Z").

Fiecare tip de specificare acopera ȋn general una sau mai multe faze din ciclul de dezvoltare a produselor software. Exista ȋnsa si situatii ȋn care ȋntr-o aceeasi faza exista tipuri de specificare diferite. De exemplu, din punct de vedere tipologic, diagramele UML se regasesc in clasa specificatiilor semiformale. Totusi, in faza de analiza a cerintelor utilizatorului diagramele cazurilor de utilizare nu sunt intotdeauna semnificative, fiind necesara dezvoltarea lor prin scenarii, adica printr-o descriere informala a rolurilor actorilor implicati. In alte cazuri, diagrama cazurilor de utilizare devine semnificativa atat pentru utilizator cat si pentru proiectant, numai prin diagramele de stare si activitate.

1.2 Utilizarea UML in specificarea semiformala a arhitecturii produselor software

Tehnicile de specificare asigura o reprezentare a sistemului care trebuie sa permita programatorului studierea, documentarea si simularea produsului software final.

UML este un limbaj de specificare grafica si textuala care unifica notatiile si conceptele orientate obiect. In orice faza de dezvoltare a unui proiect de dezvoltare a produselor software, UML serveste la descrierea cerintelor, specificarea si documentarea sistemului, definirea arhitecturii logice a programelor si modelarii solutiilor de implementare. De asemenea UML constituie un instrument de comunicare intre participantii la dezvoltarea unui proiect.

UML introduce un mod propriu de specificare, structurat pe doua niveluri de modelare: conceptual si fizic.

De fapt, UML diferentiaza, prin instrumentele de specificare pe care le contine (diagrame), mai multe puncte de vedere asupra produselor software:

extern (al utilizatorului) reprezentat prin diagrama cazurilor de utilizare, si care descrie functiunile produsului;

static, reprezentat prin diagramele de clase, obiecte, colaborare, secventa, si care descrie structura produsului (elemente componente si relatii intre elemente);

dinamic reprezentat prin diagramele de stare, activitate, si care descrie comportamentul produsului;

fizic de implementare (componentele programabile), reprezentat prin diagramele de componente, care descrie arhitectura (structura si functiuni) programelor (module sau unitati de exploatare independente) care compun produsul software proiectat;

fizic de instalare (configuratia de exploatare), reprezentat prin diagramele de instalare (deployment), care descrie solutia proiectantului privind modul de exploatare a produsului software pe o configuratie fizica adaptata functiunilor produsului si acceptata de utilizator.

Aplicarea UML pentru specificarea dezvoltarii produselor software se bazeaza pe un set de diagrame sintactice care permit descrierea si vizualizarea sistemului. Diagramele descriu componente si stadii specifice ale dezvoltarii proiectului, fiecare diagrama fiind o completare (detaliere) a unei alte diagrame.

Rolul diagramelor UML in specificarea etapelor si proceselor de dezvoltare a produselor software, nu difera de cel pe care il au in specificarea proiectelor de sistem informatic, descris in capitolul precedent. Din acest motiv, nu facem aici decat o referire la ordinea in care diagramele UML sunt utilizate in specificarea proiectelor software:

Diagrama cazurilor de utilizare - permite specificarea cerintelor;

Diagrama claselor - permite specificarea tipurilor de obiecte si relatiilor statice care compun sistemul;

Diagramele fizice:

a)      Diagrama de compozitie - reprezinta configuratia sistemului de programe, aratand cum se articuleaza componentele acestuia (spre exemplu, fisiere sursa, pachete de cod, biblioteci);

b)      Diagrame de implementare - reprezinta configuratia fizica a sistemului in care se incadreaza produsul software;

Diagramele de comportament dinamic:

a)      Diagrama de activitate - arata un comportament al produsului bazat pe o structura de control. Poate reprezenta mai multe obiecte intr-unul sau mai multe cazuri de utilizare. Reprezinta regulile de susccesiune ale activitatilor in sistem.

b)      Diagrama de stare - reprezinta ciclul de activitate comun obiectelor din aceeasi clasa si descrie toate starile posibile pe care le poate lua un obiect precum si modul de schimbare al starilor sub influenta unor evenimente interne sau externe.

c)      Diagrama de interactiune - reprezinta schimbul de mesaje intre obiecte in cadrul unor situatii particulare de functionare a sistemului.

Diagrama de secventa - serveste pentru dezvoltarea scenariilor de utilizare a sistemului. Se regaseste in mod frecvent in faza de analiza.

Diagrama de colaborare - serveste la specificarea metodelor in faza de definire a claselor participante.

2 Tehnici de conceptie

2.1 Rolul tehnicilor de conceptie in dezvoltarea produselor software

Faza de conceptie consta in construirea unei prime forme a produsului, pe baza specificatiilor rezultate din faza de analiza. Prin rafinarea acestei prime forme, in etape succesive (iterativ), se obtine o imagine finala a produsului (proiect), care permite trecerea la etapa de realizare a programelor (implementare).

In informatica, activitatea de conceptie consta in definirea si modelarea aplicatiei informatice, corespunzator cerintelor functionale exprimate prin modelul rezultat din analiza sistemului obiect. Modelul rezultat descrie structura aplicatiei si comportamentul sau.

Tehnicile de conceptie permit definirea arhitecturii logice a sistemului proiectat, intr-o forma care corespunde cerintelor functionale exprimate in faza de analiza. Prin urmare, tehnicile de conceptie fac legatura intre cerintele utilizatorului si solutia de programare gasita pentru implementarea aplicatiei. Trebuie spus ca nu se poate vorbi despre un model universal de conceptie a aplicatiilor si sistemelor informatice. Modelul conceptual depinde de nivelul de abstractizare al problemelor, care trebuie atins inainte de trecerea la realizarea aplicatiei (programare).

Sunt cunoscute in prezent doua paradigme, de conceptie diferita, privind modelarea conceptuala a produselor software: functionala si obiectuala.

Tehnicile functionale permit, in general, modelarea proceselor informationale sub mai multe aspecte, care pot fi vazute separat sau complementar:

dinamic, referitor la fluxurile de date si care reprezinta transformarea datelor in sistem;

static, referitor la structura logica a datelor (entitate-relatie);

functional, referitor la structura logica a prelucrarilor (componentele programabile si relatiile lor in sistem).

Printre cele mai cunoscute tehnici functionale se numara:

SADT (Structured Analysis and Design Technique), dezvoltata de SOFTTECH incepand din 1976, si care sunt aplicate, in general, in fazele initiale ale dezvoltarii produselor software, in special pentru reprezentarea sistemului obiect si analiza cerintelor utilizatorului. Autorii SADT prezinta aceste tehnici ca fiind o metoda unitara de "comunicare a problemelor". Modelarea se bazeaza pe doua tipuri de diagrame obtinute prin rafinari succesive: diagrama datelor (datagrama) care permite reprezentarea datelor si a activitatilor care le creeaza sau le utilizeaza si diagrama activitatilor (actigrama)care descrie inlantuirea activitatilor din sistem;

JSD (Jackson Software Development), dezvoltata incepand din 1985, ale carei concepte de baza sunt procesele si fluxurile de date. Utilizeaza doua tipuri de diagrame: SSD (System Specification Diagram), care permit descrierea comunicatiei intre procese, si arborii JSD, care permit descrierea structurii sistemului in mod ierarhic, utilizand pentru componentele logice ale sistemului notiunea de modul;

MERISE, definita intre 1978-1979 si adaptata pentru modelerea si reprezentarea sistemelor tranzactionale care utilizeaza volume mari de date. Acopera toate etapele ciclului de dezvoltare a sistemelor informatice (analiza, proiectare, implementare).

Tehnicile obiectuale (orientate obiect) au fost concepute pentru a permite dezvoltarea unor componente reutilizabile ale produselor software. Aceste componente (module) incorporeaza intr-o forma coerenta datele, functiunile si logica de control a modulelor programabile. Tehnicile obiectuale pot fi considerate ca fiind, in mod egal, metode de specificare (analiza) si metode de conceptie (proiectare).

Paradigma obiectuala se deosebeste de abordarea functionala prin faptul ca nu trateaza (separa) in mod distinct datele de prelucrari, propunand regruparea si asocierea datelor si prelucrarilor in entitati numite "obiecte". Fiecare obiect poseda un ansamblu de proprietati ale datelor cu care opereaza (numite "atribute") si un ansamblu de operatii predefinite (numite "metode") care ii permit sa raspunda unor cereri de prelucrare. Obiectele comunica intre ele prin mesaje care activeaza metodele din obiectele receptoare. Toate obiectele care poseda aceeasi structura apartin unei clase, toate obiectele similare ca structura fiind numite instante ale clasei careia ii apartin.

Diagrama claselor pentru o structura de cod orientat obiect

Pentru rezolvarea unor probleme complexe este necesara definirea unor metode de conceptie care includ, in diverse forme, tehnicile obiectuale.

Sunt cunoscute mai multe astfel de metode:

- metoda OMT (Object Modeling Technique) este o metoda dezvoltata de James Rumbaugh si care acopera, folosind acelasi formalism de reprezentare, ansamblul proceselor de analiza si conceptie. Metoda propune separarea procesului de dezvoltare a produselor software in patru etape: analiza, conceptia sistemului, conceptia obiectelor si implementarea. Metoda abordeaza sistemul din trei perspective: statica (care prezinta ierarhic entitatile din sistem - clase si asocieri) reflectata in UML prin diagrama claselor; dinamica (care prezinta comportamentul dinamic al sistemului prin descrierea starilor entitatilor si a tranzitiilor acestora declansate de diverse evenimente) reflectata in UML prin diagramele de activitate; functionala (care reprezinta procesele, datele permanente stocate in sistem si actorii sistemului si care modeleaza fluxurile de date si tipurile de mesaje care circula in sistem). Fiecare dintre aceste perspective se regaseste intr-un model a carui importanta depinde de tipul de problema studiata. Spre exemplu, in cazul unui sistem interactiv in care aspectul dinamic este esential, tehnicile de conceptie vor fi aplicate trecand de la descrierea secventelor tipice, bazate pe scenarii, la realizarea diagramelor de stare. Modelul static realizat prin OMT este extrem de detaliat. In plus fata de conceptia sistemului, metoda prezinta si conceptia obiectelor, faza in care se precizeaza detaliile de implementare. Metoda este utilizata in dezvoltarea unor aplicatii diverse, contrar altor metode orientate obiect care sunt destul de specializate.

- metoda Booch propune o abordare incrementala si iterativa a dezvoltarii produselor software, bazata pe ierarhizarea sistemului in subsisteme, fara a introduce alte reguli de abordare (ascendenta sau descendenta). In principiu, metoda cuprinde patru etape de dezvoltare: identificarea claselor si obiectelor prin abstractizarea datelor; identificarea continutului semantic al claselor si obiectelor, cu precizarea interfetelor; identificarea relatiilor intre clase cu distingerea aspectelor statice si dinamice; implementarea claselor si obiectelor.

Formalismul de reprezentare a diagramelor de clase in metoda Booch

metoda OOSE (Object Oriented Software Engineering) - introdusa de Ivar Jacobson, este bazata pe folosirea diagramelor cazurilor de utilizare pentru descrierea interactiunilor om-masina care permit studierea comportamentului utilizatorului fata de produsul software proiectat. Diagramele cazurilor de utilizare folosite aici permit, intre altele eliminarea situatiilor indezirabile pentru utilizator, analiza scenariilor alternative, descrierea functiunilor programelor, documentarea aprofundata a solutiilor de proiectare.

Formalismele diagramelor utilizate in metoda OOSE:

Fiecare caz de utilizare dispune de patru scenarii care descriu cazul din urmatoarele puncte de vedere: continut, forma, obiectiv, ciclu de viata.

2.2 Utilizarea UML in faza de conceptie a produselor software

In metodologiile de dezvoltare a produselor software orientate obiect, faza de conceptie (numita si modelare conceptuala) are drept obiectiv identificarea si reprezentarea conceptelor cu care opereaza sistemul. Modelarea conceptuala a programelor orientate obiect se realizeaza in UML pe baza diagramei claselor, definita prin specificatiile de analiza a cerintelor (CE face produsul ?). Insa, prin diagrama claselor se defineste numai structura statica a codului care urmeaza sa fie scris in faza de implementare. Astfel, in faza de conceptie, devine esentiala descrierea dinamica a comportamentului produsului software.

Toate sistemele au o structura statica si un comportament dinamic, iar UML dispune de diagrame care permit identificarea si descrierea ambelor aspecte. Diagramele de clasa exprima cel mai bine structura statica a unui sistem (clasele, obiectele si relatiile dintre ele), dar nu ilustreaza modul in care acestea coopereaza pentru gestionarea taskurilor si pentru realizarea functionalitatii sistemului. Pentru descrierea comportamentului dinamic al produsului software, in faza de conceptie sunt utilizate diagramele UML de stare, secventa, colaborare si activitate.

Diagrama de activitati si diagrama de stari exprima comportamentul claselor care compun programul, iar interactiunea dintre clase este descrisa prin diagramele de colaborari si de secvente. De asemenea, in faza de modelare conceptuala sunt propuse si solutiile de implementare a sistemului, prin intermediul diagramei componentelor si al diagramei de implementare.

Tema:

Descrieti structura statica si comportamentul unui produs software folosind diagramele UML.

3 Tehnici de verificare a produselor software

1 Introducere

Verificarea produselor software nu se refera numai la cod (program), acoperind toate produsele specifice fazelor ciclului de viata al unui proiect informatic. Rezultatul verificarii nu consta, in mod necesar, in acceptarea sau respingerea produsului. De cele mai multe ori, se cauta anomaliile posibile in functionarea produsului. Identificarea unor defectiuni posibile ale produselor software este limitata, mai ales in cazurile programelor de mari dimensiuni. Verificarea produselor software este necesara, in primul rand, pentru descoperirea erorilor de conceptie care pot influenta functionalitatea produsului (caz in care verificarea consta in testarea comportamentului produsului in diverse contexte de functionare), sau pentru identificarea cauzelor unor defectiuni care apar in functionarea curenta a produsului.

In terminologia IEEE (norma 729), termenul de defectiune (cadere) este folosit pentru a desemna o stare a produsului care genereaza o eroare manifestata printr-o anomalie in functionarea programului, si care consta in producerea unui rezultat anormal (in raport cu o anumita norma), sau intr-o pana provocata la nivelul sistemului gazda (blocaj unitate centrala sau periferice, blocarea sistemului de operare etc.):

Anomalie (fault)

Defectiune Eroare

Pana (failure)

Exista doua moduri de abordare a procesului de verificare, care prebuie sa fie considerate complementare:

verificare experimentala (numita si verificare dinamica sau testarea produsului) a comportamentului produsului folosind seturi de date care simuleaza conditiile reale de exploatare;

analiza proprietatilor produsului, fara simularea executiei programelor componente (numita si verificare statica).

2 Testarea sau verificarea dinamica

Consta in efectuarea unor jocuri de test (de incercare) care nu pot fi, in general, exhaustive. Jocul de test este ales astfel incat rezultatele executiei programului sa fie comparabile cu rezultatele asteptate conform specificatiilor de functionare ale produsului (partiale sau globale). Scopul este de a pune in evidenta eventualele erori. Testele pot sa arate prezenta erorilor dar nu pot demonstra absenta erorilor.

2.1 Construirea testelor

Se disting trei moduri de abordare a constructiei jocurilor de test:

a) Abordarea aleatoare a testului

Testul este ales in mod aleator din domeniul de definitie al datelor de intrare ale programului. Domeniul de definitie este stabilit pe baza specificatiilor de interfata operator-masina ale programului (intrari-iesiri). Metoda nu garanteaza o buna acoperire a ansamblului intrarilor. In particular, testul poate sa nu surprinda unele limite sau situatii de exceptie, avand astfel o eficacitate limitata.

b) Abordarea functionala (sau a "cutiei negre") :

Se iau in considerare numai specificatiile privind functiunile programului (sau CE trebuie sa faca produsul). Specificatiile trebuie sa fie suficient de clare si complete pentru a permite verificarea fiecarei functiuni predefinite. Verificarea functionala se refera in special la date si rezultate. Poate sa apara insa riscul unor "explozii combinatoriale", care antreneaza necesitatea de a dispune de un volum foarte mare si de o larga varietate de date de intrare, si care ar putea duce la costuri si durate excesive de testare.

O tehnica utilizata frecvent este analiza valorilor limita si regruparea in clase de echivalenta. Se bazeaza pe observatia ca erorile apar deseori la limita domeniiilor de definitie ale variabilelor incluse in program. Prin partitionarea valorilor in clase de echivalenta, in loc sa se testeze toate valorile posibile ale variabilelor, devine suficient sa se testeze numai limitele acestor clase de echivalenta. Spre exemplu, daca valorile unei variabile pot sa varieze in intervalul [a, b], se pot defini trei clase de echivalenta: < a, in interval, > b, adica se pot testa valorile: 0, a-e, a, a+e, b-e, b, b+e, unde e este un numar pozitiv suficient de mic pentru a nu depasi diferenta dintre limitele intervalului.

c) Abordarea structurala (sau a "cutiei albe"):

In aceasta forma, testarea se refera la structura interna a programului (modulului). Se pot stabili mai multe criterii de aplicare a testului:

c1) Criteriul parcurgerii instructiunilor - jocul de test trebuie sa arate ca toate instructiunile elementare sunt executate cel putin o data;

c2) Criteriul parcurgerii arcelor si nodurilor grafului de control - graful de control este o retea care cuprinde structurile de control ale programului, cum ar fi spre exemplu:

Sa vedem un prim exemplu de construire a unui graf de control pentru un program foarte simplu, scris in pseudocod Pascal, care aplica algoritmul lui Euclid pentru gasirea celui mai mare divizor comun al doua numere naturale:

begin

read(x) ; read(y) ;

while (not (x = y) ) loop

if x > y then

x := x - y ;

else

y := y - x ;

end if

end loop

cmmd := x ;

end

Se observa imediat ca, spre exemplu, jocul de test (x=3,y=3), (x=4,y=3), (x=3,y=4) acopera ambele criterii.

Fie, acum, un alt exemplu:

if x < 0 then

x := -x ;

end if

z := x ;

Se observa imediat ca, spre exemplu, pentru (x = -2) criteriul de parcurgere a instructiunilor este satisfacut, insa nu este satisfacut criteriul de parcurgere a grafului de control. Ar fi insa important de verificat ce se intampla cand x este un numar pozitiv !

Aplicarea criteriului c2 ne da posibilitatea de a defini o masura a complexitatii programului, numita complexitate ciclomatica si care poate fi exprimata prin formula:

C = A - N + 2

unde A este numarul de arce si N este numarul de noduri ale grafului de control.

Se poate demonstra ca numarul C este limita superioara a numarului de teste de efectuat pentru parcurgerea fiecarui arc cel putin o data. In primul exemplu de mai sus, putem observa ca valoarea C = 11 - 10 + 2 = 3 defineste si dimensiunea necesara a jocului de test. In al doilea exemplu de mai sus, C = 5 - 5 + 2 = 2 defineste si dimensiunea testului necesara pentru parcurgerea grafului in intregime.

c3) Criteriul de parcurgere a drumurilor din graful de control.

Spre exemplu:

if (not ( x=0)) then

y := 5 ;

else

z := z - x ;

end if

if (z > 1) then

z := z / x ;

else

z := 0 ;

end if ;

Asociem acestui program un graf de control cu dubla conditionare:

Testul (x=0,z=1), (x=1,z=3) verifica parcurgerea arcelor dar nu si a drumurilor in graf si, prin urmare, nu poate detecta o impartire la zero.

Testul (x=0,z=3), (x=1,z=1), (x=0,z=1), (x=1,z=3) verifica parcurgerea drumurilor in graf si, prin urmare, va detecta cazurile de inmpartire la zero.

Totusi, numarul de drumuri poate deveni foarte mare in cazul programelor de mari dimensiuni, ceea ce face ca acest criteriu sa nu poata fi aplicat in multe dintre cazurile reale. Spre exemplu, un program de cateva linii cuprinzand doua cicluri imbricate de cate 20 de iteratii fiecare, in care ciclul intern contine o secventa de 4 conditionari (selectii) genereaza 6400 de drumuri posibile (20 x 20 x 2 x 2 x 2 x 2).

c4) Criteriul de verificare a conditiilor.

Testul trebuie sa acopere posibilitatile "adevarat" si "fals" pentru toate conditiile elmentare din secventele condtionale (IF si CASE).

Fie exemplul:

if (a > 1 and b = 0)

x := x / a ;

end if

if (a = 2 or x > 1) then

x := x + 1 ;

end if

Modul de generare de teste este poate cel mai simplu de explicat pornind de la ipoteza operatorilor cu evaluare in scurt-circuit:
- pentru AND, se efectueaza un test cu primul operand F (restul nu mai au efect) si apoi doua teste cu primul operand T si urmatorul, respectiv, F si T;
- pentru OR se efectueaza un test cu primul operand T (restul nu mai au efect) si inca doua teste cu primul operand F si al doilea T si F, etc.

Pentru exemplul de mai sus, rezulta o tabela de forma:

a > 1 b = 0 a = 2 x > 1 Rezultat

F - - - F

T F - - F

T T - - T

- - T - T

- - F T T

- - F F F

Se observa imediat ca, spre exemplu, esantioanele de date de test (a=1,b=0,x=3), (a=2,b=1,x=1) acopera toate conditiile (criteriul c4) dar nu acopera toate instructiunile (criteriul c1).

Consideram ca, pe baza exemplelor de mai sus, se poate observa ca o strategie ideala de verificare ar fi de combinare a criteriilor de testare.

Sa mai observam, de asemenea, ca testele structurale (cutia alba) nu pot fi reutilizate ca atare in cazul modificarii programelor pentru care au fost deja aplicate. In acest caz, testele trebuie sa fie reluate fara a mai lua in considerare rezultatele verificarilor aplicate asupra versiunilor de cod precedente.

4 Un exemplu de aplicare a testului cutiei albe

Fie urmatorul program descris in pseudocod:

citeste(x)

citeste(y)

z = 0

semn = 1

daca x < 0 atunci

semn = -1

x = - x

sfarsit daca

daca y < 0 atunci

semn = - semn

y = - y

sfarsit daca

atata timp cat x >= y executa

x = x - y

z = z + 1

sfarsit

z = semn * z

a) Desenati graful de control asociat programului si numerotati nodurile.

b) Prin ce secventa de noduri trebuie sa trecem pentru a satisface criteriul de acoperire a instructiunilor? Precizati jocul de test minim necesar pentru satisfacerea acestui criteriu.

c) Prin ce secventa de noduri trebuie sa trecem pentru a satisface criteriul de acoperire a arcelor ? Precizati jocul de test minim necesar pentru satisfacerea acestui criteriu.

d) Prin ce secvente de noduri trebuie sa trecem pentru a acoperi toate drumurile posibile din graf ? Precizati jocul de test minim necesar pentru satisfacerea acestui criteriu.

Solutie:

a)

b) noduri 1 2 3 4 5 6 7 8 9 10 11 12

joc de test (x=-5, y=-2)

c) noduri 1 2 5 8 11 12 si 1 2 3 4 5 6 7 8 9 10 11 12

joc de test (x=2, y=5) et (x=-5, y=-2)

d) noduri 1 2 5 8 11 12 si 1 2 5 8 9 10 11 12 / 1 2 3 4 5 8 11 12 si

1 2 3 4 5 8 9 10 11 12 / 1 2 5 6 7 8 11 12 si

1 2 5 6 7 8 9 10 11 12 / 1 2 3 4 5 6 7 8 11 12 si

1 2 3 4 5 6 7 8 9 10 11 12

joc de test (x=2, y=5) (x=5, y=2)

(x=-2, y=5) (x=-5, y=2)

(x=2, y=-5) (x=5, y=-2)

(x=-2, y=-5) (x=-5, y=-2)

2.2 Alte tipuri de teste de verificare dinamica

Testele unitare

In paragraful precedent am pornit de la ipoteza testarii unor programe izolate, adica independente de alte programe sau module de programe. Testarea unui modul (format din mai multe programe care pot comunica prin mesaje) este asemanatoare cu testarea unui program izolat, daca acesta poate functiona independent de alte programe sau module. Altfel, daca programul sau modulul apeleaza alte programe sau module, sau este apelat din alte programe sau module, este necesara aplicarea unor teste de coeziune a apelurilor. Testul de coeziune consta in simularea comportamentului programelor in cazul apelurilor din alte programe.

Testele de integrare

Dupa efectuarea testelor unitare ale programelor, devine importanta aplicarea unor teste de integrare progresiva a programelor si modulelor in sistemul proiectat. Cunoscut si sub numele de testul alfa, urmareste punerea sistemului de programe in conditii reale de functionare, in cadrul echipei de dezvoltare a produsului, prin simularea actiunilor utilizatorului final.

Testul de receptie

Testul este, in general, efectuat de utilizatorul final al sistemului, pe echipamentele sale, cu participarea producatorului, pentru verificarea specificatiilor de utilizare a produsului. Cunoscut si sub numele de testul beta, presupune distribuirea produsului catre diverse categorii de utilizatori, inainte de construirea versiunii definitive.

Testele de regresiune

Ca urmare a modificarii a unor componente ale produselor software, testul are drept scop verificarea influentelor modificarii asupra celorlalte componente, ramase nemodificate, ale produsului.

3 Testele de verificare statica

Spre deosebire de verificarea dinamica, verificarea statica are ca scop analiza proprietatilor produsului, fara simularea executiei programelor componente.

Sunt cunoscute doua tipuri de tehnici de verificare statica: tehnici informale si tehnici formale. Aplicarea acestor tehnici depinde de complexitatea produsului software analizat si de scopurile testarii.

1 Tehnici informale

Se refera la cercetarea unui document oarecare in vederea descoperirii unor erori.

In cazul unui cod de program, analistul poate juca rolul "masinii" care executa programul ('code walk-through'), sau pot cauta, ca si in cazul unei analize a unui document de conceptie a unei aplicatii, unele erori tipice, pe baza unor liste de verificari predefinite ("check list"). Spre exemplu, o lista de verificari poate cuprinde referiri la o serie de erori clasice de programare, cum ar fi:

utilizarea unor variabile neinitializate;

salturi in sau in afara buclelor:

bucle infinite;

atribuiri incompatibile;

corespondenta gresita intre parametrii formali si efectivi;

teste de egalitate intre valori flotante;

depasitrea tablourilor;

alocarea si eliberarea improprie a zonelor de memorie etc.

Tehnicile informale de verificare statica se aplica in cadrul unor echipe formate din 3-5 participanti, avand roluri bine stabilite (proiectant, analist, moderator, client etc.). In general, verificarea se concentreaza asupra descoperirii erorilor si nu asupra modului de corectare a acestora. Sunt greu de aplicat si costisitoare (echipele trebuie sa fie compuse din experti confirmati), insa sunt considerate destul de eficiente, mai ales cand sunt complementare testelor dinamice. Sunt utilizate mai ales pentru verificarea unor produse software in medii de utilizare pentru care sunt impuse standarde de calitate de inalt nivel (NASA, MOTOROLA, IBM etc.).

2 Tehnici formale

Se pune problema de a proba, in mod formal, corectitudinea unui program. Programul este caracterizat printr-o preconditie (conditia respectarii datelor initiale ale programului) si o postconditie (conditie adevarata dupa executarea programului).

Pentru realizarea verificarii, una dintre metode, metoda Hoare, defineste mai multe afirmatii (asertiuni) logice intermediare. Pornind de la postconditie, pentru fiecare instructiune se descopera care este asertiunea care trebuie sa fie adevarata inainte de apelul instructiunii pentru ca asertiunea de dupa apelul instructiunii sa fie adevarata. Daca se poate parcurge aceasta cale pana la preconditie, se poate accepta ca programul este corect (altfel spus, daca preconditia este adevarata, atunci postconditia este adevarata)

Pentru exemplificare, sa consideram verificarea unor operatii de atribuire si de intrare / iesire.

O instructiune de scriere write(x) este echivalenta unei atribuiri output:=x. O instructiune de citire read(a) este echivalenta unei atribuiri a:=input.

Se defineste o regula (axioma) de substituire inapoi ("backward substitution"):

x := exp

care afirma ca daca Q este adevarat pentru x dupa atribuire, atunci Q este adevarat pentru exp inainte de atribuire. Devine suficient a pune in expresia Q, exp in loc de x.

Spre exemplu, sa facem proba unui program simplu:

begin

read(a) ;

read(b) ;

x := a + b ;

write(x) ;

end

Daca este adevarat dupa write(x), aceasta inseamna ca output = x, trebuie sa fie adevarat dupa x:=a+b.

Deci trebuie sa fie adevarat dupa read(a), adica a:= input1.

Deci trebuie sa fie adevarat dupa read(b), adica b:=input2.

Deci trebuie sa fie initial adevarat.

Cum afirmatia este mereu adevarata, se afla ca preconditia programului implica postconditia, ceea ce inseamna ca programul este corect.