1

Proiectarea Sistemelor Software Complexe

Curs 2 Indicatorii de Calitate ai Unui Sistem Software Complex



2.1 Context.

Orice arhitectur trebuie proiectat astfel nct s se asigure faptul c sunt respectate anumite
constrngeri impuse indicatorilor de calitate. n general indicatorii de calitate sunt: fiabilitatea,
scalabilitatea, performana i securitatea.
Indicatorii de calitate fac parte din cerinele non-funcionale ale unui sistem; prin intermediul acestor
indicatori se cuantific cum sunt ndeplinite cerinele funcionale. Orice sistem software complex are
astfel de cerine non-funcionale care sunt exprimate sub forma indicatorilor de calitate. Pentru a fi
utile, cerinele referitoare la indicatorii de calitate trebuie sa fie formulate clar i concret. O greeal
frecvent ntlnit n documentele care descriu arhitectura unui sistem este reprezentat de formulri
generice de genul: Sistemul trebuie sa fie scalabil. Acesta este o formulare imprecis care nu spune
prea multe. Nu este clar dac scalabilitatea se refer la numrul de conexiuni simultane, sau la numrul
de cereri simultane, sau la volumul mare de date, sau la toate aceste aspecte.
Definirea cu exactitate care dintre msurile de mai sus trebuie respectate de sistem este crucial pentru
proiectarea unei arhitecturi solide. Astfel o formulare corect ar fi: Sistemul trebuie s poat fi scalat n
ceea ce privete distribuirea de la 100 de utilizatori desktop aflai n locaii geografice diferite la 10.000
de utilizator fr a crete costul de instalare i configurare . Aceast formulare este mult mai precis,
astfel pentru un arhitect este clar c trebuie s gseasc o soluie care s permit instalarea i
distribuirea sistemului cu efort zero.

2.2 Performana (Performance)

Performana ca i indicator de calitate reprezint o msur care definete 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 aplicaii. Prima msur a performanei este important
pentru mai toate sistemele software din domeniul financiar, al telecomunicaiilor i guvernamental,
toate aceste aplicaii trebuind s proceseze sute, mii de tranzacii sau poate chiar zeci de mii de
tranzacii 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 consecine grave. Exist o serie de modaliti n care performana unui sistem poate fi
cuantificat acestea putnd varia de la o aplicaie la alta. n acest curs vor fi analizate trei modaliti de a
cuantifica performana unui sistem software: puterea de procesare, timpul de rspuns i termenul.



2
2.2.1 Puterea de Procesare (Throughput)

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 tranzacii pe secund (tps)
sau mesaje procesate pe secund (mps). De exemplu, o aplicaie de online banking poate s garanteze
procesarea a 1000 de tranzacii pe secund, iar o aplicaie pentru gestionarea inventarului poate s
proceseze 50 de mesaje pe secund.
Este important s se neleag 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 aplicaie 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 aplicaia
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.2.2 Timpul de Rspuns (Response Time)

Acest indicator msoar ntrzierea introdus de procesarea unei tranzacii. 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 aplicaii s fie
mai eficient, ceea ce evident este benefic pentru firma n care el lucreaz. Un exemplu sugestiv este o
aplicaie 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 afiarea 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 puin de patru secunde, iar o cerere nu
trebuie s dureze mai mult de 15 secunde.

2.2.3 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 apariia 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.


3
2.3 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 crete. 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 scalabilitii 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.3.1 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
cretere.
n cazul ideal dac nu se modific platforma hardware pe care ruleaz sistemul, pe msur ce numrul
de cereri crete, puterea de procesare a aplicaiei 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 condiii
suplimentarea puterii de calcul a platformei hardware pentru a crete puterea de procesare a
sistemului software i a micora 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 funcioneaz dac sistemul a fost proiectat ca i sistem multi-fir, sau dac mai multe
instane ale aplicaiei 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 execuie.
Scalarea n exterior funcioneaz dac efortul, necesar gestionrii distribuirii cererilor pe mai multe
maini, este redus sau n cazul ideal zero. Obiectivul principal este acela de a menine toate mainile pe
care ruleaz aplicaia 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 reinut este faptul c n ambele situaii scalabilitatea trebuie s se realizeze
fr a se modifica arhitectura sistemului. n realitate ns pe msur ce ncrcarea crete 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
cretere a competiiei pentru resurse (CPU i memorie) ntre procesele i fire de execuie de pe maina
pe care ruleaz aplicaia. 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 scalabilitii.



