Ingineria programării

Curs, anul III Calculatoare

Proiectarea arhitecturală a
sistemelor software.
Șabloane arhitecturale
Sumar
Arhitectura software. Continutul, stabilitatea si
modalitatile dezvoltarii modelului arhitectural
Proiectarea arhitecturala (dezvoltarea modelului
arhitectural). Descrieri arhitecturale in UML
Arhitecturi distribuite si multiprocesor. Concepte
arhitecturale
Șabloane arhitecturale și modele de control
Studiu de caz: proiectarea arhitecturala a unui
sistem de monitorizare meteo
Concluzii
Definiţii explicite
Proiectarea arhitecturală: știința de a construi un sistem
cu rigoare și armonie. Arhitectura software – definită de
structura/ structurile unui sistem, conține elemente
software, proprietăți vizibile extern ale acelor elemente
dar și relațiile între acestea*
 Referă structura de ansamblu a sistemului software
(intensiv - SSI) și modul in care aceasta structură
furnizează sistemului integritate semantică
Elemente şi proprietăţi vizibile:
 Se includ proprietăţile vizibile din exterior: servicii
furnizate, caracteristici de performanță, utilizarea
resurselor partajate de către mai multe elemente, etc.
 Se exclud acele proprietăţi ce nu afectează utilizarea
elementelor sau interacţiunile între elemente
Descrierea arhitecturală a SSI
Arhitectura este rezultatul unui proces de proiectare
arhitecturală, ce constă în:
 Descompunerea sistemului software în subsisteme
 Determinarea interfețelor subsistemelor
 Decizii privind modul de interacțiune între subsisteme
Documentația ce rezultă în urma procesului de proiectare
arhitecturală este înglobată în modelul arhitectural
Arhitectura este nucleul proiectului software; fiecare
inginer software trebuie să o înțeleagă
 O decizie nepotrivită luată în faza proiectării arhitecturii
software poate avea implicații negative asupra eficienței,
reutilizabilității și mentenabilității sistemului
Arhitectura - un model reutilizabil
Arhitectura este un model intermediar, un punct
de start sau plan pentru implementarea unui
sistem  project blueprint
Este important ca arhitectura să fie reutilizabilă
 ideea de software product line
 O arhitectură reutilizabilă și standardizată permite
folosirea de componente dezvoltate independent sau
de către externi
Pregătirea şi experienţa proiectanţilor
 Repetă reţetele de succes, evită repetarea greşelilor
anterioare
Continutul modelului arhitectural
Arhitectura sistem se exprimă prin câteva vederi
 Descompunerea logică in subsisteme cu interfetele lor
 Dinamica interactiunilor la executie intre subsisteme și
componente
 Datele partajate intre subsisteme
 Componentele și calculatoarele pe care componentele
sunt desfașurate la execuție
Observatii:
 O descriere a arhitecturii unui sistem arată similar unei descrieri
complete de sistem (poate include orice tip de model) dar conține
numai modelele si vederile sistem relevante dpdv arhitectural
 Un model arhitectural descrie atat aspecte structurale cat si
aspecte comportamentale ale sistemului
Vederi structurale
Arhitectura se constituie din vederi structurale
multiple, de exemplu:
 Una ce capturează relaţiile dintre modulele în care
este împărţit proiectul în faza de dezvoltare.
 O alta ce capturează relaţiile dintre elementele care
apar în timpul execuţiei programului
Partea observabilă extern a comportamentului
elementelor face parte tot din arhitectură
Termenii pot avea diferite semnificaţii:
 Elemente: obiecte, clase, funcţii, procese, programe,
biblioteci, etc.
 Interacţiuni între elemente: subdivizare, sincronizare,
apel de funcţie
Rolul arhitecturii in comunicare
Fiecare stakeholder este interesat de anumite
caracteristici ale sistemului
Rolul arhitectului: găsirea strategiilor de a
echilibra caracteristici diferite și/sau contradictorii
Rolul arhitecturii: un “limbaj” comun în care se
exprima, se negociază şi se rezolva aceste lucruri
 Arhitectura trebuie sa fie suficient de abstractă ca să
poată descrie la un nivel general inteligibil un sistem
complex
 Arhitectura trebuie sa poată fi analizată din punct de
