Curs IP

Curs 1, 2

Analiza cerintelor – rezolvarea posibilelor conflicte intre cererile utilizatorului si

prioritizarea clientilor (rezulta Software Requirements Documents)
Proiectarea arhitecturala – se stabileste arhitectura sistemului, se definesc
subsiteme si interefete, se aleg tehnologii software care vor fi folosite si
componentele hardware (rezulta Architectural Design Document)

Extragerea cerintelor

Se desfasoara in fazele de inceput a procesului de dezvoltare, scopul fiind de a

identifica si defini cerintele utilizatorului. Acesta poate continua pe intreg
parcursul procesului de dezvoltare.
Se fac studii de piata (exista produse similare? ce putem aduce nou?), studii de
fezabilitate (putem face asta si sa nu ramanem fara bani?) si se determina
domeniul in care va opera produsul (bancar, control in timp real, clinic).
Pasi extragere cerinte:
 Identificarea actorilor (utilizatori, echipamente)
 Identificarea scenariilor de utilizare
 Definirea cazurilor de utilizare
 Rafinarea cazurilor de utilizare
 Identificarea relatiilor dintre cazurile de utilizare
 Identificarea si definirea cerintelor nefunctionale (constrageri de
performanta, consum de resurse, securitate)
Identificarea si reprezentarea relatiilor dintre cazurile de utilizare

Includere – cazul A include comportamentul descris de cazul

B; exemplu: operatia de Imprumut (A) are nevoie ca
utilizatorul sa fie Autentificat (B)
Extindere – cazul E extinde un caz de utilizare A, daca A poate include E, numai in
anumite cazuri (care nu-s extinse); exemplu: cautarea
avansata este e extindere a cautarii de baza
Generalizare/specializare – B este o specializare a lui A;
exemplu: Executie tranzactii (A) este specializat in
Depunere bani sau Retragere numerar (B)

In UML, reprezentarea unui set de cazuri de utilizare si a relatiilor dintre ele se

numeste diagrama de cazuri de utilizare.
Diagrama de context cuprinde toate cazurile de utilizare ale unui sistem si actorii.
Delimiteaza sistemul de mediul sau de operare.
Cerinte nefunctionale

Cerinte ce nu pot fi asociate cu un caz de utilizare specific (constrangeri

software/hardware/legislative), cerinte de calitate a produsului (fiabilitate,
portabilitate) sau cerinte de planificare a proiectului (termene limita, resurse
necesare).
1. Cerinte de performanta
 Valori numerice precum viteza, capacitate, precizie (exemplu un
sistem care masoara temperatura cu precizie de 0.1 grade)
2. Cerinte de interfata
 Componente hardware/software cu care interactioneaza produsul
 Interfete interne/externe ale produsului
 Se definesc prin protocoale de comunicatie, fluxul de date prin
interfete si evenimente ce declanseaza schimbul de date prin
interfete
3. Cerinte de operare (practic UX)
 Descrierea dialogului cu utilizatorul
 Stilul limbajului de comenzi
 Aspectul ecranului in timpul dialogului
4. Cerinte impuse resurselor fizice
 Puterea de prelucrare, memoria necesara, spatiu pe disc
5. Cerinte de intretinere
 Usurinta de reparare a erorilor, de imbunatatire si adaptare la
schimbarea cerintelor
6. Cerinte de fiabilitate
 Frecventa acceptata a caderilor software
7. Cerinte de portabilitate
8. Cerinte de securitate
 Erori utilizator (distrugerea datelor)
 Malware
 Acces neautorizat
9. Cerinte legislative
10.Cerinte de asigurare a calitatii
Analiza cerintelor

Este responsabilitatea dezvoltatorului sa analizeze cerintele.

Scopuri:
 Descoperirea erorilor din cerintele formulate (care vor fi apoi revizuite)
 Rezolvarea conflictelor dintre cerintele diferitelor tipuri de utilizatori sau
dintre cerintele functionale si ne-functionale
 Clasificarea cerintelor dupa diferite criterii – operationale, importanta,
stabilitate
 Structurarea si formalizarea cerintelor extrase (permite descoperirea
erorilor si rezolvarea problemelor dificile inca de la inceput)
Rezultatul este un model de analiza, adica un model conceptual al sistemului. Intr-
o analiza OOD, modelul conceptual e alcatuit din clase si obiecte. Acest model
cuprinde modelul obiect – clase, diagrame de clase si obiecte si modelul dinamic –
diagrame de interactiune si de stari.
O diagrama de interactiune reprezinta interactiunile dintre un set de obiecte/un
actor si sistemul in timpul unui singur scenariu (flux de evenimente). O diagrama
de stari reprezinta comportarea in timp a unui obiect dintr-o clasa de obiecte.
Avantajele unei bune specificatii a cerintelor software:
 Documentul sta la baza contractului dintre client si dezvoltator
 Reduce efortul de dezvoltare
 Sta la baza estimarii costurilor si planificarii procesului de dezvoltare
 Permite planificarea testelor de sistem
Aproximativ 20-25% din timpul total al proiectului trebuie alocat extragerii,
analizei si specificarii cerintelor.
Diagrame de interactiune

Diagrama de secventa contine obiectele si actorii care participa la o interactiune

intr-un caz de utilizare + secventa de mesaje schimbate intre obiecte (intre
ele)/obiecte si actori.

Reprezentarea obiectelor in UML

Comportamentul unui obiect este reprezentat prin operatii.
Operatiile unui obiect sunt declansate prin mesaje trimise de alte obiecte.
Un mesaj arata cum un obiect cere altui obiect sa realizeze o operatie. Exista mai
multe tipuri de mesaje:

Mesajele sincrone blocheaza expeditorul pana se termina operatia (aia cu - - -), iar
cele asincrone (dreapta) nu intrerup executia expeditorului.

Mesajele mai pot fi conditionale (if-uri) sau repetitii.

Diagramele de colaborare sunt echivalente diagramelor de secventa, dar
evideniaza relatiile structurale dintre obiecte (legaturi dintre ele).
Curs 3

