Ingineria Programarii PDF

1.
Graful cauz i efect
a. Aplicare:
Identific cerinele care sunt incomplete i ambigue. Aceast msur exploreaz

intrrile i ieirile programului pentru a elimina ambiguitile i a obine un set complet
i consistent de specificaii.
Acest graf poate fi aplicat, de asemenea, pentru a genera cazuri de test cu o
probabilitate mare de detectare a defectelor existente n programe.
Nu se preocup de structura intern sau comportarea programului.
b. Primitive:
Lista de cauze: toate combinaiile distincte de intrri;

Lista de efecte: condiiile distincte la ieire sau transformrile strii sistemului.
Aex = nr. de ambiguiti rmase de eliminat ntr-un program;
Atot = nr. total de ambiguiti identificate.
c. Implementare:
Un graf cauz-efect este transcrierea formal a specificaiei formulate n

limbaj natural. Astfel se identific toate specificaiile i se mpart n entiti distincte. Se
analizeaz toate specificaiile pentru a stabili toate cauzele i efectele asociate. Fiecare
cauz i fiecare efect sunt identificate printr-un simbol.
Paii parcuri pentru constituirea grafului sunt:
(1) fiecare cauz i efect se reprezint prin cte un nod care are un numr
unic;
(2) se interconecteaz nodurile cauz i cele efect prin analizarea coninutului
semantic al specificaiei, transformndu-l ntr-un graf boolean. Fiecare
cauz i efect pot avea dou stri: true i false. Prin folosirea logicii
booleene, se listeaz toate strile posibile ale cauzelor i se determin n ce
condiii se va produce fiecare efect;
(3) se vor aduga constrngerile care descriu acele combinaii de cauze i
efecte care sunt imposibile semantic sau ambiental;
(4) se identific ambiguitile din:
orice cauz care nu are un efect corespunztor;
orice efect care nu are la baz o cauz;
orice combinaii cauz - efect care contrazic specificaiile sau nu pot fi
realizate.
Msura are expresia:
Aex
CE ( % ) = 1001 .
Atot
Metoda grafului cauz - efect se folosete pentru testarea programului astfel:
se construiete un tabel decizional unde coloanele corespund efectelor, iar
liniile cauzelor;
pentru fiecare efect, se identific n graf combinaii de cauze care duc la
efectul respectiv i se completeaz acea coloan;
se determin starea celorlalte efecte pentru combinaia de cauze determinat;
valorile de pe o coloan formeaz un test pentru sistem.
d. Exemplu:
Se construiete o baz de date cu numerele fiierelor nscrise ntr-un index care

identific locaiile tuturor fiierelor. Indexul are 10 seciuni.
Un sistem de afiare va permite utilizatorului s vizualizeze una din cele 10
seciuni ale indexului printr-o comand format dintr-o liter urmat de o cifr.
Primul caracter {D, L}, unde:
D = display;
L = listare.
Al doilea caracter {0, 1, ., 9} identific seciunea din index.
Ele ocup primele dou coloane.
Dac primul caracter e greit se tiprete mesajul A de eroare, iar pentru al doilea
mesajul B, unde:
A = comanda greit;
B = numr index greit.
n constituirea grafului cauz - efect se identific cauzele i efectele astfel:
Cauze:
(1) caracterul din coloana 1 este D.
(2) caracterul din coloana 1 este L.
(3) caracterul din coloana 2 este o cifr.
Efecte:
(50) este vizualizat seciunea din index.
(51) este tiprit mesajul A.
(52) este tiprit mesajul B.
1 NOT 51
OR 20
2 AND 50
NOT
3 52
Fig. 1 Graful boolean cauz - efect
Nodul 20 este un nod intermediar ce reprezint rezultatul aplicrii operatorului SAU
exclusiv nodurilor 1 i 2.
O ambiguitate a specificaiei este dat de vizualizarea seciunii, pentru c nu se
precizeaz dac e vizualizat pe ecran sau tiprit la imprimant atunci cnd se d o
comand corect.
Aceast ambiguitate se elimin prin redefinirea efectului 50 astfel:
50 A - seciunea din index se vizualizeaz pe ecran.
50 B - seciunea din index se tiprete la imprimant.
Graful cauz - efect devine:
NOT
1 20 51
OR
2 AND 50A
AND
3 50B
NOT
52
Fig. 2 Graful boolean cauz - efect (final)
Acum se poate construi tabelul 1, cu coloanele corespunznd efectelor i liniile

cauzelor.
Tabelul 1 Reguli de decizie

E f e c t e
20 C a u
50Az e 50B 51 52
I D L
1 1 1 0 1
2 1 0 1 1
20 0
3 1 1 0
Nepermis (*) * 1 1 1 1 1 1
Fiecare coloan din tabelul 1 se poate converti n mai multe teste echivalente. O
posibilitate ar fi:
Tabelul 2 Teste ale sistemului

Nr. test Intrri Rezultate scontate
1 D3 Se vizualizeaz seciunea 3 (50 A)
2 L5 Se tiprete seciunea 5 (50 B)
3 B6 Comand incorect (51)
4 LX Numr index eronat (52)
e. Instruire:
Graful cauz i efect este o tehnic matematic ce necesit cunotine de logic

boolean.
f. Beneficii:
Aceast msur permite analiza cerinelor, eliminarea ambiguitilor i constituie

o baz pentru dezvoltarea cazurilor de test.
2. Trasabilitatea cerine
a. Aplicare:
Verific conformana dintre specificaiile sistemului i cerinele iniiale ale

beneficiarului, aplicndu-se n faza incipient a ciclului de via.
Prevederea unei cerine sau adugarea unei specificaii n plus inutil pot s apar
n procesul de detaliere a cerinelor iniiale, cnd se creaz arhitectura sistemului
software.
Trasabilitatea e corect dac toate specificaiile asociate arhitecturii
sistemului au corespondent n cerinele iniiale ale beneficiarului i reciproc, dac
toate cerinele se regsesc n arhitectura sistemului.
b. Primitive:
R1 = nr. de cerine implementate n arhitectura sistemului;

R2 = nr. de cerine iniiale (beneficiar).
c. Implementare:
Msura de trasabilitate se calculeaz cu formula:
R1
TM = 100% .
R2
d. Interpretare:
Cnd toate cerinele software beneficiar sunt acoperite de arhitectura

software, msura de trasabilitate este 100%.
Dac msura de trasabilitate e mai mic de 100%, atunci unele cerine
iniiale nu au fost incluse n arhitectura software.
Arhitectura poate, totui, s conin cerine suplimentare celor iniiale. Unele
dintre acestea pot rezulta ca urmare a unor pai de rafinare, altele din noi cerine adugate
arhitecturii. Astfel de situaii trebuie analizate cu atenie.
e. Instruire:
Este necesar instruirea n interpretarea adecvat a rezultatelor.
f. Exemplu:
Se consider un sistem de suparaveghere a traficului care trebuie s transmit un
avertisment la consola operatorului i s-l tipreasc atunci cnd traficul n sistem este
ridicat.
n figura 3, nu se precizeaz tiprirea avertismentului, trasabilitatea nefiind deci
complet.
R1
R2 = R1 + 1 i TM = 100% < 100%.
R2
Avertizare
Trafic intens Sesizare
supervizor
Fig. 3 Arhitectura unui sistem de control al traficului (incomplet)

n arhitectura din fig. 4 se remediaz aceast omisiune:
Avertizare
Trafic intens Sesizare
operator
Mesaj la
imprimant
Fig. 4 Sistem de supraveghere trafic (complet)
Aici R1 = R2 + 1 i TM > 100% pentru c o cerin adiional, care n-a fost iniial
n arhitectura sistemului, s-a introdus (lund fig. 3 ca reflectnd ceea ce a cerut
beneficiarul iniial).
Aceast situaie ar putea fi i o eroare (TM > 100%).
g. Beneficii:
Acest metric, aplicat fazei de design arhitectural software, poate identifica

cerinele beneficiar neimplementate.
Metrica Halstead (metric a textului surs)
Orice limbaj de programare este caracterizat prin:

Definire de instruciuni neexecutabile(declarative);
Instruciuni executabile;
Manipularea, n cadrul expresiilor, a operatorilor i operanzilor;
Programele sunt formate din instruciuni care sunt scrise n secvene,
fr a lua n considerare ordinea execuiei;
Programele sunt privite omogen, fr s se in seama de prelucrrile
fcute.
IPOTEZE DE LUCRU:
- Cu toate c tipurile de date nseamn alocri de zone de memorie
diferite, toi operaranzii sunt considerai omogeni, putnd fi
contorizai global;
- Dei operatorii nseamn nr. diferit de cicluri main, vor fi
considerai omogeni i vor fi, aadar, contorizai global;
- Chiar dac cuvintele cheie folosite n instruciuni executabile
corespund unor secvene de compilare de lungimi diferite, vor fi
considerate omogene i se vor contoriza global.
Aceste ipoteze simplificatoare sunt specifice metricii HALSTEAD.
Se consider:
n1 nr. operanzilor distinci;
n2 nr. operatorilor distinci;
Se vor defini relaiile:
n = n1 + n2, unde n este vocabularul folosit n program;
N = N1 + N2, unde:
N1 nr. total de operanzi care apar n program;
N2 nr. total de apariii ale operatorilor n program;
N lungimea observat a programului.
C = n1 log2( n1 ) + n2 log2( n2 ), unde C este complexitatea estimat
a programului;
V = N log2( n ), unde V este volumul programului;
K = (V n2 N1) / (2 n1), unde K este claritatea programului;
L = ( 2 n1) / ( n2 N1 ), unde L reprezint nivelul de implementare;
D = 1 / L, unde D este dificultatea.
Se observ c metrica HALSTEAD privete programul ca un ansamblu
de componente, fr a lua n considerare interdependenele dintre
instruciuni i modul de execuie a lor.
De exemplu secvenele:
s = 0; s = 0;
i= 0; for ( i =1; i< n; i++ )
x [ i ] = 1; {
for ( i = 1; i < n; i++ ) y[ i ] = 0;
{ z[ i ] = i;
x [ i ] = ( i +3 ) * (i+3); x [ i ] = ( i+3 ) * (i+3);
s+ = x[ i ]; s+ = x[ i ];
} }
Secvena a) Secvena b)
dei sunt diferite ca semnificaie, din punct de vedere al execuiei i al

rezultatelor obinute conduc la valori ale metricii HALSTEAD prezentate
n tabelul 1.
Tabelul 1. Metrica HALSTEAD calculat pt. 2 secvene de program
INDICATORUL SECVENA a) SECVENA b)

n1 7 7
n2 10 10
N1 21 22
N2 26 27
V 192.11 200.28
C 52.87 52.87
D 15 15.71
Pt. secvena a)
n1 = {s, i, x, n, 0, 1, 3}----operanzi distinci;
n2 = { = ; [ ] ( ) < ++ * + }----operatori distinci.
Obs.: 1) { } i , sunt separatori.
2) Cu toate c instruciunile nu sunt comutative, metrica HALSTEAD
nu reflect necomutativitatea, tocmai de aceea, pt. realizarea unor
comparaii reprezentative, ea se aplic unor programe corecte i optimale.
De exemplu secvenele:
s= 0; s= 0;
a = 0; for (i = 0; i < n; i++)
for (i = 0; i < n; i++) {
{ a = 0;
s+ = x[ i ]; s+ = x[ i ];
} }
Secvena a) Secvena b)
, dei sunt identice din punct de vedere al metricii HALSTEAD,

neoptimalitatea secvenei b) nu este reflectat.
NUMRUL CICLOMATIC (Metrica McCabe)
Dac se consider graful G asociat unui program, care are N noduri, M arce i P
componente conexe (pentru care se identific perechi de noduri distincte legate printr-un
lan), numrul ciclomatic v(G) = M N +P.
Numrul ciclomatic reprezint o agregare de elemente neomogene (noduri, arce, perechi
de noduri legate prin lanuri).
De exemplu, pentru graful din fig. 1
X6
X4 X5
X1
X7
X2
X8
X3
Fig. 1 Graf orientat
Numrul de noduri N = 8, numrul de arce M = 7. Perechile de noduri (x1, x5), (x2, x5),
(x3, x5), (x1, x6), (x2, x6), (x3, x6), (x4, x6), sunt legate prin lanuri; n acest caz P = 7.
Numrul ciclomatic asociat grafului din fig. 1 este :
v(G) = M N +P=7 8 + 7 = 6.
Structurilor de program le corespund grafuri care au particulariti impuse de caracterul
secvenial al execuiei instruciunilor. Fiecrei structuri de program i se poate ataa un
graf orientat n care nodurile corespund instruciunilor, iar arcele ordinii de execuie a
instruciunilor. Un astfel de graf are un nod iniial (de start) i un nod terminal (de stop) i
nu este un graf conex, deoarece nu exist un drum de la nodul iniial la cel final. Prin
adugarea unui arc care pleac din nodul terminal i are cealalt extremitate n nodul
iniial se obine un graf conex, ce are o singur component (P = 1).
Numrul ciclomatic se calculeaz dup formula:
v(G) = M N +2,
deoarece a fost adugat grafului iniial un arc suplimentar (fictiv).
De exemplu, pentru un program format din 6 instruciuni de afiare care se execut
secvenial, avnd asociat graful din fig. 2,
I1 I2 I3 I4 I5 I6
Fig. 2 Graful asociat unei secvene liniare de program

numrul ciclomatic este:
v(G) = M N +2 = 5 -6 + 2 = 1.
Intuitiv, structurile liniare sunt identificate cu complexiti minime. n acest caz,
numrul ciclomatic se asimileaz cu o msur de complexitate.
Pentru programul care numr elementele pozitive, negative i nule ale unui masiv
unidimensional, al crui text surs este:
void main()
{
int np, nn, nz, i, x[10]={-3, 2, 7, 0, 11, 0, 2, 4, -1, 0};
I1: np=0;
I2: nn=0;
I3: nz=0;
I4: for(i=0; i<10; i++)
I5: if(x[i] < 0)
I6: nn++;
else
I7: if(x[i] > 0)
I8: np++;
else
I9: nz++;
I11: printf(\n Numarul elementelor negative = %d, nn);
I12: printf(\n Numarul elementelor nule = %d, nz);
I13: printf(\n Numarul elementelor pozitive = %d, np);
}, se asociaz graful din fig. 3:
Vom avea:
Numrul de noduri: N = 13
Numrul de arce: M = 15
Numrul ciclomatic asociat acestui graf:
V(G) = M N + 2 = 15 -13+ 2= 4.
Pentru un modul obinuit, 10 este complexitatea ideal maxim. Pentru un sistem

foarte complex, numrul ciclomatic poate fi mai mare. Dac numrul complexitii
calculate este prea mare, se impune o modularizare a codului.
Literatura de specialitate ofer urmtoarele valori:
Cyclomatic Complexity Risk Evaluation

110 A simple program, without much risk
1120 More complex, moderate risk
2150 Complex, high risk program
>50 Untestable program (very high risk)
Numrul ciclomatic i nivelul de context
Prin convenie, nivelul de context asociat structurii liniare este 1. Instruciunea :

if cond S1
else
S2
Este generatoarea unui nou context, iar secvenele S1 i S2 vor avea nivelul de context
majorat cu o unitate n raport cu nivelul precedent.
Pentru secvena de program:
a = 3;
b = 4;
c = 2;
if (a > b) min = b;
else min = a;
if (min > c) min = c;
printf(\n %d, min); ,graful asociat este dat n fig. 4:
nivele de context
3 2 1 2 3
n1 a=3
n2 b=4
n3 c=2
n4 if(a > b)
da
n6 n5
min=a min=b
n7
endif
n8
if(min > c) da
n9
n10 min=c
endif
n11
printf
Fig. 4 Nivele de context pentru o secven de program

Arcul care efectueaz legtura ntre un nod avnd nivelul de context Ki i un nod
avnd nivelul de context Kj va fi ponderat cu max {Ki, Kj}. Se consider un graf G
asociat programului P avnd n arce, cu ponderile p1, p2, ..., pn i m noduri. Numrul
ciclomatic ponderat este:
C = pi m +2, unde i = 1, ,n.
Indicele ciclomatic ponderat este definit prin:
Ic = C / (n * max{ pi } m + 2.
Pentru secvena de program considerat, graful din figura de mai sus are 12 arce i 11
noduri. Ponderile asociate arcelor sunt date n tabelul nr. 1.
Tabelul 1. Niveluri de context i ponderi asociate arcelor
Arcul (ni, nj) Context Ki Context Kj pi

(n1, n2) 1 1 1
(n2, n3) 1 1 1
(n3, n4) 1 1 1
(n4, n5) 1 2 2
(n4, n6) 1 2 2
(n5, n7) 2 1 2
(n6, n7) 2 1 2
(n7, n8) 1 1 1
(n8, n9) 1 2 2
(n8, n10) 1 1 1
(n9, n10) 2 1 2
(n10, n11) 1 1 1
pi 18
C = 18 11 + 2 = 9.
Numrul ciclomatic calculat dup formula lui McCabe are valoarea:
CMC = M N + 2 = 12 11 + 2 = 3.
Ic = 8 / ( 12 * 2 11 + 2 ) = 9 / 15.
Se observ, analiznd tabelul 2, c ponderea exprim mai bine diversitatea legturilor
dintre noduri.
Tabelul 2. Indicatori ponderai i neponderai
Tip indicatori C sau CMC Ic

Neponderat 3 1
Ponderat 9 9/15
I1 np = 0
I2 nz = 0
I3 nn = 0
I4 for
nu I5 if
da
I7 if
I11
I6 nn++ da
I9 nz++
I8 np++
I12
I13 Continuare ciclu (nod

fictiv)
Fig. 3 Graful asociat programului

1. Timpul mediu de descoperire a urmtoarelor k defecte
a. Aplicare:
Metrica poate fi folosit pentru a proiecta timpul mediu pn la descoperirea
urmtoarelor k defecte, dnd indicaie asupra a ct de mult timp se cere pn ce se obine
un nivel dorit de fiabilitate.
b. Primitive:
f = numr de defecte gsite de la nceputul testrii pn n prezent;
ti = timpul ntre defectarea (i-1) i i pentru un nivel de severitate dat (i=1, ).
c. Implementare:
Timpul mediu pn la defectare (metricul 4) ar trebui folosit pentru estimarea
urmtoarelor k defecte n software. El are expresia:
Timpul mediu pn la descoperirea urmtoarelor k defecte (TME)^ =
f +k 1
MTTF i , unde MTTFi este un timp mediu pn la defectare estimat ntre

^
i =f
defectarea i i i+1 i se poate calcula folosind orice model software bazat pe timpii ntre
defectri. Prin estimarea MTTF, se poate estima ct timp de testare va fi necesar pentru a
descoperi toate defectele sau un subset al defectelor reziduale.
d. Interpretare:
Calculele numerice actuale ale estimrii MTTF depind de distribuia aleas de
model pentru MTTF.
e. Consideraii:
n timpul ciclului de via al dezvoltrii software, ar trebui s se utilizeze
evalurile prediciilor unui model pentru f i n funcie de aceasta s se fac planificri
care se pot realiza.
g. Instruire:
Implementarea acestui metric cere cunoaterea aplicrii modelelor software ale
timpilor ntre defectri.
h. Exemplu:
Se folosete modelul de de-eutroficare Jelinski-Moranda pentru a estima
MTTFi (timpul mediu de defectare ntre defectrile i i i+1).
^ 1 , unde:
MTTFi =
^
^ (NF-i)
Q
^
Q = constant de proporionalitate estimat n model;
^
NF = numr estimat al defectelor existente n program.
Timpul mediu estimat pentru a descoperi urmtoarele defecte este:
f + k 1
1
TME = ^
^ (NF-i)
.
i=f Q
Pentru a ilustra calculul, fie:

^ = 0.05; NF
f = 20, Q ^ = 100.
Timpul mediu, de exemplu, pentru a descoperi urmtoarele 2 defecte este:
21
1 1 1
TME = = + = 0.50
i = 20 ( 0.05)( 100 i ) ( 0.05)( 80) ( 0.05)( 79 )
Observaie: Timpul se poate referi la timpul de execuie CPU sau calendaristic.
i. Beneficii:
Acest metric se poate reprezenta funcie de k (k = 1,2,3, NF) folosind la
aprecierea integritii unui sistem n orice moment dat.
2. Estimarea numrului de defecte rmase (prin seeding)
a. Aplicare:
Numrul estimat de defecte rmase ntr-un program ine de fiabilitatea
programului. Sunt mai multe tehnici de estimare a acestui numr. Aici se propune o
form a plantrii defectelor cu o distribuie omogen.
Acest metric poate fi aplicat oricrei faze a ciclului de via software.
Cutarea defectelor continu pn cnd se descoper un anumit numr de defecte
nsmnate, pe lng cele indigene.
b. Primitive:
NS = numr de defecte plantate;
nS = numr de defecte plantate gsite;
nF = numr de defecte indigene gsite;
c. Implementare:
o echip special insereaz NS defecte reprezentative pentru tipul de defecte
indigene ateptate s existe n soft;
echipa de test raporteaz defectele gsite n timpul unei perioade de test
prestabilit. Precizia estimrii crete cu numrul de defecte care au fost
inserate aleator n software. Fiecare defect raportat trebuie atribuit unei clase
(indigen sau inserat) i totodat se stabilete dac a mai aprut;
estimarea numrului de defecte indigene pentru o anumit clas este:
^ n F NS
NF = , unde :
nS
^
NF se va lua ca parte ntreag.
Estimarea numrului rmas de defecte este:

^ ^
NF rez = NF - nF
probabilitatea gsirii lui nF din NF defecte indigene i a lui nS din NS defecte
nsmnate, adic pentru a se gsi nF + nS defecte n program, este
Pfound = C (NS, nS)(NF, nF) / C(NF + NS, nF + nS) unde;
C(x, J) = x! / (x - J)! J! este combinri de x luate cte J.
d. Consideraii:
msura depinde de presupunerea c defectele nserate sunt reprezentative
pentru defectele existente. n general, nu toate defectele au posibilitate egal n a
fi descoperite de o procedur de test;
defectele sunt corectate n software-ul original numai dup ce s-a
determinat care sunt erorile indigene dintre toate defectele;
corecia defectelor indigene poate duce la generarea altor defecte.
e. Instruire:
se cere instruire n inserarea defectelor i monitorizarea procesului de
testare;
se cere i pricepere n clasificarea defectelor.
f. Exemplu:
Presupunem c s-au inserat 100 de defecte. n timpul perioadei de testare, au fost
gsite 50 din cele 100 de defecte plantate i 2 dintre cele indigene.
Atunci: NS = 100
nS = 50
nF = 2
^ = nFN S 2 100
NF nS = 50 =4
^ ^
Numr de defecte reziduale: NF rez = NF - nF = 4 - 2 = 2.
Nippon Telephone and Telegraph au obinut rezultate bune aplicnd metoda de
inserare defecte unui sistem de operare cu 15000 linii de cod.
3. Acoperire test (coverage)

a. Aplicare:
Msoar completitudinea procesului de testare din perspectiva utilizator i
dezvoltator. Are legtur direct cu etapele de dezvoltare, integrare i testare (pentru
testele de : unitate, sistem i acceptare).
b. Primitive:
(1) program:
funcionale (module, segmente, instruciuni, ramificri, ci);
date (clase de date).
(2) cerine:
cazuri de test;
capaciti funcionale.
c. Implementare:
Acoperire test (TC) are expresia:
(Capabiliti implementate) (Primitive program testate)
TC (%) = (Capabiliti cerute) (Primitive program totale) 100
d. Interpretare:
TC este doar un indicator al desvririi unui test. De obicei exist un
numr infinit de cazuri de test. Acesta poate fi redus semnificativ dac se definesc
logic relaii echivalente referitor la funcii i date;
ncrederea n nivelul testrii crete prin utilizarea de primitive rafinate: de
exemplu, acoperirea segment de 100% este mai puternic dect cea a modulului
de 100%.
e. Consideraii:
programul este un set de instruciuni codificate, iar cerinele sunt un set al
capabilitilor dorite de utilizator;
CUTIE
NNEAGR
CUTIE ALB
PROGRAM
CERINE
CREATIVITATE PROGRAMATOR CERINE IGNORATE/LIPS
CUTIE GRI
(ACOPERIRE DORIT)
Fig. 1 Acoperire testare
intersecia din fig. 1 reprezint setul de capabiliti cerute de utilizator care

sunt implementate;
aria stng reprezint creativitatea programator sau acele zone pentru care s-au
luat decizii de implementare necesare funcionrii hardware-ului;
aria dreapt reprezint capabilitile intenionate ale utilizatorului care lipsesc
n implementare intenionat sau nu;
corespunztor acestui model, se procedeaz astfel:
(1) programului i se asociaz o activitate de testare unitate bazat pe cunoaterea
structurii programului (cunoscut ca WHITE BOX) sau pe cea funcional
(CLEAR BOX TESTING);
(2) cerinelor li se asociaz o activitate de test sistem care, n majoritatea cazurilor,
presupune o necunoatere a implementrii program.
Sunt proiectate scenarii de test care s demonstreze operarea corect din
punctul de vedere al utilizatorului.
Primitivele cerine se cunosc i ele dau o msur de acoperire test orientat
utilizator (BLACK BOX TESTING).
Combinarea celor dou activiti duce la ceea ce se cheam GRAY BOX
TESTING. Testarea n aceast activitate vizeaz produsul, acoperirea prin test a
programului i cerinelor.
f) Instruire:
Utilizatorul ar trebui s neleag baza teoriei de testare.
g). Exemplu:
Presupunem c toate cerinele sunt implementate.
Tabelul 3 d coverage-ul test al unui set de teste n care segmentele sunt
primitivele.
Tabelul 1 Exemplu de msurare a acoperirii testrii

(cu segmente ca primitive)
Nr. Nume Numr Teste executate
de
crt modul segmente Nr. de invocri Nr. de segmente testate Procent coverage
.
50 A 177 12 52 29.38
51 B 15 2 11 73.33
52 C 7 14 4 57.14
53 D 3 34 2 66.67
54 E 54 20 18 33.33
55 F 5 5 3 60.00
56 G 9 1 9 100.00
57 H 29 2 14 48.28
TOTAL 1192 397 454 38.09 %
4. Timpul mediu pn la defectare
a. Aplicare:
Se folosete pentru a testa un MTTF specificat.
b. Primitive:
MTTF este parametrul de baz cerut de majoritatea modelelor de fiabilitate
software;
calculul e dependent de precizia nregistrrii timpului de defectare ( ti ), unde
ti este timpul dintre defectrile (i-1) i i;
pentru un mediu de dezvoltare software, se recomand timpul de execuie
CPU, iar pentru mediul operaional timpul calendaristic (mai puin precis).
c. Implementare:
se pstreaz istoria defectrilor;
se organizeaz defectele n funcie de complexitate, severitate sau rata de
reinserie;
se alege un model reprezentativ al procesului de defectare, care se valideaz
cu datele despre defectri pe care le-am nregistrat.
c. Interpretare:
O valoare mare a MTTF implic o fiabilitate i disponibilitate corespunztoare ale
software-ului.
d. Instruire:
cunotine de statistic matematic i folosire a modelelor de fiabilitate;
calculele pentru majoritatea modelelor de fiabilitate cer implementarea unor
programe pe calculator.
e. Exemplu:
Se consider trei nivele ale severitii claselor de defectare: SF1, SF2 i SF3.
Fiecare clas de defectare are proprii si timpi ntre defectri:
SF1: 180, 675, 315, 212, 278, 503, 431
SF2: 477, 1048, 685, 396
SF3: 894, 1422.
Atunci o estimare a MTTF este:
i
tk
MTTF = , pentru fiecare clas, unde:
k =1 i
tk = timpii ntre defectri;
i = nr. de defectri din clasa de severitate respectiv.
2594
MTTF SF1 = = 370 .57 ,
7
2606
MTTF SF 2 = = 651 .5,
4
2316
MTTF SF 3 = = 1158 .
2
Aceste valori pot fi comparate cu MTTF specificat pentru fiecare clas de
severitate.
Pentru c rata de defectare e constant, funcia de distribuie a defectrii poate fi
presupus exponenial i F(t) = 1 - exp(-t/MTTF), care reprezint probabilitatea
defectrii software n timpul t.
5. Rata de defectare
a. Aplicare:
Poate fi folosit pentru a indica creterea fiabilitii software n funcie de timpul
de testare.
b. Primitive:
ti = timpul ntre defectri pentru un anumit nivel de severitate (i = 1, 2,..);
fi = numrul de defectri ale unui nivel de severitate n intervalul de timp t.
c. Implementare:
rata de defectare (t) poate fi estimat din funcia de fiabilitate, R(t), care
la rndul ei se poate obine din distribuia de probabilitate cumulativ, F(t),
a timpului pn la urmtoarea defectare folosind orice model de cretere
fiabilitate, cum ar fi modelul Poisson neomogen (NHPP) sau modelul de tip
Bayesian.
R' ( t )
Rata de defectare este : (t) = R ( t ) , unde R(t) = 1 - F(t).
d. Interpretare:
(t) obinut din NHPP depinde numai de timpul t i descrete continuu;
(t) care deriv din modelul lui Littlewood depinde de timpul t i valoarea
funciei de cretere fiabilitate (i) la defectarea a i a.
Cernd funciei (i) s fie cresctoare, condiia (ti) (ti - 1) poate fi
respectat doar n sens probabilistic, pentru c programatorul poate introduce noi erori n
timpul coreciei unei erori.
e. Consideraii:
Modelul NHPP face supoziiile:
(1) Fiecare defect are probabilitate egal de expunere;
(2) Nr. de defecte detectate n timpul intervalelor destinate de test , t i, sunt
independente;
(3) Timpul ntre defectrile i-1 i i depinde de timpul pn la a (i-1) a defectare.
f. Instruire:
programe de calcul pe calculator (pt. parametri i indicatori);
cunoatere a proceselor stochastice i a tehnicilor de optimizare.
g. Exemple:
Misra , un specialist NASA, a obinut o funcie valoare medie pentru rata de
defectare testnd peste 0.5 milioane linii cod surs ale unui software folosit n aviaie.
Dup 38 sptmni de testare ( 2455 h) au fost estimai parametrii modelului
NHPP pentru categoria de erori majore:
a = 163.813; b = 0.287 10-3
Rata de defectare descresctoare are expresia:
n n
( t ) = ab exp b ti + t pentru t i t.
i =1 i =1
Littlewood a examinat un set de date de 136 timpi de execuie, publicat de Musa, pentru
a prezice timpii de defectare viitori, utiliznd