vedere al principalelor caracteristici ale sistemului
Rolul arhitecturii in asigurarea
caracteristicilor de sistem
Performanţă : se recomanda folosirea componentelor
cu granularitate larga şi nu a celor cu granularitate fina
 O arhitectură judicioasă permite localizarea
operaţiilor critice şi minimizarea comunicaţiilor
Securitate : e utila folosirea unei arhitecturi în straturi
cu păstrarea deciziilor critice în straturile interioare
Siguranţă : este legată de localizarea caracteristicilor
safety-critical într-un număr mic de sub-sisteme
Disponibilitate : se asigură 1/ prin includerea unor
componente redundante şi /2 prin asigurarea unor
mecanisme de asigurare a toleranței la defecte
Mentenabilitate : impune folosirea componentelor
fine-grain, înlocuibile
Conflicte arhitecturale
Utilizarea componentelor cu granularitate larga
îmbunătăţeşte performanţele dar reduce
mentenabilitatea
Introducerea datelor redundante îmbunătăţeşte
disponibilitatea dar face asigurarea securităţii
mult mai dificila
Localizarea facilitaţilor legate de siguranţă are ca
efect, de obicei, o creştere a comunicaţiilor deci
și o degradare a performanţelor sistem
Stabilitatea arhitecturii software
Pentru asigurarea fiabilitatii si mentenabilitatii sistemului
software, modelul arhitectural trebuie sa fie stabil
O arhitectura software e stabila daca permite adaugarea
de noi servicii si facilitati la sistem cu modificari minime
ale arhitecturii
De exemplu, in UP (the Unified Process), la sfarsitul fazei
de elaborare arhitectura software ar trebui sa fie stabila
 Succesul unui proiect UP depinde de capacitatea unei mici
echipe de arhitecti si dezvoltatori (de valoare profesionala
ridicata) de a face o arhitectura stabila cu resurse limitate
 Conform ref.cit., este posibila dezvoltarea unei arhitecturi stabile
cu doar aprox. 30% din resursele alocate proiectului
Proiectarea arhitecturală
Asigură legătura între procesele de specificare şi
celelalte procese de proiectare (de detaliu)
 În cadrul multor modele de procese software are loc
în paralel cu unele activităţi de specificare
 Implică identificarea componentelor majore de sistem
şi a comunicaţiei între acestea
Sistemele mari sunt intotdeauna descompuse in
sub-sisteme ce asigura un set legat de servicii:
proiectarea arhitecturală este procesul iniţial de
identificare a acestor servicii și stabilire a unui
cadru de control al subsistemelor și comunicare
Rolul proceselor de proiectare
arhitecturală (design)
Contribuie la găsirea soluţiei de compromis între
cerinţe (contradictorii) ale diferitelor categorii de
stakeholders şi la stabilirea calităţilor sistemului
Reprezintă un mijloc de comunicare eficient
între stakeholders
Fac primul pas către realizarea sistemului, în
direcţia asigurării calităţilor dorite ale acestuia
Realizează primele artefacte care permit analiza
viitorului sistem în vederea stabilirii calităţilor lui
Dezvoltarea modelului arhitectural
-pași inițiali
Ca prim pas, se construieste o arhitectura prototip (de
obicei, inainte de a lua in considerare orice detalii legate
de cazurile de utilizare).
In acest stadiu se utilizeaza:
 Cunostinte despre domeniul de aplicatie,

 Sabloane arhitecturale generale (urmeaza a fi discutate)

 Sugestie: mai multe echipe diferite pot sa lucreze in mod

independent la conceperea de schite ale arhitecturii, iar

apoi cele mai bune idei pot sa fie combinate
Apoi, se alege si se implementeaza un set de cazuri de
utilizare, construindu-se o arhitectura imbunatatita, etc.
Dezvoltarea iterativă a modelului
arhitectural
În cadrul unui proces iterativ, la fiecare iteratie:
 Se elaboreaza elementele arhitecturale specifice aplicatiei,
care pot include orice aspecte ale sistemului considerate a
fi relevante d.p.d.v. arhitectural
 Considerând fiecare caz de utilizare în parte, se ajustează
arhitectura pentru a permite implementarea sa
 Se maturizează arhitectura
Ar trebui inceput cu cazurile de utilizare relevante din
punct de vedere arhitectural - cele care:
 Ajuta la diminuarea celor mai semnificative riscuri tehnice
sau manageriale
 Sunt cele mai importante pentru utilizatorii sistemului
 Ajuta la implementarea oricarei functionalitati semnificative