Clase
Reprezinta un grup de obiecte care au proprietati similare (atribute), un
comportament comun (operatii), relatii comune cu alte obiecte (relatii intre clase)
si aceeasi semantica.
O clasa e reprezentata printr-un dreptunghi cu 3
compartimente (cele pentru atribute si operatii pot lipsi, dar
numele e mereu prezent).
Clasele definite in etapa de “Analiza a cerintelor” contin de regula numai numele
si atributele, fara specificarea fiecarui tip de atribut. Clasele astea se numesc clase
conceptuale.
Reprezentarea detaliata a unei clase e contruita in etapa de proiectare de detaliu.
Sunt precizate vizibilitatea informatiilor din clasa (public/private), tipul variabilelor
si lista de parametri a fiecarei operatii.
Diagrama de clase reda un set de clase si relatiile dintre ele. Clasele pot fi asociate
(A lucreaza pentru B), sau generalizate (mostenire). In cazul asocierii se pot atasa
nume de rol.

Pot fi mai multe clase asociate prin aceeasi relatie (asociere binara, ternara, n-
ara). Pot fi asociate mai multe obiecte ale unei clase la un alt obiect (sau obiecte)
ale unei alte clase. In acel caz se adauga numarul obiectelor pe relatie (one-to-
many/many-to-many, dar specifici cate - * e evident oricat).
Ascocierile pot fi unidirectionale, asta inseamna ca numai unul din obiecte are
acces la celalalt (ex: fereastra are acces la
cursor, dar cursorul nu are la fereastra).
Clasa de asociere contine atributele relatiilor intre
doua clase.
Agregarea este o forma particulara de asociere,
care exprima un cuplaj temporar de tipul “compus-
componenti”. Mai multe obiecte ale unei clase pot face parte dintr-un singur alt
obiect la un anumit punct in timp, iar la
distrugerea acelui obiect, obiectele initiale
pot face apoi parte din alt obiect (ex:
profesorii sunt intr-un departament, se distruge departamentul, dar profii inca
pot merge in alt departament).
Relatia de compunere functioneaza similar. Ca notatie, rombul (de la agregare)
este umplut. O astfel de relatie semnifica distrugerea obiectelor (ex: profesor) la
distrugerea obiectului ce le contine (ex: piese auto intr-o masina, distrugi masina,
se duc si piesele).
Relatia de dependenta este cea mai slaba relatie intre doua clase. Exprima de
obicei o relatie temporara intre obiecte: obiectul clasei dependente
interactioneaza pentru scurt timp cu obiectul clasa tinta. O clasa A depinde de o
clasa B daca o metoda a clasei A are un parametru de tip B. (ex: Om depinde de
Mancare pentru ca om.mancanca(mancare)). Relatia de dependenta poate fi
adnotata cu un stereotip care ofera informatii depsre natura relatiei.
Relatia de generalizare se bazeaza pe notiunile de clasificare, generalizare,
specializare si extindere. Factorizeaza elementelor comune (atribute, operatii,
constrangeri) ale unui ansamblu de clase intr-o clasa mai generala, numita
superclasa. Se formeaza astfel un arbore de mostenire. Exista si clase abstracte,
care nu pot fi instantiate (si orice e la OOP).
Curs 4, 5

Modelarea interfetelor

Interfata reprezinta metodele publice ale unei clase (fara constructor/destructor).

O interfata e reprezentata intr-o diagrama de clase in doua moduri:
1. Ca pe o clasa (dreptunghiul cu 3 categorii) si cu <<interface>> scris
deasupra numelui (tot in chenar)
2. Printr-un cerc adnotat cu numele interfetei, notatie numita lollipop

O clasa poate implementa mai multe interfete. O interfata reprezinta un rol pe

care obiectele unei clase il joaca in raport cu obiectele altei clase.

Proiectarea arhitecturala

Modelul de analiza ofera o vedere externa asupra sistemului, el servind ca un

mijloc de comunicare intre client si dezvoltator. Proiectarea este etapa in care se
contruieste solutia problemei. Proiectarea arhitecturala transforma modelul de
analiza intr-un model al arhitecturii sitemului.
Principalele activiatati:
 Se definesc obiectivele proiectarii
 Sunt descompuse in susbsiteme care pot fi realizate de echipe diferite
 Sunt alese strategiile de construire a sistemului
Cerintele nefunctionale devin obiectivele proiectarii. Ele descriu calitati ale
sistemului care trebuie urmarite in dezvoltare. Ele ghideaza deciziile
dezvoltatorilor atunci cand sunt necesare compromisuri.
Modelul functional devine definirea subsistemelor. Arhitectura software descrie
structura sistemului in subsisteme.
Modelul obiect devine distributia subsistemelor pe hardware.
Modelul dinamic devine fluxul global al controlului.
Modelul de proiectare trateaza si conditiile limita in functionarea sistemului.

Criterii de proiectare
Pot fi organizate in 5 grupuri:
1. Performanta
 timp de raspuns
 throughput
 utilizare de memorie
2. Increderea in sistem (dependability)
 robustetea – cat rezista la intrari neprevazute
 fiabilitate
 disponibilitate (uptime)
 toleranta la defecte
 securitate
 siguranta – sa nu puna oameni in pericol (WTF?)
3. Cost (la astea se fac compromisuri)
 costul dezvoltarii
 costul tranzitiei la utilizator (deployment) – instalare + instructie
 costul actualizarii
 costul mentenantei
4. Mentenanta
 extensibilitate
 usurinta de modificare
 adaptabilitate
  portabilitate
 calitatea codului
5. Criteriile utilizatorului final
 utilitatea – il ajuta sistemul in munca lui?
 usurinta de utilizare

Numai un numar mic din criteriile de proiectare pot deveni obiective de

proiectare. De aceea trebuie facute anumite compromisuri:
 Memorie vs viteza
 Timp de livrare vs functionalitate
 Timp de livrare/Cost dezvoltare vs fiabilitate
 Timp de livrare vs resurse umane

Arhitectura software rezulta printr-un proces iterativ de descompunere a

cerintelor functionale si alocare lor unor subsiteme ale viitorului sistem. Un
susbsitem contine un set de clase corelate, este o parte substituibila a unui sistem
si este dezvoltat de o echipa de dezvoltare independenta. In cazul sistemelor
complexe, descompunerea se aplica in mod recursiv.

