Tehnologii de elaborare a proiectelor

OVIDIU GHEORGHIES ADRIANA GHEORGHIES

Facultatea de Informatic a Universitatea Al. I. Cuza, Iai 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 Cuvnt a nainte 2 Introducere 3 Modele de dezvoltare a programelor 3.1 Etapele dezvoltrii 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 Vericare . . . . . . . . . . . 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 Unied Process . . . . . . . 3.7.1 Pornire . . . . . . . . . . . . 3.7.2 Ranare . . . . . . . . . . . . 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 Specicarea cerintelor . . . . . . . . . . . . . . . . . . . . . . . . 29 5 Concepte orientare obiect 5.1 Obiecte. Clase . . . . . . . . . . . . . 5.2 Principiile dezvoltrii orientat obiect a a 5.2.1 Incapsulare . . . . . . . . . . . 5.2.2 Mostenirea . . . . . . . . . . . 5.2.3 Polimorsmul . . . . . . . . . . 3 31 31 32 32 33 33

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

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 stri . . . . . . . . . . . . . . . . . . . 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 activiti . . . . . . . . . . . . . . . . . at 7.8.1 Stri actiuni (action states) . . . . . . . . . . a 7.8.2 Stri activitate (activity states) . . . . . . . . a 7.8.3 Tranzitii . . . . . . . . . . . . . . . . . . . . . 7.8.4 Ramicatii . . . . . . . . . . . . . . . . . . . 7.9 Recomandri 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

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

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

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

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

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

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

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

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

CUPRINS 10.3.3 Distributia fortei de munc timp a n 10.3.4 Cum nu se evalueaz costurile . . . a 10.4 Metrici orientate obiect . . . . . . . . . . 10.5 Probleme la folosirea metricilor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 78 79 79 80

CUPRINS

Capitolul 1

Cuvnt a nainte
Am scris aceste note de curs din convingere. Pornind de la experienta personal, a credem c studierea materialului prezentat aici poate a mbunti modul care a at n privim i ne implicm dezvoltarea unui program. Noi sine reectm asupra s a n n a celor scrise aici i le folosim ca referint. s a Scopul principal al activitii 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 dezvoltrii proa a a fesionale de programe. Manualul de fata nu se mrginete la a prezenta doar a s notiunile de baz strict necesare pentru acest prim pas. Am decis totusi s a a pstrm informatiile suplimentare, ca o invitatie la excelenta adresat celor a a a interesati de acest subiect. Ne cerem scuze dac aceast lucrare se va ampla s gsiti erori sina n a nt a a tactice, semantice, formulrile expeditive sau neclariti. V multumim ana at a ticipat pentru orice observatii sau sugestii. Intrebrile Dvs. sunt binevenite: a Ovidiu poate contactat la adresa ogh@infoiasi.ro, iar Adriana la adresa adrianaa@infoiasi.ro.

Oui, Mademoiselle. On ne peut vous donner aucune r`gle. Il faut avoir e du air, et puis cest tout. Mais pour en avoir, il faut tudier, e tudier et encore tudiez. e e ` EUGENE IONESCO, La leon c 7

CAPITOLUL 1. CUVANT INAINTE

Capitolul 2

Introducere
Stiinta calculatoarelor este un domeniu relativ nou. Primele calculatoare au fost construite la mijlocul anilor 1940 i de atunci au avut loc dezvoltri specs a taculoase. 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 concepute ca rezolvabile cu ajutorul calculatorului. Dup ce a prevzut a a c nici un program pentru calculatoare personale nu va necesita vreodat mai a a mult de 64 KB de memorie RAM, Bill Gates admite 1995 c lucrurile s-au n a schimbat ultimele dou decenii. n a Urmtoarele 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, a anul 1992, dou milioane de linii de cod limbaj de asamblare; n a n Sistemul de operare System V versiunea 4.0 (UNIX) a fost obtinut prin compilarea a 3 700 000 linii de cod; Programele scrise pentru naveta spatial NASA au circa 40 de milioane a de linii de cod obiect; Pentru realizarea sistemului de operare IBM OS360 au fost necesari 5000 de ani-om. Creterea programelor dimensiune i complexitate a depsit cu mult pros n s a gresele fcute domeniul tehnicilor de programare. De aceea, programarea a a n devenit i a rmas mai mult o art dect o meserie. s a a a Pentru a contracara ceea ce se pregura ca ind o criz a programrii, a fost a a propus anul 1968 termenul de ingineria programrii (software engineering), n a ntr-un mod oarecum provocator. Se dorea ca arta programrii s a a mprumute din rigoarea tiintelor inginereti pentru a putea livra programe la timp i s s s n mod economic. Paralela cu ingineria constructiilor este atractiv. Dac dorim s construim a a a o cuc pentru un cine, putem s mergem prin grdin, s cutam cteva lemne s a a a a a a a a i cteva cuie, s ne s a a narmm cu un ciocan i s a s a ncepem s lucrm. Avem anse a a s destul de bune s reuim, mai ales dac suntem a s a ndemnatici. Dac totui nu a a s 9

10

CAPITOLUL 2. INTRODUCERE

reuim, putem s ncerca a doua zi din nou cu alte lemne i alte cuie. Iar dac s a cinele refuz s si ocupe locuinta, putem s schimbm cu un altul. a a a a l a Lucrurile stau radical diferit atunci cnd dorim s construim o cas pentru a a a familia noastr. Atunci va trebui sau s angajm un arhitect care s ne fac un a a a a a proiect, sau s cumprm un proiect standard de cas. Va trebui s negociem a aa a a cu o rm de constructii pretul, durata de realizare, calitatea nisajelor. Nu ne a permitem s riscm economiile familiei pe o constructie care se va drma la a a aa a doua rafal de vnt. plus, 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 e de tenis, ne va greu s n a a i nlocuim cu altii1 . Cu att mai mult, cei care ne a ncredinteaz cteva milioane de dolari pentru a a a ridica un zgrie nori vor foarte atenti cu cine i ce conditii vor lucra. Ei vor a s n dori garantii precum c proiectul este viabil, vor angaja mai multe rme de arhi a tectur pentru a-l verica. Deasemenea, studii geologice, de zic a pamntului, a a a de meteorologie vor obligatorii. Vor folosite cele mai performante materiale i se vor angaja cei mai competenti i cu experient constructori. Eecul nu mai s s a s este o optiune pentru contractantul proiectului. Stim c inginerii constructori a ntocmesc planuri, construiesc machete, studiaz proprietilor materialelor folosite i fac rapoarte privind progresul operatiunilor. a at s Constructii de o complexitate foarte mare au fost realizate acest fel n ntr-un mod rational i economic. Inginerii de programe ar trebui s procedeze similar s a pentru ca dezvoltarea programelor s nu mai e un proces impredictibil. a Prima denitie dat ingineriei programrii a fost enuntat anul 1968 astfel: a a a n Ingineria programrii este stabilirea i utilizarea de principii inginereti soa s s lide pentru a obtine mod economic programe care sunt sigure i functioneaz n s a ecient pe maini de calcul concrete. s IEEE Standard Glossary of Software Engineering Tehnology(1983) ingiIn neria programrii este denit dup cum urmeaz: a a a a Ingineria programrii reprezint abordarea sistematic a dezvoltrii, functionrii, a a a a a ntretinerii, i retragerii din functiune a programelor s Remarcm c a doua denitie este mai vag dect prima, a a a a ntruct nu face a referire la cost i la ecient. Mai mult, se pare c experienta general negas a a n tiv acumulat a fcut s se renunte la formularea principii inginereti solide, a a a a s ntruct se pare c acestea nu pot identicate fr a supuse contestatiilor. a a aa A doua denitie adaug a referiri la perioade importante din viata unui pro a ns gram, ce urmeaz crerii i functionrii, anume a a s a ntretinerea i retragerea din s functionare. Considerm c ingineria programrii are urmtoarele caracteristici impora a a a tante: Este aplicabil producerea de programe mari a n Este o tiint inginereasc s a a Scopul nal este ndeplinirea cerintelor clientului Programele mici se pot scrie relativ usor, de ctre un singur programator, a ntr-o perioad relativ scurt de timp. Un program de 100 de instructiuni este a a cu sigurant un program mic. Nu putem da o granit a a ntre un program mic i s unul mare, a pe msur ce dimensiunea programului crete, apar provocri ns a a s a
1 S-ar

putea chiar ca ei s e aceia care s initieze procesul de a a nlocuire.

11 noi, calitativ diferite. Intruct un singur sau civa programatori nu pot avea a at timpul zic pentru terminarea programului, este necesar crearea a uneia sau a mai multor echipe de lucru. Este necesar coordonarea i comunicarea a s ntre echipe. Complexitatea sistemului software i a organizatiei care realizeaz sistes a mul software devine netrivial, putnd depi capacitatea de a a as ntelegere a unui singur individ. Apare ca dezirabil o abordare riguroas a acestor probleme, ce a a include stilul de lucru, modul de scriere a codului, etc. Ingineria programrii a propune crearea unor astfel de abordare. Ingineria programrii are ca scop obtinerea de sisteme functionale chiar i a s atunci cnd teoriile i instrumentele disponibile nu ofer rspuns la toate proa s a a vocrile ce apar. Inginerii fac lucrurile s mearg, innd seama de restrictiile a a a t a organizatiei care lucreaz i de constrngerile nanciare. n as a Problema fundamental a ingineriei programrii este a a ndeplinirea cerintelor a n clientului [8]. Aceasta trebuie realizat nu punctual, nu acest moment, ci ntr-un mod exibil i pe termen lung. Ingineria programrii se ocup cu toate s a a etapele dezvoltrii programelor, de la extragerea cerintelor de la client pn la a a a ntretinerea i retragerea din folosint a produsului livrat. Pe lng cerintele s a a a functionale, clientul dorete (de obicei) ca produsul nal s e realizat cu costuri s a de productie ct mai mici. De asemenea, este dezirabil ca aceasta s aib a a a performanta ct mai bun (uneori direct evaluabil), un cost de a a a ntretinere ct a mai mic, s e livrat la timp, i s e sigur. a s a Prezentm continuare o statistic privind gradul de satisfacere a cerintelor a n a a a pentru proiecte software mari [2]. Aceasta pare s justice orice disciplin a muncii care s a mbunteasc aceste cifre. a at a 45% livrate dar nefolosite 25% pltite dar nelivrate a 20% abandonate sau refcute a 5% folosite dup modicare a 5% folosite aa cum au fost livrate s Nerespectarea cerintelor poate avea efecte serioase. Un sistem de livrare a in sulinei pentru diabetici poate provoca moartea pacientului dac nu functioneaz a a corect. Functionarea incorect a unui sistem de control al unui satelit poate pro a voca pagube de milioane de dolari. Un program este sigur dac functioneaz i continu s functioneze fr a a s a a aa ntreruperi i fr a efectua operatii nedorite. Un program are o greeal (bug) s aa s a dac nu se comport corect. Se presupune c dezvoltatorul tia ce ar trebuit a a a s programul s fac, iar comportamentul greit nu este intentionat. Iat cteva a a s a a erori celebre. primii ani care calculatoarele au fost introduse la statiile de benzina In n din SUA, consumatorii primeau cecuri pe sume enorme. faptul era privit general cu umor i reclamatiile erau rezolvate repede; n s Sistemul de operare IBM OS360 continea aproximativ 1.000 de greeli la s ecare nou versiune care a ncerca s rezolve greelile din versiunea precea s dent; a

12

CAPITOLUL 2. INTRODUCERE Un vehicul de explorare a planetei Venus a fost pierdut deoarece programul primit de pe Pamnt pentru recticarea orbitei continea linia DO 3 I = a 1.3; instructiunea corect limbajul FORTRAN ar trebuit s contin a n a a , (virgul) loc de . (punct); a n In n a n 1979 s-a descoperit o eroare programele pentru sistemele de rcire centralele nucleare (SUA); nu fusese niciodat nevoie de executia rutinelor a ce contineau erorile; Eroare sistemul de avertizare n mpotriva atacului cu rachete balistice; procedurile de contraatac au fost declanate s nainte de a se descoperi c a a fost o eroare; Racheta Ariane 5 explodeaz iunie 1996 din cauza unei greeli de proa n s gramare; costurile s-au ridicat la 500 milioane dolari.

On two occasions I have been asked [by members of Parliament!], Pray, Mr. Babbage, if you put into the machine wrong gures, 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. CHARLES BABBAGE

Capitolul 3

Modele de dezvoltare a programelor

Cnd pornim la dezvoltarea unui program avem nevoie de: a o elegere clar a ceea ce se cere; nt a un set de metode i intrumente de lucru; s un plan de actiune. Planul de actiune se numeste model de dezvoltare. Dezvoltarea unui anumit program const a ntr-un set de pai ce se fac pentru a-l realiza. Lund cons a n siderare tipul pailor ce se efectueaz se creaz un model de lucru, ce poate s a a aplicat unei serii mai largi de proiecte. Acesta este motivul pentru care planul de actiune este numit model: el poate privit ca un ablon al dezvoltrii de s a programe. 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 Unied Process) XP (Extreme Programming)

3.1

Etapele dezvoltrii programelor a

timpul dezvoltrii programelor s-a constatat c exist anumite tipuri de acIn a a a tiviti care trebuie fcute la un moment dat: at a analiza cerintelor 13

14

CAPITOLUL 3. MODELE DE DEZVOLTARE A PROGRAMELOR proiectarea arhitectural a proiectarea detaliat a scrierea codului integrarea componentelor validare vericare ntretinere

3.1.1

Analiza cerintelor

Se stabilete ce anume vrea clientul ca programul s fac. Scopul este s a a nregistrarea cerintelor ntr-o manier ct mai clar i mai del. Claritatea se refer la lipsa a a as a a ambiguitii iar delitatea la at nregistrarea ct mai exact (posibil cuvnt cu a a a cuvnt). a

3.1.2

Proiectarea arhitectural a

Din motive de complexitate, programele mari nu pot concepute i implemens tate ca o singur bucat. Programul va trebui construit aadar din module sau a a s componente. Proiectarea arhitectural a mparte sistemul ntr-un numr de module mai a mici i mai simple, care pot abordate individual. s

3.1.3

Proiectarea detaliat a

Se realizeaz proiectarea ecrui modul al aplicatiei, cele mai mici detalii. a a n

3.1.4

Scrierea codului

Proiectul detaliat este transpus ntr-un limbaj de programare. mod tipic, In aceasta se realizeaz modular, pe structura rezultat la proiectarea arhitectua a ral. a

3.1.5

Integrarea componentelor

Modulele programului sunt combinate produsul nal. Rezultatul este sistemul n complet. Modelul big-bang acest model, componentele sunt dezvoltate i testate individual. Apoi ele In s sunt integrate sistemul nal. Avnd vedere c functionarea corect a n a n a a componentelor individuale a fost testat, integrarea ar trebui s e o formalitate. a a Din pcate, componentele nu pot testate exhaustiv, iar cnd 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 conicte n ntre anumite componente (de exemplu, conicte de partajare a resurselor).

 3.2. MODELUL CASCADA

15

S-a constatat c atunci cnd se aplic acest model, timpul de testare exa a a plodeaz, proiectul devenind greu de controlat. Aceasta justic denumirea de a a big-bang. Modelul incremental Acest model propune crearea unui nucleu al aplicatiei i integrarea a cte o s a component la un moment dat, urmat imediat de testarea sistemului obtinut. a a Astfel, se poate determina mai uor unde anume apare o problema sistem. s n Acest tip de integrare ofer de obicei rezultate mai bune dect modelul biga a bang.

