Curs 6

[Curs nr.6]

Intretinerea

Scop: Gestionarea evolutiei sistemului de dupa livrare.
Aceasta faza este in esenta o prelungire a fazei de evolutie, dar in care scade foarte mult gradul de modificare a arhitecturii. Modificarile operate au un caracter mult mai local si ele se realizeaza ca urmare a:

adaugarii unor noi cerinte;

necesitatii eliminarii unor erori ascunse.

Orice sistem folosit pe scara industriala necesita aceasta faza din 2 motive:

legea schimbarilor continui: un program utilizat intr-un mediu real trebuie modificat, altfel el devine din ce in ce mai putin utilizabil;

legea cresterii complexitatii: pe masura ce un program se modifica, structura sa devine tot mai complexa.

Trebuie facuta o distinctie intre notiunile de:

prezervare = mentinerea in exploatare a unui sistem imbatranit, care de multe ori prezinta deficiente arhitecturale;

intretinere = adaptarea continua a unui sistem aflat in functionare.

Ca principiu: daca costul prezervarii unui sistem devine mai mare decat costul dezvoltarii unuia nou, se va renunta la cel vechi.
Faza de intretinere permite managerilor sa raspunda la urmatoarele intrebari:

Cum s-au modificat cerintele dupa punerea sistemului in exploatare?

Este arhitectura sistemului inca permisiva la modificari, sau e cazul sa se refaca arhitectura?

Prima intrebare se refera la impactul pe care l-a avut noul sistem asupra beneficiarului.
A 2-a intrebare este legata de aspectul economic al afacerii: ne aflam inca in stadiu de intretinere sau, din motive sentimentale, se practica de fapt prezervarea sistemului?

Produse: sunt aceleasi ca si cele de la evolutie, la care se adauga o lista a imbunatatirilor si a bug-urilor de eliminat.

Agenti: o parte a echipei de dezvoltare sau o echipa noua care nu a participat la dezvoltare, dar cu aceeasi structura.

Jaloane: sunt aceleasi ca si la evolutie.

4.Micro-procesul

    In cadrul unui proiect OO finalizat cu succes dezvoltarea are loc prin detalieri succesive ale arhitecturii sistemului. Prin natura sa, un asemenea proces este unul iterativ si incremental controlat, a carui durata se masoara in luni sau chiar ani. Acest macr-proces este exat pe evaluarea riscurilor, adica produsele si procesul de dezvoltare sunt adaptate pe masura ce riscurile sunt identificate si apoi surmontate. In esenta, macro-procesul constituie principalul mijloc prin care management-ul masoara gradul de "sanatate" al unui proiect, respectiv ii controleaza ritmul.
    Programatorul lucreaza insa dupa un ritm idividual diferit, in cadrul unui micro-proces unde traditionalele faze de analiza-proiectare-implementare isi pierd contururile, activitatile zilnice aflandu-se mai degraba sub semnul oportunismului. In orice moment trebuie adoptate o multime de decizii tactice cu privire la elaborarea si adaptarea sistemului software.
    Este foarte important ca cei implicati in desfasurarea unui proiect sa recunoasca existenta acestor 2 tipuri de procese suprapuse, aflate oarecum la concurenta. Aceasta, deoarece cele 2 procese au agende de lucru si activitati diferite. In timp ce macro-procesul are in vedere aspecte strategice legate de planificare si functionare, micro-procesul este axat mai mult pe aspecte tactice privind calitatea produsului software.
    Organizatiile care pun accent exagerat pe macro-proces lucreaza intr-o atmosfera "ceremonioasa", in care dezvoltarea efectiva de software este tratata ca o activitate minora. Organizatiile care dau o importanta exagerata micro-procesului lucreaza intr-o atmosfera de haos institutionalizat, care de cele mai multe ori face ca echipa respectiva sa elaboreze altceva decat a fost cerut. Pentru a avea succes, o organizatie trebuie sa gaseasca un echilibru intre aceste 2 procese.
    Multe carti din domeniul management-ului software ignora aspectele privitoare la proiectantul individual, vazand in acesta doar o piesa ce poate fi oricand inlocuita si dirijata dupa dorinta. In realitate, productia de software este o activitate umana si ca atare este afectata in mai mare masura de natura echipei de proiectanti decat de aspectele tehnice. Dezvoltarea de produse software este poate unul dintre domeniile cele mai sensibile la fluctuatia fortei de munca.
    Capitolul de fata se concentreaza asupra micro-procesului, evidentiind obiectivele, produsele, activitatile, agentii, jaloanele si masuratorile relevante la nivelul membrilor individuali ai echipei.
    Scala de timp a micro-procesului poate fi exprimata in ore, zile sau saptamani.