Identificarea subsitemelor
Descompunera initiala in subsisteme pleaca de la clasele identificate in modelul
de analiza. Se grupeaza in acelasi subsistem clasele corelate functional si numarul
de asocieri dintre clasele din subsisteme diferite trebuie sa fie cat mai mic.
Relatiile de dependenta intre subsisteme se definesc prin intermediul interfetelor
subsistemelor. Un subsistem se caracterizeaza prin serviciile pe care le furnizeaza
altor subsisteme. Un serviciu este un
set de operatii corelate care au un
scop comun. Acest set formeaza
interfata/interfelete subsistemului.
Subsistemele trebuie sa fie cat mai independente unul de altul. O modificarea a
unui subsistem trebuie sa aiba influenta minima asupra altor subsisteme. O
schimbare mica a cerintelor nu trebuie sa duca la modificari majore ale
arhitecturii. Efectul unei conditii de eroare trebuie sa fie izolat unui subsistem. Un
subsistem trebuie sa poata fi inteles ca o entitate de sine-statatoare.

Strategii de descompunere in subsisteme

Descompunere ierarhica (pe verticala)

Produce un set ordonat pe niveluri. Un nivel este o grupare de subsisteme care
furnizeaza servicii corelate, posibil realizate utilizand aceleasi servicii de nivel
inferior. Nivelurile sunt ordonate in sensul ca fiecare nivel depinde numai de
nivelurile de sub el si nu are cunostinta despre nivelurile superioare.
Intr-o arhitectura inchisa, fiecare nivel poate accesa numai nivelul imediat sub el.
Intr-o arhitectura deschisa, se pot accesa mai multe niveluri aflate sub el.
Avantaj: cuplare slaba intre subsisteme, ele putand fi integrate si testate
incremental.
Dezavantaje: fiecare nivel introduce un overhead de viteza si memorie; e dificil sa
introduci functionalitati pe niveluri intermediare daca acea functionalitate nu a
fost prevazuta.
Partitionare (descompunere pe orizontala)
Se imparte sistemul in subsisteme independente, care apartin aceluiasi nivel de
abstractizare, fiecare subsistem fiind responsabil pentru o clasa diferita de
servicii. Fiecare subsistem depinde slab de celelalte dar poate opera adesea
singur.
Verificarea proiectarii arhitecturale

Se verifica daca obiectivele proiectarii au fost realizate. Se verifica daca modelul

de proiectare arhitecturala este corect, complet, consistent, realist si usor de
inteles.
Modelul de proiectare este corect daca modelul de analiza se poate mapa pe
modelul de proiectare. Trebuie sa se raspunda la urmatoarele intrebari:
 Exista un caz de utilizare/cerinta nefunctionala pentru fiecare subsistem?
 Poate fi mapat fiecare caz de utilizare pe un set de subsisteme?
 Poate fi mapat fiecare obiectiv de proiectare pe o cerinta nefunctionala?
 Sunt adresate toate cerintele nefunctionale?
 Are fiecare actor o politica de acces? Este acea politica consistenta cu
cerinta de securitate?
Modelul este complet daca:
 Exista functionalitati in cazuri de utilizare neprevazute de subsistemele
proiectate?
 Sunt prevazute conditiile limita?
Modelul este consistent daca:
 Sunt prioritizate obiectivele de proiectare conflictuale?
 Exista obiective de proiectare in contradictie cu cerinte nefunctionale?
 Exista mai multe subsisteme sau clase cu acelasi nume?
Modelul este realist daca poate fi implementat si este usor de inteles daca
dezvoltatorii neimplicati in proiectare pot intelege modelul.
Stiluri arhitecturale

Repository
Subsistemul pastreaza un set de date care alcatuiesc un repo si ofera servicii de
creare, acces si modificare a datelor. Potrivit pentru sisteme cu baze de date.
Avantaje: pot fi adaugate usor noi subsisteme
Dezavantaje: accesul la repo duce la o “strangulare” (reduce performanta) si
cuplarea intre repo si fiecare alt subsistem e mare (modfici repo-ul, mofici
celelalte subsisteme)

MVC
Subsistemul Model tine reprezentarea datelor.
Subsistemul View e responsabil de vizualizarea modelului.
Subsistemul Controller gestioneaza interactiunea cu utilizatorul.
Potrivit sistemelor interactive, mai ales cand sunt necesare multe vederi ale
modelului.

Client-Server
Clinetii cunosc interfata serverului (sau serverelor), dar serverul nu stie (si nu-i
pasa) interfetele clientilor.
Portabilitate – serverul poate fi accesat din orice sistem de operare si
independent de mediul de comunicare
Transparenta locatiei – chiar daca serverul este distribuit
Performanta inalta, scalabilitate si fiabilitate.
Peer-to-peer
O generalizare a client-server, in care subsistemele pot fi atat clienti cat si servere.
Fluxul controlului in fiecare subsistem este independent, exceptand sincronizarile
necesare pentru tratarea cererilor.
Arhitectura e mai greu de implementat caci poate introduce posibilitatea de
deadlock si complica fluxul controlului la nivelul fiecarui subsistem (peer).

Three-tier
Sunt 3 niveluri ierarhice: interfata utilizator – logica aplicatiei – baza de date.
Folosit in sistemele bazate pe Web: browserul e primul nivel, serverul web e al
doilea, iar baza de date e ultimul.
Avantaj: fiecare nivel poate fi imbunatatit independent.

Four-tier
Three-tier in care Interfata utilizatorului e descompusa in prezentarea clientului si
prezentarea serverului.
Avantaj: nivelul prezentarii clientului poate oferi o gama larga de interfete
utilizator care pot partaja elemente ale nivelului prezentarii serverului.

Pipe and filter

Filtrul e un subsistem care efectueaza un pas de procesare. Pipe e conexiunea
intre doi pasi de procesare. Filtrele proceseaza fluxuri de date.
Exemplu: Graphics pipeline

Datele persistente sunt date care nu se distrug la terminarea executiei. Se pot

folosi sisteme de fisiere (ieftine, usor de implementat) sau baze de date (flexibile,
scalabile, portabile, suporta scrieri concurente).
Controlul accesului

Intr-un sistem multi-user, fiecare tip de utilizator (actor) are anumite drepturi de
acces la resursele sistemului. Se determina obiectele partajate de actori – fisiere,
procese, instante ale claselor, se defineste mecanismul de control al accesului la
obiectele partajate si, in functie de cerintele de securitate, se stabilesc reguli de
autentificare a utilizatorilor si necesitatile de criptare a unor date.
Exista 3 mecanisme de control al fluxului operatiilor intr-un sistem:
1. Dirijat procedural
 Operatiile asteapta intrarile de la un actor
 Folosit in sistemele mai vechi si cele implementate in limbaje