Structurarea sistemelor
Arhitectura ce urmează un proces de design este
in mod normal o diagramă bloc ce prezintă un
plan general al structurii sistemului
Ea arata decompozitia unui sistem in subsisteme
care interactioneaza
Modelele cu un grad mai mare de specificitate
pot arata si cum aceste sisteme partajeaza date,
cum sunt distribuite si cum trebuie dezvoltate
interfetele intre ele
Decompozitia modulară
Reprezinta un nivel final de structurare in care
subsistemele sunt descompuse in module
Avem 2 modele principale de decompozitie:
 Obiectual, in care sistemul este descompus in final
intr-un set de obiecte ce interactioneaza
 Data-flow, in care sistemul este descompus in final in
module functionale ce transforma intrarile in iesiri
(asimilat in mare masura cu modelul pipeline)
Ambele modele permit distributia modulelor si
concurența, dar se recomandă ca aceste decizii
să fie amânate (uneori până după implementare)
Descrieri arhitecturale in UML
Toate diagramele UML pot fi utile in
descrierea diferitelor aspecte ale modelului
arhitectural.
Urmatoarele diagrame UML sunt in particular
importante pentru modelarea arhitecturii:
 Diagrame de pachete

 Diagrame de componente

 Diagrame de desfasurare
Diagrame de pachete
Pachet : mecanism general de
organizare a elementelor de
model in grupuri
• Nota: un simbol grafic
ce permite exprimarea
de constrangeri sau de
comentarii atasate unui
element (de model) sau
unei colectii de elemente
Diagrame de componente
O componenta este o parte fizica a
unui sistem, care poate fi inlocuita
cu o componenta similara si care
furnizeaza realizarea (si se
conformeaza) unui set de interfete
• O componenta furnizeaza
una sau mai multe
interfete ce pot fi utilizate
de alte componente
• Pentru vizualizarea unei
componente care utilizeaza
o interfata furnizata de o
alta componenta se
utilizeaza un semicerc (la
capatul unei linii)
Diagrame de desfasurare

Fiecare nod dintr-o Un nod este un element fizic

diagrama de desfasuare care exista la executie si
poate gazdui una sau reprezinta o resursa de calcul
mai multe componente (furnizand cel putin capacitate
software de memorare si, adesea, de
procesare)
Arhitecturi distribuite
Virtual, toate sistemele software complexe sunt
caracterizate de arhitecturi distribuite
Prelucrarea informaţiei poate fi astfel distribuita
pe mai multe sisteme de calcul, legate în reţea
(loosely coupled), cu putere de calcul disponibila
Excepţiile, ce nu necesita arhitecturi distribuite:
 Sisteme desktop – proiectate pentru a rula pe un
calculator sau statie de lucru personal(ă)
 Sisteme înglobate (embedded) – ce rulează pe un
singur procesor sau un grup de procesoare integrate
Caracteristici ale sistemelor
distribuite
Partajarea resurselor hardware/ software
Caracterul deschis
 Permite utilizarea de echipament si/ sau software
provenit din surse diferite
Prelucrarea concurentă
 Scopul principal este creşterea performantei
Scalabilitatea
 Este crescuta prin adăugarea de noi resurse
Toleranța la defecte
 Abilitatea de a continua prelucrarea după apariţia unei
erori
Dezavantaje ale sistemelor
distribuite
Complexitate
 Tipic, sistemele distribuite sunt mai complexe decât
cele centralizate
Securitate
 Mai susceptibile la atacuri externe
Management dificil
 Implica un efort mult mai mare
Lipsa de predictibilitate
 Răspunsul şi performantele sistem sunt în general
mult mai dependente de organizarea sistemului şi
încărcarea reţelei
Arhitecturi multiprocesor
Sunt arhitecturi distribuite ce includ si mod(el)ul
de distributie al proceselor multiple ce pot să se
execute (in gen.) pe procesoare fizice distincte
Pot sta la baza modelului arhitectural al multor
sisteme software complexe sau de timp real
Distribuţia proceselor pe procesoare poate fi:
 statică (pre-stabilită)
 cvasi-statică (configurabilă iniţial)
 dinamică (stabilită în timpul execuţiei, sub controlul
unui dispatcher)
Exemplu: Sistem multiprocesor de
control al traficului

Sensor Traffic flow Traffic light control

