Curs 4

[Curs nr.4]

Produse:

pe durata analizei se genereaza 4 produse:

O descriere a contextului sistemului. Serveste la stabilirea granitelor sistemului si, implicit, a distinctiei intre elementele interioare si cele exterioare ale sistemului. Ca forma de reprezentare, descrierea contextului poate fi o simpla enumerare informala a elementelor software si hardware situate la marginile sistemului. Intr-un proiect mai formal, descrierea contextului se poate face printr-o diagrama de colaborare, in care unul dintre obiecte reprezinta sistemul in ansamblu, iar celelalte reprezinta sisteme software sau hardware cu care sistemul studiat intra in interactiune.

O colectie de scenarii care definesc comportamentul sistemului.
In comunitatea specialistilor OO s-a incetatenit un mijloc foarte pragmatic de descoperire, captare, documentare si comunicare a cerintelor unui sistem, si anume cazurile de utilizare (use-case) - cunoscute de la cursul de IP. Un caz de utilizare specifica o parte a comportarii unui sistem.
Dupa cum se stie, un scenariu este o instanta a unui caz de utilizare. Pe durata analizei comportarea de ansamblu a sistemului poate fi exprimata cu ajutorul unei retele de scenarii.
Exemplu: intr-o aplicatie din domeniul bancar un caz de utilizare ar putea fi gestionarea unui credit; scenarii posibile ale acestui caz de utilizare sunt:
- solicitarea unui credit;
- efectuarea platii unei rate;
- lichidarea creditului;
- consultarea istoricului platilor;
- vanzarea creditului unei alte institutii financiare;
- tratarea intarzierilor la plata sau a neplatilor;
In ceea ce priveste dimensiunile acestei retele, in practica se aplica urmatoarea regula:

Pentru proiecte de complexitate modesta numarul normal de use-cases este de ordinul catorva duzini, numarul de scenarii principale este cu un ordin de marime mai mare, iar cel al scenariilor secundare, cu inca un ordin de marime mai mare.

Scenariile sunt aproape independente intre ele, in sensul ca pot fi studiate separat, desi in realitate fiecare dintre ele are o oarecare conexiune semantica cu celelalte. Cele mai multe dintre scenariile interesante traverseaza felii largi ale arhitecturii, atingand mai multe seturi de clase si obiecte aflate in colaborare. Prin urmare, cele mai interesante abstractiuni sunt acelea care apar in mai multe scenarii.
Insemnatatea scenariilor pentru dezvoltarea sistemelor OO decurge din urmatoarele:

Ele servesc ca mijloace esentiale de captare a cerintelor unui sistem.
Reprezinta o modalitate de comunicare.
Constituie instructiuni pentru proiectantii individuali si pentru echipa de testare.
Formeaza o baza importanta pentru planificarea in timp a iteratiilor macro-procesului, pe durata proiectarii si a evolutiei.

La ce NU sunt bune scenariile? Ele NU definesc arhitectura sistemului, ci doar ilustreaza interactiunile dinamice care apar intr-o arhitectura.

Ca forme de reprezentare a scenariilor, se pot utiliza:

cardurile CRC (CRC=Class, Responsibilities, Collaborators); sunt un fel de instrument CASE al saracului, constand dintr-un pachet de cartoteci si cateva creioane cu guma buna; avantajul lor este acela ca nu impun o anumita regula asupra notatiei si incurajeaza interactiunea activa intre echipa de proiectanti si expertii in domeniu; dezavantajul consta in faptul ca, dupa elaborarea unui scenariu, proiectantul nu poate sa lege cartotecile cu un elastic si sa le puna in bratele clientului, pe post de documentatie a fazei de analiza; cardurile CRC nu comunica aspectele temporale sau spatiale ale unui scenariu;
o notatie mai formala, diagramele de scenariu, care pot fi: diagrame de secventa si diagrame de colaborare (cunoscute, de asemenea de la IP).

In proiectele obisnuite scenariile sunt materializate sub forma unei colectii informale, care utilizeaza una sau ambele notatii amintite mai sus, aplicate pe hartie sau in contextul unui instrument software de analiza. In proiectele mai formalizate, scenariile sunt asamblate intr-un document de analiza a cerintelor care suporta revizii periodice, controlate.

Un model al domeniului. Modelul domeniului are ca scop vizualizarea claselor esentiale, responsabile pentru comportamentul central al sistemului.
In proiectele informale acest model este exprimat simplu, ca un dictionar al tuturor claselor interesante care participa in diverse scenarii.
In proiectele formalizate, modelul domeniului este reprezentat ca o colectie de diagrame de clase. Ramanand la exemplul cu aplicatia bancara, in figura de mai jos este reprezentata o diagrama de clase continand o parte a claselor importante:

Modelul domeniului nu este un produs al inventiei, ci mai mult al descoperirii. Clasele din diagrame sunt extrase direct din vocabularul problemei. De fapt, clasele si obiectele din diagramele de scenariu sunt cele care apar in modelul domeniului.

La elaborarea modelului domeniului, se pot aplica urmatoarele reguli:

la proiectele de complexitate modesta, pot sa apara cam 50-100 de clase in model, reprezentand numai abstractiunile esentiale din spatiul problemei;
atentia va fi indreptata doar asupra acelor clase care formeaza vocabularul central al problemei; daca prin inlaturarea unei clase, modelul nu se prabuseste, se poate renunta la ea, deoarece nu este importanta pentru analiza;
trebuie considerate relatiile de asociere intre clase, identificand intelesul lor si, unde e cazul, cardinalitatea (multiplicitatea) lor; in aceasta faza intereseaza mai putin relatiile de mostenire;

Modelul domeniului, pe langa vizualizarea claselor care formeaza vocabularul problemei, mai serveste si la evidentierea distributiei rolurilor si a responsabilitatilor in sistem.
Modelul domeniului nu serveste la identificarea precisa a operatiilor ce constituie suportul responsabilitatilor. Identificarea responsabilitatilor este o activitate de descoperire, in timp ce identificarea operatiilor este una de creatie.

De regula, modelul domeniului unui sistem este reprezentat ca o colectie de diagrame de clase, impreuna cu o specificatie a rolurilor si a responsabilitatilor. In anumite cazuri, la acestea se adauga si o specificatie privind durata de viata a anumitor clase, care poate fi reprezentata cu ajutorul diagramelor de stare.

O reevaluare a riscurilor. In aceasta faza, evaluarea riscurilor se refera in principal la identificarea scenariilor celor mai critice pentru succesul proiectului, in contextul setului minimal de caracteristici. Atentia trebuie indreptata spre identificarea naturii riscurilor si nu asupra solutiei lor, care va fi abordata in urmatoarea faza de dezvoltare.

Activitati:

Exista 2 activitati de baza, al caror scop este acela de a dezvolta un vocabular comun si de a obtine o intelegere comuna despre comportarea dorita a sistemului.

Planificarea scenariilor. Este activitatea centrala a fazei de analiza. In cadrul acestei activitati se procedeaza la investigarea scenariilor individuale si la construirea modelului domeniului. Aceasta activitate urmeaza de regula urmatoarea secventa de pasi:

Se enumera toate functiile primare ale sistemului si, acolo unde este posibil, ele sunt organizate sub forma de use-cases. Motivul pentru care se porneste de la setul de functii, desi avem de a face cu un proiect OO, este acela ca, la cel mai inalt nivel de abstractizare, toate sistemele nu sunt altceva decat un manunchi de servicii sau comportamente. Inceperea analizei cu o perspectiva functionala asupra sistemului permite trasarea granitelor acestuia.

Se specifica contextul sistemului.

Se intocmeste o lista a scenariilor principale. Aceasta forteaza utilizatorii si expertii in domeniu sa ajunga la un anumit consens privind comportamentele cele mai importante in raport cu setul minim de caracteristici si asupra modului in care diversele comportamente pot fi distinse unele de altele.

Documentarea scenariilor principale.

In functie de necesitati, se genereaza scenarii secundare care ilustreaza portiuni comune ale scenariilor principale sau comportarea in conditii de exceptie.

Pe masura elaborarii scenariilor se realizeaza popularea modelului domeniului cu clasele si obiectele identificate pentru fiecare scenariu, precum si cu rolurile si responsabilitatile acestora.

Acolo unde ciclul de viata al unor obiecte este semnificativ pentru comportarea sistemului, se va elabora un scenariu sau o diagrama de stare pentru obiectele respective.

In cazurile in care comportarea sistemului este determinata de evenimente externe, se va intocmi o lista cu evenimentele respective, analizandu-se impactul lor asupra sistemului. Acest lucru presupune, pentru fiecare eveniment in parte, identificarea claselor din modelul domeniului care realizeaza detectarea evenimentului si tratarea lui.

Se studiaza scenariile si modelul domeniului pentru a se gasi sabloane si se exprima aceste sabloane sub forma unor scenarii generalizate, mai abstracte sau in termeni de clase care incorporeaza structuri comune sau comportament comun.