3.1.6

Validare

procesul de validare ne asigurm c programul In a a ndeplinete cerintele utilizas torului. Intrebarea la care rspundem este: construim produsul corect? 1 . a Un exemplu de validare este testul de acceptare, care produsul este pren zentat clientului. Clientul spune dac este multumit cu produsul sau dac mai a a trebuie efectuate modicri. a

3.1.7

Vericare

procesul de vericare ne asigurm c programul este stabil i c functioneaz In a a s a a corect din punctul de vedere al dezvoltatorilor. Intrebarea la care raspundem este: construim corect produsul? 2 .

3.1.8

Intretinere

Dup ce programul este livrat clientului, mai devreme sau mai trziu sunt desa a coperite defecte sau erori ce trebuie reparate. De asemenea, pot apare schimbri a specicatiile utilizatorilor, care vor diverse imbuntiri. n a at Intretinerea const a gestionarea acestor probleme. n

3.2

Modelul cascad a

Modelul cascad denete urmtorii pai dezvoltarea unui program: a s a s n Specicarea 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.) we building the product right? (eng.)

16

CAPITOLUL 3. MODELE DE DEZVOLTARE A PROGRAMELOR

Ingineria cerintelor P roiectarea arhitecturala P roiectarea detaliata

Implementare

T estarea unitatilor T estarea sistemului

Acceptare Figura 3.1: Modelul de dezvoltare cascad n a

Nu se stipuleaz cum se fac aceti pai (metodologie, notatii), ci doar ordinea a s s efecturii lor. a Avantaje O sarcin complex este a a mpartit mai multi pai mici, ce sunt mai uor a n s s de administrat. Fiecare pas are ca rezultat un produs bine denit (documente de specicatie, model, etc.)

3.3

Modelul cascad cu a ntoarcere

Unul din dezavantajele modelului cascad este c a a ntr-un anume stadiu al dezvoltrii nu se poate inuenta rezultatul obtinut a ntr-un stadiu precedent pentru a se remedia o problema gasit. De exemplu, la testare se poate descoperi o a eroare de proiectare. Modelul cascad cu feedback propune remedierea problemelor descoperite a pasul precedent. Problemele la pasul i care sunt descoperite la pasul i + 3 n rmn neremediabile. 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. a a Dezavantajul principal al modelului cascad este acela c clientul obtine n a a o viziune practic asupra produsului doar momentul terminrii procesului de a n a dezvoltare.

 3.3. MODELUL CASCADA CU INTOARCERE

17

Ingineria cerintelor P roiectarea arhitecturala P roiectarea detaliata

Implementare

T estarea unitatilor T estarea sistemului

Acceptare Figura 3.2: Modelul de dezvoltare cascad cu n a ntoarcere

18

CAPITOLUL 3. MODELE DE DEZVOLTARE A PROGRAMELOR

3.4

Prototipizarea

O problem general care apare la dezvoltarea unui program este s ne asia a a gurm c utilizatorul obtine exact ceaa ce vrea. Prototipizarea vine sprijinul a a n rezolvrii acestei probleme. a din primele faze ale dezvoltrii, clientului i se a Inc a prezint o versiune functionala a sistemului. Aceast versiune nu este a a ntregul sistem, a este o parte a sistemului care cel putin functioneaz. ns a Prototipul ajut clientul a-i deni mai bine cerintele i prioritile. 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. Prototipul, este de obicei produs ct mai repede; pe cale de a consecint, stilul de programare este de obicei (cel putin) neglijent. 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. Se disting dou feluri de prototipuri: a de aruncat (throwaway) evolutionar cazul realizrii unui prototip de aruncat, scopul este exclusiv obtinerea In a unei specicatii. De aceea nu se acord nici o important stilului de programare a a i de lucru, punndu-se accent pe viteza de dezvoltare. Odat stabilite cerintele, s a a codul prototipului este aruncat, sistemul nal ind re-scris de la nceput, n mod tipic chiar alt limbaj de programare. n cazul realizrii unui prototip evolutionar, 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. Pe masur ce aplicatia este dezvoltat, noi caracteristici sunt adaugate a a scheletului existent. contrast cu prototipul de aruncat, aici se investete un In s efort considerabil ntr-un design modular i extensibil, precum i adoptarea s s n unui stil elegant de programare. Avantaje: permite dezvoltatorilor s elimine lipsa de claritate a specicatiilor a ofer utilizatorilor ansa de a schimba specicatiile a s ntr-un mod ce nu afecteaz drastic durata de dezvoltare. a ntretinerea este redus, deoarece validarea se face pe parcursul dezvoltrii a a se poate facilita instruirea utilizatorilor nali nainte de terminarea produsului. Dezavantaje: deoarece prototipul ruleaz a ntr-un mediu articial, anumite dezavantaje ale produsului nal pot scpate din vedere de clienti; a clientul nu ntelege de ce produsul necesit timp suplimentar pentru deza voltare, avnd vedere c prototipul a fost realizat att de repede; a n a a deoarece au ecare moment ansa de a face acest lucru, clientii schimb n s a foarte des specicatiile; poate nepopular printre dezvoltatori, deoarece implic renuntarea la a a propria munca.

3.5. METODE FORMALE

19

3.5

Metode formale

acest model de dezvoltare, sunt folosite formalismul i rigoarea matematicii. In s prima faz este construit o specicatie limbaj matematic. Apoi, aceast In a a n a specicatie este transformat programe, de obicei a n ntr-un proces incremental. Avantaje: precizia obtinut prin specicarea formal; a a pstrarea corectitudinii timpul transformrii specicatiei cod execua n a n tabil; ofer posibilitatea generrii automate de cod; a a potrivite pentru sisteme cu cerinte critice. Dezavantaje: specicarea formal este de obicei o barier de comunicare a a ntre client i s analist; necesit personal foarte calicat (deci mai scump); a folosirea impecabil a tehnicilor specicrii formale nu implic neaprat a a a a obtinerea de programe sigure, deoarece anumite aspecte critice pot omise din specicatiile initiale.

3.6

Modelul spiral n a

Modelul spiral n a ncearc s rezolve problemele modelului cascad, pastrnd a a n a a avantajele acestuia: planicare, faze bine denite, produse intermediare. Deasemenea, prototipizarea poate folosit dac se consider necesar. a a a Modelul spiral denete urmtorii pai dezvoltarea unui produs: n a s a s n studiul de fezabilitate analiza cerintelor proiectarea arhitecturii software implementarea Modelul spiral recunoate c problema principal a dezvoltrii progran a s a a a melor este riscul. Riscul nu mai este eliminat prin asertiuni de genul: in urma proiectrii am obtinut un model corect al sistemului, ca i modelul cascad. a s n a Aici riscul este acceptat, evaluat i se iau msuri pentru contracararea efectelor s a sale negative. Exemple de riscuri: timpul unui proces n ndelungat de dezvoltare, cerintele (noi) ale clientu lui sunt ignorate; o rma concurent lanseaz un program rival pe piat; a a a un dezvoltator/arhitect prasete echipa de dezvoltare; a s

20

CAPITOLUL 3. 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.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. a modelul spiral (3.3) se consider c ecare pas din dezvoltare contine o a a In a serie de activiti comune: at pregtirea: se identic obiectivele, alternativele, constrngerile; a a a gestionarea riscului: analiza i rezolvarea situatiilor de risc; s activiti de dezvoltare specice pasului curent (de ex. analiza specicatiilor at sau scrierea de cod) planicarea urmtorului stadiu: termenele limita, resurse umane, revizuia rea strii proiectului. a

3.7

Rational Unied Process

3

Rational Unied Process (Procesul unicat [de dezvoltare al rmei] Rational) denete urmtoarele activiti fundamentale: s a at Ingineria functionalitii. Sunt sintetizate necesitile functionale. at at

Cerinte. Se translateaz necesitile functionale comportament de sis a at n teme automate. Analiza i Proiectare. Se translateaz cerintele arhitectura programului. s a n Implementare. Se creaz programul conform cu arhitectura astfel a ncat comportamentul acestuia sa e consistent cu cel dorit. Testare. Se asigur c comportamentele cerute sunt corecte i c toate a a s a comportamentele necesare sunt prezente program. n
3 Denumirea englez este, probabil din motive de promovare pe piat, ambigu, putnd n a a a a nsemna i (Procesul unicat [i] rational [de dezvoltare]). s s

3.7. RATIONAL UNIFIED PROCESS

21

Administrarea conguratiei i a schimbarilor. Se gestioneaz versiunile s a tuturor entitilor din care este compus programul. at Administrarea proiectului. Sunt administrate planicrile i resursele. a s Administrarea mediului. Se instaleaz i se mentine mediul de lucru neas cesar dezvoltrii programului. a Plasament. Se efectueaz activitile necesare punerii functiune a proa at n gramului. Aceste activiti nu sunt separate timp (cum se presupune, de exemplu, at n cazul modelului cascad). Aici, ele sunt executate paralel, pe parcursul n n a n a ntregului proiect. Dup cum reiese din gura 3.4 cantitatea de cod scris la a nceputul proiectului este mic, a nu zero. Pe masur ce proiectul evolueaz, a ns a a cele mai multe dintre cerinte devin cunoscute, a noi cerinte sunt identicate: ns aceasta nseamn c activitatea cerinte se regsete pe a a a s ntreaga durat de viat a a a procesului, a apare cu pregnant la ns a nceputul acestuia. Aadar, pe masur ce procesul de dezvoltare evolueaz, importanta anumitor s a a activiti scade sau crete, a este permis ca aceste activiti s se execute la at s ns at a orice moment al dezvoltrii. a Un proiect bazat pe RUP evolueaz pai numiti iteratii. Scopul unei a n s iteratii este s dezvolte un program functional care s poat prezentat clien a a a tului, iar clientul s poat evalua. Programul obtinut la sfritul unei iteratii a l a as ar trebui s contin elemente din toate compartimentele programului, chiar dac a a a aceste compartimente nu sunt implementate complet. Intinderea timp a unei iteratii depinde de tipul de proiect la care se lun creaz, de experienta echipei etc. Este a de preferat ca iteratiile s e ct mai a ns a a scurte. Dac o iteratie este scurt, echipa de dezvoltare are oportunitatea de a a a primi mai repede reactii din partea clientului. Iteratii care dureaz o saptamn a a a sau dou sunt considerate acceptabile ca a ntindere timp. n Iteratiile pot folosite pentru a estima timpul necesar dezvoltrii proiec a tului. Dac, de exemplu, mai sunt proiectate a 20 de iteratii, iar pn a nc a a n momentul la care se face estimarea timpul de dezvoltare a fost de 2 saptmni a a pe iteratie, putem s apreciem c proiectul va mai dura aproximativ 40 de a a saptmni. Aceast tip de informatie poate de mare folos administratorilor i a a s clientilor. Initial estimrile sunt nesigure, a pe masura ce proiectul avanseaz, a ns a ele devin din ce ce mai precise. n

3.7.1

Pornire

faza de pornire, scopul principal al iteratiilor este s ajute echipa de dezvoltare In a s stabileasca care vor obiectivele esentiale ale proiectului. Se vor explora a arhitecturi alternative i solutii tehnice posibile. s urma acestei activiti, se obtin urmtoarele: In at a o enumerare a cerintelor principale, posibil form de cazuri de utilizare; n a o imagine de ansamblu asupra arhitecturii programului; o descriere a obiectivelor proiectului; un plan preliminar de dezvoltare.

22

CAPITOLUL 3. MODELE DE DEZVOLTARE A PROGRAMELOR

Figura 3.4: Activitile cadrul RUP at n

3.8. EXTREME PROGRAMMING

23

3.7.2

Ranare

faza de ranare se stabilete o In s ntelegere detaliat a problemei care trebuie a rezolvat, se hotrte arhitectura programului, se stabilete echipa de lucru, se a a as s elimin situatiile cu risc mare. a Aceast activitate produce urmtoarele: a a un prototip evolutionar al arhitecturii programului; teste care veric functionarea programului; a cazuri de utilizare care descriu majoritatea functionalitilor sistemului; at un plan de proiect detaliat pentru iteratiile urmtoare. a

3.7.3

Construire

Iteratiile din faza de contruire au ca rol adugarea se diverse caracteristici pro a gramului dezvoltat. aceast faz se ateapt ca cazurile de utilizare oferite In a a s a de client s se stabilizeze mare masur, dei unele aplicatii este posibil ca a n a s n ele s sufere oarecari modicri. a a Cazurile de utilizare sunt adaugate unul cte unul, iteratie cu iteratie la a program, pn cnd clientii pot utiliza programul a a a ntr-un mod apropiat de cel ateptat. s Activitatea de construire produce urmtoarele: a Programul propriu-zis Teste Manuale de utilizare

3.7.4

Tranzitie

cadrul acestei activitti programul este In a mbogatit mai departe cu caracteris tici, a accentul se pune pe ns mbuntirea i ranarea celor existente. a at s Sfritul acestei activitati i a as s ntregului proces de dezvoltare are loc atunci cnd: a Obiectivele propuse cadrul fazei de pornire sunt n ndeplinite; Clientul este satisfcut. a De remarcat c a doua situatie nu se suprapune peste prima. Adesea pot s a a apar cerinte ce nu au fost propuse initial. a

3.8

Extreme Programming

Extreme Programing (XP) [5] 4 este o metodologie nou de dezvoltare, inspia rat din RUP, dar care propune rezolvri originale problemelor care apar a a n dezvoltarea de programe. Fiind o tehnologie nou (i extremist) are adepti i a s a s detractori.
4 Programare

extrem a

24

CAPITOLUL 3. MODELE DE DEZVOLTARE A PROGRAMELOR

XP consider c dezvoltarea programelor nu a a nseamna ierahii, responsabiliti i termene limit aa cum se a acestea pe masa administratorului, ci at s a s a nseamn colaborarea oamenilor din care este format echipa. Acetia sunt a a s ncurajati s si arme personalitatea, s ofere i s primeasc cunoatere i s a a s a a s s a devin programatori strluciti. a a Deasemenea, XP consider c dezvoltarea de programe a a nseamn primul a n rnd scrierea de programe. 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, a n sedintelor i a rapoartelor de activitate. XP ne amintete cu respect ca ierele s s s PowerPoint nu se pot compila. De altfel, inspirarea proceselor de dezvoltare a programelor din ingineria constructiilor se pare c nu este cea mai fericit alegere. Este adevarat c un a a a inginer care vrea s construiasc un pod peste un ru face inti msuratori, a a a a a realizeaz un proiect i abia apoi trece la executie, toate acestea a s ntr-un mod secvential i previzibil. Dar dezvoltarea de programe nu seamn cu aa ceva, s a a s orict am vrea s ne pclim s credem asta. Dac inginerului constructor a a a a a a respectiv i s-ar schimba cerintele de rezistent, i s-ar muta malurile i i s-ar a s schimba rul din Siret Amazon, pentru frumusete chiar cnd a terminat de a n a construit jumtate de pod, putem siguri c acel inginer i-ar schimba modul a a s de lucru. Din pacate nsa, nu stim ( a) cum. nc Initiatorii XP, Jon Jeries i Kent Beck denesc urmtoarele dou carte, ca s a a baz lozoc pentru aceast metodologie. a a a Carta drepturilor dezvoltatorului Ai dreptul s tii ceea ce se cere, prin cerinte clare, cu declaratii clare de as prioritate. Ai dreptul s spui ct i va lua s implementezi ecare cerint, i s i a a t a a s a t revizuieti estimrile functie de experient. s a n a Ai dreptul s i accepti responsabilitile, loc ca acestea s-ti e asiga t at n a nate. Ai dreptul s produci treab de calitate orice moment. a a n Ai dreptul la liniste, distractie i la munc productiv i placut. s a as a Carta drepturilor clientului Ai dreptul la un plan general, s tii ce poate fcut, cnd, i la ce pret. as a a s Ai dreptul s vezi progresul a ntr-un sistem care ruleaz i care se dovedeste as c functioneaz trecnd teste repetabile pe care tu le specici. a a a Ai dreptul s te razgndeti, s a a s a nlocuieti functionaliti i s schimbi s at s a prioritile. at Ai dreptul s i informat de schimbarile estimri, sucient de devreme a n a pentru a putea reduce cerintele astfel ca munca s se termine la data a prestabilit. Poti chiar s te opresti la un moment dat i s rmi cu un a a s a a a sistem folositor care s reecte investitia pn la acea dat. a a a a