processor processor processor

Sensor Light
control Display control
process process process

Traffic lights
Traffic flowsensorsand
cameras Operator consoles
Concepte arhitecturale

Reference Model
Reference
Architecture
Design Architectural Software
Pattern Pattern Architecture

Architectural
Style Framework
Modele de referinţă
(Reference Model)
Un model de referinţă este o diviziune a funcţionalităţii
împreună cu fluxul de date între părţi
Rezulta printr-o decompoziţie standard a unei
probleme cunoscute în părţi care împreună, în
manieră co-operativă, rezolvă problema
Modelele de referinţă rezultă din experienţa îndelungată
într-un anumit domeniu de aplicaţie
Sunt caracteristice domeniilor mature
Exemple:
 Compilatoare: analiza lexicala, analiza sintactica,

analiza semantica, optimizare sau generare de cod

 Reţele: Modelul de referinţa OSI
Arhitecturi de referinţă
(Reference Architectures)
O arhitectură de referinţă este un model de
referinţă mapat pe elementele software,
care implementează împreuna funcţionalitatea
definita în modelul de referinţa, plus fluxurile de
date între aceste elemente
Modelul de referinţă defineşte o descompunere
a funcţionalităţilor
Arhitectura de referinţa defineşte modul de
mapare a funcţionalităţilor pe definiţii de
subsisteme/ componente
 Maparea poate fi 1 la 1 dar nu cu necesitate aceasta
 Exemplu: CORBA (Common Object Request Broker
Architecture)
Cadre
(Frameworks)
Sunt sisteme software parţial completate cu intenţia de a
fi instanţiate, ce definesc o arhitectura pentru o familie
de sisteme şi asigura blocurile de baza pentru crearea lor
Definesc şi locurile unde se pot face inserţii/ adaptări la
instanţiere: hot spots / frozen spots
Instanţierea se face prin compunerea şi subclasarea
claselor furnizate de framework (vezi OCSF/ Java)
Diferenţa framework ↔ reference architecture: un cadru
este dat sub forma de cod
Diferenţa framework ↔ biblioteca la dezvoltarea unei
aplicaţii noi:
 Pentru biblioteca: se scrie corpul main şi se utilizează elemente
(funcţii, clase, etc.) din biblioteca
 Pentru framework: de obicei el furnizează un main body
predefinit, mai trebuie adăugate/concretizate unele elemente
(funcţii, clase) pe care acesta le utilizează (inversion of control)
Şablon arhitectural
(Architectural Pattern)
Un şablon (tipar) arhitectural exprima o schemă
de organizare structurală fundamentală
pentru un sistem software
El asigură un set de sisteme predefinite,
specifică responsabilităţile acestora şi include
reguli şi guideline-uri pentru organizarea
relaţiilor între acestea
Exemplu:
 MVC (Model-View-Controller)
Stil arhitectural
(Architectural Style)
Un stil arhitectural defineşte o familie de sisteme
software prin organizarea lor structurala
Exprimarea componentelor şi relaţiilor între ele
se face în funcţie de constrângerile aplicaţiei şi
regulile asociate de compoziţie şi design
Exemplu: Pipes-and-filters (ex. pipeline sort)
 Componente procesatoare de date, cu 1 sau mai
multe porturi de intrare şi 1 sau mai multe porturi de
ieşire, toate cu acelaşi tip: Filter
 Relaţiile dintre 2 componente: conectori binari uni-
direcţionali ce transmit fluxul de date de la un port de
ieşire filtru spre un port de intrare al altui filtru: Pipe
 Constrângeri/ reguli: Un filtru nu trebuie sa cunoască
identitatea filtrelor de la care primeşte sau către care
transmite date
Relaţia şablon arhitectural ↔
stil arhitectural
Unii autori [Bass] interpretează stilul arhitectural
ca şablon arhitectural
Un stil arhitectural poate fi descris sub forma
unui şablon arhitectural
Diferenţe:
 Stilurile se refera la aspectele macroscopice, legate de
structura globala a unei aplicaţii
 Tiparele pot acoperi o gama larga de aspecte, de la
arhitectura -> design -> limbaj
 Tiparele sunt mai concrete (mai orientate pe
probleme concrete)
 Stilurile nu sunt legate de probleme sau domenii de
