Curs 7

[Curs nr.7]

Implementarea claselor si a obiectelor

Scop: reprezentarea fiecarei abstractiuni si colaborari in modul cel mai eficient si elegant.
In aceasta faza predomina activitatile de implementare, fara insa ca ele sa fie lipsite de o anume creativitate .
A selecta o cale de reprezentare eficienta si eleganta este un act de creatie care nu poate fi usor automatizat.
Implementarea este mai estompata pe durata analizei, cand serveste mai mult studierii riscurilor si descoperirii de noi clase si obiecte. Pe durata proiectarii implementarea presupune crearea unor produse executabile ce materializeaza arhitectura. Implementarea atinge varful pe durata fazei de evolutie, cand are loc detalierea succesiva a arhitecturii.
Locul pe care aceasta faza il ocupa in cadrul secventei de faze ce alcatuiesc microprocesul este justificat de faptul ca microprocesul se axeaza mai intai asupra comportamentului, amanand cat se poate deciziile legate de reprezentare. Aceasta strategie permite:

evitarea luarii unor decizii premature in ceea ce priveste implementarea, decizii care pot afecta oportunitatile de obtinere a unei arhitecturi mai simple;

libertatea de a schimba reprezentarea din ratiuni de eficienta, fara a provoca rupturi ale arhitecturii.

Produse: in aceasta faza se obtine sofware-ul care codifica reprezentarea claselor si a colaborarilor.
Activitati: selectarea structurilor si a algoritmilor care indeplinesc rolurile si responsabilitatile identificate in fazele anterioare ale microprocesului. Daca primele 3 faze ale microprocesului vizeaza perspectiva exteriorului abstractiunilor, la implementare accentul este pus pe interiorul acestora.
Activitatea se desfasoara dupa urmatorii pasi:
pt. fiecare clasa si colaborare se analizeaza protocolul; se cauta similitudini de utilizare de catre clienti, pentru a determina care sunt operatiile mai importante, cu scopul de a le optimiza;
inainte de a trece la codificarea de la zero a unei reprezentari, se studiaza posibiliattile de adaptare a unor clase existente, prin derivare sau instantiere; daca o anumita problema e mai generala, se vor alege clase abstracte sau template-uri;
se cauta obiectele carora li se pot delega responsabilitatile;
daca semantica unei abstractiuni nu poate fi obtinuta prin mostenire, instantiere sau delegare, se stabileste un set de operatii primitive, tinand cont de necesitatile clientilor abstractiunii respective;
se alege algoritmul potrivit pt. fiecare operatie; se pot crea operatii ajutatoare pentru a divide algoritmul in parti mai simple si eventual reutilizabile; se studiaza compromisurile care trebuie adoptate in ceea ce priveste stocarea informatiilor de stare vs. calcularea lor;
In general, daca s-a realizat o distributie echilibrata a responsabilitatilor in cadrul sistemului, atunci implementarea majoritatii claselor este relativ simpla.
Ca principiu: cele mai multe dintre operatiile individuale ale unei clase pot fi implementate pe cca o duzina de linii de cod. Nu e neobisnuit ca unele operatii sa necesite doar 1-2 linii de cod. Daca insa apar operatii care necesita ~100 de linii, e semn ca ceva nu e in regula.
Agenti: in aceasta faza sunt necesare alte abilitati decat in primele 3 faze ale microprocesului, si anume: implementarea poate fi realizata de ingineri de aplicatii care nu trebuie neaparat sa stie cum sa creeze clase noi, dar care trebuie macar sa stie cum sa reutilizeze si sa adapteze clasele existente.

Jaloane si masuratori: in faza de analiza implementarea se considera incheiata dupa ce au fost identificate toate abstractiunile importante necesare indeplinirii responsabilitatilor abstractiunilor de nivel inalt (din domeniul problemei).
In faza de proiectare implementarea se considera incheiata cand exista modele executabile sau aproape executabile ale abstractiunilor mentionate mai sus.
Cea mai importanta masura a calitatii in cazul implementarii este simplitatea.

5. Echipa de dezvoltare

Introducere