procedurale
 Dificil de utilizat in limbajele orientate obiect, secventierea
operatiilor fiind distribuita in seturi mari de obiecte
2. Dirijat de evenimente
 Sistemul contine o bucla principala in care se asteapta un eveniment
extern
 La producerea unui eveniment, el e transferat obiectului
corespunzator
 Structura de control simpla, cu centralizare a intrarilor in bucla
principala
 Folosit in sistemele bazate pe evenimente generate de GUI
3. Fire de executie
 Threaduri care se executa in paralel
 Threadurile pot fi create/distruse la diferite momente de timp
 Intr-un thread se asteapta intrari de la un actor

Intr-un sistem trebuie luate in considerare si cazurile limita. Anumite exceptii pot
fi chiar tolerate de sistem si incluse in proiectarea unor componente.
Curs 6

Proiectarea de detaliu
Activitati:
 Detalierea modelului arhitectural – descrierea claselor
 Optimizarea modelului arhitectural – imbunatatire timp raspuns, utilizare
memorie, complexitatea codului
 Reutilizare
 Definirea interfetelor subsistemelor

Sabloane de proiectare (Design Patterns)

Presupun reutilizarea solutiilor de proiectare. Alegerea sabloanelor trebuie sa se
bazeze pe anticiparea schimbarilor viitoare:
 Furnizor/Tehnologie/Implementare noua
 Schimbari legate de utilizarea sistemului
 Cresterea complexitatii domeniului aplicatiei
 Erori in specificatia cerintelor
Un sablon descrie o problema care se intalneste in mod repetat in proiectarea
programelor si solutia generala pentru problema respectiva. Solutia este
exprimata folosind clase (si obiecte). Descrierea problemei si solutiei este
abstracta.
Un sablon are 4 elemente esentiale:
1. Un nume care poate fi referit – se formeaza un vocabular de proiectare
2. Descrierea problemei – cand/unde apare problema?
3. Descrierea solutiei – elemente, relatiile dintre ele
4. Consecintele aplicarii sablonului – costuri, beneficii
Sablonul Adapter

Problema: Interfata existenta difera de interfata necesara clientului

Solutia: Implementam interfata necesara clientului si efectuam conversiile
necesare pentru a putea folosi interfata furnizata.
Clasa Client vrea sa foloseasca interfata ClientInterface. Aceasta e implementata
prin clasa Adapter care adapteaza LegacyClass.
Clasele Client si LegacyClass pot fi folosite impreuna fara a modifica pe vreuna,
deci permite reutilizarea. Trebuie creat un nou Adapter pentru fiecare specializare
a clasei ClientInterface.

Sablonul Bridge

Problema: Decuplarea unei interfete de o implementare a sa, astfel incat

implementarile sa poata fi inlocuite.
Solutia: Clientul are acces la o interfata Abstraction cu diferie implementari ale
clasei Implementor.
Clientul este protejat de implementarile concrete ale claselor Abstraction si
Implementor. Astfel, interfetele si implementarile pot fi modificate independente.

Sablonul Strategy

Problema: Decuplarea unei clase care decide o politica de clasele care

implementeaza diferite strategii, astfel incat implementarile sa poata fi inlocuite
in mod transparent.
Solutia: Un client acceseaza serviciile furnizate de o clasa Context. Clasa Strategy
descrie o interfata comuna tuturor mecanismelor care pot fi utilizate de Context.
Pot fi adaugati noi algoritmi fara a modifica interfata Context.
Sablonul Abstract Factory

Problema: Protejarea clientului fata de diferite platforme care implementeaza in

mod diferit acelasi set de concepte.
O clasa AbstractFactory declara operatiile de creare a produselor pe care le
foloseste un Client. Acesta depinde numai de produsele abstracte si de
AbstractFactory, deci clientul este independent de clasele produselor concrete.
Este posibila inlocuirea familiilor de obiecte in timpul executiei.
Adaugarea de produse noi este dificila deoarece trebuie extinse toate clasele
ConcreteFactory (astea sunt implementari ale AbstractFactory si e cate una
pentru fiecare produs).

Sablonul Command

Problema: Separarea comenzilor de procesarea lor, astfel incat sa poata fi

executate, anulate sau memorate intr-o coada si procesate ulterior, independent
de comanda.
Solutia: Clasa abstracta Command declara interfata care trebuie implementata de
toate comenzile concrete (ConcreteCommand).
Clientul creaza comenzi concrete si le “leaga” de obiecte Receiver specifice.
Comenzile concrete sunt implementate folosind opeartii ale obiectului Receiver.
Invoker doar executa sau anuleaza o comanda.
Obiectul Receiver si algoritmul comenzii (ConcreteCommand) sunt decuplate.
Invoker nu cunoaste comenzi specifice. ConcreteCommands sunt obiecte care pot
fi create si memorate. Pot fi
adauge noi
ConcreteCommands fara a
modifica codul existent.
Sablonul Composite

Problema: Reprezentarea unei ierarhii de inaltime si latime variabile astfel incat

frunzele si agregatele sa poata fi tratate unifrom, prin aceeasi interfata.
Solutia: Interfata Component specifica serviciile care sunt partajate de frunza
(Leaf) si agregat (Composite).
Consecinte: Clinetii utilizeaza acelasi cod pentru lucrul cu obiectele frunza si cu
obiectele agregat. Comportarea implementata in Leaf poate fi modificata fara
schimbarea ierarhiei. Pot fi adaugate noi clase Leaf fara modificarea ierarhiei.
Exemplu: Grup de elemente
grafice care pot fi translatate,
scalate, etc. Un grup poate contine
alte grupuri.
Ierarhii de fisiere si foldere. Un
folder poate contine la randul sau
alte fisiere si foldere. Pot fi folosite
aceleasi operatii pentru redenumire a fisierelor si folderelor.

Sablonul Subiect-Observator

Intentia: Defineste o dependenta one-to-many intre obiecte, astfel incat atunci

