Ingineria Programarii - Arhitectura unei Aplicatii Orientata pe Obiecte

Arhitectura unei Aplicatii Orientata pe Obiecte

Cele "4+1" Proiectii ale Arhitecturii Software
Arhitectura software nu este ceva uni-dimensional, ci se compune dintr-un numar de proieictii distincte, fiecare din ele modeland o anumita proiectia arhitecturala. Figura de mai jos reprezitna diferitele proiectii ale arhitecturii software. In aceasta lucrare vom puncta elementele centrale ale fiecarei perspective, impreuna cu notatia UML utilizata pentru reprezentarea deciziilor arhitecturale ce corespund fiecarei perspective.

-poza

Proiectia Logica (Logical View)
Aceasta perspectiva arhitecturala se refera la cerintele functionale ale sistemului - adica ce anume trebuie sa contina sistemul in termenii serviciilor oferite utilizatorilor. Perspectiva logica este redata prin intermediul diagramelor de clasa, care contin clasele din care este format sistemul impreuna cu relatiile care reprezinta abstractiiunile-cheie ale sistemului aflat in procesul de dezvoltare. Majoritate notatiei UML este folosita pentru acest tip de diagrame (ex. clase, pachete, relatii de asociere, agregaere etc). Vom discuta toate aceste aspecte in ultima lucrare.

Mecanisme-Cheie. Proiectare Tactica.
Aceasta perspectiva arhitecturala este abordata la inceputul fazei de elaborare pentru definirea claselor si a pachetelor care reprezinta abtractiunile fundamentale ale domeniului problemei. Pe masura ce proiectul evolueaza, alte clase si pachete vor fi adaugate modelului pentru a reflecta deciziile luate cu privire la mecanismele-cheie ale sistemului. Un mecanism-cheie este o decizie cu privire la anumite standarde, politci si practici uzuale. Selectia unui mecanism-cheie pentru un sistem este adesea considerata o proiectare tactica. "O proiectare tactica deficitara poate ruina si cea mai profunda arhitectura, ceea ce inseamna ca echipa de proiectare trebuie sa elimine acest risc prin identificarea explicita a politicii cheie a proiectului". Cateva dintre mecanismele-cheie cele mai uzuale sunt: alegerea unui limbaj de implementare, stocarea persistenta a datelor, aliura interfetei cu utilizatorul, tratarea erorilor, mecanisme de comunicare, mecanisme de distribuire si migrare a obiectelor.

Astazi exista o multime de solutii consacrate - tipare (patterns) - ce pot fi folosite pentru a implementa deciziile mecanismelor-cheie pentru sistemele pe care le dezvoltam. Este extrem de recomandabil ca inainte de a ne "avanta" spre gasirea unor noi solutii, sa vedem daca nu am putea folosi una din aceste solutii consacrate.

Exemple de Mecanisme-Cheie
   -limbajul folosit pentru implementare
   -GUI
   -clasele persistente (shadow classes) - pachet DB pt shadow classes
   - tratarea exceptiilor
   - alegerea unei biblioteci de clase generale

Proiectia Modulara (Compozitionala, Structurala) (Component View)
Aceasta perspectiva arhitecturala se ocupa cu organizare pe module a software-ului in cadrul unui mediu de dezvoltare dat. Proiectia modulara are in vedere realizarea cerintelor legate de usurarea procesului de dezvoltare si a administrarii software-ului, precum si facilitarea reutilizarii in contextul constrangerilor impuse de un anumit limbaj de implementare sau un anumit instrument de dezvoltare. Elementele de modelare corespunzatoare acestei perspective sunt pachetele si componentele impreuna cu conexiunile dintre acestea. Acestea sunt reprezentate in notatie UML dupa cum urmeaza:

Pachete. Organizarea Ierarhica.
In aceasta perspectiva arhitecturala, un pachet reprezinta o partitionare fizica a sistemului. Pachetele in perspectiva compozitionala sunt adesea numite subsisteme. Pachetele sunt origanizate intr-o ierarhie de nivele, in care fiecare nivel are o interfata bine definita. Faptul ca un sistem orientat pe obiecte tinde sa fie un sistem organizat pe mai multe nivele este un lucru natural. Nivele cele mai des intalnite in majoritate sistemelor sunt (de sus in jos):

