Curs1

[Curs nr.1]

1.Principii de baza

Introducere

Tehnologia orientata pe obiecte si-a demonstrat valoarea intr-o multitudine de aplicatii din cele mai diverse domenii: electronica medicala, tranzactii de valori mobiliare, sisteme de gestiune a informatiilor din intreprinderi, controlul traficului aerian, productia de semiconductori, jocurile video interactive, retele de telecomunicatii, cercetari in astronomie etc.
La ora actuala exista deja o bogata experienta acumulata in cadrul proiectelor care au adoptat tehnologia orientata pe obiecte - atat proiecte reusite, cat si proiecte esuate. In ambele cazuri, experienta rezultata a constituit un ghid pretios pentru proiectele viitoare si a condus la o concluzie foarte importanta, anume ca modelul obiectual poate avea un impact benefic asupra dezvoltarii software, dar ca un proiect necesita mult mai mult decat simpla "venerare" a acestei tehnologii.

    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 influienta 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 on-line 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 influienteaza 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 o 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 s-a 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 intr-un 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:

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.

Crearea si apoi validarea unei arhitecturi care exploateaza sabloanele identificate in 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 OO

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. In capitolul urmator se va discuta notiunea de arhitectura OO solida.

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.