Procese de Dezvoltare Software

Procese de dezvoltare software n practic
Metode de dezvoltare software

Procese de dezvoltare software
16.02.2015
Alin tefnescu
de la https://weblogs.java.net/blog/chet/archive/2008/01/crystal_methodo.html
Varianta detaliat
Procese de dezvoltare software
Prezentare bazat pe materiale de: Florentin Ipate (FMI UniBuc) - note de curs
i Ian Sommerville: Software Engineering 9th edition
de la geek-and-poke.com
Procesul de dezvoltare
cascad (waterfall)
Cerine
Avantaje i dezavantaje
n
n
Design
fiecare etap nu trebuie sa nceap nainte ca precedenta s fie ncheiat.

fiecare faz are ca rezultat unul sau mai multe documente care trebuie
aprobate
bazat pe modele de proces folosite pentru productia de hardware

Avantaj: proces bine structurat, riguros, clar; produce sisteme robuste
n
Implementare
Testare
Mentenan
Etapele procesului cascad

n
analiza i definirea cerinelor: Sunt stabilite serviciile, constrngerile i

scopurile sistemului prin consultare cu utilizatorul. (ce trebuie s fac
sistemul).
design: Se stabilete o arhitectur de ansamblu i funciile sistemului

software pornind de la cerine. (cum trebuie s se comporte sistemul).
implementare i testare unitar: Designul sistemului este transformat ntro mulime de programe (uniti de program); testarea unitilor de program
verific faptul c fiecare unitate de program este conform cu specificaia.
integrare i testare sistem. Unitile de program sunt integrate i testate

ca un sistem complet; apoi acesta este livrat clientului.
operare i mentenan. Sistemul este folosit n practic; mentenana

include: corectarea erorilor, mbuntirea unor servicii, adugarea de noi
funcionaliti.
Probleme:
dezvoltarea unui sistem software nu este de obicei un proces liniar;
etapele se ntreptrund
metoda ofer un punct de vedere static asupra cerinelor
schimbarile cerinelor nu pot fi luate n considerare dup aprobarea
specificaiei
nu permite implicarea utilizatorului dup aprobarea specificaiei
Concluzie: Modelul cascad trebuie folosit atunci cand cerinele sunt bine
nelese i cnd este necesar un proces de dezvoltare clar i riguros.
Procesul incremental
Idee: un sistem de succes de mare dimensiune ncepe cu un sistem de
succes de mic dimensiune care apoi crete puin cte puin (Gilb, 1988)
n
sunt identificate cerinele sistemului la nivel nalt, dar, n loc de

a dezvolta i livra un sistem dintr-o dat, dezvoltarea i livrarea
este realizat n pri (incremente), fiecare increment
ncorpornd o parte de funcionalitate.
cerinele sunt ordonate dup prioriti, astfel nct cele cu

prioritatea cea mai mare fac parte din primul increment, etc.
dup ce dezvoltarea unui increment a nceput, cerinele pentru

acel increment sunt ngheate, dar cerinele pentru noile
incremente pot fi modificate.
Avantajele procesului incremental

Avantaje:
n clienii nu trebuie s atepte pn ce ntreg sistemul a fost livrat pentru a
beneficia de el. Primul increment include cele mai importante cerine, deci
sistemul poate fi folosit imediat.
n primele incremente pot fi prototipuri din care se pot stabili cerinele pentru
urmtoarele incremente.
n se micoreaz riscul ca proiectul s fie un eec deorece prile cele mai
importante sunt livrate la nceput.
n deoarece cerinele cele mai importante fac parte din primele incremente,
acestea vor fi testate cel mai mult.
Probleme:
n
n
n
dificulti n transformarea cerinelor utilizatorului in incremente de mrime

potrivit.
procesul nu este foarte vizibil pentru utilizator (nu e suficient documentaie
ntre iteraii)
codul se poate degrada n decursul ciclurilor
Exemple de procese incrementale

Exist multe variante de procese de dezvoltare incrementale:
n
Unified Process cu varianta Rational Unified Process (RUP)
procese de dezvoltare n spiral introduse de Boehm
procese de dezvoltare agile. Exemple:

programare extrem (XP - extreme programming)
scrum
Rational Unified Process
de la n-ix.com
Metodologii agile
Prezentare bazat pe Ian Sommerville: Software Engineering 9th edition
Boehm spiral model
Metodologii agile
n
Metodele de dezvoltare software expeditive" dezvoltare la

mijlocul anilor 1990 ca o reacie la aa-numitele metode
elaborate", care au fost caracterizate drept puternic
reglementate i rigide (v. modelul cascad)
Puin istorie:
criza software 1960: depirea timpilor de livrare i a
bugetelor, conjugate cu nivelul sczut al calitii soluiilor.
- soluia #1: metodele structurate (80)
- soluia #2: metodologiile orientate obiect (OO)
cronicizarea crizei anilor 60
- soluia #3: mbunatirea proceselor software (CMM)
- soluia #4: metodologiile agile
Metodologii agile
n
nemulumirea cu cheltuielile implicate n metodele de proiectare

de software din anii 80 i 90 a condus la crearea metodelor agile.
aceste metode:
se concentreaz mai mult pe cod dect pe proiectare
se bazeaz pe o abordare iterativ de dezvoltare de software
produc rapid versiuni care funcioneaz, acestea evolund
repede pentru a satisface cerine n schimbare.
scopul metodelor agile este de a reduce cheltuielile n procesul
de dezvoltare a software-ul (de exemplu, prin limitarea
documentaiei) i de a rspune rapid cerinelor n schimbare.
n 2001, este publicat i semnat de mai muli practicieni
Manifestul Agil, care exprim succint principiile metodelor agile.
Agile Manifesto
Cele 12 principii ale manifestului agil

http://agilemanifesto.org/iso/ro/principles.html
1. Prioritatea noastr este satisfacia clientului prin livrarea

rapid i continu de software valoros.
2. Schimbarea cerinelor este binevenit chiar i ntr-o faz
avansat a dezvoltrii. Procesele agile valorific
schimbarea n avantajul competitiv al clientului.
3. Livrarea de software funcional se face frecvent, de
preferin la intervale de timp ct mai mici, de la cteva
sptmni la cteva luni.
4. Clienii i dezvoltatorii trebuie s colaboreze zilnic pe
parcursul proiectului.

http://agilemanifesto.org/iso/ro/
Noi scoatem la iveal modaliti mai bune de dezvoltare de
software prin experien proprie i ajutndu-i pe ceilali.
Prin aceast activitate am ajuns s apreciem:
5. Construiete proiecte n jurul oamenilor motivai. Ofer-le

mediul propice i suportul necesar i ai ncredere c
obiectivele vor fi atinse.
indivizii i interaciunea naintea proceselor i uneltelor
software-ul funcional naintea documentaiei vaste
6. Cea mai eficient metod de a transmite informaii nspre i

n interiorul echipei de dezvoltare este comunicarea fa n
fa.
colaborarea cu clientul naintea negocierii contractuale
7. Software funcional este principala msur a progresului.
receptivitatea la schimbare naintea urmririi unui plan
8. Procesele agile promoveaz dezvoltarea durabil.

Sponsorii, dezvoltatorii i utilizatorii trebuie s poat
menine un ritm constant pe termen nedefinit.
Cu alte cuvinte, dei exist valoare n elementele din dreapta, le

apreciem mai mult pe cele din stnga.
Posibile probleme cu metodologiile agile
9. Atenia continu pentru excelen tehnic i design bun

mbuntete agilitatea.
10. Simplitatea arta de a maximiza cantitatea de munc
nerealizat este esenial.
11. Cele mai bune arhitecturi, cerine i design se obin de
ctre echipe care se auto-organizeaz.
12. La intervale regulate, echipa reflecteaz la cum s devin
mai eficient, apoi i adapteaz i ajusteaz
comportamentul n consecin.
Aplicabilitatea metodelor agile

n
n companiile care dezvolt produse software de

dimensiuni mici sau mijlocii.
n cadrul companiilor unde se dezvolt software pentru uz

intern (proprietary software), deoarece exist un
angajament clar din partea clientului (intern) de a se implica
n procesul de dezvoltare i deoarece nu exist o mulime de
reguli i reglementri externe care afecteaz software-ul.
datorit orientrii lor pe echipe mici i bine integrate, exist

probleme n scalarea metodelor agile pentru sistemele mari
(dei i n acest caz se pot realiza anumite componente ale
sistemului n mod agil).
dificultatea de a pstra interesul clienilor implicai n acest

procesul de dezvoltare pentru perioade lungi
membrii echipei nu sunt ntotdeauna potrivii pentru

implicarea intens care caracterizeaz metodele agile
prioritizarea modificrilor poate fi dificil atunci cnd exist

mai multe pri interesate
meninerea simplitii necesit o munc suplimentar
contractele pot fi o problem ca i n alte metode de

dezvoltare incremental
Metodologii agile
Exemple de metodologii agile:
n
Extreme Programming (XP) - 1996
Adaptive Software Development (ASD)
Test-Driven Development (TDD)
Feature Driven Development (FDD)
Behavior Driven Developement (BDD)
Crystal Clear
Scrum - 1995
etc.
Programare extrem
XP i principiile agile
n
dezvoltarea incremental este susinut prin intermediul

livrrii de software n mod frecvent cu mici incremente.
implicarea clientului nseamn angajamentul full-time al

clientului cu echipa de dezvoltare.
oameni, nu procese prin programare pereche, proprietatea

colectiv i un proces care s evite orele lungi de lucru.
receptivitate la schimbare prin livrri frecvente
meninerea simplitii prin refactoring constant de cod.
de la spottedpaint.com
Programare extrema (XP)
Valorile XP
poate cea mai cunoscut metod agil.
Simplitate (Simplicity)
Extreme Programming (XP) are o abordare "extrem" de

dezvoltare incremental:
Comunicare (Communication)
Reacie (Feedback)
Curaj (Courage)
Respect (Respect)
noile versiuni pot fi construite de mai multe ori pe zi;

acestea sunt livrate clienilor la fiecare 2 sptmni;
toate testele trebuie s fie executate pentru fiecare
versiune i o versiune e livrabil doar n cazul n care
testele au rulat cu succes.
Informaii: http://www.extremeprogramming.org
Practici XP
n
procesul de planificare (The Planning Game)
client disponibil pe tot parcursul proiectului (On-Site Customer)
Livrri frecvente
n
livrri ct de des este posibil, cu condiia s existe o plus-valoare

pentru client
implementare treptat (Small Releases)
acest lucru asigur feedback-ul rapid
limbaj comun (Metaphor)
clientul are funcionalitatea esenial ct mai curnd posibil
integrare continu (Continuous Integration)
proiectare simpl (Simple Design)
timp ntre livrri de la o sptmn pn la o lun

(proiectele non-XP au termene de jumtate de an sau mai mult)
testare (Testing)
rescriere de cod pentru mbuntire (Refactoring)
programare n pereche (Pair Programming)
drepturi colective (Collective Ownership)
40 ore/sptmn (40-Hour Week)
standarde de scriere a codului (Coding Standard)
Planificare
n
Joc de planificare a livrrilor: clieni i

dezvoltatori.
Joc de planificare a iteraiilor: doar

dezvoltatorii
Clientul nelege domeniul de aplicare,

prioritile, nevoile business ale versiunilor care
trebuie livrate:
sorteaz cartonaele cu sarcini dup
prioriti
Dezvoltatorii estimeaz riscurile i eforturile:

sorteaz cartonaele dup risc
dac o sarcin ia mai mult de 2-4 sptmni,
e distribuit pe mai multe cartonae
Metafora
metafora este de fapt cuvntul-cheie XP pentru ceea ce ali

ingineri numesc arhitectura sistemului
se evit cuvntul arhitectur pentru a sublinia faptul c nu avem

de-a face doar cu structura general a sistemului
metafora sugereaz o coeren general, uor de comunicat,

plus mai mult maleabilitate
Integrare continu
n
codul este integrat i testat cel mult cteva ore sau o zi de cnd
este scris.
de exemplu, atunci cnd dezvoltatorii au terminat o parte din

implementare:
Testare
n
se testeaz tot ceea ce ar putea fi problematic.
programatorii scriu teste unitare folosind un cadru de testare

automatizat (de exemplu, JUnit) pentru a minimiza efortul de
scriere i verificare a testelor.
o integreaz cu codul existent
clienii, cu ajutorul dezvoltatorilor, scriu teste funcionale.
ruleaz teste i corecteaz eventualele probleme
de multe ori, se aplica metoda test-driven development:
daca toate testele sunt pozitive, adaug modificrile n

sistemul care se ocupa cu managementul codului surs.
se scriu teste naintea codului pentru a clarifica cerinele

testele sunt scrise ca programe n loc de date, astfel nct
acestea s poat fi executate automat.
fiecare testul include o condiie de corectitudine
toate testele anterioare i cele noi sunt rulate automat atunci
cnd sunt adugate noi funcionaliti, verificnd astfel c noua
funcionalitate nu a introdus erori.
Proiectare simpl
n
principiul de baz: proiectez cel mai simplu lucru care

funioneaz acum. Nu proiecta i pentru mine, pentru c sar putea s nu fie nevoie
deci, proiecteaz doar pentru a satisface cerinele i nimic
n plus
mbuntirea codului
n
mbuntirea codului prin refactoring este foarte important

deoarece XP recomand nceperea implementarii foarte repede
simplificarea codului duce la o mai bun nelegere a lui, astfel

compensnd lipsa documentaiei n anumite situaii
exemplu (three strikes and you refactor) eliminarea duplicrii:

daca o bucat de cod similar apare n trei locuri, se scrie codul
respectiv ntr-o metod care e folosit n cele trei locuri.
Programarea n echipe de doi

n
tot codul este scris de dou persoane folosind un singur

calculator
sunt dou roluri n aceast echip: Unul scrie cod i celallalt l

ajut gndindu-se la diverse posibiliti de mbuntire.
al doilea ncearc s rspund la urmtoarele:
Pair programming n practic
merge abordarea curent?

care sunt testele care s-ar putea s nu funcioneze?
exist simplificri posibile?
Avantajele programrii n doi
Drepturi colective asupra codului
susine ideea de proprietate i responsabilitate n echip pentru

sistemul colectiv.
nu exist situaia n care cineva are anumite module pe care

nimeni altcineva nu le poate atinge.
proces de revizuire mbuntit, deoarece fiecare linie de cod

este privit de ctre cel puin dou persoane (four eyes
principle).
dac cineva vede o modalitate de a mbunti ceva, va face

toate modificrile necesare n sistem (desigur e nevoie de un
sistem bun de versionare i management a codului).
ajut la mbuntirea codului.
transfer de cunotine i training implicit (important cnd membrii

echipei se schimb)
more fun?
40 de ore pe sptamn
n
sptmna de lucru de maxim 40 de ore
oamenii au nevoie de odihna necesar pentru a munci eficient i

a produce cod de calitate nalt
exist sptmni cnd e necesar s se lucreze mai mult, dar

aceasta trebuie s fie o excepie
Codul scris in mod standardizat

n
ntreaga echip ader la un set unic de convenii cu privire la

modul n care codul este scris
scopul este de facilita programarea n doi i proprietatea

colectiv a codului
Ciclul de dezvolare XP
Planificare i iteraii XP
Lucrul cu codul n XP
Dezavantaje XP
n
nu este scalabil
necesit mai multe resurse umane pe linie de cod(d.ex.

programare n doi)
implicarea clientului n dezvoltare (costuri suplimentare i

schimbri prea multe)
lipsa documentelor oficiale
necesit experien n domeniu (senior level developers)
poate deveni uneori o metoda ineficient (rescriere masiv

de cod)
Avantaje XP
n
soluie bun pentru proiecte mici
programare organizat
reducerea numrului de greeli
clientul are control (de fapt, toat lumea are control, pentru
c toi sunt implicai n mod direct)
dispoziie la schimbare chiar n cursul dezvoltrii
SCRUM
Metoda Scrum
Scrum n practic
Scrum este o metod agil, care se axeaz mai mult pe

managementul dezvoltrii incrementale, dect pe practici agile
specifice.
sprint
zilnic
backlog-ul
produsului
sprint
(2-4 spt.)
backlog-ul
sprintului
de
la
so
fth
ou
se
ed
uc
ati
on
.co
versiune
incremental
Learning Scrum
Scrum pe scurt
n
un proprietar de produs creeaz

o list de sarcini numit backlog
apoi se planific ce sarcini vor fi implementate n urmtoarea

iteraie, numit sprint.
aceast list de sarcini se numete sprint backlog.
sarcinile sunt rezolvate n decursul unui sprint care are

rezervat o perioad relativ scurt de 2-4 sptmni
echipa se ntrunete zilnic pentru a discuta progresul (daily

scrum). Ceremoniile sunt conduse de un scrum master.
la sfritului sprintului, rezultatul ar trebui s fie livrabil (adic

folosit de client sau vandabil).
dup o analiz a sprintului, se reitereaz.
Prezentare Scrum
O prezentare concis despre Scrum poate fi vizualizat la linkul

de mai jos (prezentarea va fi ncrcat i n Moodle):
http://www.slideshare.net/calin.iepure/cu-degetul-in-scrum
Tool-uri pentru agile
O comparaie de final
Exist foarte multe tool-uri pentru metodele i practicile agile.