( t ) = ,ti t ti +1
t + ( i)
i lund pentru (i) o form liniar:
(i) = 1 +2i.
Parametrii , 1 i 2 s-au obinut cu metoda verosimilitii maxime bazat pe primele 35
de observaii:
= 1.518; 1 = -0.995; 2 = 7.834.
Cu aceasta, rata de defectare dup defectarea i se poate estima cu formula:
^ ( t) = 1518
.
,
t 0.995 + 7.834 i
ti t ti + 1 (i = 1, .136).
h. Beneficii:
scderea ratei de defectare poate fi folosit pentru a arta mbuntirea
fiabilitii software ca un rezultat al folosirii operaionale;
se poate estima timpul necesar atingerii unei inte de fiabilitate
Introducere n Ingineria Programrii
Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 1

Obiective

De a face o introducere n ingineria
software i de a explica importana ei

De a prezenta rspunsuri la ntrebrile
cheie legate de ingineria programrii
De a prezenta aspecte etice i
profesionale ce sunt legate de inginerii
software

Cuprins
ntrebri frecvente despre ingineria

software
Responsabilitate ethic i profesional

Ingineria programrii
Economiile TUTUROR rilor dezvoltate depind de

software.
Tot mai multe sisteme sunt controlate de
programe.
Ingineria software se ocup cu teorii, metode i
instrumente pentru dezvoltarea software
profesional.
Cheltuielile legate de software reprezint un
procent semnificativ n toate rile dezvoltate.

Costuri software
Costurile software de cele mai multe ori
depesc costurile hardware.

Costurile de ntreinere a unui program de obicei
sunt mai mari dect costurile de dezvoltare.
Pentru sistemele cu o via lung, costurile de
mentenan pot depi de cteva ori costurile
de dezvoltare.
Ingineria programrii se ocup cu dezvoltarea
eficient a programelor.

software
Ce este software-ul?

Ce este ingineria software?
Care este diferena dintre ingineria software i
tiina calculatoarelor?
Care este diferena dintre ingineria software i
ingineria sistemelor?
Ce este un proces software?
Ce este un model al procesului software?

software
Care sunt costurile n ingineria software?

Ce sunt metodele ingineriei software?
Ce este CASE (Computer-Aided Software
Engineering)
Care sunt atributele unui software de calitate?
Care sunt provocrile eseniale ale ingineriei
software?

Ce este software-ul?

Programele de calculator i documentaia legat de ele cum
ar fi cerine, modele de proiectare i manuale de utilizare.
Produsele software pot fi dezvoltate pentru un client
particular sau pentru o pia general.
Produsele software pot fi
Generice dezvoltate pentru a fi vndute unei game largi de
utilizatori (cum ar fi Excel sau Word).
Dedicate dezvoltate pentru un singur client n conformitate cu
cerinele clientului.

Software nou poate fi creat prin dezvoltarea de noi
programe, configurnd sisteme software generice sau
reutiliznd software existent.

Ce este ingineria software?
Ingineria software este o disciplin de inginerie
ce se ocup de toate aspectele produciei
software.
Inginerii software trebuie s adopte o abordare
sistematic i organizat i s foloseasc
instrumente i tehnici potrivite cu problema de
rezolvat, cu constrngerile de dezvoltare i cu
resursele disponibile.

Care este diferena dintre ingineria software
i tiina calculatoarelor?
tiina calculatoarelor se ocup cu partea de

teorie i fundamente; ingineria software se ocup
cu prtile practice de dezvoltare i livrare a
programelor utile.
Teoriile tiinei calculatoarelor nu sunt suficiente
pentru ingineria software.

Care este diferena dintre ingineria software
i ingineria sistemelor?
Ingineria sistemelor se ocup cu toate aspectele

de dezvoltare ale sistemelor bazate pe calculator
incluznd hardware, software i ingineria
proceselor. Ingineria software este parte a
acestui proces ce se ocup cu dezvoltarea
infrastructurii software, control, aplicaii i baze
de date n sistem.
Inginerii de sistem sunt implicai n specificarea
sistemelor, proiectarea arhitecturii, integrare i
instalare.

Ce este un proces software?
Este o mulime de activiti ale cror scop este

dezvoltarea sau evoluia unui software.
Activitile generice prezente n toate procesele
software sunt:
Specificare ce ar trebui s fac sistemul i care sunt
constrngerile de dezvoltare
Dezvoltare producia sistemului software
Validare verificarea dac sistemul software este ceea
ce dorete clientul
Evoluie schimbarea sistemului software ca rspuns
la cerinele clientului
Ce este un model al procesului software?
Este o reprezentare simplificat a unui proces
software, prezentat dintr-o perspectiv specific.
Exemple de perspective prin care putem privi un
process
Perspectiv Workflow secven de activiti;
Perspectiv Data-flow fluxul informaiei (de date);
Perspectiv Rol/aciune cine ce face.
Modele generic de proces
Waterfall (cascad);
Dezvoltare iterativ;
Dezvoltare bazat pe componente.
Care sunt costurile n ingineria software?
Aproximativ 60% din costuri sunt costuri de
dezvoltare, iar 40% sunt costuri de testare. Dar
pentru software dezvoltat pentru un client
particular, costurile de evoluie de cele mai multe
ori depesc costurile de dezvoltare.
Costurile variaz n funcie de tipul sistemului
dezvoltat i n funcie de cerinele sistemului mai
ales cele de performan i fiabilitate.
Distribuia costurilor depinde mult de modelul de
dezvoltare folosit.

Distribuia costurilor pe activitate
Wa t e rfa ll m o d e l
0 25 50 75 1 00
Spe c ific a tio n De sig n De v e lo pm e nt Inte g ra tio n a nd te sting
It e ra tiv e d e v e lo pm e nt
0 25 50 75 1 00
Spe c ific a tio n Ite ra tiv e d e v e lo pm e nt Sy ste m te sting
Co m po ne nt-b a se d so ftw a re e ng ine e ring
0 25 50 75 1 00
Spe c ific a tio n De v e lo pm e nt Inte g ra tio n a nd te sting
De v e lo pm e nt a nd e v o lutio n c o sts fo r lo ng -life tim e sy st em s

0 10 200 30 400
Sy ste m de v e lo pm e nt Sy ste m e v o lutio n

Costurile de dezvoltare a unui produs
0 25 50 75 1 00
Spe c ific a tio n De v e lo pm e nt Sy ste m te sting

Ce sunt metodele ingineriei software?
Sunt abordri structurate ale dezvoltrii software care

includ modele de sistem, notaii, reguli, sfaturi de
proiectare i ghid de proces.
Diagrame de model
Descrieri grafice ale modelului de sistem;
Reguli
Constrngeri aplicate modelelor de sistem;

Recomandri
Sfaturi de bun proiectare;

Ghid de proces
Ce activiti ar trebui efectuate.

Ce este CASE (Computer-Aided Software
Engineering)
Sunt sisteme software care ofer suport pentru

activitile proceselor software.
Sistemele CASE sunt deseori folosite pentru a
realiza o metodologie de dezvoltare.
Upper-CASE
Aplicaii care vin n ajutorul activitilor de nceput ale
procesului de dezvoltare cum ar fi specificarea
cerinelor, analiz i proiectare;
Lower-CASE
Aplicaii care ajut activiti ulterioare cum ar fi
programare, depanare i testare.

Care sunt atributele unui software de
calitate?
Un software de calitate trebuie s ofere funcionalitatea i

performana cerut de client i s fie mentenabil, fiabil i
acceptat de client.
Mentenabilitate
Software-ul trebuie s evolueze pentru a fi n pas cu schimbrile;
Fiabilitate
Software-ul trebuie s fie de ncredere;
Eficien
Software-ul nu trebuie s abuzeze de resursele sistemului;
Acceptan
Software-ul trebuie s fie acceptat de utilizatorii pentru care a fost
proiectat. Acest lucru nseamn c trebuie s fie uor de neles,
utilizabil i compatibil cu alte sisteme.

Care sunt provocrile eseniale ale
ingineriei software?
Eterogenitate, promptitudine i ncredere.
Eterogenitate
Tehnicile de dezvoltare software trebuie s fac fa
platformelor i mediilor de execuie eterogene;

Promptitudine
Tehnicile de dezvoltare trebuie s duc la o mai
rapid dezvoltare a programelor;

ncredere
Tehnicile de dezvoltare trebuie s demonstreze c
utilizatorii pot folosi cu ncredere produsul software.

Responsabiliti profesionale i etice
Ingineria software implic mai multe

responsabiliti dect punerea n practic a unor
aptitudini tehnice.
Inginerii software trebuie s aib un
comportament onest i etic dac vor s fie
respectai ca profesioniti.
Comportamentul etic nseamn mai mult dect a
respecta legea.

Elemente de responsabilitate profesional
Confidenialitate
Trebuie respectat confidenialitatea angajailor i a
clienilor indiferent dac a fost semnat sau nu un
contract de confidenialitate.
Competen
Nu trebuie prezentat greit nivelul de competen.
Nu trebuie acceptat o lucrare care depete
nivelul de competen.

Elemente de responsabilitate profesional
Proprietatea intelectual
Trebuie avute n vedere legile locale legate de
patente, copyright, etc. Trebuie de asemnea luate
msuri pentru protejarea proprietilor intelectuale
ale angajailor i clienilor.
ntrebuinare iresponsabil a calculatorului
Aptitudinile de lucru cu calculatorul nu trebuie
folosite iresponsabil asupra calculatoarelor altor
persoane. Folosirea iresponsabil variaz de la
lucruri relativ triviale (jucarea unor jocuri pe
calculatoarele clientului) pn la lucruri extrem de
serioase (virusarea calculatoarelor).

Concluzii
Ingineria software este o disciplin de inginerine ce se ocup
cu toate aspecte de producie software.
Produsele software constau din programele dezvoltate i
documentaia corespunztoare. Atributele esentiale ale
produselor software sunt maintainabilitatea, fiabilitatea,
eficiena i utilitatea.
Procesul software const din activitile implicate n
dezvoltarea produselor software. Activitile de baz sunt
specificarea software, dezvoltarea, validarea i evoluia.
Metodele sunt moduri organizate de producie software. Ele
includ sugestii pentru procesul ce trebuie urmat, notaii
folosite, reguli ce guverneaz descrierile sistemului ce este
produs i sfaturi de proiectare.

Concluzii
Aplicaiile CASE sunt sisteme software
proiectate s ajute activitile de rutin din
procesul de dezvoltare software, cum ar fi
editarea diagramelor, verificarea consistenei lor
i evidena testelor rulate.
Inginerii software au responsabiliti profesionale
i sociale care depesc elementele tehnice.

Cerine Software

Obiective

De a introduce conceptele de cerine
utilizator i cerine sistem

De a descrie cerinele funcionale i ne-
funcionale
De a explica cum pot fi organizate
cerinele sotfware ntr-un document de
cerine

Cuprins

Cerine funcionale i ne-funcionale

Cerine utilizator
Cerine de sistem
Documentul de cerine software

Ingineria cerinelor

Este procesul de stabilire a serviciilor pe
care le dorete clientul de la sistem i
constrngerile de operare i dezvoltare.
Cerinele sunt descrieri ale serviciilor
sistemului.

Ce este o cerin?
Poate varia de la o fraz abstract care descrie
un serviciu sau o constrngere de sistem pn la
o specificare matematic detaliat.

Aceast situaie este inevitabil deoarece ele au
dou funcii
Pot sta la baza unei licitaii deci trebuie s fie uor
de interpretat;
Pot sta la baza unui contract deci trebuie definite n
detaliu;
Ambele descrieri sunt numite cerine.

Abstractizarea cerinelor (Davis)
Dac o companie dorete s i

defineasc cerin ele ntr-un mo
Cerinele trebuie scrise astfel
probabil diferite moduri de a n
fost ctigat, contractorul trebu
Tipuri de cerine
Cerine utilizator
Sunt fraze n limbaj natural plus diagrame ale
serviciilor pe care le ofer sistemul i constrngeri
de operare. Ele sunt scrise de clieni.
Cerine de sistem
Sunt structurate ntr-un document cu descrieri
detaliate ale funciilor sistemului, servicii i
constrngeri de operare. Definete ceea ce va fi
implementat, deci poate fi parte dintr-un contract.

Definiii i specificaii
Definiie de cerin utilizator
1. Programul trebuie s ofere mijloace de reprezentare i accesare a

1. fiierelor externe create de alte instrumente
Specificaie de cerin sistem
1.1 Utilizatorul trebuie s aib mijloace de a defini tipul fiierelor externe

2
1.2 Fiecare tip de fiier exterior poate avea un instrument asociat cu care
1.2 poate fi deschis acel
. fiier
1.3 Fiecare tip de fiier exterior poate fi reprezentat cu un icon specific
1.2 pe ecran
1.4 Trebuie oferite mijloace ca pozele ce reprezint tipurile de fiiere
1.2 externe s poat fi definite de utilizator
1.5 Cnd utilizatorul selecteaz o poz ce reprezint un fiier, efectul
1.2 seleciei este aplicarea instrumentului asociat acelui tip de fiier
1.2asupra fiierului selectat

Cine citete cerinele?
Manageri ai clientului
Utilizatori finali de sistem
Cerine
Ingineri ai clientului
utilizator
Manageri de dezvoltare
Arhiteci de sistem
Utilizatori finali de sistem

Cerine Ingineri ai clientului
sistem Arhiteci de sistem
Dezvoltatori software
Ingineri ai clientului (posibil)

Specificaii de
Arhiteci de sistem
proiectare
Dezvoltatori software

Cerine funcionale i ne-funcionale
Cerine funcionale
Descrieri ale serviciilor pe care trebuie s le ofere sistemul,
cum trebuie s reacioneze i s se comporte sistemul n
situaii particulare.
Cerine ne-funcionale
Constrngeri asupra serviciilor sau funciilor oferite de
sistem cum ar fi constrngeri de timp, constrngeri ale
procesului de dezvoltare, standarde, etc.
Cerine specifice domeniului problemei
Cerine ce provin din mediul de utilizare a sistemului.

Cerine funcionale

Descriu funcionalitatea sau serviciile
sistemului.

Depind de tipul de software i de tipul de
utilizatori ce vor folosi sistemul.
Cerinele funcionale pot fi fraze abstracte
de descriu ceea ce face sistemul, dar ele
pot descrie sistemul n detaliu.

Sistemul LIBSYS (exemplu)

Este un sistem tip bibliotec ce ofer o
interfa unic la un numr de baze de
date cu articole din diferite biblioteci.
Utilizatorii pot cuta, aduce i tipri aceste
articole pentru studiu personal.

Exemple de cerine funcionale
Utilizatorul trebuie s poat cuta articole n
toate bazele de date sau ntr-un subset selectat.
Sistemul trebuie s ofere instrumente de
vizualizare potrivite pentru citirea articolelor.

Fiecare comand trebuie s aib alocat un
identificator unic (ORDER_ID).

Imprecizii ale cerinelor
Problemele apar atunci cnd cerinele nu sunt
enunate precis.
Cerinele ambigue pot fi interpretate diferit de
utilizatori i dezvoltatori.
De exemplu termenul instrumente de vizualizare
potrivite
Intenia utilizatorului instrumente de vizualizare
speciale pentru fiecare tip de document;
Interpretarea dezvoltatorului oferirea unui editor de
text care s prezinte coninutul documentului.

Completitudinea i consistena cerinelor
n principiu, cerinele trebuie s fie complete i
consistente.
Complete
Trebuie s includ descrieri ale tuturor
facilitilor.
Consistente
Nu trebuie s existe conflicte sau contradicii
n descrierea facilitilor sistemului.
n practic, este imposibil realizarea unui
document de cerine complete i consistente.

Cerine ne-funcionale
Acestea definesc proprietile i constrngerile sistemului
cum ar fi fiabilitate, timp de rspuns i cerine de stocare.
Constrngerile sunt proprieti ale componentelor de
stocare de date, reprezentri ale sistemului, etc.

Pot fi specificate cerine de proces care impun un anumit
sistem CASE, un limbaj de programare sau o metod de
dezvoltare.

Cerinele ne-funcionale pot fi mai critice dect cele
funcionale. Dac primele nu sunt ndeplinite, sistemul
este inutilizabil.

Clasificarea cerinelor ne-funcionale

Cerine de produs
Sunt cerine care specific lucruri pe care produsul trebuie s le
ndeplineasc legat de viteza de execuie, fiabilitate, etc.

Cerine de organizare
Cerine care sunt consecine ale politicii i procedurilor
organizaiei cum ar fi standarde de proces folosite, cerine de
implementare, etc.

Cerine externe
Cerine care provin din factori externi sistemului i procesului
de dezvoltare cum ar fi cerine de interoperabilitate, cerine
legislative, etc.

Tipuri de cerine ne-funcionale
No n -fu n c tio n al
re q u ir e m e n ts
Pro d u c t Org an is atio n al Ex te rn al

r e q u ir e m e n ts re q u ir e m e n ts r e q u ir e m e n ts
Effic ie n c y Re lia b ility Po rta b ility In te r o p e r a b ility Eth ic al

re q u ir e m e n ts r e q u ir e m e n ts re q u ir e m e n ts re q u ir e m e n ts r e q u ir e m e n ts
Us a b ility De li ve ry Im p le m e n ta tio n Stan d ar d s Le g islativ e

r e q u ir e m e n ts re q u ir e m e n ts re q u ir e m e n ts re q u ir e m e n ts re q u ir e m e n ts
Pe r fo r m an ce Sp ace Pri vac y Safe ty

re q u ir e m e n ts r e q u ir e m e n ts r e q u ir e m e n ts re q u ir e m e n ts

Exemple de cerine ne-funcionale
Cerine de produs
8.1 Interfaa cu utilizatorul pentru sistemul LIBSYS
trebuie s fie implementat ca pagini HTML simple fr
cadre (frames) sau Java applets.
Cerine de organizare
9.3.2 Procesul de dezvoltare i documentele rezultate se
vor conforma celor definite n XYZCo-SP-STAN-95.
Cerine externe
7.6.5 Sistemul nu trebuie s ofere alte informaii personale
legate de clieni n afar de numele lor.

Cerine i scopuri
Cerinele ne-funcionale pot fi foarte greu de exprimat ntr-
un mod precis, iar cerinele imprecise pot fi greu verificate.
Scop
O intenie general a utilizatorului, cum ar fi uurina n utilizare.
Cerin ne-funcional verificabil
O cerin ce folosete un sistem de msur pentru a putea fi
obiectiv testat.
Scopurile sunt utile dezvoltatorilor n msura n care
cuprind inteniile utilizatorilor de sistem.

Exemple
Un scop al sistemului
Sistemul trebuie s fie uor de utilizat de operatori
experimentai i trebuie organizat astfel nct erorile de
utilizare s fie minimizate.
O cerin ne-funcional verificabil
Operatorii experimentai trebuie s poat folosi
funcionalitatea sistemului dup un total de dou ore
de nvare. Dup aceast perioad numrul mediu al
erorilor fcute de operatorii experimentai nu trebuie s
depeasc dou pe zi.

Uniti de msur pentru cerine
Proprietate Unitate
Viteza Tranzac
Timp de
Timp de
Dimensiune M Bytes
Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6
Numr d
Slide 22
Interaciunea cerinelor
Conflictele dintre diferite cerine ne-funcionale
sunt un lucru obinuit n sistemele complexe.
Sistem folosit n navete spaiale
Pentru a minimiza greutatea, numrul de cipuri
separate din sistem trebuie minimizat.
Pentru a minimiza consumul de putere, trebuie
folosite cipuri cu consum redus.
Totui, folosirea cipurilor cu consum redus poate
nsemna c vor fi folosite mai multe cipuri. Care
cerin este mai important (mai critic)?

Cerine din domeniul aplicaiei
Descriu caracteristici ale sistemului i faciliti
care reflect domeniul specific de lucru al
aplicaiei.
Ele pot fi cerine funcionale, constrngeri asupra
altor cerine sau pot defini calcule specifice.
Dac aceste cerine nu sunt ndeplinite, sistemul
poate fi inutilizabil.

Cerine din domeniul aplicaiei LIBSYS
Trebuie s existe o interfa utilizator standard
pentru toate bazele de date, interfa bazat pe
standardul Z39.50.
Datorit restriciilor de copyright, unele documente
trebuie terse imediat dup ce au fost aduse. n
funcie de cerinele utilizatorului, aceste documente
pot fi doar printate local sau pe o imprimant de
reea.

Probleme ale cerinelor din domeniul aplicaiei
nelegerea cerinelor
Cerinele sunt exprimate ntr-un limbaj specific
domeniului aplicaiei;
Acest limbaj nu este ntotdeauna neles de inginerii
software ce dezvolt sistemul.
Cerine implicite
Specialitii domeniului neleg domeniul att de bine
nct nu se gndesc c este nevoie s exprime
explicit aceste cerine.

Cerine utilizator
Trebuie s descrie cerine funcionale sau ne-
funcionale ntr-un mod care s fie neles de
ctre utilizatorii sistemului care nu au cunotine
tehnice de detaliu.
Cerinele utilizator sunt definite folosind limbajul
natural, tabele i diagrame, n msura n care pot
fi nelese de ctre toi utilizatorii.

Probleme legate de exprimarea n limbaj natural
Lipsa de claritate
Este greu s obii precizie fr s faci documentul
dificil de citit.
Confuzia cerinelor
Cerinele funcionale i cele ne-funcionale tind s fie
amestecate.
Amalgamarea cerinelor
Diferite cerine pot fi exprimate mpreun.

Cerine utilizator LIBSYS
4..5 Sistemul LIBSYS trebuie s ofere un sistem de

contabilitate care s in nregistrri ale tuturor plilor
fcute de utilizatorii sistemului. Managerii sistemului pot
configura acest sistem de contabilitate astfel nct
utilizatorii frecveni s poat beneficia de reduceri.

Probleme ale cerinelor
Cerinele includ att informaie
conceptual ct i de detaliu

Cerinele amestec tipuri diferite de cerine

Sfaturi pentru scrierea cerinelor
Inventeaz un format standard i folosete-l
pentru toate cerinele.

Folosete limbajul ntr-un mod consistent.
Folosete trebuie pentru cerinele obligatorii i
ar trebui pentru cerinele de dorit.
Scoate n eviden prile cheie ale cerinelor.

Evit folosirea jargonului informatic.

Cerine de sistem
Sunt specificaii mai detaliate ale funcionalitii
sistemului, ale serviciilor sau constrngerilor.

Ele vor fi baza pentru proiectarea sistemului.
Pot fi ncorporate ntr-un contract.
Cerinele de sistem pot fi definite sau ilustrate
folosind diferite modele de sistem.

Cerinele i proiectarea
n principiu, cerinele trebuie s exprime ceea ce
va face sistemul, iar proiectarea trebuie s
descrie cum va face sistemul aceste lucruri.

n practic, cerinele i proiectarea sunt
inseparabile
O arhitectur de sistem poate fi proiectat pentru a
structura cerinele;
Sistemul poate interopera cu alte sisteme care
genereaz cerine de proiectare;
Folosirea unei proiectri specifice poate fi o cerin
din domeniul aplicaiei.

Probleme ale specificrii n limbaj natural
Ambiguitate
Cititorii i scriitorii de cerine trebuie s interpreteze
aceleai cuvinte n acelai fel. Limbajul natural este
ambiguu, ceea ce face lucrurile dificile.
Flexibilitate prea mare
Acelai lucru poate fi spus n mai multe feluri n
specifiaie.
Lipsa modularizrii
Structurile limbajului natural nu sunt adecvate pentru
a structura cerinele de sistem.

Alternative la specificaii n limbaj natural
Nota ie Descriere
Limbaj natural Aceast aborda
structurat cerinelor.
Limbaje de Aceast aborda
descriere a cu faciliti ma
Specificaii n limbaj structurat
Libertatea scriitorului de cerine este limitat de
un ablon predefinit pentru cerine.

Toate cerinele sunt scrise ntr-o manier
standard.
Terminologia folosit n descrieri poate fi limitat.

Avantajul este c se menine expresivitatea
limbajului natural, dar este impus un grad de
uniformizare a specificaiilor.

abloane de specificaii
Definirea funciei sau a entitii.

Descrierea intrrilor i a provenienei lor.
Descrierea ieirilor i a destinaiei lor.
Indicarea altor entiti necesare.

Pre i post condiii (dac este necesar).
Efecte secundare (laterale) ale funciei.

abloane de specificaii
Insulin Pump/Control Software/SRS/3.
Funcie Calculeaz doza de in

Descriere Calculeaz doza de in
zona de siguran nt
Intrri Citirea nivelul curent
Modele grafice
Modelele grafice sunt foarte utile cnd trebuie s
ari cum se schimb starea sistemului sau cnd
trebuie specificate secvene de aciuni.

Diagrame de secven
Arat secvena evenimentelor care apar n timpul
unei interaciuni a utilizatorului cu sistemul.

Se citesc de sus n jos pentru a nelege ordinea
n care apar aciunile.
Scoaterea banilor dintr-un ATM
Validarea cardului;
Prelucrarea cerinei;
Completarea tranzaciei.

Diagram de secven pentru scoaterea
banilor dintr-un ATM
ATM Database
Card
Card number
Card OK
PIN request
PIN
Option menu Validate card
<<exception>>
invalid card
Withdraw request Balance request

Balance
Amount request
Handle request
Amount
Debit (amount)
<<exception>> Debit response

insufficient cash
Card
Card removed
Complete
Cash transaction
Cash removed
Receipt

Documentul de cerine
Documentul de cerine este exprimarea oficial a
ceea ce se cere de la dezvoltatorii sistemului.

Trebuie s includ att definiii ale cerinelor
utilizator ct i specificaii ale cerinelor de
sistem.
NU este un document de proiectare. Pe ct este
posibil, trebuie s exprime CE trebuie s fac
sistemul i nu CUM trebuie s fac

Utilizatorii documentului de cerine
Specify the requirements and
System read them to check that they
customers meet their needs. They
specify changes to the
requirements
Use the requirements

Managers document to plan a bid for
the system and to plan the
system development process
System Use the requirements to

engineers understand what system is to
be developed
System test Use the requirements to

engineers develop validation tests for
the system
System Use the requirements to help

maintenance understand the system and
engineers the relationships between its
parts

Standardul IEEE pentru cerine
Definete o structur generic pentru
documentul de cerine ce trebuie creat pentru un
sistem specific.
Introducere.
Descriere general.
Cerine specifice.
Apendice.
Index.

Structur propus pentru documentul de cerine
Prefa
Introducere
Glosar

Definirea cerinelor utilizator

Arhitectura sistemului

Specificarea cerinelor de sistem

Modele de sistem
Evoluia sistemului
Apendice
Index

Concluzii
Cerinele exprim ceea ce trebuie s fac sistemul i
definete constrngerile asupra operrii sau
implementrii.

Cerinele funcionale exprim serviciile pe care le va oferi
sistemul.

Cerinele ne-funcionale constrng sistemul sau procesul
de dezvoltare.
Cerinele utilizator sunt exprimri de nivel nalt a ceea ce
trebuie s fac sistemul. Cerinele utilizator trebuie scrise
n limbaj natural, eventual folosind tabele i diagrame.

Concluzii

Cerinele de sistem trebuie s descrie funciile
oferite de sistem.
Un document de cerine software este o
exprimare oficial a cerinelor sistemului.

Standardul IEEE este un punct de start pentru
definirea unor standarde mai detaliate de
specificare a cerinelor.

CAPITOLUL 2
FIABILITATEA PRODUSELOR SOFTWARE.
2.1 Rolul standardelor n asigurarea calitii i fiabilitii software

