3.

Principii de baz proiecte software

Introducere Ce este un proiect ? Are de-a face cu realizarea unor schimbri ntr-o manier organizat. Definiii: (1) O form temporar de organizare creia i se aloc resurse pentru a realiza activitile menite s aduc o schimbare benefic. (2) Un demers cu caracter unic i tranzitoriu, constituit n vederea atingerii unui rezultat dorit. (3) Un proces unic, constnd dintr-un set de activiti coordonate i controlate, cu date de ncepere i finalizare, avnd scopul realizrii unui obiectiv conform anumitor cerine specifice, ncluznd constrngeri de timp, costuri i resurse. Pentru a putea reliza o schimbare dorit, un proiect trebuie s aib urmtoarele caracteristici: S fie un demers unic (fiecare proiect trebuie s fie altfel dect celelalte) S aib obiective specifice de ndeplinit S aib la dispoziie resurse S aib un buget S aib un calendar de activiti S beneficieze de efortul unor oameni S i se aplice criterii de calitate

Metafora cltoriei: deplasarea cotidian cu maiana de acas la serviciu este o rutin, dar o excursie fcut special pentru a vedea un anumit loc este un proiect. Justificare economic: Ce dorii s realizai De ce Cum avei de gnd s procedai Cn Cine va fi afectat Ce resurse sunt necesare

Succesul unui proiect i-a ndeplinit obiectivele de calitate, durat, cost a ndeplinit cerinele clientului, aa cum le percepe reuete rezultatul s-l conving pe client s revin s contracteze un nou proiect dup ncheierea proiectului, a rmaas organizaia capabil s-i continue cum tebuie activitatea

Din perspectiva proiectantilor de software lucrurile se vad cam in felul urmator: la ora actuala chiar si in spatele celor mai obisnuite activitati dintr-o societate industrializata (telefonie, tranzactii de actiuni, conducerea automobilelor, examinari medicale) se afla programe sofisticate; software-ul s-a infiltrat tot mai adanc in societatea umana, ceea ce creaza o cerere tot mai mare de specialisti. Pe de alta parte, nu se poate prevedea cu certitudine ca software-ul va avea o evolutie constant crescatoare, ca va deveni mereu mai complex. Exista 2 FORTE care actioneaza asupra acestui proces: Cresterea gradului de conectare intre sisteme de calcul performante distribuite. Acest factor a fost favorizat de aparitia liniilor de transmisie cu spectru larg de frecvente. Cresterea cerintelor utilizatorilor privind imbunatatirea accesului si a vizualizarii informatiilor. Acest factor este in mare masura o consecinta a dezvoltarii unei generatii de oameni constienti de potentialul urias al automatizarii. Sub influenta acestor 2 factori, in ziua de azi au ajuns sa ni se para firesti facilitati ca: achitarea direct din contul bancar personal a unui film prin cablu comandat, accesarea online de catre cercetatori a informatiilor din laboratoare aflate la distanta, vizualizarea de catre arhitecti a unor schite create de colaboratori aflati la distanta, jocurile interactive dotate cu imagini care aproape ca nu se deosebesc de realitate, posibilitatile de urmarire a vanzarilor de catre distribuitorii de produse, astfel incat sectorul de aprovizionare sa reactioneze prompt in functie de preferintele clientilor, respectiv sectorul de marketing sa poata formula noi oferte indreptate spre grupuri tot mai specializate de consumatori (de exemplu produse pentru diabetici). Punctele in care gasim fisuri in toate aceste sisteme dau nastere la intrebari de genul "De ce nu pot sa beneficiez de cutare serviciu ?", din partea clientilor, ele fiind o consecinta a faptului ca inca nu se stapaneste indeajuns complexitatea unui anumit domeniu. Chiar daca nu am tine cont de substantiala cantitate de resurse alocate pentru intretinerea sistemelor software, disponibilul actual de programatori ar fi repede inghitit de activitatile generate de influientele celor 2 factori amintiti mai sus. Daca la aceasta se mai adauga si activitatile neproductive necesare pentru a face fata "razboiului" microprocesoarelor, al sistemelor de operare, al limbajelor de programare si chiar al metodologiei, se constata ca prea putine resurse raman pentru partea de cercetare, de descoperire si creare a unor noi clase de aplicatii. Altfel spus, desi se presupune ca oamenii au creat calculatoarele pentru a-i ajuta sa-si rezolve problemele, de fapt jumatate din timp ele insele constituie probleme. (Parafrazand o definitie umoristica data nu stiu de cine sotului/sotiei ca fiind "persoana cu care imparti necazurile pe care nu le aveai inainte de casatorie", am putea spune despre calculator ca a fost creat pentru a rezolva problemele pe care nu le aveam inainte de aparitia lui). Pe de alta parte, insa, se poate evidentia si un aspect pozitiv: astazi software-ul este mult mai putin constrans de hardware. Fata de acum un deceniu, multe aplicatii ruleaza in conditii de spatiu de memorie in exces, de conexiuni ieftine, de factor MIPS (milioane de instr/sec) crescut. Acest fapt are 2 aspecte: - hardware-ul nu mai influenteaza in mod dramatic arhitectura software; - abundenta de resurse hardware incurajeaza cereri de software tot mai mari, care probabil nu vor ajunge niciodata sa fie satisfacute.

Cu

alte

cuvinte,

ne

confruntam

cu

realitate

simpla,

dar

fundamentala:

Posibilitatile noastre de a imagina aplicatii complexe vor depasi intotdeauna posibilitatile de a le dezvolta. Deocamdata ne aflam pe panta "pozitiva" a lucrurilor, in sensul ca cererile izvorate din imaginatia noastra constituie un factor ce determina imbunatatirea modului in care construim sistemele software.

Cauze ale esecului proiectelor software Majoritatea proiectelor software au la baza motivatii dintre cele mai serioase: acoperirea unor necesitati ale pietii, oferirea unor functionalitati solicitate de anumite grupuri de utilizatori sau experimentarea unor teorii noi. Pentru unii programarea formeaza o parte necesara si inevitabila a activitatii lor, desi nu una principala. De exemplu, o banca are ca obiect principal de activitate gestionarea banilor, dar software-ul reprezinta un mijloc important in acest scop. Pentru altii scrierea de programe este o pasiune, orice altceva fiind considerat ca preocupare prozaica. In oricare din aceste cazuri programarea este o activitate consumatoare de timp si energie intelectuala. S-a constatat ca cel mai adesea esecul unor proiecte software este cauzat de: 1. Abordarea necorespunzatoare a riscurilor. 2. Faptul ca produsul realizat nu este ceea ce s-a cerut. 3. Neajunsuri de natura tehnologica.

Abordarea necorespunzatoare a riscurilor Din nefericire, pe masura desfasurarii muncii unei echipe de programatori, multe din proiecte o "iau razna" din cauza lipsei unei supervizari mature, ca sa nu spunem lipsa oricarei supervizari (conform lui Booch: majoritatea proiectelor care esueaza, ajung astfel nu atat din cauza unui management slab, cat mai ales din cauza lipsei management-ului). De obicei, in aceste cazuri lucrurile evolueaza cam asa: se elaboreaza planuri si termene tot mai nerealiste care in cele din urma ajung o succesiune de minciuni. Fiecare problema este tratata drept "o simpla chestiune de programare" in loc sa fie abordata sistematic, din perspectiva arhitecturii sistemului sau a procesului de dezvoltare insusi. Colectivul de management, in loc sa ia decizii cu privire la problemele aparute, lasa echipa de proiectanti sa actioneze "de capul ei". Urmarea este ca acestia din urma, liberi de constrangeri, neavand un obiectiv comun clar, se lasa atrasi de ceea ce li se pare lor a fi ceva "cool" in materie de implementare. Documentele cerute de beneficiari sunt tratate ca maruntisuri sau anexe ce urmeaza a fi eventual completate dupa ce echipa finalizeaza infrastructura sistemului. In final se constata ca aproape nimic din ceea ce a cerut utilizatorul nu este concretizat.

Morala: managerii trebuie sa atace in mod activ riscurile unui proiect, altfel ele ii vor ataca pe ei.