aplicaţie concrete
Şablon de proiectare
(Design Pattern)
Un şablon (tipar) de proiectare asigura o schemă de
rafinare a subsistemelor unui sistem software, şi/
sau a relaţiilor între acestea
Descrie o structura a componentelor de comunicare,
comun-recurentă, ce rezolvă o problemă generală
de design într-un context particular
Şabloanele de proiectare sunt tipare la scară mai
mica decât cele arhitecturale
 Independente de un limbaj de programare
 (De obicei) independente de o paradigmă de programare
Aplicarea unor tipare din această categorie nu
afectează structura fundamentală a unui sistem
Șabloane arhitecturale
Notiunea de șablon este utilizata la diferite nivele de
abstractizare, inclusiv la nivelul arhitecturilor software
Șabloanele arhitecturale (numite si stiluri architecturale)
inlesnesc proiectarea de sisteme software alcatuite din
subsisteme si componente cat mai independente posibil
În general, un șablon este schița unei solutii reutilizabile
la o problema generala intalnita intr-un anumit context.
Șablonul, dupa nivelul de abstractizare, poate fi:
 Sablon arhitectural – exemple: Layers, Client-Server MVC

sau Pipe-and-Filter – toate reprezintă soluții standard

pentru diferite probleme arhitecturale
 Sablon de proiectare – exemple: Observer, Façade sau
Proxy – utilizate in modelarea si proiectarea software
 Sabloane arhitecturale distribuite
tipice
Client-server
 Caracterizate de servicii distribuite, asigurate de servere şi
apelabile de către clienţi
Obiecte distribuite
 Nu se face o distincţie între clienţi şi servere
 Orice obiect din sistem poate asigura şi utiliza servicii
Middleware
 Software ce administrează şi suporta componente diferite ale
unui sistem distribuit
 Uzual, este software general (“off-the-shelf”) mai degrabă decât
dedicat, scris special pentru un sistem
Multi-layer
etc.
Sablonul arhitectural Client-Server
Exista cel putin o componenta cu rol de server, care
asteapta si apoi trateaza (sau serveste) conexiunile
Exista cel putin o componenta cu rol de client, care
initiaza conexiuni cu scopul de a obtine anumite servicii
 O varianta importanta a arhitecturii (two-tier) descrisa mai sus
este reprezentata de modelul 3-tier, care include trei tipuri de
noduri: clienti, servere de aplicatie si servere (de baze) de date
 Un server de aplicatie se comporta ca si un client atunci cand
acceseaza un server de date (ex. Flight Reservation System)
 O alta extensie este data de sablonul Peer-to-Peer. Acesta
descrie o arhitectura de sistem distribuit compusa din diverse
componente software.
 Fiecare dintre aceste componente poate fi atat client cat si
server
 Oricare doua componente (eng. peers) pot stabili un canal de
comunicare
Exemplu: Arhitectura client-server a
unei biblioteci de filme si imagini

Client 1 Client 2 Client 3 Client 4

Wide-bandwidth network

Catalogue Video Picture Hypertext

server server server server

Catalogue Film clip Digitiz ed Hypertext

files photographs web
O arhitectura peer-to-peer (p2p)

Un server central poate fi utilizat pentru

stabilirea conexiunilor intre perechi (engl.
peers)
Caracteristici arhitecturale
client-server
Avantaje
 Distributia datelor este evidenta
 Efectiva in retele, poate folosi hardware ieftin
 Usor de adaptat noi servere, de upgradat cele
existente
Dezavantaje
 Subsistemele pot folosi diferite organizari pentru date,
ceea ce poate face schimbul de date ineficient
 Management redundant pentru fiecare server
 Nu se face inregistrarea centrala de nume si servicii –
serverele si serviciile disponibile pot fi dificil de gasit
Arhitecturi de obiecte distribuite
și middleware
Nu se face distincţie între clienţi şi servere
Fiecare entitate distribuita este proiectata ca un
obiect ce asigura şi primeşte servicii
Comunicarea între obiecte are loc prin folosirea
unui sistem middleware: “object request broker”
Proiectarea lor este mult mai complexa decat a
sistemelor client/server
Sunt deschise, scalabile, flexibile, reconfigurabile
dinamic cu obiecte ce migrează în reţea conform
necesităţilor de prelucrare
Exemplu
o1 o2 o3 o4

S (o1) S (o2) S (o3) S (o4)

Object request broker

o5 o6