Domeniul calitii software-ului a fost pus n discuie pentru prima dat ntr-o conferin
internaional organizat de N.A.T.O., n anul 1968, cnd s-au analizat coninutul i semnificaia
domeniului cunoscut actualmente sub denumirea de ingineria software-ului (software engineering).
Simpozioanele i conferinele internaionale ce au avut loc dup 1968, avnd ca tematic
calitatea software-ului, ca i cercetrile i experimentrile fcute, au relevat complexitatea acestui
domeniu, precum i multitudinea de probleme care apar legat de specificarea, realizarea,
msurarea i evaluarea calitii software-ului pe ntregul ciclu de via (asigurarea calitii
software).
ISO (Organizaia Internaional de Standardizare) i IEC (Comisia Electrotehnic Internaional)
alctuiesc sistemul specializat n ceea ce privete standardizarea internaional.
Organismele naionale care sunt membre ale ISO sau IEC, iau parte la elaborarea
standardelor internaionale prin intermediul comitetelor tehnice desemnate de organizaia respectiv,
n scopul abordrii unor domenii specifice ale activitii tehnice.
Alte organizaii internaionale, guvernamentale i neguvernamentale, n colaborare cu ISO i
IEC, iau parte, de asemenea, la activitatea aceasta.
n domeniul tehnologiei informaiei ISO i IEC au creat un comitet tehnic comun,
ISO/IEC JTC1.
Proiectele Standardelor Internaionale care sunt adoptate de acest comitet tehnic comun sunt
trimise organismelor naionale care, n urma studiului efectuat, i exprim votul vizavi de un anumit
proiect de standard.
Adoptarea i publicarea ca standard internaional impun adeziunea a unui procent de minim
75% din numrul organismelor naionale care i-au exprimat votul.
Pe msur ce numrul i importana aplicaiilor software au crescut, de asemenea a crescut
i cerina de calitate pe care trebuie s o aib n vedere orice organizaie (firm) care
dezvolt i comercializeaz produse software, ea reprezentnd adevrata carte de vizit a respectivei
instituii, a crei transparen, recunoatere i certificare permit competitivitatea i prosperitatea
ei .
Pe plan mondial, cercetrile i realizrile viznd calitatea software sunt naintate, att
n mediul universitar ct i cel industrial. Ele au fost dinamizate datorit sporirii concurenei
internaionale, schimbrilor profunde n tehnologia de elaborare a software-ului, cerinelor
noi i complexe ale clienilor i de aderena la standarde (de ex.: ISO 9126).
Companii mari, care vnd produse din ramura tehnologiei informaiei, cum ar fi: Microsoft,
IBM, Hewlett-Packard, Verilog-Frana, Datamat-Italia i-au elaborat strategii pe termen lung pentru
conducerea calitii globale, avnd un rol primordial activitile manageriale i de msurare a calitii
software-ului pe ntreg ciclul de via.
Totui, rezultatele obinute de acestea nu sunt generalizate i utilizate pe scar larg, fie
datorit faptului c unele firme nu-i fac publice strategiile proprii de obinere i monitorizare a
calitii produselor software livrate, fie graie costurilor financiare mari care au fcut ca numai
organizaiile mari, care au resurse bneti substaniale, s beneficieze de implementarea lor n scopul
meninerii competitivitii i a asigurrii unui avantaj pe piaa concurenial de produse i servicii din
ramura tehnologiei informaiei.
Pe plan intern, calitatea software (sau caracteristici ale asigurrii ei) a fost studiat de
specialiti din centre de cercetare (ICI), mediile universitare (ATM, UPB, ASE), ct i de
organizaii industriale.
1
S-a acordat o atenie deosebit terminologiei i aspectelor de ordin conceptual din domeniul
calitii software, prelundu-se i adaptndu-se rezultate ale firmelor de prestigiu n domeniu,
publicate n reviste i cri de specialitate.
Rezultatele cercetrilor i experimentrilor ntreprinse n mediul universitar i
industrial au fost concretizate prin publicarea a peste 40 de lucrri de specialitate, n
perioada 1982-1994 .
O atenie aparte a fost acordat fiabilitii software-ului, studii i experimentri fiind
ntreprinse n cadrul ICI i instituiilor de nvmnt superior (ASE, UPB, ATM), drept urmare se
poate aprecia c s-a format un grup de specialiti care posed cunotine tehnice i care au acumulat
experien n domeniu pe baza experimentelor i studiilor de caz ntreprinse.
Nu se pot spune prea multe lucruri pozitive n ceea ce privete societile care se ocup
cu realizarea i comercializarea produselor din domeniul tehnologiei informaiei, unde
activitile de conducere i asigurare a calitii software-ului sunt foarte slab exprimate.
Cercetrile din domeniul ingineriei software-ului abordeaz implicit i explicit
domeniul calitii software-ului.
Tratarea implicit a calitii se refer la metode, tehnici i instrumente de realizare (analiz,
proiectare, programare) care s aib ca obiectiv final obinerea de software cu un nivel mare de
calitate.
elul specialitilor este de a elabora i implementa tehnologii pentru asigurarea i
mbuntirea calitii software.
Abordarea explicit vizeaz cercetarea direct (nemijlocit) a calitii, avnd ca obiective
principale:
definirea terminologiei i a noiunilor principale ale calitii software-ului;

stabilirea i clasificarea caracteristicilor de calitate;
construirea metodelor de specificare, msurare, estimare i evaluare a calitii
software-ului;
elaborarea listei de indicatori ai calitii software-ului.
Importana standardelor ce descriu calitatea (de ex. seria de standarde ISO 9000) rezult din
faptul c standardele ISO au fost preluate de un numr mare de organisme de standardizare naionale
i regionale.
Unele organizaii de standardizare folosesc standardele ISO fr a le modifica, altele au
introdus sisteme proprii de numerotare, textul fiind acelai cu cel al standardelor ISO.
Sunt multe organizaii care produc standarde n SUA i alte ri.
n industria de aprare avem de-a face cu standardele DOD (Departament of Defence) care
se folosesc de muli ani. O serie de standarde ale departamentului de aprare au fost preluate i
adoptate n sectorul comercial al produciei de organizaii precum IEEE (Institute for Electrical on
Engineers), ASTM (The American Society for Testing and Materials), UL (Underwriters
Laboratories) i SAE (Society for Automative Engineers).
n ceea ce privete fiabilitatea, ca una dintre principalele caracteristici de calitate
software, ea a fost abordat indirect, prin standardele de asigurare a calitii software n
ansamblu (ISO 9000, ISO 9126, i altele) sau direct, prin standarde care vizau problematica
definirii terminologiei, msurrii i evalurii fiabilitii software pe ntreg ciclul de via,
standarde publicate att de ISO/IEC, ct i de alte organisme i organizaii internaionale.
Mai jos se propune o list cu unele dintre standardele de fiabilitate (plus alte standarde la care
se fac referine) cunoscute i existente pe plan mondial, dar i n ara noastr i pe care autorul le-a
putut consulta prin intermediul IRS (Institutul Romn de Standarde):
Titlu
Nume standard
ANSI/IEEE std. 729-1983[XXXX83] IEEE Standard Glossary of Software
Engineering Terminology.
2
ANSI/IEEE std. 730-1984[XXXX84] IEEE Standard for Software Quality
Assurance Plans.
ANSI/IEEE std. 1012-1986[XXXX86] IEEE Standard for Software
Verification and Validation Plans.
ISO 8402-1994[XXXa94] Management and Assurance of quality -
vocabulary.
Nume standard Titlu

IEEE std. 982.1-1988[XXXa88] IEEE Standard Dictionary of Measures
to Produce Reliable Software.
IEEE std. 982.2-1989[XXXa89] IEEE Guide for the Use of Standard
Dictionary of Measures to Produce
Reliable Software (982.1 - 1988).
DD 198:1991[XXXb91] Guide to Assessment of Reliability of
(standard britanic) Systems Containing Software.
BS 5760:Part 0:1985[XXXa85] Introductory Guide to Reliability.
(standard britanic)
BS 5760:Part 1:1985[XXXb85] Guide to Reliability and Maintainability
(standard britanic) Programme Management.
BS 5760:Part 6:1991[XXXa91] Guides to Programmes for Reliability
(standard britanic, identic cu IEC 1014:1989) Growth.
ISO 8930-1987[XXXa87] General Principles on Reliability for
Structures.
List of Equivalent Terms.
UTE C20-317 U:1990[XXXa90] Programmes de Croisance le Fiabilit.
(standard Frana)
XP X60-500:1988[XXXb88] Terminologie relative la Fiabilit -
(standard Frana) Maintenabilit-Disponibilit.
Creterea continu a importanei acordate fiabilitii software-ului de ctre specialiti se

explic prin elaborarea de noi standarde de fiabilitate (un standard AIAA pentru fiabilitatea software
a fost aprobat n 1993[XXXX93] i alte standarde IEEE sunt sub dezvoltare) i prin crearea unei noi
discipline-Software Reability Engineering (SRE).
Ingineria fiabilitii software se maturizeaz prin extinderea standardelor i prin
promovarea lor.
Creterea comunitii de cercetare n SRE este de aproximativ 35% pe an, fapt ce explic importana
acordat acestei discipline aflat n ascensiune.
2.2 Fiabilitatea, o caracteristic a calitii software-ului

reflectat de standardele internaionale ISO 9000 i ISO 9126
2.2.1 Caracteristicile de calitate software
Convenional, inginerii software au considerat c responsabilitatea lor sunt rezultatele

tehnice ale furnizrii unui produs software care execut nite funcii conform specificaiilor.
Cel mai important lucru este s se obin calitatea prin controlarea metodelor de producere i
nu a produsului nsui.
3
Folosirea tehnicilor noi e posibil s creasc fezabilitatea i s reduc riscurile implicate n
obinerea sigur a calitii dorite.
De exemplu, metodele formale pot duce la realizarea unor nivele nalte de fiabilitate, iar
fixarea de prototipuri poate crete ansa atingerii nivelelor dorite n utilizarea produsului.
La elaborarea produselor software,
factor caracteristicile
(caracteristic) de calitate sunt privite difereniat.
Se poate pune accent la un moment dat pe realizarea la cote superioare a unei anumite
caracteristici de calitate.
Celelalte caracteristici vor avea niveluri influenate direct de caracteristica prioritar,
care trebuie meninut ntre limite care nu afecteaz nivelul global al performanei
produsului.
Programele sunt elaborate astfel nct s rspund cerinelor de prelucrare ale
criteriu criteriu n
beneficiarilor, dar 1 n (subcaracteristic)
acelai timp s. . reflecte
. posibilitile materiale i financiare ale
realizatorului i ale beneficiarilor. Dac la proiectare primeaz o anumit caracteristic, odat
cu trecerea la noi versiuni ale programului, se poate modifica ierarhizarea caracteristicilor n
raport cu criteriul importanei.
Caracteristicile metriciprogram formeaz un sistem complex,
metrici i atributele de calitate ale produselor
dinamic; creterea nivelului unei anumite caracteristici influeneaz pozitiv nivelul altor caracteristici,
dar pot exista i situaii conflictuale.
De Fig.
aceea1. Relaia
trebuie caracteristici-subcaracteristici-metrici
asigurat echilibrul necesar ncadrrii produselor program ntre limitele
admise ale performanei, prin utilizarea tehnicilor de analiz - proiectare - programare adecvate, dup
ce s-au evaluat efectele lor.
2.2.2 Clasificarea caracteristicilor de calitate
Exist mai multe criterii de clasificare a lor:

faza ciclului de via a produsului program n care se pun n eviden
caracteristici:
exist caracteristici de calitate evideniate n etapele de elaborare a produsului, iar alte
caracteristici apar n etapele de efectuare de modificri n structura produsului pentru a-i
asigura meninerea n funciune.
specificitatea produsului program care impune ca o caracteristic s fie
prioritar, iar celelalte caracteristici secundare;
persoana care elaboreaz, utilizeaz sau menine n utilizare produsul software,
care poate evidenia prezena sau absena unei caracteristici de calitate.
Cercetrile specialitilor au condus la elaborarea unei structuri conceptuale a sistemului de
caracteristici cunoscut sub numele de modelul calitii software-ului. Modelul a fost creat pentru
prima dat de Barry Boehm i colaboratorii si de la TRW Systems Group. Ulterior a fost
rafinat i extins de James McCall, P. Richard i G. Walters - modelul a fcut obiectul
standardizrii i este recomandat de ISO prin standardul ISO/IEC 9126-1991.
Componentele calitii de nivel nalt, uzual numite factori de calitate, sunt considerate n
termeni ai componentelor de calitate de nivel sczut, criterii, consistente cu viziunea dezvolttorilor
de sistem al calitii.
Aceast concepie conduce la modelul:
factor de calitate (caracteristic), criteriu de calitate (subcaracteristica) i metrici de
calitate, schematizat n fig. 1.
4
Caracteristicile de calitate reprezint punctul de vedere al utilizatorului i al efului de proiect
asupra calitii, folosind la definirea cerinelor utilizatorului i la stabilirea obiectivelor de calitate
pentru sistemul de programe.
Subcaracteristicile au semnificaie tehnic i sunt relevante pentru personalul de
specialitate (analiti, proiectani, programatori).
Ele faciliteaz comunicarea ntre eful de proiect i personalul de specialitate pentru atingerea
obiectivelor de calitate.
Subcaracteristicile se definesc pentru componentele sistemului de programe i diferitele
forme de reprezentare (cerine, specificaii, cod surs, documentaie de utilizare, .a.) pe
parcursul ciclului de via.
La ultimul nivel se definesc metricile, care permit msurarea subcaracteristicilor i, n
consecin, a caracteristicilor de pe primul nivel.
2.2.3 Relaiile dintre caracteristici
ntre caracteristici exist relaii de subordonare i de dependen ce sunt reflectate n mod

diferit de modelele calitii (ISO 9126, Esprit (recomandat de European organization for Quality),
Boehm, McCall) , aa cum se vede n fig. 2.
Relaii
Ierarhice De influen
Conflictuale Complementare
Fig. 2 Relaiile ntre caracteristici

Relaiile ierarhice de subordonare sunt definite prin structura sistemului de caracteristici i
difer de la un model la altul.
Relaiile de influen de tip conflictual semnific faptul c pe msur ce crete nivelul unei
caracteristici, este de ateptat ca nivelele celeilalte caracteristici s scad.
Relaiile de influen de tip complementar au urmtoarea semnificaie:
- dac nivelul unei caracteristici crete, atunci este de ateptat ca i nivelul celorlalte caracteristici s
creasc. Cunoaterea relaiilor i a interdependenelor ntre caracteristici e necesar n toate fazele de
specificare, determinare i evaluare a calitii sistemelor de programe, n special n faza de stabilire a
obiectivelor de calitate.
n dezvoltarea i utilizarea unui model de calitate pentru un anumit tip de sistem de
programe, e foarte important s se includ caracteristici de calitate ct mai independente.
2.2.4 Modelul calitii software din ISO 9126
Prin modelul ISO 9126 se recomand utilizarea urmtorului set de caracteristici:
5
- funcionalitate, utilizabilitate, fiabilitate, eficien, mentenabilitate i portabilitate, ca
n figura 3:
Subcaracteristici
Caracteristici
ci Funcionalitate
Utilizabilitate
Maturitate
Fiabilitate
Toleran la erori
Eficien Capacitatea de recuperare
Mentenabilitate
Portabilitate
Fig. 3 Modelul ISO/IEC 9126

Mai jos se d o descriere pe scurt a semnificaiei caracteristicilor n modelul ISO/IEC 9126:
Tabelul 1. Caracteristici de calitate n modelul ISO/IEC 9126
Caracteristic Semnificaie
- prezena i adecvana setului de funciuni fa de specificaii;
- atributele produsului sunt legate de obinerea rezultatelor corecte sau
convenite (ex. gradul necesar de precizie al valorilor);
FUNCIONALITATE - posibilitatea de interaciune a produsului cu altele specificate;
- aderarea la standarde, convenii, reglementri i alte prescripii
similare, legate de domeniul de aplicaie;
- posibilitatea produsului de a preveni accesul neautorizat, accidental
sau deliberat, la programe sau date.
- gradul de maturitate al produsului, respectiv frecvena cderilor din
cauza erorilor produsului software;
FIABILITATE - capacitatea produsului de a-i menine un anumit nivel specificat de
performan n caz de eroare;
- posibilitatea restabilirii nivelului de performan i refacerea datelor
n cazul unei erori; timpul i efortul necesar pentru aceasta.
- uurina n nelegere, efortul utilizatorului de a recunoate conceptul
UTILIZABILITATE logic i aplicabilitatea lui;
- uurina n operare;
- uurina n nvarea aplicrii produsului.
- comportamentul n timp, eficiena ca timp de rspuns - pe tipuri
PERFORMANE diverse de prelucrri, ratele de transfer sub condiii diferite de
ncrcare i configuraii diferite;
- comportamentul resurselor, respectiv consumul de memorie intern i
extern n diferite condiii.
- rapiditatea i exactitatea cu care se poate identifica o eroare n
MENTENABILITATE execuie din mesajele produsului i cauzele acesteia;
- existena n documentaie a procedurilor i facilitilor de ntreinere a
produsului.
- posibilitatea de adaptare la alte medii specifice, fr a apela faciliti
PORTABILITATE din afara produsului;
- posibilitatea de instalare a produsului ntr-un mediu specificat;
- gradul de aderare a produsului la standardele i reglementrile legate
de portabilitate.
6
Conform acestui standard, fiabilitatea e definit ca fiind capacitatea software-ului de a
menine nivelul su de performan n condiii stabilite pentru o perioad dat de timp.
Uzura sau mbtrnirea nu apare n software. Limitrile fiabilitii sunt generate de
erorile n cerine, proiectare i implementare. ntreruperile care apar din cauza acestor erori
depind de modul cum e utilizat produsul software (profilul operaional) i de opiunile
selectate n program, mai degrab dect de trecerea timpului.
n definiia ISO 8402, fiabilitatea reprezint
Aptitudinea unui produs de a ndeplini o funcie cerut....... n acest standard,
funcionalitatea este numai una din caracteristicile calitii software-ului. Ca urmare, definiia
fiabilitii a fost extrapolat la meninerea nivelului su de performan n loc de
executarea unei funcii cerute.
n ceea ce privete subcaracteristicile, se poate aprecia c nivelul lor este mai detaliat. Vom
exemplifica aici doar subcaracteristicile specifice fiabilitii, cele aparinnd celorlalte caracteristici
putndu-se afla prin consultarea standardului (se pot deduce i din semnificaia dat caracteristicilor
n tabelul 1). Ele sunt:
maturitatea - atribute ale software-ului ce vizeaz frecvena ntreruperilor datorate
erorilor software;
tolerana la defectri - aptitudinea software de a menine un nivel specificat de
funcionare n cazul apariiei erorilor sau al violrii interfeei sale;
capacitatea de recuperare - atribute software ce reflect capacitatea de restabilire a
nivelului su de funcionare i de recuperare a datelor afectate direct de apariia unor
erori, precum i timpul i efortul necesare pentru aceasta.
Definiia dat calitii din ISO 8402 exprim punctul de vedere al utilizatorilor, la fel ca i
caracteristicile din acest standard.
Utilizatorii evalueaz software-ul fr a ti aspectele interne de realizare i interaciune
software.
ntrebrile utilizatorilor pot fi de forma:
funciile cerute sunt disponibile n software?
ct de fiabil este software-ul?
ct de eficient este software-ul?
este software-ul uor de utilizat?
care-i dificultatea transferrii software-ului n alt mediu?
Realizatorii sunt responsabili de producerea software-ului care va satisface cerinele de
calitate, fiind interesai att n calitatea produsului intermediar, ct i n cea a produsului final.
Pentru a evalua calitatea produsului intermediar n fiecare faz a ciclului de realizare,
realizatorii trebuie s foloseasc msuri diferite pentru aceleai caracteristici, nefiind universale
pentru toate fazele ciclului de via..
Punctul de vedere al realizatorilor trebuie s exprime i pe cel al celor care ntrein
software-ul.
Administratorul (managerul de proiect) este interesat de calitate pe ansamblu, dect de o
caracteristic anume i de aceea va trebui s fie acordate ponderi caracteristicilor individuale, care s
oglindeasc cerinele comerciale.
Administratorul echilibreaz mbuntirea calitii cu criteriile de administrare, cum
ar fi ntrzierea fa de timpul planificat sau depirea costului, dorind optimizarea calitii n
cadrul limitelor costului, resurselor umane i a timpului prevzut. Ultimul nivel n modelul
calitii, reprezentat de metrici, nu este nc standardizat.
Se las la latitudinea organizaiilor s-i defineasc metrici specifice.
Unii specialiti folosesc alt terminologie pentru perechea caracteristici - subcaracteristici:
- caracteristici - atribute n modelul Boehm;
- factori - subfactori n modelul McCall.
Modelele difer att prin modul de ierarhizare a caracteristicilor i subcaracteristicilor, ct i
prin definiiile utilizate.
2.2.5 Standardele ISO 9000
7
Conceptul de management al calitii totale se axeaz pe lucrrile de pionierat ale lui
Armand Feigenbaum, Dr.Edward Deming, Dr. Joseph Juran i alii.
O lucrare de referin n acest domeniu este Total Quality Control, publicat de A.
Feigenbaum nc din 1951.
Calitatea total s-a aplicat pentru prima oar n Japonia la nceputul anilor 80, dup
publicarea crii Ce e calitatea total a dr. Kaoru Ishikawa. La jumtatea anilor 80,
Departamentul Aprrii S.U.A. a popularizat noiunea de management al calitii totale, extrapolnd
disciplina calitii la toate domeniile economice.
Dup o definiie dat de DOD n 1990, managementul calitii totale e o strategie pentru a
continua mbuntirea performanei la orice nivel i-n toate domeniile de responsabilitate.
Calitatea total reprezint un proces continuu cuprinznd toate aspectele unei organizaii, de
la design ori serviciu pn la producie i utilizarea produsului sau serviciului, necesitnd deplina
nelegere a cerinelor i ateptrilor clienilor i implicnd toi angajaii n aprecierea i mbuntirea
calitii, cu ajutorul unor instrumente i tehnici de mbuntire.
Standardele ISO sunt un punct de start corespunztor pentru o firm care-i propune
managementul calitii totale.
Standardele ISO 9000 descriu un set de standarde internaionale care se ocup cu
designul, producia, livrarea, serviciul i testarea procesului. Ele i propun mbuntirea
procesului de producie a unei firme.
n S.U.A. multe companii folosesc standardele MIL - I- 45208 sau MIL - Q - 9858, chiar i
acelea care nu au contracte cu industria de aprare.
Odat ce un standard al calitii sistemului s-a impus, sunt trei ci uzuale de a verifica
ndeplinirea cerinelor de calitate privind sistemele:
cumprtorul are ncredere n buna credin a furnizorului (productorului);
cumprtorul conduce procesul de verificare la productor;
cumprtorul i alege un verificator care certific calitatea sistemului (audit).
Primele dou metode sunt comune n practicile comerciale. De exemplu, DOD S.U.A.
conduce testele de verificare a calitii sistemelor pentru furnizorii si.
Standardele ISO 9000 au adoptat a treia metod de verificare a calitii.
Descrierea lor pe pri este dat n tabelul 2.
Tabelul 2. Standardele din seria ISO 9000 referitoare la calitate
ISO 8402 : 1994 Managementul calitii i asigurarea calitii - vocabular.

ISO 9000 - 1 : 1994 Managementul calitii i standarde de asigurare a calitii.
Part. 1: Ghid pentru selectare i utilizare.
Part.2: Ghid generic de aplicare a standardelor ISO 9001, 9002 i ISO
9003.
Part. 3: Ghid de aplicare a standardului ISO 9001 la dezvoltarea,
producerea i mentenana software-ului.
ISO 9000 - 4: 1993 Managementul calitii i standarde de asigurare a calitii.
Part. 4: Ghid de management al dependenei.
ISO 9001 : 1994 Calitatea sistemelor - Model pentru asigurarea calitii n proiectare,
dezvoltare, producere, instalare i ntreinere.
ISO 9002 : 1994 Calitatea sistemelor - Model pentru asigurarea calitii n producere,
instalare i ntreinere.
ISO 9003 : 1994 Calitatea sistemelor - Model pentru asigurarea calitii n inspecia
final i testare.
ISO 9004 - 1 : 1994 Managementul calitii i calitatea elementelor sistemului.
Part 1: Ghid.
Part 1: Ghid pentru ntreinere.
8
Part 1: Ghid pentru prelucrarea materialelor.
Part 1: Ghid pentru creterea calitii.
Standardele ISO 9001, 9002 i 9003 prevd cerinele contractuale ntre productor i
beneficiar.
Standardele cu cel mai mare efect n proiectare asupra calitii sunt ISO 9001, ISO 9000-3 i ISO
9000 - 4. Prin aplicarea acestora, productorul poate realiza un sistem de calitate innd seama de
etapele de proiectare, producere i dependen pentru produsele hardware ct i pentru software.
Standardul ISO 9000 - 3 ofer un ghid productorilor de software care aplic standardul
ISO 9001.
n standardul ISO 9000 - 1 se afirm:
Procesul dezvoltrii, producerii i ntreinerii produselor software este diferit de
celelalte tipuri de procese industriale n care nu este nici o diferen n faza de producie.
Software-ul nu se uzeaz i n consecin calitatea activitilor n faza de proiectare are o
importan deosebit n calitatea final a produsului.
2.3 Fiabilitatea software reflectat n standardele britanice i americane
2.3.1 Definiii i terminologie

Conform standardului IEEE (ANSI) 982.2 din 1989[XXXa89], elementele principale n
definirea software sunt: eroarea (error), neregula (fault) i defectarea (failure).
Eroarea este o greeal uman ce are ca rezultat un program incorect. n aceast categorie
se pot include, de exemplu, omiterea sau lipsa interpretrii unei cerine utilizator la redacterea
specificaiei program, precum i interpretarea greit a unei cerine sau omiterea unei cerine n
Persoana
specificaia de design. care face
n urma erorii umane apare neregula (fault
zero sau mai sau bug). Ea este materializarea nemijlocit a
multe erori
erorii umane n software, avnd ca efect necesitatea modificrii unei poriuni de cod.
n vorbirea curent, se folosete denumirea de eroare att pentru eroarea uman (error), ct
i pentru manifestarea ei direct Erori (errors) (fault sau bug). Anomaliile
n program Mediuprodusului cauzate de erori
se numesc defecte (defects). Intrri Operator
Defectarea sauPotcderea
fi (failure) e evidenierea defectului, cnd o unitate funcional a
Pot genera
sistemului (ce include atribuite
i hardware-ul comandat) 0 saunu-i
mai mai ndeplinete funcia n limite specificate.
uneia sau
Cderea (failure) apare
mai multor
cnd un anumit set
multe de date de intrare activeaz defectul existent n
software.
Erorile umane, neregulileNereguli(faults)
(faults) i defectele (defects) din software sunt cauzele
evenimentelor nedorite, iar defectrile (cderile = failures) sunt efectele.
Figura 4 reprezint schematic aceste noiuni, precum Mecanismul dezvluirii lor, n viziunea
i interaciunile
standardului britanic DD 198/1991[XXXb91] : (punerii n eviden)
Pot fi
atribuite
uneia sau
mai multor
9
Cderi (failures)
Fig. 4. Relaiile dintre termenii de baz n fiabilitatea software: Error, fault, failure.
n continuare se prezint i ali termeni frecvent utilizai de standarde:

O apreciere cantitativ a gradului n care un proces sau produs software
MSUR (metric)
posed un atribut dat.
Dat folosit n dezvoltarea sau utilizarea software pentru
implementarea msurilor sau descrierilor cantitative ale software-ului;
PRIMITIV primitiva e direct msurabil sau numrabil, i poate fi dat printr-o
constant.
Exemplu: nr. de erori, mrimea unui interval de timp, nr. arce, nr.
noduri, nr. de instruciuni executabile .a.
Probabilitatea ca software-ul s funcioneze fr defectare ntr-un timp
specificat, n condiii operaionale date.
Secvena de cod executat depinde de valorile datelor de intrare, ca
FIABILITATE urmare fiabilitatea unui program e o funcie ponderat n mod
SOFTWARE corespunztor cu distribuia datelor de intrare din mediul utilizator.
n DD 198/1991, se utilizeaz i o alt definire :
Abilitatea unui produs software de-a da performan
satisfctoare pe termen lung, fr a se defecta (ca n ISO/IEC
9126).
Procesul optimizrii fiabilitii software printr-un program care pune
MANAGEMENTUL accent pe prevenirea erorilor software, detectarea i ndeprtarea
FIABILITII neregulilor (faults) i folosirea msurtorilor pentru a maximiza
SOFTWARE fiabilitatea, pe fondul constngerilor proiect, cum ar fi costul resurselor,
planificarea i performana.
2.3.2 Construirea fiabilitii software

10
Scopul standardelor de fiabilitate este de-a sprijini dezvoltatorii de software, managerii de
proiect i utilizatorii sistem n atingerea nivelelor de fiabilitate optim n produsele software. Ele vin
n sprijinul celor care dezvolt software i clienilor care sunt confruntai cu o multitudine de modele,
tehnici i msuri, n literatur, dar care nu dau ghidare suficient n utilizarea lor efectiv.
Exist o relaie intim ntre fiabilitatea unui produs i procesele folosite n dezvoltarea
produsului.
Msurile (metricile) selectate va trebui s dea vizibilitate proceselor i produselor astfel nct
factorii eseniali necesari n evaluarea procesului i-a schimbrii acestuia s fie disponibili.
Scopul principal al standardelor este de-a furniza elementele unui program de msurare care
s sprijine o abordare constructiv pentru atingerea fiabilitii optime la sfritul implementrii
produsului; totodat ele asist managementul n dezvoltarea produsului i atingerea unor inte de
fiabilitate.
O abordare constructiv a fiabilitii software caut s elimine cauza generrii
incidentelor sistem (fig. 5) n procesul de dezvoltare software i sprijin procesele care
promoveaz evitarea bugurilor, detectarea timpurie a defectelor, eliminarea adecvat a
acestora i proiectarea unui sistem tolerant la defectri (fig. 6).
Majoritatea cderilor sunt legate de originea lor, care vizeaz:
(1) incompleta definire a necesitilor i cerinelor user;
(2) omisiuni n procesul de proiectare i codificare;
(3) folosirea improprie a sistemului;
(4) schimbri de cod excesive.
Un proces strategic de atingere a fiabilitii software include activiti, metode,
instrumente i msurtori.
Figura ( 7 ) arat acest proces i rolul integrat al msurtorilor pentru a monitoriza
calitatea procesului i a produsului.
Ea reprezint un cumul de concepte, activiti i tehnici cunoscute, care pot fi utilizate pentru
a conduce un proiect n scopul obinerii unei mai bune fiabiliti.
11
FAZA OPERAIONAL
( failures )
FAULTS
REZIDUALE
LIPS DE ... rar,

ROBUSTEE solu ia...
FAULTS
( nereguli )
ERORI
USER ... adesea alte
efecte...
SISTEM FAULTS
DETECTATE
TOLERANT
LA ... pot genera...
... UN
genereaz...
SISTEM UN PRODUS
DEFECTR
ROBUST FIABIL
I ... trebuie s fie
eliminate...
ajut,
protejeaz .. ERRORS cteva (sau 0)
dezastre SCHIMBRI failures
ERORI ( adesea fcute mai
USER trziu )
cteva (sau 0)
... originea... complet pentru o faults
surs a dificultii i
proiectare convergent
...ce trebuie costului mare n
s fie timpul implementrii
extinse.. rar defecte PUINE
secundare DEFECTRI
(faults)
PROIECTARE: PROIECTARE:
INTRRI
REALITI nestructurat;
incomplet; din lumea FAULTS
DETECTATE nemodular;
genereazreal
instabil.
ALE genereaz
VIEII nedocumentat.
PROIECT tergere
ARE: adecvat
PUINE
CUNOATERE SRAC, ORIENTARE ERORI
SCHIMBRI PREMATUR NSPRE
INSUFICIENT,
(fcuteUSER
ct mai ERORI
NEVOILE I CALITATEA TOTAL.
curnd posibile)
d natere
Fig. 5 Cauzele incidentelor (failures) previne
permite
susine implementarea uoar
extensii i controlat
directe
PROCESE
CONSTRUC-
TIVE PROIECTARE: INTRRI PROIECTARE:
stabil; din lumea modular;
PROIECT adaptabil real documentat;
ARE:
CUNOATERE DEPLIN, ORIENTARE

N TIMP PE NECESITILE
12 USER
I CALITATEA TOTAL
ABORDARE CONDUS DE UN MODEL DE
CALITATE
Fig. 6 Constructorii unui produs fiabil
13
Maintenan&Operare
CONCEPT
CERINE
CODIFICARE
TEST
DESIGN
Livrare& Instalare
Retragere
SOFTWARE
CONCEPIE
personal priceput, competent
Do it right the studiul mediului operaional i al necesitilor USER
first time studiul produselor similare
( Prevenire eroare,
reducere apariie scriere specificaii
defect, proiectare
prototipizare rapid
robust i toleran
la defectri ) simulare
Design & Codificare
proiectare structurat top - down