Ritmul micro-procesului este dat de alternanta activitatilor de descoperire-creatie-implementare.

Proiectantul, luat individual, este rareori interesat de lucruri non-tehnice ca beneficiu sau management al riscurilor. Dimpotriva, cei mai multi programatori isi leaga satisfactia profesionala direct de produdul software pe care il creaza. Ei isi manifesta mandria de a fi autorii unui program reusit, respectiv sufera sincer daca se constata ca programul are erori sau nu este ceea ce se asteapta beneficiarul. Fiecare programator asteapta o recunoastere a muncii lui, ca o contributie individuala la un anumit obiectiv comun. In ultima instanta, fiecare isi doreste sa contribuie la scrierea nucleului unui proiect spectaculos. Orice se interpune in calea acestui deziderat este considerat ca factor perturbator.
De aceea, se poate spune ca macro-procesul si micro-procesul implica agende de lucru si activitati diferite. Dar nu in sensul ca unul ar fi mai important decat celalalt.

Agenda micro-procesului unui proiect OO

Consta din urmatoarele activitati:

Selectarea abstractiunilor adecvate pentru modelarea problemei de rezolvat.

Distribuirea corecta a responsabilitatilor intre abstractiuni.

Stabilirea unui set de mecanisme care controleaza abstractiunile.

Reprezentarea concreta a abstractiunilor si a mecanismelor in modul cel mai eficient si elegant.

Se poate spune ca macro-procesul este un proces de management, in timp ce micro-procesul este unul tehnic, indreptat spre construirea unor produse reale, palpabile.
Macro-procesul constituie contextul micro-procesului, stabilind ce produse intermediare trebuie predate si care sunt jaloanele spre care echipa trebuie sa se concentreze. Macro-procesul reprezinta o forta motrice pentru echipa si este sarcina managerului de proiect sa aleaga cele mai potrivite jaloane, astfel incat echipa sa fie mentinuta "pe calea cea dreapta".
In cazul micro-procesului cade in sarcina echipei sa contribuie la atingerea setului de jaloane. Cele 2 procese nu sunt disjuncte, ci intr-o continua interferenta, in sensul ca produsele si jaloanele macro-procesului sunt create prin eforturile depuse in cadrul micro-procesului.
In plus, pentru ca un proiect sa reuseasca, este necesar sa existe o atmosfera de comunicare si deschidere care sa incurajeze membrii unei echipe sa faca aprecieri critice vis-a-vis de orice ipoteza formulata in contextul macro- sau micro-procesului. Aceasta atitudine sanatoasa reprezinta un factor de autoreglare a procesului de dezvoltare in ansamblu, prevenind echipa de a cadea in iluzii amagitoare. Afirmatii aparent inocente, ca de exemplu: "acest aspect nu e chiar atat de critic" sau "aceste clase pot fi usor implementate intr-o zi-doua" pot constitui adevarate bumeranguri care sa se intoarca impotriva unui proiect in cele mai neasteptate momente. De obicei erorile umane sunt amplificate de tehnologie, esecul fiind sigur atunci cand proiectul nu e "sincer" cu el insusi, mai ales cu privire la estimarea riscurilor si a cantitatii de efort necesar.
Intuitiv, micro-procesul fata de macro-proces ar putea fi ceea ce este miscarea de rotatie a pamantului fata de cea de revolutie. Prima genereaza alternanta zi-noapte, iar cealalta succesiunea anotimpurilor. "Rotatiile" care au loc in cadrul micro-procesului, desi presupun in principiu acceasi succesiune de activitati, prezinta deosebiri una fata de alta in functie de punctul curent din macro-proces in care se afla proiectul (asa cum de exemplu zilele sunt mai lungi in anumite anotimpuri). Astfel, pe durata fazei de analiza, accentul cade pe activitatile cu specific de descoperire; la proiectare accentul cade pe activitatile de creatie (inventie), iar la evolutie domina activitatile de implementare.
In cazul micro-procesului unui proiect OO, fazele principale sunt:

- identificarea claselor si a obiectelor
- identificarea semanticii claselor si a obiectelor
- identificarea relatiilor dintre clase si obiecte
- implementarea claselor si a obiectelor.

In cazul unui proiect elaborat intr-o maniera non-obiectuala micro-procesul presupune in esenta rafinarea succesiva a unor functii mari intr-unele mai mici.

Micro-procesul proiectelor OO are 4 caracteristici esentiale:

este ciclic, la fiecare iteratie punandu-se accentul pe o anumita portiune a sistemului sau pe un anumit nivel de abstractizare;
are un caracter de oportunitate, in sensul ca fiecare ciclu incepe doar cu ceea ce se cunoaste cel mai bine;

este axat pe roluri si responsabilitati ale claselor/obiectelor si nu pe functii si structuri de control;

este pragmatic, in sensul ca fiecare ciclu se termina prin realizarea unui produs executabil.

Identificarea claselor si a obiectelor

Scop: selectarea unor abstractiuni adecvate pentru modelarea problemei.
Acest pas este prin excelenta unul de descoperire. In functie de faza curenta a macro-procesului, el poate reprezenta:
la analiza - primul stadiu in trasarea limitelor (frontierelor) domeniului problemei; echipa de proiectanti are ca obiectiv identificarea acelor abstractiuni care formeaza vocabularul problemei; pentru aceasta se incepe printr-o selectie a notiunilor care prezinta interes.
la proiectare - stadiul de descompunere obiectuala a arhitecturii sistemului, cand echipa identifica acele abstractiuni care constituie elemente ale solutiei problemei.
la evolutie - inceputul "umplerii" scheletului arhitectural, prin identificarea abstractiunilor primitive necesare reprezentarii celor de nivel inalt si prin descoperirea aspectelor comune ale abstractizarilor existente, in vederea "factorizarii" lor cu scopul simplificarii arhitecturii.
Identificarea claselor si a obiectelor este o problema fundamental inginereasca, nu una teoretica. Aceasta activitate nu are un sfarsit clar, deoarece nu exista abstractiuni perfecte. De aceea, se recomanda ca intr-o prima faza sa se gaseasca un set de abstractiuni considerate ca "destul de bune" sau "multumitoare", lasand apoi ca natura ciclica a procesului de dezvoltare OO sa constituie mecanismul de selectie naturala care va duce la imbunatatirea ulterioara a acelor abstractiuni.
Produse: exista un singur produs de baza al acestui pas, si anume un dictionar al abstractiunilor.
Acest dictionar include clase, obiecte si mecanisme care realizeaza colaborarile intre clase/obiecte. Initial, dictionarul poate fi o simpla lista formata din clasele, obiectele si mecanismele cele mai semnificative, notate cu ajutorul unor nume cat mai sugestive. Pe masura ce procesul de dezvoltare se deruleaza, dictionarul va creste in dimensiuni si se poate constata necesitatea de a formaliza reprezentarea lui, utilizand o forma oarecare de baza de date. In acest caz dictionarul va putea servi is ca un glosar (index) pentru celelalte produse rezultate din procesul de dezvoltare, in sensul ca in dictionar pot fi incluse si descrieri sau trimiteri spre diagrame sau specificatii asociate cu o anumita abstractiune.
Se poate spune ca un asemenea dictionar reprezinta suportul central pentru vocabularul domeniului si al solutiei problemei.
Avantajele utilizarii dictionarului:
intretinerea dictionarului constrange echipa sa stabileasca un vocabular comun si consistent pentru proiectul respectiv;
dictionarul poate servi ca instrument de baleiere pe diferite directii a elementelor unui proiect; acest lucru este util mai ales in cazul includerii de noi membri in echipa, in decursul dezvoltarii proiectului;
dictionarul permite formularea unei viziuni globale asupra proiectului, in scopul identificarii eventualelor aspecte comune ale abstractiunilor.