3.8. EXTREME PROGRAMMING

25

Aceste armatii, dei par s ntelese de la sine, contin semnicatii profunde. Multe din problemele aprute dezvoltarea programelor pornesc de la a n ncalcarea acestor principii. Enumerm pe scurt cteva dintre caracteristicile XP. a a Echipa de dezvoltare nu are o structur ierarhic. Fiecare contribuie la a a proiect folosind maximul din cunotintele sale. s Scrierea de cod este activitatea cea mai important. a Proiectul este mintea tuturor programatorilor din echipa, nu documentatii, n n modele sau rapoarte. La orice moment, un reprezentant al clientului este disponibil pentru claricarea cerintelor. Codul se scrie ct mai simplu. a Se scrie cod de test inti. a Dac apare necesitatea rescrierii sau aruncrii de cod, aceasta se face fr a a aa mil. a Modicarile aduse codului sunt integrate continuu (de cateva ori pe zi). Se programeaz echip (programare perechi). Echipele se schimb la a n a n a sfritul unei iteratii (1-2 saptmni). as a a Se lucreaz 40 de ore pe saptmn, fr lucru suplimentar. a a a a aa Nu vom discuta aici avantajele aduse de aceast abordare i nici criticile care a s sunt adresate. Le lsm ca subiecte de meditatie pentru cititor. i aa

It took 300 years to build and by the time it was 10% built, everyone knew it would be a total disaster. But by then the investment was so big they felt compelled to go on. Since its completion, it has cost a fortune to maintain and is still in danger of collapsing. There are at present no plans to replace it, since it was never really needed in the rst place. K.E. IVERSON, despre turnul din Pisa

26

CAPITOLUL 3. MODELE DE DEZVOLTARE A PROGRAMELOR

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). Partea ce mai important a a a a acestui proces o reprezint comunicarea dintre client i echipa de dezvoltare. a s Cnd un inginer de programe lucreaz la stabilirea cerintelor, el este numit a a inginer de cerinte, analist de sistem sau analist. Dezvoltarea unui program ncepe de obicei cu o idee a clientului despre un nou sistem sau pentru mbunatirea unui sistem existent. Clientul angajeaz at a un analist cu care va lucra mpreun pentru specicarea mai exact a cerintelor. a a Ideea initial a clientului poate vag i prost denit, dup cum poate clar a as a a a i bine denit. s a Stabilirea cerintelor este probabil cea mai important activitate dezvol a n tarea produselor program. 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, este inutil s angajeze o echip care s programeze. 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, dar dac nimeni nu va dori s-l foloseasc, proiectul va a a a un eec. s Multe programe nu se potrivesc cu cerintele clientului nu din motive de implementare defectuas, ci din cauz c cerintele nu au fost specicate corect a a a de la nceput. Persoane ale cror legturi cu ingineria programrii sunt mai mult a a a pretinse dect obiective consider c nepotrivirea dintre ateptrile clientului i a a a s a s programul obtinut in de lipsa de cultur, simt artistic i de cunotinte tehnice t a s s ale programatorilor. 1 Adevarul este c a avea perceptie extransenzorial i a a as poseda capabiliti telepatice nu intr atributiile programatorilor. Acetia at a n s nu pot i nu au cum s cunoasc necesitile clientilor, mai ales dac nu cunosc s a a at a domeniul pentru care o anumit aplicatie este scris. Este responsabilitatea a a clientului de a veni cu cereri exacte i pertinente. Este obligatia inginerului de s cerinte de a discuta cu clientul pentru a clarica cerintele i a ajuta clientul s s-i xeze prioritile. as at Stabilirea precisa a cerintelor este primul pas obtinerea unui program n care satisface cerintele clientului. O specicatie bun este folosit i fazele de a a s n validare i vericare. s
1 Asemenea persoane pot alnite functii administrative companii ce se ocupa de nt n n dezvoltare de programe. Curios, chiar ajung s conduc echipe formate doar din programatori a a cu asemenea caliti. at

27

28

CAPITOLUL 4. INGINERIA CERINTELOR

4.1

Cerinta

Notiunea de cerint este mai veche dect dezvoltarea programelor. De exemplu, a a o cerint pentru o locomotiv ar putea arta astfel: Pe o cale ferat uscat, a a a a a locomotiva trebuie s e 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. De remarcat c aceast cerint spune ce vrea clientul. Nu spune nimic a a a despre cum ar putea realizat. Nu se specic tipul motorului (cu aburi, a a diesel, electric) sau materialul din care s se confectioneze rotile. a Controvers: este bine s facem specicarea lund considerare felul a a a n n care sistemul va implementat? 1. Nu folosim detalii de implementare. Motivatia: nu ne ateptm ca clientul s a s tie lucruri specice dezvoltrii programelor, i deci nu poate s e de acord as a s a cunostint de cauz cu stipulrile din specicatii. Secretarele care folosesc n a a a Excel stiu COM? E necesar s facem contrngeri asupra programului a din a a nc faza de concepere? 2. Folosim detalii de implementare. Cteodat nu este posibil s ignoram a a a o implemetare existent. Dac facem un program pentru o bibliotec, studiem a a a implementarea existent (tipul elor ce trebuie completate, uxul de lucru, a s modul de organizare al mediilor de stocare a informatiilor) i o copiem s n program. Putem verica dac o cerint este sau nu rezonabil din punct de a a a vedere tehnic. Pentru a putea estima timpul de dezvoltare i pretul, trebuie s luat considerare implementarea. Este o diferent a n a ntre a programa Visual n Basic i a programa C++. Costurile initiale la programarea Visual Basic s n n vor mai mici (timp de dezvoltare mai mic, programatori mai ieftini), a odat ns a ce produsul necesit dezvoltarea peste o anumit limit a complexitii, este a a a at posibil ca costurile s creasc ( a a ntretinere greoaie, probleme de performant). a legtur cu specicatia pentru locomotiv, remarcm c indic cerinte, In a a a a a a nu mod de implementare. Cerintele sunt testabile (cu instrumente de msur a a specice) i sunt clare (neambigue). Remarcm a c este incomplet: nu s a ns a a specic nimic despre costul sau termenul limit de realizare. C s vedem a a a a dac o specicatie este bun ar trebui s ne intrebam dac: a a a a spune ce i nu cum s este clar a este sucient de detaliat a este complet a Pentru comparatie, considerm urmtorul exemplu de specicatie: Scrieti a a un program Pascal care ofer functionalitatea unei agende telefonice personale. a Ar trebui s implementeze functii pentru cutarea unui numar i pentru introa a s ducerea unui nou numr de telefon. Programul ar trebui s ofere o interfat a a a utilizator prietenoas. a

4.2

Extragerea cerintelor

Presupunem c clientul i analistul lucreaz a s a mpreun, ecare a ncercnd s a a eleag pe celalalt. Esenta procesului de obtinere a cerintelor este comunint a

4.3. SPECIFICAREA CERINTELOR

29

carea. Se disting trei activiti majore care conduc la obtinerea unei specicri at a a cerintelor: Ascultare. aceast faz analistul In a a nregistreaz cerintele clientului a Gndire. 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. n s a n Scriere. Analistul i clientul cad de acord asupra unor formulari ale s cerintelor pe care analistul le considera pertinente. Aceste activiti sunt parte a unui proces iterativ, lung i complicat. Neat s gocierea este foarte important. Diferenta cultural dintre client i analist este a a s cteodat foarte mare. Exist situatii cnd exist diferente semnicative a a a a a ntre asteptrile utilizatorilor nali i ale clientului. Un exemplu concret al acestui a s tip de conict este cnd un patron care comand un program care s e utilizat a a a de ctre angajatii si dorete ca acesta s contin module de monitorizare a a a s a a muncii angajatilor 2 . O alt problema o reprezint literatura SF studiat de client, a a a nainte de angajarea echipei de dezvoltare. Clientul ateapt mult prea mult de la program s a i de la echipa de dezvoltare, s nchipuindu-i c programele se scriu ca lme, s a n ntr-o scen de doua minute, ca un amnunt dintr-un lm de dou ore. a a a Analistul trebuie: s extrag i s clarice cerintele clientului a as a s ajute la rezolvarea diferentelor de opinie a ntre clienti i utilizatori. s s sftuiasc clientul despre ce este tehnic posibil sau imposibil a a a s documenteze cerintele a s negocieze i s obtin o elegere cu clientul. a s a a nt

4.3

Specicarea cerintelor

Produsul extragerii cerintelor i a analizei este un document de specicare a s cerintelor (specicatii) 3 . Specicatiile sunt de o important crucial dez a a n voltarea cu succes a unui produs. Specicatiile sunt documente de referint cu a ajutorul crora se evalueaz dezvoltarea programului. 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 fr ca s stie (lips de etic din partea clientului), sau s e loial celui care a a a a a a l pltete. Rezolvarea o lsm ca exercitiu. a s a a 3 Cel putin pentru metodologiile anterioare XP. XP se mndrete c foloseste cartonae cu a s a s povesti.
2 Aceasta

30

CAPITOLUL 4. INGINERIA CERINTELOR

Este de preferat ca specicatiile s se restrng ct mai mult preajma a a a a a n ce, nu a CUM trebuie fcut. Ar trebui s surprind viziunea clientului asupra a a a sistemului. Specicatiile trebuie elese de dou grupuri distincte de persoane: nt a clienti i dezvoltatori. Fiecare dintre aceste grupuri tind s aib jargoane, dome s a a nii de expertiz diferite. Membrii aceste grupuri vor ca specicatiile s enunte a a exact cea ce trebuie fcut, a nsa preferintele pentru limbajul n care se exprim i a aceste lucruri sunt diferite. Clientii prefer de obicei limbajul natural, timp a n ce analitii tind s foloseasca o notatie precis (limbaj de modelare). s a a Tipuri de notatii: informale, formale, semiformale. Abordarea modern: se fac dou seturi de documente. Un set este pentru a a clienti, iar un set pentru dezvoltatori. Problema care apare este actualizarea acestor documente i mentinerea lor consistent. s a Un document de specicatii bun ar trebui s categorizeze mod explicit a n cerintele una din urmtoarele clase: n a Cerinte functionale. Indic ce ar trebui s fac sistemul. a a a Exemple: Sistemul va aa titlurile crtilor scrise de un anumit scriitor s a Sistemul va asa temperaturile din toate slile de lectur a a Cerinte privind datele. Se refer la datele de intrare/ieire din sistem a s (format, dimensiuni) i la datele stocate interiorul sistemului. s n Constrngeri. Cerinte ce trebuie respectate ad literam. Inuenteaz direct a a implementarea sistemului. Exemple: sistemul trebuie scris Pascal, sau sistemul trebuie s rspund n a a a oricrei cereri a ntr-o secund a Constrngerile se refer la: cost, data livrrii, hardware-ul utilizat, memoa a a ria disponibil, timp de rspuns, limbaj de programare, grad de arcare, a a nc sigurant (MTBF) a Recomandri. O recomandare ajut la luarea unei decizii de implementare a a atunci cnd sunt disponibile mai multe strategii. a Exemple: Timpul de rspuns al sistemului la intrarea de la tastatura ar a trebui minimizat. Folosirea memoriei trebuie minimizat. a Probleme ce pot apare legatura cu cerintele: n Cerinte vagi: sistemul trebuie s e prietenos a Cerinte contradictorii: toate datele trebuie scrise pe disc; 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. n

First study the enemy. Seek weakness. COMANDANT ROMULAN, Star Trek, Balance of Terror, data stelar 1709.2 a

Capitolul 5

Concepte orientare obiect

5.1 Obiecte. Clase

Un obiect este o entitate care are identitate, stare i comportament. s Exemple: Apartamentul situat la adresa Str. Locuintei nr. 4, Et. 4, Ap. 4, stare n impecabil, care ine iarna de cald i vara de frig. a t s Zona de memorie de la adresa 0x00FFA0BC de dimensiune 4 octeti, ecare dintre acetia avnd bitii setati pe 0; este accesibila doar pentru citire i s a s poate interpretat ca un a ntreg little-endian. Motanul Griutu, pipernicit i slab, care este de fapt pisic, mananc, se s a a joac i doarme. as Mingea mea galbena de tenis, cu diametrul 10 cm, care sare. O clas este o descriere a unei multimi de obiecte care au aceleasi caractea ristici structurale i comportmanetale. s Exemple: Apartamente care au adres, cu o stare precizat, care se in iarna de cald a a t i vara de frig. s Zone de memorie adresate pe 32 biti, de dimensiune 4 octeti, accesibile doar pentru citire i a cror biti sunt interpretati ca s a ntregi little-endian. Pisici care au nume, naltime, greutate, sex, care mannc, se joac, i a a a s dorm. Mingi, care sunt sferice, au diametru, culoare, ntrebuintare specic, i a s care sar. Putem privi o clas, acelasi timp, ca ind: a n o descriere general a unui numr de obiecte a a o colectie de metode (operatii) ce pot efectuate de instantele clasei un mecanism pentru stabilirea i reutilizarea conceptelor s 31

32

CAPITOLUL 5. 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 a

5.2

Principiile dezvoltrii orientat obiect a a

Exist anumite principii, asupr crora general se convine, referitoare la ce a a a n nseamna orientat obiect. Se consider c dezvoltarea unui program este orientat obiect dac apar a a a a urmatoarele caracteristici: ncapsularea motenirea s polimorsmul principiu, orice limbaj de programare orientat obiect ar trebui s ofere In a suport pentru constructiile de mai sus. Astfel, ar posibil s transpunem o a arhitectur orientat obiect orice limbaj orientat obiect disponibil. a a n Toate aceste trei caracteristici promoveaz reutilizarea codului. a Incapsularea permite ca o clas s e folosit fr a ti cum functioneaz (modularitate, aba a a aa s a stractizare). Motenirea permite reutilizarea codului prin folosirea de caractes ristici deja existente i adaugarea de altele noi. Polimorsmul permite scrierea s unei clase generale care specic o interfat a carei implementare va specicat a a a i apelat s a ntr-un mod transparent pentru clasele care o motenesc. s

