Tehnologii de elaborare a proiectelor

OVIDIU GHEORGHIES ¸ ADRIANA GHEORGHIES ¸

Facultatea de Informatic˘ a Universitatea “Al. I. Cuza”, Ia¸i s

2 Aceaste note de curs au fost compuse cu TEX ¸i MetaPost. Pentru editare s-a s folosit emacs. Multumim autorilor acestor programe de calitate pentru genero¸ zitatea de a le face liber disponibile.

Copyright c 2002-2005 Ovidiu Gheorghie¸, Adriana Gheorghie¸ s s

Versiune preliminar˘, 11 octombrie 2005. a

Cuprins
1 Cuvˆnt ˆ a ınainte 2 Introducere 3 Modele de dezvoltare a programelor 3.1 Etapele dezvolt˘rii programelor . . . a 3.1.1 Analiza cerintelor . . . . . . . ¸ 3.1.2 Proiectarea arhitectural˘ . . a 3.1.3 Proiectarea detaliat˘ . . . . . a 3.1.4 Scrierea codului . . . . . . . . 3.1.5 Integrarea componentelor . . 3.1.6 Validare . . . . . . . . . . . . 3.1.7 Verificare . . . . . . . . . . . 3.1.8 ˆ Intretinere . . . . . . . . . . . ¸ 3.2 Modelul cascad˘ . . . . . . . . . . . a 3.3 Modelul cascad˘ cu ˆ a ıntoarcere . . . . 3.4 Prototipizarea . . . . . . . . . . . . . 3.5 Metode formale . . . . . . . . . . . . 3.6 Modelul ˆ spiral˘ . . . . . . . . . . ın a 3.7 Rational Unified Process . . . . . . . 3.7.1 Pornire . . . . . . . . . . . . 3.7.2 Rafinare . . . . . . . . . . . . 3.7.3 Construire . . . . . . . . . . . 3.7.4 Tranzitie . . . . . . . . . . . 3.8 Extreme Programming . . . . . . . . 7 9 13 13 14 14 14 14 14 15 15 15 15 16 18 19 19 20 21 23 23 23 23

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

4 Ingineria cerintelor ¸ 27 4.1 Cerinta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 ¸ 4.2 Extragerea cerintelor . . . . . . . . . . . . . . . . . . . . . . . . . 28 ¸ 4.3 Specificarea cerintelor . . . . . . . . . . . . . . . . . . . . . . . . 29 ¸ 5 Concepte orientare obiect 5.1 Obiecte. Clase . . . . . . . . . . . . . 5.2 Principiile dezvolt˘rii orientat˘ obiect a a 5.2.1 ˆ Incapsulare . . . . . . . . . . . 5.2.2 Mostenirea . . . . . . . . . . . 5.2.3 Polimorfismul . . . . . . . . . . 3 31 31 32 32 33 33

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

4

CUPRINS

6 Modelare 35 6.1 Introducere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.2 Modele. Limbaje de modelare . . . . . . . . . . . . . . . . . . . . 36 7 UML 7.1 Scurt istoric . . . . . . . . . . . . . . . . . . . . . . . 7.2 Ce este UML? . . . . . . . . . . . . . . . . . . . . . . 7.3 Organizarea modelelor-Pachete . . . . . . . . . . . . 7.4 Diagrama cazurilor de utilizare (Use Case Diagram) 7.4.1 Use case-uri . . . . . . . . . . . . . . . . . . . 7.4.2 Actori . . . . . . . . . . . . . . . . . . . . . . 7.4.3 Relatii . . . . . . . . . . . . . . . . . . . . . . ¸ 7.5 Diagrama de clase . . . . . . . . . . . . . . . . . . . 7.5.1 Clase . . . . . . . . . . . . . . . . . . . . . . 7.5.2 Relatii . . . . . . . . . . . . . . . . . . . . . . ¸ 7.6 Diagrama de st˘ri . . . . . . . . . . . . . . . . . . . a 7.6.1 Stare . . . . . . . . . . . . . . . . . . . . . . . 7.6.2 Tranzitie . . . . . . . . . . . . . . . . . . . . ¸ 7.7 Diagrama de interactiuni . . . . . . . . . . . . . . . . ¸ 7.7.1 Diagrama de secvent˘ . . . . . . . . . . . . . ¸a 7.7.2 Diagrama de colaborare . . . . . . . . . . . . 7.8 Diagrama de activit˘¸i . . . . . . . . . . . . . . . . . at 7.8.1 St˘ri actiuni (action states) . . . . . . . . . . a ¸ 7.8.2 St˘ri activitate (activity states) . . . . . . . . a 7.8.3 Tranzitii . . . . . . . . . . . . . . . . . . . . . ¸ 7.8.4 Ramificatii . . . . . . . . . . . . . . . . . . . ¸ 7.9 Recomand˘ri generale de realizare a diagramelor . . a 7.10 O viziune formala . . . . . . . . . . . . . . . . . . . . 7.10.1 Introducere . . . . . . . . . . . . . . . . . . . 7.10.2 Arhitectura UML . . . . . . . . . . . . . . . . 8 Testare 8.1 Metode de testare . . . . . . . . . . . . . . . . 8.1.1 Testarea functional˘ (Black-box testing) ¸ a 8.1.2 Testarea stuctural˘ (White-box testing) a 8.1.3 Testarea la integrare . . . . . . . . . . . 8.1.4 Testarea interfetelor . . . . . . . . . . . ¸ 8.1.5 Testarea la stress . . . . . . . . . . . . . 8.1.6 Testarea orientat˘ obiect . . . . . . . . a 9 Calitatea programelor 10 Metrici pentru programe 10.1 Motivatii . . . . . . . . ¸ 10.2 Metrici de baz˘ . . . . . a 10.2.1 KLOC . . . . . . 10.2.2 PM . . . . . . . 10.3 Evaluarea costurilor . . 10.3.1 COCOMO . . . 10.3.2 COCOMO 2 . . 39 39 40 40 42 42 42 43 46 46 47 49 49 51 51 55 55 55 55 57 57 57 57 59 59 59 61 64 64 65 66 66 67 67 69 73 74 74 74 75 75 75 76

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . . . . . 5 78 79 79 80 .5 Probleme la folosirea metricilor . . a 10. . . . . .CUPRINS 10. . . . . . . . . . .3. 10. . . . . . . . . .4 Metrici orientate obiect . .3 Distributia fortei de munc˘ ˆ timp ¸ ¸ a ın 10. . . . . . . . . .3. . . . . . . . . . .4 Cum nu se evalueaz˘ costurile . . . . . . . . . . . . . .

6 CUPRINS .

ˆ ¸ Intreb˘rile Dvs. ¸ Ne cerem scuze dac˘ ˆ aceast˘ lucrare se va ˆ ampla s˘ g˘siti erori sina ın a ıntˆ a a ¸ tactice. On ne peut vous donner aucune r`gle. Mademoiselle. formul˘rile expeditive sau neclarit˘¸i. sunt binevenite: a Ovidiu poate fi contactat la adresa ogh@infoiasi. Noi ˆ sine reflect˘m asupra s a ın ın¸ a celor scrise aici ¸i le folosim ca referint˘.ro. La le¸on c 7 . s ¸a Scopul principal al activit˘¸ii in cadrul cursului “Tehnologii de elaborare a at proiectelor” este lucrul la un proiect personal de dimensiuni medii. Aceasta activitate v˘ va permite sa luati contact cu lumea complex˘ a dezvolt˘rii proa a a fesionale de programe. Manualul de fata nu se m˘rgine¸te la a prezenta doar ¸ a s notiunile de baz˘ strict necesare pentru acest prim pas. e ´tudier et encore ´tudiez. Am decis totusi s˘ a a p˘str˘m informatiile suplimentare. et puis c’est tout. e e ` — EUGENE IONESCO.Capitolul 1 Cuvˆnt ˆ a ınainte Am scris aceste note de curs din convingere. Mais pour en avoir. ¸ a credem c˘ studierea materialului prezentat aici poate ˆ a ımbun˘t˘¸i modul ˆ care a at ın privim ¸i ne implic˘m ˆ dezvoltarea unui program. iar Adriana la adresa adrianaa@infoiasi. V˘ multumim ana at a ¸ ticipat pentru orice observatii sau sugestii. semantice. ca o invitatie la excelenta adresat˘ celor a a ¸ ¸ ¸ a interesati de acest subiect. il faut ´tudier. Il faut avoir e du flair. Pornind de la experienta personal˘. Oui.ro.

CUVANT ˆ INAINTE .8 ˆ CAPITOLUL 1.

ın a ˆ ıntr-un mod oarecum provocator. Se dorea ca arta program˘rii s˘ ˆ a a ımprumute din rigoarea ¸tiintelor inginere¸ti pentru a putea livra programe la timp ¸i ˆ s s s ın mod economic. s˘ c˘utam cˆteva lemne s a a a a a a a a ¸i cˆteva cuie. a ¸ ˆ anul 1992. mai ales dac˘ suntem ˆ a s a ındemˆnatici. • Programele scrise pentru naveta spatial˘ NASA au circa 40 de milioane ¸ a de linii de cod obiect.Capitolul 2 Introducere Stiinta calculatoarelor este un domeniu relativ nou. Cre¸terea programelor ˆ dimensiune ¸i complexitate a dep˘sit cu mult pros ın s a gresele f˘cute ˆ domeniul tehnicilor de programare. programarea a a ın devenit ¸i a r˘mas mai mult o art˘ decˆt o meserie.0 (UNIX) a fost obtinut prin ¸ compilarea a 3 700 000 linii de cod. Avem ¸anse a a s destul de bune s˘ reu¸im. Paralela cu ingineria constructiilor este atractiv˘. dou˘ milioane de linii de cod ˆ limbaj de asamblare. Dup˘ ce a prev˘zut a a c˘ nici un program pentru calculatoare personale nu va necesita vreodat˘ mai a a mult de 64 KB de memorie RAM. Dac˘ totu¸i nu a a s 9 . • Pentru realizarea sistemului de operare IBM OS360 au fost necesari 5000 de ani-om. s˘ ne ˆ s a a ınarm˘m cu un ciocan ¸i s˘ ˆ a s a ıncepem s˘ lucr˘m. s a a a Pentru a contracara ceea ce se prefigura ca fiind o criz˘ a program˘rii. ˆ anul 1946 Goldstine ¸i von Neumann apreciau c˘ 1000 de instructiuni In s a ¸ reprezint˘ o limit˘ superioar˘ rezonabil˘ pentru complexitatea problemelor ce a a a a pot fi concepute ca rezolvabile cu ajutorul calculatorului. Primele calculatoare au ¸ ¸ fost construite la mijlocul anilor 1940 ¸i de atunci au avut loc dezvolt˘ri specs a taculoase. Dac˘ dorim s˘ construim ¸ a a a o cu¸c˘ pentru un cˆine. putem s˘ mergem prin gr˘din˘. ın a ın • Sistemul de operare System V versiunea 4. a fost a a propus ˆ anul 1968 termenul de “ingineria program˘rii” (software engineering). ın a Urm˘toarele exemple ofer˘ o imagine asupra gradului de complexitate la a a care au ajuns programele: • Sistemul de rezervare a biletelor pentru compania aerian˘ KLM continea. De aceea. Bill Gates admite ˆ 1995 c˘ lucrurile s-au ın a schimbat ˆ ultimele dou˘ decenii.

a a a a ¸ s ˆ ıntrucˆt se pare c˘ acestea nu pot fi identificate f˘r˘ a fi supuse contestatiilor. ce urmeaz˘ cre˘rii ¸i function˘rii. durata de realizare. Inginerii de programe ar trebui s˘ procedeze similar ¸ s a pentru ca dezvoltarea programelor s˘ nu mai fie un proces impredictibil. de c˘tre un singur programator. Atunci va trebui sau s˘ angaj˘m un arhitect care s˘ ne fac˘ un a a a a a proiect. a a a de meteorologie vor fi obligatorii. ˆ plus. ¸i retragerii din functiune a programelor ¸ s ¸ Remarc˘m c˘ a doua definitie este mai vag˘ decˆt prima. INTRODUCERE reu¸im. anume ˆ a a s ¸ a ıntretinerea ¸i retragerea din ¸ s functionare. studii geologice. calitatea finisajelor. a a aa ¸ A doua definitie adaug˘ ˆ a referiri la perioade importante din viata unui pro¸ a ıns˘ ¸ gram. a ˆ ıntr-o perioad˘ relativ scurt˘ de timp. construiesc machete. Un program de 100 de instructiuni este a a ¸ cu sigurant˘ un program mic. Va trebui s˘ negociem a aa a a cu o firm˘ de constructii pretul. function˘rii. putem s˘ ˆ schimb˘m cu un altul. ˆ a pe m˘sur˘ ce dimensiunea programului cre¸te. Deasemenea. Nu ne a ¸ ¸ permitem s˘ risc˘m economiile familiei pe o constructie care se va d˘rˆma la a a ¸ aa a doua rafal˘ de vˆnt. a a a ı¸ ¸ a ıl a Lucrurile stau radical diferit atunci cˆnd dorim s˘ construim o cas˘ pentru a a a familia noastr˘. a at s ¸ Constructii de o complexitate foarte mare au fost realizate ˆ acest fel ˆ ¸ ın ıntr-un mod rational ¸i economic. Ei vor a ¸ s ın ¸ dori garantii precum c˘ proiectul este viabil. s ˆ IEEE Standard Glossary of Software Engineering Tehnology(1983) ingiIn neria program˘rii este definit˘ dup˘ cum urmeaz˘: a a a a Ingineria program˘rii reprezint˘ abordarea sistematic˘ a dezvolt˘rii. Nu putem da o granit˘ ˆ ¸a ¸a ıntre un program mic ¸i s unul mare. ¸ Stim c˘ inginerii constructori ˆ ¸ a ıntocmesc planuri. E¸ecul nu mai s ¸ s ¸a s este o optiune pentru contractantul proiectului. ¸ Cu atˆt mai mult. sau s˘ cump˘r˘m un proiect standard de cas˘. de fizic˘ a pamˆntului. . Consider˘m c˘ ingineria program˘rii are urm˘toarele caracteristici impora a a a tante: • Este aplicabil˘ ˆ producerea de programe mari a ın • Este o ¸tiint˘ inginereasc˘ s ¸a a • Scopul final este ˆ ındeplinirea cerintelor clientului ¸ Programele mici se pot scrie relativ usor. putem ˆ s ıncerca a doua zi din nou cu alte lemne ¸i alte cuie. cei care ne ˆ a ıncredinteaz˘ cˆteva milioane de dolari pentru ¸ a a a ridica un zgˆrie nori vor fi foarte atenti cu cine ¸i ˆ ce conditii vor lucra. vor angaja mai multe firme de arhi¸ a tectur˘ pentru a-l verifica. Vor fi folosite cele mai performante materiale ¸i se vor angaja cei mai competenti ¸i cu experient˘ constructori. se pare c˘ experienta ˆ general negas ¸a a ¸ ın tiv˘ acumulat˘ a f˘cut s˘ se renunte la formularea “principii inginere¸ti solide”. a a a a ¸ a ˆ ıntretinerii.10 CAPITOLUL 2. dac˘ membrilor familiei nu le place orientarea a a In a ferestrelor ¸i obiecteaz˘ vehement la faptul c˘ terenul de sport este de baseball s a a ˆ loc s˘ fie de tenis. ˆ a a ¸ a a ıntrucˆt nu face a referire la cost ¸i la eficient˘. Iar dac˘ s a cˆinele refuz˘ s˘ ˆsi ocupe locuinta. a Prima definitie dat˘ ingineriei program˘rii a fost enuntat˘ ˆ anul 1968 astfel: a a ¸ a ın Ingineria program˘rii este stabilirea ¸i utilizarea de principii inginere¸ti soa s s lide pentru a obtine ˆ mod economic programe care sunt sigure ¸i functioneaz˘ ¸ ın s ¸ a eficient pe ma¸ini de calcul concrete. studiaz˘ propriet˘¸ilor materialelor folosite ¸i fac rapoarte privind progresul operatiunilor. Mai mult. apar provoc˘ri ıns˘ a a s a 1 S-ar putea chiar ca ei s˘ fie aceia care s˘ initieze procesul de ˆ a a ¸ ınlocuire. ne va fi greu s˘ ˆ ˆ ın a a ıi ınlocuim cu altii1 .

Un program are o gre¸eal˘ (bug) s aa ¸ s a dac˘ nu se comport˘ corect. clientul dore¸te (de obicei) ca produsul final s˘ fie realizat cu costuri ¸ s a de productie cˆt mai mici. s˘ fie livrat la timp. nu ˆ acest moment. ¸i s˘ fie sigur. ¸ ın as a Problema fundamental˘ a ingineriei program˘rii este ˆ a a ındeplinirea cerintelor ¸ a ın clientului [8]. un cost de ˆ ¸ a a a ıntretinere cˆt ¸ a mai mic. ˆ Intrucˆt un singur sau cˆ¸iva programatori nu pot avea a at timpul fizic pentru terminarea programului. Apare ca dezirabil˘ o abordare riguroas˘ a acestor probleme. Se presupune c˘ dezvoltatorul ¸tia ce ar fi trebuit a a a s programul s˘ fac˘. Aceasta pare s˘ justifice orice disciplin˘ a muncii care s˘ ˆ a ımbun˘t˘¸easc˘ aceste cifre. Un sistem de livrare a in¸ sulinei pentru diabetici poate provoca moartea pacientului dac˘ nu functioneaz˘ a ¸ a corect. faptul era privit ˆ general cu umor ¸i reclamatiile erau rezolvate repede. Un program este sigur dac˘ functioneaz˘ ¸i continu˘ s˘ functioneze f˘r˘ a ¸ a s a a ¸ aa ˆ ıntreruperi ¸i f˘r˘ a efectua operatii nedorite. a at a • 45% livrate dar nefolosite • 25% pl˘tite dar nelivrate a • 20% abandonate sau ref˘cute a • 5% folosite dup˘ modificare a • 5% folosite a¸a cum au fost livrate s Nerespectarea cerintelor poate avea efecte serioase. a s a Prezent˘m ˆ continuare o statistic˘ privind gradul de satisfacere a cerintelor a ın a ¸ a a pentru proiecte software mari [2]. Ingineria program˘rii are ca scop obtinerea de sisteme functionale chiar ¸i a ¸ ¸ s atunci cˆnd teoriile ¸i instrumentele disponibile nu ofer˘ r˘spuns la toate proa s a a voc˘rile ce apar. Pe lˆng˘ cerintele s ¸a a a ¸ functionale. ce a a include stilul de lucru. iar comportamentul gre¸it nu este intentionat. ¸inˆnd seama de restrictiile a a a t a ¸ organizatiei ˆ care lucreaz˘ ¸i de constrˆngerile financiare. Inginerii fac lucrurile s˘ mearg˘.11 noi. a . modul de scriere a codului. • ˆ primii ani ˆ care calculatoarele au fost introduse la statiile de benzina In ın ¸ din SUA. Iat˘ cˆteva a a s ¸ a a erori celebre. Ingineria program˘rii se ocup˘ cu toate s a a etapele dezvolt˘rii programelor. Aceasta trebuie realizat˘ nu punctual. Ingineria program˘rii a propune crearea unor astfel de abordare. Functionarea incorect˘ a unui sistem de control al unui satelit poate pro¸ a voca pagube de milioane de dolari. de la extragerea cerintelor de la client pˆn˘ la a ¸ a a ˆ ıntretinerea ¸i retragerea din folosint˘ a produsului livrat. ci ˆ ıntr-un mod flexibil ¸i pe termen lung.000 de gre¸eli la ¸ s fiecare nou˘ versiune care ˆ a ıncerca s˘ rezolve gre¸elile din versiunea precea s dent˘. ın s ¸ • Sistemul de operare IBM OS360 continea aproximativ 1. consumatorii primeau cecuri pe sume enorme. etc. calitativ diferite. Complexitatea sistemului software ¸i a organizatiei care realizeaz˘ sistes ¸ a mul software devine netrivial˘. este necesar˘ crearea a uneia sau a mai multor echipe de lucru. este dezirabil ca aceasta s˘ aib˘ ¸ a a a performanta cˆt mai bun˘ (uneori direct evaluabil˘). Este necesar˘ coordonarea ¸i comunicarea ˆ a s ıntre echipe. putˆnd dep˘¸i capacitatea de ˆ a a as ıntelegere a unui singur individ. De asemenea.

12 CAPITOLUL 2. will the right answers come out?” I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. ¸ • Eroare ˆ sistemul de avertizare ˆ ın ımpotriva atacului cu rachete balistice. — CHARLES BABBAGE . “Pray. a ın In ın a ın • ˆ 1979 s-a descoperit o eroare ˆ programele pentru sistemele de r˘cire ˆ centralele nucleare (SUA). nu fusese niciodat˘ nevoie de executia rutinelor a ce contineau erorile. if you put into the machine wrong figures. procedurile de contraatac au fost declan¸ate ˆ s ınainte de a se descoperi c˘ a a fost o eroare. costurile s-au ridicat la 500 milioane dolari.” (punct). instructiunea corect˘ ˆ limbajul FORTRAN ar fi trebuit s˘ contin˘ ¸ a ın a ¸ a “. On two occasions I have been asked [by members of Parliament!].” (virgul˘) ˆ loc de “. Babbage. Mr. • Racheta Ariane 5 explodeaz˘ ˆ iunie 1996 din cauza unei gre¸eli de proa ın s gramare.3’. INTRODUCERE • Un vehicul de explorare a planetei Venus a fost pierdut deoarece programul primit de pe Pamˆnt pentru rectificarea orbitei continea linia ’DO 3 I = a ¸ 1.

ınt a • un set de metode ¸i intrumente de lucru. Exist˘ o serie larg˘ de modele de dezvoltare: a a • ad hoc (do-it-yourself) • cascad˘ (waterfall) a • prototipizare • metode formale • spiral˘ a • RUP (Rational Unified Process) • XP (Extreme Programming) 3.1 Etapele dezvolt˘rii programelor a ˆ timpul dezvolt˘rii programelor s-a constatat c˘ exist˘ anumite tipuri de acIn a a a tivit˘¸i care trebuie f˘cute la un moment dat: at a • analiza cerintelor ¸ 13 . ce poate fi s a a aplicat unei serii mai largi de proiecte. Acesta este motivul pentru care planul de actiune este numit model: el poate fi privit ca un ¸ablon al dezvolt˘rii de ¸ s a programe. Luˆnd ˆ cons a ın siderare tipul pa¸ilor ce se efectueaz˘ se creaz˘ un model de lucru. ¸ Planul de actiune se numeste model de dezvoltare. Dezvoltarea unui anumit ¸ program const˘ ˆ a ıntr-un set de pa¸i ce se fac pentru a-l realiza. s • un plan de actiune.Capitolul 3 Modele de dezvoltare a programelor Cˆnd pornim la dezvoltarea unui program avem nevoie de: a • o ˆ ¸elegere clar˘ a ceea ce se cere.