Produsul realizat nu este ceea ce s-a cerut In alte situatii proiectele esueaza din cauza abordarii la intamplare a unor domenii de aplicatii nefamiliare. Echipa de proiectanti are doar o vaga idee asupra destinatiei finale a sistemului, fiind tentata sa se concentreze spre ceea ce, aparent, ar constitui aspecte tehnice importante (v. ilustratia). Nimeni nu este preocupat sa valideze ceea ce face impreuna cu utilizatorul si cu expertii in domeniu. Fiecaruia i se pare ca a inteles despre ce e vorba, iar la urma se constata cu surprindere ca beneficiarul respinge sistemul creat cu atata pasiune, dar in conditii de totala "eprubeta". Morala: pe durata procesului de dezvoltare trebuie implicati din plin beneficiarii sistemului. Prezenta lor constituie o atentionare constanta asupra a "de ce" si "pentru cine" se construieste sistemul.

Neajunsurile de natura tehnologica O alta categorie de proiecte esueaza din cauza tehnologiei utilizate la crearea sistemelor software. Instrumentele software "crapa" in cele mai nepotrivite momente, lipsind echipa de capacitatea de a controla complexitatea crescanda a proiectului. Pe de alta parte, adesea instrumentele folosite se dovedesc a functiona incorect, obligand proiectantii sa adopte solutii "contra naturii", pentru a sunta limitarile. Alteori, furnizorii de instrumente software livreaza altceva decat au promis initial, produse carora le lipsesc anumite functionalitati sau ale caror performante lasa mult de dorit. In cazurile cele mai rele furnizorul pur si simplu iese din afacere, lasand proiectantii total descoperiti. Necazurile de natura tehnologica apar mai ales cand pe piata de hardware/software se produc schimbari ce nu pot fi controlate de "cei mici": o anumita platforma hardware nu se mai produce, interfata si caracteristicile unui sistem de operare sunt modificate intr-un ritm prea rapid pentru ca proiectul sa tina pasul, beneficiarul isi modifica gusturile si pretentiile, de multe ori pentru ca a citit sau a auzit de undeva ca pe piata a aparut un produs grozav care pana la urma se dovedeste a fi fost doar "reclama goala". In fine, anumite instrumente/ limbaje/ metode alese de proiectanti promit avantaje reale, dar in practica se dovedeste ca extragerea acestor avantaje e mult mai dificila decat pare. In acest sens, probabil ca fraze ca cea de mai jos suna destul de familiar programatorilor: ". . . din cauza complexitatii programului 'cutare', pentru a beneficia din plin de toate facilitatile oferite, este necesar ca utilizatorul sa aloce un anumit timp ca sa invete cum sa foloseasca programul. In acest scop, pentru a veni in ajutorul utilizatorului, a fost prevazut un sistem extins de help online. Cum insa acest sistem este departe de a fi perfect, uneori informatiile necesare nu sunt evidente imediat, dar in cele mai multe cazuri informatia se afla sigur undeva in help. Cea mai dificila latura a procesului de invatare va fi de fapt sa gasiti unde . . . :). Intotdeauna este bine sa se prevada o marja suplimentara de timp pentru a studia informatiile continute de sistemul de help . . ." In situatiile in care un anumit proiect intampina obstacole de natura tehnologica, se ajunge la criza de timp daca nu se renunta la o parte a functionalitatilor promise. In ultima instanta, toate acestea sunt foarte suparatoare pentru un programator: ca profesionist, ultimul lucru la care te astepti este ca tehnologia din propria ta meserie sa se intoarca impotriva ta.

Exista insa si urmatorul aspect: de multe ori se arunca vina pe tehnologie, cand de fapt echipa de manageri ar fi trebuit sa anticipeze acest risc si sa-si ia masuri de prevedere. La urma urmei, nu traim intr-o lume perfecta! Morala: pe cat posibil, un proiect nu trebuie legat de o singura sursa de tehnologie, dar daca acest lucru este inevitabil, atunci arhitectura sistemului trebuie prevazuta cu elemente de protectie.

Stabilirea obiectivelor esentiale ale unui proiect Cu toate ca multe proiecte se soldeaza cu succes, pana si cel mai grozav dintre ele dureaza mai mult, implica mai mult efort intelectual si necesita un control mai intens decat sa planificat la initierea lui. Din pacate, asa cum arata Parnas, nu vom putea avea niciodata un proces de dezvoltare complet rational, deoarece: Utilizatorii unui sistem nu cunosc exact ceea ce doresc si nu sunt in stare sa formuleze intr-un limbaj articulat ceea ce cunosc. Chiar daca am putea stabili toate cerintele unui sistem, raman multe detalii care vor fi descoperite abia intr-un stadiu avansat al implementarii sistemului. Chiar daca am cunoaste de la inceput aceste detalii, exista niste limite fundamentale ale complexitatii pe care o fiinta umana o poate stapani. Chiar daca s-ar putea stapani intreaga complexitate a sistemului, exista forte externe, independente de proiect, care determina modificari ale cerintelor, unele dintre ele putand invalida decizii luate anterior. Sistemele construite de oameni sunt intotdeauna expuse erorilor umane. La inceperea fiecarui nou proiect, echipa de proiectanti aduce cu sine un bagaj intelectual de idei provenite din proiecte anterioare, precum si un bagaj economic format din instrumentele hardware/software de care dispune. Ambele vor influienta in mod inevitabil deciziile luate pentru noul sistem, independent de cerintele reale ale acestuia. In consecinta: "din toate aceste motive, imaginea unui proiectant software care isi elaboreaza un proiect in mod rational, fara erori, pornind de la un set de cerinte este total nerealista". Din fericire, insa este posibil sa ne apropiem de aceasta situatie ideala si de fapt, o asemenea tentativa de a "mima" un proces de dezvoltare rational este ceea ce caracterizeaza un proiect reusit. In afara de aceasta, un proiect reusit implica adoptarea unor decizii tehnice: strategice, cum ar fi: decizia de a utiliza o anume topologie client/server, un anume sistem de lucru cu ferestrele sau optiunea pentru baze de date

relationale; asemenea decizii definesc sabloane arhitecturale fundamentale si au implicatii profunde asupra sistemului de construit; tactice, cum ar fi: utilizarea unui anumit idiom pentru scrierea iteratiilor intrun program, decizii privind forma interfetei unei clase sau optarea pentru un anumit tip de baza de date relationala; aceste decizii au un caracter mai local. economice: se refera la masurile luate pentru a preveni cauzele principale ale esecului unui proiect, descrise in paragraful anterior. La initierea unui nou proiect trebuie identificate caracteristicile sale primare care vor fundamenta deciziile tehnice si economice ce urmeaza a fi luate. Stabilirea caracteristicilor unui proiect are in vedere urmatoarele criterii:

termenul de livrare completitudinea performanta calitatea toleranta la erori scalabilitatea extensibilitatea portabilitatea gradul de reutilizare arhitecturala costul dreptului de intretinerii

Este evident ca nu se va putea niciodata optimiza un sistem astfel incat acesta sa satisfaca toate criteriile enumerate. Astfel, daca termenul de livrare este principalul obiectiv al unui proiect, cum se intampla nu de putine ori, atunci e clar ca restul caracteristicilor vor avea mai mult sau mai putin de suferit. Daca trebuie sa primeze calitatea si toleranta la defecte, cum e cazul la sistemele critice (de ex. la controlul traficului aerian, instrumente medicale computerizate), atunci termenul de livrare devine o chestiune secundara. Nu inseamna ca un sistem nu poate sau nu trebuie sa-si propuna mai multe obiective, dar, important este ca echipa de management sa constientizeze compromisurile economice implicate de fiecare decizie tehnica.

Sarcina principala a echipei de management software este aceea de a echilibra un set incomplet, inconsistent si schimbator de cerinte tehnice si non-tehnice, in vederea producerii unui sistem optim din punct de vedere al unui set minimal de caracteristici. Acest set minimal de caracteristici trebuie sa constituie obiectivul principal al echipei de proiectanti.

Pentru ca un proiect sa reuseasca, echipa de proiectanti trebuie sa fie foarte drastica, in sensul ca fiecare decizie tehnica trebuie sa contribuie la satisfacerea setului minimal de caracteristici stabilit la inceput. Orice decizie care contravine acestor caracteristici trebuie inlaturata, respectiv orice decizie care este neutra ("nici nu adauga, nici nu scade") trebuie considerata drept un lux. Intreaga organizatie implicata in dezvoltarea unui sistem trebuie sa aiba o viziune comuna asupra problemei de rezolvat. Pe masura ce lucrul inainteaza, echipa trebuie sa-si puna mereu intrebarea: "ceea ce producem se incadreaza inca in setul de caracteristici stabilit ?".