Oamenii sunt mai importanti decat orice proces. Acest lucru este valabil mai ales in cazul echipelor mici, unde aptitudinile individuale contribuie la succesul unui proiect mai mult decat oricare alt factor.
In cazul echipelor mari insa, ca efect al legii numerelor mari, numarul specialistilor de nivel mediu este mai mare decat cel al specialistilor exceptionali. De aceea, aici se impune existenta unui proces rational de dezvoltare, care va permite o mai buna punere in valoare a talentelor celor de nivel mediu.
Intotdeauna, pentru ca un proiect sa se termine cu succes, sunt necesare: un proces bine definit si o echipa coeziva.
In acest capitol se va studia modul in care managerul trebuie sa-si organizeze echipa astfel incat ea sa devina unita si sa dobandeasca aptitutini superioare sumei talentelor individuale ale membrilor ei.
Pentru ca un proiect sa fie finalizat cu succes, nu este suficient sa fie angajati cativa oameni supradotati. O asemenea practica corespunde culturii programatorului de tip "cowboy" care este foarte mandru de contributia sa personala si care vede orice problema ca o simpla chestiune de programare.
De fapt exista 3 probleme legate de maniera de organizare a unei echipe in jurul catorva oameni foarte talentati:

Specialistii supradotati sunt foarte putini. Conform statisticilor, programatorii hiperproductivi constituie mai putin de 1-2% din intregul numar de programatori (un hiperproductiv este in medie de 4-10 ori mai productiv decat un programator obisnuit).
Practic, in cazul multor proiecte, organizatiile respective nu-si pot permite sa angajeze numai "genii".

E o mare diferenta intre a crea un program simplu, exceptional, care sa demonstreze un concept genial si a introduce programul respectiv intr-un proces de productie in vederea acoperirii nevoilor unor utilizatori industriali.
Asa cum s-a vazut in capitolele anterioare, a produce software de calitate presupune un proces ingineresc care necesita nu doar talent de programator si care se compune dintr-o multitudine de activitati adesea plicticoase sau anevoioase pentru a cladi o arhitectura viabila a sistemului.
Un programator de geniu de multe ori considera asemenea activitati oribile in comparatie cu munca de creare a unui program spectaculos.

Unele probleme sunt atat de complexe, incat nu pot fi acoperite de o echipa mica, oricat de dotati ar fi membrii ei.
De regula, un proiect de dimensiuni mici (cu ciclu de viata de cateva luni) necesita 1-5 oameni; un proiect cu ciclu de viata > 1 an necesita cca 10-20 oameni; proiectele complexe, de importanta geopolitica pot antrena de la 50 pana la cateva sute de oameni.
Pe de alta parte, majoritatea proiectelor sunt constranse de termene de predare fixe, bugete inflexibile si de o infrastructura mai mult sau mai putin pusa la punct. De aceea, dimensiunile echipei sunt de multe ori dictate mai degraba de factorii enumerati mai inainte decat de complexitatea problemei de rezolvat.

In general s-a constatat ca probabilitatea de esec pentru un proiect e mai mare daca echipa e mare. Vestea buna insa e aceea ca proiectele orientate pe obiecte tind sa necesite echipe mai mici decat cele non-obiectuale.

Ca o concluzie: indivizii sunt importanti, dar la nivel de productie industriala de software echipele sunt si mai importante. Pe de alta parte, procesul e important in asamblarea unei echipe, deoarece este repetabil, permite abordarea problemelor de scalabilitate si constituie suport pentru practici economice sanatoase.

Manageri si programatori

Primul lucru pe care participantii la dezvoltarea unui proiect trebuie sa-l aiba in vedere este acela ca:

dezvoltarea de software este o activitate profund umana.

Un proiect orientat pe obiecte necesita:

un anumit set de abilitati,
o alocare de resurse,
un profil al angajatilor

usor diferite in comparatie cu un proiect non-obiectual. Aceste aspecte reprezinta subiectul unor decizii tactice menite sa asigure coeziunea echipei.

Premizele constituirii unei echipe coezive sunt:

Participantii la un proiect nu sunt entitati interschimbabile. Dezvoltarea unui sistem complex necesita o echipa formata prin imbinarea calitatilor unice ale membrilor ei.
Rolul fiecarui membru trebuie apreciat la adevarata valoare. un programator nu este mai prejos decat un arhitect. Proiectantul nu este o forma de viata inferioara managerului de proiect (dar nici invers :-)).
Indivizii care compun o echipa trebuie sa-si recunoasca deschis calitatile si slabiciunile profesionale, sa nu incerce ca din orgoliu sa ocupe pozitii dincolo de competentele lor.

Roluri si responsabilitati