& testare
limbaje design
prototipizare
simulare
metode de minimizare complexitate
DEVELOPMENT
Verificare
Detect it early;
fix it as soon as revederi
practicable inspecii Concepia ideal
( detectare i prototipizare 1. folosii verificarea (activiti,
tehnici, scule)
eliminare rapid
pt. a determina i elimina
defecte ) simulare defectele;
2. folosii validarea (activiti,
probare
Validare
tehnici, scule) pt. a confirma

corectitudine absena defectelor.
Teste dinamice: run
- instalare spec
run
teste spec
- teste sistem spec run
reluare
- teste subsistem spec run
i integrare
- teste unitate (pentru a vedea c
(produs) nu s-a degradat)
PROCES
METRICII
Monitor it"
colecie de date despre primitive, calcule, evaluare
(Ct de corect?)
(Ct de complet ?)
(intrrile pentru metrici sunt furnizate prin activiti de validare

i verificare )
Fig. 7 Strategia "constructiv" de dezvoltare a unui software fiabil
Criteriile care stau la baza acestei concepii constructive (proces) sunt:

14
1. F ceva corect de prima dat:
Se pune accent pe necesitatea studierii intensive a necesitilor stabilite i nestabilite ale
aplicaiei user, precum i pe existena unei experiene suficiente n rezolvarea unei
probleme similare, ceea ce presupune angajarea unui personal priceput i competent n
construirea de produse fiabile.
Implicarea timpurie a beneficiarului n conceperea produsului prin tehnici ca
prototipizarea pentru a se asigura c utilizabilitatea este susinut i de lipsa defectrilor
n funcionare;
Metode moderne, limbaje i instrumente automate trebuie s fie utilizate pentru
promovarea productivitii i calitii n activitile de specificare, design, codificare i
testare.
2. Detectarea timpurie a erorii; fixarea ei ct de curnd posibil.
Detectarea i repararea ar trebui s fie activiti planificate adecvat.
Verificarea e procesul determinrii dac (sau nu) produsul rezultat n urma unei faze a
procesului de dezvoltare software satisface cerinele stabilite n timpul fazei anterioare.
Validarea este procesul evalurii software la sfritul unei faze ( proces ) de dezvoltare
pentru a asigura acordul cu cerinele software.
Detectarea timpurie a defectelor software prin revederi, inspecii, prototipizare, simulare sau
probarea corectitudinii unui produs va mbunti fiabilitatea.
Fiabilitatea nu poate fi obinut numai prin activitatea de testare a unui produs. Mai mult testare
nu nseamn neaprat mai bun fiabilitate. Totui, testele dinamice, metoda principal pentru validare, vor fi
folosite (n limitele unui cost) pentru a da acoperirea testrii unui produs.
3. Monitorizarea erorilor.
Evaluarea msurtorilor e folosit nu numai pentru evaluarea calitii software, ci i pentru
detectarea bugurilor.
De exemplu, dac timpul de procesare e mai mare dect o valoare dat, acesta poate fi un
motiv suficient de respingere a codului implementat i de nlocuire a lui cu altul rescris.
2.3.3 Mediul de msurare

MANAGEMENT PROCES
Msurarea presupune a compara o proprietate a unui obiect cu una similar a unui
standard de referin.
Cnd msurtorile se folosesc pentru diagnosticare, trebuie s existe un mediu propice pentru
SPECIFICAIE
colectarea i analiza datelor, ct i pentru aciunile
DA corective care se fac, toate aceste activiti
DESIGN
tehnice i manageriale desfurndu-se ntr-un flux. ( Figura 8)
Valoarea real - Valoarea ateptat
CODIFICARE (Se trece la
Informaiile folosite pentru msuri mai complexe se numesc primitive. Unele primitive
a) directTESTARE: faza urmtoare
pot deriva din produs (specificaii, cod surs, cod obiect):
- REVEDERI de dezvoltare)
instruciuni;
noduri; - INSPECII
corecie proces i NU
arce;
repetarea lui
ramificri .a.
Alte primitive, rezultate ale activitilor de validare i verificare, includ nr. erori, nr.
defecte (faults)
b i nr. cderi (failures).
Se recomand
)) doi pai n pregtirea coleciei c)
de date:
) (1) Pentru fiecare msur potenial selectat din standarde, se determin ce
date trebuie msurate din lista de primitive;
Pregtire
TOOLS i TOOLS
(2) Datele
de nregistrare
colectate se vor memora ntr-o
nregistrare baz de date, pentru
Msuria(valori)
ine istoricul
de msurare
unui proiect de dezvoltare i-n
automat scopul analizelor.
manual automat
fiier
e
primitive
mnuire,
cunotine,
inteligen
Proces de observare i monitorizare: 15
colectare date
nregistrare date
Fig. 8 Fluxul informaiei de msurare (parte a procesului de dezvoltare)
Beneficiul mare al implementrii unui efort de msurare este priceperea de a evalua

rezultatele coleciei de date, de a dezvolta msuri i a aplica analiza rezultatelor n aprecierea creterii
fiabilitii att a proceselor de dezvoltare, ct i a produsului final.
2.3.4 Criteriile de selecie a metricilor

O abordare constructiv (modern) extinde cercetarea la msuri care promoveaz fiabilitatea
prin minimizarea erorilor reziduale, ca o consecin a prevenirii erorii i a deteciei timpurii a
defectelor urmat de eliminarea acestora. Astfel, standardul 982.1 include msuri produs
pentru a determina ct de atent s-a verificat software-ul (completitudinea i transabilitatea) i
determin complexitatea n scopul studierii posibilitii shimbrii n sistem.
Se vor selecta msuri care s monitorizeze calitatea procesului de dezvoltare i care s
identifice nevoia de a face modificri timpurii n proces.
Msurile proces au scopul de a stimula adoptarea celor mai bune practici ale ingineriei
software n fiecare faz a dezvoltrii proiect, ncurajnd detectarea erorii timpuriu.
O consideraie esenial n selectarea metricilor trebuie s fie aceea ca ele s acopere
tot ciclul de via, adresndu-se att utilizatorilor ct i inginerilor de sistem (software),
oferind un spectru larg n msurarea fiabilitii.
Utilizatorul poate focaliza pe disponibilitatea sistemului i uurina n exploatare, n
timp ce inginerii pot pune accent pe existena defectelor n produsul software.
Alte metrici, cum ar fi complexitatea intereseaz permanent pe manageri i colectivul de
dezvoltare, oferindu-le informaii pentru mbuntirea procesului i controlul costurilor,
planificare, productivitate personal i priceperea profesional.
2.3.5 Organizarea i clasificarea msurrii

16
Msurile vizeaz dou obiective ale fiabilitii:
- aprecierea maturitii produs - o certificare a disponibilitii produsului pentru
operare (incluznd i o estimare a suportului necesar pentru mentenana corectiv);
- aprecierea maturitii procesului - o evaluare a capabilitii factorilor software de-a
produce produse de calitate, conform dorinelor utilizator.
Ciclul de via software poate fi modelat i rafinat ca o secven de subprocese. Fiecare
subproces are intrri i ieiri care ar trebui s satisfac criterii bine definite.
Dac un produs software nu satisface criteriul de ieire stabilit, aceasta ar trebui s
reprezinte un semnal pentru o analiz nentrziat. Fie subprocesul prezint anumite deficiene, fie
criteriul de ieire este prea sever.
Aciunea corectiv se va executa numai dup o analiz suficient (fig. 9).
Ieire Intrare
Intrare Subproces produs produs Subproces Ieire
produs n n+1 ... produs
...
Criteriul de Criteriul de
Criteriul de intrare ieire pentru intrare pentru
pentru subprocesul n subprocesul n subprocesul n + 1
Test ieire Test intrare pentru

Test intrare pentru pentru evaluarea disponibilitatea produsului
disponibilitatea produsului subprocesului n de-a intra n subprocesul n + 1
de-a intra n subprocesul n
Aciune corectiv
pentru subprocesul n
(FEEDBACK)
Fig. 12 Controlul procesului
Msurile aplicate se refer la proces i produs. Msurile produs se vor aplica obiectelor
software rezultate n urma unui proces i se mpart n ase subcategorii:
Erori (errors), defecte (faults) i incidente (failures);
Timpul mediu de defectare; rata de defectare;
Cretere fiabilitate i proiectare fiabilitate;
Defecte rmase n produs (nr. rezidual);
Completitudine i consisten;
Complexitate.
Msurile proces vor fi aplicate activitilor de dezvoltare ale ciclului de via, testrii i
mentenanei software i cuprind trei subcategorii:
Control management;
Acoperire (coverage);
Risc, beneficii i evaluare cost.
n afara acestei clasificri (funcionale), msurile pot fi de asemenea clasificate n funcie de
fazele ciclului de via software n care folosirea lor este corespunztoare.
Fazele ciclului de via clasice se bazeaz pe standardul IEEE 729-1983 (IEEE Standard
Glossary of Software Engineering Terminology i se utilizeaz pentru a ilustra cnd e adecvat
aplicarea fiecrei msuri.
17
Fazele ciclului de via sunt:
Concepia;
Specificare cerine;
Proiectare;
Implementare (codificare);
Testare;
Instalare (la beneficiar);
Operare i mentenan;
Retragere.
2.3.5.1 Clasificarea funcional a msurilor (metricilor)
Matricea de clasificare msuri (metrici) din tabelul 3 este un index al msurilor i categoriilor
funcionale propuse n [XXXa89]. Ea poate fi folosit pentru a selecta msuri aplicabile fiecrei
categorii. Apoi, pentru fiecare categorie, se prezint o matrice care va referi msurile ce se pot folosi
n fiecare faz a ciclului de via software (tabelele 4-12).
n cadrul fiecrei metrici se trece n parantez o cifr {0,1,2,3} i care are urmtoarea
semnificaie:
- 0 msura a fost formalizat dar nu a fost suficient validat n cmpul operaional;
- 1 metrica respectiv s-a folosit de o comunitate software restrns sau nu e suficient de
bine cunoscut;
- 2 metrica s-a utilizat moderat;
- 3 metrica s-a folosit intens.
Aceast cifr furnizeaz msura ncrederii n utilizarea acestei metrici, valoarea ei fiind direct
proporional cu gradul de recomandare a folosirii ei.
Pentru msurile care au n parantez cifra 2 sau 3 se vor da n anexa 1 detalii privind:
implementarea, interpretarea, consideraiile fcute, instruirea necesar, un exemplu i experiena
cerut.
a.) Msuri produs
Sunt ase subcategorii de msuri produs care au impact asupra fiabilitii:
( 1 ) Erori, defecte, incidente (cderi) - contorizeaz defectele lund n consideraie
eroarea uman, bugurile program i funcionrile sistem atipice observate;
( 2 ) MTBF; rata de defectare (cdere) - msuri derivate ale apariiei defect n timp;
( 3 ) Cretere fiabilitate i proiecie - aprecierea schimbrilor fcute ca urmare a
apariiei unui defect ntr-un produs aflat sub testare i n operare (funcionare).
( 4 ) Defecte reziduale - aprecierea apariiei defectelor rmase nedescoperite n
produs n timpul dezvoltrii, testrii sau mentenanei.
( 5 ) Completitudine i consisten - aprecierea prezenei codului tuturor prilor
sistemului software.
( 6 ) Complexitate - aprecierea factorilor dificili ntr-un sistem.
b.) Msuri proces

Exist trei subcategorii de msuri proces referitor la fiabilitate:
( 1 ) Msurile de control management - se refer la cantitatea i distribuia erorii i
defectelor, relevnd costul necesar pentru eliminarea defectelor;
( 2 ) Msurile de acoperire (coverage) - susin aciunile corective pentru a aduce
indicatorii de coverage la nivele dorite;
( 3 ) Evaluare riscuri, beneficii i cost - susin deciziile de livrare soft bazate pe
criterii tehnice i de cost.
Riscul se poate aprecia prin defectele reziduale prezente n produs la livrare i costul asociat
cu eliminarea acestora.
18
19
TABELUL 3
MATRICEA DE CLASIFICARE MSURI (METRICI)
Msuri Produs Msuri Proces

Erori, MTBF Cretere Nr. Completitudine Evaluare,
Nr. fiabilitate Control Acoperire Risc,
crt. Msuri (experien) Defecte, Rate de
&
Rezidual & Complexitate Management (Coverage)
Beneficiu,
Incidente defectare de defecte Consisten
Proiecie Cost
1 2 3 4 5 6 7 8 9 10 11
1 Densitatea defecte (2) X
2 Densitatea de defectare (3) X
3 Profilul de cdere cumulativ (1) X
4 Nr. zile-defecte (0) X X
5 Acoperire testare modular sau funcii (1) X X X
6 Graficul cauz i efect (2) X X
7 Trasabilitate cerine (3) X X X
8 Indici de defectare (1) X X
9 Distribuie eroare (1) X
10 Index de maturitate software (1) X X
11 Ore om / defecte majore detectate (2) X X
12 Nr. de cerine conflictuale (2) X X X
13 Nr. de intrri/ieiri pe modul (1) X X
14 Msuri ale ingineriei software (3) X X
15 Graful complexitii teoretice pt. arhitec. (1) X
16 Complexitatea ciclomatic (3) X X
17 Determ. testare minimal unitate (2) X X
18 Urmrire fiabilitate (2) X
19 Proiectare structur (1) X
20 Timp mediu pt. a detecta k defecte (3) X
21 Nivel de puritate software (1) X
1 2 3 4 5 6 7 8 9 10 11
22 Nr. estimat de defecte X
20
rmase (seeding) (2)
23 Cerine n acord (1) X X X
24 Acoperire test (2) X X
25 Complexitate flux date sau i-ii (1) X
26 Funcia de cretere fiabilitate (2) X
27 Nr. de defecte reziduale (1) X
28 Analiz incidente n timp (3) X X
29 Testare suficien (0) X X
30 MTBF (3) X X
31 Rata de defectare (3) X
32 Documentaie i listinguri surs (2) X
33 RELY - Fiabilitate software cerut (1) X X
34 Gata de livrare (0) X
35 Completitudine (2) X
36 Precizie testare (1) X X X
37 Fiabilitate performan sistem (2) X
38 Fiabilitate proces independent (0) X
39 Disponibilitate operaional sistem X
combinat (HW/SW) (0)
21
Tabel 4 Numrare Erori Defecte, Incidente
Nr. FAZA CICLULUI DE VIA

crt.
Concept Cerine Design Implementare Testare Instalare Operare Retragere
METRICI verificare Mentenan
(1) (2) (3) (4) (5) (6) (7) (8)
1 Densitate defecte X X X X X X X X
2 Densitatea de X X X X X X X X
defectare
3 Profilul de cdere X X X X X X X X
cumulativ
4 Nr. zile - defect X X X X X X X X
7 Transabilitate X X X
cerine
8 Indici de defectare X X X X X X X X
12 Nr. de cerine X X
conflictuale
23 Cerine n acord X X
Tabelul 5 MTFB; Rata de defectare

crt.
METRICI Concept Cerine Design Implementare Testare Instalare Operare Retragere

verificare Mentenan
(1) (2) (3) (4) (5) (6) (7) (8)
30 MTBF X X X
31 Rata de defectare X X X
22
Tabelul 6 Cretere fiabilitate i Proiecie

crt.
METRICI
(1) (2) (3) (4) (5) (6) (7) (8)
10 Index de maturitate X X X X X
software
18 Urmrire fiabilitate X X X
21 Nivel de puritate X X X
software
26 Funcia de cretere X X X
fiabilitate
28 Analiz incidente n X X X
timp
29 Testare suficien X X
30 MTBF X X X
37 Fiabilitate peforman X X X X X X
sistem
38 Fiabilitate proces X X
independent
39 Disponibilitate X X X
operaional sistem
combinat (HW/SW)
Tabelul 7 Estimare defecte reziduale

crt.
METRICI
(1) (2) (3) (4) (5) (6) (7) (8)
14 Msuri ale ingineriei X *
X
software (Halstead)
22 Nr. estimat de defecte X X X
rmase ( seeding )
27 Nr. de defecte X X X
reziduale
28 Nr. de defectri n timp X X X
36 Testare precizie X
* Dac se schimb codul sursei
Tabel 8 Completitudine; Consisten
23
crt.
METRICI
(1) (2) (3) (4) (5) (6) (7) (8)
5 Acoperire testare modular X X X
sau funcional
6 Graficul cauz i efect X X X X X
7 Transabilitate cerine X X X
12 Nr. de cerine conflictuale X X
16 Complexitate ciclomatic X X X
(faza testare )
24 Testare acoperire X X X X X
32 Documentaie listinguri X X X X
surs
35 Completitudine X X X
36 Testare precizie X
Tabelul 9 Complexitate

crt.
METRICI
(1) (2) (3) (4) (5) (6) (7) (8)
13 Nr. de intrri/ieiri pe X X X
modul
14 Msuri ale ingineriei X X
software (Halstead)
15 Gradul complexitii X X X
teoretice ptr. athitectur
16 Complexitatea ciclomatic X X X
17 Determinare testare X X X
minimal
19 Proiectare structur X X
25 Complexitate flux date sau X X X
informaii
Tabel 10 Control Management
24
crt.
METRICI
(1) (2) (3) (4) (5) (6) (7) (8)
4 Nr. de zile - defect X X X X X X X
8 Indice de defectare X X X X X X
9 Distribuie(i) eroare X X X X X X
11 Ore om/defecte majore X X X X X X
20 Timpul mediu pentru a X X X

descoperi urmtoarele K
defecte
Tabel 11 Acoperirea testrii ( coverage )

crt.
METRICI
(1) (2) (3) (4) (5) (6) (7) (8)
sau funcional
6 Graficul cauz i efect X X X X X
7 Transabilitate cerine X X X
12 Nr. de cerine conflictuale X X
24 Acoperire test X X X X X X
29 Testare suficien X X
32 Documentaie listinguri X X X X
surs
33 RELY - Fiabilitate X X X X X X X
software cerut
35 Completitudine X X X
36 Precizie testare X
Tabel 12 Evaluare, Risc, Beneficiu i Cost
Nr. METRICI FAZA CICLULUI DE VIA

crt.
25
(1) (2) (3) (4) (5) (6) (7) (8)
sau funcional
10 Index de maturitte X X X X X
software
11 Ore om/defecte majore X X X X X X
detectate
14 Msuri ale ingineriei X X
software
18 Urmrire fiabilitate X X X
19 Proiectare structur X
20 Timpul mediu pentru a X X X
detecta urmtoarele K
defecte
21 Nivel de puritate software X X X
27 Nr. de defecte reziduale X X X
31 Rata de defectare X X X
33 RELY - Fiabilitatea X X X X X X X
software cerut
34 Gata de livrare X X
26
2.3.5.2. Etapele ciclului de via software
Pentru a veni n sprijinul utilizatorului, n sensul de a ti cnd s aplice msurile respective

software-ului, ciclul de via s-a divizat n (fig. 10):
timpuriu;
mijlociu;
trziu.
n segmentul timpuriu msurile vizeaz cauzele poteniale ale fiabilitii sistem.
Diviziunea mijlocie se refer la reducerea erorilor de proces, care pot mbunti eficiena
dezvoltrii software. Ultimul segment refer msurile de performan ale fiabilitii sistem.
Segmente ale ciclului de via
Timpuriu Mijlociu Trziu
Concepte Proiectare
Implementare
Cerine Operare
Instalare Retragere
Testare i i
Verificare Mentenan
funcional
Fig.10 Clasificarea ciclului de via
Procesul de msurare
Procesul de msurare a fiabilitii poate fi descris n nou etape (fig. 11).

Aceste etape se pot suprapune sau apar n diferite secvene, funcie de nevoile de
organizare.
Fiecare etap urmrete obinerea unui produs cu potenial nalt de fiabilitate.
Ali factori care influeneaz procesul msurrii:
un comitet de management ferm care s aprecieze continuu maturitatea proces
i produs sau stabilitatea (ori amndou);
folosirea personalului pregtit n aplicarea msurilor unui proiect ntr-un mod
util; instrumente software utilizate;
nelegerea distinciei dintre erori, defecte i defectri.
Etapa 1: Planificarea organizaional-strategic

Se iniializeaz un proces de planificare:
27
Se identific ce caracteristici de fiabilitate ale produsului software sunt necesare
pentru aceste obiective;
Se stabilete o strategie pentru msurarea i managementul fiabilitii software;
Se stabilesc practici documentate pentru conducerea msurtorilor.
Etapa a 2-a: Determinarea scopurilor fiabilitii software

Se definesc scopurile de fiabilitate pentru software-ul care se dezvolt, innd seama
de restriciile proiect: dimensiunea, costul i planificarea;
Se stabilete un domeniu acceptabil de valori;
Se stabilesc inte pentru fiabilitatea intermediar n diferite momente ale efortului de
dezvoltare.
Etapa a 3-a: Implementarea procesului de msurare

Se stabilete un proces de msurare fiabilitate software care se potrivete cel mai bine cu
cerinele organizaiei.
Se revd etapele 4 8 i se selecteaz acelea care conduc cel mai bine la fiabilitatea optim,
funcie de mediul de lucru specific.
Etapa a 4-a: Selectare msuri poteniale

Se identific msurile poteniale care ar putea fi folositoare n atingerea obiectivelor de
fiabilitate stabilite n etapa a 2-a. Se folosete tabelul 3 pentru a determina ce categorie sau categorii
ale msurtorilor de fiabilitate ar putea fi cele mai folositoare proiectului.
Etapa a 5-a: Pregtirea coleciei de date i a planului de msurare

Pentru fiecare msur potenial se determin primitivele necesare n executarea msurtorii.
Datele trebuie organizate de aa fel nct informaiile referitoare la evenimente din timpul
dezvoltrii s fie nregistrate corespunztor ntr-o baz de date i reinute pentru a monitoriza istoria
proiectului sau a face previziuni.
Etapa a 6-a: Monitorizare msurtori

Odat ce colectarea datelor i prezentarea lor ncep, se monitorizeaz msurtorile i
progresul fcut n timpul dezvoltrii pentru a se putea conduce fiabilitatea i astfel s poat fi atinse
elurile pentru livrarea produs.
Se pot lua msuri corective pentru a mbunti caracteristicile software.
Etapa a 7-a: Apreciere fiabilitate

Se analizeaz msurtorile pentru a se asigura c fiabilitatea produsului rezultat
satisface obiectivele stabilite i c este acceptabil;
Se verific consistena criteriului de acceptare i suficiena testelor care demonstreaz
c obiectivele de fiabilitate au fost atinse;
Se documenteaz paii parcuri n aprecierea fiabilitii software;
Se asigur c mbuntirile de fiabilitate n software au fost fcute.
Etapa a 8-a: Folosire software

Se apreciaz efectivitatea efortului de msurare i se execut aciunea corectiv
necesar;
Se face o analiz atent a efortului de msurare n scopul aprecierii fiabilitii produs
i a practicilor de dezvoltare;
Se nregistreaz leciile nvate i se evalueaz satisfacia utilizator vizavi de
fiabilitatea software;
Se identific practicile care sunt inefective i cerinele care indic necesitatea
dezvoltrii i rafinrii msurtorilor i metricilor viitoare.
Etapa a 9-a: Reinerea datelor despre msurtorile software
28
Datele procesului de dezvoltare i din timpul operrii se rein (se nregistreaz) pentru
proiecte viitoare. Ele formeaz baza pentru mbuntirea fiabilitii i comparaiilor msurilor
utilizate n mai multe proiecte.
fiabilitate
Restricii 1. Planificare
i
obiective
strategic organizational
Necesiti Scopuri de
utilizator
2. Determinare scopuri fiabilitate
fiabilitate software intermediar
3. Implementare Proces de
a unui proces de msurare msurare
fiabilitate
Date de
performan 4. Selectare 5. Pregtirea unui
software msuri poteniale plan de msurare i
a unei colecii de date
6. Monitorizarea
msurtorilor
Ajustri
NU necesare
S-a construit
fiabilitate
7. Aprecierea
9. Reinerea datelor fiabilitii
despre msurtorile
software mbuntiri necesare
Obiectivele NU
de fiabilitate sunt
Evaluare practici de satisfcute
msurare
DA ( ACCEPTABIL)
8. Folosire Satisfacie
software utilizator
Fig. 11 Procesul de msurare a fiabilitii
29
Material auxiliar din cartea Ingineria sistemelor informatice, M. Popescu, ATM, 2005
Modele ale ciclului de via ale produselor software
Activitile ciclului de via sunt grupate n faze sau etape.

O asemenea organizare pe faze este dat n tabelul 1:
Tabelul 1. Fazele ciclului de via
FAZE OBIECTIVE PRODUSE FINALE

Cerine utilizator Formularea problemei Specificaii cerine utilizator
Cerine software Analiza problemei Cerine i specificaii software
Proiectarea arhitecturii Soluii de proiectare Proiect de ansamblu
Producie Implementare Proiect de detaliu, software testat
Transfer Instalare Software instalat, instruire clieni, depanare
Mentenan Evoluie produs software Software ntreinut i dezvoltat
Felul n care se grupeaz activitile i succesiunea fazelor duc la diferite modele care
implementeaz ciclul de via.
Un model al ciclului de via descrie activitatea de realizare a produsului software i fluxul
procesului de dezvoltare.
Dintre cele mai cunoscute modele, innd seama de evoluia lor n timp, putem enumera
[CSAB98]:
Modelul n cascad
Modelul incremental
Modelul evolutiv
Modelul n spiral
Inginerie software bazat pe model
I. Modelul n cascad
Este un model tradiional de dezvoltare software, care presupune c dezvoltarea ncepe cu

definirea cerinelor i a specificaiilor (secvenial, dar i alternndu-le).
Urmeaz proiectarea, dup care se pot implementa module mici ce se pot testa separat i
apoi mpreun; dup ce se termin testul de integrare, produsul software este testat i livrat la
beneficiar, urmnd faza de mentenan (fig. 1 ).
Definire cerine
Analiz
Proiectare
Implementare cod
Testare
Utilizare i mentenan
Fig.1 Modelul de dezvoltare n cascad
n acest model intrrile unei faze sunt ieirile alteia.

Feedback-ul e generat de erorile care se repercuteaz asupra fazei urmtoare.
Erorile se propag indirect, antrennd costuri de modificare, de aceea fiecare faz trebuie
testat foarte atent.
Dac se utilizeaz modelul n domenii mai puin cunoscute, pot interveni costuri mari,
antrenate de nelegerea eronat a cerinelor, fapt descoperit ntr-o etap trzie, de aceea la nivel
conceptual e necesar utilizarea unor prototipuri n fazele iniiale ale ciclului de via.
Fazele modelului n cascad implic personal diversificat ca pregtire (analiti,
programatori, testeri .a.) i se poate afirma c este o strategie de implementare clasic.
II. Modelul incremental
Etapele finale se realizeaz n mai muli pai succesivi, fapt ce permite obinerea de mai
multe versiuni ale produsului software (fig. 2).
Cerine utilizator
Cerine software
Proiectare arhitectural
Proiectare detaliat i
producie
Transfer
timp
Fig.2 Modelul incremental
Modelul are caracteristicile:

analiza i proiectul arhitectural se realizeaz ntr-o singur component;
proiectarea detaliat, producia, transferul i mentenana au loc n mai muli pai
succesivi;
obinerea produsului software pe pai permite verificarea dac acesta va da
rezultatele scontate;
riscul e divizat la cteva incremente mai mici n loc s se concentreze pe o
dezvoltare ampl;
nelegerea cerinelor pentru incrementele ulterioare e mai bun, aceast metodologie
fiind foarte adecvat programelor de risc sczut mediu;
modelul incremental e mai bun dect modelul n cascad, necesitnd o organizare
suplimentar, dar prin obinerea de mai multe versiuni ofer posibilitatea creterii
calitii produsului software.
III. Modelul evolutiv
Fa de modelele prezentate anterior, cere o organizare mai bun i un management mai

complicat. Este foarte indicat i util cnd specificaiile iniiale nu sunt foarte clare sau cnd se
realizeaz un software nou i nu se pot formula specificaii precise i complete sau acestea nu sunt
stabile [PRES93].
Modelul evolutiv, prin parcurgerea pailor si, creaz un prototip iniial, care, la final, prin
reluarea etapelor va satisface cerinele clienilor (fig. 3).
Cerine utilizator
Cerine software
Proiectare detaliat i
producie
Transfer
timp
Fig.3 Modelul evolutiv
Axat pe protopizare, prin reluarea tuturor fazelor, modelul acesta construiete un produs n
timp mai ndelungat, dar ofer posibilitatea rezolvrii unor probleme noi sau adugarea de funcii
noi cerute de utilizatorii produselor software.
Prototipul este folositor utilizatorului final care va nelege mai bine ce dorete sau ce se
vrea de la produs, el fiind implicat n ntreg procesul de dezvoltare(fig. 10) i e util i realizatorului
n testarea unor tehnici, algoritmi sau interfee realizate.
n ceea ce privete prototipul, el are dou forme:
prototipul de ncercare, care trebuie realizat rapid, chiar dac e incomplet i care se
utilizeaz pentru validarea interfeei i a unor algoritmi implementai, urmrind
construirea unei arhitecturi care s rspund ct mai bine cerinelor utilizatorilor;
prototipul evolutiv, care dezvolt produsul final, avnd ca scop nglobarea tuturor
caracteristicilor de calitate formulate; acest prototip evolueaz mai lent, dar permite
mbuntirea continu a calitii produsului final, reducnd astfel costurile de
mentenan.
Acest model este utilizat de programele cu risc mediu nalt.
Provocarea pentru dezvoltatorii de sistem va consta n a concepe un proces de dezvoltare
care va descoperi, defini i formula cerinele reale, implicnd direct utilizatorii i testnd versiunile
intermediare ale prototipurilor.
Raportat la cerinele pieei, modelul poate oferi o soluie evolutiv sau una revoluionar
(prin strategia agresiv).
Combinarea celor dou soluii, innd seama de studiile de pia, poate duce la o soluie
intermediar.
Reluare pn cnd produsul e complet
Setare obiective: "Ingineria" unui