Daca raspunsul e "da", atunci echipa e pe "calea cea buna". Daca raspunsul e "nu", atunci exista 3 posibilitati: Sa se anuleze deciziile cele mai recente care au dus la devierea proiectului de la obiectivele propuse. Relaxarea unor restrictii. Abandonarea proiectului. Orice tentativa de a proceda in alt mod inseamna de fapt ignorarea realitatii. Si din pacate realitatea are un mod foarte uracios de a demasca slabiciunile unui proiect, slabiciuni pe care proiectantii isi inchipuie ca le-au ingropat sub un munte de artificii tehnice. De obicei, trezirea la realitate ia forma unor mutre iritate sau agresiv-apatice ale utilizatorului final, care de cele mai multe ori are un model cat se poate de neechivoc al problemei sale.

Tipuri de proiecte Fiecare proiect software, OO sau non-OO, se caracterizeaza printr-o anumita politica sau stil de dezvoltare, care depinde de alegerea explicita sau implicita a setului minimal de caracteristici. Din acest punct de vedere putem distinge urmatoarele tipuri de proiecte: Orientate pe calendar Orientate pe cerinte Orientate pe documentatie Orientate pe calitate Orientate pe arhitectura

Proiecte orientate pe calendar Se caracterizeaza printr-o grija obsesiva privind planificarea termenelor de livrare. Cuvantul de ordine este "operativitatea". Toate deciziile se iau pe termen scurt, avandu-se in vedere exclusiv ceea ce urmeaza a fi scadent in viitorul imediat. Tot ce nu contribuie la respectarea termenelor stabilite este ignorat sau fusarit. Se urmareste doar ca produsul sa respecte un minimum-minimorum de functionalitate si performanta. Ca urmare, au de suferit calitatea, completitudinea, documentatia si integritatea conceptuala. Singurul argument care ar putea justifica o asemenea optica ar fi acela ca organizatia respectiva ar da faliment daca proiectul nu ar fi predat la timp. Proiectele orientate pe calendar in general nu incorporeaza un proces definit, ci doar o anumita cantitate de disciplina informala derivata din cultura locala in materie de programare, redata plastic prin asertiuni de genul: "Adevaratii programatori nu utilizeaza metode". Nu putine sunt organizatiile care functioneaza in aceasta atmosfera de haos continuu, mentinerea lor in viata fiind asigurata de munca eroica a catorva bravi programatori. O firma nou infiintata ar putea adopta strategia orientarii pe calendar pentru o scurta perioada de timp, deoarece acesta poate fi singurul mod de a patrunde pe piata. Daca firma este mica nu poate rezista mult timp in acest regim. O firma mare, care isi poate permite sa aloce forta de munca pe mai multe proiecte paralele, va putea aplica stilul orientat pe calendar mai mult timp; scotand rapid pe piata mai multe produse, asemenea firme vor obtine in felul acesta un avantaj psihologic asupra concurentei.

In orice caz insa, politica orientata exclusiv pe calendar nu constituie o solutie viabila pe termen lung. Deoarece produsele rezultate sunt rareori scalabile, extensibile, portabile sau reutilizabile, costul intretinerii lor atinge in timp valori intolerabile. Proiectele orientate pe calendar au si un cost social. Daca din cand in cand e interesant sa faci parte dintr-o echipa care lucreaza intr-un ritm alert, un asemenea stil de viata nu poate dura la nesfarsit. De obicei, organizatiile care lucreaza permanent sub presiunea termenelor nu au o morala profesionala sanatoasa. Cand un proiectant este capabil sa ia decizii bune si profunde, el nu va avea nici o satisfactie daca mereu va trebui sa sacrifice calitatea si sa opteze pentru solutiile expeditive.

Proiecte orientate pe cerinte Se caracterizeaza printr-o atentie exagerata acordata comportarii observabile din exterior a sistemului. Deciziile se iau in primul rand in conformitate cu necesitatile locale ale fiecarei cerinte. Calitatea si performanta sunt importante doar in masura in care exista cerinte explicite in acest sens. In ceea ce priveste respectarea termenelor de predare, o organizatie care aplica strategia orientata pe cerinte este dispusa mai degraba sa accepte intarzieri, decat sa renunte la anumite functii ale sistemului. Integritatea conceptuala a proiectului este afectata, deoarece nu exista interesul de a promova principii de genul portabilitate, reutilizare, extensibilitate, dincolo de ceea ce ar putea eventual implica unele dintre cerinte. Un asemenea stil de proiecte se justifica acolo unde lista cerintelor este bine definita, unde comportarea vizibila a sistemului este clara, iar probabilitatea sa apara modificari este mica. In aceste cazuri completitudinea este principalul obiectiv, iar sistemul rezultat este optim in raport cu un set static de cerinte. Proiectele orientate pe cerinte sunt conduse de regula dupa urmatorul proces: Enumerarea tuturor functiilor sistemului. Proiectarea componentelor corespunzatoare fiecarei functii. Implementarea fiecarei componente. Aceste activitati se numesc de obicei analiza, proiectare, respectiv implementare, adica traditionalele faze ale modelului in cascada. Intr-o oarecare masura stilul orientat pe cerinte este un vestigiu al tehnicilor de programare structurata extinse la nivel de analiza si proiectare. Acest stil a fost folosit cu succes in multe proiecte din perioada '70-'80. Totusi, are o deficienta: nu acopera problema modificarilor cerintelor. Figura de mai jos reda, intr-un mod putin simplificat, arhitectura canonica a unui sistem software dezvoltat in cadrul unui proces orientat pe cerinte:

O asemenea arhitectura, de tip "burlan" (stovepipe) este compusa de regula dintr-un substrat continand cateva elemente de suport (cum ar fi de exemplu baze de date sau programe utilitare) folosite in comun de toate firele de executie ale sistemului. Deasupra acestui substrat se afla un ansamblu de structuri paralele, corespunzatoare fiecarei functii majore a sistemului. Exista clase de aplicatii, cum ar fi cele orientate pe tranzactii, pentru care structura din figura de mai sus este foarte naturala, deoarece fiecare tranzactie poate fi exprimata ca o secventa independenta de actiuni. Aceasta structura incurajeaza de asemenea dezvoltarea in paralel a componentelor, intrucat acestea nu se afecteaza una pe alta. In practica, aplicatiile create dupa arhitectura "burlan" nu arata chiar asa clare ca in figura. Structurile verticale au lungimi si/sau grosimi diferite. Mai ales in cazul sistemelor mostenite (legacy systems), intre structurile verticale exista si interconexiuni, ceea ce duce la complicarea arhitecturii. Folosind acest model arhitectural, urmarirea cerintelor este usurata deoarece fiecare cerinta poate fi, cel putin teoretic, pusa in corespondenta cu cate o componenta (acesta este tot un mod de gandire inspirat din cultura programarii structurate) Ca dezavantaje, se pot aminti:

modelul nu incurajeaza arhitecturile simple, care exploateaza sabloane comune existente intre functiile sistemului; deoarece diferitele ramuri ale arhitecturii tind sa fie optimizate local, in raport cu cerintele individuale, aparitia unor noi cerinte va determina fie invalidarea unor ipoteze anterioare, si ca urmare modificarea mai multor ramuri, fie introducerea unor noi ramuri, ceea ce va duce la diluarea structurii si, deci, la scaderea gradului de reutilizare. In plus, o data cu trecerea timpului, pe masura ce sistemul este modificat, arhitectura tinde sa se "prabuseasca" sub propria greutate.

Regula: Daca se estimeaza ca mai mult de 90% din cerintele sistemului vor fi stabile de-a lungul vietii acestuia, atunci stilul orientat pe cerinte reprezinta o solutie rezonabila. Pentru un grad de stabilitate mai mic de 90% este necesar un alt model de dezvoltare, care sa asigure o valoare tolerabila a costurilor de intretinere.

