Facultatea de Automatica, Calculatoare si Electronica

Master Ingineria Calculatoarelor si Comunicatiilor

Metrici de performan software

Aprecierea calitativ a performanei software

Profesor:
Mihai Mocanu
Student:
Cojocaru Adina

Cuprins

Facultatea de Automatica, Calculatoare si Electronica

Master Ingineria Calculatoarelor si Comunicatiilor

1. Metrici de performan software.....................................................................3

1.1. Definiie matematic a Metricii
Software...............................................3
1.2. Functii
indeplinite ...................................................................................4
1.3. Definitia Software-ului. Metrici
Software...............................................5
2. Aprecierea calitativ a performanei software.................................................6
2.1.1. Performana (Performance)............................................................6
2.1.2. Puterea de Procesare (Throughput)................................................7
2.1.3. Timpul de Rspuns (Response Time).............................................7
2.1.4. Termenul(Deadline)........................................................................8
2.2. Scalabilitatea...........................................................................................
.8
2.2.1. Numrul de Cereri Simultane (Request Load)...............................8
2.2.2. Numrul de Conexiuni Simultane (Simultaneous Connections)....9
2.2.3. Dimensiunea Datelor (Data Size)...................................................9
2.2.4. Distribuirea (Deployment)..............................................................9
2.3. Tolerana la Modificri
(Modifiability) ................................................10
2.4. Securitatea
(Security)............................................................................10
2.5. Disponibilitatea
(Availability)...............................................................10
2.6. Integrarea
(Integration)..........................................................................11
Bibliografie......................................................................
.................................12

Facultatea de Automatica, Calculatoare si Electronica

Master Ingineria Calculatoarelor si Comunicatiilor

1. Metrici de performan software

Metricile software sunt modele(reguli) folosite pentru a msura cantitativ anumite caracteristici ale
sistemelor informatice. Metricile software inglobeaz modele, indicatori i proprietaile acestora, precum
i modaliti de evaluare i validare. Metricile software se folosesc pentru a reduce subiectivitatea
aprecierii unui program.

1.1.

Definiie matematic a Metricii Software:

Metrica software este un model matematic dezvoltat n jurul unei ecuaii de forma:
y = f( x )
Un model matematic cuprinde una sau mai multe ecuaii, inecuaii i are una sau mai multe funcii
obiectiv, iar rolul lui este de a descrie starea sistemului asociat. Metrica software are rolul de a msura o
anumit caracteristic a unui produs program, lund n calcul factorii ce influeneaz nivelul
caracteristicii masurate. Aplicndu-se tuturor produselor software dintr-un lot omogen, metrica devine
instrumentul prin intermediul cruia se efectueaz clasificri i ierarhizri ale produselor software. O
metric software este funcie obiectiv a modelului matematic cruia i aparine, dac prin aplicarea ei se
are n vedere maximizarea sau minimizarea nivelului caracteristicii cercetate n funcie de toi factorii de
influen:
f(X) < sau f(X) >
unde:
X vectorul factorilor ce influeneaz caracteristica software masurat;
si niveluri limit admise.
Metrica software este restricie a modelului matematic daca plaseaz nivelul msurat al caracteristicii ntrun interval definit de:
< f(X) <
In timp ce modelul matematic are ca obiectiv definirea structurii software, metrica creeaz condiiile care
permit compararea i are caracter normativ.

Facultatea de Automatica, Calculatoare si Electronica

Master Ingineria Calculatoarelor si Comunicatiilor

Gestionarea eficient a oricrui proces necesit cuantification, measurement, and modeling.tificare,

msurare, i modelare. Software Metricile software ofer o baz cantitativ pentru dezvoltareaacceptance.
ment and validation of models of the software devel-i validarea modelelor procesului de dezvoltare
software. Metrics can be used to improve Metricile pot fi utilizate pentru mbuntireaFaced with this
situation, the author has chosen to software productivity and quality. productivitatii i calitatii software.
This module in- and reviews their use in constructing models of the Although currentDei
curentsumptions, environment of application, and validity metrics and models are certainly inadequate, a
num- msurtorile i modelele sunt cu siguran inadecvate, un numarber of organizations are achieving
promising results de organizaii au rezultate promitoarethrough their use. prin utilizarea lor.

1.2.

Funcii indeplinite

Metricile software au rolul de a realiza:

Funcia de msurare. Cu siguran cea mai important funcie a metricilor software, msurarea
reprezint obiectivul principal n jurul cruia sunt dezvoltate aceste instrumente. Produsele software
aparin unui domeniu strict obiectiv, n care orice realizare are fundamente matematice i caracteristici
descrise de valori numerice, deci care sunt msurabile i reprezentate prin numere.
Funcia de comparare. Scopul final al utilizrii metricilor software este de a analiza din punctul de
vedere al unei caracteristici software un program i de a-l compara cu el nsui , ncadrndu-l ntr-o
categorie definit de programe, sau de a-l compara cu alte produse software, plasndu-l pe o anumit
treapt din ierarhia software.
Funcia de analiz. Rezult din dorina de a da semnificaie rezultatelor numerice obinute prin aplicarea
modelelor matematice asociate metricilor. n finalul analizei, pe baza numerelor obinute, produsului
software i se confer caliti ca fiabilitate, economie de timp, economie de resurse, caliti care sunt mult
mai puternice i mai semnificative dect simplele valori numerice din care sunt deduse.
Funcia de estimare. Metrica software, asemenea indicatorilor statistici, este folosit pentru msurarea
tendinei de cretere/scdere a nivelului caracteristicii software cercetate, plecndu-se de la ipoteza c
variabilele sunt aceleai.

Facultatea de Automatica, Calculatoare si Electronica

Master Ingineria Calculatoarelor si Comunicatiilor
Funcia de verificare. Rezultatele obinute aplicnd metrica software sunt totodat utilizate pentru a
confirma i ntri sau pentru a infirma concluziile obinute prin alte metode. Utilizarea unei metrici
software n practic implic ipoteza validrii acesteia i asigurarea independenei rezultatelor.

1.3.

Definitia Software-ului. Metrici Software

Este important s se defineasc n continuare software-ul. Essentially, software n esen, softwareul metrics deals with the measurement of the software se ocup cu msurtorile produsului software part
of a larger area that might be called softwareproduct and the process by which it is developed.i a
procesului prin care acesta este dezvoltat. In n this discussion, the software product should be aceast
discuie, produsul software ar trebui s fie confine itself to software metrics as defined above.viewed as
an abstract object that evolves from an privit ca un obiect abstract care evolueaz de la oinitial statement
of need to a finished software sys- declaraie iniial de necesitate la un sistem software terminat tem,
including source and object code and the, inclusiv codul surs i codul obiect i various forms of
documentation produced during de-diverse forme de documentare produse n timpul de velopment.
dezvoltare.
Ordinarily, these measurements of the n mod obinuit, aceste sunt studiate i dezvoloped for use in
modeling the software developmenttate pentru utilizarea n modelarea de procese software. process.
These metrics and models are then used toAceste valori i modele sunt apoi folosite pentru a
estimate/predict product costs and schedules and to estima / anticipa costurile produselor i s (either
source or object code), or the number of measure productivity and product quality. msoare
productivitatea i calitatea produselor. Informa- Informatiile tion gained from the metrics and the model
can then obinute din msurtori apoi pot fi utilizate n gestionarea i controlul dezvoltarii software of
poor quality, andopment process, leading, one hopes, to improvedprocesului de mbuntire a results.
rezultatelor. Good metrics should facilitate the development of
Msurtorile bune ar trebui s faciliteze dezvoltarea de .models that are capable of predicting
process ormodelele care sunt capabile de a prezice un proces sau product parameters, not just describing
them. parametrii de produs, nu doar a le descrie. Thus, Astfel, metricele ideale ar trebui sa fie simple si

Facultatea de Automatica, Calculatoare si Electronica

Master Ingineria Calculatoarelor si Comunicatiilor
precis definite, astfel nct s fie clear how the metric can be evaluated; clar cum o metrica poate fi
evaluat:

objective, to the greatest extent possible;obiectiv, n cea mai mare msur posibil; products,
and higher productivity. easily obtainable ( ie , at reasonable cost);

cu un cost rezonabil

uor de obinut

validthe metric should measure what itmetrica ar trebui s msoare ceea ce is intended to
measure; and este destinat s msoare

robustrelatively insensitive to (intuitive-insensibila la ly) insignificant changes in the process

or modificri nesemnificative n procesul de dezvoltare al produsului. product. In addition, for
maximum utility in analytic studies
.scales

. Caliti fundamentale required of any technical system are necesare pentru orice sistem tehnic sunt:

functionalitycorrectness, reliability, etc.; funcionalitate,corectitudine, fiabilitate

performanceresponse time, throughput, performan, timp de rspuns, debit, speed, etc.;

andviteza

