1/132

Inginerie software
2/132
1 FazeIe dezvoItrii unui produs software
1.1 Ce este ingineria programrii?
Stiin|a calculatoarelor este un domeniu relativ nou. Primele calculatoare au Iost
construite la mijlocul anilor 1940 si de atunci au avut loc dezvoltri spectaculoase, n anul
1946 Goldstine si von Neumann apreciau c 1000 de instruc|iuni reprezint o limit
superioar rezonabil pentru complexitatea problemelor ce pot Ii 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 oIer o imagine asupra gradului de complexitate la care au ajuns
programele n zilele noastre:
- sistemul de rezervare a biletelor pentru compania aerian KLM con|inea, n anul
1992, dou milioane de linii de cod n limbaj de asamblare;
- sistemul de operare System V versiunea 4.0 (UNIX) a Iost ob|inut prin
compilarea a 3.700.000 linii de cod;
- programele scrise pentru naveta spa|ial NASA au circa 40 de milioane de linii
de cod;
- pentru realizarea sistemului de operare IBM OS360 au Iost necesari 5000 de ani-
om.
Cresterea programelor n dimensiune si complexitate a depsit cu mult progresele Icute
n domeniul tehnicilor de programare. De aceea, programarea a devenit si a rmas mai mult o
art dect o meserie.
O paralel cu ingineria construc|iilor este atractiv. Dac dorim s construim o cusc
pentru cine, putem s mergem prin grdin, s cutam lemne si cuie, s lum un ciocan si s
ncepem s lucrm. Avem sanse destul de bune s reusim, mai ales dac suntem ndemnatici.
Dac totusi nu reusim, putem ncerca a doua zi din nou cu alte lemne si alte cuie. Iar dac
cinele nu ncape n cusc, putem s ne cumprm alt cine.
Lucrurile stau radical diIerit atunci cnd dorim s construim o cas pentru Iamilia
noastr. Atunci va trebui sau s angajm un arhitect care s ne Iac un proiect, sau s
cumprm un proiect standard de cas. Va trebui s negociem cu o Iirm de construc|ii pre|ul,
durata de realizare, calitatea Iinisajelor. Nu ne permitem s riscm economiile Iamiliei pe o
construc|ie care se va drma la a doua raIal de vnt. n plus, dac membrilor Iamiliei nu le
place orientarea Ierestrelor sau peisajul, nu i putem schimba cu al|ii (n cel mai ru caz, ne
schimb ei pe noi).
Cu att mai mult, dac o Iirm plteste cteva milioane de dolari pentru a ridica un
zgrie nori, reprezentan|ii acesteia vor Ii Ioarte aten|i cu cine si n ce condi|ii vor lucra. Ei vor
dori garan|ii c proiectul este viabil, vor angaja mai multe Iirme de arhitectur pentru a-1
veriIica. De asemenea, studii geologice, de Iizic a pmntului sau meteorologie vor Ii
obligatorii. Vor Ii Iolosite cele mai perIormante materiale si se vor angaja cei mai competen|i
si cu experien| constructori. Esecul nu mai este o op|iune pentru contractantul proiectului.
Stim c inginerii constructori ntocmesc planuri, construiesc machete, studiaz
propriet|ile materialelor Iolosite si Iac rapoarte privind progresul opera|iunilor. Construc|ii
de o complexitate Ioarte mare au Iost realizate n acest Iel ntr-un mod ra|ional si economic.
Inginerii de programe ar trebui s procedeze similar pentru ca dezvoltarea programelor s nu
mai Iie un proces impredictibil.
Pe msur ce complexitatea programelor crestea, la sIrsitul anilor '60 ncepea s se
preIigureze deja o criz a programrii. Un raport prezentat de ctre o companie, n care erau
analizate cteva proiecte si stadiile lor de Iinalizare, a constatat c:
3/132
2 din sistemele soItware contractate au Iunc|ionat de la predare;
3 din sistemele soItware au putut Iunc|iona dup cteva modiIicri;
29 au Iost predate dar n-au Iunc|ionat niciodat;
19 au Iost Iolosite dar au Iost abandonate; 47 au Iost pltite dar niciodat predate.
Pentru a contracara aceste tendin|e, la conIerin|a organizat de comitetul stiin|iIic al
NATO n anul 1968, a Iost propus termenul de ingineria programrii (engl. ,soItware
engineering"), ntr-un mod oarecum provocator. Se dorea ca arta programrii s mprumute
din rigoarea stiin|elor ingineresti pentru a putea livra programe la timp si n mod economic.
Prima deIini|ie dat ingineriei programrii a Iost enun|at astIel (F. L. Bauer):
Ingineria programrii este stabilirea si utilizarea de principii ingineresti solide pentru a
ob|ine n mod economic programe sigure si care Iunc|ioneaz eIicient pe masini de calcul
reale.
In IEEE Standard Glossary oI SoItware Engineering Technology (1983) ingineria
programrii este deIinit dup cum urmeaz:
Ingineria programrii reprezint abordarea sistematic a dezvoltrii, Iunc|ionrii,
ntre|inerii, si retragerii din Iunc|iune a programelor.
Remarcm c a doua deIini|ie este mai vag dect prima, ntruct nu Iace reIerire la cost
si la eIicien|. Mai mult, se pare c experien|a n general negativ acumulat a Icut s se
renun|e la Iormularea ,principii ingineresti solide", ntruct se pare c acestea nu pot Ii
identiIicate Ir a Ii supuse contesta|iilor. A doua deIini|ie adaug ns reIeriri la perioade
importante din via|a unui program, ce urmeaz crerii si Iunc|ionrii, si anume ntre|inerea si
retragerea din Iunc|ionare.
Considerm c ingineria programrii are urmtoarele caracteristici importante:
- este aplicabil n producerea de programe mari;
- este o stiin| inginereasc;
- scopul Iinal este ndeplinirea cerin|elor clientului.
Programele mici se pot scrie relativ usor, de ctre un singur programator, ntr-o perioad
destul de scurt de timp. Un program de 100 de instruc|iuni este cu siguran| un program mic.
Nu putem identiIica precis grani|a dintre un program mic si unul mare, ns pe msur ce
dimensiunea programului creste, apar provocri noi, calitativ diIerite.
ntruct un singur sau c|iva programatori nu pot avea timpul Iizic pentru terminarea
programului, este necesar crearea uneia sau mai multor echipe de lucru. Este necesar
coordonarea si comunicarea ntre echipe. Complexitatea sistemului soItware si a organiza|iei
care realizeaz sistemul soItware devine important, putnd depsi capacitatea de n|elegere 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 cerin|elor poate avea eIecte serioase. Un sistem de livrare a insulinei
pentru diabetici poate provoca moartea pacientului dac nu Iunc|ioneaz corect. Func|ionarea
incorect a unui sistem de control al unui satelit poate provoca pagube de milioane de dolari.
Un program este Iiabil dac Iunc|ioneaz si continu s Iunc|ioneze Ir ntreruperi un
interval de timp. Aceast no|iune exprim de Iapt rezisten|a la condi|iile de Iunc|ionare. Un
sistem de operare trebuie s Iie Iiabil pentru c trebuie s Iunc|ioneze o perioad suIicient de
lung de timp Ir s cad, indiIerent de programele care ruleaz pe el, chiar dac nu
totdeauna la perIorman|e optime.
Programul este sigur dac Iunc|ioneaz corect, Ir opera|ii nedorite. Un program
pentru un automat bancar trebuie s Iie sigur, pentru a eIectua tranzac|iile n mod absolut
corect, chiar dac Iunc|ionarea sa poate Ii ntrerupt din cnd n cnd. Atunci cnd
Iunc|ioneaz ns, trebuie s Iunc|ioneze Ioarte bine.
Programul este sigur dac Iunc|ioneaz corect, Ir opera|ii nedorite. Un automat bancar
trebuie s Iie sigur, pentru a eIectua tranzac|iile n mod absolut corect, chiar dac Iunc|ionarea
4/132
sa poate Ii ntrerupt din cnd n cnd. Atunci cnd Iunc|ioneaz ns, trebuie s Iunc|ioneze
Ioarte bine.
Un program are o eroare (engl. ,bug") dac nu se comport corect. Se presupune c
dezvoltatorul stia ce ar Ii trebuit programul s Iac, iar comportamentul gresit nu este
inten|ionat. Iat cteva erori celebre:
- n primii ani n care calculatoarele au Iost introduse la sta|iile de benzin din
SUA, consumatorii primeau cecuri pe sume enorme. Faptul era privit n general
cu umor si reclama|iile erau rezolvate repede;
- Sistemul de operare IBM OS360 con|inea aproximativ 1.000 de greseli la Iiecare
nou versiune care ncerca s rezolve greselile din versiunea precedent;
- Un vehicul de explorare a planetei Venus a Iost pierdut deoarece programul
primit de pe Pmnt pentru rectiIicarea orbitei con|inea linia 'DO 31 1.3';
instruc|iunea corect n limbajul FORTRAN ar Ii trebuit s con|in virgul n loc
de punct;
- In 1979 s-a descoperit o eroare n programele pentru sistemele de rcire n
centralele nucleare din SUA; din Iericire, nu Iusese niciodat nevoie de execu|ia
rutinelor ce con|ineau erorile;
- Din cauza unei erori n sistemul de avertizare mpotriva atacului cu rachete
balistice, procedurile de contraatac au Iost declansate nainte de a se descoperi
c a Iost o eroare;
- Racheta Arianne 5 a explodat n iunie 1996 din cauza unei greseli de
programare; costurile s-au ridicat la 500 milioane dolari.
Ingineria programrii are ca scop ob|inerea de sisteme Iunc|ionale chiar si atunci cnd
teoriile si instrumentele disponibile nu oIer rspuns la toate provocrile ce apar. Inginerii Iac
lucrurile s mearg, |innd seama de restric|iile organiza|iei n care lucreaz si de
constrngerile Iinanciare.
Problema Iundamental a ingineriei programrii este ndeplinirea cerin|elor clientului.
Aceasta trebuie realizat nu punctual, nu n acest moment, ci ntr-un mod Ilexibil si pe termen
lung. Ingineria programrii se ocup cu toate etapele dezvoltrii programelor, de la extragerea
cerin|elor de la client pn la ntre|inerea si retragerea din Iolosin| a produsului livrat. Pe
lng cerin|ele Iunc|ionale, clientul doreste (de obicei) ca produsul Iinal s Iie realizat cu
costuri de produc|ie ct mai mici. De asemenea, este de dorit ca aceasta s aib perIorman|e
ct mai bune (uneori direct evaluabile), un cost de ntre|inere ct mai mic, s Iie livrat la timp,
si s Iie sigur. Rezumnd, atributele cheie ale unui produs soItware se reIer la:
- posibilitatea de a putea Ii ntre|inut: un produs cu un lung ciclu de via| este
supus deseori modiIicrilor, de aceea el trebuie Ioarte bine documentat;
- Iiabilitate: produsul trebuie s se comporte dup cerin|ele utilizatorului si s nu
,cad" mai mult dect e prevzut n speciIica|iile sale;
- eIicien|: produsul nu trebuie s Ioloseasc n pierdere resursele sistemului ca
memoria sau ciclii procesor;
- interIa|a potrivit pentru utilizator: interIa|a trebuie s |in seama de capacitatea
si cunostin|ele utilizatorului.
Optimizarea tuturor acestor atribute e diIicil deoarece unele se exclud pe altele (o mai
bun interIa| pentru utilizator poate micsora eIicien|a produsului), n cazurile n care
eIicien|a este critic, acest lucru trebuie speciIicat explicit nc din Iaza de preluare a
cerin|elor utilizatorului, precum si compromisurile pe care ea le implic privind ceilal|i
Iactori.
Trebuie spus c ingineria programrii nu rezolv toate problemele care apar atunci cnd
se scriu programe. Ingineria programrii nu oIer nici teorii. Inginerii Iac lucrurile s mearg.
Totusi, n momentul de Ia|, ingineria programrii ne poate spune sigur ce s nu Iacem.
5/132
1.2 Fazele ingineriei programrii
Exist patru Iaze Iundamentale ale metodologiilor ingineriei programrii:
- analiza (ce dorim s construim);
- proiectarea (cum vom construi);
- implementarea (construirea propriu-zis);
- testarea (asigurarea calit|ii).
Desi aceste Iaze se reIer n mod special la ciclul de via| al produsului soItware, ele pot
Ii aplicate si altor stadii de existen| prin care trece un program de la ,nastere" pn la
,moarte": lansare, ntre|inere, iesire din uz.
1.2.1 Faza de anaIiz
Aceast Iaz deIineste cerin|ele sistemului, independent de modul n care acestea vor Ii
ndeplinite. Aici se deIineste problema pe care clientul doreste s o rezolve. Rezultatul acestei
Iaze este documentul cerin|elor, care trebuie s precizeze clar ce trebuie construit.
Documentul ncearc s redea cerin|ele din perspectiva clientului, deIinind scopurile si
interac|iunile la un nivel descriptiv nalt, independent de detaliile de implementare, cum ar Ii,
de exemplu: Iormularea problemei, asteptrile clientului sau criteriile pe care trebuie s le
ndeplineasc produsul.
Grani|a dintre descrierile de nivel nalt si cele de nivel sczut nu este Ioarte bine trasat.
Uneori, dac un detaliu tehnic important trebuie speciIicat, el va aprea n document. Totusi,
aceasta trebuie s Iie excep|ia si nu regula. Aceste excep|ii pot Ii determinate de necesitatea
men|inerii compatibilit|ii cu alte sisteme deja existente, sau a unor anumite op|iuni dorite de
client, de exemplu utilizarea unui anumit standard sau o constrngere asupra dimensiunilor
imaginii aplica|iei, care poate Ii destinat unei categorii speciale de utilizatori sau care va rula
pe niste sisteme cu o serie de particularit|i (monitoare care nu suport rezolu|ii mari). Faza
de analiz poate Ii vzut ca o raIinare a detaliilor. Distinc|ia dintre detaliile de nivel nalt si
cele de nivel sczut sunt puse mai bine n eviden| de abordrile top-down (unde se merge
ctre detaliile de nivel sczut) si bottom-up (care tind ctre detaliile de nivel nalt).
Documentul cerin|elor poate Ii realizat ntr-o manier Iormal, bazat pe logic
matematic, sau poate Ii exprimat n limbaj natural, n mod tradi|ional, el descrie obiectele din
sistem si ac|iunile care pot Ii realizate cu ajutorul obiectelor. Aici no|iunea de ,obiect" nu
trebuie conIundat cu obiectul din programarea orientat obiect. Descrierea obiectelor si
ac|iunilor trebuie s Iie general si s nu depind de o anumit tehnologie. Desigur, ntr-o
abordare POO, descrierile vor lua Iorma obiectelor si metodelor, ns n alte abordri,
obiectele pot Ii de exemplu servicii care acceseaz baze de date.
In general, documentul cerin|elor descrie ontologia proiectului, adic vocabularul de
cuvinte cheie (n special construc|ii substantivale si verbale) care va Ii utilizat pentru deIinirea
protocolului speciIic aplica|iei. Descrierile acestea nu implic proiectarea arhitecturii
aplica|iei, ci enumerarea pr|ilor componente si a modului n care acestea se comport. Mai
trziu, n Iaza de proiectare, acestea vor Ii transIormate n primitive inIormatice, precum liste,
stive, arbori, graIuri, algoritmi si structuri de date.
Mai concret, documentul trebuie s con|in descrieri pentru urmtoarele categorii:
- Obiecte: Documentul trebuie s deIineasc mai nti ontologia sistemului, care
este bazat n mare parte pe construc|ii substantivale pentru identiIicarea
pieselor, pr|ilor componente, constantelor, numelor si a rela|iilor dintre acestea;
- Ac|iuni: Documentul trebuie s deIineasc de asemenea ac|iunile pe care trebuie
s le ndeplineasc sistemul si care sunt sugerate n general de construc|ii
verbale. Exemple de ac|iuni sunt: metodele, Iunc|iile sau procedurile;
6/132
- Stri: Sunt deIinite ca mul|imi de setri si valori care disting sistemul ntre dou
ipostaze spa|io-temporale. Fiecare sistem trece printr-o serie de schimbri de
stare. Exemple de stri sunt: starea ini|ial, cea Iinal sau strile de eroare. Cele
mai multe stri depind de domeniul problemei. Strile sunt asociate cu obiectele
sistemului. Un eveniment declanseaz o tranzi|ie de stare care poate conduce la
ndeplinirea unei ac|iuni de ctre sistem;
- Scenarii tipice: Un scenariu este o secven| de pasi urma|i pentru ndeplinirea
unui scop. Cnd sistemul este terminat si aplica|ia este disponibil, clientul
trebuie s poat utiliza, ntr-o manier ct mai Iacil si clar speciIicat, toate
scenariile tipice ale aplica|iei. Scenariile tipice trebuie s reprezinte majoritatea
scenariilor de utilizare ale aplica|iei. Ponderea acestora variaz de la un sistem la
altul, dar 90 se consider o propor|ie acceptabil. Binen|eles c un sistem cu
un singur scenariu de utilizare este relativ simplu de ob|inut, pe cnd unul cu mii
de scenarii posibile va Ii mult mai diIicil de analizat. Deseori este invocat
regula 80/20: 80 din Iunc|ionalitatea sistemului se realizeaz cu 20 din
eIortul de munc. Executarea restului minoritar de Iunc|ionalitate necesit marea
majoritate a timpului de lucru;
- Scenarii atipice: Un scenariu atipic trebuie s Iie ndeplinit de sistem numai n
cazuri speciale. Clientul poate s spere, de exemplu, c o eroare neprevzut este
un eveniment atipic. Totusi, sistemul trebuie s gestioneze un numr ct mai
mare de categorii de erori, prin tehnici stabilite, precum tratarea excep|iilor,
monitorizarea proceselor etc.;
- Cerin|e incomplete sau nemonotone: O enumerare complet a cerin|elor pentru
toate situa|iile care pot aprea n condi|ii de lucru reale nu este posibil. In
logica tradi|ional, o teorie este deIinit de o mul|ime Iinit de axiome.
Teoremele din teoria respectiv sunt propozi|ii 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 Iost demonstrate anterior. O
nou teorie nu mai este o simpl extensie a teoriei vechi, ci o mul|ime de
teoreme noi, mpreun cu o parte din teoremele vechi. Procesul de stabilire a
cerin|elor are o natur iterativ si nemonoton. Mul|imea ini|ial de cerin|e
(axiomele) deIineste posibilit|ile (teoremele) sistemului. Noile cerin|e pot
inIirma solu|iile vechi. Pe msur ce un sistem creste n dimensiuni si
complexitate, stabilirea cerin|elor devine din ce n ce mai diIicil, mai ales cnd
procesul de colectare a cerin|elor este distribuit, Iiind realizat de indivizi cu
specializri diIerite.
1.2.2 Faza de proiectare
Pe baza cerin|elor din Iaza de analiz, acum se stabileste arhitectura sistemului:
componentele sistemului, interIe|ele si modul lor de comportare:
- Componentele sunt elementele constructive ale produsului. Acestea pot Ii create
de la zero sau reutilizate dintr-o bibliotec de componente. Componentele
raIineaz si captureaz semniIica|ia detaliilor din documentul cerin|elor;
- InterIe|ele ajut la mbinarea componentelor. O interIa| reprezint grani|a dintre
dou componente, utilizat pentru comunicarea dintre acestea. Prin intermediul
interIe|ei, componentele pot interac|iona;
- Comportamentul, determinat de interIa|, reprezint rspunsul unei componente
la stimulii ac|iunilor altor componente.
7/132
Documentul de proiectare descrie planul de implementare a cerin|elor. Se identiIic
detaliile privind limbajele de programare, mediile de dezvoltare, dimensiunea memoriei,
platIorma, algoritmii, structurile de date, deIini|iile de tip globale, interIe|ele etc.
In aceast Iaz trebuie indicate si priorit|ile critice pentru implementare. Acestea
sugereaz sarcinile care, dac nu sunt executate corect, conduc la esecul sistemului. Totusi,
chiar dac priorit|ile critice sunt ndeplinite, acest Iapt nu duce automat la succesul
sistemului, ns creste nivelul de ncredere c produsul va Ii o reusit.
Folosind scenariile tipice si atipice, trebuie realizate compromisurile inerente ntre
perIorman| si complexitatea implementrii. Analiza perIorman|elor presupune studierea
modului n care diIeritele arhitecturi conduc la diIerite caracteristici de perIorman| pentru
Iiecare scenariu tipic. In Iunc|ie de Irecven|a de utilizare a scenariilor, Iiecare arhitectur va
avea avantaje si dezavantaje. Un rspuns rapid la o ac|iunea a utilizatorului se realizeaz
deseori pe baza unor costuri de resurse suplimentare: indecsi, managementul cache-ului,
calcule predictive etc. Dac o ac|iune este Ioarte Irecvent, ea trebuie realizat corect si
eIicient. O ac|iune mai rar trebuie de asemenea implementat corect, dar nu este evident care
e nivelul de perIorman| necesar n acest caz. O situa|ie n care o astIel de ac|iune trebuie
implementat cu perIorman|e maxime este nchiderea de urgen| a unui reactor nuclear.
Planul de implementare si planul de test, descrise mai jos, pot Ii incluse de asemenea n
Iazele de implementare si respectiv testare. Ins unul din scopurile Iazei de proiectare este
stabilirea unui plan pentru terminarea sistemului, de aceea cele dou planuri au Iost incluse n
paragraIul curent.
Planul de implementare stabileste programul dup care se va realiza implementarea si
resursele necesare (mediul de dezvoltare, editoarele, compilatoarele etc.).
Planul de test deIineste testele necesare pentru stabilirea calit|ii sistemului. Dac
produsul trece toate testele din planul de test, este declarat terminat. Cu ct testele sunt mai
amnun|ite, cu att este mai mare ncrederea n sistem si deci creste calitatea sa. Un anume
test va veriIica doar o por|iune a sistemului. Acoperirea testului este procentajul din produs
veriIicat prin testare, n mod ideal, o acoperire de 100 ar Ii excelent, ns este rareori
ndeplinit. De obicei, un test cu o acoperire de 90 este simpl, ns ultimele 10 necesit o
perioad de timp semniIicativ.
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 Iirmei MicrosoIt. Din ra|iuni de perIorman|, BIOS-ul a Iost plasat ntr-un chip ROM, si
deci patch-urile pentru eventualele erori erau imposibile. AstIel, au Iost 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 si apoi trebuia generat un eveniment care s
declanseze un test. Foarte repede, setul de test a devenit mult mai mare dect BIOS-ul. A
aprut astIel problema testrii nsusi a mediului de test! In Iinal, o acoperire de 100 a Iost
atins, dar cu un cost Ioarte ridicat. O solu|ie mai ieItin a Iost nscrierea BlOS-ului ntr-o
combina|ie dintre EPROM (Electronic Programmable Read Only Memory) si ROM. Cea mai
mare parte a produsului era plasat n ROM, iar patch-urile erau plasate n EPROM. Aceasta a
Iost abordarea adoptat de Apple pentru Macintosh.
In general, este suIicient ca testele s cuprind scenariile tipice si atipice, Ir s veriIice
ntregul sistem, cu absolut toate Iirele de execu|ie. Acesta poate con|ine ramiIica|ii interne,
erori sau ntreruperi care conduc la Iire de execu|ie netestate. Majoritatea sistemelor sunt pline
de bug-uri nedescoperite. De obicei, clientul particip n mod logic la testarea sistemului si
semnaleaz erori care vor Ii ndeprtate n versiunile ulterioare.
8/132
1.2.3 Faza de impIementare
In aceast Iaz, sistemul este construit, ori plecnd de la zero, ori prin asamblarea unor
componente pre-existente. Pe baza documentelor din Iazele anterioare, echipa de dezvoltare ar
trebui s stie exact ce trebuie s construiasc, chiar dac rmne loc pentru inova|ii si
Ilexibilitate. De exemplu, o component poate Ii proiectat mai restrns, special pentru un
anumit sistem, sau mai general, pentru a satisIace o direc|ie de reutilizare.
Echipa trebuie s gestioneze problemele legate de calitate, perIorman|, biblioteci si
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 satisIac n mod complet scenariile de
utilizare. Aceste erori trebuie corectate nainte ca sistemul s Iie predat clientului
si chiar nainte ca procesul de dezvoltare ulterioar a produsului s poat
continua;
- Erori necritice: Sunt cunoscute, dar prezen|a lor nu aIecteaz n mod
semniIicativ calitatea observat a sistemului. De obicei aceste erori sunt listate n
notele de lansare si au modalit|i de ocolire bine cunoscute;
- Erori necunoscute: Exist ntotdeauna o probabilitate mare ca sistemul s
con|in un numr de erori nedescoperite nc. EIectele acestor erori sunt
necunoscute. Unele se pot dovedi critice, altele pot Ii rezolvate cu patch-uri sau
eliminate n versiuni ulterioare.
1.2.4 Faza de testare
Calitatea produsului soItware este Ioarte important. Multe companii nu au nv|at ns
acest lucru si produc sisteme cu Iunc|ionalitate extins, dar cu o calitate sczut. Totusi, e mai
simplu s-i explici clientului de ce lipseste o anumit Iunc|ie dect s-i explici de ce produsul
nu este perIormant. Un client satisIcut de calitatea produsului va rmne loial Iirmei si va
astepta noile Iunc|ii n versiunile urmtoare.
In multe metodologii ale ingineriei programrii, Iaza de testare este o Iaz separat,
realizat de o echip diIerit dup ce implementarea s-a terminat. Motivul este Iaptul c un
programator nu-si poate descoperi Ioarte usor propriile greseli. O persoan nou care priveste
codul poate descoperi greseli evidente care scap celui care citeste si reciteste materialul de
multe ori. Din pcate, aceast practic poate determina o atitudine indiIerent Ia| de calitate
n echipa de implementare.
Tehnicile de testare sunt abordate preponderent din perspectiva productorului
sistemului, n mod ideal, si clientul trebuie s joace un rol important n aceast Iaz. Testele
de regresiune (engl. ,regression test") sunt colec|ii de programe care testeaz una sau mai
multe trsturi ale sistemului. Rezultatele testelor sunt adunate si dac exist erori, bug-ul este
corectat. Un test de regresiune valid genereaz rezultate veriIicate, numite ,standardul de
aur". Validitatea rezultatului unui test ar trebui s Iie determinat de documentul cerin|elor, n
practic, echipa de implementare este responsabil de interpretarea validit|ii.
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 modiIicate n standardul de aur, pentru a se potrivi asteptrilor curente. Pachetul de test
este rulat din nou si genereaz noi rezultate. Acestea sunt comparate cu rezultatele
standardelor de aur. Dac sunt diIerite, n sistem a aprut o greseal. Greseala este corectat si
dezvoltarea continu. Acest mecanism detecteaz situa|iile cnd starea curent de dezvoltare a
produsului invalideaz o stare existent. AstIel, se previne regresiunea sistemului ntr-o stare
de eroare anterioar.
Exist patru puncte de interes n testele de regresiune pentru asigurarea calit|ii.
9/132
Testarea intern trateaz implementarea de nivel sczut. Fiecare Iunc|ie 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 unit|ilor testeaz o unitate ca un ntreg. Aici se testeaz interac|iunea mai
multor Iunc|ii, dar numai n cadrul unei singure unit|i. Testarea este determinat de
arhitectur. De multe ori sunt necesare asa-numitele ,schele", adic programe special
construite pentru stabilirea mediului de test. Numai cnd mediul este realizat se poate executa
o evaluare corect. Programul schel stabileste stri si valori pentru structurile de date si
asigur Iunc|ii externe Iictive. De obicei, programul schel nu are aceeasi calitate ca produsul
soItware testat si adesea este destul de Iragil. O schimbare mic n test poate determina
schimbri importante n programul schel. Aceste teste se mai numesc teste ,black-box"
deoarece numai detaliile interIe|ei sunt vizibile pentru test.
Testarea intern si a unit|ilor poate Ii automatizat cu ajutorul instrumentelor de
acoperire (engl. ,coverage tools"), care analizeaz codul surs si genereaz un test pentru
Iiecare alternativ a Iirelor execu|ie. Depinde de programator combinarea acestor teste n
cazuri semniIicative care s valideze rezultatelor Iiecrui Iir de execu|ie. De obicei,
instrumentul de acoperire este utilizat ntr-un mod oarecum diIerit: el urmreste liniile de cod
executate ntr-un test si apoi raporteaz procentul din cod executat n cadrul testului. Dac
acoperirea este mare si liniile surs netestate nu prezint mare importan| pentru calitatea
general a sistemului, atunci nu mai sunt necesare teste suplimentare.
Testarea aplica|iei testeaz aplica|ia ca ntreg si este determinat de scenariile echipei de
analiz. Aplica|ia trebuie s execute cu succes toate scenariile pentru a putea Ii pus la
dispozi|ia clientului. Spre deosebire de testarea intern si a unit|ilor, care se Iace prin
program, testarea aplica|iei se Iace de obicei cu scripturi care ruleaz sistemul cu o serie de
parametri si colecteaz rezultatele. In trecut, aceste scripturi erau create manual. In prezent,
exist instrumente care automatizeaz si acest proces. Majoritatea aplica|iilor din zilele
noastre au interIe|e graIice (GUI). Testarea interIe|ei graIice pentru asigurarea calit|ii poate
pune anumite probleme. Cele mai multe interIe|e, dac nu chiar toate, au bucle de
evenimente, care con|in cozi de mesaje de la mouse, tastatur, Ierestre etc. Asociate cu Iiecare
eveniment sunt coordonatele ecran. Testarea interIe|ei presupune deci memorarea tuturor
acestor inIorma|ii si elaborarea unei modalit|i prin care mesajele s Iie trimise din nou
aplica|iei, la un moment ulterior.
Testarea la stres determin calitatea aplica|iei n mediul su de execu|ie. Ideea este
crearea unui mediu mai solicitant dect cel n care aplica|ia va rula n mod obisnuit. Aceasta
este cea mai diIicil si complex categorie de teste. Sistemul este supus unor cerin|e din ce n
ce mai numeroase, pn cnd acesta cade. Apoi produsul este reparat si testul de stres se
repet pn cnd se atinge un nivel de stres mai ridicat dect nivelul asteptat de pe sta|ia
clientului. Deseori apar aici conIlicte ntre teste. Fiecare test Iunc|ioneaz corect atunci cnd
este Icut separat. Cnd dou teste sunt rulate n paralel, unul sau ambele teste pot esua.
Cauza este de obicei managementul incorect al accesului la resurse critice. Mai apar si
probleme de memorie, cnd un test si aloc memorie si apoi nu o mai dealoc. Testul pare s
Iunc|ioneze 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 Icut mai nti o introducere n problematica domeniului ingineriei
programrii, insistndu-se pe cauzele care au determinat dezvoltarea sa: cresterea continu a
complexit|ii sistemelor soItware. Apoi s-au descris cele patru Iaze Iundamentale ale
metodologiilor ingineriei programrii: analiza, proiectarea, implementarea si testarea,
necesare pentru realizarea unor sisteme de calitate.
10/132
2 MetodoIogii de dezvoItare a programeIor
1. Etapele dezvoltrii programelor
2. Metodologii generice
2.1. Metodologia secven|ial
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 Iormale
3.7. Extreme Programming
4. Concluzii
2.1 Etapele dezvoltrii programelor
Cnd pornim la dezvoltarea unui program avem nevoie de:
- n|elegere clar a ceea ce se cere;
- un set de metode si instrumente de lucru;
- un plan de ac|iune.
Planul de ac|iune se numeste metodologie de dezvoltare. Dezvoltarea unui anumit
program const ntr-un set de pasi ce se Iac pentru a-1 realiza. Lund n considerare tipul
pasilor ce se eIectueaz se creeaz un model de lucru, ce poate Ii aplicat unei serii mai largi de
proiecte. Acesta este motivul pentru care planul de ac|iune este numit model: el poate Ii privit
ca un sablon al dezvoltrii de programe, n timpul dezvoltrii programelor s-a constatat c
exist anumite tipuri de activit|i care trebuie Icute la un moment dat:
- Analiza cerin|elor: Se stabileste ce anume vrea clientul ca programul s Iac.
Scopul este nregistrarea cerin|elor ntr-o manier ct mai clar si mai Iidel.
Claritatea se reIer la lipsa ambiguit|ii iar Iidelitatea la nregistrarea ct mai
exact (posibil cuvnt cu cuvnt);
- Proiectarea arhitectural: Din motive de complexitate, programele mari nu pot Ii
concepute si implementate ca o singur bucat. Programul va trebui construit
asadar din module sau componente. Proiectarea arhitectural mparte sistemul
ntr-un numr de module mai mici si mai simple, care pot Ii abordate individual;
- Proiectarea detaliat: Se realizeaz proiectarea Iiecrui modul al aplica|iei, 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
Iinal. Rezultatul este sistemul complet, n modelul numit big-bang componentele
sunt dezvoltate si testate individual, dup care sunt integrate n sistemul Iinal.
Avnd n vedere c Iunc|ionarea corect a componentelor individuale a Iost
testat, integrarea ar trebui s Iie o Iormalitate. Din pcate, componentele nu pot
Ii testate exhaustiv, iar cnd acestea lucreaz mpreun pot s apar situa|ii pe
care o anumit component nu le-a ntlnit n procesul de testare sau conIlicte
ntre anumite componente (de exemplu, conIlicte de partajare a resurselor). S-a
11/132
constatat c atunci cnd se aplic acest model, timpul de testare explodeaz,
proiectul devenind greu de controlat; aceasta justiIic denumirea de ,big-bang".
Modelul incremental propune crearea unui nucleu al aplica|iei si integrarea a
cte o component la un moment dat, urmat imediat de testarea sistemului
ob|inut. AstIel, se poate determina mai usor unde anume apare o problema n
sistem. Acest tip de integrare oIer de obicei rezultate mai bune dect modelul
big-bang;
- Validarea: n procesul de validare ne asigurm c programul ndeplineste
cerin|ele 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 mul|umit cu produsul sau dac mai
trebuie eIectuate modiIicri;
- VeriIicarea: n procesul de veriIicare ne asigurm c programul este stabil si c
Iunc|ioneaz corect din punctul de vedere al dezvoltatorilor, ntrebarea la care
rspundem este: construim corect produsul?
- ntre|inerea: Dup ce programul este livrat clientului, mai devreme sau mai
trziu sunt descoperite deIecte sau erori ce trebuie reparate. De asemenea, pot
aprea schimbri n speciIica|iile utilizatorilor, care vor diverse mbunt|iri,
ntre|inerea const n gestionarea acestor probleme.
Se poate constata usor c aceste activit|i sunt n strns legtur cu cele patru Iaze ale
ingineriei programrii: analiza, proiectarea, implementarea si testarea.
2.2 Metodologii generice
n acest paragraI, vor Ii prezentate trei categorii importante de metodologii: secven|ial,
ciclic si hibrid, n metodologia secven|ial (cascad), cele patru Iaze urmeaz una alteia
ntr-o modalitate serial, n metodologia ciclic (spiral), Iazele sunt dispuse n cicluri care si
genereaz incremental contribu|iile la sistemul Iinal. Metodologia hibrid (ecluz) combin
progresul constant al metodologiei secven|iale cu incrementale iterative ale metodologiei
ciclice.
2.2.1 MetodoIogia secven{iaI
n metodologia secven|ial, cunoscut si sub numele de metodologia ,cascad", are loc
mai nti Iaza de analiz, apoi cea de proiectare, urmat de cea de implementare, iar n Iinal se
realizeaz testarea. Echipele care se ocup de Iiecare Iaz pot Ii diIerite, iar la Iiecare tranzi|ie
de Iaz poate Ii necesar o decizie managerial.
Figura 2-1 Metodologia secvenial
Avantaje
Metodologia secven|ial este potrivit cnd complexitatea sistemului este mic iar
cerin|ele sunt statice. Ea spune c mai nti trebuie s ne gndim ce trebuie construit, apoi s
stabilim un plan de lucru si apoi s realizm proiectul, |innd cont de standardele de calitate.
De asemenea, se aliniaz metodelor de inginerie hardware. For|eaz men|inerea unei
discipline de lucru care evit presiunea scrierii codului nainte de a cunoaste precis ce produs
va trebui de Iapt construit. De multe ori, echipa de implementare se aIl n situa|ia de a
programa nainte de Iinalizarea analizei, ceea ce conduce inevitabil la descoperirea unor pr|i
de cod inutile sau care contribuie Ioarte pu|in (poate chiar si ineIicient) la Iunc|ionalitatea
produsului Iinal. Totusi, acest cod devine un balast Ioarte costisitor: diIicil de abandonat si
12/132
greu de schimbat. Aceast metodologie Ior|eaz analiza si planiIicarea naintea implementrii,
o practic Ioarte nimerit n multe situa|ii.
Un mare numr de sisteme soItware din trecut au Iost construite cu o metodologie
secven|ial. Multe companii si datoreaz succesul acestui mod de realizare a programelor.
Trebuie spus totusi si c presiunea de schimbare din partea surselor externe era destul de
limitat la momentul respectiv.
Dezavantaje
Unul din principalele dezavantaje ale metodologiei secven|iale este Iaptul c acord o
Ioarte mare importan| Iazei de analiz. Membrii echipei de analiz ar trebui s Iie probabil
clarvztori ca s poat deIini toate detaliile aplica|iei nc de la nceput. Greselile nu sunt
permise, deoarece nu exist un proces de corectare a erorilor dup lansarea cerin|elor Iinale.
Nu exist nici Ieedback de la echipa de implementare n ceea ce priveste complexitatea
codului corespunztor unei anumite cerin|e. O cerin| simplu de Iormulat poate creste
considerabil complexitatea implementrii, n unele cazuri, este posibil s Iie chiar imposibil
de implementat cu tehnologia actual. Dac echipa de analiz ar sti c o cerin| nu poate Ii
implementat, ei ar putea-o schimba cu o cerin| diIerit care s satisIac cele mai multe
dintre necesit|i si care s Iie mai usor de eIectuat.
Comunicarea dintre echipe este o problem: cele patru echipe pot Ii diIerite iar
comunicarea dintre ele este limitat. Modul principal de comunicare sunt documentele
realizate de o echip si trimise urmtoarei echipe cu Ioarte pu|in Ieedback. Echipa de analiz
nu poate avea toate inIorma|iile privitoare la calitate, perIorman| si motivare.
ntr-o industrie n continu miscare, metodologia secven|ial poate produce sisteme
care, la vremea lansrii, s Iie deja nvechite. Accentul att de mare pus pe planiIicare nu
poate determina rspunsuri suIicient de rapide la schimbare. Ce se ntmpl dac clientul si
schimb cerin|ele dup terminarea Iazei de analiz? Acest lucru se ntmpl ns Irecvent;
dup ce clientul vede prototipul produsului, el si poate schimba unele cerin|e.
2.2.2 MetodoIogia cicIic
Metodologia ciclic, cunoscut si sub numele de metodologia ,spiral", ncearc s
rezolve unele din problemele metodologiei secven|iale. Si aceast metodologie are patru Iaze,
ns n Iiecare Iaz se consum un timp mai scurt, dup care urmeaz mai multe itera|ii prin
toate Iazele. Ideea este de Iapt urmtoarea: gndeste un pic, planiIic un pic, implementeaz
un pic, testeaz un pic si apoi ia-o de la capt. In mod ideal, Iiecrei Iaze trebuie s i se acorde
aten|ie si importan| egale.
Documentele de la Iiecare Iaz si schimb treptat structura si con|inutul, la Iiecare ciclu
sau itera|ie. Pe msur ce procesul nainteaz, sunt generate din ce n ce mai multe detalii. In
Iinal, dup cteva cicluri, sistemul este complet si 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 perIec|ionrii incrementale ale metodologiei
secven|iale. Permite Ieedback-ul de la Iiecare echip n ceea ce priveste complexitatea
cerin|elor. Exist etape n care pot Ii corectate eventualele greseli privind cerin|ele. Clientul
poate arunca o privire asupra rezultatului si poate oIeri inIorma|ii importante mai ales n Iaza
dinaintea lansrii produsului. Echipa de implementare poate trimite echipei de analiz
13/132
inIorma|ii privind perIorman|ele si viabilitatea sistemului. Acesta se poate adapta mai bine
progresului tehnologic: pe msur ce apar noi solu|ii, ele pot Ii ncorporate n arhitectura
produsului.
Dezavantaje
Metodologia ciclic nu are nici o modalitate de supraveghere care s controleze
oscila|iile de la un ciclu la altul. In aceast situa|ie, Iiecare ciclu produce un eIort mai mare de
munc pentru ciclul urmtor, ceea ce ncarc orarul planiIicat si poate duce la eliminarea unor
Iunc|ii sau la o calitate sczut. Lungimea sau numrul de cicluri poate creste Ioarte mult. De
vreme ce nu exist constrngeri asupra echipei de analiz s Iac lucrurile cum trebuie de
prima dat, acest Iapt duce la scderea responsabilit|ii. Echipa de implementare poate primi
sarcini la care ulterior se va renun|a. Echipa de proiectare nu are o viziune global asupra
produsului si deci nu poate realiza o arhitectur complet. Nu exist termene limit precise.
Ciclurile continu Ir o condi|ie clar de terminare. Echipa de implementare poate Ii pus n
situa|ia nedorit n care arhitectura si cerin|ele sistemului sunt n permanen| schimbare.
2.2.3 MetodoIogia hibrid ecIuz
Metodologia ecluz (engl. ,watersluice"), propus de Ronald LeRoi Burback (1998),
separ aspectele cele mai importante ale procesului de dezvoltare a unui produs soItware de
detaliile mai pu|in semniIicative si se concentreaz pe rezolvarea primelor. Pe msur ce
procesul continu, detaliile din ce n ce mai Iine sunt raIinate, pn cnd produsul poate Ii
lansat. Aceast metodologie hibrid preia natura iterativ a metodologiei spiral, la care
adaug progresul sigur al metodologiei cascad.
Analiza
Proiectare
mplementare
Testare
Proiectare
mplementare
Testare
mplementare
Testare
Testare
Produs
Schita de principiu
Prototip
Alfa / Beta
Produs
Figura 2-3 Metodologia hibrid ecluz
La nceput, ntr-un proces iterativ, Iazele de analiz, proiectare, implementare si testare
sunt mpr|ite n mai multe sarcini poten|iale, Iiecruia atribuindu-i-se o prioritate care
reIlect beneIiciul ndeplinirii sarcinii respective pentru scopul Iinal. La Iiecare moment se
execut sarcina cu prioritate maxim. In Iunc|ie de dimensiunea echipelor, mai multe sarcini
pot Ii realizate n paralel. Sarcinile rmase, de prioritate minim, sunt pstrate pentru
14/132
examinare ulterioar. Descompunerea problemei este Ioarte important. Cu ct
descompunerea si stabilirea priorit|ilor sunt mai bune, cu att mai eIicient este metodologia.
Pe msur ce sarcinile stabilite sunt ndeplinite, noi sarcini pot Ii descoperite. Acestea
sunt adugate sarcinilor rmase nesolu|ionate si se reatribuie priorit|ile. Procesul continu
pn cnd produsul este gata de lansare.
Priorit|ile se stabilesc pe baza unei Iunc|ii de prioritate, care depinde att de domeniul
problemei si de normele Iirmei. Ea trebuie s realizeze un compromis ntre cantitate si
calitate, ntre Iunc|ionalitate si constrngerile privind resursele, ntre asteptri si realitate.
Toate Iunc|iile de prioritate ar trebuie s aib ca prim scop lansarea produsului.
Pe lng rolul evident de a stabili priorit|ile si deci ordinea de execu|ie a sarcinilor de
lucru, Iunc|ia mai trebuie s gestioneze sarcinile conIlictuale si nemonotone. Ea trebuie s
mpart aceste sarcini n grupuri consistente, s reglementeze selec|ia grupurilor consistente si
apoi s dirijeze selec|ia sarcinilor din cadrul grupurilor. Pe msur ce sistemul creste, Iunc|ia
de prioritate trebuie s aleag sarcini consistente cu partea deja constituit din sistem. O
sarcin nemonoton vine n contradic|ie cu sistemul realizat deja si trebuie eliminat dac nu
este absolut necesar pentru succesul sistemului.
Odat ce o component este terminat si acceptat de echip, schimbrile asupra sa sunt
nghe|ate. Componenta va Ii schimbat numai dac modiIicrile sunt absolut necesare iar
echipa este dispus s ntrzie lucrul la restul sistemului pentru a le eIectua. Schimbrile
trebuie s Iie pu|ine la numr, bine justiIicate si documentate.
Etapele principale ale metodei sunt: schi|a de principiu, prototipul, versiunile alIa/beta
si produsul Iinal.
n prima etap, schi|a de principiu, echipele lucreaz simultan la toate Iazele problemei.
Echipa de analiz sugereaz cerin|ele. Echipa de proiectare le discut si trimite sarcinile
critice de implementare echipei de implementare. Echipa de testare pregteste si dezvolt
mediul de test n Iunc|ie de cerin|e. Echipa de implementare se concentreaz asupra sarcinilor
critice, care n general sunt cele mai diIicile. Aceast abordare contrasteaz cu practica
curent de realizare mai nti a sarcinilor simple. Totusi, majoritatea produselor care urmeaz
acest model esueaz. Odat ce componentele critice au Iost realizate, sistemul este gata de a
Iace tranzi|ia ctre stadiul de prototip. Unul din scopurile aceste etape este de a se convinge
echipele c o solu|ie poate Ii gsit si pus n practic.
n cea de a doua etap, de prototip, cerin|ele si documentul cerin|elor sunt nghe|ate.
Schimbrile n cerin|e sunt nc permise, ns ar trebuie s Iie Ioarte rare si numai dac sunt
absolut necesare, deoarece modiIicrile cerin|elor n acest stadiu al proiectului sunt Ioarte
costisitoare. Este posibil totusi ajustarea arhitecturii, pe baza noilor op|iuni datorate
tehnologiei. Dup ce sarcinile critice au Iost terminate, echipa de implementare se poate
concentra pe extinderea acestora, pentru deIinirea ct mai multor aspecte ale aplica|iei. Unul
din scopurile acestei etape este de a convinge persoanele din aIara echipelor c o solu|ie este
posibil.
Acum produsul este gata pentru lansarea versiunilor alIa si beta. Arhitectura este
nghe|at, iar accentul cade pe implementare si asigurarea calit|ii. Prima versiune lansat se
numeste n general alIa. Produsul este nc imatur; numai sarcinile critice au Iost
implementate la calitate ridicat. Numai un numr mic de clien|i sunt n general dispusi s
accepte o versiune alIa si s-si asume riscurile asociate. O a doua lansare reprezint versiunea
beta. Rolul su este de a convinge clien|ii c aplica|ia va Ii un produs adevrat si de aceea se
adreseaz unui numr mai mare de clien|i. Cnd o parte suIicient de mare din sistem a Iost
construit, poate Ii lansat n sIrsit produsul. n aceast etap, implementarea este nghe|at si
accentul cade pe asigurarea calit|ii. Scopul este realizarea unui produs competitiv. In
produsul Iinal nu se accept erori critice.
Avantaje
15/132
Metodologia ecluz recunoaste Iaptul c oamenii Iac greseli si c nici o decizie nu
trebuie s Iie absolut. Echipele nu sunt blocate ntr-o serie de cerin|e sau ntr-o arhitectur
imobil care se pot dovedi mai trziu inadecvate sau chiar gresite. Totusi, pentru respectarea
termenelor limit, metodologia impune date de nghe|are a unor Iaze. Exist timp suIicient
pentru corectarea greselilor decizionale pentru atingerea unui nivel suIicient 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 renun|e n mod normal. Metodologia ncearc s mute toate erorile
la nceputul procesului, unde corectarea, sau chiar renceperea de la zero a lucrului, nu sunt
Ioarte costisitoare.
Dezavantaje
Metodologia presupune asumarea unor responsabilit|i privind delimitarea etapelor si
nghe|area succesiv a Iazelor de dezvoltare. Ea presupune crearea unui mediu de lucru n
care acceptarea responsabilit|ii pentru o decizie care se dovedeste mai trziu gresit s nu se
repercuteze n mod negativ asupra individului. Se doreste de asemenea schimbarea atitudinii
echipelor Ia| de testare, care are loc nc de la nceput, si Ia| de comunicarea continu, care
poate Ii diIicil, ntruct cele patru Iaze reprezint perspective diIerite asupra realizrii
produsului.
2.3 Metodologii concrete
2.3.1 MetodoIogia 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
ntretinere si revalidare
Figura 2-4 Metodologia cascad
Dup Iiecare 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 Iiecare dou etape. AstIel, metoda cascad este de Iapt o combina|ie de
metodologie secven|ial cu elemente ciclice. Totusi, n practica inginereasc, termenul
,cascad" este utilizat ca un nume generic pentru orice metodologie secven|ial.
16/132
Acesta este modelul dup care de obicei sistemele sunt dezvoltate n practic. De
asemenea, reordonarea Iazelor s-a dovedit a Ii sub-optimal. Exist o mare atrac|ie pentru
acest model datorit experien|ei, tradi|iei n aplicarea sa si succesului pe care 1-a implicat. O
sarcin complex este mpr|it n mai mul|i pasi mici, ce sunt mai usor de administrat.
Fiecare pas are ca rezultat un produs bine deIinit (documente de speciIica|ie, model, etc.)
Modelul cascad cu Ieedback propune remedierea problemelor descoperite n pasul
precedent. Problemele la pasul /' care sunt descoperite la pasul / 3 rmn neremediabile. Un
model realist ar trebui s oIere 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 ob|ine o viziune
practic asupra produsului doar n momentul terminrii procesului de dezvoltare. De
asemenea, modelul nu are suIicient putere descriptiv, n sensul c nu integreaz activit|i ca
managementul resurselor sau managementul conIigura|iei. Aceasta Iace diIicil coordonarea
proiectului.
Dup cum am men|ionat la prezentarea metodologiei generice secven|iale, si modelul
cascad impune nghe|area speciIica|iilor Ioarte devreme n procesul de dezvoltare pentru a
evita itera|iile Irecvente (rentoarcerile n Iazele anterioare atunci cnd n Iaza curent s-au
detectat erori: n timpul analizei se descoper erori de speciIica|ii, n timpul implementrii se
descoper erori de speciIica|ii/proiectare etc., astIel nct procesul poate implica multiple
secven|e de itera|ii ale activit|ilor de dezvoltare), nghe|area prematur a cerin|elor conduce
la ob|inerea unui produs prost structurat si care nu execut ceea ce doreste utilizatorul.
Conduce de asemenea la ob|inerea unei documenta|ii neadecvate deoarece schimbrile
intervenite n itera|iile Irecvente nu sunt actualizate n toate documentele produse.
2.3.2 MetodoIogia spiraI
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: planiIicare, Iaze bine deIinite, produse intermediare.
El deIineste urmtorii pasi n dezvoltarea unui produs:
- studiul de Iezabilitate;
- analiza cerin|elor;
- proiectarea arhitecturii soItware;
- implementarea.
Modelul n spiral recunoaste c problema principal a dezvoltrii programelor este
riscul. Riscul nu mai este eliminat prin aser|iuni de genul: ,n urma proiectrii am ob|inut un
model corect al sistemului", ca n modelul cascad. Aici riscul este acceptat, evaluat si se iau
msuri pentru contracararea eIectelor sale negative. Exemple de riscuri:
- n timpul unui proces ndelungat de dezvoltare, cerin|ele noi ale clientului sunt
ignorate;
- clientul schimb cerin|ele;
- o Iirm concurent lanseaz un program rival pe pia|;
- un dezvoltator/arhitect prseste echipa de dezvoltare;
- o echip nu respect un termen de livrare pentru o anumit component.
In modelul spiral se consider c Iiecare pas din dezvoltare con|ine o serie de activit|i
comune:
- pregtirea: se identiIic obiectivele, alternativele, constrngerile;
- gestionarea riscului: analiza si rezolvarea situa|iilor de risc;
- activit|i de dezvoltare speciIice pasului curent (de exemplu analiza
speciIica|iilor sau scrierea de cod);
17/132
- planiIicarea 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 si prototipul
3. Conceperea opera|iilor
4. Cerin|ele si planul ciclului de via|
5. Obiective, alternative, constrngeri
6. Analiza riscului si prototipul
- Ciclul 2 - Analiza Iinal:
7. Simulare, modele, benchmark-uri
8. Cerin|e soItware si validare
9. Plan de dezvoltare
10. Obiective, alternative, constrngeri
11. Analiza riscului si prototipul
- Ciclul 3 - Proiectarea:
12. Simulare, modele, benchmark-uri
13. Proiectarea produsului soItware, validare si veriIicare
14. Integrare si plan de test
15. Obiective, alternative, constrngeri
16. Analiza riscului si prototipul opera|ional
- Ciclul 4 - Implementarea si testarea:
17. Simulare, modele, benchmark-uri
18. Proiectare detaliat
19. Cod
20. Integrarea unit|ilor si testarea acceptrii
21. Lansarea produsului
18/132
Procesul ncepe n centrul spiralei. Fiecare ciclu terminat reprezint o etap. Pe msur
ce spirala este parcurs, produsul se maturizeaz. Cu Iiecare ciclu, sistemul se apropie de
solu|ia Iinal. Desi este considerat ca un exemplu generic pentru metodologia ciclic, metoda
are si elemente secven|iale, puse n eviden| de evolu|ia constant de la o etap la alta.
2.3.3 MetodoIogia spiraI WinWin
Aceast metodologie extinde spirala Boehm prin adugarea unui pas de stabilire a
priorit|ii la nceputul Iiecrui ciclu din spiral si prin introducerea unor scopuri intermediare,
numite puncte ancor. Procesul WinWin identiIic un punct de decizie. Pentru Iiecare punct
de decizie, se stabilesc obiectivele, constrngerile si alternativele.
Punctele ancor stabilesc trei scopuri intermediare. Primul punct ancor, numit
obiectivul ciclului de via|, precizeaz cazurile sigure de Iunc|ionare pentru ntregul sistem,
artnd c exist cel pu|in o arhitectur Iezabil (adic posibil din punct de vedere practic)
care satisIace scopurile sistemului. Primul scop intermediar este stabilit cnd sunt terminate
obiectivele de nivel nalt ale sistemului, arhitectura, modelul ciclului de via| si prototipul
sistemului. Aceast prim ancor spune de ce, ce, cnd, cine, unde, cum si estimeaz costul
produsului. Dup executarea acestor opera|ii, este disponibil analiza de nivel nalt a
sistemului.
Al doilea punct ancor deIineste arhitectura ciclului de via|, iar al treilea - capacitatea
opera|ional ini|ial, incluznd mediul soItware necesar, hardware-ul, documenta|ia pentru
client si instruirea acestuia.
Aceste puncte ancor corespund etapelor majore din ciclul de via| al unui produs:
dezvoltarea ini|ial, lansarea, Iunc|ionarea, ntre|inerea si iesirea din Iunc|iune.
2.3.4 Prototipizarea
O problem general care apare la dezvoltarea unui program este s ne asigurm c
utilizatorul ob|ine exact ceea ce vrea. Prototipizarea vine n sprijinul rezolvrii acestei
probleme, nc din primele Iaze ale dezvoltrii, clientului i se prezint o versiune Iunc|ional
a sistemului. Aceast versiune nu reprezint ntregul sistem, ns este o parte a sistemului care
cel pu|in Iunc|ioneaz.
Prototipul ajut clientul n a-si deIini mai bine cerin|ele si priorit|ile. Prin intermediul
unui prototip, el poate n|elege ce este posibil si 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 pu|in) neglijent. Ins scopul principal al prototipului este de a ajuta n
Iazele de analiz si proiectare si nu Iolosirea unui stil elegant.
Se disting dou Ieluri de prototipuri:
- de aruncat (throw-away);
- evolu|ionar.
n cazul realizrii unui prototip de aruncat, scopul este exclusiv ob|inerea unei
speciIica|ii. De aceea nu se acord nici o importan| stilului de programare si de lucru,
punndu-se accent pe viteza de dezvoltare. Odat stabilite cerin|ele, codul prototipului este
,aruncat", sistemul Iinal Iiind rescris de la nceput, chiar n alt limbaj de programare.
n cazul realizrii unui prototip evolu|ionar, scopul este de a crea un schelet al aplica|iei
care s poat implementa n prim Iaz o parte a cerin|elor sistemului. Pe msur ce aplica|ia
este dezvoltat, noi caracteristici sunt adugate scheletului existent, n contrast cu prototipul
de aruncat, aici se investeste un eIort considerabil ntr-un design modular si extensibil,
precum si n adoptarea unui stil elegant de programare.
Aceast metod are urmtoarele avantaje:
- permite dezvoltatorilor s elimine lipsa de claritate a speciIica|iilor;
19/132
- oIer utilizatorilor sansa de a schimba speciIica|iile ntr-un mod ce nu aIecteaz
drastic durata de dezvoltare;
- ntre|inerea este redus, deoarece validarea se Iace pe parcursul dezvoltrii;
- se poate Iacilita instruirea utilizatorilor Iinali nainte de terminarea produsului.
Dintre dezavantajele principale ale prototipizrii amintim:
- deoarece prototipul ruleaz ntr-un mediu artiIicial, anumite dezavantaje ale
produsului Iinal pot Ii scpate din vedere de clien|i;
- clientul nu n|elege de ce produsul necesit timp suplimentar pentru dezvoltare,
avnd n vedere c prototipul a Iost realizat att de repede;
- deoarece au n Iiecare moment sansa de a Iace acest lucru, clien|ii schimb
Ioarte des speciIica|iile;
- poate Ii nepopular printre dezvoltatori, deoarece implic renun|area la propria
munc.
2.3.5 MetodoIogia Booch
Aceast metodologie asigur o dezvoltare orientat obiect n Iazele de analiz si
proiectare. Faza de analiz este mpr|it n mai mul|i pasi. Primul pas este stabilirea
cerin|elor din perspectiva clientului, genernd o descriere de nivel nalt a Iunc|ionrii si
structurii sistemului. Al doilea pas este analiza domeniului, realizat prin deIinirea claselor:
atributele, metodele, mostenirea. Faza de analiz este terminat cu un pas de validare. Aceast
Iaz itereaz cei trei pasi pn cnd solu|ia este consistent.
Si Iaza de proiectare este iterativ. Design-ul logic este transIormat n design Iizic, cu
detalii privind Iirele de execu|ie, procesele, perIorman|ele, tipurile de date, structurile de date
etc. Se creeaz un prototip si apoi se testeaz. Faza itereaz design-ul logic, cel Iizic,
prototipurile si testarea.
Metodologia Booch este secven|ial n sensul c mai nti este terminat analiza si apoi
proiectarea. Ea este ciclic datorit itera|iilor din Iiecare Iaz. Metoda se concentreaz n
special asupra acestor dou Iaze, de analiz si proiectare, Ir s insiste Ioarte mult asupra
implementrii si testrii.
2.3.6 Metode formaIe
In acest model de dezvoltare, sunt Iolosite Iormalismul si rigoarea matematicii. In prima
Iaz este construit o speciIica|ie n limbaj matematic. Apoi, aceast speciIica|ie este
transIormat n programe, de obicei ntr-un proces incremental.
Avantaje:
- precizia ob|inut prin speciIicarea Iormal;
- pstrarea corectitudinii n timpul transIormrii speciIica|iei n cod executabil;
- oIer posibilitatea generrii automate de cod;
- sunt potrivite pentru sisteme cu cerin|e critice.
Dezavantaje:
- speciIicarea Iormal este de obicei o barier de comunicare ntre client si analist;
- necesit personal Ioarte caliIicat (deci mai scump);
- Iolosirea impecabil a tehnicilor speciIicrii Iormale nu implic neaprat
ob|inerea de programe sigure, deoarece anumite aspecte critice pot Ii omise din
speciIica|iile ini|iale.
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 (si
20/132
extrem) are att adep|i ct si critici. XP consider c dezvoltarea programelor nu nseamn
ierarhii, responsabilit|i si termene limit, asa cum se aIl acestea pe masa administratorului,
ci nseamn colaborarea oamenilor din care este Iormat echipa. Acestia sunt ncuraja|i s si
aIirme personalitatea, s oIere si s primeasc cunostin|e si s devin programatori strluci|i.
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 stuIoase, a sedin|elor si a rapoartelor de
activitate. XP ne aminteste cu respect ca Iisierele PowerPoint nu se pot compila.
De altIel, inspirarea proceselor de dezvoltare a programelor din ingineria construc|iilor
se pare c nu este cea mai Iericit alegere. Este adevrat c un inginer care vrea s
construiasc un pod peste un ru Iace mai nti msurtori, realizeaz un proiect si abia apoi
trece la execu|ie, toate acestea ntr-un mod secven|ial si previzibil. Dar dezvoltarea de
programe nu seamn cu asa ceva, orict am vrea s credem asta. Dac inginerului
constructor respectiv i s-ar schimba cerin|ele de rezisten| si i s-ar muta malurile chiar cnd a
terminat de construit jumtate de pod, putem Ii siguri c acel inginer si-ar schimba modul de
lucru. Din pcate ns, nu stim (nc) cum.
Ini|iatorii XP deIinesc urmtoarele dou carte, ca baz IilosoIic pentru aceast
metodologie.
Carta drepturilor dezvoltatorului:
- Ai dreptul s stii ceea ce se cere, prin cerin|e clare, cu declara|ii clare de
prioritate;
- Ai dreptul s spui ct |i va lua s implementezi Iiecare cerin|, si s |i
revizuiesti estimrile n Iunc|ie de experien|;
- Ai dreptul s |i accep|i responsabilit|ile, n loc ca acestea s-|i Iie asignate;
- Ai dreptul s Iaci treab de calitate n orice moment;
- Ai dreptul la liniste, distrac|ie si la munc productiv si plcut.
- Carta drepturilor clientului:
- Ai dreptul la un plan general, s stii ce poate Ii Icut, cnd, si la ce pre|;
- Ai dreptul s vezi progresul ntr-un sistem care ruleaz si care se dovedeste c
Iunc|ioneaz trecnd teste repetabile pe care le speciIici tu;
- Ai dreptul s te rzgndesti, s nlocuiesti Iunc|ionalit|i si s schimbi
priorit|ile;
- Ai dreptul s Iii inIormat de schimbrile n estimri, suIicient de devreme pentru
a putea reduce cerin|ele astIel ca munca s se termine la data prestabilit. Po|i
chiar s te opresti la un moment dat si s rmi cu un sistem Iolositor care s
reIlecte investi|ia pn la acea dat.
Aceste aIirma|ii, desi par de la sine n|elese, con|in semniIica|ii proIunde. 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
Iolosind maximul din cunostin|ele sale;
- Scrierea de cod este activitatea cea mai important;
- Proiectul este n mintea tuturor programatorilor din echip, nu n documenta|ii,
modele sau rapoarte;
- La orice moment, un reprezentant al clientului este disponibil pentru clariIicarea
cerin|elor;
- Codul se scrie ct mai simplu;
- Se scrie mai nti cod de test;
- Dac apare necesitatea rescrierii sau eliminrii codului, aceasta se Iace Ir mil;
21/132
- ModiIicrile aduse codului sunt integrate continuu (de cteva ori pe zi);
- Se programeaz n echip (programare n perechi). Echipele se schimb la
sIrsitul unei itera|ii (1-2 sptmni);
- Se lucreaz 40 de ore pe sptmn, Ir lucru suplimentar.
2.4 Concluzii
Au Iost prezentate aici cele mai importante metodologii de dezvoltare a programelor.
Mai nti au Iost descrise metodologiile generice: secven|ial, ciclic si hibrid, cu avantajele
si dezavantajele Iiecreia. Apoi s-au amintit cteva metode concrete de dezvoltate: modelul
cascad, modelul spiral, WinWin, prototipizarea, metodologia Booch, metodele Iormale si
asa-numita ,programare extrem".
22/132
3 ManagementuI unui proiect software
3.1 Managementul software
Multe proiecte de dezvoltare soItware au probleme, mai devreme sau mai trziu
deoarece ori programul nu este livrat la timp, ori bugetul este depsit, ori clien|ii sunt
nemul|umi|i. De multe ori cauzele sunt de natur tehnic. Ins, n la Iel de multe situa|ii,
problemele si au originea n organizarea si managementul proiectului. Cnd un produs este
livrat prea trziu, motivele prezentate sunt n general urmtoarele:
- programatorii nu au spus adevrul despre situa|ia real a codului;
- clientul nu stia ce vrea de Iapt;
- echipa de management a subestimat timpul necesar terminrii proiectului;
- echipa de management nu a acordat suIicient timp pentru planiIicarea atent a
proiectului;
- productivitatea programatorilor s-a dovedit mult inIerioar asteptrilor.
Aparent, nu e simplu s termini cu succes un proiect de dezvoltare soItware. Pe lng
aspectele tehnice, legate n general de cele patru Iaze prezentate anterior (analiz, proiectare,
implementare, testare), s-a dovedit c aspectele privind organizarea si managementul
proiectului sunt cel pu|in la Iel de importante.
Un proiect de dezvoltare soItware nu este de obicei complet izolat. In cadrul Iirmei se
poate lucra si la alte proiecte si deci poate Ii necesar identiIicarea unor legturi ntre proiecte,
stabilirea de priorit|i etc. Pentru acest proces de meta-planiIicare (planiIicare a planiIicrii)
se Ioloseste deseori termenul planiIicare inIorma|ional. Scopul su este precizarea unor
condi|ii sau constrngeri pentru Iiecare proiect concret.
De asemenea, nici din punct de vedere tehnic programul nu este pornit de la zero. El
trebuie s Iie interIa|at cu programe existente, s extind Iunc|ionalitatea altor programe, s
Ioloseasc biblioteci de Iunc|ii etc. De Iapt, nsusi termenul de dezvoltare soItware poate Ii
considerat nepotrivit. Nu doar programul este dezvoltat, ci un ntreg sistem. SoItware-ul este o
component principal, dar nu este unic.
S considerm un sistem pentru automatizarea unei biblioteci. El va con|ine diverse
componente soIt, precum baze de date despre cr|i si persoane sau interIe|e pentru prelucrarea
interactiv a cererilor utilizatorilor. Pe lng acestea, trebuie gsite modalit|i de rezolvare a
unor probleme de genul:
- identiIicarea electronic a cr|ilor prin coduri de bare;
- achizi|ionarea de componente hardware care s scaneze aceste coduri si s
creeze elemente de identiIicare pentru cr|ile noi;
- instruirea bibliotecarilor pentru utilizarea noilor instrumente de lucru (cursuri,
instruire practic etc.);
- alctuirea unei documenta|ii prietenoase pentru abona|i.
Un proiect de dezvoltare soItware poate Ii vzut astIel:
23/132
Program
Program
SoItware
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, si componenta soItware poate include mai multe module de program care
interac|ioneaz si asigur Iunc|ionalitatea dorit n mod colectiv.
Pe baza constrngerilor, se ncepe lucrul la un anumit proiect concret. Primul pas, de
mare importan|, este planiIicarea proiectului. Apoi, pe parcursul execu|iei trebuie controlate
cinci entit|i: timpul, inIorma|iile, organizarea, calitatea si banii.
3.1.1 PIanificarea proiectuIui
PlaniIicarea proiectului presupune identiIicarea propriet|ilor care vor inIluen|a
dezvoltarea. Aceste propriet|i nu sunt Ioarte bine n|elese dect dup terminarea Iazei de
analiz. De aceea, planiIicarea are n mod necesar o natur dinamic.
Cooper (1984) subliniaz 13 elemente importante ale planului proiectului:
b) Introducerea: Sunt descrise condi|iile si istoricul proiectului, mpreun cu
scopurile, numele persoanelor responsabile si un sumar al proiectului;
c) Implicarea utilizatorului: Viitorii utilizatori vor Ii implica|i din timp n timp
n proiect. Planul trebuie s cuprind ce inIorma|ii, servicii si resurse sunt
asigurate de utilizatori si cnd se va ntmpla acest lucru;
d) Riscurile: In orice moment exist riscuri: hardware-ul nu va Ii livrat la timp,
personalul caliIicat este insuIicient, lipsesc inIorma|ii esen|iale s.a.m.d. n mod
ideal, riscurile poten|iale trebuie identiIicate ct mai devreme si echipa de
management trebuie s ia msuri pentru eliminarea lor. Pe msur ce
necunoscutele proiectului devin mai numeroase, creste si numrul riscurilor;
e) Standardele, tehnicile, procedurile: Proiectele soItware sunt proiecte mari, n
care sunt implicate multe persoane. De aceea, este nevoie de o disciplin de
lucru clar, bazat pe standarde si proceduri asupra crora toat lumea a czut
de acord. O mare importan| o are documenta|ia: cnd trebuie livrat, cum este
evaluat calitatea sa, cum se asigur permanenta sa actualizare;
24/132
I) Organizarea proiectului: n cadrul echipei proiectului se identiIic diverse
roluri: project manager, tester, programator, analist etc. Aceste roluri trebuie
clar delimitate iar atribu|iile Iiecruia trebuie bine precizate si clariIicate. In
acest scop, poate Ii necesar o perioad de instruire a membrilor echipei;
g) Fazele proiectului: n primul curs au Iost amintite Iazele de dezvoltare ale
unui produs soItware. Metodologiile de aplicare a acestora sunt numeroase.
Echipa de management trebuie s se decid care model va Ii urmat si care sunt
pasii obligatorii. Proiectul trebuie divizat n pr|i gestionabile care pot Ii
alocate unor echipe diIerite. De asemenea, trebuie estimate timpul si costul
Iiecrei Iaze. Tipuri diIerite de proiecte au diIerite caracteristici si necesit
deci modele diIerite;
h) Analiza cerinelor yi proiectarea: Se indic metodele si tehnicile care vor Ii
utilizate n analiz si proiectare, precum si resursele si instrumentele necesare
pentru acestea;
i) Implementarea: Se identiIic resursele si instrumentele necesare pentru
implementare si se precizeaz cum va Ii gestionat volumul Ioarte mare de
documenta|ie tehnic ce va rezulta de aici;
j) Testarea: Se descriu mediile si echipamentele de test necesare;
k) Resursele: Sunt enumerate resursele hardware si instrumentele necesare
pentru proiect;
l) Asigurarea calitii: Se identiIic procedurile care vor Ii Iolosite pentru a
veriIica dac proiectul ndeplineste standardele de calitate dorite;
m) Modificrile: Pentru un proiect, modiIicrile sunt inevitabile. Echipa de
management trebuie s se asigure c aceste schimbri sunt tratate ntr-un mod
organizat, pe baza unor proceduri bine deIinite. Fiecare modiIicare propus
trebuie nregistrat si revzut. Cnd o modiIicare este aprobat, se estimeaz
costurile corespunztoare. Dup ncorporarea sa n sistemul existent, trebuie
redactate noi versiuni ale documenta|iei pentru a reIlecta schimbrile din cod;
n) Livrarea: n Iinal, trebuie respectate procedurile necesare pentru livrarea
produsului ctre client.
Planul proiectului trebuie s Iurnizeze o imagine clar a ceea ce trebuie Icut, att
pentru client ct si pentru echipa de realizare. Dac obiectivele nu sunt clare, ele nu vor Ii
niciodat ndeplinite.
3.1.2 ControIuI proiectuIui
Dup ce planul proiectului a Iost realizat si aprobat, poate ncepe executarea propriu-
zis. Pe parcursul executrii, trebuie controlate urmtoarele dimensiuni:
- timpul;
- inIorma|iile;
- organizarea;
- calitatea;
- banii.
Cursul de evolu|ie al proiectului (aspectul timp) este greu de msurat. AIirma|iile de
genul ,90 din cod a fost deja scris" trebuie cntrite de dou ori nainte de a Ii crezute. De
obicei, se prezint o situa|ie mai bun a proiectului dect este n realitate. Timpul necesar
construirii unui sistem este n mod evident legat de dimensiunea sa si deci de Ior|a de munc
utilizat. Cu ct un sistem este mai mare, cu att este necesar mai mult timp pentru
dezvoltarea sa, desi 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 si resursele umane Iolosite. Totusi, cu ct sunt implicate mai multe
25/132
persoane, cu att va creste timpul pentru coordonare si comunicare. Peste un anumit punct,
mrirea personalului va avea ca eIect cresterea timpului de dezvoltare. n acest sens, legea lui
Brooks aIirm c adugarea de personal la un proiect ntrziat l va ntrzia si mai mult.
Din punctul de vedere al inIorma|iilor, accentul principal cade pe realizarea
documentaiei: documentele utilizatorului, documentele tehnice si documenta|ia proiectului
nsusi, care include starea curent de lucruri, modiIicrile convenite, deciziile luate.
n cadrul echipei, Iiecare persoan trebuie s-si cunoasc Ioarte clar rolul. Dac rolurile
nu sunt deIinite sau sunt neclare, Iiecare individ si va stabili propriile scopuri, care pot intra
n contradic|ie cu scopurile proiectului. Project manager-ul trebuie s |in seama de aceste
aspecte organiza|ionale la alctuirea echipei si stabilirea atribu|iilor.
Calitatea este Ioarte important, deoarece clien|ii nu se mul|umesc cu solu|ii pur
tehnice, ci doresc sisteme adecvate nevoilor lor reale. De multe ori, cerin|ele de calitate pot Ii
conIlictuale. Pe parcursul executrii proiectului, acestea trebuie mereu evaluate, pentru ca s
poat Ii luate msuri din timp pentru remedierea problemelor. Calitatea nu trebuie s Iie o
trstur adugat, ci o caracteristic intrinsec a sistemului.
Controlarea resurselor Iinanciare nseamn n mare parte controlarea costurilor de
personal. Desi costurile asociate hardware-ului si diIeritelor instrumente nu poate Ii neglijat,
acestea pot Ii de obicei estimate destul de precis n Iazele incipiente ale proiectului. Estimarea
costului se reduce astIel la estimarea Ior|ei de munc necesare, care depinde de mul|i Iactori.
Un Iactor important este dimensiunea soItware-ului (determinat de exemplu de mrimea
codului). Exist ns si al|i Iactori care inIluen|eaz costurile sau productivitatea. O echip
bine echilibrat de persoane experimentate vor avea o productivitate mult mai mare dect o
echip nou Iormat de persoane Ir experien|.
3.2 Managementul configuraiei
Pe parcursul ciclului de via| al unui proiect de dezvoltare soItware sunt create si
actualizate un mare numr de elemente, precum module de cod surs, cerin|e de modiIicare
etc. Pentru gestionarea acestora trebuie s existe un set de proceduri bine deIinite, care poart
numele de managementul conIigura|iei.
De cele mai multe ori, un sistem .soItware nu este monolitic. Sistemele exist n diIerite
versiuni si conIigura|ii. Versiunile diIerite apar atunci cnd sunt Icute modiIicri dup ce
sistemul a Iost livrat clientului. Din timp n timp, clientul este conIruntat cu o nou lansare.
DiIerite versiuni pot exista si pentru componentele din sistem. Dac o modiIicare a Iost
aprobat, un programator poate implementa schimbarea prin rescrierea unei componente, n
acelasi timp, un altul poate utiliza n continuare versiunea anterioar a aceleiasi componente.
La orice moment trebuie s existe o singur versiune oIicial setului de documente
legate de proiect. Aceasta se numeste linie de baz (engl. ,baseline"), deIinit ca standard
IEEE: ,o speciIica|ie sau un produs care a Iost analizat si acceptat n mod Iormal, care
serveste n continuare ca baz pentru dezvoltarea viitoare si care poate Ii modiIicat numai prin
proceduri Iormale de control al modiIicrilor". Linia de baz este deci o baz de date partajat
care con|ine toate entit|ile aprobate, denumite entit|i de conIigurare (engl. ,conIiguration
items"). O entitate de conIigurare este deIinit de asemenea ca standard IEEE astIel: ,o
colec|ie de elemente hardware sau soItware tratate ca o unitate n scopul gestionrii
conIigura|iei".
Exemple de entit|i de conIigura|ie sunt:
- modulele de cod surs;
- modulele de cod obiect;
- speciIicarea cerin|elor;
- documenta|ia de proiectare;
- planul de test;
26/132
- cazurile de test;
- rezultatele de test;
- manualul utilizatorului.
O sarcin Iundamental a managementului conIigura|iei este men|inerea integrit|ii
acestui set de elemente, lucru deosebit de important atunci cnd modiIicrile sunt integrate n
sistem. S presupunem c n Iaza de testare este descoperit o eroare major ntr-un modul.
Atunci to|i pasii deja eIectua|i trebuie parcursi n ordine invers si pe lng modiIicarea
codului trebuie modiIicate si documentele de proiectare sau chiar cerin|ele. Aceste schimbri
pot interac|iona cu munca altor programatori, care Iolosesc versiunea anterioar. Mai ru, un
alt programator poate eIectua propriile sale modiIicri la acelasi modul. Managementul
conIigura|iei se ocup de gestionarea tuturor acestor schimbri pe parcursul ntregului ciclu de
via| al produsului.
Orice modiIicare propus pentru linia de baz se numeste cerere de modificare si este
tratat precum urmeaz:
- ModiIicarea este trimis comisiei de control al conIigura|iei (CCC). Pentru
evaluarea propunerii, comisia are nevoie de inIorma|ii privind modul n care
schimbrile vor aIecta produsul si procesul de dezvoltare: volumul de cod nou
sau modiIicat, cerin|e suplimentare de test, legtura cu alte schimbri, costurile
poten|iale, complexitatea modiIicrii, severitatea erorii (dac e cazul), resursele
necesare etc.;
- CCC evalueaz cererea, care poate Ii aprobat, respins sau amnat dac sunt
necesare mai multe inIorma|ii. Dac este aprobat, se stabileste un termen de
implementare;
- CCC se asigur c toate entit|ile de conIigura|ie aIectate de schimbare vor Ii
actualizate corespunztor.
Am men|ionat c entit|ile din baza de date partajat pot Ii utilizate Ir restric|ii de to|i
membrii echipei. Dac o entitate trebuie modiIicat, persoana responsabil de schimbare
primeste o copie a entit|ii si apoi entitatea este blocat temporar, astIel nct nimeni s nu
poat o modiIica n acelasi timp. Persoana desemnat ac|ioneaz asupra copiei. Dup ce
modiIicarea este testat, este trimis napoi la CCC. Dup ce comisia o aprob, entitatea este
inclus n baza de date, schimbarea e documentat si apoi entitatea e deblocat. Sirul de
modiIicri documentate Iormeaz istoricul reviziei entitii.
Cnd o entitate e modiIicat, este pstrat si versiunea veche. Aceasta poate Ii nc
utilizat de alte persoane pn cnd acestea se adapteaz schimbrii. Avnd versiuni diIerite
pentru aceeasi entitate, trebuie s existe o modalitate de a le distinge. De obicei, se preIer o
schem numeric, n care Iiecare versiune urmtoare este identiIicat de urmtorul numr.
Pentru o component X vom avea deci versiunile X.0, X.1, X.2 s.a.m.d.
Schema GNU de numerotare denot versiunea unui produs soItware printr-un triplet de
ntregi: versiunea major, versiunea minor si patch-ul. ntre dou versiuni majore, n produs
au loc schimbri majore ale Iunc|ionalit|ii si n acest caz nu este garantat compatibilitatea
napoi.
Dimpotriv, ntre dou versiuni minore ale aceleiasi versiuni majore trebuie s existe
compatibilitate. De exemplu, Iormatele de Iisiere suportate de o versiune ulterioar trebuie s
Iie suportate si de versiunea minor anterioar. Rolul unei versiuni minore este introducerea
unor Iunc|ii noi. Func|iile vechi nu vor Ii ndeprtate; totusi documenta|ia programului l
poate avertiza pe utilizator c la anumite Iunc|ii se va renun|a n viitor.
Patch-ul nu poate realiza dect schimbri n implementarea unor Iunc|ii. De obicei,
rolul su este corectarea unor erori ale programului.
Aceste reguli nu se aplic ns si pentru programele n versiuni alIa sau beta (O.F).
nainte de versiunea 1.0, deoarece programul este n curs de Iormare, sunt permise modiIicri
27/132
importante ntre versiuni. Totusi, versiunea 1.0 trebuie s reprezinte o platIorm stabil, cu ct
mai pu|ine bug-uri, care s poat Ii utilizat cu ncredere de clien|i. Nu e neaprat necesar ca
aceasta s con|in ct mai multe Iunc|ionalit|i, ci ca Iunc|iile implementate s Iie ct mai
sigure. Noi Iunc|ionalit|i pot Ii adugate n versiunile urmtoare.
La nivelul codului surs, managementul conIigura|iei este sprijinit de instrumente
puternice, care blocheaz si deblocheaz elementele, asigur numerotarea automat a
reviziilor si Iurnizeaz utilizatorului ultima versiune disponibil.
Un astIel de instrument este CVS (Concurrent Versions System), care permite crearea
istoricului schimbrilor din cod. Cnd sursele sunt modiIicate uneori apar erori, care pot Ii
detectate abia dup un interval mare de timp de la modiIicare, n aceste situa|ii este util
identiIicarea versiunilor vechi si implicit a schimbrilor care au produs eroarea. CVS nu
salveaz toate Iisierele surs din diIeritele versiuni, ci numai modiIicrile aduse Iisierelor. De
asemenea, cnd mai mul|i programatori lucreaz la acelasi proiect, trebuie evitat
suprascrierea de ctre o persoan a modiIicrilor alteia. O rezolvare a acestei probleme este
blocarea unui Iisier astIel nct acesta s nu poat Ii modiIicat dect de un singur dezvoltator
la un anumit moment de timp. Abordarea CVS se bazeaz pe izolarea programatorilor,
astIel nct Iiecare lucreaz n propriul su director, iar la sIrsit, cnd to|i au terminat,
programele sunt integrate.
3.3 Managementul echipei
n multe organiza|ii care dezvolt proiecte soItware, programatorii, analistii si al|i
proIesionisti lucreaz mpreun ntr-o echip. Stabilirea structurii adecvate a unei echipei
depinde de mul|i Iactori, precum numrul de persoane, experien|a si gradul de implicare n
proiect, tipul proiectului, diIeren|ele individuale si stilul.
Orice tip de proiect implic un numr de sarcini de lucru. O responsabilitate
Iundamental a project manager-ului este coordonarea si distribuirea sarcinilor ctre to|i
membrii echipei. Pentru un proiect mic, echipa va consta n cteva persoane. Pe msur ce
creste dimensiunea proiectului, si dimensiunea echipei va creste. Echipele mari sunt diIicil de
coordonat iar volumul comunicrii dintre membri tinde s creasc exponen|ial cu mrimea
echipei. De aceea, echipele mari sunt mpr|ite n subechipe astIel nct majoritatea
comunicrii si coordonrii s se desIsoare la nivelul acestora.
3.3.1 ManagementuI for{ei de munc
O echip este Iormat din indivizi, Iiecare cu scopurile sale personale. Este sarcina
project manager-ului s Iormeze din acestia o echip, n care scopurile individuale sunt
subscrise scopului proiectului ca ntreg. IdentiIicarea nc de la nceput a scopurilor
proiectului este Ioarte important, iar aceste scopuri trebuie aduse la cunostin|a membrilor
echipei, n caz contrar, Iiecare persoan si va stabili propriile scopuri, ceea ce poate cauza
probleme serioase. De exemplu, un programator pune accent pe viteza programului, altul
doreste s Ioloseasc ct mai pu|in memorie, iar altul consider c cel mai important este s
scrie ct mai multe linii de cod.
Dup ce au Iost stabilite scopurile, trebuie monitorizate si evaluate performanele
membrilor echipei. Acest lucru este diIicil, deoarece mare parte din ceea ce se Iace este
,invizibil" iar progresul e greu de msurat. De aceea, n mod ideal, se deIineste
productivitatea drept suma Iunc|ionalit|ilor realizate n unitatea de timp. Din punct de
vedere practic, productivitatea se deIineste 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 Iaptul c programatorii
tind s scrie ct mai mult cod cu putin|, care are eIecte negative. De asemenea, deIini|ia
28/132
aceasta a productivit|ii nu ncurajeaz reutilizarea componentelor, care ar conduce la scrierea
unui cod mai mic.
3.3.1.1 Mecanisme de coordonare
Mintzberg (1983) distinge cinci conIigura|ii organiza|ionale tipice:
- Structura simpl: ntr-o structur simpl exist unul sau numai c|iva manageri
si un nucleu de persoane care lucreaz la produc|ia proiectului propriu-zis.
Aceast conIigura|ie este ntlnit de obicei n Iirmele noi, cu personal redus.
Specializarea este limitat, la Iel si instruirea si Iormalizarea. Mecanismul de
coordonare corespunztor este supervizarea direct;
- Birocraia automat: Cnd con|inutul sarcinilor este complet speciIicat, este
posibil executarea acestora pe baz de instruc|iuni precise. Exemple tipice ale
acestui tip de conIigura|ie sunt produc|ia de mas si liniile de asamblare.
Instruirea este redus, n schimb se pune mare accent pe specializare si
Iormalizare. Coordonarea se ob|ine prin standardizarea proceselor de lucru;
- Forma divizionalizat: n acest tip de conIigura|ie Iiecrei divizii (Iiecrui
proiect) i se acord o mare autonomie n ceea ce priveste modul de atingere a
scopurilor. Detaliile sunt stabilite de divizii. Coordonarea se ob|ine prin
standardizarea produc|iei. Controlul se exercit regulat prin msurarea
perIorman|elor diviziilor. Acest mecanism de coordonare este posibil numai
atunci cnd este speciIicat precis rezultatul Iinal;
- Birocraia profesional: Dac nu este posibil speciIicarea rezultatului sau
con|inutul sarcinilor, coordonarea poate Ii realizat prin standardizarea
caliIicrii. ProIesionistii talenta|i se bucur de o autonomie considerabil privind
modul de ndeplinire a atribu|iilor;
- Adhocraia: n proiecte mari si/sau inovatoare, lucrul este divizat ntre mai
mul|i specialisti, n acest caz, poate Ii greu sau chiar imposibil de stabilit cu
precizie ce trebuie s Iac Iiecare specialist sau modul n care trebuie s-si
ndeplineasc sarcinile. Succesul proiectului depinde de capacitatea grupului de
a atinge un scop nespeciIicat ntr-un mod nespeciIicat. Coordonarea se ob|ine
prin ajustare reciproc.
Trebuie spus c majoritatea organiza|iilor reale nu pot Ii ncadrate ntr-un singur tip de
conIigura|ie. DiIerite departamente ale Iirmei pot Ii organizate diIerit. De asemenea, tipurile
prezentate reprezint idei abstracte, n realitate, organiza|iile pot tinde spre unul din aceste
tipuri, pstrnd n acelasi timp si caracteristici ale celorlalte.
3.3.1.2 Stiluri de management
Teoria lui Reddin (1970) a stilurilor de management pune accent pe Iactorii interni.
Autorul distinge dou dimensiuni ale managementului Ior|ei de munc:
- gradul de dirijare a rela|iei: se reIer la aten|ia acordat individului si rela|iilor
lui cu al|i indivizi din organiza|ie;
- gradul de dirijare a sarcinii: priveste aten|ia acordat rezultatelor care trebuie
ob|inute si modului n care acestea trebuie ob|inute.
Gradele de dirijare pot Ii sczute sau ridicate, ceea ce conduce la patru combina|ii de
baz, prezentate n Tabelul 3-1. Desigur, aceste combina|ii corespund unor orientri extreme.
Pentru Iiecare dimensiune, exist n realitate o ntreag gam de nuan|e.
29/132
gradul de dirijare a
rela|iei
gradul de dirijare a sarcinii
sczut ridicat
sczut stil de separare stil de angajament
ridicat stil de rela|ionare stil de integrare
Tabelul 3-1 Stilurile de management ale lui Reddin
Stilul cel mai potrivit pentru o anumit situa|ie depinde de tipul lucrrii:
- Stilul de separare: Este cel mai potrivit pentru munca de rutin. EIicien|a este
tema central. Project manager-ul se comport ca un birocrat care aplic reguli si
proceduri. Acest stil corespunde conIigura|iei birocra|iei automate;
- Stilul de relaionare: Este cel mai eIicient n situa|iile n care oamenii trebuie
motiva|i, coordona|i si instrui|i. Sarcinile sunt clar atribuite indivizilor. Munca
nu are un caracter de rutin, ci este inovatoare si specializat. Stilul este
asemntor conIigura|iei de adhocra|ie;
- Stilul de angajament: Este cel mai eIicient cnd se lucreaz sub tensiune.
Project manager-ul trebuie s stie cum s se ating scopurile Ir s trezeasc
resentimente. Stilul e asemntor conIigura|iei de birocra|ie proIesional;
- Stilul de integrare: Se potriveste situa|iilor cnd rezultatul este nesigur. Munca
are o natur exploratorie si sarcinile au un puternic caracter de interdependen|.
Rolul project managerului este s stimuleze si s motiveze. Si n acest caz,
conIigura|ia de adhocra|ie este cea mai apropiat.
Fiecare proiect de dezvoltare soItware poate necesita diIerite mecanisme. De exemplu,
pentru o echip experimentat, care trebuie s dezvolte o aplica|ie bine speciIicat ntr-un
domeniu Iamiliar, coordonarea poate Ii realizat prin standardizarea produc|iei. Pentru o
aplica|ie complex si novatoare, acest mecanism ar Ii ineIicient.
3.3.2 Organizarea echipei
Indivizii coopereaz n cadrul unei echipe pentru a ob|ine un rezultat optim, ntr-o
echip se pot distinge diverse roluri: exist manageri, testeri, designeri, programatori s.a.m.d.
n Iunc|ie de dimensiunea proiectului, o persoan poate ndeplini mai multe roluri, sau diIerite
persoane pot avea acelasi rol. Este Ioarte important ca atribu|iile rolurilor s Iie bine precizate
si delimitate. Este de asemenea important ca anumite roluri s Iie separate; de exemplu, se
recomand separarea echipei de test de echipa de implementare.
Echipele mari sunt greu de gestionat si deseori sunt mpr|ite n subechipe. Prin
deIinirea clar a responsabilit|ilor subechipelor, comunicarea dintre membrii echipei se
limiteaz la comunicarea n cadrul aceleiasi subechipe, ceea ce mreste productivitatea.
3.3.2.1 Organizarea ierarhic
n mediile dedicate producerii de soItware, se ntlnesc deseori structuri ierarhice. n
Iunc|ie de dimensiunea proiectului si/sau a organiza|iei, pot exista diIerite nivele de
management.
Figura 3-2 prezint un exemplu de organizare ierarhic. Dreptunghiurile denot
subechipele n care se lucreaz eIectiv. Cercurile reprezint managerii. Aici avem dou nivele
de management. La nivelul inIerior, subechipele sunt responsabile de dezvoltarea diIeritelor
pr|i ale proiectului. Managerii acestora au rolul de a le coordona activitatea. La nivelul
superior, se coordoneaz activitatea subechipelor pe ansamblu.
30/132
Figura 3-2 Organizare ierarhic
Organizarea ierarhic reIlect deseori structura global a sistemului care trebuie
dezvoltat. Dac sistemul are trei subsisteme majore, pot exista trei subechipe. De asemenea,
pot exista unit|i Iunc|ionale asociate cu responsabilit|i speciIice proiectului, cum ar Ii
testarea.
O problem a organizrii ierarhice este distan|a dintre nivelele superioare si inIerioare
ale piramidei. Munca ,real" se Iace de obicei pe nivelele inIerioare, unde sunt prelucrate
cunostin|ele concrete despre aplica|ie. Pe msur ce ne ridicm n ierarhie, cunoasterea devine
din ce n ce mai pu|in speciIic; de aceea managementul de pe nivelele superioare tinde s
aplice coordonarea prin standardizare. Totusi, 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 inIorma|ia 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 conIorm planului.
Aceste distorsiuni sunt totusi diIicil de mpiedicat. Ele sunt cauzate de Iaptul c linia
ierarhic pe care se raporteaz progresul este aceeasi cu cea utilizat pentru evaluarea
perIorman|elor. Oamenii doresc evaluri pozitive si de aceea tind s-si modiIice si rapoartele
n consecin|. Dac datele privind progresul proiectului sunt colectate si prelucrate de
persoane neimplicate n evaluarea membrilor echipei, cresc mult sansele ca si inIorma|iile s
Iie suIicient de corecte.
Un alt aspect problematic al acestui tip de organizare este Iaptul c individul este
judecat, att din punct de vedere social ct si Iinanciar, dup nivelul pe care l ocup n
ierarhie. Este de n|eles aspira|ia de a ajunge pe nivele din ce n ce mai nalte, desi nu este
Ioarte clar dac acest lucru este de dorit. Principiul lui Peter din legile lui Murphy spune: ntr-
o organiza|ie ierarhic, Iiecare angajat urc pn la nivelul su de incompeten|. Totusi, un
programator bun nu e neaprat si un bun manager. Programarea necesit competen|e diIerite
de cele ale managementului. Ideal ar Ii stimularea oamenilor pentru men|inerea lor pe
nivelele la care lucreaz cel mai bine.
3.3.2.2 Organizarea matrice
Acest tip de organizare este deseori ntlnit n situa|ia cnd la un proiect soItware
lucreaz oameni din diIerite departamente si care pot avea simultan mai mul|i seIi. Unitatea
de baz este un grup mic, specializat. Pot exista mai multe unit|i cu aceeasi specializare.
Unit|ile sunt organizate n conIormitate cu specializarea lor; de exemplu: graIic
computerizat, baze de date, interIe|e utilizator, controlul calit|ii etc. Proiectele implic
31/132
unit|i cu diIerite specializri. Indivizii sunt organiza|i pe dou axe: una reprezentnd
grupurile specializate iar cealalt - proiectele la care particip:
programare n
timp real
graIic 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 situa|ie, project manager-ul este responsabil de terminarea cu succes a
proiectului. El controleaz una sau mai multe unit|i si trebuie s men|in sau s mreasc, pe
termen lung, baza de cunostin|e si experien|a membrilor echipei. El poate pune accent pe
ridicarea gradului de dirijare a sarcinii, n timp ce managerii unit|ilor se pot concentra pe
cresterea gradului de dirijare a rela|iei. O astIel de organizare poate Ii Ioarte eIicient, cu
condi|ia s existe suIicient ncredere reciproc si dorin| de cooperare.
3.3.2.3 Echipa programatorului yef
Acest tip de organizare a Iost propus de Harlan Mills (1970). Nucleul unei astIel de
echipe const n trei persoane. Programatorul seI este conductorul echipei si rspunde de
proiectarea si implementarea por|iunilor cheie ale sistemului. El este ajutat de un asistent.
Dac e nevoie, acesta poate lua temporar locul programatorului seI. Un bibliotecar se ocup
de administrare si documentare. Pe lng aceste trei persoane, mai poate exista un mic grup de
exper|i. Evident, programatorul seI joac un rol central si trebuie s Iie Ioarte competent, mai
ales n domeniul tehnic, dar si managerial. Se pune problema dac exist suIicien|i astIel de
programatori seIi.
No|iunea ini|ial de programator seI pare elitist. Pentru un proiect de dimensiuni Ioarte
mari este mai plauzibil ideea unui grup restrns responsabil colectiv. Rolurile nu sunt
structurate n Iunc|ie de stadiile ciclului de via| a produsului. Nu exist analisti, designeri,
programatori. Testarea ns poate Ii alocat unei anumite persoane. In grup pot exista diIerite
nivele de experien|. Persoanele cele mai experimentate au rolul de programator seI si
asistent, nceptorii nva| din mers si la nceput pot ndeplini rolul bibliotecarului.
3.3.2.4 Principii generale de organizare a unei echipe
IndiIerent de modul n care este organizat o echip, cel mai important este Iaptul c
trebuie s Iie o echip. Testele privind productivitatea n proiectele de dezvoltare soItware au
artat c Iactorii privind capacit|ile echipei au o importan| mult mai mare dect orice
altceva. Principiile de organizare a unei echipe n general se aplic si n cazul proiectelor
soItware:
- Folosirea unui numr mic de oameni capabili: Productivitatea maxim este
ob|inut de un grup relativ mic de oameni. Grupurile mari necesit mai mult
comunicare, care are eIecte negative asupra productivit|ii si duce la erori mai
multe;
- Sarcinile trebuie puse n acord cu motiva|iile si capacit|ile oamenilor
disponibili: Cu alte cuvinte, trebuie s ne asigurm ca principiul lui Peter nu se
aplic si n cazul echipei noastre, n cele mai multe organiza|ii, programatorilor
Ioarte buni li se oIer Iunc|ii manageriale. Este mult mai bine s li se oIere
posibilit|i de a avansa n carier n arii mai tehnice ale dezvoltrii si ntre|inerii
soItware-ului;
32/132
- Pe termen lung, organiza|ia are mai mult de cstigat dac i ajut pe angaja|i s
dea ceea ce au mai bun: AltIel spus, nici una din situa|iile urmtoare nu trebuie
s aib loc:
- Principiul lui Peter inversat: angaja|ii 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 sansa s lucreze n alt domeniu. S-ar
putea ca persoana respectiv s prseasc Iirma pentru a lucra la altceva mai
interesant;
- Principiul lui Paul: angaja|ii urc n ierarhie pn la nivelul la care experien|a lor
devine nvechit n cinci ani: Avnd n vedere viteza cu care nout|ile intr pe
pia|a dezvoltrii soItware, angaja|ii trebuie s aib posibilitatea s Iie la curent
cu acestea;
- Este bine s Iie selecta|i oameni care s Iormeze o echip bine echilibrat si
armonioas: Nu este suIicient s existe n echip doar c|iva exper|i de vrI.
Trebuie s existe si persoane care s ndeplineasc sarcinile mai simple, de
rutin, pe care exper|ii s-ar putea sim|i chiar insulta|i s le rezolve;
- Cine nu se potriveste cu echipa trebuie ndeprtat: Dac echipa nu Iunc|ioneaz
ca o unitate coerent, de multe ori suntem nclina|i s mai asteptm pu|in, s
vedem cum evolueaz lucrurile si s sperm ca totul va merge bine. Acest lucru
este duntor pe termen lung.
3.4 Concluzii
n acest curs au Iost prezentate mai nti no|iuni legate de managementul unui proiect
soItware, precum planiIicarea si controlul proiectului. Apoi au Iost tratate problemele legate
de gestionarea crerii si modiIicrii elementelor caracteristice unui proiect de dezvoltare
soItware. Au Iost explicate mecanismele care |in de managementul unei echipe, privind n
deosebi coordonarea si stilurile de management, alturi de modalit|i de organizare a echipei
si sIaturi practice pentru organizarea optim a unei echipe de dezvoltare a unui proiect
soItware.
33/132
4 Estimarea costuIui unui proiect software
4.1 Introducere
La construirea unei case, la decorarea unei bi sau a unei grdini, dorim s cunoastem
costul precis al opera|iilor ce urmeaz a Ii eIectuate nainte de nceperea acestora. Un grdinar
este capabil s Iac o aproximare a costurilor bazndu-se, de exemplu, pe tipul pmntului,
mrimea dorit a terasei sau a zonei cu iarb, prezen|a sau absen|a unui iaz si pe alte
inIorma|ii similare. Apoi aceast estimare poate Ii Icut mai precis printr-un dialog ulterior
nainte de a se ncepe lucrrile. Cine doreste o precizie similar n ceea ce priveste estimarea
costurilor pentru un proiect de dezvoltare soItware ar putea avea o surpriz.
Estimarea costurilor unei aplica|ii soItware reprezint un domeniu Ioarte pu|in
dezvoltat, n care to|i se bazeaz doar pe aproximri. Din Iericire exist si excep|ii de la
aceast situa|ie. Acum exist un numr de algoritmi care ne permit s estimm costul total si
timpul de dezvoltare pentru un proiect soItware pe baza unui numr limitat de generatori
relevan|i de costuri.
n cele mai multe modele de estimare, este presupus o rela|ie simpl ntre cost si eIort.
EIortul poate Ii msurat de exemplu n luni-om (adic numrul estimativ de luni necesar unui
singur om s realizeze lucrarea), si Iiecrei luni-om i se asociaz o sum Iix de bani,
corespunztor salariului angaja|ilor. Costul total estimat se ob|ine nmul|ind numrul estimat
de luni-om cu Iactorul constant considerat.
No|iunea de cost total reprezint de obicei costul eIortului ini|ial de dezvoltare soItware,
costul analizei cerin|elor, proiectrii, implementrii si testrii, Ir a Ii luate n considerare
costurile de ntre|inere. Prin timp de dezvoltare se n|elege timpul dintre speciIicarea
cerin|elor si momentul n care produsul soItware va Ii predat clientului. No|iunea de cost, care
se va Iolosi n continuare, nu include si posibilele costuri hardware. Ea include numai
costurile legate de personalul angajat n dezvoltarea produsului soItware.
Cercetrile n domeniul estimrii costului sunt departe de a Ii cristalizate. DiIerite
modele Iolosesc diIerite sisteme de msur si generatori de costuri, nct este Ioarte diIicil
compararea lor. S presupunem c un model Ioloseste o ecua|ie de Iorma:
1.05
2.7 E KLOC =
Acesta ecua|ie arat o rela|ie ntre eIortul necesar si mrimea produsului (KLOC Kilo-
Lines OI Code, kilo-linii de cod). Unitatea de msur a eIortului poate Ii numrul de luni-om
necesare. Apar aici mai multe ntrebri. Ce este o linie de cod? Numrm codul masin sau
codul surs ntr-un limbaj de nivel nalt? Numrm de asemenea si comentariile, liniile libere
care mresc vizibilitatea sau nu? Lum n considerare si zilele libere, vacan|ele, concediile
medicale n no|iunea de luni-om sau se reIer numai la o msurare net? DiIerite interpretri
ale acestor ntrebri pot conduce la rezultate complet diIerite. Uneori nici nu este cunoscut ce
deIini|ii au Iost Iolosite n aplicarea modelului.
Pentru a determina ecua|iile unui model algoritmic de estimare a costului, putem urma
diIerite abordri, n primul rnd ne putem baza ecua|ia pe rezultatul experimentelor, ntr-un
asemenea experiment, n general variem un parametru, n timp ce ceilal|i parametri rmn
constan|i. In acest Iel ncercm s determinm inIluen|a pe care o are parametrul care variaz.
Un exemplu tipic este cel ce testeaz dac comentariile ajut la n|elegerea unui program.
Vom pune un numr de ntrebri despre acelasi program unor programatori mpr|i|i n dou
grupuri. Primul grup va primi programul Ir comentarii, iar al doilea grup va primi textul
aceluiasi program, dar comentat. Folosind rezultatele celor dou grupuri, putem testa ipoteza
realist c o n|elegere mai bun si mai rapid a programului are eIecte pozitive asupra
ntre|inerii programului.
34/132
O alt modalitate de a descoperi modele algoritmice de estimare a costului se bazeaz
pe o analiz a datelor unui proiect real, dar si pe un suport teoretic. O organiza|ie poate
strnge date despre un numr de sisteme soItware care au Iost dezvoltate. Aceste date pot
privi timpul petrecut la diIerite Iaze bine determinate, caliIicarea personalului implicat,
momentele de timp n care au aprut erori, att n timpul testrii ct si dup instalare,
complexitatea, robuste|ea si al|i Iactori importan|i ai proiectului, mrimea diIeritelor entit|i
implicate si o analiz statistic a acestor date. Un exemplu pentru o asemenea rela|ie este cea
dat mai sus, ce exprim o legtur ntre E si KLOC. Aplicabilitatea si corectitudinea acestor
ecua|ii este, n mod evident, dependent de corectitudinea datelor pe care se bazeaz. De
asemenea, trebuie cunoscut ipoteza ce st la baza ecua|iei.
Rezultatele ob|inute n acest Iel reprezint o medie, cea mai bun aproximare bazat pe
datele disponibile, de aceea rezultatele ob|inute trebuie aplicate cu aten|ie. De exemplu,
programul ce urmeaz a Ii dezvoltat n cadrul unui nou proiect nu se poate compara cu
produse anterioare datorit inova|iilor implicate. Estimarea costurilor pentru un proiect legat
de o navet spa|ial nu poate Ii Icut printr-o simpl extrapolare a proiectelor anterioare.
Trebuie re|inut c aplicarea oarb a unor Iormule din modele existente nu va rezolva
problema estimrii costului. Fiecare model necesit o adaptare la mediul n care va Ii Iolosit.
Aceasta conduce la necesitatea colectrii continue a datelor din propriul proiect si aplicarea
unor metode statistice pentru a calibra parametrii modelului.
Neconcordan|ele dintre diIeritele modele mai pot aprea deoarece:
- Majoritatea modelelor oIer o rela|ie ntre numrul lunilor-om necesar si mrime
(n linii de cod). Dup cum am remarcat mai devreme, exist mai multe deIini|ii
diIerite pentru aceste no|iuni;
- EIortul nu nseamn ntotdeauna acelasi lucru. Uneori se consider activit|ile
pornind de la conceperea produsului, dup ce au Iost Iixate cerin|ele. Alteori se
includ eIorturile de ntre|inere.
- Cu toate acestea, modelele de estimare a costului au multe caracteristici comune.
Acestea reIlect importan|a Iactorilor care intervin asupra costului de dezvoltare
si de eIortului. Cresterea n|elegerii costului programelor ne permite s
identiIicm strategii de crestere a productivit|ii soItware, cele mai importante
Iiind:
- Scrierea de mai pu|in cod: Mrimea sistemului este una din cauzele principale a
eIortului si a costului. Prin metode care ncearc sa reduc mrimea, cum ar Ii
reutilizarea programului si utilizarea de limbaje de nivel nalt, se pot ob|ine
reduceri semniIicative;
- Stimularea oamenilor s lucreze la capacitatea maxim: Capacit|ile de lucru
individual si n echip au un mare impact asupra productivit|ii. Angajarea celor
mai buni oameni este de obicei o aIacere proIitabil. O mai bun stimulare,
condi|ii mai bune de lucru, cursurile de perIec|ionare asigur oportunit|i de
crestere a productivit|ii; Evitarea reIacerii componentelor dezvoltate anterior:
Studiile au artat c pentru a rescrie ceea ce s-a produs deja este necesar un eIort
considerabil. Aplicnd modele cum ar Ii realizarea prototipurilor si utilizarea
metodelor moderne de programare precum ascunderea inIorma|iilor, se pot
reduce semniIicativ costurile;
- Dezvoltarea si Iolosirea mediilor de dezvoltare integrate, cu instrumentele ce pot
ajuta la eliminarea sau eIicientizarea unor etape.
Au Iost Icute numeroase studii n care scopul principal era estimarea eIortului necesar
pentru o sarcin limitat de programare. Primele experimente au Iost realizate de Halstead
(1977). La baza modelului su st Iaptul c numrarea liniilor de cod poate constitui o
problem, chiar dac avem o deIini|ie exact a termenului ,linie de cod". Unele linii sunt mult
35/132
mai complicate dect altele. ConIorm teoriei lui Halstead, este mai bine s se porneasc de la
un numr de unit|i sintactice, dup cum sunt recunoscute de compilator. Halstead Iace
distinc|ia ntre operatori si operanzi. Operatorii denot o opera|ie; exemple de operatori sunt
operatorii standard (, -, *, etc.), dar si semnul de punctua|ie punct si virgul (;) care arat
structura unei instruc|iuni si construc|ii ca iI-then-else si while-do. Operanzii nseamn date:
variabile si constante. Calcularea numrului de operatori si operanzi dintr-un program va oIeri
o mai bun msur a mrimii dect simpl calculare a numrului de linii.
Cele patru entit|i de baz pentru un program, n modelul Halstead sunt:
-
1
n numrul de operatori diIeri|i;
-
2
n numrul de operanzi diIeri|i;
-
1
N numrul total de apari|ii ale operatorilor;
-
2
N numrul total de apari|ii ale operanzilor;
Pentru lungimea unui program, Halstead d urmtoarea ecua|ie:
1 2
N N N = +
AstIel se ob|ine o raIinare a msurrii numrului de linii simple de cod, LOC. Att LOC
ct si N oIer o bun corela|ie cu eIortul de programare. De aceea este important s se
gseasc modalit|i de estimare a entit|ilor precum LOC si N n primele etape. Valoarea lui
N depinde de
1
n si
2
n . Valoarea lui
1
n este, de cele mai multe ori, un Iactor 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 Ii utilizat n orice program este Iix: to|i sunt prezenta|i n sintaxa
limbajului. Majoritatea programelor vor Iolosi un mare procent din acestea, cel pu|in 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 Iost enun|at urmtoarea rela|ie empiric:
102 5.31 LOC JARS = +
AstIel, Iiecare program va con|ine aproximativ 100 de linii de cod, plus 5 linii
suplimentare pentru Iiecare variabil ce apare n program. Primele experimente arat c n
acest Iel se pot ob|ine aproximri destul de corecte ale mrimii si eIortului necesar. Valoarea
estimat a lui VRS poate Ii ob|inut relativ devreme dac este Iolosit o metod de
proiectare top-down n combina|ie cu un limbaj de nivel nalt.
Generalizarea acestor rezultate la programe mai mari nu este indicat, n programele
mai complexe, Iactori precum interIa|a dintre componente si comunicarea necesar ntre
persoanele implicate joac un rol ce nu poate Ii neglijat. Cunoscnd mrimea estimat a unui
proiect, vom Ii interesa|i 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 Ii 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 Iizic. Dac vom ncerca s micsorm acest timp nominal de
dezvoltare prea mult, vom intra ntr-o ,zon imposibil", iar sansele de esec vor creste.
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 reIlect aceste argumente non-
tehnice sunt prezentate n exemplele urmtoare:
- Dac avem 12 luni pentru a Iinaliza o lucrare, ea va necesita 12 luni. Acest
motiv poate Ii privit ca o variant a legii Parkinson: munca ocup tot timpul
disponibil;
36/132
- Dac stim c concuren|a a Icut o oIert de 100.000 de euro, noi vom Iace o
oIert de 90.000 de euro. Acesta este cunoscut sub denumirea de pre| de cstig;
- Dorim s ne promovm produsul la un anumit trg de tehnic de calcul si din
acest motiv programul trebuie scris si testat n urmtoarele 9 luni, desi realizm
c timpul este limitat. Aceast situa|ie este cunoscut sub denumirea de metoda
bugetului de estimare a costului.
- Proiectul poate Ii dezvoltat ntr-un an, dar seIul nu ar accepta acest termen. Stim
c termenul de 10 luni este acceptabil si atunci l programm pentru 10 luni.
Aceste estimri pot avea eIecte dezastruoase, dup cum s-a demonstrat Irecvent n
scurta istorie a acestui domeniu. Argumentele politice intervin ntotdeauna dac estimrile
sunt realizate de cei implica|i direct n proiect, cum ar Ii managerul proiectului sau o persoan
ce lucreaz direct cu acesta, n curnd estimrile vor inIluen|a sau vor Ii inIluen|ate de ctre
dorin|ele 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
experien|ei, n 1968, unei echipe de programatori i s-a cerut s dezvolte un compilator
FORTRAN pentru trei masini diIerite. EIortul necesar pentru aceste trei proiecte este descris
n tabelul de mai jos:
Compilatorul EIortul (n luni-om)
Compilatorul EIortul (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 cuantiIicat, precum caracteristicile de personalitate sau
caracteristici neobisnuite ale proiectului, pot Ii astIel lua|i n considerare, n acest caz,
calitatea estimrii nu poate depsi calitatea expertului.
Pentru o estimare mai precis se pot solicita mai mul|i exper|i. Totusi, dac un grup de
persoane trebuie s gseasc mpreun o solu|ie, vom observa c unii membri ai grupului au
un impact mai mare asupra rezultatului dect ceilal|i. Unii nu si vor exprima opinia sau vor Ii
impresiona|i de opiniile celorlal|i. Aceasta poate avea un impact negativ asupra rezultatului
Iinal. Pentru a anticipa acest eIect negativ, putem Iolosi metoda Delphi, n metoda Delphi,
Iiecare expert si expune opinia n scris. Un moderator colecteaz estimrile ob|inute astIel si
le redistribuie celorlal|i exper|i, n acest proces nu sunt asociate numele exper|ilor cu
estimrile lor. Fiecare expert va preda o nou estimare bazat pe inIorma|iile primite de la
moderator. Acest proces continu pn cnd se ajunge la un consens.
O alt metod care doreste ob|inerea 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 si o
estimare pesimist b. Folosind o distribu|ie beta, eIortul asteptat va Ii:
4
6
a m b
E
+ +
=
Aceast estimare va Ii probabil mai bun dect dac s-ar Ii considerat numai media
aritmetic a lui a si b.
4.3 Modele algoritmice clasice
Mesajul din paragraIul precedent este clar: pentru a ob|ine estimri acceptabile, trebuie
nregistrate datele proiectelor anterioare. Procednd astIel, vom prezice costul pe baza
37/132
propriet|ilor msurabile ale proiectului curent. In acest paragraI, vom prezenta primele
demersuri pentru a ob|ine modele algoritmice de estimare a costului programelor.
Nelson (1966) oIer un model liniar pentru estimarea eIortului necesar pentru un proiect
de dezvoltare soItware. Modelele liniare au urmtoarea Iorm:
0
1
n
i i
i
E a a x
=
= +

n
CoeIicien|ii
i
a sunt constante, iar
i
x reprezint Iactorii care au impact asupra eIortului
necesar. Un numr mare de Iactori poate inIluen|a productivitatea si implicit eIortul necesar.
Analiznd cu aten|ie datele proiectelor precedente si diIerite combina|ii de Iactori, putem
ncerca s ob|inem un model cu un numr mic de Iactori. Nelson, de exemplu, sugereaz un
model care ia n considerare 14 Iactori:
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 ecua|ie E reprezint numrul estimat de luni-om necesar. SemniIica|ia
Iactorilor
i
x si domeniul lor de deIini|ie sunt prezentate n tabelul urmtor:
Factor Descriere Valori posibile
1
x
Instabilitatea speciIica|iilor cerin|elor 0-2
2
x
Instabilitatea proiectrii 0-3
3
x
Procentajul de instruc|iuni matematice 0-100
4
x
Procentajul de instruc|iuni I/O 0-100
5
x
Numrul subprogramelor numr
6
x
Utilizarea unui limbaj de nivel nalt 0 (da) / 1 (nu)
7
x
Aplica|ie comercial 0 (da) / 1 (nu)
8
x
Program de sine stttor 0 (da) / 1 (nu)
9
x
Primul program pe aceast masin 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
Masina gazd diIerit de masina |int 1 (da) / 0 (nu)
13
x
Numr de erori numr
14
x
Dezvoltare pentru o organiza|ie militar 0 (da) / 1 (nu)
Putem Iace mai multe observa|ii asupra acestui model, n dezvoltarea programelor
pentru aplica|iile de aprare, n care programele vor Ii ncorporate n masini diIerite de masina
gazd (un exemplu ar putea Ii programul de control al zborului pentru rachete), Iactori precum
12
x si
14
x vor avea cu siguran| un impact mare asupra costului. Aceasta nu se va mai veriIica
ns ntr-un caz complet diIerit. Observm din nou c baza de date cu datele proiectelor care
stau la baza modelului au un impact semniIicativ asupra Iactorilor care inIluen|eaz costul.
Pu|in probabil n acest model este penalizarea din cauza Iolosirii limbajului de asamblare n
locul unui limbaj de nivel nalt (
6
x ): aproximativ 7 luni-om, indiIerent de mrimea
proiectului, n mod similar, constanta negativ a0 si ceilal|i doi Iactori care au coeIicien|i
negativi au o probabilitate mic de apari|ie.
n general modelele liniare nu Iunc|ioneaz Ioarte bine. Desi exist un numr mare de
Iactori care inIluen|eaz productivitatea, este pu|in probabil ca ei s intervin independent si
liniar.
38/132
Trebuie atras aten|ia asupra preciziei acestui tip de Iormul, n Iormula lui Nelson,
constantele sunt date cu precizia a 2 zecimale. Aplicnd aceast Iormul va rezulta o estimare
a eIortului de genul 97,32 de luni-om. Va trebui totusi s avem grij la capcana exprimat n
sloganul: exist trei tipuri de minciuni - minciuni mici, minciuni mari si statistici. Formula lui
Nelson este rezultatul analizei statistice a datelor unui proiect real si trebuie interpretat ca
atare, adic n termeni probabilistici. Dac avem o estimare E, atunci eIortul real R va veriIica
Iormula:
, ) , ) , )
1 1 P E R E s s + > ,
unde valori acceptabile pentru si sunt: 0,2 si 0,9.
S presupunem c estimarea este de 100 luni-om. SemniIica|ia Iormulei este
urmtoarea: probabilitatea ca proiectul s necesite n realitate ntre 80 si 120 de luni-om este
mai mare ca 90.
Costurile estimate prin acest tip de model rezult ntr-un anumit interval, rmnnd o
probabilitate diIerit de zero ca acesta s Iie n aIara intervalului. Aplicabilitatea acestor
estimri este puternic inIluen|at de mrimea intervalului si de probabilitatea ca valoarea real
a costului sa Iie ntr-adevr n acel interval, n special pentru proiectele ce necesit eIort mai
mare, este bine s se considere valoarea superioar a intervalului n care se aIl 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 Iiecare modul, va Ii ob|inut un cost estimativ iar costul Iinal va Ii
suma costurilor modulelor, cu o corec|ie aplicat datorit integrrii modulelor.
Wolverton descrie un model n care o matrice a costurilor este Iolosit ca punct de
plecare n determinarea costurilor modulelor, n aceast matrice exist un numr limitat de
tipuri diIerite de module si un numr de nivele de complexitate. Tabelul urmtor ilustreaz o
matrice ipotetic de costuri. Elementele matricei reIlect costul pentru Iiecare linie de cod.
Tipul modulului Complexitate
Mic <-> Mare
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. InterIa| 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 si mrime
k
S , va
rezulta un cost al modulului
k k if
M S C = .
Acest tip de model are de asemenea probleme, n aIar de diIicultatea estimrii costului
de integrare a modulelor, utilizatorul trebuie s estimeze subiectiv clasa de complexitate din
care Iace parte Iiecare modul, ceea ce determin un grad mare de nesiguran|. Al|i Iactori care
vor avea impact asupra productivit|ii, cum ar Ii experien|a n programare si caracteristicile
hardware, nu sunt lua|i n considerare. Extinderea matricei pentru a include si acesti Iactori ar
creste gradul de subiectivitate al metodei.
4.4 Modele algoritmice moderne
n paragraIele anterioare am remarcat Iaptul c eIortul de programare este corelat cu
mrimea programului. Exist diIerite modele (neliniare) care exprim aceast legtur. O
Iorm general este:
, ) , )
1
,...,
c
n
E a b KLOC f x x = + ,
39/132
unde KLOC reprezint mrimea programului n kilo-linii de cod, iar E reprezint eIortul
n luni-om. a, b sic sunt constante iar , )
1
,...,
n
f x x este o Iunc|ie care depinde de valorile
Iactorilor
1
,...,
n
x x . n general, Iormula de baz este:
c
E a b KLOC = + .
Ea este ob|inut printr-o analiz de regresiune a datelor proiectelor disponibile. Totusi
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 Iactori care
inIluen|eaz productivitatea (asa numi|ii generatori de cost). De exemplu, dac unul din
Iactorii Iolosi|i reprezint ,experien|a echipei de programatori aceasta poate cauza o corec|ie
a costului nominal estimat cu 1.50, 1.20, 1.00, 0.80, 0.60 pentru un nivel de expertiz Ioarte
sczut, sczut, mediu, nalt si respectiv Ioarte nalt.
Tabelul urmtor con|ine unele Iormule de baz Ioarte cunoscute pentru rela|ia dintre
mrimea programului si eIort. Din motivele enun|ate anterior este diIicil 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 apari|ia unui Ienomen Ioarte bine cunoscut din teoria economic.
Pentru o produc|ie de mas, se presupune c este mai ieItin s se produc mari cantit|i din
acelasi produs. Costurile Iixe vor Ii mpr|ite astIel unui numr mai mare de unit|i, 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 si
instrumente de testare, care poate Ii distribuit unui numr mai mare de linii de cod.
In cazul opus (c ~ 1), observm c dup un anumit punct, producerea de unit|i
suplimentare implic costuri suplimentare. Putem aIirma c programele Ioarte mari vor Ii
mult mai scumpe. Suma necesar va Ii mai mare deoarece creste necesitatea de comunicare si
de control managerial, deoarece problemele si interIe|ele devin mai complexe. Deci Iiecare
linie de cod suplimentar necesit mai mult eIort.
Nu exist nici un argument convingtor pentru nici un tip de rela|ie, desi ultima (c ~ 1)
pare mai plauzibil, n mod sigur, pentru proiecte Ioarte mari, eIortul creste mai mult dect
liniar cu mrimea. Este evident c valoarea exponentului c inIluen|eaz Ioarte mult valoarea
calculat E, n special pentru valori mari ale KLOC. Tabelul urmtor prezint valorile lui E,
calculate prin metodele prezentate anterior si pentru cteva valori ale KLOC. Se remarc
marea diIeren| dintre modele. Pentru programe mici, prin metoda Halstead rezult costuri
estimate mici. Pentru proiecte cu aproximativ un milion de linii de cod, acelasi 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
40/132
Aceste observa|ii nu trebuie s ne conduc la concluzia c aceste metode sunt complet
inutile. Este mai probabil c exist diIeren|e mari ntre caracteristicile seturilor de proiecte pe
care se bazeaz diIerite modele. Stim c numerele utilizate n modele provin din urma analizei
datelor proiectelor reale. Dac aceste date reIlect diIerite proiecte si/sau medii de dezvoltare,
modelele se vor comporta la Iel. Nu putem copia pur si simplu aceste Iormule. Fiecare mediu
are caracteristicile sale proprii si este deci necesar adaptarea parametrilor la mediul speciIic
(proces numit calibrare).
Cea mai important problem a acestui model este ob|inerea unei estimri sigure a
mrimii programului de la nceput. Cum am putea s estimm numrul de pagini ale unui
roman care nu a Iost scris nc? Chiar dac stim numrul de personaje, de loca|ii si intervalul
n care se va desIsura povestea, este o iluzie asteptarea de la nceput unei estimri realiste a
mrimii. Cu ct naintm n realizarea proiectului, cu att va Ii mai exact estimarea mrimii.
Dac proiectarea se apropie de Iinal, ne putem Iorma o impresie rezonabil asupra mrimii
programului rezultat. Dar numai cnd sistemul va Ii predat vom cunoaste numrul exact.
Clientul ns solicit o estimare a pre|ului 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 paragraIele urmtoare, vom analiza cteva modele ce
se bazeaz pe mrimi cunoscute ntr-o etap ini|ial.
4.4.1 ModeIuI WaIston-FeIix
Ecua|ia ce st la baza modelului Walston-Felix este:
0.91
5.2 E KLOC = . Acest model a
Iost creat prin analiza a 60 de proiecte de la IBM. Aceste proiecte erau complet diIerite ca
mrime, iar programele au Iost scrise n mai multe limbaje de programare. Totusi nu
reprezint o surpriz Iaptul c dac aplicm acest model chiar unei submul|imi a celor 60 de
proiecte, nu vom avea rezultate satisIctoare.
ncercnd s explice aceste rezultate dintr-o plaj mare de valori, Walston si Felix au
identiIicat 29 de variabile care inIluen|eaz n mod sigur productivitatea. Pentru Iiecare din
aceste variabile au Iost considerate trei nivele: mare, mediu si mic. Pentru un numr de 51 de
proiecte, Walston si Felix au determinat nivelul Iiecrei variabile din cele 29, mpreun cu
productivitatea ob|inut (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
interIa| utilizator de complexitate sczut. Pentru o interIa| de complexitate nalt sau
medie, productivitatea este de 295 si respectiv 124 de linii de cod pe lun. Ultima coloan
reprezint varia|ia productivit|ii, PC (engl. ,productivity change"), valoarea absolut a
diIeren|ei dintre valorile minime si maxime.
Variabila Productivitatea medie pentru valoarea variabilei PC
Complexitatea interIe|ei
utilizator
normal
500
normal
295
~ normal
124
376
CaliIicarea si experien|a
personalului
mic
132
medie
257
mare
410
278
41/132
Experien| anterioar cu
aplica|ii similare
minim
146
medie
221
vast
410
264
Procentajul de programatori
participan|i n Iaza de proiectare
25
153
25-50
242
~ 50
391
238
Raportul dintre mrimea medie
a echipei si durata proiectului
(persoane/lun)
0.5
305
0.5-0.9
310
~0.9
171
134
Walston si Felix consider c indexul productivit|ii I poare Ii determinat pentru noile
proiecte dup urmtoarea rela|ie:
29
1
i i
i
I W X
=
=

unde ponderile
i
W sunt deIinite astIel:
, )
10
0.5 log
i i
W PC = .
n rela|ia de mai sus,
i
PC reprezint varia|ia productivit|ii Iactorului I . Pentru primul
Iactor din tabelul de mai sus, complexitatea interIe|ei cu utilizatorul, rezult urmtoarele:
1
PC
376, deci
1
W 1.29. Variabilele
i
X pot lua valorile 1 , 0 sau l, unde Iactorul
corespunztor este de nivel sczut, mediu sau nalt. Indexul productivit|ii ob|inut poate Ii
tradus ntr-o productivitate asteptat (linii de cod scrise pe lun-om).
Trebuie men|ionat c numrul Iactorilor lua|i n considerare n acest model este destul
de ridicat (29 de Iactori din 51 de proiecte). De asemenea, nu este clar cum acesti Iactori se
inIluen|eaz unul pe cellalt. Un alt dezavantaj ar Ii c numrul de alternative pentru Iiecare
Iactor este de numai 3, si nu oIer destule op|iuni pentru situa|iile practice.
4.4.2 ModeIuI COCOMO
COCOMO (COnstuctive COst MOdel) este unul din cei mai bine documenta|i
algoritmi de estimare a costului (Boehm, 1981). n Iorma sa cea mai simpl, numit ,Basic
COCOMO", Iormula care exprim legtura dintre eIort si mrimea programului este:
c
E b KLOC = ,
unde b si 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 organiza|ia lor. AstIel, ei pot s lucreze de la nceput,
neIiind necesare investi|ii ini|iale. 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 Ii integrat ntr-un mediu care este Ioarte strict.
Exemplu de asemenea proiecte sunt programe de control al traIicului aerian sau
aplica|iile militare;
- Semidetasate: Aceasta este o Iorm intermediar. Echipa poate Ii Iormat din
persoane experimentate si neexperimentate, proiectul poate Ii destul de mare, dar
nu Ioarte mare.
Pentru clase diIerite, parametrii metodei Basic COCOMO iau urmtoarele valori:
Clasa de proiect b c
organic 2.4 1.05
semidetasat 3.0 1.12
integrat 3.6 1.20
42/132
Tabelul urmtor prezint estimri ale eIortului pentru Iiecare din cele trei moduri,
pentru diIerite valori ale KLOC (desi un proiect organic de un milion de linii de cod nu este
realist). Se observ inIluen|a Ioarte mare a constantei c asupra estimrilor ob|inute. Estimrile
eIortului sunt exprimate tot n luni-om.
KLOC organic semidetasat integrat
1 2.4 3.0 3.6
10 26.9 39.6 57.1
50 145.9 239.4 392.9
100 302.1 521.3 904.2
1000 3390 6872 14333
4.4.3 ModeIuI Putnam-Norden
Norden a studiat distribu|ia Ior|ei de munc n timp ntr-un numr de proiecte de
dezvoltare soItware n anii '60. A descoperit c aceast distribu|ie avea deseori o Iorm
caracteristic. Aceast Iorm caracteristic este bine aproximat de distribu|ia Rayleigh.
Bazndu-se pe aceast descoperire, Putnam a dezvoltat un model de estimare a costului n
care Ior|a 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 Iactor de accelerare care determin panta ini|ial a curbei, iar K
reprezint Ior|a de munc total necesar, incluznd Iaza de ntre|inere. K este egal cu
volumul zonei delimitate de curba Rayleigh, reprezentat n Iigura l.
Integrarea ecua|iei pentru , ) FM t determin eIortul 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 Ii apropiat de momentul de timp n care proiectul
va Ii predat clientului. Aria delimitat de curba Rayleigh ntre punctele 0 si T va Ii o bun
aproximare a eIortului ini|ial de dezvoltare. Pentru acesta ob|inem:
, ) 0.3945 E I T K = =
43/132
Acest rezultat este Ioarte apropiat de o regul euristic Ioarte des utilizat: 40 din
eIortul total este cheltuit pentru dezvoltarea eIectiv, n timp ce 60 este cheltuit pentru
ntre|inere. SpeciIicarea cerin|elor nu este inclus n model. Estimrile conIorm acestui model
nu se pot aplica dect ncepnd cu proiectarea si implementarea.
4.5 Distribuirea forei de munc n timp
Mai mul|i cercettori au criticat Iolosirea curbei Rayleigh pentru estimarea costului
(Pillai, 1997). Modelul lui Norden nu se bazeaz pe o teorie, ci mai mult pe observa|ii. Mai
mult, datele sale se reIer mai mult la proiecte hardware. Nu s-a demonstrat ns Iaptul c
proiectele soItware se comport la Iel. Acestea prezint uneori o acumulare rapid a Ior|ei de
munc care invalideaz modelul n Iazele incipiente ale proiectului.
Putnam a Iolosit observa|ii empirice legate de nivelele de productivitate pentru a deriva
ecua|ia soItware-ului din curba Rayleigh:
1 4
3 3
D kE t =
unde D este dimensiunea proiectului, E este eIortul total n ani-om, t este timpul scurs
pn la lansare n ani iar k este un Iactor tehnologic bazat pe 14 componente, precum:
- maturitatea general a proiectului si tehnicile de management;
- gradul de utilizare a tehnicilor de ingineria programrii;
- nivelul limbajelor de programare Iolosite;
- capacitatea si experien|a echipei de dezvoltare;
- complexitatea aplica|iei.
Puterea supraunitar a timpului are implica|ii puternice asupra alocrii resurselor n
proiecte mari. Prelungiri relativ mici ale datei de livrare pot determina reducerea substan|ial
a eIortului (Pressman, 1997).
Pentru estimarea eIortului, Putnam a introdus ecua|ia acumulrii Ior|ei de munc:
3
E
A
t
=
unde A este numit accelerarea Ior|ei de munc iar E si t au semniIica|iile de mai sus.
Accelerarea Ior|ei de munc este 12,3 pentru proiecte soItware noi, cu multe interIe|e si
interac|iuni cu alte sisteme, 15 pentru sisteme de sine stttoare si 27 pentru reimplementri
ale sistemelor existente.
Pe baza celor dou ecua|ii, putem elimina timpul si determina eIortul:
, )
9
4
7
7 D
E A
k
= .
Acest rezultat este interesant deoarece arat c eIortul este propor|ional cu dimensiunea
la puterea 9/ 7 1.286 ~ , valoare similar cu Iactorul lui Boehm, ntre 1,05 si 1,20.
Evident, scurtarea timpului de dezvoltare implic un numr mai mare de persoane
necesare pentru proiect. ReIerindu-ne la modelul curbei Rayleigh, scurtarea timpului de
dezvoltare conduce la mrirea valorii a, Iactorul de accelerare care determin panta ini|ial a
curbei. VrIul curbei Rayleigh se deplaseaz spre stnga si n acelasi timp n sus. AstIel
ob|inem o crestere a puterii necesare la nceputul proiectului si o Ior| de munc maxim mai
mare.
Exist si dezavantaje ale acestei deplasri. Mai multe studii au artat c productivitatea
individual scade odat cu cresterea echipei. ConIorm lui Brooks, exist dou cauze ale
acestui Ienomen:
- Dac o echip se mreste, va creste timpul acordat comunicrii cu ceilal|i
membri ai echipei (pentru consultare, sincronizarea sarcinilor etc.);
- Dac este adugat Ior| de munc suplimentar unei echipe n timpul
dezvoltrii unui proiect, mai nti scade productivitatea. Noii membri ai echipei
44/132
nu sunt productivi de la nceput, n acelasi timp ei necesit ajutor, deci timp, de
la ceilal|i membri ai echipei n timpul procesului de nv|are. Luate mpreun,
acestea conduc la scderea productivit|ii totale.
Combinnd aceste dou inIorma|ii, ajungem la Ienomenul cunoscut sub denumirea de
legea lui Brooks: adugarea de personal la un proiect ntrziat l va ntrzia si mai mult.
Analiznd o mare baz de date ale proiectelor, Conte a descoperit urmtoarea rela|ie
ntre productivitatea medie L (msurat n linii de cod pe lun-om) si mrimea medie a unei
echipe P:
0.5
777 L P

= .
Formula atest Iaptul c productivitatea individual scade exponen|ial cu mrimea
echipei. Numrul de legturi de comunicare ntre persoanele implicate ntr-un proiect este
determinat de mrimea si structura echipei. Dac ntr-o echip de mrime P Iiecare membru
trebuie s-si coordoneze activit|ile sale cu to|i ceilal|i din echip, numrul legturilor de
comunica|ie va Ii:
, ) 1
2
P P
. Dac Iiecare membru trebuie s comunice numai cu un singur
alt membru, acest numr va Ii: P-1. Mai pu|in comunicare dect aceasta nu este rezonabil,
deoarece ne-am conIrunta cu echipe independente. Numrul de legturi de comunica|ie
variaz de la aproximativ P la aproximativ
2
2
P
. ntr-o organizare ierarhic, aceasta conduce
la P

ci de comunica|ie, cu 1 2 < < .

Pentru un membru al echipei, numrul de legturi de comunica|ie variaz de la l la P -1.
Dac productivitatea individual maxim este L si Iiecare legtur de comunica|ie conduce la
o pierdere a productivit|ii /, atunci productivitatea medie va Ii:
, ) 1 L L l P

= ,
unde , 0,1 e este o msur a numrului de legturi de comunica|ie. Presupunem c
exist cel pu|in 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 mul|ime dat de valori pentru L, l si , pentru valori cresctoare ale lui P,
aceast Iunc|ie creste de la 0 la o valoare maxim si apoi scade din nou. Deci exist o mrime
optim a echipei
opt
P , care conduce la o productivitate maxim a echipei. Productivitatea
echipei pentru diIerite 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 comunica|ie (l 50). Cu interac|iune 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
45/132
4.6 Concluzii
n acest curs au Iost prezentate diIerite modele pentru estimarea eIortului necesar pentru
dezvoltarea unui proiect soItware, a Ior|ei de munc necesare si a timpului eIectiv de
dezvoltare. S-au descris si Iactorii care nu trebuie s contribuie la estimarea costului
proiectului. In Iinal, s-a prezentat o modalitate de estimare a distribu|iei Ior|ei de munc n
timp pentru gsirea optimului numrului de persoane implicate n proiect.
46/132
5 ReutiIizarea resurseIor software
'ntre timp, Dedal, stul de Creta si de lunga sa absen| de acas, sim|ea un dor nebun
de |ara sa, dar era blocat de mare. Apoi el spuse: ,Regele mi poate nchide calea pe uscat si
pe mare, dar, desigur, cerul este liber si noi pe acolo vom merge. Poate c Minos de|ine restul,
dar aerul nu i apar|ine ". Spunnd aceste cuvinte, Dedal si-a ndreptat aten|ia spre stiin|e nc
neexplorate si a sIidat legile naturii. A asezat un rnd de pene, ncepnd cu cele mai mici, apoi
crescndu-le dimensiunea, astIel nct marginea prea c se nclin n sus. In acelasi Iel naiul
cu care cnt ciobanii este construit din trestie, Iiecare pu|in mai lung dect cealalt. Apoi, a
Iixat penele la mijloc cu a|, iar la baz cu cear; dup ce le-a aranjat n acest Iel, le-a ndoit
pu|in, dndu-le o Iorm usor curb, asa cum arat aripile psrilor.
Publius Ovidius Naso: MetamorIoze, VIII, 183-194
5.1 Introducere
Dedal merit un loc n mitologia ingineriei programrii. Pe vremea regelui Minos,
soItware-ul nu exista si totusi existau problemele si no|iunile pe care le regsim n ingineria
programrii de astzi. Un exemplu l constituie construirea sistemelor complexe. Dedal de|ine
cu siguran| un record n acest domeniu. A reusit s administreze un proiect care poate Ii
comparat cu proiectele de dezvoltare soItware din ziua de astzi: construirea labirintului din
Knossos.
Dup o vreme, Dedal a dorit s prseasc insula Creta, asa cum Ovidius povesteste mai
sus. Totusi regele Minos nu a vrut s i dea drumul. Stim cum se termin povestea: Dedal
zboar din Creta mpreun cu Iiul su, Icar. n ciuda avertismentelor tatlui su, Icar zboar
din ce n ce mai sus, se aproprie prea mult de soare si ceara din aripi se topeste. Icar cade n
mare si se neac iar Dedal reuseste n schimb s ajung cu bine n Sicilia.
Construc|ia 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 soItware nu
prezint importan| aici. Ceea ce intereseaz n discu|ia de Ia| este aplicarea anumitor
principii n construc|ie:
- reutilizarea resurselor: Dedal a Iolosit pene adevrate;
- reutilizarea proiectrii: el a imitat aripi reale;
- interIa|area componentelor: n acea vreme, oamenii Ioloseau ceara pentru a lipi
diverse lucruri ntre ele; calitatea lipiciului are un impact enorm asupra triniciei
produsului Iinal. n urma aplicrii corecte si Ierme a acestor principii, a Iost
realizat cu succes un proiect ambi|ios (zborul lui Dedal pn n Italia),
ncercarea de a cuceri cerul cu o tehnologie insuIicient s-a terminat cu un
dezastru (prbusirea lui Icar n mare).
S Iacem acum un salt n istorie, la sIrsitul anilor '70. Criza soItware era deja acut de
mul|i ani. Cererea de noi aplica|ii depsea cu mult posibilit|ile Ior|ei de munc din domeniu.
DiIeren|a dintre cerere si oIert era n continuare n crestere. Reutilizarea soIt-ului este una
din cile explorate pentru a ob|ine o crestere semniIicativ n productivitatea soItware.
De ce s se scrie cod pentru niste calcule deja cunoscute? Reutilizarea componentelor
soItware de calitate nu duce oare la cresterea drastic a siguran|ei si productivit|ii? Totusi, nu
este chiar att de simplu. Utilizarea componentelor soItware existente necesit standardizarea
denumirilor si interIe|elor. Ideea de a lipi componente ntre ele nu este direct transIerabil n
domeniul programrii.
Punctul de vedere modern nu restric|ioneaz no|iunea de reutilizare a soIt-ului la
reutilizarea componentelor. Si inIorma|iile care privesc proiectarea pot Ii reutilizate, asa cum
pot Ii reutilizate si alte cunostin|e culese n timpul construc|iei unui proiect soItware.
47/132
Foarte apropiat de reutilizarea soItware este si Ilexibilitatea programelor, care trebuie
s Iie n continu adaptare la modiIicrile circumstan|elor, n implementarea urmtoarei
versiuni a unui sistem, am preIera, evident, s Iolosim ct mai mult din versiunea curent.
Aceasta este de asemenea considerat a Ii o Iorm de reutilizare a soIt-ului.
5.2 Reutilizarea produselor intermediare
Bibliotecile cu buc|i de cod gata de utilizat, asa cum sunt cele numerice sau calculele
statistice, sunt Iolosite de ceva timp si pe o arie destul de larg. Aceast Iorm de reutilizare
nu este n mod necesar potrivit altor domenii. n alte domenii ne putem descurca mai bine
reIolosind schelete de componente, componente ale cror detalii nu au Iost nc deIinite, ntr-
un mediu n care acelasi tip de soItware este implementat mereu, aceste schelete pot Ii
modelate ntr-o proiectare reutilizabil. O tehnic similar este aceea de a reutiliza arhitectura
unui sistem soItware, asa cum este ntlnit la construc|ia compilatoarelor, de exemplu. Prin
integrarea cunostin|elor despre domeniu n accesorii soItware, ajungem n domeniul
sistemelor de transIormri, al generatoarelor de aplica|ii si al limbajelor de genera|ia a patra.
O clasiIicare general a tehnologiilor de reutilizare presupune:
- tehnologii bazate pe compunere;
- tehnologii bazate pe generare.
ntr-o tehnologie bazat pe compunere, reutilizarea se Iace par|ial prin compunerea unui
nou sistem din componentele existente. Elementele cu care se construieste (engl. ,building
blocks") sunt Iragmente pasive ce sunt copiate dintr-o baz de componente existent. ntr-o
tehnologie bazat pe generare, este mult mai diIicil identiIicarea componentelor reutilizate.
Mai precis, cunostin|ele reutilizate se regsesc ntr-un program care genereaz un alt program,
ntr-o tehnologie bazat pe generare, tiparele reutilizabile reprezint un element activ Iolosit
pentru a genera sistemul |int. Exemple mai vechi ale acestor dou tehnologii sunt bibliotecile
de subrutine si, respectiv, generatoarele de aplica|ii. Cele mai multe sisteme reutilizate de|in
aspecte din ambele perspective.
5.2.1 BibIioteci i componente software
Dac avem de realizat un program care trebuie s Iac apel la Iunc|ii trigonometrice, n
mod normal nu ne gndim s ne construim propriile rutine de calcul al acestor Iunc|ii, n
general, acestea sunt deja implementate n majoritatea limbajelor de programare. Ne-am pune
problema reimplementrii lor doar n cazuri particulare, cnd perIorman|ele programului
depind n mod direct de precizia sau viteza calculelor.
Punnd ntrebarea de ce este asa de simpl reutilizarea Iunc|iilor matematice, ajungem
s gsim un numr mare de piedici ce sunt puse n Ia|a reutilizrii componentelor soItware n
alte domenii. Pentru reutilizarea cu usurin| a unor Iunc|ii, trebuie s avem:
- un domeniu bine cunoscut, cu o terminologie standardizat; ,cosinus" (sau
,cos") reprezint acelasi lucru pentru toat lumea;
- o interIa| bine precizat: avem nevoie de exact un numr pentru a calcula
Iunc|ia cosinus;
- un Iormat de date standardizat: un numr poate Ii reprezentat n virgul Iix, n
virgul mobil, n dubl precizie, si cam att.
Reutilizarea rutinelor Iunc|ioneaz cel mai bine ntr-un domeniu de aplica|ii bine
documentat, cu no|iuni clare si pentru care datele de intrare sunt ntr-un Iormat standardizat.
Istoria modern a reutilizrii soItware ncepe cu Mellroy, care a prevzut un viitor strlucit
pentru o tehnologie a unei componente soItware la ConIerin|a NATO de Ingineria
programrii din 1968. Din punctul su de vedere, ar trebui s Iie posibil asamblarea
sistemelor si componentelor mari dintr-un numr de blocuri gata de utilizat, asa cum sistemele
hardware sunt asamblate Iolosind componente standard.
48/132
Pentru ca reutilizarea componentelor soItware s Iie 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 stii s speciIici
ceea ce cau|i, exist o sans mic s gsesti acel lucru;
- nelegerea: Pentru a decide dac o anume component este utilizabil, este
nevoie de o n|elegere precis si suIicient de complet a ceea ce Iace respectiva
component;
- Adaptarea: Componenta selectat poate s nu se potriveasc Iix problemei. A
crpi codul nu reprezint o variant satisIctoare si, n orice caz, justiIicat
numai atunci cnd este proIund n|eleas;
- Compunerea: Un sistem este Iormat din mai multe componente cuplate. Se
pune problema: cum conectm componentele ntre ele?
Componentele hardware sunt de obicei clasiIicate ntr-o ierarhie multinivel. Avnd n
vedere c s-au standardizat deja conven|iile 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 si inIorma|ii de sincronizare, care descriu diIerite aspecte ale
componentelor.
S-au Icut unele eIorturi pentru a clasiIica componentele soItware 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 spa|iu si
timp.
structuri
monolitice siruri de caractere, stive, cozi
polilitice Liste, arbori, graIuri
instrumente utilit|i Iiltre
n ceea ce priveste ultimele dimensiuni, Booch deosebeste patru categorii:
- Concuren: obiectele si pot pstra sau nu semantica proprie atunci cnd exist
mai multe Iire 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 dispozi|ie opera|ii 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 Iost utilizate rela|iile structurale dintre elementele unor structuri
de date compuse. De exemplu, exist o rela|ie 1-1 ntre elementele unei structuri lineare, ca
lista sau coada.
structuri
0-0 mul|imi
1-1 Stive,cozi, liste
1-n Arbori
n-m graIuri
Acest Ienomen Iunc|ioneaz pentru ierarhii de componente n general. Dac nu se
cunoaste modul n care este organizat ierarhia, exist doar o mic sans s se gseasc
componenta cutat. Exemplele din tabelele de mai sus induc oarecum n eroare, deoarece
componentele de pe nodurile Irunz ale ierarhiei ncorporeaz abstractizri Ioarte cunoscute,
n alte domenii va Ii mai pu|in n|elegere reciproc n ceea ce priveste componentele
primitive si denumirea acestora. Prin urmare, construirea unei taxonomii utilizabile este de
obicei mai greu de realizat n alte domenii.
49/132
O alt observa|ie care se poate Iace privind reutilizarea componentelor priveste
granularitatea lor. Cu ct este mai mare o component, cu att va Ii 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 cresterea mrimii
componentei. Acest lucru este datorat Iaptului c, n general, componentele mai mari tind s
impun constrngeri mai multe mediului lor. Exist aici o analogie cu teorema Iundamental a
biologiei a lui Fisher: cu ct un organism este mai adaptat unui mediu dat, cu att este mai
pu|in pregtit pentru un alt mediu.
n domeniul clasiIicrii componentelor, o contribu|ie semniIicativ apar|ine lui Prieto-
Diaz. O bibliotec de componente bazate pe schema clasiIicrii sale ajut la localizarea
componentelor poten|ialelor utilizabile si la estimarea eIortului necesar pentru a adapta o
component, atunci cnd aceasta a Iost gsit.
Schema clasiIicrii lui Prieto-Diaz Ioloseste un numr de caracteristici, numite Ia|ete,
care descriu Iiecare component. De exemplu, componentele ntr-un mediu UNIX pot Ii
clasiIicate Iunc|ie de ac|iunea pe care o ncorporeaz, de obiectul pe care l manipuleaz sau
de structura de date Iolosit. ClasiIicarea unui obiect nseamn alegerea unei n-tuple care se
potriveste cel mai bine acelei componente.
ClasiIicarea bazat pe Ia|ete are anumite avantaje Ia| de clasiIicarea bazat pe
enumerare, asa cum este utilizat n exemplele din taxonomia lui Booch. Schemele strict
enumerative Iolosesc o ierarhie predeIinit si oblig la cutarea unui nod care se potriveste cel
mai bine componentei ce trebuie clasiIicat. Desi pot Ii Iolosite si reIerin|e ncrucisate cu alte
noduri, re|eaua rezultat devine destul de complicat.
De obicei este greu de gsit o component care s se potriveasc perIect cerin|elor
noastre. Dar asta nu nseamn c nu se poate gsi o component utilizabil. Sistemul lui
Prieto-Diaz oIer posibilitatea de a expanda ntrebrile deoarece ia n considerare si
componentele care sunt apropiate de cea cutat, pentru oricare din Ia|ete. Pentru a determina
apropierea de o component, se Iac msurri potrivite ale distan|ei dintre no|iunile care
compun Ia|etele.
O dat ce s-a gsit o mul|ime de componente candidate, acestea sunt ordonate de ctre
un sistem de evaluare dup criteriul considerat al potrivirii lor. n aIar de distan|a
conceptual, propriet|i ca lungimea (o estimare subiectiv), structura (numrul de module,
complexitatea) si documentarea (o estimare subiectiv) joac un rol n procesul de selec|ie.
Un proiect de cercetare construit pe baza rezultatelor ob|inute de Prieto-Diaz este
descris de Burton (1987). El si asocia|ii si au implementat un prototip de bibliotec de
soItware reutilizabil. n sistemul lor, descrierea Iiecrei componente soItware este
reprezentat de un numr de atribute, cum ar Ii lungimea componentei, complexitatea sa,
rezultatele testrii, erorile raportate, calitatea documenta|iei si readaptabilitatea. Dac trebuie
aleas una dintre componente, reutilizatorul poate indica interactiv relevan|a Iiecrui atribut.
Este ob|inut apoi o ordine a importan|ei, bazat pe indica|iile utilizatorului. Variind valorile
diIeritelor atribute, reutilizatorul poate avea o vedere de ansamblu a valorii relative a
componentelor eligibile.
Perspectiva lui Prieto-Diaz a Iost aplicat cu succes si n alte programe de reutilizare.
Aceste proiecte diIer considerabil n ceea ce priveste schemele lor de clasiIicare si de
recuperare si cantitatea de instrumente ajuttoare puse la dispozi|ie de mediu. Schemele de
clasiIicare variaz de la un simplu cuvnt cheie ntr-un context pn la recuperarea complet
automat a unui cuvnt cheie din documenta|ia existent; pot Ii de asemenea implicate pn si
cunostin|e elaborate din domeniul aplica|iei, n ceea ce priveste recuperarea, sistemele pot
ntrebuin|a tezaure extensibile pentru a lega termeni similari, sau pot oIeri posibilit|i de
navigare pentru a inspecta componente similare.
50/132
Experien|ele concrete arat ns c, din punct de vedere practic, bibliotecile de
componente utile nu con|in un numr mare de componente. De exemplu, Prieto si 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, clasiIicarea si 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 abIoane
n paragraIele precedente am presupus c bibliotecile de componente sunt buc|i de cod
gata de Iolosit. Aplicabilitatea unei componente poate Ii mrit prin omiterea speciIicrii
anumitor detalii. Sabloanele sunt componente neterminate. Prin instan|ierea lor, de exemplu
prin completarea unor detalii, rezult componente (re)utilizabile.
Un exemplu de posibil sablon este o procedur care implementeaz un algoritm de
sortare. Detalii ca limitele mul|imii de sortat, tipul elementelor mul|imii si operatorii
rela|ionali Iolosi|i pentru a compara elementele mul|imii nu prezint importan| pentru esen|a
algoritmului.
Aceasta se reduce n ultim instan| la separarea dintre Iunc|ionalitate si tipurile de date
Iolosite n implementare. Poten|iala reutilizare este puternic mrit dac biblioteca con|ine, pe
lng tipuri abstracte de date, si sabloane.
Cu ct sunt acceptate mai multe detalii, cu att se poate aplica un sablon mai general.
Totusi exist un pre| pentru toate acestea. Costul pltit pentru a ob|ine o aplica|ie complet
probabil va creste propor|ional cu numrul de goluri ce trebuie umplute.
Sabloanele nu trebuie constrnse numai la subrutine. Exist sabloane care pot Ii
instan|iate ntr-un program complet pentru un domeniu de aplica|ie Ioarte precis, n acest caz,
avem de-a Iace cu generatoare de aplica|ii.
5.2.3 ReutiIizarea proiectrii
Reutilizarea proiectrii se dovedeste proIitabil ntr-un mediu n care este dezvoltat
mereu si mereu acelasi tip de program. n multe medii de aIaceri aplica|iile sunt considerate n
mod gresit unice. Drept urmare, ele sunt proiectate si implementate pornind de la zero de
Iiecare dat. Lanergan si Grasso (1984) declarau c n programele comerciale scrise n
COBOL exist numai cteva opera|ii de baz diIerite, cum ar Ii sortarea, actualizarea si
raportarea.
Reutilizarea arhitecturii, adic modalitatea n care diverse pr|i a unui sistem se mbin,
este oarecum diIerit de reutilizarea componentelor soItware sau a sabloanelor. O bibliotec
de arhitecturi soItware nu este chiar asa de util. Pentru Iiecare problem n parte am putea
mai degrab s cutm o arhitectur speciIic. O arhitectur nepotrivit nu poate Ii niciodat
baza unui sistem bun. Situa|ia se modiIic oarecum dac o problem apare n mod repetat n
diIerite variante. Dac exist o arhitectur standard util pentru un anumit tip de problem,
aceasta poate Ii aplicat tuturor variantelor viitoare.
Un prim domeniu din stiin|a calculatoarelor n care se poate reutiliza arhitectura
soItware este construc|ia compilatoarelor. Marea majoritate a compilatoarelor sunt construite
cu aceleasi componente: parser, analizor lexical, analizor sintactic, tabel de simboluri,
generator de cod. Exist cteva tipuri bine deIinite de parsere, cum ar Ii parserele LL(1) sau
LALR(l). Exist o teorie ampl despre cum Iunc|ioneaz 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 Ir cusur si bine cunoscut de a ataca probleme ntr-un domeniu diIicil.
51/132
Un alt exemplu este domeniul mediilor de dezvoltare soItware, n care majoritatea
ntrebuin|eaz un depozit de inIorma|ii centrale nconjurat de un numr mic de straturi ce
con|ine instrumente ce devin din ce n ce mai speciIice ctre straturile exterioare.
Reutilizarea arhitecturii se regseste rareori si n alte domenii. Principalul motiv este c
un corp similar de cunostin|e partajate si cristalizate pur si simplu nu exist. Putem totusi
observa cum cteva tipuri de arhitecturi standard au Iost 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
Iiecare disciplin de inginerie trebuie depus o munc enorm si cstigat mult experien|
nainte de a realiza o astIel de standardizare.
5.2.4 Sisteme de transformare
Am men|ionat deja natura transIorma|ional a procesului de implementare soItware. O
speciIica|ie a cerin|elor descrie sistemul ce trebuie realizat ntr-o anume reprezentare, Iie c e
vorba de limbaj natural, limbaj Iormal sau pictural, n urma unor stadii intermediare, aceast
descriere este transIormat ntr-un produs Iinal, codiIicat ntr-un limbaj de programare
oarecare.
Dou tipuri de transIormri se repet n timpul acestui proces:
- rafinri: prin adugarea detaliilor si deciziilor de implementare se raIineaz
descrierea produsului.
- transformri lingvistice: n timpul anumitor pasi, descrierea produsului este
translatat dintr-un limbaj n altul.
Evident, ambele tipuri de transIormri pot Ii Icute manual, ceea ce deseori se si
ntmpl. Putem lua totusi n considerare posibilitatea asisten|ei computerizate n realizarea
acestor transIormri, adic, mai precis, un sistem automat care s Iac transIormri.
Cel mai simplu punct de pornire ne este pus la dispozi|ie de transIormrile lingvistice
ale clasei. O construc|ie de Iorma:
II Exists i in 1..N SuchThat A|i| x then ...
este Ioarte clar. Din pcate, aceast construc|ie nu exist n majoritatea limbajelor de
nivel nalt Iolosite n prezent. Prin urmare, la un moment dat, construc|ia IIExists va trebui
nlocuit cu o secven| de cod echivalent semantic.
Un sistem de transIormare pentru un domeniu de aplica|ie larg va necesita n general
ndrumare uman pentru realizarea raIinrii. De exemplu, dac o descriere de nivel nalt
aminteste de mul|imi de obiecte, aceasta se poate raIina printr-o reprezentare Iolosind liste sau
arbori binari, n general, programatorul este cel care va decide ce structuri de date se potrivesc
cel mai bine aplica|iei, dac sistemului de transIormare i lipsesc cunostin|ele pentru a realiza
automat acest lucru.
Cea mai diIicil sarcin a unui utilizator de sistem de transIormare este identiIicarea
unor nivele intermediare consistente, bine deIinite care trebuie Iolosite n procesul de
transIormare. Dac reusim s descompunem acest proces n niste pasi bine separa|i din punct
de vedere conceptual, atunci transIormrile devin realizabile.
O ntrebare interesant este dac putem Iormaliza toate construc|iile si construi un
compilator inteligent care s translateze o proiectare n cod executabil Ir interven|ie uman.
Acest lucru este ntr-adevr posibil dac restric|ionm domeniul de aplica|ie la unul Ioarte
ngust. Pentru a putea rescrie din toate punctele de vedere o proiectare, trebuie s se introduc
n sistem, ntr-un Iel sau altul, o cantitate suIicient de cunostin|e n domeniul aplica|iei.
AstIel de sisteme sunt generatoarele de aplica|ii.
52/132
5.2.5 Generatoare de apIica{ii i Iimbaje de a patra genera{ie
Generatoarele de aplica|ie scriu programe. Un generator de aplica|ie are un volum de
cunostin|e despre domeniul aplica|iei, care este de obicei destul de ngust. Pentru a ob|ine un
program este nevoie, evident, de o speciIica|ie a acestuia. De ndat ce speciIica|ia este
disponibil, programul este generat automat.
Principul Iolosit este acelasi pe care se bazeaz un sablon: programul eIectiv de generat
este deja construit n generatorul de aplica|ii. Instan|ierea unui program eIectiv este realizat
prin completarea unui numr de detalii. DiIeren|a Ia| de sablon este aceea c mrimea
codului livrat este mult mai mare la un generator de aplica|ii. De asemenea, detaliile sunt n
general Iurnizate la un nivel mai nalt de abstractizare, n ceea ce priveste conceptele si
no|iunile extrase din domeniul de aplica|ie.
Un generator de aplica|ii poate Ii ntrebuin|at n orice domeniu care are o astIel de
structur nct opera|iile complicate din cadrul domeniului s poat Ii automatizate n mare
msur. Un exemplu l reprezint generarea automat a rapoartelor din baze de date. Asa
numitele compilatoare de compilatoare reprezint un alt exemplu tipic de generator de
aplica|ii: avnd gramatica unui limbaj de programare (adic detaliile), rezult un parser pentru
acel limbaj.
Limbajele de a patra genera|ie sau limbajele de nivel Ioarte nalt (engl. VHLL, ,very
high level languages") sunt deseori men|ionate alturi de generatoarele de aplica|ii. Limbajele
de a patra genera|ie oIer construc|ii de programare la un nivel mai nalt dect limbajele de
programare de a treia genera|ie.
Expresiile dintr-un domeniu de aplica|ie dat pot Ii introduse direct n limbajul de a patra
genera|ie corespunztor. Prin urmare, limbajul de a patra genera|ie trebuie s aib cunostin|e
despre domeniul de aplica|ie respectiv. Aceasta nseamn c si limbajele de a patra genera|ie
sunt potrivite numai pentru un domeniu speciIic, limitat.
Nu exist nici o diIeren| Iundamental ntre limbajele de a patra genera|ie si
generatoarele de aplica|ie. Atunci cnd se doreste testarea capacit|ilor generative ale unui
sistem, se Ioloseste de obicei generatorul de aplica|ii. Termenul ,limbaj de a patra genera|ie"
eviden|iaz construc|iile de programare de nivel nalt ce sunt oIerite.
Generatoarele de aplica|ii si limbajele de a patra genera|ie oIer niste reduceri poten|iale
de cost, avnd n vedere c detaliile de implementare nu trebuie s |in cont de probleme ca:
nivelul de inteligibilitate al codului s Iie mare, cantitatea de cod scris s Iie mic, numrul de
erori s Iie mic, codul s Iie usor de ntre|inut.
n practic, utilizatorul poate dori ceva ce nu este oIerit 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 Iolosirii limbajelor de a patra genera|ie, si anume scrierea
de programe inteligibile la un nivel mai ridicat de abstractizare.
5.3 Reutilizarea instrumentelor i a tehnicilor
n acest paragraI vom descrie un numr de concepte, metode si tehnici care pot avea un
impact pozitiv asupra reutilizrii soItware, rediscutnd perspectivele din sec|iunile precedente.
5.3.1 Limbaje de interconectare a moduIeIor
Rela|ia dintre diIeritele module ale unui sistem pot Ii exprimate Iormal ntr-un Limbaj
de Interconectare a Modulelor (engl. MIL, ,module interconnection language"). MIL
reprezint un instrument important atunci cnd se proiecteaz si se ntre|in sisteme mari,
constituite din diverse module. O descriere MIL este o descriere Iormal a structurii Iormale a
unui sistem soItware, care poate Ii utilizat pentru a veriIica automat integritatea sistemului si
pentru a veriIica dac diversele module sunt conIorme cu interIe|ele aprobate.
53/132
Vom prezenta n continuare un mic Iragment dintr-un cod MIL pentru a ilustra aspectul
general a unui astIel de limbaj. Exemplul priveste structura unui compilator cu un singur pas.
Nota|ia Iolosit este INTERCOL (Tichy, 1979), n care descrierea const dintr-o secven| de
module si de Iamilii de sisteme urmate de un set de compozi|ii. Exemplul con|ine o singur
Iamilie de sisteme. Un membru al acestei Iamilii reprezint o versiune a unui sistem. De notat
c Iamilia de module scan are implementri multiple, cte una pentru Iiecare limbaj suportat.
Compozi|ia dat la sIrsitul descrierii selecteaz un numr de blocuri deIinite 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/
implementation SCAN03 .. PASCAL
end scan
.
module errormsg
provide procedura errormsg_proc
implementation ERRMSG
end errormsg
COMPOSTON
compile_A = [compile, SCAN02, PARSE.NP, SYMBL.PL/,
POSTFXGEN.NP, 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 propriet|ile dorite ale modulelor care vor deveni
parte component a sistemului considerat;
- VeriIicri ale tipurilor statice ntre diIerite module: Acest lucru garanteaz
automat c diIeritele module respect interIa|a. O interIa| poate Ii modiIicat
numai dup ce a Iost realizat respectiva modiIicare n proiectare;
- Proiectarea si 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 Iace automat;
- Controlul versiunilor: Pentru a evita conIuziile dintre versiunile (pr|ilor) unui
sistem n timpul implementrii si ntre|inerii, este nevoie de o abordare
organizat.
54/132
Conceptele de baz ale unui MIL sunt:
- resursele: tot ce are nume ntr-un limbaj de programare (constant, tip, variabil,
procedur) si tot ce poate Ii Icut disponibil de ctre un modul pentru un alt
modul;
- modulele: care Iac resursele disponibile sau care le utilizeaz;
- sistemele: grupuri de module care ndeplinesc mpreun o sarcin bine deIinit.
Pentru lumea exterioar, un sistem poate Ii vzut ca un singur modul.
Legtura dintre module poate Ii modelat ca un graI: nodurile graIului reprezint
module, n timp ce arcele (orientate) reprezint dependen|ele dintre module. Func|ie de gradul
de complexitate al MIL, acest graI poate Ii un arbore, un graI orientat aciclic sau un graI
orientat Ir nici o restric|ie.
Toate MIL arat aceleasi limitri: ele se implic numai n sintaxa interIe|elor. Nu se
poate aprecia dac resursele prelucrate au sens sau nu. Goguen (1986) a ncercat s Iac un
pas mai departe pentru a asigura unui MIL o semantic limitat. Sistemul lui se numeste
Limbaj de Interconectare a Bibliotecilor (engl. LIL, ,library interconnection language"). LIL
con|ine urmtoarele entit|i:
- pachete cu axiome asociate: aceste axiome spun ceva legat de opera|ia
pachetului. Axiomele pot Ii Iormale (ntr-o logic primar) si inIormale (limbaje
naturale);
- teorii: seamn cu pachetele, dar nu con|in deloc cod. Acestea arat numai c ar
trebui Iurnizate anumite tipuri si Iunc|ii si pun la dispozi|ie axiomele care
descriu comportarea acestor Iunc|ii;
- vizualizrile: arat cum este ndeplinit o anumit teorie.
Un exemplu ar putea clariIica aceast descriere. Fie SORT un pachet generic pentru
sortarea unei secven|e, nc nu am speciIicat tipul elementelor din secven|. Teoria
ORDEREDSET ne spune ce este aceea o ordonare, Iolosind urmtoarele axiome:
-
1 2
E E s (reIlexivitate);
-
1 2 2 3 1 3
, E E E E E E s s s (tranzitivitate);
-
1 2 2 1 1 2
, E E E E E E s s = (antisimetrie);
-
1 2
E E s sau
2 1
E E s (ordine complet).
Mul|imea numerelor naturale cu rela|ia de ordine ,~" satisIace aceste axiome. Dar
exist multe alte ordonri posibile (cum ar Ii: toate numerele pare care sunt mai mari dect
toate numele impare si att numerele pare ct si cele impare s Iie n ordinea Iireasc). Dac
dorim s sortm o secven| n ordine descresctoare, alegem o vizualizare care are ca
elemente ale ORDEREDSET numerele naturale si rela|ia ,~" ca rela|ie de ordine.
Construc|ia de mai sus a Iost numit de ctre Goguen compozi|ie orizontal.
Vizualizarea descrie o interIa| ntre dou componente aIlate la acelasi nivel de abstractizare.
O component caut o teorie, cealalt satisIace axiomele, pe cnd vizualizarea ne transmite
cum se potrivesc ele. Este de asemenea posibil si o compozi|ie vertical, n pachetul SORT
nu a Iost nc deIinit modalitatea n care trebuie implementat o secven|. De aceea, SORT
trebuie s Iie 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 nota|ie Iormal nu pot Ii
veriIicate automat. De aceea, Goguen propune un adevrat sistem de management, care ar
trebui s poat veriIica 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 lan|ul demonstra|iei.
Putem constata c MIL se potriveste bine cu sistemele de transIormare si alte Iorme de
reutilizare n care proiectarea joac un rol esen|ial. Atunci cnd se caut o component
55/132
potrivit ntr-o bibliotec de module, semantica acestora este mult mai important dect
sintaxa interIe|ei. LIL reprezint un prim pas n aceast direc|ie, deoarece legtura semantic
este una din cele mai importante probleme n demararea reutilizrii.
5.3.2 Programarea orientat obiect
Programarea orientat obiect a Iost una din cele mai rsuntoare sintagme ale anilor '80.
Care este poten|ialul limbajelor orientate obiect n ceea ce priveste reutilizarea soItware? Este
evident c bibliotecile de module devin mult mai utilizabile dac con|in 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 Ii mostenite dintr-o clas convenabil deja prezent n bibliotec iar caracteristicile
n plus pot Ii adugate unei subclase nou deIinite.
Mostenirea si polimorIismul unui limbaj orientat pe obiect asigur prin ele nsele
oportunit|i pentru construirea pr|ilor reutilizabile. Acestea promoveaz apari|ia unor clase
abstracte care pot servi ca punct de plecare pentru derivarea mai multor componente speciIice.
5.4 Perspectivele reutilizrii software
Dup cum spunea Johnson n 1988, ,abstractizrile utile sunt descoperite, nu inventate",
n orice tehnologie de reutilizare, blocurile reutilizabile, Iie c sunt sub Iorma unor subrutine,
sabloane, transIormri sau solu|ii ale problemelor cunoscute de proiectan|i, corespund
pieselor de cunoastere cristalizate, piese care pot Ii Iolosite n alte situa|ii dect cele pentru
care au Iost gndite ini|ial. O ntrebare central n toate tehnologiile de reutilizare discutate
mai sus este Ielul n care se poate exploata o mul|ime dat de blocuri reutilizabile. Aceasta are
o mare importan| n diversele proiecte din domeniul bibliotecilor de componente, unde
principalul scop este de a prevedea modalit|i de extragere a componentei utilizabile pentru
sarcina n lucru, n mod alternativ, putem privi reutilizarea soItware drept identiIicarea
blocurilor de care avem nevoie pentru a le putea Iolosi n diverse aplica|ii.
Atunci cnd se ncearc identiIicarea unor componente reIolosibile, principala problem
este de a se decide de ce componente avem nevoie. O component reIolosibil trebuie
valoriIicat, nu din motivul evident c ne scuteste de a implementa Iunc|ionalitatea noi nsine,
ci pentru c oIer o parte din cunostin|ele domeniului corect, adic exact Iunc|ionalitatea de
care avem nevoie, cstigat dup mult experien| si dup mai multe ncercri de a gsi
abstractizrile corecte. Componentele ar trebui s reIlecte no|iunile primitive ale domeniului
aplica|iei. Pentru a putea identiIica o mul|ime adecvat de primitive pentru un domeniu dat,
este necesar o experien| considerabil n implementarea unui soItware pentru acel domeniu.
Pe msur ce este cstigat aceast experien|, evolueaz ncet si mul|imea adecvat de
primitive.
Un domeniu este caracterizat printr-o colec|ie de no|iuni comune care au coeren|, n
timp ce n aIara domeniului, aceleasi no|iuni nu exist sau nu prezint aceeasi coeren|.
Domeniile pot Ii mai largi sau mai restrnse, de exemplu:
- program pentru contabilitate;
- program pentru contabilitate multina|ional;
- program pentru contabilitate multina|ional implementat de SoIt SRL.
Toate programele de contabilitate vor con|ine no|iuni ca ,registru" si ,balan|".
Programul pentru contabilitate multina|ional ca avea cteva no|iuni reIeritoare la Iluxul de
bani ntre diIerite |ri, no|iuni care nu exist n sistemele de contabilitate pentru aprozare sau
gogoserii. Reprezentrile no|iunilor n programul dezvoltat de SoIt SRL vor Ii diIerite de cele
ale altor Iirme din cauza Iolosirii diIeritelor metodologii sau conven|ii.
Pentru majoritatea domeniilor, nu este evident imediat care sunt primitivele corecte.
Este n ultim instan| o problem de ncercare si eroare. AstIel, ncet-ncet se gseste
56/132
mul|imea adecvat de primitive. Pe msur ce se dezvolt un domeniu, deosebim un numr de
etape:
- La nceput, nu exist nc un set clar de no|iuni si tot programul este scris de la
nceput. Experien|a se cstig ncet, pe msur ce se nva| din greselile
anterioare;
- n etapa a doua, probleme similare sunt depistate si rezolvate n moduri similare.
Sunt recunoscute primele primitive semantice. Dup ce se ncearc si se d gres,
se decide care sunt primitivele utile si 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 mul|ime de concepte, s-au gsit solu|ii
standard pentru o serie de probleme standard;
- n sIrsit, domeniul a Iost explorat n totalitate. Implementarea programelor
pentru domeniu poate Ii automatizat. Nu se mai programeaz eIectiv, ci se
Ioloseste o interIa| standard Iormat din primitivele semantice ale domeniului.
Majoritatea reutilizrii apare n ultima etap, desi 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" si compilatorul transIorm acesta ntr-un program ,adevrat".
Aceast ac|iune nu mai este privit ca reutilizare. Un Ienomen asemntor apare la tranzi|ia
dintr-un limbaj de a treia genera|ie ntr-un limbaj de a patra genera|ie.
Din punctul de vedere al reutilizrii, clasiIicarea de mai sus este una normal, natural
pentru evolu|ia unui domeniu. Diversele etape sunt categorizate la nivele calitative diIerite:
n prima etap nu exist reutilizare;
- n a doua etap reutilizarea este ad hoc;
- n a treia etap reutilizarea este structurat, componentele existente sunt
reIolosite ntr-un mod organizat atunci cnd se implementeaz un nou program;
- n etapa a patra, reutilizarea este institu|ionalizat si automatizat, eIortul uman
este restric|ionat la nivele superioare de abstractizare.
n cadrul unui domeniu dat este Iolosit un limbaj inIormai, n care acelasi lucru poate Ii
exprimat n mai multe moduri, Iolosind concepte care nu sunt bine deIinite. Totusi, limbajul
inIormai este usor de n|eles deoarece conceptele se reIer la un univers de expunere comun
att vorbitorului ct si asculttorului.
ntr-un limbaj Iormal, conceptele nu se reIer la experien|a sau cunostin|ele de zi cu zi.
Acestea au n|eles abia ntr-un sistem Iormal. Un astIel de sistem Iormal este o masin
virtual iar limbajul su este de asemenea un limbaj Iormal.
A Iormaliza un domeniu nseamn a construi un limbaj Iormal (pe domeniu) care
mimeaz un limbaj inIormai existent. Trebuie apoi s se aleag dintre diversele primitivele
semantice care exist inIormai. Uneori este convenabil s se adauge noi primitive, care se
potrivesc bine domeniului Iormalizat. De exemplu, s considerm domeniul setrilor de
tehnoredactare. O parte a Iormatrii documentelor se reIer la asamblarea cuvintelor n linii si
a liniilor n paragraIe. Secven|a de cuvinte care compune un paragraI trebuie mpr|it n linii
astIel nct rezultatul s Iie satisIctor din punct de vedere tipograIic.
Knuth (1981) descrie aceast problem Iolosind termenii ,cutii", ,lipici" si ,penalizri".
Cuvintele sunt cuprinse n cutii cu o anume l|ime. Spa|iul alb dintre cuvinte este considerat
lipici, care se poate mri sau micsora. Este preIerat un spa|iu conven|ional ntre cuvinte
adiacente, iar acestei asocieri i corespunde o penalizare nul. Apropierea sau deprtarea
cuvintelor atrage o penalizare pozitiv. Cu ct este mrit sau micsorat mai mult lipiciul, cu
att este mai mare penalizarea. Prin urmare, penalizarea asociat cu Iormatarea unui ntreg
paragraI este suma pedepselor asociate spa|iilor inter-cuvnt din paragraIul Iormatat.
Problema poate Ii reIormulat astIel: mparte paragraIul n linii astIel nct penalizarea total
s Iie minim. Trebuie men|ionat c penalizrile pot Ii asociate si altor propriet|i nedorite din
57/132
punct de vedere tipograIic, asa cum este despr|irea cuvintelor n silabe la sIrsitul unui rnd.
No|iunile ,cutii", ,lipici" si ,penalizri" oIer o Iormalizare elegant a anumitor aspecte ale
tehnoredactrii. De asemenea, oIer o solu|ie eIicient a problemei de mai sus, Iolosind o
tehnic a programrii dinamice.
n practic, Iormalizarea nu este o activitate cu un singur pas. Este mai degrab un
proces iterativ. Versiunea Iormalizat nu descrie tocmai exact limbajul inIormai, 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 Iolosesc limbajul (n domeniile
de nivel nalt) si cei care l implementeaz (n domeniile de nivel sczut). Odat ce limbajul
domeniului Iormal este hotrt, el aIecteaz si limbajul inIormai al domeniului. Persoanele
care lucreaz n cadrul domeniului ncep s Ioloseasc primitivele limbajului Iormal.
Este acum clar c nu este indicat trecerea direct de la etapa nti (Ir reutilizare) la
etapa a treia (reutilizare structurat). Formalizarea are un eIect de solidiIicare asupra
primitivelor semantice ale domeniului. No|iunile privind primitivele se modiIic, deoarece
acestea nu mai sunt considerate ca venind din universul de discurs intuitiv, ci din Iormalismul
care st la baza acestuia. Rspunsul la ntrebarea crucial dac am Iormalizat primitivele
semantice corecte devine mai greu de gsit. Etapa a doua (reutilizarea ad hoc) este Ioarte
important, n aceast etap avem o vedere de interior a domeniului de aplica|ie si descoperim
primitivele semantice utile. Att n ceea ce priveste lucrul cu primitivele, ct si implementarea
lor, se dovedeste c aceast experien| este de o importan| vital pentru Iormalizarea
domeniul n mod corect. 5. Aspecte non-tehnice ale reutilizrii soItware
Pn acum am discutat numai aspectele tehnice ale reutilizrii soItware. Ingineria
programrii nu este preocupat numai de aspectele tehnice, ci si de indivizi si de mediul n
care acestia si desIsoar activitatea. Domeniul ingineriei programrii este inIluen|at de
societate. Reutilizarea soItware n Europa este posibil diIerit de cea din Statele Unite sau
Japonia. Din cauza diIeren|elor culturale si a structurilor economice diIerite, nu este limpede
a-priori c abordarea Toshiba poate Ii copiat de europeni cu aceleasi rezultate.
Desi pn acum discu|ia noastr s-a reIerit la aspectele tehnice ale reIolosirii soItware,
acesta nu poate Ii ncheiat Ir cteva cuvinte despre problemele non-tehnice, care sunt intim
mpletite cu cele tehnice. Diversi cercettori ai reIolosirii soItware au discutat aprins c
tehnologia necesar reIolosirii soItware este disponibil, dar principalele probleme care inhib
o industrie prosper a reIolosirii sunt de natur non-tehnic. Programele reIolosibile cu succes
con|in urmtoarele caracteristice:
- Management auxiliar necondi|ionat si extensibil: Un program reIolosibil
necesit schimbri pe msur ce este implementat. Implicarea managementului
este esen|ial pentru a Iace modiIicrile s Iunc|ioneze, n particular, construirea
unei baze de articole reutilizabile necesit o investi|ie n avans care s-ar putea s
nu Iie recuperabil dect dup un timp;
- Stabilirea unei structuri organizatorice auxiliare: Organiza|ia trebuie s Iurnizeze
ini|iativa, Iondurile si politicile pentru programul reutilizabil. Este necesar un
corp separat pentru a evalua poten|ialii candida|i pentru includerea ntr-o
bibliotec reutlizabil. Este necesar un bibliotecar pentru ntre|inerea bibliotecii;
- Implementarea incremental a programului: Un prim catalog cu articole
poten|ial reutilizabile poate Ii construit cu un cost relativ mic. Experien|e
pozitive cu o astIel de bibliotec ini|ial vor Iurniza stimulentele materiale
necesare pentru a mri biblioteca, a inventa o schem de clasiIicare etc.;
- Succese semniIicative, att pe plan Iinanciar ct si organizatoric: De exemplu, o
crestere cu 50 a productivit|ii pe o perioad de c|iva ani;
58/132
- Programatorii suIer de sindromul ,neinventat aici": Prin crearea unui mediu
care valoriIic att crearea de soItware reutilizabil ct si reutilizarea soItware, se
stabileste o atmosIer n care reutilizarea poate deveni un succes;
- Analiza domeniului este un proces n care conceptele si mecanismele pe care se
bazeaz un domeniu bine n|eles sunt identiIicate si transIormate n resursele
reutilizabile.
5.5 Economia reutilizrii software
5.5.1 Economia refoIosirii software
,Reutilizarea este o investi|ie pe termen lung." (Tracz, 1990) Reutilizarea nu este
gratuit, ntr-un mediu tradi|ional de dezvoltare, produsele sunt realizate n Iunc|ie de situa|ie.
Este probabil ca situa|ii similare s necesite produse si componente pu|in diIerite. Pentru ca o
component soItware s devin reIolosibil, trebuie s Iie generalizat pornind de la situa|ia
prezent, testat si documentat intens, ncorporat ntr-o bibliotec si o schem de clasiIicare
si pstrat ca o entitate separat. Aceste opera|ii necesit investi|ii ini|iale, care ncep s Iie
recuperabile abia dup o anumit perioad de timp.
Recuperri imediate ale investi|iei pot Ii ob|inute dac programul reIolosit este mic la
nceput si are o bibliotec ini|ial ai crei membri sunt extrasi din produsele existente.
Dezvoltarea programului poate Ii apoi justiIicat pe baza experien|elor pozitive anterioare.
Dar chiar si atunci trebuie alocate Ionduri care nu sunt speciIice proiectului.
Consecin|ele economice ale reutilizrii soItware depsesc economiile costurilor n
produc|ie si ntre|inere. Se modiIic nssi natura procesului de dezvoltare soItware.
Programul devine un capital. Costurile ini|iale mari sunt legate de recuperri pe perioade mai
mari de timp.
5.5.2 ReutiIizarea software i managementuI
Produc|ia de soItware trebuie s Iie organizat astIel nct s Iie promovat reutilizarea.
Modelul tradi|ional cascad tinde s mpiedice reutilizarea. n modelul cascad, accentul cade
pe msurarea si 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 (si uneori singurul) scop este de a termina
proiectul curent la timp si ncadrat n buget. Nu exist nici o motivare n a Iace urmtorul
proiect s arate bine. n consecin|, reutilizarea soItware tinde s capete o prioritate mic.
Reutilizarea soItware trebuie s Iie ncorporat n procesul de dezvoltare. Articolele
reutilizabile trebuie cutate n mod activ.
Chiar si bibliotecile de articole reutilizabile trebuie administrate. AstIel, trebuie creat o
inIrastructur organiza|ional care Iace accesibil biblioteca (documentare, scheme de
clasiIicare), evalueaz candida|ii pentru includerea n bibliotec, men|ine si actualizeaz
biblioteca etc. Un rol organiza|ional separat, bibliotecarul, poate Ii 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. Proiectan|ii exper|i valoreaz
greutatea lor n aur. Orice programator mediu este capabil s scrie un program mare,
complicat. Pentru a ob|ine o solu|ie radical nou, mai bun, mai mic, mai elegant pentru
aceeasi 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 aprecia|i dect
programatorii sau proiectan|ii. Dac esti bun cu adevrat, mai devreme sau mai trziu (dar de
obicei mai devreme), te vei ridica pe scara ierarhic si vei ajunge s Iaci parte administra|ie.
Dup Brooks, exist un singur mod de a neutraliza acest Ienomen. Pentru a ne asigura c
acesti oameni sclipitori rmn proiectan|i de sistem, avem nevoie de o schem de personal
59/132
dual, n care proiectan|ii buni au aceleasi perspective n ceea ce priveste slujba ca si
administratorii buni.
5.5.3 Aspecte psihoIogice aIe reutiIizrii software
,Reutilizarea codului altor persoane ar demonstra c mie nu mi pas de munca mea. Nu
voi mai reutiliza cod, asa cum nici Hemingway nu Ioloseste paragraIele altor scriitori." (Cox,
1990)
Reutilizarea nseamn c programatorii trebuie s se adapteze, s ncorporeze sau s
,rentinereasc" codul scris de al|i programatori. Exist dou aspecte importante ale acestui
proces:
- sunt programatorii dispusi s Iac acest lucru?
- sunt capabili s Iac acest lucru?
Diverse cercetri arat c programatorii Iolosesc anumite scheme standard n anumite
situa|ii standard. Programatorii experimenta|i tind s devin conIuzi atunci cnd o problem
cunoscut a Iost rezolvat Iolosind solu|ii ne-standard. Drept consecin|, gradul de reutilizare
a componentelor este mrit dac aceste componente con|in abstractizri Iamiliare
programatorilor. Aceleasi probleme apar n analiza de domeniu, n care se ncearc
identiIicarea no|iunilor Iamiliare exper|ilor ntr-un anumit domeniu.
n alte studii apare ideea c un eIect secundar al Iolosirii proiectrilor standard si a
componentelor standard este n|elegerea crescut a programului rezultat. De ndat ce to|i
programatorii se obisnuiesc cu un anumit stil, toate programele par a Ii scrise de aceeasi
echip. Orice echip poate n|elege si adapta un program scris de oricare alt echip.
5.6 Concluzii
Reutilizarea soItware este mai degrab un obiectiv dect un domeniu. A aprut ca o
problem n cadrul ingineriei programrii, nu din cauza Iascina|iei sale ca problem stiin|iIic,
ci datorit cstigul scontat n productivitatea dezvoltrii soItware. Prima conIerin| despre
reutilizarea soItware a avut loc n 1983. De atunci, acest subiect a primit o aten|ie din ce n ce
mai mare. n acest curs am discutat principalele perspective ale problemei reutilizrii.
Diversele tehnologii de reutilizare discutate pot Ii divizate n dou mari categorii tehnologii
bazate pe compunere si tehnologii bazate pe generare, n primul caz, se urmreste
ncorporarea componentelor existente n noul program ce va Ii implementat, ntr-o tehnologie
bazat pe generare, este mult mai diIicil s se identiIice explicit componentele care se
reutilizeaz. Cunostin|ele reutilizate pot Ii gsite n programe care genereaz alte programe.
Au Iost descrise n continuare caracteristicile limbajelor de interconectare a modulelor. S-au
men|ionat perspectivele reutilizrii soItware si n Iinal s-a insistat si asupra aspectelor non-
tehnice ale reutilizrii: economia, managementul si psihologia reutilizrii.
60/132
6 Ingineria cerin{eIor. AnaIiza orientat obiect
6.1 Ingineria cerinelor
Primul pas logic n dezvoltarea unui program este stabilirea precis a cerin|elor
clientului (ceea ce vrea clientul s Iac programul). Partea cea mai important a acestui proces
o reprezint comunicarea dintre client si echipa de dezvoltare. Cnd un inginer de programe
lucreaz la stabilirea cerin|elor, el este numit inginer de cerin|e, analist de sistem sau analist.
Dezvoltarea unui program ncepe de obicei cu o idee a clientului despre un nou sistem sau
pentru mbunt|irea unui sistem existent. Clientul angajeaz un analist cu care va lucra
mpreun pentru speciIicarea mai exact a cerin|elor. Ideea ini|ial a clientului poate Ii vag si
prost deIinit, sau dimpotriv, poate Ii clar si bine deIinit.
Stabilirea cerin|elor este probabil cea mai important activitate n dezvoltarea
produselor program. Dac un client nu stie sau nu poate s stabileasc n urma unei discu|ii cu
echipa de dezvoltare n mod exact ce vrea s Iac 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 Iolosite, dar dac nimeni nu va dori s-1 Ioloseasc,
proiectul va Ii un esec.
Multe programe nu se potrivesc cu cerin|ele clientului nu din motive de implementare
deIectuoas, ci din cauz c cerin|ele nu au Iost speciIicate corect de la nceput. Persoane ale
cror legturi cu ingineria programrii sunt mai mult pretinse dect obiective consider c
nepotrivirea dintre asteptrile clientului si programul ob|inut |in de lipsa de cultur, sim|
artistic si cunostin|e tehnice ale programatorilor. Adevrul este c programatorii nu pot si nu
au cum s cunoasc necesit|ile clien|ilor, mai ales dac nu cunosc domeniul pentru care este
scris o anumit aplica|ie.
Este responsabilitatea clientului de a veni cu cereri exacte si pertinente. Este obliga|ia
inginerului de cerin|e s discute cu clientul pentru a clariIica cerin|ele si a-1 ajuta s-si Iixeze
priorit|ile. Stabilirea precis a cerin|elor este primul pas n ob|inerea unui program care
satisIace nevoile clientului. O speciIica|ie bun este Iolosit si n Iazele de validare si
veriIicare.
6.1.1 Cerin{a
No|iunea de cerin| este mai veche dect dezvoltarea programelor. De exemplu, o
cerin| pentru o locomotiv ar putea arta astIel: pe o cale Ierat uscat, locomotiva trebuie s
Iie capabil s porneasc un tren de 100 tone pe o pant de maxim 5 cu o accelera|ie de cel
pu|in 0,5 m/s2. De remarcat c aceast cerin| spune ce vrea clientul. Nu spune nimic despre
cum ar putea Ii realizat. Nu se speciIic tipul motorului (cu aburi, diesel, electric) sau
materialul din care s se conIec|ioneze ro|ile.
Apare aici o problem controversat: este bine s Iacem speciIicarea lund n
considerare Ielul n care sistemul va Ii implementat? Fiecare variant are avantajele si
dezavantajele ei:
- Nu Iolosim detalii de implementare: Nu ne asteptm ca un client s stie lucruri
speciIice dezvoltrii programelor, si deci nu poate s Iie de acord n cunostin|
de cauz cu stipulrile din speciIica|ii. Secretarele care Iolosesc Excel stiu
COM? E necesar s Iacem constrngeri asupra programului nc din Iaza de
concepere?
- Folosim detalii de implementare: Cteodat nu este posibil s ignorm o
implementare existent. Dac Iacem un program pentru o bibliotec, studiem
implementarea existent (tipul Iiselor ce trebuie completate, Iluxul de lucru,
61/132
modul de organizare al mediilor de stocare a inIorma|iilor) si o ,copiem" n
program. Putem veriIica dac o cerin| este sau nu rezonabil din punct de
vedere tehnic. Pentru a putea estima timpul de dezvoltare si pre|ul, trebuie luat
n considerare implementarea. Exist o diIeren| ntre a programa n Visual
Basic si a programa n Visual C. Costurile ini|iale la programarea n Visual
Basic vor Ii mai mici (timp de dezvoltare mai mic, programatori mai ieItini),
ns odat ce produsul necesit dezvoltarea peste o anumit limit a
complexit|ii, costurile vor creste (ntre|inere greoaie, probleme de
perIorman|).
6.1.2 Extragerea cerin{eIor
Presupunem c analistul si clientul lucreaz mpreun, Iiecare ncercnd s l n|eleag
pe cellalt. Esen|a procesului de ob|inere a cerin|elor este comunicarea. Se disting trei
activit|i majore care conduc la ob|inerea unei speciIicri a cerin|elor:
- Ascultare: analistul nregistreaz cerin|ele clientului;
- Gndire: analistul ncearc s traduc cerin|ele clientului n limbaj tehnic si s se
asigure de pertinen|a cerin|elor n acest context;
- Scriere: analistul si clientul cad de acord asupra unor Iormulri ale cerin|elor pe
care analistul le consider pertinente.
Aceste activit|i sunt parte a unui proces iterativ, lung si complicat. Negocierea este
Ioarte important. DiIeren|a cultural dintre client si analist este cteodat Ioarte mare. Exist
situa|ii cnd exist diIeren|e semniIicative ntre asteptrile utilizatorilor Iinali si ale clientului.
Un exemplu concret al acestui tip de conIlict este cnd un patron ce comand un program care
s Iie utilizat de ctre angaja|ii si doreste ca acesta s con|in module de monitorizare a
muncii angaja|ilor. Aceasta ridic o dilem de natur etic pentru inginerul programator: s
anun|e angaja|ii c sunt spiona|i Ir s stie sau s Iie loial celui care l plteste. O alt
problem o reprezint literatura SF studiat de client, nainte de angajarea echipei de
dezvoltare. Clientul asteapt mult prea mult de la program si de la echipa de dezvoltare,
nchipuindu-si c programele se scriu ca n Iilme, ntr-o scen de dou minute, ca un amnunt
dintr-un Iilm de dou ore. n concluzie, analistul trebuie:
- s extrag si s clariIice cerin|ele clientului;
- s ajute la rezolvarea diIeren|elor de opinie ntre clien|i si utilizatori;
- s sItuiasc clientul despre ce este tehnic posibil sau imposibil;
- s documenteze cerin|ele;
- s negocieze si s ob|in o n|elegere cu clientul.
6.1.3 Metode pentru identificarea cerin{eIor utiIizatoriIor
Una sau mai multe din urmtoarele modele prezentate mai jos pot Ii Iolosite pentru a
identiIica cerin|ele utilizatorului:
- Interviuri: Interviurile trebuie astIel structurate nct s poat aborda toate
aspectele implicate de sistemul soItware ce va trebui dezvoltat. Cnd exist
Ioarte mul|i utilizatori, se va selecta un set reprezentativ dintre acestia pentru a Ii
intervieva|i. Interviurile pot Ii utile n a asigura:
o completitudinea cerin|elor utilizatorului;
o existen|a unei acceptri generale a cerin|elor utilizatorului;
- Studiul sistemelor soItware existente deja: De multe ori, noul sistem soItware
este destinat nlocuirii altui sistem existent. Investigarea caracteristicilor si bune
si rele ale sistemului existent poate ajuta n determinarea cerin|elor pentru ceea
62/132
ce se doreste. Examinarea manualelor utilizatorilor, a documentelor cerin|elor si
a diverselor propuneri poate Ii Ioarte Iolositoare;
- Studiul de fezabilitate: Studiul de Iezabilitate reprezint analiza si 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 cerin|ele sunt neclare sau incomplete, ar putea Ii util
dezvoltarea unui prototip, bazat pe un set de cerin|e de prob, pentru a identiIica
cerin|ele reale ale utilizatorilor.
6.1.4 Metode pentru specificarea cerin{eIor utiIizatoriIor
6.1.4.1 Limbajul natural
Modul evident de speciIicare a unei cerin|e este limbajul natural. Limbajul natural este
Ioarte accesibil dar inconsistent si ambiguu. De exemplu, aIirma|ia: Baza de date va con|ine o
adres poate Ii interpretat dup cum urmeaz:
- Va Ii doar o singur adres
- parte din baza de date va Ii desemnat ca o adres.
- Va Ii cel pu|in o adres n baza de date.
6.1.4.2 Formalisme matematice
Formule matematice pot Ii Iolosite pentru a clariIica o cerin|. Toate simbolurile
Iolosite ntr-o expresie trebuie deIinite sau reIerite.
6.1.4.3 Engleza structurat
Engleza structurat este un limbaj de speciIicare care Ioloseste un vocabular si o sintax
Ioarte limitate.
Vocabularul const doar din:
- verbe imperative ale limbii engleze;
- termeni deIini|i ntr-un glosar;
- cuvinte rezervate.
Sintaxa e limitat la urmtoarele posibilit|i:
- simple construc|ii declarative;
- construc|ii decizionale;
- construc|ii repetitive.
Engleza structurat este Iolosit de obicei pentru a descrie procesele de baz ale
sistemului.
Exemple:
- construc|ii declarative
GET RAW DATA
REMOVE INSTRUMENT EFFECTS
CALIBRATE CORRECTED DATA
- construc|ii decizionale
IF SAMPLE IS OF NOMINAL QUALITY THEN
CALIBRATE SAMPLE
ELSE
STORE BAD SAMPLE
- construc|ii repetitive
FOR EACH SAMPLE
63/132
GET POINTING DIRECTION
AT TIME OF SAMPLE STORE POINTING DIRECTION WITH SAMPLE
Formaliznd engleza structurat se poate automatiza prelucrarea cerin|elor (veriIicarea
automat, o analiz automat, transIormri si aIisri) si se poate simpliIica deIinirea testelor
pentru Iaza de veriIicare si validare a sistemelor.
6.1.4.4 Tabele
Tabelele reprezint o metod de descriere concis si complet a cerin|elor. Aceast
metod poate rezuma anumite rela|ii, interac|iuni ntre cerin|e mai eIicient dect o prezentare
textual.
6.1.4.5 Diagrame bloc ale sistemului
Diagramele bloc reprezint modul tradi|ional 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 DocumentuI cerin{eIor utiIizatoruIui (DCU)
Acesta este documentul obligatoriu, produs n Iaza deIinirii cerin|elor si trebuie s Iie
Iinalizat nainte de proiectarea sistemului. DCU trebuie:
- s Iurnizeze o descriere general ceea ce utilizatorul doreste s execute sistemul;
- s con|in toate cerin|ele cunoscute, ale utilizatorilor;
- s descrie toate opera|iile pe care le va executa sistemul;
- s descrie toate constrngerile impuse sistemului;
- s deIineasc toate interIe|ele externe sistemului sau s con|in reIerin|e despre
ele n alte documente.
Costul modiIicrii cerin|elor creste cu att mai mult cu ct proiectul nainteaz n Iazele
urmtoare. In Iaza de testare a sistemului, veriIicarea se va Iace pe baza DCU. Standardele
ingineriei programrii recomand urmtoarele caracteristici ale stilului de prezentare a unui
DCU:
- DCU trebuie scris Iolosind un limbaj, vocabular si stil usor de n|eles de ctre
to|i utilizatorii. DCU trebuie s Iie clar, consistent, modiIicabil;
- Un DCU este clar dac orice cerin| este neambigu (are o singur interpretare)
si este n|eleas de to|i participan|ii la proiect;
- O cerin| trebuie scris ntr-o singur propozi|ie iar justiIicrile trebuie separate
de aceasta. Se recomand ca cerin|ele corelate ntre ele s Iie grupate.
Structurarea cerin|elor n document este Ioarte important;
- Un DCU este consistent dac nu exist conIlicte ntre cerin|e. Folosirea mai
multor termeni pentru a speciIica acelasi lucru este un exemplu de inconsisten|;
- Un DCU este modiIicabil dac orice modiIicare a cerin|elor poate Ii
documentat usor, complet si consistent.
6.1.5.1 Evoluia DCU
ModiIicrile inevitabile ale DCU sunt responsabilitatea utilizatorului. E necesar
pstrarea unei istorii a modiIicrilor eIectuate. Problema actualizrii ntregii documenta|ii va
Ii rezolvat cnd va Ii stabilit o arhitectur electronic standard pentru documente. Dac
schimbrile cerin|elor sunt rezolvate direct n Iaza de implementare, Ir a mai Ii prinse n
documenta|ie, aceasta poate provoca serioase probleme n Iaza de ntre|inere a sistemului.
Ini|iatorul proiectului ar trebui s monitorizeze tendin|a n apari|ia unor noi cerin|e ale
utilizatorului. O tendin| cresctoare va periclita succesul proiectului.
64/132
6.1.5.2 Responsabiliti
Se pun n eviden| urmtoarele recomandri:
- deIinirea clar tuturor responsabilit|ilor nainte de nceperea DCU;
- utilizatorii reali ai sistemului sunt responsabili pentru determinarea cerin|elor de
capabilitate;
- inginerii soItware trebuie s ia parte la Iormarea DCU pentru a-i ajuta pe
utilizatori;
- indiIerent de organizare, utilizatorii nu trebuie s dicteze solu|ii iar echipa de
dezvoltare nu trebuie s dicteze cerin|e.
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. Cerin|e speciIice
Sec|iunea l trebuie s descrie pe scurt scopul sistemului soItware, listele de deIini|ii
pentru termeni utiliza|i n document, lista de reIerin|e bibliograIice identiIicate prin autor, titlu
si date, si o trecere n revist a restului documentului.
Sec|iunea 2 se reIer la:
- capabilit|ile generale ale sistemului si de ce sunt ele necesare;
- constrngerile generale si motivul pentru care au Iost impuse;
- caracteristicile generale ale utilizatorilor sistemului (nivelul educa|iei lor,
limbajul, experien|a lor tehnic pot impune importante constrngeri asupra
soItware-ului) din Iazele de operare si ntre|inere ale sistemului. Este important
clasiIicarea acestor utilizatori si estimarea numrului lor, n Iiecare categorie;
- mediul extern n care sistemul va opera, prin diagrame de context pentru a
eviden|ia interIe|ele externe si prin diagrame bloc pentru a eviden|ia activit|ile
din ntregul sistem;
- situa|iile de risc eviden|iate n urma analizei riscurilor.
Sec|iunea 3 este partea principal a DCU, prezentnd toate cerin|ele de capabilitate si
cerin|ele restrictive ale sistemului. Validitatea sistemului soItware se va Iace pe baza acestor
cerin|e. Se recomand urmtoarele caracteristici:
- Fiecare cerin| trebuie unic identiIicat;
- Fiecare cerin| trebuie marcat Iunc|ie de importan|a sa (unele pot Ii extrem de
importante, altele inacceptabile, altele suspendate pn la ob|inerea unor resurse
necesare, altele sunt prioritare, instabile);
- Fiecare cerin| trebuie s Iie veriIicabil. O aIirma|ie trebuie s con|in o
singur cerin|. O cerin| e veriIicabil dac exist o metod ce demonstreaz
obiectiv c ea este asigurat de sistem. (AIirma|ii ca: ,interIa|a utilizator va Ii
prietenoas", ,sistemul va merge bine", nu sunt veriIicabile deoarece termenii
,bine", ,prietenos" nu au interpretri obiective). Dac nu exist o metod pentru
veriIicarea acestei cerin|e, 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 soItware continu s se
conIrunte cu probleme ca slaba productivitate si calitate a produselor soItware, companiile de
soItware din ntreaga lume caut mereu noi solu|ii, sub Iorm de utilitare, metode, tehnici.
65/132
Tehnicile structurate au Iost considerate solu|ia salvatoare a anilor 1970-1980. Apoi s-a
sugerat c orientarea obiect ar Ii o astIel de solu|ie. Fiecare nou paradigm a Iost adoptat cu
un oarecare Ianatism. Totusi, n 1988, ntr-un eseu intitulat No Silver Bullet, Brooks
argumenta c nu exist nici o solu|ie magic pentru diIicilele probleme Iundamentale ale
dezvoltrii sistemelor soItware. Nu exist nici un panaceu, nici un miracol care s creasc
productivitatea si n acelasi timp s elimine toate erorile sistemului. Deci, nu e cazul s ne
Iacem iluzii c tehnicile OO ar putea Ii cheia tuturor problemelor. Nu exist nici o garan|ie c
ea ar putea preveni dezastrul unui sistem soItware.
Un analist Ir experien|, intervievnd comunitatea utilizatorilor, ar putea s nu
descopere obiectele relevante din sistem. Un utilizator recalcitrant sau necooperant ar putea s
nu Iurnizeze anumite inIorma|ii, servicii, atribute ale sistemului. Si, binen|eles, orice proiect
poate suIeri, indiIerent de utilitarele si metodele Iolosite, din cauza modului de coordonare a
proiectului, sau a incompeten|ei personalului.
Obiectul reprezint o ncapsulare a valorilor unor atribute si a serviciilor lor exclusive.
O clas descrie un set de obiecte cu atribute si servicii comune. Un obiect este o instan| a
unei clase si crearea unui obiect se numeste instan|iere. Clasa poate Ii descompus n
subclase. Subclasele au n comun atributele caracteristice unei Iamilii de clase, mostenind
opera|iile si atributele claselor-prin|i.
Ini|iatorii acestei metode argumenteaz c modul de a privi un sistem din perspectiva
obiectelor este mult mai natural dect analiza sistemelor din punct de vedere Iunc|ional.
SpeciIica|iile bazate pe obiecte sunt mai adaptabile dect cele bazate pe Iunc|ii.
Cele mai importante si recunoscute metode AOO sunt:
- Coad-Yourdon;
- Rumbaugh-Object Modelling Technique (OMT);
- Shlaer-Mellor;
- Booch (cr|ile lui Booch privind metodele OO au Iost prezentate de Stroustrup,
inventatorul limbajului C, ca Iiind singurele care merit s Iie studiate n acest
domeniu datorit practicilor aproIundate de analiz si proiectare expuse n
lucrrile sale. Din pcate ns, nota|iile utilizate de Booch sunt complicate si
exist prea pu|ine utilitare care s suporte aceast metod.)
n momentul de Ia|, analiza orientat obiect evolueaz iar analistii, de obicei, combin
tehnicile diIeritelor metode n Iaza de analiz a problemei.
Ecua|ia utilizat pentru a recunoaste o metod OO este:
OO clase si obiecte mostenire comunicare prin mesaje
In acest Iel se poate spune dac un limbaj sau un mediu este sau nu OO. Analiza
orientat obiect nu se utilizeaz pentru sisteme care au Ioarte pu|ine Iunc|ionalit|i sau pentru
sisteme cu 1-2 clase si obiecte.
6.2.1 PrincipiiIe anaIizei orientate obiect
Principiile utilizate de AOO se bazeaz n primul rnd pe trsturile esen|iale ale
programrii orientate obiect:
- Abstractizare (procedural si de date);
- Mostenire. Pe lng acestea, alte principii importante sunt:
- Comunicarea prin mesaj e;
- Utilizarea metodelor de organizare:
- obiecte si atribute;
- obiecte si pr|ile sale; o clase si membrii.
66/132
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. Asadar, abstractizarea este un mecanism care permite reprezentarea unei
situa|ii complexe a lumii reale printr-un model simpliIicat. De exemplu, abstractizarea unei
culori din lumea real poate Ii realizat prin modelul RGB (red, green, blue).
Abstractizarea procedural este principiul conIorm cruia orice opera|ie poate Ii tratat
ca o singur entitate n ciuda Iaptului c ea presupune realizarea mai multor opera|ii de pe
nivelul urmtor de detaliu. Aceast Iorm de abstractizare joac un rol Ioarte important n
deIinirea serviciilor sistemului.
Abstractizarea datelor reprezint un mecanism mai puternic de abstractizare conIorm
cruia tipurile de date sunt deIinite n termenii opera|iilor ce se aplic obiectelor de acel tip,
cu restric|ia c valorile acelor obiecte pot Ii observate si modiIicate doar prin intermediul
opera|iilor men|ionate.
Prin aplicarea acestui principiu, un analist deIineste atributele si serviciile care
manipuleaz aceste atribute. Singurul mod de a accesa un atribut este prin intermediul
serviciilor. Atributele si serviciile pot Ii vzute ca Iormnd un ntreg.
Abstrac|iile sunt ncapsulate n obiecte. Strile si 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 Iolosi modelul HSV (hue, saturation, value) dac acesta este mai potrivit, Ir ca acest
Iapt s aIecteze restul sistemului.
6.2.3 Motenirea
Mostenirea reprezint mecanismul prin care se exprim similarit|ile dintre clase,
simpliIicnd deIinirea claselor prin utilizarea unor clase anterior deIinite. Acest principiu
pune n eviden| generalizarea si specializarea, Icnd explicite atributele si serviciile
comune, printr-o ierarhie de clase. Principiul mostenirii permite analistului s speciIice
atributele si serviciile comune doar o singur dat, sau s specializeze si s extind anumite
atribute si servicii.
PolimorIismul adaug o nou dimensiune la separarea dintre interIa| si implementare,
dintre ce si cum. El permite crearea de programe Ilexibile si extensibile, n care noi trsturi
pot Ii adugate cu usurin| nu numai n momentul crerii proiectului, dar si n etapele de
dezvoltare ulterioare. PolimorIismul rmne totusi un detaliu de implementare, care poate Ii
ignorat n Iaza de analiz.
6.2.4 Comunicarea prin mesaje
Se reIer la interac|iunea prin mesaje ntre obiecte, interac|iune care corepunde modului
imperativ al limbajelor (comand, cerere). 2.5. Metodele de organizare
Strategia analizei poate Ii construit pe baza a trei metode de organizare:
- iIeren|ierea ntre obiecte si atributele lor (de ex.: a distinge ntre un copac si
nl|imea sa);
- diIeren|ierea dintre obiectul ca ntreg si pr|ile sale componente (de exemplu: a
distinge ntre un copac si ramurile sale);
- diIeren|ierea diverselor clase de obiecte (de exemplu: clasa pietrelor si clasa
arborilor).
6.3 Metoda de analiz Coad-Yourdon
Coad si Yourdon descriu o metod AOO bazat pe cinci activit|i majore:
67/132
- identiIicarea claselor si obiectelor;
- identiIicarea structurilor;
- identiIicarea atributelor;
- identiIicarea serviciilor;
- identiIicarea subiectelor.
Puterea metodei const n descrierea scurt, concis si Iolosirea unor texte generale ca
surse de deIini|ii. Un mare avantaj este men|inerea aceleiasi nota|ii att n Iaza de analiz ct
si n cea de proiectare.
6.3.1 Activitatea I: Identificarea cIaseIor i obiecteIor
Exist mai multe motive principale pentru care trebuie identiIicate clasele si obiectele:
- gsirea unei reprezentri tehnice a sistemului mai aproape de modul n care
concepem lumea nconjurtoare;
- se creeaz astIel o baz stabil pentru analiz si speciIica|ii: clasele si obiectele
pentru un sistem de control al traIicului aerian pot Ii aceleasi si peste cinci ani,
doar serviciile si atributele se pot modiIica radical. Clasele si obiectele sunt
relativ stabile de-a lungul timpului, urmnd ca, la apari|ia modiIicrilor
ulterioare, ele s constituie o baz pentru reutilizare;
- evitarea schimbrii reprezentrii de baz n momentul trecerii de la Iaza de
analiz la cea de proiectare. Aceast problem se rezolv prin utilizarea unei
reprezentri orientate obiect att n Iaza de analiz ct si n Iazele de proiectare
si implementare.
Nota|ii:
O clas de baz, Ir obiecte instan|iate, va Ii reprezentat astIel:
Figura 6-1 Clas fr instane
O clas cu obiecte instan|iate va Ii reprezentat astIel:
Nume clasa
Atribute
Proprietati
Figura 6-2 Clas cu instane
Numele clasei:
- este o construc|ie substantival (engl. ,noun phrase", un singur substantiv sau
substantiv si adjectiv);
- se alege |innd cont de vocabularul standard al domeniului problemei. Folosirea
unei terminologii neIamiliare clientului l Iace s se simt Irustrat si stnjenit;
- se reIer doar la un singur obiect al clasei;
- trebuie s Iie sugestiv;
68/132
- se recomand s se scrie Iolosind litere mari si mici pentru a Iace mai usoar
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 mpr|irea problemei n
subdomenii. De exemplu, dac avem nevoie de 100 de clase, domeniul poate Ii mpr|it n 3-4
subdomenii, Iiecare cu 25-35 de clase.
Odat identiIicate clasele ,candidate", ele trebuie examinate pentru a se decide dac vor
Ii n Iinal incluse n modelul orientat obiect. Exist o serie de criterii pentru aceast decizie:
- Sunt toate aspectele identiIicate relevante pentru sistem? Poate Ii descris orice
obiect al unei clase? Care sunt atributele lui poten|iale? De exemplu, atributele
poten|iale pentru un Iunc|ionar sunt: nume, parol, autoriza|ie. Altele, precum
nl|imea, semne particulare, greutate, nu sunt relevante pentru sistem;
- Este absolut necesar ca un obiect s execute anumite activit|i?
- 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 identiIica un set de atribute aplicabile ntotdeauna tuturor obiectelor
clasei?
Toate clasele identiIicate trebuie s se concentreze asupra inIorma|iilor si serviciilor
cerute de sistem. Nu se Iac reIeriri la detalii de proiectare, desi e bine ca acestea s Iie
re|inute, notate, nc din aceast Iaz. E posibil ca echipa de proiectare s adauge noi clase si
obiecte care s realizeze procesarea cerut de proiectare. Se recomand realizarea analizei si
speciIica|iilor ne|innd cont de o arhitectur speciIic soItware sau hardware a sistemului,
chiar dac clientul garanteaz c ea nu se schimb niciodat.
Trebuie evitat re|inerea unor inIorma|ii care rezult din altele. De exemplu, nu are rost
s se re|in vrsta persoanei dac sistemul deja a nregistrat data nasterii. Trebuie luate n
considerare acele atribute si servicii din care apoi se pot ob|ine rezultate derivate.
6.3.2 Activitatea a II-a: Identificarea structuriIor
Aceast activitate se reIer la eviden|ierea structurilor de tip generalizare-specializare
(,gen-spec") si ntreg-pr|i:
- Structura gen-spec poate Ii vzut ca aspect de diIeren|iere ntre clase,
asemntor deIini|iilor utilizate de gndirea uman pentru organizarea
cunostin|elor, cu gen proxim si diIeren|e speciIice. De exemplu: generalizarea
limbaj de programare si specializarea C . Mai pu|in Iormal, corectitudinea
acestei structuri poate Ii testat prin construc|ii de Iorma ,este un (o)" sau ,este
un Iel de". Pentru exemplul de mai sus, veriIicarea va Ii: ,C este un limbaj de
programare"'. n cadrul structurii gen-spec se aplic principiul mostenirii;
- Structura ntreg-pr|i eviden|iaz componen|a unui obiect. De exemplu: ntregul
limbaj de programare si partea sintax. Corectitudinea acestei structuri poate Ii
testat prin construc|ii de Iorma ,are un (o)": un limbaj de programare are o
sintax, n cadrul structurii ntreg-pr|i se aplic mecanismul agregrii. Din
punct de vedere al implementrii, corespondentul este compunerea claselor.
6.3.2.1 Structura gen-spec
Nota|ia pentru structura gen-spec este urmtoarea:
69/132
Figura 6-3 Structura gen-spec
n vrI se aIl o clas de generalizare, iar pe nivelele urmtoare clase de specializare
(liniile unesc clasele si nu obiectele). Punctul de ramiIicare a liniilor spre specializri se
reprezint printr-un semicerc. Fiecare clas-specializare este denumit astIel nct s aib un
n|eles de sine stttor. Numele cel mai potrivit este Iormat din numele clasei generalizatoare
urmat de numele naturii specializrii. De exemplu, pentru generalizarea Senzor, sunt preIerate
specializrile SenzorCritic si SenzorStandard Ia| de numele Critic si Standard.
n clasele specializate se noteaz numai atributele si serviciile caracteristice. Nu este
necesar men|ionarea atributelor si serviciilor mostenite din clasa de baz. Dac sunt posibile
mai multe specializri, este util considerarea mai nti a celei mai simple si celei mai
complicate specializri, si apoi gsirea unei variante intermediare. Exemplu:
Considerm clasa Avion ca o generalizare. Ea poate Ii specializat n mai multe moduri:
- AvioaneCuReac|ie si AvioaneCuElice;
- AvioaneCivile si AvioaneMilitare;
- AvioaneCuAripiFixe si AvioaneCuAripiMobile;
- AvioaneComerciale si AvioaneP articular e.
S considerm prima specializare (AvioaneCuReac|ie si AvioaneCuElice). Are sens
aceast specializare sens pentru domeniul problemei? Dac nu, atunci nu este necesar. Are
sistemul nevoie s recunoasc diIeren|a dintre avioanele cu reac|ie si cele Ir reac|ie? Sunt
responsabilit|ile sistemului diIerite pentru Iiecare din aceste dou specializri? Dac nu,
atunci acestea nu sunt necesare.
Exist ntr-adevr mostenire, adic anumite atribute si servicii ale clasei Avion se aplic
tuturor avioanelor si apoi se specializeaz n atribute si servicii care se aplic doar celor cu
reac|ie si cu elice? Dac nu, specializarea nu are rost.
Dac singura diIeren| ntre AvionCuReac|ie si AvioaneCuElice este tipul avionului,
atunci se Ioloseste 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 reIlectarea 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:
70/132
Localizare
Avion 1
Aeroport
Figura 6-4 Structur gen-spec eronat
6.3.2.2 Structura ntreg-parte
Nota|ia pentru structura ntreg-parte este urmtoarea:
ntreg
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 inIerioar
pr|i ale acestui obiect. Triunghiul Iace distinc|ia dintre ntreg si pr|i. Fiecare capt al liniei
este marcat cu un interval, indicnd numrul de pr|i pe care un ntreg le poate avea si
numrul de ntregi corespunztori unei pr|i, la orice moment de timp .
Exemple:
71/132
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 organiza|ie este o colec|ie:
- posibil, Ir Iunc|ionari
- de cel mult m Iunc|ionari
72/132
iar un Iunc|ionar este membru al unei singure organiza|ii.
.3.2.2.1 Strategii de identificare a structurilor ntreg-parte
Pentru identiIicarea poten|ialelor structuri ntreg-parte, se consider aspectele:
- ansamblu-pr|i
- container-con|inut
- colec|ie-membri
n plus, se recomand studiul rezultatelor AOO precedente, pentru eviden|ierea
eventualelor structuri de acest tip, care ar putea Ii reIolosite. 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
73/132
In acest exemplu, avionul este considerat un container, pilotul gsindu-se nuntru.
Totusi, pilotul nu apar|ine avionului, nu este o parte a sa, precum motorul. Dac domeniul
problemei si responsabilit|ile 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 organiza|ie poate Ii considerat o colec|ie de Iunc|ionari.
.3.2.2.2 Jerificarea structurilor ntreg-parte
Pentru Iiecare obiect considerat ntreg se veriIic, pentru Iiecare din pr|ile sale, dac:
- acea parte apar|ine domeniului problemei si intereseaz sistemul din punct de
vedere al serviciilor. De exemplu, dac domeniul problemei se reIer 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
responsabilit|ile sistemului includ doar cunostin|e despre starea avionului
(Iunc|ional sau neIunc|ional) sau starea motorului, atunci nu e necesar o clas
Motor. Este suIicient s se prevad un atribut Stare n clasa Avion. Dac ns
sistemul trebuie s stie mai mult despre motor (model, numr de serie, data
Iabrica|iei etc.), atunci este necesar o clas Motor.
Considernd apoi Iiecare obiect ca o parte poten|ial dintr-un ntreg, se veriIic
utilitatea prezen|ei lui n acelasi mod.
6.3.3 Activitatea a III-a: Identificarea atributeIor
Un atribut este o proprietate, calitate sau caracteristic pentru care Iiecare obiect al unei
clase are o anumit valoare. Atributele adaug detalii abstractizrilor de tip clas sau
structur. Ele descriu valori ncapsulate n obiect si vor Ii manipulate exclusiv de ctre
serviciile acelui obiect. Atributele si serviciile obiectului sunt tratate ca un ntreg. Dac o alt
parte a sistemului doreste s acceseze atributele unui obiect, o poate Iace doar prin
speciIicarea unui mesaj de conectare, corespunztor serviciului deIinit de obiect. De-a lungul
74/132
timpului, domeniul claselor rmne relativ stabil, n schimb, atributele sunt mult mai
susceptibile de a se modiIica. Se recomand deIinirea atributelor pe baza urmtoarei strategii:
- identiIicarea atributelor;
- pozi|ionarea atributelor;
- identiIicarea conexiunii instan|elor;
- veriIicarea cazurilor speciale;
- speciIicarea atributelor.
6.3.3.1 Identificarea atributelor
Pentru Iiecare clas, urmrim:
- cum sunt descrise obiectele n general;
- cum sunt descrise obiectele n domeniul problemei;
- cum sunt descrise obiectele n contextul responsabilit|ilor sistemului;
- ce anume trebuie memorat n timp;
- care sunt strile n care se poate aIla 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 acelasi n|eles, ca de exemplu nume, Iormat din nume si prenume, sau adres,
compus din strad, numr, cod postal, oras, |ar).
6.3.3.2 Poziionarea atributelor
Fiecare atribut va Ii pus n clasa pe care o descrie mai bine. De exemplu, n sistemul de
nregistrare a unui vehicul, culoarea acestuia este Ioarte important. Ea este re|inut 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 pozi|ioneaz 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 instan|elor e un model al maprilor ntre domeniile problemelor
obiectelor. Este n strns legtur cu structurile ntreg-parte.
Nota|ie
Figura 6-11 Conexiunea instanelor
Conexiunea instan|elor e reprezentat printr-o linie care uneste obiectele. Fiecare obiect
are o cantitate (m) sau interval (m,n), marcate pe conexiune, reIlectnd restric|iile
conexiunilor cu alte obiecte. Limitele intervalului au urmtoarele semniIica|ii:
- Limita inIerioar
75/132
o O, dac este o conexiune op|ional; 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 Iiecare atribut se veriIic dac exist cazuri cnd nu este aplicabil. De exemplu,
clasa Vehicul poate avea atributul Trac|iune cu valorile: benzin, motorin, electric etc. Dar
pentru anumite vehicule, care nu au motor, acest atribut poate avea valoarea ,Inaplicabil".
Dac exist un astIel de caz, trebuie reanalizat strategia gen-spec, veriIicnd dac nu mai
sunt necesare structuri gen-spec care n-au Iost cuprinse n model.
n continuare, se veriIic clasele care au un singur atribut, n acest caz, Iie clasa are un
singur atribut pentru c asa impun responsabilit|ile sistemului (Iigura 12), Iie atributul nu
este bine pozi|ionat, el apar|innd unei alte clase (Iigura 13). VeriIicnd domeniul problemei,
se constat c n loc de dou clase (Garan|ie si Adres) se poate Iolosi doar una singur
(Garan|ie).
Figura 6-12 Plasarea unui singur atribut ntr-o clas pe care o descrie
Figura 6-13 Plasarea greyit a unui atribut
6.3.3.5 Specificarea atributelor
Pentru speciIicarea atributelor, exist urmtoarele recomandri:
- Numele atributelor trebuie s Iie sugestive, din domeniul problemei;
- SpeciIicarea unui atribut trebuie nso|it de o sumar descriere a sa;
- SpeciIicarea unui atribut trebuie nso|it de eventuale restric|ii:
o unitate de msur, intervale;
o precizie;
o valoare implicit;
76/132
o n ce condi|ii sunt permise serviciile de creare si acces;
o n ce msur este aIectat de valorile altor atribute;
Exemplu de speciIicare a atributelor:
Clasa Senzor
Atribut Model: numrul modelului
Atribut Secven|alnit: secven|a de ini|ializare
Atribut Conversie: const din Iactori de scalare si unit|i 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, oII, standby)
Atribut Valoare: cea mai recent valoare a senzorului
Unele atribute si schimb Ioarte rar valoarea (Model, Secven|elnit, Conversie), altele
si-o schimb mai des (Interval, Adres, Prag, Stare), iar altele sunt dinamice (Valoare).
Atributul Valoare este rezultatul citirii unei valori n unit|i Iizice (de exemplu vol|i) si al
conversiei sale n unit|i standard de msur. Poate Ii tratat ca o valoare recalculabil si n
acest caz nu e nevoie de un atribut Valoare. Dar e posibil ca sistemul s necesite cunoasterea
acestei valori n orice moment, indiIerent de starea senzorului (chiar dac senzorul este n
starea standby, n care valoarea nu poate Ii citit si deci calculat). Este posibil deci, ca
atributul Valoare s nu poat Ii recalculat de Iiecare dat si atunci se justiIic prezen|a sa.
6.3.4 Activitatea a IV-a: Identificarea serviciiIor
n analiza orientat obiect se recomand ca identiIicarea serviciilor s se realizeze dup
identiIicarea claselor, structurilor si atributelor. Serviciul este deIinit ca Iiind o opera|ie
speciIic unui obiect. Pe lng eviden|ierea acestor servicii, se mai pune problema deIinirii
comunica|iilor necesare ntre obiecte. Strategia deIinirii serviciilor const n urmtoarele
etape. Mai nti se identiIic strile posibile ale obiectelor, date de valorile atributelor lor.
Pentru a identiIica starea unui obiect:
- se examineaz valorile poten|iale ale atributelor;
- se determin dac sistemul are comportri diIerite pentru aceste valori;
- se examineaz rezultatele AOO anterioare.
Exemplu: care din atributele sistemului Senzor reIlect o schimbare n starea obiectului?
Atributele sistemului sunt cele prezentate mai sus. Pentru acest sistem valorile atributelor
Model, Secven|alnit, Conversie, Interval, Adres, Prag nu implic o modiIicare a comportrii
sistemului, ns atributul Stare reIlect o schimbare n comportarea sistemului. Valorile sale
sunt: on, oII si standby. Diagramele strilor obiectelor prezint diIeritele stri ale sistemului n
timp.
Nota|ia pentru diagramele strilor obiectelor:
Figura 6-14 Diagrama strilor obiectelor
Exemplu:
77/132
Figura 6-15 Diagrama strilor obiectului pentru sistemul Senzor
n acest exemplu, sgeata din vrI indic starea ini|ial. Sunt prezentate doar strile si
tranzi|iile legale.
Apoi se trece la identiIicarea serviciilor propriu-zise. Exist dou tipuri de servicii:
- servicii algoritmic-simple;
- servicii algoritmic-complexe.
Serviciile algoritmic-simple se aplic Iiecrei clase, sunt implicite si nu sunt
reprezentate pe stratul serviciilor. Exemple tipice de astIel de servicii sunt: crearea obiectelor
(constructorii), accesul la obiecte (opera|ii get/set) si distrugerea obiectelor (destructorul).
Majoritatea opera|iunilor unui sistem (80 - 95) se concentreaz n serviciile algoritmic-
simple.
Serviciile algoritmic-complexe sunt si ele de dou tipuri: de calcul (calculeaz un
rezultat Iolosind valorile unor atribute) si de monitorizare (supravegheaz un sistem sau
dispozitiv extern, trateaz intrrile si iesirile acestuia, achizi|ioneaz si controleaz date).
Tot n cadrul identiIicrii serviciilor trebuie precizate si conexiunile prin mesaje ntre
obiecte, adic modurile n care un obiect transmi|tor trimite un mesaj ctre un obiect receptor
pentru ca acesta din urm s execute o anumit prelucrare. Prelucrarea este denumit n
speciIicarea serviciilor transmi|torului si deIinit m speciIicarea serviciilor receptorului.
Nota|ie:
Figura 6-16 Conexiune prin mesaje
Receptorul primeste mesajul, execut opera|iunea corespunztoare si returneaz un
rezultat transmi|torului.
Pentru conexiuni prin mesaje de la un obiect spre mai multe obiecte, exist urmtoarea
nota|ie:
Figura 6-17 Conexiune prin mesaje spre mai multe obiecte
Interac|iunile dintre Iactorul uman si sistem sunt si ele reprezentate n modelul AOO:
78/132
Figura 6-18 Interaciune cu factorul uman
Pentru a eviden|ia conexiunile prin mesaje ntre obiecte, se pun urmtoarele ntrebri
pentru Iiecare obiect:
- de serviciile cror alte obiecte are nevoie? Se traseaz cte o sgeat ctre
Iiecare din aceste obiecte;
- ce alte obiecte au nevoie de serviciile lui ? Se traseaz cte o sgeat dinspre
Iiecare din aceste obiecte;
- se urmreste conexiunea prin mesaj spre obiectul destinatar si se repet aceleasi
ntrebri;
- se examineaz rezultatele AOO anterioare.
6.3.5 Activitatea a V-a: Identificarea subiecteIor
In AOO, termenul de subiect este un mecanism pentru ghidarea cititorului (analist,
manager, expert, utilizator, client) n n|elegerea unui model de analiz Ioarte mare si
complex. Subiectele oIer o imagine de perspectiv asupra unui model complex.
Fiecare clas din vrIul Iiecrei structuri se asigneaz unui subiect. Fiecare clas care nu
Iace 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
identiIicate deja.
Subiectele se raIineaz apoi utiliznd subdomeniile problemei. De Iapt, se aplic
principiul ntreg-parte pe domeniul problemei. RaIinarea ia n considera|ie interdependen|ele
si interac|iunile minimale ntre subiecte. Interdependen|ele sunt exprimate de structuri
atribute, iar interac|iunile sunt exprimate de servicii.
Un subiect se reprezint printr-un dreptunghi, Iiind etichetat n interior cu un nume si un
numr si con|innd si lista claselor care Iac parte din acel subiect. Practic, pentru modele
Ioarte complexe, subiectele se pot reprezenta n trei moduri:
- Subiecte ne-expandate: doar dreptunghiul cu numele si numrul lor:
Figura 6-19 : Subiect ne-expandat
- Subiecte par|ial expandate, con|innd lista claselor componente:
79/132
Figura 6-20 Subiect parial expandat
Subiecte total expandate, cnd se reprezint mpreun cu alte straturi ale modelului AOO, prin
zone parti|ionate si numerotate. In interiorul dreptunghiurilor numerotate vor Ii incluse clasele
cu nota|ia complet: nume, atribute, servicii, eventual si cu legturile dintre ele:
Figura 6-21 Subiect total expandat
O clas poate Iace parte din mai multe subiecte, cnd acest lucru este necesar pentru
ghidarea cititorului. Subiectele pot con|ine la rndul lor alte subiecte, Iurniznd astIel o hart
multinivel. n general, subiectele sunt necesare pentru modele relativ mari, avnd aproximativ
30-40 de clase. IdentiIicarea subiectelor se va Iace abia dup ce clasele au Iost identiIicate si
bine n|elese.
6.4 Concluzii
n acest curs au Iost prezentate mai nti chestiuni legate de ingineria cerin|elor:
deIinirea cerin|ei, extragerea, identiIicarea si speciIicarea cerin|elor. Apoi a Iost descris
problematica general a analizei orientate obiect, insistndu-se pe metoda de analiz Coad-
Yourdon si pe activit|ile ei speciIice: identiIicarea claselor si obiectelor, a structurilor,
atributelor, serviciilor si subiectelor.
80/132
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 pasi:
- studiul si n|elegerea problemei;
- identiIicarea mai multor solu|ii posibile si evaluarea Iiecreia din ele. Alegerea
ei depinde de experien|a proiectantului, simplitatea acesteia, valabilitatea
componentelor reutilizabile;
- descrierea Iiecrei abstractizri a Iiecrei solu|ii, nainte de crearea
documenta|iei Iormale, ar putea Ii necesar ca proiectantul s pregteasc o
descriere inIormativ a proiectului pentru a Ii examinat n detaliu, n Ielul
acesta, omisiunile si erorile posibile ar putea Ii eliminate nainte ca proiectul s
Iie documentat.
Activit|ile esen|iale n cursul proiectrii sunt urmtoarele:
- Proiectarea arhitectural: subsistemele ntregului sistem sunt identiIicate si
documentate;
- Specificarea abstract: pentru Iiecare subsistem, se prezint o speciIicare
abstract a serviciilor si a constrngerilor sub care acestea opereaz;
- Proiectarea interfeei: pentru Iiecare subsistem, interIa|a cu celelalte
subsisteme este proiectat si documentat;
- Proiectarea componentelor: serviciile Iurnizate de un subsistem sunt
parti|ionate ntre componentele acelui subsistem;
- Proiectarea structurilor de date: structurile de date utilizate n implementarea
sistemului sunt proiectate n detaliu si speciIicate.
- Proiectarea algoritmilor: algoritmii utiliza|i pentru a Iurniza servicii sunt
proiecta|i n detaliu si speciIica|i. Acest proces se repet pentru Iiecare subsistem
pn cnd componentele identiIicate pot Ii mapate direct n componentele
limbajului de programare.
7.2 Caracteristicile unei proiectri corecte
Rezultatul principal a Iazei de proiectare este un model al codului care arat cum este
implementat sistemul si o diagram a dependen|elor dintre module, care arat cum va Ii
sistemul divizat n module si cum interac|ioneaz acestea. Pentru module mai diIicile, se
includ speciIica|ii speciale.
Ce nseamn o proiectare corect? Desigur, nu exist o modalitate simpl si obiectiv
care s spun c o proiectare este mai bun dect alta. Dar exist unele propriet|i cheie care
pot Ii utilizate pentru a msura calitatea proiectrii, n mod ideal, o proiectare ar trebui s aib
toate aceste caracteristici. In practic, trebuie Icute compromisuri ntre ele. Aceste
caracteristici sunt extensibilitatea, siguran|a si eIicien|a.
7.2.1 ExtensibiIitatea
Proiectarea trebuie s poat suporta noi Iunc|ii. Un sistem perIect din toate celelalte
puncte de vedere, dar n care nu poate Ii integrat nici o schimbare sau mbunt|ire, nu este
de prea mare Iolos. Chiar dac nu exist cerin|e pentru trsturi suplimentare, probabil vor
exista schimbri n domeniul problemei care vor necesita schimbri n program.
SuIicien|a modelului: Modelul problemei trebuie s reIlecte caracteristicile suIiciente
ale problemei. Un obstacol des ntlnit atunci cnd se doreste extinderea unui sistem este
81/132
Iaptul c anumite no|iuni nu sunt exprimate n cod si deci Iunc|ionalit|ile corespunztoare
care trebuie adugate nu-si gsesc locul n program. Un exemplu n acest sens poate Ii vzut
n MicrosoIt Word. Acesta a Iost proiectat plecnd de la premisa c structura Iundamental de
organizare a unui document este paragraIul. De aceea, structurile ierarhice pot Ii introduse cu
greutate si, ca eIect, divizarea documentului n sec|iuni nu se Iace Ioarte eIicient. Optimizarea
modelului nu trebuie s elimine substructurile care numai par neIolositoare. Abstractizrile nu
trebuie s nlocuiasc structurile concrete dect dup o analiz serioas.
Localizarea: Chiar dac programul cuprinde no|iuni suIiciente pe baza crora s poat Ii
adugate noi Iunc|ionalit|i, acestea trebuie introduse Ir a modiIica tot codul. De aceea,
proiectarea trebuie s Iie localizat, adic problemele diIerite trebuie separate n regiuni
distincte ale codului. Modulele trebuie decuplate ct mai mult, astIel nct o schimbare s nu
antreneze modiIicri n cascad.
7.2.2 Siguran{a
Sistemul trebuie s aib un comportament sigur, care nu presupune doar lipsa
,prbusirilor" sau a pierderii datelor, ci si Iaptul c trebuie s ruleze corect, asa cum se
asteapt utilizatorul. Nu e suIicient ca sistemul s ndeplineasc o speciIica|ie obscur, ci
trebuie s ndeplineasc o speciIica|ie care poate Ii n|eleas usor de utilizator, astIel 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 siguran|ei variaz n Iunc|ie de tipul aplica|iei. Conexiunile teleIonice
automate trebuie s Iie n permanen| disponibile si s Iie Ioarte sigure, uneori pot Ii
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 aceleasi ntrzieri se pot dovedi catastroIale
pentru un controler de reactor nuclear.
Modelarea atent. Siguran|a nu poate Ii introdus usor ntr-un sistem existent. Cheia
realizrii de produse sigure este modelarea si dezvoltarea atent. Problemele serioase n
sistemele critice n general nu apar din erori de programare, ci din erori de analiz a
problemei. Programatorii pur si 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 Iurtun pe aeroportul din Varsovia, ns Irnele nu au Iunc|ionat, avionul
a iesit de pe pist si a luat Ioc.
Analiza si testarea. Orict de atent ar Ii cineva, este Ioarte probabil c va Iace pn la
urm greseli. Din punct de vedere al costului, cea mai bun solu|ie este veriIicarea codului de
ctre alt persoan. O testare mai detaliat si care poate descoperi erori mai subtile poate Ii
realizat cu un instrument automat.
7.2.3 Eficien{a
Sistemul trebuie s consume resurse n limite rezonabile. EIicien|a depinde de context.
O aplica|ie care ruleaz pe un teleIon celular nu are disponibil la Iel de mult memorie ca
una care ruleaz pe un PC. Pentru determinarea eIicien|ei unui program, se analizeaz n
general timpul de execu|ie si spa|iul necesar. Pe lng timpul de execu|ie, este la Iel de
important si timpul necesar dezvoltrii, care este legat de costul aplica|iei. O proiectare care
poate Ii implementat mai economic poate Ii preIerabil uneia care ndeplineste 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 perIorman| trebuie considerate nc de la nceput n
Iaza de proiectare.
Evitarea tenden|iozit|ii. Cnd se dezvolt modelul obiectelor pentru problem, trebuie
excluse orice preocupri legate de implementare. Un model care con|ine detalii de
82/132
implementare este tenden|ios (engl. ,biased"), deoarece Iavorizeaz o anumit implementare.
Rezultatul este excluderea unor posibilit|i de implementare care se pot dovedi n Iinal mai
eIiciente.
Optimizarea, n general, ,optimizare" este o denumire gresit, deoarece nseamn
cresterea perIorman|elor n detrimentul altor calit|i, cum ar Ii claritatea structurii. Dac
optimizarea nu este tratat cu aten|ie, putem risca s ajungem la un sistem mai prost din toate
punctele de vedere. Sunt recomandate numai optimizrile care vor avea eIecte Ioarte
puternice, de exemplu o modiIicare 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 stim, Iaza de proiectare se aIl situat ntre analiz si implementare. Toate
aceste Iaze Iac parte din procesul de dezvoltare orientat obiect. Asa cum am vzut n cursul
precedent, analiza orientat obiect se reIer la dezvoltarea unui model orientat obiect al
domeniului aplica|iei. Obiectele identiIicate reIlect entit|i si opera|ii asociate cu problema
care trebuie rezolvat. Proiectarea orientat obiect priveste dezvoltarea unui model orientat
obiect al sistemului soItware care trebuie s implementeze cerin|ele identiIicate. Programarea
orientat obiect urmreste implementarea (punerea n practic a) proiectrii soItware Iolosind
un anumit limbaj de programare orientat obiect.
Continund Iaza de analiz orientat obiect, proiectarea orientat obiect este o strategie
n care sistemul se gndeste n termeni de ,obiecte", n loc de opera|ii si Iunc|ii. Programul nu
este proiectat ca o mul|ime de Iunc|ii care schimb date prin parametri si memorie comun
(variabile globale), ci ca o mul|ime de obiecte care interac|ioneaz. Obiectele si pstreaz
starea intern si si deIinesc opera|iile pe baza acesteia. Prin ascunderea inIorma|iilor despre
reprezentarea strii, ei limiteaz accesul exterior la starea intern. Asadar, caracteristicile
proiectrii orientate obiect sunt urmtoarei e:
a) sistemul este proiectat ca o mul|ime de obiecte care interac|ioneaz, si
gestioneaz propria stare intern si oIer servicii altor obiecte;
b) obiectele sunt create prin instan|ierea unei clase care deIineste atributele si
opera|iile asociate obiectului; mai multe obiecte ale aceleiasi clase pot coexista
n acelasi program;
c) clasele sunt abstractizri ale lumii reale sau entit|i care ncapsuleaz
inIorma|ii de stare si care deIinesc un numr de servicii care creeaz,
acceseaz sau modiIic starea;
d) obiectele sunt entit|i independente n care reprezentarea strii poate Ii
modiIicat Ir a aIecta alte clase din sistem;
e) Iunc|ionalitatea sistemului este dat de serviciile asociate Iiecrui obiect;
obiectele interac|ioneaz prin apelarea serviciilor deIinite de alte obiecte;
I) nu exist zone de memorie comun; obiectele comunic prin apeluri de servicii
si nu prin variabile partajate; nu exist posibilitatea ca o component s Iie
aIectat de schimbarea unei inIorma|ii partajate si deci modiIicrile sunt mai
usor de implementat;
g) obiectele pot Ii distribuite si pot Ii executate secven|ial 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:
83/132
- n|elegerea si deIinirea contextului n care va evolua sistemul si a modului n
care acesta va Ii utilizat;
- proiectarea arhitecturii sistemului;
- identiIicarea principalelor obiectelor din sistem;
- dezvoltarea modelelor de proiectare;
- speciIicarea interIe|elor obiectelor.
Aceste etape nu trebuie gndite ntr-o ordine strict, ele se ntreptrund si se
inIluen|eaz reciproc. Pe msur ce sunt realizate modelele obiect, activit|ile de mai sus
modiIic treptat arhitectura sistemului. Proiectarea nu este un proces simplu si bine structurat.
In realitate, se propun si se raIineaz solu|ii pe msur ce se adun mai multe inIorma|ii, se
revine asupra unor decizii dac acestea se dovedesc gresite; uneori se exploreaz n detaliu
toate op|iunile, alteori detaliile sunt ignorate pentru a Ii considerate mai trziu n cadrul
procesului.
7.4.1 ContextuI sistemuIui i modeIeIe de utiIizare
Prima etap a procesului de proiectare soItware este n|elegerea rela|iilor dintre sistemul
proiectat si mediul su extern. Aceasta va determina alegerea Iunc|ionalit|ilor necesare si
structurarea lor astIel nct sistemul s poat comunica eIicient cu mediul. Contextul
sistemului si modelul de utilizare a sistemului reprezint dou modele complementare ale
rela|iei dintre sistem si mediu:
- contextul sistemului este un model static care descrie celelalte sisteme din
mediu;
- modelul de utilizare a sistemului este un model dinamic care descrie
interac|iunea dintre sistem si mediu.
7.4.2 Proiectarea arhitecturii
Dup ce au Iost deIinite interac|iunile dintre sistem si mediu, aceste inIorma|ii pot Ii
utilizate ca baz pentru proiectarea arhitecturii sistemului. Desigur, inIorma|iile din etapa
precedent trebuie combinate cu unele cunostin|e generale despre principiile proiectrii
arhitecturii si cu unele cunostin|e detaliate despre domeniul problemei.
O regul euristic spune c ntr-un model de arhitectur nu trebuie incluse mai mult de
sapte entit|i Iundamentale. Fiecare din aceste entit|i poate Ii apoi descris separat, dar,
binen|eles, depinde de proiectant dac vrea s prezinte n arhitectur structura tuturor
entit|ilor sistemului.
De exemplu, arhitectura unui agent de corectare lexical (spell-checker) poate Ii
urmtoarea:
Control de editare
(RichTextBox)
Utilizator
Prelucrare
text
Text
Spell-checker
agent
Cuvinte
Marcare cuvinte
Fisiere
Dictionar
Figura 7-1 Exemplu de arhitectur: agent spell-checker
84/132
7.4.3 Identificarea obiecteIor
In acest stadiu al proiectrii, deja s-au conturat unele idei despre obiectele esen|iale
pentru sistem. Obiectele si clasele identiIicate n Iaza de analiz sunt veriIicate si raIinate
pentru a se potrivi n programul care urmeaz a Ii realizat.
O tehnic de identiIicare a obiectelor este utilizarea unei abordri comportamentale.
Proiectantul ncearc s n|eleag mai nti comportamentul general al sistemului.
Comportamentelor diIerite le corespund pr|i diIerite din sistem. Mai trebuie vzut cine
ini|iaz si particip n aceste comportamente. Participan|ii cu rol semniIicativ sunt recunoscu|i
drept obiecte.
Alt tehnic se bazeaz pe analiza scenariilor. DiIeritele scenarii ale utilizrii sistemului
sunt identiIicate si analizate pe rnd. Pentru Iiecare scenariu se identiIic obiectele necesare,
mpreun cu atributele si serviciile acestora.
7.4.4 ModeIe de proiectare
Modelele de proiectare arat clasele si obiectele n cadrul sistemului, precum si rela|iile
dintre acestea. Ele reprezint puntea de legtur ntre cerin|ele sistemului si implementarea
sistemului. De cele mai multe ori, exist cerin|e conIlictuale pentru modele. Ele trebuie s Iie
abstracte pentru ca detaliile nesemniIicative s nu ascund rela|iile cu cerin|ele sistemului.
Totusi, ele trebuie de asemenea s includ suIiciente detalii pentru ca programatorii s poat
lua deciziile de implementare corespunztoare.
O solu|ie a acestei probleme este dezvoltarea de modele diIerite la diIerite nivele de
detaliu. Cnd exist legturi strnse ntre inginerii de cerin|e, proiectan|i si programatori,
modelele abstracte sunt suIiciente. Decizii speciIice de proiectare pot Ii Icute pe msur ce
sistemul este implementat. Cnd legturile dintre echipele implicate sunt indirecte (de
exemplu, cnd sistemul este proiectat de o parte a unei organiza|ii si implementat n alt
parte), sunt necesare modele mai detaliate. Detalierea modelului depinde si de tipul de sistem
dezvoltat. Un sistem simplu de prelucrare secven|ial a datelor va Ii proiectat ntr-un mod
diIerit Ia| de un sistem integrat de timp real si deci vor Ii necesare modele de proiectare
diIerite. 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 si ai rela|iilor dintre ele; rela|iile importante care trebuie documentate
n aceast etap sunt: rela|iile de generalizare, rela|iile Ioloseste/este Iolosit de,
rela|iile de compunere etc.;
- modelele dinamice, care descriu structura dinamic a sistemului, cu
interac|iunile dintre obiectele sistemului (nu dintre clase); interac|iunile care
trebuie documentate aici sunt serviciile solicitate de obiecte si modul n care
starea sistemului este inIluen|at de acestea.
7.4.5 Specificarea interfe{eIor obiecteIor
O parte important a procesului de proiectare este speciIicarea interIe|elor dintre
diIeritele componente ale proiectrii. Ea este Ioarte important si deoarece permite
posibilitatea ca obiectele si celelalte componente s Iie proiectate n paralel. Odat ce a Iost
speciIicat interIa|a, cei care dezvolt celelalte obiecte pot considera c aceasta este interIa|a
care va Ii implementat.
Proiectan|ii trebuie s evite inIorma|iile privind reprezentarea interIe|ei. Reprezentarea
trebuie s Iie ascuns, iar pentru accesarea si actualizarea datelor trebuie Iurnizate servicii ale
obiectelor. Dup cum stim, dac reprezentarea este ascuns, ea poate Ii schimbat Ir a
aIecta obiectele care Iolosesc atributele respective, n acest Iel, design-ul devine mai usor de
85/132
ntre|inut. De exemplu, reprezentarea unei stive ca vector poate Ii schimbat cu o reprezentare
de tip list Ir s aIecteze celelalte obiecte care Iolosesc stiva.
Intre obiecte si interIe|e nu exist n mod necesar o rela|ie simpl 1:1. Acelasi obiect
poate avea mai multe interIe|e care semniIic perspective diIerite asupra serviciilor pe care le
Iurnizeaz. De exemplu, n Java sau C#, interIe|ele sunt declarate separat de obiecte iar
obiectele ,implementeaz" interIe|ele. De asemenea, un grup de obiecte poate Ii accesat
printr-o singur interIa|.
Proiectarea interIe|elor obiectelor trebuie s speciIice semnturile si 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 interac|iunii cu Iactorul uman;
- componenta coordonrii task-urilor;
- componenta coordonrii datelor.
Fiecare component este construit din clase si obiecte. Componenta domeniului
problemei se bazeaz pe modelul logic construit n timpul analizei orientate obiect. Dac
sistemul va Ii implementat ntr-un limbaj de programare orientat obiect, atunci va exista o
coresponden| de l la l ntre clasele si obiectele domeniului problemei. Componenta
interac|iunii cu Iactorul uman coordoneaz mesajele dinspre si nspre utilizator. Componenta
coordonrii task-urilor se reIer la multiplele Iire de execu|ie existente ntr-un sistem.
Componenta coordonrii datelor Iurnizeaz inIrastructura pentru nregistrarea si regsirea
datelor. Corespunztoare acestor patru componente, metoda identiIic patru activit|i:
- proiectarea componentei domeniului problemei;
- proiectarea componentei interac|iunii cu Iactorul uman;
- proiectarea componentei coordonrii task-urilor;
- proiectarea componentei coordonrii datelor.
7.5.1 Activitatea I: Proiectarea componentei domeniuIui probIemei
n aceast prim activitate, componentele domeniului rezultate din analiz sunt utilizate
si suplimentate. Deoarece se bazeaz pe reutilizarea claselor identiIicate de Iaza de analiz,
modiIicrile trebuie men|inute pe ct posibil la un nivel redus.
Apoi clasele speciIice domeniului problemei sunt grupate mpreun prin adugarea unei
clase rdcin. Viznd direct limbajul de programare care va Ii utilizat pentru implementare,
poate Ii necesar modiIicarea structurilor gen-spec pentru a se potrivi nivelului de mostenire
oIerit de limbajul ales.
Dac structurile gen-spec ale modelului analizei orientate obiect includ mosteniri
multiple, trebuie Icute cteva modiIicri ale acestora atunci cnd se va utiliza un limbaj de
programare orientat obiect care nu suport mecanismul mostenirii sau care nu suport dect
mostenirea simpl. Dou tipuri de mostenire multipl sunt prezentate n Iigurile 2 si 3.
86/132
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 mostenire multipl (de exemplu C), se recomand
evitarea acesteia datorit complexit|ii pe care o presupune. In cazul limbajelor care suport
87/132
doar mostenire simpl (Java, C#) se pot aplica metode de a transIorma o mostenire multipl
ntr-o mostenire simpl:
Clasa A
Clasa B
Clasa B2 Clasa B1
1
1,m
Figura 7-4 Formarea unor ierarhii separate, mapate ntre ele prin structuri ntreg-parte
Ierarhia multipl poate Ii transIormat direct ntr-o ierarhie simpl, caz n care anumite
atribute si servicii vor Ii repetate n clasele specializate.
Figura 7-5 Acomodarea cu limbaje care nu suport moytenire multipl
Dac limbajul nu suport mecanismul de mostenire, Iiecare structur gen-spec se va
descompune n clasele componente.
Figura 7-6 Acomodarea cu limbaje care nu suport moytenire
88/132
Urmtorul pas n schimbarea componentelor domeniului problemei este mbunt|irea
aspectelor de perIorman|. Viteza poate Ii mbunt|it prin msurarea vitezei eIective a
codului si prin optimizarea acestuia. Cresterea vitezei e necesar de obicei cnd ntre obiecte
exist un traIic prea mare de mesaje. In acest caz, se combin dou sau mai multe clase.
Singurul mod de a sti dac aceste modiIicri contribuie la cresterea vitezei, este prin msurare
si observare. Viteza perceput de utilizator poate Ii 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 Ii salvat de componenta de coordonare
a datelor. In ambele abordri, la componenta domeniului problemei trebuie adugate atribute
si servicii speciIice.
Pentru Iacilitarea proiectrii si programrii, componentele de nivel sczut pot Ii izolate
n clase separate. Ultimul pas n proiectarea componentei domeniului problemei este
veriIicarea completrilor aduse la rezultatele Iazei de analiz orientat obiect.
7.5.2 Activitatea a II-a: Proiectarea componentei interac{iunii cu factoruI
uman
Pentru aceast activitate se recomand prototipizarea. Activitatea ncepe cu clasiIicarea
persoanelor care vor utiliza sistemul, pe baza unor criterii precum:
- nivel de pregtire;
- nivel de organizare;
- apartenen|a la diIerite grupuri (de exemplu: Iunc|ionar sau client). Fiecare
categorie deIinit trebuie descris, incluzndu-se un scenariu de task-uri. Pentru
Iiecare categorie, trebuie notate urmtoarele:
- ce este;
- scopul;
- caracteristici (de exemplu: vrst, educa|ie etc.);
- Iactori critici de succes (necesit|i/dorin|e, preIerin|e/antipatii/tendin|e
subiective);
- nivel de pregtire;
- scenarii ale task-urilor.
Apoi trebuie proiectat o ierarhie de comenzi pentru sistem prin studierea sistemelor
existente de interac|iune cu Iactorul uman. Pentru raIinarea ierarhiei, trebuie considerate
urmtoarele:
- ordonarea serviciilor;
- parti|ionarea modelelor ntreg-parte si veriIicarea dimensiunilor structurii de
comenzi (l|ime: numrul de categorii de op|iuni, adncime: numrul de nivele
pentru Iiecare categorie de op|iuni);
- minimizarea numrului de pasi necesari pentru eIectuarea unui serviciu.
- n continuare se proiecteaz detaliat interac|iunea, dup urmtoarele criterii:
- consisten|a;
- minimizarea numrului de pasi;
- acordarea de Ieedback prompt si semniIicativ utilizatorilor;
- asigurarea Iunc|iilor ,undo";
- minimizarea rolului capacit|ii de memorare a utilizatorilor pentru reamintirea
op|iunilor;
- minimizarea timpului de nv|are si a eIortului;
- proiectarea estetic a sistemului (este important ca utilizatorilor s le plac
sistemul).
89/132
Dup veriIicarea utilit|ii interac|iunilor, sunt proiectate clasele de interac|iune cu
Iactorul uman: Ierestre, cmpuri, graIice etc. De cte ori e posibil, trebuie utilizate interIe|ele
graIice standard cu utilizatorul (GUI).
7.5.3 Activitatea a III-a: Proiectarea componentei coordonrii task-uriIor
Mai nti trebuie vzut dac e nevoie de task-uri n sistem. Urmtoarele tipuri de
sisteme necesit task-uri:
- sisteme de achizi|ii de date si de control al dispozitivelor locale;
- interac|iuni cu Iactorul uman cu Ierestre multiple care ruleaz simultan;
- sisteme multi-user;
- sisteme mono-procesor care necesit comunicare si 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 Ii identiIicate:
- task-uri declansate de un eveniment (de exemplu: apsarea unui buton al mouse-
ului);
- task-uri declansate la un anumit interval de timp;
- task-uri prioritare si critice.
Cnd sunt necesare trei sau mai multe task-uri, se recomand adugarea unui task
special de coordonare. Dup identiIicarea task-urilor, necesitatea lor trebuie reveriIicat.
Pentru Iiecare task, trebuie speciIicat:
- ce este task-ul;
- cum este coordonat task-ul;
- cum comunic task-ul.
7.5.4 Activitatea a IV-a: Proiectarea componentei coordonrii dateIor
Mai nti trebuie selectat o abordare pentru coordonarea datelor: Iisiere simple sau un
sistem de gestionare a bazelor de date, pe baza unor criterii potrivite. Apoi, n Iunc|ie de
abordarea aleas, trebuie proiectat componenta de coordonare a datelor, adic a Iormatului
de date si a serviciilor corespunztoare.
7.6 Concluzii
Scopul acestui curs este de a realiza o introducere n procesul de proiectare a sistemelor
soItware. Au Iost amintite mai nti caracteristicile unei proiectri corecte: extensibilitatea,
siguran|a si eIicien|a, mpreun cu modalit|ile prin care pot Ii atinse aceste deziderate. S-a
deIinit proiectarea orientat obiect si s-au detaliat etapele acestei Iaze de dezvoltare a
produselor soItware: determinarea contextului sistemului si a modelelor de utilizare,
proiectarea arhitecturii, identiIicarea obiectelor, modelele de proiectare si speciIicarea
interIe|elor obiectelor, n Iinal, s-a concretizat aceast Iaz prin descrierea metodei de
proiectare Coad-Yourdon, cu cele patru activit|i speciIice: proiectarea componentei
domeniului problemei, proiectarea componentei interac|iunii cu Iactorul uman, proiectarea
componentei coordonrii task-urilor si proiectarea componentei coordonrii datelor.
90/132
8 Limbaje de modeIare. UML
8.1 Limbaje de modelare
Problema principal care apare n dezvoltarea programelor este complexitatea. Folosirea
de modele poate nlesni abordarea unor astIel de probleme. Un model este o simpliIicare a
unui anumit sistem, care permite analizarea unora dintre propriet|ile acestuia. Lucrul cu
modelele poate Iacilita o mai bun n|elegere a sistemului modelat, datorit diIicult|ii
intrinseci de n|elegere a sistemului n ntregul su. Folosirea tehnicii ,divide et impera"
permite n|elegerea pr|ilor componente ale unui sistem, iar ansambul sistemului ca o
interac|iune ntre pr|ile acestuia. Un model reusit re|ine caracteristicile importante ale
obiectului modelat (caracteristicile necesare) si le ignor pe cele irelevante. De remarcat c
no|iunile de important/irelevant sunt relative, ele depinznd de scopul pentru care se Iace
modelarea. AstIel apare plauzibil construirea mai multor modele pentru un anumit obiect,
Iiecare surprinznd anumite aspecte ale acestuia.
Orice metodologie de dezvoltare a programelor abordeaz problema comunicrii dintre
membrii echipei. Este posibil s apar situa|ii n care modelul construit de proiectant s nu Iie
n|eles exact de cel ce scrie cod, Iie din cauza lipsei de precizie a modului n care este
prezentat modelul, Iie datorit incompletitudinei acestuia; adesea o serie de amnunte subtile,
evidente pentru proiectant, nu sunt transmise explicit. O rezolvare a problemei comunicrii ar
Ii ca aceeasi persoan s Iie implicat direct n toate Iazele dezvoltrii. Chiar si asa, apare des
situa|ia n care o persoan trebuie s continue munca alteia.
Se impune asadar existen|a unui limbaj Iormal de comunicare a cerin|elor. Termenul
,Iormal" este esen|ial. De obicei, chiar si n proiecte de dimensiuni reduse se Iace modelare,
ns ntr-un limbaj speciIic celui care modeleaz, determinat de viziunea sa asupra problemei
si de pregtirea acestuia (de exemplu, un matematician va Ii nclinat s utilizeze o nota|ie
algebric, un arhitect o nota|ie preponderent graIic etc.) Folosirea unui limbaj ,intern" nu
trebuie considerat negativ, ea avnd un rol esen|ial n gndire n general si n modelare n
particular. Asa cum Iormalismul ra|ionamentului matematic poate Ii agentul de transmisie al
adevrului matematic (care, odat transmis, este ,tradus" n limbajul intern al receptorului),
Iormalismul limbajului de modelare const n stabilirea unor elemente cu o semantic asupra
creia se convine si cu ajutorul crora se pot transmite idei ntr-un mod ct mai eIicient si Ir
ambiguit|i.
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 ineIicient s considerm
aspectul greut|ii microprocesorului de Iiecare dat cnd utilizm un calculator si 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 arteIact ce depseste capacitatea de n|elegere a unui singur individ. Motivul
pentru care exist totusi microprocesoare si navete cosmice este simplu: se Iolosesc modele.
Modelul este o simpliIicare a realit|ii. Aceast simpliIicare re|ine caracteristicile relevante
ale unui sistem, n timp ce le ignor pe celelalte.
S considerm analiza comportamentului unui corp sub ac|iunea unei Ior|e externe. Pe
baza experien|ei n domeniu, stim c singurele atribute care inIluen|eaz analiza n acest caz
sunt masa corpului si Ior|a rezultant care ac|ioneaz asupra corpului. Un model uzual de
reprezentare a acestei probleme este urmtorul:
91/132
m
v
Figura 8-1 Modelare n fizic
Acest model Iace cteva simpliIicri evidente. Forma corpului este desenat ca un
ptrat. Diverse alte caracteristici sau interac|iuni cu mediul sunt ignorate. Pe de alt parte,
viteza si Ior|a sunt reprezentate prin vectori. Viteza este notat cu v, Ior|a cu F, masa cu m.
Toate aceste elemente Iormeaz un model. Pentru un ini|iat, desenul de mai sus este
consistent, expresiv si compact. O descriere alternativ, sub Iorma de text, desi posibil mai
exact, ar Ii mai greoaie: ,Iie un corp de mas m asupra cruia ac|ioneaz o Ior| F cu punctul
de aplica|ie n centrul su de greutate. Corpul se deplaseaz cu o vitez v perpendicular pe
direc|ia Ior|ei".
Limbajul natural pare s Iie cel mai la ndemn limbaj de modelare. Experien|a arat
ns c Iolosirea sa induce adesea neclarit|i si inconsisten|e. Apare astIel necesitatea deIinirii
unui limbaj neambiguu pentru speciIicarea modelelor. Se convine asupra unui set de elemente
ale limbajului precum si asupra semanticii acestora. Evident, descrierea elementelor si a
semanticii se Iace n ultim instan| n limbaj natural, deci pot aprea aici unele ambiguit|i,
n acest caz ns, limbajul natural este Iolosit numai ntr-o mic parte a sistemului iar
problemele de semantic pot Ii localizate. Eliminarea ambiguit|ilor din modele poate Ii
Icut mbunt|ind precizia limbajului de modelare si nu cutnd erori de semantic n
ntreaga descriere a modelului.
8.2 Ce este UML?
Limbajul uniIicat de modelare (engl. ,UniIied Modeling Language"), UML, este un
limbaj pentru speciIicarea, vizualizarea, construirea si documentarea elementelor sistemelor
soItware, ns poate Ii Iolosit si pentru alte sisteme, cum ar Ii cele de modelare a aIacerilor.
UML reprezint o colec|ie de practici ingineresti optime, care au Iost ncununate de succes n
modelarea sistemelor mari si complexe. Dezvoltarea unui model pentru sisteme soItware
industriale nainte de nceperea construc|iei eIective este esen|ial. Modelele bune sunt
absolut necesare pentru comunicarea dintre echipele care lucreaz la acelasi proiect si pentru
asigurarea solidit|ii arhitecturale. Odat cu cresterea complexit|ii sistemului, creste si
importan|a unor tehnici potrivite de modelare. Exist mul|i Iactori suplimentari pentru
succesul unui proiect, dar un Iactor esen|ial este respectarea riguroas a standardelor cu
ajutorul unui limbaj de modelare.
UML nu garanteaz succesul proiectului, dar perIec|ioneaz multe lucruri. De exemplu,
scade n mod semniIicativ costul instruirii n cazul schimbrilor legate de proiecte sau
organiza|ii. Limbajul asigur posibilitatea integrrii instrumentelor, proceselor si domeniilor,
ns mai important este Iaptul c asigur dezvoltatorilor un mod general de rezolvare a
problemelor de concep|ie si planiIicare.
Mai nainte de UML, nu exista un limbaj clar si standardizat de modelare. Utilizatorii
erau nevoi|i s aleag unul dintre multele limbaje similare, cu diIeren|e minore asupra puterii
de expresie. Cele mai multe limbaje mprtseau o serie de concepte unanim recunoscute, care
erau exprimate usor diIerit prin diverse nota|ii. Aceste diIeren|e au Iragmentat industria
92/132
orientat obiect si au descurajat noii utilizatori s nve|e modelarea vizual. De Iapt,
utilizatorii doreau un limbaj standardizat, o ,lingua Iranca a modelrii.
Intre 1989 si 1994 erau Iolosite mai mult de 50 de limbaje de modelare soItware, Iiecare
cu propriile nota|ii. Fiecare limbaje avea elemente de sintax speciIice si n acelasi timp
elemente comune cu alte limbaje. Mai mult, nici un limbaj nu era complet, inginerii soItware
apelnd deseori la mai multe limbaje.
La mijlocul anilor '90 trei metode s-au dovedit mai eIiciente:
- Booch: potrivit mai ales pentru proiectare si implementare, cu dezavantajul
unor nota|ii complicate;
- OMT (Object Modeling Technique): potrivit pentru analiz si sisteme
inIorma|ionale cu multe date;
- OOSE (Object Oriented SoItware Engineering): aceast metod a propus asa-
numitele cazuri de utilizare, care ajutau la n|elegerea comportamentului
ntregului sistem.
In 1994, Jim Rumbaugh, creatorul OMT, a uimit ntreaga comunitate soItware cnd a
prsit General Electric, alturndu-se lui Grady Booch la Ra|ional Corp. Scopul
parteneriatului era combinarea ambelor perspective ntr-o metod uniIicat, n 1995 si Ivar
Jacobson, creatorul OOSE, a venit la Ra|ional, iar ideile lui (n special conceptul de cazuri de
utilizare) au Iost adugate ,Metodei uniIicate"; metoda rezultant a Iost numit ,Limbajul de
modelare uniIicat" - UML. n ciuda disputelor ini|iale, noua metod a nceput s aib din ce
n ce mai mul|i sus|intori n industria soItware, Iormndu-se un consor|iu UML din care
Iceau parte gigan|i precum Hewlett-Packard, MicrosoIt si Oracle.
UML 1.0 a Iost propus spre standardizare n cadrul OMG (Object Management Group)
n ianuarie 1997. Pn la sIrsitul anului 1997 echipa care lucra la UML s-a extins, urmnd o
perioad n care UML a primit o speciIicare Iormal mai riguroas. Versiunea UML l. l a Iost
adoptat ca standard de ctre OMG n noiembrie 1997. n martie 2003 a Iost publicat
versiunea 1.5. n momentul de Ia| se lucreaz la versiunea 2.0.
n UML exist numeroase diagrame (modele), aceasta Iavoriznd existen|a mai multor
puncte de vedere privind sistemul. Dup cum am vzut, procesul de dezvoltare soItware are
multe componente, Iiecare cu propria sa perspectiv: analisti, proiectan|i, programatori,
testeri, echipe de asigurarea calit|ii, autori ai documenta|iei, clien|i. Fiecare dintre acesti este
interesat de un alt aspect al sistemului, la un nivel diIerit de detaliu. De exemplu,
programatorul trebuie s n|eleag arhitectura sistemului pentru a o converti n cod de nivel
sczut. Dimpotriv, autorul documenta|iei trebuie s n|eleag comportamentul global al
sistemului pentru a sti cum Iunc|ioneaz produsul. UML ncearc s rezolve problema
modelrii la toate aceste nivele de detaliu.
8.3 Modelarea cazurilor de utilizare
Un instrument UML Ioarte puternic este reprezentarea cazurilor de utilizare, adic
descrierea mul|imii de interac|iuni dintre utilizator si sistem. Prin construirea unei colec|ii de
cazuri de utilizare, putem descrie ntregul sistem ntr-o manier clar si concis. Cazurile de
utilizare sunt denumite de obicei printr-o combina|ie substantival-verbal, de exemplu:
Plteste Iactura, Creeaz cont etc. Nota|ia pentru un caz de utilizare este prezentat n Iigura
urmtoare:
Figura 8-2 Caz de utilizare
93/132
Un caz de utilizare trebuie s aib un ini|iator al ac|iunii, numit actor. In cazul unui
sistem bancar, retragerea banilor este Icut de clien|i, astIel nct clientul devine unul din
actori:
Retrage bani
Client
Figura 8-3 Caz de utilizare cu actor
Actorii nu sunt numai oameni, ci orice cauz extern care ini|iaz 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 interac|iona cu mai multe cazuri de utilizare, iar un anumit
caz de utilizare poate Ii ini|iat de actori diIeri|i:
Figura 8-4 Cazuri de utilizare cu actori multipli
Desi par Ioarte simple, ignorarea cazurilor de utilizare este o mare greseal. Acestea
sunt Ioarte importante deoarece:
- deIinesc domeniul sistemului, permi|nd vizualizarea dimensiunii si sIerei de
ac|iune a ntregului proces de dezvoltare;
- sunt similare cerin|elor, dar cazurile de utilizare sunt mai clare si mai precise
datorit structurii riguroase de nota|ie;
- suma cazurilor de utilizare este sistemul ca ntreg; ceea ce nu este acoperit de un
caz de utilizare se situeaz n aIara sistemului de construit;
- permit comunicarea dintre client si dezvoltatori, de vreme ce diagrama este
Ioarte simpl si poate Ii n|eleas de oricine;
- ghideaz echipele de dezvoltare n procesul de dezvoltare;
- ajut echipele de testare si autorii manualelor de utilizare.
Se pune problema deIinirii granularit|ii cazurilor de utilizare: ntr-un anumit scenariu,
Iiecare interac|iune utilizator-sistem trebuie s Iie un caz de utilizare sau un singur caz de
utilizare poate ncapsula toate interac|iunile. Pentru un bancomat, scenariul presupune mai
multe interac|iuni: introducerea card-ului, introducerea codului PIN, selectarea sumei dorite,
94/132
conIirmarea ei, scoaterea card-ului, preluarea chitan|ei. Fiecare din acesti pasi trebuie s Iie
cte un caz de utilizare?
Introduce card
Operator
Introduce PIN
Introduce suma
Confirma suma
Ia suma
Ia card
Figura 8-5 Cazuri de utilizare incorecte
Dac pentru un sistem suIicient de complex am urma aceast strategie, ar rezulta un
numr imens de cazuri de utilizare, care nu si-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 satisIac un scop pentru actor.
n exemplul anterior, se poate pune problema: preluarea chitan|ei este un scop al
clientului? Nu neaprat. La Iel se procedeaz si pentru celelalte cazuri de utilizare. Nici unul
nu descrie suIicient de corect scopul clientului, care este de Iapt retragerea unei sume de bani.
Retrage bani
Client
Figura 8-6 Caz de utilizare corect
8.4 Modelarea conceptual. Diagrama de clase
Modelarea conceptual (numit si ,modelarea domeniului") este activitatea de
identiIicare 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 Iurnizeaz structura codului care va Ii scris. Problema principal
este identiIicarea conceptelor. Regula de urmat aici este: dac clientul nu n|elege conceptul,
probabil c nu este un concept.
O clas se reprezint printr-o csu| mpr|it n trei. In partea de sus este notat numele
clasei, n partea median atributele iar n partea de jos opera|iile sale.
95/132
Figura 8-7 Clasa n notaie UML
8.4.1 Asocierea
Urmtorul pas este deIinirea rela|iilor dintre concepte. S presupunem urmtoarele dou
concepte:
Figura 8-8 Concepte nrudite funcional
Dac Iiecare manager conduce o masin n compania respectiv, ntre aceste concepte
exist o rela|ie:
Figura 8-9 Asocierea n notaie UML
Linia simpl n UML are rolul de asociere. Numerele descriu cardinalitatea asocierii,
adic ne spun cte instan|e sunt permise din Iiecare concept. Urmtoarea Iigur prezint
cteva cardinalit|i posibile, desi din punct de vedere al nota|iei nu exist restric|ii asupra
cardinalit|ilor care pot Ii speciIicate.
96/132
Figura 8-10 Cardinalitatea asocierii
O greseal care poate Ii Icut n aceast Iaz este s decidem c exist o rela|ie 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 sti ce nseamn Iiecare si va trebui s o lum de la nceput.
n Iigura urmtoare este prezentat un exemplu de asociere ntre clase:
97/132
Masina
conduce
1
Manager
Pensie
contribuie la
1..*
Angajat
Curs de pregatire
Zi libera
Vacanta
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 Ii 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
98/132
8.4.3 Compunerea
Compunerea este un concept similar cu agregarea, ns mai puternic deoarece implic
Iaptul c un ntregul nu poate exista Ir pr|i. In exemplul de agregare de mai sus, dac se
nltur placa de sunet, calculatorul rmne calculator, ns o carte nu poate exista Ir pagini;
o carte este compus din pagini. Nota|ia este asemntoare, dar rombul este plin:
Pagina Carte
1..*
Figura 8-13 Compunerea n notaie UML
8.4.4 VizibiIitatea atributeIor i opera{iiIor
In Iigura urmtoare sunt prezentate nota|iile pentru vizibilitatea atributelor si opera|iilor
(privat, protejat, public), n mod text si n mod graIic.
Nota|ie Descriere Nota|ie Descriere
Spa|iu de nume Metod sau Iunc|ie
Clasa Operator
InterIa| Proprietate
Structur Cmp sau variabil
Uniune Eveniment
Enumerare Constant
DeIini|ie de tip Element de
enumerare
Modul Element de hart
Intrinsec Declara|ie extern
Delegat Macro
Excep|ie Template
Harta Necunoscut sau
eroare
Global
Nota|ie semnal Descriere Explica|ii
No Signal Icon~ Public Accesibil de oriunde si prin orice component care l reIer
Protejat Accesibil numai din clasa sau tipul care l con|ine sau din
clasele sau tipurile derivate din acestea.
Privat Accesibil numai din clasa sau tipul care l con|ine.
Intern Accesibil numai din aceast component
Prieten Accesibil numai din proiect.
ReIerin| O reIerin| la un obiect.
99/132
Figura 8-14 Vizibilitatea atributelor yi operaiilor
8.4.5 Motenirea
De multe ori, mai multe clase din arhitectur au atribute si opera|ii comune. Acestea pot Ii
introduce ntr-o singur clas si mostenite 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 yi operaii comune
Dac am mai vrea s adugm o clas Pisic, ar trebui s repetm atributele si opera|iile
comune. Solu|ia este mostenirea dintr-o clas mai general. Nota|ia UML pentru mostenire
este urmtoarea:
Figura 8-16 Moytenirea n notaie UML
Trebuie s subliniem c atributul vrst a Iost transIormat din privat n protejat, pentru a
putea Ii mostenit n clasele derivate.
100/132
O greseal Irecvent n proiectarea orientat obiect este utilizarea abuziv a mostenirii,
ceea ce conduce la probleme n ntre|inerea programului. Dac mai multe clase sunt legate de
una singur, schimbrile n clasa de baz vor aIecta si clasele derivate. De asemenea, cnd
derivm o clas trebuie s parcurgem ntreaga ierarhie pentru a vedea ce Iace implicit clasa
respectiv. Aceast problem este cunoscut sub denumirea de proliIerarea claselor.
Mostenirea nu trebuie Iolosit dect ca mecanism de generalizare, adic se Ioloseste
numai dac clasele derivate sunt specializri ale clasei de baz.
De asemenea, toate deIini|iile 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 gresit este urmtorul:
Animal
# varsta
+ mananca()
+ doarme()
+ se joaca()
+ zboara()
Om
- nume
+ munceste()
+ vorbeste()
Figura 8-17 Moytenire incorect
Se poate observa c opera|ia zboar nu se aplic si clasei Om.
8.4.6 PoIimorfismuI
Clasele derivate pot redeIini implementarea unei metode. In exemplul urmtor, clasele
Pian si Vioar sunt derivate din Instrument. Totusi, Iiecare implementeaz metoda cnt n
Ielul su speciIic. Nota|ia n acest caz este repetarea numelui metodei n Iiecare clas.
Figura 8-18 Polimorfismul n notaie UML
101/132
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 Interfe{e
Dac o clas implementeaz o interIa|, ntre cele dou exist o rela|ie de realizare. S
presupunem c Instrument din exemplul precedent e acum o interIa| iar clasele Pian si
Vioar trebuie s implementeze metoda cnt. Nota|ia este asemntoare celei de la
mostenire, dar cu linie punctat, iar interIa|a e declarat explicit. Cuvintele introduse ntre ,"
si ," se numesc stereotipuri, n Iigura 20 se poate observa stereotipul UML interIace.
Figura 8-20 Notaia UML pentru interfee
O nota|ie alternativ este urmtoarea:
nstrument
+ canta()
Pian Vioara
102/132
Figura 8-21 Notaie alternativ pentru interfee
8.4.8 Metode statice
n nota|ia 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
participan|ilor si descrierea modelelor de comunica|ie. Modelul de comunica|ie al instan|elor
care joac un rol pentru ndeplinirea unui anumit scop se numeste interac|iune. Diagramele de
interac|iune au dou Iorme, bazate pe aceleasi inIorma|ii de baz, dar care se concentreaz
Iiecare pe un alt aspect al interac|iunii: diagramele de secven| si diagramele de colaborare.
8.5.1 Diagrama de secven{e
Diagrama de secven|e pune accentul pe aspectul temporal (ordonarea n timp a
mesajelor), Iiind potrivit speciIica|iilor de timp real si scenariilor complexe. Nota|ia graIic
este un tabel care are pe axa X obiecte, iar pe axa Y mesaje ordonate cresctor n timp. Axa Y
arat pentru Iiecare obiect timpul ca o linie vertical punctat (,linia vie|ii" unui obiect, engl.
,liIeline") si perioada n care obiectul preia controlul execu|iei (reprezentat printr-un
dreptunghi) si eIectueaz o ac|iune, direct sau prin intermediul procedurilor subordonate.
In Iigura urmtoare este descris interac|iunea simpliIicat ntre un client si un server.
De remarcat c n diagrama de secven|e utilizm obiecte, nu clase, ntr-un program pot exista
mai multe instan|e ale aceleiasi clase care au roluri diIerite n sistem. Un obiect este
identiIicat de numele su si numele clasei pe care o instan|iaz. Numele obiectului poate s
lipseasc dac nu este semniIicativ pentru n|elegerea comportamentului sistemului. Liniile
orizontale continue semniIic mesaje ini|iate obiecte, iar liniile orizontale punctate reprezint
mesaje-rspuns.
103/132
Figura 8-23 Diagram de secvene
8.5.2 Diagrama de coIaborare
Diagrama de colaborare se concentreaz pe rolurile instan|elor si rela|iile dintre ele. Ea
nu con|ine timpul ca o dimensiune separat, de aceea secven|a de comunica|ii si Iirele de
execu|ie concurente trebuie numerotate.
Figura 8-24 Diagram de colaborare n exemplul de mai sus, asteriscul semnific posibilitatea mai multor
interogri SQL yi a mai multor rezultate.
104/132
8.6 Diagrame de activiti
Diagramele de activit|i sunt Iolosite pentru modelarea proceselor sau a algoritmilor din
spatele unui anumit caz de utilizare. Din multe puncte de vedere, diagrama de activit|i din
UML este echivalentul orientat pe obiect al diagramei Iluxurilor de date din dezvoltarea
structurat.
Nota|ia este urmtoarea:
- nod ini|ial: un cerc plin este punctul de start al diagramei; desi nu este
obligatoriu, prezen|a sa Iace diagrama mai lizibil;
- nod Iinal: un cerc plin nconjurat de un alt cerc; o diagram poate avea 0, l sau
mai multe noduri Iinale;
- activitate: dreptunghiurile rotunjite reprezint activit|ile care au loc;
- Iluxuri: sge|ile diagramei;
- punct Iinal al Iluxului: un cerc cu un X n interior; indic Iaptul c procesul se
opreste n acest punct;
- ramiIica|ie (engl. ,Iork"): o bar neagr cu un Ilux de intrare si mai multe Iluxuri
de iesire; denot nceputul unor activit|i desIsurate n paralel;
- reunire (engl. ,join"): o bar neagr cu mai multe Iluxuri de intrare si un Ilux de
iesire; denot sIrsitul prelucrrilor paralele;
- condi|ie: text asociat unui Ilux, care deIineste o condi|ie care trebuie s Iie
adevrat pentru traversarea nodului;
- decizie: un romb cu un Ilux de intrare si mai multe Iluxuri de iesire; Iluxurile de
iesire includ condi|ii;
- mbinare (engl. ,merge"): un romb cu mai multe Iluxuri de intrare si un Ilux de
iesire; toate Iluxurile de intrare trebuie s ating acest punct pentru ca procesul
s continue;
- parti|ie (engl. ,swimlanes"): o parte a diagramei care indic cine/ce ndeplineste
activit|ile;
- not: o speciIica|ie suplimentar sub Iorm de text.
n Figura 8-25 este prezentat o diagram de activit|i cu decizii. ,Candidatul trebuie s
Iie admis" este o not asociat unei decizii.
Figura 8-25 Diagram de activiti cu decizii
105/132
n Figura 8-26 este prezentat o alt diagram de activit|i, cu parti|ii si ramiIica|ii.
Figura 8-26 Diagram de activiti cu partiii yi ramificaii
106/132
8.7 Diagrame de stri
Obiectele au att comportament, ct si stare intern, cu alte cuvinte, ndeplinesc ac|iuni
si de|in inIorma|ii. Unele obiecte au comportamente Ioarte complexe, care depind Ioarte mult
de starea intern. Pentru a le n|elege, dezvoltatorii utilizeaz diagramele de stri, care descriu
modul de Iunc|ionare a instan|elor.
Diagramele de stri UML descriu diIeritele stri n care se poate gsi un obiect si
tranzi|iile dintre aceste stri. O stare reprezint o etap n modelul comportamental al unui
obiect si, le Iel ca n cazul diagramelor de activit|i, este posibil s avem stri ini|iale si stri
Iinale. O stare ini|ial este cea n care se gseste obiectul cnd este creat. O stare Iinal este o
stare din care nu mai exist tranzi|ii. Tranzi|ia reprezint schimbarea strii, trecerea dintr-o
stare n alta, si poate Ii determinat de un eveniment extern sau intern.
Figura urmtoare prezint un exemplu de diagram de stare pentru nscrierea la un curs
op|ional propus cu un numr limitat de studen|i. Dreptunghiurile rotunjite reprezint stri:
instan|ele clasei Curs pot Ii n urmtoarele stri: Propus, PlaniIicat, Disponibil pentru
nscrieri, Ocupat, nchis pentru nscrieri. Starea ini|ial este notat tot printr-un cerc plin, iar
starea Iinal printr-un cerc plin nconjurat de alt cerc, la Iel ca n diagramele de activit|i
(dovad a consisten|ei modelului).
Figura 8-27 Diagram de stri
n Figura 8-28 putem observa cum strile din Figura 8-27 se grupeaz ntr-o asa numit
superstare, pentru a putea descrie un sistem complex la un nivel superior de abstractizare.
107/132
Figura 8-28 Diagram de stri: superstare
8.8 Diagrama pachetelor
Entit|ile UML pot Ii grupate n pachete - containere logice n care pot Ii plasate
elemente nrudite, ca si directoarele din sistemele de operare. Desi orice entitate UML poate Ii
introdus ntr-un pachet, de obicei rolul pachetelor este de a grupa clase si uneori cazuri de
utilizare nrudite.
ntr-un pachet UML numele elementelor trebuie s Iie unice. Totusi, un avantaj
important al pachetelor este c mai multe clase pot avea acelasi nume dac apar|in unor
pachete diIerite. Dac dou echipei si B lucreaz n paralel, echipai nu va trebui s se
preocupe de con|inutul pachetului echipei 5, cel pu|in din punctul de vedere al denumirilor.
Asadar, utilitatea pachetelor apare deoarece: elementele sistemelor mari pot Ii grupate n
subsisteme mai mici si este permis dezvoltarea iterativ n paralel.
La Iormarea pachetelor trebuie s se |in seama de urmtoarele deziderate. Un pachet
trebuie s aib o Iunc|ionalitate bine precizat, el nu trebuie s ndeplineasc Iunc|ii multiple,
deoarece devine greu de n|eles. De asemenea, dependen|ele dintre pachete trebuie s Iie
minime.
108/132
Figura 8-29 Diagram de pachete
La rndul su, un pachet poate Ii explicitat:
Figura 8-30 Pachet explicitat
8.9 Diagrame de implementare
8.9.1 Diagrama componenteIor
Diagrama componentelor este asemntoare cu diagrama pachetelor, permi|nd
vizualizarea modului n care sistemul este divizat si a dependen|elor dintre module. Diagrama
componentelor pune ns accentul pe elementele soItware Iizice (Iisiere, biblioteci,
executabile) si nu pe elementele logice, ca n cazul pachetelor.
Figura 8-31 Diagram de componente
109/132
8.9.2 Diagrama de Iansare
Diagramele de lansare (engl. ,deployment diagrams") descriu conIigura|ia elementelor
de prelucrare la run-time si componentele soItware, procesele si obiectele care se execut pe
ele. Aceste diagrame sunt graIuri de noduri conectate de asocia|ii de comunicare. Nodurile pot
con|ine instan|e ale componentelor, indicnd Iaptul c acea component ruleaz sau se
execut n nodul respectiv. Nodurile sunt reprezentate prin paralelipipede. Cercurile
reprezint interIe|e, n Iigura 32 este prezentat un exemplu de diagram de lansare pentru o
aplica|ie browser care utilizeaz protocolul TCP/IP pentru accesarea unui server.
Figura 8-32 Diagram de lansare
8.10Concluzii
n aceste cursuri a Iost mai nti argumentat necesitatea unui sistem de nota|ie
standardizat pentru etapele dezvoltrii unui proiect soItware. Apoi au Iost prezentate nota|iile
principale ale limbajului UML: diagramele de clase, de interac|iune, de activit|i, de stri, de
pachete si de implementare.
110/132
9 ImpIementarea
9.1 Introducere
Implementarea este Iaza n care este produs codul corespunztor proiectului Iurnizat de
Iaza anterioar, ndeplinind restric|iile de resurse, acurate|e si perIorman| indicate de
speciIica|ii.
Procesul implementrii este cel mai diIicil de descris, neIiind riguros deIinit.
Implementarea este procesul transIormrii abstractizrii prezentate n proiect ntr-o realizare
Iizic utiliznd limbajul arhitecturii |int. Este o Iaz concretizat ntr-o stare conIuz, deseori
haotic si instabil pentru sistemele soItware complexe, n care coordonarea este diIicil.
O problem major care cauzeaz instabilitatea const n diIicultatea 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 Ii proiectul, este necesar un
oarecare eIort pentru a scrie codul corespunztor, ori aceasta este o surs de erori.
n al doilea rnd, procesul de transIormare proiect-implementare este si mai diIicil cnd
proiectul nu este complet, consistent sau nu comunic exact si inteligibil ceea ce se doreste
din partea sistemului. Erorile de proiectare determin pierderea timpului programatorilor n a
rezolva probleme gresite puse. Acestea sunt erorile de logic si sunt cele mai Irecvente. De
aceea este Ioarte important utilizarea unor metode riguroase pentru prezentarea proiectrii.
In al treilea rnd, unele aspecte sunt n aIara domeniului proiectantului. EIectele exacte
ale utilizrii unui anumit sistem de operare sau limbaj de programare sunt n aIara scopului
proiectantului dar reprezint o important decizie a programatorului.
n cele din urm, implementarea nssi este predispus ctre erori, Iiind un proces
creator uman. Limbajul de programare poate Ii Iolosit incorect, aceasta nsemnnd c un
anumit timp si eIort se vor consuma pentru corectarea acestor erori. Din pcate, corectarea
erorilor nu este o sarcin usoar. S-a constatat c un programator are 50 sanse s descopere
eroarea ntr-un interval de 5-10 linii de cod si numai 20 sanse s o descopere ntr-un
domeniu de 40-50 linii.
Documentele de baz produse n aceast Iaz sunt:
- codul surs si obiect comentate ntr-o Iorm standard sau respectnd anumite
conven|ii;
- pliante (dosare) ale soItware-ului, prezentnd modulele soItware individuale;
- manualul de utilizare a produsului soItware, prezentnd conven|iile utilizate n
programe, o prezentare general a implementrii, descrierea particularit|ilor;
planul pentru coordonarea conIigura|iei;
- planul pentru testarea produsului.
Un aspect important n managementul Iazei de implementare este cel al
managementului conIigura|iei sistemului soItware. Motivul const n Iaptul c produsul se
gseste n diverse Iaze pe msur ce echipele de programatori implementeaz diIerite pr|i ale
sale si nu exist un produs ,ntreg" pn la integrarea tuturor modulelor. De aceea, la anumite
intervale de timp, toate modulele vor Ii reunite Iormnd o anumit versiune a produsului, baza
de la care programatorii vor lucra n continuare. Aceste aspecte au Iost deja detaliate ntr-un
curs anterior.
9.2 Limbaje de programare
n Iaza de implementare se extinde mai nti proiectul din Iaza anterioar la
componentele primitive ale sistemului. Se vor Iolosi aceleasi metode din Iaza de proiectare
(proiectarea structurat, proiectarea orientat obiect, metode Iormale). Urmtorul pas este a
111/132
deIini prelucrarea Iiecrui modul prin metode ca: hr|i de Iluxuri (engl. ,Ilowcharts"),
raIinarea pas cu pas, limbaje de proiectare a programelor, pseudocodul, etc.
Implementarea implic scrierea codului ntr-un limbaj de programare, veriIicarea si
integrarea sa cu alte programe pentru ob|inerea unui sistem Iinal.
O decizie Ioarte 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 si 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 execu|ia programului, el
trebuie s deIineasc modul cum se execut prelucrrile, n general, aceste limbaje suport
caracteristicile programrii structurate:
- secven|a: permite speciIicarea ordinii execu|iei instruc|iunilor;
- selec|ia: permite evaluarea unei condi|ii si luarea unei decizii;
- itera|ia: permite existen|a structurilor repetitive.
O alt caracteristic important este diviziunea n module, care permite descompunerea
Iunc|ional. Limbajele imperative moderne permit realizarea de programe orientate obiect, n
acest caz, programarea structurat poate Ii 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 si
eventual un singur punct de iesire;
- tipizarea puternic: impune ca tipul Iiecrei date s Iie declarat. Acest lucru
previne aplicarea operatorilor asupra obiectelor incompatibile din punct de
vedere al tipului si ajut compilatorul n eviden|ierea erorilor si n compilarea
eIicient;
- recursivitatea: permite unui modul s se autoapeleze. Limbajele orientate obiect
suport toate caracteristicile limbajelor de programare structurat si, n plus:
- mostenirea: este tehnica prin care modulele pot prelua Iunc|ionalit|i de la
modulele de nivel superior;
- polimorIismul: este abilitatea unui program de a lucra cu diIerite tipuri de date
sau de a realiza ac|iuni diIerite pentru instan|e ale unor clase diIerite. Ideal ar Ii
ca un limbaj OO s Iie complet polimorI, astIel nct s nu mai Iie necesare
por|iuni de cod pentru Iiecare tip de dat. PolimorIismul implic suportul pentru
legare dinamic (engl. ,dynamic binding"), adic legarea metodelor obiectelor
de selectarea mesajului n momentul execu|iei si nu al compilrii;
- mesajele: mesajele sunt utilizate pentru implementarea interIe|elor. Un mesaj
con|ine detaliile ac|iunii care trebuie realizat si este trimis de ctre un obiect
ctre un alt obiect pentru a invoca un serviciu al celui din urm.
9.2.2 Limbaje decIarative
Limbajele declarative pornesc cu o concep|ie diIerit de limbajele imperative.
Programatorul nu mai controleaz explicit execu|ia programului, ci speciIic ce trebuie
realizat, care sunt regulile care pot rezolva problema, ns pasii eIectivi de rezolvare a
problemei si ordinea acestora sunt decisi de program, nu de programator. Construc|ia secven|
si pierde din importan| deoarece programul nu mai poate Ii vzut ca o secven| de
instruc|iuni de la nceput pn la sIrsit. Datorit diIeren|ei de abordare, programele scrise n
limbaje declarative apar diIerite Ia| de cele scrise n limbaje imperative.
112/132
9.3 Analiza unor limbaje de programare
9.3.1 C/C++
C/C este Iolosit pe scar larg pentru programarea proIesionist. Acesta combin
virtu|ile unui limbaj de nivel nalt cu eIicien|a limbajului de asamblare. C a Iost dezvoltat de
Dennis Ritchie n 1972 la AT&T's Bell Laboratories si a Iost Iolosit pentru scrierea sistemului
de operare UNIX. Datorit legilor antitrust, Laboratoarelor Bell li s-au interzis drepturile de
autor asupra C-ului si UNIX-ului. De aceea, compilatoarele de C sunt n domeniul public si au
Iost adoptate de majoritatea universit|ilor. Limbajul C a Iost standardizat (ANSI C) n 1990.
n 1981, Bjarne Stroustrup a propus C. C-ul originar este utilizat Ioarte rar, de aceea mul|i
programatori se reIer la C cu termenul de ,C". C con|ine toate elementele de baz ale
C-ului, la care s-au adugat numeroase trsturi de programare orientat obiect. Si C a Iost
standardizat (ISO C) n 1997.
Avantaje:
- EIicien|: C/C pot crea programe mai rapide si cu dimensiuni mai mici dect
aproape orice alt limbaj de programare, cu excep|ia limbajului de asamblare;
- Portabilitate: Un program scris n C/C poate Ii usor copiat si compilat pe alt
calculator, cu unele modiIicri. 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, totusi, acest lucru poate genera conIuzie
si erori;
- Numr mare de programatori: Acest limbaj este cunoscut de Ioarte mul|i
programatori, care ar putea modiIica mai trziu un program existent.
Dezavantaje:
- DiIicil de stpnit: C/C este unul din cele mai diIicile limbaje de programare.
In timpul necesar nv|rii complete a C/C, un program poate Ii deja terminat
n alt limbaj;
- Complexitate: C/C are puterea de a manipula direct memoria si hardware-ul
calculatorului. Acest lucru sporeste sansele apari|iei unei erori si timpul necesar
pentru debug;
- DiIicil de citit si n|eles: Programele sunt create o dat si modiIicate de multe
alte ori. Datorit naturii criptice a C/C, n|elegerea unui program poate ridica
probleme.
Pentru a exempliIica ultima aIirma|ie, orict ar prea de ciudat, urmtorul program C
este corect sintactic:
#include <stdio.h>
#define O (b=b?b-1:(p++,5),*p&1<<b)
#define o O?O
char*p,j=2,b,c;e(n){for(p="|'8I0>+@{=#_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_
~fWU8)75?I#\75?WHN0{jE=]<V*1]JI#5VK)R9A6~J5X9X#69/+VX4 =S%!X-[)OE
#1XRZ\"?~%^-#Dz&M\\RST|%\G66*~&^HV0> {%^-
8_P}%N>FO(}'M^JQ=z&U!:O(J{%&9G4|%ERO(~(WU8)G4{'E=]^G4",b=n;*p++<122||--
b;);c=*p;while(--c>31&&c!=79)putchar(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;}main(){while(++j<15)e(1),e(13+j),e(15),e(j-(j<4));}
si, mai mult, aIiseaz urmtorul text:
113/132
On the Iirst day oI Christmas my true love gave to me
a partridge in a pear tree.
On the second day oI Christmas my true love gave to me
two turtle doves
and a partridge in a pear tree.
On the third day oI Christmas my true love gave to me
three Irench hens, two turtle doves
and a partridge in a pear tree.
On the Iourth day oI Christmas my true love gave to me
Iour calling birds, three Irench hens, two turtle doves
and a partridge in a pear tree.
On the IiIth day oI Christmas my true love gave to me
Iive golden rings;
Iour calling birds, three Irench hens, two turtle doves
and a partridge in a pear tree.
On the sixth day oI Christmas my true love gave to me
six geese a-laying, Iive golden rings;
Iour calling birds, three Irench hens, two turtle doves
and a partridge in a pear tree.
On the seventh day oI Christmas my true love gave to me
seven swans a-swimming,
six geese a-laying, Iive golden rings;
Iour calling birds, three Irench hens, two turtle doves
and a partridge in a pear tree.
On the eighth day oI Christmas my true love gave to me
eight maids a-milking, seven swans a-swimming,
six geese a-laying, Iive golden rings;
Iour calling birds, three Irench hens, two turtle doves
and a partridge in a pear tree.
On the ninth day oI Christmas my true love gave to me
nine ladies dancing, eight maids a-milking, seven swans a-swimming,
six geese a-laying, Iive golden rings;
Iour calling birds, three Irench hens, two turtle doves
and a partridge in a pear tree.
On the tenth day oI 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, Iive golden rings;
Iour calling birds, three Irench hens, two turtle doves
and a partridge in a pear tree.
114/132
On the eleventh day oI 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, Iive golden rings;
Iour calling birds, three Irench hens, two turtle doves
and a partridge in a pear tree.
On the twelIth day oI 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, Iive golden rings;
Iour calling birds, three Irench hens, two turtle doves
and a partridge in a pear tree.
9.3.2 Basic
Basic (Beginner's AII Purpose Symbolic Instruction Code) a Iost dezvoltat la Dartmouth
College n 1964 sub coordonarea lui J. Kemeny si a lui T. Kurtz. Ideea era crearea unui limbaj
Ioarte simplu de nv|at care s serveasc drept treapt intermediar pentru studen|ii care
nv|au Fortran si Algol. Basic a Iost primul produs vndut de MicrosoIt si primul caz major
de piraterie soItware: a Iost copiat si distribuit pe scar larg nc nainte de a Ii lansat (Bill
Gates a pierdut o copie n timpul unei demonstra|ii publice).
Fiind un limbaj de nivel nalt usor de Iolosit, este Ioarte nimerit pentru a preda
Iundamentele programrii nceptorilor si a devenit un limbaj utilizat de mul|i amatori pentru
realizarea de programe simple. La nceput necesita un interpretor, astIel nct nceptorii s
poat crea programul ntr-o manier interactiv, s-1 ruleze, testeze si corecteze. Limbajele
interpretate Iavorizeaz nv|area programrii, dar ruleaz mult mai lent dect programele
compilate. De aceea, programatorii proIesionisti le evit n general. Noile versiuni de Basic
posed compilatoare, cum ar Ii Visual Basic, n care pot Ii create programe de calitate
comercial. Si Basic-ul a Iost standardizat: ANSI Minimal Basic (1978) si ANSI Full Basic
(1987).
Avantaje:
- Usor de nv|at: Poate Ii nv|at si Iolosit mai repede dect majoritatea celorlalte
limbaje;
- Permite prototipizare rapid: n Visual Basic, prototipurile se pot crea repede.
Apoi acestea pot Ii transIormate n programe reale Iunc|ionale. 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 condi|ie important pentru
program, Visual Basic nu este o alegere potrivit;
- Claritate redus: Datorit sintaxei limbajului, programele de mari dimensiuni
devin greu de citit si n|eles;
- InIlexibil: Visual Basic este usor de nv|at, ns ascunde detaliile tehnice ale
programrii. In acelasi timp, mpiedic programatorul s controleze total
calculatorul, ceea ce limiteaz puterea programelor;
- Portabilitate limitat: Visual Basic ruleaz numai pe platIorme Windows.
115/132
9.3.3 PascaI
Este un limbaj de nivel nalt care ncurajeaz programarea modular, bine structurat.
Pascal este acceptat pe scar larg ca limbaj educa|ional si de dezvoltare a aplica|iilor. Este
mai pu|in Ilexibil dect C/C, compilatorul Iace mai multe veriIicri, ns n acest Iel scade
riscul apari|iei erorilor. Avnd la nceput scop didactic, conversiile de tip sunt mult mai stricte
dect n C, ceea ce scade riscul apari|iilor erorilor, dar n acelasi timp scade si Ilexibilitatea,
libertatea si imagina|ia pe care o pot pune n practic programatorii. Limbajul a aprut n
1971, creat de Nicklaus Wirth. Un pas nainte important Ia| de celelalte limbaje existente la
momentul respectiv a Iost Iaptul c suporta recursivitatea.
In prezent, Pascal st la baza mai multor medii de dezvoltare a aplica|iilor comerciale,
cu suport orientat obiect. Borland Delphi (sub Windows) si CodeWarrior Pascal si 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 aplicabilit|ii calculatoarelor pe pia|a produselor electronice n vederea
crerii de produse electronice inteligente care s poat Ii controlate si programate centralizat,
printr-un dispozitiv asemntor cu o telecomand. Aceleasi cerin|e de stabilitate si
independen| n sisteme eterogene existau si pentru Internet. De aceea, desi proiectat ini|ial n
alte scopuri, Java s-a potrivit perIect aplica|iilor world-wide-web.
Sun a prezentat Iormal Java n 1995. In curnd, Netscape Inc. a anun|at c va ncorpora
suport pentru Java n browser-ul lor. Mai trziu, si MicrosoIt a Icut acelasi lucru, ntrind
rolul limbajului Java n zona Internet.
Java apar|ine unei noi genera|ii de limbaje de programare, care si-a cstigat 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 mbunt|easc limbajul. Din acelasi motiv, multe
companii au nc o atitudine de expectativ n legtur cu Java. Totusi, dac portabilitatea este
important, Java este alegerea cea mai bun.
O caracteristic a limbajului este masina virtual (sau interpretorul) care trebuie s
existe pe calculatorul client. Fiecare platIorm are propria masin virtual, care execut de
Iapt programul pe sistemul de operare respectiv. Cnd un program este compilat, rezult un
Iisier de ,byte-codes", Ioarte asemntoare cu instruc|iunile masin, Ir ns a Ii speciIice
unui anumit procesor. Procesul transIormrii ,byte-codes" n cod masin este Ioarte simplu si
se Iace la runtime. Din acest motiv ns, exist clare diIeren|e de perIorman| ntre un
program Java interpretat si 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 scuteste programatorul de
sarcina dezalocrii memoriei alocate dinamic. Aceast trstur Iace programarea mai usoar
si 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) Ir modiIicri
suplimentare;
- Siguran|: Java a preluat trsturile pozitive ale C/C si a evitat multe din
neajunsuri. Neavnd pointeri, programele Java au mai pu|ine sanse de eroare la
accesarea memoriei;
- Bazat pe C/C: Deoarece Java e derivat din C/C, oricine stie C/C poate
nv|a rapid Java.
116/132
Dezavantaje:
- Lent si mai pu|in eIicient: Deoarece este un limbaj interpretat de ctre masina
virtual, programele Java ruleaz mai lent dect programele echivalente n cod
nativ;
- DiIicil de nv|at: Java arat ca C/C, deci este la Iel de greu de nv|at ca si
acesta.
9.3.5 C#
C# este cel mai nou limbaj important de programare, dezvoltat de Anders Hejlsberg la
MicrosoIt. C# este primul limbaj proiectat de la nceput pentru Internet. Este un limbaj
modern care combin cele mai bune caracteristici ale celor mai Iolosite limbaje de
programare. Odat cu C#, MicrosoIt a lansat si platIorma .NET, care permite compilarea si
interIa|area de programe scrise n limbaje diIerite.
C# este Ioarte asemntor n ceea ce priveste sintaxa cu Java, ns pstreaz o apropiere
mai mare de C. Att Java ct si C# compileaz mai nti ntr-un limbaj intermediar: Java
byte-code, respectiv MicrosoIt Intermediate Language (MSIL). n C#, compilarea codului
intermediar n cod nativ este ns mai eIicient. C# are de asemenea un garbage collector, care
s-a demonstrat matematic c este Ioarte aproape de optimul posibil. Ca si Java, C# a renun|at
la mostenirile multiple, n Iavoarea unui model de mostenire simpl extins de mostenirea
multipl a interIe|elor. Spre deosebire de Java, care a renun|at total la pointeri, C# permite
Iolosirea acestora, dar numai n cazuri speciale, marcate ,unsaIe".
Un alt avantaj l constituie posibilitatea generrii automate a documenta|iei pe baza
codului surs.
9.4 Comparaie ntre unele limbaje de programare
Pentru a exempliIica, s considerm implementarea unui algoritm de cutare a
maximului dintr-un sir de numere n timpul introducerii sirului respectiv.
Limbajul C:
#include <stdio.h>
#include <stdlib.h>
void main()
{
int dim, i;
float *vector; // float vector[10];
float max;
printf("Dimensiunea vectorului: ");
scanf("%d", &dim);
vector = (float*)calloc(dim, sizeof(float));
for (i=0; i<dim; i++)
{
printf("Vector[%d]: ", i+1);
scanf("%f", &vector[i]);
if (i==0)
max = vector[i];
else
{
if (max < vector[i])
max = vector[i];
}
}
printf("Maximul: %f", max);
free(vector);
}
117/132
Limbajul C++
#include <iostream.h>
void main()
{
int dim;
cout << "Dimensiunea vectorului: ";
cin >> dim;
float *vector;
vector = new float[dim];
float max;
for (int i=0; i<dim; i++)
{
cout << "Vector[" << (i+1) << "]: ";
cin >> vector[i];
if (i==0)
max = vector[i];
else
{
if (max < vector[i])
max = vector[i];
}
}
cout << "Maximul: " << max;
delete []vector;
}
Limbajul Basic
10 INPUT "Dimensiunea vectorului: ", dimvect
20 DIM vector(dimvect)
30 LET max = O
40 FOR i=l TO dimvect
50 INPUT ("Vector ("; i ; "): "); vector(i)
60 IF i = l THEN LET max = vector(i): GOTO 80
70 IF max < vector(i) THEN max = vector(i)
80 NEXT i
90 PRINT "Maximul: "; max
O versiune adaptat pentru Visual Basic este:
Private Sub Max()
Dim max As Double
Dim dimens As Integer
Dim vector(dimens) As Double
For i = 1 To dimens
If i = 1 Then
max = vector(i)
Else
If max < vector(i) Then max = vector(i)
Next i
End Sub
Limbajul Pascal
program simplu; { Pascal nu este un limbaj case sensitive }
uses crt;
var max: real;
118/132
dim,i: integer;
vector:array[1..10] of real;
begin
writeln('Dimensiunea vectorului: ');
readln(dim);
for i:=1 to dim do
begin
writeln('Vector[', i, ']: ');
readln(vector[i]);
if i=1 then
max := vector[i]
else begin
if max < vector[i] then
max := vector[i];
end;
end;
writeln('Maximul: ', max);
end.
Limbajul 1ava
import java.io.*;
public class Simple
{
public static void main(String[] args)
{
System.out.println("Dimensiunea vectorului: ");
String s = System.in.readLine();
int dim = Integer.parseInt(s);
float[] vector = new float[dim];
float max = 0;
for (int i=0; i<dim; i++)
{
System.out.println("Vector[" + (i+1) + "]: ");
s = System.in.readLine();
vector[i] = Float.parseFloat(s);
if (i==0)
max = vector[i];
else
{
if (max < vector[i])
max = vector[i];
}
}
System.out.println("Maximul: " + max);
}
}
Limbajul C#
using System;
class Simple
{
[STAThread]
static void Main(string[] args)
{
Console.Write("Dimensiunea vectorului: ");
string s = Console.ReadLine();
int dim = int.Parse(s);
float[] vector = new float[dim];
119/132
float max = 0;
for (int i=0; i<dim; i++)
{
Console.Write("Vector[{0}]: ", i+1);
s = Console.ReadLine();
vector[i] = float.Parse(s);
if (i==0)
max = vector[i];
else
{
if (max < vector[i])
max = vector[i];
}
}
Console.WriteLine("Maximul: {0}", max);
}
}
Limbajul Clips (declarativ)
(defrule introd_dim
=>
(printout t "Dimensiunea vectorului: ")
(assert (dim (read)))
)
(defrule init_max
(dim ?)
=>
(printout t "Vector(1): ")
(bind ?val (read))
(assert (vector ?val))
(assert (max ?val))
(assert (i 2))
)
(defrule continue
(dim ?d)
?f1 <- (i ?i)
(test (<= ?i ?d))
?f2 <- (vector $?vect)
?f3 <- (max ?max)
=>
(printout t "Vector(" ?i "): ")
(bind ?val (read))
(retract ?f1 ?f2)
(assert (i (+ ?i 1)))
(assert (vector $?vect ?val))
(if (< ?max ?val) then
(retract ?f3)
(assert (max ?val))
)
)
(defrule print_max
(dim ?d)
(i ?i)
(test (> ?i ?d))
(max ?max)
=>
(printout t "Maximul: " ?max crlf)
)
120/132
Not: gsirea maximului ntr-un sir se poate realiza mult mai usor n Clips:
(defrule max
(vector $? ?v1 $?)
(forall (vector $? ?v2 $?)
(test (<= ?v2 ?v1))
)
=>
(printout t "Maximul: " ?v1 crlf)
)
n primul program s-a ncercat ns implementarea algoritmului secven|ial. Se vede
astIel diIeren|a de concep|ie ntre abordrile imperativ si declarativ.
9.5 Utilitare pentru implementare i testare
O gam larg de utilitare sunt valabile pentru dezvoltarea programelor, depanarea si
testarea acestora:
- Utilitare de modelare (engl. ,modeling tools"): Genereaz nucleul (,scheletul")
modulelor; genereaz automat declara|ii pentru constante, variabile, tipuri pentru
includerea n codul surs al Iiecrui modul. Unele utilitare de modelare pot
transIorma diagramele reprezentnd apelurile modulelor n apeluri de Iunc|ii sau
proceduri complet comentate, desi Ir a avea valorile parametrilor actuali. Dac
asemenea utilitare sunt Iolosite, scrierea codului ncepe prin a completa
,scheletul" unui astIel de modul: se completeaz toate apelurile; se introduc
construc|iile iterative (while, repeat, loop, etc); se introduc construc|iile
alternative (iI, case, etc.) si se adaug n Iinal detaliile de baz ca opera|ii
aritmetice, opera|ii de intrare-iesire si alte apeluri sistem;
- Generatoare de cod: TransIorm rela|ii Iormale n cod surs. Se utilizeaz n
domenii ca gestiunea bazelor de date si interac|iunea cu Iactorul uman, domenii
caracterizate de un cod repetitiv si de necesitatea de a executa numeroase
opera|ii de rutin dar esen|iale. Deoarece generatoarele de cod sunt din ce n ce
mai mult integrate n metodele de proiectare, va Ii posibil de a genera automat
codul surs pentru por|iuni din ce n ce mai mari ale componentelor unui sistem.
Chiar dac pentru pr|i ale sistemului codul va Ii scris manual, utilizarea
generatoarelor de cod rmne n continuare avantajoas. ModiIicri n cerin|ele
soItware pot rezulta n schimbri automate n declara|iile datelor si modulelor,
pstrnd si veriIicnd consisten|a de-a lungul ciclului de via| al produsului;
- Editoare: Creeaz si modiIic codul surs si documenta|ia.
- Editoare senzitive la limbaj: Creeaz cod surs corect din punct de vedere
sintactic. Aceste editoare con|in un interpretor care ajut n scrierea unui cod
surs corect din punct de vedere sintactic. Cele mai simple astIel de editoare
recunosc parantezele si realizeaz o aliniere automat care Iac programul mai
usor de n|eles si reduc erorile. E posibil, de asemenea, de a Iurniza scheme
(tipare) pentru construirea programelor, con|innd headere standard, sec|iuni
obligatorii pentru declararea constantelor si tipurilor de date. Acestea pot Ii
generate automat de utilitarele de modelare. Editoarele care recunosc aceste
scheme pot reduce timpul de dezvoltare si pot preveni erorile;
- Analizoare statice: Examineaz codul surs. Analiza static este procesul de
scanare a textului unui program pentru detectarea unor erori:
o identiIic variabile neutilizate sau utilizate nainte de a Ii asignate;
o veriIic dac valoarea variabilei este n intervalul admis;
o Iurnizeaz o prezentare a structurii aplica|iei;
121/132
o msoar complexitatea codului n termenii unei metrici;
o transIorm codul surs ntr-un limbaj intermediar pentru veriIicare
Iormal;
o msoar anumite atribute ale codului cum ar Ii numrul de linii de cod si
nivelul maxim de imbricare.
Cele mai multe compilatoare Iurnizeaz unele din caracteristicile analizoarelor statice
(cum ar Ii prima caracteristic). Analizoarele statice dedicate de obicei Iurnizeaz Iunc|ii de
analiz static avansate, cum ar Ii analiza structurii codului;
- Compilatoare: TransIorm codul surs n cod obiect. Acestea variaz n vitez,
completitudinea veriIicrilor, usurin|a utilizrii, Iolosirea sintaxei standard,
calitatea codului si aIisrilor si prezen|a caracteristicilor de programare.
Alegerea compilatorului este de importan| crucial. Viteza compilatorului
aIecteaz costul produsului si usurin|a n dezvoltarea, depanarea si ntre|inerea
produsului, n timp ce calitatea codului aIecteaz perIorman|ele produsului n
timpul execu|iei. Compilatoarele ar trebui comparate |innd cont de viteza lor,
de timpul de execu|ie al programului si dimensiunea codului. Dimensiunile
stivei si a memoriei heap pot Ii, de asemenea, importante. Compilatoarele
variaz mult si Iunc|ie de caracteristicile care suport programarea:
o listare complet;
o cross-reIeren|ierea;
o dimensiunea datelor si modulelor;
o diagnosticare;
o veriIicare complet;
o veriIicarea limitelor vectorilor.
Cele mai avansate compilatoare execut anumite optimizri pentru masini secven|iale
sau paralele, ncercnd s descopere si s elimine deIicien|ele codului surs. Aceste optimizri
pot Ii impuse prin switch-uri, de exemplu prin directive n codul surs. Utilizatorii ar trebui s
veriIice dac optimizrile pe care le doresc sunt implementate n compilatoarele candidat.
- Linkeditoare: Reunesc modulele obiect n programe executabile. Acestea sunt
Iurnizate de masin, sistemul de operare sau compilator. De aceea, utilizatorul
are n Ioarte mic msur controlul asupra alegerii acestora. Este util ca
linkeditorul s determine automat bibliotecile si directoarele pe care trebuie s le
utilizeze si care sunt modulele sau componentele care trebuie linkeditate. Cele
mai multe linkeditoare pot Ii controlate de parametri crea|i de utilitare build sau
make;
- Depanatoarele: Localizeaz erori n timpul execu|iei programului. Utilizarea
depanatoarelor simbolice interactive este puternic ncurajat, mai ales pentru
veriIicare. Un depanator bun este integrat cu editorul si
compilatorul/interpretorul si permite o gam de moduri de investigare: pas cu
pas, trasare prin breakpoint, vizualizarea valorilor variabilelor, setarea unor
condi|ii;
- Analizoarele dinamice: Examineaz programele n curs de execu|ie. Analiza
dinamic este procesul de msurare a resurselor (timp CPU, timp intrare-iesire,
memorie) consumate de Iiecare modul si linie de cod. n contrast cu analizoarele
statice, cele dinamice se Iolosesc pentru programe n curs de execu|ie.
Analizoarele dinamice se mai numesc si proIilers. Ele mai pot Ii Iolosite si
pentru a determina dac toate instruc|iunile programului au Iost executate n
timpul testului (test de acoperire). Unele analizoare dinamice veriIic dac
programul utilizeaz corect memoria, de exemplu, veriIic dac apelurile pentru
alocarea memoriei au corespondent n apeluri pentru dezalocare, determinnd
122/132
astIel scprile de memorie (engl. ,memory leaks"). Analizoarele dinamice pot
localiza pr|ile sistemului care cauzeaz slabe perIorman|e ale acestuia si pot
detecta erori de programare (exemplu: ini|ializri inutile);
- Utilitare de test: Testeaz module si programe. Acestea suport una sau mai
multe din urmtoarele Iunc|ii: generarea si gestiunea datelor de test, veriIicarea
automat a rezultatelor, diagnosticarea erorilor si depanarea. Utilitarele generale
de test pot genera un volum mare de date de intrare;
- Procesoare de text: Sunt utilizate pentru crearea documentelor;
- Generatoare de documenta|ie: Genereaz documenta|ie utilizator din codul
surs. Men|in consisten|a dintre cod si documenta|ie si Iac procesul de
documentare concurent cu cel de codare. Generatoarele de cod pot include
utilitare pentru generarea automat a documenta|iei;
- Utilitare pentru managementul conIigura|iei: nregistreaz versiunile modulelor
si Iisierelor. Sunt organizate n baze de date si controleaz dezvoltarea
sistemelor cnd multe module pot exista n diIerite versiuni. Unele utilitare
permit speciIicarea unei conIigura|ii (m module n n versiuni), compilare
automat, linkeditare si arhivare a acestora. Este recomandat Iolosirea
utilitarelor pentru managementul conIigura|iei cnd numrul de module sau de
versiuni devine Ioarte mare.
9.6 Concluzii
In concluzie, procesul de implementare este diIicil de caracterizat si de descris. Aici se
regsesc aspecte ale analizei cerin|elor, ale speciIica|iilor si proiectrii. Programatorul va
trebui s Iac un numr de importante compromisuri ntre siguran|a produsului, costul,
eIicien|a, timpul de execu|ie, posibilitatea lui de ntre|inere, etc. Sarcina cea mai diIicil a
programatorului este de a realiza aceast pluralitate a scopurilor. Este diIicil de a spune care
va Ii rezultatul acestor compromisuri att timp ct produsul nu este complet si testat. Odat ce
produsul a Iost Iinalizat, n sensul c toate pr|ile sale componente au Iost reunite si sistemul
poate Iunc|iona, ncepe etapa urmtoare a procesului de dezvoltare si anume Iaza testrii.
123/132
10 PsihoIogia si etica programrii
10.1Programarea ca activitate uman
, Considerm cu prea mult usurin| programele ca Iiind doar pentru compilare. Ar
trebui s le luam n calcul si ca mijloace de comunicare intre noi si ceilal|i, ca mijloace de
exprimare a propriilor gnduri ctre nou nsine. " (Green, 1990)
In prezent se recunoaste importan|a nevoilor utilizatorului n momentul conceperii
sistemelor interactive dar, pn n 1980, aceste nevoi nu prea au Iost luate n calcul. De ce ar
Ii de dorit introducerea comentariilor n programe? De ce ar Ii mai bine s nu se Ioloseasc
,go to"-uri? De ce conceptul X ar Ii mai bun dect conceptul 7? De ce utilizatorii unui anumit
sistem se simt pierdu|i si se enerveaz, n timp ce utilizatorii unui sistem similar, dar cu o
interIa| graIic diIerit, dimpotriv, lucreaz cu plcere?
Cele mai multe cr|i de programare si inginerie soItware dau propriile rspunsuri
acestor ntrebri. De cele mai multe ori rspunsurile nu sunt deloc Iondate. Argumentele
aduse se bazeaz mai mult pe intui|ie si presupusa experien| a cititorului. Totusi intui|ia nu
este suIicient. Este nevoie de teorii sus|inute de dovezi empirice solide si de experimente
bine puse la punct pentru a se putea gsi rspunsuri Iondate la ntrebri ca cele de mai sus.
Tom Love a introdus termenul de psihologie a programrii pentru a arta ,comuniunea"
dintre psihologie si inIormatic. Psihologia programrii prezint Iactorii umani lega|i de
conceperea si utilizarea programelor, cum ar Ii:
usurin|a cu care programatorii manipuleaz diverse construc|ii ale limbajelor de
programare;
probleme legate de capacitatea de nv|are a programrii;
predispozi|ia spre erori si robuste|ea construc|iilor unui limbaj;
tipurile de erori Icute de programatori;
usurin|a de a utiliza aplica|ii soItware, de exemplu procesoarele de text, de ctre
neini|ia|i;
rolul help-ului on-line.
Primele cercetri empirice despre maniera n care lucreaz programatorii au Iost sever
criticate; nevoia unei metodologii solide pentru aceste experimente a Iost subliniat n mod
repetat, n ultimii ani calitatea experimentelor legate de Iactorii umani a crescut si au Iost
Iormulate cteva teorii utile.
In momentul cnd se Iac experimente, o aten|ie sporit trebuie acordat aplicabilit|ii
ecologice (adic a relevan|ei rezultatelor n cazul generalizrii n situa|ii reale). Aplicabilitatea
ecologic trebuie luat n calcul att atunci cnd e vorba de utilizarea practic a interIe|ei
graIice ct si atunci cnd se Iac studii experimentale asupra comportamentului
programatorului. Factorii care trebuie lua|i n considerare sunt:
Mul|imea subiec|ilor: DiIeren|ele ntre indivizi inIluen|eaz rezultatele ob|inute. Multe
dintre testele aplicate programatorilor au avut drept subiect programatori Ir experien|, de
exemplu studen|i. Alte experimente au artat c aceleasi rezultate nu sunt neaprat valabile si
n cazul programatorilor proIesionisti. Asemenea diIeren|e ntre exper|i si nceptori apar si
atunci cnd se evalueaz interIe|ele graIice. DiIeren|ele de motivare pot avea, de asemenea,
un rol Ioarte important. Utilizatorii reali sunt, de obicei, inIluen|a|i de produc|ie. De exemplu,
ei nu citesc manualele de utilizare; au lucruri mai bune de Icut;
Contextul sistemului: Pentru a testa o anumit construc|ie dintr-un limbaj,
experimentatorii Iolosesc limbaje simpliIicare (,limbaje jucrie", engl. ,toy languages"). Intr-
un caz real, caracteristicile limbajului interac|ioneaz. InterIe|ele utilizator sunt deseori testate
izolat, astIel nct nu este luat n calcul consisten|a cu alte aplica|ii. Nu este Ioarte clar dac
rezultatele astIel ob|inute pot Ii transIerate direct n practicile reale;
124/132
Dimensiunea problemei: Din motive practice, majoritatea testelor Iolosesc aplica|ii
mici, iar problemele care apar sunt clare. Si n acest caz generalizarea la aplica|ii mari si la
probleme vagi se poate Ii pus sub semnul ntrebrii. Aceast situa|ie este cunoscut sub
numele de ,eroarea examenului scolar";
Contextul de lucru: In realitate oamenii sunt deseori conIrunta|i cu suprapunearea mai
multor sarcini (n timp ce ncearc s gseasc o eroare, sun teleIonul).
Programatorii scriu programe. Ei exprim algoritmi Iolosind construc|ii proprii unui
limbaj de programare. Pentru aceasta, trebuie s cunoasc sintaxa si semantica acestor
construc|ii. Mai trebuie s stie cum sa construiasc programe logice din blocurile de
construc|ie pe care le au la dispozi|ie. Cu ct stim mai bine s Iolosim un limbaj de
programare, cu att mai bine vom reusi 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 si s oIere suport. Programatorul trebuie s n|eleag si programele scrise de
altcineva. De multe ori programele sunt mai mult citite dect Iolosite practic.
Un model descriptiv despre modul n care trebuie s-si desIsoare lucrul programatorii
ar trebui s includ toate aceste activit|i prezentate mai sus.
Un model cognitiv al memorie umane distinge trei tipuri de memorie: memoria
senzorial, de scurt durat si de lung durat. Memoria senzorial re|ine pentru un timp
Ioarte scurt inIorma|iile oIerite de sistemul perceptiv, n vederea prelucrrii acestora.
InIorma|iile 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
unit|i. Nu cunoastem cu precizie dimensiunea exact, dar este important de re|inut este c are
o capacitate limitat.
Entit|ile din memoria de scurt durat nu necesit conexiuni cu inIorma|ii elementare.
Oamenii combin inIorma|iile n unit|i ct mai mari. Acest proces este numit chunking, iar
unit|ile de inIorma|ie sunt numite chunks (buc|i, por|iuni). De exemplu, secven|a de ciIre
,234567" poate ocupa 5 intrri n memoria de scurt durat. Totusi, dac este recunoscut ca
Iiind un numr de teleIon, este codat si ocup o singur intrare. AstIel intrrile n memorie
de scurt durat pot Ii vzute ca etichete pentru o anumit inIorma|ie, ca o ciIr, un numr de
teleIon sau o rutin de sortare. Cnd inIorma|ia este prelucrat si manipulat pentru
executarea unor opera|ii, memoria de scurt durat se comport ca o memorie activ, ca si
registrele unui calculator.
InIorma|iile relevante pe termen lung sunt pstrate n memoria de lung durat.
Avnd la baz acest model, apar dou ntrebri importante: ce tip de cunostin|e posed
programatorul n memoria de lung durat si ce tip de procese cognitive apar n vederea
gsirii solu|iei n memoria sa activ? Programatorii proIesionisti de|in un vast si complex
volum de inIorma|ii n memoria de lung durat. Acestea reprezint concepte generale,
neIiind direct legate de un anumit limbaj de programare si privesc att concepte de nivel
sczut (de exemplu atribuirea unei variabile), ct si concepte de nivel nalt (de exemplu un
algoritm de sortare). Acestea sunt cunostin|e semantice.
Memoria de lung durat mai con|ine si cunostin|e sintactice, ca de exemplu Iormatul
construc|iei ,while" din C. Cunostin|ele sintactice sunt arbitrare si deci usor de uitat. E mai
usor de nv|at o structur sintactic atunci cnd structura semantic corespunztoare este deja
cunoscut. Asa se explic Iaptul c nv|area unui prim limbaj de programare se dovedeste
mai diIicil dect nv|area 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 diIerit (de exemplu un limbaj declarativ cum ar Ii CLIPS Ia| de un
limbaj procedural ca C-ul).
125/132
Cunoasterea semantic trebuie nv|at si asimilat. Cunostin|ele sintactice pot Ii
stpnite prin simple exerci|ii. Aceste dou tipuri de cunostin|e nu sunt integrate mpreun n
memorie. De exemplu, n|elegerea sensului unei sarcini nu este legat neaprat de modul n
care aceasta este transpus ntr-un anumit limbaj de programare.
Si inIorma|iile din memorie de lung durat pot Ii descompuse din punctul de vedere al
domeniilor la care se reIer. Pe lng cunostin|e inIormatice, un programator cunoaste, de
asemenea, unul sau mai multe domenii de aplicabilitate. Cnd avem de-a Iace cu probleme
concrete, cunostin|ele din diIerite domenii sunt Iolosite pentru a ob|ine un rezultat.
Pentru a Iinaliza acest model, trebuie s investigm procesul rezolvrii problemelor
asociat cu sarcina programatorului. Deosebim aici patru etape n rezolvarea unei probleme:
n|elegerea problemei;
realizarea unui plan, descoperirea unei strategii de ob|inere a solu|iei;
executarea planului;
veriIicarea rezultatelor.
Dac unui programator i se d o problem, presupunem c acesta Ioloseste mai nti
memoria de scurt durat pentru a re|ine speciIica|iile. Cnd problema este analizat, sunt
Iolosite si inIorma|ii generale din memoria de lung durat. Acesti sunt primii pasi spre
ob|inerea solu|iei.
In a doua etap se utilizeaz tehnici de raIinare pas cu pas si proiectarea top-down sunt
sus|inute. Folosind raIinarea pas cu pas, este Iormulat mai nti o prim solu|ie, pe plan
general. Apoi, problema este mpr|it n una sau mai multe subprobleme, pentru care se caut
solu|ii.
Devierea de la proiectarea top-down este o consecin| a proiectrii deIectuoase. Totusi,
o descompunere top-down absolut este doar un caz particular, atunci cnd solu|ia se cunoaste
precis. In practic, programatorii trec repede de la un nivel de abstractizare la altul. Dac
recunosc o solu|ie par|ial a unei pr|i a problemei, ei ncep un Iaz de proiectare detaliat
pentru implementarea solu|iei respective. Invers, dac dezvoltarea unei solu|ii conduce la
descoperirea unor cerin|e suplimentare, acestea pot deveni centrul aten|iei.
O teorie interesant (Soloway, 1986) sus|ine c programatorii rezolv problemele
Iolosind planuri de programare, Iragmente de program care corespund unor ac|iuni stereotipe
si reguli care descriu conven|ii de programare. De exemplu, pentru a calcula suma unui sir de
numere, progrmatorul utilizeaz un contor-sum care este ini|ializat cu O si la care, n cadrul
buclei, se adun urmtoarea val orare din sir. Planurile de programare sunt legate de conceptul
de jalon. Jaloanele sunt cunostin|e care indic prezen|a unei anumite structuri sau opera|ii. De
exemplu, o idee Iundamental n rutinele de sortare este interschimbarea a dou valori. Dac
ni se prezint un program care con|ine opera|ii de interschimbare, imediat ne gndim c ar
putea Ii un program de sortare.
Experimentele eIectuate (Wiedenbeck, 1991) au artat c programele de sortare care
con|ineau opera|ii de interschimbare explicite sunt mult mai usor recunoscute ca atare dect
programele n care interschimbarea este mascat. S-a constatat c prezen|a jaloanelor Ialse
induc n eroare programatorii. Programatorii experimenta|i se bazeaz mai mult pe prezen|a
jaloanelor dect nceptorii. Acest Iapt reIlect asocierea mai puternic a jalonului cu un
anumit tip de program, datorit experien|ei. De asemenea, exper|ii ncearc s ,recunoasc"
pr|i mari din program, s n|eleag ideea din program, Ir s ia n calcul detaliile.
10.1.1 Scrierea programeIor
Aproape toate textele despre programare con|in sIaturi menite s creasc n|elegerea
programelor. Aceste sIaturi privesc probleme ca: adugarea comentariilor, numele sugestive
ale variabilelor, alinierea etc. Ne putem ntreba n ce circumstan|e aceste sIaturi vor produce
rezultate mai bune. Ce ne intereseaz este eIectul acestor indica|ii perceptive n n|elegerea
126/132
programelor. Cnd studiem codul unui program, construim o structur semantic intern care
s corespund programului. Elementele men|ionate mai sus usureaz procesul.
10.1.1.1 Comentariile
Exper|ii nu sunt ntru totul de acord cu Ielul si volumul de comentarii ce trebuie incluse
n codul surs. Orice carte de programare ne va spune s documentm programele create, desi
acestea pot avea si eIecte negative. De multe ori comentariile nu sunt rescrise n momentul
modiIicrii codului. AstIel, comentariile mai vechi pot s induc n eroare cititorul.
Shneiderman (1980) prezint un experiment n care 62 de studen|i 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 Iunc|ionalitatea programului. Cel de-al doilea
grup (L) a primit un cod avnd comentarii detaliate pentru instruc|iunile Iolosite. Ambelor
grupuri li s-a cerut s Iac mici schimbri asupra programului. De asemenea, li s-a mai dat si
un test de memorie: ct de multe linii pot Ii reproduse. La ambele teste, grupul H a ob|inut
punctaj mai mare dect L.
WoodIield (1981) a studiat legtura ntre modularitate si comentarii. Pentru acest
experiment au Iost testa|i, n mare parte, programatori experimenta|i. WoodIield a Iolosit
patru variante ale unui program de 100 de linii: o variant monolitic Iormat dintr-un singur
modul, dou variante Iolosind descompunere Iunc|ional, si o variant bazat pe abstractizare.
Toate versiunile avnd comentarii au ob|inut un scor mai bun dect cele Ir. Totusi, pentru
versiunea monolitic, diIeren|ele au Iost mici. Versiunea abstract a ob|inut perIorman|ele
cele mai bune.
Comentariile nu sunt stocate n structura semantic intern construit. Ele doar conduc
la o ob|inere mai usoar a acesteia. Programatorii nceptori sunt mai aten|i la comentarii
dect cei experimenta|i. Pentru programe scurte, proIesionistii nu au nevoie de comentarii,
mai ales dac structura programului poate Ii ob|inut prin alte mijloace. De exemplu, se pot
Iolosi nume mnemonice, care sunt suIiciente pentru a determina structura semantic a
programului. Cnd numele nu au n|eles, comentariile reprezint singurul ajutor. Combina|ia
ntre nume Ir sens si programe monolitice poate explica diIicult|ile pe care le ntmpin
programatorii.
Comentariile care explic Iunc|ionalitatea sunt preIerate 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 Iolosim terminologia domeniului, pentru a micsora diIeren|a dintre
problem si domeniul programului. De exemplu, este mai bine s Iolosim
// Caut studentul cu media cea mai mare
dect
// Caut cea mai mare valoare din tabel
10.1.1.2 Numele variabilelor
Dac ne conIruntm cu un program n care variabilele sunt numite P, Q, si R, vom
ntmpina diIicult|i n a n|elege semniIica|ia lor. Pe de alt parte, mnemonice de Iorma cont
sau Iactur reIlect un anumit rol semantic si determin o legtur direct ctre ceea ce
reprezint ele. Asadar, mnemonicele Iaciliteaz procesul de n|elegere. Totusi, dac cel care
citeste programul cunoaste deja algoritmul, numele variabilelor nu mai prezint o importan|
deosebit.
127/132
10.1.1.3 Indentaia
Indenta|ia (engl. spa|iere, zim|uire) se reIer la determinarea distan|ei Ia| de margine
(n caractere albe) a liniilor de program, astIel nct s poat Ii puse n eviden| anumite
structuri ale programului.
Scopul indenta|iei este cresterea lizibilit|ii codului. Stilul indenta|iei poate diIeri
considerabil, chiar dac este Iolosit acelasi limbaj de programare. Mul|i programatori si-au
dezvoltat propriul stil de aliniere. Ei Iolosesc acest stil cnd citesc programe sau cnd si
construiesc structura intern corespunztoare. Cnd sunt conIrunta|i cu un program cu o
indenta|ie diIerit, Iorma vizual diIerit poate stnjeni, cel pu|in la nceput, n|elegerea
codului.
In prezent exist si alte mijloace de punere n eviden| a structurii unui program. De
exemplu, cuvintele cheie pot Ii scrise cu litere aldine iar comentariile cu litere cursive.
10.1.2 Concepte aIe IimbajeIor de programare
n paragraIul anterior am discutat cteva probleme de nota|ie independente de limbajul
de progrmare Iolosit. Acum vom vorbi despre concepte speciIice limbajelor de programare.
O ipotez din lingvistic aIirm c modul nostru de gndire este ngrdit de limbajul n
care ne exprimm. Reciproc, modul nostru de a gndi limiteaz utilizarea limbajului.
Construc|iile limbajului ar trebui, de asemenea, s Iie adaptate la sarcinile care trebuie
ndeplinite de ctre programator. De exemplu primele limbaje de programare oIereau doar o
singur construc|ie pentru itera|ie. Limbajele recente oIer mai multe variante: ,Ior", ,while".
Totusi resim|im n continuare nevoia de a iesi dintr-o bucl de la mijloc, deoarece acest lucru
corespunde aproape perIect modului nostru de gndire. Limbajele de programare ar trebui
concepute n asa Iel nct s Iaciliteze o exprimare ct mai natural a algoritmilor.
Cercetrile experimentale reIeritoare la problemele de nota|ie s-au ocupat si de
structurile decizionale. Ele au artat c sunt preIerate construc|iile ,iI-then-else" Ia| de
construc|iile ,iI-goto", deoarece sunt mai usor de Iolosit. Construc|iile din prima categorie
sunt si mai usor de indentat, si astIel codul devine mai usor de citit si n|eles. De asemenea,
Iiind construc|ii de nivel mai nalt, ele sunt mai pu|in complexe.
Cnd se pune problema depanrii codului, prezen|a instruc|iunilor ,goto" creste
diIicultatea procesului si a timpul necesar realizrii sale. Un experiment realizat de Benander
(1990) a eviden|iat 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 Ir ,goto";
Timpul mediu pentru depanarea programelor cu ,goto"-uri era mai mare dect cel al
programelor Ir ,goto".
Acest tip de experiment demonstreaz c alegerea structurilor de control, structurate sau
nestructurate, are o importan| major. Aceast experien| sus|ine anecdota care spune c
numrul de erori pe care le are un program este direct propor|ional cu numrul de ,goto"-uri.
Totusi, un program Ir goto-uri nu este obligatoriu Ir erori.
Un alt rezultat important este Iaptul c utilizarea structurilor si claselor creste gradul de
abstractizare al programului, cu eIecte beneIice asupra n|elegerii. AstIel se explic si tendin|a
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. Totusi, atunci cnd dimensiunea
programelor creste, tehnica modularizrii devine Ioarte important, iar modiIicrile sunt mult
mai rapide dect n cazul programelor monolitice echivalente.
128/132
10.1.3 Interfa{a cu utiIizatoruI
Un sistem n care interac|iunile apar la un nivel inteligibil pentru utilizator va Ii 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 Ioarte posibil ca
utilizatorii (mai ales nespecialisti) s nu-1 accepte. De aceea, n multe cazuri, interIa|a cu
utilizatorul necesit mai mult de 30 din cod, deoarece este un Iactor critic pentru succesul
sau esecul sistemului respectiv.
Exist trei Iactori care inIluen|eaz interac|iunea dintre utilizatorul uman si calculator:
Modelul mental al utilizatorului: Este modelul masinii pe care l creeaz utilizatorul, pe
baza educa|iei si cunostin|elor despre sistem sau domeniul aplica|iei. In timpul interac|iunii cu
sistemul, acest model este utilizat pentru a planiIica ac|iunile, pentru a prezice si interpreta
reac|iile sistemului. Modelul mental reIlect n|elegerea utilizatorului asupra a ceea ce con|ine
sistemul, cum Iunc|ioneaz acesta si de ce. Modelul este determinat ini|ial de meta-
comunicare, adic instruire si documentare. El evolueaz n timp, pe msur ce utilizatorul
dobndeste o n|elegere 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 interac|iune, Iorma si con|inutul schimbului inIorma|ional,
chiar si aspectul Iizic al sistemului, dispozitivele externe conectate etc.;
Modelul conceptual: Este modelul precis din punct de vedere tehnic creat de
proiectan|i, o reprezentare complet a sistemului asupra tuturor aspectelor legate de
interac|iunea cu utilizatorul. Pe baza acestui model reac|ioneaz sistemul la ac|iunile
utilizatorului.
Problema Iundamental a realizrii unei interIe|e ntre om si 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. Interac|iunea om-calculator trebuie s aib aceeasi structur, pe
ct posibil. Dac o anumit ac|iune este perceput ca o singur unitate conceptual n
domeniul sarcinii, este derutant ac|ionarea unui ntreg sir de comenzi pentru a realiza eIectul
dorit. De asemenea, sarcinile care sunt apropiate n domeniul problemei (adic sunt conectate
semantic) trebuie s Iie apropiate si n interac|iunea cu sistemul computerizat.
Inginerii programatori sunt nclina|i s modeleze interIa|a cu utilizatorul dup structura
mecanismului de implementare si nu dup structura domeniului problemei. De exemplu, un
program poate solicita introducerea secven|ei , T10 2" pentru a ob|ine IO2, doar pentru c
sistemul recunoaste si prelucreaz mai usor prima variant, n acelasi Iel, documenta|ia
urmreste de multe ori detaliile si modelele de implementare, iar mesajele de eroare sunt
Iormulate n termeni care reIlect punctul de vedere al programatorului si nu problemele
utilizatorului. Pe lng cunostin|ele speciIice sarcinii, cunostin|ele generale joac de
asemenea un rol important n construirea modelului mental. Dac o combina|ie de taste
,CTRLJ" ntr-un editor de text mut cursorul cu o linie mai jos, utilizatorul poate deduce c
apsarea ,CTRLS" mut cursorul cu o linie mai sus. Dac ns aceast combina|ie are ca
eIect stergerea Iisierului, acest lucru va produce conIuzie si Irustrare.
Noile cunostin|e sunt integrate cunostin|elor existente. Limitrile memoriei de scurt
durat si aten|iei joac si ele un rol. Secven|ele lungi de comenzi, meniurile cu un mare numr
de elemente, nesiguran|a asupra ,locului unde ne aIlm" au ca eIect stnjenirea interac|iunii.
Aceste aspecte sunt cunoscute sub denumirea de ncrcare cognitiv. Pe msur ce ncrcarea
cognitiv creste, sistemul devine mai greu de nv|at, utilizatorul oboseste mai repede si
ncepe s Iac mai multe greseli.
129/132
De Iiecare dat cnd omul ncepe s nve|e ceva, el traverseaz o curb de nv|are.
Acelasi Ienomen apare si n cazul unui program. Viteza cu care utilizatorul traverseaz curba
de nv|are corespunztoare programului si devine expert este o msur important a
complexit|ii acelui program. Aceast msur este n acelasi timp un indicator mai bun al
utilizabilit|ii sistemului dect no|iuni subiective precum ,interIa| prietenoas".
O alt problem este consisten|a interIe|ei. Aceasta nu trebuie dus la extrem, n unele
cazuri, trebuie realizat un compromis ntre consisten| si Iunc|ionalitate. S considerm un
exemplu n care consisten|a a Iost sacriIicat n Iavoarea unei scheme care reIlect mai bine
sarcinile utilizatorului. In Iigura l, sunt prezentate dou conIigura|ii posibile pentru tastele
sge|i. Modelul stea este un model consistent. Totusi, studiile eIectuate au artat c T-ul ntors
este cea mai utilizabil conIigura|ie. Creatorii de jocuri pe calculator cunosc acest lucru de
mult timp. De aceea, si n jocurile mai vechi tastele Iolosite pentru direc|ii erau, de exemplu,
W, A, S, D si nu W, A, Z, S.
Figura 1. Dispunerea tastelor sge|i
Pe msur ce utilizatorul traverseaz curba de nv|are, mai devreme sau mai trziu el
atinge un nivel acceptabil pentru el la momentul respectiv, desi nu este nc expert. Acest
Ienomen apare la un mare numr de aplica|ii. De exemplu, majoritatea utilizatorilor de Linux
cunosc bine numai o submul|ime a comenzilor disponibile. Despre o alt submul|ime de
comenzi au doar o idee vag, ns nu le cunosc exact Iunc|ionalit|ile. Despre restul de
comenzi, utilizatorii respectivi nu au auzit.
Prin instruire si documentare, utilizatorul si construieste mai nti o imagine despre
Iacilit|ile oIerite de sistem si apoi ncearc s realizeze ceva practic ct mai devreme, nainte
s aib o n|elegere deplin asupra sistemului. Dac nu beneIiciaz de ajutor n continuare,
sunt mari sansele s nu n|eleag niciodat no|iunile respective.
Pentru submul|imea de comenzi abia cunoscute, se recomand un sistem de help pasiv,
on-line sau oII-line (sub Iorm de documenta|ie). Pentru comenzile necunoscute de utilizator,
se recomand un help activ, care s-1 ndrume pe utilizator si s-i explice noile no|iuni
necunoscute ntlnite.
Pentru realizarea interIe|ei graIice cu utilizatorul, se recomand urmtoarele principii de
proiectare: a) Dialog simplu si natural: Dialogurile nu trebuie s con|in inIorma|ii irelevante.
Fiecare unitate suplimentar de inIorma|ie concureaz cu alte unit|i relevante pentru
atragerea aten|iei. InIorma|iile trebuie s apar ntr-o ordine logic si natural;
b) Limbaj potrivit utilizatorului: Dialogurile trebuie s utilizeze concepte si Iraze
Iamiliare utilizatorului. Dialogul nu trebuie exprimat n termeni lega|i de calculatoare;
c) Minimizarea ncrcrii mnezice: Utilizatorul nu trebuie s Iie nevoit s re|in
inIorma|ii dintr-o parte a dialogului n alta. Trebuie s existe modalit|i simple de a descoperi
ce trebuie Icut n continuare, unde se poate ntoarce si unde s primeasc instruc|iuni
generale de utilizare;
d) Consisten|: Utilizatorii nu trebuie s se ntrebe dac anumite cuvinte diIerite
nseamn acelasi lucru;
e) Feedback: Sistemul trebuie s inIormeze permanent utilizatorul asupra a ceea ce se
ntmpl. Chiar dac unele ac|iuni necesit mai mult timp, utilizatorul trebuie s dispun de
un indicator (de exemplu procentual) care s-1 inIormeze despre progresul ac|iunii;
130/132
I) Iesiri marcate clar: Utilizatorii Iac greseli si pot alege Iunc|ii nepotrivite. Trebuie s
existe o modalitate prin care acestia s poat iesi din starea nedorit Ir a Ii nevoie de un
lung dialog cu sistemul;
g) Scurtturi (engl. ,shortcuts"): Utilizatorii nceptori nu sunt incomoda|i de
dialogurile ample, deoarece se simt n siguran| si astIel pot nv|a mai usor sistemul.
Utilizatorii experimenta|i nu mai au nevoie de asa ceva, se simt chiar incomoda|i n astIel de
situa|ii si de aceea sistemul trebuie s le permit s sar peste pasii bine cunoscu|i;
h) Mesaje de eroare potrivite: Mesajele de eroare trebuie exprimate n limbaj natural si
nu trebuie s se reIere la starea intern a sistemului. Ele trebuie s speciIice clar eroare si s
propun solu|ii de rezolvare;
i) Prevenirea erorilor: Este mai bine ca sistemul s previn eventualele erori. De
exemplu, dac utilizatorul doreste s prseasc programul, sistemul trebuie s-1 ntrebe dac
vrea sasi salveze mai nti datele.
10.2Etica programrii
Programarea este rezultatul unui comportament uman inten|ionat, realizat de persoane
cu anumite valori (si deci etic). Tehnologia nu este neutr din punctul de vedere al valorilor.
Chiar si scrierea unui program simplu presupune, ntr-un anumit Iel, valorile programatorului.
Mai mult, programele sunt mijlocare de comunicare, codul surs este o Iorm de exprimare.
In consecin|, prin codul scris, programatorii au ocazia s-si comunice valorile.
10.2.1 CoduI etic IEEE
Un exemplu de cod etic este cel al IEEE (The Institute oI Electrical and Electronics
Engineers, 1990), care con|ine 10 puncte:
a) acceptarea responsabilit|ii de luare a deciziilor ingineresti n conIormitate cu
siguran|a, sntatea si bunstarea public si dezvluirea prompt a Iactorilor care ar putea
pune n pericol oamenii si mediul;
b) evitarea conIlictelor de interese reale sau percepute ori de cte ori acest lucru este
posibil si dezvluirea lor ctre pr|ile implicate atunci cnd asemenea conIlicte exist;
c) corectitudinea si realismul cerin|elor sau estimrilor bazate pe date disponibile;
d) respingerea mitei sub toate Iormele ei;
e) perIec|ionarea n|elegerii tehnologiei, aplica|iilor sale adecvate si a consecin|elor
poten|iale; I) men|inerea sau perIec|ionarea propriei competen|e tehnice si asumarea
rspunderii pentru sarcinile care i privesc pe al|ii numai n cazul caliIicrii prin instruire sau
experien| sau dup dezvluirea complet a limitrilor legate de acestea;
g) cutarea, acceptarea si acordarea de critici oneste ale lucrrilor tehnice, recunoasterea
si corectarea erorilor si creditarea adecvat a contribu|iilor altora;
h) tratarea neprtinitoare a tuturor persoanelor, Ir a |ine seama de Iactori precum ras,
religie,
sex, handicap, vrst sau na|ionalitate; i) evitarea deIavorizrii altora, a propriet|ii,
reputa|iei sau serviciului lor prin ac|iuni incorecte
sau ruvoitoare; j) asisten|a acordat colegilor n dezvoltarea lor proIesional si n
respectarea prezentului cod
de etic.
10.2.2 Legea drepturiIor de autor
In Romnia, legea drepturilor de autor (numrul 8 din 14 martie 1996) recunoaste si
garanteaz dreptul de autor asupra operelor de crea|ie intelectual, literar, artistic sau
stiin|iIic, incluznd si programele de calculator.
131/132
Ca si alte opere protejate, precum scrierile literare, operele de art plastic, operele
cinematograIice, programele pentru calculator sunt opere de crea|ie intelectual, care nu sunt
rezultate ale unei munci mecanice, executate cu mijloace tehnice obisnuite sau cu ajutorul
unor cunostin|e ce stau la ndemna oricui. Programele de calculator sunt opere de crea|ie
intelectual, a cror valoare nu este dat de suportul material pe care programul n sine este
Iixat si nici de munca depus pentru realizarea acestor suporturi (de exemplu dischete,
CDROM-urile). Valoarea protejat de lege este chiar crea|ia intelectual original
concretizat n programul pentru calculator si n materialele asociate, precum manualele de
utilizare.
Legea romn protejeaz programele de calculator independent de valoarea si destina|ia
lor concret. Protec|ia acordat de lege nu se opreste numai la obiectul dreptului de autor. Este
protejat deopotriv si titularul acestui drept, autorul programului de calculator respectiv.
Autorul programului are dreptul de a decide dac, n ce mod si cnd va Ii utilizat opera sa,
inclusiv de a consim|i la utilizarea operei de ctre al|ii. Acest drept se reIer la autoriza|ia de
reproducere integral sau par|ial a programului de calculator si la diIuzarea acestuia.
Consim|mntul pe care titularul dreptului de autor l d unei persoane pentru a putea
reproduce, Iolosi, diIuza sau importa copii ale unui program de calculator, se concretizeaz n
practic n licen|e. Ele sunt documentele care probeaz c reproducerea, Iolosirea, diIuzarea
unui program de calculator de ctre o anumit persoan s-a realizat cu consim|mntul
autorului.
Lipsa licen|elor echivaleaz cu lipsa autorizrii din partea autorului. Importan|a acestor
licen|e este evident, ntruct desIsurarea activit|ilor men|ionate Ir aceste licen|e
reprezint inIrac|iuni, 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 inIrac|iune mai grav.
10.2.3 Licen{a pubIic generaI GNU
Licen|ele majorit|ii programelor sunt concepute pentru a priva utilizatorul de libertatea
de a modiIica si distribui programele respective. In contrast, inten|ia Licen|ei Publice
Generale GNU este de a garanta libertatea de a distribui si modiIica programele si de a se
asigura c programele sunt libere pentru to|i utilizatorii. Libertatea programelor nu implic
neaprat absen|a costului. Licen|a GNU este conceput pentru a garanta libertatea de a
distribui copii ale programelor libere (si de a oIeri acest serviciu contra cost, dac se doreste
acest lucru dori|i), de a ob|ine codul surs, de a schimba programul sau a Iolosi por|iuni din el
n noi programe libere.
Pentru protec|ia autorilor, licen|a asigur Iaptul c nu exist nici un Iel de garan|ie
pentru un program liber. Dac programul este modiIicat de altcineva si distribuit mai departe,
beneIiciarii programului trebuie s stie c ceea ce au nu este originalul, n asa Iel nct nici o
problem introdus de altcineva nu va avea un eIect negativ asupra reputa|iei autorilor ini|iali.
Orice program liber este n mod constant amenin|at de patentele soItware. Licen|a GNU
doreste evitarea pericolului ca cei ce redistribuie programe libere s ob|in patente, practic
transIormnd programul ntr-unul aIlat sub controlul total al persoanei sau institu|iei ce de|ine
patentul (engl. ,proprietary"). Pentru a preveni aceast situa|ie, licen|a GNU consider c
orice patent trebuie acordat Iie n asa Iel nct s poat Ii Iolosit gratuit si Ir restric|ii de
oricine, Iie deloc.
Dintre termenii si condi|iile licen|ei GNU, men|ionm:
Pute|i copia si distribui copii nemodiIicate ale codului surs al Programului n Iorma n
care l primi|i, prin orice mediu, cu condi|ia s speciIica|i vizibil pe Iiecare copie autorul si
lipsa oricrei garan|ii, s pstra|i intacte toate notele reIeritoare la aceast Licen| si la absenta
oricrei garan|ii si s distribui|i o copie a acestei Licen|e cu Iiecare copie a Programului.
132/132
Pute|i pretinde o retribu|ie Iinanciar pentru actul Iizic de transIer al unei copii, si pute|i oIeri
garan|ie contra cost.
Pute|i eIectua modiIicri asupra copiilor Programului (sau asupra oricror por|iuni ale
sale), crend astIel un "proiect bazat pe Program". Copierea si distribuirea unor asemenea
modiIicri sau proiecte se pot Iace conIorm termenilor sec|iunii precedente (1), doar dac
toate condi|iile urmtoarele sunt ndeplini te:
o Toate Iisierele modiIicate trebuie s con|in note Ioarte vizibile men|ionnd Iaptul c
dumneavoastr le-a|i modiIicat, precum si data Iiecrei modiIicri;
o Orice proiect pe care l distribui|i sau publica|i, care n ntregime sau n parte con|ine
sau este derivat din Program (sau orice parte a acestuia), trebuie s poat Ii Iolosit de oricine,
gratuit si n ntregime, n termenii acestei Licen|e;
o Daca programul modiIicat citeste comenzi n mod interactiv, trebuie s l modiIica|i n
asa Iel nct atunci cnd este pornit n mod interactiv s aIiseze un mesaj reIeritor la drepturile
de autor precum si o not men|ionnd lipsa oricrei garan|ii (sau s men|ioneze Iaptul c
dumneavoastr oIeri|i o garan|ie).
Pute|i copia si distribui Programul (sau un proiect bazat pe el, conIorm Sec|iunii 2) n
Iormat obiect sau executabil conIorm termenilor Sec|iunilor l si 2 de mai sus, cu condi|ia s
ndeplini|i una dintre condi|iile de mai jos:
o S l oIeri|i nso|it de codul surs corespunztor, n Iormat citibil de ctre masin, care
trebuie s Iie distribuit n termenii Sec|iunilor l si 2 de mai sus pe un mediu de distribu|ie
uzual transportului de soItware; sau
o S l oIeri|i nso|it de o oIert scris, (valid pentru cel pu|in trei ani, pentru o tax
care s nu depseasc costul Iizic al eIecturii distribu|iei sursei), de a oIeri o copie complet,
n Iormat citibil de ctre masin, a codului surs, distribuit n termenii Sec|iunilor l si 2 de mai
sus, pe un mediu de distribu|ie uzual transportului de soItware; sau
o S l oIeri|i nso|it de inIorma|ia pe care a|i primit-o reIeritoare la oIerta de a distribui
codul sursa corespunztor. (Aceast alternativ este permis numai pentru distribuiri
necomerciale si doar dac a|i primit programul n Iormat obiect sau executabil mpreun cu
aceast oIert, n conIormitate cu Sub sec|iunea b de mai sus.)
Deoarece programul este oIerit sub o licen| ce nu implic nici un cost, nu exist nici o
garan|ie pentru program, n msura permis de legile ce se aplic. Exceptnd situa|iile unde
este speciIicat altIel n scris, de|intorii drepturilor de autor si/sau alte pr|i implicate oIer
programul ,n Iorma existent" Ir nici o garan|ie de nici un Iel, explicit sau implicit,
incluznd, dar Ir a Ii limitat la, garan|ii implicite de vandabilitate si conIormitate unui
anumit scop. V asuma|i n ntregime riscul n ceea ce priveste calitatea si perIorman|a acestui
program, n cazul n care programul se dovedeste a Ii deIect, v asuma|i n ntregime costul
tuturor serviciilor, repara|iilor si corec|iilor necesare.
10.3Concluzii
In acest curs s-a urmrit trecerea n revist a unor probleme de psihologie cu
aplicabilitate n domeniul programrii, care pot determina eIicientizarea scrierii codului,
precum si realizarea unor interIe|e cu utilizatorul usor de nv|at si de Iolosit. S-a insistat apoi
asupra eticii programrii, detaliindu-se un cod etic si, n Iinal, s-au prezentat unele chestiuni
de ordin legal, privind drepturile de autor asupra programelor realizate.