Proiecte orientate pe documentatie Reprezinta o forma degenerata a stilului orientat pe cerinte, impins spre birocratie. Deciziile privind dezvoltarea se iau tinand cont de documentatia care trebuie livrata in pasul urmator. Adesea, pe masura ce se apropie termenul de predare a unui document, orice activitate de dezvoltare propriu-zisa inceteaza pana cand documentul respectiv este editat si pus in bratele utilizatorului care, oricum nu-l va citi. Dupa care, proiectantii se vor da peste cap sa recupereze timpul pierdut, pana la urmatoarea intrerupere. Proiectele demarate cu intentia de a aplica stilul orientat pe cerinte pot usor fi deviate spre stilul orientat pe documentatie. Aceasta se intampla de regula cand managementul, nesigur asupra metodei de a controla latura creativa a procesului de dezvoltare, impune in mod fortat realizarea unui maldar de ceea ce se considera a fi documente esentiale.

Daca in cadrul unui proiect angajatii lucreaza mai mult ca editori de documente decat ca programatori, sau daca costul actualizarii documentatiei este mai mare decat costul unei modificari in program, acestea sunt semne sigure ca proiectul a alunecat in "gaura neagra" a stilului orientat pe documentatie. Toate acestea nu inseamna ca orice documentatie este inutila, adica nu trebuie sa se treaca in extrema cealalta, redata plastic prin asertiuni de genul: "Adevaratii programatori nu scriu documentatie"! Anumite documente constituie instrumente esentiale pentru management si servesc drept marturii ale procesului de dezvoltare. Ceea ce trebuie evitat este documentatia gratuita, facuta de dragul documentarii. Practic, doar in cateva situatii este admis ca intr-un proiect cantitatea de hartie livrata sa depaseasca software-ul propriu-zis, si anume: la elaborarea unei biblioteci de clase de exemplu, este foarte important ca aceasta sa fie foarte minutios documentata, astfel incat utilizatorul sa poata intelege si utiliza clasele respective. Si in acest caz, insa, trebuie analizate costurile, deoarece se poate constata ca uneori este mai economic sa se angajeze un consultant tehnic care sa ofere asistenta utilizatorului, decat sa se elaboreze documentatie scrisa.

Proiecte orientate pe calitate Se caracterizeaza printr-o preocupare obsedanta in legatura cu anumite metrici cuantificabile. Aceste metrici se pot referi la: comportamentul extern, observabil al sistemului; de exemplu:
o o o

pentru un sistem de control al traficului aerian se poate impune ca durata de cadere sa fie mai mica decat 1 sec/decada; pentru o aplicatie bancara se poate necesita o capacitate de prelucrare de cateva sute de tranzactii/sec in perioadele de varf; pentru un sistem de gestionare de retele se poate cere ca perioada medie dintre 2 caderi sa fie de ordinul a catorva luni;

caracteristici interne ale sistemului, cum ar fi: complexitatea relativa a claselor, adancimea si largimea laticelor de clase; calitatea produsului: rata de detectare a defectelor, densitatea defectelor. In cadrul proiectelor orientate pe calitate, deciziile se iau cu precadere in sensul optimizarii metricilor selectate. Setul minimal de caracteristici care trebuie adoptat pentru aceste proiecte include de regula: completitudinea, chiar daca implica necesitatea relaxarii termenelor de predare, gradul destul de ridicat de detaliu al documentatiei (care de multe ori

poate include o parte matematica stufoasa) necesare pentru a demonstra ca sistemul satisface cerintele de calitate si corectitudine. Celelalte caracteristici (extensibilitate, portabilitate etc) sunt secundare ca importanta, ele oricum neputand fi masurate usor. Deseori, atingerea cerintelor de calitate impun ca anumite elemente ale sistemului sa fie puternic optimizate, rezultatul fiind un sistem destul de fragil (atingand o parte a sistemului risti sa strici componentele optimizate din alta parte). Stilul orientat pe calitate este esential pentru anumite clase de aplicatii: sisteme de control pentru centralele nucleare, sisteme de control pentru aparatele de zbor, sistemele de control pentru aparatura medicala, sistemele de comutare din centralele telefonice. Toate acestea reprezinta sisteme critice, care nu trebuie sa esueze in mod catastrofic. Regula: Daca esecul unui sistem software poate pune in pericol fie si viata unui singur om, pentru acel sistem trebuie aplicat stilul de dezvoltare orientat pe calitate. In general, proiectele orientate pe calitate prezinta o mare inertie, in sensul ca orice modificare este intampinata cu multe retineri. Aceasta, din cauza costurilor ridicate generate de verificare si validare. In cazuri extreme se aplica masuri ultra-conservatoare, cum ar fi verificarea compatibilitatii binare a noilor versiuni. Chiar si efectuarea unui upgrading la un compilator utilizat in dezvoltarea sistemului poate constitui o decizie morala majora. Mai ales acolo unde e vorba de vieti omenesti, se pot aplica verificari formale pentru a mari gradul de incredere in comportarea sistemului. Sistemele orientate pe calitate au o forma simpla de masurare a succesului: daca se ajunge ca o echipa de avocati sa evalueze pagubele provocate de esecul unui asemenea sistem, inseamna ca esecul este tragic. Daca in anumite domenii politica orientata pe calitate este absolut necesara, in altele ea reprezinta un lux pe care dezvoltatorii de software nu si-l pot permite. Aceasta nu inseamna ca proiectele respective trebuie sa ignore aspectele calitative, ci inseamna ca atingerea unui anumit nivel de calitate constituie intotdeauna o decizie economica. In cel mai bun caz, un proiect va trebui sa realizeze un echilibru intre satisfacerea cerintelor privind calitatea si costurile necesare acestui lucru. De multe ori, relaxarea usoara a unor restrictii de calitate (cum ar fi perioada medie intre caderi) poate avea un impact imens asupra reducerii costurilor dezvoltarii. De aceea, este important ca managementul sa analizeze oportunitatea oricarei cerinte privind calitatea, daca aceasta apare prea restrictiva. Pe de alta parte, de cele mai multe ori sacrificarea calitatii in favoarea scurtarii duratei de dezvoltare este o falsa economie. In consecinta, un manager intelept va lua in considerare intotdeauna si aspectul costurilor de intretinere in timp a produsului, inainte de a adopta astfel de compromisuri.

Proiecte orientate pe arhitectura Reprezinta la ora actuala cel mai matur stil de dezvoltare, caracterizat prin crearea unui cadru care satisface toate cerintele principale cunoscute, dar ramane dispus la adaptari in raport cu cerintele inca necunoscute sau neintelese. Stilul orientat pe arhitectura se situeaza, pe o scara evolutiva, deasupra stilului orientat pe cerinte. Intre cele 2 stiluri exista multe asemanari, exceptand faptul ca stilul orientat pe arhitectura, aplicat la proiectele orientate pe obiecte, incearca sa atenueze dezavantajele stilului orientat pe cerinte. Proiectele orientate pe arhitectura presupun de regula urmatorul proces: Specificarea comportamentului dorit al sistemului prin intermediul unei colectii de scenarii.

in

Crearea si apoi validarea unei arhitecturi care exploateaza sabloanele identificate scenarii.

Evolutia arhitecturii, prin efectuarea de corectii necesare pentru a o adapta unor noi cerinte, pe masura ce acestea sunt descoperite. Aceste activitati sunt numite: analiza, proiectare si evolutie sau fazele unui ciclu de viata OO. Se poate spune ca stilul orientat pe arhitectura reprezinta o combinatie a tehnologiei OO cu ingineria software traditionala. Asa cum se arata in figura de mai jos, stilul orientat pe arhitectura genereaza structuri similare celui orintat pe cerinte (ceea ce e un lucru bun), dar care au un substrat mai mare (ceea ce e si mai bine, deoarece aici flexibilitatea arhitecturii devine importanta). Deasupra infrastructurii se afla structurile paralele corespunzatoare fiecarei functii majore a sistemului, lucru care permite trasarea corespondentei intre cerinte si implementare.

Spre deosebire de stilul orientat pe cerinte, aceste structuri paralele sunt de mici dimensiuni, deoarece ele se bazeaza foarte mult pe facilitatile oferite de infrastructura care inglobeaza toate aspectele comune (toti factorii comuni) gasite in domeniul aplicatiei. In felul acesta, fiecare cerinta a sistemului este satisfacuta de catre o componenta mica, iar adaugarea sau modificarea unei functiuni se poate face cu efort minim. Cea mai importanta caracteristica a proiectelor orientate pe arhitectura este aceea ca elementele lor componente tind sa corespunda unor entitati sau concepte existente in lumea reala, aflate intr-o ierarhie care incepe de la implementare si se termina cu vocabularul domeniului problemei.