Cteva exemple:
http://agilescout.com/best-agile-scrum-tools/
Metode agile
Metode cascad
Metode formale
criticalitate sczut
criticalitate ridicat
criticalitate extrem
dezvoltatori seniori
dezvoltatori juniori
dezvoltatori seniori
cerine in schimbare
cerine relativ fixe
cerine limitate
echipe mici
echipe mari
echipe mici
cultur orientat
spre schimbare
cultur orientat
spre ordine
cultur orientat spre

calitate i precizie
https://www.scrumwise.com/scrum/#
http://www.acunote.com/how-it-works
http://asana.com pentru lucru n echip (nu neaprat agil)
Cteva exemple
Tehnicile agile sunt folosite n foarte multe companii, dei multe
dintre ele nu folosesc explicit termenul de agile.
Cteva referine:
n
Google: http://georgekontopidis.com/blog/2011/googles-agile-practices/
Facebook: http://www.facebook.com/note.php?note_id=409881258919
SAP: http://scn.sap.com/community/agile-software-engineering
Microsoft: http://msdn.microsoft.com/en-us/vstudio/aa718795.aspx
IBM: http://www.ibm.com/software/rational/agile/

Specificaii formale - Limbajul Z
23.02.2015
Alin tefnescu
relaii
scheme
exemple
mulimi
recapitulare
Introducere
Z, B, Event-B
n
Jean-Raymond Abrial (1938- )
Inventatorul metodelor formale Z i B
Z dezvoltat n anii 70s, standartizat in 2002
B dezvoltat n ani 90, aplicat cu succes n industrie
Event-B dezvoltat n anii 00 ca succesor al lui B
B folosit la dezvoltarea de software n transport (metroul

din Paris, New York etc.). La Paris, 110.000 linii cod B
au generat 80.000 linii de cod Ada pentru automatizarea
controlului pe o linie fr conductor
Event-B - tooluri nc in dezvoltare (Univ. din Bucureti a

participat de curnd la un proiect european mpreun cu
Siemens, Bosch, etc.)
n continuare prezentam cteva elemente ale notaiei Z
Specificaii formale
O specificaie formal:
- folosete notaii matematice pentru a descrie ntr-un model

precis ce proprieti trebuie s aib un sistem
- descrie ce trebuie s fac sistemul i nu cum

- independent de cod
- poate fi folosit pentru nelegerea cerinelor i analiza lor
(uneori se poate si genera cod dintr-o specificaie suficient
de precis)
n Z descompunerea unei specificaii se face n mai multe
piese numite scheme
Introducere
Referine
Operatori
Mulimi
Mulimi
Operaii pe mulimi
Operaii pe mulimi
Tipuri
Tipuri
Tipuri compuse
Variabile
Abrevieri sintactice
Definiii axiomatice
Relaii
Operaii pe relaii
(DE REINUT)
Operaii pe relaii
Funcii
(DE REINUT)
(DE REINUT)
Scheme
Scheme
Scheme
Schemele ca tipuri/mulimi
Incluziunea schemelor
Exemplu
Incluziunea schemelor
Mulimea tuturor datelor valide poate fi reprezentat ntr-o schem
Scheme generice
Conjuncii de scheme
Redenumirea variabilelor
Disjuncii de scheme
Exemplu: bilete la teatru
Schemele ca operaii
Schemele ca operaii
Schemele ca operaii
Operatorul Delta
Operatorul Xi
Exemplu Delta, Xi
Exemplu Delta, Xi
Exemplu Delta, Xi
Cuantificarea (ascunderea variabilelor) n scheme
Compunerea schemelor de operaii
Compunerea schemelor de operaii
Exemplu
Negocierea cerinelor n practic

Cerine software
02.03.2015
Alin tefnescu
de la dilbert.com
Despre cerine
n Cerinele
sunt descrieri ale serviciilor oferite de sistem i a

constrngerilor sub care acesta va fi dezvoltat i va opera
Cerine
n Cerinele
pornesc de la afirmaii abstracte de nivel nalt pn

la specificaii matematice funcionale detaliate (d.ex. Z)
n Cerinele
ndeplinesc mai multe funcii:
pot constitui baza negocierilor pentru un contract ca

atare trebuie s fie deschise diverselor interpretri
Prezentare bazat pe:

Software Engineering 9th ed. (2011) de Ian Sommerville
http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/
pot constitui baza contractului n sine ca atare trebuie

definite ct mai detaliat
Tipuri de cerine
n Cerine
utilizator
Utilizatorii documentului cu cerine

n clienii:
impun cerinele i verific apoi dac acestea sunt

conforme cu nevoile lor. Pot cere modificri ale cerinelor.
afirmaii n limbaj natural i diagrame a serviciilor oferite de

sistem laolalt cu constrngerile operaionale.
scrise pentru clieni.
n Cerinele
sistemului
un document structurat stabilind descrierea detaliat a

funciilor sistemului, serviciile oferite i constrngerile
operaionale.
poate fi parte a contractului cu clientul.
Utilizarea cerinelor
n Cerinele
utilizator se adreseaz:
utilizatorilor finali
inginerilor clientului
proiectanilor de sistem
managerilor clientului
managerilor de contracte
n Cerinele
de sistem se adreseaz:
utilizatorilor finali
inginerilor clientului
proiectanilor de sistem
programatorilor
managerii: utilizeaz documentul pentru a stabili termenii

contractului i a planifica procesul de producie
n inginerii
de sistem: utilizeaz documentul pentru a nelege

ce trebuie dezvoltat
n inginerii
de la testare: utilizeaz documentul pentru a

proiecta testele de validare
Cerine funcionale i non-funcionale

n Cerine
funcionale:
afirmaii despre servicii pe care sistemul trebuie s le
conin, cum trebuie el s rspund la anumite intrri i
cum s reacioneze n anumite situaii.
n Cerine
non-funcionale:
constrngeri ale serviciilor i funciilor oferite de sistem
cum ar fi: constrngeri de timp, constrngeri ale procesului
de dezvoltare, standarde, etc.
Cerine funcionale
Tipuri de cerine non-funcionale

n Cerine
n Descriu
funcionalitatea sistemului i serviciile oferite
n Depind
de tipul softului, de utilizatorii avui n vedere i de

tipul sistemului pe care softul este utilizat
n Cerinele
funcionale ale utilizatorilor pot fi descrieri de

ansamblu dar cerinele funcionale ale sistemului trebuie s
descrie n detaliu serviciile oferite
ale produsului
Cerine care specific un anumit comportament al

produsului. D.ex.: gradul de utilitate, eficien (vitez de
execuie), fiabilitate, portabilitate etc.
n Cerine
legate de organizare
Cerine care sunt consecine ale politicilor de organizare a

produciei software. D. ex.: standarde utilizate, cerine de
implementare, cerine de livrare etc.
n Cerine
externe
Cerine asociate unor factori externi. D. ex.: cerine de

interoperabilitate, cerine legislative etc.
Cerine non-funcionale
n Definesc
proprieti i constrngeri ale sistemului.

D.ex.: fiabilitatea, timpul de rspuns, cerinele pentru spaiul
de stocare, cerine ale sistemului de intrri-ieiri etc.
n La
ntocmirea lor se va ine cont de un anumit mediu de

dezvoltare, limbaj de programare sau metod de dezvoltare
n Cerinele
non-funcionale pot fi mai critice dect cele

funcionale. Dac nu sunt ndeplinite, sistemul nu va fi util
scopului n care a fost dezvoltat.
Tipuri de cerine non-funcionale

Proprietate
Exprimare (exemple)
Vitez
Tranzacii/sec; Timp de rspuns la utilizator
Dimensiune
MB; Nr. de cipuri necesare
Uurina utilizrii
Timp de nvare; dimensiunea help-ului
Fiabilitate
Timpul mediu dintre dou defecte;

Rata de apariie a defectelor
Robustee
Probabilitatea de corupere a datelor la eroare;

Timpul de restart dup apariia unui defec
Portabilitatea
Procentul de linii de cod dependente de inta

implementrii; Numrul de sisteme int
Cerine ale utilizatorilor
Cerinele sistemului
n Cerinele
utilizator trebuie s descrie cerine funcionale i

non-funcionale ntr-o manier n care sunt pe nelesul
utilizatorilor sistemului care nu dein cunotine tehnice
detaliate.
n cerinele
sistemului sunt specificate mai detaliat dect

cerinele utilizator
n scopul
principal al lor este acela de a fi baza proiectrii

sistemului
n cerinele
trebuie s exprime ce poate face sistemul, iar

proiectul trebuie s exprime cum se poate implementa
sistemul
n ele
pot fi incorporate n contract
de la dilbert.com
Recomandari pentru scrierea cerinelor

n adoptarea
unui format standard i utilizarea lui la toate
cerinele
limbajului ntr-un format consistent. E bine s se
foloseasc trebuie pentru cerinele obligatorii i ar trebui
pentru cele opionale
n evidenierea
textului care identific prile importante ale
cerinelor
n dac
n Prefa
n Introducere
n utilizarea
n evitarea
Structura documentului de specificare a cerinelor
jargonului
este cazul, includerea unei explicaii de ce este

necesar o anumit cerin
n Glosar
de termeni
n Definirea
cerinelor utilizatorilor
n Arhitectura
sistemului
n Specificarea
n Modelarea
n Evoluia
n Anexe
n Index
cerinelor de sistem
sistemului
sistemului
Posibiliti de reprezentare a cerinelor

n limbaj
natural: Cerinele sunt organizate n paragrafe

numerotate.
n limbaj
natural structurat: utilizarea unui format standard

sau a machetelor n conjuncie cu limbajul natural
n limbaj
de proiectare: asemntor unui limbaj de programare

dar mai abstract (nu prea se mai folosete)
n limbaj
grafic suplimentat cu adnotri textuale (mai ales

pentru cerine sistem), cum ar fi UML.
n specificaii
matematice: concepte matematice lucrnd cu

maini cu stri finite sau relaii peste mulimi - Z, B. Elimin
ambiguitile, dar pot fi dificil de neles.
Exemplu pomp de insulin
n Cerina
3.2: Sistemul msoar glicemia la fiecare 10 minute

i, dac e nevoie, pompeaz insulin.
(Explicaie: Modificarea glicemiei e relativ lent, astfel c
msurtori mai frecvente nu sunt necesare. Pe de alt parte,
msurtori prea rare pot rata valori periculoase ale glicemiei.)
n Cerina
3.6: Sistemul va rula un test intern o dat pe minut

pentru a verifica funcionarea corect a pompei, conform
tabelului 1.
(Explicaie: Un test intern poate detecta probleme hardware
sau software, alertnd utilizatorul n cazul unor
disfuncionaliti.)
Exemplu de cerin structurat

Insulin Pump / Control Software / SRS / 3.3.2
n Colecteaz
date de la
senzorul pentru glicemie
(zahrul din snge) i
calculeaz cantitatea de
insulin care trebuie injectat
Function: Calculeaz doza de insulin pentru a menine glicemia n

limite normale.
Description: Calculeaz doza de insulin care trebuie injectat pentru
a menine glicemia n limitele normale de 3-7 uniti.
Inputs: Valoarea curent (r2); dou valori anterioare (r0 i r1).
n Calculul
se bazeaz pe
diferenele glicemiei n timp.
Source: Valoarea citit de senzor. Celelalte valori din memorie.
n Trimite
semnale cu valoarea
dozei de insulin unei
micropompe.
corect este
critic pentru sntatea
pacientului.
Exemple de cerine n limbaj natural
Outputs: CompDose - doza de insulin care trebuie injectat.

Destination: Ciclul de control al pompei.
n Funcionarea
de la lenny-diabetes.com
Exemplu de cerin structurat continuat

Insulin Pump / Control Software / SRS / 3.3.2 (continuare)
Action: CompDose este zero dac glicemia e stabil sau scade, sau
dac nivelul ei crete, dar rata de cretere e n scdere. Dac
nivelul crete i rata de cretere de asemenea crete, atunci
CompDose se calculeaz mprind la 4 diferena dintre r2 i r1 i
rotunjind rezultatul. Daca rezultatul rotunjit este zero, atunci
CompDose ia valoarea predefinit a dozei minime.
Requirements: Doua valori anterioare pentru a putea calcula rata
de schimbare a glicemiei.
Pre-condition: Rezervorul de insulin conine cel puin valoarea
maxim permis a unei doze de insulin.
Post-condition:
r0 este nlocuit cu r1 i r1 cu r2.

Diagrame UML
02.03.2015
Alin tefnescu
Side effects Niciunul.
Specificaie tabelar (completeaz limbajul natural)

Condiie
Aciune
Nivelul glicemiei scade: (r2 < r1)
CompDose := 0
Nivelul glicemiei stabil: (r2 = r1)
CompDose := 0
Nivelul glicemiei crete i rata de cretere

CompDose := 0
descrete: 0 < (r2-r1) < (r1-r0)
UML
CompDose := round ((r2-r1)/4)

Nivelul glicemiei crete i rata de cretere
e stabil sau crete: (r2-r1) (r1-r0) > 0 Dac rezultatul de mai sus e 0,
CompDose := MinimumDose
Bonus: o specificaie n notaia Z pentru pompa cu insulin

poate fi studiat aici: http://ifs.host.cs.st-andrews.ac.uk/Books/
SE9/WebChapters/PDF/Ch_27_Formal_spec.pdf
de la wikipedia.org
UML n practic
De ce modelm?
O scurt istorie a modelrii
modele statice (structurale): aprute destul de devreme,

ca desene, nu obiecte.
modele dinamice: d.ex. flowcharts (Gilbreth 1921),

automate finite (McCulloch-Pitts 1943), statecharts (Harel
1980), diagrame de secvene (1990) etc.
Astfel, diverse tipuri de modele pentru sisteme (software)

au fost studiate de-a lungul timpului.
ns modelarea a devenit foarte vizibil dup introducerea

paradigmei orientate pe obiecte (OO).
Modelarea orientat pe obiecte
Complexitatea e o problem n dezvoltarea programelor.
n anii 80 i nceputul anilor 90 a avut loc o dezvoltare

foarte puternic a paradigmei OO.
Folosirea unor modele poate nlesni abordarea

complexitii.
o mulime de experi OO, fiecare cu compania, tool-ul,

cartea i modul de modelare propriu
Un model este o reprezentare abstract, de obicei grafic,

a unui aspect al unui sistem.
printre ei i Booch, Rumbauch, Jacobson, denumii the

three amigos, cei care au iniiat Unified Modeling
Language (UML)
Consoriul OMG (Object Management Group) a reuit s

standardizeze UML:
1997 - UML 1.0
2011 - UML 2.4
Acesta permite o mai bun nelegere a sistemului i

analiza unor proprieti ale acestuia.
Cele 14 tipuri de diagrame UML

UML este un limbaj grafic pentru vizualizarea, specificarea, construcia i
documentaia necesare pentru dezvoltarea de sisteme software (OO)
complexe.
Tipurile de diagrame UML 2.0:
Motive pentru care UML este folosit

n
UML este standardizat
existena multor tool-uri
flexibilitate: modelarea se poate adapta la diverse domenii

folosind profiluri i stereotipuri
portabilitate: modelele pot fi exportate n format XMI (XML

Metadata Interchange) i folosite de diverse tool-uri
se poate folosi doar o submulime de diagrame
arhitectura software e important
de la wikipedia.org
Motive pentru care UML nu este folosit
Tipuri de folosire UML
Nu este cunoscut notaia UML
UML e folosit n diverse moduri n proiecte sau organizaii:
UML e prea complex (14 tipuri de diagrame)
Notaiile informale sunt suficiente
diagrame UML pentru a schia doar diverse aspecte ale

sistemului
Documentarea arhitecturii nu e considerat important
diagrame UML care apar n documente (uneori dup ce a

fost fcut implementarea)
diagrame UML foarte detaliate sunt descrise n tool-uri

nainte de implementare i apoi cod este generat pe baza
acestor modele
Tool-uri UML
Cazuri de utilizare n practic
Exist foarte multe tool-uri pentru UML:

http://en.wikipedia.org/wiki/List_of_UML_tools
Cteva tool-uri gratuite (care mi s-au prut ok):
n
Visual Paradigm for UML - (community edition, gratuit)

http://www.visual-paradigm.com/download/community.jsp
Astah (community edition, gratuit)

http://astah.net/download#community
Violet UML Editor (gratuit, Java-based):

http://violet.sourceforge.net
LucidChart (gratuit pentru universiti, web-based, iPad app)

https://www.lucidchart.com
Visio 2013 Professional (gratuit pentru studeni prin Dreamspark)
Cazuri de utilizare (Use Cases)

Introduse de Ivar Jacobson la nceputul anilor 90.
Adoptate n standardul UML.
Cazuri de utilizare
Descriu comportamentul sistemului din punct de

vedere al utilizatorului
Dou pri principale:

sistem (componente i descrierea acestora)
utilizatori (elemente externe)
Cuprinde:
Diagrama cazurilor de utilizare
Descrierea cazurilor de utilizare
Diagrama cazurilor de utilizare - un exemplu
Actori
de la wikipedia.org
Un actor reprezinta un rol jucat de un utilizator.
Nu reprezint un singur utilizator, ci o clas de utilizatori.
Acelai utilizator poate avea diferite roluri (d.ex. Personal

sau ClientCarte), dup cum un rol poate fi avut de mai muli
utilizatori.
Identificarea actorilor = identificarea rolurilor avute de

utilizatori n cadrul sistemului
Elementele principale
Caz de utilizare (component a sistemului): unitate

coerent de funcionalitate sau task; reprezentat printr-un
oval.
Actor (utilizator al sistemului): element extern care