S (o5) S (o6)
Sablonul arhitectural Broker
Faciliteaza distributia obiectelor unui sistem software
in mod transparent pe diferite noduri
 Utilizand arhitectura Broker, un obiect poate apela
metode ale unui alt obiect fara sa stie ca acesta din
urma este situat pe un alt calculator
 Aici poate fi util sablonul de proiectare Proxy
 O componenta Broker (ce trateaza toate invocarile
locale de obiecte) se poate atasa fiecarui calculator
care gazduieste obiecte distribuite
Un standard pentru acest tip de arhitectura este
CORBA (Common Object Request Broker Architecture)
Arhitecturi multistrat (model
masina abstracta)
Pot evidentia clar interfetele subsistemelor
Sistemul este organizat intr-un set de straturi
(sau masini abstracte), fiecare asigurand un set
de servicii
Suporta dezvoltarea incrementala a subsistemelor
din diferitele straturi
Atunci cand se schimba interfata unui strat,
numai stratul adiacent este afectat
Dezavantaj: structurarea sistemelor cu foarte
multe straturi este dificila
Version management system
Version management

Object management

Database system

Operating
system
Arhitectura 3-tier si multi-layer
Strat de prezentare
 Are ca rol prezentarea rezultatelor unor prelucrări şi
colectarea intrărilor utilizatorilor
Strat de procesare a aplicaţiilor
 Se ocupa de asigurarea funcţionalităţii specifice
aplicaţiilor (de ex. într-un sistem bancar a funcţiilor
de banking ca openAccount, closeAccount etc.)
Strat de management al datelor
 Se ocupa de managementul sistemelor de baze de
date ale aplicaţiilor
Straturi ale aplicaţiilor

Presentation layer

Application processing
layer

Data management
layer
Sablonul arhitectural Multi-Layer
Intr-un sistem organizat pe nivele (Multi-Layer), orice nivel utilizeaza
doar serviciile nivelelor inferioare – adesea numai serviciile nivelului
imediat inferior
Un nivel are o interfata bine definita (API) ce defineste servicile pe
care le furnizeaza) utilizata de nivelele (imediat) superioare.
 Un nivel superior vede un nivel inferior ca un set de servicii

 Nivelele inferioare nu cunosc detalii/ interfete ale niv. superioare

Un sistem complex poate fi construit prin suprapunerea de nivele cu

grade tot mai ridicate de abstractizare; de ex., intr-un program:
 Este important sa existe un nivel separat pentru interfata
utilizator (independenta acestui nivel permite aplicatiei sa
functioneze cu diferite interfete utilizator)
 Nivelele imediat inferioare interfetei utilizator furnizeaza functiile
aplicatie determinate de cazurile de utilizare
 Nivelele inferioare acestora furnizeaza servicii de acces la baze de
date, comunicare in retea, etc.
Exemple de sisteme Multi-Layer
Șablonul MVC (model-view-controller)
In acest șablon arhitectural:
 Funcționalitatea de bază (core) și datele aplicației sunt
abstractizate în model
 O vedere (view ) este responsabilă pentru prezentarea

(afișarea) de informații către un utilizator

 Un controler este responsabil pentru acceptul datelor

de intrare de la un utilizator, interpretarea lor pentru a

decide ce trebuie făcut și acțiunea în consecință (de
ex. actualizarea datelor sau invocarea unei funcții)
→Putem avea una sau mai multe vederi și unul sau mai
multe controlere care împreună alcătuiesc interfața
utilizator (uzual, GUI)
MVC
Sablonul Transaction Processing
In acest sablon arhitectural:
 Un proces citeste o serie de intrari in secventa.
 Fiecare intrare descrie o tranzactie – comanda care
in mod tipic efectueaza anumite modificari asupra
datelor stocate de sistem
 Exista o componenta dispecer care decide actiunea
corespunzatoare fiecarei tranzactii
 Aceasta expediaza un mesaj spre una dintr-o serie de
componente ce intermediaza tranzactia (transaction
handler)
 In fiecare caz, este esential ca tranzactia sa fie
realizata complet sau deloc
Exemple
Sistem Broker

Arhitectura Transaction Processing ce

poate fi utilizata in cazul unui sistem
de rezervari pentru curse aeriene
Sablonul arhitectural Repository
Utilizeaza date partajate de toate subsistemele
Atunci cand subsistemele ce interactioneaza fac si
schimb de date, el poate avea loc in 2 moduri:
 Datele partajate pot fi stocate central intr-o baza de