economycost effectiveness. Cost scazut, eficacitate.

Metricile software s-au definit pe baza a trei surse: metrici bazate pe textul surs, metrici bazate pe

graful asociat programului, metrici de comportament care nregistreaz niveluri ale parametrilor n timpul
execuiei programului.
Caracteristici:
Simplitate: Definirea si utilizarea metricilor este una simpla.
Obiective: Masuratori facute de persone diferite au acelasi rezultat.
Usor de colectat: Efortul si costurile colectarii datelor necesare este acceptabil.
Robuste: Sunt insensitive la schimba minore permitand comparatii utile.
Valide: Masuratorile facute evidentiaza situatia reala.

Facultatea de Automatica, Calculatoare si Electronica

Master Ingineria Calculatoarelor si Comunicatiilor
Exemple de Metrici
1.

Numar de linii de cod

2.

Densitatea comentariilor

3.

Fiabilitatea

4.

Mentenanta

5.

Testabilitate

6.

Interoperabilitate

7.

Corectitudine

8.

Consistenta

9.

Lizibilitate

10.

Bug-uri pe numarul e linii de cod

11.

COCOMO (COnstructive COst Model)

2. Aprecierea calitativa a performantei software

2.1.1. Performana
Performana ca i indicator de calitate reprezint o msur care define te fie volumul de procesri pe
care o aplicaie trebuie s l poat face pe unitatea de timp sau termenul (deadline-ul) care trebuie
respectat pentru finalizarea corect a unei aplica ii. Prima msur a performan ei este important pentru
mai toate sistemele software din domeniul financiar, al telecomunica iilor i guvernamental, toate aceste
aplicaii trebuind s proceseze sute, mii de tranzac ii sau poate chiar zeci de mii de tranzac ii pe secund.
A dou msur a performanei este important pentru aplicaiile de timp-real care sunt ntlnite mai ales
n domeniul militar; pentru acest tip de aplicaii ntrzieri de o milisecund pot avea consecin e grave.
Exist o serie de modaliti n care performana unui sistem poate fi cuantificat acestea putnd varia de la
7

Facultatea de Automatica, Calculatoare si Electronica

Master Ingineria Calculatoarelor si Comunicatiilor
o aplicaie la alta. n acest curs vor fi analizate trei modalit i de a cuantifica performan a unui sistem
software: puterea de procesare, timpul de rspuns i termenul.
2.1.2. Puterea de Procesare
Puterea de procesare (throughput) reprezint o msur a volumului de procesri care trebuie realizate
n unitatea de timp. Volumul de procesri se msoar de cele mai multe ori n tranzac ii pe secund (tps)
sau mesaje procesate pe secund (mps). De exemplu, o aplica ie de online banking poate s garanteze
procesarea a 1000 de tranzacii pe secund, iar o aplica ie pentru gestionarea inventarului poate s
proceseze 50 de mesaje pe secund. Este important s se n eleag ce se specific prin puterea de
procesare. Astfel ntr-un anumit context poate fi vorba de puterea de procesare medie calculat pentru un
anumit interval de timp sau poate fi vorba de un vrf de procesare. Aceste dou lucruri sunt diferite i
influeneaz n mod diferit arhitectura sistemului. Un exemplu elocvent este reprezentat de o aplica ie
online care prea pariuri. n majoritatea timpului puterea de procesare necesar este foarte mic ntruct nu
se ntmpl mai nimic. Situaia se schimb ns atunci cnd are loc o curs de cai, astfel nainte cu 10-5
minute de nceputul cursei aplicaia poate sa primeasc pn la cteva sute ce cereri. n acest caz este
crucial ca aplicaia sa poat s proceseze n timp util toate cererile primite altfel afacerea va avea de
suferit. De aceea n acest scenariu aplica ia trebuie s fie proiectat astfel nct s asigure o putere de
procesare care s satisfac un vrf de cereri i nu un volum mediu.
2.1.3.Timpul de Rspuns (Response Time)
Acest indicator msoar ntrzierea introdus de procesarea unei tranzac ii. Timpul de rspuns este de cele
mai multe ori msurat ca timpul necesar unui sistem software pentru a rspunde la o anumit modificare
aprut la intrrile sistemului. Un timp de rspuns mic face ca utilizatorul unei aplica ii s fie mai eficient,
ceea ce evident este benefic pentru firma n care el lucreaz. Un exemplu sugestiv este o aplica ie de tip
punct de vnzare folosit pentru un magazin de tip supermarket. Astfel atunci cnd este scanat un articol
un rspuns rapid, de o secund sau mai puin, pentru afi area preului nseamn c, clientul va fi servit
rapid. i n acest caz este important s se disting ntre valoarea medie a acestui indicator i cea garantat.
Unele aplicaii necesit ca toate cererile s fie tratate ntr-un anumit interval de timp, ceea ce nseamn c
este vorba de un timp de rspuns garantat. Altele ns pot s specifice valori medii pentru timpul de
rspuns ceea ce nseamn c ntrzieri mai mari sunt permise atunci cnd sistemul este foarte ncrcat. n
acest ultim caz se mai poate impune o restricie de tip limit superioar pentru timpul de rspuns. De
exemplu se poate cere ca 95% din cereri s fie tratate n mai pu in de patru secunde, iar o cerere nu
trebuie s dureze mai mult de 15 secunde.