5 reguli de reusita a proiectelor software O definitie nu neaparat comerciala a unui proiect reusit spune ca:

Un proiect software se considera reusit daca:

satisface sau chiar depaseste asteptarile utilizatorului, a fost dezvoltat in limite de timp si de buget rezonabile, este flexibil la modificari si usor de adaptat.

(O definitie mai prozaica ar fi: un proiect de succes este acela care aduce multi bani!). Definitia de mai sus (cea cuprinsa in chenar) nu face referire la tehnologia aplicata in dezvoltarea proiectului. Cu alte cuvinte ea este valabila si in cazul proiectelor non-OO. Totusi, in literatura de specialitate se afirma ca, din punct de vedere statistic, numarul proiectelor OO reusite este mult mai mare decat al celor non-OO reusite. In cazul in care pentru un proiect se alege tehnologia obiectuala, problema care se pune este aceea a modului in care se va aplica aceasta tehnologie pentru a obtine maximum de beneficii, deoarece doar simplul fapt ca se hotaraste adoptarea metodologiei OO nu asigura automat succesul unui proiect. In primul rand, sa vedem CARE sunt beneficiile pe care le poate aduce orientarea pe obiecte: timpi de livrare mai mici o calitate mai buna o mare flexibilitate la schimbari un grad ridicat de reutilizare. In mare, aceste beneficii adreseaza in mod direct diverse aspecte din setul minimal de caracteristici adoptat pentru un proiect. In al doilea rand sa vedem DE CE orientarea pe obiecte aduce aceste beneficii: Modelul OO al unei probleme si al solutiei ei incurajeaza crearea unui vocabular comun intre utilizatorii sistemului si proiectantii lui, permitand astfel o interpretare comuna a problemei. Aplicarea metodei de integrare continua creaza posibilitatea identificarii din timp a riscurilor, astfel incat corectiile incrementale sa nu destabilizeze ceea ce deja s-a dezvoltat. O arhitectura OO permite o separare clara intre elementele independente ale sistemului, in felul acesta putandu-se ridica adevarate "ziduri de protectie" (firewalls) intre elementele respective, cu avantajul ca o modificare efectuata asupra unui element nu va afecta tot restul sistemului. Pe langa cele enumerate mai sus, intervin si caracteristici care tin de natura intrinseca a tehnologiei OO: simplitate, localizarea structurii si a comportamentului, expresivitatea relatiei de mostenire etc. Pentru a putea estima daca un anumit proiect este "pe calea cea buna" trebuie analizate cateva practici importante ale echipei respective, 5 dintre acestea fiind esentiale: 1. Concentrarea atenta asupra dezvoltarii sistemului pentru a defini clar o colectie minimala de caracteristici. Acest principiu este de fapt valabil si pentru proiecte non-OO, dar avantajul pe care il aduce metodologia OO in acest caz este faptul ca permite o reactie mai buna la schimbarile ce apar in intelegerea unei probleme, schimbari ce se vor manifesta si in setul minimal de caracteristici. Tehnicile OO dau posibilitatea de a efectua modificari fara a implica refacerea unei cantitati considerabile din proiect. 2. Existenta in cadrul organizatiei a unei mentalitati orientate spre rezultate, care incurajeaza comunicarea si care nu este obsedata de spectrul esecului. Tehnologia OO vine si in intampinarea acestui principiu. Ea impune o permanenta comunicare intre membrii echipei de proiectanti, dar si intre acestia si utilizatori, fapt care garanteaza o mai buna si mai

rapida intelegere a problemei, precum si o formare a unei viziuni comune asupra sistemului de dezvoltat. In ceea ce priveste teama de esec, aceasta genereaza de regula 2 fenomene nesanatoase: un accent exagerat asupra partii de analiza si respectiv o evitare a experimentarii. In realitate, in toate disciplinele ingineresti, si poate ca in productia de software mai mult, zicala ca "din greseli invata omul" isi gaseste o foarte buna aplicare. Examinand cauzele si imprejurarile unui esec, putem desprinde invataminte utile care vor duce pe viitor la evitarea erorilor respective. In cazul proiectelor OO trebuie ca proiectantii sa aiba permanent in minte ideea ca nu exista abstractiuni perfecte, iar in cazul in care se constata ca anumite clase nu sunt bune, acest lucru trebuie sa constituie un imbold spre imbunatatirea abstractiunilor respective si nu un motiv de descurajare. Pe de alta parte, nici extrema cealalta nu este de dorit, si anume lansarea intr-o munca de experimentare fara restrictii, de prototipizare grosiera, intr-o maniera "hacker"-ista cu scopul construirii de abstractiuni perfecte, condusi de principiul: "Dati-mi Smalltalk (sau alt limbaj), un laptop si un loc unde sa stau, si voi muta lumea". 3. Utilizarea eficienta a modelarii OO. Utilizarea eficienta a claselor si a obiectelor presupune mai mult decat simpla manipulare a mecanismelor sintactice ale unui limbaj de programare OO. Este foarte important de subliniat ca clasa este o unitate necesara, dar nu si suficienta de descompunere a unui sistem. Arhitectura unui sistem se exprima mai intai in termeni de grupuri de clase (package-uri sau cluster-e) si acestea, la randul lor, se formeaza din clase individuale. 4. Existenta unei viziuni arhitecturale puternice. Un sistem cu o arhitectura solida se caracterizeaza prin unitate si integritate conceptuala. Doar avand o imagine clara a arhitecturii, se pot descoperi abstractiunile si mecanismele comune mai multor parti ale sistemului si astfel se poate ajunge la simplificarea lui. 5. Aplicarea unui model iterativ si incremental bine condus, al ciclului de viata. Din experienta s-a constatat ca proiectele OO reusite nu au fost dezvoltate in cadrul unui proces anarhic, dar nici draconic de restrictiv. Maniera recomandata de desfasurare a procesului de dezvoltare este cea iterativa si incrementala. Un proces software iterativ presupune o detaliere succesiva a arhitecturii OO, astfel incat fiecare noua versiune a acesteia se bazeaza pe experienta si rezultatele obtinute din versiunea anterioara. Un proces incremental presupune ca fiecare trecere printr-un ciclu de forma analiza-proiectare-evolutie conduce spre o detaliere treptata a deciziilor strategice si tactice, obtinandu-se in ultima instanta solutionarea cerintelor reale ale utilizatorului (care de obicei nu sunt formulate explicit), sistemul ramanand insa simplu, fiabil si adaptabil. Un proces iterativ si incremental poate asigura o reconciliere a celor 2 factori opusi: creativitatea (care nu trebuie constransa) si disciplina, sau, altfel spus, arta si stiinta care intervin in ingineria software.

2. Produse i procese
In foarte multe privinte procesul de dezvoltare software se aseamana cu procesul de construire a unei case. Astfel, daca cineva doreste sa-si construiasca o casa, in primul rand va purta discutii cu arhitectul, discutii care vor ajuta la formarea unei viziuni comune asupra produsului care sa satisfaca nevoile familiei si sa se incadreze in limitele impuse de buget si de timp. Schitele de proiect sunt importante atat pentru beneficiar cat si pentru arhitect, deoarece constituie un mijloc de comunicare a intentiilor intr-un mod mai formal si mai precis. Uneltele de constructie performante si masuratorile sunt necesare pentru toti tamplarii, electricienii, instalatorii si zugravii pentru a materializa proiectul. Inspectiile periodice la fata locului, din partea beneficiarului ca si din partea unor experti in domeniul constructiilor, sunt esentiale pentru a verifica daca ceea ce se face este conform cu dorintele clientului si cu standardele in vigoare. In final, insa, ceea ce este mai important pentru client si familia sa este produsul finit - insasi casa. Orice alta activitate este secundara, dar constituie pasi inevitabili in procesul de elaborare a produsului final. Pe masura ce nevoile familiei se modifica (de ex. poate aparea necesitatea amenajarii unei parti din subsol ca birou sau dormitor), respectiv pe masura ce lucrurile se uzeaza (de ex. este necesara renovarea bucatariei sau repararea unui robinet fisurat in baie), urmatorul lucru important il constituie existenta unei marturii palpabile sau conceptuale care sa reflecte scheletul arhitectural al casei. Un asemenea document:

permite sa se stabileasca de ex. daca un anumit perete este de rezistenta sau poate fi daramat pentru a se extinde o camera, indica traseele tevilor de apa, pentru cazul in care se doreste practicarea unei derivatii in vederea instalarii unei chiuvete suplimentare descrie stilul de ansamblu al exteriorului casei, pentru a se putea sti daca un anumit element functional sau de decor care urmeaza a fi adaugat se va incadra in acest stil.

Tot acest proces descris mai sus este analog procesului de dezvoltare software. O organizatie care dezvolta un software de calitate niciodata nu pierde din vedere obiectivul primordial: dezvoltarea, furnizarea si intretinerea in mod eficient a unor produse care sa multumeasca utilizatorul si care sa satisfaca toate cerintele stabilite. Un program care face ceva util este cel mai important produs al oricarui proiect. Activitatile de analiza, proiectare, implementare, verificare a calitatii si documentare sunt importante numai in masura in care contribuie la atingerea acestui scop. Orice altceva (discutii, intalniri, programare, redactare, testare) este secundar. Al doilea ca importanta dupa programul insusi, este documentul care descrie arhitectura produsului. Acesta este esential pentru evolutia si intretinerea programului. Toate modificarile impuse fie de aparitia unor cerinte noi, fie de eliminarea unor erori, trebuie facute de asa maniera incat sa se armonizeze cu arhitectura originala. Altminteri, in timp, se va ajunge la un sistem "peticit", de calitate slaba, a carui structura originala devine din ce in ce mai obscura, pana cand nu mai poate fi modificata. Asemenea sisteme fragile sunt un adevarat balast pentru compania care trebuie sa se ocupe de ele in continuare, mentinerea lor "in viata" costand adesea mai mult decat o reproiectare de la zero. Pentru personalul tehnic din domeniul software, dezvoltarea de software la nivel industrial ar putea parea mult mai usor de abordat, daca totul s-ar rezuma la chestiuni de programare. Din nefericire foarte rar cerintele, chiar daca sunt complete, sunt si corecte, neambigue si fixe. Regulile afacerilor fluctueaza, tehnologia se schimba, programatorii vin si pleaca. Din

aceste motive, in special proiectele care urmaresc sa creeze produse durabile trebuie sa elaboreze un set de produse intermediare care faciliteaza scopul final - furnizarea unui sistem software de calitate. Ca urmare, orice organizatie care urmareste sa livreze si sa intretina programe in mod sistematic, trebuie sa adopte un model de proces suficient de bine definit, astfel incat, cu fiecare aplicatie complexa abordata, echipa sa poata imbunatati continuu procesul, facandu-l mai eficient si mai flexibil la schimbarile de cerinte. Dezvoltarea unor produse de calitate Ce este un produs software de calitate ? Din perspectiva unui programator, raspunsul este unul obiectiv: un program de calitate este acela care functioneaza si care realizeaza tot ce se asteapta de la el, nimic mai mult sau mai putin. Din perspectiva utilizatorului final si a echipei de dezvoltare in ansamblu, raspunsul este unul subiectiv: un program de calitate este unul elegant. Eleganta este un atribut care presupune simplitate, claritate, usurinta in intelegere. Software-ul de calitate rezolva probleme complexe prin intermediul unor mecanisme a caror bogatie semantica permite aplicarea lor in domenii complet diferite. Eleganta inseamna a gasi abstractizarea potrivita, inseamna utilizarea resurselor limitate in maniere mereu noi. Exemplu: O companie de transporturi intampina probleme cu gestionarea miilor de colete care circula prin reteaua sa. Ea a creat un sistem orientat pe obiecte pentru managementul operatiilor zilnice. Un model obiectual de abordare a problemei a parut a fi solutia potrivita. Pe baza acestei structuri a fost posibila adaugarea incrementala a noi module care au dus la eficientizarea procesului ca timp si cost. Folosind algoritmi genetici, ruland pe un supercalculator independent, consultantii software au putut sa supravegheze constant reteaua si sa ofere sfaturi personalului de deservire. A reiesit ca algorimii de baza puteau fi utilizati si pentru determinarea rutelor optimale de livrare a pachetelor catre clienti. Acest exemplu arata importanta unei arhitecturi orientate pe obiecte. Vom discuta arhitectura unei asemenea aplicatii, pornind de la clase si ajungand la generatoare de aplicatii (frameworks). Pentru un programator individual, care utilizeaza programarea orientata pe obiecte (OOP, Object Oriented Programming), unitatea primara de compunere a programului este clasa. Pentru programatorii care folosesc metode neobiectuale, unitatea primara a unui program este algoritmul. Pentru proiectele OO unitatea de baza in care ele se pot descompune este clasa, nu algoritmul. Trebuie insa precizat ca, asa cum s-a aratat in capitolul anterior clasa este necesara dar nu suficienta ca element de descompunere. O clasa de calitate are urmatoarele caracteristici:

Furnizeaza o abstractizare clara, bine delimitata a unui concept din vocabularul domeniului problemei sau al solutiei ei. O clasa denota un set de obiecte care impartasesc o structura si un comportament comun. Astfel, intr-un sistem OO se pot identifica multe clase care materializeaza limbajul specific domeniului abordat. De exemplu, intr-un sistem de plati, se vor gasi clase reprezentand clienti, furnizori, plati si produse. Intr-un sistem medical veti identifica clase reprezentand pacienti, prestatori si servicii. In amandoua cazurile prezentate, daca privim din perspectiva implementarii, se pot identifica clase care reprezinta elemente specifice limbajului

programatorilor: tranzactii, liste (de produse sau servicii) si tabele (de furnizori sau prestatori de servicii). Cu alte cuvinte: Orice clasa dintr-un sistem OO trebuie sa corespunda unei entitati tangibile sau unei abstractiuni conceptuale din domeniul utilizatorului final sau al implementatorului. Se recomanda inlaturarea tuturor claselor care nu satisfac aceasta cerinta. Prin "abstractizare clara", se intelege ca o clasa trebuie sa aiba frontiere bine definite in spatiul problemei. O clasa reprezentand toti furnizorii costisitori dintr-un sistem medical nu este o abstractizare buna, deoarece notiunea de "costisitor" este vaga si subiectiva. Un alt element legat de delimitarea unei abstractizari se refera la structura si comportamentul incapsulate intr-o clasa. De exemplu, o clasa reprezentand clientii dintr-un sistem de evidenta a platilor va contine atribute ca: numele, adresa si telefonul clientului. A atasa insa ca atribut al clientului o lista a angajatilor ar fi o eroare, deoarece lista respectiva nu face parte din vocabularul sistemului de plati. Similar, comportamentul asociat cu clasa ce reprezinta clientii poate include posibilitatea de a consulta istoricul platilor sau esalonarea creditului unui anumit client. In schimb, ar fi deplasat sa se dea posibilitatea de a consulta numele copiilor unui client, deoarece acest lucru este total irelevant in contextul sistemului abordat.

Incorporeaza un set minimal si bine definit de responsabilitati, pe care le indeplineste foarte bine. O responsabilitate denota obligatia unui obiect de a manifesta un anumit comportament. Deoarece orice obiect este instanta unei anumite clase, rezulta ca o clasa trebuie sa inglobeze responsabilitatile tuturor instantelor sale. Distribuirea responsabilitatilor intr-un sistem OO reprezinta o decizie critica. Nu trebuie nici sa avem putine clase care "au prea multe de facut", dar nici sa avem multe clase care "au prea putine de facut". Ca regula generala: O clasa obisnuita trebuie sa inglobeze cam 3-5 responsabilitati. Desigur ca de la regula generala vor exista unele exceptii. De exemplu o clasa care modeleaza o fereastra dintr-o interfata grafica este o abstractiune fundamentala si ea va contine foarte multe responsabilitati. In schimb, o clasa care modeleaza o valva sau un aparat de masura dintr-un sistem de automatizari industriale poate include doar 1-2 responsabilitati. Important este ca, la aplicarea regulii de mai sus sa se aiba in vedere caracteristici ca: usurinta in intelegere si flexibilitate. Trebuie subliniat faptul ca responsabilitatea unei clase nu se confunda cu operatiile sale. O responsabilitate este dusa la indeplinire printr-un set de operatii care coopereaza intre ele Realizeaza o separare clara a interfetei (comportamentului) abstractiunii, in raport cu implementarea. Este usor de inteles si simpla dar totodata extensibila si adaptabila. Daca distribuirea responsabilitatilor in cadrul sistemului s-a facut bine, atunci clasele rezultate vor fi clare si simple. Dezvoltarea claselor in conditii de izolare este dificila. A crea un sistem OO de calitate inseamna mai mult decat a crea niste clase individuale de calitate. Intr-un sistem complex nici o clasa nu exista in izolare, dimpotriva: clasele colaboreaza unele cu altele pentru a se obtine functionarea sistemului. De aceea, din perspectiva unui arhitect software, a construi sisteme de calitate implica luarea in considerare a unor structuri software care transcend