Activitati: exista o singura activitate de baza asociata acestui pas, si anume descoperirea si crearea abstractiunilor.
Aceasta activitate este in esenta o problema de clasificare. Ea nu are o solutie optima unica, ci eventual un set de solutii acceptabile, iar uneori cateva solutii de profunzime, in functie de compromisurile sau restrictiile adoptate in contextul problemei.
Pentru a ilustra acestea, vom considera ca exemplu urmatoarea problema de clasificare: dandu-se un set de 4 obiecte: cal, pictura, cer si masina, se cere sa se selecteze acela care se deosebeste de restul. Deoarece nu se specifica un anumit context (criteriu), raspunsuri acceptabile pot fi mai multe: calul este singura fiinta vie sau singurul obiect care nu poate fi albastru, pictura este singura care poate servi la a reprezenta atat celelalte obiecte cat si pe ea insasi, cerul este singurul obiect fara contur bine determinat etc. Daca la un moment dat efectuam o schimbare a cerintelor (lucru care se intampla in orice proiect real), in sensul ca specificam faptul ca problema este una de modelare a unui sistem de polite de asigurare, in acest caz probabil aria solutiilor se va restrange. Astfel, putem spune de exemplu ca cerul este singurul care nu poate face obiectul unei asigurari.
Cum sunt detectate cele mai multe dintre clase, obiecte si mecanisme?
Examinand vocabularul persoanelor familiarizate cu domeniul problemei de rezolvat;
Explorand bagajul de cunostinte si experienta celor implicati in dezvoltarea si utilizarea ulterioara a sistemului.
Majoritatea claselor sunt destul de usor de gasit. Mai dificila este stabilirea limitelor lor precise.
Din experienta s-a constatat ca identificarea claselor si a obiectelor se poate face eficient prin intermediul scenariilor, folosind tehnica CRC.
O secventa tipica de desfasurare a activitatii este urmatoarea:
Se genereaza un set de abstractiuni "candidate", aplicand metode clasice ale analizei OO, si anume cautand obiectele cu proprietati comune. In fazele de inceput ale ciclului de viata "candidatii" care constituie un bun punct de plecare sunt entitatile tangibile din enuntul problemei. In fazele ulterioare abstractiunile vor rezulta prin identificarea evenimentelor externe care influenteaza sistemul: pentru fiecare eveniment trebuie sa existe un obiect care in ultima instanta detecteaza si/sau reactioneaza la evenimentul respectiv.
Pornind de la comportamentul observabil din exterior al sistemului (function points), se identifica rolurile si responsabilitatile entitatilor din domeniul problemei care genereaza acel comportament. La fel ca in cazul evenimentelor, pentru fiecare latura a comportamentului trebuie sa existe anumite abstractiuni care initiaza si participa la functiunea respectiva. Evidentierea laturilor comportamentului se realizeaza analizand scenariile elaborate in cadrul macro-procesului.