Interfata Utilizator
Pachete Specifice Aplicatiei
Pachete Dedicate Reutilizabile
Mecanisme-cheie
Pachete Specifice pentru Hardware si pentru Sistemul de Operare

Corespondenta intre Proiectia Logica si cea Modulara
Informatia din proiectia logica este conecta la informatia din proiectia modulara prin maparea pachetelor logice in pachete fizice. In general, un pachet din perspectiva logica corespunde unui pachet din proiectia modulara. Uneori insa aceasta mapara unu-la-unu nu este posibila (de ex. un pachet logic trebuie impartit in doua pachete fizice datorita faptului ca este achizitionat de la doi furnizori diferiti, sau doua pachete logice se contopesc intr-un singur pachet fizic pentru o mai buna comunicare intre obiecte etc.)

Exemplul Sistemului de Inregistrare
Proiectia modulara se reprezinta prin intermediul unor diagrame de componente. Pentru fiecare sistem exista o diagrama principala de componente in care de obicei sunt redate pachetele (subsistemele) definite pentru acel sistem. Avand in vedere si ierarhia de nivele amintita mai sus, aceasta diagrama arata astfel pentru exemplul nostru:

Proiectia Run-Time (Procesuala, de Rulare) (Process View)

Aceasta perspectiva arhitecturala este focalizata asupra implementarii structurii sistemului la nivel run-time. Aceasta perspectiva ia in considerare cerinte cum ar fi performanta, fiabilitatea, scalabilitatea, integritatea, sincronizarea, management-ul sistemului. Pentru a vizualiza componentele run-time si executabile care compun sistemul care a fost dezvoltat sunt utilizate diagramele de componente. Componentele sunt legate intre ele prin relatii de dependenta. Componentele run-time arata maparea claselor in biblioteci cum sun applet-urile Java, componentele Active X, si bibliotecile dinamice (DLL). Componentele executabile indica interfetele si relatiile de dependenta intre executabile.

In Rational Rose informatia despre perspectiva procesuala este realizata prin intermediul diagramelor realizae in sectiunea Component View. Componentele (run-time sau executabile) sunt atasate pachetelor care reprezinta subsistemul de care ele apartin. Diagramele sunt create pentru reprezenta dependentele intre diferitele tipuri de componente din sistem.

Proiectia Run-Time in Problema Inregistrarii Cursurilor
Decizia proiectantilor sistemului de inregistrare a fost aceea de a utiliza doua biblioteci run-time (DLL) - una legata de obtinerea informatiilor despre cursuri si oferte de cursuri, si una pentru informatii legate de baza de date. Aceasta decizie a fost luata avand in vedere faptul ca structura cursurilor si strategia de alegere a bazei de date sunt cele mai predispuse la schimbari. Facandu-le biblioteci, in versiunile ulterioare doar aceste biblioteci vor trebui inlocuite pentru implementarea schimbarilor. Deasemenea s-a decis crearea a trei fisiere executabile - Registrator.exe; Student.exe si Profesor.exe. Intre executabile nu exista nici o legatura. Diagrama de componente pentru executabilul Profesor.exe este redata mai jos:

Proiectia Logistica (Topologica, de Dispunere) (Deployment View)

Aceasta perspectiva arhitecturala implica maparea sistemului software pe nodurile de procesare. Perspectiva logistica arata configuratia elementelor de procesare run-time si procesele software care "vietuiesc" in ele. Aceasta perspectiva are in vedere cerinte cum ar fi scalabilitatea, performanta de timp sau fiabilitatea. Reprezentarea acestei perspective se realizeaza prin diagrame logistice care se compun din diferite noduri de procesare impreuna cu conexiunile lor in sistem. In UML un nod de procesare este reprezentat astfel:

Nodurile sunt conectate intre ele prin intermediul unor relatii de asociere care indica cai de comunicare intre noduri. Procesele software care ruleaza intr-un nod sunt redate ca text atasat unui nod sau grup de noduri.

Exemplul
In figura de mai jos este prezentat exemplul unei astfel de diagrame logistice pentru exemplul

Proiectia Use-Case (Comportamentala, Behaviorala, Functionala) (Use Case View)