Analiza domeniului. Are ca scop descoperirea explicita a riscurilor si identificarea claselor si a obiectelor comune pentru mai multe probleme. Aceasta activitate cuprinde 2 pasi semi-independenti:

Studiul unor sisteme existente care sunt similare celui aflat in dezvoltare.

Pentru aspectele inca nesigure ale sistemului se dezvolta prototipuri care vor fi utilizate la validarea presupunerilor facute de proiectanti in legatura cu comportarea dorita a sistemului, respectiv vor servi ca baza de comunicare cu utilizatorul final.

Agenti:

pentru elaborarea prototipului cel mai eficient este sa se utilizeze o echipa mica, formata din arhitectul sistemului, 1-2 analisti sau proiectanti-sefi, 1-2 experti in domeniu si/sau utilizatori si un membru al colectivului de testare/control calitate.

Jaloane si masuratori: exista 3 jaloane de baza:

specificarea contextului sistemului, a functiilor si a scenariilor;
elaborarea scenariilor sistemului;
completarea modelului sistemului.

Regula: faza de analiza poate fi considerata ca incheiata cand echipa a elaborat aproximativ 80% dintre scenariile principale si o colectie reprezentativa a scenariilor secundare. Scenariile principale trebuie sa se refere doar la comportamentul extern al sistemului, la constrangerile impuse asupra lui si la raspunsul sistemului la posibile evenimente nedorite.

Proiectarea

Scop: crearea unei arhitecturi pentru viitoarea implementare.
O data terminata analiza, exista de multe ori tendinta de a considera modelul domeniului rezultat din analiza ca fiind gata pentru codare, fara a mai trece prin faza de proiectare. Unii incearca sa ignore aceasta faza fie pentru ca sunt grabiti sa ajunga la produsul finit si nu mai au timp de arhitectura, fie pentru ca nu au convingerea ca proiectarea arhitecturala are vreo valoare reala.
Fara o arhitectura sanatoasa, un proiect nu va avea o integritate conceptuala, clasele nu se vor imbina, chiar daca ele, luate separat sunt bune, iar sistemul rezultat va fi fragil, greu de inteles si mult mai complex decat ar fi nevoie de fapt.
Proiectarea poate incepe indata ce echipa a obtinut o intelegere rezonabila asupra cerintelor. Ea se concentreaza asupra structurii statice si dinamice a sistemului. In paralel cu proiectarea, analiza poate continua, in principal pentru a studia partile inca nesigure ale comportarii sistemului. Proiectarea serveste in primul rand la crearea unui schelet concret al sistemului pe care vor fi "agatate" componentele rezultate la implementare. Pentru proiecte de complexitate modesta, al caror ciclu de viata este de aprox. 1 an, faza de proiectare dureaza cam 1 luna, rar depasind 2 luni.
La terminarea acestei faze, managerii trebuie sa poata raspunde la urmatoarele intrebari:

Care este structura de baza a sistemului?

Care sunt sabloanele care contureaza aceasta structura, conferindu-i simplitate?

Ce parti ale sistemului pot fi reutilizate sau adaptate din alte surse?

Care este planuldupa care se preconizeaza evolutia arhitecturii spre producerea sistemului?

Exista factori de risc noi sau cunoscuti care inca nu au fost depasiti ?

Cautarea raspunsurilor la aceste intrebari reprezinta motorul procesului de proiectare. Primele 2 intrebari din lista de mai sus privesc forma arhitecturii rezultate. A 3-a intrebare priveste caile de rezolvare a problemei prin adaptarea unor cadre existente, utilizand diverse generatoare de aplicatii si exploatand anumite sisteme mostenite (legacy sistems). Ultimele intrebari se refera la stabilirea unui plan de evolutie a arhitecturii in faza urmatoare.

Produse:

pe durata proiectarii se genereaza 5 produse:

O arhitectura executabila. Este cel mai important produs al acestei faze, deoarece:

Reprezinta o manifestare tangibila a multor decizii strategice.
Ofera o platforma de validare a multor ipoteze facute la analiza si la proiectare.
Este o forma intermediara stabila a sistemului, care poate fi mai usor "adaugita" pe masura ce se descopera noi detalii ale problemei si se creaza noi structuri.

O arhitectura executabila