cand un obiect isi schimba starea, toate obiectele dependente de el sunt
notificate si actualizate automat.
Creste gradul de reutilizare a claselor prin separarea obiectelor dependente in
clase distincte slab cuplate. Poate fi utilizat cand o abstractie are doua aspecte,
unul dependent de celalalt, sau cand modificarea unui obiect necesita
modificarea mai multor alte obiecte sau cand un obiect trebuie sa notifice alte
obiecte fara a presupune cine sunt acele obiecte de fapt.
Notify poate fi apelat:
 de operatiile care modifica starea subiectului
o clientul nu mai trebuie sa apeleze notify
o modificari succesive rezulta in actualizari succesive (ineficient)
 de catre clienti, la momentul potrivit
o clientul cere actualizarea dupa un numar de modificari (eficient)
o clientul devine responsabil de apelarea notify

Cum alegem sabloanele de proiectare

Este necesara independenta de producator si/sau de platforma?

Abstract factory
Trebuie sa se respect o interfata deja existenta?
Adapter
Trebuie sa se poata adapta la noi protocoale?
Bridge
Toate comenzile trebuie sa poata fi anulate?
Command
Trebuie sa se poata implementa structuri agregate?
Composite
Trebuie decuplata politica de mecanismele care o implementeaza sau ca diferiti
algoritmi sa poata fi schimbati dinamic la momentul executiei?
Strategy
Curs 7

Analiza functionala

Proiectarea OO pleaca de la o analiza OO si produce o arhitectura software in care

un modul program (unitatea de decompozitie minimala) este clasa.
O alta strategie de structurare a unui sistem software se bazeaza pe analiza
functionala si proiectarea functionala, care isi au originile in dezvoltarea
limbrajelor procedurale.
Proiectarea functionala pleaca de la o analiza functionala si produce o arhitectura
in care un modul program este o functie sau o procedura.
In analiza functionala, sistemul este structurat prin descompunerea prelucrarilor
pe care trebuie sa le efectueze sistemul. Descompunerea se poate face la mai
multe niveluri de abstractizare, ceea ce conduce la o arhitectura ierarhica.
Modelul de analiza functionala poate fi reprezentat in UML prin:
 Diagrame de activitate – pentru reprezentarea prelucrarilor la diferite
niveluri de abstractizare
 Diagrame de clase – reprezentarea datelor persistente
 Diagrame de stari – modelarea comportamentului dependent de timp al
sistemului
Prelucrarile descrise in modelul de analiza sunt alocate subsistemelor.
Diagrame de structura

Nodurile diagramei reprezinta module functionale (functii) si arcele reprezinta

relatiile de apel intre module. Sagetile indica fluxul datelor, iar parametri sunt
pusi de-a lungul conexiunilor.
Un modul de intrare accepta date de
intrare ale sistemului sau date de la un
modul situat pe un nivel mai coborat al
diagramei si le transfera unui modul
situat pe un nivel superior, intr-o forma
transformata.
Un modul de transformare accepta date
de la un modul de nivel superior si le
transfera inapoi modulului. Un modul de
iesire efectueaza o operatie de iesire utilizator sau de transfer de date catre un
sistem extern.
Recomandari de proiectare a modulelor functionale
Minimizarea cuplarii intre module. Evitarea cuplarii prin structuri de date,
variabile “steag” sau prin date globale.
Minimizarea fan-out. Numarul de module apelate de modul sa fie cat mai mic.
Maximizarea fan-in. Numarul de module care apeleaza modului sa fie cat mai
mare.
Factorizarea functionalitatilor comune in module reutilizabile.

Comparatie intre abordarea functionaal si cea OO

Analiza functionala organizeaza un sistem pe baza prelucrarilor, nu in jurul unor
obiecte. Metodele functionale sunt utile pentru dezvoltarea de programe in care
prelucrarile sunt mai importante si mai complexe decat datele. Majoritatea
modificarilor se aduc functiilor. O conceptie OO e mai usor de extins decat una
functionala, pentru ca se adauga pur si simplu obiecte si relatii in plus.
Curs 8

Testarea programelor

Un caz de test este un set de date de intrare + rezultatele pe care programul

trebuie sa le produca + specificatia functiei testate.
Un test este o executie a programului pentru a exersa un caz de test. Se ruleaza
programul cu date de intrare specificate si se verifica cu cele asteptate.
O suita de test e un set de teste.
Scopul testarii este verificarea si validarea programelor. Prin testare nu se poate
demonstra corectitudinea unui program, dar cazurile de test se aleg astfel incat sa
se descopere posibile defecte existente in programul testat.

Teste unitare
Se efectueaza la nivelul unei unitati de program: functie, procedura, etc.
Sunt realizate de programatorul care implementeaza unitatea program. Unitatea
tratata este considerata independenta care nu necesita prezenta altor unitati ale
programului.
Unitatile program cu care interactioneaza unitatea testata sunt simulate prin:
 Modulul ciot (<<stub>>) – simuleaza modulele apelate de modulul testat
 Modulul driver (<<driver>>) – simuleaza cazurile de apel ale modului testat
Modulul driver apeleaza modulul care urmeaza sa fie testat, furnizandu-i date de
intrare.
Metode de alegere a cazurilor de test pentru testarea unitara
Testarea functionala (“black box”): datele de test se aleg pe baza specificatiei
unitatii testate
Testarea structurala (“white box”): datele de test se aleg pe baza codului unitatii
testate
Testarea random: datele de test sunt generate in mod aleator pe baza domeniilor
de valori ale variabilelor de intrare
Testarea bazata pe mutatii: se introduc defecte in cod; o suita de test care nu
detecteaza defectul introdus e considerata ineficienta

Testarea claselor
Presupune separarea fiecarei metode si testarea comportarii in timp a obiectelor.
Testarea “Alpha-Omega” presupune trecerea unui obiect al clasei testate prin
toate starile sale, de la creare pana la distrugere, prin apelul tuturor metodelor
clasei. Este o testare minimala a unei clase.
Ordinea de apel a metodelor depinde de tipul clasei:
 Non-modal – clasa care accepta orice mesaj (apel) in orice stare, ordinea de
apel nu conteaza
 Quasi-modal – clasa in care constrangerile privind ordinea mesajelor se
schimba in acelasi timp cu starea obiectelor claselor (exemplu: containere –
stiva plina/goala)
 Modal – clasa care are constrangeri permanente si fixe privind ordinea