date (“repository”) si pot fi accesate de toate subsist.
 Fiecare subsistem mentine propria baza de date si
poate trimite date explicit altor subsisteme
Cand trebuie partajate mari cantitati de date, cel
mai folosit este modelul de partajare “repository”
Analogie: Shared vs. Message passing, ca modele
de comunicatie in programarea paralela
Caracteristici ale modelului
Avantaje:
 Asigura un mod eficient de partajare a datelor
 Subsistemele nu trebuie sa se preocupe de modul de
producere a datelor
 Managementul centralizat (backup, securitate)
 Modelul de partajare este public  repository schema
Dezavantaje:
 Subsistemele trebuie sa faca un compromis asupra
unui model de date comun in repository
 Evolutia datelor este dificila, costisitoare
 Nu pot fi aplicate politici de management specifice
 Este dificil de distribuit in mod eficient
Exemplu
Acest model poate fi utilizat in proiectarea pachetelor CASE:

Design Code
editor generator

Design Project Program

translator repository editor

Design Report
analyzer generator
Sablonul arhitectural Pipe-and-
Filter
Un flux de date, intr-un format relativ simplu,
este transmis printr-o serie de procese:
 Fiecare proces transforma fluxul intr-un anumit mod
 Fluxul de date alimenteaza arhitectura in mod
continuuu
 (Conceptual) Procesele lucreaza in mod concurent
 Aceasta arhitectura este foarte flexibila:
 Aproape toate componentele ar putea fi eliminate
 Componentele pot fi inlocuite
 Se pot insera noi componente
 Anumite componente pot fi reordonate
Exemplu de arhitectura Pipe-
and-Filter

O arhitectura Pipe-and-Filter pentru procesare

sunet
Modele de control
Schimbul de date nu este suficient ca model pt.
interactiunea dinamica a subsistemelor
Fluxul de control intre subsisteme este distinct
fata de modelul de decompozitie a subsistemelor
Controlul centralizat
 Un subsistem detine resposabilitatea generala de
control (pornirea si oprirea altor subsisteme)
Controlul dirijat de evenimente
 Fiecare subsistem raspunde autonom evenimentelor
generate extern, din alte subsisteme sau din mediu
Modelul “call-return”
Centralizat, aplicabil sistemelor secventiale

Main
program

Routine 1 Routine 2 Routine 3

Routine 1.1 Routine 1.2 Routine 3.1 Routine 3.2

Control centralizat in timp real

Sensor Actuator
processes processes

System
contr oller

Computation User Fault

processes interface handler
Control dirijat de evenimente cu
broadcasting
Subsistemele anunta interes pentru unele even.
Cand acestea apar, primesc controlul
 Modul de control nu e inglobat in eveniment sau in
handlerul de mesaj, ci in handlerele de eveniment din
subsisteme
 Ex: Broadcasting selectiv
Sub-system Sub-system Sub-system Sub-system
1 2 3 4

Event and messa ge handler

Control dirijat de intreruperi
Folosit in sisteme in timp real; intreruperile sunt
detectate de un handler (subsistem specializat)
si trimise altui subsistem pentru tratare
Interrup ts

Interrup t
vecto r

Han dler Han dler Han dler Han dl er

1 2 3 4

Pro ces s Pro ces s Pro ces s Pro ces s

1 2 3 4
Studiu de caz: Sistem de monitorizare
meteo
Specificaţie iniţiala:
Necesitate: pentru a genera hărţi meteorologice în mod
regulat folosind date colectate de la staţii meteo la distanţă
şi de la alte surse (observatoare meteo, baloane şi sateliţi)
Staţiile meteo transmit datele lor unui calculator zonal ca
răspuns la o cerere de la acel calculator
Calculatoarele zonale validează datele colectate şi le pot
integra cu alte date din diferite surse
Datele integrate sunt arhivate; folosind date din această
arhivă şi o bază de date de hărţi digitizate se creează un
set de hărţi meteo locale
Hărţile pot fi tipărite sau afişate în diferite formate
Modelarea contextuală şi cea
comportamentală a sistemului
Au ca scop dezvoltarea unei înţelegeri interne şi
a relaţiilor dintre sistemul software ce trebuie
proiectat şi mediul exterior
Contextul sistemului
 Un model static ce descrie relaţia cu alte sisteme.