performan; prototip
tehnice;
calitate (fiabilitate)
Codificare i testare prototip
Alegerea arhitecturii sistemului
Livrare prototip pentru evaluarea utilizator
Pregtirea planului de dezvoltare evolutiv Analiza rezultatelor
Feedback utilizator Feedback utilizator
Fig.4 Implicarea utilizatorului n modelul evolutiv

IV. Modelul n spiral
Modelul a fost dezvoltat de Barry Boehm i furnizeaz o concepie de reducere a riscului n

ciclul de via software. El pornete de la premisa c n faza de mentenan a produselor software
pot aprea probleme care necesit definirea de noi cerine de specificare, de analiz i proiectare
[JACO96].
Modelul n spiral (fig. 11) descrie cum se dezvolt un produs pentru a construi o nou
versiune i cum aceasta evolueaz incremental de la un prototip la un produs complet.
Se poate pune ntrebarea: "Care este diferena ntre modelele evolutiv, incremental i n
spiral ?"
Actualmente, majoritatea programelor folosesc o combinaie a celor trei modele.
Modelul n spiral este o combinaie a modelului incremental cu cel evolutiv, la care se
adaug managementul riscului.
Cheia alegerii unei metode de dezvoltare e dirijat de factori ca (att pentru softul militar
ct i cel civil):
(1) timpul de livrare pe pia;
(2) nelegerea cerinelor;
(3) perimarea tehnologiei;
(4) orientarea necesitilor utilizatorilor;
(5) complexitatea;
(6) amplitudinea efortului investit;
(7) ciclul de via anticipat al sistemului;
(8) dezvoltarea de hardware n paralel.
Modelul are aceleai etape de realizare, ns fiecare ciclu de dezvoltare ncepe cu studiul de
fezabilitate, continund apoi cu specificarea cerinelor, analiza, proiectarea i implementarea.
ANALIZ
PROIECTARE
SPECIFICAII CERINE
v1
v2 v3 v4
IMPLEMENTARE I TESTARE INDIVIDUAL
VERSIUNE FINAL
INTEGRARE
Fig.5 Modelul n spiral
Fiecare dintre etapele modelului n spiral cuprinde o succesiune de activiti:

determinarea obiectivelor etapei, a variantelor posibile i a restriciilor;
evaluarea alternativelor, identificarea riscurilor i soluionarea lor;
dezvoltarea i verificarea urmtorului nivel al produsului;
ntocmirea planului etapei urmtoare, analiznd riscurile.
Criteriul care st la baza alegerii unor alternative de implementare este costul implicat.
n esen, dezvoltarea produselor software conine toate fazele i activitile descrise, chiar
dac se numesc altfel n diferite metodologii, dezvoltarea avnd loc incremental, indiferent de
metoda de dezvoltare aleas.
La nceput un grup mic de persoane face analiza i proiectarea, ntr-o manier iterativ.
Cnd structura sistemului devine stabil, este antrenat mai mult personal n activitile de
implementare i testare.
O divizare a timpului destinat fazelor proiectului, precum i raportul timp/efort pe faze, pot
arta ca n fig. 6 .
efort
Testare
Implementare
Proiectare
Analiz
timp
Fig.6 Relaia efort-timp

Construirea, n ultimul timp, a unor instrumente care asist realizarea produselor software n
toate fazele, au permis noi abordri ale ciclului de via (instrumente CASE - Computer Aided
Software Engineering).
Aceste instrumente CASE implementeaz metodologiile de realizare a produselor software
bazate pe structura funcional, pe structura bazelor i/sau metodologiile orientate obiect, permind
construirea, verificarea, validarea, testarea, memorarea i reutilizarea componentelor aplicaiilor i
produselor program.
Prin furnizarea unor modele de analiz-proiectare i prin generarea automat de cod pentru
aceste modele, instrumentele CASE permit obinerea unor produse fiabile i de calitate, reducnd
totodat termenele de livrare.
V. Inginerie software bazat pe model
Presupune dezvoltarea produsului software avnd la baz un model care s uureze

nelegerea construirii acestuia.
Se au n vedere urmtoarele tipuri de modele:
Modele de produse software
Acestea ofer o form grafic de programare de nivel foarte nalt.
Modelele se pot simula i anima pentru a oferi feedback i suport pentru verificarea i
evaluarea performanelor.
Modele de procese - utilizate n toate activitile ciclului de via.
Pot fi implementate asemntor cu cele de produse software.
Generarea de cod pentru modele.
Modelele pot fi mbuntite i stocate automatizat pentru a fi incluse n programe.
Modele de testare.
Asigur testarea prin modelare i simularea driverelor externe.
Folosirea modelelor presupune a urma aceleai faze ale ciclului de via, ntr-o etap
rafinndu-se modelul din faza precedent.
Ingineria software bazat pe modele presupune existena unor instrumente CASE care s
implementeze modelele, oferind avantaje deoarece:
modelul e o reprezentare abstract a sistemului considerat, folosit pentru a-i studia
proprietile;
modelele permit formalizarea cerinelor i depistarea inconsistenei i
incompletitudinii.
n ceea ce privete produsele software, se folosesc:
modele funcionale (diagrame de flux de date DFD-Data Flow Diagram);
modele de date (diagrame entitate-relaie ERD-Entity Relationship Diagram);
modele de control (diagrame de tranziie a strilor STD- States Transition Diagram,
diagrame PETRI);.
O alt clasificare mparte modelele produselor software n:
modele descriptive (statice);
modele operaionale (dinamice), ce pot simula comportarea sistemului la utilizator.
Modelele operaionale i evolutive pot execute i testa produsul n fiecare faz, permind
controlul de calitate i asigurarea fiabilitii pe ntreg ciclului de via.
Dezvoltarea axat pe model necesit, pentru toate tipurile de modele (funcional, de date, de
control):
un limbaj de modelare cu o semantic clar, care s se utilizeze la toate nivelurile
(analiz, proiectare) i de ctre ntreg personalul implicat (analiti, programatori,
utilizatori);
o tehnologie care s fie documentat i care s cuprind un editor grafic, un
generator de cod i o baz de date pentru simulare i aplicaii (de exemplu, Power
Designer Suite al firmei Sybase).
Fiabilitatea i calitatea
produselor software
Concepte generale privind
calitatea
Calitatea produselor software reprezint
totalitatea nsuirilor tehnice, economice i
sociale ale produselor software.
Ea reprezint ansamblul nsuirilor ce
exprim gradul n care acestea satisfac
nevoia utilizatorilor, n funcie de parametrii
tehnico-economici, de utilitate i de eficiena
economic n exploatare.
Gradul de utilitate al produselor program cuprinde:
a) calitatea de concepie si proiectare - msura n care
proiectul produsului program asigura satisfacerea
cerinelor utilizatorilor;
b) calitatea de execuie - msura n care procesul de
elaborare se desfoar conform fluxurilor stabilite, cu
utilizarea resurselor adecvate;
c) calitatea de conformitate - gradul de concordanta
dintre nsuirile reale ale produsului program si cele
prezentate n documentaia finala;
d) capacitatea de utilizare - comportamentul produsului
program n rezolvarea curenta a problemelor aparinnd
clasei pentru care a fost elaborat;
e) capacitatea de mentenan - msura n care pot fi
eliminate anomaliile ce apar n timpul execuiei sau pot fi
puse de acord noi cerine de prelucrare cu efortul pentru
implementare.
Particularitile manifestrii calitii n domeniul produselor software:
- producia de software nu este o producie de masa, fiecare produs software fiind un
unicat;
- produsele software sunt reproductibile cu costuri aproape nule, ceea ce nseamn ca,
odat realizat un produs, el este disponibil ntr-un numr nelimitat de exemplare.
Calitatea copiilor este aceeai cu cea a originalului, deci o calitate necorespunztoare
se poate propaga cu efecte nefavorabile, antrennd costuri de remediere foarte mari i
afectnd imaginea firmei productoare;
- produsele software nu sunt supuse uzurii fizice, ele se erodeaz numai din punct de
vedere moral, atunci cnd nu mai corespund noilor cerine sau cnd apar produse
software mai performante care realizeaz aceleai funciuni;
- pentru a putea utiliza produsele software este nevoie de un procesor care sa le ruleze.
Sistemele de calcul i de operare sunt supuse, de asemenea, uzurii morale, punndu-
se i n acest caz problema transferrii produsului software ntr-un alt mediu. Un
produs software care poseda o portabilitate ridicat poate fi modificat cu uurin, cu
costuri mici.
- comportamentul instruciunilor este egal n timp, nu se deterioreaz;
- erorile sunt provocate de folosirea sau combinarea incorect a instruciunilor sau altor
componente elementare, i nu de aceste componente n sine;
- interaciunile dintre componentele unui program sunt, n general, mai complexe, mai
ales daca acestea ruleaz n cadrul unor aplicaii complexe;
- erorile exist deja n program, ele sunt eliminate cu timpul, prin depanare, deci
programul nu i pierde calitile prin trecerea timpului, ci si le mbuntete;
- eliminarea unei erori nu d siguran c a diminuat numrul total de erori cu o unitate;
- non-calitatea programelor poate fi atribuit n ntregime greelilor umane, de
proiectare, concepie, programare, documentare.
Evaluarea calitii produselor
program
Caracteristicile de calitate
1. Fiabilitatea: un program posed caracteristica de fiabilitate n msura n care ndeplinete funciile de
prelucrare cerute de beneficiar, pe un interval de timp dat, fr erori;
2. Corectitudinea: un produs program este corect daca transformrile pe care le efectueaz conduc la
obinerea de rezultate ce corespund calitativ i cantitativ cu specificaiile de programare;
3. Eficacitatea: realizeaz o corelaie ct mai adecvat ntre consumurile de resurse (timp de execuie,
memorie intern, tipuri i numr periferice) i complexitatea problemei ce se rezolv;
4. Sigurana n utilizarea curent: stabilete msura n care un program aplicativ nu permite efectuarea
de modificri neautorizate sau nedorite n volume de date, precum i distrugerea parial sau total a
volumelor de date;
5. Stabilitatea: indic "rezistenta" programului aplicativ fa de efectele generate de o modificare a datelor
iniiale, ct i n secvenele de instruciuni care compun modulele care intr n componenta sa;
6. Mentenabilitatea: msura n care este permis actualizarea rapid si uoar a produsului program
pentru a putea continua utilizarea acestuia chiar n condiii modificate;
7. Adaptabilitatea: capacitatea produsului program de a permite integrarea de noi funcii de prelucrare i
de a include acele secvene de instruciuni care mresc performanta programului, aducndu-l la nivelul
eficienei de utilizare de la un moment dat, ulterior elaborrii;
8. Liniaritatea: msoar gradul n care la elaborarea unui modul, a unei secvene sunt utilizate instruciuni
care se executa una dup alta sau msura n care nu sunt utilizate instruciuni de salt condiionat sau
necondiionat.
9. Claritatea: un produs program este considerat neclar atunci cnd secvenele ce formeaz modulele sale
conin instruciuni ce pot lipsi fr a fi afectata calitatea rezultatelor finale;
10. Reutilizabilitatea: reprezint capacitatea unor module ale produsului program de a fi ncorporate n
alte programe avnd rezultat direct economia de munca;
11. Portabilitatea: este caracteristica de calitate care pune n eviden gradul n care un produs program
poate fi rulat pe mai multe tipuri de calculatoare;
12. Integrabilitatea: este caracteristica de calitate care arata gradul n care produsele program pot fi
incluse n sisteme complexe de prelucrare a datelor.
Atributele calitii
1. testabilitatea: ofer utilizatorilor posibilitatea de a pune n eviden ct mai
multe variante de probleme ce pot fi rezolvate i comportamentul
programului aplicativ n situaii particulare (fiiere vide, date incomplete,
date neconsistente);
2. completitudinea: este atributul ce d msura n care modulele produsului
software sunt parial activabile i fiecare realizeaz funcia de prelucrare
dat n specificaii;
3. generalitatea: este atributul care pune n eviden aria de cuprindere a
funciilor de prelucrare, variantele problemei ce pot fi rezolvate, cazurile
particulare, dimensiunile maxime ce se iau n considerare;
4. consistena: pune n evident msura n care modulele realizeaz funcii de
prelucrare necontradictorii i se bazeaz pe uniformizare n folosirea
simbolurilor, a regulilor de construire a identificatorilor, etichetelor i n
general a secvenelor omogene;
5. complexitatea: fiecrui program aplicativ i se asociaz o reprezentare sub
form arborescent sau o alt form grafic ce conine noduri i arce
orientate. Complexitatea este un atribut care permite stabilirea diferenelor
dintre structurile programelor i ierarhizarea programelor dup noduri, arce
i modul de orientare a acestora din urm.
6. flexibilitatea: determin volumul de restricii impus utilizatorilor pentru a
obine rezultate complete i corecte prin folosirea unui program aplicativ;
programul aplicativ este cu att mai flexibil cu ct volumul restriciilor este
mai redus;
7. modularitatea: este atributul de calitate care descrie ordinea din cadrul
produsului format din module.
Modele ale calitii software
modelul Boehm
modelul James McCall.
Modelul Boehm
definete urmtoarele caracteristici de
calitate:
portabilitate,
fiabilitate,
eficien,
testabilitate,
usurina nelegerii - gradul n care obiectivele
i scopul produsului sunt clar definite,
modificabilitate - gradul n care produsul
faciliteaz efectuarea schimbrilor.
Atributele de calitate ale modelului
Boehm
independena fa de hardware,
completitudine,
acuratee - gradul n care ieirile furnizate de produs sunt suficient
de precise pentru a satisface cerinele impuse,
consistena - gradul n care produsul conine notaii, terminologie i
simboluri unitare),
eficiena utilizrii hardware-ului (gradul n care produsul software
utilizeaz n mod economic hardware-ul),
accesibilitate - gradul n care produsul prezint componentele sale
ntr-o manier organizat,
structuralitate - gradul n care produsul nu conine informaii
excesive,
lizibilitate - gradul n care funciunile produsului pot fi identificate prin
citirea codului sursa,
extensibilitate - gradul n care produsul faciliteaz extinderea sa cu
noi funciuni de prelucrare
Modelul James McCall
mbuntete modelul Boehm
st la baza elaborarii standardului ISO 9126 din 1991.
Factorii de calitate prevzuti de McCall sunt grupai n trei categorii:
exploatarea i utilizarea produsului:
corectitudine;
fiabilitate;
eficiena (volumul resurselor de calcul i al codului utilizat de produs pentru
realizarea funciunilor);
integritate (gradul n care poate fi controlat accesul, de catre persoanele
neautorizate, la produs i la date);
utilizabilitate (efortul necesar pentru nvarea produsului i pentru pregtirea
datelor de intrare);
revizia produsului:
mentenabilitate;
testabilitate;
flexibilitate
tranziia produsului:
portabilitate;
reutilizabilitate;
interoperabilitate (efortul necesar pentru a cupla produsul cu alte produse).
Msurarea nivelului calitii
(software metrics metrici software) disciplina destinat
construirii i analizei indicatorilor cu care se evalueaz
nivelul caracteristicilor de calitate
Pentru o caracterizare concret trebuie respectate
urmtoarele cerine:
a. ierarhizarea caracteristicilor de calitate msurabile, dup
importana pe care ele o prezint la beneficiar;
b. evaluarea ct mai precis a nivelului fiecrei caracteristici i
sporirea efortului pentru creterea preciziei;
c. nivelul maxim al caracteristicii trebuie s fie asociat produselor
program cele mai bune;
d. stabilirea modului n care se utilizeaz informaia privind
calitatea, pentru creterea duratei ciclului de via al produsului
program.
Indicatorii de calitate pentru caracteristici, atribute, metrici sunt caracterizai prin: valoarea
i ponderea indicatorului, relaii de influenare (conflictuale sau complementare) i relaii de
ierarhizare (care se stabilesc ntre indicatorii ce se afla n relaii de subordonare).
n cazul relaiilor de ierarhizare, indicatorilor subordonai le sunt asociate ponderi care
semnific gradul de importan fa de ceilali indicatori subordonai aceluiai indicator-
printe. Suma ponderilor de pe un nivel inferior subordonat unei caracteristici de calitate
este constant i egal cu 1 (cel mai utilizat sistem de ponderi).
unde n numrul de indicatori j de pe nivelul inferior subordonat indicatorului i.

Valoarea a unui element de evaluare se stabilete cu relaia:
k - numarul de ordine al metricii,

q numrul de ordine al elementului de evaluare,
S numrul total de evaluri ale aceluiai element de evaluare,
s numrul de ordine al evalurii elementului de evaluare,
valoarea asociata elementului de evaluare q subordonat metricii k pentru evaluarea s
Standarde de calitate
Standarde pentru managementul calitii
Pe plan internaional, domeniul managementului i
asigurrii calitii este reglementat prin standardele ISO
seria 9000, care descriu cerinele pentru sistemul calitii
ntr-o organizaie, fr a specifica ns modalitatea de
implementare a acestuia.
Standardele ISO seria 9000 pot fi utilizate n urmtoarele
situaii:
Asigurarea intern a calitii, la iniiativa conducerii organizaiei;
Cerine contractuale ntre furnizor i client referitoare la sistemul
calitii pentru furnizor;
Evaluare de aderen, caz n care furnizorul este evaluat de
ctre client pentru conformitatea sistemului calitii cu un
standard de referin;
Certificarea sistemului calitii de ctre o ter parte (un
organism de certificare) n raport cu cerinele unui standard de
referin.
Standardele din seria ISO, traduse
n limba romn
SR ISO 8402: 1995; Ediia a 2-a: Managementul calitii i asigurarea calitii - vocabular
SR ISO 9000-1: 1996; Ediia a 2-a: Standarde pentru managementul calitii i asigurarea
calitii - Partea 1: Ghid pentru selecie i utilizare
SR ISO 9000-2 : 1995; Ediia 1: Standardele pentru conducerea calitii i asigurarea calitii -
Partea 2: Ghid pentru aplicarea ISO 9001, ISO 9002 si ISO 9003 la dezvoltarea, livrarea i
mentenana software-ului
SR ISO 9000-3: 1995; Ediia 1: Standardele pentru conducerea calitii i asigurarea calitii -
Partea 2: Ghid pentru aplicarea ISO 9001 la dezvoltarea, livrarea i mentenana software-
ului
SR EN ISO 9001: 1995; Ediia a 2-a: Sistemele calitii - Model pentru asigurarea calitii n
proiectare, dezvoltare, producie, montaj i service
producie, montaj i service
inspecii si ncercri finale
SR EN ISO 9004-1: 1996; Ediia 1: Managementul calitiii i elemente ale sistemului calitii -
Partea 1: Ghid
SR ISO 9004-2:1991; Ediia 1 : Conducerea calitii i elemente ale sistemului calitii - Partea
a 2-a: Ghid pentru servicii
SR ISO 9004-3:1993; Ediia 1: Conducerea calitii si elemente ale sistemului calitii - Partea
a 3-a: Ghid pentru materiale procesate
SR ISO 10011-1:1994; Ediia 1: Ghid pentru auditarea sistemelor calitii- Partea 1: Auditare
SR ISO 10011-2:1993; Ediia 1: Ghid pentru auditarea sistemelor calitii- Partea a 2-a: Criterii
de calificare pentru auditorii sistemelor calitatii
SR ISO 10011-3:1994; Ediia 1 : Ghid pentru auditarea sistemelor calitii- Partea a 3-a:
Conducerea programelor de audit
SR ISO 10013:1996; Ediia 1 : Ghid pentru elaborarea manualelor calitii
Alte standarde netraduse n limba romna
ISO 9000-4:1993 Dependability Management

ISO 9004-4:1993 Quality Improvement
ISO 9004-5 Quality Assurance Plans
ISO 9004-6 Project Management
ISO 9004-7 Configuration Management
ISO 9004-8 Quality Principles
ISO 10012-1:1992 Management of Measurement
Equipement
ISO 10012-2 Control of Measurement Processes
Cerinele ISO 9000 privind sistemele de
calitate
Standardele calitii produselor software
Standardul ISO/IEC/9126 - Caracteristici de calitate
software i metrici are urmatoarele componente:
9126/1 Caracteristici i subcaracteristici de calitate;
defineste caracteristicile i subcaracteristicile de calitate;
se utilizeaz pentru specificarea cerinelor de calitate, evaluarea
calitii produsului, proiectarea listei de verificare pentru revizuirea
proiectrii i testare.
9126/2 Metrici externe;
definete un set de metrici externe pentru msurarea unei
caracteristici sau subcaracteristici de calitate;
se utilizeaz pentru specificarea cerinelor de calitate, evaluarea
calitii produselor n fazele de testare i acceptare, dezvoltarea de
noi metrici.
9126/2 Metrici interne;
definete un set de metrici interne utilizabile la msurarea atributelor
interne ale produselor software;
se utilizeaz pentru definirea scopurilor proiectului, revizuirea
produselor intermediare, dezvoltare de noi metrici.
Standardul ISO/IEC 14598 Evaluarea Produselor Software are
urmtoarele componente:
14598/1 - definete termenii utilizai i prezint cerine i recomandri
generale privind specificarea i evaluarea calitii produselor software;
14598/2 - definete cerine privind managementul proceselor suport n
evaluarea produsului software i face recomandri privind dezvoltarea i
utilizarea unui plan de msurare;
14598/3 este destinat fazei de dezvoltare a produsului software i
conine criterii de selectare a metricilor i recomandri privind verificarea
i validarea caracteristicilor de calitate, analiza msurrii, ameliorarea
procesului de evaluare;
14598/4 definete un proces de evaluare a calitii unui produs
software, utilizabil pentru selectarea unui produs din mai multe produse
sau de acceptare a unui produs utilizndu-se caracteristicile de calitate
i metricile din standardul 9126 i modelul de evaluare 14598-1;
14598/5 definete cerine i face recomandri privind evaluarea
produselor software aflate n faza de livrare-implementare;
14598/6 definete cerinele privind documentaia ce nsoete
evaluarea produsului software i face recomandri privind dezvoltarea i
validarea evalurii
Standarde de calitate a procesului de realizare
a produselor software -
Software Capability Maturity Model (SW-CMM)
CMM prevede cinci nivele de maturitate:
1. Initial. Procesul de dezvoltare poate fi caracterizat ca ad-hoc si
ocazional, chiar haotic. Un numr mic de procese sunt definite, iar
succesul depinde de eforturile individuale ale lucrtorilor.
2. Repeatable. Sunt stabilite procese de baz ale managementului
de proiect pentru urmrirea costurilor, planului de lucru i a
funcionalitaii. Experiena existent asigur repetabilitatea
succesului n proiecte cu aplicaii similare.
3. Defined. Att procesul de management ct si cel de dezvoltare
este documentat, standardizat i integrat ntr-un proces standard al
organizaiei. Toate proiectele folosesc o versiune ajustat i
aprobat a procesului standard.
4. Managed. Are loc colectarea datelor care masoar calitatea
procesului i a produsului. Ambele procese (management si
dezvoltare) sunt gestionate i controlate n plan cantitativ.
5. Optimizing. Procesele pot fi continuu mbuntite cu ajutorul
feedback-ului cantitativ i al ideilor i tehnologiilor novatoare.
Aplicarea ISO 9001 pentru
industria software
Factorii de succes pentru mbuntirea proceselor
software prin ISO 9001 sunt:
definirea i documentarea strii curente
identificarea celor mai bune practici
identificarea proceselor lucrative
simplificarea procedurilor de rutin
audituri interne
spirit de echipa
ateliere de lucru (workshop-uri)
definirea unui limbaj comun
studii ale percepiei clientilor
FIABILITATEA PRODUSELOR
SOFTWARE. DEFINIRE I OBIECTIVE
Fiabilitatea software e un obiectiv de
calitate major. Rar este acceptat
fiabilitatea medie sau sczut
APRECIEREA FIABILITII
FOLOSIND METRICI SOFTWARE
LOC (Lines of Code) - se folosete ca o msur de normalizare pentru
fiabilitatea software (defecte/KLOC), pentru aprecierea productivitii
(LOC/lun programator) i furnizeaz o estimare brut a costului/efort.
Metrici de numrare defecte - aproape toate programele de metrici
industriale colecteaz date despre defectele software descoperite n timpul
dezvoltrii i testrii; de multe ori, astfel de programe nu sunt denumite
explicit "programe de metrici", fiind privite ca practici ale ingineriei software
i ale managementului de configuraie;
Numrul ciclomatic MC Cabe - dei exist multe critici la adresa lui,
rmne foarte popular. E simplu de calculat printr-o analiz static i se
utilizeaz frecvent pentru controlul complexitii codului. Se spune c la
Hewlett Packard orice modul cu o complexitate ciclomatic mai mare de 16
trebuie reproiectat.
Punctele funcionale: analiza punctelor funcionale este foarte grea pentru
a se face corespunztor i de complexitate gratuit dac se utilizeaz la
estimarea resurselor. Totui, s-a acceptat ca o msur a dimensiunii
standard, n special n sectorul IT financiar.
Programul de construire a metricilor
de fiabilitate software
n contextul msurrii software sunt trei clase
de entiti:
Procese: orice activitate specific, set de activiti
sau timp n fabricarea unui produs sau dezvoltarea
unui proiect. Exemple n acest sens sunt: specificarea
cerinelor, proiectarea, codificarea i verificarea sau o
anumit perioad de timp specific, cum ar fi "primele
trei luni ale proiectului X".
Produse: orice rezultat al unei activiti sau
document rezultat dintr-un proces. Exemple: codul
surs, o specificaie de proiectare, un plan de test i
un manual de utilizare produs software.
Resurse: orice intrare ntr-un proces. Exemple: o
persoan sau o echip, un compilator sau un
instrument de testare software.
Cerine impuse metricilor
metricii trebuie s fie uor de neles. De exemplu, liniile de cod
(LOC, KLOC) i punctele funcionale sunt cele mai obinuite msuri
ale dimensiunii software (potenial i ale complexitii);
metricii trebuie s fie ieftini pentru a putea fi cumprai; studiile arat
c aproximativ 5% - 10% din costurile totale de dezvoltare se pot
datora metricilor;
metricii trebuie s fie testai nainte de a se utiliza; pot avea o baz
teoretic solid, dar nu au aplicare sau evaluare practic;
metricii trebuie s fie un ajutor managerial pentru mbuntirea
proceselor;
metricii s fie disponibili la timp; dac un metric nu e disponibil dect
atunci cnd sunt probleme, de exemplu dac rata de defectare n-a
fost msurat timpuriu, poate fi nefolositor mai trziu;
metricii trebuie s stimuleze mbuntirile de proces; nu se vor
utiliza metrici pentru a judeca echipa sau performana individual;
metricii trebuie s fie folositori la mai multe niveluri: s serveasc
att managementului ct i echipei tehnice pentru mbuntirea
proceselor de dezvoltare.
Analiza datelor
Metricii de fiabilitate folosesc date obiective i
subiective:
datele obiective: contoare ale unor caracteristici
(KLOC, puncte funcionale, componente, funcii
testate, uniti codificate, modificri, erori) ce se pot
verifica independent;
date subiective: aprecieri individuale ale unei
caracteristici sau condiii (nivelul dificultii problemei,
gradul noii tehnologii implicate, stabilitatea cerinelor).
Bazele de date create conin trei tipuri de date:
date de cost - reflect eforturile fcute;
date despre procese - reflect informaia despre
programe (metodologie, instrumente i tehnici
utilizate) i experiena/instruirea personalului;
date despre produs - includ dimensiunea, date despre
modificri, defecte i rezultatele analizelor statistice
asupra codului livrat.
Procesul de management utiliznd
metrici
Metrici software pentru fiabilitate n
ciclul de via
Se vor aborda trei faze ale ciclului de via
software, unde se pot aplica cu impact
direct asupra fiabilitii tehnicile de
prevenire a erorilor i metricile software :
specificare cerine;
proiectare i codificare;
testare
Metrici de fiabilitate pentru
specificarea cerinelor
Linii de text - linii fizice coninute de fiierul text;
Imperative - numrul de cerine i fraze care cer s se
ntreprind o aciune. Este un indicator de baz;
Continuri - fraze care urmeaz unei exprimri imperative i
specific cerinele de nivel sczut (pentru un numr de
cerine suplimentare);
Directive - referine la figuri, tabele sau note;
Fraze ineficiente - clauze care pot produce incertitudine
datorit ambiguitii sau nelesului multiplu pe care-l au;
Incompletitudine - afirmaii din text gen TBD (To Be
Determined) sau TBS (To Be Supplied - de livrat);
Opiuni- cuvinte care par s ofere dezvoltatorului alegerea
n a ndeplini specificaiile, dar care pot fi ambigue.
Rezultatele la nivelul 3 (proiectare arhitecturala) si 4 (proiectare detaliata)
Metrici de fiabilitate pentru proiectare i
codificare
n1 - numrul de operatori distinci;

n2 - numrul de operanzi distinci;
N1 - numrul total de apariii ale
operatorilor;
N2 - numrul total de apariii ale
operanzilor.
Metrici de fiabilitate pentru
testarea software
numrul de erori rmase n produs;

timpul necesar pentru a detecta erorile
reziduale;
timpul de testare suplimentar pentru a
atinge un anumit obiectiv de fiabilitate,
etc.
Ingineria Programrii
Metrici
Curs 12
Adriana Gheorghie, adrianaa@infoiasi.ro