mesajelor
Testarea claselor in JUnit:
1. Crearea unui obiect si selectarea metodei de start
2. Selectarea valorilor parametrilor de intrare a metodei
3. Calculul valorilor care se asteapta sa fie returnate de metoda
4. Executia metodei selectate asupra obiectului creat folosind valorile
sleectate ale parametrilor de intrare
5. Verificarea rezultatului

Testarea de integrare
Scopul este de a integra modulele dezvoltate independent intr-un sistem
functional.
Se verifica interactiunile dintre module, grupuri de module, pana la nivel de
sistem. In cazul unui program alcatuit din clase, modulele sunt functii membre ale
claselor. Clasele sunt testate individual prin teste unitare. Testele de integrare
presupun, ca si testele unitare, realizarea de module “ciot” si module “driver”.
Metoda big-bang presupune integrarea intr-un program executabil a tuturor
modulelor existente la un moment dat. Problema e ca apar toate erorile posibile
in acelasi timp.
Integrarea progresiva este mai eficienta, la fiecare nou test se adauga cate un
singur modul. Astfel, erorile apar treptat.
Integrarea ascendenta (de jos in sus)
Mai intai se testeaza modulele care nu apeleaza alte module. E nevoie de un
modul driver pentru fiecare modul al programului (si niciun ciot).
Avantaje: nu se folosesc module ciot, cele driver fiind mult mai usor de
implementat; modulele de nivel coborat se apeleaza de multe ori, deci e mai
avantajos sa fie implementate, nu simulate de cioturi.
Dezavantaje: Programul e disponibil numai dupa integrarea ultimului modul;
corectarea erorilor poate necesita reproiectarea; principalele erori sunt
descoperite de abia la sfarsit

Integrarea descendenta (de sus in jos)

Se incepe prin testarea modulului principal, apoi se testeaza programul obtinut
prin integrarea modulului principal si a modulelor apelate direct de el, samd. Se
foloseste un singur modul driver si cate un ciot pentru fiecare alt modul.
Avantaje: erorile sunt descoperite din timp; programul obtinut e mai fiabil;
programul exista de la inceput.
Dezavantaje: se implementeaza un ciot pentru fiecare nou modul; componentele
complexe sunt dificil de simulat prin module ciot; pentru primele teste e nevoie sa
adaugam intructiuni de afisare.

Integrarea <<sandwich>> (hibrida)

Se integreaza modulele de pe nivelul ierarhic cel mai coborat (cal mai des apelate)
prin tehnica de jos in sus. Se integreaza modulele cel mai putin apelate cu tehnica
de sus in jos. Restul modulelor se integreaza intr-o ordine convenabila.
Reduce dezavantajele integrarii descendente prin folosirea modulelor reale in
locul cioturilor.
Testarea de sistem

Se verifica daca softul satisface cerintele specificate. Sunt teste ale sistemului si
echipamentului complet. Ocupa cel mai mult timp din perioada de testare. Toate
testele sunt de tip “black box”.

Teste functionale
Se folosesc cazuri derivate din cerintele functionale. Includ si teste de interfata cu
utilizatorul.
Teste de performanta
Se verifica daca performanta corespunde cerintelor in conditii normale si
nefavorabile.
Teste de comunicare (cu interfete externe)
Se verifica fluxul datelor si al controlului prin interfete externe. Se folosesc
protocoale de comunicatie.
Teste ale utilizarii resurselor
Cat de mult e utilizat CPU, RAM, spatiu pe disc, reteaua.
Teste de fiabilitate
Se verifica satisfacerea cerintelor de fiabilitate. Se folosesc toate statisticile
operationale (date de test random generate conform unei legi de probabilitate).
Testarea e trecuta cand rata de esec e sub o valoare ceruta.
Teste de securitate
Se verifica daca sistemul e protejat impotriva anumitor atacuri.
Teste de portabilitate
Teste de siguranta in functionare (nu pierzi fisiere/informatii)
Teste de stres
Testarea de acceptare
Scopul este de a verifica daca produsul respecta cerintele clientului. La aceste
teste participa si clientul.
Testarea se face in mai multe etape: alfa si beta (crapa mult, crapa putin).
Alfa se efectueaza folosind cerintelor utilizatorului pana cand clientul si
dezvoltatorul cad de acord ca programul e o reprezentare satisfacatoare a
cerintelor. La beta programul e distribuit unui numar select de utilizatori pentru a
il testa in conditii reale.

Teste regresive
Dupa corectarea unor erori se fac astfel de teste pentru a verifica ca nu au aparut
alte erori. Testele astea se fac in timpul dezvoltarii si in timpul perioadei de
operare a softului.
Curs 9

Testarea functionala
Bazata pe specificatia componentei testate si focalizata pe verificarea
comporatarii sale externe. Obiectul testat e tratat ca o “cutie neagra”.

Testarea ad-hoc
Programul este executat in mod repetat pentru intrari random, observandu-se
comportarea sa.

Testarea bazata pe analiza domeniilor de valori ale variabilelor de I/O

Se identifica domeniul de valori al fiecarei variabile de I/O, analizand specificatia
cerintelor si documentele de proiectare. Se aleg valori speciale din domeniul
fiecarei variabile. Se proiecteaza apoi teste cu diferite combinatii ale variabilelor
de intrare/iesire.
Pentru variabile numerice daca e data o multime (nr finit) de elemente, se
testeaza folosind toate valori + cateva din afara multimii. Pentru un interval de
numere, se aleg valorile extreme (capetele intervalului), valori nevalide, valori cu
proprietati matematice speciale (0 si 1).
Pentru tablouri se testeaza intrari de dimensiuni diferite (vector, matrice, cub) si
cu elemente distincte. In unele cazuri sunt folosite teste pentru subseturi ale
tabloului (ex: diagonala principala pentru o matrice).
Alegerea cazurilor de test prin analiza domeniilor variabilelor de intrare conduce
la prea multe cazuri de test (vectorii de test sunt combinatii ale valorilor de
intrare selectate).
Alegerea cazurilor de test prin analiza domeniilor varaibelelor de iesire necesita
analiza specificatiei in directia inversa (sa stii ce faci la intrare ca sa poti verifica ce
scoti).
Pairwise testing
Metoda asigura ca fiecare combinatie posibila intre valorile selectate pentru
fiecare pereche de variabile de intrare este acoperita prin cel putin un test. Studii
au aratat ca metoda aceasta poate detecta 70% din defecte.
Tablourile se numesc ortogonale deoarece:
 fiecare combinatie posibila intre valorile a doua variabile apare o singura
