Curs 10 - Arhitecturi de dezvoltare enterprise

Introducere
Arhitectura software a unui program sau sistem de calcul este reprezentata de structura
sistemului, ce cuprinde elementele software, proprietatile vizibile ale acestor elemente si
relatiile dintre ele.
Elementele apar, in mod obisnuit, in cadrul arhitecturii ca componente software high level sau
module sistem.
Proprietatile externe vizibile ale unui element descriu functionalitatile pe care un element le
expune altor elemente, precum serviciile oferite, informatiile de performanta, implicatiile de
securitate, etc. Ele sunt descrise sub forma interfetelor componentei.
Arhitectura unui sistem software necesita multiple structuri din perspective diferite, numite si
view-uri, pentru a cuprinde elementele si proprietatile pe care le poseda. Design-ul OO este
concentrat pe un view static al sistemului care identifica componentele software si
specificatiile de la nivelul interfetei.
Dintr-o perspectiva practica arhitectura poate fi considerata ca un plan abstract ce descrie
principiile esentiale si deciziile sistemului software, incluzand componentele esentiale si
interactiunile lor. copul crearii arhitecturii intr-un proiect de dezvoltare software este acela
de a facilita implementarea si pentru a ne asigura ca produsul intruneste toate cerintele.
!rei dintre caracteristicile importante, de care arhitectura unui sistem soft trebuie sa tina cont,
sunt"
cala, care indica cantitatea necesara de resurse pentru a implementa si suporta
sistemul.
Distributia, care se refera la rularea intr-o retea, pe servere si middleware distribuite.
#ntr-un sistem distribuit, abilitatea de a alege locul in care componentele sunt
localizate si cum acestea comunica revine in sarcina arhitectului de sistem.
ecuritatea, care se refera atat la masurile de securitate obisnuite, prote$area accesului
neautorizat, etc, cat si la normative de securitate precum O% &arbanes-Oxle' Act of
())(* sau +#PPA &+ealth #nsurance Privac' and Portabilit' Act of ,--.*.
Rolul si responsabilitatile unui arhitect
/rearea si validarea unei arhitecturi sunt activitati esentiale care asigura calitatea unui produs.
#n faza de inceput a realizarii unei arhitecturi, arhitectul analizeaza cerintele si creaza modelul
use-case pentru a prinde cerintele functionale, cerintele la nivelul de servicii &01* si
cerintele non-functionale. #n aceasta faza arhitectul lucreaza cu pro$ect managerul pentru a
identifica resursele cele mai potrivite hard, soft si de personal pentru proiectare si validare.
!ot in aceasta faza arhitectul lucreara cu artefactele produse in analiza cerintelor pentru a
identifica entitatile semnificative si relatiile dintre ele. Aceasta va crea Domain 2odel. Pe
baza acestui model arhitectul defineste structura tehnica globala a sistemului. /eea ce rezulta
este un ADD &Architecture Description Document*.
#n faza de elaborare arhitectul rafineaza ADD prin identificarea componentelor high-level ale
aplicatiei si serviciile reutilizabile selectand tehnologiile potrivite utilizate pentru
implementarea acestora. 3alidarea acestora se face intr-un prototip ce permite testari.
1esponsabilitatile unui arhitect sunt"
!ehnice"
o Arhitectura trebuie sa raspunda cerintelor de calitate si sa reduca riscurile
produsului
o #dentificarea use case-urilor arhitectural semnificative, care sunt aspecte ale
sistemului ce au cel mai inalt grad de risc asociat. #dentificarea se face, in
principiu, pe baza urmatoarelor cerinte" concurenta, sincronizare, legac'
integration
o 1ecomandarea tehnologiilor necesare si framewor4-uri utilizate de proiect
o Dezvoltarea sau ghidarea dezvoltarii prototipului arhitectural.
De management"
o #ntelegerea costurilor, arhitectul trebuie sa furnizeze informatii persoanelor
responsabile de buget pentru ca acestea sa ia decizii corecte
o 5estiunea comunicatiilor cu ceilalti membri ai echipei pentru clarificarea si
rafinarea cerintelor utilizatorului sau in folosirea tehnologiilor alese
Domain model si ADD formeaza planul arhitectural al sistemului software. Planul trebuie sa
fie orientat spre calitatea serviciilor cerute de sistem in detrimentul functionalitatii. Acesta
contine mai multe view-uri. /el mai cumoscut model este modelul 67,, care cuprinde aceste
cerinte"
0ogical view, spri$ina cerintele functionale si este reprezentat de modelul obiect, care
descrie descompunerea sistemului in module software abstracte
#mplementation &development* view, spri$ina gestiunea softului, descrie cum sunt
organizate modulele software in mediul de dezvoltare
Deplo'ment &ph'sical* view, spri$ina desfasurarea si instalarea sistemului software,
furnizeaza o reprezentare a amplasarii hardware si protocoalelor de comunicare,
mapeaza modulele software nodurilor hardware
Process view, spri$ina cerintele non-functionale, descrie concurenta si distributia
functionalitatii in procese precum si modul de comunicare a acestora
8se case view, prezinta o abstractizare a cerintelor si stabileste criterii de testare
pentru prototipurile arhitecturale
Prototipul arhitectural este un model al proiectului arhitectural. Prototipul se bazeaza pe cele
mai semnificative use case-uri carora li se creaza implementari pentru"
A demonstra viabilitatea tehnologiilor si produselor prescrise in planul arhitectural
A testa cerintele de calitate a serviciilor
A prezenta un view concret asupra modelului, standardelor, etc
Membrii teamului de dezvoltare
Arhitectura poate fi creata de un individ sau de mai multi oameni organizati intr-o echipa. #n
orice caz, planul arhitectural trebuie pus in practica de o echipa formata din urmatorii membri"
0eader-ul echipei, este un liant intre s'stem designer si echipa de dezvoltare
2odelatorul enterprise, creaza business-ul aplicatiei. 2ai este cunoscut ca" enterprise
modeler, business anal'st, domain modeler sau s'stem anal'st
Arhitectul de sistem, imagineaza design-ul si implementarea pentru hardware si
servere, furnizeaza un mediu de dezvoltare ce ofera scalabilitate, incredere si un grad
inalt de disponibilitate
Arhitectul de aplicatie, imagineaza design-ul si implementarea pentru software-ul de
aplicatie si pentru integrarea componentelor. 9urnizeaza o structura a aplicatiei
Designer-ul de sistem, foloseste planul arhitectural pentru a crea un plan de design
mult mai detaliat al infrastructurii aplicatiei
Designer-ul de aplicatie, foloseste planul arhitectural pentru a crea un plan mult mai
detaliat pentru a fi implementat de dezvoltatorii de soft
Dezvoltatorul de soft, implementeaza design-ul arhitectural
!esterul, testeaza partile din design si raporteaza potentialele erori de arhitectura
1esponsabilul cu calitatea &:A*, testeaza unitatile complete pentru a le verifica
functionalitatea
/onfiguratorul, configureaza aplicatia pentru un anume domeniu de operare
Alte parti interesate, au interes in produs si includ utilizatori, clienti si membri ai
echipei de dezvoltare
Modelarea arhitecturii folosind UML (the Unified Modelin Lanuae!
820 este un standard industrial pentru vizualizarea, descrierea si documentarea sistemelor
software. 9urnizeaza un set de diagrame pentru a modela componentele sistemului si
interactiunea lor"
Diagramele de clasa, ilusteaza clasele din sistem si relatiile dintre aceste clase,
precum asocierea si mostenirea. unt folosite pentru a descrie domain model
Diagramele de interactiune, sunt menite sa prinda interactiunile dinamice si
comunicarea intre componentele sistemului. /ele mai utilizate sunt"
o Diagramele de comunicare numite si collaboration diagrams, evidentiaza
legaturile de date intre componentele in interactiune
o Diagramele de secventa, evidentiaza schimbul de date de-a lungul timpului
Diagramele de componente, evidentiaza componentele ma$ore ale softului si cum
sunt ele integrate in sistem. Aceste diagrame pot contine componente soft care nu
sunt orientate pe obiecte precum legac' code si documente web
Diagrama de desfasurare, evidentiaza nodurile hard si aran$area lor in sistem. Este
utila pentru a evidentia cum este configurat un sistem distribuit. #n arhitectura
componentele soft pot fi afisate in interiorul nodurilor hardware pentru a evidentia
cum sunt ele desfasurate
Diagrame de pachet, ne permit sa grupam diversele constructii create in model. 0a
nivelul arhitecturii diagramele de pachet pot fi utilizate pentru a descrie cum
produsele hardware si software, tehnologiile si componentele aplicatiei sunt
organizate pe la'ere
Arhitectura si desin
Diferentele intre arhitectura si design sunt date din urmatoarele puncte de vedere"
;ivelul abstract"
o Din punct de vedere al arhitecturii este mare si cuprinzator, dar se pune accent
pe putine detalii
o Din punct de vedere al design-ului este mic si specific cu accente pe detalii
1ezultatele"
o Din punct de vedere al arhitecturii planurile de sistem si subsistem si
prototipurile arhitecturale
o Din punct de vedere al design-ului, design-ul componentelor si specificatii de
cod
Domeniul de interes"
o Din punct de vedere al arhitecturii cerintele non-functionale si managementul
riscului
o Din punct de vedere al design-ului cerintele functionale
8rmatoarele caracteristici sunt esentiale pentru calitatea unui design bazat pe componente"
Abstractizarea, se concentreza pe detaliile arhitectutale semnificative ale unei
componente. /elelalte detalii sunt date in faza de design. Abstractizarea a$uta echipa
de dezvoltare sa modularizeze componentele unui sistem. #n plus, permite despartirea
tas4-urilor astfel incat echipa sa poata lucra in paralel
#ncapsularea, spri$ina abstractizarea prin ascunderea detaliilor ce au fost ignorate in
timpul definirii abstractizarii
/oeziunea, spri$ina abstractizarea si incapsularea prin faptul ca asigura ca toate
detaliile ascunse prin incapsulare contribuie la definitia abstractizarii
/uplarea, masoara gradul de conexiune al componentelor. #n interiorul incapsularii
cuplarea este folositoare deoarece se adauga coeziunii abstractizarii. #n exterior este
un obstacol deoarece reduce flexibilitatea si reutilizarea componentelor
"abloane arhitecturale
8n sablon &pattern* descrie o problema de design ce apare periodic intr-un context si ii aduce
o solutie. 0a fel ca sabloanele de design pentru rezolvarea problemelor de design in cazul
OOP, sabloanele arhitecturale sunt utile pentru creerea arhitecturii software, prin furnizarea
unei structuri bine definite. /ele mai intrebuintate sabloane de arhitectura in enterprise sunt"
0a'ers pattern, care structureaza aplicatia astfel incat sa poata fi descompusa in
grupuri de subtas4-uri si fiecare grup reprezinta un nivel particular de abstractizare.
Acest sablon este folosit fie pentru izolarea dependentelor intr-un sistem bazat pe
nivele de servicii sau pentru a limita vizibilitatea componentelor de la nivelul
aplicatiei. Exemple" modelul de retea O# &Open 'stem #nterconnection* si
arhitectura multi-tiered a aplicatiilor enterprise. 0a'ers pattern a$uta la stabilirea
nivelurilor logice si a straturilor tehnologice intr-un sistem distribuit. pre exemplu,
putem folosi acest sablon pentru a asigura flexibilitatea arhitecturii. Daca consideram
o baza de date in care se produc modificari frecvente de structura folosim un database
abstraction la'er in locul claselor entitate obisnuite.
23/ pattern, separa arhitectura in trei module diferite" prezentarea datelor, procesare
si inmagazinare.
Metodoloia "un#one Architecture
/reata initial la sfarsitul anilor -) s-a dezvoltat pe baza 1ational 8nified Process &18P* si
incorporeaza best practices pentru a descrie un proces ce este potrivit dezvoltarii aplicatiilor
enterprise. un!one A2 introduce un model tridimensional cu cele mai importante probleme
ale aplicatiilor enterprise. Aceste dimensiuni sunt" tiers, la'ers si s'stemic <ualities.
!iers &nivelele*" descriu cum o aplicatie distribuita este descompusa in module pentru a
reduce cuplarea si a creste flexibilitatea sistemului. Aceasta permite modificarea fiecarui nivel
fara a afecta celelalte nivele. O aplicatie enterprise are urmatoarele nivele"
;ivelul client, contine acele functiuni ale aplicatiei care sunt clienti ai serviciilor
implementate in aplicatie. pre exemplu" browsere web, clienti standalone =ava, clienti
ai serviciilor web
;ivelul prezentarii web, contine modulele aplicatiei ce furnizeaza servicii clientilor
folosind tehnologii web. 2odulele acestui nivel receptioneaza cereri prin metode
+!!P si trimite raspunsuri inapoi la client prin limba$e mar4up precum +!20 sau
%20
;ivelul business logic, contine module ale aplicatiei ce implementeaza principiile de
lucru ale aplicatiei
;ivelul de integrare, contine modulele si tehnologiile ce asista alte module in
conectare si comunicarea cu nivelul resurselor enterprise
;ivelul resurselor enterprise, contine sisteme si module ce furnizeaza functionalitatea
aplicatiei. #n general acestea sunt module non =ava, precum 5>D-urile
0a'er-ele, descriu cum o aplicatie distribuita este implementata in infrastructura platformei,
ce cuprinde" middleware, sistemul de opearare, hardware si echipamente de retea. Avem
urmatoarele la'ere"
Application la'er, contine toate modulele necesare aplicatiei. #n principiu ma$oritatea
dezvoltarii de cod se face in acest la'er
3irtual platform la'er, contine interfetele cu modulele middleware din application
infrastructure la'er. Aceste interfete sunt deseori standardizate. Acest la'er furnizeaza
o puternica decuplare intre application la'er si infrastructura din application
infrastructure la'er
Application infrastructure la'er contine acele parti ale middleware-ului ce furnizeaza
infrastructura operationala si de dezvoltare pentru aplicatie. Exemple" servere de
aplicatie si 5>D-uri
Enterprise services la'er contine parti ale sistemului de operare si retelei
/ompute and storage la'er contine partea de hardware
;etwor4 infrastructure la'er, contine infrastructura fizica a retelei" rutere, switch-uri,
etc
'stemic <ualities" descrie modul in care aplicatia enterprise atinge standardele de calitate
cerute.
/aracteristicile lui un!one A2 includ"
Dezvoltare orientata spre use-case, adica sistemul este construit dupa modul in care
este utilizat. Avem urmatoarele notiuni"
o 8se case" interactiunea dintre un actor si sistemul construit
o Actor" un user, un alt sistem sau un dispozitiv extern. istemul raspunde la
interactiunile actorului prin executarea unei secvente de actiuni
Dezvoltare repetata si elementara, adica proiectul este impartit in subproiecte mai mici
gestionate pe baze individuale. 9iecare subproiect are propriul ciclu de viata. 9iecare
subproiect este baza urmatorului subproiect in procesul de dezvoltare. Dezvoltare
elementara inseamna ca o parte a procesului de dezvoltare urmareste sa incheie un set
de use-case-uri. Astfel, orice rezultat elementar este un mini-release al produsului,
sporind functionalitatea sistemului. Dezvoltarea repetata inseamna ca procesul de
lucru se va incheia cu o dezvoltare finala. O iteratie va fi un pas intr-un flux
Dezvoltare centrata pe arhitectura, adica definirea cerintelor sistemului necesita
multiple reprezentari
Dezvoltare orientata pe serviciu, adica aplicatia este organizata ca o colectie de
servicii reutilizabile. Aceste servicii expun o interfata de acces ce ascunde
implementarea concreta
Dezvoltare orientata spre sabloane. un!one A2 include elemente de 23/, PA/
&Presentation Abstraction /ontrol*, 0a'ers si !iers
"$stemic %ualities
1eprezinta proprietati ale unui sistem ce stabilesc calitatea serviciilor pe care sistemul le poate
livra. /alitatile sistemice determina design-ul sistemului, de aceea trebuie sa prioritizam
cerintele astfel incat sa cream o arhitectura ce minimizeaza constrangerile acestor calitati.
/alitatile sistemice sunt uneori grupate in categorii dependent de cum sunt observate sau cum
au ele efect. 5rupurile calitatilor sistemice sunt"
2anifest <ualities, sunt acele calitati evidente pentru utilizator"
o Performanta, o masura a timpului de raspuns asa cum este vazut de utilizator
o #ncredere, o masura a probabilitatii ca datele sa fie corecte, atat in depozitul
de date cat si in rezultatele prezentate utilizatorilor
o Disponibilitate, o masura a probabilitatii ca sistemul sa opereze o incercare a
utilizatorului de a-l folosi pina cand va termina de procesat cererea utilizator
o 8tilizabilitate, o masura a abilitatii ca un utilizator sa invete sa utilizeze
sistemul pentru a efectua un tas4
Operational <ualities sunt evidente atunci cand sistemul ruleaza, dar nu sunt evidente
unui anumit autilizator. Acestea includ"
o !ranzitarea, o masura a cantitatii de munca ce poate fi efectuata intr-un
anumit timp
o Administrarea, o masura a interventiei umane, precum bac4up-urile necesare
pentru a mentine sistemul in functiune
o ecuritatea, o masura a increderii ca datele sa fie prote$ate la deschidere
neautorizata sau modificare
o ervibilitatea, o masura a cantitatii de munca necesare pentru intretinerea
non-rutina, precum inlocuirea unei componente
o !estabilitatea, o masura a cantitatii de munca necesare pentru identificarea si
izolarea unei erori in sistem
Developmental <ualities, afecteaza modul in care este construit sistemul. Aceste
calitati se manifesta doar in faza de dezvoltare si sunt irelevante in momentul
evolutiei sistemului"
o 1ealizabilitatea, o masura a probabilitatii ca o functionalitate sa fie
implementata cu succes
o Planificabilitatea, o masura a increderii in plan si in costurile estimate
Evolutionar' <ualities, sunt in legatura cu comportamentul sistemului atunci cand
este modificat sau actualizat"
o calabilitatea, inversul unei masuri a muncii si costului necesar pentru a
modifica sistemul astfel incat sa furnizeze o tranzitare mai buna
o #ntretinerea, inversul unei masuri a muncii necesare eliminarii bug-urilor
o Extensibilitatea, inversul unei masuri a muncii si costului pentru adaugarea de
noi functionalitati sistemului
o 9lexibilitatea, inversul unei masuri a muncii si costului necesar efectuarii de
schimbari sitemului
o 1eutilizabilitatea, o masura a portabilitatii, adica dandu-se un nou proiect cu
cerinte asemanatoare o parte a sistemului poate fi integrat in noul sistem
o Portabilitatea, inversul unei masuri a muncii sau costurilor pentru migrarea
componentelor catre o noua platforma
/a parte a evaluarii trebuie sa ne gandim la aspectul brut al arhitecturii dat de sase variabile
independente numite si dimensiuni"
/apacitate, adica dimensiunea puterii brute dintr-un element, procesor mai puternic,
conexiuni la retea mai rapide sau capacitatea mediului de stocare. Denumiri
alternative ale capacitatii sunt" height sau horsepower
1edundanta, dimensiunea in care sistemele multiple lucreaza la acelasi $ob, spre
exemplu incarcarea pe servere. 1edundata este cunoscuta si sub numele de width
2odularitate, dimensiunea in care impartim o problema in elemente separate si le
raspandim pe mai multe sisteme. 2odularitatea se mai numeste si depth, adica cat de
adanc trebuie sa patrundem in sistem pentru a obtine datele de care avem nevoie. /u
cat aceasta dimensiune este mai mare cu atat avem nevoie de mai multe componente
de lucru
!oleranta, timpul disponibil pentru a indeplini o cerere a utilizatorului. !oleranta este
perceputa ca performanta globala a sistemului
3olumul de munca, munca efectuata la un anumit punct dinauntrul sistemului
Eterogenitate, diversitatea tehnologiilor folosite de sistem sau subsisteme
8rmatorul tabel ilustreaza impactul a trei dimensiuni &capacitate, redundanta si modularitate*
in calitatile sistemice. /ele notate cu 7 au tendinta de a creste calitatea sistemica, cele notate
cu ? au tendinta de a descreste calitatea.
/apacitatea poate afecta calitatile de performanta, precum cresterea tranzitarii sau reducerea
timpului de raspuns. /resterea capacitatii se obtine prin hardware-uri mai puternice iar daca
acestea sunt mai putin sigurea atunci capacitatea poate afecta alte calitati.
1edundanta, adica utilizarea mai multor copii ale unui anumit serviciu care lucreaza in
paralel, imbunatateste siguranta pentru ca daca o masina cade o alta poate sa ii ia locul.
1edundanta poate de asemenea creste performanta deoarece aduce o putere de procesare. 8n
prost design al redundantei poate degrada performanta prin cresterea traficului de retea. De
asemenea, redundanta face sistemul mult mai complex, ceea ce reduce administrabilitatea si
securitatea.
2odularitatea de obicei creste gradul de tranzitare, dar performanta, din punctul de vedere al
userului individual, nu este neaparat imbunatatita. e poate imbunatati, insa, securitatea
pentru ca fiecare bucatica de sistem poate fi prote$ata individual. #ncrederea si disponibilitatea
scad, deoarece mai multe masini trebuie sa functioneze in acelasi timp pentru a realiza $ob-ul.
Acelasi lucru se intampla si cu administrabilitatea pentru ca sistemul este mai complex. O
modularizare bine facuta poate creste toate calitatile pentru ca putem modifica fiecare element
intr-o relativa izolare.
8tilizabilitatea poate creste daca se atinge un inalt grad de satisfacere a utilizatorului, la nivel
arhitectural, prin manipulari de erori personalizate, internationalizare, etc.
&ractici de imbunatatire a calitatilor
2ulte practici la nivelul infrastructurii necesare imbunatatirii calitatilor sistemice se bazeaza
pe utilizarea componentelor redundante in sistem. Putem aplica aceste strategii fie la
produsele vandute fie la sistemele server. Alegerea depinde de costul implementarii si de
cerinte precum performanta, tranzitarea si scalabilitatea.
#ncarcarea echilibrata &load balancing* permite serverelor sa redirectioneze o cerere catre un
alt server pe baza unui algoritm load-balancing predeterminat. 0oad balancing este suportata
de o mare varietate de produse de la switch-uri de servere sistem la servere de aplicatie.
Avanta$ul load balancing este ca ne permite sa distribuim activitatile pe diferite masini mai
mici, in locul folosirii uneia mare care manipuleaza toate cererile.
#mplementarea load balancing-ului se face prin alegerea unei load-balancer cu caracteristici
de performanta si disponibilitate. Avem urmatoarele"
0oad balancers in switch-urile de retea, implementate de firme si ofera avanta$ul
vitezei
0oad balancers in clusterele de management a softului si serverelor de aplicatie, sunt
implementate cu soft-ul si sunt gestionate impreuna cu componentele aplicatiei, ceea
ce ofera flexibilitate si administrabilitate
0oad balancers bazate pe instantele server bazate pe configurarea D;, distributia
incarcarii se face instante multiple ale serverului ce se mapeaza la acelasi nume gazda
D;. Este simplu de setat, dar de obicei nu adreseaza problema afinitatii de sesiune.
0oad balancer-ul se bazeaza pe cateva solutii standard in luarea deciziilor"
Algoritmul round robin, care alege pe rand fiecare server
!impul de raspuns sau algoritmul primul disponibil, se monitorizeaza timpul de
raspuns al serverelor si se alege cel care raspunde primul
Algoritmul cel mai putin incarcat, se monitorizeaza incarcarea serverelor si se alege
cel care are capacitatea cea mai mare
Algoritmul ponderat, se specifica o prioritate a algoritmilor anteriori dand unelor
servere un volum de munca mai mare decat altora
Algoritmul client bazat pe D;, distribuie incarcarea pe clientul al carui D; se
specifica
Pe langa aceste solutii marea ma$oritate a implementarii load balancerelor ne permit sa cream
propria strategie de incarcare echilibrata si apoi putem sa o instalam.