interacioneaz cu sistemul; reprezentat printr-o figurin
Asociaii de comunicare: legturi ntre actori i cazuri de

utilizare; reprezentate prin linii solide
Descrierea cazurilor de utilizare: un document (narativ)

care descrie secvena evenimentelor pe care le execut un
actor pentru a efectua un caz de utilizare
Clasificare actori
Pot exista actori primari i actori secundari:

n
Actorii primari sunt cei pentru care folosirea sistemului are o

anumit valoare (beneficiari); de exemplu ClientCarte. De
obicei, actorii principali iniiaz cazul de utilizare.
Actorii secundari sunt cei cu ajutorul crora se realizeaz

cazul de utilizare; de exemplu un sistem pentru gestiunea
unei biblioteci. Actorii secundari nu iniiaz cazul de
utilizare, dar particip la realizarea acestuia.
Actorii pot fi att actori umani ct i sisteme externe.
Cazuri de utilizare
Un caz de utilizare este o unitate coerent de funcionalitate.
Un caz de utilizare nglobeaz un set de cerine ale

sistemului care reies din specificaiile iniiale i sunt rafinate
pe parcurs.
Cazurile de utilizare pot avea complexiti diferite; de

exemplu mprumut carte i Caut carte.
Cazuri de utilizare i scenarii

n
un caz de utilizare reprezint o mulime de scenarii

referitoare la utilizarea unui sistem.
un scenariu este o instan a unui caz de utilizare; de

exemplu, urmtoarele dou scenarii sunt instane ale cazului
de utilizare mprumut carte:
Persoana X mprumut o carte de la bibliotec. Pentru c
ea nu mai are cri mprumutate, primete cartea i
sistemul memoreaz acest lucru.
Persoana Y ncearc s mprumute o carte, dar este
refuzat pentru c mai are deja mprumutate trei cri, care
este numrul maxim posibil.
un caz de utilizare trebuie s fie nsoit de o descriere

(un exemplu de ablon va fi furnizat mai trziu)
Frontiera sistemului
este important de a defini frontiera sistemului astfel nct s

se poat face distincie ntre mediul extern i mediul intern
(responsabilitile sistemului)
ea poate avea un nume
cazurile de utilizare sunt nuntru, iar actorii n afar.
daca se dezvolt un sistem software, frontiera se stabilete

de obicei la frontiera dintre hardware i software.
trasarea frontierei este opional; trebuie ns indicat atunci

cnd exist mai multe subsisteme, pentru a le delimita clar.
Relaia include
Dac dou sau mai multe cazuri de utilizare au o

component comun, aceasta poate fi reutilizat la definirea
fiecruia dintre ele.
n acest caz, componenta refolosit este reprezentat tot

printr-un caz de utilizare legat prin relaia include de
fiecare dintre cazurile de utilizare de baz.
Practic, relaia include arat c secvena de evenimente

descris n cazul de utilizare inclus se gsete i n secvena
de evenimente a cazului de utilizare de baz.
Relaia include
Sgeata este orientat ctre cazul de utilizare care este

folosit i este etichetat cu stereotipul include .
Atunci cnd cazul de utilizare inclus se schimb, acest lucru

va afecta cazul de utilizare de baz, n schimb cazul de
utilizare inclus nu va depinde de cazul de utilizare de baz.
Relaia extend
Relaia extend
De obicei, se folosete pentru a pune in eviden excepiile.

D.ex. putem separa cazul de utilizare mprumut carte ntrun caz de utilizare frecvent ntlnit (principal), n care
utilizatorului i este permis s mprumute o carte i un caz de
utilizare mai rar ntlnit (excepional), n care utilizatorului i
este refuzat mprumutul deoarece depete numrul maxim
de cri permise.
Se poate specifica i punctul de extensie
Atenie i la direcia sgeii (care arat spre cazul principal)
Relaia de generalizare
Acest tip de relaie poate exista att ntre dou cazuri de
utilizare ct i ntre doi actori.
Relaia extend se folosete pentru separarea diferitelor

comportamente ale cazurilor de utilizare.
n
Dac un caz de utilizare conine dou sau mai multe scenarii

semnificativ diferite (n sensul c se pot ntmpla diferite
lucruri n funcie de anumite circumstane), acestea se pot
reprezenta ca un caz de utilizare principal i unul sau mai
multe cazuri de utilizare excepionale.
generalizarea ntre cazuri de utilizare indic faptul c un caz

de utilizare poate moteni comportamentul definit n alt caz
de utilizare.
generalizarea ntre actori arat c un actor motenete

structura i comportamentul altui actor.
Generalizarea este asemntoare cu relaia extend .

De obicei, folosim extend dac descriem un comportament
excepional care depinde de o condiie testat n timpul
execuiei i generalizarea pentru a evidenia o anumit
versiune a unui task.
ablon pentru descrierea cazurilor de utilizare (o variant)

Caz de utilizare
Identificatorul i numrul de referin al cazului de

utilizare, istoria modificrilor
Descriere
Scopul n care e folosit cazul de utilizare i sursa

cerinelor funcionale
Actori
Lista actorilor implicai
Ipoteze
Condiii ce trebuie s fie adevrate ca un caz de

utilizare s se termine cu succes
Pai
Interaciunile dintre actori i sistem care sunt necesare

pentru a atinge scopul n care e folosit cazul de utilizare
Alternative
(opional)
Cerine nonfuncionale
(opional)
Probleme
Orice alternativ ntlnit n paii cazului de utilizare
Atenie!
scopul principal al acestui tip de diagrame este de a arta

relaia dintre actori i cazuri de utilizare, nu relaia dintre
cazuri de utilizare (dei i aceasta este posibil prin relaiile
include sau extend sau generalizare)
nu se arat ordinea diferitelor cazuri de utilizare (aceasta se

poate exprima prin alte diagrame - de stri sau de secven).
deci NU exist linii simple ntre cazuri de utilizare!

(am observat aceast greeal destul de frecvent n decursul
timpului)
Lista cerinelor non-funcionale pe care trebuie s le

ndeplineasc un caz de utilizare
Lista problemelor care rmn s fie rezolvate
nc un exemplu
Descriere la:
http://www.math-cs.gordon.edu/courses/cs211/ATMExample/UseCases.html
Importana cazurilor de utilizare
Cazurile de utilizare descriu funcionalitatea sistemului; adic

modul lui de folosire perceput de utilizatori (actorii externi).
Scopul final al sistemului este de a realiza funcionalitatea

descris n modelul cazurilor de utilizare (alturi de cerinele
nefuncionale).
Cazurile de utilizare sunt folosite pentru:

analiz: identific funcionalitatea cerut i o valideaz
mpreun cu clienii
design i implementare: trebuie realizate
testare: verific sistemul; ele devin baza pentru generare de
cazuri de testare.
Diagrame de secvene (sequence diagrams)

de la agilemodeling.com
tipul de diagram UML care pune n eviden transmiterea de mesaje

(sau apeluri de metode) de-a lungul timpului
foarte asemntoare cu MSC (Message Sequence Charts)

standardizate separat prin ITU Z.120. Diferena principal este faptul c
diagramele de secven sunt orientate spre paradigma OO. Vezi i
http://en.wikipedia.org/wiki/Message_Sequence_Chart#Comparison_to_UML
Diagrame de secvene
Cu exemple din UML basics: sequence diagrams de Donald Bell (IBM)
Diagrame de secven n practic
Manager
Elemente de baz
ef (autohton)
Obiectele i actorii sunt reprezentai la captul de sus al unor linii

punctate, care reprezint linia de via a obiectelor.
Scurgerea timpului este reprezentat n cadrul diagramei de sus n jos.
Un mesaj se reprezint printr-o sgeat de la linia de via a

obiectului care trimite mesajul la linia de via a celui care-l primete.
Timpul ct un obiect este activat este reprezentat printr-un dreptunghi

subire care acoper linia sa de via.
Opional, pot fi reprezentate rspunsurile la mesaje printr-o linie

punctat, dar acest lucru nu este necesar.
Mesaj intern
Creare i distrugere
Un obiect este creat prin plasarea acestuia n

josul paginii, poziia sa corespunznd cu
momentul n care a fost creat obiectul.
n
Un mesaj poate fi intern (nu neaprat ntre dou obiecte diferite)
Tipuri principale de mesaje
Distrugerea unui obiect este reprezentat

printr-un X.
Grzi
mesaj sincron (sau apel de metod). Obiectul

pierde controlul pn primete rspuns
mesaj de rspuns: rspunsuri la mesajele
sincrone; reprezentarea lor este opional.
mesaj asincron: nu ateapt rspuns, cel care
trimite mesajul rmnnd activ (poate trimite alte
mesaje).
[pastDueBalance=0] decide dac mesajul addStudent()

este transmis sau nu
Fragment [opt]
Atunci cnd exist mai

multe mesaje
dependente de o gard,
se folosete fragmentul
(combination fragment):
opt
[gard]
Fragment [loop]
Structurile
repetitive sunt
introduse prin
cuvntul cheie
[loop] urmat de o
un numr care
spune de cte ori
se execut grupul
respectiv sau de o
gard.
(Similar cu
if then
din programare)
Fragment [alt]
i multe altele
Exist multe alte concepte disponibile n diagramele de secvene,

acestea permind modelarea unor scenarii complexe
De exemplu:
[neg]: secvene de mesaje invalide (care nu trebuie s aib loc)
[par]: paralelism
[ref] includerea diagramelor unele n altele
aspecte temporale: cuantificarea trecerii timpului ntre mesaje
invariani
etc.
Similar cu
if then else
exist n diagramele de secvene
alt
[gard]
[else]
Diagrame de clase n practic

Diagrame UML de clase
09.03.2015
Alin tefnescu
de la lolzland.com
Introducere la clase
n
Modelarea unui sistem presupune identificarea lucrurilor

care sunt importante pentru acesta i care formeaz
vocabularul lui. n UML, toate aceste lucruri sunt modelate
folosind noiunea de clas.
O clas nseamn descrierea unei mulimi de obiecte care

au n comun aceleai atribute, operaii, relaii i semnificaii.
Diagramele de clase sunt folosite pentru a specifica

structura static a sistemului, adic:
ce clase exist n sistem i
care este legtura dintre ele.
Diagrame de clase
Recapitulare paradigma orientare pe obiect

n
Obiect: structur software care grupeaz

stri i comportament, folosind conceptul de
ncapsulare
Clas: machet folosit pentru crearea de

obiecte.
Motenire: mecanism natural de organizare

ierarhic a claselor, reutiliznd elemente
comune.
Interfa: un contract ntre o clas i lumea

exterioar. Cnd o clas implementeaz o
interfa, promite s ofere comportamentul
publicat de interfa.
Pachet: organizare a claselor i interfeelor
folosind un spaiu de nume (namespace).
Folosirea pachetelor permite o structurare
mai bun a proiectelor mari.
class Bicycle {
int speed = 0;
int gear = 1;
void changeGear(int newValue) {
gear = newValue;
}
void speedUp(int increment) {
speed = speed + increment;
}
void applyBrakes(int decrement) {
speed = speed - decrement;
}
}
class MountainBike extends Bicycle {
// new fields and methods defining
// a mountain bike go here
}
interface Bicycle {
void changeGear(int newValue);
void speedUp(int increment);
void applyBrakes(int decrement);
}
class MyBicycle implements Bicycle {
// remainder of this class
// implemented as before
}
package ro.unibuc.fmi.bikes;
import ro.unibuc.fmi.bikes.*;
Reprezentarea grafic a unei clase

n
n UML, o clas este prezentat printr-un dreptunghi n

interiorul cruia se scrie numele acesteia:
Abonat
n
Fiecare clas este caracterizat printr-o mulime de

atribute i operaii:
Abonat
atribute
operaii
Atribute
n
Un atribut reprezint o
proprietate a unei clase.
Atributele descriu datele
coninute de obiectele din clasa
respectiv.
Pentru fiecare atribut trebuie

specificat tipul acestuia.
Tipurile folosite pot fi tipuri de
baz sau clase.
Pentru fiecare atribut pot fi

specificate vizibilitatea,
multiplicitatea i valoarea iniial.
Abonat
# id : Integer
- nume : String [1..2]
- prenume : String [1..3]
- adresa : String
~ nrMaximAdmis : Integer
+ nrCrimprumutate ( ) : Integer
+ mprumut (c : CopieCarte)
+ returneaz (c : CopieCarte)
+ acceptmprumut ( ) : Boolean
Vizibilitatea atributelor
Dpdv al vizibilitii, atributele pot fi:
publice +: pot fi accesate de
orice alt clas
private -: nu pot fi accesate
de alte clase
protejate #: pot fi accesate
doar de subclasele care
descind din clasa respectiv
package ~: pot fi accesate
doar de clasele din acelai
package
Abonat
# id : Integer
- adresa : String
~ nrMaximAdmis : Integer = 3
Multiplicitatea atributelor
n
Atributele pot avea diverse

multipliciti (default e 1).
De exemplu: 5, *, 1..3, 3..*, etc.
Atributele pot avea o valoare
iniial. Vezi nrMaximAdmis din
clasa alturat.
Operaii
Abonat
# id : Integer
- adresa : String
Operaii
n
Operaiile clasei definesc

modurile n care interacioneaz
obiectele.
Cnd un obiect trimite un mesaj
ctre un alt obiect, i cere
acestuia din urm s execute o
operaie.
Obiectul care primete mesajul
va apela o metod pentru a
executa aceast operaie.
Semntura unei operaii este

format din:
numele operaiei,
numele i tipurile parametrilor
(dac e cazul) i
tipul care trebuie returnat
(dac este cazul).
La fel ca i atributele, operaiile

pot fi publice, private, protejate,
sau corespunztoare unui
pachet.
Operaii specifice: constructori,

accesori (getX) i mutatori (setX).
Relaii ntre clase

Abonat
# id : Integer
- adresa : String
Clasele formeaz relaii
Tipuri de relaii ntre clase:

asociere
generalizare
dependen
realizare
Abonat
# id : Integer
- adresa : String
Asocieri
n
Asocierile sunt legturi structurale ntre clase.
ntre dou clase exist o asociere atunci cnd un obiect dintr-o

clas interacioneaz cu un obiect din cealalt clas.
Dup cum clasele erau reprezentate prin substantive, asocierile

sunt reprezentate prin verbe.
Pentru a indica direcia de citire a numelui asocierii (d. ex. de la

Abonat la Carte) se poate folosi un triunghi negru.
Asocieri
n
n general, clasa A este asociat cu clasa B, dac un obiect din

clasa A trebuie s aib cunotin de un obiect din clasa B.
n particular, putem identifica urmtoarele cazuri:
Un obiect din clasa A trimite un mesaj ctre un obiect din
clasa B
Un obiect din clasa A creeaz un obiect din clasa B
Un obiect din clasa A are un atribut ale crui valori sunt
obiecte sau colecii de obiecte din clasa B
Multipliciti
n
Participarea unei clase la o asociere este caracterizat de o

anumit multiplicitate. De exemplu, o carte poate avea una sau
mai multe copii, n timp ce o copie de carte aparine doar unei
singure cri.
n UML, multiplicitile pot fi specificate n modul urmtor:

un numr, de exemplu 1
un interval de numere, de exemplu 2..5
un numr arbitrar, folosind simbolul *.
Roluri
Uneori asocierea este mai uor de neles dac rolurilor

pe care obiectele le au n cadrul asocierii li se atribuie
nume separate.
Navigabilitate
n UML putem plasa o sgeat la unul dintre capetele

liniei ce reprezint asocierea pentru a arta c este
posibil s se trimit mesaje n direcia sgeii.
n exemplul de mai jos, spunem c obiectul Curs va avea

cunotin de obiectul Student, dar nu i invers.
Navigabilitate - exemplu n Java
Observaie: o asociaie poate s refere o singur clas
Navigabilitate
n
Specificarea unei direcii de navigaie nu nseamn neaprat ca nu

este posibil o navigaie n sens invers, ci ca acest lucru este mai
greu de realizat.
Atunci cnd se specific sensul de navigare de la clasa A la clasa

B, exist o modalitate precis i direct de acces de la un obiect
din clasa A la un obiect din clasa B (A stocheaz o referin la B).
n exemplul (Student Curs), asocierea poate fi implementat

printr-un atribut care s reprezinte mulimea de obiecte din clasa
Student care particip la Curs.
Dac nu exist nici o sgeat (navigabilitatea nu este specificat

explicit), atunci se consider ca asocierea este bidirecional.
n general, navigabilitatea este specificat explicit doar cnd este

cu adevrat important pentru aplicaie.
Agregare i compunere
n
Agregarea i compunerea reprezint tipuri de asociere n care un

obiect dintr-o clas face parte dintr-un obiect din alt clas.
Agregarea este modul cel mai general de a indica n UML o relaie

de tip parte-ntreg.
Diferena dintre o simpl asociere i agregare este pur

conceptual: folosirea agregrii indic faptul c o clas reprezint
un lucru "mai mare" (ntregul), care conine mai multe lucruri "mai
mici" (prile).
Compunerea
n
Exist ns un caz special de agregare, compunerea, n care

relaia dintre ntreg i prile sale este mai puternic.
Compunerea implic o apartenen puternic a prii la ntreg

i o coinciden ntre durata de via a prii i a ntregului:
dac ntregul este creat, mutat sau distrus, atunci i prile
componente sunt create, mutate sau distruse.
n cazul compunerii, o parte nu poate s fie coninut n mai

