Ingineria Programarii

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.
A
ex
nr. de ambiguiti rmase de eliminat ntr!un program;
A
tot
nr. total de ambiguiti identificate.
c. Implementare:
Un graf cauz-efect este transcrierea formal a specificaiei formulate n
limba! natural. Astfel se identific toate specificaiile i se mpart n entiti distincte. "e
analizeaz toate specificaiile pentru a stabili toate cauzele i efectele asociate. "iecare
cauz i fiecare efect sunt identificate printr-un simbol.
#aii parcuri pentru constituirea grafului sunt:
$%& fiecare cauz i efect se reprezint prin c#te un nod care are un numr
unic;
$'& se interconecteaz nodurile cauz i cele efect prin analizarea coninutului
semantic al specificaiei$ transform#ndu-l ntr-un graf boolean. "iecare
cauz i efect pot a%ea dou stri: true i false. &rin folosirea logicii
booleene$ se listeaz toate strile posibile ale cauzelor i se determin n ce
condiii se %a produce fiecare efect'
()* se %or aduga constr#ngerile care descriu acele combinaii de cauze i
efecte care sunt imposibile semantic sau ambiental'
(+* 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.
(sura are expresia:
( )
=
tot
ex
A
A
CE % %)) *
.
(etoda 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 respecti+ i se completeaz acea coloan;
se determin starea celorlalte efecte pentru combinaia de cauze determinat;
+alorile de pe o coloan formeaz un test pentru sistem.
d. Exemplu:
"e construiete o baz de date cu numerele fiierelor nscrise ntr!un index care
identific locaiile tuturor fiierelor. Indexul are %) seciuni.
,n sistem de afiare +a permite utilizatorului s +izualizeze una din cele %)
seciuni ale indexului printr!o comand format dintr!o liter urmat de o cifr.
#rimul caracter {-, .}, unde:
- displa/;
. listare.
Al doilea caracter {), %, 0., 1} identific seciunea din index.
2le ocup primele dou coloane.
-ac primul caracter e greit se tiprete mesa3ul A de eroare, iar pentru al doilea
mesa3ul 4, unde:
A , comanda greit'
- , numr index greit.
5n constituirea grafului cauz ! efect se identific cauzele i efectele astfel:
.auze:
$%& caracterul din coloana % este 6-7.
$'& caracterul din coloana % este 6.7.
$8& caracterul din coloana ' este o cifr.
/fecte:
$9)& este +izualizat seciunea din index.
$9%& este tiprit mesa3ul A.
$9'& este tiprit mesa3ul 4.
Fig. 1 Graful boolean cauz - efect
%
'
8
9%
9)
9'
')
:;
N:<
AN-
N:<
Nodul ') este un nod intermediar ce reprezint rezultatul aplicrii operatorului "A,
exclusi+ nodurilor % i '.
: ambiguitate a specificaiei este dat de +izualizarea seciunii, pentru c nu se
precizeaz dac e +izualizat pe ecran sau tiprit la imprimant atunci c=nd se d o
comand corect.
Aceast ambiguitate se elimin prin redefinirea efectului 9) astfel:
01 A - seciunea din index se %izualizeaz pe ecran.
01 - - seciunea din index se tiprete la imprimant.
>raful cauz ! efect de+ine:
Fig. 2 Graful boolean cauz - efect (final)
Acum se poate construi tabelul %, cu coloanele corespunz=nd efectelor i liniile
cauzelor.
Tabelul 1 Reguli de decizie
2 f e c t e
')
I - .
9)A 9)4 9% 9'
% % % ) %
' % ) % %
') )
8 % % )
Nepermis $?& ? % % % % % %
%
'
8
9%
9)A
9)4
')
:;
N:<
AN-
N:<
9'
AN-
@ a u z e
Aiecare coloan din tabelul % se poate con+erti n mai multe teste ecBi+alente. :
posibilitate ar fi:
Tabelul 2 Teste ale sistemului
Nr. test Intrri ;ezultate scontate
% - 8 "e +izualizeaz seciunea 8 $9) A&
' . 9 "e tiprete seciunea 9 $9) 4&
8 4 C @omand incorect $9%&
D . E Numr index eronat $9'&
e. Instruire:
>raful cauz i efect este o teBnic matematic ce necesit cunotine de logic
boolean.
f. Beneficii:
Aceast msur permite analiza cerinelor, eliminarea ambiguitilor i constituie
o baz pentru dez+oltarea cazurilor de test.
2. 3rasabilitatea cerine
a. Aplicare:
Ferific conformana dintre specificaiile sistemului i cerinele iniiale ale
beneficiarului, aplic=ndu!se n faza incipient a ciclului de %ia.
#re+ederea unei cerine sau adugarea unei specificaii n plus inutil pot s apar
n procesul de detaliere a cerinelor iniiale, c=nd se creaz arBitectura sistemului
softGare.
3rasabilitatea e corect dac toate specificaiile asociate ar4itecturii
sistemului au corespondent n cerinele iniiale ale beneficiarului i reciproc$ dac
toate cerinele se regsesc n ar4itectura sistemului.
b. Primitive:
5
1
, nr. de cerine implementate n ar4itectura sistemului'
5
2
, nr. de cerine iniiale (beneficiar*.
c. Implementare:
(sura de trasabilitate se calculeaz cu formula:
36 , 7 1118 .
d. Interpretare:
.#nd toate cerinele soft9are beneficiar sunt acoperite de ar4itectura
soft9are$ msura de trasabilitate este 1118.
:ac msura de trasabilitate e mai mic de 1118$ atunci unele cerine
iniiale nu au fost incluse n ar4itectura soft9are.
ArBitectura poate, totui, s conin cerine suplimentare celor iniiale. ,nele
dintre acestea pot rezulta ca urmare a unor pai de rafinare, altele din noi cerine adugate
arBitecturii. Astfel de situaii trebuie analizate cu atenie.
e. Instruire:
2ste necesar instruirea n interpretarea adec+at a rezultatelor.
f. Exemplu:
"e consider un sistem de supara+egBere a traficului care trebuie s transmit un
a+ertisment la consola operatorului i s!l tipreasc atunci c=nd traficul n sistem este
ridicat.
5n figura 8, nu se precizeaz tiprirea a+ertismentului, trasabilitatea nefiind deci
complet.
;
'
;
%
H % i <( I %))* J %))*.
Fig. 3 Arhitectura unui siste !e control al traficului (inco"let)
;
%

;
'
5
1

5
2
<rafic intens
A+ertizare
super+izor
"esizare
5n arBitectura din fig. D se remediaz aceast omisiune:
Fig. # $iste !e su"ra%eghere trafic (co"let)
Aici ;
%
;
'
H % i <( K %))* pentru c o cerin adiional, care n!a fost iniial
n arBitectura sistemului, s!a introdus $lu=nd fig. 8 ca reflect=nd ceea ce a cerut
beneficiarul iniial&.
Aceast situaie ar putea fi i o eroare $<( K %))*&.
g. Beneficii:
Acest metric, aplicat fazei de design arBitectural softGare, poate identifica
cerinele beneficiar neimplementate.
<rafic intens
A+ertizare
operator
"esizare
(esa3 la
imprimant
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;
#rogramele sunt formate din instruciuni care sunt scrise !n secvene
f$r$ a lua !n considerare ordinea execuiei;
#rogramele sunt privite omogen f$r$ s$ se in$ seama de prelucr$rile
f$cute%
IPOTEZE DE LUCRU:
& 'u toate c$ tipurile de date !nseamn$ aloc$ri de zone de memorie
diferite toi operaranzii sunt considerai omogeni put(nd fi
contorizai global;
& De"i operatorii !nseamn$ nr% diferit de cicluri ma"in$ vor fi
considerai omogeni "i vor fi a"adar contorizai global;
& ')iar dac$ cuvintele c)eie folosite !n instruciuni executabile
corespund unor secvene de compilare de lungimi diferite vor fi
considerate omogene "i se vor contoriza global%
*ceste ipoteze simplificatoare sunt specifice metricii HALTEAD!
e c"#sider:
#$ + nr% operanzilor distinci;
#% + nr% operatorilor distinci;
,e vor defini relaiile:
# & #$ ' #% unde n este vocabularul folosit !n program;
( & ($ ' (% unde:
($ + nr% total de operanzi care apar !n program;
(% + nr% total de apariii ale operatorilor !n program;
( + lungimea observat$ a programului%
C & #$ l")
%
( #$ ) ' #% l")
%
( #% )* unde ' este complexitatea estimat$
a programului;
+ & ( l")
%
( # ) unde - este volumul programului;
, & (+ #% ($) - (% #$) unde . este claritatea programului;
L & ( % #$) - ( #% ($ ) unde / reprezint$ nivelul de implementare;
D & $ - L unde D este dificultatea%
,e observ$ c$ metrica 0*/,12*D prive"te programul ca un ansamblu
de componente f$r$ a lua !n considerare interdependenele dintre
instruciuni "i modul de execuie a lor%
De exemplu secvenele:
s 3 4; s 3 4;
i3 4; for ( i 35; i6 n; i77 )
x 8 i 9 3 5; :
for ( i 3 5; i 6 n; i77 ) ;8 i 9 3 4;
: z8 i 9 3 i;
x 8 i 9 3 ( i 7< ) = (i7<); x 8 i 9 3 ( i7< ) = (i7<);
s7 3 x8 i 9; s7 3 x8 i 9;

> >
,ecvena a) ,ecvena b)
de"i sunt diferite ca semnificaie din punct de vedere al execuiei "i al
rezultatelor obinute conduc la valori ale metricii 0*/,12*D prezentate
!n tabelul 5%
1abelul 5% Metrica 0*/,12*D calculat$ pt% ? secvene de program
I(DICATORUL EC+E(.A a) EC+E(.A /)
n5 @ @
n? 54 54
A5 ?5 ??
A? ?B ?@
- 5C?%55 ?44%?D
' E?%D@ E?%D@
D 5E 5E%@5
#t% secvena a)
n5 3 :s i x # 0 $ 1>&&&&operanzi distinci;
n? 3 : & 2 3 4 ( ) 5 '' 6 ' >&&&&operatori distinci%
Obs%: 5) 7 8 9i * sunt separatori%
?) 'u toate c$ instruciunile nu sunt comutative metrica 0*/,12*D
nu reflect$ necomutativitatea tocmai de aceea pt% realizarea unor
comparaii reprezentative ea se aplic$ unor programe corecte "i optimale%
De exemplu secvenele:
s3 4; s3 4;
a 3 4; for (i 3 4; i 6 n; i77)
for (i 3 4; i 6 n; i77) :
: a 3 4;
s7 3 x8 i 9; s7 3 x8 i 9;
> >
,ecvena a) ,ecvena b)
de"i sunt identice din punct de vedere al metricii 0*/,12*D
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 repreint o agregare de elemente neomogene (noduri, arce, perechi
de noduri legate prin lanuri)!
De exemplu, pentru graful din fig! "
#ig! " Graf orientat
Numrul de noduri N $ %, numrul de arce M $ &! Perechile de noduri (x", x'), (x(, x'),
(x), x'), (x", x*), (x(, x*), (x), x*), (x+, x*), sunt legate prin lanuri, -n acest ca P $ &!
Numrul ciclomatic asociat grafului din fig! " este .
v(G) = M N +P=7 8 + 7 = 6.
/tructurilor de program le corespund grafuri care au particulariti impuse de caracterul
sec0enial al execuiei instruciunilor! #iecrei structuri de program i se poate ataa un
graf orientat -n care nodurile corespund instruciunilor, iar arcele ordinii de execuie a
instruciunilor! 1n 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 o2ine un graf conex, ce are o singur component (P $ ")!
Numrul ciclomatic se calculea dup formula.
v(G) = M N +!
deoarece a fost adugat grafului iniial un arc suplimentar (ficti0)!
De exemplu, pentru un program format din * instruciuni de afiare care se execut
sec0enial, a03nd asociat graful din fig! (,
#ig! ( Graful asociat unei sec0ene liniare de program

4(

4)

4"
4+ 4'
4*
4&
4%
5( 5) 5+ 5' 5* 5"
numrul ciclomatic este.
v(G) = M N + = " #6 + = $.
5ntuiti0, structurile liniare sunt identificate cu complexiti minime! 6n acest ca,
numrul ciclomatic se asimilea cu o msur de complexitate!
Pentru programul care numr elementele poiti0e, negati0e i nule ale unui masi0
unidimensional, al crui text surs este.
0oid main()
7
int np, nn, n, i, x8"9:$7-), (, &, 9, "", 9, (, +, -", 9;,
5". np$9,
5(. nn$9,
5). n$9,
5+. for(i$9, i<"9, i==)
5'. if(x8i: < 9)
5*. nn==,
else
5&. if(x8i: > 9)
5%. np==,
else
5?. n==,
5"". printf(@An Numarul elementelor negati0e $ BdC, nn),
5"(. printf(@An Numarul elementelor nule $ BdC, n),
5"). printf(@An Numarul elementelor poiti0e $ BdC, np),
;, se asocia graful din fig! ).
%&' avea(
Numrul de noduri. N $ ")
Numrul de arce. M $ "'
Numrul ciclomatic asociat acestui graf.
D(G) $ ME N = ( $ "' -")= ($ +!
Pentru un modul o2inuit, "9 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 modulariare a codului!
Fiteratura de specialitate ofer urmtoarele 0alori.
C)c*&'atic C&'+*e,it) Ri-. /va*0ati&1
"E"9 G simple program, Hithout much risI
""E(9 More complex, moderate risI
("E'9 Jomplex, high risI program
>'9 1ntesta2le program (0erK high risI)
N0'2r0* cic*&'atic 3i 1ive*0* 4e c&1te,t
Prin con0enie, ni0elul de context asociat structurii liniare este "! 5nstruciunea .
if cond /"
else
/(
Lste generatoarea unui nou context, iar sec0enele /" i /( 0or a0ea ni0elul de context
maMorat cu o unitate -n raport cu ni0elul precedent!
Pentru sec0ena de program.
a $ ),
2 $ +,
c $ (,
if (a > 2) min $ 2,
else min $ a,
if (min > c) min $ c,
printf(@An BdC, min), ,graful asociat este dat -n fig! +.
ni0ele de context

) ( " ( )
n" a$)
n( 2$+
n) c$(
n+ if(a > 2)
n*
min$a
n'
min$2
n&
endif
n"9
endif
n?
min$c
n%
if(min > c)
n""
printf
#ig! + Ni0ele de context pentru o sec0en de program
da
da
Grcul care efectuea legtura -ntre un nod a03nd ni0elul de context Ni i un nod
a03nd ni0elul de context NM 0a fi ponderat cu max 7Ni, NM;! /e consider un graf G
asociat programului P a03nd n arce, cu ponderile p
"
, p
(
, !!!, p
n
i m noduri! Numrul
ciclomatic ponderat este.
J $ Op
i
E m =(, unde i $ ", P,n!
5ndicele ciclomatic ponderat este definit prin.
5c $ J Q (n R max7 p
i
; E m = (!
Pentru sec0ena de program considerat, graful din figura de mai sus are "( arce i ""
noduri! Ponderile asociate arcelor sunt date -n ta2elul nr! "!
Tabe*0* $. Nive*0ri 4e c&1te,t 3i +&14eri a-&ciate arce*&r
Arc0* (1i! 15) C&1te,t 6i C&1te,t 65 +
i
(n", n() " " "
(n(, n)) " " "
(n), n+) " " "
(n+, n') " ( (
(n+, n*) " ( (
(n', n&) ( " (
(n*, n&) ( " (
(n&, n%) " " "
(n%, n?) " ( (
(n%, n"9) " " "
(n?, n"9) ( " (
(n"9, n"") " " "
Op
i
"%
J $ "% E "" = ( $ ?!
Numrul ciclomatic calculat dup formula lui McJa2e are 0aloarea.
J
MJ
$ M E N = ( $ "( E "" = ( $ )!
5c $ % Q ( "( R ( E "" = ( ) $ ? Q "'!
/e o2ser0, anali3nd ta2elul (, c ponderea exprim mai 2ine di0ersitatea legturilor
dintre noduri!
Tabe*0* . I14icat&ri +&14era7i 3i 1e+&14era7i
Ti+ i14icat&ri C -a0 C
MC
5c
Neponderat ) "
Ponderat ? ?Q"'
5" np $ 9
5( n $ 9
5) nn $ 9
5+ for
5' if
5* nn==
da
5& if
5% np==
5? n==
Jontinuare ciclu (nod
ficti0)
nu
da
5""
5"(
5")
#ig! ) 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;
t
i
= timpul ntre defectarea (i!" #i i pentru un nivel de severitate dat (i=!, $".
c. Implementare:
%impul mediu pn la defectare (metricul 4" ar trebui folosit pentru estimarea
urmtoarelor k defecte n soft&are. 'l are e(presia)
%impul mediu pn la descoperirea urmtoarelor k defecte (%M'" =
M%%* i
i f
f k
!
, unde M%%*
i
este un timp mediu pn la defectare estimat ntre
defectarea i #i i+! #i se poate calcula folosind orice model soft&are bazat pe timpii ntre
defectri. ,rin estimarea M%%*, se poate estima ct timp de testare va fi necesar pentru a
descoperi toate defectele sau un subset al defectelor reziduale.
d. Interpretare:
-alculele numerice actuale ale estimrii M%%* depind de distribuia aleas de
model pentru M%%*.
e. Consideraii:
.n timpul ciclului de via al dezvoltrii soft&are, 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:
/mplementarea acestui metric cere cunoa#terea aplicrii modelelor soft&are ale
timpilor ntre defectri.
h. Exemplu:
0e folose#te modelul de de-eutroficare Jelinski-Moranda pentru a estima
M%%*i (timpul mediu de defectare ntre defectrile i #i i+!".
M%%*i = , unde)
1 = constant de proporionalitate estimat n model;
NF = numr estimat al defectelor e(istente n program.
%impul mediu estimat pentru a descoperi urmtoarele defecte este)
2
2
2
2
!
1 (3*i"
2 2
2
%M'
i f
f k
!
.
,entru a ilustra calculul, fie)
f = 45, 1 = 5.56; 3* = !55.
%impul mediu, de e(emplu, pentru a descoperi urmtoarele 4 defecte este)
( ) ( ) ( ) ( ) ( ) ( )
TME
i
i
!
5 56 !55
!
5 56 75
!
5 56 89
565
45
4!
. . .
.
Oser!a"ie: Timpul se poate referi la timpul de e#ecu"ie $%& sau calendaristic.
i. Beneficii:
:cest metric se poate reprezenta funcie de k (k = !,4,;, $ 3*" folosind la
aprecierea integritii unui sistem n orice moment dat.
'. (stimarea numrului de defecte rmase )prin seedin*+
a. Aplicare:
3umrul estimat de defecte rmase ntrun program ine de fiabilitatea
programului. 0unt mai multe te<nici de estimare a acestui numr. :ici se propune o
form a plantrii defectelor cu o distribuie omogen.
,cest metric poate fi aplicat oricrei fa-e a ciclului de !ia" soft.are.
-utarea defectelor continu pn cnd se descoper un anumit numr de defecte
nsmnate, pe lng cele indigene.
b. Primitive:
N
/
= numr de defecte =plantate>;
n
/
= numr de defecte =plantate> gsite;
n
F
= numr de defecte indigene gsite;
c. Implementare:
o ec<ip special insereaz 3
0
defecte reprezentative pentru tipul de defecte
indigene a#teptate s e(iste n soft;
ec<ipa de test raporteaz defectele gsite n timpul unei perioade de test
prestabilit. ,recizia estimrii cre#te cu numrul de defecte care au fost
inserate aleator n soft&are. *iecare defect raportat trebuie atribuit unei clase
(indi*en sau inserat" #i totodat se stabile#te dac a mai aprut;
estimarea numrului de defecte indigene pentru o anumit clas este)
3* = , unde )
3* se va lua ca parte ntreag.
'stimarea numrului rmas de defecte este)
2 2
!
1 (3*i"
2 2
2 n
*
3
0
n
0
2
3* rez = 3* n
*
probabilitatea gsirii lui n
*
din 3* defecte indigene #i a lui n
0
din 3
0
defecte
nsmnate, adic pentru a se gsi n
*
+ n
0
defecte n program, este
,
found
= - (3
0
, n
0
"?(3*, n
*
" @ -(3* + 3
0
, n
*
+ n
0
" unde;
-((, A" = (B @ (( A"B AB este combinri de ( luate cte A.
d. Consideraii:
msura depinde de presupunerea c defectele nserate sunt reprezentative
pentru defectele e(istente. .n general, nu toate defectele au posibilitate egal n a
fi descoperite de o procedur de test;
defectele sunt corectate n soft&areul original numai dup ce sa
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:
,resupunem c sau inserat !55 de defecte. .n timpul perioadei de testare, au fost
gsite 65 din cele !55 de defecte plantate #i 4 dintre cele indigene.
:tunci) 3
0
= !55
n
0
= 65
n
*
= 4
NF
n N
n
F S
S
1
]
1

1
]
1

4 !55
65
C
3umr de defecte reziduale) 3* rez = 3* n
*
= C 4 = 4.
Nippon Telep0one and Tele*rap0 au obinut rezultate bune aplicnd metoda de
inserare defecte unui sistem de operare cu !6555 linii de cod.
1. ,coperire test )co!era*e+
a. Aplicare:
Msoar completitudinea procesului de testare din perspecti!a utili-ator 2i
de-!oltator. :re legtur direct cu etapele de dezvoltare, integrare #i testare (pentru
testele de ) unitate, sistem #i acceptare".
b. Primitive:
(!" program)
funcionale (module, segmente, instruciuni, ramificri, ci";
date (clase de date".
(4" cerine)
2
2 2
2 2
cazuri de test;
capaciti funcionale.
c. Implementare:
:coperire test (%-" are e(presia)

%- (D" = ? !55
d. Interpretare:
%- este doar un indicator al desvr#irii unui test. Ee obicei e(ist un
numr infinit de cazuri de test. :cesta poate fi redus semnificativ dac se definesc
logic relaii ec<ivalente referitor la funcii #i date;
.ncrederea n nivelul testrii cre#te prin utilizarea de primitive rafinate) de
e(emplu, acoperirea segment de !55D este mai puternic dect cea a modulului
de !55D.
e. Consideraii:
programul este un set de instruciuni codificate, iar cerinele sunt un set al
capabilitilor dorite de utilizator;
Fig. Acoperire testare
intersecia din fig. ! reprezint setul de capabiliti cerute de utilizator care
sunt implementate;
aria stng reprezint creativitatea programator sau acele zone pentru care sau
luat decizii de implementare necesare funcionrii <ard&areului;
aria dreapt reprezint capabilitile intenionate ale utilizatorului care lipsesc
n implementare intenionat sau nu;
corespunztor acestui model, se procedeaz astfel)
(-apabiliti implementate"
(-apabiliti cerute"
(,rimitive program testate"
(,rimitive program totale"
-'F/3G' /H3IF:%'@J/,0K
-F':%/L/%:%' ,FIHF:M:%IF
,FIHF:M
-'F/3G'
-M%/' :JNK
-M%/'
33':HFK
-M%/' HF/
(:-I,'F/F' EIF/%K"
(!" programului i se asociaz o acti!itate de testare unitate bazat pe cunoa#terea
structurii programului (cunoscut ca 345T( 6O7+ sau pe cea funcional
($8(,9 6O7 T(/T5N:";
(4" cerinelor li se asociaz o activitate de test sistem care, n maOoritatea cazurilor,
presupune o necunoa#tere a implementrii program.
0unt proiectate scenarii de test care s demonstreze operarea corect din
punctul de !edere al utili-atorului.
,rimitivele cerine se cunosc #i ele dau o msur de acoperire test orientat
utilizator (NJ:-P NIQ %'0%/3H".
-ombinarea celor dou activiti duce la ceea ce se c<eam HF:R NIQ
%'0%/3H. %estarea n aceast activitate vizeaz produsul, acoperirea prin test a
programului #i cerinelor.
f! Instruire:
Mtilizatorul ar trebui s neleag baza teoriei de testare.
g!. Exemplu:
,resupunem c toate cerinele sunt implementate.
%abelul ; d coverageul test al unui set de teste n care segmentele sunt
primitivele.
"abelul Exemplu de m#surare a acoperirii test#rii
$cu segmente ca primitive!
Nr. Nume Numr
de
Teste e#ecutate
crt
.
modul se*mente Nr. de in!ocri Nr. de se*mente testate %rocent co!era*e
65
6!
64
6;
6C
66
6S
68
:
N
-
E
'
*
H
T
!88
!6
8
;
6C
6
9
49
!4
4
!C
;C
45
6
!
4
64
!!
C
4
!7
;
9
!C
49.;7
8;.;;
68.!C
SS.S8
;;.;;
S5.55
!55.55
C7.47
TOT,8 11;' 1;< 4=4 1>.?; @
4. Timpul mediu pAn la defectare
a. Aplicare:
0e folose#te pentru a testa un M%%* specificat.
b. Primitive:
M%%* este parametrul de baz cerut de maOoritatea modelelor de fiabilitate
soft&are;
calculul e dependent de precizia nregistrrii timpului de defectare ( ti ", unde
ti este timpul dintre defectrile (i!" #i i;
pentru un mediu de dezvoltare soft&are, se recomand timpul de e(ecuie
-,M, iar pentru mediul operaional timpul calendaristic (mai puin precis".
c. 5mplementare:
se pstreaz istoria defectrilor;
se organizeaz defectele n funcie de comple(itate, severitate sau rata de
reinserie;
se alege un model reprezentativ al procesului de defectare, care se valideaz
cu datele despre defectri pe care leam nregistrat.
c. Interpretare:
I valoare mare a M%%* implic o fiabilitate #i disponibilitate corespunztoare ale
soft&areului.
d. Instruire:
cuno#tine de statistic matematic #i folosire a modelelor de fiabilitate;
calculele pentru maOoritatea modelelor de fiabilitate cer implementarea unor
programe pe calculator.
e. Exemplu:
0e consider trei nivele ale severitii claselor de defectare) 0*!, 0*4 #i 0*;.
*iecare clas de defectare are proprii si timpi ntre defectri)
/F1: !75, S86, ;!6, 4!4, 487, 65;, C;!
/F': C88, !5C7, S76, ;9S
/F1: 79C, !C44.
:tunci o estimare a M%%* este)
M%%*
t
i
k
k
i
!
, pentru fiecare clas, unde)
t
k
= timpii ntre defectri;
i = nr. de defectri din clasa de severitate respectiv.
M%%* 0*!
469C
8
;85 68 . ,
M%%* 0*4
4S5S
C
S6! 6 . ,
MTTF SF ;
4;!S
4
!!67 .
:ceste valori pot fi comparate cu M%%* specificat pentru fiecare clas de
severitate.
,entru c rata de defectare e constant, funcia de distribuie a defectrii poate fi
presupus e(ponenial #i *(t" = ! e(p(t@M%%*", care reprezint probabilitatea
defectrii soft&are n timpul t.
=. 9ata de defectare
a. Aplicare:
,oate fi folosit pentru a indica cre#terea fiabilitii soft&are n funcie de timpul
de testare.
b. Primitive:
t
i
= timpul ntre defectri pentru un anumit nivel de severitate (i = !, 4,$..";
f
i
= numrul de defectri ale unui nivel de severitate n intervalul de timp t.
c. Implementare:
rata de defectare )t+ poate fi estimat din func"ia de fiailitateB 9)t+B care
la rndul ei se poate obine din distriu"ia de proailitate cumulati!B F)t+B
a timpului pn la urmtoarea defectare folosind orice model de cre#tere
fiabilitate, cum ar fi modelul %oisson neomo*en )N4%%+ sau modelul de tip
6aCesian.
Fata de defectare este ) )t+ D
F t
F t
U ( "
( "
B unde 9)t+ D 1 - F)t+.
d. Interpretare:
)t+ o"inut din N4%% depinde numai de timpul t 2i descre2te continuu;
(t" care deriv din modelul lui 8ittle.ood depinde de timpul t #i valoarea
func"iei de cre2tere fiailitate )i+ la defectarea a i a.
-ernd funciei (i" s fie cresctoare, condiia )t
i
+ )t
i
- 1+ poate fi
respectat doar n sens probabilistic, pentru c programatorul poate introduce noi erori n
timpul coreciei unei erori.
e. Consideraii:
Modelul N4%% face supoziiile)
(!" *iecare defect are probabilitate egal de e(punere;
(4" 3r. de defecte detectate n timpul intervalelor destinate de test , t
i
, sunt
independente;
(;" %impul ntre defectrile i! #i i depinde de timpul pn la a (i!" a defectare.
f. Instruire:
programe de calcul pe calculator (pt. parametri #i indicatori";
cunoa#tere a proceselor stoc<astice #i a te<nicilor de optimizare.
g. Exemple:
Misra , un specialist 3:0:, a obinut o funcie valoare medie pentru rata de
defectare testnd peste 5.6 milioane linii cod surs ale unui soft&are folosit n aviaie.
Eup ;7 sptmni de testare ( 4C66 <" au fost estimai parametrii modelului
3T,, pentru categoria de erori maOore)
a = !S;.7!;; b = 5.478 !5
;
Fata de defectare descresctoare are e(presia)
( ) t ab b t t i
i
n
+
_
,
'
e(p
!
pentru t t i
i
n
!
.
8ittle.ood a e(aminat un set de date de !;S timpi de e(ecuie, pulicat de Musa, pentru
a prezice timpii de defectare viitori, utiliznd
( )
( )
t
t i
,t t t i i
+
+!
#i lund pentru (i" o form liniar)
(i" =
!
+
4
i.
,arametrii ,
!
#i
4
sau obinut cu metoda verosimilitii ma(ime bazat pe primele ;6
de observaii)
= !.6!7;
!
= 5.996;
4
= 8.7;C.
-u aceasta, rata de defectare dup defectarea i se poate estima cu formula)
( ) t
t i
+
!6!7
5 996 87;C
.
. .
,
t
i
t t
i + !
(i = !, $.!;S".
h. Beneficii:
scderea ratei de defectare poate fi folosit pentru a arta mbuntirea
fiabilitii soft&are ca un rezultat al folosirii operaionale;
se poate estima timpul necesar atingerii unei inte de fiabilitate
2
Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 1
Introducere n Ingineria Programrii
Obiective
G
De a face o introducere n ingineria
software i de a explica importana ei
G
De a prezenta rspunsuri la ntrebrile
cheie legate de ingineria programrii
G
De a prezenta aspecte etice i
profesionale ce sunt legate de inginerii
software
Cuprins
G
ntrebri frecvente despre ingineria
software
G
Responsabilitate ethic i profesional
Ingineria programrii
G
Economiile !!R"R rilor dezvoltate depind de
software#
G
ot mai multe sisteme sunt controlate de
programe#
G
$ngineria software se ocup cu teorii% metode i
instrumente pentru dezvoltarea software
profesional#
G
&heltuielile legate de software reprezint un
procent semnificativ n toate rile dezvoltate#
Costuri software
G
Costurile software de cele mai multe ori
depesc costurile hardware.
G
Costurile de ntreinere a unui program de obicei
sunt mai mari dect costurile de devoltare.
Pentru sistemele cu o via lung! costurile de
mentenan pot depi de cteva ori costurile
de devoltare.
G
Ingineria programrii se ocup cu devoltarea
eficient a programelor.
"ntrebri frecvente despre ingineria
software
G
Ce este software#ul$
G
Ce este ingineria software$
G
Care este diferena dintre ingineria software i
tiina calculatoarelor$
G
Care este diferena dintre ingineria software i
ingineria sistemelor$
G
Ce este un proces software$
G
Ce este un model al procesului software$
"ntrebri frecvente despre ingineria
software
G
Care sunt costurile n ingineria software$
G
Ce sunt metodele ingineriei software$
G
Ce este C%&' (Computer#%ided &oftware
'ngineering)
G
Care sunt atributele unui software de calitate$
G
Care sunt provocrile eseniale ale ingineriei
software$
Ce este software#ul$
G
Programele de calculator i documentaia legat de ele cum
ar fi cerine! modele de proiectare i manuale de utiliare.
G
Produsele software pot fi devoltate pentru un client
particular sau pentru o pia general.
G
Produsele software pot fi
* +enerice , devoltate pentru a fi vndute unei game largi de
utiliatori (cum ar fi '-cel sau .ord).
* /edicate , devoltate pentru un singur client n conformitate cu
cerinele clientului.
G
&oftware nou poate fi creat prin devoltarea de noi
programe! configurnd sisteme software generice sau
reutilind software e-istent.
Ce este ingineria software$
G
Ingineria software este o disciplin de inginerie
ce se ocup de toate aspectele produciei
software.
G
Inginerii software trebuie s adopte o abordare
sistematic i organiat i s foloseasc
instrumente i tehnici potrivite cu problema de
reolvat! cu constrngerile de devoltare i cu
resursele disponibile.
Care este diferena dintre ingineria software
i tiina calculatoarelor$
G
0tiina calculatoarelor se ocup cu partea de
teorie i fundamente1 ingineria software se ocup
cu prtile practice de devoltare i livrare a
programelor utile.
G
2eoriile tiinei calculatoarelor nu sunt suficiente
pentru ingineria software.
Care este diferena dintre ingineria software
i ingineria sistemelor$
G
Ingineria sistemelor se ocup cu toate aspectele
de devoltare ale sistemelor baate pe calculator
inclund hardware! software i ingineria
proceselor. Ingineria software este parte a
acestui proces ce se ocup cu devoltarea
infrastructurii software! control! aplicaii i bae
de date n sistem.
G
Inginerii de sistem sunt implicai n specificarea
sistemelor! proiectarea arhitecturii! integrare i
instalare.
Ce este un proces software$
G
'ste o mulime de activiti ale cror scop este
devoltarea sau evoluia unui software.
G
%ctivitile generice preente n toate procesele
software sunt3
*
'pecificare , ce ar trebui s fac sistemul i care sunt
constrngerile de devoltare
*
Dezvoltare , producia sistemului software
*
(alidare , 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$
G
'ste o repreentare simplificat a unui proces
software! preentat dintr#o perspectiv specific.
G
'-emple de perspective prin care putem privi un
process
*
Perspectiv .or4flow , secven de activiti1
*
Perspectiv /ata#flow , flu-ul informaiei (de date)1
*
Perspectiv 5ol6aciune , cine ce face.
G
7odele generic de proces
*
.aterfall (cascad)1
*
/evoltare iterativ1
*
/evoltare baat pe componente.
Care sunt costurile n ingineria software$
G
%pro-imativ 89: din costuri sunt costuri de
devoltare! iar ;9: sunt costuri de testare. /ar
pentru software devoltat pentru un client
particular! costurile de evoluie de cele mai multe
ori depesc costurile de devoltare.
G
Costurile varia n funcie de tipul sistemului
devoltat i n funcie de cerinele sistemului mai
ales cele de performan i fiabilitate.
G
/istribuia costurilor depinde mult de modelul de
devoltare folosit.
/istribuia costurilor pe activitate
Wa t e rfa ll m o de l
It e ra tiv e de v e lo pm e nt
Co m po ne nt-b a se d so ftw a re e ng ine e ring
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 e m s
Sy ste m e v o lutio n
1 0 2 0 0 3 0 0 0 0
Sy ste m de v e lo pm e nt
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
2 ! ! 0
" !
1 0 0 0
Spe c ific a tio n De v e lo pm e nt Inte g ra tio n a nd te sting
2 ! ! 0 " ! 1 0 0 0
Spe c ific a tio n Ite ra tiv e de v e lo pm e nt Sy ste m te sting
2 ! ! 0 " ! 1 0 0 0
Costurile de devoltare a unui produs
Spe c ific a tio n De v e lo pm e nt Sy ste m te sting
2 ! ! 0
" !
1 0 0 0
Ce sunt metodele ingineriei software$
G
&unt abordri structurate ale devoltrii software care
includ modele de sistem! notaii! reguli! sfaturi de
proiectare i ghid de proces.
G
/iagrame de model
* /escrieri grafice ale modelului de sistem1
G
5eguli
* Constrngeri aplicate modelelor de sistem1
G
5ecomandri
* &faturi de bun proiectare1
G
+hid de proces
* Ce activiti ar trebui efectuate.
Ce este C%&' (Computer#%ided &oftware
'ngineering)
G
&unt sisteme software care ofer suport pentru
activitile proceselor software.
G
&istemele C%&' sunt deseori folosite pentru a
realia o metodologie de devoltare.
G
<pper#C%&'
*
%plicaii care vin n a=utorul activitilor de nceput ale
procesului de devoltare cum ar fi specificarea
cerinelor! anali i proiectare1
G
>ower#C%&'
*
%plicaii care a=ut activiti ulterioare cum ar fi
programare! depanare i testare.
Care sunt atributele unui software de
calitate$
G
<n software de calitate trebuie s ofere funcionalitatea i
performana cerut de client i s fie mentenabil! fiabil i
acceptat de client.
G
7entenabilitate
* &oftware#ul trebuie s evoluee pentru a fi n pas cu schimbrile1
G
?iabilitate
* &oftware#ul trebuie s fie @de ncredereA1
G
'ficien
* &oftware#ul nu trebuie s abuee de resursele sistemului1
G
%cceptan
* &oftware#ul trebuie s fie acceptat de utiliatorii pentru care a fost
proiectat. %cest lucru nseamn c trebuie s fie uor de neles!
utiliabil i compatibil cu alte sisteme.
Care sunt provocrile eseniale ale
ingineriei software$
G
'terogenitate! promptitudine i ncredere.
G
'terogenitate
*
2ehnicile de devoltare software trebuie s fac fa
platformelor i mediilor de e-ecuie eterogene1
G
Promptitudine
*
2ehnicile de devoltare trebuie s duc la o mai
rapid devoltare a programelor1
G
"ncredere
*
2ehnicile de devoltare trebuie s demonstree c
utiliatorii pot folosi cu ncredere produsul software.
5esponsabiliti profesionale i etice
G
Ingineria software implic mai multe
responsabiliti dect punerea n practic a unor
aptitudini tehnice.
G
Inginerii software trebuie s aib un
comportament onest i etic dac vor s fie
respectai ca profesioniti.
G
Comportamentul etic nseamn mai mult dect a
respecta legea.
'lemente de responsabilitate profesional
G
Confidenialitate
*
2rebuie respectat confidenialitatea anga=ailor i a
clienilor indiferent dac a fost semnat sau nu un
contract de confidenialitate.
G
Competen
*
Bu trebuie preentat greit nivelul de competen.
Bu trebuie acceptat o lucrare care depete
nivelul de competen.
'lemente de responsabilitate profesional
G
Proprietatea intelectual
*
2rebuie avute n vedere legile locale legate de
patente! copCright! etc. 2rebuie de asemnea luate
msuri pentru prote=area proprietilor intelectuale
ale anga=ailor i clienilor.
G
"ntrebuinare iresponsabil a calculatorului
*
%ptitudinile de lucru cu calculatorul nu trebuie
folosite iresponsabil asupra calculatoarelor altor
persoane. ?olosirea iresponsabil varia de la
lucruri relativ triviale (=ucarea unor =ocuri pe
calculatoarele clientului) pn la lucruri e-trem de
serioase (virusarea calculatoarelor).
Concluii
G
Ingineria software este o disciplin de inginerine ce se ocup
cu toate aspecte de producie software.
G
Produsele software constau din programele devoltate i
documentaia corespuntoare. %tributele esentiale ale
produselor software sunt maintainabilitatea! fiabilitatea!
eficiena i utilitatea.
G
Procesul software const din activitile implicate n
devoltarea produselor software. %ctivitile de ba sunt
specificarea software! devoltarea! validarea i evoluia.
G
7etodele sunt moduri organiate de producie software. 'le
includ sugestii pentru procesul ce trebuie urmat! notaii
folosite! reguli ce guvernea descrierile sistemului ce este
produs i sfaturi de proiectare.
Concluii
G
%plicaiile C%&' sunt sisteme software
proiectate s a=ute activitile de rutin din
procesul de devoltare software! cum ar fi
editarea diagramelor! verificarea consistenei lor
i evidena testelor rulate.
G
Inginerii software au responsabiliti profesionale
i sociale care depesc elementele tehnice.
Cerine Software
Obiective
G
De a introduce conceptele de cerine
utilizator i cerine sistem
G
De a descrie cerinele funcionale i ne-
funcionale
G
De a explica cum pot fi organizate
cerinele sotfware ntr-un document de
cerine
Cuprins
G
Cerine funcionale i ne-funcionale
G
Cerine utilizator
G
Cerine de sistem
G
Documentul de cerine software
Ingineria cerinelor
G
ste procesul de stabilire a serviciilor pe
care le dorete clientul de la sistem i
constr!ngerile de operare i dezvoltare"
G
Cerinele sunt descrieri ale serviciilor
sistemului"
Ce este o cerin#$
G
%oate varia de la o fraz# abstract# care descrie
un serviciu sau o constr!ngere de sistem p!n# la
o specificare matematic# detaliat#"
G
&ceast# situaie este inevitabil# deoarece ele au
dou# funcii
'
%ot sta la baza unei licitaii ( deci trebuie s# fie uor
de interpretat)
'
%ot sta la baza unui contract ( deci trebuie definite n
detaliu)
'
&mbele descrieri sunt numite cerine"
&bstractizarea cerinelor *Davis+
Dac o companie dore te s ini ieze dezvoltarea unui proiect software mare , trebuie s
defineasc cerin ele ntr -un mod suficient de abstract ca solu ia s nu fie predefinit .
Cerin ele trebuie scrise astfel nct diferite firme s poate licita pentru con tract, oferind
probabil diferite moduri de a ndeplini cerin ele organiza iei clien t. Odat ce contractul a
fost c tigat, contractorul trebuie s scrie o defini ie a sistemului mult mai detaliat astfel
nct clientul s n eleag i s valideze comportamentul programului. Ambele do cumente
pot fi numite document de cerin e pentru sistem.
,ipuri de cerine
G
Cerine utilizator
'
Sunt fraze n limba- natural plus diagrame ale
serviciilor pe care le ofer# sistemul i constr!ngeri
de operare" le sunt scrise de clieni"
G
Cerine de sistem
'
Sunt structurate ntr-un document cu descrieri
detaliate ale funciilor sistemului. servicii i
constr!ngeri de operare" Definete ceea ce va fi
implementat. deci poate fi parte dintr-un contract"
Definiii i specificaii
1. %rogramul trebuie s# ofere mi-loace de reprezentare i accesare a
1. fiierelor externe create de alte instrumente
1.1 /tilizatorul trebuie s# aib# mi-loace de a defini tipul fiierelor externe
2
1.2 0iecare tip de fiier exterior poate avea un instrument asociat cu care
1.2 poate fi desc1is acel fiier .
1.3 0iecare tip de fiier exterior poate fi reprezentat cu un icon specific
1.2 pe ecran
1.4 ,rebuie oferite mi-loace ca pozele ce reprezint# tipurile de fiiere
1.2 externe s# poat# fi definite de utilizator
1.5 C!nd utilizatorul selecteaz# o poz# ce reprezint# un fiier. efectul
1.2 seleciei este aplicarea instrumentului asociat acelui tip de fiier
1.2asupra fiierului selectat
Definiie de cerin# utilizator
Specificaie de cerin# sistem
Cine citete cerinele$
2anageri ai clientului
/tilizatori finali de sistem
Ingineri ai clientului
2anageri de dezvoltare
&r1iteci de sistem
/tilizatori finali de sistem
Ingineri ai clientului
&r1iteci de sistem
Dezvoltatori software
Ingineri ai clientului *posibil+
&r1iteci de sistem
Dezvoltatori software
Cerine
utilizator
Cerine
sistem
Specificaii de
proiectare
Cerine funcionale i ne-funcionale
G
Cerine funcionale
'
Descrieri ale serviciilor pe care trebuie s# le ofere sistemul.
cum trebuie s# reacioneze i s# se comporte sistemul n
situaii particulare"
G
Cerine ne-funcionale
'
Constr!ngeri asupra serviciilor sau funciilor oferite de
sistem cum ar fi constr!ngeri de timp. constr!ngeri ale
procesului de dezvoltare. standarde. etc"
G
Cerine specifice domeniului problemei
'
Cerine ce provin din mediul de utilizare a sistemului"
Cerine funcionale
G
Descriu funcionalitatea sau serviciile
sistemului"
G
Depind de tipul de software i de tipul de
utilizatori ce vor folosi sistemul"
G
Cerinele funcionale pot fi fraze abstracte
de descriu ceea ce face sistemul. dar ele
pot descrie sistemul n detaliu"
Sistemul 3I4S5S *exemplu+
G
ste un sistem tip bibliotec# ce ofer# o
interfa# unic# la un num#r de baze de
date cu articole din diferite biblioteci"
G
/tilizatorii pot c#uta. aduce i tip#ri aceste
articole pentru studiu personal"
xemple de cerine funcionale
G
/tilizatorul trebuie s# poat# c#uta articole n
toate bazele de date sau ntr-un subset selectat"
G
Sistemul trebuie s# ofere instrumente de
vizualizare potrivite pentru citirea articolelor"
G
0iecare comand# trebuie s# aib# alocat un
identificator unic *O6D67ID+"
Imprecizii ale cerinelor
G
%roblemele apar atunci c!nd cerinele nu sunt
enunate precis"
G
Cerinele ambigue pot fi interpretate diferit de
utilizatori i dezvoltatori"
G
De exemplu termenul 8instrumente de vizualizare
potrivite9
'
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
G
:n principiu. cerinele trebuie s# fie complete i
consistente"
G
Complete
'
,rebuie s# includ# descrieri ale tuturor
facilit#ilor"
G
Consistente
'
;u trebuie s# existe conflicte sau contradicii
n descrierea facilit#ilor sistemului"
G
:n practic#. este imposibil# realizarea unui
document de cerine complete i consistente"
Cerine ne-funcionale
G
&cestea definesc propriet#ile i constr!ngerile sistemului
cum ar fi fiabilitate. timp de r#spuns i cerine de stocare"
Constr!ngerile sunt propriet#i ale componentelor de
stocare de date. reprezent#ri ale sistemului. etc"
G
%ot fi specificate cerine de proces care impun un anumit
sistem C&S. un limba- de programare sau o metod# de
dezvoltare"
G
Cerinele ne-funcionale pot fi mai critice dec!t cele
funcionale" Dac# primele nu sunt ndeplinite. sistemul
este inutilizabil"
Clasificarea cerinelor ne-funcionale
G
Cerine de produs
' Sunt cerine care specific# lucruri pe care produsul trebuie s# le
ndeplineasc# legat de viteza de execuie. fiabilitate. etc"
G
Cerine de organizare
' Cerine care sunt consecine ale politicii i procedurilor
organizaiei cum ar fi standarde de proces folosite. cerine de
implementare. etc"
G
Cerine externe
' Cerine care provin din factori externi sistemului i procesului
de dezvoltare cum ar fi cerine de interoperabilitate. cerine
legislative. etc"
,ipuri de cerine ne-funcionale
Pe r fo r man c e
re q uir e m e n ts
Spac e
r e q uir e m e n ts
Us a b ility
Effic ie n c y
re q uir e me n ts
Re lia b ility
Po rta b ility
re q uir e me n ts
In te r o pe r a b ility
re q uir e m e n ts
Eth ic al
r e q uir e me n ts
Le g is lativ e
re q uir e m e n ts
Im ple m e n ta tio n
re q uir e m e n ts
Stan d ar d s
re q uir e m e n ts
De li ve ry
re q uir e m e n ts
Safe ty
re q uir e m e n ts
Pri vac y
Pro d uc t
Org an is atio n al
re q uir e m e n ts
Ex te rn al
r e q uir e me n ts
o n !fun c tio n al
re q uir e m e n ts
xemple de cerine ne-funcionale
G
Cerine de produs
<"= Interfaa cu utilizatorul pentru sistemul 3I4S5S
trebuie s# fie implementat# ca pagini >,23 simple f#r#
cadre *frames+ sau ?ava applets"
G
Cerine de organizare
@"A"B %rocesul de dezvoltare i documentele rezultate se
vor conforma celor definite n C5DCo-S%-S,&;-@E"
G
Cerine externe
F"G"E Sistemul nu trebuie s# ofere alte informaii personale
legate de clieni n afar# de numele lor"
Cerine i scopuri
G
Cerinele ne-funcionale pot fi foarte greu de exprimat ntr-
un mod precis. iar cerinele imprecise pot fi greu verificate"
G
Scop
' O intenie general# a utilizatorului. cum ar fi uurina n utilizare"
G
Cerin# ne-funcional# verificabil#
' O cerin# ce folosete un sistem de m#sur# pentru a putea fi
obiectiv testat#"
G
Scopurile sunt utile dezvoltatorilor n m#sura n care
cuprind inteniile utilizatorilor de sistem"
xemple
G
Un scop al sistemului
' Sistemul trebuie s# fie uor de utilizat de operatori
experimentai i trebuie organizat astfel nc!t erorile de
utilizare s# fie minimizate"
G
O cerin ne-funcional verificabil
' Operatorii experimentai trebuie s# poat# folosi
funcionalitatea sistemului dup# un total de dou# ore
de nv#are" Dup# aceast# perioad# num#rul mediu al
erorilor f#cute de operatorii experimentai nu trebuie s#
dep#easc# dou# pe zi"
/nit#i de m#sur# pentru cerine
Proprietate Unitate de msur
Viteza Tranzacii/secund procesate
Timp de rspuns
Timp de mprosptare pe ecran
Dimensiune M Bytes
Numr de cipuri ROM/RAM
Uurin de utiizare Timp de n!are
Numru de "erestre de a#utor
$ia%iitate Timpu mediu p&n a eroare
'ro%a%iitatea de indisponi%iitate
Rata de apariie a erorior
Disponi%iitate
Ro%ustee Timp de restart dup eroare
'rocentu de e!enimente ce cauzeaz erori
'ro%a%iitatea de corupere a dateor a erori
'orta%iitate 'rocentu de instruciuni ce depind de mediu int
de impementare
Numru de medii int de impementare

Interaciunea cerinelor
G
Conflictele dintre diferite cerine ne-funcionale
sunt un lucru obinuit n sistemele complexe"
G
Sistem folosit n navete spaiale
'
%entru a minimiza greutatea. num#rul de cipuri
separate din sistem trebuie minimizat"
'
%entru a minimiza consumul de putere. trebuie
folosite cipuri cu consum redus"
'
,otui. 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
G
Descriu caracteristici ale sistemului i facilit#i
care reflect# domeniul specific de lucru al
aplicaiei"
G
le pot fi cerine funcionale. constr!ngeri asupra
altor cerine sau pot defini calcule specifice"
G
Dac# aceste cerine nu sunt ndeplinite. sistemul
poate fi inutilizabil"
Cerine din domeniul aplicaiei 3I4S5S
G
,rebuie s# existe o interfa# utilizator standard
pentru toate bazele de date. interfa# bazat# pe
standardul DA@"EH"
G
Datorit# restriciilor de copIrig1t. 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"
%robleme ale cerinelor din domeniul aplicaiei
G
:nelegerea cerinelor
'
Cerinele sunt exprimate ntr-un limba- specific
domeniului aplicaiei)
'
&cest limba- nu este ntotdeauna neles de inginerii
software ce dezvolt# sistemul"
G
Cerine implicite
'
Specialitii domeniului neleg domeniul at!t de bine
nc!t nu se g!ndesc c# este nevoie s# exprime
explicit aceste cerine"
Cerine utilizator
G
,rebuie s# descrie cerine funcionale sau ne-
funcionale ntr-un mod care s# fie neles de
c#tre utilizatorii sistemului care nu au cunotine
te1nice de detaliu"
G
Cerinele utilizator sunt definite folosind limba-ul
natural. tabele i diagrame. n m#sura n care pot
fi nelese de c#tre toi utilizatorii"
%robleme legate de exprimarea n limba- natural
G
3ipsa de claritate
'
ste greu s# obii precizie f#r# s# faci documentul
dificil de citit"
G
Confuzia cerinelor
'
Cerinele funcionale i cele ne-funcionale tind s# fie
amestecate"
G
&malgamarea cerinelor
'
Diferite cerine pot fi exprimate mpreun#"
Cerine utilizator 3I4S5S
4..5 Sistemul LIBSYS trebuie s ofere un sistem de
contabilitate care s in nregistr ri ale tuturor pl ilor
f cute de utilizatorii sistemului . Managerii sistemului pot
configura acest sistem de contabilitate astfel nct
utilizatorii frecven i s poat beneficia de reduceri .
%robleme ale cerinelor
G
Cerinele includ at!t informaie
conceptual# c!t i de detaliu
G
Cerinele amestec# tipuri diferite de cerine
Sfaturi pentru scrierea cerinelor
G
Inventeaz# un format standard i folosete-l
pentru toate cerinele"
G
0olosete limba-ul ntr-un mod consistent"
0olosete JtrebuieK pentru cerinele obligatorii i
Jar trebuiK pentru cerinele de dorit"
G
Scoate n eviden# p#rile c1eie ale cerinelor"
G
vit# folosirea -argonului informatic"
Cerine de sistem
G
Sunt specificaii mai detaliate ale funcionalit#ii
sistemului. ale serviciilor sau constr!ngerilor"
G
le vor fi baza pentru proiectarea sistemului"
G
%ot fi ncorporate ntr-un contract"
G
Cerinele de sistem pot fi definite sau ilustrate
folosind diferite modele de sistem"
Cerinele i proiectarea
G
:n principiu. cerinele trebuie s# exprime ceea ce
va face sistemul. iar proiectarea trebuie s#
descrie cum va face sistemul aceste lucruri"
G
:n practic#. cerinele i proiectarea sunt
inseparabile
'
O ar1itectur# de sistem poate fi proiectat# pentru a
structura cerinele)
'
Sistemul poate interopera cu alte sisteme care
genereaz# cerine de proiectare)
'
0olosirea unei proiect#ri specifice poate fi o cerin#
din domeniul aplicaiei"
%robleme ale specific#rii n limba- natural
G
&mbiguitate
'
Cititorii i scriitorii de cerine trebuie s# interpreteze
aceleai cuvinte n acelai fel" 3imba-ul natural este
ambiguu. ceea ce face lucrurile dificile"
G
0lexibilitate prea mare
'
&celai lucru poate fi spus n mai multe feluri n
specifiaie"
G
3ipsa modulariz#rii
'
Structurile limba-ului natural nu sunt adecvate pentru
a structura cerinele de sistem"
&lternative la specificaii n limba- natural
Nota ie Descriere
Limbaj natural
structurat
Aceast abordare depinde de definirea unor abloane standard pentru exprimarea
cerin elor.
Limbaje de
descriere a
proiect rii
Aceast abordare folose te limbaje asem n toare cu limbajele de programare , dar
cu facilit i mai abstracte pentru a specifica cerin ele prin definirea unui model
opera ional al sistemului. Aceast abordare nu este pre mult folosit ast zi , cu toate
c poate fi util pentru specifica iile de interfe e.
Nota ii grafice Un limbaj grafic, suplimentat de note de text, folosit pentru a defini cerin ele
func ionale ale sistemului. Ast zi se folosesc descrieri de tip use -case (cazuri de
utilizare) i diagrame de secven .
Specifica ii
matematice
Acestea sunt nota ii bazate pe concepte matematice cum ar fi automate cu st ri
finite. Aceste specifica ii neambigue reduc discut iile dintre client i contractor
legate de func ionalitatea sistemului. Pe de alt parte majoritatea clien ilor nu
n eleg specifica iile formale i au mari rezerve n a le accepta ca i contract.

Specificaii n limba- structurat
G
3ibertatea scriitorului de cerine este limitat# de
un ablon predefinit pentru cerine"
G
,oate cerinele sunt scrise ntr-o manier#
standard"
G
,erminologia folosit# n descrieri poate fi limitat#"
G
&vanta-ul este c# se menine expresivitatea
limba-ului natural. dar este impus un grad de
uniformizare a specificaiilor"
Labloane de specificaii
G
Definirea funciei sau a entit#ii"
G
Descrierea intr#rilor i a provenienei lor"
G
Descrierea ieirilor i a destinaiei lor"
G
Indicarea altor entit#i necesare"
G
%re i post condiii *dac# este necesar+"
G
fecte secundare *laterale+ ale funciei"
Labloane de specificaii
Insulin Pump/Control Software/SRS/3.3.2
Funcie (acueaz doza de insuin) Ni!eu si*ur de za+r
Descriere (acueaz doza de insuin ce tre%uie administrat c&nd ni!eu msurat de za+ este n
zona de si*uran ntre , i - uniti.
Intrri (itirea ni!eu curent de za+r /r012 i precedentee dou citiri /r3 and r41
Surs Ni!eu curent de za+r de a senzor. Ate citiri din memorie.
Ieiri Doza(acuat 5 doza de insuin ce tre%uie administrat
Destinaie Buca principa de contro
Aciune: Doza(acuat este zero dac ni!eu za+ruui este sta%i sau n cdere sau dac ni!eu
este n cretere2 dar rata de cretere scade. Dac ni!eu crete i rata de cretere crete i ea2 atunci
Doza(acuat se o%ine mprind di"erena dintre ni!eu curent a za+ruui i ni!eu precedent a 6 i
rotun#ind rezutatu. Dac rezutatu este rotun#it a zer o atunci Doza(acuat este doza minim ce poate
"i administrat.
Necesit Dou citiri precedente pentru a putea "i cacuat rata modi"icrii ni!euui de za+r.
Pre-condiie Rezer!oru de insuin conine ce puin doza ma7im de insuin..
Post-condiie r3 este nocuit de r42 apoi r4 este nocuit de r0
Efecte-secundare Nici unu

2odele grafice
G
2odelele grafice sunt foarte utile c!nd trebuie s#
ar#i cum se sc1imb# starea sistemului sau c!nd
trebuie specificate secvene de aciuni"
Diagrame de secven#
G
&rat# secvena evenimentelor care apar n timpul
unei interaciuni a utilizatorului cu sistemul"
G
Se citesc de sus n -os pentru a nelege ordinea
n care apar aciunile"
G
Scoaterea banilor dintr-un &,2
'
Malidarea cardului)
'
%relucrarea cerinei)
'
Completarea tranzaciei"
Diagram# de secven# pentru scoaterea
banilor dintr-un &,2
ATM Database
Card
Card number
Card OK
PIN request
PIN
Option menu
<<exception>>
invalid card
Withdraw request
Amount request
Amount
Balance request
Balance
<<exception>>
insufficient cash
Debit (amount)
Debit response
Card
Card removed
Cash
Cash removed
Receipt
Validate card
Handle request
Complete
transaction
Documentul de cerine
G
Documentul de cerine este exprimarea oficial# a
ceea ce se cere de la dezvoltatorii sistemului"
G
,rebuie s# includ# at!t definiii ale cerinelor
utilizator c!t i specificaii ale cerinelor de
sistem"
G
;/ este un document de proiectare" %e c!t este
posibil. trebuie s# exprime C trebuie s# fac#
sistemul i nu C/2 trebuie s# fac#
/tilizatorii documentului de cerine
Use the requirements to
develop validation tests for
the system
Use the requirements
doument to plan a !id for
the system and to plan the
system development proess
Use the requirements to
understand what system is to
!e developed
System test
en"ineers
#ana"ers
System
en"ineers
Speify the requirements and
read them to he$ that they
meet their needs. %hey
speify han"es to the
requirements
System
ustomers
Use the requirements to help
understand the system and
the relationships !etween its
parts
System
maintenane
en"ineers
Standardul I pentru cerine
G
Definete o structur# generic# pentru
documentul de cerine ce trebuie creat pentru un
sistem specific"
'
Introducere"
'
Descriere general#"
'
Cerine specifice"
'
&pendice"
'
Index"
Structur# propus# pentru documentul de cerine
G
%refa#
G
Introducere
G
Nlosar
G
Definirea cerinelor utilizator
G
&r1itectura sistemului
G
Specificarea cerinelor de sistem
G
2odele de sistem
G
voluia sistemului
G
&pendice
G
Index
Concluzii
G
Cerinele exprim# ceea ce trebuie s# fac# sistemul i
definete constr!ngerile asupra oper#rii sau
implement#rii"
G
Cerinele funcionale exprim# serviciile pe care le va oferi
sistemul"
G
Cerinele ne-funcionale constr!ng sistemul sau procesul
de dezvoltare"
G
Cerinele utilizator sunt exprim#ri de nivel nalt a ceea ce
trebuie s# fac# sistemul" Cerinele utilizator trebuie scrise
n limba- natural. eventual folosind tabele i diagrame"
Concluzii
G
Cerinele de sistem trebuie s# descrie funciile
oferite de sistem"
G
/n document de cerine software este o
exprimare oficial# a cerinelor sistemului"
G
Standardul I 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 su! denumirea de "ingineria software-ului# $software engineering%.
&impozioanele i conferinele internaionale ce au a'ut loc dup ()*+, a'nd ca tematic
calitatea software-ului, ca i cercetrile i e,perimentrile fcute, au relevat !"#le$%tatea ae&tu%
'!"en%u( #reu" )% "ult%tu'%nea 'e #r!*le"e are a#ar le+at 'e &#e%,%area( real%-area(
".&urarea )% evaluarea al%t./%% &!,t0are1ulu% #e ntre+ul %lu 'e v%a/. 2a&%+urarea al%t./%%
&!,t0are3.
-&O $Organizaia -nternaional de &tandardizare% i -./ $/omisia .lectrote0nic -nternaional%
alctuiesc sistemul specializat n ceea ce pri'ete standardizarea internaional.
Organismele naionale care sunt mem!re ale -&O sau -./, iau parte la ela!orarea
standardelor internaionale prin intermediul comitetelor te0nice desemnate de organizaia respecti',
n scopul a!ordrii unor domenii specifice ale acti'itii te0nice.
Alte organizaii internaionale, gu'ernamentale i negu'ernamentale, n cola!orare cu -&O i
-./, iau parte, de asemenea, la acti'itatea aceasta.
4n '!"en%ul tehnologiei informaiei ISO )% IEC au reat un !"%tet te5n% !"un(
ISO6IEC 7TC1.
1roiectele &tandardelor -nternaionale care sunt adoptate de acest comitet te0nic comun sunt
trimise organismelor naionale care, n urma studiului efectuat, i e,prim 'otul 'iza'i de un anumit
proiect de standard.
Adoptarea i pu!licarea ca standard internaional impun adeziunea a unui procent de "%n%"
89: '%n nu".rul !r+an%&"el!r na/%!nale are )%1au e$#r%"at v!tul.
1e msur ce numrul i importana aplicaiilor software au crescut, de asemenea a crescut
i cerina de calitate pe care tre!uie s o ai! n 'edere orice organizaie $firm% care
dez'olt i comercializeaz produse software, ea reprezentnd ade'rata carte de 'izit a respecti'ei
instituii, a crei transparen, recunoatere i certificare permit competiti'itatea i prosperitatea
ei .
Pe #lan "!n'%al( eret.r%le )% real%-.r%le v%-;n' al%tatea &!,t0are &unt na%ntate( at;t
n "e'%ul un%ver&%tar ;t )% el %n'u&tr%al. Ele au ,!&t '%na"%-ate 'at!r%t. &#!r%r%% !nuren/e%
%nterna/%!nale( &5%"*.r%l!r #r!,un'e n te5n!l!+%a 'e ela*!rare a &!,t0are1ulu%( er%n/el!r
n!% )% !"#le$e ale l%en/%l!r )% 'e a'eren/a la &tan'ar'e 2'e e$.< ISO 91263.
/ompanii mari, care 'nd produse din ramura te0nologiei informaiei, cum ar fi2 3icrosoft,
-43, 5ewlett-1ac6ard, 7erilog-8rana, Datamat--talia i-au ela!orat strategii pe termen lung pentru
conducerea calitii glo!ale, a'nd un rol primordial acti'itile manageriale i de msurare a calitii
software-ului pe ntreg ciclul de 'ia.
Totui, rezultatele o!inute de acestea nu sunt generalizate i utilizate pe scar larg, fie
datorit faptului c unele firme nu-i fac pu!lice strategiile proprii de o!inere i monitorizare a
calitii produselor software li'rate, fie graie costurilor financiare mari care au fcut ca numai
organizaiile mari, care au resurse !neti su!staniale, s !eneficieze de implementarea lor n scopul
meninerii competiti'itii i a asigurrii unui a'anta9 pe piaa concurenial de produse i ser'icii din
ramura te0nologiei informaiei.
Pe #lan %ntern( al%tatea &!,t0are 2&au arater%&t%% ale a&%+ur.r%% e%3 a ,!&t &tu'%at. 'e
&#e%al%)t% '%n entre 'e eretare 2ICI3( "e'%%le un%ver&%tare 2AT=( UPB( ASE3( ;t )% 'e
!r+an%-a/%% %n'u&tr%ale.
(
&-a acordat o atenie deose!it terminologiei i aspectelor de ordin conceptual din domeniul
calitii software, prelundu-se i adaptndu-se rezultate ale firmelor de prestigiu n domeniu,
pu!licate n re'iste i cri de specialitate.
Re-ultatele eret.r%l!r )% e$#er%"ent.r%l!r ntre#r%n&e n "e'%ul un%ver&%tar )%
%n'u&tr%al au ,!&t !nret%-ate #r%n #u*l%area a #e&te >? 'e lur.r% 'e &#e%al%tate( n
#er%!a'a 19821199> .
O atenie aparte a fost acordat fia!ilitii software-ului, studii i e,perimentri fiind
ntreprinse n cadrul -/- i instituiilor de n'mnt superior $A&., :14, AT3%, drept urmare se
poate aprecia c s-a format un grup de specialiti care posed cunotine te0nice i care au acumulat
e,perien n domeniu pe !aza e,perimentelor i studiilor de caz ntreprinse.
@u &e #!t &#une #rea "ulte lurur% #!-%t%ve n eea e #r%ve)te &!%et./%le are &e !u#.
u real%-area )% !"er%al%-area #r!'u&el!r '%n '!"en%ul te5n!l!+%e% %n,!r"a/%e%( un'e
at%v%t./%le 'e !n'uere )% a&%+urare a al%t./%% &!,t0are1ulu% &unt ,!arte &la* e$#r%"ate.
Ceret.r%le '%n '!"en%ul %n+%ner%e% &!,t0are1ulu% a*!r'ea-. %"#l%%t )% e$#l%%t
'!"en%ul al%t./%% &!,t0are1ulu%.
Tratarea %"#l%%t. a calitii se refer la metode, te0nici i instrumente de realizare $analiz,
proiectare, programare% care s ai! ca o!iecti' final o!inerea de software cu un ni'el mare de
calitate.
;elul specialitilor este de a ela!ora i implementa te0nologii pentru asigurarea i
m!untirea calitii software.
A!ordarea e$#l%%t. 'izeaz cercetarea direct $nemi9locit% a calitii, a'nd ca o!iecti'e
principale2
definirea terminologiei i a noiunilor principale ale calitii software-ului<
sta!ilirea i clasificarea caracteristicilor de calitate<
construirea metodelor de specificare, msurare, estimare i e'aluare a calitii
software-ului<
ela!orarea listei de indicatori ai calitii software-ului.
-mportana standardelor ce descriu calitatea $de e,. seria de standarde -&O )===% rezult din
faptul c standardele -&O au fost preluate de un numr mare de organisme de standardizare naionale
i regionale.
:nele organizaii de standardizare folosesc standardele -&O fr a le "!'%,%a( altele au
introdus sisteme proprii de numerotare, te,tul fiind acelai cu cel al standardelor -&O.
&unt multe organizaii care produc standarde n &:A i alte ri.
>n industria de aprare a'em 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 $-nstitute for .lectrical on
.ngineers%, AST= $T0e American &ociet? for Testing and 3aterials%, UL $:nderwriters
@a!oratories% i SAE $&ociet? for Automati'e .ngineers%.
4n eea e #r%ve)te ,%a*%l%tatea( a una '%ntre #r%n%#alele arater%&t%% 'e al%tate
&!,t0are( ea a ,!&t a*!r'at. %n'%ret( #r%n &tan'ar'ele 'e a&%+urare a al%t./%% &!,t0are n
an&a"*lu 2ISO 9???( ISO 9126( )% altele3 &au '%ret( #r%n &tan'ar'e are v%-au #r!*le"at%a
'e,%n%r%% ter"%n!l!+%e%( ".&ur.r%% )% evalu.r%% ,%a*%l%t./%% &!,t0are #e ntre+ %lul 'e v%a/.(
&tan'ar'e #u*l%ate at;t 'e ISO6IEC( ;t )% 'e alte !r+an%&"e )% !r+an%-a/%% %nterna/%!nale.
3ai 9os se propune o list cu unele dintre standardele de fia!ilitate $plus alte standarde la care
se fac referine% cunoscute i e,istente pe plan mondial, dar i n ara noastr i pe care autorul le-a
putut consulta prin intermediul -A& $-nstitutul Aomn de &tandarde%2
@ u "e & t a n ' a r '
T % t l u
AN&-B-... std. CD)-()+EFGGGG+EH -... &tandard Ilossar? of &oftware
.ngineering Terminolog?.
D
AN&-B-... std. CE=-()+JFGGGG+JH -... &tandard for &oftware Kualit?
Assurance 1lans.
AN&-B-... std. (=(D-()+*FGGGG+*H -... &tandard for &oftware
7erification and 7alidation 1lans.
-&O +J=D-())JFGGGa)JH 3anagement and Assurance of Lualit? -
'oca!ular?.
@ u "e & t a n ' a r ' T % t l u
-... std. )+D.(-()++FGGGa++H -... &tandard Dictionar? of 3easures
to 1roduce Aelia!le &oftware.
-... std. )+D.D-()+)FGGGa+)H -... Iuide for t0e :se of &tandard
Dictionar? of 3easures to 1roduce
Aelia!le &oftware $)+D.( - ()++%.
DD ()+2())(FGGG!)(H
$standard !ritanic%
Iuide to Assessment of Aelia!ilit? of
&?stems /ontaining &oftware.
4& MC*=21art =2()+MFGGGa+MH
$standard !ritanic%
-ntroductor? Iuide to Aelia!ilit?.
4& MC*=21art (2()+MFGGG!+MH
$standard !ritanic%
Iuide to Aelia!ilit? and 3aintaina!ilit?
1rogramme 3anagement.
4& MC*=21art *2())(FGGGa)(H
$standard !ritanic, identic cu -./ (=(J2()+)%
Iuides to 1rogrammes for Aelia!ilit?
Irowt0.
-&O +)E=-()+CFGGGa+CH Ieneral 1rinciples on Aelia!ilit? for
&tructures.
@ist of .Lui'alent Terms.
:T. /D=-E(C :2())=FGGGa)=H
$standard 8rana%
1rogrammes de /roisance le 8ia!ilitN.
G1 G*=-M==2()++FGGG!++H
$standard 8rana%
Terminologie relati'e O la 8ia!ilitN -
3aintena!ilitN-Disponi!ilitN.
/reterea continu a importanei acordate fia!ilitii software-ului de ctre specialiti se
e,plic prin ela!orarea de noi standarde de fia!ilitate $un standard A-AA pentru fia!ilitatea software
a fost apro!at n ())EFGGGG)EH i alte standarde -... sunt su! dez'oltare% i prin crearea unei noi
discipline-&oftware Aea!ilit? .ngineering $&A.%.
-ngineria fia!ilitii software se maturizeaz prin e,tinderea standardelor i prin
promo'area lor.
/reterea !"un%t./%% de cercetare n &A. este de apro,imati' EMP pe an, fapt ce e,plic importana
acordat acestei discipline aflat n ascensiune.
2.2 Fiabilitatea, o caracteristic a calitii software-ului
reflectat de standardele internaionale I! "### i I! "12$
2.2.1 %aracteristicile de calitate software
C!nven/%!nal( %n+%ner%% &!,t0are au !n&%'erat . re&#!n&a*%l%tatea l!r &unt re-ultatele
te5n%e ale ,urn%-.r%% unu% #r!'u& &!,t0are are e$eut. n%)te ,un/%% !n,!r" &#e%,%a/%%l!r.
/el mai important lucru este s se o!in calitatea prin controlarea metodelor de producere i
nu a produsului nsui.
E
8olosirea te0nicilor noi e posi!il s creasc feza!ilitatea i s reduc riscurile implicate n
o!inerea sigur a calitii dorite.
De e,emplu, metodele formale pot duce la realizarea unor ni'ele nalte de fia!ilitate, iar
fi,area de prototipuri poate crete ansa atingerii ni'elelor dorite n utilizarea produsului.
La ela*!rarea #r!'u&el!r &!,t0are( arater%&t%%le 'e al%tate &unt #r%v%te '%,eren/%at.
Se #!ate #une aent la un "!"ent 'at #e real%-area la !te &u#er%!are a une% anu"%te
arater%&t%% 'e al%tate.
Celelalte arater%&t%% v!r avea n%velur% %n,luen/ate '%ret 'e arater%&t%a #r%!r%tar.(
are tre*u%e "en/%nut. ntre l%"%te are nu a,etea-. n%velul +l!*al al #er,!r"an/e%
#r!'u&ulu%.
Pr!+ra"ele &unt ela*!rate a&t,el n;t &. r.&#un'. er%n/el!r 'e #relurare ale
*ene,%%ar%l!r( 'ar n aela)% t%"# &. re,lete #!&%*%l%t./%le "ater%ale )% ,%nan%are ale
real%-at!rulu% )% ale *ene,%%ar%l!r. Da. la #r!%etare #r%"ea-. ! anu"%t. arater%&t%.( !'at.
u treerea la n!% ver&%un% ale #r!+ra"ulu%( &e #!ate "!'%,%a %erar5%-area arater%&t%%l!r n
ra#!rt u r%ter%ul %"#!rtan/e%.
/aracteristicile i atri!utele de calitate ale produselor program formeaz un sistem comple,,
dinamic< creterea ni'elului unei anumite caracteristici influeneaz poziti' ni'elul altor caracteristici,
dar pot e,ista i situaii conflictuale.
De aceea tre!uie asigurat ec0ili!rul necesar ncadrrii produselor program ntre limitele
admise ale performanei, prin utilizarea te0nicilor de analiz - proiectare - programare adec'ate, dup
ce s-au e'aluat efectele lor.
2.2.2 %lasificarea caracteristicilor de calitate
.,ist mai multe criterii de clasificare a lor2
,a-a %lulu% 'e v%a/. a #r!'u&ulu% #r!+ra" n are &e #un n ev%'en/.
arater%&t%%2
e,ist caracteristici de calitate e'ideniate n etapele de ela!orare a produsului, iar alte
caracteristici apar n etapele de efectuare de modificri n structura produsului pentru a-i
asigura meninerea n funciune.
&#e%,%%tatea #r!'u&ulu% #r!+ra" are %"#une a ! arater%&t%. &. ,%e
#r%!r%tar.( %ar elelalte arater%&t%% &eun'areA
#er&!ana are ela*!rea-.( ut%l%-ea-. &au "en/%ne n ut%l%-are #r!'u&ul &!,t0are(
are #!ate ev%'en/%a #re-en/a &au a*&en/a une% arater%&t%% 'e al%tate.
/ercetrile specialitilor au condus la ela!orarea unei structuri conceptuale a sistemului de
caracteristici cunoscut su! numele de "!'elul al%t./%% &!,t0are1ulu%. 3odelul a fost creat pentru
prima dat 'e BarrB B!e5" )% !la*!rat!r%% &.% 'e la TRW SB&te"& Cr!u#. :lterior a fost
rafinat i e,tins 'e 7a"e& =Call( P. R%5ar' )% C. Walter& - modelul a fcut o!iectul
standardizrii i este recomandat de ISO #r%n &tan'ar'ul ISO6IEC 912611991.
/omponentele calitii de ni'el nalt, uzual numite ,at!r% 'e al%tate, sunt considerate n
termeni ai componentelor de calitate de ni'el sczut, r%ter%%, consistente cu 'iziunea dez'olttorilor
de sistem al calitii.
Aceast concepie conduce la modelul2
factor de calitate $caracteristic%, criteriu de calitate $su!caracteristica% i metrici de
calitate, sc0ematizat n fig. (.
J
metrici
metrici
factor $caracteristic%
$su!caracteristic%
criteriu
(
criteriu
n
Fig. 1. Relaia caracteristici-subcaracteristici-metrici
. . .
Carater%&t%%le 'e al%tate re#re-%nt. #untul 'e ve'ere al ut%l%-at!rulu% )% al )e,ulu% 'e #r!%et
a&u#ra al%t./%%( folosind la definirea cerinelor utilizatorului i la sta!ilirea o!iecti'elor de calitate
pentru sistemul de programe.
Su*arater%&t%%le au &e"n%,%a/%e te5n%. )% &unt relevante #entru #er&!nalul 'e
&#e%al%tate 2anal%)t%( #r!%etan/%( #r!+ra"at!r%3.
.le faciliteaz comunicarea ntre eful de proiect i personalul de specialitate pentru atingerea
o!iecti'elor de calitate.
Su*arater%&t%%le &e 'e,%ne& #entru !"#!nentele &%&te"ulu% 'e #r!+ra"e )% '%,er%tele
,!r"e 'e re#re-entare 2er%n/e( &#e%,%a/%%( !' &ur&.( '!u"enta/%e 'e ut%l%-are( ).a.3 #e
#arur&ul %lulu% 'e v%a/..
@a ultimul ni'el se definesc metricile, care permit msurarea su!caracteristicilor i, n
consecin, a caracteristicilor de pe primul ni'el.
2.2.& Relaiile dintre caracteristici
>ntre caracteristici e,ist relaii de su!ordonare i de dependen ce sunt reflectate n mod
diferit de modelele calitii $-&O )(D*, .sprit $recomandat de .uropean organization for Kualit?%,
4oe0m, 3c/all% , aa cum se 'ede n fig. D.
Aelaiile ierar0ice de su!ordonare sunt definite prin structura sistemului de caracteristici i
difer de la un model la altul.
Aelaiile de influen de tip conflictual semnific faptul c pe msur ce crete ni'elul unei
caracteristici, este de ateptat ca ni'elele celeilalte caracteristici s scad.
Aelaiile de influen de tip complementar au urmtoarea semnificaie2
- dac ni'elul unei caracteristici crete, atunci este de ateptat ca i ni'elul celorlalte caracteristici s
creasc. /unoaterea relaiilor i a interdependenelor ntre caracteristici e necesar n toate fazele de
specificare, determinare i e'aluare a calitii sistemelor de programe, n special n faza de sta!ilire a
o!iecti'elor de calitate.
>n dez'oltarea 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.' (odelul calitii software din I! "12$
1rin modelul -&O )(D* se recomand utilizarea urmtorului set de caracteristici2
M
Aelaii
-erar0ice
De influen
/onflictuale /omplementare
Fig. 2 Relaiile ntre caracteristici
- funcionalitate, utiliza!ilitate, fia!ilitate, eficien, mentena!ilitate i porta!ilitate, ca
n figura E2
3ai 9os se d o descriere pe scurt a semnificaiei caracteristicilor n modelul -&OB-./ )(D*2
Tabelul 1. %aracteristici de calitate n modelul I!)I*% "12$
Carater% &t% . Se"n%,%a/% e
8:N/;-ONA@-TAT.
- prezena i adec'ana setului de funciuni fa de specificaii<
- atri!utele produsului sunt legate de o!inerea rezultatelor corecte sau
con'enite $e,. gradul necesar de precizie al 'alorilor%<
- posi!ilitatea de interaciune a produsului cu altele specificate<
- aderarea la standarde, con'enii, reglementri i alte prescripii
similare, legate de domeniul de aplicaie<
- posi!ilitatea produsului de a pre'eni accesul neautorizat, accidental
sau deli!erat, la programe sau date.
8-A4-@-TAT.
- gradul de maturitate al produsului, respecti' frec'ena cderilor din
cauza erorilor produsului software<
- capacitatea produsului de a-i menine un anumit ni'el specificat de
performan n caz de eroare<
- posi!ilitatea resta!ilirii ni'elului de performan i refacerea datelor
n cazul unei erori< timpul i efortul necesar pentru aceasta.
:T-@-QA4-@-TAT.
- uurina n nelegere, efortul utilizatorului de a recunoate conceptul
logic i aplica!ilitatea lui<
- uurina n operare<
- uurina n n'area aplicrii produsului.
1.A8OA3AN;.
- comportamentul n timp, eficiena ca timp de rspuns - pe tipuri
di'erse de prelucrri, ratele de transfer su! condiii diferite de
ncrcare i configuraii diferite<
- comportamentul resurselor, respecti' consumul de memorie intern i
e,tern n diferite condiii.
3.NT.NA4-@-TAT.
- rapiditatea i e,actitatea cu care se poate identifica o eroare n
e,ecuie din mesa9ele produsului i cauzele acesteia<
- e,istena n documentaie a procedurilor i facilitilor de ntreinere a
produsului.
1OATA4-@-TAT.
- posi!ilitatea de adaptare la alte medii specifice, fr a apela faciliti
din afara produsului<
- posi!ilitatea de instalare a produsului ntr-un mediu specificat<
- gradul de aderare a produsului la standardele i reglementrile legate
de porta!ilitate.
*
Fig. 3 Modelul ISO/IEC 12!
3entena!ilitate
3aturitate
Toleran la erori
/apacitatea de recuperare
8uncionalitate
:tiliza!ilitate
1orta!ilitate
8ia!ilitate
.ficien
/aracteristici
ci
&u!caracteristici
/onform acestui standard, ,%a*%l%tatea e 'e,%n%t. a ,%%n' a#a%tatea &!,t0are1ulu% 'e a
"en/%ne n%velul &.u 'e #er,!r"an/. n !n'%/%% &ta*%l%te #entru ! #er%!a'. 'at. 'e t%"#.
U-ura &au "*.tr;n%rea nu apare n software. L%"%t.r%le ,%a*%l%t./%% &unt +enerate 'e
er!r%le n er%n/e( #r!%etare )% %"#le"entare. 4ntreru#er%le are a#ar '%n au-a ae&t!r er!r%
'e#%n' 'e "!'ul u" e ut%l%-at #r!'u&ul &!,t0are 2#r!,%lul !#era/%!nal3 )% 'e !#/%un%le
&eletate n #r!+ra"( "a% 'e+ra*. 'e;t 'e treerea t%"#ulu%.
4n 'e,%n%/%a ISO 8>?2( ,%a*%l%tatea re#re-%nt.
DA#t%tu'%nea unu% #r!'u& 'e a n'e#l%n% ! ,un/%e erut.......E. 4n ae&t &tan'ar'(
,un/%!nal%tatea e&te nu"a% una '%n arater%&t%%le al%t./%% &!,t0are1ulu%. Ca ur"are( 'e,%n%/%a
,%a*%l%t./%% a ,!&t e$tra#!lat. la D"en/%nerea n%velulu% &.u 'e #er,!r"an/.E n l! 'e
De$eutarea une% ,un/%% eruteE.
>n ceea ce pri'ete su!caracteristicile, se poate aprecia c ni'elul lor este mai detaliat. 7om
e,emplifica aici doar &u*arater%&t%%le &#e%,%e ,%a*%l%t./%%, cele aparinnd celorlalte caracteristici
putndu-se afla prin consultarea standardului $se pot deduce i din semnificaia dat caracteristicilor
n ta!elul (%. .le sunt2
"atur%tatea - atri!ute ale software-ului ce 'izeaz frec'ena ntreruperilor datorate
erorilor software<
t!leran/a la 'e,et.r% - aptitudinea software de a menine un ni'el specificat de
funcionare n cazul apariiei erorilor sau al 'iolrii interfeei sale<
a#a%tatea 'e reu#erare - atri!ute software ce reflect capacitatea de resta!ilire a
ni'elului 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 -&O +J=D e,prim punctul de 'edere al utilizatorilor, la fel ca i
caracteristicile din acest standard.
Ut%l%-at!r%% evaluea-. &!,t0are1ul ,.r. a )t% a&#etele %nterne 'e real%-are )% %ntera/%une
&!,t0are.
>ntre!rile utilizatorilor pot fi de forma2
,un/%%le erute &unt '%&#!n%*%le n &!,t0areF
;t 'e ,%a*%l e&te &!,t0are1ulF
;t 'e e,%%ent e&te &!,t0are1ulF
e&te &!,t0are1ul u)!r 'e ut%l%-atF
are1% '%,%ultatea tran&,er.r%% &!,t0are1ulu% n alt "e'%uF
Aealizatorii sunt responsa!ili de producerea software-ului care 'a satisface cerinele de
calitate, fiind interesai att n calitatea produsului intermediar, ct i n cea a produsului final.
1entru a e'alua calitatea produsului intermediar n fiecare faz a ciclului de realizare,
realizatorii tre!uie s foloseasc msuri diferite pentru aceleai caracteristici, nefiind uni'ersale
pentru toate fazele ciclului de 'ia..
1unctul de 'edere al realizatorilor tre!uie s e,prime i pe cel al celor care ntrein
software-ul.
A'"%n%&trat!rul 2"ana+erul 'e #r!%et3 este interesat de calitate pe ansam!lu, dect de o
caracteristic anume i de aceea 'a tre!ui s fie acordate ponderi caracteristicilor indi'iduale, care s
oglindeasc cerinele comerciale.
A'"%n%&trat!rul e5%l%*rea-. "*un.t./%rea al%t./%% u r%ter%%le 'e a'"%n%&trare, cum
ar fi ntrzierea fa de timpul planificat sau depirea costului, '!r%n' !#t%"%-area al%t./%% n
a'rul l%"%tel!r !&tulu%( re&ur&el!r u"ane )% a t%"#ulu% #rev.-ut. :ltimul ni'el n modelul
calitii, reprezentat de "etr%%( nu este nc standardizat.
&e las la latitudinea organizaiilor s-i defineasc metrici specifice.
:nii specialiti folosesc alt terminologie pentru perec0ea caracteristici - su!caracteristici2
- arater%&t%% 1 atr%*ute n modelul 4oe0m<
- ,at!r% 1 &u*,at!r% n modelul 3c/all.
3odelele difer att prin modul de ierar0izare a caracteristicilor i su!caracteristicilor, ct i
prin definiiile utilizate.
2.2.+ tandardele I! "###
C
C!ne#tul 'e "ana+e"ent al al%t./%% t!tale &e a$ea-. #e lur.r%le 'e #%!n%erat ale lu%
Ar"an' Fe%+en*au"( Dr.E'0ar' De"%n+( Dr. 7!&e#5 7uran )% al/%%.
O lucrare de referin n acest domeniu este DT!tal Gual%tB C!ntr!lE( pu!licat de A.
8eigen!aum nc din ()M(.
/alitatea total s-a aplicat pentru prima oar n Raponia la nceputul anilor S+=, dup
pu!licarea crii "/e e calitatea total# a dr. Taoru -s0i6awa. @a 9umtatea anilor S+=,
Departamentul Aprrii &.:.A. a popularizat noiunea de management al calitii totale, e,trapolnd
disciplina calitii la toate domeniile economice.
Dup o definiie dat de DOD n ())=, "ana+e"entul al%t./%% t!tale e o strategie pentru a
continua m!untirea performanei la orice ni'el i-n toate domeniile de responsa!ilitate.
/alitatea total reprezint un proces continuu cuprinznd toate aspectele unei organizaii, de
la design ori ser'iciu pn la producie i utilizarea produsului sau ser'iciului, necesitnd deplina
nelegere a cerinelor i ateptrilor clienilor i implicnd toi anga9aii n aprecierea i m!untirea
calitii, cu a9utorul unor instrumente i te0nici de m!untire.
Stan'ar'ele ISO &unt un #unt 'e &tart !re&#un-.t!r #entru ! ,%r". are1)% #r!#une
"ana+e"entul al%t./%% t!tale.
Stan'ar'ele ISO 9??? 'e&r%u un &et 'e &tan'ar'e %nterna/%!nale are &e !u#. u
'e&%+nul( #r!'u/%a( l%vrarea( &erv%%ul )% te&tarea #r!e&ulu%. Ele )% #r!#un "*un.t./%rea
#r!e&ulu% 'e #r!'u/%e a une% ,%r"e.
>n &.:.A. multe companii folosesc standardele 3-@ - -- JMD=+ sau 3-@ - K - )+M+, c0iar i
acelea care nu au contracte cu industria de aprare.
Odat ce un standard al calitii sistemului s-a impus, &unt tre% .% u-uale 'e a ver%,%a
n'e#l%n%rea er%n/el!r 'e al%tate #r%v%n' &%&te"ele<
u"#.r.t!rul are nre'ere n *una re'%n/. a ,urn%-!rulu% 2#r!'u.t!rulu%3A
u"#.r.t!rul !n'ue #r!e&ul 'e ver%,%are la #r!'u.t!rA
u"#.r.t!rul )% ale+e un ver%,%at!r are ert%,%. al%tatea &%&te"ulu% 2au'%t3.
1rimele dou metode sunt comune n practicile comerciale. De e,emplu, DOD &.:.A.
conduce testele de 'erificare a calitii sistemelor pentru furnizorii si.
&tandardele -&O )=== au adoptat a treia metod de 'erificare a calitii.
Descrierea lor pe pri este dat n ta!elul D.
Tabelul 2. Standardele din seria ISO """ re#eritoare la calitate
-&O +J=D 2 ())J 3anagementul calitii i asigurarea calitii - 'oca!ular.
-&O )=== - ( 2 ())J 3anagementul calitii i standarde de asigurare a calitii.
$art. 12 I0id pentru selectare i utilizare.
-&O )=== - D 2 ())E 3anagementul calitii i standarde de asigurare a calitii.
$art.22 I0id generic de aplicare a standardelor -&O )==(, )==D i -&O
)==E.
-&O )=== - E 2 ())( 3anagementul calitii i standarde de asigurare a calitii.
$art. 32 I0id de aplicare a standardului -&O )==( la dez'oltarea,
producerea i mentenana software-ului.
-&O )=== - J2 ())E 3anagementul calitii i standarde de asigurare a calitii.
$art. %2 I0id de management al dependenei.
-&O )==( 2 ())J /alitatea sistemelor - 3odel pentru asigurarea calitii n proiectare,
dez'oltare, producere, instalare i ntreinere.
-&O )==D 2 ())J /alitatea sistemelor - 3odel pentru asigurarea calitii n producere,
instalare i ntreinere.
-&O )==E 2 ())J /alitatea sistemelor - 3odel pentru asigurarea calitii n inspecia
final i testare.
-&O )==J - ( 2 ())J 3anagementul calitii i calitatea elementelor sistemului.
$art 12 I0id.
-&O )==J - D 2 ())( 3anagementul calitii i calitatea elementelor sistemului.
$art 12 I0id pentru ntreinere.
+
-&O )==J - E 2 ())E 3anagementul calitii i calitatea elementelor sistemului.
$art 12 I0id pentru prelucrarea materialelor.
-&O )==J - J 2 ())E 3anagementul calitii i calitatea elementelor sistemului.
$art 12 I0id pentru creterea calitii.
&tandardele -&O )==(, )==D i )==E pre'd cerinele contractuale ntre productor i
!eneficiar.
&tandardele cu cel mai mare efect n proiectare asupra calitii sunt -&O )==(, -&O )===-E i -&O
)=== - J. 1rin aplicarea acestora, productorul poate realiza un sistem de calitate innd seama de
etapele de proiectare, producere i dependen pentru produsele 0ardware ct i pentru software.
&tandardul -&O )=== - E ofer un g0id productorilor de software care aplic standardul
-&O )==(.
4n &tan'ar'ul ISO 9??? 1 1 &e a,%r".<
DPr!e&ul 'e-v!lt.r%%( #r!'uer%% )% ntre/%ner%% #r!'u&el!r &!,t0are e&te '%,er%t 'e
elelalte t%#ur% 'e #r!e&e %n'u&tr%ale n are nu e&te n%% ! '%,eren/. n ,a-a 'e #r!'u/%e.
S!,t0are1ul nu &e u-ea-. )% n !n&e%n/. al%tatea at%v%t./%l!r n ,a-a 'e #r!%etare are !
%"#!rtan/. 'e!&e*%t. n al%tatea ,%nal. a #r!'u&ulu%E.
2.& Fiabilitatea software reflectat n standardele britanice i americane
2.&.1 ,efiniii i terminologie
/onform standardului -... $AN&-% )+D.D din ()+)FGGGa+)H, elementele principale n
definirea software sunt2 er!area $error%, nere+ula $fault% i 'e,etarea $failure%.
Er!area este o greeal uman ce are ca rezultat un program incorect. >n aceast categorie
se pot include, de e,emplu, omiterea sau lipsa interpretrii unei cerine utilizator la redacterea
specificaiei program, precum i interpretarea greit a unei cerine sau omiterea unei cerine n
specificaia de design.
>n urma erorii umane apare nere+ula $fault sau !ug%. .a este materializarea nemi9locit a
erorii umane n software, a'nd ca efect necesitatea modificrii unei poriuni de cod.
>n 'or!irea curent, se folosete denumirea de eroare att pentru eroarea uman $error%, ct
i pentru manifestarea ei direct n program $fault sau !ug%. Anomaliile produsului cauzate de erori
se numesc 'e,ete $defects%.
De,etarea sau cderea $,a%lure% e e'idenierea defectului, cnd o unitate funcional a
sistemului $ce include i 0ardware-ul comandat% nu-i mai ndeplinete funcia n limite specificate.
/derea $failure% apare cnd un anumit set de date de intrare acti'eaz defectul e,istent n
software.
Er!r%le u"ane( nere+ul%le 2,ault&3 )% 'e,etele 2'e,et&3 '%n &!,t0are &unt au-ele
even%"entel!r ne'!r%te( %ar 'e,et.r%le 2.'er%le H ,a%lure&3 &unt e,etele.
8igura J reprezint sc0ematic aceste noiuni, precum i interaciunile lor, n 'iziunea
standardului !ritanic DD ()+B())(FGGG!)(H 2
)
Nereguli $faults%
3ecanismul dez'luirii
$punerii n e'iden%
/deri $failures%
.rori $errors%
3ediu
-ntrri
Operator
1ot fi
atri!uite
uneia sau
mai multor
1ot fi
atri!uite
uneia sau
mai multor
1ot genera
= sau mai
multe
1ersoana
care face
zero sau mai
multe erori
Fig. %. Relaiile dintre termenii de ba- n fiabilitatea software. *rror, fault, failure.
>n continuare se prezint i ali termeni frec'ent utilizai de standarde2
=ISURI $metric%
O apreciere cantitati' a gradului n care un proces sau produs software
posed un atri!ut dat.
PRI=ITIJI
Dat folosit n dez'oltarea sau utilizarea software pentru
implementarea msurilor sau descrierilor cantitati'e ale software-ului<
primiti'a e direct msura!il sau numra!il, i poate fi dat printr-o
constant.
.,emplu2 nr. de erori, mrimea unui inter'al de timp, nr. arce, nr.
noduri, nr. de instruciuni e,ecuta!ile .a.
FIABILITATE
SOFTWARE
1ro!a!ilitatea ca software-ul s funcioneze fr defectare ntr-un timp
specificat, n condiii operaionale date.
&ec'ena de cod e,ecutat depinde de 'alorile datelor de intrare, ca
urmare fia!ilitatea unui program e o funcie ponderat n mod
corespunztor cu distri!uia datelor de intrare din mediul utilizator.
>n DD ()+B())(, se utilizeaz i o alt definire 2
A*%l%tatea unu% #r!'u& &!,t0are 'e1a 'a #er,!r"an/.
&at%&,..t!are #e ter"en lun+( ,.r. a &e 'e,eta 2a n ISO6IEC
91263.
=A@ACE=E@TUL
FIABILITIKII
SOFTWARE
1rocesul optimizrii fia!ilitii software printr-un program care pune
accent pe pre'enirea erorilor software, detectarea i ndeprtarea
neregulilor $faults% i folosirea msurtorilor pentru a ma,imiza
fia!ilitatea, pe fondul constngerilor proiect, cum ar fi costul resurselor,
planificarea i performana.
2.&.2 %onstruirea fiabilitii software
(=
&copul standardelor de fia!ilitate este de-a spri9ini dez'oltatorii de software, managerii de
proiect i utilizatorii sistem n atingerea ni'elelor de fia!ilitate optim n produsele software. .le 'in
n spri9inul celor care dez'olt software i clienilor care sunt confruntai cu o multitudine de modele,
te0nici i msuri, n literatur, dar care nu dau g0idare suficient n utilizarea lor efecti'.
E$%&t. ! rela/%e %nt%". ntre ,%a*%l%tatea unu% #r!'u& )% #r!e&ele ,!l!&%te n 'e-v!ltarea
#r!'u&ulu%.
3surile $metricile% selectate 'a tre!ui s dea 'izi!ilitate proceselor i produselor astfel nct
factorii eseniali necesari n e'aluarea procesului i-a sc0im!rii acestuia s fie disponi!ili.
&copul principal al standardelor este de-a furniza elementele unui program de msurare care
s spri9ine o a!ordare constructi' pentru atingerea fia!ilitii optime la sfritul implementrii
produsului< totodat ele asist managementul n dez'oltarea produsului i atingerea unor inte de
fia!ilitate.
O a*!r'are !n&trut%v. a ,%a*%l%t./%% &!,t0are aut. &. el%"%ne au-a +ener.r%%
%n%'entel!r &%&te" 2,%+. 93 n #r!e&ul 'e 'e-v!ltare &!,t0are )% &#r%L%n. #r!e&ele are
#r!"!vea-. ev%tarea *u+ur%l!r( 'etetarea t%"#ur%e a 'e,etel!r( el%"%narea a'evat. a
ae&t!ra )% #r!%etarea unu% &%&te" t!lerant la 'e,et.r% 2,%+. 63.
=aL!r%tatea .'er%l!r &unt le+ate 'e !r%+%nea l!r( are v%-ea-.<
213 %n!"#leta 'e,%n%re a nee&%t./%l!r )% er%n/el!r u&erA
223 !"%&%un% n #r!e&ul 'e #r!%etare )% !'%,%areA
2M3 ,!l!&%rea %"#r!#r%e a &%&te"ulu%A
2>3 &5%"*.r% 'e !' e$e&%ve.
:n #r!e& &trate+% de atingere a fia!ilitii software include at%v%t./%( "et!'e(
%n&tru"ente )% ".&ur.t!r%.
F%+ura 2 8 3 arat. ae&t #r!e& )% r!lul %nte+rat al ".&ur.t!r%l!r #entru a "!n%t!r%-a
al%tatea #r!e&ulu% )% a #r!'u&ulu%.
.a reprezint un cumul de concepte, acti'iti i te0nici cunoscute, care pot fi utilizate pentru
a conduce un proiect n scopul o!inerii unei mai !une fia!iliti.
((
Fig. & Cau'ele incidentelor (#ailures)
(D

... trebuie s* #ie
eli+inate...
FANA OPERA K IO@ALO

$ failures %

LIPSO DE
ROBUSTE K E

FAULTS
RENIDUALE

FAULTS
( nereguli )

FAULTS
DETECTATE
... adesea alte
e#ecte...
... rar ,
solu ia...
... -ot genera...
... generea'* ...
de'astre
surs* a di#icult* ii . i
costului +are n
ti+-ul i+-le+ent*rii
ERRORS
... originea ...
PROIECTARE<

nestructurat*/

ne+odular*/

nedocu+entat*.
PROIECTARE<

inco+-let*/

instabil*.
CU@OA P TERE SORACO( ORIE@TARE
I@SUFICIE@TO( PRE=ATURO 4@SPRE
@EJOILE USER P I CALITATEA TOTALO.

SCQI=BORI
$ adesea fUcute mai
trziu %
...ce trebuie
s* #ie
e0tinse..
ERORI
USER
I@TRORI
'%n lu"ea
realR
SISTE=
TOLERA@T
LA
DEFECTIR
I
U@ PRODUS
FIABIL
c1te2a (sau ")
#ailures
U@ SISTE=
ROBUST
c1te2a (sau ")
#aults
ERORI
USER
ERORI
PUKI@E
ERORI
PUKI@E
DEFECTIRI
(#aults)
FAULTS
DETECTATE
SCQI=BIRI
(#3cute c1t +ai
cur1nd -osibile)
REALITIKI
ALE
JIEKII

PROIECT
ARE<
4susine
e0tensii
directe 4
PROIECTARE<
sta!il<
adapta!il
PROIECTARE<
modular<
documentat<
I@TRIRI
'%n lu"ea
real.
CU@OAPTERE DEPLI@I( ORIE@TARE
4@ TI=P PE @ECESITIKILE USER
PI CALITATEA TOTALI
ABORDARE CO@DUSI DE U@ =ODEL DE
CALITATE
4-er+ite
i+-le+entarea u.oar3
.i controlat3 4
4d3 na.tere4
4-re2ine4
PROCESE
CO@STRUC1
TIJE

PROIECT
ARE<
4generea'34
4.tergere
adec2at34
4generea'34
4rar de#ecte
secundare4
4co+-let -entru o
-roiectare con2ergent3 4
4a5ut3,
-rote5ea'3 ..4
Fig. ! Constructorii unui -rodus #iabil
(E
C
O
@
C
E
P
T
C
E
R
I
@
K
E
D
E
S
I
C
@
C
O
D
I
F
I
C
A
R
E
T
E
S
T
I
n
&
t
a
l
a
r
e

S

L
%
v
r
a
r
e
O
#
e
r
a
r
e
S
=
a
%
n
t
e
n
a
n
/
.
Retra+ere
S
O
F
T
W
A
R
E
"Do it rig0t t0e
first time#
$ 1re'enire eroare,
reducere apariie
defect, proiectare
ro!ust i toleran
la defectri %
/
O
N
/
.
1
;
-
.
D
e
s
i
g
n

V

/
o
d
i
f
i
c
a
r
e
D
E
J
E
L
O
P
=
E
@
T
"Detect it earl?<
fi, it as soon as
practica!le#
$ detectare i
eliminare
defecte %
7
e
r
i
f
i
c
a
r
e
7
a
l
i
d
a
r
e
P
R
O
C
E
S
"3onitor itW
$/t de corectX%
$/t de complet X%
3
.
T
A
-
/
-
-
Fig. 6 Strategia 7constructi237 de de'2oltare a unui so#t8are #iabil
/riteriile care stau la !aza acestei concepii constructi'e $proces% sunt2
(J
personal priceput, competent
studiul mediului operaional i al necesitilor :&.A
studiul produselor similare
scriere specificaii
prototipizare rapid
simulare
proiectare structurat top - down
V testare
lim!a9e design
prototipizare
simulare
metode de minimizare comple,itate
spec
spec
spec
spec run
run
run
run
%once/ia ideal
1. folosii 'erificarea $acti'iti,
te0nici, scule%
pt. a determina i elimina
defectele<
2. folosii 'alidarea $acti'iti,
te0nici, scule% pt. a confirma
a!sena defectelor.
re'ederi
inspecii
prototipizare
rapid
simulare
pro!are
corectitudine
Teste dinamice2
1 %n&talare
te&te
1 te&te &%&te"
1 te&te &u*&%&te"
)% %nte+rare
1 te&te un%tate
2#r!'u&3
reluare
$pentru a 'edea c
nu s-a degradat%
colecie de date despre primiti'e, calcule, e'aluare
$intrUrile pentru metrici sunt furnizate prin acti'itUi de 'alidare
i 'erificare %
1. F. eva !ret 'e #r%"a 'at.<
&e pune accent pe necesitatea studierii intensi'e a necesitilor sta!ilite i nesta!ilite ale
aplicaiei user, precum i pe e,istena unei e,periene suficiente n rezol'area unei
pro!leme similare, ceea ce presupune anga9area unui personal priceput i competent n
construirea de produse fia!ile.
-mplicarea timpurie a !eneficiarului n conceperea produsului prin te0nici ca
prototipizarea pentru a se asigura c utiliza!ilitatea este susinut i de lipsa defectrilor
n funcionare<
3etode moderne, lim!a9e i instrumente automate tre!uie s fie utilizate pentru
promo'area producti'itii i calitii n acti'itile de specificare, design, codificare i
testare.
2. Detetarea t%"#ur%e a er!r%%A ,%$area e% ;t 'e ur;n' #!&%*%l.
Detectarea i repararea ar tre!ui s fie acti'iti planificate adec'at.
Jer%,%area e procesul determinrii dac $sau nu% produsul rezultat n urma unei faze a
procesului de dez'oltare software satisface cerinele sta!ilite n timpul fazei anterioare.
Jal%'area este procesul e'alurii software la sfritul unei faze $ proces % de dez'oltare
pentru a asigura acordul cu cerinele software.
Detectarea timpurie a defectelor software prin re'ederi, inspecii, prototipizare, simulare sau
pro!area corectitudinii unui produs 'a m!unti fia!ilitatea.
F%a*%l%tatea nu poate fi o!inut numai prin acti'itatea de testare a unui produs. 3ai mult testare
nu nseamn neaprat mai !un fia!ilitate. Totui, testele dinamice, metoda principal pentru 'alidare, 'or fi
folosite $n limitele unui cost% pentru a da acoperirea testrii unui produs.
M. =!n%t!r%-area er!r%l!r.
.'aluarea msurtorilor e folosit nu numai pentru e'aluarea calitii software, ci i pentru
detectarea !ugurilor.
De e,emplu, dac timpul de procesare e mai mare dect o 'aloare dat, acesta poate fi un
moti' suficient de respingere a codului implementat i de nlocuire a lui cu altul rescris.
2.&.& (ediul de msurare
=.&urarea #re&u#une a !"#ara ! #r!#r%etate a unu% !*%et u una &%"%lar. a unu%
&tan'ar' 'e re,er%n/..
/nd msurtorile se folosesc pentru diagnosticare, tre!uie s e,iste un mediu propice pentru
colectarea i analiza datelor, ct i pentru aciunile corecti'e care se fac, toate aceste acti'iti
te0nice i manageriale desfurndu-se ntr-un flu,. $ 8igura + %
In,!r"a/%%le ,!l!&%te #entru ".&ur% "a% !"#le$e &e nu"e& #r%"%t%ve. :nele primiti'e
pot deri'a direct din produs $specificaii, cod surs, cod o!iect%2
instruciuni<
noduri<
arce<
ramificri .a.
Alte primiti'e, re-ultate ale at%v%t./%l!r 'e val%'are )% ver%,%are, includ nr. er!r%, nr.
defecte $,ault&% i nr. cderi $,a%lure&%.
Se re!"an'. '!% #a)% n #re+.t%rea !le/%e% 'e 'ate<
213 Pentru ,%eare ".&ur. #!ten/%al. &eletat. '%n &tan'ar'e( &e 'eter"%n. e
'ate tre*u%e ".&urate '%n l%&ta 'e #r%"%t%veA
223 Datele !letate &e v!r "e"!ra ntr1! *a-. 'e 'ate( #entru a /%ne %&t!r%ul
unu% #r!%et 'e 'e-v!ltare )%1n &!#ul anal%-el!r.
(M
SPECIFICAKIE
DESIC@
CODIFICARE
TESTARE<
9 RE:E;ERI
9 I<S$EC=II
(0102*(*13 4R!%*
DA
$&e trece la
faza urmtoare
de dez'oltare%
corecie proces i
repetarea lui
@U
Jal!area real. 1 Jal!area a)te#tat.

TOOLS
'e nre+%&trare
aut!"atR

Pre+.t%re
)%
nre+%&trare
"anualR
,%)%er
e
#r%"%t%ve
4roces de obser5are i monitori-are.
colectare date
nregistrare date
TOOLS
'e "R&urare
aut!"atR
3suri $'alori%
mnuire,
cunotine,
inteligenU
a3
*
33
3
3
Fig. > Flu0ul in#or+aiei de +3surare (-arte a -rocesului de de'2oltare)
4eneficiul mare al implementrii unui efort de msurare este priceperea de a e'alua
rezultatele coleciei de date, de a dez'olta msuri i a aplica analiza rezultatelor n aprecierea creterii
fia!ilitii att a proceselor de dez'oltare, ct i a produsului final.
2.&.' %riteriile de selecie a metricilor
O a!ordare constructi' $modern% e,tinde cercetarea la ".&ur% care promo'eaz fia!ilitatea
prin "%n%"%-area er!r%l!r re-%'uale, ca o consecin a #reven%r%% er!r%% )% a 'ete/%e% t%"#ur%% a
'e,etel!r ur"at. 'e el%"%narea ae&t!ra. A&t,el( &tan'ar'ul 982.1 %nlu'e ".&ur% #r!'u&
#entru a 'eter"%na ;t 'e atent &1a ver%,%at &!,t0are1ul 2!"#let%tu'%nea )% tran&a*%l%tatea3 )%
'eter"%n. !"#le$%tatea n &!#ul &tu'%er%% #!&%*%l%t./%% &5%"*.r%% n &%&te".
&e 'or selecta msuri care s monitorizeze al%tatea #r!e&ulu% 'e 'e-v!ltare i care s
identifice ne'oia de a face modificri timpurii n proces.
3surile proces au scopul de a stimula adoptarea celor mai !une practici ale ingineriei
software n fiecare faz a dez'oltrii proiect, ncura9nd detectarea erorii timpuriu.
O !n&%'era/%e e&en/%al. n &eletarea "etr%%l!r tre*u%e &. ,%e aeea a ele &. a!#ere
t!t %lul 'e v%a/.( a're&;n'u1&e at;t ut%l%-at!r%l!r ;t )% %n+%ner%l!r 'e &%&te" 2&!,t0are3(
!,er%n' un &#etru lar+ n ".&urarea ,%a*%l%t./%%.
Ut%l%-at!rul poate focaliza pe '%&#!n%*%l%tatea &%&te"ulu% )% u)ur%n/a n e$#l!atare, n
timp ce %n+%ner%% #!t #une aent #e e$%&ten/a 'e,etel!r n #r!'u&ul &!,t0are.
Alte metrici, cum ar fi !"#le$%tatea intereseaz permanent pe "ana+er% )% !let%vul 'e
'e-v!ltare( oferindu-le informaii pentru "*un.t./%rea #r!e&ulu% )% !ntr!lul !&tur%l!r(
#lan%,%are( #r!'ut%v%tate #er&!nal )% #r%e#erea #r!,e&%!nal..
2.&.+ !rgani-area i clasificarea msurrii
(*
3surile 'izeaz dou o!iecti'e ale fia!ilitii2
- a#re%erea "atur%t./%% #r!'u& - o certificare a disponi!ilitii produsului pentru
operare $incluznd i o estimare a suportului necesar pentru mentenana corecti'%<
- a#re%erea "atur%t./%% #r!e&ulu% - o e'aluare a capa!ilitii factorilor software de-a
produce produse de calitate, conform dorinelor utilizator.
C%lul 'e v%a/. &!,t0are #!ate ,% "!'elat )% ra,%nat ca o sec'en de su!procese. 8iecare
su!proces are intrri i ieiri care ar tre!ui s satisfac criterii !ine definite.
Dac un produs software nu satisface r%ter%ul 'e %e)%re &ta*%l%t, aceasta ar tre!ui s
reprezinte un semnal pentru o analiz nentrziat. 8ie su!procesul prezint anumite deficiene, fie
criteriul de ieire este prea se'er.
Aciunea corecti' se 'a e,ecuta numai dup o analiz suficient $fig. )%.
Fig. 12 Controlul -rocesului
=.&ur%le a#l%ate se refer la #r!e& )% #r!'u&. =.&ur%le #r!'u& se 'or aplica o!iectelor
software rezultate n urma unui proces i se mpart n ase su!categorii2
Er!r% 2err!r&3( 'e,ete 2,ault&3 )% %n%'ente 2,a%lure&3A
T%"#ul "e'%u 'e 'e,etareA rata 'e 'e,etare<
Cre)tere ,%a*%l%tate )% #r!%etare ,%a*%l%tate<
De,ete r."a&e n #r!'u& 2nr. re-%'ual3A
C!"#let%tu'%ne )% !n&%&ten/.<
C!"#le$%tate.
=.&ur%le #r!e& 'or fi aplicate at%v%t./%l!r 'e 'e-v!ltare ale %lulu% 'e v%a/.( te&t.r%% )%
"entenan/e% &!,t0are )% u#r%n' tre% &u*ate+!r%%<
C!ntr!l "ana+e"entA
A!#er%re 2!vera+e3A
R%&( *ene,%%% )% evaluare !&t.
>n afara acestei clasificri $funcionale%, msurile pot fi de asemenea clasificate n funcie de
fazele ciclului de 'ia software n care folosirea lor este corespunztoare.
8azele ciclului de 'ia clasice se !azeaz pe standardul IEEE 8291198M $-... &tandard
Ilossar? of &oftware .ngineering Terminolog? i se utilizeaz pentru a ilustra cnd e adec'at
aplicarea fiecrei msuri.
(C
. . .
Su*#r!e&
n
Su*#r!e&
n T 1
-ntrare
produs
-eire
produs
. . .
-eire
produs
-ntrare
produs
/riteriul de intrare
pentru su!procesul n
/riteriul de
ieire pentru
su!procesul n
/riteriul de
intrare pentru
su!procesul n Y (
Test ieire
pentru e'aluarea
su!procesului n
Aciune corecti'
pentru su!procesul n
$8..D4A/T%
Test intrare pentru
disponi!ilitatea produsului
de-a intra n su!procesul n Y (
Test intrare pentru
disponi!ilitatea produsului
de-a intra n su!procesul n
Fa-ele %lulu% 'e v%a/. &unt<
C!ne#/%aA
S#e%,%are er%n/eA
Pr!%etareA
I"#le"entare 2!'%,%are3A
Te&tareA
In&talare 2la *ene,%%ar3A
O#erare )% "entenan/.A
Retra+ere.
2.&.+.1 %lasificarea funcional a msurilor 6metricilor7
3atricea de clasificare msuri $metrici% din ta!elul E este un inde, al msurilor i categoriilor
funcionale propuse n FGGGa+)H. .a poate fi folosit pentru a selecta msuri aplica!ile fiecrei
categorii. Apoi, pentru fiecare categorie, se prezint o matrice care 'a referi msurile ce se pot folosi
n fiecare faz a ciclului de 'ia software $ta!elele J-(D%.
>n cadrul fiecrei metrici se trece n parantez o cifr {=,(,D,E}i care are urmtoarea
semnificaie2
- ? msura a fost formalizat dar nu a fost suficient 'alidat n cmpul operaional<
- 1 metrica respecti' s-a folosit de o comunitate software restrns sau nu e suficient de
!ine cunoscut<
- 2 metrica s-a utilizat moderat<
- M metrica s-a folosit intens.
Aceast cifr furnizeaz msura ncrederii n utilizarea acestei metrici, 'aloarea ei fiind direct
proporional cu gradul de recomandare a folosirii ei.
1entru msurile care au n parantez cifra D sau E se 'or da n ane,a ( detalii pri'ind2
implementarea, interpretarea, consideraiile fcute, instruirea necesar, un e,emplu i e,periena
cerut.
a.3 =.&ur% #r!'u&
&unt ase su!categorii de msuri produs care au impact asupra fia!ilitii2
$ ( % Er!r%( 'e,ete( %n%'ente 2.'er%3 1 !nt!r%-ea-. 'e,etele lu;n' n !n&%'era/%e
er!area u"an.( *u+ur%le #r!+ra" )% ,un/%!n.r%le &%&te" at%#%e !*&ervateA
$ D % =TBFA rata 'e 'e,etare 2.'ere3 1 ".&ur% 'er%vate ale a#ar%/%e% 'e,et n t%"#A
$ E % Cre)tere ,%a*%l%tate )% #r!%e/%e 1 a#re%erea &5%"*.r%l!r ,.ute a ur"are a
a#ar%/%e% unu% 'e,et ntr1un #r!'u& a,lat &u* te&tare )% n !#erare 2,un/%!nare3.
$ J % De,ete re-%'uale 1 a#re%erea a#ar%/%e% 'e,etel!r r."a&e ne'e&!#er%te n
#r!'u& n t%"#ul 'e-v!lt.r%%( te&t.r%% &au "entenan/e%.
$ M % C!"#let%tu'%ne )% !n&%&ten/. 1 a#re%erea #re-en/e% !'ulu% tutur!r #.r/%l!r
&%&te"ulu% &!,t0are.
$ * % C!"#le$%tate 1 a#re%erea ,at!r%l!r '%,%%l% ntr1un &%&te".
*.3 =.&ur% #r!e&
.,ist trei su!categorii de msuri proces referitor la fia!ilitate2
$ ( % =.&ur%le 'e !ntr!l "ana+e"ent 1 &e re,er. la ant%tatea )% '%&tr%*u/%a er!r%% )%
'e,etel!r( relev;n' !&tul nee&ar #entru el%"%narea 'e,etel!rA
$ D % =.&ur%le 'e a!#er%re 2!vera+e3 1 &u&/%n a/%un%le !ret%ve #entru a a'ue
%n'%at!r%% 'e !vera+e la n%vele '!r%teA
$ E % Evaluare r%&ur%( *ene,%%% )% !&t 1 &u&/%n 'e%-%%le 'e l%vrare &!,t *a-ate #e
r%ter%% te5n%e )% 'e !&t.
Aiscul se poate aprecia prin defectele reziduale prezente n produs la li'rare i costul asociat
cu eliminarea acestora.
(+
()
T A B E L U L M
=A T R I C E A D E C L A S I F I C A R E =I S U R I 2 =E T R I C I 3
=.& ur% Pr !'u& =.& ur % Pr!e &
@r.
rt.
=.& ur % 2 e$#er % en/ .3
Er!r%(
De,ete(
In%'ente
=TBF
Rate 'e
'e,etare
Cre)tere
,%a*%l%tate
S
Pr!%e/%e
@r.
Re-%'ual
'e 'e,ete
C!"#let%tu'%ne
S
C!n&%&ten/.
C!"#le$%tate
C!ntr!l
=ana+e"ent
A!#er%re
2C!vera+e3
Evaluare(
R%&(
Bene,%%u(
C!&t
1 2 & ' + $ 8 9 " 1# 11
( Den&%tatea 'e,ete 223 G
D Den&%tatea 'e 'e,etare 2M3 G
E 1rofilul de cdere cumulati' $(% G
J Nr. zile-defecte $=% G G
M Acoperire testare modular sau funcii $(% G G G
* Cra,%ul au-. )% e,et 223 G G
C Tra&a*%l%tate er%n/e 2M3 G G G
+ -ndici de defectare $(% G G
) Distri!uie eroare $(% G
(= -nde, de maturitate software $(% G G
(( Ore !" 6 'e,ete "aL!re 'etetate 223 G G
(D @r. 'e er%n/e !n,l%tuale 223 G G G
(E Nr. de intrriBieiri pe modul $(% G G
(J =.&ur% ale %n+%ner%e% &!,t0are 2M3 G G
(M Iraful comple,itii teoretice pt. ar0itec. $(% G
(* C!"#le$%tatea %l!"at%. 2M3 G G
(C Deter". te&tare "%n%"al. un%tate 223 G G
(+ Ur".r%re ,%a*%l%tate 223 G
() 1roiectare structur $(% G
D= T%"# "e'%u #t. a 'eteta U 'e,ete 2M3 G
D( Ni'el de puritate software $(% G
( D E J M * C + ) (= ((
DD @r. e&t%"at 'e 'e,ete G
D=
r."a&e 2&ee'%n+3 223
DE /erine n acord $(% G G G
DJ A!#er%re te&t 223 G G
DM /omple,itate flu, date sau i-ii $(% G
D* Fun/%a 'e re)tere ,%a*%l%tate 223 G
DC Nr. de defecte reziduale $(% G
D+ Anal%-. %n%'ente n t%"# 2M3 G G
D) Testare suficien $=% G G
E= =TBF 2M3 G G
E( Rata 'e 'e,etare 2M3 G
ED D!u"enta/%e )% l%&t%n+ur% &ur&. 223 G
EE A.@Z - 8ia!ilitate software cerut $(% G G
EJ Iata de li'rare $=% G
EM /ompletitudine $D% G
E* 1recizie testare $(% G G G
EC F%a*%l%tate #er,!r"an/. &%&te" 223 G
E+ 8ia!ilitate proces independent $=% G
E) Disponi!ilitate operaional sistem
com!inat $5[B&[% $=%
G
D(
Tabel % <u+3rare Erori ;e#ecte, Incidente
@r.
rt.
=ETRICI
FANA CICLULUI DE JIAKI
/oncept
2 1 3
/erine
2 2 3
Design
2 M 3
-mplementare
2 > 3
Testare
2 9 3
-nstalare
'erificare
2 6 3
Operare
3entenan
2 8 3
Aetragere
2 8 3
( Densitate defecte V V V V V V V V
D Densitatea de
defectare
V V V V V V V V
E 1rofilul de cdere
cumulati'
V V V V V V V V
J Nr. zile - defect V V V V V V V V
C Transa!ilitate
cerine
V V V
+ -ndici de defectare V V V V V V V V
(D Nr. de cerine
conflictuale
V V
DE /erine n acord V V
Tabelul & MTF?/ Rata de de#ectare
@r.
rt.
=ETRICI
/oncept
2 1 3
/erine
2 2 3
Design
2 M 3
-mplementare
2 > 3
Testare
2 9 3
-nstalare
'erificare
2 6 3
Operare
3entenan
2 8 3
Aetragere
2 8 3
E= 3T48 V V V
E( Aata de defectare V V V
DD
Tabelul ! Cre.tere #iabilitate .i $roiecie
@r.
rt.
=ETRICI
2 1 3 2 2 3 2 M 3 2 > 3 2 9 3 2 6 3 2 8 3 2 8 3
(= -nde, de maturitate
software
V V V V V
(+ :rmrire fia!ilitate V V V
D( Ni'el de puritate
software
V V V
D* 8uncia de cretere
fia!ilitate
V V V
D+ Analiz incidente n
timp
V V V
D) Testare suficien V V
E= 3T48 V V V
EC 8ia!ilitate peforman
sistem
V V V V V V
E+ 8ia!ilitate proces
independent
V V
E) Disponi!ilitate
operaional sistem
com!inat $5[B&[%
V V V
Tabelul 6 Esti+are de#ecte re'iduale
@r.
rt.
=ETRICI
2 1 3 2 2 3 2 M 3 2 > 3 2 9 3 2 6 3 2 8 3 2 8 3
(J 3suri ale ingineriei
software $5alstead%
V
V
W
DD Nr. estimat de defecte
rmase $ seeding %
V V V
DC Nr. de defecte
reziduale
V V V
D+ Nr. de defectri n timp V V V
E* Testare precizie V
W DacU se sc0im!U codul sursei
Tabel > Co+-letitudine/ Consisten3
DE
@r.
rt.
=ETRICI
2 1 3 2 2 3 2 M 3 2 > 3 2 9 3 2 6 3 2 8 3 2 8 3
M Acoperire testare modular
sau funcional
V V V
* Iraficul cauz i efect V V V V V
C Transa!ilitate cerine V V V
(D Nr. de cerine conflictuale V V
(* /omple,itate ciclomatic
$faza testare %
V V V
DJ Testare acoperire V V V V V
ED Documentaie listinguri
surs
V V V V
EM /ompletitudine V V V
E* Testare precizie V
Tabelul Co+-le0itate
@r.
rt.
=ETRICI
2 1 3 2 2 3 2 M 3 2 > 3 2 9 3 2 6 3 2 8 3 2 8 3
(E Nr. de intrriBieiri pe
modul
V V V
software $5alstead%
V V
(M Iradul comple,itii
teoretice ptr. at0itectur
V V V
(* /omple,itatea ciclomatic V V V
(C Determinare testare
minimal
V V V
() 1roiectare structur V V
DM /omple,itate flu, date sau
informaii
V V V
Tabel 1" Control Manage+ent
DJ
@r.
rt.
=ETRICI
2 1 3 2 2 3 2 M 3 2 > 3 2 9 3 2 6 3 2 8 3 2 8 3
J Nr. de zile - defect V V V V V V V
+ -ndice de defectare V V V V V V
) Distri!uie$i% eroare V V V V V V
(( Ore omBdefecte ma9ore V V V V V V
D= Timpul mediu pentru a
descoperi urmtoarele T
defecte
V V V
Tabel 11 @co-erirea test3rii ( co2erage )
@r.
rt.
=ETRICI
2 1 3 2 2 3 2 M 3 2 > 3 2 9 3 2 6 3 2 8 3 2 8 3
sau funcional
V V V
* Iraficul cauz i efect V V V V V
C Transa!ilitate cerine V V V
(D Nr. de cerine conflictuale V V
DJ Acoperire test V V V V V V
D) Testare suficien V V
ED Documentaie listinguri
surs
V V V V
EE A.@Z - 8ia!ilitate
software cerut
V V V V V V V
EM /ompletitudine V V V
E* 1recizie testare V
Tabel 12 E2aluare, Risc, ?ene#iciu .i Cost
@r.
rt.
=ETRICI FANA CICLULUI DE JIAKI
DM
2 1 3 2 2 3 2 M 3 2 > 3 2 9 3 2 6 3 2 8 3 2 8 3
sau funcional
V V V
(= -nde, de maturitte
software
V V V V V
(( Ore omBdefecte ma9ore
detectate
V V V V V V
software
V V
(+ :rmrire fia!ilitate V V V
() 1roiectare structur V
D= Timpul mediu pentru a
detecta urmtoarele T
defecte
V V V
D( Ni'el de puritate software V V V
DC Nr. de defecte reziduale V V V
E( Aata de defectare V V V
EE A.@Z - 8ia!ilitatea
software cerut
V V V V V V V
EJ Iata de li'rare V V
D*
2.&.+.2. *ta/ele ciclului de 5ia software
1entru a 'eni n spri9inul utilizatorului, n sensul de a ti cnd s aplice msurile respecti'e
software-ului, ciclul de 'ia s-a di'izat n $fig. (=%2
timpuriu<
mi9lociu<
trziu.
>n segmentul t%"#ur%u msurile 'izeaz au-ele #!ten/%ale ale ,%a*%l%t./%% &%&te".
Di'iziunea "%Ll!%e se refer la re'uerea er!r%l!r 'e #r!e&, care pot m!unti eficiena
dez'oltrii software. Ult%"ul &e+"ent refer ".&ur%le 'e #er,!r"an/. ale ,%a*%l%t./%% &%&te".
Fig.1" Clasi#icarea ciclului de 2ia3
Pr!e&ul 'e ".&urare
1rocesul de msurare a fia!ilitii poate fi descris n nou etape $fig. ((%.
Ae&te eta#e &e #!t &u#ra#une &au a#ar n '%,er%te &even/e, funcie de ne'oile de
organizare.
8iecare etap urmrete o!inerea unui produs cu potenial nalt de fia!ilitate.
Ali factori care influeneaz procesul msurrii2
un !"%tet 'e "ana+e"ent ,er" are &. a#re%e-e !nt%nuu "atur%tatea #r!e&
)% #r!'u& &au &ta*%l%tatea 2!r% a";n'!u.3A
,!l!&%rea #er&!nalulu% #re+.t%t n a#l%area ".&ur%l!r unu% #r!%et ntr1un "!'
ut%lA %n&tru"ente &!,t0are ut%l%-ateA
n/ele+erea '%&t%n/%e% '%ntre er!r%( 'e,ete )% 'e,et.r%.
*ta/a 1. Plan%,%area !r+an%-a/%!nal1&trate+%.
&e iniializeaz un proces de planificare2
-mplementare
Se+"ente ale %lulu% 'e v%a/.
Timpuriu
3i9lociu Trziu
/oncepte
/erine
1roiectare
Testare
-nstalare
i
7erificare
funcional
Operare
i
3entenan
Aetragere
DC
&e identific ce caracteristici de fia!ilitate ale produsului software sunt necesare
pentru aceste o!iecti'e<
&e sta!ilete o strategie pentru msurarea i managementul fia!ilitii software<
&e sta!ilesc practici documentate pentru conducerea msurtorilor.
*ta/a a 2-a< Deter"%narea &!#ur%l!r ,%a*%l%t./%% &!,t0are
&e definesc scopurile de fia!ilitate pentru software-ul care se dez'olt, innd seama
de restriciile proiect2 '%"en&%unea( !&tul )% #lan%,%area<
&e sta!ilete un domeniu accepta!il de 'alori<
&e sta!ilesc inte pentru fia!ilitatea intermediar n diferite momente ale efortului de
dez'oltare.
*ta/a a &-a< I"#le"entarea #r!e&ulu% 'e ".&urare
&e sta!ilete un proces de msurare fia!ilitate software care se potri'ete cel mai !ine cu
cerinele organizaiei.
&e re'd etapele J \ + i se selecteaz acelea care conduc cel mai !ine la fia!ilitatea optim,
funcie de mediul de lucru specific.
*ta/a a '-a. Seletare ".&ur% #!ten/%ale
&e identific msurile poteniale care ar putea fi folositoare n atingerea o!iecti'elor de
fia!ilitate sta!ilite n etapa a D-a. &e folosete ta!elul E pentru a determina ce categorie sau categorii
ale msurtorilor de fia!ilitate ar putea fi cele mai folositoare proiectului.
*ta/a a +-a. Pre+.t%rea !le/%e% 'e 'ate )% a #lanulu% 'e ".&urare
1entru fiecare msur potenial se determin primiti'ele necesare n e,ecutarea msurtorii.
Datele tre!uie organizate de aa fel nct informaiile referitoare la e'enimente din timpul
dez'oltrii s fie nregistrate corespunztor ntr-o !az de date i reinute pentru a monitoriza istoria
proiectului sau a face pre'iziuni.
*ta/a a $-a< =!n%t!r%-are ".&ur.t!r%
Odat ce colectarea datelor i prezentarea lor ncep, se monitorizeaz msurtorile i
progresul fcut n timpul dez'oltrii pentru a se putea conduce fia!ilitatea i astfel s poat fi atinse
elurile pentru li'rarea produs.
&e pot lua msuri corecti'e pentru a m!unti caracteristicile software.
*ta/a a 8-a. A#re%ere ,%a*%l%tate
&e analizeaz msurtorile pentru a se asigura c fia!ilitatea produsului rezultat
satisface o!iecti'ele sta!ilite i c este accepta!il<
&e 'erific consistena criteriului de acceptare i suficiena testelor care demonstreaz
c o!iecti'ele de fia!ilitate au fost atinse<
&e documenteaz paii parcuri n aprecierea fia!ilitii software<
&e asigur c m!untirile de fia!ilitate n software au fost fcute.
*ta/a a 9-a< F!l!&%re &!,t0are
&e apreciaz efecti'itatea efortului de msurare i se e,ecut aciunea corecti'
necesar<
&e face o analiz atent a efortului de msurare n scopul aprecierii fia!ilitii produs
i a practicilor de dez'oltare<
&e nregistreaz leciile n'ate i se e'alueaz satisfacia utilizator 'iza'i de
fia!ilitatea software<
&e identific practicile care sunt inefecti'e i cerinele care indic necesitatea
dez'oltrii i rafinrii msurtorilor i metricilor 'iitoare.
*ta/a a "-a. Re/%nerea 'atel!r 'e&#re ".&ur.t!r%le &!,t0are
D+
Datele procesului de dez'oltare i din timpul operrii se rein $se nregistreaz% pentru
proiecte 'iitoare. .le formeaz !aza pentru m!untirea fia!ilitii i comparaiilor msurilor
utilizate n mai multe proiecte.
Fig. 11 $rocesul de +3surare a #iabilit3ii
O!iecti'ele
de fia!ilitate sunt
satisfcute
1. 1lanificare
strategic organizational
2. Determinare scopuri
fia!ilitate software
&. -mplementare
a unui proces de msurare
'. &electare
msuri poteniale
+. 1regtirea unui
plan de msurare i
a unei colecii de date
$. 3onitorizarea
msurtorilor
8. Aprecierea
fia!ilitii
9. 8olosire
software
". Aeinerea datelor
despre msurtorile
software
&copuri de
fia!ilitate
intermediar
1roces de
msurare
fia!ilitate
Aestricii
i
o!iecti'e
Necesiti
utilizator
Date de
performan
software
A9ustri
necesare
>m!untiri necesare
&atisfacie
utilizator
.'aluare practici de
msurare
DA $ A//.1TA4-@]%
&-a construit
fia!ilitate
N:
N:
fia!ilitate
D)
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 !IE"TI#E P$%&'E FI(A)E
Cerine utilizator Formularea problemei Specificaii cerine utilizator
Cerine softare Analiza problemei Cerine !i specificaii softare
"roiectarea ar#itecturii Soluii de proiectare "roiect de ansamblu
"roducie $mplementare "roiect de detaliu% softare testat
&ransfer $nstalare Softare instalat% instruire clieni% depanare
'entenan (voluie produs softare Softare ntreinut !i dezvoltat
Felul n care se grupeaz activitile !i succesiunea fazelor duc la diferite modele care
implementeaz ciclul de via.
)n model al ciclului de via descrie activitatea de realizare a produsului softare !i flu*ul
procesului de dezvoltare.
+intre cele mai cunoscute modele% in,nd seama de evoluia lor n timp% putem enumera
-CSA./01:
'odelul n cascad
'odelul incremental
'odelul evolutiv
'odelul n spiral
$nginerie softare bazat pe model
I. Modelul *n cascad+
(ste un model tradiional de dezvoltare softare% care presupune c dezvoltarea ncepe cu
definirea cerinelor !i a specificaiilor 2secvenial% dar !i altern,ndu3le4.
)rmeaz proiectarea% dup care se pot implementa module mici ce se pot testa separat !i
apoi mpreun5 dup ce se termin testul de integrare% produsul softare este testat !i livrat la
beneficiar% urm,nd faza de mentenan 2fig. 1 4.
Fig.1 Modelul de dezvoltare n cascad
6n acest model intrrile unei faze sunt ie!irile alteia.
Feedbac73ul e generat de erorile care se repercuteaz asupra fazei urmtoare.
(rorile se propag indirect% antren,nd costuri de modificare% de aceea fiecare faz trebuie
testat foarte atent.
+ac se utilizeaz modelul n domenii mai puin cunoscute% pot interveni costuri mari%
antrenate de nelegerea eronat a cerinelor% fapt descoperit ntr3o etap t,rzie% 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 2anali!ti%
programatori% testeri !.a.4 !i se poate afirma c este o strategie de implementare clasic.
II. Modelul incremental
(tapele finale se realizeaz n mai muli pa!i succesivi% fapt ce permite obinerea de mai
multe versiuni ale produsului softare 2fig. 84.
)tilizare !i mentenan
&estare
$mplementare cod
"roiectare
Analiz
+efinire cerine
Cerine utilizator
Cerine softare
"roiectare ar#itectural
"roiectare detaliat !i
producie
Transfer
Fig.2 Modelul incremental
'odelul are caracteristicile:
timp
analiza !i proiectul ar#itectural se realizeaz ntr3o singur component5
proiectarea detaliat% producia% transferul !i mentenana au loc n mai muli pa!i
succesivi5
obinerea produsului softare pe pa!i permite verificarea dac acesta va da
rezultatele scontate5
riscul e divizat la c,teva incremente mai mici n loc s se concentreze pe o
dezvoltare ampl5
nelegerea cerinelor pentru incrementele ulterioare e mai bun% aceast metodologie
fiind foarte adecvat programelor de risc sczut mediu5
modelul incremental e mai bun dec,t modelul n cascad% necesit,nd o organizare
suplimentar% dar prin obinerea de mai multe versiuni ofer posibilitatea cre!terii
calitii produsului softare.
III. Modelul e,oluti,
Fa de modelele prezentate anterior% cere o organizare mai bun !i un management mai
complicat. (ste foarte indicat !i util c,nd specificaiile iniiale nu sunt foarte clare sau c,nd se
realizeaz un softare nou !i nu se pot formula specificaii precise !i complete sau acestea nu sunt
stabile -"9(S/:1.
'odelul evolutiv% prin parcurgerea pa!ilor si% creaz un prototip iniial% care% la final% prin
reluarea etapelor va satisface cerinele clienilor 2fig. :4.
Cerine utilizator
Cerine softare
"roiectare ar#itectural
"roiectare detaliat !i
producie
&ransfer
Fig.3 Modelul evolutiv
A*at pe protopizare% prin reluarea tuturor fazelor% modelul acesta construie!te un produs n
timp mai ndelungat% dar ofer posibilitatea rezolvrii unor probleme noi sau adugarea de funcii
noi cerute de utilizatorii produselor softare.
timp
"rototipul este folositor utilizatorului final care va nelege mai bine ce dore!te sau ce se
vrea de la produs% el fiind implicat n ntreg procesul de dezvoltare2fig. 1;4 !i e util !i realizatorului
n testarea unor te#nici% algoritmi sau interfee realizate.
6n ceea ce prive!te prototipul% el are dou forme:
prototipul de ncercare% care trebuie realizat rapid% c#iar dac e incomplet !i care se
utilizeaz pentru validarea interfeei !i a unor algoritmi implementai% urmrind
construirea unei ar#itecturi care s rspund c,t mai bine cerinelor utilizatorilor5
prototipul evolutiv% care dezvolt produsul final% av,nd ca scop nglobarea tuturor
caracteristicilor de calitate formulate5 acest prototip evolueaz mai lent% dar permite
mbuntirea continu a calitii produsului final% reduc,nd astfel costurile de
mentenan.
Acest model este utilizat de programele cu risc mediu nalt.
"rovocarea pentru dezvoltatorii de sistem va consta n a concepe un proces de dezvoltare
care va descoperi% defini !i formula cerinele reale% implic,nd direct utilizatorii !i test,nd versiunile
intermediare ale prototipurilor.
9aportat la cerinele pieei% modelul poate oferi o soluie evolutiv sau una revoluionar
2prin strategia agresiv4.
Combinarea celor dou soluii% in,nd seama de studiile de pia% poate duce la o soluie
intermediar.
9eluare p,n c,nd produsul e complet

<$ngineria< unui
prototip
Setare obiective:
performan5
te#nice5
calitate 2fiabilitate4
Fig.4 Implicarea utilizatorului n modelul evolutiv
Codificare !i testare prototip
Alegerea ar#itecturii sistemului
=ivrare prototip pentru evaluarea utilizator
Analiza rezultatelor "regtirea planului de dezvoltare evolutiv
Feedbac7 utilizator
Feedbac7 utilizator
I#. Modelul *n spiral+
'odelul a fost dezvoltat de .arr> .oe#m !i furnizeaz o concepie de reducere a riscului n
ciclul de via softare. (l porne!te de la premisa c n faza de mentenan a produselor softare
pot aprea probleme care necesit definirea de noi cerine de specificare% de analiz !i proiectare
-?ACO/@1.
'odelul n spiral 2fig. 114 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 A<
Actualmente% maBoritatea programelor folosesc o combinaie a celor trei modele.
'odelul n spiral este o combinaie a modelului incremental cu cel evolutiv% la care se
adaug managementul riscului.
C#eia alegerii unei metode de dezvoltare e diriBat de factori ca 2at,t pentru softul militar
c,t !i cel civil4:
214 timpul de livrare pe pia5
284 nelegerea cerinelor5
2:4 perimarea te#nologiei5
2C4 orientarea necesitilor utilizatorilor5
2D4 comple*itatea5
2@4 amplitudinea efortului investit5
2E4 ciclul de via anticipat al sistemului5
204 dezvoltarea de #ardare n paralel.
'odelul are acelea!i etape de realizare% ns fiecare ciclu de dezvoltare ncepe cu studiul de
fezabilitate% continu,nd apoi cu specificarea cerinelor% analiza% proiectarea !i implementarea.
AFA=$GH
"9O$(C&A9(
S"(C$F$CAI$$ C(9$FI(
vC v:
v8
v1
$'"=('(F&A9( J$ &(S&A9( $F+$K$+)A=H
K(9S$)F( F$FA=H
$F&(L9A9(
Fig. Modelul n spiral
Fiecare dintre etapele modelului n spiral cuprinde o succesiune de activiti:
determinarea obiectivelor etapei% a variantelor posibile !i a restriciilor5
evaluarea alternativelor% identificarea riscurilor !i soluionarea lor5
dezvoltarea !i verificarea urmtorului nivel al produsului5
ntocmirea planului etapei urmtoare% analiz,nd riscurile.
Criteriul care st la baza alegerii unor alternative de implementare este costul implicat.
6n esen% dezvoltarea produselor softare conine toate fazele !i activitile descrise% c#iar
dac se numesc altfel n diferite metodologii% dezvoltarea av,nd loc incremental% indiferent de
metoda de dezvoltare aleas.
=a nceput un grup mic de persoane face analiza !i proiectarea% ntr3o manier iterativ.
C,nd 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 timpMefort pe faze% pot
arta ca n fig. @ .
Fig.! "elaia e#ort$timp
efort
&estare
$mplementare
"roiectare
Analiz
timp
Construirea% n ultimul timp% a unor instrumente care asist realizarea produselor softare n
toate fazele% au permis noi abordri ale ciclului de via 2instrumente CAS( 3 Computer Aided
So#t%are Engineering4.
Aceste instrumente CAS( implementeaz metodologiile de realizare a produselor softare
bazate pe structura funcional% pe structura bazelor !iMsau metodologiile orientate obiect% permi,nd
construirea% verificarea% validarea% testarea% memorarea !i reutilizarea componentelor aplicaiilor !i
produselor program.
"rin furnizarea unor modele de analiz3proiectare !i prin generarea automat de cod pentru
aceste modele% instrumentele CAS( permit obinerea unor produse fiabile !i de calitate% reduc,nd
totodat termenele de livrare.
#. Inginerie soft-are .a/at+ pe model
"resupune dezvoltarea produsului softare av,nd la baz un model care s u!ureze
nelegerea construirii acestuia.
Se au n vedere urmtoarele tipuri de modele:
'odele de produse softare
Acestea ofer o form grafic de programare de nivel foarte nalt.
'odelele se pot simula !i anima pentru a oferi feedbac7 !i suport pentru verificarea !i
evaluarea performanelor.
'odele de procese 3 utilizate n toate activitile ciclului de via.
"ot fi implementate asemntor cu cele de produse softare.
Lenerarea de cod pentru modele.
'odelele pot fi mbuntite !i stocate automatizat pentru a fi incluse n programe.
'odele de testare.
Asigur testarea prin modelare !i simularea driverelor e*terne.
Folosirea modelelor presupune a urma acelea!i faze ale ciclului de via% ntr3o etap
rafin,ndu3se modelul din faza precedent.
$ngineria softare bazat pe modele presupune e*istena unor instrumente CAS( care s
implementeze modelele% oferind avantaBe deoarece:
modelul e o reprezentare abstract a sistemului considerat% folosit pentru a3i studia
proprietile5
modelele permit formalizarea cerinelor !i depistarea inconsistenei !i
incompletitudinii.
6n ceea ce prive!te produsele softare% se folosesc:
modele funcionale 2diagrame de flu* de date +F+3+ata Flo +iagram45
modele de date 2diagrame entitate3relaie (9+3(ntit> 9elations#ip +iagram45
modele de control 2diagrame de tranziie a strilor S&+3 States &ransition +iagram%
diagrame "(&9$45.
O alt clasificare mparte modelele produselor softare n:
modele descriptive 2statice45
modele operaionale 2dinamice4% ce pot simula comportarea sistemului la utilizator.
'odelele operaionale !i evolutive pot e*ecute !i testa produsul n fiecare faz% permi,nd
controlul de calitate !i asigurarea fiabilitii pe ntreg ciclului de via.
+ezvoltarea a*at pe model necesit% pentru toate tipurile de modele 2funcional% de date% de
control4:
un limbaB de modelare cu o semantic clar% care s se utilizeze la toate nivelurile
2analiz% proiectare4 !i de ctre ntreg personalul implicat 2anali!ti% programatori%
utilizatori45
o te#nologie care s fie documentat !i care s cuprind un editor grafic% un
generator de cod !i o baz de date pentru simulare !i aplicaii 2de e*emplu% "oer
+esigner Suite al firmei S>base4.

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.

radul 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 flu"urilor stabilite# cu
utilizarea resurselor adec$ate!
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 rezol$area curenta a problemelor aparin%nd
clasei pentru care a fost elaborat!
e) capacitatea de mentenan - msura n care pot fi
eliminate anomaliile ce apar n timpul e"ecuiei sau pot fi
puse de acord noi cerine de prelucrare cu efortul pentru
implementare.

!articularitile 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 e"emplare.
Calitatea copiilor este aceeai cu cea a originalului# deci o calitate necorespunztoare
se poate propaga cu efecte nefa$orabile# antren%nd costuri de remediere foarte mari i
afect%nd imaginea firmei productoare!
- produsele software nu sunt supuse uzurii fizice# ele se erodeaz numai din punct de
$edere moral# atunci c%nd nu mai corespund noilor cerine sau c%nd apar produse
software mai performante care realizeaz aceleai funciuni!
- pentru a putea utiliza produsele software este nevoie de un procesor care sa le ruleze.
&istemele de calcul i de operare sunt supuse# de asemenea# uzurii morale# pun%ndu-
se i n acest caz problema transferrii produsului software ntr-un alt mediu. 'n
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 pro$ocate 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 comple"e# mai
ales daca acestea ruleaz n cadrul unor aplicaii comple"e!
- erorile e"ist de(a 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.

#valuarea calitii produselor
program
Caracteristicile de calitate
$. %iabilitatea: un program posed caracteristica de fiabilitate n msura n care ndeplinete funciile de
prelucrare cerute de beneficiar# pe un inter$al de timp dat# fr erori!
). Corectitudinea: un produs program este corect daca transformrile pe care le efectueaz conduc la
obinerea de rezultate ce corespund calitati$ i cantitati$ cu specificaiile de programare!
*. #ficacitatea: realizeaz o corelaie c%t mai adec$at ntre consumurile de resurse +timp de e"ecuie#
memorie intern# tipuri i numr periferice) i comple"itatea problemei ce se rezol$!
,. &igurana n utilizarea curent: stabilete msura n care un program aplicati$ nu permite efectuarea
de modificri neautorizate sau nedorite n $olume de date# precum i distrugerea parial sau total a
$olumelor de date!
-. &tabilitatea: indic .rezistenta. programului aplicati$ fa de efectele generate de o modificare a datelor
iniiale# c%t i n sec$enele de instruciuni care compun modulele care intr n componenta sa!
/. 'entenabilitatea: msura n care este permis actualizarea rapid si uoar a produsului program
pentru a putea continua utilizarea acestuia c0iar n condiii modificate!
1. (daptabilitatea: capacitatea produsului program de a permite integrarea de noi funcii de prelucrare i
de a include acele sec$ene de instruciuni care mresc performanta programului# aduc%ndu-l la ni$elul
eficienei de utilizare de la un moment dat# ulterior elaborrii!
2. )iniaritatea: msoar gradul n care la elaborarea unui modul# a unei sec$ene sunt utilizate instruciuni
care se e"ecuta una dup alta sau msura n care nu sunt utilizate instruciuni de salt condiionat sau
necondiionat.
3. Claritatea: un produs program este considerat neclar atunci c%nd sec$enele ce formeaz modulele sale
conin instruciuni ce pot lipsi fr a fi afectata calitatea rezultatelor finale!
45. *eutilizabilitatea: reprezint capacitatea unor module ale produsului program de a fi ncorporate n
alte programe a$%nd rezultat direct economia de munca!
44. !ortabilitatea: este caracteristica de calitate care pune n e$iden gradul n care un produs program
poate fi rulat pe mai multe tipuri de calculatoare!
4). +ntegrabilitatea: este caracteristica de calitate care arata gradul n care produsele program pot fi
incluse n sisteme comple"e de prelucrare a datelor.

(tributele calitii
4. testabilitatea: ofer utilizatorilor posibilitatea de a pune n e$iden c%t mai
multe $ariante de probleme ce pot fi rezol$ate i comportamentul
programului aplicati$ n situaii particulare +fiiere $ide# date incomplete#
date neconsistente)!
). completitudinea: este atributul ce d msura n care modulele produsului
software sunt parial acti$abile i fiecare realizeaz funcia de prelucrare
dat n specificaii!
*. generalitatea: este atributul care pune n e$iden aria de cuprindere a
funciilor de prelucrare# $ariantele problemei ce pot fi rezol$ate# cazurile
particulare# dimensiunile ma"ime ce se iau n considerare!
,. consistena: pune n e$ident msura n care modulele realizeaz funcii de
prelucrare necontradictorii i se bazeaz pe uniformizare n folosirea
simbolurilor# a regulilor de construire a identificatorilor# etic0etelor i n
general a sec$enelor omogene!
-. complexitatea: fiecrui program aplicati$ i se asociaz o reprezentare sub
form arborescent sau o alt form grafic ce conine noduri i arce
orientate. Comple"itatea este un atribut care permite stabilirea diferenelor
dintre structurile programelor i ierar0izarea programelor dup noduri# arce
i modul de orientare a acestora din urm.
/. flexibilitatea: determin $olumul de restricii impus utilizatorilor pentru a
obine rezultate complete i corecte prin folosirea unui program aplicati$!
programul aplicati$ este cu at%t mai fle"ibil cu c%t $olumul restriciilor este
mai redus!
1. modularitatea: este atributul de calitate care descrie ordinea din cadrul
produsului format din module.

6odele ale calitii software
modelul 7oe0m
modelul 8ames 6cCall.

'odelul ,oehm
definete urmtoarele caracteristici de

calitate:
9
portabilitate#
9
fiabilitate#
9
eficien#
9
testabilitate,
9
usurina nelegerii - gradul n care obiecti$ele
i scopul produsului sunt clar definite#
9
modificabilitate - gradul n care produsul
faciliteaz efectuarea sc0imbrilor.

:tributele de calitate ale modelului
7oe0m
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 0ardware-ul)#
accesibilitate - gradul n care produsul prezint componentele sale
ntr-o manier organizat#
structuralitate - gradul n care produsul nu conine informaii
e"cesi$e#
lizibilitate - gradul n care funciunile produsului pot fi identificate prin
citirea codului sursa#
extensibilitate - gradul n care produsul faciliteaz e"tinderea sa cu

noi funciuni de prelucrare

'odelul -ames 'cCall
mbuntete modelul 7oe0m
st la baza elaborarii standardului ;&< 34)/ din 4334.
Factorii de calitate pre$zuti de 6cCall sunt grupai n trei categorii:

9 e"ploatarea i utilizarea produsului:
corectitudine!
fiabilitate!
eficiena +$olumul 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 n$area produsului i pentru pregtirea
datelor de intrare)!
9 re$izia produsului:
mentenabilitate!
testabilitate!
flexibilitate
9 tranziia produsului:
portabilitate!
reutilizabilitate!
interoperabilitate +efortul necesar pentru a cupla produsul cu alte produse).

'surarea nivelului calitii
+software metrics 9 metrici software) disciplina destinat

construirii i analizei indicatorilor cu care se e$alueaz
ni$elul caracteristicilor de calitate
=entru o caracterizare concret trebuie respectate

urmtoarele cerine:
9 a. ierar0izarea caracteristicilor de calitate msurabile# dup
importana pe care ele o prezint la beneficiar!
9 b. e$aluarea c%t mai precis a ni$elului fiecrei caracteristici i
sporirea efortului pentru creterea preciziei!
9 c. ni$elul ma"im al caracteristicii trebuie s fie asociat produselor
program cele mai bune!
9 d. stabilirea modului n care se utilizeaz informaia pri$ind
calitatea# pentru creterea duratei ciclului de $ia al produsului
program.

;ndicatorii de calitate pentru caracteristici# atribute# metrici sunt caracterizai prin: $aloarea
i ponderea indicatorului# relaii de influenare +conflictuale sau complementare) i relaii de
ierar0izare +care se stabilesc ntre indicatorii ce se afla n relaii de subordonare).
>n cazul relaiilor de ierar0izare# indicatorilor subordonai le sunt asociate ponderi care
semnific gradul de importan fa de ceilali indicatori subordonai aceluiai indicator-
printe. &uma ponderilor de pe un ni$el inferior subordonat unei caracteristici de calitate
este constant i egal cu 4 +cel mai utilizat sistem de ponderi).
unde n 9 numrul de indicatori ( de pe ni$elul inferior subordonat indicatorului i.
?aloarea a unui element de e$aluare se stabilete cu relaia:
@ - numarul de ordine al metricii#
A 9 numrul de ordine al elementului de e$aluare#
& 9 numrul total de e$aluri ale aceluiai element de e$aluare#
s 9 numrul de ordine al e$alurii elementului de e$aluare#
9 $aloarea asociata elementului de e$aluare A subordonat metricii @ pentru e$aluarea s

&tandarde de calitate
&tandarde pentru managementul calitii
=e plan internaional# domeniul managementului i

asigurrii calitii este reglementat prin standardele ;&<
seria 3555# care descriu cerinele pentru sistemul calitii
ntr-o organizaie# fr a specifica ns modalitatea de
implementare a acestuia.
&tandardele ;&< seria 3555 pot fi utilizate n urmtoarele

situaii:
9
:sigurarea intern a calitii# la iniiati$a conducerii organizaiei!
9 Cerine contractuale ntre furnizor i client referitoare la sistemul
calitii pentru furnizor!
9 E$aluare de aderen# caz n care furnizorul este e$aluat de
ctre client pentru conformitatea sistemului calitii cu un
standard de referin!
9
Certificarea sistemului calitii de ctre o ter parte +un
organism de certificare) n raport cu cerinele unui standard de
referin.

&tandardele din seria ;&<# traduse
n limba rom%n
&* +&. /012" $3345 Ediia a )-a: 6anagementul calitii i asigurarea calitii - $ocabular
&* +&. 3111-$" $336! Ediia a )-a: &tandarde pentru managementul calitii i asigurarea
calitii - =artea 4: B0id pentru selecie i utilizare
&* +&. 3111-2 " $3345 Ediia 4: &tandardele pentru conducerea calitii i asigurarea calitii -
=artea ): B0id pentru aplicarea ;&< 3554# ;&< 355) si ;&< 355* la dez$oltarea# li$rarea i
mentenana software-ului
&* +&. 3111-7" $3345 Ediia 4: &tandardele pentru conducerea calitii i asigurarea calitii -
=artea ): B0id pentru aplicarea ;&< 3554 la dez$oltarea# li$rarea i mentenana software-
ului
&* #8 +&. 311$: 433-! Ediia a )-a: &istemele calitii - 6odel pentru asigurarea calitii n
proiectare# dez$oltare# producie# monta( i ser$ice
&* #8 +&. 3112: 433-! Ediia a )-a: &istemele calitii - 6odel pentru asigurarea calitii n
producie# monta( i ser$ice
&* #8 +&. 3117: 433-! Ediia a )-a: &istemele calitii - 6odel pentru asigurarea calitii n
inspecii si ncercri finale
&* #8 +&. 3110-$" $3365 Ediia 4: 6anagementul calitiii i elemente ale sistemului calitii -
=artea 4: B0id
&* +&. 3110-2"$33$5 Ediia 4 : Conducerea calitii i elemente ale sistemului calitii - =artea
a )-a: B0id pentru ser$icii
&* +&. 3110-7"$337! Ediia 4: Conducerea calitii si elemente ale sistemului calitii - =artea
a *-a: B0id pentru materiale procesate
&* +&. $11$$-$"$330! Ediia 4: B0id pentru auditarea sistemelor calitii- =artea 4: :uditare
&* +&. $11$$-2"$337! Ediia 4: B0id pentru auditarea sistemelor calitii- =artea a )-a: Criterii
de calificare pentru auditorii sistemelor calitatii
&* +&. $11$$-7"$330! Ediia 4 : B0id pentru auditarea sistemelor calitii- =artea a *-a:
Conducerea programelor de audit
&* +&. $11$7"$336! Ediia 4 : B0id pentru elaborarea manualelor calitii

:lte standarde netraduse n limba rom%na
;&< 3555-,:433* CependabilitD 6anagement
;&< 355,-,:433* EualitD ;mpro$ement
;&< 355,-- EualitD :ssurance =lans
;&< 355,-/ =ro(ect 6anagement
;&< 355,-1 Configuration 6anagement
;&< 355,-2 EualitD =rinciples
;&< 4554)-4:433) 6anagement of 6easurement

EAuipement
;&< 4554)-) Control of 6easurement =rocesses

Cerinele ;&< 3555 pri$ind sistemele de
calitate

&tandardele calitii produselor software
&tandardul ;&<F;ECF34)/ - Caracteristici de calitate

software i metrici 9 are urmatoarele componente:
9
34)/F4 9 Caracteristici i subcaracteristici de calitate!
defineste caracteristicile i subcaracteristicile de calitate!
se utilizeaz pentru specificarea cerinelor de calitate# e$aluarea
calitii produsului# proiectarea listei de $erificare pentru re$izuirea
proiectrii i testare.
9 34)/F) 9 6etrici e"terne!
definete un set de metrici e"terne pentru msurarea unei
caracteristici sau subcaracteristici de calitate!
se utilizeaz pentru specificarea cerinelor de calitate# e$aluarea
calitii produselor n fazele de testare i acceptare# dez$oltarea de
noi metrici.
9
34)/F) 9 6etrici interne!
definete un set de metrici interne utilizabile la msurarea atributelor
interne ale produselor software!
se utilizeaz pentru definirea scopurilor proiectului# re$izuirea
produselor intermediare# dez$oltare de noi metrici.

&tandardul ;&<F;EC 4,-32 9 E$aluarea =roduselor &oftware 9 are
urmtoarele componente:
9 4,-32F4 - definete termenii utilizai i prezint cerine i recomandri
generale pri$ind specificarea i e$aluarea calitii produselor software!
9 4,-32F) - definete cerine pri$ind managementul proceselor suport n
e$aluarea produsului software i face recomandri pri$ind dez$oltarea i
utilizarea unui plan de msurare!
9 4,-32F* 9 este destinat fazei de dez$oltare a produsului software i
conine criterii de selectare a metricilor i recomandri pri$ind $erificarea
i $alidarea caracteristicilor de calitate# analiza msurrii# ameliorarea
procesului de e$aluare!
9 4,-32F, 9 definete un proces de e$aluare a calitii unui produs
software# utilizabil pentru selectarea unui produs din mai multe produse
sau de acceptare a unui produs utiliz%ndu-se caracteristicile de calitate
i metricile din standardul 34)/ i modelul de e$aluare 4,-32-4!
9 4,-32F- 9 definete cerine i face recomandri pri$ind e$aluarea
produselor software aflate n faza de li$rare-implementare!
9 4,-32F/ 9 definete cerinele pri$ind documentaia ce nsoete
e$aluarea produsului software i face recomandri pri$ind dez$oltarea i
$alidarea e$alurii

&tandarde de calitate a procesului de realizare
a produselor software -
&oftware Capabilit9 'aturit9 'odel :&;-C''<
C66 pre$ede cinci ni$ele de maturitate:

4. +nitial. =rocesul de dez$oltare poate fi caracterizat ca ad-0oc si
ocazional# c0iar 0aotic. 'n numr mic de procese sunt definite# iar
succesul depinde de eforturile indi$iduale ale lucrtorilor.
). *epeatable. &unt stabilite procese de baz ale managementului
de proiect pentru urmrirea costurilor# planului de lucru i a
funcionalitaii. E"periena e"istent asigur repetabilitatea
succesului n proiecte cu aplicaii similare.
*. =efined. :t%t procesul de management c%t si cel de dez$oltare
este documentat# standardizat i integrat ntr-un proces standard al
organizaiei. Goate proiectele folosesc o $ersiune a(ustat i
aprobat a procesului standard.
,. 'anaged. :re loc colectarea datelor care masoar calitatea
procesului i a produsului. :mbele procese +management si
dez$oltare) sunt gestionate i controlate n plan cantitati$.
-. .ptimizing. =rocesele pot fi continuu mbuntite cu a(utorul
feedbac@-ului cantitati$ i al ideilor i te0nologiilor no$atoare.

(plicarea +&. 311$ pentru
industria software
Factorii de succes pentru mbuntirea proceselor

software prin ;&< 3554 sunt:
definirea i documentarea strii curente
identificarea celor mai bune practici
identificarea proceselor lucrati$e
simplificarea procedurilor de rutin
audituri interne
spirit de ec0ipa
ateliere de lucru +wor@s0op-uri)
definirea unui limba( comun
studii ale percepiei clientilor

%+(,+)+>(>#( !*.=?&#).*
&.%>;(*#. =#%+8+*# @+ .,+#C>+A#
Fiabilitatea software e un obiecti$ de

calitate ma(or. Har este acceptat
fiabilitatea medie sau sczut

(!*#C+#*#( %+(,+)+>BC++
%.).&+8= '#>*+C+ &.%>;(*#
).C +Lines of Code) - se folosete ca o msur de normalizare pentru
fiabilitatea software +defecteFIJ<C)# pentru aprecierea producti$itii
+J<CFlun programator) i furnizeaz o estimare brut a costuluiFefort.
'etrici de numrare defecte - aproape toate programele de metrici
industriale colecteaz date despre defectele software descoperite n timpul
dez$oltrii i testrii! de multe ori# astfel de programe nu sunt denumite
e"plicit .programe de metrici.# fiind pri$ite ca practici ale ingineriei software
i ale managementului de configuraie!
8umrul ciclomatic 'C Cabe - dei e"ist multe critici la adresa lui#
rm%ne foarte popular. E simplu de calculat printr-o analiz static i se
utilizeaz frec$ent pentru controlul comple"itii codului. &e spune c la
Kewlett =ac@ard orice modul cu o comple"itate ciclomatic mai mare de 4/
trebuie reproiectat.
!unctele funcionale: analiza punctelor funcionale este foarte grea pentru
a se face corespunztor i de comple"itate gratuit dac se utilizeaz la
estimarea resurselor. Gotui# s-a acceptat ca o msur a dimensiunii
standard# n special n sectorul ;G financiar.

=rogramul de construire a metricilor
de fiabilitate software
>n conte"tul msurrii software sunt trei clase

de entiti:
9
!rocese: orice acti$itate specific# set de acti$iti
sau timp n fabricarea unui produs sau dez$oltarea
unui proiect. E"emple n acest sens sunt: specificarea
cerinelor# proiectarea# codificarea i $erificarea sau o
anumit perioad de timp specific# cum ar fi .primele
trei luni ale proiectului L..
9
!roduse" orice rezultat al unei acti$iti sau
document rezultat dintr-un proces. E"emple: codul
surs# o specificaie de proiectare# un plan de test i
un manual de utilizare produs software.
9
*esurse: orice intrare ntr-un proces. E"emple: o
persoan sau o ec0ip# un compilator sau un
instrument de testare software.

Cerine impuse metricilor
metricii trebuie s fie uor de neles. Ce e"emplu# liniile de cod
+J<C# IJ<C) i punctele funcionale sunt cele mai obinuite msuri
ale dimensiunii software +potenial i ale comple"itii)!
metricii trebuie s fie ieftini pentru a putea fi cumprai! studiile arat
c apro"imati$ -M - 45M din costurile totale de dez$oltare se pot
datora metricilor!
metricii trebuie s fie testai nainte de a se utiliza! pot a$ea o baz

teoretic solid# dar nu au aplicare sau e$aluare practic!
metricii trebuie s fie un a(utor managerial pentru mbuntirea
proceselor!
metricii s fie disponibili la timp! dac un metric nu e disponibil dec%t
atunci c%nd sunt probleme# de e"emplu dac rata de defectare n-a
fost msurat timpuriu# poate fi nefolositor mai t%rziu!
metricii trebuie s stimuleze mbuntirile de proces! nu se $or

utiliza metrici pentru a (udeca ec0ipa sau performana indi$idual!
metricii trebuie s fie folositori la mai multe ni$eluri: s ser$easc
at%t managementului c%t i ec0ipei te0nice pentru mbuntirea
proceselor de dez$oltare.

(naliza datelor
6etricii de fiabilitate folosesc date obiecti$e i

subiecti$e:
9
datele obiecti$e: contoare ale unor caracteristici
+IJ<C# puncte funcionale# componente# funcii
testate# uniti codificate# modificri# erori) ce se pot
$erifica independent!
9
date subiecti$e: aprecieri indi$iduale ale unei
caracteristici sau condiii +ni$elul dificultii problemei#
gradul noii te0nologii implicate# stabilitatea cerinelor).
7azele de date create conin trei tipuri de date:

9
date de cost - reflect eforturile fcute!
9
date despre procese - reflect informaia despre
programe +metodologie# instrumente i te0nici
utilizate) i e"perienaFinstruirea personalului!
9
date despre produs - includ dimensiunea# date despre
modificri# defecte i rezultatele analizelor statistice
asupra codului li$rat.

Procesul de management utiliznd
metrici

6etrici software pentru fiabilitate n
ciclul de $ia
&e $or aborda trei faze ale ciclului de $ia

software# unde se pot aplica cu impact
direct asupra fiabilitii te0nicile de
pre$enire a erorilor i metricile software :
9
specificare cerine!
9
proiectare i codificare!
9
testare

'etrici de fiabilitate pentru
specificarea cerinelor
Jinii de te"t - linii fizice coninute de fiierul te"t!
;mperati$e - numrul de cerine i fraze care cer s se

ntreprind o aciune. Este un indicator de baz!
Continuri - fraze care urmeaz unei e"primri imperati$e i
specific cerinele de ni$el sczut +pentru un numr de
cerine suplimentare)!
Cirecti$e - referine la figuri# tabele sau note!
Fraze ineficiente - clauze care pot produce incertitudine

datorit ambiguitii sau nelesului multiplu pe care-l au!
;ncompletitudine - afirmaii din te"t gen G7C +To Be

Determined) sau G7& +To Be Supplied - de li$rat)!
<piuni- cu$inte care par s ofere dez$oltatorului alegerea

n a ndeplini specificaiile# dar care pot fi ambigue.

Hezultatele la ni$elul * +proiectare ar0itecturala) si , +proiectare detaliata)

'etrici de fiabilitate pentru proiectare i
codificare
n4 - numrul de operatori distinci!
n) - numrul de operanzi distinci!
N4 - numrul total de apariii ale

operatorilor!
N) - 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 obiecti$ de fiabilitate#
etc.
Ingineria Programrii
Curs 12
Curs 12
Adriana Gheorghie, adrianaa@infoiasi.ro
Ovidiu Gheorghie, ogh@infoiasi.ro
Metrici
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)
50 25 13 7 4 Productivitate (NOP/PM)
Foarte
mare Mare
Nominal
a
Mic
a
Foarte
mica Experienta programatorului
IP
12
COCOMO 2: proiectarea iniial
Efort
2.5
KLOC
1.1 .. 1.24
Capacitatea
personalului
Sigurana i
complexitate
Reutilizare
cerut
Dificultatea
platformei
Experiena
personalului
Faciliti
asisten
Planificare
Numar linii cod
generate automat
Procentul de
linii de cod
generate automat
Productivitatea
pentru acest tip
de activitate
1
.
.
6
NOP =>Size (2..40 LOC/NOP)
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:
Sigurana
Constrngeri
timp
Constrngeri
memorie
Folosirea
instrumentelor
Experiena
echipei
D
a
,

p
r
e
u
l

e
s
t
e

p
e

l
u
n
!
IP
12
Distribuia forei de munc n timp
20 om-lun
20 oameni muncesc 1 luna
4 oameni muncesc 5 luni
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)
N
U
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
G
De a explica cum poate fi proiectat un software
ca o mulime de obiecte care interacioneaz
ntre ele
G
De a descrie activitile procesului de proiectare
orientat obiect
G
De a prezenta diferite modele ce pot fi folosite
pentru a descrie un proiect orientat obiect
G
De a arta felul n care limbajul grafic UM poate
fi folosit pentru a reprezenta aceste modele
!uprins
G
Obiecte "i clase de obiecte
G
Procesul de proiectare orientat obiect
G
#voluia proiectrii
Dezvoltarea orientat obiect
G
$naliza% proiectarea "i programarea orientat obiect
sunt nrudite dar distincte&
G
$naliza orientat obiect 'OO$( se ocup cu
realizarea unui model obiectual al domeniului
aplicaiei&
G
Proiectarea orientat obiect 'OOD( se ocup cu
realizarea unui model obiectual al sistemului care
implementeaz cerinele&
G
Programarea orientat obiect 'OOP( se ocup cu
implementarea unui proiect orientat obiect ntr)un
limbaj de programare orientat obiect% cum ar fi *ava
sau !++&
!aracteristici ale OOD
G
Obiectele sunt abstractizri ale entitilor din
lumea real sau ale entitilor unui sistem&
G
Obiectele sunt independente "i ncapsuleaz
stare sau informaie&
G
,uncionalitatea sistemului este exprimat n
termeni de servicii oferite de obiecte&
G
-unt eliminate datele comune% obiectele
comunic.nd prin sc/imb de mesaje&
G
Obiectele pot fi distribuite "i pot fi executate
secvenial sau n paralel&
Obiecte care interacionez
sta te o 3
o 3 :C3
sta te o 4
o 4: C4
sta te o 1
o 1 : C1
sta te o 6
o 6 : C1
sta te o 5
o 5 :C5
sta te o 2
o 2 : C3
o ps1 () o ps3 () o ps4 ()
o ps3 () o ps1 ()
o ps5 ()
$vantaje ale OOD
G
Mentenan mai u"oar& Obiectele pot fi
nelese ca entiti independente&
G
Obiectele sunt poteniale componente
reutilizabile&
G
Pentru unele sisteme% poate exista o
ec/ivalen clar ntre entiti din lumea
real "i obiecte ale sistemului&
G
Obiectele sunt entiti dintr)un sistem
software ce reprezint entiti din lumea
real sau din alte sisteme&
G
!lasele de obiecte sunt modele '"abloane(
pentru obiecte& #le pot fi folosite pentru a
crea obiecte&
G
!lasele de obiecte pot mo"teni atribute "i
servicii 'metode( de la alte clase de obiecte&
Un obiect este o entitate care are o stare i o mul ime definit de
opera ii care opereaz asupra acelei st ri . Starea este reprezentat
ca o mul ime de atribute. Opera iile asociate obiectului ofer
servicii pentru alte obiecte (clien i ) care solicit aceste servicii
cnd au nevoie de anumite calcule.
Obiectele sunt create dup defini ie unei clase de obiecte. O
defini ie a unei clase de obiecte serve te ca model pentru obiecte .
Ea include declara ii ale tuturor atributelor i metodelor
(serviciilor) ce trebuie asociate cu un obiect din aceas clas.
UM '0/e Unified Modeling anguage(
G
Diferite notaii pentru descrierea proiectelor
orientate obiect au fost propuse ntre anii
1234 "i 5444&
G
imbajul UM este o integrare a acestor
notaii&
G
#l descrie notaii folosite pentru diferite
modele ce pot rezulta n analiza sau
proiectarea orientat obiect&
G
UM este astzi standardul pentru modelarea
orientat obiect&
!lasa $ngajat 'UM(
$ngajat
name: string
address: string
dateOfBirth: Date
employeeNo: integer
socialSecurityNo: string
depar tment: Dept
manager: Employee
salary: integer
status: {current, left, retired
ta!"ode: integer
# # #
$oin %&
lea'e %&
retire %&
changeDetails %&
!omunicarea obiectelor
G
!onceptual% obiectele comunic prin sc/imb
de mesaje&
G
Mesaje
6
7umele metodei apelate8
6
!opii ale informaiei necesare pentru executarea
metodei&
G
9n practic% mesajele sunt implementate prin
apeluri de funcii 'metode(
6
7ume : numele funciei8
6
;nformaii : lista de parametrii&
#xemple de mesaje
// Apelul unei metode asociate cu un obiect
// buffer ce returneaz urm toarea valoare
// din buffer
v = circularBuffer.Get () ;
// Apelul unei metode asociate cu un
// obiect termostat care seteaz
// temperatura ce trebuie men inut
thermostat.setTemp (20) ;
<eneralizare "i mo"tenire
G
Obiectele sunt instane ale unor clase care definesc
tipul atributelor "i operaiile&
G
!lasele pot fi aranjate ntr)o ierar/ie de clase n care
o clas 'super)clas( este o generalizare a uneia
sau a mai multor clase 'sub)clase(&
G
O sub)clas mo"tene"te atributele "i metodele de la
super)cals "i poate aduga propriile metode "i
atribute&
G
<eneralizarea din UM este implementat prin
mo"tenire n limbajele de programare orientate
obiect&
O ierar/ie de clase
Em plo ye e
Pro g ra m m e r
pro j e c t
pro g La ng ua g e s
Ma na g e r
Pro j e c t
Ma na g e r
b ug e tsCo ntro lle
a te !ppo "nte
pro j e c ts
#e pt$
Ma na g e r
%tra te g "c
Ma na g e r
e pt re spo ns"b "l"t"e s
$vantaje ale mo"tenirii
G
#ste un mecanism de abstractizare ce poate
fi folosit pentru a clasifica entiti&
G
#ste un mecanism de reutilizare at.t la nivel
de proiectare c.t "i la nivel de programare&
G
O ierar/ie de mo"tenire este o surs de
informaie de organizare despre domenii "i
siteme&
Probleme legate de mo"tenire
G
!lasele de obiecte nu sunt independente% ele
nu pot fi nelese fr a face referire la super)
clase&
G
Proiectanii au tendina de a refolosi ierar/iile
create la analiz% ceea ce poate duce la
ineficien&
G
;erar/iile de mo"tenire la analiz% proiectare
"i programare au funcii diferite "i trebuie
ntreinute separat&
$socieri UM
G
Obiectele "i clasele de obiecte particip n
relaii cu alte obiecte "i clase de obiecte&
G
9n UM% o relaie general este indicat prin
o asociere&
G
$socierile pot fi adnotate cu informaie ce
descrie asocierea&
G
$socierile 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 #e pa r tm e nt
Ma na g e r
"s&m e m b e r&o '
"s&m a na g e &b y
m a na g e s
Obiecte concurente
G
Obiectele fiind entiti independente se
preteaz foarte bine la implementri
concurente&
G
Modelul de sc/imb 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
G
Procesul de proiectare implic dezvoltarea
c.torva modele ale sistemului&
G
#le necesit mult efort de dezvoltare "i
ntreinere iar pentru sistemele mici acest
lucru poate s nu fie eficient din punct de
vedere al costurilor&
G
0otu"i pentru sistemele mari dezvoltate de
grupuri diferite% modelele de proiectare sunt
un mecanism esenial de comunicare&
#tape ale procesului
G
#videniem activitile c/eie fr s ne
legm de un proces anume cum ar fi =UP&
6
Definirea contextului "i modele de utilizare ale
sistemului8
6
Proiectarea ar/itecturii sistemului8
6
;dentificarea principalelor obiecte din sistem8
6
Dezvoltarea modelelor de proiectare8
6
-pecificarea interfeelor obiectelor&
-istem de monitorizare meteo
Este necesar un sistem de monitorizare meteo pentru a genera
h r i meteorologice n mod regulat folosind date colectate de la
sta ii meteo la distan i de la alte surse cum ar fi observatoare
meteo, baloane i sateli i . Sta iile meteo transmit datele lor
calculatorului din acea zon ca r spuns 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 h r i digitizate se
creaz un set de h r i meteo locale . H r ile pot fi tip rite pe o
imprimant special sau pot fi afi ate n diferite formate .
!ontextul sistemului "i modele de utilizare
G
Dezvoltare unei nelegeri ale relaiilor dintre
sistemul software ce trebuie proiectat "i mediul
exterior
G
!ontextul sistemului
6
#ste un model static ce descrie relaia cu alte sisteme& -e
folose"te un model de tip subsistem&
G
Model de utilizare
6
#ste un model dinamic ce descrie cum interacionez
sistemul cu mediul& -e folosesc cazuri de utilizare 'use)
cases( pentru a arta interaciunile
$r/itectur pe straturi
(su)system*
Data collection
(su)system*
Data processing
(su)system*
Data archi'ing
(su)system*
Data display
-tratul de colectare a datelor
Obiectele se ocup cu ac/iziionarea
de la surse de la distan
-tratul de procesare a datelor
Obiectele se ocup cu verificarea "i
+ntegrarea datelor colectate
-tratul de ar/ivare a datelor
Obiectele se ocup cu stocarea
datelor pentru viitoare prelucrri
-tratul de afi"are a datelor
Obiectele se ocup cu pregtirea "i
pre,entarea datelor ntr)o form
u"or de neles
-ubsisteme n sistemul de monitorizare meteo
#a ta
sto ra g e
(se r
"nte r 'a c e
) sub sy ste m *
#a ta c o lle c t"o n
) sub sy ste m *
#a ta pro c e ss"ng
) sub sy ste m *
#a ta a rc +", "ng
) sub sy ste m *
#a ta "spla y
-e a t+e r
sta t"o n
%a te ll"te
Co m m s
.a llo o n
/b se r, e r
Ma p sto re
#a ta sto re
#a ta
sto ra g e
Ma p
(se r
"nte r 'a c e
Ma p
"spla y
Ma p
pr"nte r
#a ta
c +e c 0"ng
#a ta
"nte g ra t"o n
Modele de utilizare 'use)cases(
G
Modelele de utilizare sunt folosite pentru a
reprezenta fiecare interaciune cu sistemul&
G
Un model de utilizare prezint
funcionalitatea sistemului la nivel de actori "i
scopuri ale actorilor&
!azuri de utilizare pentru o staie meteo
%ta r tup
%+uto 1 n
2e po r t
Ca l"b ra te
3e st
Descrierea unui Use)case

Sistem Sta ie meteo
Use-case Raport
Actori Sistemul meteo de colectare a datelor, Sta ia meteo
Descriere Sta ia meteo trimite sistemului meteo de colectare un sumar al datelor meteo colectate de
la instrumente n perioada de colectare. Datele trimise sunt maximul, minimul i media
temperaturii solului i aerului , ale presiunii aerului, vitezei vntului, precipita iile totale i
direc ia vntului .
Stimuli Sistemul meteo de colectare a datelor stabile te o conexiune prin modem cu sta ia meteo
i cere transmiterea datelor .
R spuns Datele sumarizate sunt trimise c tre sistemul meteo de colectare a datelor
Comentarii Sta iile meteo sunt solicitate s trimit rapoarte de obiecei odat pe or dar aceast
frecven poate s difere de la o sta ie la alta i poate fi modificat pe viitor .
Proiectare ar/itectural
G
Odat ce interaciunile dintre sistem "i mediul lui au
fost nelese% aceast informaie este folosit pentru
proiectarea ar/itecturii sistemului&
G
O ar/itectur pe straturi este potrivit pentru staia
meteo
6
-tratul de interfa pentru rezolvarea comunicaiilor8
6
-tratul de colecie de date pentru lucrul cu instrumentele
meteo8
6
-tratul instrumentelor meteo pentru colectarea datelor&
G
9n mod normal nu trebuie s apar mai mult de >
entiti ntr)un model ar/itectural&
$r/itectura unei staii meteo
-e a t+e r sta t"o n
Ma na g e s a ll
e 4te rna l
c o m m un"c a t"o ns
Co lle c ts a n
sum m a r"se s
1 e a t+e r a ta
Pa c 0a g e o '
"nstrum e nts 'o r ra 1
a ta c o lle c t"o ns
) sub sy ste m *
) sub sy ste m *
5nstrum e nts
) sub sy ste m *
5nte r'a c e
;dentificarea obiectelor
G
;dentificarea obiectelor 'sau a claselor de obiecte(
este partea cea mai dificil a proiectrii orientate
obiect&
G
7u exist nici o ?formul magic? pentru identificarea
obiectelor& #a se bazeaz doar pe aptitudini%
experien "i cunoa"terea foarte bun a domeniului
de ctre proiectanii sistemului&
G
;dentificarea obiectelor este un proces iterativ& #ste
puin probabil ca de prima dat s poi identifica
toate obiectele corect&
$bordri posibile
G
,olosirea unei abordri gramaticale bazate pe
descrierea sistemului n limbaj natural 'folosit n
metoda @ood de proiectare orientat obiect(&
G
,olosirea unei abordri bazate pe identificarea
lucrurilor tangibile din domeniul aplicaiei&
G
,olosirea unei abordri comportamentale "i
identificarea obiectelor bazat pe cine particip n
sistem "i cu ce comportament&
G
,olosirea unei analize bazate pe scenarii& Obiectele%
atributele "i metodele din fiecare scenariu sunt
identificate&
Descrierea unei staii meteo
O sta ie meteo este un pachet de instrumente controlate de
software, ce colecteaz date , efectueaz unele proces ri de date i
transmite aceste date pentru proces ri ulterioare . Instrumentele
includ termometre de aer i de sol , un anemometru pentru
m surarea vitezei i direc iei vntului , un barometru i un
instrument pentru m surarea precipita iilor . Datele sunt collectate
periodic.
Cnd se d o comand pentru trans miterea datelor meteo, sta ia
meteo proceseaz i sumarizeaz datele colectate . Datele
sumarizate sunt transmise calculatorului pentru procesarea h r ilor
cnd se prime te o cerere de transmisie .
!lasele de obiecte ale unei staii meteo
G
0ermometru de sol% $nemometru% Aarometru
6
Obiecte din domeniul aplicaiei care sunt
obiecte B/ardwareC corespunztoare
intrumentelor din sistem&
G
-taia meteo
6
;nterfaa de baz a staiei meteo cu mediul su&
#a reflect interaciunile identificate n modelul
use)case&
G
Datele meteo
6
9ncapsuleaz "i sumarizeaz datele provenite
de la instrumente&
!lasele de obiecte ale unei staii meteo
"e nt"'"e r
re po r t-e a t+e r ()
c a l"b ra te ("nstrum e nts)
te st ()
sta r tup ("nstrum e nts)
s+uto 1 n ("nstrum e nts)
-e a t+e r%ta t"o n
te st ()
c a l"b ra te ()
6ro un
t+e rm o m e t e r
te m pe r a ture
!ne m o m e t e r
1 "n%pe e
1 "n#"re c t"o n
te st ()
.a ro m e t e r
pre ssure
+e "g +t
te st ()
c a l"b ra te ()
-e a t+e r#a ta
a "r3e m pe r a ture s
g ro un3 e m pe r a ture s
1 "n%pe e s
1 "n#"re c t"o ns
pre ssure s
ra "n'a ll
c o lle c t ()
sum m a r"se ()
$lte obiecte "i rafinarea obiectelor
G
,olosii cuno"tiine din domeniul aplicaiei
pentru a identifica alte obiecte "i operaii
6
-taiile meteo trebuie s aib un identificator
unic8
6
-taiile meteo sunt situate la distan astfel c
defeciuni ale instrumentelor trebuie raportare
automat& -unt necesare atribute "i operaii
pentru auto)testare&
G
Obiecte active sau pasive
6
9n acest caz obiectele sunt pasive "i colecteaz
datele la cerere nu din proprie iniiativ&
Modele de proiectare
G
Modelele de proiectare prezint obiectele%
clasele de obiecte "i relaiile dintre aceste
entiti&
G
Modelele statice descriu structura static a
sistemului n termeni de clase de obiecte "i
relaii&
G
Modelele dinamice descriu interaciunile
dinamice dintre obiecte&
#xemple de modele de proiectare
G
Modele tip sub)sistem care arat gruprile
logice de obiecte n sub)sisteme coerente&
G
Modele de secven care arat secvena
interaciunilor ntre obiecte&
G
Modele de stare arat cum obiecte
individuale "i sc/imb starea ca rspuns la
evenimente&
G
$lte modele% cum ar fi modele use)case%
modele de agregare% modele de
generallizare% etc&
-ub)sisteme n staia meteo
) sub sy ste m *
5nte r 'a c e
) sub sy ste m *
Co m m sCo ntro lle r
-e a t+e r%ta t"o n
-e a t+e r#a ta
5nstrum e nt
%ta tus
) sub sy ste m *
5nstrum e nts
!"r
t+e rm o m e te r
6ro un
t+e rm o m e te r
2a "n6a ug e
.a ro m e te r
!ne m o m e te r
-"n7a ne
Modele de secven
G
Modelele de secven arat interaciunile
dintre obiecte
6
Obiectele sunt aranjate orizontal n partea de
sus a diagramei8
6
0impul este reprezentat vertical deci modelele
se citesc de sus n jos8
6
;nteraciunile sunt reprezentate de sgei
etic/etate8 diferite stiluri de sgei reprezint
diferite tipuri de interaciuni8
6
Un dreptung/i 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
re 8 ue st (re po r t)
a c 0no 1 le g e ()
re po r t ()
sum m a r"se ()
re ply (re po r t)
a c 0no 1 le g e ()
se n (re po r t)
:-e a t+e r%ta t"o n :-e a t+e r#a ta
Diagrame de stare
G
$rat cum rspund obiectele la diferite cereri "i
tranziiile n starea obiectelor provocate de aceste
cereri
6 Dac starea obiectului este -/utdown atunci obiectul
poate rspunde la un mesaj de tip -tartup'(8
6 9n starea de a"teptare 'Daiting( obiectul a"teapt alte
mesaje8
6 Dac prime"te mesajul reportDeat/er'( atunci trece n
starea -ummarising8
6
a primirea mesajului calibrate'( se trece n starea de
calibrare8
6
-e intr n starea de colectare a datelor atunci c.nd se
prime"te un mesaj de la un cronometru din sistem&
Deat/er station state diagram
tra nsm "ss"o n o ne
c a l"b ra te ()
te st ()
sta r tup ()
s+uto 1 n ()
c a l"b ra t"o n /9
te st c o m ple te
1 e a t+e r sum m a ry
c o m ple te
c lo c 0
c o lle c t"o n
o ne
/pe ra t"o n
%+uto 1 n
-a "t"ng
3e st"ng
3ra nsm "tt"ng
Co lle c t"ng
%um m a r"s"ng
Ca l"b ra t"ng
-pecificare interfeei obiectelor
G
;nterfeele obiectelor trebuie specificate
astfel nc.t obiectele "i alte componente s
poat fi proiectate n paralel&
G
Obiectele pot avea mai multe interfee care
sunt puncte de vedere diferite asupra
metodelor oferite de obiecte&
G
UM folose"te diagrame de clase pentru
specificarea interfeelor% dar poate fi folosit "i
limbajul *ava&
;nterfaa 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
#voluia proiectrii
G
$scunderea informaiei n obiecte nseamn
c modificrile asupra unui obiect nu
afecteaz alte obiecte ntr)o manier
impredictibil&
G
- presupunem c trebuie adugate staiilor
meteo faciliti pentru monitorizarea polurii&
$cestea iau o prob de aer "i calculeaz
cantitatea diferiilor poluani din atmosfer&
G
!itirile de poluare sunt transmise mpreun
cu datele meteo&
Modificri cerute
G
$dugarea unei clase de obiecte numite
$ir EualitF ca parte din Deat/er-tation&
G
$dugarea unei operaii report$irGualitF
la Deat/er-tation& Modificarea
programului de control pentru colectarea
citirilor de poluare&
G
$dugarea obiectelor reprezent.nd
instrumentele de monitorizare a polurii&
Monitorizarea polurii
:/#a ta
sm o 0 e #a ta
b e n; e ne #a ta
c o lle c t ()
sum m a r"se ()
!"r 8 ua l"ty
"e nt"'"e r
re po r t!"r<ua l"ty ()
c a l"b ra te ("nstrum e nts)
te st ()
sta r tup ("nstrum e nts)
s+uto 1 n ("nstrum e nts)
-e a t+e r%ta t"o n
Po llut"o n m o n"to r"ng "nstrum e nts
:/m e te r %m o 0e Me te r
.e n;e ne Me te r
G
Proiectarea orientat obiect este o abordare a
proiectrii n care componentele proiectate au operaii
"i stare intern&
G
Obiectele trebuie s aib un constructor "i operaii de
inspectare& #le ofer servicii altor obiecte&
G
Obiectele pot fi implementate secvenial sau
concurent&
G
UM 'Unified Modeling anguage( ofer diferite notaii
pentru definirea diferitelor modele de obiecte&
!oncluzii
!oncluzii
G
Diferite modele pot fi realizate n timpul
proiectrii orientate obiect& $cestea includ
modele statice "i dinamice de sistem&
G
;nterfeete obiectelor trebuie definite precis
folosind c/iar limbaje de programare&
G
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 199: Rumbaugh i se altur lui Booch la irma Rational
Sot!are "i #ncep uniicarea metodei lui Booch cu O$T%
Octombrie 199!: &pare versiunea '() drat a *niied $ethod% +acobson
se altur "i el lui Rational Sot!are% se #ncepe #ncorporarea OOS, #n *$-%
"unie 199#: apare *$- versiunea '(., apoi ia na"tere Consor/iul *$-%
"anuarie 199$: *$- 0(' 1creat cu contribu/ia 2,C, 34, I5-ogi6, Intellicorp,
IB$, $icrosot, Oracle "(a(7 este oerit spre standardizare catre Object
$anagement 8roup 1O$87, ca raspuns la cererea O$8 pentru un limbaj
standard de modelare%
"ulie 199$: 9ersiunea revizuita *$- 0(0 1creat de catre un grup mult largit
de parteneri7 este oerit catre O$8 pentru standardizare%
1 noiembrie 199$: *$- 0(0 este adoptat ca standard de catre O$8%
$entenan/a *$- este preluat de ctre O$8, care public ulterior reviziile
*$- 0(: 1iunie 0..)7 "i *$- 0(; 1#n toamna lui 0..)7%
<n anul %&&& a aprut versiunea *$- 0(=%
<n %&&1 se public revizia *$- :('

Principii de ba'
,ste un limbaj standard pentru scrierea de

schi/e sot!are
Scopul *$- este vizualizarea, speciicarea,

construirea "i documentarea arteactelor unui
sistem sot!are5intensiv, orientat5obiect(
*$- este numai un limbaj, deci este numai o

parte a unei metode de dezvoltare sot!are(
,ste independent de proces

Obiecti(e
*$- a devenit un standard de modelare recunoscut de catre O$8
1Object $anagement 8roup7( Standardizarea a avut loc #n
noiembrie 0..>, iar limbajul a continuat sa ie #mbunt/it(
*$- este limbaj de modelare "i nu metodologie( 2e obicei o
metodologie const, cel pu/in #n principiu, at?t dintr5un limbaj de
modelare, c?t "i dintr5un proces de modelare( -imbajul de modelare
este nota/ia graic olosit pentru descrierea modelului, iar procesul
este succesiunea de pa"i ce trebuie urma/i pentru a realiza eectiv
modelul(
*$- poate i deinit, pe scurt, ca un limbaj de vizualizare,
speciicare, construire "i documentare a modelelor( 9aloarea lui
const #n urmatoarele@
5 este un standard deschis,
5 realizeaz #ntreg ciclul de via/ al dezvoltarii sot!are5ului,
5 acoper multe tipuri de aplica/ii,
5 este bazat pe marea e6perient a celor care l5au realizat,
5 este implementat de multe produse de tip C&S,(

Caracteristicile modelrii vizuale
descoper procesele care au loc #n cadrul

sistemului, olosind analiza cazurilor de
utilizare 1*S, C&S,7
se constituie #ntr5un bun mijloc de

comunicare
simpliicAreduce comple6itatea sistemului,
deine"te arhitectura sot!are5ului,
permite reutilizarea componentelor(

*TI-IB&R,& *$-
deinirea granitelor sistemului si unctiilor lui

majore, olosind cazurile de utilizare si actorii
descrierea cazurilor de utilizare olosind

diagramele de interactiune
reprezentarea structurii statice a sistemului

olosind diagramele de clase
modelarea comportamentului obiectelor cu

ajutorul diagramelor de tranzitie a starilor
reprezentarea arhitecturii izice a implementarii

cu ajutorul diagramelor de componente si de
amplasare
e6tinderea unctionalitatii cu ajutorul

stereotipurilor

)ipuri de diagrame UML
*nali'a
2iagrama cazurilor de utilizare 1Use Case Diagram7
2iagrama de activita/i 1Activity Diagram7
Proiectare
5 Structura@ 2iagrama de clase 1Class Diagram7
5 Comportamentul@
2iagrama de stari 1Statechart Diagram7
2iagrame de interac/iuni 1Interactions Diagrams7
o 2iagrama de secven/a 1Sequence Diagram7
o 2iagrama de colaborare 1Collaboration Diagram7
"mplementare
C 2iagrama de componente 1Component Diagram7
C 2iagrama de plasare 1Deployment Diagram7

+oncepte de ba'a
Blocurile constructive ale UML

C
elemente
structurale
comportamentale
de grupare
de adnotare
C
relatii
C
diagrame
Regulile care dicteaza modul #n care aceste

blocuri pot i combinate
Mecanismele generale ale UML

,lemente structurale
Sunt substantivele modelelor *$-, reprezent?nd #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 orientat5obiect(
reprezinta o descriere a unui set de obiecte ce

partajeaza aceleasi atribute, operatii, relatii si
semantica, put?nd implementa una sau mai multe
interete
clasele pot include abstractizari ale unor parti din

domeniului problemei precum si implementari ale
solutiei si pot i olosite pentru a reprezenta
elemente pur conceptuale, elemente sot!are sau
elemente hard!are

,lementele constitutive ale unei
clase
Atributele C un atribut este o proprietate, cu

nume, a unei clase, descriind o plaja de valori
pe care instan/ele acelei proprietati le pot lua
Operaiile C o operatie este implementarea unui

serviciu ce poate i solicitat de catre orice obiect
al clasei pentru a5i aecta comportamentul
1o operatie este o abstractizare a unei prelucrari
ce se poate aplica unui obiect, partajata de catre
toate obiectele acelei clase7
Responsabilitile C o responsabilitate este o

obligatie a unei clase

Conditiile #ndeplinite de o clas
bine structurat
Sa oere o abstractizare clara a unei entitati ce

apartine vocabularului domeniului problemei sau
al domeniului solutiei%
Sa #ncorporeze o multime restr?nsa si bine

deinita, de responsabilitati%
Sa oere o separare clara a abstractizarilor si a

implementarilor%
Sa ie inteligibila si simpla, dar #n acelasi timp

e6tensibila si adaptabila

Simbolul clasei
Dume clasa
&tribute
Operatii
Responsabilitati

Instanta
reprezinta o maniestare concreta a unei

abstractizari asupra careia se poate aplica un
set de operatii si care are stare ce stocheaza
eectele operatiilor(
Instantele pot i @
5 concrete C reprezinta instante ale unor clase
concrete%
5 prototipice C reprezinta instante potentiale ale
claselor concrete care sunt subclase ale claselor
abstracte, sau ale claselor concrete care
realizeaza interete

Interfata
C reprezinta o colectie de operatii care

speciica un serviciu al unei clase sau al
unei componente
Simbol@
Dume intera/

Colaborarea
deineste o interactiune% o colaborare este

un ansamblu de elemente ce lucreaza
#mpreuna pentru a oeri un comportament
cooperativ mai important dec?t suma
comportamentelor elementelor
Simbol@
Dume colaborare

Cazul de utilizare
reprezinta o descriere a seturilor de

secvente de actiuni pe care le e6ecuta un
sistem, conduc?nd la un rezultat
observabil ce prezinta importanta pentru
un anumit actor
Simbol@
Dume caz de utilizare

Clasa activa
o clasa ale carei obiecte poseda unul sau

mai multe procese sau ire de e6ecutie si
prin urmare pot initia controlul activitatilor

Componenta
o parte izica, #nlocuibila, a unui sistem,

care oera implementarea unui set de
interete
Simbol@

Nodul
element izic care e6ist la momentul

e6ecu/iei "i reprezint o resurs de calcul,
are cel pu/in memorie "i adesea capacit/i
de procesare
Simbol@
Dume nod

,lemente comportamentale
Sunt partile dinamice ale modelului *$-,
reprezent?nd comportamentul modelului #n
timp si spatiu( ,le sunt verbele modelului(
5
Interactiune
5
Ma"in cu stri

Interactiune
este un comportament ce cuprinde un set

de mesaje schimbat #ntre o multime de
obiecte #ntr5un conte6t particular, pentru a
realiza un scop speciic( Implica un numar
de alte elemente, incluz?nd mesaje,
secvente de actiuni si legaturi
5 Simbol@
nume

Main cu stri
este un comportament ce speciica

secventa de stari prin care trece un obiect
sau o interactiune #n cursul e6istentei sale,
ca raspuns la evenimente, #mpreuna cu
raspunsurile la aceste evenimente
Simbol@
nume

,lemente de grupare
sunt partile organizationale ale modelelor

*$-( ,6ista un singur tip de elemente de
grupare, pachetele(
*n pachet este un mecanism general

pentru organizarea elementelor #n grupe(
<ntr5un pachet pot i plasate elemente
structurale, elemente comportamentale si
chiar alte elemente de grupare(
Simbol@
Dume pachet

,lemente de adnotare
sunt partile e6plicative ale modelelor *$-(

,6ista un singur astel de tip de element,
nota 5 un simbol pentru marcarea de
restrictii sau de comentarii atasate unui
element sau a unei colectii de elemente
Simbol@
nume not

-elatii
abstractiuni ce leaga elementele #ntre ele(

O relatie este o cone6iune #ntre elemente
C
dependentele
C
generalizarile
C
asocierile
C
realizarile

ependenta
este o relatie semantica #ntre doua

elemente #n care o schimbare a unui
element 1elementul independent7 poate
aecta celalalt element 1elementul
dependent7( Se utilizeaza atunci c?nd se
doreste indicarea aptului ca un element
este olosit de un altul
Simbol@

!socierea
este o relatie structurala care descrie un

set de legaturi, o legatura iind o
cone6iune #ntre obiecte
Simbol@ '((0 E
rol rol

2incolo de orma de baza a asocierilor, se mai olosesc si
urmatoarele notiuni@
Nume 5 olosit pentru a descrie natura relatiei%
Rol 5 atunci c?nd o clasa participa #ntr5o asociere, ea are

un rol speciic pe care #l joaca #n acea relatie%
Multiplicitate 5 indica numarul de obiecte ce pot i

conectate prin intermediul unei instante a unei asocieri%
!gregare 5 este un tip de asociere ce modeleaza o

relatie de tipul Fare unG, ceea ce #nseamna ca un obiect
al #ntregului are 1contine7 obiectele partii

Clase "i asocieri

"eneralizarea
se oloseste pentru a arata e6istenta unor

relatii de tip parinteAcopil( ,ste o relatie de
specializare #n care obiectele elementului
specializat 1copil7 pot i substitute pentru
obiecte ale elementului generalizat
1parinte7
Simbol@

Realizarea
este o relatie semantica #ntre clasiicatori,

unde un clasiicator speciica un contract
pe care un alt clasiicator garanteaza sa #l
e6ecute
Simbol@

.iagrame
sunt prezentari graice ale unui set de

elemente, cel mai adesea e6primate ca un
gra de noduri 1elementele7 si arce
1relatiile7(
Clasiicare
C
2iagrame structurale
C
2iagrame comportamentale

-eguli UML
Blocurile constructive *$- nu pot i grupate oricum, #n

maniera aleatoare, e6ist?nd reguli detaliate pentru
deinirea modelelor bine ormate%
*n model bine ormat este unul autoconsistent semantic

si #n armonie cu modelele sale #nrudite(
,6ista reguli semantice pentru nume, domeniul de

reprezentare, vizibilitate, integritate si e6ecutie%
Sunt admise si modele mai putin dect bine !ormate, #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
speciicatii
adnotari
diviziuni generale
mecanisme de e6tensie
C
stereotip
C
valoare etichetat
C
constrngere

Specificatii
pentru iecare parte a notatiei graice *$-

e6ista o speciicatie ce oera o descriere
te6tuala a sinta6ei si semanticii acelui bloc
constructiv%
#n timp ce notatia graica *$- se oloseste

pentru vizualizarea unui sistem,
speciicatiile *$- se olosesc pentru
speciicarea detaliilor sistemului

*dnotari
Notele sunt cel mai important tip de adnotare( O

nota este un simbol graic pentru reprezentarea
graica a constr?ngerilor sau comentariilor
atasate unui element sau unei colectii de
elemente(
Dotele se olosesc numai pentru acele cerinte,

observatii si e6plicatii care nu pot i acute #n
mod simplu sau inteligibil olosind celelalte
elemente *$-%
Simbol@

.i(i'iuni generale
diviziunea clasaAobiect
C
o clasa este o abstractie,
C
un obiect este o maniestare concreta a acelei
abstractii%
separatia interataAimplementare
C
interata declara un contract
C
implementarea reprezinta o realizare concreta
a acelui contract, responsabila pentru
realizarea integrala a semanticii complete a
interetei

$ecanisme de e6tensie
un #tereotip e6tinde vocabularul *$-,

permit?nd crearea de noi tipuri de blocuri
constructive derivate din cele e6istente,
dar care sunt speciice unei anumite
probleme%

O valoare etichetata e6tinde proprietatile

unui bloc constructiv *$-, permit?nd
crearea de noi inormatii #n cadrul
speciicatiei elementului

O constr$ngere e6tinde semantica unui

bloc constructiv *$-, permit?nd
adaugarea de noi reguli sau modiicarea
unora e6istente

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 structurale
Diagrame comportamentale

Diagrame structurale
Diagrame de clase
Diagrame de obiecte
Diagrame de componente
Diagrame de amplasare
Diagramele de pachet

Diagrame comportamentale
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 nielul sau de

a!stractizare (nu expune dec"t acele parti care
sunt esentiale pentru ntelegere);
#u este at"t de redusa nc"t sa dezinformeze

cititorul asupra elementelor semantice releante.

DIAGRAME DE CLAE (DC)
contin o multime de clase, interfete si

cola!orari, precum si relatiile dintre ele
sunt cele mai folosite diagrame n

modelarea sistemelor orientate o!iect
ilustreaza ederea statica de proiectare a

unui sistem

Clas$ a!stract$

Clasele template

DIAGRAME DE CLAE (DC)
interfa%a
Element ce apare n diagramele de clase

DIAGRAME DE CLAE
atributele !i opera"iile
&eprezentare'
(intaxa folosita pentru descrierea atri!utelor'

nume)atri!ut ' tip)atri!ut * aloare)initiala
(intaxa folosita pentru descrierea operatiilor'

#ume)operatie ( lista)argumente ) ' tip)returnat
unde +lista)argumente, reprezinta lista argumentelor
operatiei, fiecare argument fiind descris astfel '
nume)argument ' tip)argument *
aloare)implicita.

DIAGRAME DE CLAE
atributele !i opera"iile
-izi!ilitatea atri!utele si operatiilor unei
clase'
publice ( . ) orice alta clasa poate
folosi proprietatea sau poate inoca
operatia;
protejate ( / ) sunt izi!ile numai pentru
descendentii clasei respectie;
pri#ate ( 0 ) numai clasa respectia poate folosi
proprietatea sau operatia.

DIAGRAME DE CLAE
tipuri de opera"ii
Abstracte $ sunt operatii incomplete pentru care

clasele copii tre!uie sa furnizeze o
implementare (sunt specificate cu caractere
italice);
%run&a (1leaf2) nu pot fi suprascrise;
'olimorfice 0 sunt specificate, intr0o ierar3ie de

clase, cu aceasi semnatura, n diferite puncte
ale ierar3iei. 4peratia inocata, n momentul
executiei, este aleasa n functie de tipul
o!iectului caruia i apartine.

DIAGRAME DE CLAE
repre&ent(ri utiili&ate

DIAGRAME DE CLAE
rela"ii
5socieri;
&ela%ii de generalizare;
&ela%ii de dependenta;
&ela%ii de realizare;

DIAGRAME DE CLAE
rela"ii) asocierea

DIAGRAME DE CLAE
rela"ii) asocierea ) clasa a asocierii

DIAGRAME DE CLAE
rela"ii) asocierea ) agregarea
impla este n ntregime conceptuala si

nu face altcea dec"t sa disting$ ntre un
+ntreg, si o +parte,;
Compo&i%ie semnific$ faptul ca par%ile pot
fi create dup$ o!iectul compus, dar o data
create traiesc si sunt distruse odat$ cu
o!iectul compus

DIAGRAME DE CLAE
rela"ii) asocierea ) agregarea

DIAGRAME DE CLAE
rela"ii) generali&area
una sau mai multe clase mo6tenesc

structura si comportamentul unei clase
mai generale.
dac$ o clas$ mo6tene6te structura si

comportamentul mai multor clase aem
de0a face cu mo6tenire multipl$

DIAGRAME DE CLAE
7odelarea oca!ularului unui sistem implica luarea de
decizii n ce prie6te a!stractiz$rile care fac parte din
sistemul aflat in construc%ie si cele care r$m"n n afara
grani%elor sistemului. Cu a8utorul diagramelor de clase se
or specifica aceste a!stractiz$ri si responsa!ilit$%ile lor.
9entru modelarea oca!ularului se procedeaz$ astfel '
(e identifica acele elemente pe care utilizatorii si implementatorii
le folosesc pentru a descrie pro!lema sau solu%ia;
9entru fiecare a!stractizare se identifica un set de responsa!ilitati;
tre!uie sa existe o distri!u%ie ec3ili!rata a acestora ntre clase;
(e or specifica toate atri!utele si opera%iile necesare pentru
ndeplinirea responsa!ilit$%ilor de c$tre fiecare clasa.

DIAGRAME DE CLAE
9entru modelarea cola!or$rilor se procedeaz$ astfel '

(e identifica mecanismul care se dore6te sa fie modelat; un
mecanism reprezint$ anumite func%ii sau un anumit
comportament a unei p$r%i a sistemului, care rezulta n urma
interac%iunii unui grup de clase, interfe%e etc.;
9entru fiecare mecanism se identifica clasele, interfe%ele, rela%iile

etc.;
Folosirea scenariilor pentru a erifica si descoperi elementele

mecanismelor ( se pot descoperi par%i uitate ale modelului sau
par%i cu o semnifica%ie gre6ita );
9opularea elementelor cu con%inutul lor ( pentru clase se

porne6te cu o repartizare ec3ili!rata a responsa!ilit$%ilor ).

DIAGRAME DE CLAE
e*emplu
(e considera cazul unei aplica%ii ce permite utilizatorilor

sa comande prin :nternet articolele pe care doresc sa le
cumpere. 9rincipalele func%ii ale sistemului sunt '
0 5dministrarea !azei de date cu articolele disponi!ile.
0 ;ratarea cererilor clien%ilor.
<n astfel de sistem consta, n principal, din trei p$r%i '
(ererul de !aze de date stoc3eaz$ informa%ii despre

articolele disponi!ile.
5plica%ia care se executa pe serer trateaz$ cererile enite de

la clien%i, interog3eaz$ si actualizeaz$ !aza de date;
9rogramele client care se executa pe !ro=ser0ele clien%ilor.

DIAGRAME DE CLAE
e*emplu

DIAGRAME DE +,IEC-E (D+)
7odeleaz$ instan%e ale elementelor con%inute n diagramele de

clase.
(e folosesc pentru modelarea aspectelor statice ale unui sistem.
5ceasta implica surprinderea unui instantaneu al sistemului.
4 diagrama de o!iecte surprinde aspectele statice ale unei
interac%iuni, const"nd din o!iecte care interac%ioneaz$, dar f$r$ a
trimite mesa8e.
Elementele principale con%inute ntr0o diagrama de o!iecte sunt

o!iectele si leg$turile. De asemenea, pot con%ine note si
constr"ngeri. (e pot folosi pac3ete si su!sisteme pentru gruparea
elementelor.
Fiecare o!iect este reprezentat printr0un dreptung3i, care con%ine
numele o!iectului, sau numele si clasa o!iectului (separate prin
doua puncte), sau numai numele clasei o!iectului (caz n care se
spune despre o!iect ca este anonim).


9a6ii urma%i pentru construirea unei diagramelor de

o!iecte'
:dentificarea mecanismului care se dore6te a fi modelat (un
mecanism reprezint$ anumite func%ii sau comportamente ale
unei par%i a sistemului, care rezulta n urma interac%iunii unui
grup de clase, interfe%e etc.;
9entru fiecare mecanism se identifica elementele participante

(clase, interfe%e etc.);
(e considera un scenariu care folose6te acest mecanism; se
considera un anumit moment n timp si se identifica o!iectele
care participa la scenariu;
(e reprezint$ st$rile (cu alorile atri!utelor) pentru fiecare o!iect,
necesare pentru n%elegerea scenariului;
(imilar se reprezint$ leg$turile ntre o!iecte, reprezent"nd

instan%e ale asocierilor.

'AC.E-E (I DIAGRAME DE
'AC.E-E
&ol' necesitatea organiz$rii elementelor n parti%ii

mai mici
9ac3et !ine proiectat' grupeaz$ elemente

apropriate din punct de edere semantic
9ac3etele !ine structurate sunt sla! cuplate

ntre ele si au un control al accesului la
con%inutul lor !ine definit
#umele pac3etului'
+nume simplu, sau
+nume de cale,

'AC.E-E
Elementele unui pac3et'
Clase
:nterfete
Componente
#oduri
Cola!orari
Cazuri de utilizare
5lte pac3ete
&ela%ii ntrepac3ete'
:mport > export
?eneralizare

'AC.E-E) Import / e*port
daca pac3etul 5 importa pac3etul @, atunci elementele

din 5 or edea elementele pu!lice din @. 9artea pu!lica
a lui @ reprezint$ exportul pac3etului @. ?rafic se
reprezint$ printr0o rela%ie de dependen%$ stereotipizat$
cu stereotipul AAimportBB ca n figura urm$toare

'AC.E-E) Generali&are
Generali&are este asem$n$toare cu generalizarea

claselor. 9ac3etele mai specializate mo6tenesc
elementele pu!lice si prote8ate de la pac3etul mai
general. (imilar cazului claselor, pac3etele mai
specializate pot nlocui pac3etele mai generale

'AC.E-E) e*emplu

DIAGRAMA CA0URIL+R DE
U-ILI0ARE
Cazul de utilizare specifica comportamentul sistemului

sau a unei p$r%i din sistem si este o descriere a unui set
de secen%e de ac%iuni, incluz"nd ariante, pe care, un
sistem le executa pentru a produce un rezultat
o!sera!il pentru un actor.

U-ILI0ARE
Actorul reprezint$ un set de roluri pe care utilizatorul le

folose6te c"nd interac%ioneaz$ cu cazurile de utilizare.
<n actor reprezint$ un rol uman, un dispoziti 3ard=are
sau orice alt sistem.
4 instan a unui actor reprezint$ o interac%iune

indiiduala cu sistemul. 5ctorii nu fac parte din sistem. Ei
se afla n afara sistemului si pot fi conecta%i la cazuri de
utilizare prin asocieri.
Fluxul de evenimente descrie comportamentul unui caz

de utilizare
<n caz de utilizare folose6te un set de secen%e,

descrierea sa fiind separata pe fluxuri alternatie.
Fiecare arianta poate fi exprimata n secen%e diferite
numite scenarii.

U-ILI0ARE
Colaborare reprezint$ societatea elementelor unui caz

de utilizare, incluz"nd deopotri$ structura statica si cea
dinamica

U-ILI0ARE
Cazurile de utilizare pot fi organizate prin gruparea lor n

pac3ete, ca n cazul claselor, exist"nd rela%ii de
generalizare, de incluziune si de extindere'
?eneralizarea cazurilor de utilizare se realizeaz$ asem$n$tor ca
n cazul claselor, cazul de utilizare CcopilC mo6tenind
comportamentul si n%elesul cazului de utilizare Cp$rinteC; copilul
poate ad$uga sau suprascrie comportamentul p$rintelui si l
poate su!stitui n orice loc in care apare acesta.
:ncluziunea ntre cazuri de utilizare semnifica faptul ca un caz de

utilizare de !aza ncorporeaz$ comportamentul altui caz de
utilizare, intr0o loca%ie specificata n cazul de utilizare de !aza.
Extinderea ntre cazuri de utilizare specifica faptul ca un caz de
utilizare de !aza ncorporeaz$ comportamentul unui alt caz de
utilizare, ntr0o loca%ie specificata indirect, prin extinderea cazului
de utilizare.

U-ILI0ARE
DC< este o diagrama care con%ine un set de cazuri de utilizare,

actori si rela%iile dintre acestea (de dependenta, de generalizare si
de asociere). De asemenea, DC< poate con%ine restric%ii si pac3ete,
folosite pentru a grupa elementele.

U-ILI0ARE
5legerea actorilor unei DC<'
(e identifica actorii care ncon8oar$ sistemul, aleg"nd grupurile

care'
necesita a8utor din partea sistemului pentru a0si ndeplini sarcinile;
sunt necesare pentru a executa func%iile sistemului
interac%ioneaz$ cu 3ard=are0ul extern sau cu alte produse soft=are
executa func%ii secundare pentru administrare si ntre%inere
5ctorii identici se organizeaz$ su! forma unei ierar3ii folosind
rela%ii de generalizare si specializare
5colo unde este necesar, se identifica un stereotip pentru
fiecare tip de actor.
(e populeaz$ DC< cu ace6ti actori si se specifica c$ile de
comunicare de la fiecare actor c$tre cazurile de utilizare ale
sistemului.

U-ILI0ARE

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 ec!en"# (D$)
diagrama de colaborare (DC).

DIAGRAMA DE $EC%EN&' (D$)
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 o#".
$lementele %&'
Linia de via a obiectelor linie verticala care reprezint

existenta unui obiect de-a lungul unei perioade de timp.
(ajoritatea obiectelor care apar n %) exista pe toata durata
interaciunii, avnd linia de viata trasata de la vrful diagramei
pn la baza
Punctul de control este un dreptung*i nalt si subire care

indica perioada de timp n care obiectul realizeaz o aciune.
+aptul de sus al dreptung*iului este aliniat la nceputul actiunii
iar captul de jos la sfritul aciunii.

,orma generala a unei diagrame de secvena'

$xemplu' %& care descrie un scenariu corespunztor

cazului de utilizare -+omanda articole.

DIAGRAMA DE C(LA)(RARE
(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 %+'

calea pentru a indica faptul ca un obiect este legat cu un altul
trebuie sa existe o cale !/local/, /parameter/, /global/ sau /self/"
num#rul de ec!en"# - pentru a indica ordinea, mesajul trebuie
prefixat cu un numr ncepnd de la 0 cresctor !se pot
modela mesaje imbricate, astfel' 0 este primul mesaj, 0.0 este
primul mesaj n mesajul 0, 0.1 este al doilea etc."

(DC)
,orma generala a unei diagrame de colaborare'

(DC)
%+ pentru cazul de utilizare -&electare informaii despre evenimente.

DIAGRAMA DE ACTI%ITATI (DA)
este o sc*em 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, %2 este o colecie de vrfuri si arce.
$lementele %2
stri de activitate i stri de aciune
tranziii
obiecte
ramuri
bifurcaii si mbinri
culuare !s3imlanes"

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. $le sunt atomice

i nu pot fi ntrerupte.
&trile de activitate pot fi descompuse, activitatea putnd

fi reprezentat de alt diagram. $le nu sunt atomice si
pot fi ntrerupte
&tarea de aciune este un caz particular al strii de

activitate. 4ntre 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. 4n 5(6 tranziiile se reprezint printr-
o linie. ,luxul 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. 7amura este reprezentata prin simbolul 8e
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.
&imbolul utilizat de 5(6 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. 4n 5(6 aceste grupuri se numesc culuare
deoarece, vizual, fiecare grup este separat de celelalte
grupuri, prin bare verticale groase. ,iecare culuar are un
nume, unic n diagrama. +uluarul reprezinta o entitate
din lumea reala. ,iecare culoar poate fi implementat prin
una sau mai multe clase.
Flu de obiecte (ob!ect flow) - obiectele pot fi implicate

n fluxul de control asociat cu diagrama de activitate. &e
poate preciza rolul, starea si atributele unui flux de
obiecte.


DA* ,luxul activitilor cazurilor de utilizare -6ogin 9 6ogout. si -+omanda articole.

DIAGRAME DE TRAN+ITIE A
$TARIL(R
diagrama de tran,i"ie a t#rilor 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.
ma-ina cu t#ri este un comportament care specifica secvena de stri prin
care trece un obiect, pe parcursul vieii sale, ca rspuns la evenimente
tarea este o condiie sau o situaie n viata unui obiect, cnd acesta
satisface anumite condiii, realizeaz anumite activiti sau ateapt
anumite evenimente
e!enimentul reprezint specificarea unei apariii semnificative care are o
locaie n spaiu si timp
acti!itatea este o execuie nonatomic n derulare ntr-o maina de stare
ac"iunea este o operaie atomica, executabila, care duce la sc*imbarea
unei stri sau returneaz o valoare
diagrama de tranziie con"ine'
stari sim"le si com"use
Tranzitii
#venimente
actiuni

DIAGRAME DE TRAN+ITIE A
$TARIL(R
Prile unei stri$
:ume' o stare poate fi si anonima
2ciuni de intrare 9 ieire, executate la intrarea 9 ieirea dintr-o
stare
;ranziii interne' realizate fr a cauza o sc*imbare de stare
&ubstri' structura imbricata a unei stri implica substri disjuncte
sau concurente
$venimente amnate' sunt recunoscute ntr-o stare, dar puse ntr-
o coad pentru a fi rezolvate de obiect ntr-o alt stare.
tarea ini"ial# indic locul implicit de start pentru o main de stare
sau o substare
tarea final# indic execuia unei maini de stare sau faptul c
starea de finalizare a fost completat
c.imbarea 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 TRAN+I&IE A $T'RIL(R
8rile unei tranziii'
&tarea sursa
$veniment declanator' a crui receptare de ctre

obiect face posibil s aib loc tranziia
+ondiii' expresie booleana care este evaluat cnd

are loc tranziia< dac are valoare de adevr, atunci
tranziia poate avea loc
2ciunea' operaie atomic, executabil, care poate

aciona direct asupra obiectului care deine maina de
stri i indirect asupra altor obiecte care sunt vizibile
obiectului
&tarea destinaie

DIAGRAME DE TRAN+I&IE A $T'RIL(R
forma general#

DIAGRAME DE TRAN+ITIE A $TARIL(R
t#ri si tran,i"ii a!anate
Ac"iuni de intrare / ie-ire' se folosesc atunci cnd se dorete ca aceeai aciune sa
aib loc ori de cte ori se intra ntr-o stare 9 se prsete o stare, indiferent de
tranziia care conduce la acea stare
Tran,i"ii interne0 folosite atunci cnd se dorete rezolvarea unor evenimente fr a
prsi starea
Acti!it#"i0 cnd este ntr-o stare n general obiectul rmne inactiv, ateptnd apariia
unui eveniment. 5neori, aflat ntr-o stare, un obiect va realiza o sarcina si o va
continua pn cnd este ntrerupt de un eveniment. 8entru aceasta se folosete o
tranziie speciala do1 &e poate de asemenea specifica o secvena de aciuni !de
exemplu' do9op0!a"<op1!b"<op=!c"".
E!enimente am2nate0 n unele situaii de modelare, se dorete recunoaterea unor
evenimente, dar amnarea rspunsului la acestea. 2ceasta se specifica prin listarea
unui eveniment cu aciunea speciala defer1

ubt#ri
$ubtarea este o stare imbricata ntr-o alta stare
$tarea com"usa este o stare care are substari< poate conine

substari ec!en"iale sau concurente
$ubtari ec!en"iale au dijuncte ,iind dat un set de stri
secveniale, obiectul se afla n starea compusa si doar ntr-una din
substarile sale la un moment dat. 5neori se dorete modelarea unui
obiect astfel nct sa se memoreze ultima substare care a fost activa
nainte de parasirea strii compuse. 8entru aceasta se folosesc 3itorii
ale tarilor4 ( .itor5 tate ). %aca se dorete ca o tranziie din afara
obiectului compus sa activeze ultima substare care a fost activa, atunci
tranziia va fi reprezentata ctre -*istor# states..
$ubtari concurente' specifica doua sau mai multe maini de stare
care se executa n paralel, n contextul obiectului care le include. %ate
fiind doua sau mai multe substari concurente la acelai nivel, un obiect
va fi ntr-o stare secveniala din fiecare din strile concurente. > maina
cu stri imbricate concurenta nu are stare iniiala sau finala.

ubt#ri
> tranziie ce conduce la ieirea dintr-o stare compusa poate avea ca sursa starea compusa
sau o substare a ei

DIAGRAME DE TRAN+ITIE A $TARIL(R * e6em7lu

DIAGRAME DE DE$8'9URARE
(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.
&e reprezint componentele n nod, ntr-un compartiment

separat.
diagramele de desfurare nu sunt importante numai pentru

vizualizarea, specificarea si documentarea sistemelor
distribuite, client9server, ci i pentru direcionarea sistemelor
executabile prin inginerie direct i invers

DIAGRAME DE DE$8'9URARE
(DD)

DIAGRAME DE DE$8'9URARE (DD)
%iagramele de desfurare pentru un soft3are 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 DE$8'9URARE (DD)
Utili,are0
8entru modelarea sistemelor cu soft3are

implementat *ard3are
8entru modelarea sistemelor client9server
8entru modelarea sistemelor complet

distribuite

DIAGRAME DE C(M:(NENTE
(DC)
descriu un set de componente i relaiile dintre ele.

?rafic, reprezint o colecie de noduri i arce
utilizare'
8entru a modela codul sursa
8entru a modela produse executabile
8entru a modela baze de date fizice
8entru a modela sisteme adaptabile

DIAGRAME DE C(M:(NENTE
(DC)

Eta7e i acti!it#"i0recomand#ri
(material o7"ional de tudiu)
Modelarea reali,#rii unui ca, de utili,are0 poate fi

realizat de una sau mai multe colaborri. 2ceasta
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 7roduelor e6ecutabile i a
bibliotecilor
identificarea partiionrii sistemului fizic. &tabilirea

impactului elementelor te*nice, 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

Eta7e si acti!it#"i0recomand#ri
Modelarea fi-ierelor; 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 interfe"e de 7rogramare a

a7lica"iei (A:I)
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 28) n msura n

care este important pentru a arata configuraia unei
implementri specifice

Modelarea codului ura
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 etic*et, 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, 5(6-ul
folosindu-se doar pentru vizualizare

Modelarea 7roceoarelor i
di7o,iti!elor
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 ditribu"iei com7onentelor
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 im7lement#rii unei o7era"ii
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. (ai departe, se poate
extinde partea structural i comportamental a
colaborrii, folosind diagrame de clasa i diagrame de
interaciune

Modelarea unui mecanim
se identifica mecanismele majore care

formeaz ar*itectura sistemului
se reprezint fiecare mecanism ca o

colaborare
se dezvolt partea de structur i

comportamental pentru fiecare colaborare

Modelarea unui -ablon (7attern) de

7roiectare
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 (7attern) ar.itectural
se stabilete pattern-ul pornind de la o ar*itectur

dat
se modeleaz tiparul de lucru ca un pac*et 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
Curs 11
Curs 11
Adriana Gheorghie,
adrianaa@infoiasi.ro
Ovidiu Gheorghie,
ogh@infoiasi.ro
T
e
s
ta
re
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
36
64
scriere cod
proiectare
Cnd facem erorile?
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
Cazurile de
test
Datele
de test
Rezultatele
testului
Rapoarte
de testare
Proiecteaz
cazurile de test
Pregtete
datele de test
Compar rezultatele
pentru cazurile de test
Ruleaz programul
cu datele de test
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 de test
I
e
Rezultatele testului
O
e
date care cauzeaz
un comportament anormal
rezultate care evideniaz
prezena unor erori
Program
IP
11
Testare funcional (2)
Problema esenial: datele de test selectate
s aib o probabilitate mare de a aparine
mulimii I
e
.
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
Program
Intrri valide
Intrri invalide
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:
Codul componentei
Date de test
Rezultate
deriveaz
testeaz
IP
11
Testare structural exemplu (1)
class Result{
public boolean found;
public int index;
}
class BinSearch{
public static void search(int key, int[] elemArray, Result r)
{
int first = 0;
int last = elemArray.length-1;
int middle;
r.found = false; r.index=-1;
while (first<=last) {
middle = (first+last)/2;
if (elemArray[middle] == key){
r.index = middle;
r.found = true;
return;
} else if (elemArray[middle]<key)
first = middle+1;
else
last = middle-1;
}
}//while
}//search
}
1
2
3
8
9 5 6
7
4
first>last while first<=last
if (elemArray[middle] == key)
if (elemArray[middle]<key)
Graful execuiei
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)
1
2
3
8
9 5 6
7
4
first>last while first<=last
if (elemArray[middle] == key)
if (elemArray[middle]<key)
Graful execuiei
Cazuri de test:
a) 1, 2, 3, 8, 9
b) 1, 2, 3, 4, 6, 7, 2
c) 1, 2, 3, 4, 5, 7, 2
d) 1, 2, 3, 4, 6, 7, 2, 8, 9
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 !"#$ de %o&n 'anle(

pentru a desemna dez)oltarea de software
utiliz*nd 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 nc*t s permit transmiterea uoara a datelor ntre
componente
sa stoc&eze informaiile referitoare la software ntr-o +i+liotec
computerizat, permi*nd accesarea acestor informaii de ctre toi mem+rii
ec&ipei de ela+oratori
s poat fi utilizat ca +az pentru automatizarea procesului de producere a
software-ului folosind una sau mai multe metode de analiz i proiectare
s fie reutiliza+il pentru dez)oltarea de noi sisteme, aplicaii i programe
s poat fi utilizat pe orice platform &ardware, ncep*nd cu calculatoare
personale p*n la mainframe-uri
s permit realizarea uoara a interfeei cu utilizatorul final i e,pandarea
interaciunii cu acesta
s asigure dez)oltarea de aplicaii n lim+a-e de programare e)oluate
s asigure software-ul realizat din punct de )edere calitati).

Importana i a)anta-ele utilizrii
CASE-urilor
scurteaz durata de realizare a proiectelor i de implementare a

aplicaiilor
asigur din punct de )edere calitati) produsul software i cresc
ncrederea utilizatorului n calitatea acestuia
asist realizarea fiecrei etape i deci m+untesc calitatea
procesului de realizare
dez)oltarea software-ului se face conform unor metodologii care
specific pe l*ng etapele de dez)oltare, coninutul i ieirile
fiecrei etape, n mod difereniat dup natura produsului sau dup
domeniul su de aplicaie
o+inerea de specificaii de definire complete
acurateea specificaiilor de realizare .de proiectare/
o+inerea unei ci uor de ntreinut i dez)oltat .n ideea c un
produs software nu este niciodat n mod real terminat, dez)oltarea
sa fiind prelungit de operaiile de mentenan/.

Generaii de produse CASE
include facilitai pentru di)erse etape ale

ciclului de )ia tradiional su+ form de
instrumente pentru0
1
planificarea strategic .la ni)elul sistemelor
comple,e/
1
etapa de analiz
1
etapa de proiectare
1
generare de cod
Generaia I

Generaia I
caracteristici
instrumentele )e&iculeaz un numar

mare de date
ofer interfaa grafica pentru utilizator
sunt utilizate n general pe 2C
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 e,ist un generator central de cod care stoc&eaz
codul generat ntr-un depozit
permit lucrul n ec&ip pentru ela+orarea de proiecte

comple,e, de dimensiuni mari
asigur facilitai de management al acestor proiecte, at*t

pentru acti)itile specifice etapelor ciclului de )ia la
ni)el de proiect, c*t i la ni)elul ntregii organizaii
ela+oratoare de software
acestei generaii i aparin CASE-uri care ofer suport

pentru ntreg ciclul de )ia, numite i Integrated-CASE
sau I-CASE i care ofer suport pentru realizarea
proiectelor folosind mai multe metode de analiz i
proiectare

3eneraia III
caracteristici
4eprezint colecie de produse de tip CASE i

de alte componente integrate care asigur
suportul pentru ma-oritatea tipurilor de
interaciuni ntre componentele mediului i ntre
utilizator i mediu.
asigur monitorizarea realizrii proiectelor, c*t i

realizarea propriu-zis, asigur*nd p*n la
generarea de cod integral i generarea
automat a documentelor cu posi+iliti de
inginerie in)ers .re)erse engineering/.
faciliti indi)iduale pe 2C
faciliti la ni)el de proiect pe 5A6
faciliti la ni)el de organizaie pe mainframe

Clasificarea i evaluarea
produselor CASE
dup metodele de analiz i proiectare

implementate0
1
neorientate o+iect, +azate pe metodologii de
analiz i proiectare structurat .sau metode
funcii7date/8
1
pur orientate o+iect8
1
mi,te - care suport am+ele tipuri de
metodologii.

produselor CASE
dup numrul metodelor de analiz i proiectare

implementate0
1
ofer suport pentru o singur metod de analiz i
proiectare8
1
ofer suport pentru mai multe metode i n acest caz 0
folosete independent mai multe metode8
permite trecerea automat a documentelor realizate pentru o
anumit metod n documente ec&i)alente ale altei metode.
dup modul de acoperire a etapelor ciclului de

)ia i de realizare a aplicaiilor0
1
acoper una sau mai multe pri ale ciclului de )ia8
1
acoper tot ciclul de )ia .I-CASE/.

produselor CASE
dup codul generat:

1 nu genereaz cod8
1 genereaz cod care conine0
numai a+loane i cod parial ce tre+uie completat i optimizat8
cod integral, e,ecuta+il pe +aza transformrii directe a proiectului.
dup modul de lucru asigurat:
1 n ec&ip8
1 n reea.
dup modul n care permite realizarea altor proiecte, sau
saloane de proiecte
1 integral8
1 parial.
permite reverse engineering - actualizarea diagramelor dup

modificri n cod!
permite includerea sa ntr-un mediu integrat de dezvoltare I"E
#Integrat "evelopment Environment$%

E,emple de produse CASE
CASE-uri care implementeaz metodologii de ingineria
informaiei integrate:
1 IE9 - Information Engineering 9acilit(
1 IE: - Information Engineering :or;+enc&
CASE-uri care implementeaz metodologii integrate #&E'ISE,
SAS"&$:
1 E<CE5E4A=>4
1 =EA':>4?
1 A'C - @ESI36E4
CASE-uri suport pentru ciclul de via, azate pe metodologii
structurate sau orientate oiect:
1 SAS=E'-A4BI=EC=
1 EASA-CASE
1 :ES='>C6=
1 CAAE66E->+-ect=eam
1 4ational 4ose.
CASE-uri neintegrate, suport pentru te(nici )i proceduri din
ingineria soft*are la nivel de activitate+sarcin:
1 E4-'odeler
1 ADC.

Componente de az ale unui
produs CASE
editor de diagrame
analizor de structur
depozit central .repositor(/
generator de cod
instrumente pentru inginerie in)ers
generator de documentaie
suport pentru ciclul de )ia
instrument pentru gestiunea proiectului

.management proiect/
interfa utilizator cu +rowser specializat

Editorul de diagrame
este componenta oligatorie a unui

CASE
permite construirea i modificarea tuturor

tipurilor de diagrame
introducerea informaiilor n editor poate fi

fcut n dou moduri0
1
de ctre utilizator, prin intermediul unei
interfee
1
din repositor(, atunci c*nd acesta este
actualizat prin re)erse engineering

Condiii ce tre+uie satisfcute0

1
s permit introducerea i modificarea uoar a
tuturor entitilor grafice descrise de metoda de
proiectare8
1
suprafaa grafic s fie de calitate, s permit operaii
de zoom, de grupare i aliniere a elementelor
diagramei8
1
s permit tiprirea eficient a documentelor i
paginarea lor, precum i selectarea informaiilor ce
)or fi tiprite8
1
s dea posi+ilitatea de a decide entitile ce )or fi
cuprinse ntr-o pagin fr a trunc&ia informaiile8
1
s permit construirea automat a unor tipuri
ec&i)alente de diagrame.

,aza de informaii #repositor-$
este o component oligatorie, care are drept

rol acumularea i stocarea n manier
organizat a tuturor informaiilor
Caracteristici i a)anta-e0
1
documentaia de realizare a oricrui proiect, n
totalitatea ei, se gsete n repositor(, de unde poate
fi tiprit integral sau parial
1
documentaia finala a produsului software este
realizat pe +aza informaiilor despre proiect
coninute n repositor(
1
creterea preciziei i a acurateei documentaiei fa
de cazul n care aceasta este realizat pe &*rtie,
deoarece sunt detectate erorile, inconsistenele i
omisiunile
1
asigur lucrul n ec&ip 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 e,istente n repositor(, i de a
semnala0
1
introducerea n acelai domeniu de )izi+ilitate
.diagram, dicionar de date, etc./ a dou entiti de
acelai tip, cu acelai nume8
1
)erific dac toate entitile referite sunt definite
1
semnaleaz relaii de motenire definite circular
1
)erific corectitudinea semantic i sintactic a
adnotrilor formale.

Instrumentele pentru reverse engeneering

#inginerie invers$ au drept rol re)enirea din
fazele de sf*rit 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 lim+a- de programare, a
diagramelor realizate n faza de proiectare.
,ro*ser specializat - este instrumentul pentru

)izualizarea informaiilor unei mulimi de entiti
cu structur comple,. 2ermite accesul direct al
utilizatorului la diagramele care descriu
proiectele, coninute n repositor(, dispun*nd de
opiuni de filtrare i cutare.

Generator de documentaie - conine

modele de documente i ofer
utilizatorului posi+ilitatea de a-i concepe
propriile documente n mod fle,i+il.
Gestiunea configuraiei - permite

mem+rilor ec&ipei de dez)oltare s
lucreze n paralel i n acelai timp s
foloseasc informaia coninut n modelul
glo+al pentru a dez)olta orice proiect nou.

Ingineria Programarii

Î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

Încărcat de

Drepturi de autor:

Formate disponibile

1.

Graful cauz i efect

Jal!area real. 1 Jal!area a)te#tat.

9eluare p,n c,nd produsul e complet

Calitatea produselor software reprezint

Ea reprezint ansamblul nsuirilor ce

radul de utilitate al produselor program cuprinde:

modelul 8ames 6cCall.

definete urmtoarele caracteristici de

eficiena utilizrii hardware-ului +gradul n care produsul software

extensibilitate - gradul n care produsul faciliteaz e"tinderea sa cu

st la baza elaborarii standardului ;&< 34)/ din 4334.

Factorii de calitate pre$zuti de 6cCall sunt grupai n trei categorii:

+software metrics 9 metrici software) disciplina destinat

=entru o caracterizare concret trebuie respectate

=e plan internaional# domeniul managementului i

&tandardele ;&< seria 3555 pot fi utilizate n urmtoarele

;&< 3555-,:433* CependabilitD 6anagement

;&< 355,-,:433* EualitD ;mpro$ement

;&< 355,-- EualitD :ssurance =lans

;&< 355,-/ =ro(ect 6anagement

;&< 355,-1 Configuration 6anagement

;&< 355,-2 EualitD =rinciples

;&< 4554)-4:433) 6anagement of 6easurement

;&< 4554)-) Control of 6easurement =rocesses

&tandardul ;&<F;ECF34)/ - Caracteristici de calitate

C66 pre$ede cinci ni$ele de maturitate:

Factorii de succes pentru mbuntirea proceselor

Fiabilitatea software e un obiecti$ de

>n conte"tul msurrii software sunt trei clase

metricii trebuie s fie testai nainte de a se utiliza! pot a$ea o baz

metricii trebuie s stimuleze mbuntirile de proces! nu se $or

6etricii de fiabilitate folosesc date obiecti$e i

7azele de date create conin trei tipuri de date:

&e $or aborda trei faze ale ciclului de $ia

Jinii de te"t - linii fizice coninute de fiierul te"t!

;mperati$e - numrul de cerine i fraze care cer s se

Cirecti$e - referine la figuri# tabele sau note!

Fraze ineficiente - clauze care pot produce incertitudine

;ncompletitudine - afirmaii din te"t gen G7C +To Be

<piuni- cu$inte care par s ofere dez$oltatorului alegerea

n4 - numrul de operatori distinci!

n) - numrul de operanzi distinci!

N4 - numrul total de apariii ale

N) - numrul total de apariii ale

numrul de erori rmase n produs!

timpul necesar pentru a detecta erorile

timpul de testare suplimentar pentru a

,ste un limbaj standard pentru scrierea de

Scopul *$- este vizualizarea, speciicarea,

*$- este numai un limbaj, deci este numai o

,ste independent de proces

descoper procesele care au loc #n cadrul

se constituie #ntr5un bun mijloc de

simpliicAreduce comple6itatea sistemului,

deine"te arhitectura sot!are5ului,

permite reutilizarea componentelor(

deinirea granitelor sistemului si unctiilor lui

descrierea cazurilor de utilizare olosind

reprezentarea structurii statice a sistemului

modelarea comportamentului obiectelor cu

reprezentarea arhitecturii izice a implementarii

e6tinderea unctionalitatii cu ajutorul