1. componentele sunt dezvoltate ¸i testate individual. Modelul big-bang ˆ acest model. Scopul este ˆ s a a ınregistrarea cerintelor ˆ ¸ ıntr-o manier˘ cˆt mai clar˘ ¸i mai fidel˘.1. a 3.1. integrarea ar trebui s˘ fie o formalitate. iar cˆnd acestea lucreaz˘ a a a ˆ ımpreun˘ pot s˘ apar˘ situatii pe care o anumit˘ component˘ nu le-a ˆ alnit a a a ¸ a a ıntˆ ˆ procesul de testare sau conflicte ˆ ın ıntre anumite componente (de exemplu.5 Integrarea componentelor Modulele programului sunt combinate ˆ produsul final.3 Proiectarea detaliat˘ a Se realizeaz˘ proiectarea fiec˘rui modul al aplicatiei. a 3. In aceasta se realizeaz˘ modular.4 Scrierea codului Proiectul detaliat este transpus ˆ ıntr-un limbaj de programare. conflicte de partajare a resurselor). Avˆnd ˆ vedere c˘ functionarea corect˘ a ın a ın a ¸ a componentelor individuale a fost testat˘. Programul va trebui construit a¸adar din module sau a a s componente. MODELE DE DEZVOLTARE A PROGRAMELOR • proiectarea arhitectural˘ a • proiectarea detaliat˘ a • scrierea codului • integrarea componentelor • validare • verificare •ˆ ıntretinere ¸ 3. componentele nu pot fi testate exhaustiv. programele mari nu pot fi concepute ¸i implemens tate ca o singur˘ bucat˘. Proiectarea arhitectural˘ ˆ a ımparte sistemul ˆ ıntr-un num˘r de module mai a mici ¸i mai simple. Apoi ele In s sunt integrate ˆ sistemul final. . ˆ mod tipic.1 Analiza cerintelor ¸ Se stabile¸te ce anume vrea clientul ca programul s˘ fac˘. s 3.1.1. care pot fi abordate individual. a a Din p˘cate. pe structura rezultat˘ la proiectarea arhitectua a ral˘.14 CAPITOLUL 3. ˆ cele mai mici detalii. Rezultatul este sistemul ın complet. a a ¸ ın 3. Claritatea se refer˘ la lipsa a a as a a ambiguit˘¸ii iar fidelitatea la ˆ at ınregistrarea cˆt mai exact˘ (posibil cuvˆnt cu a a a cuvˆnt).2 Proiectarea arhitectural˘ a Din motive de complexitate.

ˆ care produsul este preın zentat clientului. a Un exemplu de validare este testul de acceptare. a a ¸ Astfel.2 Modelul cascad˘ a Modelul cascad˘ define¸te urm˘torii pa¸i ˆ dezvoltarea unui program: a s a s ın • Specificarea cerintelor ¸ • Proiectarea arhitectural˘ a • Proiectarea detaliat˘ a • Scrierea codului • Testarea componentelor • Testarea sistemului • Testul de acceptare 1 Are 2 Are we building the right product? (eng. ˆ ın ¸ a at Intretinerea const˘ ¸ a ˆ gestionarea acestor probleme. timpul de testare exa a a plodeaz˘.1. ˆ Intrebarea la care raspundem este: construim corect produsul? 2 .) we building the product right? (eng. ˆ Intrebarea la care r˘spundem este: construim produsul corect? 1 .1. proiectul devenind greu de controlat.6 Validare ˆ procesul de validare ne asigur˘m c˘ programul ˆ In a a ındepline¸te cerintele utilizas ¸ torului. 3. pot apare schimb˘ri a ˆ specificatiile utilizatorilor. Aceasta justific˘ denumirea de a a ’big-bang’.1. urmat˘ imediat de testarea sistemului obtinut. Modelul incremental Acest model propune crearea unui nucleu al aplicatiei ¸i integrarea a cˆte o ¸ s a component˘ la un moment dat. a 3.8 ˆ Intretinere ¸ Dup˘ ce programul este livrat clientului.7 Verificare ˆ procesul de verificare ne asigur˘m c˘ programul este stabil ¸i c˘ functioneaz˘ In a a s a a corect din punctul de vedere al dezvoltatorilor.) .˘ 3. care vor diverse imbun˘t˘¸iri. MODELUL CASCADA 15 S-a constatat c˘ atunci cˆnd se aplic˘ acest model.2. se poate determina mai u¸or unde anume apare o problema ˆ sistem. Clientul spune dac˘ este multumit cu produsul sau dac˘ mai a ¸ a trebuie efectuate modific˘ri. mai devreme sau mai tˆrziu sunt desa a coperite defecte sau erori ce trebuie reparate. 3. De asemenea. s ın Acest tip de integrare ofer˘ de obicei rezultate mai bune decˆt modelul biga a bang. ın 3.