data
 fiecare vector de test este diferit de ceilalti
 fiecare vector de test e independent statistic (aparitia unuia nu
influenteaza aparitia altora)
Metoda este eficienta pentru ca:
 se obtin usor cazurile de test (totul poate fi automatizat)
 este o metoda statistica sistematica de testarea a interactiunilor intre
perechi de variabile
 furnizeaza o acoperire uniforma a tuturor combinatiilor de variabile
 utila in teste de integritate, de interfata utilizator, de sistem si de
performanta

Partitionarea in clase de echivalente

In multe cazuri, un program se comporta la fel pentru intrari diferite. Toti vectorii
de test care dau acelasi comportament fac parte dintr-o “clasa de echivalenta”.
Determinarea claselor de echivalenta se efectueaza pe baza specificatiei
programului testat.
Avantaje: Numarul de cazuri de test pentru acoperirea unui domeniu larg e de
obicei mic. Probabilitate mare de descoperire a defectelor.
Teste statistice aleg date de intrare aleator dupa o anumita lege. Au rezultate
neuniforme – uneori foarte bune, alteori inutile. In general se folosesc ca teste de
fiabilitate – se urmareste mai mult comportarea in timp a programului.
Curs 10

Testarea structurala

Este focalizata pe implementarea obiectului testat. Obiectul e tratat ca o cutie

transparenta (white box). Se foloseste in testarea unitara, de integritate si in
testarea programelor mici.
Cazurile de test se obtine pe baza grafului controlului al codului componentei
testate.
Evidentiaza urmatoarele tipuri de greseli:
 cai absente in graful de control – se ignora conditii
 cai definite incorect/incomplet – conditii de ramificatie gresita
 acituni incorecte/absente – ex: apelam o functie cu parametri gresiti

Graful fuxului controlului a componentei testate e principalul intrument folosit

pentru aceasta testare. Exista trei tipuri de noduri:
 noduri de prelucrare – portiuni care se executa mereu
in aceeasi secventa
 noduri de decizie – pentru if-uri
 noduri de jonctiune a mai multor ramificatii
Arcele reprezinta transferul controlului intre ndourile de
prelucrare. Graful are un nod unic de intrare si un nod unic de
iesire.
Pentru testarea ciclurilor se aleg cai care nu traverseaza ciclul
(evidentiaza greseli de initializare sau a calculelor de dupa
ciclu care se bazeaza pe executia lui), cai cu o singura iteratie
(verifica intializarea ciclului) si cai cu doua iteratii (evidentiaza
greseli care impiedica repetarea ciclului).
Avantaje:
 Graful controlului poate fi generat automat pe baza sursei
 Predicatele de cale pot fi generate automat pe baza grafului
 Vectorii de test la fel, alesi random din domeniul datelor de intrare
Dezavantaje:
 Cazurile de test depinde de codul programului, trebuie recalculate la orice
modificare, deci nu pot fi reutilizate dupa o modificare a testului
 Cazurile de test acopera functionalitatile implementate, nu le descopera pe
cele absente
Testele structurale trebuie, deci, sa fie completate cu cele functionale. Testele
structurale pot evidentia unele erori care nu sunt descoperite de teste
functionale, care folosesc esantioane ale datelor de intrare.

Revizii software
Sunt efectuate asupra artefactelor produse in procesul de dezvoltare software:
documente de specificare a cerintelor, documente de proiectare, planuri de
management, cod sursa.
Scopul este de a identifica defecte si de a imbunatatii calitatea. Reviziile se
efectueaza la inceputul dezvoltarii pentru a fi mai economice, dar se fac si in
fazele finale (de ex. asupra manulului de utilizare).
Se impart in 4 categorii:
 Revizii tehnice
 Prezentari (walkthroughs)
 Audituri
 Inspectii
Reviziile tehnice evalueaza articole software pentru a le imbunatati din punct de
vedere tehnic prin corectarea defectelor sau prin abordari alternative.
Obiectivele unei revizii tehnice:
 Articolele revizuite sa fie conforme cu specificatiile facute anterior
 Sa fie produse in conformitate cu standardele prevazute
 Fiecare modificare sa fie implementata corect
 Articolele revizuite sa nu contina defecte
Procesul de revizie are 2 etape:
1. Pregatirea (inainte de intrunire)
 Fiecare membru al echipei studiaza articolele supuse reviziei si
inregistreaza fiecare problema intalnita. Problemele sunt trimise
autorului articolului revizuit
 Autorul studiaza problemele si trimite un formular cu raspunsul sau
 Conducatorul echipei clasifica toate problemele in majore/minore/de
editare
2. Intrunirea
 Se decide daca fiecare probleam trebuie sa fie inchisa (e rezolvata
problema), trebuie sa fie modificat articolul sau trebuie rejectata
problema
Prezentarile sunt utile in evaluarea timpurie a documentelor, a modelelor si a
codului in fazele de specificare a cerintelor software, proiectare si implementare.
Obiectivul prezentarii este de a evalua articolul software (cautarea defectelor) si
de a educa si a rezolva problemele de stil. Inainte de intrunire, membri echipei
studiaza articolul si in timpul intrunirii autorul prezinta articolul revizuit (spre
deosebire de reviziile tehnice unde doar se vorbeste despre probleme).
Auditurile sunt revizii efectuate de grupuri externe. Se verifica sa se respecte
standardele, specificatiile si procedurile stabilite.
Inspectiile au rol de a depista defecte care trebuie corectate. Se fac inainte de
testare pentru a verifica proiectarea cazurilor de test si procedurilor de testare.
Sunt eficiente si economice, pot detecta >50% din numarul total de defecte din
timpul dezvoltarii.
Curs 11

Modelele de dezvoltare software

Ciclul de viata al unui program

O secventa ciclica de etape in existenta
programului, care include toate activitatile
necesare pentru dezvoltarea, operarea si
intretinerea sa.
Modelul de dezvoltare este o decriere generala a
procesului de dezvoltare. Are ca scop optimizarea
procesului de dezvoltare, pentru obtinerea de
produse de calitate, in mod reproductibil (si in
limitele costurilor si termenelor limita).

Modelul Waterfall (dezvoltare liniara)