mult de un singur ntreg, astfel nct multiplicitatea asocierii la
extremitatea ntregului trebuie s fie 1 sau 0..1.
Exemplu
Asocieri mutual exclusive

n
Asocierile mutual exclusive: dou sau mai multe asocieri care

nu pot exista n acelai timp. Cu alte cuvinte, exist un sau
exclusiv ntre acestea.
Clase de asociere
n
o asociere poate avea date i responsabiliti proprii;

de exemplu, nota studentului la curs.
astfel de asociere poate fi tratat ea nsi ca o clas.
Generalizare (generalization)
n
Generalizare - exemplu n Java
Generalizare: relaie ntre un lucru

general (numit superclas sau printe,
ex. Abonat) i un lucru specializat
(numit subclas sau copil, ex.
AbonatPremium)
Un obiect al unei clase mai generale poate fi substituit cu

un obiect al unei clase mai specializate n orice context,
dar nu i invers.
Motenirea (inheritance)
Generalizarea n practic
Bird
TweetingBird
AngryBird
ntr-o relaie de generalizare, copilul va moteni structura

i comportamentul printelui: toate atributele, operaiile i
relaiile care exist n superclas vor exista i n subclas.
FlappyBird
Alin tefnescu
de la http://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/index.html
Motenirea
Clase abstracte
Pe de alt parte, copilul poate aduga structur i

comportament nou, adic poate avea atribute, operaii i
relaii noi fa de cele ale superclasei.
n plus, copilul poate chiar schimba comportamentul
printelui. Acest lucru se ntmpl atunci cnd o operaie a
subclasei care are aceeai semntur ca i o operaie a
superclasei suprascrie acea operaie. Acest lucru poart
numele de polimorfism.
Motenire multipl
n
O clas abstract este o clas

pentru care nu pot exista instane
directe.
O clas abstract nu furnizeaz

implementarea pentru cel puin una
dintre operaiile sale.
O clas concret este una care poate

avea instane directe.
n UML numele unei clase abstracte

se scrie n italic.
Clasele abstracte pot fi folosite ca superclase ntr-o ierarhie de clase ntre

care exist o asociere de tip generalizare. O astfel de ierarhie va avea ca
nod rdcin o clas abstract, iar ca noduri frunze clase concrete.
Dependene
Atunci cnd o clas care are

un singur printe se spune c
folosete motenire simpl;
n caz contrar, motenirea se
numete multipl.
o clas A depinde de o clas B dac o modificare n

specificaia lui B poate produce modificarea lui A, dar nu
neaprat i invers
cel mai frecvent caz de dependen este relaia dintre o

clas care folosete alt clas ca parametru ntr-o operaie
n majoritatea cazurilor,
motenirea simpl este
suficient, dar exist ns i
cazuri cnd motenirea multipl
este mai eficient.
notaia este o sgeat cu linie punctat dinspre clasa care

este dependent spre cealalt clas
de la http://www.uml-diagrams.org/generalization.html
Motenirea multipl poate fi problematic dac un copil are

mai muli prini al cror comportament se suprapune.
(n Java motenirea multipl nu este permis.)
Interfee
n
n UML, o interfa specific o colecie de operaii i/sau

atribute, pe care trebuie s le furnizeze o clas sau o
component.
O interfa este evideniat prin stereotipul interface

deasupra numelui.
Interfee i realizri
n
D.ex. interfaa specific operaiile unei clase care sunt vizibile n

afara acesteia. Ea nu trebuie s specifice toate operaiile pe care le
poate efectua acea clas, astfel nct aceeai clas poate
corespunde mai multor interfee, iar o interfa poate corespunde
mai multor elemente.
Realizarea unei interfee - exemplu n Java
Interfa sau generalizare?

Interfeele i generalizrile sunt asemntoare (realizarea unei
interfee poate fi privit ca un fel de motenire). ns exist diferene:
n
Faptul c o clas realizeaz (sau corespunde) unei interfae este

reprezentat grafic printr-o linie ntrerupt cu o sgeat triunghiular
(alternativ, exist i o notaie cu cerc, dar nu o discutm aici).
Conceptual: Interfaa nu presupune o relaie strns ntre clase

precum generalizarea.
atunci cnd se intenioneaz crearea unor clase nrudite, care au
comportament comun, atunci trebuie folosit generalizarea.
dac se vrea doar o mulime de obiecte care sunt capabile s
efectueze nite operaii comune (d.ex. afiare), atunci interfaa
este de preferat.
Implementare: Anumite limbaje (Java) ofer doar motenire simpl,

astfel nct interfaa este n acest caz singura soluie pentru
implementarea motenirii multiple. O clas poate moteni de la o
singur superclas, dar poate implementa mai multe interfee.
Pachete
Un mod de a organiza clasele ntr-o diagrama este folosirea pachetelor.
n
Grafic, un pachet este un dreptunghi cu numele n colul din stnga-sus,

iar clasele care-i aparin sunt reprezentate n dreptunghi. Alternativ, se
pot lega clasele de pachet cu notaia .
Pachete - implementare n Java
Stereotipuri
n
O anumit caracteristic a unei clase (i nu numai) poate fi

evideniat folosind stereotipuri. Acestea sunt etichete
plasate deasupra numelui.
Exemple de stereotipuri standard: dataType i

enumeration, dar utilizatorul i poate defini stereotipurile
proprii.
nc un exemplu
de la http://msdn.microsoft.com/en-us/library/dd409437.aspx
Observaie: notaia poate fi folosit i ntre clase, nu numai

ntre clase i pachete.
Cod generat
public class Menu {

Collection<Order> orders;
Collection<MenuItem> menuItems;
}
public class MenuItem {

Menu menu;
}
public class OrderItem {

Order order;
MenuItem menuItem;
private int quantity;
}
public class Order {

Menu chosenMenu;
Collection<OrderItem> orderItems;
private Money totalPrice;
public void addItem(MenuItem item) {}
public void deleteItem(MenuItem item) {}
}
Diagrame de stri
public class PhoneOrder extends Order {

private string callbackNumber;
public void callback() { }
}
Diagrame de stri n viaa real

Diagrame UML de stri
16.03.2015
Alin tefnescu
Maini de stri (State machines)

n
Obiectele din aceeai clas pot reaciona diferit la primirea

unui mesaj, acest lucru depinznd de starea lor, adic de
valorile atributelor obiectelor.
Diagramele de stare (numite i maini de stare sau

statecharts) descriu dependena dintre starea unui obiect i
mesajele pe care le primete sau alte evenimente
recepionate.
Elemente
stri, reprezentate prin dreptunghiuri cu coluri rotunjite
tranziii ntre stri, reprezentate prin sgei
evenimente care declaneaz tranziiile dintre stri
cel mai des ntlnite evenimente sunt mesajele primite de

ctre obiect.
nceputul i sfritul
n
semnul de nceput, reprezentat printr-un un disc negru din

care pornete o sgeat (fr etichet) spre starea iniial
a sistemului.
pot exista de asemenea i semne de sfrit, reprezentate

printr-un disc negru cu un cerc exterior, n care sosesc
sgei din strile finale ale sistemului. Acestea corespund
situaiilor n care obiectul ajunge la sfritul vieii sale i
este distrus.
Stri
O stare este o mulime de configuraii ale obiectului care se

comport la fel la apariia unui eveniment.
O stare poate fi identificat prin constrngeri aplicate

atributelor obiectului.
Exemplu: diagrama de stare pentru televizor

Atribute (ale unei clase Televizor)
esteAlimentat : Boolean
numarProgram : Integer
Constrngeri care definesc strile:
Nealimentat: {not esteAlimentat}
Inactiv:
{esteAlimentat and numarProgram = 0}
Activ:
{esteAlimentat and numarProgram > 0}
Evenimente i aciuni
n
un eveniment este ceva care se produce asupra unui

obiect, precum primirea unui mesaj.
o aciune reprezint ceva care poate fi fcut de ctre

obiect, precum transmiterea unui mesaj.
reprezentare pe tranziii: eveniment/aciune
Activitile strilor
evenimentele i aciunile pot fi asociate i strilor, n acest

caz ele fiind folosite pentru a specifica activitile desfurate
n timpul n care obiectul se afl n starea respectiv.
Stare
selecteazaProgram(p)/antena.recepioneazProgram(p)
Grzi
n
pe lng evenimentele care declaneaz o tranziie

(schimbarea strilor), exist i grzi, care pot condiiona
execuia tranziiilor.
Activitile strilor
Cel mai frecvent utilizate evenimente asociate strilor sunt:

entry : activiti produse cnd obiectul intr n starea respectiv;
Astfel, n anumite situaii un eveniment declaneaz o

tranziie numai dac atributele obiectului ndeplinesc o
anumit condiie suplimentar (gard).
reprezentare pe tranziii: eveniment [gard] / aciune
exit : activiti produse cnd obiectul iese din starea respectiv;

do : activiti produse n timp ce obiectul se afl n starea respectiv.
Stri compuse
Stri compuse: stri istoric
O stare S poate conine substri care detaliaz

comportamentul sistemului n starea S. n acest caz, spunem
ca S este o stare compus.
n general, cnd o tranziie intr ntr-o stare compus,

submaina corespunztoare acesteia va ncepe s
funcioneze din starea sa iniial.
Exemplu: situaia cutrii unui canal de televiziune se face

n timp ce televizorul este activ i poate fi reprezentat ca o
diagram de stare inclus CutareCanal.
Uneori este necesar ca submaina s-i reaminteasc

starea n care a rmas i s-i reia funcionarea din acea
stare.
Astfel, starea Activ va deveni compus, incluznd

subcomportamentul de cutare. Pentru aceasta se folosete
notaia include/CutareCanal.
Pentru acest lucru se folosete o stare istoric, reprezentat

printr-un cerc n care apare litera H.
Stri compuse: substri
CutareCanal:
Stri istoric - exemplu
PROIECTELE LA LABORATOR (la gr. 232, 233, 234)
Stri compuse: stri concurente

n
Exist posibilitatea exprimrii activitilor concurente dintr-o stare.
Grafic: se mparte dreptunghiul corespunztor strii compuse printr-o

linie punctat, n regiunile obinute fiind reprezentate submainile care
vor aciona concurent.
Exemplu: adugm la cazul televizorului considerat i situaia cnd

acesta conine un ceas, care funcioneaz n acelai timp cu televizorul.
nc un exemplu
Echipe de 3-5 studeni care implementeaz un proiect la

alegere n limbajul de programare favorit.
Dou componente principale (cu pondere egal la not):
- implementarea
- document care trebuie s conin:
descriere n limbaj natural a proiectului
list de cerine n limbaj natural (structurat)
cteva specificaii formale (Z sau JML)
modelare UML, coninnd urmtoarele diagrame:
+ diagrame cazuri de utilizare
+ diagrame de clase
+ diagrame de secvene
+ diagrame de stri
teste (unit testing i altele - v. cursurile urmtoare)
Exemplu de modelare UML a unui proiect

de la Florin Ostafi - Ingineria sistemelor de programe
http://rtb-team.sourceforge.net/rtb-team_analysis.htm
n
alege[nr_stud<3]/nr_stud++
La linkul de mai sus este un exemplu de proiect software

care este documentat prin diverse tipuri de diagrame UML
Testare n practic

Testare - partea 1
23.03.2015
Alin tefnescu
de la dilbert.com
Generaliti - validare i verificare (V&V)

Verificare
construim corect produsul?
Testare software
se refer la dezvoltarea produsului

Validare
construim produsul corect?
se refer la respectarea specificaiilor, la utilitatea produsului
Prezentare bazat pe materiale de Florentin Ipate (UniBuc) i Florin Leon (UT Iai)
Verificarea i validarea trebuie s stabileasc ncrederea c

produsul este potrivit pentru scopul su
Aceasta nu nseamn c produsul este lipsit de defecte
Doar c produsul trebuie s fie suficient de bun pentru utilizare
Evaluarea unui produs software
Terminologie (IEEE)
Depinde de scopul produsului, de ateptrile utilizatorilor i

factorii de pia:
Eroare (engl. error)

o aciune uman care are ca rezultat un defect n produsul
software
Defect (engl. fault)

consecina unei erori n produsul software
un defect poate fi latent: nu cauzeaz probleme ct timp nu
apar condiiile care determin execuia anumitor linii de cod
Defeciune (engl. failure)

manifestarea unui defect: cnd execuia programului ntlnete
un defect, acesta provoac o defeciune
abaterea programului de la comportamentul ateptat
Funcionalitatea programului
nivelul de ncredere depinde de ct de critic este sistemul
pentru utilizatori
Ateptrile utilizatorilor
utilizatorii pot avea grade diferite de ateptri pentru
diferite tipuri de produse software
Mediul de afaceri
lansarea rapid pe pia a unui produs poate fi uneori mai
important dect gsirea tuturor defectelor n program
Testarea unui program
evideniaz prezena erorilor i nu absena lor
este singura tehnic de validare pentru cerine nonfuncionale, deoarece programul trebuie executat pentru a i
se analiza comportamentul
este utilizat de obicei alturi de verificarea static pentru o

siguran ct mai mare
Bug
Bug: termen colocvial utilizat deseori ca sinonim pentru defect
de la dilbert.com
Testarea i depanarea
n
testarea de validare
intenioneaz s arate c produsul nu ndeplinete cerinele
testele ncearc s arate c o cerin nu a fost implementat
adecvat
testarea defectelor
teste proiectate s descopere prezena defectelor n sistem
testele ncearc s descopere defecte
depanarea (debugging)
are ca scop localizarea i repararea erorilor corespunztoare
implic formularea unor ipoteze asupra comportamentului
programului, corectarea defectelor i apoi re-testarea
programului
Asigurarea calitii
Cteva principii de testare

n
o parte necesar a unui caz de test este definirea ieirii sau

rezultatului ateptat
programatorii nu ar trebui s-i testeze propriile programe

(excepie face testarea de nivel foarte jos - testarea unitar)
organizaiile ar trebui s foloseasc i companii (sau

departamente) externe pentru testarea propriilor programe
rezultatele testelor trebuie analizate amnunit
trebuie scrise cazuri de test att pentru condiii de intrare

invalide i neateptate, ct i pentru condiii de intrare valide i
ateptate
Cteva principii de testare (continuare)

n
programul trebuie examinat pentru a vedea dac nu face ce

trebuie; de asemenea, trebuie examinat pentru a vedea dac nu
cumva face ceva ce nu trebuie
se ocup de procesele de dezvoltare care s conduc la

producerea unui software de calitate
pe ct posibil, cazurile de test trebuie salvate i re-executate

dup efectuarea unor modificari
include procesul de testare a produsului
probabilitatea ca mai multe erori s existe ntr-o seciune a

programului este proporional cu numrul de erori deja
descoperite n acea seciune
efortul de testare nu trebuie subapreciat
creativitatea necesar procesului de testare nu trebuie

subapreciat
testarea se refer la detectarea defectelor
asigurarea calitii se refer la prevenirea lor
Modelul V
Cerine utilizator
Cerine sistem
Module
Testare de acceptan
validare
verificare
Arhitectura sistem
Testarea de integrare (integration testing)
Testare de sistem
Testarea este determinat de arhitectur
Testare unitar
+ multe alte
tipuri de testare
Testarea unitar (unit testing)
Testeaz interaciunea mai multor uniti
Testare de integrare
IMPLEMENTARE
o unitate (sau un modul) se refer de obicei la un element

atomic (clas sau funcie), dar poate nsemna i un element de
nivel mai nalt: bibliotec, driver etc.
Testarea sistemului (system testing)

n
testarea sistemului testeaz aplicaia ca ntreg i este

determinat de scenariile de analiz
aplicaia trebuie s execute cu succes toate scenariile pentru a

putea fi pus la dispoziia clientului
spre deosebire de testarea intern i a componentelor, care se

face prin program, testarea aplicaiei se face de obicei cu scripturi care ruleaz sistemul cu o serie de parametri i colecteaz
rezultatele
testarea aplicaiei trebuie s fie realizat de o echip

independent de echipa de implementare
testele se bazeaz pe specificaiile sistemului
testarea unei uniti se face n izolare

pentru simularea apelurilor externe se pot utiliza funcii
externe fictive (engl. stubs)
Testarea de acceptan (acceptance testing)

n
testele de acceptan determin dac sunt ndeplinite cerinele

unei specificaii sau ale contractului cu clientul.
sunt de diferite tipuri:
Testarea performanei (performance testing)

n
sigurana (reliability) - meninerea unui nivel specificat de

performan
teste rulate de dezvoltator nainte de a livra produsul software
securitatea - persoanele neautorizate s nu aib acces, iar

celor autorizate s nu le fie refuzat accesul
teste rulate de utilizator (user acceptance testing)

teste de operaionalitate (operational testing)
utilizabilitatea - capacitatea de a fi neles, nvat i utilizat
testare alfa i beta: alfa la dezvoltator, beta la client cu un

grup ales de utilizatori
Testele de regresie (regression testing)

n
O parte din testare se concentreaz pe evaluarea proprietilor

non-funcionale ale sistemului, cum ar fi:
etc. (v. urmtoarele dou slide-uri)
Testarea la ncrcare (load testing)
un test valid genereaz un set de rezultate verificate, numit

standardul de aur
testele de regresie sunt utilizate la re-testare, dup realizarea

unor modificri, pentru a asigura faptul c modificrile nu au
introdus noi defecte n codul care funciona bine anterior
asigur faptul c sistemul poate gestiona un volum ateptat de

