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

Site curs:
https://sites.google.com/site/arhswcm
Arhitecturi pentru sisteme software

Curs 1
Cristina Mndru
Slide 1
Arhitecturi software - exemple
Cristina Mndru
Slide 2
Cristina Mndru
Slide 3
Cristina Mndru
Slide 4
Cristina Mndru
Slide 5
Cristina Mndru
Slide 6
Cristina Mndru
Slide 7
Cristina Mndru
Slide 8
Concluzie
Probleme ale descrierilor naive ale arhitecturii software
Text informal i diagrame de tip box-and-lines.
Intuitive
Precizie slab
Rareori formalizat
O soluie : Dezvoltarea ARHITECTURAL a sistemelor software i

descrierea formal a structurii acestora.
Cristina Mndru
Slide 9
Dezvoltarea arhitectural a sistemelor software
Compunerea sistemelor din pri componente.
Asigurarea conformitii sistemului cu arhitectura i cu
proprietile dorite.
Utilizare arhitecturi standard pentru integrare.
Reutilizare.
Reducere costuri utiliznd linii de produse.
Cristina Mndru
Slide 10
Dezvoltarea arhitectural a sistemelor software
Compunerea sistemelor din pri componente.
Asigurarea conformitii sistemului cu arhitectura i cu
proprietile dorite.
Utilizare arhitecturi standard pentru integrare.
Reutilizare.
Reducere costuri utiliznd linii de produse.
Cristina Mndru
Slide 11
PLAN CURS
Obiectivele cursului
Definiia i rolul arhitecturii software
Evoluia domeniului
Arhitectura software n context
Impactul arhitecturii software
Relaiile de influen ale arhitecturii software
Rolul i calitile arhitectului software
Cristina Mndru
Slide 12
Obiectivele cursului - 1
Rolul arhitecturii software n procesul de dezvoltare a software-lui.
Recunoaterea principalelor stiluri i abloane arhitecturale.
Descrierea cerinelor astfel nct arhitectura s poat fi evaluat.
nelegerea principiilor unei bune documentaii arhitecturale.
nelegerea modului de incorporare a COTS i middleware n

proiectele arhitecturale.
Generarea de alternative arhitecturale pentru o problem i

alegerea uneia dintre ele.
Cristina Mndru
Slide 13
Obiectivele cursului - 2
Proiectarea i construirea unui sistem de dimensiuni medii care

satisface o specificaie arhitectural
nelegerea modului n care notaiile formale pot fi utilizate

pentru a specifica arhitecturi.
Evaluarea adecvrii unei arhitecturi date n ndeplinirea unui

set de cerine sistem i echilibrarea compromisurilor asupra
calitii.
Cunoaterea tendinelor de viitor n domeniul arhitecturilor

software.
Cristina Mndru
Slide 14
PLAN CURS
Evoluia domeniului
Cristina Mndru
Slide 15
Arhitectur software - Definiie

Definiii la:
http://www.sei.cmu.edu/architecture/start/definitions.cfm
Definiia adoptat la acest curs:
Arhitectura software a unui sistem de calcul este setul structurilor

unui sistem necesare pentru a realiza raionamente referitoare la
acesta, structuri coninnd elementele software, relaiile dintre
acestea i proprietile vizibile din exterior ale ambelor.
Clements, Bachmann, Bass, Garlan, Ivers, Little, Nord, Stafford, Documenting Software
Architectures: Views and Beyond, Addison Wesley Longman, 2010
Cristina Mndru
Slide 16
Proiectare arhitectural
Elemente ale modelului analiz

Informaii despre domeniul aplicaiei
abloane i stiluri arhitecturale existente
PROIECTARE ARHITECTURAL
Arhitectura aplicaiei
= Perspectiv general asupra software-lui.
Cristina Mndru
Slide 17
Locul i rolul arhitecturii software

Proiect de nivel superior al sistemului
Abstractizri la nivel de sistem
Modele reutilizabile la nivel de sistem
Rspunde cerinelor de comportament i de calitate
Cristina Mndru
Slide 18
Importana arhitecturii software

Reducerea costurilor de dezvoltare i de mentenan
clarificarea structurii sistemului pe diferite nivele
reutilizare
Creterea calitii produsului software
clarificarea cerinelor
explicitarea deciziilor, realizate pe baz de principii, i a

implicaiilor lor
analize la nivel de sistem
analiza precoce a problemelor de proiectare
Cristina Mndru
Slide 19
Importana arhitecturii software reducerea costurilor

de mentenan
Aproape 50% din efortul de mentenen este

investit n analiza i nelegerea codului i
documentaiei existente.
Cristina Mndru
Slide 20
Arhitectur software vs. programare

ARHITECTURA SOFTWARE
Interaciunile dintre prile

componente
PROGRAMAREA
ImplementareaSUilor
componente
Proprietile structurale
Proprietile computaionale
Declarativ
Operaional
n mare parte static
n mare parte dinamic
Performan la nivel de
sistem
vedereH[WHULRDUD
modulelor
Cristina Mndru
Performan la nivel de
algoritm
vedere interioar a
modulelor
Slide 21
PLAN CURS
Evoluia domeniului
Cristina Mndru
Slide 22
Evoluia 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
Cristina Mndru
Slide 23
Recunoaterea importanei arhitecilor n companiile de

dezvoltare de software
Procese software ce includ revizuiri ale arhitecturii i
documentaie arhitectural explicit
Utilizare de linii de produse, de standarde arhitecturale, de
cadre pentru integrare de componente
Codificarea vocabularului, notaii i instrumente pentru proiectare
arhitectural
Cri i cursuri de arhitecturi software
Cristina Mndru
Slide 24
ncorporarea notaiilor arhitecturale n principalele limbaje de

proiectare (ex. UML 2.0) i instrumente (ex. Software Architect
de la IBM)
MetodeED]DWHSHSURLHFWDUHDUKLWHFWXUDOi rafinarea acesteia
(ex. MDA Model Driven Architecture)
Unele instrumente pentru analizDUKLWHFWXUDO
Standarde arhitecturale pentru sisteme enterprise (ex. RM-ODP,
TOGAF)
Cristina Mndru
Slide 25
PLAN CURS
Evoluia domeniului
Cristina Mndru
Slide 26
Ingineria sistemelor
Ingineria sistemelor GLVFLSOLQGHSURLHFWDUHi management
pentru proiectarea i construirea de sisteme mari, complexe,
interdisciplinare.
Arhitectura sistemului element critic al ingineriei sistemelor:
Descrie elementele i interaciunile unui sistem complet precum

i contribuia acestora la scopul sistemului
Include identificarea i caracterizarea elementelor sistemului,

fr a descrie substructurile acestor elemente.
Cristina Mndru
Slide 27
Interese n proiectri arhitecturale

Nivel de abstractizare
Arhitectur enterprise
Arhitectur sistem
Arhitectur software
Proiect software nonarhitectural
Cristina Mndru
Interese cheie n proiectare

Procese business i modele operaionale
'DWHEXVLQHVV
6WUXFWXUi relaii organizaionale
3Uile interesate n afacere (stakeholders)
Infrastructura IT
Identificarea contextului sistemului

Partiionare (centrat pe Hw i infrastructur)
Identificarea cerinelor software
Cerinele funcionale generale ale sistemului
Integrare i testare la nivel de sistem
Identificarea atributelor de calitate

Cerinele funcionale pentru software
Partiionarea aplicaiilor software
Integrare i testare la nivel de software i de sistem
Caracteristicile limbajului
Eficiena algoritmilor
Proiectarea structurilor de date
Testarea aplicaiei software
Implementarea funcionalitii
Slide 28
Ierarhia proiectrii arhitecturale

Principii:
Interese diferite pe nivele diferite

Deciziile de pe nivelele superioare impun constrngeri nivelelor
inferioare
Nivelul superior transfer responsabilitatea detalieriiFWUH
nivelul inferior
Cristina Mndru
Slide 29
Ierarhia proiectrii arhitecturale

ENTERPRISE: procesul
business mapat pe o
infrastructur cu
granularitate mare.
SISTEM: Concentrare pe
cerinele funcionale
alocate elementelor fizice.
(sisteme de sisteme)
SOFTWARE: multidemnsional; satisfcnd

cerine funcionale i de calitate.
Deseori ortogonal n raport cu structurile
sistemului.
Critic n satisfacerea obiectivelor business.
Cristina Mndru
Slide 30
PLAN CURS
Evoluia domeniului
Cristina Mndru
Slide 31
Atributele de calitate (modificabilitate, disponibilitate,

performan, etc.) sunt dependente de design.
Gndirea arhitectural este gndire strategic.
O arhitectur software proiectat deliberat i bine documentat
ofer valoare proiectului i firmei ce dezvolt software-ul.
Cristina Mndru
Slide 32

Proiectul arhitectural i documentaia asociat:
servesc ca vehicol de comunicare
ghideaz deciziile iniiale de proiectare
reduc riscul
ajut la managementul proiectului/produsului
faciliteaz reutilizarea
Cristina Mndru
Slide 33

DocumentaiaDUKLWHFWXULLRIHUXQFDGUXGHUHIHULQ n care pot fi
expuse i negociate interese concurente.
Permite:
Negocierea cerinelor tuturor prilor interesate
Realizarea de informri asupra progresului
Alocare de resurse i ghidarea construirii produsului software
Documentaia trebuie s fie:
DESCRIPTIV -SHQWUXFRPXQLFDUH
PRESCRIPTIV - pentru proiectani i pentru

implementatori.
Servesc ca vehicol de comunicare
*KLGHD]GHFL]LLOHLQLiale de proiectare
5HGXFULVFXO
$MXWODPDQDJHPHQWXOSURLHFWXOXL/produsului
)DFLOLWHD]UHXWLOL]DUHD
Cristina Mndru
Slide 34

Arhitectura face trecerea de la specificarea cerinelor (ce?) la
ndeplinirea acestora (cum?).
Arhitectul poate prezice calitile sistemului prin studierea
abstractizrilor arhitecturale ale acestuia.
Deciziile arhitecturale influeneaz proprietile sistemului n

moduri cunoscute
Proiectul arhitectural poate fi analizat i utilizat pentru a prezice
n ce msur vor fi obinute proprietile ateptate de la sistem.
PERFORMAN HYLWDUHJkWXLUL, cuplare strns a

elementelor, limitareaFDQWLWii i frecvenei comunicrilor
distribuite i ntre elemente
MODIFICABILITATE FHQWUDUHSHUHVSRQVDELOLWile
elementelor, decuplareaHOHPHQWHORU, localizarea
responsabilitilor, minimizarea i simplificarea
dependenelor ntre elementele sistemului.
Cristina Mndru

5HGXFULVFXO
Slide 35

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
servete ca echipament de testare suport pentru
prototipare, integrare, testare precoce.

Reduc riscul
Cristina Mndru
Slide 36

Permite realizarea deHVWLPULPDLSUHFLVH ale costurilor i planului de timp.
Estimrile se bazeaz pe elementele arhitecturii

Echipa responsabil pentru un anume element ofer estimrile pentru acesta
Managerii de proiect integreaz estimrile i rezolv dependenele i
conflictele
Util n managementul modificrilor.
Permite prilor interesate s judece i s gestioneze modificrile la sistem

pe toat durata de via a acestuia (aprox. 80%GLQHIRUWDUHORFGXSGH]YROWDUHDi
punerea iniial n funciune a sistemului).
Arhitectura mparte modificrile n trei clase:
Locale un singur element

Non-locale mai multe elemente
Arhitecturale PRGLILFULODWRSRORJLDVLVWHPXOXLVDXODPHFDQLVPHOHGHFRPXQLcare
i coordonare.
Ofer nelegere i cunoatereSWUXQ]WRDUHGH-a lungul ntregului ciclu de

via al sistemului.
Reduc riscul
Cristina Mndru
Slide 37

Faciliteaz reutilizarea de elemente cu granularitate mare.
Exemple:
Componente (ex. baze de date, COTS)
Cadre de dezvoltare (ex. Java EE)
Linii de produsereutilizare strategic)

Obs.5HXWLOL]DUHDGHPRGXOHGHJUDQXODULWDWHPLFDUHXUPWRDUHOHGHzavantaje:
Este costisitor i dificil de gsit funciile, metodele sau procedurile cele mai
potrivite
Este dificil de determinat proprietile motenite n aceste module.

5HGXFULVFXO
Cristina Mndru
Slide 38
PLAN CURS
Evoluia domeniului
Cristina Mndru
Slide 39
Ciclul business al arhitecturii (ABC)
Relaiile dintre obiectivele afacerii, cerinele produsului,

experiena arhitectului, arhitecturi i sisteme formeaz un
ciclu.
Arhitectura software este influenat de o serie de factori.

Arhitectura software i sistemul dezvoltat pe baza ei influeneaz, la
rndul ei, aceti factori.
n centrul acestui ciclu st arhitectul software.
nelegerea i analiza acestui ciclu poate ajuta compania s-i

gestioneze afacerea, organizarea i arhitectura.
Cristina Mndru
Slide 40
ABC - Factorii ce influeneaz arhitectura software
Cristina Mndru
Prile interesate n sistem

Firma ce dezvolt sistemul
Contextul tehnologic
Cunotinele i experiena arhitectului
Slide 41

Stakeholder-i (clieni, utilizatori, dezvoltatori, manageri, personal de
ntreinere, 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 organizaionale i proprietile la nivelul business ale sistemului

sunt rareori nelese i cu att mai puin bine exprimate arhitectul
trebuie s joace un rol activ n identificarea i angajarea precoce a
stakeholder-ilor n ciclul de dezvoltare.
Cristina Mndru
Slide 42

Cristina Mndru
Slide 43

Clase de influene organizaionale:
Afacerea imediat
Firma poate avea o investiie n anumite bunuri, cum ar fi arhitecturi existente i

produsele bazate pe acestea.
Afacerea pe termen lung
Arhitectura poate fi nucleul unei investiii pe termen lung n infrastructur, pentru

ndeplinirea obiectivelor strategice ale firmei.
Structura organizaional
Structura organizaional poate modela arhitectura a.. diviziunile de funcionalitate

se aliniaz la unitile de expertiz existente.
Cristina Mndru
Slide 44

Contextul tehnologic existent n momentul elaborrii arhitecturii.
Include:
Limbaje
Instrumente
Sisteme de operare
Platforme de calcul
Cadre de implementare
Practici industriale standard i tehnici de inginerie software

Cristina Mndru
Slide 45

Arhitecii iau decizii de proiectare pe baza experienei lor.
Experienele reuite conduc la replicarea proiectelor care au mers bine

Experienele nereuite vor fi evitate n noile proiecte,FKLDUGDF
metodele, tehnicile i/sau tehnologiile ce au codus la acestea ar putea
funciona bine n alte proiecte
Alegerile pe care le face un arhitect sunt influenate de experiena, de
instruirea (training) i de educaia sa formal (n acest ordine!).

Cristina Mndru
Slide 46
ABC - Factorii influenai de arhitectura software

Arhitectura i sistemul dezvoltat
pe baza acesteia vor
influena:
Structura i obiectivele
firmei dezvoltatoare
Cerinele beneficiarilor
Experiena arhitectului
Tehnologia
Cristina Mndru
Slide 47

Arhitectul divizeaz sistemul n componente majore i uniti de
lucru.
Structura i obiectivele firmei dezvoltatoare
modeleaz firma prin partiionarea forei de munc
Tehnologia
ajut la stabilirea unui vocabular de comunicare
baz pentru WBS, utilizat n planificare,XUPULUHi bugetare
organizare n scopul gestionrii configuraiilor
organizare n scopul elaborrii documentaiei
baz pentru integrare i testare
Arhitectul definete elementele software ce trebuie implementate i

integrate. Acestea devin baz pentru:
alocare talente, recrutare, formare echip

activiti de dezvoltare, testare i integrare
estimare i alocare resurse
planuri de timp, bugete, urmrire proiect i supraveghere
Cristina Mndru
Slide 48

Arhitecturile pot influena obiectivele unei firme
deoarece:
Un sistem de succes construit pe baza unei anumite arhitecturi

poate permite unei companii s pun stpnire pe o anumit
zon de pia
Arhitectura poate oferi oportuniti pentru producere eficient i
punere n funciune de sisteme similare.

Tehnologia
Cristina Mndru
Slide 49

Pe baza cunotinelor despre sisteme similare clienii
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.
Clienii vor cere arhitecturi de calitate n sistemele viitoare

Pe baza cunotinelor despre sistemul dezvoltat clienii
i vor modifica
cerinele sistem n raport cu disponibilitii sistemelor
i elementelor existente.
Tehnologia
Cristina Mndru
Slide 50

Dezvoltarea unei arhitecturi mbogete experiena arhitectului.
Tehnologii, instrumente, metode ce au fost utilizate n

dezvoltarea de sisteme reuite conduc la crearea de sisteme
viitoare n aceeai manier.
Arhitectura unui sistem euat este evitat n proiecte viitoare.

Tehnologia
Cristina Mndru
Slide 51

Ocazional, un sistem sau o arhitectur vor modifica stadiul actual
al tehologiei.
Exemple:
generatoare de compilatoare
baze de date relaionale
foi de calcul
sisteme de operare cu interfee grafice
WWW
Java

Tehnologia
Cristina Mndru
Slide 52
PLAN CURS
Evoluia domeniului
Competenele, rolul i calitile arhitectului software
Cristina Mndru
Slide 53
Tehnologie
competene
nelegerea profund a
domeniului i tehnologiilor
pertinente
Posibilitatea de a decela
elementele tehologice care
reprezint cheia succesului
rol
caliti
Modelare
Creativ
Analiza compromisurilor
Capabil de investigaie
Practic/pragmatic
Patrunztor
Prototipare/experimentare/
simulare
Pregtirea documentelor i
prezentrilor arhitecturii
software
Metode de dezvoltare i
tehnici de modelare
Analiza tendinelor
tehnologice
Tolerant fa de ambiguiti,
dispus la reluri, n cutare
de soluii multiple
Capacitate de a lucra pe
nivel abstract
Un punct de vedere asupra

sistemului
Cristina Mndru
Slide 54
Consultan
competene
Tehnici de a obine i
provoca informaii
Metode cadru de
consultare
Cunosctor al proceselor
(business, software,
management)
rol
Crearea unei relaii de

ncredere n consultant
nelegerea a ceea ce
doresc i au nevoie
dezvoltatorii de la
arhitectur
caliti
Angajat n succesul altora
Empatic, abordabil
Practic/pragmatic
Agent de schimb eficient
Bun mentor
Ajut dezvoltatorii s vad

valoarea arhitecturii i s
neleag cum o pot utiliza
cu succes
Mentor pentru arhitecii

juniori
Cristina Mndru
Slide 55
Strategie
competene
rol
Strategia i raiunile
Influenarea strategiei
fundamentale ale companiei afacerii
Competitorii (produse,
strategii, procese)
caliti
Vizionar
Antreprenorial
Traducerea strategiei
afacerii n viziune i
strategie tehnic
Practica business a
companiei
nelegerea clientului i a
tendinelor din pia
Capturarea n arhitectur a
cerinelor clientului, a celor
organizaionale i a
cerinelor business
Cristina Mndru
Slide 56
Politici oganizaionale
competene
Care sunt juctorii cheie

n companie
rol
Comunicare
Ascultare, nod esenial n

reeaua de comunicare
interuman, exercitare de
influen.
Ce doresc acetia pe
planul afacerii i pe plan
personal
VnzareaXQHLYL]LXQL.
Pstrarea acesteia n via.
caliti
Abilitatea de a vedea din

puncte de vedere multiple i
de a exprima n puncte de
vedere multiple
ncreztor i clar/logic n
exprimare
Luarea periodic a pulsului

tuturor factorilor critici de
influen asupra proiectului
arhitectural.
Ambiios i hotart
Rbdtor (cu msur)
Rezistent i flexibil
Sensibil la localizarea i
fluxul puterii n cadrul
companiei
Cristina Mndru
Slide 57
Conducere
competene
Autocunoatere
rol
Stabilirea contextului echipei

(viziunea)
caliti
Vzut ca lider de ceilali dar

i de el nsui.
Luare de decizii i asumarea lor
Construire echipe
Motivare
Carismatic i credibil.
ncredere c se poate face

i c poate conduce efortul
respectiv .
Angajat, dedicat, pasionat.
Plasarea ntregului efort ntrun context mai larg, att al

afacerii ct i personal.
Cristina Mndru
Slide 58
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., PatternOriented Software Architecture. A System of Patterns, John Wiley & Sons, 1996
Cristina Mndru
Slide 59

Curs 2
Cristina Mndru
Slide 1
PLAN CURS
Analiza definiiei arhitecturii software
Tipuri de vederi (viewtypes), stiluri i vederi
Definiii
Perspectiva static
Perspectiva dinamic
Perspectiva alocrii
Concluzie
Limbajul Acme i instrumentul AcmeStudio
Cristina Mndru
Slide 2
Arhitectura software - definiie

Arhitectura software a unui sistem de calcul este
setul structurilor unui sistem
necesare pentru a realiza raionamente referitoare la acesta,
structuri coninnd elementele software,
relaiile dintre acestea i
proprietile vizibile din exterior ale ambelor.
Proiectarea i documentarea arhitecturii software sunt eseniale

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!!!
Cristina Mndru
Slide 3

Caracteristici ale arhitecturii software:
Abstractizare a sistemului.
PartiionareGHFODUDWLYi asignareGH
responsabiliti.
Definete elementele i modul n care sunt acestea
relaionate.
Suprim detaliile despre comportamentul intern i
despre informaiile locale ale elementelor.
Cristina Mndru
Slide 4
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
relaie cu el nsui.
Arhitectura ndeplinete cerinele funcionale i n acelai timp

promoveaz o serie de caliti ale sistemului (ex. performan,
flexibilitate, etc.).
Cristina Mndru
Slide 5

Abstractizare a structurilor reale ce compun sistemul software.
Structurile sunt reale

Reprezentrile lor sunt abstracte
Cristina Mndru
Slide 6

Tipuri de structuri software:
Structur static -FRG, apel metod/funcie,
Structur dinamic - proces/fire de execuie, flux de date,
Structur fizic - alocarea sistemului de fiiere, procesor, reea,

.
Cristina Mndru
Slide 7
Structur, perspectiv, vedere
STRUCTURI ale
sistemului OM
Un edificiu trebuie s aib trei caliti: durabilitate

(firmitas), utilitate (utilitas), estetic (venustas).
Marcus Vitruvius Pollio, De architectura
Cristina Mndru
Slide 8
Inima ca (sub)STRUCTUR
a aparatului circulator.
O vedere din perspectiv

dinamic
O vedere din perspectiv

static
Vedere (view) RUHSUH]HQWDUHDXQHLVWUXFWXUL,

vzut dintr-o anumit perspectiv.
Cristina Mndru
Slide 9

Perspectiva FIZIC
Vederi ale alocrilor la:
calculatoare
dispozitive
reele
Arhitectura software
Perspectiva STATIC
Vederi ale modulelor:
clase
funcii
interfee
Perspectiva DINAMIC
Vederi ale componentelor i
conectorilor:
procese
diagrame de secvene
flux de date
Cristina Mndru
Slide 10

Arhitectura sistemului permite raionamenteUHIHULWRDUHODVDWLVIDFHUHDGHFWUHVLVWHPD:
cerinelor de calitate
cerinelor de comportament
Deciziile arhitectului se reflect n structurile sistemului.
Rezult : deciziile arhitecturale sunt cele care permit sistemului s ndeplineasc cerinele
de calitate i comportament.
Cristina Mndru
Slide 11

Element parte a unui sistem.
Perspectiva
STATIC
Cristina Mndru
Tipuri de elemente
clase, fiiere, ...
DINAMIC
fire de execuie, flux de date, control, ...
FIZIC
pachete software, platforme software,...
Slide 12

Elementele interacioneaz prin interfee care mpart detaliile
elementelor n pri publice i pri private.
Aceste interaciuni formeaz relaiile dintre elementele arhitecturale.
Arhitectura se ocup doar cu partea public a acestei partiionri.
Cristina Mndru
Slide 13

Tipurile de relaii depind de tipurile de elemente, care depind la rndul lor de perspectiv.
Exemple:
uses
uses
Modul A
date
date
Proces X
Modul B
Proces Y
Modul C
Vedere din perspectiv STATIC

Elemente: module
Relaii: uses
Cristina Mndru
date
Vedere din perspectiv DINAMIC

Elemente: procese
Relaii: flux de date
Slide 14

Proprieti funcionale : responsabilitile elementelor, asignate n cursul proiectrii
arhitecturale.
Proprieti non-funcionale : cerinele de calitate pentru sistem i componentele sale.

Proprietile vizibile depind de perspectiva asupra sistemului.
Exemplu:
Perspectiv static PRGLILFDELOLWDWHD
Perspectiv dinamic - performana
Cristina Mndru
Slide 15
PLAN CURS
Definiii
Perspectiva static
Perspectiva dinamic
Perspectiva alocrii
Concluzie
Cristina Mndru
Slide 16
Tipuri de vederi, stiluri i vederi

Arhitectura software a unui sistem de calcul este setul structurilor unui sistem
necesare pentru a realiza raionamente referitoare la acesta, structuri
coninnd elementele software, relaiile dintre acestea i proprietile vizibile
din exterior ale ambelor.
ntr-o vedereDUKLWHFWXUDOHVWHreprezentatXQDQXPLWIHOGHVWUXFWXU
exemple:
Structura modulelor indicnd compoziia/decompoziia 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 execuiei, reprezentnd componentele i conectorii

dintre acestea.
Cristina Mndru
Slide 17
Tipuri de vederi i vederi

Vedere (view) = o reprezentare a unui (sub)set de elemente ale
sistemului i a relaiilor asociate cu acestea.
Vederea reprezint sistemul dintr-o anumit perspectiv.
Fiecare perspectivHVWHFDUDFWHUL]DWGHXQtip de vedere ce

definete tipuri de elemente i tipuri de relaii specifice.
O vedere este construit dintr-o anumit perspectiv, folosind tipul
de vedere corespunztor acesteia.
Cristina Mndru
Slide 18
Tipuri de vederi i vederi

Arhitectul software consider sistemul din trei perspective:
Perspectiva static modul n care sistemul este structurat ca set de

uniti de implementare (cod).
Vederile reprezint modulele sistemului. Tipul de vedere este Module
Viewtype.
Perspectiva dinamic modul n care sistemul este structurat ca set de

uniti de execuie (elemente ce au comportament i interaciuni la
momentul execuiei).
Vederile reprezint componentele sistemului i conectorii dintre acestea.
Tipul de vedere este C&C Viewtype.
Perspectiva alocrii modul n care sistemul se relaioneaz cu structurile

non-softwareGLQFRQWH[WXOVX.
Vederile reprezint modul de alocare a structurilor software pe structurile
non-software ale sistemului. Tipul de vedere este Allocation Viewtype.
Cristina Mndru
Slide 19
Stiluri
Stil arhitectural specializare pentru tipuri de elemente i de relaii,
mpreun cu un set de constrngeri referitoare la modul de
utilizare a acestora.
Motivaie:
Au fost observate forme ce se repet n sisteme diferite. Aceste forme au
proprieti 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
Cristina Mndru
Stiluri diferite pentru zone diferite ale sistemului.

Stiluri diferite pentru perspective diferite asupra sistemului.
Slide 20
Stiluri
Stil arhitectural specializare pentru tipuri de elemente i de relaii,
mpreun cu un set de constrngeri referitoare la modul de
utilizare a acestora.
Stil arhitectural poate defini:
Restricii asupra elementelor
Tipuri de relaii ntre elemente
Modaliti de utilizare a elementelor
Modaliti de configurare a elementelor
Cristina Mndru
Slide 21
PLAN CURS
Definiii
Perspectiva static
Perspectiva dinamic
Perspectiva alocrii
Concluzie
Cristina Mndru
Slide 22
Perspectiva static Module Viewtype

Tip de element :
modul unitate de cod ce implementeaz un set de

responsabiliti.
Tipuri de relaii :
is part of relaia parte-ntreg
depends on relaia de dependen
is a relaia de specializare/generalizare
Cristina Mndru
Slide 23

UTILITATE
Construire :
Modulele sunt asignate echipelor n vederea implementrii.
Deseori modulele sunt uniti pentru proiectarea ulterioar (ex.

pentru proiectarea de interfee).
Analiz :
Trasabilitatea i analiza impactului modificrilor se bazeaz pe

unitile de implementare.
Managementul proiectului, bugetarea, planificarea i

monitorizarea utilizeaz frecvent aceste module.
Cristina Mndru
Slide 24

NOTAII
Informale : box-and-lines, cu ncuibare
UML : diagrame de clase
Cristina Mndru
Slide 25

STILURI
Stilul de descompunere
descompunerea (ierarhic) n module
suport dezvoltare concurent
Stilul de generalizare
ierarhie a specializrii
suport reutilizare; gestionarea unui numr mare de definiii
Stilul stratificat (layered) :
maini virtuale
suport portabilitate, reutilizare
Cristina Mndru
STILURI
Descompunere
Generalizare
Stratificare
Slide 26
STILURI
Descompunere
Generalizare
Stratificare
Tip elemente : modul

Tip relaii : is part of
Criterii de descompunere :
Obinerea modificabilitii
Construire vs. Cumprare
Linii de produse
Utilitate :
Punct de pornire. Modulelor le sunt asignate responsabiliti.
Analiza modificare/impact
Baz pentru asignare de sarcini de lucru pentru membrii echipei de

dezvoltare.
Cristina Mndru
Slide 27

NOTAII
Informal :
box-and-lines, ncuibate
schi textual
tabel
STILURI
Descompunere
Generalizare
Stratificare
UML :
Diagrama de clase cu relaia de compoziie
Diagrama de pachete
Cristina Mndru
Slide 28

Exemplu
Cristina Mndru
STILURI
Descompunere
Generalizare
Stratificare
Slide 29
STILURI
Descompunere
Generalizare
Stratificare
Tip elemente : modul

Tip relaii : is a
Proprieti :
motenire interfa
motenire implementare
Utilitate :
baz pentru proiectarea OO
baz pentru evoluie i extindere
reutilizare
Cristina Mndru
Slide 30

NOTAII
Formal :
Limbaje de programare
UML
Cristina Mndru
STILURI
Descompunere
Generalizare
Stratificare
Slide 31
Tipuri elemente : straturi (nivele), main virtual
STILURI
Descompunere
Generalizare
Stratificare
Tip relaii : allowed-to-use (specializare a relaiei depends-on)
Reguli (variante multiple):
Fiecare element software aparine 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

acelai nivel.
Cristina Mndru
Slide 32

STILURI
Descompunere
Generalizare
Stratificare
Utilitate :
Portabilitate
Dezvoltare incremental
Separare de probleme (concerns)
Variaii:
Nivele segmentate:
divizare nivel n segmente (sau submodule)

i precizarea relaiei allow-to-use la nivel de segment,
pentru segmente de pe acelai nivel
i segmente de pe nivele diferite.
Cristina Mndru
Slide 33

NOTAII
Informale : dreptunghiuri i sgei, stiv de
dreptunghiuri, inele concentrice.
STILURI
Descompunere
Generalizare
Stratificare
Cristina Mndru
Slide 34
PLAN CURS
Definiii
Perspectiva static
Perspectiva dinamic
Perspectiva alocrii
Concluzie
Cristina Mndru
Slide 35
Perspectiva dinamic
Component-and-connector (C&C) Viewtype
Tipuri de elemente :
component = unitate de calcul i/sau memorare date pe

timpul execuiei; accesibil prin porturi.
conector = mecanism de interaciune; definete roluri.
Tipuri de relaii :
attachment ataare port al componentei la rol al

conectorului
Proprieti : informaii pentru construire i pentru analiz
Atribute de calitate VXSRUWSHQWUXDQDOL]
Altele funcie de stil
Cristina Mndru
Slide 36
Perspectiva dinamic C&C Viewtype

UTILITATE
La construire
Definete sistemul din perspectiv dinamic (n timpul execuiei)

determinnd
comportamentul ce trebuie construit,
cile de interaciune
mecanismele de comunicare.
La analiz
Model pe baza cruia se analizeaz proprietile (emergente) ale

sistemului (disponibilitatea, performana, securitatea, ncrederea, etc.).
Cristina Mndru
Slide 37

NOTAII
Informale : box-and-lines
UML : diagrama de componente
Acme (AcmeStudio) :
Cristina Mndru
Slide 38

STILURI (exemple fundamentale)
Data Flow
Pipe&filters (Reea de flux de date)
Call-and-return
Client - Server
Peer-to-Peer
Service Oriented Architecture
Event-based
Publish-Subscribe
Repository
Cristina Mndru
Blackboard
Slide 39
PROBLEME TRANSVERSALE
corelate n mod similar cu mai multe stiluri
extind stilurile fundamentale genernd variante ale acestora
Procese comunicante
Trepte (tiers)
Reconfigurare dinamic
Cristina Mndru
Slide 40
PLAN CURS
Definiii
Perspectiva static
Perspectiva dinamic
Perspectiva alocrii
Concluzie
Cristina Mndru
Slide 41
Perspectiva alocrii
Allocation Viewtype
Elemente software = definite n perspectiva static sau n cea

dinamic.
Elemente din context (infrastructur)
Tipuri de relaii :
allocated-to repartizare element software pe element (nonsoftware) din context.
Cristina Mndru
Slide 42
Perspectiva alocrii Allocation Viewtype

UTILITATE
La construire
Definete modul de repartizare a elementelor software ale aplicaiei pe

elementele infrastructurii (n general, non-software)
Pe infrastructura hw/sw
Pe membrii echipelor de dezvoltare i de ntreinere
La analiz
Model de integrare a arhitecturii software n context.
Cristina Mndru
Slide 43

NOTAII
Informale
Cristina Mndru
UML : diagrama de repartizare (deployment)
Slide 44

STILURI
Stilul repartizrii
Alocarea elementelor software la modulele infrastructurii de procesare i de
comunicare
Exemple de proprieti :FHOHQHFHVDUHFDOFXOULL(i obinerii) performanei i disponibilitii
Stilul implementrii
Alocarea elementelor software la structuri din sistemele de fiiere al mediilor de
dezvoltare
Exemple de proprieti : fiiere i capaciti
Stilul de alocare a lucrului

Alocarea elementelor software la unitile de lucru din compania de dezvoltare
Exemple de proprieti : seturi de competene
Cristina Mndru
Slide 45
PLAN CURS
Definiii
Perspectiva static
Perspectiva dinamic
Perspectiva alocrii
Concluzie
Cristina Mndru
Slide 46
Concluzie
Sistemele combinaii de stiluri
Ex. Tiers-repository-events
Este necesar nelegerea stilurilor pure, ce constituie blocurile constructive
Regul : nu amestecai stiluri din tipuri diferite de vederi
Cristina Mndru
Creaz confuzie (Ex: layers i tiers)

Slide 47
Exemplu Test Parsing System

Perspectiva static
Stilul de descompunere
Cristina Mndru
Slide 48

Perspectiva dinamic
Vedere C&C
Cristina Mndru
Slide 49

Perspectiva alocrii
Stilul implementrii
Cristina Mndru
Slide 50
PLAN CURS
Definiii
Perspectiva static
Perspectiva dinamic
Perspectiva alocrii
Concluzie
Cristina Mndru
Slide 51
Perspectiva dinamic
Descompunerea (general) sistemului n componente ce

interacioneaz la execuie
Utilizare abstractizri globale pentru conectare componente
Analiza proprietilor emergente ale sistemului
performan, rat de transfer, ntrzieri, ...
fiabilitate, securitate, toleran la defecte, modificabilitate

dinamic, ...
Cristina Mndru
Slide 52
Perspectiva dinamic
Vedere C&C include:
Componente: definesc locaiile de realizare a calculelor

Exemple: filtre, baze de date, obiecte, tipuri de date abstracte.
Conectori: definesc interaciunile dintre componente

Exemple: apel de procedur, conduct (pipe), anunare eveniment.
Stil arhitectural C&C - definete o familie de arhitecturi prin:
Cristina Mndru
Tipuri de componente i conectori (vocabular)

Constrngeri topologice
Constrngeri semantice
Slide 53
Descriere arhitecturi
Exemple de limbaje (ADLs)
Rapide: evenimente cu simulare i animaie
UniCon: accent pe eterogenitate i compilare
Wright: spacificaii 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
Cristina Mndru
Slide 54
Acme limbaj reprezentativ
ncearc s ofere o abordare deschis (open-ended) pentru

reprezentarea arhitecturii
XML pentru arhitectur
Descriere structur + permite adnotri
Poate fi consumat selectiv de diferite instrumente
Cristina Mndru
Slide 55
Acme ENTITILE DE PRIM RANG
Component element computaional
Port punct de interfa pentru component
Conector interaciune ntre componente
Rol punct de interfa pentru conector
Sistem graf de componente i conectori
Exemplu sistem client-server
Cristina Mndru
Slide 56
Acme 35235,(7I
Descriu caracteristici nestructurale ale elementelor
Detalii de interfa (ex. servicii solicitate, servicii oferite)
Proprieti locale ale componentelor sau conectorilor (ex. viteze, capaciti,
ntrzieri)
Atribute de calitateproprieti emergente la nivelul sistemului) (ex.
performan, fiabilitate, securitate)
Comportament (ex. calcule executate de componente, protocoale pentru
conectori)
Constrngeri (ex. restricii topologice, restricii asupra proprietilor)
Cristina Mndru
Slide 57
Acme 35235,(7I
ReprezentareSURSULHWi DGQRWULFXSHUHFKLDWULEXW-valoare
Proprietile sunt tipate categorii de tipuri:
Built-in : int, boolean, string, etc
Constructori : set, record, enumeration, sequence
Definite de utilizator
Cristina Mndru
Slide 58
Acme 5(35(=(175,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
Cristina Mndru
Slide 59
Acme 5(35(=(175,i ABSTRACTION MAPS
System
Unui element Acme i se pot asocia

mai multe reprezentri.
Abstraction Map VSHFLILFDUH

legturi
LQWHULRUXO-H[WHULRUXO
reprezentrii
port intern - port extern

(la componente)
...
...
...
...
Abstraction
Map
System
(sub-architecture)
Component Representation
Cristina Mndru
Slide 60
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, ...)
Set de constrngeri
Restricii de utilizare corect a tipurilor
Set de vizualizri
Definirea vocabularului asociat stilului

Definirea structurii cerut fiecrui element
Modul de afiare a elementelor stilului
Set de analize
Cristina Mndru
Ce se poate deduce despre o anumit arhitectur

Slide 61
Definire tip element
<categorie> Type <nume-tip> = <declaraie-tip>
Exemplu
Definire subtip element

<categorie> Type <nume-tip> = <nume-tip>
extended with <declaraie-tip>
Exemplu
Cristina Mndru
Slide 62
Definire tip proprietate se pot utiliza tipuri predefinite i tipuri compuse
Property Type <nume-tip> = <declaraie-tip>
Exemple
Exemplu de utilizare tip de proprietate :
Cristina Mndru
Slide 63
Definiie familie (stil arhitectural) = colecie de definiii de tip.
Exemplu :
Exemplu de utilizare :
Cristina Mndru
Slide 64
Acme CONSTRNGERI
Restricii de combinare a elementelor

Definite prin predicate
Valori : true/false
Variaie a First Order Predicate Logic
Extins cu primitive pentru arhitectur

Modelat conform OCL (de la UML)
Se pot ataa 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 relaii i constrngeri.
Cristina Mndru
Slide 65
Acme CONSTRNGERI
Categorii principale :
Invariant WUHEXLHVDWLVIFXWSHQWUXFDVLVWHPXOVILHOHJDO.
Ex. Nu se accept bucle n graful C&C.
Euristic SURGXFHDYHUWL]ULGDFQXHVDWLVIFXW.
Ex. Nu se accept mai mult de 5 clieni pentru un server.
Exemplu:
Cerin : Stabilirea unui invariant care s impun ca fiecare client s fie conectat la
un server.
Soluie : ataarea urmtorului invariant la familia client-server
Invariant
forall c : ClientT in self.components
| exists s : ServerT in self.components
| connected (c,s);
Cristina Mndru
Slide 66
Definiie familie (stil arhitectural) = colecie de definiii de tipFRPSOHWDWFX
definiii de constrngeri.
Cristina Mndru
Slide 67
AcmeStudio instrument software construit peste Eclipse.
Cristina Mndru
Slide 68

Curs 3
Cristina Mndru
Slide 1
PLAN CURS
Elementele care dirijeaz definirea arhitecturii

Exprimri tipice pentru cerine referitoare la atributele de
calitate
O metod mai bun pentru exprimarea cerinelor pentru
atribute de calitate
O metod pentru descoperirea cerinelor pentru atribute de
calitate
Cristina Mndru
Slide 2
Elementele care dirijeaz arhitectura

Elementele care dirijeaz definirea arhitecturi sunt date de cerinele
ce stau la baza proiectrii arhitecturii software.
Cerinele
funcionale
Arhitectura
software
Atributele de
calitate
Constrngerile
Cristina Mndru
Slide 3
Cerinele funcionale
Cerinele funcionale descriu CE trebuie s fac sistemul.

La nivelul proiectrii arhitecturale se stabilesc funciile de
nivel nalt (nu detaliile).
Pe msur ce arhitectura este creat i rafinat, vom afla
mai multe informaii despre cerinele funcionale de
detaliu.
Cristina Mndru
Slide 4
Constrngerile
Constrngerile reprezint decizii de proiectare pre-fabricate.
Constrngeri tehnice (directe).
Constrngeri impuse de nivelul business, de pia, i/sau de companie

(indirecte).
Uneori pot apare constrngeri impuse de proiectant.

Exemplu: Pentru persistena datelor se va utiliza oED]GHGDWH.
Orice selecie/decizie devine o constrngere

pentru activitatea ulterioar de proiectare.
Cristina Mndru
Slide 5
Constrngeri business
Exemple de constrngeri business cu impact arhitectural:
Piaa int i timpul de lansare pe pia
Ateptrile referitoare la costuri i la beneficii
Planul de furnizare incremental
Durata de via proiectat pentru sistem
Disponibilitatea forei 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 investiiilor
Cristina Mndru
Slide 6
Constrngerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce ngrdesc
spaiul de proiectare.
EXEMPLE:
Utilizarea i/sau integrarea cu sisteme legacy
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Dei originile constrngerilor sunt diferite, toate vor avea impact

(mai mult sau mai puin) asupra deciziilor arhitecturale iniiale.
Cristina Mndru
Slide 7
Atribute de calitate
Cerinele funcionale descriu ceea ce trebuie s fac sistemul.

Cerinele non-functionale reprezint tot ceea ce nu este legat
de funcionalitatea sistemului, cum ar fi modificabilitate,
performan, etc.
Termenul cerine non-funcionaleLQWURGXFHRIDOV
partiionare, deoarece nu se pot descrie atributele de calitate
fr a descrie funcionalitatea sistemului.
Cristina Mndru
Slide 8
Def. Atribute de calitate -FDUDFWHULVWLFLSHFDUHVLVWHPXOWUHEXLHV
le posede n plus fa de funcionalitatea sa.
Reprezint elementele de dirijare a arhitecturii software care

sunt cel mai greu de descoperit, de exprimat i de testat.
Atributele de calitate i constrngerile sunt preponderente fa
de funcionalitate n dirijarea definirii structurii arhitecturale.
Cristina Mndru
Slide 9
Atributele de calitate i arhitectura

Deciziile arhitecturale
implementeaz funcionalitatea,
ndeplinesc constrngerile,
promoveaz unele atribute de calitate
inhib alte atribute de calitate.
Arhitectura este element critic n realizarea atributelor de calitate.
O modificare n arhitectur care mbuntete 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 actualizri la un sistem software.
Cristina Mndru
Slide 10
PLAN CURS

calitate
calitate
Cristina Mndru
Slide 11
Descrieri tipice pentru cerine de sistem
Timpul de rspuns al sistemului pentru orice aciune va fi mai mic de 0.5 sec
Funciile 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 nct s fie minimizate sau
eliminate posibilitatea i impactul cderii serverului. Disponibilitatea i
funcionalitatea staiilor client trebuie meninut pe timpul cderii serverelor sau
a altor clieni.
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 cderile software i de a reporni
automat componenta corespunztoare.
O component software de tip RCM interogat va rspunde la un mesaj n
timp de max. 1 secund.
...modificare i adaptare flexibil a HCI (Human-Computer Interface) n
vederea crerii unui look and feel specific clientului.
Cristina Mndru
Slide 12
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 variaii mari.
Descrierile sunt vagi i le lipsete o msura cunatificabil.
Din discuiile asupra ilitilor sistemului i ceea ce

nseamn ele cu adevrat rezult dezbateri nonproductive.
Cristina Mndru
Slide 13

De exemplu, fie urmtoarea cerin: Sistemul trebuie s fie
modificabil.
Cerin cu neles neclar.
Nu se poate proiecta un sistem modificabil pentru toate

schimbrile poteniale.
Fiecare sistem este modificabil n raport cu un set de schimbri

i nemodificabil n raport cu alt set de schimbri.
Costul i planul de timp (schedule) sunt factori externi structurii

sistemului ce pot interzice anumite modificri ale acestuia.
Problema nu este modificabilitatea problemele sunt:
Cum putem anticipa mai devreme schimbrile?
Cum putem planifica i proiecta sistemul pentru a face fa

schimbrilor?
Cristina Mndru
Slide 14

Relaiile dintre atributele de calitate pot fi complexe.
Exemplu: Cderea sistemului poate fi un aspect de disponibilitate, de securitate i de
utilizabilitate.
Atributele de calitate sunt deseori n tensiuni reciproce.

Exemplu: Pentru a crete securitatea sistemului se vor adauga module suplimentare, ceea ce
poate duce la scaderea performanei.
Dac nu se cunoate care atribute de calitate sunt importante atunci:

Nu conteaz care este promovat de arhitectura proiectat
Tensiunile nu pot fi rezolvate n mod satisfctor
Nu exist o baz pentru a analiza structurile
Cristina Mndru
Slide 15

Arhitectura software afecteaz majoritatea calitilor, dar
nu toate aspectele tuturor calitilor.
Exemplu: S considerm utilizabilitatea.
Alegerea butoanelor radio, casetelor de dialogVDXD

liniilor de comand afecteaz utilizabilitatea, dar acestea
nu sunt decizii arhitecturale.
Izolarea acestor decizii astfel nct 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.
Cristina Mndru
Slide 16
PLAN CURS

calitate
calitate
Cristina Mndru
Slide 17
Scenarii pentru atribute de calitate

Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bun a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
baz de raionament pentru decizii arhitecturale privind

structurile necesare pentru echilibrarea tuturor factorilor care
dirijeaz arhitectura.
cuantificarea este baz pentru msurare conformanei,
completitudinii i succesului.
Cristina Mndru
Slide 18
Scenarii pentru atribute de calitate 6 componente

1.
Stimul O condiie care afecteaz sistemul.
2.
Surs de stimuli Entitatea care a generat un stimul.
3.
Mediu (Context) Condiiile n care a aprut stimulul.
4.
Artefact Artefactul ce a fost stimulat de ctre stimul.
5.
Rspuns Activitatea din sistem ce a rezultat din cauza

stimulului.
6.
Msura rspunsului Msura prin care va fi evaluat

rspunsul sistemului.
Exemplu: aributul de disponibilitate
Cristina Mndru
Slide 19
Pentru a ilustra proprietile diferitelor atribute de calitate folosim
urmtoarele exemple de atribute de calitate de prim rang.
Cristina Mndru
disponibilitatea
modificabilitatea
performana
securitatea
Slide 20
Atribute de calitate - Disponibilitatea

Def. Disponibilitatea se ocup de avariile sistemului i de
consecinele asociate acestora.
Avarierea (cderea) unui sistem are loc atunci cnd acesta nu mai
furnizeaz un serviciu consistent cu specificaiile sale.
Zone de interes :
Prevenirea avariilor catastrofice ale sistemului
Detectarea avariilor sistemului
Revenirea cu succes din avarie
Timpul necesar recuperrii sistemului din avarii
Frecvena avariilor
Moduri degradate de operare datorate avariilor
Cristina Mndru
Slide 21

EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
defect de: omisiune, crash,
temporizare, evenimente, rspuns
Rspunsuri
Detectare i notificare, nregistrare,
Dezactivare, indisponibilizare,
continuare operare n mod degradat
Surse
interne, externe, software, hardware
Msuri pentru rspunsuri
Artefacte
Intervalele critice de timp cnd

sistemul trebuie s fie disponibil
sistem, procesoare, software,

hardware, memorie, reele
Timpul de disponibilitate
Contexte
Timpul de reparare
Intervalele de timp n care sistemul

poate opera n mod degradat
operaional, test, dezvoltare,

ncrcare, inert
Cristina Mndru
Slide 22
Exemplu de scenariu de disponibilitate:

Un mesaj extern neanticipat este recepionat de proces n
timpul funcionrii normale. Procesul informeaz operatorul
despre recepionarea mesajului i continu s funcioneze.
Cristina Mndru
Slide 23
Atribute de calitate - Modificabilitatea

Def. ModificabilitateaVHUHIHUODcostul schimbrii i la uurina
cu care un sistem software se poate adaptaODVFKLPEUL.
Zone de interes :
Identificarea schimbrilor posibile.
funcii, 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 schimbrii.
Cristina Mndru
Slide 24

Stimuli
Rspunsuri
adugare/tergere/modificare
funcionalitate sau atribut de calitate
Localizarea zonelor ce vor fi modificate

Realizarea modificrilor fr a induce
efecte colaterale
Testarea modificrii cu efort minim
Repartizarea modificrii cu efort minim
Surse
Utilizator final, dezvoltator,
administrator sistem
Artefacte
Sisteme, OS, hardware, software
Costul n termeni de componente, efort i

bani
Msura n care modificarea afecteaz alte
funcii i/sau atribute de calitate
Contexte
La execuie, la compilare, la
construire (build), la proiectare
Cristina Mndru
Slide 25

Exemplu de scenariu de modificabilitate:
Un membru al echipei de dezvoltare dorete s modifice interfaa 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 modificri nu trebuie
s apar efecte colaterale asupra comportamentului aplicaiei.
Cristina Mndru
Slide 26
Atribute de calitate - Performana

Def. Performana se refer la temporizare: de ct timp are
nevoie sistemul pentru a rspunde la apariia unui
eveniment.
Zone de interes :
Surse diferite de evenimente: ntreruperi, mesaje, cereri de

la utilizatori, tranzacii, etc.
Viteze i abloane variabile de apariie a evenimentelor:

sporadic, periodic, stocastic, combinaie
Timpul de rspuns: timpul scurs ntre apariia evenimentului

i reacia sistemului
Cristina Mndru
Slide 27

Stimuli
Rspunsuri
Apariia periodic, sporadic sau

stocastic a evenimentului
Procesare stimuli
Surse
intern, extern, software, hardware
ntrziere, termen (deadline), rat de

transfer, rat de insucces, pierdere
date
Artefacte
sisteme, OS, hardware, software
Contexte
operaional, test, dezvoltare,
ncrcare, inert
Cristina Mndru
Slide 28

Exemplu de scenariu de performan:
500 utilizatori iniiaz 1 000 tranzacii pe minut n manier stocastic
n cursul operrii n condiii normale i fiecare tranzacie este
procesat cu o ntrziere medie de 2 secunde.
Cristina Mndru
Slide 29
Atribute de calitate - Securitatea

Def. Securitatea PVXUDDELOLWii sistemului de a rezista la
ncercrile neautorizate de utilizare a datelor sau serviciilor,
oferind n acelai timp acces utilizatorilor legitimi.
Zone de interes :
non-repudiere: Tranzaciile nu pot fi repudiate de ctre nici una din prile
participante la tranzacie.
confidenialitate: Datele i serviciile sunt protejate la accesele neautorizate.

integritate: Datele i serviciile sunt furnizate conform cu specificaiile.
asigurare: Participanii la o tranzacie au n realitate identitatea pe care o
declar.
disponibilitate: Sistemul va fi disponibil pentru utilizrile legitime.

auditing: Activitile sunt urmrite n cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mndru
Slide 30

Stimuli
O entitate ncearc s afieze/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
Cristina Mndru
Slide 31

Rspunsuri
Autentificare utilizator
Ascunderea identitii utilizatorului
Blocarea accesului la date/servicii
Garantarea/respingerea accesului la date/servicii
ntegistrare acces/tentativ de acces la date, modificri la date
Memorare date n format codificat
Recunoaterea de cereri de date sau servicii inexplicabil de mari sau neobinuite
Raportare/restricionare acces.
Timp/efort/resurse necesare pentru a eluda cu succes msurile 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
Msura n care datele/serviciile au fost avariate
Msura n care accesele legitime au fost repudiate
Cristina Mndru
Slide 32

Exemplu de scenariu de securitate:
Un individ identificat corect ncearc s modifice date din sistem de
la un site extern. Sistemul detecteaz comportamentul maliios,
menine un audit al istoricului aciunilor individului i reface datele
n cursul zilei curente.
Stimul
Surs stimul
Artefacte stimulate
Context
Rspuns
Msur rspuns
Cristina Mndru
Slide 33
Alte atribute de calitate la nivelul sistemului:
Cristina Mndru
interoperabilitate
siguran
utilizabilitate
extensibilitate
portabilitate
uor de nvat
scalabilitate
mentenabilitate
testabilitate
Exist i atribute de calitate mai

particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Slide 34
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 cerinelor cu respectarea tuturor constrngerilor.
Constructibilitate
sistemul poate fi construit de echipa disponibil n timpul dat i este

deschis anumitor modificri pe timpul procesului de dezvoltare.
Cristina Mndru
Slide 35
Numirea unui atribut de calitate nu este suficient pentru a-i

nelege corect i complet semnificaia.
Semnificaia real, corect i complet a atributului se poate

transmite utiliznd un scenariu.
Cristina Mndru
Slide 36
PLAN CURS

calitate
calitate
Cristina Mndru
Slide 37
QAW Quality Attribute Workshop

QAW -PHWRGFDUHLPSOLFVtakeholder-ii sistemului n
descoperirea atributelor de calitate eseniale pentru
un sistem software.
Caracteristici cheie ale metodei QAW
Centrat pe sistem
Concentrat pe stakeholder
Utilizat nainte de proiectarea arhitecturii software
Cristina Mndru
Slide 38

PROCEDURA
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
Cristina Mndru
Reiterare de cte ori este necesar,

cu lrgirea comunitii de stakeholder-i.
Slide 39

Participanii:
O reprezentare ct se poate de divers a

stakeholder-ilor. (nu este neobinuit o participare de 20
stakeholder-i).
Echipa QAW -H[WHUQSURLHFWXOXL:

Scrib QAW : consemneaz scenariile brute,
prioritizrile lor, scenariile rafinate i orice chestiuni
relevante
Coordonator QAW : faciliteaz discuiile i asigur
faptul c metoda este aplicat n manier eficace i
oportun.
Cristina Mndru
Slide 40

Pas 1:
Introducere i prezentarea metodei QAW

Obiectiv:
Asigurarea faptului c toi stakeholder-ii neleg metoda

QAW i toi participanii au ansa s se prezinte.
Cristina Mndru
Slide 41

Pas 2: Prezentarea afacerii / misiunii
Obiectiv:
Asigurarea faptului c toi cei prezeni neleg:

Contextul business al sistemului
Cerinele funcionale de nivel nalt
Constrngerile de nivel nalt
Cerinele de nivel nalt pentru atributele de calitate
Planurile generale pentru dezvoltare (ciclu de via,
domeniu, responsabiliti, etc.)
OBS: Aceste elemente reprezint date de intrare pentru

QAW. (Dac nu sunt nc cunoscute, atunci este prea devreme
pentru QAW).
Cristina Mndru
Slide 42

Pas 3:
Prezentarea planului arhitecturii

Obiectiv:
Arhitectul explic audienei rezultatele curente al activitilor

de definire a arhitecturii, care includ :
Cristina Mndru
Extragerea i analiza cerinelor

Constrngeri cheie la nivel tehnic i la nivel business
Domeniul (de aciune al) sistemului i contextul su
Slide 43

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 cunoate i obine
clarificri/adugri/eliminri din partea stakeholder-ilor.
Pe lista astfel obinut se va concentra sesiunea de brainstorming.
Cristina Mndru
Slide 44

Pas 5:
Brainstorming pentru scenarii

Obiectiv:
Generarea unei liste iniiale de scenarii brute care reflect

necesitile stakeholder-ilor reprezentai.
Sesiune de brainstorming n care fiecare stakeholder are
ocazia s genereze cel puin un scenariu.
Cristina Mndru
Slide 45

Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea n

cursul procesului de votare.
Stakeholder-ii care au iniiat scenariile au cuvntul final

referitor la faptul c scenariul lor este reprezentat n
mod adecvat ntr-un scenariu combinat.
Cristina Mndru
Slide 46

Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor
stakeholder-ilor reprezentai.
Se utilizeaz o schem de votare n care fiecare

stakeholder are alocat un numr de voturi egal cu
aprox. 30% din numrul 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.

Cristina Mndru
Slide 47

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 pri componente (stimuli, surse

stimuli, artefacte, contexte, rspunsuri, msuri pentru rspunsuri)
Orice ntrebare pe care stakeholder-ii o au referitoare la scenariu
Orice problem ce apare n cursul rafinrii
Cristina Mndru
Slide 48
produce
QAW
poate fi utilizat pentru
Cristina Mndru
Scenarii brute pentru atribute de calitate

Prioritizarea scenariilor
Scenarii rafinate
Rafinare cerine
Prioritizare activiti de dezvoltare
Identificarea i diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Slide 49

QAW n context
QAW poate ajuta arhitecii s neleag contextul business,

comunitatea de stakeholder-i, dorinele, necesitile i
ateptrile acestora n raport cu sistemul software.
Informaiie produse de QAW reprezint doar nceputul
E posibil ca s nu fie prezeni toi stakeholder-ii

Timpul este limitat
Compania ar putea vrea s modifice prioritile
ntrebri/probleme adiionale pot s apar deoarece nu
toate datele sunt disponibile la momentul desfurrii unui
QAW
va fi necesar o rafinare considerabil a scenariilor.

Cristina Mndru
Slide 50
Metodologie general
Identificarea i gruparea cerinelor pe categorii:

funcionale, atribute de calitate, constrngeri tehnice i
business
Formularea cerinelor funcionale folosind cazuri de

utilizare
Crearea scenariilor pentru atributele de calitate
Determinarea fixitii constngerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare

grup n termeni de importan
Iniial: critice, importante, bine de avut
Ulterior: prioritizare n termeni de dificultate
concentrarea ateniei pe cerinele importante i dificile.

Cristina Mndru
Slide 51
ablon pentru descriere atribut de calitate

Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referin
Descriere brut a atributului de calitate:

Fie un nume (ex. Modificabilitate) fie o propoziie ce ncearc s descrie o cerin pentru un atribut de calitate
sau pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determin sistemul s reacioneze ntr-un anume fel.

Poate fi o cerin utilizator, un eveniment sau o ntrerupere, o eroare,
o cerere de modificare, etc.
Context:
Descrierea contextelor relevante care ar putea afecta rspunsul i

msuri semnificative ale rspunsului. Poate include condiii ca
operare normal, ncrcare de vrf, operare degradat, n timpul
dezvoltrii, etc.
Elemente sistem:
Elementele sistem afectate de stimul. n etapele iniiale ale ciclului de

dezvoltare (nainte de proiectarea arhitectural) elementele afectate
ar putea s nu fie cunoscute. Dup nceperea proiectrii, scenariile
trebuie rafinate iar elementele identificate n momentul n care devin
cunoscute.
Rspunsul sistemului:
Rspunsul dorit din partea sistemului.
Msuri semnificative:
Una sau mai multe msuri semnificative prin care va fi judecat

calitatea rspunsului. Msurile rspunsului poate fi date n termeni
de ore-persoan, detecie erori, timp de rspuns, timp de recuperare,
etc.
Cristina Mndru
Slide 52
CONCLUZII
Elementele care dirijeaz arhitectura impun forma acesteia
cerine funcionale de nivel nalt, constrngeri tehnice i

constrngeri business, atribute de calitate
Atributele de calitate i constrngerile sunt preponderente fa

de funcionalitate 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 eseniale.
Cristina Mndru
Slide 53

Curs 4
Cristina Mndru
Slide 1
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
Cristina Mndru
Slide 2
Structuri software
Structurile sunt componente reale ale unui sistem software.

Reprezentrile arhitecturale sunt abstractizri 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.
Cristina Mndru
Slide 3
Structuri
Perspectiva
Static
Dinamic
Fizic
Cristina Mndru
Exemple de
structuri
Exemple de
relaii
Tip de vederi
Straturi (layers)
Module de cod
...
Dependen
Apel
...
Module
Procese
Fire de execuie
...
Flux de date
Evenimente
...
C&C
Fisiere executabile
Calculatoare
Senzori
Linii seriale
Wireless
...
Allocation
Slide 4
Stiluri
Stil VWUXFWXUJHQHUDODXQHLIDPLOLLGHVLVWHPHFXWUVWXUL
similare i care apar n mod repetitiv n realitate.
Se bazeaz pe:
Natura elementelor
Aranjarea topologic
Natura relaiilor ntre elemente
Exemple: stiluri pentru flux de date, stiluri distribuite, stiluri cu

evenimente, etc.
Stil = ablon arhitectural
Cristina Mndru
Slide 5
abloane (Patterns)
Experii reutilizeaz esena soluiei unei probleme similare (gndire
n perechi PROBLEM-SOLUIE)
Categorii de abloane funcie de granularitate:
ablon arhitectural
Tactic
ablon de proiectare
Idiom
Cristina Mndru
Slide 6
abloane (stiluri) arhitecturale

Stil arhitectural = structur fundamental care
Definete o soluie general pentru un anume tip de probleme

mpacheteaz i definete o familie de structuri arhitecturale
generale
Posed proprieti 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 nelege punctele tari, punctele slabe i consecinele devierilor de la
forma pur.
n realitate
Sistemele deviaz n general de la formele pure

Sistemele combin simultan mai multe stiluri arhitecturale
Cristina Mndru
Slide 7
abloane (stiluri) arhitecturale

Definesc:
Un set de tipuri de elemente i responsabilitile generale asignate

acestora
Un set de tipuri de relaii ntre elemente
Un aranjament topologic al elementelor i relaiilor
Reguli semantice referitoare la modul de conectare, interaciune i

transformare a elementelor i relaiilor
Exemple canonice
Dac se ader la semantici, stilul va promova unele proprieti i va

inhiba altele.
Cristina Mndru
Slide 8
Tactici
Ofer o schem pentru rafinarea elementelor unui sistem

software i a relaiilor dintre acestea.
Sunt independente de limbajul de programare
Se adreseaz unor probleme mai fineGHSURLHFWDUHGHFkW
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)
Cristina Mndru
Slide 9
Exemplu 7DFWLFSHQWUXGLVSRQLELOLWDWH
Cristina Mndru
Slide 10
abloane de programare
Design patterns
GranularitatePDLPLFGHFkWVWLOXULOHDUKLWHFWXUDOH.
Se concentreaz pe arhitecturi OO.
Se concentreaz pe structuri de clase i probleme de

construire a codului, nu pe structuri i proprieti la nivel de
sistem.
Consider c modularitatea i reutilizarea sunt cele mai
importante atribute de calitate pe care proiectarea trebuie s le
adreseze.
Cristina Mndru
Slide 11
abloane viziune de ansamblu
Client
Server
abloan (stil) arhitectural - utilizat la

nceputul proiectrii de nivel nalt pentru a
adresa proprieti la nivel de sistem.
Tactic -XWLOL]DWSHQWUXDUDILQDHOHPHQWHOH
arhitecturale nainte de implementare.
MVC, Abstract Factory, Flyweight, Proxy,
Main Loop
{
read sensor
apply correction constant
write data to memory
move actuator
check for error
:
}
Cristina Mndru
ablon de programare VHDGUHVHD]

problemelor de proiectare orientate pe cod.
Idiom - utilizat la proiectarea de detaliu la

nivel de element
Slide 12
Importana abloanelor arhitecturale
Punct de plecare n activitatea de proiectare de obicei se ncepe cu

alegerea unui ablon general de partiionare.
Ofer un vocabular comun pentru proiectani
abloanele expun proprieti cunoscute.
Mijloc de descriere soluii 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
Arhitecii pot judeca proprietile ansamblului prin prisma proprietilor

abloanelor componente.
Ofer prghii pentru
Proiectani : arhitecii selecteaz acele structuri care ndeplinesc cerinele

funcionale i atributele de calitate.
Evaluatori : cei careVWXGLD]SURLHFWHOHDUKLWHFWXUDOHSHQWUXDVHDVLJXUDF

ndeplinesc cerinele funcionale i atributele de calitate.
Cristina Mndru
Slide 13
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. motenire, polimorfism, pentru

limbajele OO)
Cristina Mndru
Slide 14
Structuri
Structurile sunt componente reale ale unui sistem software.
Reprezentrile arhitecturale sunt abstractizri ale structurilor reale cuprinse ntr-un
sistem software.
Recomandare : analiz structuri n termeni de :
Perspectiva i vedereaUHSUH]HQWDW
Aranjarea topologic (de obicei GHVHQXOVDXUHSUH]HQWDUHD
canonic)
Elemente i relaii (fundamentele structurii)
SemanticileVWUXFWXULL
Calitile promovate i cele inhibateGHVWUXFWXU
Contextul tipic de utilizare, exemple, variante structurale.
Cristina Mndru
Slide 15
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
Cristina Mndru
Slide 16
Stiluri specifice perspectivei C&C

Def. Stil arhitectural = specializare pentru tipuri de elemente i de
relaii, mpreun cu un set de constrngeri 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
Cristina Mndru
Slide 17

C&C captureaz aspectele dinamice ale sistemului
Stilul - asociat cu un model computaional care definete fluxul

datelor i fluxul de control
Modele computaionale :
Data flow calculul dirijat de fluxul datelor n sistem
Call-return componentele interacioneaz prin invocri sincrone ale

capabilitilor oferite de alte componente
Event-based - componentele interacioneaz prin evenimente sau mesaje

asincrone
Repository - componentele interacioneaz printr-o colecie vast de date

persistente partajate
Cristina Mndru
Slide 18
Familia de stiluri pentru flux de date (data flow)

Sistem n flux de date caracteristici fundamentale:
Structura de proiectare este determinat de circulaia datelorGHODR

component la alta.
Disponibilitatea datelorFRQWUROHD]FDOFXOHOH.
Fluxul de date este explicit.
Aceasta este singuraIRUPGHFRPXQLFDUH ntre componente.
Variaii funcie de:
Modul de exercitare a controlului (ex. push vs. pull)
Gradul de concuren dintre procese
Gradul de calcul incremental
Restricii topologice, etc.
Cristina Mndru
Slide 19
Elemente pentru flux de date

Elemente: procesri date
Tipurile de interfee sunt port de date de intrare i port de date de

ieire
Port de intrare citete date
Port de ieire scrie date
Modelul computaional : citete date de la port(uri) de intrare,

calculeaz, scrie date la port(uri) de ieire
Relaii: fluxuri(streams) de date
Unidirecional (de obicei asincron, buffer-at)
Interfeele sunt rolurile de reader i writer
Modelul computaional : transferul datelor de la rolul writer la rolul

reader
Cristina Mndru
Slide 20
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 fora determinant pentru
arhitectur.
Flux de date
Modul n care datele circul printr-o colecie de uniti de calcul.
Controlul (i calculul) sunt activate de disponibilitatea datelor.
Obs. abloanele arhitecturale pentru flux de date nu sunt acelai lucru cu DFD din analiza
structurat tradiional.
Cristina Mndru
Slide 21
Stiluri din familia flux de date

Batch sequential
Procesare secvenial; componentele transform toate datele de

pe intrare dup care rezultatul este trimis spre prelucrare
urmtoarei componente.
Tipic pentru primele aplicaii pentru sisteme de management al informaiilor (MIS).
Pipe-and-filter
Procesare incremental; componentele aplic transformrile i

transmit rezultatul componentei urmtoare pe msur ce primesc
date.
Tipizate de ctre Unix
Control de proces
Structur n bucl pentru a controla
variabilele de context
Cristina Mndru
Slide 22
Stilul batch sequential

Flux de date prin memorie extern
Program
Program
Program ...
Uniti de calcul
Cristina Mndru
Slide 23

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

Process
A
Input
Output1
Process
B
Output2
Process
C
Perspectiv i viewtype
Perspectiva dinamic.
C&C Viewtype DUDWprocesele (componente) i conexiunile
stabilite la execuie (conectori).
Cristina Mndru
Slide 24
Output

Semantici
Datele de intrare sunt transformate secvenial; la fiecare pas datele

sunt procesate n totalitate.
Procesele sunt independente i nu partajeaz stare cu alte
procese.
Procesarea concurent este imposibil.
Datele de ieire ale unui proces sunt memorate n fiiere i devin
intrri pentru procesul urmtor.
n mod ideal, formatul datelor de ieire ale unui proces este
compatibil cu formatul datelor de intrare pentru urmtorul proces.
Procesele pot ncepe atunci cnd toate datele lor de intrare sunt
pregtite i se opresc cnd nu mai exist date i procesarea a fost
ncheiat.
Deseori sunt necesare mecanisme de control al job-urilor (definite
utiliznd JCL job control language).
Cristina Mndru
Slide 25

Atribute de calitate promovate
Simplitate LQWHJULWDWHFRQFHSWXDO
Reutilizarea proceselor
Modificabilitate SURFHVULOHSRWILXor stabilite folosind limbaje de
control (JCL)
Detecie i tratare erori, recuperare sistem problemele se pot
izola relativ uor.
Atribute de calitate inhibate
Performan
Interactivitate (imposibil)
Necesit intervenie i supraveghere uman
Cristina Mndru
Slide 26
ablonul batch sequential - exemple

Aplicaii tipice
Procesarea clasic a datelor
Calcul taxe
Calcul impozite
Primele medii de dezvoltare de software
Cristina Mndru
Slide 27
Stilul pipe-and-filter
Modelul computaional:
Structur ce proceseaz fluxuri de date prin transformarea
incremental a datelorGHFWUHHOHPHQWHVXFFHVLYH.
mbogire date prin calcule i adugare de informaii

Rafinare prin distilarea datelor sau prin ndeprtarea informaiilor
nerelevante
TransformareGDWHSULQVFKLPEDUHDUHSUH]HQWULLORU
Filtrele nu cunosc identitatea filtrelor precedente sau urmtoare
ansamblul de calcul este o compunere funcional a funciilor filtrelor
Cristina Mndru
Slide 28
Tipuri de componente: Filtru
Citete date de la unul sau mai multe porturi de intrare, le transform i scrie
rezultatele pe unul sau mai multe porturi de ieire
Poate funciona concurent cu alte filtre
Transform fluxuri (de intrare) n fluxuri (de ieire)
Nu pstreaz starea de la o instaniere la alta

Tipuri de conectori: Pipe (conducta)
Transfer datele de la un port de ieire a unui filtru la un port de intrare al altui filtru
Are un singur rol de intrare date i un singur rol de ieire date
Transfer unidirecional, cu pstrarea ordinii, cu pstrarea datelor (canal de

comunicare buffer-at)
Conductele formeaz grafuri pentru transmiterea datelor

Relaii : Ataare
Asociere port de ieire date al unui filtru cu rol de intrare date al unei conducte i port
de intrare date al unui filtru cu rol de ieire date al unei conducte
Cristina Mndru
Slide 29
Topologie
Elemente (filtre) legate prin relaii (conducte)
Perspectiv i viewtype
Perspectiva dinamic
C&C viewtype DUDWSURFHVHOH/firele de execuie (filtre) i
conexiunile (pipes) stabilite la execuie.
Cristina Mndru
Slide 30
Stilul pipe-and-filter Semantici (1)
Filtrele pot funciona asincron i concurent
Datele sunt transformate incremental
Corectitudinea datelor de ieire nu trebuie s depind de ordinea n

care se execut filtrele din cadrul sistemului
Elementele din sistem se activeaz n prezena datelor, dar execuiile
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 pstraz starea de la o instaniere la alta
Nu se cunosc informaii despre filtrele precedente sau ulterioare
Rata de procesare a filtrelor depinde de rata cu care datele sunt

disponibile
Funcia realizat de un filtru este determinat la configurarea
sistemului. Odat cu construirea sistemului se stabilete definitiv funcia compus
aplicat fluxului de date.
Cristina Mndru
Slide 31
Stilul pipe-and-filter Semantici(2)
Flux de date unidirecional, cu pastrarea ordinii i coninutului

Conductele nu au stare i sunt utilizate pentru a transfera
datele
Ieirea unei conducte se poate conecta doar la un port de
intrare al unui filtru sau la destinaia final a datelor (data sink).
Intrarea unei conducte se poate conecta doar la un port de
ieire sau la sursa de date.
Deseori sunt necesare mecanisme speciale pentru a face
legturi.
Conductele ofera posibiliti de memorare infinite pentru a
permite citiri/scrieri asincrone
Cristina Mndru
Slide 32
Simplitate LQWHJULWDWHFRQFHSWXDO
Reutilizarea filtrelor datorit independenei funcionale a acestora
Modificabilitate legarea conectorilor la execuie (late binding)
permite reconfigurarea simpl a reelei de conducte i filtre
Performan se poate crete prin paralelizarea procesrii datelor

Interactivitate (dificil)
Detectarea i tratarea erorilor i refacerea sistemului
Cristina Mndru
Slide 33
Stilul pipe-and-filter - exemple

Sisteme de procesare semnale ex. Sistem de colectare a datelor de
telemetrie
Frame
Collection
Time Tag
Frame
Minor Frame
Decom
Measurement
units
Display Data
Record Data
Major Frame
Decom
Apply
coefficients
Recepionarea fluxului de date de telemetrie, decomutare cadre

(separare canale multiple de date codificate), aplicare de coeficieni, afiare i
memorare date.
Cristina Mndru
Slide 34
Stilul pipe-and-filter - exemple

Filtre: procese Unix
Conducte: fluxuri buffer-ate suportate de sistemul de operare
Fiierele sunt considerate surse i destinaii finale de date; spre deosebire

de filtre, fiierele sunt pasive.
Surse i destinaii 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 informaie trebuie codificat (ASCII, UniCode), transferat, apoi
decodificat.
Exemplu:
cat/etc/passwd | grep joe | sort > junk

passwd
Cristina Mndru
cat
grep
sort
junk
Slide 35
ablonul pipe-and-filter - exemple
Arhitectura de procesare a cererilor de la Apache Web server
Paradigma map-reduceGHODPRWRDUHOHGHFXWDUH
Yahoo!Pipes pentru procesare RSS feeds
http://pipes.yahoo.com/pipes
Sisteme de calcul tiinific ce proceseaz i analizeaz

cantiti mari de date experimentale
Cristina Mndru
Slide 36
Comparaie abloane
Batch Sequential
Pipe-and-Filter
Descompun sistemul n elemente ce interacioneaz doar prin intermediul

datelor transferate ntre acestea.
Granularitate mare
Granularitate fin
Laten mare ntre paii de

procesare
Prezena datelor pornete procesarea
Acces extern la intrare
Intrare localizat
Concurena este imposibil
Concurena este posibil
Non-interactivitate
Interactivitate dificil, dar posibil
Datele sunt procesate n ntregime

la fiecare pas
Datele sunt procesate incremental
Cristina Mndru
Slide 37
Variante ale stilului pipe-and-filter
Filtre cu buffer-are
Eventual i prelucrri simple H[. ordonare

Scdere de performan
Limitare la memoria intern disponibil
Obs. O posibil soluie de utilizare a memoriei externe violez semanticile stilului i poate
submina proprietile de reconfigurare i reutilizare promovate de stil i conduce,GH
asemenea, la scderea performanei.
Reele concurente
Divizarea procesrii pe structuri paralele.

Promoveaz performana, cu excepia cazurilor n care exist gtuiri
pe flux.
Filtre cu difuzare (broadcasting) de evenimente
Cristina Mndru
Lansare eveniment de obicei atunci cnd apare o problem la filtru.

Se va urmri meninerea unei cuplri slabe (eventual nule) cu alte
elemente, pentru a nu viola semanticile stilului.
Slide 38
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 aplicaii pe flux de date deoarece:
Permite reutilizarea i reconfigurarea filtrelor.
Sistemul poate fi analizat uor.
Reduce efortul de testare a sistemului i de re-testarea de dup

reconfigurare.
Permite procesare incremental I procesare paralel.
Performana este determinat de filtrul cel mai lent.
Cristina Mndru
Slide 39
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 msurrii datelor
de intrare.
Clasificare 1:
Sisteme de control cu evenimente discrete

Sisteme cu control continuu
Obs. Majoritatea sistemelor reale utilizeaz ambele strategii de control.

Ne ocupm de sistemele cu control continuu.
Clasificare 2:
Sisteme de control n bucl deschis

Sisteme de control n bucl nchis
Cristina Mndru
Slide 40
Stiluri pentru control proces

SISTEME DE CONTROL exemple
Sistemele de nclzire, ventilare i aer condiionat (HVAC)
Sisteme ambientale inteligente
Sisteme de control pentru motoarele automobilelor
Sisteme de manufacturare i producie
Sisteme pentru pompieri i securitate
Electrocasnice
Roboi i subsistemele lor
Simulatoare, sisteme aerospaiale, etc.
Cristina Mndru
Slide 41
Control n bucl deschis
Un sistem de control n bucl deschis nu necesit

msurarea variabilelor de ieire pentru a corecta erorile.
Reglarea se face prin intervenie extern (manual).
Soluie simpl i bun dac variaiile sunt mici.
Dac variaiile sunt mari sau brute, solicit atenie frecvent

din partea operatorului uman.
Avantaj : simplitate
Dezavantaj: insensibil la dinamica n timp a sistemului controlat.
Cristina Mndru
Slide 42
Control n bucl nchis

Strategie de control mai sofisticat.
Se fac msurtori asupra mediului i asupra ieirilor din sistem.

Valorile msurate sunt folosite ulterior pentru a regla automat sistemul.
Forme de control:
Feedback
Feed-forward
Obs. n practic se utilizeaz uneori o combinaie a celor dou forme de control, rezultnd trei
abloane diferite.
Feedback
Proces prin care o parte din semnalul de ieire sau o funcie aplicat
acestuia este transmis napoi pe intrarea elementului de control.
Are loc n timp real, permind controlul sistemului n timp ce acesta

funcioneaz.
Cristina Mndru
Slide 43
Stil pentru control n bucl nchis, cu feedback

Controller unul sau mai multe elemente responsabile
s furnizeze semnale de dirijare a instalaiei.
Intrare de referin - una sau mai

multe intrri ce reprezint valorile
ideale ale variabilelor controlate.
Instalaie elementul sistemului care reacioneaz

la informaiile de dirijare, execut operaiile i
manipuleaz variabilele controlate.
Variabile de intrare zero sau

mai multe intrri care sunt
alimentate (sau eantionate)
continuu de ctre controller.
Informaii de dirijare datele trimise

la instalaie i care dirijeaz
volumul de activitate al instalaiei.
Variabile controlate ieirea sistemului, reprezentnd

cantitatea ce trebuie meninut la o anumit valoare.
Feedback semnalulFDUHUHSUH]LQWRSDUWHVDXRIXQFie aplicat asupra

variabilei controlate; este returnat la controler.
Cristina Mndru
Slide 44
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 rmase deschise:
Evenimente discrete vs. Bucl de control continuu
Combinaia dintre control proporional, integral i diferenial
proporional cu valoarea erorii,

diferenial - reacie funcie de variaia erorilor,
PID - proporional-integral-derivativ
Modaliti de reglare i de facilitare a reglrii
ablonul permite proiectanilor s aloce elementelor responsabiliti

n etapele iniiale de proiectare,
n vederea obinerii unor proprieti generale la nivel de sistem.
Cristina Mndru
Slide 45
Stiluri pentru sisteme de control

n sistemele de control exist o cuplare strns ntre elementele fizice
i elementele software; consecine:
Promovarea performanei
Reducerea dimensiunii codului executabil i consumului de memorie
Inhibarea modificabilitii i abilitii de a reutiliza elemente (n general)
Sistemele de control pun probleme speciale de dezvoltare. Pe lng

controlul fizic, sistemul trebuie :
s rspund repede i deterministic

s fie sigur i s aib un grad foarte mare de disponibilitate n medii
extreme.
Cristina Mndru
Slide 46

Curs 5
Cristina Mndru
Slide 1
Perspectiva dinamic
Perspectiva dinamic modul n care sistemul este structurat
ca set de uniti de execuie (elemente ce au comportament
i interaciuni la momentul execuiei).
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)
Cristina Mndru
Slide 2
Perspectiva dinamic
component = unitate de calcul i/sau memorare date pe

timpul execuiei; accesibil prin porturi care expun
intefeele componentei.
conector = mecanism de interaciune ntre componente;

definete roluri care expun interfeele conectorului.
Tip de port/rol = interfa = replici multiple*ODRFRPSRQHQW/conector
*Notaie
multiplicitate: [a] create static, [0..b] create dinamic
Cristina Mndru
Slide 3
Perspectiva dinamic
Component
Exemple
Proces, obiect, client, server, datastore, complexe reprezentate pe nivele multiple de

detaliu
Conector
Categorii: link i protocol de comunicare, flux informaii, acces la memorie
partajat
Exemple
Invocare servicii, cozi mesaje asincrone, multicast evenimente, pipe
Canal de comunicare orientat pe tranzacii, ESB (enterprise service bus)
nglobeaz un protocol de interaciune (ordine interaciuni, punctul curent de

control, gestionare condiii de eroare i time-out) trebuie documentat.
Reprezint forme complexe de interaciune GHWDOLHUHXOWHULRDUFD
subsistem C&C.
Ex. High level DSHOGHSURFHGXU

Detalii n context distribuit:
Protocoale pentru time-out, gestionare erori, mpachetare/despachetare date, localizare

furnizor
Cristina Mndru
Slide 4
Perspectiva dinamic
Tipuri de relaii :
attachment ataare port al componentei la rol al conectorului
interface delegation asociere port cu porturi ale

subcomponentelor; asociere rol cu roluri ale structurii interne
Condiii :
Ataare valid : port rol ; cu respectare protocol de interaciune
Delegare interfa ntre porturi/roluri compatibile
Conectorul trebuie ataat la o component (nu poate exista izolat)
Cristina Mndru
Slide 5
Perspectiva dinamic
Tipuri i instane
Tip definiie pentru o clas de componente sau conectori; set de variante.
Nivele de specializare:
Stil arhitectural (ex.FOLHQW, server, conector cerere/rspuns)

Tehnologie (ex. Java servlet, EJB, MySQL)
Domeniu (servlet control comunicare cu ATM)
Aplicaie
Instan UHSUH]HQWDWSHRGLDJUDP&&C;
Conform cu un tip n termeni de:
Cristina Mndru
Comportament
Interfee (tip i multiplicitate)
Substructuri
Proprieti
Restricii topologice
Slide 6

NOTAII
Informale : box-and-lines
UML : diagrama de componente
Acme (AcmeStudio) :
Cristina Mndru
Slide 7
Stil arhitectural specializare pentru tipuri de elemente i de relaii, mpreun

cu un set de constrngeri referitoare la modul de utilizare a acestora.

Reprezentare parial a claselor de stiluri C&C
Calcul dirijat de fluxul

datelor n sistem
Invocri sincrone ale

capabilitilor oferite
de componente
Calcul dirijat de
evenimente sau
mesaje asincrone
Comunicare printr-o
colecie vast de date
persistente partajate
Clements, Bachmann, Bass, Garlan, Ivers, Little, Nord, Stafford, Documenting Software Architectures: Views and
Beyond, Second Edition, Addison Wesley, 2010
Cristina Mndru
Slide 8
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 aplicaii Web specializare pentru stilul n trepte
Arhitectur aplicaii Java EE specializare pentru stilul n trepte
Cristina Mndru
Slide 9
Stiluri pentru structuri call-return - fundamente
Modelul computaional :
Conin elemente ce ofer servicii altor elemente.
Componente : furnizor serviciu, consumator serviciu
Conectorii - transfer cererea de la productorul de serviciu la consumatorul

acestuia i rezultatul n sens invers.
Elementele depind de serviciile invocate pentru a-i ndeplini

reponsabilitile proprii.
Cristina Mndru
Slide 10
Stiluri pentru structuri call-return - fundamente
Serviciile pot funciona n 2 moduri:
Blocant HOHPHQWHOHVROLFLWDQWHWUHEXLHVDtepte 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.
Cristina Mndru
Slide 11
Stiluri pentru structuri call-return - componente

Furnizor serviciu FRPSRQHQWFXXQDVDXPDLPXOWHLQWHUIHe prin
care ofer servicii.
Categorii de interfee :
De obicei, componentele cunosc identitatea elementelor pe ale

cror servicii se bazeaz, DAR
Expune un set de servicii utilizabile de ctre alte elemente. (provided)

Expune un set de servicii pe care alte elemente trebuie s le ofere. (required)
Nu ntotdeauna
Numele furnizorului de servicii poate deveni cunoscut pe parcurs.
Component SRDWHILFRPSOH[, cu multe detalii de proiectare (nu

doar o clas sau o funcie)
Cristina Mndru
Slide 12
Stiluri pentru structuri call-return - componente

Serviciile sunt de obicei grupate i mpachetate n baza unui scop
comun:
Pentru simplitatea mentenanei si a modificrii
Pentru facilitarea reutilizrii unor elementorte arhitecturale de

dimensiuni mari
Pentru a crea uniti vandabile
Pentru a partiiona construirea elementelor n raport cu fora de

munc de dezvoltare
Cristina Mndru
Slide 13
Stiluri pentru structuri call-return relaii (1)

Relaiile sunt baza pentru schimbul de informaii i de control ntre
elemente.
Categorii de relaii:
Asimetric
Participani : apelant i apelat
Semantic : apelatul ofer servicii utilizate de apelant
Exemplu : apel de procedur
Simetric (peer-to-peer)
Participani :GRXHOHPHQWH, fiecare putnd fi att apelant ct i
apelat
Semantic : fiecare element poate furniza servicii celuilalt
Exemple : sisteme OO
Cristina Mndru
Slide 14
Stiluri pentru structuri call-return relaii (2)

Responsabilitile pentru control i pentru date nu sunt separate.
Relaii ntre date :
Datele pot fi transferate n ambele sensuri, ca parametri de la

apelant la apelat i ca rspuns n sens invers.
Relaii pe fluxul de control:
Forma cea mai simpl

de la apelant la apelat, apleantul blocndu-se n ateptarea rspunsului.
Forme mai complexe

Protocol de interaciune ce definete secvene de cereri i rspunsuri
Pot implica concuren i rendezvous/joining
Cristina Mndru
Slide 15
Stiluri pentru structuri call-return -VHPDQWLF

Corectitudinea funcional a sistemului este ierarhic.
Corectitudinea oricrui element arhitectural depinde de corectitudinea

elementelor pe ale cror servicii se bazeaz.
Conduce n mod natural la specificarea design-lui pe baz de interfa
i de pre/post-condiii
Precondiii condiiile n care poate fi solicitat serviciul

Postcondiii condiiile asupra rezultatului invocrii serviciului
Momentul legrii (binding) apelului la recipient:
Cristina Mndru
Static - la compilare (ex. tipuri abstracte de date tradiionale)

Dinamic la execuie (ex. sisteme OO)
Prin intermediar (broker) XWLOL]DUHDXQXLEURNHUGHRELHFWHSHQWUXD
gsi obiecte i servicii (ex. RMI, RPC)
Slide 16
Stiluri pentru structuri call-return atribute de calitate

Modificabilitate prin separare (probleme i interfa)
Modificabilitatea este mrit pe baz de apeluri i

rspunsuri puine i depinde n mod esenial de o bun
asignare a reponsabilitilor.
ncapsularea i motenirea (n paradigma OO)
promoveaz reutilizarea elementelor.
Cristina Mndru
Performana este inhibat de ctre ramificaiile de control.

Comportamentul corect i disponibilitatea sunt distribuite pe mai
multe elemente.
Slide 17
PLAN CURS
Stilul peer-to-peer
Cristina Mndru
Slide 18
Tip componente: client, server
Client LQYRFVHUYLFLL (consumator)

Server RIHUVHUYLFLL (furnizor)
Tip conectori : cerere/rspuns

roluri: cerere, rspuns
Relaia : ataare port cerere client cu rol cerere conector i port rspuns
server cu rol rspuns conector.
Cristina Mndru
Slide 19
Modelul computational:
Client - iniiaz interaciune prin invocare serviciu la server i se

blocheaz n ateptarea rezultatului.
Server DVWHDSWVROLFLWUL, execut calcule i trimite rspuns.
Comunicare asimetric : clientul cunoate identitatea serverului nainte de apel, nu i

reciproc.
Cristina Mndru
Slide 20
Variante :
Server-ele pot iniia aciuni asupra clientului prin proceduri de

notificare (call-back) nregistrate de client la server.
Interaciune multipl n cadrul unei sesiuni.
Componente server pot fi clieni pentru alte componente

Specializri exemple de restricii suplimentare:
Cristina Mndru
Numrul de atari la un port dat
Relaii permise ntre servere
Creare ierarhie pe mai multe trepte (tiers) prin grupare i

distribuire componente. Exemple ?
Slide 21
Atribute de calitate promovate :
Extensibilitate DGXJDUHGHQRLFOLHQi i servere
Modificabilitate i reutilizare - prin separare servicii comune
Scalabilitate i disponibilitate - cu replicare server
Permite analizarea dependabilitii, securitii i capacitii de transfer date

(throughput).
Cristina Mndru
Fiabilitatea
Performana
Securitatea
Simplitatea sisteme cu complexitate mare; dificil de testat i de ntreinut.
Slide 22
PLAN CURS
Stilul peer-to-peer
Cristina Mndru
Slide 23
Stilul peer-to-peer
Componente : procese independente
Conectori : call/return
Comunicare bidirecional ntre 2 sau mai multe componente
Relaii : ataare dinamic component cu conector
Cristina Mndru
Slide 24
Stilul peer-to-peer
Model computaional :
Cooperare componente ale unui peer ; fiecareFRPSRQHQWSRDWH

iniia interaciuni.
Simetric RULFHFRPSRQHQWSRDWHSURGXFHi consuma servicii
Succesiune operaii:
conectare la reeaua de componente,
cutare component
invocare serviciu
Cristina Mndru
Slide 25
Stilul peer-to-peer
Variante :
Propagare de la un peer la altul n cutarea unei componente
Noduri speciale (ultrapeer / ultranode / supernode)FDSDELOLWi de

indexare sau rutare
Limitarea numrul de componente conectate
Restricii de cunoatere identitate
Cristina Mndru
Slide 26
Stilul peer-to-peer
Flexibilitate caracter simetric
Compozabilitate cooperare componente pentru a oferi un serviciu
Echilibrare ncrcare
Scalabilitate dinamic conectare componente la runtime
Disponibilitate cu replicare componente
Permite analizarea dependabilitii, securitii i capacitii de

transfer date (throughput).
Cristina Mndru
Slide 27
Stilul peer-to-peer
Exemple sisteme distribuite
Reele de partajare fiiere (exemple ?)
Aplicaii de mesagerie instant i VoIP
Desktop grid computing systems
Gnutella transfer bidirecional de fiiere
Cristina Mndru
Slide 28
PLAN CURS
Stilul peer-to-peer
Cristina Mndru
Slide 29
Stilul SOA
SOA Service-Oriented Architecture
Colecie de componente distribuite care ofer i/sau consum
servicii.
Componente executabile : compozabile indiferent de limbajul de
dezvoltare i platforma de execuie.
Componente independente funcional.
Cristina Mndru
Slide 30
Stilul SOA
Tipuri de componente :
furnizor serviciu RIHUVHUYLFLXSULQLQWHUID publicat
consumator serviciu LQYRFVHUYLFLLGLUHFWVDXSULQLQWHUPHGLDU
Registru furnizorii nregistreaz servicii, consumatorii

descoper servicii la runtime
Server de orchestrare FRRUGRQHD]LQWHUDFiunile pe baza

unor scripturi ce definesc fluxuri de lucru (workflow)
ESB (enterprise service bus) element de rutare i transformare

mesaje
Cristina Mndru
Slide 31
Stilul SOA
Tipuri de conectori :
SOAP protocol SOAP (over HTTP) comunicare sincron; conecteaz

porturi descrise cu WSDL
REST intermediaz operaiile 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)
Relaii : ataare dinamicSRUWXULGLVSRQLELOHODFRQHFWRULFRUHVSXQ]WRUL.

Model computaional :
Cooperare componente; descris n general ca workflow.
*Exemple: IBM WebSphere MQ, Microsoft MSMQ, Apache ActiveMQ
Cristina Mndru
Slide 32
Stilul SOA
Variante :
Consumatorii sunt conectai la furnizori, posibil prin componente

intermediare.
Interoperabilitate independen de platforma de execuie a

componentelor
Suport pentru integrare sisteme legacy
Flexibilitate -UHFRQILJXUDUHGLQDPLF
Cristina Mndru
Slide 33
PLAN CURS
Stilul peer-to-peer
Cristina Mndru
Slide 34
Trepte (tiers)
Mecanism de partiionare a sistemelor prin gruparea logic a
componentelor n trepte.
Criterii:
Tip componente
Partajare mediu de execuie
Obiectiv comun
Restricii topologice referitoare la comunicarea ntre componente: se pot

conecta direct doar componente din aceeai treapt sau din trepte adiacente.
Restricii referitoare la tipul de comunicare ntre trepte adiacente (ex. callreturn 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
Cristina Mndru
Slide 35
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:
Interfaa cu utilizatorul
Logica de procesare funcional (business rules)
Memorare / acces date
Dezvoltate i ntreinute separat, ca elemente independente, de

multe ori pe platforme diferite.
Cristina Mndru
Slide 36

Interfaa utilizator se execut pe o staie desktop i utilizeaz un GUI standard

(browser-ul).
Logica de procesare funcional (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 rndul ei, din mai multe trepte stilul
devine "n-tiered."
Datele sunt amplasate pe un sistem separat care gzduiete un repozitoriu (RDBMS).
Front end, sau

procesele front
end.
Client
Reguli
Business
Date
Middle tier
n mod tipic un browser
Cristina Mndru
n mod tipic RDBMS
Slide 37

O problem cheie a arhitectului partiionarea nivelului intermediar

(middle tier).
Conceptul de middleware a cptat identitate odat cu apariia
sistemelor n-tiered.
Stilul n-tier introduce o separare care:
Permite actualizarea sau nlocuirea independent a oricrei trepte

funcie de necesiti se pstreaz integritatea conceptual.
Permite mecanisme ce promoveaz performana, securitatea,

fiabilitatea.
Cristina Mndru
Slide 38
PLAN CURS
Stilul peer-to-peer
Cristina Mndru
Slide 39
Structur general n 3 trepte

specializare a stilului n trepte pentru domeniul aplicaiilor WEB
Web
Browser
Web
Browser
Web
Browser
Web
Browser
Treapta UI
Cristina Mndru
Load
Balancer
Web
Server
Router/
Firewall
Web
Server
:
Proxy
Server
Web
Server
Application
Server
Database
Server
:
Application
Server
Treapta regulilor business

Database
Server
Treapta datelor
Slide 40
Avantaje
Stil n 3 trepte pentru aplicaii Web
Browser-e Web performante
Iniial 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 bii. Acest
nivel de criptare este considerat ca fiind adecvat pentru cantiti mici
de informaii comericale i pentru tranzacii scurte.
Cristina Mndru
Slide 41
Avantaje
Server-e proxy
mbuntesc performana:
Memoreaz n cache
pagini web accesate frecvent, a.. utilizatorii le pot extrage fr acces direct la site.
Pot fi localizate geografic aproape de utilizator i plasate n aceeai

reea 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

informaii.
Tipuri uzitate:
Packet filters H[DPLQHD]DQWHWHOH7&3i IP ale fiecrui pachet primit

i rejecteaz pachetele necorespunztoare.
Application proxies specifice aplicaiilor; cunosc protocoalele folosite
de aplicaie i filtreaz traficul pe baza unor modele de comportament
cunoscute.
Cristina Mndru
Slide 42
Avantaje
Echilibrarea ncrcrii
(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 cunoaterea caracteristicilor de procesare i de ncrcare ale
server-elor.
Suplimentar se poate monitoriza starea fiecrui server i, dac apare o

disfuncionalitate, traficul este redirijat ctre alt server din fondul comun.
Cristina Mndru
Slide 43
Avantaje
Server-e Web
performan
i scalabilitate
Fire multiple de execuie, utiliznd un fond comun de fire de execuie din

care fiecare fir poate fi repartizat pentru a trata o cerere nouDSUXW.
Un server cu fire multiple de execuie este mai puin predispus la gtuiri i

la ntrzieri mari pentru cazurile cele mai defavorabile.
Scalabilitate prin nlocuirea procesoarelor cu versiuni mai puternice.
Cristina Mndru
Slide 44
Avantaje
Server-e de aplicaii*
modificabilitate,
scalabilitate,
performan
*Server
Aplicaiile desfurate pe aceste servere implementeaz logica

business iar serverele de aplicaii implementeaz conectivitatea,
care dicteaz modul n care interacioneaz clienii i server-ele.
Au permis transferarea unei poriuni semnificative de

funcionalitate de la clienii fatODWUHDSWDLQWHUPHGLDU.
Au permis bazelor de date s se concentreze pe memorarea,

extragerea i analiza datelor,IUDVHSUHRFXSDGHPRGXOn
care vor fi utilizate datele.
de aplicaii infrastructura pentru o clas de aplicaii ce se execut pe treapta intermediar.
Cristina Mndru
Slide 45
Avantaje
Baze de date performan, scalabilitate, disponibilitate
Utilizeaz n mod frecvent replicarea pentru performan, scalabilitate

i disponibilitate.
Pot utiliza mecanismul de caching pentru performan suplimentar.
Cristina Mndru
Slide 46
PLAN CURS
Stilul peer-to-peer
Cristina Mndru
Slide 47
Tehnologia Java EE
EJB (Enterprise Java Beans)
Definete un API care permite dezvoltatorilor s creeze, s

repartizeze i s gestioneze la server aplicaii bazate pe componente.
JSF(Java Server Faces)
Tehnologie pentru construirea de interfee utilizator din componente.
JSP (Java Server Pages)
Metod pentru crearea de pagini Web dinamice.
Java Servlets
Mecanism de extindere a funcionalitii la server, ce permite crearea

de coninut dinamic.
JMS (Java Messaging Service)
Suport pentru transfer asincron de mesaje utiliznd fie point-to-point

fie publish-subscribe ca stil de interaciune.
Cristina Mndru
Slide 48
Tehnologia Java EE
JNDI (Java Naming and Directory Interface)
Serviciul de directori pentru Java EE, ce permite clientului i servleturilor de pe treapta Web s extrag referine la obiectele utilizator
definite ca EJB.
JTA(Java Transaction Architecture) i JTS (Java Transaction Service)
Permite obiectelor EJB i clienilor lor s participe n procesri

orientate pe tranzacii.
JCA (Java EE Connector Architecture)
Arhitectur standard pentru conectarea platformei Java EE la

sisteme EIS (Enterprise Information Sistems) eterogene.
Include aplicaii mpachetate; exemple:
ERP (Enterprise Resource Planning)
Sisteme CRM (Customer Relationship Management)
Cristina Mndru
Slide 49
Tehnologia Java EE
CAS / COM Bridge (Client Access Services) / (Component Object Model)
Permite integrarea de aplicaii COM i Java EE din cadrul unei

reele.
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 interfee remote
ntre clieni i server-e, pe care le pot implementa utiliznd APIul Java RMI.
JDBC (Java Database Connectivity)
Cristina Mndru
Interfa uniform transparent la o gam larg de baze de date

relaionale.
Baz comun din care se pot construi instrumente i interfee pe
nivele superioare.
Slide 50
Arhitectur Java EE n-Tiered

specializare stil n trepte pentru tehnologia Java EE
Client Tier
Business
Logic Tier
Web Tier
EIS Tier
HTTP
Browser-Based
Client Applications
(HTML, applets,
DHTML/
Scripting)
ERPs
Web Server
Application
Components
Servlets
JSPs
CRMs
Mainframe
TP System
EJBs
RMI over IIOP
Java Client
Applications
CAS COM Bridge
Windows/COM
Client Applications
Container
Services
Components
(e.g JTS, JMS)
RMI
Cristina Mndru
RDBMs
JDBC
Slide 51
Java EE DERUGULDUKLWHFWXUDOH
Treapta client include
Browser-e internet ce trimit cereri HTTP i FTP.
Pagini HTML de la un alt server Web.
Clieni Java de sine stttori (stand-alone) careFRPXQLFGLUHFWFXFRPSRQHQWHOH

de pe treapta business.
Obiecte Microsoft care comunic direct cu componentele de pe treapta business.
Treapta Web H[HFXWXQVHUYHU:HEFHJHVWLRQHD]FHUHULGHODFOLHQi
Rspunde la cereri invocnd servlet-uri sau JSP de pe platforma Java EE.
Servlet-urile interogheaz treapta componentelor business pentru a obine

informaiile ce vor fi returnate clientului.
JSP sunt pagini HTML statice ce conin fragmente de cod servlet invocate de
mecanismul JSP.
Cristina Mndru
Slide 52
Java EE DERUGULDUKLWHFWXUDOH
Treapta componentelor business conine nucleul logicii business n
componente EJB care:
Recepioneaz cereri de la servlet-uri,
Satisfac cererile accesnd diverse surse de date,
Sunt gzduite ntr-un container EJBFDUHFRQWUROHD]i monitorizeaz firele

de execuie EJB.
Treapta EIS conine n mod tipic una sau mai multe baze de date i aplicaii
gzduite 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.
Cristina Mndru
Slide 53
Java EE repartizarea componentelor aplicaiei
Cristina Mndru
Slide 54
Java EE artefactele aplicaiei i organizarea lor
Cristina Mndru
Slide 55
Java EE - concluzii
Java EE este una din abordrile tehnologice pentru construirea sistemelor n-tiered.
Alte abordri;
CORBA (Common Object Request Broker Architecture) de la OMG
Un broker al cererilor pentru obiecte (ORB) permite obiectelor s-i publice interfeele.
Programele client i alte obiecte le pot localiza oriunde n reea 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 atenie pentru a obine un

design optim al arhitecturii aplicaiei n raport cu cerinele de calitate impuse.
n ciuda simplitii i puterii cadrului de implementare Java EE,H[LVWPXOWH

decizii arhitecturale ce trebuie fcute cu atenie.
Cristina Mndru
Majoritatea acestor decizii se vor face cu privire la partiionare i asignare de

responsabiliti nivelelor intermediar i EIS.
Slide 56

Curs 6
Cristina Mndru
Slide 1
PLAN CURS
Stiluri bazate pe evenimente
Stiluri cu evenimente implicite
Stiluri cu date partajate
Stilul repository pasiv
Stilul blackboard
Cristina Mndru
Slide 2
Categorii i semantici
Sisteme bazate pe evenimente

- categorii
Exemple de implementri pentru evenimente

Proiectarea sistemelor bazate pe evenimente
Discuie asupra atributelor de calitate
Evenimente explicite
evenimentele sunt trimise explicit la
anumite elemente.
Comunicare
asincron
fr autoblocare
Evenimente implicite HYHQLPHQWHOH

sunt difuzate ctre elemente. Elementele
rspund la evenimentele de care sunt
interesate.
Cristina Mndru
Slide 3
Invocare implicit
vs.,QYRFDUHH[SOLFLW

Invocare explicit
Obiect
ObiectBB
Obiect
ObiectAA
op1
op2
op3
Obiect
ObiectCC
Invocare implicit
op1
ev1
op2
Obiect
ObiectBB
Obiect
ObiectAA
Obiect
ObiectCC
Cristina Mndru
op3
Slide 4

- semantici

Elemente
obiecte, fire de execuie, procese
Relaii ntre elemente

Comunicarea ntre componente (locale sau distribuite) se face
prin evenimente.
Topologie
Procese concurente slab cuplate
Modelul computaional
Sistem de procese sau obiecte independente care reacioneaz
la evenimente generate n contextul lor i care genereaz la
rndul lor reacii n alte componente ca efect al anunrii de noi
evenimente.
Cristina Mndru
Slide 5

- semantici

Semantici
Evenimente implicite
Emitorii nu cunosc identitatea receptorilor

Ordinea de execuie este non-determinist
Evenimente explicite
Emitorii cunosc identitatea receptorilor

Ordinea de execuie poate fi anticipat.
n ambele variante ale stilului, corectitudinea comportamentului oricrui element ce emite

un eveniment nu depinde de corectitudinea comportamentului nici unuia dintre
elementele care recepioneaz evenimentul.
Cristina Mndru
Slide 6
Implementri 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_destinaie)
Este necesar cunoaterea destinatarului (PID/nume_proces)
Variante de tratare a semnalului recepionat:

ignorare
utilizare aciune implicit
creare i utilizare funcie special definit pentru tratare semnal.
Cristina Mndru
Slide 7

Visual Basic limbaj orientat pe evenimente
Componentele de interfa (Widget-uri) au proprieti, metode i

evenimente.
Widget-urile trimit diferite evenimente n funcie de interaciunile

utilizatorului, de timer-e, etc.
Fiecare widget rspunde la un set fixat de evenimente.
Dezvoltatorii ataaz cod la fiecare tip de eveniment al unui widget,

cod ce va fi executat la apariia evenimentului respectiv.
Limbaj orientat pe evenimente, dar slab OO.

Accesul la proprietile i metodele unui widget nu promoveaz un grad
superior de ncapsulare.
Cristina Mndru
Slide 8

Java -RIHUGRXPHFDQLVPHGHOXFUXFXHYHQLPHQWHOH.
1.
2.
Set predefinit de evenimente utilizabile n dezvoltarea interfeei cu

utilizatorul.
Mecanismul Observer / Observable pentru transmitere i recepionare de
evenimente.
Un obiect Observer reacioneaz prin apelul metodei update() atunci

cnd este notificat de ctre un obiect Observable.
Dezvoltatorii trebuie s scrie codul pentru implementarea metodei

update().
Suport late binding: se pot aduga i elimina obiecte Observer i

Observable n timpul execuiei.
Simultan cu notificarea prin eveniment se pot trimite i obiecte ca parametrii.
Cristina Mndru
Slide 9

Dei implementrile variaz, evenimentele reprezint o caracteristic

puternic a limbajelor moderne.
C++
are event i definete 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 implementri sau extensii de limbaje pentru lucrul cu evenimente.
Cristina Mndru
Slide 10
Implementri la nivel de platform

JMS: Java Messaging Services
Mecanisme pentru lucrul cu evenimente pe platforma CORBA
ESB (Enterprise service bus) - middleware pentru SOA (Service-Oriented

Architecture)
Cristina Mndru
Slide 11
Proiectarea
sistemelor bazate pe evenimente

Sistemele orientate pe evenimente sunt proiectate n mod deliberat de

ctre arhitect.
n proiectarea acestui tip de sisteme arhitectul trebuie s ia n

considerare:
Declaraiile evenimentelor
Structura evenimentelor
Legturile evenimentelor
Anunarea evenimentelor
Concurena evenimentelor
Cristina Mndru
Slide 12
Declararea evenimentelor

Cum ?
Set predefinit de evenimente
Declaraie static de eveniment
Declaraie dinamic de eveniment
Unde ?
Declaraii centralizate
Declaraii distribuite
Sistemele cu evenimente ofer:
nregistrare nregistrare surse de evenimente i nregistrare interes pentru

evenimente
manageri de mesaje/evenimente responsabili cu facilitarea comunicrii

ntre elementele din sistem.
Cristina Mndru
Slide 13
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
Cristina Mndru
Slide 14
Legarea evenimentelor

Cum ?
Static
Dinamic
Cristina Mndru
Slide 15
Anunarea evenimentelor

Cum ?
O singur anunare
Anunri multiple
Ambele
Evenimente pierdute
Evenimentele pierdute vor fi bufferat-e la nivel de element sau centralizat
Coordonarea difuzrii (anunrii) evenimentelor
Cristina Mndru
Slide 16
Concurena evenimentelor

Ce sunt elementele din stil ? Cum trateaz acestea concurena ?
Obiecte
Procese
Fire de execuie
Cum sunt furnizate evenimentele ?
Furnizare total (toate datele, la toate elementele)
Furnizare selectiv (date pariale, la unele elemente)
Furnizare la grup
Cristina Mndru
Receptorii evenimentului sunt identificai pe baza grupului de care

aparin.
Slide 17
Analiza
sistemelor bazate pe evenimente

Problematic
Durata de via a componentelor n raport cu

comunicarea/recepionarea de evenimente.
Sunt evenimentele anunate la momente corespunztoare?
Exist evenimente anunate n momente nepotrivite?
Legturile eveniment-metod sunt suficiente pentru a obine

comportamentul dorit pentru sistem?
Exist posibilitatea de a nu nregistra componente suficiente

sau componentele potrivite la un anume eveniment?
Interferena componentelor
Cristina Mndru
Exist posibilitatea ca dou componente s lucreze concurent

pe date partajate?
Slide 18
Modele pentru dispecerizarea

evenimentelor
Utilizarea unei cozi de mesaje i dispecerizarea evenimentelor n

ordinea n care au ajuns.
Ordine total
Ordinea de generare
Toate obiectele recepioneaz evenimentele n aceeai 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.
Ordine cauzal exemplu:
e3 nu trebuie furnizat nainte

de e1.
Cristina Mndru
e1
e1
e2
e3
Slide 19
Atribute de calitate - discuie

Atribute de calitate ce trebuie considerate la alegerea

stilurilor orientate pe evenimente:
Performana
Reutilizabilitatea
Testabilitatea
Mentenabilitatea
Disponibilitatea
Modificabilitatea/scalabilitatea
Integritatea conceptual
Cristina Mndru
Slide 20

Performana
n general inhibat, datorit non-determinismului:
Ordinea execuiilor operaiilor din sistem este nedeterminat

dificil de:
garantat timpul de rspuns,
realizat planificarea activitilor
Reutilizabilitatea
n general promovat, deoarece elementele pot fi reutilizate simplu,

prin nregistrare la evenimente.
Elementele nu trebuie s cunoasc identitatea altor elemente din

sistem.
Cristina Mndru
Slide 21

Testabilitatea
Testarea este dificil deoarece:
Cristina Mndru
Urmrirea evenimentelor de la anunarea la recepionarea lor

poate fi dificil i poate necesita instrumente i/sau structuri
speciale ale sistemului.
Ordinea operaiilor poate depinde de factori multipli ce

influeneaz generarea i recepionarea evenimentelor.
Datorit non-determinismului, trecerea unui anumit test nu

garanteaz corectitudinea sistemului.
Slide 22

Mentenabilitatea
n general promovat, deoarece elementele lucreaz independent

fr a afecta alte componente (modificrile tind s fie locale).
Poate fi afectat de necesitatea unei coordonri centralizate a:
evenimentelor,
nregistrrilor la evenimente,
politicilor de dispecerizare a evenimentelor.
Disponibilitate
Posibilitatea pierderii de evenimente reduce disponibilitatea

sistemului.
Cristina Mndru
Slide 23

Modificabilitatea / scalabilitatea
n general promovat, deoarece pot fi adugate uor la sistem

elemente noi.
Totui adugarea de elemente noi va crete overhead-ul i va

afecta n final performana.
Integritatea conceptual
Separarea problemelor i integritatea conceptual sunt, n general,

promovate deoarece obiectele au un grad ridicat de independen.
Evenimentele i politica de interaciune pot fi separate clar de

elementele ce interacioneaz.
Este dificil de modelat i analizat comportamentul la momentul

execuiei, datorit non-determinismului.
Cristina Mndru
Slide 24
PLAN CURS
Stilul blackboard
Cristina Mndru
Slide 25
(sisteme Publish Subscribe)

Componente:
Orice component C&C cu cel puin un port publish sau subscribe*.
Conectori:
Conector publish-subscribe cu rolurile announce i listen
Relaii:
Attachment port publish la rol announce; port subscribe la rol listen
Modelul computaional:
Componentele se aboneaz la evenimente. La anunarea unui eveniment de ctre o

component, conectorul dispecerizeaz evenimentul la toi abonaii acestuia.
Un eveniment poate avea nregistrai 0...n receptori.
*Obs. Orice component poate avea unul sau mai multe porturi din fiecare tip.
Cristina Mndru
Slide 26
(sisteme Publish Subscribe)

Invocare implicit YDULDQWDHYHQLPHQWHORULPSOLFLWH
Componente cu interfee procedurale nregistreaz una din

proceduri la un eveniment.
La apariia 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 invocrilor implicite nu este
specificat.
Cristina Mndru
Slide 27
Exemple de sisteme ce utilizeaz

stilul Publish - Subscribe
GUI gesturile utilizator preluate de dispozitive fizice sunt tratate ca evenimente

i sunt trimise la rutine corespunztoare de tratare a acestora.
Aplicaii n stil MVC componentele View sunt notificate la modificarea strii

componentei Model.
Medii de programare extensibile instrumentele sunt coordonate prin

evenimente
Mailing lists abonare la subiecte de interes
Reele sociale notificare friends la modificarea unui site personal
Cristina Mndru
Slide 28
PLAN CURS
Stilul blackboard
Cristina Mndru
Slide 29

Structur de date centralreprezentnd starea curent a sistemului),
asupra creia opereaz un set de componente independente.
Componente:
Depozitar (repository) pentru memorarea (persistena) datelor centralizate.

Accesor date (proces, fir de execuie, obiect), careDFFHVHD]GDWHOH
centralizate.
Conectori:
Connector accesare / modificare date
Relaii :
Attach -LQWHUPHGLD]FRQHFWDUHDDFFHVRUGDWHODGHSR]LWDU.
Cristina Mndru
Slide 30

Topologie
Accesori date slab cuplai aflai 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: relaional, OO, layered, ierarhic.
Localizarea controlului corespunde unor abloane specifice (v. Sld. 33, Sld. 43)
Cristina Mndru
Slide 31

Scalabilitatea, datorit decuplrii i ncapsulrii accesorilor care simplific

adugarea de noi surse de cunotine.
Interoperabilitatea referitoare la datele accesate n comun.
Simplitatea WUHEXLHJDUDQWDWH[FOuderea mutual.
Performana FXWDUHDGDWHORUHVWHFRQVXPDWRDUHGHWLPSi non-deterministic.
Modificabilitatea GLILFLOGDFVXQWQHFHVDUHVFKLPEULn structura datelor

partajate.
Securitatea QHFHVLWDWHDDVLJXUULLi verificrii identitii accesorilor.
Cristina Mndru
Slide 32

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
informaiilor din depozitar.
Exemple: baze de date cu interogare continu,

triggere pe date.
Cristina Mndru
Slide 33
PLAN CURS
Stilul blackboard
Cristina Mndru
Slide 34
Stilul repository pasiv - variante

Memorie partajat
Depozitarul central de date este n mod tipic n memoria volatil (n puncte

strategice ale execuiei, starea se poate pstra i pe medii de durat mai mare).
Accesorii sunt strns cuplai cu depozitarul.

Accesorii sunt fire de execuie concurente, procesoare sau obiecte ce
acceseaz depozitarul.
Accesorii opereaz independent unul de altul.
Controlul general este distribuit ntre accesori.
Cristina Mndru
Slide 35
Stilul repository pasiv - variante

Baze de date clasice
Depozitarul central pstreaz starea datelor pe termen lung (persistena).

Accesorii sunt aplicaii software, deseori aflate la distan fa de
depozitarul central de date.
Accesorii opereaz independent asupra datelor din depozitar, n ce
privete interogrile i actualizrile.
Controlul general este distribuit ntre accesori.
Exist suport pentru lucrul cu tranzacii.
Cristina Mndru
Slide 36
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:
Cristina Mndru
tranzacii
securitate
controlul concurenei
integritatea datelor
Slide 37
PLAN CURS
Stilul blackboard
Cristina Mndru
Slide 38
Stilul blackboard
Stil flexibil pentru rezolvarea colaborativ a unei probleme.
Rezultat al cercetrilor n domeniul inteligenei artificiale.
Aplicabilitate n domeniul industrial la:
Procesare de semnale
Radare
Prelucrare de imagini
Procesarea vorbirii
Cristina Mndru
Slide 39
Semantici i atribute de calitate

Detalii
Stilul blackboard
Problematica proiectrii
Elemente
depozitar (blackboard),
surse de cunotine,
control.
Relaii ntre elemente
Evenimente pentru notificarea surselor de cunotine.
Flux de date transferat de sursele de cunotine cu depozitarul.
Cristina Mndru
Slide 40

Detalii
Stilul blackboard
Topologie
variabil; sursele de cunotine legate direct i independent la depozitar.
Semantici
Sursele de cunotine:
Procese independente capabile s rezolve probleme specifice.
Lucreaz independent n zona lor de experiz pentru a rezolva mpreun o problem

complex.
Nu interacioneaz ntre ele n mod direct; nu cunosc ce alte surse de cunotine sunt
active simultan.
Depozitarul
Partiionat n regiuni, a.. sursele de cunotine transfer date cu un anumit nivel de

structurare i abstractizare.
Elementul de control - este responsabil cu planificarea urmtoarei surse de cunotine ce

trebuie activat.
Cristina Mndru
Slide 41

Detalii
Stilul blackboard
Legate n special de soluionarea problemelor de inteligen artificial :

modificabilitate, scalabilitate, mentenabilitate, interoperabilitate,
separabilitate calcule.
Simplitatea
dezvoltarea surselor de cunotine este complicat i poate necesita expertiz
de domeniu superioar.
Performana
Fiind n mare msur non-deterministice, este dificil de estimat durata obinerii
rspunsului.
Problema de ansamblu este rezolvat n manier incremental, secvenial.
Testabilitatea
Dificil de testat i de analizat corectitudinea aplicaiei.
Cristina Mndru
Slide 42

Detalii
Stilul blackboard - detalii
Cunotinele din domeniul aplicaiei sunt partiionate i codificate ntr-o colecie de

componente numite surse de cunotine.
Elementele stilului:
Blackboard - depozitar organizat ierarhic n care se salveaz soluiile generate de sursele de

cunotine.
Datele din depozitar:
Surse de cunotine
reprezint starea complet (intermediar /ILQDO) a soluiei problemei,

sunt deseori eterogene,
sunt organizate ierarhic.
Rspund la modificrile din starea blackboard-lui.
Genereaz soluii independente i scriu n blackboard soluii complete sau pariale.
Modulul de control (scheduler/control shell)
Selecteaz (funcie de logica aplicaiei) o surs de cunotine i o planific pentru

execuie.
Determin momentul n care problema este rezolvat.
Cristina Mndru
Slide 43

Detalii
Topologie: (2 variante)
Exist un element explicit de control.
Nu exist element explicit de control.

Sursele de cunotine (KSs) sunt activate
de starea blackboard-lui.
Sursele de cunotine sunt planificate/activate de

ctre elementul de control, n urma monitorizrii de
ctre acesta a strii blackboard-lui.
KS1
KS1
Blackboard
Blackboard
:
:
KSn
KSn
Citire/Monitorizare
stare
Control
Proces
Cristina Mndru
Depozitar date
:
:
Accesare date (read/write)
Planificare i
invocare surse de
cunotine
Invocare
Slide 44

Detalii
Elementul BLACKBOARD
Structur de date partajat disponibil surselor de cunotine.
Depozitarul sistemelor blackboard servete ca memorie primar (brut) ce conine

date de intrare pentru sursele de cunotine, soluii pariale, alternative, soluii
finale.
Elementul blackboard ofer mecanisme de comunicare ce permit realizarea de

operaii de citire i scriere de ctre sursele de cunotine i de ctre elementele de
control.
Mecanismele pentru planificare, control i activare a surselor de cunotine pot fi

implementate direct n blackboard sau n elemente externe acestuia.
Modificrile din coninutul blackboard-lui genereaz notificri ctre surse de

cunotine, care vor reaciona corespunztor la prezena sau la modificarea
anumitor informaii.
Cristina Mndru
Slide 45

Detalii
Elementul BLACKBOARD
Aplicaiile 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 informaii.
Sursele de cunotine citesc i scriu informaii din/n regiuni specifice.
Aceste abstractizri sunt utile proiectanilor i faciliteaz cutri rapide i

sistematice realizate de ctre sursele de cunotine.
Date coninute pot fi
statice,
dinamice generate n timpul execuiilor.
Cristina Mndru
Slide 46

Detalii
Elementele SURSE DE CUNOTINE
Fiecare surs de cunotine este specializat n rezolvarea anumitor

aspecte ale problemei de ansamblu.
Funcionare independent de alte surse de cunotine; sursele de cunotine nu se

cunosc ntre ele.
Fiecare surs de cunotine contribuie la soluionarea problemei.
Sursele de cunotine sunt capabile s transfere date cu elementul blackboard.
Sursele de cunotine sunt capabile s utilizeze anumite informaii din blackboard

pentru a construi sau a rafina cunotine.
n unele aplicaii sursele de cunotine culeg date din exterior i le utilizeaz pentru
a aduga cunotine n blackboard.
Cristina Mndru
Slide 47

Detalii
Elementele SURSE DE CUNOTINE
Implementrile sunt partiionate pe baz de condiii i aciuni.

Surs de cunotine (KS)
invoc, declaneaz,
execut...
Condiie
Aciune
Specific o condiie n care sursa de

cunotine contribuie la rezolvarea
problemei.
La ndeplinirea condiiei se invoc
aciunea corespunztoare.
Cristina Mndru
Modificare sau plasare de cunotine noi n

blackboard.
Aciunile pot include noi condiii.
Slide 48

Detalii
Elementul de CONTROL
Responsabilitile generale ale elementului de control:
Dirijarea ntregului proces de rezolvare a problemei prin coordonarea surselor de

cunotine n a rspunde la modificrile din coninutul blackboard.
Pe baza rezultatelorDFWLYULLXQHLVXUVHGHFXQRtine, elementul de control poate
determina sursa de cunotine cea mai potrivit a fi activat la pasul urmtor,
planifica execuia surselor de cunotine,
estima fidelitatea soluiei,
finaliza rezolvarea problemei.
Controlul poate s difere n mod substanial la diferite implementri ale

stilului.
Cristina Mndru
Slide 49

Detalii
Stilul blackboard
Situaii n care se sugereaz utilizarea stilului blackboard:
Exist mai multe moduri de a rezolva problema.
Exist mai multe rspunsuri corecte.
Rspunsul cel mai bun poate varia i depinde de mai muli factori.
Sunt necesare expertize diverse pentru soluionarea problemei.
Exist incertitudini, erori i variaii la nivelul surselor de date disponibile

(ex. Raport sczut ntre semnal i zgomot).
Cristina Mndru
Slide 50

Detalii
Stilul blackboard problematica proiectrii

Reprezentare date - Comunicarea ntre elemente se face prin intermediul informaiilor
din blackboard.
Sensibilizare - Elementele trebuie s devin contiente de evenimentele relevante.

Investigare - Crearea de elemente care pot gsi informaii relevante n mod eficient.
Interaciune - Crearea de elemente capabile s utilizeze datele intermediare produse de
alte elemente.
Integrare - Combinarea sub forma unui rspuns coeziv a rezultatelor produse de diferite
elemente.
Coordonare - Determinarea elementelor s-i concentreze activitile pe lucrurile potrivite

la momentul potrivit.
Cristina Mndru
Slide 51

Detalii

Proiectarea surselor de cunotine
Codificarea i reprezentarea cunotinelor
Formatul de reprezentare a datelor specifice
Formate de date recunoscute
Mecanisme de preluare a datelor din blackboard
Posibile surse externe de date
Cristina Mndru
Slide 52

Detalii

Proiectarea surselor de cunotine (cont.)
mpachetarea codului sub form de fir de execuie, proces sau obiect
Nivelul de detaliu al contribuiei la blackboard (doar rezultatul, expunerea

rezultatelor intermediare, etc.); are impact asupra performanei.
Modul de gsire a soluiilor: n paralel, ntreesut, secvenial.

Concurena mbuntete performana dar crete foarte mult
complexitatea sistemului.
Unele probleme nu pot fi rezolvate cu o abordare concurent.
Modul de ntiinare despre modificrile din blackboard

Interogare
Evenimente
Apel de metod
Cristina Mndru
Slide 53

Detalii

Proiectarea elementului blackboard
Reprezentarea informaiilor :
compromis ntre expresivitatea reprezentrilor nelese de puine surse de cunotine i

reprezentri mai generale nelese de toate sursele de cunotine.
abstractizri de reprezentare mai expresive au impact negativ asupra performanei.
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 relaiilor : detectarea i eliminarea informaiilor duplicat.
Gestionarea gruprii atributelor : detectarea de atribute similare n obiecte diferite

i gruparea lor ntr-un singur obiect.
Gestionarea propagrii valorilor : detectarea de modificri ale valorilor din

informaiile nrudite i reacionarea n mod corespunztor.
Cristina Mndru
Slide 54

Detalii

Proiectarea controlului
Implementarea controlului ntr-un element separat sau n blackboard

compromis referitor la separarea problemelor i modificabilitate.
Abordarea arbitrrii surselor de cunotine: Planificare vs. Selectarea

urmtoarei surse de cunotine.
Maximizarea progresului soluionrii problemei i minimizarea efortului

de calcul.
Determinarea momentului obinerii soluiei necesit suficiente informaii

despre blackboard fr ns a avea expertiza colectiv a surselor de cunotine.
Codificarea rspunsului (dificil)

Uor de construit sisteme blackboard cu criterii de terminare suboptime.
Soluia ideal e mai uor de codificat dect soluiile practice suficiente.
Multe obiective i soluii sunt bazate pe euristici.
Cristina Mndru
Slide 55

Detalii
Proiectarea controlului (cont.)

Modelul de rezolvare a problemei utilizat:
Raionament backward GHODVWDUHDILQDOFWUHVWDUHDLQLial.
Raionament forward de la starea iniial ctre atingerea obiectivului.
Raionament oportunistic
Cristina Mndru
ncepe cu un set de fapte cunoscute.
Continu n funcie de direcia care pare cea mai productiv.
Slide 56

Detalii
Stilul blackboard exemplu
Surse de cunotine
Condiie
Aciune
Strat n
Blackboard
:
Strat 3
Condiie
Aciune
Strat 2
Strat 1
Condiie
Aciune
Control
Blackboard
Monitor
Coad
control
date
Control
Cristina Mndru
Planificator
Slide 57

Curs 7
Cristina Mndru
Slide 1
PLAN CURS
Perspectiva static module views
Stilul decomposition
Stilul uses
Stilul generalization
Stilul layered
Stilul aspects
Stilul data model
Perspectiva alocrii allocation views
Stilul deployment
Stilul install
Stilul work assignment
Cristina Mndru
Slide 2
Perspectiva static modul n care sistemul este structurat ca set

de uniti de implementare (cod).
Vederile reprezint modulele sistemului. Tipul de vedere este
Module Viewtype.
Tipuri elemente :
modul XQLWDWHGHLPSOHPHQWDUHDXQXLVHWFRHUHQWGH
responsabiliti
Tipuri relaii:
is part of descompunere n submodule/subsisteme
depends on uses, allowed to use, crosscuts, data relationship
is a generalizare, realizare interfa
Cristina Mndru
Slide 3

Module views ilustreaz:
structura sistemului descompus n uniti de cod
LSRWH]HDVXSUDVHUYLFLLORURIHULWHGHPRGXOH
agregarea unitilor n ansamble
structurile globale de date (afectate de sau cu impact asupra mai multor module)
Cristina Mndru
Slide 4

Utilitate
Schi (plan, model) pentru construirea codului
Definirea alocrii sarcinilor, timpului, bugetului de dezvoltare
Planificarea dezvoltrii incrementale
Analiza trasabilitii cerinelor (ndeplinirea cerinelor prin colaborarea modulelor)
Analiza impactului modificrilor (pe baza relaiilor dintre module)
Explicarea funcionalitii sistemului
Explicarea structurii codului
Ilustrarea structurii informaiilor persistente
Cristina Mndru
Slide 5

Modul SURSULHWi tipice
Nume
Set coerent de responsabiliti
Aciunile realizate
Cunotinele gestionate
Deciziile
Rolul n cadrul ansamblului sistemului, relativ la funcionalitate i atribute de

calitate.
Interfeele i vizibilitatea acestora

Informaii de implementare
Corespondena cu unitile de cod surs (fiiere cod, date, test, configurare)
Informaii testare (plan, cazuri de testare, structuri, date)
Informaii management (anticipare buget, grafic)
Constrngeri de implementare
Proprieti specifice stilului
Cristina Mndru
Slide 6
PLAN CURS
Stilul uses
Stilul layered
Stilul aspects
Stilul data model
Stilul deployment
Stilul install
Cristina Mndru
Slide 7
Figure from : Clements, Bachmann, Bass, Garlan, Ivers, Little, Nord, Stafford, Documenting Software
Definirea structurii sistemului n termeni de module i submodule ale
acestora.
Primul pas n dezvoltarea modelului arhitectural.

Definete modulele ce apar n restul vederilor statice i organizarea lor.
Tipuri de elemente : modul, subsistem

Tipuri de relaii : is part of
Constrngeri :
nu sunt permise bucle n graful descompunerii
un modul poate fi coninut ntr-un singur modul
Cristina Mndru
Slide 8
Subsistem (grup de module) SDUWHDXQXLVLVWHPFDUH:
Implementeaz un subset coeziv al funcionalitii sistemului

Poate fi executat i testat independent (corespunde unui grup de
componente)
Util n dezvoltare i repartizare incremental.

Obs.
Subsisteme diferite pot avea pri comune
Nu orice parte a unui sistem este subsistem (ex. bibliotec cu funcii utilitare)
Cristina Mndru
Slide 9
Criterii de descompunere:
ndeplinire atribute de calitate
Ex. Modificabilitate aplicarea principiului de ascundere a informaiilor ncapsulare

aspecte modificabile n module separate ORFDOL]DUHDPRGLILFULORU.
Decizii de reutilizare
Reutilizare UHVSRQVDELOLWi predefinite DORFDUHDUHVWXOXLGHUHVSRQVDELOLWi.
Implementare linii de produse software difereniere module comune de

module variabile.
Repartizare sarcini GH]YROWDUHSDUDOHO; competene echip.
Cristina Mndru
Slide 10
Figures from : Clements, Bachmann, Bass, Garlan, Ivers, Little, Nord, Stafford, Documenting Software
Notaii:
Informale
casete cu nume, incluse
liste identate
UML
pachete i clase
subsisteme
adnotri UHVSRQVDELOLWile
stereotipuri - informaii suplimentare de tip
Cristina Mndru
Slide 11
PLAN CURS
Stilul uses
Stilul layered
Stilul aspects
Stilul data model
Stilul deployment
Stilul install
Cristina Mndru
Slide 12
Stilul uses
Definete relaii de dependen ntre module.
Tipuri de elemente : modul, subsistem
Tipuri de relaii : uses (specializare a relaiei depends on)
A uses B = A depinde de existena i corectitudinea lui B.

Ex.
A utilizeaz un dispozitiv partajat lsat ntr-o stare utilizabil de ctre B
A utilizeaz un rezultat lsat de B ntr-o variabil partajat
A sleepsSkQFH%WULPLWHXQVHPQDOawaken.
Contra Ex: A calls B (exception handler) - - B nu influeneaz corectitudinea lui A.
Cristina Mndru
Slide 13
Stilul uses
Notaii:
Informale
UML
boxes and lines

tabelar
pachete, clase, subsisteme

asociere stereotipat
Cristina Mndru
DSM
Dependency Structure Matrix
Slide 14
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 relaia uses.
Cristina Mndru
Slide 15
Coresponden vederi
Specificaii sistem:
Accept flux de caractere pe intrare.

Produce flux de caractere pe ieire conform
unei configuraii date.
Cristina Mndru
Maparea elementelor vederilor
C&C view
Module
view
sistemul
main
Split
split, config,
stdio
To_lower
to_lower,
config, stdio
To_upper
to_upper,
config, stdio
Merge
merge,
config, stdio
fiecare
conduct
(pipe)
stdio
Slide 16
PLAN CURS
Stilul uses
Stilul layered
Stilul aspects
Stilul data model
Stilul deployment
Stilul install
Cristina Mndru
Slide 17
Definete relaii de generalizare/specializare ntre module.
Generalizare FDSWXUDUHWUVWXULFRPXQH
Specializare capturare variaii
Extindere DGXJDUH/eliminare/modificare specializri

Evoluia trsturilor comune PRGLILFDUHJHQHUDOL]UL
Tipuri de elemente : modul

Tipuri de relaii : is a
Constrngeri : nu sunt permise cicluri
Nu se recomand motenirea multipl!
Cristina Mndru
Slide 18
Notaii:
UML
interfee i clase
generalizare clas / interfa
realizare interfa
Cristina Mndru
Slide 19
Utilizare n modele OO
Proiectarea incremental a unui modul prin extensii succesive
Modelare variaii prin modificri locale
Reutilizarea abstractizrilor
Cristina Mndru
Slide 20
PLAN CURS
Stilul uses
Stilul layered
Stilul aspects
Stilul data model
Stilul deployment
Stilul install
Cristina Mndru
Slide 21
Stilul layered
Definete 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 relaii : allowed to use
A is allowed to use %= Implementarea oricrui modul din stratul A poate utiliza
oricare din facilitile publice oferite de stratul B.
Cristina Mndru
Slide 22
Stilul layered
Constrngeri :
un modul aparine unui singur strat (layer)
exist cel puin 2 straturi
relaia 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
acelai strat.
Cristina Mndru
Slide 23
Stilul layered
Criterii grupare:
Se anticipeaz evoluie independent
Nivele de competene necesare n dezvoltare
Ex. Presentation layer asignat unei echipe competente n utilizarea tehnologiilor GUI
Nivele de reutilizare
Nivele de abstractizare
Necesiti de portabilitate
Layere-le inferioare sunt independente de cele superioare.

Fiecare layer prezint o interfa care ascunde dependenele de layere-le inferioare.
Cristina Mndru
Slide 24
Stilul layered
Notaii:
Informale
Stiv cu/far sgei
Straturi segmentate
Inele concentrice
Straturi transversale
Straturi tridimensionale
UML
Reprezentare:
pachete stereotipate
Straturi
Coninut straturi
dependen stereotipat
Cristina Mndru
Relaii : ntre straturi,

ntre segmente
Slide 25
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 aplicaiei (modul cod corespunztor).
Aplicaie
Key
layer
SO
allowed to use
callback
Hardware
Nu violeaz constrngerile stilului deoarece funcionarea corect a

hardware-lui nu depinde de existena i funcionarea corect a SO, iar
funcionarea corect a SO nu depinde de existena i funcionarea corect
a aplicaiei.
Cristina Mndru
Slide 26
Stilul layered
Utilizare DSM pentru depistare dependene care violeaz semanticile
stilului.
(a) Allow to use doar pentru

nivelul imediat inferior.
(b) Allow to use pentru orice
nivel inferior.
Cristina Mndru
Slide 27
Comparaie: 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 execuie.
Elementele de tip trepte sunt procese/fire de execuie care sunt vizibile la
momentul execuiei; sunt reprezentate n vederi de tip C&C.
EXEMPLU
rezult structur vizibil la

execuie
Fie urmtoarele trei straturi
UI
Aplicaie
Broker
Servicii comune
Abstractizri SO
Data Tier
dup compilare
PERSPECTIVA STATIC
Cristina Mndru
PERSPECTIVA DINAMIC
Slide 28
Comparaie: layers vs. decomposition

Avionics system
Behavior-hiding module
Software-decission hiding module
Cristina Mndru
Hardware-hiding module
Slide 29
PLAN CURS
Stilul uses
Stilul layered
Stilul aspects
Stilul data model
Stilul deployment
Stilul install
Cristina Mndru
Slide 30
Stilul aspects
Definete module ce implementeaz interese transversale i relaii ale
acestora cu restul modulelor.
Interese transversale ex. : controlul accesului, managementul tranzaciilor,

jurnalizare
Modificabilitate VLPSOLILFDUHDPRGXOHORUFHLPSOHPHQWHD]IXQFionalitate 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 relaii : crosscutts leag modul aspect de alt modul
Constrngeri :
un modul aspect nu se poate lega cu el nsui.
Cristina Mndru
Slide 31
Stilul aspects
Notaii: UML
Aspectclas stereotipat
Pointcut specification (lista modulelor afectate) : comentariu descriptiv sau
relaie stereotipat
Cristina Mndru
Slide 32
PLAN CURS
Stilul uses
Stilul layered
Stilul aspects
Stilul data model
Stilul deployment
Stilul install
Cristina Mndru
Slide 33
Stilul data model

Descrie structura static a informaiilor n termeni de entiti i relaii
ntre acestea.
Nivele de abstractizare:
conceptual
logic
fizic
Tipuri de elemente : data entity obiect cu informaii ce trebuie reprezentate n sistem

Tipuri de relaii : asociere, generalizare/specializare
Constrngeri :
De evitat dependenele funcionale.
Cristina Mndru
Slide 34
Stilul data model

Notaii:
ERD (Entity-Relationship Diagram)
crows foot ERD
UML
Diagram clase
Cristina Mndru
Slide 35
Stilul data model

Model conceptual
- domeniul problemei
Model logic
- conformarea cu o tehnologie de
management (ex. relaional, OO)
Evoluie model date
Model fizic
-detalii de implementare
-optimizri
Cristina Mndru
Slide 36
PLAN CURS
Stilul uses
Stilul layered
Stilul aspects
Stilul data model
Stilul deployment
Stilul install
Cristina Mndru
Slide 37
Perspectiva alocrii modul n care sistemul se relaioneaz cu

structurile (software i non-software) din contextulVX.
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]DWGHSURSULHWi solicitate contextului
element de context DUHSURSULHWi oferite sistemului
Tipuri relaii:
allocated to un element software este alocat unui element de

context.
Cristina Mndru
Slide 38

Stilurile fundamentale ale perspectivei alocrii.
Cristina Mndru
Slide 39
PLAN CURS
Stilul uses
Stilul layered
Stilul aspects
Stilul data model
Stilul deployment
Stilul install
Cristina Mndru
Slide 40
Stilul deployment
Definete amplasarea componentelor i conectorilor arhitecturii software
pe infrastructura hardware/software.
software : component, conector
de context : procesor, memorie, disk reea (router, canal comunicare, firewall, bridge)
Tipuri de relaii : allocated to, migrates to, copy migrates to, execution mogrates
to (alocare dinamic)
Cristina Mndru
Slide 41
Stilul deployment
Utilitate:
Analiza i mbuntirea unor atribute de calitate

Performana
Echilibrare ncrcare
Diminuare trafic (volumul i frecvena comunicrilor ntre elemente de infrastructur)
Creterea performanei infrastructurii (adugare/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 testrii i integrrii sistemului
Evaluare costuri
Cristina Mndru
Slide 42
Stilul deployment
Notaii:
UML
Deployment diagram
Formale
AADL (Architecture Analysis and Design Language)
SysML (System Modelling Language)
Cristina Mndru
Slide 43
PLAN CURS
Stilul uses
Stilul layered
Stilul aspects
Stilul data model
Stilul deployment
Stilul install
Cristina Mndru
Slide 44
Stilul install
Definete organizarea componentelor arhitecturii software ca structur
de fiiere.
software : component
de context : element configuraie (fiier, folder)
Tipuri de relaii :
allocated to -FRPSRQHQWDORFDWODHOHPHQWFRILJXUDie
containment element configuraie coninut n element cofiguraie
Cristina Mndru
Slide 45
Stilul install
Utilitate:
Creare de proceduri pentru build-and-deploy
Navigare/cutare n structura de fiiere a sistemului instalat
Selectare i configurare fiiere pentru construirea unui pachet specific de

instalare (ex. o anumit versiune)
Actualizarea i configurarea fiierelor unei versiuni cu instalri multiple
Identificare fiier lips sau defect
Proiectarea i implementarea unei caracteristici de actualizareDXWRPDW
Cristina Mndru
Slide 46
Stilul install
Notaii:
UML
informale
<<artifact>> - element configuraie

<<manifest>> - relaia containment
*.jar Java archive

*.war Web archive
*.ear Enterprise archive
Cristina Mndru
Slide 47
PLAN CURS
Stilul uses
Stilul layered
Stilul aspects
Stilul data model
Stilul deployment
Stilul install
Cristina Mndru
Slide 48

Definete repartizarea componentelor arhitecturii software la echipele de
dezvoltare.
software : modul
de context : unitate organizaional (persoan, echip, departament, subcontractor)
Tipuri de relaii :
allocated to
Cristina Mndru
Slide 49

Utilitate:
Repartizarea activitilor 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
Cristina Mndru
Slide 50

Notaii: informale
Provenite din vederea descompunerii (stilul decomposition)

Cristina Mndru
Slide 51
Alte stiluri ale alocrii
Stilul implementation repartizarea artefactelor de dezvoltare (clase, programe, script-uri,

cazuri de testare, fiiere make, documentaie, ...)
pe structura de fiiere a contextului de dezvoltare
Stilul data stores UHSDUWL]DUHDHQWLWilor de date (ex. tabele) pe servere hardware
Specializri ale stilului deployment pentru tehnologie
Microsoft (Tiered Distribution)
IBMs WebSphere topologies
Specializri ale stilului work assignment
Stilul platform repartizare artefacte de dezvoltare la locaii 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

independeni, n conformitate cu o strategie de integrare tehnic.
Cristina Mndru
Slide 52

Curs 8
Cristina Mndru
Slide 1
Procesul de proiectare arhitectural
Cerine i nevoi
nestructurate
Ghid pentru arhitect
Cristina Mndru
ar
hi
te
Constrngeri
de proiectare
ct
Funcionalitate global Atribute de calitate

Constrngeri business i tehnice
Ciclul de influene
Stakeholder-i
Decizii de
proiectare
Slide 2
Proiectarea arhitectural
Proiectul arhitecturii (design-ul arhitectural)
Este primul artefact al proiectrii
La trecerea de la CE este necesar la CUM se realizeaz.
Activitile arhitectului software:
Partiioneaz sistemul n elemente
Definete responsabilitile elementelor
Definete relaiileGLQWUHHOHPHQWH
Creaz documentaia
Repet (de cte ori e necesar)
Proiectarea arhitectural este influenat de:
Organizaie
Caracteristicile produsului
Procesul de dezvoltare de software

Cristina Mndru
Slide 3
Influena caracteristicilor produsului

Exemplu: caracteristica : Complexitatea sistemului
Arhitectura sistemelor complexe este ierarhic:
Spaiul de proiectare al unui arhitect este element pentru alt arhitect
Poate necesita utilizarea arhitecturii ntregului sistem/ntreprindere
Necesit echipe de arhiteci
Plasarea n context:
Arhitectura ntreprinderii
CONSTRNGE
Arhitectura sistemului
Arhitectura software-lui
Proiectul de detaliu
pentru software
Cristina Mndru
Slide 4
Influena factorilor organizaionali
Constrngeri impuse de :
ncadrarea ntr-un grafic al livrabilelor
Dezvoltare distribuit
Dimensiunea organizaiei
Structura organizaiei
Arhitectul trebuie s neleag factorii organizaionali i impactul lor

asupra arhitecturii sistemului software.
Cristina Mndru
Slide 5
Influena 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

cteva cerine:
Nu este necesar identificarea tuturor cerinelor nainte de a ncepe

proiectarea arhitectural.
Proiectul arhitecturii va permite descoperirea de cerine

necunoscute sau puin nelese i poate ajuta, de asemenea, la
rafinarea cerinelor.
Se recomand ca proiectarea arhitectural s fie iterativ, indiferent

de modelul procesului software.
Cristina Mndru
Slide 6
Pre- i Post- condiii ale procesului de proiectare a

arhitecturii
Intrri cerine i constrngeri (architectural drivers)
Cerine funcionale de nivel superior (generale).
Cerine pentru atributele de calitate.
Constrngeri tehice i business.
Ieiri
Descompunerea arhitectural: elemente, responsabiliti, relaii i

interfee
Documentaia :
reprezentri ale arhitecturii din cele 3 perspective fundamentale
date, motivaii, proz descriptiv, etc.
Cristina Mndru
Slide 7
Cerine funcionale i constrngeri
Cerinele funcionale de nivel superior sunt acele cerine

funcionale care au impact asupra arhitecturii
Descrierile textuale ale comportamentului obligatoriu al sistemului

(...shall...).
Cazurile de utilizare ce descriu modul n care opereaz sistemul.
Constrngerile includ
Constrngerile tehnice - devin cerine n care deciziile de proiectare

sunt pre-specificate.
Constrngerile business sau programatice -QXVXQWGHQDWXU

tehnic dar au un impact indirect profund asupra proiectului
arhitecturii.
Cristina Mndru
Slide 8
Cerinele pentru atributele de calitate sunt deseori derivate din

specificaii abstracte
Competitivitate pe o pia cu costuri sczute.
Sistemul trebuie s fie sigur.
Sistemul trebuie s fie modificabil.
QAW (Quality Attribute Workshop) este o tehnic bun pentru

obinerea de scenarii iniiale pentru atributele de calitate, DAR
De obicei se obin 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.
Cristina Mndru
Slide 9
Rafinare scenariu pentru atribut de calitate

Exemplu de cerin pentru un atribut de calitate:
Un mesaj neanticipat este recepionat de un proces al sistemului n timpul funcionrii
normale. Procesul trebuie s informeze operatorul i s continue operarea n mod
normal, fr a avea perioade de nefuncionare.
Atributul de calitate vizat

Este o descriere rezonabil a acestuia (n sensul c se poate proiecta o arhitectur
utiliznd acest scenariu) ?
Arhitectul va rafina scenariile iniiale 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-iniializarea discului n background.
Cristina Mndru
Slide 10
Rafinare continu
Se pot utiliza componentele scenariului pentru atribute de calitate (v.curs 3 slide
19)SHQWUXUDILQDUHDFRQWLQXDVFHQDULLORUSHQWUXDWULEXWHOHGHFDlitate.
Surs pentru stimul entitatea care a generat un stimul
Stimul o condiie care afecteaz sistemul
Context contextul (referitor la sistem) n care a aprut stimulul
Artefact elementul sistemului ce a fost stimulat de ctre stimul
Rspuns activitatea ce rezult n sistem din cauza stimulului
Msuri ale rspunsului msura prin care va fi evaluat rspunsul sistemului la stimul
Se rafineaz scenariile atributelor de calitate pe msur ce se analizeaz,

se descompune i/sau se modific arhitectura sistemului software.
Cristina Mndru
Slide 11
Cerine i constrngeri vs. specificaii de sistem

Nu sunt necesare specificaii detaliate nainte de a se ncepe
Pe msur ce se exploreaz i se analizeaz cerinele i

constrngerile n dialog cu stakeholder-ii, se fac noi descoperiri
despre spaiul cerinelor. De obicei nu apar noi cerine ci se ajunge
la o mai bun nelegere a celor existente.
Proiectul arhitecturii ofer un instrument natural pentru rafinarea i

stabilizarea cerinelor i ajut la descoperirea zonelor potenial
problematice.
Toate cerinele se vor maturiza pe msur ce se dezvolt proiectul

arhitecturii.
Cristina Mndru
Slide 12
Exemplu
Fie urmtorul scenariu pentru atribut de calitate:

n condiii de operare normal i pentru orice configuraia de vehicul aerian, simulatorul
software preia eantioane de date de intrare de la toate comenzile de intrare de la
pilot i actualizeaz toate afiajele cu o frecven de 75Hz.
n esen, arhitectul trebuie s rspund la urmtoarea ntrebare:

Fiind dat acest stimul provenit din aceast surs, la aceste artefacte, n aceste condiii
(context), rspunde sistemul aa cum este precizat n msuraLQGLFDWSHQWUX
rspuns?
Surs pentru stimul

Stimul
Context
Artefact
Rspuns
Msuri ale rspunsului
Cristina Mndru
Slide 13
Ghid pentru arhitectul software

Identificarea contextului
Selectarea unui element de pornire, descompunere, rafinare
Consolidarea documentaiei
Evaluarea arhitecturii
Repetare procedur
Obs. Dac sunt implicate i sisteme legacy atunci trebuie n prealabil descoperit i evaluat
arhitectura acestora.
Cristina Mndru
Slide 14
Exemplu
Simulator de zbor
Intrri de la pilot : crm, elevator, eleron, acceleraie
Ieiri : afirile simulatorului, micarea simulatorului
Cristina Mndru
Slide 15
Exemplu contextul business

Specificaiile sistemului
Obiectivul : construirea unui simulator general pentru antrenare, ieftin i portabil
Controlul micrii se face simplu i e bazat pe sistem cardanic
Suport pentru max. 3 (243cm X 138cm X 9,5 cm) panouri de afiare plate pentru vederile
din exteriorul cabinei de pilotaj
Un panou de afiare plat mic pentru instrumentele de msur
Procesoare bazate Intel HDJUHDWVROXia cu procresoare multiple.
Responsabiliti contractuale:
Contractorul principal este responsabil pentru sistemul cardanic, carcasa simulatorului, controalele
pilotului (crm, elevator, eleron, acceleraie) i pentru panourile de afiare.
Presupunem c suntem subcontractori pentru dezvoltarea software-lui, contractorul principal
avnd responsabilitatea construirii simulatorului.
Cristina Mndru
Slide 16
Hardware-ul simulatorului
Intrare
Aparate de msur
Afiaj frontal
Comenzi pilot
Afiaj lateral
Afiaj frontal
Carcasa
Carcasa
Aparate de msur
Comenzi pilot
Afiaj lateral
Afiaj lateral
Pilot
Sistem cardanic
Pilot
Vedere lateral
Cristina Mndru
Vedere de sus
Slide 17
Cerine cheie (1)

C1. Sistemul accept intrri de la pilot prin intermediul crmei,
elevatorului, eleronului i acceleraiei
Actualizeaz 3 afiaje pentru a oferi imagini din afara cabinei.
Actualizeaz afiajul pentru instrumentele de msur (altitudine,

orizont artificial, poziie, combustibil, senzor RPM, unghiul de
urcare/coborre).
Activeaz sistemul cardanic pentru a simula forele 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.
Cristina Mndru
Slide 18
Cerine cheie (2)

C3. Sistemul trebuie s ofere rspuns instantaneu (actualizarea
imaginilor i a micrii) la comenzile pilotului, a.. s ofere o
experien realist i s previn rul de simulator.
C4. Sistemul trebuie s fie uor de dezasamblat i mutat n alt locaie.
C5. Ulterior punerii sale n funciune, sistemul trebuie s permit
editarea de noi controale de zbor.
Este evident necesar rafinarea i analiza acestor cerine nainte de

nceperea proiectrii.
Cristina Mndru
Slide 19
Stabilire context
Problematic general:
Poziia arhitectului software n raport cu alte activiti de proiectare
Sistem, ntreprindere, software, toate.
Crui proiectant i va impune restricii arhitectura software realizat
Arhiteci, proiectani de detaliu pentru software, programatori.
Elemente externe arhitecturii proiectate:
Surse de date, evenimente, interfee externe
Sisteme legacy
Factori de mediu
Cristina Mndru
Slide 20
Stabilire context - exemplu
Crm
Elevator
Eleron
Acceleraie
Afiaj stnga
Simulator
Software
Afiaj dreapta
Afiaj central
Instrumente de msur
Gimbal
Limitele sistemului
Intrare pentru sistem
Ieire sistem
Sistem
Cristina Mndru
Slide 21

Repetare procedur
Cristina Mndru
Slide 22
Selectare element de pornire

Descompunere
Descompunere (1)
Rafinare
Contextul sistemului stabilete scena pentru descompunerile ulterioare

ale sistemului.
Un context lipsit de acuratee, incomplet, sau imprecis stabilit are

consecine negative asupra descompunerii sistemului i asupra
implementrii.
EXEMPLE:
Responsabiliti greit definite ntre organizaii
Intrri/ieiri nedefinite
Dificulti de integrare (agravate n dezvoltarea distribuit)
Ateptri care nu se potrivesc
Cristina Mndru
Slide 23

Descompunere
Descompunere (2)
Rafinare
Istoric, descompunerea a fost dirijat de funcionalitate.
Din discuiile de la acest curs rezult c structura unui sistem are puin
n comun cu funcionalitatea pur i mai mult cu satisfacerea:
Constrngerilor:
Constrngerile devin limite pentru spaiul de proiectare: fie le satisfacem

fie negociem relaxarea lor.
Atributelor de calitate:
Cristina Mndru
Cerinele pentru atributele de calitate sunt deseori mpletite cu

funcionalitatea, dar msura n care sunt satisfcute atributele ne
conduce de obicei ctre structur.
Slide 24
EXEMPLU scenarii pentru atribute de calitate cheie

Fie urmtoarele scenarii pentru atribute de calitate cu prioritate mare:
Sistemul trebuie s poat fi reamplasat ntr-o locaie nou. Sistemul poate fi
dezasamblat i mpachetat pentru transport n 4 ore i reasamblat la noua locaie n
4 ore.
Simulatorul trebuie reconfigurat pentru a simula un aeroplan de performan. Pentru
aceasta sistemul este oprit (shut down), sunt ncrcate noile reguli de zbor pentru
aeroplanul performant, sistemul este repornit i pregtit de utilizare n mai puin de
15 minute.
n condiii de operare normal i pentru orice configuraia de vehicul aerian,

simulatorul software preia eantioane de date de intrare de la toate comenzile de
intrare de la pilot i actualizeaz toate afiajele, cu o frecven de 75Hz.
Cristina Mndru
Slide 25

Descompunere
Selectarea unui element de pornire
Rafinare
Se selecteaz perspectiva iniial aceasta trebuie meninut pe

parcursul operaiei de descompunere;
Comutarea ctre o alt perspectiv se va face n mod contient!
Se selecteaz un stil arhitectural global care satisface cerinele i

constrngerile cheie.
DISCUIE:
Unele probleme pot sugera un stil particular.
Stilurile sunt puncte de plecare i trebuie rafinate.
Dei la nivel global sistemul poate expune un anume stil, sistemele reale sunt
ansambluri de stiluri.
Un singur stil nu poate optimiza toate cerinele i constrngerile trebuie

fcute compromisuri. Aceasta evideniaz importana prioritizrii cerinelor i
constrngerilor.
Cristina Mndru
Slide 26

Descompunere
Rafinare
Selectarea unui element de pornire
Dac nu este evident un stil de pornire, descompunerea ncepe cu

sistemul.
Decompunerea este condus utiliznd toate cerinele i constrngerile.
Se ncepe cu constrngerile, se continu cu atributele de calitate i n final
se consider funcionalitatea.
Sistemul este descompus n elemente care sunt consistente cu
perspectiva.
Constrngeri
Forele de
proiectare
Structuri
Funcionalitate de nivel nalt
Proiectul
arhitecturii
Arhitect
Cristina Mndru
Slide 27

Descompunere
Exemplu (1)
Rafinare
Simulatorul de zbor
O constrngere cheie trebuie utilizate procesoare Intel.

Foreaz aceasta alte constngeri ca:
Utilizarea unui anumit limbaj
Utilizarea unui anumit sistem de operare ?
Ce atribute de calitate ar putea fi determinante pentru descompunere:
Abilitatea de a aduga controale la simulator
Abilitatea de a modifica regulile de zbor,
Portabilitatea fizic
Necesitile de performan,... sau altceva?
Aceti factori trebuie s v motiveze intuiia.
Cristina Mndru
Slide 28

Descompunere
Exemplu (2)
Rafinare
Un simulator este un sistem de control clasic i exist dou stiluri pe

care le putem lua n considerare:
Stilul polling (I/E cu ateptare n bucl)
Stilul bazat pe ntreruperi (interrupt/event)
NTREBRI :
Este unul dintre acestea o poziie de pornire rezonabil?
Care sunt avantajele i dezavantajele fiecrui stil considerat?
Ce ar putea motiva selectarea unuia dintre aceste stiluri sau a unei alte abordri?
Cristina Mndru
Slide 29

Descompunere
Rafinare
Exemplu (3)
Propunere: luarea n considerare atributului de calitate performan.

Astfel sistemul trebuie considerat din perspectiv dinamic i
descompus n procese.
Limita sistemului
Intrare
Ieire
Se tie c buclele de I/E sunt rapide i deterministice. Totui utilizarea unei

singure bucle este limitat necesitatea de a gndi sistemul n termeni de bucle
concurente.
crm
elevator
eleron
acceleraie
Sistem
afiaj stnga
afiaj dreapta
afiaj central
instrumente de msur
gimbal
Simulator
Software
afiaj stnga
afiaj dreapta
afiaj central
Bucl
actualizare afiaje
instrumente de msur
gimbal x
gimbal y
gimbal z
proces
Cristina Mndru
Depozitar
crm
elevator
eleron
acceleraie
Bucl citire
date de intrare
Bucl
actualizare
sistem cardanic
memorie date
scriere
date
citire
date
Slide 30

Descompunere
Exemplu (4)
Rafinare
Descompunerea este i trebuie s fie ghidat n mare msur de

intuiie i experien.
Cunoaterea structurilor este util i deseori tempereaz deciziile
instinctive.
n exemplu:
Stilul predominant este polling (cu ateptare n bucl), dar este utilizat i
un depozitar ansamblu de stiluri.
Concurena este aplicat ca tactic asupra stilului selectat iniial, cu
scopul creterii suplimentare a performanei.
Cristina Mndru
Slide 31

Descompunere
Ghid pentru descompunere (1)
Rafinare
Scopul descompunerii iniiale este de a decide asupra partiionrii

grosiere a sistemului n elemente.
RafinareaDFHVWRUHOHPHQWHVHIDFHSULQGHFRPSXQHULXOWHULRDUH.
Dup descompunerea iniial, descompunerea elementelor are loc n
manier iterativ.
Operaii:
Asignarea corespunztoare la elemente a responsabilitilor

derivate din cerine funcionale, cerine de calitate i constrngeri.
Rafinarea elementelor prin selectarea de stiluri subordonate i/sau

prin decompunere ulterioar.
Aplicarea corespunztoare de tactici de rafinare.
Dezvoltarea i definirea interfeelor elementelor subordonate.
Cristina Mndru
Slide 32

Descompunere
Ghid pentru descompunere (2)
Rafinare
Recomandri pentru operaia de descompunere a sistemului:
Pstrarea consistenei cu perspectiva i cu elementele i relaiile

specifice acesteia.
Este util creare la nceput a unei legende.
Ordinea descompunerii / rafinrii variaz:
Utilizarea eficient a expertizei speciale descompunere n

adncime.
Cunoaterea domeniului GHVFRPSXQHUHRUL]RQWDO.
Tehnologie nou nevoia de prototipuri descompunere n

adncime.
Cristina Mndru
Slide 33

Descompunere
Asignarea responsabilitilor
Rafinare
Responsabilitile sunt derivate din cerinele funcionale, cerinele de

calitate i constrngeri.
Cerinele funcionale descrise textual i cu cazuri de utilizare
Atributele de calitate descrise cu scenarii
Constrngeri business i constrngeri tehnice
Responsabilitile funcionale i constrngerile tehnice sunt asignate la

elemente specifice.
Atributele de calitate i unele constrngeri businessVXQWVDWLVIFXWHGH
nsi partiionarea sistemului.
Cristina Mndru
Slide 34

Descompunere
Asignarea responsabilitilor - exemplu
Rafinare
Structura general: Structura general a fost aleas astfel nct s maximizeze performana
sistemului i conine trei bucle concurente. Alternativa rejectat include rejectat din motivele
Citire date de intrare: Preia eantioane de la controalele pilotului i scrie date ntr-o
tabel cu valori curente (TVC).
Depozitar: Memorie volatil ce gzduiete TVC. Aceast structur conine ultimele valori citite de la
intrarea datelor de la pilot.
Actualizare afiaje: Citete date din TVC i actualizeaz afiajele cu informaii din exteriorul cabinei
de comand conform regulilor de zbor specifice aeronavei pentru care a fost configurat simulatorul.
Actualizare sistem cardanic: Citete date din TVC i scrie date la dispozitivul hardware de control
al sistemului cardanic pentru a mica simulatorul conform regulilor de zbor specifice aeronavei
pentru care a fost configurat simulatorul.
afiaj stnga
afiaj dreapta
afiaj central
Bucl
actualizare afiaje
instrumente de msur
gimbal x
gimbal y
gimbal z
proces
Cristina Mndru
Depozitar
crm
elevator
eleron
acceleraie
Bucl citire
date de intrare
Bucl
actualizare
sistem cardanic
memorie date
scriere
date
citire
date
Slide 35

Descompunere
Rafinarea elementelor -PHWRG
Rafinare
Dup descompunerea iniial i alocarea responsabilitilor.

Recursiv - descompunerea i rafinarea fiecrui element al sistemului:
Asignarea de responsabiliti la elemente, extrase din cerine i

constrngeri.
Complementarea cu tactici a stilurilor arhitecturale sau a

descompunerii iniiale.
Rafinarea elementelor subordonate.
Definirea interfeelor elementelor subordonate.
Cristina Mndru
Slide 36

Descompunere
Rafinarea elementelor - impact
Rafinare
Descompunerile elementelor ar putea necesita rafinarea cazurilor de

utilizare, a scenariilor pentru atribute de calitate i a constngerilor.
De exemplu, un caz de utilizare care iniializeaz ntregul sistem trebuie divizat

n cazuri de utilizare care iniializeaz subsistemele n condiii variate.
Rafinarea i descompunerea elementelor are impact asupra satisfacerii

responsabilitilor.
Responsabilitile unui element descompus sunt delegate elementelor

subordonate acestuia
Pot fi implicate elemente subordonate la nivel individual o responsabilitate

este satisfcut de un element subordonat ce nu mai este descompus.
Poate fi necesar coordonarea de elemente subordonate VDWLVIDFHUHDXQHL

responsabiliti implic cooperarea mai multor elemente subordonate i devine
o responsabilitate distribuit.
Cristina Mndru
Slide 37

Descompunere
Exemplu (1)
Rafinare
Fie cerina de a oferi suport pentru configurarea de vehicule multiple pe baza

regulilor de zbor primul pas este revizitarea scenariului de configurare.
Simulatorul trebuie reconfigurat pentru a simula un aeroplan performant. Sistemul
este oprit (shut down), sunt ncrcate noile reguli de zbor pentru aeroplanul
performant, sistemul este repornit i pregtit de utilizare n mai puin de 15 minute.
Acest scenariu ofer o informaie crucial asupra momentului cnd trebuie s fie
fcut configurarea i ct de repede trebuie s reporneasc sistemul.
Reconfigurarea este descris n termeni de performan acesta este un lucru obinuit
i ilustreaz natura complex i obscur a cerinelor pentru atribute de calitate.
Configurarea nu a fost nc asignat ca responsabilitate nu s-a ncheiat

Cristina Mndru
Slide 38

Descompunere
Rafinare
Exemplu (2)
afiaj stnga
afiaj dreapta
afiaj central
Bucl
actualizare afiaje
instrumente de msur
gimbal x
gimbal y
gimbal z
proces
Depozitar
crm
elevator
eleron
acceleraie
Bucl citire
date de intrare
Bucl
actualizare
sistem cardanic
memorie date
scriere
date
citire
date
Pe baza descompunerii iniiale, pare rezonabil ca responsabilitatea pentru reconfigurarea

simulatorului s fie legat de controlul afiajelor i al sistemului cardanic, deoarece
actualizarea acestor elemente depinde de regulile de zbor configurate.
Trebuie ns s analizm n detaliu aceste elemente pentru a nelege cum funcioneaz
configurarea, pentru a asigna responsabilitatea i pentru a vedea dac putem satisface
msurile rspunsului exprimate n scenariu.
Cristina Mndru
Slide 39

Descompunere
Rafinare
Exemplu (3)
afiaj stnga
afiaj dreapta
afiaj central
Bucl
actualizare afiaje
instrumente de msur
gimbal x
gimbal y
gimbal z
Bucl
actualizare
sistem cardanic
proces
afiaj stnga
afiaj dreapta
afiaj central
instrumente de msur
Depozitar
fiiere
de configurare
gimbal x
gimbal y
gimbal z
Cristina Mndru
Depozitar
crm
elevator
eleron
acceleraie
Bucl citire
date de intrare
scriere
date
memorie date
citire
date
Bucl
actualizare afiaje
Proces de
iniializare sistem
Depozitar
TVC
Bucl
actualizare
sistem cardanic
Bucl citire
date de intrare
Instaniaz
Slide 40
crm
elevator
eleron
acceleraie

Descompunere
Exemplu (4)
Rafinare
Responsabilitile de pornire i de reconfigurare a sistemului, nealocate

anterior, au fost asignate procesului de iniializareDVLVWHPXOXL.
Responsabilitile trebuie actualizate de cte ori modificm
descompunerea !.
Procesul de iniializare a sistemului: Responsabil de citirea i parsarea fiierelor
de configurare, verificndu-le totodat i corectitudinea.
Dup validarea configurrii, procesul de iniializare a sistemului va configura
corespunztor i va instania procesele de actualizare afiaje, de actualizare sistem
cardanic, i de citire date de intrare.
Cristina Mndru
Slide 41

Descompunere
Schimbarea perspectivei
Rafinare
Perspective diferite permit analizarea a diferite caliti ale sistemului.

n cursul descompunerii i asignrii de responsabiliti poate fi necesar
schimbarea perspectivei i nceperea descompunerii dintr-o
perspectiv nou.
Fie urmtoarea cerin:
Modificarea software-lui pentru simulator, a.. s poat ncorpora clapete ulterior
lansrii facilitilor iniiale de operare. Modificarea trebuie realizat n mai puin de 3
luni-om, inclusiv testare.
Dac utilizm vederi dinamice, este imposibil analiza, proiectarea i

asignarea de responsabiliti referitoare la aceast cerin de
modificare.
Cristina Mndru
Slide 42

Descompunere
Exemplu (1)
afiaj stnga
afiaj dreapta
afiaj central
instrumente de msur
Depozitar
fiiere
de configurare
gimbal x
gimbal y
gimbal z
Rafinare
Bucl
actualizare afiaje
Proces de
iniializare sistem
Depozitar
TVC
Bucl
actualizare
sistem cardanic
Bucl citire
date de intrare
crm
elevator
eleron
acceleraie
Instaniaz
Pentru a permite funcionarea clapetelor ar putea fi implicate procesele de citire a datelor de intrare, de
actualizare a afiajelor i de actualizare a sistemului cardanic, justificnd astfel analiza suplimentar a
acestor elemente probabil este o modificare local dar este greu de precizat din aceast perspectiv.
Pentru a proiecta aceast modificare potenial este necesar s apelm la vederile

modulare ale acestor procese (din perspectiva static).
Cristina Mndru
Slide 43

Descompunere
Rafinare
Exemplu (2)
Depozitar
TVC
Bucl citire
date de intrare
Citire
date
crm
elevator
eleron
acceleraie
Instaniaz
proces
Scriere
date
Memorie date
Bucla principal de citire
Cititor date eleron
Cititor date crm
Cititor date elevator

Driver dispozitiv
invocare
Driver dispozitiv
Modul scriere n TVC
Cititor date acceleraie

Driver dispozitiv
Driver dispozitiv
modul
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 nelege: posibilitileGHDGXJDUHDFODSHWHORU, impactul
adugrii clapetelor asupra performanei, dac e suficient un acelai driver de dispozitiv pentru toate clapetele
sau sunt necesare drivere separate, dac exist abordri mai bune.
Cristina Mndru
Slide 44

Descompunere
Rafinare
Exemplu (3)
afiaj stnga
afiaj dreapta
afiaj central
Bucl
actualizare afiaje
instrumente de msur
Actualizare afiaje (Main)
Calcul poligoane
exterioare cabinei
de comand
Calcul aparate de
msur
Refresh afiaj
instrumente de
msur
Refresh
afiaj stnga
Refresh afiaje
Refresh
afiaj central
Citire TVC
Refresh
afiaj dreapta
Dup descompunerea i analiza din perspectiv static (vedere modular) a procesului de actualizare a
afiajelorUH]XOWFmodificrile pot fi izolate n afiajul instrumentelor de msur deoarece doar n
afiajele corespunztoare sunt vizibile efectele clapetelor efectele sunt configurabile n fiierele de
configurare a vehiculului.
Cristina Mndru
Slide 45

Descompunere
Rafinare
Exemplu (4)
gimbal x
gimbal y
gimbal z
Bucl actualizare
sistem cardanic
Actualizare sistem cardanic (Main)
Actualizare sistem cardanic
Calcul
micare
Scrie Gimbal X
Scrie Gimbal Y
Driver dispozitiv
Driver dispozitiv
Citire TVC
Scrie Gimbal Z
Driver dispozitiv
Dup descompunerea i analiza din perspectiv static (vedere modular) a procesului de actualizare a
sistemului cardanic rezult c modificrile pentru adugarea de clapete nu vor afecta software-ul.
Clapetele vor schimba micarea dispozitivului cardanic, dar efectele sunt configurabile n fiierele de
configurare a vehiculului.
Cristina Mndru
Slide 46
Selectare tactici pentru rafinarea

elementelor (1)
Descompunere
Rafinare
Tacticile rafineaz stilurile i pot ajuta la echilibrarea efectelor negative ale unui
stil.
Factori ce ghideaz selectarea tacticilor:
Cerinele i consrngerile (n particular cerinele pentru atributele de calitate).

Efectele colaterale pe care un stil care implementeaz tactica le are asupra
cerinelor funcionale, cerinelor de calitate i constrngerilor.
Aplicarea tacticilor nseamn rafinarea deciziilor arhitecturale iniiale.

Metafora dialog pentru rafinarea elementelor:
Cerina: crearea unui simulator de zbor general Tactic: bucle concurente
Tactica promoveaz: performana
Stil iniial: polling
Stilul promoveaz: simplitate, uurin n testare Tactica inhib: o anume modificabilitate,
simplitatea.
Stilul inhib: performana
Etc.
Cristina Mndru
Slide 47
Selectare tactici pentru rafinarea

elementelor (2)
Descompunere
Rafinare
Valoarea stilurilor i tacticilor selectate n exemplul anterior depinde de

importana relativ a performanei i modificabilitii.
Aceasta ilustreaz noiunea de compromis arhitectural i importana
prioritizrii cerinelor i constrngerilor.
Arhitecii trebuie s realizeze compromisurile necesare meninerii echilibrului

stilurilor i tacticilor a.. proiectul arhitecturii s ndeplineasc proprietile
dorite pentru sistem.
Cristina Mndru
Slide 48

Descompunere
Definirea interfeelor
Rafinare
Interfeele elementelor se bazeaz pe relaiile ntre elemente.

Interfeele constau din:
Serviciile i proprietile pe care le necesit i pe care le ofer un element

de proiectare, identificate n cursul alocrii de responsabiliti.
Fluxurile de date i de control necesitate de fiecare element, conform
definiiei sale.
Nivelul de detaliu poate fi mai grosier dect signatura GHOHJDUHD, ctre

proiectani, a stabilirii detaliilor de comunicare.
Se pot utiliza cazurile de utilizare i scenariile pentru a nelege mai bine
interfeele:
Interaciunile
Dependenele
Informaiile partajate i schimbate de componente
Cristina Mndru
Slide 49

Repetare procedur
Cristina Mndru
Slide 50
Documentarea arhitecturii (1)

1.
Precizarea contextului proiectului.
2.
Documentarea cerinelor i constrngerilor i a prioritilorORUUHODWLYH.
3.
Crearea reprezentrilor arhitecturii iniiale
Considerarea perspectivei i consistena cu perspectiva

Stabilirea contextului sistemului i contextului software-lui
Includerea de explicaiiSHQWUXUHSUH]HQWULOHJUDILFH
4.
Documentarea responsabilitilor elementelor i a relaiilor dintre ele.
5.
Documentarea motivaiilor deciziilor de proiectare
6.
7.
Responsabilitile elementelor
Alegerile fcute i variantele respinse
Ipotezele considerate
Prezentarea rezultatelor analizei / prototipurilor care au venit n sprijinul

deciziilor de proiectare luate.
Documentarea responsabilitilor i interfeelor pentru fiecare element i
actualizarea acestora la fiecare modificare.
Cristina Mndru
Slide 51
Documentarea arhitecturii (2)
Documentarea arhitecturii pe parcursul proiectrii ei.
Capturarea corect a informaiilor de proiectare (n special motivaiile).
Capturarea permanent a informaiilor pentru a evita uitarea lor i

aglomerarea activitilor de realizare a documentaiei.
Cristina Mndru
Slide 52

Repetare procedur
Cristina Mndru
Slide 53
Metode de evaluare a arhitecturii

Utilizarea scenariilor derivate din cazurile de utilizare funcional, pentru
a testaFDUKLWHFWXUDntrunete cerinele funcionale cheie de nivel
nalt.
Utilizarea scenariilor pentru atributele de calitate i a cazurilor de

utilizare, pentru a testaFDUKLWHFWXUDntrunete cerinele cheie
pentru atributele de calitate.
ATAM (Architecture Tradeoff Analysis Method) este o modalitate de a ne asigura

c arhitectura satisface cerinele funcionale, cerinele de calitate i
constrngerile. (http://www.sei.cmu.edu)
Cristina Mndru
Slide 54
Recomandare
Evaluarea continu pe parcursul elaborrii arhitecturii.

Problemele aprute pot fi diminuate prin
reproiectare,
experimentare,
studiere suplimentar.
Cristina Mndru
Slide 55

Repetare procedur
Cristina Mndru
Slide 56
Repetare procedur (1)

Am definit:
Elemente i relaii
Responsabiliti atribuite
Interfee
Documentaie
Descompunerea, rafinarea, evaluarea i documentarea continu pn cnd:
Elementele i relaiile sunt definite i suficient documentate.
Responsabilitile derivate din cerine funcionale, de calitate i

constrngeri sunt asignate elementelor.
Interfeele elementelor sunt definite.
Documentaia arhitectural este suficient de complet; este prescriptiv

i descriptiv.
Arhitectura a fost evaluat i acceptat.
Cristina Mndru
Slide 57
Repetare procedur (2)

Factori de care depinde reluarea:
domeniul i complexitatea.
asigurarea unei documentaii suficiente.

Cel mai important factor este intuiia arhitectului.
De fapt nu se termin niciodat.
Proiectarea arhitecturii trebuie s fie o activitate continu pe durata de via a

produsului.
Dup punerea n funciune arhitectura joac un rol semnificativ n gestionarea
modificrilor i n estimarea costului i impactului acestora. Arhitectura mparte
modificrile n:
Locale n interiorul unui singur element
Non-locale VHSURSDJGLQFRORGHOLPLWHOHXQXLVLQJXUHOHPHQW
Arhitecturale HURGHD]VWUXFWXUDIXQGDPHQWDODVLVWHPXOXL
Aceast analiz este imposibil n lipsa unei arhitecturi explicite i bine documentate.
Cristina Mndru
Slide 58
Revizitarea contextului business (1)

Dac apar situaii speciale este important s revizitm stakeholder-ii i
cerinele business generale.
Fie urmtoarea cerin:
Pentru a permite antrenarea n grup, simulatoarele trebuie interconectate ntr-o reea pentru
a crea un singur mediu de simulare n care utilizatorii pot interaciona.
Aceast cerin intr n conflict cu o serie de cerine i constrngeri iniiale.
Pe durata de via a unui produs pot s apar oricnd cerine aflate n conflict.
De aceea poate s apar necesitatea de a revizita contextul business oricnd pe
durata de via a produsului.
Cristina Mndru
Slide 59

Contextul original VLPXODWRUXQLF, de sine stttor.
Noua cerin modific domeniul sistemului n mod semnificativ.
simulator
Arhitectul trebuie s fie preocupat de:

Modul n care entitile de la alte simulatoare apar pe afiaj.
simulator
Ce informaie trebuie trimis la alte simulatoare i cum este trimis

aceasta.
simulator
Alte probleme ce necesit atenie:

Cum vor fi conectate simulatoarele individuale pentru a forma unVLVWHP.
Exist un standard?
simulator
Simulatoarele se comport bine individual, dar cum se vor comporta ca

federaie?
Cum va fi reprezentat spaiul simulatorului ntr-un mediu de simulare
distribuit?
Cristina Mndru
Slide 60

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 adevrat?
Este suficient pia pentru aceast caracteristic?
Suntem dispui s pltim pentru complexitatea adugat?
Se poate aduga aceast caracteristic mai trziu?
Ct de trziu?
Dac o adugm mai trziu suntem dispui s pltim acum mai mult pentru un
proiect care va permite adugarea mai uoar sau vom relua atunci proiectarea
de la zero?
Acestea sunt ntrebri la care trebuie s rspundem nainte de a ne ocupa de detalii tehnice.
Cristina Mndru
Slide 61

Arhitecii 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.
Modificrile aprute n urmtoarele zone indic necesitatea revizitrii

contextului business:
Modelele business
Structurile organizaionale
Stakeholder-i cheie
Pieele
Tehnologiile
Cristina Mndru
Slide 62
Bibliografie suplimentar
The Architecture Based Design Method
http://www.sei.cmu.edu/reports/00tr001.pdf
Attribute-Driven Design (ADD), Version 2.0

A Practical Example of Applying Attribute-Driven Design (ADD), Version 2.0

Architecture-Centric Engineering (ACE) Initiative

http://www.sei.cmu.edu/library/assets/brochures/RTSS_ACE_2010.pdf
(disponibile i n seciunea Documentaii de pe site-ul cursului)
Cristina Mndru
Slide 63
Arhitecturi pentru sisteme

software
Curs 9
Cristina Mndru
Slide 1
PLAN CURS
SOA $UKLWHFWXURULHQWDWSHVHUYLFLL
Caracteristicile serviciilor
Perspectiva C&C
Atribute de calitate promovate si inhibate
Cloud computing
Caracteristici, avantaje, aplicabilitate
Modele pentru CC
CC & SOA
Cristina Mndru
Slide 2
SOA generic
Cristina Mndru
Slide 3
Mecanism SOA
Cristina Mndru
Slide 4
SOA Arhitectur orientat pe servicii

SOA abordare arhitectural pentru construirea de sisteme sau de
aplicaii care utilizeaz un set de servicii.
Serviciu o implementare a unei funcionaliti bine definit, cu o interfa

publicat care se poate descoperi i care poate fi utilizat de consumatorii
serviciului la construirea de aplicaii sau de procese business.
SOA definete funcionalitatea unei aplicaii ca un set de servicii partajate,

reutilizabile.
SOA stil arhitectural n care sistemele sunt compuse din consumatori de

servicii i furnizori de servicii.
Cristina Mndru
Slide 5

SOA soluie de integrare de aplicaii disparate ntr-un context web aflate
pe platforme multiple de implementare.
SOA definete interfaa serviciului n termeni de protocol i funcionalitate.
Endpoint punct de acces la serviciu.
SOA VHWGHXQLWi de funcionalitate distincte servicii - care sunt

disponibile ntr-o reea pentru a permite combinarea i reutilizarea lor n
producerea de aplicaii.
Comunicarea transfer de date n formate bine definite sau coordonare

activiti ntre dou sau mai multe servicii.
Cristina Mndru
Slide 6

SOA frameworks servicii reutilizabile ce constituie scheletul unei
arhitecturi.
Nivel de abstractizare ridicat
Tipice unui domeniu
Scalabile
Incorporeaz abloane de proiectare i bune practici de inginerie software
Specific responsabilitile componentelor din fiecare strat i colaborrile

dintre acestea.
Avantaje framework:
Proiectarea, dezvoltarea i repartizarea rapid de servicii web, aplicaii i

portlet-uri modulare, flexibile, scalabile, suportive.
mbuntirea consistenei software-lui livrat.
Autocontrol asupra sa i asupra aplicaiei i serviciilor create n cadrul

acestuia.
Cristina Mndru
Slide 7

Alte definiii
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]
Cristina Mndru
Slide 8
PLAN CURS
Perspectiva C&C
Cloud computing
Modele pentru CC
CC & SOA
Cristina Mndru
Slide 9
Reutilizabile
Expun un contract formal - definete termenii schimbului de informaii
(interfaa) i alte informaii de descriere a serviciului
Implementare invizibil i irelevant pentru consumatorii serviciului

Slab cuplate
Compozabile aplicaiile 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 reea suport accese de la distan
Localizare transparent suport pentru migrare; pstrat ntr-un registry
Cristina Mndru
Slide 10
Compozabile:
Creare aplicaie = asamblarea i coordonarea activitilor serviciilor
necesare implementrii procesului business.
Se poate scrie cod suplimentar pentru implementarea funcionalitii specifice aplicaiei.
Surse de servicii:
Existente n companie i reutilizate
Externe
Construite special pentru aplicaia curent
Problematic proiectare:
Identificare funcionalitate pentru serviciu
Stabilire granularitate serviciu
Cristina Mndru
Slide 11
PLAN CURS
Perspectiva C&C
Cloud computing
Modele pentru CC
CC & SOA
Cristina Mndru
Slide 12
Perspectiva arhitectural
Interaciunea consumator furnizor serviciu : manifestat la runtime.
Perspectiva si viewtype
Dinamic, C&C
OBS:
Diagramele C&C sunt complementate cu diagrame de comportament (ex. diagrame
de secvene) care descriu secvenele de interaciuni ce au loc n diferite
tranzacii.
Cristina Mndru
Slide 13
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 utiliznd
Cristina Mndru
SOAP
HTTP
Infrastructur pentru transfer mesaje
Slide 14
Specificul descrierii arhitecturale

n general - descrierea arhitecturii centrat pe structurile sistemului ce
trebuie implementat.
Soluiile SOA QHFHVLWnelegerea i documentarea fluxului procesului
business.
EXEMPLU din: Bianco P., Kotermanski R., Merson P., Evaluating a Service-Oriented Architecture, sept. 2007
OPC Order Processing Center
Cristina Mndru
Slide 15
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 SVWUHD]LQIRUPDii despre servicii,SHFDUHOH

furnizeaz la cerere consumatorilor n vederea descoperirii
serviciilor
Magistrala -PHGLD]LQWHUDFiunea orientat pe evenimente

dintre consumatorii i furnizorii de servicii
Cristina Mndru
Slide 16
PLAN CURS
Perspectiva C&C
Cloud computing
Modele pentru CC
CC & SOA
Cristina Mndru
Slide 17

Interoperabilitatea : abilitatea unei colecii de entiti care comunic de a
partaja informaie specific i de a opera cu aceasta conform unor
semantici operaionale agreate.
SOA asigur interoperabilitatea serviciilor dezvoltate n limbaje

diferite i repartizate pe platforme diferite (tehnologii diferite: .NET,
Java EE, PHP, etc).
Cristina Mndru
Slide 18

Extensibilitatea : uurina de a extinde capabilitile serviciilor fr a
afecta alte servicii sau pri ale sistemului.
Extindere:
-
arhitectur, adugnd noi servicii
servicii, fr modificarea interfeei
servicii, cu modificarea interfeei
Depinde de extensibilitatea mesajelor interfeei.
Limitare vocabular i structur mesaje LPSOLFRFRPXQLFDUHPDLeficient
Compromis : eficien comunicare vs. extensibilitate
Cristina Mndru
Slide 19

Modificabilitatea : abilitatea de a face rapid i eficient modificri la un sistem
Cuplare slab ntre consumatori i furnizori
Servicii auto-coninute, modulare, accesate prin interfee coezive
Dependene puine i controlate ntre elementele arhitecturii
Promovat modificabilitatea implementrilor
Inhibat modificabilitatea interfeei deoarece este dificil de identificat

consumatorii serviciului.
Cristina Mndru
Slide 20
Atribute de calitate parial promovate
Fiabilitatea : abilitatea unui sistem de a se menine n operare.
- fiabilitatea mesajelor sintagme ale furnizrii mesajelor:

1. in-order Mesajele sunt livrate n ordinea n care au fost trimise.
2. at-least-once Fiecare mesaj trimis este livrat cel puin 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
Cristina Mndru
Slide 21

Adaptabilitatea : uurina cu care un sistem poate fi schimbat pentru a
servi noi cerine.
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

Adugare de noi servcicii
Modificare a modurilor de combinare a serviciilor
Problem: Nu exist standarde. Gestionarea adaptabilitii este fcut de consumatorii i
furnizorii de servicii i depinde de fiecare situaie n parte.
Cristina Mndru
Slide 22

Disponibilitatea : gradul n care un serviciu este operaional i accesibil
atunci cnd trebuie utilizat.
monitorizat la furnizor i la consumator

contracte SLA (service level agreement) -VSHFLILFIXUQL]RUXOVHUYLFLXOXL,
disponibilitatea garantat pentru serviciu, penaliti pentru furnizor.
Cristina Mndru
Slide 23

Utilizabilitatea :PVXUDFDOLWii experienei utilizatorului n interaciunea
cu informaii sau servicii.
La furnizor:
Granularitate mai mare a datelor trimise de serviciu : implic transfer redus n reea
(ex. opiuni de selecie, informaii suplimentare pentru clarificare date).
Operaii tipice pentru utilizabilitate: anulare cerere, undo, serviciu pe date agregate,
informaii de feedback (ex. procentUHDOL]DW, timp estimat pn la finalizare)
La consumator:
- posibilitatea de a reface o stare
- resincronizarea cu un serviciu cu care s-a ntrerupt comunicarea
Cristina Mndru
Slide 24

Scalabilitatea : abilitatea de a funciona, fr degradarea altor atribute de
calitate, atunci cnd sistemul iVFKLPEGLPHQVLXQHDVDXYROXPXOFX
scopul de a ndeplini nevoile utilizatorilor.
Depinde de implementarea serviciilor folosite.
Soluii pentru creterea scalabilitii:
Scalabilitate orizontal : distribuirea ncrcrii pe mai multe calculatoare
Scalabilitate vertical : upgrade hardware la site-ul serviciului
Cristina Mndru
Slide 25

Securitatea : confidenialitate, autentificare, integritate, disponibilitate
Servicii furnizate de teri
Autentificarea nu este ntotdeauna suficient
3URWHMDUHDGDWHORUHQHFHVDUODWUDQVPLVLHGDUi pe perioada stocrii
Mecanisme pentru gestionarea drepturilor de acces
Informaiile din registrul de servicii trebuie s fie la zi i adugate de furnizori

valizi
Cristina Mndru
Slide 26

Performana :WLPSGHUVSXQV, numr de cereri procesate n unitatea de
timp, abilitatea de a respecta termene (deadlines).
Comunicare n sisteme distribuite
Reelele tipice nu garanteaz laten deterministic
Apeluri suplimentare pentru descoperire servicii
Overhead-ul introdus de protocoalele de comunicare (stub/skeleton,
motoare SOAP, proxy, etc.)
Soluii pentru mbuntirea performanei:
Transparena localizrii serviciilor replicarea serviciului i aplicarea unei

strategii de echilibrare a ncrcrii creterea numrului de cereri
procesate n unitatea de timp i a disponibilitii sistemului.
Posibilitatea de a funciona n regim asincron.
Cristina Mndru
Slide 27

Testabilitatea : gradul n care este facilitat stabilirea criteriilor de testare
i performana 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 aprute la
execuie:
Aplicaie
Serviciu utilizat de aplicaie
Infrastructura aplicaiei sau cea a serviciului
ncrcarea platformei pe care ruleaz serviciul
Agentul care descoper i localizeaz serviciul
Soluii:
Furnizorul ofer servicii i infrastructuri adiionale ca suport pentru procesele
de testare i de depanare desfurate att la furnizor ct i la client.
Instrumente pentru testare servicii individuale i testare de integrare.
Cristina Mndru
Slide 28
Discuie
Soluiile SOA -XWLOL]HD]OHJDUHGLQDPLFSHQWUXDSHUPLWHFLDOWHUQDWLYH
de execuie i ordonri diferite ale mesajelor.
Atributele de calitate sunt mai dificil de estimat i de analizat.
SOA FRQHFWDUHGHVLVWHPH, entiti business i tehnologii multiple

trebuie analizate complexitatea ansamblului i forele politice pentru a
decide compromisurile arhitecturale necesare (mai mult dect n cazul
proiectrii unei singure aplicaii, unde predomin preocuprile tehnice).
Evaluarea unei arhitecturi SOA trebuie s echilibreze aspectele specifice

SOA cu aspecte relevante pentru restul stilurilor implicate n
arhitectura final a sistemului dezvoltat.
Cristina Mndru
Slide 29
PLAN CURS
Perspectiva C&C
Cloud computing

Modele pentru CC
CC & SOA
Cristina Mndru
Slide 30
Cloud computing
Cloud computing (CC) Opiune (soluie) 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 reea (internet).
Suport flexibil pentru:
creare/utilizare funcionalitate pentru aplicaie (SaaS)
dezvoltare i rulare aplicaie (PaaS)
repartizarea aplicaiei (IaaS)
Alt perspectiv SDUWDMDUHWUDQVSDUHQWi flexibil de resurse distribuite

hw i sw de ctre utilizatori multipli.
Cloud = system of systems
Cristina Mndru
Slide 31
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
achiziioneze hw/sw suplimentare pentru a utiliza serviciul
Furnizorii gestioneaz infrastructura (hw i sw) i pun n comun
resurse de capacitatea celor cerute de consumatori.
Cristina Mndru
Slide 32
Cloud computing
Tehnologii suport:
Virtualizare : procesul de substituire n care resurse fizice sunt substituite
prin resurse logice (virtuale) careYRUDYHDSURSULHWi derivate din cele ale
resurselor originale dar capacitate diferit.
Software as a service furnizarea online de funcionalitate software,
similar cu furnizarea acesteia de pe maina local.
Arhitecturi grid - servicii de tip cluster
Cristina Mndru
Slide 33
Cloud computing
Proiectarea n contextul CC se bazeaz pe principiul unei arhitecturi

scalabile ca poate fi utilizat de inginerii sistemului.
Ofer un mod tipic de a obine i gestiona resurse IT pe scar larg.

Resursele de calcul sunt furnizate ca utiliti.
Resursele sunt configurabile funcie de necesitile consumatorului.
Resursele fizic distribuite devin resurse logice locale.
Cristina Mndru
Slide 34
Cloud computing analiz economic

CC model economic pentru un mod specific de a obine i
gestiona resurse IT.
Consumatorul nu deine bunuri IT proprii.
Procurare/eliberare resurse - la cerere, funcie de necesitile consumatorului.
Modelele de taxare - flexibile i predictibile

Permit planificarea la consumator.
Pay per use

Pay per subscription
Pay per transaction
Consumatori
ntreprinderi mici - majoritatea
ntreprinderi mari -H[SORUHD]SDUDGLJPD
Cristina Mndru
Slide 35
Cloud computing
CC DVFXQGHFRQVXPDWRULORUGHUHVXUVHDFWLYLWile de achiziie,
ntreinere, monitorizare pentru infrastructura necesar.
Activitile de management al resurselor sunt implementate de o

infrastructur dedicat a furnizorului.
Ex. Webmail
Furnizorul - ntreine spaiul server i ofer acces.
Consumatorul LQWURGXFHRDGUHVZHEn browser i trimite informaiile de acces la
un cont.
Cristina Mndru
Slide 36
Cloud computing
Cristina Mndru
Slide 37
PLAN CURS
Perspectiva C&C
Cloud computing
Modele pentru CC
CC & SOA
Cristina Mndru
Slide 38
Caracteristici cheie
Resurse la cerere consumatorul achiziioneaz unilateral capabiliti de calcul
funcie de necesiti, fr interaciune uman cu fiecare furnizor de servicii.
Acces omniprezent la reea FDSDELOLWile sunt disponibile n reea 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 locaiile acestora

resursele de calcul ale furnizorului sunt constituite n rezervoare pentru a servi
consumatorii conform unui model de chiriai multipli (multitenant). Diferite resurse
fizice i virtuale sunt asignate dinamic i reasignate conform cererilor consumatorilor.
Consumatorul nu are control asupra localizrii resursei primite.
Elasticitate rapid capabilitile sunt furnizate/eliberate rapid i elastic.

ConsumatorulSHUFHSHFUHVXUVHOHVXQWLQILQLWHi pot fi cumprate oricnd i n
orice cantitate.
Servicii msurate. Capabilitile sunt taxate pe baz de msurtori, utiliznd un

model de taxare care s permit promovarea optimizrii utilizrii resurselor.
Cristina Mndru
Slide 39
Avantaje
Disponibilitate acces oricnd la resurse prin intermediul unei conexiuni internet standard.
Colaborare modalitate de a lucra simultan pe date i informaii comune.
Elasticitate furnizorul gestioneaz transparent utilizarea resurselor, pe baz de cerine care se
schimb dinamic.
Infrastructur la cost redus modelul de taxare permite consumatorului s plteasc doar

resursele necesare, fr investiie n resurse fizice i fr costuri de mentenan i upgrade.
Mobilitate datele i aplicaiile pot fi accesate de oriunde.

Reducere risc utilizare pentru testare de idei i concepte nainte de a se face investiii majore n
tehnologie.
Scalabilitate acces la resurse scalabile funcie 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 ctre
mai muli consumatori.
Implementare rapid i inovativ HOXGDUHDDFWLYLWilor de achiziionare, instalare, testare

platform; reutilizare servicii inovate continuu de ctre furnizori.
Green UHGXFHFRQVXPXOGHHQHUJLHHOHFWULF.
Cristina Mndru
Slide 40
Dezavantaje
Interoperabilitate nu exist nc un set universal de standarde i/sau interfee, 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.
Constrngeri de platform i limbaj unii furnizori suport doar anumite platforme i limbaje.
Regulamente jurisdicie, protecie date, practici corecte de manipulare a informaiilor, transferul
datelor internaionale preocup n special organizaiile 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 confidenialitatea datelor, informaiile sunt expuse n mediu necontrolat de consumator.
Soluie la o parte din probleme: SLA (service level agreement) = contract ntre furnizor i
consumator n care sunt prevzute nivele de calitate pentru serviciu i penalizri dac acestea nu sunt
ndeplinite.
Cristina Mndru
Slide 41
CC recomandat
Procese, aplicaii i date puternic independente, slab cuplate cu alte
aplicaii sau informaii.
Puncte de integrare bine definite n care aplicaia 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.
Aplicaii noi
Cristina Mndru
Slide 42
CC nerecomandat
Procese, date i aplicaii strns cuplate, puternic interdependente
Puncte de integrare nedefinite, lipsa mecanismelor de sincronizare
ntre componentele din cloud i cele din ntreprindere. (interfee)
Necesitatea unui nivel ridicat de securitate.
Controlul este critic.
Nucleul arhitecturii interne nu este suficient de ordonat.
Aplicaia necesit interfa nativ.
Balan defavorabil a costului.
Aplicaii legacy.
Cristina Mndru
Slide 43
PLAN CURS
Perspectiva C&C
Cloud computing
Modele pentru CC
SOA & CC
Cristina Mndru
Slide 44
Cloud computing - clasificri
Cristina Mndru
Slide 45
SaaS
Capabilitate: Software-as-a-Service (SaaS, AaaS).
Capabiliti specifice nivelului business (ex. E-mail, CRM)

SaaS tehnic de a oferi aplicaii software utilizatorilor finali fr a cere
acestora s ruleze aplicaia pe calculatorul propriu.
Exemple de furnizori:
Google Apps: ofer instrumente de birou bazate web (ex. E-mail, calendar, management
documente)
salesforce.com: aplicaie pentru managementul relaiilor cu clienii (customer relationship
management - CRM)
zoho.com: gam larg de aplicaii bazate web, n cea mai mare parte pentru utilizare la nivel
enterprise
http://sites.force.com/appexchange/home cloud computing marketplace
Cristina Mndru
Slide 46
PaaS
Capabilitate: Platform-as-a-Service (PaaS).
Capabiliti specifice dezvoltrii i execuiei de aplicaii.

Utilizarea resurselor oferite de furnizor pentru a crea i rula aplicaii mai vaste
dect cele pe care consumatorul le poate gestiona pe resursele proprii.
Akamai EdgePlatform: platform pentru calcul distribuit pe care consumatorii i pot pune aplicaii
web proprii.
Force.com: platform de dezvoltare i execuie aplicaii i componente cumprate de la
AppExchange sau aplicaii ale consumatorului.
Google App Engine: stiv complet pentru dezvoltare i execuie de aplicaii
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
Cristina Mndru
Slide 47
IaaS
Capabilitate: Infrastructure-as-a-Service (IaaS).
Infrastructur computaional (ex. CPU, memorie, reea, main virtual)

Permite consumatorilor s-i extind n mod flexibil i eficient infrastructura IT.
Amazon Elastic Compute Cloud (EC2): ofer o main 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 fiiere distribuit pentru uz individual
Rackspace Cloud: ofer acces la resurse scalabile dinamic de calcul i stocare i la aplicaii i
instrumente cloud oferite de furnizori teri
Cristina Mndru
Slide 48
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 organizaia proprietar.
Exemple de companii ce ofer resurse pentru construirea de cloud privat: 3tera;Eucalyptus;
Oracle (Fusion); Ubuntu.
Specializri ale acestor tipuri:
Cloud comunitar resurse partajate de mai multe organizaii; sprijin

nevoile i problemele specifice comunitii
Cloud hibrid combinaie de cloud public, privat, community.
Cristina Mndru
Slide 49
CC - discuie
Utilizarea resurselor din cloud extinderea arhitecturii dincolo de graniele
ntreprinderii pentru a incorpora resursele cloud arhitectura nu se oprete la
firewall.
nelegerea att a resurselor care exist n ntreprindere ct 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 cerinele.
Utilizarea Web-ului a revoluionat modul n care se acceseaz i se vizualizeaz

informaiile.
CC va revoluioneaz modul n care privim resursele IT.
Cristina Mndru
Slide 50
Tehnologii CC - detalii
Cristina Mndru
Slide 51
PLAN CURS
Perspectiva C&C
Cloud computing
Modele pentru CC
CC & SOA
Cristina Mndru
Slide 52
CC & SOA
Concepte diferite
n relaie
SOA ablon arhitectural

- La nivel strategic decizie funcie de cerine i constrngeri
CC instan de arhitectur (opiune arhitectural)
- La nivel tactic mod de a rezolva problema
Combinaie recomandat pentru probleme la nivel de ntreprindere.
Cristina Mndru
Slide 53
CC & SOA
Se pot utiliza independent.
DAR
CC este definit i funcioneaz n termeni de servicii, oferind servicii externe.

CC este o soluie 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, incluzndu-le n arhitectur ca

atare.
Problema arhitectului -V decid ce servicii, informaii i procese sunt
candidate pentru a fi plasate n cloud i s decid ce servicii cloud trebuie
abstractizate n cadrul SOA existent sau emergent.
Cristina Mndru
Slide 54
CC & SOA
SOA poate utiliza resursele CC ca servicii, incluzndu-le n arhitectur ca atare
SOA se poate realiza utiliznd CC.
Cristina Mndru
Slide 55
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
rmn local i ce poate fi pus n cloud.
Arhitectur SOA bun strategie bun CC

reducerea costurilor i creterea agilitii.
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 modificrile serviciilor.
Cristina Mndru
Slide 56
CC & SOA
SOA utiliznd CC este o abordare arhitectural foarte bun:
Abilitatea de a folosi resurse utiliznd configuraia cea mai bun posibil
Transparena localizrii resurselor
Scalabilitatea resurselor
Proiectarea arhitectural pentru SOA & CC este esenial !!!

CC ofer opiuni arhitecturale referitoare la platforme (noi) mai eficiente i mai
ieftine.
n cursul proiectrii arhitecturale se pot reloca i/sau crea componente
arhitecturale pe platforme CC.
Cristina Mndru
Slide 57
CC & SOA - viitor

Mutarea mai multor resurse de tip infrastructur pe platforme CC, incluznd
memorie, baze de date, procesare tranzacii, dezvoltare aplicaii.
Mixarea i potrivirea acestor resurse n contextul arhitecturii unei aplicaii.
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 mprtiaDUKLWHFWXUDODDFHLIXUQL]RULGHFORXGFHRIHUFHD
mai bun funcionalitate, fiabilitate i pre, iar resursele furnizate de cloud vor colabora
fr probleme cu toate resursele locale.
Cristina Mndru
Slide 58

Curs 10
Cristina Mndru
Slide 1
PLAN CURS
Concepte referitoare la documentaie

Tehnici de realizare a documentaiei
Utilizarea UML pentru reprezentarea arhitecturii
Cristina Mndru
Slide 2
Rol
Principii
Documentarea arhitecturii software
Elemente
Architectura software servete ca plan general pentru sistem i

pentru proiectul de dezvoltare a acestuia.
Este artefactul cel mai potrivit pentru realizarea analizelor n fazele

iniiale de dezvoltare de software.
Este purttorul principal al atributelor de calitate.
Este cheia ntreinerii i evoluieiVLVWHPXOXLGXSGDUHa acestuia n

funciune.
Documentarea arhitecturii este un pas esenial n realizarea ei.
Cristina Mndru
Slide 3
Rol
Principii
Rolul documentaiei
Elemente
Documentaia arhitectural are rolul de a comunica informaii i

idei.
Documentaia trebuie realizat a.. cel ce o citete s neleag corect i complet

informaiile i ideile transmise.
Probleme ale practicii curente:
Diagrame box-and-line ambigue
Justificare insuficient a motivaiilor
Lipsa discutrii de variante alternative
Utilizarea inconsistent a notaiilor
Combinaii confuze de perspective i tipuri de vederi
Cristina Mndru
Slide 4
Rol
Principii
Principiile documentaiei complete
Elemente
1.
Scris din punctul de vedere al cititorului.
2.
Evitarea repetrilor nenecesare.
3.
Evitarea abiguitilor.
4.
Utilizarea unei organizri standard.
5.
Explicarea motivaiilor pentru deciziile arhitecturale.
6.
Pstrarea documentaieiODFXUHQWFXPRGLILFULOH.
7.
Revizuirea documentaiei.
Majoritatea acestor principii se aplic pentru documentaie n general, nu doar pentru

documentaia arhitecturilor software.
Cristina Mndru
Slide 5
Rol
Principii
Evitarea ambiguitilor
Dac se utilizeaz diagrame box-and-line, atunci se vor defini precis

semnificaiile casetelor i ale liniilor (ex. prin includerea unei legende).
Precizarea semnificaiei sgeilor:
Elemente
Flux de control? Flux de date? Invocare serviciu?
Indicarea faptului c se folosete o notaie standard (ex. UML).

Tipurile de vederi nu se vor combina dect n mod controlat i cu
precizarea acestui lucru.
Suplimentarea notaiilor grafice cu explicaii.
Cristina Mndru
Slide 6
Rol
Principii
Elemente
Corect:
Liniile i casetele au forme/culori diferite i o cheie de explicare a

semnificaiei 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
Distincie clar ntre perspective (tipuri de vederi)
Separarea problemelor (concerns)
Precizarea corespondenelor, acolo unde e posibil i necesar
Cristina Mndru
Slide 7
Rol
Principii
Elemente
Incorect:
Toate liniile arat la fel
Sgeile nu nseamn nimic
Sgeile nseamn mai multe lucruri
Confuzie ntre implementare i abstractizare arhitectural
Lipsa unei legende sau a unei chei de interpretare
EXEMPLU:
Semnificaii posibile pentru sgei 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
Cristina Mndru
Slide 8
Rol
Exemplu de documentaie bun
Principii
vedere din perspectiva C&C
Elemente
Legend
Faade
Component
Administrator
Console
Web Component
LDAP Directory
RDBMS
Meta
Viewer
Join
Engine
Rule &
Configuration DB
Integrated
Data Rep
Direct Adapter
Indirect Adapter
Controller
Viewer
Transaction Log
Interface
SOAP Connector
& roles
Adapter
Manager
Indirect
Aapter2
Indirect
Aapter1
Direct
Adapter2
Direct
Adapter1
Change Log
LDAP Connector
& roles
DB Connector
& roles
RMI Connector
& roles
Event Bus
Connector
& roles
Adapter
Registry
System Boundary
External
LDAP1
Cristina Mndru
External
LDAP2
External
DB1
External
DB2
Slide 9
Rol
Elementele eseniale ale documentaiei

arhitecturale (1)
Contextul business, motivaia produsului, domeniul
Atributele de calitate, preferabil n termeni de scenarii
Enunul constrngerilor
business, de implementare, de repartizare
Descrierea contextului
Elemente
Enunul cerinelor
Principii
Sistemele cu care trebuie s interacioneze, interfeele externe
Diagramele de reprezentare a arhitecturii
Cu precizarea clar a semnificaiilor liniilor i casetelor
Extinse cu proz explicativ
Coninnd vederile relevante
Cristina Mndru
Slide 10
Rol
Elementele eseniale ale documentaiei

arhitecturale (2)
Principii
Elemente
Motivarea deciziilor arhitecturale
Modul n care se adreseaz cerinele i constrngerile
Alternativele considerate
Caracteristici de aplicare stil / linie de produse
Dimensiunile de variabilitate pronosticate
Aspectele ce trebuie schimbate
Probleme de management
Implicaii asupra structurii organizaionale a echipei de dezvoltare
Utilizarea revizuirilor arhitecturii
Alte probleme de proiectare
OA&M (operaii, administrare i ntreinere)
Cristina Mndru
Slide 11
PLAN CURS

Cristina Mndru
Slide 12
Tehnici de realizare a documentaiei 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 interfeelor
Diagrame de secvene
Diagrame de context
Combinare vederi
Utilizare ierarhii
Documentare interfee
Cristina Mndru
Slide 13
Diagrame de context
Tehnici de realizare
a documentaiei ahitecturale
Combinare vederi
Utilizare ierarhii
Utilitate: nelegerea arhitecturii (sub)sistemului necesit att cunoaterea elementelor

i relaiilor sale componente ct i a elementelor contextului i a relaiilor cu
acestea.
Pe diagrama de context se reprezint:
Contextul cu care interacioneaz sistemul
Interfeele 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 -FLOHGHLQWHUDFiune ale

(sub)sistemului cu elemente externe acestuia
n perspectiva alocrii cu vedere de repartizare -DOWHVLVWHPHFXFDUH

partajeaz aceleai resurse ale contextului.
Cristina Mndru
Slide 14
Diagrame de context
Combinare vederi
Utilizare ierarhii
Diagrama de context exemplu 1
EDOS/EBnet
LO data
Other Users
Interaction
Interaction
GLAS higher
level products
GLAS SCF
GLAS LO
data
MODIS higher
level products
Science Computing
Facilities
Algorithms
Science
Data
Processing
Segment
Exchange Data
Remarcai:
Data Acquisition
Request
ASTER GDS
LOR Data
MODAPS MODIS L1A/L
Indicarea clar a
sistemului i a contextului
Etichetarea conectorilor
externi
Utilizarea unei
chei/legende
Reprezentarea
multiplicitii
LPS
1B, ancillary
data
Higher level
AMSR-E data
products
MOPITT LO
data
AMSR-E SCF
ACRIM L0 data & higher level products
MOPITT SCF
SAGE III
higher level
products
MOPITT LO
higher level
products
SAGE III
LO data
SAGE III MOC
SAGE III SCF
KEY
System
Cristina Mndru
External
Entity
ACRIM SCF
SAGE III
LO data
X interacts with Y
Data flows from

X to Y
Slide 15
Diagrame de context
Combinare vederi
Utilizare ierarhii
Notification Data
Create Project
SMTP
SMTP
Server
Server
Administrator
Administrator
Refer other project data
Member
Member
ofofOther
OtherTeam
Team
TSP
TSPSupport
Support
Tool
Tool
System
System
Manage personal
Process, product data
Personnel Data
HR
HRSystem
System
Manage Project Data
Team
Team
Member
Member
Team
TeamLeader
Leader
LEGEND
External Entity
(System)
Cristina Mndru
External Entity
(People)
System
Database
connection
Interaction
Message
Slide 16
Diagrame de context
Combinare vederi
Utilizare ierarhii

Users
Users
Users
Users
Administrator
Legend
System
Boundary
Administrating
Operation
User
Query
External Directory
External RDBMS
Web Client
LDAP user ( Application,
LDAP Client and so on)
Interaction
Metadirectory
External
LDAP server1
External
LDAP server2
Cristina Mndru
User
Information
User
Information
User
Information
User
Information
External
DB server1
External
DB server2
Slide 17
Diagrame de context
Combinare vederi
Combinarea vederilor multiple
Utilizare ierarhii
Separarea vederilor ne permite s divizm i s dominm

complexitatea arhitecturii.
Ofer o separare clar a problemelor (concerns)
Genereaz ns probleme de relaionare a lor
Documentaia informal are tendina de a estompa problematica
n special problemele ce depesc frontierele tipurilor de vederi
Precizarea modului n care sunt relaionate vederile d informaii

despre profunzimea nelegerii ntregii arhitecturi!
Cristina Mndru
Slide 18
Diagrame de context
Combinare vederi
Utilizare ierarhii
Relaionarea vederilor unui sistem - prin precizarea corespondenelor

dintre:
module
componente i connectori
descompunerea modular
straturi
componente i connectori
decizii de repartizare
straturi
asignare de sarcini de dezvoltare
Cristina Mndru
Slide 19
Diagrame de context
Combinare vederi
Utilizare ierarhii
PROCEDUR:
1. Construire vedere combinat care arat elementele i relaiile a
dou vederi constitutive
A. Utilizare suprapuneri
B. Definire a unui stil hibrid care combin elemente i relaii ale ambelor vederi
2. Creare a unui document de legtur care conine corespondenele

dintre elementele i relaiile dintr-o vedere cu elementele i
relaiile din cealalt vedere.
Ex. Arat cum modulele sunt replicate n componente i conectori.
Cristina Mndru
Slide 20
Diagrame de context
Combinare vederi
Combinarea vederilor multiple exemplu 1

Behavior-Hiding Module
Function Driver Module
Air Data Computer Module
Audible Signal Module
Computer Fail Signal Module
Doppler Radar Module
Flight Information Display Module
Forward Looking Radar Module
Head-Up Display Module
Inertial Measurement Set Module
Panel Module
Projected Map Display Set Module
Shipboard Inertial Nav. Sys. Mod.
Visual Indicator Module
Weapon Release Module
Ground Test Module
Shared Services Module
Mode Determination Module
Panel I/O Support Module
Shared Subroutine Module
Stage Director Module
System Value Module
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 Module
Physical Models Module
Aircraft Motion Module
Earth Characteristics Module
Human Factors Module
Target Behavior Module
Weapon Behavior Module
Software Utility Module
Power-Up Initialization Module
Numerical Algorithms Module
System Generation Module
System Generation Parameter Mod.
Support Software Module
Cristina Mndru
Utilizare ierarhii
Metod simpl de combinare n aceeai vedere a informaiilor

din dou stiluri (stilul de descompunere i stilul stratificat).
KEY
Behavior-hiding
module
Software decisionhiding module
Hardware-hiding
module
Function Driver
Shared Services
Data
Banker
Physical
Models
Filter
Behaviors
Device Interfaces
Application Data Types
Software
Utilities
Extended Computer
Slide 21
Diagrame de context
Combinare vederi
Utilizare ierarhii
&OLHQW7LHU
%URZVHU
1
:$3
%URZVHU1
$SSOLFDWLRQ
1
Suprapunere vedere C&C de

detaliu cu stilul n trei trepte.
/RJLF7LHU
:HE6HUYHU
:$36HUYHU
6HUYOHW&RQWDLQHU
6HUYOHW&RQWDLQHU
-63
*OREDO
5HS0DQ
6HUYOHW
/RFDO
5HS0DQ
/RFDO
5HS0DQ
-63
-DYD%HDQV C
6HUYOHW
-DYD%HDQV
/2*
)LOH
&KHFN
3RLQWHU
&KHFN
3RLQWHU
$SSOLFDWLRQ
%URZVHU
6073
/LQNDJH
7DVN
&KHFNRU
/2*
)LOH
'DWD7LHU
763'DWD
Cristina Mndru
+5'DWD
+56\VWHP
,QWHUIDFH
Slide 22
Diagrame de context
Combinare vederi
Utilizare ierarhii
Suprapunere vedere C&C cu

vedere de alocare.
Cristina Mndru
Slide 23
Diagrame de context
Combinare vederi
Utilizare ierarhii
Combinare printr-o punte a stilului pipe-and-filter cu un stil cu date partajate.
Filters
Bridging
Element
Database
Cristina Mndru
Slide 24
Diagrame de context
Combinare vederi
Utilizare ierarhii
Utilizare ierarhii
Scop: Pstrarea descrierii arhitecturale n limite controlabile
Detaliile elementelor sunt definite n vederi separate.
Stiluri diferite expun relaii arhitecturale diferite:
Relaia parte-ntregHVWHVSHFLILFYHGHULLFHUHSUH]LQW
descompunerea n module.
Relaia substructur apare n vederi de tip C&C reprezentate

pe trepte multiple.
Cristina Mndru
Slide 25
Utilizare ierarhii exemplu

Faade
Component
Administrator
Console
Diagrame de context
Combinare vederi
Utilizare ierarhii
Legend
Web Component
LDAP Directory
RDBMS
Meta
Viewer
Join
Engine
Rule &
Configuration DB
Integrated
Data Rep
Direct Adapter
Indirect Adapter
Controller
Viewer
Transaction Log
Interface
SOAP Connector
& roles
Adapter
Manager
Indirect
Aapter2
Indirect
Aapter1
Direct
Adapter2
Direct
Adapter1
Change Log
LDAP Connector
& roles
DB Connector
& roles
RMI Connector
& roles
Event Bus
Connector
& roles
Adapter
Registry
System Boundary
External
LDAP1
Cristina Mndru
External
LDAP2
External
DB1
External
DB2
Slide 26
Diagrame de context
Combinare vederi
Utilizare ierarhii
Detaliere componentei Join Engine
Legend
Message
Handler
Interface
Rule Set
Manager
Call &
Return
Transaction
Coordinator
Agent
Send port
Receive port
Context
Receiver
Rule
Translator
<Faade
Component>
Router
Join
Engine
Rule and
<Configuration DB>
<Event Bus>
Cristina Mndru
Slide 27

Faade
Component
Administrator
Console
Diagrame de context
Combinare vederi
Utilizare ierarhii
Legend
Web Component
LDAP Directory
RDBMS
Meta
Viewer
Join
Engine
Rule &
Configuration DB
Integrated
Data Rep
Direct Adapter
Indirect Adapter
Controller
Viewer
Transaction Log
Interface
SOAP Connector
& roles
Adapter
Manager
Indirect
Aapter2
Indirect
Aapter1
Direct
Adapter2
Direct
Adapter1
Change Log
LDAP Connector
& roles
DB Connector
& roles
RMI Connector
& roles
Event Bus
Connector
& roles
Adapter
Registry
System Boundary
External
LDAP1
Cristina Mndru
External
LDAP2
External
DB1
External
DB2
Slide 28
Diagrame de context
Combinare vederi

Detaliere componentei Direct Adapter
Utilizare ierarhii
Legend
Message
Handler
Interface
Agent
Sensor
Transaction
Coordinator
Receiver
From the
system
Sender
To the System
Cache
Call &
Return
Cache
Access
Send port
Receive port
Change
Notifier
Load Sensor
Connection
Manager
<Event Bus>
<Transaction
Log>
<Change
Log>
Direct
Adapter2
LDAP
Directory
Schema
Cache
Context
<External DB>
Cristina Mndru
Slide 29
<Adapter
Manager>
Diagrame de context
Combinare vederi

Detaliere componentei Indirect Adapter
Utilizare ierarhii
Legend
Message
Handler
Interface
Agent
Transaction
Coordinator
Receiver
From the
System
Sender
To The
System
Sensor
Call &
Return
Send port
Receive port
Context
LDIF
Converter
<Event Bus>
Load Sensor
Indirect
Aapter2
<Transaction Log>
Connection
Manager
LDIF Rule
Manager
<External DB>
Cristina Mndru
Slide 30
<Adapter
Manager>
Diagrame de context
Documentarea interfeelor i a
comportamentului
Combinare vederi
Utilizare ierarhii
Etap cheie la trecerea de la diagrame informale de nivel nalt la

specificaii arhitecturale mai detaliate.
Natura documentaiei depinde de:
Tipul de vedere i de stil
Nivelul de detaliu dorit
Notaiile utilizate
Cristina Mndru
Slide 31
Diagrame de context
Combinare vederi
Utilizare ierarhii
Interfa = frontier prin care interacioneaz sau comunic dou

elemente.
Specificaie de interfa = un enunDOSURSULHWilor, pe care arhitectul
alege s le fac cunoscute, ale elementuluiFHSUH]LQWLQWHUIDa.
Ceea ce este exprimat este la latitudinea arhitectului.
Poate evolua n timp.
Actor (pentru un anumit element) = element, utilizator sau sistem cu care

interacioneaz elementul considerat.
Resurs (a unei interfee) facilitate adresabil n cadrul unei interfee.
Ex. Funcie, metod, flux de date, variabil global, endpoint mesaj, declanator eveniment.
Cristina Mndru
Slide 32
Diagrame de context
Combinare vederi
Utilizare ierarhii
Principii:
Toate elementele au interfee
Interfaa unui element este separat de implementarea acesteia
Un element poate avea mai multe interfee
Elementele ofer interfee (provided)
Elementele pot solicita interfee (required)
Mai muli actori pot interaciona simultan cu un element prin intermediul

unei interfee a acestuia
Interfeele pot fi extinse prin specializare
2FRPSRQHQWSRDWHRIHULPDLPXOWHLQVWDQe ale aceleiai interfee

Cristina Mndru
Slide 33
Diagrame de context
Exemplu mod de organizare a

documentaiei interfeelor
Combinare vederi
Utilizare ierarhii
Syntax signatura : include orice informaie necesar

pentru a scrie corect un program ce utilizeaz resursa.
Semantics UH]XOWDWXOXWLOL]ULLUHVXUVHLGLQSHUVSHFWLYD
actorului ce o invoc (schimbare stare element,
evenimente/mesaje transmise, etc); efecte colaterale;
restricii de utilizare a resursei.
Error Handling condiii de eroare i excepii ridicate
de resurs, respectiv comune tuturor resurselor
interfeei.
Variability parametrii de configurare i modul n care
acetia afecteaz semanticile interaciunii.
Quality-Attribute Characteristics valorile promise
pentru atribute de calitate. (ex. SLA)
Extras din Documenting Software Architectures: Views and

Beyond, Clements, et al. 2010
Cristina Mndru
Slide 34
Diagrame de context
Combinare vederi
Interfee module vs. Interfee n vederi C&C
Utilizare ierarhii
Interfa modul:
Definete (cel puin) 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:
Definete un punct de interaciune a componentei cu contextul su n timpul execuiei.
Numit port, pentru a face distincia de interfaa unui modul.
Exemplu: Filtru)FXGRXLHiri,
ambele scriind caractere ntr-o conduct.
Cristina Mndru
<<Interface>>
Output
Porturi
Slide 35
Diagrame de context
Combinare vederi
Documentarea comportamentului
Utilizare ierarhii
Limitri ale definiiilor de interfa:
Nu precizeaz ordinea interaciunilor
Nu precizeaz modul de interaciune ntre elemente multiple.
Soluie exprimare comportament

(notaii diferite; nivelul de detaliere este ales de arhitect)
Exemplu: diagram de secvene
Cristina Mndru
Slide 36
Documentaie beyond views

Cristina Mndru
Slide 37
CONCLUZII
Documentaia nu nseamn doar casete i linii
Vederi diferite necesit notaii diferite
Nivelul de detaliu depinde de contextul de utilizare al documentaiei
Realizarea unei documentaii bune nu este o activitate trivial
Efortul merit fcut
Cristina Mndru
Slide 38
PLAN CURS

Cristina Mndru
Slide 39
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 constrngeri, stereotipuri i valori

etichetate).
Se pot crea profile UML grupuri de extensii.
Cristina Mndru
Slide 40
UML
Poate fi utilizat pentru documentarea urmtoarelor tipuri de reprezentri
pentru structurile sistemului software:
Vederi ale modulelor (structuri statice)

Perspectiva static
Vederi ale structurilor dinamice
Vederi de alocare
Perspectiva alocrii
Modelul datelor
Modelul datelor
Perspectiva dinamic
UML nu este ntotdeauna notaia cea mai potrivit.
Documentarea comportamentului complementeaz vederile asupra

structurii.
Cristina Mndru
Slide 41
UML
Atenie:
Documentaia unei vederi
arhitecturale include
diagrama DAR i o serie
de elemente explicative.

Cristina Mndru
Slide 42
Perspectiva static
UML SHUVSHFWLYDVWDWLF
module viewtype
Tip de element :
- modul unitate de cod
ce implementeaz un set de
responsabiliti.
Cristina Mndru
Perspectiva alocrii
Modelul datelor
Tipuri de relaii :
- is part of relaia parte-ntreg
- depends on relaia de dependen
- is a relaie de specializare/generalizare
sau de implementare
REPREZENTRI folosind UML:

Diagrama de clase (clase i interfee)
Diagrama de pachete
is part of
Diagram de pachete
conine (sub) pachete
i clase
Perspectiva dinamic
Obs. UML ofer i alte relaii standard, care pot fi

specializate utiliznd stereotipuri.
depends on
Dependena poate fi de
mai multe tipuri,
specificate prin stereotip
(<<refine>>,
<<instantiate>>,)
is a
Generalizare clas
Realizare interfa
Slide 43
Perspectiva static
module viewtype
Perspectiva dinamic
Perspectiva alocrii
Modelul datelor
reprezentarea DESCOMPUNERII MODULARE
Cristina Mndru
Slide 44
Perspectiva static
module viewtype
Perspectiva dinamic
Perspectiva alocrii
Modelul datelor
reprezentarea descompunerii modulare i a DEPENDENELOR ntre MODULE
Cristina Mndru
Slide 45
Perspectiva static
module viewtype
Perspectiva dinamic
Perspectiva alocrii
Modelul datelor
Exemplu de rafinare pachet (2 nivele de rafinare)
Cristina Mndru
Slide 46
Perspectiva static
UML SHUVSHFWLYDGLQDPLF
C&C viewtype
-FRPSRQHQW = de execuie (proces, fir de execuie,
EJB, servlet, DLL, obiect,...) sau de date.
- conector coad de ateptare, conduct, RMI,...).
Perspectiva dinamic
Perspectiva alocrii
Modelul datelor
Tipuri de relaii :
Diverse mecanisme de interaciune
Apel procedur (local, remote)
Comunicare(sincron, asincron)
REPREZENTARE folosind UML:
Diagrama de componente
Component
Port (poate avea instane multiple)
Interfee (provided i required)
Conectori de asamblare
Conectori de delegare
Cristina Mndru
Slide 47
Perspectiva static
Perspectiva dinamic
Notaii pentru interfee
Cristina Mndru
Perspectiva alocrii
Modelul datelor
Slide 48
Perspectiva static
Perspectiva dinamic
Notaii pentru conectori
Perspectiva alocrii
Modelul datelor
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 adnotri.
Pentru detalii vezi raportul tehnic C&C_cu_UML.pdf
Cristina Mndru
Slide 49
Perspectiva static
UML SHUVSHFWLYDDORFULL
allocation viewtype
- nod = de execuie i de comunicare (main
server, router,...).
- Artefact software = fiier, director.
Perspectiva dinamic
Perspectiva alocrii
Modelul datelor
Tipuri de relaii :
- Canal de comunicare
- coninut n

Diagrama de repartizare
Nod - dispozitiv
Nod mediu de execuie
Artefact software
Cristina Mndru
Slide 50
Perspectiva static
Perspectiva dinamic
UML modelul datelor

Tip de element :
- entitate = element persistent
Perspectiva alocrii
Modelul datelor
Tipuri de relaii :
- Asociere (1:1, 1:n, n:n)
- Generalizare/specializare
- Agregare

Diagrama de clase
Cristina Mndru
Slide 51
UML reprezentare comportament

Arhitectura software se ocup n mod esenial cu structurileVLVWHPHORU
software.
Diagramele structurale ilustreaz toate interaciunile poteniale ntre
elementele software i cu contextul.
Descrierea structurilor sistemului software trebuie complementat prin diagrame
de comportament. Acestea ilustreaz abloane specifice de interaciune
prin care sistemul rspunde la stimuli.
Variante de REPREZENTARE folosind UML:

Diagrama secvene
Diagrama de comunicare
Diagrama de activitate
Diagrama de timp
Diagrama de stri
Cristina Mndru
Slide 52
UML - Combinarea vederilor multiple

Exemplu
Mapare ntre 2 vederi: allocation view i module view.
Cristina Mndru
Slide 53

Curs 11
Cristina Mndru
Slide 1
PLAN CURS
Concepte generale n evaluarea arhitecturilor software
SAAM (Software Architecture Analysis Method)
ATAM (Architecture Tradeoff Analysis Method)
ACDM (Architecture Centric Design Method)
Cristina Mndru
Slide 2
Practica curent
Analiza i evaluarea arhitecturilor software este n curs de maturizare.
Au nceput s apar cteva metode industriale de evaluare puternice
SAAM, ATAM, ALMA, FAAM, ...
SEI (Software Engineering Institute) cercetare de pionierat i vast n

domeniul evalurii arhitecturilor software.
Cristina Mndru
Slide 3
Motivaii 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 consecinele defectrilor asociate cu sistemele mari i
complexe intensiv software justific costurile evalurii arhitecturii
software.
CONCLUZIE:
Evaluarea arhitecturii software este un mod eficient de a descoperi
consecinele deciziilor arhitecturale
Cristina Mndru
nainte de proiectarea de detaliu i de implementare,VDX

dac actualizarea sistemului angajeaz resurse majore.
Slide 4
Metode pentru evaluarea arhitecturilor software

dezvoltate la SEI (Software Engineering Institute)
Altele:
Specifice unui domeniu
De interes industrial restrns
Mai puin codificate
Cristina Mndru
Slide 5
PLAN CURS
Cristina Mndru
Slide 6
SAAM dezvoltat la SEI
Una din primele metode de evaluare a arhitecturilor software
Predecesor al ATAM
Metod de evaluare a arhitecturilor n scopul asigurrii ndeplinirii cerinelor

pentru atribute de calitate la sistemele intensiv software.
Cuprinde 6 pai.
Cristina Mndru
Slide 7
SAAM - procedura
Pas 1 Dezvoltarea de scenarii pentru atribute de calitate via brainstorming.
Pas 2 Descrierea arhitecturii/arhitecturilor candidat.
Scenariu direct poate fi ndeplinit

Pas 3 Clasificarea scenariilor n directe sau indirecte. fr nici o modificare la sistem.
Scenariu indirect poate fi ndeplinit
Pas 4 Evaluarea scenariilor.
prin modificarea sistemului.
Arhitectul:
demonstreaz executarea scenariului direct,
descrie modul n care arhitectura ar trebui
schimbat pentru a ndeplini scenariul indirect.
Pas 5 Evaluarea interaciunilor dintre scenarii.
Pas 6 Evaluarea de ansamblu.

Ataare ponderi la fiecare scenariu i interaciune ntre
scenarii, funcie de importan.
Dac arhitectura satisface scenariul, primete valoarea
ponderat corespunztor.
Cristina Mndru
Dou scenarii indirecte interacioneaz

dac necesit modificri la acelai
element al sistemului.
Zone cu interaciuni semnificative
ntre scenarii pot revela o potenial
slab separare a problemelor.
Slide 8
SAAM - probleme
Codificare slab
Pot exista diferene de aplicare de la evaluator la evaluator.
Rezultatele sunt deseori impredictibile.
Durata de realizare a evalurilor variaz.
La momentul crerii SAAM, maturitatea disciplinei arhitecturi softwareHUD

relativ sczut puine informaii referitoare la:
Atributele de calitate i relaia acestora cu structura
Scenarii pentru atribute de calitate
Tactici
Documentarea arhitecturilor, ...
Lips modele, instrumente sau instruire pentru evaluatori.

SAAM -FHQWUDWSH
funcionalitate relativ la scenariile directe
diferite feluri de modificabilitate (scalabilitate, portabilitate, ...) relativ la

scenariile indirecte.
Cristina Mndru
Slide 9
PLAN CURS
Cristina Mndru
Slide 10

Obiectiv evaluarea consecinelor deciziilor arhitecturale n raport cu
cerinele pentru atribute de calitate i obiectivele business.
Metod bazat pe scenarii:
Se pleac de la premiza c organizaia nu a identificat sau codificat n

mod explicit cerinele pentru atribute de calitate.
Scenariile sunt dezvoltate de stakeholder-i i utilizate pentru analizarea
arhitecturii n vederea descoperirii de riscuri.
Riscurile descoperite pe parcursul evalurii ATAM pot deveni apoi inta
activitilor de diminuare, cum ar fi analiz i proiectare ulterioare,
prototipare, cercetare,HWF.
Compromisurile aprute, non-riscurile i punctele sensibile pot fi
identificate explicit i documentate.
Cristina Mndru
Slide 11
ATAM
NU
Fixarea, prioritizarea sau determinarea impactului riscurilor (activitate ulterioar
ATAM).
Ofer analize precise i formale.
DA
Descoper tendine generale corelaii ntre deciziile arhitecturale i
proprietile sistemului.
Descoper orice risc, punct sensibil, compromis i non-risc, create de deciziile
arhitecturale.
Cristina Mndru
Slide 12
ATAM - utilizare
Pe parcursul ciclului de dezvoltare de software, dac exist o arhitectur

de evaluat.
Dup ce arhitectura a fost specificat dar exist cod puin sau deloc.
Pentru evaluarea alternativelor arhitecturale.
Pentru evaluarea arhitecturii unui sistem existent.
Arhitectur de evaluat = reprezentri arhitecturale ale unui sistem existent sau a

unuia ce urmeaz a fi dezvoltat.
Cristina Mndru
Slide 13
ATAM - procedura
Faza 0:
Partneriat
i
Pregtire
Durata: variaz
Comunicare: telefon,
email
Cristina Mndru
Faza 1:
Evaluare
iniial
Faza 2:
Evaluare
complet
Durata: 1.5 - 2 zile pentru

fiecare faz.
Comunicare: edin condus n mod
tipic la sediul clientului.
Faza 3:
Urmarire
Durata: variaz
Comunicare: telefon,
email.
Slide 14
ATAM Faza 0
Precede partea tehnic a evalurii.
Clientul i o parte din echipa de evaluare fac schimb de preri referitoare

la metod i la sistemul a crui arhitectur trebuie evaluat.
Conductorul evalurii va lua decizia de a realiza sau nu evaluarea.
Dac decizia este pozitiv, atunci este elaborat un agreement de realizare
a evalurii.
Se creaz nucleul echipei de evaluare.
Echipa de evaluare citete documentaia arhitectural oferit.
Se prezint evaluatorilor determinanii business i arhitectura.
Sunt identificai stakeholder-ii corespunztori, iar acetia sunt decii s

participe la evaluarea ATAM. Echipa de evaluare primete lista
participanilor cu rolurile acestora n raport cu sistemul.
Cristina Mndru
Slide 15
ATAM Faza 0
Decizia de realizare a evalurii

Condiii:
Evaluatorii trebuie s neleag suficient de bine starea arhitecturii pentru a se lua o

decizie i a se putea asigura c sistemul candidat este pregtit pentru evaluare.
Dac se ia o decizie negativ, atunci trebuie explicate clienilor motivele acesteia i

sugerate operaii de remediere, sau trebuie lucrat mpreun cu clienii la
dezvoltarea arhitecturii.
Consideraii 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 documentaie arhitectural suficient pentru a proceda
la evaluarea ATAM.
Exist o reprezentare a contextului i mai multe reprezentri ale sistemului (module,

C&C, alocare)
Exist suficient text descriptiv.
Cristina Mndru
Slide 16
ATAM echipa de evaluare
4 6 persoane
Roluri:
Conductor
Moderator IDFLOLWHD]GLVFXii, brainstorming i analiz
Secretar FRPSOHWHD]IRUPXODUXOHOHFWURQLF$7$0FXDUERUHOHXWLOLWDUDO
atributelor de calitate, scenarii brute, riscuri, sensibiliti i compromisuri.
Observator proces PRQLWRUL]HD]HWDSHOHSURFHVXOXL de evaluare, ia notie

despre acesta i despre modul n care ar putea fi mbuntit.
Organizator timp LQGLFPRGHUDWRUXOXLPRPHQWXOH[SLUULLWLPSXOXLDORFDW

pentru o etap.
Specialist(i) ULGLFSUREOHPHODFDUHQXV-au gndit stakeholder-ii; pune

ntrebri bazate pe modul n care atributele de calitate de interes sunt
corelate cu stilurile arhitecturale.
Cristina Mndru
Slide 17
ATAM Paii procesului

1.
Prezentarea metodei ATAM
2.
Prezentarea determinrilor business
3.
Prezentarea arhitecturii
4.
Identificarea abordrilor arhitecturale
5.
Generarea arborelui utilitar al atributelor de calitate
6.
Analiza abordrilor arhitecturale
7.
Brainstorm i prioritizare scenarii
8.
9.
Prezentarea rezultatelor
10.
Producerea unui raport final pentru client
11.
Evaluarea calitii procesului de evaluare i a materialelor ATAM.
Cristina Mndru
Faza 1
Faza 2
Faza 3
Slide 18
ATAM Faza 1
Implic un grup restrns de stakeholder-i, orientai predominant pe partea tehnic.
Faza 1 este:
Centrat pe arhitectur
Concentrat pe obinerea informaiilor arhitecturale detaliate i pe analiza
acestora.
Analiz n manier descendent (top-down).
Cristina Mndru
Slide 19
ATAM Faza 1
Pasul 1: Prezentarea ATAM - echipa de evaluare:
Motivele evalurii arhitecturilor software

Paii, pe scurt
Tehnicile
Ieirile produse de metod
Pasul 2: Prezentarea determinanilor business - un reprezentant al clientului ATAM
Contextul business al sistemului
Cerinele funcionale de nivel nalt
Cerinele de nivel nalt pentru atributele de calitate
Determinrile arhitecturale atributele de calitate care dau forma arhitecturii
Cerinele critice cerinele de calitate care sunt eseniale pentru succesul sistemului
Evaluatorii trebuie s ASCULTE CU ATENIE: 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 situaie securitate.
Cristina Mndru
Slide 20
ATAM Faza 1
Pasul 3: Prezentarea arhitecturii - arhitectul
Constrngerile tehnice (sistem de operare, hardware, middleware)
Alte sisteme cu care sistemul trebuie s interacioneze
Abordrile arhitecturale utilizate pentru a rspunde la cerinele pentru atribute de

calitate.
Pasul 4: Identificarea abordrilor arhitecturale echipa de evaluare
Distilarea atributelor de calitate i asocierea lor cu determinanii business.
Distilarea determinanilor arhitecturii (funcii, caliti, constrngeri).
Identificarea abordrilor 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 urmrite.
Cristina Mndru
Slide 21
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

ctre 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 performana, modificabilitatea, securitatea i disponibilitatea)
Scenariile sunt plasate n nodurile terminale.
Conine 3 pri majore
Cristina Mndru
Slide 22
ATAM Faza 1
Realizat pe baz de SCENARII
Utilitate scenarii:
Reprezentarea intereselor stakeholder-ilor
nelegerea cerinelor pentru atributele de calitate
Acoperire scenarii:
Utilizri anticipate ale sistemului
Modificri anticipate ale sistemului
Presiuni neanticipate asupra sistemului
Acceptare scenarii:
Precizeaz clar stimulul i rspunsurile de interes
Este foarte specific
Cristina Mndru
Slide 23
ATAM Faza 1
SCENARII:
stimuli context - rspunsuri
Exemple:
Scenariu de utilizare:
Utilizatorul remote solicit un raport din baza de date via Web pe timpul perioadei de vrf
i l obine n 5 secunde.
Scenariu de extindere:
Adugarea unui nou server de date pentru a reduce latena din scenariul 1 la 2,5
secunde cu un efort de o persoan timp de o sptmn.
Scenariu exploratoriu:
Jumtate dintre servere se defecteaz n timpul operrii normale fr a afecta
disponibilitatea gobal a sistemului.
Cristina Mndru
Slide 24
ATAM Faza 1
Pasul 6: Analiza abordrilor arhitecturale
Scenariul brut este expandat ntr-un scenariu format din 6 pri: surs, stimul, context,
artefact, rspuns, msur pentruUVSXQV.
Arhitectului i se pun ntrebri de forma:

Fiind dat <stimul>, din sursa <surs>, afectnd <artefact>, n condiiile definite
de <context>, artai cum arhitectura rspunde n cadrul <msuriiSHQWUX
rspuns>LQGLFDWn scenariu.
Cristina Mndru
Slide 25
ATAM Faza 1
ablon pentru analiza ATAM
Cristina Mndru
Slide 26
ATAM Faza 1
Arhitectul utilizeaz reprezentrile arhitecturale pentru a parcurge scenariul i a descrie
modul n care arhitectura rspunde la stimul.
Evaluatorii ATAM i stakeholder-ii pot pune ntrebri, utile pentru a descoperi:
Riscurile
Non-riscurile
Punctele sensibile
Compromisurile
Risc GHFL]LHDUKLWHFWXUDOFXSRWHQial problematic.

Non-risc GHFL]LHDUKLWHFWXUDOEXQ.
Punct sensibil proprietate a uneia sau mai multor componente (i/sau relaii ntre
componente),FULWLFSHQWUXREinerea unui anumit atribut de calitate.
Compromis SURSULHWDWHFHDIHFWHD]PDLPXOWHDWULEXWHi este punct sensibil pentru
mai multe atribute.
Cristina Mndru
Slide 27
ATAM Faza 1
Pasul 6: Analiza abordrilor arhitecturale - exemple
Regulile de scriere a modulelor logicii business din treapta a 2-a
Risc GHFL]LHDUKLWHFWXUDO a arhitecturii n 3 trepte nu sunt clar articulate. Aceasta ar putea
rezulta n replicare de funcionalitate, compromind astfel
cu potenial problematic.
modificabilitatea treptei a 3-a.
Compromis SURSULHWDWHFH
afecteaz mai multe atribute i
este punct sensibil pentru mai multe atribute.
Punct sensibil proprietate
a uneia sau mai multor componente
(i/sau relaii ntre componenente),
critic pentru obinerea unui anumit
atribut de calitate.
Schimbarea nivelului de criptare poate avea un

impact semnificativ att asupra securitii ct i
asupra performanei.
Valoarea medie a efortului de ntreinere al unui sistem,

msurat n numr de zile-om, poate fi sensibil la gradul
de ncapsulare al protocoalelor de comunicare i al
formatelor fiierelor.
Non-risc GHFL]LHDUKLWHFWXUDOEXQ.
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.
Cristina Mndru
Slide 28
ATAM Faza 2
Faza 2
caracteristici:
Implic un grup mai mare de stakeholder-i.

Concentrat pe obinerea punctelor de vedere ale diferiilor stakeholder-i i pe
verificarea rezultatelor fazei 1.
Centrat pe stakeholder.
Analiz ascendent (bottom-up).
Activiti ale echipei de evaluare n perioada dintre faza 1 i faza 2:
Consolidarea notielor, arborelui utilitar, riscurilor, non-riscurilor, punctelor de

sensibilitate i compromisurilor.
Construirea unei reprezentri pentru faza 2 care recapituleaz rezultatele fazei 1.
Stabilire de teme de risc potenial.
nceperea crerii prezentrii finale i scrierii raportului final.
Planificarea logisticii pentru faza 2.
Cristina Mndru
Slide 29
ATAM
Stabilire tem de risc potenial - exemplu
Risc: Nu au fost stabilite

bugete pentru sincronizarea
activitilor lucrative dificil de
prezis timpul de rspuns
Tem de risc: Nu exist o abordare holistic la

managementul resurselor
Risc: Nu exist o abordare

disciplinat a activitilor de
planificare planul este realizat
din mers
Impact asupra: Cost, timp de lansare pe pia,

abilitatea de a concura cu competitorii
Risc: Modificri minore la

sincronizrile unor activiti
lucrativeDXLPSDFW
impredictibil asupra altor
activiti
Cristina Mndru
Risc: Cerinele de memorie pentru

sistem nu pot fi prezise pn ce nu sunt
integrate toate activitile.
Risc: Alocarea resurselor sistemului nu

este parte a arhitecturii, iar resursele
necesare nu pot fi estimate sau bugetate
Slide 30
ATAM Faza 2
Paii
1.
Prezentarea ATAM
2.
Prezentarea determinrilor business
3.
Prezentarea arhitecturii
4.
Identificarea abordrilor arhitecturale
5.
Generarea arborelui utilitar al atributelor de calitate
6.
7.
Brainstorm i prioritizare scenarii
8.
9.
Prezentarea rezultatelor
Cristina Mndru
Slide 31
ATAM Faza 2
Pasul 7: Brainstorm i prioritizare scenarii
Grupul de stakeholder-i este mai mare i mai divers dect 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 numr de voturi egal cu 30% din

numrul scenariilor generate.
Prioritatea scenariilor se stabilete prin vot.
Cristina Mndru
Slide 32
ATAM Faza 2
Se continu analiza de la pasul 6, cu grupul extins de stakeholder-i i

utiliznd noile scenarii:
Se identific noi riscuri i non-riscuri.
Se adnoteaz informaii arhitecturale suplimentare pe msur ce sunt

descoperite.
La terminare echipa va solicita o pauz de aprox. 2 ore, timp n care se va

completa prezentarea final.
Cristina Mndru
Slide 33
ATAM Faza 2
Pasul 9: Prezentarea rezultatelor
Conductorul echipei de evaluare face, n mod tipic,SUH]HQWDUHDILQDO.
Prezentarea se va concentra pe informaiile de nivel nalt :
Procesul ATAM, durata, participanii,
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.
Cristina Mndru
Slide 34
ATAM Fluxul conceptual
Determinrile
business
Atribute
de calitate
Scenarii
Analiza
Arhitectura
software
Abordri
arhitecturale
Decizii
arhitecturale
Compromisuri
impact
Puncte sensibile
distilate
n
Teme de risc
Cristina Mndru
Non-riscuri
Riscuri
Slide 35
ATAM - probleme
Procedur disruptiv QHFHVLWntrerupere, pregtire, 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
organizaii mici.
Calitatea analizei ATAM (paii 6 i 8) depinde de antrenamentul, intuiia
i experiena evaluatorilor.
Nu exist instrumente suport.
Nu se precizeaz ce se poate face cu cu rezultatul evalurii i nu exist
un proces formal pentru utilizarea acestuia.
Adaptarea, utilizarea i practicarea curent a ATAM n cadrul unei firme
necesit o infrastructur semnificativ.
Cristina Mndru
Slide 36
PLAN CURS
Cristina Mndru
Slide 37
Evaluare continu
Alternativ la o procedur disruptiv.
Posibila mpletire a arhitecturii n ciclul de producie i de mentenan.
Utilizarea arhitecturii ca o ancor a ntregului proiect, pentru dezvoltarea

de planuri, pentru diminuarea riscurilor, pentru alinierea forei de munc,
etc.
Metoda $&'0(Architecture Centric Design Method)

-
Evaluare continu a arhitecturii.
Rafinare incremental a arhitecturii.
Cristina Mndru
Slide 38
Stabilirea determinailor arhitecturali
etapa 2
Determinarea i stabilirea domeniului proiectului
etapa 3
Creare/rafinare proiect arhitectural
etapa 4
Evaluare proiect arhitectural
etapa 5
DECIZIA
DA
NU
Cristina Mndru
etapa 6
Planificare/conducere experimente
Stage 7
Planificarea produciei
Stage 8
Producia
Perioada de
certitudine
etapa 1
Perioada de incertitudine
Slide 39

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 iniial de echipe a..
fiecare membru i nelege responsabilitile.
Ghidul, tabelele, modelele i listele de verificare oferite de ACDM sunt
deosebit de utile.
Cristina Mndru
Slide 40

Zone ce pot fi mbuntite:
Necesit un antrenament semnificativ pe tematica arhitecturilor software pentru

a nelege eficient, a aprecia i a utiliza tehnicile cuprinse n metod.
mbuntire prin:
Ghidare suplimentar referitoare la modul de proiectare i de evaluare a arhitecturilor

software,
Ghidare suplimentar referitoare la utilizarea arhitecturii pentru activiti de ntreinere i

extindere a sistemului,
Ghidare i instrumente pentru documentarea arhitecturilor,
Tehnici de recuperare a proiectelor arhitecturale pierdute (reconstrucia arhitecturii),
Tehnici pentru msurarea conformanei cu proiectul arhitectural.
Sunt necesare adaptri, pentru mpletirea ACDM cu procesul global de

dezvoltare de software.
Cristina Mndru
Slide 41

Lattanze, A., 2008. Architecting Software Intensive Systems: A Practitioners Guide, Auerbach
Publishing, 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
Metod de
obinere, de la
stakeholder-i,
a determinailor
arhitecturii.
etapa 2
etapa 3
etapa 4
etapa 5
etapa 6
etapa 7
etapa 8
Metode pentru
organizarea i
documentarea
determinailor
arhitecturii.
Ghid de
proiectare i
documentare a
arhitecturii
teoretice.
Metod pentru
revizuirea
proiectului
arhitectural.
Ghid pentru
clasificarea i
analizarea
problemelor i
pentru luarea
deciziei de
realizare sau nu
a sistemului.
Modele pentru
planificarea
experimentelor.
Modele, liste de
verificare i
metod pentru
estimarea i
planificarea
produciei.
Modele i liste
de verificare
pentru
urmrire i
supraveghere
a produciei
utiliznd
arhitectura i
planurile de
producie.
Modele de
planificare
pentru
perioada de
incertitudine.
Cristina Mndru
Modele pentru
proiectare,
nregistrare
element i
responsabiliti
de relaionare;
modele pentru
nregistrare
motivaii.
Liste de
verificare
pentru
recenzori.
Modele pentru
nregistrare
probleme.
Liste de
verificare i
modele pentru
actualizarea
planurilor din
perioada de
incertitudine.
Slide 42

Curs 10
Cristina Mndru
Slide 1
Observaii preliminare
1. Cerinele pentru atributele de calitate sunt elementele fundamentale de
dirijare a proiectrii unei arhitecturi software.
Dovada 1:GDFDUILLPSRUWDQWGRDUIXQFionalitatea, 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: mbuntire
performan, securitate, modificabilitate, ...
2. Pentru multe atribute de calitate exist o istorie ndelungat i o baz

bogat de cunotine cadre (framework) valoroase utilizate la analizarea
arhitecturilor.
Ex. Performan teoria cozilor de ateptare, teoriaSODQLILFULL
Fiabilitate modele Markov
Cristina Mndru
Slide 2
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 securitii
Principii ale ingineriei securitii
Ciclul de dezvoltare a arhitecturii securitii
Cristina Mndru
Slide 3
Problema
Obiectiv: Trecerea sistematic de la un set de cerine la o arhitectur
software care le satisface.
Cunotine necesare:
De domeniu
Proiectare arhitectural
Metodologie de proiectare
...
Obiectiv general: proiectarea metodic de arhitecturi software a.. s

ndeplineasc atribute de calitate n mod predictibil.
Cristina Mndru
Slide 4
Exprimare cerine
Elementele de dirijare a proiectrii arhitecturale:
Constrngeri decizii de proiectare pre-definite.
Caracteristici funcii ce adaug valoare pentru utilizator.
Atribute de calitate.
Cerinele funcionale importan minor
Atributele de calitate i constrngerile importan major
Abordarea metodologic a proiectrii propus:
Determinarea precis a atributelor de calitate n termeni de scenarii

Exploatarea structurii modelelor pentru atributele de calitate, pentru
definirea structurii arhitecturilor bine formate.
Cristina Mndru
Slide 5
Exprimare cerine
Model pentru specificarea atributelor de calitate:
Utilizarea de scenarii generale pentru atributele de calitate,

independente de sistem, ca ghid pentru specificarea cerinelor pentru
atributele de calitate.
Caracterizarea cerinelor pentru atributele de calitate ale unui anume
sistem printr-o colecie de scenarii concrete pentru atributele de calitate.
Acestea sunt instane ale scenariilor generale.
Prile componente ale unui scenariu:
Cristina Mndru
Stimul
Surs stimul
Contextul n care apare stimulul
Artefactul influenat de stimul
Rspunsul sistemului la stimul
Msurile rspunsului
Slide 6
Scenarii generale exemple
Scenariu pentru disponibilitate

Tabela de generare scenarii pentru disponibilitate:
Stimul:
Surs stimul:
Intern sistemului
Eveniment neanticipat
Extern sistemului
Actualizare la o surs de date

Artefact:
Context:
Operare normal
Proces
Mod degradat
Memorie persistent
Msuri rspuns:
Rspuns:
nregistrare
Procentaj de disponibilitate
Notificare parteneri
Interval de timp n care sistemul

poate funciona n mod degradat
Operare n mod normal sau

degradat
Exemplu de Scenariu:
Un mesaj neanticipat este recepionat de un proces al sistemului n timpul funcionrii
normale. Procesul trebuie s-l nregistreze, s informeze partenerii corespunztori i
s continue funcionarea n mod normal,IUntreruperi.
Cristina Mndru
Slide 7
Scenariu pentru performan

Tabela de generare scenarii pentru performan:
Stimul:
Surs stimul:
Eveniment declanat de sistem
Periodic
Eveniment extern
Stocastic
Sporadic
Context:
Artefact:
Condiii normale
Condiii critice (ex. suprancrcare)
Sistem
Msuri rspuns:
Rspuns:
Procesare stimul
Laten
Modificarea nivelului serviciului
Termen limit
Rat de transfer
etc
Exemplu de scenariu:
Un eveniment extern sporadic este recepionat de sistem n condiii de funcionare
normal.6LVWHPXOWUHEXLHVSURFHVH]HVWLPXOXOntr-un termen limit specificat.
Cristina Mndru
Slide 8
Scenariu pentru modificabilitate

Tabela de generare scenarii pentru modificabilitate:
Surs stimul:
Stimul:
Utilizator final
Adugare / tergere / variaie
Administrator
funcionalitate, calitate, capacitate
Dezvoltator
Artefact:
Sistem
Sistem
Interfa utilizator
Context:
La execuie
Context
La compilare
Platform
La construire (build)
Produs COTS
La proiectare
Msuri rspuns:
Dificultate n termeni de timp i / sau cost
Rspuns:
Identificarea locurilor modificrilor
Realizare modificare fr afectarea celorlalte funcii

Testare modificare
Repartizare (deploy) modificare
Cristina Mndru
Slide 9
Scenariu pentru securitate

Tabela de generare scenarii pentru securitate:
Surs stimul:
Individ sau sistem
Stimul:
ncercare de
Identificat corect
Anonim
Identificat incorect
Afiare informaii
Utilizarea unui serviciu al sistemului
Modificare / tergere informaii
Reducerea disponibilitii resurselor sistemului
Artefact:
Sistem
n timp ce utilizatorul folosete sistemul
Date din sistem
Msuri rspuns:
Din afara sistemului
Nivel / timp / resurse de competen necesare
Rspuns:
eludrii cu probabilitate de succes a
Autentificare utilizator
mecanismelor de securitate
Ascunde identificarea utilizatorului
...
Permite / blocheaz accesul la date / servicii (inclusiv
drepturi)
Context:
nregistrare modificri / acces pe baza identitii

Memorare informaii ntr-un format ce nu poate fi citit
Cristina Mndru
Slide 10
Scenariu pentru utilizabilitate

Tabela de generare scenarii pentru utilizabilitate:
Surs stimul:
Utilizator final
Context:
Stimul:
Caracteristicile de instruire ale sistemului
Utilizarea eficient a sistemului
La execuie
Minimizarea impactului erorilor
La configurare
Adaptarea sistemului la nevoile utilizatorului
Rspuns:
Sistem de help
Interfa familiar
Agregare dete / comenzi
Utilizarea confortabil a sistemului

Artefact:
Sistem
Msuri rspuns:
Reutilizare de informaii
Timp de realizare sarcini
Undo
Numrul de erori
Cancel
...
Personalizare
Internaionalizare
...
Cristina Mndru
Slide 11
PLAN CURS
Scenarii generale
Tactici
Cristina Mndru
Slide 12
Tactici arhitecturale
Tactic arhitectural = mijloc de satisfacere a unei msuri 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 modeluluiDWULEXWXOXLGHFDOLWDWHYDULD]ntr-o
anumit direcie.
Cristina Mndru
Slide 13
Tactici arhitecturale exemple
Tactici pentru performan

Performan
Arbitrare
solicitare
Gestionare
solicitare
Creterea eficienei calculelor
Introducerea concurenei
Reducerea overhead-lui de calcul
Determinarea politicii de
planificare
Gestionarea ratei de apariie a

evenimentului
Controlul frecvenei de eantionare
Utilizare protocoale de
sincronizare
Gestionare resurse
multiple
Creterea concurenei
fizice
Echilibrarea alocrii
resurselor
Creterea localitii
datelor
Limitarea timpilor de execuie
Cristina Mndru
Slide 14
Tactici pentru modificabilitate

Modificabilitate
Localizare
modificri
Prevenirea efectului
de propagare
Coeren semantic
Ascundere informaii
Anticiparea schimbrilor
Pstrarea interfeelor
existente
Generalizare modul
Limitarea opiunilor posibile
Servicii comune abstracte
Cristina Mndru
Restricionarea cilor de
comunicare
Utilizarea unui intermediar
Amnarea stabilirii
de legturi
nregistrare la momentul
execuiei
Fiiere de configurare
Polimorfism
Componente nlocuibile
Aderare la protocoale
Slide 15
Tactici pentru disponibilitate

Disponibilitate
Detecie
defecte
Recuperare -
pregtire i
reparare
Ping/Echo
Votare
Heartbeat
(PULS)
Redundan activ
Excepii
Cristina Mndru
Redundan pasiv
Prevenire
Recuperare
reintroducere
Shadow
ndeprtare de
la serviciu
Resincronizare stri
Tranzacii
Rollback
Monitorizare
proces
Rezerve
Slide 16
PLAN CURS
Scenarii generale
Tactici
Cristina Mndru
Slide 17
ADD Attribute Driven Design

ADD metodGHSURLHFWDUHDUKLWHFWXUDOn care procesul este condus de
cerinele pentru atributele de calitate.
Definit ca proces recursiv de descompunere a unui (sub)sistem aplicnd

tactici arhitecturale i abloane care satisfac cerinele 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
Cristina Mndru
Slide 18
ADD Attribute Driven Design

Pas 1: Stabilirea suficienei specificaiilor pentru cerine
cerinele funcionale
constrngerile de proiectare
scenariile pentru atributele de calitate
bine definite i prioritizate
Pas 2: Alegerea elementului ce va fi descompus

- iniial ntregul sistem; ulterior subsistemele identificate n trecerile anterioare
Pas 3: Identificarea cerinelor candidat care dirijeaz arhitectura
Pas 4: Alegerea unui concept de proiectare ce satisface cerinele care dirijeaz
arhitectura: se iau decizii arhitecturale.
/LVWDUHDPDMRULWii alternativelor de proiectare
Selectarea abloanelor preferate
Evaluarea pentru validarea proiectului arhitectural
5HDOL]DUHDGHPRGLILFULSHQWUXFRUHFWDUHDGHILFLHQelor detectate.
Pas 5: Instanierea elementelor arhitecturii i alocarea de responsabiliti
Pas 6: Definirea interfeelor pentru elementele instaniate
Pas 7: Verificarea i rafinarea cerinelor i transformarea lor n constrngeri pentru
elementele instaniate.
Cristina Mndru
Slide 19
PLAN CURS
Scenarii generale
Tactici
Cristina Mndru
Slide 20
ADD Exemplu
Aplicarea ADDSHQWUXSURLHFWDUHDXQXLVXEVLVWHPFHRIHUVHUYLFLLGHtoleran
la defecte, identificat ntr-o prim etap de aplicare a metodei pentru
proiectarea unui sistem de urmrire.
Interogare stare / rspuns
Actualizare stare
Sistem urmrire
Sistem
Actor interogare
Actor actualizare
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
Cristina Mndru
Slide 21
ADD cerine funcionale

R1. Actor actualizare WULPLWHODLQWHUYDOGH1 sec. actualizri la serviciul urmrire;
Serviciul poate tolera pierderi ocazionale de date, n special n condiii tranzitorii
cauzate de defectarea echipamentului: serviciul se poate redresaGXSUDWDUHDD
2 actualizri atunci cnd o primete pe a 3-a; dac se pierd mai mult de 3
actualizri consecutive, operatorul trebuie s asiste serviciul n procesul de
redresare pentru a evita intervenia operatorului, procesarea trebuie s
renceap n mai puin de 2 sec. dup o cdere.
R2. Actor interogare trimite sporadic cereri de interogare date i trebuie s primeasc
exact un rspuns la fiecare interogare.
Categorii actoriLQWHURJDUH:
-FHUHULIUHFYHQWHSHQWUXFDQWLWi mici de date;
-FHUHULRFD]LRQDOHSHQWUXFDQWLWi mari de date.
Timpul de rspuns pentru interogri trebuie s fie mai mic dectGXEOXOWLPSXOXLQRUPDO
de rspuns pentru o interogare particular.
Cristina Mndru
Slide 22
ADD constrngeri de proiectare

C1. capacitate:
coeficient utilizare procesor i memorie 50%; coeficient utilizare

reea 50%
100 clieni de actualizare; 25 clieni de interogare
seHVWLPHD]100 actualizri i 5LQWHURJULSHsecund

C2. dispozitivPHPRULHSHUVLVWHQW:
informaii de stare salvate cel puin odat pe minut de ctre serviciul

urmrire; folosite ca date de restart dac toate replicile serviciului
urmrire cad.
C3. replici:
serviciul urmrire i memoria persistent vor avea cte 2 replici

pentru asigurare disponibilitate, fiabilitate i mentenabilitate.
Cristina Mndru
Slide 23
ADD scenarii cerine pentru atribute de calitate agreate de prile

interesate
Scenariul S15HYHQLUHUDSLG:
Scenariul S25HYHQLUHOHQW:
Stimul
Cade o component hw/sw a serviciului

urmrire
Cade o component hw/ sw a serviciului urmrire
Surs stimul
Componenta ce se defecteaz
Componenta ce se defecteaz
Context
Exist dou replici n sistem.
Artefact
Componenta servete mai muli clieni

concureni i pot exista i alte cereri ntr-o
coad de ateptare
Serviciul urmrire
Doar o replic a serviciului urmrire ofer servicii.

O copie a componentei este disponibil pe
memoria persistent i poate fi transferat la un
procesor de rezerv via LAN.
Rspuns
Msur
rspuns
Onorarea tuturor cererilor efectuate anterior

i pe timpul avariei. Cererile de actualizare
pot fi ignorate max. 2 sec.
Replica secundar devine replic primar;

ncepe procesarea cererilor de actualizare n
mai puin de 2 sec. de la avariere.Toate
cererile de interogare trebuie onorate cu o
ntrziere medie de max. 3 sec.
Cristina Mndru
Serviciul urmrire
Informare clieni - serviciu indisponibil.
Relansare serviciu. Informare clieni DFFHSWDUH
actualizri.
Corelare actualizri cu informaiile anterioare
(automat
/ cueste
asisten
administrator).
Serviciul
disponibil
n max.min.
Informare
clieni DFFHSWDUHLQWHURJUL.
Starea componentei
la revenire difer cu max. 1
min. fa de starea acesteia la momentul
producerii avariei.
Slide 24
ADD Rezultatul primei etape

Reprezentare simplificat
Citire/scriere stare
Comunicare sincron
Server urmrire
Serviciu
toleran
la defecte
Serviciu
pornire
Serviciu
comunicare
sincron
Client
Client
interogare
Client
interogare
interogare
Cristina Mndru
Funcii sistem
Serviciu
naming
Memorie
persistent
Comunicare asincron
Serviciu
comunicare
asincron
Servicii middleware
Serviciu de
descompus
Serviciu
nregistrare
Client
Client
actualizare
Client
actualizare
actualizare
Slide 25
ADD Rezultatul primei etape
Stil ales: client server
Divizare server n dou componente A i B
Strategii de repartizare:
1.
A i B pe acelai procesor 50% utilizare procesor, 100 clieni actualizare, 30 clieni interogare
2.
A i B n procesoare diferite 50% utilizare procesoare, 150 clieni actualizare, 50 clieni 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 clieni noi dac nu se poate pstra o rezerv predefinit de
memorie.
Serviciu de naming nregistrare interfee la componentele server-ului.
Client actualizare / interogare apeleaz serviciu de comunicare asincron / sincron care

apeleaz iniial serviciul naming pentru gsire serviciu (A sau B) i pstraz aceast informaie n
cache pentru apeluri ulterioare.
Cristina Mndru
Slide 26
ADD Etapa 2
Obiectiv: Proiectarea serviciului toleran la defecte parial, referitor la
serviciu urmrire.
Directive pentru proiectantul arhitecturii serviciului toleran la defecte:
-
Se vor utiliza cerine, modelul existent al elementului critic, scenariile pentru atributele
de calitate, cu scopul de a aduga toleran la defecte serviciului urmrire.
Dac cerinele care dirijeaz arhitectura dirijeaz la o soluie prea complex, se vor
renegocia n sensul relaxrii lor.
Se vor documenta variantele arhitecturale considerate i raiunile pentru alegerea
fcut.
Proiectarea serviciului pornire este responsabilitatea unei alte echipe, iar soluiile 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 VHYDXUPULGRDUVDWLVIDFHUHDFHULQelor
care dirijeaz arhitectura, nu se va realiza un proiect de detaliu.
Cristina Mndru
Slide 27
ADD
Etapa 2
2. Alegerea elementului ce va fi descompus : Serviciul toleran la defecte.

Obs. Doar problematica referitoare la serviciul urmrire.
3. Identificarea cerinelor candidat care dirijeaz arhitectura:

Obs. Identificate folosind i constngerile de proiectare rezultate din etapa 1.
Cerine ce dirijeaz arhitectura
Importan
Dificultate
Scenariu: Revenire rapid (S1)
mare
mare
Scenariu: Revenire lent (S2)
medie
medie
Cerin: funcionalitatea serviciului urmrire (R1 i R2)
mare
mare
Cerin proiectare: restricii de capacitate (C1)
mare
mare
Cerin proiectare: serviciu memorie persistent (C2)
medie
mic
Cerin proiectare: dou replici (C3)
mare
mare
Rezultat etapa 1: caracteristici de repartizare (P1)
mare
mare
Rezultat etapa 1: mecanisme de comunicare (P2)
mare
mic
Rezultat etapa 1: timpiUHIDFHUHVWDUHGLQPHPRULDSHUVLVWHQW(P3)
mare
mare
Cristina Mndru
Slide 28
ADD Etapa 2
Pas 4: Alegerea unui concept de proiectare ce satisface cerinele care dirijeaz
arhitectura
4.1 Identificarea intereselor asociate cerinelor care dirijeaz arhitectura
Interese (concerns) asociate cu serviciile de toleran la defecte:
Pregtire WDFWLFLGHUXWLQSHSHULRDGDQRUPDOGHIXQFionare pentru a asigura

revenirea sistemului
Detecie tactici asociate cu detectarea avariilor i notificarea unui element de

rezolvare a problemei
Refacere operaii realizate n perioada de tranziie de la cderea sistemului pn la

revenirea acestuia la regimul de funcionare normal.
Cristina Mndru
Slide 29
ADD Etapa 2
Alegere concept de proiectare
4.1 Identificarea intereselor asociate cerinelor care dirijeaz arhitectura - detalii
Toleran la defecte
Pregtire
Recuperare
Detecie
Transparen la clieni
Restart
Monitorizare stare de
funcionare
Pornire replic nou
Deployment
Comportament client actualizare dup avarie

tranzitorie
Integritate
date
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)
Cristina Mndru
Slide 30
ADD Etapa 2
4.2 Creare list de abloane potrivite cu fiecare interes, identificare parametrii discriminatori
si valorile acestora. 4.3 Selectare abloane
Interes = Restart
Nume ablon
Parametrii discriminatori
Tip replic
Estimare durat nefuncionare
Pierdere servicii
Cold restart
pasiv
> 2 min
da
Warm restart
pasiv
> 0.3 sec
posibil
Master / Master
activ
> 50 msec
nu
Load sharing
activ
> 50 msec
nu
Raionament :
Conform R1 i S1 : timp maxim de repornire = 2 sec.

Warm restart: mai simplu de implementat.
Consecine :
Server-ul primar (A i B) recepioneaz toate cererile i rspunde la ele.

Server-ul secundar (standby: A i B) este ncrcat pe alt procesor i preia starea din
memoria persistent atunci cnd e promovat ca primar.
Cristina Mndru
Slide 31
ADD Etapa 2
Interes = Deployment
Nume ablon
P#1
P#2
Grupat
A, B
A, B
Separat
A, B
A, B
A cade
# actualizri
#interogri
Timp revenire
A, B
100
30
1.4
A, B
150
50
0.8
Raionament :
Arhitectul este familiar cu ablonul Grupat, chiarGDFUHYHQLUHDSUHVXSXQHFLWLUHDVWULORU

ambelor componente A i B din memoria persistent.
Totui sunt ndeplinite cerinele.
Consecine :
Componentele server-ului primar (A i B)SDUWDMHD]DFHODi procesor. Similar,

componentele server-ului secundar (A i B) partajeaz un alt procesor.
Sistemul nu va fi operaional cu componentele server-ului primar n procesoare diferite.
Cristina Mndru
Slide 32
ADD Etapa 2
Interes = Integritate date
Nume ablon
ncrcare de comunicare
ncrcare procesor standby
Slow checkpoint (Ckp)
1.2 sec la fiecare minut
nu
Fast checkpoint
1.2 sec la fiecare 2 secunde
nu
Ckp + Log Changes
1.2 sec per minut + 100 mesaje per sec.
nu
Ckp + Bundled Log Changes
1.2 sec per minut + 1 mesaj per x sec.
nu
Ckp + Sync Primary & Backup
1.2 sec per minut + 1 mesaj per x sec.
Copie actualizat a strii
Raionament :
Conform S2 : checkpoint la fiecare minut

Conform S1 : timp maxim actualizare 2 sec.
Se alege x=2 i varianta cea mai simpl.
Consecine :
Replica primar: salveaz starea odat pe minut n fiierul Ckp; adun toate schimbrile de
stare i le salveaz n fiierul Log la fiecare 2 sec.
Server-ul promovat ca primar: calculeaz starea conform informaiilor din Ckp i Log i
lanseaz salvarea ei n memoria persistent; fr a se bloca n ateptarea ncheierii acestei
operaii, continu procesarea actualizrilor i interogrilor.
Cristina Mndru
Slide 33
ADD Etapa 2
Parametru discriminator
Interes = Monitorizare stare funcionare

Nume ablon
ncrcarea liniei de comunicare
Heartbeat (PULS)
4 mesaje (pt. A, A, B, B)
Ping / Echo
8 mesaje (ping i echo pt. A, A, B, B)
Update client detects failure
0 mesaje
Query client detects failure
0 mesaje
Raionament :
Se prefer controlul de ctre dezvoltatorii aplicaiei a cerinelor de temporizare.

Se alege varianta cea mai simpl i care necesit lrgime de band mai mic.
PULS setat la 0.25 sec 4 mesaje per sec.
Consecine :
1.2 sec (iniializarea celor 2 fiiere Ckp) + 0.25 sec (PULS) .55 sec rezerv.
O component de monitorizare a strii de funcionare 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.
Cristina Mndru
Slide 34
ADD Etapa 2
Interes = Transparen la clieni
Nume ablon
Protocol necesar
Loc timeout
Clientul gestioneaz avaria
unicast
client
Proxy gestioneaz avaria
unicast
Proxy
Infrastructura gestioneaz avaria
multicast
infrastructur
Raionament :
Se prefer ca clienii s nu gestioneze avaria ca s nu apar uor interpretri greite.

Infrastructura nu are capabilitate multicast inclus; adugarea ei este costisitoare iar simularea ei
cu unicast multiplu dubleaz utilizarea sistemului de comunicare.
Consecine :
Serviciul Proxy nregistreaz elementele A i B la serviciul de nume i apoi pornete componentele

primare i secundare, nregistrndu-le la serviciul de nume sub nume diferite de cele anterioare.
Clientul invoc serviciul de nume i obine referina la A sau B,FXFDUHLQYRFRRSHUDie la serviciul
de comunicare corespunztor. Acesta folosete Proxy pentru a determina replica primar. Apoi
obine de la serviciul de nume referina corespunztoare, pe care o va folosi n apelurile ulterioare.
Dac replica primar cade, componenta de monitorizare a strii detecteaz lips PULS la aceasta
i informeaz serviciul Proxy.
Proxy informeaz serviciile de comunicare despre avarie. Aceste elemente trimit cererile ctre
serverul primar nou promovat, obinnd referinele corespunztoare de la serviciul de nume.
Cristina Mndru
Slide 35
ADD Etapa 2
Interes = pornire replic nou

Amnare decizie pn la corelarea cu activitatea echipei responsabil cu proiectarea
mecanismului de pornire.
Interes = comportament client actualizare dup avarie tranzitorie

0RQLWRUXOVWULLGHIXQFionare 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 urmtoarea cerere de actualizare.
Cristina Mndru
Slide 36
ADD Etapa 2
Interes = Comportament client actualizare dup avarie hard

Nume ablon
Parametru discriminator
Impact
Continuare trimitere actualizri
Trimitere date inutilizabile
Oprire trimitere actualizri
Linie de comunicare liber pe durata nefuncionrii
Salvare actualizri ntr-un fiier
ncrcare mesaje mari la pornire
Raionament :
Conform S2 se accept comportament degradat i restart.

Nu are rost trimiterea de date inutilizabile
Consecine :
Clienii trebuie s fie capabili s
accepte o intrare care s-i informeze c serviciul urmrire a czut,
opreasc trimiterea de actualizri.
Cristina Mndru
Slide 37
ADD Etapa 2
Interes = comportament client interogare dup avarie tranzitorie

0RQLWRUXOVWULLGHIXQFionare informeaz componenta Proxy despre avarie i
promoveaz replica secundar la rang de replic primar.
Proxy trimite un nou cod de acces secundar la fiecare mecanismGHFRPXQLFDUH
sincron, cod ce va fi folosit pentru urmtoarea cerere de actualizare sau la relansarea
cererii n curs.
n ultimul caz serviciul de comunicare sincron poate primi rspuns dublu i trebuie s
poat renuna la unul dintre acestea.
Interes = comportament client interogare dup avarie hard

Similar cu comportament client actualizare dup avarie hard.
Cristina Mndru
Slide 38
ADD Etapa 2
4.4 Determinarea relaiei ntre abloane i cerinele care dirijeaz arhitectura
Interes
ablon selectat
Baz decizie
Numr replici
Dou replici
C3
Restart
Warm standby
C3, S1
Deployment
Grupat
C1
Integritate date
Checkpoint + Bundled Log Changes
C2, C1, S1, S2
Detecie defecte
PULS
C1, S1, arhitect
Transparen la clieni
C1, arhitect
Client actualizare defect tranzitoriu
n/a
Client actualizare defect hard
Stop trimitere actualizri
C1, S2
Client interogare defect tranzitoriu
n/a
Client interogare defect hard
Stop trimitere interogri
C1, S2
Cristina Mndru
Slide 39
ADD Etapa 2
4.5 Capturarea vederilor arhitecturale preliminare
Elementele sistemului i iteraia ADD n care au fost definite
Elemente definite direct din cerine
Elemente definite n iteraia 1
Elemente definite n iteraia 2
Serviciu urmrire
Serviciu urmrire A
Monitor stare funcionare
Clieni interogare
Serviciu urmrire B
Proxy
Clieni actualizare
Serviciu comunicare sincron
Fiier CkpA
Memorie persistent
Serviciu comunicare asincron
Fiier CkpB
Serviciu nume
Fiier LogA
Serviciu nregistrare
Fiier LogB
Cristina Mndru
Slide 40
ADD Etapa 2
Reprezentare simplificat
Citire/scriere stare
Serviciu toleran la defecte

Monitor stare
funcionare
Server urmrire
primar
Proxy
Comunicare sincron
Serviciu
pornire
Funcii sistem
Serviciu
naming
Server urmrire
secundar
Serviciu
comunicare
sincron
Serviciu
comunicare
asincron
Cristina Mndru
Servicii middleware
Servicii
toleran la
defecte
Serviciu
nregistrare
Notificare avarie
PULS
CkpA, CkpB
Pe durata revenirii
LogA, LogB
Client
Client
interogare
Client
interogare
interogare
Comunicare asincron
Client
Client
actualizare
Client
actualizare
actualizare
Slide 41
ADD Etapa 2
Comportamentul sistemului pentru detecie avarie i recuperare din avarie exemplu.
Cristina Mndru
Slide 42
ADD Etapa 2
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 fiier Log (2s)
Th periodicitate PULS (0.25s)
TrA, TrB WLPSGHUHIDFHUHVWDUH$, BFXGDWHGLQPHPRULDSHUVLVWHQW(0.8s+0.6s)
TrL timp refacere fiier Log cu date din memoria persistent (0.2s)
Tus timp actualizare stare A i B cu date din fiier Log (0.1s)
Cristina Mndru
Slide 43
ADD Etapa 2
4.6 Evaluarea i rezolvarea inconsistenelor
Variante mbuntire 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. ncrcare prea mare a mecanismului de comunicare.
2.
Periodicitate salvare n Log =.5 sec; salvare echivalent cu PULS recunoscut de

memoria persistent extindere funcionalitate memorie persistent cu recunoatere
cdere 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.

Cristina Mndru
Slide 44
ADD Etapa 2
Variante mbuntire sistem (cont.):
5.
Integritate date cu pstrarea la secundar a unei copii actualizate a strii primarulului.
Necesit modificarea modelului proiectat anterior : doar dac va fi necesar.
6.
Reducerea dimensiunii strii ce trebuie salvat prin recalcularea la restart a unor date
de stare.
Necesit modificarea modelului proiectat anterior QHFHVLWDFRUGXOHFKLSHLFHDUHDOL]DW

etapa 1.
Acordul obinut TrA=TrB=0.6s. TrA || TrL=0.65s. T nou = 1.75s.
Cristina Mndru
Slide 45
ADD Etapa 2
Pas 5: Instanierea elementelor arhitecturale i alocarea responsabilitilor.
Element A (B) :
Primete mesaje de la clieni, actualizeaz starea i rspunde la interogri.

A este repartizat pe acelai procesor cu B dup o cdere a B, va funciona pe acelai procesor
cu noul B primar pn la instanierea unui nou B pe cellalt procesor care va prelua rolul de primar
(proces nedefinit nc).
Trimite PULS la monitorul strii de funcionare la fiecare 0.25s
Salveaz starea n fiierul CkpA la fiecare minut.
Cumuleaz schimbrile de stare i scrie n fiierul 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 interesai.
Memoria persistent:
Conine fiierele CkpA, CkpB, LogA i LogB, suprascrise la fiecare actualizare.
Monitorul strii de funcionare

Utilizeaz un timer pentru a verifica pulsurile primite de la A, A,B i B. Dac lipsete un semnal PULS
notific elementul Proxy.
Cristina Mndru
Slide 46
ADD Etapa 2
Serviciu comunicare asincron :
Primete cereri de la clienii actualizare i o direcioneaz ctre elementul corespunztor, folosind

serviciile elementului Proxy. Dac ambele replici sunt inactive cere clienilor s ntrerup trimiterea
mesajelor de actualizare.
Serviciu comunicare asincron :

Primete cereri de la clienii interogare. Funcioneaz similar cu serviciul comunicare asincron, cu
diferena c blocheaz clienii pn la obinerea rspunsului la interogare.
Proxy:
nregistreaz toate metodele elementelor A i B la serviciul de nume. Pornete 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 direcioneaz ctre elementul primar
corespunztor. Dup detectarea unei avarii trimite serviciilor de comunicare referinele la metodele din
secundarul promovat ca primar.
Client actualizare / interogare

Cderea unei componente i revenirea din avarie sunt transparente pentru clieni. Se pot pierde un numr
acceptat de actualizri, respectiv poate s apar o ntrizere acceptat a rspunsului la interogare.
La apariia unei cderi hard (fr backup) clienii vor fi notificai pentru a opri trimiterea de mesaje.
Cristina Mndru
Slide 47
ADD Etapa 2
Pas 6: Definirea interfeelor elementelor instaniate.
Solicitant
Furnizor
Interfa
Timp
A (B) primar
Memoria persistent CkpA(B)
WriteCkp
60s
A (B) primar
Memoria persistent LogA(B)
WriteLog
1s
A (B) primar, secundar
PULS
0.25s
A (B) primar
Memoria persistent CkpA(B)
ReadCkp
La refacere
A (B) primar
Memoria persistent LogA(B)
ReadLog
La refacere
Proxy
AvariePrimar
max. 1s de la detectare
Client interogare
Interogare
aleator
Client actualizare
Serviciu comunicare asincron
Actualizare
1s
Proxy
Naming
Register
La pornire
Proxy
Serviciu comunicare (s/a)
PrimaryFailed
La refacere
Proxy
Serviciu comunicare (s/a)
Stop
Avarie ambele replici
A (B) primar
Interogare
aleator
A (B) primar
Actualizare
1s
Cristina Mndru
Slide 48
ADD Etapa 2
Pas 7 Verificarea ndeplinirii cerinelor de ctre arhitectura componentei
dezvoltat la pasul curent, rafinarea cerinelor i transformarea lor n
constrngeri pentru elementele proiectate.
Cerine ce dirijeaz arhitectura
Realizare & Constrngeri noi
Scenariu: Revenire rapid (S1)
warm restart; deployment distribuit;

integritate date Ckp60s & Log1s;
detecie avarie PULS la 0.25s; citiri
paralele din Ckp & Log pentru refacere.
Scenariu: Revenire lent (S2)
integritate date Ckp60s & Log1s
Cerin: funcionalitatea serviciului urmrire (R1 i R2)
warm restart
Cerin proiectare: restricii de capacitate (C1)
deployment distribuit
Cerin proiectare: serviciu memorie persistent (C2)
integritate date Ckp60s & Log1s
Cerin proiectare: dou replici (C3)
warm restart, deployment distribuit
Rezultat etapa 1: caracteristici de repartizare (P1)
warm restart, deployment distribuit
Rezultat etapa 1: mecanisme de comunicare (P2)
serviciu comunicare (s/a), Proxy
Rezultat etapa 1: timpiUHIDFHUHVWDUHGLQPHPRULDSHUVLVWHQW(P3)
renegociat TrA=TrB=0.6s
Cristina Mndru
Slide 49
PLAN CURS
Scenarii generale
Tactici
Cristina Mndru
Slide 50
Arhitectura securitii = politicile de securitate i elementele de control
pentru diminuarea riscurilor, care sunt integrate n arhitectura sistemului
n scopul reducerii riscului unei ameninri.
Obiective ale arhitecturii securitii:
Confidenialitate SUHYHQLUHDGLYXOJULLGHLQIRUPDii utilizatorilor,

entitilor sau proceselor neautorizate.
Integritate SUHYHQLUHDPRGLILFULLVDXGLVWUXJHULLHOHPHQWHORUGH
valoare de ctre utilizator sau entitate neautorizat.
Disponibilitate protecia fa de atacuri de tip denial-of-service cu
impact asupra accesului utilizatorilor la sistem.
Non-repudiere DVLJXUDUHDFQLFLXQXLSDUWLFLSDQWODRLQWHUDFiune nu i
se refuz rolul n cadrul interaciunii.
Cristina Mndru
Slide 51
Ameninri, atacuri i vulnerabiliti

Ameninare (Threat) = eveniment potenial ce duce la
compromiterea sistemului.
Atac instan sau realizare a unei ameninri.
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
securitii.
Cristina Mndru
Slide 52
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
Cristina Mndru
Slide 53
Cerine pentru arhitectura securitii

Autentificare SURFHVXOGHVWDELOLUHDYDOLGLWii unei identiti pretinse.
Autorizare SURFHVXOGHGHWHUPLQDUHFRHQWLWDWHYDOLGDWDUHDFFHVXO
permis la un element securizat.
Audit abilitatea de a identifica i de a asocia o entitate cu interaciunea sa
cu un element securizat.
! Obiective nerealiste de proiectare !:
Predicia cu acuratee maxim a riscurilor de securitate
Eliminarea tuturor riscurilor de securitate
Securitate complet automat
Eliminarea total a interveniei umane
Integrarea produselor comerciale (COTS) cu pstrarea integral a securitii
Cristina Mndru
Slide 54
Tensorii proiectrii arhitecturale pentru securitate
Obiective ortogonale
Uurin n utilizare
Disponibilitate mare
Adaptabilitate
Evoluie
Performan
Scalabilitate
Interoperabilitate
Robustee
Mentenabilitate
Reconstruirea evenimentelor
Portabilitate
Securitate
Cristina Mndru
Arhitectura
sistemului
Obiective opuse
Slide 55
Controlul securitii
Controale
prevenie
Controale detecie
i recuperare
Autentificare
Authorizare
Proces/utilizator
Impunerea
controlului
accesului
Non-repudiere
Tranzacii
private
Audit
Integritate
IDs
Resurs
Restaurare
Comunicaii protejate
Identificare
Gestionarea cheilor criptografice
Controale suport
Administrarea securitii
Proteciile sistemului
Cristina Mndru
Slide 56
PLAN CURS
Scenarii generale
Tactici
Cristina Mndru
Slide 57
Securitatea este parte integrant a arhitecturii sistemului
Aprare n adncime (protejare, detectare, recuperare)
Stabilirea i separarea zonelor de ncredere
Privilegiul minim
Simplitate
Echilibrarea balanei risc cost
Protejarea informaiilor aflate n tranzit i a celor de pe suporturile de

memorare
Nu exist securitate absolut
Cristina Mndru
Slide 58
Protecie
Detecie
Aprare n adncime
Cristina Mndru
Recuperare
Slide 59
Protecie
Detecie
Exemplu sistem portal web
Recuperare
Cerin : autentificare i autorizare
Authentication/Authorization Server
Workstations
Data
Web Server
Application Servers
Laptops
Cristina Mndru
Slide 60
Protecie
Detecie
Recuperare
Cerin : audit
SSL
Workstations
Data
Web Server
Application Servers
SSL
Laptops
Audit
Data
Security
Audit Server
Audit Workstation
Cristina Mndru
Slide 61
Protecie
Detecie
Recuperare
Cerin : autentificare puternic
SSL
Workstations
Data
Web Server
Application Servers
SSL
Laptops
Audit
Data
Security
Audit Server
SD
Audit Workstation
Cristina Mndru
Slide 62
Protecie
Detecie
Recuperare
Zone de ncredere
Middle Tier
Workstations
SSL
Web Clients
Data
Firewall
SSL
Server
Firewall
Firewall
Application Servers
Audit
Data
Security
Laptops
Audit Server
SD
Audit Workstation
Cristina Mndru
Slide 63
Protecie
Detecie
Aprare n adncime
Detecie
Recuperare
SD
Cristina Mndru
Slide 64
Protecie
Detecie
Aprare n adncime
Recuperare
Recuperare
0LGGOH7LHU
$XWKHQWLFDWLRQ$XWKRUL]DWLRQ6HUYHU
%DFNXS
'DWD
:RUNVWDWLRQV
66/
:HE&OLHQWV
1HWZRUN,'6
)LUHZDOO
)LUHZDOO
:HE6HUYHUZ
66/
,'6
'DWD
)LUHZDOO
$SSOLFDWLRQ6HUYHUV
$XGLW
'DWD
6HFXULW\
/DSWRSV
5HGXQGDQW
6HUYHU
$XGLW6HUYHU
SD
$XGLW:RUNVWDWLRQ
Cristina Mndru
Slide 65
PLAN CURS
Scenarii generale
Tactici
Cristina Mndru
Slide 66
Stabilire politici
Evaluare
Evaluare risc
Gestionare
Cerine
Implementare
Cristina Mndru
Proiectare
Slide 67
Evaluare
Planificare
proiect
Definire
cerine
Cristina Mndru
Proiectare
Proiectare
Dezvoltare
Implementare
Proiectare
Evaluare
Cerine
Implementare
n fazele mentenanei/evoluiei SW
Gestionare
Evaluare risc
Gestionare
Cerine
Evaluare
risc
Stabilire
politici
Stabilire politici
Integrare
& Test
Instalare
& Acceptare
Slide 68

Curs 13
Cristina Mndru
Slide 1
dirijareDSURLHFWULLXQHLDUKLWHFWXULVRIWZDUH.
DAR exist:

arhitecturilor.
Cristina Mndru
Slide 2
PLAN CURS
Utilizabilitatea sistemelor software
abloane arhitecturale pentru utilizabilitate bazate pe separare
abloane arhitecturale suport pentru utilizabilitate (USAP)
Un exemplu de USAP
Cristina Mndru
Slide 3
Utilizabilitate
Def. Utilizabilitate = msura calitii experimentate de utilizator n
interaciunea cu informaii sau servicii.
Chiar dac funcionalitatea este corect,

Chiar dac UI este separat de funcionalitate,
Deciziile arhitecturale realizate iniial pot mpiedica implementarea unui

sistem utilizabil.
E posibil ca o anumit modificare solicitat (de caracteristic sau de

funcionalitate) n sensul creterii utilizabilitii s ajung prea adnc n
arhitectura sistemului pentru a permite realizarea ei viabil din punct de
vedere economic i de timp.
Cristina Mndru
Slide 4
Utilizabilitate exemple de scenarii generale

Feedback warning/status/alert
Se vor afia indicatori de stare sau de alert cnd sunt satisfcute condiiile
corespunztoare.
Profil utilizator
Fiecare utilizator trebuie s poat seta diferii parametrii care controleaz
prezentarea.
Agregare comenzi
Utilizatorul trebuie s poat invoca executarea unei colecii de comenzi.
Recuperarea din avarie
La cderea sistemului, procesorului sau reelei, utilizatorul nu trebuie s piard
starea curent.
Suport pentru internaionalizare
Utilizatorul trebuie s poat folosi un limbaj i un format de afiare care i este
familiar.
Cristina Mndru
Slide 5
Obiective curs
nelegerea principiilor de baz ale arhitecturilor software pentru sisteme

interactive.
nelegerea modului n care aceste principii afecteaz utilizabilitateaVLVWHPXOXL.
Motivul utilizrii de abloane bazate pe separare.
Cazuri n care abloanele bazate pe separare nu sunt suficiente.
Cristina Mndru
Slide 6
Practici obinuite n proiectarea de detaliu a sistemelor

interactive
Toate tehnicile HCI (Human Computer Interaction) suport pentru proiectarea de

detaliu a interfeei utilizator sunt bazate pe proiectare iterativ.
(i.e proiectare, testare (analiz sau msurare), modificare, re-testare)
Odat ce software-ul a fost dezvoltat, iterarea implic modificri ale acestuia.
Inginerii software pregtesc realizarea acestor modificri prin izolarea seciunii ce

va fi modificat (separare).
Cristina Mndru
Slide 7
PLAN CURS
Un exemplu de USAP
Cristina Mndru
Slide 8
abloane arhitecturale pentru utilizabilitate

bazate 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)
Reacie la dezavantajele MVC
Utilizate curent n practic, cu succes dovedit.
Cristina Mndru
Slide 9
MVC
Orientat obiect
Model starea i
funcionalitatea aplicaiei
(operaii).
View UHGPRGHOHi trimite

gesturile utilizatorului la
controller.
Dispozitiv
de intrare
View
Comma
Comma
nd
nd
Process
Process
or
or
Model
Comma
Comma
nd
nd
Process
Process
or
or
Dispozitiv
de ieire
Controller
Controller DFWXDOL]HD]
modelul, selecteaz vedere,
definete comportamentul
aplicaiei (interaciuni, flux).
Cristina Mndru
Slide 10
MVC
Avantaje
Suport pentru vederi multiple asupra acelorai date
Utilizatorul are perspective multiple asupra acelorai date (ex. vederi de tip
outline i de tip layout)
Diferite dispozitive prezint aceleai informaii n moduri corespunztoare

platformelor pe care se afl (ex. PDA, laptop)
Diferii utilizatori au acces simultan la aceleai date
Separare prezentare (view) de aplicaie SHUPLWHUHDOL]DUHDGHPRGLILFULDOH

prezentrii independent de restul aplicaiei.
Cristina Mndru
Slide 11
abloane bazate pe separare

Larg utilizate n practic.
Suport pentru dezvoltarea de instrumente specializate
Biblioteci de widget-uri
Diferite tipuri de controller-e
Separarea prezentrii de aplicaie este foarte important.
DAR abloanele bazate pe separare nu sunt suficiente pentru sistemele

interactive.
Cristina Mndru
Slide 12
abloane bazate pe separare i proiectarea iterativ

Cerine revelate pe parcursul proiectrii iterative:
Modificri ale funcionalitii
Modificri ale UI referitoare la coninutul ecranelor
Modificri ale UI dincolo de coninutul ecranului
Modificri facilitate de
arhitectura software
Cerine descoperite
pe parcursul proiectrii
iterative
Zona de modificri dificil de realizat

Cristina Mndru
Slide 13
MVC i proiectarea iterativ (1)
Modificare asupra caracteristicilor afirii modificare view : view conine toat

logica de afiare.
Ex. Modificare culori, font, aezare n pagin (layout).
Modificare la fluxul prezentrii modificare controller : controller-ul definete fluxul

prezentrii.
Ex. Modificarea ordinii dialogurilor.
Cristina Mndru
Slide 14

Adugarea abilitii de a anula o comand cu durat mare de execuie.
Modificari la toate componentele arhitecturii:
View EXWRQ&DQFHOVDXDOWPRGDOLWDWHGHDFRPDQGDDQXODUHD
Controller ORJLFDGHUVSXQVODFRPDQGi de executare a funciei

corespunztoare
Model modul de alocare a resurselor, ...
Probleme:
Implic toate componentele arhitecturii
Localizare slab
Dac cerina apare trziu,YDQHFHVLWDPRGLILFULFRQVLGHUDELOHDOHDUKLWHFWXULL
Cristina Mndru
Slide 15
Concluzii
Proiectarea de detaliu a interfeei 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.
Cristina Mndru
Slide 16
PLAN CURS
Un exemplu de USAP
Cristina Mndru
Slide 17
abloane arhitecturale suport pentru utilizabilitate

(USAP Usability Supporting Architectural Patterns)
Obiectiv recunoaterea i prevenirea problemelor obinuite de utilizabilitate care
nu sunt suportate de principiul separrii.
Soluie - 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 forelor ce acioneaz, n aceste scenarii, asupra

arhitecturii proiectate.
Oferirea unei liste de verificareDUHVSRQVDELOLWilor software importante.
Oferirea de abloane arhitecturaleFXSRVLELOLWi de satisfacere a acestor scenarii.
Cristina Mndru
Slide 18

(USAP)
Sensibilitate din punct de vedere arhitectural
Un scenariu de utilizabilitate este considerat sensibil din punct de vedere arhitectural dac
satisfacerea acestuia poate necesita modificri la arhitectura sistemului.
ntr-un ablon bazat pe separare, aceasta nseamn c implementarea modificrii va avea

impact att asupra prezentrii ct i asupra abstractizrii (modelului).
abloanele bazate pe separare sunt destinate localizrii modificrilor referitoare la

prezentarea informaiilor.
Rezult - exemplu:
Modificri de culori i font QXVXQWVHQVLELOHGLQSXQFWGHYHGHUHDUKLWHFWXUDO
Adugarea opiunii de anulare (Cancel) HVWHVHQVLELOGLQSXQFWGHYHGHUHDUKLWHFWXUDO.
Cristina Mndru
Slide 19

(USAP)
Scenariu de utilizabilitate sensibil din punct de vedere arhitectural - exemplu.
Anulare comenzi
Utilizatorul trimite o comand, apoi se rzgndete dorind oprirea operaiei i
revenirea sistemului la starea dinaintea lansrii comenzii. Nu conteaz motivul
utilizatorului: poate fi o greeal a sa, poate fi din cauz c sistemul nu
rspunde la comand, sau poate s-a modificat contextul.
Cristina Mndru
Slide 20

(USAP)
Exemple de modificri sensibile din punct de vedere arhitectural.
Agregarea datelor
Agregarea comenzilor
Alerte
Anulare comenzi
Verificarea corectitudinii
Evaluarea sistemului
Validare form/cmp
Jurnalizare istoric
Meninerea independenei dispozitivelor
(diferite metode de acces)
Meninerea compatibilitii cu alte sisteme
Accesibilizarea vederilor
Modificarea interfeelor
Navigarea n cadrul unei singure vederi
Observarea strii sistemului
Operare consistent la traversarea vederilor
Feedback al progresului
Help performant (Context-Sensitive Help)
Cristina Mndru
Recuperarea din defecte

Reutilizare informaii
Extragere parole uitate
Indicare stare
Suport pentru cutri extensive
(diferite limbi)
Suport pentru activiti multiple
Suport pentru Undo
Suport pentru personalizare
(profil utilizator)
Suport pentru vizualizare
Tur
Utilizare concurent
(Multi-tasking)
Verificare resurse
Wizard
ModelDOIOX[XOXLGHDFWLYLWi
Lucru n ritmul utilizatorului
Lucru n context nefamiliar
Slide 21
Procesul de dezvoltare
Echipa de dezvoltare:
Ingineri software
Specialiti n utilizabilitate
Manager proiect
Scenariile de utilizabilitate sensibile din punct de vedere arhitectural sunt

surse de cerine, deci
Trebuie s fie concrete
Trebuie s fie eficace pentru un sistem particular.
Cristina Mndru
Slide 22
n plus fa de scenariile de utilizabilitate sensibile din punct de vedere
arhitectural, sunt necesare:
Determinarea balanei cost-beneficiu n implementarea scenariului

Oferirea unui ghid pentru echipa de dezvoltare referitor la problemele asociate
cu implementarea soluiei.
Ingineri software cost
Specialiti n utilizabilitate - beneficii
Manager proiect - arbitru
Ghid:
Pentru ingineri software
Lista responsabilitilor ce trebuie considerate de ctre orice soluie de implementare a

scenariului
Exemplu de soluie care aloc responsabiliti modulelor bazate pe MVC
Pentru specialitii n utilizabilitate
Tipurile de beneficii ateptate de la scenariul propus
Cristina Mndru
Slide 23
Forele ce acioneaz asupra proiectului arhitectural

Fore diferite motiveaz aspecte
particulare ale soluiei.
Reguli organizaionale la utilizator

Activitate n context
Sistem
Software
Utilizator
Starea software-lui
Fore
Fore
Fore
Dorine i
capabiliti
Beneficii
Cristina Mndru
Fore
Responsabiliti
generale
Beneficii
oferite de
soluie
Decizii de
proiectare
anterioare
Fore
Soluie specific
(mai multe detalii)
Ex. Tactici.
Slide 24
Discuie despre proiectarea arhitecturii

Forele provin din diferite surse:
Activitatea implicat i contextul n care opereaz utilizatorul.
Ex. Cancel este util doar dac operaia este de lung durat.
Dorinele i capabilitile factorului uman.

Ex., Utilizatorii fac greeli. Cancel ofer un mod de a corecta greeli.
Starea sistemului (software-lui).

Ex. Reelele cad. Dnd utilizatorului posibilitatea de anulare a unei operaii,
acesta poate preveni blocarea datorat unei cderi de reea.
Cristina Mndru
Slide 25
Beneficiile utilizabilitii
Elementele ce definesc utilizabilitatea unui sistem software depind de
contextul de utilizare al acestuia.
Aspecte comune:
Eficiena utilizrii
Timpul necesar nvrii modului de utilizare eficient
Suport pentru explorare i pentru rezolvarea problemelor
Satisfacia utilizatorului (ex. ncredere, confort, acceptare de ctre
utilizatorii discreionari)
Beneficiile utilizabilitii pot fi organizate ierarhic.

Cristina Mndru
Slide 26
Beneficiile utilizabilitii o ierarhie

Reduce
impactul
erorilor
sistemului
Crete eficiena
utilizatorului individual
Crete
performana
activitilor
de rutin
Accelereaz
poriunea
liber de
erori a
activitilor
de rutin
Crete
performana
activitilor
non-rutiniere
Reduce
impactul
erorilor
utilizator la
operaiile
de rutin
(scpri din
vedere)
Cristina Mndru
Reduce impactul
erorilor
utilizatorului
datorate lipsei de
cunotine
Sprijin
Faciliteaz
rezolvarea
problemelor nvarea
Previne
greelile
Previne
erorile
sistemului
Crete
ncrederea i
confortul
utilizatorului
Tolereaz
erorile
sistemului
Se adapteaz
greelilor
Slide 27
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 soluiei:
Soluia general UHVSRQVDELOLWile software-lui ce trebuie ndeplinite de

orice soluie.
Soluia specific un ablon arhitectural care arat cum trebuie
implementat soluia general n contextul unui ablon bazat pe separare.
Pentru exemplificare, vom considera MVC ca fiind un ablon bazat pe separare

acoperitor.
Cristina Mndru
Slide 28
Documentarea ablonului
Context
Situaia scenarii de utilizabilitate sensibile din punct de vedere arhitectural.
Condiiile constrngeri asupra momentelor cnd situaia este relevant.
Beneficiile utilizabilitii enumerarea beneficiilor aduse utilizatorului prin

adoptarea acestui scenariu.
Ghid cost-implementare
Soluia general VHWGHUHVSRQVDELOLWi pe care fiecare soluie trebuie s le

satisfac.
Raiuni fundamentale pentru fiecare responsabilitate n termeni de fore aflate

n conflict:
Forele exercitate de activitate i de context,

Forele exercitate de dorinele i capabilitile factorului uman,
Forele exercitate de starea software-lui atunci cnd utilizatorul dorete s aplice
scenariul sensibil din punct de vedere arhitectural.
Soluia specific ablonul arhitectural pentru rezolvarea situaiei, prin

asumarea unui ablon bazat pe separare acoperitor (ex. MVC).
Cristina Mndru
Slide 29
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 conine:
Identificare scenariu de utilizabilitate sensibil din punct de vedere arhitectural

Oferirea de informaii a.. echipa de dezvoltare s poat face aprecieri n
cunotin de cauz despre aplicabilitatea scenariului
Condiiile n care este aplicabil scenariul
Beneficiile oferite de implementarea scenariului
Responsabilitile generale utile n orice situaie, mpreun cu raiunile

fundamentale pentru fiecare responsabilitate
Soluie specific bazat pe MVC.
Cristina Mndru
Slide 30
PLAN CURS
Un exemplu de USAP
Cristina Mndru
Slide 31
USAP exemplu Cancel
Contextul
Beneficiile
Responsabilitile generale
Soluia specific
Situaia: 8WLOL]DWRUXOWULPLWHRFRPDQGi apoi se rzgndete, dorind s

opreasc operaia i s readuc sistemul n starea de dinainte de lansarea
comenzii. Nu conteaz motivul utilizatorului: poate fi o greeal a sa, poate
fi din cauz c sistemul nu rspunde la comand, sau poate s-a modificat
contextul.
Condiii asupra situaiei:

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 ctre utilizator sau se poate
lansa automat prin sesizarea unui anumit context.
Cristina Mndru
Slide 32
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
Crete eficiena utilizatorului individual

Crete performana activitilor de rutin
Accelereaz poriunea liber de erori a performanei operaiilor de rutin

Cancel permite utilizatorilor s revoce comenzi lansate accidental i s revin la la
activitatea anterioar mai repede dect dac ar atepta terminarea comenzii
eronate.
Crete performana activitilor non-rutiniere

Sprijin rezolvarea problemelor
Cancel permite utilizatorului s aplice comenzi i s exploreze fr team,
deoarece i poate oricnd anula aciunile.
Reduce impactul erorilor utilizatorului cauzate de lipsa de cunotine

(greeli)
Se adapteaz greelilor
Cancel permite utilizatorilor s anuleze comenzile pe care le-au invocat din
necunoatere i s revin la activitatea anterioar mai repede dect dac ar
atepta terminarea comenzii eronate.
Cristina Mndru
Slide 33
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
Reduce impactul erorilor sistemului
Tolereaz erorile sistemului

Cancel permite utilizatorilor s anuleze comenzi care nu lucreaz corespunztor.
Crete ncrederea i confortul utilizatorului
Cancel permite utilizatorilor s lucreze fr team deoarece i pot oricnd anula

aciunile.
Cristina Mndru
Slide 34
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
R1: Se va oferi un buton, o opiune de menu, un accelerator i/sau alte

mijloace de a anula comanda curent.
Fore dinspre context i dinspre activitate
Fore dinspre utilizator
Utilizatorii i comunic inteniile prin gesturi speciale (ex.DSVDUHEXWRQ)
Fore dinspre software
Pentru a executa ceva, software-ul trebuie s recepioneze un gest utilizator.
Cristina Mndru
Slide 35
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
R2: Permanent sistemul trebuie s asculte pentru comanda Cancel

sau pentru modificrile de context.
Nimeni nu poate prezice cnd apare o schimbare n context.
Nimeni nu poate prezice cnd utilizatorii vor dori s anuleze o comand.
Cristina Mndru
Slide 36
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
R3: Sistemul trebuie s culeag permanent informaii (stare, utilizare

resurse, gesturi utilizator,HWF.) care permit recuperarea strii sale
de dinainte de executarea comenzii curente.
Cristina Mndru
Slide 37
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
R4: Sistemul trebuie s confirme recepionarea corespunztoare 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 msFL-a fost recepionat comanda, altfel va ncerca
din nou.
Cristina Mndru
Slide 38
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
R5: Dac comanda este capabil s se anuleze direct la momentul

anulrii, comanda trebuie s rspund prin anularea sa.
Activitatea sau contextul a indicat faptul c activitatea trebuie s se termine (ex.
memorie insuficient).
Utilizatorul i-a comunicat dorina de a se termina comanda.
Comanda este reactiv n momentul anulrii.
Cristina Mndru
Slide 39
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
R6: Dac comanda nu este capabil s se anuleze direct la momentul

anulrii, comanda trebuie anulat de ctre o poriune activ a
sistemului.
Comanda nu este reactiv n momentul anulrii.
Cristina Mndru
Slide 40
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
R7: Dac comanda a invocat procese pentru colaborare, aceste

procese trebuie informate despre anularea comenzii ce le-a invocat
(aceste procese au responsabiliti proprii pe care trebuie s le realizeze ca
rspuns la aceast informare, posibil tratnd-o ca pe o anulare).
Informaia dat proceselor colaborator poate include cerere de

anulare, progresul anulrii i/sau ncheierea anulrii.
Comanda a invocat procese colaborator.
Cristina Mndru
Slide 41
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
R8: Dac sistemul este capabil s deruleze napoi toate modificrile,

pn la starea anterioar executrii comenzii de anulat, starea
sistemului trebuie restaurat la starea anterioar executrii
acesteia.
Utilizatorii doresc ca sistemul s funcioneze ca i cnd comanda anulat nu ar fi fost
lansat.
Sistemul este capabil s deruleze napoi toate schimbrile, pn la starea de dinaintea
executrii comenzii.
Cristina Mndru
Slide 42
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
R9: Dac sistemul nu este capabil s deruleze napoi unele modificri

realizate pe durata executrii comenzii de anulat pn la momentul
anulrii, sistemul trebuie restaurat ntr-o stare ct mai apropiat de
cea anterioar executrii comenzii de anulat.
lansat.
Sistemul nu este capabil s deruleze napoi toate schimbrile, pn la starea de
dinaintea executrii comenzii.
Cristina Mndru
Slide 43
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific

anulrii, sistemul trebuie s informeze utilizatorul despre diferena,
dac exist, dintre starea restaurat i cea anterioar lansrii
comenzii de anulat.
lansat. Dac utilizatorii nu sunt contieni de schimbrile de stare, atunci este
posibil s produc erori ulterioare.
Cristina Mndru
Slide 44
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
R11: Sistemul trebuie s elibereze toate resursele (pe care le poate

elibera) consumate pentru procesarea comenzii de anulat.
Sistemul trebuie s rmn stabil n timp.'DFH[LVWUHVXUVHQHHOLEHUDWH, aceasta
poate conduce la degradri i cderi ulterioare ale sistemului (ex. memory leak).
Utilizatorii doresc ca sistemul s revin n starea de dinaintea lansrii comenzii.
Cristina Mndru
Slide 45
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
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 parial.
poate conduce la degradri i cderi ulterioare ale sistemului (ex. memory leak)
Resursele au fost consumate irevocabil i nu pot fi restaurate.
Cristina Mndru
Slide 46
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
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 atepte prea mult anularea
comenzii.
Procesul de anulare a comenzii dureaz mai mult de 1 sec.
Cristina Mndru
Slide 47
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
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.
comenzii.
Cristina Mndru
Slide 48
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
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).
Utilizatorii doresc s fie notificai la ncheierea procesului de anulare.
Cristina Mndru
Slide 49
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
Alte responsabiliti posibile:

n cazul n care comanda anulat este critic, pot fi necesare i alte
aciuni.
Exemple:
Blocarea posibilitii ca utilizatorul s mai trimit i alte comenzi.
Solicitarea de confirmri, dac anumite resurse nu sunt eliberate.
Cristina Mndru
Slide 50
Observaii
Contextul
Beneficiile
Soluia specific
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 relaiei

cost/beneficiu:
Exemplu de intrare n tabel:
Beneficiul : eficien crescut - utilizatorul dorete s lucreze n paralel cu un proces de
anulare de lung durat
Costul : poate fi prea mare, funcie de contextul sistemului.
Cristina Mndru
Slide 51
abloane acoperitoare
Contextul
Beneficiile
Soluia specific
n general proiectanii nu construiesc proiectul sistemului pe baza scenariilor

de utilizabilitate sensibile din punct de vedere arhitectural.
Proiectanii au cteva abloane acoperitoare pe care le utilizeaz (ex. MVC).
Un ablon arhitectural introduce fore suplimentare dinspre software

asupra soluiei specifice.
Vom utiliza MVC pentru a ilustra:
Efectul ablonului acoperitor asupra soluiei specifice
Utilizarea unui ablon larg folosit n aplicaii Web
Cristina Mndru
Slide 52
Soluia specific
Contextul
Beneficiile
Soluia specific
Vedere arhitectural -SUH]LQWXQXOVDXPDLPXOWHDVSHFWHDOH

arhitecturii.
Vederi comune reprezentate n UML:
Diagrama de componente SUH]LQWXQLWile majore de software dar nu

ilustreaz comportamentul dinamic sau asignarea unitilor la diferite
procesoare.
Diagrama de secvene DUDWVHFYHQa activitilor pentru un singur fir de
control n cadrul sistemului.
Cristina Mndru
Slide 53
Soluia specific
Contextul
Beneficiile
Soluia specific
Contextul soluiei specifice MVC
:View
ActiveCommand
:Model
:Controller
Cristina Mndru
Slide 54
Contextul
Beneficiile
Soluia specific
Soluia specific

Diagrama de componente pentru o soluie specific pentru Cancel.
:View
ActiveCommand
:Model
:Controller
Prior-StateManager
:Model
Listener
:Controller
Cristina Mndru
CollaboratingProcess
:Model
CancellationManager
:Model
Slide 55
Soluia specific
Responsabilitile componentelor noi
Listener
Tip: controller
Trebuie s asculte permanent pentru comenzile de anulare sau pentru modificrile de
context (R2)
Cancellation Manager
Contextul
Beneficiile
Soluia specific
Tip: model
Permanent ascult i culege informaii (R2, R3)
Trateaz anularea dac nu primete rspuns 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 informaii (n colaborare cu Cancellation Manager stare, utilizare
resurse, aciuni,...) ce permit refacerea strii sistemului anterioar executrii comenzii
curente (R3)
Dac nu se primete rspuns de la Active Command (R6), colaboreaz cu
Cancellation Manager pentru a restaura sistemul n starea anterioar executrii
comenzii curente (R18) sau ntr-o stare ct mai apropiat de aceasta (R9).
Cristina Mndru
Slide 56
Soluia specific
Responsabilitile noi pentru componentele vechi
View
Contextul
Beneficiile
Soluia specific
Tip: view
Ofer buton, opiune menu, accelerator i/sau alt modalitate de anulare a
comenzii curente (R1)
Trebuie s asculte permanent pentru comenzile de anulare sau pentru
modificrile de context (R2)
Prezint utilizatorului informaiile de feedback despre progresul procesului de
anulare (R4, R14, R15)
Active Command
Tip: model
Culege permanent informaii (R3)
Trateaz anularea prin terminarea proceselor i restaurarea strii i
resurselor(R5, R8, R11)
Trimite feedback corespunztor ctre utilizator (R12, R14, R15)
Cristina Mndru
Slide 57
Contextul
Beneficiile
Soluia specific
Soluia specific
Diagrama de secvene a activitilor anterioare lansrii comenzii de anulare.
:View
:Controller
:User
normal
operation
ActiveCommand
:Model
CancellationManager
:Model
Prior-StateManager
:Model
normal
operation
invoke
register (R3)
save current state (R3)
Cristina Mndru
Slide 58
Contextul
Beneficiile
Soluia specific
Soluia specific
Diagrama de secvene a activitilor de dup lansarea comenzii de anulare.
:View
:User
press
cancel
button (R1)
Listener
:Controller
send cancel
request (R1, R2)
acknowledge
users
command (R4)
ActiveCommand
:Model
CancellationManager
:Model
cancel active
command (R2)
change cursor shape (R14)
Prior-StateManager
:Model
estimates cancel
time 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)
Cristina Mndru
restore cursor (R15)
Slide 59

similare cu Cancel
Undo
Similaritate (VWHQHFHVDUUHYHQLUHDODRVWDUHDQWHULRDUFXQRVFXW.
Diferen UndoVHH[HFXWGRDUGXSWHUPLQDUHDFRPHQ]LL. n acest caz nu

este necesar operaia de ascultare permanent.
Similaritate Nu se poate prezice momentul apariiei.
Diferen 1XVHDIOVXEFRQWUROXOXWLOL]DWRUXOXLLDUGHUXODUHDnapoi se face

ct mai puin posibil (nu neaparat pn la starea de dinaintea lansrii ultimei
comenzi).
Cristina Mndru
Slide 60

Concluzii
Separarea UI de logica aplicaiei SUDFWLFFXUHQWn proiectarea software-lui.

Este suportat proiectarea iterativ a UI, dar sunt introduse probleme de
Aceste probleme apar, n general, n cazul cerinelor de utilizabilitate care
traverseaz componentele separate.
abloanele arhitecturale suport pentru utilizabilitate (USAP) sunt o abordare
pentru soluionarea problemelor de utilizabilitate sensibile din punct de vedere
arhitectural.
Cristina Mndru
Slide 61
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
Cristina Mndru
Slide 62

Curs 13
Cristina Mndru
Slide 1
dirijareDSURLHFWULLXQHLDUKLWHFWXULVRIWZDUH.
DAR exist:

arhitecturilor.
Cristina Mndru
Slide 2
PLAN CURS
Un exemplu de USAP
Cristina Mndru
Slide 3
Utilizabilitate
Def. Utilizabilitate = msura calitii experimentate de utilizator n
interaciunea cu informaii sau servicii.
Chiar dac funcionalitatea este corect,

Chiar dac UI este separat de funcionalitate,
Deciziile arhitecturale realizate iniial pot mpiedica implementarea unui

sistem utilizabil.
E posibil ca o anumit modificare solicitat (de caracteristic sau de

funcionalitate) n sensul creterii utilizabilitii s ajung prea adnc n
arhitectura sistemului pentru a permite realizarea ei viabil din punct de
vedere economic i de timp.
Cristina Mndru
Slide 4
Utilizabilitate exemple de scenarii generale

Feedback warning/status/alert
Se vor afia indicatori de stare sau de alert cnd sunt satisfcute condiiile
corespunztoare.
Profil utilizator
Fiecare utilizator trebuie s poat seta diferii parametrii care controleaz
prezentarea.
Agregare comenzi
Utilizatorul trebuie s poat invoca executarea unei colecii de comenzi.
Recuperarea din avarie
La cderea sistemului, procesorului sau reelei, utilizatorul nu trebuie s piard
starea curent.
Utilizatorul trebuie s poat folosi un limbaj i un format de afiare care i este
familiar.
Cristina Mndru
Slide 5
Obiective curs
nelegerea principiilor de baz ale arhitecturilor software pentru sisteme

interactive.
nelegerea modului n care aceste principii afecteaz utilizabilitateaVLVWHPXOXL.
Motivul utilizrii de abloane bazate pe separare.
Cazuri n care abloanele bazate pe separare nu sunt suficiente.
Cristina Mndru
Slide 6
Practici obinuite n proiectarea de detaliu a sistemelor

interactive
Toate tehnicile HCI (Human Computer Interaction) suport pentru proiectarea de

detaliu a interfeei utilizator sunt bazate pe proiectare iterativ.
(i.e proiectare, testare (analiz sau msurare), modificare, re-testare)
Odat ce software-ul a fost dezvoltat, iterarea implic modificri ale acestuia.
Inginerii software pregtesc realizarea acestor modificri prin izolarea seciunii ce

va fi modificat (separare).
Cristina Mndru
Slide 7
PLAN CURS
Un exemplu de USAP
Cristina Mndru
Slide 8
abloane arhitecturale pentru utilizabilitate

bazate 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)
Reacie la dezavantajele MVC
Utilizate curent n practic, cu succes dovedit.
Cristina Mndru
Slide 9
MVC
Orientat obiect
Model starea i
funcionalitatea aplicaiei
(operaii).
View UHGPRGHOHi trimite

gesturile utilizatorului la
controller.
Dispozitiv
de intrare
View
Comma
Comma
nd
nd
Process
Process
or
or
Model
Comma
Comma
nd
nd
Process
Process
or
or
Dispozitiv
de ieire
Controller
Controller DFWXDOL]HD]
modelul, selecteaz vedere,
definete comportamentul
aplicaiei (interaciuni, flux).
Cristina Mndru
Slide 10
MVC
Avantaje
Suport pentru vederi multiple asupra acelorai date
Utilizatorul are perspective multiple asupra acelorai date (ex. vederi de tip
outline i de tip layout)
Diferite dispozitive prezint aceleai informaii n moduri corespunztoare

platformelor pe care se afl (ex. PDA, laptop)
Diferii utilizatori au acces simultan la aceleai date
Separare prezentare (view) de aplicaie SHUPLWHUHDOL]DUHDGHPRGLILFULDOH

prezentrii independent de restul aplicaiei.
Cristina Mndru
Slide 11
abloane bazate pe separare

Larg utilizate n practic.
Suport pentru dezvoltarea de instrumente specializate
Biblioteci de widget-uri
Diferite tipuri de controller-e
Separarea prezentrii de aplicaie este foarte important.
DAR abloanele bazate pe separare nu sunt suficiente pentru sistemele

interactive.
Cristina Mndru
Slide 12
abloane bazate pe separare i proiectarea iterativ

Cerine revelate pe parcursul proiectrii iterative:
Modificri ale funcionalitii
Modificri ale UI referitoare la coninutul ecranelor
Modificri ale UI dincolo de coninutul ecranului
Modificri facilitate de
arhitectura software
Cerine descoperite
pe parcursul proiectrii
iterative
Zona de modificri dificil de realizat

Cristina Mndru
Slide 13
Modificare asupra caracteristicilor afirii modificare view : view conine toat

logica de afiare.
Ex. Modificare culori, font, aezare n pagin (layout).
Modificare la fluxul prezentrii modificare controller : controller-ul definete fluxul

prezentrii.
Ex. Modificarea ordinii dialogurilor.
Cristina Mndru
Slide 14

Adugarea abilitii de a anula o comand cu durat mare de execuie.
Modificari la toate componentele arhitecturii:
View EXWRQ&DQFHOVDXDOWPRGDOLWDWHGHDFRPDQGDDQXODUHD
Controller ORJLFDGHUVSXQVODFRPDQGi de executare a funciei

corespunztoare
Model modul de alocare a resurselor, ...
Probleme:
Implic toate componentele arhitecturii
Localizare slab
Dac cerina apare trziu,YDQHFHVLWDPRGLILFULFRQVLGHUDELOHDOHDUKLWHFWXULL
Cristina Mndru
Slide 15
Concluzii
Proiectarea de detaliu a interfeei 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.
Cristina Mndru
Slide 16
PLAN CURS
Un exemplu de USAP
Cristina Mndru
Slide 17

(USAP Usability Supporting Architectural Patterns)
Obiectiv recunoaterea i prevenirea problemelor obinuite de utilizabilitate care
nu sunt suportate de principiul separrii.
Soluie - 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 forelor ce acioneaz, n aceste scenarii, asupra

arhitecturii proiectate.
Oferirea unei liste de verificareDUHVSRQVDELOLWilor software importante.
Oferirea de abloane arhitecturaleFXSRVLELOLWi de satisfacere a acestor scenarii.
Cristina Mndru
Slide 18

(USAP)
Sensibilitate din punct de vedere arhitectural
Un scenariu de utilizabilitate este considerat sensibil din punct de vedere arhitectural dac
satisfacerea acestuia poate necesita modificri la arhitectura sistemului.
ntr-un ablon bazat pe separare, aceasta nseamn c implementarea modificrii va avea

impact att asupra prezentrii ct i asupra abstractizrii (modelului).
abloanele bazate pe separare sunt destinate localizrii modificrilor referitoare la

prezentarea informaiilor.
Rezult - exemplu:
Modificri de culori i font QXVXQWVHQVLELOHGLQSXQFWGHYHGHUHDUKLWHFWXUDO
Adugarea opiunii de anulare (Cancel) HVWHVHQVLELOGLQSXQFWGHYHGHUHDUKLWHFWXUDO.
Cristina Mndru
Slide 19

(USAP)
Scenariu de utilizabilitate sensibil din punct de vedere arhitectural - exemplu.
Anulare comenzi
Utilizatorul trimite o comand, apoi se rzgndete dorind oprirea operaiei i
revenirea sistemului la starea dinaintea lansrii comenzii. Nu conteaz motivul
utilizatorului: poate fi o greeal a sa, poate fi din cauz c sistemul nu
rspunde la comand, sau poate s-a modificat contextul.
Cristina Mndru
Slide 20

(USAP)
Exemple de modificri sensibile din punct de vedere arhitectural.
Agregarea datelor
Agregarea comenzilor
Alerte
Anulare comenzi
Verificarea corectitudinii
Evaluarea sistemului
Validare form/cmp
Jurnalizare istoric
Meninerea independenei dispozitivelor
(diferite metode de acces)
Meninerea compatibilitii cu alte sisteme
Accesibilizarea vederilor
Modificarea interfeelor
Navigarea n cadrul unei singure vederi
Observarea strii sistemului
Operare consistent la traversarea vederilor
Feedback al progresului
Help performant (Context-Sensitive Help)
Cristina Mndru

Reutilizare informaii
Extragere parole uitate
Indicare stare
Suport pentru cutri extensive
(diferite limbi)
Suport pentru activiti multiple
Suport pentru Undo
Suport pentru personalizare
(profil utilizator)
Suport pentru vizualizare
Tur
Utilizare concurent
(Multi-tasking)
Verificare resurse
Wizard
ModelDOIOX[XOXLGHDFWLYLWi
Lucru n ritmul utilizatorului
Lucru n context nefamiliar
Slide 21
Echipa de dezvoltare:
Ingineri software
Specialiti n utilizabilitate
Manager proiect
Scenariile de utilizabilitate sensibile din punct de vedere arhitectural sunt

surse de cerine, deci
Trebuie s fie concrete
Trebuie s fie eficace pentru un sistem particular.
Cristina Mndru
Slide 22
n plus fa de scenariile de utilizabilitate sensibile din punct de vedere
arhitectural, sunt necesare:
Determinarea balanei cost-beneficiu n implementarea scenariului

Oferirea unui ghid pentru echipa de dezvoltare referitor la problemele asociate
cu implementarea soluiei.
Ingineri software cost
Specialiti n utilizabilitate - beneficii
Manager proiect - arbitru
Ghid:
Pentru ingineri software
Lista responsabilitilor ce trebuie considerate de ctre orice soluie de implementare a

scenariului
Exemplu de soluie care aloc responsabiliti modulelor bazate pe MVC
Pentru specialitii n utilizabilitate
Tipurile de beneficii ateptate de la scenariul propus
Cristina Mndru
Slide 23
Forele ce acioneaz asupra proiectului arhitectural

Fore diferite motiveaz aspecte
particulare ale soluiei.
Reguli organizaionale la utilizator

Activitate n context
Sistem
Software
Utilizator
Starea software-lui
Fore
Fore
Fore
Dorine i
capabiliti
Beneficii
Cristina Mndru
Fore
Responsabiliti
generale
Beneficii
oferite de
soluie
Decizii de
proiectare
anterioare
Fore
Soluie specific
(mai multe detalii)
Ex. Tactici.
Slide 24
Discuie despre proiectarea arhitecturii

Forele provin din diferite surse:
Activitatea implicat i contextul n care opereaz utilizatorul.
Ex. Cancel este util doar dac operaia este de lung durat.
Dorinele i capabilitile factorului uman.

Ex., Utilizatorii fac greeli. Cancel ofer un mod de a corecta greeli.
Starea sistemului (software-lui).

Ex. Reelele cad. Dnd utilizatorului posibilitatea de anulare a unei operaii,
acesta poate preveni blocarea datorat unei cderi de reea.
Cristina Mndru
Slide 25
Beneficiile utilizabilitii
Elementele ce definesc utilizabilitatea unui sistem software depind de
contextul de utilizare al acestuia.
Aspecte comune:
Eficiena utilizrii
Timpul necesar nvrii modului de utilizare eficient
Suport pentru explorare i pentru rezolvarea problemelor
Satisfacia utilizatorului (ex. ncredere, confort, acceptare de ctre
utilizatorii discreionari)
Beneficiile utilizabilitii pot fi organizate ierarhic.

Cristina Mndru
Slide 26
Beneficiile utilizabilitii o ierarhie

Reduce
impactul
erorilor
sistemului
Crete eficiena
utilizatorului individual
Crete
performana
activitilor
de rutin
Accelereaz
poriunea
liber de
erori a
activitilor
de rutin
Crete
performana
activitilor
non-rutiniere
Reduce
impactul
erorilor
utilizator la
operaiile
de rutin
(scpri din
vedere)
Cristina Mndru
Reduce impactul
erorilor
utilizatorului
datorate lipsei de
cunotine
Sprijin
Faciliteaz
rezolvarea
problemelor nvarea
Previne
greelile
Previne
erorile
sistemului
Crete
ncrederea i
confortul
utilizatorului
Tolereaz
erorile
sistemului
Se adapteaz
greelilor
Slide 27
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 soluiei:
Soluia general UHVSRQVDELOLWile software-lui ce trebuie ndeplinite de

orice soluie.
Soluia specific un ablon arhitectural care arat cum trebuie
implementat soluia general n contextul unui ablon bazat pe separare.
Pentru exemplificare, vom considera MVC ca fiind un ablon bazat pe separare

acoperitor.
Cristina Mndru
Slide 28
Documentarea ablonului
Context
Situaia scenarii de utilizabilitate sensibile din punct de vedere arhitectural.
Condiiile constrngeri asupra momentelor cnd situaia este relevant.
Beneficiile utilizabilitii enumerarea beneficiilor aduse utilizatorului prin

adoptarea acestui scenariu.
Ghid cost-implementare
Soluia general VHWGHUHVSRQVDELOLWi pe care fiecare soluie trebuie s le

satisfac.
Raiuni fundamentale pentru fiecare responsabilitate n termeni de fore aflate

n conflict:
Forele exercitate de activitate i de context,

Forele exercitate de dorinele i capabilitile factorului uman,
Forele exercitate de starea software-lui atunci cnd utilizatorul dorete s aplice
scenariul sensibil din punct de vedere arhitectural.
Soluia specific ablonul arhitectural pentru rezolvarea situaiei, prin

asumarea unui ablon bazat pe separare acoperitor (ex. MVC).
Cristina Mndru
Slide 29
Concluzii
abloanele bazate pe separare nu ofer suport pentru toate scenariile de
Abordarea prezentat este mpachetat n USAP i conine:
Identificare scenariu de utilizabilitate sensibil din punct de vedere arhitectural

Oferirea de informaii a.. echipa de dezvoltare s poat face aprecieri n
cunotin de cauz despre aplicabilitatea scenariului
Condiiile n care este aplicabil scenariul
Beneficiile oferite de implementarea scenariului
Responsabilitile generale utile n orice situaie, mpreun cu raiunile

fundamentale pentru fiecare responsabilitate
Soluie specific bazat pe MVC.
Cristina Mndru
Slide 30
PLAN CURS
Un exemplu de USAP
Cristina Mndru
Slide 31
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
Situaia: 8WLOL]DWRUXOWULPLWHRFRPDQGi apoi se rzgndete, dorind s

opreasc operaia i s readuc sistemul n starea de dinainte de lansarea
comenzii. Nu conteaz motivul utilizatorului: poate fi o greeal a sa, poate
fi din cauz c sistemul nu rspunde la comand, sau poate s-a modificat
contextul.
Condiii asupra situaiei:

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 ctre utilizator sau se poate
lansa automat prin sesizarea unui anumit context.
Cristina Mndru
Slide 32
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
Crete eficiena utilizatorului individual

Crete performana activitilor de rutin
Accelereaz poriunea liber de erori a performanei operaiilor de rutin

Cancel permite utilizatorilor s revoce comenzi lansate accidental i s revin la la
activitatea anterioar mai repede dect dac ar atepta terminarea comenzii
eronate.
Crete performana activitilor non-rutiniere

Sprijin rezolvarea problemelor
Cancel permite utilizatorului s aplice comenzi i s exploreze fr team,
deoarece i poate oricnd anula aciunile.
Reduce impactul erorilor utilizatorului cauzate de lipsa de cunotine

(greeli)
Se adapteaz greelilor
Cancel permite utilizatorilor s anuleze comenzile pe care le-au invocat din
necunoatere i s revin la activitatea anterioar mai repede dect dac ar
atepta terminarea comenzii eronate.
Cristina Mndru
Slide 33
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
Reduce impactul erorilor sistemului
Tolereaz erorile sistemului

Cancel permite utilizatorilor s anuleze comenzi care nu lucreaz corespunztor.
Crete ncrederea i confortul utilizatorului
Cancel permite utilizatorilor s lucreze fr team deoarece i pot oricnd anula

aciunile.
Cristina Mndru
Slide 34
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
R1: Se va oferi un buton, o opiune de menu, un accelerator i/sau alte

mijloace de a anula comanda curent.
Utilizatorii i comunic inteniile prin gesturi speciale (ex.DSVDUHEXWRQ)
Pentru a executa ceva, software-ul trebuie s recepioneze un gest utilizator.
Cristina Mndru
Slide 35
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
R2: Permanent sistemul trebuie s asculte pentru comanda Cancel

sau pentru modificrile de context.
Cristina Mndru
Slide 36
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
R3: Sistemul trebuie s culeag permanent informaii (stare, utilizare

resurse, gesturi utilizator,HWF.) care permit recuperarea strii sale
de dinainte de executarea comenzii curente.
Cristina Mndru
Slide 37
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
R4: Sistemul trebuie s confirme recepionarea corespunztoare 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 msFL-a fost recepionat comanda, altfel va ncerca
din nou.
Cristina Mndru
Slide 38
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
R5: Dac comanda este capabil s se anuleze direct la momentul

anulrii, comanda trebuie s rspund prin anularea sa.
Comanda este reactiv n momentul anulrii.
Cristina Mndru
Slide 39
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
R6: Dac comanda nu este capabil s se anuleze direct la momentul

anulrii, comanda trebuie anulat de ctre o poriune activ a
sistemului.
Comanda nu este reactiv n momentul anulrii.
Cristina Mndru
Slide 40
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
R7: Dac comanda a invocat procese pentru colaborare, aceste

procese trebuie informate despre anularea comenzii ce le-a invocat
(aceste procese au responsabiliti proprii pe care trebuie s le realizeze ca
rspuns la aceast informare, posibil tratnd-o ca pe o anulare).
Informaia dat proceselor colaborator poate include cerere de

anulare, progresul anulrii i/sau ncheierea anulrii.
Comanda a invocat procese colaborator.
Cristina Mndru
Slide 41
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
R8: Dac sistemul este capabil s deruleze napoi toate modificrile,

pn la starea anterioar executrii comenzii de anulat, starea
sistemului trebuie restaurat la starea anterioar executrii
acesteia.
lansat.
Sistemul este capabil s deruleze napoi toate schimbrile, pn la starea de dinaintea
executrii comenzii.
Cristina Mndru
Slide 42
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific

anulrii, sistemul trebuie restaurat ntr-o stare ct mai apropiat de
cea anterioar executrii comenzii de anulat.
lansat.
Cristina Mndru
Slide 43
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific

anulrii, sistemul trebuie s informeze utilizatorul despre diferena,
dac exist, dintre starea restaurat i cea anterioar lansrii
comenzii de anulat.
lansat. Dac utilizatorii nu sunt contieni de schimbrile de stare, atunci este
posibil s produc erori ulterioare.
Cristina Mndru
Slide 44
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
R11: Sistemul trebuie s elibereze toate resursele (pe care le poate

elibera) consumate pentru procesarea comenzii de anulat.
poate conduce la degradri i cderi ulterioare ale sistemului (ex. memory leak).
Cristina Mndru
Slide 45
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
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 parial.
poate conduce la degradri i cderi ulterioare ale sistemului (ex. memory leak)
Resursele au fost consumate irevocabil i nu pot fi restaurate.
Cristina Mndru
Slide 46
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
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).
comenzii.
Cristina Mndru
Slide 47
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
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.
comenzii.
Cristina Mndru
Slide 48
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
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).
Utilizatorii doresc s fie notificai la ncheierea procesului de anulare.
Cristina Mndru
Slide 49
USAP exemplu Cancel
Contextul
Beneficiile
Soluia specific
Alte responsabiliti posibile:

n cazul n care comanda anulat este critic, pot fi necesare i alte
aciuni.
Exemple:
Blocarea posibilitii ca utilizatorul s mai trimit i alte comenzi.
Solicitarea de confirmri, dac anumite resurse nu sunt eliberate.
Cristina Mndru
Slide 50
Observaii
Contextul
Beneficiile
Soluia specific
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 relaiei

cost/beneficiu:
Exemplu de intrare n tabel:
Beneficiul : eficien crescut - utilizatorul dorete s lucreze n paralel cu un proces de
anulare de lung durat
Costul : poate fi prea mare, funcie de contextul sistemului.
Cristina Mndru
Slide 51
abloane acoperitoare
Contextul
Beneficiile
Soluia specific
n general proiectanii nu construiesc proiectul sistemului pe baza scenariilor

de utilizabilitate sensibile din punct de vedere arhitectural.
Proiectanii au cteva abloane acoperitoare pe care le utilizeaz (ex. MVC).
Un ablon arhitectural introduce fore suplimentare dinspre software

asupra soluiei specifice.
Vom utiliza MVC pentru a ilustra:
Efectul ablonului acoperitor asupra soluiei specifice
Utilizarea unui ablon larg folosit n aplicaii Web
Cristina Mndru
Slide 52
Soluia specific
Contextul
Beneficiile
Soluia specific
Vedere arhitectural -SUH]LQWXQXOVDXPDLPXOWHDVSHFWHDOH

arhitecturii.
Vederi comune reprezentate n UML:
Diagrama de componente SUH]LQWXQLWile majore de software dar nu

ilustreaz comportamentul dinamic sau asignarea unitilor la diferite
procesoare.
Diagrama de secvene DUDWVHFYHQa activitilor pentru un singur fir de
control n cadrul sistemului.
Cristina Mndru
Slide 53
Soluia specific
Contextul
Beneficiile
Soluia specific
:View
ActiveCommand
:Model
:Controller
Cristina Mndru
Slide 54
Contextul
Beneficiile
Soluia specific
Soluia specific

Diagrama de componente pentru o soluie specific pentru Cancel.
:View
ActiveCommand
:Model
:Controller
Prior-StateManager
:Model
Listener
:Controller
Cristina Mndru
CollaboratingProcess
:Model
CancellationManager
:Model
Slide 55
Soluia specific
Responsabilitile componentelor noi
Listener
Tip: controller
Trebuie s asculte permanent pentru comenzile de anulare sau pentru modificrile de
context (R2)
Cancellation Manager
Contextul
Beneficiile
Soluia specific
Tip: model
Permanent ascult i culege informaii (R2, R3)
Trateaz anularea dac nu primete rspuns 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 informaii (n colaborare cu Cancellation Manager stare, utilizare
resurse, aciuni,...) ce permit refacerea strii sistemului anterioar executrii comenzii
curente (R3)
Dac nu se primete rspuns de la Active Command (R6), colaboreaz cu
Cancellation Manager pentru a restaura sistemul n starea anterioar executrii
comenzii curente (R18) sau ntr-o stare ct mai apropiat de aceasta (R9).
Cristina Mndru
Slide 56
Soluia specific
Responsabilitile noi pentru componentele vechi
View
Contextul
Beneficiile
Soluia specific
Tip: view
Ofer buton, opiune menu, accelerator i/sau alt modalitate de anulare a
comenzii curente (R1)
Trebuie s asculte permanent pentru comenzile de anulare sau pentru
modificrile de context (R2)
Prezint utilizatorului informaiile de feedback despre progresul procesului de
anulare (R4, R14, R15)
Active Command
Tip: model
Culege permanent informaii (R3)
Trateaz anularea prin terminarea proceselor i restaurarea strii i
resurselor(R5, R8, R11)
Trimite feedback corespunztor ctre utilizator (R12, R14, R15)
Cristina Mndru
Slide 57
Contextul
Beneficiile
Soluia specific
Soluia specific
Diagrama de secvene a activitilor anterioare lansrii comenzii de anulare.
:View
:Controller
:User
normal
operation
ActiveCommand
:Model
CancellationManager
:Model
Prior-StateManager
:Model
normal
operation
invoke
register (R3)
save current state (R3)
Cristina Mndru
Slide 58
Contextul
Beneficiile
Soluia specific
Soluia specific
Diagrama de secvene a activitilor de dup lansarea comenzii de anulare.
:View
:User
press
cancel
button (R1)
Listener
:Controller
send cancel
request (R1, R2)
acknowledge
users
command (R4)
ActiveCommand
:Model
CancellationManager
:Model
cancel active
command (R2)
change cursor shape (R14)
Prior-StateManager
:Model
estimates cancel
time 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)
Cristina Mndru
restore cursor (R15)
Slide 59

similare cu Cancel
Undo
Similaritate (VWHQHFHVDUUHYHQLUHDODRVWDUHDQWHULRDUFXQRVFXW.
Diferen UndoVHH[HFXWGRDUGXSWHUPLQDUHDFRPHQ]LL. n acest caz nu

este necesar operaia de ascultare permanent.
Similaritate Nu se poate prezice momentul apariiei.
Diferen 1XVHDIOVXEFRQWUROXOXWLOL]DWRUXOXLLDUGHUXODUHDnapoi se face

ct mai puin posibil (nu neaparat pn la starea de dinaintea lansrii ultimei
comenzi).
Cristina Mndru
Slide 60

Concluzii
Separarea UI de logica aplicaiei SUDFWLFFXUHQWn proiectarea software-lui.

Este suportat proiectarea iterativ a UI, dar sunt introduse probleme de
Aceste probleme apar, n general, n cazul cerinelor de utilizabilitate care
traverseaz componentele separate.
abloanele arhitecturale suport pentru utilizabilitate (USAP) sunt o abordare
pentru soluionarea problemelor de utilizabilitate sensibile din punct de vedere
arhitectural.
Cristina Mndru
Slide 61
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
Cristina Mndru
Slide 62

Curs 14
Cristina Mndru
Slide 1
PLAN CURS
Linii de produse software
Domeniul liniei de produse
Potenial de reutilizare
Arhitectura software UHVXUVUHXWLOL]DELO

Rolul arhitecturii n linia de produse
Variabilitate
Documentarea i evaluarea arhitecturii
Problematica adoptrii liniilor de produse

Studiu de caz - linia de produse osciloscoape Tektronix
Standarde pentru integrare de componente
Cristina Mndru
Slide 2
Reutilizare n producia de bunuri

Soluie productivitate:
Linii de producie (iniiator: Ford) producie pentru pia masiv, dar cu posibiliti
reduse de diversificare.
Cerin:
Personalizare n mas (mass customization) = producia pe scar larg de bunuri
croite conform cerinelor clienilor individuali.
Soluie productivitate:
Platform = baz de tehnologii pe care sunt construite alte tehnologii sau procese.
Cristina Mndru
Slide 3
Reutilizare n dezvoltarea de software

Ideal:
Construirea de sisteme software asamblndu-le din piese existente deja (ca ntrun puzzle).
Real:
Seamn mai curnd cu construirea de jucrii avnd la dispoziie o cutie plin cu

piese din diferite jocuri (Puzzle, Lego, ...), i nc o mulime de alte kit-uri incompatibile
culegem piese i ne ateptm s se potriveasc.
O soluie linii de produse software

Utilizarea unui set de active de baz pentru producerea unui set de produse
nrudite.
Flexibilitatea = caracteristica cheie pentru liniile de produse.
Cristina Mndru
Slide 4
Reutilizare - istoric
Liniile de produse software bazate pe caracteristici comune ale produselor

reprezint un concept inovativ i n evoluie al ingineriei software.
Linda Northrop, Software Product Lines Essentials, 2008
http://www.sei.cmu.edu
Cristina Mndru
Slide 5
Linii de produse o definiie

Def. Linie de produse software = set de sisteme intensiv software
care au un set comun, gestionat, de caracteristici care satisfac necesitile specifice unui
anumit segment de pia sau unui anumit scop
i care sunt dezvoltate dintr-un nucleu comun de active (resurse) de baz, ntr-un mod
prestabilit.
Referitor la
Strategie de pia/
Domeniu de aplicare
Este satisfcut de
Partajeaz
Arhitectur
Produse
Utilizat pentru a structura
Sunt construite din
Componente
Cristina Mndru
Slide 6
Concepte fundamentale
Nucleu comun de active de baz = colecie de artefacte i resurse.
Diferenierea produselor prin adaptareaDFWLYHORUGHED]:
planificat nainte de dezvoltarea produsului
uor de utilizat de ctre dezvoltatori
fr a periclita proprietile existente ale activelor de baz
REUTILIZARE STRATEGIC.
Strategie plan de aciune pentru atingerea unui anumit scop.
Construirea de produse particulare conform unui planGHUHXWLOL]DUHDDFWLYHORUGH

baz i a variabilitilor implementate n acestea.
Cristina Mndru
Slide 7
Concepte fundamentale
Activ de baz artefact sau resurs construit pentru a fi utilizat n producerea mai multor
produse ale liniei de produse.
Variabilitate = abilitatea unui sistem, a unui activ sau a unui mediu de dezvoltare de a oferi
suport pentru producerea unui set de artefacte care difer ntre ele ntr-o manier
preplanificat.
Variabilitate LP abilitatea unui activ de baz de a se adapta la utilizri n diferite contexte
ale produselor din cadrul domeniului LP
Activ de produs = artefact parte a unui produs din linia de produse software.
Domeniu = mulime de cunotine specializate,GRPHQLXGHH[SHUWL], sau colecie de
funcionaliti corelate.
Practic a liniei de produse software utilizarea sistematic a activelor de baz pentru
asamblarea, instanierea, sau generarea de produse multiple care constituie linia de
produse software; implic reutilizare strategic, cu granularitate mare.
Cristina Mndru
Slide 8
Variabilitate
Parte variabil parte ce poate s varieze a unui activ.
Variaie = modul n care difer dou sau mai multe variante GHVFULVn termeni
de capabiliti sau proprieti pe care le au variantele.
Mecanism de variaie mecanism care sprijin crearea i/sau selectarea de
variante conforme cu constrngerile pentru partea variabil a activului de
baz. (ncapsuleaz partea variabil)
Variant realizarea unei pri variabile a unui activ de baz prin exercitarea
mecanismelor sale de variaie.
Variabilitate n timp = existena de versiuni diferite ale unui artefact care sunt valide la diferite
momente de timp.
Variabilitate n spaiu = existena unui artefact sub diferite forme n acelai timp.
Cristina Mndru
Slide 9
Variabilitate - exemple
Parte variabil
Variaie
Variant
reea comunicare
tip reea comunicare
LAN cablat, LAN wireless, PAN
securizare
model securitate
autentificare, firewall, criptare
UI
tip UI
UI dispozitive mobile, GUI desktop,

GUI Web
interfa subsistem
protocol comunicare
list protocoale de comunicare prin

interfaa respectiv
Cristina Mndru
Slide 10
Variabilitate - exemple
Exemple de spaii de variabilitate.
Neil Mather, Concepts and Implementation

Techniques for Web Systems ProductLines Using Existing Frameworks, ACM
Digital Library 2011
Cristina Mndru
Slide 11
Ingineria liniilor de produse software

Dezvoltare linie de produse procesul de creare de active de baz sau de produse ale liniei
de produse.
Ingineria domeniului procesul n care sunt definite i realizate elementele comune

(similitudinile) i variabilitatea liniei de produse. realizarea platformei (elementele
comune i suportul pentru variabilitate). dezvoltareaDFWLYHORUGHED]
Subprocese cheie: managementul produsului, ingineria cerinelor de domeniu, modelarea
domeniului, realizarea domeniului (implementarea modelului), testarea domeniului
Ex. www.methodsandtools.com-archive-archive.php?id=49
Features concepte abstracte pentru descrierea aspectelor comune i aspectelor variabile.
Ingineria aplicaiilor procesul n care sunt construite aplicaiile liniei de produse prin
reutilizarea artefactelor domeniului i exploatarea variabilitii liniei de produse.
dezvoltarea produselor.
Cristina Mndru
Slide 12
Haitham S. Hamza, Gamal M. Aly, Using Product Line

Architectures to Leverage Systematic Reuse of
Business Knowledge: An Industrial
Experience, ACM Digital Library 2010
Cristina Mndru
Slide 13
Variabilitate
Cerin:
Gestionarea variabilitii, n mod consistent, pentru ntreaga linie de produse
Soluie:
Crearea activelor de baz cu variabilitate inclus.
Modelarea explicit a variabilitii
Modelul de variabilitate:
activele de baz
aspectele variabile la fiecare activ de baz
condiiile pentru variaii n fiecare activ de baz
mecanismele de variaie
consecinele aplicrii variaiei
Cristina Mndru
Slide 14
Exemplu
Felix Bachmann, Paul C. Clements, Variability in Software Product Lines, Technical report 2005
http://www.sei.cmu.edu
Cristina Mndru
Slide 15

Dezvoltare activ de baz
Determinarea a ceea ce rmne neschimbat n fiecare produs ce-l folosete i ceea ce

trebuie s varieze de la un produs la altul.
Alegerea unui mecanism de variaie care sprijin variaia necesar, permind totodat
ca ceea ce este comun s fie oferit fr variaie de la un produs la altul.
Furnizarea de instruciuni (sub forma unui plan de producie) care explic dezvoltatorilor
de produse cum trebuie s utilizeze mecanismele de variaie incluse n activele de baz
pentru a crea produsul.
Dezvoltare produs
Adaptarea i configurarea activelor reutilizabile pentru a ndeplini cerine specifice

Aplicarea planului de producie pentru setul activelor de baz ce intr n componena
produsului dezvoltat.
Executarea procesului de aplicare a fiecrui mecanism de variaie necesar.
Cristina Mndru
Slide 16
Variabilitatea n liniile de produse

Activ de baz
Parte variabil
Variant
Condiie de aplicare
mecanism de variaie
Proces de aplicare
mecanism de variaie
Mecanism de variaie
Bachmann F, Clements P.C, Variability in Software Product Lines, technical report 2005
Cristina Mndru
Slide 17

Instrumente specializate:
http://www.biglever.com/?source=splsite
http://www.pure-systems.com/Home.142.0.html
http://www.esi.es/plum/
OpenSource
http://gsd.uwaterloo.ca:8088/SPLOT/splot_open_source.html
Lista instrumente aplicabile

http://www.softdevtools.com/modules/weblinks/viewcat.php?cid=92
Site:
http://www.softwareproductlines.com/
Cristina Mndru
Slide 18
Avantaje
Eficien i productivitate crescute.
mbuntirile remarcabile pentru
cost,
timp de lansare pe pia
productivitate
EXEMPLE
Nokia raporteaz producerea a 25 - 30 de modele diferite de telefoane pe an prin abordarea

liniilor de produse.
Cummins a redus timpul de produse a software-lui pentru un motor diesel de la 1 an la 1

sptamn.
Motorola a realizat o cretere cu 400% a productivitii la o familie de pager-e unidirecionale.
Hewlett-Packard a redus timpul de lansare pe pia cu un factor de 7 i a crescut

productivitatea cu un factor de 4 la o familie de imprimante.
Cristina Mndru
Slide 19
Exemplu - Nokia
Variabilitate
numr de taste
dimensiune afiaj
setul de caracteristici
suport pentru limb i ar
protocol de comunicare
caracteristici configurabile
comportament
etc.
Cristina Mndru
Slide 20
PLAN CURS

Variabilitate

Cristina Mndru
Slide 21
Domeniul liniei de produse (1)

Domeniul unei linii de produse delimiteaz sistemele care aparin de cele
care nu aparin liniei de produse.
Reprezint predicia cea mai bun a organizaiei referitoare la ce produse i vor fi
solicitate n viitor.
Este determinat de :
Realizatorii planurilor stategice
Marketing
Analitii de domeniu
Nevoia de a construi mai multe produse similare
Cristina Mndru
Slide 22
Domeniul liniei de produse (2)

Analiza variabilitii liniei de produse discerne ntre aspectele comune
pentru toi membrii familiei i aspectele variabile de la un membru la
altul.
Implic studiul pieelor, stakeholder-ilor i proiectare n scopul identificrii
elementelor comune.
Discuie - dimensiunea domeniului liniei de produse:
Domeniu prea ngust (produsele variz n cadrul unui numr redus de caracteristici)
numr insuficient de produse pentru a se justifica linia de produse.
Domeniu prea larg (produsele variaz ca tipuri i caracteristici) costuri prea mari
pentru
construirea de produse individuale,
ntreinerea resurselor de baz.
Cristina Mndru
Slide 23
PLAN CURS

Variabilitate

Cristina Mndru
Slide 24
Potenial de reutilizare (1)

Cerine
Majoritatea cerinelor sunt comune cu cele ale sistemelor instaniate anterior din
linia de produse, deci pot fi re-utilizate.
Proiect arhitectural
O arhitectur reprezint o investiie de timp semnificativ din partea celor mai

talentai ingineri ai firmei.
Pentru un produs nou, pasul cel mai important al proiectrii este deja fcut.
Modele, cod i documentaie
Pe lng reutilizarea codului, reutilizarea elementelor include artefacte de

proiectare i documentaie.
Analiz
Modele pentru performan, analize ale graficului de timp, analize ale sistemelor
distribuite, alocarea proceselor la procesoare, tolerana la defecte, ncrcarea
reelei, i altele asemenea, pot fi reutilizate la toate produsele din linia de
produse.
Cristina Mndru
Slide 25

Testare
Planurile, procesele, cazurile, datele, ncrcrile, instrumentele de testare,

raportarea defectelor i urmrirea proceselor, pot fi stabilite o singur dat pentru
o linie de produse.
Eliminare defecte
Liniile de produse duc la mbuntirea mai rapid a calitii produselor deoarece

fiecare sistem nou preia avantajele legate de eliminarea defectelor din sistemele
ce l-au precedat.
Pot fi remediate clase largi de produse atunci cnd un client gsete un defect la
un membru al familiei.
Cu fiecare instaniere de produs nou, crete ncrederea dezvoltatorului i a

clientului.
Cu ct sistemul este mai complicat, cu att este mai mare avantajul primit la
rezolvarea problemelor dificile pentru ntreaga familie de produse.
Cristina Mndru
Slide 26

Exemplare de sisteme
Produsele puse n funciune servesc ca prototipuri de demonstrare i ca modele

de inginerie pentru produsele viitoare.
Personal calificat
Expertiza este aplicabil ntregii linii de produse.
Planificare proiect
Bugetarea i planificarea sunt mai predictibile deoarece experiena este cel mai
bun indicator al performanei viitoare.
Structurile de divizare a activitii (WBS) nu trebuie reinventate.
Dimensiunea i compoziia echipei sunt uor de determinat pe baza experienei

anterioare.
Procese, metode i instrumente
Controlul configuraiilor, facilitile, planurile, procesele de aprobare,

instrumentele, procesele de punere n funciune, standardele de codificare, i o
varietate de activiti suport zilnice odat stabilite sunt valabile pentru ntreaga
linie de produse.
Cristina Mndru
Slide 27
PLAN CURS

Variabilitate

Cristina Mndru
Slide 28
Reutilizarea arhitecturii software
Majoritatea firmelor produc familii formate din produse nrudite,

difereniate printr-o serie de caracteristici.
Aceast situaie poate oferi o oportunitate de reutilizare a arhitecturilor

i a restului activelor de baz corelate cu acestea.
Dezvoltarea unei arhitecturi software reprezint o investiie

semnificativ.
Investiia ar putea fi amortizat prin utilizarea ei la mai multe sisteme.
Reutilizarea poate oferi un avantaj competitiv major.
Pentru a stabili o linie de produse viabil este necesar proiectarea

arhitecturii software cu intenia de a fi reutilizat.
Cristina Mndru
Slide 29
Arhitecturi pentru linii de produse

Observaia de baz :H[LVWVLPLODULWi ntre produse anterioare i viitoare.
Se pot obine economii de producie prin:

Definirea aspectelor comune.
Oferirea unei infrastructuri reutilizabile (cadru) care s fie suport pentru
aceste aspecte comune.
Definirea unui mod de a specializa cadrul pentru un produs particular.
La baza acestui efort se regsete n mod tipic o arhitectur software care
stabilete o viziune comun pentru structura, coninutul i variabilitatea
produselor din familie.
Cristina Mndru
Slide 30
Arhitectura liniei de produse

ntr-o strategie bazat pe linii de produse, produsele sunt instaniate dintr-o
arhitectur comun.
Ofer structura tuturor produselor din familia liniei de produse.
Definete elementele, relaiile, interfeele,.a., care constituie baza de

resurse.
St la baza planurilor de producie care definesc modul n care

produsele sunt instaniate din arhitectura liniei de produse, utiliznd i
elemente din baza de resurse.
Centrarea pe arhitectur sprijin reutilizarea strategic (care este diferit de reutilizarea

aleatoare.)
Cristina Mndru
Slide 31
Rolul arhitecturii n liniile de produse

Arhitectura joac un rol cheie n liniile de produse.
Structurile arhitecturale (abloane, stiluri,...)
tipizeaz o familie de soluii la probleme recurente specifice unui domeniu

particular.
pot conduce la arhitecturi de referin
care reprezint modele reutilizabile de cunotine.
Promoveaz ceea ce este comun produselor.

Faciliteaz reutilizarea i liniile de produse.
Reduce curba de nvare.
Exemple din industrie: ERP, CRM,
avionic, telecomunicaii.
Arhitecturile de referin
definesc esena arhitecturii sistemelor pentru un anumit domeniu
pot fi utilizate pentru a crea cadre de implementare.
Cadrele de implementareQXVXQWDUKLWHFWXUDSURGXVXOXLGDURIHUXQDYDQWDMHFRQRPLF
semnificativ prin reducerea:
timpului necesar proiectrii, codificrii i testrii de funcionalitate similar,
numrului de defecte introduse n produs.
Cristina Mndru
Slide 32
Arhitecturi i cadre de dezvoltare de aplicaii

Cadrele de implementare bazate pe arhitecturi de referin sunt folosite pentru construirea de
produse pentru domeniul respectiv.
Exemplu: derivare cadru de implementare pentru aplicaii business orientate web.
Cunoatere
codificat:
contabilitate
management al
clienilor
:
Cunoatere
codificat:
reelistic
protocoale
partiionare i
responsabiliti ale
elementelor
:
Domeniul:
E-business
Stilul:
client server
pe n trepte
Arhitectura de
referin:
Cadrul de
implementare:
Standardul JavaEE
JBoss
Cunoatere
codificat:
specificaii servicii
limbaj
modele de fire de
execuie
:
Cunoatere codificat:
biblioteci de servicii
servicii de securitate
servicii de
tranzacionare
Modele de dezvoltare
:
Putem aplica deliberat acest concept pentru o familie de produse nrudite, adic vom
defini arhitectura familiei de produse din care vom deriva un cadru de dezvoltare
a produselor familiei respective.
Cristina Mndru
Slide 33
Arhitecturi i cadre de dezvoltare

Arhitectur de referin nglobeaz cunoatere despre cum se proiecteaz
arhitecturi concrete de sisteme pentru un anumit domeniu de aplicaii.
Arhitectur linie de produse VSHFLDOL]DWSHXQVXEVHW
specific de sisteme software dintr-un domeniu; soluie
standardizat pentru o familie de produse.
Produs
Cristina Mndru
Slide 34
Linii de produse atribute de calitate

Caliti necesare arhitecturilor software pentru linii de produse :
Modificabilitate abilitatea de a asambla diferite elemente n diferite combinaii
Portabilitate abilitatea de a utiliza diferite elemente hardware
Scalabilitate abilitatea de a suporta extinderi n dimensiune, funcionalitate,...

SAU abilitatea de a suporta scderi n dimensiune.
Extensibilitate DELOLWDWHDGHDDGXJDQRLFDUDFWHULVWLFLIDPLOLHLGHSURGXVH.
Caliti necesare produselor instaniate din linia de produse :
Performan
Cost
Funcionalitate
Obs. O arhitectur bun nu implic necesitatea sau posibilitatea unei linii de produse.
Cristina Mndru
Slide 35

Arhitectura software rolul central n grupul activelor de baz ale liniei de
produse.
Responsabiliti ale arhitectuluiXQHLOLQLLGHSURGXVH:
Identific prile variabile ale produselor
Ofer suport pentru variabilitate n cadrul arhitecturii
Evalueaz adecvarea arhitecturii la linia de produse
Caracteristici ale arhitecturiiXQHLOLQLLGHSURGXVH:
Se aplic tuturor membrilor liniei de produse FKLDUGDFIXQFiile i

calitile lor difer.
Conine att aspectele comune ct i aspectele variabile ale membrilor
familiei.
Cristina Mndru
Slide 36
PLAN CURS

Variabilitate

Cristina Mndru
Slide 37
Identificarea variaiilor
Def. Variaie = o diferen dintre dou sau mai multe produse.
Exemple:
Dirijori arhitecturali: funcionalitate, constrngeri, atribute de calitate
Platforme
Piee int
Interfee (cultur/limb), etc.
Variaiile produselor trebuie identificate n cadrul procesului de culegere i

analiz a cerinelor.
Identificarea variaiilor trebuie s fie o activitate continu de-a lungul ciclului de
via al liniei de produse.
Cristina Mndru
Slide 38
Mecanisme de variaie
Mecanism de variaie - introdus n active de baz.
Exemple:
motenire,
substituire componente,
plug-ins,
template,
parametri,
generator,
aspecte,
configurator,
execuii condiionale
Cristina Mndru
Slide 39
Mecanisme de variaie
Includerea sau omiterea de elemente
De exemplu, compilare condiional sau proceduri de construire (build) care includ sau exclud
diferite elemente pentru diferite instanieri de produse.
Includerea unui numr diferit de elemente replicate

De exemplu, pentru a crete capacitatea se pot produce variante prin adugare de servere.
Selectarea sau configurarea elementelor care ofer diferite caracteristici de

comportament i/sau atribute de calitate.
De exemplu, s considerm dou produse ce utilizeaz acelai element:HOHPHQWXOVXSRUW
dezactivarea sau reactivarea unor caracteristici, funcie de produsul la care este folosit.
Specializarea i/sau generalizarea claselor care conin elementele de variaie.

Clasele pot fi scrise a.. s se poat adapta unei varieti de specializri ce pot fi scrise pentru
fiecare produs.
Configurare la momentul execuiei (runtime):
Configurarea la execuie bazat pe parametri inclui n elemente, ca suport pentru variabilitate.
Configurare dinamic de tip plug-and-play.
Cristina Mndru
Slide 40
PLAN CURS

Variabilitate

Cristina Mndru
Slide 41
Documentaie
Documentaie (suplimentar) specific liniilor de produse:
Documentaie pentru toate activele de baz (incluznd cerine, proiectare, etc.)
Prile variabile
Motivaii de stabilire a prii variabile legate de domeniul curent al liniei de

produse.
Descrierea locului i motivelor variaiilor din produse i a modului n care acesta

sunt tratate.
Combinaiile de elemente permise i interzise.
Planul de producieFDUHLQGLFPRGXOn care vor fi construite sau instaniate

produsele.
Cristina Mndru
Slide 42
Evaluarea arhitecturii unei linii de produse

Evaluare n raport cu adecvarea la obiectiv (ca pentru orice arhitectur software).
Motivaii pentru realizarea evalurii:
Multe sisteme depind de arhitectur
Crearea arhitecturii este o investiie semnificativ
Succesul unei firme poate sta n arhitectura liniei de produse
Arhitectura trebuie s poat suporta cerinele de COMPORTAMENT I

cele pentru ATRIBUTE DE CALITATE pentru TOI membrii liniei de
produse.
Evaluatorii trebuie s dezvolte scenarii care implic instanierea arhitecturii
pentru diferite produse din familia de produse.
Cristina Mndru
Centrare pe prile variabile, care trebuie s:
adreseze corespunztor fiecare membru al familiei de produse,
ofere suficient flexibilitate pentru a acoperi domeniul liniei de produse,
permit construirea produselor ct mai repede posibil,
nu impun costuri sau riscuri inacceptabile la producerea nici unui membru al

familiei.
Slide 43
Evaluarea arhitecturii unei linii de produse

Momente n care se realizeaz:
Dup crearea arhitecturii pentru ntreaga familie de produse.
La crearea primului produs instan utiliznd arhitectura.
Dup revizuiri majore ale arhitecturii liniei de produse.
Cnd cerine de pia, domeniul sau stakeholder-ii se modific semnificativ.
Cnd este propus un nou produs ce pare a fi n afara domeniului liniei de

produse DUKLWHFWXUDOLQLHLGHSURGXVHWUHEXLHHYDOXDWSHQWUXDVHYHGHa
dac este suficient.
Cristina Mndru
Slide 44
PLAN CURS

Variabilitate

Cristina Mndru
Slide 45

Firm
Majoritatea firmelor construiesc produse izolate.
Proces
Un proces de dezvoltare existent trebuie modificat radical pentru a suporta linii

de produse.
E posibil ca o firm matur s fi investit deja mult n mbuntirea unui proces
de dezvoltare existent.
Afacere
Este necesar un caz business valid pentru a se justifica costul unei linii de
produse.
Poate fi dificil de cuantificat economiile i costurile de amortizare.
Tehnologie
Angajare ferm n crearea i ntreinerea arhitecturii software.
Cost
Costurile iniiale de creare a unei linii de produse sunt mari.

Cristina Mndru
Slide 46

Resurs
Caracteristici specifice
Arhitectur
Trebuie s suporte variaia inerent liniei de

produse.
Componente software
Trebuie proiectate pentru a fi generale, dar fr

a se pierde din performan; trebuie s conin
pri variabile.
Modelarea i analiza
performanei
Reutilizarea analizei ar putea impune

constrngeri alocrii pe procesoare.
Planuri de test, cazuri de

testare, date de test, planuri
proiect
Trebuie s ia n considerare prile variabile i

instanele multiple ale liniei de produse: fiecare
plan va fi dependent de gradul de reutilizare.
Instrumente, procese,
personal, competene,
instruire
Trebuie s fie mai robuste; trebuie s implice

instruire i expertiz centrate pe resursele i
procedurile asociate cu linia de produse.
Cristina Mndru
Slide 47
Strategii de adoptare
Adoptarea unei linii de produse -SUREOHPGHWLSinserie de tehnologie.
Abordri:
Descendent XQPDQDJHUGHFUHWHD]FILUPDYDXWLOL]DRDERUGDUHGHWLSOLQie de
produse.
Problem modificarea comportamentului dezvoltatorilor.
Ascendent proiectanii descoper valoarea i oportunitatea exploatrii liniilor de

produse.
Problem managerii sunt deseori refractari n a cheltui bani pe ceva ce nu se

transform n funcionalitate imediat.
Adoptarea este favorizat de
Avocat care nelege perfect liniile de produse i impactul acestora asupra companiei.
Arhitect talentat care nelege liniile de produse.
Rbdarea i suportul managerilor.
Consideraii la adoptare
Istoria companiei, cultura companiei, starea curent i starea dorit.

Cristina Mndru
Slide 48
Eecuri
Factori de eec:
Lipsa unei persoane care nelege liniile de produse i care este ntr-o poziie cu
autoritate i vizibilitate.
Lipsa experienei arhitecturale n proiectarea unei arhitecturi suport pentru o linie de
produse.
Lipsa unui suport susinut i ferm din partea managerilor,OLQLDGHSURGXVHILLQG
abandonat la primul semn de dificultate.
Reticena managerilor intermediari de a renuna la controlul autocratic asupra proiectelor.
Eec n a identifica un caz business i economic clar pentru adoptarea abordrii bazat
pe linii de produse.
Inabilitatea de a echilibra finanarea liniei i a produselor n mod corespunztor.
Probleme de securitate sau de confidenialitate ntre produsele familiei de produse.
Eec n antrenarea adecvat a personalului pentru a lucra n cadrul unei abordri bazat
pe linii de produse.
Cristina Mndru
Slide 49
Linii de produse DQDOL]HFRQRPLF

Dezvoltare produs individual
Efortul
de dezvoltare
Cadre pentru linii de produse

(bunuri ale companiei)
COTS
(sistem de operare, instrumente, compilator, ...)
Cost
cumulativ
Fr arhitectur
pentru linie de produse
Cu arhitectur pentru linie de produse
Numrul de produse construite

Cristina Mndru
Slide 50
Linii de produse
CONCLUZII
Linii de produse software SDUDGLJPGHGH]YROWDUHGHVRIWZDUHbazat

pe arhitectur.
Abordarea bazat pe linii de produse devine din ce n ce mai popular pe
msur ce companiile realizeaz avantaje remarcabile de cost, timp i
calitate prin utilizarea acesteia.
Adoptarea unei linii de produse nu este simpl i poate fi ameninat de
mai multe probleme; adoptarea trebuie considerat cu atenie i
implementarea sa trebuie atent planificat.
Cristina Mndru
Slide 51
Linii de produse
Bibliografie
Northrop, L. & Clements, P. A Framework for Software Product Line Practice, Version 5.0.
<http://www.sei.cmu.edu/productlines/framework.html>.
Brownsword, Lisa & Clements, Paul. A Case Study in Successful Product Line Development,
CMU/SEI-96-TR-016.
Clements, Paul C. & Northrop, Linda M. Salion, Inc.: A Software Product Line Case Study, CMU/SEI2002-TR-038.
Clements, Paul; Cohen, Sholom; Donohoe, Patrick; Northrop, Linda. Control Channel Toolkit: A
Software Product Line Case Study, CMU/SEI-2001-TR-030.
Bergey, John K. & Goethert, Wolfhart B. Developing a Product Line Acquisition Strategy for a DoD
Organization: A Case Study, CMU/SEI-2001-TN-021.
Cohen, Sholom. Case Study: Building and Communicating a Business Case for a DoD Product Line,
CMU/SEI-2001-TN-020.
O'Brien, Liam. Architecture Reconstruction to Support a Product Line Effort: Case Study, CMU/SEI2001-TN-015.
Cristina Mndru
Slide 52
PLAN CURS

Variabilitate

Cristina Mndru
Slide 53
Stiluri arhitecturale specializate
Stiluri arhitecturale
Generice
Specifice (specializate pe domenii)
Stilul arhitectual este

specializat pentru o
anumit familie de produse.
Specializarea suport analize, reutilizare cod, instrumente.

Stiluri
generice
Specializri de
stiluri generice
Flux date
Call-Return
...
Pipes & Filters
Multitier
...
Standarde
Standarde
generice
de domeniu
pentru integrare pentru integrare
de componente de componente
CORBA
COM
JavaBeans
...
EJB
HLA
...
Linii de produse
Tektronix Oscilloscopes
Xerox Network Scanning
Arch
...
Specificitate
Cristina Mndru
Slide 54
Specializare stiluri
Relaie ntre stiluri
Specializarea constrngeri suplimentare, specificitate de domeniu.
Exemplu:
Data Flow
Styles
Batch
Sequential
Pipe and Filter
Control Systems
Unix PF
Cristina Mndru
Slide 55
Studiu de caz
Linia de produse: osciloscoape Tektronix
Contextul de apariie:
Creterea complexitii instrumentelor de msur
Creterea rolului software-lui n produse ce erau preponderent hardware.
Ateptri crescute ale utilizatorilor.
Culturi de dezvoltare separate
Produse similare dezvoltate de divizii diferite
Slab partajare
Metode de construire de la zero
Hardware nou sau UI nou software nou.
Produse inflexibile i fragile
Erori din ce n ce mai serioase datorate funcionrii n regim de task-uri

concurente.
Timp de lansare pe pia excesiv (4-5 ani)

Cristina Mndru
Slide 56
Studiu de caz
Cristina Mndru
Slide 57
Studiu de caz
PROVOCAREA
Posibiliti de reutilizare ntre diviziile de producie.
Construirea sistemelor de instrumentaie din generaia viitoare.
Suport pentru un rspuns interactiv mai bun.
Platforme hardware multiple pentru aceeai interfa utilizator.
Interfee utilizator multiple pentru aceeai platform (piee verticale).
Reducerea timpului de lansare pe pia.
Cristina Mndru
Slide 58
Studiu de caz
semnale
forme de und
Imagini ale
formelor de und
i valori msurate
Osciloscop
Cristina Mndru
Slide 59
Studiu de caz
Soluie: Varianta 1 descompunere OO.
forme de und
forme de und
max-min
forme de und
x-y
waveform
w: time-> voltage
max: -> voltage
min: -> voltage
invert: ...
add: ...
Cristina Mndru
forme de und
cumulate
Rezultat: Sute de clase, structur slab,

nu se identific un ablon general.
Slide 60
Studiu de caz
Soluie: Varianta 2 DUKLWHFWXUn straturi.
Hardware
Digitizare
Vizualizare
Interfa utilizator
Rezultat: Limitele de abstractizare nu sunt realiste.
Cristina Mndru
Slide 61
Studiu de caz
Soluie: Varianta 3 DUKLWHFWXUSLSH-and-filter.
Semnal
Cuplare
Achiziie
To-XY
Forme de und
Impulsuri
Subsistem de declanare
Clip
Grafic
Msurare
Valoare msurat
Rezultat: Un model mai bun, dar nu este clar cum se

modeleaz intrrile de la utilizator.
Cristina Mndru
Slide 62
Studiu de caz
Soluie: Varianta 4 DUKLWHFWXUSLSH-and-filter cu filtre
parametrizate.
Cuplare
Cuplare
Semnal
Fel, rat
Transform
Dimensiune
Achiziie
To-XY
Clip
Forme de und
Grafic
Impulsuri
Sistem de declanare
Msurare
Valori msurate
Rezultat: Model elegant, dar relativ dificil de neles

de ctre implementatatori.
Cristina Mndru
Slide 63
Studiu de caz
Soluie: Varianta 5 DUKLWHFWXUSLSH-and-filter cu filtre
parametrizate i conducte colorate.
Cuplare
Cuplare
Semnal
Fel, rat
Transform
Dimensiune
Achiziie
To-XY
Clip
Forme de und
Impulsuri
Sistem de declanare
Grafic
Msurare
Valori msurate
Rezultat: Model elegant i implementabil.

Cristina Mndru
Slide 64
Studiu de caz
REZULTATE
Stilul arhitectural a fost utilizat ca baz pentru urmtoarea generaie de

produse osciloscop.
S-a obinut un cadru(framework) reuit, n care timpul de lansare pe
pia a sczut dramatic pentru produsele familiei.
A fost mbuntit fiabilitatea produsului.
Interfaa utilizator a devenit extensibil.
A condus la cadre noi, dincolo de domeniul osciloscoapelor.
Un nou imbold pentru colaborri de cercetare i dezvoltare.
Cristina Mndru
Slide 65
Alte modele arhitecturale

Dezvoltarea ulterioar a liniei de produse a implicat i crearea altor cadre arhitecturale
pentru gestionarea altor aspecte ale sistemelor de instrumentare i a altor pri
ale software-lui.
Framework PF (pipe-and-filter) extins:
Date partajate
Filtre trigger-ate
Rate variabile
Utilizare flexibil a intrrilor
Arhitectura interfeei utilizator:
Flux de control de la panourile frontale ctre interior
Ierarhii de menu-uri
Cristina Mndru
Slide 66
Mecanisme utile
Utilizarea prototiprii
Concurent cu proiectarea
Concentrat pe traducerea n concepte OO i performan
Mediu de dezvoltare (pentru ingineri)
Aplicabilitate, odat ce stilul arhitectural a fost definit
Revizuiri frecvente ale design-lui
Conectarea design-lui la realitate
Competene i motivare
Experi de domeniu i dezvoltatori de sistem
Expertiz n abstractizare i modele formale
Dorina de a abandona modele vechi de proiectare
Dorina de a rejecta arhitecturi necorespunztoare
Instrumente
Nu sunt necesare n perioada de conceptualizare
Eseniale pe parcursul dezvoltrii
Management
Iniial -VODVHOLEHUWDWH
Ulterior -VDMXWHODLPSXQHUHDVWDQGDUGHORU
Cristina Mndru
Slide 67
Concluzii
Proiectarea arhitecturii liniilor de produse implic iteraii.
Proiectarea arhitecturii liniilor de produse implic interaciune.
Problematica i implementarea cerinelor extra-funcionale

afecteaz alegerile arhitecturale.
Avantajele oferite de liniile de produse:
Reducere semnificativ a timpului de lansare pe pia.
Cretere semnificativ a calitii.
Cristina Mndru
Slide 68
PLAN CURS

Variabilitate

Cristina Mndru
Slide 69
n general este dificil de dezvoltat aplicaii din componente realizate de furnizori

diferii.
Conformitatea signaturii nu este suficient; sunt, de asemenea, relevante:
Ordinea de invocare
Ipoteze referitoare la localizarea controlului
Reprezentri ale datelor
Condiii de sincronizare
Cutare / descoperire / numire
Gestionarea defectelor
Modalitate de ameliorare : agrearea unor standarde de interoperabilitate,

numite standarde pentru integrare de componente.
Cristina Mndru
Slide 70

Exemplu: NIST ECMA model de referin pentru CASE
Memorare i
management date
Management
grupuri de entiti
Definiii i execuie
modele de procese
Dezvoltarea interfeei
utilizator
Cristina Mndru
Comunicare instrument-instrument i instrument-context

Slide 71

Exemplu: Middleware
Scris ntr-un limbaj neutru
pentru definire de interfee (IDL)
Interfaa
server-lui
Implementarea server-lui
(ntr-un limbaj de programare)
Implementarea clientului
(ntr-un limbaj de programare)
Compilatorul
IDL
Procesul
Client
Client-side
Server-side
Glue Scrise ntr-un limbaj de programare, Glue
Procesul
Server
dar independent de clieni
Middleware
Middleware
Un protocol peste TCP/IP
Cristina Mndru
Slide 72
Definiie
Standard arhitectural ce permite compunerea flexibil de componente
realizate de teri.
Definete:
1.
2.
3.
Structura general a aplicaiei n termenii tipurilor majore ale

componentelor constituente.
Set de interfeeVWDQGDUGFHGHVFULXFDSDELOLWile cerute componentelor.
Infrastructur reutilizabil ce sprijin integrarea componentelor prin
servicii partajate i canale de comunicare.
Cristina Mndru
Slide 73
Coninut
Reguli referitoare la interfeele componentelor
Structur, coninut, capabiliti necesare
Reguli i infrastructur pentru conectori
Definirea modurilor permise de interaciune ntre componente
Infrastructura suport pentru interoperabilitate

(n general) API la servicii de comunicare low-level
Convenii de numire i descoperire
De obicei, folosind un serviciu specializat de tip registry.
Baz de elemente reutilizabile
Blocuri fundamentale pentru construire de componente.
Instrumente pentru generare sistem.
Cristina Mndru
Slide 74
Politici
Standarde de facto
Impuse de furnizor (ex. IBM, Microsoft, Oracle)

Exemple: COM, .NET, JEE
Standarde definite n colaborare (de ctre un segment al industriei sau de

ctre organizaii speciale standards body .)
Proiectate n mod tipic de o comisie
Deseori apar ca reacie la cele de facto

Exemple: NIST/ECMA model pentru instrumente CASE, standarde OMG (DCE, UML,
...); HLA
Cristina Mndru
Slide 75
Observaii generale referitoare la standardele pentru

integrare de componente
ConectoriiVXQW, de obicei,SDUWHDFHDPDLLPSRUWDQW.
nelegerea acestui lucru este critic pentru succes.
Un API este fundamental, dar nu suficient.
Trebuie nelese, de asemenea, temporizrile, protocoalele, etc.
Forma de baz a interaciunii este doar o mic parte a arhitecturii.
Se adaug: managementul prilor, tratarea erorilor, pause-resume, negocieri

referitoare la date partajate, caracteristici pentru creterea performanei.
Testul de conformanHVWHRSUREOHPVHULRDV.
Pentru furnizorii de componente i furnizorii de infrastructur.
Cristina Mndru
Slide 76
CONCLUZII
Arhitecturile pentru liniile de produse i arhitecturile standardelor pentru
integrare de componente ofer avantaje pltite cu scderea gradului de
generalitate.
Deseori acestea sunt specializri sau combinaii ale stilurilor pure.

Dac sunt proiectate corect, au un impact mare asupra dezvoltrii de
produse software i asupra industriei n general.
Realizarea i utilizarea lor corect sunt dificile
Procesul trebuie s fie iterativ, experimental, colectiv.
Trebuie oferit mai mult dect un API.
Cristina Mndru
Slide 77
Studiu suplimentar
Din seciunea Documentaii studiai:
spl-essentials.pdf
Variability_in_spl_2005_05tr012.pdf
SPLEng_Diagram.pdf
Cristina Mndru
Slide 78

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

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

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

Transféré par

Droits d'auteur :

Formats disponibles

Site curs:

Arhitecturi pentru sisteme software

Arhitecturi pentru sisteme software

Arhitecturi software - exemple

Arhitecturi pentru sisteme software

Arhitecturi software - exemple

Arhitecturi pentru sisteme software

Arhitecturi software - exemple

Arhitecturi pentru sisteme software

Arhitecturi software - exemple

Arhitecturi pentru sisteme software

Arhitecturi software - exemple

Arhitecturi pentru sisteme software

Arhitecturi software - exemple

Arhitecturi pentru sisteme software

Arhitecturi software - exemple

Arhitecturi pentru sisteme software

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

O soluie : Dezvoltarea ARHITECTURAL a sistemelor software i

Arhitecturi pentru sisteme software

Dezvoltarea arhitectural a sistemelor software

Compunerea sistemelor din pri componente.

Asigurarea conformitii sistemului cu arhitectura i cu

Utilizare arhitecturi standard pentru integrare.

Reducere costuri utiliznd linii de produse.

Arhitecturi pentru sisteme software

Dezvoltarea arhitectural a sistemelor software

Compunerea sistemelor din pri componente.

Asigurarea conformitii sistemului cu arhitectura i cu

Utilizare arhitecturi standard pentru integrare.

Reducere costuri utiliznd linii de produse.

Arhitecturi pentru sisteme software

Definiia i rolul arhitecturii software

Arhitectura software n context

Impactul arhitecturii software

Relaiile de influen ale arhitecturii software

Rolul i calitile arhitectului software

Arhitecturi pentru sisteme software

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

Recunoaterea principalelor stiluri i abloane arhitecturale.

Descrierea cerinelor astfel nct arhitectura s poat fi evaluat.

nelegerea principiilor unei bune documentaii arhitecturale.

nelegerea modului de incorporare a COTS i middleware n

Generarea de alternative arhitecturale pentru o problem i

Arhitecturi pentru sisteme software

Proiectarea i construirea unui sistem de dimensiuni medii care

nelegerea modului n care notaiile formale pot fi utilizate

Evaluarea adecvrii unei arhitecturi date n ndeplinirea unui

Cunoaterea tendinelor de viitor n domeniul arhitecturilor

Arhitecturi pentru sisteme software

Definiia i rolul arhitecturii software

Arhitectura software n context

Impactul arhitecturii software

Relaiile de influen ale arhitecturii software

Rolul i calitile arhitectului software

Arhitecturi pentru sisteme software

Arhitectur software - Definiie

Arhitectura software a unui sistem de calcul este setul structurilor

Arhitecturi pentru sisteme software

Elemente ale modelului analiz

Arhitecturi pentru sisteme software

Locul i rolul arhitecturii software

Arhitecturi pentru sisteme software