Agenti: nu toti proiectantii au aptitudinile necesare pentru a realiza aceasta activitate. Ea este in primul rand sarcina arhitectului de proiect. Pe langa acesta, analistii care lucreaza alaturi de experti in domeniul problemei trebuie sa fie capabili sa descopere abstractiunile. Inginerii de aplicatii, care se ocupa in principal cu implementarea si asamblarea claselor, identifica si ei o parte din abstractiuni, dar acestea vor avea un caracter mai degraba tactic.
Jaloane si masuratori: acest pas se considera terminat pentru iteratia curenta a micro-procesului cand echipa a ajuns la un consens rezonabil cu privire la dictionarul de abstractiuni.
Un indiciu ca proiectul merge bine este acela ca nu apar modificari dramatice ale consensului la fiecare ciclu al micro-procesului. Daca setul de abstractiuni se modifica foarte frecvent, acesta poate fi un semn ca echipa inca nu a identificat un obiectiv comun sau ca arhitectura este deficitara.

Identificarea semanticii claselor si a obiectelor

Scop: determinarea unei distributii corecte a responsabilitatilor intre clase si obiecte.
Acest pas este presupune cate o cantitate mica de:
descoperire, adica intelegerea in profunzime a semanticii fiecarei abstractiuni;
creatie, adica determinarea setului adecvat de roluri si responsabilitati si atasarea lor fiecarei abstractiuni;
implementare, adica aducerea deciziilor de mai sus la o forma concreta.
In functie de faza curenta a macro-procesului, el poate avea diferite obiective:
la analiza - rolurile si responsabilitatile fiecarei abstractiuni sunt asociate cu diferite parti ale modelului domeniului sau cu diferite straturi ale sistemului.
la proiectare - se stabileste o separare clara a componentelor arhitecturale, in sensul ca abstractiunile cu o semantica inrudita sunt grupate impreuna, in timp ce abstractiunile independente semantic sunt tinute separat.
la evolutie - se detaliaza semantica abstractiunilor, transformand-o dintr-o descriere libera intr-un ansamblu de protocoale concrete si apoi in semnaturi precise pentru operatii, respectiv in specificatii clare ale colaborarilor ce definesc fiecare mecanism.
Acest pas se axeaza pe comportament si considera chestiunile legate de reprezentare ca fiind secundare.
Specificarea semanticii claselor si a obiectelor, la debutul ciclului de viata, se realizeaza de obicei scriind responsabilitatile lor sub forma de text liber. Fiecare responsabilitate trebuie sa poata fi descrisa intr-o singura fraza sau propozitie. Pe masura ce se deruleaza procesul de dezvoltare, descrierile respective se transforma in seturi de operatii care, mai intai au doar nume, apoi capata si semnaturi complete. In acest fel se creaza posibilitatea de trasare, si anume: o anumita responsabilitate este satisfacuta de un anumit set de operatii, iar fiecare operatie, la randul ei, contribuie la comportamentul unei anumite abstractiuni.
Trebuie precizat ca identificarea semanticii claselor si a obiectelor se desfasoara atat la nivel de clase individuale, cat si la nivel de grupuri de clase. Daca la nivel de clasa rolurile si responsabilitatile se materializeaza ca operatii membru, in cazul grupurilor de clase, responsabilitatile se materializeaza ca set de operatii ce realizeaza anumite servicii exportate de grupul respectiv.