Ovidiu Gheorghie, ogh@infoiasi.ro
IP
12
Aprecierea calitii
Cum msurm calitatea unui lucru?
Calitatea construciei (ct de bine este lucrat, dac exist
defecte n materialul din care este fabricat ...)
Calitatea designului (elegan, comfort ...)
O combinaie ntre calitile construciei i ale designului
(rezistena...)
n general putem spune c un scaun A este mai bun
dect un scaun B sub un anumit aspect al calitii,
dar de obicei este greu de precizat cu ct este mai
bun.
IP
12
Calitatea unui program (1)
Nu se examineaz calitatea construciei (=> unicitate
ntre toate disciplinele inginereti)
Toate atributele calitii se refer la design.
Dac ne referim la valori estetice:
Programele sunt n mare parte invizibile, iar valorile estetice
conteaz doar pentru prile vizibile
nafar de interfa, singurele aspecte observabile la un
program sunt:
Notaiile folosite pentru design i scrierea codului
Comportamentul programului atunci cnd interacioneaz cu
alte entiti.
IP
12
Atunci cnd vorbim despre calitatea unui
program trebuie:
S definim atribute ale calitii care ne
intereseaz;
S cutm modaliti de msurare a lor;
S putem da o reprezentare designului;
S scriem specificaii care s ghideze
programatorii (calitile designului s fie
respectate i de implementare).
IP
12
Codul surs
Codul care implementeaz un design este o
reprezentare a acelui design.
Asigurarea calitii fcut dup scrierea
codului este un proces costisitor.
IP
12
Msoar ct de bine se potrivete un program
mediului su.
Ia n calcul aspecte de tipul:
Programul funcioneaz;
Programul face ceea ce trebuie s fac;
Programul este sigur;
Programul poate fi adaptat pe msur ce nevoile se
schimb.
Toate msurile referitoare la calitate sunt relative.
IP
12
Concepte ale calitii
Siguran
Eficiena
ntreinere
Uzabilitate
IP
12
Sigurana
Este programul complet, consistent i robust?
completitudine trateaz toate intrrile posibile;
consisten se comport ntotdeauna aa cum
este ateptat;
robustee se comport bine n situaii anormale
(ex. lipsa resurselor).
IP
12
Eficiena
Programul utilizeaz ntr-un mod eficient
resursele? (procesor, memorie, reea...)
Eficiena este ntotdeauna mai puin
important dect sigurana.
Este mai uor s facem un program sigur s
fie eficient dect un program eficient s fie
sigur.
IP
12
ntreinere
Ct de uor poate fi modificat design-ul
ulterior?
Tipuri de ntreinere:
Corectiv: eliminarea erorilor;
Perfectiv: adugarea de funcionaliti care ar fi
trebuit s fie oferite;
Adaptiv: actualizarea programului cnd se
schimb cerinele.
IP
12
Uzabilitate
Ct de uor este programul de nvat i de
folosit?
IP
12
Atribute msurabile
Simplitate
Modularitate
IP
12
Simplitate
Este msura invers a complexitii.
Aspecte ale complexitii:
Complexitatea fluxului de control: numr cile
posibile de execuie ale unui program (vezi testare
structural).
Complexitatea fluxului de informaii: numr
datele care sunt transmise n program.
Complexitatea nelegerii: numr identificatorii i
operatorii folosii.
IP
12
Modularitate
Poate fi msurat uitndu-ne la:
Coeziune: ct de bine lucreaz mpreun
componentele unui modul.
Cuplaj: gradul de interaciune ntre module.
IP
12
Motivaii pentru metrici
Efectum msurtori pentru
a nelege
a controla
a prevedea
Cnd poi s msori lucrul despre care vorbeti i s

exprimi aceasta n numere, atunci tii ceva despre acel
lucru. Dar cnd nu poi s l msori, cnd nu poi s l
exprimi n numere, cunotinele tale sunt slabe i
nesatisfctoare; ele pot fi nceputul cunoaterii, dar mai
nimic nu este nc fcut pentru a ajunge la stadiul de
tiin. (Lord Kelvin)
IP
12
Ce se dorete a fi msurat
Dimensiunea unui program
Complexitatea unui program
Fiabilitatea unui program
Timpul necesar dezvoltrii unui program

Alocarea resurselor necesare dezvoltrii unui
program
Productivitatea muncii
Costurile de dezvoltare
IP
12
Metrici de baz
KLOC: Kilo Lines Of Code (mii linii de cod)
Effort, PM: Person Month (Om lun).

IP
12
COCOMO
COnstructive COst MOdel (Boehm 1981)
Folosit pentru evaluarea costurilor
Trei nivele de rafinare a prediciilor:

COCOMO de baz
COCOMO intermediar
COCOMO detaliat
IP
12
COCOMO de baz
Formula pentru efortul necesar dezvoltrii n
funcie de numrul de linii de cod
Exprimat n PM
Constante ce depind de tipul proiectului
Organic: b = 2.4 c=1.5

Semidetaat: b = 3.0 c=1.12
Integrat: b = 3.6 c = 1.20
IP
12
COCOMO 2
Propus de Boehm n 1995
Ia n calcul tehnicile moderne de dezvoltare

aprute
Prototipizare
Dezvoltarea pe componente
4GL
Ofer posibilitatea de a face estimri nc din

primele faze ale dezvoltrii
IP
12
COCOMO 2: Prototipizarea iniial
Surprinde efortul necesar realizrii unui

prototip al aplicaiei
Se bazeaz pe numrul de puncte obiect

(NOP)
IP
12
NOP
Se inventariaz ecranele ce trebuie afiate
Simple: 1
Complexe: 2
Foarte complexe: 3
Se inventariaz rapoartele ce trebuie generate

Simple: 2
Complexe: 5
Foarte complexe: 8
Fiecare modul n limbaj de nivel mai jos (ex. 3GL): 10
Suma punctelor obinute reprezint numrul total de

puncte obiect ale programului.
IP
12
COCOMO 2: Prototipizarea iniial
(cont.)
Formula de calcul a efortului
Procentul de reutilizare a codului Productivitatea (NOP/PM)
Foarte Mic Nominal Foarte

Experienta programatorului mica a a Mare mare
Productivitate (NOP/PM) 4 7 13 25 50
IP
12
COCOMO 2: proiectarea iniial
NOP =>Size (2..40 LOC/NOP)
KLOC
Efort 1.1 .. 1.24
2.5
Capacitatea Reutilizare Experiena

Planificare
personalului cerut personalului
1..6
Sigurana i Dificultatea Faciliti

complexitate platformei asisten
Procentul de Productivitatea
Numar linii cod linii de cod pentru acest tip
generate automat generate automat de activitate
IP
12
COCOMO 2: dup proiectare
Se estimeaz numrul total de linii de cod

(ESLOC)
Factori luai n calcul

Volatilitatea cerinelor
Gradul posibilitii de reutilizare a codului
IP
12
COCOMO 2:
influena asupra costurilor
Atributele produsului
Sigurana produsului; Complexitatea modulelor
sistemului; Dimensiunea documentaiei cerute;
Dimensiunile bazei de date utilizate; Procentajul
cerut de componente reutilizabile.
Atributele sistemului de calcul

Constrngeri privind timpul de execuie;
Volabilitatea platformei pe care se face
dezvoltarea; Constrngeri de memorie.
IP
12
COCOMO 2:
influena asupra costurilor (cont.)
Atributele personalului
Capacitatea analitilor; Capacitatea
programatorilor; Continuitatea personalului;
Experiena analistului n domeniul problemei;
Experiena programatorilor n domeniul problemei;
Experiena n limbajele i instrumentele folosite
Atributele proiectului
Utilizarea intrumentelor; Gradul de lucru n echipe
aflate la distan i calitatea comunicrii ntre
echipe; Comprimarea planului de dezvoltare
IP
12
COCOMO 2:
calcularea timpului de dezvoltare
Timpul necesar dezvoltrii produsului se
calculeaz dup formula:
IP
12
COCOMO 2:
calcularea preului de dezvoltare
Preul se calculeaz dup formula:
n!
lu
e pe
Constrngeri Experiena st
Sigurana echipei ule
memorie e
, pr
Constrngeri Folosirea Da
timp instrumentelor
IP
12
Distribuia forei de munc n timp
20 om-lun
20 oameni muncesc 1 luna
4 oameni muncesc 5 luni
NU
1 om muncete 20 luni
Productivitatea individual scade atunci cnd echipa

de dezvoltare crete
Comunicare suplimentar
La adugarea de noi membri, productivitatea iniial scade
Creterea numeric a forei de munc la un proiect

rmas n urm are ca efect rmnerea i mai n urm
a proiectului. (Legea lui Brooks)
IP
12
(2)
Productivitatea medie (L: LOC/PM)
P: dimensiunea medie a echipei

IP
12
(2)
Pentru o echip cu P persoane putem avea
ntre P-1 i P(P-1)/2
canale de comunicaie.
Fiecare canal induce o
pierdere l de eficien
Productivitatea individual va fi:
Productivitatea echipei (de dimensiune P) va fi:

IP
12
Cum NU se calculeaz costurile
i NU se fac planificri
Avem 12 luni s terminm treaba, deci treaba va dura 12
luni. Legea lui Parkinson: munca se ntinde pe timpul
avut la dispoziie.
tim c competitorul a cerut $1.000.000. Noi cerem

$900.000.
tim c bugetul clientului pentru produs este de

$500.000. Att ne cost i pe noi dezvoltarea.
Vrem s prezentm produsul la CeBit anul viitor:

terminm pn atunci produsul.
Programul va dura 1 an, dar voi spune c va dura 10

luni. Ce-o s mai conteze 2 luni peste planificare...
IP
12
Metrici Orientate Obiect
Adncimea arborelui de derivare
Numrul claselor derivate dintr-o clas
Metode bazate pe ponderi pentru o clas
Cuplaje ntre clase de obiecte
Responsabilitile unei clase
Lipsa coeziunii n metode
IP
12
Adncimea arborelui de derivare
Care este cel mai lung brum de la clasa

rdcin pn la o clas derivat din
aceasta?
Cu ct o clas se afl mai jos n ierarhie, cu
att crete probabilitatea s moteneasc
mai multe metode de la ancestori.
IP
12
Numrul claselor derivate dintr-o
clas
Cte subclase are o anumit clas?
Indic importana unei anumite clase.
Dei motenirea este o form de refolosire a
codului, un numr mare de clase derivate
conduce la o structur complex a ierarhiei
de clase.
IP
12
Metode bazate pe ponderi pentru
o clas
Cte metode sunt ntr-o clas i ct de
complexe sunt ele?
Numrul i complexitatea metodelor indic
timpul necesar dezvoltrii i meninerii clasei.
Un numr mare de metode ntr-o clas are un
impact mai puternic asupra claselor derivate
i reduce generalitatea.
IP
12
Cuplaje ntre clase de obiecte
De cte clase este legat o anumit clas?
Prea multe cuplaje mpiedic modularitatea i
refolosirea codului.
IP
12
Responsabilitile unei clase
Cte metode pot fi invocate de o metod a
unei alte clase?
Indic complexitatea.
IP
12
Lipsa coeziunii n metode
Fiecare unitate reprezint o unitate logic din
punctul de vedere al funcionalitii?
Coeziunea promoveaz ncapsularea. Dac
metodele nu sunt coezive s-ar putea s fie
nevoie de o subclas.
IP
12
Probleme la folosirea metricilor
Lipsa de acuratee
Rezistena din partea angajailor
Folosirea lor n alte scopuri dect au fost create
Disensiuni n cadrul echipei de dezvoltare

IP
12
V mulumim !
... pentru
atenie
rbdare
Proiectare orientat obiect

Obiective
De a explica cum poate fi proiectat un software
ca o mulime de obiecte care interacioneaz
ntre ele
De a descrie activitile procesului de proiectare

orientat obiect
De a prezenta diferite modele ce pot fi folosite
pentru a descrie un proiect orientat obiect
De a arta felul n care limbajul grafic UML poate
fi folosit pentru a reprezenta aceste modele

Cuprins
Obiecte i clase de obiecte
Procesul de proiectare orientat obiect

Evoluia proiectrii

Dezvoltarea orientat obiect
Analiza, proiectarea i programarea orientat obiect
sunt nrudite dar distincte.
Analiza orientat obiect (OOA) se ocup cu
realizarea unui model obiectual al domeniului
aplicaiei.
Proiectarea orientat obiect (OOD) se ocup cu
realizarea unui model obiectual al sistemului care
implementeaz cerinele.

Programarea orientat obiect (OOP) se ocup cu
implementarea unui proiect orientat obiect ntr-un
limbaj de programare orientat obiect, cum ar fi Java
sau C++.

Caracteristici ale OOD

Obiectele sunt abstractizri ale entitilor din
lumea real sau ale entitilor unui sistem.

Obiectele sunt independente i ncapsuleaz
stare sau informaie.

Funcionalitatea sistemului este exprimat n
termeni de servicii oferite de obiecte.
Sunt eliminate datele comune, obiectele
comunicnd prin schimb de mesaje.
Obiectele pot fi distribuite i pot fi executate
secvenial sau n paralel.

Obiecte care interacionez
o 1 : C1 o 3 :C3 o 4: C4
sta te o 1 sta te o 3 sta te o 4
o ps1 () o ps3 () o ps4 ()
o 2 : C3 o 6 : C1 o 5 :C5
sta te o 2 sta te o 6 sta te o 5
o ps3 () o ps1 () o ps5 ()

Avantaje ale OOD
Mentenan mai uoar. Obiectele pot fi
nelese ca entiti independente.
Obiectele sunt poteniale componente
reutilizabile.
Pentru unele sisteme, poate exista o
echivalen clar ntre entiti din lumea
real i obiecte ale sistemului.

Obiectele sunt entiti dintr-un sistem
software ce reprezint entiti din lumea
real sau din alte sisteme.

Clasele de obiecte sunt modele (abloane)
pentru obiecte. Ele pot fi folosite pentru a
crea obiecte.
Clasele de obiecte pot moteni atribute i
servicii (metode) de la alte clase de obiecte.

Un obiect este o entitate care are o stare i o mulime definit de

operaii care opereaz asupra acelei stri. Starea este reprezentat
ca o mulime de atribute. Operaiile asociate obiectului ofer
servicii pentru alte obiecte (clieni) care solicit aceste servicii
cnd au nevoie de anumite calcule.
Obiectele sunt create dup definiie unei clase de obiecte. O

definiie a unei clase de obiecte servete ca model pentru obiecte.
Ea include declaraii ale tuturor atributelor i metodelor
(serviciilor) ce trebuie asociate cu un obiect din aceas clas.

UML (The Unified Modeling Language)
Diferite notaii pentru descrierea proiectelor
orientate obiect au fost propuse ntre anii
1980 i 2000.
Limbajul UML este o integrare a acestor
notaii.
El descrie notaii folosite pentru diferite
modele ce pot rezulta n analiza sau
proiectarea orientat obiect.

UML este astzi standardul pentru modelarea
orientat obiect.

Clasa Angajat (UML)
Angajat
name: string
address: string
dateOfBirth: Date
employeeNo: integer
socialSecurityNo: string
depar tment: Dept
manager: Employee
salary: integer
status: {current, left, retired}
taxCode: integer
. ..
join ()
leave ()
retire ()
changeDetails ()

Comunicarea obiectelor

Conceptual, obiectele comunic prin schimb
de mesaje.

Mesaje
Numele metodei apelate;
Copii ale informaiei necesare pentru executarea
metodei.

n practic, mesajele sunt implementate prin
apeluri de funcii (metode)
Nume = numele funciei;
Informaii = lista de parametrii.

Exemple de mesaje
// Apelul unei metode asociate cu un obiect
// buffer ce returneaz urmtoarea valoare
// din buffer
v = circularBuffer.Get () ;
// Apelul unei metode asociate cu un

// obiect termostat care seteaz
// temperatura ce trebuie meninut
thermostat.setTemp (20) ;

Generalizare i motenire
Obiectele sunt instane ale unor clase care definesc
tipul atributelor i operaiile.
Clasele pot fi aranjate ntr-o ierarhie de clase n care
o clas (super-clas) este o generalizare a uneia
sau a mai multor clase (sub-clase).
O sub-clas motenete atributele i metodele de la
super-cals i poate aduga propriile metode i
atribute.

Generalizarea din UML este implementat prin
motenire n limbajele de programare orientate
obiect.

O ierarhie de clase
Em plo ye e
Ma na g e r Pro g ra m m e r
b ud g e tsCo ntro lle d pro j e c t

pro g La ng ua g e s
d a te Appo inte d
Pro j e c t De pt. Stra te g ic

Ma na g e r Ma na g e r Ma na g e r
pro j e c ts de pt re spo nsib ilitie s

Avantaje ale motenirii
Este un mecanism de abstractizare ce poate
fi folosit pentru a clasifica entiti.
Este un mecanism de reutilizare att la nivel
de proiectare ct i la nivel de programare.
O ierarhie de motenire este o surs de
informaie de organizare despre domenii i
siteme.

Probleme legate de motenire
Clasele de obiecte nu sunt independente, ele
nu pot fi nelese fr a face referire la super-
clase.

Proiectanii au tendina de a refolosi ierarhiile
create la analiz, ceea ce poate duce la
ineficien.
Ierarhiile de motenire la analiz, proiectare
i programare au funcii diferite i trebuie
ntreinute separat.

Asocieri UML
Obiectele i clasele de obiecte particip n
relaii cu alte obiecte i clase de obiecte.
n UML, o relaie general este indicat prin
o asociere.
Asocierile pot fi adnotate cu informaie ce
descrie asocierea.

Asocierile pot indica faptul c un atribut al
unui obiect este un alt obiect asociat sau c
o metod se bazeaz pe un obiect asociat.

Un model de asocieri
Em plo y e e De pa r tm e nt
is-m e m b e r-o f
is-m a na g e d-b y
m a na g e s
Ma na g e r

Obiecte concurente
Obiectele fiind entiti independente se
preteaz foarte bine la implementri
concurente.

Modelul de schimb de mesaje pentru
comunicarea dintre obiecte poate fi
implementat direct dac obiectele sunt
executate pe procesoare diferite ntr-un
sistem distribuit.

Un proces de proiectare orientat obiect
Procesul de proiectare implic dezvoltarea
ctorva modele ale sistemului.

Ele necesit mult efort de dezvoltare i
ntreinere iar pentru sistemele mici acest
lucru poate s nu fie eficient din punct de
vedere al costurilor.
Totui pentru sistemele mari dezvoltate de
grupuri diferite, modelele de proiectare sunt
un mecanism esenial de comunicare.

Etape ale procesului
Evideniem activitile cheie fr s ne
legm de un proces anume cum ar fi RUP.
Definirea contextului i modele de utilizare ale
sistemului;
Proiectarea arhitecturii sistemului;
Identificarea principalelor obiecte din sistem;
Dezvoltarea modelelor de proiectare;
Specificarea interfeelor obiectelor.

Sistem de monitorizare meteo
Este necesar un sistem de monitorizare meteo pentru a genera

hri meteorologice n mod regulat folosind date colectate de la
staii meteo la distan i de la alte surse cum ar fi observatoare
meteo, baloane i satelii. Staiile meteo transmit datele lor
calculatorului din acea zon ca rspuns la o cerere de la acel
calculator.
Calculatoarele zonale valideaz datele colectate i le integreaz cu

date din diferite surse. Datele integrate sunt arhivate i, folosind
date din aceast arhiv i o baz de date de hri digitizate se
creaz un set de hri meteo locale. Hrile pot fi tiprite pe o
imprimant special sau pot fi afiate n diferite formate.
Contextul sistemului i modele de utilizare
Dezvoltare unei nelegeri ale relaiilor dintre
sistemul software ce trebuie proiectat i mediul
exterior

Contextul sistemului
Este un model static ce descrie relaia cu alte sisteme. Se
folosete un model de tip subsistem.

Model de utilizare
Este un model dinamic ce descrie cum interacionez
sistemul cu mediul. Se folosesc cazuri de utilizare (use-
cases) pentru a arta interaciunile

Arhitectur pe straturi
Stratul de afiare a datelor

Obiectele se ocup cu pregtirea i
subsystem prezentarea datelor ntr-o form
Data display uor de neles
Stratul de arhivare a datelor

subsystem Obiectele se ocup cu stocarea
Data archiving datelor pentru viitoare prelucrri
Stratul de procesare a datelor

subsystem Obiectele se ocup cu verificarea i
Data processing Integrarea datelor colectate
Stratul de colectare a datelor

subsystem Obiectele se ocup cu achiziionarea
Data collection de la surse de la distan

Subsisteme n sistemul de monitorizare meteo
sub sy ste m
Da ta c o lle c tio n sub sy ste m
Da ta displa y
Ob se rv e r Sa te llite
U Useser r Ma p
Co m m s inte
inter rfafac ce e displa y
We a the r Ma p
sta tio n Ba llo o n Ma p printe r
sub sy ste m sub sy ste m

Da ta pro c e ssing Da ta a rc hiv ing
Da
Datata
Da ta Da ta sto
storaragge e
c h e c king inte g ra tio n
Ma p sto re Da ta sto re

Modele de utilizare (use-cases)
Modelele de utilizare sunt folosite pentru a
reprezenta fiecare interaciune cu sistemul.

Un model de utilizare prezint
funcionalitatea sistemului la nivel de actori i
scopuri ale actorilor.

Cazuri de utilizare pentru o staie meteo
Sta r tup
Sh utdo w n
Re po r t
Ca lib ra te
Te st

Descrierea unui Use-case
Sistem
Use-case
Actori
Odat ce interaciunile dintre sistem i mediul lui au
fost nelese, aceast informaie este folosit pentru
proiectarea arhitecturii sistemului.

O arhitectur pe straturi este potrivit pentru staia
meteo
Stratul de interfa pentru rezolvarea comunicaiilor;
Stratul de colecie de date pentru lucrul cu instrumentele
meteo;
Stratul instrumentelor meteo pentru colectarea datelor.

n mod normal nu trebuie s apar mai mult de 7
entiti ntr-un model arhitectural.

Arhitectura unei staii meteo
We a th e r sta tio n
sub sy ste m Ma na g e s a ll
e xte rna l
Inte rfa c e c o m m unic a tio ns
sub sy ste m Co lle c ts a nd

sum m a rise s
Da ta c o lle c tio n
w e a th e r d a ta
sub sy ste m Pa c ka g e o f
Instrum e nts instrum e nts fo r ra w
d a ta c o lle c tio ns

Identificarea obiectelor
Identificarea obiectelor (sau a claselor de obiecte)
este partea cea mai dificil a proiectrii orientate
obiect.
Nu exist nici o 'formul magic' pentru identificarea
obiectelor. Ea se bazeaz doar pe aptitudini,
experien i cunoaterea foarte bun a domeniului
de ctre proiectanii sistemului.
Identificarea obiectelor este un proces iterativ. Este
puin probabil ca de prima dat s poi identifica
toate obiectele corect.

Abordri posibile
Folosirea unei abordri gramaticale bazate pe
descrierea sistemului n limbaj natural (folosit n
metoda Hood de proiectare orientat obiect).
Folosirea unei abordri bazate pe identificarea
lucrurilor tangibile din domeniul aplicaiei.
Folosirea unei abordri comportamentale i
identificarea obiectelor bazat pe cine particip n
sistem i cu ce comportament.

Folosirea unei analize bazate pe scenarii. Obiectele,
atributele i metodele din fiecare scenariu sunt
identificate.

Descrierea unei staii meteo
O staie meteo este un pachet de instrumente controlate de

software, ce colecteaz date, efectueaz unele procesri de date i
transmite aceste date pentru procesri ulterioare. Instrumentele
includ termometre de aer i de sol, un anemometru pentru
msurarea vitezei i direciei vntului, un barometru i un
instrument pentru msurarea precipitaiilor. Datele sunt collectate
periodic.
Cnd se d o comand pentru transmiterea datelor meteo, staia

meteo proceseaz i sumarizeaz datele colectate. Datele
sumarizate sunt transmise calculatorului pentru procesarea hrilor
cnd se primete o cerere de transmisie.
Clasele de obiecte ale unei staii meteo
Termometru de sol, Anemometru, Barometru
Obiecte din domeniul aplicaiei care sunt
obiecte hardware corespunztoare
intrumentelor din sistem.
Staia meteo
Interfaa de baz a staiei meteo cu mediul su.
Ea reflect interaciunile identificate n modelul
use-case.
Datele meteo
ncapsuleaz i sumarizeaz datele provenite
de la instrumente.

Clasele de obiecte ale unei staii meteo
We a th e rSta tio n We a th e rDa ta
id e ntifie r a irTe m pe r a ture s

g ro und T e m pe r a ture s
re po r tWe a th e r ()
w indSpe e d s
c a lib ra te (instrum e nts)
w indDire c tio ns
te st ()
pre ssure s
sta r tup (instrum e nts)
ra infa ll
sh utd o w n (instrum e nts)
c o lle c t ()
sum m a rise ()
Gro und Ane m o m e t e r Ba ro m e t e r

th e rm o m e t e r pre ssure
w ind Spe e d
te m pe r a ture w ind Dire c tio n h e ig h t
te st () te st ()
te st ()
c a lib ra te () c a lib ra te ()

Alte obiecte i rafinarea obiectelor
Folosii cunotiine din domeniul aplicaiei

pentru a identifica alte obiecte i operaii
Staiile meteo trebuie s aib un identificator
unic;
Staiile meteo sunt situate la distan astfel c
defeciuni ale instrumentelor trebuie raportare
automat. Sunt necesare atribute i operaii
pentru auto-testare.

Obiecte active sau pasive
n acest caz obiectele sunt pasive i colecteaz
datele la cerere nu din proprie iniiativ.

Modele de proiectare
Modelele de proiectare prezint obiectele,
clasele de obiecte i relaiile dintre aceste
entiti.
Modelele statice descriu structura static a
sistemului n termeni de clase de obiecte i
relaii.
Modelele dinamice descriu interaciunile
dinamice dintre obiecte.

Exemple de modele de proiectare

Modele tip sub-sistem care arat gruprile
logice de obiecte n sub-sisteme coerente.

Modele de secven care arat secvena
interaciunilor ntre obiecte.

Modele de stare arat cum obiecte
individuale i schimb starea ca rspuns la
evenimente.
Alte modele, cum ar fi modele use-case,
modele de agregare, modele de
generallizare, etc.

Sub-sisteme n staia meteo
sub sy ste m sub sy ste m
Inte r fa c e Da ta c o lle c tio n
Co m m sCo ntro lle r We a th e rDa ta
Instrum e nt
We a th e rSta tio n Sta tus
sub sy ste m
Instrum e nts
Air
th e rm o m e te r Ra inGa ug e Ane m o m e te r
Gro und Ba ro m e te r Wind Va ne

th e rm o m e te r

Modele de secven

Modelele de secven arat interaciunile
dintre obiecte
Obiectele sunt aranjate orizontal n partea de
sus a diagramei;
Timpul este reprezentat vertical deci modelele
se citesc de sus n jos;
Interaciunile sunt reprezentate de sgei
etichetate; diferite stiluri de sgei reprezint
diferite tipuri de interaciuni;
Un dreptunghi subire n linia de timp a unui
obiect reprezint timpul n care obiectul
controleaz sistemul.

Model de secven pentru colectarea
datelor
:Co m m sCo ntro lle r :We a th e rSta tio n :We a th e rDa ta
re q ue st (re po r t)
a c kno w le d g e ()
re po r t ()
sum m a rise ()
se nd (re po r t)
re ply (re po r t)
a c kno w le d g e ()

Diagrame de stare
Arat cum rspund obiectele la diferite cereri i
tranziiile n starea obiectelor provocate de aceste
cereri
Dac starea obiectului este Shutdown atunci obiectul
poate rspunde la un mesaj de tip Startup();
n starea de ateptare (Waiting) obiectul ateapt alte
mesaje;
Dac primete mesajul reportWeather() atunci trece n
starea Summarising;
La primirea mesajului calibrate() se trece n starea de
calibrare;
Se intr n starea de colectare a datelor atunci cnd se
primete un mesaj de la un cronometru din sistem.

Weather station state diagram
Ope ra tio n c a lib ra te ()

Ca lib ra ting
c a lib ra tio n OK
sta r tup () te st ()
Sh utdo w n Wa iting Te sting
sh utdo w n () tra nsm issio n do ne te st c o m ple te
Tra nsm itting

c lo c k c o lle c tio n
do ne re po r tWe a the r ()
w e a th e r sum m a ry
c o m ple te
Sum m a rising
Co lle c ting

Specificare interfeei obiectelor
Interfeele obiectelor trebuie specificate
astfel nct obiectele i alte componente s
poat fi proiectate n paralel.
Obiectele pot avea mai multe interfee care
sunt puncte de vedere diferite asupra
metodelor oferite de obiecte.
UML folosete diagrame de clase pentru
specificarea interfeelor, dar poate fi folosit i
limbajul Java.

Interfaa obiectului staie meteo
interface WeatherStation {
public void WeatherStation () ;
public void startup () ;

public void startup (Instrument i) ;
public void shutdown () ;

public void shutdown (Instrument i) ;
public void reportWeather ( ) ;
public void test () ;

public void test ( Instrument i ) ;
public void calibrate ( Instrument i) ;
public int getID () ;
} //WeatherStation

Evoluia proiectrii

Ascunderea informaiei n obiecte nseamn
c modificrile asupra unui obiect nu
afecteaz alte obiecte ntr-o manier
impredictibil.
S presupunem c trebuie adugate staiilor
meteo faciliti pentru monitorizarea polurii.
Acestea iau o prob de aer i calculeaz
cantitatea diferiilor poluani din atmosfer.
Citirile de poluare sunt transmise mpreun
cu datele meteo.

Modificri cerute
Adugarea unei clase de obiecte numite

Air quality ca parte din WeatherStation.
Adugarea unei operaii reportAirQuality

la WeatherStation. Modificarea
programului de control pentru colectarea
citirilor de poluare.
Adugarea obiectelor reprezentnd

instrumentele de monitorizare a polurii.

Monitorizarea polurii
We a th e rSta tio n
Air q ua lity
ide ntifie r
NODa ta
re po r tWe a the r () sm o k e Da ta
re po r tAirQua lity () b e nz e ne Da ta
c a lib ra te (instrum e nts)
te st () c o lle c t ()
sta r tup (instrum e nts) sum m a rise ()
shutdo w n (instrum e nts)
Po llutio n m o nito ring instrum e nts
NOm e te r Sm o ke Me te r
Be nze ne Me te r

Concluzii
Proiectarea orientat obiect este o abordare a
proiectrii n care componentele proiectate au operaii
i stare intern.
Obiectele trebuie s aib un constructor i operaii de
inspectare. Ele ofer servicii altor obiecte.
Obiectele pot fi implementate secvenial sau
concurent.
UML (Unified Modeling Language) ofer diferite notaii
pentru definirea diferitelor modele de obiecte.

Concluzii
Diferite modele pot fi realizate n timpul
proiectrii orientate obiect. Acestea includ
modele statice i dinamice de sistem.
Interfeete obiectelor trebuie definite precis
folosind chiar limbaje de programare.
Proiectarea orientat obiect poate simplifica
mult evoluia sistemului.