Comportamentul unui sistem aflat in curs de dezvoltare, adica functionalitatea pe care sistemul trebuie sa o ofere, este documentata prin intermediul acestui model care ilustreaza functiile pe care sistemul trebuie sa le indeplineasca (use-cases), vecinatatea sistemului (actorii) si relatiile dintre aceste functii si actori (diagramele use-case). Cel mai important rol al modelului use-case este acela de comunicatie. Acest model ofera mijlocul de comunicare ce poate fi utilizat atat de catre beneficiarii sau utilizatorii sistemului cat si de catre dezolvatorii sai pentru a discuta comportarea si functionalitate sistemului.

Actorii
Actorii nu sunt parte a sistemului - ei reprezinta orice sau pe oricine care trebuie sa interactioneze cu sistemul. Un actor poate sa introduca informatii in sistem, sa receptioneze informatii din sistem, fie sa faca ambele operatii. In mod normal actorii sunt detectati din enuntul problemei si pe baza discutiilor purtate cu beneficiarii sistemului sau cu experti in domeniu. Urmatoarele intrebari pot fi utile pentru identificarea actorilor dintr-un sistem:

Cine este interesat de o anumita cerinta ?
Cine este beneficiarul utilizarii sistemului?
Cine furnizeaza informatii sistemului, cine utilizeaza aceasta informatie si cine elimina informatii din sistem?
Care sunt resursele externe pe care le foloseste sistemul?

Cum Identificam Corect Actorii?
Trebuie avuta mare grija atunci cand este vorba de identificarea actorilor pentru un sistem. Aceasta identificare se desfasora intr-o maniera iterativa, rareori lista initiala de actori fiind si ce finala. Se pot utiliza urmatoarele "reguli de aur":

Regula 1: Doi actori care utilizeaza sistemul in acelasi fel reprezinta in fapt un singur actor.

Regula 2: Daca fiecare functionalitate necesara unui nou actor (candidat) se suprapune peste functionalitatea necesara unui alt actor deja identificat, vom renunta la introducerea noului actor. Cu alte cuvinte, nu vom atribui cate un actor pentru fiecare rol pe care o persoana il poate juca in raport cu sistemul.

TEMA: Sa se identifice actorii din proiectul de inregistrare a cursurilor justificandu-se alegerea lor! Pe baza regulilor de mai sus, vom considera un student-preparator ca fiind un actor distinct sau nu?

Use-Cases
Un use-case modeleaza un dialog intre un actor si sistem. Use-case-urile reprezinta functionalitatea sistemului, adica facilitatile oferite de sistem unui actor. Colectia use-case-urilor pentru un sistem reprezinta totalitatea modalitatilor in care un sistem poate fi utilizat. Definitia formala a unui use-case este: Un use-case este o secventa de tranzactii efectuate de sistem care produc rezultate masurabile pentru un anumit actor.

Urmatoarele intrebari ar putea fi utile in identificarea UseCase-urilor pentru un sistem:

Care sunt sarcinile fiecarui actor?
Exista un actor care sa creeze, sa stocheze, sa modifice, sa stearga sau sa citeasca informatii din sistem?
Care sunt UseCase-urile prin care se vor crea, stoca, modifica, sterge si citi aceste informatii?
Pot fi indeplinite toate cerintele functionale prin intermediul UseCase-urilor pe care le-am definit deja?
Exista vreun actor care trebuie sa informeze sistemul asupra unor schimbari externe subite?
Exista vreun actor care trebuie informat de catre sistem asupra anumitor evenimente care se produc in sistem?

Notatia UML pentru un actor si respectiv pentru un use-case sunt cele redate mai jos:

Cum Identificam Corect un Use-Case?
Una dintre problemele principale care apar in alegerea unui use-case este nivelul de detaliu ce se regaseste intr-un use-case. Cu alte cuvinte, cat de mic sau de mare ar trebui sa fie? Nu exista un raspuns univoc la aceasta intrebare. O "regula de aur" ar putea fi aceasta:

Regula: Un use-case reprezinta o parte de functionalitate completa. Un use-case trebuie sa ofere ceva util unui actor.

O alta problema ar fi cum sa tratam acele functionalitati care desi diferite, apartin totusi impreuna. O regula ar putea fi:

Regula: Daca mai multe functionalitati sunt declansate de un acelasi actori si manipuleaza aceleasi entitati din sistem, acele functionalitati formeaza impreuna un use-case unic.

TEMA: Pe baza enuntului proiectului de inregistrare a cursurilor sa se identifice use-case-urile existente in acest sistem. In conformitate cu regulile de mai sus, vom considera adaugarea, stergerea si modificarea unui curs (operatii efectuate de catre Registrator) ca fiind use-case-uri distincte, sau nu?