Consta in o succesiune de faze ce se inlantuie liniar, de la analiza cerintelor pana
la livrarea la client. Fiecare faza corespunde unei activitati si trebuie sa se termine
la o anumita data prin producerea unui document sau unui program.
Fiecare faza include reivizia rezultatelor fazei; nu se trece la urmatoarea faza
decat dupa ce rezultatele sunt satisfacatoare.
Avantaje:
 Produsul software este bine documentat
 Permite un bun management al proiectului (planificarea resurselor,
estimari de cost, etc.)
Dezavantaje:
 Toate riscurile sunt incluse intr-un singur ciclu de dezvoltare
 Executabilul e disponibil tarziu; la fel si detectarea erorilor
Riscurile pot fi:
 factori de experienta
 factori de planificare – estimarea resurselor si termenelor limita
 factori tehnologici – noutatea tehnologica, metode de dezvoltare
 factori externi – calitatea specificatiei clientilor (incomplete/ambigue)

Acest model se recomanda pentru proiectele in care cerintele sunt bine intelese
de la inceput si nu se modifica pe parcursul procesului de dezvoltare.
Nu e potrivit pentru proiecte cu cerinte vagi/neclare, proiecte cu cerinte care se
pot schimba si proiecte de lunga durata.
Modelul in “V”
Este o varianta a modelului waterfall, care include elaborarea planurilor de test in
fazele de specificare si proiectare. Avantajul fata de modelul cascada este ca
sansele de succes sunt mai mari, datorita elaborarii planurilor de test in primele
etape ale procesului de dezvoltare.

Dezvoltarea pe baza de prototip

Scopul prototipului este de a clarifica si a specifica exact cerintele. Prototipul
ofera functionalitatile viitorului produs si interfata cu utilizatorul. Nu se
recomanda utilizarea sa in dezvoltarea produsului final, chiar daca implementarea
este in acelasi limbaj.
Studiul de fezabilitate
Precede orice proces software, indiferent de modelul de dezvoltare. Se determina
obiectivele proiectului, se analizeaza procesul care ar trebui imbunatatit/produsul
care ar trebui sa fie inlocuit de noul produs software.
In urma studiului se poate decide ca proiectul e realizabil si poate incepe, sau ca
nu e realizabil si trebuie abandonat – nu aduce beneficii clientului, costuri prea
mari sau nu avem echipamentul necesar.
Modelul de dezvoltare iterativa si incrementala
Produsul software e dezvoltat in mai multe iteratii, fiecare iteratie incluzand un
“ciclu de dezvoltare cascada”. Fiecare produs se incheie cu un produs executabil.

Analiza de nivel inalt

Se defineste o “viziune” asupra sistemului: scopul sau, obiectivele principale, cine
il va utiliza, ce functionalitati are.
In unele cazuri se analizeaza “domeniul problemei” pentru a intelege structura si
dinamica organizatiei tinta si pentru a asigura o aceeasi intelegere a organizatiei
tinata de catre client, utilizatorii finali si dezvoltatori.
Se definesc cazurile de utilizare a sistemului si actorii. Se dezvolta un plan initial al
proiectului – se impart cerintele in subseturi care vor fi implementate in diferite
iteratii. Se defineste o arhitectura de nivel inalt a produsului software.

Iteratiile
Scopul fiecarei iteratii este de a produce un produs executabil prin care se poate
demonstra partilor interesate o parte din functionalitatile viitorului produs.
Durata unei iteratii depinde de proiect, cu cat o iteratie e mai scurta cu atat mai
usor se primeste feedback. Obiectivele unei iteratii se stabilesc pe baza iteratiilor
precedente.
In fiecare iteratie se adauga functionalitati noi proiectului anterior si, la nevoie, se
modifica prototipul anterior pe baza feedbackului.
Avantaje:
 In fiecare etapa e livrat un executabil
 Flexibil in schimbarea cerintelor
 E mai usor de depanat
Dezavantaj: arhitectura intiiala e greu de testat, si se poate ajunge la o abordare
“build and fix”, deci afecteaza calitatea produsului final.
Calitatea produselor software

Calitatea unui produs e definita ca totalitatea caracteristicilor prin care el

satisface o serie de necesitati. Calitatea unui produs e data de capacitatea sa de a
putea fi utilizat eficient, efectiv si confortabil.
Vederea externa – black box view
Consumatori ai produselor sau serviciilor software:
 clienti – responsabili pentru achizitia produselor software
 utilizatori – cei care folosesc produsul
Vederea interna – white box view
Producatori software – orice persoana implicata in dezvoltare.

Calitatea software din perspectiva consumatorului

Functionalitatea – produsul indeplineste functiile specificate
Fiabilitatea – produsul indeplineste functiile corect, in utilizari repetate
Alte aspecte – usurinta de utilizare/instalare, portabilitate.
Calitatea software din perspectiva dezvoltatorului
Principala calitate e ca produsul software sa fie conform cu specificatia.
Pentru manageri: alegerea unui proces de dezvoltare adecvat.
Pentru cei implicati in oferirea serviciului: usurinta de utilizare
Pentru cei cu mentenanta: usurinta de intretinere
Modelul de calitate ISO 9126

Este un model de calitate software, organizat ierarhic in doua nivelul. Pe primul

nivel sunt 6 caracteristici de calitate de nivel inalt.
1. Functionalitatea – produsul realizeaza un set de functii specificate, care
satisfac necesitatile definite sau implicite;
a. Adecvarea – functiile oferite sunt adecvate scopului produsului
b. Precizia – rezultatele furnizate sunt corecte/agreate
c. Interoperabilitatea – capacitatea produsului de a interactiona cu
sistemele specificate
d. Securitatea – previne accesul neautorizat la program/date?
2. Fiabilitatea – se comporta conform specificatiilor in conditiile definite
a. Maturitaea – atribut bazat pe frecventa caderilor in timpul operarii
b. Toleranta la defecte
3. Usurinta de utilizare – e usor de inteles, invatat si operat?
4. Eficienta
5. Usurinta de intretinere
6. Portabilitatea

Modelul de calitate ISO/IEC 25010

1. Functionalitatea
2. Fiabilitatea
3. Eficienta
4. Securitatea
5. Compatibilitatea
6. Usurinta de intretinere
7. Usurinta de utilizare
8. Portabilitatea