UML (Unified Modeling
Language)
limbaj unificat de modelare
orientat obiect
Scop
Cunoasterea unui limbaj vizual
orientat obiect, standard de
realizare a aplicatiilor si
sistemelor
ISTORIC
Principalele etape de unificare, ce au condus la UML:
Octombrie 1994: Rumbaugh i se altur lui Booch la firma Rational
Software i ncep unificarea metodei lui Booch cu OMT;
Octombrie 1995: Apare versiunea 0.8 draft a Unified Method; Jacobson
se altur i el lui Rational Software; se ncepe ncorporarea OOSE n UML;
Iunie 1996: apare UML versiunea 0.9, apoi ia natere Consoriul UML;
Ianuarie 1997: UML 1.0 (creat cu contribuia DEC, HP, I-Logix, Intellicorp,
IBM, Microsoft, Oracle .a.) este oferit spre standardizare catre Object
Management Group (OMG), ca raspuns la cererea OMG pentru un limbaj
standard de modelare;
Iulie 1997: Versiunea revizuita UML 1.1 (creat de catre un grup mult largit
de parteneri) este oferit catre OMG pentru standardizare;
14 noiembrie 1997: UML 1.1 este adoptat ca standard de catre OMG;
Mentenana UML este preluat de ctre OMG, care public ulterior reviziile
UML 1.2 (iunie 1998) i UML 1.3 (n toamna lui 1998);
n anul 2000 a aprut versiunea UML 1.4;
n 2001 se public revizia UML 2.0
Principii de baz
Este un limbaj standard pentru scrierea de
schie software
Scopul UML este vizualizarea, specificarea,
construirea i documentarea artefactelor unui
sistem software-intensiv, orientat-obiect.
UML este numai un limbaj, deci este numai o
parte a unei metode de dezvoltare software.
Este independent de proces
Obiective
UML a devenit un standard de modelare recunoscut de catre OMG
(Object Management Group). Standardizarea a avut loc n
noiembrie 1997, iar limbajul a continuat sa fie mbuntit.
UML este limbaj de modelare i nu metodologie. De obicei o
metodologie const, cel puin n principiu, att dintr-un limbaj de
modelare, ct i dintr-un proces de modelare. Limbajul de modelare
este notaia grafic folosit pentru descrierea modelului, iar procesul
este succesiunea de pai ce trebuie urmai pentru a realiza efectiv
modelul.
UML poate fi definit, pe scurt, ca un limbaj de vizualizare,
specificare, construire i documentare a modelelor. Valoarea lui
const n urmatoarele:
- este un standard deschis,
- realizeaz ntreg ciclul de via al dezvoltarii software-ului,
- acoper multe tipuri de aplicaii,
- este bazat pe marea experient a celor care l-au realizat,
- este implementat de multe produse de tip CASE.
Caracteristicile modelrii vizuale
descoper procesele care au loc n cadrul
sistemului, folosind analiza cazurilor de
utilizare (USE CASE)
se constituie ntr-un bun mijloc de
comunicare
simplific/reduce complexitatea sistemului,
definete arhitectura software-ului,
permite reutilizarea componentelor.
UTILIZAREA UML
definirea granitelor sistemului si functiilor lui
majore, folosind cazurile de utilizare si actorii
descrierea cazurilor de utilizare folosind
diagramele de interactiune
reprezentarea structurii statice a sistemului
folosind diagramele de clase
modelarea comportamentului obiectelor cu
ajutorul diagramelor de tranzitie a starilor
reprezentarea arhitecturii fizice a implementarii
cu ajutorul diagramelor de componente si de
amplasare
extinderea functionalitatii cu ajutorul
stereotipurilor
Tipuri de diagrame UML
Analiza
Diagrama cazurilor de utilizare (Use Case Diagram)
Diagrama de activitai (Activity Diagram)
Proiectare
- Structura: Diagrama de clase (Class Diagram)
- Comportamentul:
Diagrama de stari (Statechart Diagram)
Diagrame de interaciuni (Interactions Diagrams)
o Diagrama de secvena (Sequence Diagram)
o Diagrama de colaborare (Collaboration Diagram)
Implementare
Diagrama de componente (Component Diagram)
Diagrama de plasare (Deployment Diagram)
Concepte de baza
Blocurile constructive ale UML
elemente
structurale
comportamentale
de grupare
de adnotare
relatii
diagrame
Regulile care dicteaza modul n care aceste
blocuri pot fi combinate
Mecanismele generale ale UML
Elemente structurale
Sunt substantivele modelelor UML, reprezentnd n cea
mai mare parte componente statice ale modelului
Clasa
Instanta
Interfata
Colaborarea
Cazul de utilizare
Clasa activa
Componenta
Nodul
Clasa
cel mai important bloc constructiv al oricarui
sistem orientat-obiect.
reprezinta o descriere a unui set de obiecte ce
partajeaza aceleasi atribute, operatii, relatii si
semantica, putnd implementa una sau mai multe
interfete
clasele pot include abstractizari ale unor parti din
domeniului problemei precum si implementari ale
solutiei si pot fi folosite pentru a reprezenta
elemente pur conceptuale, elemente software sau
elemente hardware
Elementele constitutive ale unei
clase
Atributele un atribut este o proprietate, cu
nume, a unei clase, descriind o plaja de valori
pe care instanele acelei proprietati le pot lua
Operaiile o operatie este implementarea unui
serviciu ce poate fi solicitat de catre orice obiect
al clasei pentru a-i afecta comportamentul
(o operatie este o abstractizare a unei prelucrari
ce se poate aplica unui obiect, partajata de catre
toate obiectele acelei clase)
Responsabilitile o responsabilitate este o
obligatie a unei clase
Conditiile ndeplinite de o clas
bine structurat
Sa ofere o abstractizare clara a unei entitati ce
apartine vocabularului domeniului problemei sau
al domeniului solutiei;
Sa ncorporeze o multime restrnsa si bine
definita, de responsabilitati;
Sa ofere o separare clara a abstractizarilor si a
implementarilor;
Sa fie inteligibila si simpla, dar n acelasi timp
extensibila si adaptabila
Simbolul clasei
Nume clasa
Atribute
Operatii
Responsabilitati
Instanta
reprezinta o manifestare concreta a unei
abstractizari asupra careia se poate aplica un
set de operatii si care are stare ce stocheaza
efectele operatiilor.
Instantele pot fi :
- concrete reprezinta instante ale unor clase
concrete;
- prototipice reprezinta instante potentiale ale
claselor concrete care sunt subclase ale claselor
abstracte, sau ale claselor concrete care
realizeaza interfete
Interfata
reprezinta o colectie de operatii care
specifica un serviciu al unei clase sau al
unei componente
Simbol:
Nume interfa
Colaborarea
defineste o interactiune; o colaborare este
un ansamblu de elemente ce lucreaza
mpreuna pentru a oferi un comportament
cooperativ mai important dect suma
comportamentelor elementelor
Simbol:
Nume colaborare
Cazul de utilizare
reprezinta o descriere a seturilor de
secvente de actiuni pe care le executa un
sistem, conducnd la un rezultat
observabil ce prezinta importanta pentru
un anumit actor
Simbol:
Nume caz de utilizare
Clasa activa
o clasa ale carei obiecte poseda unul sau
mai multe procese sau fire de executie si
prin urmare pot initia controlul activitatilor
Componenta
o parte fizica, nlocuibila, a unui sistem,
care ofera implementarea unui set de
interfete
Simbol:
Nodul
element fizic care exist la momentul
execuiei i reprezint o resurs de calcul,
are cel puin memorie i adesea capaciti
de procesare
Simbol:
Nume nod
Elemente comportamentale
Sunt partile dinamice ale modelului UML,
reprezentnd comportamentul modelului n
timp si spatiu. Ele sunt verbele modelului.
- Interactiune
- Main cu stri
Interactiune
este un comportament ce cuprinde un set
de mesaje schimbat ntre o multime de
obiecte ntr-un context particular, pentru a
realiza un scop specific. Implica un numar
de alte elemente, incluznd mesaje,
secvente de actiuni si legaturi
- Simbol:
nume
Main cu stri
este un comportament ce specifica
secventa de stari prin care trece un obiect
sau o interactiune n cursul existentei sale,
ca raspuns la evenimente, mpreuna cu
raspunsurile la aceste evenimente
Simbol:
nume
Elemente de grupare
sunt partile organizationale ale modelelor
UML. Exista un singur tip de elemente de
grupare, pachetele.
Un pachet este un mecanism general
pentru organizarea elementelor n grupe.
ntr-un pachet pot fi plasate elemente
structurale, elemente comportamentale si
chiar alte elemente de grupare.
Simbol: Nume pachet
Elemente de adnotare
sunt partile explicative ale modelelor UML.
Exista un singur astfel de tip de element,
nota - un simbol pentru marcarea de
restrictii sau de comentarii atasate unui
element sau a unei colectii de elemente
Simbol:
nume not
Relatii
abstractiuni ce leaga elementele ntre ele.
O relatie este o conexiune ntre elemente
dependentele
generalizarile
asocierile
realizarile
Dependenta
este o relatie semantica ntre doua
elemente n care o schimbare a unui
element (elementul independent) poate
afecta celalalt element (elementul
dependent). Se utilizeaza atunci cnd se
doreste indicarea faptului ca un element
este folosit de un altul
Simbol:
Asocierea
este o relatie structurala care descrie un
set de legaturi, o legatura fiind o
conexiune ntre obiecte
Simbol: 0..1 *
rol rol
Dincolo de forma de baza a asocierilor, se mai folosesc si
urmatoarele notiuni:
Nume - folosit pentru a descrie natura relatiei;
Rol - atunci cnd o clasa participa ntr-o asociere, ea are
un rol specific pe care l joaca n acea relatie;
Multiplicitate - indica numarul de obiecte ce pot fi
conectate prin intermediul unei instante a unei asocieri;
Agregare - este un tip de asociere ce modeleaza o
relatie de tipul are un, ceea ce nseamna ca un obiect
al ntregului are (contine) obiectele partii
Clase i asocieri
Generalizarea
se foloseste pentru a arata existenta unor
relatii de tip parinte/copil. Este o relatie de
specializare n care obiectele elementului
specializat (copil) pot fi substitute pentru
obiecte ale elementului generalizat
(parinte)
Simbol:
Realizarea
este o relatie semantica ntre clasificatori,
unde un clasificator specifica un contract
pe care un alt clasificator garanteaza sa l
execute
Simbol:
Diagrame
sunt prezentari grafice ale unui set de
elemente, cel mai adesea exprimate ca un
graf de noduri (elementele) si arce
(relatiile).
Clasificare
Diagrame structurale
Diagrame comportamentale
Reguli UML
Blocurile constructive UML nu pot fi grupate oricum, n
maniera aleatoare, existnd reguli detaliate pentru
definirea modelelor bine formate;
Un model bine format este unul autoconsistent semantic
si n armonie cu modelele sale nrudite.
Exista reguli semantice pentru nume, domeniul de
reprezentare, vizibilitate, integritate si executie;
Sunt admise si modele mai putin dect bine formate, n
sensul ca se pot admite si modele cu elemente ascunse,
modele incomplete sau modele inconsistente, cel putin
pentru iteratiile preliminare ale procesului de dezvoltare.
Mecanisme generale UML
specificatii
adnotari
diviziuni generale
mecanisme de extensie
stereotip
valoare etichetat
constrngere
Specificatii
pentru fiecare parte a notatiei grafice UML
exista o specificatie ce ofera o descriere
textuala a sintaxei si semanticii acelui bloc
constructiv;
n timp ce notatia grafica UML se foloseste
pentru vizualizarea unui sistem,
specificatiile UML se folosesc pentru
specificarea detaliilor sistemului
Adnotari
Notele sunt cel mai important tip de adnotare. O
nota este un simbol grafic pentru reprezentarea
grafica a constrngerilor sau comentariilor
atasate unui element sau unei colectii de
elemente.
Notele se folosesc numai pentru acele cerinte,
observatii si explicatii care nu pot fi facute n
mod simplu sau inteligibil folosind celelalte
elemente UML;
Simbol:
Diviziuni generale
diviziunea clasa/obiect
o clasa este o abstractie,
un obiect este o manifestare concreta a acelei
abstractii;
separatia interfata/implementare
interfata declara un contract
implementarea reprezinta o realizare concreta
a acelui contract, responsabila pentru
realizarea integrala a semanticii complete a
interfetei
Mecanisme de extensie
un Stereotip extinde vocabularul UML,
permitnd crearea de noi tipuri de blocuri
constructive derivate din cele existente,
dar care sunt specifice unei anumite
probleme;
O valoare etichetata extinde proprietatile
unui bloc constructiv UML, permitnd
crearea de noi informatii n cadrul
specificatiei elementului
O constrngere extinde semantica unui
bloc constructiv UML, permitnd
adaugarea de noi reguli sau modificarea
unora existente
Language)
orientat obiect
Diagrame
sunt prezentari grafice ale unui set de
elemente, cel mai adesea exprimate ca un
graf de noduri (elementele) si arce
(relatiile).
Clasificare
Diagrame de clase
Diagrame de obiecte
Diagrame de componente
Diagrame de amplasare
Diagramele de pachet
Diagrame de cazuri de utilizare
Diagrame de secventa
Diagrame de colaborare
Diagrame de tranzitie a starilor
Diagrame de activitate
Diagrama bine structurata
Este focalizata pe comunicarea unui aspect al
sistemului;
Contine numai acele elemente care sunt
importante pentru ntelegerea acelui aspect;
Furnizeaza detalii consistente cu nivelul sau de
abstractizare (nu expune dect acele parti care
sunt esentiale pentru ntelegere);
Nu este att de redusa nct sa dezinformeze
cititorul asupra elementelor semantice relevante.
DIAGRAME DE CLASE (DC)
contin o multime de clase, interfete si
colaborari, precum si relatiile dintre ele
sunt cele mai folosite diagrame n
modelarea sistemelor orientate obiect
ilustreaza vederea statica de proiectare a
unui sistem
Clas abstract
Clasele template
DIAGRAME DE CLASE (DC)
interfaa
Element ce apare n diagramele de clase
DIAGRAME DE CLASE
atributele i operaiile
Reprezentare:
Sintaxa folosita pentru descrierea atributelor:
nume_atribut : tip_atribut = valoare_initiala
Sintaxa folosita pentru descrierea operatiilor:
Nume_operatie ( lista_argumente ) : tip_returnat
unde lista_argumente reprezinta lista argumentelor
operatiei, fiecare argument fiind descris astfel :
nume_argument : tip_argument =
valoare_implicita.
DIAGRAME DE CLASE
atributele i operaiile
Vizibilitatea atributele si operatiilor unei
clase:
publice ( + ) orice alta clasa poate
folosi proprietatea sau poate invoca
operatia;
protejate ( # ) sunt vizibile numai pentru
descendentii clasei respective;
private ( - ) numai clasa respectiva poate folosi
proprietatea sau operatia.
DIAGRAME DE CLASE
tipuri de operaii
Abstracte sunt operatii incomplete pentru care
clasele copii trebuie sa furnizeze o
implementare (sunt specificate cu caractere
italice);
Frunza ({leaf}) nu pot fi suprascrise;
Polimorfice - sunt specificate, intr-o ierarhie de
clase, cu aceasi semnatura, n diferite puncte
ale ierarhiei. Operatia invocata, n momentul
executiei, este aleasa n functie de tipul
obiectului caruia i apartine.
DIAGRAME DE CLASE
reprezentri utiilizate
DIAGRAME DE CLASE
relaii
Asocieri;
Relaii de generalizare;
Relaii de dependenta;
Relaii de realizare;
DIAGRAME DE CLASE
relaii- asocierea
DIAGRAME DE CLASE
relaii- asocierea - clasa a asocierii
DIAGRAME DE CLASE
relaii- asocierea - agregarea
Simpla este n ntregime conceptuala si
nu face altceva dect sa disting ntre un
ntreg si o parte;
Compoziie semnific faptul ca parile pot
fi create dup obiectul compus, dar o data
create traiesc si sunt distruse odat cu
obiectul compus
DIAGRAME DE CLASE
relaii- asocierea - agregarea
DIAGRAME DE CLASE
relaii- generalizarea
una sau mai multe clase motenesc
structura si comportamentul unei clase
mai generale.
dac o clas motenete structura si

comportamentul mai multor clase avem
de-a face cu motenire multipl
DIAGRAME DE CLASE
Modelarea vocabularului unui sistem implica luarea de
decizii n ce privete abstractizrile care fac parte din
sistemul aflat in construcie si cele care rmn n afara
granielor sistemului. Cu ajutorul diagramelor de clase se
vor specifica aceste abstractizri si responsabilitile lor.
Pentru modelarea vocabularului se procedeaz astfel :
Se identifica acele elemente pe care utilizatorii si implementatorii
le folosesc pentru a descrie problema sau soluia;
Pentru fiecare abstractizare se identifica un set de responsabilitati;
trebuie sa existe o distribuie echilibrata a acestora ntre clase;
Se vor specifica toate atributele si operaiile necesare pentru
ndeplinirea responsabilitilor de ctre fiecare clasa.
DIAGRAME DE CLASE
Pentru modelarea colaborrilor se procedeaz astfel :
Se identifica mecanismul care se dorete sa fie modelat; un
mecanism reprezint anumite funcii sau un anumit
comportament a unei pri a sistemului, care rezulta n urma
interaciunii unui grup de clase, interfee etc.;
Pentru fiecare mecanism se identifica clasele, interfeele, relaiile
etc.;
Folosirea scenariilor pentru a verifica si descoperi elementele
mecanismelor ( se pot descoperi pari uitate ale modelului sau
pari cu o semnificaie greita );
Popularea elementelor cu coninutul lor ( pentru clase se
pornete cu o repartizare echilibrata a responsabilitilor ).
DIAGRAME DE CLASE
exemplu
Se considera cazul unei aplicaii ce permite utilizatorilor
sa comande prin Internet articolele pe care doresc sa le
cumpere. Principalele funcii ale sistemului sunt :
- Administrarea bazei de date cu articolele disponibile.
- Tratarea cererilor clienilor.
Un astfel de sistem consta, n principal, din trei pri :

Serverul de baze de date stocheaz informaii despre
articolele disponibile.
Aplicaia care se executa pe server trateaz cererile venite de
la clieni, interogheaz si actualizeaz baza de date;
Programele client care se executa pe browser-ele clienilor.
DIAGRAME DE CLASE
exemplu
DIAGRAME DE OBIECTE (DO)
Modeleaz instane ale elementelor coninute n diagramele de
clase.
Se folosesc pentru modelarea aspectelor statice ale unui sistem.
Aceasta implica surprinderea unui instantaneu al sistemului.
O diagrama de obiecte surprinde aspectele statice ale unei
interaciuni, constnd din obiecte care interacioneaz, dar fr a
trimite mesaje.
Elementele principale coninute ntr-o diagrama de obiecte sunt
obiectele si legturile. De asemenea, pot conine note si
constrngeri. Se pot folosi pachete si subsisteme pentru gruparea
elementelor.
Fiecare obiect este reprezentat printr-un dreptunghi, care conine
numele obiectului, sau numele si clasa obiectului (separate prin
doua puncte), sau numai numele clasei obiectului (caz n care se
spune despre obiect ca este anonim).
Paii urmai pentru construirea unei diagramelor de
obiecte:
Identificarea mecanismului care se dorete a fi modelat (un
mecanism reprezint anumite funcii sau comportamente ale
unei pari a sistemului, care rezulta n urma interaciunii unui
grup de clase, interfee etc.;
Pentru fiecare mecanism se identifica elementele participante
(clase, interfee etc.);
Se considera un scenariu care folosete acest mecanism; se
considera un anumit moment n timp si se identifica obiectele
care participa la scenariu;
Se reprezint strile (cu valorile atributelor) pentru fiecare obiect,
necesare pentru nelegerea scenariului;
Similar se reprezint legturile ntre obiecte, reprezentnd
instane ale asocierilor.
PACHETE SI DIAGRAME DE
PACHETE
Rol: necesitatea organizrii elementelor n partiii
mai mici
Pachet bine proiectat: grupeaz elemente
apropriate din punct de vedere semantic
Pachetele bine structurate sunt slab cuplate
ntre ele si au un control al accesului la
coninutul lor bine definit
Numele pachetului:
nume simplu sau
nume de cale
PACHETE
Elementele unui pachet:
Clase
Interfete
Componente
Noduri
Colaborari
Cazuri de utilizare
Alte pachete
Relaii ntrepachete:
Import / export
Generalizare
PACHETE- Import / export
daca pachetul A importa pachetul B, atunci elementele
din A vor vedea elementele publice din B. Partea publica
a lui B reprezint exportul pachetului B. Grafic se
reprezint printr-o relaie de dependen stereotipizat
cu stereotipul <<import>> ca n figura urmtoare
PACHETE- Generalizare
Generalizare este asemntoare cu generalizarea
claselor. Pachetele mai specializate motenesc
elementele publice si protejate de la pachetul mai
general. Similar cazului claselor, pachetele mai
specializate pot nlocui pachetele mai generale
PACHETE- exemplu
DIAGRAMA CAZURILOR DE
UTILIZARE
Cazul de utilizare specifica comportamentul sistemului
sau a unei pri din sistem si este o descriere a unui set
de secvene de aciuni, incluznd variante, pe care, un
sistem le executa pentru a produce un rezultat
observabil pentru un actor.
UTILIZARE
Actorul reprezint un set de roluri pe care utilizatorul le
folosete cnd interacioneaz cu cazurile de utilizare.
Un actor reprezint un rol uman, un dispozitiv hardware
sau orice alt sistem.
O instan a unui actor reprezint o interaciune
individuala cu sistemul. Actorii nu fac parte din sistem. Ei
se afla n afara sistemului si pot fi conectai la cazuri de
utilizare prin asocieri.
Fluxul de evenimente descrie comportamentul unui caz
de utilizare
Un caz de utilizare folosete un set de secvene,
descrierea sa fiind separata pe fluxuri alternative.
Fiecare varianta poate fi exprimata n secvene diferite
numite scenarii.
UTILIZARE
Colaborare reprezint societatea elementelor unui caz
de utilizare, incluznd deopotriv structura statica si cea
dinamica
UTILIZARE
Cazurile de utilizare pot fi organizate prin gruparea lor n
pachete, ca n cazul claselor, existnd relaii de
generalizare, de incluziune si de extindere:
Generalizarea cazurilor de utilizare se realizeaz asemntor ca
n cazul claselor, cazul de utilizare "copil" motenind
comportamentul si nelesul cazului de utilizare "printe"; copilul
poate aduga sau suprascrie comportamentul printelui si l
poate substitui n orice loc in care apare acesta.
Incluziunea ntre cazuri de utilizare semnifica faptul ca un caz de
utilizare de baza ncorporeaz comportamentul altui caz de
utilizare, intr-o locaie specificata n cazul de utilizare de baza.
Extinderea ntre cazuri de utilizare specifica faptul ca un caz de
utilizare de baza ncorporeaz comportamentul unui alt caz de
utilizare, ntr-o locaie specificata indirect, prin extinderea cazului
de utilizare.
UTILIZARE
DCU este o diagrama care conine un set de cazuri de utilizare,
actori si relaiile dintre acestea (de dependenta, de generalizare si
de asociere). De asemenea, DCU poate conine restricii si pachete,
folosite pentru a grupa elementele.
UTILIZARE
Alegerea actorilor unei DCU:
Se identifica actorii care nconjoar sistemul, alegnd grupurile
care:
necesita ajutor din partea sistemului pentru a-si ndeplini sarcinile;
sunt necesare pentru a executa funciile sistemului
interacioneaz cu hardware-ul extern sau cu alte produse software
executa funcii secundare pentru administrare si ntreinere
Actorii identici se organizeaz sub forma unei ierarhii folosind
relaii de generalizare si specializare
Acolo unde este necesar, se identifica un stereotip pentru
fiecare tip de actor.
Se populeaz DCU cu aceti actori si se specifica cile de
comunicare de la fiecare actor ctre cazurile de utilizare ale
sistemului.
UTILIZARE
Language)
orientat obiect
DIAGRAMA DE INTERACTIUNE
(DI)
folosita pentru modelarea aspectelor dinamice
ale sistemului
folosita pentru construirea unui sistem executabil
prin inginerie inversa.
este alctuita dintr-un set de obiecte si relaiile
dintre ele, incluznd si mesaje pe care obiectele
i le trimit unul altuia
exist dou tipuri de diagrame de interaciune
diagrama de secven (DS)
diagrama de colaborare (DC).
DIAGRAMA DE SECVEN (DS)
este o diagram de interaciune care subliniaz ordinea
mesajelor n timp
grafic, este o tabela care arata obiectele (aranjate pe
axa ox) si mesajele ordonate n funcie timp (pe axa oy).
Elementele DS:
Linia de via a obiectelor linie verticala care reprezint
existenta unui obiect de-a lungul unei perioade de timp.
Majoritatea obiectelor care apar n DI exista pe toata durata
interaciunii, avnd linia de viata trasata de la vrful diagramei
pn la baza
Punctul de control este un dreptunghi nalt si subire care
indica perioada de timp n care obiectul realizeaz o aciune.
Captul de sus al dreptunghiului este aliniat la nceputul actiunii
iar captul de jos la sfritul aciunii.
Forma generala a unei diagrame de secvena:
Exemplu: DS care descrie un scenariu corespunztor
cazului de utilizare Comanda articole
DIAGRAMA DE COLABORARE
(DC)
este o diagrama de interaciune care subliniaz
organizarea structural a obiectelor care trimit i primesc
mesaje (acestea sunt plasate primele, ca vrfuri ale unui
graf, se traseaz legturile care conecteaz obiecte, ca
arcuri n acest graf, apoi se aduga acestor legturi
mesajele pe care obiectele le primesc sau le trimit)
grafic, este o colecie de vrfuri si arce.
elementele specifice DC:
calea pentru a indica faptul ca un obiect este legat cu un altul
trebuie sa existe o cale ("local", "parameter", "global" sau "self")
numrul de secven - pentru a indica ordinea, mesajul trebuie
prefixat cu un numr ncepnd de la 1 cresctor (se pot
modela mesaje imbricate, astfel: 1 este primul mesaj, 1.1 este
primul mesaj n mesajul 1, 1.2 este al doilea etc.)
(DC)
Forma generala a unei diagrame de colaborare:
(DC)
DC pentru cazul de utilizare Selectare informaii despre evenimente
DIAGRAMA DE ACTIVITATI (DA)
este o schem logic care prezint fluxurile de control
dintre activiti.
este folosit pentru a modela aspectele dinamice ale
sistemului
presupune modelarea unui proces pas cu pas,
modelndu-se fluxul unui obiect care trece din stare n
stare.
grafic, DA este o colecie de vrfuri si arce.
Elementele DA
stri de activitate i stri de aciune
tranziii
obiecte
ramuri
bifurcaii si mbinri
culuare (swimlanes)
Stri de activitate i stri de aciune
sunt stri ale sistemului, fiecare reprezentnd executarea
unei aciuni
reprezentare grafica: n interior se poate scrie orice
expresie
strile de aciune nu pot fi descompuse. Ele sunt atomice
i nu pot fi ntrerupte.
Strile de activitate pot fi descompuse, activitatea putnd
fi reprezentat de alt diagram. Ele nu sunt atomice si
pot fi ntrerupte
Starea de aciune este un caz particular al strii de
activitate. ntre ele exist anumite diferene de notaie:
starea de activitate are pri n plus: aciuni de intrare i
de ieire, precum i specificarea mainii pe care se
desfoar activitatea.
Tranziia reprezint fluxul de control de trecere de la o stare
de activitate sau de aciune complet la urmtoarea stare de
activitate sau de aciune. n UML tranziiile se reprezint printr-
o linie. Fluxul de control trebuie s nceap i s se termine
undevas existe o stare iniiala notata cu i o stare final
Ramura - specific o cale alternativ, bazat pe o expresie

booleana. Ramura este reprezentata prin simbolul Pe
fiecare tranziie care pleac din acest simbol, se plaseaz o
expresie booleana care se evalueaz numai cnd se intr n
ramur.
Bifurcaii i mbinri utilizate cnd se modeleaz fluxuri de

producie sau procese de afaceri i apar fluxuri concurente.
Simbolul utilizat de UML este o bara de sincronizare (o linie
orizontala sau verticala groasa).
Culuare (Swimlanes) - uneori apare necesitatea de a
mparti starile de activitate n grupuri, fiecare grup
reprezentnd o organizatie responsabila cu activitatea
respectiva. n UML aceste grupuri se numesc culuare
deoarece, vizual, fiecare grup este separat de celelalte
grupuri, prin bare verticale groase. Fiecare culuar are un
nume, unic n diagrama. Culuarul reprezinta o entitate
din lumea reala. Fiecare culoar poate fi implementat prin
una sau mai multe clase.
Flux de obiecte (object flow) - obiectele pot fi implicate

n fluxul de control asociat cu diagrama de activitate. Se
poate preciza rolul, starea si atributele unui flux de
obiecte.
DA- Fluxul activitilor cazurilor de utilizare Login / Logout si Comanda articole
DIAGRAME DE TRANZITIE A
STARILOR
diagrama de tranziie a strilor arata o maina de stare
ele sunt utile n modelarea ciclului de viata a unui obiect
pot fi ataate claselor, cazurilor de utilizare sau ntregului sistem, pentru a
vizualiza, specifica si documenta aspectele dinamice ale acestora.
maina cu stri este un comportament care specifica secvena de stri prin
care trece un obiect, pe parcursul vieii sale, ca rspuns la evenimente
starea este o condiie sau o situaie n viata unui obiect, cnd acesta
satisface anumite condiii, realizeaz anumite activiti sau ateapt
anumite evenimente
evenimentul reprezint specificarea unei apariii semnificative care are o
locaie n spaiu si timp
activitatea este o execuie nonatomic n derulare ntr-o maina de stare
aciunea este o operaie atomica, executabila, care duce la schimbarea
unei stri sau returneaz o valoare
diagrama de tranziie conine:
stari simple si compuse
Tranzitii
Evenimente
actiuni
DIAGRAME DE TRANZITIE A
STARILOR
Prile unei stri:
Nume: o stare poate fi si anonima
Aciuni de intrare / ieire, executate la intrarea / ieirea dintr-o
stare
Tranziii interne: realizate fr a cauza o schimbare de stare
Substri: structura imbricata a unei stri implica substri disjuncte
sau concurente
Evenimente amnate: sunt recunoscute ntr-o stare, dar puse ntr-
o coad pentru a fi rezolvate de obiect ntr-o alt stare.
starea iniial indic locul implicit de start pentru o main de stare
sau o substare
starea final indic execuia unei maini de stare sau faptul c
starea de finalizare a fost completat
schimbarea unei stri presupune c a avut loc o tranziie
pn la efectuarea tranziiei obiectul este ntr-o stare sursa
dup ce tranziia are loc obiectul este ntr-o stare destinaie.
DIAGRAME DE TRANZIIE A STRILOR
Prile unei tranziii:

Starea sursa
Eveniment declanator: a crui receptare de ctre
obiect face posibil s aib loc tranziia
Condiii: expresie booleana care este evaluat cnd
are loc tranziia; dac are valoare de adevr, atunci
tranziia poate avea loc
Aciunea: operaie atomic, executabil, care poate
aciona direct asupra obiectului care deine maina de
stri i indirect asupra altor obiecte care sunt vizibile
obiectului
Starea destinaie
DIAGRAME DE TRANZIIE A STRILOR
forma general
DIAGRAME DE TRANZITIE A STARILOR
stri si tranziii avansate
Aciuni de intrare / ieire: se folosesc atunci cnd se dorete ca aceeai aciune sa
aib loc ori de cte ori se intra ntr-o stare / se prsete o stare, indiferent de
tranziia care conduce la acea stare
Tranziii interne: folosite atunci cnd se dorete rezolvarea unor evenimente fr a
prsi starea
Activiti: cnd este ntr-o stare n general obiectul rmne inactiv, ateptnd apariia
unui eveniment. Uneori, aflat ntr-o stare, un obiect va realiza o sarcina si o va
continua pn cnd este ntrerupt de un eveniment. Pentru aceasta se folosete o
tranziie speciala do. Se poate de asemenea specifica o secvena de aciuni (de
exemplu: do/op1(a);op2(b);op3(c)).
Evenimente amnate: n unele situaii de modelare, se dorete recunoaterea unor
evenimente, dar amnarea rspunsului la acestea. Aceasta se specifica prin listarea
unui eveniment cu aciunea speciala defer.
substri
Substarea este o stare imbricata ntr-o alta stare
Starea compusa este o stare care are substari; poate conine
substari secveniale sau concurente
Substari secveniale sau disjuncte Fiind dat un set de stri
secveniale, obiectul se afla n starea compusa si doar ntr-una din
substarile sale la un moment dat. Uneori se dorete modelarea unui
obiect astfel nct sa se memoreze ultima substare care a fost activa
nainte de parasirea strii compuse. Pentru aceasta se folosesc istorii
ale starilor ( history states ). Daca se dorete ca o tranziie din afara
obiectului compus sa activeze ultima substare care a fost activa, atunci
tranziia va fi reprezentata ctre history states.
Substari concurente: specifica doua sau mai multe maini de stare
care se executa n paralel, n contextul obiectului care le include. Date
fiind doua sau mai multe substari concurente la acelai nivel, un obiect
va fi ntr-o stare secveniala din fiecare din strile concurente. O maina
cu stri imbricate concurenta nu are stare iniiala sau finala.
sub stri
O tranziie ce conduce la ieirea dintr-o stare compusa poate avea ca sursa starea compusa
sau o substare a ei
DIAGRAME DE TRANZITIE A STARILOR - exemplu
DIAGRAME DE DESFURARE
(DD)
reprezint un tip de diagrame folosit n modelarea aspectelor
fizice ale unui sistem orientat obiect
diagrama arat configuraia nodurilor de procesare si a
componentelor lor n momentul execuiei aplicaiei.
pentru alocarea componentelor la noduri exist mai multe
variante:
alocarea nu este vizibila (se gsete n specificaia fiecrui nod).
se folosesc relaii de dependenta pentru conectarea
componentelor la nodurile de care aparin.
Se reprezint componentele n nod, ntr-un compartiment
separat.
diagramele de desfurare nu sunt importante numai pentru
vizualizarea, specificarea si documentarea sistemelor
distribuite, client/server, ci i pentru direcionarea sistemelor
executabile prin inginerie direct i invers
DIAGRAME DE DESFURARE
(DD)
DIAGRAME DE DESFURARE (DD)
Diagramele de desfurare pentru un software care interacioneaz
cu dispozitive pe care de obicei nu le direcioneaz sistemul de
operare sau care sunt distribuite fizic pe mai multe procesoare
DIAGRAME DE DESFURARE (DD)
Utilizare:
Pentru modelarea sistemelor cu software
implementat hardware
Pentru modelarea sistemelor client/server
Pentru modelarea sistemelor complet
distribuite
DIAGRAME DE COMPONENTE
(DC)
descriu un set de componente i relaiile dintre ele.
Grafic, reprezint o colecie de noduri i arce
utilizare:
Pentru a modela codul sursa
Pentru a modela produse executabile
Pentru a modela baze de date fizice
Pentru a modela sisteme adaptabile
DIAGRAME DE COMPONENTE
(DC)
Etape i activiti:recomandri
(material opional de studiu)
Modelarea realizrii unui caz de utilizare: poate fi
realizat de una sau mai multe colaborri. Aceasta
presupune urmtorii pai:
identificarea elementelor structurale necesare si suficiente
pentru a exprima semantica cazului de utilizare
exprimarea organizrii acestor elemente structurale n diagrame
de clasa
luarea n considerare a fiecrui scenariu ce reprezint cazul de
utilizare
exprimarea dinamicii acestor scenarii n diagrame de
interaciune
organizarea elementelor structurale i comportamentale ca o
colaborare care va fi conectat la cazul de utilizare prin realizare
Modelarea produselor executabile i a

bibliotecilor
identificarea partiionrii sistemului fizic. Stabilirea
impactului elementelor tehnice, de management al
configuraiei i reutilizrii
modelarea produselor executabile i bibliotecilor sub
forma de componente folosind elementele standard
corespunztoare
modelarea interfeelor semnificative pe care unele
componente le folosesc i altele le realizeaz
modelarea relaiilor dintre produsele executabile,
biblioteci i interfee
Etape si activiti:recomandri
Modelarea fiierelor, tabelelor si

documentelor
se identifica componentele auxiliare
se modeleaz aceste componente
se modeleaz relaiile dintre aceste
componente i alte produse executabile,
biblioteci i interfee din sistem
Modelarea unei interfee de programare a

aplicaiei (API)
se identific semnificaiile majore din punct de vedere
al programrii i se modeleaz fiecare ca o interfa,
colectnd atributele i operaiile
se vizualizeaz acele proprieti ale interfeelor,
importante ntr-un anumit context
se modeleaz realizarea fiecrei API n msura n
care este important pentru a arata configuraia unei
implementri specifice
Modelarea codului sursa

n funcie de restriciile impuse de instrumentele de
dezvoltare, se modeleaz fiierele ce conin detalii ale
elementelor logice, mpreun cu dependenele de
compilare
se includ valori etichet, cum ar fi versiune, autor,
informaia de verificare a intrrilor i ieirilor
pe ct este posibil, gestionarea relaiilor dintre fiiere
va fi efectuat de instrumentele de dezvoltare, UML-ul
folosindu-se doar pentru vizualizare
Modelarea procesoarelor i
dispozitivelor
se identific elementele de calcul ale
implementrii sistemului i se reprezint
fiecare ca un nod
dac elementele reprezint procesoare i
dispozitive generice, ele se reprezint direct,
n caz contrar se folosesc stereotipuri.
se stabilesc atributele i operaiile fiecruia
Modelarea distribuiei componentelor

fiecare component din sistem se aloc unui nod
se stabilesc locaii pentru componente (executabile,
biblioteci)
se stabilete alocarea, n unul din urmtoarele
moduri:
alocarea nu este vizibila, ea se regsete n specificaia
fiecrui nod
folosind relaiile de dependen, se conecteaz fiecare nod
cu componentele corespunztoare
se listeaz componentele dintr-un nod ntr-un compartiment
separat
Modelarea implementrii unei operaii
se identific parametrii, valoarea de retur i alte
obiecte vizibile ale operaiei
dac operaia este simpl se implementeaz direct n
cod, ceea ce poate fi pstrat n spatele modelului, sau
poate fi vizualizat explicit ntr-un nod
daca operaia este complicat din punct de vedere al
algoritmului, se modeleaz realizarea ei folosind o
diagrama de activiti
daca operaia este complex, implementarea se va
reprezenta ca o colaborare. Mai departe, se poate
extinde partea structural i comportamental a
colaborrii, folosind diagrame de clasa i diagrame de
interaciune
Modelarea unui mecanism
se identifica mecanismele majore care
formeaz arhitectura sistemului
se reprezint fiecare mecanism ca o
colaborare
se dezvolt partea de structur i
comportamental pentru fiecare colaborare
Modelarea unui ablon (pattern) de
proiectare
se identific soluia comun pentru problem
i se refer ca mecanism
se modeleaz mecanismul ca o colaborare,
asigurnd aspectele structurale si
comportamentale
se identific elementele ce trebuie legate de
context i se stabilesc ca parametri ai
colaborrii
Modelarea unui ablon (pattern) arhitectural
se stabilete pattern-ul pornind de la o arhitectur
dat
se modeleaz tiparul de lucru ca un pachet stereotip,
ce conine toate elementele necesare i suficiente
pentru a descrie diferite aspecte ale tiparului
se stabilesc clasele care trebuie extinse, operaiile
care trebuie implementate i semnalele care trebuie
avute n vedere
Ingineria Programrii
Testare
Curs 11
Adriana Gheorghie,
adrianaa@infoiasi.ro
Ovidiu Gheorghie,
ogh@infoiasi.ro
IP
11
Sondaj
Ai avea ncredere ntr-o central nuclear complet automatizat?
Ai avea ncredere ntr-un pilot automat complet automatizat?

scris de Dvs. niv?
scris de unul dintre colegii Dvs. ?
Ai avea curajul s scriei un sistem expert pentru diagnosticare?
dar dac ceva merge prost i suntei fcut responsabil?

IP
11
Ct de ru stm?
Tehnicile de vrf actuale nu sunt capabile s
obin programe fr defecte.
Se fac 30 - 85 erori la 1000 linii de cod (81)
Dup testare intensiv: 0.5 3 erori la 1000

linii de cod (86)
IP
11
Cum descoperim defectele?
cu stupoare!
Program rezervare companie aerian: anuna

eronat c locurile cele mai ieftine au fost
vndute.
Eroarea a fost descoperit de manageri, care

au vzut c veniturile pe un trimestru sunt cu
50 milioane $ mai mici!
IP
11
Cnd facem erorile?
36
scriere cod
proiectare
64
IP
11
Validare, verificare
Validare: Construim produsul corect?
(Are we building the right product?)
=>program corect din punctul de vedere al
utilizatorului
Verificare: Construim corect produsul?

(Are we building the product right?)
=>program corect din punctul de vedere al
programatorului
IP
11
Testare
Scop: scoaterea n eviden a defectelor unui
program nainte ca programul s fie livrat.
Test reuit este acela care face programul s

se comporte incorect (evideniaz un defect).
Testarea demonstreaz prezena, i nu

absena, erorilor ntr-un program.
IP
11
Testare model general
Proiecteaz Cazurile de
cazurile de test test
Pregtete Datele
de test
datele de test
Ruleaz programul Rezultatele

cu datele de test testului
Compar rezultatele Rapoarte

pentru cazurile de test de testare
IP
11
Metode de testare
Testare funcional
Testare structural
Testarea la integrare
Testarea interfeelor
Testarea la stress
Testarea orientat obiect
IP
11
Testare funcional (cutie neagr)
Testele sunt derivate din specificaiile

programului sau componentei.
Testerul este preocupat doar de
funcionalitatea, nu i de modul n care este
implementat programul. date care cauzeaz
un comportament anormal
Date de test Ie
Program rezultate care evideniaz

prezena unor erori
Rezultatele testului Oe
IP
11
Testare funcional (2)
Problema esenial: datele de test selectate

s aib o probabilitate mare de a aparine
mulimii Ie.
De multe ori alegerea datelor de test ine de
experiena anterioar a celui care face
testarea (folosete cunotine din domeniul
problemei).
IP
11
Abordare sistematic: datele de intrare se

mpart n clase de echivalen.
Datele din aceeai clas de echivalen au

caracteristici comune => programul va avea
un comportament similar pentru toi membrii
aceleiai clase.
Clasele de echivalen se pot identifica i

pentru rezultatele furnizate de program.
IP
11
Intrri invalide Intrri valide
Program
Ieiri
IP
11
Clasele de echivalen se identific

folosind specificaiile programului.
Odat identificate, datele de test se aleg

din fiecare clas (este indicat s se
testeze graniele i un punct de mijloc).
Dac datele de intrare pot avea dimensiuni

diferite este bine s varieze la fiecare test.
IP
11
Testare funcional exemplu (1)
procedure search(Key:ELEM, T:SEQ of ELEM,
Found:BOOLEAN, L:ELEM_INDEX)
Precondiie:
-- secvena are cel puin un element
T.first()<=T.last()
Postcondiie:
-- elementul este gsit pe poziie indicat de L
(Found and T[L]=Key)
-- elementul nu apare n secven
(not Found and not (exist i, T.first() >= i <= T.last(), T[i]=Key)
Clase de echivalen:
1. Date n care elementul cheie apare n secven.
2. Date n care elementul cheie nu apare n secven.
3. Secvena conine o singur valoare.
4. Secvena conine mai multe valori.
IP
11
Testare funcional exemplu (2)
Cazuri de test
Secvena Element cutat
a) o valoare este n secven
b) o valoare nu este n secven
c) mai multe valori primul element din secven
d) mai multe valori ultimul element din secven
e) mai multe valori elementul din mijloc al secvenei
f) mai multe valori nu este n secven
Date de test
secvena de intrare cheia rezultat ateptat (Found,L))
a) 17 17 true,1
b) 17 0 false, ??
c) 17, 29, 21, 23 17 true, 1
d) 41, 18, 9, 31, 30, 16, 45 45 true, 7
e) 17, 18, 21, 23, 29, 41, 38 23 true, 4
f) 21, 23, 29, 33, 38 25 false, ??
IP
11
Testare structural (cutie alb)
Testele sunt construite innd cont de
implementarea programului i vizeaz
execuia fiecrei instruciuni cel puin o dat.
Se aplic la uniti de program de dimensiuni
mici (subrutin, operaie asociat unui
obiect).
Analiza codului ofer indicaii privind numrul
de teste necesare pentru a avea garania c
toate instruciunile din program (component)
au fost executate cel puin o dat.
IP
11
Testare structural (2)
Schema general:
Date de test
testeaz deriveaz
Codul componentei Rezultate