Produse: in acest pas rezulta in principiu 3 produse:
O specificatie a rolurilor si responsabilitatilor abstractiunilor esentiale. Este cel mai important produs, mai ales in fazele incipiente ale ciclului de viata. Ca forme de reprezentare a specificatiei, se pot folosi de la simple schite, text CRC, pana la notatii mai riguroase.
Software-ul care codifica aceasta specificatie. Este bine sa se elaboreze cat mai devreme posibil. Practic acest produs presupune scrierea interfetei fiecarei clase importante in limbajul de programare ales. De exemplu, pentru C++, acest produs consta din setul de fisiere header.
Diagrame sau alte modalitati similare de reprezentare a semanticii fiecarei abstractiuni. Aceste diagrame sunt utile deoarece anumite aspecte ale semanticii nu pot fi captate prin text sau cod. In functie de faza curenta a macro-procesului, diagramele elaborate vor fi: diagrame de scenariu (la analiza), diagrame de clase si de stari (la proiectare si evolutie).
Imposibilitatea de a specifica clar semantica abstractiunilor in acest pas poate fi un indiciu ca abstractiunile nu au fost bine alese.
Activitati: exista 3 activitati majore in acest pas:
Planificarea scenariilor
Proiectarea claselor individuale
Identificarea sabloanelor
Planificarea scenariilor
Planificarea scenariilor, asa cum s-a vazut, este o parte esentiala a macro-procesului. In acest context, obiectivul central este selectarea unui set adecvat de scenarii si utilizarea lor pentru dirijarea proiectarii arhitecturii. In contextul micro-procesului planificarea scenariilor se refera la aspecte tactice ale modului in care sunt utilizate scenariile la identificarea abstractiunilor. De regula aceasta activitate presupune urmatoarele etape:
Se selecteaza unul sau mai multe scenarii legate de aceeasi functiune a sistemului si se evidentiaza care sunt abstractiunile (identificate in pasul anterior al micro-procesului) implicate in scenariile respective.
Se parcurge fiecare scenariu, atasand suficiente responsabilitati abstractiunilor componente, cat sa se obtina comportamentul dorit. La nevoie se pot atasa atribute care sa reprezinte elementele structurale necesare indeplinirii anumitor responsabilitati.
Pe masura ce se inainteaza cu aceste actiuni, se pot efectua si realocari ale responsabilitatilor pentru a rezulta in final o distributie echilibrata a lor. Acolo unde este posibil, se recomanda reutilizarea sau adaptarea responsabilitatilor deja existente. O alta operatie destul de frecventa este divizarea unor responsabilitati complexe in elemente mai simple.
In practica se intalneste adesea urmatoarea situatie: pentru a se putea face fata complexitatii unui scenariu, se creaza un numar mai mare de clase. Desi aparent contrara principiilor proiectarii OO, aceasta practica se justifica prin aceea ca, de multe ori adaugand cateva clase bine plasate, anumite responsabilitati se "deplaseaza", rezultand o mai buna partajare si echilibrare a lor intre clase.
Proiectarea claselor individuale
Daca la planificarea scenariilor se abordeaza semantica abstractiunilor intr-o maniera top-down (de sus in jos), proiectarea claselor individuale presupune o identificare a semanticii in mod bottom-up (de jos in sus). Ambele activitati sunt importante, deoarece impreuna ele acopera cele 2 fatete ale unei abstractiuni:

exteriorul, deoarece planificarea scenariilor este axata pe modul in care este utilizata abstractiunea, si

interiorul, deoarece proiectarea claselor individuale priveste ansamblul claselor, subclaselor si al delegarilor ce formeaza o singura abstractiune.

Proiectarea claselor individuale are un caracter mai mult tactic, deoarece nu presupune proiectare arhitecturala. De regula, aceasta activitate implica urmatoarele etape:
Se selecteaza o abstractiune si i se enumera rolurile si responsabilitatile.
Se dezvolta un set minimal acoperitor de operatii care satisfac responsabilitatile.
Se analizeaza fiecare operatie pentru a vedea daca este sau nu primitiva. O operatie primitiva nu necesita o descompunere in/delegare spre alte operatii. Pentru operatiile compuse se procedeaza la izolarea si evidentierea componentelor sale primitive. Operatiile compuse pot fi retinute in clasa respectiva sau pot fi impinse spre alte clase utilitare, mai ales daca sunt pasibile de modificari frecvente.
In fazele avansate ale procesului de dezvoltare software se vor trata si aspectele privitoare la ciclul de viata al unei abstractiuni care presupune, printre altele, crearea, copierea si distrugerea abstractiunii respective. In general este recomandabil ca aceste aspecte sa fie tratate in cadrul unei politici unitare, si nu sa se permita ca fiecare abstractiune sa urmeze un idiom propriu.
In functie de necesitati, se adauga unele operatii primitive care nu sunt necesare clientilor deja existenti, dar care se estimeaza ca ar putea servi in viitor, realizand in acest fel completarea unei abstractiuni.
Pe masura ce se avanseaza in cadrul macro-procesului, proiectarea claselor individuale trece de la stadiul in care se ocupa de clase izolate, la stadiul in care trebuie sa abordeze multimi de clase organizate ierarhic. In acest stadiu, printre altele, se pune problema plasarii corecte a operatiilor in cadrul ierarhiei de clase. In practica se recomanda aplicarea urmatoarelor reguli:

operatiile care vor fi utilizate de perechi de clase vor fi plasate in cate o superclasa comuna, eventual introducandu-se o noua clasa abstracta intermediara;

operatiile utilizate de multimi disjuncte de clase se vor incapsula intr-o clasa "reuniune";

operatiile care sunt unice, apartinand unor clase specifice sau care reprezinta specializari ale altor operatii trebuie "impinse" spre nivelele inferioare ale ierarhiei.

Identificarea sabloanelor
Este tot o activitate specifica macro-procesului, dar in contextul micro-procesului reprezinta tactica folosita pentru a exploata orice "factor comun" intalnit in sistem. Pe parcursul elaborarii semanticii abstractiunilor este foarte importanta detectarea sabloanelor de comportare deoarece ele reprezinta posibilitati de reutilizare. Identificarea sabloanelor presupune de obicei urmatoarele etape:
Avand un set de scenarii, se cauta sabloane ale interactiunilor (colaborarilor) intre abstractiuni, eliminandu-se diferentele nejustificate dintre diferitele invocari ale interactiunilor respective. Reutilizarea sabloanelor de colaborare asigura o integritate a viziunii arhitecturale.
Avand un set de responsabilitati, se cauta sabloane ale comportamentului. Rolurile si responsabilitatile comune trebuie reunite sub forma unor clase de baza sau abstracte comune.
In fazele avansate ale procesului de dezvoltare, cand se dispune deja de operatii concrete, se cauta sabloane ale semnaturilor operatiilor. Semnaturile care se repeta se vor incapsula in clase utilitare comune.

Agenti: planificarea scenariilor este condusa de experti in domeniu asistati de proiectanti. Pe masura ce se inainteaza in cadrul procesului de dezvoltare si scade riscul ca problemele sa fie gresit intelese, aceasta activitate capata un caracter din ce in ce mai tactic, motiv pentru care ea poate fi indeplinita si de programatori individuali sau de mici echipe de programatori. La fel, proiectarea claselor este o activitate care se executa la nivel de programatori individuali, sau in grupuri de cate 2 programatori, unul jucand rol de mentor. In orice caz, activitatile desfasurate la nivel individual nu vor fi tinute "la secret", rezultatele lor trebuind sa fie supuse periodic unui control de catre o terta persoana. Identificarea sabloanelor este de asemenea o munca a proiectantilor individuali, dar pentru garantia reusitei este mai bine sa fie incredintata unei mici echipe tip "tiger". Acest lucru va ajuta si la propagarea viziunii arhitecturale astfel incat fiecare proiectant sa aiba o vedere globala asupra problemei.
Jaloane si masuratori: aceasta faza se considera completata cand echipa a reusit elaborarea unui set primitiv acoperitor de responsabilitati, respectiv operatii pentru fiecare abstractiune. Ca regula generala in vederea aprecierii dimensiunilor abstractiunilor, se poate folosi urmatoarea:
Cele mai multe clase au in medie o duzina de operatii. Nu sunt neobisnuite nici clasele cu 1-2 operatii, mai ales daca e vorba de clase derivate. Clasele care au un numar mult mai mare decat media statistica nu constituie neaparat erori, dar pot fi un avertisment ca nivelul de abstractizare aplicat este prea scazut.

