Curs 2

ARHITECTURA
SISTEMELOR
SOFTWARE
Dr. ing. Liviu PERNIU
Curs 2
PRINCIPII DE ARHITECTUR SOFTWARE
Documentul de arhitectur software

Actualizat pe tot parcursul ciclului de voia al produsului software
ncepe n faza de Iniiere
Se dezvolt n special n faza de Elaborare
Ofer o imagine de ansamblu ce ajut la nelegerea arhitecturii

Servete la mbuntirea comunicrii dintre arhitect i persoanele
implicate n proiect
Adun i explic toate deciziile importante luate la proiectare
Trebuie s fie ct mai concis posibil
Curs 2
Coninutul unui document de arhitectur

Introducere
Reprezentare arhitectural
Scopul i restriciile arhitecturii
Vederea de domeniu
Vederea Use-Case
Vederea cerinelor non-funcionale
Vederewa logic
Vederea de proces
Vederea de implementare
Vederea de introducere n mediul real de funcionare
Dimensiune i performan
Calitate
Curs 2
Documentul cu reguli de proiectare

Este creat i susinut de ctre arhitect
Ofer posibilitatea comunicrii cu dezvoltatorii
Proiectanii
Deintorii pachetelor
Dezvoltatorii de componente
Cei care se ocup de revizuire
Se adreseaz mediilor de dezvoltare i de execuie
Hardware i sistem de operare
Sistemelor de gestiune a bazelor de date
Mediilor de dezvoltare a interfeelor grafice utilizator
Limbajelor de programare i instrumentelor de dezvoltare
Utilizrii mecanismelor (modelul de programarel)
Curs 2
Arhitectul mai contribuie la

Stabilirea de reguli de testare
Testarea componentelor separat
Testarea legturilor
Testarea final
Testarea atributelor de calitate ale

sistemului
Performana
Latena
Cantitatea de date ce trebuie

prelucrat ntr-un anumit interval
de timp
Fiabilitatea
Dsiponibilitatea
Reguli de modificare
Modificri ale bazei de date
Modificri ale interfeei
Adugarea sau eliminarea de
componente
Asamblarea sau descompunerea de
componente
Modificri ale mediului de dezvoltare
Modificri ale arhitecturii,
Planul de management al configurrilor

software
Testarea elementelor sensibile ale

arhitecturii
Curs 2
Arhitectura de referin
Elemente cheie furnizate la sfritul fazei de Elaborare
O implementare parial a sistemului (prototipul arhitectural)
Proiectele i regulile de arhitectur care (mpreun) arat faptul c:
Sistemul va ndeplini cerinele funcionale cheie
Sistemul va avea atributele de calitate dorite (va ndeplini cerinele nonfuncionale)
Cantitatea de date prelucrat ntr-un anumit interval de timp, securitate, scalabilitate,
termenele stabilite etc.
Riscurile critice pot fi reduse sau eliminate
Curs 2
Prototipul arhitectural
Este o parte a arhitecturii de referin
Repprezint o implementare parial a sistemului
Este creat pentru a demonstra
Funciile sistemului
Proprietile sistemului (atributele de calitate)
Este creat pentru a reduce riscurile identificate

Este creat cu scopul de a deveni o parte a implementrii sistemului
Curs 2
Definiia componentelor software

O unitate de distribuire, asamblare, introducere n mediul real de
funcionare i de nlocuire
ndeplinete o funcionalitate non-trivial
Este definit prin serviciile pe care le ofer i serviciile pe care le cere
Serviciile arat comportamentul unei componente doar din punct de vedere
al ansamblului
O component are sens doar n contextul:

Unei arhitecturi
Unui model al componentelor i a unui cadru de elaborare
Nu este obligatoriu s fie o singur unitate de cod

Curs 2
Proveniena componentelor software

Arhitecturi modulare
Componente proiectate, elaborate i testate individual i integrate treptat
Componente reutilizabile
Ofer soluii comune
Pot fi mai mari dect coleciile de utilitare sau bibliotecile de clase
Creeaz baza reutilizrii
Elementele de infrastructur a componentelor

Se pune n discuie dac este mai eficient s se creeze sau s se
cumpere.
Curs 2
Aspecte de reutilizare a componentelor

Identificarea componentei corespunztoare
ncredere
Calitatea componentei
Viabilitatea productorului componentei
Potrivirea
Din punct de vedere funcional
Din punct de vedere tehnic
Implicaii arhitecturale
Adaptabilitate i evoluie
Curs 2
Aspecte de reutilizare a componentelor

Legal
Cultural
Compesaie
Cost
Costul componentei
Costul de ntreinere al componentei
Curs 2
Un ablon
Reprezint o soluie la o problem ntr-un anumit context
Codific anumite cunotine preluate din experiena obinut ntr-un
anumit domeniu
Reprezint elemente reutilizabile de proiectare
Simplific i grbete proiectarea
Reduce riscul
Faciliteaz comunicarea dintre proiectani
Curs 2
Tipuri de abloane
Sistemele bine structurate conin mai multe abloane la diferite nivele
Idiomuri sistem lingvistic cu trsturi proprii folosit de un anumit grup
La nivel de limbaj de programare
abloane pentru analiz i proiectare

La nivel de clas
abloane arhitecturale
La nivel de component i de subsistem
abloane la nivel de organizaie

La nivel de domeniu
Curs 2
Exemple de abloane de proiectare

abloane pentru creare
Abstractizare
Prototip
abloane structurale
Adaptor
Conexiune
Proxy
Design Patterns: Elements of Reusable Object-Oriented

Software: E. Gamma, E. Helm, R. Johnson, J. Vlissides,
Addison-Wesley, 1995
abloane comportamentale
Lanul de responsabiliti
Mediator
Vizitator
Obiect concurent
Curs 2
Aspectul unui ablon obinuit

Nume
Context
Problema
Aspectele ce trebuie luate n considerare
Elementele de for (cerine, restricii etc.) care genereaz problema
i influeneaz soluia
Soluia
Justificare
Contextul rezultat
Exemple
Curs 2
abloane de modelare a proiectului

Un ablon de proiectare este modelat sub forma unei colaborri
parametrizate
Aspect structural
Aspect comportamental
Parametrii ablonului se folosesc pentru adaptarea colaborrii la o

anumit utilizare
Parametrii
ablonului
Nume ablon
Colaborare
parametrizat
Aspect structural
Aspect
comportamental
Curs 2
Exemplu de ablon de modelare a proiectului

Parametrii
ablonului
Participant1
Participani
Param1
Param1
Param2
Nume ablon
Rol
Participant2
Param2
Colaborrile
abstracte
se
utilizeaz pentru a prezenta
patrticipanii i relaiile dintre
acetia n cadrul ablonului.
Curs 2
Exemplu: ablon de proiectare: ablon pentru Proxy

Nume: Proxy (cunoscut i sub denumirea de surogat)
Context:
Clienii trebuie s acceseze un serviciu al altui obiect sau component, iar
accesul direct nu este posibil sau de dorit.
Problema:
De obicei nu este bine s se permit accesul direct la serviciile unei componente
sau obiect, de exemplu din motive de securitate. De asemenea s-ar putea s fie
imposibil s se acceseze n mod direct o component datorit locaiei sale fizice.
Dac un obiect nu poate fi accesat n mod direct, trebuie prevzut un mecanism
suplimentar ntre client i serviciul cerut.
Curs 2
Exemplu: ablon de proiectare: ablon pentru Proxy

Cerine:
Accesul indirect la un serviciu trebuie s fie eficient i nu trebuie s introduc un cost
excesiv
Faptul c serviciile nu sunt accesate n mod direct trebuie s fie un aspect transparent
clientului
Soluie
Clientul trebuie s comunice cu un delegat al componentei i nu cu componenta
propriu-zis. Delagatul este un proxy (obiect de apropiere) care trebuie s ofere
interfaa (serviciile) componentei, dar poate face i alte lucruri suplimentare, cum
ar fi, de exemplu, verificarea aspectelor de securitate.
Curs 2
Exemplu: ablon de proiectare: Proxy: Vedere static

Original
Furnizorul
serviciului
Furnizorul de servicii
Destinatarul serviciului
Surogat
Proxy
Destinatarul
serviciului
Client
Surogat
Proxy
AbstractOriginal
serviciul 1()
serviciul 2()
Client
sarcina()
Proxy
pre-procesare()
post-procesare()
Original
Curs 2
Exemplu: ablon de proiectare: Proxy: Vedere

dinamic
c : Client
p : Proxy
o : Original
sarcina ( )
serviciul1( )
pre-procesare( )
serviciul1( )
post-procesare( )
Curs 2
Exemple de abloane arhitecturale

Procese distribuite
Bazat pe reguli
Client-Server
Straturi
Condus de evenimente
MVC
Bazat pe cadre
Broker
Batch-uri
Tranzacie
Filtre
Blackboard
Bazat pe depozite
Interpretor
- Software Architecture: Perspective On An Emerging Discipline, Mary Shaw, David Garlan, PrenticeHall, 1996
- Pattern-Oriented Software Architecture - A System of Patterns, Buschmann, F, Meunier, R., Rohnert,
H., Sommerlad, P., and Stahl, M., John Wiley and Sons, 1996.
Curs 2
Combinarea abloanelor
Un sistem distribuit tipic, obinuit, probabil va fi necesar s foloseasc:
ablonul de stratificare (sisteme cu mai multe nivele de abstractizare)
ablonul client-server
ablonul de folosire a depozitelor de date
ablonul broker
ablonul de notificare a evenimentelor
ablonul MVC
ablonul proceselor distribuite
etc.
Curs 2
Mecanismele arhitecturale sunt abstractizri