Facultatea de Automatica, Calculatoare si Electronica

Master Ingineria Calculatoarelor si Comunicatiilor

2.1.4.Termenul(Deadline)
Acest indicator msoar intervalul de timp n care sistemul software trebuie s finalizeze un anumit task,
finalizarea taskului dup expirarea termenului fiind echivalent cu apari ia unei erori n sistem. Acest
indicator este specificat n special pentru sistemele software de timp real. Astfel de sistem fiind ntlnite
chiar i n sistemul bancar, de exemplu, o tranzacie efectuat la un bancomat este considerat invalid
dac dureaz mai mult dect o perioad de timp specificat.
2.2.1. Scalabilitatea
Scalabilitatea reprezint un indicator ce msoar ct de bine se comport sistemul dac dimensiunea
problemei pentru care el a fost proiectat s o rezolve cre te. Pentru ca acest indicator s devin unul
concret este necesar s se stabileasc ce poate s creasc. Proiectarea sistemelor software scalabile nu este
un lucru uor. De foarte multe ori necesitatea pentru scalabilitate nu este evident nc de la nceput. Este
foarte important ca arhitectul s nu introduc n nucleul arhitecturii structuri care nu sunt scalabile. Chiar
dac scalabilitatea este prevzut ca i o cerin pentru sistem de cele mai multe ori testarea scalabilit ii
sistemului nu se poate realiza fie pentru c este prea costisitor din punct de vedere financiar fie fiindc
agenda proiectului nu permite acest lucru. n continuare vor fi prezentate cteva exemple de indicatori
concrei care exprim scalabilitatea unui sistem.

2.2.2. Numrul de Cereri Simultane (Request Load)

Considerm o aplicaie care pe o anumit platform hardware garanteaz o putere de procesare de 100 tps
i un timp mediu de rspuns de o secund. Dac numrul de cereri simultane pentru acest sistem software
crete de zece ori se pune ntrebarea dac arhitectura sistemului poate suporta o astfel de cre tere. n cazul
ideal dac nu se modific platforma hardware pe care ruleaz sistemul, pe msur ce numrul de cereri
crete, puterea de procesare a aplica iei ar trebuie s rmn constant (100 tps), iar timpul de rspuns ar
trebui s creasc liniar (10 s). O arhitectur scalabil ar permite n aceste condi ii suplimentarea puterii de
calcul a platformei hardware pentru a crete puterea de procesare a sistemului software i a mic ora
timpul de rspuns. Suplimentarea puterii de calcul se poate realiza n dou feluri: (1) adugarea mai
multor procesoare i probabil mai mult memorie (scalare n sus scale up) sau (2) distribuirea sistemului
software pe mai multe maini (scalare n exterior scale out). Scalarea n sus func ioneaz dac sistemul
9

Facultatea de Automatica, Calculatoare si Electronica