5.2.1

Incapsulare

Incapsulare nseamna punerea mpreuna a prtilor puternic corelate ale unui a program scopul crerii de uniti ce pot proiectate, implementate, depanate, n a at testate i mentinute una cte una. s a Limbajele orientate obiect consider codul i datele ca parte a unei entiti a s at indivizibile numite obiect. Datele continute ntr-un obiect sunt de regul moa dicate doar prin intermediul codului (metodelor) obiectului respectiv. Fiecare obiect poate privit ca un mic procesor a crui comportare este denit de a a modul cum rspunde la un apel de metod. 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. a Ascunderea informatiei: utilizatorii unui obiect nu au nevoie s stie (nu-i a intereseaz, nu trebuie s stie) implementarea metodelor. Un utilizator poate a a modica starea obiectului doar mod indirect, prin apelul de metode. El nu n trebuie s tie modalitatea care modic metoda starea obiectului ci doar a s n a efectul acestei modicari. Un avantaj al acestei abordri este c a a mbuntiri a at ale codului pot apare fr a schimba interfata. Aceast separare este esential aa a a pentru producerea de cod refolosibil i usor de intretinut. s

 5.2. PRINCIPIILE DEZVOLTARII ORIENTATA OBIECT

33

5.2.2

Mostenirea

Adesea anumite clase sunt percepute ca specilizri ale altor clase. 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. Sau, o a a clas este super-clas a unei altei clase. a a O subclas are caracteristicile super-clasei pe care le extinde a ntr-un anume fel, 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 motenete caracteristicile supera a s s clasei. Avantaje: Denitii concise ale claselor: pentru subclase este sucient s descriem a cum difer fat de super-clase. a a Reutilizarea codului: loc s duplice codul, clasele derivate reutilizeaz n a a codul existent superclas. n a

5.2.3

Polimorsmul

Polimorsm: interpretarea semanticii unui apel de metod se face de catre cel a care primeste apelul, nu de catre apelant (acelasi apel de metoda se poate comporta diferit pentru tipuri de obiecte diferite). Extinderea programelor cu tipuri noi de date se simplic foarte mult. a Informatii suplimentare: [4].

CLASS, from Latin classis, summons, division of citizens for military draft, hence army, eet, also class in general. THE AMERICAN HERITAGE DICTIONARY

34

CAPITOLUL 5. CONCEPTE ORIENTARE OBIECT

Capitolul 6

Modelare
6.1 Introducere

Problema principal care apare dezvoltarea programelor este complexitatea. a n Folosirea de modele poate nlesni abordarea de probleme complexe. Un model este o simplicare unui anumit sistem, ce permite analizarea unora dintre proprietile acestuia. Lucrul cu modelele poate facilita o mai bun elegere a at a nt sistemului modelat, datorit dicultii intrinseci de a at ntelegere a sistemului n ntregul sau. Folosirea tehnicii divide et impera permite elegerea prtilor nt a componente ale unui sistem, iar ansambul sistemului ca o interactiune ntre prtile acestuia. Un model reuit retine caracteristicile importante ale obiectului a s modelat i le ignor pe cele irelevante. De remarcat c notiunile de importans a a t/irelevant sunt relative, ele depinznd de scopul pentru care se face modelarea. a Astfel apare plauzibil construirea mai multor modele pentru un anumit obiect, a ecare surprinznd anumite aspecte ale acestuia. a Orice metodologie de dezvoltare a programelor abordeaz problema comua nicrii a ntre membrii echipei. Este posibil s apar situatii care modelul a a n construit de proiectant s nu e a nteles exact de cel ce scrie cod, e din cauza lipsei de precizie a modului care este prezentat modelul, e datorit incomn a pletitudinii acestuia; adesea o serie de amnunte subtile ce sunt evidente pentru a designer nu sunt transmise. O rezolvare a problemei comunicarii ar ca aceeai s persoan s e implicat direct toate fazele dezvoltrii. Chiar i aa, apare a a a n a s s des situatia care o persoan trebuie s continuie munca alteia. Se impune n a a aadar existenta unui limbaj formal de comunicare al cerintelor. s Termenul formal este esential. De obicei, chiar i proiecte de dimensiuni s n reduse, se face modelare, a ns ntr-un limbaj specic celui care modeleaz, detera minat viziunea sa asupra problemei i de pregatirea acestuia (un matematician s va utiliza o notatie algebric, un arhitect o notatie preponderent grac etc.) a a Folosirea unui limbaj intern nu trebuie privit ca negativ, ea avnd se pare a a a un rol esential gndire general i modelare particular. Modelarea este n a n s n n posibil, chiar i fr folosirea explicit a unui limbaj: a s aa a Cuvintele scrise sau limbajul rostit, nu par s joace nici un rol mecaa n nismele gndirii mele. Entitile zice ce par s serveasc drept elemente de a at a a gndire sunt anumite semne i imagini mai mult sau mai putin clare ce pot a s reproduse i combinate voluntar. (Albert Einstein) s 35

36

CAPITOLUL 6. MODELARE

Aceasta nu nseamn c a comunica altora ideile este facil: a a Trebuie s traduc gndurile a a ntr-un limbaj ce nu curge la fel de lin. Aa s c pierd o groaz de timp cautnd cuvintele i frazele corespunztoare, i sunt a a a s a s contient c atunci cnd mi se cere brusc s vorbesc, de multe ori sunt foarte s a a a neclar datorit faptului c m exprim pur i simplu stngaci i aceasta nu din a a a s a s cauza lipsei de claritate a perceptiei. (Francis Galton) Aa cum formalismul rationamentului matematic poate agentul de transs a n misie al adevarului matematic [7] (care, odat transmis, este tradus limbajul intern al receptorului), formalismul limbajului de modelare const din a stabilirea de elemente cu o semantic asupra creia se convine i cu ajutorul a a s crora s se poat trasmite idei mod ct mai ecient i neambiguu. a a a n a s Limbajul de modelare UML si propune s deneasc o modalitate ct mai a a a precis, general i extensibil de comunicare a modelelor. El a fost creat pria as a n mul rnd pentru a facilita proiectarea programelor, a nsa datorit expresivitii a at sale poate folosit i alte domenii (proiectare hardware, modelarea proceselor s n de afaceri etc.) [6] Folosirea UML faciliteaz comunicarea modelelor, a nu asigur crearea a ns a unui model bun. Limbajul de modelare nu specic i nu poate specica ce a s modele trebuie create, ce ordine i cum trebuie ele utilizate pentru un sistem n s particular. El nu este un nlocuitor al inteligentei, experientei i bunului gust s [9].

6.2

Modele. Limbaje de modelare

Deseori, atunci cnd ne gndim la un obiect a a ntr-un context oarecare, ingorm a caracteristicile care nu intereseaz. De exemplu, la un microprocesor nu ne a intereseaz culoarea sau greutatea. Din punct de vedere practic, este probaa bil inecient s considerm aspectul greutatii microprocesorului de ecare dat a a a cnd utilizam un calculator i de aceea un mecanism de eliminare a caracterisa s ticilor irelevante functioneaz probabil mintea ecruia. a n a Exist a nsa obiecte mult mai complexe dect un microprocesor. O rachet a a cosmic este probabil un artefact ce depete capacitatea de a as s ntelegere a unui singur individ. Motivul pentru care exist totui microprocesoare i navete a s s cosmice este simplu: se folosesc modele. Modelul este o simplicare a realitii. at Aceast simplicare retine caracteristicile relevante ale unui sistem, timp ce le a n ignor pe celelalte. Termenul de relevant este bine eles relativ, diferite aspecte a nt ind relevante functie de problema la care se foloseste modelul respectiv. n S considerm c dorim s analizm modul de comportare al unui corp sub a a a a a actiunea unei forte externe. Pe baza experientei domeniu, tim c singu n s a rele atribute care inuenteaz analiza acest caz sunt masa corpului i forta a n s net care actioneaz asupra corpului. Un model a a ncetenit printre zicieni de at reprezentare a acestei probleme este prezentat gura 6.1: n Acest model face cteva simplicari evidente. Forma corpului este desenat a a ca un ptrat. Diverse alte caracteristici sau interectiuni cu mediul sunt ignorate. a Pe de alt parte, viteza i forta sunt reprezentate prin vectori. Viteza este notat a s a cu v, forta cu F, masa cu m. Toate aceste elemente formeaz un model. Pentru a un initiat, desenul de mai sus este consistent, expresiv i compact. O descriere s alternativ, sub forma de text, dei posibil mai exacta, ar mai greoaie. a s Fie un corp de mas m asupra cruia actioneaz o forta F cu punctul de a a a

6.2. MODELE. LIMBAJE DE MODELARE v

37

F Figura 6.1: Modelarea zica n aplicatie centrul su de greutate. Corpul se deplaseaz cu o vitez v perpen n a a a dicular pe directia fortei. a Limbajul natural pare s e cel mai la a ndemn limbaj de modelare. Experienta a a arat a c folosirea sa induce adesea neclaritati i inconsistente. Apare asta ns a s fel necesitatea denirii unui limbaj neambiguu de specicat modele. Se convine asupra unui set de elemente ale limbajului precum i asupra semanticii acestora. s Evident, descrierea elementelor i a semanticii se face ultim instant lims n a a n baj natural, deci pot apare ambiguiti. acest caz a, limbajul natural este at In ns folosit numai ntr-o mic parte a sistemului i problemele de semantic pot a s a localizate. Eliminarea ambiguitatilor din modele poate facut a mbuntind a at precizia limbajului de modelare i nu cautnd erori de semantic s a a n ntreaga descriere a modelului.

Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing. DICK BRANDON

38

CAPITOLUL 6. MODELARE

Capitolul 7

UML
7.1 Scurt istoric

Incepnd cu mijlocul anilor 1970 i continund anii 1980 au aparut diverse a s a n limbaje de modelare, odat cu creterea experientei de lucru cadrul paradiga s n mei orientate obiect. Astfel, numrul de limbaje de modelare ajunge de la 10 a pna la mai mult de 50 perioada 1989-1994. Limbajele de modelare de success a n din aceast perioad sunt Booch (Grady Booch), OOSE - Object-Oriented Softa a ware Engineering (Ivar Jacobson) i OMT - Object Modeling Technique (James s Rumbaugh). Aceste limbaje aveau propriile punce tari i slbiciuni, dup cum s a a creatorii lor puneau accentul pe anumite idei de modelare. Astfel, utilizatorii gseau tehnicile de modelare ce le erau necesare unui proiect particular numai a anumite limbaje, fapt ce a alimentat rzboiul metodelor. La mijlocul anilor n a 1990, cnd este semnalat o nou generatie de limbaje de modelare, a a a a nceput un proces de omogenizare, prin ncorporarea ecare limbaj a caracteristicilor n gasite celelalte limbaje. n Cei trei autori ai limbajelor de modelare principale, Booch, Rumbaugh i s Jacobson, au ajuns la concluzia ca ar mai bine s conduc evolutia limbajelor a a lor pe un acelasi drum, pentru a elimina diferentele gratuite ce nu fceau dect a a sa ncurce utilizatorii. Un al doilea motiv a fost unul pragmatic, reieit din nes cesitatea industriei software de a avea o oarecare stabilitate pe piata limbajelor de modelare. Al treilea motiv a fost convingerea c prin unirea fortelor se pot a aduce mbunatatiri tehnicilor existente. Dezvoltarea UML a nceput mod ocial octombrie 1994, cnd Rumn n a baugh s-a alaturat lui Booch cadrul companiei Rational Software, ambii n lucrnd la unicarea limbajelor Booch i OMT. Versiunea preliminar 0.8 a a s a Unied (Metoda Unicat - asa cum era numit atunci) a fost publicat oca a a n tombrie 1995. Tot atunci, Jacobson s-a alturat echipei de la Rational i scopul a s UML a fost extins pentru a include i OOSE. iunie 1996 a fost publicat s In a versiunea 0.9 a UML. Pe parcursul anului 1996, ca o consecint a reactiilor coa munitii proiectantilor de sistem, a devenit clar ca UML este vzut de catre at a multe companii ca o optiune strategic pentru dezvoltarea produselor lor. A fost a creat un consortiu UML format din organizatii doritoare s aloce resurse pen a tru a obtine o denitie nal a UML. Dintre aceste companii care au contribuit a la crearea UML 1.0 au fcut parte DEC, Hewlet-Packard, I-Logix, Intellicorp, a 39

40

CAPITOLUL 7. UML

IBM, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments etc. UML 1.0 a fost propus spre standardizare cadrul OMG ianuarie 1997. n n Pn la sfritul anului 1997 echipa care lucra la UML s-a extins, urmnd o a a as a perioad care UML a primit o specicare formal mai riguroas. Versiunea a n a a UML 1.1 a fost adoptat ca standard de catre OMG noiembrie 1997. Actuala n mente UML este dezvoltat de catre OMG Revision Task Force, condus de Cris Kobryn. Versiunea 1.2 a UML a fost o revizie editoriala; versiunile 1.3 au fost publicate ncepnd cu sfritul anului 1998. septembrie 2001 a fost publicat a as In a versiunea 1.4. momentul de fat se lucreaz la versiunea 2.0 a UML. In a a

7.2

Ce este UML?

UML (Unied Modeling Language) este un limbaj de modelare bazat pe notatii grace folosit pentru a specica, vizualiza, construi i documenta componentele s unui program [6],[3]. UML este un limbaj cu ajutorul caruia se pot construi (descrie) modele. Un model surprinde un anumit aspect al unui program. Fiecrui 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 stri (Statechart Diagram) a Diagrama de activiti (Activity Diagram) at Diagrame de implementare: Diagrama de componente (Component Diagram) Diagrama de plasare (Deployment Diagram)

7.3

Organizarea modelelor-Pachete

Un pachet (package) reprezint o grupare a elementelor unui model. Pachetele a nsele pot continute unul ntr-altul. Un pachet poate contine att alte pachete a subordonate, ct i alte tipuri de elemente ale modelului. Toate tipurile de a s elemente ale unui model UML pot organizate pachete. n Pachetele reprezint baza pentru controlul conguratiei, depozitare i cona s trolul accesului. Fiecare element poate continut de un singur pachet. Totui s pachetele pot face referiri la alte pachete, iar modelerea acestor situatii se face folosind unul dintre stereotipurile import i s access asociate unei relatii de dependent. a Notatia grac pentru pachet este prezentat gura 7.1. Un exemplu de a a n relatii care se pot stabili ntre pachete este dat gura 7.2. n

7.3. ORGANIZAREA MODELELOR-PACHETE

41

Figura 7.1: Notatia grac pentru pachet a

Figura 7.2: Exemplu de relatii care se pot stabili ntre pachete

42

CAPITOLUL 7. UML

Figura 7.3: Notatia grac pentru use case a

7.4

Diagrama cazurilor de utilizare (Use Case Diagram)

Nici un program nu este izolat, el interactionnd cu oameni sau cu alte sisteme a pentru ndeplinirea unui scop. O diagram use case este una din cele 4 diagrame folosite UML pentru a a n modela aspectele dinamice ale unui program alturi de diagrama de activiti, a at diagrama de stri, diagrama de secvent i diagrama de colaborare. a a s Elementele componente ale unei diagrame use case sunt use case-uri, actori i relatiile care se stabilesc s ntre acestea.

7.4.1

Use case-uri