Se foloseşte un model de tip subsistem
Model de utilizare
 Un model dinamic ce descrie cum interacţionează
sistemul cu mediul
 Pentru a arăta interacţiunile se folosesc cazuri de
utilizare (use-cases)
Cazuri de utilizare/ modele de proiectare
Urmează identificarea
Star tup
obiectelor, claselor de
obiecte şi relaţiilor dintre
Shutdown aceste entităţi
Modelele statice descriu
Repor t structura statică a
sistemului în termeni de
clase de obiecte şi relaţii
Calibrate
Modelele dinamice
descriu interacţiunile
Test dinamice dintre obiecte
Tipuri de modele de proiectare
Se utilizează diferite tipuri de modele pentru
descrierea proiectării
Modele tip sub-sistem: arată grupările logice de
obiecte în sub-sisteme coerente
Modele de stare: arată cum obiectele individuale
îşi schimbă starea ca răspuns la evenimente
Modele de secvenţă: pentru a descrie secvenţa
interacţiunilor între obiecte
etc.
Punct de start: documentarea CU
Sistem Staţie meteo
Use-case Raport
Actori Sistemul meteo de colectare a datelor, Staţia meteo
Descriere Staţia meteo trimite sistemului meteo de colectare un sumar al
datelor meteo colectate de la instrumente în perioada de colectare.
Datele trimise sunt maximul, minimul şi media temperaturii solului
şi aerului, ale presiunii aerului, vitezei vântului, precipitaţiile totale
şi direcţia vântului.
Stimuli Sistemul meteo de colectare a datelor stabileşte o conexiune prin
modem cu staţia meteo şi cere transmiterea datelor.
Răspuns Datele sumarizate sunt trimise către sistemul meteo de colectare a
datelor
Comentarii Staţiile meteo sunt solicitate să trimită rapoarte de obicei odată pe
oră dar această frecvenţă poate să difere de la o staţie la alta şi
poate fi modificată pe viitor.
Proiectarea arhitecturală
Odată ce interacţiunile dintre sistem şi mediul lui au
fost înţelese, această informaţie este folosită pentru
proiectarea arhitecturii sistemului
O arhitectură pe straturi este potrivită atât pentru staţia
meteo, cât și pentru sistemul global de monitorizare
Pentru staţia meteo arhitectura multi-layer poate fi:
 Stratul de interfaţă pentru rezolvarea comunicaţiilor
 Stratul de colectare de date pentru lucrul cu
instrumentele meteo
 Stratul instrumentelor meteo pentru colectarea datelor
În mod normal numărul de entităţi care pot să apară
într-un model arhitectural e limitat (nu mai mult de 7)
Arhitectura unei staţii meteo
Weather station

Manages all
«subsystem» external
Inter face communications

«subsystem» Collects and

Data collection summarises
weather data

«subsystem» Package of
Instruments instruments for raw
data collections
Arhitectura sistemului global (multi-layer)

Stratul de afişare a datelor

Obiectele se ocupă cu pregătirea şi
«subsystem» prezentarea datelor într-o formă
Data display uşor de înţeles

Stratul de arhivare a datelor

«subsystem» Obiectele se ocupă cu stocarea
Data archiving datelor pentru viitoare prelucrări

Stratul de procesare a datelor

«subsystem» Obiectele se ocupă cu verificarea şi
Data processing Integrarea datelor colectate

Stratul de colectare a datelor

«subsystem» Obiectele se ocupă cu achiziţionarea
Data collection de la surse de la distanţă
Arhitectura sistem: interacţiunea între
subsisteme
«subsystem»
Data collection «subsystem»
Data display

Observer Satellite
User
User Map
inter
interface
face display
Comms

Weather Map
Map printer
station Balloon

«subsystem» «subsystem»
Data processing Data archiving

Data
Data
Data Data storage
storage
checking integ ration
Map store Data store
Concluzii
Arhitectura este nucleul proiectului software
Pentru ca un sistem software sa fie fiabil,
modelul arhitectural trebuie sa fie stabil
Proiectarea arhitecturală asigură legătura între
procesele de specificare şi proiectarea de detaliu
Virtual, toate sistemele software complexe sunt
caracterizate de arhitecturi distribuite
Sabloanele arhitecturale sunt solutii standard de
proiectare pentru sisteme software alcatuite din
subsisteme si componente independente