clasele individuale si anume, ca urmare a unei distribuiri judicioase a responsabilitatilor se va urmari obtinerea unor colaborari calitative intre clase. Exemplu: Sistemul MacApp este poate cel mai elocvent exemplu de generator de aplicatii de calitate. Prima versiune disponibila a aparut la inceputul lui 85 si folosea limbajul Object Pascal. MacApp a reprezentat unul dintre primele generatoare de aplicatii disponibile comercial. Domeniul sau era general, intentia fiind de a permite crearea de aplicatii conforme cu standardul Macintosh in ceea ce priveste interfata utilizator. Dupa cum era de asteptat, primele versiuni ale bibliotecii generatorului nu au fost prea grozave, in principal din cauza ca biblioteca, in ansamblul ei, se prezenta ca o mare de clase, ale caror interrelatii trebuiau descoperite de catre cei ce aveau indrazneala sa se avante pe acest teritoriu neexplorat. Mai mult, responsabilitatile nu erau clar distribuite intre clase, adaptarea unor clase individuale fiind astfel mult ingreunata. Dupa considerabile experimentari si utilizari reale, biblioteca a fost radical modificata (clase, ierarhii, distributia responsabilitatilor), pe la sfarsitul anilor 80. In jurul anului 1990 biblioteca a fost in intregime rescrisa in C++, operandu-se si alte modificari in structura claselor. O versiune relativ stabila a fost gata in 1992. De aceasta data biblioteca a fost mult mai abordabila, inteligibila si adaptabila. Important a fost ca avea o arhitectura explicita, nu mai era doar o mare de clase, iar colaborarile intre clase erau bine documentate. O colaborare de clase bine conceputa se caracterizeaza prin: Este rezultatul contributiei unui set restrans de clase care conlucreaza in vederea obtinerii unui anumit comportament. Genereaza un comportament care nu reprezinta responsabilitatea unei singure abstractiuni, ci care deriva din ansamblul de responsabilitati distribuite pe setul de clase. Crearea colaborarilor importante dintr-un sistem este activitatea centrala a arhitectilor software pe durata fazei de proiectare. Aceste colaborari reprezinta "sufletul" unei arhitecturi, deoarece ele sunt deciziile strategice care realizeaza conturul de baza al sistemului. Distribuirea responsabilitatilor intr-un sistem OO trebuie sa se faca pe 2 directii:

verticala: de-a lungul ierarhiilor de clase care sunt legate prin relatii de generalizare/specializare; orizontala: intre perechi de clase care colaboreaza una cu alta.

Aceste 2 dimensiuni - ierarhiile de clase si colaborarile la nivel de perechi de clase reprezinta elementele de baza ale oricarei arhitecturi OO bine structurate. Ca atare, reluand ideea initiala a acestui paragraf, putem spune ca: un produs software de calitate presupune o calitate locala, data de clasele individuale si o calitate globala, data de arhitectura.

Arhitecturi OO O arhitectura OO bine structurata consta din: Un set de clase organizate de regula in ierarhii multiple.

Un set de colaborari care specifica modul in care clasele coopereaza intre ele pentru a genera diversele functiuni ale sistemului.

Prima dimensiune a unei arhitecturi OO (setul de clase) realizeaza captarea MODELULUI STATIC al abstractiunilor care formeaza vocabularul domeniului problemei. Spunem vocabular, deoarece fiecare abstractiune reprezinta ceva din limbajul unui utilizator sau al unui implementator. De exemplu, intr-un sistem de procesare a cartilor de credit vom gasi ierarhii aproape independente corespunzatoare unor notiuni cum ar fi: conturi, institutii si vanzari. Fiecare dintre acestea sunt cate o ierarhie, nu doar cate o singura clasa. De exemplu, daca ne referim la conturi, exista conturi individuale, conturi colective, conturi cu dobanda sau fara etc. Pentru toate acestea sunt necesare clase distincte care insa pot fi relationate intr-o ierarhie de tipul generalizare/specializare. Ca regula generala, intr-un sistem trebuie prevazuta cate o ierarhie pentru fiecare abstractiune fundamentala a modelului. Folosind ierarhii distincte pentru reprezentarea abstractiunilor cu semantica foarte diferita, se asigura o mai buna distributie a resonsabilitatilor in sistem. Fiecare ierarhie independenta, impreuna cu clasele primitive care asigura suport pentru clasele abstracte, reprezinta o grupare naturala a abstractiunilor ce compun un sistem. Vom numi o asemenea grupare categorie de clase, deoarece ea denota un element arhitectural mai cuprinzator decat o clasa sau chiar decat o ierarhie. Daca ar fi sa facem o corespondenta cu structurile dintr-un limbaj de programare OO, intuitiv, categoria de clase corespunde cu spatiul de nume (namespace) din C++ sau cu pachetul (package) din Java. Intr-un proiect OO cea mai mare unitate de descompunere o reprezinta categoria de clase. In interiorul unei categorii se gasesc clase inrudite din punct de vedere semantic. Ca regula generala, daca intr-un sistem se gasesc mai mult decat 50 de clase, e cazul sa se realizeze o descompunere a sistemului in categorii de clase. O categorie tipica este formata cam dintr-o duzina de clase. A doua dimensiune a unei arhitecturi OO (setul de colaborari) realizeaza captarea MODELULUI DINAMIC al sistemului. Fiecare colaborare reprezinta un anumit comportament generat de un set de obiecte distincte dar care coopereaza intre ele, de multe ori aceste cooperari traversand granitele categoriilor de clase. Atunci cand se abordeaza dinamica unui sistem trebuie evidentiat modul in care anumite grupuri de obiecte colaboreaza, astfel incat aspectele comune ale comportamentului sa fie tratate cu ajutorul unor mecanisme comune. Majoritatea sistemelor OO necesita mai putin de 10-20 de mecanisme centrale. Un mecanism central are adanci implicatii arhitecturale si reprezinta o decizie strategica. Cele mai multe dintre sistemele OO trebuie sa includa mecanisme centrale care rezolva urmatoarele aspecte: Persistenta obiectelor (adica pastrarea valorilor lor pentru perioade nedefinite de timp; cel mai adesea mecanismele de asigurare a persistentei presupun existenta unor baze de date OO sau relationale). Gestionarea memoriei. Gestionarea proceselor. Transmiterea/receptionarea mesajelor. Distribuirea si migrarea obiectelor. Conectarea in retea. Tranzactiile. Tratarea evenimentelor.

Tratarea exceptiilor. Interfata utilizator. Aceasta lista nu este exhaustiva, dar reprezinta cele mai des intalnite mecanisme dintr-un sistem. Pentru fiecare din aspectele enumerate exista mai multe solutii, iar sarcina echipei de proiectanti este de a alege una dintre ele, tinand cont si de cerinte precum: performanta, capacitate, fiabilitate, securitate etc. Fiecare asemenea decizie strategica implica, la un nivel de detaliu mai mare, o suma de decizii tactice. Se poate spune ca structura logica si fizica a arhitecturii unui sistem OO este creata prin aplicarea tuturor deciziilor strategice si tactice adoptate de-a lungul procesului de dezvoltare. Un aspect foarte important aici il constituie detectarea aspectelor comune (sabloane) ale comportamentului care permite obtinerea unei arhitecturi mai simple. Toate sistemele OO bine structurate sunt pline de sabloane, incepand cu cadre (frameworks) si mecanisme, la nivel global (strategic), si terminand cu idiomuri, la nivel local (tactic). Un sablon reprezinta o solutie comuna a unei probleme intr-un anumit context.