Un use case (caz de utilizare) reprezint cerinte ale utilizatorilor. El este o a descriere a unei multimi de secvente de actiuni (incluznd variante) pe care a un program le execut atunci cnd interactioneaz cu entitile din afara lui a a a at (actori) i care conduc la obtinerea unui rezultat observabil i de folos actorului. s s Un use case descrie ce face un program sau subprogram, dar nu precizeaz nimic a despre cum este realizat (implementat) o anumit functionalitate. a a a Fiecare use case are un nume prin care se deosebete de celelalte use cases uri. Acesta poate un ir arbitrar de caractere, a de regul numele sunt s ns a scurte fraze verbale care denumesc un comportament ce exist vocabularul a n sistemului ce trebuie modelat. Figura 7.3 prezint notatia grac pentru use case. a a Comportamentul unui use case poate specicat descriind un ux de evenimente ntr-un text sucient de clar ca s poat eles de cineva din exterior a a nt (de exemplu utilizatorul). Acest ux de evenimente trebuie s includ cum ina a cepe i se termin use case-ul atunci cnd acesta interactioneaz cu actori, ce s a a a obiecte sunt interschimbate, precum i uxuri alternative ale acestui compors tament. Aceste uxuri de evenimente reprezint scenarii posibile de utilizare a a sistemului. Identicarea use case-urilor se face pornind de la cerintele utilizatorului i s analiznd descrierea problemei. a

7.4.2

Actori

Actorii reprezint o multime de roluri pe care utilizatorii unor use case-uri le a joac atunci cnd interactioneaz cu aceste use case-uri. Actorii sunt entiti a a a at exterioare sistemului. Ei pot utilizatori (persoane), echipamente hardware sau alte programe. Fiecare actor are un nume care indic rolul pe care acesta a l joac interactiunea cu programul. a n

7.4. DIAGRAMA CAZURILOR DE UTILIZARE (USE CASE DIAGRAM)43

Figura 7.4: Notatia grac pentru actor a Notatie grac pentru un actor este ilustrat gura 7.4. a a n Exist dou moduri care actorii pot interactiona cu un sistem: a a n 1. folosind sistemul, adic initiaz executia unor use case-uri. a a 2. ind folositi de ctre sistem, adic ofer functionalitate pentru realizarea a a a unor use case-uri. Fiecare actor trebuie s comunice cu cel putin un use case. a Pentru identicarea actorii ar trebui s rspundem la urmtoarele a a a ntrebri: a Cine folosete 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.4.3

Relatii

Relatiile pot de mai multe tipuri: asociere, dependent i generalizare. a s Relatia de asociere Poate exista ntre actori i use-case-uri, sau s ntre use-case-uri. Este folosit a pentru a exprima interactiunea (comunicarea) ntre elementele pe care le unete. s Relatia de asociere se reprezint grac printr-o linie i este evidentiat a s a n gura 7.5. Relatia de dependent a Se poate stabili numai ntre use-case-uri. Relatiile de dependent pot de dou a a tipuri: include i extend. s Dependenta de tip include Notatie grac este dat gura 7.6. a a n acest caz comportamentul use case-ului B este inclus use case-ul A. In n B este de sine stttor, a este necesar pentru a asigura functionalitatea use aa ns case-ului de baz A. Dependenta de tip include se folosette pentru a scoate evident un com n a portament comun (B poate inclus mai multe use case-uri de baz). n a Dependenta de tip extend

44

CAPITOLUL 7. UML

Figura 7.5: Exemplu de diagram use case a

Figura 7.6: Notatia grac pentru relatia de dependent de tip include a a

7.4. DIAGRAMA CAZURILOR DE UTILIZARE (USE CASE DIAGRAM)45

Figura 7.7: Notatia grac pentru relatia de dependent de tip extend a a

Figura 7.8: Notatia grac pentru relatia de generalizare a ntre use case-uri

Notatie grac se poate vedea gura 7.7. a n acest caz comportamentul use case-ului B poate In nglobat use case-ul n A. A i B sunt de sine sttatoare. A controleaz dac B va executat sau nu. s a a a Punctele de extensie specic locul care use case-ul specializat (B) extinde use a n case-ul de baz (A). Pentru ecare use case pot specicate mai multe puncte a de extensie. Fiecare dintre aceste puncte trebuie s aib un nume. Aceste nume a a trebuie s e unice, a nu este obligatoriu ca ele s coincid cu numele use a ns a a case-urilor specializate. De asemenea, trebuie precizat conditia de care depinde a apelul use case-ului specializat. Acest tip de relatie se folosete pentru a modela alternative. s

Relatia de generalizare Se stabiliete s ntre elemente de acelai tip (doi actori, sau doua use-case-uri). s Este similar relatiiei de generalizare (motenire) care se stabiliete a s s ntre clase. Elementul derivat motenete comportamentul i relatiile elementului de baz. s s s a cazul unei relatii de generalizare In ntre use case-uri comportamentul poate modicat sau extins; use case-ul derivat poate nlocui anumite situatii n use case-ul de baz. Case-ul derivat controleaz ce anume se execut i ce se a a as modic din use case-ul de baz. Figura 7.8 ilustreaz notatia grac pentru a a a a relatia de generalizare ntre use case-uri. Observatie: gura 7.9actorii A i B joac acelai rol R atunci cnd n s a s a comunic cu use case-ul UC (a), i joaca roluri diferite interactiunea cu use a s n case-ul UC (b). Utilizri ale diagramei use case: a pentru a modela contextul unui sistem: determinarea granitelor sistemului i a actorilor cu care acesta interactioneaz. 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. Va rezulta specicarea comportamentului dorit. Sistemul apare ca a o cutie neagr. Ceea ce se vede este cum reactioneaz el la actiunile din a a exterior.

46

CAPITOLUL 7. UML

Figura 7.9: Tipuri de roluri jucate de actori interactiunea cu use case-ul UC n (a) A i B joac acelai rol R (b) A i B joaca roluri diferite s a s s

Figura 7.10: Exemplu de notatie grac pentru clas a a

7.5

Diagrama de clase

Este folosit pentru a modela structura (viziunea statica asupra) unui sistem. a O astfel de diagram contine de obicei clase, i relatii care se stabilesc a s ntre acestea. Clasele sunt folosite pentru a surprinde vocabularul sistemului ce trebuie dezvoltat. Ele pot include: abstractii care fac parte din domeniul problemei clase necesare la momentul implementrii. a O clas poate reprezenta entiti software, entiti hardware sau concepte. a at at Modelarea unui sistem presupune identicarea elementelor importante din punctul de vedere al celui care modeleaz. Aceste elemente formeaz vocabulaa a rul sistemului. Fiecare dintre aceste elemente are o multime de proprieti. at Un exemplu de notatie grac pentru clas este dat gura 7.10. a a n

7.5.1

Clase

Elementele unei clase sunt: Nume - prin care se distinge de alte clase. O clas a poate desenat artndu-i numai numele. a aa

7.5. DIAGRAMA DE CLASE

47

Figura 7.11: Notatiile grace pentru diferite tipuri de relatii (a) asociere bidirectional, (b) asociere unidirectional, (c) agregare, (d) dependent, (e) a a a generalizare, (f) realizare Atribute - un atribut reprezint numele unei proprieti a clasei. a at Operatii (metode) - o operatie reprezint implementarea unui serviciu care a poate cerut oricrui obiect al clasei. a O clas poate avea oricte atribute i operatii sau poate s nu aib nici un a a s a a atribut sau nici o operatie. Modelarea vocabularului unui sistem presupune identicarea elementelor pe care utilizatorul sau programatorul le folosete pens tru a descrie solutia problemei. Pentru ecare element se identic o multime a de responsabiliti (ce trebuie s fac acesta), dupa care se denesc atributele at a a i operatiile necesare s ndeplinirii acestor responsabiliti. at

7.5.2

Relatii

O relatie modeleaz o conexiune semantic sau o interactiune a a ntre elementele pe care le conecteaz. modelarea orientat obiect cele mai importante relatii a In a sunt relatiile de asociere, dependenta, generalizare i realizare. Un caz particular s al relatiei de asociere constituie relatia de agregare. l Figura 7.11 ilustreaz notatiile grace pentru diferite tipuri de relatii. a Relatia de asociere Asocierea este o relatie important ce apare foarte des diferite contexte de a n modelare. Ea se folosete pentru a exprima o conexiune semantica s ntre obiecte individuale apartinnd unor anumite clase. a Asocierile poart informatii despre legturile dintre obiectele unui sistem. Pe a a masur ce sistemul evolueaz, legturile dintre obiecte pot create sau distruse. a a a Relatia de asociere ofer baza arhitectural pentru modelarea conlucrrii i a a a s interactiunii dintre clase. O asociere interactioneaz cu obiectele sale prin intermediul capetelor de a asociere. Capetele de asociere pot avea nume, cunoscute sub denumirea de roluri, i vizibilitate, ce specic modul care se poate naviga s a n nspre respectivul capt de asociere. Cea mai important caracteristic a lor este multiplicitatea, a a a

48

CAPITOLUL 7. UML

Figura 7.12: Notatia grac detaliat a relatiei de asociere a a

ce specic cte instante ale ale unei clase pot relationate cu o instant a altei a a a clase. De obicei multiplicitatea este folosit pentru asociatiile binare. a Reprezentarea grac a asocierii este o linie (sau drum) ce conecteaz clasele a a ce particip asociere. Numele asocierii este plasat pe linie, iar multiplicitatea a n i rolurile sunt plasate la extremitile sale (gura 7.12). s at Este posibil specicarea directiei unei asocieri, pentru a elimina legturi a a redundante sau irelevante pentru un anumit model. aceast situatie notatia In a grac pentru relatia de asociere este o linie cu o sgeat la unul din capete a a a indicnd directia asocierii (gura 7.11 (b)). a Relatia de agregare O agregare este o asociere ce modeleaz o relatie parte- a ntreg. Este reprezentat a ca un romb gol ataat la captul asocierii de lng clasa agregat (gura 7.11 s a a a (c)). gur 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). Relatia de agregare este deci un caz particular al relatiei de asociere. Ea poate avea toate elementele unei relatii de asociere, a general se specic ns n a numai multiplicitatea. Se folosete pentru a modela situatiile care un obiect s n este format din mai multe componente. Relatia de dependent a a a ntre dou elemente a O dependent (gura 7.11 (d)) indic o relatie semantic a ale modelului. Se folosete situatia care o schimbare elementul destinatie s n n n (B) poate atrage dup sine o schimbare elementul surs (A). Aceast relatie a n a a modeleaz interdependentelor ce apar la implementare. Dependentele pot s a a apar i la structurarea unui sistem pachete, denind arhitectura sistemului. as n Relatia de generalizare Relatia de generalizare (gura 7.11 (e)) se folosete pentru a modela conceptul s de motenire s ntre clase. gur clasa A este derivat din clasa B. Spunem In a a c A este clasa derivat (sau subclasa, sau clasa copil), iar B este clasa de baza a a (sau superclasa, sau clasa printe). a Relatia de generalizare mai poart denumirea de relatie de tip is a (este un a fel de), sensul c o instant a clasei derivate A este acelai timp o instant n a a n s a a clasei de baz B (clasa A este un caz particular al clasei B sau, altfel spus, a clasa B este o generalizare a clasei A). Clasa A motenete toate atributele i s s s metodele clasei B. Ea poate aduga noi atribute sau metode sau le poate redeni a pe cele existente.

 7.6. DIAGRAMA DE STARI Relatia de realizare

49

Relatia de realizare (gura 7.11 (f)) se folosete cazul care o clas (A) s n n a implementeaz o interfat (B). Se spune c A realizeaz interfata specicat de a a a a a B. O interfat este o specicare comportamental fr o implementare asociat. a a aa a O clas include o implementare. Una sau mai multe clase pot realiza o interfat a a prin implementarea metodelor denite de acea interfat. a a a Figura 7.13 prezint un exemplu de diagram de clase.

7.6

Diagrama de stri a

Este folosit pentru a modela comportamentul unui singur obiect. Diagrama a de stri specic o secvent de stri prin care trece un obiect de-a lungul vietii a a a a sale ca raspuns la evenimente mpreun cu rspunsul la aceste evenimente. a a Un eveniment reprezint ceva (atomic) ce se ampl la un moment dat i a nt a s care are ataat o locatie timp i spatiu. Evenimentele modeleaz aparitia s a n s a unui stimul care poate conduce la efectuarea unei tranzitii ntre stri. 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. Ex: exceptii. s apeluri de operatii (de obicei sincrone): un obiect invoca o operatie pe un alt obiect. Controlul este preluat de obiectul apelat, se efectueaz a operatia, obiectul apelat poate trece ntr-o nou stare, dup care se red a a a controlul obiectului apelant. trecerea timpului o schimbare a strii a Evenimentele pot clasicate felul urmtor: n a sincrone sau asincrone externe sau interne externe: se produc ntre sistem i actori (de exemplu apasrea unui s a buton pentru ntreruperea executiei programului. interne: se produc ntre obiectele ce alctuiesc un sistem (de exemplu a overow exception). O actiune reprezint executia atomic a unui calcul care are ca efect schim a a barea strii sau returnarea unei valori. a Prin activitate se elege executia neatomica a unor actiuni. nt O diagrama de stri poate contine stri i tranzitii. a a s

7.6.1

Stare

Prin stare se elege o conditie sau situatie din viata unui obiect timpul creia nt n a acesta satisface anumite conditii, efectueaz o activitate sau ateapt aparitia a s a unui eveniment.

50

CAPITOLUL 7. UML

Figura 7.13: Exemplu de diagram de clase. a

7.7. DIAGRAMA DE INTERACTIUNI

51

Figura 7.14: Notatia grac pentru stare a Notatia grac pentru stare este det gura 7.14. a a n Elementele unei stri sunt: a Nume - identic mod unic o stare. Numele este reprezentat de o succesiune a n de iruri de caractere. s Actiuni de intrare/ieire - sunt actiuni ce se produc la intrarea, respective s ieirea din starea respectiv. s a Substri - care pot disjuncte (secvential active - gura 7.15(a)) sau concurente a (simultan active - gura 7.15(b)). Tranzitii interne - sunt tranzitii ntre substari care nu produc schimbarea strii obiecului. s Stri particulare (ilustrate gura 7.16) sunt: a n stare initial: starea din care pleac entitatea modelat. a a a stare nal: stare care entitatea modelat si termin existenta. a n a a

7.6.2

Tranzitie

O tranzitie reprezint o relatie a ntre dou stri indicnd faptul c un obiect aat a a a a prima stare va efectua nite actiuni i apoi va intra starea a doua atunci n s s n cnd un anumit eveniment se petrece. a Elementele unei tranzitii sunt ilustrate grac gura 7.17. n Starea surs reprezint starea din care se pleac. a a a Eveniment este evenimentul care declaneaz tranzitia. s a Conditie gard (guard condition) este o expresie boolean. Aceasta se a a evalueaz la producerea evenimentului care declaneaz tranzitia. Tranzitia a s a poate avea loc numai dac conditia este satisfcut. a a a Actiune - optional se poate specica o actiune care s se execute odat cu a a efectuarea tranzitiei. Starea destinatie reprezint starea care ajunge obiectul dup efectuarea a n a tranzitiei. Figura 7.18 arat un exemplu de diagram de stare. a a

7.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. Contextul unei interactiuni (unde pot gsi interactiuni) poate : a sistemul/un subsistem (uzual): multimea obiectelor din sistem care cola boreaz a ntre ele o operatie: interactiuni ntre parametri, variabile locale i globale s

52

CAPITOLUL 7. UML

Figura 7.15: Notatia grac pentru strile compuse: (a) care contin substri a a a disjuncte, (b) care contin substri concurente. a

Figura 7.16: Notatia grac pentru starea initial (a) i starea nal (b) a a s a

7.7. DIAGRAMA DE INTERACTIUNI

53

Figura 7.17: Elementele unei tranzitii o clas: interactiuni a ntre atributele unei clase (cum colaboreaz ele), a interactiuni cu obiecte globale, sau cu parametrii unei operatii. Scopul unei diagrame de interactiuni este acela de a specica modul care n se realizeaz o operatie sau un caz de utilizare. a Obiectele care particip la o interactiune pot lucruri concrete sau proa totipuri. De obicei, ntr-o colaborare obiectele reprezint prototipuri ce joaca a diferite roluri, i nu obiecte specice din lumea real. s a Intre obiectele care particip la o colaborare se pot stabili legturi. O a a legtur (link) reprezint o conexiune semantic a a a a ntre obiecte. Ea este o instant a a unei asocieri i poate avea toate atributele specice asocierii (nume, roluri, nas vigare, agregare), dar nu i multiplicitate. s Obiectele care interactioneaz comunica a ntre ele, comunicarea facndu-se a prin schimb de mesaje. Un mesaj specic o comunicare a ntre obiecte. El poart o informatie i este urmat de o activitate. a s Primirea unei instante a unui mesaj poate considerat o instant a unui a a eveniment. Unui mesaj este asociat o actiune care poate avea ca efect schimi a barea strii actuale a obiectului. a Tipuri de actiuni existente UML: n call: invoc o operatie a unui obiect. Un obiect si poate trimite lui si a nsu un mesaj (invocare local a unei operatii). Este cel mai comun tip de a mesaj. Operatia apelat trebuie s e denit de obiectul apelat i vizibil a a a s a apelantului. return: returneaz o valoare apelantului. a send: trimite un semnal unui obiect. create: creeaz un obiect. a destroy: distruge un obiect. Un obiect se poate autodistruge.

54

CAPITOLUL 7. UML

 7.8. 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). Exist dou tipuri de diagrame a a de interactiuni: diagrama de secvent i diagrama de colaborare. Ele specic a s a aceeai informatie, a pun accentul pe aspecte diferite. s ns

