Carte CNovac

UNIVERSITATEA Vasile Alecsandri
BACU
FACULTATEA DE INGINERIE

CORNELIA NOVAC UDUDEC

INGINERIA SISTEMELOR DE
PROGRAME

Ingineria programrii
Ediie adugit i revizuit

EDITURA ALMA MATER BACU

2011
Ingineria sistemelor de programe

PREFA

Dac constructorii ar construi casele n felul n care programatorii concep
programe, atunci prima ciocnitoare care ar veni, ar distruge civilizaia.
Acest enun de altfel un murphysm, cunoscut i sub numele de legea lui
Weinberg ne poate induce o percepie de loc optimist asupra modul de
concepere i realizare a aplicaiilor software. Situaia real nu este nici pe
departe att de sumbr, dar nici nu putem manifesta un optimism exagerat.
Una dintre legile nencrederii din cunoscuta antologie a lui Murphy se
enun astfel:
Computerele nu sunt piese de ncredere, iar oamenii sunt i mai puin.
Mai mult, legea are i urmtorul corolar:
La originea oricrei erori care este atribuit calculatorului, vei gsi cel
puin dou greeli umane, incluznd-o pe aceea de a da vina pe calculator.
Ingineria software, prin argumentele pe care le aduce, ncearc s
prezinte i celelalte faete ale problemei. Tocmai pentru c se tie c un
program face ceea ce i spui tu s fac, iar nu ceea ce ai vrea s fac, este
absolut necesar ca exigenele utilizatorului s se regseasc n final n
funcionalitatea pachetului software oferit.
Cert este c, s-a renunat de mult la amatorism i la proiectarea ad-hoc a
sistemelor software fie i numai dac ne gndim la complexitatea acestora i a
faptului c realizarea lor scpa de sub control.
Mi-am propus n lucrarea de fa, intitulat Ingineria sistemelor de
programe, o denumire mai complet dect vechea, cea de Inginerie a
programrii, s mprtesc cititorului cte ceva din experiena acumulat i
totodat s-i pun la dispoziie un ghid de proiectare i realizare a sistemelor
informatice cu metodele i tehnicile actuale. Este motivul pentru care, urmrind
ciclul de via al produsului software, am fcut o trecere n revist a paradigmelor
Ingineria sistemelor de programe

din ingineria software, a metodologiei UML, a costului, a calitii i a metricilor de
evaluare a sistemelor software.
Capitolele 6 a fost dedicat abloanelor de proiectare, metodologie
cunoscut n literatura de specialitate ca Design Patterns.
Cartea se adreseaz n egal msur att specialitilor, ct i utilizatorilor
care doresc s cunoasc mai bine caracteristicile de realizare i implementare
ale sistemelor de programe.
De asemenea, lucrarea este destinat studenilor de la seciile inginereti
i de la Informatic, care au ca disciplin de studiu Ingineria software sau
Ingineria programrii i pentru care sper s constituie un instrument de lucru
util.

Autoarea
Martie 2011

Ingineria sistemelor de programe Cuprins

1

CUPRINS

Capitolul 1 Sistemeinformatice. Probleme i perspective Pag.
1.1. Introducere 5
1.2. Probleme ale software-ului 11
1.3. Satisfacerea cerinelor utilizatorului i costul software 13
1.4. Performana, portabilitatea i mentenana software 16
1.5. Fiabilitatea 18
1.6. Cerine pentru ingineria sistemelor de programe 18
1.7. Teorema pentru ingineria software 19
1.8. Clasificarea sistemelor de programe 25
1.9. Documentaia sistemelor de programe 30
1.10.Dreptul de proprietate i garanii 33
1.11. Exerciii propuse 35
Capitolul 2 Etapele de dezvoltare a sistemelor de programe 37
2.1. Ciclul de via 37
2.2. Cerine- Specificaii 46
2.3. Concepte ale specificaiilor de programe 52
2.4. Specificarea formal 57
2.5. Exemple de specificare formal 59
2.6. Exerciii 66
Capitolul 3 Paradigmele de dezvoltare a sistemelor software 69
3.1. Etapele de dezvoltare software 69
3.2. Paradigmele de dezvoltare software 71

2
- Metodologia cascad 78
- Metodologia spiral 81
- Metodologia spiral WinWin 83
- Prototipizarea 84
- Metode formale 88
- Metoda V 89
- Programarea extrem 89
- Metoda Open Source 93
- Reverse Engineering 94
- Metoda de dezvoltare Offshore 94
- Metodologia orientat pe obiect 95
Capitolul 4 UML- Limbaj unificat de modelare 101
4.1. Introducere n UML 101
4.2. Diagrame i concepte UML 104
- Diagrama claselor 105
- Diagrama cazurilor de utilizare 112
- Diagrama de stare 115
- Diagrama de activitate 119
- Diagrama secveniale 122
- Diagrama de colaborare 125
- Diagrama de aplicaie 129
Capitolul 5 Principii de proiectare orientat pe obiect 133
5.1. Principiul Deschis-nchis 133
5.2. Principiul substituiei Liskov 137
5.3. Principiul Inversrii Dependenelor 144
5.4. Stabilitate. Principiul dependenelor stabile 151
Capitolul 6 abloane de proiectare software 161
6.1. Elementele unui ablon de proiectare 161
6.2. Cum rezolv abloanele problemele de proiectare 166
6.3. Cum se selecteaz un ablon 167
6.4. Cum se folosete un ablon de proiectare 169

3
Capitolul 7 Proiectarea sistemelor software 173
7.1. Procesul de proiectare 173
7.2. Proiectarea arhitectural 177
7.3. Proiectarea calitii 180
7.4. Modularizarea proiectului 186
Capitolul 8 Testarea sistemelor software 191
8.1. Introducere 191
8.2. Testarea pe parcursul ciclului de via al unui program 192
8.3. Testele de sistem 196
8.4. Determinarea cazurilor de test 197
Capitolul 9 Estimarea costurilor unui proiect software 211
9.1. Costuri i efort 211
9.2. Modelul Halstead 212
9.3. Modele algoritmice clasice Modele liniare 214
- Modelul Nelson 214
- Modelul Wolverton 215
9.4. Modele algoritmice moderne Modele neliniare 215
- Modelul Walston Felix 216
- Modelul COCOMO 217
- Modelul Putnam Norden 221
- Legea lui Books 223
- Mrimea echipei i productivitatea 223
Capitolul 10 Calitatea sistemelor software 225
10.1. Indicatori de calitate 225
10.2. Productivitatea 228
10.3. Asigurarea fiabilitii produselor software 229
10.4. Metrici software pentru paradigma orientat obiect 233
10.5. Modele de studiere a posteriori a fiabilitii 237
10.6. Modele software pentru reducerea erorilor 247
10.7. Utilizarea datelor eronate pentru mbuntirea deciziilor 252
10.8. Reducerea erorilor datorit msurtorilor 254

4
10.9. Aplicarea analizei cauzale procesului de modificare a software-ului 256
Capitolul 11 Evaluarea sistemelor software 267
11.1. Set de metrici software pentru conducerea proceselor de
mentenan a programelor
267
- Definirea setului de metrici 268
11.2. Program de implementare a metricilor 281
Bibliografie 283

Ingineria sistemelor de programe Capitolul 1
5

1
Sistemele informatice. Probleme i perspective
1.1 Introducere
tiina calculatoarelor, domeniu de activitate recunoscut ca avnd o
dinamic extrem de ridicat, a evoluat n ultimii ani pe coordonate cum ar fi
conceperea de noi tehnologii pentru realizarea aplicaiilor software sau noi
modaliti de lucru n echip. Dac n anul 1946 Goldstine i von Neumann
apreciau c 1000 de instruciuni reprezint o limit superioar rezonabil pentru
complexitatea problemelor ce pot fi concepute ca rezolvabile cu ajutorul
calculatorului astzi o asemenea dimensiune este atins doar cu scop didactic.
Mai mult, dup ce a estimat n 1981 c nici un program pentru calculatoare
personale nu va necesita vreodat mai mult de 640 KB de memorie RAM, Bill
Gates, n anul 1995 a recunoscut c lucrurile s-au schimbat mult n ultimele dou
decenii.
Urmtoarele exemple ofer o imagine mai complet a complexitii la care
a ajuns software-ul n zilele noastre:
o Sistemul de rezervare a biletelor pentru compania aerian KLM
coninea, n anul 1992, 2000000 de linii de cod n limbaj de
asamblare;
o Sistemul de operare System V versiunea 4.0 (UNIX) a fost obinut
prin compilarea a 3.700.000 linii de cod;
o Sistemele de programe pentru controlul navetelor spaiale NASA
au circa 40 de milioane de linii de cod;
o Pentru realizarea sistemului de operare IBM OS360 au fost
necesari 5000 de ani- munc.om.
6
Creterea n dimensiune i complexitate a aplicailor software a depit
cu mult progresele fcute n domeniul tehnicilor de programare. De aceea, o
paralel ntre ingineria software i ingineria construciilor ar fi atractiv.
Dac dorim s construim o cuc pentru cine, putem s mergem n
grdin, s cutam lemne i cuie, s lum un ciocan i s ncepem s lucrm.
Avem anse destul de bune s reuim, mai ales dac suntem ndemnatici.
Dac totui nu ne iese, putem ncerca a doua zi din nou cu alte lemne i alte
cuie. i totui, dac cinele nu ncape n cuc, putem s ne cumprm alt
cine.
Lucrurile stau radical diferit atunci cnd dorim s construim o cas pentru
familia noastr. n acest caz va trebui sau s angajm un arhitect care s ne fac
un proiect, sau s cumprm un proiect standard de cas. Va trebui s negociem
cu o firm de construcii preul, durata de realizare, calitatea finisajelor. Nu ne
permitem s riscm economiile familiei pe o construcie care se va drma la o
rafal de vnt. n plus, dac membrilor familiei nu le place orientarea ferestrelor
sau peisajul, nu i putem schimba cu alii (n cel mai ru caz, ne schimb ei pe
noi).
Cu att mai mult, dac o firm pltete cteva milioane de dolari pentru a
ridica un zgrie nori, reprezentanii acesteia vor fi foarte ateni cu cine i n ce
condiii vor lucra. Ei vor dori garanii c proiectul este viabil, vor angaja mai multe
firme de arhitectur pentru a-l verifica. De asemenea, vor fi obligatorii studiile
geologice, de fizic a pmntului sau meteorologie. Se vor folosi cele mai
performante materiale i se vor angaja cei mai competeni i cu experien
constructori. Eecul nu mai este o opiune pentru contractantul proiectului.
tim c inginerii constructori ntocmesc planuri, construiesc machete,
studiaz proprietile materialelor folosite i fac rapoarte privind progresul
operaiunilor. Construcii de o complexitate foarte mare au fost realizate n acest
fel ntr-un mod raional i economic. Constructorii de aplicaii software trebuie
s procedeze la fel pentru ca dezvoltarea programelor s nu mai fie un proces
impredictibil.
7
Pe msur ce complexitatea programelor cretea, la sfritul anilor 60
ncepea s se prefigureze deja o criz a software-ului. Un raport prezentat de
ctre o companie de software, n care erau analizate diverse proiecte i stadiile
lor de finalizare, a constatat c:
o 2% din sistemele software contractate au funcionat de la predare;
o 3% din sistemele software au putut funciona dup cteva
modificri;
o 29% au fost predate dar n-au funcionat niciodat;
o 19% au fost folosite dar au fost abandonate;
o 47% au fost pltite dar niciodat predate.
Pentru a contracara aceste tendine, la conferina organizat de comitetul
tiinific al NATO n anul 1968, a fost propus termenul de ingineria software (engl.
software engineering), ntr-un mod oarecum provocator. Se dorea ca
programarea s mprumute din rigoarea tiinelor inginereti pentru a putea livra
programe la timp i eficient. Prima definiie dat ingineriei software a fost
formulat astfel (F. L. Bauer):
Ingineria software este stabilirea i utilizarea de principii inginereti solide
pentru a obine n mod economic programe sigure i care funcioneaz eficient
pe maini de calcul reale.
n IEEE Standard Glossary of Software Engineering Technology (1983)
ingineria software este definit dup cum urmeaz:
Ingineria software, ingineria sistemelor de programe sau ingineria
programrii cum a fost cunoscut n Romnia, reprezint abordarea sistematic
a dezvoltrii, funcionrii, ntreinerii, i retragerii din funciune a programelor.
Remarcm c a doua definiie este mai vag dect prima, ntruct nu face
referire la cost i la eficien. Mai mult, se pare c experiena n general negativ
acumulat a fcut s se renune la formularea principii inginereti solide,
ntruct acestea nu pot fi identificate fr a fi supuse contestaiilor.
A doua definiie adaug ns referiri la perioade importante din viaa unui
program, ce urmeaz crerii i funcionrii sale, i anume ntreinerea i
retragerea din funciune.
8
Se consider c ingineria software are urmtoarele caracteristici
importante:
o este aplicabil n producerea de sisteme de programe mari;
o este o tiin inginereasc;
o scopul final este ndeplinirea cerinelor clientului.
Programele mici se pot scrie relativ uor, de ctre un singur programator,
ntr-o perioad destul de scurt de timp. Un program de 100 de instruciuni este
cu siguran un program mic. Nu putem identifica precis grania dintre un
program mic i unul mare, ns pe msur ce dimensiunea programului crete,
apar provocri noi, calitativ diferite.
Deoarece un singur programator, sau chiar mai muli, nu pot avea timpul
fizic pentru terminarea programului, este necesar crearea uneia sau mai multor
echipe de lucru. Este necesar coordonarea i comunicarea ntre echipe.
Complexitatea sistemului software i a organizaiei care realizeaz sistemul
software devine important, putnd depi capacitatea de nelegere a unui
singur individ.
Dac avem n vedere rapoartele publicate de grupul Standish
(www.standishgroup.com) care precizeaz c n Statele Unite ale Americii se
cheltuiesc anual 250 de miliarde de dolari pentru producia de software i c 33%
dintre proiectele informatice eueaz, adic 80 de miliarde de dolari se pierd,
atunci devine extrem de important modul n care este proiectat i realizat
software-ul. Acelai studiu Standish arat c 83% dintre proiectele informatice au
probleme.
Este limpede, n acest context c proiectarea i realizarea aplicaiilor
informatice nu pot fi fcute oricum ci trebuie s respecte normele i metodologiile
standardizate, n primul rnd PMI (Project Managemant Institute) i apoi pe cele
specifice aplicaiilor software.
Termenul de inginerie software, aprut n 1968 i ales ca titlu pentru
conferina despre criza software reunit la iniiativa comitetului tiinific NATO,
sugera analogia cu disciplinele tradiionale i avea ca scop atenionarea i
9
alertarea informaticienilor n privina caracterului rudimentar al tehnicilor folosite
de ei n dezvoltarea software-ului.
Dar n timp ce conceptele au progresat i au fost aplicate metodele cele
mai eficace, instrumentele nu au evoluat pe msur.
Cteva instrumente au aprut foarte repede la nceputul anilor 70, cum ar
fi generatoarele ARIANE, ATLAS, PAC, dar acelea cu excepia lui PAC, au
sucombat datorit faptului c nu s-au putut adapta uor trecerii de la lucrul
batch la cel conversaional .
Apare ca dezirabil o abordare riguroas a problemelor software-ului,
care s includ stilul de lucru, modul de scriere a codului etc.
Nerespectarea cerinelor poate avea efecte serioase. Un sistem de livrare
a insulinei pentru diabetici poate provoca moartea pacientului dac nu
funcioneaz corect. Funcionarea incorect a unui sistem de control al unui
satelit poate provoca pagube de milioane de dolari.
Un program este fiabil dac funcioneaz si continu s funcioneze fr
ntreruperi i erori un interval de timp. Aceast noiune exprim de fapt rezistena
la condiiile de funcionare. Un sistem de operare trebuie s fie fiabil pentru c
este obligatoriu s funcioneze o perioad suficient de lung de timp fr s
clacheze, indiferent de programele care ruleaz pe el, chiar dac nu totdeauna la
performane optime.
Programul este sigur dac funcioneaz corect, fr operaii nedorite. Un
program pentru un automat bancar trebuie s fie sigur, pentru a efectua
tranzaciile n mod absolut corect, chiar dac funcionarea sa poate fi ntrerupt
din cnd n cnd. Atunci cnd funcioneaz ns, trebuie s funcioneze foarte
bine.
Un program are o eroare dac nu se comport corect. Se presupune c
dezvoltatorul tia ce ar fi trebuit s execute programul, iar comportamentul greit
nu este intenionat.
Iat cteva erori celebre:
10
o n primii ani n care calculatoarele au fost introduse la staiile de benzin
din SUA, consumatorii primeau cecuri pe sume enorme. Faptul era privit
n general cu umor i reclamaiile erau rezolvate repede;
o Sistemul de operare IBM OS360 coninea aproximativ 1.000 de erori la
fiecare nou versiune care ncerca s rezolve erorile din versiunea
precedent;
o Un vehicul de explorare a planetei Venus a fost pierdut deoarece
programul primit de pe Pmnt pentru rectificarea orbitei coninea
instruciunea 'DO 3 I = 1.3'; instruciunea corect n limbajul FORTRAN
ar fi trebuit s conin virgul n loc de punct;
o n 1979 s-a descoperit o eroare n programele pentru sistemele de rcire
n centralele nucleare din SUA; din fericire, nu fusese niciodat nevoie
de execuia rutinelor ce conineau erorile;
o Din cauza unei erori n sistemul de avertizare mpotriva atacului cu
rachete balistice, procedurile de contraatac au fost declanate nainte
de a se descoperi c a fost o eroare;
o Racheta Arianne 5 a explodat n iunie 1996 din cauza unei greeli de
programare; costurile s-au ridicat la 500 milioane dolari.
Ingineria software are ca scop obinerea de sisteme funcionale chiar i
atunci cnd teoriile i instrumentele disponibile nu ofer rspuns la toate
provocrile ce apar. Inginerii fac ca lucrurile s mearg, innd seama de
restriciile organizaiei n care lucreaz i de constrngerile financiare.
Problema fundamental a ingineriei software este satisfacerea cerinelor
utilizatorului. Aceasta trebuie realizat nu punctual, nu imediat, ci ntr-un mod
flexibil i pe termen lung.
Ingineria software se ocup de toate etapele dezvoltrii programelor, de la
achiziia cerinelor de la client pn la ntreinerea i retragerea din folosin a
produsului livrat. Pe lng cerinele funcionale, clientul dorete (de obicei) ca
produsul final s fie realizat cu costuri de producie ct mai mici. De asemenea,
este de dorit ca aceasta s aib performane ct mai bune (uneori direct
evaluabile), un cost de ntreinere ct mai mic, s fie livrat la timp, i s fie sigur.
11
Rezumnd, atributele cheie ale unui produs software se refer la:
o Mentenabilitate, posibilitatea de a putea fi ntreinut: un produs cu un ciclu
de via lung este supus deseori modificrilor, de aceea el trebuie foarte
bine documentat;
o Fiabilitate: produsul trebuie s se comporte dup cerinele utilizatorului i
s nu cad mai mult dect e prevzut n specificaiile sale;
o Eficien: produsul nu trebuie s foloseasc n pierdere resursele
sistemului ca memoria sau timpul de procesare;
o Interfaa potrivit pentru utilizator: interfaa trebuie s in seama de
capacitatea i cunotinele utilizatorului.
Optimizarea tuturor acestor atribute e dificil deoarece unele se exclud pe
altele (de exemplu, o mai bun interfa pentru utilizator poate micora eficiena
produsului). n cazurile n care eficiena este critic, acest lucru trebuie specificat
explicit nc din faza de preluare a cerinelor utilizatorului, precum i
compromisurile pe care ea le implic privind ceilali factori.
Trebuie spus c ingineria software nu rezolv toate problemele care apar
atunci cnd se scriu programe dar, n momentul de fa, ea ne poate spune sigur
ce s nu facem.

1.2 Probleme ale software-ului
Una dintre cele mai ntlnite probleme ale sistemelor software este
"proiectarea greit" (n engl. bad design). Pentru a rezolva problema unui
design greit trebuie mai nti definit aceast problem i analizate cauzele ei.
Definiia unei proiectri greite
O pies software care satisface cerinele impuse, legate de funcionalitate,
are un "design greit", dac ndeplinete cel puin una din condiiile de mai jos:
1. Este dificil de modificat, pentru c orice modificare implic modificri n
multe alte pri ale sistemului, aceast caracteristic numindu-se
rigiditate;
2. Dac se face o modificare, alte pri ale sistemului nu mai funcioneaz;
aceast caracteristic se numete fragilitate;
12
3. Este dificil de refolosit n alt aplicaie pentru c nu poate fi detaat de
aplicaia curent. Aceast caracteristic se numete imobilitate.
Cauze ale unui design greit"
Una din cauzele rigiditii, fragilitii i imobilitii unei proiectri este
interdependena modulelor implicate n acel design.
Un design este rigid dac nu poate fi modificat cu uurin. Aceast
rigiditate este cauzat de faptul c o singur modificare ntr-un modul produce o
cascad de modificri n modulele dependente de acesta, datorit
interdependenei. Cnd numrul de modificri (care survin ca urmare a primei
modificri) nu poate fi prevzut de ctre proiectant sau de ctre persoana care se
ocup de mentenana sistemului, atunci impactul modificrii nu poate fi estimat,
i implicit nici costul modificrii.
Fragilitatea este tendina unui program de a nu mai funciona atunci cnd
se face o modificare. n acest caz, survin o serie de noi probleme; cel mai
adesea, acestea sunt de natur diferit dect a modificrii iniiale. Rezolvarea
acestora conduce la alte probleme. O mare fragilitate conduce la un software de
o calitate sczut.
Un design este imobil atunci cnd un modul din program, care se dorete
a fi detaat i folosit ntr-o alt aplicaie, este dependent de detaliile din restul
aplicaiei. Adesea, costul pentru separarea modulului dorit de restul aplicaiei
este mult mai mare dect dac se realizeaz un nou modul, acesta fiind unul
dintre motivele pentru care se renun la re-folosirea / re-utilizarea piesei de
software.
Un sistem software este un sistem dinamic, care de-a lungul ciclului de
via se modific inevitabil.
Modificarea cerinelor pentru un sistem software poate duce la
dezvoltarea unui design greit. De asemenea, modificarea cerinelor nseamn
modificarea specificaiilor. Specificarea cerinelor se realizeaz ntr-un document
scris care trebuie s poat fi citit i neles att de beneficiar ct i de proiectant.
Altfel, beneficiarul nu poate s-l avizeze. Exist mai multe motive pentru care
cerinele se schimb:
13
- Beneficiarul (clientul) software-ului vine cu noi cerine, fie n sensul
adugrii de noi funcionaliti aplicaiei, fie n sensul modificrii funciilor
deja specificate;
- Analistul sau persoana care se ocup de proiect (i a formulat iniial
cerinele aplicaiei) a interpretat greit cererile clientului;
- La iniierea oricrui proiect, se discut cu beneficiarul software-ului despre
ateptrile acestuia de la viitoarea pies de software, scopul fiind
formularea ct mai exact a cerinelor sale. Aceste cerine sunt notate i
analizate. n timpul acestui proces, unele din cerinele iniiale ale clientului
pot fi uitate. n faza de feedback de la client, aceste cerine sunt
reconsiderate. Ca urmare, apar modificri ale programului;
- Exist numeroase alte cauze ale modificrii cerinelor unei aplicaii. Spre
exemplu, cauze care nu sunt legate direct de proiect, dar care se rsfrng
asupra acestuia: o lege nou, o nou politic de aprovizionare a firmei, o
reorganizare sau o fuziune a firmei pentru care este dezvoltat aplicaia,
etc. Toate aceste aspecte pot modifica cerinele aplicaiei. Cu ct durata
de via a proiectului este mai lung, cu att este mai vulnerabil la
modificri de acest tip.
Att sistemele cu un design bun ct i cele cu design greit sunt supuse
modificrilor. Diferena dintre ele este c proiectarea bun este stabil cnd sunt
supuse modificrii.

1.3 Satisfacerea cerinelor utilizatorilor i costul software-ului
Nici un produs, deci nici produsele software, nu vor fi solicitate i utilizate
dac ele nu rspund unor nevoi ale utilizatorilor. Cu ct sunt mai bine acoperite
cerinele celor care beneficiaz de facilitile produsului software respectiv i cu
ct produsul va rspunde mai bine acestor solicitri, cu att cererea pentru
sistemul (produsul) respectiv va fi mai mare.
Statisticile arat c n rile puternic industrializate, ponderea ocupat de
costul software-ului n produsul naional brut este n continu cretere. Acest cost
este influenat, i determinat totodat, de o serie de factori cum ar fi:
14
productivitatea de programare, predicia timpului n care se va realiza produsul
final, costul hardware-ului n raport cu cel al software-ului, utilizarea
generatoarelor de programe, etc.
Costul software-ului este n mare parte determinat de nivelul salariilor
celor implicai n producia de software. Productivitatea medie a programatorilor
este de 10-20 instruciuni (ntr-un limbaj de programare) pe zi. Acestea includ
clarificarea specificaiilor problemei, proiectarea programului, codificare, testare
i documentare.Surprinztor, aceast productivitate nu depinde de limbajul
utilizat. Productivitatea este influenat de lucrul individual sau n echip al
programatorului i de tipul aplicaiei proiectate (software de aplicaii sau software
de baz). Se tie, de exemplu, c sistemele de operare se realizeaz mai greu
dect diversele aplicaii software.
Costul software-ului comparativ cu cel al hardware-ului a iscat controverse
de-a lungul timpului. Faimoasa curb "S - shapped" a artat schimbrile relative
intervenite n cost de-a lungul anilor. De exemplu, n anii '55 software-ul
reprezenta aproximativ 10% din costul proiectului (fig. 1.1).

1960 1970 1980 1990 ani

Fig.1.1. Relaia ntre costul hardware-ului i software-ului n timp
Odat cu impactul social al microcalculatoarelor (al calculatoarelor
personale), percepia omului obinuit n ceea ce privete costul software-ului s-a
modificat.
100%
10%
Hardware
Software
15
"Dac copilul meu poate s scrie un program-joc n dou sptmni, DE
CE este software-ul aa de scump ?" , iat o ntrebare la care nu se poate
rspunde foarte uor, pe nelesul tuturor.
n alt ordine de idei, cheltuielile legate de producia de software sunt
influenate de utilizarea "pachetelor de programe" specializate pentru diferite
probleme (ex. grafic, interfee utilizator inteligente, etc.), precum i de folosirea
generatoarelor de programe de aplicaii.
Rezumnd, se poate spune c software-ul este scump dac ne raportm
la produsul naional brut (este vorba de rile puternic industrializate) n primul
rnd din cauza productivitii sczute a programatorilor. Este ceea ce percepe
omul obinuit. Astfel se nate, n mod natural, ntrebarea : Cum poate fi sczut
costul? Este interesant de vzut care parte din dezvoltarea unui produs software
cost mai mult. Fig. 1.2 ilustreaz acest lucru.

Fig. 1.2 Costul relativ n diferite stadii de dezvoltare ale software-ului

Dac totui erorile sunt o problem major, atunci, cnd apar ele? Fig.1.3
arat numrul relativ de erori comise n diferite stadii de evoluie a software-ului.
Dar problema este puin mai dificil i const n a stabili ct cost depistarea unei
erori. Se tie c o eroare nedescoperit cost mai mult dect ar fi costat ea dac
ar fi fost descoperit i nlturat la timp.

Testare
1/2
Analiza i
Proiectare
1/3
1/6
Codificare
16

Fig. 1.3. Numrul relativ de erori de-a lungul stadiilor de evoluie ale software-ului

Erorile de sintax sunt descoperite automat de ctre compilatoare, la prima
compilare, i pot fi corectate cu uurin. Din contr, erorile de proiectare pot fi
detectate de abia n faza de testare, ceea ce implic o activitate, cteodat
destul de laborioas, de reproiectare.

Fig.1.4 Costul relativ pentru depistarea diferitelor tipuri de erori software

1.4 Performana, portabilitatea i mentenana software-ului
Performana unui program este numit adesea eficien. Acest
terminologie dateaz din vremea cnd viteza hardware-ului era destul de mic iar
costul calculatorului relativ mare, ceea ce nsemna c efortul trebuia ndreptat
spre utilizarea ct mai judicioas a memoriei i procesorului central, printr-un
program ct mai eficient care conducea n final, la scurtarea timpului de execuie
Programare
i
logic
1/3
1/6
Sintaxa
Proiectare

Programare
logic,
sintaxa
20%
17
i deci la o performan mai bun a sistemului. n momentul de fa, prin
performan se subnelege:
- un rspuns al sistemului ntr-o perioad de timp rezonabil;
- obinerea unui semnal de control la ieire (ntr-un timp rezonabil);
Timpul scurt de execuie i utilizarea unei memorii mici sunt dou cerine
mutual contradictorii. De regul exist programe lente, dar mici ca memorie
ocupat, sau rapide, dar de dimensiune mare. n general, este necesar s se
fac o apreciere adecvat a cerinelor de performan particular a unei "piese"
software. Visul productorilor de software a fost ntotdeauna de a transfera
software-ul de pe un tip de calculator pe altul, cu minimum de efort. Odat cu
apariia limbajelor de nivel nalt i cu stabilirea de standarde internaionale s-a
ajuns la o portabilitate complet, n majoritatea aplicaiilor software.
Mentenana este termenul folosit pentru orice activitate de ntreinere a unei
"piese" software, dup ce ea a fost dat n exploatare. Sunt dou tipuri de
mentenan:
a). corectiv - prin care se nltur erorile aprute n timpul exploatrii;
b). adaptiv - care apare ca urmare a schimbrilor intervenite n solicitrile
utilizatorilor, n sistemul de operare sau n limbajele de programare.
O idee despre ct reprezint activitile de mentenan raportate la
ntregul produs software se poate ilustra n fig. 1.5.

Fig.1.5 Proporia activitilor n cadrul realizrii unui produs software

Specificaii
3%
Mentenan
67%
Solicitri 3%
Proiectare 5%
Codificare 7%
Testare unitate 8%
Testare
sistem 7%
18
1.5 Fiabi litatea
n termeni generali fiabilitatea software reprezint capacitatea sistemului
de a rspunde cerinelor utilizatorului (de a-i executa misiunea), n conformitate
cu specificaiile sale de proiectare.
n mod curent, testarea este principala tehnic care d certitudinea c
software-ul lucreaz corect. Dar problema se complic atunci cnd trebuie stabilit
timpul n care este testat o pies software pentru a avea certitudinea c este
corect.
De exemplu: n cazul sistemului OS-360, sistemul de operare lansat de
IBM, dup depistarea unui numr de 1000 erori, firma lanseaz o nou versiune.
n timpul desfurrii programului spaial american, un vehicul spaial fr
om a fost trimis spre planeta Venus. A fost necesar o corecie de traiectorie, iar
calculatorul, care avea misiunea de control, trebuia s execute urmtoarea
instruciune:
DO 3 I=1.3
Aceasta este o instruciune de atribuire perfect valid n FORTRAN, dar
programatorul avea intenia s execute o structura repetitiv (DO) de trei ori
(I=1,3), numai c n loc de virgul dupa cifra 1 (care desemna valoarea iniial a
contorului) a pus punct . Calculatorul a executat deci n locul unui ciclu, o
instruciune de atribuire, dnd variabilei DO3I valoarea 1.3 ! Ca urmare naveta
spaial a luat o traiectorie greit i nu a mai fost gsit niciodat. De notat c
acest program a fost compilat i testat cu succes!
Cu civa ani n urm, sistemul de securitate american a intrat n alarm
sesiznd un atac mpotriva S.U.A. S-a dovedit a fi o alarm fals ca urmare a
unei erori a computerului, dar pn a fost descoperit, populaia a avut "o zi
lung", intrnd ntr-o procedur de autoaprare .

1.6 Cerine pentru ingineria sistemelor de programe
Aa cum a reieit din cele expuse pn acum exist cteva cerine
obligatorii pentru ca un produs informatic, un sistem software s fie utilizat i
anume:
19
- satisfacerea ct mai complet a cerinelor utilizatorului;
- cost de producie ct mai sczut;
- performan ridicat;
- portabilitate;
- cost de ntreinere sczut (mentenan bun);
- fiabilitate ridicat;
- livrare la timp.
Cele mai multe dintre acestea, aa cum se poate observa n fig. 1.6. sunt
n conflict, adic nu pot fi satisfcute simultan la maximum. n consecin, n
funcie de domeniul de aplicaie i de cerinele problemei se va face o ierarhie a
cerinelor acordnd prioritate maxim celor care sunt critice pentru sistem.

Fig. 1.6 Cerine complementare i n conflict n ingineria software

1.7 Teorem pentru ingineria software

S-a amintit n paragrafele precedente despre erorile care apar n sistemele
software mai ales atunci cnd acestea sunt de complexitate mare. Mai mult,
dimensiunea acestora are influen direct asupra costurilor de realizare ale
software-ului.
Costul
producerii
Performana
Uor de
ntreinut
Solicitri
de ultim
moment
Fiabilitate
Cerine n conflict
Cerine
20
S presupunem c avem o msur pentru dimensiunea unei probleme P,
notat cu M(P), iar costul scrierii unui program pentru problema P este C(P).
Dac P i Q sunt dou probleme pentru care avem M(P) > M(Q) atunci ntre
costuri exist relaia C(P) > C(Q). Deci, cu alte cuvinte costul elaborrii
programelor, ntr-o prim aproximaie este o funcie monoton cresctoare de
dimensiunea programelor.
Fie acum dou probleme separate i distincte, notate P i Q, i vrem s
creem un program combinat. Lund mpreun cele dou probleme vom obine o
problem nou P+Q, a crei dimensiune este
M(P+Q) >M(P) +M(Q).
ntre costuri va exista relaia : C(P+Q) > C(P) + C(Q).
Rezult c este mai uor de creat dou programe mici dect unul mare
care cumuleaz funciile ambelor programe. Aceasta se explic prin luarea n
consideraie a complexitii programelor. Pe msur ce complexitatea crete, pot
apare I mai multe erori, generate i de interaciunea dintre programe.
Fenomenul menionat este caracteristic tuturor domeniilor n care se rezolv
probleme.
n toate cazurile la o uoar cretere a complexitii unei probleme (plecnd
de la o problem simpl) se remarc o cretere uoar a numrului de erori. Mai
devreme sau mai trziu ns, numrul de erori ncepe s creasc foarte repede.
Astfel pentru cazul proiectrii programelor se poate obine o curb a erorilor
de felul celei prezentate n fig. 1.7.

Nr. elemente problema
Fig.1.7. Curba erorilor la descompunerea problemei n subprobleme

Nr.cereri
21
Acest efect este determinat de limitrile fiinei umane n prelucrarea
informaiilor. Se pare c suntem capabili la un moment dat s prelucrm simultan
I complet informaii referitoare numai la aproximativ apte obiecte, entiti sau
concepte distincte. Peste 7 2 entitI distincte ce trebuie folosite simultan,
numrul de erori comise crete mult mai repede. Dac problema este
descompus n subprobleme atunci numrul erorilor crete mai lent (linia
punctat).
Tocmai aceast relaie dintre elementele problemei I generarea erorilor
justific inegalitatea C(P +Q) > C(P) + C(Q). Aceasta nseamn c n cazul
problemelor mari pentru a nvinge complexitatea cu un cost mai redus trebuie s
se recurg la descompunerea problemei n module mai mici i
cvasiindependente.
Fcnd o substituie n relaia de mai sus se obine:
C(P) >C(P) + C(P)
numit teorema fundamental a ingineriei programrii, n care P i P sunt dou
subprobleme independente prin a cror rezolvare se soluioneaz la un cost mai
sczut problema P. Dac cele dou probleme nu sunt chiar independente, atunci
trebuie soluionat i interferena dintre ele.
Procesul de descompunere n componente mai simple, relativ
independente, introduce noi surse de erori, mai ales legate de comunicarea
dintre ele. Erorile introduse sunt n general mai simple i mai uor de localizat.
n aceste condiii ne putem atepta la o curb a erorilor care crete mai
lent n raport cu numrul de elemente ale problemei ce trebuie prelucrate
simultan (linia punctat din fig.1.7).
S considerm urmtorul caz:
Trebuie proiectat un produs program cu 5000 linii (instruciuni). El poate fi
realizat ca un singur modul cu un cost ridicat sau descompus n 10 module a 500
de linii fiecare, .a.m.d. n cazul extrem se poate realiza I din 5000 de module a
cte o instruciune fiecare.
Natural, costul de realizare depinde de dimensiunea modulului i va fi cu
att mai mic cu ct dimensiunea este mai mic (curba 1 din fig.1.8).
22
Legend: 1- Cost realizare module
2- Cost realizare interfee ntre module.
3- Cost total

Fig.1.8. Relaiile cost-dimensiune modul i cost-numr module

n schimb, pe msur ce produsul se descompune n mai multe
componente, apar efecte noi datorit interferenelor, n numr mai mare, dintre
module. Cu ct crete numrul modulelor, cu att crete i costul realizrii
interfeelor dintre module (curba 2 din fig.1.8).
Costul realizrii ntregului program (deci I numrul erorilor comise) este
suma dintre cele dou tendine opuse de realizare (curba 3 din fig.1.8).
Ceea ce se poate concluziona de aici este existena unui cost optim de
realizare care determin n ultim instan o dimensiune optim de modul i un
numr optim de module n care proiectul poate fi descompus.
Evident acest optim nu poate fi precizat cu exactitate, ci trebuie cutat n
fiecare caz n parte. O soluie de proiectare care adopt ca baz principiul
modularitii i propune s gseasc acest optim.
Termenul de inginerie software, aprut n 1968 i ales ca titlu pentru
conferina despre criza software reunit la iniiativa comitetului tiinific NATO,
sugera analogia cu disciplinele tradiionale i avea ca scop atenionarea i
alertarea informaticienilor n privina caracterului rudimentar al tehnicilor folosite
de ei n dezvoltarea software-ului . Dar n timp ce conceptele au progresat i au
fost aplicate metodele cele mai eficace, instrumentele nu au evoluat pe msur.
Soluiile la problemele software-ului expuse pn acum nu sunt mutual exclusive,
ci din contra se completez unele pe altele.
3
2
1
Denumire modul /Nr. module
Cost
23
Ele sunt :
- dezvoltarea sistematic n toate stadiile de dezvoltare a unei piese
software ;
- asistena calculatorului pentru dezvoltarea software-ului (limbaje de
generaia a patra, medii pentru dezvoltare software, proiectare asistat
pentru inginerie software instrumente software (CASE), UML, etc.) ;
- concentrarea efortului pentru depistarea ct mai exact a dorinelor
utilizatorilor ;
- utilizarea specificrii formale pentru cerinele sistemului ;
- demonstraia fcut n faa beneficiarilor printr-o versiune timpurie a
sistemului (prototipizare) ;
- utilizarea de limbaje de programare noi ;
- creterea efortului pentru asigurarea c software-ul nu are erori .
Acestea constituie totodat i principalele obiective ale crii de fa, care
vor fi tratate pe rnd n continuare .
Una dintre ideile dominante n abordarea dezvoltrii software-ului este
dezvoltarea pe baza ciclului de via sau modelul waterfall . n acest context
se mparte dezvoltarea unui produs informatic n pai independeni, aflai ntr-o
anumit succesiune.
Paii succesivi sunt:
stabilirea cerinelor

specificarea

proiectarea

implementarea

testarea

operarea i ntreinerea

24
Specialitii au idei diferite despre ce trebuie s conin exact fiecare pas n
parte, dar principiile modelului ciclului de viaa sunt :
1. Exist o serie succesiv de pai ;
2. Fiecare pas este bine definit ;
3. Fiecare pas creeaz un produs definit (adesea doar o foaie de
hrtie) ;
4. Corectitudinea fiecrui pas trebuie verificat cu grij.
Specificarea formal, verificarea, prototipizarea, precum i alte tehnici
actuale se adreseaz numai unei clase de probleme luate n considerare n
sistem, n ciclul de via software.
Pe scar larg, proiectul va cuprinde un numr de activiti legate ntre
ele cum ar fi : analiza, specificarea, proiectarea, implementarea i altele.
n mod categoric, dac vrem ca proiectele software s aib succes atunci
ele trebuie nainte bine planificate i efectiv controlate n fiecare etap de
execuie. Trebuie nlocuite metodele ad-hoc printr-o disciplin organizat.
Unul dintre termenii care este utilizat foarte des astzi n conexiune cu software-
ul este calitatea acestuia. n general, orice produs care corespunde scopului
pentru care a fost realizat este considerat un produs de calitate. n contextul
realizrii software-ului dac un pachet de programe ntrunete ateptrile
utilizatorilor poate fi considerat un produs de calitate.
Calitatea poate fi atins numai dac exist i sunt aplicate efectiv
standarde, tehnici i proceduri care s funcioneze i s fie monitorizate. Aceste
activiti poart numele generic de asigurarea calitii .
Problema producerii unui software corect poate fi abordat prin utilizarea
unor tehnici adecvate de specificare i verificare (formal i informal) . Dar
corectitudinea este numai un aspect al calitaii. Utilizarea explicit a unei
discipline de conducere a proiectului este factorul cheie n obinerea unei caliti
software ridicate.

25
1.8 Clasificarea sistemelor de programe
Clasificarea programelor presupune mprirea acestora n diverse categorii n
funcie de anumite criterii. Exactitatea acestor clasificri depinde n mare
msur de precizia cu care aceste criterii pot fi cuantificate i precizate. O astfel
de clasificare n funcie de dimensiunea programelor mparte programele n:
programe mari i programe mici. Limita dintre aceste clase este vag.
Se consider de obicei c programele mici sunt acelea realizate de o
singur persoan, fr a fi neaparat descompuse n module, ntr-un interval de
timp scurt. n aceasta categorie intr programele realizate de nceptori n cursul
procesului de instruire.
n categoria programelor mari intr n acest context toate programele ce
nu se ncadreaz n limitele convenite pentru programele simple.
O alt schem de clasificare a fost introdus de E.Yourdan avnd, la baz
ceea ce el numete complexitatea tratrii programelor.
Pentru a face o ierarhizare dup acest criteriu, Yourdan ia n considerare
mai muli parametri, cum ar fi:
- dimensiunea programelor exprimat n funcie de linii surs;
- numrul de programatori ce particip la realizarea programelor;
- durata de timp afectat realizrii programului;
- intensitatea interaciunii cu alte programe sau sisteme.
Cerine deosebite: fiabilitate ridicat, complexiti suplimentare.
Yourdan distinge urmtoarele categorii de programe:
1) Programe simple. Aceast categorie cuprinde programele care:
- au mai puin de 1000 linii surs;
- sunt scrise de un singur programator n cel mult 6 luni;
- nu au interaciuni cu alte programe sau sisteme.
2) Programe de complexitate medie
- au mai puin de 10 000 linii surs;
- sunt scrise de 1-5 programatori n cel mult 2 ani;
- au interaciuni puine sau deloc cu alte sisteme;
- constau n general din 10-100 module;
26
Exemple: cea mai mare parte a aplicaiilor existente.
3) Programe complexe
- au mai puin de 100 000 linii surs ;
- sunt scrise de 5-20 programatori n 2-3 ani;
- sunt structurate n mai multe sisteme;
- interacioneaz cu alte sisteme;
- cuprind n general ntre 100-1000 module.
Exemple: compilatoarele pentru limbajele de nivel nalt, SGBD-uri, aplicaii
de timp real.
4) Programe deosebit de complexe:
- au ntre 100 000-1milion de linii surs;
- sunt scrise de o echip format din 100-1000 programatori pe par-
cursul mai multor ani;
- constau din 1000-10 000 module;
- interaciuni complexe cu alte module ;
- necesit prelucrri de timp real, telecomunicaii, multitasking.
Exemple: Sisteme de operare de tip OS/360, VS/370 dezvoltate de IBM,
UNIX, sisteme informatice naionale, etc.
5) Programe aproape imposibile: Dei puine la numr prezint
urmtoarele caracteristici:
- au ntre 1-10 milioane de instruciuni;
- pentru realizare sunt necesare echipe de mai mult de 1000 progra-
matori, pe perioada mai multor ani (10 ani sau mai mult);
- includ ntotdeauna prelucrri de timp real;
- necesit teleprelucrare de date;
- sunt implicate in procese critice (ex.control de trafic aerian, aprare
spaiu aerian);
Pentru un astfel de proiect n Australia s-a specificat un timp mediu ntre
dou cderi consecutive de 47 ani.
Deficiena major a celor dou sisteme de clasificare prezentate mai sus
const n dificultile mari ntimpinate n definirea diverselor clase de programe.
27
Exist in literatura de specialitate un alt sistem de clasificare mai satisfctor,
care se bazeaz pe recunoaterea faptului c orice program este un alt model al
unui model teoretic pentru o abstractizare a unei poriuni din lumea real.
Conform acestei clasificri programele sunt mprite n 3 categorii, S, P i
E. Deoarece programele considerate mari de clasificrile anterioare intr, n
general, n clasele P sau E, noua schem de clasificare reprezint o reluare pe
alt plan a punctelor de vedere anterioare.
A) Programe S - Programe a cror funcie este definit complet printr-o
specificaie. Programarea pe baz de specificaie este forma din care deriv cele
mai avansate metodologii de programare. De precizat c toate programele mari
sunt construite ca structuri de programe S.
Aa cum se remarc din fig.1.9, specificaia, ca o definire formal a
problemei, cuprinde toate datele care stau la baza procesului de creare a
programului. Programul astfel obinut constitue n final o soluie a problemei. El
este ntr-adevr o soluie deci prin execuie pe calculator ieirile sunt deduse din
intrri, n conformitate cu specificaia.

Fig.1.9. Programe S

Poriune din
lumea real
SOLUIE

PROGRAM
PROBLEMA

ENUN FORMAL

SPECIFICAIE PROGRAM
28
n aceste condiii poate fi modificat pentru a-i mbunti claritatea, pentru
a-i reduce resursele necesare n timpul execuiei, sau chiar pentru a crete
ncrederea n corectitudinea sa, ns toate modificrile nu trebuie s-i afecteze
corespondena ntre intrri/ieiri pe care o definete i care este efectiv realizat
n cursul execuiei.
De fiecare dat cnd programul este modificat trebuie aratat c relaia
intrri-ieiri nu s-a schimbat sau c noul program satisface o alt specificaie,
definind astfel o soluie a unei noi probleme.
B) Programe P Exist programe al cror enun este un model al unei
abstractizri a unei situaii din lumea real, coninnd incertitudini, necunoatere,
criterii arbitrare, variabile continue, etc. ntr-un anumit sens un astfel de enun
reflect punctul de vedere personal al analistului i deci att enunul problemei,
ct i soluia ei aproximeaz situaia din lumea real. Exemplu: jocul de ah,
prognoza vremii, etc.

Fig.1.10. Programe P
Poriune din
lumea
real

PROBLEM
SCHIMBARE
COMPARARE

INFORMAIE
PROGRAM

ABSTRACIE
(MODEL REALITATE)

CERINE
SPECIFICAIE
DATE DIN
CALCULE
DATE DIN
OBSERVAII
29
Dei problema de rezolvat poate fi precis definit, acceptabilitatea unei
soluii este determinat de contextul n care este folosit.
Soluia obinut este evaluat prin comparaii cu mediul real i nu cu
specificaia. Aceasta este diferena esenial dintre programul S i P.
Deci dac n cazul programelor S corectitudinea este legat, prin definiii,
numai de specificaii, n situaia programelor P aceasta este strns legat de
valoarea i valabilitatea soluiei obtinute n contextul sau din lumea real.
Diferenele dintre datele obinute din observaii i din calcule pot cauza
modificri n inelegerea realitii, n perceperea i formularea problemei, n
model, n specificaia i/sau realizarea programului.
Diferenele ntre observaii i calcule nu sunt ntotdeauna datorate
funcionrii defectuoase a programului sau imperfeciunii modelului. Acestea sunt
dificulti care n timp pot fi depite. Dar realitatea nu este fix i ea se schimb,
implicnd totodat, noi modificri ale programelor.
C) Programe E (fig.1.11) - Sunt programe care automatizeaz o activitate
uman sau social. Ele reprezint o aplicare a calculatorului n lumea real, din
care cauz noile sisteme mai poart numele i de sisteme cu calculator inclus.
Programele E sunt cele mai predispuse la modificri din cauza unei
interaciuni puternice cu mediul.
Exemplu: Sisteme de operare pentru calculator, gestiune de stocuri,
rezervri de locuri, i sisteme de IA, sisteme expert. n toate cazurile
comportarea sistemului, cerinele utilizatorilor i suportul cerut depind de
experimentrile directe la utilizatori.
Pe msur ce acesta se familiarizeaz cu un sistem al crui proiect i
atribuii, depind cel puin parial, de propria lor atitudine, este posibil o modificare
a comportamentului acestora, pentru a reduce sau a mri eficiena. n mod
inevitabil aceasta implicare conduce la cerine de modificare a sistemului.
Aceste modificri par a fi continue i nu ocazionale i sunt intrinseci naturii
sistemelor de calcul i a modului n care sunt dezvoltate i folosite programele.

30

Fig.1.11. Programe S

1.9. Documentaia sistemelor de programe

O parte extrem de important a oricrui produs software este documentaia,
de care va depinde ulterior utilizarea, ntreinerea sistemului i eventual
extensibilitatea. n mod normal, documentaia este elaborat n cu dou scopuri.
Primul este de a descrie pachetul software i modul lui de utilizare. Aceast
documentaie este cunoscut sub numele de documentaie de utilizare i este
destinat utilizatorului sistemului, avnd un caracter mai puin tehnic.
n momentul de fa, documentaia de utilizare este un instrument de
marketing foarte important. O documentaie bun, mpreun cu o interfa bine
proiectat I prietenoas, mresc accesibilitatea produsului I prin aceasta
sporesc vnzrile. Productorii care se respect angajeaz de obicei personal
calificat pentru elaborarea documentaiei sau furnizeaz versiunea preliminar a
pachetului unor autori independeni, astfel ca la lansarea pe pia a produsului s
apar i manualele necesare diferitelor categorii de utilizatori.
CERINE
SPECIFICAII
Aplicaiie
din lumea
real
PROGRAM
Schimbare
de
mediu
ABSTRACIE
MODEL
Schimbare
IEIRE Comparar
31
n general, documentaia de utilizare ia forma unui manual care conine o
prezentare a celor mai folosite caracteristici oferite de produsul respectiv (adesea
sub forma unui ghid pas cu pas), un capitol cu instruciuni de instalare i o
seciune de referin n care toate funciile produsului sunt descrise detaliat.
Adesea, manualul este disponibil n form tiprit, dar sunt i multe cazuri
n care el este furnizat sub forma unui fiier stocat pe acelaI mediu ca i
produsul software. Aceast modalitate permite utilizatorului s vad pe ecran
poriuni ale manualului chiar n timp ce folosete produsul. n acest caz,
informaiile sunt mprite n segmente de mici dimensiuni, numite pachete de
asisten (help), care sunt incluse direct n sistemul software, n sensul c se
poate cere acces chiar din cadrul programului sau uneori apar automat pe ecran
dac utilizatorul ezit prea mult ntre comenzi.
Cel de al doilea scop urmrit de documentaie este de a descrie sistemul
astfel nct acesta s fie ntreinut pe durata celorlalte perioade de via.
Documentaia de acest tip este cunoscut sub numele de documentaie de
sistem i are n mod inevitabil un caracter mult mai tehnic dect documentaia
de utilizare.
Cu ani n urm, aceast documentaie consta n programe surs, n forma
final, la care se mai adugau unele explicaii schiate dup ncheirea procesului
de dezvoltare abordare, pe care o vor recunoate probabil muli programatori
nceptori. Aceast manier este inacceptabil astzi, mai ales pentru sistemele
de mari dimensiuni.
Astfel documentarea sistemului ncepe cu dezvoltarea specificaiilor iniiale
i continu pe toat durata de via a produsului software. Documentaia va
consta n final din toate documentele elaborate n faza de dezvoltare a
sistemului, inclusiv specificaiile conform crora a fost verificat sistemul,
diagramele de flux de date i de relaii ntre entitI, dicionarul de date I
schemele de sistem, care reflect structura sa modular.
De o mare importan sunt versiunile surs ale tuturor programelor din
sistem, care trebuie prezentate ntr-un format lizibil. De aceea, specialitii
ncurajeaz limbajele de nivel nalt, bine proiectate, includerea n programe a
32
comentariilor i proiectarea modular, care permite prezentarea fiecrui modul n
parte ca un ntreg corect.
Faptul c documentarea sistemului trebuie s fie un un proces permanent
duce la apariia unor conflicte ntre principiile ingineriei software i natura uman.
Pe msur ce dezvoltarea sistemului nainteaz, este puin probabil ca
specificaiile, diagramele i schemele iniiale s rmn nemodificate. De cele
mai multe ori vor aprea schimbri datorate unor probleme care nu au fost
prevzute de la nceput (de aceea i tehnicile care utilizeaz prototipuri iau din ce
n ce mai mult amploare). n acest caz, exist tendina de a se efectua direct
modificrile respective, fr a se mai reveni la documentele proiectate anterior. n
acest situaie, documentele nu mai sunt conforme cu realitatea, iar
documentaia final va fi incorect.
Iat deci un alt argument n favoarea instrumentelor CASE, care uureaz
mult redesenarea diagramelor i actualizarea dicionarelor de date. n plus, n
contextul metodologiilor bazate pe prototipuri, care accept ideea c analiza i
proiectarea sunt procese iterative n cadrul implementrii, modificarea
documentaiei devine regula i nu excepia. n acest mediu, probabilitatea de
obinere a unei documentaii finale corecte crete considerabil.
n nchiere, vom preciza din nou c exemplul cu actualizarea documentaiei
este doar una dintre problemele ntmpinate de ingineria software, care trebuie
s mbine regulile abstracte ale tiinei cu nelegerea naturii umane. Este
suficient s spunem c n orice proiect care implic lucrul n echip apar
inevitabil conflicte interpersonale, ambiii i orgolii, ca s nelegem c ingineria
software este un domeniu vast, care include multe aspecte psihologice ce nu
sunt legate direct de ceea ce numim informatic.Totui, indiferent de natura
relaiilor care exist ntr-o echip de proiectare a produselor software,
documentaia sistemului trebuie s nsoeasc produsul, s fie complet i n
perfect concordan cu versiunea oferit utilizatorului. Este o cerin obligatorie
din cele ce desemneaz aa numitul produs la cheie .Acelai lucru este valabil
i pentru produsele care au suferit modificri, adugri sau extensii.

33
1.10. Dreptul de proprietate i garanii

n nchierea acestui capitol este bine s lum n discuie i cteva aspecte
juridice ale ingineriei software. Dei s-ar crede c principiile juridice generale
sunt suficiente pentru rezolvarea disputelor aprute n industria software, lucrurile
nu stau chiar aa. n particular, este necesar o metod prin care investiia
important fcut de o persoan fizic sau juridic pentru a dezvolta un produs
software de calitate s fie protejat, iar persoana respectiv s-i poat acoperi
cheltuielile I s obin profit. n lipsa unei protecii a investiiei, puini vor fi cei
care s-ar incumeta s produc software-ul de care societatea are nevoie.
Din pcate, problemele referitoare la dreptul de proprietate asupra
produselor software nu se ncadreaz foarte clar n legile existente privind
protecia drepturilor de autor i a brevetelor. Dei aceste legi au fost elaborate
tocmai pentru a permite fabricantului unui produs s-i fac public produsul,
pstrndu-i totodat drepturile de proprietate asupra lui, particularitile
produselor software au pus adesea instanele n mare dificultate n eforturile lor
de aplica i n acest caz legile generale privind proprietatea intelectual.
Iniial, drepturile de autor au fost elborate pentru a proteja operele literare.
n acest caz, valoarea nu st n ideeile exprimate, ci mai degrab n modul n
care sunt redate aceste idei. Valoarea unei opere literatre rezid din stil, form i
nu neaparat din subiect.
Prin urmare, munca autorului (artistului) este protejat acordndu-i-se
acestuia dreptul de proprietate asupra unei formulri a unei idei i nu asupra
ideii n sine. O alt persoan este deci liber s exprime aceeaI idee, cu
condiia ca n cele dou versiuni s nu apar similitudini substaniale.
n cazul unui produs software, ideea se exprim n algoritm. Spre
deosebire ns de o poezie sau un roman, valoarea unui produs software nu
const n maniera particular n care este expimat algoritmul, ci chiar din
algoritm. n multe cazuri, costurile fazei de dezvoltare a unui pachet software se
concentreaz tocmai n descoperirea unor algoritmi, i mai puin n reprezentarea
acestora.
34
Prin urmare, aplicarea direct a legii drepturilor de autor va lsa
neprotrejat tocmai investiia principal a productorului de software, permind
unei firme concurente s utilizeze liber algoritmul descoperit de acesta, cu
condiia ca reprezentarea s nu fie substanial similar.
ntr-un fel, putem spune c legile referitoare la drepturile de autor au fost
concepute astfel nct s protejeze mai degrab implementarea dect funcia,
ns valoarea unui programn const adesea mai degrab n funcie dect n
form.
De aceea, legea dreptului de autor este mai potrivit pentru protecia
programelor care implementeaz algoritmi clasici, bine cunoscuI, dect pentru
protecia investiiilor care conduc la descoperirea de noi algorimi.
Dac un algoritm este deja cunoscut, atunci valoarea programului const n
modul n care este exprimat respectivul algoritm; n schimb, pentru un algoritm
nou i creativ, principala valoare a programului este chiar algoritmul, pe care din
pcate legea dreptului de autor nu l protejeaz.
Este paradoxal, cu ct eforturile de dezvoltare ale unui program sunt mai
creative, cu att legea dreptului de autor l protejeaz mai puin.
n domeniul drepturilor de proprietate asupra pachetelor software,
utilizarea brevetelor se lovete de mai multe obstacole, dintre care cel mai
important este principiul general care statueaz c nimeni nu poate fi proprietarul
unor fenomene naturale, cum ar fi legile fizicii sau formulele matematice.
n general, instanele au decis c algoritmii intr i ei n aceast categorire,
astfel c i n acest caz legea las neprotejat cea mai valoroas component a
programului algoritmul. n plus, obinerea unui brevet este un proces costisitor
i ndelungat, a crui durat poate fi de ordinul anilor. n acest timp, un produs
software se uzeaz moral, iar pn la obinerea brevetului de invenie solicitantul
nu are nici un drept de exclusivitate.
Legile dreptului de autor i cele legate de brevete au rolul de a ncuraja att
creterea numrului de invenii, ct i schimbul liber de idei, n beneficiul
societii.
35
Atunci cnd drepturile le sunt protejate, creatorii i inventatorii sunt mai
tentai s i aduc realizrile la cunotina publicului.
Adesea, productorii de software precizeaz pentru produsele lor un set
de garanii prin care i stabilesc limitele de responsabilitate.
Acestea iau forme ca: n nici o situaie compania X nu i asum
rspunderea pentru pagubele de orice fel provocate prin utilizarea acestui
software sau Compania Y nu garanteaz c acest software corespunde exact
cerinelor dumneavoastr.
Cu toate acestea, instanele iau arareori n considerare aceste limitri de
responsabilitate dac se dovedete c productorul a dat dovad de neglijen.
n aceste cazuri, problema care se pune este dac productorul a asigurat
produsului un nivel de calitate compatibil cu natura sa.
Astfel, un nivel acceptabil pentru un procesor de text poate fi considerat
neglijen dac este vorba de un sistem de control al unui reactor nuclear. Prin
urmare, cea mai bun metod mpotriva eventualelor reclamaii este abordarea
cu maximum de seriozitate a procesului de dezvoltare a sistemului produs.

1.11. Exerciii propuse

1. Care este propria dv. cerin atunci cnd dezvoltai o pies software? De
ce? Trebuie s v reexaminai solicitarea?
2. Este softawe-ul scump ? Ce criteriu ai utilizat pentru a ajunge la concluzia
dumneavoastr?
3. Este uor de dezvoltat/programat un sistem software? Justificai-v
rspunsul.
4. Se tie c exist diferene enorme ntre programatori din punctul de
vedere al productivitii . De ce credei c este aceast situaie? Care
este cauza diferenelor dintre diveri programatori?
5. Se consider urmtoarele cazuri :
a. Un microcalculator care controlez o main de splat;
b. Un sistem de control al unei staii de transformare a energiei electrice;
36
c. Software pentru calcularea i tiparirea unui stat de plat;
d. Un sistem de operare de interes general ;
e. Un sistem care controleaz i monitorizeaz un echipament medical;
f. O rutin matematic de interes general;
g. Un joc pe calculator.
Pentru fiecare dintre aceste situaii analizai importana diferitelor solicitri
identificate n acest capitol. Punei-le n ordine, pentru fiecare situaie.
6. Care credei c va fi costul hardware-ului i software-ului n fiecare dintre
cazurile de mai nainte?
7. Ce credei despre mentenan? V-ar place s o facei?
8. Dai un exemplu de program n care minimizarea timpului de execuie i
memoria ocupat sunt contradictorii. Gndii-v la un exemplu n care
sunt n armonie.
9. Analizai conflictele i consistenele dintre solicitri din ingineria
software.
10. n completarea cerinelor descrise n acest capitol exist i altele n care
ingineria software ar avea succes?


37

2
Etapele de dezvoltare a sistemelor de programe
2.1. Ciclul de via
Exist patru faze fundamentale ale metodologiilor ingineriei software:
o analiza (ce dorim s construim);
o proiectarea (cum vom construi);
o implementarea (construirea propriu-zis);
o testarea (asigurarea calitii).
Dei aceste faze se refer n mod special la ciclul de via al produsului
software, ele pot fi aplicate i altor stadii de existen prin care trece un program
de la natere pn la moarte: lansare, ntreinere, ieire din uz.
2.1.1. Faza de analiz
Aceast faz definete cerinele sistemului, independent de modul n care
acestea vor fi ndeplinite. Acum se definete problema pe care clientul dorete s
o rezolve. Rezultatul acestei faze este documentul care conine specificarea
cerinelor i care trebuie s precizeze clar ce trebuie construit.
Documentul ncearc s redea cerinele din perspectiva clientului,
definind scopurile i interaciunile la un nivel descriptiv nalt, independent de
detaliile de implementare, cum ar fi, de exemplu: formularea problemei,
ateptrile clientului sau criteriile pe care trebuie s le ndeplineasc produsul.
Grania dintre descrierile de nivel nalt i cele de nivel sczut nu este
foarte bine trasat.
Uneori, dac un detaliu tehnic important trebuie specificat, el va aprea n
document. Totui, aceasta trebuie s fie excepia i nu regula. Aceste excepii
pot fi determinate de necesitatea meninerii compatibilitii cu alte sisteme deja
existente, sau a unor anumite opiuni dorite de client, de exemplu utilizarea unui

38
anumit standard sau o constrngere asupra dimensiunilor imaginii aplicaiei, care
poate fi destinat unei categorii speciale de utilizatori sau care va rula pe nite
sisteme cu o serie de particulariti (de exemplu, monitoare care nu suport
rezoluii mari, etc.).
Faza de analiz poate fi vzut ca o rafinare a detaliilor. Distincia dintre
detaliile de nivel nalt i cele de nivel sczut sunt puse mai bine n eviden de
abordrile top-down (unde se merge ctre detaliile de nivel sczut) i bottom-up
(care tind ctre detaliile de nivel nalt).
Documentul cerinelor, numit specificarea cerinelor poate fi realizat ntr-o
manier formal, bazat pe logic matematic, sau poate fi exprimat n limbaj
natural. n mod tradiional, el descrie obiectele din sistem i aciunile care pot fi
realizate cu ajutorul obiectelor. Aici noiunea de obiect nu trebuie confundat cu
obiectul din programarea orientat obiect. Descrierea obiectelor i aciunilor
trebuie s fie general si s nu depind de o anumit tehnologie. Desigur, ntr-o
abordare POO, descrierile vor lua forma obiectelor i metodelor, ns n alte
abordri, obiectele pot fi de exemplu servicii care acceseaz baze de date.
n general, documentul cerinelor descrie ontologia proiectului, adic
vocabularul de cuvinte cheie (n special construcii substantivale i verbale) care
va fi utilizat pentru definirea protocolului specific aplicaiei. Descrierile acestea nu
implic proiectarea arhitecturii aplicaiei, ci enumerarea prilor componente i a
modului n care acestea se comport. Mai trziu, n faza de proiectare, acestea
vor fi transformate n primitive informatice, precum liste, stive, arbori, grafuri,
algoritmi i structuri de date.
Mai concret, documentul trebuie s conin descrieri pentru urmtoarele
categorii:
o Obiecte: Documentul trebuie s defineasc mai nti ontologia sistemului,
care este bazat n mare parte pe construcii substantivale pentru
identificarea pieselor, prilor componente, constantelor, numelor i a
relaiilor dintre acestea;
o Aciuni: Documentul trebuie s defineasc de asemenea aciunile pe care
trebuie s le ndeplineasc sistemul i care sunt sugerate n general de

39
construcii verbale. Exemple de aciuni sunt: metodele, funciile sau
procedurile;
o Stri: Sunt definite ca mulimi de setri i valori care disting sistemul ntre
dou ipostaze spaio-temporale. Fiecare sistem trece printr-o serie de
schimbri de stare. Exemple de stri sunt: starea iniial, cea final sau
strile de eroare. Cele mai multe stri depind de domeniul problemei.
Strile sunt asociate cu obiectele sistemului. Un eveniment declaneaz o
tranziie de stare care poate conduce la ndeplinirea unei aciuni de ctre
sistem;
o Scenarii tipice: Un scenariu este o secven de pai urmai pentru
ndeplinirea unui scop. Cnd sistemul este terminat i aplicaia este
disponibil, clientul trebuie s poat utiliza, ntr-o manier ct mai facil si
clar specificat, toate scenariile tipice ale aplicaiei. Scenariile tipice
trebuie s reprezinte majoritatea scenariilor de utilizare ale aplicaiei.
Ponderea acestora variaz de la un sistem la altul, dar 90% se consider
o proporie acceptabil. Bineneles c un sistem cu un singur scenariu de
utilizare este relativ simplu de obinut, pe cnd unul cu mii de scenarii
posibile va fi mult mai dificil de analizat. Deseori este invocat regula
80/20: 80% din funcionalitatea sistemului se realizeaz cu 20% din efortul
de munc. Executarea restului minoritar de funcionalitate necesit marea
majoritate a timpului de lucru;
o Scenarii atipice: Un scenariu atipic trebuie s fie ndeplinit de sistem
numai n cazuri speciale. Clientul poate s spere, de exemplu, c o eroare
neprevzut este un eveniment atipic. Totui, sistemul trebuie s
gestioneze un numr ct mai mare de categorii de erori, prin tehnici
stabilite, precum tratarea excepiilor, monitorizarea proceselor etc.;
o Cerine incomplete sau nemonotone: O enumerare complet a cerinelor,
pentru toate situaiile care pot aprea n condiii de lucru reale, nu este
posibil. n logica tradiional, o teorie este definit de o mulime finit de
axiome. Teoremele din teoria respectiv sunt propoziii adevrate. Dac
se adaug ulterior noi axiome, teoremele existente rmn valide iar noile

40
teoreme dezvoltate sunt adugate teoremelor stabilite. n logica
nemonoton, adugarea de noi axiome poate invalida unele teoreme care
au fost demonstrate anterior. O nou teorie nu mai este o simpl extensie
a teoriei vechi, ci o mulime de teoreme noi, mpreun cu o parte din
teoremele vechi. Procesul de stabilire a cerinelor are o natur iterativ si
nemonoton. Mulimea iniial de cerine (axiomele) definete posibilitile
(teoremele) sistemului. Noile cerine pot infirma soluiile vechi. Pe msur
ce un sistem crete n dimensiuni i complexitate, stabilirea cerinelor
devine din ce n ce mai dificil, mai ales cnd procesul de colectare a
cerinelor este distribuit, fiind realizat de indivizi cu specializri diferite.

2.1.2. Faza de proiectare
Pe baza cerinelor din faza de analiz, acum se stabilete arhitectura
sistemului: componentele sistemului, interfeele i modul lor de comportare:
o Componentele sunt elementele constructive ale produsului. Acestea pot fi
create de la zero sau reutilizate dintr-o bibliotec de componente.
Componentele rafineaz si captureaz semnificaia detaliilor din
documentul cerinelor;
o Interfeele ajut la mbinarea componentelor. O interfa reprezint grania
dintre dou componente, utilizat pentru comunicarea dintre acestea. Prin
intermediul interfeei, componentele pot interaciona;
o Comportamentul, determinat de interfa, reprezint rspunsul unei
componente la stimulii aciunilor altor componente.
Documentul de proiectare descrie planul de implementare a cerinelor. Se
identific detaliile privind limbajele de programare, mediile de dezvoltare,
dimensiunea memoriei, platforma, algoritmii, structurile de date, definiiile globale
de tip, interfeele etc.
n aceast faz trebuie indicate i prioritile critice pentru implementare.
Acestea sugereaz sarcinile care, dac nu sunt executate corect, conduc la
eecul sistemului. Totui, chiar dac prioritile critice sunt ndeplinite, acest fapt

41
nu duce automat la succesul sistemului, ns crete nivelul de ncredere c
produsul va fi o reuit.
Folosind scenariile tipice i atipice, trebuie realizate compromisurile
inerente ntre performan si complexitatea implementrii. Analiza performanelor
presupune studierea modului n care diferitele arhitecturi conduc la diferite
caracteristici de performan pentru fiecare scenariu tipic. n funcie de frecvena
de utilizare a scenariilor, fiecare arhitectur va avea avantaje i dezavantaje. Un
rspuns rapid la o aciune a utilizatorului se realizeaz deseori pe baza unor
costuri de resurse suplimentare: indeci, managementul cache-ului, calcule
predictive etc. Dac o aciune este foarte frecvent, ea trebuie realizat corect i
eficient. O aciune mai rar trebuie de asemenea implementat corect, dar nu
este evident care e nivelul de performan necesar n acest caz. O situaie n
care o astfel de aciune trebuie implementat cu performane maxime este
nchiderea de urgen a unui reactor nuclear.
Planul de implementare i planul de test, descrise mai jos, pot fi incluse
de asemenea n fazele de implementare i respectiv testare. ns unul din
scopurile fazei de proiectare este stabilirea unui plan pentru terminarea
sistemului, de aceea cele dou planuri au fost incluse n paragraful curent.
Planul de implementare stabilete programul dup care se va realiza
implementarea i resursele necesare (mediul de dezvoltare, editoarele,
compilatoarele etc.).
Planul de test definete testele necesare pentru stabilirea calitii
sistemului. Dac produsul trece toate testele din planul de test, este declarat
terminat. Cu ct testele sunt mai amnunite, cu att este mai mare ncrederea n
sistem i deci crete calitatea sa. Un anume test va verifica doar o poriune a
sistemului. Acoperirea testului este procentajul din produs verificat prin testare. n
mod ideal, o acoperire de 100% ar fi excelent, ns ea este rareori ndeplinit.
De obicei, un test cu o acoperire de 90% este simplu, ns ultimele 10% necesit
o perioad de timp semnificativ.
De exemplu, s considerm BIOS-ul (Basic Input/Output System)
construit de IBM la nceputul anilor 80 n strns legtur cu sistemul de operare

42
DOS (Disk Operating System) al firmei Microsoft. Din raiuni de performan,
BIOS-ul a fost plasat ntr-un chip ROM, i deci patch-urile pentru eventualele
erori erau imposibile. Astfel, au fost necesare teste cu acoperire de 100%. Codul
propriu-zis al BIOS-ului era destul de mic, cteva mii de linii. ns deoarece
BIOS-ul are o natur asincron, testul a presupus mai nti crearea unui mediu
asincron care s aduc sistemul n starea dorit si apoi trebuia generat un
eveniment care s declaneze un test. Foarte repede, setul de test a devenit
mult mai mare dect BIOS-ul. A aprut astfel problema testrii nsui a mediului
de testre! n final, o acoperire de 100% a fost atins, dar cu un cost foarte ridicat.
O soluie mai ieftin a fost nscripionarea BIOS-ului ntr-o combinaie dintre
EPROM (Electronic Programmable Read Only Memory) i ROM. Cea mai mare
parte a produsului era plasat n ROM, iar patch-urile erau plasate n EPROM.
Aceasta a fost abordarea adoptat de Apple pentru Macintosh.
n general, este suficient ca testele s cuprind scenariile tipice i atipice,
fr s verifice ntregul sistem, cu absolut toate firele de execuie. Acesta poate
conine ramificaii interne, erori sau ntreruperi care conduc la fire de execuie
netestate. Majoritatea sistemelor sunt pline de bug-uri nedescoperite. De obicei,
clientul particip n mod logic la testarea sistemului i semnaleaz erori care vor
fi ndeprtate n versiunile ulterioare.
2.1.3. Faza de implementare
n aceast faz, sistemul este construit, ori plecnd de la zero, ori prin
asamblarea unor componente pre-existente. Pe baza documentelor din fazele
anterioare, echipa de dezvoltare ar trebui s tie exact ce trebuie s
construiasc, chiar dac rmne loc pentru inovaii i flexibilitate.
De exemplu, o component poate fi proiectat mai restrns, special
pentru un anumit sistem, sau mai general, pentru a satisface o direcie de
reutilizare.
Echipa trebuie s gestioneze problemele legate de calitate, performan,
biblioteci i depanare. Scopul este producerea sistemului propriu-zis. O problem
important este ndeprtarea erorilor critice. ntr-un sistem exist trei tipuri de
erori:

43
o Erori critice: mpiedic sistemul s satisfac n mod complet scenariile
de utilizare. Aceste erori trebuie corectate nainte ca sistemul s fie
predat clientului i chiar nainte ca procesul de dezvoltare ulterioar a
produsului s poat continua;
o Erori necritice: Sunt cunoscute, dar prezena lor nu afecteaz n mod
semnificativ calitatea observat a sistemului. De obicei aceste erori
sunt listate n notele de lansare i au modaliti de ocolire bine
cunoscute;
o Erori necunoscute: Exist ntotdeauna o probabilitate mare ca
sistemul s conin un numr de erori nedescoperite nc. Efectele
acestor erori sunt necunoscute. Unele se pot dovedi critice, altele pot fi
rezolvate cu patch-uri sau eliminate n versiuni ulterioare.
2.1.4. Faza de testare
Calitatea produsului software este foarte important. Multe companii nu
au nvat ns acest lucru i produc sisteme cu funcionalitate extins, dar cu o
calitate sczut. Totui, e mai simplu s-i explici clientului de ce lipsete o
anumit funcie dect s-i explici de ce produsul nu este performant. Un client
satisfcut de calitatea produsului va rmne loial firmei i va atepta noile funcii
n versiunile urmtoare.
n multe metodologii ale ingineriei software, faza de testare este o faz
separat, realizat de o echip diferit dup ce implementarea s-a terminat.
Motivul este faptul c un programator nu-i poate descoperi foarte uor propriile
greeli. O persoan nou care privete codul poate descoperi greeli evidente
care scap celui care citete i recitete materialul de multe ori. Din pcate,
aceast practic poate determina o atitudine indiferent fa de calitate n echipa
de implementare.
Tehnicile de testare sunt abordate preponderent din perspectiva
productorului sistemului. n mod ideal, i clientul trebuie s joace un rol
important n aceast faz.
Testele de regresiune (engl. regression test) sunt colecii de programe
care testeaz una sau mai multe trsturi ale sistemului. Rezultatele testelor sunt

44
adunate i dac exist erori, eroarea este corectat. Un test de regresiune valid
genereaz rezultate verificate, numite standardul de aur.
Validitatea rezultatului unui test ar trebui s fie determinat de documentul
cerinelor. n practic, echipa de implementare este responsabil de interpretarea
validitii.
Testele sunt colectate, mpreun cu rezultatele standardelor de aur, ntr-
un pachet de test de regresiune. Pe msur ce dezvoltarea continu, sunt
adugate mai multe teste noi, iar testele vechi pot rmne valide sau nu. Dac
un test vechi nu mai este valid, rezultatele sale sunt modificate n standardul de
aur, pentru a se potrivi ateptrilor curente. Pachetul de test este rulat din nou i
genereaz noi rezultate. Acestea sunt comparate cu rezultatele standardelor de
aur. Dac sunt diferite, nseamn c n sistem a aprut o eroare. Eroarea este
corectat si dezvoltarea continu. Acest mecanism detecteaz situaiile cnd
starea curent de dezvoltare a produsului invalideaz o stare existent. Astfel, se
previne regresiunea sistemului ntr-o stare de eroare anterioar.
Exist patru puncte de interes n testele de regresiune pentru asigurarea
calitii.
Testarea intern trateaz implementarea de nivel sczut. Fiecare funcie
sau component este testat de ctre echipa de implementare. Aceste teste se
mai numesc teste clear-box sau white-box, deoarece toate detaliile sunt
vizibile pentru test.
Testarea unitilor testeaz o unitate ca un ntreg. Aici se testeaz
interaciunea mai multor funcii, dar numai n cadrul unei singure uniti. Testarea
este determinat de arhitectur. De multe ori sunt necesare aa-numitele
schele, adic programe special construite pentru stabilirea mediului de test.
Numai cnd mediul este realizat se poate executa o evaluare corect. Programul
schel stabilete stri i valori pentru structurile de date i asigur funcii externe
fictive. De obicei, programul schel nu are aceeai calitate ca produsul software
testat i adesea este destul de fragil. O schimbare mic n test poate determina
schimbri importante n programul schel. Aceste teste se mai numesc teste
black-box deoarece numai detaliile interfeei sunt vizibile pentru test.

45
Testarea intern si a unitilor poate fi automatizat cu ajutorul
instrumentelor de acoperire (engl. coverage tools), care analizeaz codul surs
i genereaz un test pentru fiecare alternativ a firelor de execuie. Depinde de
programator combinarea acestor teste n cazuri semnificative care s valideze
rezultatelor fiecrui fir de execuie. De obicei, instrumentul de acoperire este
utilizat ntr-un mod oarecum diferit: el urmrete liniile de cod executate ntr-un
test i apoi raporteaz procentul din cod executat n cadrul testului. Dac
acoperirea este mare i liniile surs netestate nu prezint mare importan pentru
calitatea general a sistemului, atunci nu mai sunt necesare teste suplimentare.
Testarea aplicaiei testeaz aplicaia ca ntreg i este determinat de
scenariile echipei de analiz. Aplicaia trebuie s execute cu succes toate
scenariile pentru a putea fi pus la dispoziia clientului. Spre deosebire de
testarea intern si a unitilor, care se face prin program, testarea aplicaiei se
face de obicei cu scripturi care ruleaz sistemul cu o serie de parametri i
colecteaz rezultatele. n trecut, aceste scripturi erau create manual. n prezent,
exist instrumente care automatizeaz si acest proces. Majoritatea aplicaiilor din
zilele noastre au interfee grafice (GUI).
Testarea interfeei grafice pentru asigurarea calitii poate pune anumite
probleme. Cele mai multe interfee, dac nu chiar toate, au bucle de
evenimente, care conin cozi de mesaje de la mouse, tastatur, ferestre etc.i
care asociate cu fiecare eveniment sunt coordonatele ecran. Testarea interfeei
presupune deci memorarea tuturor acestor informaii i elaborarea unei
modaliti prin care mesajele s fie trimise din nou aplicaiei, la un moment
ulterior.
Testarea la stres determin calitatea aplicaiei n mediul su de execuie.
Ideea este crearea unui mediu mai solicitant dect cel n care aplicaia va rula n
mod obinuit. Aceasta este cea mai dificil si complex categorie de teste.
Sistemul este supus unor cerine din ce n ce mai numeroase, pn cnd acesta
cade. Apoi produsul este reparat i testul de stres se repet pn cnd se atinge
un nivel de stres mai ridicat dect nivelul ateptat de pe staia clientului. Deseori
apar aici conflicte ntre teste. Fiecare test funcioneaz corect atunci cnd este

46
fcut separat. Cnd dou teste sunt rulate n paralel, unul sau ambele teste pot
eua. Cauza este de obicei managementul incorect al accesului la resurse
critice. Mai apar i probleme de memorie, cnd un test i aloc memorie i apoi
nu o mai elibereaz. Testul pare s funcioneze corect, ns dup ce este rulat
de mai multe ori, memoria disponibil se reduce iar sistemul cade.
Concluzii
Problematica domeniului ingineriei software este divers i se amplific
pe msura creterii continue a complexitii sistemelor software.
Toate eforturile au fost i sunt direcionate ctre satisfacerea ct mai
complet a cerinelor utilizatorilor, a creterii calitii sistemelor i a scderii
costurilor de producere.

2.2. Cerine Specificaii

n mod logic, prima etap n realizarea unui produs software const n
stabilirea cu precizie a ceea ce utilizatorul dorete de la sistem. Dominanta n
aceast etap o constituie comunicarea dintre beneficiar (numit utilizator) i
inginerul software. Inginerul care se ocup de stabilirea cerinelor utilizatorului,
ceea ce de fapt reprezint analiza sistemului, se va numi simplu analist. Totul
ncepe odat cu ideea utilizatorului de a avea un sistem nou. El colaboreaz cu
analistul pentru definirea cerinelor i specificaiilor de proiectare ale sistemului.
Utilizatorul poate s aib o idee foarte vag despre ceea ce dorete sau, din
contra, el poate s tie foarte exact.
n mod foarte categoric, stabilirea specificaiilor de proiectare este o etap
deosebit de important n dezvoltarea ulterioar a sistemului.

2.2.1. Noiunea de "cerin"
Taskul de analiz i definire a cerinelor nu este nou pentru un sistem i n
particular pentru un sistem software. Cerina reprezint ceea ce dorete de fapt
utilizatorul, fr a se preciza de fapt cum se realizeaz acel lucru. Una dintre
marile controverse din Computer Science se enun astfel:

47
Este sau nu este necesar s se specifice i cum realizeaz sistemul o
anumit solicitare. Aceasta este relaia dintre specificare i implementare.
De cele mai multe ori, utilizatorul nu agreeaz s i se explice cum va fi
implementat sistemul, sau mai mult, nici nu-l intereseaz. Pentru analist ns
acest lucru este important pentru c, n funcie de varianta aleas, tie cum s-i
orienteze investigaiile i, de asemenea, ce restricii are. Implementarea unui
sistem poate reprezenta o parte important din specificaiile unui nou sistem. Mai
mult, implementarea i specificarea par a fi intercorelate.
Mai sunt i alte considerente i raiuni la care analistul trebuie s se
gndeasc n timpul analizei. n primul rnd, trebuie s verifice dac o anumit
solicitare este tehnic posibil. n al doilea rnd, este vital s ia n considerare
implementarea pentru a putea estima costul i data de livrare a sistemului. O alt
cerin pentru specificaii este dac acestea pot s constituie un ghid privind
modul n care sistemul rspunde dorinelor utilizatorilor.
Cteodat, specificaiile sufer de deficiene majore, cum ar fi: sunt
incomplete, nu exist nici o meniune despre cost sau termen de livrare.
S lum acum n discuie specificaiile solicitrilor pentru o pies simpl
de software:
S se scrie un program Pascal care s realizeze un repertoar de telefon
personal. Programul trebuie s implementeze funciile de cutare a unui numr
dat i de introducere a unui numr nou. De asemenea, el trebuie s realizeze o
interfa prietenoas cu utilizatorul .
Pentru a decide dac o specificaie este bun, se formuleaz ntrebrile:
- Oare spune CE trebuie s fac sistemul i nu CUM ?
- Este clar ?
- Este suficient de detaliat ?
- Este complet ?
n privina primei ntrebri se stipuleaz deja n enun c, programul va fi
scris n limbajul Pascal, care semnific de fapt CUM se va implementa aplicaia.
n al doilea rnd, specificaiile nu dau detalii asupra naturii celor dou funcii - ele

48
sunt, n totalitate, vagi. n al treilea rnd, cerina cu privire la interfaa prietenoas
cu utilizatorul este i ea extrem de vag.
n concluzie, este uor s scrii specificaii pentru piese software, dar este
dificil s scrii specificaii bune. Se va examina mai departe ghidul pentru scrierea
specificaiilor produselor software.

2.2.2. Procesul de alegere a cerinelor
Activitatea de selectare a cerinelor presupune colaborarea i lucrul
mpreun att al analistului ct i al utilizatorului. Se pot distinge trei feluri de
activiti n cadrul acestui proces de specificare a cerinelor, i anume:
- ascultarea ( sau selectarea cererilor);
- analizarea cererilor;
- scrierea (sau definirea cererilor).
Selectarea presupune ascultarea nevoilor utilizatorilor, punnd ntrebri
astfel nct utilizatorii s-i poat clarifica ct mai bine cererile, ca n final s se
nregistreze punctul de vedere al utilizatorului privind specificaiile sistemului.
Analiza este etapa n care efectiv inginerul software se gndete cum poate
transforma punctul de vedere al utilizatorului, privind sistemul, ntr-o reprezentare
care s poat fi implementat n sistem. Acest lucru poate fi adesea dificil din
cauza existenei unor puncte de vedere diferite ale diverilor utilizatori.
Definirea cererilor nseamn scrierea ntr-o manier clar, adesea n limbaj
natural, a ceea ce sistemul trebuie s furnizeze utilizatorului. Aceast informaie
se numete specificarea cererilor.
n procesul complicat al comunicrii i negocierii aceste trei activiti se pot
repeta sporadic. De multe ori, pot exista situaii de conflict, generate de exemplu
de faptul c unii utilizatori influenai de filmele de "science fiction" vzute, au
impresia c se poate face orice cu calculatorul, sau doresc un nivel foarte nalt
de inteligen artificial.
Rezumnd, rolul analistului este:
1. S achiziioneze i s selecteze cererile de la utilizatori.
2. S ajute la rezolvarea diferenelor posibile dintre utilizatori.

49
3. S avizeze utilizatorul despre ceea ce este tehnic posibil sau imposibil.
4. S clarifice cererile utilizatorilor.
5. S documenteze solicitrile (se va vedea n seciunea urmtoare).
6. S negocieze i n final s pun de acord diferitele opinii al utilizatorilor
pentru formularea specificaiilor.

2.2.4. Specificarea cerinelor
Sfritul procesului de analiz i selectare a cererilor l constituie
specificarea acestora. Este o "pies vital" din documentaia sistemului,
crucial n dezvoltarea ulterioar a oricrui sistem. Specificarea este
documentul de referin prin care este asigurat dezvoltarea sistemului.
Cei trei factori importani care sunt luai n consideraie sunt:
1) nivelul de detaliere;
2) cui este adresat documentul;
3) notaiile utilizate.
Primul factor se refer la nevoia de a restrnge specificaiile, pe ct posibil
numai la ceea ce "face sistemul" i nu la cum va realiza cerina respectiv.
A doua problema este important deoarece specificaiile trebuie s fie
nelese de dou categorii diferite de oameni: utilizatori i proiectani.
Utilizatorii prefer o descriere netehnic, exprimat n limbaj natural. Din
pcate acesta este excelent pentru scrisori i comunicare, dar impropriu pentru
specificaii precise, consistente i neambiguii.
Pe de alt parte, analistul avnd o orientare tehnic, va dori probabil s
utilizeze o notaie precis (chiar matematic) pentru a specifica sistemul.
Exist cteva notaii pentru scrierea specificaiilor:
- informale - scrise n limbaj natural, utilizate ct mai clar i cu ct mai mult
grij posibil;
- formale - utiliznd notaii matematice, cu rigoare i consisten;
- semiformale - utiliznd o combinaie de limbaj natural cu diferite diagrame
i notaii tabelare.

50
Cele mai multe dintre aceste notaii i au originea n metodele pentru
proiectarea software-ului, care sunt de fapt metodele de implementare a
software-ului. Aceste notaii vor fi discutate mai trziu i includ pseudocodul,
diagramele de flux i diagramele de structur
n momentul de fa, cele mai multe specificaii sunt scrise n limbaj natural,
la care se adaug notaii formale, cum ar fi diagramele de flux, diagramele UML
pentru a clarifica textul.
Varianta modern este de a elabora dou documente i anume:
1. Specificaiile cererilor scrise n primul rnd pentru utilizatori, pentru a
descrie punctul lor de vedere asupra sistemului, exprimat n limbaj natural.
Acestea constituie substana contractului dintre utilizatori i proiectani.
2. O specificare tehnic, care este folosit n primul rnd de proiectani,
exprimat ntr-o form de notaii formale i descriind numai o parte a informaiei
n toate specificaiile cererilor.
n msura n care aceste dou documente sunt adoptate trebuie ca ele s
fie compatibile. Considernd c specificaiile sunt scrise de obicei n limbaj
natural, trebuie s se proiecteze structura general a specificaiilor i s se
identifice prile componente.
O abordare care asigur o structur clar a specificaiilor este
partiionarea. Programele sunt constituite n mod esenial, din combinaii de date
i aciuni. n specificaii, elementele corespunztoare sunt solicitrile funcionale
i de date.
Una dintre disputele majore din "lumea calculatoarelor" este relativ la
prioritatea uneia sau alteia dintre cele dou elemente eseniale i anume: date
sau funcii. n abordrile de dezvoltare a sistemelor din ingineria software se
tinde mai mult spre a plasa datele dup aciuni. Din contra, n abordrile de
tratare a informaiei se plaseaz mai nti datele i apoi aciunile.
Abordrile actuale de dezvoltare a sistemelor software, cum ar fi cele
orientate pe obiecte, acord o importan egal datelor i funciilor care trateaz
aceste date.

51
Totui, formatul specificrilor tinde s reflecte metoda de dezvoltare a
sistemului care va fi utilizat ulterior.
O lista de verificare a coninutului pentru specificaiile solicitrilor trebuie
s arate astfel:
- solicitri funcionale;
- solicitri de date;
- restricii;
- ghid de aplicare.
Solicitri funcionale
Solicitrile funcionale sunt esena specificaiilor cererilor. Ele indic
sistemului "ceea ce trebuie s fac". Solicitrile funcionale sunt caracterizate de
verbe i realizeaz aciuni.
Exemple:
- Sistemul va afia titlurile i toate crile scrise de acelai autor.
- Sistemul va afia permanent temperaturile tuturor mainilor.
Solicitri de date
Acestea au dou componente:
1. Date de intrare sau ieire pentru sistem, cum ar fi de exemplu dimensiunile
ecranului;
2. Date care sunt memorate n sistem, de obicei n fiiere pe disc. De
exemplu, informaia despre crile dintr-o bibliotec public.
Restriciile
Acestea au de regul influene asupra implementrii sistemului. Exemple:
Sistemul trebuie scris n limbajul de programare ADA, Sistemul va
rspunde utilizatorului n timp de o secund. Principalele restricii care pot
apare sunt:
1). Costul
2). Termenul de livrare
3). Echipamentul hardware necesar
4). Capacitatea intern a memoriei
5). Capacitatea memoriei externe

52
6). Timpul de rspuns
7). Limbajul de programare care trebuie utilizat
8). Volumul de date ( ex. sistemul trebuie s memoreze informaii despre
10000 angajai)
9). Nivelul de ncrcare pentru terminale pe unitatea de timp
10). Fiabilitatea solicitrilor (ex. sistemul trebuie s aib un anumit timp mediu
ntre defeciuni pentru o perioad de ase luni).
Restriciile se adreseaz adesea implementrii, de aceea trebuie fcute cu mare
grij.
Ghidul de aplicare
Acesta furnizeaz informaii utile pentru implementare, n situaia n care
exist mai multe strategii de implementare. De exemplu: Timpul de rspuns al
sistemului la cererile sosite de la tastatur trebuie s fie minimizat. Sau o alt
alternativ: Utilizarea memoriei interne trebuie s fie ct mai redus.
Acum, dup ce s-au studiat diferitele clasificri ale specificaiilor, trebuie
examinate i deficienele care pot s apar. Una dintre ele este imprecizia
informaiei. De exemplu: Interfaa va fi prietenoas. n alt situaie sunt n
contradicie unele cu altele, cum ar fi: Rezultatele vor fi memorate pe suport
magnetic , sau, Sistemul va rspunde n mai puin de o secund.
Omisiunea sau incompletitudinea pot fi uneori dificil de identificat. O
categorie tipic de specificaii omise este aceea referitoare la tratarea datelor de
intrare eronate, furnizate de utilizator. Cteodat o solicitare este neclar sau
susceptibil de mai multe interpretri i aceasta datorit, bineneles, limbajului
natural de descriere.
n conluzie, realizarea cu succes a specificaiilor este o activitate necesar
i care solicit implicarea cu competen a unui mare numr de persoane.

2.3. Concepte ale specificaiilor de programare
Orice program se exprim n dou forme:

53
una fiind o mulime obinuit de comenzi i structuri de control
caracteristice limbajului de programare utilizat, care exprim CUM se
rezolv problema;
a doua este o serie de propoziii (secvene) ntr-un formalism
matematic, care exprim CE face programul.
Presupunnd c una dintre aceste forme este o reprezentare
satisfctoare a inteniilor programatorului, dac se poate demonstra c ele
expim acelai lucru, sau au aceeai semnificie, atunci se poate concluziona c
programul este corect. Aceast abordare a verificrii programului nu implic nici
un alt concept de corectitudine absolut, ci doar demonstreaz consistena celor
dou descrieri ale aceleeai probleme.
Atunci cnd se solicit descreierea semnificaiei unei piese de software,
de regul se descrie interaciunea programului cu mediul utilizatorilor.
Exprimarea semnificaiei programului n termenii utilizatorilor prin descrierea
execuiilor sale posibile se numete descriere operaional. Aceast descriere
nu este unic, o alt cale fiind descreierea n termenii entitilor unui limbaj de
programare.
Utilizarea unui formalism pentru descrierea programului permite
verificarea mai multor implementri ale aceleai probleme.
Exprimarea semnificaiei programului (ale specificaiilor sale) ntr-un
formalism al calculului cu predicate de ordinul nti, chiar dac raionamentul
este nc n termenii entitilor utilizate de limbajul de programare, este efectiv
independent de orice concept al execuiei comenzilor pe un calculator real sau
abstract. Acest concept este important deoarece permite ca, n principiu s se
exprime semnificaia programului ntr-o astfel de manier nct consistena mai
multor implementri s fie verificat.
Se tie c una dintre cele mai importante surse de erori n programe este
generat de absena unei poriuni din proiectul logic, deci un program trebuie
exprimat (descris) n aa fel nct s se reduc aceast surs de erori.


54
2.3.1.Variabilele i strile unui program
Dac examinm un program scris n orice limbaj de programare putem
identifica dou aspecte: unul este controlul execuiei instruciunilor (if-then, etc.),
al doilea este execuia comenzilor (ca asignri de valori rezultate n urma unor
evaluri).
Ne putem astfel imagina c pentru fiecare variabil a programului exist o
stare care conine informaia curent la orice moment de timp. Aceast stare
este identificat de valoarea variabilei care poate fi schimbat de execuia unei
comenzi.
S presupunem c fiecrei variabile a unui program i asociem una din
axe ntr-un spaiu cartezian multidimensional, care se va numi spaiul strilor
unui program. Un punct n acest spaiu este o stare a programului. Execuia
unei comenzi elementare este vizualizat n acest spaiu ca un segment ce leag
starea programului nainte de execuie de cea de dup execuie. n acest
context, spaiul strilor este o mulime a tuturor valorilor posibile ale variabilelor
programului.
Expresia condiiilor care trebuie satisfcute, n spaiul strilor, pentru o
execuie corect a programului se numete precondiie. Specificaiile strilor la
terminarea programului se numesc postcondiii.
Operaiile dintr-un program ne permit s reorganizm diferitele
reprezentri ale aceluiai concept. Un tip de date este o mulime de valori i
operaii definite pe ea nsi.
Exemple:
" mai mare dect " : G x G {true, false}
>
"adunare" : G x G G
+
n acest context, un sistem este o colecie de mecanisme care realizeaz
unul sau mai multe tipuri de date.

55
Tipurile de date pot fi definite prin enumerare, prin operaii sau prin
proceduri. Depinde de limbajul de programare modul n care acestea sunt
implementate n compilatoare.
n conformitate cu Dijkstra programatorii pot utiliza trei modaliti de
proiectare a programelor: enumerarea, inducia matematic i abstractizarea.
Instrumentul mental al enumerrii este principala metod folosit de
programatori. Utilizm gndirea enumerativ ori de cte ori vrem s instruim pe
cineva despre execuia mai multor activiti.
A doua metod indicat de Dijkstra, inducia matematic, este foarte
utilizat pentru proiectarea structurilor repetitive (cicluri). De remarcat c, inducia
matematic nu este un proces mental natural ca enumerarea.
n general, principiile induciei pot fi definite astfel:
1. Baza induciei este de a stabili c un anumit element p al unei mulimi
S satsface o relaie R.
2. Pasul induciei este de a arta c un element generic y a lui S
satisface R, adic exist T(y), unde T este orice fel de transformare n
care alt element a lui S satisface R.
3. Dac baza i pasul induciei sunt demonstrate, atunci orice element
derivnd din p printr-un numr de aplicaii ale lui T, de asemenea
satsfac R.
Principiul induciei este fundamentarea teoretic a metodei de verificare
propus de Floyd. Importana acestui concept de baz este aceea c nu cere o
execuie mental a unei secvene de comand, permind proiectarea i
verificarea ciclurilor care trebuie executate de mai multe ori, n funcie de valori
particulare ale datelor.
Atunci cnd inducia matematic este aplicat asupra strilor descrise de
relaia R, aceast metod este un instrument efectiv pentru proiectarea
secvenelor de iteraii n general i executarea lor de ori cte ori.
n proiectarea programelor, aa cum am amintit deja, se utilizeaz i
limbajul logicii predicatelor. Fiecare predicat definete un subset al spaiului
strilor pentru care el este adevrat.

56
Precondiia unui program este un predicat care definete un subset al
strilor acceptat ca intrare legitim. Constanta predicat T, care este adevrat
peste tot, definete toate strile posibile ale spaiului strilor. Constanta predicat
F, care este fals peste tot, nu definete nici o stare n spaiul strilor.
Cu alte cuvinte, dac spaiul strilor reprezint ntregul univers al
obiectelor care pot fi manipulate de program, T definete n ntregime acest
univers , iar F este mulimea vid. Dac un program a fost specificat cu o
precondiie care accept orice stare din spaiul strilor, T este n mod clar
predicatul care reprezint corect aceast condiie.
Predicatele definesc submulimi ale spaiului strilor. n acest context,
verificarea corectitudinii programului n totalitate poate fi definit.
Dndu-se un program S i o precondiie r, vom gsi "cea mai slab
precondiie", adic condiia care definete numai i numai acele stri iniiale care
asigur terminarea n strile care satisfac r.
Aceast precondiie, "cea mai slab" este un predicat funcie att de S
ct i de r, indicat prin wp(S,r).
Bineneles c se poate defini i problema dual. Dndu-se o precondiie p
a unui program S, vom gsi "cea mai puternic" postcondiie, adic predicatul
care definete numai i numai acele stri pentru care programul va satisface
terminarea cnd este iniializat ntr-o stare care satsface p.
Aceast "cea mai puternic" postcondiie este o funcie de S i p definit
ca Sp(S,p).
Conceptele "cea mai slab" precondiie i "cea mai puternic" postcondiie
au fost introduse de Dijkstra n 1976. Acestea au fost necesare pentru a descrie
tehnica de proiectare a lui Dijkstra numit calculul programrii.
Ideea de baz este de a utiliza tehnici de demonstrare a corectitudinii nu
prin verificarea programului deja creat printr-un mijloc sau altul , ci prin a ghida
pas cu pas proiectarea programului n mod explicit i contient.
Calculul Dijkstra este direct ndreptat spre realizarea unei tehnici care, la
fritul programelor, s furnizeze verificarea proiectrii lor printr-o analiz
"intelectual" nainte de testarea produsului.

57
Pe scurt, calculul Dijkstra const n construirea de expresii scrise n
limbajul calculului predicatelor care s descrie precondiiile i postcondiiile
problemei i care s se verifice ca adevrate n contextul problemei. Puterea
acestui calcul este evident n cazul problemelor greu de algoritmat.
O tehnic destul de comun n programare este abstractizarea procedural.
Ea const din abstractizarea unei piese din program (de regul nescris nc)
prin substituirea n textul su a precondiiei i postcondiiei. n acest fel ntreaga
structur a programului poate fi definit i se demonstrez corectitudinea lui prin
utilizarea unui text mai scurt.
Aceast tehnic poate fi efectiv aplicat pentru algoritmi a cror
complexitate i dimensiune nu sunt prea mari. Nu este de imaginat s se aplice
aceast metod pentru proiectarea unui sistem software mare. Totui, este
posibil de conceput c fiecare sistem mare este compus din mai multe pri
componente, fiecare dintre acestea nefiind prea mare, care poate fi proiectat
folosind abstractizarea procedural.
Problemele specifice limbajelor de programare, cum ar fi pointerii i
transmiterile de parametri ntre module, limiteaz aplicabilitatea calculului
Dijkstra. Totui, exprimarea specificaiilor programelor n termenii limbajului
calculului predicativ ajut la reducerea erorilor.

2.4. Specificarea formal
Obiectivul acestui capitol este de a nelege i scrie specificaiile unui
sistem software. S-a amintit deja c ieirile din activitatea de analiz sunt
constituite din specificaii de proiectare, care conin att solicitri funcionale ct
i solicitri de date, cu alte cuvinte se detaliaz cu precizie ceea ce sistemul va
executa avnd n vedere restriciile practice de care proiectantul va ine cont. Ne
vom referi la componenta funcional a specificaiilor de proiectare ca la o
specificaie software .
Comportarea unui sistem este influenat de dezvoltarea lui n cele trei
faze, i anume: specificarea, implementarea i verificarea. O abordare
convenional este specificarea sistemului n limbaj natural (n limba romna),

58
scrierea programului ntr-un limbaj de programare (ex. Pascal) i verificarea prin
testare. S-a argumentat c o astfel de abordare este susceptibil la tot felul de
erori i n ultim instan genereaz software incorect.
Utiliznd abordarea convenional se pune ntrebarea: cum i de ce au
fost scrise programe incorecte? Exist trei cauze eseniale:
1. Specificarea este greit - ea poate fi ambigu, vag, inconsistent
i/sau incomplet.
2. Programul este greit - nu execut ceea ce exist n specificaii.
3. Verificarea este incomplet - testarea nu este exhaustiv, mai mult
dect att, nici nu poate fi exhaustiv .
Exist urmtoarele aseriuni pentru cele trei faze importante din
dezvoltarea software-ului :
1). Specificarea este o descriere - adic spune CE reprezint problema;
2). Problema este o realizare a specificaiei - adic spune CUM poate fi
rezolvat problema;
3). Verificarea este o justificare - spune DE CE realizarea satisface
specificaia.
Specificarea ntr-o notaie formal, mai mult dect ntr-un limbaj natural,
aduce beneficii imediate. "Formal" nseamn scrierea n ntregime ntr-un limbaj
cu o sintax explicit i precis i cu o semantic definit. Limbajul matematic
este mai apropiat pentru acest scop.
Avantajele utilizrii unei notaii formale pot fi rezumate astfel:
- Specificaiile formale pot fi studiate matematic - cu alte cuvinte, o
specificaie poate fi judecat utiliznd tehnicile matematice. De exemplu, diverse
forme de inconsisten sau incompletitudine n specificaii pot fi detectate
automat.
- Specificaiile formale pot fi ntreinute cu mai mult uurin dect dac
ar fi scrise n limbaj natural. Aceasta face ca specificaiile s prezinte mai mult
siguran i s fie asigurat controlul posibilelor consecine ale schimbrilor.
- Notaia utilizat pentru exprimarea specificaiilor formale este extensibil.

59
Utiliznd un limbaj de specificare formal avem posibilitatea de a mecaniza
transformarea specificaiilor n programe. Prototipizarea sistemelor (n general
ineficient) poate fi generat automat din specificaii mai adecvate pentru
viabilitatea sistemului propus.
i mai important este c n acest fel, avem posibilitatea potenial de a
dovedi corectitudinea programului n raport cu specificaiile sale.

2.5. Exemplu de specificare formal
n mod curent, cele mai cunoscute limbaje de specificare formal sunt Z i
VDM. Ambele utilizeaz o abordare pe baz de model, adic reprezint tipurile
de date i structurile necesare pentru a putea descrie problema folosind entiti
cum ar fi: mulimi, funcii i propoziii.
Limbajul Z a fost prima dat introdus de Jean-Raymond Abriel n 1979 i
dezvoltat n cadrul Programming Research Group la Universitatea Oxford. Partea
"puternic" a lui Z este aceea c specificaiile structurate pot fi achiziionate
folosind "schema de calcul" ; aceasta permite specificaiilor s fie construite n
trei blocuri mai mici, iar programele pot fi proiectate top-down sau bottom-up,
pentru componentele lor procedurale.
Metoda VDM (Vienna Development Method) a fost iniiat n laboratoarele
de cercetare IBM din Viena, n 1970. Aceast metod se bazeaz pe notaiile
semantice, o abordare a definirii limbajelor de programare fcut de Scott i
Strachey. VDM reprezint mai mult dect un limbaj semantic, el punnd la
dizpoziia celor care l utilizeaz reguli i proceduri care vor fi urmrite n diferite
stadii de dezvoltare a sistemului.
Z i VDM au notaii vaste i complexe. Este interesant poate de subliniat
c un set relativ mic de instrumente permite specificarea cu uurin a unei clase
largi de probleme tipice.
Pentru a putea nelege mai bine exemplul urmtor, s relum cteva
notaii matematice cum ar fi: mulimile, secvenele i funciile.
O mulime este o colecie de obiecte, exprimat de obicei prin enumerarea
elementelor incluse ntre acolade. De exemplu:

60
{Anton, Vasile, Ioana, Alice}
este o mulime de nume. Se poate utiliza semnul "e" pentru a indica apartenena
unui element la o mulime.
Astfel Anton e {Anton, Vasile, Ioana, Alice}, dar
Sandu e {Anton, Vasile, Ioana, Alice}.
O secven este o colecie ordonat de obiecte exprimate n mod normal
prin enumerarea elementelor sale, incluse n paranteze drepte. De exemplu:
[ Anton, Vasile, Ioana, Alice ]
este o secven de nume. Captul (capul) secvenei este Anton, iar corpul este
[Vasile, Ioana, Alice]. Dac S este o secven, atunci elementele lui S
marcheaz mulimea de elemente din secvena S. Dac S este o secven a
mulimii, atunci elemente lui S = {Anton, Vasile, Ioana, Alice}. O secven poate
avea elemente care se repet, n timp ce o mulime, nu.
O funcie exprim o relaie ntre dou elemente ale unei mulimi. De
exemplu, director poate asocia nume cu numere de telefon. Dac vom utiliza
Nume pentru a reprezenta mulimea tuturor numelor posibile i Numr pentru a
reprezenta mulimea tuturor numerelor de telefon posibile, atunci putem descrie
director astfel:
director : Nume Numr
Vom spune c director este o funcie de tip Nume Numr . Orice
funcie de acest tip va avea ca argument un membru din Nume i va returna un
membru din mulimea Numr. Totui, directorul nostru particular este parial, n
sensul c este definit numai pentru unele elemente din Nume deoarece nu toate
persoanele au telefon.
Submulimea (subsetul) pe care este definit funcia se numete domeniul
de definiie al funciei. De exemplu, s presupunem c Nume este mulimea
{Anton, Vasile, Ioana, Alice} i Numr este mulimea {421563, 123456}. n acest
caz directorul va fi definit explicit astfel:
director(Anton) = 421563
director(Alice) = 123456

61
Dac Vasile i Ioana nu au telefon atunci director (Vasile) i director (Ioana)
nu sunt definite. Domeniul funciei este mulimea {Anton, Alice}, care este un
subset al mulimii Nume .
Funcia director mai poate fi definit prin explicitarea enumerativ a
Numelui legat de un Numr, astfel:
director = {Anton 421563, Alice 123456}
Anton 421563 i Alice 123456 se numesc "corespondene" (maplets).
Director este o funcie finit deoarece domeniul su este finit, cu alte cuvinte
conine un numr finit de corespondene.
Funciile exprim mai mult dect o relaie. Astfel, dac lum ca model
funcia telefon, mai multe persoane pot avea acelai numr de telefon, dar o
anumit persoan nu poate avea dect un singur numr de telefon.
S considerm acum urmtorul exemplu pentru a descrie specificaiile
formale simple pentru o problem descris informal astfel :
O banc are numai un ghieu unde n mod normal clienii ateapt la
coad. Fiecare client se identific prin numrul de cont i sunt permise numai
tranzacii de adugare sau scoatere din cont. Clientului i se refuz eliberarea
sumei cerute dac contul su este vid. Dac el dorete mai mult dect are n
cont atunci va primi numai suma pe care o mai are n cont. Dup ce s-a efectuat
tranzacia, clientul prsete banca.
Primul lucru care trebuie fcut este s se stabileasc un model matematic
adecvat pentru sistemul propus. Conturile din banc pot fi modelate printr-o
funcie parial care face corespondena ntre numerele de cont i balana bncii:
banc : Cont Balan
Cont este mulimea de numere de conturi posibile, iar Balan este mulimea
tuturor balanelor (disponibilului) bncii. Deci o funcie banc poate arta astfel :
{a1 23, a2 87, a3 45},
care indic de exemplu, c persoana care are numrul de cont a1 are 45000 lei
n cont, .a.m.d. Domeniul funciei banc (scris dom_banc) este o submulime
{a1,a2,a3}, care identific conturile.

62
Coada la ghieul bncii poate fi modelat ca o secven de numere de
cont astfel:
coad : secvCont
n acest fel [a2,a5,a1] reprezint o coad tipic. Vom adopta convenia c
prima persoan din linie reprezint capul cozii. De notat c putem avea elemente
care se repet, adic o persoan poate s apar de mai multe ori n coad. Ne
vom asigura c acest lucru nu este posibil, introducnd restricii suplimentare ori
de cte ori se schimb sau actualizeaz coada.
Avem acum specificarea formal a operaiilor care se vor efectua n
sistemul modelat. Fiecare operaie va fi specificat prin trei componente:
1. Intrrile operaiei;
2. Condiia n care operaia poate fi aplicat (precondiia);
3. Expresia care arat relaia dintre starea sistemului nainte de operaie i
starea sistemului dup operaie (post-condiia).
Vom adopta convenia de a folosi numele obinuit pentru a desemna
starea iniial i &nume, pentru starea final. Exemplu : coad reprezint starea
cozii nainte de sosirea unui client, iar &coad, dup.
S lum acum specificaia care introduce un client n coad:
sosire (client : Cont)
precondiie
client e dom_banc
client e elem_coad
post-condiie
&coad =adaug_ coad [client]
Numele operaiei este sosire. Ea are o intrare numit client, de tip Cont.
Precondiia indic faptul c atunci cnd un client sosete la coad el trebuie s
aib cont n banc, alftel nu va fi acceptat n coada de ateptare. Post-condiia
indic faptul c dup operaie coada se mrete cu o persoan. ( Observaie:
adaug este un operator de concatenare a dou secvene).
De exemplu, s presupunem:
banc = {a1 23, a2 87, a3 45}

63
coad = [a2]
client =[a1]
atunci
client e {a1,a2,a3}
client e {a2}
i
&coad =[a2,a1]
Vom scrie acum o operaie care acord credit unui client care are cont i
se afl n capul cozii (este primul n coad):
credit (suma : Balan )
precondiia
coad = [ ]
post-condiia
&banc =banc {cap coad banc(cap coad) +suma}
&coad =elimin coad
Operaia credit are o intrare numit sum, de tip Balan i o precondiie
care precizeaz c lista (coada) nu trebuie s fie vid, adic trebuie s fie mcar
o persoan la coad.
este un operator de scriere adiional, peste ceea ce era nainte. El
creaz o nou funcie din alte dou date ca operanzi. De exemplu, s
presupunem c:
banc ={a1 23, a2 87, a3 45}
coad =[a2,a1]
suma = 10
Atunci
capul cozii = a2
banc(capul cozii) =87
astfel nct
&banc ={a1 23, a2 87, a3 45} {a2 87+10}
={a1 23, a2 97, a3 45}

64
Corespondena care are a2 n stnga a fost scris peste vechea
coresponden, definind astfel o nou funcie care modeleaz noua stare a
bncii.
Ultima component a post-condiiei arat c dup efectuarea tranzaciei,
clientul din fa prsete coada :
&coad = elimin [a2 a1]
=[a1]
n final, vom defini operaia care permite efectuarea retragerii de bani din
cont :
debit ( suma : Balan )
precondiie
coad = [ ]
banc ( capul cozii ) > suma
post-condiia
&banc =banc {capul cozii banc(capul cozii) - suma}
&coad =elimin coad

Prima component din precondiie arat mai nti c nu trebuie s fie vid
coada i apoi presupune c:
banc ={a1 23, a2 87, a3 45}
coad =[a2,a1]
suma = 10
Capul cozii este a2 iar banc (capul cozii) =87
A doua component a precondiiei specific faptul c balana relativ la
contul clientului trebuie s fie mai mare sau egal cu suma pe care acesta
intenioneaz s-o scoat din banc.
n contextul validrii specificaiilor (ceea ce nseamn de fapt nglobarea
cerinelor), vom specifica acum un invariant .
Un invariant este o aseriune despre componentele modelului matematic,
pe care se vor baza apoi specificaiile noastre. Dac invariantul se afl nainte de

65
operaiile pe care le-am specificat, atunci el trebuie s apar i dup ce operaia
este complet.
El exprim ceva ce este ntotdeauna adevrat. De exemplu, exist un
invariant pentru banc:
( a e dom_banc ) banc(a) > 0
elem_coad _ dom_banc
# coad s 10

Acest invariant stipuleaz c :
1. Oricare ar fi a din domeniul bncii, valoarea lui banc(a) este mai mare
sau egal cu zero. Aceasta nseamn c toi clienii bncii au credit.
2. Mulimea de persoane aflat n coad este o submulime a domeniului
bncii. Aceasta nseamn c fiecare persoan din coad are un cont n banc.
3. Numrul de elemente din coad este mai mic sau egal cu 10,
considernd c nu vor fi niciodat mai mult de 10 persoane la coad.
Intuitiv, se poate vedea c debitul i creditul conserv acest invariant, dar
sosire nu, de aceea nu a existat nici o restricie cu privire la lungimea cozii.
Totui sosire va conserva invariantul dac vom aduga un extra predicat :
# coad < 10
n precondiia sa.
Invarianii furnizeaz un instrument de valoare pentru asigurarea
consistenei peste operaiile care se fac n cadrul specificaiilor.
Concluzii:
Rezumnd, un mediu ideal de inginerie software (cu sublinierea cuvntului
inginerie), ca scenariu tipic pentru dezvoltarea unui program, trebuie s arate
astfel:
- S existe o specificare formal, derivat dintr-o descriere informal, care
s ajute mai bine la nelegerea problemei.
- S existe o dovad care s demonstreze c specificarea real se poate
realiza printr-un algoritm.

66
- S existe un prototip (chiar dac este ineficient) care s poat fi
prezentat celui care trebuie s valideze proiectul.
- S se scrie programul sau programele derivate din specificaii.
- S existe o dovad c programul este corect prin prisma specificaiilor
sale.
Dezvoltarea unor instrumente integrate de software care s susin
fiecare dintre aceste faze este considerat vital pentru acceptarea unui astfel de
scenariu.

2.6. Exerciii
1) Care sunt informaiile necesare care trebuie colectate i nregistrate ca
specificaii software?
2) Explicai dificultile limbajului natural pentru descrierea specificaiilor
software?
3) Luai ca exemplu un sistem informatic mic (care dorii dv.). Identificai
componentele funcionale i de date din sistem. Identificai problemele legate de
specificaiile software cum ar fi: ambiguitate, inconsisten i informaii vagi.
4) Exist solicitarea pentru un sistem informatic care s gestioneze
informaiile despre carile existente ntr-o mic bibliotec de departament.
s1 - sistemul trebuie s funcioneze pe un calculator standard PC;
s2 - pentru fiecare carte informaiile standard sunt:
- titlul
- autorul
- codul de clasificare (cota crii)
- anul apariiei
- dac este mprumutat
- data solicitrii
s3 - calculatorul trebuie s memoreze informaiile pentru 1000 de cri
s4 - sistemul trebuie s rspund la urmtoarele comenzi de la tastatur:
(a) solicitarea de mprumut a unei cri

67
(b) napoierea unei cri mprumutate
(c) crearea unei nregistrri pentru o carte nou achiziionat;
s5 - comenzile vor fi accesibile printr-o selecie cu ajutorul cursorului
dintr-un meniu;
s6 - calculatorul trebuie s rspund n maximum 30 de secunde de la
formularea cererii;
s7 - calculatorul trebuie s fie capabil s tipreasc ntregul catalog al
crilor, cu un cap de tabel corespunzator. Acest lucru trebuie s se fac n
paralel cu alt comand primit;
s8 - msuri de securitate: sistemul va iniializa informaiile din bibliotec
numai dac el conine zero cri;
s9 - cnd o carte este tears sistemul va afia informaiile despre ea;
s10 - sistemul trebuie livrat la data D, trebuie s nu depaeasc costul C,
s fie n ntregime documentat i uor de ntreinut.
5. " Scriei un program de sortare ". Este aceast modalitate, adecvat ca
specificaie ?
6. Un aspect necesar al specificaiilor este discuia cu potenialii utilizatori.
Cei mai muli dintre ei nu neleg notaiile matematice. Este acesta un
dezavantaj? Ce aduc n plus notaiile formale pentru a face aceast munc mai
productiv?
7. Enumerai cteva cerine non-funcionale din implementarea
programului de mprumut la banc.
8. Scriei specificaiile pentru deschiderea i nchiderea unui cont bancar.
9. Modificai invariantul pentru banc astfel nct s ilustreze faptul c o
persoan nu poate s apar de mai multe ori n coad.
10. Pentru cine sunt mai importante atributele unei specificaii, pentru
programator sau pentru cel care implementeaz programul ?


68


69

3

Paradigmele de dezvoltare a sistemelor de
programe
3.1. Etapele dezvoltrii programelor
Cnd pornim la dezvoltarea unui program avem nevoie de:
o nelegere clar a ceea ce se cere;
o un set de metode i instrumente de lucru;
o un plan de aciune.
Planul de aciune se numete metodologie de dezvoltare. Dezvoltarea
unui anumit program const ntr-un set de pai ce se fac pentru a-l realiza.
Lund n considerare tipul pailor ce se efectueaz, se creeaz un model de
lucru, ce poate fi aplicat unei serii mai largi de proiecte. Acesta este motivul
pentru care planul de aciune este numit model: el poate fi privit ca un ablon al
dezvoltrii de programe. n timpul dezvoltrii programelor s-a constatat c exist
anumite tipuri de activiti care trebuie fcute la un moment dat:
o Analiza cerinelor: Se stabilete ce anume vrea clientul ca programul s fac.
Scopul este nregistrarea cerinelor ntr-o manier ct mai clar i mai fidel.
Claritatea se refer la lipsa ambiguitii iar fidelitatea la nregistrarea ct mai
exact (posibil cuvnt cu cuvnt);
o Proiectarea arhitectural: Din motive de complexitate, programele mari nu pot
fi concepute i implementate ca o singur bucat. Programul va trebui
construit aadar din module sau componente. Proiectarea arhitectural
mparte sistemul ntr-un numr de module mai mici i mai simple, care pot fi
abordate individual;

70
o Proiectarea detaliat: Se realizeaz proiectarea fiecrui modul al aplicaiei, n
cele mai mici detalii;
o Scrierea codului: Proiectul detaliat este transpus ntr-un limbaj de
programare. De obicei, aceasta se realizeaz modular, pe structura rezultat
la proiectarea arhitectural;
o Integrarea componentelor: Modulele programului sunt combinate n produsul
final. Rezultatul este sistemul complet. n modelul numit big-bang
componentele sunt dezvoltate i testate individual, dup care sunt integrate n
sistemul final. Avnd n vedere c funcionarea corect a componentelor
individuale a fost testat, integrarea ar trebui s fie o formalitate. Din pcate,
componentele nu pot fi testate exhaustiv, iar cnd acestea lucreaz mpreun
pot s apar situaii pe care o anumit component nu le-a ntlnit n procesul
de testare sau conflicte ntre anumite componente (de exemplu, conflicte de
partajare a resurselor). S-a constatat c atunci cnd se aplic acest model,
timpul de testare explodeaz, proiectul devenind greu de controlat; aceasta
justific denumirea de big-bang. Modelul incremental propune crearea unui
nucleu al aplicaiei i integrarea a cte o component la un moment dat,
urmat imediat de testarea sistemului obinut. Astfel, se poate determina mai
uor unde anume apare o problema n sistem. Acest tip de integrare ofer de
obicei rezultate mai bune dect modelul big-bang;
o Acceptarea: n procesul de acceptare ne asigurm c programul ndeplinete
cerinele utilizatorului. ntrebarea la care rspundem este: construim produsul
corect? Un exemplu de acceptare este testul de acceptare, n care produsul
este prezentat clientului. Clientul spune dac este mulumit cu produsul sau
dac mai trebuie efectuate modificri;
o Verificarea: n procesul de verificare ne asigurm c programul este stabil i
c funcioneaz corect din punctul de vedere al dezvoltatorilor. ntrebarea la
care rspundem este: construim corect produsul?
o ntreinerea: Dup ce programul este livrat clientului, mai devreme sau mai
trziu sunt descoperite defecte sau erori ce trebuie reparate. De asemenea,

71
pot aprea schimbri n specificaiile utilizatorilor, care vor diverse
mbuntiri. ntreinerea const n gestionarea acestor probleme.
Se poate constata uor c aceste activiti sunt n strns legtur cu cele
patru faze ale ingineriei programrii: analiza, proiectarea, implementarea i
testarea.

3.2. Paradigmele de dezvoltare software
Paradigmele de dezvoltare a sistemelor de programe se constituie din dou
categorii de metodologii i anume:
- 3.2.1. Metodologii generice
Metodologia secvenial
Metodologia ciclic
Metodologia hibrid ecluz
- 3.2.2. Metodologii concrete.
Metodologia cascad
Metodologia spiral
Metodologia spiral WinWin
Prototipizarea
Metodologia Booch
Metode formale
Metoda V
Programarea extrem
Metodologia Open Source
Reverse Engineering
Metodologia de dezvoltare Offshore
Metodologii orientate obiect

3.2.1. Metodologii generice
n acest paragraf, vor fi prezentate trei categorii importante de metodologii:
secvenial, ciclic i hibrid. n metodologia secvenial (cascad), cele patru
faze urmeaz una alteia ntr-o modalitate serial. n metodologia ciclic (spiral),

72
fazele sunt dispuse n cicluri care i genereaz incremental contribuiile la
sistemul final. Metodologia hibrid (ecluz) combin progresul constant al
metodologiei secveniale cu incrementele iterative ale metodologiei ciclice.

3.2.1.1. Metodologia secvenial
n metodologia secvenial (fig.3.1), cunoscut i sub numele de
metodologia cascad, are loc mai nti faza de analiz, apoi cea de proiectare,
urmat de cea de implementare, iar n final se realizeaz testarea. Echipele care
se ocup de fiecare faz pot fi diferite, iar la fiecare tranziie de faz poate fi
necesar o decizie managerial.

Fig. 3.1. Metodologia secvenial
Avantaje
Metodologia secvenial este potrivit cnd complexitatea sistemului este
mic iar cerinele sunt statice. Ea spune c mai nti trebuie s ne gndim ce
trebuie construit, apoi s stabilim un plan de lucru i apoi s realizm proiectul,
innd cont de standardele de calitate. De asemenea, se aliniaz metodelor de
inginerie hardware. Foreaz meninerea unei discipline de lucru care evit
presiunea scrierii codului nainte de a cunoate precis ce produs va trebui de fapt
construit.
De multe ori, echipa de implementare se afl n situaia de a programa
nainte de finalizarea analizei, ceea ce conduce inevitabil la descoperirea unor
pri de cod inutile sau care contribuie foarte puin (poate chiar i ineficient) la
funcionalitatea produsului final. Totui, acest cod devine un balast foarte
costisitor: dificil de abandonat i greu de schimbat. Aceast metodologie foreaz
analiza i planificarea naintea implementrii, o practic foarte nimerit n multe
situaii.

73
Un mare numr de sisteme software din trecut au fost construite cu o
metodologie secvenial. Multe companii i datoreaz succesul acestui mod de
realizare a programelor. Trebuie spus totui i c presiunea de schimbare din
partea surselor externe era destul de limitat la momentul respectiv.

Dezavantaje
Unul din principalele dezavantaje ale metodologiei secveniale este faptul c
acord o foarte mare importan fazei de analiz. Membrii echipei de analiz ar
trebui s fie probabil clarvztori ca s poat defini toate detaliile aplicaiei nc
de la nceput. Greelile nu sunt permise, deoarece nu exist un proces de
corectare a erorilor dup lansarea cerinelor finale. Nu exist nici feedback de la
echipa de implementare n ceea ce privete complexitatea codului corespunztor
unei anumite cerine. O cerin simplu de formulat poate crete considerabil
complexitatea implementrii. n unele cazuri, este posibil s fie chiar imposibil de
implementat cu tehnologia actual. Dac echipa de analiz ar ti c o cerin nu
poate fi implementat, ei ar putea-o schimba cu o cerin diferit care s
satisfac cele mai multe dintre necesiti i care s fie mai uor de efectuat.
Comunicarea dintre echipe este o problem: cele patru echipe pot fi
diferite iar comunicarea dintre ele este limitat. Modul principal de comunicare
sunt documentele realizate de o echip i trimise urmtoarei echipe cu foarte
puin feedback. Echipa de analiz nu poate avea toate informaiile privitoare la
calitate, performan i motivare.
ntr-o industrie n continu micare, metodologia secvenial poate produce
sisteme care, la vremea lansrii, s fie deja nvechite. Accentul att de mare pus
pe planificare nu poate determina rspunsuri suficient de rapide la schimbare. Ce
se ntmpl dac clientul i schimb cerinele dup terminarea fazei de analiz?
Acest lucru se ntmpl ns frecvent; dup ce clientul vede prototipul produsului,
el i poate schimba unele cerine.


74
3.2.1.2. Metodologia ciclic
Metodologia ciclic (fig.3.2), cunoscut i sub numele de metodologia
spiral, ncearc s rezolve unele din problemele metodologiei secveniale. i
aceast metodologie are patru faze, ns n fiecare faz se consum un timp mai
scurt, dup care urmeaz mai multe iteraii prin toate fazele.
Ideea este de fapt urmtoarea: gndete un pic, planific un pic,
implementeaz un pic, testeaz un pic i apoi ia-o de la capt. n mod ideal,
fiecrei faze trebuie s i se acorde atenie i importan egale.
Documentele de la fiecare faz i schimb treptat structura i coninutul, la
fiecare ciclu sau iteraie. Pe msur ce procesul nainteaz, sunt generate din ce
n ce mai multe detalii. n final, dup cteva cicluri, sistemul este complet i gata
de lansare. Procesul poate ns continua pentru lansarea mai multor versiuni ale
produsului.

Fig.3.2. Metodologia ciclic
Avantaje
Metodologia ciclic se bazeaz pe ideea perfecionrii incrementale ale
metodologiei secveniale. Permite feedback-ul de la fiecare echip n ceea ce
privete complexitatea cerinelor.
Exist etape n care pot fi corectate eventualele greeli privind cerinele.
Clientul poate arunca o privire asupra rezultatului i poate oferi informaii
importante mai ales n faza dinaintea lansrii produsului. Echipa de
implementare poate trimite echipei de analiz informaii privind performanele i
viabilitatea sistemului. Acesta se poate adapta mai bine progresului tehnologic:
pe msur ce apar noi soluii, ele pot fi ncorporate n arhitectura produsului.
Dezavantaje
Metodologia ciclic nu are nici o modalitate de supraveghere care s
controleze oscilaiile de la un ciclu la altul. n aceast situaie, fiecare ciclu

75
produce un efort mai mare de munc pentru ciclul urmtor, ceea ce ncarc
orarul planificat i poate duce la eliminarea unor funcii sau la o calitate sczut.
Lungimea sau numrul de cicluri poate crete foarte mult. De vreme ce nu exist
constrngeri asupra echipei de analiz s fac lucrurile cum trebuie de prima
dat, acest fapt duce la scderea responsabilitii. Echipa de implementare
poate primi sarcini la care ulterior se va renuna.
Echipa de proiectare nu are o viziune global asupra produsului i deci nu
poate realiza o arhitectur complet. Nu exist termene limit precise. Ciclurile
continu fr o condiie clar de terminare. Echipa de implementare poate fi
pus n situaia nedorit n care arhitectura i cerinele sistemului sunt n
permanen schimbare.

3.2.1.3. Metodologia hibrid ecluz
Metodologia ecluz (engl. watersluice), propus de Ronald LeRoi Burback
(1998), separ aspectele cele mai importante ale procesului de dezvoltare a unui
produs software de detaliile mai puin semnificative i se concentreaz pe
rezolvarea primelor. Pe msur ce procesul continu, detaliile din ce n ce mai
fine sunt rafinate, pn cnd produsul poate fi lansat. Aceast metodologie
hibrid (fig.3.3) preia natura iterativ a metodologiei spiral, la care adaug
progresul sigur al metodologiei cascad.
La nceput, ntr-un proces iterativ, fazele de analiz, proiectare,
implementare i testare sunt mprite n mai multe sarcini poteniale, fiecruia
atribuindu-i-se o prioritate care reflect beneficiul ndeplinirii sarcinii respective
pentru scopul final. La fiecare moment se execut sarcina cu prioritate maxim.
n funcie de dimensiunea echipelor, mai multe sarcini pot fi realizate n paralel.
Sarcinile rmase, de prioritate minim, sunt pstrate pentru examinare ulterioar.
Descompunerea problemei este foarte important. Cu ct descompunerea i
stabilirea prioritilor sunt mai bune, cu att mai eficient este metodologia.
Pe msur ce sarcinile stabilite sunt ndeplinite, noi sarcini pot fi
descoperite. Acestea sunt adugate sarcinilor rmase nesoluionate i se
reatribuie prioritile. Procesul continu pn cnd produsul este gata de lansare.

76
Prioritile se stabilesc pe baza unei funcii de prioritate, care depinde att
de domeniul problemei i ct i de normele firmei. Ea trebuie s realizeze un
compromis ntre cantitate i calitate, ntre funcionalitate i constrngerile privind
resursele, ntre ateptri i realitate. Toate funciile de prioritate ar trebuie s aib
ca prim scop lansarea produsului.
Pe lng rolul evident de a stabili prioritile i deci ordinea de execuie a
sarcinilor de lucru, funcia mai trebuie s gestioneze sarcinile conflictuale i
nemonotone. Ea trebuie s mpart aceste sarcini n grupuri consistente, s
reglementeze selecia grupurilor consistente i apoi s dirijeze selecia sarcinilor
din cadrul grupurilor. Pe msur ce sistemul crete, funcia de prioritate trebuie
s aleag sarcini consistente cu partea deja constituit din sistem. O sarcin
nemonoton vine n contradicie cu sistemul realizat deja i trebuie eliminat
dac nu este absolut necesar pentru succesul sistemului.

Fig. 3.3. Metodologia hibrid ecluz

Odat ce o component este terminat i acceptat de echip, schimbrile
asupra sa sunt ngheate. Componenta va fi schimbat numai dac modificrile
sunt absolut necesare iar echipa este dispus s ntrzie lucrul la restul

77
sistemului pentru a le efectua. Schimbrile trebuie s fie puine la numr, bine
justificate i documentate.
Etapele principale ale metodei sunt: schia de principiu, prototipul, versiunile
alfa/beta i produsul final. n prima etap, schia de principiu, echipele lucreaz
simultan la toate fazele problemei. Echipa de analiz sugereaz cerinele.
Echipa de proiectare le discut i trimite sarcinile critice de implementare echipei
de implementare. Echipa de testare pregtete i dezvolt mediul de test n
funcie de cerine. Echipa de implementare se concentreaz asupra sarcinilor
critice, care n general sunt cele mai dificile. Aceast abordare contrasteaz cu
practica curent de realizare mai nti a sarcinilor simple. Dac nu sunt
respectate cu strictee etapele sistemele pot s eueaze. Odat ce
componentele critice au fost realizate, sistemul este gata de a face tranziia ctre
stadiul de prototip.
Unul din scopurile aceste etape este de a se convinge echipele c o soluie
poate fi gsit i pus n practic.
n cea de a doua etap, de prototip, cerinele i documentul cerinelor sunt
ngheate. Schimbrile n cerine sunt nc permise, ns ar trebuie s fie foarte
rare i numai dac sunt absolut necesare, deoarece modificrile cerinelor n
acest stadiu al proiectului sunt foarte costisitoare. Este posibil totui ajustarea
arhitecturii, pe baza noilor opiuni datorate tehnologiei. Dup ce sarcinile critice
au fost terminate, echipa de implementare se poate concentra pe extinderea
acestora, pentru definirea ct mai multor aspecte ale aplicaiei. Unul din scopurile
acestei etape este de a convinge persoanele din afara echipelor c o soluie este
posibil.
Acum produsul este gata pentru lansarea versiunilor alfa i beta. Arhitectura
este ngheat, iar accentul cade pe implementare i asigurarea calitii. Prima
versiune lansat se numete n general alfa. Produsul este nc imatur; numai
sarcinile critice au fost implementate la calitate ridicat. Numai un numr mic de
clieni sunt n general dispui s accepte o versiune alfa i s-i asume riscurile
asociate. O a doua lansare reprezint versiunea beta. Rolul su este de a

78
convinge clienii c aplicaia va fi un produs adevrat i de aceea se adreseaz
unui numr mai mare de clieni.
Cnd o parte suficient de mare din sistem a fost construit, poate fi lansat n
sfrit produsul. n aceast etap, implementarea este ngheat i accentul cade
pe asigurarea calitii. Scopul este realizarea unui produs competitiv. n produsul
final nu se accept erori critice.
Avantaje
Metodologia ecluz recunoate faptul c oamenii fac greeli i c nici o
decizie nu trebuie s fie absolut. Echipele nu sunt blocate ntr-o serie de cerine
sau ntr-o arhitectur imobil care se pot dovedi mai trziu inadecvate sau chiar
greite. Totui, pentru respectarea termenelor limit, metodologia impune date
de ngheare a unor faze. Exist timp suficient pentru corectarea greelilor
decizionale pentru atingerea unui nivel suficient de ridicat de ncredere. Se pune
mare accent pe comunicarea ntre echipe, ceea ce reduce cantitatea de cod
inutil la care ar trebui s se renune n mod normal. Metodologia ncearc s
mute toate erorile la nceputul procesului, unde corectarea, sau chiar
renceperea de la zero a lucrului, nu sunt foarte costisitoare.
Dezavantaje
Metodologia presupune asumarea unor responsabiliti privind delimitarea
etapelor i nghearea succesiv a fazelor de dezvoltare. Ea presupune crearea
unui mediu de lucru n care acceptarea responsabilitii pentru o decizie care se
dovedete mai trziu greit s nu se repercuteze n mod negativ asupra
individului. Se dorete de asemenea schimbarea atitudinii echipelor fa de
testare, care are loc nc de la nceput, i fa de comunicarea continu, care
poate fi dificil, ntruct cele patru faze reprezint perspective diferite asupra
realizrii produsului.

3.2.2. Metodologii concrete
3.2.2.1. Metodologia cascad
Metodologia cascad, propus de Barry Boehm, este una din cele mai
cunoscute exemple de metodologie de ingineria programrii. Exist numeroase

79
variante ale acestui proces. ntr-o variant detaliat, metodologia cascad
cuprinde etapele prezentate n fig.3.4.
Dup fiecare etap exist un pas de acceptare. Procesul curge de la
etap la etap, ca apa ntr-o cascad. n descrierea originar a lui Boehm, exist
o ntoarcere, un pas napoi interactiv ntre fiecare dou etape. Astfel, metoda
cascad este de fapt o combinaie de metodologie secvenial cu elemente
ciclice. Totui, n practica inginereasc, termenul cascad este utilizat ca un
nume generic pentru orice metodologie secvenial.
Acesta este modelul dup care de obicei sistemele sunt dezvoltate n
practic. De asemenea, reordonarea fazelor s-a dovedit a fi sub-optimal. Exist
o mare atracie pentru acest model datorit experienei, tradiiei n aplicarea sa i
succesului pe care l-a implicat. O sarcin complex este mprit n mai muli
pai mici, ce sunt mai uor de administrat. Fiecare pas are ca rezultat un produs
bine definit (documente de specificaie, model, etc.)
Modelul cascad cu feedback propune remedierea problemelor descoperite
n pasul precedent. Problemele la pasul i care sunt descoperite la pasul i +3
rmn neremediabile.
Un model realist ar trebui s ofere posibilitatea ca de la un anumit nivel s
se poat reveni la oricare dintre nivelele anterioare.
Dezavantajul principal al modelului n cascad apare deoarece clientul
obine o viziune practic asupra produsului doar n momentul terminrii
procesului de dezvoltare. De asemenea, modelul nu are suficient putere
descriptiv, n sensul c nu integreaz activiti ca managementul resurselor sau
managementul configuraiei. Aceasta face dificil coordonarea proiectului.
Dup cum am menionat la prezentarea metodologiei generice secveniale,
i modelul cascad impune nghearea specificaiilor foarte devreme n procesul
de dezvoltare pentru a evita iteraiile frecvente (rentoarcerile n fazele anterioare
atunci cnd n faza curent s-au detectat erori: n timpul analizei se descoper
erori de specificaii, n timpul implementrii se descoper erori de
specificaii/proiectare etc., astfel nct procesul poate implica multiple secvene
de iteraii ale activitilor de dezvoltare).

80
nghearea prematur a cerinelor conduce la obinerea unui produs prost
structurat i care nu execut ceea ce dorete utilizatorul. Conduce de asemenea
la obinerea unei documentaii neadecvate deoarece schimbrile intervenite n
iteraiile frecvente nu sunt actualizate n toate documentele produse.

Fig. 3.4. Metodologia cascad

81
3.2.2.2. Metodologia spiral
Metodologia spiral, propus tot de Boehm, este un alt exemplu bine
cunoscut de metodologie a ingineriei programrii. Acest model ncearc s
rezolve problemele modelului n cascad, pstrnd avantajele acestuia:
planificare, faze bine definite, produse intermediare. El definete urmtorii pai n
dezvoltarea unui produs:
o studiul de fezabilitate;
o analiza cerinelor;
o proiectarea arhitecturii software;
o implementarea.
Modelul n spiral (fig. 3.5.) recunoate c problema principal a dezvoltrii
programelor este riscul. Riscul nu mai este eliminat prin aseriuni de genul: n
urma proiectrii am obinut un model corect al sistemului, ca n modelul
cascad. Aici riscul este acceptat, evaluat i se iau msuri pentru contracararea
efectelor sale negative.
.

Fig. 3.5. Modelul spiral

Exemple de riscuri:
n timpul unui proces ndelungat de dezvoltare, cerinele noi ale clientului
sunt ignorate;

82
clientul schimb cerinele;
o firm concurent lanseaz un program rival pe pia;
un dezvoltator/arhitect prsete echipa de dezvoltare;
o echip nu respect un termen de livrare pentru o anumit component
Metodologia spiral cuprinde urmtoarele etape, grupate pe patru cicluri
(Tabelul 3.1)
n modelul spiral se consider c fiecare pas din dezvoltare conine o serie de
activiti comune:
pregtirea: se identific obiectivele, alternativele, constrngerile;
gestionarea riscului: analiza i rezolvarea situaiilor de risc;
activiti de dezvoltare specifice pasului curent (de exemplu analiza
specificaiilor sau scrierea de cod);
planificarea urmtorului stadiu: termenele limit, resurse umane,
revizuirea strii proiectului.
n modelul spiral se consider c fiecare pas din dezvoltare conine o serie
de activiti comune:
pregtirea: se identific obiectivele, alternativele, constrngerile;
gestionarea riscului: analiza i rezolvarea situaiilor de risc;
activiti de dezvoltare specifice pasului curent (de exemplu analiza
specificaiilor sau scrierea de cod);
planificarea urmtorului stadiu: termenele limit, resurse umane,
revizuirea strii proiectului.
Procesul ncepe n centrul spiralei. Fiecare ciclu terminat reprezint o
etap. Pe msur ce spirala este parcurs, produsul se maturizeaz. Cu fiecare
ciclu, sistemul se apropie de soluia final.
Dei este considerat ca un exemplu generic pentru metodologia ciclic,
metoda are i elemente secveniale, puse n eviden de evoluia constant de la
o etap la alta.


83
Tabelul 3.1. Ciclurile metodologiei n spiral
Ciclul 1 Analiza preliminar:
1. Obiective, alternative, constrngeri
2. Analiza riscului i prototipul
3. Conceperea operaiilor
4. Cerinele i planul ciclului de via
Ciclul 2 Analiza final:
7. Simulare, modele, benchmark-uri
8. Cerine software i acceptare
9. Plan de dezvoltare
Ciclul 3 Proiectarea:
13. Proiectarea produsului software, acceptare i verificare
14. Integrare i plan de test
16. Analiza riscului i prototipul operaional
Ciclul 4 Implementarea i testarea:
18. Proiectare detaliat
19. Cod
20. Integrarea unitilor i testarea acceptrii
21. Lansarea produsului

3.2.2.4. Metodologia spiral WinWin
Aceast metodologie extinde spirala Boehm prin adugarea unui pas de
stabilire a prioritii la nceputul fiecrui ciclu din spiral i prin introducerea unor
scopuri intermediare, numite puncte ancor. Modelul spiral WinWin identific un

84
punct de decizie. Pentru fiecare punct de decizie, se stabilesc obiectivele,
constrngerile i alternativele.
Punctele ancor stabilesc trei scopuri intermediare. Primul punct ancor,
numit obiectivul ciclului de via, precizeaz cazurile sigure de funcionare pentru
ntregul sistem, artnd c exist cel puin o arhitectur fezabil (adic posibil
din punct de vedere practic) care satisface scopurile sistemului. Primul scop
intermediar este stabilit cnd sunt terminate obiectivele de nivel nalt ale
sistemului, arhitectura, modelul ciclului de via i prototipul sistemului. Aceast
prim ancor spune de ce, ce, cnd, cine, unde, cum i estimeaz costul
produsului. Dup executarea acestor operaii, este disponibil analiza de nivel
nalt a sistemului.
Al doilea punct ancor definete arhitectura ciclului de via, iar al treilea
capacitatea operaional iniial, incluznd mediul software necesar, hardware-
ul, documentaia pentru client i instruirea acestuia.
Aceste puncte ancor corespund etapelor majore din ciclul de via al unui
produs: dezvoltarea iniial, lansarea, funcionarea, ntreinerea i ieirea din
funciune.

3.2.2.5. Prototipizarea
O problem general care apare la dezvoltarea unui program este s ne
asigurm c utilizatorul obine exact ceea ce vrea. Prototipizarea vine n sprijinul
rezolvrii acestei probleme. nc din primele faze ale dezvoltrii, clientului i se
prezint o versiune funcional a sistemului.
Aceast versiune nu reprezint ntregul sistem, ns este o parte a
sistemului care cel puin funcioneaz. Prototipul ajut clientul n a-i defini mai
bine cerinele i prioritile. Prin intermediul unui prototip, el poate nelege ce
este posibil i ce nu din punct de vedere tehnologic. Prototipul este de obicei
produs ct mai repede; pe cale de consecin, stilul de programare este de
obicei (cel puin) neglijent. ns scopul principal al prototipului este de a ajuta n
fazele de analiz i proiectare i nu folosirea unui stil elegant.
Se disting dou feluri de prototipuri:

85
o jetabil sau de aruncat (throw-away);
o evoluionar sau lent i recuperabil.
n cazul realizrii unui prototip jetabil, scopul este exclusiv obinerea unei
specificaii. De aceea nu se acord nici o importan stilului de programare i de
lucru, punndu-se accent pe viteza de dezvoltare. Odat stabilite cerinele, codul
prototipului este aruncat, sistemul final fiind rescris de la nceput, chiar n alt
limbaj de programare.
n cazul realizrii unui prototip evoluionar, scopul este de a crea un schelet
al aplicaiei care s poat implementa n prim faz o parte a cerinelor
sistemului. Pe msur ce aplicaia este dezvoltat, noi caracteristici sunt
adugate scheletului existent. n contrast cu prototipul de aruncat, aici se
investete un efort considerabil ntr-un design modular i extensibil, precum i n
adoptarea unui stil elegant de programare.
Aceast metod are urmtoarele avantaje:
o permite dezvoltatorilor s elimine lipsa de claritate a specificaiilor;
o ofer utilizatorilor ansa de a schimba specificaiile ntr-un mod ce
nu afecteaz drastic durata de dezvoltare;
o ntreinerea este redus, deoarece acceptarea se face pe parcursul
dezvoltrii;
o se poate facilita instruirea utilizatorilor finali nainte de terminarea
produsului.
Dintre dezavantajele principale ale prototipizrii amintim:
o deoarece prototipul ruleaz ntr-un mediu artificial, anumite
dezavantaje ale produsului final pot fi scpate din vedere de clieni;
o clientul nu nelege de ce produsul necesit timp suplimentar pentru
dezvoltare, avnd n vedere c prototipul a fost realizat att de
repede;
o deoarece au n fiecare moment ansa de a face acest lucru, clienii
schimb foarte des specificaiile;
o poate fi nepopular printre dezvoltatori, deoarece implic, n cazul
prototipului jetabil, renunarea la propria munc.

86
Acest model, cunoscut de asemenea sub numele de prototip rapid, ncearc
s rezolve neajunsul modelului n cascad legat de faptul c pn la construirea
produsului final nu se tie cu exactitate ce a dorit ntr-adevr utilizatorul.
Dezvoltarea evolutiv este similar abordrii exploratorii, dar scopul acestei
dezvoltri este de a stabili cerinele utilizatorului, mai ales atunci cnd este dificil
de fcut acest lucru, sau cnd documentele de specificaii existente sunt ambigui
sau incomplete. Aceast tehnic este n esen o metod de analiz a
specificaiilor.

Fig.3.6. Modelul prototipului rapid

Plecnd de la stabilirea n mare a specificaiilor, inginerul software
construiete un prototip rapid i las clientul s-l experimenteze. n momentul n
care clientul este satisfcut, proiectantul poate trece la elaborarea documentului
cu specificaiile produsului, care este apoi folosit n construcia software-ului
utiliznd, de exemplu, un model n cascad (fig.3.7).
Stabilirea n principiu
a cerinelor
Construire
prototip
Evaluare
Specificarea
sistemului
Utilizarea unui model
de proiectare i
implementare
NU
DA
Ok?

87
Cnd se construiete un prototip, proiectarea i implementarea se
realizeaz n faze diferite de timp.
Cele dou abordri pot fi combinate n mod util aa cum se arat n fig. 3.7.
n acest caz, stadiul de analiz a cerinelor din cadrul modelul n cascad a fost
nlocuit de stadiul necesar al prototipizrii iar bucla de feedback a disprut.
Punctul forte al acestui model combinat este acela c, n acest mod
dezvoltarea software-ului devine, n mod esenial, un proces complet liniar.
Datorit completitudinii specificaiilor utilizatorului, buclele de reacie (feedback)
din stadiile precedente par a fi, din ce n ce mai puin, necesare.

Fig.3.7. Modelul integrat cascad i prototipizare

Stabilirea n principiu
a cerinelor
Construire
prototip
Evaluare
Specificare
cerine utilizator
Proiectare
Implementare
Mentenan
DA
NU
Ok?

88
3.2.2.6. Metodologia Booch
Aceast metodologie asigur o dezvoltare orientat obiect n fazele de
analiz i proiectare. Faza de analiz este mprit n mai muli pai. Primul pas
este stabilirea cerinelor din perspectiva clientului, genernd o descriere de nivel
nalt a funcionrii i structurii sistemului. Al doilea pas este analiza domeniului,
realizat prin definirea claselor: atributele, metodele, motenirea. Faza de
analiz este terminat cu un pas de acceptare. Aceast faz itereaz cei trei pai
pn cnd soluia este consistent.
i faza de proiectare este iterativ. Design-ul logic este transformat n
design fizic, cu detalii privind firele de execuie, procesele, performanele, tipurile
de date, structurile de date etc. Se creeaz un prototip i apoi se testeaz. Faza
itereaz design-ul logic, cel fizic, prototipurile i testarea.
Metodologia Booch este secvenial n sensul c mai nti este terminat
analiza i apoi proiectarea. Ea este ciclic datorit iteraiilor din fiecare faz.
Metoda se concentreaz n special asupra acestor dou faze, de analiz i
proiectare, fr s insiste foarte mult asupra implementrii i testrii.

3.2.2.7. Metode formale
n acest model de dezvoltare, sunt folosite formalismul i rigoarea
matematicii. n prima faz este construit o specificaie n limbaj matematic. Apoi,
aceast specificaie este transformat n programe, de obicei ntr-un proces
incremental.
Avantaje:
o precizia obinut prin specificarea formal;
o pstrarea corectitudinii n timpul transformrii specificaiei n cod
executabil;
o ofer posibilitatea generrii automate de cod;
o sunt potrivite pentru sisteme cu cerine critice.
Dezavantaje:
o specificarea formal este de obicei o barier de comunicare ntre
client i analist;

89
o necesit personal foarte calificat (deci mai scump);
o folosirea impecabil a tehnicilor specificrii formale nu implic
neaprat obinerea de programe sigure, deoarece anumite aspecte
critice pot fi omise din specificaiile iniiale.

3.2.2.7. Modelul V
n limba german se numete V-Modell i a fost dezvoltat pentru
reglementarea dezvoltrii de software n administraia federal german. Acest
model evideniaz testarea pe tot parcursul ciclului de dezvoltare (Fig. 3.7.).
Trecerea la faza urmtoare a dezvoltrii software-ului se face numai dup
ce toate produsele din faza curent au trecut testele de verificare i validare
Procesul de verificare i validare are scopul detectrii ct mai multor erori n
ciclul de dezvoltare

Fig. 3.7. Modelul V

3.2.2.8. Programarea Extrema
Programarea Extrema (Kent Beck, 1996) este o metodologie care propune
rezolvri originale pentru problemele care apar n dezvoltarea de programe.
Este o metod de programare agil, potrivit dezvoltrii rapide de aplicaii

90
Fiind o tehnologie nou (i extrem) are att adepi ct i critici. XP
consider c dezvoltarea programelor nu nseamn ierarhii, responsabiliti i
termene limit, aa cum se afl acestea pe masa administratorului, ci nseamn
colaborarea oamenilor din care este format echipa. Acetia sunt ncurajai s i
afirme personalitatea, s ofere i s primeasc cunotine i s devin
programatori strlucii.
De asemenea, XP consider c dezvoltarea de programe nseamn n
primul rnd scrierea de programe. Aceast sintagm banal se pare c este
uitat de multe companii care se ascund n spatele proceselor de dezvoltare
stufoase, a edinelor i a rapoartelor de activitate. XP ne amintete cu respect
ca fiierele PowerPoint nu se pot compila.
De altfel, inspirarea proceselor de dezvoltare a programelor din ingineria
construciilor se pare c nu este cea mai fericit alegere. Este adevrat c un
inginer care vrea s construiasc un pod peste un ru face mai nti msurtori,
realizeaz un proiect i abia apoi trece la execuie, toate acestea ntr-un mod
secvenial i previzibil. Dar dezvoltarea de programe nu seamn cu aa ceva,
orict am vrea s credem asta. Dac inginerului constructor respectiv i s-ar
schimba cerinele de rezisten i i s-ar muta malurile chiar cnd a terminat de
construit jumtate de pod, putem fi siguri c acel inginer i-ar schimba modul de
lucru. Din pcate ns, nu tim (nc) cum. Iniiatorii XP definesc urmtoarele
dou carte, ca baz filosofic pentru aceast metodologie.
Principiile metodelor agile
Implicarea clientului
- Clientul trebuie implicat pe tot parcursul procesului de dezvoltare.
Rolul su este de a prioritiza noile cerine i de a evalua iteraiile
sistemului
Livrarea incremental
- Programul este dezvoltat incremental, clientul indicnd cerinele care
trebuie incluse la fiecare iteraie
Oamenii nu procesul

91
- Abilitile echipei de dezvoltare trebuie recunoscute i exploatate.
Echipa trebuie lsat s-i contureze propriile modaliti de lucru, fr
a i se da reete
Acceptarea schimbrii
- Echipa trebuie s se atepte ca cerinele s se schimbe iar
proiectarea sistemului trebuie fcut astfel nct s se adapteze uor
la aceste schimbri
Meninerea simplitii
- Concentrare pe simplitate att n programele dezvoltate ct i n
procesul de dezvoltare. Oricnd este posibil, trebuie eliminat
complexitatea din sistem
Problemele metodelor agile
Este dificil meninerea interesului clienilor implicai n proces
Membrii echipei pot fi incapabili s se adapteze la implicarea intens
caracteristic metodelor agile
Cnd exist mai muli factori de decizie, este dificil prioritizarea
schimbrilor
Meninerea simplitii necesit lucru suplimentar
Contractele pot fi o problem n cazul dezvoltrii iterative
Carta drepturilor dezvoltatorului:
o Ai dreptul s tii ceea ce se cere, prin cerine clare, cu declaraii clare
de prioritate;
o Ai dreptul s spui ct i va lua s implementezi fiecare cerin, i s i
revizuieti estimrile n funcie de experien;
o Ai dreptul s i accepi responsabilitile, n loc ca acestea s-i fie
asignate;
o Ai dreptul s faci treab de calitate n orice moment;
o Ai dreptul la linite, distracie i la munc productiv i plcut.
Carta drepturilor clientului:
o Ai dreptul la un plan general, s tii ce poate fi fcut, cnd, i la ce
pre;

92
o Ai dreptul s vezi progresul ntr-un sistem care ruleaz i care se
dovedete c funcioneaz trecnd teste repetabile pe care le specifici
tu;
o Ai dreptul s te rzgndeti, s nlocuieti funcionaliti i s schimbi
prioritile;
o Ai dreptul s fii informat de schimbrile n estimri, suficient de
devreme pentru a putea reduce cerinele astfel ca munca s se
termine la data prestabilit. Poi chiar s te opreti la un moment dat i
s rmi cu un sistem folositor care s reflecte investiia pn la acea
dat.
Aceste afirmaii, dei par de la sine nelese, conin semnificaii profunde.
Multe din problemele aprute n dezvoltarea programelor pornesc de la
nclcarea acestor principii. Enumerm pe scurt cteva dintre caracteristicile XP:
o Echipa de dezvoltare nu are o structur ierarhic. Fiecare contribuie la proiect
folosind maximul din cunotinele sale;
o Scrierea de cod este activitatea cea mai important;
o Proiectul este n mintea tuturor programatorilor din echip, nu n
documentaii, modele sau rapoarte;
o La orice moment, un reprezentant al clientului este disponibil pentru
clarificarea cerinelor;
o Codul se scrie ct mai simplu;
o Se scrie mai nti cod de test;
o Dac apare necesitatea rescrierii sau eliminrii codului, aceasta se face fr
mil;
o Modificrile aduse codului sunt integrate continuu (de cteva ori pe zi);
o Se programeaz n echip (programare n perechi). Echipele se schimb la
sfritul unei iteraii (1-2 sptmni);
o Se lucreaz 40 de ore pe sptmn, fr lucru suplimentar.
Concluzii
Au fost prezentate aici cele mai importante metodologii de dezvoltare a
programelor, mai puin metodologia orientat obiect care a devenit n momentul

93
de fa, suveran i despre care vom vorbi n continuare. Mai nti au fost
descrise metodologiile generice: secvenial, ciclic i hibrid, cu avantajele i
dezavantajele fiecreia. Apoi s-au amintit cteva metode concrete de dezvoltate:
modelul cascad, modelul spiral, WinWin, prototipizarea, metodologia Booch,
metodele formale i aa-numita programare extrem.

3.2.2.9. Metodologia Open Source
Metodologia Open Source nseamn surs la vedere. Este o abordare
recent, aprut ca urmare a dezvoltrii mijloacelor de comunicaie: FTP, e-mail,
grupuri de discuie Exemple clasice sunt: sistemul de operare Linux, browser-ul
Netscape 5.
Codul surs este transmis utilizatorului final ntr-o manier non-proprietar
(fr patent), pe baza unei licene open-source (gen GNU+ sistem de operare
Open Source gen Unix).
Critici
Nu exist documente de proiectare sau alte documentaii ale proiectului
Nu se realizeaz testarea la nivel de sistem
Nu exist cerine ale utilizatorilor n afar de funcionalitatea de baz
Marketingul produsului este incomplet
O iteraie tipic pentru o astfel de abordare este:
Dezvoltatorul realizeaz proiectarea i codarea (individual sau n echip);
Ceilali dezvoltatori sau comunitatea de utilizatori realizeaz debugging-ul
i testare;
Noile funcionaliti dorite i erorile depistate sunt trimise iniiatorului
proiectului;
Se lanseaz o nou versiune cu erorile corectate i se analizeaz noile
cerinele;
Se distribuie o list de sarcini ctre comunitatea de utilizatori, cutndu-se
membri voluntari care s execute sarcinile de pe list;


94
3.2.2.10. Reverse Engineering - Inginerie invers
Se analizeaz sistemele anterioare i se ncearc reutilizarea
componenelor existente:
- Software, hardware
- Documentaie, metode de lucru
Unele componente nu pot fi utilizate, altele trebuie modificate (n faza de
proiectare);
Componentele selectate sunt integrate direct n sistem.

3.2.2.11. Metodologia de dezvoltare Offshore
Offshore nseamn n limba englez , n larg. Companiile consider ca
profitabil outsourcing-ul pentru funciile care pot fi dezvoltate mai ieftin n alt ar
Venituri din outsourcing IT n 2004 au fost:
India 43%
Canada 32%
China 5%
Europa de Est 5%
Motivarea externalizrii (outsourcing) este:
Reducerea costurilor;
Creterea eficienei;
Concentrarea asupra obiectivelor critice ale proiectului;
Accesarea flexibil a unor resurse care altfel nu ar fi accesibile (de
exemplu personal nalt calificat)
Dimensiunea mare a proiectului.
Etapele metodologiei sunt:
1. Iniierea proiectului (local)
2. Analiza cerinelor (local)
3. Proiectarea de nivel nalt (local)
4. Proiectarea detaliat (offshore)
5. Implementarea (offshore)
6. Testarea (offshore sau local)

95
7. Livrarea (local).

3.2.2.12. Metodologia orientat pe obiect
Metodologia proiectrii orientate pe obiect inverseaz metodologiile
anterioare, n special metodologiile funcionale, aa cum au fost ele concepute
de Yourdan, n sensul c focalizeaz abordarea pe identificarea obiectelor din
domeniul aplicaiei, potrivind apoi procedurile n jurul acestor obiecte. La o
eventual modificare a cerinelor , nu va mai fi necesar s fie schimbat toat
structura obiectelor.
Din start, termenul orientat pe obiect nseamn organizarea software-ului ca
o colecie de obiecte discrete, fiecare obiect ncorpornd att structuri de date,
ct i comportament.
Ce este un obiect?
Un obiect poate fi considerat o entitate care ncorporeaz att structuri de
date, numite atribute, ct i comportament, denumit operaii.
Un obiect trebuie s aib caracteristicile urmtoare:
- Identitate : obiectul este o entitate discret, care se distinge dintre alte
entiti. Exemple: o fereastr pe o staie de lucru, un triunghi isoscel, o list de
persoane.
- Clasificare : obiectele cu aceleai atribute i operaii se grupeaz n clase.
Fiecare obiect cu aceleai atribute i operaii poate fi considerat ca o instan a
unei clase. Exemple: fereastr, triunghi, list.
- Polimorfism : aceeai operaie (cu acelai nume) poate s aib
comportament diferit n clase diferite. Exemple: a muta o fereastr, a muta un
triunghi. Operaia a muta nseamn lucruri diferite, depinznd de obiectul asupra
cruia se aplic. Implementarea concret a unei operaii ntr-o clas se numete
metod.

96
- Motenire: Este o caracteristic a abordrii obiectuale i se refer la
transmiterea pe cale ierarhic a atributelor i metodelor tuturor claselor
descendente, ntr- o relaie ierarhic.
Modele de lucru n OMT
Metodologia de proiectare orientat pe obiect s-a dezvoltat iniial ca tehnic
de modelare a obiectelor cunoscut i sub numele de OMT, n englez Object
Modelling Technique i a evoluat apoi printr-o tehnologie unificat numit UML.
OMT-ul folosete trei modele de baz i anume: modelul obiectelor,
modelul dinamic, modelul funcional.
Modelul obiectelor:
- descrie structura static a obiectelor din sistem i relaiile dintre ele;
- descrie ce se modific n sistem (adic obiectele);
- este reprezentat cu ajutorul diagramelor de obiecte.
O diagram de obiecte este un graf ale crui noduri sunt obiectele i ale
crui arce sunt relaiile dintre obiecte.
Modelul dinamic:
- descrie acele aspecte ale sistemului care se schimb n timp;
- specific i implementeaz partea de control a sistemului;
- descrie cnd se modific sistemul;
- este reprezentat cu ajutorul diagramelor de stare.
Modelul funcional:
- descrie transformrile valorilor datelor n cadrul sistemului;
- descrie cum se modific sistemul;
- este reprezentat cu ajutorul diagramelor de flux de date.
O diagram de flux de date este un graf ale crui noduri sunt procesele i
ale crui arce sunt fluxurile de date.

97
Etapele aplicrii metodologiei orientate pe obiect
Metodologia OO pentru dezvoltarea software-ului const din construirea, n
etapa de analiz a sistemului, a unui model complet al aplicaiei, care va
cuprinde cele trei modele prezentate anterior. Ulterior se vor aduga detaliile de
implementare necesare. Etapele sunt: analiza, proiectarea sistemului,
proiectarea obiectelor, implementarea sistemului.
- Analiza
Pornind de la specificarea cerinelor, analistul va concepe un model cu
obiecte din domeniul aplicaiei i nu al programrii ( ca de exemplu liste, arbori,
etc).
- Proiectarea sistemului
Proiectantul de sistem va lua decizii generale asupra arhitecturii globale a
sistemului, va alege o strategie de implementare i o strategie de alocare a
resurselor. De asemenea, va trebui s stabileasc mprirea sistemului mare n
subsisteme.
- Proiectarea obiectelor
Proiectantul obiectelor va aduga detalii de implementare modelului obinut
la analiz, n concordan cu strategia aleas n etapa de proiectare a sistemului.
Accentul se va pune acum pe algoritmii i structurile de date folosite pentru a
implementa clasele obinute n etapa de analiz.
- Implementarea
n cele din urm, clasele i relaiile dintre clase obinute n celelalte etape
vor fi traduse ntr-un limbaj de programare, ntr-o baz de date sau vor fi
implementate hardware. Este important de remarcat c dei analiza unui sistem
poate s se efectueze folosind noiuni de obiecte i clase, nu este neaparat
necesar ca implementarea s se fac ntr-un limbaj de programare orientat pe
obiect (cum ar fi J ava, C++, Smalltalk, Eiffel sau ADA). Implementarea poate fi
fcut n orice limbaj de programare. Un exemplu n acest sens l constituie
biblioteca de elemente de interfa pentru X Window, numit Motif, care este

98
scris n C, dei a fost proiectat folosindu-se noiuni de analiz orientat pe
obiect.
Conceptele de baz
A. Abstractizarea
Accentul pentru un obiect se pune pe ce este acesta i nu pe ce trebuie s
fac, nainte de a stabili concret detaliile de implementare. De aceea, etapa
esenial n crearea unei aplicaii orientate pe obiect este analiza I nu
implementarea, care poate deveni mecanic i n mare parte automatizat, dac
se folosesc instrumente software specializate ( gen CASE).
B. ncapsularea (ascunderea informaiei)
ncapsularea const n separarea aspectelor externe ale unui obiect, care
sunt accesibile altor obiecte, de aspectele de implementare interne ale obiectului,
care sunt ascunse celorlalte obiecte. Utilizatorul obiectului poate accesa doar
anumite atribute i operaii, n scopul perfecionrii unui algoritm sau eliminrii
unor erori. ncapsularea ne va mpiedica s modificm toate caracteristicile
obiectului, iar aplicaiile care utilizeaz obiectul nu vor avea de suferit.
C. mpachetarea datelor i a comportamentului n acelai obiect
Aceasta se refer tocmai la faptul c un obiect conine att structuri de date
ct i operaii, i permite s se tie ntotdeauna crei clase i aparine o anumit
metod, chiar dac exist mai multe operaii cu aceeai nume, n clase diferite.
D. Partajarea
Tehnicile orientate pe obiect promoveaz partajarea la diverse niveluri.
Partajarea poate nsemna transmiterea acelorai structuri de date i respectiv,
operaii de-a lungul unor clase, dintr-o ierarhie de clase. Acest lucru are un efect
benefic asupra economisirii spaiului. Pe de alt parte, partajarea ofer
posibilitatea reutilizrii proiectrii, respectiv a codului anumitor clase, n
proiectele ulterioare.
E. Accentul pus pe structura de obiect, nu pe cea de procedur
Este una dintre caracteristicile principale ale tehnicilor orientate pe obiect.
Dac n tehnicile funcionale (sau procedurale) accentul n analiza sistemului
cade pe descompunerea funcional a acestuia, deci pe ceea ce trebuie s fac


99
sistemul (n ultim instan pe construirea diagramelor de flux), n tehnicile OOP
accentul cade pe nelegerea sistemului din punct de vedere al descompunerii
acestuia n entiti (obiecte) i n stabilirea relaiilor dintre acestea, deci pe ce
este un obiect. Mult nainte de a stabili ce face sistemul, problema care se pune
const n a preciza cine execut i care sunt relaiile ntre cei care execut; deci
mai important este diagrama obiectelor.
Analiza orientat pe obiecte
Analiza este primul pas al metodologiei tehnicii de modelare orientat pe
obiecte i are ca scop construirea unui model precis, concis i concret al lumii
reale.
n figura 3.8 este prezentat o vedere general asupra procesului de
analiz. Analistul, cel care realizeaz analiza problemei, ncepe cu definirea
problemei, aa cum este ea formulat de potenialii utilizatori. Analistul va
construi un model, care poate fi incomplet, pe baza unor cerine incomplete. De
aceea, modelul trebuie apoi rafinat.
Primul pas n definirea problemei este specificarea cerinelor. Se va stabili
ceea ce trebuie s fac aplicaia i nu cum, i anume se vor defini:
- scopul problemei;
- necesitile;
- contextul aplicaiei;
- diverse presupuneri;
- performaele necesare;
n partea de proiectare i implementare se vor urmri:
- algoritmi;
- structurile de date;
- arhitectura;
- optimizrile.


100

Analiza

Proiectare

Fig.3.8. Procesul de analiza vedere general

Concl uzii
1. Simpla adoptare a unei metodologii fr o analiz temeinic a
cerinelor i contextului de lucru nu este fezabil.
2. Fr sprijin din partea factorilor de decizie executiv, dezvoltarea
proiectului este complex i de durat.
3. Metodologia este o tactic ce trebuie considerat numai dup
determinarea strategiei generale a companiei

UTILIZATORI

CERINE
GENERALE
PUNEREA
PROBLEMEI

CONSTRUIREA
MODELULUI
MODELUL OBIECTELOR
MODELUL DINAMIC
MODELUL FUNCIONAL
Intervieverea
utilizatorului
Experiena din
lumea real
Cunotine
proprii

101

4

UML- Limbaj unificat de modelare
4.1. Introducere n UML
Limbajul unificat de modelare, numit prescurtat UML se dorete a fi un
instrument care s ofere o metodologie unificat de modelare, analiz i
proiectare a sistemelor informatice. El ofer o arhitectur de sistem pentru
analiza i proiectarea orientat obiect a sistemelor software, incluznd i
documentarea acestora, dar i pentru modelarea altor sisteme non-software,
cum ar fi modelarea afacerilor, de exemplu.
Metodele orientate pe obiect au evoluat ncepnd cu anii 1960. Multe dintre
limbajele orientate pe obiect au ctigat popularitate n anii 80 i proiectanii de
sistem au dorit i o metodologie de proiectare orientat pe obiect. Comunitatea
programatorilor era ns nc puternic dependent de metodele de proiectare
structurate, rezultnd astfel, din combinarea celor dou tipuri de metode de
programare, modele inconsistente.
Totul a pornit de la Grupul de Management pe Obiect (OMG- Object
Management Group), un consoriu de peste 800 de membri i companii
amaricane (fondat n 1989) care produc i distribuie aplicaii realizate n
tehnologie orientat obiect. Scopurile principale sunt reutilizarea, portabilitatea i
interoperabilitatea software-lui orientat pe obiect.
Adoptarea specificaiei UML a redus gradul de confuzie n cadrul industriei
limbajelor de programare i a permis schimbul reciproc ntre instrumentele
vizuale de dezvoltare.

102
UML este succesorul cel mai bun al metodelor de analiz i proiectare
orientate obiect (OOA&A) care au aprut ntre 1980-1990 cum sunt OOADA
(Booch), OMT (Rumbaugh) i OOSE (Jacobson). Prima sa versiune a aprut n
Ianuarie 1997 i a fost dezvoltat de cei trei autori amintii mai nainte, adic:
Grady Booch, Jim Rumbaugh i Ivar Jacobson.
UML a fost selectat ca standard al limbajelor de modelare orientate obiect
(OOML- Object Oriented Modeling Language) de ctre OMG i este utilizat de
dezvoltatorii de produse software.
CE ESTE UML ?
Sunt multe definiii i nici una unanim acceptat sau standardizat. Dar toate
au n comun urmtoarele:
UML este un limbaj grafic pentru vizualizarea, specificarea, construrirea i
documentarea componentelor unui sistem software.
Mai mult se poate spune c UML este un limbaj vizual de modelare, dar care
nu are pretenia de a fi un limbaj de programare vizual, el putnd fi utilizat ca un
limbaj universal pentru descrierea sistemelor.
UML poate fi utilizat in toate domeniile ingineriei software oferind un mod
standard de a scrie proiecte de sistem, incluznd obiectele conceptuale i
funciile de sistem precum i obiecte concrete cum ar fi declaraiile din limbajul
de programare, scheme ale bazelor de date i componente software reutilizabile.
Acest limbaj unificat reprezint o arhitectur bazat pe patru niveluri de
abstractizare definite n metamodelul UMLi anume:
1. Meta-metamodelul infrastructura pentru o arhitectur de modele;
2. Metamodelul o instan a unui meta-metamodel i definete
semantica necesar pentru reprezentarea modelelor aplicaiei;
3. Modelul o instan a unui metamodel;
4. Obiecte utilizator o instan a unui model, utilizate pentru
descrierea unui domeniu specific de informaie.
Metamodelul UML este un model logic i are n componena sa trei pachete
logice:
- Elemente de comportament (Behavioral Elements);

103
- Elemente de baz (Foundation);
- Mecanisme generale (Model Management).
Avantajele unui metemodel logic este acela c accentueaz declarativele
semantice, nlturnd detalile de implementare. Implementrile care utilizeaz
metamodelul logic trebuie s se conformeze semanticilor sale i s fie capabil s
importe i s exporte obiecte.
n cadrul fiecrui pachet, elementele unui element sunt definite astfel: sintax
abstract, reguli foarte bine formulate sau reguli de corectitudine i semantic.

Fig. 4.1. Structura UML
Componentele de baz ale UML sunt elementele model. Un model
reprezint o colecie de obiecte (clase, pachete, actori, cazuri de utilizare,
componente i noduri), relaii (de asociere, dependen, generalizri) i
diagrame.
Un model :
- Este entitatea de baza a proiectarii;
- Este individualizat;
- Este legat de alte modele prin legaturi;

Diagrame de
activitate
Masini de stare
(State Machines)
Cazuri de utilizare
(Use Cases)
Colaborari
(Colaboration)
Comportament comun
(Common Behavior)
Elemente de comportament
(Behavioral Elements)
Mecani sme generale
(Model Management)
Elemente de baza
(Foundation)
Mecanisme extinse
(Extension Mechanism)
Nucleu
(Core)
Tipuri de date
(Data Types)

104
- Este reprezentat grafic.
Modelele sunt de dou tipuri: modele structurale (statice) care accentueaz
structura obiectelor din sistem, incluznd i clasele lor, interfeele, atributele i
relaiile i modele de comportament (dinamice), care accentueaz
comportamentul obiectelor din sistem, incluznd i metodele, interaciunea,
colaborrile i starea lor istoric.
Principalele obiective ale UML-ului sunt:
S pun la dispoziia utilizatorului un limbaj vizual pentru dezvoltarea i
specificarea
sistemului;
S suporte concepte de dezvoltare de nivel superior cum sunt
componente, colaborri, modele;
S ncurajeze utilizarea limbajelor de programare orientate pe obiect;
S furnizeze o baz formal pentru nelegerea limbajului de modelare.

4.2. Diagrame i concepte UML
UML definete patru tipuri de diagrame :
1. Diagrama de clase (Class Diagram);
1.1. Diagrama de obiecte (Object Diagram);
2. Diagrama cazurilor de utilizare (Use Case Diagram);
3. Diagrame de comportament (Behavior Diagrams);
3.3.1. Diagrama de stare, sau grafice de stri (Statechart
Diagram);
3.3.2. Diagrama de activitate (Activity Diagram);
3.3.3. Diagrama de interaciuni (Interaction Diagrams);
3.3.4. Diagrama secvenial (Sequence Diagram);
3.3.5. Diagrama de colaborare (Collaboration Diagram);
4. Diagrame de implementare (Implementation Diagrams);
4.1. Diagrama de componente (Component Diagram);
4.2. Diagrama de aplicaie (de dezvoltare) (Deployment
Diagram).

105
Aceste diagrame furnizeaz perspective multiple i diferite asupra sistemului
din punctul de vedere al analizei i/sau dezvoltrii.
4.2.1. Diagrama de clase (Class Diagram)
O diagrama a claselor este un graf ale crui noduri sunt clasele din sistem i
ale crui arce sunt relaiile dintre clase. Diagrama claselor este probabil cea mai
important diagram UML. O astfel de diagram poate conine interfee, pachete,
legturi, i chiar instane, cum ar fi obiecte.
Clasele sunt tipuri abstracte de date. n cadrul programului se lucreaz cu
instanieri ale claselor definite, numite obiecte.
Clasele de obiecte sunt categorii de obiecte cu atribute (structuri de date) i
operaii (comportament) comune.
Fiecare obiect are propria sa:
stare (definita de un set de valori pstrate n atributele sale);
identitate (obiectele se disting ntre ele prin existen , nu prin
atribute);
comportament (felul n care un obiect acioneaz i reacioneaz
n termenii comunicarii prin mesaje i schimbrii ale strii ).
Scopul diagramei de clase este de a prezenta structura de clase din
cadrul unui model. n aplicaiile orientate pe obiect clasele au atribute, operaii
i relaii cu alte clase.
Elementul fundamental al diagramei claselor este un dreptunghi care
reprezint o clas, aa cum este ilustrat n figura 3.2.

Fig. 4.2. Reprezentarea unei clase din diagrama de clase UML

Class
Atribute
Operaii ()

106
Dreptunghiul care reprezint clasa este mprit n trei compartimente cu
urmtoarele semnificaii:
- Compatimentul de sus este cel mai important i conine numele clasei;
- Compatimentul din mijloc conine o list de atribute;
- Compartimentul de jos conine o list de operaii.
n multe diagrame compartimentele de mijloc i de jos sunt omise. Chiar i
atunci cnd sunt prezente, ele nu arat toate atributele i operaiile. Scopul este
de a arata doar acele atribute i operaii care sunt eseniale pentru diagrama
respectiv.
Diagrama claselor poate conine urmtoarele elemente model:
Pachete. Pachetele sunt utilizate pentru a structura modelul.
Dependene ntre pachete. Acestea arat c respectivele clase
dintr-un pachet utilizeaza clasele pachetului de care depind.
Colaborri ntre obiecte.
Interfee. Interfeele nu conin atribute, ci doar operaii.
Clase. Clasele reprezint cel mai important concept al programrii
orientat pe obiect i al UML.
Relaii de motenire. Acestea se pot regsi ntre interfee sau
ntre clase, dar niciodat ntre o interfa i o clas.
Relaii de implementare. Pot exista numai ntre interfee i clase.
Relaii de asociere. Asocierile sunt relaii ntre clase.
n construirea claselor care vor sta la baza proiectrii programului trebuie
clarificate entitile care vor evolua n sistem i operaiile asociate. Trebuie de
asemenea definite reponsabilitile fiecarei clase n implementare i colaborrile
ntre clasele modelate grafic prin legturi de diverse tipuri i cu diferite
multiplicitti. Legturile sunt simbolul relaiilor ntre clase.
Un exemplu de reprezentare a unei clase i anume clasa Cerc este
prezentat n figura 4.3.


107

Fig. 4.3. Reprezentarea clasei Circle

Fiecare instan de tip Circle pare c are o instan de tip Point. Aceasta
este o relaie cunoscut ca relaie de compoziie i figurat n UML ca n fig. 4.4.

Fig. 4.4. Relaie de compoziie

Rombul negru reprezint compoziia. El este plasat n dreptul cercului
deoarece cercul este compus din puncte. Punctul nu trebuie s tie nimic despre
cerc. Sgeata din partea cealalt denot faptul c relaia poate fi parcurs numai
ntr-un sens. n UML se presupune c relaiile sunt implicit bidirecionale cu
excepia cnd se termin print-o sgeat aa cum am prezentat mai sus. Dac s-
ar omite sgeat ar nsemna c Punctul trebuie s cunoasc Cercul, ceea ce la
nivel de cod ar nsemna s de include # include Cercle.h n Point.h.
Relaiile de compoziie sunt mai puternice dect cele de coninut sau
agregare. Agregarea este ntregul sau o parte din relaie. n cazul prezentat
Cercle este ntregul iar Point parte a Cercle.
Relaia de compoziie indic de asemenea c timpul de via al Point
depinde de Cercle. Aceasta nseamn c, dac Cercul este distrus va fi distrus i
Punctul.
n limbajul C++ aceast clas se reprezint astfel:

Circle
I t sRadi us: doubl e
I t sCent er : Poi nt
ar ea( ) : doubl e
ci r cumf er ence( ) : doubl e
set Cent er ( Poi nt )
set Radi us( doubl e)

108
Class Circle {
public:
void SetCenter(const Point&);
void SetRadius(double);
double Area() const;
double Circumference() const;
private:
double itsRadius;
Point itsCenter;
};
n acest caz s-a reprezentat relaia de compoziie ca o variabil membr. Se
poate folosi la fel de bine un pointer care la sfrit v-a fi ters de destructorul
Cercului.
Clasificatori
Un clasificator este un element care descrie caracteristicile de
comportament i structurale ale sistemului. Clasificatorii acceptai de UML sunt
de mai multe tipuri i includ: clase, tipuri de date, interfee, componente,
semnale, noduri, cazuri de utilizare i subsisteme. Un clasificator declar un set
de caracteristici care includ atribute, metode i operaii. Numele unui clasificator
este unic i reprezint o metaclas abstract.
UML admite urmtoarele tipuri speciale de clasificatori, numite stereotipuri :
<<metaclas>> - precizeaz c instanele clasificatorului sunt clase;
<<powertype>> - specific un clasificator ale crui obiecte sunt
descendenii unui anumit printe;
<<process>> un clasificator care reprezint un flux de control cu o
interfa puternic;
<<thread>> un clasificator care reprezint un flux de control;
<<utility>> specific un clasificator care nu are instane;
Un atribut descrie un domeniu de valori pe care le pot lua instanele unui
clasificator. El poate avea o valoare iniial i una dintre urmtoarele proprietpi

109
care se refer la posibilitaile de modificare a valorii, dup ce obiectul a fost
creat:
changeable (modificabil)- nu se impune nici o rectricie asupra valorii
atributului;
addOnly valabil numai pentru atributele cu ordin de multiplicitate mai
mare ca unu; o valoare odat adugat nu mai poate fi tears sau
modificat;
frozen valoarea atributului nu poate fi modificat dup iniializarea
obiectului.
O operaie este un serviciu care poate fi solicitat de ctre un obiect. Are
aceeai semnificaie ca i n cazul metodelor OMT prezentate n capitolul 2. O
operaie n UML poate avea una dintre urmtoarele proprieti care se refer la
simultaneietatea apelurilor concurente ctre o clas pasiv:
isQuery ndic dac se schimb sau nu starea sistemului. Dac are
valoarea true starea sistemului rmne neschimbat.
sequential apelurile trebuie efectuate secvenial;
guarded se pot produce simultan apeluri multiple ctre o instan dar
numai unul are permisiunea s nceap, celelalte fiind blocate pn la
finalizarea operaiei.
concurrent - se pot produce simultan apeluri multiple ctre o instan,
fiecare dintre ele putnd fi realizate n paralel.
Operaiile pot avea parametri care sunt utilizai pentru specificare i fiecare
include un nume, un tip i direcia comunicrii. Direcia se poate indica astfel:
in parametru de intrare care nu poate fi modificat;
out parametru de ieire care poate fi modificat pentru a transmite
informaii ctre alte elemente;
inout parametru de intrare care poate fi modificat;
return valoare returnat de un apel.
Multiplicitatea unei clase specific numrul de instane pe care le poate
avea. Multiplicitatea se aplic i la nivel de atribut.
O diagram tipic de clase este prezentat n figura 3.5.

110

Fig. 4.5. Diagram de clase

4.2.1.1. Diagrama de obiecte
Aceast diagram evideniaz un set de obiecte i relaiile cu alte obiecte la
un moment dat. O diagrama de obiecte poate fi considerat un caz special al
diagramelor claselor sau al diagramei de colaborri i este o instan a unei
diagrame de clase. Ea arat o instan a unei stri a unui sistem la un moment
dat i conine: obiecte, legturi, eventual note i constrngeri .
Obiectele pot fi :
Actor este un obiect care opereaz asupra altor obiecte dar asupra cruia
nu poate opera alt obiect;
Server un obiect care poate opera pe alte obiecte;
Agent un obiect care opereaz asupra altor obiecte i asupra cruia pot
opera alte obiecte. Un agent lucreaz n numele unui actor sau altui
agent.

111
Legtura reprezint o instan a unei relaii de asociere i definete o
conexiune ntre instane. O legtur trebuie s aib un furnizor
(desemneaz elementul care nu este afectat de o modificare) i un client.
Un element furnizor poate participa n mai multe relaii de legtur ctre
diferii clieni. Un element client poate participa numai ntr-o singur relaie
de legtur cu un furnizor. O legtur este o dependen unde furnizorul
este un model i clientul reprezint instanierea modelului care
ndeplinete substituirea parametrilor modelului;
Note pentru formularea constrngerilor i a altor comentarii sau alte
explicaii referitoare la clasificatorul utilizat;
Aceast diagram folosete pentru vizualizarea, specificarea, construirea i
documentare structurii obiectelor i n special pentru a arta structurile de date.
Modelarea structurii obiectelor presupune:
Identificarea mecanismului de modelat (o anumit funcie sau
comportamentul unei pri a sistemului);
Pentru fiecare mecanism, se identific clasele, interfeele i alte elemente
care particip la aceast colaborare;
Se consider un scenariu prin acest mecanism; se determin fiecare
obiect care particip la mecanism;
Selectarea obiectelor care au responsabiliti de nivel nalt pentru fluxul
lucrrii;
Identificarea precondiiilor strilor iniiale i postcondiiilor strilor finale;
Specificarea activitilor i aciunilor ncepnd cu starea iniial;
Evidenierea tranzaciilor care conecteaz aceste activiti i aciuni;
Evidenierea obiectelor importante implicate n fluxul de lucrri, cu
evidenierea schimbrii valorilor obiectelor.
Modelarea operaiilor presupune:
Colectarea abstraciilor implicate n operaii (parametri, atribute ale
claselor);
Identificarea precondiiilor strii iniiale i postcondiiilor strii finale;
Specificarea activitilor i aciunilor ncepnd cu starea iniial;

112
Folosirea ramificrii dac este necesar;
Folosirea bifurcrii i reunirii pentru specificarea fluxurilor de control
paralele.

4.2.2. Diagrama cazurilor de utilizare
Diagrama prezint funcionalitatea sistemului din punctul de vedere al
interaciunilor externe i este utilizat n etapa de analiz. Elementele UML
coninute ntr-o astfel de diagram sunt: cazuri de utilizare, actori, relaii de
utilizare (includere), relaii de extindere, relaii de generalizare i de asociere.
Elementele din aceast diagram sunt utilizate n primul rnd pentru a defini
comportamentul sistemului, a subsistemelor, a unei entiti, fr a specifica
structura intern. Diagrama cazurilor de utilizare prezinta relatia dintre actori,
cazuri de utilizare si sistem.
Diagrama este un grafic care conine actori, un set de cazuri de utilizare,
posibile interfee i relaiile dintre acestea.

1. Componentele diagramei cazurilor de utilizare
Nr. Denumire component Simbol grafic
1 Actor

2. Cazul de utilizare

3. Relaii

1. Un actor este cineva sau ceva care interacioneaza cu sistemul .
Exemple:


113

Este o entitate intern sistemului (utilizator uman, dispozitiv fizic, un alt
sistem), legat de acesta printr-un schimb de informaie. Definete un set al
rolurilor pe care utilizatorii unei entiti le pot avea n cadrul interaciunii cu
aceasta.
2. Cazuri de utilizare
Orice caz de utilizare specific o succesiune de aciuni (evenimente),
cu variantele lor, pe care entitatea le realizeaz atunci cnd
interacioneaz cu actorii si.
Comportamentul unui caz de utilizare este specificat prin descrierea
setului de aciuni.

3. Relaii Uses i Extends
Relaiile de utilizare Uses (includere): Se folosesc atunci cnd exist
un comportament care se repet identic n situaia mai multor cazuri de
utilizare.
Relaiile de extensie - Extends : Sunt un tip special de generalizare
pentru cazurile de utilizare folosite atunci cnd avem un caz de utilizare
similar cu un alt caz, dar care face ceva n plus fa de acesta. Exemplul tipic
pentru o astfel de diagram este prezentat n figura 3.6. i se refer la
modelul cumprrii de produse online. Sageile pline din figuri reprezint
cazuri copii ( ).

Afi seaza cererea Acces i nformatii Afi seaza comanda
Analist Profesor
Student
Sistem Contabil

114

Fig. 4.6. Diagrama cazurilor de utilizare pentru comer on-line

Un alt exemplu de diagram a cazurilor de utilizare este prezentat n figura
4.7. i se refer la un sistem de eviden a studenilor.

Fig. 4.7. Diagrama cazurilor de utilizare pentru un sistem de eviden a
studenilor


115
Un alt exemplu de diagram este ilustrat n figura 3.8. Este prezentat un caz
de utilizare al unui sistem destinat urmrii activitii unei agenii de turism.
Utilizatorul (actor n sistem) se autentific i poate deveni client al agenii. De
asemenea un ofertant de servicii turistice se poate adresa agenii i devine
utilizator, dar de alt tip. Operatorul (angajat al agenii de turism), actor i el n
sistem, poate vizualiza clienii existeni, ofertele i poate face rezervri.

Fig. 4.8. Diagrama cazurilor de utilizare pentru o agenie de turism

4.2.3. Diagrame de comportament
4.2.3.1. Diagrama de stare
La fel ca i n abordarea OMT, prezentat n capitolul 3, diagrama de
stare modeleaz comportamentul unui singur obiect (instan a unei clase), a
unui caz de utilizare, a unui actor sau a ntregului sistem artnd de fapt
comportamentul orientat - eveniment al obiectului.
O diagram de stare UML este un graf care poate conine urmtoarele
elemente: stri, maini de stri, tranziii, evenimente, aciuni i bare de
sincronizare. O main de stri este o succesiune de stri prin care trece un

116
obiect, pe durata sa de via ca rspuns la evenimente. O main de stare poate
fi reprezentat prin intermediul urmtoarelor diagrame :
- diagrama de stare, caz n care accentul este pus pe comportamentul
ordonat-eveniment al obiectului;
- diagrama de activitate, caz n care accentul este pus pe activitile ce au
loc n obiect.
O stare reprezint o situaie din viaa unui obiect, putnd satisface anumite
condiii, realiznd activiti sau ateptnd producerea unor evenimente.
O stare poate fi:
Iniial, sau de nceput arat momentul de iniiere a mainii de stare
sau al unei substri i se reprezint n diagram printr-un cerc
nnegrit;
Intermediar o stare prin care trece maina de stare;
Final maina de stare a fost executat. Se reprezint prin dou
cercuri concentrice, cercul din interior fiind nnegrit.
Compus are n componen mai multe substri disjuncte. Se
reprezint printr-un dreptunghi mprit pe orizontal n dou zone.
Concurenial. Se reprezint printr-un dreptunghi mprit pe
orizontal n trei zone.
ntr-o diagram, strile se reprezint prin dreptunghiuri cu colurile rotunjite.
Tranziia reprezint trcerea de la o stare la alta dintr-o diagrama de stare.
Se reprezint printr-o sgeat.
Un exemplu de diagram de stare, cu toate elementele descrise mai sus
este prezentat n fig. 4.9 i reprezint maina de stare pentru un obiect
Produs.Diagrama de stare compus pentru acelai obiect este ilustrat n
fig.3.10.


117

Fig. 4.9. Diagram de stare

Fig.4.10. Diagrama de stare compus

118

Fig. 4.11. Diagrama de stare concurenial

Cazul exemplului discutat, agenia de turism diagrama de stare compus este
ilustrat n figura 4.12.

Fig. 4.12. Diagrama de stare compus pentru agenia de turism


119
4.2.3.2. Diagrama de activitate
O diagram de activitate este un caz particular al diagramelor de stare UML,
care definete un proces ce evolueaz de-a lungul aciunilor sale. Aceast
diagram nu extinde semantica diagramelor UML dar definete forme
prescurtate care se aplic modelrii proceselor. Este utilizat mai ales atunci
cnd este necesar evidenierea legturii fiecrui serviciu sau a ami multor
procese paralele. Diagrama evideniaz fluzul de control de la o activitate la alta.
O activitate rezult dintr-o anumit aciune (apelul unei operaii, trimiterea
unui semnal, crearea sau distrugerea unui obiect), sau evaluareaunei expresii
care schimb starea sistemului sau ntoarce o valoare.
Diagrama de activitate este o variant a unei maini de stri, n care strile
reprezint performana activitilor sau subactivitilor.
O stare de activiti reprezinta o subactivitate care are o anumit durat i
este constituit dintr-un set de aciuni.
Activitile reprezint task - uri ce trebuie realizate de ctre calculator sau de
o persoan, i vor fi traduse n cadrul modelului prin intermediul unor metode
metode specifice ataate claselor care vor ngloba comportament de control.
Diagrama de activitate conine urmtoarele elemente UML: stri (de
activitate, de aciune, de nceput, de sfrit), tranziii, obiecte, decizii, semnale
(recepionate sau transmise), bare de sincronizare, culoare (swimlane).
Simbolurile lor grafice sunt:
- Reprezint starea iniial, nceputul procesului;
Reprezint starea final sau sfritul procesului (nu este absolut
necesar figurarea strii finale, dac aceasta reiese clar din
contextul activitilor reprezentate).
Starea de aciune strile prin care este posibil s treac programul n
funcie de ceea ce are de executat.
Bloc de condiionare ce mparte secvena n mai multe alternative
Bloc de bifurcare - este similar conectorului logic i. Firele de
execuie care pleac din acest element se pot desfura paralel sau
pe rnd.

120
Bloc de reunire element prin care se sincronizeaz firele de execuie.
Bloc de sincronizare. Este folosit n cazul subsecvenelor concurente
pentru a sincroniza relaia producator-consumator astfel nct
consumatorul s utilizeze resursele disponibile la un moment dat.
Tranziie menine strile active i elementele modelului mpreun.
Reprezint dependene. Se pot trasa ntre oricare dintre elementele
modelului.
Pentru o mai bun ntelegere a diagramelor de activiti vom considera
urmtorul exemplu:
Se consider sistemul de gestiune al unei biblioteci. O persoan poate
mprumuta sau restitui o carte, nu poate mprumuta nici o carte dac are datorii
ctre bibliotec sau dac are deja cinci cri mprumutate. Pentru acest caz
diagrama de activitate este prezentat n figura 4.13.

Fig. 4.13. Diagrama de activitate pentu sistemul Biblioteca

121

Pentru sistemul Agenia de turism pe care l-am mai exemplificat anterior,
diagrama de activitate este prezentat n figura 4.14.

Fig. 4.14. Diagrama de activiti pentru sistemul Agenia de turism

Diagrama de activitate reflect comportamentul mai multor obiecte din cadrul
unui caz de utilizare. n figura 4.14 este prezentat de exemplu, activitatea de
inserare de client nou i de logare a acestuia n calitate de client.
Diagrama de activitate poate fi utilizat pentru:
1. Modelarea fluxului de activitate, activiti aa cum sunt vzute de actorii
din sistem. Aceasta presupune:
- selectarea obiectelor care au responsabiliti de nivel nalt pentru fluxul
de activitate;
- identificarea precondiiilor strilor iniiale i postcondiiilor strilor finale;
- specificarea activitilor i aciunilor ncepnd cu starea iniial;
- evidenierea tranziiilor care conecteaz aceste activiti i aciuni;

122
- precizarea obiectelor importante implicate n fluxul de activitate, cu
evidenierea schimbrii valorilor.
2. Modelarea operaiilor:
- colectarea abstraciilor implicate n operaii (parametri, atributeale
claselor);
- identificarea precondiiilor strilor iniiale i postcondiiilor strilor finale;
- specificarea activitilor i aciunilor ncepnd cu starea iniial;
- folosirea ramificrilor, dac este necesar;
- folosirea bifurcrii i reunirii pentru specificarea fluxurilor de control
paralele.

4.2.3.3. Diagrame de interaciuni
Diagramele de interaciuni sunt modele care descriu modul n care grupuri
de obiecte colaboreaz n acelai comportament. De obicei o diagram de
interaciuni captureaz comportamentul unui singur caz de utilizare. Diagrama
prezint un obiecte i mesaje care se schimb ntre acele obiecte n cazul de
utilizare respectiv.
Exist dou tipuri de diagrame de interaciune: diagramele secveniale i
diagramele de colaborare.
4.2.3.4. Diagramele secveniale
Diagramele secveniale sau diagrame de secven sunt reprezentri
alternative pentru interaciuni ntre obiecte. Ele reprezint interaciunile ntre
obiecte din punct de vedere temporal, contextul obiectelor nefiind prezentat n
mod explicit (ca n diagramele de colaborare), accentul concentrndu-se pe
exprimarea interaciunilor.
ntr-o diagram secvenial, un obiect este desenat ca un deptunghi n
captul unei linii verticale ntrerupte care reprezinz linia de via a obiectului.
Diagrama de secvene, alturi de diagrama de colaborare, surprinde
colaborrile ntre obiecte n cadrul unui anumit scenariu.
Obiectivul principal al acestei diagrame este acela de a exprima fluxul
mesajelor ntre obiecte, n timp secvenial. Diagrama de secvene arat

123
ordonarea n timp secvenial a interaciunilor ntre obiecte, iar n particular,
aceasta arat obiectele care particip la o interaciune i succesiunea mesajelor
care sunt schimbate.
Modelarea fluxului de control prin ordonarea n timp a mesajelor presupune:
Stabilirea contextului interaciunii (sistem, subsistem, operaie, clas, un
scenariu al unui caz de utilizare sau colaborare);
Identificarea obiectelor care joac rol n aciune;
Stabilirea pentru fiecare obiect a duratei de via n timpul interaciunii.
Pentru obiectele create i distruse n timpul interaciunii trebuie s se
indice explicit, prin mesaj, acest lucru;
Pentru fiecare mesaj ncepnd cu primul (care iniiaz aciunea) i
continund cu celelalte n ordinea succesiunii, se prezint proprietile
(parametrii);
Timpul i spaiul cerut pentru fiecare mesaj;
Precondiii sau postcondiii pentru fiecare mesaj.
Pentru un flux complet de control se pot utiliza mai multe diagrame.
Diagrama secvenial are dou dimensiuni: una vertical care reprezint
timpul, i una orizontal care reprezint diferite obiecte.
Firele verticale ntrerupte reprezint durata de via a unui obiect.
Mesajele indicate pe sgeile ce intr ntr-un anumit fir nu sunt altceva dect
metode ale clasei obiectului respectiv, care au fost apelate n cadrul obiectului cu
rol de control.
Aa cum am precizat deja n interiorul unei diagrame secveniale, obiectele
sunt plasate la nceputul diagramei. Dedesubtul fiecrui obiect se afl o linie
ntrerupt, care este numit linia de via a obiectului, i care reprezint durata
de via a obiectului n timpul interaciunii.
Fiecare mesaj este reprezentat de o sgeat plasat ntre liniile de via
ale celor dou obiecte care interacioneaz. Ordinea n care aceste mesaje sunt
transmise este de la nceputul ctre sfritul diagramei. Fiecare mesaj are o
etichet cu numele mesajului; de asemenea se pot include argumente i unele
informaii de control i se pot folosi auto-delegaiile.

124
Auto-delegaia este un mesaj pe care un obiect i-l transmite singur,
reprezentat de o bucl ntoars ctre linia de via a obiectului.
Un element nou care apare n diagrama secvenial este activarea.
Activarea se petrece atunci cnd o metod este activat, deoarece ea
poate s fie n execuie sau n ateptare.
Un alt element care apare este mesajul asincron. Acest mesaj asincron
poate executa unul din urmtoarii pai:
creeaz un nou fir;
creeaz un obiect nou;
comunic cu un fir care este deja n execuie.
n fig. 4.15 este prezentat diagrama secvenial pentru acelai sistem
exemplificat i n diagrama cazurilor de utilizare i destinat unei agenii de turism.
Diagrama a fost realizat n mediul Visual Paradigm. Dreptunghiurile verticale
situate pe liniile de via ale obiectelor reprezint activarea metodelor.
Simbolurile X prezente la sfritul liniilor de via indic tergerea obiectului.
Sgeile ntoarse reprezint auto-delegaia.

Fig. 4.15. Diagrama secvenial pentru o agenie de turism

125
n concluzie diagrama secvenial trebuie s analizeze detaliat o anumit
secven liniar a fluxului de control din cadrul unui caz de utilizare, urmrind
un anumit fir de activiti din diagrama de activiti, dup ce clasele au fost
modelate n detaliu .
4.2.3.5. Diagrame de colaborare
Diagrama de colaborare este un tip de diagram de interaciune, nrudit cu
diagrama secvenial , cu diferena c, n acest caz, accentul cade pe
interaciunea (comunicarea prin schimb de mesaje) ntre diferitele obiecte
implicate ntr-un caz de utilizare i nu pe succesiunea n timp a mesajelor .
Secvenialitatea acestora poate fi totui modelat prin numerotare (nu prin
dispunerea de-a lungul axei care simboliza durata de viata a unui obiect) .
Fiecare diagram de colaborare realizeaz o vedere de ansamblu a
legturilor sau a relaiilor structurale ce se stabilesc ntre obiectele i entitile
obiectelor din modelul curent.
Se pot crea una sau mai multe diagrame de colaborare pentru fiecare
pachet logic din model. Elementele de baz ale acestui tip de diagram sunt
obiectele (instane ale claselor), legturile (instane ale asocierilor definite ntre
clase n diagrama claselor), i mesajele care pot fi asociate bidirecional
legturilor.
Un obiect are: stare, comportament i identitate. Fiecare obiect din
diagram indic o instan a clasei. Simbolul de obiect este similar cu cel al
clasei exceptnd faptul c numele este subliniat. Dac se utilizeaz acelai
nume pentru mai multe obiecte utilizate n aceeai diagram, ele se presupun a
reprezenta acelai obiect; pe de alta parte, fiecare simbol de obiect reprezint n
mod distinct un obiect.
Dac exist mai multe instane de obiecte ale aceleai clase, se poate
modifica simbolul de obiect de exemplu, cu un click pe opiunea Multiple
Instances din Object Specification, al meniului mediului UML.
Mesajele dintre obiecte reprezint comunicarea dintre acestea i indic
aciunea n desfurare. Mesajul se scrie orizontal pe o sageat ce face legtura
dintre dou obiecte.

126
Un mesaj se poate reprezenta n trei moduri: mesajul singur, mesajul nsoit
de numrul secvenei sau mesajul cu numrul secvenei i o etichet.
S lum ca exemplu un sistem de gestionare a unei biblioteci
departamentale i s ntocmim diagrama de colaborare pentru : scenariul de
mprumut a unei cri i scenariul de restituire a crii. Fig. 4.16. reprezint
diagrama de colaborare pentru scenariul de mprumut al unei cri, iar figura 4.17
prezint diagrama de colaborare pentru ecenariul de restituire a crii.

Fig. 4.16. Diagrama de colaborare pentru mprumut de carte dintr-o bibliotec

Fig. 4.17. Diagrama de colaborare pentru scenariu de restituire a unei cri
O fereastra Introducere
date:ferdate
Restituie carte:
RestituieCarte
Bibliotecar : Bibliotecar()
3: CautaFisa(Date,Byte)
4: VerificaDataRet(date)
O carte :
Carte
O fisa :
Fisa
1: new()
2: VerificaCartela()
5: ActualizeazaStare(Byte)
6: ActualizeazaFisa(Date,Byte)
O fereastra Introducere
date:ferdate
O cerere
imprumut:SolicitaCarte
Bibliotecar : Bibliotecar()
O carte :
Carte
O fisa :
Fisa
3: CautaFisa(Date,Byte)
4: CautaCarte(String,String,String,Byte,Byte)
1: new()
2: VerificaCartela()
5: ActualizeazaStare(Byte)
6: ActualizeazaFisa(Date,Byte)

127
Pentru o mai bun nelegere i eventual o comparaie ntre cele dou tipuri
de diagrame de interaciuni (diagrama secvenial i diagrama de colaborare)
figura 4.18. reprezint diagrama de colaborare pentru sistemul destinat ageniei
de turism discutat anterior.

Fig. 4.18. Diagrama de colaborare pentru agenia de turism

4.2.4. Diagrame de implementare
Diagramele de implementare, aa cum le arat i numele, relev aspecte
ale implementrii, incluznd cod surs i execuia. Exist dou tipuri de astfel de
diagrame i anume: diagrame de componente i diagrame de aplicaie.
4.2.4.1. Diagrama de componente
Diagrama de componente este utilizat n modelarea aspectelor fizice ale
sistemelor prezentnd modul de organizare i relaiile de dependen ntre
componente i obiecte. O astfel de diagram are n componen urmtoarele
elemente UML: componente, obiecte, interfee i relaii de dependen.

128
Componenta se va utiliza pentru a reprezenta software-ul utilizat de sistem
(cod surs, cod binar sau executabil) sau alte documente existente n sistem. O
instan a unei componente reprezint o implementare run-time i poate fi
utilizat pentru a arta implementarea unit-urilor care au identitate n momentul
execuiei aplicaiei. Componentele unui sistem, incluznd programe, DLL, etc.,
pot fi amplasate n noduri.
Pentru a figura dependenele dintre diferite componente se utilizeaz o linie
ntrerupt de la o component la alta sau, de la o component la interfaa altei
componente. Alte elemente care pot fi incluse sunt: note, legturi, note ataate.
Diagrama se utilizez n unul dintre urmtoarele scopuri:
Modelarea codului surs;
Modelarea codurilor executabile;
Modelarea bazelor de date fizice;
Modelarea sistemelor adaptabile.
Fig. 4.19. prezint o diagram cu trei componente: Clieni, care este o baz
de date, Comenzi- baz de date, Eviden comenzi- aplicaie. De asemenea n
diagram exist i un obiect, Popescu Ion, care este instan a clasei Client.
Relaiile dintre aceste elemente sunt relaii de dependen.
Fig.4.20. prezint o diagram cu patru componente: Comenzi, Teri i
Produse, care sunt fiiere i Eviden teri, care este aplicaie.

Fig. 4.19. Diagrama cu trei componente

129

Fig. 4.20. Diagrama cu patru componente

4.2.4.2. Diagrama de aplicaie (deployment diagram)
Diagramele de aplicaie sau de desfurare arat structura fizic a
sistemului hardware i software, mai precis configurarea elementelor de procese
run-time, a componentelor software, i a proceselor i obiectelor. Au n
componen urmtoarele elemente UML: noduri, componente, obiecte, relaii de
dependen, relaii de asociere (comunicaie), precum i elemente ajuttoare:
note, legturi, etc.
Componentele au acelai rol i funcii ca n diagrama componentelor.
Nodurile sunt obiecte fizice care exist n timpul execuiei aplicaiei i reprezint
de obicei resurse de prelucrare. Ele includ componente ale calculatoarelor,
resurse umane sau resurse de procesare mecanic.
Diagramele de aplicaie arat configuraia elementelor de procesare n
timpule execuiei aplicaiei, precum i componenete software, procese i obiecte.
Ele sunt utilizate pentru a modela viziunea asupra desfurrii statice a
sistemului. Componentele care nu exist ca entiti la execuie ( de exemplu un
program care a fost compilat ) nu apar n aceste diagrame, ci numai n diagrama
componentelor.
O diagram este reprezentat ca un graf n care nodurile sunt conectate prin
relaii de comunicare. Nodurile pot conine i instane ale componentelor. Acest

130
lucru indic faptul c acele componente exist sau ruleaz n acele noduri. La
rndul lor componentele pot conine obiecte.
Componentele sunt conectate cu alte componente prin intermediul relaiilor
de dependen (linii ntrerupte n diagram), sau prin interfee. Aceste interfee
indic faptul c o component utilizeaz serviciile unei alte componente.
Componentele pot s migreze de la un nod la altul , iar acest lucru se
reprezint n diagram cu ajutorul stereotipului << becomes>> pentru relaii de
dependen.
O diagram de aplicaie, pentru o aplicaia cu clieni i furnizori este
prezentat n fig. 4.21.
Diagramele de aplicaie se folosesc n urmtoarele cazuri:
Modelarea sistemelor cu software implantat hardware. Diagramele se
utilizeaz pentru a modela dispozitivele i procesele care compun
sistemul.
Modelarea sistemelor client-server. Un astfel de sistem este o
arhitectur focalizat pe realizarea unei separri nete ntre interfaa
sistemului cu utilizatorul (de la client) i datele permanente ale
sistemului (de pe server).
Modelarea sistemelor complet distribuite.


131

Fig. 4.21. Diagrama de aplicaie


132


133

5

Principii de proiectare orientate pe obiect
Proiectarea orientat pe obiecte (OOD : Object Oriented Design) este o
metod de descompunere a arhitecturii unui sistem software cu scopul obinerii
modularizrii acestuia. OOD se bazeaz pe programarea orientat pe obiect,
implicit pe obiectele pe care orice sistem sau subsistem le manipuleaz. Se
poate spune c OOD este relativ independent fa de limbajul de programare
folosit (J ava, C++).
Pentru construirea unui design bun al sistemelor software, trebuie
respectate mai multe principii de baza ale OOD, respectarea acestora putnd fi
privit ca o modalitate de rezolvare a acestor probleme.
5.1. Pri ncipiul Deschis nchis
Principiul Deschis nchis (in engl. Open Close Principle, OCP), a fost
formulat de ctre Bertrand Meyer n cadrul unui articol n 1988, astfel:

"Orice entitate software (clase, module, funcii, etc) ar trebui sa fie
deschis pentru extindere, i nchis pentru modificare." (Software
entities should be open for extension, but closed for modification)

Prin utilizarea principiului deschis nchis se evit fragilitatea, rigiditatea si
imobilitatea piesei de soft, proiectndu-se module care "s nu se modifice
niciodat". n proiectarea sistemului de folosete abstractizarea i
polimorfismul. Cnd specificaiile sistemului se modific, comportamentul

134
modulelor se extinde prin adugarea de cod nou, fr a interveni cu modificri n
codul deja existent, care funcioneaz.
Un modul software care respect principiul deschis nchis are dou
caracteristici principale:
1. "deschis pentru extindere": comportamentul modulului
poate fi extins. Se poate obine astfel un comportament nou n
conformitate cu noile cerine ale aplicaiei.
2. "nchis pentru modificri": codul surs al modulului este
"inviolabil", nimnui nu i se permite s fac schimbri n cod.
Dei la o prima vedere cele dou cerine par contradictorii, totui
ele pot fi simultan satisfcute prin utilizarea abstractizrii.
n limbajele de programare orientate pe obiecte, se pot crea
abstractizri care sunt fixe din punct de vedere al codului, dar care
totui reprezint un grup nelimitat de posibile comportamente.
Abstractizrile sunt clasele de baz abstracte, iar grupul nelimitat de
comportamente este dat de toate clasele ce se pot deriva din acestea.
Deci, prin utilizarea abstractizrii se ndeplinete restricia impus de
OCP: modulele sunt scrise astfel nct s poat fi extinse fr a fi
modificate.
n Fig. 5.1 se prezint un exemplu foarte utilizat de proiectare a unei
aplicaii simple, n care att clasa Client ct i clasa Server sunt dou clase
concrete. Clasa Client utilizeaz clasa Server. Dac se dorete ca un obiect
Client s utilizeze un alt obiect Server, atunci clasa Client trebuie modificat
pentru a indica numele noii clase server, deci aceasta proiectare nu respect
OCP.

Fig. 5.1 Proiectare greit Client-Server

135
Fig. 5.2 prezint design-ul pentru aplicaia Server Client astfel nct s
respecte principiul deschis nchis. n acest caz, se utilizeaz o clas abstract
AbstractServer , din care se deriveaz clasa concreta Server i clasa Client
depinde de aceast clasa abstract. Obiectele Client vor folosi obiecte ale unei
clasei derivate ServerA. Dac se dorete ca obiectele Client s foloseasc
obiecte ale unei alte clase Server, atunci se creeaz, prin derivare, din clasa
abstract o nou clas concret ServerB. n acest mod, codul clasei Client
rmne nemodificat.

Fig. 5.2. Proiectare corect Client-Server

Pentru obinerea unor noi comportamente necesare extinderii aplicaiei,
trebuie doar s se deriveze din clasa abstract, clase concrete Server care
implementeaz noi comportamente.
nchidere strategic
Nici un program nu poate fi nchis 100%. [8]. Nici un program nu poate fi
nchis pentru modificri n mod total, deoarece, orict de nchis ar fi un modul,
ntotdeauna pot aprea situaii pentru care nu a fost nchis. Avnd n vedere c,
nchiderea unui modul fa de modificri nu poate fi complet, ea trebuie s fie
strategic.
nchiderea strategic presupune ca designer-ul arhitecturii sistemului s
abstractizeze partea care este cea mai susceptibil a fi extins.

136
nchiderea explicit a sistemului la modificri se obine utiliznd
abstractizarea. Clasa abstract furniznd metode care pot fi invocate dinamic i
n cadrul crora se stabilesc politicile de decizie la nivel general.
O alt metod care ajut la nchiderea sistemului se bazeaz pe abordare
data-driven, care presupune plasarea codului care se refer la deciziile de
politic volatil ntr-o locaie separat, fie ntr-un alt fiier, fie ntr-un alt obiect,
astfel c pe viitor modificrile se vor face ntr-un numr minim de locaii.
Reguli de proiectare folosite n OOD
Principiul deschis nchis este sursa unor reguli de proiectare folosite n
OOD. Acestea se refer la variabile private i variabilele globale folosite n
program:
Toate variabilele s fie private
Aceasta este dintre cele mai ntlnite convenii n OOD. Variabilele unei
clase trebuie s fie cunoscute doar n metodele definite n clasa respectiv.
Aceste variabile nu trebuie cunoscute de ctre alte clase, nici mcar de clasele
derivate. De aceea, este recomandat s fie declarate private, i nu public sau
protected.
Privit din prisma OCP, motivaia acestei convenii este urmtoarea: cnd
variabilele dintr-o clas se modific, fiecare dintre clasele care depind de acestea
ar trebui modificate. Deci, nici o funcie care depinde de o variabil, nu poate fi
nchis fa de aceasta. Datele constante (declarate const n C++sau final n
Java) pot fi publice sau protejate, fr a nclca principiul nchiderii.
n OOD, nchiderea celorlalte clase, inclusiv a claselor derivate, fa de
modificarea variabilelor dintr-o clas, poart numele de ncapsulare datelor.
Avantaje ale ncapsulrii datelor:
- securitatea datelor: acestea nu pot fi modificate din exteriorul
clasei n care sunt vizibile;
- consisten: prin modificarea variabilelor din alte clase, de ctre
diferii utilizatori pot aprea situaii de inconsisten, datorate unor
modificri care nu sunt atomice.

137
Fr variabile globale
Argumentele mpotriva variabilelor globale sunt similare celor mpotriva
variabilelor publice. Nici un modul care utilizeaz o variabil global nu poate fi
nchis fa de celelalte module care modific respectiva variabil. Este posibil ca
un modul s utilizeze variabila global ntr-un mod neateptat pentru celelalte
module care o mai folosesc.
Designerul trebuie s evalueze ct din nchiderea aplicaie este "sacrificat"
n favoarea variabilelor globale i s determine dac avantajele oferite de
utilizarea variabilelor globale compenseaz dezavantajele date de utilizarea lor.
Concluzii
n multe privine acest principiu este considerat esena proiectrii orientate
pe obiecte. Avantajele care se obin de pe urma folosirii acestuia sunt reutilizarea
codului i mentenabilitatea software-ului. OCP afirm ca un design bine gndit
poate fi extins fr modificri, noile caracteristici ale sistemului adugndu-se
prin completarea de cod nou, i nu prin modificarea celui existent.
Mecanismele pe care se sprijin acest principiu sunt abstractizarea i
polimorfismul.
Faptul ca se programeaz ntr-un limbaj orientat pe obiecte nu duce
automat la concordan / conformitate cu OCP, ci este necesar ca designerul s
aplice abstractizarea pe acele pri ale programului care sunt susceptibile de a fi
modificate.
Crearea abstractizrilor i apoi derivarea claselor concrete din aceste
abstractizri, duc la obinerea unor module deschise pentru extindere i nchise
pentru modificare. Mecanismul care asigura crearea acestor clase derivate este
motenirea, iar principiul substituiei al lui Liskov este cel care ghideaz designul
acestor ierarhii de clase.

5.2. Principiul substituiei Liskov
Principiul substituiei al lui Liskov (Liskov Substitution Principle, LSP) a fost
enunat n literatura de specialitate astfel:

138
Funciile care utilizeaz pointeri sau referine ctre clasele de baz,
trebuie s poat utiliza obiecte ale claselor derivate din clasa de baz n
mod transparent [Riel 1996].
Doar atunci cnd obiectele claselor derivate pot nlocui complet obiecte ale
claselor de baz, codul poate fi reutilizat, atingndu-se astfel scopul OCP
(obinerea unui cod reutilizabil, prin extindere i nu prin modificare); deci LSP
poate fi interpretat ca un mijloc de verificare a codului, din punctul de vedere al
obinerii unui design n acord cu OCP.
Acest principiu creeaz ierarhii de clase care se conformeaz OCP. S
presupunem c exist o metod care nu se conformeaz LSP, atunci acea
metod utilizeaz un pointer sau o referin ctre clasa de baz, i n acelai
timp "tie", conform presupunerii de mai sus, despre toate clasele derivate din
clasa de baz. O astfel de metod ncalc OCP deoarece trebuie modificat ori
de cate ori o nou clas derivat din clasa de baz este creat.
Exemple pentru ilustrarea LSP: Fie o clas Rectangle:
public class Rectangle {
private double width;
private double height;

public double getHeight() {
return height;
}
public void setHeight(double height) {
this.height = height;
}
public double getWidth() {
return width;
}
public void setWidth(double width) {
this.width = width;}}

139
Att n C++ ct i n Java, motenirea se bazeaz pe modelul relaional ISA.
Modelul relaional ISA descrie o relaie strict ntre clase, n care membrii unei
clase formeaz o submulime a unei alte clase. Modelul ISA (is a) pune n
eviden c un obiect (RombA din Fig. 5.3.) care aparine unei subclase (clasa
Romb din Fig. 5.3), aparine simultan tuturor super-claselor (deci RombA este o
instan a lui Romb, dar este n acelai timp instan i a claselor Patrulater si
Poligon )
Utilizarea modelului ISA este considerat ca fiind o tehnic de baz n
Analiza Orientat pe Obiecte (Object Oriented Analysis, OOA).

Fig. 5.3. Modelul relaional ISA

n continuarea exemplului de mai sus, s presupunem c la un moment dat,
n decursul dezvoltrii unor noi aplicaii, proiectantul are nevoie s utilizeze i
ptrate. Deoarece un ptrat este un dreptunghi cu toate laturile egale, putem
modela clasa Square prin derivare din clasa Rectangle, n conformitate cu
modelul ISA relationship. Dar acest mod de a gndi, poate duce la anumite
probleme pe care le vom ntmpina cnd trecem efectiv la scrierea codului.

140
Prima problem, i cea mai important, este legat de variabilele heigth i
width; pentru a defini un ptrat nu avem nevoie i de lime si de nlime (deci
de amndou), dar clasa Square le va moteni pe amndou. O problem
secundar este legat de folosirea eficient a memoriei, mai ales dac se
utilizeaz sute de obiecte ale clasei Square.
Dar trecnd peste acest aspect al eficienei memoriei utilizate, o problem
important este cea generat de existen celor dou metode setWidth i
setHeight. n primul rnd, aceste metode sunt inadecvate pentru clasa Square,
deoarece dimensiunile unui ptrat sunt egale. Iat deci o problem de design,
care totui poate fi depit dac modificm codul celor dou metode astfel:
cnd se seteaz "limea" unui obiect Square, "nlimea" va fi ajustat n mod
corespunztor, i reciproc. n acest mod un obiect Square i pstreaz
proprietile matematice.
public class Square extends Rectangle{
public void setWidth(double width) {
super.setWidth(width);
super.setHeight(width);
}

public void setHeight(double height) {
super.setHeight(height);
super.setWidth(height);
}
}
Dar dac pentru a deriva, trebuie modificat clasa de baz, nseamn ca
aceasta are o problem de proiectare. Mai mult, acest lucru reprezint o
nclcare a OCP, deoarece programul ar trebui sa fie nchis pentru modificri.
Consistena unui model
n acest moment, exist dou clase, care n aparen funcioneaz
corespunztor. Square i Rectangle, fiecare modeleaz corespunztor obiectele

141
matematice ale cror nume le poart (ptrat i dreptunghi). n aparen, se poate
spune c sistemul are un comportament consistent.
Se poate trage concluzia c modelul este auto-consistent i corect. Dar
aceast concluzie ar fi o eroare deoarece un model care este auto-consistent
nu este n mod necesar consistent i cu toi utilizatorii si.
S considerm urmtoarea funcie:
void g(Rectangle r)
{
r.setWidth(5);
r.setHeight(4);
assert ((r.getWidth() * r.getHeight()) == 20) ;
}
n mod evident aceasta metod funcioneaz corespunztor pentru
Rectangle, dar pentru Square genereaz o aseriune fals. Aceasta este o
problem grav. Desigur, programatorul care a scris aceast metod a fcut o
presupunere ndreptit i anume c modificarea limii unui dreptunghi las
nlimea acestuia neschimbat. Funcia g(Rectangle) este un exemplu de
funcie care accept referine ctre Rectangle dar care nu funcioneaz
corespunztor pentru obiectele din clasa Square. Acest tip de funcii ncalc
principiul substituiei al lui Liskov.
Validitatea nu este intrinsec
Cazul expus mai sus impune o concluzie important: validitatea unui model
nu poate fi considerat semnificativ dect ntr-un anumit context. Un model
izolat nu poate fi apreciat din punct de vedere al validitii lui. Validitatea unui
model se exprim n termenii clienilor si.
Spre exemplu, n cazul de mai sus cnd s-a examinat versiunea final a
claselor Square i Rectangle, n mod izolat, s-a ajuns la concluzia c sunt
consistente i valide. Totui, examinndu-le din punctul de vedere al unui
programator care a fcut respectiva presupunere n legtur cu clasa de baz, s-
a ajuns la concluzia c modelul este greit.

142
Deci, pentru aprecierea unui proiect, analiza trebuie s fie fcut ntr-un
context i nu n mod izolat. Design-ul trebuie vzut din perspectiva utilizatorilor
acestuia; ei lucreaz pe baza unor presupuneri rezonabile asupra modului de
funcionare a modelului.
Trebuie analizat de ce modelul claselor Square i Rectangle, care prea
corect, nu a funcionat. Nu este ptratul un dreptunghi? Nu a funcionat relaia
modelului ISA, orice obiect al clasei Square aparine sau nu i clasei Rectangle?
Un ptrat poate fi un dreptunghi, dar din punct de vedere strict matematic.
Un ptrat ca obiect al clasei Square nu este un obiect Rectangle, deoarece
comportamentul unui obiect Square nu este consistent cu comportamentul unui
obiect Rectangle, iar clasele tocmai acest aspect trebuie sa-l modeleze:
comportamentul .
LSP accentueaz faptul c n OOD, modelul relaional ISA se ocup de
comportament. Prin comportament se nelege comportamentul public,
extrinsec, cel pe care se bazeaz clienii, i nu comportamentul privat, intrinsec
al obiectului. Spre exemplu, autorul funciei g(), de mai sus, s-a bazat pe faptul
c pentru un obiect al clasei Rectangle, limea i nlimea variaz independent.
Aceast independen a celor dou variabile este un comportament public
extrinsec pe care, probabil, conteaz i ali programatori.
Pentru ca LSP s fie valabil, implicit OCP, toate clasele derivate trebuie
s respecte comportamentul pe care clienii l ateapt de la clasa de baz
pe care o utilizeaz.
Design prin contract
Exist o strns relaie ntre LSP i conceptul de Design by contract, aa
cum a fost definit de Bertrand Meyer [1]. Utiliznd aceast schem, metodele
claselor declar precondiii i postcondiii. O metod se execut dac
precondiiile sunt adevrate. La terminarea metodei, aceasta garanteaz c
postcondiiile vor fi adevrate.
Aplicnd pe exemplul de mai sus, putem spune c postcondiia metodei
setWidth(double w) n clasa Rectangle este:

143
assert((width ==w) && (height ==old.height))
Regula care se aplic precondiiilor i postcondiiilor la derivare, aa cum a
formulat-o B. Meyer este urmtoarea:
Cnd se redefinete o metod n clasa derivat, precondiia se nlocuiete
prin una mai "slab", iar postcondiia prin una mai "puternic".
Cu alte cuvinte, utilizarea unui obiect se face prin intermediul interfeei
clasei de baz i utilizatorul cunoate doar precondiiile i postcondiiile acestei
clase. Deci, obiectele claselor derivate nu trebuie s impun precondiii mai
puternice dect ale clasei de baz, ele trebuie s accepte orice precondiie pe
care clasa de baz o accept. De asemenea, clasele derivate trebuie s se
conformeze tuturor postcondiiilor clasei de baz, comportamentul i ieirile lor
nu trebuie s ncalce nici una din constrngerile impuse de superclas.
Postcondiia din metoda setWidth(double w) din clasa Square este mai puin
restrictiv dect cea din metoda setWidth(double w) din clasa Rectangle,
deoarece nu se conformeaz celei din superclasa, mai exact nu respect i
condiia: (height == old.height). Deci, metoda setWidth(double w) din clasa
Square ncalc contractul clasei de baz.
Concluzii
Respectarea OCP are ca efect obinerea unor aplicaii mai robuste, cu o
mai bun mentenabilitate i reutilizabilitate a codului. Principiul substituiei este o
caracteristic important a acelor programe/aplicaii care respect OCP,
deoarece tipurile derivate pot nlocui tipurile de baz astfel nct codul claselor
de baz poate fi oricnd reutilizat i codul claselor derivate oricnd modificat.
Substituia claselor de baz cu obiecte ale claselor derivate este posibil,
deoarece clasele derivate respect comportamentul extrinsec al superclaselor.
Obiectele subclaselor, conform LSP, se comport ntr-o manier consistent cu
promisiunile fcute de superclas n API. Astfel, claselor client li se furnizeaz
un comportament stabil, pe care se pot baza.

144
Mecanismul prin care se implementeaz o structur ierarhic conform cu
OCP i LSP este prezentat n capitolul urmtor, Principiul Inversrii
Dependenelor.
5.3. Principiul Inversrii Dependenelor
Structura unui program, rezultat n urma respectrii OCP i LSP, este
generalizat n principiul inversrii dependenelor (The Dependency Inversion
Principle, DIP), formulat astfel:
A. Modulele de pe nivelele superioare nu trebuie s depind de modulele de
pe nivelele inferioare. Modulele de pe cele dou nivele ar trebuie s depind de
nite abstractizri.
B. Abstractizrile nu trebuie s depind de detalii. Detaliile trebuie s depind
de abstractizri.
Acest principiu este mecanismul de realizare a OCP, deoarece prin
aplicarea DIP se creeaz o arhitectur a sistemului nchis pentru modificri
(abstractizrile de pe nivelul superior) i deschis pentru extindere (clase
concrete de pe nivelul inferior), deci modulele sunt reutilizabile i stabile.
Metodele tradiionale de dezvoltare a software-ului (programarea
structural) creeaz structuri n care modulele de pe nivelele superioare depind
de cele de pe nivelele inferioare i abstractizrile depind de detalii de
implementare. Termenul de "inversare" din titulatura principiului, se folosete
pentru a evidenia structura dependenelor inversat fa de metodele
procedurale tradiionale.
n general, modulele de pe nivelul superior conin logica aplicaiei, ele dau o
identitate aplicaiei, i totui ele depind de modulele de pe nivelul inferior, fiind
afectate direct de orice modificare n nivelul de care depind. Normal este ca
nivelul superior s impun schimbri n nivelul inferior, modulele de pe nivelul
superior s fie independente fa de cele de pe nivelul inferior. Astfel, DIP
impune ca, pe de o parte, ntr-o ierarhie de clase, clasa din care se deriveaz
s nu cunoasc nici una dintre subclasele sale, iar pe de alta parte,
modulele care implementeaz detaliile depind de abstractizri, i nu invers.

145
Fie exemplul din Fig. 5.4 al unui program alctuit din trei module. Modul de
pe nivelul 1, Client, implementeaz logica programului, iar modulele de pe nivelul
2 realizeaz anumite operai, conform deciziilor luate de modulul Client. Aa cum
se observ i din figur, modulul Client este dependent de modulele de pe nivelul
2. Dac modulele de pe nivelul 2 mai pot fi reutilizate n aplicaii n care s
ndeplineasc aceleai funcii, modulul de pe nivelul 1 este nereutilizabil el fiind
strict dependent de modulele de pe nivelul inferior, cel mult poate fi reutilizat ntr-
un context care s implice celelalte dou module.

Fig. 5.4. Structura unui program alctuit din trei module

Situaia din exemplu de mai sus poate fi caracterizat prin observaia c
modulul de pe nivelul superior (logica programului) este dependent de modulele
de pe nivelul inferior, module pe care le controleaz. Dac modulul Client poate fi
modificat astfel nct s devin independent de celelalte module, atunci el poate
fi reutilizat fr probleme, n alte programe de aceeai natur. OOD ne pune la
dispoziie un mecanism pentru a face acest lucru: inversarea dependenelor.
Dac sistemului din Fig. 5.4 i se aplic principiul inversrii dependenelor,
conform cruia modulele de pe nivele superioare nu depind de modulele de pe
nivelele inferioare ci de nite abstractizri, iar abstractizrile nu depind de
detalii, se obine diagrama de clase din Figura 5.5. Astfel, n aceast proiectare
apar dou clase abstracte "AbstractReader" i "AbstractWriter". Modulul Client
depinde de aceste dou abstractizri. n acest fel a fost nlturat dependena

146
clasei Client fa de clasele Reader i Writer. Dependena a fost inversat, n
sensul c att clasa Client ct i clasele Reader i Writer depind de cele dou
clase abstracte.

Fig. 5.5. Structura unui program alctuit din trei module n urma aplicrii DIP

Cu acest nou design, clasa Client poate fi reutilizat i n alte contexte,
independent de clasele concrete Reader i Writer. Cu uurin se pot aduga noi
clase derivndu-se din clasele abstracte AbstractReader, respectiv
AbstractWriter; clasa Client nu va depinde de nici una din clasele nou create prin
derivare. n acest fel clasa Client a devenit mobil.
n general, prin utilizarea principiul inversrii dependenelor se obine o
structur organizat pe nivele, cu modulele reutilizabile pe cele dou nivele.
Modulele de pe nivelul inferior sunt reutilizate n forma librriilor. Dac modulele
de pe nivelul superior ar depinde de cele de pe nivelul inferior, reutilizarea lor n
alt context este dificil. Conformndu-se DIP, dac ele sunt independente, atunci
reutilizarea este uor de realizat.

147

Organizarea pe nivele
Conform lui Booch [Booch, 1996]:
"[] Toate arhitecturile orientate pe obiect, bine structurate au nivele clar
definite, fiecare nivel oferind un set de servicii prin intermediul interfeei sale."
O interpretare simplist a acestei afirmaii ar putea duce la realizarea unei
arhitecturi n care dependenele ar fi pasate de la un nivel la altul, avnd n
vedere c dependena este tranzitiv.(Fig. 5.6).
Nivelul Deciziilor depinde de Nivelul Mecanismelor, care depinde de
Nivelul Serviciilor, deci Nivelul Deciziilor depinde de Nivelul Serviciilor
(tranzitivitatea dependenelor).

Fig. 5.6 Tranzitivitatea dependenelor
O structur corect este cea n care nivelele inferioare ofer servicii prin
intermediul interfeelor abstracte. (Fig. 5.7).

Fig. 5.7 Structur corect n care nivelurile sunt independente unele fa de
altele i dependente doar de interfee

148
Interfaa reprezint totalitatea serviciilor pe care nivelul inferior le ofer
nivelului superior. Deci, toate nivelele sunt independente unele fa altele, i
dependente doar de clasele abstracte. Nu se mai transfer dependenele de la
un nivel la altul, i orice modificare ce se efectueaz pe un nivel inferior nu
afecteaz nivelul superior. Cu alte cuvinte, conform acestui model, Nivelul
Deciziilor este complet independent de nivelele inferioare, putnd fi reutilizat n
orice alt context n care se definete un nivel inferior bazat pe interfaa Nivelului
Mecanismelor.
Deci, inversnd dependenele, se creeaz o structur care are toate
calitile unui bun design: flexibilitate, durabilitate i mobilitate.
Comparaie ntre o arhitectura procedural i una OO
Comparaia ntre o arhitectur procedural i una orientat-obiect are ca
scop s pun n eviden avantajele i dezavantajele fiecreia. n Fig. 5.8 este
schiat arhitectura unui sistem procedural, n Fig. 5.9 este schiat arhitectura
unui sistem orientat pe obiecte.
Dezavantajele unei arhitecturi procedurale sunt:
- nu exist o separare clar a nivelului decizional al aplicaiei de nivelul
mecanismelor de implementare i de cel al detaliilor;
- orice modificare n modulele de pe nivelul inferior duce la modificri n
modulele de pe nivelul superior.
-

Fig. 5.8. O arhitectur a unui sistem procedural


149

Fig. 5.9. O arhitectur a unui sistem OO

Aceste dezavantaje sunt nlturate n cadrul unei arhitecturi OO, care
respect principiile OCP, LSP i DIP:
- prin organizarea pe nivele se separ clar nivelul decizional de cel al
implementrii detaliilor,
- prin inversarea dependenelor, obinndu-se o arhitectur alctuit din
piese de software flexibile, mobile i uor de reutilizat, deci toate atributele unui
bun design.
Dup cum se observ, ntr-o arhitectur OO, modulele care au detalii de
implementare nu depind de un alt modul, ci numai de abstractizri.
Reguli de proiectare folosite n OOD
Prin utilizarea PID, s-a ajuns la cteva rezultate practice. Aplicarea acestora
de ctre proiectanii de software, contribuie la facilitarea muncii lor i asigur
obinerea unui design de calitate.
Utilizarea interfeelor (claselor abstracte) pentru a evita legturile directe
ntre clasele concrete (Fig.5.10)


150

Fig. 5.10. O arhitectur care utilizeaz interfeele (clase abstracte) pentru a evita
legturile directe ntre clasele concrete

Utilizarea interfeelor contribuie la obinerea unui cod stabil pentru clasa
concret Client. O clasa abstract este mai puin probabil s fie modificat, pe de
alt parte o clas abstract este mai uor de extins/modificat. Totui, trebuie avut
n vedere c a modifica o abstractizare contravine OCP, care se bazeaz pe
stabilitatea abstraciunii.
Regul de baz - Evitarea dependenelor tranzitive prin utilizarea
interfeelor!
Concluzii
DIP este sursa multor beneficii ale tehnologiei orientate pe obiect; prin
aplicarea lui se obin module reutilizabile. Este foarte important pentru
construcia codului, ca acesta s fie rezistent, robust i elastic la modificri.
Deoarece abstractizrile i detaliile aplicaiei sunt izolate unele de altele, codul
este mult mai uor de ntreinut (mentenabilitate crescut).
Cheia din principiul inversrii dependenelor este utilizarea abstractizrii, la
fel ca i n OCP. Detaliile de implementare sunt izolate de unele de altele, ntre
ele fiind interpuse abstractizrile (care sunt clase stabile), astfel o modificare
efectuat ntr-un modul ce implementeaz detalii nu se propag n ntreg
sistemul. Izolarea claselor care implementeaz detalii i dependena acestora
doar de abstractizri contribuie la obinerea unor clase care pot fi utilizate, cu
uurin, n alte aplicaii.

151
Privit din perspectiva principiilor prezentate n seciunile anterioare, se poate
spune c OCP este scopul, DIP asigur mecanismul de ndeplinire a scopului,
iar LSP este modalitatea de verificare a mecanismului.
Care este scopul unui design conform OCP ?
Obinerea unor entiti software care s fie deschise pentru extindere dar
nchise la modificri, n acest timp pstrndu-se calitile unui bun design:
flexibilitate, mobilitate i reutilizabilitate. DIP specific modalitatea de atingerea
acestui scop: ntr-o ierarhie de clase, clasa din care se deriveaz nu cunoate
nici una dintre subclasele sale i modulele care implementeaz detaliile depind
de abstractizri, i nu invers. Iar prin LSP se asigur o msura a calitii
motenirii, verificndu-se ca prin motenire s se obin subclase care au
aceleai proprieti ca i superclasa.
Aceste trei principii sunt strns legate ntre ele: dac este nclcat unul
dintre principiile LSP sau DIP, atunci implicit este nclcat OCP.

5.4. Stabilitate. Principiul dependenelor stabile
Aa cum s-a artat n cadrul subcapitolului 1.2. Probleme ale software-ului,
interdependena reprezint una dintre cauzele pentru care un design este rigid,
imobil i dificil de reutilizat. Totui, interdependena este necesar dac modulele
implicate n design "colaboreaz". Ca urmare exist tipuri de dependen utile i
tipuri de dependen indezirabile.
n acest paragraf se propune un model de design n care dependenele sunt
toate utile i se descrie un set de indicatori pentru msurarea conformitii
designului cu modelul propus.
Aceti indicatori msoar stabilitatea software-ului. Stabilitatea este nsi
esena designului software. Cnd se proiecteaz un sistem software, se
dorete ca acesta s fie stabil atunci cnd este modificat. Acesta este i scopul
OCP: obinerea unor sisteme stabile. n acest capitol vom analiza modalitatea n
care conceptul de stabilitate se rsfrnge asupra relaiilor dintre pachete, n
cadrul structurilor aplicaiilor de mari dimensiuni.

152
Stabilitate i Dependen. Dependene utile
Se consider exemplul din subcapitolul 5.3 (Principiul inversrii
dependenelor), cel al unui sistem alctuit din 3 module: Client, Reader, Writer
(Fig. 5.4 ). Din analiza detaliat a acestei structuri, a rezultat c acest design
este rigid, fragil i dificil de reutilizat, din cauza faptului c modulul care
implementeaz logica programului (modulul Client), este dependent de modulele
de pe nivelul inferior. Pentru nlturarea acestei dependene, se aplic DIP i se
obine o structur (Fig. 5.5 ) n care modulul de pe nivelul superior depinde de
nite abstractizri. Designul astfel obinut, este robust, mentenabil i uor de
reutilizat.
Dependene utile
Totui, nu toate dependenele au fost ndeprtate, ci doar cele care
afecteaz calitile programului. Dependenele rmase sunt nevolatile, pentru c
obiectul/modulul/clasa fa de care se manifest dependena este puin probabil
s se modifice. Probabilitatea ca aceste clase abstracte, AbstractReader i
AbstractWriter, s se modifice este foarte mic, spunem despre ele c au o
volatilitate sczut.
Deoarece clasa Client depinde de module nevolatile, este puin predispus
la schimbri. Aceast situaie ilustreaz foarte bine principiul deschis nchis:
clasa Client este deschis la extinderi, deoarece putem crea noi versiuni de
clase concrete derivate din AbstractReader i AbstractWriter pe care Client s le
acioneze, i este nchis pentru modificri deoarece nu trebuie modificat
pentru a face aceste extinderi.
Putem afirma n consecin, c o dependen util este o dependen fa
de un modul/clas cu o volatilitate sczut. Cu ct volatilitatea este mai sczut,
cu att dependena este "mai bun". O dependen este indezirabil cnd se
manifest fa de un modul volatil. Cu ct modulul/clasa fa de care se
manifest dependena este mai volatil, cu att dependena este "mai nedorit".

153
Stabilitatea
Volatilitatea unui modul depinde de mai multe tipuri de factori. Spre
exemplu, exist programe care sunt publicate cu numrul de versiune; module
care conin numrul versiunii sunt volatile, deoarece sunt modificate ori de cte
ori o nou versiune este lansat. Pe de alt parte, alte module sunt modificate
mult mai rar. Volatilitatea depinde i de presiunea pieei i cererile clienilor. Un
modul este sau nu posibil s fie modificat, dac conine sau nu ceva ce clientul
dorete s schimbe. Acest tip de factori sunt greu de apreciat.
Exist, totui, un factor care influeneaz volatilitatea i care poate fi
msurat: stabilitatea. Stabilitatea, n sensul general acceptat, se definete ca
fiind "greu de modificat".
Stabilitatea nu este o msura a probabilitii de a modifica un modul, ci a
dificultii de a-l modifica.
Deci, modulele care sunt mai greu de modificat, sunt mai puin volatile.
n exemplul amintit mai sus, clasele abstracte AbstractrReader i
AbstractWriter sunt stabile. Caracteristicile care fac aceste clase stabile, sunt:
sunt independente, nu depind de nimic i nimic nu poate fora o
schimbare a lor. Se numesc clase independente acele clase care nu
depind de nimic altceva.
de aceste clase depind alte clase (Client, Reader i Writer depind de
clasele abstracte din exemplu). Clasele derivate sunt clase dependente.
Cu ct vor exista mai multe clase derivate, cu att mai greu va fi s
modificm clasele de baz. Dac vom dori s modificm cele dou clase
abstracte, va trebui s modificm i clasele derivate. Deci, exist motive
serioase pentru care nu vom modifica cele dou clase, mbuntindu-le
astfel stabilitatea. Clasele de care depind multe alte clase, se numesc
responsabile.
Clasele responsabile tind s fie stabile deoarece orice modificare a lor are
un impact puternic asupra claselor dependente. Cele mai stabile clase sunt
cele care sunt independente i responsabile, deoarece asemenea clase nu
au nici un motiv s se modifice, i au multe motive s nu se modifice.

154
Principiul dependenelor stabile
ntr-un proiect (design), dependena dintre pachete ar trebui s fie n sensul
creterii stabilitii pachetelor. Un pachet ar trebui s depind de pachete mai
stabile dect el.
Un design nu poate fi complet static, un anume grad de volatilitate este
necesar dac se dorete realizarea mentenanei. Acest lucru se obine dac
designul se conformeaz principiului nchiderii generale (Common Closure
Principle, CCP). Prin utilizarea acestui principiu, se creeaz pachete care sunt
sensibile doar la anumite tipuri de modificri. Aceste pachete sunt proiectate s
fie volatile. Modificrile n aceste pachete sunt ateptate i prevzute.
Nici un pachet, despre care tim c va fi volatil, nu ar trebui s aib ntre
dependeni pachete greu de modificat. n caz contrar, i pachetul volatil va fi greu
de modificat. n conformitate cu principiul dependenelor stabile (The Stable
Dependencies Principle, SDP), pachetele care sunt proiectate s fie instabile
(uor de modificat) nu au ca dependeni pachete care au o stabilitate mai mare
dect a lor (mai greu de modificat).
Indicatori ai stabilitii
O modalitate de a msura stabilitatea unui pachet este numrarea
dependenelor care "intr" i "ies" din pachet. Aceasta ne va ajuta la calcularea
stabilitii poziionale a pachetului.
Se definesc urmtorii indicatori:
Ca : dependene aferente: Numrul claselor din afara pachetului care
depind de clasele din acest pachet;
Ce : dependene eferente: Numrul de clase din cadrul pachetului care
depind de clase din afara pachetului;
I : Instabilitatea:
Ce Ca
Ce
I

Acest indicator are valori n domeniul [0,1].
I = 0 indic un grad maxim de stabilitate a pachetului;
I = 1 indic un grad maxim de instabilitate a pachetului.

155
Indicatorii Ca i Ce sunt calculai prin numrarea claselor din exteriorul
pachetului n cauz care au relaii de dependen cu clasele din interiorul
pachetului.
S considerm urmtorul exemplul din Fig. 5.11., n care sgeile punctate
reprezint dependenele ntre pachete. Relaiile dintre clasele pachetelor arat
care este natura dependenei, modul cum este implementat aceasta (motenire,
agregare, asociere).
Calcularea stabilitii pachetului din centrul diagramei.
Observm ca exist 4 clase exterioare pachetului care sunt n relaii cu
clasele interioare pachetului, deci Ca=4. Mai mult, exist 3 clase exterioare
pachetului central de care depind clasele interioare, deci Ce=3.

7
3
ce Ca
Ce
I

Cnd I=1, nici un alt pachet nu depinde de pachetul curent, dar el depinde
de alte pachete. Acesta este gradul maxim de instabilitate al unui pachet;
pachetul este iresponsabil i dependent.
Cnd I=0, pachetul curent nu depinde de nici un alt pachet, dar de el depind
alte pachete. Este responsabil i independent. Un astfel de pachet are un grad
maxim de stabilitate. Din cauza pachetelor dependente, pachetul curent este
dificil de modificat, i nu depinde de alte pachete care ar putea fora o modificare
a acestuia.
Principiul dependenelor stabile afirm c indicatorul I al unui pachet ar
trebui s fie mai mare dect indicatorul I al pachetelor dependente de el; I ar
trebuie s descreasc n sensul dependenei.
Nu toate pachetele ar trebui s fie stabile. Dac toate pachetele din
sistem sunt stabile, atunci sistemul nu ar mai putea fi modificat. Sistemul trebuie
proiectat astfel nct unele pachete s fie stabile iar altele instabile. Fig. 5.12
arat situaia ideala pentru un sistem de trei pachete.

156

Fig. 5.11. Exemplu de calculare a gradului de stabilitate al unui pachet

Fig. 5.12. Situaia ideal din punct de vedere a stabilitii pentru un sistem cu trei
pachete
Pachetele care prezint o probabilitate mai mare de a fi modificate sunt
aezate pe un nivel superior, iar cele care sunt stabile sunt aezate la baz.
Pentru acest mod de aranjare a pachetelor, orice sgeat direcionat n sus
nseamn o nclcare a principiului dependenelor stabile.
O parte din software-ul unei aplicaii nu trebuie s se modifice foarte des, i
anume logica de nivel nalt a aplicaiei, deciziile de design. Nu este de dorit ca
aceste decizii arhitecturale s fie volatile, deci software-ul care ncapsuleaz

157
deciziile de nivel nalt, ar trebui plasat n cadrul unor pachete stabile. Pachetele
instabile ar trebui s conin doar acele pri de software, despre care se tie c
este probabil s fie modificate.
Dac logica aplicaiei este plasat n pachete stabile, atunci codul surs al
acestor pachete va fi dificil de modificat. Acest fapt, ar putea face desing-ul
inflexibil. OCP ofer soluia pentru a face un pachet s fie flexibil i totui s aib
un grad maxim de stabilitate (I=0),. Conform acestui principiu este posibil i este
oportun crearea unor clase care s fie suficient de flexibile pentru a fi extinse
fr modificri. Acest lucru se realizeaz prin utilizarea claselor abstracte.
Principiul abstractizrilor stabile
Pachetele care au grad maxim de stabilitate ar trebui s fie maxim
abstracte. Pachetele instabile ar trebui s fie concrete. Abstractizarea unui
pachet ar trebui s fie direct proporional cu stabilitatea sa.
Principiul abstractizrilor stabile (The Stable Abstractions Principle, SAP)
stabilete o relaie ntre stabilitate i abstractizare afirmnd c un pachet
stabil ar trebui s fie i abstract astfel nct stabilitatea sa s nu-l mpiedice s fie
extins. Pe de alt parte, un pachet instabil ar trebui s fie concret deoarece
instabilitatea permite codului s fie cu uurin modificat.
Dac un pachet se dorete a fi stabil, ar trebui s fie alctuit din clase
abstracte astfel nct s poat fi extins. Pachetele stabile care pot fi extinse sunt
i flexibile i nu constrng design-ul.
Spre deosebire de principiul inversri dependinelor care este un
principiu pentru clase, principiile dependenelor stabile i al abstractizrilor
stabile sunt principii care se aplic pachetelor.
Msurarea gradului de abstractizare a unui pachet se face utiliznd
indicatorul A, care se calculeaz ca fiind raportul dintre numrul de clase
abstracte dintr-un pachet i numrul total de clase din pachet.
Clase NumarTotal
Abstracte NumarClase
A
Valorile indicatorului A sunt din intervalul [0,1].

158
Dac A=0 : nseamn c un pachet nu are clase abstracte.
Dac A=1 : nseamn ca pachetul n cauz conine numai clase
abstracte.
Relaia dintre stabilitate, I, i gradul de abstractizare, A (Fig. 5.13)
Pentru stabilirea relaiei dintre stabilitate, msurat de indicatorul I, i
gradul de abstractizare, msurat cu indicatorul A, se realizeaz un grafic n care
A se pune pe axa vertical, iar I pe axa orizontal. Pachetele care au o stabilitate
i o abstractizare maxim se gsesc n punctul (0,1). Pachetele cu gradul de
instabilitate cel mai mare i concrete se gsesc n punctul (1,0).
Nu se poate impune tuturor pachetelor s se gseasc fie la (0,1) fie la (1,0)
deoarece pachetele au grade diferite de stabilitate i abstractizare , aa nct se
admite c exist un loc geometric al punctelor care definesc o poziie rezonabil
pentru pachete n planul A/I. Se deduce care este acest loc geometric, gsind
ariile n care pachetele nu ar trebui s se gseasc, adic zonele de
excluziune.

Fig. 5.13. Relaia dintre stabilitate, I, i gradul de abstractizare, A. Zonele de
excluziune.

Se consider un pachet n zona determinat de A=0 i I=0, acesta va fi un
pachet stabil i concret. Un astfel de pachet nu este de dorit deoarece este
rigid, nu poate fi extins pentru c nu este abstract i este foarte dificil de
modificat pentru c este stabil. Deci, nu este de dorit ca toate pachetele s se

159
gseasc n zona punctului (0,0). Zona de vecintate a punctului (0,0) este o
zon de excluziune.
Se consider un pachet n zona determinat de A=1 i I=1. Un astfel de tip
de pachet este de asemenea indezirabil (poate chiar imposibil) deoarece are
grad maxim de abstractizare i totui nici un alt pachet nu depinde de el. i acest
tip de pachet este rigid, pentru c abstractizrile sunt imposibil de extins. Deci,
un pachet in aceast zon este fr sens. Zona din jurul punctului (1,1) este o
zon de excluziune.
Fie pachetul din A=0.5 i I=0.5. Acest pachet este parial extensibil pentru
c este parial abstract; este parial stabil deci extinderile nu duc la instabilitate
maxim. Un astfel de pachet pare echilibrat, deoarece stabilitatea i
abstractizarea se compenseaz reciproc. Deci, zona n care A=I nu este o zon
de excluziune. Pe linia dintre (0,1) i (1,0) se gsesc pachetele a cror
abstractizare este compensat de ctre stabilitate.
Un pachet de pe aceast dreapt nu este "prea abstract" pentru stabilitatea
sa i nici "prea instabil" pentru abstractizarea sa; are un numr "potrivit" de clase
concrete i abstracte, proporional cu dependenele aferente i eferente. Totui
cel mai favorabil punct n care se poate gsi un pachet este la unul din cele dou
capete ale acestei drepte. n practic, nu exist un astfel de caz ideal. Un pachet
are caracteristici bune, dac este plasat pe aceast dreapt sau ct mai aproape
de ea.
Distana fa de Secvena Principal
Considernd c pe dreapta numit Secvena Principal, se gsesc
pachetele care au caracteristicile ideale, putem crea un indicator care msoar
distana pachetului curent faa de cazul ideal.

2
1
I A
D
unde :

160
- D = Distana dintre punctul n care se gsete pachetul fa de
dreapta numit secvena principal;
- A =gradul de abstractizare;
- I =gradul de stabilitate.
Acest indicator are valori cuprinse n intervalul [0, ~0.707]. (Putem
normaliza acest indicator s aib valori cuprinse n intervalul [0,1].)
Fiind dat acest indicator, un design poate fi analizat din punctul de vedere al
conformrii lui la dreapta principal . Pentru un pachet dat, D poate fi calculat.
Orice pachet pentru care indicatorul D nu are o valoare apropiat de zero trebuie
reexaminat i restructurat.
Concluzii
Indicatorii descrii mai sus msoar conformitatea unui design fa de un
model de dependene i abstractizri. Aceti indicatori ncearc s msoare
calitatea unui design din anumite puncte de vedere, fr a avea pretenia de
adevr absolut. n funcie de dorine de la un design, se pot defini i folosi diveri
indicatori.


161

6

Motto:
abloanele de proiectare software te ajuta s
nvei mai mult din succesele altora, dect din
propriile eecuri
[Mark J ohnson]

abloane software de proiectare
6.1. Elementele unui ablon de proiectare software
n ingineria software, prin ablon de proiectare (n englez design pattern,
prescurtat-DP) se nelege o soluie, un tipar care se aplic la un anumit tip de
probleme. Un design pattern este o descriere sau un model pentru o soluie a
problemei Un ablon nu poate fi transformat direct n cod surs. abloanele de
proiectare n OOD (Object Oriented Design) arat relaiile i interaciunile dintre
clase sau obiecte, fr a detalia clasele i obiectele care sunt implicate.
Scopul proiectrii cu abloane este acela de a face un bun design orientat
pe obiecte, i mai mult de att, un design reutilizabil (ceea ce este mai
important dect reutilizarea codului, dar adesea reutilizarea designului implic i
reutilizarea codului).
Calitatea unui design software este direct proporional cu experiena i
cunotinele anterioare ale celui care l realizeaz. Un expert reutilizeaz soluii
pe care le-a gsit n trecut i care deja i-au dovedit eficiena n probleme
asemntoare. Cnd un expert gsete o soluie pe care o consider bun, o

162
refolosete. abloanele de proiectare rezolv probleme specifice de design,
fcnd proiectul OO mai flexibil, elegant i reutilizabil. Design patterns ajut
designerii de software propunnd nite abloane bazate pe experiena
anterioar. Un designer care este familiarizat cu DP, le poate aplica imediat,
pentru rezolvarea unor probleme specifice, fr a fi nevoit s le redescopere.
abloanele software sunt structuri care respect principiilor de proiectare,
deoarece sunt obinute ca urmare a aplicrii acestor principii (abloanele sunt
rezultate directe ale principiilor). Cu alte cuvinte, prin utilizarea abloanelor
software n cursul proiectrii unei arhitecturi OO, se obine garania c sistemul
respect principiile prezentate n capitolul 5 al acestei lucrri, avnd i calitile
unui bun design: reutilizabil, flexibil i robust.
Lucrarea de referin pentru abloanele de proiectare este Design
Patterns: Elements of Reusable Object-Oriented Software [Gamma, 1997],
adesea se fac referiri la ea sub denumirea de GoF sau Gang-Of-Four. Autorii
propun soluii recurente la probleme comune n designul software. n cartea GoF
sunt propuse 23 de abloane de proiectare ntr-o form uor de reutilizat; aceste
abloane ncorporeaz experiena autorilor n rezolvarea problemelor de OOD.
abloanele din aceasta carte au scopul de a descrie obiectele, clasele i
modul n care acestea comunic, scopul urmrit fiind rezolvarea unei probleme
general de design ntr-un context particular.
Un ablon are patru elemente eseniale:
1. Nume: se dorete ca numele s descrie n cteva cuvinte, o
problem de design pattern, soluia i efectele ei.
2. Problema: descrie situaiile n care se aplic ablonul. Explic att
problema ct i contextul acesteia.
3. Soluia: descrie elementele care fac parte din design, relaiile
dintre ele, responsabilitile fiecrui element i colaborrile dintre acestea.
Soluia nu descrie un proiect concret specific unei situaii sau o implementare
concret, deoarece ablonul are un caracter general, referindu-se la o diversitate
de contexte. DP furnizeaz o descriere abstract a unei probleme i un

163
aranjament general al elementelor componente (clase i obiecte) care rezolv
problema descris.
4. Efecte: se refer la rezultatele aplicrii ablonului. Acestea sunt
foarte importante atunci cnd evalum alternativele i pentru a estima costurile i
beneficiile aplicrii ablonului. Efectele unui ablon se resimt i n flexibilitatea,
extensibilitatea i portabilitatea unui sistem.
ablonul identific clasele i instanele participante, rolul acestora,
colaborarea i distribuirea responsabilitilor ntre ele.

Tabel 6.1. abloanele de proiectare GoF
SCOP (Ce face ablonul)
Creaional Structural Comportamental

Cui se
Clasa Factory
Method
Adapter Interpreter
Template Method
aplic
ablonul ?
Obiect Abstract
Factory
Builder
Prototype
Singleton
Adapter
Bridge
Composite
Decorator
Facade
Proxy
Chain of
Responsability
Command
Iterator
Mediator
Memento
Flyweight
Observer
State
Strategy
Visitor

Dup scop autorii GoF au propus trei mari categorii de abloane :
abloanele creaionale
Abstract Factory furnizeaz o interfa pentru crearea familiilor de
obiecte dependente sau relaionate, fr a specifica clasele lor concrete.

164
Builder separ construcia unui obiect complex de reprezentrile sale
astfel nct procese de cosctrucie similare pot crea reprezentri diferite.
Factory Method definete o interfa pentru crearea unui obiect, dar
las subclasele s decid care clas va fi instaniat.
Prototype specific tipurile de obiecte create folosind o interfa
prototipizat i creaz noi obiecte copiind acel prototip.
Singleton asigur c o clas are numai o instan, dar furnizeaz un
punct global pentru a o accesa.

abloanele structurale
Adapter face conversia interfeei unei clase la interfaa dorit de client.
Adapter permite claselor s lucreze mpreun, ceea ce altfel n-ar fi posibil din
cauza incompatibilitii intefeelor.
Bridge decuplez o form abstract de implementarea sa asftel nct
cele dou pot fi schimbate independent.
Composite compune obiecte din arborele de structur care reprezint
pari sau ntreaga ierarhie. Composite las clienii s trateze fiecare n parte i
uniform obiectele i compunerea lor.
Decorator ataeaz n mod dinamic responsabiliti adiionale
obiectelor. Furnizeaz subclaselor o alternativ flexibil pentru extinderea
funcionalitilor.
Facade furnizeaz interfa unificat cu un set de interfee ntr-un
subsistem. Definete o interfa de nivel nalt care determin ca subsistemul s
fie mai uor de utilizat.
Flyweight folosete tehnica sharing (divizare n mod egal) pentru a
lucra cu un numr mare de obiecte mici n mod efficient.
Proxy furnizez un nlocuitor pentru alt obiect n scopul de a controla
accesul la el.


165
abloane de comportament
Chain of Responsability- permite cuplarea expeditorului unei cereri cu
destinatarul ei dnd mai mult dect unui sisngur obiect ansa de a utiliza acea
cerere. nlnuie obiecte destinatare i las cererea s treac de-a lungul irului
att timp ct un obiect o utilizeaz.
Command ncapsuleaz cererea ca un obiect lasnd prin aceasta
clieni parametrizai cu diferite cereri, coad sau tabel de cereri i suport operaii
care se pot detaa.
Interpreter dndu-se un limbaj, definind o reprezentare pentru gramatica
sa, interpretez propoziii din acel limbaj.
Iterator furnizeaz o cale de acces la elementele unui agregat de obiecte
secveniale fr a expune reprezentarea sa intern.
Mediator definete un obiect care ncapsuleaz toat mulimea de
obiecte cu care interacionez. Mediator promovez cuplajul slab pstrnd
obiectele pentru a putea fi referite n mod explicit i las s poat fi schimbat
independent interaciunea lor.
Memento fr a fi violat ncapsularea, capturez i externeaz starea
intern a unui obiect, astfel nct, obiectul poate fi restaurat mai trziu n starea
sa.
Observer - definete o dependen unu-multi ntre obiecte, astfel nct
cnd un obiect i schimb starea toate obiectele din dependena sa sunt
actualizate n mod automat.
State permite unui obiect s-i modifice comportamentul atunci cnd se
schimb starea sa intern. Obiectul va prea c-i schimb clasa.
Strategy definete o familie de algoritmi, ncapsulai fiecare i-i face
interanjabili. Strategy las algoritmul s poat fi schimbat n mod independent
de clienii care l utilizeaz.
Template Method las subclasele s-i redefineasc civa pai din
algoritm far a modifica structura algoritmului.
Visitor permite s defineti o nou operaie fr schimbarea claselor de
elemente cu care aceasta opereaz.

166
Acestea sunt cele mai cunoscute DP, dar nu sunt singurele. Lucrarea
amintit mai sus a fost publicat pentru prima dat n 1995, de atunci au aprut
i alte abloane mai mult sau mai puin cunoscute, unele noi (tratnd noi tipuri de
probleme, aprute ca urmare a dezvoltrii limbajelor OO), altele sunt variaii ale
abloanelor amintite mai sus (aplicaii ale abloanelor GoF pe cazuri particulare).

6.2. Cum rezolv abloanele problemele de proiectare
abloanele de proiectare rezolv o serie ntreg de probleme curente cu
care se confrunt proiectanii de sisteme orientate pe obiecte, n diferite moduri.
Programele orientate pe obiecte sunt constituie, evident din obiecte. Un obiect
mpachetez, asamblez la un loc, att datele ct i procedurile care opereaz
cu acele date. Procedurile se numesc metode sau operaii. Un obiect execut o
operaie n momentul n care primete o cerere (sau un mesaj) de la un client.
Cererile constituie singura modalitate de a determina un obiect sa execute
o operaie. Operaiile constituie singura cale de a schimba datele interne ale
obiectului. Din cauza acestor restricii se spune c starea intern a obiectului
este ncapsulat;ea nu poate fi accesat direct, iar reprezentarea sa este
invizibil n afara obiectului.
Partea cea mai dificil a proiectrii orientat-obiect este descompunerea
proiectului n obiecte. Sarcina este dificil deoarece trebuie luai n consideraie
muli factori caum ar fi: ncapsulare, granularitate, dependen, flexibilitate,
performan, evoluie, reutilizare, i muli alii. Ei tot nfluenez descompunerea
i cteodat sunt n contradicie.
Multe obiecte provin din modelul de analiz, dar adesea proiectele OO au
clase care nu au nici o legtur cu lumea real. Unele dintre acestea sunt clase
de nivel inferior, cum ar fi tabelele, altele, sunt de nivel mai ridicat, cum ar fi
Compositor, ablonul care introduce o abstractizare pentru tratarea uniform a
obiectelor care fizic nu sunt la fel. Modelarea strict a lumii reale conduce ctre
un sistem care reflect astzi lumea real dar nu n mod necesar i mine!
Abstractizrile care decurg din proiectare sunt cheia realizrii unui proiect flexibil.

167
abloanele de proiectare ajut la identificarea celor mai puin evidente
abstractizri i obiecte care le captureaz. De exemplu, obiectele care reprezint
un proces sau un algoritm nu apar n natur, dar sunt parte crucial pentru
proiecte flexibile. ablonul Strategy ( ) descrie cum se implementez familii
interanjabile de algoritmi. ablonul State ( ) reprezint fiecare stare a unei
entiti sau obiect.
Aceste obiecte sunt rareori gsite n timpul analizei sau n stadii timpurii ale
proiectrii. Ele sunt descoperite mai trziu n cursul derulrii proiectrii cnd se
ncerc realizarea unui proiect mai flexibil sau reutilizabil.
Obiectele pot varia drastic ca numr i dimensiune. Se poate reprezenta
orice ca obiect, plecnd de la hardware i pn la ntrega aplicaie. Cum
decidem care poate fi un obiect? abloanele se adreseaz exact acestei cerine.
ablonul Facade descrie cum putem reprezenta subsisteme complete ca
obiecte, Flyweight descrie cum vor fi suportate un numr uria de obiecte de o
granularitate mai fin. Alte abloane descriu ci specifice de descompunere a
unui obiect n altele mai mici.

6.3. Cum se selecteaz un ablon
Atunci cnd sunt mai multe abloane la dispoziie este relativ dificil s se
selecteze exact acelea care se adreseaz unei probleme particulare, mai ales
atunci cnd proiectantul nu este familiarizat cu ele.
Exist cteva criterii de selecie a celui mai potrivit ablon pentru o anumit
problem.
Se trec n revist abloanele de proiectare care sunt disponibile, se
studiaz ce ofer fiecare i se aleg acelea care se potrivesc cel mai bine
problemei care trebuie proiectat.
Se studiaz relaiile dintre abloane (fig. 6.1) i se alege grupul cel mai
potrivit.
Se studiaz scopurile, asemanrile i deosebirile dintre abloane.

168
Se parcurge lista (Tabel 6.2.) cu acele aspecte ale abloanelor care pot fi
modificate n mod independent, modificri care corespund scopului proiectului
propus.
Dac proiectantul nu are experien n proiectarea orientat pe obiect se
poate ncepe cu cele mai simple i comune abloane de proiectare: Abstract
Factory, Factory Method, Adapter, Observer, Composite, Strategy, Decorator,
Template Method.

Fig. 6.1. Relaiile ntre abloanele de proiectare

169

6.4. Cum se folosete un ablon de proiectare

O abordare pas cu pas a proiectrii unui sistem software folosind
abloane ar putea s decurg n felul urmtor:
1. Se citete descrierea ablonului pentru a avea o imagine general. Se
acord o atenie deosebit seciunilor de aplicabilitate i consecine pentru
a avea garania c ablonul de proiectare corespunde problemei;
2. Se revine i se studiaz seciunile de structur, participani i colaborri.
Trebuie s se neleag exact clasele i obiectele din ablon i modul n
care aceastea relaionez unele cu altele.
3. Se examineaz apoi seciunea de cod care prezint un exemplu concret.
Studiind codul se poate nva cum se implementeaz ablonul.
4. Se aleg numele participaniilor din ablon, nume care trebuie s aib o
semnificaie n contextul aplicaiei. Numele participanilor din design
patterns sunt de obicei prea abstarcte pentru a aprea direct n aplicaie i
de aceea este util s se ncorporeze numele participanilor n numele care
apar n aplicaie pentru a fi mai explicite n implementare. De exemplu,
dac se utilizeaz Strategy pattern pentru un text care compune
algoritmul, atunci putem avea clasa numit SimpleLayoutStrategy sau
TextLayoutStrategy.
5. Se definesc clasele. Se declar interfeele, se stabilesc relaiile de
motenire i se definesc variabilele care reprezint datele i obiectele
referite. Se identific clasele existente din aplicaie pe care ablonul le va
afecta i se pun de acord.
6. Se definesc numele specifice aplicaiei pentru operaiile din ablon. nc o
dat, numele depind n general de aplicaie. Se folosesc responsabilitile
i colaborrile asociate cu fiecare operaie ca un ghid. De asemenea, este
bine s existe consecven n conveniile de notare. De exemplu, se
folosete prefixul Creeaz- de fiecare dat cnd desemnm o metod
Factory.

170
7. Se implementeaz operaiile avnd grij de responsabilitile i
colaborrile din ablon. Seciunea de implemantare ofer sugestii pentru
implementare.
8. Se definesc clasele. Se declar interfeele, se stabilesc relaiile de
9. Se definesc clasele. Se declar interfeele, se stabilesc relaile de
10. Se definesc numele specifice aplicaiei pentru operaiile din ablon. nc o
dat, numele depind n general de aplicaie. Se folosesc responsabilitile
i colaborrile asociate cu fiecare operaie ca un ghid. De asemenea, este
bine s existe consecven n conveniile de notare. De exemplu, se
folosete prefixul Creeaz- de fiecare dat cnd desemnm o metod
Factory.
11. Se implementeaz operaiile avnd grij de responsabilitile i
colaborrile din ablon. Seciunea de implemantare ofer sugestii pentru
implementare.


171
Tabelul 6.2. Aspectele de proiectare care pot fi modificate n design patterns
Scop ablon de
proiectare
Aspecte care pot fi modificate
Creaional Abstract Factory Familiile de obiecte produs
Builder Modalitatea n care pot fi create obiectele
compozite
Factory Method Subclasa obiectelor care sunt instaniate
Prototype Clasa obiectelor care este instaniat
Singleton O singur instan a unei clase
Structural Adapter Interfaa cu un obiect
Bridge Implementarea unui obiect
Composite Structura i compoziia unui obiect
Decorator Responsabilitile proprii ale unui obiect fr
subclase
Facade Interfaa cu un subsistem
Flyweight Memorarea costurilor obiectelor
Proxy Modul n care este accesat obiectul- locaia
sa
Comportamental Chain of
Responsability
Obiectul care poate ndeplini o solicitare
Command Cnd i cum poate fi indeplinit o solicitare
Interpreter Gramatica i interpretarea unui limbaj
Iterator Cum sunt accesate i parcurse elementele
unei mulimi
Mediator Cum i care obiecte interacionez unele cu
altele
Memento Ce informaie privat este memorat n afara
obiectului i cnd.
Observer Numrul obiectelor care depind de alt obiect;
Cum poate fi actualizat obiectul dependent.
State Strile unui obiect
Strategy Un algoritm
Template Method Paii unui algoritm
Visitor Operaiile care pot fi aplicate obiectului
(obiectelor) fr schimbarea clasei (claselor).


172


173

7

Proiectarea sistemelor software

7.1. Procesul de proi ectare
Proiectarea software-ului implic urmtoarele stadii:
(1) Studierea i nelegerea problemei. Fr o nelegere profund i
corect a sistemului proiectarea efectiv a software-ului ar fi practic imposibil.
Problema trebuie examinat din unghiuri diferite, astfel nct s permit o privire
din interior a cerinelor de proiectare.
(2) Identificarea caracteristicilor principale i, n cele din urm, o
posibil soluie. Adesea este util s se identifice mai multe soluii i s se
evalueze fiecare dintre ele. Alegerea soluiei depinde de experiena
proiectantului, de componentele reutilizabile pe care le are la dispoziie, de
simplitatea soluiilor derivate.
(3) Descrierea fiecrei abstractizri utilizate n soluie. nainte de a
crea documentaia formal, totui proiectantul trebuie s stabilesc dac este
necesar s construiasc o descriere informal a proiectului. Erorile i omisiunile
din nivelurile nalte ale proiectrii, care sunt descoperite de-a lungul proiectrii la
nivelurile sczute, pot fi corectate nainte ca proiectul s fie documentat.
Un model general de proiectare a software-ului este un graf orientat.
Nodurile grafului reprezint entitile de proiectare, cum ar fi procesele, funciile
sau tipurile, iar legturile reprezint relaiile existente ntre entiti. Scopul

174
procesului de proiectare este de a crea un asemenea graf fr inconsistene i n
care toate relaiile dintre entiti sunt legale (posibile).
Procesul de proiectare implic utilizarea formalismului ca proiectare
progresiv, cu un backtraking constant pentru a corecta mai repede i mai puin
formal, proiectele. Proiectantul ncepe cu o imagine foarte neformal a proiectului
i o rafineaz, adugndu-i informaie pentru a realiza un proiect mai bine
formalizat (Fig.7.1).

Fig.71. Procesul de proiectare

Procesul de proiectare implic descrierea sistemului ntr-un numr diferit
de niveluri de abstractizare, permind astfel descoperirea mai devreme a
omisiunilor sau a erorilor. Aceast reacie creeaz posibilitatea ca diferitele stadii
de proiectare s fie rafinate.
Fig.7.2. prezint stadiile procesului de proiectare i al descrierilor de
proiectare produse ca rezultat al acestor activiti.
Ieirea fiecrei activiti de proiectare este o specificaie. Aceast
specificaie poate fi abstract, o specificare formal care este produs pentru a
clarifica cerinele, sau poate fi o specificare a modului n care o parte din sistem
va fi realizat.
Astfel, procesului de proiectare continu, adugndu-se din ce n ce mai
multe detalii la specificare. Ultimile ieiri sunt specificaiile algoritmilor i ale
structurilor de date care vor constitui baza pentru implementarea sistemului.

Schi
proiect
informal
Proiect
informal
Proiect puin
formalizat

Proiect final

175

Fig.7.2. Activiti de proiectare i produse proiectate

Fig. 7.2 sugereaz c stadiile procesului de proiectare sunt secveniale. n
realitate, activitatea de proiectare se desfoar n paralel cu alte produse de
proiectare, aflate n faze de detaliere diferite ale procesului de proiectare.
Activitile prezentate n fig. 7.2 sunt eseniale n proiectarea sistemelor
software mari i cuprind urmtoarele:
(1). Proiectarea arhitecturii. Se realizeaz subsistemele ntregului sistem
identificndu-se i documentndu-se relaiile dintre ele.
(2). Specificarea abstract. Se genereaz specificri abstracte ale
serviciilor pentru fiecare subsistem n parte i se stabilesc restriciile sub care va
opera sistemul.
(4). Proiectarea componentei. Serviciile produse de subsistem sunt
partiionate n funcie de componentele din acel subsistem.
(5). Proiectarea structurilor de date. Structurile de date folosite n
implementarea sistemului vor fi proiectate n detaliu i specificate.
(6). Proiectarea algoritmului. Algoritmii utilizai pentru a furniza servicii vor
fi proiectai n detaliu i specificai.
Procesul este repetat pentru fiecare subsistem, pn cnd componentele
identificate pot fi transpuse direct n componente ale unui limbaj de programare
cum ar fi package, proceduri sau funcii.
Specificarea
cerinelor
Proiectarea
arhitecturii
Specificarea
abstract
Proiectarea
interfeei
Proiectarea
componentei
Proiectarea
structurii de
date
Proiectarea
algoritmului
Arhitectura
sistemului
Specficarea
software-ului
Specificare
component
Specificare
structur
de date
Specificare
algoritmi
Specificare
interfa

176
O abordare recomandat pentru proiectarea pe scar larg este
proiectarea top-down n care problema este recursiv mprit n subprobleme,
pn cnd sunt identificate toate subproblemele elementare.
Forma general a proiectului care de obicei iese la iveal dintr-o astfel de
abordare este aproximativ ierarhic (fig.4.3), legturile de ncruciare observn-
du-se n graf pe nivelurile sczute ale arborelui de proiectare, astfel nct
proiectanii pot identifica posibilitile de reutilizare.

Fig.7. 3. Structura proiectrii software

De fapt nu este recomandabil s se proiecteze sistemele ntr-o manier
care este strict top-down. Proiectanii i utilizeaz adesea experiena anterioar
de proiectare i nu au nevoie ntotdeauna s descompun toate abstractizrile,
tiind exact care parte a sistemului poate fi construit.
Proiectarea top-down a fost propus n conjuncie cu descompunerea
funcional i este o abordare valid n care componentele proiectate sunt strns
legate. Totui cnd este adoptat o proiectare orientat pe obiect i multe
obiecte existente urmeaz s fie reutilizate, proiectarea top-down nu este cea
mai indicat.
Proiectantul utilizeaz obiectele existente ntr-o reea de proiectare i
construiete proiectul cu ele. Nu exist nici un concept de ierarhizare a tuturor
obiectelor existente ntr-un singur obiect ierarhic.


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

7.2.1. Procesul: obinerea modelul ui de proi ectare arhitecturala
1. Abordare descendenta
Se pleaca de la specificatia cerintelor software: S
Se descompune setul cerintelor, S, in subseturi relativ independente, S1, S2,
Fiecare subset de cerinte, Si, este alocat unui subsistem al arhitecturii
software: SA1, SA2...
Fiecare subset de cerinte Si este descompus in subseturi mai simple, Si1,
Si2, .. care sunt alocate unor subsisteme ale subsistemului SAi: SAi1, SAi2,..
............................................
Descompunerea modelului de proiectare arhitecturala se oprete atunci
cand nivelul sau de detaliu permite:
continuarea dezvoltarii in paralel de catre mai multi membrii ai echipei de
dezvoltare,
planificarea activitatilor urmatoare ale procesului de dezvoltare (pana la
livrare),
estimarea resurselor umane necesare si a costurilor.
Rezultatul este o structura ierarhica alcatuita din subsisteme interconectate,
fiecare subsistem fiind descompus pana la nivel de module.

178
Un modul de proiectare poate fi: modul functional (functie, procedura),
clasa, componenta, in functie de metoda de proiectare folosita: functionala
sau orientat obiect.
Fiecarui modul de proiectare i s-a alocat un set de cerinte pe care trebuie sa
le implementeze.
Se incearca gasirea unor module existente care ar putea fi folosite in
implementarea modulelor definite in procesul de proiectare.
2. Abordare ascendent
Centrata pe reutilizare
Se pleaca de la un set de module existente : module functionale sau clase
Se cauta o descompunere a cerintelor in subseturi care pot fi implementate
folosind componentele existente
3. Abordare hibrida
Se pleaca de la setul de cerinte software, care se descompune iterativ,
dar in procesul de descompunere se urmareste definirea de module care pot fi
implementate folosind module existente.

7.2.2. Modelul de proiectare athitect ural
Este o structur ierarhic realizat din subsisteme interconectate, fiecare
subsistem fiind alcatuit dintr-un set de module interconectate sau din alte
subsisteme, s.a.m.d.
Modelul poate fi reprezentat prin :
diagrame de componente si diagrame de distributie combinate cu
diagrame de componente
diagrame de clase, in care relatiile ierarhice se bazeaza pe
generalizare si specializare
diagrame de structura (Fig.7.4), in cazul unei descompuneri
functionale : descompunerea iterativa a functiilor pe care trebuie sa le
implementeze sistemul


179

Fig.7.4. Diagrama de structura

Nodurile arborelui sunt module functionale.
Arcele reprezinta relatiile de apel intre module.
Sagetile indica fluxul datelor
Pentru fiecare modul al arhitecturii software se scrie o specifi catie:
Fiecare modul este specificat prin:
Identificatorul(unic) si tipul sau (clasa, functie, fisier, program)
Scopul sau cerintele software pe care le implementeaza
Componenetele subordonate: modulele apelate/ obiectele utilizate/
fisierele unei baze de date
Interfata componentei: fluxul datelor si al controlului
Dependentele sale: conditii care trebuie sa fie satisfacute inainte sau dupa
executia sa, operatii interzise in timpul executiei componentei
Prelucrarea interna a componentei, la nivelul cel mai coborat in limbaj
natural
Structurile de date interne


180
Planul testelor de integrare precizeaza ordinea in care vor fi integrate
modulele in subsisteme si apoi subsistemele pana la nivel de sistem precum si
testele care vor fi efectuate la integrare.

7.3. Proiectarea calitii
Nu exist nici n momentul de fa o modalitate absolut garantat care s
ateste c un proiect este fr nici o eroare. n funcie de domeniul de aplicaie i
de cerinele proiectului, un proiect bun ar putea fi proiectul care permite
producerea unui cod eficient, sau ar putea fi proiectul cu dimensiunea cea mai
mic posibil, pentru care implementarea s fie ct mai compact, sau proiectul
care asigur mentenana cea mai bun.
Un proiect mentenabil poate fi cu rapiditate adaptat pentru a i se adauga
noi functionaliti sau pentru a le modifica pe cele existente. Proiectul trebuie s
fie inteligibil, iar schimbrile s aib un efect local. Componentele proiectului
trebuie s aib coeziune, ceea ce nseamn c toate prile componente s fie
legate logic ntre ele. Ele trebuie s poat fi cu uurin decuplate, cuplajul fiind o
msur a independenei componentelor.
Multe preocupri i cercetri tiinifice au avut n vedere stabilirea unor
metrici de proiectare a calitii, care s ateste n final c un proiect este bun.
Cele mai multe asemenea metrici au fost dezvoltate n conjuncie cu metodele
structurate ale lui Yourdan. Caracteristicile de calitate sunt n mod egal aplicabile
att proiectrii orientate pe obiect ct i proiectrii oriantate funcional, i sunt :
coeziunea, cuplajul, inteligibilitatea, adaptabilitatea.

7.3.1. Coeziunea
Coeziunea unei componente este o msur a ct de bine se potrivete ea
logic cu celelalte. O component poate implementa o singur funcie logic sau o
singur entitate logic i toate prile componentei trebuie s contribue la
aceast implementare. Dac componenta include pri care nu sunt direct legate
de funcia ei logic (de exemplu, dac exist un grup de operaii care se execut

181
n acelai timp i nu au legtur cu funcia), aceasta nseamn c gradul de
coeziune este scazut.
Constantine i Yourdan (1979) au identificat apte niveluri de coeziune n
ordine cresctoare a gradului, i anume:
1). Coeziune de coinciden. Prile componente nu sunt ntr-o relaie, ci
pur i simplu sunt asamblate ntr-o singur component.
2). Asociere logic. Componentele care realizeaz funcii similare, cum ar
fi operaii de intrare, tratarea erorilor,etc., sunt asamblate mpreun ntr-o singur
component.
3). Coeziune temporal. Toate componentele care sunt active la un
moment de timp, cum ar fi cele necesare la pornire sau la oprire, trebuie s fie la
un loc.
4). Coeziunea procedural. Elementele dintr-o component trebuie s
aib o singura secven de control.
5). Coeziune de comunicare. Toate elementele unei componente
opereaz pe aceleai date de intrare sau produc aceleai date de ieire.
6). Coeziune secvenial. Ieirea dintr-un element al componentei
servete ca intrare pentru alt element.
7). Coeziune funcional. Fiecare parte a componentei este necesar
pentru execuia unei singure funcii.
Aceste clase de coeziune nu sunt n mod strict definite, iar Constantine i
Yourdan le-au ilustrat prin exemple. Nu este ntotdeauna uor s se fac o
clasificare a unui sistem ntr-o anumit categorie de coeziune.
Metoda lui Yourdan este aplicabil i este evident c cea mai bun form
de coeziune a unei uniti este funcia.Totui, cel mai mare grad de coeziune l
au sistemele orientate pe obiecte i acest lucru reprezint de fapt o caracteristic
a acestora. ntr-adevar, unul dintre principalele avantaje ale acestei modaliti de
proiectare este acela c obiectele creeaz sistemului o coeziune natural.
Un obiect coerent (care are coeziune) este acela n care este reprezentat
o singur entitate i n care sunt incluse toate operaiile pentru acea entitate. n
acest context se poate defini urmtoarea clasa de coeziune:

182
Coeziune de obiect. Fiecare operaie are ca rezultat acea funcionalitate
care s permit obiectului s poat fi modificat, inspectat sau utilizat ca surs de
servicii.
Coeziunea este o caracteristic de dorit deoarece aceasta nseamn c
un modul reprezint o singur parte din soluia problemei. Dac este necesar s
se modifice sistemul, acest parte exist ntr-un singur loc i orice trebuie fcut
cu ea se afl ncapsulat ntr-o singur unitate.
Dac funcionalitatea este furnizat de un sistem-obiect care utilizeaz
motenirea din super-clase, coeziunea obiectului care motenete atribute i
operaii este redus. Nu este posibil mult timp s se considere obiectul ca o
unitate distinct. Toate super-clasele vor putea de asemenea s fie inspectate
dac funcionalitatea unui obiect nu este n totalitate neleas.
7.3.2. Cuplajul
Cuplajul este legat de coeziune i este un indicator al triei intercorelrii
dintre unitile programului.
Sistemele cu cuplaj ridicat au interconectri puternice cu unitile din
program care depind unele de altele. Sistemele cu cuplaj slab sunt construite din
uniti independente sau aproape independente.
Ca reguli generale: toate modulele au cuplaj ridicat dac ele utilizeaz
variabile n comun sau dac ele i schimb informaia de control. Constantine si
Yourdan au numit aceast cuplare comun sau cuplare prin control. Cuplajul
slab este obinut prin asigurarea ca, att timp ct este posibil, informaia
reprezentativ este pstrat n interiorul unei componente, iar interfaa de date
cu alte uniti se realizeaz numai prin lista de parametri. Dac este nevoie s
fie partajate datele, aceast partajare poate fi controlat, cum este n ADA n
cazul package. Aceasta se numete cuplare prin date. Fig. 7.5 si 7.6 ilustreaz
cuplajul puternic, respectiv cuplajul slab al modulelor.
O problema a cuplajului provine din faptul c se pot cupla diverse module
prin valori de variabile. Orice schimbare a acestor valori presupune o schimbare
n program.

183
Se pare ca principalul avantaj al proiectrii orientate pe obiect rezid din
faptul c proiectele rezultate manifest un cuplaj slab.
Principala caracteristic a acestei abordari orientate pe obiect este
tocmai aceea c ascunde ceea ce este n interiorul obiectului astfel nct
sistemul nu trebuie s aib o stare partiionat cu nici un alt obiect, iar un
obiect poate fi la rndul lui nlocuit de altul, cu aceeai interfa.
Motenirea n sistemele orientate pe obiect are o form definit de cuplaj.
Obiectele care motenesc atribute i operaii sunt cuplate cu super-clasele lor,
iar schimbrile fcute n superclase trebuie operate cu grij, deoarece acestea
se propag n toate clasele care motenesc acea super-clas.

Fig.7.5. Cuplaj puternic Fig.7.6 Cuplaj slab

7.3.3. Inteligibilitatea
Schimbarea componentei unui proiect are drept implicaie ca persoana
responsabil de acea schimbare s neleag operaia facut. Acest lucru se
refer la cteva caracteristici ale componentei i anume:
(1) Coeziunea. Poate acea componenta s fie neleas fr alte referiri la
celelalte componente?
(2) Numele. Sunt numele utilizate n nelesul componentei?
DATE
COMUNE
MODUL A MODUL B
MODUL C MODUL D

DATE A
MODUL C

DATE C
MODUL B

DATE B
MODUL D

DATE D

MODUL A

184
(3) Documentare. Este componenta documentat astfel nct s reflecte o
legatur clar ntre entitile din lumea reala i component?
(4) Complexitate. Ct de mare este complexitatea algoritmilor utilizai n
implementarea componentei? n acest context se utilizeaz complexitatea ntr-o
manier neformal.
Complexitatea nalt implic multe relaii ntre diferite componente ale
proiectului i o structur logic complex, care poate implica secvene if-then-
else imbricate.
Complexitatea componentelor este greu de neles i de aceea
proiectantul trebuie s se strduiasc s conceap componente pe ct posibil
mai simple.
Cel mai mare efort n stabilirea de metrici pentru calitatea proiectului este
concentrat pe ncercarea de a asigura complexitatea componentei, obinndu-
se astfel o msur a inteligibilitii componentei. Complexitatea afecteaz
nelegerea, dar sunt i ali factori care o afecteaz, cum ar fi organizarea datelor
i stilul n care proiectul este descris.
Msurile complexitii pot numai s furnizeze un indicator al inteligibilitii
componentei. Motenirea n proiectele orientate pe obiect afecteaz nelegerea.
Motenirea este folosit pentru a ascunde detalii de proiectare, iar proiectul
este uor de neles.
Pe de alt parte, utilizarea motenirii solicit celui care citete proiectul s
priveasc la multe clase diferite de obiecte din ierarhia de motenire, iar
nelegerea proiectului este redus.

7.3.4. Adaptabilitatea
Pentru ca un proiect s fie bine ntreinut, el trebuie s poat fi cu uurin
adaptat diverselor cerine survenite ulterior. Aceasta implic, subneles, ca toate
componentele s fie cuplate slab. Mai mult dect att, adaptabilitatea nseamn
ca proiectul s fie bine documentat, documentaia componentelor s poat fi
neleas cu uurin n concordan cu implementarea, iar implementarea s fie
scris ntr-o form accesibil.

185
Un proiect adaptabil trebuie s aib un nivel nalt de vizibilitate i trebuie s
existe o relaie clar ntre diferitele niveluri ale proiectului. Trebuie s fie posibil
pentru cititorul proiectului s gseasc relaia dintre reprezentarea ca o diagram
de structuri i reprezentarea transformrii datelor (Fig.7.7).
De asemenea, trebuie s fie uor s se ncorporeze schimbrile fcute din
proiect n toate documentele proiectului. Pentru o adaptabilitate optim
componenta trebuie s se conin numai pe sine.
Adaptabilitatea unei componente poate s implice schimbri numai ale unei
pri a componentei care se refer la funciile externe, astfel ca specificarea
acestor funcii externe s fie de asemenea luat n consideraie de ctre cel care
face modificarea.
Unul dintre principalele avantaje ale motenirii sistemelor orientate pe
obiect este acela c n acest caz componentele pot fi adaptate cu uurin.
Mecanismul de adaptare nu se refer la modificarea componentei, ci la
crearea unei noi componente care motenete atributele i operaiile
componentei originale.
Numai atributele i operaiile care trebuie schimbate sunt modificate.
Aceast adaptabilitate simpl este motivul pentru care limbajele orientate pe
obiect sunt att de eficiente pentru prototipizarea rapid.
Totui, pentru sistemele cu via scurt, trebuie avut n vedere c
motenirea devine o problem atunci cnd sunt operate din ce n ce mai multe
schimbri i reeaua de motenire devine din ce n ce mai complex.
Funcionalitatea este adesea distribuit n diverse puncte ale reelei, iar
componentele sunt n acest caz greu de neles.
Experiena n programarea orientat pe obiect a artat c reeaua de
motenire trebuie periodic revizuit i restructurat pentru a se reduce
complexitatea i duplicarea funcionalitii. n mod clar, aceasta face s creasc
costul schimbrii sistemului.


186

Nivelul
diagramei
datelor

Nivelul
structurii

Fig.7.7 Diagrama de structur i reprezentare a datelor

7.4. Modularizarea proiectul ui
7.4.1. Principii de modularizare:
Modulele trebuie sa fie simple si cat mai independente unul de altul:
o O modificare a unui modul are influenta minima asupra altor
componente
o O schimbare mica a cerintelor nu conduce la modificari majore ale
arhitecturii software (gruparea cerintelor corelate in acelasi modul)
o Efectul unei conditii de eroare este izolat in modulul are a generat-o
o Un modul poate fi inteles ca o entitate de sine-statatoare
Modulele trebuie sa ascunda modul de implementare a functiilor
descrise de interfata lor, de ex. cum sunt memorate datele cu care
lucreaza (tablou, lista, arbore, in memorie sau intr-un fisier)
7.4.2. Reguli de proiectare a modulelor:
Minimizarea cuplarii intre module:

187
o Minimizarea numarului de elemente prin care comunica modulele;
o Evitarea cuplarii prin structuri de date
o Evitarea cuplarii prin variabile steag (cuplarea prin control)
o Evitarea cuplarii prin date globale
Maximizarea coeziunii interne a fiecarei componente: elementele
grupate intr-o componenta trebuie sa fie corelate, de ex. sa contribuie la
aceeasi prelucrare
Restrangerea numarului de module apelate (fan-out) de un modul:
Maximizarea numarului de module care utilizeaza un modul ( fan-in)
incurajaza reutilizarea (Fig. 7.8)
Fan-in mare: un numar mare de module depind de el
Fan-out mare: modulul depinde de multe module
Factorizare: functionalitatile comune sunt definite in module reutlizabile.

Fig.7.8. Exemplu de diagram de structur

188
Documentul de proiectare arhitecturala (ADD)
Sablonul documentului in standardele ESA:
a. Abstract
b. Table of Contents
c. Document Status Sheet Status sheet for configuration control.
d.
Document Change Records
since previous issue
A list of document changes.
1. Introduction
1.1 Purpose
The purpose of this particular ADD and its
intended readership.
1.2 Scope
Scope of the software. Identifies the product by
name, explains what the software will do.
1.3 List of definitions
The definitions of all used terms, acronyms and
abbreviations.
1.4 List of references All applicable documents.
1.5 Overview
Short description of the rest of the ADD and how
it is organized.
2. System overview
Short introduction to system context and design.
Background of the project.
3. System context (for each external interface ...)
3.n External interface definition The relationship with external system n.
4. System design
4.1 Design method Name and reference of the method used.
4.2 Decomposition description
Overview of components: decomposition,
dependency or interface view.
5. Component descriptions (for each component ...)
5.n Component identifier A unique identifier.

189
5.n.1 Type Task, procedure, package, program, file, ...
5.n.2 Purpose Software requirements implemented.
5.n.3 Function What the component does.
5.n.4 Subordinates
Child components (modules called, files
composed of, classes used).
5.n.5 Dependencies
Components to be executed before/after,
excluded operations during execution.
5.n.6 Interfaces Data and control flow in and out.
5.n.7 Resources Needed to perform the function.
5.n.8 References To other documents.
5.n.9 Processing Internal control and data flow.
5.n.10 Data Internal data.
6. Feasibility and resource
estimates
A summary of computer resources needed to
build, operate and maintain the software.
7. Requirements traceability
matrix
A table showing how each software requirement
of the SRD is linked to components in the ADD.

7.4.3. Proiectarea de detaliu
Se efectueaza la nivelul modulelor definite in proiectarea arhitecturala.
Poate avea loc in paralel, pentru diferite module.
Detaliaza modelul de proiectare arhitecturala:
o pot fi definite module de nivel mai coborat
o se detaliza componenta claselor: atributele si functiile membre
o se aleg biblioteci utilizate in implementare
o se incurajeaza reutilizarea
o sunt descrisi algoritmii


190


191

8

Testarea sistemelor software

8.1. Intoducere
Un test const n execuia programului pentru un set de date de intrare
convenabil ales, pentru a verifica dac rezultatul obinut este corect.
Un caz de test este un set de date de intrare mpreun cu datele de ieire
pe care programul ar trebui s le produc. De exemplu, valorile coeficienilor
a,b,c ai unei ecuaii de gradul doi mpreun cu valorile x1, x2, n testul unui
program de rezolvare a ecuaiilor de gradul doi. Cazurile de test se aleg astfel
nct s fie puse n eviden, dac este posibil, situaiile de funcionare
necorespunztoare.
Testarea este activitatea de concepie a cazurilor de test, de execuie a
testelor i de evaluare a rezultatelor testelor, n diferite etape ale ciclului de via
al programelor. Tehnicile de testare sunt mult mai costisitoare dect metodele
statice (inspectrile i demonstrrile de corectitudine), de aceea n prezent se
apreciaz c tehnicile statice pot fi folosite pentru a le completa pe cele dinamice,
obinndu-se astfel o reducere a costului total al procesului de verificare i
validare. Metodele traditionale de verificare/validare presupun realizarea
verificrii/validrii prin inspectri i teste. Aceste activiti ocup circa 30-50% din
efortul total de dezvoltare, n funcie de natura aplicaiei.
Prin testare nu se poate demonstra corectitudinea unui program. Aceasta
deoarece n cele mai multe cazuri este practic imposibil s se testeze programul

192
pentru toate seturile de date de intrare care pot conduce la execuii diferite ale
programului. Testarea poate doar s demonstreze prezena erorilor ntr-un
program. ntr-un sens, testarea este un proces distructiv, deoarece urmrete s
determine o comportare a programului neintenionat de proiectani sau
implementatori. Din acest punct de vedere testarea nu trebuie s fie fcut de
persoanele care au contribuit la dezvoltarea programului. Pe de alt parte
conoaterea structurii programului si a codului poate fi foarte utila pentru
alegerea unor date de test relevante.
Testarea n vederea verificrii programului folosete date de test alese
de participanii la procesul de dezvoltare a programului. Ea este efectuat la mai
multe nivele: la nivel de unitate funcional, de modul, de subsistem, de sistem.
Testarea n vederea validrii programului, numit i testare de
acceptare, are drept scop stabilirea faptului c programul satisface cerinele
viitorilor utilizatori. Ea se efectueaz n mediul n care urmeaz s funcioneze
programul, deci folosindu-se date reale. Prin testarea de acceptare pot fi
descoperite i erori, deci se efectueaz i o verificare a programului.

8.2. Testarea pe parcursul cicl ului de via al unui program.
8.2.1. Testele "unitare"
Testarea unui modul (o funcie, o clas, unitate Pascal, un pachet ADA, etc.)
este realizat de programatorul care implementeaz modulul. Toate celelalte
teste sunt efectuate, n general, de persoane care nu au participat la dezvoltarea
programului.
Scopul testarii unui modul este de a se stabili ca modulul este o
implementare corecta a specificatiei sale (conforma cu specificatia sa).
Specificatia poate fi neformala sau formala. De exemplu:
- o specificaie de pre i post condiii pentru o funcie sau procedur;
- un invariant al clasei, care specific mulimea strilor posibile ale fiecrui obiect
din clasa respectiv, mpreun cu specificaii de pre i post condiii la nivelul
funciilor membru;
- o specificaie algebric a clasei;

193
- o specificaie Z/Z++ etc.
In cursul testarii unui modul, modulul este tratat ca o entitate independent,
care nu necesit prezena altor componente ale programului. Testarea izolat a
unui modul ridic dou probleme:
- simularea modulelor apelate de cel testat;
- simularea modulelor apelante.
Modulele prin care se simuleaz modulele apelate de modulul testat se
numesc module "ciot" (n englez, "stub") . Un modul "ciot" are aceeai interfa
cu modulul testat i realizeaz n mod simplificat funcia sa. De exemplu, dac
modulul testat apeleaz o funcie de sortare a unui vector, cu antetul:
void sortare(int n, int *lista);
se poate folosi urmtoarea funcie "ciot":
void sortare(int n, int *lista)
{ int i;
printf(" \n Lista de sortat este:");
for(i=0; i<n; i++) printf("%d", lista[i]);
// se citeste lista sortata, furnizata de testor
for(i=0; i<n; i++) scanf("%d", lista[i]);
}

Fig.8.1. Structura programului executabil pentru testarea izolata a unui modul

Modul driver
Modul testat
Modul ciot Modul ciot

194
Un modul "ciot" se poate reduce eventual la o tabel de perechi de forma:
"valori ale parametrilor de intrare la un apel - rezultatul prevzut".
Cazurile de apel ale modulului testat de ctre celelalte module ale
programului sunt simulate n cadrul unui "modul driver". Modulul driver apeleaz
modulul testat furnizndu-i ca date de intrare datele de test ale modulului. Datele
de test pot fi generate de modulul driver, pot fi preluate dintr-un fiier sau
furnizate de testor ntr-o manier interactiv.
8.2.2. Testele de integrare
Sunt dedicate verificrii interaciunilor dintre module, grupuri de module,
subsisteme, pn la nivel de sistem. Exist mai multe metode de realizare a
testelor de integrare.
Testele de integrare presupun, ca i testele unitare, realizarea de module
"ciot" i module "driver". Numrul de module "driver" i de module "ciot" necesare
n testele de integrare depinde de ordinea n care sunt testate modulele (metoda
de integrare). Testele de integrare necesit de asemenea instrumente de
gestiune a versiunilor i a configuraiilor.
8.2.2.1. Metoda " big-bang"
Sunt integrate ntr-un program executabil toate modulele existente la un
moment dat. Modulele "driver" i "ciot" necesare sunt de asemenea integrate.
Metoda este periculoas cci toate erorile apar n acelai timp i localizarea lor
este dificil.
8.2.2.2. Integrare progresiva. Metodele de integrare progresiv sunt mult mai
eficiente. In fiecare moment se adaug ansamblului de module integrate numai
un singur modul. Astfel, erorile care apar la un test provin din modulul care a fost
ultimul integrat.
8.2.2.2.1. Integrarea ascendent (bottom-up)
Se ncepe prin testarea modulelor care nu apeleaz alte module, apoi se
adaug progresiv module care apeleaz numai modulele deja testate, pn cnd
este asamblat ntregul sistem. Metoda necesit implementarea cte unui modul
"driver" pentru fiecare modul al programului (i nici un modul "ciot").


195
Avantajele testrii de jos n sus
Nu sunt necesare module "ciot". Modulele "driver" se implementeaz mult
mai uor dect modulele "ciot". Exist chiar instrumente care produc automat
module "driver".
Dezavantajele testrii de jos n sus
1. Programul pe baza cruia se efectueaz validarea cerinelor este
disponibil numai dup testarea ultimului modul.
2. Corectarea erorilor descoperite pe parcursul integrrii necesit
repetarea procesului de proiectare, codificare i testare a modulelor. Principalele
erori de proiectare sunt descoperite de abia la sfrit, cnd sunt testate modulele
principale ale programului. ceea ce, n general, conduce la reproiectare i
reimplementare.
8.2.2.2.2. Integrarea descendent (top-down)
Se ncepe prin testarea modulului principal, apoi se testeaz programul
obinut prin integrarea modulului principal i a modulelor direct apelate de el, i
aa mai departe. Metoda presupune implementarea unui singur modul "driver"
(pentru modulul principal) i a cte unui modul "ciot" pentru fiecare alt modul al
programului.
Integrarea descendent poate avea loc pe parcursul unei implementri
descendente a programului. Modulul principal este testat imediat ce a fost
implementat, moment n care nu au fost nc implementate modulele apelate de
el. De aceea, pentru testare este necesar s se implementeze module "ciot". In
continuare, pe msur ce se implementeaz modulele de pe nivelul ierarhic
inferior, se trece la testarea lor folosind alte module ciot, .a.m.d. In fiecare pas
este nlocuit un singur modul "ciot" cu cel real.
Avantajele testrii de sus n jos
1. Erorile de proiectare sunt descoperite timpuriu, la inceputul procesului
de integrare, atunci cnd sunt testate modulele principale ale
programului. Aceste erori fiind corectate la nceput, se evit
reproiectarea i reimplementarea majoritii componentelor de nivel

196
mai cobort, aa cum se ntmpl cnd erorile respective sunt
descoperite la sfritul procesului de integrare.
2. Programul obtinut este mai fiabil caci principalele module sunt cel
mai mult testate.
3. Prin testarea modulelor de nivel superior se poate considera c sistemul
n ansamblul su exist dintr-o faza timpurie a dezvoltrii i deci se poate exersa
cu el n vederea validrii cerinelor; acest aspect este de asemenea, foarte
important n privina costului dezvoltrii sistemului.
Dezavantajele testrii de sus n jos
1. Este necesar s se implementeze cte un modul "ciot" pentru fiecare
modul al programului, cu excepia modulului principal.
2. Este dificil de simulat prin module "ciot" componente complexe i
componente care conin n interfa structuri de date.
3. n testarea componentelor de pe primele nivele, care de regul nu
afieaz rezultate, este necesar s se introduc instruciuni de afiare, care apoi
sunt extrase, ceea ce presupune o nou testare a modulelor.
Aceste dezavantaje pot fi reduse aplicand tehnici hibride, de exemplu,
folosind n locul unor module "ciot", direct modulele reale testate. Integrarea nu
trebuie sa fie strict descendenta. De exemplu, experienta arata ca este foarte util
sa se nceap prin integrarea modulelor de interfa utilizator. Aceasta permite
continuarea integrrii n condiii mai bune de observare a comportrii
programului.

8.3. Testele de sistem
Acestea sunt teste ale sistemului de programe i echipamente complet.
Sistemul este instalat i apoi testat n mediul su real de funcionare. Sunt teste
de conformitate cu specificaia cerintelor de sistem (software) :
teste functionale, prin care se verifica satisfacerea cerintelor
functionale
teste prin care se verifica satisfacerea cerintelor ne-functionale :
o de performan,

197
o de fiabilitate,
o de securitate, etc.
Adesea, testele de sistem ocup cel mai mult timp din ntreaga perioad de
testare.

8.3.1. Testele de acceptare (validare)
Sunt teste de conformitate cu produsul solicitat, conform contractului cu
clientul (->Specificatia cerintelor utilizatorilor). Aceste teste sunt uneori conduse
de client. Pentru unele produse software, testarea de acceptare are loc n dou
etape:
1. Testarea alfa: se efectueaz folosindu-se specificaia cerinelor
utilizatorilor, pn cnd cele dou pri cad de acord c programul este
o reprezentare satisfctoare a cerinelor.
2. Testarea beta: programul este distribuit unor utilizatori selecionai,
realizndu-se astfel testarea lui n condiii reale de utilizare.
8.3.2. Testele regresive
Se numesc astfel testele executate dup corectarea erorilor, pentru a se
verifica dac n cursul corectrii nu au fost introduse alte erori. Aceste teste sunt
efectuate de regul n timpul mentenanei sistemului. Pentru uurarea lor este
necesar s se arhiveze toate testele efectuate n timpul dezvoltrii programului,
ceea ce permite, n plus, verificarea automat a rezultatelor testelor regresive

8.4. Determinarea cazuril or de test
Testarea unui modul, a unui subsistem sau chiar a ntregului program
presupune stabilirea unui set de cazuri de test.
Un caz de test cuprinde:
- un set de date de intrare;
- funcia / funciile exersate prin datele respective;
- rezultatele (datele de ieire) ateptate;
n principiu (teoretic) testarea ar trebui s fie exhaustiv, adic s asigure
exersarea tuturor cilor posibile din program. Adesea o astfel de testare este

198
imposibil, de aceea trebuie s se opteze pentru anumite cazuri de test. Prin
acestea trebuie s se verifice rspunsul programului att la intrri valide ct
i la intrri nevalide.
Sunt dou metode de generare a cazurilor de test, care nu se exclud, de
multe ori fiind folosite mpreun. Ambele metode pot sta la baza unor instrumente
de generare automat a datelor (cazurilor) de test:
1. Cazurile de test se determin pe baza specificaiei componentei testate, fr
cunoaterea realizrii ei; acest tip de testare se numete testare cutie
neagra (black box).
2. Cazurile de test se determin prin analiza codului componentei testate. Acest
tip de testare se mai numete i testare cutie transparent, sau testare
structural.
8.4.1. Testarea cutie neagr .
Cazurile de test trebuie s asigure urmtoarele verificri:
- reacia componentei testate la intrri valide;
- reacia componentei la intrri nevalide;
- existena efectelor laterale la execuia componentei, adic a unor efecte care nu
rezult din specificaie;
- performanele componentei (dac sunt specificate).
Deoarece n marea majoritate a cazurilor testarea nu poate fi efectuat
pentru toate seturile de date de intrare (testare exhaustiv), n alegerea datelor
de test plecnd de la specificaii se aplic unele metode fundamentate teoretic
precum i o serie de euristici.
Alegerea cazurilor de test folosind clasele de echivalen
Cazurile de test pot fi alese partiionnd att datele de intrare ct i cele de
ieire ntr-un numr finit de clase de echivalen. Se grupeaz ntr-o aceeai clas
datele care, conform specificaiei, conduc la o aceeai comportare a programului.
O dat stabilite clasele de echivalen ale datelor de intrare, se alege cte
un eantion (de date de test) din fiecare clas. De exemplu, dac o dat de
intrare trebuie s fie cuprins ntre 10 i 19, atunci clasele de echivalen sunt:
1) valori <10

199
2) valori ntre 10 i 19
3) valori >19
Se pot alege ca date de test: 9, 15, 20.
Experiena arat c este util s se aleag date de test care sunt la frontiera
claselor de echivalen. Astfel, pentru exemplul de mai sus ar fi util s se testeze
programul pentru valorile de intrare 10 i 19.
Alte cazuri de test se aleg astfel nct la folosirea lor s se obin
eantioane din clasele de echivalen ale datelor de ieire (dun interiorul si de la
frontierele lor).
Exemplu:
Fie un program care trebuie s genereze ntre 3 i 6 numere cuprinse ntre
1000 i 2500. Atunci se vor alege intrri astfel nct ieirea programului s fie:
- 3 numere egale cu 1000
- rezultat eronat: mai puin de 3 numere sau mai mult de 6 numere sau valori n
afara intervalului [1000..2500]
- ntre 3 i 6 numere cuprinse ntre 1000 i 2500
n alegerea datelor de test trebuie s se elimine redundanele rezultate din
considerarea att a claselor de echivalen de intrare ct i a celor de ieire.
Unele programe trateaz datele de intrare n mod secvenial. n aceste
cazuri se pot detecta erori n program testndu-l cu diverse combinaii ale
intrrilor n secven. Metoda de partiionare n clase de echivalen nu ajut n
alegerea unor astfel de combinaii. Numrul de combinaii posibile este foarte
mare chiar i pentru programe mici. De aceea nu pot fi efectuate teste pentru
toate combinaiile. n aceste cazuri este esenial experiena celui care
alctuiete setul de cazuri de test.
Testarea "cutie neagr" este favorizat de existena unei specificaii
formale a componentei testate.

200
Exemplu: Fie o funcie de cutare a unui numr ntreg ntr-un tablou de numere
ntregi, specificat astfel:
int cauta (int x[], int nrelem, int numar);
pre : nrelem >0 and exist i in [0..nrelem-1] : x[i] = numar
post : x [cauta(x,nrelem,numar)] =numar and x' =x
error : cauta(x,nrelem,numar) =-1 and x' =x
Intrrile valide sunt cele care satisfac pre-condiia. Efectele laterale ale
funciei "cauta" s-ar putea reflecta n modificarea unor variabile globale. Pentru
evidenierea lor ar trebui ca la fiecare execuie de test a funciei s se vizualizeze
valorile variabilelor globale nainte i dup apelul funciei. Aceste verificri pot fi
limitate, nlocuindu-se cu inspectarea codului funciei, din care rezult
evantualitatea modificrii unor variabile globale.
Setul minim de date de test trebuie s verifice funcia n urmtoarele
situaii:
1. tablou vid (nrelem=0)
2. tablou cu un singur element (nrelem=1)
a). valoarea parametrului "numar" este n tablou
b). valoarea parametrului "numar" nu este n tablou
3. tablou cu numr par de elemente ("nrelem" este un numr par)
a). "numar" este primul n tablou
b). "numar" este ultimul n tablou
c). "numar" este ntr-o poziie oarecare a tabloului
d). "numar" nu este n tablou
4. tablou cu numr impar de elemente ("nrelem" este impar)
i a,b,c,d ca la punctul 3.
Din specificaie rezult c funcia nu trebuie s modifice tabloul; de aceea,
apelul su n programul de test trebuie s fie precedat i urmat de vizualizarea
parametrului tablou.
Setul cazurilor de test ar putea fi:
1) intrri: orice tablou
nrelem=0

201
orice numr
ieiri : valoarea funciei =-1
tabloul nemodificat
2) intrri: x[0] =10
nrelem=1
numr =10
ieiri : valoarea funciei =0
tabloul nemodificat: x[0]=10
3) intrri: x[0]=10
nrelem=1
numr =15
ieiri : valoarea funciei =-1
tabloul nemodificat: x[0] =10
4) intrri: x[0] =10, x[1] =20
nrelem=2
numr =10
ieiri : valoarea funciei =0
tabloul nemodificat: x[0] =10, x[1] =20
............................................................................................................
n alegerea cazurilor de test s-au folosit urmtoarele euristici:
- Programele de cutare prezint erori atunci cnd elementul cutat este primul
sau ultimul in structura de date;
- De multe ori programatorii neglijeaz situaiile n care colecia prelucrat n
program are un numr de elemente neobinuit, de exemplu zero sau unu;
- Uneori, programele de cutare se comport diferit n cazurile: numr de
elemente din colecie par, respectiv numr de elemente din colecie impar; de
aceea sunt testate ambele situaii
Concluzii:
Setul de cazuri de test a fost determinat numai pe baza specificaiei
componentei i a unor euristici (este vorba de experiena celui care
efectueaz testele), deci fr s se cunoasc structura intern a

202
componentei, care este tratat ca o cutie neagr. Eventuala examinare a
codului surs nu urmrete analiza fluxului datelor i a cilor de execuie, ci
doar identificarea variabilelor globale cu care componenta interacioneaz.
Clasele de echivalen se determin pe baza specificaiei.
Se aleg drept cazuri de test eantioane din fiecare clas de echivalen a
datelor de intrare. Experiena arat c cele mai utile date de test sunt
acelea aflate la frontierele claselor de echivalen.
Cazurile de test alese verific componenta doar pentru un numr limitat de
eantioane din clasele de echivalen ale datelor de intrare; faptul c din
testare a rezultat c ea funcioneaz corect pentru un membru al unei
clase nu este o garanie c va funciona corect pentru orice membru al
clasei.
Se determin de asemenea clasele de echivalen ale datelor de ieire i
se aleg pentru testare datele de intrare care conduc la date de ieire aflate
la frontierele acestor clase.
Partiionarea n clase de echivalen nu ajut la depistarea erorilor
datorate secvenierii datelor de intrare. In aceste cazuri este util
experiena programatorului. Reprezentarea comportrii programului printr-
o diagram de stri-tranziii poate fi folositoare n determinarea
secvenelor de date de intrare de utlizat n testarea programului.
Testele cutie neagr, numite i teste funcionale sunt utile nu numai pentru
testarea programului. Ele pot fi utilizate (ca teste statice) pentru verificarea unei
specificaii intermediare fa de o specificaie de nivel superior.
Slbiciunile testelor funcionale:
- Nu este suficient s se verifice c programul satisface corect toate funciile
specificate; unele proprieti interne, nespecificate, ca de exemplu timpul de
rspuns, nu sunt verificate;
- Programul este testat pentru ceea ce trebuie s fac conform specificaiilor
i nu i pentru ceea ce face n plus, de exemplu pentru ca implementarea s
fie mai eficient sau pentru a facilita reutilizarea;

203
- In absena unui standard n privina specificaiilor formale, tehnicile de testare
functional sunt eterogene
8.4.2. Testarea structural
Acest tip de testare se bazeaz pe analiza fluxului controlului la nivelul
componentei testate. Principalul instrument folosit n analiz este graful program
sau graful de control. Acesta este un graf orientat, ale crui noduri sunt de dou
tipuri: noduri care corespund blocurilor de instruciuni indivizibile maximale i
noduri care corespund instruciunilor de decizie. Blocurile de instruciuni
indivizibile maximale sunt poriuni liniare maximale de instruciuni care se
execut ntotdeauna n aceeai secven. Fiecare bloc are un singur punct de
intrare i un singur punct de ieire. Arcele reprezint transferul controlului ntre
blocurile/instruciunile componentei program.
Graful program are un nod unic de intrare i un nod unic de
ieire. Dac exist mai multe puncte de intrare sau mai multe puncte
de ieire, acestea trebuie s fie unite ntr-unul singur(care se adaug
suplimentar). Nodul de intrare are gradul de intrare zero, iar cel de
ieire are gradul de ieire zero.
Fie urmtorul text de program:
f1=fopen(.);
f2=fopen(.);
fscanf(f1, %f, x);
fscanf(f1, %f, y);
z=0;
while(x>=y)
{ x-=y;
z++;
}
fprintf(f2, %d, z);
fclose(f1); fclose(f2);
Textul este decupat n urmtoarele blocuri:
1. f1=fopen(.);

204
f2=fopen(.);
fscanf(f1, %f, x);
fscanf(f1, %f, y);
z=0
2. while(x>=y)
3. x-=y;
z++;
4. fprintf(f2, %d, z);
fclose(f1);
fclose(f2);
Graful de control este redat n Fig.8.2.

Fig.8.2. Graful de control

Se consider cile care ncep cu nodul de intrare i se termin cu nodul de
ieire. Testarea structural const n execuia componentei testate pentru date
de intrare alese astfel nct s fie parcurse unele dintre aceste ci. Nu este
necesar, i n general este imposibil, s se execute toate cile de la intrare la
ieire ale unui program sau ale unei componente program. Prezena ciclurilor
conduce la un numr foarte mare (deseori infinit) de ci. De asemenea, anumite
ci sunt ne-executabile.
Testele structurale favorizeaz evidenierea urmtoarelor tipuri de erori
logice:
START
STOP
1
2
3
4
x>=y

205
1. Ci absente n graful program - ca urmare a ignorrii unor condiii (de
exemplu: test de mprire la zero);
2. Selectarea unei ci necorespunztoare - datorit exprimrii incorecte (de
multe ori incomplete) a unei condiii;
3. Aciune necorespunztoare sau absent (de exemplu: calculul unei valori
cu o metod incorect, neatribuirea unei valori unei anumite variabile,
apelul unei proceduri cu o list de argumente incorect, etc.).
Dintre acestea, cel mai simplu de depistat sunt erorile de tip 3. Pentru
descoperirea lor este suficient s se asigure execuia tuturor instruciunilor
programului.
Alegerea cilor de testat are loc pe baza unor criterii de acoperire a
grafului de control. Dintre acestea cele mai cunoscute sunt:

Execuia tuturor instruciunilor

Cazurile de test se aleg astfel nct s se asigure execuia tuturor
instruciunilor componentei testate. Acesta este un criteriu de testare minimal.
El nu este ntotdeauna satisfctor.
De exemplu, pentru testarea componentei cu graful din Fig.8.3, pe baza
criteriului execuiei tuturor instruciunilor, este suficient s se aleag date de test
care asigur execuia conditiei si a instruciuilor I1 i I2. Nu se testeaz cazurile
n care condiia are valoarea FALSE. Transferul controlului pentru astfel de
cazuri poate fi eronat.

206

Fig.8.3. Graful componentei

Traversarea tuturor arcelor
Cazurile de test se aleg astfel nct s se asigure traversarea fiecrui arc al
grafului program cel puin pe o cale. Pe baza acestui criteriu se va putea verifica
dac transferul controlului este corect pentru valoarea FALSE a condiiei, n
exemplul de mai sus. In acelai timp, criteriul nu impune traversarea mai mult de
o dat a unui ciclu. Anumite erori apar numai atunci cnd un ciclu este traversat
de mai multe ori.

Traversarea tuturor cilor
Pe baza acestui criteriu ar trebui ca testele s asigure traversarea tuturor
cilor componentei testate. Pentru majoritatea programelor nu se poate aplica
acest criteriu, deoarece numrul de ci de execuie este infinit. Criteriul poate fi
restricionat, de exemplu asigurnd traversarea tuturor cilor cu o lungime mai
mic sau egal cu o constant dat.
Problema alegerii cazurilor de test const din trei subprobleme distincte:
- selectarea cilor de testat;
- alegerea datelor de test pentru execuia fiecrei ci selectate;
- determinarea rezultatelor care trebuie s se obin la fiecare test.
condiie TRUE FALSE
I1
I2

207
n continuare prezentm o metod de alegere a datelor de test pe baza
criteriului traversrii tuturor arcelor grafului de control. Metoda presupune
parcurgerea urmtoarelor etape:
1. Se determin setul cilor de testat, C, astfel nct:
a) c e C este o cale de la nodul de intrare la nodul de iesire;
b) fiecare arc din graful de control este cuprins ntr-o cale c eC
c) E lung (c) =minima
c e C
2. Se determin predicatul fiecrei ci, c e C, R
c
(I), unde I = (i
1
,
i
2
, , i
n
) este vectorul variabilelor de intrare;
3. Pentru fiecare R
c
(I), c e C, se determin un set de atribuiri X
c
pentru
variabilele de intrare care satisfac predicatul cii:
R
c
(X
c
) =true
Atunci setul datelor de test este:
DT ={X
c
| c e C, X
c
e D
I
, R
c
(X
c
) = true },
n
unde
=
=
n
k
ik I
D D
1
, iar D
ik
este domeniul de valori al variabilei de intrare i
k.

1. Pentru fiecare X
c
e DT, se determina valorile corecte ale variabilelor de
ieire

Exemplu

Fie urmatorul graf program :


208

Fig. 8.4. Graf program

Obs: testul v2>v1 trebuie inlocuit cu v2>i1.
1) Alegerea cailor :

Se poate alege setul de ci C:
C ={c
1
, c
2
},
unde c
1
={1,2,3,4,5,3,6,7}
c
2
={1,2,3,6,7}
n afara condiiilor menionate s-au mai avut n vedere urmtoarele criterii:
- alegerea unei ci care s nu conina ciclul
- alegerea unei ci care s conina ciclul, parcurgndu-l o singura dat, pentru
ca lungimea cii s fie minim.
2) Determinarea predicatelor de cale
O metod de determinare a predicatului unei ci const n concatenarea
condiiilor de ramificare de pe calea respectiv pe msura ce sunt ntlnite atunci
cnd calea este parcursa de la nodul de ieire pan la cel de intrare. Totodat, la
ntlnirea unei atribuiri, y E, dac y face parte din expresia curent a
predicatului, se substituie y cu E.

209
In unele cazuri, predicatul obinut printr-o singur parcurgere a unui ciclu
este fals pentru orice atribuire a variabilelor de intrare. Un astfel de caz
corespunde unei ci neexecutabile. In consecint se va alege un predicat n care
ciclul este parcurs de dou sau de mai multe ori.
Construirea predicatelor de cale

Rc
1
=v2 >i1
+ 3 se substituie v
2
cu (v
2
+v
3
)
Rc
1
=(v2+v3) >i1
+ 5
Rc
1
=(v2+(v3+2)) >i1
+ 4
Rc
1
=(v2+v3+2) >i1

A ~(v2 >i1)
+ 3
Rc
1
=((v2+v3)+v3+2) >i1

A ~((v2+v3) >i1)
+ 2
Rc
1
=(4 >i1) A ~(1 >i1)
+ 1
Rc
1
=(4 >i1) A (i1 >=1) A (i1 >=0) <=>Rc
1
=(1 <=i1 <4) .
Calea c1 este executat pentru orice valoare a lui i1 care satisface acest
predicat.
Stabilirea rezultatelor execuiei fiecrei ci pentru fiecare set de date de test
ales, necesit cunoaterea transformrii realizate de componenta analizat
asupra datelor de intrare. Aceasta rezult din specificaia componentei. In cazul
de fa trebuie s se stabileasc ce valoare trebuie sa aib iesirea e1 pentru
fiecare valoare aleas pentru i1. Programul reprezentat prin graful de control
analizat calculeaz numarul maxim de termeni ai sumei 1+3+5++(2j+1), j >=
0, care pot fi adunati a.. suma lor s fie mai mica dect i1. Astfel se poate
verifica c pentru orice 1<= i1 <=4, e1 = 1, cci dac s-ar aduna doi termeni,
1+3 = 4, 4>i1.
Cazul de test al cii c1 poate fi: i1=2, e1 = 1.
Calea c2 = {1,2,3,6,7}
Rc
2
=v2 >i1 + 3
Rc
2
=(v2+v3) >i1 + 2
Rc
2
=0 +1 >i1
+ 1

210
Rc
2
=(i1 <1)

A (i1 >=0) <=> Rc
2
=(0 <=i1 <1) => Rc
2
=(i1 =0)
Cazul de test: i1 = 0, e1 =0.
Slabiciunile testelor structurale sunt:
- testele selectionate depind numai de structura programului; ele trebuie
recalculate la fiecare modificare; nu pot fi reutilizate eficient de la o versiune
la alta;
- testele selecionate acoper cazurile legate de ceea ce face componenta
testat i nu de ceea ce trebuie s fac; astfel, dac un caz particular a fost
uitat in faza de implementare, testul structural nu releva aceasta deficien; el
trebuie deci completat cu testul funcional. Mai exact trebuie s se nceap cu
testarea funcional care se completez cu testarea structural.
Testele statistice
Testele statistice se efectueaza in timpul testarii de sistem. Se numesc
astfel testele n care datele de test se aleg aleator, dup o lege de probabilitate
care poate fi:
- uniform pe domeniul datelor de intrare al programului testat- aceste teste se
mai numesc teste statistice uniforme;
- similar cu distribuia datelor de intrare estimate pentru exploatarea
programului aceste teste se mai numesc teste statistice operaionale.
Rezultatele experimentale ale testelor statistice uniforme sunt inegale.
Pentru unele programe s-au dovedit foarte eficiente, ele conducnd la
descoperirea unor erori nsemnate. Pentru altele s-au dovedit ineficiente. O
posibil explicaie ar consta n faptul c ele asigur o bun acoperire n cazul
programelor pentru care domeniile de intrare ale cilor de execuie au o
probabilitate comarabil. Ele nu acoper cile care corespund tratrii excepiilor.
De aceea, trebuie completate cu teste folosind date de intrare n afara
domeniului intrrilor.
Testele statistice operaionale sunt n general teste de fiabilitate. Prin ele
nu se urmrete n general descoperirea de erori ci mai ales comportarea
programului n timp. Cderile observate n timpul acestor teste permit estimarea
masurilor de fiabilitate, cum ar fi MTBF (Mean Time Between Failures).

211

9

Estimarea costului unui proiect software

9.1. Costuri i efort
Estimarea costurilor unei aplicaii software este greu de realizat cu precizie
n cele mai multe modele de estimare, este presupus o relaie simpl ntre cost
i efort; efortul poate fi msurat n luni-om. Exist o relaie ntre efortul necesar i
mrimea produsului (KLOC kilolines of code, kilo-linii de cod).
Pentru a determina ecuaiile unui model algoritmic de estimare a costului
exist mai multe abordri:
1. Un parametru variaz n timp ce ceilali parametri rmn constani i
se determin influena parametrului variabil asupra rezultatului
De ex. comentariile asupra depanrii i ntreinerii
2. Se analizeaz datelor unor proiecte anterioare
De ex. timpul necesar fazelor de dezvoltare, calificarea
personalului implicat, mrimea produsului final;
Analiza costurilor permite identificarea unor strategii de cretere a
productivitii software:
Scrierea de mai puin cod
Stimularea oamenilor s lucreze la capacitatea maxim
Evitarea refacerii componentelor dezvoltate anterior
Dezvoltarea i folosirea mediilor de dezvoltare integrate


212
9.2. Modelul Halstead
i propune o estimare mai obiectiv a mrimii unui program pe baza unui
numr de uniti sintactice: operanzi i operatori
Entiti de baz:
n
1
= numrul de operatori diferii
n
2
= numrul de operanzi diferii
N
1
= numrul total de apariii ale operatorilor
N
2
= numrul total de apariii ale operanzilor
Vocabularul: n = n
1
+n
2

Lungimea implementrii: N =N
1
+N
2

Ecuaia lungimii: N' = n
1
log
2
n
1
+n
2
log
2
n
2

Volumul programului: V =N log
2
n
Variabile
- Estimare empiric a lungimii programului n linii de cod:
LOC =102 +5,31 * VARS
- Fiecare program care va conine aproximativ 100 de linii de cod, plus 5
linii suplimentare pentru fiecare variabil care apare n program.
Generalizarea acestor rezultate la programe mai mari nu este indicat. n
programele mai complexe, factori precum interfaa dintre componente i
comunicarea necesar ntre persoanele implicate joac un rol ce nu poate fi
neglijat.
ntr-o abordare naiv am putea considera c un proiect ce necesit 60 de
luni-om poate fi realizat ntr-un an cu o echip de 5 persoane sau ntr-o lun cu o
echip de 60 de persoane. Aceast abordare ns este prea simplist.
Costurile estimate au deseori o culoare politic, iar rezultatele sunt
determinate de argumente care nu au o natur tehnic.
Dac avem 12 luni pentru a finaliza o lucrare, ea va necesita
12 luni. Acest motiv poate fi privit ca o variant a legii Parkinson: munca ocup
tot timpul disponibil.

213
Dac tim c o ofert de 100000 de euro a fost fcut de concuren, noi
vom face o ofert de 90000 de euro. Acesta este cunoscut sub denumirea de
pre de ctig.
Dorim s ne promovm produsul la un anumit trg de tehnic de calcul i
din acest motiv programul trebuie scris i testat n urmtoarele 9 luni, dei
realizm c timpul este limitat. Aceast situaie este cunoscut sub denumirea
de metoda bugetului de estimare a costului.
Proiectul poate fi dezvoltat ntr-un an, dar eful nu ar accepta acest termen.
tim c termenul de 10 luni este acceptabil i atunci l programm pentru 10 luni.
Simpla comparare a caracteristicilor unui proiect cu un proiect precedent nu
garanteaz o estimare corect a costului su. Dac o echip lucreaz n mod
repetat la proiecte asemntoare, timpul de lucru necesar va scdea, datorit
acumulrii experienei.
n 1968, unei echipe de programatori i s-a cerut s dezvolte un compilator
FORTRAN pentru trei maini diferite.

Rezultate:
Compilatorul Efortul (n luni-om)
1 72
2 36
3 14

Consultarea experilor
Metoda Delphi
Fiecare expert i expune opinia n scris. Un moderator colecteaz estimrile
obinute astfel i le redistribuie celorlali experi. Numele experilor nu sunt
asociate cu estimrile lor. Fiecare expert va preda o nou estimare bazat pe
informaiile primite de la moderator. Procesul continu pn cnd se ajunge la un
consens


214
Distribuia beta
Un expert realizeaz mai multe estimri: o estimare optimist a, o estimare
realist m i o estimare pesimist b.
Efortul ateptat va fi:
E =(a +4m +b) / 6,
o estimare mai bun probabil dect dac s-ar fi considerat numai media
aritmetic a lui a i b.

9.3.Modele algoritmice clasice - Modele liniare
Efortul pentru realizarea unui proiect este:

Coeficienii a
i
sunt constante, iar x
i
reprezint factorii care au impact
asupra efortului necesar;
E reprezint efortul (de exemplu, numrul necesar estimat de luni-om);

Modelul Nelson
E =-33,63 +9,15x
1
+10,73x
2
+0,51x
3
+0,46x
4
+0,40x
5
+7,28x
6
-21,45x
7

+ 13,5x
8
+12,35x
9
+58,82x
10
+30,61x
11
+29,55x
12
+0,54x
13
-25,20x
14

Factor Descriere Valori posibile
x
1
Instabilitatea specificaiilor cerinelor 0-2
x
2
Instabilitatea proiectrii 0-3
x
3
Procentajul de instruciuni matematice 0-100
x
4
Procentajul de instruciuni I/O 0-100
x
5
Numrul subprogramelor numr
x
6
Utilizarea unui limbaj de nivel nalt 0(da) / 1(nu)
x
7
Aplicaie comercial 0(da) / 1(nu)
x
8
Program de sine stttor 0(da) / 1(nu)
x
9
Primul program pe aceast main 1(da) / 0(nu)
x
10
Dezvoltare concurent de hardware 1(da) / 0(nu)
x
11
Utilizarea dispozitivelor random-access 1(da) / 0(nu)
x
12
Main gazd diferit de maina int 1(da) / 0(nu)
x
13
Numr de erori numr
x
14
Dezvoltare pentru o organizaie militar 0(da) / 1(nu)

215

Dac avem o estimare E, atunci efortul real R va verifica formula:

unde valori acceptabile pentru i sunt:
=0,2 i =0,9.
Exemplu: S presupunem c estimarea este de 100 luni-om. Atunci
probabilitatea ca proiectul s necesite n realitate ntre 80 i 120 de luni-om este
mai mare ca 90%. Exist o probabilitate diferit de zero ca efortul real s fie n
afara intervalului.

Modelul Wolverton
Este o abordare bottom-up cu o matrice de costuri, care are un numr limitat
de tipuri diferite de module i un numr de nivele de complexitate.

Complexitate
Tipul modulului Mic Mare
1. Management de date 11 13 15 18 22
2. Management de memorie 25 26 27 29 32
3. Algoritm 6 8 14 27 51
4. Interfa utilizator 13 16 19 23 29
5. Control 20 25 30 35 40

Fiind dat o matrice de costuri C, un modul de tip I, complexitate j i mrime
S
k
, va rezulta un cost al modulului M
k
=S
k
C
ij

9.4. Modele algoritmice moderne Modele neliniare
Forma general este:

Valorile constantelor a, b, c rezult pe baza unei analize de regresiune a
datelor proiectelor disponibile. De obicei, f nu se ia n considerare.


216
Constanta c

c < 1: analogie cu producia de mas (costurile fixe se mpar pe mai
multe uniti de produs);
c > 1: efortul crete exponenial cu mrimea datorit creterii
complexitii
o Pentru proiecte mari, aceast relaie pare mai plauzibil.

Exemple

KLOC Halstead Boehm Walston-Felix
1 0,7 2,4 5,2
10 22,1 26,9 42,3
50 247,5 145,9 182,8
100 700 302,1 343,6
1000 22135,9 3390,1 2792,6

Modelul Walston-Felix
A fost creat prin analiza a 60 de proiecte de la IBM. Proiectele erau complet
diferite ca mrime, iar programele au fost scrise n mai multe limbaje de
programare. Au fost identificate 29 de variabile care influeneaz productivitatea.
Pentru fiecare din aceste variabile au fost considerate trei niveluri: mare, mediu
i mic.


217

Variabila Productivitatea medie pentru
valoarea variabilei
PC
Complexitatea interfeei utilizator <normal
500
normal
295
>normal
124
376
Calificarea i experiena personalului mic
132
medie
257
mare
410
278
Experiena anterioar cu aplicaii similare minim
146
medie
221
vast
410
264
Procentajul de programatori participani n
faza de proiectare
<25%
153
25 - 50%
242
>50%
391
238
Raportul dintre mrimea medie a echipei i
durata proiectului (persoane/lun)
<0,5
305
0,5 0,9
310
>0,9
171
134

Walston i Felix consider c indexul productivitii I poate fi determinat
pentru noile proiecte dup urmtoarea relaie
i
i
i
X W I

29
1

unde ponderile W
i
sunt definite astfel:
) ( log 5 , 0
10 i i
PC W

Modelul COCOMO
Modelul COCOMO COnstructive COst MOdel a lui Boehm este unul
dintre cele mai cunoscute modele de cost care se aplic proiectelor.
Sunt trei clase de proiecte:
Organice: o echip relativ mic dezvolt programul ntr-un mediu
cunoscut. Sunt de obicei programe relativ mici.
Integrate: sisteme pentru care mediul impune constrngeri severe (de ex.
programe de control al traficului aerian sau aplicaiile militare);
Semidetaate: o form intermediar;


218
Exemple

Clasa de proiect b c
organic 2,4 1,05
semidetaat 3,0 1,12
integrat 3,6 1,20

KLOC organic semidetaat integrat
1 2,4 3,0 3,6
10 26,9 39,6 57,1
50 145,9 239,4 392,9
100 302,1 521,3 904,2
1000 3390 6872 14333

Analiza punctelor funcionale
Se bazeaz pe numrarea diferitelor structuri de date utilizate. Este potrivit
mai ales pentru aplicaiile comerciale, n care structura datelor are o foarte mare
importan. Este mai puin indicat pentru proiectele n care algoritmii joac rolul
dominant (de ex. compilatoarele sau aplicaiile n timp real).
Analiza se bazeaz pe modalitile n care diveri utilizatori interacioneaz
cu aplicaiile.
Se consider c sistemul ndeplinete cinci funcii fundamentale:
- Funcii referitoare la date
1. Fiiere interne logice;
2. Fiiere externe de interfa ;
- Funcii tranzacionale
3. Intrri externe;
4. Ieiri externe;
5. Cereri externe;


219
1. Fiiere interne logice n englez Internal Logical Files, FIL. Permit
utilizatorilor s foloseasc datele pe care trebuie s le ntrein. De
exemplu, un pilot poate introduce datele de navigare la un terminal din
carling nainte de plecare. Datele sunt stocate ntr-un fiier i pot fi
modificate n timpul misiunii. Pilotul este deci responsabil pentru
ntreinerea acestor date.
2. Fiierele externe de interfa n englez External Interface Files, FEI.
Utilizatorul nu este responsabil pentru ntreinerea datelor; acestea sunt
localizate n alt sistem care le ntreine. Utilizatorul sistemului analizat
solicit datele doar pentru informare. De exemplu, un pilot se poate
informa asupra poziiei cu ajutorul sateliilor GPS sau al sistemelor de la
sol. El nu are responsabilitatea actualizrii acestor date, ns le poate
accesa n timpul zborului.
3. Intrrile externe, n englez , External Input, IE. Permit utilizatorului s
ntrein fiierele interne logice prin operaii de adugare, modificare i
tergere.
4. Ieirile externe, n englez, External Output, EE. Permit utilizatorului s
produc date de ieire. De exemplu, pilotul poate s afieze separat
viteza la sol i viteza real n aer, informaii derivate din datele interne (pe
care le poate ntreine) i cele externe (pe care le poate accesa).
5. Cererile externe, n englez, External Inquiries, CE. Pentru ca
utilizatorul s poat selecta i afia datele din fiiere, el trebuie s
introduc informaii de selecie pentru a gsi datele n conformitate cu
anumite criterii. n aceast situaie datele din fiiere nu sunt modificate, ci
doar cutate i furnizate. De exemplu, dac pilotul afieaz date cu privire
la relieful solului, date stocate anterior, rezultatul este regsirea direct a
informaiilor.

Puncte funcionale neajustate
Prin ncercri repetate, s-au stabilit ponderi pentru fiecare dintre aceste
entiti. Numrul de puncte funcionale neajustate este:

220
PFN = 10
.
FIL + 7
.
FEI + 4
.
IE + 5
.
EE + 4
.
CE
n funcie de complexitatea tipurilor de date, se disting o serie de valori
penrtu aceste puncte funcionale, prezentate n tabelul urmtor:

Nivel de complexitate
Tip Simplu Mediu Complex
FIL 7 10 15
FEI 5 7 10
IE 3 4 6
EE 4 5 7
CE 3 4 6

Puncte funcionale ajustate
Pentru ajustarea suplimentar a estimrilor, se iau n calcul i alte 14
caracteristici care influeneaz dezvoltarea aplicaiilor:
Comunicaiile de date
Funciile distribuite
Performana
Folosirea masiv a configuraiilor
Rata tranzaciilor
Intrrile de date online
Eficiena utilizatorilor finali
Actualizrile online
Prelucrrile complexe
Refolosirea
Uurina la instalare
Uurina la folosire
Locaiile multimple
Facilitarea modificrilor

221
Influena fiecrei caracteristici este evaluat pe o scar de la 0 (nu
influeneaz) la 5 (influen puternic). Gradul de influenare GI este suma
acestor puncte pentru toate caracteristicile
Se calculeaz apoi factorul de complexitate tehnic: FCT =0,65 +0,01 *
GI
Punctele funcionale ajustate (PF) se obin astfel: PF =PFN * FCT.
Avantaje
Msura productivitii este un rezultat natural, deoarece punctele
funcionale sunt independente de tehnologie i deci pot fi utilizate pentru a
compara productivitatea pe platforme diferite i cu instrumente de
dezvoltare diferite;
Ele pot fi folosite pentru a stabili o rat de productivitate (PF / h) care
faciliteaz estimrile privind durata proiectului ca ntreg;

Distribuirea forei de munc n timp
Modelul Putnam-Norden
Distribuia forei de munc n timp are de multe ori o form caracteristic, bine
aproximat de distribuia Rayleigh. Astfel, fora de munc necesar la un
moment de timp t este:

Maximul curbei este apropiat de momentul de timp n care proiectul va fi
predat clientului. Acest rezultat este foarte apropiat de o regul euristic foarte

222
des utilizat: 40% din efortul total este cheltuit pentru dezvoltarea efectiv, n
timp ce 60% este cheltuit pentru ntreinere.

Ecuaia software-ului
Putnam a folosit observaii empirice legate de nivelurile de productivitate
pentru a deriva ecuaia software-ului din curba Rayleigh:
3 / 4 3 / 1
t E k D ,
Unde D este dimensiunea proiectului, E este efortul total n ani-om, t este
timpul scurs pn la lansare n ani iar K este un factor tehnologic bazat pe 14
componente, precum:
Maturitatea general a proiectului i tehnicile de management;
Gradul de utilizare a tehnicilor de ingineria programrii;
Nivelul limbajelor de programare folosite;
Capacitatea i experiena echipei de dezvoltare;
Complexitatea aplicaiei.
Efortul
Pentru estimarea efortului, Putnam a introdus ecuaia acumulrii forei de
munc:
A= E/t
3
,
unde A este numit accelerarea forei de munc iar E i t au semnificaiile de mai
sus.
Accelerarea forei de munc este 12,3 pentru proiecte software noi, cu
multe interfee i interaciuni cu alte sisteme, 15 pentru sisteme de sine
stttoare i 27 pentru reimplementri ale sistemelor existente.
Pe baza celor dou ecuaii putem elimina timpul i determina efortul:
E = (D/k)
9/7.
A
4/7
Acest rezultat este interesant deoarece arat c efortul este proporional cu
dimensiunea la puterea 9/7 1,286, valoare similar cu factorul Boehm, ntre
1,05 i 1,20.


223
Consecine
Scurtarea timpului de dezvoltare implic un numr mai mare de persoane
necesare pentru proiect;
Referindu-ne la modelul curbei Rayleigh, scurtarea timpului de dezvoltare
conduce la mrirea valorii a, factorul de accelerare care determin panta iniial
a curbei; vrful curbei Rayleigh se deplaseaz spre stnga i n acelai timp n
sus;
Astfel obinem o cretere a puterii necesare la nceputul proiectului i o
for de munc maxim mai mare.

Legea lui Brooks
Mai multe studii au artat c productivitatea individual scade odat cu
creterea echipei. Conform lui Brooks, exist dou cauze ale acestui fenomen:
Crete timpul acordat comunicrii cu ceilali membri ai echipei (pentru
consultare, sincronizarea sarcinilor etc.);
Mai nti scade productivitatea, deoarece noii membri ai echipei nu
sunt productivi de la nceput. n acelai timp ei necesit ajutor, deci
timp, de la ceilali membri ai echipei n timpul procesului de nvare
Legea lui Brooks: adugarea de personal la un proiect ntrziat l va
ntrzia i mai mult.

Mrimea echipei i productivitatea
Productivitatea individual (msurat n linii de cod pe lun-om) scade cu
mrimea echipei.


224
Mrimea echipei Productivitatea individual Productivitate
total
1 500 500
2 450 900
3 400 1200
4 350 1400
5 300 1500
5,5 275 1512
6 250 1500
7 200 1400
8 1500 1200

Concluzii
Nu exist o relaie simpl ntre preul unui sistem i costul su de
dezvoltare;
Factorii care afecteaz productivitatea includ aptitudinile individuale,
experiena n domeniu, natura proiectului, dimensiunea proiectului,
instrumentele utilizate i mediul de lucru;
Preul unui produs software poate fi stabilit astfel nct s se ctige un
contract i apoi funcionalitatea este ajustat conform preului;
Pentru estimarea costului pot fi folosite tehnici diferite;
Modelele algoritmice de estimare a costurilor se bazeaz pe analiza
cantitativ a caracteristicilor proiectelor, permind compararea influenei
acestor caracteristici;
Timpul necesar terminrii unui proiect nu este proporional cu numrul de
persoane care lucreaz la proiect.


225

10

Calitatea sistemelor software

10.1. Indicatori de calitate
Dei software-ul a aprut mai trziu ca domeniu al ingineriei, calitatea lui
trebuie demonstrat i garantat. Problema care a aprut astfel n ingineria
software se refer la modul n care se definete n acest caz calitatea.
n conferinele specialitilor din domeniu au existat argumente c s-ar
putea defini drept: "ceva potrivit pentru utilizare", sau "satisfacerea cerinelor
utilizatorilor" sau "absena defectelor" (Grady, 1993).
Unul dintre principalele obiective ale ingineriei software este de a pune la
dispoziie dezvoltatorilor metodologii i instrumente pentru a realiza software de
mai bun calitate. Tabelul 10.1 elaborat de Mayer, prezint cu titlu de exemplu
zece factori de calitate ai software-ului. Aceti factori pot fi contradictorii, cum ar
fi de exemplu portabilitatea i integritatea care aduc adesea prejudicii eficacitii,
dar ofer o platform comun de comparare i evaluare a produselor software.
Calitatea va fi adesea rezultatul unui compromis. Cnd se lucreaz fr
un instrument de realizare, acest compromis se face ntr-o manier inconsistent
de ctre programator, ceea ce nu este de dorit.
Cnd se lucreaz cu un instrument software, aceasta se face ntr-o
manier mai mult sau mai puin voluntar, de ctre constructorul instrumentului
software respectiv.

226
ntre eficacitate i fiabilitate, majoritatea instrumentelor au ales deja, dar
mai trebuie ca nivelul de compromis care a fost adoptat s fie i acceptat de cei
care cumpr instrumentul software respectiv.
Validitatea este aptitudinea software-ului de a-i ndeplini corect funciile.
Transpus n planul concepiei, aceast aptitudine ajut ca specificaiile
definite s reflecte ntr-adevr cerinele utilizatorilor.
Fiabilitatea este aptitudinea produsului software de a funciona n condiii
anormale, n conformitate cu specificaiile sale de proiectare (definiie dat de
Mayer). De exemplu, rezistena la introducerea de date incorecte, reluri posibile
n caz de pan a sistemului (software sau hardware), posibilitile de a lucra
cnd totui sistemul este degradat, etc. Acest factor nu este independent de
contextul tehnic n care se utilizeaz aplicaia software.

Tabelul 10.1. Factorii de apreciere ai calitii - B. Mayer
Factor Definiii
Validitate Aptitudinea produsului software de a ndeplini exact funciile
sale, definite prin caietul de sarcini i prin specificare.
Fiabilitate Aptitudinea produsului software de a funciona n condiii
anormale
ExtensibilitateUurina cu care un software se preteaz la o modificare sau
la o extindere a funciilor solicitate.
ReutilizibiltateAptitudinea unui produs software de a fi reutilizat, n totalitate
sau i parial, ntr-o nou aplicaie.
CompatibilitateUurina cu care un sistem poate fi combinat cu altele
Eficacitate Utilizarea opional a resurselor materiale (procesoare,
memorie intern i extern, protocoale de comunicaie, etc)
Portabilitate Uurina cu care un produs poate fi transferat pe medii
diferite hardware i software.
VerificabilitateUurina cu care se pregtesc procedurile i testele de validare
(n particular jocurile de ncercare) i procedurile de
detectare a erorilor care urmeaz unui incident n exploatare.
Integritate Aptitudinea software-ului de a-i proteja codul i datele de
accesri neautorizate.
Uurina de
utilizare
Facilitatea de nelegere, de utilizare, de pregtire a datelor, de
interpretare a erorilor, de revenire n caz de utilizare eronat.

Extensibilitatea este posibilitatea de a modifica cu uurin software-ul, n
ideea adugrii de noi funcii sistemului . Este un factor de calitate dificil de

227
msurat, pentru c adesea se leag de nivelul limbajului de programare (de
exemplu, este mai uor de modificat n Cobol dect n limbaj de asamblare, este
mai uor de modificat n Pascal dect n Cobol).
Reutilizarea este aptitudinea software-ului de a putea fi utilizat n aplicaii
noi. Conceptul nu este nou, de mult vreme se fac subprograme generale de
tratare a datelor, sau schelete de programe care s automatizeze diverse funcii.
Propietatea de motenire aprut n abordarea orientat pe obiecte a
permis ca metodele scrise pentru un obiect s poat fi motenite de un altul.
Compatibilitatea, a nu se confunda cu portabilitatea, reprezint uurina cu
care un produs software poate fi combinat cu altele. Este nevoie n unele situaii
s se achiziioneze aplicaii din exterior (care vor deveni subsisteme n aplicaia
care se realizeaz) i care trebuie s funcioneze mpreun cu aplicaiile deja
existente.
Eficacitatea este utilizarea optimal a resurselor materiale. De cnd exist
Informatica, puterea mainilor se dubleaz la fiecare 18 luni, dar tot este
insuficient pentru a putea ignora problemele de performan.
Pe de o parte, se realizeaz aplicaii din ce n ce mai sofisticate care
presupun calculatoare performante, pe de alt parte gradul de putere al mainii
este consumat pentru confortul utilizatorului : pe un Macintosh sau un PC sub
Windows, mai mult de 80% din capacitate este utilizat pentru a trata interfaa
grafic, i numai 20% rmn pentru a putea fi utilizai de aplicaie.
Portabilitatea este uurina cu care un produs software poate fi transferat
pe un alt hardware sau sistem de operare.
Acesta este un criteriu pe care furnizorii de instrumente l pun n fa, pentru
c permite diminuarea dependenei utilizatorului de hardware.
Verificabilitatea este facilitatea prin care se pregtesc procedurile de
tratare i validare a sistemului. Este un criteriu interesant la care trebuie reflectat
puin: se poate cu uurin verifica dac un sistem merge sau nu, se pot construi
teste de ncercri care s garanteze c o parte din software sau tot sistemul
funcioneaz ?

228
Cnd ne confruntm cu o problem de testare a unui software care nu este
cunoscut i nici nu a mai fost realizat pn atunci, nu este uor de stabilit dac
rezultatul furnizat de sistem este corect sau nu.
Integritatea este aptitudinea sistemului de a-si proteja codul i datele
de utilizri neautorizate; este mai mult o caracteristic general de mediu n care
trebuie s funcioneze sistemul, dect o caracteristic direct furnizat prin
instrumentul software. Dar, instrumentul trebuie eventual s suplineasc
carenele mediului de dezvoltare.
Facilitatea de utilizare reprezint tot ceea ce este legat de ergonomia
aplicaiei, de uurina cu care este utilizat. Nu este acelai lucru pentru utilizator
dac nelege intuitiv i repede modul n care funcionez sistemul sau i trebuie
trei luni pentru a-l face operaional.
De asemenea, nu este acelai lucru dac primete un mesaj de eroare
clar, sau trebuie s consulte un manual pentru a-i nelege semnificaia.
Ergonomia este pe punctul de a deveni un criteriu foarte important pentru
funcionalitatea nsi a sistemului, pentru c, fr ndoial, se consider drept
competen a unui sistem dac el se achit corect de sarcina sa (criteriul de
validitate).

10.2. Productivitatea

Al doilea obiectiv al unui instrument software este de a produce software ct
mai repede posibil . Cum calitatea i productivitatea acoper aspecte diferite, ele
presupun adesea un compromis. Dac se vizeaz productivitatea n mentenan,
va trebui fr ndoial s se investeasc mai mult n concepie, pentru a gsi
structuri de date mai generale i s se determine ceea ce poate fi parametrizat.
Dar aceasta se va face n detrimentul termenului de livrare al software-ului.
Dac, din contra, obiectivul este s fie ceva care funcioneaz, modul de
abordare este altul. Sunt situaii n nu exist alt alegere sau sunt cazuri extreme
care pot justifica existena chiar a dou instrumente de dezvoltare, unul care s
produc mai repede, dar care furnizeaz un cod mai puin eficient sau mai puin

229
mentenabil, cellalt care permite s se lucreze mai riguros, atunci cnd este timp
pentru aceasta.
Productivitatea are punct de conflict cu calitatea atunci cnd se atinge un
nivel minim al acesteia din urm, sub care nu se poate cobor.
Productivitatea unui proiect trebuie s se msoare n mod global, la captul
mai multor ani de utilizare care s includ toate fazele, de la concepie la
mentenan. n practic, se ntmpl relativ rar s se msoare productivitatea n
afara fazei de realizare, ceea ce este cu certitudine interesant, dar nu reprezint
dect o mic parte din ceea ce trebuie msurat.
Cu ct productivitatea de realizare a unui proiect este mai mare, cu att
timpul de livrare al produsului scade i implicit i costul produsului va fi mai mic.
Mai mult, interesul productorilor de software pentru achiziionarea de
instrumente performante de lucru care s mreasc productivitatea va fi n
continu cretere.

10.3. Asigurarea fiabilitii produselor software
10.3.1. Niveluri prescrise de fiabilitate
nc din faza stabilirii cerinelor i specificaiilor pentru o aplicaie
informatic trebuie s se impun nivelul de fiabilitate al sistemului ca un
compromis ntre preul de cost i consecinele defectrilor. Astfel un produs
software conceput pentru cercetri spaiale cu participare uman trebuie s aib
o fiabilitate mai mare dect unul pentru jocuri pe calculator. Este necesar deci ca
produsele software s se nscrie n anumite clase de fiabilitate. Clasele de
fiabilitate sunt urmtoarele:
a) Foarte sczut (very low). Acest nivel se prescrie atunci cnd defectarea are
ca singur consecin inconvenientul productorului de a nltura o neregul n
program. Asemenea situaie intervine, de exemplu n cazul modelelor
demonstrative sau al simulrilor.
b) Sczut (low). Acest nivel corespunde n cazurile n care defectarea implic o
pierdere mic, uor de recuperat, pentru beneficiar. Sistemele utilizate n
predicie pe termen lung sunt exemple tipice.

230
c) Nominal (nominal). Acest nivel corespunde cazului cnd defectarea implic o
pierdere moderat pentru beneficiar, dar remedierea situaiei nu este prea
costisitoare. Sistemul de gestionare a stocurilor sau sistemele informaionale de
conducere sunt exemple tipice pentru aceast clas de fiabilitate.
d) Ridicat (high). Efectele defectrii pot implica o pierdere financiar mare sau
un inconvenient major pentru factorul uman. Exemple tipice sunt sistemele
bancare i cele ale distribuiei energiei electrice.
e) Foarte ridicat (very high). Efectele defectrii pot consta n pierderi de viei
omeneti. Cazul tipic l constitue sistemul de control al reactoarelor nucleare.
n funcie de nivelul de fiabilitate prescris, se poate stabili ce efort necesar s fi
alocat n fiecare etap a realizrii produsului. n fig. 7.5 se reprezint acest
efort normat la cel necesar obinerii unei fiabiliti nominale. Figura poate fi
utilizat i n vederea evalurii produsului pe baza efortului investit n procesul
de realizare. Se observ c diferenele n ceea ce privete efortul investit
devin mai mari n fazele de integrare i testare.
10.3.2. Proiectarea structurii pentru asigurarea fiabilitii
Asigurarea fiabilitii la nivelul proiectului se bazeaz pe realizarea unei
structuri ct mai simple i transparente. Pentru a avea un control asupra acestor
caracteristici trebuie s se cunosc:
P
1
= numrul total de module din program
P
2
= numrul de module dependente de intrri (I) sau ieiri (E)
P
3
= numrul de module dependente de o procesare anterioar
P
4
= numrul de elemente din bazele de date
P
5
=numrul elementelor neunice din baza de date (BD)
P
6
= numrul de segmente din baza de date (BD)
P
7
= numrul de module cu mai mult de o intrare i o ieire
Cu ajutorul mrimilor P
1
- P
7
se evalueaz ase mrimi derivate D
1
- D
6

care exprim simplitatea structurii programului. Cu ct valorile D
i
sunt mai mari,
cu att este mai ndoielnic fiabilitatea programului.
D
1
este o variabil binar egal cu zero dac proiectarea este descendent
(top-down) i cu 1 n caz contrar;

231
D
2
exprim dependena la nivelul modulelor;
D
3
exprim dependena de procesarea anterioar;
D
4
arat mrimea bazei de date;
D
5
arat compartimentarea bazei de date;
D
6
arat mrimea interaciunii programului cu exteriorul;

Fig.10.1 Reprezentarea efortului pentru asigurarea nivelului de fiabilitate prescris

O sintez a mrimilor D
1
- D
6
este dat de indicele de structurare a
proiectului DSM, care are expresia:

= =
= =
6
1 i
6
1 i
i i i
1 w , D w DSM
unde w
i
sunt ponderi alese n funcie de importana fiecrei caracteristici D
i
.
Valori apropiate de 1 pentru D
1
- D
6
, respectiv pentru DSM, indic o deficien a
proiectului care trebuie corectat prin reproiectare, astfel nct s se micoreze
mrimile primare P
1
- P
7
. Orice modificare n proiect trebuie analizat din unghiul
de vedere al indicelui de structurare, pentru a decide n ce msur modificarea
propus mbuntete proiectul. Indicele de structurare permite de asemenea
evaluar ea comparativ a unor proiecte diferite.

very high

high

nominal

low

very low
1,4

1,2

0,8

0,6
1
Cerine-Specificaii Proiectare Implementare Testare

232
10.3.3. Complexitatea fluxului informaional
Pn acum s-a avut n vedere structura proiectului privit din punct de
vedere static. Abordnd un punct de vedere dinamic, este necesar s se
considere complexitatea fluxului de informaie, care parcurge structura. n acest
scop, se determin fluxul de informaie ntre module, considerndu-se c un flux
de informaie de la A la B are loc dac:
(1) A apeleaz B sau,
(2) B apeleaz A i A returneaz o valoare utilizat ulterior de B sau,
(3) att A ct i B sunt apelai de un alt modul care face s treac o valoare de la
A la B.
Fie:
l
fi
nr. de fluxuri care intr ntr-o procedur (local flows into);
l
fo
nr. de fluxuri care iese dintr-o procedur (local flows out);
datain = numrul structurilor de date din care o procedur i ia datele
dataout = numrul structurilor de date care sunt actualizate de
procedur
lenght = numrul de instruciuni scrise ntr-o procedur (inclusiv
comentariile).
Pentru a evalua complexitatea fluxului informaional global se calculeaz
numrul de ci informaionale care intr n, respectiv ies din, module:
fanin =l
fi
+ datain;
fanout =l
fo
+dataout
n ansamblu, complexitatea informaional IFC este dat de expresia:
IFC =length (fanin * fanout)
2
.
Cu ajutorul acestei caracterizri se pot identifica acele module care, avnd
o complexitate informaional mai mare, sunt probabil afectate de erori, deci au o
fiabilitate mai redus. Se identific, de asemenea, procedurile care au mai mult
dect o funcie, punctele de trafic informaional intensiv i modulele cu o
complexitate funcional excesiv.
Examinarea complexitii informaionale trebuie ntreprins n faza
proiectrii detaliate i n faza integrrii produsului.

233

10.4. Metrici software pentru paradigma orientat pe obiect

Acestea nu sunt att de numeroase ca n cazul paradigmei procedurale.
S-au propus (Chidamber i Kemerer, 1991) ase metrici de proiectare
orientate obiect i anume:
- DIT (Depth of the Inheritance Tree) - adncimea arborelui de motenire;
- NOC (Number of Children) - numrul de motenitori;
- CBO (Corepling Between Object) - cuplarea dintre obiecte;
- RFC (Response For a Class) - rspunsul pentru o clas;
- LCOM (Lack of Cohesion of Methods) - lipsa coeziunii metodei
- WMC (Weighted Method per Class) - ponderea metodei n clas.
a). Metrica DIT msoar poziia clasei n ierarhia de clase. Se adreseaz
conceptului de motenire din OOP. Se poate face ipoteza c cu ct este mai
mare metrica DIT cu att este mai greu de meninut clasa. Valoarea metricii DIT
este dat de numrul nivelului clasei n ierarhia de clase. DIT-ul pentru rdcin
este zero.
DIT = numrul de nivel de motenire
DIT e [ 0, N ], N > 0
b). Metrica NOC msoar numrul de motenitori direci ai unei clase. Se
are n vedere acelai concept de motenire din OOP dar se consider c cu ct
numrul de motenitori direci ai unei clase este mai mare cu att este mai
afectat potenialul de motenire.
De exemplu, dac sunt mai multe subclase a unei clase care au
dependene de metode sau instane de variabile definite n superclase atunci
orice schimbri n aceste metode sau variabile afecteaz subclasele.
Se poate spune c cu ct este mai mare metrica NOC cu att este mai greu
de meninut clasa. Deci:
NOC = numrul subclaselor directe
NOC e [ 0, N ], N >0

234
c). Metrica RFC msoar cardinalitatea clasei, rspunsuri ale unei clase.
Mulimea de rspunsuri ale unei clase const din toate metodele locale i toate
celelalte metode apelate de metodele locale. Pare intuitiv c, cu ct este mai
mare mulimea de rspunsuri, cu att mai complex este clasa.
Deci cu ct este mai mare metrica RFC cu att mai dificil este de meninut
clasa din cauza apelurilor unui numr mare de metode n rspunsul crora se pot
depista cu dificultate erorile.
RFC = numrul de metode locale + numrul de metode apelate de
metodele locale.
RFC e [ 0, N ] ; N >0
d). Metrica LCOM msoar lipsa coeziunii clasei. Coeziunea unei clase este
caracterizat prin ct de strns sunt legate metodele locale de variabile locale
instaniate n clas. Aceast metod se adreseaz conceptului de metod din
OOP. Pare logic c o clas care are o mai mare coeziune este mai uor de
ntreinut. Deci cu ct metrica LCOM este mai mare cu att este mai dificil de
ntreinut clasa, deoarece dac toate metodele definite din clas acceseaz mai
multe seturi independente de structuri de date incapsulate n clas, clasa nu
poate fi bine proiectat i partiionat.
LCOM = numrul de seturi disjuncte din metodele locale.
Nu exist intersecie a dou mulimi i nici dou metode care s aib n
comun o variabil local n domeniul [ 0, N ] , N > 0.
e). Metrica WMC msoar complexitatea static a tuturor metodelor. Intuitiv,
cu ct exist mai multe metode, cu att mai complex este clasa. De asemenea,
cu ct este mai mare fluxul de control al metodelor unei clase cu att mai dificil
este de neles i de ntreinut.
WMC = suma complexitilor ciclice McCabe din metodele locale.
WMC e [ 0, N ] , N >0.
McCabe a definit complexitatea ciclic ca o msur bazat pe controlul
fluxului n proceduri/funcii. Complexitatea ciclic se bazeaz pe complexitatea
din graful direct.

235
Pentru programele structurate o echivalen mai simpl pentru
complexitatea ciclic este contorizat de condiiile booleene simple din structurile
de control (adic while, if, case, do-while, for, etc).
McCabe (1989) a extins apoi complexitatea ciclic pentru a msura
diagrama de structur de proiectare.

10.4.1. Metrici de definire i adugare orientate pe obiect
Dou obiecte se spune c sunt cuplate dac ele acioneaz unul cu cellalt.
Formele de cuplare ale obiectelor sunt: cuplare prin motenire, cuplare prin
transmitere de mesaje i cuplare prin date abstracte.
Cuplarea prin motenire
Motenirea promoveaz reutilizarea software-ului n metodele orientate pe
obiect, dar creeaz de asemenea posibilitatea violrii ncapsulrii i ascunderii
informaiei. Aceasta apare deoarece proprietile din superclase sunt expuse
subclaselor fr nici o restricie de acces. Utilizarea motenirii, dac nu este bine
proiectat, poate introduce complexitate suplimentar n sistem, datorat
atributelor care sunt ncapsulate n superclas care sunt expuse fr restricii
accesului din subclase. Mai mult, o clas motenete mai multe atribute
neprivate dect acceseaz. DIT i NOC sunt folosite pentru msurarea
caracteristicilor de motenire.
DIT indic cte subclase are o clas, artnd astfel cte clase depind de o
anumit clas. NOC indic cte clase pot fi direct afectate de o clas.
Cuplarea prin transmiterea de mesaje
Un canal de comunicare n tehnologia OOP este transmiterea de mesaje.
Cnd un obiect are nevoie de servcii de la alt obiect, el transmite un mesaj.
Mesajul se compune de obicei din identificatorul obiectului, serviciul (metoda)
solicitat i lista de parametrii pentru metod.
Cuplarea prin mesaje (MPC Message Passing Coupling) este utilizat
pentru msurarea complexitii mesajului care trece prin clase. Deoarece tipul

236
unui mesaj este definit de o clas i utilizat de obiectele clasei, metrica MPC d
de asemenea un indiciu despre cte mesaje trec printre obiectele clasei.
MPC = numrul de "instruciuni" definite i transmise ntr-o clas.
Numrul de mesaje transmise n afar de o clas poate indica ct de
dependent este implementarea unei metode locale de alte metode din alte
clase.
Aceasta nu poate fi sugestiv pentru numrul mesajelor recepionate de o
clas.
Cuplarea prin tipuri abstracte de date
Conceptul de tip de dat abstract (ADT) a fost introdus de McGregor
(McGregor, 1990), iar clasa poate fi privit ca o implementare a ADT-ului.
O variabil declarat n interiorul unei clase X poate avea tipul ADT care,
este o alt definiie a clasei, determinnd astfel un tip special de cuplare dintre X
i cealalt clas, pentru c X are acces la proprietile clasei ADT. Acest tip de
cuplaj poate produce violarea ncapsulrii dac limbajul de programare permite
accesul direct la proprietile private din ADT. Metrica care msoar
complexitatea de cuplaj determinat de ADT este cuplajul prin date abstacte
(DAC):
DAC =numrul de ADT-uri definite ntr-o clas.
Numrul de variabile care au ca tip ADT poate indica numrul de structuri
de date dependente de definiiile altor clase.
O alt metric utilizat este numrul de metode dintr-o clas (NOM).
Deoarece metodele locale dintr-o clas constituie interfa clasei, NOM servete
drept cea mai bun metric de interfa.
NOM = numrul de metode locale.
Numrul de metode locale definite ntr-o clas poate s indice
proprietatea de operare a unei clase. Mai multe metode ntr-o clas constituie o
interfa mai complex a clasei.

237
10.4.2. Metrici de dimensiune
Acest tip de metrici software au fost mult timp utilizate n aprecierea
software-ului. Metrica "linie de cod" - LOC este folosit pentru a msura o
procedur sau o funcie, iar cumularea metricilor LOC din toate procedurile i
funciile este folost pentru msurarea programului. Totui dimensiunea n OOP
nu este ntotdeauna bine stabilit.
n OOP n locul metricii LOC, care este calculat numrnd simbolurile ";"
dintr-o clas, se va folosi metrica numit SIZE1 care face acelai lucru.
SIZE1 =numrul de ";" dintr-o clas.
A doua metric de dimensiune folosit este numrul de proprieti
(incluznd atribute i metode) definite ntr-o clas. Aceast metric este SIZE2 i
este egal cu numrul de atribute plus numrul de metode locale.

Concluzii:
Pentru a fi utile aceste metrici trebuie incluse ntr-o analiz care s aib la
baz un model matematic, date i instrumente.
Modelul poate fi unul statistic, dac datele colectate sunt suficiente,
(numeroase), iar instrumentele trebuie s aib n vedere un anumit limbaj de
programe orientat pe obiecte i eventuale instrumente de "nregistrare" ale
acestor metrici.

10.5. Modele de studiere a posteriori a fiabilitii produselor
software

n literatura de specialitate exist o serie de metode i modele care permit
studierea fiabilitii sistemelor software dup ce ele au fost proiectate (a
posteriori).
Aa cum s-a artat anterior, aceasta conduce la mrirea timpului de testare
i nu garanteaz n totalitate c la sfrit s-au eliminat toate erorile.
Fiecare model prezentat are la baz cteva ipoteze de lucru.
MODELUL I
Se bazeaz pe urmtorele ipoteze:
1. Exist un numr dat de erori la momentul iniial;

238
2. Rata de detecie a erorilor este proporional cu numrul erorilor
reziduale;
3. Fiecare eroare descoperit este imediat corectat, astfel nct
numrul erorilor coninute n program scade cu o eroare la fiecare
moment de detecie;
4. Rata erorilor ntre dou momente de detecie succesive este
constant.

N(o) o

t
Fig.10.2. Curba lui z(t)

Pornind de la aceste ipoteze, rata de detecie a erorilor z(t) se modeleaz
cu relaia:

z(t) = o (N d),
unde:
N - numrul iniial al erorilor;
o - un coeficient de proporionalitate, reprezentnd decrementul lui z(t)
corespunztor deteciei i coreciei unei erori;
d - numrul de erori detectate i corectate pn la momentul t.
Fig. 7.6 reprezint dependena lui z n funcie de t.
MODELUL II
Acest model se bazeaz pe urmtoarele ipoteze:
1. Numrul de erori existente ntr-un program la nceputul fazei de testare
descrete pe msur ce erorile sunt corectate;
2. Numrul de erori reziduale Nr este egal cu diferena ntre numrul de
erori iniial prezente N i numrul cumulativ de erori corectate Nc;
Z(t)

239
3. Numrul de instruciuni n limbaj main rmne constant.
Modul de variaie n timp a numrului de erori reziduale i a celor corectate
n conformitate cu acest model este reprezentat n Fig.10.3

Fig.10.3. Curba erorilor reziduale

c
r
+c
c
=N/I
c
c
- numr de erori corectate pe instruciune
c
r
- numr de erori reziduale pe instruciune
n intervalul de timp (t, t+At) scurs dup perioada de testare probabilitatea
de a avea o eroare, P
e
, este:
P
c
= c
r
r
u
At
unde este o constant determinat de structura programului, iar r
u
este rata de
utilizare a unei instruciuni.
Dar :
P
e
= z(t)At
z(t) = r
u
(N/I - c
c
(o))

MODELUL III
Acest model, pstrnd o parte din ipotezele i formulrile modelului I, este
valoros prin aceea c permite o delimitare mai precis a timpului (timp real de
execuie - adic timpul ct procesorul execut programul, n raport cu timpul
calendaristic de dezvoltare a programului). Modelul se bazeaz pe urmtoarele
ipoteze principale:

240
1. Rata de corecie a erorilor este proportional cu rata de detecie
a erorilor;
2. Rata erorilor instantanee este proporional cu numrul erorilor
reziduale;
3. Manifestarea tuturor erorilor care intervin n cursul execuiilor
programului este efectiv observat.
Rata de detecie a erorilor z(t) este modelat de relaia:
( ) d N z(t) =
,
unde:
N - numrul iniial al erorilor;
t - timpul cumulat de funcionare al unitii centrale;
o - coeficient de proporionalitate, estimat;
- coeficientul frecven de execuie (definit ca raportul dintre numrul
mediu de execuii a unei instruciuni i numrul total de instruciuni);
d - numrul de erori detectate i corectate pn la momentul t.
Numrul erorilor reziduale va fi:
N n =N
0
exp(- o t),
iar timpul mediu de erori:
0
N
e
TMIE
t

=

n relaiile anterioare N
0
reprezint numrul de erori inerente (necorectate
prin punerea la punct a programului).
MODELUL IV
n acest model erorile se clasific n erori critice i erori necritice; erorile
critice sunt cele care conduc la oprirea misiunii n curs de execuie, n care caz
sistemul este indisponibil. Compararea unui produs software n conformitate cu
acest model este dat de graful din fig. 10.4. Se fac urmtoarele notaii:
a - raportul dintre numrul de erori critice i numrul total al erorilor;

241
- rata de detecie a erorilor;
c
- rata de corecie a unei erori critice;
n
- rata de corecie a unei erori necritice.

Fig.10.4. Graful de stare

Din graf se poate distinge existena a patru stri, care au semnificaiile:
starea 1 - nu sunt erori, programul funcioneaz conform specificaiilor sale;
starea 2 -au fost detectate una sau mai multe erori necritice pentru
program; se ateapt s se gseasc un anumit numr de erori nainte de a le
corecta pe toate;
starea 3 -a fost detectat o eroare critic, dup detecia unui anumit nuimr
de erori necritice; aceasta este corectat imediat i apoi programul revine la
starea 2;
starea 4 -au fost detectate una sau mai multe erori critice; este acordat
prioritate coreciei acestora.
Aceste patru stri permit s se defineasc un model markovian de evoluie
a sistemului, pe baza cruia este posibil determinarea indicatorilor de fiabilitate.
De exemplu, disponibilitatea unui modul de program poate fi exprimat prin
ecuaia:
A(t) =P
1
(t) +P
2
(t)

unde P
1
(t) i P
2
(t) sunt probabilitile ca modulul s fie n strile 1 respectiv 2.
Starea
4
Starea
1
Starea
2
Starea
3

c

r

c

a (1-a) a

242
Pentru un numr de module M ale unui sistem, fiecare modul avnd
disponibilitatea A
i
(t), disponibilitatea ntregului sistem este:
( ) ( ) t A t A
i
M
1 i
S
=
=

MODELUL V
Acest model presupune ipotezele:
1. Produsul software conine un numr n de erori;
2. Fiecare eroare detectat este corectat, rata de detecie fiind ca i n
cazul modelelor precedente proporional cu numrul de erori rezultate;
3. Variabilele aleatoare, timpul de funcionare fr eroare i timpul de
corecie a erorii sunt distribuite exponenial.
Evoluia sistemului este descris de un model markovian, cruia i
corespunde graful de tranziie din Fig. 10.5.

Fig.10.5. Graful de tranziie n cazul modelului V

Se pot defini:
- Starea (n-k) - starea pentru care a fost corectat a (k-1) eroare i nu a
aprut nc eroarea numrului k;
m

m

m

m-1
m

m-k
m
m

n-2At
m-1At
n-1At
mAt
nAt
m-kAt
n-kAt n-k-1At
1-nAt 1-n-1At 1-n-2At 1-n-kAt 1-n-k-1At
1-mAt 1-m-1At 1-m-kAt

243
- Starea (m-k) - starea pentru care a fost detectat, dar nu i corectat,
eroarea numrului k;
-
n-k
At - probabilitatea de trecere din starea (m-k) la starea (m-k-1), fiind
rata de detecie a erorii;
-
m-k
At - probabilitatea de trecere din starea (n-k) n starea (n-k-1), fiind
rata de corecie a erorii
MODELUL VI
Se fac urmatoarele ipoteze:
1. Erorile software sunt independente de timpul de operare al
programului n cauz: dac programul este bine testat n
perioada de rodaj, nu vor apare erori de exploatare;
2. Atunci cnd mulimea datelor de intrare n exploatarea
programului nu coincid cu cele din perioada de rodaj, exist o
anumit probabilitate F s apar erori n cursul rulrii
programului.
Pornind de la aceste ipoteze, se poate determina probabilitatea de eroare a
unui program n funcie de formele posibile ale acestuia:
=
=
1
N
1 i
1 1
b P F
N
1
- reprezint numrul de forme posibile ale aceluiai program n
funcie de datele de intrare care, prin analogie cu terminologia
utilizat n cazul sistemelor materiale, se vor numi numr de
intrri ale unui program;
P
i
- probabilitatea de apariie a intrrii i;
b
i
- o funcie binar care ia valoarea 1 daca programul i este
eronat i 0 dac programul este corect.
Dac formele posibile ale programului au loc cu aceeai probabilitate
P
i
=1/N, atunci probabilitatea de eroare a programului devine:
i
1
N
1 i
i
N
b
F

=
=

244
Dac programul este testat pentru n intrri diferite i apar erori,
probabilitatea ca programul s fie eronat se va putea exprima ca:
1
1
1
N
F F
k k
=
+

Probabilitatea de eroare

Numarul de intrari care cauzeaza erori
Fig.10.6. Probabilitatea de eroare
n ipoteza ca o eroare odat detectat nu mai apare n aceleai condiii, se poate
exprima probabilitatea de eroare a unui program dup rodaj ca fiind:
1
k 1 k
N
1
F F =
+

unde s-au fcut notaiile:
F
k
- probabilitatea de eroare a programului nainte de rodaj;
F
k+1
- probabilitatea de eroare a programului dup rodaj;
N
1
- intrrile care conduc la un program eronat;
l - numrul de intrri ale sistemului logic (program) care cauzeaz erori n
timpul testarilor din perioada de rodaj F. F
k+1
i F
k
pot fi calculate pe baza relaiei
F=e/N, iar N
1
se estimez ca fiind panta dreptei din Fig.10.6, dreapt care poate
fi ridicat experimental n perioada de rodaj.


245
MODEL EMPIRIC DE STUDIU AL FIABILITII - MODELUL COMPLEXITII
Se consider urmtoarele categorii de compexitate:
a) COMPLEXITATEA LOGICII, se refer la codul surs al programului
(numr de instruciuni executabile, numr de instruciuni de selecie, numr de
instruciuni de iteraie, etc.).
salt sel it
e
t
log
C C C
I
I
C + + + =
I
t
- numrul total de instruciuni;
I
e
- numrul de instruciuni executabile;
C
it
- complexitatea iteraiilor;
=
i
i i it
w m C

n care: m
i
- numrul de cicluri de nivel i;
w
i
- factor de ponderare.
astfel nct
=
=
Q
1 i
i
1 w

Q este numrul maxim de imbricri de cicluri n program
C
sel
este complexitatea instruciunilor de selecie (IF)
=
i i sel
w n C

n care: n
i
- numrul de instruciuni de decizie de nivel i
w
i
- factor de ponderare
C
salt
- numr de instruciuni de salt necondiionat.
b) COMPLEXITATEA INTERFERENELOR, se msoar prin numrul de
apeluri de rutine din (de exemplu, sistemul cognitiv i rezolutiv) sistem.
2
s
u C
int
+ =
;
n care: u - numrul de apeluri de rutine din sistem
s - numrul de apeluri de rutine sistem.
c) COMPLEXITATEA INTRRII-IEIRII se msoar prin numrul de
operaii de I/E:

246
i/e
i/e
i
rut
e
i/e
i/e
I
i
C
I
I
C =

unde:
I
i/e
- numrul de instruciuni de I/E;
=
i
log/rut rut
C C - suma complexitii logicii tuturor rutinelor;
i
i/e
i - suma instruciunilor de I/E din toate rutinele.

d). COMPLEXITATEA CALCULULUI se msoar prin numrul de
instruciuni de asignare de valori ce conin operatori aritmetici:
c
c
C
I
c
C
i
i
rut
e
calc
=
;
c - numrul de instruciuni de calcul;
I
e
- numrul de instruciuni executabile;
C
rut
- suma complexitii logicii tuturor rutinelor;
E
i
i
C - suma instruciunilor de calcul ale tuturor rutinelor.
e). CLARITATEA, se msoar prin raportul dintre numrul de instruciuni
cu comentariu i numrul total de instruciuni.
t
com
I
I
L =

I
com
- numrul de instruciuni cu comentariu;
I
t
- numrul total de instruciuni
Complexitatea total se definete astfel:
C=C
log
+0.1C
it
+0.2C
calc
+0.4C
i/e
-0.1L
n cazul unei complexiti ridicate se consider c fiabilitatea programului
este sczut.


247
10.6. Metode software pentru reducerea erorilor

Ceea ce este unanim acceptat este faptul c trebuie focalizate eforturile
ctre depistarea i ndeprtarea defectelor care, n software se numesc de
regul erori. Un defect (o eroare) este orice lips din specificaiile de proiectare
sau implementare a procesului (Grady, 1992).
Ingineria se strduiete nu numai s creeze i s mbuntaeasc noi produse,
ci s le produc cu costuri eficiente.
Un cost major n software este stabilirea, depistarea defectului. Multe
studii arat c preul pentru gsirea i stabilirea "defectelor" software pot varia
dramatic n funcie de timpul scurs pn la gsirea lor (Grady, 1992).
innd cont de faptul c exist costuri relative mai mari dect 100 la 1, un
beneficiu major al practicilor inginereti este de a reduce costul i varietatea
relurilor.
Cele mai multe evaluri ale calitii software se fac de-a lungul activitilor
de testare.
ngrijorarea managerilor se manifest n general n acest stadiu i n
consecin, unele dintre produsele finale care suport mbuntiri n urma
testrii de-a lungul dezvoltrii au suportat de fapt primele mbuntiri ale calitii.
Criteriile utilizate pentru a judeca cnd s-a ncheiat testarea sistemelor
software sunt foarte largi i adesea subiective. Din cauza unei variaii largi n
ceea ce privete luarea n considerare a acestora n aprecierea calitii software
(permis de o lips de standardizare), firma Hewlett- Packard (HP) a creat un set
de criterii de msurare a calitii. Propunerea lor este de a certifica produsele
software realizate i gata de livrare (Grady, 1992).
Cerinele pentru a realiza acest obiectiv au rezultat din urmtoarele
considerente:
Furnizeaz o msur de proces consistent pentru produsul testat;
Furnizeaz "piese" cuantificabile pentru a evalua progresul pn la
realizarea produsului;
Permite funcionalitatea pe faze;

248
ncurajeaz automatizarea unui numr ct mai mare de teste;
Mrete fiabilitatea produsului care funcioneaz la utilizatori.
Aceste criterii au condus la un set echilibrat de teste i mrimi de baz
msurabile, n raport cu care s poat fi judecat calitatea.
Standardele de testare includ cerinele urmtoare:
- ntindere: extinderea testrii att la ceea ce este accesibil utilizatorului,
ct i peste funciile interne;
- adncime: testare acoperitoare a ramificaiilor;
- fiabilitate: operare continu sub "stress";
-stabilitate: abilitate de acoperire a condiiilor pentru producerea erorilor;
- densitatea defectelor remanente la livrare.
Testarea sistemelor mari n standard HP include multiple cicluri de test.
Se utilizeaz de obicei trei stadii pentru completare i stabilitate. Fiecare din ele
au cerine ridicate de ntindere, adncime, operare continu i densitate de
defect. Aceste cerine permit integrarea unui mare numr de componente cu
nivel de calitate cunoscut.
Un prim indicator pentru management a fost rata defectelor care apar n
sistem. Fig. 10.7. prezint 3 curbe a defectelor care apar (n cazul cererilor de
service) (Grady, 1992). Numrul defectelor n fiecare caz este normalizat de
cantitatea de cod, n mii de linii surs fr comentarii (KNCSS). Vrful curbei
reprezint mai multe produse care ori n-au fost certificate ori au fost realizate
fr s li se aplice criteriile de certificare. Minimul curbei este media a 12
produse certificate, iar linia medie arat c rata defectelor, chiar a celor mai
proaste produse certificate, a fost mult mai bun dect a produselor care nu au
fost executate dup standarde.
Acest grafic sugereaz c un bun proces de testare contribuie la o rat mai
sczut i mai stabil a erorilor care apar (Fig.10.7).


249

Fig.10.7. Spectrul tehnic al unui program

10.6.1. Inspecii, acoperire cu cod i complexitate
Procesul de testare implic de regul numeroi ingineri, care trebuie s
consulte, s semnaleze i corecteze sistemul. n contrast cu aceasta, inspeciile
pot fi startate chiar i de un singur inginer i, mai mult, exist rezultate mai bine
documentate pentru acest gen de activitate dect pentru orice alt practic din
ingineria software.
Dei inspeciile sunt n primul rnd tehnici de detecie a erorii, experienele
n domeniu au artat c i activitile de pregtire a inspeciei au drept rezultat
prevenirea erorii. n cazurile n care "producia" de software nu se face ntr-o
forma standardizat, pregatirea pentru o inspecie foreaz o clarificare a
cerinelor. Inspeciile pot ajuta la "a acoperi" multe defecte nainte ca ele s
devin foarte costisitoare sau nainte ca ele s fie foarte integrate n sistem, ceea
ce le-ar face dificil de nlturat. Ca o remarc la fel de important, inspecia
impune disciplin. Trebuie create produse inspectabile la intervale regulate de
timp, ceea ce va avea drept rezultat obinerea diferitelor imagini ale prilor
produsului final.
Produsele au din proiect, de regul, mai multe pri, iar inspectarea
acestora va produce un feedback msurabil i obiectiv. n final, inspeciile vor

250
constitui o cale de educare a echipei de software i de ncurajare a celor mai
bune practici, acestea fiind aspectele unei bune inginerii software.
O modalitate important de a pstra inspeciile eficiente este de a produce
rezultate msurabile. Obiectul unei bune inspecii este de a gsi, mai repede dect
pe alte ci, unde se afla hibele. Se poate msura procentajul de defecte gsite i
timpul n care au fost depistate.
De exemplu, o echipa HP a gsit cte un defect la fiecare patru ore de testare
a sistemului. Rata de gsire a defectului prin inspectarea codului a fost ca timp de
4,4 ori mai bun dect fr inspectare (Grady, 1992). Ei au reuit s evalueze dac
au ajuns la un punct de diminuare a rspunsurilor sistemului i, de asemenea, ct
timp i efort au investit pentru aceasta.
Adesea inginerii software cred c au fcut toate testrile posibile, cnd de
fapt nu este aa. Reflectarea erorilor n codificare este msurat prin utilizarea unui
instrument care insereaz instruciuni n codul surs precompilat. Cnd se ruleaz
testul, "extracodul" marcheaz segmentele care au fost executate i care nu.
Fig. 10.8 prezint reflectarea erorilor n codificare pentru 22 de proiecte HP pe
care realizatorii afirm c le-au testat cu atenie.
Datele prezentate de acest grafic au fost foarte persuasive n a da o asigurare,
att managerilor ct i inginerilor, n ceea ce privete utilitatea msurrii codificrii.
Astfel, s-a gsit c nu este foarte greu de a obine 80%-85% testare pentru
codificare pentru un limbaj familiar programatorilor n timpul testrii sistemului sau a
integrrii diverselor niveluri cu ajutorul unui instrument care identific codul netestat.
nc o dat trebuie fcut precizarea c aceast tehnic nu necesit o echip
mare de testare.
Una dintre metricile definite cu civa ani n urm a fost complexitatea
ciclic a software-ului, care deriv dintr-o analiz a "drumurilor" poteniale prin
codul surs. Aceasta este o msur care anticipeaz unele dificulti poteniale din
timpul testrii, semnalate de instrumentele de prezentare a codificrii despre care
s-a discutat anterior.


251
Este o metric foarte util inginerilor software pentru semnalare modulelor
complexe, care pot fi predispuse la erori i pot deveni greu de ntreinut. Exist
de asemenea, instrumente comerciale care msoar capacitatea combinnd
complexitatea cu imagini vizuale.

Fig.10.8. Reflectarea tipic prin codificare nainte de msuratori

Rezultate ncurajatoare n acest domeniu a obinut David Card n
"Measuring Software Design Quality". El definete complexitatea proiectat ca o
funcie a complexitii structurale bazate pe rspndirea n form de evantai a
complexitii datelor n funcie de numrul variabilelor de I/O i complexitii
procedurale n funcie de numrul de decizii. Rezultatele sale arat o foarte
strns corelaie ntre densitatea defectelor pentru modulele din opt proiecte.
O analiz similar pentru modulele unui proiect a artat c, dei proporia
pentru complexitatea individual a modulelor difer de cele din studiul lui Card,
se poate gsi de asemenea o bun corelaie a defectelor. n acest caz corelaia
s-a stabilit exact pentru componentele "n evoluie". Rezultatele sunt
prezentate n Fig. 10.9.
Standardele de testare, inspecie i complexitatea ciclic, precum i
relatarea prin codificare sunt exemple ale practicilor suficient de evoluate i
demonstate pentru a putea fi luate n consideraie de ingineria software.
Fiecare punct reprezint un proiect
un proiect
media
P
r
o
c
e
n
t
s
a
j
u
l

d
e

c
o
d
i
f
i
c
a
r
e

100

80

60

40

20

0

252
Rezultatele prezentate n Fig.10.9. sunt ncurajatoare i ele arat c este
posibil s se utilizeze aceste metrici i n mbuntirea deciziilor proiectate.

Fig. 10.9. Analiza defectelor prin codificarea unui modul

10.7. Utilizarea datelor eronate pentru mbuntirea deciziilor

La sfritul anului 1986 Consiliul de Metrici Software HP a fcut cunoscute
definiiile categoriilor standard de cauze ale defectelor. Fig. 10.10 reprezint
modelul definiiilor prezentate n lucrarea lui Grady (1992). Modelul este utilizat n
scopul selectrii unui descriptor pentru origini, tipuri i moduri, pentru fiecare
raport de defectare care este rezolvat. De exemplu, un defect ar putea fi o eroare
de proiectare care face parte din interfaa cu utilizatorul dar care lipsete ca
descriere din specificaiile interne. Un alt defect ar putea fi o eroare de codificare,
atunci cnd ceea ce este logic, este eronat.
Fig. 10.11 ne d o idee a modului n care erorile variaz de la o entitate la
alta. Umbrele diferite reflect partea de origine din fig. 10.10. Sectoarele de cerc
care se decupeaz din zona de mijloc a fig. 10.10, indic tipul erorilor. Cele mai
largi 8 surse de erori pentru diferite divizii HP sunt prezentate n fiecare sector de
cerc. Toate cele 4 rezultate profileaz defectele gsite numai de-a lungul testrii
sistemului i testrii integrrilor n sistem.
Unele diferene se datoreaz inconsecvenei cu care diferitele persoane
utilizeaz definiiile. Deoarece definiiile au chiar scopul de a concentra procesul
de mbuntire a eforturilor n domeniul costurilor mai sczute de corectare,
inconsistenele sunt rezolvate atunci cnd grupul definete cauzele hibelor i le

253
fixeaz printr-un "brainstorm". Din acest motiv datele prezentate n Fig. 10.11
sunt aa de importante. Continund n timp marcarea erorilor se poate de
asemenea msura ct de bine sunt adoptate soluiile.

Fig.10.10. Categoriile surselor de defecte software

Fig.10.11. Sursele de erori pentru patru divizii HP (erori gsite n testare)

Aceasta abordare activ de identificare i de ndeprtare a proceselor care
prezint slbiciuni constituie surse de nepreuit pentru a mbunti calitatea. Se
pare c exist mai multe atribute care ajut n obinerea succesului n ceea ce
privete calitatea software i anume:
Origine
(Deunde?)
Specificaie
solicitri
Proiec
t
Cod Medi
u
Documentar
e
Altele
Solicitri sau
specificaii

Funcionalita
te
Interfa HW

Interfa SW

Interfa
utilizator

Descriere
Comunicaii ntre
procese

Definireadatelor

Proiect de modul

Descriere logic

Corectare erori

Standarde

Logic

Calcul

Manipulare
date

Modul de
interaf /
implementare

Test SW

Test HW

Instrumente
dedezvoltare

Integrare SW

Lipsuri Neclariti Eronat Schimbat Modalitate

mai bun
Tip
(Ce?)
Mod (De
ce?)

254
- O diagram conceptual simpl, cum este cea din fig. 10.10 ajut
evaluatorii s nteleag ce este cel mai simplu de fcut, i i ghideaz n vederea
proporionrii cantitii de efort necesare raportrilor;
- Definiiile standard pentru tipurile de defecte ajut la rezolvarea pe
diferite ci de raionament a problemelor similare;
- Furniznd un cadru pentru raportarea analizelor de erori care au fost
rezolvate se ncurajeaz interesul altor grupuri n a ntreprinde astfel de aciuni;
- Pregtirea n colectarea datelor despre erori i analizarea lor este de
asemenea,foarte valoroas.

10.8. Reducerea erorilor datorit msurtorilor

Cunoscnd care erori apar cel mai frecvent n testare sau mai trziu, se pot
concentra eforturile de mbuntire a acestei situaii. Echipele HP, de care s-a
mai amintit deja, au cules date pentru specificaii, proiect i inspeciile de cod.
Toate acestea sunt prezentate n Fig. 10.12.
Trebuie manifestat puin precauie n interpretarea acestor date specifice,
att timp ct ele n-au fost colectate n mod uniform. Linia orizontal din mijlocul
figurii indic valorile pentru defectele diferite care au fost gsite n aceeai faz.
Barele verticale reprezint ocaziile favorabile de a reduce, semnificativ,
aceste surse de defecte. De exemplu, numrul mare de defecte dintr-un modul
proiectat sugereaz c ar fi nevoie s se nlocuiasc tehnica de proiectare sau
s se completeze metodele existente. Barele de sub linie arat valorile pentru
defectele gsite n fazele imediat urmtoare n care au fost create. Barele
verticale sunt aici, surse, att pentru o prevenire mai bun, ct i ocazii de
detectare mai precoce a erorilor.
De exemplu, solicitrile, funcionalitatea i descrierea funcional a
defectelor se combin n a sugera c proiectele trebuie schimbate datorit unei
definiri (specificaii) iniiale neadecvate a produsului. n asemenea situaii ar fi util
de folosit prototipurile.


255

Fig.10.12. Profilul erorilor

Aceste tipuri de date creeaz posibilitatea de a lua decizii mai bine
informate i indic o cale de evaluare a rezultatelor schimbrilor cu o precizie
mai bun dect n trecut.
Introducnd noi proceduri standard pentru corectarea erorilor n cazul a
trei produse realizate s-au obinut rezultatele prezentate n fig. 10.13.
S-a nceput cu realizarea produsului n care erau 58 de erori, apoi s-a
validat ceea ce era proiectat i efectiv s-a nlocuit cea mai mare parte a erorilor
rezultnd cele dou produse B i C (Grady, 1992).
n concluzie, o bun calitate software este rezultatul unei bune inginerii
software.

Fig.10.13. Erori de manevrare


256
Toate organizaiile trebuie ndrumate s adopte practici de inginerii
software att pentru considerente de afaceri, ct i pentru cerine profesionale,
aceasta fiind singura formul de obinere a unui produs software ct mai aproape
de necesitile utilizatorilor.

10.9. Apli carea analizei cauzale procesului de modificare a
software-ului

Producerea sistemelor software de nalt calitate pe scar larg n cadrul
unor restricii de proiect i de buget a devenit o interesant competiie n ingineria
software. Modificarea acestor sisteme pentru a ncorpora noul i posibilitile de
schimbare supun tot timpul sistemul la o competiie din ce n ce mai mare.
Aceast activitate de modificare trebuie s fie executat fr a afecta
calitatea existent a sistemului. Din pcate, acest obiectiv este rareori atins,
modificrile software introducnd adesea efecte laterale nedorite i conducnd la
reducerea calitii.
O abordare tradiional n dezvoltarea produsului software de nalt
calitate const n aplicarea unei metodologii de dezvoltare, cu sublinieri
accentuate pe detecia erorilor. Acest proces de detectare a erorilor const ntr-o
cutare continu, prin inspectare i testare la diverse niveluri.
O abordare mai eficace pentru dezvoltarea unui produs de nalt calitate
este o accentuare pe prevenirea erorilor, care se poate face prin aplicarea
analizei cauzale. Analiza cauzal const n colectarea i analiza datelor de
defect software n ordinea identificrii cauzelor lor. Din momentul n care cauzele
sunt identificate, pot fi aduse mbuntiri proiectului pentru a preveni apariiile
viitoare ale erorilor.
O lucrare de specialitate de la firma IBM prezint o metodologie de
abordare a proiectului care utilizeaz analiza cauzal i feedback-ul ca mijloace
pentru obinerea mbuntirii calitii i, n final, prevenirea defeciunilor.

257

Fig.10.14. Procesul de analiz cauzal

Metodologia de prevenire a defectelor se bazeaz pe urmtoarele trei concepte:
1) Proiectanii i-au evaluat propriile greeli;
2) Analiza cauzal este parte din procesul de dezvoltare software;
3) Feedback-ul este parte din proces.
O privire general a procesului de analiz cauzal propus de Jones este
ilustrat n Fig.10.14
Prima activitate const din nceperea activitii echipei de analiz cu
urmtoarele obiective:
a) Revederea datelor eronate de intrare;
b) Revederea liniilor directoare din metodologie;
c) Revederea listelor de verificare potrivite;
d) Identificarea cerinelor echipei.
Urmtoarea activitate este dezvoltarea produsului care apare, folosind
feedback-ul obinut de la activitatea echipei ntrunit n scopul prevenirii crerii
de noi erori.
Produsele rezultate sunt apoi validate i refcute acolo unde este
necesar.

ntlnireaechipei
Dezvoltarea
produsului
Validare i refacere
produs dezvoltat
Analiza cauzal a
erorilor
Implementarea
aciunii

F

E

E

D

B

A

C

K

9.5. Aplicarea analizei cauzale procesului de modificare a software-ului

258
Activitatea de analiz cauzal este apoi efectuat, ncepnd cu analiza
erorilor, fcut de autorii erorilor. Aceasta implic analizarea fiecrei erori pentru
a determina:
1) tipul erorii sau categoria;
2) faza n care a fost gsit;
3) faza n care a fost creat;
4) cauza (cauzele) erorii;
5) soluia (soluiile) pentru prevenirea apariiei erorii n viitor.
Aceast informaie este nregistrat ntr-o anumit form n analiza
cauzal i folosit apoi ca dat de intrare ntr-o baz de date.
O alt echip de analiz cauzal se ntlnete apoi pentru analizarea
datelor din baza de date. n plus, grupul poate avea nevoie la un moment dat s
se consulte cu alte persoane din afara echipei (proiectani, persoane care au
efectuat testele, etc.), pentru a completa analiza. Echipa de analiz cauzal este
responsabil pentru identificarea ariilor majore de probleme, privind datele
eronate ca un ntreg, n loc de analizarea unei erori particulare la un moment
dat. Echipa folosete metoda de rezolvare a problemelor pentru: a analiza
datele, a determina punctele asupra crora trebuie s lucreze, cauzele grupurilor
de probleme i pentru a dezvolta planuri de implementare i recomandri care
s previn apariia tipului sau tipurilor similare de probleme n viitor.
Aceste recomandri sunt apoi supuse unei aciuni n echip, care are
urmtoarele responsabiliti:
a) Evaluarea i prioritizarea recomandrilor;
b) Implementarea recomandrilor;
c) Rspndirea feedback-ului.
Echipa de aciune trebuie s se ntlneasc periodic (de exemplu, o dat
pe lun) pentru a revedea orice nou plan de implementare recepionat de la
echipa de analiz cauzal i s verifice stadiul planurilor de implementare
prevzute, precum i numrul aciunilor.
Starea aciunii este de asemenea pstrat n baza de date a analizei
cauzale i monitorizat de aciunile echipei.

259
Cele mai multe eforturi raportate la activitile de analiz cauzal au fost
focalizate pe dezvoltarea procesului. Aceasta reprezint, din pcate, un
procentaj ridicat de efort consumat n timpul activitilor de modificare software.
Modificrile software apar pe msura adugrii de noi posibiliti sau pe msura
modificrii celor existente ale sistemului. Modificarea n linii mari a unui sistem
complex este o mare consumatoare de timp i o activitate succeptibil la erori.
Aceast sarcin devine i mai dificil n timp, pe msur ce sistemul se mrete
i structurile sale se deterioreaz.
Analiza cauzal
Paii analizei cauzale sunt prezentai sumar n Fig.10.15.

Fig.10.15. Analiza cauzal n procesul de modificare software

Pasul 1. Obinerea rapoartelor asupra problemei
Prima activitate care trebuie efectuat este colectarea rapoartelor asupra
problemei care rezult din procesele de modificare ce au suferit scrutinul analizei
cauzale. Aceste rapoarte pot fi generate intern prin testare, sau extern, de la un
client.
Pasul 2. Prioritizarea problemelor
Prioritizarea erorilor permite o analiz a cauzelor care contribuie la
creterea prioritii problemei i const n mprirea erorilor n trei categorii, i
anume:
1) Critice;
Obinerea rapoartelor asupra
problemei
Prioritizareaproblemelor
Clarificareacererilor
Analizacauzei erorilor
Dezvoltarea recomandrilor

260
2) Majore;
3) Minore.
Erorile critice slbesc funcionalitatea i interzic testarea viitoare. Erorile
majore slbesc parial funcionarea, iar erorile minore nu afecteaz n mod
normal operarea sistemului.

Pasul 3. Clasificarea erorilor
Dup prioritizarea erorilor urmeaz clasificarea lor. Primul obiectiv al acestei
clasificri este facilitatea care se creeaz astfel pentru a lega erorile de cauzele
lor. De-a lungul anilor au fost propuse numeroase clasificri ale erorilor. Dei
clasificarea nu este neaprat necesar n efectuarea unei analize cauzale,
datorit faptului c sistemele bazate pe cunotine nu sunt produse software
obinuite, nu este lipsit de interes o astfel de ncercare, care s adauge la
categoriile de erori din software-ul tradiional, clase noi, specifice sistemelor de
inteligen artificial (Novac 1994).
Clasificarea erorilor furnizeaz de asemenea informaii utile atunci cnd se
determin eficacitatea din punct de vedere al costului eliminrii erorilor care ar
putea s apar.
Categoriile de erori sunt :
A) Erori de proiectare;
B) Erori provenite din validarea cunoaterii;
C) Erori de interfa incompatibil;
D) Sincronizare incorect dintre proiectele paralele;
E) Resturi corectate de obiecte incorecte;
F) Epuizarea resurselor sistemului.

A) Erori de proiectare
Aceast categorie reflect erorile software cauzate de o transpunere
improprie a cerinelor n proiect, de-a lungul perioadei de modificare.
Sunt incluse proiectul la toate nivelurile, achiziia i structurarea
cunoaterii, realizarea prototipului. Exemple tipice de erori de proiectare sunt:

261
A1) Erori logice: Condiii eronate logic n reguli, transpunere logic
greit a cunoaterii n reguli, etc.
A2) Erorile de calcul sunt legate de inacurateea i greelile fcute n
implementare legate de operaia de calcul, n special n cazul n care se folosesc
cunotine care rezult din algoritmi de calcul, cum ar fi algoritmii precompilai
care studiaz rezistena navei n cazul unui sistemului expert.
A3) Lipsa excepiei de manipulare. Aceste erori includ greeala de a
lucra cu condiii unice sau cazuri unice chiar i atunci cnd exist excepii i
acestea au fost prevzute n specificaiile proiectului.
A4) Erori de timp. Acest tip de erori reflect proiectarea incorect a
timpului critic software. De exemplu, sistemul ncearc s fac o cutare
"forward" cu multe inferene atunci cnd rspunsul sistemului trebuie s fie foarte
rapid, lund n considerare numai cunotine de suprafa.
A5) Erori de manipulare a datelor. Aceste erori includ greelile fcute la
iniializarea datelor nainte de utilizare, utilizri improprii ale constantelor din
sistem, control neadecvat al fiierelor de date adiionale sistemului, etc.
A6) Erorile n conceptele I/O includ forme de intrare sau ieire n/din
fiiere eronate, erori de formatare, definirea unor nregistrri de dimensiune
greit, protocoale de I/O eronate sau improprii dispozitivelor sistemului.
A7) Definirea greit a datelor. Aceast categorie reflect proiectarea
incorect a structurilor de date care vor fi utilizate n diferitele module din baza de
cunotine, sau incorecta definire a structurilor globale. Se reflect de asemenea
aici abstractizarea incorect a datelor.

B). Erori provenite din validarea cunoaterii
Aceast categorie, specific sistemelor bazate pe cunotine, se refer la
erorile care apar n oricare dintre fazele de prelucrare a cunoaterii, ncepnd cu
achiziia primar a cunotinelor i continund cu mentenana sistemelor (vezi
8.4 Validarea cunoaterii).


262
C). Interfa incompatibil
Erorile legate de interfa apar atunci cnd interfeele dintre dou sau mai
multe tipuri diferite de componente modificate nu sunt compatibile. Se pot da
urmtoarele exemple de acest gen:
1) Se transmit ntre diversele module parametri diferii, fa de cei care
sunt ateptai;
2) Se efectueaz alte operaii de ctre modulele apelate dect cele
care s-au gndit n proiect. Aceste situaii pot s apar i din cauza propagrii
erorilor de la modulele eronate;
3) Dezacordul dintre baze de date i cod atunci cnd baza a fost
proiectat;
4) Rutine de execuie sau alte rutine, inexistente;
5) Dezacord ntre software i hardware;
6) Dezacord ntre software i firmware (microprogramare) atunci cnd
anumii parametri trebuie obinui prin microprogramare.

D) Sincronizarea incorect dintre proiectele paralele
Pentru o evoluie mai larg a unui sistem, ciclurile de dezvoltare software
ale mai multor realizri se pot suprapune aa cum se prezint n fig. 10.16.
Fig.10.16. Evoluia sistemului software

Aceast categorie de erori apare atunci cnd schimbrile, modificrile din
proiectul anterior A, sunt incorect continuate n proiectul B, care este proiectul
curent.


263
E). " Resturi" corectate de obiecte incorecte
ntr-un efort mai mare de mentenan resturile de obiecte sunt cteodat
folositoare. Aceste resturi pot rezulta din mai multe revizii ale sistemului. Erorile
comise atunci cnd se modific modulele cu resturi (pri) de obiecte fac parte
din aceast categorie.

F). Epuizarea resurselor sistemului
Acest tip de erori apare atunci cnd resursele sistemului, cum ar fi
memoria i timpul real devin insuficiente. Exemple de acest tip sunt: epuizarea
spaiului n stiva dinamic de memorie (heap), a unor registre, sau a ceasului de
timp real.

Pasul 4. Analiza i determinarea cauzelor erorilor
Cel mai critic pas din realizarea analizei cauzale este determinarea cauzei
fiecrei erori. Aceast sarcin este cel mai bine realizat de programatorul care a
introdus eroarea. Pentru a facilita identificarea cauzei erorii, proiectanii software
care au introdus erorile trebuie intervievai, dar ntr-o manier neoficial i cu
foarte mare grij pentru a nu provoca reacia lor de aprare. Analiza pentru
prevenirea defectului trebuie subliniat clar ca fiind scop i prioritate n acest
interviu. Bazat pe informaia obinut de la proiectantul care a introdus eroarea
se poate selecta o categorie cauzal de erori.
Considerm c se pot identifica apte categorii majore de cauze care
conduc la erori n modificarea software-ului. Acestea difer de altele prezentate
n literatura de specialitate i care sunt orientate direct ctre descoperirea
cauzelor erorilor comise de-a lungul dezvoltrii unui sistem software nou. Aceste
scheme de clasificare a erorilor nu se adreseaz n exclusivitate numai cauzei
care a produs erorile aprute de-a lungul procesului de mentenan.
Cerina de determinare a categoriei cauzale pentru fiecare eroare este de a
colecta datele necesare pentru stabilirea categoriei cauzale creia i corespunde
cel mai bine eroarea. Acest lucru furnizeaz o metod pentru evaluarea eficienei
costului implementrii recomandrilor care elimin sau reduc cauzele erorii.

264
Categoriile cauzale obinuite n activitile de modificare sunt:
I) Cunoaterea sistemului / experiena
Aceast categorie cauzal reflect lipsa cunoaterii proiectului software al
produsului sau a procesului de modificare. Se pot da cteva exemple:
1) nelegerea greit (confuziile) a proiectului existent;
2) nelegerea greit a procesului de modificare;
3) nelegerea neadecvat a mediului de programare. Mediul de
programare incluznd personal, maini, management, instrumente de dezvoltare
i ali factori care afecteaz posibilitatea de dezvoltare i modificare a sistemului;
4) nelegerea neadecvat a solicitrilor clientului.

II) Comunicaia
Aceast categorie cauzal reflect problemele de comunicare n ceea ce
privete modificrile care trebuie efectuate. Se identific cauzele care nu au fost
atribuite lipsei cunoaterii sau experienei i care apar datorit comunicrii
incorecte sau incomplete.
Problemele de comunicare sunt de asemenea cauzate de confuzia n
rndurile membrilor echipei n ceea ce privete responsabilitatea sau deciziile.
Cteva exemple de probleme de erori n comunicare sunt:
1. Greeala unui grup de proiectare datorit necomunicrii ultimei
modificri;
2. Eroare n scrierea unei rutine de tratare a erorilor deoarece fiecare
membru al echipei a considerat c ea este scris de altul.

III) Impacturile software
Aceast categorie reflect eroarea proiectantului software n considerarea
tuturor implicaiilor posibile ale modificrii software-ului. Un exemplu este
omiterea unei codificri de acoperire a erorii dup adugarea unei noi piese
harware.


265
IV) Metode / standarde
Aceast categorie reflect nclcrile de metode i/sau standarde n
module, de asemenea, limitri ale metodelor existente sau ale standardelor care
contribue la defectri. Un exemplu ar fi omiterea revizuirii codificrii, nainte de
testare.

V) Caracteristica desfurarii
Aceast categorie reflect problemele legate de inabilitatea software-ului,
hardware-ului, componentelor bazei de date, de a se integra la un moment dat.
Este caracterizat de o lips a planurilor de prevenire care s evite problemele
cauzate de lipsa componentelor.

VI) Instrumente de susinere
n aceast categorie se regsesc problemele legate de instrumentele care
introduc erori. Un exemplu l constituie un instrument de validare a cunoaterii care
se utilizeaz pentru evaluarea bazelor de cunotine i care introduce erori n
cunotine.

VII) Eroarea uman
Aceast categorie cauzal reflect erorile umane comise de-a lungul
procesului de modificare care nu sunt atribuibile altor surse. Proiectantul a tiut
ce face i a neles totul de la un cap la altul, dar a greit pur i simplu.


266


267

11

Evaluarea sistemelor software

11.1. Set de metrici software pentru conducerea proceselor de mentenan
a programelor
Problema evalurii sistemelor software a devenit cu att mai acut i
important cu ct dimensiunea, costul i locul strategic ocupat de sistem a
crescut n timp.
Aa cum fiecrui produs i se ataeaz la livrarea ctre beneficiar un
certificat de calitate, tot aa sistemele software, indiferent de tehnica de realizare
(clasic sau din domeniul inteligenei artificiale), trebuie s fie garantate i
studiate din punctul de vedere al fiabiltii, calitii i ntreinerii (mentenabilitii)
lor.
Un studiu de specialitate (Stark, 1994) face cunoscute rezultatele
cercetrilor unui grup nsrcinat cu administrarea programelor din cadrul NASA,
care a definit i implementat un set de metrici software coninnd 13 metrici
destinate s corecteze i s adapteze aciunile de mentenan.
Echipa numit MOD a rspuns de astfel de activiti de mentenan
software la diferite niveluri (sisteme, subsisteme, module) utiliznd paradigma
solicitare (ntrebare) metric, care identific o mulime de 13 metrici pentru
utilizarea curent i de viitor n studiul sistemelor. Aceste metrici permit
evaluarea strii curente a activitilor de mentenan i predicioneaz rezultate
viitoare (solicitri) cum ar fi :

268
-"Ct de mare trebuie s fie echipa de care este nevoie pentru evaluare? "
-"Ct timp va dura lucrul pentru ncheierea raportului software?"

Definirea setului de metrici
Literatura de specialitate n mentenan software precizeaz metricile
pentru astfel de activiti.
Tabelul 11.1 Concluziile privind paradigma cerere/ntrebare/metric
Cerere ntrebare Metrici
Maximizarea
satisfaciei
clientului
Cte probleme afecteaz
utilizatorul (clientul)?
- Raportul discrepanelor (DR) i
solicitrile de service (SR) de-a
lungul desfurrii.
- Fiabilitate software
-Raport ntrerupere/ funcionare
Ct timp dureaz pentru
a definitiva o problem?
- Terminarea DR/SR - DR/SR
de-a lungul desfurrii.
Unde sunt "ngustrile" - Utilizarea saff-ului
- Utilizarea resurselor
calculatorului
Minimizarea
efortului i
proiectului
Unde se consum
resursele?
- Utilizarea staff-ului- Planificarea
SR- Instanieri gen ADA-
Distribuia tipului de erori
Ct de mentenabil este
sistemul?
- Utilizarea resurselor
calculatorului
- Dimensiunea software-ului
- Densitatea erorilor
- Volatilitatea soft-ului
- Complexitatea software-ului
Minimizarea
defectelor
Este software-ul
susinut (confirmat)
efectiv inginerete?
- Densitatea erorilor
- Raport ntrerupere/ funcionare
- Instanieri ADA
- Fiabilitate software


269
De asemenea, n lucrarea lui Gill (1991) se pune problema datelor care
trebuie pstrate n timpul mentenanei sistemului, sau care determin activiti de
mentenan ( Zuse 1992).
Pornind de la acestea, se pot sintetiza problemele legate de activitile de
mentenan a software-ului inteligent ca evolund pe direcia "cerere- ntrebare-
metrici" (Tabelul 11.1).
Observaii:
Metricile sunt utilizabile individual, dar cel mai mare beneficiu deriv din
faptul c ele sunt folosite ca o mulime de pai n solicitri de concuren cum ar
fi calitate fa de productivitate sau calitatea n raport cu datele realizate, etc.
Pentru a obine aceste beneficii se raporteaz mai mult de o metric la
fiecare cerere, iar alte metrici ntrein desfurarea cererii (de exemplu fiabilitatea
software). Aceste desfurri pot furniza nu numai observaii din interiorul
proiectului, dar permit de asemenea verificri asupra consistenei datelor.
efii proiectului pot s combine metricile pentru a investiga pai nevizibili
numai cu o singur metric.

1.Dimensiunea software-ului
Mrimea, dimensiunea software-ului este un parametru primar de intrare
n mai multe modele de estimare a costului i calitii software-ului i este strns
legat de alte metrici din mulime (cum ar fi densitatea erorilor, complexitate,
etc).
Metrica este definit ca numrul de linii de cod surs (NLCS) care au fost
ntreinute n proiect. Aceasta poate fi utilizat n proiectul de management
pentru urmtoarele activiti:
Mulimea de metrici pentru mentenana software-ului
1a). Urmrirea efortului necesar pentru ntreinerea codului. O cretere n
dimensiune a software-ului poate conduce la meninerea unui personal mai
numeros de ntreinere. Dac se poate stabili o relaie ntre specificaiile
proiectului, prin utilizarea unui model de cost sau a unei regresii liniare

270
simple, atunci mrimea privind schimbarea staff-ului de mentenan poate
fi predicionat prin schimbarea n dimensiune a software-ului.
1b). Anticiparea problemele de performan n hard, n timp real. O
tendin ctre creterea dimensiunii software-ului ar iniia aciuni corective care,
fiecare, ar contoriza sau s-ar armoniza cu efortul crescut de depanare i/sau
puterea calculatorului.
Fig.11.1 ilustreaz dimensiunea software-ului unor sisteme MOD pentru 6
ani, ntre 1986-1991(Kern, 1992). Se nregistreaz o medie de aproximativ 7,5%
cretere pe an. Aceast evaluare poate fi combinat cu limbajul de programare
(sau cu generatorul de sisteme expert folosit), care este ghid pentru numrul de
NLCS pe care un programator trebuie s-l ntrein i cu numrul ateptat de
erori din cod pentru a dezvolta programele proiectului, semnificativ pentru
intensificarea, actualizarea i precizarea numrului de rapoarte cu discrepane
care sunt de ateptat de-a lungul unui an.
De exemplu, dac codul conine 1,5 erori/1000 LCS (KNLCS), n medie,
atunci prin adugare, 600 * 15 =900 erori ar fi nserate n soft.
Mai mult, dac inginerul soft poate "suporta" 80 KNLCS (n medie), atunci
solicitrile proiectului vor fi de aproximativ 240 de oameni pentru a ntreine
aceste sisteme.

Fig.11.1. NLCS executabil (n) i total (o) pe an
1986 1987 1988 1989 1990 1991
ani
20
16
12
8
4
0
D
i
m
e
n
s
i
u
n
e
a

s
o
f
t
w
a
r
e

(
M
i
l
i
o
a
n
e

d
e

l
i
n
i
i

d
e

c
o
d
)

NLCS executabile
NLCS total

271

2. Echipa de software
Schimbrile n echipa de software au un impact direct asupra costurilor
proiectului i asupra progresului n mentenana software.
Aceast metric este reprezentat de numrul de ore de-a lungul unei
luni consumate de inginerii software direct implicai n activitile de mentenan
i furnizeaz informaii de management legate de datele care ar fi necesare
pentru o predicie a viitoarelor cereri ale staff-ului proiectului.
De asemenea, poate fi folosit pentru urmtoarele aciuni:
2a). S estimeze eficacitatea n activitile de inginerie software prin
evaluarea numrului de pai i a resurselor necesare n fiecare proces de
mentenan. Este posibil s se continue sau s se elimine pai din proces, astfel
nct s-l fac mai eficient i s rspund mai bine utilizatorilor.
2b). S identifice cele mai intensive resurse din activitile de mentena
(de exemplu, solicitri de schimbare, evaluare, planificare, implementare, test,
eliberare de resurse).
2c). S identifice cele mai intensive resurse din sistem.
Aceast metric permite o "verificare de sntate" a proiectului prin
comparaii cu regulile de aciune recunoscute n industrie pentru cheltuiala cu
personalul de-a lungul fazei de mentenan, din ciclul de via al sistemului
software.
De exemplu, Fig. 11.2 prezint situaia pentru un proiect MOD.
Se observ c sistemul 5 consum cele mai multe ore-persoan cu
activiti de mentenan (evaluri SR, implementri i .a.m.d). Combinnd
aceste informaii cu metrica de densitate, frecven a erorii, s-a recomandat o
schimbare n echipa de software a acestor sisteme. Orice sisteme care deviaz
semnificativ de la profilul planificat al proiectului va atrage atenia asupra sa.

3. Procesarea solicitrii de mentenan
Aceast metric monitorizeaz fluxul activitii de mentenan software i
determin nivelul de satisfacere a clientului.

272
Maximiznd satisfacia utilizatorului, este important s se manipuleze
solicitrile cele mai vizibile pentru client, asigurndu-i astfel o asisten
permanent.

Fig. 11.2. Schimbri software cerute de eficiena desfurrii proiectului

Metrica permite i unui analist s execute urmtoarele funcii:
3a). S fac o predicie asupra cantitii de munc necesar datorit noilor
solicitri, sau noilor rapoarte, comparndu-le cu cereri similare din alte proiecte.
3b). S determine nivelul satisfacerii clientului de ctre produs, conducnd
cu grij evoluia n echipa de management.
3c). S efectueze studii de ocupare a personalului, a resurselor
calculatorului, reducnd posibilele rmie din modelul de simulare a
evenimentelor discrete ale proceselor n cauz.
Fig. 11.3 d un exemplu a acestei metrici pentru un proiect MOD. Linia
continu orizontal (Progres) reprezint diferena dinte cererile incluse i nou
sosite ntr-o perioad de un an.
Aceast metric reprezint o bun cale de a observa tendina cumulat a
muncii rmase de efectuat, sau pentru a estima cantitatea total de munc
solicitat. n mod ideal, "progresul" ar trebui s fie aproape zero.
De exemplu, o linie a progresului care crete la +20 (~10%) justific o
investigaie a motivului acestei creteri a restului. Dac linia descrete la - 20,
atunci proiectul furnizeaz o descriere a metodelor folosite pentru a satisface un
mare numr de solicitri.

273

Fig.11.3. Schimbri software cerute de eficiena desfurrii proiectului

4. Planificarea mrit a software-ului
Metrica de planificare sporit a software-ului traseaz mrimea timpului
necasar pentru includerea unei cereri sporite i efortul ingineresc consumat
pentru aceast solicitare. Sunt folosite dou date primare pentru a calcula
aceast metric:
1). Numrul planificat i actual de ore de inginerie cheltuite cu acest
suprasolicitare;
2). Timpul calendaristic scurs de la apariia cererii pn la rezolvarea ei,
ca facilitate de utilizare.
Mulimea de metrici include i aceast metric deoarece permite
managerilor proiectului s identifice produciile de plan cu cel mai nalt risc, s
evalueze timpul necesar, pentru a oferi utilizatorilor o cerere sporit i s
predicioneze cantitatea de munc pe care o incumb aceast cerere.
De exemplu, cnd se primete o cerere de service i se asigneaz o
prioritate (aceasta semnific risc pentru plan, sistem, proiect), datele de care are
nevoie i se estimeaz personalul necesar pentru satisfacerea complet a task-
ului.
DR sau DR noi sosite
DR sau DR incluse
-60
-30
0
60
30
90
120
N
u
m
r
u
l

d
e

c
e
r
e
r
i

(
S
R

s
a
u

D
R
)

I
u
l
-
9
1

A
u
g
-
9
1

S
e
p
-
9
1

O
c
t
-
9
1

N
o
i
-
9
1

D
e
c
-
9
1

I
a
n
-
9
2

F
e
b
-
9
2

M
a
r
-
9
2

A
p
r
-
9
2

M
a
i
-
9
2

I
u
n
-
9
2


274
Trasnd aceste estimri peste actuala desfurare de date a solicitrii
adiionale, conducerea proiectului poate s-i modifice procesul estimat i s
furnizeze utilizatorilor o informaie mai bun n ceea ce privete schimbrile
efectuate n sistem.

5. Utilizarea resurselor calculatorului
Metrica privind utilizarea resurselor calculatorului (CRU) marcheaz modul
de utilizare a resurselor sistemului. Sunt incluse patru resurse, i anume: CPU,
disc, memorie i utilizarea canalului I/O. Metricile CRU sunt raportate ca
procentaje din capacitatea resurselor i furnizeaz un cadru pentru prezentarea
concluziilor analizei rezultatelor sistemului n raport cu contractul (Kern, 1992).

Fig.11.4. Utilizarea capacitii de memorare pentru un proiect

De asemenea, avertizeaz mai devreme conducerea proiectului n cazul
n care utilizatorii s-au apropiat de limitele de capacitate ale resurselor sistemului.
Modul n care sunt utilizate aceste resurse n cadrul unui proiect MOD
sunt ilustrate n Fig.11.4. Cnd sistemul ocup 90% din capacitate, proiectanii
au neles c trebuie s ndeprteze din sistem fiierele perimate i s creeze

275
mai mult spaiu de memorare. Aceste aciuni au redus procentajul la mai puin de
50%.
Previziunea c volumul de date memorate se apropie de capacitatea de
90% se potrivete cu o dreapt de regresie de forma:
capacitate = rata_de_ocupare * luna + constant, de la punctele datei
pn la ultima aciune corectiv.
Aceast linie intersecteaz pragul de 90% capacitate n octombrie 1993,
cnd a fost efectuat ultima aciune corectiv.

6. Densitatea erorilor
Numrul rapoartelor de discrepane incluse ntr-un proiect cu un software
fix, per KNLCS, n funcie de timp, definete metrica de densitate sau frecvena
erorilor. Densitatea erorilor msoar calitatea codificrii i poate fi utilizat
pentru:
6a). Predicia numrului de erori remanente n cod prin utlizarea unui
model de calitate;
6b). Stabilirea densitii standard de erori n scop de comparaie i
predicie pentru fiecare nivel sever de defectare sau tip de eroare. Aceasta
permite proiectanilor s identifice sistemele sau procesele crora trebuie s li se
acorde o atenie deosebit.
Fig.11.5 este o diagram Pareto de densitate a erorilor pentru un sistem,
timp de 5 ani, n cadrul unui proiect MOD. Acest grafic este un instrument util
pentru "filtrarea" mbuntirii calitii propuse a proiectului. Deoarece timpul i
banii sunt resurse limitative, proiectanii au nceput s investigheze cauzele
"defectrilor" dup densitatea de erori raportat, n cazul sistemului A.
Aceste investigaii conduc la concluzia c trebuie schimbate planurile,
unele componente, sau reconstituit software-ul. Conducerea proiectului poate
de asemenea s utilizeze aceste informaii pentru a-i lua msuri de prevedere
atunci cnd ia n considerare cereri de extindere a sistemului, sau a acelor
module n care s-au sesizat erori.


276
7. Volatilitatea software-ului
Belady i Lehman au definit n 1976, pentru prima dat "volatilitatea
software-ului". Este un raport dintre numrul de module schimbate din cauza
cererii de mentenan i numrul total de module eliberate n timp.

Fig.11.5. Densitatea erorilor pe sistem

Sarcina acestei metrici este de a msura cantitatea de schimbri n
structura software-ului, n timp. Utilizat mpreun cu fiabilitatea, CRU i
complexitatea proiectat, ea ajut managerii s decid dac o procedur
calificat de test ar putea fi reexecutat i s identifice nevoia de reconstruire a
software-ului.
Se pot stabili dou reguli de baz pentru acest metric, i anume:
(1) Cnd volatilitatea depete 30% este necesar o recalificare pentru o
utilizare operaional;
(2) Dac metrica depete 80% pentru produsul realizat, sistemul va
trebui reconstituit.


277
8. Durata raportului de discrepane
Aceast metric (DR) ofer o msur a timpului necesar pentru rezolvarea
tuturor rapoartelor de discrepane din momentul descoperirii lor i pn la
ncheierea proiectului.

Fig. 11.6. Durata DR i zonele critice

Durata unei discrepane este calculat din punct de vedere al datelor
raportate, minus datele supuse aciunii i furnizeaz o privire din interior a
eficienei procesului de depanare. O mrime semnificativ a vechilor DR-uri
poate indica c au fost necesare mai multe resurse pentru a le nchide, a le
lichida. Examinarea numrului i vrstei DR-urilor cu prioritate critic ridicat
permite managerului de proiect s estimeze timpul de rspuns n depanare. De
asemenea, un numr mic de DR-uri poate indica existena unor probleme dificile
care necesit schimbri extensive pentru corecie, sau probleme care nu au fost

278
bine nelese i solicit mai mult atenie. Fig. 11.6 este un raport de durat a
unui DR simplu.
n plus, managerii responsabili cu procesele de discrepane pstreaz data
i durata vechilor rapoarte atunci cnd primesc altele noi.
Suma acestor "vrste" i ciclurile individuale de timp sunt utilizate pentru a
identifica ngustrile din domeniu i a mbunti procesul.

9. Raportul ntrerupere/funcionare
n lucrrile de specialitate s-a comunicat c o schimbare n software are
numai 20% anse de succes dac implic mai mult sau chiar 50 NLCS i
aproape 50% anse de modificri fcute corect, pentru mai puin de 10 NLCS
ntr-o prim ncercare. Raportul ntrerupere/funcionare este numrul de erori
inserate n soft-ul operaional, n liniile de baz, mprit la numrul de modificri
fcute n produsul software.
De exemplu, dac sunt trei discrepane care trebuie corectate i n urma
coreciei rezult o eroare, raportul va fi 0,33. Aceasta nseamn c activitatea de
corecie a avut eficacitate 67% n rezolvarea DR-urilor. Metrica ajut de
asemenea la execuia urmtoarelor funcii:
a). Estimarea numrului de probleme care afecteaz clientul sau a
numrului de erori remanente n cod, utiliznd un model de simulare;
b). Identificarea sursele care pun probleme pentru software, ca i
dezvoltarea i aprobarea lui.
Aceasta este, de asemenea, necesar conducerii pentru urmrirea
inspeciilor care privesc codul i testarea proiectului.
Metrica raportului msoar eficacitatea organizrii mentenabilitii n ceea
ce privete modificrile n software-ul operaional de baz.

10. Fiabilitatea software-ului
Fiabilitatea software-ului poate fi definit drept probabilitatea ca software-ul
s nu fie defect ntr-o perioad specificat de timp i n condiii, de asemenea
specificate.

279
Bazndu-se pe datele operaionale de defectare, metrica "fiabilitatea
software-ului" furnizeaz o indicaie a numrului de erori de-a lungul unei
perioade de durat dat. Ea traseaz rata erorii software-ului curent prin date.
Metrica poate fi utilizat s controleze traficul schimbrilor prin sistem astfel nct
s fie meninut o rat acceptabil a erorilor.
Dac sistemul este realizat bine n ceea ce privete o "mulime prag" de
mentenabilitate, atunci vor fi permise schimbri complexe.

Fig.11.7. Rata erorilor software pentru 12 misiuni

Aproape toate proiectele au o cerin legat de fiabilitatea software,
deoarece exist un punct de la care rata erorilor din software face sistemul s fie
inutilizabil.
Fig. 11.7 ilustreaz forma ratei erorilor software ntr-o serie de misiuni de
zbor a Centrului de Control NASA. Aceste date ajut la determinarea unui
program acceptabil i stabilete cerinele viitoare.

11. Complexitatea proiectului
Complexitatea proiectului, ca metric, indic numrul de module cu care
complexitatea proiectului a crescut fa de ceea ce s-a stabilit iniial. n acest caz
se utilizeaz metrica complexitii extinse a lui McCabe, care contorizeaz
numrul de ci de execuie independente de-a lungul unei piese date de
software, ceea ce nseamn de fapt numrul de ramificaii logice plus 1. De
asemenea, ea permite conducerii proiectului s schieze posibilitile furnizorului

280
de a menine un nivel acceptabil al complexitii, la nivelul fiecrui modul n
parte. Complexitatea este strns corelat cu efortul de mentenan al
programatorului i cu numrul de erori gsite de-a lungul testrii i operrii.

12. Distribuia tipului de erori
Aceast metric prezint raportul desfurat de discrepane n trei moduri:
(1). Prin desfurarea codului (aceasta nseamn: hardware, software,
resurse umane, neputin de a fi duplicat .a.m.d.);
(2). Prin tipul problemei care a fost greit (adic logic, computaional,
interfa, data de intrare, etc.)
(3). Prin procesul care a introdus problema (adic cereri, proiect, cod,
test).
Toate acestea servesc la identificarea acelor aspecte ale procesului care
sunt "susceptibile" la erori, precum i celor mai comune tipuri de erori introduse.
Informaia provenind de la aceast metric trimite napoi n lanul de
dezvoltare i conducere, astfel nct managerii pot s ia efectiv msuri de
reducere a riscului (de exemplu o mai bun inspecie) i de asemenea s reduc
tipul i cauzele erorilor. De asemenea, metrica este utilizat pentru identificarea
solicitrilor pentru instrumente de mentenan software mult mai utile.
Tabelul 11.2 arat comportarea unui proiect MOD.

Tabelul 11.2 Rapoarte de probleme care au aprut la un proiect MOD
Desfurarea codului Rapoarte de probleme
Incapabil de a reproduce problema
Problema de duplicare
Configurare sau limite de proiectare
Software fix
Erori umane
Hardware fix
Altele
317
185
95
265
28
5
77


281
13. Instanieri tip ADA (limbajul de programare ADA)
Metrica "instanieri tip ADA" reprezint un numr de uniti generice ADA i
codificate de-a lungul activitii de mentenan, dimensiunea unei uniti generice
(n NLCS) i o mrime a timpului n care unitatea generic este instaniat.
Cerina acestei metrici este de a marca numrul i dimensiunea
componentelor reutilizabile dezvoltate de proiect pentru folosirea lor n interiorul
proiectului sau n alte proiecte. Aceast metric marcheaz unitile generice
ADA reutilizate i poate fi utilizat atunci cnd sistemele de inteligen artificial
folosesc drept "cunotine" de profunzime algoritmi precompilai.

11.2. Programul de implementare a metricilor
Dup definirea mulimii de metrici trebuie s se treac la colectarea,
analiza, raportarea i utilizarea metricilor.
Primul pas n implementarea lor este de a emite o directiv de
management. Acest pas este considerat pozitiv deoarece asigur consistena
de-a lungul proiectului i demonstreaz c cel mai nalt nivel al proiectului,
suport efortul.
Importana acestui suport nu poate fi exagerat; fr el metricile
programului nu ar fi luate n serios, n particular de contractani.
Al doilea pas este de a furniza instrumente automate pentru a susine
metricile de program. Se utilizeaz spreadsheet-uri pentru a rezuma i raporta
metricile datelor.
Observaii:
Dou dintre metricile de baz, i anume complexitatea proiectului i
fiabilitatea software, sunt dificil de evaluat i calculat manual, i de aceea
necesit instrumente automate (chiar gen sisteme expert) care s conduc
competent astfel de activiti..
Echipa MOD recomand ca instrument "Modelarea statistic i estimarea
funciilor de fiabilitate pentru software" (SMERFS) pentru msurarea fiabilitii
software. Acest instrument include o varietate de domenii incluznd IBM-PC -
urile i calculatoarele compatibile IBM-PC. Instrumentul de msurare al

282
complexitii este UX-metric / PC-metric de la SET Laboratories (1990). Acesta
este un instrument comercial ieftin care contorizeaz NLCS, comentarii, linii albe
i calculeaz metricile de complexitate pentru o varietate de limbaje de generaia
a treia incluznd FORTRAN, C i ADA. El lucreaz pe staii i suport sistemul
de operare UNIX la fel de bine ca i pe PC-uri, IBM compatibile.
O astfel de activitate trebuie organizat sistematic, ncepnd cu proiectarea,
achiziia de cunotine i continund cu implementarea, testarea i mentenan
sistemelor de programe pentru a putea "garanta" calitatea produsului software
elaborat i a-i demonstra, i n aceast manier, superioritatea fa de
programele tradiionale.

Ingineria sistemelor de programe Bibliografie

283
BIBLIOGRAFIE

[Arno, 1991] Arnold P.S., S.Bodoff, D.Coleman, H.E.Gilchrist, F.M.Hayes: An
Evaluation of five Object-Oriented Development Methods, J OOP,
1991, pp.107-121
[Bain, 2008] Bain S., - Emergent Design : The Evolutionary Nature of
Professional Software Development, Addison Wesley, March 2008,
448p., ISBN-0-321-50936-6.
[Bass, 2003] Bass L., P. Clements, R. Kazman Software Architecture in
Practice, Addison Wesley Pub., April 2003, 560p, ISBN- 0-321-
15495-9.
[Beck, 2007] Beck K., Implementation Patterns, Ed. Addison Wesley,
November 2007, 176p,ISBN- 0-321-41309-1.
[Beck, 1997] Beck K., Make It Run, Make It Right: Design Through
Refactoring, The Smalltalk Report, Vol.6, No.4, pp 19-24, SIGS
Publications, J anuary 1997.
[Booc, 1996] Booch G., Object Solutions, Addison Wesley, 1996
[Booc, 2005] Booch G., J . Rumbaugh, I. J acobson Unified Modeling Language
User Guide, Addison Wesley , 2005, 496p, ISBN- 0-321-26797-4.
[Busc, 2007] Buschmann F., Pattern-Oriented Software Architecture, Vol.4: A
Pattern Language for Distributed Computing , Ed. J ohn
Wiley&Sons, May 2007, 636 p., ISBN-0-470-05902-8.
[Busc, 1996] Buschmann F., R. Meunier, H. Rohnert, P. Sommerland, M. Stal
Pattern-Oriented Software Architecture : A System of Patterns,
J ohn Wiley&Sons, 1996.
[Caya,2002] Cayannes C., B. Keeton Enterprise JavaBeans 2.0., Editura
Teora, Bucureti, 2002
[Coad, 1995] Coad P., D. North, M. Mayfield,-Object Models: Strategies, Patterns
and Applications, Prentice Hall, 1995.

284
[Cook, 1994] Cook S., J . Daniels,- Designing Object Systems :Object Oriented
Modeling with Syntropy, Prentice Hall, 1994.
[Coop, 1997] Cooper, J . W.- Principles of Object-Oriented Programming in Java
1.1 Coriolis(Ventana), 1997.
[Coop, 1998] Cooper J .,W.- The Design Patterns Java Companion, Addison-
Wesley, 1998, 218p.
[Copl, 1995] Coplien J ., - A Generative Development Process Pattern
Language, Coplien & Schmidt, 1995, pp. 183-237.
[Cosh, 1995] Coplien, J ames O. and Schmidt, Douglas C., Pattern Languages of
Program Design, Addison-Wesley, 1995.
[Doc MySql] Documentaia MySQL - http://dev.mysql.com/doc/
[DocJ ava16] Documentaia Java 1.6
http://java.sun.com/javase/6/docs/api/index.html
[Duva, 2007] Duvall P., Continous Integration : Improving Software Quality and
Reducing Risk, Addison Wesley, 2007, 336p, ISBN-0-321-33638-0.
[Eclipse, Pr] Eclipse Project - www.eclipse.org/
[Essent. Soft] Essential Software Engineering- www.rspa.com/spi/
[Gamm, 1997] Gamma E., R. Helm, R. J ohnson, J . Vlissides Design Patterns:
Elements of Reusable Object-Oriented Software, Ed. Addison
Wesley, 1997, 395p, ISBN - 0-201-63361-2.
[Grad, 1993] Grady, R.B .- Practical Results from Measuring Software
Quality, Commun. ACM, Vol.36, No.11, Nov., 1993.
[Grad, 1992] Grady, R.B. Practical Software metrics for Project
Management and Process Improvement , Prentice-Hall, New
York, 1992, pp.17-18, 75-78, 139-140, 161, 171, 215, 232.
[Grah, 1992] Graham M, E. Mettala The Domain Specific Software
Architecture Program. Proceedings of DARPA Software
Technology Conference, 1992, pp.204-210
[Hanm, 2007] Hanmer R., Patterns for Fault Tolerant Software, Ed. J ohn Wiley
& Sons, December 2007, 308p, ISBN-0-470-31979-8.

285
[Fort, 2001] Forta B., R. Keer Dezvoltarea aplcaiilor JavaServer Pages,
Editura Teora Bucureti, 2001.
[Fowl, 1997] Fowler M., - Analysis Patterns: Reusable Object Models, Addison
Wesley, 1997
[Fowl, 1999] Fowler M., K. Beck, J . Brant, W. Opdyke, D. Roberts Refactoring:
Improving the Design of Existing Code, Addison Wesley Pub. J uly
1999, ISBN-0-201-48567-2.
[Fowl, 2003] Fowler M., UML Distilled A Brief Guide of the Standard Object
Modeling Language, Addison Wesley, 2003, 208p, ISBN-0-321-
19363-7.
[J ava2SDK] J ava 2 SDK- Standard Edition
http://java.sun.com/products/jdk/1.4.1/
[J 2EE Tutor] J 2EE Tutorial- http://java.sun.com/j2ee/tutorial
[Kosk, 2007] Koskela L., Test Driven : TDD and Acceptance TDD for Java
Developers, Ed. Manning, 2007, 470p., ISBN- 0-193-23985-0.
[Kura, 1998] Kurata D., - Programming with Objects, Visual Basic Programmers
J ournal, J une, 1998.
[Leve, 1992] Levendel, Y. Reliability Analysis of Large Software Systems
Defect Data Modeling, , IEEE Trans. Software Eng., No. 16,
pp. 141-152, 1992.
[Lisk, 1987] Liskov B., Data Abstraction and Hierarchy, The Conference On
Object Oriented Programming Systems Languages and
Applications, ACM, New York, USA, 1987, p.17-34, ISBN-0-89791-
266-7.
[MaOd,1996] Martin J ., J .J . Odell- Object-Oriented Methods: Pragmatic
Considerations, Prentice Hall, 1996
[Mart, 1996] Martin R., Design Principle and Design Patterns, 1996
www.objectmentor.com/resources/articles/ocp.pdf

286
[McGr,2001] McGregor J ., D. Sykes A Practical Guide to Testing Object-
Oriented Software, Addison Wesley, 2001, 417 p., ISBN -0-201-
32564-0.
[Meye, 1994] Meyer B., Object Oriented Software Construction,
Prentince Hall, 1994
[Nova, 1994] Novac, C. Sistem expert pentru asigurarea fiabilitii complexului
integrat de control al navigabilitii pe timp de furtun, Tez de
doctorat, Galati, 1994.
[Nova, 1999] Novac, C., Inginerie software, Ed. Tehnica, Bucuresti, 1999, 162
pagini, ISBN 973-31-1354-9;
[Nova, 2008] Novac-Ududec, C., Metode i tehnici pentru proiectarea sistemelor
software, Ed. Didactic i Pedagogic, Bucureti, 2008, ISBN 978-
973-30-2094-3, 311 pag.
[Nyga, 2007] Nygard M., Release It: Design and Deploy Production Ready
Software, Pragmatic Bookshelf Pub., 2007, 326p, ISBN- 0-978-
73921-3.
[Pair Prog] Pair Programming- www.pairprogramming.com
[Pree, 1994] Pree, Wolfgang, Design Patterns for Object Oriented Software
Development, Addison-Wesley, 1994.
[Pres, 1992] Pressman R., Software Engineering. A Practitioner's Approach, The
3
th
Edition, McGraw-Hill, 1992.
[Riel, 1996] Riel, Arthur J ., Object-Oriented Design Heuristics, Addison-Wesley,
Reading, MA, 1996.
[Rumb, 1994]Rumbaugh J . The life of an Object Model : How the Object Model
Change DuringDevelopment. J ournal of Object-Oriented
Programming, 7(1):24-32, March/April, 1994.
[Rumb, 1996]Rumbaugh J ., - OMT Insights, SIGS Books, 1996.
[Shal, 2000] Shalloway A, J . Trott Design Patterns Explained: A New
Perspective on Object-Oriented Design, 2000, 358p.
[Scrum Met] SCRUM Methodology www.controlchaos.com

287
[Shla, 1997] Shlaer S., S. Mellor Recursive Design of an Application
Independent Architecture, IEEE Software, Vol.14, No.1, 1997.
[Shor, 2007] Shore J .,, S. Warden The Art of Agile Development, Ed. OReilly
Media, October 2007, 430p, ISBN- 0-596-52767-5.
[Tudo, 2007] Tudosa L., abloane de proiectare software n realizarea unei
aplicaii OO - Lucrare de disertaie master, Departamentul de
Calculatoare i Informatic Aplicat, Universitatea Dunrea de
J os, Galai, 2007.
[Vlis, 1996] Vlissides J ., J . Coplien, N. Kerth, - Pattern Languages of Program
Design 2 [PloPD2], Addison Wesley, 1996.
[Well, D. J .] Wells D. J ., - Ghid practic pentru programarea extrem
www.extremeprogramming.org

Carte CNovac

Încărcat de

Informații document

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

Carte CNovac

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSITATEA Vasile Alecsandri

S-ar putea să vă placă și