Funcionalitatea
cerut
realizat de clasele
clientului folosind
Mediul de
implementare
restricionate de
Mecanisme
Specificaii suplimentare
Produse
Baze de date
Tehnologii
etc.
responsabil de
Modelul Use-Case
Arhitect
Curs 2
Tipuri de mecanisme arhitecturale
Slide
Slide
59
59
Mecanismele arhitecturale sunt definite progresiv, din ce n ce mai

detaliat, i din ce n ce mai concret
Mecanismele de analiz (conceptual) - o proprietate general a unei categorii
extinse de sisteme care ofer funcionalitatea prin care se interacioneaz cu sau sprijin
funcionalitatea de baz a unei aplicaii (de exemplu, persistena, comunicarea)
Mecanismele de proiectare (concret) - prezint unele detalii ale mediului n care se

va face implementarea, dar nu sunt legate de o anumit implementare (tehnologii
specifice strategice: alegerea dintre o baz de date relaionale sau o baz de date
orientat pe obiecte.
Mecanisme de implementare (real) - se aleg tehnologii concrete, cum ar fi de

exemplu, alegerea unei baze de date ORACLE sau a unei baze de date SQL Server
comunicare, persisten
Mecanism
de analiz
ORB, RDBMS
Orbix, Oracle
Mecanism
de proiectare
Mecanism de
implementare
Curs 2
Exemplu de corelaie ntre mecanismele arhitecturale

Mecanisme
de analiz
Persisten
Comunicare
Mecanisme
de proiectare
Mecanisme de
implementare
Sisteme de gestiune a bazelor

de date relaionale
JDBC + Oracle
Sisteme de gestiune a bazelor de

date orientate pe obiecte
ObjectStore
Orbix
Object Request Broker
VisiBroker
MSMQ
Coada de mesaje
MQSeries
Curs 2
Mecanismele arhitecturale asigur cerinele arhitecturale

Cerine
Cerinele
FURPS
Analiz
Proiectare
Implementare
Influeneaz
Mecanisme de
analiz
Cerinele de
proiectare
Influeneaz
Cerinele de
implementare
influeneaz
Rafinate n
Mecanisme
de proiectare
Rafinate n
Mecanisme de
implementare
Curs 2
Exemple de mecanisme folosite la analiz

Auditarea mecanism de urmrire a execuiei sistemului i a datelor pstrate
n sistem, motiv pentru care este nevoie de:
Istoric
Jurnal
Comunicarea mecanism ce permite comunicarea dintre procese, chiar i n
cadrul unei reele. Sunt necesare:
Distribuirea
Mesageria
Depanarea
Managementul erorilor mecanisme de detectare, comunicare, jurnalizare,
raportare i refacere dup defectare. Sunt necesare cel puin:
Detecia
Raportarea
Tolerana la defectri
Curs 2
Mecanisme de documentare (modelul de programare)

Pentru fiecare dintre mecanismele create, arhitectul trebuie s ofere un
model de programare care prezint interfaa mecanismului i explic
cum trebuie folosit.
Programatorii trebuie s lucreze cu o serie de abstractizri ale
mecanismului sistemului, numit model de programare
Modelul de programare trebuie s explice:
Cnd i cum trebuie folosit mecanismul
Implicaiile utilizrii mecanismului
Programatorii nu trebuie s cunosc detaliile tehnice ale infrastructurii

Programatorii trebuie s se concentreze pe implementarea funcionalitii
sistemului
Prezentate n documentul cu reguli de proiectare


Exmplu de mecanism de persisten folosind un sistem de gestiune a bazelor
de date relaionale i un obicet de conexiune JDBC
Curs 2
DBPersistentClass
PersistentClassList
create() : PersistentClass
read(searchCriteria : string) : PersistentClassList
update(c : PersistentClass)
delete(c : PersistentClass)
DB_faade
PersistenceClient
Requestor
getString() : string
new()
add(c: PersistentClass)
getData()
setData()
command()
new()
Persistent_object_list
Persistent_object
DB_faade
Persistent_object
Persistent_object_list
Persistence RDBMS - JDBC
ResultSet
PersistentClass
Statement
SQL_helper
Result
executeQuery(sql : String) : ResultSet

executeUpdate(sql : String) : int
Drive_manager
DB_connection
Connection
createStatement() : Statement
Diagrama
Diagrama este
este oo diagram
diagram de
de colaborare
colaborare
folosit
folosit pentru
pentru aa prezenta
prezenta mecanismul
mecanismul de
de
persisten
persisten n
n cazul
cazul utilizrii
utilizrii unui
unui sistem
sistem
relaional
relaional de
de gestiune
gestiune aa bazelor
bazelor de
de date.
date.
Clasele
Clasele abstracte
abstracte (cu
(cu caractere
caractere nclinate)
nclinate)
reprezint
reprezint roluri
roluri n
n cadrul
cadrul mecanismului
mecanismului
JDBC
JDBC ce
ce trebuie
trebuie completate
completate de
de ctre
ctre
proiectant
proiectant pentru
pentru aa instania
instania mecanismul.
mecanismul.
Clasele
Clasele ce
ce trebuie
trebuie nlocuite
nlocuite cu
cu clase
clase
concrete
concrete de
de ctre
ctre proiectant
proiectant sunt
sunt prezentate
prezentate
n
n galben.
galben.
DriverManager
getConnection(url, user, pass) : Connection
Curs 2
Exemplu de parcurgere a pailor de folosire a JDBC

Alturi de exemplele de folosire a mecanismelor (de exemplu,
diagramele de interaciune), arhitecii trebuie s prezinte paii i
regulile necesare de aplicare a mecanismului
Ofer accesul la bibliotecile claselor necesare pentru implementarea JDBC
Ofer pachetul java.sql
Creeaz clasele DBPersistentClasses
Regul: cte o clas DBPersistentClass pentru fiecare clas persistent
ncorporarea claselor DBPersistentClasses n cadrul proiectului
Se aloc unui pachet/strat
Se adaug relaiile cu clienii persisteni
Crearea/actualizarea diagramelor de interaciune care descriu:
Iniializarea bazei de date
Accesul la clasele persistente: Create, Read, Update, Delete
Curs 2
Medii de elaborare a claselor

Un ablon imlpementat parial pentru partea orizontal a unei aplicaii
Trebuie extins i adaptat pentru a putea fi instaniat
De obicei este nevoie de proiectant care ofer implementrile interfeelor
abstracte
Pot fi reprezentate sub form de pachete

Un pachet ce conine tipuri i clase abstracte i concrete proiectate pentru a
putea fi refolosite
Software Reuse: Architecture, Process and Organization for Business Success: I. Jacobson, M. Griss, P. Jonsson;
Addison-Wesley, 1997
Curs 2
Instanierea unui mediu de elaborare a claselor

Exemplul
Exemplul de
de mai
mai jos
jos reprezint
reprezint oo modalitate
modalitate de
de instaniere
instaniere aa mediului
mediului de
de elaborare
elaborare aa claselor
claselor
X11.
X11. Subsistemul
Subsistemul numit
numit My
My Interface
Interface este
este creat
creat prin
prin instanierea
instanierea subsistemului
subsistemului abstract.
abstract.
Mediul de elaborare a claselor

X11
Window
Button
My Interface
MyWindow
MyButton
Curs 2
Mediul de elaborare a componentelor

Arhitectur dedicat special
Alctuit din mecanisme/servicii cheie i politici de utilizare a acestor
mecanisme/servicii la nivel de component
Politici impuse de ctre mediul de elaborare
Ex. Mecanisme de elaborare a obiectelor de business
Pornire i oprire
Comunicare (direct i bazat pe evenimente)
Managementul componentelor/obiectelor (containere)
Managementul tranzaciilor
Persisten
Managementul erorilor
Prezentare (GUI)
Component Software: Beyond Object-Oriented

Programming; Clemens Szyperski, Addison-Wesley, 1997
Curs 2
Mediul de producere a componentelor = Infrastructur
Un set de mecanisme i servicii pe baza crora se poate construi un

anumimt fel de arhitectur a unei aplicaii
Trebuie s rezolve multe dintre dificultile majore ale arhitecturii
Orientat de obicei spre un anumit domeniu: comand i control, MIS,
sistem automat etc.
Curs 2
Crearea de componente cu ajutorul mediilor de producere a acestora

Productorii de componente se concentreaz pe proiectarea i implementarea
logicii aplicaiei
Mecanismele (serviciile) apar sub forma unor obiecte/interfee n modelul de
programare a componentei
Mediile de producere a componentelor sunt dotate de obicei cu instrumente
Care neleg implementarea mecanismelor de baz
Care abstractizeaz mecanismele n cadrul modelului de programare a componentei
Funcionalitate
Logica aplicaiei
Scris de ctre
productorul de
componente
Oferit de
mediul de
producere a
componentelor
Clasele
interfeelor
generate de
obicei de
ctre mediul
de elaborare
Infrastructur
Controlul eerorilor
Curs 2
Iteraia n arhitectur
Contextul iteraiei
- La nceputul iteraiei se face o descriere a contextului n care se desfoar ntregul proces,
prezentndu-se felul n care iteraia se ncadreaz n procesul general de dezvoltare
software.
Descrierea fluxului de lucru la elaborare

- n etapa urmtoare se face o prezentare detaliat a procedurilor implicate (de exemplu,
prezentarea vederilor arhitecturale i a corespondenelor acestora), inclusiv a consideraiilor
fcute de ctre arhitect la elaborarea vederilor i a corespondenelor lor.
Revizuirea arhitecturii propuse

-
La final, se va face o revizuire a arhitecturii propuse iniial i se ofer setul de reguli necesar.
Curs 2
Fluxurile de lucru ale

procesului
Faze
Iniiere
Elaborare
Construcie
Tranziie
Modelarea domeniului
Cerine
Analiz i proiectare
Implementare
Testare
Introducere n mediul real de funcionare
Fluxurile suport
Configurare i managementul modificrilor
Managementul proiectului
Mediu
Ne aflm aici!
Iteraii
preliminare
Iter.
#1
Iter.
#2
Iter.
#n
Iter. Iter.
#n+1 #n+2
Iter.
#m
Iter.
#m+1
Iteraii
Curs 2
Intrrile folosite n faza de Elaborare

Cerine iniiale
Cerine arhitecturale semnificative (SAR) documentate prin:
Vederea Use-Case (cerine funcionale)
Vederea cerinelor non-funcionale.
Vederea iniial de domeniu

Ipotezele i datele iniiale referitoare la arhitectur
Modelul de analiz iniial (opional)
Evaluarea riscului iniial
Curs 2
Axarea pe modificri
Aspectul cel mai important ce trebuie avut n vedere n faza de Elaborare este acela referitor la
modificri. De exemplu, presupunnd c avem patru iteraii, acestea ar putea arta cam aa:
Iteraia 1:
Alctuirea echipei
nelegerea tehnologiilor de baz (att cele folosite la elaborare ct i cele ntlnite la execuie)
Cunoaterea amnunit a domeniului revizuirea modelului de domeniu
Revizuirea cerinelor
Mecanisme cheie, cteva use case-uri critice
Iteraia 2:
Adugarea de mecanisme noi; revizuirea mecanismelor proiectate anterior
Adugarea de use case-uri noi i a diagramelor de colaborare corespunztoare
Verificarea parametrilor sistemului, cum ar fi performana
Integrarea cu alte sisteme externe
Iteraia 3:
Acordarea unei atenii sporite relaiilor ce se stabilesc n timpul funcionrii, integrare extern sporit
Stabilirea de aspecte msurabile pentru sistem i pentru managementul proiectului
Iteraia 4:
mpachetarea mecanismelor
Planificarea fazei de implementare
Stabilirea de reguli impuse la elaborare
Curs 2
Algoritmul (schema logic) de

elaborare a arhitecturii
Start
Elaborarea vederii
de domeniu
Corespondena DoUC
Se pot elabora n paralel, dar cei mai muli

prefer s introduc mai nti cerinele
funcionale
Corespondena DoLo
Elaborarea vederii
Use case
Corespondena NFUC
Elaborarea vederii cerinelor
non-funcionale
Corespondena UCLo
Corespondena NFLo
Corespondena NFPr
Elaborarea
vederii logice
LoPr Mapping
Corespondena NFIm
Corespondena LoIm
Elaborarea
vederii de proces
Corespondena LoDe
PrIm Mapping
Corespondena NFPmrf
PrPmrf Corespondena
Elaborarea vederii
de implementare
ImPmrf Corespondena
Elaborarea vederii de punere

n mediul real de funcionare
Curs 2
Corespondenele vederii Use case

Domeniu
Cerine non-funcionale
(Informaii)
DoUC
NFUC
Use-Case
Use case-urile se refer la conceptele din

domeniul respectiv.
Activitile i procesele din acel domeniu sunt
reprezentate cu ajutorul Use case-urilor.
Utilizabilitatea, performana
sau scalabilitatea trebuie
asociate Use case-urilor
Curs 2
Exemplu de descriere Use case (Corespondena DoUC)

3. Fluxul de evenimente
3.1. Fluxul principal
Nr.
Eveniment
Comentarii
Studentul alege cursul de pe pagina Web a universitii
Studentului i se prezint o pagin de cutare n care se face i o descriere a

cursului pentru care este interesat
Studentului i se cere s aleag o specializare din lista prezenatat
Studentul alege o specializare
Sistemul prezint data la care s-a fcut nregistrarea i cere o confirmare
Sistemul afieaz confirmarea
7
8
Cursurile sunt organizate pe catedre, apoi pe cicluri de nvmnt i apoi pe grupuri

(100, 200 etc.)
Sistemul pstreaz datele studentului pe care le poate afia oricnd se cere acest lucru
Catedra
Se trimite ctre sistemul de plat o nregistrare nou

ContStudent
1..n
nregistrrile sunt adunate pentru fiecare student, iar la sfrit se prezitn suma total
de plat
Sfritul Use case-ului
+curs oferit
0..1
0..n
Curs
1
+cursuri posibile
Student
0..n
0..n
urmeaz
Orar
0..n
Specializare

Examplu de coresponden ntre cerinele non-funcionale i Use Case-uri
(Corespondena NFUC)
Curs 2
Cerin
ntrebare
Impact
Rspuns
Sistemul trebuie s ofere att

acces Internet ct i acces n
reea local
De ce nu se
folosete
doar
accesul Internet?
Cere elaborarea a
dou
tipuri
de
interfee
alternative
care va conduce la
creterea costului cu
25%
Trebuie s avem
acces dedidat de
mare vitez la
sistem.
Mare
Sistemul trebuie s foloseasc

ORACLE pe sistemul de
operare Windows
De ce nu se
folosete un sistem
SQL Server care s
ruleze
pe
Windows?
Trebuie s existe
personal specializat
care s tie s
lucreze att pe SQL
Server ct i pe
ORACLE
Sistemul existent
pentru
cursuri
folosete
dj
platforma
ORACLE
Mare
Stratul
intermediar
(middleware) trebuie s ruleze
pe servere Windows
Dac
folosim
ORACLE de ce nu
folosim servere Sun
pentru elaborarea
stratului
intermediar?
Prin folosirea unei

singure familii de
tehnologii
se
economisete
15%
din
costul
de
dezvoltare
Avem n vedere
ca mai trziu s
migrm sistemul
pe
platforme
Microsoft.
Mare
= 100/15 100
de utilizatori cu 15
sec. timp maxim
de rspuns
Mediu
Sistemul trebuie s prelucreze

cel puin 7 nregistrri la
cursuri pe secund
Prioritate
Slide-ul
urmtor

Examplu de coresponden ntre cerinele non-funcionale i Use Case-uri
(Corespondena NFUC)
Curs 2
Vede raport
Din slide-ul
anterior
Student
Se nregistreaz la curs
Conectare
Profesor
Sistem existent
pentru cursuri
Trimite note
Pstreaz informaiile profesorului
Sistem de nregistrare
existent
Pstreaz informaiile studentului
ncheierea nregistrrii
Sistem
existent de
plat
Curs 2
Consideraii referitoare la vederea Use case

Care dintre Use case-uri ilustreaz cel mai bine funcionalitatea critic
a sistemului?
Care sunt cele mai dificile Use case-uri (cel mai greu de implementat)?
n ce ordine trebuie proiectat, implementat i testat un Use case?
Ce grup de cunotiine este necesar pentru a descrie Use case-urile?
Care dintre cerinele non-funcionale trebuie avute n vedere?
Curs 2
Vederea Use case: Procesul de elaborare

Alegerea celor mai importante use case-uri din punct de vedere
arhitectural din modelul Use case (Vederea Use-Case)
Ordonarea use case-urilor alese
(Rolul responsabil de elaborarea Use-Case-urilor) descrie cele mai
importante use case-uri
Face referire la entitile vederii de domeniu, dac este cazul
(Corespondena DoUC)
Face corespondena dintre cerinele non-funcionale i use case-urile

cele mai importante din punct de vedere arhitectural (Corespondena
NFUc)
Curs 2
Use case-urile cele mai importante din punct de vedere

arhitectural
Sunt use case-uri critice n ceea ce privete
funcionalitatea sistemelor
Sunt use case-uri cu ajutorul crora se poate
simula arhitectura i care ajut la identificarea
principalelor probleme i riscuri
Sunt use case-urile cele mai predispuse la
modificri
Nu :
Se aleg Use case-urile echivalente
Se urmresc toate evenimentele, dect dac acestea
se afl n legtur cu o parte nsemnat a sistemului
sau sunt critice pentru sistem
Curs 2
Ordonarea use case-urilor

Scenariile se ordoneaz dup influena asupra funcionalitilor
sistemului (importante sau auxiliare)
Se iau n considerare riscurile care trebuie micorate
Prezentarea arhitecturii se consider a fi complet atunci cnd:
Se realizeaz vederea logic complet
Se stabilesc corespondenele dintre vederile de implementare, de proces
i de punere n mediul real de funcionare
Se mi ine cont i de alte obiective tactice sau restricii cum ar fi

prezentare unui demo, fondurile avute la dispoziie etc.
Curs 2
Consideraii asupra vederii logice

Preocuprile i deciziile ce trebuie avute n vedere la elaborarea
vederii logice sunt:
Ce reprezint partiionarea unui sistem?
Ce sarcini trebuie s ndeplineasc elementele importante ale sistemului?
Care este descompunerea logic a acestor elemente?
Care sunt cele mai importante interfee i interaciuni ale sistemului cu
mediul n care funcioneaz?
Care sunt mecanismele arhitecturale majore?
Se pot folosi specificaiile elementelor pentru a le testa implementarea?
Este proiectul arhitectural uor de neles i elegant?
Curs 2
Corespondenele vederii logice

NFLo
UCLo
Use-Case
Domeniu
(Funcional)
(Informaii)
DoLo
Conceptele de domeniu (entitile)
sunt prezentate prin clase sau
subsisteme, constrngerile de
domeniu sunt prezentate prin
constrngeri de proiectare
Logica
Proiectele logice sunt modificate

de proprietile sistemuluisau de
cerinele tehnologice
Use case-urile sunt

prezentate prin colaborri
sau elemente logice
Curs 2
Elaborarea vederii logice: analiza i proiectarea

Modelul logic este elaborat n dou etape
Modelul de analiz = setul iniial de concepte
Modelul de proiectare = setul int de concepte
Vederea logic este o proiecie a modelului de proiectare

Modelul de analiz reprezint o abstractizare a modelului de proiectare
i este opional
Modelul de proiectare este o abstractizare a modelului de implementare
Curs 2
Vederea logic: Analiza

Identificarea conceptelor cheie
Identificarea partiiilor iniiale ale sistemului (nivele, pachete)
Identificarea mecanismelor de analiz
(Proiectant) Proiecteaz realizrile use case-urilor (prezentate n
corespondena UCLo)
Curs 2
Identificarea conceptelor cheie

Stabilirea claselor de analiz preliminare (surse)
Cunotiine din domeniu
Vederea de domeniu (Corespondena DoLo)
Cerine
Stabilirea relaiilor dintre clasele de analiz

Documentarea claselor de analiz i a relaiilor acestora
Scurt descriere a clasei de analiz
Acestea vor fi revizuite pe parcursul proiectrii logice
Curs 2
Exemplu: modelarea conceptelor cheie
Curs
Profesor
+instructor
0..n
0..n
+ IdentificatorCurs
+ NumeCurs
1
1
0..n
0..n
Student
+urmeaz
0..n
+orar
0..n
Specializare
+ NumarSpecializare : Integer
+ capacitate : Integer
1
0..1
ContStudent
Curs 2
Partiiile iniiale
n multe situaii, pot exista arhitecturi predefinite sau abloane
arhitecturale ce pot fi refolosite.
Concept i reutilizare (stratificare)
Elemente de grup care se afl ala acelai nivel de abstractizare
Elementele de la nivelul mai nalt de abstractizare pot refolosi elemente de la
nivelele mai joase de abstractizare
Separarea problemelor
Gruparea elementelor cu responsabiliti asemntoare
Gruparea elementelor asemntoare
Reziliena
Gruparea elementelor aflate n strns legtur
Gruparea elementelor care se modific mpreun (interfaa utilizator, reguli de
domeniu, date pstrate)
Evitarea dependenelor circulare

Curs 2
Vederea stratificat a unui sistem

Cod specific
echipamentului i
clientului
Procese i alte
coduri ale
aplicaiei
Concepte
importante, clase
etc.
Mecanisme,
servicii
Cod specific H/W,
cod specific O/S
cod cu caracter
general (ex. ORB,
MQS,)
Aplicaie
4
Cadrul
aplicaiei
Infrastructura
1
Curs 2
Exemplu: Partiionarea iniial
<<layer>>
Interfaa utilizator
(din modelul de proiectare)
<<layer>>
Logica de domeniu
<<layer>>
Servicii
Stratul
Interfaa
utilizator
conine
Stratul
Interfaa
utilizator
conine
elementele
elementele modelului
modelului care
care au
au rolul
rolul de
de aa
interaciona
interaciona cu
cu utilizatorul.
utilizatorul.
Stratul
Stratul Logica
Logica de
de domeniu
domeniu conine
conine acele
acele
elemente
elemente ale
ale modelului
modelului care
care acord
acord
comportamentul
comportamentul specific
specific acelui
acelui domeniu.
domeniu.
Stratul
Stratul de
de Servicii
Servicii conine
conine acele
acele elemente
elemente
de
de model
model ce
ce ofer
ofer servicii
servicii elementelor
elementelor din
din
stratul
stratul superior.
superior. Aceste
Aceste servicii
servicii se
se pot
pot folosi
folosi
n
n cadrul
cadrul aplicaiilor.
aplicaiilor.
Curs 2

Slide
Slide
25
25
Identificarea mecanismelor de analiz
Mecanismele de analiz sunt mecanisme arhitecturale necesare

rezolvrii unor probleme identificate pe parcursul analizei sistemului
Metoda de sus n jos (cunotine anterioare)
Arhitecii experimentai care cunosc problema i soluiile corespunztoare
acesteia
Proprietile impuse sistemului sau cerinele tehnologice (din vederea cerinelor
non-funcionale)
Metoda de jos n sus (descoperite pe parcurs)

Mecanismele de analiz sunt descoperite pe parcurs
Arhitecii recunosc anumite abloane care pot deveni soluii ale problemelor
descoperite
Mecanismele de analiz evideniaz i numesc problema

(corepondena NFLo)
De exemplu, arhitectul sistemului stabilete c sistemul are nevoie de un
mecanism de persisten
Curs 2
Vederea logic: Procesul de elaborare (Proiectare)

Etapele de proiectare sunt:
Stabilirea mecanismelor de proiectare i implementare (elaborarea
modelului de programare)
Stabilirea subsistemelor i a interfeelor lor
Stabilire posibilitilor de reutilizare
Revizuirea partiiilor iniiale ale sistemului
(Proiectant) Revizuirea realizrilor use-case (stabilite n corespondena
UCLo)
(Proiectant) Detaliaz elemente de proiectare
Alege cele mai importante elementele de proiectare
Curs 2
Stabilirea mecanismelor de proiectare i implementare

Clasificarea clienilor i a mecanismelor de analiz
Profile de utilizare
Alegerea mecanismelor de proiectare

Compararea profilelor de utilizare cu caracteristicile mecanismelor de proiectare
Crearea listei mecanismelor de implementare

Transformarea mecanismelor de proiectare n mecanisme de implementare
Corespondena mecanismelor arhitecturale (revizuirea corespondenei NFLo)
Documentaiile mecanismelor arhitecturale

Documentul cu arhitectura produsului software (corespondena mecanismelor
arhitecturale )
Stabilirea de reguli de proiectare (modelul de programare)
Curs 2
Exemple de caracteristici ale mecanismelor

Persistena
Granularitate dimensiunea
obiectelor care se pstreaz
Volum numrul de obiecte care
trebuie pstrate
Durata ct timp trebuie pstrate
obiectele
Mod de acces modalitatea de
identificare unic i modul de
extragere
Frecvena accesului (CRUD) ct de
des se modific obiectele
Fiabilitate obiectele fac fa unei
cderi a sistemului?
Securitate
Dimensiunea datelor
Granularitatea utilizatorului
Reguli de securitate
Categorii de privilegii
Interfaa motenit
Laten
Durata
Mecanism de acces
Frecvena accesului
Comunicare
Laten ct de repede pot comunica
obiectele unele cu altele
Sincronizare tip de comunicare
sincron sau asincron
Dimensiunea mesajului
Protocol flux automat, pstrare n
memorie etc.
etc.
Curs 2
Exemplu de profile de utilizare folosite la mecanismul de

persisten
Profil 1
Profil 2
Granularitate
2-24 KB
2-3 MB
Volum (nr. obiecte)
100,000
2-4
Durata
> 2 ore
zile
Mod de acces
aleator
aleator
mic: 100/h
mic: 2/zi
medie: 3,000/h
medie: 10/zi
mare: 9,000/h
mare: 100/h
Frecven acces
Fabilitate
mare
mare
Ajut la stabilirea/identificarea setului optimal de mecanisme de

proiectare i implementare
Curs 2
Exemplu de mecanism de persisten folosit la

proiectare
n memoria intern
Pn la N MB total (dimensiune x volum) n care N < 30
Acces foarte rapid (< 1 ms)
Poate suporta diferite moduri de acces
Fr persisten n afara procesului
Greu de coordonat accesul concurent
n memoria extern
Pn la 20-30 MB
Vitez de modificare mic
Vitez de citire moderat
(continued)
Curs 2
Exemplu de coresponden NFLo

Cerin
ntrebare
Impact
Rspuns
Sistemul trebuie s ofere att

acces Internet ct i acces n
reea local
De ce nu se
folosete
doar
accesul Internet?
Cere elaborarea a
dou
tipuri
de
interfee
alternative
care va conduce la
creterea costului cu
25%
Trebuie s avem
acces dedidat de
mare vitez la
sistem.
Mare
Sistemul trebuie s foloseasc

ORACLE pe sistemul de
operare Windows
De ce nu se
folosete un sistem
SQL Server care s
ruleze
pe
Windows?
Trebuie s existe
personal specializat
care s tie s
lucreze att pe SQL
Server ct i pe
ORACLE
Sistemul existent
pentru
cursuri
folosete
dj
platforma
ORACLE
Mare
Stratul
intermediar
(middleware) trebuie s ruleze
pe servere Windows
Dac
folosim
ORACLE de ce nu
folosim servere Sun
pentru elaborarea
stratului
intermediar?
Prin folosirea unei

singure familii de
tehnologii
se
economisete
15%
din
costul
de
dezvoltare
Avem n vedere
ca mai trziu s
migrm sistemul
pe
platforme
Microsoft.
Mare
= 100/15 100
de utilizatori cu 15
sec. timp maxim
de rspuns
Mediu
Sistemul trebuie s prelucreze

cel puin 7 nregistrri la
cursuri pe secund
Prioritate
<<mechanism>>
Persistena RDBMS - JDBC
Curs 2
Subsisteme
Un subsistem este n acelai timp o clas i un pachet
Un subsistem conine i comportamentul coninuturilor sale
Sunt uor de nlocuit
Pot fi folosite la fel ca i clasele
Clasa client
PachetB
<<subsistem>>
Clasa B1
Clasa B2
Curs 2
Utilizarea subsistemelor
Subsistemele pot fi folosite la partiionarea unui sistem n componente independente:
Controlat, configurat sau furnizat
Dezvoltat, atta timp ct interfeele sale rmn nemodificate
Implementat de-a lungul unor noduri de calcul distribuite
Modificat fr a afecta alte pri ale sistemului
Subsistemele mai pot fi folosite la:
Partiionarea sistemului n uniti care ofer o anumit securitate a resurselor cheie
Reprezint produse existente sau sisteme externe n cadrul proiectrii (de exemplu,
componente)
Se modeleaz mai multe variante de implementare
Curs 2
Identificarea subsistemelor
Se caut clase de analiz complexe
Se caut produse existente sau sisteme externe
Se caut colaborri de obiecte i cuplri
Se urmrete opionalitatea (comportamentul opional din cadrul modelului de
colaborare, sau caracteristicile ce pot fi eliminate, actualizate sau nlocuite cu
altele)
Se stabilesc actorii i interfaa utilizator
Se urmrete substituirea (reprezint nivele diferite ale serviciului pentru o
anumit caracteristic - de exemplu, disponibilitate nalt, medie sau sczut
- , fiecare dintre acestea folosind aceleai interfee
Se urmrete distribuirea (dac o anumit funcionalitate trebuie ndeplinit
ntr-un anumit nod, se creeaz un subsistem pentru acel nod)
Se urmrete instabilitatea (creearea de pri separate n cadrul unui sistem
care se ateapt s se modifice frecvent)
Curs 2
Stabilirea interfeelor
Stabilirea unui grup de interfee candidat pentru subsistemele identificate anterior organizarea funcionalitilor subsistemelor n grupuri de funcionaliti coezive, asociate.
Aceste grupuri stabilesc setul iniial de interfee ale sistemului. Trebuie stabilit o operaie
corespunztoare fiecrei funcionaliti, la care se adaug parametrii i valorile de retur.
Cutarea de similitudini ntre interfee - se caut nume, funcionaliti i operaii
asemntoare. Se introduc operaiile comune ntr-o nou interfa.
Stabilirea dependenelor interfeelor - se adaug relaii de dependen ntre interfee i
clase i/sau alte interfee care apar n semnturile operaiilor interfeelor
Stabilirea corespondenelor dintre subsisteme i interfee
Stabilirea comportamentului specific pentru fiecare interfa - dac operaiile interfeelor
trebuie invocate ntr-o anumit ordine, trebuie creat o main de stare care s prezinte
strile vizibile sau care se pot deduce ce trebuie suportate pentru fiecare element de
proiectare care se materializeaz ntr-o interfa.
mpachetarea interfeelor - Interfeele pot fi gestionate i controlate n mod independent de
sisteme. Interfeele trebuie grupate n conformitate cu funcionalitile lor. Dac un
subsistem are doar o singur interfa, acesta poate fi plasat n acelai pachet cu interfaa.
Interfeele stabile, bine definite reprezint cheia unei arhitecturi rezistente la ocuri
Curs 2
Exemplu de proiectare a subsistemelor i interfeelor

<<boundary>>
SistemPlata
// trimite chitanta()
<<interface>>
IPlata
<<subsystem>>
Sistem de plata
trimiteChitanta(ptSpec : Spec, ptStudent : Student)
<<boundary>>
CatalogCursuri
// afiseaza lista cursuri()
<<interface>>
ICatalogCurs
<<subsystem>>
Catalog de cursuri
afiseazaCurs(ptSemestru : Semestru) : ListaCursuri
Curs 2
Vederea logic: elemente arhitecturale importante

Organizarea/structura modelului
Partiii (straturi, pachete)
Elemente de proiectare majore/de baz

Esenial pentru domeniu (nu toate subclasele)
Vizibilitate mare
Participare n unele interfee importante
Vizibilitate localizat, dar cu impact major asupra performanelor generale ale
sistemului
Introducerea unui algoritm nou sau critic
Curs 2
Vederea logic: elemente arhitecturale importante

Toate subsistemele i interfeele exportate
n special interfee exportate de pe straturi
Nu modulele individuale
Mecanisme arhitecturale
Modele de programare
Curs 2
Aspecte ce trebuie avute n vedere la evaluarea vederii logice

Partiionarea
Partiionarea unui sistem trebuie s se fac consistent din punct de vedere logic
Toate elementele trebuie identificate cu uurin n proiect, iar cile ctre
elementele imbricate trebuie s fie intuitive
Este bine s nu fie mai mult de 7 partiii majore
Mecanisme arhitecturale
Trebuie identificate i modelate toate mecanismele arhitecturale necesare
Arhitectura trebuie s ofere o imagine complet i atotcuprinztoare asupra
mecanismelor
Trebuie definite modelele de programare.
Curs 2

Pachete/subsisteme
Se verific dac numele pachetelor sunt sugestive
Se verific dac exist o imagine cuprinztoare a serviciilor oferite de ctre
pachete
Se verific dac elementele unui pachet sunt la locul potrivit n funcie de criteriile
stabilite. Dac nu, se mut n alte pachete sau se creeaz alte pachete
Se verific dac depdendenele pachetelor corespund relaiilor dintre elementele
pachetului respectiv. Dac clasele dintr-un pachet nu sunt legate funcional
ntre ele, se pot muta unele dintre clase n alte pachete sau se creeaz alte
pachete.
Se verific dac exist elemente sau colaborri dintre elemente n cadrul
pachetului care pot fi separate n pachete independente
Se verific dac raportul dintre numrul de pachete i numrul de clase este
corespunztor
Curs 2

Clase
Se verific dac toate clasele cheie au fost corect i precis identificate i
modelate
Se verific dac toate clasele importante mpreun cu relaiile lor sunt
consistente n raport cu vederea de domeniu, cu cerinele, cu glosaurl de termeni
etc.
Se verific dac numele fiecrei clase reflect bine rolul pe care l joac (este
sugestiv)
Se verific interconectarea claselor (toate prile funcioneaz n ansamblu)
Se verific dac toate elementele claselor sunt necesare pentru realizrile use
case
Curs 2
Corespondenele folosite n vederea logic
Cerinele de performan,
fiabilitate i distribuire vor stabili
clasele active
NFPr
Logic
LoPr
Clasele sunt marcate ca fiind active

i se folosesc stereotipuri la fel ca la
procese i fire de execuie. Se
prezint managerii de resurse.
Proces
Curs 2
Aspecte ce trebuie luate n considerare la elaborarea vederii de

proces
Se stabilesc clasele active (care trebuie s ruleze n propriul fir de execuie)
pe baza cerinelor de distribuire, concuren i scalabilitate (numr de
procese, timp de rspuns etc.)
Se urmrete modul de comunicare a claselor ce ruleaz n fire de execuie
separate
Semantica de referin
Transportul datelor
Se stabilesc resursele de calcul necesare pentru rularea claselor active i a

claselor pasive asociate
Se stabilete modalitatea de gestionare a claselor active i a resurselor
sistemului
Calitatea serviciului
Curs 2
Procese i fire de execuie

Stabilirea stereotipurilor pentru clasele active
Proces (stereotipul <<process>>)
<<process>>
ClasaA
Flux de control puternic

Procesele sunt de sine stttoare
Pot fi descompuse n fire de execuie individuale
<<thread>>
ClasaB
Fir de execuie (stereotipul <<thread>>)

Flux de control
Firele de execuie ruleaz n interiorul unui proces nchis
Curs 2
Elaborarea vederii de proces

nelegerea cerinelor de concuren, distribuire i scalabilitate
Identificarea firelor de execuie independente (procese i fire de execuie)
(corespondena LoPr)
Stabilirea elementelor instaniate de ctre procese/fire de execuie
(corespondena LoPr)
Stabilit pe baza relaiilor dintre clase
Definirea cerinelor de comunicaie interproces

Pe baza relaiilor dintre clase
Sincron sau asincron
Realizarea corespondenei dintre IPC i mecanismele disponibile (corespondena
LoPr)
Modelarea imaginii de execuie a fiecrui proces

Realizarea corespondenei dintre procese/fire de execuie i mediul de
implementare
Realizarea corespondenei dintre cerinele de concuren i elementele de
proiectare (corespondena NFPr)
Curs 2
Cerine de concuren
Concurena motenit (extern)
Se stabilete dac sistemul este distribuit i dac pri ale sale opereaz concurenial
Se urmrete dac sistemul controleaz evenimente externe aflate n legtur care
apar aleator
Se urmrete dac sistemul controleaz canale independente de introducere a datelor
Concuren datorat cerinelor interne

Se urmrete dac sistemul trebuie s fie scalabil la diverse rate ale tranzaciilor fr
a-i scdea performanele
Se verific dac performanele sistemului pot fi mbuntite dac mai multe operaii
se desfoar n paralel
Se urmrete dac sistemul ndeplinete condiiile de disponibilitate i fiabilitate
Curs 2
Exemplu de cerine de concuren

n sistemul de nregistrare la curs a studenilor, concurena provine din
cerine i din arhitectur:
Mai muli utilizatori trebuie s poat efectua activiti concurenial
Dac o specializare se completeaz nainte ca studentul s-i creeze profilul,
acesta trebuie atenionat
Prototipurile de analiz a riscurilor au descoperit c baza de date a
sistemului existent de oferire a cursurilor nu ndeplinete condiiile de
performan fr a introduce unele mbuntiri la nivelul intermediar de
procesare
Curs 2
Stabilirea firelor de excuie independente

Folosirea firelor de execuie separate poate fi necesar pentru:
Folosirea mai multor procesoare. Pot fi mai multe procesoare ntr-un nod sau
mai multe noduri ntr-un sistem distribuit.
Creterea gradului de utilizare a unui procesor (prin alocarea ciclurilor altor
activiti dac un fir de edxecuie este suspendat).
Reacia rapid la stimuli externi.
Introducerea unui serviciu legat de apariia n timp a evenimentelor (ntreruperi,
activiti planificate, activiti periodice etc.).
Ordonarea activitilor. Procesele separate permit ca funcionalitatea n cadrul
diferitelor procese s poat fi ordonat n mod individual.
Scalabilitate. ncrcarea este distribuit ntre mai multe procese i procesoare.
Disponibilitate. Procese redundante. Se poate obine o disponibilitate mai mare
prin folosirea unor procese de rezerv.
Suportul unor subsisteme mari. Unele subsisteme mari pot cere procese
separate (de exemplu, sisteme de gestiune a bazelor de date, managerii de
tranzacii etc.).
Curs 2
Strategii de identificare a firelor de execuie separate

Strategia 1
Dinspre interior spre exterior
Intrare: modelul de proiectare, corespondena UCLo
Rezultat: vederea de proces, corepondena LoPr
Se urmresc clasele existente i se identific oportunitile de concuren
Se grupeaz elementele care coopereaz i care trebuie s se execute n
cadrul aceluiai fir de execuie
Se separ elementele care nu interacioneaz
Se repet pn cnd se obine un numr minim de procese care asigur
ns distribuirea i resursele necesare de utilizare efectiv
Curs 2
Strategii de identificare a firelor de execuie separate

Strategia 2
Dinspre exterior spre interior
Intrare: vederea cerinelor non-funcionale
Rezultat: vederea de proces, corepondenele Lopr i NFPr
Se verific cerinele de concuren
Se definete cte un fir separat de execuie pentru fiecare stimul extern
Se definete cte un fir de execuie separat pentru fiecare serviciu
Se reduce numrul de fire de execuie

Exemplu de coresponden ntre vederea logic i vederea de proces din
punct de vedere al proceselor i firelor de execuie
Curs 2
Toate paginile clientului i serverului sunt

reprezentate prin <<threads>> i ruleaz n
sau sunt gestionate de ctre managerii de
resurse
<<process>>
<<process>>
ServerWeb
BrowserWeb
<<Client Page>>
Principala
<<Client Page>>
IncepeInregistrare
<<Client Page>>
Inregistrare
<<Client Page>>
AlegeCurs
<<process>>
ServerAplicatie
<<Server Page>>
TrimiteInregistrare
<<process>>
<<process>>
TPM
ConectorCatalogCursuri
<<Server Page>>
ObtineListaCursuri
<<thread>>
CoordonatorInregistrareWeb
<<Server Page>>
ObtineListaSpecializari
+ obtineSpecializari()
Curs 2
Transformarea claselor n procese/fire de execuie

(corespondena LoPr)
Se ncepe cu clasele active (clasele ce au stereotipul
<<process>>/<<thread>>)
Se urmresc legturile dintre clasele active i toate celelalte clase
asociate
Toate clasele pasive gsite, n afara celor active sau celor deja
asociate altor procese, trebuie asociate unei clase active
Clasele pasive folosite de mai multe clase active trebuie stabilite n
mod explicit, deoarece afecteaz mpachetarea claselor active n
cadrul componentelor n vederea de implementare.
Curs 2
Exemplu de transformare a claselor n procese/fire de

execuie
<<process>>
ServerAplicatie
(din managerii de resurse)
<<Server Page>>
(din paginile serverului)
ListaSpecializari
(din artefacte universitare)
<<Server Page>>
ObtineListaCursuri
ListaCursuri
(din artefacte universitare)
Curs 2
Stabilirea necesitilor comunicrii interproces

Stabilirea asocierilor la comunicarea interproces
Asocieri ntre clase active
Asocieri dintre dou clase pasive din clase active separate
Stabilirea tipului de comunicare

Sincron (de ntlnire)
Diagrame de colaborare
Asincron (de tip cutie potal)
Stabilirea semanticilor de sincronizare

Secveniale
De aprare
Proprieti pe operaiile claselor
Concurente
Curs 2
Stabilirea necesitilor comunicrii interproces

Modelarea comunicrii interproces
Diagrame de colaborare (n cadrul corespondenei UCLo)
Instanele proceselor
Tip de comunicare
Semantici de comunicare
Coreposndena dintre comunicaia interproces i mecanismele

disponibile (corespondena LoPr)
Curs 2
Exemplu de prezentare a relaiilor IPC n vederea de

proces
Mecanism IPC :
COM
<<process>>
ServerAplicatie
<<Server Page>>
<<process>>
TPM
<<Server Page>>
Trimiteinregistrare
<<Server Page>>
ObtineListaCursuri
<<thread>>
CoordonatorWebInregistrare
IInregistrareWeb
Curs 2
Modelarea imaginii de execuie

Imaginea de execuie
Reprezint un instantaneu la un anumit moment dat al execuiei procesului i
instanelor firelor de execuie fr a face referire la locaie.
Vederea post instaniere/activare a firelor de execuie a sistemului
Identificarea numrului de obiecte active (instane de proces) de

acelai tip care exist i timpul execuiei
Modelarea diagramelor de obiecte UML
Cte una pe proces
Instanele de proces/fir de execuie mpreun cu legturile acestora
Curs 2
Exemplu de reprezentare a imaginii de execuie n

vederea de proces
BW1 :
BrowserWeb
PC1 :
IncepeInregistrare
SW :
ServerWeb
SA :
ServerAplicatie
WB2 :
BrowserWeb
PS1 :
ObtineListaCursuri
PC2 :
AlegeCurs
Curs 2
Transpunerea proceselor/firelor de execuie n mediul de

implementare
Anumite medii de implementare ofer suport ncorporat pentru procese,
infrastructur de comunicare i management de resurse
Adugarea elementelor n modelul de proiectare
Manageri de resurse
Biblioteci de clase, medii de dezvoltare
Interfee (API) etc.
Managerii de resurse se modeleaz sub form de clase de tip

<<process>> n vederea de proces
Se prezint clasele active gestionate de ctre acestea sau care rulez n
cadrul acestora
Curs 2
Exemplu de management al resurselor prezentat n

vederea de proces
Mecanism IPC :
COM
<<process>>
ApplicationServer
<<Server Page>>
ObtineListaCursuri
<<Server Page>>
<<process>>
TPM
<<Server Page>>
TrimiteInregistrare
<<thread>>
(din coordonatori)
IInregistrareWeb
(din coordonatori)
Curs 2
Exemplu de coresponden NFPr

Mai muli utilizatori trebuie s-i poat efectua activitatea n mod concurenial.
Mecanism IPC :
HTTP
<<process>>
BrowserWeb
<<Client Page>>
Inregistrare
(din paginile client)
Mecanism IPC :
COM
Mecanism IPC :
COM
<<process>>
ServerWeb
<<process>>
ServerAplicatie
<<process>>
TPM
<<submit>>
<<Server Page>>
TrimiteInregistrare
(din paginile server)
IInregistrareWeb
(din coordonatori)
<<thread>>
(din coordonatori)
<<Form>>
FormularAlegereSpecializare
Curs 2
Aspecte ce trebuie luate n considerare la elaborarea

vederii de proces
Set de responsabiliti echilibrat ntre procese
Distribuirea echilibrat a activitilor
Procese independente
Coeziune mare ntre clasele corespunztoare aceluiai proces
Legtur slab ntre clasele corespunztoare aceluaii proces
Se identific procesele care trebuie s se afle n acelai loc i se

evalueaz impactul
Trebuie identificate mesajele care se produc asincron, astfel nct
acestea s fie procesate atunci cnd sunt mai multe resurse disponibile
Curs 2
Aspecte ce trebuie luate n considerare la elaborarea

vederii de proces
Identificarea, evitarea i oferirea de soluii strategice n cazul apariiei
situaiilor concureniale (situaia proceselor n cazul resurselor
insuficiente)
Msurarea timpului de rspuns la mesaje
Respectarea cerinelor de performan/ncrcare
Identificarea punctelor slabe ale arhitecturii
Utilizarea resurselor partajate
Comunicaia interproces i interprocesor
Utilizarea memoriei fizice i virtuale
Curs 2
Corespondenele preluate pentru elaborarea vederii de

implementare
Vedere de proces
Vedere logic
LoIm
PrIm
Vederea de
implementare
Vederea cerinelor
non-funcionale
NFIm
Alegerea componentelor depinde

de cerinele sistemului de operare,
limbajul de programare i alte
tehnologii folosite
Clasele active sunt atribuite

componentelor care le implementeaz.
Clasele logice sunt atribuite

componentelor care le implementeaz.
Se stabilete modalitatea de
mpachetare a elementelor active.
Trebuie stabilit modalitatea de

mpachetare fizic a elementelor logice.
Curs 2
Aspecte ce trebuie avute n vedere la elaborarea

vederii de implementare
Elementele implementate mpreun sub forma unor uniti de
implementare
Organizarea echipei de programatori (afecteaz partiiile
vederii/modelului de implementare)
Elementele care se folosesc pentru pornirea funcionrii sistemului
Elementele reutilizabile (produse COTS)
Limbajele de programare utilizate la crearea elementelor
Dependena elementelor (unele de altele) n timpul funcionrii i n etapa
de construcie
Curs 2
Elaborarea vederii de implementare

Stabilirea componentelor de lucru
Stabilirea componentelor folosite n mediul real de funcionare
Realizarea corespondenei dintre componentele de lucru i
componentele folosite n mediul real de funcionare
Stabilirea componentelor de execuie
Stabilirea structurii modelului de implementare
Realizarea corespondenei dintre cerinele non-funcionale i
componente (corespondena NFIm)
Alegerea elementelor de implementare importante din punct de
vedere arhitectural
Curs 2
Stabilirea componentelor de lucru

Aspecte avute n vedere
mprirea activitilor de programare (organizarea echipei,
managementul configurrii)
Alegerea mediilor de implementare (limbaje de programare)
Configurri anticipate ale mediului real de funcionare (corespondena
ImPmrf)
Corespondena dintre elementele logice/de proces i componentele de
lucru (corespondenele LoIm, PrIm)
Etap intermediar a corespondenei dintre componentele de lucru i
componentele de punere n mediul real de funcionare)
Curs 2
Exemplu de transsformare a proceselor n componente

de lucru (corespondena PrIm)
Vederea de proces
<<process>>
(din catalogul de cursuri)
<<urmeaz>>
<<.CPP>>
ConectorCatalog
CursuriPrincipal
<<.H>>
TipuriDate
Domeniu
<<.H>>
TipData
Orb
<<.H>>
TipuriDateUniversitate
<<.CPP>>
ClaseORB
Curs 2
Transformarea elementelor logice n componente de

lucru i (corespondena LoIm)
Se stabilete felul n care se implementeaz fiecare clas (de
exemplu mai multe clase ntr-o component)
Corespondena LoIm poate fi obinut pe baza corespondenei LoPr
+ PrIm
Clasele active i pasive transformate n vederea de implementare pe
baza corespondenei PrIm
Clasele active i clasele pasive necesare trebuie s decid mpachetarea
claselor n cadrul componentelor de lucru.
Curs 2
Stabilirea componentelor la punerea n mediul real de

funcionare
Aspecte ce trebuie avute n vedere
Prile necesare pentru livrarea sistemului complet funcional
Decizii de partiionare fizic a sistemului (corespondena ImPmrf)
Fire de execuie identificate n vederea de proces (corespondena PrIm)
Alegeri privitoare la mediul de implementare (exemple: modelul
componentelor, sistem de operare)
Pri care se ateapt s se modifice n timp
Pri care se actualizeaz/se produc separat
Pri vzute ca elemente reutilizable
Curs 2
Stabilirea componentelor la punerea n mediul real de

funcionare
Folosind vederea de proces ca intrare, componentele de punere n
mediul real de funcionare provin din (corespondena PrIm):
Clase active. Trebuie definit o component care s gzduiasc fiecare
clas de tip <<process>>, precum i clasele aociate.
Resurse partajate. Trebuie s existe n propriile componente de punere n
mediul real de funcionare, astfel nct s poat fi partajate
Stabilirea unitilor de punere n mediul real de funcionare

Componentele de punere n mediul real de funcionare care trebuie s
lucreze mpreun
Curs 2
Transformarea componentelor de lucru n componente

de punere n mediul real de funcionare
Componentele de lucru necesare pentru obinerea componentelor de punere
n mediul real de lucru
Aspecte avute n vedere
Elementele de proces care se transform n componente de lucru (corespondena
PrIm)
Nu poate exista dect o singur component de lucru pentru fiecare component de punere n
mediul real de funcionare
Toate componentele de lucru care conin elementele necesare unui proces pentru a se putea
executa trebuie transformate n aceleai componente de punere n mediul real de funcionare
Curs 2
Exemplu de vedere de implementare avnd componente de lucru i

componente de punere n mediul real de lucru
Vederea de proces
<<process>>
(din lista de cursuri)
<<EXE>>
ConectorCat
alogCursuri
<<.CPP>>
ConectorCatalog
CursuriPrincipal
<<.H>>
TipuriDateUniversitate
<<urmeaz>>
<<.H>>
TipuriDate
Domeniu
<<.H>>
TipData
Orb
<<.CPP>>
ClaseOrb
Curs 2
Stabilirea componentelor de execuie
Sunt acele componente care exist n timpul funcionrii sistemului

Aspecte avute i vedere
Elementele vederii logice (corespondena LoIm)
Mecanismele de implementare alese pentru componentele de puenere n
Curs 2
Exemplu de prezentare a componentelor de execuie n

vederea de implementare (corespondena LoIm)
<<Client Page>>
Principala
Vederea logic
<<urmeaz>>
<<legatura>>
<<Client Page>>
IncepeInregistrare
<<Form>>
FormularCautareCurs
<<urmeaz>>
<<Form>>
FormularAlegereCurs
<<trimite>>
<<creeaza>>
<<Client Page>>
Inregistrare
<<Server Page>>
ObtineListaCursuri
<<trimite>>
<<creeaza>>
<<Client Page>>
AlegeCurs
<<trimite>>
<<Form>>
<<execution>>
FormularCautareCurs
<<Server Page>>
<<execution>>
FormularAelegereCurs
<<execution>>
<<urmeaz>>
<<Server Page>>
TrimiteInregistrare
Curs 2
Structurarea modelului de implementare

Crearea structurii iniiale a modelului de implementare
Se pornete pe baza structurii modelului de proiectare
Se ajusteaz structura pentru:

Organizarea echipei de programare
Declaraiile de tip
Cod i componente de subsistem existente
Ajustarea dependenelor
Stabilirea locului de amplasare a executabilelor
Curs 2
Exemplu de structur a modelului de implementare

Server de nregistrare
Pagini DU
Inregistrare COM
Componente DU
Inregistrare
Pagini client DU
Unitati de punere n
mediul real de
functionare
InterfataLAN
InterfataWeb
<<layer>>
InterfataUtilizator
Managementul
sesiunii
<<layer>>
LogicaDomeniu
<<layer>>
Servicii
Middleware
AccesBazaDate
Reutilizare
Coordonatori
AccesSistem
Existent
ArtefacteUniversitate
Curs 2
Exemplu de coresponden NFIm

Logica de prezentare este scris n Visual Basic
ASP
VBScripts
ObtineCurs
sVBScript
ObtineSpec
sVBScript
Inregistrare
VBScript
Curs 2
Important din punct de vedere arhitectural n vederea de

implementare
Structura/organizarea modelului
Partiii (straturi, pachete) mpreun cu dependenele
Componente principale/de baz

Uniti de punere n mediul real de funcionare
Componente de punere n mediul real de funcionare i componentele de lucru
asociate
Componentele de punere n mediul real de funcionare i componentele
asociate de execuie
Toate componentele asociate elementelor vederii logice (corespondena LoIm)
i elementelor vederii de proces (corespondena PrIm)
Componente reutilizabile (COTS)

Corespondenele necesare pentru crearea vederii de punere n mediul
real de funcionare
Curs 2
Vederea
Vederea de
logic
implementare
LoDe
Componentele sunt grupate n uniti i
se asociaz nodurilor.
Se stabilete distribuia fizic a

elementelor logice.
ImDe
Instanele componentelor sunt

ncrcate n memorie pentru execuie.
Vederea de punere
n mediul real
de funcionare
Elementele de proces sunt asociate

nodurilor fizice.
Elementele logice sunt asociate

nodurilor fizice.
Alegerea topologiei de reea este

influenat de platforma hardware
aleas sau de tehnologia de
comunicare.
PrDe
NFDe
Se stabilete distribuia fizic a

elementelor de proces.
Vederea cerinelor
Vederea de proces
non-funcionale
Curs 2
Aspecte ce trebuie avute n vedere la realizarea vederii

de punere n mediul real de funcionare
Alegerea componentelor hardware (procesoare, elemente de reea
etc.) necesare pentru funcionarea sistemului
Alegerea modului de conectare a nodurilor
Alegerea corespondenei dintre componentele/unitile de punere n
mediul real de funcionare i noduri
Stabilirea performanelor, cantitii de date ce trebuie procesate,
fiabilitii i disponibilitii sistemului
n general, vederea de punere n mediul real de funcionare se
preocup mai ales de aspecte de performan, cantitatea de
date ce trebuie procesate, tolerana la defectri,
disponibilitatea, instalarea i mentenana sistemului.
Curs 2
Elaborarea vederii de punere n mediul real de

funcionare
nelegerea cerinelor de distribuire
Stabilirea configuraiilor de reea
Niduri i conexiuni
Asocierea elementelor la noduri (corespondenele LoDe, PrDe, ImDe)

Obiecte, procese, componente
Transformarea cerinelor de distribuire n elemente de punere n

mediul real de funcionare (corespondena NFPmrf)
Curs 2
Necesitatea distribuirii
Reducerea ncrcrii procesorului
Cerine speciale de procesare de exemplu, procesarea digital de
semnal, unde este nevoie de procesoare specializate
Preocupri referitoare la scalabilitate un numr prea mare de
utilizatori concureni care nu poate fi suportat de ctre un singur
procesor
Preocupri de natur economic
Accesul distribuit la sistem
Performan
Tolerana la defectri
Curs 2
Elemente de modelare folosite n vederea de punere n

Nod
Resurs de calcul fizic folosit la execuie
<<Node>>
Nod #1
Nod de tip procesor

Execut aplicaia sistemului
Nod de tip dispozitiv
<<Processor>>
Procesor #1
Suport dispozitivul
De obicei este controlat de ctre un procesor
Conexiune
Conexiune
Mecanism de comunicare
Mediu fizic
<<Device>>
Dispozitiv #1
Protocol software
Curs 2
Exemplu de configuraie a reelei n vederea de punere

n mediul real de funcionare
IIOP
COM
<<UNIX>>
Server
plat
<<Windows>>
PC
<<LAN>>
<<LAN>>
<<NT>>
Server aplicaie
<<LAN>>
<<Sun>>
Server catalog
de cursuri
<<dialup>>
Windows 2000
IIS
ASP
MTS
Inregistrarea paginilor server
Inregistrarea componentelor COM
<<Windows>>
Staie Web
<<LAN>>
Sun Solaris v5.1
<<Sun>>
IE6
HTTP
ODBC
Server
baz
de date
Sun Solaris v5.1
Oracle 8 v3.3
Curs 2
abloane folosite la distribuire
Client/Server
Trei nivele
Activitatea de baz se desfoar la client
Activitatea de baz se desfoar la server
Peer-to-peer
Curs 2
Exemple de arhitecturi de tip client/server

Activitate desfutrat n cea mai mare parte la client, activitate desfurat n cea mai mare parte pe server
Client C
Client B
Client A
Aplicaie
Aplicaie
Servicii de domeniu
Browser Web
DCOM
CORBA Beans
ADO/R
Motorul
oiectului
Server de
obiecte
COM
MTS
Beans
ETS
Server
Web
HTML
CGI
ASP
Servicii oferite
de obiecte
Serviciile
obiectului
Motorul
obiectelor
Motorul
obiectului
Java
Servere de baze de date
n
n exemplul
exemplul de
de mai
mai sus,
sus, clientul
clientul A
A este
este un
un exemplu
exemplu de
de arhitectur
arhitectur pe
pe 22 nivele,
nivele, cu
cu cea
cea mai
mai mare
mare parte
parte aa logicii
logicii aplicaiei
aplicaiei plasat
plasat
pe
server.
Clientul
B
reprezint
o
arhitectur
tipic
pe
3
nivele
cu
serviciile
de
domeniu
plasate
ntr-un
server
de
obiecte.
Clientul
pe server. Clientul B reprezint o arhitectur tipic pe 3 nivele cu serviciile de domeniu plasate ntr-un server de obiecte. Clientul
C
C reprezint
reprezint oo aplicaie
aplicaie tipic
tipic Web.
Web.
Curs 2
Architectura peer-to-peer
Servicii
oferite de
aplicaie
Aplicaie
DCOM
CORBA Beans
ADO/R
COM
MTS
Servicii
oferite de
domeniu
Servicii de
date
Beans
ETS
Servicii oferite
de obiecte
Motorul
obiectelor
Aplicaie
DCOM
CORBA Beans
ADO/R
COM
MTS
Beans
ETS
Servicii oferite
de obiecte
Motorul
obiectelor
Curs 2
Evaluarea arhitecturii sfritul iteraiei de Elaborare

Grupul de activiti care se efectueaz pentru evaluare
Reevaluarea riscurilor
Corectarea eventualelor defecte
Detectarea eventualelor inadvertene dintre cerine i arhitectur (cerine
lips, cerine care nu au fost invocate etc.)
Evaluarea performanei, fiabilitii, securitii etc.
Identificarea posibilitilor de reutilizare
Condus de un grup de persoane (ARG Architecture Review Group)

desemnate s evalueze arhitectura elaborat
Arhitectul este membru al grupului ARG
Arhitectul nu conduce grupul ARG
Durata evalurii depinde de

Dimensiunea proiectului/sistemului
Numrul de iteraii
Curs 2
Algoritmul de evaluare a arhitecturii

Crearea grupului de evaluare a arhitecturii (ARG)
Stabilirea costului i duratei evalurii
Obinerea aprobrii de la persoanele interesate de bunul mers al proiectului
Colectarea informaiilor
Modelele de arhitectur elaborate
Lista ordonat dup periculozitate a riscurilor identificate
Specificaiile critice de funcionalitate
Criteriile de reuit (atributele de calitate stabilite)
Rezultatele testrii prototipului arhitectural
Justificri ale deciziilor cheie luate pe parcurs
(continuare)
Curs 2
Algoritmul de evaluare a arhitecturii

Crearea listei de verificare a elementelor de arhitectur
Evaluarea informaiilor arhitecturale
Iteraii
Evaluarea strategiilor de reducere a riscurilor
Evaluarea funciilor de baz ale sistemului
Evaluarea atributelor de calitate ale sistemului
Alte probleme de pe lista de verificare
Pn cnd se parcurg toate elementele din lista de verificare
Alctuirea profilului de calitate al arhitecturii

Discuii purtate cu cele mai semnificative persoane interesate de bunul mers
al proiectului
Curs 2
Profilul de calitate al arhitecturii

<Companie>
Funcionalitate
Performan
Uurina utilizrii
Securitate
Disponibilitate
Rapiditatea modificrilor
Mentenan
Portabilitate
Uuurina integrrii
Testabilitate
Prioriti
Prioritate: S sau s pentru calitate sczut
M sau m pentru calitate medie
I sau i pentru calitate ridicat
Satisfacie: 0 (zero) pentru nesatisfctor
1 pentru satisfctor
2 pentru foarte mulumit
Satisfacia
Administrator sistem
Conductorul echipei de programare
ntreinere
Programator
Arhitect
Vnzri i suport
<Proiect>
Client
Utilizator final
Persoane interesate de bunul mers al proiectului
Formularul
Formularul alturat
alturat a
a fost
fost
propus
propus de
de ctre
ctre Herman
Herman
Postema
Postema n
n lucrarea
lucrarea
Architecture
Architecture Assessment:
Assessment:
Approach
Approach and
and Experiences,
Experiences,
Proceedings
Proceedings of
of SPI
SPI 98
98,, Monte
Monte
Carlo,
Carlo, Dec.
Dec. 1998.
1998. Profilul
Profilul
prezint
prezint o
o evaluare
evaluare subiectiv
subiectiv
referitor
referitor la
la ndeplinirea
ndeplinirea
ateptrilor
ateptrilor persoanelor
persoanelor
interesate
interesate de
de bunul
bunul mers
mers al
al
proiectului.
proiectului. Profilul
Profilul conine:
conine:
calitile
calitile sistemului
sistemului care
care
se
se evalueaz;
evalueaz;
prioriti
prioriti subiective
subiective
atribuite
atribuite calitilor
calitilor de
de
ctre
ctre diferite
diferite persoane;
persoane;
nivelul
nivelul de
de satisfacie
satisfacie al
al
calitilor
calitilor
Curs 2
Verificarea cunotinelor
Care sunt informaiile de intrare la nceperea fazei de Elaborare?
Descriei, pe scurt, preocuprile/aspectele ce trebuie avute n vedere
de ctre un arhitect la elaborarea fiecrei vederi arhitecturale.
Descriei, pe scurt, modul de elaborare al fiecrei vederi arhitecturale.
Care sunt activitile prevzute pentru evaluarea arhitecturii
elaborate?

Curs 2

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Curs 2

Încărcat de

Drepturi de autor:

Formate disponibile

ARHITECTURA

PRINCIPII DE ARHITECTUR SOFTWARE

Documentul de arhitectur software

Ofer o imagine de ansamblu ce ajut la nelegerea arhitecturii

PRINCIPII DE ARHITECTUR SOFTWARE

Coninutul unui document de arhitectur

PRINCIPII DE ARHITECTUR SOFTWARE

Documentul cu reguli de proiectare

Dr. ing. Liviu PERNIU

PRINCIPII DE ARHITECTUR SOFTWARE

Arhitectul mai contribuie la

Testarea atributelor de calitate ale

Cantitatea de date ce trebuie

Planul de management al configurrilor

Testarea elementelor sensibile ale

Dr. ing. Liviu PERNIU

PRINCIPII DE ARHITECTUR SOFTWARE

Riscurile critice pot fi reduse sau eliminate

Dr. ing. Liviu PERNIU

PRINCIPII DE ARHITECTUR SOFTWARE

Este creat pentru a reduce riscurile identificate

PRINCIPII DE ARHITECTUR SOFTWARE

Definiia componentelor software

O component are sens doar n contextul:

Nu este obligatoriu s fie o singur unitate de cod

PRINCIPII DE ARHITECTUR SOFTWARE

Proveniena componentelor software

Elementele de infrastructur a componentelor

PRINCIPII DE ARHITECTUR SOFTWARE

Aspecte de reutilizare a componentelor

Dr. ing. Liviu PERNIU

PRINCIPII DE ARHITECTUR SOFTWARE

Aspecte de reutilizare a componentelor

Dr. ing. Liviu PERNIU

PRINCIPII DE ARHITECTUR SOFTWARE

Dr. ing. Liviu PERNIU

PRINCIPII DE ARHITECTUR SOFTWARE

abloane pentru analiz i proiectare

abloane la nivel de organizaie

Dr. ing. Liviu PERNIU

PRINCIPII DE ARHITECTUR SOFTWARE

Exemple de abloane de proiectare

Design Patterns: Elements of Reusable Object-Oriented

Dr. ing. Liviu PERNIU

PRINCIPII DE ARHITECTUR SOFTWARE

Aspectul unui ablon obinuit

PRINCIPII DE ARHITECTUR SOFTWARE

abloane de modelare a proiectului

Parametrii ablonului se folosesc pentru adaptarea colaborrii la o

PRINCIPII DE ARHITECTUR SOFTWARE

Exemplu de ablon de modelare a proiectului

PRINCIPII DE ARHITECTUR SOFTWARE

Exemplu: ablon de proiectare: ablon pentru Proxy

Dr. ing. Liviu PERNIU

PRINCIPII DE ARHITECTUR SOFTWARE

Exemplu: ablon de proiectare: ablon pentru Proxy

Dr. ing. Liviu PERNIU

PRINCIPII DE ARHITECTUR SOFTWARE

Exemplu: ablon de proiectare: Proxy: Vedere static

Dr. ing. Liviu PERNIU

PRINCIPII DE ARHITECTUR SOFTWARE

Exemplu: ablon de proiectare: Proxy: Vedere

Dr. ing. Liviu PERNIU

PRINCIPII DE ARHITECTUR SOFTWARE