7.7.1

Diagrama de secvent a

Diagrama de secvent pune accentul pe aspectul temporal (ordonarea timp a n a mesajelor). Notatia grac este un tabel (gura 7.19) care are pe axa X obiecte, iar pe a axa Y mesaje ordonate cresctor timp. Axa Y arat pentru ecare 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). aceast a In a perioad obiectul efectueaz o actiune, direct sau prin intermediul procedurilor a a subordonate.

7.7.2

Diagrama de colaborare

Diagrama de colaborare: pune accentul pe organizarea structural a obiectelor a care particip la interactiune. Ea contine obiecte, legturi care se stabilesc a a ntre acestea, precum i mesajele prin care obiectele comunic. Mesajele sunt s a prexate de un numr care indic ordonarea timp a acestora i sunt ataate a a n s s legturilor dintre obiecte. Unei legturi pot ataate mai multe mesaje. a a i s Notatia grac: este un graf care vrfurile reprezint obiecte, iar arcele a n a a reprezint legaturile dintre ele. a

7.8

Diagrama de activiti at

Este folosit pentru a modela dinamica unui proces sau a unei operatii. Spre a deosebire de diagramele de interactiuni, care evidentiaz controlul executiei de a la obiect la obiect, diagramele de activitati scot evident controlul executiei n a de la o activitate la alta. Diagramele de activiti pot contine: at stri activiti i stri actiuni: sunt stri ale sistemului a at s a a tranzitii obiecte

7.8.1

Stri actiuni (action states) a

Modeleaz ceva care se ampl (de exemplu evaluarea unei expresii, apelul a nt a unei operatii a unui obiect, crearea/distrugerea unui obiect). O stare actiune reprezint executia unei actiuni. Ea nu poate descompus. Strile actiuni a a a sunt atomice (nu pot ntrerupte chiar dac se produc evenimente) i au o a s durat nesemnicativ (foarte mic). a a a

56

CAPITOLUL 7. UML

Figura 7.19: Exemplu de diagram de secvent care ilustreaz ce se ampl a a a nt a atunci cnd un student propune un proiect a

 7.9. RECOMANDARI GENERALE DE REALIZARE A DIAGRAMELOR57

7.8.2

Stri activitate (activity states) a

Pot descompuse, activitatea lor putnd repezentat cu ajutorul altor diaa a grame de activiti. Strile activitate nu sunt atomice (pot at a ntrerupte de aparitia unui eveniment) i au durat ( s a ndeplinirea lor se face ntr-un interval de timp)

7.8.3

Tranzitii

Atunci cnd se termin executia unei activiti sau a unei actiuni controlul este a a at dat urmatoarei actiuni sau activiti. at

7.8.4

Ramicatii

Specic alternative a cror alegere depinde de o expresie boolean. O ramicatie a a a poate avea o tranzitie de intrare i dou sau mai multe tranzitii de ieire. Fie s a s care tranzitie de ieire trebuie s aib o conditie gard. Aceste conditii trebuie s a a a s e disjuncte (s nu se suprapun), altfel uxul de control al executiei va a a a ambiguu (nu se tie pe care cale se va continua executia). Conditiile trebuie s a s acopere toate posibilitile, altfel sistemul se poate bloca. ns a at Exist posibilitatea ca mai multe activiti s se execute paralel. Pentru a at a n sincronizarea acestora se folosesc aa numitele bare de sincronizare. Acestea pot s de dou feluri: a Fork Poate avea o tranzitie de intrare i dou sau mai multe tranzitii de ieire, ecare s a s tranzitie de ieire prezentnd un ux de control independent. Activitile de sub s a at fork sunt concurente. Join Reprezint sincronizarea a dou sau mai multor uxuri de control. La join ea a care ux de control ateapt pn cnd toate celelale uxuri de intrare ajung s a a a a acel punct. Poate avea dou sau mai multe tranzitii de intrare i o singur n a s a tranzitie de ieire. s Figura 7.20 ilustreaz un exemplu de diagram de activiti. a a at

7.9

Recomandri generale de realizare a diagraa melor

Diagramele s nu e nici prea complicate, dar nici prea simpliste. a Dati nume sugestive elementelor componente. Aranjati elementele astfel at liniile s nu se intersecteze. nc a Incercati s nu artati prea multe tipuri de relatii odat (altfel vor rezulta a a a diagrame complicate). Dac este nevoie, realizati mai multe diagrame a separate.

58

CAPITOLUL 7. UML

Figura 7.20: Exemplu de diagram de activiti care ilustreaz modul care o a at a n persoan si prepar butura favorit (cafea), sau alege optiunea de a bea cola a a a a cazul care constat c a rmas fr cafea. n n a a a aa

7.10. O VIZIUNE FORMALA

59

7.10
7.10.1

O viziune formala
Introducere

mod curent, interactionm i lucrm cu diferite obiecte. Aceste obiecte pot In a s a foarte complexe. Apare astfel necesitatea de a lucra cu modele, adic cu a imagine mentale simplicate. De obicei, modelele sunt specice ecrui individ a i transmiterea lor poate pune probleme. Pentru a uura comunicarea, este s s de dorit s existe un limbaj comun cu ajutorul cruia s se poat descrie i a a a a s transmit modele. Putem folosi, de exemplu, limbajul natural. Slbiciunea sa a a este c, ciuda efortului care se poate depune pentru a obtine o exprimare a n exact, folosirea sa poate duce la ambiguiti. Putem s folosim un limbaj de a at a programare pentru a modela, i am ctiga astfel exactitate. Dac aceasta s as n a ar o cale sigur de exprimare, o consecint ar c ingineria programrii nu a a a a a ar avea rost1 . O optiune ar folosirea unui limbaj de specicare algebric. Din pcate, lipsa de expeient a majoritii programatorilor acest domeniu face, a a at n deocamdat, aceast abordare nerealist. a a a Limbajele ce sunt folosite pentru a exprima modele sunt numite metamodele. Sensul folosit aici al prexului meta- este acela de ceva care transcede, care este mai curpinztor [1]. Pentru simplitate, putem citi meta-x, ca limbaj pentru a exprimat entiti de tip x. De exemplu, clasa este un meta-obiect. at Pentru ca un anumit limbaj de modelare s nu e ambiguu, la descrierea a acestuia se folosete de obicei un limbaj formal. Limbajul care este specicat s n metamodelul este numit meta-metamodel. Arhitectura cvadri-strat de modelare este denete urmtoarele livele: s a Obiect. Entitate specic mediului. Exemple: pisoiul Worf, negru. a Model. Denete un limbaj de specicare a obiectelor. Exemple: Pisica, s Culoare. Metamodel. Denete un limbaj de specicare a modelelor. Exemple: s Clas, Atribut. a Meta-metamodel. Denete un limbaj de specicare a netamodelelor. s Exemple: MetaClas, MetaAtribut. a UML este un metamodel, adic un limbaj de specicare a modelelor. a

7.10.2

Arhitectura UML

Pentru ca limbajul de specicat modele (meta-modelul) s aib o semantic a a a precis, este necesar denirea acestuia a a ntr-un cadru riguros. Limbajul folosit pentru denirea UML este o combinatie de notatie grac, limbaj natural i a s limbaj formal. Notatia grac folosit este ai notatia grac a UML. Astfel, un subset a a nss a al UML este folosit pentru a modela ntreg limbajul grac UML. O asemenea descriere meta-circular2 pare c se abate de la scopul declarat al preciziei. a a Autorii limbajului au considerat a c acesta este compromisul cel mai bun ns a
1 Din 2 Pentru

pcate, are a a elege denitia UML este necesar cunoaterea unei prti a UML nt a s a

60

CAPITOLUL 7. UML

ntre expresivitate i simplitate. Pe de alt parte, descrieri meta-circulare apar s a destul de des. De exemplu, dictionarele i regulile gramaticare ale unei limbi pot s exprimate acea limb. Un compilator de C este folosit pentru a compila n a un compilator de C. cazul UML, descrierea circular este In a ntrerupt prin a folosirea limbajului natural.

Die Mathematiker sind eine Art Franzosen: redet man zu ihnen, so ubersetzen sie es in ihre Sprache, und dann ist es alsobald ganz etwas Anders. GOETHE, Maxime i cugetri (1829) s a

Capitolul 8

Testare
Scopul dezvoltrii software este acela de a obtine un program conform cu specicatiile a pe baza crora a fost scris i care corespunde ateptrilor clientului. Testaa s s a rea este activitatea prin care sunt scoase evident defecte ale unui program n a nainte ca programul s e livrat. Exist dou procese diferite strns legate de a a a a activitatea de testare. Acestea sunt validarea i vericarea. s Validarea este procesul prin care ne asigurm c programul este corect din a a punctul de vedere al clientului. Intrebarea care se pune cazul validrii este: n a Construim produsul corect? (Are we building the right product?). Vericarea este procesul prin care ne asigurm c programul este corect a a din punctul de vedere al programatorului. Intrebarea care se pune aici este Construim corect produsul? (Are we building the product right?). Validarea i vericarea au loc la ecare etap a procesului de dezvoltare a s a unui program. Cea mai mare parte a acestor procese, a, se desfoar atunci ns as a cnd sistemul este operational, adic dup faza de implementare. a a a Cu exceptia programelor mici, sistemele nu ar trebui testate de la nceput ca un ntreg nedivizibil. Sistemele mari sunt construite din subsisteme. Subsistemele, la rndul lor, sunt formate din module. Modulele contin proceduri i a s functii. Procesul de testare trebuie efectuat etape pe msur ce sistemul este n a a implementat. Figura 8.1 prezint un proces de testare cinci etape care componentele a n n sunt testate mai ai individual, apoi sunt integrate sistem. Sistemul este nt n testat pe msur ce noi componente sunt integrate i, nal, sistemul este a a s n testat cu date primite de la client. cazul ideal, defectele componentelor sunt In descoperite devreme procesul de testare, iar problemele legate de interfete n ies evident la integrare. Totui, defectele descoperite program trebuie n a s n reparate, astfel aprnd noi etape procesul de testare. Procesul de testare este aa n un proces iterativ. Informatii obtinute etapele trzii sunt furnizate etapelor n a timpurii. Etapele procesului de testare sunt: 1. Testarea unitilor. Componentele individuale sunt testate pentru a se at asigura functionarea lor corect. Fiecare component este testat inde a a a pendent. 2. Testarea modulelor. Un modul reprezint o colectie de componente care a depind unele de altele. Exemple de module sunt clase de obiecte, tipuri ab61

62

CAPITOLUL 8. 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.1: Proces de testare cinci etape n stracte de date sau colectii de proceduri i functii. Un modul s ncapsuleaz a componente nrudite care pot testate fr a necesita prezenta altor moaa dule din sistem. 3. Testarea subsistemelor. Aceast faz presupune testarea unei colectii a a de module care au fost integrate ntr-un subsistem. Cele mai obinuite s probleme care apar aceast etap sunt cele legate de nepotriviri ale n a a interfetelor. Procesul de testare al subsistemelor trebuie, deci, s se con a centreze pe detectarea erorilor de interfat ale modulelor exersnd mod a a n riguros aceste interfete. 4. Testarea sistemului. Subsistemele sunt integrate formnd sistemul. Acest a proces vizeaz gsirea erorilor care apar datorit problemelor de interactiune a a a ntre subsisteme i s ntre interfete ale subsistemelor. Aceast faz se ocup a a a i de validarea sistemului, precum i de testarea unor proprieti ale siss s at temului. 5. Testul de acceptare. Este etapa nal a procesului de testare a nainte ca sistemul s e acceptat vederea folosirii lui. aceast faz sistemul este a n In a a testat cu date furnizate de ctre client loc de datele de test simulate a n folosite celelalte etape. Testul de acceptare poate scoate evident n n a erori i omisiuni denirea cerintelor deoarece datele reale pot exersa s n sistemul mod diferit fat de datele de test. Testul de acceptare poate n a evidentia i probleme legate de modul (uurinta) de utilizare sau probleme s s de performant ale sistemului. a Testarea unitilor este responsabilitatea programatorilor care dezvolt comat a ponenta. Programatorii si construiesc propriile date de test i testeaz codul s a incremental, pe msur ce este scris. Ei sunt cei mai msur s fac acest a a n a a a a lucru deoarece cunosc cel mai bine componenta pe care o dezvolt. Aceast a a

63

Localizeaza eroarea

P roiecteaza modalitatea de corectare a erorii

Corecteaza eroarea

Retesteaza programul