Un idiom este legat de un anumit limbaj de programare si reprezinta o conventie general acceptata de utilizare a limbajului respectiv. Se poate spune ca un idiom este o forma de reutilizare pe scara mica. Un mecanism este o structura in cadrul careia obiectele colaboreaza in vederea obtinerii unui anumit comportament care satisface o anumita cerinta a problemei. Mecanismele reprezinta decizii de proiectare privind modul in care coopereaza colectiile de obiecte. Ele se mai numesc sabloane de proiectare (design patterns). Un cadru reprezinta o colectie de clase care ofera un set de servicii pentru un domeniu particular. Cadrul exporta un numar de clase si mecanisme pe care utilizatorii le pot adapta. Cadrele sunt forme de reutilizare pe scara larga. Se mai numesc generatoare de aplicatii.

Considerand arhitectura unui sistem OO din perspectiva sabloanelor pe care le inglobeaza, putem spune ca infrastructura unei arhitecturi OO canonice include de regula urmatoarele straturi, fiecare strat fiind reprezentat printr-un anumit cadru :

a. Functii de baza ale sistemului de operare. b. Comunicare in retea. Aceste 2 nivele practic izoleaza aplicatia de detaliile hardware.

c. Stocarea obiectelor persistente. d. Gestionarea obiectelor distribuite. Aceste 2 nivele reprezinta resursele care realizeaza stocarea si distribuirea obiectelor, dand aplicatiei "iluzia" ca obiectele traiesc permanent intr-un spatiu virtual de adrese.

e. Nivelul (cadrul) independent de aplicatie. f. Medii de aplicatii. g. Interfata grafica utilizator (GUI). Aceste 3 nivele acopera abstractiunile independente de aplicatie (de exemplu clasele de utilizare generala, cum ar fi colectiile), obiecte de aplicatie (care furnizeaza diverse servicii ca: tiparire, gestionarea clipboard-ului etc) si facilitati de tip GUI care furnizeaza abstractiunile primitive necesare construirii de interfete utilizator.

h. Modelul domeniului. i. Cadrul dependent de domeniu.

Aceste din urma nivele contin abstractiunile ce apartin domeniului problemei de rezolvat (modelul domeniului) si colaborarile intre aceste abstractiuni (sabloanele care formeaza cadrul dependent de domeniu). Pe scurt, o arhitectura bine structurata

este construita pe nivele de abstractizare, realizeaza o separare clara a sarcinilor fiecarui nivel si este simpla. Simplitatea provine din reutilizarea sabloanelor pe diverse nivele.

Produsele unui proiect software Reluand exemplul cu casa, prezentat la inceputul acestui capitol, putem spune ca, pe langa casa propriu-zisa, pe durata constructiei ei rezulta si alte produse care, fie sunt derivate din procesul de construire, fie sunt ajutatoare acestui proces. De exemplu, constructorul si proprietarul semneaza un constract in care se specifica ce anume se va construi. Pentru unele constructii se elaboreaza si un model la scara redusa. Se elaboreaza, de asemenea, desene care vor reda aspectul general al casei, precum si schite de detaliu necesare executiei instalatiilor electrice si de canalizare. Constructorii vor avea nevoie la un moment dat de niste schele, pe care le vor demonta la terminarea lucrului. Se pot folosi fotografii ale unor case existente sau desene care sa serveasca drept model pentru anumite detalii de constructie sau decorare. La sfarsit, din toate acestea, proprietarul va ramane probabil cu casa, un rand de chei, cateva schite generale si cu instructiunile de intretinere si garantie. Si procesul de dezvoltare software este similar. La dezvoltarea unui proiect, o echipa bine organizata va elabora doar cantitatea necesara de produse, pe langa aplicatia propriu-zisa. Lista produselor reutilizabile a oricarui sistem software include:

Arhitectura. Proiectul. Codul. Cerintele. Datele. Interfetele utilizator. Estimari si masuratori. Planurile de proiect. Testele. Documentatia.

Aceste produse sunt reutilizabile deoarece ele pot fi folosite si dupa ce se incheie procesul de dezvoltare in cadrul caruia au fost create, servind la dezvoltarea in continuare si a altor proiecte. Produsele din lista de mai sus pot fi clasificate in functie de principalele categorii de persoane care le folosesc:

echipa de dezvoltare utilizatorii finali echipa de manageri

In functie de gradul de formalizare aplicat in procesul de dezvoltare, produsele se pot manifesta in forme tangibile sau intangibile (dar nu paranormale :)). Pentru echipa de dezvoltare produsele relevante sunt:

arhitectura deciziile tactice de proiectare codul

Arhitectura este produsul cel mai important pentru echipa de dezvoltare, pentru ca ea defineste forma sistemului si se pastreaza mai mult timp dupa ce aplicatia a fost livrata. In forma intangibila, arhitectura se regaseste in insasi structura aplicatiei, precum si in mintea arhitectilor. In forma tangibila, arhitectura poate lua forma unui prototip sau a unui document care descrie ierarhiile principale si mecanismele de baza folosite. Deciziile de proiectare la nivel tactic se refera la proiectarea claselor, a categoriilor de clase si a interfetelor subsistemelor principale. In forma intangibila aceste decizii se manifesta ca un set de idiomuri si mecanisme aplicate in dezvoltare. In forma tangibila, ele se regasesc in documentatii gen ghiduri (indrumatoare). Codul este cel mai tangibil produs al echipei de dezvoltare. El cuprinde implementarea claselor si documentatia referitoare la semantica fiecarui membru important al claselor. Pentru utilizatorul final, in afara de aplicatia executabila propriu-zisa, produsele relevante sunt:

cerintele datele interfata utilizator

Cerintele sunt importante din urmatoarele motive:

forteaza dezvoltatorii si utilizatorii sa comunice in legatura cu asteptarile acestora din urma; constituie, impreuna cu evaluarea riscurilor, o baza pentru planificarea proiectului; formeaza baza pentru majoritatea activitatilor de testare.

In forma intangibila cerintele exista in mintea utilizatorului final. In forma tangibila, ele sunt cuprinse intr-un document aflat intr-o continua actualizare. Experienta arata ca un asemenea document ar trebui sa fie unul bazat pe scenarii, insotite eventual de prototipuri care sa ofere modele operationale ale comportamentului dorit al sistemului. Datele se refera la totalitatea informatiilor brute care sunt prelucrate de aplicatie. In cazul in care datele nu apar descrise explicit intr-un document, pe masura ce sistemul dezvoltat creste in dimensiuni, se ajunge adesea la situatii de fragmentare a datelor si de inmultire a redundantelor. Interfetele utilizator, ca produse reutilizabile, reprezinta aspectul general (look & feel) al unei familii de programe. Desi platformele grafice bazate pe ferestre existente la ora actuala propun un "look & feel" propriu, ele lasa totusi programatorilor un grad considerabil de libertate in alegerea stilului interfetei, mai ales la utilizarea elementelor de control din ferestre. In forma intangibila, o interfata exista ca stil aplicat in realizarea ferestrelor si controalelor ce intervin intr-o aplicatie aflata in executie. Forma tangibila presupune de regula un document cu rol de ghid de stil. Un asemenea ghid poate oferi o baza pentru stabilirea consensului intre dezvoltatori si utilizatori. In plus, el ar putea fi folosit si in proiecte viitoare. In felul acesta se pot economisi costurile de instruire necesare atunci cand aplicatiile livrate nu prezinta o consistenta a interfetelor. Pentru echipa de management produsele importante sunt:

estimari si masuratori planurile de proiect testele documentatia

Estimarile provin din experienta unor proiecte anterioare, adaptata la specificul noului proiect si la cultura organizatiei ce realizeaza proiectul. Aceasta deoarece s-a observat ca cel mai mare impact asupra productivitatii unei organizatii il are capacitatea echipei de dezvoltare ca intreg. Intrucat tehnologia obiectuala este relativ noua, inca nu exista o experienta bogata care sa permita aplicarea unor metode traditionale de estimare (de exemplu COCOMO) la proiecte OO. Ca urmare, multe dintre aceste proiecte trebuie sa se bazeze pe estimari informale, calibrate pe cateva proiecte pilot. Planificarea proiectului cuprinde infrastructura necesara pentru stabilirea termenelor si alocarea resurselor umane. In cazul proiectelor care se desfasoara intr-un mod haotic, termenele sunt stabilite ad-hoc, iar alocarea resurselor reprezinta putin mai mult decat angajarea in proiect a persoanelor care in momentul respectiv nu sunt prea incarcate.