Master Ingineria Calculatoarelor si Comunicatiilor
a fost proiectat ca i sistem multi-fir, sau dac mai multe instan e ale aplica iei pot fi executate n paralel
pe aceeai main. Ultima variant ns va consuma mai mult memorie ntruct procesele sunt mult mai
costisitoare n ceea ce privete consumul de resurse dect firele de execu ie. Scalarea n exterior
funcioneaz dac efortul, necesar gestionrii distribuirii cererilor pe mai multe ma ini, este redus sau n
cazul ideal zero. Obiectivul principal este acela de a men ine toate ma inile pe care ruleaz aplica ia la fel
de ncrcate n caz contrar investiia n hardware-ul suplimentar este irosit. Distribuirea ncrcrii n mod
egal pe mai multe maini poart numele de load-balancing. Un lucru foarte important de re inut este
faptul c n ambele situaii scalabilitatea trebuie s se realizeze fr a se modifica arhitectura sistemului.
n realitate ns pe msur ce ncrcarea cre te se va constata o scdere a puterii de procesare a sistemului
i o cretere exponenial a timpului de rspuns. Acest lucru se ntmpl din dou motive. Primul motiv
este acela c, creterea numrului de cereri duce la o cre tere a competi iei pentru resurse (CPU i
memorie) ntre procesele i fire de execuie de pe ma ina pe care ruleaz aplica ia. Al doilea motiv este
acela c fiecare cerere consum resurse suplimentare, iar n cele din urm se va ajunge la epuizarea
resurselor i evident la limitarea scalabilit ii.
2.2.3. Numrul de Conexiuni Simultane (Simultaneous Connections)
Dac un sistem software a fost proiectat s suporte un numr de 1000 de utilizatori concuren i se pune
problema cum va reaciona sistemul dac acest numr va cre te foarte mult. Avnd n vedere c orice
conexiune va consuma resurse este evident c numrul de conexiuni va fi limitat. De exemplu, dac o
aplicaie creeaz cate un proces pentru fiecare conexiune este evident c resursele se vor termina relativ
repede, procesele fiind mari consumatoare de resurse.

2.2.4. Dimensiunea Datelor (Data Size)

Acest indicator evalueaz performanele unui sistem software atunci cnd dimensiunea datelor procesate
crete. De exemplu, o aplicaie de instant messaging este proiectat s prelucreze mesaje text scurte, dar
ce se ntmpla daca dimensiunea acestor mesaje cre te foarte mult? Sau n cazul unei aplica ii care caut
informaii ntr-o arhiva de date de dimensiuni specificate, se pune ntrebarea ce se ntmpl dac
dimensiunea arhivei crete n ceea ce privete cantitatea de date stocat n ea.
2.2.5. Distribuirea (Deployment)
n ceea ce privete distribuirea unei aplicaii intereseaz dac cre terea numrului de utilizatori duce la
creterea efortului depus n vederea distribuirii i actualizrii aplica iei. Ideal ar fi ca aplica ia s fie
10

Facultatea de Automatica, Calculatoare si Electronica

Master Ingineria Calculatoarelor si Comunicatiilor
distribuit i actualizat printr-un mecanism automatizat, care s poat distribui i configura dinamic
aplicaia la un nou client sau s o actualizeze pentru un client vechi.

2.3. Tolerana la Modificri (Modifiability)

Tolerana la modificri este un indicator care msoar ct este de u or sau dificil s se modifice sistemul
software pentru a implementa noi cerine funcionale sau non-func ionale. Pentru a se evalua acest
indicator se pot anticipa posibile modificri, de cele mai multe ori astfel de modificri sunt precizate chiar
n cerinele sistemului. Dup ce au fost identificate posibilele modificri trebuie s se evalueze impactul
pe care modificrile l vor avea asupra arhitecturii sistemului. n final calculndu-se costul implicat pentru
realizarea acestor modificri. Arhitectura unui sistem trebuie proiectat n a a fel nct modificrile
ulterioare care sunt probabile s implice doar modificri locale la nivel de componente. Dac se constat
c o modificare ulterioar care este probabil implic modificri n lan , atunci este nevoie de o regndire
a arhitecturii ntregului sistem.
2.4. Securitatea (Security)
Cele mai uzuale cerine referitoare la securitate sunt urmtoarele:
- Autentificarea: aplicaia poate verifica identitatea utilizatorilor i a altor aplica ii cu care comunic;
- Autorizarea: utilizatorii i aplicaiile autentificate au anumite drepturi de acces la resursele sistemului;
- Criptarea: mesajele trimise de i ctre aplica ie sunt criptate;
- Integritatea: asigur faptul c, coninutul unui mesaje nu este modificat n timpul transmisiei;
- Nerepudierea: expeditorul unui mesaj este sigur c mesajul a ajuns la destinatar, iar destinatarul este
sigur de identitatea expeditorului.
Exist o serie de tehnologii care sunt folosite n prezent pe scar larg i care ofer suport pentru aceste
aspecte ale securitii unei aplicaii. De exemplu, Secure Socket Layer (SSL) i Public Key Infrastructure
(PKI) sunt folosite foarte des pentru aplicaiile Internet pentru a garanta autentificarea, criptarea i
nerepudierea. Autentificarea i autorizarea sunt suportate in Java prin Java Authentication and
Authorization Service (JAAS). i exemplele pot continua.
2.5. Disponibilitatea (Availability)
Disponibilitatea unei aplicaii este strns legat de fiabilitate. Dac o aplica ie nu este disponibil atunci
cnd este nevoie de ea, atunci este puin probabil c aplica ia i ndepline te rolul pentru care ea a fost
dezvoltat. Majoritatea aplicaiilor trebuie s fie disponibile cel pu in n timpul orelor de lucru. Aplica iile
Internet trebuie ns s fie disponibile 24 din 24. Disponibilitatea poate fi msurat ca i raportul de timp
11

Facultatea de Automatica, Calculatoare si Electronica

Master Ingineria Calculatoarelor si Comunicatiilor
n care aplicaia este utilizabil. Apari ia unei defec iuni face ca aplica ia s fie indisponibil. Defec iunile
influeneaz fiabilitatea unei aplicaii care se msoar ca fiind timpul mediu dintre apari ia defec iunilor.
De obicei sistemele software care necesit o disponibilitate mare trebuie s nu con in a a numitul singur
punct de defectare (single point of failure) i s con in mecanisme care s detecteze defec iunea
automat i s reporneasc componenta defectat. Replicarea componentelor este o metoda eficient de a
crete fiabilitatea i evident disponibilitatea unui sistem software. Astfel, atunci cnd apare o defec iune la
o component replicat sistemul poate s funcioneze pentru c folose te celelalte replici ale componentei
care nc funcioneaz. Se poate ns ca performan a sistemului s fie afectat de defec iune, dar el va fi
totui disponibil. Recuperarea dup apariia unei defeciuni afecteaz de asemenea disponibilitatea
sistemului. Un sistem software are capacitatea de a se recupera dac el revine la parametrii de func ionare
normali dup ce a aprut o defeciune. Este de dorit ca defec iunea s fie detectat automat, iar procedura
de recuperare, de asemenea s fie ini iat automat. Avnd n vedere c pe parcursul ct se execut
procedura de recuperare sistemul nu este disponibil, este de dorit ca aceast procedur s fie ct mai
scurt ca durat.
2.5. Integrarea (Integration)
Integrarea este un indicator care msoar u urin a cu care sistemul poate fi incorporat ntr-un context de
aplicaii mai larg. De multe ori valoarea unei aplicaii poate fi mrit dac func ionalitatea sau datele
produse de aplicaie pot fi folosite n alte moduri dect cele care au fost prevzute de cel care a proiectat
aplicaia. Cele mai folosite strategii de integrare sunt cele la nivelul datelor sau cele realizate printr-o
interfa API. Integrarea la nivelul datelor se poate realiza prin stocarea i manipularea datelor n a a fel
nct alte aplicaii s le poat accesa. De exemplu, poate s fie suficient s se foloseasc o baza de date
relaionat pentru stocarea datelor sau poate s fie nevoie de implementarea unei func ii care s permit
exportarea datelor ntr-un format cunoscut (XML sau CSV). Singurul dezavantaj al integrrii la nivelul
datelor l constituie faptul c, aplicaiile care vor accesa datele nu mai sunt restric ionate n nici un fel i
pot modifica datele fr s respecte anumite reguli. Pentru a se evita acest lucru se poate dezvolta o
interfaa API prin intermediul creia s se poat accesa datele, n acest fel putnd fi respectate anumite
reguli, n plus se poate asigura i o anumit securitate. Evident aceast a doua solu ie este mai costisitoare
dect prima, de aceea arhitectul trebuie s aleag solu ia care este potrivit pentru un anumit sistem
software.

12

Facultatea de Automatica, Calculatoare si Electronica

Master Ingineria Calculatoarelor si Comunicatiilor

Bibliografie

1. https://www.google.com/url?
sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CB0QFjAA&url=http%3A
%2F%2Fstst.elia.pub.ro%2Fnews%2FIS%2FTeme%2520IS
%25202011_12%2FBalint%2520Iliuta%2520441A%2520METRICI%2520ALE
%2520COMPLEXITATII
%2520SOFTWARE.doc&ei=32RjVbv6KYSz7AbD04PAAQ&usg=AFQjCNFKPW6Z6XgVpjWO19wyOt2P2zNw&sig2=CL30K_tS1r7GS1kIEg6OhA&bvm=bv.93990622,d.Z
GU&cad=rja
2. http://www.aut.upt.ro/staff/diercan/data/PSSC/curs-02.pdf

13