Tipuri de Relatii In Proiectia Use-Case
Intre un actor si un use-case poate exista o relatie de asociere. Acest tip de asociere este adesea referita ca fiind o asociere de comunicare intrucat reprezinta comunicarea dintre un actor si un use-case. O astfel de asociere poate fi navigabila in ambele directii (de la actor la use-case si invers), sau poate fi navigabila numai intr-o directie. Sensul de navigare pentru o astfel de asociere indica cine a initiat comunicarea. In figura de mai jos, actorul comunica cu doua use-case-uri, in ambele cazuri actorul initiind comunicarea.

In figura anterioara mai putem observa ca intre doua use-case-uri pot exista doua tipuri de relatii: uses si extends. Mai multe use-case-uri pot avea in comun anumite "blocuri" de functionalitate. Aceasta functionalitate comuna este prin urmare plasata in use-case-uri separate, pentru a se evita fi doumentarea repetata a acelei funcionalitati. Relatia de acest tip a fost denumita uses.

In contrast cu aceasta, relatia de tip extends este utilizata pentru a indica: un comportament optional sau un comportament care se va executa doar in anumite conditii.

Stereotipuri
Limbajul de modelare UML are definit un conceput numit stereotip, care permite extinderea elementelor fundamentale de modelarea ale limbajului pentru a crea noi elemente de modelare. Prin urmare, stereotipurile permit UML-ului sa aiba definite un set minimal de simboluri care pot fi extinse acolo unde este necesar pentru a oferi un instrument adecvat si semnificativ de comunicare pentru sistemul particular care se dezvolta. Numele unui stereotip este inclus intre simbolurile "<<" si ">>" ca in figura de mai sus. Mai sus, folosirea stereotipurile a fost necesar in contextul relatiilor dintre use-case-uri pentru a face distinctie intre relatia de tip uses si cea de tip extends, intrucat ambele sunt reprezentate prin intermediul unei sageti de generalizare.

Use-Case Diagrams
O diagrama use-case este o reprezentare grafica a unora sau a tuturor actorilor si use-case-urilor precum si a interactiunii dintre ele identificate pentru sistemul aflat in curs de dezvoltare. Pentru fiecare sistem se defineste in mod uzual o diagrama use-case principala (Main Use-Case Diagram) care reprezinta o imagine a limitelor sistemului (indicate de actori) precum si a functionalitatilor majore oferite de sistem (indicate prin use-case-uri). Alte diagrame use-case pot fi create pe masura ce sunt necesare. Cateva exemple ar putea fi:

O diagrama ce contine toate use-case-urile in care este implicat un anumit actor
O diagrama care sa reprezinte toate use-case-urile ce sunt implementate intr-o iteratie
O diagrama indicand un use-case si toate relatiile sale

Probleme
Se cere sa se identifice si apoi sa se modeleze in Rational Rose actorii, use-case-urile si relatiile aferente, pentru un sistem de rezervare a biletelor CFR care are urmatoarele cerinte:
    1. Calatorii vor avea acces on-line la sistem, pentru a consulta mersul trenurilor, in speta oferta de trenuri intre doua statii date.
    2. Casierii vor accesa sistemul pentru a realiza, daca este posibil, rezervari la un anumit tren, pentru o anumita destinatie si un anumit numar de locuri. In cazul efectuarii rezervarii, sistemul va calcula costul biletului, pe baza unor tabele de tarife. Casierul va confirma plata, iar sistemul va tipari biletele de calatorie.
    3. Gestionarea bazei de date cu informatii legate de mersul trenurilor si tabelele de tarife va fi efectuata de un operator central. Calatorii, prin intermediul casierilor, vor avea posibilitatea sa renunte la rezervari, caz in care sistemul va trebui sa calculeze suma de rambursat; aceasta va depinde de momentul renuntarii (inainte sau dupa plecarea trenului).

Se lasa la latitudinea proiectantilor alegerea informatiilor care trebuie introduse/extrase in cazul fiecarui caz de utilizare, precum si identificarea unor cazuri de exceptie posibile.

Bibliografie

[Quatr98] T. Quatrani - "Visual Modeling with Rational Rose and UML", Addison-Wesley, 1998
[Booch95] G. Booch - "Object Solutions", Addison-Wesley, 1995

Hosted by www.Geocities.ws