1/135

INGINERIE SOFTWARE........................................................................................................................ 5
1 FAZELE DEZVOLTRII UNUI PRODUS SOFTWARE............................................................ 6
1.1 CE ESTE INGINERIA PROGRAMRII?............................................................................................. 6
1.2 FAZELE INGINERIEI PROGRAMRII............................................................................................... 9
1.2.1 Faza de analiz................................................................................................................. 9
1.2.2 Faza de proiectare .......................................................................................................... 10
1.2.3 Faza de implementare..................................................................................................... 12
1.2.4 Faza de testare................................................................................................................ 12
1.3 CONCLUZII ................................................................................................................................ 13
2 METODOLOGII DE DEZVOLTARE A PROGRAMELOR..................................................... 14
2.1 ETAPELE DEZVOLTRII PROGRAMELOR..................................................................................... 14
2.2 METODOLOGII GENERICE .......................................................................................................... 15
2.2.1 Metodologia secvenial ................................................................................................. 15
2.2.2 Metodologia ciclic ........................................................................................................ 16
2.2.3 Metodologia hibrid ecluz ............................................................................................ 17
2.3 METODOLOGII CONCRETE ......................................................................................................... 19
2.3.1 Metodologia cascad...................................................................................................... 19
2.3.2 Metodologia spiral........................................................................................................ 20
2.3.3 Metodologia spiral WinWin.......................................................................................... 22
2.3.4 Prototipizarea ................................................................................................................. 22
2.3.5 Metodologia Booch......................................................................................................... 23
2.3.6 Metode formale ............................................................................................................... 23
2.3.7 Extreme Programming.................................................................................................... 23
2.4 CONCLUZII ................................................................................................................................ 25
3 MANAGEMENTUL UNUI PROIECT SOFTWARE.................................................................. 26
3.1 MANAGEMENTUL SOFTWARE.................................................................................................... 26
3.1.1 Planificarea proiectului .................................................................................................. 27
3.1.2 Controlul proiectului ...................................................................................................... 28
3.2 MANAGEMENTUL CONFIGURAIEI............................................................................................. 29
3.3 MANAGEMENTUL ECHIPEI ......................................................................................................... 31
3.3.1 Managementul forei de munc....................................................................................... 31
3.3.1.1 Mecanisme de coordonare ........................................................................................................... 32
3.3.1.2 Stiluri de management ................................................................................................................. 32
3.3.2 Organizarea echipei........................................................................................................ 33
3.3.2.1 Organizarea ierarhic................................................................................................................... 33
3.3.2.2 Organizarea matrice..................................................................................................................... 34
3.3.2.3 Echipa programatorului ef.......................................................................................................... 35
3.3.2.4 Principii generale de organizare a unei echipe............................................................................. 35
3.4 CONCLUZII ................................................................................................................................ 36
4 ESTIMAREA COSTULUI UNUI PROIECT SOFTWARE........................................................ 37
4.1 INTRODUCERE ........................................................................................................................... 37
4.2 CUM NU TREBUIE ESTIMAT COSTUL........................................................................................... 39
4.3 MODELE ALGORITMICE CLASICE ............................................................................................... 40
4.4 MODELE ALGORITMICE MODERNE............................................................................................. 42
4.4.1 Modelul Walston-Felix.................................................................................................... 44
4.4.2 Modelul COCOMO......................................................................................................... 45
4.4.3 Modelul Putnam-Norden................................................................................................. 46
4.5 DISTRIBUIREA FOREI DE MUNC N TIMP ................................................................................. 46
4.6 CONCLUZII ................................................................................................................................ 48
5 REUTILIZAREA RESURSELOR SOFTWARE......................................................................... 49
5.1 INTRODUCERE ........................................................................................................................... 49
5.2 REUTILIZAREA PRODUSELOR INTERMEDIARE ............................................................................ 50
5.2.1 Biblioteci i componente software .................................................................................. 50
5.2.2 abloane.......................................................................................................................... 53
5.2.3 Reutilizarea proiectrii ................................................................................................... 53
2/135
5.2.4 Sisteme de transformare.................................................................................................. 54
5.2.5 Generatoare de aplicaii i limbaje de a patra generaie ............................................... 55
5.3 REUTILIZAREA INSTRUMENTELOR I A TEHNICILOR .................................................................. 55
5.3.1 Limbaje de interconectare a modulelor .......................................................................... 55
5.3.2 Programarea orientat obiect ........................................................................................ 58
5.4 PERSPECTIVELE REUTILIZRII SOFTWARE ................................................................................. 58
5.5 ECONOMIA REUTILIZRII SOFTWARE......................................................................................... 61
5.5.1 Economia refolosirii software......................................................................................... 61
5.5.2 Reutilizarea software i managementul .......................................................................... 61
5.5.3 Aspecte psihologice ale reutilizrii software .................................................................. 62
5.6 CONCLUZII ................................................................................................................................ 62
6 INGINERIA CERINELOR. ANALIZA ORIENTAT OBIECT............................................ 63
6.1 INGINERIA CERINELOR............................................................................................................. 63
6.1.1 Cerina ............................................................................................................................ 63
6.1.2 Extragerea cerinelor...................................................................................................... 64
6.1.3 Metode pentru identificarea cerinelor utilizatorilor...................................................... 64
6.1.4 Metode pentru specificarea cerinelor utilizatorilor....................................................... 65
6.1.4.1 Limbajul natural........................................................................................................................... 65
6.1.4.2 Formalisme matematice ............................................................................................................... 65
6.1.4.3 Engleza structurat....................................................................................................................... 65
6.1.4.4 Tabele .......................................................................................................................................... 66
6.1.4.5 Diagrame bloc ale sistemului ....................................................................................................... 66
6.1.5 Documentul cerinelor utilizatorului (DCU)................................................................... 66
6.1.5.1 Evoluia DCU .............................................................................................................................. 66
6.1.5.2 Responsabiliti............................................................................................................................ 67
6.1.5.3 Coninutul DCU........................................................................................................................... 67
6.2 ANALIZA ORIENTAT OBIECT. METODE DE ANALIZ ORIENTAT OBIECT ................................. 67
6.2.1 Principiile analizei orientate obiect................................................................................ 68
6.2.2 Abstractizarea................................................................................................................. 69
6.2.3 Motenirea ...................................................................................................................... 69
6.2.4 Comunicarea prin mesaje ............................................................................................... 69
6.3 METODA DE ANALIZ COAD-YOURDON.................................................................................... 69
6.3.1 Activitatea I: Identificarea claselor i obiectelor............................................................ 70
6.3.2 Activitatea a Il-a: Identificarea structurilor ................................................................... 71
6.3.2.1 Structura gen-spec........................................................................................................................ 71
6.3.2.2 Structura ntreg-parte ................................................................................................................... 73
6.3.2.2.1 Strategii de identificare a structurilor ntreg-parte ............................................................... 75
6.3.2.2.2 Verificarea structurilor ntreg-parte ..................................................................................... 76
6.3.3 Activitatea a IlI-a: Identificarea atributelor ................................................................... 76
6.3.3.1 Identificarea atributelor................................................................................................................ 77
6.3.3.2 Poziionarea atributelor ................................................................................................................ 77
6.3.3.3 Identificarea conexiunilor instanelor........................................................................................... 77
6.3.3.4 Verificarea cazurilor speciale....................................................................................................... 78
6.3.3.5 Specificarea atributelor ................................................................................................................ 78
6.3.4 Activitatea a IV-a: Identificarea serviciilor .................................................................... 79
6.3.5 Activitatea a V-a: Identificarea subiectelor.................................................................... 81
6.4 CONCLUZII ................................................................................................................................ 82
7 PROIECTAREA ORIENTAT OBIECT..................................................................................... 83
7.1 PROCESUL PROIECTRII SISTEMELOR SOFTWARE ...................................................................... 83
7.2 CARACTERISTICILE UNEI PROIECTRI CORECTE ........................................................................ 83
7.2.1 Extensibilitatea ............................................................................................................... 83
7.2.2 Sigurana......................................................................................................................... 84
7.2.3 Eficiena.......................................................................................................................... 84
7.3 PROIECTAREA ORIENTAT OBIECT ............................................................................................ 85
7.4 ETAPELE PROIECTRII ORIENTATE OBIECT ................................................................................ 85
7.4.1 Contextul sistemului i modelele de utilizare.................................................................. 86
7.4.2 Proiectarea arhitecturii .................................................................................................. 86
7.4.3 Identificarea obiectelor................................................................................................... 87
7.4.4 Modele de proiectare ...................................................................................................... 87
7.4.5 Specificarea interfeelor obiectelor................................................................................. 87
3/135
7.5 METODA DE PROIECTARE COAD-YOURDON.............................................................................. 88
7.5.1 Activitatea I: Proiectarea componentei domeniului problemei ...................................... 88
7.5.2 Activitatea a Il-a: Proiectarea componentei interaciunii cu factorul uman .................. 91
7.5.3 Activitatea a IlI-a: Proiectarea componentei coordonrii task-urilor............................ 92
7.5.4 Activitatea a IV-a: Proiectarea componentei coordonrii datelor ................................. 92
7.6 CONCLUZII ................................................................................................................................ 92
8 LIMBAJE DE MODELARE. UML............................................................................................... 93
8.1 LIMBAJE DE MODELARE ............................................................................................................ 93
8.2 CE ESTE UML? ......................................................................................................................... 94
8.3 MODELAREA CAZURILOR DE UTILIZARE.................................................................................... 95
8.4 MODELAREA CONCEPTUAL. DIAGRAMA DE CLASE ................................................................. 97
8.4.1 Asocierea ........................................................................................................................ 98
8.4.2 Agregarea ..................................................................................................................... 100
8.4.3 Compunerea.................................................................................................................. 101
8.4.4 Vizibilitatea atributelor i operaiilor........................................................................... 101
8.4.5 Motenirea .................................................................................................................... 102
8.4.6 Polimorfismul................................................................................................................ 103
8.4.7 Interfee......................................................................................................................... 104
8.4.8 Metode statice............................................................................................................... 105
8.5 DIAGRAME DE INTERACIUNE................................................................................................. 105
8.5.1 Diagrama de secvene................................................................................................... 105
8.5.2 Diagrama de colaborare............................................................................................... 106
8.6 DIAGRAME DE ACTIVITI ...................................................................................................... 107
8.7 DIAGRAME DE STRI ............................................................................................................... 109
8.8 DIAGRAMA PACHETELOR ........................................................................................................ 110
8.9 DIAGRAME DE IMPLEMENTARE ............................................................................................... 111
8.9.1 Diagrama componentelor ............................................................................................. 111
8.9.2 Diagrama de lansare .................................................................................................... 112
8.10 CONCLUZII .............................................................................................................................. 112
9 IMPLEMENTAREA..................................................................................................................... 113
9.1 INTRODUCERE ......................................................................................................................... 113
9.2 LIMBAJE DE PROGRAMARE ...................................................................................................... 113
9.2.1 Limbaje imperative ....................................................................................................... 114
9.2.2 Limbaje declarative ...................................................................................................... 114
9.3 ANALIZA UNOR LIMBAJE DE PROGRAMARE ............................................................................. 115
9.3.1 C/C++........................................................................................................................... 115
9.3.2 Basic ............................................................................................................................. 117
9.3.3 Pascal ........................................................................................................................... 118
9.3.4 Java............................................................................................................................... 118
9.3.5 C#.................................................................................................................................. 119
9.4 COMPARAIE NTRE UNELE LIMBAJE DE PROGRAMARE ........................................................... 119
9.5 UTILITARE PENTRU IMPLEMENTARE I TESTARE...................................................................... 123
9.6 CONCLUZII .............................................................................................................................. 125
10 PSIHOLOGIA SI ETICA PROGRAMRII.......................................................................... 126
10.1 PROGRAMAREA CA ACTIVITATE UMAN ................................................................................. 126
10.1.1 Scrierea programelor.................................................................................................... 128
10.1.1.1 Comentariile............................................................................................................................. 129
10.1.1.2 Numele variabilelor ................................................................................................................. 129
10.1.1.3 Indentaia ................................................................................................................................. 130
10.1.2 Concepte ale limbajelor de programare....................................................................... 130
10.1.3 Interfaa cu utilizatorul ................................................................................................. 131
10.2 ETICA PROGRAMRII ............................................................................................................... 133
10.2.1 Codul etic IEEE ............................................................................................................ 133
10.2.2 Legea drepturilor de autor............................................................................................ 133
10.2.3 Licena public general GNU..................................................................................... 134
10.3 CONCLUZII .............................................................................................................................. 135

4/135

5/135
Inginerie software
6/135
1 Fazele dezvoltrii unui produs software
1.1 Ce este ingineria programrii?
tiina calculatoarelor este un domeniu relativ nou. Primele calculatoare au fost
construite la mijlocul anilor 1940 i de atunci au avut loc dezvoltri spectaculoase, 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. Dup ce a prevzut n 1981 c nici un program pentru calculatoare
personale nu va necesita vreodat mai mult de 640 KB de memorie RAM, Bill Gates admite
n 1995 c lucrurile s-au schimbat n ultimele dou decenii.
Urmtoarele exemple ofer o imagine asupra gradului de complexitate la care au ajuns
programele n zilele noastre:
sistemul de rezervare a biletelor pentru compania aerian KLM coninea, n anul
1992, dou milioane de linii de cod n limbaj de asamblare;
sistemul de operare System V versiunea 4.0 (UNIX) a fost obinut prin
compilarea a 3.700.000 linii de cod;
programele scrise pentru naveta spaial NASA au circa 40 de milioane de linii
de cod;
pentru realizarea sistemului de operare IBM OS360 au fost necesari 5000 de ani-
om.
Creterea programelor n dimensiune i complexitate a depit cu mult progresele fcute
n domeniul tehnicilor de programare. De aceea, programarea a devenit i a rmas mai mult o
art dect o meserie.
O paralel cu ingineria construciilor este atractiv. Dac dorim s construim o cuc
pentru cine, putem s mergem prin 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 reuim, putem ncerca a doua zi din nou cu alte lemne i alte cuie. Iar 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. Atunci 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 a doua 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-1
verifica. De asemenea, studii geologice, de fizic a pmntului sau meteorologie vor fi
obligatorii. Vor fi folosite 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.
Inginerii de programe ar trebui s procedeze similar pentru ca dezvoltarea programelor s nu
mai fie un proces impredictibil.
Pe msur ce complexitatea programelor cretea, la sfritul anilor '60 ncepea s se
prefigureze deja o criz a programrii. Un raport prezentat de ctre o companie, n care erau
analizate cteva proiecte i stadiile lor de finalizare, a constatat c:
7/135
2% din sistemele software contractate au funcionat de la predare;
3% din sistemele software au putut funciona dup cteva modificri;
29% au fost predate dar n-au funcionat niciodat;
19% au fost folosite dar au fost abandonate; 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 programrii (engl. software
engineering"), ntr-un mod oarecum provocator. Se dorea ca arta programrii s mprumute
din rigoarea tiinelor inginereti pentru a putea livra programe la timp i n mod economic.
Prima definiie dat ingineriei programrii a fost enunat astfel (F. L. Bauer):
Ingineria programrii 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.
In IEEE Standard Glossary of Software Engineering Technology (1983) ingineria
programrii este definit dup cum urmeaz:
Ingineria programrii 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 se pare c 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, i anume ntreinerea i
retragerea din funcionare.
Considerm c ingineria programrii are urmtoarele caracteristici importante:
este aplicabil n producerea de programe mari;
este o tiin inginereasc;
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.
ntruct un singur sau civa programatori 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. Apare ca dezirabil o abordare riguroas a acestor probleme, ce include
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 i continu s funcioneze fr ntreruperi un
interval de timp. Aceast noiune exprim de fapt rezistena la condiiile de funcionare. Un
sistem de operare trebuie s fie fiabil pentru c trebuie s funcioneze o perioad suficient de
lung de timp fr s cad, 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.
Programul este sigur dac funcioneaz corect, fr operaii nedorite. Un automat bancar
trebuie s fie sigur, pentru a efectua tranzaciile n mod absolut corect, chiar dac funcionarea
8/135
sa poate fi ntrerupt din cnd n cnd. Atunci cnd funcioneaz ns, trebuie s funcioneze
foarte bine.
Un program are o eroare (engl. bug") dac nu se comport corect. Se presupune c
dezvoltatorul tia ce ar fi trebuit programul s fac, iar comportamentul greit nu este
intenionat. Iat cteva erori celebre:
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;
Sistemul de operare IBM OS360 coninea aproximativ 1.000 de greeli la fiecare
nou versiune care ncerca s rezolve greelile din versiunea precedent;
Un vehicul de explorare a planetei Venus a fost pierdut deoarece programul
primit de pe Pmnt pentru rectificarea orbitei coninea linia 'DO 31= 1.3';
instruciunea corect n limbajul FORTRAN ar fi trebuit s conin virgul n loc
de punct;
In 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;
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;
Racheta Arianne 5 a explodat n iunie 1996 din cauza unei greeli de
programare; costurile s-au ridicat la 500 milioane dolari.
Ingineria programrii 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
lucrurile s mearg, innd seama de restriciile organizaiei n care lucreaz i de
constrngerile financiare.
Problema fundamental a ingineriei programrii este ndeplinirea cerinelor clientului.
Aceasta trebuie realizat nu punctual, nu n acest moment, ci ntr-un mod flexibil i pe termen
lung. Ingineria programrii se ocup cu toate etapele dezvoltrii programelor, de la extragerea
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. Rezumnd, atributele cheie ale unui produs software se refer la:
posibilitatea de a putea fi ntreinut: un produs cu un lung ciclu de via este
supus deseori modificrilor, de aceea el trebuie foarte bine documentat;
fiabilitate: produsul trebuie s se comporte dup cerinele utilizatorului i s nu
cad" mai mult dect e prevzut n specificaiile sale;
eficien: produsul nu trebuie s foloseasc n pierdere resursele sistemului ca
memoria sau ciclii procesor;
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 (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 programrii nu rezolv toate problemele care apar atunci cnd
se scriu programe. Ingineria programrii nu ofer nici teorii. Inginerii fac lucrurile s mearg.
Totui, n momentul de fa, ingineria programrii ne poate spune sigur ce s nu facem.
9/135
1.2 Fazele ingineriei programrii
Exist patru faze fundamentale ale metodologiilor ingineriei programrii:
analiza (ce dorim s construim);
proiectarea (cum vom construi);
implementarea (construirea propriu-zis);
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.
1.2.1 Faza de analiz
Aceast faz definete cerinele sistemului, independent de modul n care acestea vor fi
ndeplinite. Aici se definete problema pe care clientul dorete s o rezolve. Rezultatul acestei
faze este documentul cerinelor, 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 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 (monitoare care nu suport rezoluii mari). 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 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 i 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.
In 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:
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;
Aciuni: Documentul trebuie s defineasc de asemenea aciunile pe care trebuie
s le ndeplineasc sistemul i care sunt sugerate n general de construcii
verbale. Exemple de aciuni sunt: metodele, funciile sau procedurile;
10/135
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;
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 i 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;
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.;
Cerine incomplete sau nemonotone: O enumerare complet a cerinelor pentru
toate situaiile care pot aprea n condiii de lucru reale nu este posibil. In
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 teoreme
dezvoltate sunt adugate teoremelor stabilite. In 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 i 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.
1.2.2 Faza de proiectare
Pe baza cerinelor din faza de analiz, acum se stabilete arhitectura sistemului:
componentele sistemului, interfeele i modul lor de comportare:
Componentele sunt elementele constructive ale produsului. Acestea pot fi create
de la zero sau reutilizate dintr-o bibliotec de componente. Componentele
rafineaz i captureaz semnificaia detaliilor din documentul cerinelor;
Interfeele ajut la mbinarea componentelor. O interfa reprezint grania dintre
dou componente, utilizat pentru comunicarea dintre acestea. Prin intermediul
interfeei, componentele pot interaciona;
Comportamentul, determinat de interfa, reprezint rspunsul unei componente
la stimulii aciunilor altor componente.
11/135
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 de tip globale, interfeele etc.
In 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 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 i complexitatea implementrii. Analiza performanelor presupune studierea
modului n care diferitele arhitecturi conduc la diferite caracteristici de performan pentru
fiecare scenariu tipic. In funcie de frecvena de utilizare a scenariilor, fiecare arhitectur va
avea avantaje i dezavantaje. Un rspuns rapid la o aciunea 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. Ins 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 este rareori
ndeplinit. De obicei, un test cu o acoperire de 90% este simpl, 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 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 BlOS-ului era destul de mic, cteva mii de linii. Ins
deoarece BIOS-ul are o natur asincron, testul a presupus mai nti crearea unui mediu
asincron care s aduc sistemul n starea dorit i 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 test! In final, o acoperire de 100% a fost
atins, dar cu un cost foarte ridicat. O soluie mai ieftin a fost nscrierea BlOS-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.
In 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.
12/135
1.2.3 Faza de implementare
In 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
debug. Scopul este producerea sistemului propriu-zis. O problem important este
ndeprtarea erorilor critice, ntr-un sistem exist trei tipuri de erori:
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;
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;
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.
1.2.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.
In multe metodologii ale ingineriei programrii, 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 adunate i dac exist erori, bug-ul 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, n sistem a aprut o greeal. Greeala este corectat i
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.
13/135
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.
Testarea intern i 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 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 i 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. In trecut, aceste scripturi erau create manual. In prezent,
exist instrumente care automatizeaz i 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. 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 i 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 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 dealoc. Testul pare s
funcioneze corect, ns dup ce este rulat de mai multe ori, memoria disponibil se reduce iar
sistemul cade.
1.3 Concluzii
n acest curs s-a fcut mai nti o introducere n problematica domeniului ingineriei
programrii, insistndu-se pe cauzele care au determinat dezvoltarea sa: creterea continu a
complexitii sistemelor software. Apoi s-au descris cele patru faze fundamentale ale
metodologiilor ingineriei programrii: analiza, proiectarea, implementarea i testarea,
necesare pentru realizarea unor sisteme de calitate.
14/135
2 Metodologii de dezvoltare a programelor
1. Etapele dezvoltrii programelor
2. Metodologii generice
2.1. Metodologia secvenial
2.2. Metodologia ciclic
2.3. Metodologia hibrid ecluz
3. Metodologii concrete
3.1. Metodologia cascad
3.2. Metodologia spiral
3.3. Metodologia spiral WinWin
3.4. Prototipizarea
3.5. Metodologia Booch
3.6. Metode formale
3.7. Extreme Programming
4. Concluzii
2.1 Etapele dezvoltrii programelor
Cnd pornim la dezvoltarea unui program avem nevoie de:
nelegere clar a ceea ce se cere;
un set de metode i instrumente de lucru;
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-1 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:
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);
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;
Proiectarea detaliat: Se realizeaz proiectarea fiecrui modul al aplicaiei, n
cele mai mici detalii;
Scrierea codului: Proiectul detaliat este transpus ntr-un limbaj de programare.
De obicei, aceasta se realizeaz modular, pe structura rezultat la proiectarea
arhitectural;
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
15/135
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;
Validarea: n procesul de validare ne asigurm c programul ndeplinete
cerinele utilizatorului, ntrebarea la care rspundem este: construim produsul
corect? Un exemplu de validare este testul de acceptare, n care produsul este
prezentat clientului. Clientul spune dac este mulumit cu produsul sau dac mai
trebuie efectuate modificri;
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?
ntreinerea: Dup ce programul este livrat clientului, mai devreme sau mai
trziu sunt descoperite defecte sau erori ce trebuie reparate. De asemenea, 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.
2.2 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), fazele sunt dispuse n cicluri care i
genereaz incremental contribuiile la sistemul final. Metodologia hibrid (ecluz) combin
progresul constant al metodologiei secveniale cu incrementale iterative ale metodologiei
ciclice.
2.2.1 Metodologia secvenial
n metodologia secvenial, 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.

Figura 2-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
16/135
greu de schimbat. Aceast metodologie foreaz analiza i planificarea naintea implementrii,
o practic foarte nimerit n multe situaii.
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.
2.2.2 Metodologia ciclic
Metodologia ciclic, 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. In 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. In
final, dup cteva cicluri, sistemul este complet i gata de lansare. Procesul poate ns
continua pentru lansarea mai multor versiuni ale produsului.

Figura 2-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
17/135
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. In aceast situaie, fiecare ciclu 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.
2.2.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 preia natura iterativ a metodologiei spiral, la care
adaug progresul sigur al metodologiei cascad.
Analiza
Proiectare
Implementare
Testare
Proiectare
Implementare
Testare
Implementare
Testare
Testare
Produs
Schita de principiu
Prototip
Alfa / Beta
Produs

Figura 2-3 Metodologia hibrid ecluz
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. In funcie de dimensiunea echipelor, mai multe sarcini
pot fi realizate n paralel. Sarcinile rmase, de prioritate minim, sunt pstrate pentru
18/135
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.
Prioritile se stabilesc pe baza unei funcii de prioritate, care depinde att de domeniul
problemei 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.
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 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. Totui, majoritatea produselor care urmeaz
acest model eueaz. 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 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. In
produsul final nu se accept erori critice.
Avantaje
19/135
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.
2.3 Metodologii concrete
2.3.1 Metodologia cascad
Metodologia cascad, propus de Barry Boehm, este una din cele mai cunoscute
exemple de metodologie de ingineria programrii. Exist numeroase variante ale acestui
proces. Intr-o variant detaliat, metodologia cascad cuprinde urmtoarele etape:
Cerinte sistem si validare
Cerinte software si validare
Analiza si validare
Proiectare detaliata si validare
Scriere cod si debug
Testare si validare
Intretinere si revalidare

Figura 2-4 Metodologia cascad
Dup fiecare etap exist un pas de validare. 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.
20/135
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 1-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 /' care sunt descoperite la pasul / + 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), 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.
2.3.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:
studiul de fezabilitate;
analiza cerinelor;
proiectarea arhitecturii software;
implementarea.
Modelul n spiral 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. Exemple de riscuri:
n timpul unui proces ndelungat de dezvoltare, cerinele noi ale clientului sunt
ignorate;
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.
In 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);
21/135
planificarea urmtorului stadiu: termenele limit, resurse umane, revizuirea strii
proiectului.
Metodologia spiral cuprinde urmtoarele etape, grupate pe patru cicluri:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

Figura 2-5 Metodologia spiral
Ciclul l - Analiza preliminar:
1. Obiective, alternative, constrngeri
2. Analiza riscului i prototipul
3. Conceperea operaiilor
4. Cerinele i planul ciclului de via
5. Obiective, alternative, constrngeri
6. Analiza riscului i prototipul
Ciclul 2 - Analiza final:
7. Simulare, modele, benchmark-uri
8. Cerine software i validare
9. Plan de dezvoltare
10. Obiective, alternative, constrngeri
11. Analiza riscului i prototipul
Ciclul 3 - Proiectarea:
12. Simulare, modele, benchmark-uri
13. Proiectarea produsului software, validare i verificare
14. Integrare i plan de test
15. Obiective, alternative, constrngeri
16. Analiza riscului i prototipul operaional
Ciclul 4 - Implementarea i testarea:
17. Simulare, modele, benchmark-uri
18. Proiectare detaliat
19. Cod
20. Integrarea unitilor i testarea acceptrii
21. Lansarea produsului
22/135
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.
2.3.3 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. Procesul WinWin identific un 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.
2.3.4 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. Ins 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:
de aruncat (throw-away);
evoluionar.
n cazul realizrii unui prototip de aruncat, 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:
permite dezvoltatorilor s elimine lipsa de claritate a specificaiilor;
23/135
ofer utilizatorilor ansa de a schimba specificaiile ntr-un mod ce nu afecteaz
drastic durata de dezvoltare;
ntreinerea este redus, deoarece validarea se face pe parcursul dezvoltrii;
se poate facilita instruirea utilizatorilor finali nainte de terminarea produsului.
Dintre dezavantajele principale ale prototipizrii amintim:
deoarece prototipul ruleaz ntr-un mediu artificial, anumite dezavantaje ale
produsului final pot fi scpate din vedere de clieni;
clientul nu nelege de ce produsul necesit timp suplimentar pentru dezvoltare,
avnd n vedere c prototipul a fost realizat att de repede;
deoarece au n fiecare moment ansa de a face acest lucru, clienii schimb
foarte des specificaiile;
poate fi nepopular printre dezvoltatori, deoarece implic renunarea la propria
munc.
2.3.5 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 validare. 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.
2.3.6 Metode formale
In acest model de dezvoltare, sunt folosite formalismul i rigoarea matematicii. In prima
faz este construit o specificaie n limbaj matematic. Apoi, aceast specificaie este
transformat n programe, de obicei ntr-un proces incremental.
Avantaje:
precizia obinut prin specificarea formal;
pstrarea corectitudinii n timpul transformrii specificaiei n cod executabil;
ofer posibilitatea generrii automate de cod;
sunt potrivite pentru sisteme cu cerine critice.
Dezavantaje:
specificarea formal este de obicei o barier de comunicare ntre client i analist;
necesit personal foarte calificat (deci mai scump);
folosirea impecabil a tehnicilor specificrii formale nu implic neaprat
obinerea de programe sigure, deoarece anumite aspecte critice pot fi omise din
specificaiile iniiale.
2.3.7 Extreme Programming
Extreme Programming (Kent Beck, 1996) este o metodologie care propune rezolvri
originale pentru problemele care apar n dezvoltarea de programe. Fiind o tehnologie nou (i
24/135
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.
Carta drepturilor dezvoltatorului:
Ai dreptul s tii ceea ce se cere, prin cerine clare, cu declaraii clare de
prioritate;
Ai dreptul s spui ct i va lua s implementezi fiecare cerin, i s i
revizuieti estimrile n funcie de experien;
Ai dreptul s i accepi responsabilitile, n loc ca acestea s-i fie asignate;
Ai dreptul s faci treab de calitate n orice moment;
Ai dreptul la linite, distracie i la munc productiv i plcut.
Carta drepturilor clientului:
Ai dreptul la un plan general, s tii ce poate fi fcut, cnd, i la ce pre;
Ai dreptul s vezi progresul ntr-un sistem care ruleaz i care se dovedete c
funcioneaz trecnd teste repetabile pe care le specifici tu;
Ai dreptul s te rzgndeti, s nlocuieti funcionaliti i s schimbi
prioritile;
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:
Echipa de dezvoltare nu are o structur ierarhic. Fiecare contribuie la proiect
folosind maximul din cunotinele sale;
Scrierea de cod este activitatea cea mai important;
Proiectul este n mintea tuturor programatorilor din echip, nu n documentaii,
modele sau rapoarte;
La orice moment, un reprezentant al clientului este disponibil pentru clarificarea
cerinelor;
Codul se scrie ct mai simplu;
Se scrie mai nti cod de test;
Dac apare necesitatea rescrierii sau eliminrii codului, aceasta se face fr mil;
25/135
Modificrile aduse codului sunt integrate continuu (de cteva ori pe zi);
Se programeaz n echip (programare n perechi). Echipele se schimb la
sfritul unei iteraii (1-2 sptmni);
Se lucreaz 40 de ore pe sptmn, fr lucru suplimentar.
2.4 Concluzii
Au fost prezentate aici cele mai importante metodologii de dezvoltare a programelor.
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".
26/135
3 Managementul unui proiect software
3.1 Managementul software
Multe proiecte de dezvoltare software au probleme, mai devreme sau mai trziu
deoarece ori programul nu este livrat la timp, ori bugetul este depit, ori clienii sunt
nemulumii. De multe ori cauzele sunt de natur tehnic. Ins, n la fel de multe situaii,
problemele i au originea n organizarea i managementul proiectului. Cnd un produs este
livrat prea trziu, motivele prezentate sunt n general urmtoarele:
programatorii nu au spus adevrul despre situaia real a codului;
clientul nu tia ce vrea de fapt;
echipa de management a subestimat timpul necesar terminrii proiectului;
echipa de management nu a acordat suficient timp pentru planificarea atent a
proiectului;
productivitatea programatorilor s-a dovedit mult inferioar ateptrilor.
Aparent, nu e simplu s termini cu succes un proiect de dezvoltare software. Pe lng
aspectele tehnice, legate n general de cele patru faze prezentate anterior (analiz, proiectare,
implementare, testare), s-a dovedit c aspectele privind organizarea i managementul
proiectului sunt cel puin la fel de importante.
Un proiect de dezvoltare software nu este de obicei complet izolat. In cadrul firmei se
poate lucra i la alte proiecte i deci poate fi necesar identificarea unor legturi ntre proiecte,
stabilirea de prioriti etc. Pentru acest proces de meta-planificare (planificare a planificrii)
se folosete deseori termenul planificare informaional. Scopul su este precizarea unor
condiii sau constrngeri pentru fiecare proiect concret.
De asemenea, nici din punct de vedere tehnic programul nu este pornit de la zero. El
trebuie s fie interfaat cu programe existente, s extind funcionalitatea altor programe, s
foloseasc biblioteci de funcii etc. De fapt, nsui termenul de dezvoltare software poate fi
considerat nepotrivit. Nu doar programul este dezvoltat, ci un ntreg sistem. Software-ul este o
component principal, dar nu este unic.
S considerm un sistem pentru automatizarea unei biblioteci. El va conine diverse
componente soft, precum baze de date despre cri i persoane sau interfee pentru prelucrarea
interactiv a cererilor utilizatorilor. Pe lng acestea, trebuie gsite modaliti de rezolvare a
unor probleme de genul:
identificarea electronic a crilor prin coduri de bare;
achiziionarea de componente hardware care s scaneze aceste coduri i s
creeze elemente de identificare pentru crile noi;
instruirea bibliotecarilor pentru utilizarea noilor instrumente de lucru (cursuri,
instruire practic etc.);
alctuirea unei documentaii prietenoase pentru abonai.
Un proiect de dezvoltare software poate fi vzut astfel:
27/135
Program
Program
Software
Oameni
Documentatie
Proceduri
Intrare Iesire
C
o
n
s
t
r
a
n
g
e
r
i

Figura 3-1 Abordarea sistemic a unui proiect de dezvoltare software
Se observ c sistemul cuprinde un numr de componente. La rndul su, n sens mai
restrns, i componenta software poate include mai multe module de program care
interacioneaz i asigur funcionalitatea dorit n mod colectiv.
Pe baza constrngerilor, se ncepe lucrul la un anumit proiect concret. Primul pas, de
mare importan, este planificarea proiectului. Apoi, pe parcursul execuiei trebuie controlate
cinci entiti: timpul, informaiile, organizarea, calitatea i banii.
3.1.1 Planificarea proiectului
Planificarea proiectului presupune identificarea proprietilor care vor influena
dezvoltarea. Aceste proprieti nu sunt foarte bine nelese dect dup terminarea fazei de
analiz. De aceea, planificarea are n mod necesar o natur dinamic.
Cooper (1984) subliniaz 13 elemente importante ale planului proiectului:
b) Introducerea: Sunt descrise condiiile i istoricul proiectului, mpreun cu
scopurile, numele persoanelor responsabile i un sumar al proiectului;
c) Implicarea utilizatorului: Viitorii utilizatori vor fi implicai din timp n timp
n proiect. Planul trebuie s cuprind ce informaii, servicii i resurse sunt
asigurate de utilizatori i cnd se va ntmpla acest lucru;
d) Riscurile: In orice moment exist riscuri: hardware-ul nu va fi livrat la timp,
personalul calificat este insuficient, lipsesc informaii eseniale .a.m.d. n mod
ideal, riscurile poteniale trebuie identificate ct mai devreme i echipa de
management trebuie s ia msuri pentru eliminarea lor. Pe msur ce
necunoscutele proiectului devin mai numeroase, crete i numrul riscurilor;
e) Standardele, tehnicile, procedurile: Proiectele software sunt proiecte mari, n
care sunt implicate multe persoane. De aceea, este nevoie de o disciplin de
lucru clar, bazat pe standarde i proceduri asupra crora toat lumea a czut
de acord. O mare importan o are documentaia: cnd trebuie livrat, cum este
evaluat calitatea sa, cum se asigur permanenta sa actualizare;
28/135
f) Organizarea proiectului: n cadrul echipei proiectului se identific diverse
roluri: project manager, tester, programator, analist etc. Aceste roluri trebuie
clar delimitate iar atribuiile fiecruia trebuie bine precizate i clarificate. In
acest scop, poate fi necesar o perioad de instruire a membrilor echipei;
g) Fazele proiectului: n primul curs au fost amintite fazele de dezvoltare ale
unui produs software. Metodologiile de aplicare a acestora sunt numeroase.
Echipa de management trebuie s se decid care model va fi urmat i care sunt
paii obligatorii. Proiectul trebuie divizat n pri gestionabile care pot fi
alocate unor echipe diferite. De asemenea, trebuie estimate timpul i costul
fiecrei faze. Tipuri diferite de proiecte au diferite caracteristici i necesit
deci modele diferite;
h) Analiza cerinelor i proiectarea: Se indic metodele i tehnicile care vor fi
utilizate n analiz i proiectare, precum i resursele i instrumentele necesare
pentru acestea;
i) Implementarea: Se identific resursele i instrumentele necesare pentru
implementare i se precizeaz cum va fi gestionat volumul foarte mare de
documentaie tehnic ce va rezulta de aici;
j) Testarea: Se descriu mediile i echipamentele de test necesare;
k) Resursele: Sunt enumerate resursele hardware i instrumentele necesare
pentru proiect;
l) Asigurarea calitii: Se identific procedurile care vor fi folosite pentru a
verifica dac proiectul ndeplinete standardele de calitate dorite;
m) Modificrile: Pentru un proiect, modificrile sunt inevitabile. Echipa de
management trebuie s se asigure c aceste schimbri sunt tratate ntr-un mod
organizat, pe baza unor proceduri bine definite. Fiecare modificare propus
trebuie nregistrat i revzut. Cnd o modificare este aprobat, se estimeaz
costurile corespunztoare. Dup ncorporarea sa n sistemul existent, trebuie
redactate noi versiuni ale documentaiei pentru a reflecta schimbrile din cod;
n) Livrarea: n final, trebuie respectate procedurile necesare pentru livrarea
produsului ctre client.
Planul proiectului trebuie s furnizeze o imagine clar a ceea ce trebuie fcut, att
pentru client ct i pentru echipa de realizare. Dac obiectivele nu sunt clare, ele nu vor fi
niciodat ndeplinite.
3.1.2 Controlul proiectului
Dup ce planul proiectului a fost realizat i aprobat, poate ncepe executarea propriu-
zis. Pe parcursul executrii, trebuie controlate urmtoarele dimensiuni:
timpul;
informaiile;
organizarea;
calitatea;
banii.
Cursul de evoluie al proiectului (aspectul timp) este greu de msurat. Afirmaiile de
genul 90% din cod a fost deja scris" trebuie cntrite de dou ori nainte de a fi crezute. De
obicei, se prezint o situaie mai bun a proiectului dect este n realitate. Timpul necesar
construirii unui sistem este n mod evident legat de dimensiunea sa i deci de fora de munc
utilizat. Cu ct un sistem este mai mare, cu att este necesar mai mult timp pentru
dezvoltarea sa, dei se poate ncerca scurtarea intervalului prin alocarea suplimentar de
personal. Una din problemele care apar aici este gsirea unui compromis ct mai bun ntre
timpul de dezvoltare i resursele umane folosite. Totui, cu ct sunt implicate mai multe
29/135
persoane, cu att va crete timpul pentru coordonare i comunicare. Peste un anumit punct,
mrirea personalului va avea ca efect creterea timpului de dezvoltare. n acest sens, legea lui
Brooks afirm c adugarea de personal la un proiect ntrziat l va ntrzia i mai mult.
Din punctul de vedere al informaiilor, accentul principal cade pe realizarea
documentaiei: documentele utilizatorului, documentele tehnice i documentaia proiectului
nsui, care include starea curent de lucruri, modificrile convenite, deciziile luate.
n cadrul echipei, fiecare persoan trebuie s-i cunoasc foarte clar rolul. Dac rolurile
nu sunt definite sau sunt neclare, fiecare individ i va stabili propriile scopuri, care pot intra
n contradicie cu scopurile proiectului. Project manager-ul trebuie s in seama de aceste
aspecte organizaionale la alctuirea echipei i stabilirea atribuiilor.
Calitatea este foarte important, deoarece clienii nu se mulumesc cu soluii pur
tehnice, ci doresc sisteme adecvate nevoilor lor reale. De multe ori, cerinele de calitate pot fi
conflictuale. Pe parcursul executrii proiectului, acestea trebuie mereu evaluate, pentru ca s
poat fi luate msuri din timp pentru remedierea problemelor. Calitatea nu trebuie s fie o
trstur adugat, ci o caracteristic intrinsec a sistemului.
Controlarea resurselor financiare nseamn n mare parte controlarea costurilor de
personal. Dei costurile asociate hardware-ului i diferitelor instrumente nu poate fi neglijat,
acestea pot fi de obicei estimate destul de precis n fazele incipiente ale proiectului. Estimarea
costului se reduce astfel la estimarea forei de munc necesare, care depinde de muli factori.
Un factor important este dimensiunea software-ului (determinat de exemplu de mrimea
codului). Exist ns i ali factori care influeneaz costurile sau productivitatea. O echip
bine echilibrat de persoane experimentate vor avea o productivitate mult mai mare dect o
echip nou format de persoane fr experien.
3.2 Managementul configuraiei
Pe parcursul ciclului de via al unui proiect de dezvoltare software sunt create i
actualizate un mare numr de elemente, precum module de cod surs, cerine de modificare
etc. Pentru gestionarea acestora trebuie s existe un set de proceduri bine definite, care poart
numele de managementul configuraiei.
De cele mai multe ori, un sistem .software nu este monolitic. Sistemele exist n diferite
versiuni i configuraii. Versiunile diferite apar atunci cnd sunt fcute modificri dup ce
sistemul a fost livrat clientului. Din timp n timp, clientul este confruntat cu o nou lansare.
Diferite versiuni pot exista i pentru componentele din sistem. Dac o modificare a fost
aprobat, un programator poate implementa schimbarea prin rescrierea unei componente, n
acelai timp, un altul poate utiliza n continuare versiunea anterioar a aceleiai componente.
La orice moment trebuie s existe o singur versiune oficial setului de documente
legate de proiect. Aceasta se numete linie de baz (engl. baseline"), definit ca standard
IEEE: o specificaie sau un produs care a fost analizat i acceptat n mod formal, care
servete n continuare ca baz pentru dezvoltarea viitoare i care poate fi modificat numai prin
proceduri formale de control al modificrilor". Linia de baz este deci o baz de date partajat
care conine toate entitile aprobate, denumite entiti de configurare (engl. configuration
items"). O entitate de configurare este definit de asemenea ca standard IEEE astfel: o
colecie de elemente hardware sau software tratate ca o unitate n scopul gestionrii
configuraiei".
Exemple de entiti de configuraie sunt:
modulele de cod surs;
modulele de cod obiect;
specificarea cerinelor;
documentaia de proiectare;
planul de test;
30/135
cazurile de test;
rezultatele de test;
manualul utilizatorului.
O sarcin fundamental a managementului configuraiei este meninerea integritii
acestui set de elemente, lucru deosebit de important atunci cnd modificrile sunt integrate n
sistem. S presupunem c n faza de testare este descoperit o eroare major ntr-un modul.
Atunci toi paii deja efectuai trebuie parcuri n ordine invers i pe lng modificarea
codului trebuie modificate i documentele de proiectare sau chiar cerinele. Aceste schimbri
pot interaciona cu munca altor programatori, care folosesc versiunea anterioar. Mai ru, un
alt programator poate efectua propriile sale modificri la acelai modul. Managementul
configuraiei se ocup de gestionarea tuturor acestor schimbri pe parcursul ntregului ciclu de
via al produsului.
Orice modificare propus pentru linia de baz se numete cerere de modificare i este
tratat precum urmeaz:
Modificarea este trimis comisiei de control al configuraiei (CCC). Pentru
evaluarea propunerii, comisia are nevoie de informaii privind modul n care
schimbrile vor afecta produsul i procesul de dezvoltare: volumul de cod nou
sau modificat, cerine suplimentare de test, legtura cu alte schimbri, costurile
poteniale, complexitatea modificrii, severitatea erorii (dac e cazul), resursele
necesare etc.;
CCC evalueaz cererea, care poate fi aprobat, respins sau amnat dac sunt
necesare mai multe informaii. Dac este aprobat, se stabilete un termen de
implementare;
CCC se asigur c toate entitile de configuraie afectate de schimbare vor fi
actualizate corespunztor.
Am menionat c entitile din baza de date partajat pot fi utilizate fr restricii de toi
membrii echipei. Dac o entitate trebuie modificat, persoana responsabil de schimbare
primete o copie a entitii i apoi entitatea este blocat temporar, astfel nct nimeni s nu
poat o modifica n acelai timp. Persoana desemnat acioneaz asupra copiei. Dup ce
modificarea este testat, este trimis napoi la CCC. Dup ce comisia o aprob, entitatea este
inclus n baza de date, schimbarea e documentat i apoi entitatea e deblocat. irul de
modificri documentate formeaz istoricul reviziei entitii.
Cnd o entitate e modificat, este pstrat i versiunea veche. Aceasta poate fi nc
utilizat de alte persoane pn cnd acestea se adapteaz schimbrii. Avnd versiuni diferite
pentru aceeai entitate, trebuie s existe o modalitate de a le distinge. De obicei, se prefer o
schem numeric, n care fiecare versiune urmtoare este identificat de urmtorul numr.
Pentru o component X vom avea deci versiunile X.0, X.1, X.2 .a.m.d.
Schema GNU de numerotare denot versiunea unui produs software printr-un triplet de
ntregi: versiunea major, versiunea minor i patch-ul. ntre dou versiuni majore, n produs
au loc schimbri majore ale funcionalitii i n acest caz nu este garantat compatibilitatea
napoi.
Dimpotriv, ntre dou versiuni minore ale aceleiai versiuni majore trebuie s existe
compatibilitate. De exemplu, formatele de fiiere suportate de o versiune ulterioar trebuie s
fie suportate i de versiunea minor anterioar. Rolul unei versiuni minore este introducerea
unor funcii noi. Funciile vechi nu vor fi ndeprtate; totui documentaia programului l
poate avertiza pe utilizator c la anumite funcii se va renuna n viitor.
Patch-ul nu poate realiza dect schimbri n implementarea unor funcii. De obicei,
rolul su este corectarea unor erori ale programului.
Aceste reguli nu se aplic ns i pentru programele n versiuni alfa sau beta (O.F).
nainte de versiunea 1.0, deoarece programul este n curs de formare, sunt permise modificri
31/135
importante ntre versiuni. Totui, versiunea 1.0 trebuie s reprezinte o platform stabil, cu ct
mai puine bug-uri, care s poat fi utilizat cu ncredere de clieni. Nu e neaprat necesar ca
aceasta s conin ct mai multe funcionaliti, ci ca funciile implementate s fie ct mai
sigure. Noi funcionaliti pot fi adugate n versiunile urmtoare.
La nivelul codului surs, managementul configuraiei este sprijinit de instrumente
puternice, care blocheaz i deblocheaz elementele, asigur numerotarea automat a
reviziilor i furnizeaz utilizatorului ultima versiune disponibil.
Un astfel de instrument este CVS (Concurrent Versions System), care permite crearea
istoricului schimbrilor din cod. Cnd sursele sunt modificate uneori apar erori, care pot fi
detectate abia dup un interval mare de timp de la modificare, n aceste situaii este util
identificarea versiunilor vechi i implicit a schimbrilor care au produs eroarea. CVS nu
salveaz toate fiierele surs din diferitele versiuni, ci numai modificrile aduse fiierelor. De
asemenea, cnd mai muli programatori lucreaz la acelai proiect, trebuie evitat
suprascrierea de ctre o persoan a modificrilor alteia. O rezolvare a acestei probleme este
blocarea unui fiier astfel nct acesta s nu poat fi modificat dect de un singur dezvoltator
la un anumit moment de timp. Abordarea CVS se bazeaz pe izolarea programatorilor,
astfel nct fiecare lucreaz n propriul su director, iar la sfrit, cnd toi au terminat,
programele sunt integrate.
3.3 Managementul echipei
n multe organizaii care dezvolt proiecte software, programatorii, analitii i ali
profesioniti lucreaz mpreun ntr-o echip. Stabilirea structurii adecvate a unei echipei
depinde de muli factori, precum numrul de persoane, experiena i gradul de implicare n
proiect, tipul proiectului, diferenele individuale i stilul.
Orice tip de proiect implic un numr de sarcini de lucru. O responsabilitate
fundamental a project manager-ului este coordonarea i distribuirea sarcinilor ctre toi
membrii echipei. Pentru un proiect mic, echipa va consta n cteva persoane. Pe msur ce
crete dimensiunea proiectului, i dimensiunea echipei va crete. Echipele mari sunt dificil de
coordonat iar volumul comunicrii dintre membri tinde s creasc exponenial cu mrimea
echipei. De aceea, echipele mari sunt mprite n subechipe astfel nct majoritatea
comunicrii i coordonrii s se desfoare la nivelul acestora.
3.3.1 Managementul forei de munc
O echip este format din indivizi, fiecare cu scopurile sale personale. Este sarcina
project manager-ului s formeze din acetia o echip, n care scopurile individuale sunt
subscrise scopului proiectului ca ntreg. Identificarea nc de la nceput a scopurilor
proiectului este foarte important, iar aceste scopuri trebuie aduse la cunotina membrilor
echipei, n caz contrar, fiecare persoan i va stabili propriile scopuri, ceea ce poate cauza
probleme serioase. De exemplu, un programator pune accent pe viteza programului, altul
dorete s foloseasc ct mai puin memorie, iar altul consider c cel mai important este s
scrie ct mai multe linii de cod.
Dup ce au fost stabilite scopurile, trebuie monitorizate i evaluate performanele
membrilor echipei. Acest lucru este dificil, deoarece mare parte din ceea ce se face este
invizibil" iar progresul e greu de msurat. De aceea, n mod ideal, se definete
productivitatea drept suma funcionalitilor realizate n unitatea de timp. Din punct de
vedere practic, productivitatea se definete ca numrul de linii de cod realizate pe lun-om.
Toat lumea este de acord c nu este o msur optim, dar pn n prezent nu s-a gsit una
mai bun. Una din marile pericole ale utilizrii acestei metode este faptul c programatorii
tind s scrie ct mai mult cod cu putin, care are efecte negative. De asemenea, definiia
32/135
aceasta a productivitii nu ncurajeaz reutilizarea componentelor, care ar conduce la scrierea
unui cod mai mic.
3.3.1.1 Mecanisme de coordonare
Mintzberg (1983) distinge cinci configuraii organizaionale tipice:
Structura simpl: ntr-o structur simpl exist unul sau numai civa manageri
i un nucleu de persoane care lucreaz la producia proiectului propriu-zis.
Aceast configuraie este ntlnit de obicei n firmele noi, cu personal redus.
Specializarea este limitat, la fel i instruirea i formalizarea. Mecanismul de
coordonare corespunztor este supervizarea direct;
Birocraia automat: Cnd coninutul sarcinilor este complet specificat, este
posibil executarea acestora pe baz de instruciuni precise. Exemple tipice ale
acestui tip de configuraie sunt producia de mas i liniile de asamblare.
Instruirea este redus, n schimb se pune mare accent pe specializare i
formalizare. Coordonarea se obine prin standardizarea proceselor de lucru;
Forma divizionalizat: n acest tip de configuraie fiecrei divizii (fiecrui
proiect) i se acord o mare autonomie n ceea ce privete modul de atingere a
scopurilor. Detaliile sunt stabilite de divizii. Coordonarea se obine prin
standardizarea produciei. Controlul se exercit regulat prin msurarea
performanelor diviziilor. Acest mecanism de coordonare este posibil numai
atunci cnd este specificat precis rezultatul final;
Birocraia profesional: Dac nu este posibil specificarea rezultatului sau
coninutul sarcinilor, coordonarea poate fi realizat prin standardizarea
calificrii. Profesionitii talentai se bucur de o autonomie considerabil privind
modul de ndeplinire a atribuiilor;
Adhocraia: n proiecte mari i/sau inovatoare, lucrul este divizat ntre mai
muli specialiti, n acest caz, poate fi greu sau chiar imposibil de stabilit cu
precizie ce trebuie s fac fiecare specialist sau modul n care trebuie s-i
ndeplineasc sarcinile. Succesul proiectului depinde de capacitatea grupului de
a atinge un scop nespecificat ntr-un mod nespecificat. Coordonarea se obine
prin ajustare reciproc.
Trebuie spus c majoritatea organizaiilor reale nu pot fi ncadrate ntr-un singur tip de
configuraie. Diferite departamente ale firmei pot fi organizate diferit. De asemenea, tipurile
prezentate reprezint idei abstracte, n realitate, organizaiile pot tinde spre unul din aceste
tipuri, pstrnd n acelai timp i caracteristici ale celorlalte.
3.3.1.2 Stiluri de management
Teoria lui Reddin (1970) a stilurilor de management pune accent pe factorii interni.
Autorul distinge dou dimensiuni ale managementului forei de munc:
gradul de dirijare a relaiei: se refer la atenia acordat individului i relaiilor
lui cu ali indivizi din organizaie;
gradul de dirijare a sarcinii: privete atenia acordat rezultatelor care trebuie
obinute i modului n care acestea trebuie obinute.
Gradele de dirijare pot fi sczute sau ridicate, ceea ce conduce la patru combinaii de
baz, prezentate n Tabelul 3-1. Desigur, aceste combinaii corespund unor orientri extreme.
Pentru fiecare dimensiune, exist n realitate o ntreag gam de nuane.

gradul de dirijare a sarcinii gradul de dirijare a
relaiei
sczut ridicat
33/135
sczut stil de separare stil de angajament
ridicat stil de relaionare stil de integrare
Tabelul 3-1 Stilurile de management ale lui Reddin
Stilul cel mai potrivit pentru o anumit situaie depinde de tipul lucrrii:
Stilul de separare: Este cel mai potrivit pentru munca de rutin. Eficiena este
tema central. Project manager-ul se comport ca un birocrat care aplic reguli i
proceduri. Acest stil corespunde configuraiei birocraiei automate;
Stilul de relaionare: Este cel mai eficient n situaiile n care oamenii trebuie
motivai, coordonai i instruii. Sarcinile sunt clar atribuite indivizilor. Munca
nu are un caracter de rutin, ci este inovatoare i specializat. Stilul este
asemntor configuraiei de adhocraie;
Stilul de angajament: Este cel mai eficient cnd se lucreaz sub tensiune.
Project manager-ul trebuie s tie cum s se ating scopurile fr s trezeasc
resentimente. Stilul e asemntor configuraiei de birocraie profesional;
Stilul de integrare: Se potrivete situaiilor cnd rezultatul este nesigur. Munca
are o natur exploratorie i sarcinile au un puternic caracter de interdependen.
Rolul project managerului este s stimuleze i s motiveze. i n acest caz,
configuraia de adhocraie este cea mai apropiat.
Fiecare proiect de dezvoltare software poate necesita diferite mecanisme. De exemplu,
pentru o echip experimentat, care trebuie s dezvolte o aplicaie bine specificat ntr-un
domeniu familiar, coordonarea poate fi realizat prin standardizarea produciei. Pentru o
aplicaie complex i novatoare, acest mecanism ar fi ineficient.
3.3.2 Organizarea echipei
Indivizii coopereaz n cadrul unei echipe pentru a obine un rezultat optim, ntr-o
echip se pot distinge diverse roluri: exist manageri, testeri, designeri, programatori .a.m.d.
n funcie de dimensiunea proiectului, o persoan poate ndeplini mai multe roluri, sau diferite
persoane pot avea acelai rol. Este foarte important ca atribuiile rolurilor s fie bine precizate
i delimitate. Este de asemenea important ca anumite roluri s fie separate; de exemplu, se
recomand separarea echipei de test de echipa de implementare.
Echipele mari sunt greu de gestionat i deseori sunt mprite n subechipe. Prin
definirea clar a responsabilitilor subechipelor, comunicarea dintre membrii echipei se
limiteaz la comunicarea n cadrul aceleiai subechipe, ceea ce mrete productivitatea.
3.3.2.1 Organizarea ierarhic
n mediile dedicate producerii de software, se ntlnesc deseori structuri ierarhice. n
funcie de dimensiunea proiectului i/sau a organizaiei, pot exista diferite nivele de
management.
Figura 3-2 prezint un exemplu de organizare ierarhic. Dreptunghiurile denot
subechipele n care se lucreaz efectiv. Cercurile reprezint managerii. Aici avem dou nivele
de management. La nivelul inferior, subechipele sunt responsabile de dezvoltarea diferitelor
pri ale proiectului. Managerii acestora au rolul de a le coordona activitatea. La nivelul
superior, se coordoneaz activitatea subechipelor pe ansamblu.
34/135
P
A D C B
Subechipa A Subechipa B Subechipa C Testare

Figura 3-2 Organizare ierarhic
Organizarea ierarhic reflect deseori structura global a sistemului care trebuie
dezvoltat. Dac sistemul are trei subsisteme majore, pot exista trei subechipe. De asemenea,
pot exista uniti funcionale asociate cu responsabiliti specifice proiectului, cum ar fi
testarea.
O problem a organizrii ierarhice este distana dintre nivelele superioare i inferioare
ale piramidei. Munca real" se face de obicei pe nivelele inferioare, unde sunt prelucrate
cunotinele concrete despre aplicaie. Pe msur ce ne ridicm n ierarhie, cunoaterea devine
din ce n ce mai puin specific; de aceea managementul de pe nivelele superioare tinde s
aplice coordonarea prin standardizare. Totui, chiar dac deciziile importante se iau la aceste
nivele, n multe cazuri sunt luate n considerare semnalele venite de pe nivelele de jos, care
sunt de obicei nsumate pe nivele intermediare.
De multe ori, pe msur ce informaia urc n ierarhie, lucrurile tind s par din ce n ce
mai bune. Urmtorul scenariu nu este imposibil:
nivelul de jos: avem probleme serioase la implementarea modulului X;
nivelul 1: sunt ceva probleme cu modulul X;
nivelul 2: progresul este constant, nu prevd probleme reale;
nivelul de sus: totul merge conform planului.
Aceste distorsiuni sunt totui dificil de mpiedicat. Ele sunt cauzate de faptul c linia
ierarhic pe care se raporteaz progresul este aceeai cu cea utilizat pentru evaluarea
performanelor. Oamenii doresc evaluri pozitive i de aceea tind s-i modifice i rapoartele
n consecin. Dac datele privind progresul proiectului sunt colectate i prelucrate de
persoane neimplicate n evaluarea membrilor echipei, cresc mult ansele ca i informaiile s
fie suficient de corecte.
Un alt aspect problematic al acestui tip de organizare este faptul c individul este
judecat, att din punct de vedere social ct i financiar, dup nivelul pe care l ocup n
ierarhie. Este de neles aspiraia de a ajunge pe nivele din ce n ce mai nalte, dei nu este
foarte clar dac acest lucru este de dorit. Principiul lui Peter din legile lui Murphy spune: ntr-
o organizaie ierarhic, fiecare angajat urc pn la nivelul su de incompeten. Totui, un
programator bun nu e neaprat i un bun manager. Programarea necesit competene diferite
de cele ale managementului. Ideal ar fi stimularea oamenilor pentru meninerea lor pe
nivelele la care lucreaz cel mai bine.
3.3.2.2 Organizarea matrice
Acest tip de organizare este deseori ntlnit n situaia cnd la un proiect software
lucreaz oameni din diferite departamente i care pot avea simultan mai muli efi. Unitatea
de baz este un grup mic, specializat. Pot exista mai multe uniti cu aceeai specializare.
Unitile sunt organizate n conformitate cu specializarea lor; de exemplu: grafic
computerizat, baze de date, interfee utilizator, controlul calitii etc. Proiectele implic
35/135
uniti cu diferite specializri. Indivizii sunt organizai pe dou axe: una reprezentnd
grupurile specializate iar cealalt - proiectele la care particip:

programare n
timp real
grafic baze de date testare
proiectul A X X
proiectul B X X X
proiectul C X X X
Tabelul 3-2 Organizare matrice
n aceast situaie, project manager-ul este responsabil de terminarea cu succes a
proiectului. El controleaz una sau mai multe uniti i trebuie s menin sau s mreasc, pe
termen lung, baza de cunotine i experiena membrilor echipei. El poate pune accent pe
ridicarea gradului de dirijare a sarcinii, n timp ce managerii unitilor se pot concentra pe
creterea gradului de dirijare a relaiei. O astfel de organizare poate fi foarte eficient, cu
condiia s existe suficient ncredere reciproc i dorin de cooperare.
3.3.2.3 Echipa programatorului ef
Acest tip de organizare a fost propus de Harlan Mills (1970). Nucleul unei astfel de
echipe const n trei persoane. Programatorul ef este conductorul echipei i rspunde de
proiectarea i implementarea poriunilor cheie ale sistemului. El este ajutat de un asistent.
Dac e nevoie, acesta poate lua temporar locul programatorului ef. Un bibliotecar se ocup
de administrare i documentare. Pe lng aceste trei persoane, mai poate exista un mic grup de
experi. Evident, programatorul ef joac un rol central i trebuie s fie foarte competent, mai
ales n domeniul tehnic, dar i managerial. Se pune problema dac exist suficieni astfel de
programatori efi.
Noiunea iniial de programator ef pare elitist. Pentru un proiect de dimensiuni foarte
mari este mai plauzibil ideea unui grup restrns responsabil colectiv. Rolurile nu sunt
structurate n funcie de stadiile ciclului de via a produsului. Nu exist analiti, designeri,
programatori. Testarea ns poate fi alocat unei anumite persoane. In grup pot exista diferite
nivele de experien. Persoanele cele mai experimentate au rolul de programator ef i
asistent, nceptorii nva din mers i la nceput pot ndeplini rolul bibliotecarului.
3.3.2.4 Principii generale de organizare a unei echipe
Indiferent de modul n care este organizat o echip, cel mai important este faptul c
trebuie s fie o echip. Testele privind productivitatea n proiectele de dezvoltare software au
artat c factorii privind capacitile echipei au o importan mult mai mare dect orice
altceva. Principiile de organizare a unei echipe n general se aplic i n cazul proiectelor
software:
Folosirea unui numr mic de oameni capabili: Productivitatea maxim este
obinut de un grup relativ mic de oameni. Grupurile mari necesit mai mult
comunicare, care are efecte negative asupra productivitii i duce la erori mai
multe;
Sarcinile trebuie puse n acord cu motivaiile i capacitile oamenilor
disponibili: Cu alte cuvinte, trebuie s ne asigurm ca principiul lui Peter nu se
aplic i n cazul echipei noastre, n cele mai multe organizaii, programatorilor
foarte buni li se ofer funcii manageriale. Este mult mai bine s li se ofere
posibiliti de a avansa n carier n arii mai tehnice ale dezvoltrii i ntreinerii
software-ului;
36/135
Pe termen lung, organizaia are mai mult de ctigat dac i ajut pe angajai s
dea ceea ce au mai bun: Altfel spus, nici una din situaiile urmtoare nu trebuie
s aib loc:
Principiul lui Peter inversat: angajaii urc n ierarhie pn la nivelul la care
devin indispensabili: De exemplu, un programator poate deveni singurul expert
ntr-un anumit domeniu. El nu va avea ansa s lucreze n alt domeniu. S-ar
putea ca persoana respectiv s prseasc firma pentru a lucra la altceva mai
interesant;
Principiul lui Paul: angajaii urc n ierarhie pn la nivelul la care experiena lor
devine nvechit n cinci ani: Avnd n vedere viteza cu care noutile intr pe
piaa dezvoltrii software, angajaii trebuie s aib posibilitatea s fie la curent
cu acestea;
Este bine s fie selectai oameni care s formeze o echip bine echilibrat i
armonioas: Nu este suficient s existe n echip doar civa experi de vrf.
Trebuie s existe i persoane care s ndeplineasc sarcinile mai simple, de
rutin, pe care experii s-ar putea simi chiar insultai s le rezolve;
Cine nu se potrivete cu echipa trebuie ndeprtat: Dac echipa nu funcioneaz
ca o unitate coerent, de multe ori suntem nclinai s mai ateptm puin, s
vedem cum evolueaz lucrurile i s sperm ca totul va merge bine. Acest lucru
este duntor pe termen lung.
3.4 Concluzii
n acest curs au fost prezentate mai nti noiuni legate de managementul unui proiect
software, precum planificarea i controlul proiectului. Apoi au fost tratate problemele legate
de gestionarea crerii i modificrii elementelor caracteristice unui proiect de dezvoltare
software. Au fost explicate mecanismele care in de managementul unei echipe, privind n
deosebi coordonarea i stilurile de management, alturi de modaliti de organizare a echipei
i sfaturi practice pentru organizarea optim a unei echipe de dezvoltare a unui proiect
software.
37/135
4 Estimarea costului unui proiect software
4.1 Introducere
La construirea unei case, la decorarea unei bi sau a unei grdini, dorim s cunoatem
costul precis al operaiilor ce urmeaz a fi efectuate nainte de nceperea acestora. Un grdinar
este capabil s fac o aproximare a costurilor bazndu-se, de exemplu, pe tipul pmntului,
mrimea dorit a terasei sau a zonei cu iarb, prezena sau absena unui iaz i pe alte
informaii similare. Apoi aceast estimare poate fi fcut mai precis printr-un dialog ulterior
nainte de a se ncepe lucrrile. Cine dorete o precizie similar n ceea ce privete estimarea
costurilor pentru un proiect de dezvoltare software ar putea avea o surpriz.
Estimarea costurilor unei aplicaii software reprezint un domeniu foarte puin
dezvoltat, n care toi se bazeaz doar pe aproximri. Din fericire exist i excepii de la
aceast situaie. Acum exist un numr de algoritmi care ne permit s estimm costul total i
timpul de dezvoltare pentru un proiect software pe baza unui numr limitat de generatori
relevani de costuri.
n cele mai multe modele de estimare, este presupus o relaie simpl ntre cost i efort.
Efortul poate fi msurat de exemplu n luni-om (adic numrul estimativ de luni necesar unui
singur om s realizeze lucrarea), i fiecrei luni-om i se asociaz o sum fix de bani,
corespunztor salariului angajailor. Costul total estimat se obine nmulind numrul estimat
de luni-om cu factorul constant considerat.
Noiunea de cost total reprezint de obicei costul efortului iniial de dezvoltare software,
costul analizei cerinelor, proiectrii, implementrii i testrii, fr a fi luate n considerare
costurile de ntreinere. Prin timp de dezvoltare se nelege timpul dintre specificarea
cerinelor i momentul n care produsul software va fi predat clientului. Noiunea de cost, care
se va folosi n continuare, nu include i posibilele costuri hardware. Ea include numai
costurile legate de personalul angajat n dezvoltarea produsului software.
Cercetrile n domeniul estimrii costului sunt departe de a fi cristalizate. Diferite
modele folosesc diferite sisteme de msur i generatori de costuri, nct este foarte dificil
compararea lor. S presupunem c un model folosete o ecuaie de forma:
1.05
2.7 E KLOC =
Acesta ecuaie arat o relaie ntre efortul necesar i mrimea produsului (KLOC = Kilo-
Lines Of Code, kilo-linii de cod). Unitatea de msur a efortului poate fi numrul de luni-om
necesare. Apar aici mai multe ntrebri. Ce este o linie de cod? Numrm codul main sau
codul surs ntr-un limbaj de nivel nalt? Numrm de asemenea i comentariile, liniile libere
care mresc vizibilitatea sau nu? Lum n considerare i zilele libere, vacanele, concediile
medicale n noiunea de luni-om sau se refer numai la o msurare net? Diferite interpretri
ale acestor ntrebri pot conduce la rezultate complet diferite. Uneori nici nu este cunoscut ce
definiii au fost folosite n aplicarea modelului.
Pentru a determina ecuaiile unui model algoritmic de estimare a costului, putem urma
diferite abordri, n primul rnd ne putem baza ecuaia pe rezultatul experimentelor, ntr-un
asemenea experiment, n general variem un parametru, n timp ce ceilali parametri rmn
constani. In acest fel ncercm s determinm influena pe care o are parametrul care variaz.
Un exemplu tipic este cel ce testeaz dac comentariile ajut la nelegerea unui program.
Vom pune un numr de ntrebri despre acelai program unor programatori mprii n dou
grupuri. Primul grup va primi programul fr comentarii, iar al doilea grup va primi textul
aceluiai program, dar comentat. Folosind rezultatele celor dou grupuri, putem testa ipoteza
realist c o nelegere mai bun i mai rapid a programului are efecte pozitive asupra
ntreinerii programului.
38/135
O alt modalitate de a descoperi modele algoritmice de estimare a costului se bazeaz
pe o analiz a datelor unui proiect real, dar i pe un suport teoretic. O organizaie poate
strnge date despre un numr de sisteme software care au fost dezvoltate. Aceste date pot
privi timpul petrecut la diferite faze bine determinate, calificarea personalului implicat,
momentele de timp n care au aprut erori, att n timpul testrii ct i dup instalare,
complexitatea, robusteea i ali factori importani ai proiectului, mrimea diferitelor entiti
implicate i o analiz statistic a acestor date. Un exemplu pentru o asemenea relaie este cea
dat mai sus, ce exprim o legtur ntre E i KLOC. Aplicabilitatea i corectitudinea acestor
ecuaii este, n mod evident, dependent de corectitudinea datelor pe care se bazeaz. De
asemenea, trebuie cunoscut ipoteza ce st la baza ecuaiei.
Rezultatele obinute n acest fel reprezint o medie, cea mai bun aproximare bazat pe
datele disponibile, de aceea rezultatele obinute trebuie aplicate cu atenie. De exemplu,
programul ce urmeaz a fi dezvoltat n cadrul unui nou proiect nu se poate compara cu
produse anterioare datorit inovaiilor implicate. Estimarea costurilor pentru un proiect legat
de o navet spaial nu poate fi fcut printr-o simpl extrapolare a proiectelor anterioare.
Trebuie reinut c aplicarea oarb a unor formule din modele existente nu va rezolva
problema estimrii costului. Fiecare model necesit o adaptare la mediul n care va fi folosit.
Aceasta conduce la necesitatea colectrii continue a datelor din propriul proiect i aplicarea
unor metode statistice pentru a calibra parametrii modelului.
Neconcordanele dintre diferitele modele mai pot aprea deoarece:
Majoritatea modelelor ofer o relaie ntre numrul lunilor-om necesar i mrime
(n linii de cod). Dup cum am remarcat mai devreme, exist mai multe definiii
diferite pentru aceste noiuni;
Efortul nu nseamn ntotdeauna acelai lucru. Uneori se consider activitile
pornind de la conceperea produsului, dup ce au fost fixate cerinele. Alteori se
includ eforturile de ntreinere.
Cu toate acestea, modelele de estimare a costului au multe caracteristici comune.
Acestea reflect importana factorilor care intervin asupra costului de dezvoltare
i de efortului. Creterea nelegerii costului programelor ne permite s
identificm strategii de cretere a productivitii software, cele mai importante
fiind:
Scrierea de mai puin cod: Mrimea sistemului este una din cauzele principale a
efortului i a costului. Prin metode care ncearc sa reduc mrimea, cum ar fi
reutilizarea programului i utilizarea de limbaje de nivel nalt, se pot obine
reduceri semnificative;
Stimularea oamenilor s lucreze la capacitatea maxim: Capacitile de lucru
individual i n echip au un mare impact asupra productivitii. Angajarea celor
mai buni oameni este de obicei o afacere profitabil. O mai bun stimulare,
condiii mai bune de lucru, cursurile de perfecionare asigur oportuniti de
cretere a productivitii; Evitarea refacerii componentelor dezvoltate anterior:
Studiile au artat c pentru a rescrie ceea ce s-a produs deja este necesar un efort
considerabil. Aplicnd modele cum ar fi realizarea prototipurilor i utilizarea
metodelor moderne de programare precum ascunderea informaiilor, se pot
reduce semnificativ costurile;
Dezvoltarea i folosirea mediilor de dezvoltare integrate, cu instrumentele ce pot
ajuta la eliminarea sau eficientizarea unor etape.
Au fost fcute numeroase studii n care scopul principal era estimarea efortului necesar
pentru o sarcin limitat de programare. Primele experimente au fost realizate de Halstead
(1977). La baza modelului su st faptul c numrarea liniilor de cod poate constitui o
problem, chiar dac avem o definiie exact a termenului linie de cod". Unele linii sunt mult
39/135
mai complicate dect altele. Conform teoriei lui Halstead, este mai bine s se porneasc de la
un numr de uniti sintactice, dup cum sunt recunoscute de compilator. Halstead face
distincia ntre operatori i operanzi. Operatorii denot o operaie; exemple de operatori sunt
operatorii standard (+, -, *, etc.), dar i semnul de punctuaie punct i virgul (;) care arat
structura unei instruciuni i construcii ca if-then-else i while-do. Operanzii nseamn date:
variabile i constante. Calcularea numrului de operatori i operanzi dintr-un program va oferi
o mai bun msur a mrimii dect simpl calculare a numrului de linii.
Cele patru entiti de baz pentru un program, n modelul Halstead sunt:

1
n = numrul de operatori diferii;

2
n = numrul de operanzi diferii;

1
N = numrul total de apariii ale operatorilor;

2
N = numrul total de apariii ale operanzilor;
Pentru lungimea unui program, Halstead d urmtoarea ecuaie:
1 2
N N N = +
Astfel se obine o rafinare a msurrii numrului de linii simple de cod, LOC. Att LOC
ct i N ofer o bun corelaie cu efortul de programare. De aceea este important s se
gseasc modaliti de estimare a entitilor precum LOC i N n primele etape. Valoarea lui
N depinde de
1
n i
2
n . Valoarea lui
1
n este, de cele mai multe ori, un factor constant pentru
multe programe scrise ntr-un anumit limbaj de programare de nivel nalt. Aceast constant
depinde de limbajul de programare ales. De exemplu, pentru un limbaj dat, numrul maxim de
operatori care poate fi utilizat n orice program este fix: toi sunt prezentai n sintaxa
limbajului. Majoritatea programelor vor folosi un mare procent din acestea, cel puin o dat. O
ipotez consider c
2
n este determinat n principal de numrul de variabile (VRS) care apar
n program. Bazndu-se pe aceste presupuneri, a fost enunat urmtoarea relaie empiric:
102 5.31 LOC VARS = +
Astfel, fiecare program va conine aproximativ 100 de linii de cod, plus 5 linii
suplimentare pentru fiecare variabil ce apare n program. Primele experimente arat c n
acest fel se pot obine aproximri destul de corecte ale mrimii i efortului necesar. Valoarea
estimat a lui VRS poate fi obinut relativ devreme dac este folosit o metod de
proiectare top-down n combinaie cu un limbaj de nivel nalt.
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. Cunoscnd mrimea estimat a unui
proiect, vom fi interesai n continuare s evalum timpul de dezvoltare necesar. ntr-o
abordare naiv am putea considera c un proiect ce necesit 100 de luni-om poate fi realizat
ntr-un an cu o echip de 8,5 persoane sau ntr-o lun cu o echip de 100 de persoane. Aceast
abordare ns este prea simplist. Un proiect de o anumit dimensiune corespunde unei
anumite perioade de timp fizic. Dac vom ncerca s micorm acest timp nominal de
dezvoltare prea mult, vom intra ntr-o zon imposibil", iar ansele de eec vor crete.
4.2 Cum nu trebuie estimat costul
Costurile estimate au deseori o culoare politic, iar rezultatele sunt determinate de
argumente care nu au o natur tehnic. Motive tipice care reflect aceste argumente non-
tehnice sunt prezentate n exemplele urmtoare:
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;
40/135
Dac tim c concurena a fcut o ofert de 100.000 de euro, noi vom face o
ofert de 90.000 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.
Aceste estimri pot avea efecte dezastruoase, dup cum s-a demonstrat frecvent n
scurta istorie a acestui domeniu. Argumentele politice intervin ntotdeauna dac estimrile
sunt realizate de cei implicai direct n proiect, cum ar fi managerul proiectului sau o persoan
ce lucreaz direct cu acesta, n curnd estimrile vor influena sau vor fi influenate de ctre
dorinele acestor persoane.
Pe de alt parte, 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. Efortul necesar pentru aceste trei proiecte este descris
n tabelul de mai jos:
Compilatorul Efortul (n luni-om)
Compilatorul Efortul (n luni-om)
1 72
2 36
3 14
Pentru estimarea costului se poate apela la serviciul unui expert, care apeleaz la
propria sa experien. Factori greu de cuantificat, precum caracteristicile de personalitate sau
caracteristici neobinuite ale proiectului, pot fi astfel luai n considerare, n acest caz,
calitatea estimrii nu poate depi calitatea expertului.
Pentru o estimare mai precis se pot solicita mai muli experi. Totui, dac un grup de
persoane trebuie s gseasc mpreun o soluie, vom observa c unii membri ai grupului au
un impact mai mare asupra rezultatului dect ceilali. Unii nu i vor exprima opinia sau vor fi
impresionai de opiniile celorlali. Aceasta poate avea un impact negativ asupra rezultatului
final. Pentru a anticipa acest efect negativ, putem folosi metoda Delphi, n metoda Delphi,
fiecare expert i expune opinia n scris. Un moderator colecteaz estimrile obinute astfel i
le redistribuie celorlali experi, n acest proces nu sunt asociate numele experilor cu
estimrile lor. Fiecare expert va preda o nou estimare bazat pe informaiile primite de la
moderator. Acest proces continu pn cnd se ajunge la un consens.
O alt metod care dorete obinerea unei estimri mai bune este aceea de a avea un
expert care s realizeze mai multe estimri: o estimare optimist a, o estimare realist m i o
estimare pesimist b. Folosind o distribuie beta, efortul ateptat va fi:
4
6
a m b
E
+ +
=
Aceast estimare va fi probabil mai bun dect dac s-ar fi considerat numai media
aritmetic a lui a i b.
4.3 Modele algoritmice clasice
Mesajul din paragraful precedent este clar: pentru a obine estimri acceptabile, trebuie
nregistrate datele proiectelor anterioare. Procednd astfel, vom prezice costul pe baza
41/135
proprietilor msurabile ale proiectului curent. In acest paragraf, vom prezenta primele
demersuri pentru a obine modele algoritmice de estimare a costului programelor.
Nelson (1966) ofer un model liniar pentru estimarea efortului necesar pentru un proiect
de dezvoltare software. Modelele liniare au urmtoarea form:
0
1
n
i i
i
E a a x
=
= +

n
Coeficienii
i
a sunt constante, iar
i
x reprezint factorii care au impact asupra efortului
necesar. Un numr mare de factori poate influena productivitatea i implicit efortul necesar.
Analiznd cu atenie datele proiectelor precedente i diferite combinaii de factori, putem
ncerca s obinem un model cu un numr mic de factori. Nelson, de exemplu, sugereaz un
model care ia n considerare 14 factori:
1 2 3 4 5 5 7
8 9 10 11 12 13 14
33.63 9.15 10, 73 0.51 0.46 0.40 7.28 21.45
13.5 12.35 58.82 30.61 29.55 0.54 25.20
E x x x x x x x
x x x x x x x
= + + + + + +
+ + + + + +

n aceast ecuaie E reprezint numrul estimat de luni-om necesar. Semnificaia
factorilor
i
x i domeniul lor de definiie sunt prezentate n tabelul urmtor:
Factor Descriere Valori posibile
1
x Instabilitatea specificaiilor cerinelor 0-2
2
x
Instabilitatea proiectrii 0-3
3
x Procentajul de instruciuni matematice 0-100
4
x Procentajul de instruciuni I/O 0-100
5
x Numrul subprogramelor numr
6
x Utilizarea unui limbaj de nivel nalt 0 (da) / 1 (nu)
7
x
Aplicaie comercial 0 (da) / 1 (nu)
8
x Program de sine stttor 0 (da) / 1 (nu)
9
x
Primul program pe aceast main 1 (da) / 0 (nu)
10
x
Dezvoltare concurent de hardware 1 (da) / 0 (nu)
11
x Utilizarea dispozitivelor random-access 1 (da) / 0 (nu)
12
x
Maina gazd diferit de maina int 1 (da) / 0 (nu)
13
x
Numr de erori numr
14
x
Dezvoltare pentru o organizaie militar 0 (da) / 1 (nu)
Putem face mai multe observaii asupra acestui model, n dezvoltarea programelor
pentru aplicaiile de aprare, n care programele vor fi ncorporate n maini diferite de maina
gazd (un exemplu ar putea fi programul de control al zborului pentru rachete), factori precum
12
x i
14
x vor avea cu siguran un impact mare asupra costului. Aceasta nu se va mai verifica
ns ntr-un caz complet diferit. Observm din nou c baza de date cu datele proiectelor care
stau la baza modelului au un impact semnificativ asupra factorilor care influeneaz costul.
Puin probabil n acest model este penalizarea din cauza folosirii limbajului de asamblare n
locul unui limbaj de nivel nalt (
6
x ): aproximativ 7 luni-om, indiferent de mrimea
proiectului, n mod similar, constanta negativ a0 i ceilali doi factori care au coeficieni
negativi au o probabilitate mic de apariie.
n general modelele liniare nu funcioneaz foarte bine. Dei exist un numr mare de
factori care influeneaz productivitatea, este puin probabil ca ei s intervin independent i
liniar.
42/135
Trebuie atras atenia asupra preciziei acestui tip de formul, n formula lui Nelson,
constantele sunt date cu precizia a 2 zecimale. Aplicnd aceast formul va rezulta o estimare
a efortului de genul 97,32 de luni-om. Va trebui totui s avem grij la capcana exprimat n
sloganul: exist trei tipuri de minciuni - minciuni mici, minciuni mari i statistici. Formula lui
Nelson este rezultatul analizei statistice a datelor unui proiect real i trebuie interpretat ca
atare, adic n termeni probabilistici. Dac avem o estimare E, atunci efortul real R va verifica
formula:
( ) ( ) ( )
1 1 P E R E + ,
unde valori acceptabile pentru i sunt: = 0,2 i = 0,9.
S presupunem c estimarea este de 100 luni-om. Semnificaia formulei este
urmtoarea: probabilitatea ca proiectul s necesite n realitate ntre 80 i 120 de luni-om este
mai mare ca 90%.
Costurile estimate prin acest tip de model rezult ntr-un anumit interval, rmnnd o
probabilitate diferit de zero ca acesta s fie n afara intervalului. Aplicabilitatea acestor
estimri este puternic influenat de mrimea intervalului i de probabilitatea ca valoarea real
a costului sa fie ntr-adevr n acel interval, n special pentru proiectele ce necesit efort mai
mare, este bine s se considere valoarea superioar a intervalului n care se afl costul n locul
valorii estimate.
O alt modalitate prin care un expert poate ajunge la o estimare a costului este printr-un
proces bottom-up. Pentru fiecare modul, va fi obinut un cost estimativ iar costul final va fi
suma costurilor modulelor, cu o corecie aplicat datorit integrrii modulelor.
Wolverton descrie un model n care o matrice a costurilor este folosit ca punct de
plecare n determinarea costurilor modulelor, n aceast matrice exist un numr limitat de
tipuri diferite de module i un numr de nivele de complexitate. Tabelul urmtor ilustreaz o
matrice ipotetic de costuri. Elementele matricei reflect costul pentru fiecare linie de cod.
Complexitate
Mic <-> Mare
Tipul modulului
1 2 3 4 5
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
k
S , va
rezulta un cost al modulului
k k ij
M S C = .
Acest tip de model are de asemenea probleme, n afar de dificultatea estimrii costului
de integrare a modulelor, utilizatorul trebuie s estimeze subiectiv clasa de complexitate din
care face parte fiecare modul, ceea ce determin un grad mare de nesiguran. Ali factori care
vor avea impact asupra productivitii, cum ar fi experiena n programare i caracteristicile
hardware, nu sunt luai n considerare. Extinderea matricei pentru a include i aceti factori ar
crete gradul de subiectivitate al metodei.
4.4 Modele algoritmice moderne
n paragrafele anterioare am remarcat faptul c efortul de programare este corelat cu
mrimea programului. Exist diferite modele (neliniare) care exprim aceast legtur. O
form general este:
( ) ( )
1
,...,
c
n
E a b KLOC f x x = + ,
43/135
unde KLOC reprezint mrimea programului n kilo-linii de cod, iar E reprezint efortul
n luni-om. a, b ic sunt constante iar ( )
1
,...,
n
f x x este o funcie care depinde de valorile
factorilor
1
,...,
n
x x . n general, formula de baz este:
c
E a b KLOC = + .
Ea este obinut printr-o analiz de regresiune a datelor proiectelor disponibile. Totui
primul generator de cost este mrimea programului, msurat n linii de cod. Acest cost
nominal estimat este apoi adaptat prin corectarea sa pentru un numr de factori care
influeneaz productivitatea (aa numiii generatori de cost). De exemplu, dac unul din
factorii folosii reprezint experiena echipei de programatori aceasta poate cauza o corecie
a costului nominal estimat cu 1.50, 1.20, 1.00, 0.80, 0.60 pentru un nivel de expertiz foarte
sczut, sczut, mediu, nalt i respectiv foarte nalt.
Tabelul urmtor conine unele formule de baz foarte cunoscute pentru relaia dintre
mrimea programului i efort. Din motivele enunate anterior este dificil s comparm aceste
modele. Este interesant de observat c valoarea lui c variaz n jurul valorii de l n toate
modelele.
Autor Formula
Halstead
1.50
0.7 E KLOC =
Boehm
1.05
2.4 E KLOC =
Walston-Felix
0.91
5.2 E KLOC =
Cnd c < l, se remarc apariia unui fenomen foarte bine cunoscut din teoria economic.
Pentru o producie de mas, se presupune c este mai ieftin s se produc mari cantiti din
acelai produs. Costurile fixe vor fi mprite astfel unui numr mai mare de uniti, ceea ce
conduce la scderea costului pe unitate. In cazul programelor, liniile de cod sunt produsul.
Dac presupunem c producnd multe linii de cod va scade costul pe linie de cod. Motivul
este costul instrumentelor scumpe precum generatoare de program, medii de dezvoltare i
instrumente de testare, care poate fi distribuit unui numr mai mare de linii de cod.
In cazul opus (c > 1), observm c dup un anumit punct, producerea de uniti
suplimentare implic costuri suplimentare. Putem afirma c programele foarte mari vor fi
mult mai scumpe. Suma necesar va fi mai mare deoarece crete necesitatea de comunicare i
de control managerial, deoarece problemele i interfeele devin mai complexe. Deci fiecare
linie de cod suplimentar necesit mai mult efort.
Nu exist nici un argument convingtor pentru nici un tip de relaie, dei ultima (c > 1)
pare mai plauzibil, n mod sigur, pentru proiecte foarte mari, efortul crete mai mult dect
liniar cu mrimea. Este evident c valoarea exponentului c influeneaz foarte mult valoarea
calculat E, n special pentru valori mari ale KLOC. Tabelul urmtor prezint valorile lui E,
calculate prin metodele prezentate anterior i pentru cteva valori ale KLOC. Se remarc
marea diferen dintre modele. Pentru programe mici, prin metoda Halstead rezult costuri
estimate mici. Pentru proiecte cu aproximativ un milion de linii de cod, acelai model
genereaz estimri ale costului cu un ordin de mrime mai mari dect prin aplicarea metodei
Walston-Felix.
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
Aceste observaii nu trebuie s ne conduc la concluzia c aceste metode sunt complet
inutile. Este mai probabil c exist diferene mari ntre caracteristicile seturilor de proiecte pe
44/135
care se bazeaz diferite modele. tim c numerele utilizate n modele provin din urma analizei
datelor proiectelor reale. Dac aceste date reflect diferite proiecte i/sau medii de dezvoltare,
modelele se vor comporta la fel. Nu putem copia pur i simplu aceste formule. Fiecare mediu
are caracteristicile sale proprii i este deci necesar adaptarea parametrilor la mediul specific
(proces numit calibrare).
Cea mai important problem a acestui model este obinerea unei estimri sigure a
mrimii programului de la nceput. Cum am putea s estimm numrul de pagini ale unui
roman care nu a fost scris nc? Chiar dac tim numrul de personaje, de locaii i intervalul
n care se va desfura povestea, este o iluzie ateptarea de la nceput unei estimri realiste a
mrimii. Cu ct naintm n realizarea proiectului, cu att va fi mai exact estimarea mrimii.
Dac proiectarea se apropie de final, ne putem forma o impresie rezonabil asupra mrimii
programului rezultat. Dar numai cnd sistemul va fi predat vom cunoate numrul exact.
Clientul ns solicit o estimare a preului de la nceput. In acest caz, numrul liniilor de
cod reprezint o msur prea inexact pentru a reprezenta o baz pentru estimarea costului.
De aceea trebuie cutat o alternativ, n paragrafele urmtoare, vom analiza cteva modele ce
se bazeaz pe mrimi cunoscute ntr-o etap iniial.
4.4.1 Modelul Walston-Felix
Ecuaia ce st la baza modelului Walston-Felix este:
0.91
5.2 E KLOC = . Acest model a
fost creat prin analiza a 60 de proiecte de la IBM. Aceste proiecte erau complet diferite ca
mrime, iar programele au fost scrise n mai multe limbaje de programare. Totui nu
reprezint o surpriz faptul c dac aplicm acest model chiar unei submulimi a celor 60 de
proiecte, nu vom avea rezultate satisfctoare.
ncercnd s explice aceste rezultate dintr-o plaj mare de valori, Walston i Felix au
identificat 29 de variabile care influeneaz n mod sigur productivitatea. Pentru fiecare din
aceste variabile au fost considerate trei nivele: mare, mediu i mic. Pentru un numr de 51 de
proiecte, Walston i Felix au determinat nivelul fiecrei variabile din cele 29, mpreun cu
productivitatea obinut (exprimat ca numrul liniilor de cod pe lun-om). Aceste rezultate
sunt prezentate n tabelul urmtor pentru cteva din cele mai importante variabile. De
exemplu, productivitatea medie este de 500 de linii de cod pe lun-om pentru proiecte cu o
interfa utilizator de complexitate sczut. Pentru o interfa de complexitate nalt sau
medie, productivitatea este de 295 i respectiv 124 de linii de cod pe lun. Ultima coloan
reprezint variaia productivitii, PC (engl. productivity change"), valoarea absolut a
diferenei dintre valorile minime i maxime.
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
Experien 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 poare fi determinat pentru noile
proiecte dup urmtoarea relaie:
45/135
29
1
i i
i
I W X
=
=

unde ponderile
i
W sunt definite astfel:
( )
10
0.5 log
i i
W PC = .
n relaia de mai sus,
i
PC reprezint variaia productivitii factorului I . Pentru primul
factor din tabelul de mai sus, complexitatea interfeei cu utilizatorul, rezult urmtoarele:
1
PC
= 376, deci
1
W = 1.29. Variabilele
i
X pot lua valorile 1 , 0 sau l, unde factorul
corespunztor este de nivel sczut, mediu sau nalt. Indexul productivitii obinut poate fi
tradus ntr-o productivitate ateptat (linii de cod scrise pe lun-om).
Trebuie menionat c numrul factorilor luai n considerare n acest model este destul
de ridicat (29 de factori din 51 de proiecte). De asemenea, nu este clar cum aceti factori se
influeneaz unul pe cellalt. Un alt dezavantaj ar fi c numrul de alternative pentru fiecare
factor este de numai 3, i nu ofer destule opiuni pentru situaiile practice.
4.4.2 Modelul COCOMO
COCOMO (COnstuctive COst MOdel) este unul din cei mai bine documentai
algoritmi de estimare a costului (Boehm, 1981). n forma sa cea mai simpl, numit Basic
COCOMO", formula care exprim legtura dintre efort i mrimea programului este:
c
E b KLOC = ,
unde b i c sunt constante ce depind de tipul proiectului ce este executat. Boehm
distinge trei clase de proiecte:
Organice: n proiectele de tip organic o echip relativ mic dezvolt programul
ntr-un mediu cunoscut. Persoanele implicate au n general experien n proiecte
similare realizate n organizaia lor. Astfel, ei pot s lucreze de la nceput,
nefiind necesare investiii iniiale. Proiectele de acest tip sunt de multe ori
programe relativ mici;
Integrate: Proiectele din acest tip implic sisteme unde mediul impune
constrngeri severe. Produsul va fi integrat ntr-un mediu care este foarte strict.
Exemplu de asemenea proiecte sunt programe de control al traficului aerian sau
aplicaiile militare;
Semidetaate: Aceasta este o form intermediar. Echipa poate fi format din
persoane experimentate i neexperimentate, proiectul poate fi destul de mare, dar
nu foarte mare.
Pentru clase diferite, parametrii metodei Basic COCOMO iau urmtoarele valori:
Clasa de proiect b c
organic 2.4 1.05
semidetaat 3.0 1.12
integrat 3.6 1.20
Tabelul urmtor prezint estimri ale efortului pentru fiecare din cele trei moduri,
pentru diferite valori ale KLOC (dei un proiect organic de un milion de linii de cod nu este
realist). Se observ influena foarte mare a constantei c asupra estimrilor obinute. Estimrile
efortului sunt exprimate tot n luni-om.
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
46/135
1000 3390 6872 14333
4.4.3 Modelul Putnam-Norden
Norden a studiat distribuia forei de munc n timp ntr-un numr de proiecte de
dezvoltare software n anii '60. A descoperit c aceast distribuie avea deseori o form
caracteristic. Aceast form caracteristic este bine aproximat de distribuia Rayleigh.
Bazndu-se pe aceast descoperire, Putnam a dezvoltat un model de estimare a costului n
care fora de munc necesar la un moment de timp t este dat de:
( )
2
2
at
FM t K a t e

=
unde a este un factor de accelerare care determin panta iniial a curbei, iar K
reprezint fora de munc total necesar, incluznd faza de ntreinere. K este egal cu
volumul zonei delimitate de curba Rayleigh, reprezentat n figura l.
Integrarea ecuaiei pentru ( ) FM t determin efortul cumulat I:
( )
( )
2
1
at
I t K e

=
1.414K a
0.858K a
0.386K a
1
2a
3
2a
t
2
P
a
n
t
a
i
n
i
t
i
a
l
a
K
a

Figura 1. Curba Rayleigh
Dac considerm momentul de timp T n care curba Rayleigh ajunge n punctul de
maxim, atunci
2
1
a
T
= . Acest moment T va fi apropiat de momentul de timp n care proiectul
va fi predat clientului. Aria delimitat de curba Rayleigh ntre punctele 0 i T va fi o bun
aproximare a efortului iniial de dezvoltare. Pentru acesta obinem:
( ) 0.3945 E I T K = =
Acest rezultat este foarte apropiat de o regul euristic foarte des utilizat: 40% din
efortul total este cheltuit pentru dezvoltarea efectiv, n timp ce 60% este cheltuit pentru
ntreinere. Specificarea cerinelor nu este inclus n model. Estimrile conform acestui model
nu se pot aplica dect ncepnd cu proiectarea i implementarea.
4.5 Distribuirea forei de munc n timp
Mai muli cercettori au criticat folosirea curbei Rayleigh pentru estimarea costului
(Pillai, 1997). Modelul lui Norden nu se bazeaz pe o teorie, ci mai mult pe observaii. Mai
mult, datele sale se refer mai mult la proiecte hardware. Nu s-a demonstrat ns faptul c
47/135
proiectele software se comport la fel. Acestea prezint uneori o acumulare rapid a forei de
munc care invalideaz modelul n fazele incipiente ale proiectului.
Putnam a folosit observaii empirice legate de nivelele de productivitate pentru a deriva
ecuaia software-ului din curba Rayleigh:
1 4
3 3
D kE t =
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.
Puterea supraunitar a timpului are implicaii puternice asupra alocrii resurselor n
proiecte mari. Prelungiri relativ mici ale datei de livrare pot determina reducerea substanial
a efortului (Pressman, 1997).
Pentru estimarea efortului, Putnam a introdus ecuaia acumulrii forei de munc:
3
E
A
t
=
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:
( )
9
4
7
7 D
E A
k
= .
Acest rezultat este interesant deoarece arat c efortul este proporional cu dimensiunea
la puterea 9/ 7 1.286 , valoare similar cu factorul lui Boehm, ntre 1,05 i 1,20.
Evident, 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.
Exist i dezavantaje ale acestei deplasri. Mai multe studii au artat c productivitatea
individual scade odat cu creterea echipei. Conform lui Brooks, exist dou cauze ale
acestui fenomen:
Dac o echip se mrete, va crete timpul acordat comunicrii cu ceilali
membri ai echipei (pentru consultare, sincronizarea sarcinilor etc.);
Dac este adugat for de munc suplimentar unei echipe n timpul
dezvoltrii unui proiect, mai nti scade productivitatea. 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. Luate mpreun,
acestea conduc la scderea productivitii totale.
Combinnd aceste dou informaii, ajungem la fenomenul cunoscut sub denumirea de
legea lui Brooks: adugarea de personal la un proiect ntrziat l va ntrzia i mai mult.
Analiznd o mare baz de date ale proiectelor, Conte a descoperit urmtoarea relaie
ntre productivitatea medie L (msurat n linii de cod pe lun-om) i mrimea medie a unei
echipe P:
0.5
777 L P

= .
48/135
Formula atest faptul c productivitatea individual scade exponenial cu mrimea
echipei. Numrul de legturi de comunicare ntre persoanele implicate ntr-un proiect este
determinat de mrimea i structura echipei. Dac ntr-o echip de mrime P fiecare membru
trebuie s-i coordoneze activitile sale cu toi ceilali din echip, numrul legturilor de
comunicaie va fi:
( ) 1
2
P P
. Dac fiecare membru trebuie s comunice numai cu un singur
alt membru, acest numr va fi: P-1. Mai puin comunicare dect aceasta nu este rezonabil,
deoarece ne-am confrunta cu echipe independente. Numrul de legturi de comunicaie
variaz de la aproximativ P la aproximativ
2
2
P
. ntr-o organizare ierarhic, aceasta conduce
la P

ci de comunicaie, cu 1 2 < < .

Pentru un membru al echipei, numrul de legturi de comunicaie variaz de la l la P -1.
Dac productivitatea individual maxim este L i fiecare legtur de comunicaie conduce la
o pierdere a productivitii /, atunci productivitatea medie va fi:
( ) 1 L L l P

= ,
unde ( ]
0,1 este o msur a numrului de legturi de comunicaie. Presupunem c
exist cel puin o persoan care s comunice cu mai mult de o persoan, deci 0 > . Pentru o
echip de mrime P, aceasta conduce la o productivitate total:
( )
( )
1
tot
L PL P L l P

= = .
Pentru o mulime dat de valori pentru L, l i , pentru valori cresctoare ale lui P,
aceast funcie crete de la 0 la o valoare maxim i apoi scade din nou. Deci exist o mrime
optim a echipei
opt
P , care conduce la o productivitate maxim a echipei. Productivitatea
echipei pentru diferite valori ale lui P este data n tabelul de mai jos. Aici, presupunem c
productivitatea individual este de ( ) 500 / 500 LOC lun om L + = , iar scderea de
productivitate este de 10% pe canal de comunicaie (l = 50). Cu interaciune complet ntre
membrii echipei ( = 1), rezult o echip optim de 5.5 persoane:
Mrimea echipei Productivitatea individual Productivitatea 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 150 1200
4.6 Concluzii
n acest curs au fost prezentate diferite modele pentru estimarea efortului necesar pentru
dezvoltarea unui proiect software, a forei de munc necesare i a timpului efectiv de
dezvoltare. S-au descris i factorii care nu trebuie s contribuie la estimarea costului
proiectului. In final, s-a prezentat o modalitate de estimare a distribuiei forei de munc n
timp pentru gsirea optimului numrului de persoane implicate n proiect.
49/135
5 Reutilizarea resurselor software
ntre timp, Dedal, stul de Creta i de lunga sa absen de acas, simea un dor nebun
de ara sa, dar era blocat de mare. Apoi el spuse: Regele mi poate nchide calea pe uscat i
pe mare, dar, desigur, cerul este liber i noi pe acolo vom merge. Poate c Minos deine restul,
dar aerul nu i aparine ". Spunnd aceste cuvinte, Dedal i-a ndreptat atenia spre tiine nc
neexplorate i a sfidat legile naturii. A aezat un rnd de pene, ncepnd cu cele mai mici, apoi
crescndu-le dimensiunea, astfel nct marginea prea c se nclin n sus. In acelai fel naiul
cu care cnt ciobanii este construit din trestie, fiecare puin mai lung dect cealalt. Apoi, a
fixat penele la mijloc cu a, iar la baz cu cear; dup ce le-a aranjat n acest fel, le-a ndoit
puin, dndu-le o form uor curb, aa cum arat aripile psrilor.
Publius Ovidius Naso: Metamorfoze, VIII, 183-194
5.1 Introducere
Dedal merit un loc n mitologia ingineriei programrii. Pe vremea regelui Minos,
software-ul nu exista i totui existau problemele i noiunile pe care le regsim n ingineria
programrii de astzi. Un exemplu l constituie construirea sistemelor complexe. Dedal deine
cu siguran un record n acest domeniu. A reuit s administreze un proiect care poate fi
comparat cu proiectele de dezvoltare software din ziua de astzi: construirea labirintului din
Knossos.
Dup o vreme, Dedal a dorit s prseasc insula Creta, aa cum Ovidius povestete mai
sus. Totui regele Minos nu a vrut s i dea drumul. tim cum se termin povestea: Dedal
zboar din Creta mpreun cu fiul su, Icar. n ciuda avertismentelor tatlui su, Icar zboar
din ce n ce mai sus, se aproprie prea mult de soare i ceara din aripi se topete. Icar cade n
mare i se neac iar Dedal reuete n schimb s ajung cu bine n Sicilia.
Construcia lui Dedal este interesant din punctul de vedere al reutilizrii resurselor.
Faptul c acest lucru intereseaz mai mult partea de hardware dect pe cea de software nu
prezint importan aici. Ceea ce intereseaz n discuia de fa este aplicarea anumitor
principii n construcie:
reutilizarea resurselor: Dedal a folosit pene adevrate;
reutilizarea proiectrii: el a imitat aripi reale;
interfaarea componentelor: n acea vreme, oamenii foloseau ceara pentru a lipi
diverse lucruri ntre ele; calitatea lipiciului are un impact enorm asupra triniciei
produsului final. n urma aplicrii corecte i ferme a acestor principii, a fost
realizat cu succes un proiect ambiios (zborul lui Dedal pn n Italia),
ncercarea de a cuceri cerul cu o tehnologie insuficient s-a terminat cu un
dezastru (prbuirea lui Icar n mare).
S facem acum un salt n istorie, la sfritul anilor '70. Criza software era deja acut de
muli ani. Cererea de noi aplicaii depea cu mult posibilitile forei de munc din domeniu.
Diferena dintre cerere i ofert era n continuare n cretere. Reutilizarea soft-ului este una
din cile explorate pentru a obine o cretere semnificativ n productivitatea software.
De ce s se scrie cod pentru nite calcule deja cunoscute? Reutilizarea componentelor
software de calitate nu duce oare la creterea drastic a siguranei i productivitii? Totui, nu
este chiar att de simplu. Utilizarea componentelor software existente necesit standardizarea
denumirilor i interfeelor. Ideea de a lipi componente ntre ele nu este direct transferabil n
domeniul programrii.
Punctul de vedere modern nu restricioneaz noiunea de reutilizare a soft-ului la
reutilizarea componentelor. i informaiile care privesc proiectarea pot fi reutilizate, aa cum
pot fi reutilizate i alte cunotine culese n timpul construciei unui proiect software.
50/135
Foarte apropiat de reutilizarea software este i flexibilitatea programelor, care trebuie
s fie n continu adaptare la modificrile circumstanelor, n implementarea urmtoarei
versiuni a unui sistem, am prefera, evident, s folosim ct mai mult din versiunea curent.
Aceasta este de asemenea considerat a fi o form de reutilizare a soft-ului.
5.2 Reutilizarea produselor intermediare
Bibliotecile cu buci de cod gata de utilizat, aa cum sunt cele numerice sau calculele
statistice, sunt folosite de ceva timp i pe o arie destul de larg. Aceast form de reutilizare
nu este n mod necesar potrivit altor domenii. n alte domenii ne putem descurca mai bine
refolosind schelete de componente, componente ale cror detalii nu au fost nc definite, ntr-
un mediu n care acelai tip de software este implementat mereu, aceste schelete pot fi
modelate ntr-o proiectare reutilizabil. O tehnic similar este aceea de a reutiliza arhitectura
unui sistem software, aa cum este ntlnit la construcia compilatoarelor, de exemplu. Prin
integrarea cunotinelor despre domeniu n accesorii software, ajungem n domeniul
sistemelor de transformri, al generatoarelor de aplicaii i al limbajelor de generaia a patra.
O clasificare general a tehnologiilor de reutilizare presupune:
tehnologii bazate pe compunere;
tehnologii bazate pe generare.
ntr-o tehnologie bazat pe compunere, reutilizarea se face parial prin compunerea unui
nou sistem din componentele existente. Elementele cu care se construiete (engl. building
blocks") sunt fragmente pasive ce sunt copiate dintr-o baz de componente existent. ntr-o
tehnologie bazat pe generare, este mult mai dificil identificarea componentelor reutilizate.
Mai precis, cunotinele reutilizate se regsesc ntr-un program care genereaz un alt program,
ntr-o tehnologie bazat pe generare, tiparele reutilizabile reprezint un element activ folosit
pentru a genera sistemul int. Exemple mai vechi ale acestor dou tehnologii sunt bibliotecile
de subrutine i, respectiv, generatoarele de aplicaii. Cele mai multe sisteme reutilizate dein
aspecte din ambele perspective.
5.2.1 Biblioteci i componente software
Dac avem de realizat un program care trebuie s fac apel la funcii trigonometrice, n
mod normal nu ne gndim s ne construim propriile rutine de calcul al acestor funcii, n
general, acestea sunt deja implementate n majoritatea limbajelor de programare. Ne-am pune
problema reimplementrii lor doar n cazuri particulare, cnd performanele programului
depind n mod direct de precizia sau viteza calculelor.
Punnd ntrebarea de ce este aa de simpl reutilizarea funciilor matematice, ajungem
s gsim un numr mare de piedici ce sunt puse n faa reutilizrii componentelor software n
alte domenii. Pentru reutilizarea cu uurin a unor funcii, trebuie s avem:
un domeniu bine cunoscut, cu o terminologie standardizat; cosinus" (sau
cos") reprezint acelai lucru pentru toat lumea;
o interfa bine precizat: avem nevoie de exact un numr pentru a calcula
funcia cosinus;
un format de date standardizat: un numr poate fi reprezentat n virgul fix, n
virgul mobil, n dubl precizie, i cam att.
Reutilizarea rutinelor funcioneaz cel mai bine ntr-un domeniu de aplicaii bine
documentat, cu noiuni clare i pentru care datele de intrare sunt ntr-un format standardizat.
Istoria modern a reutilizrii software ncepe cu Mellroy, care a prevzut un viitor strlucit
pentru o tehnologie a unei componente software la Conferina NATO de Ingineria
programrii din 1968. Din punctul su de vedere, ar trebui s fie posibil asamblarea
sistemelor i componentelor mari dintr-un numr de blocuri gata de utilizat, aa cum sistemele
hardware sunt asamblate folosind componente standard.
51/135
Pentru ca reutilizarea componentelor software s fie realizabil, trebuie mai nti s
rezolvm urmtoarele probleme:
Cutarea: Trebuie s cutm componenta potrivit ntr-o baz de date de
componente disponibile. Acest lucru este posibil numai dac avem metode
disponibile potrivite pentru descrierea componentelor. Dac nu tii s specifici
ceea ce caui, exist o ans mic s gseti acel lucru;
nelegerea: Pentru a decide dac o anume component este utilizabil, este
nevoie de o nelegere precis i suficient de complet a ceea ce face respectiva
component;
Adaptarea: Componenta selectat poate s nu se potriveasc fix problemei. A
crpi codul nu reprezint o variant satisfctoare i, n orice caz, justificat
numai atunci cnd este profund neleas;
Compunerea: Un sistem este format din mai multe componente cuplate. Se
pune problema: cum conectm componentele ntre ele?
Componentele hardware sunt de obicei clasificate ntr-o ierarhie multinivel. Avnd n
vedere c s-au standardizat deja conveniile de nume, se poate trece n revist ierarhia. La cel
mai de jos nivel sunt date descrieri alternative ale componentelor, ca de exemplu: descrierea
limbajului, schema logic i informaii de sincronizare, care descriu diferite aspecte ale
componentelor.
S-au fcut unele eforturi pentru a clasifica componentele software dup principii
ierarhice, n taxonomia lui Booch (1987), o component este descris mai nti de nivelul de
abstractizare pe care l implementeaz. O parte din taxonomia sa este prezentat n tabelul
urmtor, n al doilea rnd, componentele sunt descrise de comportamentul lor n spaiu i
timp.
monolitice iruri de caractere, stive, cozi
structuri
polilitice Liste, arbori, grafuri
instrumente utiliti filtre
n ceea ce privete ultimele dimensiuni, Booch deosebete patru categorii:
Concuren: obiectele i pot pstra sau nu semantica proprie atunci cnd exist
mai multe fire de control;
Spaiu: obiectele sunt sau nu sunt statice ca dimensiune;
Manager de memorie: obiectele pot sau nu administra singure memoria;
Iterator: componentele pot sau nu pot pune la dispoziie operaii care s permit
acces la obiectele cuprinse de component.
Tabelul urmtor descrie o alt taxonomie a unor bine cunoscute structuri de date. Pentru
a crea aceast taxonomic au fost utilizate relaiile structurale dintre elementele unor structuri
de date compuse. De exemplu, exist o relaie 1-1 ntre elementele unei structuri lineare, ca
lista sau coada.
0-0 mulimi
1-1 Stive,cozi, liste
1-n Arbori
structuri
n-m grafuri
Acest fenomen funcioneaz pentru ierarhii de componente n general. Dac nu se
cunoate modul n care este organizat ierarhia, exist doar o mic ans s se gseasc
componenta cutat. Exemplele din tabelele de mai sus induc oarecum n eroare, deoarece
componentele de pe nodurile frunz ale ierarhiei ncorporeaz abstractizri foarte cunoscute,
n alte domenii va fi mai puin nelegere reciproc n ceea ce privete componentele
primitive i denumirea acestora. Prin urmare, construirea unei taxonomii utilizabile este de
obicei mai greu de realizat n alte domenii.
52/135
O alt observaie care se poate face privind reutilizarea componentelor privete
granularitatea lor. Cu ct este mai mare o component, cu att va fi mai bun rezultatul
reutilizrii ei. Pe de alt parte, componentele mari tind s devin mai greu de reutilizat, avnd
n vedere c gradul de reutilizare a unei componente scade o dat cu creterea mrimii
componentei. Acest lucru este datorat faptului c, n general, componentele mai mari tind s
impun constrngeri mai multe mediului lor. Exist aici o analogie cu teorema fundamental a
biologiei a lui Fisher: cu ct un organism este mai adaptat unui mediu dat, cu att este mai
puin pregtit pentru un alt mediu.
n domeniul clasificrii componentelor, o contribuie semnificativ aparine lui Prieto-
Diaz. O bibliotec de componente bazate pe schema clasificrii sale ajut la localizarea
componentelor potenialelor utilizabile i la estimarea efortului necesar pentru a adapta o
component, atunci cnd aceasta a fost gsit.
Schema clasificrii lui Prieto-Diaz folosete un numr de caracteristici, numite faete,
care descriu fiecare component. De exemplu, componentele ntr-un mediu UNIX pot fi
clasificate funcie de aciunea pe care o ncorporeaz, de obiectul pe care l manipuleaz sau
de structura de date folosit. Clasificarea unui obiect nseamn alegerea unei n-tuple care se
potrivete cel mai bine acelei componente.
Clasificarea bazat pe faete are anumite avantaje fa de clasificarea bazat pe
enumerare, aa cum este utilizat n exemplele din taxonomia lui Booch. Schemele strict
enumerative folosesc o ierarhie predefinit i oblig la cutarea unui nod care se potrivete cel
mai bine componentei ce trebuie clasificat. Dei pot fi folosite i referine ncruciate cu alte
noduri, reeaua rezultat devine destul de complicat.
De obicei este greu de gsit o component care s se potriveasc perfect cerinelor
noastre. Dar asta nu nseamn c nu se poate gsi o component utilizabil. Sistemul lui
Prieto-Diaz ofer posibilitatea de a expanda ntrebrile deoarece ia n considerare i
componentele care sunt apropiate de cea cutat, pentru oricare din faete. Pentru a determina
apropierea de o component, se fac msurri potrivite ale distanei dintre noiunile care
compun faetele.
O dat ce s-a gsit o mulime de componente candidate, acestea sunt ordonate de ctre
un sistem de evaluare dup criteriul considerat al potrivirii lor. n afar de distana
conceptual, proprieti ca lungimea (o estimare subiectiv), structura (numrul de module,
complexitatea) i documentarea (o estimare subiectiv) joac un rol n procesul de selecie.
Un proiect de cercetare construit pe baza rezultatelor obinute de Prieto-Diaz este
descris de Burton (1987). El i asociaii si au implementat un prototip de bibliotec de
software reutilizabil. n sistemul lor, descrierea fiecrei componente software este
reprezentat de un numr de atribute, cum ar fi lungimea componentei, complexitatea sa,
rezultatele testrii, erorile raportate, calitatea documentaiei i readaptabilitatea. Dac trebuie
aleas una dintre componente, reutilizatorul poate indica interactiv relevana fiecrui atribut.
Este obinut apoi o ordine a importanei, bazat pe indicaiile utilizatorului. Variind valorile
diferitelor atribute, reutilizatorul poate avea o vedere de ansamblu a valorii relative a
componentelor eligibile.
Perspectiva lui Prieto-Diaz a fost aplicat cu succes i n alte programe de reutilizare.
Aceste proiecte difer considerabil n ceea ce privete schemele lor de clasificare i de
recuperare i cantitatea de instrumente ajuttoare puse la dispoziie de mediu. Schemele de
clasificare variaz de la un simplu cuvnt cheie ntr-un context pn la recuperarea complet
automat a unui cuvnt cheie din documentaia existent; pot fi de asemenea implicate pn i
cunotine elaborate din domeniul aplicaiei, n ceea ce privete recuperarea, sistemele pot
ntrebuina tezaure extensibile pentru a lega termeni similari, sau pot oferi posibiliti de
navigare pentru a inspecta componente similare.
53/135
Experienele concrete arat ns c, din punct de vedere practic, bibliotecile de
componente utile nu conin un numr mare de componente. De exemplu, Prieto i Diaz
raporteaz n 1991 c numrul de articole ale bibliotecii din laboratoarele GTE a ajuns de la
190 n 1988 la 128 n 1990. Din aceast cauz, clasificarea i recuperarea componentelor nu
este, de cele mai multe ori, principalul impediment n calea unui program reutilizat de succes.
Adevrata problem este completarea bibliotecii cu componentele corecte.
5.2.2 abloane
n paragrafele precedente am presupus c bibliotecile de componente sunt buci de cod
gata de folosit. Aplicabilitatea unei componente poate fi mrit prin omiterea specificrii
anumitor detalii. abloanele sunt componente neterminate. Prin instanierea lor, de exemplu
prin completarea unor detalii, rezult componente (re)utilizabile.
Un exemplu de posibil ablon este o procedur care implementeaz un algoritm de
sortare. Detalii ca limitele mulimii de sortat, tipul elementelor mulimii i operatorii
relaionali folosii pentru a compara elementele mulimii nu prezint importan pentru esena
algoritmului.
Aceasta se reduce n ultim instan la separarea dintre funcionalitate i tipurile de date
folosite n implementare. Poteniala reutilizare este puternic mrit dac biblioteca conine, pe
lng tipuri abstracte de date, i abloane.
Cu ct sunt acceptate mai multe detalii, cu att se poate aplica un ablon mai general.
Totui exist un pre pentru toate acestea. Costul pltit pentru a obine o aplicaie complet
probabil va crete proporional cu numrul de goluri ce trebuie umplute.
abloanele nu trebuie constrnse numai la subrutine. Exist abloane care pot fi
instaniate ntr-un program complet pentru un domeniu de aplicaie foarte precis, n acest caz,
avem de-a face cu generatoare de aplicaii.
5.2.3 Reutilizarea proiectrii
Reutilizarea proiectrii se dovedete profitabil ntr-un mediu n care este dezvoltat
mereu i mereu acelai tip de program. n multe medii de afaceri aplicaiile sunt considerate n
mod greit unice. Drept urmare, ele sunt proiectate i implementate pornind de la zero de
fiecare dat. Lanergan i Grasso (1984) declarau c n programele comerciale scrise n
COBOL exist numai cteva operaii de baz diferite, cum ar fi sortarea, actualizarea i
raportarea.
Reutilizarea arhitecturii, adic modalitatea n care diverse pri a unui sistem se mbin,
este oarecum diferit de reutilizarea componentelor software sau a abloanelor. O bibliotec
de arhitecturi software nu este chiar aa de util. Pentru fiecare problem n parte am putea
mai degrab s cutm o arhitectur specific. O arhitectur nepotrivit nu poate fi niciodat
baza unui sistem bun. Situaia se modific oarecum dac o problem apare n mod repetat n
diferite variante. Dac exist o arhitectur standard util pentru un anumit tip de problem,
aceasta poate fi aplicat tuturor variantelor viitoare.
Un prim domeniu din tiina calculatoarelor n care se poate reutiliza arhitectura
software este construcia compilatoarelor. Marea majoritate a compilatoarelor sunt construite
cu aceleai componente: parser, analizor lexical, analizor sintactic, tabel de simboluri,
generator de cod. Exist cteva tipuri bine definite de parsere, cum ar fi parserele LL(1) sau
LALR(l). Exist o teorie ampl despre cum funcioneaz compilatoarele, n acest mod a
evoluat o arhitectur de compilatoare standard general acceptat. Evident, nu s-a demonstrat
niciodat c aceasta este singura cale, sau cea mai bun cale pentru a construi compilatoare.
Dar este o metod fr cusur i bine cunoscut de a ataca probleme ntr-un domeniu dificil.
54/135
Un alt exemplu este domeniul mediilor de dezvoltare software, n care majoritatea
ntrebuineaz un depozit de informaii centrale nconjurat de un numr mic de straturi ce
conine instrumente ce devin din ce n ce mai specifice ctre straturile exterioare.
Reutilizarea arhitecturii se regsete rareori i n alte domenii. Principalul motiv este c
un corp similar de cunotine partajate i cristalizate pur i simplu nu exist. Putem totui
observa cum cteva tipuri de arhitecturi standard au fost implementate n alte discipline de
inginerie. De exemplu, Spector (1986) descrie procedurile utilizate n construirea podurilor de
autostrad din punctul de vedere al ingineriei programrii. Standish (1984) observ c n
fiecare disciplin de inginerie trebuie depus o munc enorm i ctigat mult experien
nainte de a realiza o astfel de standardizare.
5.2.4 Sisteme de transformare
Am menionat deja natura transformaional a procesului de implementare software. O
specificaie a cerinelor descrie sistemul ce trebuie realizat ntr-o anume reprezentare, fie c e
vorba de limbaj natural, limbaj formal sau pictural, n urma unor stadii intermediare, aceast
descriere este transformat ntr-un produs final, codificat ntr-un limbaj de programare
oarecare.
Dou tipuri de transformri se repet n timpul acestui proces:
rafinri: prin adugarea detaliilor i deciziilor de implementare se rafineaz
descrierea produsului.
transformri lingvistice: n timpul anumitor pai, descrierea produsului este
translatat dintr-un limbaj n altul.
Evident, ambele tipuri de transformri pot fi fcute manual, ceea ce deseori se i
ntmpl. Putem lua totui n considerare posibilitatea asistenei computerizate n realizarea
acestor transformri, adic, mai precis, un sistem automat care s fac transformri.
Cel mai simplu punct de pornire ne este pus la dispoziie de transformrile lingvistice
ale clasei. O construcie de forma:
If Exists i in 1..N SuchThat A[i] = x then ...
este foarte clar. Din pcate, aceast construcie nu exist n majoritatea limbajelor de
nivel nalt folosite n prezent. Prin urmare, la un moment dat, construcia IfExists va trebui
nlocuit cu o secven de cod echivalent semantic.
Un sistem de transformare pentru un domeniu de aplicaie larg va necesita n general
ndrumare uman pentru realizarea rafinrii. De exemplu, dac o descriere de nivel nalt
amintete de mulimi de obiecte, aceasta se poate rafina printr-o reprezentare folosind liste sau
arbori binari, n general, programatorul este cel care va decide ce structuri de date se potrivesc
cel mai bine aplicaiei, dac sistemului de transformare i lipsesc cunotinele pentru a realiza
automat acest lucru.
Cea mai dificil sarcin a unui utilizator de sistem de transformare este identificarea
unor nivele intermediare consistente, bine definite care trebuie folosite n procesul de
transformare. Dac reuim s descompunem acest proces n nite pai bine separai din punct
de vedere conceptual, atunci transformrile devin realizabile.
O ntrebare interesant este dac putem formaliza toate construciile i construi un
compilator inteligent care s translateze o proiectare n cod executabil fr intervenie uman.
Acest lucru este ntr-adevr posibil dac restricionm domeniul de aplicaie la unul foarte
ngust. Pentru a putea rescrie din toate punctele de vedere o proiectare, trebuie s se introduc
n sistem, ntr-un fel sau altul, o cantitate suficient de cunotine n domeniul aplicaiei.
Astfel de sisteme sunt generatoarele de aplicaii.
55/135
5.2.5 Generatoare de aplicaii i limbaje de a patra generaie
Generatoarele de aplicaie scriu programe. Un generator de aplicaie are un volum de
cunotine despre domeniul aplicaiei, care este de obicei destul de ngust. Pentru a obine un
program este nevoie, evident, de o specificaie a acestuia. De ndat ce specificaia este
disponibil, programul este generat automat.
Principul folosit este acelai pe care se bazeaz un ablon: programul efectiv de generat
este deja construit n generatorul de aplicaii. Instanierea unui program efectiv este realizat
prin completarea unui numr de detalii. Diferena fa de ablon este aceea c mrimea
codului livrat este mult mai mare la un generator de aplicaii. De asemenea, detaliile sunt n
general furnizate la un nivel mai nalt de abstractizare, n ceea ce privete conceptele i
noiunile extrase din domeniul de aplicaie.
Un generator de aplicaii poate fi ntrebuinat n orice domeniu care are o astfel de
structur nct operaiile complicate din cadrul domeniului s poat fi automatizate n mare
msur. Un exemplu l reprezint generarea automat a rapoartelor din baze de date. Aa
numitele compilatoare de compilatoare reprezint un alt exemplu tipic de generator de
aplicaii: avnd gramatica unui limbaj de programare (adic detaliile), rezult un parser pentru
acel limbaj.
Limbajele de a patra generaie sau limbajele de nivel foarte nalt (engl. VHLL, very
high level languages") sunt deseori menionate alturi de generatoarele de aplicaii. Limbajele
de a patra generaie ofer construcii de programare la un nivel mai nalt dect limbajele de
programare de a treia generaie.
Expresiile dintr-un domeniu de aplicaie dat pot fi introduse direct n limbajul de a patra
generaie corespunztor. Prin urmare, limbajul de a patra generaie trebuie s aib cunotine
despre domeniul de aplicaie respectiv. Aceasta nseamn c i limbajele de a patra generaie
sunt potrivite numai pentru un domeniu specific, limitat.
Nu exist nici o diferen fundamental ntre limbajele de a patra generaie i
generatoarele de aplicaie. Atunci cnd se dorete testarea capacitilor generative ale unui
sistem, se folosete de obicei generatorul de aplicaii. Termenul limbaj de a patra generaie"
evideniaz construciile de programare de nivel nalt ce sunt oferite.
Generatoarele de aplicaii i limbajele de a patra generaie ofer nite reduceri poteniale
de cost, avnd n vedere c detaliile de implementare nu trebuie s in cont de probleme ca:
nivelul de inteligibilitate al codului s fie mare, cantitatea de cod scris s fie mic, numrul de
erori s fie mic, codul s fie uor de ntreinut.
n practic, utilizatorul poate dori ceva ce nu este oferit de sistem, n acest caz, o bucat
de cod scris la mn" trebuie adugat programului generat automat. Fcnd acest lucru se
pierde unul din marile avantaje ale folosirii limbajelor de a patra generaie, i anume scrierea
de programe inteligibile la un nivel mai ridicat de abstractizare.
5.3 Reutilizarea instrumentelor i a tehnicilor
n acest paragraf vom descrie un numr de concepte, metode i tehnici care pot avea un
impact pozitiv asupra reutilizrii software, rediscutnd perspectivele din seciunile precedente.
5.3.1 Limbaje de interconectare a modulelor
Relaia dintre diferitele module ale unui sistem pot fi exprimate formal ntr-un Limbaj
de Interconectare a Modulelor (engl. MIL, module interconnection language"). MIL
reprezint un instrument important atunci cnd se proiecteaz i se ntrein sisteme mari,
constituite din diverse module. O descriere MIL este o descriere formal a structurii formale a
unui sistem software, care poate fi utilizat pentru a verifica automat integritatea sistemului i
pentru a verifica dac diversele module sunt conforme cu interfeele aprobate.
56/135
Vom prezenta n continuare un mic fragment dintr-un cod MIL pentru a ilustra aspectul
general a unui astfel de limbaj. Exemplul privete structura unui compilator cu un singur pas.
Notaia folosit este INTERCOL (Tichy, 1979), n care descrierea const dintr-o secven de
module i de familii de sisteme urmate de un set de compoziii. Exemplul conine o singur
familie de sisteme. Un membru al acestei familii reprezint o versiune a unui sistem. De notat
c familia de module scan are implementri multiple, cte una pentru fiecare limbaj suportat.
Compoziia dat la sfritul descrierii selecteaz un numr de blocuri definite anterior.

system compile
provide compile

module compiler
provide procedure compiler
require scanner, parser, postfix_generator, symtbl_funct
end compiler

module scan
provide package scanner is
type token: ALPHA
function nextchar_funct return: CHARACTER
procedure backup_proc
end scanner
require symtbl_proc, errormsg_proc
implementation SCAN02 .. PL/I
implementation SCAN03 .. PASCAL
end scan

module errormsg
provide procedura errormsg_proc
implementation ERRMSG
end errormsg

COMPOSITION
compile_A =[compile, SCAN02, PARSE.NIP, SYMBL.PL/I,
POSTFIXGEN.NIP, SYSLBL, VRFY, ERRORMSG]
end compile

Ideile de baz din spatele implementrii MIL sunt:
Un limbaj separat pentru proiectarea de sisteme: MIL nu reprezint un limbaj de
programare. El doar descrie proprietile dorite ale modulelor care vor deveni
parte component a sistemului considerat;
Verificri ale tipurilor statice ntre diferite module: Acest lucru garanteaz
automat c diferitele module respect interfaa. O interfa poate fi modificat
numai dup ce a fost realizat respectiva modificare n proiectare;
Proiectarea i legarea modulelor ntr-o singur descriere: In vremurile de nceput
ale programrii sistemelor complexe, diversele module erau asamblate la mn.
Folosind MIL, acest lucru se poate face automat;
Controlul versiunilor: Pentru a evita confuziile dintre versiunile (prilor) unui
sistem n timpul implementrii i ntreinerii, este nevoie de o abordare
organizat.
57/135
Conceptele de baz ale unui MIL sunt:
resursele: tot ce are nume ntr-un limbaj de programare (constant, tip, variabil,
procedur) i tot ce poate fi fcut disponibil de ctre un modul pentru un alt
modul;
modulele: care fac resursele disponibile sau care le utilizeaz;
sistemele: grupuri de module care ndeplinesc mpreun o sarcin bine definit.
Pentru lumea exterioar, un sistem poate fi vzut ca un singur modul.
Legtura dintre module poate fi modelat ca un graf: nodurile grafului reprezint
module, n timp ce arcele (orientate) reprezint dependenele dintre module. Funcie de gradul
de complexitate al MIL, acest graf poate fi un arbore, un graf orientat aciclic sau un graf
orientat fr nici o restricie.
Toate MIL arat aceleai limitri: ele se implic numai n sintaxa interfeelor. Nu se
poate aprecia dac resursele prelucrate au sens sau nu. Goguen (1986) a ncercat s fac un
pas mai departe pentru a asigura unui MIL o semantic limitat. Sistemul lui se numete
Limbaj de Interconectare a Bibliotecilor (engl. LIL, library interconnection language"). LIL
conine urmtoarele entiti:
pachete cu axiome asociate: aceste axiome spun ceva legat de operaia
pachetului. Axiomele pot fi formale (ntr-o logic primar) i informale (limbaje
naturale);
teorii: seamn cu pachetele, dar nu conin deloc cod. Acestea arat numai c ar
trebui furnizate anumite tipuri i funcii i pun la dispoziie axiomele care
descriu comportarea acestor funcii;
vizualizrile: arat cum este ndeplinit o anumit teorie.
Un exemplu ar putea clarifica aceast descriere. Fie SORT un pachet generic pentru
sortarea unei secvene, nc nu am specificat tipul elementelor din secven. Teoria
ORDEREDSET ne spune ce este aceea o ordonare, folosind urmtoarele axiome:

1 2
E E (reflexivitate);

1 2 2 3 1 3
, E E E E E E (tranzitivitate);

1 2 2 1 1 2
, E E E E E E = (antisimetrie);

1 2
E E sau
2 1
E E (ordine complet).
Mulimea numerelor naturale cu relaia de ordine >" satisface aceste axiome. Dar
exist multe alte ordonri posibile (cum ar fi: toate numerele pare care sunt mai mari dect
toate numele impare i att numerele pare ct i cele impare s fie n ordinea fireasc). Dac
dorim s sortm o secven n ordine descresctoare, alegem o vizualizare care are ca
elemente ale ORDEREDSET numerele naturale i relaia >" ca relaie de ordine.
Construcia de mai sus a fost numit de ctre Goguen compoziie orizontal.
Vizualizarea descrie o interfa ntre dou componente aflate la acelai nivel de abstractizare.
O component caut o teorie, cealalt satisface axiomele, pe cnd vizualizarea ne transmite
cum se potrivesc ele. Este de asemenea posibil i o compoziie vertical, n pachetul SORT
nu a fost nc definit modalitatea n care trebuie implementat o secven. De aceea, SORT
trebuie s fie conectat la o component cu un nivel mai cobort de abstractizare care
implementeaz o secven.
Este evident c axiomele care nu sunt exprimate ntr-o notaie formal nu pot fi
verificate automat. De aceea, Goguen propune un adevrat sistem de management, care ar
trebui s poat verifica axiomele (de exemplu: aprobarea de ctre un demonstrator de
teoreme, de ctre programator, executarea cu succes a ctorva teste), n caz c apare o eroare,
o analiz a cii critice ar putea indica cea mai slab legtur n lanul demonstraiei.
Putem constata c MIL se potrivete bine cu sistemele de transformare i alte forme de
reutilizare n care proiectarea joac un rol esenial. Atunci cnd se caut o component
58/135
potrivit ntr-o bibliotec de module, semantica acestora este mult mai important dect
sintaxa interfeei. LIL reprezint un prim pas n aceast direcie, deoarece legtura semantic
este una din cele mai importante probleme n demararea reutilizrii.
5.3.2 Programarea orientat obiect
Programarea orientat obiect a fost una din cele mai rsuntoare sintagme ale anilor '80.
Care este potenialul limbajelor orientate obiect n ceea ce privete reutilizarea software? Este
evident c bibliotecile de module devin mult mai utilizabile dac conin module orientate
obiect. Dac modulul cutat nu este gsit, nu este necesar adaptarea unui modul aproape
potrivit prin crpirea codului, acesta este ntotdeauna un demers periculos. Caracteristicile
dorite pot fi motenite dintr-o clas convenabil deja prezent n bibliotec iar caracteristicile
n plus pot fi adugate unei subclase nou definite.
Motenirea i polimorfismul unui limbaj orientat pe obiect asigur prin ele nsele
oportuniti pentru construirea prilor reutilizabile. Acestea promoveaz apariia unor clase
abstracte care pot servi ca punct de plecare pentru derivarea mai multor componente specifice.
5.4 Perspectivele reutilizrii software
Dup cum spunea Johnson n 1988, abstractizrile utile sunt descoperite, nu inventate",
n orice tehnologie de reutilizare, blocurile reutilizabile, fie c sunt sub forma unor subrutine,
abloane, transformri sau soluii ale problemelor cunoscute de proiectani, corespund
pieselor de cunoatere cristalizate, piese care pot fi folosite n alte situaii dect cele pentru
care au fost gndite iniial. O ntrebare central n toate tehnologiile de reutilizare discutate
mai sus este felul n care se poate exploata o mulime dat de blocuri reutilizabile. Aceasta are
o mare importan n diversele proiecte din domeniul bibliotecilor de componente, unde
principalul scop este de a prevedea modaliti de extragere a componentei utilizabile pentru
sarcina n lucru, n mod alternativ, putem privi reutilizarea software drept identificarea
blocurilor de care avem nevoie pentru a le putea folosi n diverse aplicaii.
Atunci cnd se ncearc identificarea unor componente refolosibile, principala problem
este de a se decide de ce componente avem nevoie. O component refolosibil trebuie
valorificat, nu din motivul evident c ne scutete de a implementa funcionalitatea noi nine,
ci pentru c ofer o parte din cunotinele domeniului corect, adic exact funcionalitatea de
care avem nevoie, ctigat dup mult experien i dup mai multe ncercri de a gsi
abstractizrile corecte. Componentele ar trebui s reflecte noiunile primitive ale domeniului
aplicaiei. Pentru a putea identifica o mulime adecvat de primitive pentru un domeniu dat,
este necesar o experien considerabil n implementarea unui software pentru acel domeniu.
Pe msur ce este ctigat aceast experien, evolueaz ncet i mulimea adecvat de
primitive.
Un domeniu este caracterizat printr-o colecie de noiuni comune care au coeren, n
timp ce n afara domeniului, aceleai noiuni nu exist sau nu prezint aceeai coeren.
Domeniile pot fi mai largi sau mai restrnse, de exemplu:
program pentru contabilitate;
program pentru contabilitate multinaional;
program pentru contabilitate multinaional implementat de Soft SRL.
Toate programele de contabilitate vor conine noiuni ca registru" i balan".
Programul pentru contabilitate multinaional ca avea cteva noiuni referitoare la fluxul de
bani ntre diferite ri, noiuni care nu exist n sistemele de contabilitate pentru aprozare sau
gogoerii. Reprezentrile noiunilor n programul dezvoltat de Soft SRL vor fi diferite de cele
ale altor firme din cauza folosirii diferitelor metodologii sau convenii.
Pentru majoritatea domeniilor, nu este evident imediat care sunt primitivele corecte.
Este n ultim instan o problem de ncercare i eroare. Astfel, ncet-ncet se gsete
59/135
mulimea adecvat de primitive. Pe msur ce se dezvolt un domeniu, deosebim un numr de
etape:
La nceput, nu exist nc un set clar de noiuni i tot programul este scris de la
nceput. Experiena se ctig ncet, pe msur ce se nva din greelile
anterioare;
n etapa a doua, probleme similare sunt depistate i rezolvate n moduri similare.
Sunt recunoscute primele primitive semantice. Dup ce se ncearc i se d gre,
se decide care sunt primitivele utile i care sunt cele inutile;
n a treia etap, domeniul este gata de reutilizare. S-au implementat un numr
rezonabil de programe, s-a stabilit o mulime de concepte, s-au gsit soluii
standard pentru o serie de probleme standard;
n sfrit, domeniul a fost explorat n totalitate. Implementarea programelor
pentru domeniu poate fi automatizat. Nu se mai programeaz efectiv, ci se
folosete o interfa standard format din primitivele semantice ale domeniului.
Majoritatea reutilizrii apare n ultima etap, dei nu mai este recunoscut ca atare.
Acum mult timp n urm, calculatoarele erau programate n limbaj de asamblare, n limbaje
de nivel nalt scriem ce dorim" i compilatorul transform acesta ntr-un program adevrat".
Aceast aciune nu mai este privit ca reutilizare. Un fenomen asemntor apare la tranziia
dintr-un limbaj de a treia generaie ntr-un limbaj de a patra generaie.
Din punctul de vedere al reutilizrii, clasificarea de mai sus este una normal, natural
pentru evoluia unui domeniu. Diversele etape sunt categorizate la nivele calitative diferite:
n prima etap nu exist reutilizare;
n a doua etap reutilizarea este ad hoc;
n a treia etap reutilizarea este structurat, componentele existente sunt
refolosite ntr-un mod organizat atunci cnd se implementeaz un nou program;
n etapa a patra, reutilizarea este instituionalizat i automatizat, efortul uman
este restricionat la nivele superioare de abstractizare.
n cadrul unui domeniu dat este folosit un limbaj informai, n care acelai lucru poate fi
exprimat n mai multe moduri, folosind concepte care nu sunt bine definite. Totui, limbajul
informai este uor de neles deoarece conceptele se refer la un univers de expunere comun
att vorbitorului ct i asculttorului.
ntr-un limbaj formal, conceptele nu se refer la experiena sau cunotinele de zi cu zi.
Acestea au neles abia ntr-un sistem formal. Un astfel de sistem formal este o main
virtual iar limbajul su este de asemenea un limbaj formal.
A formaliza un domeniu nseamn a construi un limbaj formal (pe domeniu) care
mimeaz un limbaj informai existent. Trebuie apoi s se aleag dintre diversele primitivele
semantice care exist informai. Uneori este convenabil s se adauge noi primitive, care se
potrivesc bine domeniului formalizat. De exemplu, s considerm domeniul setrilor de
tehnoredactare. O parte a formatrii documentelor se refer la asamblarea cuvintelor n linii i
a liniilor n paragrafe. Secvena de cuvinte care compune un paragraf trebuie mprit n linii
astfel nct rezultatul s fie satisfctor din punct de vedere tipografic.
Knuth (1981) descrie aceast problem folosind termenii cutii", lipici" i penalizri".
Cuvintele sunt cuprinse n cutii cu o anume lime. Spaiul alb dintre cuvinte este considerat
lipici, care se poate mri sau micora. Este preferat un spaiu convenional ntre cuvinte
adiacente, iar acestei asocieri i corespunde o penalizare nul. Apropierea sau deprtarea
cuvintelor atrage o penalizare pozitiv. Cu ct este mrit sau micorat mai mult lipiciul, cu
att este mai mare penalizarea. Prin urmare, penalizarea asociat cu formatarea unui ntreg
paragraf este suma pedepselor asociate spaiilor inter-cuvnt din paragraful formatat.
Problema poate fi reformulat astfel: mparte paragraful n linii astfel nct penalizarea total
s fie minim. Trebuie menionat c penalizrile pot fi asociate i altor proprieti nedorite din
60/135
punct de vedere tipografic, aa cum este desprirea cuvintelor n silabe la sfritul unui rnd.
Noiunile cutii", lipici" i penalizri" ofer o formalizare elegant a anumitor aspecte ale
tehnoredactrii. De asemenea, ofer o soluie eficient a problemei de mai sus, folosind o
tehnic a programrii dinamice.
n practic, formalizarea nu este o activitate cu un singur pas. Este mai degrab un
proces iterativ. Versiunea formalizat nu descrie tocmai exact limbajul informai, ci precizeaz
o posibil interpretare. Dac i studiem semantica, acesta poate avea cteva aspecte nedorite,
n continuare este atins un compromis acceptabil ntre cei ce folosesc limbajul (n domeniile
de nivel nalt) i cei care l implementeaz (n domeniile de nivel sczut). Odat ce limbajul
domeniului formal este hotrt, el afecteaz i limbajul informai al domeniului. Persoanele
care lucreaz n cadrul domeniului ncep s foloseasc primitivele limbajului formal.
Este acum clar c nu este indicat trecerea direct de la etapa nti (fr reutilizare) la
etapa a treia (reutilizare structurat). Formalizarea are un efect de solidificare asupra
primitivelor semantice ale domeniului. Noiunile privind primitivele se modific, deoarece
acestea nu mai sunt considerate ca venind din universul de discurs intuitiv, ci din formalismul
care st la baza acestuia. Rspunsul la ntrebarea crucial dac am formalizat primitivele
semantice corecte devine mai greu de gsit. Etapa a doua (reutilizarea ad hoc) este foarte
important, n aceast etap avem o vedere de interior a domeniului de aplicaie i descoperim
primitivele semantice utile. Att n ceea ce privete lucrul cu primitivele, ct i implementarea
lor, se dovedete c aceast experien este de o importan vital pentru formalizarea
domeniul n mod corect. 5. Aspecte non-tehnice ale reutilizrii software
Pn acum am discutat numai aspectele tehnice ale reutilizrii software. Ingineria
programrii nu este preocupat numai de aspectele tehnice, ci i de indivizi i de mediul n
care acetia i desfoar activitatea. Domeniul ingineriei programrii este influenat de
societate. Reutilizarea software n Europa este posibil diferit de cea din Statele Unite sau
Japonia. Din cauza diferenelor culturale i a structurilor economice diferite, nu este limpede
a-priori c abordarea Toshiba poate fi copiat de europeni cu aceleai rezultate.
Dei pn acum discuia noastr s-a referit la aspectele tehnice ale refolosirii software,
acesta nu poate fi ncheiat fr cteva cuvinte despre problemele non-tehnice, care sunt intim
mpletite cu cele tehnice. Diveri cercettori ai refolosirii software au discutat aprins c
tehnologia necesar refolosirii software este disponibil, dar principalele probleme care inhib
o industrie prosper a refolosirii sunt de natur non-tehnic. Programele refolosibile cu succes
conin urmtoarele caracteristice:
Management auxiliar necondiionat i extensibil: Un program refolosibil
necesit schimbri pe msur ce este implementat. Implicarea managementului
este esenial pentru a face modificrile s funcioneze, n particular, construirea
unei baze de articole reutilizabile necesit o investiie n avans care s-ar putea s
nu fie recuperabil dect dup un timp;
Stabilirea unei structuri organizatorice auxiliare: Organizaia trebuie s furnizeze
iniiativa, fondurile i politicile pentru programul reutilizabil. Este necesar un
corp separat pentru a evalua potenialii candidai pentru includerea ntr-o
bibliotec reutlizabil. Este necesar un bibliotecar pentru ntreinerea bibliotecii;
Implementarea incremental a programului: Un prim catalog cu articole
potenial reutilizabile poate fi construit cu un cost relativ mic. Experiene
pozitive cu o astfel de bibliotec iniial vor furniza stimulentele materiale
necesare pentru a mri biblioteca, a inventa o schem de clasificare etc.;
Succese semnificative, att pe plan financiar ct i organizatoric: De exemplu, o
cretere cu 50% a productivitii pe o perioad de civa ani;
61/135
Programatorii sufer de sindromul neinventat aici": Prin crearea unui mediu
care valorific att crearea de software reutilizabil ct i reutilizarea software, se
stabilete o atmosfer n care reutilizarea poate deveni un succes;
Analiza domeniului este un proces n care conceptele i mecanismele pe care se
bazeaz un domeniu bine neles sunt identificate i transformate n resursele
reutilizabile.
5.5 Economia reutilizrii software
5.5.1 Economia refolosirii software
Reutilizarea este o investiie pe termen lung." (Tracz, 1990) Reutilizarea nu este
gratuit, ntr-un mediu tradiional de dezvoltare, produsele sunt realizate n funcie de situaie.
Este probabil ca situaii similare s necesite produse i componente puin diferite. Pentru ca o
component software s devin refolosibil, trebuie s fie generalizat pornind de la situaia
prezent, testat i documentat intens, ncorporat ntr-o bibliotec i o schem de clasificare
i pstrat ca o entitate separat. Aceste operaii necesit investiii iniiale, care ncep s fie
recuperabile abia dup o anumit perioad de timp.
Recuperri imediate ale investiiei pot fi obinute dac programul refolosit este mic la
nceput i are o bibliotec iniial ai crei membri sunt extrai din produsele existente.
Dezvoltarea programului poate fi apoi justificat pe baza experienelor pozitive anterioare.
Dar chiar i atunci trebuie alocate fonduri care nu sunt specifice proiectului.
Consecinele economice ale reutilizrii software depesc economiile costurilor n
producie i ntreinere. Se modific nsi natura procesului de dezvoltare software.
Programul devine un capital. Costurile iniiale mari sunt legate de recuperri pe perioade mai
mari de timp.
5.5.2 Reutilizarea software i managementul
Producia de software trebuie s fie organizat astfel nct s fie promovat reutilizarea.
Modelul tradiional cascad tinde s mpiedice reutilizarea. n modelul cascad, accentul cade
pe msurarea i controlarea progresului proiectului. Calitatea produsului n raport cu gradul de
reutilizare este greu de msurat. Nu exist un stimulent real pentru a cuta s se realizeze
gradul de reutilizare, avnd n vedere c principalul (i uneori singurul) scop este de a termina
proiectul curent la timp i ncadrat n buget. Nu exist nici o motivare n a face urmtorul
proiect s arate bine. n consecin, reutilizarea software tinde s capete o prioritate mic.
Reutilizarea software trebuie s fie ncorporat n procesul de dezvoltare. Articolele
reutilizabile trebuie cutate n mod activ.
Chiar i bibliotecile de articole reutilizabile trebuie administrate. Astfel, trebuie creat o
infrastructur organizaional care face accesibil biblioteca (documentare, scheme de
clasificare), evalueaz candidaii pentru includerea n bibliotec, menine i actualizeaz
biblioteca etc. Un rol organizaional separat, bibliotecarul, poate fi creat tocmai pentru acest
scop. Sarcinile sale seamn cu cele ale unui administrator de baze de date.
Un alt tip de reutilizare este reutilizarea persoanelor. Proiectanii experi valoreaz
greutatea lor n aur. Orice programator mediu este capabil s scrie un program mare,
complicat. Pentru a obine o soluie radical nou, mai bun, mai mic, mai elegant pentru
aceeai problem, este nevoie de o persoan care are idei sclipitoare din cnd n cnd.
O problem major n domeniul nostru este c administratorii sunt mai apreciai dect
programatorii sau proiectanii. Dac eti bun cu adevrat, mai devreme sau mai trziu (dar de
obicei mai devreme), te vei ridica pe scara ierarhic i vei ajunge s faci parte administraie.
Dup Brooks, exist un singur mod de a neutraliza acest fenomen. Pentru a ne asigura c
aceti oameni sclipitori rmn proiectani de sistem, avem nevoie de o schem de personal
62/135
dual, n care proiectanii buni au aceleai perspective n ceea ce privete slujba ca i
administratorii buni.
5.5.3 Aspecte psihologice ale reutilizrii software
Reutilizarea codului altor persoane ar demonstra c mie nu mi pas de munca mea. Nu
voi mai reutiliza cod, aa cum nici Hemingway nu folosete paragrafele altor scriitori." (Cox,
1990)
Reutilizarea nseamn c programatorii trebuie s se adapteze, s ncorporeze sau s
rentinereasc" codul scris de ali programatori. Exist dou aspecte importante ale acestui
proces:
sunt programatorii dispui s fac acest lucru?
sunt capabili s fac acest lucru?
Diverse cercetri arat c programatorii folosesc anumite scheme standard n anumite
situaii standard. Programatorii experimentai tind s devin confuzi atunci cnd o problem
cunoscut a fost rezolvat folosind soluii ne-standard. Drept consecin, gradul de reutilizare
a componentelor este mrit dac aceste componente conin abstractizri familiare
programatorilor. Aceleai probleme apar n analiza de domeniu, n care se ncearc
identificarea noiunilor familiare experilor ntr-un anumit domeniu.
n alte studii apare ideea c un efect secundar al folosirii proiectrilor standard i a
componentelor standard este nelegerea crescut a programului rezultat. De ndat ce toi
programatorii se obinuiesc cu un anumit stil, toate programele par a fi scrise de aceeai
echip. Orice echip poate nelege i adapta un program scris de oricare alt echip.
5.6 Concluzii
Reutilizarea software este mai degrab un obiectiv dect un domeniu. A aprut ca o
problem n cadrul ingineriei programrii, nu din cauza fascinaiei sale ca problem tiinific,
ci datorit ctigul scontat n productivitatea dezvoltrii software. Prima conferin despre
reutilizarea software a avut loc n 1983. De atunci, acest subiect a primit o atenie din ce n ce
mai mare. n acest curs am discutat principalele perspective ale problemei reutilizrii.
Diversele tehnologii de reutilizare discutate pot fi divizate n dou mari categorii tehnologii
bazate pe compunere i tehnologii bazate pe generare, n primul caz, se urmrete
ncorporarea componentelor existente n noul program ce va fi implementat, ntr-o tehnologie
bazat pe generare, este mult mai dificil s se identifice explicit componentele care se
reutilizeaz. Cunotinele reutilizate pot fi gsite n programe care genereaz alte programe.
Au fost descrise n continuare caracteristicile limbajelor de interconectare a modulelor. S-au
menionat perspectivele reutilizrii software i n final s-a insistat i asupra aspectelor non-
tehnice ale reutilizrii: economia, managementul i psihologia reutilizrii.
63/135
6 Ingineria cerinelor. Analiza orientat obiect
6.1 Ingineria cerinelor
Primul pas logic n dezvoltarea unui program este stabilirea precis a cerinelor
clientului (ceea ce vrea clientul s fac programul). Partea cea mai important a acestui proces
o reprezint comunicarea dintre client i echipa de dezvoltare. Cnd un inginer de programe
lucreaz la stabilirea cerinelor, el este numit inginer de cerine, analist de sistem sau analist.
Dezvoltarea unui program ncepe de obicei cu o idee a clientului despre un nou sistem sau
pentru mbuntirea unui sistem existent. Clientul angajeaz un analist cu care va lucra
mpreun pentru specificarea mai exact a cerinelor. Ideea iniial a clientului poate fi vag i
prost definit, sau dimpotriv, poate fi clar i bine definit.
Stabilirea cerinelor este probabil cea mai important activitate n dezvoltarea
produselor program. Dac un client nu tie sau nu poate s stabileasc n urma unei discuii cu
echipa de dezvoltare n mod exact ce vrea s fac produsul, este inutil s angajeze o echip
care s programeze. O echip de programatori poate s scrie cel mai estetic program din punct
de vedere al tehnicilor de programare folosite, dar dac nimeni nu va dori s-1 foloseasc,
proiectul va fi un eec.
Multe programe nu se potrivesc cu cerinele clientului nu din motive de implementare
defectuoas, ci din cauz c cerinele nu au fost specificate corect de la nceput. Persoane ale
cror legturi cu ingineria programrii sunt mai mult pretinse dect obiective consider c
nepotrivirea dintre ateptrile clientului i programul obinut in de lipsa de cultur, sim
artistic i cunotine tehnice ale programatorilor. Adevrul este c programatorii nu pot i nu
au cum s cunoasc necesitile clienilor, mai ales dac nu cunosc domeniul pentru care este
scris o anumit aplicaie.
Este responsabilitatea clientului de a veni cu cereri exacte i pertinente. Este obligaia
inginerului de cerine s discute cu clientul pentru a clarifica cerinele i a-1 ajuta s-i fixeze
prioritile. Stabilirea precis a cerinelor este primul pas n obinerea unui program care
satisface nevoile clientului. O specificaie bun este folosit i n fazele de validare i
verificare.
6.1.1 Cerina
Noiunea de cerin este mai veche dect dezvoltarea programelor. De exemplu, o
cerin pentru o locomotiv ar putea arta astfel: pe o cale ferat uscat, locomotiva trebuie s
fie capabil s porneasc un tren de 100 tone pe o pant de maxim 5% cu o acceleraie de cel
puin 0,5 m/s2. De remarcat c aceast cerin spune ce vrea clientul. Nu spune nimic despre
cum ar putea fi realizat. Nu se specific tipul motorului (cu aburi, diesel, electric) sau
materialul din care s se confecioneze roile.
Apare aici o problem controversat: este bine s facem specificarea lund n
considerare felul n care sistemul va fi implementat? Fiecare variant are avantajele i
dezavantajele ei:
Nu folosim detalii de implementare: Nu ne ateptm ca un client s tie lucruri
specifice dezvoltrii programelor, i deci nu poate s fie de acord n cunotin
de cauz cu stipulrile din specificaii. Secretarele care folosesc Excel tiu
COM? E necesar s facem constrngeri asupra programului nc din faza de
concepere?
Folosim detalii de implementare: Cteodat nu este posibil s ignorm o
implementare existent. Dac facem un program pentru o bibliotec, studiem
implementarea existent (tipul fielor ce trebuie completate, fluxul de lucru,
64/135
modul de organizare al mediilor de stocare a informaiilor) i o copiem" n
program. Putem verifica dac o cerin este sau nu rezonabil din punct de
vedere tehnic. Pentru a putea estima timpul de dezvoltare i preul, trebuie luat
n considerare implementarea. Exist o diferen ntre a programa n Visual
Basic i a programa n Visual C++. Costurile iniiale la programarea n Visual
Basic vor fi mai mici (timp de dezvoltare mai mic, programatori mai ieftini),
ns odat ce produsul necesit dezvoltarea peste o anumit limit a
complexitii, costurile vor crete (ntreinere greoaie, probleme de
performan).
6.1.2 Extragerea cerinelor
Presupunem c analistul i clientul lucreaz mpreun, fiecare ncercnd s l neleag
pe cellalt. Esena procesului de obinere a cerinelor este comunicarea. Se disting trei
activiti majore care conduc la obinerea unei specificri a cerinelor:
Ascultare: analistul nregistreaz cerinele clientului;
Gndire: analistul ncearc s traduc cerinele clientului n limbaj tehnic i s se
asigure de pertinena cerinelor n acest context;
Scriere: analistul i clientul cad de acord asupra unor formulri ale cerinelor pe
care analistul le consider pertinente.
Aceste activiti sunt parte a unui proces iterativ, lung i complicat. Negocierea este
foarte important. Diferena cultural dintre client i analist este cteodat foarte mare. Exist
situaii cnd exist diferene semnificative ntre ateptrile utilizatorilor finali i ale clientului.
Un exemplu concret al acestui tip de conflict este cnd un patron ce comand un program care
s fie utilizat de ctre angajaii si dorete ca acesta s conin module de monitorizare a
muncii angajailor. Aceasta ridic o dilem de natur etic pentru inginerul programator: s
anune angajaii c sunt spionai fr s tie sau s fie loial celui care l pltete. O alt
problem o reprezint literatura SF studiat de client, nainte de angajarea echipei de
dezvoltare. Clientul ateapt mult prea mult de la program i de la echipa de dezvoltare,
nchipuindu-i c programele se scriu ca n filme, ntr-o scen de dou minute, ca un amnunt
dintr-un film de dou ore. n concluzie, analistul trebuie:
s extrag i s clarifice cerinele clientului;
s ajute la rezolvarea diferenelor de opinie ntre clieni i utilizatori;
s sftuiasc clientul despre ce este tehnic posibil sau imposibil;
s documenteze cerinele;
s negocieze i s obin o nelegere cu clientul.
6.1.3 Metode pentru identificarea cerinelor utilizatorilor
Una sau mai multe din urmtoarele modele prezentate mai jos pot fi folosite pentru a
identifica cerinele utilizatorului:
Interviuri: Interviurile trebuie astfel structurate nct s poat aborda toate
aspectele implicate de sistemul software ce va trebui dezvoltat. Cnd exist
foarte muli utilizatori, se va selecta un set reprezentativ dintre acetia pentru a fi
intervievai. Interviurile pot fi utile n a asigura:
o completitudinea cerinelor utilizatorului;
o existena unei acceptri generale a cerinelor utilizatorului;
Studiul sistemelor software existente deja: De multe ori, noul sistem software
este destinat nlocuirii altui sistem existent. Investigarea caracteristicilor i bune
i rele ale sistemului existent poate ajuta n determinarea cerinelor pentru ceea
65/135
ce se dorete. Examinarea manualelor utilizatorilor, a documentelor cerinelor i
a diverselor propuneri poate fi foarte folositoare;
Studiul de fezabilitate: Studiul de fezabilitate reprezint analiza i proiectarea
principalelor caracteristici ale sistemului n scopul de a determina dac
implementarea este posibil;
Prototipul: Un prototip este un model executabil al unor aspecte selectate din
sistemul propus. Dac cerinele sunt neclare sau incomplete, ar putea fi util
dezvoltarea unui prototip, bazat pe un set de cerine de prob, pentru a identifica
cerinele reale ale utilizatorilor.
6.1.4 Metode pentru specificarea cerinelor utilizatorilor
6.1.4.1 Limbajul natural
Modul evident de specificare a unei cerine este limbajul natural. Limbajul natural este
foarte accesibil dar inconsistent i ambiguu. De exemplu, afirmaia: Baza de date va conine o
adres poate fi interpretat dup cum urmeaz:
Va fi doar o singur adres
parte din baza de date va fi desemnat ca o adres.
Va fi cel puin o adres n baza de date.
6.1.4.2 Formalisme matematice
Formule matematice pot fi folosite pentru a clarifica o cerin. Toate simbolurile
folosite ntr-o expresie trebuie definite sau referite.
6.1.4.3 Engleza structurat
Engleza structurat este un limbaj de specificare care folosete un vocabular i o sintax
foarte limitate.
Vocabularul const doar din:
verbe imperative ale limbii engleze;
termeni definii ntr-un glosar;
cuvinte rezervate.
Sintaxa e limitat la urmtoarele posibiliti:
simple construcii declarative;
construcii decizionale;
construcii repetitive.
Engleza structurat este folosit de obicei pentru a descrie procesele de baz ale
sistemului.
Exemple:
construcii declarative
GET RAW DATA
REMOVE INSTRUMENT EFFECTS
CALIBRATE CORRECTED DATA
construcii decizionale
IF SAMPLE IS OF NOMINAL QUALITY THEN
CALIBRATE SAMPLE
ELSE
STORE BAD SAMPLE
construcii repetitive
FOR EACH SAMPLE
66/135
GET POINTING DIRECTION
AT TIME OF SAMPLE STORE POINTING DIRECTION WITH SAMPLE
Formaliznd engleza structurat se poate automatiza prelucrarea cerinelor (verificarea
automat, o analiz automat, transformri i afiri) i se poate simplifica definirea testelor
pentru faza de verificare i validare a sistemelor.
6.1.4.4 Tabele
Tabelele reprezint o metod de descriere concis i complet a cerinelor. Aceast
metod poate rezuma anumite relaii, interaciuni ntre cerine mai eficient dect o prezentare
textual.
6.1.4.5 Diagrame bloc ale sistemului
Diagramele bloc reprezint modul tradiional de prezentare a proceselor dorite. Ele pot,
de asemenea, demonstra contextul n care sistemul va opera atunci cnd este o parte dintr-un
sistem mai mare.
6.1.5 Documentul cerinelor utilizatorului (DCU)
Acesta este documentul obligatoriu, produs n faza definirii cerinelor i trebuie s fie
finalizat nainte de proiectarea sistemului. DCU trebuie:
s furnizeze o descriere general ceea ce utilizatorul dorete s execute sistemul;
s conin toate cerinele cunoscute, ale utilizatorilor;
s descrie toate operaiile pe care le va executa sistemul;
s descrie toate constrngerile impuse sistemului;
s defineasc toate interfeele externe sistemului sau s conin referine despre
ele n alte documente.
Costul modificrii cerinelor crete cu att mai mult cu ct proiectul nainteaz n fazele
urmtoare. In faza de testare a sistemului, verificarea se va face pe baza DCU. Standardele
ingineriei programrii recomand urmtoarele caracteristici ale stilului de prezentare a unui
DCU:
DCU trebuie scris folosind un limbaj, vocabular i stil uor de neles de ctre
toi utilizatorii. DCU trebuie s fie clar, consistent, modificabil;
Un DCU este clar dac orice cerin este neambigu (are o singur interpretare)
i este neleas de toi participanii la proiect;
O cerin trebuie scris ntr-o singur propoziie iar justificrile trebuie separate
de aceasta. Se recomand ca cerinele corelate ntre ele s fie grupate.
Structurarea cerinelor n document este foarte important;
Un DCU este consistent dac nu exist conflicte ntre cerine. Folosirea mai
multor termeni pentru a specifica acelai lucru este un exemplu de inconsisten;
Un DCU este modificabil dac orice modificare a cerinelor poate fi
documentat uor, complet i consistent.
6.1.5.1 Evoluia DCU
Modificrile inevitabile ale DCU sunt responsabilitatea utilizatorului. E necesar
pstrarea unei istorii a modificrilor efectuate. Problema actualizrii ntregii documentaii va
fi rezolvat cnd va fi stabilit o arhitectur electronic standard pentru documente. Dac
schimbrile cerinelor sunt rezolvate direct n faza de implementare, fr a mai fi prinse n
documentaie, aceasta poate provoca serioase probleme n faza de ntreinere a sistemului.
Iniiatorul proiectului ar trebui s monitorizeze tendina n apariia unor noi cerine ale
utilizatorului. O tendin cresctoare va periclita succesul proiectului.
67/135
6.1.5.2 Responsabiliti
Se pun n eviden urmtoarele recomandri:
definirea clar tuturor responsabilitilor nainte de nceperea DCU;
utilizatorii reali ai sistemului sunt responsabili pentru determinarea cerinelor de
capabilitate;
inginerii software trebuie s ia parte la formarea DCU pentru a-i ajuta pe
utilizatori;
indiferent de organizare, utilizatorii nu trebuie s dicteze soluii iar echipa de
dezvoltare nu trebuie s dicteze cerine.
6.1.5.3 Coninutul DCU
Structura general a unui DCU, recomandat de standardul ingineriei programrii, este
prezentat n continuare:
1. Introducere
2. Descriere general
3. Cerine specifice
Seciunea l trebuie s descrie pe scurt scopul sistemului software, listele de definiii
pentru termeni utilizai n document, lista de referine bibliografice identificate prin autor, titlu
i date, i o trecere n revist a restului documentului.
Seciunea 2 se refer la:
capabilitile generale ale sistemului i de ce sunt ele necesare;
constrngerile generale i motivul pentru care au fost impuse;
caracteristicile generale ale utilizatorilor sistemului (nivelul educaiei lor,
limbajul, experiena lor tehnic pot impune importante constrngeri asupra
software-ului) din fazele de operare i ntreinere ale sistemului. Este important
clasificarea acestor utilizatori i estimarea numrului lor, n fiecare categorie;
mediul extern n care sistemul va opera, prin diagrame de context pentru a
evidenia interfeele externe i prin diagrame bloc pentru a evidenia activitile
din ntregul sistem;
situaiile de risc evideniate n urma analizei riscurilor.
Seciunea 3 este partea principal a DCU, prezentnd toate cerinele de capabilitate i
cerinele restrictive ale sistemului. Validitatea sistemului software se va face pe baza acestor
cerine. Se recomand urmtoarele caracteristici:
Fiecare cerin trebuie unic identificat;
Fiecare cerin trebuie marcat funcie de importana sa (unele pot fi extrem de
importante, altele inacceptabile, altele suspendate pn la obinerea unor resurse
necesare, altele sunt prioritare, instabile);
Fiecare cerin trebuie s fie verificabil. O afirmaie trebuie s conin o
singur cerin. O cerin e verificabil dac exist o metod ce demonstreaz
obiectiv c ea este asigurat de sistem. (Afirmaii ca: interfaa utilizator va fi
prietenoas", sistemul va merge bine", nu sunt verificabile deoarece termenii
bine", prietenos" nu au interpretri obiective). Dac nu exist o metod pentru
verificarea acestei cerine, aceasta este invalid.
6.2 Analiza orientat obiect. Metode de analiz orientat obiect
Acesta este numele unei clase de metode de analiz a unei probleme prin studiul
obiectelor domeniului problemei respective. Pe msur ce industria de software continu s se
confrunte cu probleme ca slaba productivitate i calitate a produselor software, companiile de
software din ntreaga lume caut mereu noi soluii, sub form de utilitare, metode, tehnici.
68/135
Tehnicile structurate au fost considerate soluia salvatoare a anilor 1970-1980. Apoi s-a
sugerat c orientarea obiect ar fi o astfel de soluie. Fiecare nou paradigm a fost adoptat cu
un oarecare fanatism. Totui, n 1988, ntr-un eseu intitulat No Silver Bullet, Brooks
argumenta c nu exist nici o soluie magic pentru dificilele probleme fundamentale ale
dezvoltrii sistemelor software. Nu exist nici un panaceu, nici un miracol care s creasc
productivitatea i n acelai timp s elimine toate erorile sistemului. Deci, nu e cazul s ne
facem iluzii c tehnicile OO ar putea fi cheia tuturor problemelor. Nu exist nici o garanie c
ea ar putea preveni dezastrul unui sistem software.
Un analist fr experien, intervievnd comunitatea utilizatorilor, ar putea s nu
descopere obiectele relevante din sistem. Un utilizator recalcitrant sau necooperant ar putea s
nu furnizeze anumite informaii, servicii, atribute ale sistemului. i, bineneles, orice proiect
poate suferi, indiferent de utilitarele i metodele folosite, din cauza modului de coordonare a
proiectului, sau a incompetenei personalului.
Obiectul reprezint o ncapsulare a valorilor unor atribute i a serviciilor lor exclusive.
O clas descrie un set de obiecte cu atribute i servicii comune. Un obiect este o instan a
unei clase si crearea unui obiect se numete instaniere. Clasa poate fi descompus n
subclase. Subclasele au n comun atributele caracteristice unei familii de clase, motenind
operaiile i atributele claselor-prini.
Iniiatorii acestei metode argumenteaz c modul de a privi un sistem din perspectiva
obiectelor este mult mai natural dect analiza sistemelor din punct de vedere funcional.
Specificaiile bazate pe obiecte sunt mai adaptabile dect cele bazate pe funcii.
Cele mai importante i recunoscute metode AOO sunt:
Coad-Yourdon;
Rumbaugh-Object Modelling Technique (OMT);
Shlaer-Mellor;
Booch (crile lui Booch privind metodele OO au fost prezentate de Stroustrup,
inventatorul limbajului C++, ca fiind singurele care merit s fie studiate n acest
domeniu datorit practicilor aprofundate de analiz i proiectare expuse n
lucrrile sale. Din pcate ns, notaiile utilizate de Booch sunt complicate i
exist prea puine utilitare care s suporte aceast metod.)
n momentul de fa, analiza orientat obiect evolueaz iar analitii, de obicei, combin
tehnicile diferitelor metode n faza de analiz a problemei.
Ecuaia utilizat pentru a recunoate o metod OO este:
OO = clase i obiecte + motenire + comunicare prin mesaje
In acest fel se poate spune dac un limbaj sau un mediu este sau nu OO. Analiza
orientat obiect nu se utilizeaz pentru sisteme care au foarte puine funcionaliti sau pentru
sisteme cu 1-2 clase i obiecte.
6.2.1 Principiile analizei orientate obiect
Principiile utilizate de AOO se bazeaz n primul rnd pe trsturile eseniale ale
programrii orientate obiect:
Abstractizare (procedural i de date);
Motenire. Pe lng acestea, alte principii importante sunt:
Comunicarea prin mesaj e;
Utilizarea metodelor de organizare:
obiecte i atribute;
obiecte i prile sale; o clase i membrii.
69/135
6.2.2 Abstractizarea
Principiul abstractizrii presupune ignorarea acelor aspecte ale unui subiect care nu sunt
relevante pentru obiectivul curent. Aceasta este o tehnic important pentru a coordona
complexitatea. Aadar, abstractizarea este un mecanism care permite reprezentarea unei
situaii complexe a lumii reale printr-un model simplificat. De exemplu, abstractizarea unei
culori din lumea real poate fi realizat prin modelul RGB (red, green, blue).
Abstractizarea procedural este principiul conform cruia orice operaie poate fi tratat
ca o singur entitate n ciuda faptului c ea presupune realizarea mai multor operaii de pe
nivelul urmtor de detaliu. Aceast form de abstractizare joac un rol foarte important n
definirea serviciilor sistemului.
Abstractizarea datelor reprezint un mecanism mai puternic de abstractizare conform
cruia tipurile de date sunt definite n termenii operaiilor ce se aplic obiectelor de acel tip,
cu restricia c valorile acelor obiecte pot fi observate i modificate doar prin intermediul
operaiilor menionate.
Prin aplicarea acestui principiu, un analist definete atributele i serviciile care
manipuleaz aceste atribute. Singurul mod de a accesa un atribut este prin intermediul
serviciilor. Atributele i serviciile pot fi vzute ca formnd un ntreg.
Abstraciile sunt ncapsulate n obiecte. Strile i comportamentele comune ale
obiectelor sunt ncorporate n clase. Implementarea intern propriu-zis este ascuns de restul
sistemului. De exemplu, dac o culoare este vzut ca o valoare RGB, reprezentarea intern
poate folosi modelul HSV (hue, saturation, value) dac acesta este mai potrivit, fr ca acest
fapt s afecteze restul sistemului.
6.2.3 Motenirea
Motenirea reprezint mecanismul prin care se exprim similaritile dintre clase,
simplificnd definirea claselor prin utilizarea unor clase anterior definite. Acest principiu
pune n eviden generalizarea i specializarea, fcnd explicite atributele i serviciile
comune, printr-o ierarhie de clase. Principiul motenirii permite analistului s specifice
atributele i serviciile comune doar o singur dat, sau s specializeze i s extind anumite
atribute i servicii.
Polimorfismul adaug o nou dimensiune la separarea dintre interfa i implementare,
dintre ce i cum. El permite crearea de programe flexibile i extensibile, n care noi trsturi
pot fi adugate cu uurin nu numai n momentul crerii proiectului, dar i n etapele de
dezvoltare ulterioare. Polimorfismul rmne totui un detaliu de implementare, care poate fi
ignorat n faza de analiz.
6.2.4 Comunicarea prin mesaje
Se refer la interaciunea prin mesaje ntre obiecte, interaciune care corepunde modului
imperativ al limbajelor (comand, cerere). 2.5. Metodele de organizare
Strategia analizei poate fi construit pe baza a trei metode de organizare:
iferenierea ntre obiecte i atributele lor (de ex.: a distinge ntre un copac i
nlimea sa);
diferenierea dintre obiectul ca ntreg i prile sale componente (de exemplu: a
distinge ntre un copac i ramurile sale);
diferenierea diverselor clase de obiecte (de exemplu: clasa pietrelor i clasa
arborilor).
6.3 Metoda de analiz Coad-Yourdon
Coad i Yourdon descriu o metod AOO bazat pe cinci activiti majore:
70/135
identificarea claselor i obiectelor;
identificarea structurilor;
identificarea atributelor;
identificarea serviciilor;
identificarea subiectelor.
Puterea metodei const n descrierea scurt, concis i folosirea unor texte generale ca
surse de definiii. Un mare avantaj este meninerea aceleiai notaii att n faza de analiz ct
i n cea de proiectare.
6.3.1 Activitatea I: Identificarea claselor i obiectelor
Exist mai multe motive principale pentru care trebuie identificate clasele i obiectele:
gsirea unei reprezentri tehnice a sistemului mai aproape de modul n care
concepem lumea nconjurtoare;
se creeaz astfel o baz stabil pentru analiz i specificaii: clasele i obiectele
pentru un sistem de control al traficului aerian pot fi aceleai i peste cinci ani,
doar serviciile i atributele se pot modifica radical. Clasele i obiectele sunt
relativ stabile de-a lungul timpului, urmnd ca, la apariia modificrilor
ulterioare, ele s constituie o baz pentru reutilizare;
evitarea schimbrii reprezentrii de baz n momentul trecerii de la faza de
analiz la cea de proiectare. Aceast problem se rezolv prin utilizarea unei
reprezentri orientate obiect att n faza de analiz ct i n fazele de proiectare
i implementare.
Notaii:
O clas de baz, fr obiecte instaniate, va fi reprezentat astfel:

Figura 6-1 Clas fr instane
O clas cu obiecte instaniate va fi reprezentat astfel:

Figura 6-2 Clas cu instane
Numele clasei:
este o construcie substantival (engl. noun phrase", un singur substantiv sau
substantiv i adjectiv);
se alege innd cont de vocabularul standard al domeniului problemei. Folosirea
unei terminologii nefamiliare clientului l face s se simt frustrat i stnjenit;
se refer doar la un singur obiect al clasei;
trebuie s fie sugestiv;
71/135
se recomand s se scrie folosind litere mari i mici pentru a face mai uoar
citirea sa.
Numrul de clase n modelul AOO depinde de complexitatea domeniului problemei: 35
este media; 110 clase deja sunt prea multe, n acest caz, se recomand mprirea problemei n
subdomenii. De exemplu, dac avem nevoie de 100 de clase, domeniul poate fi mprit n 3-4
subdomenii, fiecare cu 25-35 de clase.
Odat identificate clasele candidate", ele trebuie examinate pentru a se decide dac vor
fi n final incluse n modelul orientat obiect. Exist o serie de criterii pentru aceast decizie:
Sunt toate aspectele identificate relevante pentru sistem? Poate fi descris orice
obiect al unei clase? Care sunt atributele lui poteniale? De exemplu, atributele
poteniale pentru un funcionar sunt: nume, parol, autorizaie. Altele, precum
nlimea, semne particulare, greutate, nu sunt relevante pentru sistem;
Este absolut necesar ca un obiect s execute anumite activiti?
Este caracterizat o clas prin mai multe atribute? O clas cu un singur atribut
este considerat suspect;
Este caracterizat o clas prin mai multe obiecte? O clas cu un singur obiect
este considerat suspect;
Se poate identifica un set de atribute aplicabile ntotdeauna tuturor obiectelor
clasei?
Toate clasele identificate trebuie s se concentreze asupra informaiilor i serviciilor
cerute de sistem. Nu se fac referiri la detalii de proiectare, dei e bine ca acestea s fie
reinute, notate, nc din aceast faz. E posibil ca echipa de proiectare s adauge noi clase i
obiecte care s realizeze procesarea cerut de proiectare. Se recomand realizarea analizei i
specificaiilor neinnd cont de o arhitectur specific software sau hardware a sistemului,
chiar dac clientul garanteaz c ea nu se schimb niciodat.
Trebuie evitat reinerea unor informaii care rezult din altele. De exemplu, nu are rost
s se rein vrsta persoanei dac sistemul deja a nregistrat data naterii. Trebuie luate n
considerare acele atribute i servicii din care apoi se pot obine rezultate derivate.
6.3.2 Activitatea a Il-a: Identificarea structurilor
Aceast activitate se refer la evidenierea structurilor de tip generalizare-specializare
(gen-spec") i ntreg-pri:
Structura gen-spec poate fi vzut ca aspect de difereniere ntre clase,
asemntor definiiilor utilizate de gndirea uman pentru organizarea
cunotinelor, cu gen proxim i diferene specifice. De exemplu: generalizarea
limbaj de programare i specializarea C+ + . Mai puin formal, corectitudinea
acestei structuri poate fi testat prin construcii de forma este un (o)" sau este
un fel de". Pentru exemplul de mai sus, verificarea va fi: C++ este un limbaj de
programare"'. n cadrul structurii gen-spec se aplic principiul motenirii;
Structura ntreg-pri evideniaz componena unui obiect. De exemplu: ntregul
limbaj de programare i partea sintax. Corectitudinea acestei structuri poate fi
testat prin construcii de forma are un (o)": un limbaj de programare are o
sintax, n cadrul structurii ntreg-pri se aplic mecanismul agregrii. Din
punct de vedere al implementrii, corespondentul este compunerea claselor.
6.3.2.1 Structura gen-spec
Notaia pentru structura gen-spec este urmtoarea:
72/135

Figura 6-3 Structura gen-spec
n vrf se afl o clas de generalizare, iar pe nivelele urmtoare clase de specializare
(liniile unesc clasele i nu obiectele). Punctul de ramificare a liniilor spre specializri se
reprezint printr-un semicerc. Fiecare clas-specializare este denumit astfel nct s aib un
neles de sine stttor. Numele cel mai potrivit este format din numele clasei generalizatoare
urmat de numele naturii specializrii. De exemplu, pentru generalizarea Senzor, sunt preferate
specializrile SenzorCritic i SenzorStandard fa de numele Critic i Standard.
n clasele specializate se noteaz numai atributele i serviciile caracteristice. Nu este
necesar menionarea atributelor i serviciilor motenite din clasa de baz. Dac sunt posibile
mai multe specializri, este util considerarea mai nti a celei mai simple i celei mai
complicate specializri, i apoi gsirea unei variante intermediare. Exemplu:
Considerm clasa Avion ca o generalizare. Ea poate fi specializat n mai multe moduri:
AvioaneCuReacie i AvioaneCuElice;
AvioaneCivile i AvioaneMilitare;
AvioaneCuAripiFixe i AvioaneCuAripiMobile;
AvioaneComerciale i AvioaneP articular e.
S considerm prima specializare (AvioaneCuReacie i AvioaneCuElice). Are sens
aceast specializare sens pentru domeniul problemei? Dac nu, atunci nu este necesar. Are
sistemul nevoie s recunoasc diferena dintre avioanele cu reacie i cele fr reacie? Sunt
responsabilitile sistemului diferite pentru fiecare din aceste dou specializri? Dac nu,
atunci acestea nu sunt necesare.
Exist ntr-adevr motenire, adic anumite atribute i servicii ale clasei Avion se aplic
tuturor avioanelor i apoi se specializeaz n atribute i servicii care se aplic doar celor cu
reacie i cu elice? Dac nu, specializarea nu are rost.
Dac singura diferen ntre AvionCuReacie i AvioaneCuElice este tipul avionului,
atunci se folosete doar clasa Avion cu un atribut pentru tipul avionului, putnd lua diverse
valori. Nu este necesar o structur gen-spec n acest caz.
Unul din criteriile construirii unei structuri gen-spec este reflectarea unei generalizri-
specializri n domeniul problemei. Aceste structuri nu trebuie construite doar pentru a
extrage atribute comune. Un exemplu eronat de structur gen-spec este urmtorul:
73/135
Localizare
Avion 1
Aeroport

Figura 6-4 Structur gen-spec eronat
6.3.2.2 Structura ntreg-parte
Notaia pentru structura ntreg-parte este urmtoarea:
Intreg
Parte 1
Parte 2
c,d
a, b
e ,f
g ,h

Figura 6-5Structur ntreg-parte
In partea superioar este reprezentat obiectul ntreg al clasei, iar n partea inferioar
pri ale acestui obiect. Triunghiul face distincia dintre ntreg i pri. Fiecare capt al liniei
este marcat cu un interval, indicnd numrul de pri pe care un ntreg le poate avea i
numrul de ntregi corespunztori unei pri, la orice moment de timp .
Exemple:
74/135
Motor
0,1
Avion
0,4

Figura 6-6 Structur ntreg-parte:
Avion-Motor n acest exemplu, un Avion este un ansamblu:
de O motoare (planor)
de cel mult 4 motoare
iar un Motor este o parte din:
nu neaprat dintr-un avion
cel mult un avion
Functionar
1
Organizatie
0,m

Figura 6-7 Structur ntreg-parte: Organizaie-Funcionar
Aici, o organizaie este o colecie:
posibil, fr funcionari
de cel mult m funcionari
75/135
iar un funcionar este membru al unei singure organizaii.
6.3.2.2.1 Strategii de identificare a structurilor ntreg-parte
Pentru identificarea potenialelor structuri ntreg-parte, se consider aspectele:
ansamblu-pri
container-coninut
colecie-membri
n plus, se recomand studiul rezultatelor AOO precedente, pentru evidenierea
eventualelor structuri de acest tip, care ar putea fi refolosite. Exemple:
Motor
0,1
Avion
0,4

Figura 6-8 Structur ntreg-parte: ansamblu-pri
Pilot
0,n
Avion
0,m

Figura 6-9 Structur ntreg-parte: container-coninut
76/135
In acest exemplu, avionul este considerat un container, pilotul gsindu-se nuntru.
Totui, pilotul nu aparine avionului, nu este o parte a sa, precum motorul. Dac domeniul
problemei i responsabilitile sistemului trebuie s asigneze un pilot unui avion, atunci o
clas Pilot este necesar. Exemplu:
Functionar
1
Organizatie
0,m

Figura 6-10Structur ntreg-parte: colecie-membri
O organizaie poate fi considerat o colecie de funcionari.
6.3.2.2.2 Verificarea structurilor ntreg-parte
Pentru fiecare obiect considerat ntreg se verific, pentru fiecare din prile sale, dac:
acea parte aparine domeniului problemei i intereseaz sistemul din punct de
vedere al serviciilor. De exemplu, dac domeniul problemei se refer la
Serviciul meselor, atunci partea Motor pentru ntregul Avion nu are sens. Dac
ns domeniul problemei este Transportul aerian, atunci ea are sens;
acea parte captureaz mai mult dect o singur valoare de stare. Dac
responsabilitile sistemului includ doar cunotine despre starea avionului
(funcional sau nefuncional) sau starea motorului, atunci nu e necesar o clas
Motor. Este suficient s se prevad un atribut Stare n clasa Avion. Dac ns
sistemul trebuie s tie mai mult despre motor (model, numr de serie, data
fabricaiei etc.), atunci este necesar o clas Motor.
Considernd apoi fiecare obiect ca o parte potenial dintr-un ntreg, se verific
utilitatea prezenei lui n acelai mod.
6.3.3 Activitatea a IlI-a: Identificarea atributelor
Un atribut este o proprietate, calitate sau caracteristic pentru care fiecare obiect al unei
clase are o anumit valoare. Atributele adaug detalii abstractizrilor de tip clas sau
structur. Ele descriu valori ncapsulate n obiect i vor fi manipulate exclusiv de ctre
serviciile acelui obiect. Atributele i serviciile obiectului sunt tratate ca un ntreg. Dac o alt
parte a sistemului dorete s acceseze atributele unui obiect, o poate face doar prin
specificarea unui mesaj de conectare, corespunztor serviciului definit de obiect. De-a lungul
77/135
timpului, domeniul claselor rmne relativ stabil, n schimb, atributele sunt mult mai
susceptibile de a se modifica. Se recomand definirea atributelor pe baza urmtoarei strategii:
identificarea atributelor;
poziionarea atributelor;
identificarea conexiunii instanelor;
verificarea cazurilor speciale;
specificarea atributelor.
6.3.3.1 Identificarea atributelor
Pentru fiecare clas, urmrim:
cum sunt descrise obiectele n general;
cum sunt descrise obiectele n domeniul problemei;
cum sunt descrise obiectele n contextul responsabilitilor sistemului;
ce anume trebuie memorat n timp;
care sunt strile n care se poate afla obiectul;
studiul rezultatelor anterioare ale AOO n probleme similare pentru reutilizarea
atributelor.
Fiecare atribut trebuie s captureze un concept atomic (o singur valoare sau un grup de
valori, avnd acelai neles, ca de exemplu nume, format din nume i prenume, sau adres,
compus din strad, numr, cod potal, ora, ar).
6.3.3.2 Poziionarea atributelor
Fiecare atribut va fi pus n clasa pe care o descrie mai bine. De exemplu, n sistemul de
nregistrare a unui vehicul, culoarea acestuia este foarte important. Ea este reinut de sistem
la momentul nregistrrii vehiculului. Este deci culoare un atribut al clasei
Evenimentnregistrare sau al clasei Vehicul (Rspunsul corect este: Vehicul.)
Pentru clasele care prezint o structur gen-spec, atributul se poziioneaz n cel mai de
sus punct al structurii n care rmne aplicabil pentru toate specializrile sale. Dac un atribut
se aplic pe un nivel ntreg de specializri, atunci este mutat pe nivelul generalizator
corespunztor.
6.3.3.3 Identificarea conexiunilor instanelor
O conexiune a instanelor e un model al maprilor ntre domeniile problemelor
obiectelor. Este n strns legtur cu structurile ntreg-parte.
Notaie
1
0,m

Figura 6-11 Conexiunea instanelor
Conexiunea instanelor e reprezentat printr-o linie care unete obiectele. Fiecare obiect
are o cantitate (m) sau interval (m,n), marcate pe conexiune, reflectnd restriciile
conexiunilor cu alte obiecte. Limitele intervalului au urmtoarele semnificaii:
Limita inferioar
78/135
o O, dac este o conexiune opional; o > l, dac e o conexiune obligatorie;
Limita superioar
o l, dac este o singur conexiune; o > l, dac sunt conexiuni multiple.
6.3.3.4 Verificarea cazurilor speciale
Pentru fiecare atribut se verific dac exist cazuri cnd nu este aplicabil. De exemplu,
clasa Vehicul poate avea atributul Traciune cu valorile: benzin, motorin, electric etc. Dar
pentru anumite vehicule, care nu au motor, acest atribut poate avea valoarea Inaplicabil".
Dac exist un astfel de caz, trebuie reanalizat strategia gen-spec, verificnd dac nu mai
sunt necesare structuri gen-spec care n-au fost cuprinse n model.
n continuare, se verific clasele care au un singur atribut, n acest caz, fie clasa are un
singur atribut pentru c aa impun responsabilitile sistemului (figura 12), fie atributul nu
este bine poziionat, el aparinnd unei alte clase (figura 13). Verificnd domeniul problemei,
se constat c n loc de dou clase (Garanie i Adres) se poate folosi doar una singur
(Garanie).
Functionar
Nume

Figura 6-12 Plasarea unui singur atribut ntr-o clas pe care o descrie
Garantie
Nume
Cantitate
Adresa
Adresa
Garantie
Nume
Cantitate
Adresa

Figura 6-13 Plasarea greit a unui atribut
6.3.3.5 Specificarea atributelor
Pentru specificarea atributelor, exist urmtoarele recomandri:
Numele atributelor trebuie s fie sugestive, din domeniul problemei;
Specificarea unui atribut trebuie nsoit de o sumar descriere a sa;
Specificarea unui atribut trebuie nsoit de eventuale restricii:
o unitate de msur, intervale;
o precizie;
o valoare implicit;
79/135
o n ce condiii sunt permise serviciile de creare i acces;
o n ce msur este afectat de valorile altor atribute;
Exemplu de specificare a atributelor:
Clasa Senzor
Atribut Model: numrul modelului
Atribut Secvenalnit: secvena de iniializare
Atribut Conversie: const din factori de scalare i uniti de msur
Atribut Interval: intervalul de valori pentru senzor
Atribut Adres: adresa acestui senzor
Atribut Prag: valoare de prag la care se semnaleaz alarma
Atribut Stare: starea senzorului (on, off, standby)
Atribut Valoare: cea mai recent valoare a senzorului
Unele atribute i schimb foarte rar valoarea (Model, Secvenelnit, Conversie), altele
i-o schimb mai des (Interval, Adres, Prag, Stare), iar altele sunt dinamice (Valoare).
Atributul Valoare este rezultatul citirii unei valori n uniti fizice (de exemplu voli) i al
conversiei sale n uniti standard de msur. Poate fi tratat ca o valoare recalculabil i n
acest caz nu e nevoie de un atribut Valoare. Dar e posibil ca sistemul s necesite cunoaterea
acestei valori n orice moment, indiferent de starea senzorului (chiar dac senzorul este n
starea standby, n care valoarea nu poate fi citit i deci calculat). Este posibil deci, ca
atributul Valoare s nu poat fi recalculat de fiecare dat i atunci se justific prezena sa.
6.3.4 Activitatea a IV-a: Identificarea serviciilor
n analiza orientat obiect se recomand ca identificarea serviciilor s se realizeze dup
identificarea claselor, structurilor i atributelor. Serviciul este definit ca fiind o operaie
specific unui obiect. Pe lng evidenierea acestor servicii, se mai pune problema definirii
comunicaiilor necesare ntre obiecte. Strategia definirii serviciilor const n urmtoarele
etape. Mai nti se identific strile posibile ale obiectelor, date de valorile atributelor lor.
Pentru a identifica starea unui obiect:
se examineaz valorile poteniale ale atributelor;
se determin dac sistemul are comportri diferite pentru aceste valori;
se examineaz rezultatele AOO anterioare.
Exemplu: care din atributele sistemului Senzor reflect o schimbare n starea obiectului?
Atributele sistemului sunt cele prezentate mai sus. Pentru acest sistem valorile atributelor
Model, Secvenalnit, Conversie, Interval, Adres, Prag nu implic o modificare a comportrii
sistemului, ns atributul Stare reflect o schimbare n comportarea sistemului. Valorile sale
sunt: on, off i standby. Diagramele strilor obiectelor prezint diferitele stri ale sistemului n
timp.
Notaia pentru diagramele strilor obiectelor:

Figura 6-14 Diagrama strilor obiectelor
Exemplu:
80/135
Stare =off
Stare =standby
Stare =on

Figura 6-15 Diagrama strilor obiectului pentru sistemul Senzor
n acest exemplu, sgeata din vrf indic starea iniial. Sunt prezentate doar strile i
tranziiile legale.
Apoi se trece la identificarea serviciilor propriu-zise. Exist dou tipuri de servicii:
servicii algoritmic-simple;
servicii algoritmic-complexe.
Serviciile algoritmic-simple se aplic fiecrei clase, sunt implicite i nu sunt
reprezentate pe stratul serviciilor. Exemple tipice de astfel de servicii sunt: crearea obiectelor
(constructorii), accesul la obiecte (operaii get/set) i distrugerea obiectelor (destructorul).
Majoritatea operaiunilor unui sistem (80% - 95%) se concentreaz n serviciile algoritmic-
simple.
Serviciile algoritmic-complexe sunt i ele de dou tipuri: de calcul (calculeaz un
rezultat folosind valorile unor atribute) i de monitorizare (supravegheaz un sistem sau
dispozitiv extern, trateaz intrrile i ieirile acestuia, achiziioneaz i controleaz date).
Tot n cadrul identificrii serviciilor trebuie precizate i conexiunile prin mesaje ntre
obiecte, adic modurile n care un obiect transmitor trimite un mesaj ctre un obiect receptor
pentru ca acesta din urm s execute o anumit prelucrare. Prelucrarea este denumit n
specificarea serviciilor transmitorului i definit m specificarea serviciilor receptorului.
Notaie:
Transmitator Receptor

Figura 6-16 Conexiune prin mesaje
Receptorul primete mesajul, execut operaiunea corespunztoare i returneaz un
rezultat transmitorului.
Pentru conexiuni prin mesaje de la un obiect spre mai multe obiecte, exist urmtoarea
notaie:
Transmitator

Figura 6-17 Conexiune prin mesaje spre mai multe obiecte
Interaciunile dintre factorul uman i sistem sunt i ele reprezentate n modelul AOO:
81/135

Figura 6-18 Interaciune cu factorul uman
Pentru a evidenia conexiunile prin mesaje ntre obiecte, se pun urmtoarele ntrebri
pentru fiecare obiect:
de serviciile cror alte obiecte are nevoie? Se traseaz cte o sgeat ctre
fiecare din aceste obiecte;
ce alte obiecte au nevoie de serviciile lui ? Se traseaz cte o sgeat dinspre
fiecare din aceste obiecte;
se urmrete conexiunea prin mesaj spre obiectul destinatar i se repet aceleai
ntrebri;
se examineaz rezultatele AOO anterioare.
6.3.5 Activitatea a V-a: Identificarea subiectelor
In AOO, termenul de subiect este un mecanism pentru ghidarea cititorului (analist,
manager, expert, utilizator, client) n nelegerea unui model de analiz foarte mare i
complex. Subiectele ofer o imagine de perspectiv asupra unui model complex.
Fiecare clas din vrful fiecrei structuri se asigneaz unui subiect. Fiecare clas care nu
face parte din nici o structur se asigneaz, de asemenea, unui subiect. Se recomand studiul
rezultatelor anterioare ale AOO pentru probleme similare pentru a se utiliza subiecte
identificate deja.
Subiectele se rafineaz apoi utiliznd subdomeniile problemei. De fapt, se aplic
principiul ntreg-parte pe domeniul problemei. Rafinarea ia n consideraie interdependenele
i interaciunile minimale ntre subiecte. Interdependenele sunt exprimate de structuri
atribute, iar interaciunile sunt exprimate de servicii.
Un subiect se reprezint printr-un dreptunghi, fiind etichetat n interior cu un nume i un
numr i coninnd i lista claselor care fac parte din acel subiect. Practic, pentru modele
foarte complexe, subiectele se pot reprezenta n trei moduri:
Subiecte ne-expandate: doar dreptunghiul cu numele i numrul lor:

Figura 6-19 : Subiect ne-expandat
Subiecte parial expandate, coninnd lista claselor componente:
82/135
1. Subiectul 1
Clasa 1
Clasa 2
2. Subiectul 2
Clasa 3
Clasa 4

Figura 6-20 Subiect parial expandat
Subiecte total expandate, cnd se reprezint mpreun cu alte straturi ale modelului AOO, prin
zone partiionate i numerotate. In interiorul dreptunghiurilor numerotate vor fi incluse clasele
cu notaia complet: nume, atribute, servicii, eventual i cu legturile dintre ele:

Figura 6-21 Subiect total expandat
O clas poate face parte din mai multe subiecte, cnd acest lucru este necesar pentru
ghidarea cititorului. Subiectele pot conine la rndul lor alte subiecte, furniznd astfel o hart
multinivel. n general, subiectele sunt necesare pentru modele relativ mari, avnd aproximativ
30-40 de clase. Identificarea subiectelor se va face abia dup ce clasele au fost identificate i
bine nelese.
6.4 Concluzii
n acest curs au fost prezentate mai nti chestiuni legate de ingineria cerinelor:
definirea cerinei, extragerea, identificarea i specificarea cerinelor. Apoi a fost descris
problematica general a analizei orientate obiect, insistndu-se pe metoda de analiz Coad-
Yourdon i pe activitile ei specifice: identificarea claselor i obiectelor, a structurilor,
atributelor, serviciilor i subiectelor.
83/135
7 Proiectarea orientat obiect
7.1 Procesul proiectrii sistemelor software
Proiectarea este un proces creativ, care necesit o oarecare experien practic,
acumulat n timp. Acest proces implic o serie de pai:
studiul i nelegerea problemei;
identificarea mai multor soluii posibile i evaluarea fiecreia din ele. Alegerea
ei depinde de experiena proiectantului, simplitatea acesteia, valabilitatea
componentelor reutilizabile;
descrierea fiecrei abstractizri a fiecrei soluii, nainte de crearea
documentaiei formale, ar putea fi necesar ca proiectantul s pregteasc o
descriere informativ a proiectului pentru a fi examinat n detaliu, n felul
acesta, omisiunile i erorile posibile ar putea fi eliminate nainte ca proiectul s
fie documentat.
Activitile eseniale n cursul proiectrii sunt urmtoarele:
Proiectarea arhitectural: subsistemele ntregului sistem sunt identificate i
documentate;
Specificarea abstract: pentru fiecare subsistem, se prezint o specificare
abstract a serviciilor i a constrngerilor sub care acestea opereaz;
Proiectarea interfeei: pentru fiecare subsistem, interfaa cu celelalte
subsisteme este proiectat i documentat;
Proiectarea componentelor: serviciile furnizate de un subsistem sunt
partiionate ntre componentele acelui subsistem;
Proiectarea structurilor de date: structurile de date utilizate n implementarea
sistemului sunt proiectate n detaliu i specificate.
Proiectarea algoritmilor: algoritmii utilizai pentru a furniza servicii sunt
proiectai n detaliu i specificai. Acest proces se repet pentru fiecare subsistem
pn cnd componentele identificate pot fi mapate direct n componentele
limbajului de programare.
7.2 Caracteristicile unei proiectri corecte
Rezultatul principal a fazei de proiectare este un model al codului care arat cum este
implementat sistemul i o diagram a dependenelor dintre module, care arat cum va fi
sistemul divizat n module i cum interacioneaz acestea. Pentru module mai dificile, se
includ specificaii speciale.
Ce nseamn o proiectare corect? Desigur, nu exist o modalitate simpl i obiectiv
care s spun c o proiectare este mai bun dect alta. Dar exist unele proprieti cheie care
pot fi utilizate pentru a msura calitatea proiectrii, n mod ideal, o proiectare ar trebui s aib
toate aceste caracteristici. In practic, trebuie fcute compromisuri ntre ele. Aceste
caracteristici sunt extensibilitatea, sigurana i eficiena.
7.2.1 Extensibilitatea
Proiectarea trebuie s poat suporta noi funcii. Un sistem perfect din toate celelalte
puncte de vedere, dar n care nu poate fi integrat nici o schimbare sau mbuntire, nu este
de prea mare folos. Chiar dac nu exist cerine pentru trsturi suplimentare, probabil vor
exista schimbri n domeniul problemei care vor necesita schimbri n program.
Suficiena modelului: Modelul problemei trebuie s reflecte caracteristicile suficiente
ale problemei. Un obstacol des ntlnit atunci cnd se dorete extinderea unui sistem este
84/135
faptul c anumite noiuni nu sunt exprimate n cod i deci funcionalitile corespunztoare
care trebuie adugate nu-i gsesc locul n program. Un exemplu n acest sens poate fi vzut
n Microsoft Word. Acesta a fost proiectat plecnd de la premisa c structura fundamental de
organizare a unui document este paragraful. De aceea, structurile ierarhice pot fi introduse cu
greutate i, ca efect, divizarea documentului n seciuni nu se face foarte eficient. Optimizarea
modelului nu trebuie s elimine substructurile care numai par nefolositoare. Abstractizrile nu
trebuie s nlocuiasc structurile concrete dect dup o analiz serioas.
Localizarea: Chiar dac programul cuprinde noiuni suficiente pe baza crora s poat fi
adugate noi funcionaliti, acestea trebuie introduse fr a modifica tot codul. De aceea,
proiectarea trebuie s fie localizat, adic problemele diferite trebuie separate n regiuni
distincte ale codului. Modulele trebuie decuplate ct mai mult, astfel nct o schimbare s nu
antreneze modificri n cascad.
7.2.2 Sigurana
Sistemul trebuie s aib un comportament sigur, care nu presupune doar lipsa
prbuirilor" sau a pierderii datelor, ci i faptul c trebuie s ruleze corect, aa cum se
ateapt utilizatorul. Nu e suficient ca sistemul s ndeplineasc o specificaie obscur, ci
trebuie s ndeplineasc o specificaie care poate fi neleas uor de utilizator, astfel nct
acesta s poat prezice comportamentul sistemului. Pentru sistemele distribuite, este
important disponibilitatea. Pentru sisteme de timp real, este important sincronizarea.
Criteriile de stabilire a siguranei variaz n funcie de tipul aplicaiei. Conexiunile telefonice
automate trebuie s fie n permanen disponibile i s fie foarte sigure, uneori pot fi
suprancrcate, iar alte ori mai au loc rutri eronate de mesaje, ntrzieri mici ntr-un program
de trimitere a email-urilor nu prea conteaz, ns aceleai ntrzieri se pot dovedi catastrofale
pentru un controler de reactor nuclear.
Modelarea atent. Sigurana nu poate fi introdus uor ntr-un sistem existent. Cheia
realizrii de produse sigure este modelarea i dezvoltarea atent. Problemele serioase n
sistemele critice n general nu apar din erori de programare, ci din erori de analiz a
problemei. Programatorii pur i simplu nu iau n calcul o anumit proprietate a mediului n
care este plasat sistemul. De exemplu, incidentul din 1993 cnd un avion Airbus a ncercat s
aterizeze pe timp de furtun pe aeroportul din Varovia, ns frnele nu au funcionat, avionul
a ieit de pe pist i a luat foc.
Analiza i testarea. Orict de atent ar fi cineva, este foarte probabil c va face pn la
urm greeli. Din punct de vedere al costului, cea mai bun soluie este verificarea codului de
ctre alt persoan. O testare mai detaliat i care poate descoperi erori mai subtile poate fi
realizat cu un instrument automat.
7.2.3 Eficiena
Sistemul trebuie s consume resurse n limite rezonabile. Eficiena depinde de context.
O aplicaie care ruleaz pe un telefon celular nu are disponibil la fel de mult memorie ca
una care ruleaz pe un PC. Pentru determinarea eficienei unui program, se analizeaz n
general timpul de execuie i spaiul necesar. Pe lng timpul de execuie, este la fel de
important i timpul necesar dezvoltrii, care este legat de costul aplicaiei. O proiectare care
poate fi implementat mai economic poate fi preferabil uneia care ndeplinete toate
metricile de calitate dar este mai scump.
Modelul obiectului. Alegerea modelului obiectelor din cod este crucial, deoarece este
greu de schimbat. De aceea, intele de performan trebuie considerate nc de la nceput n
faza de proiectare.
Evitarea tendeniozitii. Cnd se dezvolt modelul obiectelor pentru problem, trebuie
excluse orice preocupri legate de implementare. Un model care conine detalii de
85/135
implementare este tendenios (engl. biased"), deoarece favorizeaz o anumit implementare.
Rezultatul este excluderea unor posibiliti de implementare care se pot dovedi n final mai
eficiente.
Optimizarea, n general, optimizare" este o denumire greit, deoarece nseamn
creterea performanelor n detrimentul altor caliti, cum ar fi claritatea structurii. Dac
optimizarea nu este tratat cu atenie, putem risca s ajungem la un sistem mai prost din toate
punctele de vedere. Sunt recomandate numai optimizrile care vor avea efecte foarte
puternice, de exemplu o modificare care reduce complexitatea de timp de la O(n) la timp
constant. Optimizrile unor aspecte minore trebuie evitate dac presupun o scdere n
claritatea proiectrii.
7.3 Proiectarea orientat obiect
Dup cum tim, faza de proiectare se afl situat ntre analiz i implementare. Toate
aceste faze fac parte din procesul de dezvoltare orientat obiect. Aa cum am vzut n cursul
precedent, analiza orientat obiect se refer la dezvoltarea unui model orientat obiect al
domeniului aplicaiei. Obiectele identificate reflect entiti i operaii asociate cu problema
care trebuie rezolvat. Proiectarea orientat obiect privete dezvoltarea unui model orientat
obiect al sistemului software care trebuie s implementeze cerinele identificate. Programarea
orientat obiect urmrete implementarea (punerea n practic a) proiectrii software folosind
un anumit limbaj de programare orientat obiect.
Continund faza de analiz orientat obiect, proiectarea orientat obiect este o strategie
n care sistemul se gndete n termeni de obiecte", n loc de operaii i funcii. Programul nu
este proiectat ca o mulime de funcii care schimb date prin parametri i memorie comun
(variabile globale), ci ca o mulime de obiecte care interacioneaz. Obiectele i pstreaz
starea intern i i definesc operaiile pe baza acesteia. Prin ascunderea informaiilor despre
reprezentarea strii, ei limiteaz accesul exterior la starea intern. Aadar, caracteristicile
proiectrii orientate obiect sunt urmtoarei e:
a) sistemul este proiectat ca o mulime de obiecte care interacioneaz, i
gestioneaz propria stare intern i ofer servicii altor obiecte;
b) obiectele sunt create prin instanierea unei clase care definete atributele i
operaiile asociate obiectului; mai multe obiecte ale aceleiai clase pot coexista
n acelai program;
c) clasele sunt abstractizri ale lumii reale sau entiti care ncapsuleaz
informaii de stare i care definesc un numr de servicii care creeaz,
acceseaz sau modific starea;
d) obiectele sunt entiti independente n care reprezentarea strii poate fi
modificat fr a afecta alte clase din sistem;
e) funcionalitatea sistemului este dat de serviciile asociate fiecrui obiect;
obiectele interacioneaz prin apelarea serviciilor definite de alte obiecte;
f) nu exist zone de memorie comun; obiectele comunic prin apeluri de servicii
i nu prin variabile partajate; nu exist posibilitatea ca o component s fie
afectat de schimbarea unei informaii partajate i deci modificrile sunt mai
uor de implementat;
g) obiectele pot fi distribuite i pot fi executate secvenial sau paralel; deciziile
asupra paralelismului nu trebuie luate nc de la nceputul procesului de
proiectare.
7.4 Etapele proiectrii orientate obiect
Procesul general al proiectrii orientate obiect cuprinde mai multe etape:
86/135
nelegerea i definirea contextului n care va evolua sistemul i a modului n
care acesta va fi utilizat;
proiectarea arhitecturii sistemului;
identificarea principalelor obiectelor din sistem;
dezvoltarea modelelor de proiectare;
specificarea interfeelor obiectelor.
Aceste etape nu trebuie gndite ntr-o ordine strict, ele se ntreptrund i se
influeneaz reciproc. Pe msur ce sunt realizate modelele obiect, activitile de mai sus
modific treptat arhitectura sistemului. Proiectarea nu este un proces simplu i bine structurat.
In realitate, se propun i se rafineaz soluii pe msur ce se adun mai multe informaii, se
revine asupra unor decizii dac acestea se dovedesc greite; uneori se exploreaz n detaliu
toate opiunile, alteori detaliile sunt ignorate pentru a fi considerate mai trziu n cadrul
procesului.
7.4.1 Contextul sistemului i modelele de utilizare
Prima etap a procesului de proiectare software este nelegerea relaiilor dintre sistemul
proiectat i mediul su extern. Aceasta va determina alegerea funcionalitilor necesare i
structurarea lor astfel nct sistemul s poat comunica eficient cu mediul. Contextul
sistemului i modelul de utilizare a sistemului reprezint dou modele complementare ale
relaiei dintre sistem i mediu:
contextul sistemului este un model static care descrie celelalte sisteme din
mediu;
modelul de utilizare a sistemului este un model dinamic care descrie
interaciunea dintre sistem i mediu.
7.4.2 Proiectarea arhitecturii
Dup ce au fost definite interaciunile dintre sistem i mediu, aceste informaii pot fi
utilizate ca baz pentru proiectarea arhitecturii sistemului. Desigur, informaiile din etapa
precedent trebuie combinate cu unele cunotine generale despre principiile proiectrii
arhitecturii i cu unele cunotine detaliate despre domeniul problemei.
O regul euristic spune c ntr-un model de arhitectur nu trebuie incluse mai mult de
apte entiti fundamentale. Fiecare din aceste entiti poate fi apoi descris separat, dar,
bineneles, depinde de proiectant dac vrea s prezinte n arhitectur structura tuturor
entitilor sistemului.
De exemplu, arhitectura unui agent de corectare lexical (spell-checker) poate fi
urmtoarea:

Figura 7-1 Exemplu de arhitectur: agent spell-checker
87/135
7.4.3 Identificarea obiectelor
In acest stadiu al proiectrii, deja s-au conturat unele idei despre obiectele eseniale
pentru sistem. Obiectele i clasele identificate n faza de analiz sunt verificate i rafinate
pentru a se potrivi n programul care urmeaz a fi realizat.
O tehnic de identificare a obiectelor este utilizarea unei abordri comportamentale.
Proiectantul ncearc s neleag mai nti comportamentul general al sistemului.
Comportamentelor diferite le corespund pri diferite din sistem. Mai trebuie vzut cine
iniiaz i particip n aceste comportamente. Participanii cu rol semnificativ sunt recunoscui
drept obiecte.
Alt tehnic se bazeaz pe analiza scenariilor. Diferitele scenarii ale utilizrii sistemului
sunt identificate i analizate pe rnd. Pentru fiecare scenariu se identific obiectele necesare,
mpreun cu atributele i serviciile acestora.
7.4.4 Modele de proiectare
Modelele de proiectare arat clasele i obiectele n cadrul sistemului, precum i relaiile
dintre acestea. Ele reprezint puntea de legtur ntre cerinele sistemului i implementarea
sistemului. De cele mai multe ori, exist cerine conflictuale pentru modele. Ele trebuie s fie
abstracte pentru ca detaliile nesemnificative s nu ascund relaiile cu cerinele sistemului.
Totui, ele trebuie de asemenea s includ suficiente detalii pentru ca programatorii s poat
lua deciziile de implementare corespunztoare.
O soluie a acestei probleme este dezvoltarea de modele diferite la diferite nivele de
detaliu. Cnd exist legturi strnse ntre inginerii de cerine, proiectani i programatori,
modelele abstracte sunt suficiente. Decizii specifice de proiectare pot fi fcute pe msur ce
sistemul este implementat. Cnd legturile dintre echipele implicate sunt indirecte (de
exemplu, cnd sistemul este proiectat de o parte a unei organizaii i implementat n alt
parte), sunt necesare modele mai detaliate. Detalierea modelului depinde i de tipul de sistem
dezvoltat. Un sistem simplu de prelucrare secvenial a datelor va fi proiectat ntr-un mod
diferit fa de un sistem integrat de timp real i deci vor fi necesare modele de proiectare
diferite. In general, exist dou tipuri de modele de proiectare care descriu o proiectare
orientat obiect:
modelele statice, care descriu structura static a sistemului n termenii claselor
sistemului i ai relaiilor dintre ele; relaiile importante care trebuie documentate
n aceast etap sunt: relaiile de generalizare, relaiile folosete/este folosit de,
relaiile de compunere etc.;
modelele dinamice, care descriu structura dinamic a sistemului, cu
interaciunile dintre obiectele sistemului (nu dintre clase); interaciunile care
trebuie documentate aici sunt serviciile solicitate de obiecte i modul n care
starea sistemului este influenat de acestea.
7.4.5 Specificarea interfeelor obiectelor
O parte important a procesului de proiectare este specificarea interfeelor dintre
diferitele componente ale proiectrii. Ea este foarte important i deoarece permite
posibilitatea ca obiectele i celelalte componente s fie proiectate n paralel. Odat ce a fost
specificat interfaa, cei care dezvolt celelalte obiecte pot considera c aceasta este interfaa
care va fi implementat.
Proiectanii trebuie s evite informaiile privind reprezentarea interfeei. Reprezentarea
trebuie s fie ascuns, iar pentru accesarea i actualizarea datelor trebuie furnizate servicii ale
obiectelor. Dup cum tim, dac reprezentarea este ascuns, ea poate fi schimbat fr a
afecta obiectele care folosesc atributele respective, n acest fel, design-ul devine mai uor de
88/135
ntreinut. De exemplu, reprezentarea unei stive ca vector poate fi schimbat cu o reprezentare
de tip list fr s afecteze celelalte obiecte care folosesc stiva.
Intre obiecte i interfee nu exist n mod necesar o relaie simpl 1:1. Acelai obiect
poate avea mai multe interfee care semnific perspective diferite asupra serviciilor pe care le
furnizeaz. De exemplu, n Java sau C#, interfeele sunt declarate separat de obiecte iar
obiectele implementeaz" interfeele. De asemenea, un grup de obiecte poate fi accesat
printr-o singur interfa.
Proiectarea interfeelor obiectelor trebuie s specifice semnturile i semantica
serviciilor asigurate de un obiect sau de ctre un grup de obiecte.
7.5 Metoda de proiectare Coad-Yourdon
Metoda de proiectare orientat obiect Coad-Yourdon const n 4 componente:
componenta domeniului problemei;
componenta interaciunii cu factorul uman;
componenta coordonrii task-urilor;
componenta coordonrii datelor.
Fiecare component este construit din clase i obiecte. Componenta domeniului
problemei se bazeaz pe modelul logic construit n timpul analizei orientate obiect. Dac
sistemul va fi implementat ntr-un limbaj de programare orientat obiect, atunci va exista o
coresponden de l la l ntre clasele i obiectele domeniului problemei. Componenta
interaciunii cu factorul uman coordoneaz mesajele dinspre i nspre utilizator. Componenta
coordonrii task-urilor se refer la multiplele fire de execuie existente ntr-un sistem.
Componenta coordonrii datelor furnizeaz infrastructura pentru nregistrarea i regsirea
datelor. Corespunztoare acestor patru componente, metoda identific patru activiti:
proiectarea componentei domeniului problemei;
proiectarea componentei interaciunii cu factorul uman;
proiectarea componentei coordonrii task-urilor;
proiectarea componentei coordonrii datelor.
7.5.1 Activitatea I: Proiectarea componentei domeniului problemei
n aceast prim activitate, componentele domeniului rezultate din analiz sunt utilizate
i suplimentate. Deoarece se bazeaz pe reutilizarea claselor identificate de faza de analiz,
modificrile trebuie meninute pe ct posibil la un nivel redus.
Apoi clasele specifice domeniului problemei sunt grupate mpreun prin adugarea unei
clase rdcin. Viznd direct limbajul de programare care va fi utilizat pentru implementare,
poate fi necesar modificarea structurilor gen-spec pentru a se potrivi nivelului de motenire
oferit de limbajul ales.
Dac structurile gen-spec ale modelului analizei orientate obiect includ moteniri
multiple, trebuie fcute cteva modificri ale acestora atunci cnd se va utiliza un limbaj de
programare orientat obiect care nu suport mecanismul motenirii sau care nu suport dect
motenirea simpl. Dou tipuri de motenire multipl sunt prezentate n figurile 2 i 3.
89/135

Figura 7-2 Diamantul mic
Radacina
Clasa A
Clasa AB1
Clasa B
Clasa AB2 Clasa AB1B2
Clasa B2 Clasa B1

Figura 7-3 Diamantul mare
Chiar dac limbajul permite motenire multipl (de exemplu C++), se recomand
evitarea acesteia datorit complexitii pe care o presupune. In cazul limbajelor care suport
90/135
doar motenire simpl (Java, C#) se pot aplica metode de a transforma o motenire multipl
ntr-o motenire simpl:

Figura 7-4 Formarea unor ierarhii separate, mapate ntre ele prin structuri ntreg-parte
Ierarhia multipl poate fi transformat direct ntr-o ierarhie simpl, caz n care anumite
atribute i servicii vor fi repetate n clasele specializate.
Clasa A
Clasa AB1 Clasa AB2 Clasa AB1B2

Figura 7-5 Acomodarea cu limbaje care nu suport motenire multipl
Dac limbajul nu suport mecanismul de motenire, fiecare structur gen-spec se va
descompune n clasele componente.
Clasa AB1 Clasa AB2 Clasa AB1B2

Figura 7-6 Acomodarea cu limbaje care nu suport motenire
91/135
Urmtorul pas n schimbarea componentelor domeniului problemei este mbuntirea
aspectelor de performan. Viteza poate fi mbuntit prin msurarea vitezei efective a
codului i prin optimizarea acestuia. Creterea vitezei e necesar de obicei cnd ntre obiecte
exist un trafic prea mare de mesaje. In acest caz, se combin dou sau mai multe clase.
Singurul mod de a ti dac aceste modificri contribuie la creterea vitezei, este prin msurare
i observare. Viteza perceput de utilizator poate fi mrit prin memorarea rezultatelor
intermediare (engl. caching").
Tot n aceast activitate se ia n calcul suportul pentru componenta de coordonare a
datelor. Fiecare obiect se poate stoca singur sau poate fi salvat de componenta de coordonare
a datelor. In ambele abordri, la componenta domeniului problemei trebuie adugate atribute
i servicii specifice.
Pentru facilitarea proiectrii i programrii, componentele de nivel sczut pot fi izolate
n clase separate. Ultimul pas n proiectarea componentei domeniului problemei este
verificarea completrilor aduse la rezultatele fazei de analiz orientat obiect.
7.5.2 Activitatea a Il-a: Proiectarea componentei interaciunii cu factorul
uman
Pentru aceast activitate se recomand prototipizarea. Activitatea ncepe cu clasificarea
persoanelor care vor utiliza sistemul, pe baza unor criterii precum:
nivel de pregtire;
nivel de organizare;
apartenena la diferite grupuri (de exemplu: funcionar sau client). Fiecare
categorie definit trebuie descris, incluzndu-se un scenariu de task-uri. Pentru
fiecare categorie, trebuie notate urmtoarele:
ce este;
scopul;
caracteristici (de exemplu: vrst, educaie etc.);
factori critici de succes (necesiti/dorine, preferine/antipatii/tendine
subiective);
nivel de pregtire;
scenarii ale task-urilor.
Apoi trebuie proiectat o ierarhie de comenzi pentru sistem prin studierea sistemelor
existente de interaciune cu factorul uman. Pentru rafinarea ierarhiei, trebuie considerate
urmtoarele:
ordonarea serviciilor;
partiionarea modelelor ntreg-parte i verificarea dimensiunilor structurii de
comenzi (lime: numrul de categorii de opiuni, adncime: numrul de nivele
pentru fiecare categorie de opiuni);
minimizarea numrului de pai necesari pentru efectuarea unui serviciu.
n continuare se proiecteaz detaliat interaciunea, dup urmtoarele criterii:
consistena;
minimizarea numrului de pai;
acordarea de feedback prompt i semnificativ utilizatorilor;
asigurarea funciilor undo";
minimizarea rolului capacitii de memorare a utilizatorilor pentru reamintirea
opiunilor;
minimizarea timpului de nvare i a efortului;
proiectarea estetic a sistemului (este important ca utilizatorilor s le plac
sistemul).
92/135
Dup verificarea utilitii interaciunilor, sunt proiectate clasele de interaciune cu
factorul uman: ferestre, cmpuri, grafice etc. De cte ori e posibil, trebuie utilizate interfeele
grafice standard cu utilizatorul (GUI).
7.5.3 Activitatea a IlI-a: Proiectarea componentei coordonrii task-urilor
Mai nti trebuie vzut dac e nevoie de task-uri n sistem. Urmtoarele tipuri de
sisteme necesit task-uri:
sisteme de achiziii de date i de control al dispozitivelor locale;
interaciuni cu factorul uman cu ferestre multiple care ruleaz simultan;
sisteme multi-user;
sisteme mono-procesor care necesit comunicare i coordonare ntre task-uri;
sisteme multi-procesor;
sisteme care comunic cu alte sisteme.
Dac nu sunt necesare, task-urile nu trebuie proiectate ntruct mresc complexitatea.
Exist cteva tipuri de task-uri care pot fi identificate:
task-uri declanate de un eveniment (de exemplu: apsarea unui buton al mouse-
ului);
task-uri declanate la un anumit interval de timp;
task-uri prioritare i critice.
Cnd sunt necesare trei sau mai multe task-uri, se recomand adugarea unui task
special de coordonare. Dup identificarea task-urilor, necesitatea lor trebuie reverificat.
Pentru fiecare task, trebuie specificat:
ce este task-ul;
cum este coordonat task-ul;
cum comunic task-ul.
7.5.4 Activitatea a IV-a: Proiectarea componentei coordonrii datelor
Mai nti trebuie selectat o abordare pentru coordonarea datelor: fiiere simple sau un
sistem de gestionare a bazelor de date, pe baza unor criterii potrivite. Apoi, n funcie de
abordarea aleas, trebuie proiectat componenta de coordonare a datelor, adic a formatului
de date i a serviciilor corespunztoare.
7.6 Concluzii
Scopul acestui curs este de a realiza o introducere n procesul de proiectare a sistemelor
software. Au fost amintite mai nti caracteristicile unei proiectri corecte: extensibilitatea,
sigurana si eficiena, mpreun cu modalitile prin care pot fi atinse aceste deziderate. S-a
definit proiectarea orientat obiect i s-au detaliat etapele acestei faze de dezvoltare a
produselor software: determinarea contextului sistemului i a modelelor de utilizare,
proiectarea arhitecturii, identificarea obiectelor, modelele de proiectare i specificarea
interfeelor obiectelor, n final, s-a concretizat aceast faz prin descrierea metodei de
proiectare Coad-Yourdon, cu cele patru activiti specifice: proiectarea componentei
domeniului problemei, proiectarea componentei interaciunii cu factorul uman, proiectarea
componentei coordonrii task-urilor i proiectarea componentei coordonrii datelor.
93/135
8 Limbaje de modelare. UML
8.1 Limbaje de modelare
Problema principal care apare n dezvoltarea programelor este complexitatea. Folosirea
de modele poate nlesni abordarea unor astfel de probleme. Un model este o simplificare a
unui anumit sistem, care permite analizarea unora dintre proprietile acestuia. Lucrul cu
modelele poate facilita o mai bun nelegere a sistemului modelat, datorit dificultii
intrinseci de nelegere a sistemului n ntregul su. Folosirea tehnicii divide et impera"
permite nelegerea prilor componente ale unui sistem, iar ansambul sistemului ca o
interaciune ntre prile acestuia. Un model reuit reine caracteristicile importante ale
obiectului modelat (caracteristicile necesare) i le ignor pe cele irelevante. De remarcat c
noiunile de important/irelevant sunt relative, ele depinznd de scopul pentru care se face
modelarea. Astfel apare plauzibil construirea mai multor modele pentru un anumit obiect,
fiecare surprinznd anumite aspecte ale acestuia.
Orice metodologie de dezvoltare a programelor abordeaz problema comunicrii dintre
membrii echipei. Este posibil s apar situaii n care modelul construit de proiectant s nu fie
neles exact de cel ce scrie cod, fie din cauza lipsei de precizie a modului n care este
prezentat modelul, fie datorit incompletitudinei acestuia; adesea o serie de amnunte subtile,
evidente pentru proiectant, nu sunt transmise explicit. O rezolvare a problemei comunicrii ar
fi ca aceeai persoan s fie implicat direct n toate fazele dezvoltrii. Chiar i aa, apare des
situaia n care o persoan trebuie s continue munca alteia.
Se impune aadar existena unui limbaj formal de comunicare a cerinelor. Termenul
formal" este esenial. De obicei, chiar i n proiecte de dimensiuni reduse se face modelare,
ns ntr-un limbaj specific celui care modeleaz, determinat de viziunea sa asupra problemei
i de pregtirea acestuia (de exemplu, un matematician va fi nclinat s utilizeze o notaie
algebric, un arhitect o notaie preponderent grafic etc.) Folosirea unui limbaj intern" nu
trebuie considerat negativ, ea avnd un rol esenial n gndire n general i n modelare n
particular. Aa cum formalismul raionamentului matematic poate fi agentul de transmisie al
adevrului matematic (care, odat transmis, este tradus" n limbajul intern al receptorului),
formalismul limbajului de modelare const n stabilirea unor elemente cu o semantic asupra
creia se convine i cu ajutorul crora se pot transmite idei ntr-un mod ct mai eficient i fr
ambiguiti.
Deseori, atunci cnd ne gndim la un obiect ntr-un context oarecare, ignorm
caracteristicile care nu intereseaz. De exemplu, la un microprocesor nu ne intereseaz
culoarea sau greutatea. Din punct de vedere practic, este probabil ineficient s considerm
aspectul greutii microprocesorului de fiecare dat cnd utilizm un calculator i de aceea
mintea uman dispune probabil de un mecanism de eliminare a caracteristicilor irelevante.
Exist ns obiecte mult mai complexe dect un microprocesor. O rachet cosmic este
probabil un artefact ce depete capacitatea de nelegere a unui singur individ. Motivul
pentru care exist totui microprocesoare i navete cosmice este simplu: se folosesc modele.
Modelul este o simplificare a realitii. Aceast simplificare reine caracteristicile relevante
ale unui sistem, n timp ce le ignor pe celelalte.
S considerm analiza comportamentului unui corp sub aciunea unei fore externe. Pe
baza experienei n domeniu, tim c singurele atribute care influeneaz analiza n acest caz
sunt masa corpului i fora rezultant care acioneaz asupra corpului. Un model uzual de
reprezentare a acestei probleme este urmtorul:
94/135
F

Figura 8-1 Modelare n fizic
Acest model face cteva simplificri evidente. Forma corpului este desenat ca un
ptrat. Diverse alte caracteristici sau interaciuni cu mediul sunt ignorate. Pe de alt parte,
viteza i fora sunt reprezentate prin vectori. Viteza este notat cu v, fora cu F, masa cu m.
Toate aceste elemente formeaz un model. Pentru un iniiat, desenul de mai sus este
consistent, expresiv i compact. O descriere alternativ, sub forma de text, dei posibil mai
exact, ar fi mai greoaie: fie un corp de mas m asupra cruia acioneaz o for F cu punctul
de aplicaie n centrul su de greutate. Corpul se deplaseaz cu o vitez v perpendicular pe
direcia forei".
Limbajul natural pare s fie cel mai la ndemn limbaj de modelare. Experiena arat
ns c folosirea sa induce adesea neclariti i inconsistene. Apare astfel necesitatea definirii
unui limbaj neambiguu pentru specificarea modelelor. Se convine asupra unui set de elemente
ale limbajului precum i asupra semanticii acestora. Evident, descrierea elementelor i a
semanticii se face n ultim instan n limbaj natural, deci pot aprea aici unele ambiguiti,
n acest caz ns, limbajul natural este folosit numai ntr-o mic parte a sistemului iar
problemele de semantic pot fi localizate. Eliminarea ambiguitilor din modele poate fi
fcut mbuntind precizia limbajului de modelare i nu cutnd erori de semantic n
ntreaga descriere a modelului.
8.2 Ce este UML?
Limbajul unificat de modelare (engl. Unified Modeling Language"), UML, este un
limbaj pentru specificarea, vizualizarea, construirea i documentarea elementelor sistemelor
software, ns poate fi folosit i pentru alte sisteme, cum ar fi cele de modelare a afacerilor.
UML reprezint o colecie de practici inginereti optime, care au fost ncununate de succes n
modelarea sistemelor mari i complexe. Dezvoltarea unui model pentru sisteme software
industriale nainte de nceperea construciei efective este esenial. Modelele bune sunt
absolut necesare pentru comunicarea dintre echipele care lucreaz la acelai proiect i pentru
asigurarea soliditii arhitecturale. Odat cu creterea complexitii sistemului, crete i
importana unor tehnici potrivite de modelare. Exist muli factori suplimentari pentru
succesul unui proiect, dar un factor esenial este respectarea riguroas a standardelor cu
ajutorul unui limbaj de modelare.
UML nu garanteaz succesul proiectului, dar perfecioneaz multe lucruri. De exemplu,
scade n mod semnificativ costul instruirii n cazul schimbrilor legate de proiecte sau
organizaii. Limbajul asigur posibilitatea integrrii instrumentelor, proceselor i domeniilor,
ns mai important este faptul c asigur dezvoltatorilor un mod general de rezolvare a
problemelor de concepie i planificare.
Mai nainte de UML, nu exista un limbaj clar i standardizat de modelare. Utilizatorii
erau nevoii s aleag unul dintre multele limbaje similare, cu diferene minore asupra puterii
de expresie. Cele mai multe limbaje mprteau o serie de concepte unanim recunoscute, care
erau exprimate uor diferit prin diverse notaii. Aceste diferene au fragmentat industria
95/135
orientat obiect i au descurajat noii utilizatori s nvee modelarea vizual. De fapt,
utilizatorii doreau un limbaj standardizat, o lingua franca a modelrii.
Intre 1989 i 1994 erau folosite mai mult de 50 de limbaje de modelare software, fiecare
cu propriile notaii. Fiecare limbaje avea elemente de sintax specifice i n acelai timp
elemente comune cu alte limbaje. Mai mult, nici un limbaj nu era complet, inginerii software
apelnd deseori la mai multe limbaje.
La mijlocul anilor '90 trei metode s-au dovedit mai eficiente:
Booch: potrivit mai ales pentru proiectare i implementare, cu dezavantajul
unor notaii complicate;
OMT (Object Modeling Technique): potrivit pentru analiz i sisteme
informaionale cu multe date;
OOSE (Object Oriented Software Engineering): aceast metod a propus aa-
numitele cazuri de utilizare, care ajutau la nelegerea comportamentului
ntregului sistem.
In 1994, Jim Rumbaugh, creatorul OMT, a uimit ntreaga comunitate software cnd a
prsit General Electric, alturndu-se lui Grady Booch la Raional Corp. Scopul
parteneriatului era combinarea ambelor perspective ntr-o metod unificat, n 1995 i Ivar
Jacobson, creatorul OOSE, a venit la Raional, iar ideile lui (n special conceptul de cazuri de
utilizare) au fost adugate Metodei unificate"; metoda rezultant a fost numit Limbajul de
modelare unificat" - UML. n ciuda disputelor iniiale, noua metod a nceput s aib din ce
n ce mai muli susintori n industria software, formndu-se un consoriu UML din care
fceau parte gigani precum Hewlett-Packard, Microsoft i Oracle.
UML 1.0 a fost propus spre standardizare n cadrul OMG (Object Management Group)
n ianuarie 1997. Pn la sfritul anului 1997 echipa care lucra la UML s-a extins, urmnd o
perioad n care UML a primit o specificare formal mai riguroas. Versiunea UML l. l a fost
adoptat ca standard de ctre OMG n noiembrie 1997. n martie 2003 a fost publicat
versiunea 1.5. n momentul de fa se lucreaz la versiunea 2.0.
n UML exist numeroase diagrame (modele), aceasta favoriznd existena mai multor
puncte de vedere privind sistemul. Dup cum am vzut, procesul de dezvoltare software are
multe componente, fiecare cu propria sa perspectiv: analiti, proiectani, programatori,
testeri, echipe de asigurarea calitii, autori ai documentaiei, clieni. Fiecare dintre aceti este
interesat de un alt aspect al sistemului, la un nivel diferit de detaliu. De exemplu,
programatorul trebuie s neleag arhitectura sistemului pentru a o converti n cod de nivel
sczut. Dimpotriv, autorul documentaiei trebuie s neleag comportamentul global al
sistemului pentru a ti cum funcioneaz produsul. UML ncearc s rezolve problema
modelrii la toate aceste nivele de detaliu.
8.3 Modelarea cazurilor de utilizare
Un instrument UML foarte puternic este reprezentarea cazurilor de utilizare, adic
descrierea mulimii de interaciuni dintre utilizator i sistem. Prin construirea unei colecii de
cazuri de utilizare, putem descrie ntregul sistem ntr-o manier clar i concis. Cazurile de
utilizare sunt denumite de obicei printr-o combinaie substantival-verbal, de exemplu:
Pltete factura, Creeaz cont etc. Notaia pentru un caz de utilizare este prezentat n figura
urmtoare:

Figura 8-2 Caz de utilizare
96/135
Un caz de utilizare trebuie s aib un iniiator al aciunii, numit actor. In cazul unui
sistem bancar, retragerea banilor este fcut de clieni, astfel nct clientul devine unul din
actori:

Figura 8-3 Caz de utilizare cu actor
Actorii nu sunt numai oameni, ci orice cauz extern care iniiaz un caz de utilizare, de
exemplu un alt sistem de calcul sau un concept mai abstract, precum timpul sau o anumit
dat calendaristic: n ultima zi a lunii se actualizeaz registrele de salarii. Pentru majoritatea
sistemelor, un anumit actor poate interaciona cu mai multe cazuri de utilizare, iar un anumit
caz de utilizare poate fi iniiat de actori diferii:
Porneste
Operator
Inchide
Produce raport
Vede starea
comenzilor
Sistem de
comanda

Figura 8-4 Cazuri de utilizare cu actori multipli
Dei par foarte simple, ignorarea cazurilor de utilizare este o mare greeal. Acestea
sunt foarte importante deoarece:
definesc domeniul sistemului, permind vizualizarea dimensiunii i sferei de
aciune a ntregului proces de dezvoltare;
sunt similare cerinelor, dar cazurile de utilizare sunt mai clare i mai precise
datorit structurii riguroase de notaie;
suma cazurilor de utilizare este sistemul ca ntreg; ceea ce nu este acoperit de un
caz de utilizare se situeaz n afara sistemului de construit;
permit comunicarea dintre client i dezvoltatori, de vreme ce diagrama este
foarte simpl i poate fi neleas de oricine;
ghideaz echipele de dezvoltare n procesul de dezvoltare;
ajut echipele de testare i autorii manualelor de utilizare.
Se pune problema definirii granularitii cazurilor de utilizare: ntr-un anumit scenariu,
fiecare interaciune utilizator-sistem trebuie s fie un caz de utilizare sau un singur caz de
utilizare poate ncapsula toate interaciunile. Pentru un bancomat, scenariul presupune mai
multe interaciuni: introducerea card-ului, introducerea codului PIN, selectarea sumei dorite,
97/135
confirmarea ei, scoaterea card-ului, preluarea chitanei. Fiecare din aceti pai trebuie s fie
cte un caz de utilizare?

Figura 8-5 Cazuri de utilizare incorecte
Dac pentru un sistem suficient de complex am urma aceast strategie, ar rezulta un
numr imens de cazuri de utilizare, care nu i-ar mai servi practic scopul de descriere a
comportamentului sistemului la nivel nalt.
Cnd se ia decizia includerii unui nou caz de utilizare, trebuie s se respecte urmtoarea
regul euristic: un caz de utilizare trebuie s satisfac un scop pentru actor.
n exemplul anterior, se poate pune problema: preluarea chitanei este un scop al
clientului? Nu neaprat. La fel se procedeaz i pentru celelalte cazuri de utilizare. Nici unul
nu descrie suficient de corect scopul clientului, care este de fapt retragerea unei sume de bani.

Figura 8-6 Caz de utilizare corect
8.4 Modelarea conceptual. Diagrama de clase
Modelarea conceptual (numit i modelarea domeniului") este activitatea de
identificare a conceptelor importante pentru sistem, n tehnica de programare orientat pe
obiect, modelarea conceptual se realizeaz prin diagrama claselor, ntruct clasele reprezint
concepte. Diagrama claselor furnizeaz structura codului care va fi scris. Problema principal
este identificarea conceptelor. Regula de urmat aici este: dac clientul nu nelege conceptul,
probabil c nu este un concept.
O clas se reprezint printr-o csu mprit n trei. In partea de sus este notat numele
clasei, n partea median atributele iar n partea de jos operaiile sale.
98/135

Figura 8-7 Clasa n notaie UML
8.4.1 Asocierea
Urmtorul pas este definirea relaiilor dintre concepte. S presupunem urmtoarele dou
concepte:
Manager
Nume
Masina
Numar inmatriculare
Capacitate motor
Culoare

Figura 8-8 Concepte nrudite funcional
Dac fiecare manager conduce o main n compania respectiv, ntre aceste concepte
exist o relaie:

Figura 8-9 Asocierea n notaie UML
Linia simpl n UML are rolul de asociere. Numerele descriu cardinalitatea asocierii,
adic ne spun cte instane sunt permise din fiecare concept. Urmtoarea figur prezint
cteva cardinaliti posibile, dei din punct de vedere al notaiei nu exist restricii asupra
cardinalitilor care pot fi specificate.
99/135

Concept A
*
Concept B
Concept A
1..*
Concept B
Concept A
1..8
Concept B
Concept A
18
Concept B
Concept A
1,3,5,7,11
Concept B
Oricat de multe
Una sau mai multe
Intre 1 si 8
Exact 18
Multime specificata

Figura 8-10 Cardinalitatea asocierii
O greeal care poate fi fcut n aceast faz este s decidem c exist o relaie ntre
dou concepte, s trasm o linie ntre ele, dar s nu notm tipul de asociere. Dup ce vom
trasa toate liniile nu vom mai ti ce nseamn fiecare i va trebui s o lum de la nceput.
n figura urmtoare este prezentat un exemplu de asociere ntre clase:
100/135
Masina
conduce
1
Manager
Pensie
contribuie la
1..*
Angajat
Curs de pregatire
Zi libera
Vacanta
g
e
s
t
i
o
n
e
a
z
a
p
o
a
t
e

p
a
r
t
i
c
i
p
a

l
a

p
o
a
t
e

l
u
a
p
o
a
t
e

lu
a
1
1
1
1..*
0..*
0..*
0..*
0..*
0..*
0..*

Figura 8-11 Asociere complex
8.4.2 Agregarea
Un aspect important al proiectrii orientate obiect este agregarea, ideea c un obiect
poate fi construit din altele. De exemplu, un calculator este o agregare ntre procesor, plac
video, plac de sunet etc.
1..*
Procesor
Placa video
Placa sunet
Calculator
1..*
1..*

Figura 8-12 Agregarea n notaie UML
101/135
8.4.3 Compunerea
Compunerea este un concept similar cu agregarea, ns mai puternic deoarece implic
faptul c un ntregul nu poate exista fr pri. In exemplul de agregare de mai sus, dac se
nltur placa de sunet, calculatorul rmne calculator, ns o carte nu poate exista fr pagini;
o carte este compus din pagini. Notaia este asemntoare, dar rombul este plin:

Figura 8-13 Compunerea n notaie UML
8.4.4 Vizibilitatea atributelor i operaiilor
In figura urmtoare sunt prezentate notaiile pentru vizibilitatea atributelor i operaiilor
(privat, protejat, public), n mod text i n mod grafic.

Notaie Descriere Notaie Descriere

Spaiu de nume

Metod sau funcie

Clasa

Operator

Interfa

Proprietate

Structur

Cmp sau variabil

Uniune

Eveniment

Enumerare

Constant

Definiie de tip

Element de enumerare

Modul

Element de hart

Intrinsec

Declaraie extern

Delegat

Macro

Excepie

Template

Harta

Necunoscut sau eroare

Global

Notaie semnal Descriere Explicaii
<No Signal Icon> Public Accesibil de oriunde si prin orice component care l refer

Protejat Accesibil numai din clasa sau tipul care l conine sau din
clasele sau tipurile derivate din acestea.

Privat Accesibil numai din clasa sau tipul care l conine.

Intern Accesibil numai din aceast component

Prieten Accesibil numai din proiect.

Referin O referin la un obiect.
102/135

Figura 8-14 Vizibilitatea atributelor i operaiilor
8.4.5 Motenirea
De multe ori, mai multe clase din arhitectur au atribute i operaii comune. Acestea pot fi
introduce ntr-o singur clas i motenite n celelalte. De exemplu:
Caine
- varsta
+mananca()
+doarme()
+latra()
+se joaca()
Om
- nume
- varsta
+mananca()
+doarme()
+munceste()
+vorbeste()
+se joaca()

Figura 8-15 Clase cu atribute i operaii comune
Dac am mai vrea s adugm o clas Pisic, ar trebui s repetm atributele i operaiile
comune. Soluia este motenirea dintr-o clas mai general. Notaia UML pentru motenire
este urmtoarea:
Animal
- varsta
+mananca()
+doarme()
+se joaca()
Caine
+latra()
Om
- nume
+munceste()
+vorbeste()

Figura 8-16 Motenirea n notaie UML
Trebuie s subliniem c atributul vrst a fost transformat din privat n protejat, pentru a
putea fi motenit n clasele derivate.
103/135
O greeal frecvent n proiectarea orientat obiect este utilizarea abuziv a motenirii,
ceea ce conduce la probleme n ntreinerea programului. Dac mai multe clase sunt legate de
una singur, schimbrile n clasa de baz vor afecta i clasele derivate. De asemenea, cnd
derivm o clas trebuie s parcurgem ntreaga ierarhie pentru a vedea ce face implicit clasa
respectiv. Aceast problem este cunoscut sub denumirea de proliferarea claselor.
Motenirea nu trebuie folosit dect ca mecanism de generalizare, adic se folosete
numai dac clasele derivate sunt specializri ale clasei de baz.
De asemenea, toate definiiile clasei de baz trebuie s se aplice tuturor claselor
derivate. Aceasta este regula 100%. Dac nu se aplic aceast regul, clasele derivate nu sunt
specializri ale clasei de baz. Un exemplu de derivare greit este urmtorul:
Animal
#varsta
+mananca()
+doarme()
+se joaca()
+zboara()
Om
- nume
+munceste()
+vorbeste()

Figura 8-17 Motenire incorect
Se poate observa c operaia zboar nu se aplic i clasei Om.
8.4.6 Polimorfismul
Clasele derivate pot redefini implementarea unei metode. In exemplul urmtor, clasele
Pian i Vioar sunt derivate din Instrument. Totui, fiecare implementeaz metoda cnt n
felul su specific. Notaia n acest caz este repetarea numelui metodei n fiecare clas.

Figura 8-18 Polimorfismul n notaie UML
104/135
De multe ori avem nevoie s lsm o metod neimplementat ntr-o clas (metod
abstract sau virtual), pe care s o implementm pe un nivel mai de jos al ierarhiei. O metod
abstract se noteaz cu italice.

Figura 8-19 Clas de baz cu o metod abstract (virtual)
8.4.7 Interfee
Dac o clas implementeaz o interfa, ntre cele dou exist o relaie de realizare. S
presupunem c Instrument din exemplul precedent e acum o interfa iar clasele Pian i
Vioar trebuie s implementeze metoda cnt. Notaia este asemntoare celei de la
motenire, dar cu linie punctat, iar interfaa e declarat explicit. Cuvintele introduse ntre "
i " se numesc stereotipuri, n figura 20 se poate observa stereotipul UML interface.

Figura 8-20 Notaia UML pentru interfee
O notaie alternativ este urmtoarea:
Instrument
+canta()
Pian Vioara

105/135
Figura 8-21 Notaie alternativ pentru interfee
8.4.8 Metode statice
n notaia UML, metodele statice se subliniaz:
Math
+Abs(val : double) : double
+Sin(angle : double) : double
+Exp(val : double) : double

Figura 8-22 Clas cu metode statice
8.5 Diagrame de interaciune
Descrierea comportamentului implic dou aspecte: descrierea structural a
participanilor i descrierea modelelor de comunicaie. Modelul de comunicaie al instanelor
care joac un rol pentru ndeplinirea unui anumit scop se numete interaciune. Diagramele de
interaciune au dou forme, bazate pe aceleai informaii de baz, dar care se concentreaz
fiecare pe un alt aspect al interaciunii: diagramele de secven i diagramele de colaborare.
8.5.1 Diagrama de secvene
Diagrama de secvene pune accentul pe aspectul temporal (ordonarea n timp a
mesajelor), fiind potrivit specificaiilor de timp real i scenariilor complexe. Notaia grafic
este un tabel care are pe axa X obiecte, iar pe axa Y mesaje ordonate cresctor n timp. Axa Y
arat pentru fiecare obiect timpul ca o linie vertical punctat (linia vieii" unui obiect, engl.
lifeline") i perioada n care obiectul preia controlul execuiei (reprezentat printr-un
dreptunghi) i efectueaz o aciune, direct sau prin intermediul procedurilor subordonate.
In figura urmtoare este descris interaciunea simplificat ntre un client i un server.
De remarcat c n diagrama de secvene utilizm obiecte, nu clase, ntr-un program pot exista
mai multe instane ale aceleiai clase care au roluri diferite n sistem. Un obiect este
identificat de numele su i numele clasei pe care o instaniaz. Numele obiectului poate s
lipseasc dac nu este semnificativ pentru nelegerea comportamentului sistemului. Liniile
orizontale continue semnific mesaje iniiate obiecte, iar liniile orizontale punctate reprezint
mesaje-rspuns.
106/135

Figura 8-23 Diagram de secvene
8.5.2 Diagrama de colaborare
Diagrama de colaborare se concentreaz pe rolurile instanelor i relaiile dintre ele. Ea
nu conine timpul ca o dimensiune separat, de aceea secvena de comunicaii i firele de
execuie concurente trebuie numerotate.

Figura 8-24 Diagram de colaborare n exemplul de mai sus, asteriscul semnific posibilitatea mai multor
interogri SQL i a mai multor rezultate.
107/135
8.6 Diagrame de activiti
Diagramele de activiti sunt folosite pentru modelarea proceselor sau a algoritmilor din
spatele unui anumit caz de utilizare. Din multe puncte de vedere, diagrama de activiti din
UML este echivalentul orientat pe obiect al diagramei fluxurilor de date din dezvoltarea
structurat.
Notaia este urmtoarea:
nod iniial: un cerc plin este punctul de start al diagramei; dei nu este
obligatoriu, prezena sa face diagrama mai lizibil;
nod final: un cerc plin nconjurat de un alt cerc; o diagram poate avea 0, l sau
mai multe noduri finale;
activitate: dreptunghiurile rotunjite reprezint activitile care au loc;
fluxuri: sgeile diagramei;
punct final al fluxului: un cerc cu un X n interior; indic faptul c procesul se
oprete n acest punct;
ramificaie (engl. fork"): o bar neagr cu un flux de intrare i mai multe fluxuri
de ieire; denot nceputul unor activiti desfurate n paralel;
reunire (engl. join"): o bar neagr cu mai multe fluxuri de intrare i un flux de
ieire; denot sfritul prelucrrilor paralele;
condiie: text asociat unui flux, care definete o condiie care trebuie s fie
adevrat pentru traversarea nodului;
decizie: un romb cu un flux de intrare i mai multe fluxuri de ieire; fluxurile de
ieire includ condiii;
mbinare (engl. merge"): un romb cu mai multe fluxuri de intrare i un flux de
ieire; toate fluxurile de intrare trebuie s ating acest punct pentru ca procesul
s continue;
partiie (engl. swimlanes"): o parte a diagramei care indic cine/ce ndeplinete
activitile;
not: o specificaie suplimentar sub form de text.
n Figura 8-25 este prezentat o diagram de activiti cu decizii. Candidatul trebuie s
fie admis" este o not asociat unei decizii.

Figura 8-25 Diagram de activiti cu decizii
108/135
n Figura 8-26 este prezentat o alt diagram de activiti, cu partiii i ramificaii.

Figura 8-26 Diagram de activiti cu partiii i ramificaii
109/135
8.7 Diagrame de stri
Obiectele au att comportament, ct i stare intern, cu alte cuvinte, ndeplinesc aciuni
i dein informaii. Unele obiecte au comportamente foarte complexe, care depind foarte mult
de starea intern. Pentru a le nelege, dezvoltatorii utilizeaz diagramele de stri, care descriu
modul de funcionare a instanelor.
Diagramele de stri UML descriu diferitele stri n care se poate gsi un obiect i
tranziiile dintre aceste stri. O stare reprezint o etap n modelul comportamental al unui
obiect i, le fel ca n cazul diagramelor de activiti, este posibil s avem stri iniiale i stri
finale. O stare iniial este cea n care se gsete obiectul cnd este creat. O stare final este o
stare din care nu mai exist tranziii. Tranziia reprezint schimbarea strii, trecerea dintr-o
stare n alta, i poate fi determinat de un eveniment extern sau intern.
Figura urmtoare prezint un exemplu de diagram de stare pentru nscrierea la un curs
opional propus cu un numr limitat de studeni. Dreptunghiurile rotunjite reprezint stri:
instanele clasei Curs pot fi n urmtoarele stri: Propus, Planificat, Disponibil pentru
nscrieri, Ocupat, nchis pentru nscrieri. Starea iniial este notat tot printr-un cerc plin, iar
starea final printr-un cerc plin nconjurat de alt cerc, la fel ca n diagramele de activiti
(dovad a consistenei modelului).

Figura 8-27 Diagram de stri
n Figura 8-28 putem observa cum strile din Figura 8-27 se grupeaz ntr-o aa numit
superstare, pentru a putea descrie un sistem complex la un nivel superior de abstractizare.
110/135

Figura 8-28 Diagram de stri: superstare
8.8 Diagrama pachetelor
Entitile UML pot fi grupate n pachete - containere logice n care pot fi plasate
elemente nrudite, ca i directoarele din sistemele de operare. Dei orice entitate UML poate fi
introdus ntr-un pachet, de obicei rolul pachetelor este de a grupa clase i uneori cazuri de
utilizare nrudite.
ntr-un pachet UML numele elementelor trebuie s fie unice. Totui, un avantaj
important al pachetelor este c mai multe clase pot avea acelai nume dac aparin unor
pachete diferite. Dac dou echipei i B lucreaz n paralel, echipai nu va trebui s se
preocupe de coninutul pachetului echipei 5, cel puin din punctul de vedere al denumirilor.
Aadar, utilitatea pachetelor apare deoarece: elementele sistemelor mari pot fi grupate n
subsisteme mai mici i este permis dezvoltarea iterativ n paralel.
La formarea pachetelor trebuie s se in seama de urmtoarele deziderate. Un pachet
trebuie s aib o funcionalitate bine precizat, el nu trebuie s ndeplineasc funcii multiple,
deoarece devine greu de neles. De asemenea, dependenele dintre pachete trebuie s fie
minime.
111/135

Figura 8-29 Diagram de pachete
La rndul su, un pachet poate fi explicitat:

Figura 8-30 Pachet explicitat
8.9 Diagrame de implementare
8.9.1 Diagrama componentelor
Diagrama componentelor este asemntoare cu diagrama pachetelor, permind
vizualizarea modului n care sistemul este divizat i a dependenelor dintre module. Diagrama
componentelor pune ns accentul pe elementele software fizice (fiiere, biblioteci,
executabile) i nu pe elementele logice, ca n cazul pachetelor.

Figura 8-31 Diagram de componente
112/135
8.9.2 Diagrama de lansare
Diagramele de lansare (engl. deployment diagrams") descriu configuraia elementelor
de prelucrare la run-time i componentele software, procesele i obiectele care se execut pe
ele. Aceste diagrame sunt grafuri de noduri conectate de asociaii de comunicare. Nodurile pot
conine instane ale componentelor, indicnd faptul c acea component ruleaz sau se
execut n nodul respectiv. Nodurile sunt reprezentate prin paralelipipede. Cercurile
reprezint interfee, n figura 32 este prezentat un exemplu de diagram de lansare pentru o
aplicaie browser care utilizeaz protocolul TCP/IP pentru accesarea unui server.

Figura 8-32 Diagram de lansare
8.10 Concluzii
n aceste cursuri a fost mai nti argumentat necesitatea unui sistem de notaie
standardizat pentru etapele dezvoltrii unui proiect software. Apoi au fost prezentate notaiile
principale ale limbajului UML: diagramele de clase, de interaciune, de activiti, de stri, de
pachete i de implementare.
113/135
9 Implementarea
9.1 Introducere
Implementarea este faza n care este produs codul corespunztor proiectului furnizat de
faza anterioar, ndeplinind restriciile de resurse, acuratee i performan indicate de
specificaii.
Procesul implementrii este cel mai dificil de descris, nefiind riguros definit.
Implementarea este procesul transformrii abstractizrii prezentate n proiect ntr-o realizare
fizic utiliznd limbajul arhitecturii int. Este o faz concretizat ntr-o stare confuz, deseori
haotic i instabil pentru sistemele software complexe, n care coordonarea este dificil.
O problem major care cauzeaz instabilitatea const n dificultatea translatrii
proiectrii n cod surs. In primul rnd, de cele mai multe ori proiectarea nu va realiza o
mapare de l la l ctre implementare. De aceea, orict de bun ar fi proiectul, este necesar un
oarecare efort pentru a scrie codul corespunztor, ori aceasta este o surs de erori.
n al doilea rnd, procesul de transformare proiect-implementare este i mai dificil cnd
proiectul nu este complet, consistent sau nu comunic exact i inteligibil ceea ce se dorete
din partea sistemului. Erorile de proiectare determin pierderea timpului programatorilor n a
rezolva probleme greite puse. Acestea sunt erorile de logic i sunt cele mai frecvente. De
aceea este foarte important utilizarea unor metode riguroase pentru prezentarea proiectrii.
In al treilea rnd, unele aspecte sunt n afara domeniului proiectantului. Efectele exacte
ale utilizrii unui anumit sistem de operare sau limbaj de programare sunt n afara scopului
proiectantului dar reprezint o important decizie a programatorului.
n cele din urm, implementarea nsi este predispus ctre erori, fiind un proces
creator uman. Limbajul de programare poate fi folosit incorect, aceasta nsemnnd c un
anumit timp i efort se vor consuma pentru corectarea acestor erori. Din pcate, corectarea
erorilor nu este o sarcin uoar. S-a constatat c un programator are 50% anse s descopere
eroarea ntr-un interval de 5-10 linii de cod i numai 20% anse s o descopere ntr-un
domeniu de 40-50 linii.
Documentele de baz produse n aceast faz sunt:
codul surs i obiect comentate ntr-o form standard sau respectnd anumite
convenii;
pliante (dosare) ale software-ului, prezentnd modulele software individuale;
manualul de utilizare a produsului software, prezentnd conveniile utilizate n
programe, o prezentare general a implementrii, descrierea particularitilor;
planul pentru coordonarea configuraiei;
planul pentru testarea produsului.
Un aspect important n managementul fazei de implementare este cel al
managementului configuraiei sistemului software. Motivul const n faptul c produsul se
gsete n diverse faze pe msur ce echipele de programatori implementeaz diferite pri ale
sale i nu exist un produs ntreg" pn la integrarea tuturor modulelor. De aceea, la anumite
intervale de timp, toate modulele vor fi reunite formnd o anumit versiune a produsului, baza
de la care programatorii vor lucra n continuare. Aceste aspecte au fost deja detaliate ntr-un
curs anterior.
9.2 Limbaje de programare
n faza de implementare se extinde mai nti proiectul din faza anterioar la
componentele primitive ale sistemului. Se vor folosi aceleai metode din faza de proiectare
(proiectarea structurat, proiectarea orientat obiect, metode formale). Urmtorul pas este a
114/135
defini prelucrarea fiecrui modul prin metode ca: hri de fluxuri (engl. flowcharts"),
rafinarea pas cu pas, limbaje de proiectare a programelor, pseudocodul, etc.
Implementarea implic scrierea codului ntr-un limbaj de programare, verificarea i
integrarea sa cu alte programe pentru obinerea unui sistem final.
O decizie foarte important este alegerea unui limbaj potrivit de programare. Din punct
de vedere al semanticii, urmtoarele dou clase mari de limbaje sunt larg recunoscute:
limbaje imperative (numite uneori i procedurale): Fortran, Basic, Pascal,
C/C++, Java, C#
limbaje declarative: Lisp, Prolog, Clips.
9.2.1 Limbaje imperative
ntr-un limbaj imperativ, programatorul controleaz exact execuia programului, el
trebuie s defineasc modul cum se execut prelucrrile, n general, aceste limbaje suport
caracteristicile programrii structurate:
secvena: permite specificarea ordinii execuiei instruciunilor;
selecia: permite evaluarea unei condiii i luarea unei decizii;
iteraia: permite existena structurilor repetitive.
O alt caracteristic important este diviziunea n module, care permite descompunerea
funcional. Limbajele imperative moderne permit realizarea de programe orientate obiect, n
acest caz, programarea structurat poate fi aplicat doar n interiorul metodelor
Alte caracteristici ale unor limbaje imperative sunt:
structurarea n blocuri: impune ca un modul s aib un singur punct de intrare i
eventual un singur punct de ieire;
tipizarea puternic: impune ca tipul fiecrei date s fie declarat. Acest lucru
previne aplicarea operatorilor asupra obiectelor incompatibile din punct de
vedere al tipului i ajut compilatorul n evidenierea erorilor i n compilarea
eficient;
recursivitatea: permite unui modul s se autoapeleze. Limbajele orientate obiect
suport toate caracteristicile limbajelor de programare structurat i, n plus:
motenirea: este tehnica prin care modulele pot prelua funcionaliti de la
modulele de nivel superior;
polimorfismul: este abilitatea unui program de a lucra cu diferite tipuri de date
sau de a realiza aciuni diferite pentru instane ale unor clase diferite. Ideal ar fi
ca un limbaj OO s fie complet polimorf, astfel nct s nu mai fie necesare
poriuni de cod pentru fiecare tip de dat. Polimorfismul implic suportul pentru
legare dinamic (engl. dynamic binding"), adic legarea metodelor obiectelor
de selectarea mesajului n momentul execuiei i nu al compilrii;
mesajele: mesajele sunt utilizate pentru implementarea interfeelor. Un mesaj
conine detaliile aciunii care trebuie realizat i este trimis de ctre un obiect
ctre un alt obiect pentru a invoca un serviciu al celui din urm.
9.2.2 Limbaje declarative
Limbajele declarative pornesc cu o concepie diferit de limbajele imperative.
Programatorul nu mai controleaz explicit execuia programului, ci specific ce trebuie
realizat, care sunt regulile care pot rezolva problema, ns paii efectivi de rezolvare a
problemei i ordinea acestora sunt decii de program, nu de programator. Construcia secven
i pierde din importan deoarece programul nu mai poate fi vzut ca o secven de
instruciuni de la nceput pn la sfrit. Datorit diferenei de abordare, programele scrise n
limbaje declarative apar diferite fa de cele scrise n limbaje imperative.
115/135
9.3 Analiza unor limbaje de programare
9.3.1 C/C++
C/C++ este folosit pe scar larg pentru programarea profesionist. Acesta combin
virtuile unui limbaj de nivel nalt cu eficiena limbajului de asamblare. C a fost dezvoltat de
Dennis Ritchie n 1972 la AT&T's Bell Laboratories i a fost folosit pentru scrierea sistemului
de operare UNIX. Datorit legilor antitrust, Laboratoarelor Bell li s-au interzis drepturile de
autor asupra C-ului i UNIX-ului. De aceea, compilatoarele de C sunt n domeniul public i au
fost adoptate de majoritatea universitilor. Limbajul C a fost standardizat (ANSI C) n 1990.
n 1981, Bjarne Stroustrup a propus C++. C-ul originar este utilizat foarte rar, de aceea muli
programatori se refer la C++ cu termenul de C". C++ conine toate elementele de baz ale
C-ului, la care s-au adugat numeroase trsturi de programare orientat obiect. i C++ a fost
standardizat (ISO C++) n 1997.
Avantaje:
Eficien: C/C++ pot crea programe mai rapide i cu dimensiuni mai mici dect
aproape orice alt limbaj de programare, cu excepia limbajului de asamblare;
Portabilitate: Un program scris n C/C++ poate fi uor copiat i compilat pe alt
calculator, cu unele modificri. Pentru majoritatea sistemelor de operare exist
compilatoare de C/C++;
Flexibilitate: Pentru un programator experimentat, conversia liber a tipurilor de
date este un avantaj. Pentru nceptori, totui, acest lucru poate genera confuzie
i erori;
Numr mare de programatori: Acest limbaj este cunoscut de foarte muli
programatori, care ar putea modifica mai trziu un program existent.
Dezavantaje:
Dificil de stpnit: C/C++ este unul din cele mai dificile limbaje de programare.
In timpul necesar nvrii complete a C/C++, un program poate fi deja terminat
n alt limbaj;
Complexitate: C/C++ are puterea de a manipula direct memoria i hardware-ul
calculatorului. Acest lucru sporete ansele apariiei unei erori i timpul necesar
pentru debug;
Dificil de citit i neles: Programele sunt create o dat i modificate de multe
alte ori. Datorit naturii criptice a C/C++, nelegerea unui program poate ridica
probleme.
Pentru a exemplifica ultima afirmaie, orict ar prea de ciudat, urmtorul program C
este corect sintactic:

#i ncl ude <st di o. h>
#def i ne O ( b=b?b- 1: ( p++, 5) , *p&1<<b)
#def i ne o O?O
char *p, j =2, b, c; e( n) {f or ( p=" | ' 8I 0>+@{=#_P0- ] PV. ] F>TM! YK' ?? | T\ " Z8}aE<&D- ! : -
T' \ " \ O<~cG5$, <2' #; / UI . 0{d^HV6817- 2F95- T7X| c^/ 1XB] *) 3WHG0/ 0}dN>G RMZB. 12. P]
~hM^J \ \ [ \ <R^ ( 7; ) R9A78{gU! : N) E5OPUR><29A6| e&9V; E[ Q: , S1. P] }eES. $Z) : B. *O+$G_
~f WU8) 75?I #\ 75?WHN0{j E=] <V*1] J I #5VK) R9A6~J 5X9X#69/ +VX4 =S%! X- [ ) OE
#1XRZ\ " ?~%^- #Dz&M\ \ RST| %\ G66*~&^HV0> {%^-
8_P}%N>FO( }' M^J Q=z&U! : O( J {%&9G4| %ERO( ~( WU8) G4{' E=] ^G4" , b=n; *p++<122| | - -
b; ) ; c=*p; whi l e( - - c>31&&c! =79) put char ( 44+( o?o?o?-
34: 68: O?60: 74: O?64: o?o?2: 54: O?23: 63: 77: O?55: o?76: 15: 35: -
12: o?61: O?56: 65: O?66: 53: o?o?O?75: 58: 0: 70: 57: o?71: o?73: 1: 67: O?72: 59) ) ; c>32?e
( n- 1) : 0; }mai n( ) {whi l e( ++j <15) e( 1) , e( 13+j ) , e( 15) , e( j - ( j <4) ) ; }

i, mai mult, afieaz urmtorul text:
116/135

On the first day of Christmas my true love gave to me
a partridge in a pear tree.

On the second day of Christmas my true love gave to me
two turtle doves
and a partridge in a pear tree.

On the third day of Christmas my true love gave to me
three french hens, two turtle doves
and a partridge in a pear tree.

On the fourth day of Christmas my true love gave to me
four calling birds, three french hens, two turtle doves
and a partridge in a pear tree.

On the fifth day of Christmas my true love gave to me
five golden rings;
four calling birds, three french hens, two turtle doves
and a partridge in a pear tree.

On the sixth day of Christmas my true love gave to me
six geese a-laying, five golden rings;
four calling birds, three french hens, two turtle doves
and a partridge in a pear tree.

On the seventh day of Christmas my true love gave to me
seven swans a-swimming,
six geese a-laying, five golden rings;
four calling birds, three french hens, two turtle doves
and a partridge in a pear tree.

On the eighth day of Christmas my true love gave to me
eight maids a-milking, seven swans a-swimming,
six geese a-laying, five golden rings;
four calling birds, three french hens, two turtle doves
and a partridge in a pear tree.

On the ninth day of Christmas my true love gave to me
nine ladies dancing, eight maids a-milking, seven swans a-swimming,
six geese a-laying, five golden rings;
four calling birds, three french hens, two turtle doves
and a partridge in a pear tree.

On the tenth day of Christmas my true love gave to me
ten lords a-leaping,
nine ladies dancing, eight maids a-milking, seven swans a-swimming,
six geese a-laying, five golden rings;
four calling birds, three french hens, two turtle doves
and a partridge in a pear tree.
117/135

On the eleventh day of Christmas my true love gave to me
eleven pipers piping, ten lords a-leaping,
nine ladies dancing, eight maids a-milking, seven swans a-swimming,
six geese a-laying, five golden rings;
four calling birds, three french hens, two turtle doves
and a partridge in a pear tree.

On the twelfth day of Christmas my true love gave to me
twelve drummers drumming, eleven pipers piping, ten lords a-leaping,
nine ladies dancing, eight maids a-milking, seven swans a-swimming,
six geese a-laying, five golden rings;
four calling birds, three french hens, two turtle doves
and a partridge in a pear tree.

9.3.2 Basic
Basic (Beginner's AII Purpose Symbolic Instruction Code) a fost dezvoltat la Dartmouth
College n 1964 sub coordonarea lui J. Kemeny i a lui T. Kurtz. Ideea era crearea unui limbaj
foarte simplu de nvat care s serveasc drept treapt intermediar pentru studenii care
nvau Fortran i Algol. Basic a fost primul produs vndut de Microsoft i primul caz major
de piraterie software: a fost copiat i distribuit pe scar larg nc nainte de a fi lansat (Bill
Gates a pierdut o copie n timpul unei demonstraii publice).
Fiind un limbaj de nivel nalt uor de folosit, este foarte nimerit pentru a preda
fundamentele programrii nceptorilor i a devenit un limbaj utilizat de muli amatori pentru
realizarea de programe simple. La nceput necesita un interpretor, astfel nct nceptorii s
poat crea programul ntr-o manier interactiv, s-1 ruleze, testeze i corecteze. Limbajele
interpretate favorizeaz nvarea programrii, dar ruleaz mult mai lent dect programele
compilate. De aceea, programatorii profesioniti le evit n general. Noile versiuni de Basic
posed compilatoare, cum ar fi Visual Basic, n care pot fi create programe de calitate
comercial. i Basic-ul a fost standardizat: ANSI Minimal Basic (1978) i ANSI Full Basic
(1987).
Avantaje:
Uor de nvat: Poate fi nvat i folosit mai repede dect majoritatea celorlalte
limbaje;
Permite prototipizare rapid: n Visual Basic, prototipurile se pot crea repede.
Apoi acestea pot fi transformate n programe reale funcionale. Alte limbaje,
precum C/C++, sunt prea greu de utilizat pentru a crea un prototip.
Dezavantaje:
Lent: Programele scrise n Visual Basic n general ruleaz mult mai ncet dect
programele echivalente n C/C++. Dac viteza este o condiie important pentru
program, Visual Basic nu este o alegere potrivit;
Claritate redus: Datorit sintaxei limbajului, programele de mari dimensiuni
devin greu de citit i neles;
Inflexibil: Visual Basic este uor de nvat, ns ascunde detaliile tehnice ale
programrii. In acelai timp, mpiedic programatorul s controleze total
calculatorul, ceea ce limiteaz puterea programelor;
Portabilitate limitat: Visual Basic ruleaz numai pe platforme Windows.
118/135
9.3.3 Pascal
Este un limbaj de nivel nalt care ncurajeaz programarea modular, bine structurat.
Pascal este acceptat pe scar larg ca limbaj educaional i de dezvoltare a aplicaiilor. Este
mai puin flexibil dect C/C++, compilatorul face mai multe verificri, ns n acest fel scade
riscul apariiei erorilor. Avnd la nceput scop didactic, conversiile de tip sunt mult mai stricte
dect n C, ceea ce scade riscul apariiilor erorilor, dar n acelai timp scade i flexibilitatea,
libertatea i imaginaia pe care o pot pune n practic programatorii. Limbajul a aprut n
1971, creat de Nicklaus Wirth. Un pas nainte important fa de celelalte limbaje existente la
momentul respectiv a fost faptul c suporta recursivitatea.
In prezent, Pascal st la baza mai multor medii de dezvoltare a aplicaiilor comerciale,
cu suport orientat obiect. Borland Delphi (sub Windows) i CodeWarrior Pascal i THINK
Pascal (sub Macintosh) sunt cele mai utilizate.
9.3.4 Java
Limbajul Java este rezultatul Stealth Project" al Sun Microsystem, care avea ca scop
cercetarea n domeniul aplicabilitii calculatoarelor pe piaa produselor electronice n vederea
crerii de produse electronice inteligente care s poat fi controlate i programate centralizat,
printr-un dispozitiv asemntor cu o telecomand. Aceleai cerine de stabilitate i
independen n sisteme eterogene existau i pentru Internet. De aceea, dei proiectat iniial n
alte scopuri, Java s-a potrivit perfect aplicaiilor world-wide-web.
Sun a prezentat formal Java n 1995. In curnd, Netscape Inc. a anunat c va ncorpora
suport pentru Java n browser-ul lor. Mai trziu, i Microsoft a fcut acelai lucru, ntrind
rolul limbajului Java n zona Internet.
Java aparine unei noi generaii de limbaje de programare, care i-a ctigat n ultima
perioad o mare popularitate. In Java se pot crea programe complexe sau mini-programe
(applet-uri) care s ruleze pe Internet. Deoarece Java este nc la nceput, Sun Microsystems,
creatorul su, ncearc permanent s mbunteasc limbajul. Din acelai motiv, multe
companii au nc o atitudine de expectativ n legtur cu Java. Totui, dac portabilitatea este
important, Java este alegerea cea mai bun.
O caracteristic a limbajului este maina virtual (sau interpretorul) care trebuie s
existe pe calculatorul client. Fiecare platform are propria main virtual, care execut de
fapt programul pe sistemul de operare respectiv. Cnd un program este compilat, rezult un
fiier de byte-codes", foarte asemntoare cu instruciunile main, fr ns a fi specifice
unui anumit procesor. Procesul transformrii byte-codes" n cod main este foarte simplu i
se face la runtime. Din acest motiv ns, exist clare diferene de performan ntre un
program Java interpretat i un program C, compilat n cod nativ. Bruce Eckel, n Thinking in
Java", consider c, n medie, un program Java este de aproximativ 20 de ori mai lent dect un
program C echivalent.
Un alt avantaj l constituie garbage collector"-ul, care scutete programatorul de
sarcina dezalocrii memoriei alocate dinamic. Aceast trstur face programarea mai uoar
i elimin o ntreag clas de erori.
Avantaje:
Portabilitate deplin: Orice program scris n Java poate rula (teoretic) pe toate
sistemele de operare importante (Windows, Linux, Macintosh) fr modificri
suplimentare;
Siguran: Java a preluat trsturile pozitive ale C/C++ i a evitat multe din
neajunsuri. Neavnd pointeri, programele Java au mai puine anse de eroare la
accesarea memoriei;
Bazat pe C/C++: Deoarece Java e derivat din C/C++, oricine tie C/C++ poate
nva rapid Java.
119/135
Dezavantaje:
Lent i mai puin eficient: Deoarece este un limbaj interpretat de ctre maina
virtual, programele Java ruleaz mai lent dect programele echivalente n cod
nativ;
Dificil de nvat: Java arat ca C/C++, deci este la fel de greu de nvat ca i
acesta.
9.3.5 C#
C# este cel mai nou limbaj important de programare, dezvoltat de Anders Hejlsberg la
Microsoft. C# este primul limbaj proiectat de la nceput pentru Internet. Este un limbaj
modern care combin cele mai bune caracteristici ale celor mai folosite limbaje de
programare. Odat cu C#, Microsoft a lansat i platforma .NET, care permite compilarea i
interfaarea de programe scrise n limbaje diferite.
C# este foarte asemntor n ceea ce privete sintaxa cu Java, ns pstreaz o apropiere
mai mare de C++. Att Java ct i C# compileaz mai nti ntr-un limbaj intermediar: Java
byte-code, respectiv Microsoft Intermediate Language (MSIL). n C#, compilarea codului
intermediar n cod nativ este ns mai eficient. C# are de asemenea un garbage collector, care
s-a demonstrat matematic c este foarte aproape de optimul posibil. Ca i Java, C# a renunat
la motenirile multiple, n favoarea unui model de motenire simpl extins de motenirea
multipl a interfeelor. Spre deosebire de Java, care a renunat total la pointeri, C# permite
folosirea acestora, dar numai n cazuri speciale, marcate unsafe".
Un alt avantaj l constituie posibilitatea generrii automate a documentaiei pe baza
codului surs.
9.4 Comparaie ntre unele limbaje de programare
Pentru a exemplifica, s considerm implementarea unui algoritm de cutare a
maximului dintr-un ir de numere n timpul introducerii irului respectiv.
Limbajul C:

#i ncl ude <st di o. h>
#i ncl ude <st dl i b. h>
voi d mai n( )
{
i nt di m, i ;
f l oat *vect or ; / / f l oat vect or [ 10] ;
f l oat max;
pr i nt f ( " Di mensi unea vect or ul ui : " ) ;
scanf ( " %d" , &di m) ;
vect or = ( f l oat *) cal l oc( di m, si zeof ( f l oat ) ) ;
f or ( i =0; i <di m; i ++)
{
pr i nt f ( " Vect or [ %d] : " , i +1) ;
scanf ( " %f " , &vect or [ i ] ) ;
i f ( i ==0)
max = vect or [ i ] ;
el se
{
i f ( max < vect or [ i ] )
max = vect or [ i ] ;
}
}
pr i nt f ( " Maxi mul : %f " , max) ;
f r ee( vect or ) ;
}
120/135

Limbajul C++

#i ncl ude <i ost r eam. h>
voi d mai n( )
{
i nt di m;
cout << " Di mensi unea vect or ul ui : " ;
ci n >> di m;
f l oat *vect or ;
vect or = new f l oat [ di m] ;
f l oat max;
f or ( i nt i =0; i <di m; i ++)
{
cout << " Vect or [ " << ( i +1) << " ] : " ;
ci n >> vect or [ i ] ;
i f ( i ==0)
max = vect or [ i ] ;
el se
{
i f ( max < vect or [ i ] )
max = vect or [ i ] ;
}
}
cout << " Maxi mul : " << max;
del et e [ ] vect or ;
}
Limbajul Basic

10 I NPUT " Di mensi unea vect or ul ui : " , di mvect
20 DI M vect or ( di mvect )
30 LET max = O
40 FOR i =l TO di mvect
50 I NPUT ( " Vect or ( " ; i ; " ) : " ) ; vect or ( i )
60 I F i = l THEN LET max = vect or ( i ) : GOTO 80
70 I F max < vect or ( i ) THEN max = vect or ( i )
80 NEXT i
90 PRI NT " Maxi mul : " ; max

O versiune adaptat pentru Visual Basic este:

Pr i vat e Sub Max( )
Di mmax As Doubl e
Di mdi mens As I nt eger
Di mvect or ( di mens) As Doubl e
For i = 1 To di mens
I f i = 1 Then
max = vect or ( i )
El se
I f max < vect or ( i ) Then max = vect or ( i )
Next i
End Sub

Limbajul Pascal

pr ogr amsi mpl u; { Pascal nu este un limbaj case sensitive }
uses cr t ;

var max: r eal ;
121/135
di m, i : i nt eger ;
vect or : ar r ay[ 1. . 10] of r eal ;

begi n
wr i t el n( ' Di mensi unea vect or ul ui : ' ) ;
r eadl n( di m) ;
f or i : =1 t o di mdo
begi n
wr i t el n( ' Vect or [ ' , i , ' ] : ' ) ;
r eadl n( vect or [ i ] ) ;
i f i =1 t hen
max : = vect or [ i ]
el se begi n
i f max < vect or [ i ] t hen
max : = vect or [ i ] ;
end;
end;
wr i t el n( ' Maxi mul : ' , max) ;
end.

Limbajul Java

i mpor t j ava. i o. *;
publ i c cl ass Si mpl e
{
publ i c st at i c voi d mai n( St r i ng[ ] ar gs)
{
Syst em. out . pr i nt l n( " Di mensi unea vect or ul ui : " ) ;
St r i ng s = Syst em. i n. r eadLi ne( ) ;
i nt di m= I nt eger . par seI nt ( s) ;
f l oat [ ] vect or = new f l oat [ di m] ;
f l oat max = 0;
f or ( i nt i =0; i <di m; i ++)
{
Syst em. out . pr i nt l n( " Vect or [ " + ( i +1) + " ] : " ) ;
s = Syst em. i n. r eadLi ne( ) ;
vect or [ i ] = Fl oat . par seFl oat ( s) ;
i f ( i ==0)
max = vect or [ i ] ;
el se
{
i f ( max < vect or [ i ] )
max = vect or [ i ] ;
}
}
Syst em. out . pr i nt l n( " Maxi mul : " + max) ;
}
}
Limbajul C#

usi ng Syst em;
cl ass Si mpl e
{
[ STAThr ead]
st at i c voi d Mai n( st r i ng[ ] ar gs)
{
Consol e. Wr i t e( " Di mensi unea vect or ul ui : " ) ;
st r i ng s = Consol e. ReadLi ne( ) ;
i nt di m= i nt . Par se( s) ;
f l oat [ ] vect or = new f l oat [ di m] ;
122/135
f l oat max = 0;
f or ( i nt i =0; i <di m; i ++)
{
Consol e. Wr i t e( " Vect or [ {0}] : " , i +1) ;
s = Consol e. ReadLi ne( ) ;
vect or [ i ] = f l oat . Par se( s) ;
i f ( i ==0)
max = vect or [ i ] ;
el se
{
i f ( max < vect or [ i ] )
max = vect or [ i ] ;
}
}
Consol e. Wr i t eLi ne( " Maxi mul : {0}" , max) ;
}
}

Limbajul Clips (declarativ)

( def r ul e i nt r od_di m
=>
( pr i nt out t " Di mensi unea vect or ul ui : " )
( asser t ( di m( r ead) ) )
)
( def r ul e i ni t _max
( di m?)
=>
( pr i nt out t " Vect or ( 1) : " )
( bi nd ?val ( r ead) )
( asser t ( vect or ?val ) )
( asser t ( max ?val ) )
( asser t ( i 2) )
)
( def r ul e cont i nue
( di m?d)
?f 1 <- ( i ?i )
( t est ( <= ?i ?d) )
?f 2 <- ( vect or $?vect )
?f 3 <- ( max ?max)
=>
( pr i nt out t " Vect or ( " ?i " ) : " )
( bi nd ?val ( r ead) )
( r et r act ?f 1 ?f 2)
( asser t ( i ( + ?i 1) ) )
( asser t ( vect or $?vect ?val ) )
( i f ( < ?max ?val ) t hen
( r et r act ?f 3)
( asser t ( max ?val ) )
)
)
( def r ul e pr i nt _max
( di m?d)
( i ?i )
( t est ( > ?i ?d) )
( max ?max)
=>
( pr i nt out t " Maxi mul : " ?max cr l f )
)

123/135
Not: gsirea maximului ntr-un ir se poate realiza mult mai uor n Clips:
( def r ul e max
( vect or $? ?v1 $?)
( f or al l ( vect or $? ?v2 $?)
( t est ( <= ?v2 ?v1) )
)
=>
( pr i nt out t " Maxi mul : " ?v1 cr l f )
)

n primul program s-a ncercat ns implementarea algoritmului secvenial. Se vede
astfel diferena de concepie ntre abordrile imperativ i declarativ.
9.5 Utilitare pentru implementare i testare
O gam larg de utilitare sunt valabile pentru dezvoltarea programelor, depanarea i
testarea acestora:
Utilitare de modelare (engl. modeling tools"): Genereaz nucleul (scheletul")
modulelor; genereaz automat declaraii pentru constante, variabile, tipuri pentru
includerea n codul surs al fiecrui modul. Unele utilitare de modelare pot
transforma diagramele reprezentnd apelurile modulelor n apeluri de funcii sau
proceduri complet comentate, dei fr a avea valorile parametrilor actuali. Dac
asemenea utilitare sunt folosite, scrierea codului ncepe prin a completa
scheletul" unui astfel de modul: se completeaz toate apelurile; se introduc
construciile iterative (while, repeat, loop, etc); se introduc construciile
alternative (if, case, etc.) i se adaug n final detaliile de baz ca operaii
aritmetice, operaii de intrare-ieire i alte apeluri sistem;
Generatoare de cod: Transform relaii formale n cod surs. Se utilizeaz n
domenii ca gestiunea bazelor de date i interaciunea cu factorul uman, domenii
caracterizate de un cod repetitiv i de necesitatea de a executa numeroase
operaii de rutin dar eseniale. Deoarece generatoarele de cod sunt din ce n ce
mai mult integrate n metodele de proiectare, va fi posibil de a genera automat
codul surs pentru poriuni din ce n ce mai mari ale componentelor unui sistem.
Chiar dac pentru pri ale sistemului codul va fi scris manual, utilizarea
generatoarelor de cod rmne n continuare avantajoas. Modificri n cerinele
software pot rezulta n schimbri automate n declaraiile datelor i modulelor,
pstrnd i verificnd consistena de-a lungul ciclului de via al produsului;
Editoare: Creeaz i modific codul surs i documentaia.
Editoare senzitive la limbaj: Creeaz cod surs corect din punct de vedere
sintactic. Aceste editoare conin un interpretor care ajut n scrierea unui cod
surs corect din punct de vedere sintactic. Cele mai simple astfel de editoare
recunosc parantezele i realizeaz o aliniere automat care fac programul mai
uor de neles i reduc erorile. E posibil, de asemenea, de a furniza scheme
(tipare) pentru construirea programelor, coninnd headere standard, seciuni
obligatorii pentru declararea constantelor i tipurilor de date. Acestea pot fi
generate automat de utilitarele de modelare. Editoarele care recunosc aceste
scheme pot reduce timpul de dezvoltare i pot preveni erorile;
Analizoare statice: Examineaz codul surs. Analiza static este procesul de
scanare a textului unui program pentru detectarea unor erori:
o identific variabile neutilizate sau utilizate nainte de a fi asignate;
o verific dac valoarea variabilei este n intervalul admis;
o furnizeaz o prezentare a structurii aplicaiei;
124/135
o msoar complexitatea codului n termenii unei metrici;
o transform codul surs ntr-un limbaj intermediar pentru verificare
formal;
o msoar anumite atribute ale codului cum ar fi numrul de linii de cod i
nivelul maxim de imbricare.
Cele mai multe compilatoare furnizeaz unele din caracteristicile analizoarelor statice
(cum ar fi prima caracteristic). Analizoarele statice dedicate de obicei furnizeaz funcii de
analiz static avansate, cum ar fi analiza structurii codului;
Compilatoare: Transform codul surs n cod obiect. Acestea variaz n vitez,
completitudinea verificrilor, uurina utilizrii, folosirea sintaxei standard,
calitatea codului i afirilor i prezena caracteristicilor de programare.
Alegerea compilatorului este de importan crucial. Viteza compilatorului
afecteaz costul produsului i uurina n dezvoltarea, depanarea i ntreinerea
produsului, n timp ce calitatea codului afecteaz performanele produsului n
timpul execuiei. Compilatoarele ar trebui comparate innd cont de viteza lor,
de timpul de execuie al programului i dimensiunea codului. Dimensiunile
stivei i a memoriei heap pot fi, de asemenea, importante. Compilatoarele
variaz mult i funcie de caracteristicile care suport programarea:
o listare complet;
o cross-referenierea;
o dimensiunea datelor i modulelor;
o diagnosticare;
o verificare complet;
o verificarea limitelor vectorilor.
Cele mai avansate compilatoare execut anumite optimizri pentru maini secveniale
sau paralele, ncercnd s descopere i s elimine deficienele codului surs. Aceste optimizri
pot fi impuse prin switch-uri, de exemplu prin directive n codul surs. Utilizatorii ar trebui s
verifice dac optimizrile pe care le doresc sunt implementate n compilatoarele candidat.
Linkeditoare: Reunesc modulele obiect n programe executabile. Acestea sunt
furnizate de main, sistemul de operare sau compilator. De aceea, utilizatorul
are n foarte mic msur controlul asupra alegerii acestora. Este util ca
linkeditorul s determine automat bibliotecile i directoarele pe care trebuie s le
utilizeze i care sunt modulele sau componentele care trebuie linkeditate. Cele
mai multe linkeditoare pot fi controlate de parametri creai de utilitare build sau
make;
Depanatoarele: Localizeaz erori n timpul execuiei programului. Utilizarea
depanatoarelor simbolice interactive este puternic ncurajat, mai ales pentru
verificare. Un depanator bun este integrat cu editorul i
compilatorul/interpretorul i permite o gam de moduri de investigare: pas cu
pas, trasare prin breakpoint, vizualizarea valorilor variabilelor, setarea unor
condiii;
Analizoarele dinamice: Examineaz programele n curs de execuie. Analiza
dinamic este procesul de msurare a resurselor (timp CPU, timp intrare-ieire,
memorie) consumate de fiecare modul i linie de cod. n contrast cu analizoarele
statice, cele dinamice se folosesc pentru programe n curs de execuie.
Analizoarele dinamice se mai numesc i profilers. Ele mai pot fi folosite i
pentru a determina dac toate instruciunile programului au fost executate n
timpul testului (test de acoperire). Unele analizoare dinamice verific dac
programul utilizeaz corect memoria, de exemplu, verific dac apelurile pentru
alocarea memoriei au corespondent n apeluri pentru dezalocare, determinnd
125/135
astfel scprile de memorie (engl. memory leaks"). Analizoarele dinamice pot
localiza prile sistemului care cauzeaz slabe performane ale acestuia i pot
detecta erori de programare (exemplu: iniializri inutile);
Utilitare de test: Testeaz module i programe. Acestea suport una sau mai
multe din urmtoarele funcii: generarea i gestiunea datelor de test, verificarea
automat a rezultatelor, diagnosticarea erorilor i depanarea. Utilitarele generale
de test pot genera un volum mare de date de intrare;
Procesoare de text: Sunt utilizate pentru crearea documentelor;
Generatoare de documentaie: Genereaz documentaie utilizator din codul
surs. Menin consistena dintre cod i documentaie i fac procesul de
documentare concurent cu cel de codare. Generatoarele de cod pot include
utilitare pentru generarea automat a documentaiei;
Utilitare pentru managementul configuraiei: nregistreaz versiunile modulelor
i fiierelor. Sunt organizate n baze de date i controleaz dezvoltarea
sistemelor cnd multe module pot exista n diferite versiuni. Unele utilitare
permit specificarea unei configuraii (m module n n versiuni), compilare
automat, linkeditare i arhivare a acestora. Este recomandat folosirea
utilitarelor pentru managementul configuraiei cnd numrul de module sau de
versiuni devine foarte mare.
9.6 Concluzii
In concluzie, procesul de implementare este dificil de caracterizat i de descris. Aici se
regsesc aspecte ale analizei cerinelor, ale specificaiilor i proiectrii. Programatorul va
trebui s fac un numr de importante compromisuri ntre sigurana produsului, costul,
eficiena, timpul de execuie, posibilitatea lui de ntreinere, etc. Sarcina cea mai dificil a
programatorului este de a realiza aceast pluralitate a scopurilor. Este dificil de a spune care
va fi rezultatul acestor compromisuri att timp ct produsul nu este complet i testat. Odat ce
produsul a fost finalizat, n sensul c toate prile sale componente au fost reunite i sistemul
poate funciona, ncepe etapa urmtoare a procesului de dezvoltare i anume faza testrii.
126/135
10 Psihologia si etica programrii
10.1 Programarea ca activitate uman
Considerm cu prea mult uurin programele ca fiind doar pentru compilare. Ar
trebui s le luam n calcul i ca mijloace de comunicare intre noi i ceilali, ca mijloace de
exprimare a propriilor gnduri ctre nou nine. " (Green, 1990)
In prezent se recunoate importana nevoilor utilizatorului n momentul conceperii
sistemelor interactive dar, pn n 1980, aceste nevoi nu prea au fost luate n calcul. De ce ar
fi de dorit introducerea comentariilor n programe? De ce ar fi mai bine s nu se foloseasc
go to"-uri? De ce conceptul X ar fi mai bun dect conceptul 7? De ce utilizatorii unui anumit
sistem se simt pierdui i se enerveaz, n timp ce utilizatorii unui sistem similar, dar cu o
interfa grafic diferit, dimpotriv, lucreaz cu plcere?
Cele mai multe cri de programare i inginerie software dau propriile rspunsuri
acestor ntrebri. De cele mai multe ori rspunsurile nu sunt deloc fondate. Argumentele
aduse se bazeaz mai mult pe intuiie i presupusa experien a cititorului. Totui intuiia nu
este suficient. Este nevoie de teorii susinute de dovezi empirice solide i de experimente
bine puse la punct pentru a se putea gsi rspunsuri fondate la ntrebri ca cele de mai sus.
Tom Love a introdus termenul de psihologie a programrii pentru a arta comuniunea"
dintre psihologie i informatic. Psihologia programrii prezint factorii umani legai de
conceperea i utilizarea programelor, cum ar fi:
uurina cu care programatorii manipuleaz diverse construcii ale limbajelor de
programare;
probleme legate de capacitatea de nvare a programrii;
predispoziia spre erori si robusteea construciilor unui limbaj;
tipurile de erori fcute de programatori;
uurina de a utiliza aplicaii software, de exemplu procesoarele de text, de ctre
neiniiai;
rolul help-ului on-line.
Primele cercetri empirice despre maniera n care lucreaz programatorii au fost sever
criticate; nevoia unei metodologii solide pentru aceste experimente a fost subliniat n mod
repetat, n ultimii ani calitatea experimentelor legate de factorii umani a crescut i au fost
formulate cteva teorii utile.
In momentul cnd se fac experimente, o atenie sporit trebuie acordat aplicabilitii
ecologice (adic a relevanei rezultatelor n cazul generalizrii n situaii reale). Aplicabilitatea
ecologic trebuie luat n calcul att atunci cnd e vorba de utilizarea practic a interfeei
grafice ct i atunci cnd se fac studii experimentale asupra comportamentului
programatorului. Factorii care trebuie luai n considerare sunt:
Mulimea subiecilor: Diferenele ntre indivizi influeneaz rezultatele obinute. Multe
dintre testele aplicate programatorilor au avut drept subiect programatori fr experien, de
exemplu studeni. Alte experimente au artat c aceleai rezultate nu sunt neaprat valabile i
n cazul programatorilor profesioniti. Asemenea diferene ntre experi i nceptori apar i
atunci cnd se evalueaz interfeele grafice. Diferenele de motivare pot avea, de asemenea,
un rol foarte important. Utilizatorii reali sunt, de obicei, influenai de producie. De exemplu,
ei nu citesc manualele de utilizare; au lucruri mai bune de fcut;
Contextul sistemului: Pentru a testa o anumit construcie dintr-un limbaj,
experimentatorii folosesc limbaje simplificare (limbaje jucrie", engl. toy languages"). Intr-
un caz real, caracteristicile limbajului interacioneaz. Interfeele utilizator sunt deseori testate
izolat, astfel nct nu este luat n calcul consistena cu alte aplicaii. Nu este foarte clar dac
rezultatele astfel obinute pot fi transferate direct n practicile reale;
127/135
Dimensiunea problemei: Din motive practice, majoritatea testelor folosesc aplicaii
mici, iar problemele care apar sunt clare. i n acest caz generalizarea la aplicaii mari i la
probleme vagi se poate fi pus sub semnul ntrebrii. Aceast situaie este cunoscut sub
numele de eroarea examenului colar";
Contextul de lucru: In realitate oamenii sunt deseori confruntai cu suprapunearea mai
multor sarcini (n timp ce ncearc s gseasc o eroare, sun telefonul).
Programatorii scriu programe. Ei exprim algoritmi folosind construcii proprii unui
limbaj de programare. Pentru aceasta, trebuie s cunoasc sintaxa i semantica acestor
construcii. Mai trebuie s tie cum sa construiasc programe logice din blocurile de
construcie pe care le au la dispoziie. Cu ct tim mai bine s folosim un limbaj de
programare, cu att mai bine vom reui s ndeplinim aceste sarcini.
De obicei, simpla scriere de cod nu este singura sarcina pe care trebuie s o
ndeplineasc programatorul. Acesta trebuie s conceap programul, s-1 testeze,
documenteze i s ofere suport. Programatorul trebuie s neleag i programele scrise de
altcineva. De multe ori programele sunt mai mult citite dect folosite practic.
Un model descriptiv despre modul n care trebuie s-i desfoare lucrul programatorii
ar trebui s includ toate aceste activiti prezentate mai sus.
Un model cognitiv al memorie umane distinge trei tipuri de memorie: memoria
senzorial, de scurt durat i de lung durat. Memoria senzorial reine pentru un timp
foarte scurt informaiile oferite de sistemul perceptiv, n vederea prelucrrii acestora.
Informaiile cu un anumit grad de relevan sunt pstrate apoi n memoria de scurt durat.
Aceasta are o capacitate limitat. Miller (1956) estimeaz dimensiunea ei la aproximativ 7
uniti. Nu cunoatem cu precizie dimensiunea exact, dar este important de reinut este c are
o capacitate limitat.
Entitile din memoria de scurt durat nu necesit conexiuni cu informaii elementare.
Oamenii combin informaiile n uniti ct mai mari. Acest proces este numit chunking, iar
unitile de informaie sunt numite chunks (buci, poriuni). De exemplu, secvena de cifre
234567" poate ocupa 5 intrri n memoria de scurt durat. Totui, dac este recunoscut ca
fiind un numr de telefon, este codat i ocup o singur intrare. Astfel intrrile n memorie
de scurt durat pot fi vzute ca etichete pentru o anumit informaie, ca o cifr, un numr de
telefon sau o rutin de sortare. Cnd informaia este prelucrat i manipulat pentru
executarea unor operaii, memoria de scurt durat se comport ca o memorie activ, ca i
registrele unui calculator.
Informaiile relevante pe termen lung sunt pstrate n memoria de lung durat.
Avnd la baz acest model, apar dou ntrebri importante: ce tip de cunotine posed
programatorul n memoria de lung durat i ce tip de procese cognitive apar n vederea
gsirii soluiei n memoria sa activ? Programatorii profesioniti dein un vast i complex
volum de informaii n memoria de lung durat. Acestea reprezint concepte generale,
nefiind direct legate de un anumit limbaj de programare i privesc att concepte de nivel
sczut (de exemplu atribuirea unei variabile), ct i concepte de nivel nalt (de exemplu un
algoritm de sortare). Acestea sunt cunotine semantice.
Memoria de lung durat mai conine i cunotine sintactice, ca de exemplu formatul
construciei while" din C. Cunotinele sintactice sunt arbitrare i deci uor de uitat. E mai
uor de nvat o structur sintactic atunci cnd structura semantic corespunztoare este deja
cunoscut. Aa se explic faptul c nvarea unui prim limbaj de programare se dovedete
mai dificil dect nvarea urmtorului (sau urmtoarelor). Dup un timp este necesar numai
stpnirea unei sintaxe noi. Desigur, acest lucru nu se ntmpl dac noul limbaj are o
structur semantic diferit (de exemplu un limbaj declarativ cum ar fi CLIPS fa de un
limbaj procedural ca C-ul).
128/135
Cunoaterea semantic trebuie nvat i asimilat. Cunotinele sintactice pot fi
stpnite prin simple exerciii. Aceste dou tipuri de cunotine nu sunt integrate mpreun n
memorie. De exemplu, nelegerea sensului unei sarcini nu este legat neaprat de modul n
care aceasta este transpus ntr-un anumit limbaj de programare.
i informaiile din memorie de lung durat pot fi descompuse din punctul de vedere al
domeniilor la care se refer. Pe lng cunotine informatice, un programator cunoate, de
asemenea, unul sau mai multe domenii de aplicabilitate. Cnd avem de-a face cu probleme
concrete, cunotinele din diferite domenii sunt folosite pentru a obine un rezultat.
Pentru a finaliza acest model, trebuie s investigm procesul rezolvrii problemelor
asociat cu sarcina programatorului. Deosebim aici patru etape n rezolvarea unei probleme:
nelegerea problemei;
realizarea unui plan, descoperirea unei strategii de obinere a soluiei;
executarea planului;
verificarea rezultatelor.
Dac unui programator i se d o problem, presupunem c acesta folosete mai nti
memoria de scurt durat pentru a reine specificaiile. Cnd problema este analizat, sunt
folosite i informaii generale din memoria de lung durat. Aceti sunt primii pai spre
obinerea soluiei.
In a doua etap se utilizeaz tehnici de rafinare pas cu pas i proiectarea top-down sunt
susinute. Folosind rafinarea pas cu pas, este formulat mai nti o prim soluie, pe plan
general. Apoi, problema este mprit n una sau mai multe subprobleme, pentru care se caut
soluii.
Devierea de la proiectarea top-down este o consecin a proiectrii defectuoase. Totui,
o descompunere top-down absolut este doar un caz particular, atunci cnd soluia se cunoate
precis. In practic, programatorii trec repede de la un nivel de abstractizare la altul. Dac
recunosc o soluie parial a unei pri a problemei, ei ncep un faz de proiectare detaliat
pentru implementarea soluiei respective. Invers, dac dezvoltarea unei soluii conduce la
descoperirea unor cerine suplimentare, acestea pot deveni centrul ateniei.
O teorie interesant (Soloway, 1986) susine c programatorii rezolv problemele
folosind planuri de programare, fragmente de program care corespund unor aciuni stereotipe
i reguli care descriu convenii de programare. De exemplu, pentru a calcula suma unui ir de
numere, progrmatorul utilizeaz un contor-sum care este iniializat cu O i la care, n cadrul
buclei, se adun urmtoarea val orare din ir. Planurile de programare sunt legate de conceptul
de jalon. Jaloanele sunt cunotine care indic prezena unei anumite structuri sau operaii. De
exemplu, o idee fundamental n rutinele de sortare este interschimbarea a dou valori. Dac
ni se prezint un program care conine operaii de interschimbare, imediat ne gndim c ar
putea fi un program de sortare.
Experimentele efectuate (Wiedenbeck, 1991) au artat c programele de sortare care
conineau operaii de interschimbare explicite sunt mult mai uor recunoscute ca atare dect
programele n care interschimbarea este mascat. S-a constatat c prezena jaloanelor false
induc n eroare programatorii. Programatorii experimentai se bazeaz mai mult pe prezena
jaloanelor dect nceptorii. Acest fapt reflect asocierea mai puternic a jalonului cu un
anumit tip de program, datorit experienei. De asemenea, experii ncearc s recunoasc"
pri mari din program, s neleag ideea din program, fr s ia n calcul detaliile.
10.1.1 Scrierea programelor
Aproape toate textele despre programare conin sfaturi menite s creasc nelegerea
programelor. Aceste sfaturi privesc probleme ca: adugarea comentariilor, numele sugestive
ale variabilelor, alinierea etc. Ne putem ntreba n ce circumstane aceste sfaturi vor produce
rezultate mai bune. Ce ne intereseaz este efectul acestor indicaii perceptive n nelegerea
129/135
programelor. Cnd studiem codul unui program, construim o structur semantic intern care
s corespund programului. Elementele menionate mai sus uureaz procesul.
10.1.1.1 Comentariile
Experii nu sunt ntru totul de acord cu felul si volumul de comentarii ce trebuie incluse
n codul surs. Orice carte de programare ne va spune s documentm programele create, dei
acestea pot avea i efecte negative. De multe ori comentariile nu sunt rescrise n momentul
modificrii codului. Astfel, comentariile mai vechi pot s induc n eroare cititorul.
Shneiderman (1980) prezint un experiment n care 62 de studeni au studiat un
program FORTRAN lung de 26 de linii. Un grup (H) a primit programul avnd comentarii de
nivel nalt la nceputul codului, care descriau funcionalitatea programului. Cel de-al doilea
grup (L) a primit un cod avnd comentarii detaliate pentru instruciunile folosite. Ambelor
grupuri li s-a cerut s fac mici schimbri asupra programului. De asemenea, li s-a mai dat i
un test de memorie: ct de multe linii pot fi reproduse. La ambele teste, grupul H a obinut
punctaj mai mare dect L.
Woodfield (1981) a studiat legtura ntre modularitate i comentarii. Pentru acest
experiment au fost testai, n mare parte, programatori experimentai. Woodfield a folosit
patru variante ale unui program de 100 de linii: o variant monolitic format dintr-un singur
modul, dou variante folosind descompunere funcional, i o variant bazat pe abstractizare.
Toate versiunile avnd comentarii au obinut un scor mai bun dect cele fr. Totui, pentru
versiunea monolitic, diferenele au fost mici. Versiunea abstract a obinut performanele
cele mai bune.
Comentariile nu sunt stocate n structura semantic intern construit. Ele doar conduc
la o obinere mai uoar a acesteia. Programatorii nceptori sunt mai ateni la comentarii
dect cei experimentai. Pentru programe scurte, profesionitii nu au nevoie de comentarii,
mai ales dac structura programului poate fi obinut prin alte mijloace. De exemplu, se pot
folosi nume mnemonice, care sunt suficiente pentru a determina structura semantic a
programului. Cnd numele nu au neles, comentariile reprezint singurul ajutor. Combinaia
ntre nume fr sens i programe monolitice poate explica dificultile pe care le ntmpin
programatorii.
Comentariile care explic funcionalitatea sunt preferate comentariilor de nivel sczut.
Comentariile nu trebuie s imite codul, ca n exemplul urmtor:
x = O; // x devine O
Comentariile corecte ajut la construirea structurii semantice interne. Cnd scriem
comentarii, trebuie s folosim terminologia domeniului, pentru a micora diferena dintre
problem i domeniul programului. De exemplu, este mai bine s folosim
// Caut studentul cu media cea mai mare
dect
// Caut cea mai mare valoare din tabel
10.1.1.2 Numele variabilelor
Dac ne confruntm cu un program n care variabilele sunt numite P, Q, i R, vom
ntmpina dificulti n a nelege semnificaia lor. Pe de alt parte, mnemonice de forma cont
sau factur reflect un anumit rol semantic i determin o legtur direct ctre ceea ce
reprezint ele. Aadar, mnemonicele faciliteaz procesul de nelegere. Totui, dac cel care
citete programul cunoate deja algoritmul, numele variabilelor nu mai prezint o importan
deosebit.
130/135
10.1.1.3 Indentaia
Indentaia (engl. spaiere, zimuire) se refer la determinarea distanei fa de margine
(n caractere albe) a liniilor de program, astfel nct s poat fi puse n eviden anumite
structuri ale programului.
Scopul indentaiei este creterea lizibilitii codului. Stilul indentaiei poate diferi
considerabil, chiar dac este folosit acelai limbaj de programare. Muli programatori i-au
dezvoltat propriul stil de aliniere. Ei folosesc acest stil cnd citesc programe sau cnd i
construiesc structura intern corespunztoare. Cnd sunt confruntai cu un program cu o
indentaie diferit, forma vizual diferit poate stnjeni, cel puin la nceput, nelegerea
codului.
In prezent exist i alte mijloace de punere n eviden a structurii unui program. De
exemplu, cuvintele cheie pot fi scrise cu litere aldine iar comentariile cu litere cursive.
10.1.2 Concepte ale limbajelor de programare
n paragraful anterior am discutat cteva probleme de notaie independente de limbajul
de progrmare folosit. Acum vom vorbi despre concepte specifice limbajelor de programare.
O ipotez din lingvistic afirm c modul nostru de gndire este ngrdit de limbajul n
care ne exprimm. Reciproc, modul nostru de a gndi limiteaz utilizarea limbajului.
Construciile limbajului ar trebui, de asemenea, s fie adaptate la sarcinile care trebuie
ndeplinite de ctre programator. De exemplu primele limbaje de programare ofereau doar o
singur construcie pentru iteraie. Limbajele recente ofer mai multe variante: for", while".
Totui resimim n continuare nevoia de a iei dintr-o bucl de la mijloc, deoarece acest lucru
corespunde aproape perfect modului nostru de gndire. Limbajele de programare ar trebui
concepute n aa fel nct s faciliteze o exprimare ct mai natural a algoritmilor.
Cercetrile experimentale referitoare la problemele de notaie s-au ocupat i de
structurile decizionale. Ele au artat c sunt preferate construciile if-then-else" fa de
construciile if-goto", deoarece sunt mai uor de folosit. Construciile din prima categorie
sunt i mai uor de indentat, i astfel codul devine mai uor de citit i neles. De asemenea,
fiind construcii de nivel mai nalt, ele sunt mai puin complexe.
Cnd se pune problema depanrii codului, prezena instruciunilor goto" crete
dificultatea procesului i a timpul necesar realizrii sale. Un experiment realizat de Benander
(1990) a evideniat urmtoarele concluzii:
Programele cu rezultate eronate aveau de dou ori mai multe goto"-uri dect
programele cu rezultate corecte.
Programele cu goto"-uri aveau o structur cu mult mai proast dect cele fr goto";
Timpul mediu pentru depanarea programelor cu goto"-uri era mai mare dect cel al
programelor fr goto".
Acest tip de experiment demonstreaz c alegerea structurilor de control, structurate sau
nestructurate, are o importan major. Aceast experien susine anecdota care spune c
numrul de erori pe care le are un program este direct proporional cu numrul de goto"-uri.
Totui, un program fr goto-uri nu este obligatoriu fr erori.
Un alt rezultat important este faptul c utilizarea structurilor i claselor crete gradul de
abstractizare al programului, cu efecte benefice asupra nelegerii. Astfel se explic i tendina
de nlocuire a programrii structurate cu programarea orientat obiect.
n timpul proiectrii, problema este descompus n module. Pentru programe de mici
dimensiuni, avantajul modularizrii nu este evident. Totui, atunci cnd dimensiunea
programelor crete, tehnica modularizrii devine foarte important, iar modificrile sunt mult
mai rapide dect n cazul programelor monolitice echivalente.
131/135
10.1.3 Interfaa cu utilizatorul
Un sistem n care interaciunile apar la un nivel inteligibil pentru utilizator va fi acceptat
mai repede dect un sistem n care acest lucru nu se ntmpl. Dac sistemul este disponibil la
intervale neregulate sau d mesaje de eroare incomprehensibile, este foarte posibil ca
utilizatorii (mai ales nespecialiti) s nu-1 accepte. De aceea, n multe cazuri, interfaa cu
utilizatorul necesit mai mult de 30% din cod, deoarece este un factor critic pentru succesul
sau eecul sistemului respectiv.
Exist trei factori care influeneaz interaciunea dintre utilizatorul uman i calculator:
Modelul mental al utilizatorului: Este modelul mainii pe care l creeaz utilizatorul, pe
baza educaiei i cunotinelor despre sistem sau domeniul aplicaiei. In timpul interaciunii cu
sistemul, acest model este utilizat pentru a planifica aciunile, pentru a prezice i interpreta
reaciile sistemului. Modelul mental reflect nelegerea utilizatorului asupra a ceea ce conine
sistemul, cum funcioneaz acesta i de ce. Modelul este determinat iniial de meta-
comunicare, adic instruire i documentare. El evolueaz n timp, pe msur ce utilizatorul
dobndete o nelegere din ce n ce mai exact asupra sistemului;
Imaginea sistemului: Include toate elementele sistemului cu care vine n contact
utilizatorul. Modelul mental al utilizatorului se bazeaz n cea mai mare parte pe aceast
imagine. Ea poate include stilul de interaciune, forma i coninutul schimbului informaional,
chiar i aspectul fizic al sistemului, dispozitivele externe conectate etc.;
Modelul conceptual: Este modelul precis din punct de vedere tehnic creat de
proiectani, o reprezentare complet a sistemului asupra tuturor aspectelor legate de
interaciunea cu utilizatorul. Pe baza acestui model reacioneaz sistemul la aciunile
utilizatorului.
Problema fundamental a realizrii unei interfee ntre om i calculator este apropierea
ct mai mare a modelului conceptual de modelul mental al utilizatorului.
Utilizatorul unui sistem interactiv trebuie s ndeplineasc anumite sarcini: trimiterea
unui email, tehnoredactarea unui document etc. Toate aceste sarcini au o anumit structur,
prezent n memoria uman. Interaciunea om-calculator trebuie s aib aceeai structur, pe
ct posibil. Dac o anumit aciune este perceput ca o singur unitate conceptual n
domeniul sarcinii, este derutant acionarea unui ntreg ir de comenzi pentru a realiza efectul
dorit. De asemenea, sarcinile care sunt apropiate n domeniul problemei (adic sunt conectate
semantic) trebuie s fie apropiate i n interaciunea cu sistemul computerizat.
Inginerii programatori sunt nclinai s modeleze interfaa cu utilizatorul dup structura
mecanismului de implementare i nu dup structura domeniului problemei. De exemplu, un
program poate solicita introducerea secvenei T10 2" pentru a obine IO2, doar pentru c
sistemul recunoate i prelucreaz mai uor prima variant, n acelai fel, documentaia
urmrete de multe ori detaliile i modelele de implementare, iar mesajele de eroare sunt
formulate n termeni care reflect punctul de vedere al programatorului i nu problemele
utilizatorului. Pe lng cunotinele specifice sarcinii, cunotinele generale joac de
asemenea un rol important n construirea modelului mental. Dac o combinaie de taste
CTRL+J" ntr-un editor de text mut cursorul cu o linie mai jos, utilizatorul poate deduce c
apsarea CTRL+S" mut cursorul cu o linie mai sus. Dac ns aceast combinaie are ca
efect tergerea fiierului, acest lucru va produce confuzie i frustrare.
Noile cunotine sunt integrate cunotinelor existente. Limitrile memoriei de scurt
durat i ateniei joac i ele un rol. Secvenele lungi de comenzi, meniurile cu un mare numr
de elemente, nesigurana asupra locului unde ne aflm" au ca efect stnjenirea interaciunii.
Aceste aspecte sunt cunoscute sub denumirea de ncrcare cognitiv. Pe msur ce ncrcarea
cognitiv crete, sistemul devine mai greu de nvat, utilizatorul obosete mai repede i
ncepe s fac mai multe greeli.
132/135
De fiecare dat cnd omul ncepe s nvee ceva, el traverseaz o curb de nvare.
Acelai fenomen apare i n cazul unui program. Viteza cu care utilizatorul traverseaz curba
de nvare corespunztoare programului i devine expert este o msur important a
complexitii acelui program. Aceast msur este n acelai timp un indicator mai bun al
utilizabilitii sistemului dect noiuni subiective precum interfa prietenoas".
O alt problem este consistena interfeei. Aceasta nu trebuie dus la extrem, n unele
cazuri, trebuie realizat un compromis ntre consisten i funcionalitate. S considerm un
exemplu n care consistena a fost sacrificat n favoarea unei scheme care reflect mai bine
sarcinile utilizatorului. In figura l, sunt prezentate dou configuraii posibile pentru tastele
sgei. Modelul stea este un model consistent. Totui, studiile efectuate au artat c T-ul ntors
este cea mai utilizabil configuraie. Creatorii de jocuri pe calculator cunosc acest lucru de
mult timp. De aceea, i n jocurile mai vechi tastele folosite pentru direcii erau, de exemplu,
W, A, S, D i nu W, A, Z, S.

Figura 1. Dispunerea tastelor sgei
Pe msur ce utilizatorul traverseaz curba de nvare, mai devreme sau mai trziu el
atinge un nivel acceptabil pentru el la momentul respectiv, dei nu este nc expert. Acest
fenomen apare la un mare numr de aplicaii. De exemplu, majoritatea utilizatorilor de Linux
cunosc bine numai o submulime a comenzilor disponibile. Despre o alt submulime de
comenzi au doar o idee vag, ns nu le cunosc exact funcionalitile. Despre restul de
comenzi, utilizatorii respectivi nu au auzit.
Prin instruire i documentare, utilizatorul i construiete mai nti o imagine despre
facilitile oferite de sistem i apoi ncearc s realizeze ceva practic ct mai devreme, nainte
s aib o nelegere deplin asupra sistemului. Dac nu beneficiaz de ajutor n continuare,
sunt mari ansele s nu neleag niciodat noiunile respective.
Pentru submulimea de comenzi abia cunoscute, se recomand un sistem de help pasiv,
on-line sau off-line (sub form de documentaie). Pentru comenzile necunoscute de utilizator,
se recomand un help activ, care s-1 ndrume pe utilizator i s-i explice noile noiuni
necunoscute ntlnite.
Pentru realizarea interfeei grafice cu utilizatorul, se recomand urmtoarele principii de
proiectare: a) Dialog simplu i natural: Dialogurile nu trebuie s conin informaii irelevante.
Fiecare unitate suplimentar de informaie concureaz cu alte uniti relevante pentru
atragerea ateniei. Informaiile trebuie s apar ntr-o ordine logic i natural;
b) Limbaj potrivit utilizatorului: Dialogurile trebuie s utilizeze concepte i fraze
familiare utilizatorului. Dialogul nu trebuie exprimat n termeni legai de calculatoare;
c) Minimizarea ncrcrii mnezice: Utilizatorul nu trebuie s fie nevoit s rein
informaii dintr-o parte a dialogului n alta. Trebuie s existe modaliti simple de a descoperi
ce trebuie fcut n continuare, unde se poate ntoarce i unde s primeasc instruciuni
generale de utilizare;
d) Consisten: Utilizatorii nu trebuie s se ntrebe dac anumite cuvinte diferite
nseamn acelai lucru;
e) Feedback: Sistemul trebuie s informeze permanent utilizatorul asupra a ceea ce se
ntmpl. Chiar dac unele aciuni necesit mai mult timp, utilizatorul trebuie s dispun de
un indicator (de exemplu procentual) care s-1 informeze despre progresul aciunii;
133/135
f) Ieiri marcate clar: Utilizatorii fac greeli i pot alege funcii nepotrivite. Trebuie s
existe o modalitate prin care acetia s poat iei din starea nedorit fr a fi nevoie de un
lung dialog cu sistemul;
g) Scurtturi (engl. shortcuts"): Utilizatorii nceptori nu sunt incomodai de
dialogurile ample, deoarece se simt n siguran i astfel pot nva mai uor sistemul.
Utilizatorii experimentai nu mai au nevoie de aa ceva, se simt chiar incomodai n astfel de
situaii i de aceea sistemul trebuie s le permit s sar peste paii bine cunoscui;
h) Mesaje de eroare potrivite: Mesajele de eroare trebuie exprimate n limbaj natural i
nu trebuie s se refere la starea intern a sistemului. Ele trebuie s specifice clar eroare i s
propun soluii de rezolvare;
i) Prevenirea erorilor: Este mai bine ca sistemul s previn eventualele erori. De
exemplu, dac utilizatorul dorete s prseasc programul, sistemul trebuie s-1 ntrebe dac
vrea sai salveze mai nti datele.
10.2 Etica programrii
Programarea este rezultatul unui comportament uman intenionat, realizat de persoane
cu anumite valori (i deci etic). Tehnologia nu este neutr din punctul de vedere al valorilor.
Chiar i scrierea unui program simplu presupune, ntr-un anumit fel, valorile programatorului.
Mai mult, programele sunt mijlocare de comunicare, codul surs este o form de exprimare.
In consecin, prin codul scris, programatorii au ocazia s-i comunice valorile.
10.2.1 Codul etic IEEE
Un exemplu de cod etic este cel al IEEE (The Institute of Electrical and Electronics
Engineers, 1990), care conine 10 puncte:
a) acceptarea responsabilitii de luare a deciziilor inginereti n conformitate cu
sigurana, sntatea i bunstarea public i dezvluirea prompt a factorilor care ar putea
pune n pericol oamenii i mediul;
b) evitarea conflictelor de interese reale sau percepute ori de cte ori acest lucru este
posibil i dezvluirea lor ctre prile implicate atunci cnd asemenea conflicte exist;
c) corectitudinea i realismul cerinelor sau estimrilor bazate pe date disponibile;
d) respingerea mitei sub toate formele ei;
e) perfecionarea nelegerii tehnologiei, aplicaiilor sale adecvate i a consecinelor
poteniale; f) meninerea sau perfecionarea propriei competene tehnice i asumarea
rspunderii pentru sarcinile care i privesc pe alii numai n cazul calificrii prin instruire sau
experien sau dup dezvluirea complet a limitrilor legate de acestea;
g) cutarea, acceptarea i acordarea de critici oneste ale lucrrilor tehnice, recunoaterea
i corectarea erorilor i creditarea adecvat a contribuiilor altora;
h) tratarea neprtinitoare a tuturor persoanelor, fr a ine seama de factori precum ras,
religie,
sex, handicap, vrst sau naionalitate; i) evitarea defavorizrii altora, a proprietii,
reputaiei sau serviciului lor prin aciuni incorecte
sau ruvoitoare; j) asistena acordat colegilor n dezvoltarea lor profesional i n
respectarea prezentului cod
de etic.
10.2.2 Legea drepturilor de autor
In Romnia, legea drepturilor de autor (numrul 8 din 14 martie 1996) recunoate i
garanteaz dreptul de autor asupra operelor de creaie intelectual, literar, artistic sau
tiinific, incluznd i programele de calculator.
134/135
Ca i alte opere protejate, precum scrierile literare, operele de art plastic, operele
cinematografice, programele pentru calculator sunt opere de creaie intelectual, care nu sunt
rezultate ale unei munci mecanice, executate cu mijloace tehnice obinuite sau cu ajutorul
unor cunotine ce stau la ndemna oricui. Programele de calculator sunt opere de creaie
intelectual, a cror valoare nu este dat de suportul material pe care programul n sine este
fixat i nici de munca depus pentru realizarea acestor suporturi (de exemplu dischete,
CDROM-urile). Valoarea protejat de lege este chiar creaia intelectual original
concretizat n programul pentru calculator i n materialele asociate, precum manualele de
utilizare.
Legea romn protejeaz programele de calculator independent de valoarea i destinaia
lor concret. Protecia acordat de lege nu se oprete numai la obiectul dreptului de autor. Este
protejat deopotriv i titularul acestui drept, autorul programului de calculator respectiv.
Autorul programului are dreptul de a decide dac, n ce mod i cnd va fi utilizat opera sa,
inclusiv de a consimi la utilizarea operei de ctre alii. Acest drept se refer la autorizaia de
reproducere integral sau parial a programului de calculator i la difuzarea acestuia.
Consimmntul pe care titularul dreptului de autor l d unei persoane pentru a putea
reproduce, folosi, difuza sau importa copii ale unui program de calculator, se concretizeaz n
practic n licene. Ele sunt documentele care probeaz c reproducerea, folosirea, difuzarea
unui program de calculator de ctre o anumit persoan s-a realizat cu consimmntul
autorului.
Lipsa licenelor echivaleaz cu lipsa autorizrii din partea autorului. Importana acestor
licene este evident, ntruct desfurarea activitilor menionate fr aceste licene
reprezint infraciuni, pedepsite cu nchisoare de la 3 luni la 3 ani sau cu amend de la
700.000 la 7 milioane de lei, dac nu constituie infraciune mai grav.
10.2.3 Licena public general GNU
Licenele majoritii programelor sunt concepute pentru a priva utilizatorul de libertatea
de a modifica i distribui programele respective. In contrast, intenia Licenei Publice
Generale GNU este de a garanta libertatea de a distribui i modifica programele i de a se
asigura c programele sunt libere pentru toi utilizatorii. Libertatea programelor nu implic
neaprat absena costului. Licena GNU este conceput pentru a garanta libertatea de a
distribui copii ale programelor libere (i de a oferi acest serviciu contra cost, dac se dorete
acest lucru dorii), de a obine codul surs, de a schimba programul sau a folosi poriuni din el
n noi programe libere.
Pentru protecia autorilor, licena asigur faptul c nu exist nici un fel de garanie
pentru un program liber. Dac programul este modificat de altcineva i distribuit mai departe,
beneficiarii programului trebuie s tie c ceea ce au nu este originalul, n aa fel nct nici o
problem introdus de altcineva nu va avea un efect negativ asupra reputaiei autorilor iniiali.
Orice program liber este n mod constant ameninat de patentele software. Licena GNU
dorete evitarea pericolului ca cei ce redistribuie programe libere s obin patente, practic
transformnd programul ntr-unul aflat sub controlul total al persoanei sau instituiei ce deine
patentul (engl. proprietary"). Pentru a preveni aceast situaie, licena GNU consider c
orice patent trebuie acordat fie n aa fel nct s poat fi folosit gratuit i fr restricii de
oricine, fie deloc.
Dintre termenii i condiiile licenei GNU, menionm:
Putei copia i distribui copii nemodificate ale codului surs al Programului n forma n
care l primii, prin orice mediu, cu condiia s specificai vizibil pe fiecare copie autorul i
lipsa oricrei garanii, s pstrai intacte toate notele referitoare la aceast Licen i la absenta
oricrei garanii i s distribuii o copie a acestei Licene cu fiecare copie a Programului.
135/135
Putei pretinde o retribuie financiar pentru actul fizic de transfer al unei copii, i putei oferi
garanie contra cost.
Putei efectua modificri asupra copiilor Programului (sau asupra oricror poriuni ale
sale), crend astfel un "proiect bazat pe Program". Copierea i distribuirea unor asemenea
modificri sau proiecte se pot face conform termenilor seciunii precedente (1), doar dac
toate condiiile urmtoarele sunt ndeplini te:
o Toate fiierele modificate trebuie s conin note foarte vizibile menionnd faptul c
dumneavoastr le-ai modificat, precum i data fiecrei modificri;
o Orice proiect pe care l distribuii sau publicai, care n ntregime sau n parte conine
sau este derivat din Program (sau orice parte a acestuia), trebuie s poat fi folosit de oricine,
gratuit i n ntregime, n termenii acestei Licene;
o Daca programul modificat citete comenzi n mod interactiv, trebuie s l modificai n
aa fel nct atunci cnd este pornit n mod interactiv s afieze un mesaj referitor la drepturile
de autor precum i o not menionnd lipsa oricrei garanii (sau s menioneze faptul c
dumneavoastr oferii o garanie).
Putei copia i distribui Programul (sau un proiect bazat pe el, conform Seciunii 2) n
format obiect sau executabil conform termenilor Seciunilor l i 2 de mai sus, cu condiia s
ndeplinii una dintre condiiile de mai jos:
o S l oferii nsoit de codul surs corespunztor, n format citibil de ctre main, care
trebuie s fie distribuit n termenii Seciunilor l i 2 de mai sus pe un mediu de distribuie
uzual transportului de software; sau
o S l oferii nsoit de o ofert scris, (valid pentru cel puin trei ani, pentru o tax
care s nu depeasc costul fizic al efecturii distribuiei sursei), de a oferi o copie complet,
n format citibil de ctre main, a codului surs, distribuit n termenii Seciunilor l i 2 de mai
sus, pe un mediu de distribuie uzual transportului de software; sau
o S l oferii nsoit de informaia pe care ai primit-o referitoare la oferta de a distribui
codul sursa corespunztor. (Aceast alternativ este permis numai pentru distribuiri
necomerciale i doar dac ai primit programul n format obiect sau executabil mpreun cu
aceast ofert, n conformitate cu Sub seciunea b de mai sus.)
Deoarece programul este oferit sub o licen ce nu implic nici un cost, nu exist nici o
garanie pentru program, n msura permis de legile ce se aplic. Exceptnd situaiile unde
este specificat altfel n scris, deintorii drepturilor de autor i/sau alte pri implicate ofer
programul n forma existent" fr nici o garanie de nici un fel, explicit sau implicit,
incluznd, dar fr a fi limitat la, garanii implicite de vandabilitate i conformitate unui
anumit scop. V asumai n ntregime riscul n ceea ce privete calitatea i performana acestui
program, n cazul n care programul se dovedete a fi defect, v asumai n ntregime costul
tuturor serviciilor, reparaiilor i coreciilor necesare.
10.3 Concluzii
In acest curs s-a urmrit trecerea n revist a unor probleme de psihologie cu
aplicabilitate n domeniul programrii, care pot determina eficientizarea scrierii codului,
precum i realizarea unor interfee cu utilizatorul uor de nvat i de folosit. S-a insistat apoi
asupra eticii programrii, detaliindu-se un cod etic i, n final, s-au prezentat unele chestiuni
de ordin legal, privind drepturile de autor asupra programelor realizate.