Identificarea relatiilor intre clase si intre obiecte

Scop: realizarea unui set de mecanisme care controleaza clasele si obiectele identificate pana in acest punct.
Acest pas implica in mare masura creatie in sensul adoptarii de decizii cu privire la semantica dependentelor intre clase/obiecte, respectiv intre grupuri de clase/grupuri de obiecte. In afara de aceasta exista intr-o oarecare masura si o parte de descoperire, determinata de ajustarea frontierelor abstractiunilor, precum si o parte de implementare necesara pentru verificarea implicatiilor unor decizii adoptate, care nu pot fi anticipate doar cu ajutorul schemelor pe hartie.
In functie de faza curenta a macro-procesului, acest pas poate avea diferite obiective:
la analiza - se realizeaza un model al domeniului problemei, prin considerarea asocierilor intre clase si obiecte. Aceste asocieri specifica:

modul in care clientii navigheaza printre obiectele modelului,

modul in care anumite clase si obiecte sunt structural legate de alte abstractiuni,

modul in care comportamentul este delegat intre obiecte pe parcursul derularii unui scenariu.

la proiectare - se specifica acele colaborari care sunt importante pentru arhitectura sistemului, stabilindu-se conexiunile intre grupuri de clase si obiecte care conlucreaza pentru obtinerea unui anumit comportament la un nivel superior. Se specifica de asemenea, gruparea calselor in categorii si stratificarea categoriilor una fata de alta.
la evolutie - se adauga detalii la arhitectura sistemului, pe masura ce anumite asocieri sunt traduse in instante ale unor colaborari la nivel inferior sau sunt transformate in idiomuri de programare specifice.
Identificarea relatiilor intre clase si obiecte are la baza faptul ca nici un obiect nu evolueaza in izolare fata de alte obiecte. Ea presupune nu doar o simpla detaliere a produselor obtinute in pasii anteriori ai micro-procesului, ci trebuie sa duca la identificarea unor sabloane de relatii care vor permite simplificarea arhitecturii. In acest pas se recomanda o maximizare a conexiunilor intre entitati inrudite semantic, respectiv o minimizare a conexiunilor intre entitati cu semantica foarte diferita sau care sunt pasibile de modificari.
Produse: in acest pas rezulta in principiu 3 produse:
O specificatie a relatiilor intre abstractiunile esentiale. Este cel mai important produs in acest pas. In faza de analiza a macro-procesului specificatia se refera la toate formele de asociere intre abstractiuni, in timp ce la proiectare si evolutie ea se refera la relatii mai specifice, cum ar fi mostenirea, agregarea etc. Ca forme de reprezentare a specificatiei, se pot folosi de la simple schite, text CRC, pana la notatii mai riguroase.
Software-ul care codifica aceasta specificatie. Practic acest produs presupune detalierea interfetelor elaborate in pasul anterior al micro-procesului, prin introducerea conexiunilor semantice intre clase.
Diagrame sau alte modalitati similare de reprezentare a semanticii fiecarei relatii. Aceste diagrame sunt poate mai utile aici decat in alti pasi, deoarece orice relatie implica mai mult decat o singura abstractiune. In functie de faza curenta a macro-procesului, diagramele elaborate vor fi: diagrame de clase (la analiza), diagrame de categorii (pachete) si de stari, diagrame care sa reflecte corespondenta intre clase si fisiere, sau intre obiecte, respectiv procese distribuite si procesoare (la proiectare si evolutie).
Activitati: exista 3 activitati majore in acest pas:
Specificarea asocierilor
Identificarea colaborarilor
Detalierea asocierilor
Agenti: aceeasi ca si in cazul identificarii semnaticii claselor si a obiectelor.

Jaloane si masuratori: se considera ca aceasta faza este terminata cand a avut loc specificarea semanticii si a relatiilor intre abstractiunile cele mai importante, intr-o masura suficienta incat pe baza specificarii respective sa se poata implementa clasele implicate.