date, similar cu acela din locaia destinaie (de exemplu la client)
verific eficiena sistemului i modul n care scaleaz acesta

pentru un mediu real de execuie
pe msur ce dezvoltarea continu, sunt adugate alte teste

noi, iar testele vechi pot rmne valide sau nu
dac un test vechi nu mai este valid, rezultatele sale sunt

modificate n standardul de aur
acest mecanism previne regresia sistemului ntr-o stare de

eroare anterioar
Testarea la stres (stress testing)

n
solicit sistemul dincolo de ncrcarea maxim proiectat
suprancrcarea testeaz modul n care cade sistemul

sistemele nu trebuie s eueze catastrofal
testarea la stres verific pierderile inacceptabile de date sau
funcionaliti
testeaz ct de uor de folosit este sistemul
se poate face n laboratoare sau pe teren cu utilizatori din

lumea real
exemple de metode folosite:
deseori apar aici conflicte ntre teste. Fiecare test funcioneaz

corect atunci cnd este fcut separat. Cnd dou teste sunt rulate n
paralel, unul sau ambele teste pot eua
cauza este de obicei managementul incorect al accesului la
resurse critice (de exemplu, memoria)
testare pe hol (hallway testing): cu civa utilizatori aleatori
o alt variant, soak testing, presupune rularea sistemului pentru o

perioad lung de timp (zile, sptmni, luni)
n acest caz, de exemplu scurgerile nesemnificative de memorie
se pot acumula i pot provoca cderea sistemului
A/B testing: n special pentru web design, modificarea unui

singur element din UI (d.ex. culoarea sau poziia unui buton)
i verificarea comportamentului unui grup de utilizatori
Testarea interfeei cu utilizatorul (GUI testing)

n
Testarea utilizabilitii (usability testing)
majoritatea aplicaiilor din zilele noastre au interfee grafice cu

utilizatorul (GUI)
testarea interfeei grafice poate pune anumite probleme
cele mai multe interfee, dac nu chiar toate, au bucle de
evenimente, care conin cozi de mesaje de la mouse,
tastatur, ferestre, touchscreen etc.
asociate cu fiecare eveniment sunt coordonatele ecran
testarea interfeei cu utilizatorul presupune memorarea
tuturor acestor informaii i elaborarea unei modaliti prin
care mesajele s fie trimise din nou aplicaiei, la un moment
ulterior
de obicei se folosesc scripturi pentru testare
testare de la distan: analizarea logurilor utilizatorilor (dac

i dau acordul pentru aceasta)
recenzii ale unor experi (externi)
Inspeciile codului (code reviews)

n
o alt metod de asigurarea calitii este citirea codului cu

scopul de a detecta erori
n varianta extins, echipa de inspecie/recenzie a codului are

patru membri:
Moderatorul un programator competent
Programatorul cel care a scris codul inspectat
Designer-ul, dac este o persoan diferit de programator
Un specialist n testare
Inspeciile codului (2)

n
activiti:

n
programatorul nu trebuie s fie defensiv, ci constructiv
programatorul citete, instruciune cu instruciune, logica

programului
nu trebuie s vad inspecia ca pe un atac personal, ci ca pe

o modalitate de a crete calitatea muncii sale
ceilali participani pun ntrebri
rezultatele inspeciei sunt confideniale
programatorul nsui poate descoperi cele mai multe erori
programatorul primete reacii privind stilul de programare,

tehnicile i algoritmii folosii
se caut n program cele mai ntlnite tipuri de erori (folosind de

exemplu o list de erori comune)
ceilali participani beneficiaz de pe urma expunerii la un alt stil

de programare
identificarea timpurie a seciunilor celor mai predispuse la erori

ajut la sporirea ateniei acordate acestora n faza de testare

n
inspectorii detecteaz erorile, programatorul trebuie s le

corecteze
dac sunt descoperite multe erori sau unele erori necesit

corecii substaniale, moderatorul stabilete o nou inspecie
dup corectarea lor
erorile determinate pot conduce la modificarea design-ului
de obicei, durata unei sesiuni de inspecie este de 90-120 de

minute, cu o rat de 150 de instruciuni pe or
dac programul este mai mare, se stabilesc mai multe sesiuni

de inspecie, organizate pe module
testare
de tip
cutie neagr
Testarea de tip cutie neagr

n
testarea exhaustiv nu este fezabil
generarea aleatorie a cazurilor de test nu este eficient
posibil soluie: se iau n considerare numai intrrile (ntr-un

modul, component sau sistem) i ieirile dorite, conform
specificaiilor
structura intern este ignorat (de unde i numele de black
box testing)
deoarece se bazeaz pe funcionalitatea descris n
specificaii, se mai numete i testare funcional
poate fi folosit n principiu la orice nivel de testare (unitar,
integrare, sistem)
Observaii
n
datele de test sunt generate pe baza specificaiei (cerinelor)

programului, structura programului nejucnd nici un rol
tipul de specificaie ideal pentru testarea cutie neagr este

alctuit din pre-condiii i post-condiii
exemple de metode de testare de tip cutie neagr:

partiionare n clase de echivalen
analiza valorilor de frontier
partiionarea n categorii
graful cauz-efect
testarea tuturor perechilor
testarea bazat pe modele
etc.
Partiionare n clase de echivalen

n
ideea de baz este de a partiiona domeniul problemei (datele

de intrare) n partiii de echivalen sau clase de echivalen
astfel nct, din punctul de vedere al specificaiei, datele dintr-o
clas s fie tratate n mod identic
cum toate valorile dintr-o clas au acelai comportament,

presupunem c toate valorile dintr-o clas sunt procesate n
acelai fel, fiind deci suficient s se aleag cte o valoare din
fiecare clas
domeniul de ieire este tratat asemntor
Partiionare n clase de echivalen

n
clasele de echivalen nu trebuie s se suprapun, deci orice

clase care s-ar suprapune trebuie descompuse n clase
separate
dup ce clasele au fost identificate, se alege o valoare din

fiecare clas. n plus, pot fi alese i date invalide (care sunt n
afara claselor i nu sunt procesate de nici o clas)
alegerea valorilor din fiecare clas este arbitrar deoarece se

presupune c toate valorile sunt procesate ntr-un mod identic
Exemplu - cutare simpl ntr-un ir
Clase de echivalen pentru intrri

n
n trebuie s fie ntre 1 si 20, deci se disting 3 clase de echivalen:

N_1 = 1..20
N_2 = { n | n < 1 }
N_3 = { n | n > 20 }
ntregul n determin lungimea irului de caractere i nu se

precizeaz nimic despre tratarea diferit a irurilor de lungime
diferit deci a doua intrare nu determin clase de echivalen
suplimentare
c nu determin deocamdat clase de echivalen suplimentare
opiunea de a cuta un nou caracter este binar, deci se disting

2 clase de echivalen
S_1 = { y }
S_2 = { n }
Se testeaz un program care verific dac un caracter se afl

ntr-un ir de cel mult 20 de caractere.
Mai precis, se introduc n caractere, unde n este un ntreg ntre
1 i 20, iar apoi un caracter c, care este cutat printre cele n
caractere introduse anterior.
Programul va produce o ieire care indic prima poziie din ir
unde a fost gsit caracterul c sau un mesaj indicnd ca acesta
nu a fost gsit.
La final, utilizatorul are opiunea s caute un alt caracter
tastnd y (yes) sau s termine procesul tastnd n (no).
Domeniul de intrri
Ieiri
Exist 4 intrri:
un ntreg pozitiv n
un ir de caractere x
caracterul care se caut c
opiunea de a cuta sau nu un alt caracter s
Const din urmtoarele 2 posibile rspunsuri:

poziia la care caracterul se gsete n ir, sau
un mesaj care arat c nu a fost gsit caracterul.
Acestea sunt folosite pentru a mpri domeniul de intrare n
2 clase: una pentru cazul n care caracterul se afl n irul de
caractere i una pentru cazul n care acesta lipsete:
C_1(x) = { c | c se afl n x }
C_2(x) = { c | c nu se afl n x }
Clase de echivalen pentru program
Intrri i rezultate
Clasele de echivalen pentru ntregul program se obin ca o

combinaie a claselor individuale:
Intrri
Rezultatul care trebuie afiat
C_111 = { (n, x, c, s) | n N_1, |x| = n, c C_1(x), s S_1 }
C_112 = { (n, x, c, s) | n N_1, |x| = n, c C_1(x), s S_2 }
abc
Afieaz poziia 1;
se cere introducerea unui nou caracter
C_121 = { (n, x, c, s) | n N_1, |x| = n, c C_2(x), s S_1 }
abc
Afieaz poziia 1
abc
Caracterul nu apare;
se cere introducerea unui nou caracter
abc
Caracterul nu apare
C_122 = { (n, x, c, s) | n N_1, |x| = n, c C_2(x), s S_2 }

C_2
= { (n, x, c, s) | n N_2 }
C_3
= { (n, x, c, s) | n N_3 }
Date de test
Setul de date de test se alctuiete alegndu-se o valoare a intrarilor
pentru fiecare clas de echivalen. De exemplu:
C_111 : (3, abc, a, y)
C_112 : (3, abc, a, n)
C_121 : (3, abc, d, y)
Cere introducerea unui ntreg ntre 1 si 20
25
Cere introducerea unui ntreg ntre 1 si 20
Avantaje
n
reduce drastic numrul de date de test doar pe baza specificaiei
potrivit pentru aplicaii de tipul procesrii datelor, n care intrarile i

ieirile sunt uor de identificat i iau valori distincte
Dezavantaje
n
modul de definire a claselor nu este evident (nu exist nici o

modalitate riguroas sau mcar nite indicaii clare pentru
identificarea acestora).
n unele cazuri, dei specificaia ar putea sugera c un grup de

valori sunt procesate identic, acest lucru nu este adevarat. (Acest
lucru ntrete ideea ca metodele de tip cutie neagr trebuie
combinate cu cele de tip cutie alb.)
mai puin aplicabile pentru situaii cnd intrrile i ieirile sunt

simple, dar procesarea este complex.
C_122 : (3, abc, d, n)

C_2 : (0, _, _, _)
C_3 : (25, _, _, _)
Analiza valorilor de frontier (boundary value analysis)
analiza valorilor de frontier este o alt metod de tip cutie

neagr
este folosit de obicei mpreun cu partiionarea n clase de

echivalen
ea se concentreaz pe examinarea valorilor de frontier ale

claselor, care de regul sunt o surs important de erori
aceast metod adaug informaii suplimentare pentru

generarea setului de date de test
Valori de frontier
Pentru exemplul nostru, odat ce au fost identificate clasele,
valorile de frontier sunt uor de identificat:
valorile 0, 1, 20, 21 pentru n
caracterul c poate s se gseasc n irul x pe prima sau
pe ultima poziie.
Deci se vor testa urmtoarele valori:
N_1 : 1, 20
N_2 : 0
N_3 : 21
C_1 : c_11 se afl pe prima poziie n x, c_12 se afl pe
ultima poziie n x
pentru restul claselor se ia cte o valoare (arbitrar)
Date de test
Astfel, pentru C_111 si C_112 vom alege cte 3 date de test (x
de 1 caracter i x de 20 de caractere n care c se gsete pe
poziia 1 i pe poziia 20), iar pentru C_121 i C_122 cte 2
date de test (x de 1 caracter i x de 20 de caractere). n total
vom avea 12 date de test:
C_111 : (1, a, a, y), (20, abcdefghijklmnoprstu, a, y),
(20, abcdefghijklmnoprstu, u, y)
C_112 : (1, a, a, n), (20, abcdefghijklmnoprstu, a, n),
(20, abcdefghijklmnoprstu, u, n)
C_121: (1, a, b, y), (20, abcdefghijklmnoprstu, z, y)
C_122: (1, a, b, n), (20, abcdefghijklmnoprstu, z, n)
C_2 : (0, _, _, _)
C_3 : (21, _, _, _)
Intrri (tabelar)
Intrri
n
1
x
a
20
abcdefghijklmnoprstu
20
20
0
21
c
a
a
b
b
a
a
u
u
z
z
s
y
n
y
n
y
n
y
n
y
n
Partiionarea n categorii (category-partition)

n
aceast metod pentru testare de tip cutie neagr se bazeaz

pe cele dou anterioare.
ea ncearc s genereze date de test care "acoper"
funcionalitatea sistemului i astfel, s creasc posibilitatea de
gsire a erorilor.
cuprinde urmtorii 7 pai:
1. descompune specificaia funcional n uniti (programe,
funcii, etc.) care pot fi testate separat
2. pentru fiecare unitate, identific parametrii i condiiile de
mediu (ex. starea sistemului la momentul execuiei) de
care depinde comportamentul acesteia
Partiionarea n categorii - continuare
Exemplu - paii 1-3

n
Pentru exemplul nostru:

1. descompune specificaia n uniti: avem o singur unitate
2. identific parametrii: n, x, c, s
3. gsete categorii:
n : dac este n intervalul valid 1..20
x : dac este de lungime minim, maxim sau
intermediar
c : dac ocup prima sau ultima poziie sau o poziie n
interiorul lui x sau nu apare n x
s : dac este pozitiv (y) sau negativ (n)
Exemplu - pasul 4
continuare:
3. gsete categoriile (proprieti sau caracteristici
importante) fiecrui parametru sau condiiile de mediu.
4. partiioneaz fiecare categorie n alternative. O alternativ
reprezint o mulime de valori similare pentru o categorie.
5. scrie specificaia de testare. Aceasta const din lista
categoriilor i lista alternativelor pentru fiecare categorie.
6. creeaz cazuri de testare prin alegerea unei combinaii de
alternative din specificaia de testare (fiecare categorie
contribuie cu zero sau o alternativ).
7. creeaza date de test alegnd o singur valoare pentru
fiecare alternativ.
4. Partiioneaz fiecare categorie n alternative:

n : <0, 0, 1, 2..19, 20, 21, >21
x : lungime minim, maxim sau intermediar
c : poziia este prima, n interior sau ultima; sau c nu apare n x
s : y, n
Exemplu - pasul 5
Exemplu - pasul 6 - observaie
5. Scrie specificaia de testare
Din specificaia de testare anterior ar trebui s rezulte

7 x 3 x 4 x 2 = 168 de cazuri de testare.
n
1. { n | n < 0 }
2. 0
3. 1
4. 2..19
5. 20
6. 21
7. { n | n > 21 }
[ok, lungime1]
[ok, lungime_medie]
[ok, lungime20]
1. { x | |x| = 1 }
2. { x | 1 < |x| < 20 }
3. { x | |x| = 20 }
[if ok and lungime1]

[if ok and lungime_medie]
[if ok and lungime20]
Exemplu - pasul 5 - continuat

5. Scrie specificaia de testare - continuare
c
1. { c | c se afl pe prima poziie n x } [if ok]
2. { c | c se afl n interiorul lui x }
[if ok and not lungime1]
3. { c | c se afl pe ultima poziie n x } [if ok and not lungime1]

4. { c | c nu se afl n x }
s
1. y
[if ok]
2. n
[if ok]
[if ok]
Pe de alt parte, unele combinaii de alternative nu au sens

i pot fi eliminate. Acest lucru se poate face adugnd
constrngeri acestor alternative.
Constrngerile pot fi: fie proprieti ale alternativelor, fie
condiii de selecie bazate pe aceste proprieti. n acest caz,
alternativele vor fi combinate doar daca conditiile de selectie
sunt satisfacute.
n exemplul nostru (folosind constrngerile date anterior n
paranteze []), putem reduce numrul cazurilor de testare la
24.
Exemplu - pasul 6
6. Creeaz cazuri de testare (24 de teste)
n1
n2
n3x1c1s1
n3x1c1s2
n3x1c4s1
n3x1c4s2
n4x2c1s1
n4x2c1s2
n4x2c2s1
n4x2c2s2
n4x2c3s1
n4x2c3s2
n4x2c4s1
n4x2c4s2
n5x3c1s1
n5x3c1s2
n5x3c2s1
n5x3c2s2
n5x3c3s1
n5x3c3s2
n5x3c4s1
n5x3c4s2
n6
n7
Exemplu - pasul 7 (creeaz date de test)

Intrri
-5
0
1
1
1
1
5
5
5
5
5
5
5
5
20
20
20
20
20
20
20
20
21
25
a
a
a
a
abcde
abcde
abcde
abcde
abcde
abcde
abcde
abcde
a
a
b
b
a
a
c
c
e
e
f
f
a
a
c
c
u
u
z
z
y
n
y
n
y
n
y
n
y
n
y
n
y
n
y
n
y
n
y
n
n
paii de nceput (identificarea parametrilor i a condiiilor de mediu

precum i a categoriilor) nu sunt bine definii, bazndu-se pe
experiena celui care face testarea. Pe de alta parte, odat ce
aceti pai au fost realizai, aplicarea metodei este clar.
este mai clar definit dect metodele cutie neagr anterioare i

poate produce date de testare mai cuprinztoare, care testeaz
funcionaliti suplimentare; pe de alt parte, datorit exploziei
combinatorice, pot rezulta date de test de foarte mari dimensiuni.

Testare - partea 2
30.03.2015
Alin tefnescu
Testare n practic
Structura programului ca graf
testare
de tip
cutie alb
datele de test sunt generate pe baza implementrii

(programului), fr a lua n considerare specificaia
(cerinele) programului
pentru a utiliza structura programului, acesta poate fi