ci doar ordinea a s s ¸ efectu˘rii lor. la testare se poate descoperi o a eroare de proiectare.16 CAPITOLUL 3. . notatii).3 Modelul cascad˘ cu ˆ a ıntoarcere Unul din dezavantajele modelului cascad˘ este c˘ ˆ a a ıntr-un anume stadiu al dezvolt˘rii nu se poate influenta rezultatul obtinut ˆ a ¸ ¸ ıntr-un stadiu precedent pentru a se remedia o problema gasit˘. MODELE DE DEZVOLTARE A PROGRAMELOR Ingineria cerintelor P roiectarea arhitecturala P roiectarea detaliata Implementare T estarea unitatilor T estarea sistemului Acceptare Figura 3. etc.1: Modelul de dezvoltare ˆ cascad˘ ın a Nu se stipuleaz˘ cum se fac ace¸ti pa¸i (metodologie. a Avantaje O sarcin˘ complex˘ este ˆ a a ımpartit˘ ˆ mai multi pa¸i mici. Fiecare pas are ca rezultat un produs bine definit (documente de specificatie. Un model realist ar trebui s˘ ofere posibilitatea ca de la a a a un anumit nivel s˘ se poat˘ reveni la oricare dintre nivelele anterioare. Modelul cascad˘ cu feedback propune remedierea problemelor descoperite a ˆ pasul precedent. ce sunt mai u¸or ¸ a ın s s de administrat. De exemplu. a a Dezavantajul principal al modelului ˆ cascad˘ este acela c˘ clientul obtine ın a a ¸ o viziune practic˘ asupra produsului doar ˆ momentul termin˘rii procesului de a ın a dezvoltare. model.) ¸ 3. Problemele la pasul i care sunt descoperite la pasul i + 3 ın r˘mˆn neremediabile.

3.2: Modelul de dezvoltare ˆ cascad˘ cu ˆ ın a ıntoarcere .˘ 3. MODELUL CASCADA CU ˆ INTOARCERE 17 Ingineria cerintelor P roiectarea arhitecturala P roiectarea detaliata Implementare T estarea unitatilor T estarea sistemului Acceptare Figura 3.

Pe masur˘ ce aplicatia este dezvoltat˘.4 Prototipizarea O problem˘ general˘ care apare la dezvoltarea unui program este s˘ ne asia a a gur˘m c˘ utilizatorul obtine exact ceaa ce vrea. ˆ a scopul ¸a ¸ Ins˘ principal al prototipului este de a ajuta ˆ fazele de analiz˘ ¸i proiectare ¸i nu ın as s folosirea unui stil elegant. Aceast˘ versiune nu este ˆ a ¸ a ıntregul sistem. a •ˆ ıntretinerea este redus˘. Avantaje: • permite dezvoltatorilor s˘ elimine lipsa de claritate a specificatiilor a ¸ • ofer˘ utilizatorilor ¸ansa de a schimba specificatiile ˆ a s ¸ ıntr-un mod ce nu afecteaz˘ drastic durata de dezvoltare. ıns˘ ¸ ¸ a Prototipul ajut˘ clientul ˆ a-¸i defini mai bine cerintele ¸i priorit˘¸ile. Se disting dou˘ feluri de prototipuri: a • de aruncat (throwaway) • evolutionar ¸ ˆ cazul realiz˘rii unui prototip de aruncat. aici se investe¸te un In s efort considerabil ˆ ıntr-un design modular ¸i extensibil. scopul este exclusiv obtinerea In a ¸ unei specificatii. deoarece validarea se face pe parcursul dezvolt˘rii a a • se poate facilita instruirea utilizatorilor finali ˆ ınainte de terminarea produsului. ˆ a este o parte a sistemului care cel putin functioneaz˘. a ¸ • clientul nu ˆ ıntelege de ce produsul necesit˘ timp suplimentar pentru deza voltare. Dezavantaje: • deoarece prototipul ruleaz˘ ˆ a ıntr-un mediu artificial. avˆnd ˆ vedere c˘ prototipul a fost realizat atˆt de repede. precum ¸i ˆ adoptarea s s ın unui stil elegant de programare. ın ˆ cazul realiz˘rii unui prototip evolutionar. clientii schimb˘ ın s ¸ a foarte des specificatiile. Odat˘ stabilite cerintele. De aceea nu se acord˘ nici o important˘ stilului de programare ¸ a ¸a ¸i de lucru. ˆ a din primele faze ale dezvolt˘rii. a ın a a • deoarece au ˆ fiecare moment ¸ansa de a face acest lucru. scopul este de a crea un schelet In a ¸ al aplicatiei care s˘ poat˘ implementa ˆ prim˘ faz˘ o parte a cerintelor sistea a ın a a ¸ mului. s a a ¸ codul prototipului este ’aruncat’. ¸ • poate fi nepopular˘ printre dezvoltatori. ˆ contrast cu prototipul de aruncat. anumite dezavantaje ale produsului final pot fi sc˘pate din vedere de clienti. Prototipul. Prototipizarea vine ˆ sprijinul a a ¸ ın rezolv˘rii acestei probleme. stilul de programare este de obicei (cel putin) neglijent. clientului i se a Inc˘ a prezint˘ o versiune functionala a sistemului. pe cale de a consecint˘. este de obicei produs cˆt mai repede. Prin a ın s ¸ s at intermediul unui prototip el poate ˆ ¸elege ce este posibil ¸i ce nu din punct de ınt s vedere tehnologic. sistemul final fiind re-scris de la ˆ ınceput.18 CAPITOLUL 3. MODELE DE DEZVOLTARE A PROGRAMELOR 3. deoarece implic˘ renuntarea la a a ¸ propria munca. noi caracteristici sunt adaugate a ¸ a scheletului existent. . punˆndu-se accent pe viteza de dezvoltare. ˆ ın mod tipic chiar ˆ alt limbaj de programare.

5. ¸ ¸ 3.5 Metode formale ˆ acest model de dezvoltare. evaluat ¸i se iau m˘suri pentru contracararea efectelor s a sale negative. ca ¸i ˆ modelul cascad˘. Apoi. METODE FORMALE 19 3. a s . Avantaje: • precizia obtinut˘ prin specificarea formal˘. a a a Modelul ˆ spiral˘ define¸te urm˘torii pa¸i ˆ dezvoltarea unui produs: ın a s a s ın • studiul de fezabilitate • analiza cerintelor ¸ • proiectarea arhitecturii software • implementarea Modelul ˆ spiral˘ recunoa¸te c˘ problema principal˘ a dezvolt˘rii prograın a s a a a melor este riscul.3. Exemple de riscuri: • ˆ timpul unui proces ˆ ın ındelungat de dezvoltare. • o firma concurent˘ lanseaz˘ un program rival pe piat˘. aceast˘ In a a ¸ ın a specificatie este transformat˘ ˆ programe. Riscul nu mai este eliminat prin asertiuni de genul: “in urma proiect˘rii am obtinut un model corect al sistemului”. ¸ a a • p˘strarea corectitudinii ˆ timpul transform˘rii specificatiei ˆ cod execua ın a ¸ ın tabil. sunt folosite formalismul ¸i rigoarea matematicii.6 Modelul ˆ spiral˘ ın a Modelul ˆ spiral˘ ˆ ın a ıncearc˘ s˘ rezolve problemele modelului ˆ cascad˘. a a • potrivite pentru sisteme cu cerinte critice. ¸ Dezavantaje: • specificarea formal˘ este de obicei o barier˘ de comunicare ˆ a a ıntre client ¸i s analist. In s ˆ prima faz˘ este construit˘ o specificatie ˆ limbaj matematic. prototipizarea poate fi folosit˘ dac˘ se consider˘ necesar. Deasemenea. pastrˆnd a a ın a a avantajele acestuia: planificare. a ¸ s ın a Aici riscul este acceptat. a • folosirea impecabil˘ a tehnicilor specific˘rii formale nu implic˘ neap˘rat a a a a obtinerea de programe sigure. de obicei ˆ ¸ a ın ıntr-un proces incremental. deoarece anumite aspecte critice pot fi omise ¸ din specificatiile initiale. • necesit˘ personal foarte calificat (deci mai scump). cerintele (noi) ale clientu¸ lui sunt ignorate. faze bine definite. a a ¸a • un dezvoltator/arhitect p˘rase¸te echipa de dezvoltare. • ofer˘ posibilitatea gener˘rii automate de cod. produse intermediare.

resurse umane. • Testare. constrˆngerile. s s ¸ . Se translateaz˘ necesit˘¸ile functionale ˆ comportament de sis¸ a at ¸ ın teme automate. a a a • gestionarea riscului: analiza ¸i rezolvarea situatiilor de risc. at at ¸ • Cerinte. s ¸ • activit˘¸i de dezvoltare specifice pasului curent (de ex. analiza specificatiilor at ¸ sau scrierea de cod) • planificarea urm˘torului stadiu: termenele limita. a ¸ ˆ modelul spiral˘ (3. Sunt sintetizate necesit˘¸ile functionale. a 3.7 Rational Unified Process 3 Rational Unified Process (Procesul unificat [de dezvoltare al firmei] Rational) define¸te urm˘toarele activit˘¸i fundamentale: s a at • Ingineria functionalit˘¸ii. putˆnd ın a ¸a a a ˆ ınsemna ¸i (Procesul unificat [¸i] rational [de dezvoltare]).3) se consider˘ c˘ fiecare pas din dezvoltare contine o a a ¸ In a serie de activit˘¸i comune: at • preg˘tirea: se identific˘ obiectivele. MODELE DE DEZVOLTARE A PROGRAMELOR 1 : pregatirea [take stock] 2 : gestiunea riscului [dealing with risk] 4 : planif icarea urmatorului stagiu [planning] 3 : dezvoltarea [development] Figura 3. ambigu˘. revizuia rea st˘rii proiectului. • Analiza ¸i Proiectare.20 CAPITOLUL 3.3: Modelul de dezvoltare ˆ spiral˘ ın a • o echipa nu respect˘ un termen de livrare pentru o anumit˘ component˘ a a a • clientul schimb˘ cerintele. probabil din motive de promovare pe piat˘. Se creaz˘ programul conform cu arhitectura astfel ˆ a ıncat comportamentul acestuia sa fie consistent cu cel dorit. s a ¸ ın • Implementare. alternativele. Se translateaz˘ cerintele ˆ arhitectura programului. ın 3 Denumirea ˆ englez˘ este. Se asigur˘ c˘ comportamentele cerute sunt corecte ¸i c˘ toate a a s a comportamentele necesare sunt prezente ˆ program.

Dac˘. Se gestioneaz˘ versiunile s a tuturor entit˘¸ilor din care este compus programul. iar pˆn˘ ˆ a ınc˘ ¸ a a ın momentul la care se face estimarea timpul de dezvoltare a fost de 2 sapt˘mˆni a a pe iteratie. Iteratii care dureaz˘ o saptamˆn˘ ¸ ¸ a a a sau dou˘ sunt considerate acceptabile ca ˆ a ıntindere ˆ timp. • o descriere a obiectivelor proiectului. de exemplu. echipa de dezvoltare are oportunitatea de a a ¸ a primi mai repede reactii din partea clientului. de experienta echipei etc.7. a • Plasament. Se instaleaz˘ ¸i se mentine mediul de lucru neas ¸ cesar dezvolt˘rii programului. pe parcursul ın ın a ın a ˆ ıntregului proiect. A¸adar. Aici. Se vor explora a ¸ arhitecturi alternative ¸i solutii tehnice posibile. mai sunt proiectate ˆ a 20 de iteratii. putem s˘ apreciem c˘ proiectul va mai dura aproximativ 40 de ¸ a a sapt˘mˆni. ¸ ¸ a ıns˘ a ele devin din ce ˆ ce mai precise. ¸ ın a • o imagine de ansamblu asupra arhitecturii programului. Sunt administrate planific˘rile ¸i resursele. chiar dac˘ a ¸ a a aceste compartimente nu sunt implementate complet. a s • Administrarea mediului. a ıns˘ a a cele mai multe dintre cerinte devin cunoscute. pe masur˘ ce procesul de dezvoltare evolueaz˘. Se efectueaz˘ activit˘¸ile necesare punerii ˆ functiune a proa at ın ¸ gramului. ˆ a apare cu pregnant˘ la ˆ ıns˘ ¸a ınceputul acestuia. posibil ˆ form˘ de cazuri de utilizare. .7. ˆ a este permis ca aceste activit˘¸i s˘ se execute la at s ıns˘ at a orice moment al dezvolt˘rii. importanta anumitor s a a ¸ activit˘¸i scade sau cre¸te. Aceast tip de informatie poate fi de mare folos administratorilor ¸i a a ¸ s clientilor. s ¸ ˆ urma acestei activit˘¸i. ˆ a nu zero. Scopul unei a ın s ¸ ¸ iteratii este s˘ dezvolte un program functional care s˘ poat˘ fi prezentat clien¸ a ¸ a a tului. ˆ a noi cerinte sunt identificate: ¸ ıns˘ ¸ aceasta ˆ ınseamn˘ c˘ activitatea cerinte se reg˘se¸te pe ˆ a a ¸ a s ıntreaga durat˘ de viat˘ a ¸a a procesului. ele sunt executate ˆ paralel. at ın ˆ cazul modelului ˆ cascad˘). se obtin urm˘toarele: In at ¸ a • o enumerare a cerintelor principale. iar clientul s˘ ˆ poat˘ evalua. ˆ a pe masura ce proiectul avanseaz˘. ın 3.4 cantitatea de cod scris˘ la a ˆ ınceputul proiectului este mic˘. de exemplu. a Un proiect bazat pe RUP evolueaz˘ ˆ pa¸i numiti iteratii. Initial estim˘rile sunt nesigure. Este ˆ a de preferat ca iteratiile s˘ fie cˆt mai a ¸ ıns˘ ¸ a a scurte. • un plan preliminar de dezvoltare. scopul principal al iteratiilor este s˘ ajute echipa de dezvoltare In ¸ a s˘ stabileasca care vor fi obiectivele esentiale ale proiectului. Programul obtinut la sfˆr¸itul unei iteratii a ıl a ¸ as ¸ ar trebui s˘ contin˘ elemente din toate compartimentele programului. Aceste activit˘¸i nu sunt separate ˆ timp (cum se presupune.1 Pornire ˆ faza de pornire.3. Pe masur˘ ce proiectul evolueaz˘. ın Iteratiile pot fi folosite pentru a estima timpul necesar dezvolt˘rii proiec¸ a tului. RATIONAL UNIFIED PROCESS 21 • Administrarea configuratiei ¸i a schimbarilor. at • Administrarea proiectului. ˆ Intinderea ˆ timp a unei iteratii depinde de tipul de proiect la care se luın ¸ creaz˘. Dup˘ cum reiese din figura 3. Dac˘ o iteratie este scurt˘.

MODELE DE DEZVOLTARE A PROGRAMELOR Figura 3.4: Activit˘¸ile ˆ cadrul RUP at ın .22 CAPITOLUL 3.

a ¸ ¸ 3.3. a at s Sfˆr¸itul acestei activitati ¸i a ˆ as s ıntregului proces de dezvoltare are loc atunci cˆnd: a • Obiectivele propuse ˆ cadrul fazei de pornire sunt ˆ ın ındeplinite.7. ¸ • teste care verific˘ functionarea programului. de¸i ˆ unele aplicatii este posibil ca a ın a s ın ¸ ele s˘ sufere oarecari modific˘ri. inspia rat˘ din RUP. iteratie cu iteratie la a ¸ ¸ program.3 Construire Iteratiile din faza de contruire au ca rol ad˘ugarea se diverse caracteristici pro¸ a gramului dezvoltat. Adesea pot s˘ a ¸ a apar˘ cerinte ce nu au fost propuse initial.4 Tranzitie ˆ cadrul acestei activit˘ti programul este ˆ In a ımbogatit mai departe cu caracteris¸ tici.8.7.2 Rafinare ˆ faza de rafinare se stabile¸te o ˆ In s ıntelegere detaliat˘ a problemei care trebuie a rezolvat˘. dar care propune rezolv˘ri originale problemelor care apar ˆ a a ın dezvoltarea de programe. se stabile¸te echipa de lucru.7. EXTREME PROGRAMMING 23 3. Fiind o tehnologie nou˘ (¸i extremist˘) are adepti ¸i a s a ¸ s detractori. a ¸ Aceast˘ activitate produce urm˘toarele: a a • un prototip evolutionar al arhitecturii programului. se hot˘r˘¸te arhitectura programului. se a a as s elimin˘ situatiile cu risc mare. ¸ at • un plan de proiect detaliat pentru iteratiile urm˘toare. ¸ a 3.8 Extreme Programming Extreme Programing (XP) [5] 4 este o metodologie nou˘ de dezvoltare. 4 Programare extrem˘ a . ˆ a accentul se pune pe ˆ ıns˘ ımbun˘t˘¸irea ¸i rafinarea celor existente. a a Cazurile de utilizare sunt adaugate unul cˆte unul. • Clientul este satisf˘cut. pˆn˘ cˆnd clientii pot utiliza programul ˆ a a a ¸ ıntr-un mod apropiat de cel a¸teptat. a De remarcat c˘ a doua situatie nu se suprapune peste prima. ˆ aceast˘ faz˘ se a¸teapt˘ ca cazurile de utilizare oferite In a a s a de client s˘ se stabilizeze ˆ mare masur˘. s Activitatea de construire produce urm˘toarele: a • Programul propriu-zis • Teste • Manuale de utilizare 3. a ¸ • cazuri de utilizare care descriu majoritatea functionalit˘¸ilor sistemului.

a ¸ a a • Ai dreptul s˘ te razgˆnde¸ti. cˆnd. as a a s ¸ • Ai dreptul s˘ vezi progresul ˆ a ıntr-un sistem care ruleaz˘ ¸i care se dovedeste as c˘ functioneaz˘ trecˆnd teste repetabile pe care tu le specifici. pentru frumusete chiar cˆnd a terminat de a ın a construit jum˘tate de pod. i s-ar muta malurile ¸i i s-ar ¸ a s schimba rˆul din Siret ˆ Amazon. ¸ s a as a Carta drepturilor clientului • Ai dreptul la un plan general. inspirarea proceselor de dezvoltare a programelor din ingineria constructiilor se pare c˘ nu este cea mai fericit˘ alegere. MODELE DE DEZVOLTARE A PROGRAMELOR XP consider˘ c˘ dezvoltarea programelor nu ˆ a a ınseamna ierahii. ınc˘ Initiatorii XP. XP ne aminte¸te cu respect ca fi¸ierele ¸ s s s PowerPoint nu se pot compila. a a a a a realizeaz˘ un proiect ¸i abia apoi trece la executie. De altfel. Ace¸tia sunt a a s ˆ ıncurajati s˘ ˆsi afirme personalitatea. putem fi siguri c˘ acel inginer ¸i-ar schimba modul a a s de lucru. nu stim (ˆ a) cum. a a a Carta drepturilor dezvoltatorului • Ai dreptul s˘ ¸tii ceea ce se cere. s˘ ˆ a a s a ınlocuie¸ti functionalit˘¸i ¸i s˘ schimbi s at s a priorit˘¸ile. ¸i s˘ ˆ¸i a a ıt a ¸a s a ıt revizuie¸ti estim˘rile ˆ functie de experient˘. a a ın • Ai dreptul la liniste. s˘ ofere ¸i s˘ primeasc˘ cunoa¸tere ¸i s˘ a ı¸ a s a a s s a devin˘ programatori str˘luciti. cu declaratii clare de as ¸ ¸ prioritate. ¸i la ce pret. • Ai dreptul s˘ spui cˆt ˆ¸i va lua s˘ implementezi fiecare cerint˘. distractie ¸i la munc˘ productiv˘ ¸i placut˘. XP consider˘ c˘ dezvoltarea de programe ˆ a a ınseamn˘ ˆ primul a ın rˆnd scrierea de programe. s˘ ¸tii ce poate fi f˘cut. s a a s oricˆt am vrea s˘ ne p˘c˘lim s˘ credem asta. Aceast˘ sintagm˘ banal˘ se pare c˘ este uitat˘ de a a a a a a multe companii care se ascund ˆ spatele proceselor de dezvoltare stufoase. s a ın ¸ ¸a • Ai dreptul s˘ ˆ¸i accepti responsabilit˘¸ile. toate acestea ˆ a s ıntr-un mod secvential ¸i previzibil. Dar dezvoltarea de programe nu seam˘n˘ cu a¸a ceva. prin cerinte clare. at • Ai dreptul s˘ fii informat de schimbarile ˆ estim˘ri. responsabilit˘¸i ¸i termene limit˘ a¸a cum se afl˘ acestea pe masa administratorului. Dac˘ inginerului constructor a a a a a a respectiv i s-ar schimba cerintele de rezistent˘. ˆ loc ca acestea s˘-ti fie asiga ıt ¸ at ın a¸ nate. Din pacate ˆ ınsa. suficient de devreme a ın a pentru a putea reduce cerintele astfel ca munca s˘ se termine la data ¸ a prestabilit˘. a ¸ a a a . ca ¸ s a a baz˘ filozofic˘ pentru aceast˘ metodologie. Este adevarat c˘ un ¸ a a a inginer care vrea s˘ construiasc˘ un pod peste un rˆu face intˆi m˘suratori. a a Deasemenea.24 CAPITOLUL 3. ci at s a s a ˆ ınseamn˘ colaborarea oamenilor din care este format˘ echipa. • Ai dreptul s˘ produci treab˘ de calitate ˆ orice moment. a ın sedintelor ¸i a rapoartelor de activitate. Poti chiar s˘ te opresti la un moment dat ¸i s˘ r˘mˆi cu un a ¸ a s a a a sistem folositor care s˘ reflecte investitia pˆn˘ la acea dat˘. Jon Jeffries ¸i Kent Beck definesc urm˘toarele dou˘ carte.

nu ˆ documentatii.E. • La orice moment. despre turnul din Pisa . contin semnificatii profunde. a • Modificarile aduse codului sunt integrate continuu (de cateva ori pe zi). a • Se scrie cod de test intˆi. f˘r˘ lucru suplimentar. — K. de¸i par ˆ ¸ s ıntelese de la sine. But by then the investment was so big they felt compelled to go on. since it was never really needed in the first place. aceasta se face f˘r˘ a a aa mil˘. s ¸ • Scrierea de cod este activitatea cea mai important˘. ¸ ¸ Multe din problemele ap˘rute ˆ dezvoltarea programelor pornesc de la ˆ a ın ıncalcarea acestor principii. Enumer˘m pe scurt cˆteva dintre caracteristicile XP. Le l˘s˘m ca subiecte de meditatie pentru cititor.3. Fiecare contribuie la a a proiect folosind maximul din cuno¸tintele sale. as ¸ a a • Se lucreaz˘ 40 de ore pe sapt˘mˆn˘. a • Dac˘ apare necesitatea rescrierii sau arunc˘rii de cod. Since its completion. Echipele se schimb˘ la a ın a ın a sfˆr¸itul unei iteratii (1-2 sapt˘mˆni). everyone knew it would be a total disaster. IVERSON. ıi aa ¸ It took 300 years to build and by the time it was 10% built. ¸ • Codul se scrie cˆt mai simplu. it has cost a fortune to maintain and is still in danger of collapsing. • Se programeaz˘ ˆ echip˘ (programare ˆ perechi).8. un reprezentant al clientului este disponibil pentru clarificarea cerintelor. EXTREME PROGRAMMING 25 Aceste afirmatii. There are at present no plans to replace it. ın ın ¸ modele sau rapoarte. a a • Echipa de dezvoltare nu are o structur˘ ierarhic˘. a a a a aa Nu vom discuta aici avantajele aduse de aceast˘ abordare ¸i nici criticile care a s ˆ sunt adresate. a • Proiectul este ˆ mintea tuturor programatorilor din echipa.

MODELE DE DEZVOLTARE A PROGRAMELOR .26 CAPITOLUL 3.

¸ Dezvoltarea unui program ˆ ıncepe de obicei cu o idee a clientului despre un nou sistem sau pentru ˆ ımbunat˘¸irea unui sistem existent.Capitolul 4 Ingineria cerintelor ¸ Primul pas logic ˆ dezvoltarea unui program este stabilirea precis˘ a cerintelor ın a ¸ clientului (ceea ce clientul vrea ca programul s˘ fac˘). s 1 Asemenea persoane pot fi ˆ alnite ˆ functii administrative ˆ companii ce se ocupa de ıntˆ ın ¸ ın dezvoltare de programe. Este responsabilitatea a ¸ a clientului de a veni cu cereri exacte ¸i pertinente. analist de sistem sau analist. a a ¸ Ideea initial˘ a clientului poate fi vag˘ ¸i prost definit˘. simt artistic ¸i de cuno¸tinte tehnice ¸ t a ¸ s s ¸ ale programatorilor. Partea ce mai important˘ a a a a acestui proces o reprezint˘ comunicarea dintre client ¸i echipa de dezvoltare. ci din cauz˘ c˘ cerintele nu au fost specificate corect a a a ¸ de la ˆ ınceput. Clientul angajeaz˘ at a un analist cu care va lucra ˆ ımpreun˘ pentru specificarea mai exact˘ a cerintelor. dup˘ cum poate fi clar˘ ¸ a as a a a ¸i bine definit˘. at 27 . O echip˘ de prograa a a a a matori poate s˘ scrie cel mai estetic program din punct de vedere al tehnicilor a de programare folosite. s Multe programe nu se potrivesc cu cerintele clientului nu din motive de ¸ implementare defectuas˘. dar dac˘ nimeni nu va dori s˘-l foloseasc˘. a s Cˆnd un inginer de programe lucreaz˘ la stabilirea cerintelor. Curios. 1 Adevarul este c˘ a avea perceptie extransenzorial˘ ¸i a a ¸ as poseda capabilit˘¸i telepatice nu intr˘ ˆ atributiile programatorilor. Persoane ale c˘ror leg˘turi cu ingineria program˘rii sunt mai mult a a a pretinse decˆt obiective consider˘ c˘ nepotrivirea dintre a¸tept˘rile clientului ¸i a a a s a s programul obtinut ¸in de lipsa de cultur˘. proiectul va a a a fi un e¸ec. Dac˘ clientul nu ¸tie sau nu poate s˘ stabileasc˘ ˆ a s a a ın urma unei discutii cu echipa de dezvoltare ˆ mod exact ce vrea ca produsul s˘ ¸ ın a fac˘. O specificatie bun˘ este folosit˘ ¸i ˆ fazele de ¸ ¸ a a s ın validare ¸i verificare. el este numit a a ¸ inginer de cerinte. Ace¸tia at a ın ¸ s nu pot ¸i nu au cum s˘ cunoasc˘ necesit˘¸ile clientilor. s a Stabilirea cerintelor este probabil cea mai important˘ activitate ˆ dezvol¸ a ın tarea produselor program. este inutil s˘ angajeze o echip˘ care s˘ programeze. mai ales dac˘ nu cunosc s a a at a domeniul pentru care o anumit˘ aplicatie este scris˘. chiar ajung s˘ conduc˘ echipe formate doar din programatori a a cu asemenea calit˘¸i. as at Stabilirea precisa a cerintelor este primul pas ˆ obtinerea unui program ¸ ın ¸ care satisface cerintele clientului. Este obligatia inginerului de s ¸ cerinte de a discuta cu clientul pentru a clarifica cerintele ¸i a ajuta clientul ¸ ¸ s s˘-¸i fixeze priorit˘¸ile.

fluxul de lucru. ¸i deci nu poate s˘ fie de acord as a s a ˆ cunostint˘ de cauz˘ cu stipul˘rile din specificatii.2 Extragerea cerintelor ¸ Presupunem c˘ clientul ¸i analistul lucreaz˘ ˆ a s a ımpreun˘. Secretarele care folosesc ın ¸a a a ¸ Excel stiu COM? E necesar s˘ facem contrˆngeri asupra programului ˆ a din a a ınc˘ faza de concepere? 2. remarc˘m c˘ indic˘ cerinte. Cˆteodat˘ nu este posibil s˘ ignoram a a a o implemetare existent˘. Remarc˘m ˆ a c˘ este incomplet˘: nu s a ıns˘ a a specific˘ nimic despre costul sau termenul limit˘ de realizare. este a a a at posibil ca costurile s˘ creasc˘ (ˆ a a ıntretinere greoaie. a s modul de organizare al mediilor de stocare a informatiilor) ¸i o ’copiem’ ˆ ¸ s ın program. electric) sau materialul din care s˘ se confectioneze rotile. C˘ s˘ vedem a a a a dac˘ o specificatie este bun˘ ar trebui s˘ ne intrebam dac˘: a ¸ a a a • spune ce ¸i nu cum s • este clar˘ a • este suficient de detaliat˘ a • este complet˘ a Pentru comparatie. a a diesel. a 4. Folosim detalii de implementare. trebuie s luat˘ ˆ considerare implementarea. studiem a a a implementarea existent˘ (tipul fi¸elor ce trebuie completate. INGINERIA CERINTELOR ¸ 4. Este o diferent˘ ˆ a ın a ıntre a programa ˆ Visual ın Basic ¸i a programa ˆ C++.28 CAPITOLUL 4. ¸ ¸a ˆ leg˘tur˘ cu specificatia pentru locomotiv˘. a ¸ Ar trebui s˘ implementeze functii pentru c˘utarea unui numar ¸i pentru introa ¸ a s ducerea unui nou num˘r de telefon. Pentru a putea estima timpul de dezvoltare ¸i pretul. Motivatia: nu ne a¸tept˘m ca clientul ¸ s a s˘ ¸tie lucruri specifice dezvolt˘rii programelor. De exemplu. probleme de performant˘). In a a ¸ a a a a ¸ nu mod de implementare. ¸ ¸a a o cerint˘ pentru o locomotiv˘ ar putea ar˘ta astfel: Pe o cale ferat˘ uscat˘.1 Cerinta ¸ Notiunea de cerint˘ este mai veche decˆt dezvoltarea programelor. fiecare ˆ a ıncercˆnd s˘ a a ˆ ¸eleag˘ pe celalalt. programatori mai ieftini). Nu se specific˘ tipul motorului (cu aburi. Costurile initiale la programarea ˆ Visual Basic s ın ın vor fi mai mici (timp de dezvoltare mai mic. Nu folosim detalii de implementare. Cerintele sunt testabile (cu instrumente de m˘sur˘ ¸ a a specifice) ¸i sunt clare (neambigue). Putem verifica dac˘ o cerint˘ este sau nu rezonabil˘ din punct de a ¸a a vedere tehnic. Programul ar trebui s˘ ofere o interfat˘ a a ¸a utilizator prietenoas˘. Nu spune nimic a a ¸a despre cum ar putea fi realizat˘. ¸ ¸ De remarcat c˘ aceast˘ cerint˘ spune ce vrea clientul. Dac˘ facem un program pentru o bibliotec˘. a ¸ Controvers˘: este bine s˘ facem specificarea luˆnd ˆ considerare felul ˆ a a a ın ın care sistemul va fi implementat? 1. ˆ a odat˘ ıns˘ a ce produsul necesit˘ dezvoltarea peste o anumit˘ limit˘ a complexit˘¸ii. ¸a a a a a locomotiva trebuie s˘ fie capabil˘ s˘ porneasca un tren de 100 tone pe o pant˘ a a a a de maxim 5% cu o acceleratie de cel putin 30km/h. Esenta procesului de obtinere a cerintelor este comuniınt a ¸ ¸ ¸ . consider˘m urm˘torul exemplu de specificatie: Scrieti ¸ a a ¸ ¸ un program Pascal care ofer˘ functionalitatea unei agende telefonice personale.

Rezolvarea o l˘s˘m ca exercitiu. sau s˘ fie loial celui care ˆ ¸ a a a ¸ a a a ıl pl˘te¸te. ˆ a a a ınainte de angajarea echipei de dezvoltare. 2 Aceasta . Clientul a¸teapt˘ mult prea mult de la program s a ¸i de la echipa de dezvoltare. a s a ¸ a ınt 4. Se disting trei activit˘¸i majore care conduc la obtinerea unei specific˘ri at ¸ a a cerintelor: ¸ • Ascultare.3. XP se mˆndre¸te c˘ foloseste cartona¸e cu ¸ a s a s povesti. a s a a ¸ 3 Cel putin pentru metodologiile anterioare XP. a a Trebuie avute ˆ vedere: ın • nivelul de detaliu • cui ˆ este adresat documentul ıi • notatia folosit˘ ¸ a ridic˘ o dilem˘ de etic˘ pentru inginerul programator: s˘ anunte angajatii c˘ a a a a ¸ ¸ a sunt spionati f˘r˘ ca s˘ stie (lips˘ de etic˘ din partea clientului). Neat s gocierea este foarte important˘. Analistul ¸i clientul cad de acord asupra unor formulari ale s cerintelor pe care analistul le considera pertinente. s a ın ˆ ıntr-o scen˘ de doua minute. SPECIFICAREA CERINTELOR ¸ 29 carea. ˆ aceast˘ faz˘ analistul ˆ a In a a ıncearc˘ s˘ traduc˘ cerintele clientului a a a ¸ ˆ limbaj tehnic ¸i s˘ se asigure de pertinenta cerintelor ˆ acest context. ˆ aceast˘ faz˘ analistul ˆ In a a ınregistreaz˘ cerintele clientului a ¸ • Gˆndire. ¸ s • s˘ sf˘tuiasc˘ clientul despre ce este tehnic posibil sau imposibil a a a • s˘ documenteze cerintele a ¸ • s˘ negocieze ¸i s˘ obtin˘ o ˆ ¸elegere cu clientul. Diferenta cultural˘ dintre client ¸i analist este a ¸ a s cˆteodat˘ foarte mare. ˆ s ınchipuindu-¸i c˘ programele se scriu ca ˆ filme. ¸ Aceste activit˘¸i sunt parte a unui proces iterativ. a a a Analistul trebuie: • s˘ extrag˘ ¸i s˘ clarifice cerintele clientului a as a ¸ • s˘ ajute la rezolvarea diferentelor de opinie ˆ a ¸ ıntre clienti ¸i utilizatori.3 Specificarea cerintelor ¸ Produsul extragerii cerintelor ¸i a analizei este un document de specificare a ¸ s cerintelor (specificatii) 3 . Un exemplu concret al acestui a s tip de conflict este cˆnd un patron care comand˘ un program care s˘ fie utilizat a a a de c˘tre angajatii s˘i dore¸te ca acesta s˘ contin˘ module de monitorizare a a ¸ a s a ¸ a muncii angajatilor 2 .4. Specificatiile sunt documente de referint˘ cu ¸ ¸a ajutorul c˘rora se evalueaz˘ dezvoltarea programului. ın s a ¸ ¸ ın • Scriere. Specificatiile sunt de o important˘ crucial˘ ˆ dez¸ ¸ ¸ ¸a a ın voltarea cu succes a unui produs. Exist˘ situatii cˆnd exist˘ diferente semnificative ˆ a a a ¸ a a ıntre astept˘rile utilizatorilor finali ¸i ale clientului. lung ¸i complicat. O alt˘ problema o reprezint˘ literatura SF studiat˘ de client. ca un am˘nunt dintr-un film de dou˘ ore.

Influenteaz˘ direct a ¸ a implementarea sistemului. memoa a a ria disponibil˘. timp de r˘spuns. formale. ˆ a ınsa preferintele pentru limbajul ¸n care se exprim˘ ¸ i a aceste lucruri sunt diferite. “Balance of Terror”.30 CAPITOLUL 4. semiformale. ¸ Abordarea modern˘: se fac dou˘ seturi de documente. ın ¸ First study the enemy. dimensiuni) ¸i la datele stocate ˆ interiorul sistemului. a Probleme ce pot apare ˆ legatura cu cerintele: ın ¸ • Cerinte vagi: sistemul trebuie s˘ fie prietenos ¸ a • Cerinte contradictorii: toate datele trebuie scrise pe disc. Ar trebui s˘ surprind˘ viziunea clientului asupra a a a sistemului. Fiecare dintre aceste grupuri tind s˘ aib˘ jargoane. a Exemple: Timpul de r˘spuns al sistemului la intrarea de la tastatura ar a trebui minimizat. Indic˘ ce ar trebui s˘ fac˘ sistemul. ¸ ¸ a a a Exemple: Sistemul va afi¸a titlurile c˘rtilor scrise de un anumit scriitor s a Sistemul va afisa temperaturile din toate s˘lile de lectur˘ a a • Cerinte privind datele. grad de ˆ arcare. dome¸ s a a nii de expertiz˘ diferite. Star Trek. s ın • Constrˆngeri. Se refer˘ la datele de intrare/ie¸ire din sistem ¸ a s (format. iar un set pentru dezvoltatori. data stelar˘ 1709. s a a Tipuri de notatii: informale. Folosirea memoriei trebuie minimizat˘. limbaj de programare. sau sistemul trebuie s˘ r˘spund˘ ın a a a oric˘rei cereri ˆ a ıntr-o secund˘ a Constrˆngerile se refer˘ la: cost. ˆ timp ¸ a ın ce anali¸tii tind s˘ foloseasca o notatie precis˘ (limbaj de modelare). timpul de ras¸ puns 1 s Succestul unui proces de dezvoltare a unui program se bazeaz˘ pe extragerea a ˆ mod profesionist a cerintelor de la client. INGINERIA CERINTELOR ¸ Este de preferat ca specificatiile s˘ se restrˆng˘ cˆt mai mult ˆ preajma a ¸ a a a a ın ce. Un set este pentru a a clienti. hardware-ul utilizat. Problema care apare este actualizarea ¸ acestor documente ¸i mentinerea lor consistent˘. Exemple: sistemul trebuie scris ˆ Pascal. Clientii prefer˘ de obicei limbajul natural. Specificatiile trebuie ˆ ¸elese de dou˘ grupuri distincte de persoane: ¸ ınt a clienti ¸i dezvoltatori. s a Un document de specificatii bun ar trebui s˘ categorizeze ˆ mod explicit ¸ a ın cerintele ˆ una din urm˘toarele clase: ¸ ın a • Cerinte functionale. nu a CUM trebuie f˘cut.2 a . data livr˘rii. a a ınc˘ sigurant˘ (MTBF) ¸a • Recomand˘ri. O recomandare ajut˘ la luarea unei decizii de implementare a a atunci cˆnd sunt disponibile mai multe strategii. Cerinte ce trebuie respectate ad literam. — COMANDANT ROMULAN. Membrii aceste grupuri vor ca specificatiile s˘ enunte a ¸ a ¸ exact cea ce trebuie f˘cut. Seek weakness.

Locuintei nr. pipernicit ¸i slab. se joac˘. O clas˘ este o descriere a unei multimi de obiecte care au aceleasi caractea ¸ ristici structurale ¸i comportmanetale. cu o stare precizat˘.Capitolul 5 Concepte orientare obiect 5. 4. care se ¸in iarna de cald a a t ¸i vara de frig. Putem privi o clas˘. care este de fapt pisic˘. care ¸ine iarna de cald ¸i vara de frig. ˆ ıntrebuintare specific˘. care manˆnc˘. ¸i a s care sar. Ap. as • Mingea mea galbena de tenis. culoare. care sare. de dimensiune 4 octeti. • Mingi. 4. ca fiind: a ın • o descriere general˘ a unui num˘r de obiecte a a • o colectie de metode (operatii) ce pot fi efectuate de instantele clasei ¸ ¸ ¸ • un mecanism pentru stabilirea ¸i reutilizarea conceptelor s 31 . se ¸ s a a joac˘ ¸i doarme. sex. • Motanul Griutu’. mananc˘. 4. au diametru. care sunt sferice.1 Obiecte. accesibile doar pentru citire ¸i a c˘ror biti sunt interpretati ca ˆ s a ¸ ¸ ıntregi little-endian. fiecare dintre ace¸tia avˆnd bitii setati pe 0. Et. s • Zone de memorie adresate pe 32 biti. ˆ ınaltime. Clase Un obiect este o entitate care are identitate. este accesibila doar pentru citire ¸i s a ¸ s poate fi interpretat˘ ca un ˆ a ıntreg little-endian. greutate. ˆ acelasi timp. a t s • Zona de memorie de la adresa 0x00FFA0BC de dimensiune 4 octeti. ¸i a a a s dorm. s Exemple: • Apartamente care au adres˘. s Exemple: • Apartamentul situat la adresa Str. ˆ stare ¸ ın impecabil˘. • Pisici care au nume. cu diametrul 10 cm. stare ¸i comportament.

Aceast˘ separare este esential˘ aa ¸ a ¸ a pentru producerea de cod refolosibil ¸i usor de intretinut. Un utilizator poate a a modifica starea obiectului doar ˆ mod indirect. Un avantaj al acestei abord˘ri este c˘ ˆ a a ımbun˘t˘¸iri a at ale codului pot apare f˘r˘ a schimba interfata. orice limbaj de programare orientat obiect ar trebui s˘ ofere In a suport pentru constructiile de mai sus. s ¸ a Limbajele orientate obiect consider˘ codul ¸i datele ca parte a unei entit˘¸i a s at indivizibile numite obiect. Datele continute ˆ ¸ ıntr-un obiect sunt de regul˘ moa dificate doar prin intermediul codului (metodelor) obiectului respectiv. CONCEPTE ORIENTARE OBIECT • o abstractizare a unui obiect • un tip de date Spunem c˘ un obiect care apartine unei clase este instant˘ a acelei clase. ˆ a Incapsularea permite ca o clas˘ s˘ fie folosit˘ f˘r˘ a ¸ti cum functioneaz˘ (modularitate. referitoare la ce a a a ın ˆ ınseamna “orientat obiect”. depanate. Polimorfismul permite scrierea s unei clase generale care specific˘ o interfat˘ a carei implementare va fi specificat˘ a ¸a a ¸i apelat˘ ˆ s a ıntr-un mod transparent pentru clasele care o mo¸tenesc. aba a a aa s a stractizare). a a ˆ Intr-un sistem orientat obiect se lucreaz˘ ˆ mod uzual cu o colectie de a ın obiecte ce coopereaz˘ pentru a obtine un anumit rezultat. ar fi posibil s˘ transpunem o ¸ a arhitectur˘ orientat˘ obiect ˆ orice limbaj orientat obiect disponibil. s ¸ . Fiecare obiect poate fi privit ca un mic procesor a c˘rui comportare este definit˘ de a a modul cum r˘spunde la un apel de metod˘. implementate. Astfel. asupr˘ c˘rora ˆ general se convine.32 CAPITOLUL 5.2 Principiile dezvolt˘rii orientat˘ obiect a a Exist˘ anumite principii.1 ˆ Incapsulare ˆ Incapsulare ˆ ınseamna punerea ˆ ımpreuna a p˘rtilor puternic corelate ale unui a¸ program ˆ scopul cre˘rii de unit˘¸i ce pot fi proiectate. a ¸ ¸a 5. a a ın Toate aceste trei caracteristici promoveaz˘ reutilizarea codului. s 5.2. El nu ın trebuie s˘ ¸tie modalitatea ˆ care modific˘ metoda starea obiectului ci doar a s ın a efectul acestei modificari. a ¸ Ascunderea informatiei: utilizatorii unui obiect nu au nevoie s˘ stie (nu-i ¸ a intereseaz˘. prin apelul de metode. Mo¸tenirea permite reutilizarea codului prin folosirea de caractes ristici deja existente ¸i adaugarea de altele noi. nu trebuie s˘ stie) implementarea metodelor. ın a at testate ¸i mentinute una c˘te una. Se consider˘ c˘ dezvoltarea unui program este orientat˘ obiect dac˘ apar a a a a urmatoarele caracteristici: •ˆ ıncapsularea • mo¸tenirea s • polimorfismul ˆ principiu.

a ¸a • Reutilizarea codului: ˆ loc s˘ duplice codul. a a O subclas˘ are caracteristicile super-clasei pe care le extinde ˆ a ıntr-un anume fel. nu de catre apelant (acelasi apel de metoda se poate comporta diferit pentru tipuri de obiecte diferite). Avantaje: • Definitii concise ale claselor: pentru subclase este suficient s˘ descriem ¸ a cum difer˘ fat˘ de super-clase. clasele derivate reutilizeaz˘ ın a a codul existent ˆ superclas˘.3 Polimorfismul Polimorfism: interpretarea semanticii unui apel de metod˘ se face de catre cel a care primeste apelul. hence army.2. also class in general. summons. PRINCIPIILE DEZVOLTARII ORIENTATA OBIECT 33 5. division of citizens for military draft. from Latin “classis”. ın a 5.2. Sau. — THE AMERICAN HERITAGE DICTIONARY .2.˘ ˘ 5. o a a clas˘ este super-clas˘ a unei altei clase. fleet. Extinderea programelor cu tipuri noi de date se simplific˘ foarte mult. a De exemplu: • metalele pretioase sunt metale • masinile de curse sunt masini • romanele sunt carti Spunem ca o clas˘ de obiecte este sub-clas˘ altei clase de obiecte.2 Mostenirea Adesea anumite clase sunt percepute ca speciliz˘ri ale altor clase. ¸ CLASS. a Informatii suplimentare: [4]. de exemplu: • Metalele pretioase au fat˘ de celelalte metale valoare monetar˘ ¸a a • O zebr˘ este un cal cu dungi a Mai spunem c˘ sub-clasa sau clasa derivat˘ mo¸tene¸te caracteristicile supera a s s clasei.

34 CAPITOLUL 5. CONCEPTE ORIENTARE OBIECT .

un arhitect o notatie preponderent grafic˘ etc. chiar ¸i f˘r˘ folosirea explicit˘ a unui limbaj: a s aa a Cuvintele scrise sau limbajul rostit. s ¸ ¸ Termenul formal este esential. Un model este o simplificare unui anumit sistem.) a a Folosirea unui limbaj “intern” nu trebuie privit˘ ca negativ˘.Capitolul 6 Modelare 6. fie datorit˘ incomın a pletitudinii acestuia. a fiecare surprinz˘nd anumite aspecte ale acestuia. O rezolvare a problemei comunicarii ar fi ca aceea¸i s persoan˘ s˘ fie implicat˘ direct ˆ toate fazele dezvolt˘rii. Se impune ¸ ın a a a¸adar existenta unui limbaj formal de comunicare al cerintelor. se face modelare. Modelarea este ¸ ın a ın s ın ın posibil˘. a ın Folosirea de modele poate ˆ ınlesni abordarea de probleme complexe. Folosirea tehnicii “divide et impera” permite ˆ ¸elegerea p˘rtilor ınt a¸ componente ale unui sistem. detera minat viziunea sa asupra problemei ¸i de pregatirea acestuia (un matematician s va utiliza o notatie algebric˘. fie din cauza lipsei de precizie a modului ˆ care este prezentat modelul. datorit˘ dificult˘¸ii intrinseci de ˆ a at ıntelegere a sistemului ˆ ın ˆ ıntregul sau. Un model reu¸it retine caracteristicile importante ale obiectului a¸ s ¸ modelat ¸i le ignor˘ pe cele irelevante. apare a a a ın a s s des situatia ˆ care o persoan˘ trebuie s˘ continuie munca alteia. a Astfel apare plauzibil˘ construirea mai multor modele pentru un anumit obiect. Lucrul cu modelele poate facilita o mai bun˘ ˆ ¸elegere a at a ınt sistemului modelat. Este posibil s˘ apar˘ situatii ˆ care modelul a a ¸ ın construit de proiectant s˘ nu fie ˆ a ınteles exact de cel ce scrie cod. iar ansambul sistemului ca o interactiune ˆ ¸ ıntre p˘rtile acestuia. nu par s˘ joace nici un rol ˆ mecaa ın nismele gˆndirii mele. De obicei. Chiar ¸i a¸a. ea avˆnd se pare a a a un rol esential ˆ gˆndire ˆ general ¸i ˆ modelare ˆ particular.1 Introducere Problema principal˘ care apare ˆ dezvoltarea programelor este complexitatea. ce permite analizarea unora dintre propriet˘¸ile acestuia. Entit˘¸ile fizice ce par s˘ serveasc˘ drept elemente de a at a a gˆndire sunt anumite semne ¸i imagini mai mult sau mai putin clare ce pot fi a s ¸ reproduse ¸i combinate “voluntar”. a Orice metodologie de dezvoltare a programelor abordeaz˘ problema comua nic˘rii ˆ a ıntre membrii echipei. chiar ¸i ˆ proiecte de dimensiuni ¸ s ın reduse. ele depinzˆnd de scopul pentru care se face modelarea. (Albert Einstein) s 35 . De remarcat c˘ notiunile de importans a a ¸ t/irelevant sunt relative. ˆ a ˆ ıns˘ ıntr-un limbaj specific celui care modeleaz˘. adesea o serie de am˘nunte subtile ce sunt evidente pentru a designer nu sunt transmise.

) [6] Folosirea UML faciliteaz˘ comunicarea modelelor. general˘ ¸i extensibil˘ de comunicare a modelelor. Viteza este notat˘ a s ¸ a cu v. la un microprocesor nu ne a intereseaz˘ culoarea sau greutatea. masa cu m.36 CAPITOLUL 6. expresiv ¸i compact. ˆ timp ce le a ¸ ın ignor˘ pe celelalte. ar fi mai greoaie. De exemplu. El a fost creat ˆ pria as a ın mul rˆnd pentru a facilita proiectarea programelor. Limbaje de modelare Deseori. Forma corpului este desenat˘ a a ca un p˘trat. viteza ¸i forta sunt reprezentate prin vectori. Termenul de relevant este bineˆ ¸eles relativ. at Aceast˘ simplificare retine caracteristicile relevante ale unui sistem. ingor˘m a caracteristicile care nu intereseaz˘. a ın a Exist˘ ˆ a ınsa obiecte mult mai complexe decˆt un microprocesor. Pentru ¸ a un initiat. ˆ ce ordine ˆi cum trebuie ele utilizate pentru un sistem ın s particular. a a a ın a s Limbajul de modelare UML ˆsi propune s˘ defineasc˘ o modalitate cˆt mai ı¸ a a a precis˘. ¸tim c˘ singu¸ ¸ ın s a rele atribute care influenteaz˘ analiza ˆ acest caz sunt masa corpului ¸i forta ¸ a ın s ¸ net˘ care actioneaz˘ asupra corpului. Toate aceste elemente formeaz˘ un model. ˆ a nu asigur˘ crearea a ıns˘ a unui model bun. Limbajul de modelare nu specific˘ ¸i nu poate specifica ce a s modele trebuie create. diferite aspecte a ınt fiind relevante ˆ functie de problema la care se foloseste modelul respectiv. formalismul limbajului de modelare const˘ din a stabilirea de elemente cu o semantic˘ asupra c˘reia se convine ¸i cu ajutorul a a s c˘rora s˘ se poat˘ trasmite idei ˆ mod cˆt mai eficient ¸i neambiguu. Diverse alte caracteristici sau interectiuni cu mediul sunt ignorate. El nu este un ˆ ınlocuitor al inteligentei. O descriere ¸ s alternativ˘. ¸i sunt a a a s a s con¸tient c˘ atunci c˘nd mi se cere brusc s˘ vorbesc.2 Modele. Modelul este o simplificare a realitˆ¸ii. ˆ a ınsa datorit˘ expresivitˆ¸ii a at sale poate fi folosit ¸i ˆ alte domenii (proiectare hardware. Un model ˆ a ¸ a ıncet˘¸enit printre fizicieni de at reprezentare a acestei probleme este prezentat ˆ figura 6. a s Fie un corp de mas˘ m asupra c˘ruia actioneaz˘ o forta F cu punctul de a a ¸ a ¸ . Motivul pentru care exist˘ totu¸i microprocesoare ˆi navete a s s cosmice este simplu: se folosesc modele. este “tradus” ˆ limbajul intern al receptorului). Din punct de vedere practic. odat˘ transmis. ın ¸ S˘ consider˘m c˘ dorim s˘ analiz˘m modul de comportare al unui corp sub a a a a a actiunea unei forte externe.1: ın Acest model face cˆteva simplificari evidente. 6. atunci cˆnd ne gˆndim la un obiect ˆ a a ıntr-un context oarecare. sub forma de text. forta cu F. Pe baza experientei ˆ domeniu. a ¸ Pe de alt˘ parte. experientei ¸i bunului gust ¸ s [9]. de¸i posibil mai exacta. O rachet˘ a a cosmic˘ este probabil un artefact ce dep˘¸e¸te capacitatea de ˆ a as s ıntelegere a unui singur individ. (Francis Galton) ¸ A¸a cum formalismul rationamentului matematic poate fi agentul de transs ¸ a ın misie al adevarului matematic [7] (care. modelarea proceselor s ın de afaceri etc. este probaa bil ineficient s˘ consider˘m aspectul greutatii microprocesorului de fiecare dat˘ a a ¸ a cˆnd utilizam un calculator ¸i de aceea un mecanism de eliminare a caracterisa s ticilor irelevante functioneaz˘ probabil ˆ mintea fiec˘ruia. MODELARE Aceasta nu ˆ ınseamn˘ c˘ a comunica altora ideile este facil: a a Trebuie s˘ traduc gˆndurile ˆ a a ıntr-un limbaj ce nu curge la fel de lin. A¸a s c˘ pierd o groaz˘ de timp caut˘nd cuvintele ¸i frazele corespunz˘toare. de multe ori sunt foarte s a a a neclar datorit˘ faptului c˘ m˘ exprim pur ¸i simplu st˘ngaci ¸i aceasta nu din a a a s a s cauza lipsei de claritate a perceptiei. desenul de mai sus este consistent.

and when it is bad. s Evident. Experienta a a ¸ arat˘ ˆ a c˘ folosirea sa induce adesea neclaritati ¸i inconsistente. Eliminarea ambiguitatilor din modele poate fi facut˘ ˆ a ımbun˘t˘¸ind a at precizia limbajului de modelare ¸i nu cautˆnd erori de semantic˘ ˆ ˆ s a a ın ıntreaga descriere a modelului. LIMBAJE DE MODELARE v 37 m F Figura 6. descrierea elementelor ¸i a semanticii se face ˆ ultim˘ instant˘ ˆ lims ın a ¸a ın baj natural. Documentation is like sex: when it is good. Se convine asupra unui set de elemente ale limbajului precum ¸i asupra semanticii acestora. very good. MODELE. deci pot apare ambiguit˘¸i. ˆ acest caz ˆ a.1: Modelarea ˆ fizica ın aplicatie ˆ centrul s˘u de greutate.6. limbajul natural este at In ıns˘ folosit numai ˆ ıntr-o mic˘ parte a sistemului ¸i problemele de semantic˘ pot fi a s a localizate.2. Corpul se deplaseaz˘ cu o vitez˘ v perpen¸ ın a a a dicular˘ pe directia fortei. Apare asta ıns˘ a ¸ s ¸ fel necesitatea definirii unui limbaj neambiguu de specificat modele. a ¸ ¸ Limbajul natural pare s˘ fie cel mai la ˆ a ındemˆn˘ limbaj de modelare. — DICK BRANDON . it is better than nothing. it is very.

38 CAPITOLUL 6. MODELARE .

9 a UML. cˆnd Rumın ın a baugh s-a alaturat lui Booch ˆ cadrul companiei Rational Software. a devenit clar ca UML este v˘zut de catre at ¸ a multe companii ca o optiune strategic˘ pentru dezvoltarea produselor lor. Intellicorp. prin ˆ ıncorporarea ˆ fiecare limbaj a caracteristicilor ın gasite ˆ celelalte limbaje. numˆrul de limbaje de modelare ajunge de la 10 a pˆna la mai mult de 50 ˆ perioada 1989-1994. fapt ce a alimentat ”rˆzboiul metodelor”. OOSE .asa cum era numit˘ atunci) a fost publicat˘ ˆ oca a a ın tombrie 1995. Pe parcursul anului 1996. La mijlocul anilor ın a 1990. Dintre aceste companii care au contribuit ¸ ¸ a la crearea UML 1. cˆnd este semnalat˘ o nou˘ generatie de limbaje de modelare. a ˆ a a a ¸ ınceput un proces de omogenizare. ın Cei trei autori ai limbajelor de modelare principale.1 Scurt istoric ˆ Incepˆnd cu mijlocul anilor 1970 ¸i continuˆnd ˆ anii 1980 au aparut diverse a s a ın limbaje de modelare. Tot atunci.Object Modeling Technique (James s Rumbaugh). ambii ın lucrˆnd la unificarea limbajelor Booch ¸i OMT. Jacobson s-a alˆturat echipei de la Rational ¸i scopul a s UML a fost extins pentru a include ¸i OOSE. Astfel. au ajuns la concluzia ca ar fi mai bine s˘ conduc˘ evolutia limbajelor a a ¸ lor pe un acelasi drum. utilizatorii g˘seau tehnicile de modelare ce le erau necesare unui proiect particular numai a ˆ anumite limbaje.8 a a s a Unified (Metoda Unificat˘ . I-Logix. Booch.Capitolul 7 UML 7. Dezvoltarea UML a ˆ ınceput ˆ mod oficial ˆ octombrie 1994. Hewlet-Packard. Limbajele de modelare de success a ın din aceast˘ perioad˘ sunt Booch (Grady Booch). Astfel. Un al doilea motiv a fost unul pragmatic. ˆ iunie 1996 a fost publicat˘ s In a versiunea 0.0 au f˘cut parte DEC. pentru a elimina diferentele gratuite ce nu f˘ceau decˆt ¸ a a sa ˆ ıncurce utilizatorii. Versiunea preliminar˘ 0. Al treilea motiv a fost convingerea c˘ prin unirea fortelor se pot a ¸ aduce ˆ ımbunatatiri tehnicilor existente. dup˘ cum s a a creatorii lor puneau accentul pe anumite idei de modelare.Object-Oriented Softa a ware Engineering (Ivar Jacobson) ¸i OMT . Aceste limbaje aveau propriile punce tari ¸i sl˘biciuni. reie¸it din nes cesitatea industriei software de a avea o oarecare stabilitate pe piata limbajelor de modelare. odat˘ cu cre¸terea experientei de lucru ˆ cadrul paradiga s ın mei orientate obiect. Rumbaugh ¸i s Jacobson. a 39 . A fost ¸ a creat un consortiu UML format din organizatii doritoare s˘ aloce resurse pen¸ ¸ a tru a obtine o definitie final˘ a UML. ca o consecint˘ a reactiilor co¸a ¸ munit¸˘ii proiectantilor de sistem.

UML este un limbaj cu ajutorul caruia se pot construi (descrie) modele. ˆ momentul de fat˘ se lucreaz˘ la versiunea 2. Actuala ın mente UML este dezvoltat de catre OMG Revision Task Force.40 CAPITOLUL 7. Un exemplu de ¸ a a ın relatii care se pot stabili ˆ ¸ ıntre pachete este dat ˆ figura 7. Oracle.2 Ce este UML? UML (Unified Modeling Language) este un limbaj de modelare bazat pe notatii ¸ grafice folosit pentru a specifica. Fiec˘rui model ˆ coresa ıi punde o diagram˘. Tipuri de diagrame existente ˆ UML sunt: a ın • Diagrama cazurilor de utilizare (Use Case Diagram) • Diagrama de clase (Class Diagram) • Diagrame care descriu comportamentul: – Diagrame de interactiuni (Interactions Diagrams) ¸ ∗ Diagrama de secvent˘ (Sequence Diagram) ¸a ∗ Diagrama de colaborare (Collaboration Diagram) – Diagrama de st˘ri (Statechart Diagram) a – Diagrama de activit˘¸i (Activity Diagram) at • Diagrame de implementare: – Diagrama de componente (Component Diagram) – Diagrama de plasare (Deployment Diagram) 7. Toate tipurile de a s elemente ale unui model UML pot fi organizate ˆ pachete. MCI Systemhouse. construi ¸i documenta componentele s unui program [6]. Microsoft. vizualiza.3 au fost publicate ˆ ıncepˆnd cu sfˆr¸itul anului 1998. UML 1.2 a UML a fost o revizie editoriala. ˆ septembrie 2001 a fost publicat˘ a as In a versiunea 1. ın ın Pˆn˘ la sfˆr¸itul anului 1997 echipa care lucra la UML s-a extins. In ¸a a 7. Versiunea a ın a a UML 1.2.[3]. versiunile 1. ın . Rational. Versiunea 1.1. urmˆnd o a a as a perioad˘ ˆ care UML a primit o specificare formal˘ mai riguroas˘.3 Organizarea modelelor-Pachete Un pachet (package) reprezint˘ o grupare a elementelor unui model. Un model surprinde un anumit aspect al unui program. Texas Instruments etc. Fiecare element poate fi continut de un singur pachet. condus de Cris Kobryn. iar modelerea acestor situatii se face ¸ folosind unul dintre stereotipurile import ¸i s access asociate unei relatii de dependent˘.1 a fost adoptat˘ ca standard de catre OMG ˆ noiembrie 1997. UML IBM. ın Pachetele reprezint˘ baza pentru controlul configuratiei. cˆt ¸i alte tipuri de elemente ale modelului. ¸ ¸a Notatia grafic˘ pentru pachet este prezentat˘ ˆ figura 7. Pachetele a ˆ ınsele pot fi continute unul ˆ ¸ ıntr-altul.0 a UML. depozitare ¸i cona ¸ s trolul accesului.4. Totu¸i ¸ s pachetele pot face referiri la alte pachete.0 a fost propus spre standardizare ˆ cadrul OMG ˆ ianuarie 1997. Un pachet poate contine atˆt alte pachete ¸ a subordonate.

3.1: Notatia grafic˘ pentru pachet ¸ a Figura 7. ORGANIZAREA MODELELOR-PACHETE 41 Figura 7.7.2: Exemplu de relatii care se pot stabili ˆ ¸ ıntre pachete .

Fiecare actor are un nume care indic˘ rolul pe care acesta ˆ a ıl joac˘ ˆ interactiunea cu programul.3: Notatia grafic˘ pentru use case ¸ a 7. el interactionˆnd cu oameni sau cu alte sisteme ¸ a pentru ˆ ındeplinirea unui scop. El este o a ¸ descriere a unei multimi de secvente de actiuni (incluzˆnd variante) pe care ¸ ¸ ¸ a un program le execut˘ atunci cˆnd interactioneaz˘ cu entit˘¸ile din afara lui a a ¸ a at (actori) ¸i care conduc la obtinerea unui rezultat observabil ¸i de folos actorului. ˆ a de regul˘ numele sunt s ıns˘ a scurte fraze verbale care denumesc un comportament ce exist˘ ˆ vocabularul a ın sistemului ce trebuie modelat. 7. O diagram˘ use case este una din cele 4 diagrame folosite ˆ UML pentru a a ın modela aspectele dinamice ale unui program al˘turi de diagrama de activit˘¸i. a ın ¸ . echipamente hardware sau alte programe. Acesta poate fi un ¸ir arbitrar de caractere. Ei pot fi utilizatori (persoane).1 Use case-uri Un use case (caz de utilizare) reprezint˘ cerinte ale utilizatorilor. Figura 7. a 7.2 Actori Actorii reprezint˘ o multime de roluri pe care utilizatorii unor use case-uri le a ¸ joac˘ atunci cˆnd interactioneaz˘ cu aceste use case-uri. Acest flux de evenimente trebuie s˘ includ˘ cum ina a cepe ¸i se termin˘ use case-ul atunci cˆnd acesta interactioneaz˘ cu actori. a a a ¸ Fiecare use case are un nume prin care se deosebe¸te de celelalte use cases uri.3 prezint˘ notatia grafic˘ pentru use case. UML Figura 7. ce s a a ¸ a obiecte sunt interschimbate.4. dar nu precizeaz˘ nimic a despre cum este realizat˘ (implementat˘) o anumit˘ functionalitate. a at diagrama de st˘ri.4. Aceste fluxuri de evenimente reprezint˘ scenarii posibile de utilizare a a sistemului.42 CAPITOLUL 7. a ¸a s Elementele componente ale unei diagrame use case sunt use case-uri. diagrama de secvent˘ ¸i diagrama de colaborare. precum ¸i fluxuri alternative ale acestui compors tament. s ¸ s Un use case descrie ce face un program sau subprogram.4 Diagrama cazurilor de utilizare (Use Case Diagram) Nici un program nu este izolat. a ¸ a Comportamentul unui use case poate fi specificat descriind un flux de evenimente ˆ ıntr-un text suficient de clar ca s˘ poat˘ fi ˆ ¸eles de cineva din exterior a a ınt (de exemplu utilizatorul). Identificarea use case-urilor se face pornind de la cerintele utilizatorului ¸i ¸ s analizˆnd descrierea problemei. Actorii sunt entit˘¸i a a ¸ a at exterioare sistemului. actori ¸i relatiile care se stabilesc ˆ s ¸ ıntre acestea.

Relatia de dependent˘ ¸ ¸a Se poate stabili numai ˆ ıntre use-case-uri. adic˘ initiaz˘ executia unor use case-uri.3 Relatii ¸ Relatiile pot fi de mai multe tipuri: asociere.6. adic˘ ofer˘ functionalitate pentru realizarea ¸ a a a ¸ unor use case-uri. s Dependenta de tip include ¸ Notatie grafic˘ este dat˘ ˆ figura 7. In ın B este de sine st˘t˘tor. ¸ ¸a s Relatia de asociere ¸ Poate exista ˆ ıntre actori ¸i use-case-uri. dependent˘ ¸i generalizare. ın a Dependenta de tip extend ¸ .4: Notatia grafic˘ pentru actor ¸ a Notatie grafic˘ pentru un actor este ilustrat˘ ˆ figura 7. a ¸ Pentru identificarea actorii ar trebui s˘ r˘spundem la urm˘toarele ˆ a a a ıntreb˘ri: a • Cine folose¸te programul? s • De cine are nevoie programul pentru a-si indeplini sarcinile? • Cine este responsabil cu administrarea sistemului? • Cu ce ehipamente externe trebuie s˘ comunice programul? a • Cu ce sisteme software externe trebuie s˘ comunice programul? a • Cine are nevoie de rezultatele (raspunsurile) oferite de program? 7.5. sau ˆ s ıntre use-case-uri. Fiecare actor trebuie s˘ comunice cu cel putin un use case. ı Dependenta de tip include se folosette pentru a scoate ˆ evident˘ un com¸ ¸ ın ¸a portament comun (B poate fi inclus ˆ mai multe use case-uri de baz˘).4. ˆ a este necesar pentru a asigura functionalitatea use aa ıns˘ ¸ case-ului de bazˆ A. DIAGRAMA CAZURILOR DE UTILIZARE (USE CASE DIAGRAM)43 Figura 7.4. ¸ a a ın Exist˘ dou˘ moduri ˆ care actorii pot interactiona cu un sistem: a a ın ¸ 1. ¸ a a ın ˆ acest caz comportamentul use case-ului B este inclus ˆ use case-ul A. s Relatia de asociere se reprezint˘ grafic printr-o linie ¸i este evidentiat˘ ˆ ¸ a s ¸ a ın figura 7. Este folosit˘ a pentru a exprima interactiunea (comunicarea) ˆ ¸ ıntre elementele pe care le une¸te.4. folosind sistemul. Relatiile de dependent˘ pot fi de dou˘ ¸ ¸a a tipuri: include ¸i extend.7. a ¸ a ¸ 2. fiind folositi de c˘tre sistem.

5: Exemplu de diagram˘ use case a Figura 7.6: Notatia grafic˘ pentru relatia de dependent˘ de tip include ¸ a ¸ ¸a . UML Figura 7.44 CAPITOLUL 7.

Acest tip de relatie se folose¸te pentru a modela alternative. s Este similar˘ relatiiei de generalizare (mo¸tenire) care se stabilie¸te ˆ a ¸ s s ıntre clase.4. ¸ a ın ˆ acest caz comportamentul use case-ului B poate fi ˆ In ınglobat ˆ use case-ul ın A. A ¸i B sunt de sine st˘tatoare. A controleaz˘ dac˘ B va fi executat sau nu. Case-ul derivat controleaz˘ ce anume se execut˘ ¸i ce se a a as modific˘ din use case-ul de baz˘. Ceea ce se vede este cum reactioneaz˘ el la actiunile din a ¸ a ¸ exterior. DIAGRAMA CAZURILOR DE UTILIZARE (USE CASE DIAGRAM)45 Figura 7. use case-ul derivat poate ˆ ınlocui ˆ anumite situatii ın ¸ use case-ul de baz˘. ¸ s Relatia de generalizare ¸ Se stabilie¸te ˆ s ıntre elemente de acela¸i tip (doi actori. ¸i joaca roluri diferite ˆ interactiunea cu use a s ın ¸ case-ul UC (b).7. trebuie precizat˘ conditia de care depinde a ¸ apelul use case-ului specializat. Pentru fiecare use case pot fi specificate mai multe puncte a de extensie.9actorii A ¸i B joac˘ acela¸i rol R atunci cˆnd ın s a s a comunic˘ cu use case-ul UC (a). Va rezulta specificarea comportamentului dorit. sau doua use-case-uri). Aceste nume a a trebuie s˘ fie unice. Figura 7.7: Notatia grafic˘ pentru relatia de dependent˘ de tip extend ¸ a ¸ ¸a Figura 7. Fiecare dintre aceste puncte trebuie s˘ aib˘ un nume. Sistemul apare ca a o cutie neagr˘. ˆ a nu este obligatoriu ca ele s˘ coincid˘ cu numele use a ıns˘ a a case-urilor specializate. s a a a Punctele de extensie specific˘ locul ˆ care use case-ul specializat (B) extinde use a ın case-ul de baz˘ (A). De asemenea. s s s ¸ a ˆ cazul unei relatii de generalizare ˆ In ¸ ıntre use case-uri comportamentul poate fi modificat sau extins. Observatie: ˆ figura 7.7. s ¸ a • pentru a modela cerintele unui sistem: ce trebuie s˘ fac˘ sistemul (dintr¸ a a un punct de vedere exterior sistemului) independent de cum trebuie s˘ a fac˘. Utiliz˘ri ale diagramei use case: a • pentru a modela contextul unui sistem: determinarea granitelor sistemului ¸ ¸i a actorilor cu care acesta interactioneaz˘. Elementul derivat mo¸tene¸te comportamentul ¸i relatiile elementului de baz˘. .8 ilustreaz˘ notatia grafic˘ pentru a a a ¸ a relatia de generalizare ˆ ¸ ıntre use case-uri.8: Notatia grafic˘ pentru relatia de generalizare ˆ ¸ a ¸ ıntre use case-uri Notatie grafic˘ se poate vedea ˆ figura 7.

¸i relatii care se stabilesc ˆ a ¸ s ¸ ıntre acestea.10: Exemplu de notatie grafic˘ pentru clas˘ ¸ a a 7.10. Clasele sunt folosite pentru a surprinde vocabularul sistemului ce trebuie dezvoltat. a O astfel de diagram˘ contine de obicei clase.5. entit˘¸i hardware sau concepte.46 CAPITOLUL 7.9: Tipuri de roluri jucate de actori ˆ interactiunea cu use case-ul UC ın ¸ (a) A ¸i B joac˘ acela¸i rol R (b) A ¸i B joaca roluri diferite s a s s Figura 7. Fiecare dintre aceste elemente are o multime de propriet˘¸i. UML Figura 7. at Un exemplu de notatie grafic˘ pentru clas˘ este dat ˆ figura 7. Ele pot include: • abstractii care fac parte din domeniul problemei ¸ • clase necesare la momentul implement˘rii. a aa . O clas˘ a poate fi desenat˘ ar˘tˆndu-i numai numele. Aceste elemente formeaz˘ vocabulaa a rul sistemului.5 Diagrama de clase Este folosit˘ pentru a modela structura (viziunea statica asupra) unui sistem. a at at Modelarea unui sistem presupune identificarea elementelor importante din punctul de vedere al celui care modeleaz˘. ¸ a a ın 7.prin care se distinge de alte clase.1 Clase Elementele unei clase sunt: Nume . a O clas˘ poate reprezenta entit˘¸i software.

(e) ¸ a ¸ a ¸a generalizare. Capetele de asociere pot avea nume. ce specific˘ modul ˆ care se poate naviga ˆ s a ın ınspre respectivul cap˘t de asociere. a ¸ ¸ Relatia de asociere ¸ Asocierea este o relatie important˘ ce apare foarte des ˆ diferite contexte de ¸ a ın modelare. Pe a ¸ a masur˘ ce sistemul evolueaz˘. (c) agregare. cunoscute sub denumirea de roluri. DIAGRAMA DE CLASE 47 Figura 7. leg˘turile dintre obiecte pot fi create sau distruse. Pentru fiecare element se identific˘ o multime ¸ a ¸ de responsabilit˘¸i (ce trebuie s˘ fac˘ acesta). Cea mai important˘ caracteristic˘ a lor este multiplicitatea.7. Un caz particular ¸ ¸ s al relatiei de asociere ˆ constituie relatia de agregare. a a a Relatia de asociere ofer˘ baza arhitectural˘ pentru modelarea conlucr˘rii ¸i ¸ a a a s interactiunii dintre clase.o operatie reprezint˘ implementarea unui serviciu care ¸ a poate fi cerut oric˘rui obiect al clasei. ¸ O asociere interactioneaz˘ cu obiectele sale prin intermediul capetelor de ¸ a asociere. ¸ ıl ¸ Figura 7.un atribut reprezint˘ numele unei propriet˘¸i a clasei.5.11: Notatiile grafice pentru diferite tipuri de relatii (a) asociere ¸ ¸ bidirectional˘. a a a .2 Relatii ¸ O relatie modeleaz˘ o conexiune semantic˘ sau o interactiune ˆ a a ¸ ıntre elementele pe care le conecteaz˘. (b) asociere unidirectional˘. Modelarea vocabularului unui sistem presupune ¸ identificarea elementelor pe care utilizatorul sau programatorul le folose¸te pens tru a descrie solutia problemei. a at Operatii (metode) .5. ¸i vizibilitate. dependenta. (d) dependent˘. a O clas˘ poate avea oricˆte atribute ¸i operatii sau poate s˘ nu aib˘ nici un a a s ¸ a a atribut sau nici o operatie. generalizare ¸i realizare.11 ilustreaz˘ notatiile grafice pentru diferite tipuri de relatii. at 7. Ea se folose¸te pentru a exprima o conexiune semantica ˆ s ıntre obiecte individuale apartinˆnd unor anumite clase. dupa care se definesc atributele at a a ¸i operatiile necesare ˆ s ¸ ındeplinirii acestor responsabilit˘¸i. ˆ modelarea orientat˘ obiect cele mai importante relatii a In a ¸ sunt relatiile de asociere. ¸ a Asocierile poart˘ informatii despre leg˘turile dintre obiectele unui sistem. (f) realizare Atribute .

a ¸ Relatia de agregare ¸ O agregare este o asociere ce modeleaz˘ o relatie parte-ˆ a ¸ ıntreg. Dependentele pot s˘ a ¸ ¸ a apar˘ ¸i la structurarea unui sistem ˆ pachete.48 CAPITOLUL 7. De obicei multiplicitatea este folosit˘ pentru asociatiile binare. Relatia de dependent˘ ¸ ¸a a ¸ a ıntre dou˘ elemente a O dependent˘ (figura 7. altfel spus. a Relatia de generalizare mai poart˘ denumirea de relatie de tip is a (este un ¸ a ¸ fel de). definind arhitectura sistemului. iar multiplicitatea a ın ¸i rolurile sunt plasate la extremit˘¸ile sale (figura 7. sau clasa p˘rinte). sau clasa copil). Clasa A mo¸tene¸te toate atributele ¸i s s s metodele clasei B. ˆ a ˆ general se specific˘ ¸ ıns˘ ın a numai multiplicitatea. Se folose¸te ˆ situatia ˆ care o schimbare ˆ elementul destinatie s ın ¸ ın ın ¸ (B) poate atrage dup˘ sine o schimbare ˆ elementul surs˘ (A).11 (d)) indic˘ o relatie semantic˘ ˆ ¸a ale modelului.12: Notatia grafic˘ detaliat˘ a relatiei de asociere ¸ a a ¸ ce specific˘ cˆte instante ale ale unei clase pot fi relationate cu o instant˘ a altei a a ¸ ¸ ¸a clase. pentru a elimina leg˘turi a ¸ a redundante sau irelevante pentru un anumit model. Ea poate ad˘uga noi atribute sau metode sau le poate redefini a pe cele existente.11 s a a a (c)). ˆ figur˘ o instant˘ a clasei A contine o instant˘ a clasei B (altfel spus un In a ¸a ¸ ¸a obiect B este o parte unui obiect A).12). a ¸ Reprezentarea grafic˘ a asocierii este o linie (sau drum) ce conecteaz˘ clasele a a ce particip˘ ˆ asociere. Relatia de agregare este deci un caz particular al relatiei de asociere. s at Este posibil˘ specificarea directiei unei asocieri. UML Figura 7. .11 (e)) se folose¸te pentru a modela conceptul ¸ s de mo¸tenire ˆ s ıntre clase. Aceast˘ relatie a ın a a ¸ modeleaz˘ interdependentelor ce apar la implementare.11 (b)). Ea ¸ ¸ poate avea toate elementele unei relatii de asociere. ˆ figur˘ clasa A este derivat˘ din clasa B. a clasa B este o generalizare a clasei A). as ın Relatia de generalizare ¸ Relatia de generalizare (figura 7. Spunem In a a c˘ A este clasa derivat˘ (sau subclasa. Numele asocierii este plasat pe linie. iar B este clasa de baza a a (sau superclasa. ˆ aceast˘ situatie notatia In a ¸ ¸ grafic˘ pentru relatia de asociere este o linie cu o s˘geat˘ la unul din capete a ¸ a a indicˆnd directia asocierii (figura 7. Este reprezentat˘ a ca un romb gol ata¸at la cap˘tul asocierii de lˆng˘ clasa agregat (figura 7. ˆ sensul c˘ o instant˘ a clasei derivate A este ˆ acela¸i timp o instant˘ ın a ¸a ın s ¸a a clasei de baz˘ B (clasa A este un caz particular al clasei B sau. Se folose¸te pentru a modela situatiile ˆ care un obiect s ¸ ın este format din mai multe componente.

1 Stare Prin stare se ˆ ¸elege o conditie sau situatie din viata unui obiect ˆ timpul c˘reia ınt ¸ ¸ ¸ ın a acesta satisface anumite conditii. se efectueaz˘ a operatia. O actiune reprezint˘ executia atomic˘ a unui calcul care are ca efect schim¸ a ¸ a barea st˘rii sau returnarea unei valori.˘ 7. obiectul apelat poate trece ˆ ¸ ıntr-o nou˘ stare. 7.11 (f)) se folose¸te ˆ cazul ˆ care o clas˘ (A) ¸ s ın ın a implementeaz˘ o interfat˘ (B). a a Un eveniment reprezint˘ ceva (atomic) ce se ˆ ampl˘ la un moment dat ¸i a ıntˆ a s care are ata¸at˘ o locatie ˆ timp ¸i spatiu. a Prin activitate se ˆ ¸elege executia neatomica a unor actiuni. • trecerea timpului • o schimbare a st˘rii a Evenimentele pot fi clasificate ˆ felul urm˘tor: ın a • sincrone sau asincrone • externe sau interne – externe: se produc ˆ ıntre sistem ¸i actori (de exemplu apas˘rea unui s a buton pentru ˆ ıntreruperea executiei programului. Se spune c˘ A realizeaz˘ interfata specificat˘ de a ¸a a a ¸ a B. DIAGRAMA DE STARI Relatia de realizare ¸ 49 Relatia de realizare (figura 7.13 prezint˘ un exemplu de diagram˘ de clase. dup˘ care se red˘ a a a controlul obiectului apelant. . O interfat˘ este o specificare comportamental˘ f˘r˘ o implementare asociat˘. a Evenimentele pot include: • semnale: un semnal este un stimul asincron care are un nume ¸i care este s aruncat de un obiect ¸i receptionat de altul. ¸a a a Figura 7.6. efectueaz˘ o activitate sau a¸teapt˘ aparitia ¸ a s a ¸ unui eveniment.6. ınt ¸ ¸ O diagrama de st˘ri poate contine st˘ri ¸i tranzitii. Evenimentele modeleaz˘ aparitia s a ¸ ın s ¸ a ¸ unui stimul care poate conduce la efectuarea unei tranzitii ˆ ¸ ıntre st˘ri. Ex: exceptii. Controlul este preluat de obiectul apelat. Diagrama a de st˘ri specific˘ o secvent˘ de st˘ri prin care trece un obiect de-a lungul vietii a a ¸a a ¸ sale ca raspuns la evenimente ˆ ımpreun˘ cu r˘spunsul la aceste evenimente. a ¸ a s ¸ 7. ¸a a aa a O clas˘ include o implementare. ¸ – interne: se produc ˆ ıntre obiectele ce alc˘tuiesc un sistem (de exemplu a overflow exception).6 Diagrama de st˘ri a Este folosit˘ pentru a modela comportamentul unui singur obiect. s ¸ • apeluri de operatii (de obicei sincrone): un obiect invoca o operatie pe ¸ un alt obiect. Una sau mai multe clase pot realiza o interfat˘ a ¸a prin implementarea metodelor definite de acea interfat˘.

50 CAPITOLUL 7. UML Figura 7. a .13: Exemplu de diagram˘ de clase.

14. Tranzitia a s a ¸ ¸ poate avea loc numai dac˘ conditia este satisf˘cut˘.15(a)) sau concurente a ¸ (simultan active .sunt tranzitii ˆ ¸ ¸ ıntre substari care nu produc schimbarea st¸rii obiecului. respective ¸ s ¸ ie¸irea din starea respectiv˘. Numele este reprezentat de o succesiune a ın de ¸iruri de caractere.figura 7. Contextul unei interactiuni (unde pot g˘si interactiuni) poate fi: ¸ a ¸ • sistemul/un subsistem (uzual): multimea obiectelor din sistem care cola¸ boreaz˘ ˆ a ıntre ele • o operatie: interactiuni ˆ ¸ ¸ ıntre parametri.figura 7. s a Subst˘ri . ¸ Figura 7.14: Notatia grafic˘ pentru stare ¸ a Notatia grafic˘ pentru stare este det˘ ˆ figura 7. a Elementele unei tranzitii sunt ilustrate grafic ˆ figura 7.sunt actiuni ce se produc la intrarea.16) sunt: a ın • stare initial˘: starea din care pleac˘ entitatea modelat˘. DIAGRAMA DE INTERACTIUNI ¸ 51 Figura 7.17. ¸ Starea destinatie reprezint˘ starea ˆ care ajunge obiectul dup˘ efectuarea ¸ a ın a tranzitiei.7 Diagrama de interactiuni ¸ Este folosit˘ pentru a modela comportamentul unei multimi de obiecte dintr-un a ¸ anumit context care interactioneaz˘ ˆ a ıntre ele pentru a ˆ ındeplini un anumit scop. Aceasta se ¸ a a evalueaz˘ la producerea evenimentului care declan¸eaz˘ tranzitia.15(b)). s Actiuni de intrare/ie¸ire . s St˘ri particulare (ilustrate ˆ figura 7. a a 7. Tranzitii interne . a ın a ı¸ a ¸ 7.identific˘ ˆ mod unic o stare.care pot fi disjuncte (secvential active . ¸ a a ın Elementele unei st˘ri sunt: a Nume .optional se poate specifica o actiune care s˘ se execute odat˘ cu ¸ ¸ ¸ a a efectuarea tranzitiei.7. variabile locale ¸i globale s . a a a Eveniment este evenimentul care declan¸eaz˘ tranzitia.18 arat˘ un exemplu de diagram˘ de stare.7.6.2 Tranzitie ¸ O tranzitie reprezint˘ o relatie ˆ ¸ a ¸ ıntre dou˘ st˘ri indicˆnd faptul c˘ un obiect aflat a a a a ˆ prima stare va efectua ni¸te actiuni ¸i apoi va intra ˆ starea a doua atunci ın s ¸ s ın cˆnd un anumit eveniment se petrece. s a ¸ Conditie gard˘ (guard condition) este o expresie boolean˘. ¸ ın Starea surs˘ reprezint˘ starea din care se pleac˘. a ¸ a a Actiune . ¸ a a a • stare final˘: stare ˆ care entitatea modelat˘ ˆsi termin˘ existenta.

16: Notatia grafic˘ pentru starea initial˘ (a) ¸i starea final˘ (b) ¸ a ¸ a s a .15: Notatia grafic˘ pentru st˘rile compuse: (a) care contin subst˘ri ¸ a a ¸ a disjuncte. UML Figura 7. (b) care contin subst˘ri concurente.52 CAPITOLUL 7. ¸ a Figura 7.

Un mesaj specific˘ o comunicare ˆ a ıntre obiecte. • return: returneaz˘ o valoare apelantului. Unui mesaj ˆ este asociat˘ o actiune care poate avea ca efect schimıi a ¸ barea st˘rii actuale a obiectului. • create: creeaz˘ un obiect. Un obiect se poate autodistruge. a s Primirea unei instante a unui mesaj poate fi considerat˘ o instant˘ a unui a ¸a eveniment. De obicei. dar nu ¸i multiplicitate. ˆ ıntr-o colaborare obiectele reprezint˘ prototipuri ce joaca a diferite roluri. a Tipuri de actiuni existente ˆ UML: ¸ ın • call: invoc˘ o operatie a unui obiect. Este cel mai comun tip de a ¸ mesaj. ¸i nu obiecte specifice din lumea real˘. Un obiect ˆsi poate trimite lui ˆ si a ¸ ı¸ ınsu¸ un mesaj (invocare local˘ a unei operatii). sau cu parametrii unei operatii. a interactiuni cu obiecte globale. agregare). s a ˆ Intre obiectele care particip˘ la o colaborare se pot stabili leg˘turi. a • send: trimite un semnal unui obiect. s Obiectele care interactioneaz˘ comunica ˆ a ıntre ele.7. . roluri. DIAGRAMA DE INTERACTIUNI ¸ 53 Figura 7. comunicarea facˆndu-se a prin schimb de mesaje. a • destroy: distruge un obiect. Operatia apelat˘ trebuie s˘ fie definit˘ de obiectul apelat ¸i vizibil˘ ¸ a a a s a apelantului. nas vigare. O a a leg˘tur˘ (link) reprezint˘ o conexiune semantic˘ ˆ a a a a ıntre obiecte.7. ¸ ¸ Scopul unei diagrame de interactiuni este acela de a specifica modul ˆ care ¸ ın se realizeaz˘ o operatie sau un caz de utilizare. a ¸ Obiectele care particip˘ la o interactiune pot fi lucruri concrete sau proa ¸ totipuri. Ea este o instant˘ ¸a a unei asocieri ¸i poate avea toate atributele specifice asocierii (nume. El poart˘ o informatie ¸i este urmat de o activitate.17: Elementele unei tranzitii ¸ • o clas˘: interactiuni ˆ a ¸ ıntre atributele unei clase (cum colaboreaz˘ ele).

54 CAPITOLUL 7. UML .

Ea contine obiecte. ˆ a pun accentul pe aspecte diferite. 7. a a ıi s Notatia grafic˘: este un graf ˆ care vˆrfurile reprezint˘ obiecte.8 Diagrama de activit˘¸i at Este folosit˘ pentru a modela dinamica unui proces sau a unei operatii.2 Diagrama de colaborare Diagrama de colaborare: pune accentul pe organizarea structural˘ a obiectelor a care particip˘ la interactiune.7.8. Mesajele sunt s a prefixate de un num˘r care indic˘ ordonarea ˆ timp a acestora ¸i sunt ata¸ate a a ın s s leg˘turilor dintre obiecte. Axa Y arat˘ pentru fiecare obiect a ın a linia vietii (linie punctat˘ vertical˘) ¸i perioada ˆ care obiectul preia controlul ¸ a a s ın executiei (reprezentat˘ printr-un dreptunghi subtire pe linia vietii). a a a . Ele specific˘ ¸ ¸a s a aceea¸i informatie. O stare actiune ¸ ¸ reprezint˘ executia unei actiuni. Unei leg˘turi ˆ pot fi ata¸ate mai multe mesaje. Exist˘ dou˘ tipuri de diagrame a a de interactiuni: diagrama de secvent˘ ¸i diagrama de colaborare.7. iar arcele ¸ a ın a a reprezint˘ legaturile dintre ele. Spre a ¸ deosebire de diagramele de interactiuni. DIAGRAMA DE ACTIVITATI 55 O diagram˘ de interactiuni const˘ dintr-o multime de obiecte ¸i relatiile a ¸ a s ¸ dintre ele (inclusiv mesajele care se transmit). crearea/distrugerea unui obiect). ˆ aceast˘ ¸ a ¸ ¸ In a perioad˘ obiectul efectueaz˘ o actiune.1 Diagrama de secvent˘ ¸a Diagrama de secvent˘ pune accentul pe aspectul temporal (ordonarea ˆ timp ¸a ın a mesajelor).19) care are pe axa X obiecte.˘¸ 7. a 7. direct sau prin intermediul procedurilor a a ¸ subordonate. s ¸ ıns˘ 7. care evidentiaz˘ controlul executiei de ¸ ¸ a ¸ la obiect la obiect. Notatia grafic˘ este un tabel (figura 7. diagramele de activitati scot ˆ evident˘ controlul executiei ın ¸a ¸ de la o activitate la alta. Ea nu poate fi descompus˘.1 St˘ri actiuni (action states) a ¸ Modeleaz˘ ceva care se ˆ ampl˘ (de exemplu evaluarea unei expresii. leg˘turi care se stabilesc a ¸ ¸ a ˆ ıntre acestea. Diagramele de activit˘¸i pot contine: at ¸ • st˘ri activit˘¸i ¸i st˘ri actiuni: sunt st˘ri ale sistemului a at s a ¸ a • tranzitii ¸ • obiecte 7. St˘rile actiuni a ¸ ¸ a a ¸ sunt atomice (nu pot fi ˆ ıntrerupte chiar dac˘ se produc evenimente) ¸i au o a s durat˘ nesemnificativ˘ (foarte mic˘). apelul a ıntˆ a unei operatii a unui obiect. iar pe ¸ a axa Y mesaje ordonate cresc˘tor ˆ timp.8. precum ¸i mesajele prin care obiectele comunic˘.

19: Exemplu de diagram˘ de secvent˘ care ilustreaz˘ ce se ˆ ampl˘ a ¸a a ıntˆ a atunci cˆnd un student propune un proiect a .56 CAPITOLUL 7. UML Figura 7.

Conditiile trebuie s ¸ ¸ ˆ a s˘ acopere toate posibilit˘¸ile.9.4 Ramificatii ¸ Specific˘ alternative a c˘ror alegere depinde de o expresie boolean˘.˘ 7. Pentru a at a ın sincronizarea acestora se folosesc a¸a numitele bare de sincronizare. a a at 7. activitatea lor putˆnd fi repezentat˘ cu ajutorul altor diaa a grame de activit˘¸i.8. Fie¸ s a ¸ s care tranzitie de ie¸ire trebuie s˘ aib˘ o conditie gard˘. Acestea pot s fi de dou˘ feluri: a Fork Poate avea o tranzitie de intrare ¸i dou˘ sau mai multe tranzitii de ie¸ire.20 ilustreaz˘ un exemplu de diagram˘ de activit˘¸i. realizati mai multe diagrame a ¸ separate.9 Recomand˘ri generale de realizare a diagraa melor • Diagramele s˘ nu fie nici prea complicate. ıns˘ a at Exist˘ posibilitatea ca mai multe activit˘¸i s˘ se execute ˆ paralel. altfel fluxul de control al executiei va fi a a a ¸ ambiguu (nu se ¸tie pe care cale se va continua executia). dar nici prea simpliste. ¸ s Figura 7.3 Tranzitii ¸ Atunci cˆnd se termin˘ executia unei activit˘¸i sau a unei actiuni controlul este a a ¸ at ¸ dat urmatoarei actiuni sau activit˘¸i. altfel sistemul se poate bloca. Poate avea dou˘ sau mai multe tranzitii de intrare ¸i o singur˘ ın a ¸ s a tranzitie de ie¸ire.2 St˘ri activitate (activity states) a Pot fi descompuse. ¸ at 7. Join Reprezint˘ sincronizarea a dou˘ sau mai multor fluxuri de control. ¸ ıncˆ a • ˆ Incercati s˘ nu ar˘tati prea multe tipuri de relatii odat˘ (altfel vor rezulta ¸ a a ¸ ¸ a diagrame complicate).8. .8. Activit˘¸ile de sub ¸ s a at fork sunt concurente. O ramificatie a a a ¸ poate avea o tranzitie de intrare ¸i dou˘ sau mai multe tranzitii de ie¸ire. a • Dati nume sugestive elementelor componente. Aceste conditii trebuie ¸ s a a ¸ a ¸ s˘ fie disjuncte (s˘ nu se suprapun˘). ¸ • Aranjati elementele astfel ˆ at liniile s˘ nu se intersecteze. St˘rile activitate nu sunt atomice (pot fi ˆ at a ıntrerupte de aparitia unui eveniment) ¸i au durat˘ (ˆ ¸ s a ındeplinirea lor se face ˆ ıntr-un interval de timp) 7. RECOMANDARI GENERALE DE REALIZARE A DIAGRAMELOR57 7. Dac˘ este nevoie. La join fiea a care flux de control a¸teapt˘ pˆn˘ cˆnd toate celelale fluxuri de intrare ajung s a a a a ˆ acel punct. fiecare ¸ s a ¸ s tranzitie de ie¸ire prezentˆnd un flux de control independent.

UML Figura 7.20: Exemplu de diagram˘ de activit˘¸i care ilustreaz˘ modul ˆ care o a at a ın persoan˘ ˆsi prepar˘ b˘utura favorit˘ (cafea).58 CAPITOLUL 7. sau alege optiunea de a bea cola a ı¸ a a a ¸ ˆ cazul ˆ care constat˘ c˘ a r˘mas f˘r˘ cafea. ın ın a a a aa .

De exemplu. negru. o consecint˘ ar fi c˘ ingineria program˘rii nu a ¸a a a ¸ a ar avea rost1 . at Pentru ca un anumit limbaj de modelare s˘ nu fie ambiguu.este acela de ceva care transcede. Define¸te un limbaj de specificare a obiectelor. adic˘ un limbaj de specificare a modelelor. Putem s˘ folosim un limbaj de a at a programare pentru a modela. Exemple: s Clas˘.10. Exemple: pisoiul Worf. Define¸te un limbaj de specificare a modelelor. a UML este un metamodel. a a a Limbajele ce sunt folosite pentru a exprima modele sunt numite metamodele. O optiune ar fi folosirea unui limbaj de specificare algebric˘. are a a ˆ ¸elege definitia UML este necesar˘ cunoa¸terea unei p˘rti a UML ınt ¸ a s a¸ . clasa este un meta-obiect. Notatia grafic˘ folosit˘ este ˆ a¸i notatia grafic˘ a UML. Entitate specific˘ mediului. a ¸a at ın deocamdat˘. modelele sunt specifice fiec˘rui individ a ¸i transmiterea lor poate pune probleme. Define¸te un limbaj de specificare a netamodelelor. care este mai curpinz˘tor [1]. Putem folosi.10. s Exemple: MetaClas˘. ca limbaj pentru a exprimat entit˘¸i de tip x. este s s de dorit s˘ existe un limbaj comun cu ajutorul c˘ruia s˘ se poat˘ descrie ¸i a a a a s transmit˘ modele. a • Meta-metamodel. de exemplu. putem citi meta-x. Din p˘cate. Limbajul folosit pentru definirea UML este o combinatie de notatie grafic˘. a a Autorii limbajului au considerat ˆ a c˘ acesta este compromisul cel mai bun ıns˘ a 1 Din 2 Pentru p˘cate. O asemenea descriere meta-circular˘2 pare c˘ se abate de la scopul declarat al preciziei.2 Arhitectura UML Pentru ca limbajul de specificat modele (meta-modelul) s˘ aib˘ o semantic˘ a a a precis˘. De obicei. ¸i am cˆ¸tiga astfel ˆ exactitate. O VIZIUNE FORMALA 59 7.1 O viziune formala Introducere ˆ mod curent. Exemple: Pisica.7. interaction˘m ¸i lucr˘m cu diferite obiecte. Pentru simplitate. Astfel.10 7. ˆ ciuda efortului care se poate depune pentru a obtine o exprimare a ın ¸ exact˘. folosirea sa poate duce la ambiguit˘¸i. Atribut. Limbajul ˆ care este specificat s ın metamodelul este numit meta-metamodel. la descrierea a acestuia se folose¸te de obicei un limbaj formal. Arhitectura cvadri-strat de modelare este define¸te urm˘toarele livele: s a • Obiect. a • Model. un subset ¸ a a ıns˘s ¸ a al UML este folosit pentru a modela ˆ ıntreg limbajul grafic UML. MetaAtribut. Apare astfel necesitatea de a lucra cu modele. limbaj natural ¸i ¸ ¸ a s limbaj formal. • Metamodel. Pentru a u¸ura comunicarea. Aceste obiecte pot In ¸ a s a fi foarte complexe. adic˘ cu a imagine mentale simplificate. Dac˘ aceasta s as ın a ar fi o cale sigur˘ de exprimare. Sl˘biciunea sa a a este c˘. limbajul natural. este necesar˘ definirea acestuia ˆ a a ıntr-un cadru riguros. lipsa de expeient˘ a majorit˘¸ii programatorilor ˆ acest domeniu face. a 7.10. s Culoare. aceast˘ abordare nerealist˘. Sensul folosit aici al prefixului meta.

UML ˆ ıntre expresivitate ¸i simplitate. descrieri meta-circulare apar s a destul de des. descrierea circular˘ este ˆ In a ıntrerupt˘ prin a folosirea limbajului natural. ˆ cazul UML. Un compilator de C este folosit pentru a compila ın a un compilator de C. Maxime ¸i cuget˘ri (1829) s a . dictionarele ¸i regulile gramaticare ale unei limbi pot s fi exprimate ˆ acea limb˘. Die Mathematiker sind eine Art Franzosen: redet man zu ihnen. De exemplu. Pe de alt˘ parte.60 CAPITOLUL 7. so ubersetzen sie es in ihre Sprache. — GOETHE. ¨ und dann ist es alsobald ganz etwas Anders.

defectele componentelor sunt In descoperite devreme ˆ procesul de testare. iar problemele legate de interfete ın ¸ ies ˆ evident˘ la integrare. astfel ap˘rˆnd noi etape ˆ procesul de testare. Sistemele mari sunt construite din subsisteme. Modulele contin proceduri ¸i a ¸ s functii. sistemele nu ar trebui testate de la ˆ ¸ ınceput ca un ˆ ıntreg nedivizibil. se desf˘¸oar˘ atunci ıns˘ as a cˆnd sistemul este operational.Capitolul 8 Testare Scopul dezvolt˘rii software este acela de a obtine un program conform cu specificatiile a ¸ ¸ pe baza c˘rora a fost scris ¸i care corespunde a¸tept˘rilor clientului.1 prezint˘ un proces de testare ˆ cinci etape ˆ care componentele a ın ın sunt testate mai ˆ ai individual. 2. a ¸ a a Cu exceptia programelor mici. ˆ cazul ideal. Figura 8. Acestea sunt validarea ¸i verificarea. adic˘ dup˘ faza de implementare. la rˆndul lor. Testarea unit˘¸ilor. sunt formate din module. Exemple de module sunt clase de obiecte. s Validarea este procesul prin care ne asigur˘m c˘ programul este corect din a a punctul de vedere al clientului. ˆ Intrebarea care se pune ˆ cazul valid˘rii este: ın a “Construim produsul corect?” (Are we building the right product?). Un modul reprezint˘ o colectie de componente care a ¸ depind unele de altele. Testarea modulelor. defectele descoperite ˆ program trebuie ın ¸a s ın reparate. Cea mai mare parte a acestor procese. Informatii obtinute ˆ etapele tˆrzii sunt furnizate etapelor ¸ ¸ ın a timpurii. Validarea ¸i verificarea au loc la fiecare etap˘ a procesului de dezvoltare a s a unui program. ˆ a. Subsistemele. Etapele procesului de testare sunt: 1. ˆ final. Procesul de testare este aa ın un proces iterativ. apoi sunt integrate ˆ sistem. Exist˘ dou˘ procese diferite strˆns legate de a a a a activitatea de testare. Sistemul este ıntˆ ın testat pe m˘sur˘ ce noi componente sunt integrate ¸i. Fiecare component˘ este testat˘ inde¸ a a a pendent. Verificarea este procesul prin care ne asigur˘m c˘ programul este corect a a din punctul de vedere al programatorului. Testaa s s a rea este activitatea prin care sunt scoase ˆ evident˘ defecte ale unui program ın ¸a ˆ ınainte ca programul s˘ fie livrat. Componentele individuale sunt testate pentru a se at asigura functionarea lor corect˘. Procesul de testare trebuie efectuat ˆ etape pe m˘sur˘ ce sistemul este ¸ ın a a implementat. tipuri ab61 . Totu¸i. ˆ Intrebarea care se pune aici este “Construim corect produsul?” (Are we building the product right?). sistemul este a a s ın testat cu date primite de la client.

deci. Programatorii ˆsi construiesc propriile date de test ¸i testeaz˘ codul ı¸ s a incremental. Acest a proces vizeaz˘ g˘sirea erorilor care apar datorit˘ problemelor de interactiune a a a ¸ ˆ ıntre subsisteme ¸i ˆ s ıntre interfete ale subsistemelor. precum ¸i de testarea unor propriet˘¸i ale siss s at temului. Testul de acceptare poate ın ¸a evidentia ¸i probleme legate de modul (u¸urinta) de utilizare sau probleme ¸ s s ¸ de performant˘ ale sistemului. Procesul de testare al subsistemelor trebuie. Un modul ˆ ¸ s ¸ ıncapsuleaz˘ a componente ˆ ınrudite care pot fi testate f˘r˘ a necesita prezenta altor moaa ¸ dule din sistem.62 CAPITOLUL 8. 5. Testarea sistemului. Aceast˘ faz˘ presupune testarea unei colectii a a ¸ de module care au fost integrate ˆ ıntr-un subsistem. Cele mai obi¸nuite s probleme care apar ˆ aceast˘ etap˘ sunt cele legate de nepotriviri ale ın a a interfetelor. TESTARE T estarea unitatilor T estarea modulelor T estarea subsistemelor T estarea sistemului T estul de acceptare T estarea componentelor T estarea la integrare T estarea f acuta de utilizator Figura 8. ¸a Testarea unit˘¸ilor este responsabilitatea programatorilor care dezvolt˘ comat a ponenta. ¸ 4. s˘ se con¸ a centreze pe detectarea erorilor de interfat˘ ale modulelor exersˆnd ˆ mod ¸a a ın riguros aceste interfete. Este etapa final˘ a procesului de testare ˆ a ınainte ca sistemul s˘ fie acceptat ˆ vederea folosirii lui. pe m˘sur˘ ce este scris. Aceast˘ faz˘ se ocup˘ ¸ a a a ¸i de validarea sistemului. 3. Ei sunt cei mai ˆ m˘sur˘ s˘ fac˘ acest a a ın a a a a lucru deoarece cunosc cel mai bine componenta pe care o dezvolt˘. Aceast˘ a a . Subsistemele sunt integrate formˆnd sistemul. ˆ aceast˘ faz˘ sistemul este a ın In a a testat cu date furnizate de c˘tre client ˆ loc de datele de test simulate a ın folosite ˆ celelalte etape. Testarea subsistemelor. Testul de acceptare poate scoate ˆ evident˘ ın ın ¸a erori ¸i omisiuni ˆ definirea cerintelor deoarece datele reale pot exersa s ın ¸ sistemul ˆ mod diferit fat˘ de datele de test. Testul de acceptare.1: Proces de testare ˆ cinci etape ın stracte de date sau colectii de proceduri ¸i functii.

3 ilustreaz˘ ¸ s a modul ˆ care planurile de test sunt legate de activit˘¸ile de testare ¸i dezvolın at s tare. Testarea beta presupune livrarea sistemului unui num˘r de potentiali clienti care sunt de acord s˘ foloseasc˘ sistemul. Testarea unit˘¸ilor este. ¸ Cˆnd sistemul va fi vˆndut ca un produs pe piat˘ procesul de testare poart˘ a a ¸a a denumirea de testare beta (beta testing). ˆ aceast˘ situatie sistemele sunt dezvoltate pentru un singur In a ¸ client. Acest tip de ıntˆ a utilizare real˘ a sistemului va evidentia erori care nu au fost anticipate de cei a ¸ care construiesc produsul.3: Etapele test˘rii ˆ cadrul procesului de dezvoltare software a ın activitate scoate deseori ˆ evident˘ defecte ale programului care trebuie elimiın ¸a nate. Defectele ˆ codul surs˘ trebuie localizate. Figura 8.63 Localizeaza eroarea P roiecteaza modalitatea de corectare a erorii Corecteaza eroarea Retesteaza programul Figura 8. a a a s a at prin urmare.2: Etapele unui proces de debug Specif icarea cerintelor Specif icatiile sistemului P roiectarea arhitecturala P roiectarea detaliata P lanul testului de acceptare P lanul testului de integrare a sistemului P lanul testului de integrare a subsistemelor T estarea unitatilor si a modulelor M entinere T estul de acceptare T estarea sistemului T estarea subsistemelor Figura 8. ˆ urma acestor reactii sistemul este modificat ¸i In ¸ s . Testarea ˆ vederea accept˘rii mai poart˘ denumirea de testare alpha (alın a a pha testing). Figura 8. a Ele trebuie planificate ¸i o echip˘ trebuie s˘ lucreze pe un plan de testare dezs a a voltat pe baza specificatiilor ¸i a designului sistemului. o parte a procesului de implementare. Ca rezultat al etapei de testare a unit˘¸ilor sunt a¸teptate componente conforme cu specificatiile pe baza at s ¸ c˘rora au fost dezvoltate. iar programul trebuie s˘ fie ın a a modificat pentru a satisface cerintele. Procesul de testare alpha continu˘ pˆn˘ cˆnd clientul ¸i dezvoltatorul a a a a s cad de acord asupra faptului c˘ sistemul oferit este o implementare acceptabil˘ a a a cerintelor clientului. Deci procesul de debug este o ¸ a a a parte atˆt dezvolt˘rii cˆt ¸i a test˘rii unui program. a Etapele urm˘toare presupun integrarea muncii mai multor programatori. Procesul care se ocup˘ cu localizarea ¸i corectarea erorilor din program a s poart˘ denumirea de debugging. a ¸ ¸ a a Ei vor raporta problemele ˆ alnite celor care dezvolt˘ sistemul.2 ilustreaz˘ un posibil proces de dea a bug. Testarea trebuie repetat˘ pentru a avea ¸ a siguranta c˘ modific˘rile f˘cute sunt corecte.

1 Testarea functional˘ (Black-box testing) ¸ a ˆ cazul test˘rii functionale testele sunt derivate din specificatiile programului In a ¸ ¸ sau componentei. a a a 8. ın Cazurile de test sunt specificatii care contin intr˘ri ale testului. rezultatele ¸ ¸ a a¸teptate din partea sistemului. TESTARE Cazurile de test Datele de test Rezultatele testului Rapoarte de testare P roiecteaza cazurile de test P regateste datele de test Ruleaza programul cu datele de test Compara reazultatele pentru cazurile de test Figura 8.4. dac˘ nu imposibil˘. a ¸ Testarea exhaustiv˘ este. pros ¸ a ¸ blema principal˘ care apare ˆ cazul test˘rii functionale const˘ ˆ selectarea a ın a ¸ a ın unor date de test care s˘ apartin˘ cu o probabilitate mare multimii Ie .1 Metode de testare Scopul test˘rii este de a scoate ˆ evident˘ defecte ale unui program ˆ a ın ¸a ınainte ca programul s˘ fie livrat. erorilor ˆ ¸ ıntr-un program. Ele pot fi uneori generate automat. ¸ s ın Programul este considerat o cutie neagr˘ a c˘rui comportament poate fi dea a terminat doar studiind intr˘rile ¸i ies¸irile corespuz˘toare. Un model general de testare este prezentat ˆ figura 8. precum ¸i o precizare a cerintei testate. care evidentiaz˘ un defect. fie pentru vˆnzare.5. ˆ multe a ¸ a ¸ In situatii selectia acestei multimi de date de test este bazat˘ pe experienta celui ¸ ¸ ¸ a ¸ care face testarea ¸i care folose¸te cuno¸tinte din domeniul problemei. ¸i ¸ a a ¸ s nu absenta. Schema general˘ a a s s a a modelului de testare functional˘ este ilustrat˘ ˆ figura 8.4: Model general de testare livrat fie pentru o nou˘ faz˘ de testare beta. Exist˘ s s s ¸ a ˆ a ¸i o abordare sistematic˘ ˆ care datele de intarea se ˆ ıns˘ s a ın ımpart ˆ clase de ın echivalent˘. nu ¸i de modul ˆ care este implementat acesta. ¸a s a ¸a ˆ mod normal. 8. Testarea demonstreaz˘ prezenta. cel putin impractic˘. ¸ a a ın Deoarece un test reu¸it este cel care evidentiaz˘ prezenta unei erori.64 CAPITOLUL 8. Odat˘ ¸a a ¸ a . Persoana care face testarea (tester) este preocupat˘ doar de a functionalitatea programului.1. De aceea a a a ¸ a ˆ practic˘ testarea se bazeaz˘ pe alegerea unei submultimi ale cazurilor posibile ın a a ¸ de test. s Clasele de echivalent˘ se identific˘ folosind specificatiile programului. Datele din aceea¸i clas˘ de echivalent˘ au caracteristici comune. Generarea automat˘ a cazurilor a de test este ˆ a imposibil˘ deoarece rezultatele a¸teptate nu pot fi prezise ˆ ıns˘ a s ın aceast˘ situatie. Un test reu¸it este acela care face programul s˘ se coma s a porte incorect. Datele s s ¸ de test sunt date de intrare concepute pentru testarea programului sau componentei. programul se va comporta ˆ mod similar pentru toti membrii In ın ¸ aceleia¸i clase.

s a ¸ Scopul ˆ cazul test˘rii structurale este ca fiecare drum independent din ın a program s˘ fie executat cel putin o dat˘. ˆ cazul ˆ care datele ¸ s ¸a In ın de intrare pot avea dimensiuni diferite este bine ca aceste dimensiuni s˘ varieze a la fiecare test.6: Schema general˘ a modelului de testare structural˘ a a identificate. Un singur nod va reprezenta toate instructiunile ¸ ¸ care se exucut˘ secvential pe o aceea¸i ramur˘ (atribuiri ¸i instructiunile de a ¸ s a s ¸ intare/ie¸ire). Acesta se ın a ıl ¸ obtine analizˆnd codul surs˘. Acest tip de testare se aplic˘ la unit˘¸i de program de a at dimensiuni mici (functie. 8. operatie asociat˘ unui obiect).5: Schema general˘ a modelului de testare functional˘ a ¸ a Date de test testeaza deriveaza Codul componentei Rezultate Figura 8. Muchiile grafului indic˘ fluxul executiei programului.1. Punctul de plecare ¸ a a ¸ a ˆ cazul test˘rii structurale ˆ constituie graful executiei programului. METODE DE TESTARE Date care cauzeaza un comportament anormal 65 Date de test Ie Program Rezultate care evidentiaza prezenta unor erori Rezultate Oe Figura 8.1. Ideea este ca fiecare ¸ ¸ a instructiune din program s˘ fie executat˘ cel putin o dat˘. datele de test se aleg din fiecare clas˘ (este indicat s˘ se testeze a a granitele ¸i un punct de mijloc al clasei de echivalent˘). Fiecare punct ¸ ¸ a ¸ de ramificatie trebuie testat ˆ ambele situatii (ˆ cazul ˆ care conditia este ¸ ın ¸ ın ın ¸ . Un drum independent este un drum a ¸ a care contine cel putin o muchie netestat˘ din graful executiei. Drept noduri sunt considerate punctele de deci¸ a a zie (ramificatie) din program.2 Testarea stuctural˘ (White-box testing) a ˆ cazul test˘rii structurale testele sunt construite tinˆnd cont de implementaIn a a rea programului (8.6).8.

Testele de integrare a ¸ trebuie s˘ fie dezvoltate pe baza specificatiilor sistemului. Initial ar trebui integrat˘ o configuratie mini¸ a ¸ mal˘ ¸i testat sistemul obtinut.7 prezint˘ un exemplu de testare la integrare.7: Exemplu de testare la integrare B T3 C T4 A T2 B T3 A T2 adev˘rat˘ ¸i ˆ cazul ˆ care conditia este fals˘). a a s ın ın ¸ a 8. acestea sunt corectate.1. T 2. T 2. s a ¸ este integrat. ¸i testele T 1. TESTARE T1 T1 T1 A T2 B T3 C D T4 T5 Figura 8. iar testarea integr˘rii a ¸ a componentelor ar trebui s˘ ˆ a ınceap˘ ce ˆ a ındat˘ ce sunt gata versiuni functionale a ¸ ale unor componente ale sistemului. simplificˆndu-se localizarea ¸i remedierea erorii. iar atunci cˆnd este a obtinut un rezultat eronat este greu de descoperit sursa care a cauzat eroarea. Testele T 1. T 3 a sunt mai ˆ ai rulate pe o configuratie minimal˘ format˘ din componentele A ıntˆ ¸ a a ¸i B. sistemul fiind retestat dup˘ fiecare nou˘ ad˘ugare a unei componente. ˆ acest mod este localizat˘ ¸ In a sursa problemei. a s 8.66 CAPITOLUL 8. Problemele ap˘rute se ˆ s ¸ a ıncadreaz˘ ˆ una a ın din urm˘toarele categorii: a .4 Testarea interfetelor ¸ Are loc ˆ procesul de integre a modulelor sau subsistemelor ˆ sisteme mai ın ın mari. a a a Figura 8. Obiectivul ˆ acest caz este de a detecta erori ale interfetelor sau ın ¸ presupuneri gre¸ite legate de interfete. T 3 sunt repetate pentru avea siguranta c˘ nu s ¸ a au ap˘rut erori nea¸teptate.1. Dac˘ apar erori. Fiecare modul sau subsistem are o interfat˘ care poate fi apelat˘ de ¸a a alte module. Dac˘ sunt evidentiate erori. Problema principal˘ care apare ˆ cazul acestui tip de testare const˘ ˆ a ın a ın localizarea erorilor descoperite ˆ timpul procesului de testare. Celelalte componente vor fi ad˘ugate una cˆte as ¸ a a una. Un nou modul. Acest proces de integrare ¸ presupune construirea ¸i testarea sistemului rezultat ˆ vederea descoperirii pros ın blemelor care apar datorit˘ interactiunii dintre componente. C.3 Testarea la integrare Dup˘ ce componentele programului au fost testate individual. ¸ Pentru a face localizarea erorilor mai u¸oar˘ se recomand˘ folosirea integr˘rii s a a a incrementale a componentelor. este probabil ca acestea s˘ fie a s a a cauzate de interactiunea celor trei componente. ele trebuie intea grate pentru a crea un sistem partial sau complet. De multe ori ın interactiunile ˆ ¸ ıntre componentele sistemului sunt complexe.

8. Apar ˆ cazul sistemelor ˆ timp real cˆnd se folose¸te ın ın a s memorie partajat˘ sau transmitere de mesaje. ın ¸a ¸ s ¸ Testarea la stress presupune dezvoltarea unei baterii de teste ˆ care sistemul ın este supraˆ arcat. ¸ ¸ If you think all change is for the better. Presupune validarea ¸i verificarea siss tenului pe baza specificatiilor cerintelor.1.1. METODE DE TESTARE 67 • Folosirea gre¸it˘ a interfetei. Este important ca ˆ cazul ˆ care sistemul cedeaz˘ acest lucru a ın ın a s˘ nu cauzeze coruperea datelor. Acestea sunt functii ¸i proa ¸ ¸ s ceduri. Aceast˘ eroare apare ˆ cazul interfetelor parametrizate ¸i se a a ın ¸ s poate datora trimiterii unor parametri avˆnd un alt tip decˆt cei ceruti de a a ¸ interfat˘. testarea unei clase de obiecte. testarea sistemului orientat obiect.5 Testarea la stress Are drep scop scoaterea ˆ evident˘ a performantei ¸i sigurantei sistemului. a 2. a s • Neˆ ¸elegeri legate de interfat˘. O component˘ apeleaz˘ gre¸it alt˘ coms a ¸ a a s a ponent˘. Se bazeaz˘ pe principiul cutiei negre. ˆ a a ıns˘ conceptul de clas˘ de echivalent˘ trebuie extins pentru a acoperi secvente a ¸a ¸ de operatii ˆ ¸ ınrudite. Pentru testarea lor se poate folosi testarea functional˘ sau testarea ¸ a structural˘. Aceast˘ presupunere va cauza o eroare ˆ a ın functionarea componentei apelante. ¸ • Erori de timp. sau trimiterea a unui num˘r gre¸it de parametri. sau trimiterea ˆ ¸a ıntr-o alt˘ ordine a parametrilor. Se testeaz˘ astfel comportamentul sistemului atunci cˆnd ınc˘ a a acesta cedeaz˘. 3. Se bazeaz˘ pe construirea de scenarii ˆ a ın care sunt implicate obiectele. promo . testarea unui cluster de obiecte. why put it to the test? — DISCOVERY CHANNEL.6 Testarea orientat˘ obiect a Se desf˘¸oar˘ pe mai multe nivele: as a 1. a 8. a 8. testarea individual˘ a operatiilor unui obiect. 4.1. O component˘ apelant˘ ˆ ¸elege gre¸it ınt ¸a a a ınt s specificatiile interfetei ¸i face o presupunere eronat˘ legat˘ de comporta¸ ¸ s a a mentul componentei apelate.

68 CAPITOLUL 8. TESTARE .

ne-am s at a putea referi ¸i la valori de ordin estetic. comfortul oferit. Din acest punct In a de vedere ingineria program˘rii este o disciplin˘ unic˘ ˆ a a a ıntre toate disciplinele inginere¸ti.. Codul surs˘ care implementeaz˘ un design poate fi privit ca o reprezentare a a a acelui design. a ¸ a at Pentru a putea vorbi despre calitatea unui program trebuie s˘ definim atria bute ale calit˘¸ii care ne intereseaz˘ ¸i s˘ c˘ut˘m modalit˘¸i de m˘surare a lor..Capitolul 9 Calitatea programelor Cˆnd vorbim despre calitatea unui lucru (constructie sau obiect) de obicei lu˘m a ¸ a ˆ calcul mai multi factori. ˆ a asigurarea calit˘¸ii unui program numai dup˘ scrierea Ins˘ at a codului este.eleganta. Printre ace¸tia se pot num˘ra: ın ¸ s a • calitatea realiz˘rii . s a Atunci cˆnd suntem pu¸i ˆ situatia de a compara dou˘ obiecte similare. • designul . putem spune c˘ din punctul de vedere al calit˘¸ii unul a a at este mai bun decˆt cel˘lalt. ˆ plus. un proces deosebit de costisitor. ın Este greu s˘ d˘m o definitie calit˘¸ii unui program. a ¸ • programul face ceea ce trebuie s˘ fac˘. precum ¸i modul ˆ care se comport˘ programul s s ın a atunci cˆnd interactioneaz˘ cu alte entit˘¸i. at as a a a at a trebuie s˘ putem da o reprezentare designului ¸i s˘ scriem specificatii care s˘ a s a ¸ a ghideze programatorii astfel ˆ at calit˘¸ile designului s˘ fie respectate ¸i de ıncˆ at a s implementare.. singurele aspecte observabile la un program sunt notatiile folosite ¸a ¸ pentru design ¸i scrierea codului. Ar trebui s˘ lu˘m ˆ a a ¸ at a a ın calcul aspecte de tipul: • programul functioneaz˘ ¸i.. ˆ a a¸ Inafar˘ a de interfat˘.cˆt de bine este lucrat. a a 69 . Desigur. functioneaz˘ a¸a cum are nevoie utili¸ a s ın ¸ a s zatorul s˘ functioneze. ˆ cazul programelor nu se poate evalua calitatea realiz˘rii. ˆ a programele sunt ˆ mare parte s Ins˘ ın invizibile. Toate atributele calit˘¸ii se refer˘ aici la design. ˆ general. ˆ a ˆ general este dificil de precizat cu cˆt este a a ıns˘ ın a mai bun. iar valorile estetice conteaz˘ doar pentru p˘rtile vizibile. ¸ • o combinatie ˆ ¸ ıntre design ¸i calitatea realiz˘rii. de a s ın ¸ a exemplu dou˘ scaune. dac˘ exist˘ defecte ˆ materialul a a a a ın din care este fabricat .

se refer˘ la actualizarea programului pe m˘sur˘ ce se schimb˘ a a a a a cerintele. a Simplitatea este m˘sura invers˘ a complexit˘¸ii. se poate referi la: • complexitatea fluxului de control care num˘r˘ c˘ile posibile de executie ale aa a ¸ unui program. la rˆndul a a at a ei. • complexitatea fluxului de informatii care num˘r˘ cantitatea de date care ¸ aa sunt transmise ˆ program sub form˘ de date de intrare/ie¸ire sau paraın a s metri ai functiilor.are drep scop eliminarea erorilor din program. ın a s ınv˘t s Putem da ˆ a o m˘sur˘ obiectiv˘ tutror acestor caracteristici? R˘spunsul ıns˘ a a a a este negativ. ¸ Uzabilitatea are ˆ vedere cˆt de u¸or este programul de ˆ a¸at ¸i de folosit. atunci cˆnd scriem un program. . Un program este eficient dac˘ utilizeaz˘ ˆ a a ıntr-un mod judicios resursele disponibile (memorie. ci este ¸ rezultatul unui proces de rescriere ¸i simplificare a variantei initiale a progras ¸ mului.se comport˘ bine ˆ situatii anormale (de exemplu lipsa unei a ın ¸ resurse necesare). CALITATEA PROGRAMELOR • programul poate fi adaptat pe m˘sur˘ ce nevoile utilizatorului se schimb˘. • adaptiv˘ . Eficienta este ˆ ¸ ¸ ıntotdeauna mai putin im¸ portant˘ decˆt siguranta. procesor. Singurele atria bute m˘surabile sunt cele care vizeaz˘ codul surs˘. retea). uzabili¸ s ın a tatea programului. Exist˘ mai multe tipuri de ˆ a ıntretinere: ¸ • corectiv˘ . ˆ ¸ ¸ ıntretinerea ¸i.presupune ad˘ugarea de functionalit˘¸i care ar fi trebuit s˘ fie a a ¸ at a oferite. a a a Ace¸ti factori nu pot fi m˘surati ˆ mod absolut. ¸ • complexitatea ˆ ¸elegerii care se refer˘ ca num˘rul identificatorilor ¸i opeınt a a s ratorilor folositi. a • perfectiv˘ . deci sunt criterii subiective. ¸ Scopul. Un program este sigur dac˘ este a • complet . CAPITOLUL 9. este s˘ obtinem un cod surs˘ cˆt a a ¸ a a mai simplu posibil. De obicei acest deziderat nu se obtine din prima. Este mai u¸or s˘ facem un program sigur s˘ fie eficient a a ¸ s a a decˆt un program eficient s˘ fie sigur. a a ˆ Intretinerea se refer˘ la u¸urinta cu care poate fi modificat ulterior designul ¸ a s ¸ programului. nu ˆ ultimul rˆnd.70 • programul este sigur. ˆ a ne furnizeaz˘ cˆteva s a ¸ ın ıns˘ a a concepte la care ne putem referi atunci cˆnd vorbim despre calitatea unui proa gram.se comport˘ ˆ a ıntotdeauna a¸a cum este a¸teptat. s s • robust .trateaz˘ toate intr˘rile posibile. Fiecare dintre atributele de mai sus poate fi apreciat ˆ mod ın diferit de c˘tre diferite persoane. Ele sunt siguranta. a a • consistent . Acestea sunt simplitatea ¸i a a a s modularitatea codului surs˘. Complexitatea. eficienta.

71 Modularitatea. poate fi m˘surat˘ uitˆndu-ne la coeziunea a a a a ¸i cuplajul modulelor din program. get a million miles per per gallon. InfoWorld . pe de alt˘ parte. Coeziunea se refer˘ la cˆt de bine lucreaz˘ s a a a ˆ ımpreun˘ componentele unui modul. a Rolls-Royce would today cost $100. — ROBERT CRINGLEY. Scopul ˆ constituie obtinerea unui progam ale c˘rui module au ıl ¸ a un grad ˆ ınalt de coeziune (fiecare ˆ ındepline¸te o sarcin˘ specific˘) ¸i ˆ s a a s ıntre care exist˘ cˆt mai putine dependente (cuplaj mic). a a ¸ ¸ If the automobile had followed the same development as the computer. iar cuplajul m˘soar˘ gradul de interactiune a a a ¸ ˆ ıntre module. and explode once a year killing everyone inside.

72

CAPITOLUL 9. CALITATEA PROGRAMELOR

Capitolul 10

Metrici pentru programe
Imaginati-v˘ c˘ luati un taxi ca s˘ mergeti pˆn˘ la teatru ¸i c˘ la sfˆr¸itul cursei ¸ a a ¸ a ¸ a a s a as ¸oferul v˘ cere echivalentul a 10 euro. Tema pentru acas˘ este: apreciati justetea s a a ¸ ¸ pretului. ¸ Departe de a ne a ne l˘sa prad˘ dezgustului ˆ fata unei probleme atˆt de a a ın ¸ a triviale, vom ˆ ıncerca totu¸i s˘ analiz˘m situatia. O prim˘ ˆ s a a ¸ a ıntrebare ar fi: cˆt a de departe este teatrul? Ne a¸tept˘m ca cu cˆt distanta este mai mare, cu atˆt s a a ¸ a pretul s˘ fie mai mare. Probabil c˘ nu exist˘ o tax˘ specific˘ pentru mersul ¸ a a a a a la teatru, una pentru mersul la ¸trand ¸i una pentru mersul la universitate. s s Oricum, aceasta este doar o speculatie. Cu surprindere suntem informati c˘ ˆ ¸ ¸ a ın New York, ˆ ıntr-adev˘r, cursele se pl˘tesc ˆ functie de distant˘, dar exist˘ ¸i o a a ın ¸ ¸a as exceptie la aceast˘ regul˘. Toate cursele care merg spre Manhattan cost˘ 30 de ¸ a a a dolari, oricare ar fi punctul de plecare. Scandalos, ce mai. S˘ facem ipoteza simplificatoare c˘ teatrul la care vrem s˘ mergem nu este a a a ˆ New York. Corect ar fi ca ˆ ın ınainte de a ne urca ˆ taxi s˘ ˆ ın a ıntreb˘m cˆt ne a a va costa drumul. ˆ cel mai bun caz, ¸oferul va ˆ In s ıntinde plictisit degetul spre firma de pe capota, morm˘ind ceva despre capacitatea noastr˘ de a decodifica a a alfabetul latin ¸i cifrele arabe. Minunat! Acum ¸tim cˆt cost˘ ca s˘ mergem cu s s a a a taxiul un kilometru. Din nefericire, nu ¸tim care este distanta pˆn˘ la teatru. s ¸ a a Un set de instrumente de n˘dejde ne vine ˆ ajutor. Punem rigla pe hart˘, a ın a facem ni¸te socoteli ˆ care intervine ¸i scara h˘rtii ¸i obtinem o estimare a s ın s a¸ s ¸ distantei. ˆ a o ˆ ¸ Inc˘ ınmultire ¸i obtinem un pret. Acesta fiind mult mai mic decˆt ¸ s ¸ ¸ a suma de bani pe care o avem ˆ portofel, ne urc˘m victorio¸i ˆ taxi. ın a s ın Din p˘cate, pretul de 10 euro care ni se comunic˘ la sfˆr¸it este motivul unei a ¸ a as nemultumiri evidente din partea noastr˘. Pe m˘sur˘ ce anii trec ¸i devenim mai ¸ a a a s ˆ ¸elepti, afl˘m c˘: ınt ¸ a a • Harta este imperfect˘. a • M˘surarea distantei cu rigla este imprecis˘. a ¸ a • Taxiul nu merge ˆ linie dreapt˘, ci pe ¸osele ın a s • Chiar cˆnd merge pe ¸osele, oarece ocoli¸uri ajut˘ la sporirea veniturilor a s s a ¸oferului. s • Pe lˆng˘ pretul pe kilometru exist˘ ¸i o tax˘ fix˘, de pornire, care se a a ¸ a s a a adaug˘ la suma pl˘tit˘. a a a 73

74

CAPITOLUL 10. METRICI PENTRU PROGRAME • Pretul pe care l-am citit era pretul pentru ziu˘; pretul pentru noapte era ¸ ¸ a ¸ scris cu cifre care se vedeau doar ziua. • Presiunea pneurilor taxiului poate sc˘dea, accidental sau nu, pentru a a spori aderenta pe timp de iarn˘ ¸i a m˘ri num˘rul de revolutii pe care le ¸ as a a ¸ fac rotile atunci cˆnd o anumit˘ distant˘ este parcurs˘. ¸ a a ¸a a • Pretul de pe firma luminoas˘ se poate s˘ nu fie sincronizat cu cel de pe ¸ a a taximetru.

Acum, adev˘rata tem˘ pentru acas˘ este s˘ stabiliti care este costul de a a a a ¸ dezvoltare al unui program. Presupuneti c˘ sunteti clientul. Apoi, presupuneti ¸ a ¸ ¸ c˘ sunteti ¸oferul. a ¸ s

10.1

Motivatii ¸

Atunci cˆnd un prieten ne ˆ a ıntreab˘ cum merge treaba la programul la care a lucr˘m ne putem m˘rigini s˘ spunem “bine” sau “cam r˘u”. Este acceptabil a a a a s˘ expim˘m astfel opinii personale, bazate pe intuitie ¸i afecte. Dar cˆnd ¸eful a a ¸ s a s aude c˘ proiectul merge “cam r˘u”, el vrea s˘ ¸tie de ce merge “cam r˘u”, care a a as a este distanta pˆn˘ la “acceptabil” ¸i ce trebuie f˘cut ca s˘ se ajung˘ la “foarte ¸ a a s a a a bine”. Avem nevoie a¸adar de unit˘¸i de m˘sur˘ pentru a cuantifica diverse ass at a a pecte ce apar ˆ cadrul dezvolt˘rii de programe. Ne intereseaz˘ cˆt de mare ın a a a este un program, cˆt de complex, cˆt de bine testat. De asemenea, care este a a timpul necesar dezvolt˘rii programului, de cˆ¸i oameni avem nevoie, care este a at productivitatea muncii, care sunt costurile de dezvoltare. S-au propus foarte multe modalit˘¸i de m˘surare a activit˘¸ilor ce intervin ˆ at a at ın timpul dezvolt˘rii unui produs. Aceasta exemplific˘ interesul foarte mare pena a tru subiect. Totu¸i, nu exist˘ ˆ a o metodologie unanim acceptat˘ de a face s a ınc˘ a m˘sur˘tori, de¸i unele metodologii sunt mai populare decˆt altele. Fiec˘rei mea a s a a todologii i se pot aduce critici incomode ¸i, din p˘cate, ˆ general ˆ s a ın ındrept˘¸ite. at Oricum, m˘sur˘torile imperfecte sunt mai bune decˆt nici o m˘sur˘toare, cu a a a a a conditia s˘ con¸tientiz˘m imperfectiunile. Cum avem la dispozitie multiple me¸ a s a ¸ ¸ todologii de m˘surare, aceasta ne poate spori ˆ a ıncrederea ˆ estim˘rile f˘cute. ın a a

10.2
10.2.1

Metrici de baz˘ a
KLOC

KLOC este un acronim pentru “kilo lines of code” (mii de linii de cod). De¸i s aici p˘str˘m acronimul termenilor ˆ limba englez˘, vom citi KLOC ca “mii linii a a ın a cod”. KLOC este o m˘sur˘ neechivoc˘ a dimensiunii unui program. Gre¸eala a a a s care se poate face este s˘ se considere c˘ aceast˘ metric˘ poate fi folosit˘ pentru a a a a a a trage direct concluzii ˆ alte domenii. De exemplu, programatorii care scriu ın mai multe KLOC muncesc mai mult, deci trebuie pl˘titi mai bine. Sau, prograa ¸ mele care au mai multe KLOC sunt mai complexe. Se pot da exemple multiple ˆ care programatori harnici la KLOC sunt programatori neexperimentati1 . ın ¸ Deasemenea, programe scurte pot fi deosebit de complicate.
1 Eufemismele

ˆsi au, se pare, c˘teodat˘, utilitatea lor. ı¸ a a

10.3. EVALUAREA COSTURILOR

75

10.2.2

PM

PM este un acronim pentru “person-month”2 (om-lun˘). Aceasta reprezint˘ o a a m˘sur˘ a efortului pe care o persoan˘ angajat˘ ˆ depune pe parcursul unei luni. a a a a ıl O echip˘ de 6 persoane care lucreaz˘ dou˘ luni ¸i jum˘tate efectueaz˘ 15 PM. a a a s a a Si aceasta este o m˘sur˘ oarecum imprecis˘: se refer˘ la un om nemotivat, la un ¸ a a a a om care lucreaz˘ ¸i la sfˆr¸it de s˘pt˘mˆn˘, sau la un om care este ˆ concediu as as a a a a ın medical? Luna ˆ cauz˘ este luna august sau luna februarie ˆ ın a ıntr-un an nebisect?

10.3

Evaluarea costurilor

Utilitatea fundamental˘ a metricilor este evaluarea costurilor. Aceasta induce pe a cale de cosecint˘ ¸i evaluarea altor aspecte, cum ar fi timpul necesar dezvolt˘rii, ¸a s a alocarea resurselor, etc.

10.3.1

COCOMO

COCOMO (COnstructive COst MOdel — Model constructiv al costurilor) este unul din modelele de evaluarea a costurilor cel mai bine documentate. El a fost propus de Boehm ˆ 1981. ın COCOMo propune trei nivele de rafinare a estim˘rii: COCOMO de baz˘, a a COCOMO intermediar ¸i COCOMO detaliat. s COCOMO de baz˘ propune urm˘toarea leg˘tur˘ dintre efort (exprimat ˆ a a a a ın luni-om) ¸i dimensiunea programului (exprimat˘ ˆ mii linii cod): s a ın E = b KLOC c . (10.1)

ˆ ecuatia 10.1 b ¸i c sunt constante care depind de tipul proiectului care In ¸ s este executat. Boehm a clasificat proiectele astfel: Organice Echipa de dezvoltare este rlativ mic˘ ¸i dezvolt˘ o aplicatie ˆ as a ¸ ıntr-un mediu familiar. ˆ general, oamenii implicati au experientt˘ la lucrul cu proiecte In ¸ ¸a similare. Aceste proiecte sunt rareori foarte mari. Integrate Aceste proiecte se desf˘¸oar˘ ˆ medii ˆ care exist˘ restrictii severe. at a ın ın a ¸ Proiectul va fi integrat ˆ ıntr-un produs existent care este inflexibil. Exemple de astfel de sisteme: controlarea traficului aerian, monitorizarea pacienttilor. ¸ Semideta¸ate O form˘ intermediar˘ ˆ s a a ıntre cele do˘a de mai sus. Echipa este a format˘ dintr-un amestec de oameni experimentati ¸i mai pu¸in expeimentati, a ¸ s s ¸ proiectul poate fi destul de mare, dar nu excesiv etc. Parametrii lui COCOMO de baz˘ pentru fiecare dintre aceste tipuri de a proiecte, sunt prezentati ˆ tabelul 10.1. ¸ ın Prima versiune a lui COCOMO presupunea c˘ se folose¸te modelul de deza s voltare ˆ cascad˘. De atunci, au avut loc schimb˘ri semnificative ˆ modul de ın a a ın dezvoltare a programelor. De aceea, estim˘rile COCOMO deveniser˘ irelevante. a a Am ales s˘ prezent˘m aici COCOMO de baz˘ pentru c˘ acest model reprezint˘ a a a a a modelul de inspiratie ¸i referint˘ pentru multe metrici actuale. ¸ s ¸a
2 O alt˘ denumire folosit˘ pentru aceast˘ cantitate, “man-month”, poate fi interpretat˘ ca a a a a discriminatorie.

3. similar˘ cu cea din modelul COCOMO de baz˘. P M = (1 − Preuse ) N OP P ROD (10.20 Tabela 10. ecranele foarte complexe primesc 3.3) . Num˘rul punctelor obiect se calculeaz˘ astfel: a a • Se inventariaz˘ ecranele care trebuie afi¸ate.0 b = 3.2 COCOMO 2 O versiune actualizat˘ a COCOMO a fost propus˘ de Boehm ˆ 1995.6 c = 1. ci ¸i posibilitatea obtinerii unor estim˘ri ˆ fazele incipiente a s ¸ a ın ale dezvolt˘rii. a • Fiecare modul ˆ limbaj de nivel mai jos ce trebuie scris pentru a oferi ın servicii programului orienta-obiect prime¸te 10 puncte. cum ar fi prototipizarea. Media num˘rului s ¸ a liniilor de cod necesare pentru a implementa un punct obiect poate varia de la 2 la 40 ˆ ıntr-un limbaj orientat obiect.1: Valorile parametrilor pentru COCOMO de baz˘ a 10. (10. Aceast˘ a a ın a versiune este referit˘ ca COCOMO 2. Acest nou model nu ˆ ınseamn˘ doar o rafinare a a estim˘rii pe etape. Ecranele simple primesc 1 a s punct obiect. METRICI PENTRU PROGRAME organic semideta¸at s integrat b = 2. Atunci cˆnd se ralizeaz˘ un prototip gradul de reutilizare a codului este a a semnificativ. a a E = a sizeb m. a COCOMO 2 recunoa¸te existenta mai multor modele ¸i tehnici de dezvols ¸ s tare. iar cele dificile 8. • Se inventariaz˘ rapoartele care trebuie obtinute. a¸adar formula de estimare a efortului ia ˆ calcul acest factor s ın (Preuse ). Un raport simplu prime¸te a ¸ s dou˘ puncte obiect.12 c = q.4 b = 3. cele moderat de complexe 5. este discutabil˘ a potrivirea acestora pentru programul pentru care se face evaluarea.3. Productivitatea este notat˘ cu PROD: valorile acestui parametru se a extrag din tabelul 10.2. Evident. ˆ functie s a ın ¸ de intrumentele utilizate ¸i de performanta programatorilor. utilizarea de limbaje de programare moderne etc. s De obicei se folosesc statisticile anterioare pentru a estima cˆte linii de cod a sunt necesare pentru a implementa un punct obiect.2) Proiectarea initial˘ Estim˘rile folosite pentru acest stadiu folose¸te formula ¸ a a s 10. Estimarea se bazeaz˘ pe evaluarea num˘rului punctelor obiect (NOP ¸ a a — number of object point). Boehm sugereaz˘ c˘ productivitatea variaz˘ ˆ a a a ıntre 4 ¸i 50 puncte obiect pe lun˘.05 c = 1. a Prototipizarea initial˘ Surpinde efortul necesar realiz˘rii unui prototip al ¸ a a aplicatiei. ecranele moderat de complexe primesc 2.76 CAPITOLUL 10. dezvoltarea pe compomente.

Aici. a P M = A SizeB M + P Mm (10.5. Ace¸ti factori sunt: siguranta ¸i complexitatea produsului (RCP X). experienta personalului (P REX). Acum ˆ a s s a s ¸ a ıns˘ se iau ˆ calcul 17 factori.3. iar a a 6 corespunde unei valori mari pentru factorul corespunz˘tor. Se a In a a folose¸te aceea¸i formul˘ ca ¸i cea de la proiectarea initial˘ (10.5) Ultimul termen al formulei 10. pentru a integra codul a In generat automat ˆ ıntr-un program este nevoie s˘ se scrie o anumit˘ cantitate a a (suplimentar˘) de cod. Ea este calculat˘ estimˆnd num˘rul de puncte obiect ¸i a ın a a a s apoi convertindu-l ˆ KLOC. Oricum. capacitatea personalului (P ERS). unde 1 corespunde unei valori mici. Dac˘ a a a a a consider˘m Pauto procentul de cod generat automat din aplicatie. Pentru fiecare se face o at ¸a estimare direct˘ pe o scar˘ de la 1 la 6.4). ˆ general. comprimarea ¸ planului (SCED). fat˘ de cei numai 7 folositi pˆn˘ acum.10. s ¸ s gradul de reutilizare cerut (RU SE). f˘r˘ ¸ ın aa a mai enumta formulele ˆ care ace¸tia intervin. facilit˘¸i pentru asistent˘ (F CIL). ¸ ın s • Atributele produsului – Siguranta cerut˘ a sistemului ¸ a – Complexitatea modulelor sistemului – Dimensiunea bazei de date folosite – Procentul cerul de cod reutilizabil – Dimensiunea documentatiei cerute ¸ • Atributele sistemului de calcul – Constrˆngerile privind timpul de executie a ¸ . productivitatea ˆ cazul gener˘rii automate de a ın a cod (AT P ROD) este mai mare decˆt dac˘ nu s-ar folosi aceast˘ tehnic˘.4 este folosit atunci cˆnd o cantitate ˆ a ınsemnat˘ a de cod este generat˘ automat (ASLOC).2: Valorile parametrului P ROD (productivitatea) ˆ functie de niveın ¸ lul programatorilor. dificultatea platformei (P DIF ). valoarea coeficientului a este 2. ın Termenul M este bazat pe 7 factori ai proiectului ¸i ai procesului de dezs voltare. Dimensiunea sistemului size este exprimat˘ ˆ KLOC. ın a ¸ a a Ne vom rezuma doar la a enumera factorii ce sunt luati ˆ considerare.6) Dup˘ proiectare ˆ acest stadiu estimarea poate fi f˘cut˘ mai precis.4) M = P ERS RCP X RU SE P DIF P REX F CIL SCED (10. atunci a ¸ P Mm = (ASLOC Pauto )/AT P ROD (10. EVALUAREA COSTURILOR Experienta ¸i capacitatea progrmatorilor ¸ s PROD (NOP/lun˘) a Foarte mic˘ a 4 Mic˘ a 7 77 Nominal˘ a 13 Mare 25 Foarte mare 50 Tabela 10.

nu ˆ a a ıns˘ ınseamn˘ c˘ vom avea a a un copil ˆ urm˘toarea lun˘. Conte a g˘sit urm˘toarea relatie ˆ a a ¸ ıntre ˆ ıntre productivitatea medie L (m˘surat˘ ˆ linii de cod pe om-lun˘) ¸i dimensiunea a a ın a s echipei (P ): 1 L = 777 √ . (10.3.3 Distributia fortei de munc˘ ˆ timp ¸ ¸ a ın Faptul c˘ avem o estimare a efortului necesar dezvolt˘rii unui program exprimat a a ˆ om-lun˘ (PM).33+0.2 (B−1.7) Factorul IN DP reprezint˘ costul individual pentru un membru al echipei.78 CAPITOLUL 10.2 (B−1.9) 10. nu ˆ ın a ınseamn˘ c˘ ¸tim cˆt va dura dezvoltarea ¸i nici cum vom a as a s organiza munca. METRICI PENTRU PROGRAME – Constrˆngerile priving memoria a – Volatilitatea plaformei de dezvoltare • Atributele personalului – Capacitatea analittilor ¸ – Capacitatea programatorior – Continuitatea personalului – Experienta analistului ˆ domeniul problemei ¸ ın – Experienta programatorilor ˆ domeniul problemei ¸ ın – Experienta ˆ limbajele ¸i instrumentele folosite ¸ ın s • Atributele proiectului – Utilizarea instrumentelor program – Comprimarea planului de dezvoltare – Gradul de lucru ˆ mai multe echipe ¸i calitatea comunic˘rii ˆ ın s a ıntre acestea Estimarea pretului proiectului ¸ SC = Ef f ort RELY T IM E ST OR T OOL EXP IN DP (10. s 3 Din specia homo sapiens .10) p Aceasta ˆ ınseamn˘ c˘ productivitatea individual˘ scade exponential odat˘ cu a a a ¸ a cre¸terea dimensiunii echipei. De exemplu. ın a a Pe baza unor date statistice. ¸tim c˘ unei femei3 ˆ trebuie nou˘ luni pentru a na¸te un copil. a Estimarea duratei proiectului T DEV = 3 (P M )0.33+0.01) PSCHED (10.8) (10. s a ıi a s Dac˘ strˆngem ˆ a a ıntr-o echip˘ nou˘ femei ˆ arcinate.01) T DEV = 3 (P M )0.

12) 10. deci pˆn˘ atunci trebuie a a a a s˘ fie gata.10. • Stim c˘ bugetul clientului pentru proiect este de 500 mii de dolari. ı¸ s a ı¸ • Avem 12 luni la dispozitie ca s˘ termin˘m treaba. Acestea ¸i-au dovedit destul de s des efectul dezastruos pe care ˆ au asupra clientilor sau a echipei de dezvoltare.11) (10. ¸ a a Derivarea face clasa copil dependent˘ de clasa p˘rinte.4 Metrici orientate obiect Adˆncimea arborelui de derivare M˘soar˘ lungimea celui mai lung drum a a a de la o clas˘ r˘d˘cin˘ pˆn˘ la o clas˘ derivat˘ (indirect) din aceasta. Vom spune c˘ dureaz˘ 8 luni: odat˘ ce au investit atˆt a a a a ˆ program. deci proiectul va dura 12 ¸ a a luni. ın a a Aceste decizii sunt numite “decizii politice”. a • Programul va dura cam un an de zile. ıl ¸ 10. noi vom cere 950 ¸ a de mii. Cerem ¸ a 6 sute de mii ¸i ne ˆ ¸elegem la 5. prezent˘m cˆteva modalit˘¸i ˆ care divese organizatii decid totu¸i s˘ a a at ın ¸ s a ˆsi evalueze costurile ¸i s˘ ˆsi planifice activitatea. (P − 1)γ . ˆ functie de structura echipei. de a dimensiune P .3. s ınt • Vrem s˘ prezent˘m produsul la CeBit anul viitor. dar ˆ nici un caz ¸eful meu nu va fi ın s de acord cu asta. Legea lui Parkinson: munca se ˆ ıntinde pe timpul avut la dispozitie. Consider˘m c˘ productivitatea individual˘ a unui programator este L. a a a a a a a a Cu cˆt adˆncimea arborelui de derivare este mai mare.4. ˆ a cu m˘car 1. Proa a ductivitatea medie a unui membru al echipei va fi: Lγ = L − l(P − 1)γ . Modific˘ri ˆ clasa a a a ın p˘rinte pot avea ca efect distrugerea functionalit˘¸ii clasei copil. unde 0 ≤ γ ≤ 1. ˆ ciuda negatiei a In ¸ din titlu. ˆ s Intr-o echip˘. a ¸ at .4 Cum nu se evalueaz˘ costurile a Probabil titlul acestei sectiuni ar fi trebuit s˘ fie “cum nu se evalueaz˘ ¸tiintific ¸ a as ¸ costurile” sau “cum nu este cinstit s˘ se evaleaze costurile”. cu atˆt efortul necesar a a a ˆ ¸elegerii arhitecturii cre¸te. productivitatea total˘ a echipei se exprim˘ astfel: s a a Ltot = P Lγ = P (L − l(P − 1)γ ) Vezi pagina cursului pentru grafice (10. vor trebui s˘ mai suporte dezvoltarea cˆteva luni. Consider˘m ¸ ¸ ¸ ıns˘ a a γ coeficientul specific echipei care d˘ num˘rul mediu de leg˘turi ˆ a a a ıntre membrii echipei. O adˆncime mare a arborelui de derivare poate fi ınt s a o indicatie a unei proiect˘ri stˆngace. iar a a a pierderea de productivitate datorat˘ unei leg˘turi de comunicare este l. fiecare membru trebuie s˘ ˆsi coordoneze activitatea cu ceilalti a ı¸ ¸ membri ai echipei. A¸adar. un membru poate fi nevoit s˘ In ¸ a comunice cu toti ceilalti P − 1 sau cu mai putini. METRICI ORIENTATE OBIECT 79 Putem aborda problema ¸i din punct de vedere teoretic. ¸ • Stim c˘ competitorul nostru a cerut 1 milion de dolari.

a — MIHAI EMINESCU. a Precum Atlas ˆ vehime sprijinea cerul pe um˘r ın a A¸a sprijin˘ el lumea ¸i vecia ˆ s a s ıntr-un num˘r. ¸ a Existenta unor cuplaje inutile are un efect negativ asupra modularit˘¸ii pro¸ at dusului ¸i adesea ˆ s ımpiedic˘ refolosirea codului. ¸ ın Este posibil ca ˆ anumite situatii s˘ se exagereze cu num˘rul de clase ın ¸ a a derivate create. Cuplare Prin num˘r de cuplare al unei clase ˆ ¸elegem num˘rul de clase cu a ınt a care aceasta interactioneaz˘ direct. De obicei. StudentAn4 se poate crea o singur˘ clas˘ Student a a care s˘ contin˘ atributul an studiu.80 CAPITOLUL 10. Scrisoarea I . a Un num˘r mare de metode complexe indic˘ dificult˘¸i posibile ˆ ˆ a a at ın ıntretinerea ¸ clasei. ın ¸ ın StudentAn2. ˆ locul claselor StudentAn1. Proiectantii ˆ ¸ ıncep˘tori adesea se ˆ seal˘ considerˆnd c˘ simpla grupare a a ın¸ a a a functiilor dintr-un program procedural ˆ cˆteva clase are ca efect obtinearea ¸ ın a ¸ unei arhitecturi orientate obiect. a ¸ a Metode bazate pe ponderi Se num˘r˘ metodele unei clase ¸i se estimeaz˘ aa s a complexitatea fiec˘reia dintre acestea. De exemplu. ce poate avea drept consecint˘ un slab grad de reutilizare a codua ¸a lui. un num˘r mare de metode ˆ a ıntr-o clas˘ sugereaz˘ o proiectare a a neinspirat˘.5 Probleme la folosirea metricilor • Lipsa de acuratete • Rezistenta din partea angajatilor Folosirea lor ˆ alte scopuri decˆt cele ¸ ın a pentru care au fost create • Pot stˆrni disensiuni ˆ cadrul echipei de dezvoltare a ın Aceste probleme pot fi exacerbate de faptul c˘ angajatii devin mai preocupati de a ¸ ¸ satisfacerea criteriilor impuse de o anumit˘ metric˘ decˆt de a colabora pentru a a a a dezvolta produsul la care lucreaz˘. ˆ multe situatii. a a O valoare mare a acestui num˘r pentru o clas˘ este o indicatie asupra a a ¸ importantei sale sporite ˆ sistem. METRICI PENTRU PROGRAME Num˘rul de clase derivate M˘soar˘ num˘rul de clase derivate direct dintra a a a o anumit˘ clas˘. StudentAn3. a 10.

81 . [2] Douglas Bell. [4] William Lorensen Frederick Eddy William Premerlani James R Rumbaugh. A Programming Approach. Addison-Wesley. Blaha. [6] OMG. [5] Roy Miller Ken Auer. [7] Roger Penrose. 2001. 2000. [9] Bjarne Stroustrup. 1991. Unified Modeling Language (UML) Specification: Infrastructure. OMG. 2005. Object-Oriented Modeling and Design. 1997. Pearson Education. Software Engineering. The Unified Modeling Language User Guide. The C++ Programming Language. [8] Jan Somerville. .. 1989. The Emperor’s New Mind. 1999. James Rumbaugh. editor.Bibliografie [1] American Heritage Dictionary of the English Language. Software Engineering. Penguin Books. AddisonWesley. American Heritage Dictionaries. [3] Ivar Jacobson Grady Booch. Michael R. Addison-Wesley. 6 edition. 2000.

Sign up to vote on this title
UsefulNot useful