IP
11
Testare structural exemplu (1)
class Result{
public boolean found;
public int index; Graful execuiei
}
class BinSearch{
public static void search(int key, int[] elemArray, Result r)
{ 1
int first = 0;
int last = elemArray.length-1;
int middle; first>last while first<=last
r.found = false; r.index=-1; 2
while (first<=last) {
middle = (first+last)/2; if (elemArray[middle] == key)
if (elemArray[middle] == key){ 3
r.index = middle;
if (elemArray[middle]<key)
r.found = true;
return; 8 4
} else if (elemArray[middle]<key)
first = middle+1;
else 9 5 6
last = middle-1;
}
7
}//while
}//search
}
IP
11
Testare structural (3)
Punctul de plecare l constituie graful execuiei.
nodurile reprezint decizii (se ignor atribuirile i
instruciunile de intrare/ieire)
muchiile indic fluxul execuiei
Scop: fiecare drum independent din program se
execut cel puin o dat.
Drum independent = drum care conine cel puin o
muchie nou (netestat) din graful execuiei.
Fiecare ramificaie trebuie testat n ambele situaii
(condiie adevrat/fals).
IP
11
Testare structural exemplu (2)
Graful execuiei
Cazuri de test:
1 a) 1, 2, 3, 8, 9
b) 1, 2, 3, 4, 6, 7, 2
first>last while first<=last
2 c) 1, 2, 3, 4, 5, 7, 2
d) 1, 2, 3, 4, 6, 7, 2, 8, 9
if (elemArray[middle] == key)
3
if (elemArray[middle]<key)
8 4
9 5 6
7
IP
11
Testarea la integrare
Problem: localizarea erorilor care apar n
timpul testrii.
Localizarea erorilor este mai uoar n cazul
integrrii incrementale a componentelor.
Iniial ar trebui testat o configuraie minimal
a sistemului, restul componentelor fiind
adugate una cte una.
Strategii de testare:
top-down
bottom-up
IP
11
Testarea interfeelor
Are loc atunci cnd modulele sunt integrate
pentru a crea sisteme mai mari.
Fiecare modul are o interfa utilizat de
celelalte componente ale programului.
Scop: detectarea erorilor care apar la nivelul
interfeelor sau care se datoreaz unor
presupuneri greite legate de interfee.
IP
11
Tipuri de erori
utilizare greit a interfeei (parametri cu un
alt tip sau ntr-o alt ordine dect sunt
specificai n interfa).
nelegerea greit a interfeei (presupuneri
greite legate de ce ar trebui s fac o
component).
Erori de timing (au loc n sistemele n timp
real care folosesc memorie partajat sau
transmitere de mesaje).
IP
11
Testarea la stress
Scop: evideniaz performana i sigurana
sistemului.
Presupune planificarea unei baterii de teste
n care sistemul este suprancrcat.
Se testeaz astfel comportarea sistemului
atunci cnd acesta cedeaz (este important
ca acest lucru s nu cauzeze coruperea
datelor).
IP
11
Testarea orientat obiect
Nivele de testare:
Testarea individual a operaiilor asociate
unui obiect.
Testarea individual a unei clase de obiecte
(secvene de operaii)
Testarea unui cluster de obiecte (scenarii)
Testarea sistemului OO (verificare i validare)
IP
11
V mulumim !
... pentru
atenie
rbdare
Instrumente de tip CASE
Concepte i caracteristici
CASE - Computer Aided Software Engineering -
reprezint colecii de metode, instrumente si
procese destinate ingineriei software asistat de
calculator.
denumire introdus n 1987 de John Manley
pentru a desemna dezvoltarea de software
utiliznd instrumente care s acopere i etapele
de analiz-proiectare i s ofere facilitai pentru
reprezentrile grafice folosite cu precdere de
metodele de analiz i proiectare
Caracteristici suplimentare
s ofere facilitai grafice puternice pentru a descrie i documenta software-ul
s fie integrat, astfel nct s permit transmiterea uoara a datelor ntre
componente
sa stocheze informaiile referitoare la software ntr-o bibliotec
computerizat, permind accesarea acestor informaii de ctre toi membrii
echipei de elaboratori
s poat fi utilizat ca baz pentru automatizarea procesului de producere a
software-ului folosind una sau mai multe metode de analiz i proiectare
s fie reutilizabil pentru dezvoltarea de noi sisteme, aplicaii i programe
s poat fi utilizat pe orice platform hardware, ncepnd cu calculatoare
personale pn la mainframe-uri
s permit realizarea uoara a interfeei cu utilizatorul final i expandarea
interaciunii cu acesta
s asigure dezvoltarea de aplicaii n limbaje de programare evoluate
s asigure software-ul realizat din punct de vedere calitativ.
Importana i avantajele utilizrii
CASE-urilor
scurteaz durata de realizare a proiectelor i de implementare a
aplicaiilor
asigur din punct de vedere calitativ produsul software i cresc
ncrederea utilizatorului n calitatea acestuia
asist realizarea fiecrei etape i deci mbuntesc calitatea
procesului de realizare
dezvoltarea software-ului se face conform unor metodologii care
specific pe lng etapele de dezvoltare, coninutul i ieirile
fiecrei etape, n mod difereniat dup natura produsului sau dup
domeniul su de aplicaie
obinerea de specificaii de definire complete
acurateea specificaiilor de realizare (de proiectare)
obinerea unei ci uor de ntreinut i dezvoltat (n ideea c un
produs software nu este niciodat n mod real terminat, dezvoltarea
sa fiind prelungit de operaiile de mentenan).
Generaii de produse CASE
Generaia I
include facilitai pentru diverse etape ale

ciclului de via tradiional sub form de
instrumente pentru:
planificarea strategic (la nivelul sistemelor
complexe)
etapa de analiz
etapa de proiectare
generare de cod
Generaia I
caracteristici
instrumentele vehiculeaz un numar

mare de date
ofer interfaa grafica pentru utilizator
sunt utilizate n general pe PC
partea de generare de cod se refer la
definirea datelor (ecrane, rapoarte,
definiii, fragmente de cod).
Generaia II
caracteristici
cuprinde aceleai facilitai i n general aceleai tipuri de
instrumente
generarea de cod se realizeaz pe main-frame-uri pe
care exist un generator central de cod care stocheaz
codul generat ntr-un depozit
permit lucrul n echip pentru elaborarea de proiecte
complexe, de dimensiuni mari
asigur facilitai de management al acestor proiecte, att
pentru activitile specifice etapelor ciclului de via la
nivel de proiect, ct i la nivelul ntregii organizaii
elaboratoare de software
acestei generaii i aparin CASE-uri care ofer suport
pentru ntreg ciclul de via, numite i Integrated-CASE
sau I-CASE i care ofer suport pentru realizarea
proiectelor folosind mai multe metode de analiz i
proiectare
Generaia III
caracteristici
Reprezint colecie de produse de tip CASE i
de alte componente integrate care asigur
suportul pentru majoritatea tipurilor de
interaciuni ntre componentele mediului i ntre
utilizator i mediu.
asigur monitorizarea realizrii proiectelor, ct i
realizarea propriu-zis, asigurnd pn la
generarea de cod integral i generarea
automat a documentelor cu posibiliti de
inginerie invers (reverse engineering).
faciliti individuale pe PC
faciliti la nivel de proiect pe LAN
faciliti la nivel de organizaie pe mainframe
Clasificarea i evaluarea
produselor CASE
dup metodele de analiz i proiectare
implementate:
neorientate obiect, bazate pe metodologii de
analiz i proiectare structurat (sau metode
funcii/date);
pur orientate obiect;
mixte - care suport ambele tipuri de
metodologii.
produselor CASE
dup numrul metodelor de analiz i proiectare
implementate:
ofer suport pentru o singur metod de analiz i
proiectare;
ofer suport pentru mai multe metode i n acest caz :
folosete independent mai multe metode;
permite trecerea automat a documentelor realizate pentru o
anumit metod n documente echivalente ale altei metode.
dup modul de acoperire a etapelor ciclului de
via i de realizare a aplicaiilor:
acoper una sau mai multe pri ale ciclului de via;
acoper tot ciclul de via (I-CASE).
produselor CASE
dup codul generat:
nu genereaz cod;
genereaz cod care conine:
numai abloane i cod parial ce trebuie completat i optimizat;
cod integral, executabil pe baza transformrii directe a proiectului.
dup modul de lucru asigurat:
n echip;
n reea.
dup modul n care permite realizarea altor proiecte, sau
sabloane de proiecte
integral;
parial.
permite reverse engineering - actualizarea diagramelor dup
modificri n cod;
permite includerea sa ntr-un mediu integrat de dezvoltare IDE
(Integrat Development Environment).
Exemple de produse CASE
CASE-uri care implementeaz metodologii de ingineria
informaiei integrate:
IEF - Information Engineering Facility
IEW - Information Engineering Workbench
CASE-uri care implementeaz metodologii integrate (MERISE,
SASDM):
EXCELERATOR
TEAMWORK
AMC - DESIGNER
CASE-uri suport pentru ciclul de via, bazate pe metodologii
structurate sau orientate obiect:
SYSTEM-ARHITECT
EASY-CASE
WESTMOUNT
CAYENNE-ObjectTeam
Rational Rose.
CASE-uri neintegrate, suport pentru tehnici i proceduri din
ingineria software la nivel de activitate/sarcin:
ER-Modeler
ABC.
Componente de baz ale unui
produs CASE
editor de diagrame
analizor de structur
depozit central (repository)
generator de cod
instrumente pentru inginerie invers
generator de documentaie
suport pentru ciclul de via
instrument pentru gestiunea proiectului
(management proiect)
interfa utilizator cu browser specializat
Editorul de diagrame
este componenta obligatorie a unui
CASE
permite construirea i modificarea tuturor
tipurilor de diagrame
introducerea informaiilor n editor poate fi
fcut n dou moduri:
de ctre utilizator, prin intermediul unei
interfee
din repository, atunci cnd acesta este
actualizat prin reverse engineering
Condiii ce trebuie satisfcute:
s permit introducerea i modificarea uoar a
tuturor entitilor grafice descrise de metoda de
proiectare;
suprafaa grafic s fie de calitate, s permit operaii
de zoom, de grupare i aliniere a elementelor
diagramei;
s permit tiprirea eficient a documentelor i
paginarea lor, precum i selectarea informaiilor ce
vor fi tiprite;
s dea posibilitatea de a decide entitile ce vor fi
cuprinse ntr-o pagin fr a trunchia informaiile;
s permit construirea automat a unor tipuri
echivalente de diagrame.
Baza de informaii (repository)
este o component obligatorie, care are drept
rol acumularea i stocarea n manier
organizat a tuturor informaiilor
Caracteristici i avantaje:
documentaia de realizare a oricrui proiect, n
totalitatea ei, se gsete n repository, de unde poate
fi tiprit integral sau parial
documentaia finala a produsului software este
realizat pe baza informaiilor despre proiect
coninute n repository
creterea preciziei i a acurateei documentaiei fa
de cazul n care aceasta este realizat pe hrtie,
deoarece sunt detectate erorile, inconsistenele i
omisiunile
asigur lucrul n echip i n reea
Analizorul de structur
este componenta care are drept rol depistarea i
eliminarea unor erori dificil de localizat i tratat n
fazele ulterioare celei de introducere a
informaiilor
are funcia lui de a compara ultimele date
introduse cu cele existente n repository, i de a
semnala:
introducerea n acelai domeniu de vizibilitate
(diagram, dicionar de date, etc.) a dou entiti de
acelai tip, cu acelai nume;
verific dac toate entitile referite sunt definite
semnaleaz relaii de motenire definite circular
verific corectitudinea semantic i sintactic a
adnotrilor formale.
Instrumentele pentru reverse engeneering
(inginerie invers) au drept rol revenirea din
fazele de sfrit ale realizrii aplicaiei n fazele
de nceput, adic actualizarea diagramelor n
raport cu modificrile efectuate n cod.
Generatorul de cod - permite transformarea n
cod, ntr-un anumit limbaj de programare, a
diagramelor realizate n faza de proiectare.
Browser specializat - este instrumentul pentru
vizualizarea informaiilor unei mulimi de entiti
cu structur complex. Permite accesul direct al
utilizatorului la diagramele care descriu
proiectele, coninute n repository, dispunnd de
opiuni de filtrare i cutare.
Generator de documentaie - conine
modele de documente i ofer
utilizatorului posibilitatea de a-i concepe
propriile documente n mod flexibil.
Gestiunea configuraiei - permite
membrilor echipei de dezvoltare s
lucreze n paralel i n acelai timp s
foloseasc informaia coninut n modelul
global pentru a dezvolta orice proiect nou.

Ingineria Programarii PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Ingineria Programarii PDF

Încărcat de

Drepturi de autor:

Formate disponibile

1.

Graful cauz i efect

Identific cerinele care sunt incomplete i ambigue. Aceast msur exploreaz

Lista de cauze: toate combinaiile distincte de intrri;

Un graf cauz-efect este transcrierea formal a specificaiei formulate n

Se construiete o baz de date cu numerele fiierelor nscrise ntr-un index care

Fig. 2 Graful boolean cauz - efect (final)

Acum se poate construi tabelul 1, cu coloanele corespunznd efectelor i liniile

Tabelul 1 Reguli de decizie

Tabelul 2 Teste ale sistemului

Graful cauz i efect este o tehnic matematic ce necesit cunotine de logic

Aceast msur permite analiza cerinelor, eliminarea ambiguitilor i constituie

Verific conformana dintre specificaiile sistemului i cerinele iniiale ale

R1 = nr. de cerine implementate n arhitectura sistemului;

Msura de trasabilitate se calculeaz cu formula:

Cnd toate cerinele software beneficiar sunt acoperite de arhitectura

Este necesar instruirea n interpretarea adecvat a rezultatelor.

Fig. 3 Arhitectura unui sistem de control al traficului (incomplet)

Fig. 4 Sistem de supraveghere trafic (complet)

Acest metric, aplicat fazei de design arhitectural software, poate identifica

Orice limbaj de programare este caracterizat prin:

dei sunt diferite ca semnificaie, din punct de vedere al execuiei i al

Tabelul 1. Metrica HALSTEAD calculat pt. 2 secvene de program

INDICATORUL SECVENA a) SECVENA b)

, dei sunt identice din punct de vedere al metricii HALSTEAD,

Fig. 1 Graf orientat

Fig. 2 Graful asociat unei secvene liniare de program

Pentru un modul obinuit, 10 este complexitatea ideal maxim. Pentru un sistem

Cyclomatic Complexity Risk Evaluation

Prin convenie, nivelul de context asociat structurii liniare este 1. Instruciunea :

Fig. 4 Nivele de context pentru o secven de program

Tabelul 1. Niveluri de context i ponderi asociate arcelor

Arcul (ni, nj) Context Ki Context Kj pi

Tabelul 2. Indicatori ponderai i neponderai

Tip indicatori C sau CMC Ic

I13 Continuare ciclu (nod

Fig. 3 Graful asociat programului

MTTF i , unde MTTFi este un timp mediu pn la defectare estimat ntre

Pentru a ilustra calculul, fie:

Observaie: Timpul se poate referi la timpul de execuie CPU sau calendaristic.

2. Estimarea numrului de defecte rmase (prin seeding)

Estimarea numrului rmas de defecte este:

3. Acoperire test (coverage)

CREATIVITATE PROGRAMATOR CERINE IGNORATE/LIPS

Fig. 1 Acoperire testare

intersecia din fig. 1 reprezint setul de capabiliti cerute de utilizator care

Tabelul 1 Exemplu de msurare a acoperirii testrii

Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 1

Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 2

ntrebri frecvente despre ingineria

Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 3

Economiile TUTUROR rilor dezvoltate depind de

Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 4

Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 5

Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 6

Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 7

Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 8

Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 9

tiina calculatoarelor se ocup cu partea de

Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 10

Ingineria sistemelor se ocup cu toate aspectele

Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 11

Este o mulime de activiti ale cror scop este