Figura 8.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.3: Etapele testrii cadrul procesului de dezvoltare software a n activitate scoate deseori evident defecte ale programului care trebuie elimin a nate. Procesul care se ocup cu localizarea i corectarea erorilor din program a s poart denumirea de debugging. Figura 8.2 ilustreaz un posibil proces de dea a bug. Defectele codul surs trebuie localizate, iar programul trebuie s e n a a modicat pentru a satisface cerintele. Testarea trebuie repetat pentru a avea a siguranta c modicrile fcute sunt corecte. Deci procesul de debug este o a a a parte att dezvoltrii ct i a testrii unui program. Testarea unitilor este, a a a s a at prin urmare, o parte a procesului de implementare. Ca rezultat al etapei de testare a unitilor sunt ateptate componente conforme cu specicatiile pe baza at s crora au fost dezvoltate. a Etapele urmtoare presupun integrarea muncii mai multor programatori. a Ele trebuie planicate i o echip trebuie s lucreze pe un plan de testare dezs a a voltat pe baza specicatiilor i a designului sistemului. Figura 8.3 ilustreaz s a modul care planurile de test sunt legate de activitile de testare i dezvoln at s tare. Testarea vederea acceptrii mai poart denumirea de testare alpha (aln a a pha testing). aceast situatie sistemele sunt dezvoltate pentru un singur In a client. Procesul de testare alpha continu pn cnd 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. Cnd sistemul va vndut ca un produs pe piat procesul de testare poart a a a a denumirea de testare beta (beta testing). Testarea beta presupune livrarea sistemului unui numr de potentiali clienti care sunt de acord s foloseasc sistemul. a a a Ei vor raporta problemele alnite celor care dezvolt sistemul. Acest tip de nt a utilizare real a sistemului va evidentia erori care nu au fost anticipate de cei a care construiesc produsul. urma acestor reactii sistemul este modicat i In s

64

CAPITOLUL 8. 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: Model general de testare livrat e pentru o nou faz de testare beta, e pentru vnzare. a a a

8.1

Metode de testare

Scopul testrii este de a scoate evident defecte ale unui program a n a nainte ca programul s e livrat. Un test reuit este acela care face programul s se coma s a porte incorect, care evidentiaz un defect. Testarea demonstreaz prezenta, i a a s nu absenta, erorilor ntr-un program. Un model general de testare este prezentat gura 8.4. n Cazurile de test sunt specicatii care contin intrri ale testului, rezultatele a ateptate din partea sistemului, precum i o precizare a cerintei testate. Datele s s de test sunt date de intrare concepute pentru testarea programului sau componentei. Ele pot uneori generate automat. Generarea automat a cazurilor a de test este a imposibil deoarece rezultatele ateptate nu pot prezise ns a s n aceast situatie. a Testarea exhaustiv este, dac nu imposibil, cel putin impractic. De aceea a a a a practic testarea se bazeaz pe alegerea unei submultimi ale cazurilor posibile n a a de test.

8.1.1

Testarea functional (Black-box testing) a

cazul testrii functionale testele sunt derivate din specicatiile programului In a sau componentei. Persoana care face testarea (tester) este preocupat doar de a functionalitatea programului, nu i de modul care este implementat acesta. s n Programul este considerat o cutie neagr a crui comportament poate dea a terminat doar studiind intrrile i iesirile corespuztoare. Schema general a a s s a a modelului de testare functional este ilustrat gura 8.5. a a n Deoarece un test reuit este cel care evidentiaz prezenta unei erori, pros a blema principal care apare cazul testrii functionale const selectarea a n a a n unor date de test care s apartin cu o probabilitate mare multimii Ie . multe a a In situatii selectia acestei multimi de date de test este bazat pe experienta celui a care face testarea i care folosete cunotinte din domeniul problemei. Exist s s s a a i o abordare sistematic care datele de intarea se ns s a n mpart clase de n echivalent. Datele din aceeai clas de echivalent au caracteristici comune. a s a a mod normal, programul se va comporta mod similar pentru toti membrii In n aceleiai clase. s Clasele de echivalent se identic folosind specicatiile programului. Odat a a a

8.1. 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.5: Schema general a modelului de testare functional a a Date de test testeaza deriveaza Codul componentei Rezultate

Figura 8.6: Schema general a modelului de testare structural a a identicate, datele de test se aleg din ecare clas (este indicat s se testeze a a granitele i un punct de mijloc al clasei de echivalent). cazul care datele s a In n de intrare pot avea dimensiuni diferite este bine ca aceste dimensiuni s varieze a la ecare test.

8.1.2

Testarea stuctural (White-box testing) a

cazul testrii structurale testele sunt construite tinnd cont de implementaIn a a rea programului (8.6). Acest tip de testare se aplic la uniti de program de a at dimensiuni mici (functie, operatie asociat unui obiect). Ideea este ca ecare a instructiune din program s e executat cel putin o dat. Punctul de plecare a a a cazul testrii structurale constituie graful executiei programului. Acesta se n a l obtine analiznd codul surs. Drept noduri sunt considerate punctele de deci a a zie (ramicatie) din program. Un singur nod va reprezenta toate instructiunile care se exucut secvential pe o aceeai ramur (atribuiri i instructiunile de a s a s intare/ieire). Muchiile grafului indic uxul executiei programului. s a Scopul cazul testrii structurale este ca ecare drum independent din n a program s e executat cel putin o dat. Un drum independent este un drum a a care contine cel putin o muchie netestat din graful executiei. Fiecare punct a de ramicatie trebuie testat ambele situatii ( cazul care conditia este n n n

66

CAPITOLUL 8. TESTARE T1 T1 T1 A T2 B T3 C D T4 T5 Figura 8.7: Exemplu de testare la integrare B T3 C T4 A T2 B T3 A T2

adevrat i cazul care conditia este fals). a a s n n a

8.1.3

Testarea la integrare

Dup ce componentele programului au fost testate individual, ele trebuie intea grate pentru a crea un sistem partial sau complet. Acest proces de integrare presupune construirea i testarea sistemului rezultat vederea descoperirii pros n blemelor care apar datorit interactiunii dintre componente. Testele de integrare a trebuie s e dezvoltate pe baza specicatiilor sistemului, iar testarea integrrii a a componentelor ar trebui s a nceap ce a ndat ce sunt gata versiuni functionale a ale unor componente ale sistemului. Problema principal care apare cazul acestui tip de testare const a n a n localizarea erorilor descoperite timpul procesului de testare. De multe ori n interactiunile ntre componentele sistemului sunt complexe, iar atunci cnd este a obtinut un rezultat eronat este greu de descoperit sursa care a cauzat eroarea. Pentru a face localizarea erorilor mai uoar se recomand folosirea integrrii s a a a incrementale a componentelor. Initial ar trebui integrat o conguratie mini a mal i testat sistemul obtinut. Celelalte componente vor adugate una cte as a a una, sistemul ind retestat dup ecare nou adugare a unei componente. a a a Figura 8.7 prezint un exemplu de testare la integrare. Testele T 1, T 2, T 3 a sunt mai ai rulate pe o conguratie minimal format din componentele A nt a a i B. Dac sunt evidentiate erori, acestea sunt corectate. Un nou modul, C, s a este integrat, i testele T 1, T 2, T 3 sunt repetate pentru avea siguranta c nu s a au aprut erori neateptate. Dac apar erori, este probabil ca acestea s e a s a a cauzate de interactiunea celor trei componente. acest mod este localizat In a sursa problemei, simplicndu-se localizarea i remedierea erorii. a s

8.1.4

Testarea interfetelor

Are loc procesul de integre a modulelor sau subsistemelor sisteme mai n n mari. Fiecare modul sau subsistem are o interfat care poate apelat de a a alte module. Obiectivul acest caz este de a detecta erori ale interfetelor sau n presupuneri greite legate de interfete. Problemele aprute se s a ncadreaz una a n din urmtoarele categorii: a

8.1. METODE DE TESTARE

67

Folosirea greit a interfetei. O component apeleaz greit alt coms a a a s a ponent. Aceast eroare apare cazul interfetelor parametrizate i se a a n s poate datora trimiterii unor parametri avnd un alt tip dect cei ceruti de a a interfat, sau trimiterea a ntr-o alt ordine a parametrilor, sau trimiterea a unui numr greit de parametri. a s Ne elegeri legate de interfat. O component apelant elege greit nt a a a nt s specicatiile interfetei i face o presupunere eronat legat de comporta s a a mentul componentei apelate. Aceast presupunere va cauza o eroare a n functionarea componentei apelante. Erori de timp. Apar cazul sistemelor timp real cnd se folosete n n a s memorie partajat sau transmitere de mesaje. a

8.1.5

Testarea la stress

Are drep scop scoaterea evident a performantei i sigurantei sistemului. n a s Testarea la stress presupune dezvoltarea unei baterii de teste care sistemul n este supra arcat. Se testeaz astfel comportamentul sistemului atunci cnd nc a a acesta cedeaz. Este important ca cazul care sistemul cedeaz acest lucru a n n a s nu cauzeze coruperea datelor. a

8.1.6

Testarea orientat obiect a

Se desfoar pe mai multe nivele: as a 1. testarea individual a operatiilor unui obiect. Acestea sunt functii i proa s ceduri. Pentru testarea lor se poate folosi testarea functional sau testarea a structural. a 2. testarea unei clase de obiecte. 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. 3. testarea unui cluster de obiecte. Se bazeaz pe construirea de scenarii a n care sunt implicate obiectele. 4. testarea sistemului orientat obiect. Presupune validarea i vericarea siss tenului pe baza specicatiilor cerintelor.

If you think all change is for the better, why put it to the test? DISCOVERY CHANNEL, promo

68

CAPITOLUL 8. TESTARE

Capitolul 9

Calitatea programelor
Cnd vorbim despre calitatea unui lucru (constructie sau obiect) de obicei lum a a calcul mai multi factori. Printre acetia se pot numra: n s a calitatea realizrii - ct de bine este lucrat, dac exist defecte materialul a a a a n din care este fabricat ... designul - eleganta, comfortul oferit... o combinatie ntre design i calitatea realizrii. s a Atunci cnd suntem pui situatia de a compara dou obiecte similare, de a s n a exemplu dou scaune, putem spune c din punctul de vedere al calitii unul a a at este mai bun dect cellalt, a general este dicil de precizat cu ct este a a ns n a mai bun. cazul programelor nu se poate evalua calitatea realizrii. Din acest punct In a de vedere ingineria programrii este o disciplin unic a a a ntre toate disciplinele inginereti. Toate atributele calitii se refer aici la design. Desigur, ne-am s at a putea referi i la valori de ordin estetic. a programele sunt mare parte s Ins n invizibile, iar valorile estetice conteaz doar pentru prtile vizibile. a a Inafar a de interfat, singurele aspecte observabile la un program sunt notatiile folosite a pentru design i scrierea codului, precum i modul care se comport programul s s n a atunci cnd interactioneaz cu alte entiti. a a at Pentru a putea vorbi despre calitatea unui program trebuie s denim atria bute ale calitii care ne intereseaz i s cutm modaliti de msurare a lor, at as a a a at a trebuie s putem da o reprezentare designului i s scriem specicatii care s a s a a ghideze programatorii astfel at calitile designului s e respectate i de nc at a s implementare. Codul surs care implementeaz un design poate privit ca o reprezentare a a a acelui design. a asigurarea calitii unui program numai dup scrierea Ins at a codului este, general, un proces deosebit de costisitor. n Este greu s dm o denitie calitii unui program. Ar trebui s lum a a at a a n calcul aspecte de tipul: programul functioneaz i, plus, functioneaz aa cum are nevoie utili a s n a s zatorul s functioneze. a programul face ceea ce trebuie s fac. a a 69

70 programul este sigur.

CAPITOLUL 9. CALITATEA PROGRAMELOR

programul poate adaptat pe msur ce nevoile utilizatorului se schimb. a a a Aceti factori nu pot msurati mod absolut, a ne furnizeaz cteva s a n ns a a concepte la care ne putem referi atunci cnd vorbim despre calitatea unui proa gram. Ele sunt siguranta, ecienta, ntretinerea i, nu ultimul rnd, uzabili s n a tatea programului. Un program este sigur dac este a complet - trateaz toate intrrile posibile; a a consistent - se comport a ntotdeauna aa cum este ateptat; s s robust - se comport bine situatii anormale (de exemplu lipsa unei a n resurse necesare). Un program este ecient dac utilizeaz a a ntr-un mod judicios resursele disponibile (memorie, procesor, retea). Ecienta este ntotdeauna mai putin im portant dect siguranta. Este mai uor s facem un program sigur s e ecient a a s a a dect un program ecient s e sigur. a a Intretinerea se refer la uurinta cu care poate modicat ulterior designul a s programului. Exist mai multe tipuri de a ntretinere: corectiv - are drep scop eliminarea erorilor din program; a perfectiv - presupune adugarea de functionaliti care ar trebuit s e a a at a oferite; adaptiv - se refer la actualizarea programului pe msur ce se schimb a a a a a cerintele. Uzabilitatea are vedere ct de uor este programul de aat i de folosit. n a s nvt s Putem da a o msur obiectiv tutror acestor caracteristici? Rspunsul ns a a a a este negativ. Fiecare dintre atributele de mai sus poate apreciat mod n diferit de ctre diferite persoane, deci sunt criterii subiective. Singurele atria bute msurabile sunt cele care vizeaz codul surs. Acestea sunt simplitatea i a a a s modularitatea codului surs. a Simplitatea este msura invers a complexitii. Complexitatea, la rndul a a at a ei, se poate referi la: complexitatea uxului de control care numr cile posibile de executie ale aa a unui program. complexitatea uxului de informatii care numr cantitatea de date care aa sunt transmise program sub form de date de intrare/ieire sau paran a s metri ai functiilor; complexitatea elegerii care se refer ca numrul identicatorilor i opent a a s ratorilor folositi. Scopul, atunci cnd scriem un program, este s obtinem un cod surs ct a a a a mai simplu posibil. De obicei acest deziderat nu se obtine din prima, ci este rezultatul unui proces de rescriere i simplicare a variantei initiale a progras mului.

71 Modularitatea, pe de alt parte, poate msurat uitndu-ne la coeziunea a a a a i cuplajul modulelor din program. Coeziunea se refer la ct de bine lucreaz s a a a mpreun componentele unui modul, iar cuplajul msoar gradul de interactiune a a a ntre module. Scopul constituie obtinerea unui progam ale crui module au l a un grad nalt de coeziune (ecare ndeplinete o sarcin specic) i s a a s ntre care exist ct mai putine dependente (cuplaj mic). a a

If the automobile had followed the same development as the computer, a Rolls-Royce would today cost $100, get a million miles per per gallon, and explode once a year killing everyone inside. ROBERT CRINGLEY, InfoWorld

72

CAPITOLUL 9. CALITATEA PROGRAMELOR

Capitolul 10

Metrici pentru programe