reprezentat sub forma unui graf orientat
datele de test sunt alese astfel nct s parcurg toate

elementele grafului (instruciune, ramur sau cale) mcar o
singur dat.
n funcie de tipul ales de elemente, sunt definite diferite

msuri de acoperire a grafului: acoperire la nivel de
instruciune, acoperire la nivel de ramur sau acoperire la
nivel de cale
Prezentare bazat pe materiale de Florentin Ipate (UniBuc)
Testarea de tip cutie alb (white-box testing)

n
am vzut n cursul anterior c testarea cutie neagr trateaz

funcionalitatea unui modul lund n calcul doar intrrile i ieirile
i relaiile dintre ele definite n cerine
testarea de tip cutie alb ia n calcul codul surs al

metodelor testate
testarea cutie alb vizeaz acoperirea diferitelor structuri ale

programului
de aceea se mai numete i testare structural
n practic se folosete de multe ori o combinaie ntre testarea

de tip cutie alb i cutie neagr, numit cutie gri
Transformarea programului ntr-un graf orientat

n
pentru o secven de instruciuni se introduce un nod
dou noduri n1 i n2 sunt conectate dac este posibil s se

execute n2 imediat dup n1
Exemplu: program + graf asociat

public class Test {
public static void main(String[] arg) {
KeyboardInput in = new KeyboardInput();
char s, c, nl;
boolean found;
int n,i;
char[] x = new char[20];
1
2
3
4
do {
System.out.println("Input an integer
between 1 and 20: ");
n = in.readInteger();
} while ( n<1 || n>20 );
System.out.println("input "+n+" character(s):);
6
7
8
for (i=0; i<n; i++)

x[i] = in.readCharacter();
nl = in.readCharacter();
Acoperiri
Pe baza grafului se pot defini diverse acoperiri:
n
acoperire la nivel de instruciune: fiecare instruciune (sau

nod al grafului) este parcurs mcar o dat
acoperire la nivel de ramur: fiecare ramur a grafului este

parcurs mcar o dat
acoperire la nivel de cale: fiecare cale din graf este

parcurs mcar o dat
i alte variante
... continuare
Exemplul continuat
Acoperire la nivel de instruciune (statement coverage)
... continuare
Pentru a obine o acoperire la nivel de instruciune, trebuie s

ne concentrm asupra acelor instruciuni care sunt controlate
de condiii (acestea corespund ramificaiilor din graf)
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
do {
System.out.println("Input character to search for: ");
c = in.readCharacter();
nl = in.readCharacter();
found=false;
for (i=0; !found && i<n; i++)
if (x[i]==c)
found=true;
if (found)
System.out.println("character +c+
" appears at position "+i);
else
System.out.println("character +c+"
does not appear in string");
System.out.println("Search for
another character? [y/n]: ");
s = in.readCharacter();
nl=in.readCharacter();
} while ((s=='y') || (s==Y'));
}
Intrri
n
Instruciuni parcurse
1..3, 4, 5, 6
7, 6, 8, 9..13
a
a
14, 15, 16, 14, 17, 18, 21..23
y
b
24, 9..13
14, 15, 14, 17, 19..20, 21..23
24, 25
Acoperire la nivel de instruciune

n
testarea la nivel de instruciune este privit de obicei ca nivelul

minim de acoperire pe care l poate atinge testarea structural.
Acest lucru se datoreaz sentimentului ca este absurd s dai n
funcionare un software fr a executa mcar o dat fiecare
instruciune.
totui, destul de frecvent, acesta acoperire nu poate fi obinut,
din urmtoarele motive:
existena unei poriuni izolate de cod, care nu poate fi
niciodat atins. Aceast situaie indic o eroare de design i
respectiva poriune de cod trebuie nlturat.
existena unor poriuni de cod sau subrutine care nu se pot
executa dect n situaii speciale (subrutine de eroare, a cror
execuie poate fi dificil sau chiar periculoas). n astfel de
situaii, acoperirea acestor instruciuni poate fi nlocuit de o
inspecie riguroas a codului.
Avantaje
n
realizeaz execuia mcar o singur dat a fiecrei instruciuni
n general, uor de realizat
Dezavantaje
n
nu testeaz fiecare condiie n parte n cazul condiiilor compuse

(de exemplu, pentru a se atinge o acoperire la nivel de instruciune
n programul anterior, nu este necesar introducerea unei valori
mai mici ca 1 pentru n)
nu testeaz fiecare ramur
probleme suplimentare apar n cazul instruciunilor if a cror clauz

else lipsete. n acest caz, testarea la nivel de instruciune va fora
execuiei ramurii corespunztoare valorii adevrat, dar, deoarece
nu exist clauza else, nu va fi necesar i execuia celeilalte
ramuri. Metoda poate fi extins pentru a rezolva aceast problem.
Acoperire la nivel de ramur (branch coverage)

n
este o extindere natural a metodei precedente.
genereaz date de test care testeaz cazurile cnd fiecare

decizie este adevrat sau fals.
se mai numete i decision coverage

Intrri
n
25
1
Rezultatul afiat
cere introducerea unui ntreg ntre 1 i 20
afieaz poziia 1; se cere introducerea

unui nou caracter
caracterul nu apare
Dezavantaj: nu testeaz condiiile individuale ale fiecrei decizii
Acoperire la nivel de condiie (condition coverage)

n
genereaz date de test astfel nct fiecare condiie individual

dintr-o decizie s ia att valoarea adevrat ct i valoarea fals
(dac acest lucru este posibil)
de exemplu, dac o decizie ia forma c1 || c2 sau c1 && c2,

atunci acoperirea la nivel de condiie se obine astfel nct
fiecare dintre condiiile individuale c1 i c2 s ia att valoarea
adevrat ct i valoarea fals
Nota: decizie nseamn orice ramificare n graf, chiar atunci cnd

ea nu apare explicit n program. De exemplu, pentru construcia
for i := 1 to n din Pascal condiia implicit este i n
Decizii
Avantaje
n
Decizii
Condiii individuale
while (n<1 || n>20)
n < 1, n > 20
for (i=0; i<n; i++)
i<n
for (i=0; !found && i<n; i++)
found, i < n
if (a[i]==c)
a[i] == c
if (found)
found
while ((s=='y') || (s=='Y'))
(s==y'), (s=='Y')
Acoperire la nivel de condiie
Dezavantaje
n
poate s nu realizeze o acoperire la nivel de ramur. De

exemplu, datele anterioare nu realizeaz ieirea din bucla
while ((s=='y') || (s=='Y')) (condiia global este n ambele
cazuri adevrat). Pentru a rezolva aceasta slbiciune se
poate folosi testarea la nivel de condiie/decizie.
Acoperire la nivel de condiie/decizie (C/D)

n
Intrri
se concentreaz asupra condiiilor individuale
genereaz date de test astfel nct fiecare condiie individual

dintr-o decizie s ia att valoarea adevrat ct i valoarea fals
(dac acest lucru este posibil) i fiecare decizie s ia att
valoarea adevrat ct i valoarea fals.
Rezultatul afiat
Intrri
Rezultatul afiat
25

unui nou caracter
25
caracterul nu apare; se cere introducerea

unui nou caracter
a
b

unui nou caracter
caracterul nu apare; se cere introducerea

unui nou caracter
caracterul nu apare
Acoperirea MC/DC
Acoperirea MC/DC - alt exemplu
Pentru a mbunti acoperirea anterioar se poate ncerca

acoperirea la nivel de condiii multiple (multiple condition
coverage):
n
n
Un alt exemplu: C = C1 C2 C3
Test
C1
C2
C3
se genereaz de date de test astfel nct s se parcurg toate

combinaiile posibile de adevrat i fals ale condiiilor individuale.
t1
true
true
false
true
t2
false
true
false
false
problema: poate genera o explozie combinatoric (pentru N condiii

pot fi necesare 2N teste).
t3
true
true
false
true
t4
true
false
false
false
t5
true
false
true
true
t6
true
false
false
false
Soluie: o form modificat a condition/decision coverage

(prescurtat MC/DC)
n
t1 i t2 acoper C1; t3 i t4 acoper C2; t5 i t6 acoper C3
fiecare condiie individual dintr-o decizie ia att valoarea true ct

i valoarea false
fiecare decizie ia att valoarea true ct i valoarea false
fiecare condiie individual influeneaz n mod independent

decizia din care face parte
deci {t1, t2, t3, t4, t5, t6} acoper C dpdv MC/DC
Exist ns un set minimal {t1,t2,t4,t5} care acoper C dpdv MC/DC
(t1 i t2 acoper C1; t1 i t4 acoper C2; t4 i t5 acoper C3)
Acoperirea MC/DC
Acoperirea MC/DC
fiecare condiie individual influeneaz n mod independent decizia

din care face parte nseamn c: decizia se schimb cnd
schimbm condiia respectiv i pstrm neschimbate restul
celorlalte condiii.
Avantaje:
De exemplu: pentru o expresie AND cu dou condiii C1 i C2
Test
C1
C2
C1C2
t1
true
true
true
t2
true
false
false
t3
false
true
false
t4
false
false
false
t1 i t4 acoper dpdv C/D

dar nu MC/DC
t1 i t3 acoper C1,
t1 i t2 acoper C2,
deci {t1, t2, t3} acoper MC/DC
acoperire mai puternic dect acoperirea condiie/decizie simpl,

testnd i influena condiiilor individuale asupra deciziilor
produce teste mai puine depinde liniar de numrul de condiii
Not: Standardul pentru software pentru aviaie DO-178B cere ca tot

software-ul de nivel A (pentru controlul zborului i al aterizrii) s fie
testat cu acoperirea MC/DC.
Modelul V
Acoperirea la nivel de cale (path coverage)

n
genereaz date pentru executarea fiecrei ci mcar o singur

dat
Problem: n majoritatea situaiilor exist un numr infinit (foarte

mare) de ci
Soluie: mprirea cilor n clase de echivalen.
De exemplu: 2 clase pot fi considerate echivalente daca difer doar

prin numrul de ori de care sunt traversate de acelai circuit
O metod (Paige si Holthouse - 1977): Dac un program este

structurat, atunci acesta poate fi caracterizat de o expresie regulat
format din nodurile grafului.
Cerine utilizator
Cerine sistem
verificare
Arhitectura sistem
Module
avantaje: sunt selectate ci netestate de metodele anterioare
Testare de acceptan
validare
Testare de sistem
Testare de integrare
Testare unitar
dezavantaje: pot fi multe ci, dintre care o parte nefezabile; nu

exerseaz condiiile individuale ale deciziilor
IMPLEMENTARE
+ multe alte
tipuri de testare
Testarea unitar (unit testing)
Testare unitar
cu JUnit
Prezentare bazat pe materiale de

M. Johansson, W. Ahrendt, V. Klebanov (Chalmers University)
reamintire: o unitate (sau un modul) se refer de obicei la un

element atomic. n particular, testarea unei uniti = testarea
unei proceduri, iar n programarea orientat pe obiecte a unei
metode
un test conine
iniializarea (clasei sau a argumentelor necesare)
apelul metodei testate
decizia (oracolul) dac testul a reuit sau a euat
acesta e foarte important pentru evaluarea automat a
testului
compar valorile produse de metod cu cele corecte
o suit de teste este o colecie de teste
JUnit
Un prim exemplu continuat

continuare clasa Ex1:
exemplificm testarea unitar cu JUnit
JUnit este un tool simplu, dar foarte popular, care ofer:

funcionalitatea necesar pentru execuia repetat a scrierii de
teste pentru Java
un mod de a adnota metode ca fiind teste
un mod de a executa i evalua suite de teste
poate fi rulat att n linie de comand sau integrat ntr-un IDE
(d.ex. Eclipse)
// requires: x is non-null and sorted in increasing order

// ensures: result is sorted and contains
//
the elements in x and n, but no others
public static int[] insert(int[] x, int n) {
int[] y = new int[x.length + 1];
int i;
for (i = 0; i < x.length; i++) {
if (n < x[i]) break;
y[i] = x[i];
}
y[i] = n;
for (; i < x.length; i++) {
y[i+1] = x[i];
}
return y;
}
}
Un prim exemplu
Un prim exemplu testat

JUnit poate s testeze valorile returnate ateptate:
public class Ex1 {

// requires: a is non-null, non-empty
// ensures: result is equal to a minimal element in a
public static int find_min(int[] a) {
int x, i;
x = a[0];
for (i = 1; i < a.length; i++) {
if (a[i] < x)
x = a[i];
}
return x;
}
import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;
public class Ex1Test {
@Test public void test_find_min_1() {
int[] a = {5, 1, 7};
int res = Ex1.find_min(a);
assertTrue(res == 1);
}
Execuie n consol
>
>
> javac Ex1Test.java
>
> java org.junit.runner.JUnitCore Ex1Test
JUnit version 4.11
Time: 0.005
OK (2 tests)
>
>
@Test public void test_insert_1() {

int[] x = {2, 7};
int n = 6;
int[] res = Ex1.insert(x, n);
int[] expected = {2, 6, 7};
assertTrue(Arrays.equals(expected, res));
}
...
}
Testarea excepiilor
JUnit poate s testeze diverse alte aspecte, cum ar fi excepiile:
@Test(expected = IndexOutOfBoundsException.class)
public void outOfBounds() {
new ArrayList<Object>().get (1);
}
Se scrie un test pentru Money.add()

n testarea extrem (test-first development), se scrie mai nti testul i apoi
implementarea:
import org.junit.*;
import static org.junit.Assert.*;
public class MoneyTest {
@Test public void simpleAdd() {
Currency ron = new Currency("RON");
Money m1 = new Money(120, ron);
Money result = m1.add(m2);
Money expected = new Money(280, ron);
assertTrue(expected.equals(result));
}
expected declar c outOfBounds trebuie s arunce o excepie de tip

IndexOutOfBoundsException.
Dac metoda outOfBounds arunc o alt excepie sau nu arunc nici una,
testul eueaz.
Al doilea exemplu Extreme Testing

n testarea extrem (test-first development), se scrie mai nti testul i apoi
implementarea:
class Money {
public int amount;
private Currency currency;
public Money(int amount, Currency currency) {
this.amount = amount;
this.currency = currency;
}
public Money add(Money m) {
// NEIMPLEMENTAT NC, DE SCRIS TESTUL PRIMA DAT
}
}
class Currency {
private String name;
public Currency(String name) {
this.name = name;
}
}
Exemplul Money
Acum se implementeaz metoda, dar prima oar ne asigurm ca testul eueaz
(pentru a fi siguri ca nu cumva testul s aib succces n orice condiii)
class Money {
public int amount;
...
return null;
}
}
Se scrie un test pentru Money.add()
Exemplul Money
Dup ce testul eueaz, implementm metoda ca mai jos:
Extindem clasa Money cu rata de schimb Euro, dar prima oar n test
class Money {
public int amount;

Currency ron = new Currency("RON",4.4);
}
...
return new Money (amount + m.amount, currency);
}
@Test public void addDifferentCurrency() {

Currency ron = new Currency("RON",4.4);
Currency usd = new Currency("USD",1.2);
Money m2 = new Money(150, usd);
}
}
Verificm din nou, dar testul eueaz din nou.
Problema: equals pentru obiecte

}
Modificm n implementare acum:
Exemplul Money completat

class Money {
public int amount;
Exemplul Money final

class Money {
public int amount;
private String name;

private double euroRate;
public Currency(String name,
double euroRate) {
this.name = name;
this.euroRate = euroRate;
}

}

}
public String name() {

return name;
}

return new Money(amount +
(int)(m.inEuro()*currency.rate()),currency);
}

return new Money (amount + m.amount, currency);
}
public double inEuro() {

return ((double) amount)/currency.rate();
}
public boolean equals(Object o) {

if (o instanceof Money) {
Money other = (Money)o;
return (currency == other.currency
&& amount == other.amount);
}
return false;
}
public boolean equals(Object o) {

if (o instanceof Money) {
Money other = (Money)o;
return currency == other.currency
&& amount == other.amount;}
return false;
}
nc o problem: ce se ntmpl cnd valuta e diferit?
class Currency {
public double rate(){

return euroRate;
}
}
Testele trec cu succes.
Preambulul setUp()
Anumite pri comune pot fi puse n preambulul testelor
(@Before este executat naintea fiecrui test).
private Currency ron;
private Money m1;
Alte tipuri
de testare
@Before public void setUp() {

ron = new Currency("RON",4.4);
m1 = new Money(120, ron);
}
}
@Test public void addDifferentCurr() {
Currency usd = new Currency("USD",1.2);
Money m2 = new Money(150, usd);
}
}
Alte tooluri de testare unitar
Alte tipuri de teste

Exist bineneles multe alte aspecte i tipuri de testare
JUnit este unul din reprezentanii cei mai populari a unei clase
de framework-uri numite xUnit:
http://en.wikipedia.org/wiki/XUnit
acestea folosesc urmtoarele elemente comune (adaptate la

diverse limbaje i sisteme: test runner, test case,
assertions, text fixtures (care includ un setup i
teardown), test suites i test execution, test result
formatter (pentru afiarea rezultatelor)
n
testarea claselor
nregistrarea i urmrirea defectelor
automatizarea testrii
testarea bazat pe modele
generarea de teste
tooluri de acoperire (coverage tools)
testare pentru domenii specifice:

pentru aplicaii web (d.ex. Selenium)
o list exhaustiv de alte tooluri de testare unitar:
pentru aplicaii mobile (v. http://en.wikipedia.org/wiki/

Mobile_application_testing, d.ex. Android Test Kit, Appium)
http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks
pentru jocuri (d.ex. Unity test framework)

n
n practic: testarea e important i consum multe resurse
Aspecte ale testrii aplicaiilor mobile
Exemplu - pasul 6
Exemplu - pasul 6
Exemplu - pasul 6
Exemplu - pasul 6
Evoluia automatizrii testelor
source: Practical Model-based Testing Book, 2007
Testare bazat pe modele (Model-based Testing - MBT)

Testing Process
Requirements
Models
Automation of test design
Test Design
Test Case
Descriptions
Test Implementation
Test Scripts
Model-based
Testing
Test
Data
Automated test execution

Test Execution
System Under Test
Testarea bazat pe modele (MBT)

MBT = metod de generate de test pe baza unor modele
Un model este o descriere abstract a comportamentului unui

sistem.
n MBT modelele sunt:

formalizate
salvate ntr-o anumit form
folosite pentru generarea de teste i oracole

Depanarea programelor
06.04.2015
Modele pot fi de diferite tipuri:

bazate pe stri (FSM, UML statecharts, LTS)
pre- i post-condiii (JML, OCL, B, Z, Spec#)
bazate pe interacii (UML diagrame de secven)
operaionale (algebre de proces, reele Petri), etc.
Alin tefnescu
Un mic exemplu de MBT

Cum poate arta un model cu strri:
Depanarea
programelor
Example by Harry Robinson
i ce tipuri de teste pot fi generate:

Test 1
Test 2
Execute Start
Execute Close
Execute Start
Execute Type A
Execute Delete A
Execute Type A
Execute Delete A
Execute Close
Test 3
Execute Start
Execute Type A
Execute Close
Execute No
Test 4
Execute Start
Execute Type A
Execute Close
Execute Cancel
Execute Delete A
Execute Close
Prezentare bazat pe materiale de

Moa Johansson (Univ. Chalmers) i Peter Thiemann (Univ. Freiburg)
Depanarea n practic
Depanare folosind tiprirea
Depanarea (debugging)
n
am discutat n cursurile anterioare despre testare:

se caut anumite date de intrare care s genereze un
comportament anormal
un alt scop este i acela de a obine acoperiri ct mai bune
ce facem ns n momentul n care observm ntr-adevr o
defeciune (failure) n program?
Depanarea programului (debugging):

cutarea sursei (a defectului) problemei detectate
folosind de obicei un tool numit debugger
vom vedea i cteva moduri sistematice de depanare
(dependene n program etc.)
varianta cea mai simpl (dar i cea mai simplist):

depanarea de tip println (urmrirea diverselor aspecte
tiprind n output diverse valori ale variabilelor).
d.ex. System.out.println(size = " + size);
simplu de aplicat; nu necesit alte tool-uri
dezavantaje: codul se complic, outputul se complic,
performana uneori scade, ai nevoie de recompilri
repetate, excepiile nu pot fi controlate uor etc.
Depanare folosind log-urile

n
pentru depanare se poate folosi i log-ul programului (istoria

execuiei programului), dac e disponibil:
n Java: java.util.logging
fiecare clas are asociat un obiect Logger, care are
asociat un nivel (finest, fine, , info, warning, severe) i
un handler
log-ul poate fi controlat prin program sau proprieti
rezolv multe din problemele tipului anterior de depanare
dezavantaje: codul se complic
alt soluie: un tool dedicat numit debugger
Un mic exemplu
Ce este un debugger
Funcionalitile de baz ale unui debugger (instrumentul care
ne ajut s identificm problema sau defectul n cod) sunt:
n
controlul execuiei: poate opri execuia la anumite locaii

numite breakpoints
interpretorul: poate executa instruciunile una cte una
inspecia strii programului: poate observa valoarea

variabilelor, obiectelor sau a stivei de execuie
schimbarea strii: poate schimba starea programului n

timpul execuiei
public class BinarySearch {

// presupunem ca vectorul array e ordonat crescator
public static int binarySearch(int array[], int target){
int low = 0;
int high = array.length;
int mid;
while (low <= high) {
mid = (low + high)/2;
if ( target < array[ mid ] )
high = mid - 1;
else if ( target > array[ mid ])
low = mid + 1;
else
return mid;
}
return -1;
}
}
Testare
Debugger-ul Java n Eclipse

n continuare vom vedea cum funcioneaz depanarea pentru
Java n framework-ul Eclipse:
n
Rulm cteva teste pentru funcia de cutare:

n
binarySearch( {1,2,3}, 1) == 0
OK
OK
http://www.vogella.com/tutorials/Eclipse/article.html
OK
http://www.vogella.com/tutorials/JUnit/article.html
binarySearch( {1,2,3}, -1) == -1
OK
http://www.vogella.com/tutorials/EclipseDebugging/article.html
binarySearch( {1,2,3}, 4) arunc ArrayIndexOutOfBoundsException
binarySearch( {}, 0) arunc ArrayIndexOutOfBoundsException
instruciuni de instalare i folosire n Eclipse cu Java + JUnit

+ depanare pot fi consultate aici:
vom demonstra capabilitile de depanare pentru un mic

program
Testele implementate n JUnit

public class BinarySearchTest {
@Test public void test_1() {
int[] a = {1, 2, 3};
int x = 1;
int result = BinarySearch.binarySearch(a,x);
assertTrue(result == 0);
}

int[] a = {1, 2, 3};
int x = -1;
assertTrue(result == -1);
}

int[] a = {1, 2, 3};
int x = 2;
}

int[] a = {1, 2, 3};
int x = 4;
}

int[] a = {1, 2, 3};
int x = 3;
}

int[] a = {};
int x = 0;
}
Breakpoints
Un breakpoint este o locaie n program care, atunci cnd
este atins, oprete execuia.
n
d.ex. n Eclipse, un breakpoint e setat prin: buton-dreapta i

