Arhitecturi pt Sisteme Software - Prof. Mindruta - Cursuri 1-14

Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 1

Arhitecturi pentru sisteme software

Curs 1

Site curs:https://sites.google.com/site/arhswcm

id9208661 pdfMachine by Broadgun Software - a great PDF writer! - a great PDF creator! - http://www.pdfmachine.com http://www.broadgun.com

https://sites.google.com/site/arhswcm


Arhitecturi software - exemple


Concluzie

Probleme ale descrierilor naive ale arhitecturii software

� Text informal ºi diagrame de tip box-and-lines.

� Intuitive

� Precizie slabã

� Rareori formalizatã

O soluþie : Dezvoltarea ARHITECTURALÃ a sistemelor software ºi descrierea formalã a structurii acestora.


Dezvoltarea arhitecturalã a sistemelor software

� Compunerea sistemelor din pãrþi componente.

� Asigurarea conformitãþii sistemului cu arhitectura ºi cu

proprietãþile dorite.

� Utilizare arhitecturi standard pentru integrare.

� Reutilizare.

� Reducere costuri utilizând linii de produse.


PLAN CURS

Obiectivele cursului

Definiþia ºi rolul arhitecturii software

Evoluþia domeniului

Arhitectura software în context

Impactul arhitecturii software

Relaþiile de influenþã ale arhitecturii software

Rolul ºi calitãþile arhitectului software


Obiectivele cursului - 1

Rolul arhitecturii software în procesul de dezvoltare a software-lui.

Recunoaºterea principalelor stiluri ºi ºabloane arhitecturale.

Descrierea cerinþelor astfel încât arhitectura sã poatã fi evaluatã.

Înþelegerea principiilor unei bune documentaþii arhitecturale.

Înþelegerea modului de incorporare a COTS ºi middleware în

proiectele arhitecturale.

Generarea de alternative arhitecturale pentru o problemã ºi

alegerea uneia dintre ele.


Obiectivele cursului - 2

Proiectarea ºi construirea unui sistem de dimensiuni medii care

satisface o specificaþie arhitecturalã

Înþelegerea modului în care notaþiile formale pot fi utilizate

pentru a specifica arhitecturi.

Evaluarea adecvãrii unei arhitecturi date în îndeplinirea unui

set de cerinþe sistem ºi echilibrarea compromisurilor asupra

calitãþii.

Cunoaºterea tendinþelor de viitor în domeniul arhitecturilor

software.


PLAN CURS









Arhitecturã software - Definiþie

Definiþii la:http://www.sei.cmu.edu/architecture/start/definitions.cfm

Definiþia adoptatã la acest curs:

�Arhitectura software a unui sistem de calcul este setul structurilor

unui sistem necesare pentru a realiza raþionamente referitoare la

acesta, structuri conþinând elementele software, relaþiile dintre

acestea ºi proprietãþile vizibile din exterior ale ambelor�.

Clements, Bachmann, Bass, Garlan, Ivers, Little, Nord, Stafford, Documenting Software Architectures: Views and Beyond, Addison Wesley Longman, 2010

http://www.sei.cmu.edu/architecture/start/definitions.cfm


Proiectare arhitecturalã

Informaþii despre domeniul aplicaþiei

PROIECTARE ARHITECTURALÃ

Arhitectura aplicaþiei = Perspectivã generalã asupra software-lui.

Elemente ale modelului analizã

ªabloane ºi stiluri arhitecturale existente


Locul ºi rolul arhitecturii software

Proiect de nivel superior al sistemuluiAbstractizãri la nivel de sistem

Modele reutilizabile la nivel de sistemRãspunde cerinþelor de comportament ºi de calitate


Importanþa arhitecturii software

Reducerea costurilor de dezvoltare ºi de mentenanþã clarificarea structurii sistemului pe diferite nivele reutilizare

Creºterea calitãþii produsului software clarificarea cerinþelor explicitarea deciziilor, realizate pe bazã de principii, ºi a

implicaþiilor lor analize la nivel de sistem analiza precoce a problemelor de proiectare


Importanþa arhitecturii software � reducerea costurilor de mentenanþã

Aproape 50% din efortul de mentenenþã este

investit în analiza ºi înþelegerea codului ºi documentaþiei existente.


Arhitecturã software vs. programare

PROGRAMAREA

Implementarea�SăUþilor componente

Proprietãþile computaþionale

Operaþionalã

În mare parte dinamicã

Performanþã la nivel de algoritm

�vedere� interioarã a modulelor

ARHITECTURA SOFTWARE

Interacþiunile dintre pãrþile componente

Proprietãþile structurale

Declarativã

În mare parte staticã

Performanþã la nivel de sistem

�vedere��H[WHULRDUă�D�modulelor


PLAN CURS









Evoluþia domeniului - anii 1980

Utilizare informalã de diagrame de tip box-and-lines

Aplicare ad-hoc a expertizei arhitecturale

Utilizarea neorganizatã, necodificatã, a ºabloanelor ºi stilurilor

Majoritatea proiectelor nu au �arhitect�



Recunoaºterea importanþei arhitecþilor în companiile de dezvoltare de software

Procese software ce includ revizuiri ale arhitecturii ºi documentaþie arhitecturalã explicitã

Utilizare de linii de produse, de standarde arhitecturale, de cadre pentru integrare de componente

Codificarea vocabularului, notaþii ºi instrumente pentru proiectare arhitecturalã

Cãrþi ºi cursuri de arhitecturi software



Încorporarea notaþiilor arhitecturale în principalele limbaje de proiectare (ex. UML 2.0) ºi instrumente (ex. Software Architect de la IBM)

Metode�ED]DWH�SH�SURLHFWDUH�DUKLWHFWXUDOă�ºi rafinarea acesteia (ex. MDA � Model Driven Architecture)

Unele instrumente pentru analizã�DUKLWHFWXUDOă

Standarde arhitecturale pentru sisteme enterprise (ex. RM-ODP, TOGAF)


PLAN CURS









Ingineria sistemelor

Ingineria sistemelor ��GLVFLSOLQă�GH�SURLHFWDUH�ºi management pentru proiectarea ºi construirea de sisteme mari, complexe, interdisciplinare.

Arhitectura sistemului � element critic al ingineriei sistemelor:� Descrie elementele ºi interacþiunile unui sistem complet precum

ºi contribuþia acestora la scopul sistemului

� Include identificarea ºi caracterizarea elementelor sistemului, fãrã a descrie substructurile acestor elemente.


Interese în proiectãri arhitecturale

Caracteristicile limbajului Eficienþa algoritmilor Proiectarea structurilor de date Testarea aplicaþiei software Implementarea funcþionalitãþii

Proiect software non-arhitectural

Identificarea atributelor de calitate Cerinþele funcþionale pentru software Partiþionarea aplicaþiilor software Integrare ºi testare la nivel de software ºi de sistem

Arhitecturã software

Identificarea contextului sistemului Partiþionare (centratã pe Hw ºi infrastructurã) Identificarea cerinþelor software Cerinþele funcþionale generale ale sistemului Integrare ºi testare la nivel de sistem

Arhitecturã sistem

Procese business ºi modele operaþionale�'DWH�EXVLQHVV

�6WUXFWXUă�ºi relaþii organizaþionale�3ăUþile interesate în afacere (stakeholders) Infrastructura IT

Arhitecturã �enterprise�

Interese cheie în proiectareNivel de abstractizare


Ierarhia proiectãrii arhitecturale

Principii:

Interese diferite pe nivele diferite

Deciziile de pe nivelele superioare impun constrângeri nivelelor inferioare

Nivelul superior transferã responsabilitatea detalierii�FăWUH�nivelul inferior


Ierarhia proiectãrii arhitecturale

ENTERPRISE: procesul business mapat pe o infrastructurã cu

granularitate mare.

SISTEM: Concentrare pe cerinþele funcþionale alocate elementelor fizice. (sisteme de sisteme)

SOFTWARE: multidemnsionalã; satisfãcând

cerinþe funcþionale ºi de calitate.�

Deseori ortogonalã în raport cu structurile sistemului.

Criticã în satisfacerea obiectivelor business.


PLAN CURS










Atributele de calitate (modificabilitate, disponibilitate, performanþã, etc.) sunt dependente de design.

Gândirea arhitecturalã este gândire strategicã.

O arhitecturã software proiectatã deliberat ºi bine documentatã

oferã valoare proiectului ºi firmei ce dezvoltã software-ul.



Proiectul arhitectural ºi documentaþia asociatã:

� servesc ca vehicol de comunicare

� ghideazã deciziile iniþiale de proiectare

� reduc riscul

� ajutã la managementul proiectului/produsului

� faciliteazã reutilizarea



Documentaþia�DUKLWHFWXULL�RIHUă�XQ�FDGUX�GH�UHIHULQþã în care pot fi expuse ºi negociate interese concurente.

Permite:

� Negocierea cerinþelor tuturor pãrþilor interesate� Realizarea de informãri asupra progresului

� Alocare de resurse ºi ghidarea construirii produsului software

Documentaþia trebuie sã fie:� DESCRIPTIVÃ -�SHQWUX�FRPXQLFDUH� PRESCRIPTIVÃ - pentru proiectanþi ºi pentru

implementatori.

Proiectul arhitectural ºi documentaþia asociatã:� Servesc ca vehicol de comunicare��*KLGHD]ă�GHFL]LLOH�LQLþiale de proiectare��5HGXF�ULVFXO

��$MXWă�OD�PDQDJHPHQWXO�SURLHFWXOXL/produsului��)DFLOLWHD]ă�UHXWLOL]DUHD



Arhitectura face trecerea de la specificarea cerinþelor (ce?) la îndeplinirea acestora (cum?).

Arhitectul poate prezice calitãþile sistemului prin studierea abstractizãrilor arhitecturale ale acestuia.� Deciziile arhitecturale influenþeazã proprietãþile sistemului în

moduri cunoscute

� Proiectul arhitectural poate fi analizat ºi utilizat pentru a prezice în ce mãsurã vor fi obþinute proprietãþile aºteptate de la sistem.



PERFORMANÞÃ ��HYLWDUH�JkWXLUL, cuplare strânsã a

elementelor, limitarea�FDQWLWăþii ºi frecvenþei comunicãrilor

distribuite ºi între elemente

MODIFICABILITATE ��FHQWUDUH�SH�UHVSRQVDELOLWăþile elementelor, decuplarea�HOHPHQWHORU, localizarea responsabilitãþilor, minimizarea ºi simplificarea dependenþelor între elementele sistemului.



O arhitecturã ce a fost proiectatã poate fi evaluatã pot fi identificate ºi diminuate elementele riscante ale sistemului.

Infrastructura arhitecturalã proiectatã poate fi implementatã ºi serveºte ca �echipament� de testare suport pentru prototipare, integrare, testare precoce.

Proiectul arhitectural ºi documentaþia asociatã:� Servesc ca vehicol de comunicare��*KLGHD]ă�GHFL]LLOH�LQLþiale de proiectare� Reduc riscul��$MXWă�OD�PDQDJHPHQWXO�SURLHFWXOXL/produsului��)DFLOLWHD]ă�UHXWLOL]DUHD



Permite realizarea de�HVWLPăUL�PDL�SUHFLVH ale costurilor ºi planului de timp.� Estimãrile se bazeazã pe elementele arhitecturii

� Echipa responsabilã pentru un anume element oferã estimãrile pentru acesta� Managerii de proiect integreazã estimãrile ºi rezolvã dependenþele ºi

conflictele

Utilã în managementul modificãrilor.� Permite pãrþilor interesate sã judece ºi sã gestioneze modificãrile la sistem

pe toatã durata de viaþã a acestuia (aprox. 80%�GLQ�HIRUW�DUH�ORF�GXSă�GH]YROWDUHD�ºi punerea iniþialã în funcþiune a sistemului).

� Arhitectura împarte modificãrile în trei clase:� Locale � un singur element� Non-locale � mai multe elemente� Arhitecturale ��PRGLILFăUL�OD�WRSRORJLD�VLVWHPXOXL�VDX�OD�PHFDQLVPHOH�GH�FRPXQLcare ºi coordonare.

Oferã înþelegere ºi cunoaºtere�SăWUXQ]ăWRDUH�GH-a lungul întregului ciclu de viaþã al sistemului. Proiectul arhitectural ºi documentaþia asociatã:

� Servesc ca vehicol de comunicare��*KLGHD]ă�GHFL]LLOH�LQLþiale de proiectare� Reduc riscul��$MXWă�OD�PDQDJHPHQWXO�SURLHFWXOXL/produsului��)DFLOLWHD]ă�UHXWLOL]DUHD



Faciliteazã reutilizarea de elemente cu granularitate mare.Exemple:

� Componente (ex. baze de date, COTS)� Cadre de dezvoltare (ex. Java EE)

� Linii de produse��reutilizare strategicã)

Obs.�5HXWLOL]DUHD�GH�PRGXOH�GH�JUDQXODULWDWH�PLFă�DUH�XUPăWRDUHOH�GHzavantaje:

� Este costisitor ºi dificil de gãsit funcþiile, metodele sau procedurile cele mai potrivite

� Este dificil de determinat proprietãþile moºtenite în aceste module.




PLAN CURS









Ciclul business al arhitecturii (ABC)

Relaþiile dintre obiectivele afacerii, cerinþele produsului, experienþa arhitectului, arhitecturi ºi sisteme formeazã un

ciclu.

Arhitectura software este influenþatã de o serie de factori. Arhitectura software ºi sistemul dezvoltat pe baza ei influenþeazã, la

rândul ei, aceºti factori. În centrul acestui ciclu stã arhitectul software.

Înþelegerea ºi analiza acestui ciclu poate ajuta compania sã-ºi gestioneze afacerea, organizarea ºi arhitectura.


ABC - Factorii ce influenþeazã arhitectura software

Pãrþile interesate în sistem Firma ce dezvoltã sistemul

Contextul tehnologic Cunoºtinþele ºi experienþa arhitectului



Stakeholder-i (clienþi, utilizatori, dezvoltatori, manageri, personal de întreþinere, etc) � au interese diferite pe care le vor garantate sau optimizate.

Exemple Dezvoltatori � limbaje, tehnologii

Administratori � reglare, configurare, repartizare sistem

Marketing � caracteristici ºi preþ competitive pe piaþã

Obiectivele organizaþionale ºi proprietãþile la nivelul business ale sistemului sunt rareori înþelese ºi cu atât mai puþin bine exprimate � arhitectul�trebuie sã joace un rol activ în identificarea ºi angajarea precoce a stakeholder-ilor în ciclul de dezvoltare.

�Pãrþile interesate în sistem�Firma ce dezvoltã sistemul

�Contextul tehnologic�Cunoºtinþele ºi experienþa arhitectului



Clase de influenþe organizaþionale:

Afacerea imediatãFirma poate avea o investiþie în anumite bunuri, cum ar fi arhitecturi existente ºi

produsele bazate pe acestea.

Afacerea pe termen lungArhitectura poate fi nucleul unei investiþii pe termen lung în infrastructurã, pentru

îndeplinirea obiectivelor strategice ale firmei.

Structura organizaþionalãStructura organizaþionalã poate modela arhitectura a.î. diviziunile de funcþionalitate

se aliniazã la unitãþile de expertizã existente.�Pãrþile interesate în sistem�Firma ce dezvoltã sistemul




Contextul tehnologic existent în momentul elaborãrii arhitecturii.

Include:� Limbaje

� Instrumente� Sisteme de operare

� Platforme de calcul

� Cadre de implementare� Practici industriale standard ºi tehnici de inginerie software





Arhitecþii iau decizii de proiectare pe baza experienþei lor.� Experienþele reuºite conduc la replicarea proiectelor care au mers bine

� Experienþele nereuºite vor fi evitate în noile proiecte,�FKLDU�GDFă�metodele, tehnicile ºi/sau tehnologiile ce au codus la acestea ar putea funcþiona bine în alte proiecte

� Alegerile pe care le face un arhitect sunt influenþate de experienþa, de instruirea (training) ºi de educaþia sa formalã (în acestã ordine!).




ABC - Factorii influenþaþi de arhitectura software

Arhitectura ºi sistemul dezvoltat pe baza acesteia vor influenþa:

Structura ºi obiectivele firmei dezvoltatoare

Cerinþele beneficiarilor Experienþa arhitectului Tehnologia



Arhitectul divizeazã sistemul în componente majore ºi unitãþi de lucru.

modeleazã firma prin partiþionarea forþei de muncã ajutã la stabilirea unui vocabular de comunicare

bazã pentru WBS, utilizatã în planificare,�XUPăULUH�ºi bugetare organizare în scopul gestionãrii configuraþiilor organizare în scopul elaborãrii documentaþiei bazã pentru integrare ºi testare

Arhitectul defineºte elementele software ce trebuie implementate ºi integrate. Acestea devin bazã pentru:� alocare talente, recrutare, formare echipã� activitãþi de dezvoltare, testare ºi integrare� estimare ºi alocare resurse� planuri de timp, bugete, urmãrire proiect ºi supraveghere

�Structura ºi obiectivele firmei dezvoltatoare�Cerinþele beneficiarilor�Experienþa arhitectului�Tehnologia



Arhitecturile pot influenþa obiectivele unei firme deoarece:

Un sistem de succes construit pe baza unei anumite arhitecturi poate permite unei companii sã punã stãpânire pe o anumitã

zonã de piaþã

Arhitectura poate oferi oportunitãþi pentru producere eficientã ºi punere în funcþiune de sisteme similare.




Pe baza cunoºtinþelor despre sisteme similare clienþii cer anumite tipuri de caracteristici.

Exemple:� Beneficiarii învaþã limbajul arhitectural, percep beneficiile, ºi vor tipuri

similare de arhitecturi cum ar fi client-server, EJB, CORBA, .NET, etc.� Clienþii vor cere arhitecturi de calitate în sistemele viitoare

Pe baza cunoºtinþelor despre sistemul dezvoltat clienþii îºi vor modifica cerinþele sistem în raport cu disponibilitãþii sistemelor ºi elementelor existente.




Dezvoltarea unei arhitecturi îmbogãþeºte experienþa arhitectului.

Tehnologii, instrumente, metode ce au fost utilizate în dezvoltarea de sisteme reuºite conduc la crearea de sisteme viitoare în aceeaºi manierã.

Arhitectura unui sistem eºuat este evitatã în proiecte viitoare.




Ocazional, un sistem sau o arhitecturã vor modifica stadiul actual al tehologiei.

Exemple: generatoare de compilatoare baze de date relaþionale

foi de calcul

sisteme de operare cu interfeþe grafice

WWW Java



PLAN CURS







Competenþele, rolul ºi calitãþile arhitectului software



Tehnologie

Creativ

Capabil de investigaþie

Practic/pragmatic

Patrunzãtor

Tolerant faþã de ambiguitãþi, dispus la reluãri, în cãutare

de soluþii multiple

Capacitate de a lucra pe nivel abstract

Modelare

Analiza compromisurilor

Prototipare/experimentare/simulare

Pregãtirea documentelor ºi prezentãrilor arhitecturii

software

Analiza tendinþelor tehnologice

Un punct de vedere asupra sistemului

Înþelegerea profundã a

domeniului ºi tehnologiilor pertinente

Posibilitatea de a decela elementele tehologice care reprezintã cheia succesului

Metode de dezvoltare ºi tehnici de modelare

calitãþirolcompetenþe



Consultanþã

Angajat în succesul altora

Empatic, abordabil

Practic/pragmatic

Agent de schimb eficient

Bun mentor

Crearea unei relaþii de încredere în consultant

Înþelegerea a ceea ce doresc ºi au nevoie dezvoltatorii de la arhitecturã

Ajutã dezvoltatorii sã vadã

valoarea arhitecturii ºi sã

înþeleagã cum o pot utiliza

cu succes

Mentor pentru arhitecþii juniori

Tehnici de a obþine ºi provoca informaþii

Metode cadru de consultare

Cunoscãtor al proceselor

(business, software, management)




Strategie

Vizionar

Antreprenorial

Influenþarea strategiei afacerii

Traducerea strategiei afacerii în viziune ºi strategie tehnicã

Înþelegerea clientului ºi a tendinþelor din piaþã

Capturarea în arhitecturã a

cerinþelor clientului, a celor organizaþionale ºi a cerinþelor business

Strategia ºi raþiunile fundamentale ale companiei

Competitorii (produse, strategii, procese)

Practica business a companiei




Politici oganizaþionale

Abilitatea de a vedea din puncte de vedere multiple ºi de a exprima în puncte de vedere multiple

Încrezãtor ºi clar/logic în exprimare

Ambiþios ºi hotarât

Rãbdãtor (cu mãsurã)

Rezistent ºi flexibil

Sensibil la localizarea ºi fluxul puterii în cadrul companiei

Comunicare

Ascultare, nod esenþial în reþeaua de comunicare interumanã, exercitare de influenþã.

�Vânzarea��XQHL�YL]LXQL. Pãstrarea acesteia �în viaþã�.

Luarea periodicã a pulsului

tuturor factorilor critici de influenþã asupra proiectului

arhitectural.

Care sunt jucãtorii cheie

în companie

Ce doresc aceºtia pe planul afacerii ºi pe plan personal




Conducere

Vãzut ca lider de ceilalþi dar ºi de el însuºi.

Carismatic ºi credibil.

Încredere cã se poate face

ºi cã poate conduce efortul

respectiv .

Angajat, dedicat, pasionat.

Plasarea întregului efort într-un context mai larg, atât al

afacerii cât ºi personal.

Stabilirea contextului echipei (viziunea)

Luare de decizii ºi asumarea lor

Construire echipe

Motivare

Autocunoaºtere



BIBLIOGRAFIE

Bass, L; Clements, P & Kazman, R. Software Architecture in Practice, Second Edition, Addison-Wesley Professional, 2003

Albin, Stephen T. The Art of Software Architecture:Design Methods and Techniques, John Wiley & Sons, 2003

Lattanze, Anthony J. Architecting Software Intensive Systems: A Practitioners Guide, Auerbach, 2008

Clements, Bachmann, Bass, Garlan, Ivers, Little, Nord, Stafford, Documenting Software Architectures: Views and Beyond, Addison Wesley Longman, 2010

Clements, Kazman, Klein, Evaluating Software Architectures: Methods and Case Studies, Adison Wesley Longman, 2001

Buschmann F., Menuier R., Rohnert H., Sommerlad P., Stal M., Pattern-Oriented Software Architecture. A System of Patterns, John Wiley & Sons, 1996



Curs 2



PLAN CURS

Analiza definiþiei arhitecturii software

Tipuri de vederi (viewtypes), stiluri ºi vederi

� Definiþii

� Perspectiva staticã

� Perspectiva dinamicã

� Perspectiva alocãrii

� Concluzie

Limbajul Acme ºi instrumentul AcmeStudio


Arhitectura software - definiþie

�Arhitectura software a unui sistem de calcul este

setul structurilor unui sistem

necesare pentru a realiza raþionamente referitoare la acesta,

structuri conþinând elementele software,

relaþiile dintre acestea ºi

proprietãþile vizibile din exterior ale ambelor�.

Proiectarea ºi documentarea arhitecturii software sunt esenþiale în dezvoltarea ºi evaluarea produsului software.

Dacã nu se realizeazã proiectarea arhitecturalã, în paralel cu dezvoltarea produsului software se va dezvolta implicit o arhitecturã. Care s-ar putea sã nu vã placã!!!



Caracteristici ale arhitecturii software:

Abstractizare a sistemului.

Partiþionare�GHFODUDWLYă�ºi asignare�GH�responsabilitãþi.

Defineºte elementele ºi modul în care sunt acestea relaþionate.

Suprimã detaliile despre comportamentul intern ºi despre informaþiile locale ale elementelor.



Orice sistem are o arhitecturã software (chiar dacã aceasta nu a

fost proiectatã în mod deliberat).

Cel mai simplu sistem este compus dintr-un singur element aflat în relaþie cu el însuºi.

Arhitectura îndeplineºte cerinþele funcþionale ºi în acelaºi timp promoveazã o serie de calitãþi ale sistemului (ex. performanþã, flexibilitate, etc.).









Abstractizare a structurilor reale ce compun sistemul software. Structurile sunt reale Reprezentãrile lor sunt abstracte









Tipuri de structuri software: Structurã staticã -�FRG, apel metodã/funcþie,� Structurã dinamicã - proces/fire de execuþie, flux de date,� Structurã fizicã - alocarea sistemului de fiºiere, procesor, reþea,

�.


Structurã, perspectivã, vedere

Un edificiu trebuie sã aibã trei calitãþi: durabilitate (firmitas), utilitate (utilitas), esteticã (venustas).

Marcus Vitruvius Pollio, De architectura

STRUCTURI ale sistemului OM



O vedere din perspectivã

dinamicã

O vedere din perspectivã

staticã

Vedere (view) ��R�UHSUH]HQWDUH�D�XQHL�VWUXFWXUL, vãzutã dintr-o anumitã perspectivã.

Inima ca (sub)STRUCTURÃa aparatului circulator.



Perspectiva STATICÃVederi ale modulelor:

�clase�funcþii�interfeþe

Perspectiva FIZICÃVederi ale alocãrilor la:

�calculatoare�dispozitive�reþele

Perspectiva DINAMICÃVederi ale componentelor ºi conectorilor:

�procese�diagrame de secvenþe�flux de date

Arhitectura software









Arhitectura sistemului permite raþionamente�UHIHULWRDUH�OD�VDWLVIDFHUHD�GH�FăWUH�VLVWHP�D: cerinþelor de calitate cerinþelor de comportament

Deciziile arhitectului se reflectã în structurile sistemului.

Rezultã : deciziile arhitecturale sunt cele care permit sistemului sã îndeplineascã cerinþele de calitate ºi comportament.



Element � �parte� a unui sistem.

pachete software, platforme software,...FIZICÃ

fire de execuþie, flux de date, control, ...DINAMICÃ

clase, fiºiere, ...STATICÃ

Tipuri de elementePerspectiva









�Elementele interacþioneazã prin interfeþe care împart detaliile elementelor în pãrþi publice ºi pãrþi private.

�Aceste interacþiuni formeazã relaþiile dintre elementele arhitecturale.

�Arhitectura se ocupã doar cu partea publicã a acestei partiþionãri.









Tipurile de relaþii depind de tipurile de elemente, care depind la rândul lor de perspectivã.

Exemple:

Modul B

Modul A

Modul C

uses uses

Vedere din perspectivã STATICÃ

Elemente: moduleRelaþii: uses

Proces X Proces Ydate date date

Vedere din perspectivã DINAMICÃ

Elemente: proceseRelaþii: flux de date









Proprietãþi funcþionale : responsabilitãþile elementelor, asignate în cursul proiectãrii

arhitecturale.

Proprietãþi non-funcþionale : cerinþele de calitate pentru sistem ºi componentele sale.

Proprietãþile vizibile depind de perspectiva asupra sistemului.Exemplu:�Perspectivã staticã ��PRGLILFDELOLWDWHD

�Perspectivã dinamicã - performanþa








PLAN CURS



� Definiþii




� Concluzie



Tipuri de vederi, stiluri ºi vederi

�Arhitectura software a unui sistem de calcul este setul structurilor unui sistem

necesare pentru a realiza raþionamente referitoare la acesta, structuri

conþinând elementele software, relaþiile dintre acestea ºi proprietãþile vizibile

din exterior ale ambelor�.

Într-o vedere�DUKLWHFWXUDOă�HVWH�reprezentat�XQ�DQXPLW�IHO�GH�VWUXFWXUă��exemple:

Structura modulelor indicând compoziþia/decompoziþia lor

Structura proceselor ºi modul de sincronizare

Structura hardware ºi modul în care software-ul este repartizat pe aceasta

Structura echipelor de dezvoltare ºi modul lor de cooperare

Structura la momentul execuþiei, reprezentînd componentele ºi conectorii dintre acestea.


Tipuri de vederi ºi vederi

Vedere (view) = o reprezentare a unui (sub)set de elemente ale sistemului ºi a relaþiilor asociate cu acestea.

Vederea reprezintã sistemul dintr-o anumitã perspectivã.

Fiecare perspectivã�HVWH�FDUDFWHUL]DWă�GH�XQ�tip de vedere ce defineºte tipuri de elemente ºi tipuri de relaþii specifice.

O vedere este construitã dintr-o anumitã perspectivã, folosind tipul de vedere corespunzãtor acesteia.


Tipuri de vederi ºi vederi

Arhitectul software considerã sistemul din trei perspective:

Perspectiva staticã � modul în care sistemul este structurat ca set de unitãþi de implementare (cod).

Vederile reprezintã modulele sistemului. Tipul de vedere este Module Viewtype.

Perspectiva dinamicã � modul în care sistemul este structurat ca set de unitãþi de execuþie (elemente ce au comportament ºi interacþiuni la momentul execuþiei).

Vederile reprezintã componentele sistemului ºi conectorii dintre acestea. Tipul de vedere este C&C Viewtype.

Perspectiva alocãrii � modul în care sistemul se relaþioneazã cu structurile non-software�GLQ�FRQWH[WXO�VăX.

Vederile reprezintã modul de alocare a structurilor software pe structurile non-software ale sistemului. Tipul de vedere este Allocation Viewtype.


Stiluri

Stil arhitectural � specializare pentru tipuri de elemente ºi de relaþii, împreunã cu un set de constrângeri referitoare la modul de utilizare a acestora.

Motivaþie:Au fost observate forme ce se repetã în sisteme diferite. Aceste forme au

proprietãþi cunoscute ºi pot fi reutilizate.

Stilurile arhitecturale sunt independente de sistem ºi sunt instrumente importante pentru arhitectul software.

Un sistem este de obicei compus din mai multe stiluri� Stiluri diferite pentru zone diferite ale sistemului.� Stiluri diferite pentru perspective diferite asupra sistemului.


Stiluri

Stil arhitectural � specializare pentru tipuri de elemente ºi de relaþii, împreunã cu un set de constrângeri referitoare la modul de

utilizare a acestora.

Stil arhitectural � poate defini:

Restricþii asupra elementelor

Tipuri de relaþii între elemente

Modalitãþi de utilizare a elementelor

Modalitãþi de configurare a elementelor


PLAN CURS



� Definiþii




� Concluzie



Perspectiva staticã � Module Viewtype

Tip de element :

� modul� �unitate de cod ce implementeazã un set de

responsabilitãþi.

Tipuri de relaþii :

� �is part of� � relaþia parte-întreg

� �depends on� � relaþia de dependenþã

� �is a� � relaþia de specializare/generalizare



UTILITATE

Construire :

� Modulele sunt asignate echipelor în vederea implementãrii.

� Deseori modulele sunt unitãþi pentru proiectarea ulterioarã (ex.

pentru proiectarea de interfeþe).

Analizã :

� Trasabilitatea ºi analiza impactului modificãrilor se bazeazã pe

unitãþile de implementare.

� Managementul proiectului, bugetarea, planificarea ºi

monitorizarea utilizeazã frecvent aceste module.



NOTAÞII

Informale : box-and-lines, cu încuibare

UML : diagrame de clase



STILURI

Stilul de descompunere

� descompunerea (ierarhicã) în module

suportã dezvoltare concurentã

Stilul de generalizare

� ierarhie a specializãrii

suportã reutilizare; gestionarea unui numãr mare de definiþii

Stilul stratificat (layered) :

� maºini virtualesuportã portabilitate, reutilizare

STILURI�Descompunere�Generalizare�Stratificare



Tip elemente : modul

Tip relaþii : �is part of�

Criterii de descompunere :

� Obþinerea modificabilitãþii

� Construire vs. Cumpãrare

� Linii de produse

Utilitate :

� Punct de pornire. Modulelor le sunt asignate responsabilitãþi.

� Analiza modificare/impact

� Bazã pentru asignare de sarcini de lucru pentru membrii echipei de

dezvoltare.




NOTAÞII

Informal :

box-and-lines, încuibate

schiþã textualã

tabelã

UML :

Diagrama de clase cu relaþia de compoziþie

Diagrama de pachete




Exemplu STILURI�Descompunere�Generalizare�Stratificare



Tip elemente : modul

Tip relaþii : �is a�

Proprietãþi :

� moºtenire interfaþã

� moºtenire implementare

Utilitate :

� bazã pentru proiectarea OO

� bazã pentru evoluþie ºi extindere

� reutilizare




NOTAÞII

Formal :

Limbaje de programare

UML




Tipuri elemente : straturi (nivele), maºinã virtualã

Tip relaþii : �allowed-to-use� (specializare a relaþiei �depends-on�)

Reguli (variante multiple):

� Fiecare element software aparþine unui singur nivel.

� Un element software de pe un nivel poate utiliza elemente {din orice

nivel inferior, doar elemente de pe nivelul imediat inferior}.

� Un element de pe un nivel {poate, nu poate} utiliza un element de pe

acelaºi nivel.




Utilitate :

� Portabilitate

� Dezvoltare incrementalã

� Separare de probleme (concerns)

Variaþii:� Nivele segmentate:

divizare nivel în segmente (sau submodule)

ºi precizarea relaþiei �allow-to-use� la nivel de segment,

pentru segmente de pe acelaºi nivel

ºi segmente de pe nivele diferite.




NOTAÞII

Informale : dreptunghiuri ºi sãgeþi, stivã de

dreptunghiuri, inele concentrice.



PLAN CURS



� Definiþii




� Concluzie



Perspectiva dinamicã �

Component-and-connector (C&C) Viewtype

Tipuri de elemente :

� componentã = unitate de calcul ºi/sau memorare date pe

timpul execuþiei; accesibilã prin porturi.

� conector = mecanism de interacþiune; defineºte roluri.


� �attachment� � ataºare port al componentei la rol al

conectorului

Proprietãþi : informaþii pentru construire ºi pentru analizã

� Atribute de calitate ��VXSRUW�SHQWUX�DQDOL]ă

� Altele � funcþie de stil


Perspectiva dinamicã � C&C Viewtype

UTILITATE

La construire

Defineºte sistemul din perspectivã dinamicã (în timpul execuþiei)

determinând

� comportamentul ce trebuie construit,

� cãile de interacþiune

� mecanismele de comunicare.

La analizã

Model pe baza cãruia se analizeazã proprietãþile (emergente) ale

sistemului (disponibilitatea, performanþa, securitatea, încrederea, etc.).



NOTAÞII

Informale : box-and-lines

UML : diagrama de componente

Acme (AcmeStudio) :



STILURI (exemple fundamentale)

Data Flow

� Pipe&filters (Reþea de flux de date)

Call-and-return

� Client - Server

� Peer-to-Peer

� Service Oriented Architecture

Event-based

� Publish-Subscribe

Repository

� Blackboard



PROBLEME TRANSVERSALE

corelate în mod similar cu mai multe stiluri

extind stilurile fundamentale generând variante ale acestora

Procese comunicante

Trepte (tiers)

Reconfigurare dinamicã


PLAN CURS



� Definiþii




� Concluzie



Perspectiva alocãrii �

Allocation Viewtype


� Elemente software = definite în perspectiva staticã sau în cea

dinamicã.

� Elemente din context (infrastructurã)


� �allocated-to� � repartizare element software pe element (non-

software) din context.


Perspectiva alocãrii � Allocation Viewtype

UTILITATE

La construire

Defineºte modul de repartizare a elementelor software ale aplicaþiei pe

elementele infrastructurii (în general, non-software)

� Pe infrastructura hw/sw

� Pe membrii echipelor de dezvoltare ºi de întreþinere

La analizã

Model de integrare a arhitecturii software în context.



NOTAÞII

Informale UML : diagrama de repartizare (deployment)



STILURI

Stilul repartizãrii

Alocarea elementelor software la modulele infrastructurii de procesare ºi de

comunicare

Exemple de proprietãþi :�FHOH�QHFHVDUH�FDOFXOăULL�(ºi obþinerii) performanþei ºi disponibilitãþii

Stilul implementãrii

Alocarea elementelor software la structuri din sistemele de fiºiere al mediilor de

dezvoltare

Exemple de proprietãþi : fiºiere ºi capacitãþi

Stilul de alocare a lucrului

Alocarea elementelor software la unitãþile de lucru din compania de dezvoltare

Exemple de proprietãþi : seturi de competenþe


PLAN CURS



� Definiþii




� Concluzie



Concluzie

Sistemele � combinaþii de stiluriEx. Tiers-repository-events

Este necesarã înþelegerea stilurilor pure, ce constituie blocurile constructive

Regulã : nu amestecaþi stiluri din tipuri diferite de vederi

� Creazã confuzie (Ex: layers ºi tiers)


Exemplu � Test Parsing SystemPerspectiva staticã

Stilul de descompunere


Exemplu � Test Parsing SystemPerspectiva dinamicã

Vedere C&C


Exemplu � Test Parsing SystemPerspectiva alocãrii

Stilul implementãrii


PLAN CURS



� Definiþii




� Concluzie



Perspectiva dinamicã

Descompunerea (generalã) sistemului în componente ce

interacþioneazã la execuþie

Utilizare abstractizãri globale pentru conectare componente

Analiza proprietãþilor emergente ale sistemului

� performanþã, ratã de transfer, întârzieri, ...

� fiabilitate, securitate, toleranþã la defecte, modificabilitate

dinamicã, ...



Vedere C&C include:� Componente: definesc locaþiile de realizare a calculelor

� Exemple: filtre, baze de date, obiecte, tipuri de date abstracte.

� Conectori: definesc interacþiunile dintre componente� Exemple: apel de procedurã, conductã (pipe), anunþare eveniment.

Stil arhitectural C&C - defineºte o familie de arhitecturi prin:� Tipuri de componente ºi conectori (vocabular)� Constrângeri topologice

� Constrângeri semantice


Descriere arhitecturi

Exemple de limbaje (ADLs)

� Rapide: evenimente cu simulare ºi animaþie

� UniCon: accent pe eterogenitate ºi compilare

� Wright: spacificaþii formale pentru conectori

� Aesop/Acme: orientate pe stiluri (style-specific)

� Darwin: arhitecturi orientate pe servicii

� SADL: rafinare arhitecturalã

� Meta-H: descrieri arhitecturale specifice unui domeniu (avionics)

� C-2: stil arhitectural ce utilizeazã invocare implicitã



Acme � limbaj reprezentativ

Încearcã sã ofere o abordare deschisã (open-ended) pentru reprezentarea arhitecturii

�XML pentru arhitecturã�

� Descriere structurã + permite adnotãri

� Poate fi consumat selectiv de diferite instrumente



Acme � ENTITÃÞILE DE PRIM RANG

Componentã � element computaþional

Port � punct de interfaþã pentru componentã

Conector � interacþiune între componente

Rol � punct de interfaþã pentru conector

Sistem � graf de componente ºi conectori

Exemplu � sistem client-server



Acme ��35235,(7ĂÞI

Descriu caracteristici nestructurale ale elementelor

� Detalii de interfaþã (ex. servicii solicitate, servicii oferite)

� Proprietãþi locale ale componentelor sau conectorilor (ex. viteze, capacitãþi, întârzieri)

� Atribute de calitate��proprietãþi emergente la nivelul sistemului) (ex. performanþã, fiabilitate, securitate)

� Comportament (ex. calcule executate de componente, protocoale pentru conectori)

� Constrângeri (ex. restricþii topologice, restricþii asupra proprietãþilor)



Acme ��35235,(7ĂÞI

Reprezentare�SURSULHWăþi ��DGQRWăUL�FX�SHUHFKL�DWULEXW-valoare

Proprietãþile sunt tipate � categorii de tipuri:

� Built-in : int, boolean, string, etc

� Constructori : set, record, enumeration, sequence

� Definite de utilizator



Acme ��5(35(=(17Ă5,�ºi ABSTRACTION MAPS

Suport pentru descriere ierarhicã a nivelelor de abstractizare.

� Reprezentarea sub-arhitecturilor.

� Descrieri de detaliu ale componentelor ºi conectorilor

� Încapsularea detaliilor de nivel inferior



Acme ��5(35(=(17Ă5,�ºi ABSTRACTION MAPS

Unui element Acme i se pot asocia mai multe reprezentãri.

Abstraction Map ��VSHFLILFDUH�legãturi

� ��LQWHULRUXO�-�H[WHULRUXO�reprezentãrii

� port intern - port extern (la componente)

Component Representation

System

AbstractionMap

System(sub-architecture)

...

...

...

...



Acme � DEFINIRE FAMILII (STILURI ARHITECTURALE)

Obiectiv : descrierea unui set de arhitecturi înrudite.De ce?

- Reutilizarea stilurilor comune

- Suport pentru integritatea sistemului

Elemente constitutive:� Set de tipuri (componente, conectori, ...)

� Definirea vocabularului asociat stilului� Definirea structurii cerutã fiecãrui element

� Set de constrângeri� Restricþii de utilizare corectã a tipurilor

� Set de vizualizãri� Modul de afiºare a elementelor stilului

� Set de analize� Ce se poate deduce despre o anumitã arhitecturã




Definire tip element<categorie> Type <nume-tip> = <declaraþie-tip>Exemplu

Definire subtip element<categorie> Type <nume-tip> = <nume-tip>

extended with <declaraþie-tip>Exemplu


Definire tip proprietate � se pot utiliza tipuri predefinite ºi tipuri compuse

Property Type <nume-tip> = <declaraþie-tip>Exemple

Exemplu de utilizare tip de proprietate :






Definiþie familie (stil arhitectural) = colecþie de definiþii de tip.

Exemplu :

Exemplu de utilizare :



Acme � CONSTRÂNGERI

Restricþii de combinare a elementelor Definite prin predicate

� Valori : true/false

� Variaþie a �First Order Predicate Logic�� Extinsã cu primitive pentru arhitecturã

� Modelatã conform OCL (de la UML)

� Se pot ataºa la orice instanþã în Acme, inclusiv la întregul sistem sau la familii.

Acme oferã un cadru semantic deschis ce permite punerea în corespondenþã (maparea) a aspectelor structurale ale limbajului cu un formalism logic bazat pe relaþii ºi constrângeri.



Acme � CONSTRÂNGERI

Categorii principale : Invariant ��WUHEXLH�VDWLVIăFXW�SHQWUX�FD�VLVWHPXO�Vă�ILH�OHJDO.Ex. Nu se acceptã bucle în graful C&C.

Euristicã ��SURGXFH�DYHUWL]ăUL�GDFă�QX�H�VDWLVIăFXWă.Ex. Nu se acceptã mai mult de 5 clienþi pentru un server.

Exemplu:Cerinþã : Stabilirea unui invariant care sã impunã ca fiecare client sã fie conectat la

un server.

Soluþie : ataºarea urmãtorului invariant la familia client-server

Invariantforall c : ClientT in self.components

| exists s : ServerT in self.components| connected (c,s);




Definiþie familie (stil arhitectural) = colecþie de definiþii de tip�FRPSOHWDWă�FX�definiþii de constrângeri.



AcmeStudio � instrument software construit peste Eclipse.



Curs 3



PLAN CURS

Elementele care dirijeazã definirea arhitecturii

Exprimãri tipice pentru cerinþe referitoare la atributele de calitate

O metodã mai bunã pentru exprimarea cerinþelor pentru atribute de calitate

O metodã pentru descoperirea cerinþelor pentru atribute de calitate


Elementele care dirijeazã arhitectura

Elementele care dirijeazã definirea arhitecturi sunt date de cerinþele ce stau la baza proiectãrii arhitecturii software.

Cerinþele funcþionale Atributele de

calitate

Constrângerile



Cerinþele funcþionale

Cerinþele funcþionale descriu CE trebuie sã facã sistemul.

La nivelul proiectãrii arhitecturale se stabilesc funcþiile de nivel înalt (nu detaliile).

Pe mãsurã ce arhitectura este creatã ºi rafinatã, vom afla mai multe informaþii despre cerinþele funcþionale de detaliu.


Constrângerile

Constrângerile reprezintã decizii de proiectare �pre-fabricate�.

� Constrângeri tehnice (directe).

� Constrângeri impuse de nivelul business, de piaþã, ºi/sau de companie(indirecte).

Uneori pot apare constrângeri impuse de proiectant.

Exemplu: Pentru persistenþa datelor se va utiliza o�ED]ă�GH�GDWH.

Orice selecþie/decizie devine o constrângere

pentru activitatea ulterioarã de proiectare.


Constrângeri business

Exemple de constrângeri business cu impact arhitectural:

Piaþa þintã ºi timpul de lansare pe piaþã

Aºteptãrile referitoare la costuri ºi la beneficii

Planul de furnizare incrementalã

Durata de viaþã proiectatã pentru sistem

Disponibilitatea forþei de muncã ºi alocarea experizelor

Alinierea structurii echipei cu expertiza disponibilã ºi cu structurile software

Liniile de produse software

sau alte strategii de reutilizare

pentru amortizarea investiþiilor


Constrângerile tehnice

Decizii de proiectare prestabilite ce devin elemente ce îngrãdesc

spaþiul de proiectare.EXEMPLE:

� Utilizarea ºi/sau integrarea cu sisteme legacy

� Tehnologii impuse, limbaje, protocoale, standarde, etc.

Deºi originile constrângerilor sunt diferite, toate vor avea impact

(mai mult sau mai puþin) asupra deciziilor arhitecturale iniþiale.


Atribute de calitate

Cerinþele funcþionale descriu ceea ce trebuie sã facã sistemul.

Cerinþele non-functionale reprezintã tot ceea ce nu este legat

de funcþionalitatea sistemului, cum ar fi modificabilitate, performanþã, etc.

Termenul �cerinþe non-funcþionale��LQWURGXFH�R�IDOVă�partiþionare, deoarece nu se pot descrie atributele de calitate fãrã a descrie funcþionalitatea sistemului.



Def. Atribute de calitate -�FDUDFWHULVWLFL�SH�FDUH�VLVWHPXO�WUHEXLH�Vă�le posede în plus faþã de funcþionalitatea sa.

Reprezintã elementele de dirijare a arhitecturii software care

sunt cel mai greu de descoperit, de exprimat ºi de testat.

Atributele de calitate ºi constrângerile sunt preponderente faþã

de funcþionalitate în dirijarea definirii structurii arhitecturale.


Atributele de calitate ºi arhitectura

Deciziile arhitecturale� implementeazã funcþionalitatea,

� îndeplinesc constrângerile,

� promoveazã unele atribute de calitate

� inhibã alte atribute de calitate.

Arhitectura este element critic în realizarea atributelor de calitate.

O modificare în arhitecturã care îmbunãtãþeºte o calitate poate promova ºi/sau inhiba îndeplinirea altor atribute de calitate.

Arhitectura este element critic în echilibrarea compromisurilor asupra atributelor de calitate înainte de proiectarea de detaliu, de implementare sau de investire în actualizãri la un sistem software.


PLAN CURS






Descrieri tipice pentru cerinþe de sistem

�Timpul de rãspuns al sistemului pentru orice acþiune va fi mai mic de 0.5 sec�

�Funcþiile critice în raport cu timpul cum ar fi trimiterea unei comenzi, comutarea de imagini, grafica, trebuie sã fie �suficient� de performante�

�Sistemul trebuie sã fie tolerant la defecte � astfel încât sã fie minimizate sau

eliminate posibilitatea ºi impactul cãderii serverului. Disponibilitatea ºi funcþionalitatea staþiilor client trebuie menþinutã pe timpul cãderii serverelor sau

a altor clienþi.�

�Sistemul va permite shutdown ºi restart ºi toate componentele RCM (Reliability-Centered Maintenance) pentru a reporni întregul sistem.�

�Sistemul va avea capabilitatea de a detecta cãderile software ºi de a reporni automat componenta corespunzãtoare.�

�O componentã software de tip RCM interogatã va rãspunde la un mesaj în timp de max. 1 secundã.�

�...modificare ºi adaptare flexibilã a HCI (Human-Computer Interface) în vederea creãrii unui �look and feel� specific clientului.�


Descrierea atributelor de calitate (1)

Atributele de calitate sunt deseori dificil de descoperit ºi de exprimat.

Doar numele nu este suficient.

Probleme:� Nu existã un standard larg acceptat ºi utilizat �

vocabularul are variaþii mari.

� Descrierile sunt vagi ºi le lipseºte o mãsura cunatificabilã.

� Din discuþiile asupra �ilitãþilor� sistemului ºi ceea ce înseamnã ele cu adevãrat rezultã dezbateri non-productive.



De exemplu, fie urmãtoarea cerinþã: �Sistemul trebuie sã fie modificabil.�

Cerinþã cu înþeles neclar.

� Nu se poate proiecta un sistem modificabil pentru toate schimbãrile potenþiale.

� Fiecare sistem este modificabil în raport cu un set de schimbãri ºi nemodificabil în raport cu alt set de schimbãri.

� Costul ºi planul de timp (schedule) sunt factori externi structuriisistemului ce pot interzice anumite modificãri ale acestuia.

Problema nu este modificabilitatea � problemele sunt:

� Cum putem anticipa mai devreme schimbãrile?

� Cum putem planifica ºi proiecta sistemul pentru a face faþã schimbãrilor?



Relaþiile dintre atributele de calitate pot fi complexe.

Exemplu: Cãderea sistemului poate fi un aspect de disponibilitate, de securitate ºi de utilizabilitate.

Atributele de calitate sunt deseori în tensiuni reciproce.

Exemplu: Pentru a creºte securitatea sistemului se vor adauga module suplimentare, ceea ce poate duce la scaderea performanþei.

Dacã nu se cunoaºte care atribute de calitate sunt importante atunci:� Nu conteazã care este promovat de arhitectura proiectatã

� Tensiunile nu pot fi rezolvate în mod satisfãcãtor

� Nu existã o bazã pentru a analiza structurile



Arhitectura software afecteazã majoritatea calitãþilor, dar�nu toate aspectele tuturor calitãþilor.

Exemplu: Sã considerãm utilizabilitatea.� Alegerea butoanelor radio, casetelor de dialog�VDX�D�

liniilor de comandã afecteazã utilizabilitatea, dar acestea nu sunt decizii arhitecturale.

� Izolarea acestor decizii astfel încât sã fie modificabile þine de arhitecturã, dar nu afecteazã utilizabilitatea.

Obs. Utilizabilitatea slabã este deseori un simptom al altor probleme legate de atribute de calitate.


PLAN CURS






Scenarii pentru atribute de calitate

Scenariile pentru atribute de calitate sunt metode pentrucaracterizarea mai bunã a atributelor de calitate.

Caracteristicile metodei:

cuantificarea atributelor de calitate prin intermediul scenariilor.

scenariile sunt prioritizate.

bazã de raþionament pentru decizii arhitecturale privind structurile necesare pentru echilibrarea tuturor factorilor care�dirijeazã arhitectura.

cuantificarea este bazã pentru mãsurare conformanþei, completitudinii ºi succesului.


Scenarii pentru atribute de calitate � 6 componente

1. Stimul � O condiþie care afecteazã sistemul.

2. Sursã de stimuli � Entitatea care a generat un stimul.

3. Mediu (Context) � Condiþiile în care a apãrut stimulul.

4. Artefact � Artefactul ce a fost stimulat de cãtre stimul.

5. Rãspuns � Activitatea din sistem ce a rezultat din cauza stimulului.

6. Mãsura rãspunsului � Mãsura prin care va fi evaluat rãspunsul sistemului.

Exemplu: aributul de disponibilitate



Pentru a ilustra proprietãþile diferitelor atribute de calitate folosim urmãtoarele exemple de atribute de calitate de prim rang.

� disponibilitatea� modificabilitatea� performanþa� securitatea


Atribute de calitate - Disponibilitatea

Def. Disponibilitatea se ocupã de avariile sistemului ºi de consecinþele asociate acestora.

Avarierea (cãderea) unui sistem are loc atunci când acesta nu mai

furnizeazã un serviciu consistent cu specificaþiile sale.

Zone de interes :

� Prevenirea avariilor catastrofice ale sistemului

� Detectarea avariilor sistemului

� Revenirea cu succes din avarie

� Timpul necesar recuperãrii sistemului din avarii

� Frecvenþa avariilor

� Moduri degradate de operare datorate avariilor



Stimuli

� defect de: omisiune, crash, temporizare, evenimente, rãspuns

Surse

� interne, externe, software, hardware

Artefacte

� sistem, procesoare, software, hardware, memorie, reþele

Contexte

� operaþional, test, dezvoltare, încãrcare, inert

Rãspunsuri

�Detectare ºi notificare, înregistrare,

�Dezactivare, indisponibilizare, continuare operare în mod degradat

Mãsuri pentru rãspunsuri

� Intervalele critice de timp când

sistemul trebuie sã fie disponibil

� Timpul de disponibilitate

� Intervalele de timp în care sistemul poate opera în mod degradat

� Timpul de reparare

EXEMPLE DE COMPONENTE ALE SCENARIULUI



Exemplu de scenariu de disponibilitate:

�Un mesaj extern neanticipat este recepþionat de proces în

timpul funcþionãrii normale. Procesul informeazã operatorul

despre recepþionarea mesajului ºi continuã sã funcþioneze.�


Atribute de calitate - Modificabilitatea

Def. Modificabilitatea�VH�UHIHUă�OD�costul schimbãrii ºi la uºurinþacu care un sistem software se poate adapta�OD�VFKLPEăUL.

Zone de interes :

� Identificarea schimbãrilor posibile.

� funcþii, platforme, hardware, sisteme de operare, middleware, sisteme cu care trebuie sã opereze, protocoale, etc.

� atribute de calitate: performanþã, disponibilitate, modificabilitate ulterioarã, etc.

� Stabilirea momentului ºi a executantului schimbãrii.



Stimuli

� adãugare/ºtergere/modificarefuncþionalitate sau atribut de calitate

Surse

�Utilizator final, dezvoltator, administrator sistem

Artefacte

�Sisteme, OS, hardware, software

Contexte

� La execuþie, la compilare, la construire (build), la proiectare

Rãspunsuri

� Localizarea zonelor ce vor fi modificate�Realizarea modificãrilor fãrã a induce

efecte colaterale� Testarea modificãrii cu efort minim

�Repartizarea modificãrii cu efort minim


�Costul în termeni de componente, efort ºi bani�Mãsura în care modificarea afecteazã alte

funcþii ºi/sau atribute de calitate




Exemplu de scenariu de modificabilitate:

�Un membru al echipei de dezvoltare doreºte sã modifice interfaþa utilizator a.î.

fundalul sã devinã albastru. Modificarea se va face în cod ºi vor fi necesare

3 ore pentru realizarea ºi testarea ei. În urma acestei modificãri nu trebuie

sã aparã efecte colaterale asupra comportamentului aplicaþiei.�


Atribute de calitate - Performanþa

Def. Performanþa se referã la temporizare: de cât timp are

nevoie sistemul pentru a rãspunde la apariþia unui eveniment.

Zone de interes :

� Surse diferite de evenimente: întreruperi, mesaje, cereri de la utilizatori, tranzacþii, etc.

� Viteze ºi ºabloane variabile de apariþie a evenimentelor: sporadic, periodic, stocastic, combinaþie

� Timpul de rãspuns: timpul scurs între apariþia evenimentului ºi reacþia sistemului



Stimuli

�Apariþia periodicã, sporadicã sau

stocasticã a evenimentului

Surse

� internã, externã, software, hardware

Artefacte

� sisteme, OS, hardware, software

Contexte

� operaþional, test, dezvoltare, încãrcare, inert

Rãspunsuri

�Procesare stimuli


� întârziere, termen (deadline), ratã de

transfer, ratã de insucces, pierdere date




Exemplu de scenariu de performanþã:

�500 utilizatori iniþiazã 1 000 tranzacþii pe minut în manierã stocasticã

în cursul operãrii în condiþii normale ºi fiecare tranzacþie este

procesatã cu o întârziere medie de 2 secunde.�


Atribute de calitate - Securitatea

Def. Securitatea ��PăVXUD�DELOLWăþii sistemului de a rezista la încercãrile neautorizate de utilizare a datelor sau serviciilor, oferind în acelaºi timp acces utilizatorilor legitimi.

Zone de interes :

� non-repudiere: Tranzacþiile nu pot fi repudiate de cãtre nici una din pãrþile participante la tranzacþie.

� confidenþialitate: Datele ºi serviciile sunt protejate la accesele neautorizate.

� integritate: Datele ºi serviciile sunt furnizate conform cu specificaþiile.

� asigurare: Participanþii la o tranzacþie au în realitate identitatea pe care o declarã.

� disponibilitate: Sistemul va fi disponibil pentru utilizãrile legitime.

� auditing: Activitãþile sunt urmãrite în cadrul sistemului la nivele suficiente pentru reconstituirea evenimentelor.



Stimuli

�O entitate încearcã sã afiºeze/modifice/ºteargã date sau sã acceseze

date servicii din sistem

Surse

�O entitate necunoscutã care este identificatã corect/incorect, care este internã/externã sistemului, autorizatã/neautorizatã, ºi care are acces la resurse limitate/vaste

Artefacte

� sisteme, servicii, date

Contexte

� online/offline, conectate/deconectate, protejate/neprotejate




Rãspunsuri

�Autentificare utilizator

�Ascunderea identitãþii utilizatorului�Blocarea accesului la date/servicii

�Garantarea/respingerea accesului la date/servicii

� Întegistrare acces/tentativã de acces la date, modificãri la date

�Memorare date în format codificat

�Recunoaºterea de cereri de date sau servicii inexplicabil de mari sau neobiºnuite

�Raportare/restricþionare acces.Mãsuri pentru rãspunsuri

� Timp/efort/resurse necesare pentru a eluda cu succes mãsurile de securitate

� Timp/efort/resurse necesare pentru a restaura datele/serviciile�Probabilitatea de detectare a atacurilor

�Probabilitatea de identificare a indivizilor responsabili de atac

�Procentul serviciilor disponibile în cursul unui atac de tip �denial-of-services��Mãsura în care datele/serviciile au fost avariate

�Mãsura în care accesele legitime au fost repudiate




Exemplu de scenariu de securitate:

�Un individ identificat corect încearcã sã modifice date din sistem de

la un site extern. Sistemul detecteazã comportamentul maliþios,

menþine un audit al istoricului acþiunilor individului ºi reface datele

în cursul zilei curente.�

Stimul

Sursã stimul

Artefacte stimulate

Context

Rãspuns

Mãsurã rãspuns



Alte atribute de calitate la nivelul sistemului:

� interoperabilitate� siguranþã� utilizabilitate� extensibilitate� portabilitate� uºor de învãþat� scalabilitate� mentenabilitate� testabilitate

Existã ºi atribute de calitate mai particulare, specifice strict unui domeniu (ex. Calibrabilitate).



Atribute de calitate ale arhitecturii propriu-zise:

� Integritate conceptualã

� existã o temã (viziune) care unificã proiectarea sistemului la toate

nivelele.

� Corectitudine ºi completitudine � îndeplinirea tuturor cerinþelor cu respectarea tuturor constrângerilor.

� Constructibilitate � sistemul poate fi construit de echipa disponibilã în timpul dat ºi este

deschis anumitor modificãri pe timpul procesului de dezvoltare.



� Numirea unui atribut de calitate nu este suficientã pentru a-i înþelege corect ºi complet semnificaþia.

� Semnificaþia realã, corectã ºi completã a atributului se poate

transmite utilizând un scenariu.


PLAN CURS






QAW � Quality Attribute Workshop

QAW -��PHWRGă�FDUH�LPSOLFă�Vtakeholder-ii sistemului în descoperirea atributelor de calitate esenþiale pentru un sistem software.

Caracteristici cheie ale metodei QAW

� Centratã pe sistem

� Concentratã pe stakeholder

� Utilizatã înainte de proiectarea arhitecturii software



1. Introducere ºi prezentare metodei QAW

2. Prezentarea afacerii/misiunii

3. Prezentarea planului arhitecturii

4. Identificarea elementelor care dirijeazã arhitectura

5. Brainstorming pentru scenarii

6. Consolidarea scenariilor

7. Prioritizarea scenariilor

8. Rafinarea scenariilor

PROCEDURA

Reiterare de câte ori este necesar,

cu lãrgirea comunitãþii de stakeholder-i.



Participanþii:

� O reprezentare cât se poate de diversã a

stakeholder-ilor. (nu este neobiºnuitã o participare de 20stakeholder-i).

� Echipa QAW -�H[WHUQă�SURLHFWXOXL�:

� Scrib QAW : consemneazã scenariile brute, prioritizãrile lor, scenariile rafinate ºi orice chestiuni relevante

� Coordonator QAW : faciliteazã discuþiile ºi asigurã

faptul cã metoda este aplicatã în manierã eficace ºi oportunã.



Pas 1:

Introducere ºi prezentarea metodei QAW

Obiectiv:

Asigurarea faptului cã toþi stakeholder-ii înþeleg metoda

QAW ºi toþi participanþii au ºansa sã se prezinte.



Pas 2: Prezentarea afacerii / misiunii

Obiectiv: Asigurarea faptului cã toþi cei prezenþi înþeleg:� Contextul business al sistemului� Cerinþele funcþionale de nivel înalt

� Constrângerile de nivel înalt

� Cerinþele de nivel înalt pentru atributele de calitate� Planurile generale pentru dezvoltare (ciclu de viaþã,

domeniu, responsabilitãþi, etc.)

OBS: Aceste elemente reprezintã date de intrare pentru

QAW. (Dacã nu sunt încã cunoscute, atunci este prea devreme pentru QAW).



Pas 3:

Prezentarea planului arhitecturii

Obiectiv:

Arhitectul explicã audienþei rezultatele curente al activitãþilor de definire a arhitecturii, care includ :� Extragerea ºi analiza cerinþelor

� Constrângeri cheie la nivel tehnic ºi la nivel business� Domeniul (de acþiune al) sistemului ºi contextul sãu



Pas 4:

Identificarea elementelor care dirijeazã arhitectura

Obiectiv:

Acord asupra elementelor cheie care dirijeazã arhitectura în raport cu contextul business

Coordonatorul QAW prezintã elementele care dirijeazã

arhitectura pe care le cunoaºte ºi obþine clarificãri/adãugãri/eliminãri din partea stakeholder-ilor.

Pe lista astfel obþinutã se va concentra sesiunea de brainstorming.



Pas 5:

Brainstorming pentru scenarii

Obiectiv:

Generarea unei liste iniþiale de scenarii brute care reflectã

necesitãþile stakeholder-ilor reprezentaþi.

Sesiune de brainstorming în care fiecare stakeholder are ocazia sã genereze cel puþin un scenariu.



Pas 6:

Consolidare scenarii

Obiectiv:

Combinarea scenariilor similare pentru a preveni diluarea în cursul procesului de votare.

Stakeholder-ii care au iniþiat scenariile au cuvântul final

referitor la faptul cã scenariul lor este reprezentat în mod adecvat într-un scenariu combinat.



Pas 7: Prioritizare scenarii

Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-ilor reprezentaþi.

Se utilizeazã o schemã de votare în care fiecare stakeholder are alocat un numãr de voturi egal cu

aprox. 30% din numãrul scenariilor prezente.

Votarea are loc în 2 runde; fiecare stakeholder alocã în fiecare rundã ½ din voturile sale.

Stakeholder-ii pot aloca voturi la scenarii oricum doresc.



Pas 8:

Rafinare scenarii

Obiectiv:

Scenariile principale sunt rafinate.

Pentru fiecare scenariu (dacã timpul o permite) coordonatorul elaboreazã:� Obiectivele business afectate

� Descrierea atributelor de calitate relevante

� Refrazare ca scenariu format din 6 pãrþi componente (stimuli, surse

stimuli, artefacte, contexte, rãspunsuri, mãsuri pentru rãspunsuri)

� Orice întrebare pe care stakeholder-ii o au referitoare la scenariu

� Orice problemã ce apare în cursul rafinãrii



QAWproduce � Scenarii brute pentru atribute de calitate

� Prioritizarea scenariilor� Scenarii rafinate

poate fi utilizat pentru� Rafinare cerinþe� Prioritizare activitãþi de dezvoltare� Identificarea ºi diminuarea riscurilor� Prototipuri � Proiectarea arhitecturii



QAW în context

QAW poate ajuta arhitecþii sã înþeleagã contextul business, comunitatea de stakeholder-i, dorinþele, necesitãþile ºi aºteptãrile acestora în raport cu sistemul software.

Informaþiie produse de QAW reprezintã doar începutul� E posibil ca sã nu fie prezenþi toþi stakeholder-ii

� Timpul este limitat

� Compania ar putea vrea sã modifice prioritãþile� Întrebãri/probleme adiþionale pot sã aparã deoarece nu

toate datele sunt disponibile la momentul desfãºurãrii unui

QAW

va fi necesarã o rafinare considerabilã a scenariilor.


Metodologie generalã

Identificarea ºi gruparea cerinþelor pe categorii: funcþionale, atribute de calitate, constrângeri tehnice ºi business

Formularea cerinþelor funcþionale folosind cazuri de utilizare

Crearea scenariilor pentru atributele de calitate

Determinarea fixitãþii constângerilor

Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup în termeni de importanþã

� Iniþial: critice, importante, bine de avut

� Ulterior: prioritizare în termeni de dificultate

concentrarea atenþiei pe cerinþele importante ºi dificile.


ªablon pentru descriere atribut de calitate

Una sau mai multe mãsuri semnificative prin care va fi judecatã

calitatea rãspunsului. Mãsurile rãspunsului poate fi date în termeni de ore-persoanã, detecþie erori, timp de rãspuns, timp de recuperare, etc.

Mãsuri semnificative:

Rãspunsul dorit din partea sistemului.Rãspunsul sistemului:

Elementele sistem afectate de stimul. În etapele iniþiale ale ciclului de dezvoltare (înainte de proiectarea arhitecturalã) elementele afectate ar putea sã nu fie cunoscute. Dupã începerea proiectãrii, scenariile trebuie rafinate iar elementele identificate în momentul în care devin cunoscute.

Elemente sistem:

Descrierea contextelor relevante care ar putea afecta rãspunsul ºi mãsuri semnificative ale rãspunsului. Poate include condiþii ca operare normalã, încãrcare de vârf, operare degradatã, în timpul dezvoltãrii, etc.

Context:

Fenomenul care determinã sistemul sã reacþioneze într-un anume fel. Poate fi o cerinþã utilizator, un eveniment sau o întrerupere, o eroare, o cerere de modificare, etc.

Stimul(i):

Sursa/sursele generatoare sau potenþial generatoare pentru stimul(i).Surse stimuli:

Descriere brutã a atributului de calitate:Fie un nume (ex. Modificabilitate) fie o propoziþie ce încearcã sã descrie o cerinþã pentru un atribut de calitate

sau pentru o proprietate a sistemului.

ID scenariu: ReferinþãTitlu scenariu: Titlu (descriptiv)


CONCLUZII

Elementele care dirijeazã arhitectura impun forma acesteia

� cerinþe funcþionale de nivel înalt, constrângeri tehnice ºi constrângeri business, atribute de calitate

Atributele de calitate ºi constrângerile sunt preponderente faþã

de funcþionalitate în dirijarea definirii structurii arhitecturale.

Atributele de calitate sunt dificil de descoperit ºi de documentat.

Scenariile pentru atribute de calitate permit caracterizarea clarã

ºi completã a atributelor de calitate.

QAW este o metodã ce implicã stakeholder-ii sistemului în descoperirea atributelor de calitate esenþiale.



Curs 4



PLAN CURS

Structuri software ºi ºabloane

Familia de stiluri pentru structuri de tip flux de date

Familia de stiluri pentru structuri de tip call-return


Structuri software

Structurile sunt componente reale ale unui sistem software.

Reprezentãrile arhitecturale sunt abstractizãri ale structurilor reale cuprinse într-un sistem software.

Structurile sunt de mai multe tipuri: cod, proces, hardware, etc.

Tipurile de structuri percepute depind de perspectivã.

Reprezentarea unei structuri este o vedere (view) ºi depinde, de asemenea, de perspectivã.


Structuri

AllocationLinii serialeWireless...

Fisiere executabileCalculatoareSenzori�

Fizicã

C&CFlux de dateEvenimente...

ProceseFire de execuþie...

Dinamicã

ModuleDependenþãApel...

Straturi (layers)Module de cod...

Staticã

Tip de vederiExemple de relaþii

Exemple de structuri

Perspectiva


Stiluri

Stil ��VWUXFWXUă�JHQHUDOă�D�XQHL�IDPLOLL�GH�VLVWHPH�FX�WUăVăWXUL�similare ºi care apar în mod repetitiv în realitate.

Se bazeazã pe:� Natura elementelor� Aranjarea topologicã� Natura relaþiilor între elemente

Exemple: stiluri pentru flux de date, stiluri distribuite, stiluri cu evenimente, etc.

Stil = ºablon arhitectural


ªabloane (Patterns)

Experþii reutilizeazã esenþa soluþiei unei probleme similare (gândire

în perechi PROBLEMÃ-SOLUÞIE)

Categorii de ºabloane funcþie de granularitate:

ªablon arhitectural

Tacticã

ªablon de proiectare

Idiom


ªabloane (stiluri) arhitecturale

Stil arhitectural = structurã fundamentalã care Defineºte o soluþie generalã pentru un anume tip de probleme

�Împacheteazã� ºi defineºte o familie de structuri arhitecturale generale

Posedã proprietãþi cunoscute

Selectarea unui ºablon arhitectural este deseori prima alegere majorã pe

care o face arhitectul software.

Arhitectul trebuie sã cunoascã formele pure de stiluri arhitecturale pentru a le înþelege punctele tari, punctele slabe ºi consecinþele devierilor de la forma purã.

În realitate Sistemele deviazã în general de la formele pure

Sistemele combinã simultan mai multe stiluri arhitecturale


ªabloane (stiluri) arhitecturale

Definesc:

Un set de tipuri de elemente ºi responsabilitãþile generale asignate acestora

Un set de tipuri de relaþii între elemente

Un aranjament topologic al elementelor ºi relaþiilor

Reguli semantice referitoare la modul de conectare, interacþiune ºi transformare a elementelor ºi relaþiilor

Exemple canonice

Dacã se aderã la semantici, stilul va promova unele proprietãþi ºi va inhiba altele.


Tactici

Oferã o schemã pentru rafinarea elementelor unui sistem software ºi a relaþiilor dintre acestea.

Sunt independente de limbajul de programare

Se adreseazã unor probleme mai fine�GH�SURLHFWDUH�GHFkW�stilurile arhitecturale

Promoveazã direct atributele de calitate

Pot fi utilizate pentru a rafina ºabloane de proiectare de granularitate mare

(concept introdus oficial de SEI în 2003)


Exemplu ��7DFWLFă�SHQWUX�GLVSRQLELOLWDWH


ªabloane de programare

Design patterns

Granularitate�PDL�PLFă�GHFkW�VWLOXULOH�DUKLWHFWXUDOH.

Se concentreazã pe arhitecturi OO.

Se concentreazã pe structuri de clase ºi probleme de construire a codului, nu pe structuri ºi proprietãþi la nivel de sistem.

Considerã cã modularitatea ºi reutilizarea sunt cele mai importante atribute de calitate pe care proiectarea trebuie sã le adreseze.


ªabloane � viziune de ansamblu

Client Server

Main Loop{

read sensorapply correction constant write data to memorymove actuatorcheck for error:

}

ªabloan (stil) arhitectural - utilizat la începutul proiectãrii de nivel înalt pentru a adresa proprietãþi la nivel de sistem.

Tacticã -�XWLOL]DWă�SHQWUX�D�UDILQD�HOHPHQWHOH�arhitecturale înainte de implementare.

Idiom - utilizat la proiectarea de detaliu la nivel de element

MVC, Abstract Factory, Flyweight, Proxy,� ªablon de programare ��VH�DGUHVHD]ă�problemelor de proiectare orientate pe cod.


Importanþa ºabloanelor arhitecturale

Punct de plecare în activitatea de proiectare � de obicei se începe cu alegerea unui ºablon general de partiþionare.

Oferã un vocabular comun pentru proiectanþi

� ªabloanele expun proprietãþi cunoscute.

� Mijloc de descriere soluþii de proiectare la diferite probleme ºi de discutare a meritelor ºi neajunsurilor acestora.

Independente de domeniu ºi de limbaj

Sistemele reale sunt compuse din ansambluri de ºabloane

� Arhitecþii pot judeca proprietãþile ansamblului prin prisma proprietãþilor ºabloanelor componente.

Oferã pârghii pentru

� Proiectanþi : arhitecþii selecteazã acele structuri care îndeplinesc cerinþele funcþionale ºi atributele de calitate.

� Evaluatori : cei care�VWXGLD]ă�SURLHFWHOH�DUKLWHFWXUDOH�SHQWUX�D�VH�DVLJXUD�Fă�îndeplinesc cerinþele funcþionale ºi atributele de calitate.


Idiom

ªablon de nivel inferior orientat pe cod sau structurã primitivã

de date.

Specific pentru

� Limbaj de programare (ex. Java: Observer, Observable)

� Categorie de limbaje (ex. moºtenire, polimorfism, pentru limbajele OO)


Structuri

Structurile sunt componente reale ale unui sistem software.

Reprezentãrile arhitecturale sunt abstractizãri ale structurilor reale cuprinse într-un sistem software.

Recomandare : analizã structuri în termeni de :

Perspectiva ºi vederea�UHSUH]HQWDWă

Aranjarea topologicã (de obicei ��GHVHQXO�VDX�UHSUH]HQWDUHD�canonicã)

Elemente ºi relaþii (fundamentele structurii)

Semanticile�VWUXFWXULL

Calitãþile promovate ºi cele inhibate�GH�VWUXFWXUă

Contextul tipic de utilizare, exemple, variante structurale.


PLAN CURS

Structuri software ºi ºabloane

Familia de stiluri pentru structuri de tip flux de date

Familia de stiluri pentru structuri de tip call-return


Stiluri specifice perspectivei C&C

Def. Stil arhitectural = specializare pentru tipuri de elemente ºi de relaþii, împreunã cu un set de constrângeri referitoare la modul de utilizare a acestora.

Din perspectivã dinamicã:

Un set specific de tipuri de componente

Un set specific de tipuri de conectori

Reguli de combinare a componentelor ºi conectorilor



C&C captureazã aspectele dinamice ale sistemului

Stilul - asociat cu un model computaþional care defineºte fluxul datelor ºi fluxul de control

Modele computaþionale : Data flow � calculul dirijat de fluxul datelor în sistem

Call-return � componentele interacþioneazã prin invocãri sincrone ale

capabilitãþilor oferite de alte componente

Event-based - componentele interacþioneazã prin evenimente sau mesaje

asincrone

Repository - componentele interacþioneazã printr-o colecþie vastã de date

persistente partajate


Familia de stiluri pentru flux de date (data flow)

Sistem în flux de date � caracteristici fundamentale:

Structura de proiectare este determinatã de circulaþia datelor�GH�OD�R�componentã la alta.

Disponibilitatea datelor�FRQWUROHD]ă�FDOFXOHOH.

Fluxul de date este explicit.

Aceasta este singura�IRUPă�GH�FRPXQLFDUH între componente.

Variaþii � funcþie de:

Modul de exercitare a controlului (ex. push vs. pull)

Gradul de concurenþã dintre procese

Gradul de calcul incremental

Restricþii topologice, etc.


Elemente pentru flux de date

Elemente: procesãri date

Tipurile de interfeþe sunt port de date de intrare ºi port de date de ieºire

� Port de intrare � citeºte date

� Port de ieºire � scrie date

Modelul computaþional : citeºte date de la port(uri) de intrare,�calculeazã, scrie date la port(uri) de ieºire

Relaþii: fluxuri(streams) de date

Unidirecþional (de obicei asincron, buffer-at)

Interfeþele sunt rolurile de reader ºi writer

Modelul computaþional : transferul datelor de la rolul writer la rolul reader


Flux de control vs. Flux de date

Flux de control

Modul în care controlul parcurge programul sau sistemul.

Datele pot urma controlul, dar nu reprezintã forþa determinantã pentru

arhitecturã.

Flux de date

Modul în care datele circulã printr-o colecþie de unitãþi de calcul.

Controlul (ºi calculul) sunt activate de disponibilitatea datelor.

Obs. ªabloanele arhitecturale pentru flux de date nu sunt acelaºi lucru cu DFD din analiza structuratã tradiþionalã.


Stiluri din familia flux de date

Batch sequential

Procesare secvenþialã; componentele transformã toate datele de

pe intrare dupã care rezultatul este trimis spre prelucrare

urmãtoarei componente.

Tipic pentru primele aplicaþii pentru sisteme de management al informaþiilor (MIS).

Pipe-and-filter

Procesare incrementalã; componentele aplicã transformãrile ºi transmit rezultatul componentei urmãtoare pe mãsurã ce primesc

date. Tipizate de cãtre Unix

Control de proces

Structurã în buclã pentru a controla

variabilele de context


Stilul batch sequential

Program Program Program ...

Flux de date prin memorie externã

Unitãþi de calcul



Topologie Elementele sunt etapele de procesare, conectate prin flux de date.

Perspectivã ºi viewtype

Perspectiva dinamicã.

C&C Viewtype ��DUDWă�procesele (componente) ºi conexiunile stabilite la execuþie (conectori).

ProcessA

Output1Process

BOutput2

ProcessC

OutputInput



Semantici Datele de intrare sunt transformate secvenþial; la fiecare pas datele

sunt procesate în totalitate.

Procesele sunt independente ºi nu partajeazã stare cu alte

procese.

Procesarea concurentã este imposibilã. Datele de ieºire ale unui proces sunt memorate în fiºiere ºi devin

intrãri pentru procesul urmãtor.

În mod ideal, formatul datelor de ieºire ale unui proces este compatibil cu formatul datelor de intrare pentru urmãtorul proces.

Procesele pot începe atunci când toate datele lor de intrare sunt

pregãtite ºi se opresc când nu mai existã date ºi procesarea a fost încheiatã.

Deseori sunt necesare mecanisme de control al job-urilor (definite

utilizând JCL � job control language).



Atribute de calitate promovate Simplitate ��LQWHJULWDWH�FRQFHSWXDOă

Reutilizarea proceselor Modificabilitate ��SURFHVăULOH�SRW�IL�Xºor stabilite folosind limbaje de

control (JCL)

Detecþie ºi tratare erori, recuperare sistem � problemele se pot izola relativ uºor.

Atribute de calitate inhibate Performanþã

Interactivitate (imposibilã)

Necesitã intervenþie ºi supraveghere umanã


ªablonul batch sequential - exemple

Aplicaþii tipice Procesarea clasicã a datelor

� Calcul taxe� Calcul impozite

Primele medii de dezvoltare de software


Stilul pipe-and-filter

Modelul computaþional:Structurã ce proceseazã fluxuri de date prin transformarea

incrementalã a datelor�GH�FăWUH�HOHPHQWH�VXFFHVLYH.

Îmbogãþire date prin calcule ºi adãugare de informaþii

Rafinare prin distilarea datelor sau prin îndepãrtarea informaþiilor nerelevante

Transformare�GDWH�SULQ�VFKLPEDUHD�UHSUH]HQWăULL�ORU

Filtrele nu cunosc identitatea filtrelor precedente sau urmãtoare ansamblul de calcul este o compunere funcþionalã a funcþiilor filtrelor



Tipuri de componente: Filtru Citeºte date de la unul sau mai multe porturi de intrare, le transformã ºi scrie

rezultatele pe unul sau mai multe porturi de ieºire Poate funcþiona concurent cu alte filtre

Transformã fluxuri (de intrare) în fluxuri (de ieºire)

Nu pãstreazã starea de la o instanþiere la alta

Tipuri de conectori: Pipe (conducta) Transferã datele de la un port de ieºire a unui filtru la un port de intrare al altui filtru

Are un singur rol de intrare date ºi un singur rol de ieºire date Transfer unidirecþional, cu pãstrarea ordinii, cu pãstrarea datelor (canal de

comunicare buffer-at) Conductele formeazã grafuri pentru transmiterea datelor

Relaþii : Ataºare Asociere port de ieºire date al unui filtru cu rol de intrare date al unei conducte ºi port

de intrare date al unui filtru cu rol de ieºire date al unei conducte



Topologie Elemente (filtre) legate prin relaþii (conducte)

Perspectivã ºi viewtype


C&C viewtype ��DUDWă�SURFHVHOH/firele de execuþie (filtre) ºi conexiunile (pipes) stabilite la execuþie.


Stilul pipe-and-filter � Semantici (1)

Filtrele pot funcþiona asincron ºi concurent

Datele sunt transformate incremental

Corectitudinea datelor de ieºire nu trebuie sã depindã de ordinea în care se executã filtrele din cadrul sistemului

Elementele din sistem se activeazã în prezenþa datelor, dar execuþiile sunt non-deterministice (fitrele pot trimite (push) sau extrage (pull) date).

Filtrele sunt independente ºi nu partajeazã date, servicii sau stare cu alte filtre� Nu existã un context extern în procesarea fluxurilor� Nu se pãstrazã starea de la o instanþiere la alta� Nu se cunosc informaþii despre filtrele precedente sau ulterioare

Rata de procesare a filtrelor depinde de rata cu care datele sunt disponibile

Funcþia realizatã de un filtru este determinatã la configurarea

sistemului. Odatã cu construirea sistemului se stabileºte definitiv funcþia compusã

aplicatã fluxului de date.


Stilul pipe-and-filter � Semantici(2)

Flux de date unidirecþional, cu pastrarea ordinii ºi conþinutului

Conductele nu au stare ºi sunt utilizate pentru a transfera datele

Ieºirea unei conducte se poate conecta doar la un port de intrare al unui filtru sau la destinaþia finalã a datelor (data sink).

Intrarea unei conducte se poate conecta doar la un port de ieºire sau la sursa de date.

Deseori sunt necesare mecanisme speciale pentru a face legãturi.

Conductele ofera posibilitãþi de memorare infinite pentru a permite citiri/scrieri asincrone



Atribute de calitate promovate Simplitate ��LQWHJULWDWH�FRQFHSWXDOă

Reutilizarea filtrelor datoritã independenþei funcþionale a acestora Modificabilitate � legarea conectorilor la execuþie (late binding)

permite reconfigurarea simplã a reþelei de conducte ºi filtre

Atribute de calitate inhibate Performanþã � se poate creºte prin paralelizarea procesãrii datelor

Interactivitate (dificilã)

Detectarea ºi tratarea erorilor ºi refacerea sistemului


Stilul pipe-and-filter - exemple

Sisteme de procesare semnale � ex. Sistem de colectare a datelor de telemetrie

Recepþionarea fluxului de date de telemetrie, decomutare cadre (separare canale multiple de date codificate), aplicare de coeficienþi, afiºare ºi memorare date.

Frame Collection

Major Frame Decom

Minor Frame Decom

Measurement units

Time Tag Frame

Apply coefficients

Display Data Record Data


Stilul pipe-and-filter - exemple

Filtre: procese Unix

Conducte: fluxuri buffer-ate suportate de sistemul de operare

Fiºierele sunt considerate surse ºi destinaþii finale de date; spre deosebire de filtre, fiºierele sunt pasive.

Surse ºi destinaþii finale de date, built-in: stdin, stdout, stderr În general, filtrele transformã datele de la stdin ºi trimit rezultatul la

stdout Conductele transferã fluxuri de caractere ASCII (sau UniCode)

� Avantaj: orice poate fi conectat la orice

� Dezavantaj: orice informaþie trebuie codificatã (ASCII, UniCode), transferatã, apoi decodificatã.

Exemplu:

cat/etc/passwd | grep �joe� | sort > junk

cat grep sortpasswd junk


ªablonul pipe-and-filter - exemple

Arhitectura de procesare a cererilor de la Apache Web server

Paradigma map-reduce�GH�OD�PRWRDUHOH�GH�FăXWDUH

Yahoo!Pipes pentru procesare RSS feedshttp://pipes.yahoo.com/pipes

Sisteme de calcul ºtiinþific ce proceseazã ºi analizeazã

cantitãþi mari de date experimentale

http://pipes.yahoo.com/pipes


Comparaþie ºabloane

Descompun sistemul în elemente ce interacþioneazã doar prin intermediul

datelor transferate între acestea.

Batch Sequential

� Granularitate mare

� Latenþã mare între paºii de procesare

� Acces extern la intrare

� Concurenþa este imposibilã

� Non-interactivitate

� Datele sunt procesate în întregime la fiecare pas

Pipe-and-Filter

� Granularitate finã

� Prezenþa datelor porneºte procesarea

� Intrare localizatã

� Concurenþa este posibilã

� Interactivitate dificilã, dar posibilã

� Datele sunt procesate incremental


Variante ale stilului pipe-and-filter

Filtre cu buffer-are � Eventual ºi prelucrãri simple ��H[. ordonare

� Scãdere de performanþã

� Limitare la memoria internã disponibilã

Obs. O posibilã soluþie de utilizare a memoriei externe violezã semanticile stilului ºi poate submina proprietãþile de reconfigurare ºi reutilizare promovate de stil ºi conduce,�GH�asemenea, la scãderea performanþei.

Reþele concurente� Divizarea procesãrii pe structuri paralele.� Promoveazã performanþa, cu excepþia cazurilor în care existã gâtuiri

pe flux.

Filtre cu difuzare (broadcasting) de evenimente� Lansare eveniment de obicei atunci când apare o problemã la filtru.

� Se va urmãri menþinerea unei cuplãri slabe (eventual nule) cu alte elemente, pentru a nu viola semanticile stilului.


Criterii pentru alegerea stilului pipe-and-filter

Sarcina (task) este dominatã de disponibilitatea datelor.

Datele pot fi transferate în mod predictibil de la un proces la altul.

Alegere bunã pentru multe aplicaþii pe flux de date deoarece:

� Permite reutilizarea ºi reconfigurarea filtrelor.

� Sistemul poate fi analizat uºor.

� Reduce efortul de testare a sistemului ºi de re-testarea de dupã

reconfigurare.

� Permite procesare incrementalã ªI procesare paralelã.

Performanþa este determinatã de filtrul cel mai lent.


Stiluri pentru control proces

SISTEME DE CONTROL

Inginerii sistemelor de control utilizeazã sistemele de calcul pentru:� monitorizarea unui fenomen fizic � exercitarea controlului asupra unui sistem pe baza mãsurãrii datelor

de intrare.

Clasificare 1: Sisteme de control cu evenimente discrete Sisteme cu control continuuObs. Majoritatea sistemelor reale utilizeazã ambele strategii de control.Ne ocupãm de sistemele cu control continuu.

Clasificare 2: Sisteme de control în buclã deschisã

Sisteme de control în buclã închisã


Stiluri pentru control proces

SISTEME DE CONTROL � exemple

Sistemele de încãlzire, ventilare ºi aer condiþionat (HVAC)

Sisteme ambientale inteligente

Sisteme de control pentru motoarele automobilelor

Sisteme de manufacturare ºi producþie

Sisteme pentru pompieri ºi securitate

Electrocasnice

Roboþi ºi subsistemele lor

Simulatoare, sisteme aerospaþiale, etc.


Control în buclã deschisã

Un sistem de control în buclã deschisã nu necesitã

mãsurarea variabilelor de ieºire pentru a corecta erorile.

Reglarea se face prin intervenþie externã (manualã).

Soluþie simplã ºi bunã dacã variaþiile sunt mici.

Dacã variaþiile sunt mari sau bruºte, solicitã atenþie frecventã

din partea operatorului uman.

Avantaj : simplitate

Dezavantaj: insensibil la dinamica în timp a sistemului controlat.


Control în buclã închisã

Strategie de control mai sofisticatã.

Se fac mãsurãtori asupra mediului ºi asupra ieºirilor din sistem.

Valorile mãsurate sunt folosite ulterior pentru a regla automat sistemul.

Forme de control:� Feedback

� Feed-forwardObs. În practicã se utilizeazã uneori o combinaþie a celor douã forme de control, rezultând trei

ºabloane diferite.

Feedback

� Proces prin care o parte din semnalul de ieºire sau o funcþie aplicatã

acestuia este transmisã înapoi pe intrarea elementului de control.

� Are loc în timp real, permiþând controlul sistemului în timp ce acesta funcþioneazã.


Stil pentru control în buclã închisã, cu feedback

Intrare de referinþã - una sau mai multe intrãri ce reprezintã valorile

ideale ale variabilelor controlate.

Informaþii de dirijare � datele trimise la instalaþie ºi care dirijeazã

volumul de activitate al instalaþiei.

Controller � unul sau mai multe elemente responsabile sã furnizeze semnale de dirijare a instalaþiei.

Instalaþie � elementul sistemului care reacþioneazã

la informaþiile de dirijare, executã operaþiile ºi manipuleazã variabilele controlate.

Variabile de intrare � zero sau mai multe intrãri care sunt

alimentate (sau eºantionate) continuu de cãtre controller.

Variabile controlate � ieºirea sistemului, reprezentând

cantitatea ce trebuie menþinutã la o anumitã valoare.

Feedback � �semnalul��FDUH�UHSUH]LQWă�R�SDUWH�VDX�R�IXQFþie aplicatã asupra

variabilei controlate; este returnat la controler.


Stiluri pentru sisteme de control

ªablonul pentru sistem de control în buclã închisã, cu feedback- granularitate foarte mare (grad ridicat de generalitate) poate fi utilizat doar ca punct de plecare în proiectarea sistemelor de control.

Probleme rãmase deschise:

Evenimente discrete vs. Buclã de control continuu

Combinaþia dintre control proporþional, integral ºi diferenþial� proporþional cu valoarea erorii, � diferenþial - reacþie funcþie de variaþia erorilor, � PID - proporþional-integral-derivativ

Modalitãþi de reglare ºi de facilitare a reglãrii

ªablonul permite proiectanþilor sã aloce elementelor responsabilitãþi în etapele iniþiale de proiectare,

în vederea obþinerii unor proprietãþi generale la nivel de sistem.


Stiluri pentru sisteme de control

În sistemele de control existã o cuplare strânsã între elementele fizice ºi elementele software; consecinþe:

Promovarea performanþei

Reducerea dimensiunii codului executabil ºi consumului de memorie

Inhibarea modificabilitãþii ºi abilitãþii de a reutiliza elemente (în general)

Sistemele de control pun probleme speciale de dezvoltare. Pe lângã

controlul fizic, sistemul trebuie :

sã rãspundã repede ºi deterministic

sã fie sigur ºi sã aibã un grad foarte mare de disponibilitate în medii extreme.



Curs 5




Perspectiva dinamicã � modul în care sistemul este structurat ca set de unitãþi de execuþie (elemente ce au comportament ºi interacþiuni la momentul execuþiei).

Vederile reprezintã componentele sistemului ºi conectorii dintre acestea. Tipul de vedere este C&C Viewtype.

Utilitate: Ilustrarea structurii sistemului în regim dinamic

Ghid pentru dezvoltarea sistemului

Analiza sistemului în raport cu atributele de calitate specifice regimului

dinamic (ex. performanþã, fiabilitate, disponibilitate)





� componentã = unitate de calcul ºi/sau memorare date pe

timpul execuþiei; accesibilã prin porturi care expun

intefeþele componentei.

� conector = mecanism de interacþiune între componente;

defineºte roluri care expun interfeþele conectorului.

Tip de port/rol = interfaþã = replici multiple*�OD�R�FRPSRQHQWă/conector

*Notaþie multiplicitate: [a] create static, [0..b] create dinamic




ComponentãExemple Proces, obiect, client, server, datastore, complexe � reprezentate pe nivele multiple de

detaliu

ConectorCategorii: link ºi protocol de comunicare, flux informaþii, acces la memorie

partajatãExemple Invocare servicii, cozi mesaje asincrone, multicast evenimente, pipe Canal de comunicare orientat pe tranzacþii, ESB (enterprise service bus)

Înglobeazã un protocol de interacþiune (ordine interacþiuni, punctul curent de

control, gestionare condiþii de eroare ºi time-out) � trebuie documentat.

Reprezintã forme complexe de interacþiune ��GHWDOLHUH�XOWHULRDUă�FD�subsistem C&C.

Ex. High level ��DSHO�GH�SURFHGXUăDetalii în context distribuit: Protocoale pentru time-out, gestionare erori, împachetare/despachetare date, localizare

furnizor





� �attachment� � ataºare port al componentei la rol al conectorului

� �interface delegation� � asociere port cu porturi ale

subcomponentelor; asociere rol cu roluri ale structurii interne

Condiþii :

� Ataºare validã : port � rol ; cu respectare protocol de interacþiune

� Delegare interfaþã între porturi/roluri compatibile

� Conectorul trebuie ataºat la o componentã (nu poate exista izolat)




Tipuri ºi instanþe

Tip � definiþie pentru o clasã de componente sau conectori; set de variante. Nivele de specializare:

� Stil arhitectural (ex.�FOLHQW, server, conector cerere/rãspuns)� Tehnologie (ex. Java servlet, EJB, MySQL)� Domeniu (servlet control comunicare cu ATM)� Aplicaþie

Instanþã ��UHSUH]HQWDWă�SH�R�GLDJUDPă�&&C; Conformã cu un tip în termeni de:

� Comportament� Interfeþe (tip ºi multiplicitate)� Substructuri� Proprietãþi� Restricþii topologice



NOTAÞII

Informale : box-and-lines

UML : diagrama de componente

Acme (AcmeStudio) :



Reprezentare parþialã a claselor de stiluri C&C

Clements, Bachmann, Bass, Garlan, Ivers, Little, Nord, Stafford, Documenting Software Architectures: Views and Beyond, Second Edition, Addison Wesley, 2010

Calcul dirijat de fluxul datelor în sistem

Invocãri sincrone ale

capabilitãþilor oferite de componente

Calcul dirijat de evenimente sau mesaje asincrone

Comunicare printr-o colecþie vastã de date

persistente partajate

Stil arhitectural � specializare pentru tipuri de elemente ºi de relaþii, împreunã

cu un set de constrângeri referitoare la modul de utilizare a acestora.


PLAN CURS

Familia de stiluri call-return

Stilul client-server

Stilul peer-to-peer

Stilul SOA (service oriented architecture)

Stilul în trepte � specializare pentru client-server

Arhitecturã aplicaþii Web � specializare pentru stilul în trepte

Arhitecturã aplicaþii Java EE � specializare pentru stilul în trepte


Stiluri pentru structuri call-return - fundamente

Modelul computaþional :

Conþin elemente ce oferã servicii altor elemente.

Componente : furnizor serviciu, consumator serviciu

Conectorii - transferã cererea de la producãtorul de serviciu la consumatorul

acestuia ºi rezultatul în sens invers.

Elementele depind de serviciile invocate pentru a-ºi îndeplini reponsabilitãþile proprii.


Stiluri pentru structuri call-return - fundamente

Serviciile pot funcþiona în 2 moduri:

� Blocant ��HOHPHQWHOH�VROLFLWDQWH�WUHEXLH�Vă�Dºtepte terminarea serviciului invocat înainte de a-ºi putea continua activitatea.

� Non-blocant � elementele solicitante îºi pot continua activitatea dupã invocarea unui serviciu, în paralel cu acesta.


Stiluri pentru structuri call-return - componente

Furnizor serviciu ��FRPSRQHQWă�FX�XQD�VDX�PDL�PXOWH�LQWHUIHþe prin care oferã servicii.

Categorii de interfeþe :� Expune un set de servicii utilizabile de cãtre alte elemente. (provided)

� Expune un set de servicii pe care alte elemente trebuie sã le ofere. (required)

De obicei, componentele cunosc identitatea elementelor pe ale cãror servicii se bazeazã, DAR� Nu întotdeauna� Numele furnizorului de servicii poate deveni cunoscut pe parcurs.

Componentã ��SRDWH�IL�FRPSOH[ă, cu multe detalii de proiectare (nu

doar o clasã sau o funcþie)


Stiluri pentru structuri call-return - componente

Serviciile sunt de obicei grupate ºi împachetate în baza unui scop comun:

� Pentru simplitatea mentenanþei si a modificãrii

� Pentru facilitarea reutilizãrii unor elemenãtorte arhitecturale de dimensiuni mari

� Pentru a crea unitãþi vandabile

� Pentru a partiþiona construirea elementelor în raport cu forþa de muncã de dezvoltare


Stiluri pentru structuri call-return � relaþii (1)

Relaþiile sunt baza pentru schimbul de informaþii ºi de control între elemente.

Categorii de relaþii:� Asimetricã

� Participanþi : apelant ºi apelat� Semanticã : apelatul oferã servicii utilizate de apelant

� Exemplu : apel de procedurã

� Simetricã (peer-to-peer)

� Participanþi :�GRXă�HOHPHQWH, fiecare putând fi atât apelant cât ºi apelat

� Semanticã : fiecare element poate furniza servicii celuilalt

� Exemple : sisteme OO


Stiluri pentru structuri call-return � relaþii (2)

Responsabilitãþile pentru control ºi pentru date nu sunt separate.

Relaþii între date : � Datele pot fi transferate în ambele sensuri, ca parametri de la

apelant la apelat ºi ca rãspuns în sens invers.

Relaþii pe fluxul de control:� Forma cea mai simplã

� de la apelant la apelat, apleantul blocându-se în aºteptarea rãspunsului.

� Forme mai complexe � Protocol de interacþiune ce defineºte secvenþe de cereri ºi rãspunsuri

� Pot implica concurenþã ºi rendezvous/joining


Stiluri pentru structuri call-return -�VHPDQWLFă

Corectitudinea funcþionalã a sistemului este ierarhicã.

Corectitudinea oricãrui element arhitectural depinde de corectitudinea elementelor pe ale cãror servicii se bazeazã.

Conduce în mod natural la specificarea design-lui pe bazã de interfaþã

ºi de pre/post-condiþii� Precondiþii � condiþiile în care poate fi solicitat serviciul

� Postcondiþii � condiþiile asupra rezultatului invocãrii serviciului

Momentul legãrii (binding) apelului la recipient:� Static - la compilare (ex. tipuri abstracte de date tradiþionale)

� Dinamic � la execuþie (ex. sisteme OO)� Prin intermediar (broker) ��XWLOL]DUHD�XQXL�EURNHU�GH�RELHFWH�SHQWUX�D�

gãsi obiecte ºi servicii (ex. RMI, RPC)


Stiluri pentru structuri call-return � atribute de calitate

Atribute de calitate promovate� Modificabilitate prin separare (probleme ºi interfaþã)

Modificabilitatea este mãritã pe bazã de apeluri ºi rãspunsuri puþine ºi depinde în mod esenþial de o bunã

asignare a reponsabilitãþilor. Încapsularea ºi moºtenirea (în paradigma OO)�

promoveazã reutilizarea elementelor.

Atribute de calitate inhibate� Performanþa este inhibatã de cãtre ramificaþiile de control.

� Comportamentul corect ºi disponibilitatea sunt distribuite pe mai multe elemente.


PLAN CURS



Stilul peer-to-peer







Tip componente: client, server� Client ��LQYRFă�VHUYLFLL (consumator)� Server ��RIHUă�VHUYLFLL (furnizor)

Tip conectori : cerere/rãspunsroluri: cerere, rãspuns

Relaþia : ataºare port cerere client cu rol cerere conector ºi port rãspuns

server cu rol rãspuns conector.



Modelul computational:

Client - iniþiazã interacþiune prin invocare serviciu la server ºi se blocheazã în aºteptarea rezultatului.

Server ��DVWHDSWă�VROLFLWăUL, executã calcule ºi trimite rãspuns.

Comunicare asimetricã : clientul cunoaºte identitatea serverului înainte de apel, nu ºi reciproc.



Variante :

� Server-ele pot iniþia acþiuni asupra clientului prin proceduri de notificare (call-back) înregistrate de client la server.

� Interacþiune multiplã în cadrul unei sesiuni.

� Componente server pot fi clienþi pentru alte componente

Specializãri � exemple de restricþii suplimentare:

� Numãrul de ataºãri la un port dat

� Relaþii permise între servere

� Creare ierarhie pe mai multe trepte (tiers) prin grupare ºi distribuire componente. Exemple ?



Atribute de calitate promovate :

� Extensibilitate ��DGăXJDUH�GH�QRL�FOLHQþi ºi servere

� Modificabilitate ºi reutilizare - prin separare servicii comune

� Scalabilitate ºi disponibilitate - cu replicare server

Permite analizarea dependabilitãþii, securitãþii ºi capacitãþii de transfer date (throughput).

Atribute de calitate inhibate

� Fiabilitatea

� Performanþa

� Securitatea

� Simplitatea � sisteme cu complexitate mare; dificil de testat ºi de întreþinut.


PLAN CURS



Stilul peer-to-peer






Stilul peer-to-peer

Componente : procese independente

Conectori : call/return � Comunicare bidirecþionalã între 2 sau mai multe componente

Relaþii : ataºare dinamicã componentã cu conector


Stilul peer-to-peer

Model computaþional :

Cooperare componente ale unui peer ; fiecare�FRPSRQHQWă�SRDWH�iniþia interacþiuni.

� Simetric ��RULFH�FRPSRQHQWă�SRDWH�SURGXFH�ºi consuma servicii

Succesiune operaþii:

conectare la reþeaua de componente, cãutare componentã

invocare serviciu


Stilul peer-to-peer

Variante :

� Propagare de la un peer la altul în cãutarea unei componente

� Noduri speciale (ultrapeer / ultranode / supernode)��FDSDELOLWăþi de indexare sau rutare

� Limitarea numãrul de componente conectate

� Restricþii de cunoaºtere identitate


Stilul peer-to-peer

Atribute de calitate promovate :

� Flexibilitate � caracter simetric

� Compozabilitate � cooperare componente pentru a oferi un serviciu

� Echilibrare încãrcare

� Scalabilitate dinamicã � conectare componente la runtime

� Disponibilitate cu replicare componente

� Permite analizarea dependabilitãþii, securitãþii ºi capacitãþii de transfer date (throughput).


Stilul peer-to-peer

Exemple � sisteme distribuite

Reþele de partajare fiºiere (exemple ?)

Aplicaþii de mesagerie instant ºi VoIP

Desktop grid computing systems

Gnutella � transfer bidirecþional de fiºiere


PLAN CURS



Stilul peer-to-peer






Stilul SOA

SOA � Service-Oriented Architecture

Colecþie de componente distribuite care oferã ºi/sau consumã

servicii.

Componente executabile : compozabile indiferent de limbajul de dezvoltare ºi platforma de execuþie.

Componente independente funcþional.


Stilul SOA

Tipuri de componente :

� furnizor serviciu ��RIHUă�VHUYLFLX�SULQ�LQWHUIDþã publicatã

� consumator serviciu ��LQYRFă�VHUYLFLL�GLUHFW�VDX�SULQ�LQWHUPHGLDU

� Registru � furnizorii înregistreazã servicii, consumatorii descoperã servicii la runtime

� Server de orchestrare ��FRRUGRQHD]ă�LQWHUDFþiunile pe baza unor scripturi ce definesc fluxuri de lucru (workflow)

� ESB (enterprise service bus) � element de rutare ºi transformare mesaje


Stilul SOA

Tipuri de conectori :� SOAP � protocol SOAP (over HTTP) comunicare sincronã; conecteazã

porturi descrise cu WSDL

� REST � intermediazã operaþiile de bazã ale protocolului HTTP; comunicare sincronã

� Conector de mesagerie � utilizeazã un sistem de mesagerie* pentru schimb asincron de mesaje (point-to-point sau publish-subscribe)

Relaþii : ataºare dinamicã�SRUWXUL�GLVSRQLELOH�OD�FRQHFWRUL�FRUHVSXQ]ăWRUL.

Model computaþional : Cooperare componente; descrisã în general ca workflow.

*Exemple: IBM WebSphere MQ, Microsoft MSMQ, Apache ActiveMQ


Stilul SOA

Variante :� Consumatorii sunt conectaþi la furnizori, posibil prin componente

intermediare.

Atribute de calitate promovate :� Interoperabilitate � independenþã de platforma de execuþie a

componentelor

� Suport pentru integrare sisteme legacy

� Flexibilitate -�UHFRQILJXUDUH�GLQDPLFă


PLAN CURS



Stilul peer-to-peer






Trepte (tiers)

Mecanism de partiþionare a sistemelor prin gruparea logicã a

componentelor în trepte.Criterii:

� Tip componente� Partajare mediu de execuþie� Obiectiv comun

Restricþii topologice referitoare la comunicarea între componente: se pot conecta direct doar componente din aceeaºi treaptã sau din trepte adiacente.

Restricþii referitoare la tipul de comunicare între trepte adiacente (ex. call-return într-un sens ºi notificare prin evenimente în sens opus).

Se poate aplica la orice stil C&C

În mod tipic se aplicã stilului client-server


Stilul în trepte (tiered)ca specializare a stilului client-server

Adreseazã unele inconveniente din zonele de performanþã, fiabilitate, securitate.

Promoveazã scalabilitatea ºi modificabilitatea.

Trepte tipice:� Interfaþa cu utilizatorul� Logica de procesare funcþionalã (business rules)

� Memorare / acces date

Dezvoltate ºi întreþinute separat, ca elemente independente, de multe ori pe platforme diferite.


Interfaþa utilizator se executã pe o staþie desktop ºi utilizeazã un GUI standard

(browser-ul).

Logica de procesare funcþionalã (business rules) poate fi distribuitã pe unul sau mai

multe module separate ce se executã pe unul sau mai multe servere. Treapta intermediarã (middle tier) poate fi formatã, la rândul ei, din mai multe trepte � stilul devine "n-tiered."

Datele sunt amplasate pe un sistem separat care gãzduieºte un repozitoriu (RDBMS).

Client ReguliBusiness

Date

În mod tipic un browser În mod tipic RDBMS

Middle tier

Front end, sau procesele front end.



O problemã cheie a arhitectului � partiþionarea nivelului intermediar (middle tier).

Conceptul de �middleware� a cãpãtat identitate odatã cu apariþia sistemelor �n-tiered�.

Stilul �n-tier� introduce o separare care:

� Permite actualizarea sau înlocuirea independentã a oricãrei trepte

funcþie de necesitãþi � se pãstreazã integritatea conceptualã.

� Permite mecanisme ce promoveazã performanþa, securitatea, fiabilitatea.



PLAN CURS



Stilul peer-to-peer






Structurã generalã în 3 trepte specializare a stilului în trepte pentru domeniul aplicaþiilor WEB

Web Browser

Load Balancer

Router/ Firewall

Proxy Server

Web Server

Web Server

Web Server

:

Application Server

Application Server

:

Database Server

Web Browser

Web Browser

Web Browser

Database Server

Treapta UI Treapta regulilor businessTreapta datelor


AvantajeStil în 3 trepte pentru aplicaþii Web

Browser-e Web performante Iniþial � text ºi hypertext Acum �

� Graficã ºi video

� Securitate� Java applets ºi alte variante de cod executabil la client.

HTTPS

Utilizeazã Secure Sockets Layer (SSL) ca sub-protocol al HTTP.

SSL utilizeazã o pereche de chei publicã/privatã pe 128 biþi. Acest nivel de criptare este considerat ca fiind adecvat pentru cantitãþi micide informaþii comericale ºi pentru tranzacþii scurte.


Server-e proxy Îmbunãtãþesc performanþa:

� Memoreazã în cache pagini web accesate frecvent, a.î. utilizatorii le pot extrage fãrã acces direct la site.

� Pot fi localizate geografic aproape de utilizator ºi plasate în aceeaºi reþea pentru a economisi resurse de comunicare ºi de calcul.

Pot împiedica utilizatorii sã acceseze anumite site-uri web.

Firewalls Împiedicã accesul neautorizat, din exteriorul zonei protejate, la

informaþii.

Tipuri uzitate:� Packet filters ��H[DPLQHD]ă�DQWHWHOH�7&3�ºi IP ale fiecãrui pachet primit

ºi rejecteazã pachetele necorespunzãtoare.

� Application proxies � specifice aplicaþiilor; cunosc protocoalele folosite de aplicaþie ºi filtreazã traficul pe baza unor modele de comportament

cunoscute.

Avantaje Stil în 3 trepte pentru aplicaþii Web



Echilibrarea încãrcãrii

(load balancing)

performanþã, disponibilitate ºi securitate

Cererile HTTP ºi HTTPS sunt distribuite unui fond comun de server-e.

Strategiile de echilibrare se pot baza pe planificare circularã (round-robin) sau pe cunoaºterea caracteristicilor de procesare ºi de încãrcare ale

server-elor.

Suplimentar se poate monitoriza starea fiecãrui server ºi, dacã apare o

disfuncþionalitate, traficul este redirijat cãtre alt server din fondul comun.



Server-e Web

performanþã

ºi scalabilitate

Fire multiple de execuþie, utilizând un fond comun de fire de execuþie din care fiecare fir poate fi repartizat pentru a trata o cerere nou�DSăUXWă.

Un server cu fire multiple de execuþie este mai puþin predispus la gâtuiri ºi la întârzieri mari pentru cazurile cele mai defavorabile.

Scalabilitate prin înlocuirea procesoarelor cu versiuni mai puternice.



Server-e de aplicaþii*

modificabilitate, scalabilitate, performanþã

� Aplicaþiile desfãºurate pe aceste servere implementeazã logica

business iar serverele de aplicaþii implementeazã conectivitatea, care dicteazã modul în care interacþioneazã clienþii ºi server-ele.

� Au permis transferarea unei porþiuni semnificative de funcþionalitate de la clienþii �fat��OD�WUHDSWD�LQWHUPHGLDUă.

� Au permis bazelor de date sã se concentreze pe memorarea, extragerea ºi analiza datelor,�IăUă�D�VH�SUHRFXSD�GH�PRGXO�în care vor fi utilizate datele.

*Server de aplicaþii infrastructura pentru o clasã de aplicaþii ce se executã pe treapta intermediarã.



Baze de date performanþã, scalabilitate, disponibilitate

Utilizeazã în mod frecvent replicarea pentru performanþã, scalabilitate ºi disponibilitate.

Pot utiliza mecanismul de caching pentru performanþã suplimentarã.


PLAN CURS



Stilul peer-to-peer






Tehnologia Java EE

EJB (Enterprise Java Beans)� Defineºte un API care permite dezvoltatorilor sã creeze, sã

repartizeze ºi sã gestioneze la server aplicaþii bazate pe componente.

JSF(Java Server Faces)� Tehnologie pentru construirea de interfeþe utilizator din componente.

JSP (Java Server Pages)� Metodã pentru crearea de pagini Web dinamice.

Java Servlets� Mecanism de extindere a funcþionalitãþii la server, ce permite crearea

de conþinut dinamic.

JMS (Java Messaging Service)� Suport pentru transfer asincron de mesaje utilizând fie point-to-point

fie publish-subscribe ca stil de interacþiune.


Tehnologia Java EE

JNDI (Java Naming and Directory Interface)� Serviciul de directori pentru Java EE, ce permite clientului ºi servlet-

urilor de pe treapta Web sã extragã referinþe la obiectele utilizator definite ca EJB.

JTA(Java Transaction Architecture) ºi JTS (Java Transaction Service)� Permite obiectelor EJB ºi clienþilor lor sã participe în procesãri

orientate pe tranzacþii.

JCA (Java EE Connector Architecture)� Arhitecturã standard pentru conectarea platformei Java EE la

sisteme EIS (Enterprise Information Sistems) eterogene.

� Include aplicaþii împachetate; exemple:� ERP (Enterprise Resource Planning)

� Sisteme CRM (Customer Relationship Management)


Tehnologia Java EE

CAS / COM Bridge (Client Access Services) / (Component Object Model)

� Permite integrarea de aplicaþii COM ºi Java EE din cadrul unei reþele.

RMI over IIOP (Remote Method Invocation, Internet Inter-ORB Protocol)

� Oferã o implementare RMI peste IIOP de la OMG

� Oferã un cadru în care dezvoltatorii pot defini interfeþe remote între clienþi ºi server-e, pe care le pot implementa utilizând API-ul Java RMI.

JDBC (Java Database Connectivity)� Interfaþã uniformã transparentã la o gamã largã de baze de date

relaþionale.

� Bazã comunã din care se pot construi instrumente ºi interfeþe pe nivele superioare.


Arhitecturã Java EE n-Tieredspecializare stil în trepte pentru tehnologia Java EE

�Browser-Based Client Applications (HTML, applets, DHTML/Scripting)

Java Client Applications

Windows/COM Client Applications

Web Server

ServletsJSPs

Application Components

EJBs

Container Services Components

(e.g JTS, JMS)

ERPs

CRMs

Mainframe TP System

RDBMs

Client Tier Web Tier Business Logic Tier

EIS Tier

HTTP

RMI JDBC

RMI over IIOP

CAS COM Bridge


Java EE ��DERUGăUL�DUKLWHFWXUDOH

Treapta client � include

� Browser-e internet ce trimit cereri HTTP ºi FTP.

� Pagini HTML de la un alt server Web.

� Clienþi Java de sine stãtãtori (stand-alone) care�FRPXQLFă�GLUHFW�FX�FRPSRQHQWHOH�de pe treapta business.

� Obiecte Microsoft care comunicã direct cu componentele de pe treapta business.

Treapta Web ��H[HFXWă�XQ�VHUYHU�:HE�FH�JHVWLRQHD]ă�FHUHUL�GH�OD�FOLHQþi

� Rãspunde la cereri invocând servlet-uri sau JSP de pe platforma Java EE.

� Servlet-urile interogheazã treapta componentelor business pentru a obþine informaþiile ce vor fi returnate clientului.

� JSP sunt pagini HTML statice ce conþin fragmente de cod servlet invocate de mecanismul JSP.


Java EE ��DERUGăUL�DUKLWHFWXUDOH

Treapta componentelor business � conþine nucleul logicii business în componente EJB care:

� Recepþioneazã cereri de la servlet-uri,

� Satisfac cererile accesând diverse surse de date,

� Sunt gãzduite într-un container EJB�FDUH�FRQWUROHD]ă�ºi monitorizeazã firele

de execuþie EJB.

Treapta EIS � conþine în mod tipic una sau mai multe baze de date ºi aplicaþii gãzduite pe server-e, pe mainframe-uri ºi/sau pe sisteme legacy.

� EJB interogheazã aceste depozite de date pentru a procesa cererile.

� Pentru accesarea bazelor de date se utilizeazã în mod tipic driver-e JDBC.


Java EE � repartizarea componentelor aplicaþiei


Java EE � artefactele aplicaþiei ºi organizarea lor


Java EE - concluzii

Java EE este una din abordãrile tehnologice pentru construirea sistemelor n-tiered. Alte abordãri;

� CORBA (Common Object Request Broker Architecture) de la OMG Un broker al cererilor pentru obiecte (ORB) permite obiectelor sã-ºi publice interfeþele. Programele client ºi alte obiecte le pot localiza oriunde în reþea pentru a le solicita servicii.

� Arhitectura .NET are prevederi referitoare la construirea sistemelor formate din obiecte distribuite pe platforme bazate Windows.

Utilizarea Java EE nu exclude necesitatea unei arhitecturi !� Compromisurile arhitecturale trebuie analizate cu atenþie pentru a obþine un

design optim al arhitecturii aplicaþiei în raport cu cerinþele de calitate impuse.

În ciuda simplitãþii ºi puterii cadrului de implementare Java EE,�H[LVWă�PXOWH�decizii arhitecturale ce trebuie fãcute cu atenþie.� Majoritatea acestor decizii se vor face cu privire la partiþionare ºi asignare de

responsabilitãþi nivelelor intermediar ºi EIS.



Curs 6



PLAN CURS

Stiluri bazate pe evenimente

� Stiluri cu evenimente implicite

Stiluri cu date partajate

� Stilul repository pasiv

� Stilul blackboard


Sisteme bazate pe evenimente - categorii

Evenimente explicite �evenimentele sunt trimise explicit la anumite elemente.

Evenimente implicite ��HYHQLPHQWHOH�sunt difuzate cãtre elemente. Elementele rãspund la evenimentele de care sunt

interesate.

Categorii ºi semantici

Exemple de implementãri pentru evenimente

Proiectarea sistemelor bazate pe evenimente

Discuþie asupra atributelor de calitate

Comunicareasincronã

fãrã autoblocare


Obiect AObiect A

Obiect CObiect C

Obiect BObiect B

Invocare implicitã

vs.�,QYRFDUH�H[SOLFLWă

Obiect AObiect A op1

op2 op3

Invocare explicitã

Invocare implicitã

ev1

op3

op2

op1

Obiect BObiect B

Obiect CObiect C






Stiluri bazate pe evenimente- semantici

� Elemente

� obiecte, fire de execuþie, procese

� Relaþii între elemente

� Comunicarea între componente (locale sau distribuite) se face prin evenimente.

� Topologie

� Procese concurente slab cuplate

� Modelul computaþional

� Sistem de procese sau obiecte independente care reacþioneazã

la evenimente generate în contextul lor ºi care genereazã la

rândul lor reacþii în alte componente ca efect al anunþãrii de noi

evenimente.






Stiluri bazate pe evenimente- semantici

Semantici

� Evenimente implicite

� Emiþãtorii nu cunosc identitatea receptorilor

� Ordinea de execuþie este non-deterministã

� Evenimente explicite

� Emiþãtorii cunosc identitatea receptorilor

� Ordinea de execuþie poate fi anticipatã.

În ambele variante ale stilului, corectitudinea comportamentului oricãrui element ce emite

un eveniment nu depinde de corectitudinea comportamentului nici unuia dintre elementele care recepþioneazã evenimentul.






Implementãri la nivel de limbaj

Limbajul C

� signals � întreruperi software

� Reprezentate prin întregi pozitivi (signal.h)

� Pot fi generate automat sau pot fi trimise altor procese folosind apelul sistem kill(PID_proces_destinaþie)

� Este necesarã cunoaºterea destinatarului (PID/nume_proces)

� Variante de tratare a semnalului recepþionat:

� ignorare

� utilizare acþiune implicitã

� creare ºi utilizare funcþie special definitã pentru tratare semnal.






Visual Basic � limbaj orientat pe evenimente

� Componentele de interfaþã (Widget-uri) au proprietãþi, metode ºievenimente.

� Widget-urile trimit diferite evenimente în funcþie de interacþiunile utilizatorului, de timer-e, etc.

� Fiecare widget rãspunde la un set fixat de evenimente.

� Dezvoltatorii ataºazã cod la fiecare tip de eveniment al unui widget, cod ce va fi executat la apariþia evenimentului respectiv.

� Limbaj orientat pe evenimente, dar slab OO.

� Accesul la proprietãþile ºi metodele unui widget nu promoveazã un grad

superior de încapsulare.







Java -�RIHUă�GRXă�PHFDQLVPH�GH�OXFUX�FX�HYHQLPHQWHOH.

1. Set predefinit de evenimente utilizabile în dezvoltarea interfeþei cu utilizatorul.

2. Mecanismul Observer / Observable pentru transmitere ºi recepþionare de evenimente.

� Un obiect Observer reacþioneazã prin apelul metodei update() atunci când este notificat de cãtre un obiect Observable.

� Dezvoltatorii trebuie sã scrie codul pentru implementarea metodei update().

� Suportã �late binding�: se pot adãuga ºi elimina obiecte Observer ºiObservable în timpul execuþiei.

� Simultan cu notificarea prin eveniment se pot trimite ºi obiecte ca parametrii.







Deºi implementãrile variazã, evenimentele reprezintã o caracteristicã

puternicã a limbajelor moderne.

� C++ are event ºi defineºte event source ºi event receiver.

� C# ��XWLOL]HD]ă�event ºi delegate (suport pentru invocare anonomã)

� Ada 9X are interrupt ºi interrupt handler.

� SmallTalk-80, Visual SmallTalk implementeazã evenimentele în mod similar cu Observer / Observable de la Java.

Existã ºi alte implementãri sau extensii de limbaje pentru lucrul cu evenimente.







JMS: Java Messaging Services

Mecanisme pentru lucrul cu evenimente pe platforma CORBA

ESB (Enterprise service bus) - middleware pentru SOA (Service-OrientedArchitecture)

Implementãri la nivel de platformã







Sistemele orientate pe evenimente sunt proiectate în mod deliberat de cãtre arhitect.

În proiectarea acestui tip de sisteme arhitectul trebuie sã ia în considerare:

� Declaraþiile evenimentelor

� Structura evenimentelor

� Legãturile evenimentelor

� Anunþarea evenimentelor

� Concurenþa evenimentelor






Declararea evenimentelor

Cum ?

� Set predefinit de evenimente

� Declaraþie staticã de eveniment

� Declaraþie dinamicã de eveniment

Unde ?

� Declaraþii centralizate

� Declaraþii distribuite

Sistemele cu evenimente oferã:

� înregistrare � înregistrare surse de evenimente ºi înregistrare interes pentru evenimente

� manageri de mesaje/evenimente � responsabili cu facilitarea comunicãrii

între elementele din sistem.






Structurarea evenimentelor

Cum ?

� Nume sau valori simple asociate cu un eveniment

� Listã de parametrii

� Predefinitã

� Determinatã de tipul evenimentului

� Determinatã dinamic

Transferul datelor via evenimente

� prin listã de parametrii

� prin valoarea evenimentului

� ambele






Legarea evenimentelor

Cum ?

� Static

� Dinamic






Anunþarea evenimentelor

Cum ?

� O singurã anunþare

� Anunþãri multiple

� Ambele

� Evenimente pierdute

� Evenimentele pierdute vor fi bufferat-e la nivel de element sau centralizat

� Coordonarea difuzãrii (anunþãrii) evenimentelor






Concurenþa evenimentelor

Ce sunt elementele din stil ? Cum trateazã acestea concurenþa ?

� Obiecte

� Procese

� Fire de execuþie

Cum sunt �furnizate� evenimentele ?

� Furnizare totalã (toate datele, la toate elementele)

� Furnizare selectivã (date parþiale, la unele elemente)

� Furnizare la grup

� Receptorii evenimentului sunt identificaþi pe baza grupului de care aparþin.






Analiza sistemelor bazate pe evenimente

Problematicã

� Durata de viaþã a componentelor în raport cu comunicarea/recepþionarea de evenimente.

� Sunt evenimentele anunþate la momente corespunzãtoare?

� Existã evenimente anunþate în momente nepotrivite?

� Legãturile eveniment-metodã sunt suficiente pentru a obþine comportamentul dorit pentru sistem?

� Existã posibilitatea de a nu înregistra componente suficiente sau componentele potrivite la un anume eveniment?

� Interferenþa componentelor

� Existã posibilitatea ca douã componente sã lucreze concurent

pe date partajate?






Modele pentru dispecerizarea evenimentelor

Ordinea de generare

� Utilizarea unei cozi de mesaje ºi dispecerizarea evenimentelor în ordinea în care au ajuns.

Ordine totalã

� Toate obiectele recepþioneazã evenimentele în aceeaºi ordine,�ordine ce reflectã ordonarea temporalã.

Ordine cauzalã

� Nici un eveniment nu este furnizat înainte de furnizarea tuturor evenimentelor ce au condus la generarea lui.

e1

e1

e2

e3

Ordine cauzalã � exemplu:

e3 nu trebuie furnizat înainte de e1.






Atribute de calitate - discuþie

Atribute de calitate ce trebuie considerate la alegerea stilurilor orientate pe evenimente:

� Performanþa

� Reutilizabilitatea

� Testabilitatea

� Mentenabilitatea

� Disponibilitatea

� Modificabilitatea/scalabilitatea

� Integritatea conceptualã






Performanþa

� În general inhibatã, datoritã non-determinismului:

Ordinea execuþiilor operaþiilor din sistem este nedeterminatã

dificil de:

� garantat timpul de rãspuns,

� realizat planificarea activitãþilor

Reutilizabilitatea

� În general promovatã, deoarece elementele pot fi reutilizate simplu, prin înregistrare la evenimente.

� Elementele nu trebuie sã cunoascã identitatea altor elemente din

sistem.







Testabilitatea

Testarea este dificilã deoarece:

� Urmãrirea evenimentelor de la anunþarea la recepþionarea lor poate fi dificilã ºi poate necesita instrumente ºi/sau structuri speciale ale sistemului.

� Ordinea operaþiilor poate depinde de factori multipli ce influenþeazã generarea ºi recepþionarea evenimentelor.

� Datoritã non-determinismului, trecerea unui anumit test nu garanteazã corectitudinea sistemului.







Mentenabilitatea

� În general promovatã, deoarece elementele lucreazã independent

fãrã a afecta alte componente (modificãrile tind sã fie locale).

� Poate fi afectatã de necesitatea unei coordonãri centralizate a:

� evenimentelor,

� înregistrãrilor la evenimente,

� politicilor de dispecerizare a evenimentelor.

Disponibilitate

� Posibilitatea pierderii de evenimente reduce disponibilitatea sistemului.







Modificabilitatea / scalabilitatea

� În general promovatã, deoarece pot fi adãugate uºor la sistem elemente noi.

� Totuºi adãugarea de elemente noi va creºte overhead-ul ºi va afecta în final performanþa.

Integritatea conceptualã

� Separarea problemelor ºi integritatea conceptualã sunt, în general, promovate deoarece obiectele au un grad ridicat de independenþã.

� Evenimentele ºi politica de interacþiune pot fi separate clar de elementele ce interacþioneazã.

� Este dificil de modelat ºi analizat comportamentul la momentul execuþiei, datoritã non-determinismului.







PLAN CURS







Evenimente implicite (sisteme Publish � Subscribe)

Componente:

Orice componentã C&C cu cel puþin un port publish sau subscribe*.

Conectori:

Conector publish-subscribe � cu rolurile announce ºi listen

Relaþii:

Attachment � port publish la rol announce; port subscribe la rol listen

Modelul computaþional:

Componentele se aboneazã la evenimente. La anunþarea unui eveniment de cãtre o

componentã, conectorul dispecerizeazã evenimentul la toþi abonaþii acestuia.

Un eveniment poate avea înregistraþi 0...n receptori.

*Obs. Orice componentã poate avea unul sau mai multe porturi din fiecare tip.






Invocare implicitã ��YDULDQWă�D�HYHQLPHQWHORU�LPSOLFLWH

Componente cu interfeþe procedurale înregistreazã una din

proceduri la un eveniment.

La apariþia evenimentului în sistem, procedura înregistratã cu

acesta este invocatã automat (�implicit�).

Dacã existã mai multe componente ce au înregistrat proceduri cu un anumit eveniment, ordinea invocãrilor implicite nu este

specificatã.





Evenimente implicite (sisteme Publish � Subscribe)


GUI � gesturile utilizator preluate de dispozitive fizice sunt tratate ca evenimente ºi sunt trimise la rutine corespunzãtoare de tratare a acestora.

Aplicaþii în stil MVC � componentele View sunt notificate la modificarea stãrii

componentei Model.

Medii de programare extensibile � instrumentele sunt coordonate prin evenimente

Mailing lists � abonare la subiecte de interes

Reþele sociale � notificare �friends� la modificarea unui site personal

Exemple de sisteme ce utilizeazã

stilul Publish - Subscribe


PLAN CURS








Structurã de date centralã��reprezentând starea curentã a sistemului), �asupra cãreia opereazã un set de componente independente.

Componente:

Depozitar (repository) pentru memorarea (persistenþa) datelor centralizate.

Accesor date (proces, fir de execuþie, obiect), care�DFFHVHD]ă�GDWHOH�centralizate.

Conectori:

Connector accesare / modificare date

Relaþii :

Attach �-�LQWHUPHGLD]ă�FRQHFWDUHD�DFFHVRU�GDWH�OD�GHSR]LWDU.



Topologie

Accesori date slab cuplaþi aflaþi în jurul sistemului de date partajate (unul sau mai multe depozitare).

Semantici

Accesorii scriu/citesc date.

Datele din depozitar sunt dinamice.

Structura datelor din depozitar este, în general,�VWDWLFă.

Tipuri de structuri: relaþionalã, OO, layered, ierarhicã.

Localizarea controlului corespunde unor ºabloane specifice (v. Sld. 33, Sld. 43)



Atribute de calitate promovate

Scalabilitatea, datoritã decuplãrii ºi încapsulãrii accesorilor care simplificã

adãugarea de noi surse de cunoºtinþe.

Interoperabilitatea � referitoare la datele accesate în comun.


Simplitatea ��WUHEXLH�JDUDQWDWă�H[FOuderea mutualã.

Performanþa ��FăXWDUHD�GDWHORU�HVWH�FRQVXPDWRDUH�GH�WLPS�ºi non-deterministicã.

Modificabilitatea ��GLILFLOă�GDFă�VXQW�QHFHVDUH�VFKLPEăUL�în structura datelor partajate.

Securitatea ��QHFHVLWDWHD�DVLJXUăULL�ºi verificãrii identitãþii accesorilor.



Categorii de stiluri cu date partajate

Repository pasiv

� Controlul este distribuit

între accesori.

� Exemple: memorie partajatã, baze de date.

Blackboard

� Controlul este bazat pe starea

informaþiilor din depozitar.

� Exemple: baze de date �cu interogare continuã�,

triggere pe date.


PLAN CURS







Stilul repository pasiv - variante

Memorie partajatã

Depozitarul central de date este în mod tipic în memoria volatilã (În puncte strategice ale execuþiei, starea se poate pãstra ºi pe medii de duratã mai mare).

Accesorii sunt strâns cuplaþi cu depozitarul.

Accesorii sunt fire de execuþie concurente, procesoare sau obiecte ce acceseazã depozitarul.

Accesorii opereazã independent unul de altul.

Controlul general este distribuit între accesori.


Stilul repository pasiv - variante

Baze de date clasice

Depozitarul central pãstreazã starea datelor pe termen lung (persistenþa).

Accesorii sunt aplicaþii software, deseori aflate la distanþã faþã de

depozitarul central de date.

Accesorii opereazã independent asupra datelor din depozitar, în ce priveºte interogãrile ºi actualizãrile.

Controlul general este distribuit între accesori.

Existã suport pentru lucrul cu tranzacþii.


Stilul repository pasiv - exemple

Baze de date clasice

Depozitar format din:

Baza de date

Sistemul de gestiune a datelor (DBMS)

� Oferã o interfaþã pentru extragere / manipulare date

� Oferã servicii pentru management date:

� tranzacþii

� securitate

� controlul concurenþei

� integritatea datelor


PLAN CURS







Stilul blackboard

Stil flexibil pentru rezolvarea colaborativã a unei probleme.

Rezultat al cercetãrilor în domeniul inteligenþei artificiale.

Aplicabilitate în domeniul industrial la:

Procesare de semnale

Radare

Prelucrare de imagini

Procesarea vorbirii


Stilul blackboard

Elemente

� depozitar (blackboard),

� surse de cunoºtinþe,

� control.

Relaþii între elemente

� Evenimente pentru notificarea surselor de cunoºtinþe.

� Flux de date transferat de sursele de cunoºtinþe cu depozitarul.

Semantici ºi atribute de calitate

Detalii

Problematica proiectãrii


Stilul blackboard

Topologie

� variabilã; sursele de cunoºtinþe legate direct ºi independent la depozitar.

Semantici

� Sursele de cunoºtinþe:

� Procese independente capabile sã rezolve probleme specifice.

� Lucreazã independent în zona lor de experizã pentru a rezolva împreunã o problemã

complexã.

� Nu interacþioneazã între ele în mod direct; nu cunosc ce alte surse de cunoºtinþe sunt active simultan.

� Depozitarul

� Partiþionat în regiuni, a.î. sursele de cunoºtinþe transferã date cu un anumit �nivel� de structurare ºi abstractizare.

� Elementul de control - este responsabil cu planificarea urmãtoarei surse de cunoºtinþe ce trebuie activatã.


Detalii



Stilul blackboard


� Legate în special de soluþionarea problemelor de inteligenþã artificialã : modificabilitate, scalabilitate, mentenabilitate, interoperabilitate, separabilitate calcule.


� Simplitatea � dezvoltarea surselor de cunoºtinþe este complicatã ºi poate necesita expertizã

de domeniu superioarã.

� Performanþa� Fiind în mare mãsurã non-deterministice, este dificil de estimat durata obþinerii

rãspunsului.

� Problema de ansamblu este rezolvatã în manierã incrementalã, secvenþialã.

� Testabilitatea� Dificil de testat ºi de analizat corectitudinea aplicaþiei.


Detalii



Stilul blackboard - detalii

Cunoºtinþele din domeniul aplicaþiei sunt partiþionate ºi codificate într-o colecþie de componente numite surse de cunoºtinþe.

Elementele stilului:

Blackboard - depozitar organizat ierarhic în care se salveazã soluþiile generate de sursele de

cunoºtinþe.

Datele din depozitar:

� reprezintã starea completã (intermediarã /�ILQDOă) a soluþiei problemei,

� sunt deseori eterogene,

� sunt organizate ierarhic.

Surse de cunoºtinþe� Rãspund la modificãrile din starea blackboard-lui.

� Genereazã soluþii independente ºi scriu în blackboard soluþii complete sau parþiale.

Modulul de control (scheduler/control shell)

� Selecteazã (funcþie de logica aplicaþiei) o sursã de cunoºtinþe ºi o planificã pentru

execuþie.

� Determinã momentul în care problema este rezolvatã.


Detalii




Topologie: (2 variante)

� Nu existã element explicit de control.

� Sursele de cunoºtinþe (KSs) sunt activate de starea blackboard-lui.

� Existã un element explicit de control.

� Sursele de cunoºtinþe sunt planificate/activate decãtre elementul de control, în urma monitorizãrii de

cãtre acesta a stãrii blackboard-lui.

Blackboard

KS1

KSn

::

Control

Citire/Monitorizare

stare

Planificare ºi

invocare surse de

cunoºtinþe

Blackboard

KS1

KSn

::

Proces Depozitar date Accesare date (read/write) Invocare


Detalii




Elementul BLACKBOARD

Structurã de date partajatã disponibilã surselor de cunoºtinþe.

� Depozitarul sistemelor blackboard serveºte ca memorie primarã (brutã) ce conþine date de intrare pentru sursele de cunoºtinþe, soluþii parþiale, alternative, soluþii finale.

� Elementul blackboard oferã mecanisme de comunicare ce permit realizarea de operaþii de citire ºi scriere de cãtre sursele de cunoºtinþe ºi de cãtre elementele de

control.

� Mecanismele pentru planificare, control ºi activare a surselor de cunoºtinþe pot fi implementate direct în blackboard sau în elemente externe acestuia.

� Modificãrile din conþinutul blackboard-lui genereazã notificãri cãtre surse de

cunoºtinþe, care vor reacþiona corespunzãtor la prezenþa sau la modificarea anumitor informaþii.


Detalii




Elementul BLACKBOARD

Aplicaþiile tind sã aibã structuri elaborate ale blackboard-lui, cu nivele ierarhice de abstractizare.

� Datele din blackboard sunt organizate în regiuni care corespund diferitelor categorii de informaþii.

� Sursele de cunoºtinþe citesc ºi scriu informaþii din/în regiuni specifice.

� Aceste abstractizãri sunt utile proiectanþilor ºi faciliteazã cãutãri rapide ºi sistematice realizate de cãtre sursele de cunoºtinþe.

Date conþinute pot fi

� statice,

� dinamice � generate în timpul execuþiilor.


Detalii




Elementele SURSE DE CUNOªTINÞE

Fiecare sursã de cunoºtinþe este specializatã în rezolvarea anumitor aspecte ale problemei de ansamblu.

� Funcþionare independentã de alte surse de cunoºtinþe; sursele de cunoºtinþe nu se cunosc între ele.

� Fiecare sursã de cunoºtinþe contribuie la soluþionarea problemei.

� Sursele de cunoºtinþe sunt capabile sã transfere date cu elementul blackboard.

� Sursele de cunoºtinþe sunt capabile sã utilizeze anumite informaþii din blackboard pentru a construi sau a rafina cunoºtinþe.

� În unele aplicaþii sursele de cunoºtinþe culeg date din exterior ºi le utilizeazã pentru

a adãuga cunoºtinþe în blackboard.


Detalii



AcþiuneCondiþieinvocã, declanºeazã,

executã...

Sursã de cunoºtinþe (KS)


Elementele SURSE DE CUNOªTINÞE

Implementãrile sunt partiþionate pe bazã de condiþii ºi acþiuni.

� Specificã o condiþie în care sursa de cunoºtinþe contribuie la rezolvarea problemei.

� La îndeplinirea condiþiei se invocã

acþiunea corespunzãtoare.

� Modificare sau plasare de cunoºtinþe noi în blackboard.

� Acþiunile pot include noi condiþii.


Detalii




Elementul de CONTROL

Responsabilitãþile generale ale elementului de control:

� Dirijarea întregului proces de rezolvare a problemei prin coordonarea surselor de cunoºtinþe în a rãspunde la modificãrile din conþinutul blackboard.

� Pe baza rezultatelor�DFWLYăULL�XQHL�VXUVH�GH�FXQRºtinþe, elementul de control poate

� determina sursa de cunoºtinþe cea mai potrivitã a fi activatã la pasul urmãtor,

� planifica execuþia surselor de cunoºtinþe,

� estima fidelitatea soluþiei,

� finaliza rezolvarea problemei.

Controlul poate sã difere în mod substanþial la diferite implementãri ale

stilului.


Detalii



Stilul blackboard

Situaþii în care se sugereazã utilizarea stilului blackboard:

Existã mai multe moduri de a rezolva problema.

Existã mai multe rãspunsuri corecte.

Rãspunsul cel mai bun poate varia ºi depinde de mai mulþi factori.

Sunt necesare expertize diverse pentru soluþionarea problemei.

Existã incertitudini, erori ºi variaþii la nivelul surselor de date disponibile (ex. Raport scãzut între semnal ºi zgomot).


Detalii



Stilul blackboard � problematica proiectãrii

Reprezentare date - Comunicarea între elemente se face prin intermediul informaþiilor din blackboard.

Sensibilizare - Elementele trebuie sã devinã conºtiente de evenimentele relevante.

Investigare - Crearea de elemente care pot gãsi informaþii relevante în mod eficient.

Interacþiune - Crearea de elemente capabile sã utilizeze datele intermediare produse de alte elemente.

Integrare - Combinarea sub forma unui rãspuns coeziv a rezultatelor produse de diferite elemente.

Coordonare - Determinarea elementelor sã-ºi concentreze activitãþile pe lucrurile potrivite la momentul potrivit.


Detalii




Proiectarea surselor de cunoºtinþe

� Codificarea ºi reprezentarea cunoºtinþelor

� Formatul de reprezentare a datelor specifice

� Formate de date recunoscute

� Mecanisme de preluare a datelor din blackboard

� Posibile surse externe de date


Detalii




Proiectarea surselor de cunoºtinþe (cont.)

� Împachetarea codului sub formã de fir de execuþie, proces sau obiect

� Nivelul de detaliu al contribuþiei la blackboard (doar rezultatul, expunerea

rezultatelor intermediare, etc.); are impact asupra performanþei.

� Modul de gãsire a soluþiilor: în paralel, întreþesut, secvenþial.

� Concurenþa îmbunãtãþeºte performanþa dar creºte foarte mult complexitatea sistemului.

� Unele probleme nu pot fi rezolvate cu o abordare concurentã.

� Modul de înºtiinþare despre modificãrile din blackboard

� Interogare

� Evenimente

� Apel de metodã


Detalii




Proiectarea elementului blackboard

� Reprezentarea informaþiilor :

� compromis între expresivitatea reprezentãrilor înþelese de puþine surse de cunoºtinþe ºi reprezentãri mai generale înþelese de toate sursele de cunoºtinþe.

� abstractizãri de reprezentare mai expresive au impact negativ asupra performanþei.

� Organizarea ºi structurarea datelor

� Rolul jucat în controlul sistemului : controlul poate fi inclus în elementul blackboard sau poate fi realizat de alt element din sistem.

� Gestionarea relaþiilor : detectarea ºi eliminarea informaþiilor duplicat.

� Gestionarea grupãrii atributelor : detectarea de atribute similare în obiecte diferite ºi gruparea lor într-un singur obiect.

� Gestionarea propagãrii valorilor : detectarea de modificãri ale valorilor din

informaþiile înrudite ºi reacþionarea în mod corespunzãtor.


Detalii




Proiectarea controlului

� Implementarea controlului într-un element separat sau în blackboard �compromis referitor la separarea problemelor ºi modificabilitate.

� Abordarea arbitrãrii surselor de cunoºtinþe: Planificare vs. Selectarea urmãtoarei surse de cunoºtinþe.

� Maximizarea progresului soluþionãrii problemei ºi minimizarea efortului de calcul.

� Determinarea momentului obþinerii soluþiei � necesitã suficiente informaþii despre blackboard fãrã însã a avea expertiza colectivã a surselor de cunoºtinþe.

� Codificarea rãspunsului (dificilã)

� Uºor de construit sisteme blackboard cu criterii de terminare suboptime.

� Soluþia idealã e mai uºor de codificat decât soluþiile practice suficiente.

� Multe obiective ºi soluþii sunt bazate pe euristici.


Detalii




Proiectarea controlului (cont.)

Modelul de rezolvare a problemei utilizat:

� Raþionament backward ��GH�OD�VWDUHD�ILQDOă�FăWUH�VWDUHD�LQLþialã.

� Raþionament forward � de la starea iniþialã cãtre atingerea obiectivului.

� Raþionament oportunistic

� Începe cu un set de fapte cunoscute.

� Continuã în funcþie de direcþia care pare cea mai productivã.


Detalii



Stilul blackboard � exemplu

Control

Surse de cunoºtinþe

Condiþie

Acþiune

Blackboard Monitor

Coadã

Condiþie

Acþiune

Condiþie

Acþiune

Control Planificator

Blackboard

Strat n

:

Strat 3

Strat 2

Strat 1

date

control


Detalii




Curs 7



PLAN CURS

Perspectiva staticã � module views

� Stilul decomposition

� Stilul uses

� Stilul generalization

� Stilul layered

� Stilul aspects

� Stilul data model

Perspectiva alocãrii � allocation views

� Stilul deployment

� Stilul install

� Stilul work assignment



Perspectiva staticã � modul în care sistemul este structurat ca set

de unitãþi de implementare (cod).

Vederile reprezintã modulele sistemului. Tipul de vedere este

Module Viewtype.

Tipuri elemente :

� modul ��XQLWDWH�GH�LPSOHPHQWDUH�D�XQXL�VHW�FRHUHQW�GH�responsabilitãþi

Tipuri relaþii:

� is part of � descompunere în submodule/subsisteme

� depends on � uses, allowed to use, crosscuts, data relationship

� is a � generalizare, realizare interfaþã



Module views ilustreazã:

structura sistemului � descompus în unitãþi de cod

�LSRWH]H�DVXSUD�VHUYLFLLORU�RIHULWH�GH�PRGXOH

agregarea unitãþilor în ansamble

structurile globale de date (afectate de sau cu impact asupra mai multor module)



Utilitate

Schiþã (plan, model) pentru construirea codului

Definirea alocãrii sarcinilor, timpului, bugetului de dezvoltare

Planificarea dezvoltãrii incrementale

Analiza trasabilitãþii cerinþelor (îndeplinirea cerinþelor prin colaborarea modulelor)

Analiza impactului modificãrilor (pe baza relaþiilor dintre module)

Explicarea funcþionalitãþii sistemului

Explicarea structurii codului

Ilustrarea structurii informaþiilor persistente



Modul ��SURSULHWăþi tipice

Nume

Set coerent de responsabilitãþi� Acþiunile realizate

� Cunoºtinþele gestionate

� Deciziile

� Rolul în cadrul ansamblului sistemului, relativ la funcþionalitate ºi atribute de calitate.

Interfeþele ºi vizibilitatea acestora

Informaþii de implementare� Corespondenþa cu unitãþile de cod sursã (fiºiere cod, date, test, configurare)

� Informaþii testare (plan, cazuri de testare, structuri, date)

� Informaþii management (anticipare buget, grafic)

� Constrângeri de implementare

Proprietãþi specifice stilului


PLAN CURS



� Stilul uses


� Stilul layered

� Stilul aspects




� Stilul install



Stilul decomposition

Definirea structurii sistemului în termeni de module ºi submodule ale acestora.

Primul pas în dezvoltarea modelului arhitectural. Defineºte modulele ce apar în restul vederilor statice ºi organizarea lor.

Tipuri de elemente : modul, subsistem

Tipuri de relaþii : is part of

Constrângeri :

nu sunt permise bucle în graful descompunerii

un modul poate fi conþinut într-un singur modul

Figure from : Clements, Bachmann, Bass, Garlan, Ivers, Little, Nord, Stafford, Documenting Software Architectures: Views and Beyond, Addison Wesley Longman, 2010



Subsistem (grup de module) ��SDUWH�D�XQXL�VLVWHP�FDUH:

Implementeazã un subset coeziv al funcþionalitãþii sistemului

Poate fi executat ºi testat independent (corespunde unui grup de componente)

Util în dezvoltare ºi repartizare incrementalã.

Obs.

Subsisteme diferite pot avea pãrþi comune

Nu orice parte a unui sistem este subsistem (ex. bibliotecã cu funcþii utilitare)



Criterii de descompunere:

Îndeplinire atribute de calitate

Ex. Modificabilitate aplicarea principiului de ascundere a informaþiilor încapsulare aspecte modificabile în module separate �ORFDOL]DUHD�PRGLILFăULORU.

Decizii de reutilizare

Reutilizare �UHVSRQVDELOLWăþi predefinite �DORFDUHD�UHVWXOXL�GH�UHVSRQVDELOLWăþi.

Implementare linii de produse software � diferenþiere module comune de module variabile.

Repartizare sarcini ��GH]YROWDUH�SDUDOHOă; competenþe echipã.



Notaþii:

Informale

casete cu nume, incluse

liste identate

UML

pachete ºi clase

subsisteme

adnotãri ��UHVSRQVDELOLWăþile

stereotipuri - informaþii suplimentare de tip

Figures from : Clements, Bachmann, Bass, Garlan, Ivers, Little, Nord, Stafford, Documenting Software Architectures: Views and Beyond, Addison Wesley Longman, 2010


PLAN CURS



� Stilul uses


� Stilul layered

� Stilul aspects




� Stilul install



Stilul uses

Defineºte relaþii de dependenþã între module.

Tipuri de elemente : modul, subsistem

Tipuri de relaþii : uses (specializare a relaþiei depends on)

A uses B = A depinde de existenþa ºi corectitudinea lui B.

Ex. A utilizeazã un dispozitiv partajat lãsat într-o stare utilizabilã de cãtre B

A utilizeazã un rezultat lãsat de B într-o variabilã partajatã

A sleeps�SkQă�FH�%�WULPLWH�XQ�VHPQDO�awaken.

Contra Ex: A calls B (exception handler) - - B nu influenþeazã corectitudinea lui A.


Stilul usesNotaþii: Informale UML DSMboxes and lines pachete, clase, subsisteme Dependency Structure Matrixtabelar asociere stereotipatã



Stilul uses

Utilitate importantã:

Suport pentru dezvoltare ºi repartizare incrementalã:

Definire increment pe bazã de subset coeziv construit ca închiderea tranzitivã a unui

modul în raport cu relaþia uses.



Corespondenþã vederi

Specificaþii sistem: Acceptã flux de caractere pe intrare. Produce flux de caractere pe ieºire conform

unei configuraþii date.

stdiofiecare conductã

(pipe)

merge, config, stdio

Merge

to_upper, config, stdio

To_upper

to_lower, config, stdio

To_lower

split, config, stdio

Split

mainsistemul

Module view

C&C view

Maparea elementelor vederilor



PLAN CURS



� Stilul uses


� Stilul layered

� Stilul aspects




� Stilul install



Stilul generalization

Defineºte relaþii de generalizare/specializare între module.

Generalizare ��FDSWXUDUH�WUăVăWXUL�FRPXQH

Specializare � capturare variaþii

Extindere ��DGăXJDUH/eliminare/modificare specializãri

Evoluþia trãsãturilor comune ��PRGLILFDUH�JHQHUDOL]ăUL

Tipuri de elemente : modul

Tipuri de relaþii : is a

Constrângeri : nu sunt permise cicluriNu se recomandã moºtenirea multiplã!



Notaþii:

UML

interfeþe ºi clase

generalizare clasã / interfaþã

realizare interfaþã




Utilizare � în modele OO

Proiectarea incrementalã a unui modul prin extensii succesive

Modelare variaþii prin modificãri locale

Reutilizarea abstractizãrilor


PLAN CURS



� Stilul uses


� Stilul layered

� Stilul aspects




� Stilul install



Stilul layered

Defineºte seturi coezive de servicii (grupuri de module) ºi permisiuni de utilizare între acestea.

Portabilitate � la nivel de strat (layer)

Modificabilitate � izolare implementare strat

Tipuri de elemente : strat - layer (grup de module ce oferã un set coeziv de servicii)

Tipuri de relaþii : allowed to use

A is allowed to use �%�= Implementarea oricãrui modul din stratul A poate utiliza

oricare din facilitãþile publice oferite de stratul B.



Stilul layered

Constrângeri :

un modul aparþine unui singur strat (layer)

existã cel puþin 2 straturi

relaþia nu e circularã

un element software de pe un strat poate utiliza elemente {din orice strat inferior, doar elemente de pe stratul imediat inferior}.

un element de pe un strat {poate, nu poate} utiliza un element de pe acelaºi strat.


Stilul layered

Criterii grupare:

Se anticipeazã evoluþie independentã

Nivele de competenþe necesare în dezvoltare

Ex. Presentation layer asignat unei echipe competente în utilizarea tehnologiilor GUI

Nivele de reutilizare

Nivele de abstractizare

Necesitãþi de portabilitate

Layere-le inferioare sunt independente de cele superioare.

Fiecare layer prezintã o interfaþã care ascunde dependenþele de layere-le inferioare.


Stilul layered

Notaþii:

Informale

Stivã cu/farã sãgeþi

Straturi segmentate

Inele concentrice

Straturi transversale

Straturi tridimensionale

UML

pachete stereotipate

dependenþã stereotipatã

Reprezentare:

�Straturi

�Conþinut straturi

�Relaþii : între straturi, între segmente



Stilul layered

Mecanismul call-back:

Invocare dintr-un modul de pe nivel inferior a unui handler de eroare/eveniment de pe nivel superior.

Ex. Manevrã utilizator (click mouse) : întrerupere hardware → handler la nivelul SO (driver mouse) →

handler la nivelului aplicaþiei (modul cod corespunzãtor).

Nu violeazã constrângerile stilului deoarece funcþionarea corectã a

hardware-lui nu depinde de existenþa ºi funcþionarea corectã a SO, iar funcþionarea corectã a SO nu depinde de existenþa ºi funcþionarea corectã

a aplicaþiei.

Hardware

SO

Aplicaþie

allowed to use

callback

Key

layer


Stilul layered

Utilizare DSM pentru depistare dependenþe care violeazã semanticile

stilului.

(a) Allow to use doar pentru nivelul imediat inferior.

(b) Allow to use pentru orice nivel inferior.



Comparaþie: layers vs. tiers

Structuri multistrat (layers) vs. structuri în trepte (tiers).

Elementele unei structuri multistrat sunt orientate pe cod ºi sunt reprezentate cu vederi de tip modular (ex. biblioteci).

Straturile dispar deseori la execuþie.

Elementele de tip trepte sunt procese/fire de execuþie care sunt vizibile la momentul execuþiei; sunt reprezentate în vederi de tip C&C.

EXEMPLU

Aplicaþie

Servicii comune

Abstractizãri SO

Fie urmãtoarele trei straturi�

dupã compilare�

rezultã � structurã vizibilã laexecuþie�

Data Tier

Broker

UI

PERSPECTIVA STATICÃ PERSPECTIVA DINAMICÃ


Comparaþie: layers vs. decomposition

Avionics system

Hardware-hiding module Software-decission hiding module

Behavior-hiding module



PLAN CURS



� Stilul uses


� Stilul layered

� Stilul aspects




� Stilul install



Stilul aspects

Defineºte module ce implementeazã interese transversale ºi relaþii ale acestora cu restul modulelor.

Interese transversale � ex. : controlul accesului, managementul tranzacþiilor, jurnalizare

Modificabilitate ��VLPSOLILFDUHD�PRGXOHORU�FH�LPSOHPHQWHD]ă�IXQFþionalitate business: extragerea codului ce implementeazã interes transversal ºi plasarea acestuia într-un modul separat (aspect).

Tipuri de elemente : aspect (tip modul specific AOP), modul clasic

Tipuri de relaþii : crosscutts � leagã modul aspect de alt modul

Constrângeri :

un modul aspect nu se poate lega cu el însuºi.


Notaþii: UML

Aspect��clasã stereotipatã

Pointcut specification (lista modulelor afectate) : comentariu descriptiv sau relaþie stereotipatã

Stilul aspects



PLAN CURS



� Stilul uses


� Stilul layered

� Stilul aspects




� Stilul install



Stilul data model

Descrie structura staticã a informaþiilor în termeni de entitãþi ºi relaþii între acestea.

Nivele de abstractizare:

conceptual

logic

fizic

Tipuri de elemente : data entity � obiect cu informaþii ce trebuie reprezentate în sistem

Tipuri de relaþii : asociere, generalizare/specializare

Constrângeri :

De evitat dependenþele funcþionale.


Stilul data model

Notaþii:

ERD (Entity-Relationship Diagram)

�crow�s foot� ERD

UML

Diagramã clase



Stilul data model

Model conceptual

- domeniul problemei

Model logic

- conformarea cu o tehnologie de management (ex. relaþional, OO)

Model fizic

-detalii de implementare

-optimizãri

Evoluþie model date



PLAN CURS



� Stilul uses


� Stilul layered

� Stilul aspects




� Stilul install




Perspectiva alocãrii � modul în care sistemul se relaþioneazã cu

structurile (software ºi non-software) din contextul�VăX.

Vederile reprezintã modul de alocare a structurilor arhitecturii software pe structurile (software ºi non-software) din contectul sistemului. Tipul de vedere este Allocation Viewtype.

Tipuri elemente :

� element software ��FDUDFWHUL]DW�GH�SURSULHWăþi solicitate contextului

� element de context ��DUH�SURSULHWăþi oferite sistemului

Tipuri relaþii:

� allocated to � un element software este alocat unui element de context.



Stilurile fundamentale ale perspectivei alocãrii.



PLAN CURS



� Stilul uses


� Stilul layered

� Stilul aspects




� Stilul install



Stilul deployment

Defineºte amplasarea componentelor ºi conectorilor arhitecturii software pe infrastructura hardware/software.


software : componentã, conector

de context : procesor, memorie, disk reþea (router, canal comunicare, firewall, bridge)

Tipuri de relaþii : allocated to, migrates to, copy migrates to, execution mogrates to (alocare dinamicã)


Stilul deployment

Utilitate:

Analiza ºi îmbunãtãþirea unor atribute de calitate

Performanþa Echilibrare încãrcare

Diminuare trafic (volumul ºi frecvenþa comunicãrilor între elemente de infrastructurã)

Creºterea performanþei infrastructurii (adãugare/înlocuire elemente de infrastructurã)

Disponibilitatea ºi fiabilitatea Duplicate ale componentelor software Migrarea componentelor software

Securitatea Limitarea serviciilor accesibile pe fiecare gazdã Limitare acces la zone sensibile (folosind firewall, router, bridge) Masuri de securitate la nivel fizic

Planificarea testãrii ºi integrãrii sistemului

Evaluare costuri


Stilul deployment

Notaþii:

UML

Deployment diagram

Formale

AADL (Architecture Analysis and Design Language)

SysML (System Modelling Language)



PLAN CURS



� Stilul uses


� Stilul layered

� Stilul aspects




� Stilul install



Stilul install

Defineºte organizarea componentelor arhitecturii software ca structurã

de fiºiere.


software : componentã

de context : element configuraþie (fiºier, folder)


allocated to -�FRPSRQHQWă�DORFDWă�OD�HOHPHQW�FRILJXUDþie

containment � element configuraþie conþinut în element cofiguraþie


Stilul install

Utilitate:

Creare de proceduri pentru build-and-deploy

Navigare/cãutare în structura de fiºiere a sistemului instalat

Selectare ºi configurare fiºiere pentru construirea unui pachet specific de instalare (ex. o anumitã versiune)

Actualizarea ºi configurarea fiºierelor unei versiuni cu instalãri multiple

Identificare fiºier lipsã sau defect

Proiectarea ºi implementarea unei caracteristici de �actualizare��DXWRPDWă


Stilul install

Notaþii: UML informale <<artifact>> - element configuraþie<<manifest>> - relaþia containment


*.jar � Java archive

*.war � Web archive

*.ear � Enterprise archive


PLAN CURS



� Stilul uses


� Stilul layered

� Stilul aspects




� Stilul install



Stilul work assignment

Defineºte repartizarea componentelor arhitecturii software la echipele de dezvoltare.


software : modul

de context : unitate organizaþionalã (persoanã, echipã, departament, subcontractor)


allocated to



Utilitate:

Repartizarea activitãþilor de dezvoltare

Definirea instrumentelor ºi contextelor de dezvoltare

Managementul resursei umane

Bazã pentru divizarea sarcinilor (WBS)

Bazã pentru estimarea bugetului ºi a graficului de realizare a produsului software



Notaþii: informale


Provenite din vederea descompunerii (stilul decomposition)


Alte stiluri ale alocãrii

Stilul implementation � repartizarea artefactelor de dezvoltare (clase, programe, script-uri,

cazuri de testare, fiºiere make, documentaþie, ...) pe structura de fiºiere a contextului de dezvoltare

Stilul data stores ��UHSDUWL]DUHD�HQWLWăþilor de date (ex. tabele) pe servere hardware

Specializãri ale stilului deployment pentru tehnologie

� Microsoft (Tiered Distribution)

� IBM�s WebSphere �topologies�

Specializãri ale stilului work assignment

� Stilul platform � repartizare artefacte de dezvoltare la locaþii de dezvoltare cu platforme specializate

� Stilul competence-center � repartizare artefacte de dezvoltare pe centre de competenþã

� Stilul open-source � repartizare artefacte de dezvoltare pe dezvoltatori independenþi, în conformitate cu o strategie de integrare tehnicã.



Curs 8



Procesul de proiectare arhitecturalã

Stakeholder-i

arhitect

Decizii de

proiectare

Constrângeri

de proiectare

Cerinþe ºi nevoi

nestructurate

Cic

lul d

e in

fluenþe

Ghid pentru arhitect

Constrângeri business ºi tehnice

Atribute de calitateFuncþionalitate globalã


Proiectarea arhitecturalã

Proiectul arhitecturii (design-ul arhitectural)

Este primul artefact al proiectãrii

La trecerea de la CE este necesar la CUM se realizeazã.

Activitãþile arhitectului software:

Partiþioneazã sistemul în elemente

Defineºte responsabilitãþile elementelor

Defineºte relaþiile�GLQWUH�HOHPHQWH

Creazã documentaþia

Proiectarea arhitecturalã este influenþatã de:

Organizaþie

Caracteristicile produsului

Procesul de dezvoltare de software

Repetã (de câte ori e necesar)


Influenþa caracteristicilor produsului

Exemplu: caracteristica : Complexitatea sistemului

Arhitectura sistemelor complexe este ierarhicã:

Spaþiul de proiectare al unui arhitect este element pentru alt arhitect

Poate necesita utilizarea arhitecturii întregului sistem/întreprindere

Necesitã echipe de arhitecþi

Plasarea în context:

Arhitectura întreprinderii

Arhitectura sistemului

Arhitectura software-lui

Proiectul de detaliu pentru software

CONSTRÂNGE


Influenþa factorilor organizaþionali

Constrângeri impuse de :

� Încadrarea într-un grafic al livrabilelor

� Dezvoltare distribuitã

� Dimensiunea organizaþiei

� Structura organizaþiei

Arhitectul trebuie sã înþeleagã factorii organizaþionali ºi impactul lor asupra arhitecturii sistemului software.


Influenþa ciclului procesului de dezvoltare de software

Proiectarea arhitecturalã poate fi utilizatã în orice model de proces de dezvoltare de software:� iterativ� waterfall, etc.

Proiectarea arhitecturalã poate începe imediat ce au fost identificate câteva cerinþe:

� Nu este necesarã identificarea tuturor cerinþelor înainte de a începe proiectarea arhitecturalã.

� Proiectul arhitecturii va permite descoperirea de cerinþe necunoscute sau puþin înþelese ºi poate ajuta, de asemenea, la rafinarea cerinþelor.

� Se recomandã ca proiectarea arhitecturalã sã fie iterativã, indiferent de modelul procesului software.


Pre- ºi Post- condiþii ale procesului de proiectare a arhitecturii

Intrãri � cerinþe ºi constrângeri (architectural drivers)

� Cerinþe funcþionale de nivel superior (generale).

� Cerinþe pentru atributele de calitate.

� Constrângeri tehice ºi business.

Ieºiri

� Descompunerea arhitecturalã: elemente, responsabilitãþi, relaþii ºiinterfeþe

� Documentaþia :

� reprezentãri ale arhitecturii din cele 3 perspective fundamentale

� date, motivaþii, prozã descriptivã, etc.


Cerinþe funcþionale ºi constrângeri

Cerinþele funcþionale de nivel superior sunt acele cerinþe funcþionale care au impact asupra arhitecturii

� Descrierile textuale ale comportamentului obligatoriu al sistemului (...�shall�...).

� Cazurile de utilizare ce descriu modul în care opereazã sistemul.

Constrângerile includ

� Constrângerile tehnice - devin cerinþe în care deciziile de proiectare sunt pre-specificate.

� Constrângerile business sau programatice -�QX�VXQW�GH�QDWXUă�tehnicã dar au un impact indirect profund asupra proiectului

arhitecturii.



Cerinþele pentru atributele de calitate sunt deseori derivate din specificaþii abstracte

� �Competitivitate pe o piaþã cu costuri scãzute.�

� �Sistemul trebuie sã fie sigur.�

� �Sistemul trebuie sã fie modificabil.�

QAW (Quality Attribute Workshop) este o tehnicã bunã pentru

obþinerea de scenarii iniþiale pentru atributele de calitate, DAR

� De obicei se obþin doar puncte de pornire bune� lipsesc detalii necesare pentru a sprijini proiectarea.

� Se ocupã doar de proiectare preliminarã, prototipare ºi/sau dialog cu stakeholder-ii.


Rafinare scenariu pentru atribut de calitate

Exemplu de cerinþã pentru un atribut de calitate:

�Un mesaj neanticipat este recepþionat de un proces al sistemului în timpul funcþionãrii

normale. Procesul trebuie sã informeze operatorul ºi sã continue operarea în mod normal, fãrã a avea perioade de nefuncþionare.�

Atributul de calitate vizat ��

Este o descriere rezonabilã a acestuia (în sensul cã se poate proiecta o arhitecturã

utilizând acest scenariu) ?

Arhitectul va rafina scenariile iniþiale imature pentru atributele de calitate ºi va defini scenarii de caz :

Exemplu:�Indicatorul de eroare de la rutina de acces a discului produce: Un mesaj ce va fi trimis la operator Comutarea sistemului în starea anterioarã corectã

Re-iniþializarea discului în background.�


Rafinare continuã

Se pot utiliza componentele scenariului pentru atribute de calitate (v.curs 3 slide

19)�SHQWUX�UDILQDUHD�FRQWLQXă�D�VFHQDULLORU�SHQWUX�DWULEXWHOH�GH�FDlitate.

� Sursã pentru stimul � entitatea care a generat un stimul

� Stimul � o condiþie care afecteazã sistemul

� Context � contextul (referitor la sistem) în care a apãrut stimulul

� Artefact � elementul sistemului ce a fost stimulat de cãtre stimul

� Rãspuns � activitatea ce rezultã în sistem din cauza stimulului

� Mãsuri ale rãspunsului � mãsura prin care va fi evaluat rãspunsul sistemului la stimul

Se rafineazã scenariile atributelor de calitate pe mãsurã ce se analizeazã, se descompune ºi/sau se modificã arhitectura sistemului software.


Cerinþe ºi constrângeri vs. specificaþii de sistem

Nu sunt necesare specificaþii detaliate înainte de a se începe proiectarea arhitecturalã.

� Pe mãsurã ce se exploreazã ºi se analizeazã cerinþele ºi constrângerile în dialog cu stakeholder-ii, se fac noi descoperiri despre spaþiul cerinþelor. De obicei nu apar noi cerinþe ci se ajunge la o mai bunã înþelegere a celor existente.

� Proiectul arhitecturii oferã un instrument natural pentru rafinarea ºi stabilizarea cerinþelor ºi ajutã la descoperirea zonelor potenþial problematice.

Toate cerinþele se vor maturiza pe mãsurã ce se dezvoltã proiectul

arhitecturii.


Exemplu

Fie urmãtorul scenariu pentru atribut de calitate:

�În condiþii de operare normalã ºi pentru orice configuraþia de vehicul aerian, simulatorulsoftware preia eºantioane de date de intrare de la toate comenzile de intrare de la pilot ºi actualizeazã toate afiºajele cu o frecvenþã de 75Hz.�

În esenþã, arhitectul trebuie sã rãspundã la urmãtoarea întrebare:

�Fiind dat acest stimul provenit din aceastã sursã, la aceste artefacte, în aceste condiþii (context), rãspunde sistemul aºa cum este precizat în mãsura�LQGLFDWă�SHQWUX�

rãspuns?�

�Sursã pentru stimul

�Stimul�Context�Artefact�Rãspuns

�Mãsuri ale rãspunsului


Ghid pentru arhitectul software

Identificarea contextului

Selectarea unui element de pornire, descompunere, rafinare

Consolidarea documentaþiei

Evaluarea arhitecturii

Repetare procedurã

Obs. Dacã sunt implicate ºi sisteme legacy atunci trebuie în prealabil descoperitã ºi evaluatã

arhitectura acestora.


Exemplu

Simulator de zbor

Intrãri de la pilot : cârmã, elevator, eleron, acceleraþie

Ieºiri : afiºãrile simulatorului, miºcarea simulatorului


Exemplu � contextul business

Specificaþiile sistemului

Obiectivul : construirea unui simulator general pentru antrenare, ieftin ºi portabil

Controlul miºcãrii se face simplu ºi e bazat pe sistem cardanic

Suport pentru max. 3 (243cm X 138cm X 9,5 cm) panouri de afiºare plate pentru vederile din exteriorul cabinei de pilotaj

Un panou de afiºare plat mic pentru instrumentele de mãsurã

Procesoare bazate Intel ��H�DJUHDWă�VROXþia cu procresoare multiple.

Responsabilitãþi contractuale:

Contractorul principal este responsabil pentru sistemul cardanic, carcasa simulatorului, controalele pilotului (cârmã, elevator, eleron, acceleraþie) ºi pentru panourile de afiºare.

Presupunem cã suntem subcontractori pentru dezvoltarea software-lui, contractorul principal având responsabilitatea construirii simulatorului.


Hardware-ul simulatorului

Aparate de mãsurã

Afiºaj lateralAfiºaj frontal

Intrare

Comenzi pilot

Carcasa

Pilot

Sistem cardanic

Vedere lateralã

Afiºaj lateral

Afiºaj frontal

Comenzi pilot

Carcasa

Pilot

Aparate de mãsurã

Afiºaj lateral

Vedere de sus


Cerinþe cheie (1)

C1. Sistemul acceptã intrãri de la pilot prin intermediul cârmei, elevatorului, eleronului ºi acceleraþiei

� Actualizeazã 3 afiºaje pentru a oferi imagini din afara cabinei.

� Actualizeazã afiºajul pentru instrumentele de mãsurã (altitudine, orizont artificial, poziþie, combustibil, senzor RPM, unghiul de urcare/coborâre).

� Activeazã sistemul cardanic pentru a simula forþele aeronavei asupra pilotului din simulator.

C2. Sistemul trebuie sã ofere suport pentru instruirea de bazã, dar sã

permitã simularea unei game de aeronave prin configurarea

simplã a regulilor de zbor la setarea/pornirea simulatorului.


Cerinþe cheie (2)

C3. Sistemul trebuie sã ofere rãspuns instantaneu (actualizarea imaginilor ºi a miºcãrii) la comenzile pilotului, a.î. sã ofere o

experienþã realistã ºi sã previnã �rãul de simulator�.

C4. Sistemul trebuie sã fie uºor de dezasamblat ºi mutat în altã locaþie.

C5. Ulterior punerii sale în funcþiune, sistemul trebuie sã permitã

editarea de noi controale de zbor.

Este evident necesarã rafinarea ºi analiza acestor cerinþe înainte de începerea proiectãrii.


Stabilire context

Problematicã generalã:

Poziþia arhitectului software în raport cu alte activitãþi de proiectare

� Sistem, întreprindere, software, toate.

Cãrui proiectant îi va impune restricþii arhitectura software realizatã

� Arhitecþi, proiectanþi de detaliu pentru software, programatori.

Elemente externe arhitecturii proiectate:

Surse de date, evenimente, interfeþe externe

Sisteme legacy

Factori de mediu


Stabilire context - exemplu

Simulator Software

Cârmã

Elevator

Eleron

Acceleraþie

Afiºaj stânga

Afiºaj dreapta

Afiºaj central

Instrumente de mãsurã

Gimbal

Limitele sistemului

Intrare pentru sistem

Ieºire sistem

Sistem







Repetare procedurã


Descompunere (1)

Contextul sistemului stabileºte scena pentru descompunerile ulterioare ale sistemului.

Un context lipsit de acurateþe, incomplet, sau imprecis stabilit are consecinþe negative asupra descompunerii sistemului ºi asupra implementãrii.

EXEMPLE:

� Responsabilitãþi greºit definite între organizaþii

� Intrãri/ieºiri nedefinite

� Dificultãþi de integrare (agravate în dezvoltarea distribuitã)

� Aºteptãri care nu se potrivesc

�Selectare element de pornire

�Descompunere

�Rafinare


Descompunere (2)

Istoric, descompunerea a fost dirijatã de funcþionalitate.

Din discuþiile de la acest curs rezultã cã structura unui sistem are puþin în comun cu funcþionalitatea purã ºi mai mult cu satisfacerea:

� Constrângerilor:

� Constrîngerile devin limite pentru spaþiul de proiectare: fie le satisfacem fie negociem relaxarea lor.

� Atributelor de calitate:

� Cerinþele pentru atributele de calitate sunt deseori împletite cu funcþionalitatea, dar mãsura în care sunt satisfãcute atributele ne

conduce de obicei cãtre structurã.


�Descompunere

�Rafinare


EXEMPLU � scenarii pentru atribute de calitate cheie

Fie urmãtoarele scenarii pentru atribute de calitate cu prioritate mare:

Sistemul trebuie sã poatã fi reamplasat într-o locaþie nouã. Sistemul poate fi dezasamblat ºi împachetat pentru transport în 4 ore ºi reasamblat la noua locaþie în 4 ore.

Simulatorul trebuie reconfigurat pentru a simula un aeroplan de performanþã. Pentru aceasta sistemul este oprit (shut down), sunt încãrcate noile reguli de zbor pentru

aeroplanul performant, sistemul este repornit ºi pregãtit de utilizare în mai puþin de 15 minute.

În condiþii de operare normalã ºi pentru orice configuraþia de vehicul aerian, simulatorul software preia eºantioane de date de intrare de la toate comenzile de intrare de la pilot ºi actualizeazã toate afiºajele, cu o frecvenþã de 75Hz.


Selectarea unui element de pornire

Se selecteazã perspectiva iniþialã � aceasta trebuie menþinutã pe

parcursul operaþiei de descompunere;

Comutarea cãtre o altã perspectivã se va face în mod conºtient!

Se selecteazã un stil arhitectural global care satisface cerinþele ºi constrângerile cheie.

DISCUÞIE:

� Unele probleme pot sugera un stil particular.� Stilurile sunt puncte de plecare ºi trebuie rafinate.

� Deºi la nivel global sistemul poate expune un anume stil, sistemele reale sunt ansambluri de stiluri.

� Un singur stil nu poate optimiza toate cerinþele ºi constrângerile � trebuie fãcute compromisuri. Aceasta evidenþiazã importanþa prioritizãrii cerinþelor ºi constrângerilor.


�Descompunere

�Rafinare


Dacã nu este evident un stil de pornire, descompunerea începe cu �sistemul�.

Decompunerea este condusã utilizând toate cerinþele ºi constrângerile.

Se începe cu constrângerile, se continuã cu atributele de calitate ºi în final se considerã funcþionalitatea.

Sistemul este descompus în �elemente� care sunt consistente cu perspectiva.

Forþele de

proiectare

Constrângeri

Funcþionalitate de nivel înalt

Atribute de calitate Proiectul

arhitecturii

Structuri

:

Arhitect

Selectarea unui element de pornire


�Descompunere

�Rafinare


Exemplu (1)

Simulatorul de zbor

� O constrângere cheie � �trebuie utilizate procesoare Intel�.

Forþeazã aceasta alte constângeri ca:

� Utilizarea unui anumit limbaj

� Utilizarea unui anumit sistem de operare ?

Ce atribute de calitate ar putea fi determinante pentru descompunere:

� Abilitatea de a adãuga controale la simulator

� Abilitatea de a modifica regulile de zbor,

� Portabilitatea fizicã

� Necesitãþile de performanþã,... sau altceva?

Aceºti factori trebuie sã vã motiveze intuiþia.


�Descompunere

�Rafinare


Exemplu (2)

Un simulator este un sistem de control clasic ºi existã douã stiluri pe

care le putem lua în considerare:

� Stilul polling (I/E cu aºteptare în buclã)

� Stilul bazat pe întreruperi (interrupt/event)

ÎNTREBÃRI :

Este unul dintre acestea o poziþie de pornire rezonabilã?

Care sunt avantajele ºi dezavantajele fiecãrui stil considerat?

Ce ar putea motiva selectarea unuia dintre aceste stiluri sau a unei alte abordãri?


�Descompunere

�Rafinare


Exemplu (3)

Propunere: luarea în considerare atributului de calitate performanþã.Astfel sistemul trebuie considerat din perspectivã dinamicã ºi descompus în procese. Se ºtie cã buclele de I/E sunt rapide ºi deterministice. Totuºi utilizarea unei singure bucle este limitatã necesitatea de a gândi sistemul în termeni de bucle concurente.

Simulator

Software

cârmã

elevator

eleron

acceleraþie

afiºaj stânga

afiºaj dreapta

afiºaj central

instrumente de mãsurã

gimbal

Limita sistemului

Intrare

Ieºire

Sistem

Depozitar

afiºaj dreapta Buclã

actualizare afiºaje

afiºaj stânga

afiºaj central


Buclã

actualizare

sistem cardanic

gimbal x

gimbal y

gimbal z

Buclã citire

date de intrare

cârmãelevatoreleronacceleraþie

proces memorie date scriere

date

citire

date


�Descompunere

�Rafinare


Exemplu (4)

Descompunerea este ºi trebuie sã fie ghidatã în mare mãsurã de

intuiþie ºi experienþã.

Cunoaºterea structurilor este utilã ºi deseori tempereazã deciziile

instinctive.

În exemplu:

Stilul predominant este �polling� (cu aºteptare în buclã), dar este utilizat ºi un depozitar ansamblu de stiluri.

Concurenþa este aplicatã ca tacticã asupra stilului selectat iniþial, cu scopul creºterii suplimentare a performanþei.


�Descompunere

�Rafinare


Ghid pentru descompunere (1)

Scopul descompunerii iniþiale este de a decide asupra partiþionãrii

grosiere a sistemului în elemente.

Rafinarea�DFHVWRU�HOHPHQWH�VH�IDFH�SULQ�GHFRPSXQHUL�XOWHULRDUH.

Dupã descompunerea iniþialã, descompunerea elementelor are loc în manierã iterativã.

Operaþii:

� Asignarea corespunzãtoare la elemente a responsabilitãþilorderivate din cerinþe funcþionale, cerinþe de calitate ºi constrângeri.

� Rafinarea elementelor prin selectarea de stiluri subordonate ºi/sau prin decompunere ulterioarã.

� Aplicarea corespunzãtoare de tactici de rafinare.

� Dezvoltarea ºi definirea interfeþelor elementelor subordonate.


�Descompunere

�Rafinare


Ghid pentru descompunere (2)

Recomandãri pentru operaþia de descompunere a sistemului:

� Pãstrarea consistenþei cu perspectiva ºi cu elementele ºi relaþiile specifice acesteia.

� Este utilã creare la început a unei legende.

Ordinea descompunerii / rafinãrii variazã:

� Utilizarea eficientã a expertizei speciale descompunere în adâncime.

� Cunoaºterea domeniului �GHVFRPSXQHUH�RUL]RQWDOă.

� Tehnologie nouã nevoia de prototipuri descompunere în adâncime.


�Descompunere

�Rafinare


Asignarea responsabilitãþilor

Responsabilitãþile sunt derivate din cerinþele funcþionale, cerinþele de calitate ºi constrângeri.

� Cerinþele funcþionale � descrise textual ºi cu cazuri de utilizare

� Atributele de calitate � descrise cu scenarii

� Constrângeri business ºi constrângeri tehnice

Responsabilitãþile funcþionale ºi constrângerile tehnice sunt asignate la elemente specifice.

Atributele de calitate ºi unele constrângeri business�VXQW�VDWLVIăFXWH�GH�

însãºi partiþionarea sistemului.


�Descompunere

�Rafinare


Asignarea responsabilitãþilor - exemplu

Depozitar



afiºaj stânga

afiºaj central


Buclã

actualizare

sistem cardanic

gimbal x

gimbal y

gimbal z

Buclã citire

date de intrare



date

citire

date

Citire date de intrare: Preia eºantioane de la controalele pilotului ºi scrie date într-o tabelã cu valori curente (TVC).Depozitar: Memorie volatilã ce gãzduieºte TVC. Aceastã structurã conþine ultimele valori citite de la intrarea datelor de la pilot.

Actualizare afiºaje: Citeºte date din TVC ºi actualizeazã afiºajele cu informaþii din exteriorul cabinei de comandã conform regulilor de zbor specifice aeronavei pentru care a fost configurat simulatorul.

Actualizare sistem cardanic: Citeºte date din TVC ºi scrie date la dispozitivul hardware de control al sistemului cardanic pentru a miºca simulatorul conform regulilor de zbor specifice aeronavei pentru care a fost configurat simulatorul.

Structura generalã: Structura generalã a fost aleasã astfel încât sã maximizeze performanþasistemului ºi conþine trei bucle concurente. Alternativa rejectatã include� rejectatã din motivele�


�Descompunere

�Rafinare


Rafinarea elementelor -�PHWRGă

Dupã descompunerea iniþialã ºi alocarea responsabilitãþilor.

Recursiv - descompunerea ºi rafinarea fiecãrui element al sistemului:

� Asignarea de responsabilitãþi la elemente, extrase din cerinþe ºi constrângeri.

� Complementarea cu tactici a stilurilor arhitecturale sau a descompunerii iniþiale.

� Rafinarea elementelor subordonate.

� Definirea interfeþelor elementelor subordonate.


�Descompunere

�Rafinare


Rafinarea elementelor - impact

Descompunerile elementelor ar putea necesita rafinarea cazurilor de utilizare, a scenariilor pentru atribute de calitate ºi a constângerilor.

� De exemplu, un caz de utilizare care iniþializeazã întregul sistem trebuie divizatîn cazuri de utilizare care iniþializeazã subsistemele în condiþii variate.

Rafinarea ºi descompunerea elementelor are impact asupra satisfacerii responsabilitãþilor.

Responsabilitãþile unui element descompus sunt delegate elementelor subordonate acestuia

� Pot fi implicate elemente subordonate la nivel individual o responsabilitate este satisfãcutã de un element subordonat ce nu mai este descompus.

� Poate fi necesarã coordonarea de elemente subordonate �VDWLVIDFHUHD�XQHL�responsabilitãþi implicã cooperarea mai multor elemente subordonate ºi devine o responsabilitate distribuitã.


�Descompunere

�Rafinare


Exemplu (1)

Fie cerinþa de a oferi suport pentru configurarea de vehicule multiple pe baza regulilor de zbor � primul pas este revizitarea scenariului de configurare.

Acest scenariu oferã o informaþie crucialã asupra momentului când trebuie sã fie

fãcutã configurarea ºi cât de repede trebuie sã reporneascã sistemul.

Reconfigurarea este descrisã în termeni de performanþã � acesta este un lucru obiºnuit ºi ilustreazã natura complexã ºi obscurã a cerinþelor pentru atribute de calitate.

Configurarea nu a fost încã asignatã ca responsabilitate nu s-a încheiat proiectarea arhitecturalã.

�Simulatorul trebuie reconfigurat pentru a simula un aeroplan performant. Sistemul este oprit (shut down), sunt încãrcate noile reguli de zbor pentru aeroplanul

performant, sistemul este repornit ºi pregãtit de utilizare în mai puþin de 15 minute.�


�Descompunere

�Rafinare


Exemplu (2)

Depozitar



afiºaj stânga

afiºaj central


Buclã

actualizare

sistem cardanic

gimbal x

gimbal y

gimbal z

Buclã citire

date de intrare



date

citire

date

Pe baza descompunerii iniþiale, pare rezonabil ca responsabilitatea pentru reconfigurarea simulatorului sã fie legatã de controlul afiºajelor ºi al sistemului cardanic, deoarece actualizarea acestor elemente depinde de regulile de zbor configurate.

Trebuie însã sã analizãm în detaliu aceste elemente pentru a înþelege cum funcþioneazã

configurarea, pentru a asigna responsabilitatea ºi pentru a vedea dacã putem satisface

mãsurile rãspunsului exprimate în scenariu.


�Descompunere

�Rafinare


Exemplu (3)

Depozitar



afiºaj stânga

afiºaj central


Buclã

actualizare

sistem cardanic

gimbal x

gimbal y

gimbal z

Buclã citire

date de intrare



date

citire

date

afiºaj stânga

Depozitar

fiºiere

de configurare

Proces de

iniþializare sistem

Buclã

actualizare

sistem cardanic

gimbal x

gimbal y

gimbal z


actualizare afiºajeafiºaj central


DepozitarTVC

Buclã citire

date de intrare


Instanþiazã


�Descompunere

�Rafinare


Exemplu (4)

Responsabilitãþile de pornire ºi de reconfigurare a sistemului, nealocate anterior, au fost asignate procesului de iniþializare�D�VLVWHPXOXL.

Responsabilitãþile trebuie actualizate de câte ori modificãm

descompunerea !.

Procesul de iniþializare a sistemului: Responsabil de citirea ºi parsarea fiºierelor de configurare, verificându-le totodatã ºi corectitudinea.

Dupã validarea configurãrii, procesul de iniþializare a sistemului va configura corespunzãtor ºi va instanþia procesele de actualizare afiºaje, de actualizare sistem cardanic, ºi de citire date de intrare.


�Descompunere

�Rafinare


Schimbarea perspectivei

Perspective diferite permit analizarea a diferite calitãþi ale sistemului.

În cursul descompunerii ºi asignãrii de responsabilitãþi poate fi necesarã

schimbarea perspectivei ºi începerea descompunerii dintr-o perspectivã nouã.

Fie urmãtoarea cerinþã:

�Modificarea software-lui pentru simulator, a.î. sã poatã încorpora clapete ulterior lansãrii facilitãþilor iniþiale de operare. Modificarea trebuie realizatã în mai puþin de 3 luni-om, inclusiv testare.�

Dacã utilizãm vederi dinamice, este imposibilã analiza, proiectarea ºi asignarea de responsabilitãþi referitoare la aceastã cerinþã de

modificare.


�Descompunere

�Rafinare


Exemplu (1)

afiºaj stânga

Depozitar

fiºiere

de configurare

Proces de

iniþializare sistem

Buclã

actualizare

sistem cardanic

gimbal x

gimbal y

gimbal z


actualizare afiºajeafiºaj central


DepozitarTVC

Buclã citire

date de intrare


Instanþiazã

Pentru a permite funcþionarea clapetelor ar putea fi implicate procesele de citire a datelor de intrare, de actualizare a afiºajelor ºi de actualizare a sistemului cardanic, justificând astfel analiza suplimentarã a

acestor elemente � probabil este o modificare localã dar este greu de precizat din aceastã perspectivã.

Pentru a proiecta aceastã modificare potenþialã este necesar sã apelãm la vederile

modulare ale acestor procese (din perspectiva staticã).


�Descompunere

�Rafinare


Exemplu (2)

Reprezentarea sistemului din perspective diferite contribuie la o analizã mai profundã ºi la un design mai complet.Pentru procesul de citire date de intrare vom înþelege: posibilitãþile�GH�DGăXJDUH�D�FODSHWHORU, impactul�adãugãrii clapetelor asupra performanþei, dacã e suficient un acelaºi driver de dispozitiv pentru toate clapetele sau sunt necesare drivere separate, dacã existã abordãri mai bune.

proces Memorie date

Scriere

date

Citire

dateBuclã citire

date de intrare


InstanþiazãDepozitar

TVC

Bucla principalã de citire

Cititor date cârmã

Cititor date elevator

Cititor date eleron

Cititor date acceleraþie

Modul scriere în TVC

Driver dispozitiv Driver dispozitiv Driver dispozitiv Driver dispozitiv

invocare modul


�Descompunere

�Rafinare


Exemplu (3)

afiºaj dreaptaBuclã


afiºaj stânga

afiºaj central


Dupã descompunerea ºi analiza din perspectivã staticã (vedere modularã) a procesului de actualizare a afiºajelor�UH]XOWă�Fă�modificãrile pot fi izolate în afiºajul instrumentelor de mãsurã deoarece doar în afiºajele corespunzãtoare sunt vizibile efectele clapetelor � efectele sunt configurabile în fiºierele de configurare a vehiculului.

Actualizare afiºaje (Main)

Calcul poligoane

exterioare cabinei

de comandã

Refresh afiºaje Citire TVC

Refresh

afiºaj stânga

Refresh

afiºaj central

Refresh

afiºaj dreapta

Calcul aparate de

mãsurã

Refresh afiºaj

instrumente de

mãsurã


�Descompunere

�Rafinare


Exemplu (4)

Buclã actualizare

sistem cardanic

gimbal x

gimbal y

gimbal z

Actualizare sistem cardanic (Main)

Calcul

miºcare

Actualizare sistem cardanic Citire TVC

Scrie Gimbal X Scrie Gimbal Y Scrie Gimbal Z

Driver dispozitiv Driver dispozitiv Driver dispozitiv

Dupã descompunerea ºi analiza din perspectivã staticã (vedere modularã) a procesului de actualizare a sistemului cardanic rezultã cã modificãrile pentru adãugarea de clapete nu vor afecta software-ul. Clapetele vor schimba miºcarea dispozitivului cardanic, dar efectele sunt configurabile în fiºierele de configurare a vehiculului.


�Descompunere

�Rafinare


Selectare tactici pentru rafinarea elementelor (1)

Tacticile rafineazã stilurile ºi pot ajuta la echilibrarea efectelor negative ale unui stil.

Factori ce ghideazã selectarea tacticilor:

Cerinþele ºi consrângerile (în particular cerinþele pentru atributele de calitate).

Efectele colaterale pe care un stil care implementeazã tactica le are asupra cerinþelor funcþionale, cerinþelor de calitate ºi constrângerilor.

Aplicarea tacticilor înseamnã rafinarea deciziilor arhitecturale iniþiale.

Metafora �dialog� pentru rafinarea elementelor:Tacticã: bucle concurenteTactica promoveazã: performanþaTactica inhibã: o anume modificabilitate,

simplitatea.Etc.

Cerinþa: crearea unui simulator de zbor generalStil iniþial: pollingStilul promoveazã: simplitate, uºurinþã în testareStilul inhibã: performanþa


�Descompunere

�Rafinare


Selectare tactici pentru rafinarea elementelor (2)

Valoarea stilurilor ºi tacticilor selectate în exemplul anterior depinde de importanþa relativã a performanþei ºi modificabilitãþii.

Aceasta ilustreazã noþiunea de compromis arhitectural ºi importanþa prioritizãrii cerinþelor ºi constrângerilor.

Arhitecþii trebuie sã realizeze compromisurile necesare menþinerii echilibrului stilurilor ºi tacticilor a.î. proiectul arhitecturii sã îndeplineascã proprietãþile dorite pentru sistem.


�Descompunere

�Rafinare


Definirea interfeþelor

Interfeþele elementelor se bazeazã pe relaþiile între elemente.

Interfeþele constau din:

Serviciile ºi proprietãþile pe care le necesitã ºi pe care le oferã un element de proiectare, identificate în cursul alocãrii de responsabilitãþi.

Fluxurile de date ºi de control necesitate de fiecare element, conform definiþiei sale.

Nivelul de detaliu poate fi mai grosier decât signatura �GHOHJDUHD, cãtre

proiectanþi, a stabilirii detaliilor de comunicare.

Se pot utiliza cazurile de utilizare ºi scenariile pentru a înþelege mai bine interfeþele:� Interacþiunile� Dependenþele� Informaþiile partajate ºi schimbate de componente


�Descompunere

�Rafinare







Repetare procedurã


Documentarea arhitecturii (1)

1. Precizarea contextului proiectului.

2. Documentarea cerinþelor ºi constrângerilor ºi a prioritãþilor�ORU�UHODWLYH.

3. Crearea reprezentãrilor arhitecturii iniþiale� Considerarea perspectivei ºi consistenþa cu perspectiva� Stabilirea contextului sistemului ºi contextului software-lui� Includerea de explicaþii�SHQWUX�UHSUH]HQWăULOH�JUDILFH

4. Documentarea responsabilitãþilor elementelor ºi a relaþiilor dintre ele.

5. Documentarea motivaþiilor deciziilor de proiectare� Responsabilitãþile elementelor� Alegerile fãcute ºi variantele respinse� Ipotezele considerate

6. Prezentarea rezultatelor analizei / prototipurilor care au venit în sprijinul deciziilor de proiectare luate.

7. Documentarea responsabilitãþilor ºi interfeþelor pentru fiecare element ºi actualizarea acestora la fiecare modificare.


Documentarea arhitecturii (2)

Documentarea arhitecturii pe parcursul proiectãrii ei.

� Capturarea corectã a informaþiilor de proiectare (în special motivaþiile).

� Capturarea permanentã a informaþiilor pentru a evita uitarea lor ºi aglomerarea activitãþilor de realizare a documentaþiei.







Repetare procedurã


Metode de evaluare a arhitecturii

Utilizarea scenariilor derivate din cazurile de utilizare funcþionalã, pentru a �testa��Fă�DUKLWHFWXUD�întruneºte cerinþele funcþionale cheie de nivel înalt.

Utilizarea scenariilor pentru atributele de calitate ºi a cazurilor de utilizare, pentru a �testa��Fă�DUKLWHFWXUD�întruneºte cerinþele cheie pentru atributele de calitate.

ATAM (Architecture Tradeoff Analysis Method) este o modalitate de a ne asigura cã arhitectura satisface cerinþele funcþionale, cerinþele de calitate ºi constrângerile. (http://www.sei.cmu.edu)


Recomandare

Evaluarea continuã pe parcursul elaborãrii arhitecturii.

Problemele apãrute pot fi diminuate prin

reproiectare,

experimentare,

studiere suplimentarã.







Repetare procedurã


Repetare procedurã (1)

Am definit:� Elemente ºi relaþii� Responsabilitãþi atribuite� Interfeþe� Documentaþie

Descompunerea, rafinarea, evaluarea ºi documentarea continuã pânã când:

� Elementele ºi relaþiile sunt definite ºi suficient documentate.

� Responsabilitãþile derivate din cerinþe funcþionale, de calitate ºi constrângeri sunt asignate elementelor.

� Interfeþele elementelor sunt definite.

� Documentaþia arhitecturalã este suficient de completã; este prescriptivã

ºi descriptivã.

� Arhitectura a fost evaluatã ºi acceptatã.


Repetare procedurã (2)

Factori de care depinde reluarea:� domeniul ºi complexitatea.� asigurarea unei documentaþii suficiente.

Cel mai important factor este intuiþia arhitectului.

De fapt nu se terminã niciodatã.

Proiectarea arhitecturii trebuie sã fie o activitate continuã pe durata de viaþã a

produsului.

Dupã punerea în funcþiune arhitectura joacã un rol semnificativ în gestionarea modificãrilor ºi în estimarea costului ºi impactului acestora. Arhitectura împarte modificãrile în:

� Locale � în interiorul unui singur element

� Non-locale ��VH�SURSDJă�GLQFROR�GH�OLPLWHOH�XQXL�VLQJXU�HOHPHQW

� Arhitecturale ��HURGHD]ă�VWUXFWXUD�IXQGDPHQWDOă�D�VLVWHPXOXL

Aceastã analizã este imposibilã în lipsa unei arhitecturi explicite ºi bine documentate.


Revizitarea contextului business (1)

Dacã apar situaþii speciale este important sã revizitãm stakeholder-ii ºi cerinþele business generale.

Fie urmãtoarea cerinþã:�Pentru a permite antrenarea în grup, simulatoarele trebuie interconectate într-o reþea pentru

a crea un singur mediu de simulare în care utilizatorii pot interacþiona.

Aceastã cerinþã intrã în conflict cu o serie de cerinþe ºi constrângeri iniþiale.

Pe durata de viaþã a unui produs pot sã aparã oricând cerinþe aflate în conflict.�De aceea poate sã aparã necesitatea de a revizita contextul business oricând pe

durata de viaþã a produsului.



Contextul original ��VLPXODWRU�XQLF, de sine stãtãtor.Noua cerinþã modificã domeniul sistemului în mod semnificativ.

simulator

simulator

simulator

simulator Alte probleme ce necesitã atenþie:

� Cum vor fi conectate simulatoarele individuale pentru a forma un�VLVWHP. Existã un standard?

� Simulatoarele se comportã bine individual, dar cum se vor comporta ca federaþie?

� Cum va fi reprezentat spaþiul simulatorului într-un mediu de simulare distribuit?

Arhitectul trebuie sã fie preocupat de:

� Modul în care entitãþile de la alte simulatoare apar pe afiºaj.

� Ce informaþie trebuie trimisã la alte simulatoare ºi cum este trimisã

aceasta.



Problemele puse anterior sunt de naturã tehnicã.În termeni de context business ele devin:

� Ce stakeholder-i au nevoie de aceastã caracteristicã ºi de ce?

� Este asta ceea ce vrem sã facem cu adevãrat?

� Este suficientã piaþã pentru aceastã caracteristicã?

� Suntem dispuºi sã plãtim pentru complexitatea adãugatã?

� Se poate adãuga aceastã caracteristicã mai târziu?

� Cât de târziu?

� Dacã o adãugãm mai târziu suntem dispuºi sã plãtim acum mai mult pentru un

proiect care va permite adãugarea mai uºoarã sau vom relua atunci proiectarea

de la zero?

Acestea sunt întrebãri la care trebuie sã rãspundem înainte de a ne ocupa de detalii tehnice.



Arhitecþii nu trebuie sã încerce rezolvarea acestui gen de probleme doar cu metode tehnice.

Pe de altã parte, managerii nu vor lua singuri decizii cu impact tehnic.

Modificãrile apãrute în urmãtoarele zone indicã necesitatea revizitãrii

contextului business:

� Modelele business

� Structurile organizaþionale

� Stakeholder-i cheie

� Pieþele

� Tehnologiile


Bibliografie suplimentarã

The Architecture Based Design Methodhttp://www.sei.cmu.edu/reports/00tr001.pdf

Attribute-Driven Design (ADD), Version 2.0http://www.sei.cmu.edu/reports/06tr023.pdf

A Practical Example of Applying Attribute-Driven Design (ADD), Version 2.0http://www.sei.cmu.edu/reports/07tr005.pdf

Architecture-Centric Engineering (ACE) Initiativehttp://www.sei.cmu.edu/library/assets/brochures/RTSS_ACE_2010.pdf

(disponibile ºi în secþiunea �Documentaþii� de pe site-ul cursului)


Arhitecturi pentru sistemesoftware

Curs 9



PLAN CURS

SOA ��$UKLWHFWXUă�RULHQWDWă�SH�VHUYLFLL Caracteristicile serviciilor

Perspectiva C&C

Atribute de calitate promovate si inhibate

Cloud computing

Caracteristici, avantaje, aplicabilitate

Modele pentru CC

CC & SOA


SOA genericã


Mecanism SOA


SOA � Arhitecturã orientatã pe servicii

SOA � abordare arhitecturalã pentru construirea de sisteme sau de

aplicații care utilizeazã un set de servicii.

Serviciu � o implementare a unei funcționalitãți bine definitã, cu o interfațã

publicatã care se poate descoperi și care poate fi utilizatã de consumatorii

serviciului la construirea de aplicații sau de procese business.

SOA definește funcționalitatea unei aplicații ca un set de servicii partajate, reutilizabile.

SOA � stil arhitectural în care sistemele sunt compuse din consumatori de servicii și furnizori de servicii.



SOA � soluþie de integrare de aplicaþii disparate într-un context web aflate pe platforme multiple de implementare.

SOA defineºte interfaþa serviciului în termeni de protocol ºi funcþionalitate.

Endpoint � punct de acces la serviciu.

SOA ��VHW�GH�XQLWăþi de funcþionalitate distincte � servicii - care sunt disponibile într-o reþea pentru a permite combinarea ºi reutilizarea lor în producerea de aplicaþii.

Comunicarea � transfer de date în formate bine definite sau coordonare activitãþi între douã sau mai multe servicii.



SOA frameworks � servicii reutilizabile ce constituie scheletul unei arhitecturi.

� Incorporeazã ºabloane de proiectare ºi bune practici de inginerie software

� Specificã responsabilitãþile componentelor din fiecare strat ºi colaborãrile

dintre acestea.

Avantaje framework:

� Proiectarea, dezvoltarea ºi repartizarea rapidã de servicii web, aplicaþii ºi portlet-uri modulare, flexibile, scalabile, suportive.

� Îmbunãtãþirea consistenþei software-lui livrat.

� Autocontrol asupra sa ºi asupra aplicaþiei ºi serviciilor create în cadrul acestuia.

�Nivel de abstractizare ridicat

�Tipice unui domeniu

�Scalabile



Alte definiții

� �A service-oriented architecture (SOA) is an application framework that takes everyday business applications and breaks them down into individual business functions and processes, called services. An SOA lets you build, deploy and integrate these services independent of applications and the computing platforms on which they run.��IBM Corporation

� �Service-Oriented Architecture is an approach to organizing information technology in which data, logic, and infrastructure resources are accessed by routing messages between network interfaces.��Microsoft

� A SOA is �a set of components which can be invoked, and whose interface descriptions can be published and discovered.��Worldwide Web Consortium [W3C 04]


PLAN CURS

SOA ��$UKLWHFWXUă�RULHQWDWă�SH�VHUYLFLL

Caracteristicile serviciilor Perspectiva C&C


Cloud computing


Modele pentru CC

CC & SOA


Caracteristicile serviciilor

� Reutilizabile

� Expun un contract formal - definește termenii schimbului de informații (interfața) și alte informații de descriere a serviciului

� Implementare invizibilã și irelevantã pentru consumatorii serviciului

� Slab cuplate

� Compozabile � aplicațiile pot fi organizate pe mai multe nivele de abstractizare

� Autonome � în limitele logicii implementate

� Nu memoreazã stare (stateless)

� Pot fi descoperite � pe bazã de descrieri publicate

� Au interfațã adresabilã prin rețea � suportã accese de la distanțã

� Localizare transparentã � suport pentru migrare; pãstratã într-un registry



Compozabile:

Creare aplicație = asamblarea și coordonarea activitãților serviciilor necesare implementãrii procesului business.

Se poate scrie cod suplimentar pentru implementarea funcționalitãții specifice aplicației.

Surse de servicii:� Existente în companie și reutilizate� Externe� Construite special pentru aplicația curentã

Problematicã proiectare:

� Identificare funcþionalitate pentru serviciu

� Stabilire granularitate serviciu


PLAN CURS



Perspectiva C&C Atribute de calitate promovate si inhibate

Cloud computing


Modele pentru CC

CC & SOA


Perspectiva arhitecturalã

Interacþiunea consumator � furnizor serviciu : manifestatã la runtime.

Perspectiva si viewtypeDinamicã, C&C

OBS:Diagramele C&C sunt complementate cu diagrame de comportament (ex. diagrame

de secvenþe) care descriu secvenþele de interacþiuni ce au loc în diferite tranzacþii.


Tipuri de componente ºi conectori

Tipuri de componente

� Consumator serviciu

- Furnizor serviciu- Componente speciale

-�PDJLVWUDOă�(ESB - enterprise service bus)

- registru

Tipuri de conectori:- apeluri sincrone/asincrone utilizând

� SOAP� HTTP� Infrastructurã pentru transfer mesaje

Cristina Mîndruþã Arhitecturi pentru sisteme software Slide 15OPC � Order Processing Center

Specificul descrierii arhitecturale

În general - descrierea arhitecturii centratã pe structurile sistemului ce

trebuie implementat.

Soluþiile SOA ��QHFHVLWă�înþelegerea ºi documentarea fluxului procesului business.

EXEMPLU din: Bianco P., Kotermanski R., Merson P., Evaluating a Service-Oriented Architecture, sept. 2007


Semantici

� Consumatorul serviciului trimite cereri la furnizorul serviciului

� Furnizorul serviciului furnizeazã serviciul pe baza cererii

consumatorului serviciului

� Furnizorul de serviciu poate fi consumator al altui serviciu

� Registrul ��SăVWUHD]ă�LQIRUPDții despre servicii,�SH�FDUH�OH�furnizeazã la cerere consumatorilor în vederea descoperirii serviciilor

� Magistrala -�PHGLD]ă�LQWHUDFțiunea orientatã pe evenimente

dintre consumatorii și furnizorii de servicii


PLAN CURS



Perspectiva C&C


Cloud computing


Modele pentru CC

CC & SOA



Interoperabilitatea : abilitatea unei colecții de entitãți care comunicã de a

partaja informație specificã și de a opera cu aceasta conform unor semantici operaționale agreate.

SOA asigurã interoperabilitatea serviciilor dezvoltate în limbajediferite și repartizate pe platforme diferite (tehnologii diferite: .NET,

Java EE, PHP, etc).



Extensibilitatea : ușurința de a extinde capabilitãțile serviciilor fãrã a

afecta alte servicii sau pãrți ale sistemului.

Extindere:

- arhitecturã, adãugând noi servicii

- servicii, fãrã modificarea interfeței

- servicii, cu modificarea interfeței

� Depinde de extensibilitatea mesajelor interfeței.

� Limitare vocabular și structurã mesaje ��LPSOLFă�R�FRPXQLFDUH�PDL�eficientã

Compromis : eficiențã comunicare vs. extensibilitate



Modificabilitatea : abilitatea de a face rapid și eficient modificãri la un sistem

Cuplare slabã între consumatori ºi furnizori

Servicii auto-conþinute, modulare, accesate prin interfeþe coezive

Dependenþe puþine ºi controlate între elementele arhitecturii

Promovatã modificabilitatea implementãrilor

Inhibatã modificabilitatea interfeþei deoarece este dificil de identificat consumatorii serviciului.


Atribute de calitate parțial promovate

Fiabilitatea : abilitatea unui sistem de a se menþine în operare.

- fiabilitatea mesajelor � sintagme ale furnizãrii mesajelor:1. in-order � Mesajele sunt livrate în ordinea în care au fost trimise.

2. at-least-once � Fiecare mesaj trimis este livrat cel puþin o datã.

3. at-most-once � Fiecare mesaj trimis este livrat cel mult o datã (nu existã duplicate).

4. exactly once � Fiecare mesaj trimis este livrat exact o datã.

- fiabilitatea serviciilor



Adaptabilitatea : ușurința cu care un sistem poate fi schimbat pentru a servi noi cerințe.

Independenþã localizare ºi politici declarative

Descoperire ºi negociere dinamicã a metodei de legare la serviciu ºi a comportamentului expus de acesta

Modificare transparentã a serviciilor: implementare, adaptare la noi platforme

Adãugare de noi servcicii

Modificare a modurilor de combinare a serviciilor

Problemã: Nu existã standarde. Gestionarea adaptabilitãþii este fãcutã de consumatorii ºi furnizorii de servicii ºi depinde de fiecare situaþie în parte.



Disponibilitatea : gradul în care un serviciu este operaþional ºi accesibil atunci când trebuie utilizat.

� monitorizatã la furnizor și la consumator

� contracte SLA (service level agreement) -�VSHFLILFă�IXUQL]RUXO�VHUYLFLXOXL, disponibilitatea garantatã pentru serviciu, penalitãți pentru furnizor.



Utilizabilitatea :�PăVXUD�FDOLWăþii experienþei utilizatorului în interacþiunea cu informaþii sau servicii.

La furnizor:

� Granularitate mai mare a datelor trimise de serviciu : implicã transfer redus în rețea (ex. opțiuni de selecție, informații suplimentare pentru clarificare date).

� Operații tipice pentru utilizabilitate: anulare cerere, undo, serviciu pe date agregate, informații de feedback (ex. procent�UHDOL]DW, timp estimat pânã la finalizare)

La consumator:

- posibilitatea de a reface o stare

- resincronizarea cu un serviciu cu care s-a întrerupt comunicarea



Scalabilitatea : abilitatea de a funcționa, fãrã degradarea altor atribute de

calitate, atunci când sistemul îºi�VFKLPEă�GLPHQVLXQHD�VDX�YROXPXO�FX�scopul de a îndeplini nevoile utilizatorilor.

Depinde de implementarea serviciilor folosite.

Soluții pentru creșterea scalabilitãții:

� Scalabilitate orizontalã : distribuirea încãrcãrii pe mai multe calculatoare

� Scalabilitate verticalã : upgrade hardware la site-ul serviciului



Securitatea : confidenþialitate, autentificare, integritate, disponibilitate

� Servicii furnizate de terþi

� Autentificarea nu este întotdeauna suficientã

� �3URWHMDUHD�GDWHORU�H�QHFHVDUă�OD�WUDQVPLVLH�GDU�ºi pe perioada stocãrii

� Mecanisme pentru gestionarea drepturilor de acces

� Informaþiile din registrul de servicii trebuie sã fie la zi ºi adãugate de furnizori

valizi



Performanța :�WLPS�GH�UăVSXQV, numãr de cereri procesate în unitatea de timp, abilitatea de a respecta termene (deadlines).

� Comunicare în sisteme distribuite

� Reþelele tipice nu garanteazã latenþã deterministicã

� Apeluri suplimentare pentru descoperire servicii

� Overhead-ul introdus de protocoalele de comunicare (stub/skeleton, motoare SOAP, proxy, etc.)

Soluþii pentru îmbunãtãþirea performanþei:

� Transparenþa localizãrii serviciilor replicarea serviciului ºi aplicarea unei strategii de echilibrare a încãrcãrii creºterea numãrului de cereri

procesate în unitatea de timp ºi a disponibilitãþii sistemului.

� Posibilitatea de a funcþiona în regim asincron.



Testabilitatea : gradul în care este facilitatã stabilirea criteriilor de testare

și performanța testelor în a determina îndeplinirea acestora.

� Testarea de elemente distribuite� Codul sursã al serviciilor nu este în general disponibil� Servicii descoperite la runtime nedecidabil ce serviciu concret va fi folosit� Dificil de replicat într-un context de testare cauzele problemelor apãrute la

execuþie:� Aplicaþie

� Serviciu utilizat de aplicaþie

� Infrastructura aplicaþiei sau cea a serviciului

� Încãrcarea platformei pe care ruleazã serviciul

� Agentul care descoperã ºi localizeazã serviciul

Soluþii:� Furnizorul oferã servicii ºi infrastructuri adiþionale ca suport pentru procesele

de testare ºi de depanare desfãºurate atât la furnizor cât ºi la client.� Instrumente pentru testare servicii individuale ºi testare de integrare.


Discuþie

Soluþiile SOA -�XWLOL]HD]ă�OHJDUH�GLQDPLFă�SHQWUX�D�SHUPLWH�FăL�DOWHUQDWLYH�de execuþie ºi ordonãri diferite ale mesajelor.

Atributele de calitate sunt mai dificil de estimat ºi de analizat.

SOA ��FRQHFWDUH�GH�VLVWHPH, entitãþi business ºi tehnologii multiple trebuie analizate complexitatea ansamblului ºi forþele politice pentru a decide compromisurile arhitecturale necesare (mai mult decât în cazul proiectãrii unei singure aplicaþii, unde predominã preocupãrile tehnice).

Evaluarea unei arhitecturi SOA trebuie sã echilibreze aspectele specifice SOA cu aspecte relevante pentru restul stilurilor implicate în arhitectura finalã a sistemului dezvoltat.


PLAN CURS



Perspectiva C&C


Cloud computing Caracteristici, avantaje, aplicabilitate

Modele pentru CC

CC & SOA


Cloud computing

Cloud computing (CC) � Opțiune (soluție) arhitecturalã pentru dezvoltare

de software folosind resurse virtualizate ºi scalabile dinamic,�Jă]GXLWH, executate și administrate în centre mari de date și accesibile la cerere sub�formã de servicii în rețea (internet).

Suport flexibil pentru:

� creare/utilizare funcționalitate pentru aplicație (SaaS)

� dezvoltare și rulare aplicație (PaaS)

� repartizarea aplicației (IaaS)

Altã perspectivã ��SDUWDMDUH�WUDQVSDUHQWă�și flexibilã de resurse distribuite

hw și sw de cãtre utilizatori multipli.

Cloud = system of systems


Cloud computing

Componente

� Furnizor� Consumator

Semantici:� Consumatorul solicitã resurse pe care le poate configura

� Furnizorul furnizeazã resurse sub formã de servicii cloud

� Consumatorii îºi pot extinde cererea de resurse ºi nu trebuie sã

achiziþioneze hw/sw suplimentare pentru a utiliza serviciul

� Furnizorii gestioneazã infrastructura (hw și sw) ºi pun în comun resurse de capacitatea celor cerute de consumatori.


Cloud computing

Tehnologii suport:

Virtualizare : procesul de substituire în care resurse fizice sunt substituite prin resurse logice (virtuale) care�YRU�DYHD�SURSULHWăți derivate din cele ale resurselor originale dar capacitate diferitã.

Software as a service � furnizarea online de funcționalitate software, similar cu furnizarea acesteia de pe mașina localã.

Arhitecturi grid - servicii de tip cluster


Cloud computing

Proiectarea în contextul CC se bazeazã pe principiul unei arhitecturiscalabile ca poate fi utilizatã de inginerii sistemului.

� Oferã un mod tipic de a obþine ºi gestiona resurse IT pe scarã largã.

� Resursele de calcul sunt furnizate ca utilitãþi.� Resursele sunt configurabile funcție de necesitãțile consumatorului.

� Resursele fizic distribuite devin resurse logice locale.


Cloud computing � analizã economicã

CC � model economic pentru un mod specific de a obþine ºi gestiona resurse IT.

Consumatorul nu deþine bunuri IT proprii.Procurare/eliberare resurse - la cerere, funcție de necesitãțile consumatorului.

Modelele de taxare - flexibile și predictibilePermit planificarea la consumator.

Consumatori

� întreprinderi mici - majoritatea

� întreprinderi mari -�H[SORUHD]ă�SDUDGLJPD

�Pay per use�Pay per subscription�Pay per transaction


Cloud computing

CC ��DVFXQGH�FRQVXPDWRULORU�GH�UHVXUVH�DFWLYLWățile de achiziție,

întreținere, monitorizare pentru infrastructura necesarã.

Activitãțile de management al resurselor sunt implementate de o

infrastructurã dedicatã a furnizorului.

Ex. Webmail

Furnizorul - întreþine spaþiul server ºi oferã acces.

Consumatorul ��LQWURGXFH�R�DGUHVă�ZHE�în browser ºi trimite informaþiile de acces la

un cont.


Cloud computing


PLAN CURS



Perspectiva C&C


Cloud computing

Caracteristici, avantaje, aplicabilitate Modele pentru CC

CC & SOA


Caracteristici cheie

Resurse la cerere � consumatorul achiziționeazã unilateral capabilitãți de calcul funcție de necesitãți, fãrã interacțiune umanã cu fiecare furnizor de servicii.

Acces omniprezent la rețea ��FDSDELOLWățile sunt disponibile în rețea și accesate prin mecanisme standard ce permit utilizare de platforme client eterogene (e.g., telefon

mobil, laptop, PDA).

Punerea în comun a resurselor independent de locațiile acestora �resursele de calcul ale furnizorului sunt constituite în rezervoare pentru a servi consumatorii conform unui model de chiriași multipli (multitenant). Diferite resurse fizice și virtuale sunt asignate dinamic și reasignate conform cererilor consumatorilor. Consumatorul nu are control asupra localizãrii resursei primite.

Elasticitate rapidã � capabilitãțile sunt furnizate/eliberate rapid și elastic. Consumatorul�SHUFHSH�Fă�UHVXUVHOH�VXQW�LQILQLWH�și pot fi cumpãrate oricând și în orice cantitate.

Servicii mãsurate. Capabilitãțile sunt taxate pe bazã de mãsurãtori, utilizând un

model de taxare care sã permitã promovarea optimizãrii utilizãrii resurselor.


Avantaje

Disponibilitate � acces oricând la resurse prin intermediul unei conexiuni internet standard.

Colaborare � modalitate de a lucra simultan pe date ºi informaþii comune.

Elasticitate � furnizorul gestioneazã transparent utilizarea resurselor, pe bazã de cerinþe care se

schimbã dinamic.

Infrastructurã la cost redus � modelul de taxare permite consumatorului sã plãteascã doar

resursele necesare, fãrã investiþie în resurse fizice ºi fãrã costuri de mentenanþã ºi upgrade.

Mobilitate � datele ºi aplicaþiile pot fi accesate de oriunde.

Reducere risc � utilizare pentru testare de idei ºi concepte înainte de a se face investiþii majore în

tehnologie.

Scalabilitate � acces la resurse scalabile funcþie de cererea consumatorilor.

Virtualizare � fiecare consumator are o vedere unicã a resurselor disponibile, independent de organizarea acestora în termeni de dispozitive fizice; furnizorul poate optimiza utilizarea resurselor de cãtre

mai mulþi consumatori.

Implementare rapidã ºi inovativã ��HOXGDUHD�DFWLYLWăþilor de achiziþionare, instalare, testare platformã; reutilizare servicii inovate continuu de cãtre furnizori.

�Green� ��UHGXFH�FRQVXPXO�GH�HQHUJLH�HOHFWULFă.


Dezavantaje

Interoperabilitate � nu existã încã un set universal de standarde ºi/sau interfeþe, ceea ce poate duce

la blocare pe furnizor.

Latenþã � accesul se face prin internet, ceea ce introduce latenþã pentru fiecare comunicare dintre

consumator ºi cloud.

Constrângeri de platformã ºi limbaj � unii furnizori suportã doar anumite platforme ºi limbaje.

Regulamente � jurisdicþie, protecþie date, practici corecte de manipulare a informaþiilor, transferul datelor internaþionale preocupã în special organizaþiile care gestioneazã date sensibile.

Fiabilitate � dependentã de fiabilitatea infrastructurii hw de la furnizori.

Control resurse � Nivelul de control al consumatorului asupra furnizorului ºi resurselor variazã de la

un furnizor la altul.

Securitate � se oferã securitate bazatã pe autentificare cu ID ºi parolã ºi pe criptare date.

Referitor la confidenþialitatea datelor, informaþiile sunt expuse în mediu necontrolat de consumator.

Soluþie la o parte din probleme: SLA (service level agreement) = contract între furnizor ºi consumator în care sunt prevãzute nivele de calitate pentru serviciu ºi penalizãri dacã acestea nu sunt

îndeplinite.


CC recomandat

� Procese, aplicații și date puternic independente, slab cuplate cu alte aplicații sau informații.

� Puncte de integrare bine definite în care aplicația poate partaja date, comportament și procese.

� Este suficient un nivel redus de securitate.

� Nucleul arhitecturii interne este bine organizat.

� Platforma doritã este Web/Internet sau este acceptatã repartizarea

GUI într-un browser.

� Costul conteazã și se identificã un beneficiu clar.

� Aplicații noi


CC nerecomandat

� Procese, date și aplicații strâns cuplate, puternic interdependente

� Puncte de integrare nedefinite, lipsa mecanismelor de sincronizare între componentele din cloud și cele din întreprindere. (interfețe)

� Necesitatea unui nivel ridicat de securitate.

� Controlul este critic.

� Nucleul arhitecturii interne nu este suficient de ordonat.

� Aplicația necesitã interfațã nativã.

� Balanțã defavorabilã a costului.

� Aplicații legacy.


PLAN CURS



Perspectiva C&C


Cloud computing


Modele pentru CC

SOA & CC


Cloud computing - clasificãri


SaaS

Capabilitate: Software-as-a-Service (SaaS, AaaS). Capabilitãþi specifice nivelului business (ex. E-mail, CRM)

SaaS � tehnicã de a oferi aplicații software utilizatorilor finali fãrã a cereacestora sã ruleze aplicația pe calculatorul propriu.

Exemple de furnizori:

� Google Apps: oferã instrumente de birou bazate web (ex. E-mail, calendar, management documente)

� salesforce.com: aplicație pentru managementul relațiilor cu clienții (customer relationship management - CRM)

� zoho.com: gamã largã de aplicații bazate web, în cea mai mare parte pentru utilizare la nivelenterprise

http://sites.force.com/appexchange/home � cloud computing marketplace

http://sites.force.com/appexchange/home�cloud


PaaS

Capabilitate: Platform-as-a-Service (PaaS). Capabilitãþi specifice dezvoltãrii ºi execuþiei de aplicaþii.

Utilizarea resurselor oferite de furnizor pentru a crea ºi rula aplicaþii mai vaste decât cele pe care consumatorul le poate gestiona pe resursele proprii.


� Akamai EdgePlatform: platformã pentru calcul distribuit pe care consumatorii îºi pot pune aplicaþii web proprii.

� Force.com: platformã de dezvoltare ºi execuþie aplicaþii ºi componente cumpãrate de la AppExchange sau aplicaþii ale consumatorului.

� Google App Engine: stivã completã pentru dezvoltare ºi execuþie de aplicaþii

� Microsoft Azure Services Platform: servicii de calcul ºi stocare la cerere, precum ºi o platformã de

dezvoltare bazatã pe Windows Azure

� Yahoo! Open Strategy (Y!OS): similar


IaaS

Capabilitate: Infrastructure-as-a-Service (IaaS). Infrastructurã computaþionalã (ex. CPU, memorie, rețea, mașinã virtualã)

Permite consumatorilor sã-ºi extindã în mod flexibil și eficient infrastructura IT.


� Amazon Elastic Compute Cloud (EC2): oferã o maºinã virtualã specialã (AMI) ce poate fi repartizatã

pe infrastructura EC2

� Amazon Simple Storage Solution (S3): oferã acces la resurse de stocare scalabile dinamic

� GoGrid: oferã acces la resurse scalabile dinamic de calcul ºi de stocare, ca ºi la servere dedicate

� IBM Computing on Demand (CoD): oferã acces la servere configurabile ºi la servicii de stocare date

� Microsoft Live Mesh: oferã acces la un sistem de fiºiere distribuit pentru uz individual

� Rackspace Cloud: oferã acces la resurse scalabile dinamic de calcul ºi stocare ºi la aplicaþii ºi instrumente cloud oferite de furnizori terþi


Public ºi Privat

Cloud public � resurse oferite ca servicii, de obicei printr-o conexiune la internet, pentru o taxã calculatã pe bazã de utilizare.

Cloud privat � resurse repartizate în interiorul unui firewall, gestionate și folosite de organizaþia proprietarã.

Exemple de companii ce oferã resurse pentru construirea de cloud privat: 3tera;Eucalyptus; Oracle (Fusion); Ubuntu.

Specializãri ale acestor tipuri:

Cloud comunitar � resurse partajate de mai multe organizaþii; sprijinã

nevoile ºi problemele specifice comunitãþii

Cloud hibrid � combinaþie de cloud public, privat, community.


CC - discuþie

Utilizarea resurselor din cloud extinderea arhitecturii dincolo de graniþele întreprinderii pentru a incorpora resursele cloud arhitectura nu se opreºte la firewall.

Înþelegerea atât a resurselor care existã în întreprindere cât ºi a celor furnizate de cloud este chiar mai criticã, deoarece aceste resurse trebuie configurate corect în contextul unei arhitecturi cu scopul de a îndeplini cerinþele.

Utilizarea Web-ului a revoluþionat modul în care se acceseazã ºi se vizualizeazã

informaþiile.

CC va revoluþioneazã modul în care privim resursele IT.


Tehnologii CC - detalii


PLAN CURS



Perspectiva C&C


Cloud computing


Modele pentru CC

CC & SOA


CC & SOA

� Concepte diferite

� În relaþie

� SOA � ºablon arhitectural - La nivel strategic � decizie funcþie de cerinþe ºi constrângeri

� CC � instanþã de arhitecturã (opþiune arhitecturalã)- La nivel tactic � mod de a rezolva problema

� Combinaþie recomandatã pentru probleme la nivel de întreprindere.


CC & SOA

Se pot utiliza independent.

DARCC este definit ºi funcþioneazã în termeni de servicii, oferind servicii externe.

CC este o soluþie arhitecturalã pentru SOA.

CC � extensie a SOA peste resursele furnizate de cloud (ex. storage-as-a-service, data-as-a-service, platform-as-a-service).

SOA poate utiliza resursele CC ca servicii, incluzându-le în arhitecturã ca

atare.

Problema arhitectului -�Vă decidã ce servicii, informaþii ºi procese sunt candidate pentru a fi plasate în cloud ºi sã decidã ce servicii cloud trebuie

abstractizate în cadrul SOA existentã sau emergentã.


CC & SOA

SOA poate utiliza resursele CC ca servicii, incluzându-le în arhitecturã ca atare

SOA se poate realiza utilizând CC.


CC & SOA

Structurarea sistemului conform stilului SOA este mecanism pentru reutilizare ºi agilitate ºi oferã ºi abilitatea de a ne da seama ce trebuie sã

rãmânã local ºi ce poate fi pus în cloud.

Arhitecturã SOA bunã strategie bunã CC reducerea costurilor ºi creºterea agilitãþii.

Serviciile cloud sunt model de proiectare bunã pentru utilizabilitate, durabilitate, scalabilitate.

Serviciile SOA sunt guvernate (control ºi implementare de politici) : se pot seta politici la nilvel de servicii ºi se controleazã modificãrile serviciilor.


CC & SOA

SOA utilizând CC este o abordare arhitecturalã foarte bunã:

� Abilitatea de a folosi resurse utilizând configuraþia cea mai bunã posibil

� Transparenþa localizãrii resurselor

� Scalabilitatea resurselor

Proiectarea arhitecturalã pentru SOA & CC este esenþialã !!!

CC oferã opþiuni arhitecturale referitoare la platforme (noi) mai eficiente ºi mai ieftine.

În cursul proiectãrii arhitecturale se pot reloca ºi/sau crea componente arhitecturale pe platforme CC.


CC & SOA - viitor

Mutarea mai multor resurse de tip infrastructurã pe platforme CC, incluzând

memorie, baze de date, procesare tranzacþii, dezvoltare aplicaþii.

Mixarea ºi potrivirea acestor resurse în contextul arhitecturii unei aplicaþii.

Exemplu:

Baza de date poate fi la un furnizor, platforma de dezvoltare la altul, iar serverul de proces ºi motorul de reguli la un al treilea.

Cu alte cuvinte putem �împrãºtia��DUKLWHFWXUD�OD�DFHL�IXUQL]RUL�GH�FORXG�FH�RIHUă�FHD�mai bunã funcþionalitate, fiabilitate ºi preþ, iar resursele furnizate de cloud vor colabora fãrã probleme cu toate resursele locale.



Curs 10



PLAN CURS

Concepte referitoare la documentaþie

Tehnici de realizare a documentaþiei

Utilizarea UML pentru reprezentarea arhitecturii


Documentarea arhitecturii software

Architectura software serveºte ca plan general pentru sistem ºi pentru proiectul de dezvoltare a acestuia.

� Este artefactul cel mai potrivit pentru realizarea analizelor în fazele iniþiale de dezvoltare de software.

� Este purtãtorul principal al atributelor de calitate.

� Este cheia întreþinerii ºi evoluþiei�VLVWHPXOXL�GXSă�GDUHa acestuia în funcþiune.

Documentarea arhitecturii este un pas esenþial în realizarea ei.

�Rol

�Principii

�Elemente


Rolul documentaþiei

Documentaþia arhitecturalã are rolul de a comunica informaþii ºi idei.

Documentaþia trebuie realizatã a.î. cel ce o citeºte sã înþeleagã corect ºi completinformaþiile ºi ideile transmise.

Probleme ale practicii curente:

� Diagrame box-and-line ambigue

� Justificare insuficientã a motivaþiilor

� Lipsa discutãrii de variante alternative

� Utilizarea inconsistentã a notaþiilor

� Combinaþii confuze de perspective ºi tipuri de vederi

�Rol

�Principii

�Elemente


Principiile documentaþiei complete

1. Scrisã din punctul de vedere al cititorului.

2. Evitarea repetãrilor nenecesare.

3. Evitarea abiguitãþilor.

4. Utilizarea unei organizãri standard.

5. Explicarea motivaþiilor pentru deciziile arhitecturale.

6. Pãstrarea documentaþiei�OD�FXUHQW�FX�PRGLILFăULOH.

7. Revizuirea documentaþiei.

Majoritatea acestor principii se aplicã pentru documentaþie în general, nu doar pentru documentaþia arhitecturilor software.

�Rol

�Principii

�Elemente



Evitarea ambiguitãþilor

Dacã se utilizeazã diagrame box-and-line, atunci se vor defini precis semnificaþiile casetelor ºi ale liniilor (ex. prin includerea unei legende).

Precizarea semnificaþiei sãgeþilor:

� Flux de control? Flux de date? Invocare serviciu?

Indicarea faptului cã se foloseºte o notaþie standard (ex. UML).

Tipurile de vederi nu se vor combina decât în mod controlat ºi cu precizarea acestui lucru.

Suplimentarea notaþiilor grafice cu explicaþii.

�Rol

�Principii

�Elemente


Corect:

� Liniile ºi casetele au forme/culori diferite ºi o cheie de explicare a semnificaþiei acestora

� Se utilizeazã tabele pentru rezumarea dimensiunilor/variantelor

� Diagramele nu încearcã sã transmitã prea multe:

� Separare pe vederi, unde este necesar

� Încercarea de a încadra fiecare vedere a arhitecturii într-o singurã paginã

� Utilizarea unei ierarhii

� Distincþie clarã între perspective (tipuri de vederi)

� Separarea problemelor (concerns)

� Precizarea corespondenþelor, acolo unde e posibil ºi necesar



�Rol

�Principii

�Elemente


Incorect:

� Toate liniile aratã la fel

� Sãgeþile nu înseamnã nimic

� Sãgeþile înseamnã mai multe lucruri

� Confuzie între implementare ºi abstractizare arhitecturalã

� Lipsa unei legende sau a unei chei de interpretare

EXEMPLU:

Semnificaþii posibile pentru sãgeþi într-o vedere C&C

� A transferã controlul la B

� A transferã date la B

� A preia o valoare de la B

� A transmite flux de date la B

� A trimite mesaj la B

� �

BA



�Rol

�Principii

�Elemente


Exemplu de documentaþie bunãvedere din perspectiva C&C

Web Component

LDAP Directory

RDBMS

Direct Adapter

Indirect Adapter

Controller

Interface

SOAP Connector

& roles

LDAP Connector

& roles

DB Connector

& roles

RMI Connector

& roles

Event Bus

Connector

& roles

Legend

Viewer

Rule &

Configuration DB

Integrated

Data Rep

External

LDAP1

External

LDAP2

External

DB1

External

DB2

Change Log

Me

ta

Vie

we

r

Dire

ct

Adapte

r1

Dire

ct

Adapte

r2

Indire

ct

Aapte

r1

Indire

ct

Aapte

r2

Adapte

r

Manager

Administrator

Console

Jo

in

En

gin

e

Façade

Component

Transaction Log

Adapter

Registry

System Boundary

�Rol

�Principii

�Elemente


Elementele esenþiale ale documentaþiei arhitecturale (1)

Enunþul cerinþelor

� Contextul business, motivaþia produsului, domeniul

� Atributele de calitate, preferabil în termeni de scenarii

Enunþul constrângerilor

� business, de implementare, de repartizare

Descrierea contextului

� Sistemele cu care trebuie sã interacþioneze, interfeþele externe

Diagramele de reprezentare a arhitecturii

� Cu precizarea clarã a semnificaþiilor liniilor ºi casetelor

� Extinse cu prozã explicativã

� Conþinând vederile relevante

�Rol

�Principii

�Elemente


Elementele esenþiale ale documentaþiei arhitecturale (2)

Motivarea deciziilor arhitecturale

� Modul în care se adreseazã cerinþele ºi constrângerile

� Alternativele considerate

Caracteristici de aplicare stil / linie de produse

� Dimensiunile de variabilitate pronosticate

� Aspectele ce trebuie schimbate

Probleme de management

� Implicaþii asupra structurii organizaþionale a echipei de dezvoltare

� Utilizarea revizuirilor arhitecturii

Alte probleme de proiectare

� OA&M (operaþii, administrare ºi întreþinere)

�Rol

�Principii

�Elemente


PLAN CURS





Tehnici de realizare a documentaþiei ahitecturale

� Diagrame de context

Tipuri de vederi diferite au diagrame de context diferite

� Combinarea mai multor vederi

Stiluri suprapuse ºi combinate

� Utilizare ierarhii

Pentru componente ºi conectori

� Documentarea interfeþelor

Diagrame de secvenþe

�Diagrame de context

�Combinare vederi

�Utilizare ierarhii

�Documentare interfeþe


Tehnici de realizare a documentaþiei ahitecturale

Utilitate: înþelegerea arhitecturii (sub)sistemului necesitã atât cunoaºterea elementelor ºi relaþiilor sale componente cât ºi a elementelor contextului ºi a relaþiilor cu acestea.

Pe diagrama de context se reprezintã:

� Contextul cu care interacþioneazã sistemul

� Interfeþele externe

� Alte (sub)sisteme pe care se bazeazã

Diagrama de context - variante:

� În perspectivã staticã cu vedere modularã - (sub)sistemul ºi alte straturi

� În perspectivã dinamicã cu vedere C&C -�FăLOH�GH�LQWHUDFþiune ale (sub)sistemului cu elemente externe acestuia

� În perspectiva alocãrii cu vedere de repartizare -�DOWH�VLVWHPH�FX�FDUH�partajeazã aceleaºi resurse ale contextului.


�Combinare vederi




Diagrama de context � exemplu 1

KEY

Interaction

Interaction

Algorithms

Exchange Data

Data AcquisitionRequest

LOR Data

Higher levelAMSR-E dataproducts

ACRIM L0 data & higher level products

ASTER GDS

Other Users

Science ComputingFacilities

LPS

AMSR-E SCF

ACRIM SCF

SAGE III MOC

SAGE IIILO data

ScienceData

ProcessingSegment

SAGE III SCF

SAGE IIILO data

SAGE IIIhigher levelproducts

MOPITT SCF

MOPITT LOdata

MOPITT LOhigher levelproducts

EDOS/EBnet

GLAS SCF

MODAPS

GLAS higherlevel products

LO data

GLAS LOdata

MODIS L1A/L1B, ancillarydata

MODIS higherlevel products

SystemExternalEntity

X interacts with YX Y

Data flows fromX to Y

X Y

Remarcaþi:

� Indicarea clarã a

sistemului ºi a contextului

� Etichetarea conectorilor externi

� Utilizarea uneichei/legende

� Reprezentarea multiplicitãþii


�Combinare vederi





AdministratorAdministrator

Manage Project Data

HR SystemHR SystemPersonnel Data

LEGEND

Database connection

TSP SupportTool

System

TSP SupportTool

System

Interaction

Manage personalProcess, product data

Create Project

Refer other project data

External Entity(People)

System

Memberof Other Team

Memberof Other Team

TeamMember

TeamMember Team LeaderTeam Leader

External Entity(System)

SMTPServer

SMTPServer

Notification Data

Message


�Combinare vederi





External LDAP server1

ExternalLDAP server2

External DB server1

External DB server2

User Query

UserInformation

User Information

Administrator

UserInformation

AdministratingOperation

System

Boundary

External Directory

Interaction

Legend

Metadirectory

External RDBMS

Web Client

UsersUsers

UsersUsers

LDAP user ( Application,

LDAP Client and so on)

UserInformation


�Combinare vederi




Combinarea vederilor multiple

Separarea vederilor ne permite sã divizãm ºi sã dominãm

complexitatea arhitecturii.

� Oferã o separare clarã a problemelor (concerns)

� Genereazã însã probleme de relaþionare a lor

Documentaþia informalã are tendinþa de a estompa problematica

� În special problemele ce depãºesc frontierele tipurilor de vederi

Precizarea modului în care sunt relaþionate vederile dã informaþii despre profunzimea înþelegerii întregii arhitecturi!


�Combinare vederi





Relaþionarea vederilor unui sistem - prin precizarea corespondenþelor dintre:

module ºi componente ºi connectori

descompunerea modularã ºi straturi

componente ºi connectori ºi decizii de repartizare

straturi ºi asignare de sarcini de dezvoltare


�Combinare vederi





PROCEDURÃ:

1. Construire vedere combinatã care aratã elementele ºi relaþiile a douã vederi constitutive

A. Utilizare suprapuneri

B. Definire a unui stil hibrid care combinã elemente ºi relaþii ale ambelor vederi

2. Creare a unui document de legãturã care conþine corespondenþele dintre elementele ºi relaþiile dintr-o vedere cu elementele ºi relaþiile din cealaltã vedere.

Ex. Aratã cum modulele sunt replicate în componente ºi conectori.


�Combinare vederi




Combinarea vederilor multiple � exemplu 1

Software Decision Module Application Data Type Module

Numeric Data Type Module State Transition Event Mod.

Data Banker Module Singular Values Module Complex Event Module

Filter Behavior ModulePhysical Models Module

Aircraft Motion ModuleEarth Characteristics ModuleHuman Factors Module Target Behavior ModuleWeapon Behavior Module

Software Utility ModulePower-Up Initialization ModuleNumerical Algorithms Module

System Generation ModuleSystem Generation Parameter Mod.Support Software Module

Behavior-Hiding Module Function Driver Module

Air Data Computer ModuleAudible Signal ModuleComputer Fail Signal ModuleDoppler Radar ModuleFlight Information Display ModuleForward Looking Radar ModuleHead-Up Display ModuleInertial Measurement Set ModulePanel ModuleProjected Map Display Set ModuleShipboard Inertial Nav. Sys. Mod.Visual Indicator ModuleWeapon Release ModuleGround Test Module

Shared Services ModuleMode Determination Module Panel I/O Support Module Shared Subroutine Module Stage Director Module System Value Module Shared Services

Extended Computer

Function Driver

SoftwareUtilities

Device Interfaces

DataBanker

Application Data Types

PhysicalModels

FilterBehaviors

KEY Behavior-hidingmodule

Software decision-hiding module

Hardware-hidingmodule

Metodã simplã de combinare în aceeaºi vedere a informaþiilor din douã stiluri (stilul de descompunere ºi stilul stratificat).


�Combinare vederi





763�'DWD +5�'DWD

'DWD�7LHU

%URZVHU

1

$SSOLFDWLRQ

1

:$3

%URZVHU�1

&OLHQW�7LHU

:HE�6HUYHU

-DYD%HDQV

-63 6HUYOHW

6HUYOHW�&RQWDLQHU

-63 6HUYOHW

6HUYOHW�&RQWDLQHU

-DYD%HDQV

/RJLF�7LHU

/RFDO

5HS0DQ

/RFDO

5HS0DQ

*OREDO

5HS0DQ

&KHFN

3RLQWHU

/2*

)LOH

/2*

)LOH

&KHFN

3RLQWHU

C

:$3�6HUYHU$SSOLFDWLRQ

%URZVHU

6073

/LQNDJH

7DVN

&KHFNRU

+5�6\VWHP

,QWHUIDFH

Suprapunere vedere C&C de detaliu cu stilul în trei trepte.


�Combinare vederi





Suprapunere vedere C&C cu vedere de alocare.


�Combinare vederi





Combinare printr-o punte a stilului pipe-and-filter cu un stil cu date partajate.

BridgingElement

Filters

Database


�Combinare vederi




Utilizare ierarhii

Scop: Pãstrarea descrierii arhitecturale în limite controlabile

� Detaliile elementelor sunt definite în vederi separate.

Stiluri diferite expun relaþii arhitecturale diferite:

� Relaþia �parte-întreg��HVWH�VSHFLILFă�YHGHULL�FH�UHSUH]LQWă�descompunerea în module.

� Relaþia �substructurã� apare în vederi de tip C&C reprezentatepe trepte multiple.


�Combinare vederi




Utilizare ierarhii � exemplu

Web Component

LDAP Directory

RDBMS

Direct Adapter

Indirect Adapter

Controller

Interface

SOAP Connector

& roles

LDAP Connector

& roles

DB Connector

& roles

RMI Connector

& roles

Event Bus

Connector

& roles

Legend

Viewer

Rule &

Configuration DB

Integrated

Data Rep

External

LDAP1

External

LDAP2

External

DB1

External

DB2

Change Log

Me

ta

Vie

we

r

Dire

ct

Adapte

r1

Dire

ct

Adapte

r2

Indire

ct

Aapte

r1

Indire

ct

Aapte

r2

Adapte

r

Manager

Administrator

Console

Jo

in

En

gin

e

Façade

Component

Transaction Log

Adapter

Registry

System Boundary


�Combinare vederi




Rule

Translator

Router

Transaction

Coordinator

Receiver

Rule Set

Manager

Call &

Return

Legend

Message

Handler

Interface

Agent

Join

Engin

e

Context

<Event Bus>

Rule

and

<Config

ura

tion D

B>

<Façade

Component>

Send port

Receive port

Utilizare ierarhii � exemplu Detaliere componentei �Join Engine�


�Combinare vederi




Utilizare ierarhii � exemplu

Web Component

LDAP Directory

RDBMS

Direct Adapter

Indirect Adapter

Controller

Interface

SOAP Connector

& roles

LDAP Connector

& roles

DB Connector

& roles

RMI Connector

& roles

Event Bus

Connector

& roles

Legend

Viewer

Rule &

Configuration DB

Integrated

Data Rep

External

LDAP1

External

LDAP2

External

DB1

External

DB2

Change Log

Me

ta

Vie

we

r

Dire

ct

Adapte

r1

Dire

ct

Adapte

r2

Indire

ct

Aapte

r1

Indire

ct

Aapte

r2

Adapte

r

Manager

Administrator

Console

Jo

in

En

gin

e

Façade

Component

Transaction Log

Adapter

Registry

System Boundary

Web Component

LDAP Directory

RDBMS

Direct Adapter

Indirect Adapter

Controller

Interface

SOAP Connector

& roles

LDAP Connector

& roles

DB Connector

& roles

RMI Connector

& roles

Event Bus

Connector

& roles

Legend

Viewer

Rule &

Configuration DB

Integrated

Data Rep

External

LDAP1

External

LDAP2

External

DB1

External

DB2

Change Log

Me

ta

Vie

we

r

Dire

ct

Adapte

r1

Dire

ct

Adapte

r2

Indire

ct

Aapte

r1

Indire

ct

Aapte

r2

Adapte

r

Manager

Administrator

Console

Jo

in

En

gin

e

Façade

Component

Transaction Log

Adapter

Registry

System Boundary


�Combinare vederi




Utilizare ierarhii � exemplu Detaliere componentei �Direct Adapter�

Transaction

Coordinator

LDAP

Directory

Schema

Cache

Change

Notifier

Call &

Return

Legend

Message

Handler

Interface

Agent

Sensor

Sender

To the System

Load Sensor

Receiver

From the

system

Context

<External DB>

<Tra

nsactio

n

Log>

<Event Bus>

<Adapter

Manager>

Dire

ct

Adapte

r2

<Change

Log>

Connection

Manager

Cache

Cache

Access

Send port

Receive port


�Combinare vederi




Utilizare ierarhii � exemplu Detaliere componentei �Indirect Adapter�

LDIF

Converter

Sender

To The

System

Receiver

From the

System

Connection

Manager

LDIF Rule

Manager

Load Sensor

Call &

Return

Legend

Message

Handler

Interface

Agent

Context

<External DB>

<Tra

nsactio

n L

og>

Indire

ct

Aapte

r2

<Event Bus>

<Adapter

Manager>

Transaction

Coordinator

Sensor

Send port

Receive port


�Combinare vederi




Documentarea interfeþelor ºi a comportamentului

Etapã cheie la trecerea de la diagrame informale de nivel înalt la specificaþii arhitecturale mai detaliate.

Natura documentaþiei depinde de:

� Tipul de vedere ºi de stil

� Nivelul de detaliu dorit

� Notaþiile utilizate


�Combinare vederi




Documentarea interfeþelor

Interfaþã = frontierã prin care interacþioneazã sau comunicã douã

elemente.

Specificaþie de interfaþã = un enunþ�DO�SURSULHWăþilor, pe care arhitectul alege sã le facã cunoscute, ale elementului�FH�SUH]LQWă�LQWHUIDþa.

� Ceea ce este exprimat este la latitudinea arhitectului.

� Poate evolua în timp.

Actor (pentru un anumit element) = element, utilizator sau sistem cu care interacþioneazã elementul considerat.

Resursã (a unei interfeþe)� �facilitate adresabilã în cadrul unei interfeþe.

Ex. Funcþie, metodã, flux de date, variabilã globalã, endpoint mesaj, declanºator eveniment.


�Combinare vederi




Documentarea interfeþelor

Principii:

Toate elementele au interfeþe

Interfaþa unui element este separatã de implementarea acesteia

Un element poate avea mai multe interfeþe

Elementele oferã interfeþe (provided)

Elementele pot solicita interfeþe (required)

Mai mulþi actori pot interacþiona simultan cu un element prin intermediul

unei interfeþe a acestuia

Interfeþele pot fi extinse prin specializare

�2�FRPSRQHQWă�SRDWH�RIHUL�PDL�PXOWH�LQVWDQþe ale aceleiaºi interfeþe


�Combinare vederi




Exemplu � mod de organizare a documentaþiei interfeþelor

Extras din Documenting Software Architectures: Views and Beyond, Clements, et al. 2010


�Combinare vederi



Syntax � signatura : include orice informaþie necesarã

pentru a scrie corect un program ce utilizeazã resursa.

Semantics ��UH]XOWDWXO�XWLOL]ăULL�UHVXUVHL�GLQ�SHUVSHFWLYD�actorului ce o invocã (schimbare stare element, evenimente/mesaje transmise, etc); efecte colaterale; restricþii de utilizare a resursei.

Error Handling � condiþii de eroare ºi excepþii ridicate de resursã, respectiv comune tuturor resurselor interfeþei.

Variability � parametrii de configurare ºi modul în care aceºtia afecteazã semanticile interacþiunii.

Quality-Attribute Characteristics � valorile promise pentru atribute de calitate. (ex. SLA)


Interfeþe module vs. Interfeþe în vederi C&C

Interfaþã modul:

Defineºte (cel puþin) un set de rutine ce pot fi apelate.

Poate defini ºi rutine, din alte zone ale sistemului, necesare modului.

Interfaþã componentã în vedere C&C:

Defineºte un punct de interacþiune a componentei cu contextul sãu în timpul execuþiei.

Numitã �port�, pentru a face distincþia de interfaþa unui modul.

Exemplu: Filtru�)�FX�GRXă�LHºiri,

ambele scriind caractere într-o conductã.


�Combinare vederi



FF<<Interface>>

OutputPorturi


Documentarea comportamentului

Limitãri ale definiþiilor de interfaþã:

� Nu precizeazã ordinea interacþiunilor

� Nu precizeazã modul de interacþiune între elemente multiple.

Soluþie � exprimare comportament

(notaþii diferite; nivelul de detaliere este ales de arhitect)

Exemplu: diagramã de secvenþe


�Combinare vederi




Documentaþie �beyond views�



CONCLUZII

Documentaþia nu înseamnã doar casete ºi linii

Vederi diferite necesitã notaþii diferite

Nivelul de detaliu depinde de contextul de utilizare al documentaþiei

Realizarea unei documentaþii bune nu este o activitate trivialã

Efortul meritã fãcut


PLAN CURS





UML

UML � limbaj vizual de specificare, proiectare ºi documentare a artefactelor sistemelor software.

Standard de fapt ºi de drept pentru reprezentarea proiectelor software.

Utilizat în majoritatea instrumentelor pentru MDA (Model Driven Architecture) ºi pentru inginerie inversã.

Extensibil:

Oferã mecanisme de extensie (ex. exprimare constrângeri, stereotipuri ºi valori etichetate).

Se pot crea profile UML � grupuri de extensii.


UML

Poate fi utilizat pentru documentarea urmãtoarelor tipuri de reprezentãri

pentru structurile sistemului software:

Vederi ale modulelor (structuri statice)

Vederi ale structurilor dinamice

Vederi de alocare

Modelul datelorUML nu este întotdeauna notaþia cea mai potrivitã.

Documentarea comportamentului complementeazã vederile asupra

structurii.

�Perspectiva staticã

�Perspectiva dinamicã

�Perspectiva alocãrii

�Modelul datelor


UML

Atenþie:

Documentaþia unei vederi arhitecturale include diagrama DAR ºi o serie de elemente explicative.



UML ��SHUVSHFWLYD�VWDWLFă�module viewtype

Tip de element : - modul� �unitate de cod ce implementeazã un set de

responsabilitãþi.

Tipuri de relaþii :- �is part of� � relaþia parte-întreg- �depends on� � relaþia de dependenþã- �is a� � relaþie de specializare/generalizaresau de implementare

REPREZENTÃRI folosind UML:�Diagrama de clase (clase ºi interfeþe)�Diagrama de pachete

�is part of�Diagramã de pachete

conþine (sub) pachete ºi clase

�depends on�Dependenþa poate fi de mai multe tipuri, specificate prin stereotip (<<refine>>, <<instantiate>>,�)

�is a�Generalizare clasã

Realizare interfaþã

Obs. UML oferã ºi alte relaþii standard, care pot fi specializate utilizând stereotipuri.




�Modelul datelor



reprezentarea DESCOMPUNERII MODULARE




�Modelul datelor



reprezentarea descompunerii modulare ºi a DEPENDENÞELOR între MODULE




�Modelul datelor



Exemplu de rafinare pachet (2 nivele de rafinare)




�Modelul datelor


UML ��SHUVSHFWLYD�GLQDPLFă�C&C viewtype

Tipuri de elemente : -�FRPSRQHQWă = de execuþie (proces, fir de execuþie, EJB, servlet, DLL, obiect,...) sau de date.- conector� ��coadã de aºteptare, conductã, RMI,...).

Tipuri de relaþii :Diverse mecanisme de interacþiune�Apel procedurã (local, remote)�Comunicare(sincronã, asincronã)

REPREZENTARE folosind UML:�Diagrama de componente

�Componentã

�Port (poate avea instanþe multiple)

�Interfeþe (provided ºi required)

�Conectori de asamblare

�Conectori de delegare




�Modelul datelor


Notaþii pentru interfeþe




�Modelul datelor


Notaþii pentru conectori

Limitare:

Conectorii UML nu au structurã internã, atribute sau descriere comportament.

În realitate, conectorii pot fi structuri complexe.

Alternative de reprezentare conector în UML:

componentã UML sau clasã de asociere.

element UML stereotipat cu <<tip conector>>, cu valori etichetate (tagged values) ºi alte adnotãri.




�Modelul datelor

Pentru detalii vezi raportul tehnic C&C_cu_UML.pdf


UML ��SHUVSHFWLYD�DORFăULLallocation viewtype

Tipuri de elemente : - nod = de execuþie ºi de comunicare (maºinã

server, router,...).- Artefact software = fiºier, director.

Tipuri de relaþii :- Canal de comunicare- �conþinut în�

REPREZENTARE folosind UML:�Diagrama de repartizare

Nod - dispozitiv

Nod � mediu de execuþie

Artefact software




�Modelul datelor


UML � modelul datelor

Tip de element : - entitate = element persistent

Tipuri de relaþii :- Asociere (1:1, 1:n, n:n)- Generalizare/specializare- Agregare

REPREZENTARE folosind UML:�Diagrama de clase




�Modelul datelor


UML � reprezentare comportament

Arhitectura software se ocupã în mod esenþial cu structurile�VLVWHPHORU�software.

Diagramele structurale ilustreazã toate interacþiunile potenþiale între elementele software ºi cu contextul.

Descrierea structurilor sistemului software trebuie complementatã prin diagrame

de comportament. Acestea ilustreazã ºabloane specifice de interacþiune�prin care sistemul rãspunde la stimuli.

Variante de REPREZENTARE folosind UML:�Diagrama secvenþe�Diagrama de comunicare�Diagrama de activitate�Diagrama de timp�Diagrama de stãri


UML - Combinarea vederilor multipleExemplu

Mapare între 2 vederi: allocation view ºi module view.



Curs 11



PLAN CURS

Concepte generale în evaluarea arhitecturilor software

SAAM (Software Architecture Analysis Method)

ATAM (Architecture Tradeoff Analysis Method)

ACDM (Architecture Centric Design Method)


Practica curentã

Analiza ºi evaluarea arhitecturilor software este în curs de maturizare.

Au început sã aparã câteva metode industriale de evaluare puternice

� SAAM, ATAM, ALMA, FAAM, ...

SEI (Software Engineering Institute) � cercetare de pionierat ºi vastã în domeniul evaluãrii arhitecturilor software.


Motivaþii pentru analizarea arhitecturilor software

Toate proiectele implicã compromisuri.

Arhitectura software este artefactul cel mai timpuriu din ciclul de dezvoltare de software, ºi cuprinde decizii de proiectare semnificative.

Timpul, costul ºi consecinþele defectãrilor asociate cu sistemele mari ºi complexe intensiv software justificã costurile evaluãrii arhitecturii software.

CONCLUZIE:

Evaluarea arhitecturii software este un mod eficient de a descoperi consecinþele deciziilor arhitecturale

� înainte de proiectarea de detaliu ºi de implementare,�VDX� dacã actualizarea sistemului angajeazã resurse majore.


Metode pentru evaluarea arhitecturilor software




dezvoltate la SEI (Software Engineering Institute)

Altele:

Specifice unui domeniu

De interes industrial restrâns

Mai puþin codificate


PLAN CURS







SAAM dezvoltatã la SEI

Una din primele metode de evaluare a arhitecturilor software

Predecesor al ATAM

Metodã de evaluare a arhitecturilor în scopul asigurãrii îndeplinirii cerinþelor pentru atribute de calitate la sistemele intensiv software.

Cuprinde 6 paºi.


SAAM - procedura

Pas 1 � Dezvoltarea de scenarii pentru atribute de calitate via brainstorming.

Pas 2 � Descrierea arhitecturii/arhitecturilor candidat.

Pas 3 � Clasificarea scenariilor în directe sau indirecte.

Pas 4 � Evaluarea scenariilor.

Pas 5 � Evaluarea interacþiunilor dintre scenarii.

Pas 6 � Evaluarea de ansamblu.

Scenariu direct � poate fi îndeplinit fãrã nici o modificare la sistem.Scenariu indirect � poate fi îndeplinit prin modificarea sistemului.

Arhitectul:�demonstreazã executarea scenariului direct,�descrie modul în care arhitectura ar trebui schimbatã pentru a îndeplini scenariul indirect.

�Douã scenarii indirecte interacþioneazã

dacã necesitã modificãri la acelaºi element al sistemului. �Zone cu interacþiuni semnificativeîntre scenarii pot revela o potenþialã

slabã separare a problemelor.�Ataºare ponderi la fiecare scenariu ºi interacþiune între scenarii, funcþie de importanþã.�Dacã arhitectura satisface scenariul, primeºte valoarea ponderatã corespunzãtor.


SAAM - probleme

Codificare slabã

Pot exista diferenþe de aplicare de la evaluator la evaluator.

Rezultatele sunt deseori impredictibile.

Durata de realizare a evaluãrilor variazã.

La momentul creãrii SAAM, maturitatea disciplinei �arhitecturi software��HUD�relativ scãzutã � puþine informaþii referitoare la:

� Atributele de calitate ºi relaþia acestora cu structura

� Scenarii pentru atribute de calitate

� Tactici

� Documentarea arhitecturilor, ...

Lipsã modele, instrumente sau instruire pentru evaluatori.

SAAM -�FHQWUDWă�SH�

� funcþionalitate relativ la scenariile directe

� diferite feluri de modificabilitate (scalabilitate, portabilitate, ...) relativ la scenariile indirecte.


PLAN CURS







Obiectiv � evaluarea consecinþelor deciziilor arhitecturale în raport cucerinþele pentru atribute de calitate ºi obiectivele business.

Metodã bazatã pe scenarii:

Se pleacã de la premiza cã organizaþia nu a identificat sau codificat în mod explicit cerinþele pentru atribute de calitate.

Scenariile sunt dezvoltate de stakeholder-i ºi utilizate pentru analizarea arhitecturii în vederea descoperirii de riscuri.

Riscurile descoperite pe parcursul evaluãrii ATAM pot deveni apoi þinta activitãþilor de diminuare, cum ar fi analizã ºi proiectare ulterioare, prototipare, cercetare,�HWF.

Compromisurile apãrute, non-riscurile ºi punctele sensibile pot fi identificate explicit ºi documentate.


ATAM

NU

Fixarea, prioritizarea sau determinarea impactului riscurilor (activitate ulterioarã

ATAM).

Oferã analize precise ºi formale.

DA

Descoperã tendinþe generale � corelaþii între deciziile arhitecturale ºi proprietãþile sistemului.

Descoperã orice risc, punct sensibil, compromis ºi non-risc, create de deciziile arhitecturale.


ATAM - utilizare

Pe parcursul ciclului de dezvoltare de software, dacã existã o arhitecturã

de evaluat.

Dupã ce arhitectura a fost specificatã dar existã cod puþin sau deloc.

Pentru evaluarea alternativelor arhitecturale.

Pentru evaluarea arhitecturii unui sistem existent.

Arhitecturã de evaluat = reprezentãri arhitecturale ale unui sistem existent sau a

unuia ce urmeazã a fi dezvoltat.


ATAM - procedura

Faza 0:Partneriat

ºiPregãtire

Faza 1:Evaluare iniþialã

Faza 2:Evaluare completã

Faza 3:Urmarire

Durata: variazãComunicare: telefon, email

Durata: 1.5 - 2 zile pentru fiecare fazã.Comunicare: ºedinþã condusã în mod tipic la sediul clientului.

Durata: variazãComunicare: telefon, email.


ATAM � Faza 0

Precede partea tehnicã a evaluãrii.

Clientul ºi o parte din echipa de evaluare fac schimb de pãreri referitoare la metodã ºi la sistemul a cãrui arhitecturã trebuie evaluatã.

Conducãtorul evaluãrii va lua decizia de a realiza sau nu evaluarea.

Dacã decizia este pozitivã, atunci este elaborat un agreement de realizare a evaluãrii.

Se creazã nucleul echipei de evaluare.

Echipa de evaluare citeºte documentaþia arhitecturalã oferitã.

Se prezintã evaluatorilor determinanþii business ºi arhitectura.

Sunt identificaþi stakeholder-ii corespunzãtori, iar aceºtia sunt deciºi sã

participe la evaluarea ATAM. Echipa de evaluare primeºte lista participanþilor cu rolurile acestora în raport cu sistemul.


ATAM � Faza 0

Decizia de realizare a evaluãrii

Condiþii: Evaluatorii trebuie sã înþeleagã suficient de bine starea arhitecturii pentru a se lua o

decizie ºi a se putea asigura cã sistemul candidat este pregãtit pentru evaluare.

Dacã se ia o decizie negativã, atunci trebuie explicate clienþilor motivele acesteia ºi sugerate operaþii de remediere, sau trebuie lucrat împreunã cu clienþii la dezvoltarea arhitecturii.

Consideraþii cheie: A fost identificat un arhitect responsabil ºi acesta este decis sã participe la

evaluarea ATAM.

A fost identificat un manager business, manager de program ºi/sau sponsorul sistemului, ºi acesta este decis sã participe la evaluarea ATAM.

Echipa de evaluare a primit documentaþie arhitecturalã suficientã pentru a proceda

la evaluarea ATAM.

� Existã o reprezentare a contextului ºi mai multe reprezentãri ale sistemului (module, C&C, alocare)

� Existã suficient text descriptiv.


ATAM � echipa de evaluare

4 � 6 persoane

Roluri:

� Conducãtor

� Moderator ��IDFLOLWHD]ă�GLVFXþii, brainstorming ºi analizã

� Secretar ��FRPSOHWHD]ă�IRUPXODUXO�HOHFWURQLF�$7$0�FX�DUERUHOH�XWLOLWDU�DO�atributelor de calitate, scenarii brute, riscuri, sensibilitãþi ºi compromisuri.

� Observator proces ��PRQLWRUL]HD]ă�HWDSHOH�SURFHVXOXL de evaluare, ia notiþe despre acesta ºi despre modul în care ar putea fi îmbunãtãþit.

� Organizator timp ��LQGLFă�PRGHUDWRUXOXL�PRPHQWXO�H[SLUăULL�WLPSXOXL�DORFDW�pentru o etapã.

� Specialist(i) ��ULGLFă�SUREOHPH�OD�FDUH�QX�V-au gândit stakeholder-ii; pune întrebãri bazate pe modul în care atributele de calitate de interes sunt corelate cu stilurile arhitecturale.


ATAM � Paºii procesului

1. Prezentarea metodei ATAM

2. Prezentarea determinãrilor business

3. Prezentarea arhitecturii

4. Identificarea abordãrilor arhitecturale

5. Generarea arborelui utilitar al atributelor de calitate

6. Analiza abordãrilor arhitecturale

7. Brainstorm ºi prioritizare scenarii


9. Prezentarea rezultatelor

10. Producerea unui raport final pentru client

11. Evaluarea calitãþii procesului de evaluare ºi a materialelor ATAM.

Faza 1

Faza 2

Faza 3


ATAM � Faza 1

Implicã un grup restrâns de stakeholder-i, orientaþi predominant pe partea tehnicã.

Faza 1 este:

Centratã pe arhitecturã

Concentratã pe obþinerea informaþiilor arhitecturale detaliate ºi pe analiza acestora.

Analizã în manierã descendentã (top-down).


ATAM � Faza 1

Pasul 1: Prezentarea ATAM - echipa de evaluare:

Motivele evaluãrii arhitecturilor software

Paºii, pe scurt Tehnicile Ieºirile produse de metodã

Pasul 2: Prezentarea determinanþilor business - un reprezentant al clientului ATAM

Contextul business al sistemului

Cerinþele funcþionale de nivel înalt

Cerinþele de nivel înalt pentru atributele de calitate� Determinãrile arhitecturale � atributele de calitate care dau forma arhitecturii

� Cerinþele critice � cerinþele de calitate care sunt esenþiale pentru succesul sistemului

Evaluatorii trebuie sã ASCULTE CU ATENÞIE: Atributele de calitate sunt derivate din obiectivele business.

Exemple: Sistemul trebuie sã fie disponibil 24/7 disponibilitate.

Datele utilizator nu vor fi compromise în nici o situaþie securitate.


ATAM � Faza 1

Pasul 3: Prezentarea arhitecturii - arhitectul

Constrângerile tehnice (sistem de operare, hardware, middleware)

Alte sisteme cu care sistemul trebuie sã interacþioneze

Abordãrile arhitecturale utilizate pentru a rãspunde la cerinþele pentru atribute de calitate.

Pasul 4: Identificarea abordãrilor arhitecturale � echipa de evaluare

Distilarea atributelor de calitate ºi asocierea lor cu determinanþii business.

Distilarea determinanþilor arhitecturii (funcþii, calitãþi, constrângeri).

Identificarea abordãrilor arhitecturale predominante ºi motivele pentru care au fost selectate de arhitect.

Identificarea tacticilor, ºabloanelor ºi altor mecanisme, în cadrul arhitecturii, care sunt cheie în realizarea atributelor de calitate urmãrite.


ATAM � Faza 1

Pasul 5: Generarea arborelui utilitar al atributelor de calitate � echipa de evaluare

ATAM pleacã de la ipoteza cã atributele de calitate nu au fost identificate formal de cãtre client

Atributele de calitate sunt identificate, prioritizate ºi rafinate prin construirea unui arbore utilitar:

Arbore utilitar �� Obiectivele de calitate cele mai importante sunt plasate în nodurile de nivel înalt (în mod

tipic performanþa, modificabilitatea, securitatea ºi disponibilitatea)

� Scenariile sunt plasate în nodurile terminale.

� Conþine 3 pãrþi majore


ATAM � Faza 1


Realizat pe bazã de SCENARII

Utilitate scenarii:

Reprezentarea intereselor stakeholder-ilor

Înþelegerea cerinþelor pentru atributele de calitate

Acoperire scenarii:

Utilizãri anticipate ale sistemului

Modificãri anticipate ale sistemului

Presiuni neanticipate asupra sistemului

Acceptare scenarii:

Precizeazã clar stimulul ºi rãspunsurile de interes

Este foarte specific


ATAM � Faza 1


SCENARII: stimuli � context - rãspunsuri

Exemple:

Scenariu de utilizare:

Utilizatorul remote solicitã un raport din baza de date via Web pe timpul perioadei de vârf

ºi îl obþine în 5 secunde.

Scenariu de extindere:

Adãugarea unui nou server de date pentru a reduce latenþa din scenariul 1 la 2,5 secunde cu un efort de o persoanã timp de o sãptãmânã.

Scenariu exploratoriu:

Jumãtate dintre servere se defecteazã în timpul operãrii normale fãrã a afecta

disponibilitatea gobalã a sistemului.


ATAM � Faza 1

Pasul 6: Analiza abordãrilor arhitecturale

Scenariul brut este expandat într-un scenariu format din 6 pãrþi: sursã, stimul, context, artefact, rãspuns, mãsurã pentru�UăVSXQV.

Arhitectului i se pun întrebãri de forma:

�Fiind dat <stimul>, din sursa <sursã>, afectând <artefact>, în condiþiile definite de <context>, arãtaþi cum arhitectura rãspunde în cadrul <mãsurii�SHQWUX�rãspuns>�LQGLFDWă�în scenariu.�


ATAM � Faza 1

ªablon pentru analiza ATAM


ATAM � Faza 1


Arhitectul utilizeazã reprezentãrile arhitecturale pentru a parcurge scenariul ºi a descrie modul în care arhitectura rãspunde la stimul.

Evaluatorii ATAM ºi stakeholder-ii pot pune întrebãri, utile pentru a descoperi:

Riscurile

Non-riscurile

Punctele sensibile

Compromisurile

Risc ��GHFL]LH�DUKLWHFWXUDOă�FX�SRWHQþial problematic.

Non-risc ��GHFL]LH�DUKLWHFWXUDOă�EXQă.

Punct sensibil � proprietate a uneia sau mai multor componente (ºi/sau relaþii între componente),�FULWLFă�SHQWUX�REþinerea unui anumit atribut de calitate.

Compromis ��SURSULHWDWH�FH�DIHFWHD]ă�PDL�PXOWH�DWULEXWH�ºi este punct sensibil pentru mai multe atribute.


ATAM � Faza 1

Pasul 6: Analiza abordãrilor arhitecturale - exemple

Risc ��GHFL]LH�DUKLWHFWXUDOă�cu potenþial problematic.

Compromis ��SURSULHWDWH�FH�afecteazã mai multe atribute ºi este punct sensibil pentru mai multe atribute.

Punct sensibil � proprietate a uneia sau mai multor componente (ºi/sau relaþii între componenente),�criticã pentru obþinerea unui anumit atribut de calitate.

Non-risc ��GHFL]LH�DUKLWHFWXUDOă�EXQă.

�Regulile de scriere a modulelor logicii business din treapta a 2-a a arhitecturii în 3 trepte nu sunt clar articulate. Aceasta ar putea rezulta în replicare de funcþionalitate, compromiþând astfel

modificabilitatea treptei a 3-a.�

�Schimbarea nivelului de criptare poate avea un impact semnificativ atât asupra securitãþii cât ºi asupra performanþei.�

�Valoarea medie a efortului de întreþinere al unui sistem, mãsuratã în numãr de zile-om, poate fi sensibilã la gradul

de încapsulare al protocoalelor de comunicare ºi al formatelor fiºierelor.�

�În ipoteza cã rata de sosire a mesajelor este de 1 mesaj pe secundã, cã timpul de

procesare mesaj este mai mic de 30ms ºi cã existã un proces cu prioritate mai

mare, un termen limitã soft de o secundã pare rezonabil.�


ATAM � Faza 2

Faza 2 � caracteristici: Implicã un grup mai mare de stakeholder-i.

Concentratã pe obþinerea punctelor de vedere ale diferiþilor stakeholder-i ºi pe verificarea rezultatelor fazei 1.

Centratã pe stakeholder.

Analizã ascendentã (bottom-up).

Activitãþi ale echipei de evaluare în perioada dintre faza 1 ºi faza 2:

Consolidarea notiþelor, arborelui utilitar, riscurilor, non-riscurilor, punctelor de sensibilitate ºi compromisurilor.

Construirea unei reprezentãri pentru faza 2 care recapituleazã rezultatele fazei 1.

Stabilire de teme de risc potenþial.

Începerea creãrii prezentãrii finale ºi scrierii raportului final.

Planificarea logisticii pentru faza 2.


ATAM

Stabilire temã de risc potenþial - exemplu

Risc: �Nu au fost stabilite bugete pentru sincronizarea activitãþilor lucrative � dificil de prezis timpul de rãspuns�

Risc: �Modificãri minore la

sincronizãrile unor activitãþilucrative�DX�LPSDFW�impredictibil asupra altor activitãþi�

Risc: �Cerinþele de memorie pentru sistem nu pot fi prezise pânã ce nu sunt

integrate toate activitãþile.�

Risc: �Alocarea resurselor sistemului nu este parte a arhitecturii, iar resursele necesare nu pot fi estimate sau bugetate�

Temã de risc: �Nu existã o abordare holisticã la managementul resurselor��

Impact asupra: �Cost, timp de lansare pe piaþã, abilitatea de a concura cu competitorii�

Risc: �Nu existã o abordare

disciplinatã a activitãþilor de planificare � planul este realizat din mers�


ATAM � Faza 2

Paºii

1. Prezentarea ATAM

2. Prezentarea determinãrilor business

3. Prezentarea arhitecturii

4. Identificarea abordãrilor arhitecturale

5. Generarea arborelui utilitar al atributelor de calitate


7. Brainstorm ºi prioritizare scenarii


9. Prezentarea rezultatelor


ATAM � Faza 2

Pasul 7: Brainstorm ºi prioritizare scenarii

Grupul de stakeholder-i este mai mare ºi mai divers decât în faza 1.

Stakeholder-ii genereazã scenarii în cadrul unui proces de brainstorming cu moderator.

Scenariile din nodurile terminale ale arborelui utilitar sunt folosite ca exemple

Fiecare stakeholder are alocat un numãr de voturi egal cu 30% din numãrul scenariilor generate.

Prioritatea scenariilor se stabileºte prin vot.


ATAM � Faza 2


Se continuã analiza de la pasul 6, cu grupul extins de stakeholder-i ºi utilizând noile scenarii:

� Se identificã noi riscuri ºi non-riscuri.

� Se adnoteazã informaþii arhitecturale suplimentare pe mãsurã ce sunt

descoperite.

La terminare echipa va solicita o pauzã de aprox. 2 ore, timp în care se va completa prezentarea finalã.


ATAM � Faza 2

Pasul 9: Prezentarea rezultatelor

Conducãtorul echipei de evaluare face, în mod tipic,�SUH]HQWDUHD�ILQDOă.

Prezentarea se va concentra pe informaþiile de nivel înalt :

Procesul ATAM, durata, participanþii,

Prezentare generalã a obiectivelor business,

Prezentare generalã a arhitecturii sistemului,

Arborele utilitar al atributelor de calitate,

Rezumatul analizelor realizate,

Rezumat al riscurilor, punctelor sensibile, non-riscurilor ºi compromisurilor,

Temele de risc.


ATAM � Fluxul conceptual

Decizii arhitecturale

ScenariiAtribute

de calitate

Abordãri

arhitecturale

Determinãrile

business


impact

Teme de risc

distilateîn

Analiza

Riscuri

Puncte sensibile

Compromisuri

Non-riscuri


ATAM - probleme

Procedurã disruptivã ��QHFHVLWă�întrerupere, pregãtire, evaluare ºi corectare.

Potrivitã în special pentru procese software mari, de tip waterfall, cu bugete mari.

Evaluare greoaie ºi costisitoare reticenþã în aplicarea ei la proiecte ºi organizaþii mici.

Calitatea analizei ATAM (paºii 6 ºi 8) depinde de antrenamentul, intuiþia ºi experienþa evaluatorilor.

Nu existã instrumente suport.

Nu se precizeazã ce se poate face cu cu rezultatul evaluãrii ºi nu existã

un proces formal pentru utilizarea acestuia.

Adaptarea, utilizarea ºi practicarea curentã a ATAM în cadrul unei firme necesitã o infrastructurã semnificativã.


PLAN CURS






Evaluare continuã

Alternativã la o procedurã disruptivã.

Posibila împletire a arhitecturii în ciclul de producþie ºi de mentenanþã.

Utilizarea arhitecturii ca o ancorã a întregului proiect, pentru dezvoltarea de planuri, pentru diminuarea riscurilor, pentru alinierea forþei de muncã, etc.

Metoda ��$&'0�(Architecture Centric Design Method)

- Evaluare continuã a arhitecturii.

- Rafinare incrementalã a arhitecturii.



etapa 1 Stabilirea determinaþilor arhitecturali

etapa 2 Determinarea ºi stabilirea domeniului proiectului

etapa 3 Creare/rafinare proiect arhitectural

etapa 4 Evaluare proiect arhitectural

etapa 5 DECIZIA

Stage 8 Producþia

Per

ioad

a de

ince

rtitu

dine

Per

ioad

a de

ce

rtitu

dine

etapa 6 Planificare/conducere experimente

NU

Stage 7 Planificarea producþiei

DA



Avantaje

Adreseazã proiectul arhitectural într-o manierã detaliatã.

Implicã proiectarea iterativã a arhitecturii.

Evaluarea iterativã ºi experimentarea constituie o modalitate extrem de eficientã pentru a adresa ºi diminua riscurile de naturã tehnicã într-un mod structurat.

Rolurile definite în ACDM sunt utile pentru formarea iniþialã de echipe a.î. fiecare membru îºi înþelege responsabilitãþile.

Ghidul, tabelele, modelele ºi listele de verificare oferite de ACDM sunt deosebit de utile.



Zone ce pot fi îmbunãtãþite:

Necesitã un antrenament semnificativ pe tematica arhitecturilor software pentru a înþelege eficient, a aprecia ºi a utiliza tehnicile cuprinse în metodã.

Îmbunãtãþire prin:

� Ghidare suplimentarã referitoare la modul de proiectare ºi de evaluare a arhitecturilor software,

� Ghidare suplimentarã referitoare la utilizarea arhitecturii pentru activitãþi de întreþinere ºi extindere a sistemului,

� Ghidare ºi instrumente pentru documentarea arhitecturilor,

� Tehnici de recuperare a proiectelor arhitecturale pierdute (reconstrucþia arhitecturii),

� Tehnici pentru mãsurarea conformanþei cu proiectul arhitectural.

Sunt necesare adaptãri, pentru împletirea ACDM cu procesul global de dezvoltare de software.



Lattanze, A., 2008. Architecting Software Intensive Systems: A Practitioners Guide, AuerbachPublishing, New York, NY.

Abecedar al arhitecturilor software.

Ghid de proiectare arhitecturalã ºi de utilizare a ACDM.

Ghid de utilizare ACDM împreunã cu alte cadre (frameworks) pentru procesul de dezvoltare de software.

etapa 1 etapa 2 etapa 3 etapa 4 etapa 5 etapa 6 etapa 7 etapa 8

Metodã de

obþinere, de la

stakeholder-i,

a determinaþilor

arhitecturii.

Metode pentru

organizarea ºi

documentarea

determinaþilor

arhitecturii.

Modele de

planificare

pentru

perioada de

incertitudine.

Ghid de

proiectare ºi

documentare a

arhitecturii

teoretice.

Modele pentru

proiectare,

înregistrare

element ºi

responsabilitãþi

de relaþionare;

modele pentru

înregistrare

motivaþii.

Metodã pentru

revizuirea

proiectului

arhitectural.

Liste de

verificare

pentru

recenzori.

Modele pentru

înregistrare

probleme.

Ghid pentru

clasificarea ºi

analizarea

problemelor ºi

pentru luarea

deciziei de

realizare sau nu

a sistemului.

Modele pentru

planificarea

experimentelor.

Liste de

verificare ºi

modele pentru

actualizarea

planurilor din

perioada de

incertitudine.

Modele, liste de

verificare ºi

metodã pentru

estimarea ºi

planificarea

producþiei.

Modele ºi liste

de verificare

pentru

urmãrire ºi

supraveghere

a producþiei

utilizînd

arhitectura ºi

planurile de

producþie.



Curs 10



Observaþii preliminare

1. Cerinþele pentru atributele de calitate sunt elementele fundamentale de dirijare a proiectãrii unei arhitecturi software.

Dovada 1:�GDFă�DU�IL�LPSRUWDQWă�GRDU�IXQFþionalitatea, ar fi suficient doar un sistem monolitic.

DAR existã:

Structuri redundante - pentru fiabilitate

Structuri concurente - pentru performanþã

Straturi (layers) - pentru modificabilitate

Dovada 2: restructurarea unui sistem se face de obicei din motive de calitate: îmbunãtãþire performanþã, securitate, modificabilitate, ...

2. Pentru multe atribute de calitate existã o istorie îndelungatã ºi o bazã

bogatã de cunoºtinþe cadre (framework) valoroase utilizate la analizarea arhitecturilor.

Ex. Performanþã � teoria cozilor de aºteptare, teoria�SODQLILFăULLFiabilitate � modele Markov


PLAN CURS

Principii de proiectare pentru atribute de calitate

Scenarii generale

Tactici

ADD (Attribute Driven Design)

Exemplu de aplicare ADD

Proiectare arhitecturã pentru SECURITATE

Arhitectura securitãþii

Principii ale ingineriei securitãþii

Ciclul de dezvoltare a arhitecturii securitãþii


Problema

Obiectiv: Trecerea sistematicã de la un set de cerinþe la o arhitecturã

software care le satisface.

Cunoºtinþe necesare:

De domeniu


Proiectare arhitecturalã

Metodologie de proiectare

...

Obiectiv general: proiectarea metodicã de arhitecturi software a.î. sã

îndeplineascã atribute de calitate în mod predictibil.


Exprimare cerinþe

Elementele de dirijare a proiectãrii arhitecturale:

Constrângeri � decizii de proiectare pre-definite.

Caracteristici � funcþii ce adaugã valoare pentru utilizator.

Atribute de calitate.

Cerinþele funcþionale � importanþã minorã

Atributele de calitate ºi constrângerile � importanþã majorã

Abordarea metodologicã a proiectãrii propusã:

Determinarea precisã a atributelor de calitate în termeni de scenarii

Exploatarea �structurii� modelelor pentru atributele de calitate, pentru definirea structurii arhitecturilor bine formate.


Exprimare cerinþe

Model pentru specificarea atributelor de calitate:

Utilizarea de scenarii generale pentru atributele de calitate, independente de sistem, ca ghid pentru specificarea cerinþelor pentru atributele de calitate.

Caracterizarea cerinþelor pentru atributele de calitate ale unui anume sistem printr-o colecþie de scenarii concrete pentru atributele de calitate. Acestea sunt instanþe ale scenariilor generale.

Pãrþile componente ale unui scenariu: Stimul Sursã stimul

Contextul în care apare stimulul Artefactul influenþat de stimul Rãspunsul sistemului la stimul

Mãsurile rãspunsului


Scenarii generale � exempleScenariu pentru disponibilitate

Tabela de generare scenarii pentru disponibilitate:

Sursã stimul:

� Internã sistemului

� Externã sistemului

Context:

� Operare normalã

� Mod degradat

Rãspuns:

� Înregistrare

� Notificare parteneri

� Operare în mod normal sau degradat

Stimul:

� Eveniment neanticipat

� Actualizare la o sursã de date

Artefact:

� Proces

� Memorie persistentã

Mãsuri rãspuns:

� Procentaj de disponibilitate

� Interval de timp în care sistemul poate funcþiona în mod degradat

Exemplu de Scenariu:�Un mesaj neanticipat este recepþionat de un proces al sistemului în timpul funcþionãrii

normale. Procesul trebuie sã-l înregistreze, sã informeze partenerii corespunzãtori ºi sã continue funcþionarea în mod normal,�IăUă�întreruperi.�


Scenarii generale � exempleScenariu pentru performanþã

Tabela de generare scenarii pentru performanþã:

Sursã stimul:

� Eveniment declanºat de sistem

� Eveniment extern

Context:

� Condiþii normale

� Condiþii critice (ex. supraîncãrcare)

Rãspuns:

� Procesare stimul

� Modificarea nivelului serviciului

Stimul:

� Periodic

� Stocastic

� Sporadic

Artefact:

� Sistem

Mãsuri rãspuns:

� Latenþã

� Termen limitã

� Ratã de transfer

� etc

Exemplu de scenariu:�Un eveniment extern sporadic este recepþionat de sistem în condiþii de funcþionare normalã.�6LVWHPXO�WUHEXLH�Vă�SURFHVH]H�VWLPXOXO�într-un termen limitã specificat.�


Scenarii generale � exempleScenariu pentru modificabilitate

Tabela de generare scenarii pentru modificabilitate:Sursã stimul:

� Utilizator final

� Administrator

� Dezvoltator

� Sistem

Context:

� La execuþie

� La compilare

� La construire (build)

� La proiectare

Rãspuns:

� Identificarea locurilor modificãrilor

� Realizare modificare fãrã afectarea celorlalte funcþii

� Testare modificare

� Repartizare (deploy) modificare

Stimul:

� Adãugare / ºtergere / variaþie

funcþionalitate, calitate, capacitate

Artefact:

� Sistem

� Interfaþã utilizator

� Context

� Platformã

� Produs COTS

Mãsuri rãspuns:

� Dificultate în termeni de timp ºi / sau cost


Scenarii generale � exempleScenariu pentru securitate

Tabela de generare scenarii pentru securitate:

Sursã stimul:

� Individ sau sistem

� Identificat corect

� Anonim

� Identificat incorect

Context:

� În timp ce utilizatorul foloseºte sistemul

� Din afara sistemului

Rãspuns:

� Autentificare utilizator

� Ascunde identificarea utilizatorului

� Permite / blocheazã accesul la date / servicii (inclusiv drepturi)

� Înregistrare modificãri / acces pe baza identitãþii

� Memorare informaþii într-un format ce nu poate fi citit

Stimul:� Încercare de

� Afiºare informaþii� Utilizarea unui serviciu al sistemului� Modificare / ºtergere informaþii� Reducerea disponibilitãþii resurselor sistemului

Artefact:� Sistem� Date din sistem

Mãsuri rãspuns:� Nivel / timp / resurse de competenþã necesare

eludãrii cu probabilitate de succes a

mecanismelor de securitate � ...


Scenarii generale � exempleScenariu pentru utilizabilitate

Tabela de generare scenarii pentru utilizabilitate:

Sursã stimul:

� Utilizator final

Context:

� La execuþie

� La configurare

Rãspuns:

� Sistem de help

� Interfaþã familiarã

� Agregare dete / comenzi

� Reutilizare de informaþii

� Undo

� Cancel

� Personalizare

� Internaþionalizare

� ...

Stimul:

� Caracteristicile de instruire ale sistemului

� Utilizarea eficientã a sistemului

� Minimizarea impactului erorilor

� Adaptarea sistemului la nevoile utilizatorului

� Utilizarea confortabilã a sistemului

Artefact:

� Sistem

Mãsuri rãspuns:

� Timp de realizare sarcini

� Numãrul de erori

� ...


PLAN CURS


Scenarii generale

Tactici








Tactici arhitecturale

Tacticã arhitecturalã = mijloc de satisfacere a unei mãsuri pentru un atribut de calitate, prin manipularea unui aspect al unui model pentru atributul de calitate prin decizii de proiectare arhitecturalã.

Aplicare tacticã arhitecturalã :

face trecerea de la o arhitecturã la alta

un parametru al modelului�DWULEXWXOXL�GH�FDOLWDWH�YDULD]ă�într-o anumitã direcþie.


Tactici arhitecturale � exemple

Tactici pentru performanþã

Performanþã

Gestionare solicitare

�Creºterea eficienþei calculelor

�Reducerea overhead-lui de calcul

�Gestionarea ratei de apariþie a evenimentului

�Controlul frecvenþei de eºantionare

�Limitarea timpilor de execuþie

Arbitrare solicitare

� Introducerea concurenþei

�Determinarea politicii de planificare

�Utilizare protocoale de sincronizare

Gestionare resurse multiple

�Creºterea concurenþei fizice

�Echilibrarea alocãrii

resurselor

�Creºterea localitãþii datelor



Tactici pentru modificabilitate

Modificabilitate

Localizare modificãri

�Coerenþã semanticã

�Anticiparea schimbãrilor

�Generalizare modul

�Limitarea opþiunilor posibile

�Servicii comune abstracte

Prevenirea efectului de propagare

�Ascundere informaþii

�Pãstrarea interfeþelor existente

�Restricþionarea cãilor de

comunicare

�Utilizarea unui intermediar

Amânarea stabilirii

de legãturi

� Înregistrare la momentul execuþiei

�Fiºiere de configurare

�Polimorfism

�Componente înlocuibile

�Aderare la protocoale



Tactici pentru disponibilitate

Disponibilitate

Detecþie defecte

Recuperare -�pregãtire ºi

reparare

Recuperare �reintroducere

Prevenire

�Ping/Echo

�Heartbeat (PULS)

�Excepþii

�Votare

�Redundanþã activã

�Redundanþã pasivã

�Rezerve

�Shadow

�Resincronizare stãri

�Rollback

� Îndepãrtare de

la serviciu

�Tranzacþii

�Monitorizare proces



Scenarii generale

Tactici







PLAN CURS


ADD � Attribute Driven Design

ADD � metodã�GH�SURLHFWDUH�DUKLWHFWXUDOă�în care procesul este condus de

cerințele pentru atributele de calitate.

Definitã ca proces recursiv de descompunere a unui (sub)sistem aplicând

tactici arhitecturale și șabloane care satisfac cerințele principale pentru

atribute de calitate.

Bibliografie la www.sei.cmu.edu

Wojcic R., Bachmann F., Bass L., Clements P., Merson P., Nord R., Wood B., Attribute Driven Design (ADD) Version 2.0, Technical Report CMU/SEI-2006-TR-023, nov 2006

http://www.sei.cmu.edu


ADD � Attribute Driven Design

Pas 1: Stabilirea suficienței specificațiilor pentru cerințe

� cerințele funcționale

� constrângerile de proiectare

� scenariile pentru atributele de calitate

Pas 2: Alegerea elementului ce va fi descompus

- inițial � întregul sistem; ulterior � subsistemele identificate în trecerile anterioare

Pas 3: Identificarea cerințelor candidat care dirijeazã arhitectura

Pas 4: Alegerea unui concept de proiectare ce satisface cerințele care dirijeazã

arhitectura: se iau decizii arhitecturale.

��/LVWDUHD�PDMRULWăþii alternativelor de proiectare

� Selectarea ºabloanelor preferate

� Evaluarea pentru validarea proiectului arhitectural

��5HDOL]DUHD�GH�PRGLILFăUL�SHQWUX�FRUHFWDUHD�GHILFLHQþelor detectate.

Pas 5: Instanțierea elementelor arhitecturii și alocarea de responsabilitãți

Pas 6: Definirea interfețelor pentru elementele instanțiate

Pas 7: Verificarea și rafinarea cerințelor și transformarea lor în constrângeri pentru

elementele instanțiate.

bine definite și prioritizate



Scenarii generale

Tactici







PLAN CURS


ADD � Exemplu

Aplicarea ADD�SHQWUX�SURLHFWDUHD�XQXL�VXEVLVWHP�FH�RIHUă�VHUYLFLL�GH�toleranțã la defecte, identificat într-o primã etapã de aplicare a metodei pentru proiectarea unui sistem de urmãrire.

Detalii la www.sei.cmu.edu

Wood W.G., A Practical Example of Applyng Attribute-Driven Design (ADD) Version 2.0, Technical Report CMU/SEI-2007-TR-005, febr 2007

Sistem urmãrireSistem

Interogare stare / rãspuns

Actualizare stare

Actor interogare

Actor actualizare



ADD cerinþe funcþionale

R1. Actor actualizare ��WULPLWH�OD�LQWHUYDO�GH�1 sec. actualizãri la serviciul urmãrire;

Serviciul poate tolera pierderi ocazionale de date, în special în condiþii tranzitorii cauzate de defectarea echipamentului: serviciul se poate redresa�GXSă�UDWDUHD�D�2 actualizãri atunci când o primeºte pe a 3-a; dacã se pierd mai mult de 3 actualizãri consecutive, operatorul trebuie sã asiste serviciul în procesul de redresare pentru a evita intervenþia operatorului, procesarea trebuie sã

reînceapã în mai puþin de 2 sec. dupã o cãdere.

R2. Actor interogare � trimite sporadic cereri de interogare date ºi trebuie sã primeascã

exact un rãspuns la fiecare interogare.

Categorii actori�LQWHURJDUH: -�FHUHUL�IUHFYHQWH�SHQWUX�FDQWLWăþi mici de date;�-�FHUHUL�RFD]LRQDOH�SHQWUX�FDQWLWăþi mari de date.

Timpul de rãspuns pentru interogãri trebuie sã fie mai mic decât�GXEOXO�WLPSXOXL�QRUPDO�

de rãspuns pentru o interogare particularã.


ADD constrângeri de proiectare

C1. capacitate: � coeficient utilizare procesor și memorie 50%; coeficient utilizare

rețea 50%� 100 clienți de actualizare; 25 clienți de interogare� se�HVWLPHD]ă�100 actualizãri și 5�LQWHURJăUL�SH�secundã

C2. dispozitiv�PHPRULH�SHUVLVWHQWă�:� informații de stare salvate cel puțin odatã pe minut de cãtre serviciul

urmãrire; folosite ca date de restart dacã toate replicile serviciului urmãrire cad.

C3. replici: � serviciul urmãrire ºi memoria persistentã vor avea câte 2 replici

pentru asigurare disponibilitate, fiabilitate ºi mentenabilitate.


ADD scenarii cerinþe pentru atribute de calitate agreate de pãrþile interesate

Serviciul este disponibil în max.��min.

Starea componentei la revenire diferã cu max. 1 min. faþã de starea acesteia la momentul

producerii avariei.

Replica secundarã devine replicã primarã; începe procesarea cererilor de actualizare în mai puþin de 2 sec. de la avariere.Toate cererile de interogare trebuie onorate cu o întârziere medie de max. 3 sec.

Mãsurã

rãspuns

Informare clienþi - serviciu indisponibil.

Relansare serviciu. Informare clienþi ��DFFHSWDUH�actualizãri.

Corelare actualizãri cu informaþiile anterioare (automat / cu asistenþã administrator).

Informare clienþi ��DFFHSWDUH�LQWHURJăUL.

Onorarea tuturor cererilor efectuate anterior ºi pe timpul avariei. Cererile de actualizare pot fi ignorate max. 2 sec.

Rãspuns

Serviciul urmãrireServiciul urmãrireArtefact

Doar o replicã a serviciului urmãrire oferã servicii. O copie a componentei este disponibilã pe

memoria persistentã ºi poate fi transferatã la un

procesor de rezervã via LAN.

Existã douã replici în sistem.

Componenta serveºte mai mulþi clienþi concurenþi ºi pot exista ºi alte cereri într-o coadã de aºteptare

Context

Componenta ce se defecteazãComponenta ce se defecteazãSursã stimul

Cade o componentã hw/ sw a serviciului urmãrireCade o componentã hw/sw a serviciului urmãrire

Stimul

Scenariul S2��5HYHQLUH�OHQWă:Scenariul S1��5HYHQLUH�UDSLGă:


ADD Rezultatul primei etape

Comunicare sincronã

Comunicare asincronã

Reprezentare simplificatã

Server urmãrire

Serviciucomunicareasincronã

Client interogare

Memoriepersistentã

A B

Serviciucomunicare

sincronã

Client actualizare

Client interogare

Client interogare

Client actualizare

Client actualizare

Serviciupornire

Serviciunaming

Serviciuînregistrare

Serviciutoleranþã

la defecte Funcþii sistem

Servicii middleware

Serviciu de descompus

Citire/scriere stare


ADD Rezultatul primei etape

� Stil ales: client � server

� Divizare server în douã componente A ºi B

Strategii de repartizare:

1. A ºi B pe acelaºi procesor 50% utilizare procesor, 100 clienþi actualizare, 30 clienþi interogare

2. A ºi B în procesoare diferite 50% utilizare procesoare, 150 clienþi actualizare, 50 clienþi interogare

� Servicii pentru implementare mecanisme de comunicare sincron ºi asincron.

� Timpi refacere stare din memoria persistentã: A � 0.8 sec, B � 0,6 sec.

� Serviciu înregistrare � refuzã clienþi noi dacã nu se poate pãstra o rezervã predefinitã de

memorie.

� Serviciu de naming � înregistrare interfeþe la componentele server-ului.

� Client actualizare / interogare � apeleazã serviciu de comunicare asincronã / sincronã care

apeleazã iniþial serviciul naming pentru gãsire serviciu (A sau B) ºi pãstrazã aceastã informaþie în cache pentru apeluri ulterioare.


ADD Etapa 2

Obiectiv: Proiectarea serviciului toleranþã la defecte � parþial, referitor la serviciu urmãrire.

Directive pentru proiectantul arhitecturii serviciului toleranþã la defecte:

- Se vor utiliza cerinþe, modelul existent al elementului critic, scenariile pentru atributele de calitate, cu scopul de a adãuga toleranþã la defecte serviciului urmãrire.

- Dacã cerinþele care dirijeazã arhitectura dirijeazã la o soluþie prea complexã, se vor renegocia în sensul relaxãrii lor.

- Se vor documenta variantele arhitecturale considerate ºi raþiunile pentru alegerea fãcutã.

- Proiectarea serviciului pornire este responsabilitatea unei alte echipe, iar soluþiile vor fi unificate într-o etapã ulterioarã.

Important: se cere un model arhitectural preliminar ce va fi unificat cu alte modele arhitecturale ce sunt dezvoltate în paralel �VH�YD�XUPăUL�GRDU�VDWLVIDFHUHD�FHULQþelor care dirijeazã arhitectura, nu se va realiza un proiect de detaliu.


ADD Etapa 2

2. Alegerea elementului ce va fi descompus : Serviciul toleranþã la defecte.

Obs. Doar problematica referitoare la serviciul urmãrire.

3. Identificarea cerinþelor candidat care dirijeazã arhitectura:

Obs. Identificate folosind ºi constângerile de proiectare rezultate din etapa 1.

maremareRezultat etapa 1: timpi�UHIDFHUH�VWDUH�GLQ�PHPRULD�SHUVLVWHQWă�(P3)

micãmareRezultat etapa 1: mecanisme de comunicare (P2)

maremareRezultat etapa 1: caracteristici de repartizare (P1)

maremareCerinþã proiectare: douã replici (C3)

micãmedieCerinþã proiectare: serviciu memorie persistentã (C2)

maremareCerinþã proiectare: restricþii de capacitate (C1)

maremareCerinþã: funcþionalitatea serviciului urmãrire (R1 ºi R2)

mediemedieScenariu: Revenire lentã (S2)

maremareScenariu: Revenire rapidã (S1)

DificultateImportanþãCerinþe ce dirijeazã arhitectura


ADD Etapa 2

Pas 4: Alegerea unui concept de proiectare ce satisface cerințele care dirijeazã

arhitectura

4.1 Identificarea intereselor asociate cerinþelor care dirijeazã arhitectura

Interese (concerns) asociate cu serviciile de toleranþã la defecte:

� Pregãtire ��WDFWLFL�GH�UXWLQă�SH�SHULRDGD�QRUPDOă�GH�IXQFþionare pentru a asigura revenirea sistemului

� Detecþie � tactici asociate cu detectarea avariilor ºi notificarea unui element de rezolvare a problemei

� Refacere � operaþii realizate în perioada de tranziþie de la cãderea sistemului pânã la

revenirea acestuia la regimul de funcþionare normalã.


ADD Etapa 2Alegere concept de proiectare

Toleranþã la defecte

Pregãtire Detecþie Recuperare

�Restart

�Deployment

� Integritate date

�Monitorizare stare de funcþionare

�Transparenþã la clienþi

�Pornire replicã nouã

�Comportament client actualizare dupã avarie

tranzitorie

�Comportament client actualizare dupã avarie

hard (element de backup indisponibil)

�Comportament client interogare dupã avarie

tranzitorie

�Comportament client interogare dupã avarie hard (element de backup indisponibil)

4.1 Identificarea intereselor asociate cerinþelor care dirijeazã arhitectura - detalii


4.2 Creare listã de ºabloane potrivite cu fiecare interes, identificare parametrii discriminatori si valorile acestora. 4.3 Selectare ºabloane


nu> 50 msecactivãLoad sharing

nu> 50 msecactivãMaster / Master

posibil> 0.3 secpasivãWarm restart

da> 2 minpasivãCold restart

Pierdere serviciiEstimare duratã nefuncþionareTip replicãNume ºablon

Interes = Restart Parametrii discriminatori

Raþionament :�Conform R1 ºi S1 : timp maxim de repornire = 2 sec.�Warm restart: mai simplu de implementat.

Consecinþe :�Server-ul primar (A ºi B) recepþioneazã toate cererile ºi rãspunde la ele.�Server-ul secundar (standby: A� ºi B�) este încãrcat pe alt procesor ºi preia starea din memoria persistentã atunci când e promovat ca primar.



A�, B

A�, B�

P#2

A�, B

A�, B�

A cade

150

100

# actualizãri

0.850A, B�Separat

1.430A, BGrupat

Timp revenire#interogãriP#1Nume ºablon

Interes = Deployment Parametrii discriminatori

Raþionament :

�Arhitectul este familiar cu ºablonul Grupat, chiar�GDFă�UHYHQLUHD�SUHVXSXQH�FLWLUHD�VWăULORU�ambelor componente A ºi B din memoria persistentã.

�Totuºi sunt îndeplinite cerinþele.

Consecinþe :

�Componentele server-ului primar (A ºi B)�SDUWDMHD]ă�DFHODºi procesor. Similar, componentele server-ului secundar (A� ºi B�) partajeazã un alt procesor.

�Sistemul nu va fi operaþional cu componentele server-ului primar în procesoare diferite.



nu1.2 sec per minut + 1 mesaj per x sec.Ckp + Bundled Log Changes

Copie actualizatã a stãrii1.2 sec per minut + 1 mesaj per x sec.Ckp + Sync Primary & Backup

nu1.2 sec per minut + 100 mesaje per sec.Ckp + Log Changes

nu1.2 sec la fiecare 2 secundeFast checkpoint

nu1.2 sec la fiecare minutSlow checkpoint (Ckp)

Încãrcare procesor standbyÎncãrcare de comunicareNume ºablon

Interes = Integritate date Parametrii discriminatori

Raþionament :�Conform S2 : checkpoint la fiecare minut�Conform S1 : timp maxim actualizare 2 sec.�Se alege x=2 ºi varianta cea mai simplã.

Consecinþe :�Replica primar: salveazã starea odatã pe minut în fiºierul Ckp; adunã toate schimbãrile de

stare ºi le salveazã în fiºierul Log la fiecare 2 sec.

�Server-ul promovat ca primar: calculeazã starea conform informaþiilor din Ckp ºi Log ºi lanseazã salvarea ei în memoria persistentã; fãrã a se bloca în aºteptarea încheierii acestei operaþii, continuã procesarea actualizãrilor ºi interogãrilor.



8 mesaje (ping ºi echo pt. A, A�, B, B�)Ping / Echo

0 mesajeUpdate client detects failure

0 mesajeQuery client detects failure

4 mesaje (pt. A, A�, B, B�)Heartbeat (PULS)

Încãrcarea liniei de comunicareNume ºablon

Interes = Monitorizare stare funcþionare Parametru discriminator

Raþionament :

�Se preferã controlul de cãtre dezvoltatorii aplicaþiei a cerinþelor de temporizare.

�Se alege varianta cea mai simplã ºi care necesitã lãrgime de bandã mai micã.

�PULS setat la 0.25 sec 4 mesaje per sec.

Consecinþe :

�1.2 sec (iniþializarea celor 2 fiºiere Ckp) + 0.25 sec (PULS) ��.55 sec rezervã.�

�O componentã de monitorizare a stãrii de funcþionare detecteazã lipsa unui PULS ºi informeazã toate elementele interesate.

�Mecanismul de comunicare a unei avarii interne detectatã de A sau B este sã nu se trimitã

PULS.



infrastructurãmulticastInfrastructura gestioneazã avaria

ProxyunicastProxy gestioneazã avaria

clientunicastClientul gestioneazã avaria

Loc timeoutProtocol necesarNume ºablon

Interes = Transparenþã la clienþi Parametrii discriminatori

Raþionament :�Se preferã ca clienþii sã nu gestioneze avaria ca sã nu aparã uºor interpretãri greºite.�Infrastructura nu are capabilitate multicast inclusã; adãugarea ei este costisitoare iar simularea ei

cu unicast multiplu dubleazã utilizarea sistemului de comunicare.

Consecinþe :�Serviciul Proxy înregistreazã elementele A ºi B la serviciul de nume ºi apoi porneºte componentele primare ºi secundare, înregistrându-le la serviciul de nume sub nume diferite de cele anterioare.�Clientul invocã serviciul de nume ºi obþine referinþa la A sau B,�FX�FDUH�LQYRFă�R�RSHUDþie la serviciul de comunicare corespunzãtor. Acesta foloseºte Proxy pentru a determina replica primarã. Apoi obþine de la serviciul de nume referinþa corespunzãtoare, pe care o va folosi în apelurile ulterioare.�Dacã replica primarã cade, componenta de monitorizare a stãrii detecteazã lipsã PULS la aceasta ºi informeazã serviciul Proxy.�Proxy informeazã serviciile de comunicare despre avarie. Aceste elemente trimit cererile cãtre

serverul primar nou promovat, obþinând referinþele corespunzãtoare de la serviciul de nume.



Interes = pornire replicã nouã

Amânare decizie pânã la corelarea cu activitatea echipei responsabilã cu proiectarea

mecanismului de pornire.

Interes = comportament client actualizare dupã avarie tranzitorie

��0RQLWRUXO�VWăULL�GH�IXQFþionare informeazã componenta Proxy despre avarie ºi promoveazã replica secundarã la rang de replicã primarã.

� Proxy trimite un nou cod de acces secundar la fiecare mecanism de comunicare asincronã, cod ce va fi folosit pentru urmãtoarea cerere de actualizare.



Încãrcare mesaje mari la pornireSalvare actualizãri într-un fiºier

Linie de comunicare liberã pe durata nefuncþionãriiOprire trimitere actualizãri

Trimitere date inutilizabileContinuare trimitere actualizãri

ImpactNume ºablon

Interes = Comportament client actualizare dupã avarie hard Parametru discriminator

Raþionament :

�Conform S2 se acceptã comportament degradat ºi restart.

�Nu are rost trimiterea de date inutilizabile

Consecinþe :

�Clienþii trebuie sã fie capabili sã

� accepte o intrare care sã-i informeze cã serviciul urmãrire a cãzut,

� opreascã trimiterea de actualizãri.



Interes = comportament client interogare dupã avarie tranzitorie

��0RQLWRUXO�VWăULL�GH�IXQFþionare informeazã componenta Proxy despre avarie ºi promoveazã replica secundarã la rang de replicã primarã.

� Proxy trimite un nou cod de acces secundar la fiecare mecanism�GH�FRPXQLFDUH�sincronã, cod ce va fi folosit pentru urmãtoarea cerere de actualizare sau la relansarea cererii în curs.

� În ultimul caz serviciul de comunicare sincronã poate primi rãspuns dublu ºi trebuie sã

poatã renunþa la unul dintre acestea.

Interes = comportament client interogare dupã avarie hard

Similar cu comportament client actualizare dupã avarie hard.


4.4 Determinarea relaþiei între ºabloane ºi cerinþele care dirijeazã arhitectura


C3, S1 Warm standbyRestart

C1GrupatDeployment

C2, C1, S1, S2Checkpoint + Bundled Log ChangesIntegritate date

C1, S1, arhitectPULSDetecþie defecte

C1, arhitectProxy gestioneazã avariaTransparenþã la clienþi

n/aProxy gestioneazã avariaClient actualizare � defect tranzitoriu

C1, S2Stop trimitere actualizãriClient actualizare � defect hard

n/aProxy gestioneazã avariaClient interogare � defect tranzitoriu

C1, S2Stop trimitere interogãriClient interogare � defect hard

C3Douã repliciNumãr replici

Bazã decizieªablon selectatInteres


4.5 Capturarea vederilor arhitecturale preliminare


Elementele sistemului ºi iteraþia ADD în care au fost definite

Fiºier LogBServiciu înregistrare

Fiºier LogAServiciu nume

Fiºier CkpBServiciu comunicare asincronãMemorie persistentã

Fiºier CkpAServiciu comunicare sincronãClienþi actualizare

ProxyServiciu urmãrire BClienþi interogare

Monitor stare funcþionareServiciu urmãrire AServiciu urmãrire

Elemente definite în iteraþia 2Elemente definite în iteraþia 1Elemente definite direct din cerinþe



Reprezentare simplificatã

Serviciucomunicareasincronã

Client interogare

CkpA, CkpBLogA, LogB

Server urmãrire

primar

A B

Serviciu comunicare

sincronã

Client actualizare

Client interogare

Client interogare

Client actualizare

Client actualizare

Serviciupornire

Serviciunaming

Serviciuînregistrare

Serviciu toleranþã la defecte Comunicare sincronã

Comunicare asincronã

Funcþii sistem

Servicii middleware

Servicii toleranþã la

defecte

Citire/scriere stare

Notificare avarie

Monitor starefuncþionare

Proxy

Server urmãrire

secundar

A� B�

PULS

Pe durata revenirii



Comportamentul sistemului pentru detecþie avarie ºi recuperare din avarie � exemplu.



Cazul cel mai defavorabil:

T =Tps + Th + TrA + TrB + TrL + Tus = 2 + 0.25 + 0,8 + 0.6 + 0,2 + 0.1 = 3,95 inacceptabil

� Tps � periodicitate salvare în fiºier Log (2s)

� Th � periodicitate PULS (0.25s)

� TrA, TrB ��WLPS�GH�UHIDFHUH�VWDUH�$, B�FX�GDWH�GLQ�PHPRULD�SHUVLVWHQWă�(0.8s+0.6s)

� TrL � timp refacere fiºier Log cu date din memoria persistentã (0.2s)

� Tus � timp actualizare stare A ºi B cu date din fiºier Log (0.1s)


4.6 Evaluarea ºi rezolvarea inconsistenþelor


Variante îmbunãtãþire sistem:

1. Reducere periodicitate salvare în Log; sincronizare cu PULS.

Tps=1s. (Tps+Th) de la 2.25s la 1s T nou= 2.7s.

Tps=0.5s. încãrcare prea mare a mecanismului de comunicare.

2. Periodicitate salvare în Log =��.5 sec; salvare echivalentã cu PULS recunoscut de

memoria persistentã extindere funcþionalitate memorie persistentã cu recunoaºtere cãdere ºi informare alte elemente din sistem.

Necesitã modificarea modelului proiectat anterior : doar dacã va fi necesar.

3. Cele trei accese la memoria persistentã � concurente.

Reducere teoreticã a TrA+TrB+TrL de la 1.6s la 0.8s, practic însã existã partajare de

resurse 1s. T nou= 2.1 sec.

4. Deployment cu A ºi B pe procesoare diferite refacerea unei singure componente.

max(TrA || TrL, TrB || TrL)=0.85s. T nou=1.95s.



Variante îmbunãtãþire sistem (cont.):

5. Integritate date cu pãstrarea la secundar a unei copii actualizate a stãrii primarulului.

Necesitã modificarea modelului proiectat anterior : doar dacã va fi necesar.

6. Reducerea dimensiunii stãrii ce trebuie salvatã prin recalcularea la restart a unor date de stare.

Necesitã modificarea modelului proiectat anterior �QHFHVLWă�DFRUGXO�HFKLSHL�FH�D�UHDOL]DW�

etapa 1. Acordul obþinut TrA=TrB=0.6s. TrA || TrL=0.65s. T nou = 1.75s.


Pas 5: Instanþierea elementelor arhitecturale ºi alocarea responsabilitãþilor.

Element A (B) :� Primeºte mesaje de la clienþi, actualizeazã starea ºi rãspunde la interogãri.� A este repartizat pe acelaºi procesor cu B� dupã o cãdere a B, va funcþiona pe acelaºi procesor

cu noul B primar pânã la instanþierea unui nou B pe celãlalt procesor care va prelua rolul de primar (proces nedefinit încã).

� Trimite PULS la monitorul stãrii de funcþionare la fiecare 0.25s� Salveazã starea în fiºierul CkpA la fiecare minut.� Cumuleazã schimbãrile de stare ºi scrie în fiºierul Log la fiecare 1s; sincronizare cu salvare în CkpA.� Pornirea elementelor va fi adresata ulterior, împreunã cu echipa de proiectare a arhitecturii

serviciului Pornire.� Dacã ambele A ºi B� sunt defecte, elementul Proxy va notifica actorii interesaþi.

Memoria persistentã:Conþine fiºierele CkpA, CkpB, LogA ºi LogB, suprascrise la fiecare actualizare.

Monitorul stãrii de funcþionareUtilizeazã un timer pentru a verifica pulsurile primite de la A, A�,B ºi B�. Dacã lipseºte un semnal PULS

notificã elementul Proxy.

ADD Etapa 2


Serviciu comunicare asincronã :� Primeºte cereri de la clienþii actualizare ºi o direcþioneazã cãtre elementul corespunzãtor, folosind

serviciile elementului Proxy. Dacã ambele replici sunt inactive cere clienþilor sã întrerupã trimiterea

mesajelor de actualizare.

Serviciu comunicare asincronã :Primeºte cereri de la clienþii interogare. Funcþioneazã similar cu serviciul comunicare asincronã, cu

diferenþa cã blocheazã clienþii pânã la obþinerea rãspunsului la interogare.

Proxy:Înregistreazã toate metodele elementelor A ºi B la serviciul de nume. Porneºte efectiv elementele A, A�,B ºi B� ºi le înregistreazã metodele cu nume diferite la registrul de nume. Determinã statutul de primar sau

secundar pentru fiecare element. Captureazã toate cererile ºi le direcþioneazã cãtre elementul primar

corespunzãtor. Dupã detectarea unei avarii trimite serviciilor de comunicare referinþele la metodele din secundarul promovat ca primar.

Client actualizare / interogareCãderea unei componente ºi revenirea din avarie sunt transparente pentru clienþi. Se pot pierde un numãr

acceptat de actualizãri, respectiv poate sã aparã o întârizere acceptatã a rãspunsului la interogare.La apariþia unei cãderi hard (fãrã backup) clienþii vor fi notificaþi pentru a opri trimiterea de mesaje.

ADD Etapa 2


Pas 6: Definirea interfeþelor elementelor instanþiate.

ADD Etapa 2

La refacerePrimaryFailedServiciu comunicare (s/a)Proxy

Avarie ambele repliciStopServiciu comunicare (s/a)Proxy

aleatorInterogareA (B) primarServiciu comunicare sincronã

1sActualizareA (B) primarServiciu comunicare sincronã

1sWriteLogMemoria persistentã LogA(B)A (B) primar

0.25sPULSMonitor stare funcþionareA (B) primar, secundar

La refacereReadCkpMemoria persistentã CkpA(B)A (B) primar

La refacereReadLogMemoria persistentã LogA(B)A (B) primar

max. 1s de la detectareAvariePrimarProxyMonitor stare funcþionare

aleatorInterogareServiciu comunicare sincronãClient interogare

1sActualizareServiciu comunicare asincronãClient actualizare

La pornireRegister NamingProxy

WriteCkp

Interfaþã

60s

Timp

Memoria persistentã CkpA(B)A (B) primar

FurnizorSolicitant


Pas 7 Verificarea îndeplinirii cerinþelor de cãtre arhitectura componentei

dezvoltatã la pasul curent, rafinarea cerinþelor ºi transformarea lor în constrângeri pentru elementele proiectate.

ADD Etapa 2

renegociat TrA=TrB=0.6sRezultat etapa 1: timpi�UHIDFHUH�VWDUH�GLQ�PHPRULD�SHUVLVWHQWă��(P3)

serviciu comunicare (s/a), ProxyRezultat etapa 1: mecanisme de comunicare (P2)

warm restart, deployment distribuitRezultat etapa 1: caracteristici de repartizare (P1)

warm restart, deployment distribuitCerinþã proiectare: douã replici (C3)

integritate date Ckp60s & Log1sCerinþã proiectare: serviciu memorie persistentã (C2)

deployment distribuitCerinþã proiectare: restricþii de capacitate (C1)

warm restartCerinþã: funcþionalitatea serviciului urmãrire (R1 ºi R2)

integritate date Ckp60s & Log1sScenariu: Revenire lentã (S2)

warm restart; deployment distribuit; integritate date Ckp60s & Log1s; detecþie avarie PULS la 0.25s; citiri paralele din Ckp & Log pentru refacere.

Scenariu: Revenire rapidã (S1)

Realizare & Constrângeri noiCerinþe ce dirijeazã arhitectura



Scenarii generale

Tactici







PLAN CURS



Arhitectura securitãþii = politicile de securitate ºi elementele de controlpentru diminuarea riscurilor, care sunt integrate în arhitectura sistemuluiîn scopul reducerii riscului unei ameninþãri.

Obiective ale arhitecturii securitãþii:

Confidenþialitate ��SUHYHQLUHD�GLYXOJăULL�GH�LQIRUPDþii utilizatorilor, entitãþilor sau proceselor neautorizate.

Integritate ��SUHYHQLUHD�PRGLILFăULL�VDX�GLVWUXJHULL�HOHPHQWHORU�GH�valoare de cãtre utilizator sau entitate neautorizatã.

Disponibilitate � protecþia faþã de atacuri de tip �denial-of-service� cu impact asupra accesului utilizatorilor la sistem.

Non-repudiere ��DVLJXUDUHD�Fă�QLFL�XQXL�SDUWLFLSDQW�OD�R�LQWHUDFþiune nu i se refuzã rolul în cadrul interacþiunii.


Ameninþãri, atacuri ºi vulnerabilitãþi

Ameninþare (Threat) = eveniment potenþial ce duce la compromiterea sistemului.

Atac � instanþã sau realizare a unei ameninþãri.

Vulnerabilitate (V) � un viciu sau un defect în procedurile de securitate ale sistemului, în design-ul, în implementarea sau în elementele interne de control ale acestuia care,�dacã este exploatat, poate rezulta în compromiterea securitãþii.


Elemente de control pentru diminuarea riscurilor

Proceduri de securitate

Rutare separatã pentru PIN ºi card ATM.

Dubla împachetare a materialelor / datelor sensibile înainte de expediere.

Schimbarea frecventã a parolelor utilizatorilor.

Tehnologii de securitate

Firewall

SSL (secure socket layer)

Software de verificare conturi (audit)

Detectarea intruziunilor


Cerinþe pentru arhitectura securitãþii

Autentificare ��SURFHVXO�GH�VWDELOLUH�D�YDOLGLWăþii unei identitãþi pretinse.

Autorizare ��SURFHVXO�GH�GHWHUPLQDUH�Fă�R�HQWLWDWH�YDOLGDWă�DUH�DFFHVXO�permis la un element securizat.

Audit � abilitatea de a identifica ºi de a asocia o entitate cu interacþiunea sa cu un element securizat.

! Obiective nerealiste de proiectare !:

Predicþia cu acurateþe maximã a riscurilor de securitate

Eliminarea tuturor riscurilor de securitate

Securitate complet automatã

Eliminarea totalã a intervenþiei umane

Integrarea produselor comerciale (COTS) cu pãstrarea integralã a securitãþii


Tensorii proiectãrii arhitecturale pentru securitate

Arhitectura

sistemului

Obie

ctive o

rtogonale

Obiective opuseSecuritate

Disponibilitate mare

Robusteþe

Reconstruirea evenimentelor

Uºurinþã în utilizare

Adaptabilitate

Evoluþie

Performanþã

Scalabilitate

Interoperabilitate

Mentenabilitate

Portabilitate


Controlul securitãþii

Comunicaþii protejate

ResursãProces/utilizator

Autentificare Non-repudiere

Impunerea controlului accesului

Authorizare Tranzacþiiprivate

IDs

Audit

Integritate

Restaurare

Protecþiile sistemului

Identificare

Gestionarea cheilor criptografice

Administrarea securitãþiiControale suport

Controale detecþie ºi recuperare

Controale prevenþie



Scenarii generale

Tactici







PLAN CURS



Securitatea este parte integrantã a arhitecturii sistemului

Apãrare în adâncime (protejare, detectare, recuperare)

Stabilirea ºi separarea zonelor de încredere

Privilegiul minim

Simplitate

Echilibrarea balanþei risc � cost

Protejarea informaþiilor aflate în tranzit ºi a celor de pe suporturile de memorare

Nu existã securitate absolutã


Apãrare în adâncime

Protecþie

Detecþie

Recuperare


Exemplu � sistem portal webCerinþã : autentificare ºi autorizare

Laptops

Web Server

Application Servers

Data

Workstations

Authentication/Authorization Server

Protecþie

Detecþie

Recuperare


Exemplu � sistem portal webCerinþã : audit

Laptops

Web Server

Application Servers

Data

SSL

SSL

Workstations


Security

Audit Server

AuditData

Audit Workstation

Protecþie

Detecþie

Recuperare


Exemplu � sistem portal webCerinþã : autentificare puternicã

Security

Audit Server

AuditData

Laptops

Web Server

Application Servers

Data

SSL

SSL

Workstations


Audit Workstation

S D

Protecþie

Detecþie

Recuperare


Exemplu � sistem portal webZone de încredere

Middle Tier

FirewallWeb Clients

Security

Audit Server

AuditData

Laptops

Application Servers

Data

SSL

SSL

Workstations


Audit Workstation

SD

ServerFirewall

Firewall

Protecþie

Detecþie

Recuperare


SD


Detecþie

Protecþie

Detecþie

Recuperare



Recuperare

%DFNXS

'DWD

:HE�6HUYHU�Z�

,'6

0LGGOH�7LHU

)LUHZDOO

:HE�&OLHQWV

6HFXULW\

$XGLW�6HUYHU

$XGLW

'DWD

/DSWRSV

$SSOLFDWLRQ�6HUYHUV

'DWD

66/

66/

1HWZRUN�,'6

:RUNVWDWLRQV

$XWKHQWLFDWLRQ�$XWKRUL]DWLRQ�6HUYHU

$XGLW�:RUNVWDWLRQ

SD

5HGXQGDQW

6HUYHU

)LUHZDOO)LUHZDOO

Protecþie

Detecþie

Recuperare



Scenarii generale

Tactici







PLAN CURS



Stabilire politici

Implementare Proiectare

Evaluare Evaluare risc

CerinþeGestionare



Planificareproiect

Definirecerinþe

Proiectare

Dezvoltare

Integrare& Test

Instalare& Acceptare

Sta

bilir

e po

litic

i

Eva

luar

e ris

c

Cer

inþe

Pro

iect

are

Impl

emen

tare

Gestionare

Evaluare

În fazele mentenanþei/evoluþiei SW

Stabilire politici

Implementare Proiectare

Evaluare Evaluare risc

CerinþeGestionare



Curs 13




1. Cerinþele pentru atributele de calitate sunt elementele fundamentale de dirijare�D�SURLHFWăULL�XQHL�DUKLWHFWXUL�VRIWZDUH.


DAR existã:









PLAN CURS

Utilizabilitatea sistemelor software

ªabloane arhitecturale pentru utilizabilitate bazate pe separare

ªabloane arhitecturale suport pentru utilizabilitate (USAP)

Un exemplu de USAP


Utilizabilitate

Def. Utilizabilitate = mãsura calitãþii experimentate de utilizator în interacþiunea cu informaþii sau servicii.

Chiar dacã funcþionalitatea este corectã,

Chiar dacã UI este separatã de funcþionalitate,

Deciziile arhitecturale realizate iniþial pot împiedica implementarea unui sistem utilizabil.

E posibil ca o anumitã modificare solicitatã (de caracteristicã sau de funcþionalitate) în sensul creºterii utilizabilitãþii sã ajungã prea adânc în arhitectura sistemului pentru a permite realizarea ei viabilã din punct de vedere economic ºi de timp.


Utilizabilitate � exemple de scenarii generale

Feedback warning/status/alert

�Se vor afiºa indicatori de stare sau de alertã când sunt satisfãcute condiþiile corespunzãtoare.�

Profil utilizator

�Fiecare utilizator trebuie sã poatã seta diferiþi parametrii care controleazã

prezentarea.�

Agregare comenzi

�Utilizatorul trebuie sã poatã invoca executarea unei colecþii de comenzi.�

Recuperarea din avarie

�La cãderea sistemului, procesorului sau reþelei, utilizatorul nu trebuie sã piardã

starea curentã.�

Suport pentru internaþionalizare

�Utilizatorul trebuie sã poatã folosi un limbaj ºi un format de afiºare care îi este familiar.�


Obiective curs

Înþelegerea principiilor de bazã ale arhitecturilor software pentru sisteme interactive.

Înþelegerea modului în care aceste principii afecteazã utilizabilitatea�VLVWHPXOXL.

Motivul utilizãrii de ºabloane bazate pe separare.

Cazuri în care ºabloanele bazate pe separare nu sunt suficiente.


Practici obiºnuite în proiectarea de detaliu a sistemelor interactive

Toate tehnicile HCI (Human Computer Interaction) suport pentru proiectarea de detaliu a interfeþei utilizator sunt bazate pe proiectare iterativã.

(i.e proiectare, testare (analizã sau mãsurare), modificare, re-testare)

Odatã ce software-ul a fost dezvoltat, iterarea implicã modificãri ale acestuia.

Inginerii software pregãtesc realizarea acestor modificãri prin izolarea secþiunii ce va fi modificatã (separare).


PLAN CURS




Un exemplu de USAP


ªabloane arhitecturale pentru utilizabilitatebazate pe separabilitate

MVC (Model-View-Controller) (1980, Smalltalk)

Adaptat pentru context web pe platforma Java EE de la Sun

Recomandat de Microsoft pentru .NET

Documentat în Buschmann (Pattern-Oriented Software Architecture, vol 1)

PAC (Presentation-Abstraction-Control) (1980 � univ. Din Grenoble)

Reacþie la dezavantajele MVC

Utilizate curent în practicã, cu succes dovedit.


MVC

Orientat obiect

Model � starea ºi funcþionalitatea aplicaþiei(operaþii).

View ��UHGă�PRGHOH�ºi trimite gesturile utilizatorului la controller.

Controller ��DFWXDOL]HD]ă�modelul, selecteazã vedere, defineºte comportamentul aplicaþiei (interacþiuni, flux).

Command Processor

Command Processor

ModelCommand Processor

Command Processor

View

Controller

Dispozitiv de intrare

Dispozitiv de ieºire


MVC

Avantaje

Suport pentru vederi multiple asupra aceloraºi date

� Utilizatorul are perspective multiple asupra aceloraºi date (ex. vederi de tip outline ºi de tip layout)

� Diferite dispozitive prezintã aceleaºi informaþii în moduri corespunzãtoare

platformelor pe care se aflã (ex. PDA, laptop)

� Diferiþi utilizatori au acces simultan la aceleaºi date

Separare prezentare (view) de aplicaþie �SHUPLWH�UHDOL]DUHD�GH�PRGLILFăUL�DOH�prezentãrii independent de restul aplicaþiei.


ªabloane bazate pe separare

Larg utilizate în practicã.

Suport pentru dezvoltarea de instrumente specializate

Biblioteci de widget-uri

Diferite tipuri de controller-e

Separarea prezentãrii de aplicaþie este foarte importantã.

DAR ºabloanele bazate pe separare nu sunt suficiente pentru sistemeleinteractive.


ªabloane bazate pe separare ºi proiectarea iterativã

Cerinþe revelate pe parcursul proiectãrii iterative:

Modificãri ale funcþionalitãþii

Modificãri ale UI referitoare la conþinutul ecranelor

Modificãri ale UI dincolo de conþinutul ecranului

Zona de modificãri dificil de realizat

Modificãri facilitate de

arhitectura software

Cerinþe descoperite pe parcursul proiectãrii

iterative


MVC ºi proiectarea iterativã (1)

Modificare asupra caracteristicilor afiºãrii modificare view : view conþine toatã

logica de afiºare.

Ex. Modificare culori, font, aºezare în paginã (layout).

Modificare la fluxul prezentãrii modificare controller : controller-ul defineºte fluxul prezentãrii.

Ex. Modificarea ordinii dialogurilor.



Adãugarea abilitãþii de a anula o comandã cu duratã mare de execuþie.

Modificari la toate componentele arhitecturii:

� View ��EXWRQ�&DQFHO�VDX�DOWă�PRGDOLWDWH�GH�D�FRPDQGD�DQXODUHD�

� Controller ��ORJLFD�GH�UăVSXQV�OD�FRPDQGă�ºi de executare a funcþiei corespunzãtoare

� Model � modul de alocare a resurselor, ...

Probleme:

� Implicã toate componentele arhitecturii

� Localizare slabã

� Dacã cerinþa apare târziu,�YD�QHFHVLWD�PRGLILFăUL�FRQVLGHUDELOH�DOH�DUKLWHFWXULL


Concluzii

Proiectarea de detaliu a interfeþei utilizator se bazeazã pe

abordare iterativã.

Proiectarea iterativã este suportatã de ºabloanele bazate pe separare.

Unele probleme de utilizabilitate implicã mai multe componente de diferite tipuri ale ºabloanelor bazate pe separare.


PLAN CURS




Un exemplu de USAP


ªabloane arhitecturale suport pentru utilizabilitate(USAP � Usability Supporting Architectural Patterns)

Obiectiv � recunoaºterea ºi prevenirea problemelor obiºnuite de utilizabilitate care nu sunt suportate de principiul separãrii.

Soluþie - USAP:

Identificarea aspectelor de utilizabilitate care sunt sensibile din punct de vedere arhitectural ºi reprezentarea lor cu scenarii simple.

Oferirea unui mod de analizã a forþelor ce acþioneazã, în aceste scenarii, asupra arhitecturii proiectate.

Oferirea unei liste de verificare�D�UHVSRQVDELOLWăþilor software importante.

Oferirea de ºabloane arhitecturale�FX�SRVLELOLWăþi de satisfacere a acestor scenarii.


ªabloane arhitecturale suport pentru utilizabilitate(USAP)

Sensibilitate din punct de vedere arhitectural

Un scenariu de utilizabilitate este considerat sensibil din punct de vedere arhitectural dacã

satisfacerea acestuia poate necesita modificãri la arhitectura sistemului.

Într-un ºablon bazat pe separare, aceasta înseamnã cã implementarea modificãrii va avea

impact atât asupra prezentãrii cât ºi asupra abstractizãrii (modelului).

ªabloanele bazate pe separare sunt destinate localizãrii modificãrilor referitoare la prezentarea informaþiilor.

Rezultã - exemplu:

� Modificãri de culori ºi font ��QX�VXQW�VHQVLELOH�GLQ�SXQFW�GH�YHGHUH�DUKLWHFWXUDO

� Adãugarea opþiunii de anulare (Cancel) ��HVWH�VHQVLELOă�GLQ�SXQFW�GH�YHGHUH�DUKLWHFWXUDO.



Scenariu de utilizabilitate sensibil din punct de vedere arhitectural - exemplu.

Anulare comenzi

�Utilizatorul trimite o comandã, apoi se rãzgândeºte dorind oprirea operaþiei ºi revenirea sistemului la starea dinaintea lansãrii comenzii. Nu conteazã motivul

utilizatorului: poate fi o greºealã a sa, poate fi din cauzã cã sistemul nu

rãspunde la comandã, sau poate s-a modificat contextul.�



Exemple de modificãri sensibile din punct de vedere arhitectural.

Agregarea datelor Agregarea comenzilor Alerte Anulare comenzi Verificarea corectitudinii Evaluarea sistemului Validare formã/câmp

Jurnalizare istoric Menþinerea independenþei dispozitivelor

(diferite metode de acces) Menþinerea compatibilitãþii cu alte sisteme Accesibilizarea vederilor Modificarea interfeþelor Navigarea în cadrul unei singure vederi Observarea stãrii sistemului

Operare consistentã la traversarea vederilor

Feedback al progresului Help performant (Context-Sensitive Help)

Recuperarea din defecte Reutilizare informaþii Extragere parole uitate Indicare stare Suport pentru cãutãri extensive

Suport pentru internaþionalizare(diferite limbi)

Suport pentru activitãþi multiple Suport pentru Undo Suport pentru personalizare

(profil utilizator) Suport pentru vizualizare Tur Utilizare concurentã

(Multi-tasking) Verificare resurse Wizard Model�DO�IOX[XOXL�GH�DFWLYLWăþi Lucru în ritmul utilizatorului Lucru în context nefamiliar


Procesul de dezvoltare

Echipa de dezvoltare:

Ingineri software

Specialiºti în utilizabilitate

Manager proiect

Scenariile de utilizabilitate sensibile din punct de vedere arhitectural sunt surse de cerinþe, deci

Trebuie sã fie concrete

Trebuie sã fie eficace pentru un sistem particular.



În plus faþã de scenariile de utilizabilitate sensibile din punct de vedere

arhitectural, sunt necesare:

Determinarea balanþei cost-beneficiu în implementarea scenariului

Oferirea unui ghid pentru echipa de dezvoltare referitor la problemele asociate cu implementarea soluþiei.

Ghid:

Pentru ingineri software

� Lista responsabilitãþilor ce trebuie considerate de cãtre orice soluþie de implementare a scenariului

� Exemplu de soluþie care alocã responsabilitãþi modulelor bazate pe MVC

Pentru specialiºtii în utilizabilitate

� Tipurile de beneficii aºteptate de la scenariul propus

Ingineri software � costSpecialiºti în utilizabilitate - beneficiiManager proiect - arbitru


Forþele ce acþioneazã asupra proiectului arhitectural

Reguli organizaþionale la utilizator

Activitate în context

Forþe

Sistem

Utilizator

Dorinþe ºi capabilitãþi

Software

Starea software-lui

Responsabilitãþigenerale

Soluþie specificã

(mai multe detalii)Ex. Tactici.

Forþe

Forþe

Forþe

Decizii de proiectare anterioare

ForþeBeneficii

Beneficiioferite de soluþie

Forþe diferite motiveazã aspecte

particulare ale soluþiei.


Discuþie despre proiectarea arhitecturii

Forþele provin din diferite surse:

� Activitatea implicatã ºi contextul în care opereazã utilizatorul.

� Ex. �Cancel� este util doar dacã operaþia este de lungã duratã.

� Dorinþele ºi capabilitãþile factorului uman.

� Ex., Utilizatorii fac greºeli. �Cancel� oferã un mod de a corecta greºeli.

� Starea sistemului (software-lui).

� Ex. Reþelele cad. Dând utilizatorului posibilitatea de anulare a unei operaþii, acesta poate preveni blocarea datoratã unei cãderi de reþea.


Beneficiile utilizabilitãþii

Elementele ce definesc utilizabilitatea unui sistem software depind de contextul de utilizare al acestuia.

Aspecte comune:

� Eficienþa utilizãrii

� Timpul necesar învãþãrii modului de utilizare eficientã

� Suport pentru explorare ºi pentru rezolvarea problemelor

� Satisfacþia utilizatorului (ex. încredere, confort, acceptare de cãtre

utilizatorii discreþionari)

Beneficiile utilizabilitãþii pot fi organizate ierarhic.


Beneficiile utilizabilitãþii � o ierarhie

Creºte eficienþa utilizatorului individual

Reduce impactul erorilor sistemului

Creºte încrederea ºi confortul utilizatorului

Creºte performanþa activitãþilor de rutinã

Creºte performanþa activitãþilor non-rutiniere

Reduce impactul erorilor utilizatorului datorate lipsei de cunoºtinþe

Previne erorile sistemului

Tolereazã erorile sistemului

Accelereazã porþiunea liberã de erori a activitãþilor de rutinã

Reduce impactul erorilor utilizator la operaþiile de rutinã(scãpãri din vedere)

Sprijinã rezolvarea problemelor

Faciliteazã învãþarea

Previne greºelile Se adapteazã

greºelilor


Proiectare arhitecturã

Existã o multitudine de metode diferite pentru a satisface un scenariu particular.

Majoritatea sistemelor utilizeazã ºabloane arhitecturale bazate pe separare, ca bazã pentru proiectul de ansamblu al sistemului.

În USAP sunt oferite douã componente diferite ale soluþiei:

Soluþia generalã ��UHVSRQVDELOLWăþile software-lui ce trebuie îndeplinite de orice soluþie.

Soluþia specificã � un ºablon arhitectural care aratã cum trebuie

implementatã soluþia generalã în contextul unui ºablon bazat pe separare.

Pentru exemplificare, vom considera MVC ca fiind un ºablon bazat pe separare acoperitor.



Documentarea ºablonului

Context Situaþia � scenarii de utilizabilitate sensibile din punct de vedere arhitectural.

Condiþiile � constrângeri asupra momentelor când situaþia este relevantã.

Beneficiile utilizabilitãþii � enumerarea beneficiilor aduse utilizatorului prin adoptarea acestui scenariu.

Ghid cost-implementare Soluþia generalã ��VHW�GH�UHVSRQVDELOLWăþi pe care fiecare soluþie trebuie sã le

satisfacã.

Raþiuni fundamentale pentru fiecare responsabilitate în termeni de forþe aflate în conflict:� Forþele exercitate de activitate ºi de context,

� Forþele exercitate de dorinþele ºi capabilitãþile factorului uman,

� Forþele exercitate de starea software-lui atunci când utilizatorul doreºte sã aplice

scenariul sensibil din punct de vedere arhitectural.

Soluþia specificã � ºablonul arhitectural pentru rezolvarea situaþiei, prin asumarea unui ºablon bazat pe separare acoperitor (ex. MVC).


Concluzii

ªabloanele bazate pe separare nu oferã suport pentru toate scenariile de utilizabilitate sensibile din punct de vedere arhitectural.

Abordarea prezentatã este împachetatã în USAP ºi conþine:

Identificare scenariu de utilizabilitate sensibil din punct de vedere arhitectural

Oferirea de informaþii a.î. echipa de dezvoltare sã poatã face aprecieri în cunoºtinþã de cauzã despre aplicabilitatea scenariului

� Condiþiile în care este aplicabil scenariul

� Beneficiile oferite de implementarea scenariului

� Responsabilitãþile generale utile în orice situaþie, împreunã cu raþiunile fundamentale pentru fiecare responsabilitate

� Soluþie specificã bazatã pe MVC.


PLAN CURS




Un exemplu de USAP


USAP � exemplu �Cancel�

Situaþia: �8WLOL]DWRUXO�WULPLWH�R�FRPDQGă�ºi apoi se rãzgândeºte, dorind sã

opreascã operaþia ºi sã readucã sistemul în starea de dinainte de lansarea comenzii. Nu conteazã motivul utilizatorului: poate fi o greºealã a sa, poate fi din cauzã cã sistemul nu rãspunde la comandã, sau poate s-a modificat contextul.

Condiþii asupra situaþiei:��Un utilizator lucreazã într-un sistem în care software-ul executã comenzi cu

duratã mare, i.e. mai mult de 1 sec.

Comanda de anulare poate fi trimisã explicit de cãtre utilizator sau se poate lansa automat prin sesizarea unui anumit context.

ContextulBeneficiileResponsabilitãþile generaleSoluþia specificã



Creºte eficienþa utilizatorului individual� Creºte performanþa activitãþilor de rutinã

� Accelereazã porþiunea liberã de erori a performanþei operaþiilor de rutinã

Cancel permite utilizatorilor sã revoce comenzi lansate accidental ºi sã revinã la la

activitatea anterioarã mai repede decât dacã ar aºtepta terminarea comenzii eronate.

� Creºte performanþa activitãþilor non-rutiniere� Sprijinã rezolvarea problemelor

Cancel permite utilizatorului sã aplice comenzi ºi sã exploreze fãrã teamã, deoarece îºi poate oricând anula acþiunile.

� Reduce impactul erorilor utilizatorului cauzate de lipsa de cunoºtinþe (greºeli)� Se adapteazã greºelilor

Cancel permite utilizatorilor sã anuleze comenzile pe care le-au invocat din necunoaºtere ºi sã revinã la activitatea anterioarã mai repede decât dacã ar

aºtepta terminarea comenzii eronate.




Reduce impactul erorilor sistemului� Tolereazã erorile sistemului

Cancel permite utilizatorilor sã anuleze comenzi care nu lucreazã corespunzãtor.

Creºte încrederea ºi confortul utilizatoruluiCancel permite utilizatorilor sã lucreze fãrã teamã deoarece îºi pot oricînd anula

acþiunile.




R1: Se va oferi un buton, o opþiune de menu, un accelerator ºi/sau alte mijloace de a anula comanda curentã.

Forþe dinspre context ºi dinspre activitate

Forþe dinspre utilizator

Utilizatorii îºi comunicã intenþiile prin gesturi speciale (ex.�DSăVDUH�EXWRQ)

Forþe dinspre softwarePentru a executa ceva, software-ul trebuie sã recepþioneze un gest utilizator.




R2: Permanent sistemul trebuie sã asculte pentru comanda Cancel

sau pentru modificãrile de context.


Nimeni nu poate prezice când apare o schimbare în context.


Nimeni nu poate prezice când utilizatorii vor dori sã anuleze o comandã.

Forþe dinspre software




R3: Sistemul trebuie sã culeagã permanent informaþii (stare, utilizare resurse, gesturi utilizator,�HWF.) care permit recuperarea stãrii sale

de dinainte de executarea comenzii curente.









R4: Sistemul trebuie sã confirme recepþionarea corespunzãtoare a

comenzii de anulare în timp de 150 ms. Confirmarea trebuie sã

corespundã cu maniera în care a fost trimisã comanda.



Utilizatorul trebuie sã afle în 150 ms�Fă�L-a fost recepþionatã comanda, altfel va încerca din nou.





R5: Dacã comanda este capabilã sã se anuleze direct la momentul

anulãrii, comanda trebuie sã rãspundã prin anularea sa.


Activitatea sau contextul a indicat faptul cã activitatea trebuie sã se termine (ex. memorie insuficientã).

Forþe dinspre utilizatorUtilizatorul ºi-a comunicat dorinþa de a se termina comanda.

Forþe dinspre softwareComanda este reactivã în momentul anulãrii.




R6: Dacã comanda nu este capabilã sã se anuleze direct la momentul

anulãrii, comanda trebuie anulatã de cãtre o porþiune activã a

sistemului.




Forþe dinspre softwareComanda nu este reactivã în momentul anulãrii.




R7: Dacã comanda a invocat procese pentru colaborare, aceste procese trebuie informate despre anularea comenzii ce le-a invocat (aceste procese au responsabilitãþi proprii pe care trebuie sã le realizeze ca

rãspuns la aceastã informare, posibil tratând-o ca pe o anulare). Informaþia datã proceselor colaborator poate include cerere de

anulare, progresul anulãrii ºi/sau încheierea anulãrii.




Comanda a invocat procese colaborator.




R8: Dacã sistemul este capabil sã deruleze înapoi toate modificãrile, pânã la starea anterioarã executãrii comenzii de anulat, starea sistemului trebuie restauratã la starea anterioarã executãrii

acesteia.



Utilizatorii doresc ca sistemul sã funcþioneze ca ºi când comanda anulatã nu ar fi fost

lansatã.


Sistemul este capabil sã deruleze înapoi toate schimbãrile, pânã la starea de dinaintea

executãrii comenzii.




R9: Dacã sistemul nu este capabil sã deruleze înapoi unele modificãri

realizate pe durata executãrii comenzii de anulat pânã la momentul anulãrii, sistemul trebuie restaurat într-o stare cât mai apropiatã de

cea anterioarã executãrii comenzii de anulat.




lansatã.


Sistemul nu este capabil sã deruleze înapoi toate schimbãrile, pânã la starea de

dinaintea executãrii comenzii.





realizate pe durata executãrii comenzii de anulat pânã la momentul anulãrii, sistemul trebuie sã informeze utilizatorul despre diferenþa, dacã existã, dintre starea restauratã ºi cea anterioarã lansãrii

comenzii de anulat.




lansatã. Dacã utilizatorii nu sunt conºtienþi de schimbãrile de stare, atunci este posibil sã producã erori ulterioare.







R11: Sistemul trebuie sã elibereze toate resursele (pe care le poate elibera) consumate pentru procesarea comenzii de anulat.


Sistemul trebuie sã rãmânã stabil în timp.�'DFă�H[LVWă�UHVXUVH�QHHOLEHUDWH, aceasta poate conduce la degradãri ºi cãderi ulterioare ale sistemului (ex. memory leak).

Forþe dinspre utilizatorUtilizatorii doresc ca sistemul sã revinã în starea de dinaintea lansãrii comenzii.





R12: Dacã unele resurse au fost consumate irevocabil ºi nu pot fi restaurate, sistemul trebuie sã informeze utilizatorul într-o manierã

vizibilã despre resursele restaurate doar parþial.


Sistemul trebuie sã rãmânã stabil în timp.�'DFă�H[LVWă�UHVXUVH�QHHOLEHUDWH, aceasta poate conduce la degradãri ºi cãderi ulterioare ale sistemului (ex. memory leak)


Forþe dinspre softwareResursele au fost consumate irevocabil ºi nu pot fi restaurate.




R13: Dacã procesul de anulare a comenzii dureazã mai mult de 1 sec, controlul trebuie returnat la utilizator (dacã în contextul respectiv este necesarã continuarea lucrului cu sistemul).



Utilizatorii doresc sã lucreze în paralel dacã trebuie sã aºtepte prea mult anularea comenzii.


Procesul de anulare a comenzii dureazã mai mult de 1 sec.




R14: Estimarea duratei procesului de anulare a comenzii. Dacã durata

estimatã este între 1 ºi 10 sec, atunci forma cursorului va fi modificatã pentru a reflecta o stare �busy�. Dacã durata estimatã

este mai mare de 10 sec, utilizatorului i se va prezenta un indicator al progresului.









R15: La terminarea procesului de anulare, sistemul trebuie sã ofere

feedback utilizatorului referitor la acest lucru (ex. refacerea formei cursorului, eliminarea barei cu indicatorul de progres, închiderea casetei de dialog).


Forþe dinspre utilizatorUtilizatorii doresc sã fie notificaþi la încheierea procesului de anulare.





Alte responsabilitãþi posibile:

În cazul în care comanda anulatã este criticã, pot fi necesare ºi alte acþiuni.

Exemple: Blocarea posibilitãþii ca utilizatorul sã mai trimitã ºi alte comenzi.

Solicitarea de confirmãri, dacã anumite resurse nu sunt eliberate.



Observaþii

1. Programatorul ar putea trece cu vederea unele detalii.Exemple: Eliberarea resurselor

Feedback dacã nu se poate termina anularea

Informarea colaboratorilor

2. Se recomandã realizarea unei tabele pentru analiza relaþiei cost/beneficiu:

Exemplu de intrare în tabelã:

Beneficiul : eficienþã crescutã - utilizatorul doreºte sã lucreze în paralel cu un proces de anulare de lungã duratã

Costul : poate fi prea mare, funcþie de contextul sistemului.



ªabloane acoperitoare

În general proiectanþii nu construiesc proiectul sistemului pe baza scenariilor de utilizabilitate sensibile din punct de vedere arhitectural.

Proiectanþii au câteva ºabloane acoperitoare pe care le utilizeazã (ex. MVC).

Un ºablon arhitectural introduce forþe suplimentare dinspre software asupra soluþiei specifice.

Vom utiliza MVC pentru a ilustra:

Efectul ºablonului acoperitor asupra soluþiei specifice

Utilizarea unui ºablon larg folosit în aplicaþii Web



Soluþia specificã

Vedere arhitecturalã -�SUH]LQWă�XQXO�VDX�PDL�PXOWH�DVSHFWH�DOH�arhitecturii.

Vederi comune reprezentate în UML:

Diagrama de componente ��SUH]LQWă�XQLWăþile majore de software dar nu ilustreazã comportamentul dinamic sau asignarea unitãþilor la diferite procesoare.

Diagrama de secvenþe ��DUDWă�VHFYHQþa activitãþilor pentru un singur fir de control în cadrul sistemului.



Soluþia specificã

Contextul soluþiei specifice � MVC


:Controller

:View Active-Command:Model

:Controller:Controller

:View:View Active-Command:Model

Active-Command:Model


Soluþia specificã

Contextul soluþiei specifice � MVCDiagrama de componente pentru o soluþie specificã pentru Cancel.


Prior-State-Manager:Model

:Controller

Cancellation-Manager:Model

Listener:Controller


Collaborating-Process:Model






Listener:ControllerListener:Controller






Soluþia specificã Responsabilitãþile componentelor noi

Listener� Tip: controller� Trebuie sã asculte permanent pentru comenzile de anulare sau pentru modificãrile de

context (R2) Cancellation Manager

� Tip: model� Permanent ascultã ºi culege informaþii (R2, R3)� Trateazã anularea dacã nu primeºte rãspuns de la Active Command (R6) �� Elibereazã resursele (R11)� Estimeazã durata procesului de anulare (R13, R14)� Informeazã utilizatorul despre progresul procesului de anulare (R14, R15).

Prior State Manager� Tip: model� Culege permanent informaþii (în colaborare cu Cancellation Manager � stare, utilizare

resurse, acþiuni,...) ce permit refacerea stãrii sistemului anterioarã executãrii comenzii curente (R3)

� Dacã nu se primeºte rãspuns de la Active Command (R6), colaboreazã cu

Cancellation Manager pentru a restaura sistemul în starea anterioarã executãrii

comenzii curente (R18) sau într-o stare cât mai apropiatã de aceasta (R9).



Soluþia specificã Responsabilitãþile noi pentru componentele vechi

View� Tip: view� Oferã buton, opþiune menu, accelerator ºi/sau altã modalitate de anulare a

comenzii curente (R1)� Trebuie sã asculte permanent pentru comenzile de anulare sau pentru

modificãrile de context (R2)� Prezintã utilizatorului informaþiile de feedback despre progresul procesului de

anulare (R4, R14, R15) Active Command

� Tip: model� Culege permanent informaþii (R3)� Trateazã anularea prin terminarea proceselor ºi restaurarea stãrii ºi

resurselor(R5, R8, R11) �� Trimite feedback corespunzãtor cãtre utilizator (R12, R14, R15)



Soluþia specificã

Diagrama de secvenþe a activitãþilor anterioare lansãrii comenzii de anulare.


:View :Controller Active-Command:Model



:User

normal operation

invokeregister (R3)

save current state (R3)

normal operation


Soluþia specificã

Diagrama de secvenþe a activitãþilor de dupã lansarea comenzii de anulare.


command (R4)

:View Listener :Controller

Active-Command :Model

Prior-State-Manager :Model

Cancellation-Manager :Model

press cancel

button (R1) send cancel request (R1, R2) cancel active

command (R2)

change cursor shape (R14)

acknowledge user�s

estimates canceltime between

1 and 10 secs(R14, busy cursor

needed)are you alive? (R5)

yes (R5)

return original state (R9)

original state (R9)

release resources (R11)

exiting R15)

xrestore cursor (R15)

:User


ªabloane arhitecturale suport pentru utilizabilitate (USAP) similare cu Cancel

Undo Similaritate ��(VWH�QHFHVDUă�UHYHQLUHD�OD�R�VWDUH�DQWHULRDUă�FXQRVFXWă. Diferenþã � �Undo��VH�H[HFXWă�GRDU�GXSă�WHUPLQDUHD�FRPHQ]LL. În acest caz nu

este necesarã operaþia de ascultare permanentã.

Recuperarea din defecte Similaritate � Nu se poate prezice momentul apariþiei. Diferenþã ��1X�VH�DIOă�VXE�FRQWUROXO�XWLOL]DWRUXOXL�LDU�GHUXODUHD�înapoi se face

cât mai puþin posibil (nu neaparat pânã la starea de dinaintea lansãrii ultimei

comenzi).


ªabloane arhitecturale suport pentru utilizabilitate (USAP) Concluzii

Separarea UI de logica aplicaþiei ��SUDFWLFă�FXUHQWă�în proiectarea software-lui.

Este suportatã proiectarea iterativã a UI, dar sunt introduse probleme de utilizabilitate sensibile din punct de vedere arhitectural.

Aceste probleme apar, în general, în cazul cerinþelor de utilizabilitate care traverseazã componentele separate.

ªabloanele arhitecturale suport pentru utilizabilitate (USAP) sunt o abordare pentru soluþionarea problemelor de utilizabilitate sensibile din punct de vedere arhitectural.


BIBLIOGRAFIE

Bass L., John B.E, Kates J., Achieving Usability Through Software Architecture, Technical Report CMU/SEI-2001-TR-005, 2001

Stoll P., Bass L., John B.E., Usability and Software Architecture, SATURN May 2009, Pittsburg, US

www.automationworld.com/control/abb-product-architecture-supports-usability

Lee J., Bass L., Elements of Usability Reasoning Framework, Technical Note CMU/SEI-2005-TN-030, 2005

http://www.automationworld.com/control/abb-product-architecture-supports-usability



Curs 13




1. Cerinþele pentru atributele de calitate sunt elementele fundamentale de dirijare�D�SURLHFWăULL�XQHL�DUKLWHFWXUL�VRIWZDUH.


DAR existã:









PLAN CURS




Un exemplu de USAP


Utilizabilitate

Def. Utilizabilitate = mãsura calitãþii experimentate de utilizator în interacþiunea cu informaþii sau servicii.

Chiar dacã funcþionalitatea este corectã,

Chiar dacã UI este separatã de funcþionalitate,

Deciziile arhitecturale realizate iniþial pot împiedica implementarea unui sistem utilizabil.

E posibil ca o anumitã modificare solicitatã (de caracteristicã sau de funcþionalitate) în sensul creºterii utilizabilitãþii sã ajungã prea adânc în arhitectura sistemului pentru a permite realizarea ei viabilã din punct de vedere economic ºi de timp.


Utilizabilitate � exemple de scenarii generale

Feedback warning/status/alert

�Se vor afiºa indicatori de stare sau de alertã când sunt satisfãcute condiþiile corespunzãtoare.�

Profil utilizator

�Fiecare utilizator trebuie sã poatã seta diferiþi parametrii care controleazã

prezentarea.�

Agregare comenzi

�Utilizatorul trebuie sã poatã invoca executarea unei colecþii de comenzi.�

Recuperarea din avarie

�La cãderea sistemului, procesorului sau reþelei, utilizatorul nu trebuie sã piardã

starea curentã.�

Suport pentru internaþionalizare

�Utilizatorul trebuie sã poatã folosi un limbaj ºi un format de afiºare care îi este familiar.�


Obiective curs

Înþelegerea principiilor de bazã ale arhitecturilor software pentru sisteme interactive.

Înþelegerea modului în care aceste principii afecteazã utilizabilitatea�VLVWHPXOXL.

Motivul utilizãrii de ºabloane bazate pe separare.

Cazuri în care ºabloanele bazate pe separare nu sunt suficiente.


Practici obiºnuite în proiectarea de detaliu a sistemelor interactive

Toate tehnicile HCI (Human Computer Interaction) suport pentru proiectarea de detaliu a interfeþei utilizator sunt bazate pe proiectare iterativã.

(i.e proiectare, testare (analizã sau mãsurare), modificare, re-testare)

Odatã ce software-ul a fost dezvoltat, iterarea implicã modificãri ale acestuia.

Inginerii software pregãtesc realizarea acestor modificãri prin izolarea secþiunii ce va fi modificatã (separare).


PLAN CURS




Un exemplu de USAP


ªabloane arhitecturale pentru utilizabilitatebazate pe separabilitate

MVC (Model-View-Controller) (1980, Smalltalk)

Adaptat pentru context web pe platforma Java EE de la Sun

Recomandat de Microsoft pentru .NET

Documentat în Buschmann (Pattern-Oriented Software Architecture, vol 1)

PAC (Presentation-Abstraction-Control) (1980 � univ. Din Grenoble)

Reacþie la dezavantajele MVC

Utilizate curent în practicã, cu succes dovedit.


MVC

Orientat obiect

Model � starea ºi funcþionalitatea aplicaþiei(operaþii).

View ��UHGă�PRGHOH�ºi trimite gesturile utilizatorului la controller.

Controller ��DFWXDOL]HD]ă�modelul, selecteazã vedere, defineºte comportamentul aplicaþiei (interacþiuni, flux).

Command Processor

Command Processor

ModelCommand Processor

Command Processor

View

Controller

Dispozitiv de intrare

Dispozitiv de ieºire


MVC

Avantaje

Suport pentru vederi multiple asupra aceloraºi date

� Utilizatorul are perspective multiple asupra aceloraºi date (ex. vederi de tip outline ºi de tip layout)

� Diferite dispozitive prezintã aceleaºi informaþii în moduri corespunzãtoare

platformelor pe care se aflã (ex. PDA, laptop)

� Diferiþi utilizatori au acces simultan la aceleaºi date

Separare prezentare (view) de aplicaþie �SHUPLWH�UHDOL]DUHD�GH�PRGLILFăUL�DOH�prezentãrii independent de restul aplicaþiei.


ªabloane bazate pe separare

Larg utilizate în practicã.

Suport pentru dezvoltarea de instrumente specializate

Biblioteci de widget-uri

Diferite tipuri de controller-e

Separarea prezentãrii de aplicaþie este foarte importantã.

DAR ºabloanele bazate pe separare nu sunt suficiente pentru sistemeleinteractive.


ªabloane bazate pe separare ºi proiectarea iterativã

Cerinþe revelate pe parcursul proiectãrii iterative:

Modificãri ale funcþionalitãþii

Modificãri ale UI referitoare la conþinutul ecranelor

Modificãri ale UI dincolo de conþinutul ecranului

Zona de modificãri dificil de realizat

Modificãri facilitate de

arhitectura software

Cerinþe descoperite pe parcursul proiectãrii

iterative



Modificare asupra caracteristicilor afiºãrii modificare view : view conþine toatã

logica de afiºare.

Ex. Modificare culori, font, aºezare în paginã (layout).

Modificare la fluxul prezentãrii modificare controller : controller-ul defineºte fluxul prezentãrii.

Ex. Modificarea ordinii dialogurilor.



Adãugarea abilitãþii de a anula o comandã cu duratã mare de execuþie.

Modificari la toate componentele arhitecturii:

� View ��EXWRQ�&DQFHO�VDX�DOWă�PRGDOLWDWH�GH�D�FRPDQGD�DQXODUHD�

� Controller ��ORJLFD�GH�UăVSXQV�OD�FRPDQGă�ºi de executare a funcþiei corespunzãtoare

� Model � modul de alocare a resurselor, ...

Probleme:

� Implicã toate componentele arhitecturii

� Localizare slabã

� Dacã cerinþa apare târziu,�YD�QHFHVLWD�PRGLILFăUL�FRQVLGHUDELOH�DOH�DUKLWHFWXULL


Concluzii

Proiectarea de detaliu a interfeþei utilizator se bazeazã pe

abordare iterativã.

Proiectarea iterativã este suportatã de ºabloanele bazate pe separare.

Unele probleme de utilizabilitate implicã mai multe componente de diferite tipuri ale ºabloanelor bazate pe separare.


PLAN CURS




Un exemplu de USAP


ªabloane arhitecturale suport pentru utilizabilitate(USAP � Usability Supporting Architectural Patterns)

Obiectiv � recunoaºterea ºi prevenirea problemelor obiºnuite de utilizabilitate care nu sunt suportate de principiul separãrii.

Soluþie - USAP:

Identificarea aspectelor de utilizabilitate care sunt sensibile din punct de vedere arhitectural ºi reprezentarea lor cu scenarii simple.

Oferirea unui mod de analizã a forþelor ce acþioneazã, în aceste scenarii, asupra arhitecturii proiectate.

Oferirea unei liste de verificare�D�UHVSRQVDELOLWăþilor software importante.

Oferirea de ºabloane arhitecturale�FX�SRVLELOLWăþi de satisfacere a acestor scenarii.



Sensibilitate din punct de vedere arhitectural

Un scenariu de utilizabilitate este considerat sensibil din punct de vedere arhitectural dacã

satisfacerea acestuia poate necesita modificãri la arhitectura sistemului.

Într-un ºablon bazat pe separare, aceasta înseamnã cã implementarea modificãrii va avea

impact atât asupra prezentãrii cât ºi asupra abstractizãrii (modelului).

ªabloanele bazate pe separare sunt destinate localizãrii modificãrilor referitoare la prezentarea informaþiilor.

Rezultã - exemplu:

� Modificãri de culori ºi font ��QX�VXQW�VHQVLELOH�GLQ�SXQFW�GH�YHGHUH�DUKLWHFWXUDO

� Adãugarea opþiunii de anulare (Cancel) ��HVWH�VHQVLELOă�GLQ�SXQFW�GH�YHGHUH�DUKLWHFWXUDO.



Scenariu de utilizabilitate sensibil din punct de vedere arhitectural - exemplu.

Anulare comenzi

�Utilizatorul trimite o comandã, apoi se rãzgândeºte dorind oprirea operaþiei ºi revenirea sistemului la starea dinaintea lansãrii comenzii. Nu conteazã motivul

utilizatorului: poate fi o greºealã a sa, poate fi din cauzã cã sistemul nu

rãspunde la comandã, sau poate s-a modificat contextul.�



Exemple de modificãri sensibile din punct de vedere arhitectural.

Agregarea datelor Agregarea comenzilor Alerte Anulare comenzi Verificarea corectitudinii Evaluarea sistemului Validare formã/câmp

Jurnalizare istoric Menþinerea independenþei dispozitivelor

(diferite metode de acces) Menþinerea compatibilitãþii cu alte sisteme Accesibilizarea vederilor Modificarea interfeþelor Navigarea în cadrul unei singure vederi Observarea stãrii sistemului

Operare consistentã la traversarea vederilor

Feedback al progresului Help performant (Context-Sensitive Help)

Recuperarea din defecte Reutilizare informaþii Extragere parole uitate Indicare stare Suport pentru cãutãri extensive

Suport pentru internaþionalizare(diferite limbi)

Suport pentru activitãþi multiple Suport pentru Undo Suport pentru personalizare

(profil utilizator) Suport pentru vizualizare Tur Utilizare concurentã

(Multi-tasking) Verificare resurse Wizard Model�DO�IOX[XOXL�GH�DFWLYLWăþi Lucru în ritmul utilizatorului Lucru în context nefamiliar



Echipa de dezvoltare:

Ingineri software

Specialiºti în utilizabilitate

Manager proiect

Scenariile de utilizabilitate sensibile din punct de vedere arhitectural sunt surse de cerinþe, deci

Trebuie sã fie concrete

Trebuie sã fie eficace pentru un sistem particular.