Imaginati-v c luati un taxi ca s mergeti pn la teatru i c la sfritul 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 lsa prad dezgustului fata unei probleme att de a a n a triviale, vom ncerca totui s analizm situatia. O prim s a a a ntrebare ar : ct a de departe este teatrul? Ne ateptm ca cu ct distanta este mai mare, cu att s a a a pretul s e mai mare. Probabil c nu exist o tax specic 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-adevr, cursele se pltesc 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 punctul de plecare. Scandalos, ce mai. S facem ipoteza simplicatoare c teatrul la care vrem s mergem nu este a a a New York. Corect ar ca n nainte de a ne urca taxi s n a ntrebm ct ne a a va costa drumul. cel mai bun caz, oferul va In s ntinde plictisit degetul spre rma de pe capota, mormind ceva despre capacitatea noastr de a decodica a a alfabetul latin i cifrele arabe. Minunat! Acum tim ct cost ca s mergem cu s s a a a taxiul un kilometru. Din nefericire, nu tim care este distanta pn la teatru. s a a Un set de instrumente de ndejde ne vine ajutor. Punem rigla pe hart, a n a facem nite socoteli care intervine i scara hrtii i obtinem o estimare a s n s a s distantei. a o Inc nmultire i obtinem un pret. Acesta ind mult mai mic dect s a suma de bani pe care o avem portofel, ne urcm victorioi taxi. n a s n Din pcate, pretul de 10 euro care ni se comunic la sfrit este motivul unei a a as nemultumiri evidente din partea noastr. Pe msur ce anii trec i devenim mai a a a s elepti, am c: nt a a Harta este imperfect. a Msurarea distantei cu rigla este imprecis. a a Taxiul nu merge linie dreapt, ci pe osele n a s Chiar cnd merge pe osele, oarece ocoliuri ajut la sporirea veniturilor a s s a oferului. s Pe lng pretul pe kilometru exist i o tax x, de pornire, care se a a a s a a adaug la suma pltit. 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 scdea, accidental sau nu, pentru a a spori aderenta pe timp de iarn i a mri numrul de revolutii pe care le as a a fac rotile atunci cnd o anumit distant este parcurs. a a a a Pretul de pe rma luminoas se poate s nu e sincronizat cu cel de pe a a taximetru.

Acum, adevrata 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 cnd un prieten ne a ntreab cum merge treaba la programul la care a lucrm ne putem mrigini s spunem bine sau cam ru. Este acceptabil a a a a s expimm astfel opinii personale, bazate pe intuitie i afecte. Dar cnd eful a a s a s aude c proiectul merge cam ru, el vrea s tie de ce merge cam ru, care a a as a este distanta pn la acceptabil i ce trebuie fcut ca s se ajung la foarte a a s a a a bine. Avem nevoie aadar de uniti de msur pentru a cuantica diverse ass at a a pecte ce apar cadrul dezvoltrii de programe. Ne intereseaz ct de mare n a a a este un program, ct de complex, ct de bine testat. De asemenea, care este a a timpul necesar dezvoltrii programului, de ci oameni avem nevoie, care este a at productivitatea muncii, care sunt costurile de dezvoltare. S-au propus foarte multe modaliti de msurare a activitilor ce intervin at a at n timpul dezvoltrii unui produs. Aceasta exemplic interesul foarte mare pena a tru subiect. Totui, nu exist a o metodologie unanim acceptat de a face s a nc a msurtori, dei unele metodologii sunt mai populare dect altele. Fiecrei mea a s a a todologii i se pot aduce critici incomode i, din pcate, general s a n ndreptite. at Oricum, msurtorile imperfecte sunt mai bune dect nici o msurtoare, cu a a a a a conditia s contientizm imperfectiunile. Cum avem la dispozitie multiple me a s a todologii de msurare, aceasta ne poate spori a ncrederea estimrile fcute. 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). Dei s aici pstrm acronimul termenilor limba englez, vom citi KLOC ca mii linii a a n a cod. KLOC este o msur neechivoc a dimensiunii unui program. Greeala a a a s care se poate face este s se considere c aceast metric poate 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 pltiti 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 deosebit de complicate.
1 Eufemismele

si au, se pare, cteodat, utilitatea lor. a a

10.3. EVALUAREA COSTURILOR

75

10.2.2

PM

PM este un acronim pentru person-month2 (om-lun). Aceasta reprezint o a a msur 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 jumtate efectueaz 15 PM. a a a s a a Si aceasta este o msur oarecum imprecis: se refer la un om nemotivat, la un a a a a om care lucreaz i la sfrit de sptmn, 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 timpul necesar dezvoltrii, 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 ranare a estimrii: COCOMO de baz, a a COCOMO intermediar i COCOMO detaliat. s COCOMO de baz propune urmtoarea legtur 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 clasicat 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 desfoar medii care exist restrictii severe. at a n n a Proiectul va integrat ntr-un produs existent care este inexibil. Exemple de astfel de sisteme: controlarea tracului aerian, monitorizarea pacienttilor. Semidetaate O form intermediar s a a ntre cele doa de mai sus. Echipa este a format dintr-un amestec de oameni experimentati i mai puin expeimentati, a s s proiectul poate destul de mare, dar nu excesiv etc. Parametrii lui COCOMO de baz pentru ecare dintre aceste tipuri de a proiecte, sunt prezentati tabelul 10.1. n Prima versiune a lui COCOMO presupunea c se folosete modelul de deza s voltare cascad. De atunci, au avut loc schimbri semnicative modul de n a a n dezvoltare a programelor. De aceea, estimrile COCOMO deveniser irelevante. a a Am ales s prezentm 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 interpretat ca a a a a discriminatorie.

76

CAPITOLUL 10. METRICI PENTRU PROGRAME organic semidetaat s integrat b = 2.4 b = 3.0 b = 3.6 c = 1.05 c = 1.12 c = q.20

Tabela 10.1: Valorile parametrilor pentru COCOMO de baz a

10.3.2

COCOMO 2

O versiune actualizat a COCOMO a fost propus de Boehm 1995. Aceast a a n a versiune este referit ca COCOMO 2. a COCOMO 2 recunoate existenta mai multor modele i tehnici de dezvols s tare, cum ar prototipizarea, dezvoltarea pe compomente, utilizarea de limbaje de programare moderne etc. Acest nou model nu nseamn doar o ranare a a estimrii pe etape, ci i posibilitatea obtinerii unor estimri fazele incipiente a s a n ale dezvoltrii. a Prototipizarea initial Surpinde efortul necesar realizrii unui prototip al a a aplicatiei. Estimarea se bazeaz pe evaluarea numrului punctelor obiect (NOP a a number of object point). Numrul punctelor obiect se calculeaz astfel: a a Se inventariaz ecranele care trebuie aate. Ecranele simple primesc 1 a s punct obiect, ecranele moderat de complexe primesc 2, ecranele foarte complexe primesc 3. Se inventariaz rapoartele care trebuie obtinute. Un raport simplu primete a s dou puncte obiect, cele moderat de complexe 5, iar cele dicile 8. a Fiecare modul limbaj de nivel mai jos ce trebuie scris pentru a oferi n servicii programului orienta-obiect primete 10 puncte. s De obicei se folosesc statisticile anterioare pentru a estima cte linii de cod a sunt necesare pentru a implementa un punct obiect. Evident, este discutabil a potrivirea acestora pentru programul pentru care se face evaluarea. Boehm sugereaz c productivitatea variaz a a a ntre 4 i 50 puncte obiect pe lun, functie s a n de intrumentele utilizate i de performanta programatorilor. Media numrului s a liniilor de cod necesare pentru a implementa un punct obiect poate varia de la 2 la 40 ntr-un limbaj orientat obiect. Atunci cnd se ralizeaz un prototip gradul de reutilizare a codului este a a semnicativ, aadar formula de estimare a efortului ia calcul acest factor s n (Preuse ). Productivitatea este notat cu PROD: valorile acestui parametru se a extrag din tabelul 10.2. P M = (1 Preuse ) N OP P ROD (10.2)

Proiectarea initial Estimrile folosite pentru acest stadiu folosete formula a a s 10.3, similar cu cea din modelul COCOMO de baz. a a E = a sizeb m. (10.3)

10.3. 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.2: Valorile parametrului P ROD (productivitatea) functie de niven lul programatorilor.

Aici, valoarea coecientului a este 2.5. Dimensiunea sistemului size este exprimat KLOC. Ea este calculat estimnd numrul de puncte obiect i a n a a a s apoi convertindu-l KLOC. n Termenul M este bazat pe 7 factori ai proiectului i ai procesului de dezs voltare. Aceti factori sunt: siguranta i complexitatea produsului (RCP X), s s gradul de reutilizare cerut (RU SE), dicultatea platformei (P DIF ), capacitatea personalului (P ERS), experienta personalului (P REX), comprimarea planului (SCED), faciliti pentru asistent (F CIL). Pentru ecare se face o at a estimare direct pe o scar de la 1 la 6, unde 1 corespunde unei valori mici, iar a a 6 corespunde unei valori mari pentru factorul corespunztor. a P M = A SizeB M + P Mm (10.4)

M = P ERS RCP X RU SE P DIF P REX F CIL SCED

(10.5)

Ultimul termen al formulei 10.4 este folosit atunci cnd o cantitate a nsemnat a de cod este generat automat (ASLOC). general, pentru a integra codul a In generat automat ntr-un program este nevoie s se scrie o anumit cantitate a a (suplimentar) de cod. Oricum, productivitatea cazul generrii automate de a n a cod (AT P ROD) este mai mare dect dac nu s-ar folosi aceast tehnic. Dac a a a a a considerm Pauto procentul de cod generat automat din aplicatie, atunci a P Mm = (ASLOC Pauto )/AT P ROD (10.6)

Dup proiectare acest stadiu estimarea poate fcut mai precis. Se a In a a folosete aceeai formul ca i cea de la proiectarea initial (10.4). Acum a s s a s a ns se iau calcul 17 factori, fat de cei numai 7 folositi pn acum. n a a a Ne vom rezuma doar la a enumera factorii ce sunt luati considerare, fr n aa a mai enumta formulele care acetia intervin. 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 Constrngerile privind timpul de executie a

78

CAPITOLUL 10. METRICI PENTRU PROGRAME Constrngerile 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 comunicrii n s a ntre acestea

Estimarea pretului proiectului SC = Ef f ort RELY T IM E ST OR T OOL EXP IN DP (10.7)

Factorul IN DP reprezint costul individual pentru un membru al echipei. a Estimarea duratei proiectului T DEV = 3 (P M )0.33+0.2 (B1.01) T DEV = 3 (P M )0.33+0.2 (B1.01) PSCHED (10.8)

(10.9)

10.3.3

Distributia fortei de munc timp a n

Faptul c avem o estimare a efortului necesar dezvoltrii unui program exprimat a a om-lun (PM), nu n a nseamn c tim ct va dura dezvoltarea i nici cum vom a as a s organiza munca. De exemplu, tim c unei femei3 trebuie nou luni pentru a nate un copil. s a i a s Dac strngem a a ntr-o echip nou femei arcinate, nu a a ns nseamn c vom avea a a un copil urmtoarea lun. n a a Pe baza unor date statistice, Conte a gsit urmtoarea relatie a a ntre ntre productivitatea medie L (msurat linii de cod pe om-lun) i dimensiunea a a n a s echipei (P ): 1 L = 777 . (10.10) p Aceasta nseamn c productivitatea individual scade exponential odat cu a a a a creterea dimensiunii echipei. s
3 Din

specia homo sapiens

10.4. METRICI ORIENTATE OBIECT

79

Putem aborda problema i din punct de vedere teoretic. s Intr-o echip, de a dimensiune P , ecare membru trebuie s si coordoneze activitatea cu ceilalti a membri ai echipei. functie de structura echipei, un membru poate nevoit s In a comunice cu toti ceilalti P 1 sau cu mai putini, a cu mcar 1. Considerm ns a a coecientul specic echipei care d numrul mediu de legturi a a a ntre membrii echipei, (P 1) , unde 0 1. Considerm c productivitatea individual a unui programator este L, iar a a a pierderea de productivitate datorat unei legturi de comunicare este l. Proa a ductivitatea medie a unui membru al echipei va : L = L l(P 1) . Aadar, productivitatea total a echipei se exprim astfel: s a a Ltot = P L = P (L l(P 1) )
Vezi pagina cursului pentru grafice

(10.11)

(10.12)

10.3.4

Cum nu se evalueaz costurile a

Probabil titlul acestei sectiuni ar trebuit s e cum nu se evalueaz tiintic a as costurile sau cum nu este cinstit s se evaleaze costurile. ciuda negatiei a In din titlu, prezentm cteva modaliti care divese organizatii decid totui s a a at n s a si evalueze costurile i s si planice activitatea. s a Avem 12 luni la dispozitie ca s terminm treaba, deci proiectul va dura 12 a a luni. Legea lui Parkinson: munca se ntinde pe timpul avut la dispozitie. Stim c competitorul nostru a cerut 1 milion de dolari, noi vom cere 950 a de mii. Stim c bugetul clientului pentru proiect este de 500 mii de dolari. Cerem a 6 sute de mii i ne elegem la 5. s nt Vrem s prezentm produsul la CeBit anul viitor, deci pn atunci trebuie a a a a s e gata. a Programul va dura cam un an de zile, dar nici un caz eful meu nu va n s de acord cu asta. Vom spune c dureaz 8 luni: odat ce au investit att a a a a program, vor trebui s mai suporte dezvoltarea cteva luni. n a a Aceste decizii sunt numite decizii politice. Acestea i-au dovedit destul de s des efectul dezastruos pe care au asupra clientilor sau a echipei de dezvoltare. l

10.4

Metrici orientate obiect

Adncimea arborelui de derivare Msoar lungimea celui mai lung drum a a a de la o clas rdcin pn la o clas derivat (indirect) din aceasta. a a a a a a a a Cu ct adncimea arborelui de derivare este mai mare, cu att efortul necesar a a a elegerii arhitecturii crete. O adncime mare a arborelui de derivare poate nt s a o indicatie a unei proiectri stngace. a a Derivarea face clasa copil dependent de clasa printe. Modicri clasa a a a n printe pot avea ca efect distrugerea functionalitii clasei copil. a at

80

CAPITOLUL 10. METRICI PENTRU PROGRAME

Numrul de clase derivate Msoar numrul de clase derivate direct dintra a a a o anumit clas. a a O valoare mare a acestui numr pentru o clas este o indicatie asupra a a importantei sale sporite sistem. n Este posibil ca anumite situatii s se exagereze cu numrul de clase n a a derivate create. De exemplu, multe situatii, locul claselor StudentAn1, n n StudentAn2, StudentAn3, StudentAn4 se poate crea o singur clas Student a a care s contin atributul an studiu. a a Metode bazate pe ponderi Se numr metodele unei clase i se estimeaz aa s a complexitatea ecreia dintre acestea. a Un numr mare de metode complexe indic diculti posibile a a at n ntretinerea clasei. De obicei, un numr mare de metode a ntr-o clas sugereaz o proiectare a a neinspirat, ce poate avea drept consecint un slab grad de reutilizare a codua a lui. Proiectantii nceptori adesea se seal considernd c simpla grupare a a n a a a functiilor dintr-un program procedural cteva clase are ca efect obtinearea n a unei arhitecturi orientate obiect. Cuplare Prin numr de cuplare al unei clase elegem numrul de clase cu a nt a care aceasta interactioneaz direct. a Existenta unor cuplaje inutile are un efect negativ asupra modularitii pro at dusului i adesea s mpiedic refolosirea codului. a

10.5

Probleme la folosirea metricilor

Lipsa de acuratete Rezistenta din partea angajatilor Folosirea lor alte scopuri dect cele n a pentru care au fost create Pot strni disensiuni cadrul echipei de dezvoltare a n Aceste probleme pot exacerbate de faptul c angajatii devin mai preocupati de a satisfacerea criteriilor impuse de o anumit metric dect de a colabora pentru a a a a dezvolta produsul la care lucreaz. a

Precum Atlas vehime sprijinea cerul pe umr n a Aa sprijin el lumea i vecia s a s ntr-un numr. a MIHAI EMINESCU, Scrisoarea I

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

81