apoi toggle breakpoint
strategie: se pune un breakpoint la ultima linie unde tim c

starea e corect.
dup ce nu mai avem nevoie de un breakpoint, l dezactivm
Execuie pas cu pas

Execuia pas cu pas:
step into execut instruciunea urmtoare, apoi se oprete
step over consider un apel de metod ca o instruciune
n
de obicei metodele din biblioticile Java sunt srite (ele sunt

probabil corecte i de multe ori nu avem codul lor surs)
pentru a sri peste buci mari de cod, se folosesc

breakpointuri (folosindu-se comanda resume)
Inspecia strii programului

Cnd execuia este oprit, se poate examina starea
programului
n
d.ex. n Eclipse, se poate folosi fereastra Variables unde

diverse faciliti sunt oferite (variabilele recent schimbate sunt
evideniate, se pot urmri anumite expresii sau variabile cu
optiunea watch etc.)
pentru exemplul nostru:
putem s oprim execuia nainte de ciclul while
executm pas cu pas
la a treia execuie a ciclului, low==high==3
apoi mid==3, dar array[3] nu exist
observm c dac target e mai mare dect toate elementele
n array, la final avem c low==high==array.length
Urmrirea anumitor stri

Se poate folosi o expresie boolean pentru a condiiona un
breakpoint
n
d.ex. n Eclipse, se selecteaz un breakpoint i se adaug

condiia
programul se va opri la acel breakpoint, doar dac i condiia

respectiv este adevrat
n programul nostru, putem s punem un breakpoint la prima

instruciune dup asignarea lui mid i s adugm condiia
mid == 3
Schimbarea strii programului

Ipoteza valorii corecte: variabila high ar trebui s aib
valoarea array.length-1
n
d.ex. n Eclipse, se poate schimba starea n timp ce

programul este oprit n timpul depanrii.
buton-dreapta pe high apoi Change Value
pentru exemplul nostru dup al doilea ciclu, setm high la

valoarea 2. Continund execuia obinem rezultatul corect.
Depanare
sistematic
Motivaie
n
Urmrirea cauzelor i a efectelor
Depanarea trebuie realizat ntr-un mod sistematic

deoarece:
datele asociate unei probleme pot fi mari
Dificultatea principal este aceea de a gsi sursa problemei

aprute
n exemplul nostru, problema aprea datorit lui mid in

array[mid], dar problema era generat de iniializarea lui high
Problema fundamental este faptul c un program este

executat nainte, pe cnd noi trebuie s raionm napoi
pentru a descoperi defectul
programele pot avea mii de locaii de memorie

programele pot trece prin milioane de stri nainte de a se
manifesta problema
Principalii pai n depanarea sistematic
n exemplul nostru
starea programului
int low = 0;
int high = array.length ;
int mid;
mid = (low + high)/2;
high = mid - 1;
low = mid + 1;
else
return mid;
}
return -1;
defectul e
undeva aici
timpul
ultima stare sntoas

prima stare infectat
cnd apare problema efectiv
strile sntoase trebuie separate de cele infectate

prile relevante trebuie separate de cele irelevante
Efectele instruciunilor
n exemplul nostru
Cum se pot influena instruciunile ntre ele
scriere (write): schimb starea programului; asigneaz o

nou valoare unei variabile citite n alt parte
exemple: asignri; operaiuni in/out; new()
control: schimb contorul programului, determinnd care

instruciune va fi executat la pasul urmtor
condiii, switch-uri
instruciuni repetitive (while, for)
apeluri dinamice de metode (prin reflecie)
terminare abrupt (break, return, continue)
excepii (posibile la orice obiect sau vector)
int low = 0;
int mid;
mid = (low + high)/2 ;
high = mid - 1;
low = mid + 1;
else
return mid;
}
return -1;
}
mid este data-dependent de instruciunea pe fond galben
Dependene
n exemplul nostru
Dependen de date: instruciunea B depinde cu ajutorul datelor

(data-dependent) de instruciunea A dac, prin definiie:
1. A modific o variabil v citit de B i
2. exist cel puin o cale de execuie ntre A i B n care v nu este
modificat
Rezultatul lui A influeneaz direct o variabil citit de B
Dependen de control: instruciunea B depinde prin control

(control-dependent) de instruciunea A dac, prin definiie:
1. execuia lui B poate fi (potenial) controlat de A
Rezultatul lui A poate influena faptul c B este executat sau nu
int low = 0;
int mid;
high = mid - 1;
low = mid + 1;
else
return mid;
}
return -1;
}
mid este control-dependent de instruciunea while
Dependene n sens invers

Dependen napoi: instruciunea B depinde n sens invers
(backward-dependent) de instruciunea A dac, prin definiie:
exist o secven de instruciuni A = A1, A2, , An = B
astfel nct:
1. pentru toi indicii i, Ai+1 este control-dependent sau
data-dependent de Ai i
2. exist cel puin un indice i cu Ai+1 data-dependent de Ai.
Rezultatul lui A poate influena starea programului n B
n exemplul nostru
int low = 0 ;
int mid;
high = mid - 1 ;
low = mid + 1 ;
else
return mid;
}
return -1;
mid este backward-dependent de instruciunile evideniate dup o
execuie repetat a corpului ciclului while
n exemplul nostru
int low = 0 ;
int mid;
high = mid - 1;
low = mid + 1;
else
return mid;
}
return -1;
mid este backward-dependent de instruciunile evideniate la
prima execuie a corpului ciclului while
Urmrirea defectelor
Algoritm de localizarea sistematic a defectelor
n I vom pstra un set de locaii infectate (variabil + contor de program)
n L pstrm locaia curent ntr-o execuie care a euat
1. Fie L locaia infectat raportat de eec i I := {L}
2. Calculm setul de instruciuni S care ar putea conine originea defectului:
un nivel de dependen napoi din L pe calea de execuie
3. Inspectm locaiile L1, , Ln scrise n S i dintre ele alegem ntr-o
mulime M { L1, , Ln } pe cele infectate
4. n cazul n care M (adic cel puin un Li este infectat):
4.1 Fie I : = (I \ {L}) M (nlocuim L cu noii candidai din M)
4.2 Alegem ca noua locaie L o locaie aleatoare din I
4.3 Ne ntoarcem la pasul 2.
5. L depinde doar de locaii neinfectate, deci aici este locul de infectare!
n exemplul nostru
int low = 0 ;
int mid;
high = mid - 1 ;
low = mid + 1 ;
else
return mid;
}
return -1;
Pentru intrarea ( {1,2}, 3), mid este infectat i avem

mid == low == high == 2
n exemplul nostru
int low = 0 ;
int mid;
high = mid - 1 ;
low = mid + 1 ;
else
return mid;
}
return -1;
Cutm originile lui low i high
n exemplul nostru
int low = 0 ;
int mid;
high = mid - 1 ;
low = mid + 1 ;
else
return mid;
}
return -1;
low a fost schimbat n execuia anterioar a ciclului;

dar valuarea sa, low == 1, pare n regula
n exemplul nostru
int low = 0 ;
int mid;
high = mid - 1 ;
low = mid + 1 ;
else
return mid;
}
return -1;
high == 2 e setat la nceput i a rmas neschimbat

(prima ramur if unde se poate schimba high nu a fost
aleas) i valoarea 2 nu e n regul
n exemplul nostru
int low = 0 ;
int mid;
high = mid - 1 ;
low = mid + 1 ;
else
return mid;
}
return -1;
Retestare
Dup ce corectm problema gsit, trebuie s testm
n
execuia care a condus la o defeciune devine un nou test

folosit la testarea de regresie
n timpul / dup rezolvarea problemei, se folosesc testele

unitare existente pentru a:
testa o metod suspect n izolare
asigura c rezolvarea problemei nu a introdus noi defecte
exclude ipoteze greite despre defect
high nu depinde de alte locaii, deci am gsit defectul!
n exemplul nostru
int low = 0 ;
int high = array.length - 1 ;
int mid;
high = mid - 1 ;
low = mid + 1 ;
else
return mid;
}
return -1;
Defectul rezolvat (testele ruleaz i ele corect acum)
Simplificarea problemei intrrilor mari

Cnd depanm putem avea o problem cu intrrile foarte mari.
Presupunem c avem urmtorul raport pentru o defeciune
(raportat de un utilizator, de exemplu):
binarySearch( { -256, -30, -2, -1, 5, 5, 16, 22, 44, 45, 69, 90, 90,
111, 113, 154, 200, 206, 298, 301, 305, 333, 354, 364, 376, 410,
524}, 593) care arunc un ArrayIndexOutOfBoundsException
n
trece prin mai multe iteraii de bucl, nainte de eec
posibil nepotrivit pentru a depanare
ideal ar fi s avem un test care eueaz, de dimensiuni mici
Simplificarea problemei
Exemplu
Dorim deci un test mic care eueaz
Presupunem c dorim s testm metoda urmtoare

public static int checkSum( int array[] )
O soluie divide-et-impera
1. tiem o jumtate din intrarea testului
scopul metodei checkSum este de a calcula suma de control a

vectorului de intrare array
presupunem ca metoda ntoarce un rezultat greit ori de cte

ori vectorul conine dou date identice consecutive (dar noi
nc nu tim aceasta)
avem de asemenea urmtorul test euat (dat de un utilizator):
2. verificm dac una din jumti conduce nc la o problem

3. continum pn cnd obinem un test minim care eueaz
(not: acelai principiu ca la cutarea binar!)
Probleme
n
obositor: testele repetate manual (copy-paste, ruleaz din nou)
ce facem n cazul n care nici una dintre jumti nu conduce la

un eec?
Simplificarea problemei n mod automat
{ 1, 3, 5, 3, 9, 17, 44, 3, 6, 1, 1 , 0, 44, 1, 44, 0 }
Simplificarea intrrilor (n = nr. de buci)
Dorim automatizarea soluiei propuse anterior

n
automatizm partea de copy-paste i rularea repetat de teste
partiionm intrarea testului n n buci (generalizare de la 2)

B(1)
B(n)
repetm, scond pe rnd cte o bucat i re-testnd pe

intrarea rmas
B(1)
B(i-1)
B(i+1)
B(n)
n caz c nu obinem nici un eec, cretem granularitatea

(mrim numrul de buci n care este spart intrarea)
cretem granularitatea
ajustm granularitatea
la dimensiunea intrrii
Stadiul de via al defectelor
Ciclul de via
al defectelor
de cele mai multe ori, persoana care raporteaz un

defect este diferit de cea care l repar
un proiect mare poate include mii de defecte
n astfel de situaii, raportarea i repararea nu pot fi

fcute informal: un defect ar putea fi uitat i/sau
redescoperit ulterior cu un efort suplimentar
ciclul de via poate fi mrit sau micorat n funcie de

natura proiectului
pentru proiecte mici, un defect poate fi doar deschis

sau nchis
pentru proiecte mari, un defect poate trece prin mai

multe faze de urmrire
Stadiul de via al defectelor - exemplu
http://keepcalmandprogram.me/
Stadiul de via al defectelor
Exemplu:
Ciclul de via n Bugzilla
http://www.bugzilla.org/
Srbtori luminoase
alturi de cei dragi!
Clasificarea defectelor
n multe organizaii se folosete o clasificare a defectelor
pe 4 niveluri:
n
defecte critice: afecteaz muli utilizatori, pot ntrzia

proiectul
defecte majore: au un impact major, necesit un

volum mare de lucru pentru a le repara, dar nu
afecteaz substanial graficul de lucru al proiectului
defecte minore: izolate, care se manifest rar i au un

impact minor asupra proiectului
defecte cosmetice: mici greeli care nu afecteaz

funcionarea corect a produsului software urmrire