Desi numarul specialistilor de geniu din lume este mic, este posibil (si adesea de dorit) sa se alcatuiasca o echipa foarte productiva utilizand specialisti de nivel mediu.
Pentru aceasta trebuie sa se tina cont ca fiecare om are abiliatti diferite si ca un proiect necesita un ansamblu echilibrat al acestor abilitati.
In cazul proiectelor mici, acelasi om poate juca mai multe roluri diferite; in proiectele mari fiecare rol este indeplinit de una sau mai multe persoane.

In general, intr-o echipa trebuie sa fie acoperite urmatoarele roluri:

de nucleu: producerea propriu-zisa a software-ului;

suplimentare: asigurarea suportului pentru activitatile nucleului;

periferice: aflate la granitele contextului proiectului.

Nucleul

In cazul abordarilor traditionale ale procesului de dezvoltare software, activitatea nucleului echipei este divizata astfel:

un grup se ocupa de colectarea si interpretarea cerintelor de la clienti;
un grup traduce cerintele in proiect;
un grup format din programatori scrie codul conform proiectelor.

Un asemenea stil monolitic forteaza oarecum aplicarea modelului in cascada, el fiind opusul tipului de proces iterativ si incremental ce caracterizeaza proiectele orientate pe obiecte.

In cazul proiectelor OO nucleul echipei este format din membri care indeplinesc 3 roluri distincte:

arhitect: responsabil cu structura de ansamblu a sistemului;
abstractionist: gestioneaza microarhitectura sistemului;
inginer de aplicatii: implementeaza si asambleaza clasele si colaborarile dintre clase.

Ca recomandare: cam 10% din echipa dee dezvoltare trtebuie sa constituie grupul de arhitecti, 30% sunt abstractionisti, 50% - ingineri de aplicatii, iar restul de 10% acopera roluri auxiliare.

Arhitectul
Este persoana (sau grupul) care raspunde de construirea si intretinerea arhitecturii sistemului. Principalele activitati ale arhitectului sunt:

Abstractionistul
Este o persoana care raspunde de proiectarea claselor si a categoriilor de clase. Cu alte cuvinte, abstractionistul este cel care se ocupa cu evolutia si intretinerea microarhitecturii sistemului.
Principalele activitati ale abstractionistului includ:

identificarea claselor, a pachetelor si a colaborarilor specifice domeniului, respectiv specifice implementarii;

stabilirea interfetelor si a serviciilor oferite de pachetele de clase, precum si supervizarea implementarii acestora;

realizarea testarii la nivel de categorie de clase;

consilierea arhitectului cu privire la continutul si ordinea iteratiilor succesive si punerea in aplicare a planului elaborat de arhitect;

coordonarea activitatii echipei insarcinate cu studierea alternativelor de proiectare si a riscurilor tehnice;

conducerea muncii inginerilor de aplicatii, abstractionistul fiind totodata si un mentor pentru acestia;

suplinirea arhitectului cand acesta lipseste.

In general, abstractionistul raspunde de elaborarea unor produse ca: documentatie de proiectare, parti ale documentatiei arhitecturii, interfetele claselor si ale categoriilor de clase, implementarea anumitor clase.
In timp ce arhitectul trebuie sa aiba o perspectiva globala asupra sistemului, abstractionistul trebuie sa "vada" la nivelul categoriilor de clase.
Abilitatile unui abstractionist seamana cu cele ale unui arhitect, dar de regula abstractionistul este mai bun programator. Ii lipseste in schimb experienta arhitectului.
Abstractionistul necesita si anumite calitati de analist, deoarece trebuie sa poata extrage abstractiunile ce compun un scenariu.

Inginerul de aplicatii
Este o persoana insarcinata cu implementarea claselor si a sabloanelor identificate de arhitect si abstractionist, respectiv cu asamblarea lor in fragmente de program care satisfac cerintele sistemului.
Principalele activitati ale inginerului de aplicatii includ:

In general, inginerul de aplicatii este cel care produce cod. De asemenea, el contribuie la realizarea documentatiei de proiectare si a celei de utilizare.

Pentru proiecte mici rolurile de abstractionist is inginer de aplicatii sunt indeplinite adesea de aceeasi persoana. Pentru proiecte mari sunt necesare persoane distincte. Mai mult, cu cat un proiect este mai complex, apare necesitatea de a fi implicati diferiti ingineri de aplicatii:

proiectanti de interfete grafice,
programatori pentru baze de date,
programatori pentru retele etc.

Abilitatile inginerului de aplicatii includ:

in primul rand cunostinte solide de programare; apoi:
familiaritatea cu notatiile si procesul de dezvoltare carateristice tehnologiei obiectuale;
cunoasterea idiomurilor limbajelor de programare;
usurinta de a comunica cu ceilalti coechipieri.

Echipa suplimentara

Este cea care asigura suportul pentru echipa ce formeaza nucleul, acoperind urmatoarele roluri:

Nu toate proiectele necesita intreaga lista de mai sus.

Managerul de proiect
Este rolul cel mai important, care NU POATE LIPSI. Acesta nu trebuie confundat cu arhitectul.
In timp ce arhitectul participa direct la producerea software-ului, managerul de proiect realizeaza asamblarea echipei necesare proiectului, stabileste termenele si controleaza aplicarea procesului de dezvoltare. Printre activitatile managerului de proiect se numara:

Analistul
Este insarcinat cu interpretarea cerintelor exprimate de client. El trebuie sa fie un expert in domeniul problemei. De regula, analistul conduce interviurile cu beneficiarul, identifica cerintele functionale si de performanta, rezolva conflictele si ambiguitatile setului de cerinte, este capabil sa dezvolte si sa detalieze scenarii.

Integrarea
In cazul proiectelor orientate pe obiecte, integrarea este o activitate continua, nu monolitica. Exista proiecte la care integrarea poate avea loc chiar si de cateva ori pe saptamana.
Este recomandabil ca rolul de integrator sa fie atribuit unei persoane distincte de membrii nucleului de dezvoltare, care sa fie responsabila cu asamblarea versiunilor compatibile ale diverselor produse elaborate la un moment dat, pentru a obtine o varianta executabila si livrabila a sistemului.

Controlul calitatii
In cazul proiectelor mici cade in sarcina echipei de dezvoltare. Pentru proiecte mari e util sa existe persoane separate care sa raspunda de evaluarea tuturor produselor rezultate in procesul de dezvoltare.

Redactarea documentatiilor
Se refera la elaborarea documentatiei de utilizare. La proiectele mici tendinta este de a incredinta aceasta sarcina membrilor nucleului. Aceasta practica este buna pana in punctul in care se constata ca programatorii ajung sa scrie mai mult text decat cod.
Experienta arata ca la proiectele reusite rolul redactarii documentatiei este atribuit unui redactor tehnic profesionist, capabil sa colaboreze cu nucleul echipei de dezvoltare, astfel incat sa inteleaga modelul solutiei problemei si sa-l transpuna in proza. Proiectele de dimensiuni modeste necesita 1-2 redactori cu norma partiala, in timp ce proiectele mari pot necesita o mica echipa anagajata cu norma intreaga pe o durata limitata.

Administratorul software
Se mai numeste constructor de unelte software (toolsmith) si are rolul de a crea sau de a adapta uneltele software in vederea facilitarii obtinerii produselor caracteristice unui proiect. Existenta unui asemenea specialist va degreva echipa de dezvoltare care de multe ori nu are timp sa scrie nici cel mai simplu utilitar. Administratorul software trebuie sa posede cunostinte adanci cu privire la suportul software utilizat de companie, precum si abilitati de programator care sa-i permita configurarea si adaptarea suportului respectiv dupa necesitati.
La proiecte mici aceasta sarcina poate reprezenta o parte din norma unui inginer de aplicatii. In companii mai mari, care au in derulare mai multe proiecte simultan va exista un administrator software "partajat" de toate proiectele. Doar proiectele de mari dimensiuni necesita un administrator software cu norma intreaga.

Administratorul hardware
Se mai numeste administrator de sistem si este cel care gestioneaza resursele hardware utilizate la un proiect. Pentru cei mai multi producatoari de software acest rol este indeplinit de o terta companie. Doar proiectele mari pot avea propriul administrator hardware.

Arhivarul
Acest rol se regaseste in cazul companiilor mari care promoveaza reutilizarea pe scara larga. Arhivarul sau bibliotecarul (librarian) este responsabil cu gestionarea arhivei de componente reutilizabile, incluzand cod, arhitectura, documentatie. Fara un efort sustinut de organizare, o asemenea arhiva poate deveni un imens depozit in care cautarea ar fi mai costisitoare decat rescrierea componentelor respective.
In cazul proiectelor mici rolul de bibliotecar poate fi preluat de administratorul software. Pentru proiecte mari acest rol poate fi indeplinit de o echipa formata din 2-3 persoane.

Echipa periferica

Nu este implicata in dezvoltarea software, dar are un impact specific asupra acesteia. Rolurile periferice includ: