METODE DE DEZVOLTARE SOFTWARE

Prof. univ. dr. Udrica Mioara

CUPRINS
1.2 STRUCTURA GENERAL A UNUI SISTEM INFORMATIC .............................................. 2
2. APLICAREA METODELOR ORIENTATE OBIECT N DEZVOLTAREA.......... 6
SISTEMELOR INFORMATICE ...................................................................................... 6
2.1 MODELUL ORIENTAT OBIECT .................................................................................... 7
2.1.2 Instrumente ale modelului orientat obiect ...................................................... 9
2.2 UNIFIED MODELLING LANGUAGE (UML) LIMBAJ STANDARD DE MODELARE ... 12
Tem: ........................................................................................................................ 12
Descriei limbajul UML ........................................................................................... 12
2.3 Diagrame UML ............................................................................................. 13
3.1 TEHNICI DE SPECIFICARE ......................................................................................... 24
3.2 TEHNICI DE CONCEPIE ........................................................................................... 26
3.3 TEHNICI DE VALIDARE ............................................................................................. 27
3.3.1 Verificare dinamic ........................................................................................ 27
Exemplu de aplicare a testului cutiei albe.............................................................. 28
3.3.2 Verificare static............................................................................................. 30
BIBLIOGRAFIE .............................................................................................................. 47

1. ORGANIZAIA - SISTEM DESCHIS DEFINIT CA SUPORT N PROCESUL DE

DEZVOLTARE SOFTWARE

1.1 Organizaia n viziune sistemic

Etapa actual este etapa n care economia mondial a trecut de la
societatea predominant industrial la societatea informaional, guvernat de un
set nou de reguli, n care tehnologiile digitale permite accesarea, procesarea,
stocarea i transmiterea informaiilor. Complexitatea activitilor desfurate la
nivelul organizaiilor reclam o viziune sistemic, n care fiecare component
este parte a unui ntreg.
n cadrul teoriei generale a sistemelor, disciplin tiinific care elaboreaz
principiile metodologice de investigare a sistemelor, care asigur o baz formal
metodologic unitar de cercetare, un loc important l ocup sistemele deschise,
sisteme ce pot realiza o stare de echilibru dinamic cu mediul exterior.
Organizaiile n cadrul crora se desfoar activiti economice sunt
considerate sisteme deschise (fig. 1).

SISTEM DECIZIONAL
Informaii

Decizii

SISTEM INFORMAIONAL
Date

MEDIUL
EXTERIOR

Ordine

Fig. 1
SISTEM OPERAIONAL

. sistemul informaional se definete ca un ansamblu organizat i integrat de

operaii de culegere, transmitere, prelucrare, sistematizare, analiz i
pstrare, difuzare i valorificare a informaiilor.
. sistemul informatic este un ansamblu structurat i corelat de proceduri i
echipamente electronice de calcul care permit culegerea, transmiterea i
prelucrarea datelor, obinerea de informaii.
sistemul informatic = cuprinde ansamblul aciunilor formale furnizoare de informaie,
desfurate sau planificate n interiorul organizaiei.

1.2 Structura general a unui sistem informatic

Evidenierea structurii generale a unui sistem informatic se obine
pornind de la funcia acestuia de a prelucra datele n vederea obinerii
informaiilor necesare unei desfurri normale a activitilor ntr-o organizaie.
Principalele componente sunt: intrri, prelucrri, ieiri.
Intrrile pot fi clasificate n tranzacii externe i tranzacii interne.
Tranzaciile externe reprezint mulimea datelor de intrare provenite din
exteriorul sistemului. Sunt date consemnate pe documente n cadrul sistemului
operaional (numr factur, tip document de plat, nume client), sau sunt date
provenite din mediul exterior (cursul de schimb valutar, cotele de TVA, cotele
de impozit).
Tranzaciile interne sunt reprezentate de date intermediare de lucru, obinute
n urma unor prelucrri desfurate n cadrul sistemului informaticl (situaia
stocurilor i soldurilor la o anumit perioad, valoarea total a produselor
livrate, valoarea total a ncasrilor).
Prelucrrile reprezint un ansamblu omogen de proceduri automate cu funcie
de:
creare i actualizare a bazei de date;
consultare a bazei de date;
reorganizare a bazei de date;

 salvare/restaurare a bazei de date.

Ieirile sistemului informatic sunt reprezentate de rezultatele prelucrrilor
desfurate. Ieirile pot fi obinute n urma unor operaii de transfer a datelor,
sau pot fi obinute n urma operaiilor de calcul pe baza unor algoritmi
prestabilii.
n funcie de coninutul i forma lor de reprezentare, ieirile pot fi
clasificate astfel:
indicatori sintetici
rapoarte
grafice
foi de calcul electronice
ieiri destinate altor sisteme
Dintre componente, setul de programe utilizat pentru efectuarea
prelucrrilor ocup un loc important, impunnd contextul de utilizare,
organizarea i funcionarea celorlalte componente. Cunoscut sub denumirea de
produs program, produs informatic sau produs software, pentru muli autori
substituie noiunea de sistem informatic. Din punct de vedere structural,
cuprinde dou elemente fundamentale: date i prelucrri (Wirth N-Prentice
Hall, EngleWood Cliffs, 1976):
Structuri de date + Algoritmi de prelucrare = Produs software
Un produs software poate reprezenta un program ce rezolv anumite
probleme, un sistem de operare, un compilator, un program utilitar, un mediu
de operare, un mediu de programare, un mediu de rezolvare, o platform, o
procedur, un program editor, un generator de programe, un program ativirus,
un document HTML/PHP/ASP, un program de e-mail, un browser, etc.
n cadrul unei organizaii, necesitatea unei viziuni unitare asupra
activitii desfuratede impune nglobarea produsele software ntr-un sistem
informatic. Metodele de dezvoltare software sunt astfel incluse n metodele de
dezvoltare ale sistemelor informatice.
1.3 Metode i modele utilizate n dezvoltarea sistemelor informatice
Dezvoltarea unui sistem informatic se face conform unei metode,
definit printr-un proces i un sistem de notaie.
procesul specific activitile efectuate pentru conceperea modelelor, ordinea
n care se execut i modul lor de corelare.
sistemul de notaie precizeaz conceptele i regulile de reprezentare a
modelelor.
ntr-o prim clasificare, metodele pot fi grupate n metode hard i metode soft.
Metodele hard pun accentul pe abordarea tiinific i consider c
realitatea, independent de oameni, poate fi modelat, neleas i

transformat n funcie de dorinele acestora. Consider c toate problemele

pot fi formalizate pe baze matematico-logice i acord proiritate datelor,
funciilor i proceselor.
Metodele soft ncearc s rezolve probleme legate de aspectele sociale
ale dezvoltrii sistemelor, de cerinele utilizatorilor. Din punctul lor de vedere,
analistul se confrunt cu situaii problem i nu cu probleme clar definite i
gata de rezolvare. Msurile luate ntr-o situaie sunt rezultatul schimbrii
organizaionale, analistul de sistem fiind vzut nu ca un expert n domeniu ci ca
un agent al schimbrii, capabil s-i stimuleze pe ceilali n obinerea unor noi
percepii asupra contextului problemei.
n funcie de obiectivele propuse, la definirea sau reproiectarea unui
sistem informatic, exist:
. metode orientate-funcii ( metode ale descompunerii funcionale );
. metode orientate-proces (metode ale fluxurilor de date);
. metode orientate-date (metode orientate spre informaii);
. metode orientate-obiect (iau n calcul n principal evenimentele la care trebuie
s rspund sistemul).
n funcie de modalitatea n care este perceput sistemul, exist:
. metode de analiz i descompunere ierarhic (funcional);
. metode de analiz i reprezentare orientat-sistemic ;
. metode de analiz i proiectare orientat-obiect.
Dintre acestea cele mai des utilizate n practic sunt metodele sistemice
i metodele orientate obiect:

medodele sistemice reprezint cea de-a doua generaie a metodelor de

analiz i proiectare. Bazndu-se pe teoria general a sistemelor, n cadrul
acestor metode, datele i prelucrrile asupra datelor sunt modelate i studiate
independent. mpreun formeaz un sistem. Axndu-se pe conceptul de baz de
date, care ofer coeren i elimin redundanele, metodele sistemice acord
prioritate datelor fa de prelucrri. Dezavantajele acestor metode rezult din
existena deficienelor n modelarea prelucrrilor, n prezena unor discordane
ntre modelele datelor i cele ale prelucrrilor.
Metodele sistemice respect cele trei nivele de abstractizare introduse prin
metodologia ANSI/SPARC: conceptual, logic i fizic. Exist astfel urmtoarele
modele:
pentru date:
model conceptual al datelor
model logic al datelor
descriere fizic a datelor
pentru prelucrri:
model conceptual al prelucrrilor
descriere logic a prelucrrilor
descriere fizic a prelucrrilor

Principalele metode sistemice sunt: MERISE, AXIAL, Information

Engineering.

metodele orientate obiect reprezint cea de-a treia generaie, utilizate

astzi n cazul sistemelor cu comportament dinamic, dependent de timp. Se
definesc entiti
de sine stttoare, n care sunt ncapsulate datele
(proprieti) i prelucrrile prin care este implementat comportamentul lor
(operaii).
Avantajul acestor metode rezult din faptul c ofer posibilitatea
reutilizrii componentelor. Existnd o integrare mult mai bun a datelor cu
prelucrrile, aduc o rezolvare coerent a aspectelor dinamice. Dezavantajul
este ns c nu ntotdeauna modelarea corespunde realitii reprezentate.
Cele mai utilizate metode sunt: Object Modeling Technologie (OMT),
Object Oriented Design (OOD). Succesul utilizrii metodelor orientate obiect a
determinat definirea unui limbaj standard de modelare, Unified Modeling
Language.
Indiferent de particulariti, o metod de dezvoltare a sistemelor
informatice poate fi definit ca un ansamblu de procedee folosite n vederea
realizrii unui sistem de programe ce evideniaz structura i funcionalitatea
sistemului real. Rezultatul este concretizat ntr-un ansamblu de documente de
concepie, de programe i de tehnici de testare, care:
. propun un demers, distingnd etapele de dezvoltare n ciclu de via al
sistemului;
. apeleaz la modularizare, reutilizare, abstractizare;
. propun formalisme (limbaje) i tipuri de documente (modele) care faciliteaz
comunicarea, organizarea i verificarea.
Exemple:
RAD Rapid Aplication Develoment
RUP Rational Unified Process
2TUP Two Track Unified Process
XP - eXtreme Programming
Metodele de dezvoltare dezvoltare a sistemelor informatice acoper
ntregul ciclu de via al sistemului: specificarea cerinelor, analiza i
proiectarea, implementarea, testarea i documentaia. La sfritul fiecrei
iteraii se reevalueaz prioritile proiectului.
De exemplu, n cazul Rational Unified Process, ciclul de dezvoltare este
prezentat n figura urmtoare:

Tem:
Prezentai o metod de dezvoltare a sistemelor informatice

2. Aplicarea metodelor orientate obiect n dezvoltarea

sistemelor informatice
Tehnicile orientate obiect constituie un nou mod de abordare a
sistemelor informatice, bazat pe abstracii ce corespund lumii reale. Obiectele
din domeniul sistemului real formeaz cadrul de lucru pentru definirea unui
model i ulterior conduc la implementare.
Pn n faza final dezvoltarea orientat obiect este un proces
conceptual independent de limbajul de programare. Poate servi ca mediu pentru
analiz i documentare, pentru definirea interfeei cu utilizatorul, sau pentru
programare.
Metodele orientate obiect acoper ntregul ciclul de via al sistemului,
mprit n trei faze: analiz, proiectare, implementare.
analiza
n faza de analiz se construiete un model precis, concis i inteligibil al
activitii desfurate (business model), un model complet al sistemului ce va fi
construit.
. analistul descrie ce trebuie s fac sistemul i nu cum o face, urmrete
definirea a ceea ce urmeaz s realizeze, i nu a algoritmilor care vor fi folosii.
. obiectele sunt concepte din domeniul sistemului i nu din domeniul
programrii.
. atenia este ndreptat asupra conceptelor care vor forma nucleul unei soluii
ce utilizeaz tehnici orientate obiect.
. analiza este selectiv, neacordndu-se aceeai importan tuturor
componentelor i nsuirilor; sunt examinate cerinele, analizate implicaiile,
reinute doar aspectele eseniale.

. sistemul real se descompune n entiti distincte, se stabilesc legturile dintre

ele i funciile ndeplinite.
. rezultatul este un model cu clase i asocieri, folosirea acestora fcndu-se n
partea de proiectare i implementare.
proiectarea
Scopul principal al proiectrii orientate obiect este s maximizeze
posibilitatea reutilizrii claselor n proiecte ulterioare, s identifice n relaiile
de motenire superclasele care faciliteaz reutilizarea n cadrul aceluiai
proiect.
. se pstreaz structura claselor stabilit n partea de analiz, lund n
considerare minimizarea timpului de execuie i folosirea raional a memoriei.
. operaiile identificate n etapa de analiz sunt exprimate algoritmic, cele
complexe sunt descompuse n operaii interne simple. Atributele i asocierile
sunt prezentate ntr-o form ce permite ulterior implementare ca structuri de
date specifice.
. clasele sunt rearanjate prin evidenierea unor relaii de agregare sau de
generalizare, sunt completate cu noi operaii i noi atribute, rezultate din
abstractizarea comportamentului comun.
. modelul claselor poate fi rafinat prin introducerea de noi clase, care pstreaz
rezultate intermediare de calcul.
. considernd clasele ca nite ,,cutii negre a cror interfa extern este
public, dar ale cror detalii interne sunt ascunse, proiectantul decide atributele
care sunt vizibile din exterior. Ascunderea informaiei interne permite ca
implementarea unei clase s fie modificat, fr a cere clienilor clasei s-i
modifice codul. Este necesar o nou documentare a claselor, pe baza celei din
partea de analiz, care s conin i modificrile care au aprut n faza de
proiectare.
ntr-o ultim faz a proiectrii, clasele i asocierile se regrupeaz n module.
implementarea
n timp ce primele dou etape sunt independente de mediul de
programare, n aceast etap trebuie aleas soluia informatic pentru realizarea
efectiv a sistemului.
. clasele i relaiile sunt translatate ntr-un limbaj de programare, de regul
orientat obiect.
. n cele mai multe cazuri, scrierea secvenelor de cod ntr-un limbaj orientat
obiect se face aproape automat, pe baza deciziilor luate n fazele anterioare.
2.1 Modelul orientat obiect

Aplicarea metodelor orientate obiect n dezvoltarea sistemelor

informatice conduce la construirea unui model obiect. Elementul central al
modelului l constituie obiectul.
2.1.1 Obiecte
Un obiect este o abstracie, un concept, folosit pentru reprezentarea
lumii reale i furnizarea unei baze practice pentru implementarea cu ajutorul
tehnicii de calcul. Descompunerea sistemului real n obiecte depinde de
modelator i de natura concret a problemei.
Exemple:
persoana IONESCU, produsul CALCULATOR, factura AS-1234 din 12/03/04
sunt obiecte din lumea real, ce se regsesc n sistemul informatic privind
personalul angajat, gestiunea resurselor i respectiv vnzarea de produse.
Caracteristicile unui obiect sunt: identitate, stare, comportament.
Modelul obiect poate fi definit ca o reprezentare direct a realitii cu ajutorul
unor componente elementare cu identitate proprie i caracterizate prin stare i
comportament.
Identitatea unui obiect este acea proprietate a obiectului care l distinge
de alte obiecte. Obiectul este definit de un identificator intern unic, independent
de valoarea sau de adresa de memorie a obiectului. Identificatorul nu este
controlat direct de programator i nu se confund cu diferitele nume utilizate de
programator pentru a-l numi.
Starea obiectului reprezint mulimea valorilor tuturor atributelor i
legturilor sale la un moment dat. Starea este adesea asociat cu valoarea unui
obiect satisfcnd anumite condiii.
Exemple:
persoana IONESCU, caracterizat prin atributele nume, prenume, vrst,
vechime n munc, poate fi n starea angajat cu carte de munc sau pensionar,
n funcie de valorile atributului vrst.
factura AS-1234 din 12/03/09 poate fi n starea achitat sau neachitat, stare
determinat de factori externi, reprezentai prin ncasarea sau nu a contravalorii
sale.
Comportamentul este determinat de ansamblul operaiilor pe care
obiectul le poate executa. Exprim modul n care un obiect acioneaz i
reacioneaz.
Exemple:
pentru persoana IONESCU, operaia afieaz permite calcularea i afiarea pe
ecran valorii atributului vechime n munc.
pentru factura AS-1234 din 12/03/09, operaia modifica_factura determin
modificri n datele nregistrate despre factur.
Comportamentul este cel care altereaz starea unui obiect, determin
schimbarea strii sale. Corespunztoare comportamentului global al obiectului,

mulimea valorilor grupate ntr-o stare, specific rspunsul obiectului la

evenimentul primit.
2.1.2 Instrumente ale modelului orientat obiect
Pornind de la componentele elementare, modelul obiect se obine
folosind instrumente specifice tehnicilor orientate obiect. Acestea sunt:
abstractizarea, ncapsularea i ierarhizarea.
abstractizarea
Tema:
Explicai conceptul de abstractizare.
n cazul tehnicilor orientate obiect, prin abstractizare se evideniaz
caracteristicile eseniale ale unui obiect, cele care-l disting de alte obiecte.
Practic, problema se abstractizeaz prin gruparea obiectele n clase.
Abstractizarea d putere modelrii i capacitate de generalizare de la cteva
cazuri particulare la cazuri similare. Definiiile comune (numele atributelor)
sunt memorate o singur dat pentru clas, n loc s fie memorate pentru
fiecare instan. Operaiile pot fi scrise o singur dat i toate obiectele
beneficiaz de codul reutilizat.
clase i obiecte
O clas de obiecte descrie o mulime de obiecte cu aceleai proprieti
(atribute), acelai comportament (operaii) i relaii similare fa de alte obiecte.
Fiecare obiect se mai numete instan a clasei. n termeni implementaionali,
fiecare obiect conine un pointer la clasa din care provine, deci are acces la
toate caracteristicile clasei sale.
O clas este definit prin:
numele clasei;
atributele, expresie a valorilor diferitelor stri ale instanelor de clas;
operaiile pentru manipularea instanelor de clase, numite metode.
Specificarea metodei poart numele de semntur, iar codul care
implementeaz operaiile constituie corpul metodei.
Noiunea de clas este mai mult utilizat de faza de execuie,
presupunnd dou aspecte: generarea de obiecte i stocarea setului de obiecte
care reprezint instanele claselor. Cu ajutorul clasei se descriu obiectele.
Obiectul posed propriile lui valori, lista atributelor i metodele fiind gestionate
de clas.
ncapsularea

ncapsularea este un proces de grupare a elementelor unei clase n

elemente accesibile din exterior i elemente proprii.
.permite separarea aspectului extern, accesibil altor obiecte, de implementarea
intern.
. ofer posibilitatea de a masca atributele proprii ale unui obiect, precum i
modul n care se execut operaiile. Implementarea poate fi astfel schimbat
fr a afecta aplicaia.
. garanteaz integritatea datelor coninute n obiect, datele ncapsulate fiind
protejate de accese nedorite.
. constituie una din premisele de baz ale reutilizrii. Un obiect poate evolua n
timp fr a afecta restul sistemului.
ierarhizarea
Ierarhizarea este o operaie de ordonare a claselor. Ajut la
identificarea relaiilor ntr-o ierarhie, la clarificarea i buna nelegere a
problemei.
n modelarea sistemelor reale, cele mai importante tipuri de relaii
prezente n ierarhia claselor sunt agregarea i generalizarea.
Agregarea este o relaie de tip parte-ntreg, n care obiecte care
reprezint componente ale unui ntreg, sunt asociate cu ntregul. Este o form
de asociere n care exist un obiect agregat, format din componentele sale,
componentele fiind vzute ca parte a agregatului. O aceeai parte poate aparine
mai multor agregri. Semantic agregatul este vzut ca un obiect, tratat ca o
unitate n multe operaii, dei fizic este format din mai multe obiecte.
Generalizarea este o relaie dintre o clas de baz i una sau mai multe
clase derivate ale ei. Atributele i operaiile comune sunt grupate n superclas,
fiind motenite de clase.
Observaii:
. Agregarea nu este un concept independent, ci o form special de asociere.
. n timp ce n cazul agregrii una din clase are un rol predominant n raport cu
celelalte, n cazul generalizrii clasele sunt integral coerente, subclasa aducnd
eventuale informaii adiionale, specifice.
. Agregarea implic dou clase, una fiind parte a celeilalte. Generalizarea este
un mijloc de structurare a descrierilor pentru o clas. Superclasa i clasa
specific proprietile unui obiect, obiectul fiind instan a superclasei i
instan a clasei.
motenirea
Partajarea atributelor i operaiilor de-a lungul unei ierarhii ntre clase i
subclase este evideniat cu ajutorul conceptului de motenire.
Motenirea permite constituirea de noi tipuri de obiecte i clase, evitnd
rescrierea i recodificarea. Noua clas poate moteni att operaii (metode), ct
i variabile de instan (atribute). n primul caz se poate vorbi de partajarea

codului ntre metode (code sharing), iar n al doilea caz, de partajarea

structurii ntre atribute (structure sharing).
Exemplu: n sistemul informatic privind contractarea i vnzarea
produselor, documentele pe cere se consemneaz activitile desfurate sunt
contractul i factura de vnzare. Prin generalizare se poate defini o clas
DOCUMENT, care are drept atribute NumrDocument i DatDocument.
Operaiile sunt: CautDat(NrDoc) i StergeDocument(NrDoc). Clasele
CONTRACT i FACTUR motenesc atributele i operaiile clasei
DOCUMENT. n plus, clasa CONTRACT are atributele TermenContract i
ValoareContract, iar clasa FACTUR are n plus atributul StareFactur.
DOCUMENT
NumrDocument
DatDocument
CautDat(NrDoc)
tergeDocument(NrDoc)

CONTRACT
TermenContract
Valoare contract

FACTUR
StareFactur

Motenirea ntre clase poate fi privit sub dou aspecte:

structural, cnd o clas are atribute motenite de la superclas;
comportamental, cnd o clas are metode motenite de la superclas.
Tema:
Construii exemple pentru motenire strucutral i comportamental.
Motenirea poate fi implementat static sau dinamic.
. motenirea static presupune adugarea cmpurilor motenite. n timp ce
execuia este rapid neimplicnd parcurgerea legturilor de motenire,
redefinirea unei clase este dificil, implicnd actualizarea tuturor subclaselor.
. motenirea dinamic se realizeaz fr copierea cmpurilor motenite, i
presupune parcurgerea legturilor de motenire. Actualizarea este mai uoar,
dar execuia este mai puin eficient.
Tema:
Construii exemple pentru motenire static sau dinamic.
Observaii:
. Generalizarea i motenirea sunt abstracii puternice folosite pentru
transmiterea similaritilor de la o clas la alta, pstrnd totui diferenele dintre

acestea. Subclasele motenesc trsturile superclasei, dar pot avea propriile lor
atribute i operaii.
. n timp ce generalizarea se refer la relaia dintre aceeai clas i subclasele
sale, motenirea se refer la mecanismul de a transmite atribute i operaii de-a
lungul unei relaii de generalizare. n implementare, motenirea este sinonim
cu noiunea de reutilizare a codului. Trsturile reutilizabile sunt grupate n
superclase.
polimorfism
n strns legtur cu motenirea, polimorfismul definete caracteristica
unei operaii de a se comporta n mod diferit n funcie de clasa de obiecte
creia i aparine. Polimorfismul permite invocarea pentru obiecte de diferite
tipuri a operaiilor cu acelai nume (semntur), dar semantic i implementare
diferit. La primirea mesajului, stabilirea metodei care se aplic se face n mod
dinamic, n funcie de clasa obiectului n cauz. Instane ale unor clase diferite
pot fi adresate uniform, primind aceleai mesaje, dar manifest comportamente
diferite.
2.2 Unified Modelling Language (UML) limbaj standard de modelare
Tem:
Descriei limbajul UML
Unified Modeling Language (UML) este succesorul unui val de metode
de analiz i proiectare orientate obiect, aprute la sfritul anilor 80 i
nceputul anilor 90. Este un limbaj unificat de modelare, rezultatul unui proces
de introducere a standardizrii n analiza i proiectarea orientate obiect. Este
punctul de pornire n dezvoltarea viitoarelor limbaje grafice.
Contribuii eseniale n definirea limbajului unificat de modelare au avut Grady
Booch, Jim Rumbaugh i Ivar Jacobson.
UML nu este o metod, este o notatie grafica care acoper majoritatea
tipurilor de diagrame necesare n timpul ciclului de via al dezvoltrii
software.
Punctele forte:
este un cadru de analiz obiect, oferind:
.. diferite perspective complementare ale sistemului, care ghideaz utilizarea
conceptelor obiect;
.. numeroase nivele de abstractizare, care permit controlul complexitii cu
ajutorul soluiilor obiect.
este un suport de comunicaie
.. notaia grafic permite exprimarea vizual a unei soluii obiect;
.. aspectul formal al notaiei sale limiteaz ambiguitile;

.. aspectul vizual faciliteaz evaluarea i compararea soluiilor.

este un limbaj formal i normalizat care:
.. ctig precizie;
.. ctig stabilitate;
.. ncurajeaz utilizarea instrumentelor CASE.
asigur independen fa de limbajul de implementare i de domeniul
aplicaiei
Puncte slabe:
punerea n practic a limbajului UML necesit pregtire complex de
specialitate.
permite reprezentarea modelelor, dar nu definete procesul de elaborare al
modelelor. Este un demers iterativ i incremental, ghidat de cerinele
utilizatorilor de sistem.
nu descrie cum se dezvolt software-ul, dar se poate folosi cu orice proces.
2.3 Diagrame UML
Ghidat de cerinele utilizatorului de sistem, UML este folosit ntr-un
demers iterativ i incremental, bazat pe nivele de abstractizare. Diagramele
UML sunt mijloacele de reprezentare i vizualizare a elementelor de modelare.
Tem: Prezentai cele 4+1 perspective definite de Ph. Kruchten n 1995.
2.3.1 Diagrama cazurilor de utilizare
Diagrama cazurilor de utilizare descrie funcionalitatea sistemului din
punctul de vedere al utilizatorului. Conine actori i cazuri de utilizare:
. actorii sunt elementele din sistem care genereaz sau primesc evenimente.
. un caz de utilizare este o secven de aciuni declanate cnd un actor
apeleaz la sistem pentru a ndeplini un proces.
Un caz de utilizare este iniiat ntotdeauna de un actor i exprim o
funcie a sistemului, declanat ca rspuns.
Constituindu-se ntr-un set complet de evenimente iniiate de unul sau
mai muli actori, diagrama cazurilor de utilizare precizeaz limitele sistemului,
specific interaciunea care are loc ntre actori i sistem, relaiile dintre sistem
i mediu. In plus, permit utilizatorului s-i structureze cerinele, s defineasc
modul n care va interaciona cu sistemul pentru a obine rezultatul dorit.
Pentru reprezentare se folosesc urmtoarele simboluri:
actor
participare
caz de utilizare

UML definete trei tipuri de relaii ntre actori i cazurile de utilizare (fig. 1)
Relaia de comunicare: actorul particip direct la cazul de utilizare;

 Relaia de incluziune: o instan a cazului de utilizare surs include i

comportamentul descris de un alt caz de utilizare. Acest tip de relaie se
folosete pentru simplificarea diagramei cazurilor de utilizare n situaii
complexe.
Relaia de extensie: cazul de utilizare surs poate fi extins cu
comportamentul unui alt caz de utilizare destinaie. Prin relaia de extensie
poate fi introdus, n anumite condiii, sub forma unui caz de utilizare distinct,
un nou caz de utilizare.
Observaii (fig. 1)
. aceeai persoan poate juca rolul mai multor actori, iniiind mai multe cazuri
de utilizare.
. un caz de utilizare poate avea mai muli actori, fiecare cu rolul su
...

fig .1
Descrierea unui caz de utilizare const n una sau mai multe instane ale
cazului de utilizare, numitescenarii. Scenariile sunt utilizate pentru a
evidenia alternative ntr-un caz de utilizare i pentru a testa completrilor sau
coreciilor n cazurile de utilizare.
Un scenariu include urmtoarele elemente:
nceputul cazului de utilizare - evenimentul care declanseaz cazul de
utilizare;
sfritul cazului de utilizare - evenimentul care provoac sfritul cazului de
utilizare;
interaciunea actorilor n cadrul cazului de utilizare;
schimbul de informaii n timpul interaciunilor ntre sistem i actori;
cronologia i originea informaiilor, momentul nregistrrii lor n interiorul
sau n exteriorul sistemului;

 repetrile de comportament, care pot fi descrise n secvene de cod prin

structuri repetitive;
situaiile opionale, folosind o formulare de tipul: "Actorul alege unul dintre
evenimentele urmtoare, eventual de mai multe ori.
Descrierea cazurilor de utilizare cuprinde:
denumire sau titlu
scop
actori
punct iniial
punct final
descriere derulare
rezultat msurabil
Exemplu:
n sistemul informatic privind acordarea unui credit pentru o firm,
descrierea cazului de utilizare -Analiza documentaiei depuse- este:
Denumire : Analiza documentaiei depuse
Scop : Calcularea coeficientului de risc
Actori: Inspectorul de credite
Punct iniial: Inspectorul de credite solicit documentaia depus de firm
Punct final: Obinerea valorii coeficientului de risc
Descriere derulare:
inspectorul de credite solicit documentaia depus de firm;
dac firma este un client al bncii se verific informaiile existente despre
client; dac nu, baza de date este actualizat cu datele generale ale clientului;
din documentaie se selecteaz informaia care contribuie la calcularea
coeficientului de risc;
n cazul unui coeficient de risc ridicat, cererea este respins;
se analizeaz suma cerut de firm prin comparaie cu posibilitile bncii de
a acorda creditul solicitat;
dac rezultatul este favorabil (nivel de responsabilitate < 100.000.000) cererea
de credit este admis i nregistrat;
Rezultat msurabil: Cererea de credit este admis i nregistrat, sau respins
Pentru acest caz de utilizare avem diagrama cazului de utilizare n figura 2.

fig. 2
2.3.2 Diagrama claselor i diagrama obiectelor
Structura static a sistemului, privit ca ansamblu al claselor de obiecte
i al relaiilor dintre clase, este reprezentat cu ajutorul a dou tipuri de
diagrame: diagrama claselor i diagrama obiectelor.
Diagrama claselor prezint structura sistemului dintr-un punct de vedere
general. n strns legtur cu ea, diagrama obiectelor evideniaz obiectele i
legturile dintre ele. Diagramele obiectelor prezint cazuri particulare,
faciliteaz nelegerea structurilor de date complexe.
Clasele corespund semantic entitilor din sistemul real. O clas
desemneaz un grup de obiecte care au proprieti similare (atribute), un
comportament comun (operaii) i relaii comune cu alte obiecte. Reprezentarea
unei clase presupune specificarea atributelor ce-i definesc structura, a
operaiilor ce-i definesc comportamentul i a relaiilor cu celelalte clase:
. fiecare atribut poate lua o valoare dintr-un domeniu de definiie specificat n
reprezentarea clasei. Implicit, atributele sunt ncapsulate n clas, accesul la ele
fiind permis prin intermediul operaiilor.
. operaiile sunt reprezentate mpreun cu numrul, ordinea i tipul
argumentelor necesare definirii aciunii lor. n cazul cnd operaia este o
funcie, se specific i tipul valorii returnate.
. asocierea este o conexiune semantic bidirecional ntre clase. Ea este
reprezentat printr-o linie continu ntre clasele implicate, de-a lungul creia se
scrie numele asocierii. Dac sensul de transmitere a mesajelor este unic, acesta
se evideniaz printr-o sgeat de la emitor la receptor.
Dintre proprietile unei asocieri, multiplicitatea este cel mai des
ntlnit n diagramele de structur. Este determinat de context i evideniaz
numrul instanelor unei clase ce se pot asocia cu o singur instan din alt
clas.

n diagrama claselor, multiplicitatea se specific printr-o cifr urmat

eventual de semnul + sau semnul *, printr-un interval sau printr-o
succesiune de cifre. Astfel,
1 nseamn c o instan a unei clasei este legat la o singur instan a clasei
asociate;
(1+) sau (1*) nseamn c una sau mai multe instane ale unei clase sunt legate
cu o instan a clasei asociate;
2-5 nseamn c dou pn la cinci instane ale unei clase sunt legate cu o
instan a clasei asociate;
1,2,3 nseamn c una, dou sau trei instane ale unei clase sunt legate cu o
instan a clasei asociate.
Agregarea i generalizarea, ca forme de asociere prezente n procesul
de ierarhizare a claselor, sunt reprezentate cu simboluri specifice:
. agregarea este reprezentat printr-un romb plasat la captul de asociere al
clasei agregat (figura 2.4);
. generalizarea este reprezentat printr-un triunghi ce puncteaz spre
superclas(figura 2.4);
n UML, o clas este reprezentat printr-un dreptunghi n care se
specific numele clasei, atributele i operaiile.
Nume clas
Atribute
Operaii

Furnizori
cod:integer
Nume:string
CitesteCod()
ScrieNume()

Desemnarea obiectelor se face prin nume individuale sau prin nume

generice n locul numelor individuale; numele obiectului este subliniat.
401_furnizor

: Furnizori

Observaie:
Notaia UML permite reprezentarea nivelului de vizibilitate al atributelor i
metodelor, definind trei drepturi de acces:
. public funciile din toate clasele pot accede la aceste atribute sau metode;
. protejat accesul este rezervat funciilor din clase ntre care exist o relaie de
generalizare (funciile claselor i subclaselor);
. privat accesul este limitat la metodele clasei.
Corespunztor, caracterul ce reprezint vizibilitatea este:
+
pentru un atribut public;
#
pentru un atribut protejat;
pentru un atribut privat.

Figura 3 prezint diagrama claselor n cazul sistemului informatic privind

aprovizionarea cu produse conform comenzilor primite de la clieni

fig. 3
Teme: Completai diagrama claselor cu atribute i operaii.
Construii o diagram a claselor n care s evideniai relaia de
generalizare
2.3.3 Diagrama de secvene
Diagrama de secvene ilustreaz interaciunile dintre obiecte de-a lungul
unui scenariu al unui caz de utilizare.
. fiecare obiect este reprezentat printr-un dreptunghi n care se nscrie numele.
Linia de via a obiectului se specific printr-o bar vertical.
. mesajele sunt reprezentate prin sgei orizontale de la emitor la receptor.
Convenind c timpul se scurge de sus n jos, ordinea de trimitere este dat de
poziia pe axa vertical.
. elementele prezente n diagrama de secvene sunt translatate n diagrama
claselor:
. mesajele corespund operaiilor prin care obiectele comunic;
. pentru fiecare mesaj, n clasa obiectului destinatar trebuie s existe o operaie
corespunztoare, reacia obiectului la mesajul primit.
Exemplu:

n sistemul informatic privind aprovizionarea cu mrfuri, succesiunea

operaiilor de la receptia mrfii pn la nregistrarea facturii in cadrul
serviciului financiar poate fi prezentat n diagrama de secvene din figura 4.

fig. 4

2.3.4 Diagrama de colaborare

Diagrama de colaborare este complementar diagramei de secvene,
constituind un alt mod de reprezentare a relaiilor dintre obiecte.
. prezint un grup de obiecte i interaciunile dintre ele; obiectele i legturile
dintre ele au aceeai reprezentare ca n diagrama obiectelor;
. mesajele schimbate ntre obiecte sunt reprezentate de-a lungul legturilor;
ordinea de trimitere a diferitelor mesaje este indicat printr-un numr amplasat
la nceputul mesajului.
. numele mesajului corespunde unei operaii definite n clasa obiectului
destinatar al mesajului, argumentele sale corespunznd parametrilor actuali ai
operaiei;
. argumentele mesajelor sunt reprezentate ulterior fie n pseudocod fie n
sintaxa limbajului de programare;
. pentru a evidenia declanarea interaciunilor de ctre un element extern
sistemului, n diagramele de colaborare pot fi cuprini actori.
De exemplu (fig.5), diagrama de colaborare definit pentru a evidenia
aprovizionarea cu materiale i pstrarea lor n gestiune este:

fig.5
n faza de analiz, diagramele de colaborare urmresc scenarii definite
pornind de la cazurile de utilizare. Ele pot completa modelul de analiz,
adaugnd noi clase: de frontier (pentru interaciunile dintre sistem i actori) i
de control.
n faza de proiectare, diagrama de colaborare furnizeaz un punct de
vedere complet al dinamicii sistemului, evideniind comportamentul claselor ca
rspuns la apariia unor evenimente, noi operaii i clasele crora le aparin.
Colaborrile definite pentru a urmrii anumite cerine ale utilizatorilor
pot conduce la apariia sau dispariia unor obiecte, la modificarea proprietilor
unui obiect, la actualizarea restriciilor de integritate sau la modificarea
relaiilor dintre obiecte. n cazul n care obiecte aparinnd aceleiai clase
particip la colaborri diferite, n funciile de scenarii diferite ale aceluiai caz
de utilizare, se pot specifica mpreun cu mesajele condiii ce aduc detalii
suplimentare pentru implementare.
Diagramele de colaborare mpreun cu diagramele de secvene
alctuiesc aa zisele diagrame de interaciune, ce evideniaz mesajele trimise
ntre obiecte. n timp ce o diagram de secvene se construiete pentru un
singur scenariu n care pot fi implicate mai multe obiecte, diagramele de
colaborare conin un grup restrns de obiecte, ce pot fi implicate n mai multe
scenarii.
2.3.5 Diagrama de stare

Diagrama de stare (diagrama schimbrilor de stare) descrie

comportamentul obiectelor unei clase prin stri i evenimente.
. completeaz descrierea unui caz de utilizare;
. se construiete doar pentru clasele cu comportament dinamic semnificativ;
. modeleaz ciclul de via al unei singure clase, evideniind i eventualele
evenimente trimise de ea la alt clas din sistem;
. conine o singur stare iniial i una sau mai multe stri finale, determinate de
condiiile de apariie ale evenimentelor; starea este descris printr-un nume care
o identific i o list de aciuni/activiti ce sunt executate la apariia unui
eveniment.
. tranziia de la o stare la alta reprezint schimbarea strii datorit unui
eveniment; ea este reprezentat printr-o sgeat de la starea surs la starea
destinaie etichetat cu:
.. numele evenimentului care a generat tranziia
.. condiia de apariie a evenimentului
.. aciunea ce se execut la apariia evenimentului.
. elementele prezente n diagrama de colaborare sunt translatate n diagrama
claselor:
.. aciunile/activitile ce sunt executate la apariia unui eveniment corespund
unor operaii descrise n clas;
.. starea unui obiect la un moment dat este evideniat printr-un atribut inclus
ntre atributele clasei
Exemplu: n sistemul informatic privind aprovizionarea, diagrama de stri
pentru o factur este cea din figura 6:

fig. 6

2.3.6 Diagrama de activiti

Diagrama de activiti descrie comportamentul sistemului introducnd
elemente de implementare. Folosete urmtoarele elemente: aciune, tranziie,
decizie:
. aciunea corespunde unei etape n execuia unui algoritm. Fiecare operaie,
privit ca o nlnuire de aciuni, poate fi detaliat n operaii elementare.
Pentru simplificarea diagramelor, aciuni omogene pot fi grupate n
subactiviti.
. tranziia de la o aciune la alta se reprezint printr-o sgeat etichetat
eventual cu:
numele evenimentului care determin tranziia
condiia de apariie a evenimentului
. decizia indic ramificarea unei tranziii n funcie de ndeplinirea unei
condiii.
Ataat unui caz de utilizare, diagrama de activiti i detaliaz aciunile
i procesele corespunztoare. Pentru prezentarea derulrii aciunilor sunt
folosii termeni apropiai utilizatorului.
Exemple:
diagrama de activiti din figura 7 evideniaz activitile desfurate pentru
aprovizionarea cu marf i nregistrarea ei n gestiune. Poate folosi pentru
completarea descrierii cazurilor de utilizare din sistemul informatic privind
aprovizionarea, sau poate nsoi diagrama de secvene din cadrul aceluiai
sistem informatic.

fig. 7
Ataat unei clase cu comportament dinamic semnificativ, diagrama de
activiti descrie tranziia de la o stare la alta sau algoritmul de prelucrare al
operaiilor; conine elemente de implementare ale operaiilor descrise n clase.
Aciunile pot fi descrise n limbaj natural, n pseudocod sau ntr-un limbaj de
programare (C++, Visual Basic). Echivalente schemelor logice utilizate n
programarea structurat, diagramele de activiti conin structurile
fundamentale de programare: liniar, repetitiv sau alternativ.
3. Tehnici de dezvoltare a sistemelor informatice (elemente de inginerie
software)
Progresele nregistrate n domeniul tehnicii de calcul i mai ales n
domeniul limbajelor de programare, au determinat apariia i dezvoltarea
Ingineriei Software (Software Engineering). Privit ca un cumul de metode i
tehnici bazate pe realizri din domeniul IT, permite trece de la o dezvoltare a
produselor ad-hoc i imprevizibil, la o dezvoltare structurat, constructiva i
sistematic, cu scopul de a produce n mod industrial sisteme informatice de
cea mai bun calitate.
Termenul a fost adoptat n 1968 la NATO Software Engineering
Conference, inut la Garmisch, Germania. Include cunotine, instrumente i
metode pentru definirea cererilor, pentru specificarea, construirea i ntreinerea
programelor.
Dintre definiii menionm:
F. L. Bauer (prima definiie dat ingineriei software):

Ingineria programrii este stabilirea i utilizarea de principii inginereti solide

pentru a obine n mod economic programe sigure i care funcioneaz eficient
pe maini de calcul reale.
IEEE Standard Glossary of Software Engineering Technology (1983):
Ingineria software reprezint abordarea sistematic a dezvoltrii, funcionrii,
ntreinerii i retragerii din funciune a programelor.
Acest domeniu:
are ca scop dezvoltarea metodelor, instrumentelor i tehnicilor ce pot
asigura un proces de producere software controlat, rezultatul fiind sisteme
software performante i fiabile.
este legat de tehnologii i practici aparinnd tiinei calculatoarelor,
managementului proiectelor, ingineriei, proiectrii interfeelor i altor domenii.
este n relaie cu alte discipline de inginerie: inginerie de sistem i gestiune
de proiecte, sigurana i fiabilitatea sistemelor.
se preocup de procedeele de construire software, astfel nct s fie
ndeplinite urmtoarelor criterii:
sistemul creat rspunde nevoilor utilizatorilor;
calitatea corespunde contractului de service iniial;
costurile rmn n limitele prevzute iniial;
ntrzierile rmn n limitele prevzute iniial.
Tem:
Prezentati i comentati citeva definitii/caracteristici ale ingineriei software.
Principalele ramuri ale ingineriei software acoper:
tehnicile de specificare
tehnicile de concepie
tehnicile de validare/verificare
gestiunea proiectelor
aspectele socio-economice ale proiectelor de dezvoltare a produselor
software.
3.1 Tehnici de specificare
Prin specificare nelegem o descriere a unor caracteristici ale
produsului final, (un program sau o aplicaie format dintr-un sistem de
programe) care trebuie s fie realizat n mod obligatoriu de ctre proiectant
(programator) pentru ca produsul s poat fi acceptat i utilizat de beneficiarul
su.
n fiecare dintre etapele de dezvoltare a sistemelor software complexe,
scopul i instrumentele de descriere a specificaiilor sunt diferite.

Corespunztor, exist diferite tehnici de specificare, caracteristice fiecrei faze

de dezvoltare:
tehnici de specificare a cerinelor sau a exigenelor funcionale i
nefuncionale (eficacitate, dimensiuni, siguran n funcionare etc.); se aplic
n faza de analiz a cerinelor i se exprim, n general, n limbaj natural;
tehnici de specificare a sistemului; se aplic n faza de analiz de sistem i se
refer la natura funciilor oferite, la comportamentul dorit i la datele necesare
pentru realizarea funciilor;
tehnici de specificare a arhitecturii sistemului; se aplic n faza de
concepie general i definesc modulele de arhitectur ce urmeaz s fie
realizate;
tehnici de specificare tehnic (sau de detaliu); se aplic n faza de proiectare
detaliat a modulelor, programelor i structurilor de date;
In teoria ingineriei software sunt recunoscute dou criterii de clasificare
a specificaiilor:
1 prin formalismul utilizat:
specificaii informale exprimate, n general, n limbaj natural;
. permite comunicarea ntre nespecialiti;
. nu impune reguli sau convenii de structurare i este lipsit de precizie,
fiind, prin urmare, dificil de analizat.
specificaii semiformale prezentate n general n forme grafice, avnd un
neles mai mult sau mai puin precis;
. modelul nu este normalizat, fiind deschis fa de alte metode de reprezentare
care aduc elemente specifice fr a denatura modelul;
. modelul permite specificarea structurilor de date i a relaiilor dintre
elementele de date care compun structurile reprezentate;
specificaii formale a cror sintax i semantic sunt definite n mod formal
printr-un aparat matematic adecvat.
. sunt bazate pe aparate matematice (teoria mulimilor, logica clasic, logicile
neclasice (cum ar fi logicile temporale) etc.
. sunt utilizate pentru specificarea tipurilor de date abstracte, dar pot fi
generalizate pentru a permite specificarea unor sisteme complete (ex: limbajul
Z).
2 prin caracteristicile descrise:
. specificaii declarative descriu doar proprietile produsului, necesare
pentru a rspunde cerinelor utilizatorului;
. specificaii operaionale descriu comportamentul produsului n raport cu
cerinele utilizatorului; sunt descrise printr-un model care poate fi simulat pe o
cale oarecare.
Tema:
Exemplificai utilizarea limbajului UML n specificarea semiformal a
produselor software

3.2 Tehnici de concepie

Faza de concepie const n construirea unei prime forme a sistemului,
pe baza specificaiilor rezultate din faza de analiz. Prin rafinarea acestei
prime forme, n etape succesive (iterativ), se obine o imagine final a
sitemului, imagine ce permite trecerea la etapa de realizare a programelor
(implementare).
Tehnicile de concepie permit definirea arhitecturii logice a sistemului
proiectat ntr-o form care corespunde cerinelor funcionale exprimate n faza
de analiz. Prin urmare, tehnicile de concepie fac legtura ntre cerinele
utilizatorului i soluia de programare gsit pentru implementarea aplicaiei.
Sunt cunoscute n prezent dou paradigme, de concepie diferit, privind
modelarea conceptual a produselor software: funcional i obiectual.
Tehnicile funcionale permit, n general, modelarea proceselor
informaionale sub trei aspecte, care pot fi vzute separat sau complementar:
1. dinamic, referitor la fluxurile de date i care reprezint transformarea datelor
n sistem;
2. static, referitor la structura logic a datelor (entitate-relaie);
3. funcional, referitor la structura logic a prelucrrilor (componentele
programabile i relaiile lor n sistem).
Printre cele mai cunoscute tehnici funcionale se numr: SADT (Structured
Analysis and Design Technique, JSD (Jackson Software Development),
MERISE.
Tehnicile obiectuale (orientate obiect) au fost concepute pentru a
permite dezvoltarea unor componente reutilizabile ale sistemelor software.
Aceste componente (module) ncorporeaz ntr-o form coerent datele,
funciunile i logica de control a modulelor programabile. Tehnicile obiectuale
pot fi considerate ca fiind, n mod egal, metode de specificare (analiz) i
metode de concepie (proiectare).
Abordarea obiectual se deosebete de cea funcional prin faptul c nu
trateaz (separ) n mod distinct datele de prelucrri, propunnd regruparea i
asocierea datelor i prelucrrilor n entiti numite obiecte. Fiecare obiect
posed un ansamblu de proprieti ale datelor cu care opereaz (numite
atribute) i un ansamblu de operaii predefinite (numite metode) care i
permit s rspund unor cereri de prelucrare. Obiectele comunic ntre ele prin
mesaje care activeaz metodele din obiectele receptoare. Toate obiectele care
posed aceeai structur aparin unei clase, toate obiectele similare ca structur
fiind numite instane ale clasei creia i aparin.
Sunt cunoscute mai multe astfel de metode: metoda OMT (Object
Modeling Technique), metoda Booch, metoda OOSE (Object Oriented
Software Engineering).

Tema:
Exemplificai utilizarea UML n faza de concepie a produselor software
3.3 Tehnici de validare
Verificarea sistemelor software nu se refer numai la cod (program),
acoperind toate produsele specifice fazelor ciclului de via al unui proiect
informatic. Rezultatul verificrii nu const, n mod necesar, n acceptarea sau
respingerea produsului. De cele mai multe ori, se caut anomaliile posibile n
funcionarea produsului. Identificarea unor defeciuni posibile ale produselor
software este limitat, mai ales n cazurile programelor de mari dimensiuni.
Verificarea sistemelor software este necesar, n primul rnd, pentru
descoperirea erorilor de concepie care pot influena funcionalitatea
produsului (caz n care verificarea const n testarea comportamentului
produsului n diverse contexte de funcionare), sau pentru identificarea cauzelor
unor defeciuni care apar n funcionarea curent a produsului.
In terminologia IEEE (norma 729), termenul de defeciune (cdere) este
folosit pentru a desemna o stare a produsului care genereaz o eroare
manifestat printr-o anomalie n funcionarea programului, i care const n
producerea unui rezultat anormal (n raport cu o anumit norm), sau ntr-o
pan provocat la nivelul sistemului gazd (blocaj unitate central sau
periferice, blocarea sistemului de operare etc.):
Anomalie (fault)
Defeciune Eroare
Pan (failure)
Exist dou moduri de abordare a procesului de verificare, care trebuie
s fie considerate complementare:
verificare dinamic (numit i verificare experimental sau testarea
produsului) a comportamentului produsului folosind seturi de date care
simuleaz condiiile reale de exploatare;
verificare static i analiza proprietilor produsului, fr simularea
execuiei programelor componente.
3.3.1 Verificare dinamic
Se efectueaz jocuri de test (de ncercare) care nu pot fi, n general,
exhaustive. Jocul de test este ales astfel nct rezultatele execuiei programului
s fie comparabile cu rezultatele ateptate conform specificaiilor de
funcionare ale produsului (pariale sau globale). Scopul este de a pune n

eviden eventualele erori. Testele pot s arate prezena erorilor dar nu pot
demonstra absena erorilor.
n construirea testelor se disting trei moduri de abordare a construciei
jocurilor de test:
a) Abordarea aleatoare a testului
Testul este ales n mod aleator din domeniul de definiie al datelor de
intrare ale programului. Domeniul de definiie este stabilit pe baza
specificaiilor de interfa operator-main ale programului (intrri-ieiri).
Metoda nu garanteaz o bun acoperire a ansamblului intrrilor. In particular,
testul poate s nu surprind unele limite sau situaii de excepie, avnd astfel o
eficacitate limitat.
b) Abordarea funcional (sau a cutiei negre) :
Se iau n considerare numai specificaiile privind funciunile
programului (sau CE trebuie s fac produsul). Specificaiile trebuie s fie
suficient de clare i complete pentru a permite verificarea fiecrei funciuni
predefinite. Verificarea funcional se refer n special la date i rezultate.
Poate s apar ns riscul unor explozii combinatoriale, care antreneaz
necesitatea de a dispune de un volum foarte mare i de o larg varietate de date
de intrare, i care ar putea duce la costuri i durate excesive de testare.
c) Abordarea structural (sau a cutiei albe):
In aceast form, testarea se refer la structura intern a programului
(modulului). Se pot stabili mai multe criterii de aplicare a testului:
c1) Criteriul parcurgerii instruciunilor jocul de test trebuie s arate c
toate instruciunile elementare sunt executate cel puin o dat;
c2) Criteriul parcurgerii arcelor i nodurilor grafului de control
graful de control este o reea care cuprinde structurile de control ale
programului, cum ar fi spre exemplu:

c3) Criteriul de parcurgere a drumurilor din graful de control.

c4) Criteriul de verificare a condiiilor.
Exemplu de aplicare a testului cutiei albe
Fie urmtorul program descris n pseudocod:
citete(x)
citete(y)

z=0
semn = 1
dac x < 0 atunci
semn = -1
x=-x
sfrit dac
dac y < 0 atunci
semn = - semn
y=-y
sfrit dac
atta timp ct x >= y execut
x=x-y
z=z+1
sfrit
z = semn * z
a) Desenai graful de control asociat programului i numerotai nodurile.
b) Prin ce secven de noduri trebuie s trecem pentru a satisface criteriul de
acoperire a instruciunilor? Precizai jocul de test minim necesar pentru
satisfacerea acestui criteriu.
c) Prin ce secven de noduri trebuie s trecem pentru a satisface criteriul de
acoperire a arcelor ? Precizai jocul de test minim necesar pentru satisfacerea
acestui criteriu.
d) Prin ce secvene de noduri trebuie s trecem pentru a acoperi toate drumurile
posibile din graf ? Precizai jocul de test minim necesar pentru satisfacerea
acestui criteriu.
Soluie:
a)

b) noduri
joc de test

1 2 3 4 5 6 7 8 9 10 11 12
(x=-5, y=-2)

c) noduri
joc de test

1 2 5 8 11 12 i 1 2 3 4 5 6 7 8 9 10 11 12
(x=2, y=5) et (x=-5, y=-2)

d) noduri

joc de test

1 2 5 8 11 12 i 1 2 5 8 9 10 11 12 / 1 2 3 4 5 8 11 12 i
1 2 3 4 5 8 9 10 11 12 / 1 2 5 6 7 8 11 12 i
1 2 5 6 7 8 9 10 11 12 / 1 2 3 4 5 6 7 8 11 12 i
1 2 3 4 5 6 7 8 9 10 11 12
(x=2, y=5) (x=5, y=2)
(x=-2, y=5) (x=-5, y=2)
(x=2, y=-5) (x=5, y=-2)
(x=-2, y=-5) (x=-5, y=-2)

3.3.2 Verificare static

Spre deosebire de verificarea dinamic, verificarea static are ca scop
analiza proprietilor produsului, fr simularea execuiei programelor
componente.
Sunt cunoscute dou tipuri de tehnici de verificare static: tehnici
informale i tehnici formale. Aplicarea acestor tehnici depinde de
complexitatea produsului software analizat i de scopurile testrii.

Tema: prezentai tehnicile informale i tehnicile formale din cadrul

verificrii statice.

4. STUDIU DE CAZ
Utilizarea limbajului UML depinde de complexitatea sistemului real ce
urmeaz a fi modelat, de metoda de management i realizare a proiectelor, de
tipul sistemului informatic ce se dorete realizat, precum i de nivelul de
detaliere dorit n faza de proiectare.
Diagramele UML :
. pot conduce la obinerea unui model al activitilor desfurate n sistemul
real;
. pot contribui la obinerea unei scheme concise ce rspunde problemelor cheie
ale aplicaiei;
. pot furniza specificaii detaliate pentru sincronizarea modelului cu codul
surs;
. pot evidenia erori n soluiile sistemelor deja construite .
Fiecare diagram se construiete ntr-un anumit moment al dezvoltrii
sistemului i are o anumit utilitate n proiect. Deciziile sunt luate de echipa de

realizare a proiectului, innd cont de cerinele funcionale ale sistemului i de

resursele disponibile.
4.1- Diagrame UML construite pentru obinerea unui model al
activitilor desfurate ntr-o organizaie
In acest studiu de caz ne propunem s evideniem utilizarea diagramelor
UML pentru obinerea unui model al activitii desfurate ntr-o organizaie.
n locul descrierii explicite a activitii desfurate, am preferat s evideniem
procesele identificate.
Pentru fiecare etap vom prezenta exemple i vom propune teme ce pot fi
dezvoltate lund n calcul activitatea desfurat n organizaie. Diagramele
UML construite conduc n final la o diagram a claselor complet,
implemetabil ntr-un limbaj orientat obiect. n paralel, pornind de la aceeai
diagram, se poate construi un model al claselor persistente, ce conduce la baza
de date relaional care asigur persistena datelor.
Ne vom opri dup etapa de proiectare, considernd c soluia de implementare
i persistena datelor fac obiectul altor discipline din programa de nvmnt.
Teoretic, ntregul ciclu de via al sistemului informatic poate fi mprit
n mai multe etape. Acestea sunt:
A
construirea unui model al sistemului real (Business modelling);
B
analiza (Analysis);
C
proiectarea (Design);
D
implementarea. (Implementation).
. importana i amploarea etapelor se stabilete n funcie de dimensiunea i
scopul sistemului;
. aceste etape se parcurg formal sau nu, contient sau nu, dar se parcurg;
. fiecare etap are nevoie de intrri provenite din cea anterioar i produce
iesire pentru urmtoarea;
. etapele se desfoar succesiv; dac ns lucreaz echipe specializate pe faze
de dezvoltare, se pot desfura i n paralel, pentru c dezvoltarea orientat
obiect urmeaz un model n spiral.
A
Construirea unui model al sistemului real este etapa n care se
identific procesele desfurate i modul n care ele interacioneaz.
Activitile din cadrul proceselor se detaliaz cu ajutorul diagramelor de
activiti, n 3 etape:
..A1.. se identific procesele i se includ, pe mai multe nivele, ntr-o diagram
general a activitilor desfurate. Diagrama este mai degrab cuprinztoare
dect precis, ascunznd structura organizaional i descriind doar
funcionalitatea organizaiei.
Exemplu:

Activitile desfurate conduc la identificarea mai multor procese, ce pot fi

grupate pe 3 nivele:
Nivel 1:
.1- Planificare = dezvolt i monitorizeaz planul tactic i strategic al
organizaiei: investiii, resurse, evaluare performane, monitorizare riscuri i
oportuiniti.
.2- Aprovizionare = cuprinde toate activitile legate de aprovizionare, inclusiv
achitarea facturilor primite de la furnizor; include contractarea precum i
asigurarea calitii articolelor aprovizionate.
.3- Vnzare = nregistreaz ntreaga activitate de vnzare, incluznd
marketingul, comenzile de la clieni, facturarea, distribuia.
.4- Producie = include producia i depozitarea, transportul ntre secia de
producie i depozite.
.5- Dezvoltare = se refer la construcii pentru fabrici, secii de producie,
birouri, depozite.
.6- Finane = vizeaz circuitul banilor i controlul activitilor financiare:
investiii, gestiune a conturilor bancare, raportri legale.
.7- Cercetare = urmrete cercetrile ntreprinse pentru dezvoltarea i
optimizarea activitii desfurate.
Nivel 2:
De exemplu, procesul .3- Vnzare se poate detalia astfel:
.3.1 negociere contract;
. 3.2 preluare comenzi;
. 3.3 livrare articole;
.3.4 acceptare refuzuri;
. 3.5 facturare;
. 3.6 ncasare facturi.
Nivel 3:
De exemplu,
procesul .3.2. preluare comenzi se poate detalia astfel:
.3.2.1 se confirm alegerea clientului
.3.2.2 se preia comanda de la client
3.2.3 se negociaz data livrrii
3.2.4 se stabilete data livrrii
3.2.5 se confirm detaliile din comand
procesul .3.5 facturare se poate detalia astfel:
. 3.5.1 identificare a bunurilor livrate i acceptate;
. 3.5.2 stabilire a preului de vnzare;
. 3.5.3 aplicare a reducerilor;
. 3.5.4 completare a fcaturilor;
. 3.5.5 editare i trimitere a facturilor ce nsoesc produsele.

Schematic, procesele pot fi prezentate n urmtoarea structur ierarhic:

1

3Vnzare

4 .

3.1

3.5 Facturare

3.5.2 Stabilirea preului de vnzare

.

Tema:
Definii procese suplimentare pentru activitatea desfurat n organizaie.
Detaliai cteva procese evideniate pe nivelele descrise.
Descriei activitatea desfurat astfel nct s evideniai ntr-o manier
personal procesele cuprinse n descriere.
..A2.. se construiesc diagrame de activiti pentru procesele analizate.
Pentru o mai bun nelegere a structurii i dinamicii organizaiei se includ
obiecte. Plasnd obiecte n diagrama de activiti, putem vedea unde sunt create
i manipulate obiectele n desfurarea procesului, unde se schimb starea lor.
La acest nivel, obiectele sunt privite doar ca avnd o stare ce poate fi schimbat
prin aciuni asupra obiectului.
Exemplu:
Diagrama de activiti pentru procesul .3.2. - preluare comenzi este (fig. 1):

fig. 1
Tem:
Contruii diagrame de activiti pentru alte procese
B
Analiza, n sens larg, acoper investigarea activitii desfurate i
definirea unui sistem informatic.
. ncepe dezvoltarea sistemului de la definirea proceselor, de la identificarea
cazurilor de utilizare care descriu aceste procese i merge pn la momentul n
care dezvoltatorii de sistem au un model comprehensiv al comportamentului
sistemului, pot prezenta utilizatorilor viitorul sistem, mpreun cu tipurile de
informaii memorate i regsite de el.
. se disting dou faze: analiza cerinelor i analiza de sistem.
B1
Analiza cerinelor, clasificate n cerine funcionale, care evideniaz ce
face sistemul i cerine nefuncionale, ce vizeaz performanele sistemului (
fiabilitate, calitate a interfeei).
. se centreaz n jurul diagramei cazurilor de utilizare, cea care exprim
interaciunea cu mediul exterior;
. conduce la definirea comportamentul extern al sistemului i la includerea
sistemul n contextul activitii desfurate (business environment);
Schematic, intrrile i ieirile acestei etape pot fi reprezentate ca n figura 2,
unde:
. diagrama cazurilor de utilizare prezint actorii i aciunile declanate de ei.

. descrierea unui caz de utilizare const n prezentarea scenariilor. Se iau n

calcul urmtoarele recomandri :
. se clarific toate problemele cu persoanele implicate (stakeholders);
. se identific setul de scenarii ce acoper toate alternativele i excepiile;
. pentru fiecare scenariu se construiete o diagram de secvene;
. n cazul scenariilor cu alternative i excepii se recomand construirea
diagramelor de activiti pentru evidenierea detaliilor.
. prototipurile pentru interfaa cu utilizatorul ajut la vizualizarea modului
n care sistemul lucreaz.
Participani

Scop

Procesele
existente

Analiza cerinelor

Diagrama cazurilor
de utilizare

Descrierea cazurilor
de utilizare

Prototipuri pentru
interfa

fig. 2
Participanii la dezvoltarea viitorului sistem stabilesc n aceast etap sarcini
pe grupuri de persoane implicate, iau decizii privind oportunitatea definirii unui
nou sistem informatic.
Exemplu:
Scop: Dezvoltarea unui sistem informatic pentru activitile ce vizeaz
aprovizionarea cu componente, conform comenzilor primite de la clieni pentru
asamblarea unor sisteme de calcul (produse finite).
Procese existente:
. gestiunea comenzilor primite de la clieni
. contractarea mrfurilor de la furnizor
. aprovizionarea cu marf
. gestiunea mrfurilor aprovizionate
. achitarea furnizorilor
Participani:
. utilizatori
. beneficiari
. analiti
Sarcini:
. documentarea viziunii proiectului
. construirea cazurile de utilizare
. descrierea cazurilor de utilizare

. definirea arhitecturii preliminare a sistemului

. analiza riscului
Decizii:
. ce i propune sistemul pentru fiecare din utilizatori?
. tehnic i organizaional este posibil?
. ce riscuri pot afecta fezabilitatea?
. beneficiile justific costurile?
Diagrama cazurilor de utilizare pentru procesele ce vizeaz aprovizionarea
conform contractelor ncheiate cu furnizorii este (fig. 3):

fig. 3
Descrierea cazurilor de utilizare.
Prezentm n continuare cteva scenarii ce descriu cazuri de utilizare
reprezentative, cu eventuale alternative sau excepii.
= scenariul 1
Denumire: ncheierea contractului pentru aprovizionarea cu componente
Descrierea derulrii:
.. stabilirea necesarului de aprovizionat;
.. analiza ofertelor de la furnizori;
.. alegerea furnizorului;
.. stabilirea condiiilor contactuale;
.. semnarea contractului de ambele prti.

= scenariul 2
Denumire: Gestiunea componentelor aprovizionate
Descrierea derulrii:
.. se nregistreaz factura cu care au sosit componentele;
.. gestionarul verific componentele; n funcie de calitatea i cantitatea
existent,
.. gestionarul nscrie componentele corespunztoare pe NIR; pentru o
factur se completeaz un NIR/mai multe NIR-uri;
.. NIR-urile se pstreaz n arhiva gestiunilor.
SAU
.. ntocmete proces verbal pentru componentele necorespunztoare
calitativ sau lips cantitativ;
.. furnizeaz informaii pentru stornarea facturilor la compartimentul
aprovizionare.
= scenariul 3
Denumire: Gestionarea cererii de la aprovizionare/vnzare
Descrierea derulrii:
.. gestionarul primete o comand de la departamentul aprovizionare/vnzare;
.. gestionarul verific cantitatea i calitatea cerut;
.. gestionarul calculeaz preul mediu pentru analiza ofertei n cazul
aprovizionrii/preul de vnzare pentru livrare;
.. n cazul vnzrii, descarc gestiunea dup scoaterea din gestiune a mrfii.
= scenariul 4
Denumire: validarea unui client cnd acesta sun pentru o comand
Descrierea derulrii:
. clientul furnizeaz un numr de identificare pe care operatorul l tasteaz n
fereastra de interfa;
. sistemul rspunde cu numele i adresa clientului i o parol de acces;
. operatorul cere confirmarea pentru nume, adres i parol i nchide fereastra
dac rspunsurile date sunt conforme cu datele de pe ecran.
Alternative:
1. clientul nu are un numr de identificare pentru a fi gestionat; operatorul
trebuie s cear clientului s aib un numr de identificare naintea intrrii n
sistem.
2. sistemul nu poate gsi nregistrarea cu numrul de identificare dat al
clientului i se afieaz un mesaj de eroare. Operatorul cere un nou numr de
identificare i reia operaia de validare de la pasul 1.
3. clientul nu poate furniza numele, adresa sau parola; operatorul nchide
aplicaia. Sistemul trebuie s nregistreze ncercarea nereuit pentru a permite
cercetarea fraudei.
Excepii:
. dac sistemul nu e disponibil, operatorul preia numele i numrul de telefon al
clientului i-l sun imediat ce sistemul e disponibil.

= scenariul 5
Denumire: preluarea detaliilor unei comenzi pentru un client
Descrierea derulrii:
. clientul furnizeaz codul produsului i cantitatea; operatorul tasteaz aceste
informaii pe ecran;
. clientul cere o dat anume pentru livrare, operatorul o tasteaz pe ecran.
Sistemul confirm c aceata e acceptabil/acceptat
. operatorul citete comanda i comunicat data livrrii clientului, care accept
. operatorul nchide ecranul de interfa i sistemul rspunde c aceast
comand a fost acceptat. Operatorul mulumete clientului i ntreab dac
exist alt comand
Alternative:
1. clientul nu are un cod al produsului, dar tie numele produsului. Sistemul
poate permite acceptarea numelui i regsete codul.
2. sistemul nu poate accepta data livrrii i ofer o dat apropiat pe care o
negociaz cu clientul.
3. se constat nereguli n detaliile unei comenzi:
. clientul a fcut o greeal n furnizarea datelor i operatorul trebuie s fac
modificri n detalii;
. comanda excede limita de creditare a clientului sau cere un produs neinclus n
ofert; dup discuii cu clientul se fac modificri.
4. se renun la comand din diferite motive.
Observaii:
. n situaia n care preluarea comenzii se face prin telefon, este indicat s se
construiasc o diagram de activiti care s ia n calcul i alternativele
prezentate n scenariu (fig. 4).
. iesirile evideniate n diagram reprezint intrri n alte procese (procesul de
vnzare dup transferul apelului)

fig.4
B2

Analiza de sistem, faz din care ncepem s vorbim de un proces de

elaborare a cazurilor de utilizare.

. exprim comportamentul sistemului i interaciunea cu mediul afacerii n
termeni din domeniul computerelor, ntr-un limbaj al dezvoltatorilor.
. evideniaz interaciunile dintre obiecte pornind de la scenariile descrise
anterior; se definete o prim form a structurii viitorului sistem.
. conduce la construirea unui model obiect, imagine a modului n care sistemul
se prezint utilizatorilor, a tipurilor de informaii memorate i regsite de
sistem.
Schematic, aceast etap poate fi reprezentat ca n figura 5 , unde:
Diagrama cazurilor de utilizare construit n etapa de analiz a cerinelor se
completeaz cu noile cazuri de utilizare rezultate din prezentarea scenariilor, n
special a excepiilor i a alternativelor.
Modelul obiect cuprinde:
.. diagrama claselor, ce evideniaz structura static a sistemului;
.. diagramele de secven, de colaborare i de stare, ce evideniaz dinamica
sistemului.

Analiza de sistem

Diagrama cazurilor
de utilizare

Modelul
obiect

fig.5
Pentru definirea diagramei claselor (numit i modelul domeniului n aceast
etap) inem cont c:
o clas este o abstracie pentru :
.. persoane (clieni, furnizori, studeni )
.. lucruri (catalog de produse, container, factur ..)
.. ideiconcepte abstracte (specificaii ale produselor, zborile aeriene,
conturi bancare)
n diagrama claselor nu se definesc interaciunile dintre clase ci doar cile dea lungul crora acestea se formeaz.
includerea unei clase n diagram se poate face n 2 moduri:
1. clasele se aleg dintre substantivele prezente n textul ce descrie activitatea
desfurat. Problema este c nu toate substantivele sunt nume de
clas(denumirea clientului este un atribut, facturare este descriere a unei de
activiti)
2. se apeleaz la una din urmtoarele categorii de clase utilizate n activitatea
de modelare:
Categorie clas
Tranzacii
Cataloage
Containere
Sisteme externe
Organizaii
Locuri
Rol jucat de persoane
Specificaii/descrieri de obiecte
Obiecte tangibile
Obiecte n containere

Exemplu
Vnzare, Plat
Nomenclator de produse
Container, Avion
Sistem Credit-Card
Departament de vnzri
Depozit, magazin, avion
Student, client, angajat
Descrierea produsului
Registru de vinzari, facturi
Stoc de produse, pasageri

Criterii pentru includerea claselor n diagrama claselor:

1. se definete o clas doar dac sistemul are nevoie s memoreze date despre
ea, pentru a rspunde unor cereri viitoare;
2. se definete o clas corespunztoare unui actor doar dac sistemul are nevoie
s-i aminteasc atributele actorului;
3. se exclud clasele care reprezint ieiri din sistem, dac sistemul poate calcula
informaiile cnd are nevoie de ele n viitor; rspunsurile sistemului la
evenimente (ieirile din sistem) se pot defini ca atribute, atribute calculate,
mesaje.
Criterii pentru includerea atributelor n diagrama claselor
1. se definete un atribut doar dac sistemul are nevoie de valoriile lui pentru a
rspunde unor cereri viitoare;
2. nu se folosesc atribute pentru a nregistra o conexiune ntre clase; se folosesc
asocieri;
3. un atribut se include ntr-o singur clas;
4. nu se includ atribute calculate.
Teme:
Completai diagrama cazurilor de utilizare cu noi cazurile de utilizare.
Adugai cazurilor de utilizare excepiile i alternativele rezultate din
prezentarea scenariilor.
Construii diagrama claselor pentru cazutile de utilizare descrise.
Pentru definirea diagramelor de secven, de colaborare i de stare, noiunea
de obiect este esenial n aceast etap; obiectele sunt prezentate ca aparinnd
unui stereotip, vzut ca cel mai important dintre mecanismele de extensie.
Stereotipul permite ca elemente cu aceeai strucutr s poat primi semnificaie
sau utilizare particular.
Obiectele definite pentru descrierea unui caz de utilizare pot fi:
obiecte de gestiune (entity) stereotip << entity>>
= corespund obiectelor din sistemul real; reflect concepte i elemente ce
aparin domeniului de activitate, afacerii reprezentate; sunt persistente n timp
i sunt translatate n tabele ale bazelor de date relaionale.
Exemple: facturi, mrfiri, clieni.
obiecte de control stereotip << control>>
= organizeaz comportamentul complex al sistemului. Se definesc n situaii
care implic mai multe obiecte de interfa sau obiecte de gestiune.
Exemple: un obiect ce compar coninutul unei facturi de aprovizionare cu
datele din NIR, un obiect care identific diferenele rezultate din comparaia
anterioar, un obiect care trateaz situaii posibile menionate la excepii.

 obiecte de interfa (boundary) stereotip << boundary>>

= controleaz interaciunea cu mediul exterior (outside world). Rolul lor este
s translateze informaiile furnizate de actori n evenimente interne la care
rspund obiecte de control sau obiecte de gestiune i s prezinte rspunsul
acestor obiecte astfel nct s poat fi nelese de actor.
Exemple: fereastr de ecran, formular, caset de text, butoane, liste derulante.
obiecte de implementare (factory)
= grupeaz elemente legate de structura intern a sistemului. Ele preiau
responsabilitatea pentru crearea obiectelor cnd sunt definite pentru prima dat
i pentru transferul lor n/din baza de date pe timpul duratei lor de via. Cel
mai des sunt utilizate ca obiecte legate de persisten, asigurnd comunicarea
ntre obiecte i baza de date.
Exemplu: Pentru a apela un obiect client dintr-o baz de date relaional,
acesta este preluat via un obiect de control ntr-un obiect de implementare.
Atributul cod client este utilizat pentru a regsi n baza de date o nregistrare cu
al crui coninut se populeaz atributele obiectului client. Dup ce obiectul a
fost creat n memorie, alte obiecte l pot referii. Trebuie apoi returnat n baza de
date; obiectul de implementare poate fi chemat s transfere atributele
modificate n baza de date i s distrug obiectul de gestiune.
Exemple:
Prezentm n continuare diagrame de secven construite pentru cteva din
scenariile definite anterior.
n diagrama de secvene pentru scenariul 4 (fig. 6) se include dou obiecte:
un obiect de interfa utilizat pentru interaciunea cu operatorul i un obiect de
gestiune client.
1. prin intermediul obiectului de interfa operatorul tasteaz numrul clientului
i-l trimite sistemului;
2. sistemul rspunde cu numele, adresa i numrul clientului; aceasta implic
definirea unui obiect de gestiune (al clasei client) care s memoreze nume,
adres, numr client.

fig. 6
Clasa Client poate fi reprezentat astfel:

3. dac datele afiate pe ecran corespund cu cele furnizate de client, operatorul

confirm clientul. Faptul c datele unui client trebuie validate impune definirea
unui obiect de control (Validare) care preia sarcinile confirmrii:
<<control>>
Validare
esteValidat()

Diagrama de secvene este cea din figura 7:

fig. 7
In acest moment poate fi construit diagrama claselor din figura 8.

fig. 8

Teme:
.Construii diagrame de colaborare pentru clasele: interfa preluare
comand, clieni, comand, control comand, livrare.
.Completai diagrama claselor din figura 9, cu informaii obinute din
diagramele de colaborare.
. Construii diagrama de stare pentru clasa client.
. Construii diagrama de stare pentru produse livrate.

Proiectarea se ocup de cum va opera sistemul i-l descompune n

componente ce pot fi dezvoltate individual, oferind totodat o vedere de
ansamblu asupra sistemului.
. proiectarea sistemului implic mprirea sa n subsisteme, i alocarea
resurselor hardware i software.
. proiectarea obiectelor continu strategia aleas n etapa de proiectare a
sistemului i rafineaz detaliile.
Schematic, intrrile i ieirile acestei etape pot fi reprezentate astfel:
C

Descrierea cazurilor
de utilizare

Modelul
obiect

Proiectare
Specificaii
pentru
interfa

Modelul
componentelor

Modelul
datelor

Model
obiect

Vedere
arhitectura

Cazurile de utilizare interacioneaz i interfereaz unele cu altele, prin

intermediul unor obiecte de baz (comanda este folosit de cazul de utilizare ce
reflect preluarea comenzii i de de cazul de utilizare ce reflect livrarea unei
comenzi).
Diagrama de secvene
. evideniaz noi interaciuni ntre obiecte (pentru actori sau obiecte ale claselor
noi introduse dup faza de analiz);
. poate evidenia crearea unui nou obiect, distrugerea unui obiect sau apelarea
unui obiect printr-o operaie proprie;
. verific dac obiectele definite n faza de analiz sunt viabile pentru
implementare sau trebuie restructurate; se adaug informaile schimbate;
. interaciunile din diagram (mesajele dintre obiecte) trebuie s se regseasc
printre operaiile clasei obiectului destinatar.
Diagrama de colaborare
.evideniaz funcionalitile rezultate din interaciunile cazurilor de utilizare;
. nlocuiete mesajele specificate n faza de analiz cu operaii adugate
claselor de obiecte destinatar;
Diagrama de activiti

. detaliaz interaciunile dintre cazurile de utilizare;

. descrie algoritmi ai unor operaii complexe.
Teme:
. Evideniai n diagrame cazuri de utilizare care interacioneaz i
interfereaz unele cu altele.
. Construii diagrame de colaborare pentru evidenierea funcionalitilor
rezultate din interaciunile cazurilor de utilizare.
. Construii diagrame de activiti ce detaliaz interaciunile dintre cazurile
de utilizare (editarea unei facturi);
Diagrama claselor evideniaz acum un set de obiecte legate unele de
altele i organizate astfel nct permit implementarea scenariilor ce descriu
cazurile de utilizare; cuprinde detalii necesare implementrii:
. atributelor le sunt adugate gradele de vizibilitate, eventual valori implicite
sau valori iniiale;
. pot exista alte obiecte ca atribute (stare,ClsMatAprov);
. operaiile pot manipula atributele obiectelor din clas, pot apela operaii ale
altor obiecte sau pot manipula atribute ale altor obiecte, dac acestea aparin
interfeei;
. interaciunile dintre obiecte specificate n faza de analiz sunt reprezentate
acum prin operaii; se specific semntura operaiilor i nu ce face operaia;
. se fac precizri suplimentare privind asocierile dintre obiecte; ele sunt
implementate prin atribute memorate ntr-una ori n ambele clase care se
asociaz, sau prin evidentierea legturile dintre tabele n cazul bazelor de date
relaionale .
Pornind de la aceste consideraii, prezentm n final (fig.9) o diagram a
claselor construit pentru activitatea de contractare i aprovizionare a
componentelor necesare asamblrii prouselor comandate de clieni.

fig.9

Teme:
. Construii diagrama claselor pentru activitile ce vizeaz preluarea
comenzilor i livrarea produselor.
. Construii diagrame ale claselor pentru procesele descrise n etapa de
analiz.
BIBLIOGRAFIE
Booch G., Rumbaugh J., Jacobson I. The Unified Language user Guide,
Addison-Wesley, 1999
Roper M. Software Testing, McGraw-Hill, 1994

Sommerville I. Software Engineering. Ed. Addison Wesley, 2001

K. Lunn. Software development with UML, Ed. Palgrave Macmillan, 2003.
Popa Gh, Udrica M. Baze de date ACCESS - culegere de probleme Ed. Cison,
Bucureti 2006
Udric M. Modelare orientat obiect, Ed. Cison, 2000
Zaharie D. Rosca I. Proiectare obiectuala a sistemelor informatice. Ed. Dual
Tech, Bucuresti, 2006
www.en.wikipedia.org
www.ece.cmu.edu/~koopman/des_s99/sw_testing/
www.rational.com
www.tessella.com/literature/Supplements/swdesign_UML.htm