Diverse: refactorizare, metrici, licene, management
27.04.2015
Alin tefnescu
Dezvoltatorul n practic (versiunea 1.0)
Diverse
programmingindotnet.blogspot.com
Prezentare bazat pe materiale de: Florin Leon (TU Iasi), Nigel Goddard (U. Edinburgh),
Software Project Management book, Hughes & Cotterell i altele
imagine de la joblotools.co.uk
Dezvoltatorul n practic (versiunea 2.0)
metrici
refactorizare
Diverse
licene
management
Refactorizarea
n
schimbrile pot introduce noi defecte

factorizarea trebuie efectuat n pai mici
trebuie s existe teste pentru a detecta posibilele erori
refactorizarea nu se refer la introducerea de noi funcionaliti

cele dou activiti trebuie desprite
refactorizarea mbuntete structura, nu codul

codul scris prost nu trebuie refactorizat, ci rescris
refactorizarea nu trebuie s introduc niveluri de complexitate

inutile
costurile suplimentare ale refactorizrii sunt compensate de

economiile ulterioare
metrici
refactorizare
licene
management
Refactorizare (refactoring)
n
schimbrile succesive conduc la o structur sub-optimal a

codului
crete complexitatea
scade claritatea
refactorizarea este o schimbare n structura intern a unui

produs software cu scopul de a-l face mai uor de neles i de
modificat fr a-i schimba comportamentul observabil
este o form de proiectare incremental
Exemplu - structura iniial
Prima factorizare
A treia factorizare
A doua factorizare
Semnale pentru refactorizare

Urmtoarele situaii sunt semnale pentru necesitatea refactorizrii:
n
cod duplicat
metode lungi
clase mari
liste lungi de parametri
comunicare intens ntre obiecte (cuplare puternic)
i multe altele.
V. i:
http://sourcemaking.com/refactoring
http://en.wikipedia.org/wiki/Code_smell
Optimizarea metodelor
n
scop: simplificarea i creterea coeziunii
extragerea de metode:
Optimizarea claselor
n
extragerea de clase:
de obicei funcionalitatea claselor este extins
pentru metode lungi

- o parte a metodei este transformat ntr-o nou metod
- unele din variabilele primei metode devin parametri
pentru a doua
o clas poate ajunge s aib prea multe responsabiliti
metodele care returneaz o valoare i schimb starea

unui obiect trebuie partiionate n:
- o metod care schimb starea
- o metod care returneaz o valoare
cuplarea puternic ntre 2 clase rezultate indic o

partiionare artificial
adugarea sau tergerea de parametri
se creeaz o nou clas i apoi se aplic refactorizrile

de metode i cmpuri
nlocuirea valorilor de date cu obiecte

dac asupra unor cmpuri se efectueaz operaii multiple,
acestea pot fi convertite n obiecte
Optimizarea claselor
n
scop: creterea coeziunii i reducerea cuplrii
mutarea metodelor
cnd o metod din clasa A interacioneaz mult cu
obiectele clasei B, metoda poate fi mutat n clasa B
mutarea cmpurilor
dac un cmp din clasa A este folosit mai des de ctre
metodele clasei B, cmpul poate fi mutat n clasa B
cnd cmpul devine privat, n clasa B trebuie s se
introduc proprieti accesor (get) i/sau mutator (set)
metrici
refactorizare
licene
management
Metrici de dimensiune - LOC

n
refactorizare
dimensiunea ca numr de linii de cod

ce este o linie de cod?
engl. line of code, LOC
n general, o linie nevid, care nu este comentariu
metrici
bineneles, n diverse limbaje variaz numrul de linii de cod

necesare pentru a implementa o anumit funcie
management
licene
LOC e corelat cu productivitatea, costul i calitatea (defecte /

KLOC)
cod de calitate: mai puin de 1 defect / KLOC
Metrici de implementare
Complexitate ciclomatic
Exemple de metrici:
referitoare la dimensiune
dintre dou programe cu aceeai dimensiune, programul cu

mai multe instruciuni de decizie este probabil mai complex
d.ex. numr de linii de cod

n
referitoare la complexitate
complexitatea indic nivelul de dificultate n nelegerea unui

modul:
complexitatea indic nivelul de dificultate n nelegerea unui

modul
complexitatea ciclomatic: M = e n + 2p
n = numrul de noduri (n graful asociat programului)
e = numrul de arce
d.ex. complexitate ciclomatic, variabile vii, anvergura, etc.
p = numrul de componente conexe (pentru un modul este 1)

n
complexitatea ciclomatic a unui modul este numrul de decizii

+1
aceast metric este de obicei corelat cu dimensiunea

modulului i cu numrul de defecte
Exemplu - complexitate ciclomatic
Anvergura (span)
n numrul
de instruciuni dintre 2 utilizri succesive ale unei
variabile
n dac
o variabil este refereniat de n ori, atunci are n 1

anverguri
n anvergura
medie este numrul mediu de instruciuni

executabile dintre 2 referiri succesive ale unei variabile
Pentru exemplul de mai sus (dintr-un curs anterior):

M = 13 - 10 + 1 = 4
n
Recomandare pentru complexitatea ciclomatic: M < 10
Variabile vii (live variables)

n
pentru a scrie sau citi instruciunile, un programator trebuie s

in minte o serie de variabile, inclusiv altele dect cele
implicate direct n instruciunea curent
Discuie despre metrici
complexitatea ciclomatic este definit doar pe baza logicii de

control
variabil este vie de la prima pn la ultima refereniere dintr-un

modul, incluznd toate instruciunile intermediare
variabilele vii sunt definite doar din punctul de vedere al utilizrii

datelor
pentru o instruciune, numrul de variabile vii reprezint o

msur a dificultii de nelegere a acelei instruciuni
anvergura este tot o msur a utilizrii datelor; cu ct anvergura

este mai mare, cu att modulul este mai complex
extindere la un modul: definirea numrului mediu de variabile vii

V. de asemenea: http://en.wikipedia.org/wiki/Software_metric
i Eclipse plugin pentru metrici: http://metrics.sourceforge.net
Relaii ntre diverse caliti externe i metrici

External quality attributes
refactorizare
Internal attributes
metrici
Depth of inheritance tree

Maintainability
licene
Cyclomatic complexity
Reliability
Program size in lines
of code
Reusability
Number of error
messages
management
Usability
Length of user manual
din Software Engineering, 9th ed - Ian Sommerville
Drepturile de autor
refactorizare
Legea drepturilor de autor (nr. 8 / 14 martie 1996)

recunoate i garanteaz dreptul de autor asupra operelor de
creaie intelectual, literar, artistic sau tiinific, incluznd
i programele de calculator
metrici
management
licene
englez: copyright
consimmntul pe care titularul dreptului de autor l d unei

persoane pentru a putea reproduce, folosi, difuza sau importa
copii ale unui program de calculator, se concretizeaz n
practic n licene
Proprietate intelectual
Copyright pentru codul surs
Drepturile de autor fac parte din categoria general numit

proprietate intelectual (IP - intellectual property)
n general, codul surs este supus copyright-ului (drepturilor de

autor)
Alte categorii de proprieti intelectuale:
patentele (brevete de invenie - patents): soluii originale la

anumite probleme
codul obiect i codul main sunt considerate adaptri sau

traduceri ale codului surs, deci protejate i ele
rularea unui program implic n mod necesar copierea lui
mrcile nregistrate (trademarks) i altele
copyrightul protejeaz expresia unei idei, nu ideea n sine
deci anumite tipuri de reverse engineering nu ncalc

drepturile de autor (funcia nu este protejat, ci doar codul)
codul este liceniat utilizatorului respectnd copyright-ul
problema e faptul c toate cele de mai sus nu au fost

concepute pentru software, acesta avnd caracteristici aparte
Patente
Tipuri de licene
n au
licene comerciale (pe calculator sau utilizator)
shareware (acces limitat temporal sau funcional)
freeware (gratuit)
open source:
aprut pentru a proteja inveniile de obiecte fizice sau

procese (de exemplu, motorul cu aburi).
n mai
puternice dect drepturile de autor: oprete alte persoane

s produc acel obiect, chiar dac l-au inventat independent.
n durata
de protecie este mai scurt - 17-20 ani.
n controvers
asupra a ceea ce este patentabil. Iniial, lucrurile

fizice i procesele pentru a face lucrurile fizice.
n extinse
pentru programe. Poate fi patentat un algoritm?
n Statele Unite, da. n Europa, nu, n principiu.

n Statele Unite, procesele de afaceri sunt patentabile.
D. ex., Amazon are brevete pe `un singur clic de
cumprturi, i pe ideea de clieni care recenzeaz articole
codul surs trebuie s fie disponibil i deschis pentru

modificri de ctre utilizatori. Redistribuirea (chiar i de
versiuni modificate) trebuie s fie permis.
nu exist tax pentru licen. ns produsele care includ open
source pot fi vndute.
v. definiie la http://opensource.org/docs/definition.php
exist multe asemenea licene: BSD, X11 (MIT), Mozilla
Public Licence (MPL), Gnu (GPL, LGPL), etc.
Gnu - General Public Licence (GPL)

n
a fost prima licen de tip copyleft, proprietate important care

cere ca orice modificri sau adaptri ale unui cod GPL, inclusiv
software-ul care folosete biblioteci GPL, s fie sub licena GPL
(natura viral a GPL)
GPL nu oblig distribuirea codului modificat i nu mpiedic

perceperea de taxe pentru furnizarea software-ului; i nici nu
mpiedic taxarea pentru ntreinere sau modificri (support)
GPL este incompatibil cu multe alte licene: legal nu se poate

combina software GPL cu software sub o licen incompatibil
licena GPL e adecvat atunci cnd se dorete ca software-ul s

fie accesibil n mod liber i s nu poat fi folosit de ctre cineva
care nu ofer codul surs utilizatorilor externi
refactorizare
metrici
licene
management
Lesser General Public Licence (LGPL)

n
LGPL impune restricii copyleft pe cod, dar nu i pentru

software-uri care doar folosesc codul respectiv
LGPL este folosit in principal pentru biblioteci de software, dar i

unele aplicaii, d.ex. Mozilla i LibreOffice
licena LGPL e adecvat atunci cnd se dorete ca software-ul

s fie accesibil n mod liber, dar este legal folosirea sa n
software care nu ofer codul surs utilizatorilor externi
v. http://www.fsf.org/licensing/licenses/lgpl.html
i http://www.fsf.org/licensing/licenses/gpl.html
refactorizare
metrici
management
licene
Proiect
n
Un proiect (software) este un set de activiti planificate definit

prin:
Etapele unui proiect

n
Exist trei mari etape ale unui proiect:

studiu de fezabilitate sau business case (merit fcut?)
un nceput i sfrit
planificare (cum vom face?)
un obiectiv
execuie
un domeniu de aplicare
un buget
se efectueaz o singur dat (nu e ceva repetitiv)
n
Un proiect de succes este proiectul executat n timpul dat, n

bugetul disponibil i n parametrii de calitate cerui
Managementul proiectelor software

n
managementul proiectului se refer la distribuia i controlul

bugetului, timpului i personalului
Un manager de proiect se ocup de urmtoarele activiti:

planificare
organizare
constituire echip
monitorizare
control
reprezentare
etc.
Studiu de fezabilitate
Un studiu de fezabilitate atinge urmtoarele aspecte (de obicei
ntr-un document):
n
Obiective
Motivaie
Rezumat
descriere sumar a produsului/serviciului
descriere general a soluiei propuse
descriere general a planului de implementare propus
Studiu de fezabilitate - continuare

n
Detalii privind soluia propus:

analiza SWOT (Strengths, Weaknesses, Opportunities, Threats)
Planificarea:
cine mai face acelai lucru? (studiul de pia)

comparaia cu alte soluii, avantaje+dezavantaje
achiziii necesare: observaii despre furnizor (portofoliu, suport
integrare)
tehnologii folosite: compatibilitate cu hard/software companiei
integrarea cu alte proiecte/operaii ale companiei
riscuri posibile: identificare, analiza calitativa/cantitativ, planuri
de rspuns
Studiu de fezabilitate - continuare

n
Impactul proiectului
1.1 identificarea obiectivelor i msuri pentru atingerea lor
influene pozitive + negative asupra organizaiei
1.2 stabilirea unei autoriti a proiectului
ce schimbri impune n organizaie (oprire temporar a

activitii, etc)
1.3 identificarea prilor interesate (stakeholders)
1.4 modificarea obiectivelor dup analiza prilor interesate
1.5 stabilirea metodelor de comunicare
beneficii
n
Pas 1: Domeniul de aplicare i obiectivele
Costuri
categorii de costuri + estimri
analiz cost/beneficiu (Return on Investment - ROI, payback
period)
Pas 2: Identificarea infrastructurii de aplicare i obiectivelor
4.1 identificarea i descrierea produselor proiectului (inclusiv

criteriile de calitate)
2.2 identificarea standardelor i procedurilor de instalare
4.2 etapele mari ale proiectului
2.3 organizarea echipei de proiect
4.3 construirea unei reele (ideal) a activitilor
2.1 poziionarea proiectului n portofoliul curent al firmei
n
n
Pas 3: Analiza caracteristicilor proiectului

n
Pas 4: Identificarea activitilor i livrabilelor
3.1 stabilire dac proiectul va livra un produs sau va atinge un

obiectiv
3.2 identificarea riscurilor la nivel nalt
3.3 stabilirea cerinelor utilizatorilor
3.4 selecia unui ciclu de via (tip: cascad, agil, etc.)
3.5 estimri generale ale resurselor disponibile
Pas 5: Estimatarea eforturilor pentru fiecare activitate

Pentru fiecare activitate sunt estimate:
n
efort uman necesar (numr de persoane-luni / person-months)
constrngerile temporale
Exist diverse modele de estimare a costurilor:

algoritmice: dezvoltarea pe baza datelor din trecut a unui model
privind eforturile finale (d.ex. COCOMO, Function Points etc.)
folosirea unor experi
analogie - eforturi pentru proiectelor similare finalizate
resurse disponibile / preul pe care e dispus clientul s-l
plteasc
Pas 7: Planificarea eforturilor

Reele de preceden
diagrame Gantt

Procese de Dezvoltare Software

Încărcat de

Informații document

Titlu original

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

Procese de Dezvoltare Software

Încărcat de

Drepturi de autor:

Formate disponibile

Procese de dezvoltare software n practic

Metode de dezvoltare software

Procese de dezvoltare software

fiecare etap nu trebuie sa nceap nainte ca precedenta s fie ncheiat.

bazat pe modele de proces folosite pentru productia de hardware

Etapele procesului cascad

analiza i definirea cerinelor: Sunt stabilite serviciile, constrngerile i

design: Se stabilete o arhitectur de ansamblu i funciile sistemului

integrare i testare sistem. Unitile de program sunt integrate i testate

operare i mentenan. Sistemul este folosit n practic; mentenana

sunt identificate cerinele sistemului la nivel nalt, dar, n loc de

cerinele sunt ordonate dup prioriti, astfel nct cele cu

dup ce dezvoltarea unui increment a nceput, cerinele pentru

Avantajele procesului incremental

dificulti n transformarea cerinelor utilizatorului in incremente de mrime

Exemple de procese incrementale

Unified Process cu varianta Rational Unified Process (RUP)

procese de dezvoltare n spiral introduse de Boehm

procese de dezvoltare agile. Exemple:

Rational Unified Process

Prezentare bazat pe Ian Sommerville: Software Engineering 9th edition

Boehm spiral model

Metodele de dezvoltare software expeditive" dezvoltare la

nemulumirea cu cheltuielile implicate n metodele de proiectare

Cele 12 principii ale manifestului agil

1. Prioritatea noastr este satisfacia clientului prin livrarea

Cele 12 principii ale manifestului agil

5. Construiete proiecte n jurul oamenilor motivai. Ofer-le

indivizii i interaciunea naintea proceselor i uneltelor

software-ul funcional naintea documentaiei vaste

6. Cea mai eficient metod de a transmite informaii nspre i

colaborarea cu clientul naintea negocierii contractuale

7. Software funcional este principala msur a progresului.

receptivitatea la schimbare naintea urmririi unui plan

8. Procesele agile promoveaz dezvoltarea durabil.

Cu alte cuvinte, dei exist valoare n elementele din dreapta, le

Cele 12 principii ale manifestului agil

Posibile probleme cu metodologiile agile

9. Atenia continu pentru excelen tehnic i design bun

Aplicabilitatea metodelor agile

n companiile care dezvolt produse software de

n cadrul companiilor unde se dezvolt software pentru uz

datorit orientrii lor pe echipe mici i bine integrate, exist

dificultatea de a pstra interesul clienilor implicai n acest

membrii echipei nu sunt ntotdeauna potrivii pentru

prioritizarea modificrilor poate fi dificil atunci cnd exist

meninerea simplitii necesit o munc suplimentar

contractele pot fi o problem ca i n alte metode de

Extreme Programming (XP) - 1996

Adaptive Software Development (ASD)

Test-Driven Development (TDD)

Feature Driven Development (FDD)

Behavior Driven Developement (BDD)

dezvoltarea incremental este susinut prin intermediul

implicarea clientului nseamn angajamentul full-time al

oameni, nu procese prin programare pereche, proprietatea

receptivitate la schimbare prin livrri frecvente

meninerea simplitii prin refactoring constant de cod.

Programare extrema (XP)

poate cea mai cunoscut metod agil.

Extreme Programming (XP) are o abordare "extrem" de

noile versiuni pot fi construite de mai multe ori pe zi;

procesul de planificare (The Planning Game)