4
2.3.2 Numrul de Conexiuni Simultane (Simultaneous Connections)

Dac un sistem software a fost proiectat s suporte un numr de 1000 de utilizatori concureni se pune
problema cum va reaciona sistemul dac acest numr va crete 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.3.3 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 crete foarte mult? Sau n cazul unei
aplicaii 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.3.4 Distribuirea (Deployment)

n ceea ce privete distribuirea unei aplicaii intereseaz dac creterea numrului de utilizatori duce la
creterea efortului depus n vederea distribuirii i actualizrii aplicaiei. Ideal ar fi ca aplicaia s fie
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.4 Tolerana la Modificri (Modifiability)

Tolerana la modificri este un indicator care msoar ct este de uor sau dificil s se modifice sistemul
software pentru a implementa noi cerine funcionale sau non-funcionale. 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 aa 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.5 Securitatea (Security)

Cele mai uzuale cerine referitoare la securitate sunt urmtoarele:
- Autentificarea: aplicaia poate verifica identitatea utilizatorilor i a altor aplicaii cu care
comunic;
- Autorizarea: utilizatorii i aplicaiile autentificate au anumite drepturi de acces la resursele
sistemului;
- Criptarea: mesajele trimise de i ctre aplicaie 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.

5
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.6 Disponibilitatea (Availability)

Disponibilitatea unei aplicaii este strns legat de fiabilitate. Dac o aplicaie nu este disponibil atunci
cnd este nevoie de ea, atunci este puin probabil c aplicaia i ndeplinete rolul pentru care ea a fost
dezvoltat. Majoritatea aplicaiilor trebuie s fie disponibile cel puin n timpul orelor de lucru. Aplicaiile
Internet trebuie ns s fie disponibile 24 din 24. Disponibilitatea poate fi msurat ca i raportul de timp
n care aplicaia este utilizabil.
Apariia unei defeciuni face ca aplicaia s fie indisponibil. Defeciunile influeneaz fiabilitatea unei
aplicaii care se msoar ca fiind timpul mediu dintre apariia defeciunilor. De obicei sistemele software
care necesit o disponibilitate mare trebuie s nu conin aa numitul singur punct de defectare
(single point of failure) i s conin mecanisme care s detecteze defeciunea 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 defeciune la o component replicat sistemul poate s
funcioneze pentru c folosete celelalte replici ale componentei care nc funcioneaz. Se poate ns
ca performana sistemului s fie afectat de defeciune, 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 funcionare normali dup ce a
aprut o defeciune. Este de dorit ca defeciunea s fie detectat automat, iar procedura de recuperare,
de asemenea s fie iniiat 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.7 Integrarea (Integration)

Integrarea este un indicator care msoar uurina cu care sistemul poate fi incorporat ntr-un context
de aplicaii mai larg. De multe ori valoarea unei aplicaii poate fi mrit dac funcionalitatea 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 aa 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 funcii 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 restricionate 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 soluie este mai costisitoare dect prima, de aceea arhitectul trebuie s aleag soluia
care este potrivit pentru un anumit sistem software.

6

2.8 Ali Indicatori

Exist o serie de ali indicatori de calitate care pot fi importani pentru anumite tipuri de aplicaii, de
exemplu:
- Portabilitatea (Portability): uurina cu care o aplicaie poate fi executat pe diverse platforme
hardware i software, de obicei este dependent de tehnologia folosit pentru implementare;
- Testabilitatea (Testability): ct de uor sau dificil poate fi test o aplicaie; este bine ca
arhitectura s fie ct mai simpl;
- Suportabilitatea (Supportability): ct de uor se poate oferi suport pentru aplicaie odat ce a
fost scoas n producie; prin suport se nelege diagnosticarea i rezolvarea problemelor
aprute n timpul funcionrii; este bine ca un sistem s fie modular permind astfel
actualizarea doar a modulelor n care a fost gsit o problem.


Bibliografie

[1] Ian Gorton. Essential Software Architecture. Editura Springer. 2006.