Exista ca o aplicatie reala care poate rula intre anumite limite.
Realizeaza comportarea partiala sau completa a catorva dintre scenariile interesante.
Contine cod de calitate.
Reprezinta fie o felie verticala a sistemului, fie una orizontala care capteaza cele mai interesante elemente din modelul domeniului.
O felie verticala atinge clase din majoritatea categoriilor (pachetelor), de sus in jos. In figura de mai jos sunt reprezentate cateva din categoriile de clase ce ar putea compune o aplicatie bancara:

In acest caz felia verticala ar putea presupune realizarea interfetelor necesare: procesarii unui credit, modelului de functionare si bazei de date. Este vorba despre clasele aflate la granita fiecareia dintre categoriile enumerate.
O felie orizontala ar presupune atingerea intregului model al domeniului.
In general, felia verticala vizeaza aspecte tehnologice, in timp ce felia orizontala vizeaza logica sistemului. Ca regula, se recomanda ca felia verticala sa acopere 20% din adancimea sistemului, iar felia orizontala - 80% din largime.
Atinge majoritatea interfetelor arhitecturale.
Propune un anumit numar de simplificari explicite.

Specificarea tuturor sabloanelor arhitecturale importante. Este al 2-lea produs ca importanta si reprezinta o specificare a idiomurilor, a sabloanelor de proiectare si a cadrelor (la acestea din urma se vor descrie propriile sabloane de proiectare). Sabloanele sunt importante deoarece:

Capteaza intentiile si viziunea arhitectului si servesc la transmiterea acestei viziuni intr-un mod palpabil.
Ofera solutii comune unor probleme inrudite, permitand astfel simplificarea sistemului.

Un plan al elaborarii versiunilor. Este un instrument de planificare al managerului, care prescrie termene explicite pentru fiecare incrementare a versiunilor sistemului si face o legatura intre versiuni si planificarea testelor. Un bun plan permite trasarea corespondentelor de la fiecare versiune, inapoi spre cerintele aferente, exprimate sub forma de scenarii.

Criteriile de testare. Cuprind un plan al testarilor si, unde este posibil, setul efectiv de scripturi de test.
O reevaluare a riscurilor.

Activitati:
Exista 3 activitati de baza, al caror scop este de a stabili un schelet al solutiei problemei si de a adopta decizii tactice pentru implementare. Daca, in sens larg, macro-procesul unui proiect OO cuprinde detalierea succesiva a arhitecturii, atunci proiectarea poate fi considerata ca prima iteratie din producerea arhitecturii.
In ceea ce priveste durata, pentru proiecte cu ciclu de viata de 1 an, proiectarea tine cam 1, maximum 2 luni.

Planificarea arhitecturii. Este activitatea centrala a fazei de proiectare si are drept scop stabilirea structurii de baza a sistemului. Este fundamentala pentru stabilirea integritatii conceptuale a sistemului. Ea implica crearea (inventarea) straturilor si a partitiilor intregului sistem si realizeaza o descompunere atat logica (la nivel de categorii de clase) cat si fizica (la nivel de module si alocare a procesoarelor).
In aceasta faza obiectivele care trebuie avute in vedere sunt:

interfetele;

distribuirea responsabilitatilor;

identificarea sabloanelor de proiectare.

Aceasta activitate cuprinde urmatoarea secventa de pasi:

Se considera grupurile de functiuni evidentiate in produsele de la analiza si se aloca grupurile respective la straturile si partitiile sistemului. Functiile care se bazeaza una pe alta vor face parte din straturi diferite.
In acest pas actiunile care se desfasoara sunt de pura creatie si ele sunt influientate de 3 factori:

sabloanele arhitecturale primare; de ex. pentru un sistem de timp-real se poate opta intre arhitecturi bazate pe frame-uri si cele bazate pe mesaje;

identificarea partilor cu probabilitate mare de modificare, care vor trebui grupate separat;

o intelegere a alternativelor tehnologice disponibile, ceea ce permite utilizarea unor componente gata construite.

Se valideaza arhitectura prin crearea unei versiuni executabile care satisfac partial semantica catorva dintre scenariile interesante.

Se evalueaza partile bune si slabe ale arhitecturii, identificandu-se riscurile asociate cu fiecare interfata arhitecturala.

Proiectarea tactica. Implica adoptarea unor decizii tactice privind principalele mecanisme si idiomuri care vor fi utilizate. Se ia in considerare totodata posibilitatea de a evita scrierea de cod prin reutilizarea sau adaptarea unor cadre existente.

Planificarea versiunilor. De regula aceasta activitate presupune studiul scenariilor, gruparea si ordonarea lor in functie de importanta si asocierea cu fiecare grup de scenarii a cate unei versiuni, astfel incat versiunea finala sa coincida cu produsul finit.