Uml

Analiza i proiectarea orientat obiect
a sistemelor informatice cu UML
1 Modelare i UML

yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
n acest capitol:
Despre modelare, principii de modelare, limbaje de modelare
Metodologii de realizare a sistemelor informatice
UML standard industrial de modelare obiect
Tipuri de diagrame UML
Studiul de caz e-commerce enun, exigene i restricii
Despre modelare, principii de modelare, limbaje

de modelare
De cele mai multe ori, n viaa de zi cu zi, avem de-a face cu modele. Astfel,
atunci cnd vorbim despre avioane sau automobile, avem n minte anumite
caracteristici sau aspecte ale acestor obiecte, de pild viteza sau forma lor
aerodinamic. Aceasta nseamn c am redus ntregul obiect, n cazul de fa
destul de complicat, la un model simplu, care se deplaseaz repede i are o
form alungit cu muchii rotunjite, pentru a susine o teorie sau a demonstra
ceva. Celelalte caracteristici, ca de exemplu consumul de carburani, preul sau
costul ntreinerii, au fost neglijate cu bun tiin pentru c nu erau relevante
pentru teoria noastr. La fel, atunci cnd ne referim la cunotine, prieteni sau,
dimpotriv dumani, neglijm, de cele mai multe ori, aspectul lor fizic i ne
referim la modelul lor psihologic sau comportamental verificat n relaiile cu
propria noastr persoan.
n general, spunem c nu putem trece la a realiza ceva, fr a avea n minte, la
nceput vag dar mai apoi din ce n ce mai detaliat, un model al obiectului pe
care dorim s-l construim.
Dac ne referim la sistemele informatice, acestea reprezint ele nsele modele
informaionale ale activitilor noastre n cele mai diverse domenii producie,
servicii, comer, politic, administraie. Proiectul unui sistem informatic

reprezint planul de realizare al unui asemenea sistem i pleac, evident, tot de
la un model, care reduce sistemul final la elementele lui eseniale permind
abordarea sa sistematic i controlul pe parcursul execuiei. Aceasta permite
coordonarea echipelor de realizare a proiectului prin verificarea stadiului la care
s-a ajuns fa de ceea ce era planificat, precum i elaborarea documentaiei de
proiectare.
Modelul este, prin urmare, o reprezentare abstract a unui sistem, care

permite planificarea, studiul, analiza, concepia i verificarea performanelor
sistemului nainte de realizarea sa propriu zis, precum i crearea
documentaiei de proiectare, facilitnd totodat comunicarea ntre echipele
de proiectare.
Modelul se dovedete deosebit de util n trei faze diferite ale proiectrii: n
specificarea cerinelor noului sistem, n activitatea de analiz a sistemului
proiectat, precum i n activitatea de formulare a soluiei informatice pentru
sistemul proiectat i realizare a acestuia.
9 Modelul contextului (n specificarea cerinelor)
Sistemul proiectat este considerat ca subsistem (cutie neagr), care

funcioneaz n cadrul unui sistem mai larg (de exemplu, ntreprinderea
sau segmentul de pia al acesteia). Se dezvolt un model de nivel
context care precizeaz limitele funcionale ale sistemului proiectat.
9 Modelul sistemului proiectat (n activitatea de analiz)
Modelul reprezint sistemul proiectat, vzut din interior. Acesta se
compune din obiecte care reprezint o abstractizare a conceptelor
manipulate de utilizator precum i relaiile dintre acestea. Se au n
vedere: structura static i comportamentul dinamic al sistemului.
9 Modelul soluiei informatice (n activitatea de realizare)
Modelul corespunde mijloacelor de realizare efectiv a sistemului
proiectat i evideniaz conceptele informatice utilizate ca instrumente,
limbaje sau platforme de dezvoltare. Modelul servete la studierea i
anticiparea unei soluii.
Observaie. Este de preferat s se descopere o eventual eroare de concepie pe un

model, dect n faza de exploatare sau de testare a sistemului deja realizat.
Lucrrile de specialitate menioneaz urmtoarele patru principii ale modelrii 1:

1
[BRJ] Booch Grady, Rumbaugh James, Jacobson Ivar Le guide de lutilizateur UML,
Edition Eyrolles, 2000, pp.8-10 (trad.l.engl. The Unified Modeling Language User Guide,
Addison-Wesley, 1998).
Primul principiu: Alegerea modelelor influeneaz esenial maniera de abordare

a problemelor i soluionarea lor. Cu alte cuvinte, dac este ales bine un model
poate aduce clarificri nesperate alegerii celei mai bune soluii, n timp ce o
alegere greit a modelului poate abate atenia dezvoltatorilor de la unele
probleme fundamentale. Practica arat c orientarea obiect conduce la cele mai
bune rezultate pentru construirea unor sisteme informatice care se sprijin pe
arhitecturi flexibile, chiar dac majoritatea activitilor const n calcule sau
lucrul cu baze de date.
Al doilea principiu: Modelele pot avea diferite niveluri de precizie. Cele mai bune
modele sunt acelea care las la latitudinea proiectantului alegerea nivelului de
detaliu pn la care s se coboare n realizarea diferitelor subsisteme, n funcie
de ceea ce se urmrete i care sunt resursele disponibile.
Al treilea principiu: Cele mai bune modele sunt bazate pe simul realitii. Orice
modelare simplific realitatea, dar nu trebuie s piard din vedere nici un detaliu
important. Cu ajutorul tehnicilor orientate obiect se pot reuni ntr-un tot
semantic diferitele puncte de vedere asupra unui proiect.

Al patrulea principiu: Deoarece nici un model nu este suficient prin sine nsui,
este preferabil s descompunem un sistem mare ntr-un ansamblu de mici
modele, aproape independente, care s poat fi studiate i testate separat.
Pstrnd un grad redus de interdependen, se micoreaz considerabil riscul

adoptrii unui singur model. Micile modele fac deosebit de oportun atribuirea
lor unor echipe de proiectare diferite, care s gndeasc i s realizeze liber
subsistemele de care rspund, efului de proiect fiindu-i mult mai la ndemn
coordonarea acestora.
De ce un limbaj de modelare?
Pentru a realiza un sistem, trebuie mai nti s-l modelm. Pentru a analiza un
sistem, trebuie, de asemenea, s-l modelm. Modelarea are nevoie de un
limbaj, n primul rnd ca mijloc de comunicare, pentru ca toi factorii implicai,
constructori i utilizatori, s neleag acelai lucru 2.
De ce un limbaj orientat obiect?
Iat cteva din motivaiile acestei alegeri:

1. Scopul fiecrui manager de proiect este de a putea mbunti costurile
i nltura incertitudinile programului n timp ce caut s satisfac
cerinele clientului. Unul din cei mai mari dumani ai supleei i
adaptabilitii este automatizarea exagerat. Programele foarte
complicate sunt adesea rigide, greu de modificat i n foarte scurt timp i
pierd eficiena n faa evoluiei sistemelor obiect.
2
[Fowler&Scott] Martin Fowler et Kendall Scott Le tout en poche - UML, 2002,

Campus Press, p.15 (trad.l.engl. UML Distilled, Second Edition, Addison-Wesley Longman,
Inc., 2000).
2. Pe de alt parte, atunci cnd pornim la construcia unui sistem avem

rareori ocazia s-i cunoatem toate detaliile. Multe din caracteristici
urmeaz s le descoperim pe parcurs. Interaciunea cu utilizatorul este
necunoscut. Comportamentul n timp nu poate fi dect bnuit. Factori
importani externi i chiar interni, crora suntem obligai s le facem
fa, urmeaz s apar dup nceperea proiectului. Managerul proiectului
are nevoie de instrumente pentru a stpni cerinele care pot apare,
pentru a le rafina i perfeciona pe toat durata ciclului de via a
proiectului. Proiectarea orientat-obiect dispune de asemenea
instrumente.
3. Dezvoltarea orientat obiect include i aa-numitele cazuri de utilizare
o metod de precizare i stpnire a cerinelor dinamice ale sistemului
pe care o vom descrie n detaliu n cadrul acestei lucrri. Cazurile de
utilizare cuprind un format pentru specificarea cerinelor dinamice, care
descriu n detaliu cum va reaciona sistemul ca rspuns la interaciunea
utilizatorului. Acestea formeaz o punte de legtur ntre punctul de
vedere al clientului i cel al proiectantului, ajutnd la nelegerea n
acelai fel a fenomenelor cu care va fi confruntat sistemul.
Metodologii de realizare a sistemelor informatice
Metodologia de realizare clasic a sistemelor

informatice
Realizarea clasic a sistemelor informatice, sub forma cderii de ap n
cascad (waterfall) 3, a fost conceput nc din anul 1970 i consta n 4 mari
faze care se executau succesiv i integral: analiza, proiectarea, construcia i
testarea. Aceast metodologie primitiv era destul de rigid i nu permitea
ntoarcerea la o faz precedent pn cnd nu era terminat faza curent.
ntoarcerea se fcea cu pierderi materiale mari care puneau sub semnul
ntrebrii realizarea integral a proiectului. n general, nu exista o certitudine n
construirea adevratului sistem pn la terminarea fazei de testare.
3
Vezi [LuChi-kw] Introduction to object-oriented systems development, B329 Unit 1,

pag.4-22, External Course Assessor, Dr.Lucas Chi-kwong Hui, University of Hong Kong,
2003
Metoda SDLC (Systems Development Life Cycle)

Au fost realizate i metode de management pentru planificarea, execuia i
controlul punerii n practic a unei asemenea metodologii clasice, cum ar fi
SDLC (Systems Development Life Cycle). Acesta consta n spargerea proceselor
complexe n faze i activiti. Principalele instrumente utilizate erau diagramele
de relaii ntre entiti (relation diagrams) i diagramele de fluxuri de date
(flowcharts).
Cu toat strdania de a crea instrumente care s faciliteze realizarea practic a
sistemelor informatice, SDLC pstra ns principalele inconveniente ale
metodologiei clasice, menionate mai sus.

Metoda SDLC iterativ
O ameliorare a acestei metode, SDLC iterativ, a aprut mai trziu, dup anul
1980 i consta n realizarea unui nucleu al sistemului n jurul cruia acesta se
dezvolt pas cu pas i se completeaz pe msura necesitilor aprute. Nu
insistm asupra acestei soluii care nu constituie n sine o inovaie.
Proiectarea orientat obiect

Spre deosebire de SDLC, proiectarea orientat obiect, descris ca un proces
unificat (Unified Process), se bazeaz pe o abordare obiect nc de la nceputul
analizei.
Un obiect poate fi abstractizarea unei entiti specifice utilizate n analiz sau
componenta unei soluii de program n faza de realizare. Corespondena ntre
acestea este mai evident dac limbajul utilizat este el nsui orientat obiect
(exemplu, C++ sau Java).
Proiectarea orientat obiect ncepe cu definirea actorilor umani i a funciilor

sistem ca obiecte care interacioneaz pentru a produce un anume rezultat
distinct i important pentru proiect (artifact). Aa se construiesc cazurile de
utilizare. Apoi, cazurile de utilizare se detaliaz n clase de obiecte de acelai
fel, care conin date caracteristice i modurile lor de utilizare. n sfrit,
comportamentul sistemului este descris prin diagrame de secven i de
colaborare ntre aceste clase, care se finalizeaz prin realizarea tuturor
funciilor sistemului proiectat.
Caracteristicile abordrii obiect

Obiectele sunt componente de program care efectueaz sarcini relativ limitate,
ca de exemplu actualizarea unei liste sau trasarea unei linii. Tehnologia de

proiectare i dezvoltare a obiectelor are unele trsturi care pot ajuta la
nlturarea dificultilor de proiectare i ntreinere ale marilor sisteme software
i anume 4:
1. Descrierea static i dinamic a cerinelor. Cuprinde mijloace de
prevedere, nu numai cu privire la ceea ce va face programul dar i cum
se presupune c va face acest lucru.
2. Descrierea i proiectarea static i dinamic. Prevede ci de specificare,
nu numai a modului n care a fost alctuit programul dar, de
asemenea, i cum interacionez obiectele ntre ele.
3. Modularitatea. Sistemele sunt adesea prea complicate pentru a putea fi
abordate n detaliu; ele sunt descrise, de regul, prin blocuri funcionale
mai mici, legate ntre ele printr-o ierarhie. Noi utilizm aceast ierarhie
ca pe un prim instrument de conducere, meninnd, ntr-o oarecare
msur independena blocurilor funcionale.
4. ncapsularea. Ascunde felul intern n care lucreaz obiectele fa de
restul sistemului, permite divizarea strilor i definirea funciilor proprii
fiecrui obiect. Se realizeaz astfel un management explicit al accesului
la variabilele sistemului, acesta nefiind permis dect prin intermediul
anumitor programe.
Observaie. Clasele de obiecte utilizeaz att modularitatea ct i ncapsularea. Privit
din exterior, nu se vede cum lucreaz un obiect; el poate fi tratat ca o cutie neagr
care rspunde la anumite ntrebri. Acest mod de lucru faciliteaz nelegerea i
permite dezvoltatorului s-i concentreze atenia asupra modului de utilizare a
obiectelor.
5. Motenirea. Permite mai multor tipuri de obiecte s reutilizeze proprieti

i s defineasc noi funcionaliti.
6. Agregarea. Creeaz un obiect mare din agregarea unor obiecte mici,
simple, permind manipularea strilor complexe.
7. Pachetele. ncapsuleaz obiecte n componente mai mari cu
comportamente ascunse, permind abstractizri (ascunderea detaliilor)
astfel nct programele complexe s poat fi conduse la diferite niveluri
de detaliere.
7
4
Vezi [Gutu1] S.Guu, UML Limbaj de modelare unificat destinat managementului

sistemelor complexe, n Sisteme informatice de management, Coordonatori
L.Dumitracu i M.G.Petrescu, Editura Universitii din Ploieti, 2004, pp.37-68.

Principiile de baz ale abordrii obiect sunt: ncapsularea, motenirea i

polimorfismul.
9 ncapsularea Abordarea obiect a unui sistem ncepe cu definirea

obiectelor aparinnd domeniului studiat. n cadrul unei categorii de
obiecte de acelai fel (clas) se definesc, alturi de tipurile de date
(atribute), toate aciunile de care obiectele aparinnd aceleiai clase
sunt responsabile (operaii). O clas include toate tipurile de date i
operaiile sale. Acesta este principiul ncapsulrii datelor i metodelor.
De exemplu, pentru a proteja unele caracteristici importante ale unui
obiect codul de acces al unui card, parola etc aceste atribute se
declar interne, ele neputnd fi accesate dect prin intermediul unor
metode ale clasei respective (necunoaterea acestor metode nu permite
accesul). n acest fel, datele i metodele lor de acces formeaz un tot
unitar de care ntraga clas este responsabil.
9 Motenirea Cel de al doilea principiu de baz este motenirea, cu
alte cuvinte transmiterea proprietilor unei clase (numit, n acest caz,
superclas), ctre o aa zis clas derivat, care pe lng caracteristicile
motenite poate avea i alte proprieti. n cadrul unei clase care
servete la cutarea lucrrilor pe Internet, de exemplu, se pot defini
unele principii generale, cum ar fi modul de avansare pe browser,
accesul la paginile Web, avansarea nainte/napoi etc. n cadrul unor
clase derivate care ar menine aceste principii de baz s-ar putea crea n
plus ns diferite criterii de selecie: dup numele autorului, cuvinte cheie
ale lucrrii, anul publicrii, editura etc care ar mri supleea i rapiditatea
selectrii lucrrilor.
9 Polimorfismul n sfrit, cel de al treilea principiu de baz al abordrii
obiect este polimorfismul, adic pstrarea aceleiai denumiri pentru
operaii asemntoare dar cu funciuni diferite, identificarea fcndu-se
dup formatul de apel (forma i numrul parametrilor) dar i dup clasa
creia i aparine. Aceasta permite simplificarea nelegerii logicii
procedurilor i aciunilor, respectiv a programelor care le pun n aplicare.
De exemplu, crearea unui obiect (instan) al unei clase se poate face, n
general, n mai multe feluri: a) o generare standard, n care este
suficient numele metodei, fr vreun parametru; b) o generare mai
precis, n care s se indice numele instanei create, eventual termenul
de valabilitate etc. n acest caz, dei metoda de generare poart acelai
nume, formatul de apel va fi diferit, el neavnd parametri n cazul a), sau
indicnd o serie de parametri n cazul b).
Un alt caz: S presupunem c dispunem de o clas de baz care
genereaz un punct de coordonate (x, y) ce va fi centru de simetrie i
poziionare pentru o serie de figuri geometrice plane (cerc, ptrat)
generate, la rndul lor, n clase derivate corespunztoare. Utilizarea
aceluiai nume pentru metoda de generare, s spunem genereaza, nu va

crea confuzii, deoarece apelul din interiorul clasei Cerc va crea un cerc
iar apelul din interiorul clasei Patrat va crea un ptrat. n acest fel se
simplific modelul, utilizatorul tiind c pentru a genera ceva trebuie s
tasteze generare, pentru a terge trebuie s formeze stergere etc,
rezultatul fiind diferit n funcie de clasa din care apeleaz metoda.
Observaie. Marele avantaj al abordrii obiect este acela c, dac se alege ca
mediu de programare tot un limbaj orientat obiect (de exemplu C++ sau Java),
obiectele se pstraz i evolueaz n aceeai structur i interrelaionare, de la
analiz pn la realizare.
UML standard industrial de modelare obiect

Necesitatea i obiectivele UML
Astzi, standardul industrial de modelare obiect este UML (Unified Modeling
Language), dezvoltat sub directa responsabilitate a OMG (Object Management
Group) un grup industrial interesat n unificarea metodologiei de proiectare i
standardizarea tehnologiilor obiect, pentru a putea garanta interoperabilitatea
sistemelor importante. OMG cuprinde actualmente peste 800 membri, printre
care Sun, IBM, Microsoft etc., dar i mari ntreprinderi utilizatoare din toate
sectoarele de activitate.
n figura 1.1 este schematizat istoricul naterii i dezvoltrii UML. Prinii acestui
limbaj sunt considerai a fi Grady Booch, James Rumbaugh i Ivar Jacobson
datorit unor prime lucrri n acest domeniu Object Management Technology
(OMT) i Object Oriented System Engineering (OOSE) - nc din anul 1994. n
anul 1995 se consemneaz o prim tentativ de unificare a conceptelor
ncercat de Booch i Rumbaugh, la care se altur i Jacobson n anul 1996.
Lucrarea comun este naintat OMG n ianuarie 1997 cnd apare i prima
versiune UML 1.0. adoptat la sfritul acestui an, dup anumite completri, sub
numele UML 1.1. Eforturi susinute de standardizare din parte a OMG duc la
apariia unor versiuni din ce n ce mai complete, aplicabile n industrie: 1.3 n
anul 1999 i UML 1.4 n septembrie 2001 5. Astzi se aplic pe scar larg
A se vedea [RRRT] Rational Rose RealTime for Windows, pachet de programe

comercializat de IBM, http:/www. downseek.com/download/19186.asp
versiunea 2.0 i, de curnd, i-au fcut apariia versiunile 3.0, 3.1 i 3.2 n
cadrul unor pachete de programe promovate de firmele specializate n grafic
pe calculator 6.
Figura 1.1
Istoricul UML
2004
UML 3.0
2003
UML 2.0
09/2001: vers.1.4
UML 1.4
06/1999: vers.1.3
UML 1.1
01/1997: naintarea
la OMG

Standardizare
OMG
UML 1.3
11/1997: adoptarea de ctre

OMG 09/1997: vers.1.1
Industrializare
UML 1.0
Partenerii UML
10/1996:
UML 0.91
06/1996:
UML 0.9
10/1995:
Metoda unificat 0.8
10/1994:
Booch93+OMT-2
G.Booch
Booch-91
J.Rumbaugh
OMT-1
Unificarea
Metodelor
I.Jacobson
OOSE
10
6
A se vedea [VP3.2UG] Visual Paradigm for UML 3.2 Users Guide Copyright 1999-2004
by Visual Paradigm, http:/www.apache.org Apache Software Foundation.
Conform UML, un concept derivat din cerinele utilizatorului n conformitate cu

cazurile lui de utilizare este proiectat mai departe n realizarea modelului i n
programare. Invers, plecnd de la program, putem descoperi crei necesiti i
corespunde acesta i, n consecin, care este ideea care a stat la baza
proiectului (reverse engineering).
Versiunile UML 7
Din anul 1997 pn n prezent, UML a cunoscut numeroase modificri, acestea
fiind concretizate n versiuni mai mult sau mai puin cunoscute publicului. Este
de notat faptul c principiile UML au rmas, n general, neschimbate, versiunile
UML opernd n special n domeniul formalismelor utilizate (notaii, simboluri,
convenii).
De la UML 1.0 la UML 1.1

ntre versiunile UML 1.0, aprut n ianuarie 1997 i UML 1.1 propus n luna
septembrie a aceluiai an, nu s-au semnalat deosebiri importante. Rolul de
ngheare (frozen) al asocierilor de tip compunere a fost desfiinat. El se
aplic, de la caz la caz, anumitor asocieri ale claselor i atributelor lor. Returul n
diagramele de secven a fost stabilit s se reprezinte cu linie ntrerupt.
De la UML 1.2 (i 1.1) la UML 1.3

UML 1.2 a aprut n anul 1998 iar UML 1.3 n anul 1999. Pentru aceast
versiune s-au semnalat unele modificri importante.
Z Cazurile de utilizare
Dac versiunea UML 1.1 recunotea dou tipuri de relaii ntre cazurile de
utilizare, use i extends, ambele sub form de stereotipuri, versiunea UML 1.3
nlocuiete use prin include, introduce generalizarea i definete extensia ca pe
un stereotip de dependen form mai controlat dect relaia de
generalizare.
Z Diagramele de activiti
11
7
[Fowler2] Martin Fowler - UML 2.0 CampusPress, 2004, pp.181-189 (trad.l.engl. UML
Distilled Third Edition, Addison Wesley, 2003).
Pentru a nota o condiie, se poate utiliza un romb pentru a nota att o

ramificaie ct i o fuziune (condiia se menioneaz n parantez).
Bara de sincronizare poate fi sau o ramificaie sau o jonciune. Nu se pot
aduga condiii arbitrare jonciunilor. Oricrei ramificaii trebuie s-i corespund
o jonciune care s reuneasc threads create prin acea ramificaie. Se pot
imbrica ramificaiile i jonciunile i se pot elimina din diagram ramificaii i
jonciuni atunci cnd threads pleac direct de la o ramificaie la alta sau de la o
jonciune la alta.
Jonciunile nu sunt activate dect atunci cnd toate threads care intr sunt
terminate. Dar putei avea o condiie asupra unui thread care pleac dintr-o
ramificaie. Dac aceast condiie este fals, se consider c thread este
terminat pentru nevoile jonciunii.
S-a considerat c urmtoarele versiuni ale UML ar putea modifica total
diagramele de activiti (vezi UML 2.0).

12
Cea mai important schimbare adus de UML 1.4 const n adugarea

profilurilor, ceea ce permite colectarea unui grup de extensii ntr-un ansamblu
coerent. Documentaia UML conine dou exemple de profiluri. Totodat,
formalismul definirii de stereotipuri a crescut i elementele modelului au putut
avea mai multe stereotipuri, n timp ce n UML 1.3 exista unul singur.
A fost adugat artefact-ul manifestare fizic a unei componente, s-a lucrat
asupra vizibilitii pachetelor Java n metamodele i asupra marcrii
asincronismelor prin sgei n diagramele de secven.

Principala modificare a fost adugarea unei semantici de aciune, etap
necesar pentru a face din UML un limbaj de programare.
Principalele caracteristici ale UML 2.0
Una din schimbrile cele mai evidente privete tipurile de diagrame. Diagramele
de obiecte i diagramele de pachete devin diagrame oficiale. Diagramele de
colaborare devin diagrame de comunicare. UML 2.0 introduce, de asemenea, noi
tipuri de diagrame: vedere de ansamblu a interaciunilor, timing i structuri
compozite.
Z Referitor la diagramele de clase: concepte eseniale

Atributele i asocierile unidirecionale devin dou notaii esenial diferite pentru
a reprezenta conceptul sub-adiacent de proprietate.
Multiplicitile discontinui (exemplu [2,4]) au fost abandonate. Nu mai exist

proprietatea frozen. S-au adugat noi cuvinte cheie pentru dependene.
Cuvintele cheie <<parameter>> i <<local>> nu se mai utilizeaz.
Z Diagramele de secven
Modificarea cea mai important este notaia cadrelor de interaciune, care
permite gestionarea structurilor iterative, condiionale i a altor structuri de
control ale comportamentului. Putei exprima aproape n ntregime algoritmii n
diagramele de secven. Vechile marcaje de iteraii i notaiile lor au fost
abandonate. Antetele de linii de via nu mai sunt instane, acestea fiind definite
prin termenul participant. Diagramele de colaborare se numesc acum diagrame
de comunicare.
Z Referitor la diagramele de clase: concepte avansate

Stereotipurile sunt definite de o manier mai strict. n consecin, exist
cuvinte cheie pentru a defini expresiile ntre ghilimele, numai unele dintre
acestea din urm fiind stereotipuri. n diagramele de obiecte, instanele sunt
acum specificaii de instane. Clasele pot solicita interfee i le pot realiza.
Clasificarea multipl utilizeaz ansambluri de generalizare pentru a regrupa
generalizrile. Componentele nu mai sunt reprezentate printr-un simbol special.
Obiectele active au linii duble verticale n loc de linii groase.
Z Diagramele de maini de stare

Dac UML 1 fcea distincia ntre aciuni (momentane) i activiti (continue),
UML 2 numete cele dou activiti i utilizeaz acest termen n toate cazurile.
Z Diagramele de activiti
UML 1 trata diagramele de activiti ca pe un caz particular al diagramelor de

stare. UML 2 a rupt legtura ntre acestea i a suprimat regulile de
coresponden a ramificaiilor i jonciunilor pe care le instaurase UML 1.
Au aprut noi notaii, printre care acelea de semnale temporale i de acceptare,
parmetri, specificaii de jonciune, conectori, transformatori de fluxuri, greble de
sub-diagrame, regiuni de expansiune i terminaii de fluxuri.
UML 1 considera mai multe fluxuri de intrare ntr-o activitate ca pe o fuziune
implicit, n timp ce UML 2 le trateaz ca pe o jonciune implicit. Pentru a evita
confuziile, recomandm utilizarea fuziunilor i jonciunilor explicite n diagramele
de activiti.
13
Tipuri de diagrame
UML este un limbaj esenialmente grafic, ce se definete n jurul mai multor
categorii de diagrame, fiecare dintre acestea fiind dedicat reprezentrii unor
concepte particulare ale unui sistem informatic: prima categorie descrie
serviciile funcionale, a doua privete structura static a sistemului iar cea
de-a treia se refer la dinamica funcionrii sistemului.
Diagramele funcionale

Diagramele funcionale se bazeaz exclusiv pe cazurile de utilizare pentru

specificarea cerinelor sistemului. Paradigma de reprezentare este ilustrat n
figura 1.2 i are urmtoarea semnificaie: Actorul particip la Cazul de utilizare
reprezentat n diagram. Att actorii ct i cazurile de utilizare trebuie s poarte
denumiri unice, ntre cazurile de utilizare existnd i anumite relaii de care ne
vom ocupa ulterior. Cazurile de utilizare arat ce anume trebuie proiectat, fr a
da vreo indicaie cum s se fac acest lucru.
14
Figura 1.2
Diagrama UML. Cazuri de utilizare
Actor
Caz de utilizare
Capitolul 2 se ocup de specificarea cerinelor conform cazurilor de utilizare

i construirea diagramelor cazuri de utilizare.
"______________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
Diagramele statice (sau structurale)

Diagramele statice, numite i diagrame structurale, arat legturile ntre
diferitele elemente de structur ale modelului i se refer la:
9 diagramele de clase;
9 diagramele de obiecte;
9 diagramele de pachete;
9 diagramele de structuri compozite;
9 diagramele de componen;
9 diagramele de desfurare.
Diagramele de clase
Diagramele de clase, a cror paradigm de reprezentare este ilustrat n figura
1.3, constituie punctul central al dezvoltrii obiect. n figura menionat, clasa B
caracterizat prin atributele atribut2 i atribut3 i operaiile operaie2 i
operaie3 este asociat clasei A caracterizat prin atribut1 i operaie1
printr-o relaie de agregare. Cu alte cuvinte, un numr neprecizat de instane
ale clasei B (notat cu 0..*) intr n compunerea unei instane aparinnd clasei
A. Pe de alt parte, clasa A este legat printr-o relaie de generalizare
/particularizare de sub-clasa A1 care i motenete proprietile (atribut1 i
operaie1) avnd n plus operaie4.
9 Pentru analiz, diagrama de clase este util deoarece descrie structura
entitilor manipulate de utilizator.
9 n realizarea modelului, cu o diagram de clase se reprezint de obicei
structura programelor orientate obiect sau, mai precis, modulele

limbajului de dezvoltare.
"______________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
15
Figura 1.3
Diagrama de clase UML
Clasa B
Clasa A
atribut1
operaie1()
0..*
atribut2
atribut3
operaie2()
operaie3()
Sub-clasa A1
operaie4()

16
Pe parcursul acestei lucrri, clasele au fost abordate de la simplu la complex.

Astfel, capitolul 3 se ocup cu construirea claselor conceptuale i a
relaiilor dintre aceste clase.
Capitolul 6 se ocup de clasele rezultate din analiz i arat cum se
construiete diagrama acestor clase (DCP Diagrama Claselor
Participante la analiz).
n sfrit, capitolul 9 se ocup de proiectarea specificaiilor de interfa
software i arat cum se construiesc diagramele claselor detaliate.
Diagramele de obiecte
O diagram de obiecte este o fotografie a obiectelor unui sistem la un moment
dat. Ele reprezint instane ale claselor (nu clase), de aceea se mai numesc i
diagrame de instane.
Un exemplu al acestui tip de diagram este prezentat n figura 1.4.
"______________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
Figura 1.4
Diagrama de obiecte UML
centru : ntreprindere
copil
localitate = Bucureti
printe
copil
filiala1 : ntreprindere
filiala2: ntreprindere
localitate = Braov
localitate = Constana
printe
copil
copil
Georgescu : Angajat
Ionescu: Angajat
localitate = Braov
localitate = Braov
Diagrama reprezint o ierarhie a unor obiecte aparinnd unor clase. Numele

clasei (obligatoriu) este menionat dup semnul : (obligatoriu). Numele
obiectului (opional) este menionat naintea semnului :. Din diagram se
observ c:
1. Filialele sunt tot ntreprinderi, prin urmare motenesc proprietile acestei
clase, singura diferen fiind localitatea n care funcioneaz;
2. Angajaii ntreprinderii motenesc i ei proprietile ntreprinderii care i
remunereaz, indiferent de localitate. Angajaii posed caracteristici
proprii care nu sunt evideniate n diagram.
Elementele unei diagrame de obiecte sunt specificaii de instane ale claselor i
se utilizeaz n cazurile complexe, acolo unde diagramele de clas sunt greu de
neles i pot da natere la interpretri diferite.
Obiectele intervin n cadrul: diagramelor de secven (vezi capitolul 5 i

capitolul 7), diagramelor de colaborare (vezi capitolul 7), diagramelor de
stare (vezi capitolul 8) i diagramelor de activiti (vezi capitolul 8).
17
Diagramele de pachete
Clasele reprezint structura de baz a unui sistem orientat obiect. Totui, atunci
cnd avem de-a face cu sisteme mari, cu sute de clase, acestea devin dificil de
neles i necesit gruparea elementelor UML n pachete.
Orice construcie UML (cazuri de utilizare, clase, obiecte) poate fi grupat n
uniti de nivel mai nalt sub form de pachete.
ntr-un model UML, fiecare clas aparine unui singur pachet i poart un nume
distinct n cadrul pachetului.
Pachetele pot fi, n acelai timp, membre ale altor pachete, ceea ce conduce la o
structur ierarhizat de pachete i clase.
Un pachet poate conine, totodat, sub-pachete i clase independente.
n UML, numele pachetului este urmat de semnul :: care l desparte de
numele sub-pachetului sau de numele clasei componente.
n exemplul din figura 1_5 este reprezentat pachetul java din care face parte
sub-pachetul util care conine, la rndul su, clasa Date.
Figura 1.5
Diagrama de pachete UML
java

util
18
Date
Ceea ce este reprezentat n figura 1.5 va putea fi notat java::util::Date sau Date
(de java::util) 8.
Diagramele de pachete sunt tratate n capitolul 2 i capitolul 9.
"______________________________________________________________
_________________________________________________________________
Aceast notaie a fost introdus de firma Rational Rose i nu face parte din standardul
UML.
Diagramele de structuri compozite

Una din noile caracteristici ale UML 2.0 const n posibilitatea de a descompune
ierarhic o clas ntr-o structur intern. Aceasta permite subdivizarea unui
obiect complex n diferitele sale pri componente.
n figura 1.6, de exemplu, este reprezentat clasa Telecomand mpreun cu
interfeele sale.
Figura 1.6
Diagrama de structuri composite UML (dup Jim Rumbaugh)
a). reprezentarea global
b). reprezentarea compozit
Telecomand
<<interfee realizate>>
comanda TV om-main
comanda TV aplicaii
<<interfee cerute>>
reglaj
afiare
flux de imagini
a).
comanda TV om-main
Telecomand
:Controlor
afiare
:Generator
Comanda
TV
aplicaii
reglaj
flux de imagini
b).
Din figura 1.6 a)., nu rezult dect c aceast clas are dou feluri de interfee:
realizate i cerute, precum i denumirea acestora.
Din figura 1.6 b)., aflm c aceast clas se descompune, de fapt, n dou pri:
controlor i generator iar interfeele sunt cuplate astfel:
9 comanda TV om-main la partea numit controlor, iar
9 comanda TV aplicaii, mpreun cu afiarea, reglajul i fluxul de imagini,
la partea numit generator.
Observaii privind notaiile:
1. Pentru a arta c o parte implementeaz o interfa, am desenat un conector sub
form de cerc i o sgeat cu linie ntrerupt care sosete n partea respectiv.
19
2. Pentru a arta c o parte necesit o interfa, am desenat un cuplor sub form de

semicerc i o sgeat cu linie ntrerupt care pleac din partea respectiv.
Structurile compozite sunt noi n UML 2.0 i, datorit acestei nouti, este
prematur s se prevad pn la ce punct se vor dovedi ele eficace n practic.
Diagramele de componen
Diagramele de componen, a cror paradigm de reprezentare este dat n
figura 1.7, constituie concepte de configurare a programelor n pachete de
programe, n fiiere surs sau n biblioteci. Aceste concepte arat cum se leag
ntre ele fiierele surs, pachetele de programe i bibliotecile, n cadrul
sistemului informatic proiectat. Astfel, n figura menionat sunt reprezentate
pachetul de programe de tip <<Applet>>, care cuprinde toate programele de
interfa om-main (IOM) i care comunic cu pachetul de programe de tip
<<Baza de date>> numit Clieni. Cele dou pachete de programe pot fi
amplasate pe maini diferite sau n biblioteci diferite n cadrul sistemului
informatic.

Figura 1.7
Diagrama de componen UML
20
<<Applet>>
IOM
<<Baza de date>>
Clieni
Diagramele de componen sunt utilizate n cadrul capitolului 11.
Diagramele de desfurare
Diagramele de desfurare, a cror paradigm de reprezentare este ilustrat n
figura 1.8, corespund structurii de reea informatic ce preia sistemul de
programe i modul n care sunt instalate componentele de reea. Astfel, din
figura 1.8 rezult c sistemul local este constituit din serverul central, la care
sunt legate un server de nlnuire i un server Web.
Figura 1.8
Diagrama de desfurare UML
Server de
nlnuire
Server
central
Server
Web
Diagramele de desfurare sunt utilizate n cadrul capitolului 11.
Diagramele dinamice (sau comportamentale)

Diagramele dinamice, numite i diagrame comportamentale, arat cum
interacioneaz ntre ele diferitele elemente ale modelului. Diagramele dinamice
sunt alctuite din:
9 diagramele de activiti;
9 diagramele de stare;
9 diagramele de secven;
9 diagramele de colaborare;
9 diagramele de vedere de ansamblu a interaciunilor;
9 diagramele de timing.
Diagramele de activiti
Diagramele de activiti, a cror paradigm de reprezentare este ilustrat n
figura 1.9, reprezint regulile de nlnuire ale activitilor n cadrul sistemului
(de exemplu, navigarea ntr-un site Web). Activitile sunt reprezentate prin
dreptunghiuri ovalizate iar trecerea de la o activitate la alta prin sgei, care se
ntlnesc n noduri de stare marcate prin linii verticale. Ansamblul activitilor
are un punct de intrare i un punct de ieire, marcate ca n figur.
21
Figura 1.9
Diagrama de activiti UML
Activ.2
Activ.1
Activ.3
Diagramele de activiti sunt tratate n cadrul capitolelor 8 i 12.

Diagramele de stare
22
Diagramele de stare, a cror paradigm de reprezentare este ilustrat n figura

1.10, reprezint ciclul de via comun obiectelor unei aceleiai clase i permit
completarea cunotinelor claselor, att n cadrul analizei ct i n cazul
concepiei. Convenia de reprezentare este invers ca la diagramele de activiti,
cu alte cuvinte strile sunt marcate prin dreptunghiuri cu coluri rotunjite iar
drumul de la o stare la alta prin sgei reprezentnd aciuni specifice. Ca i la
diagramele de activiti, exist mai multe ci prin care se poate ajunge de la o
stare la alta. Alegerea unei ci sau a alteia depinde de condiiile n care se afl
sistemul la momentul respectiv. n diagramele din figurile 1.9 i 1.10 nu sunt
menionate condiiile de alegere a cilor prin care se poate ajunge de la o stare
la alta.
Figura 1.10
Diagrama de stare UML
Stare1
Stare2
Stare3
Diagramele de stare sunt tratate n cadrul capitolelor 8 i 12.
Diagramele de secven
Diagramele de secven, a cror paradigm de reprezentare este ilustrat n
figura 1.11, servesc, n primul rnd, dezvoltrii de scenarii n cadrul analizei
utilizrii sistemului. n diagramele de secven mesajele sunt reprezentate
orizontal, pe o ax a timpului de sus n jos, de attea ori de cte ori apar.
Figura 1.11
Diagrama de secven UML
:Clasa A
:Clasa B
:Actor
m1
m2
Diagramele de secven sunt tratate n capitolele 5 i 7, fiind apoi

reluate n cadrul capitolului 12.
Diagramele de colaborare 9
Diagramele de colaborare, a cror paradigm de reprezentare este ilustrat n
figura 1.12, servesc aceluiai scop ca i diagramele de secven. n diagramele
de colaborare exist o singur cale, care unete dou elemente (clase, actori),
mesajele care circul pe aceast cale mpreun cu sensul lor fiind marcate pe
marginea cii cu sgei. De obicei, diagramele de colaborare se construiesc pe
baza diagramelor de secven i ilustreaz schimburile de mesaje ntre obiecte
9
Am menionat c UML 2.0 numete acest tip de element diagram de comunicare. Noi
vom continua s pstrm, n cadrul acestei lucrri, termenul de diagram de colaborare,
care ni se pare mai sugestiv, pentru a pstra corespondena cu unele lucrri mai vechi n
domeniul limbajului UML.
23
n cazul anumitor funcionri particulare ale sistemului. Att diagramele de

secven ct i diagramele de colaborare fac parte din subclasa diagramelor de
interaciune UML.
Figura 1.12
Diagrama de colaborare UML
1:m1
:Clasa A
2:m2
4:
:Actor
3:
:Clasa B
Diagramele de colaborare sunt tratate n capitolul 7, fiind apoi

reluate n cadrul capitolul 12.

Diagramele de vedere de ansamblu a interaciunilor
24
Diagramele de vedere de ansamblu a interaciunilor (ineraction overview

diagrams) sunt o combinaie ntre diagramele de activiti i diagramele de
secven.
Ele se pot considera fie diagrame de activiti n care activitile sunt nlocuite
prin mici diagrame de secven, fie diagrame de secven divizate, notaiile
avnd menirea s uureze citirea acestor diagrame.
n figura 1.13 este prezentat un exemplu simplu al acestui tip de diagrame.
Se dorete producerea i formatarea unei liste recapitulative a comenzilor. Dac
clientul este extern, obinem informaii ntr-un formular XML. Dac clientul este
intern, l obinem dintr-o baz de date. Cele dou diagrame de secven ne
arat cele dou posibiliti. Odat obinute datele, putem emite lista
recapitulativ a comenzilor.
Acesta este un nou tip de diagram UML 2.0 i este nc prematur de a emite o
idee referitoare la modul n care va fi el utilizat n practic.
"______________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
Figura 1.13
Diagrama de vedere de ansamblu a interaciunilor
[date externe]
:Client
:AnalizorXml
ncarc
getNume analizeaz
[date interne]
:Client
:BazDeDate
selecioneaz
dup clieni
i comenzi
new
getCom
new
:ComReper
toriuCzi
new
:Repertoriu
Comenzi
List Repertoriu Comenzi
Diagramele de timing
Diagramele de timing reprezint o alt form de diagrame de interaciune, n
care accentul este pus pe constrngerile de timp, fie pentru un obiect, fie pentru
un grup de obiecte.
S lum, pentru exemplificare, scenariul de funcionare al unei cafetiere
electrice. Aceasta se compune, n principal, din dou automate: cel al pompei de
evacuare al preparatului de cafea i cel al plcii nclzitoare. S presupunem c
ntre activarea pompei i cea a plcii nclzitoare trebuie s treac un interval de
minimum 10 secunde. Atunci cnd rezervorul se golete, pompa se oprete, ns
placa poate continua s funcioneze nc 15 minute 10.
10
Vezi [Fowler2] UML 2.0 CampusPress, 2004, pp.181-189 (trad.l.engl. UML Distilled
Third Edition, Addison Wesley, 2003), pp.171-172
25
Figura 1.14
Diagrama de timing
Pompa
Placa
nclzitoare
n funciune
Oprit
Rezervor golit
timp
n funciune
Oprit
{<15 min}
{>10 s}

n figura 1.14 este reprezentat diagrama de timing pentru acest caz.

Funcionarea celor dou pri principale, pompa i placa nclzitoare, este
reprezentat pe aceeai diagram a timpului. Modificrile de stare sunt
semnalate prin schimbri de nivel ale liniilor continue care urmresc procesul.
Liniile ntrerupte verticale sunt opionale i ajut la precizarea momentului n
care are loc evenimentul.
Diagramele de timing reprezint, de asemenea, o inovaie adus de UML 2.0.
Ele sunt utile pentru reprezentarea restriciilor temporale ntre schimbrile de
stare ale diferitelor obiecte.
26
Clasificarea diagramelor UML

n ncheiere, v prezentm n figura 1.15 o schem de clasificare a diagramelor
UML 2.0 care utilizeaz simbolul de generalizare/ particularizare promovat de
acest standard 11. Spre deosebire de aceast clasificare, care plaseaz
diagramele cazuri de utilizare n clasa diagramelor comportamentale, noi am
preferat s ridicm acest tip de diagrame la un nivel superior, deoarece prezint
att caracteristici de grupare structural ct i proprieti comportamentale.
Printre caracteristicile structurale amintim:
9 un caz de utilizare concentreaz n jurul su tot ce este semnificativ
dintr-o aplicaie i care produce un rezultat semnificativ pentru un anumit
actor, adic obiecte, clase i proprietile acestora care prin interaciune
conduc la rezultatul vizat.
11
Vezi [Fowler2] UML 2.0 CampusPress, 2004, pp.181-189 (trad.l.engl. UML Distilled
Third Edition, Addison Wesley, 2003), p.22
9 gruparea claselor i obiectelor implicate ntr-un caz de utilizare seamn

foarte mult cu aceea de pachet de nivel superior, dar semnificaia sa este
diferit, fiind legat esenial de comportament i scopul final al acestuia.
Caracteristicile comportamentale rmn totui acelea eseniale i rezult din
faptul c la baza separrii elementelor proiectului st comportamentul care
conduce la realizarea artefact-ului pentru actorul n cauz.
Figura 1.15
Diagrama UML. Cazuri de utilizare
Diagrama
de clase
Diagrame
de
structur
Diagrama
de
structuri
compozite
Diagrama
de obiecte
Diagrame
Diagrama
de cazuri
de utilizare
Diagrame
comportamentale
Diagrama
de
activiti
Diagrama
de stare
Diagrame
de interaciune
Diagrama
de
componen
Diagrama
de
desfurare
Diagrama
de pachete
Diagrama
de secven
Diagrama
de
colaborare
Diagrama
vedere de
ansamblu a
interaciunilor
Diagrama
de timing
27
Studiul de caz e-commerce enun, exigene

i restricii
Comerul electronic (e-commerce) se refer, n general, la utilizarea
tehnologiilor informaiei i comunicaiilor (TIC) n:
9 Cercetarea pieei;
9 ncheierea contractelor sau a diferitelor tranzacii de afaceri;
9 Achiziionarea de materiale, distribuirea produselor i derularea

vnzrilor, inclusiv prin intermediul magazinelor electronice.
28
Dac primele dou domenii sunt strns legate de relaia client-furnizor i

asigurarea confidenialitii schimbului de informaii de afaceri 12, cel de-al treilea
domeniu menionat mai sus pune accentul pe integrarea pe suport informatic a
tuturor proceselor care asigur profitabilitatea ntreprinderii. Acestea se refer
att la activitile interne ct i la legturile informaionale cu mediul
(e-business).
Magazinul electronic reproduce ntr-un spaiu virtual funciunile magazinului
clasic, cu urmtoarele avantaje: spaiu mult mai redus pentru depozitarea
mrfurilor, dispariia costurilor pentru locaie, personal spacializat n vnzri,
energie .a., reclam aproape gratuit, internaionalizarea clientelei, dar i
dezavantajul unei clientele mult mai fluctuante n funcie de noutatea i
competitivitatea produselor oferite.
n cele ce urmeaz ne vom referi la o asemenea aplicaie de gestionare a unui
magazin electronic, care ofer spre vnzare cri.
12
n 1998 OECD (Organizaia pentru Cooperare i Dezvoltare Economic) a definit

comerul electronic ca pe o sum de afaceri derulate pe reele care utilizeaz protocoale
non-proprietar stabilite pe baza unor standarde deschise, ca de exemplu Internet. Numai
c, folosirea Internetului n tranzaciile comerciale ridic serioase probleme de
confidenialitate. Acestea sunt n mare parte rezolvate astzi prin folosirea semnturii
electronice codificare electronic a documentului i semnatarului al crui secret este
asigurat printr-un sistem de chei electronice i printr-o ierarhie de instituii de garantare a
utilizrii acestora.
Scop
Se urmrete construirea unei librrii on-line pe un site Web i, cu acest prilej,
trecerea n revist a tuturor instrumentelor metodologice de proiectare orientate
obiect.
Enunul studiului de caz

Societatea comercial Librria X a decis s intre n rndul marilor librrii online, deja funcionale pe site-uri Web precum www.amazon.fr, www.fnac.com,
www.eyrolles.com .a.
Obiectivul fundamental al viitorului site www.librariaX.com este de a permite
navigatorilor pe Web de a cuta lucrri pe teme, autori, cuvinte-cheie etc., de ai constitui un co virtual propriu i apoi de a-l putea comanda i plti direct pe
Web.
Puncte de vedere asupra proiectului

Poziie
Scopul proiectului este de a ocupa o poziie n faa concurenilor generaliti,
introducnd rapid elemente de noutate. n acest scop, site-ul va trebui s fie
evolutiv i performant.
Exigene funcionale
Site-ul www.librariaX.com va trebui s regrupeze toate funcionalitile necesare
cutrii, descoperirii detaliate de lucrri, seleciei acestora i lansrii de comenzi
on-line.
Z Cutarea
Prima etap, pentru persoana care navigheaz, const n a gsi, ct mai rapid
posibil, lucrarea pe care o caut, n catalog. Referinele lucrrii fiind mai mult
sau mai puin precise, este preferabil s se furnizeze mai multe criterii de
cutare. Persoana care navigheaz trebuie s poat alege un criteriu: titlu,
29
autor, ISBN etc, sau mai multe criterii simultan (vezi exemplul de formular de
interfa om-main IOM pentru cutare rapid din figura 1.16). Ar fi de dorit ca
rezultatele cutrii s fie disponibile pe o pagin i s poat fi uor parcurse i
reclasate.
Dac persoana n cauz nu are o idee precis despre ceea ce caut, trebuie s i
se ofere un mijloc de a se plimba - aa cum ar face-o dac s-ar afla ntr-o
adevrat librrie i a avea acces la o clasificare tematic, la nouti, la o list
cu cele mai bune vnzri etc (vezi, de exemplu, ecranul IOM de cutare
general din figura 1.17. Acesta este de fapt o fereastr care se afl n
permanen n partea superioar a paginilor de cutare).

Figura 1.16
Formularul de interfa om-main IOM pentru cutarea rapid
30
Figura 1.17
Ecranul IOM de cutare general
...............
Informatic ntreprinderi management tiin tehnic practic
Introducere Cercetare avansat Teme Nouti Subiectul lunii Cele mai bune vnzri
Cutare rapid
Tema
Z Descoperirea
Fiecare carte vndut n cadrul site-ului trebuie s fie prezentat n detaliu,
punndu-se n eviden urmtoarele elemente:
9 imagine (pentru majoritatea lucrrilor) care s poat fi, eventual, mrit;
9 preul i disponibilitatea;
9 comentarii ale clienilor;
9 tabl de materii detaliat, extrase etc. (a se vedea, de exemplu, schia
IOM a paginii de prezentare a fiei detaliate a lucrrii din figura 1.18).
ntr-un veritabil magazin, clientul i alege articolele, unele dup altele, le

depune n coul su, apoi merge la cass pentru a plti. Site-ul Web ncearc s
reproduc aceast obinuin de cumprare. Astfel, navigatorul i poate
nregistra cumprturile ntr-un co virtual (vezi exemplul de co virtual) avnd
apoi posibilitatea de a aduga, a terge sau a modifica cifra care exprim
cantitatea, nainte de a plti.
"______________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
31

Figura 1.18
Fia detaliat a lucrrii
32
Z Comanda
n orice moment, clientul poate accesa formularul bonului de comand, n care
i trece coordonatele i informaiile necesare pentru plat i livrare (vezi
exemplul de bon de comand). Pentru a garanta securitatea i
confidenialitatea, se impune ca trimiterea datelor s fie criptat. n cazul n
care se dorete, sistemul trebuie s fie capabil s emit un deviz, care s poat
fi imprimat de client pentru a comanda prin fax sau curier.
Clientul trebuie s-i poat apoi urmri comenzile, s le poat modifica nainte
de a fi expediate, ntr-o manier securizat.
Exigene nefuncionale
Exigenele nefuncionale se refer la calitate i la performan.
Z Exigene de calitate
S cumperi o carte pe Web nu trebuie s-i ia mult timp i nici s ai cunotine
speciale. n acest scop, trebuie:
9 s existe o prezentare clar i intuitiv;
9 formularul de comand s fie simplu;
9 help-ul on-line s fie puternic. Clientul trebuie s poat consulta help-ul
contextual n orice moment i s navigheze pe paginile de help. Ar fi de

dorit ca noilor vizitatori s li se propun o vizit ghidat.
Z Exigene de performan
9
9
9
9
Librria X trebuie s poat gestiona conturi de peste 10.000 de clieni.

Site-ul Web trebuie s suporte peste 1.000 conexiuni simultan.
Catalogul trebuie s poat cuprinde peste 1.000.000 de titluri.
Cutarea nici unei cri nu trebuie s consume mai mult de 30 secunde.
Restricii de concepie
Z Actualizarea datelor de referin
Informaiile referitoare la lucrrile prezentate pe site provin, de regul, din dou
surse complementare:
9 prima servete la alimentarea bazei de date cu toate lucrrile noi;
9 cea de-a doua servete la actualizarea datelor referitoare la pre i starea
stocului de cri din catalog.
Sursele menionate vor fi ncrcate automat, periodic, n baza de date.

Orice alte informaii vor fi culese manual, cu ajutorul unei mici aplicaii intranet
dedicate mbogirii datelor referitoare la lucrri.
Z Actualizarea din formularele site-ului

Datele culese din site-ul Web i nregistrate n baza de date descriu
coordonatele clienilor i caracteristicile comenzilor acestora.
33
Coordonatele clienilor sunt memorate. n prima faz, ele permit trimiterea

pachetului corespunztor comenzii. n faza a doua, acestea economisesc o nou
colectare a datelor cu prilejul unei noi comenzi.
Toate datele personale sunt protejate iar confidenialitatea lor este garantat.
Comenzile sunt nregistrate, apoi tratate ulterior de serviciul clieni. Clienii pot
consulta istoricul tuturor comenzilor lor.
Z Coul
Coul navigatorului nu va fi salvat n baza de date. Durata sa de via nu va
depi pe aceea a vizitei utilizatorului.
Z Plata securizat

Culegerea numrului cartelei de credit a clientului trebuie s se efectueze

securizat, criptnd transferul HTTP prin intermediul protocolului SSL. Comanda
i numrul cartelei de credit sunt stocate n baza de date pn la prelucrarea
comenzii. Banca n cauz va valida tranzacia dup care, numrul cartelei de
credit va fi suprimat din baza de date.
34
Specificarea cerinelor
conform cazurilor de
utilizare
yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy yy
n acest capitol:
Cazurile de utilizare
Diagramele cazuri de utilizare i elementele lor
Studiul de caz e-commerce identificarea elementelor diagramelor cazuri
de utilizare
Primul pas n dezvoltarea unui proiect de sistem informatic este nelegerea
clar a problemei. n acest scop, orice analiz ncepe cu construirea cazurilor de
utilizare, care descriu modul n care va fi utilizat sistemul. Pentru a facilita
aceste descrieri, dezvoltatorii UML au inclus diagramele caz de utilizare n
specificaia limbajului.
Fiecare caz de utilizare trebuie s aib un nume, un numr i o descriere.
Un caz de utilizare trebuie s respecte o anumit form de descriere.
a. Acest caz ncepe atunci cnd ....
b. Sistemul rspunde prin ... (secven de interaciuni) ...
c. Acest caz se termin atunci cnd ...
Exemplu:
Iat cum descriem cazul de utilizare: Trasarea unei linii ntr-un program de
desenare.
a. Acest caz ncepe atunci cnd utilizatorul clickeaz pe icon-ul linie n
bara de menu.
35
b. Sistemul rspunde prin schimbarea cursorului cu o cruciuli. Atunci

cnd utilizatorul execut click pe desen i trage cursorul, sistemul
traseaz o linie.
c. Acest caz se termin atunci cnd utilizatorul ridic degetul de pe
butonul stng al mouse-ului. Linia rmne iar cruciulia dispare.
Un caz de utilizare reprezint un ansamblu de secvene de aciuni realizate de
sistem, care produc un rezultat observabil, interesant pentru un anume actor.
Diagramele cazuri de utilizare i elementele lor

Diagramele cazuri de utilizare sunt folosite pentru a stabili cerinele dinamice

ale sistemului. Acest tip de diagrame poate fi ntlnit la dou niveluri:
9 nivelul utilizatorului n care diagramele descriu cum interacioneaz
utilizatorii cu sistemul, definind astfel cerinele sistemului;
9 nivelul dezvoltatorului n care diagramele descriu cum interacioneaz
componentele sistemului, definind astfel cerinele subsistemelor.
36
Fia diagramei cazuri de utilizare este prezentat n figura 2.1. Elementele

acesteia actorii, cazurile i relaiile dintre ele - vor fi detaliate n cele ce
urmeaz (figura 2.2).
Figura 2.1
Fia diagramei UML cazuri de utilizare
Fia diagramei Cazuri de utilizare
UML
Rol
Diagrama caz de utilizare produce o prim viziune asupra
Elemente
Cnd se
utilizeaz
structurii sistemului, un punct de plecare al proiectrii, o

identificare a obiectelor i a diagramelor de secven.
Actor extern, actor intern, actor subsistem, cazuri de
utilizare, relaiile ntre cazurile de utilizare.
La nceputul proiectrii, pentru definirea modului n care
sistemul corespunde cerinelor utilizatorului. Diagramele
caz de utilizare arat modul n care cazurile de utilizare se
relaioneaz n cadrul sistemului.
Actorii
Un actor este un rol pe care utilizatorul l joac n raport cu sistemul. Actorii
realizeaz cazurile de utilizare. Un singur actor poate realiza mai multe cazuri i,
invers, un caz poate avea mai muli actori.
Tipurile de actori sunt prezentate n detaliu n figura 2.2. Exemplele se refer la
studiul de caz e-commerce i la aplicaiile propuse spre rezolvare (vezi TEMA).
Figura 2.2
Tipurile de actori
Element diagram
UML
Reprezentare
Actor extern
Reprezint utilizatorul sau un sistem

interacioneaz cu sistemul n cauz.
extern
care
Exemple:
Navigator Cutarea lucrrilor
Navigator Gestiunea coului
Navigator Efectuarea comenzii
Magazioner
ntreinerea fiierelor de magazie
37
Stabilirea programului
eful seciei producie de fabricaie
Maistru
Distribuirea sarcinilor pe muncitori
Responsabil serviciu
aprovizionare
Clientul
Selectarea listei de
furnizori
Efectuarea comenzii
Actor intern

Reprezint funcii ale personalului angajat
38
Exemple:
Efectuarea comenzii
Serviciul clieni
ntreinerea catalogului
Librar
ntreinerea site-ului
Webmaster
Distribuirea
sarcinilor pe
muncitori
Gestionarea
magaziei de piese
i subansambluri
Gestionarea
magaziei de
materiale
Actor subsistem
Denumire subsistem
Reprezint subsistemele automate de prelucrare a datelor
privite, pentru moment, ca entiti globale.
Exemple:
Gestiunea stocurilor
Librar
ntreinerea
catalogului
Nouti
Magazioner ntreinerea
fielor de
magazie
Magazioner
Client
Lansarea comenzilor
de fabricaie
Gestionarea
fiei de magazie
Efectuarea
comenzii
Elaborarea comenzii
de aprovizionat
39
Mai multe despre actori

Un actor reprezint un rol jucat de o entitate (utilizator uman, dispozitiv material

sau alt sistem) extern cazului de utilizare studiat, care interacioneaz direct cu
acesta din urm. Un actor poate consulta sau modifica direct starea sistemului,
emind sau primind mesaje purttoare de informaii.
Actor este acela care beneficiaz de utilizarea sistemului. Este de dorit s se
elimine, pe ct posibil, actorii fizici n favoarea celor logici. Aceasta ne
permite s depim tehnologiile de interfa care risc s evolueze i s
identificm actorii logici, susceptibili de a fi reutilizai. De exemplu, chiar dac
aceeai persoan fizic poate juca succesiv rolurile de librar i Webmaster fa
de site-ul Web, este vorba de doi actori diferii, dou profiluri distincte (vezi
studiul de caz e-commerce).
40
Remarci:
9 n cadrul capitolului 12 al acestei lucrri se arat un mod simplu de a genera un
actor folosind pachetul de programe VP-UML (vezi figura 12.8).
9 Acelai mod simplu de a crea un actor avem la dispoziie i atunci cnd lucrm cu
pachetul de programe RRRT (vezi capitolul 11, paragraful 11.3 Adugarea unui
caz de utilizare). n figura 11.8, care arat vederea de ansamblu a diagramei
cazurilor de utilizare intitulat Use Case View /Main, n bara de instrumente a
acesteia, situat pe latura stng a diagramei, se vede imaginea aceluiai
instrument Actor (standard UML). Executarea unui click pe aceast imagine,
urmat de mutarea mouse-ului n interiorul diagramei i efectuarea unui nou click
genereaz un actor al crui nume poate fi imediat redefinit.
Cazurile de utilizare sunt prezentate n detaliu n figura 2.3. Exemplele se refer
la studiul de caz e-commerce i la aplicaiile propuse spre rezolvare (vezi TEMA).
Figura 2.3
Element
diagram UML
Reprezentare
Caz de utilizare
Cazul A
Un ansamblu de secvene de aciuni.

Cazurile de utilizare indic ce anume trebuie proiectat.
Exemple:
Gestionarea coului
Cutarea lucrrilor
Efectuarea comenzii
ntreinerea informaiilor
editoriale
Consultarea unei
comenzi n curs
ntreinerea
sistemului
Lansarea documentelor
de fabricaie
Mai multe despre cazurile de utilizare

Fiecare caz de utilizare trebuie s aib un obiectiv n sine i s poat fi realizat
independent de altele.
Un caz de utilizare modeleaz un serviciu adus de sistem. El exprim
interaciunile actorisistem i aduce o valoare adugat notabil respectivului
actor.
O eroare frecvent este aceea de a dori s se mearg prea n detaliu. Un caz de
utilizare reprezint secvene de aciuni realizate de sistem, care reprezint n
mod precis un obiectiv specific al actorului. Cazul de utilizare nu trebuie deci s
se reduc la o singur secven i nici la o singur aciune.
Remarci:
9 n cadrul capitolului 12 al acestei lucrri se arat un mod simplu de a genera un
caz de utilizare folosind pachetul de programe VP-UML (vezi paragraful 12.3
punctul 3 i figura 12.9).
41
9 Aceeai posibilitate de a crea un caz de utilizare exist i n cadrul pachetului de

programe RRRT (vezi capitolul 11, paragraful 11.3 Adugarea unui caz de utilizare
i diagrama din figura 11.9).
Relaii ntre cazurile de utilizare

Pentru a detalia diagrama cazurilor de utilizare, UML definete trei tipuri de
relaii standard ntre cazurile de utilizare:
9 Relaia de incluziune.
9 Relaia de extensie.
9 Relaia de generalizare /specializare.
Relaiile ntre cazurile de utilizare sunt prezentate n detaliu n figura 2.4.
Figura 2.4
Relaii ntre cazurile de utilizare
Element
diagram UML

Incluziune
42
Reprezentare
A <<include>> B
Relaia de incluziune se folosete atunci cnd o secven de

comportament este identic n mai multe cazuri de utilizare.
Relaia de incluziune este formalizat prin cuvntul cheie
<<include>>, n care cazul de utilizare de baz ncorporeaz
explicit un altul, ntr-o manier obligatorie. Sgeata de la captul
liniei ntrerupte arat ce include iar cazul de utilizare aflat la captul
fr sgeat marcheaz cine include.
Includerea se refer la ntreaga procedur B nglobat n A i
executat obligatoriu odat cu A.
Exemplu:
<<include>>
Analiza de risc
Agent
comercial
Extensie
<<include>> Expertiza
Tarifare tranzacie
C
C <<extinde>> D
Relaia de extensie se folosete atunci cnd o secven de

comportament poate continua secvena de baz.
Relaia de extensie este formalizat prin cuvntul cheie
<<extinde>>, n care cazul de utilizare de baz ncorporeaz
implicit un altul, de manier opional. Sgeata de la captul liniei
ntrerupte arat cine se extinde iar cazul de utilizare aflat la captul
fr sgeat marcheaz cu ce se extinde.
Extinderea arat c n cazul D se poate trece, eventual, i la execuia
procedurii C (neobligatoriu).
Exemple:
43

Generalizare
/specializare
44
Relaia de generalizare se folosete atunci cnd una sau mai multe

cazuri de utilizare descendente, derivate, motenesc datele i
comportamentul unui caz de utilizare de baz, generalizant.
Relaia de generalizare este formulat prin cuvntul cheie
<<generalizeaz>>.
Fiecare din cazurile derivate pot cuprinde comportamente specifice,
care se adaug comportamentului motenit de la cazul generalizant.
Generalizarea este opus specializrii. (Cazurile E i F reprezint
specializri ale cazului G).
Exemple:
Remarc. Cazul de utilizare Gestiune clieni este un generalizant i

cuprinde atribute comune precum numele clienilor sau adresa
acestora, ca i metode specifice de generare i actualizare pentru
atribute. Gestiune clieni poteniali i Gestiune clieni vechi
reprezint specializri care cuprind n plus date precum forma de
plat (card, cont bancar), creditul autorizat, termenul de valabilitate
al acestuia, banca pltitoare etc, sau calificativ de bonitate pentru
vechii clieni, n scopul simplificrii procedurii de cumprare. De
asemenea, cazurile de utilizare specializate cuprind i metodele de
generare i actualizare ale atributelor specifice menionate.
Mai multe despre relaii, n general

Asocierea este cea mai general relaie ntre elementele UML (clase, cazuri de
utilizare, actori etc) care descrie un ansamblu de legturi.
Am vzut c actorul este legat de un caz de utilizare printr-o linie care arat c
el este asociat acestui caz. Cazurile de utilizare sunt legate ntre ele prin asocieri
specifice (incluziuni, extensii, generalizri) care au o simbolistic special i
poart anumite semnificaii.
Remarci:
9 n cadrul capitolului 12 al acestei lucrri se arat un mod simplu de a crea o
asociere ntre un caz de utilizare i un actor, folosind pachetul de programe VPUML (vezi paragraful 12.3 punctul 4 i figura 12.9).
9 Acelai mod simplu de a crea o asociere ntre un caz de utilizare i un actor exist
i n cadrul pachetului de programe RRRT (vezi capitolul 11, paragraful 11.3
intitulat Adugarea unui caz de utilizare i diagrama din figura 11.9.) Se execut
click pe sgeata ndoit Unidirectional Association din bara de instrumente a
diagramei i se trage de la actor ctre cazul de utilizare respectiv.
9 Extinderea sau generalizarea se execut, la ambele pachete de programe
menionate mai sus, prin selectarea instrumentului respectiv din bara de
45
instrumente a diagramei i tragerea de la cazul de utilizare extins sau generalizant

ctre cellalt caz.
Studiul de caz e-commerce identificarea

elementelor diagramelor cazuri de utilizare
n cele ce urmeaz vom identifica elementele i vom construi diagramele cazuri
de utilizare pentru studiul nostru de caz e-commerce.

Identificarea actorilor
46
Pentrul site-ul www.librariaX.com avem urmtorii actori umani:

9 navigatorul: persoana care viziteaz site-ul;
9 Web-master-ul: rolul angajailor care au n sarcin buna funcionare i
ntreinerea site-ului Web;
9 serviciul clieni: rolul angajailor care se ocup cu urmrirea comenzilorclient;
9 librarul: rolul angajailor responsabili de coninutul redacional al siteului.
De asemenea, avem n vedere:
9 sistemul informatic Nouti conectat la site-ul Web, care alimenteaz
baza de date cu toate noile lucrri;
9 Gestiunea stocurilor, care servete la actualizarea datelor privind preul
i stocul de cri din catalog.
Aceste dou surse sunt ncrcate n baza de date n mod automat i periodic.
Ansamblul actorilor este reprezentat n figura 2.5.
Figura 2.5
Actorii site-ului www.librariaX.com
Actor
extern
Actori
interni
Actori
subsisteme
Identificarea cazurilor de utilizare

Pentru fiecare actor identificat anterior, s cercetm deci diferitele intenii
specifice n care utilizeaz sistemul.
Navigatorul
Exprimarea exigenelor funcionale a pus n eviden principalele cazuri de
utilizare ale navigatorului: cutarea lucrrilor, gestionarea coului i efectuarea
comenzii. S reprezentm acest lucru printr-o diagram de cazuri de utilizare
(vezi figura 2.6).
Figura 2.6
Cazuri de utilizare pentru navigator
Observaii:
9 n relaiile reprezentate n figura 2.6, o legtur nseamn: Actorul x
particip la cazul de utilizare y.
47
9 Un navigator poate vizita site-ul cu unicul scop de a cuta lucrri, fr

intenia de a le cumpra. El poate s gestioneze un co virtual numai
pentru a face o simulare sau pentru a obine un deviz. Toate aceste
obiective sunt independente i suficiente pentru a defini cazuri de
utilizare diferite.
9 Utilizarea sgeii n asocierea cu Serviciul Clieni semnaleaz un sens unic
de transmitere a informaiei.
9 Relaiile de extindere din figura 2.6 vor fi comentate ulterior.
Angajaii ntreprinderii
Angajaii ntreprinderii Librria X, librarul i webmaster-ul, au urmtoarele
sarcini:
9 s ntrein catalogul, ceea ce face s intervin cele dou sisteme:
Nouti i Gestiunea stocurilor;
9 s ntrein informaiile editoriale;
9 s ntrein site-ul.
Aceste cazuri de utilizare sunt reprezentate n figura 2.7.

Remarc. Aceeai diagram a fost realizat cu ajutorul pachetului de programe Visual

Paradigm for Unified Modeling Language, n cadrul capitolului 12.
48
Figura 2.7
Cazuri de utilizare pentru angajai
Observaii:
9 Actorii ne-umani nu fac dect s trimit mesaje sistemului, fr s
primeasc vreunul (Remarcai sensul sgeilor de navigabilitate ctre
cazurile de utilizare).
9 Relaia de extindere din figura 2.7 va fi comentat n paragraful urmtor.
Relaiile dintre cazurile de utilizare

Cele trei cazuri principale ale navigatorului sunt legate n mod natural prin relaii
de extensie (vezi figura 2.6): cutarea se poate finaliza cu punerea unei lucrri
n co iar gestiunea coului poate da natere la o comand.
La fel, ntreinerea catalogului poate conduce, n anumite cazuri, la necesitatea
ntreinerii informaiilor editoriale (vezi figura 2.7).
Diferitele posibiliti de cutare a lucrrilor pot fi modelate cu precizie printr-o
relaie de generalizare/specializare, aa cum se arat n figura 2.8.
Figura 2.8
Relaii de generalizare/specializare ale cazului de utilizare Cutarea lucrrilor
Observaii:
9 Cutarea lucrrilor este (figura 2.8) un caz virtual (nu se realizeaz dect
prin specializrile sale).
9 Cazurile de utilizare ale angajailor nu pun n eviden nici o relaie ntre
ele.
49
Pe lng cele de mai sus, mai exist urmtoarele cazuri de utilizare ale
navigatorului:
9 consultarea comenzilor n curs;
9 consultarea help-ului on-line.
Consultarea comenzilor n curs apare n momentul n care navigatorul dorete s
intre pe site-ul www.librariaX.com pentru a trece n revist propriile comenzi i,

eventual, a face unele completri. Evident, n acest caz el trebuie s se identifice
cu un nume utilizator (user name) i parola (password) date de sistem, fr a
mai fi obligat s furnizeze toate datele sale personale. Accesul este limitat numai
la comenzile proprii.
Help-ul on-line apare n toate aplicaiile Web i este disponibil utilizatorului n
orice faz a derulrii acestora, cu alte cuvinte pentru toate celelalte cazuri de
utilizare descrise mai sus.
n figura 2.9 este reprezentat diagrama complet a cazurilor de utilizare ale
navigatorului i relaiile dintre acestea.
Aceast diagram a fost propus, ca aplicaie practic, pentru a fi realizat cu
pachetul de programe RRRT, n cadrul capitolului 11.

Remarc. Aceeai diagram a fost realizat cu ajutorul pachetului de programe Visual

Paradigm for Unified Modeling Language, n cadrul capitolului 12.
50
Figura 2.9
Completarea cazurilor de utilizare pentru navigator
Observaii:
9 Consultarea help-ului on-line nu trebuie neglijat, dar nu este un caz de
utilizare major.
9 Consultarea help-ului on-line poate extinde toate celelalte cazuri de
utilizare. n orice moment, fie la cutarea lucrrilor, fie la gestiunea
coului etc, navigatorul poate s ntrerup activitatea pentru a consulta
help-ul on-line i apoi s continue activitatea ntrerupt.
Pachetarea cazurilor de utilizare

S ncercm s simplificm vederea de ansamblu asupra cazurilor de utilizare
analizate, utiliznd n acest scop un alt tip de diagram UML i anume aceea n
care are loc o grupare (pachetare) a cazurilor pe anumite criterii. Din cele de
mai sus rezult c am putea grupa cazurile de utilizare ale navigatorului,
cazurile de utilizare ale angajailor i cazul de utilizare secundar de consultare a
help-ului on-line n pachete separate (vezi figura 2.10). Aa cum se vede n
figur, actorii att cei externi ct i cei interni sunt grupai la rndul lor ntrun singur pachet denumit Actori. ntre acetia i pachete sunt figurate linii
ntrerupte care poart numele de linii de dependen (n acest caz,
unidirecionale).
Figura 2.10
Completarea cazurilor de utilizare pentru navigator
51
Clasamentul cazurilor de utilizare i planificarea

proiectului
Putem ierarhiza realizarea cazurilor de utilizare, innd cont de:
9 prioritatea funcional determinat de serviciul Marketing al
ntreprinderii;
9 riscul tehnic estimat de eful de proiect.
Pentru exemplificare, s evalum cazurile de utilizare prezentate n studiul de
caz e-commerce de mai sus, innd cont de aceste criterii. Vom obine, n final,
clasamentul prezentat n figura 2.11.

Remarc. Un mijloc mai simplu de ierarhizare a cazurilor de utilizare reprezentate ntr-o

diagram, efectuat automat dar bazat pe un singur criteriu acela al prioritilor acordate
din exterior, ne este oferit de pachetul de programe Visual Paradigm for Unified Modeling
Language (vezi capitolul 12, figura 12.13). n cele ce urmeaz vom face ns o ierarhizare
bazat pe cele dou criterii menionate mai sus.
52
Figura 2.11
Clasamentul cazurilor de utilizare n studiul de caz e-commerce
Caz de utilizare
Prioritate
Risc
Cutarea lucrrilor
Gestionarea coului
Efectuarea comenzii
Consultarea comenzilor n curs
Consultarea help-ului on-line
ntreinerea informaiilor editoriale
ntreinerea site-ului
nalt
nalt
medie
sczut
sczut
nalt
medie
medie
mediu
sczut
nalt
mediu
sczut
nalt
sczut
sczut
Ordine de
abordare
2
3
4
6
7
1
5
5
Fa de aceast clasificare putem face urmtoarele observaii:

9 Efectuarea comenzii este de prioritate medie, deoarece navigatorul poate
scoate la imprimant devizul i apoi poate comanda prin fax sau curier
trimind plata prin pot.
9 Accentul este pus pe ntreinerea catalogului i Cutarea lucrrilor,
care sunt indispensabile n prim instan.
9 La nivelul riscurilor tehnice, eful de proiect a considerat ntreinerea

catalogului ca avnd cel mai nalt nivel de risc, din cauza problemelor
legate de integritatea informaiilor (actualizate semi-automat n baza de
date) i necesitii de a dispune de un catalog valid i la zi.
9 Efectuarea comenzii este considerat, de asemenea, ca avnd un nivel
nalt de risc, datorit problemelor de confidenialitate i de criptare ce
trebuie rezolvate.
9 Unul din principiile Procesului Unificat rezultat din dezvoltarea orientat
obiect bazat pe UML este acela de a identifica i nltura mai nti
riscurile majore.
9 Dac prioritatea este nalt i riscul de asemenea, cazul trebuie abordat
n prim instan. De aceea, ntreinerea catalogului a fost situat pe
primul loc n figura 2.11.
9 Dac prioritatea este sczut i riscul de asemenea, se poate lsa cazul
printre ultimile de rezolvat (vezi Consultarea help-ului on-line n tabelul
din figura 2.11).
9 Atunci cnd cele dou criterii sunt antagoniste, eful de proiect trebuie
s decid cntrind argumentele pro i contra i tratnd, eventual, cu
clientul pentru a stabili ordinea de abordare a cazului de utilizare
respectiv.
Conform clasificrii de mai sus, se poate elabora o planificare a proiectului care
urmeaz ordinea de abordare menionat n ultima coloan din figura 2.11.
Aceast ordine de abordare este deosebit de important, att pentru eful de
proiect care trebuie s-i organizeze echipele cu care s atace proiectul i s
planifice ntreaga aciune, ct i pentru conducerea ntreprinderii care trebuie
s-i planifice resursele pe care s le pun la dispoziia efului de proiect n aa
fel nct s nu ntrzie desfurarea lucrrilor.
"______________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
53
Specificarea detaliat a
cerinelor. Fia-tip a
cazurilor de utilizare

n acest capitol:
Descrierea detaliat a cazurilor de utilizare
Scenarii: scenariul nominal, extensii, precondiii, postcondiii, cerine
suplimentare
Fia-tip a cazurilor de utilizare
Studiul de caz e-commerce - fia-tip a cazurilor de utilizare pentru:
ntreinerea catalogului, cutarea lucrrilor, gestionarea coului,
efectuarea comenzii. Actualizarea diagramelor de caz de utilizare
54
Descrierea detaliat a cazurilor de utilizare

n capitolele precedente am identificat actorii i cazurile de utilizare. Acum vom
nva s descriem cazurile de utilizare n detaliu, pentru a obine o exprimare
precis a necesitilor nainte de a ataca analiza i construirea n detaliu a
obiectelor. n final vom nva s completm o fi-tip pentru fiecare caz de
utilizare.
Scenarii
Putem considera cazurile de utilizare drept o colecie de scenarii de succes sau
eec, ce descriu modul n care un anumit actor utilizeaz sistemul pentru a
atinge un obiectiv.
Cazul de utilizare trebuie s aib un nceput i un sfrit, clar definite.
Trebuie precizate toate variantele posibile, ncercnd totodat s ordonm

secvenial descrierile pentru a ameliora lizibilitatea.
Exist dou tipuri de scenarii: scenariul nominal i extensiile sale.
Scenariul nominal: permite satisfacerea obiectivelor actorilor prin calea cea
mai direct de succes.
Extensiile: conin toate celelalte scenarii de succes (sfrit normal) sau eec
(excepii).
Fiecare scenariu este compus din etape, care pot fi:
9 un mesaj al unui actor ctre sistem;
9 validare sau o schimbare a strii sistemului;
9 un mesaj al sistemului ctre un actor.
Etapele sunt numerotate secvenial, pentru a putea indica apoi extensiile
posibile.
Extensiile sunt foarte importante. Ele indic toate celelalte scenarii sau
ramificaii posibile, att de succes ct i de eec. Convenia de numerotare ne
ajut s le legm de scenariul nominal. Astfel, unei etape X, o prim extensie
va fi notat cu Xa i va identifica:
9 mai nti condiia care provoac extensia, i apoi
9 rspunsul sistemului.
Principiul const n descrierea condiiei care s poat fi detectat de sistem.
Apoi, rspunsul sistemului poate cuprinde una sau mai multe etape, numerotate
secvenial.
O a doua extensie referitoare la X se va nota cu Xb .a.m.d.
Fia-tip a cazurilor de utilizare

Descrierea n detaliu a unui caz de utilizare se bazeaz pe o fi-tip care descrie
textual cazul i care propunem s cuprind urmtoarele rubrici 13: actorul
principal, eventual actorii secundari, obiectivul, precondiii, postcondiii,
scenariul nominal, extensiile, i eventual cerine suplimentare.
Un rezumat al principalelor caracteristici ale fiei-tip a cazurilor de utilizare este
artat n figura 4.1.
55
13
Fia-tip nu este normalizat de UML
Figura 4.1
Fia-tip a cazurilor de utilizare rezumat
Fia-tip a
Explicaii
cazurilor
de utilizare
Rol
Fia-tip are rolul de a detalia fiecare caz de utilizare, fcnd s
Elemente
componente
Cnd se
utilizeaz

Exemplu 14
apar clar comportamentul sistemului i al actorilor care iau

parte la fiecare aciune proprie cazului de utilizare respectiv.
Actorul principal, actorii secundari, obiectivul, precondiii,
postcondiii, scenariul nominal, extensii, declanatorul, cerine
suplimentare.
Se utilizeaz ca punct de plecare pentru diagrama de secven,
diagrama de colaborare, diagrama de activiti, diagrama de
stare i toate celelalte diagrame de tip comportamental.
Fia tip: Cumprarea unui produs
Obiectiv: Satisfacerea nevoii clientului
Scenariul nominal:
1. Clientul parcurge catalogul i selecteaz articolele.
2. Clientul acceseaz pagina de validare a comenzii.
3. Clientul furnizeaz informaiile privind livrarea (adresa de
livrare, condiiile de livrare).
4. Sistemul afieaz preul, inclusiv costul transportului.
5. Clientul furnizeaz informaii referitoare la cartea sa de
credit.
6. Sistemul autorizeaz vnzarea.
7. Sistemul trimite un e-mail de confirmare clientului.
Extensii:
3a: Clientul este un client de baz:
1. Sistemul afieaz informaiile curente referitoare la tarife,
livrare i facturare.
2. Clientul le poate accepta sau modifica; ntoarcere la
etapa 6 a scenariului nominal.
6a: Sistemul nu autorizeaz cumprarea pe credit. Clientul
poate introduce din nou informaiile pe cartea sa de credit,
sau s o anuleze.
Elementele fiei-tip a cazurilor de utilizare sunt detaliate n figura 4.2.
56
14
Vezi [Fowler2] Martin Fowler - UML 2.0 CampusPress, 2004, pag.121.
Figura 4.2
Elementele fiei-tip a cazurilor de utilizare
Elementele fiei-tip a
cazurilor de utilizare
Actorul principal
Actorii secundari
Obiectivul
Scenariul nominal
Extensiile
Explicaii
Fiecare caz de utilizare are un actor principal, care

interacioneaz cu sistemul n vederea realizrii
unui serviciu.
Actorul principal este acela cruia sistemul
ncearc s-i satifac obiectivul i este, de regul,
iniiatorul cazului de utilizare.
Pot exista, uneori, i ali actori cu care sistemul
comunic pe durata realizrii cazului de utilizare.
Acetia poart numele de actori secundari.
Obiectivul enun beneficiul pentru actorul
principal realizat n cazul de utilizare respectiv.
Scenariul
nominal
descrie,
n
amnunt,
desfurarea evenimentelor n cadrul unui caz de
utilizare, sub forma unor aciuni succesive ale
actorului principal (eventual i ale actorilor
secundari) urmate de rspunsuri ale sistemului.
Scenariul nominal presupune c aciunile se
desfoar normal, se primesc n modul cel mai
direct - rspunsurile ateptate din partea
sistemului i totul se termin prin atingerea
obiectivului cazului de utilizare respectiv. Fiecare
aciune poart numele de etap. O etap poate fi:
enunul unei proceduri (din partea actorului sau
sistemului), enunul unui mesaj (din partea
actorului sau sistemului), schimbarea unei stri a
sistemului.
Convenie de notaie: n cadrul scenariului
nominal etapele se desfoar secvenial i sunt
notate 1, 2, ... , n.
O extensie nominalizeaz o condiie care
antreneaz interaciuni diferite de cele descrise n
scenariul nominal. O extensie este totdeauna o
consecin a uneia din etapele scenariului
nominal.
Convenie de notaie:
9 cifr, care indic etapa de plecare din cadrul
scenariului nominal, urmat de
9 liter a, b, ... care indic varianta (de
57
Precondiiile
Postcondiiile
Declanatorul
Cerine suplimentare
rspuns, de stare, de mesaj etc).

9 n cadrul unei extensii, aciunile se
renumeroteaz ncepnd de la 1, 2,...
O precondiie descrie ceea ce sistemul trebuie s
verifice nainte de a autoriza nceperea cazului de
utilizare.
O postcondiie descrie ceea ce sistemul trebuie s
se asigure la sfritul cazului de utilizare. Dup
fiecare scenariu nominal exist o postcondiie de
succes. Extensiile nu pot avea dect, eventual,
postcondiii minimale.
Uneori se specific i evenimentul care provoac
demarajul cazului de utilizare respectiv, care
poart numele de declanator.
Exist situaii n care este necesar adugarea
unor cerine suplimentare, referitoare la frecvena
de repetare a cazului de utilizare, condiiile n care
are loc acest scenariu etc (vezi cazul de utilizare
ntreinerea catalogului din cadrul studiului de
caz e-commerce).

Observaie: VP-UML ofer o facilitate de descriere a cazurilor de utilizare dup
58
un model apropiat de acela al fiei-tip definit mai sus (vezi capitolul 12, figura
12.11).
Studiul de caz e-commerce - fia-tip a cazurilor de

utilizare pentru: ntreinerea catalogului, cutarea
lucrrilor, gestionarea coului, efectuarea comenzii.
Actualizarea diagramelor de caz de utilizare
n subcapitolul precedent am stabilit o structur pentru fia-tip de descriere a
comportamentului unui caz de utilizare. Vom respecta aceast structur pentru
fiele-tip ale cazurilor de utilizare n cadrul aplicaiei e-commerce: ntreinerea
catalogului, cutarea lucrrilor, gestionarea coului i efectuarea comenzii pe
care le vom descrie n continuare.
Fia-tip: ntreinerea catalogului
Actorul principal: Librarul
Actori secundari: Cele dou subsisteme: Nouti i Gestiunea stocurilor.
Obiectiv: Librarul va putea controla actualizarea automat a catalogului de
lucrri prezentat pe site-ul Web.
Precondiii: Librarul s-a autentificat pe intranet. Versiunea curent a catalogului

este accesibil.
Postcondiii: O nou versiune a catalogului este disponibil.

Scenariul nominal:
1. Sistemul Nouti alimenteaz site-ul cu noile lucrri.

1. Sistemul Gestiunea stocurilor actualizeaz datele referitoare la pre i
starea stocului.
2. Librarul valideaz actualizarea catalogului.
Extensii:
1-2a: Sistemul detecteaz o disfuncionalitate de actualizare extern 15.
1: Sistemul semnalizeaz Librarului disfuncionalitatea.

2: Librarul invalideaz actualizarea parial sau eronat i revine la versiunea
precedent a catalogului. El previne Webmasterul pentru ca acesta s
demareze aciuni de ntreinere. Cazul de utilizare ia sfrit (eec).
3a: Librarul detecteaz erori sau incoerene printre noile informaii.

1: Librarul modific toate informaiile eronate.
2: Librarul valideaz actualizarea catalogului.
3b: Librarul vrea s adauge i alte informaii.
1: Librarul execut cazul de utilizare ntreinerea informaiilor editoriale.

2: Librarul valideaz actualizarea catalogului.
Cerine suplimentare: Catalogul este actualizat zilnic.
Observaie. ntre cazul de utilizare ntreinerea catalogului i cazul de
utilizare ntreinerea informaiilor editoriale apare, n urma extensiei 3b de mai
sus, o relaie de extensie (vezi capitolul 2, figura 2.7). Cu alte cuvinte, acest
ultim caz poate fi apelat din interiorul primului.
59
15
Condiia de extensie a aprut ntre etapa 1 i etapa 2 a scenariului nominal i a fost

notat cu 1-2a.
Cutarea lucrrilor
Fia-tip: Cutarea lucrrilor
Actorul principal: Navigatorul
Obiective: Navigatorul vrea s gseasc, cel mai rapid posibil, o lucrare cutat
n ansamblul Catalogului. El dorete, de asemenea, s se poat plimba, ca ntr-o

adevrat librrie, i s caute cri dup diverse criterii.
Precondiii: Catalogul este disponibil.
Postcondiii: Navigatorul a gsit lucrarea cutat sau o alt lucrare care l
intereseaz. El a nregistrat-o n coul su virtual (vezi cazul de utilizare
urmtor).

Scenariul nominal:
60
1. Navigatorul lanseaz o cutare rapid, plecnd de la 1-2 cuvinte-cheie: o

tem, un titlu, numele autorului. El poate completa direct un numr ISBN.
2. Sistemul afieaz o pagin de rezultat (vezi capitolul 1, figura 1.16).
Lucrrile sunt clasate implicit dup data apariiei, cea mai recent fiind
prima.
3. Navigatorul selecteaz o lucrare.
4. Sistemul i prezint o fi detaliat pentru lucrarea aleas (vezi capitolul 1,
figura 1.18). Aceasta va conine:
9 imagine (pentru majoritatea lucrrilor);
9 titlul, subtitluri, autori, editor, data apariiei, numrul de pagini,
limba;
9 preul i disponibilitatea lucrrii;
9 eventuale comentarii ale clienilor care au citit cartea;
9 tabla de materii detaliat, extrase din capitole etc.
5. Navigatorul pune lucrarea n coul su virtual.
Extensii:
1a: Navigatorul nu are o idee preconceput i prefer s se plimbe n raionele

librriei virtuale. Pentru aceasta, sistemul i propune un ansamblu de pagini
Web, precum: Nouti, Cele mai bune vnzri, Selecia librarului (pe
teme).
1: Navigatorul navigheaz n aceste pagini i se poate brana la etapa 3 a

scenariului nominal.
1b: Navigatorul alege s fac o cutare avansat.
1: Navigatorul accede un formular specializat care i permite s combine mai

multe feluri de cutri: dup subiect, titlu, autor, editor, limb etc. El poate
tasta numai nceputul semnificativ al unui cuvnt, continund cu *. Motorul va
cuta toate cuvintele care ncep cu literele tastate. Sufixele sunt suprimate pe
durata cutrii (exemplu: o cutare dup program va permite i gsirea unor
cuvinte ca programe sau programator). Navigatorul poate utiliza operatorii

logici AND, OR, NOT.
2a: Sistemul nu a gsit lucrarea cutat.
1: Sistemul semnalizeaz eecul i propune navigatorului o nou cutare. Cazul

rencepe de la etapa 1 a scenariului nominal.
2b: Sistemul a gsit un numr foarte mare de lucrri.
1: Sistemul semnaleaz numrul navigatorului i afieaz o prim pagin de

rezultate. Alte pagini sunt accesibile direct sau prin simbolurile <<urmtor>> i
<<precedent>>.
2: Navigatorul se plimb n aceste pagini i poate merge mai departe la etapa 3
a scenariului nominal. El poate, de asemenea, s reclaseze lucrrile obinute,
dup diverse criterii: titlu, autor, limb, disponibilitate etc.
3-5a: Navigatorul nu este interesat de rezultat.
1:Navigatorul revine la etapa 1 a scenariului nominal, pentru a lansa o nou

cutare.
2:Navigatorul abandoneaz cutarea. Cazul de utilizare ia sfrit (eec).
Cerine suplimentare: Cutarea trebuie s fie ct se poate de rapid: 95% din
cereri trebuie s reueasc n mai puin de 3 secunde. Rezultatele cercetrii
trebuie s fie pertinente, adic s corespund cererii n cel puin 99% din
cazuri. Formularul de cutare rapid trebuie s fie ntotdeauna vizibil. El trebuie
deci s existe n partea superioar a tuturor paginilor, oricare ar fi rezoluia
ecranului navigatorului (vezi capitolul 1, figura 1.17).
Observaii:
9 Fie c lanseaz o nou cutare, fie c abandoneaz, cele dou situaii
sunt simplu indicate utiliznd acelai numr de secven.
9 Soluia prezentat este mai simpl i mai pragmatic dect soluia
preliminar propus n figura 2.8 din capitolul 2. Cazurile de utilizare de
acolo dispar n favoarea unui singur caz, cel prezentat, care devine
concret. Acesta este un bun exemplu de modelare iterativ.
9 Scenariul de mai sus a fost propus ca aplicaie practic i n cadrul
capitolului 12, pentru a fi realizat cu pachetul de programe Visual
Paradigm for Unified Modeling Language (vezi figura 12.11).
"______________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
61
Gestionarea coului
Fia-tip: Gestionarea coului
Obiectiv: Atunci cnd navigatorul este interesat de o lucrare, el trebuie s aib
posibilitatea de a o nscrie ntr-un co virtual, apoi s adauge alte lucrri, s
suprime sau s modifice cantitile nainte de a nregistra comanda.
Precondiii: Nu sunt.
Postcondiii: Nu sunt.

Scenariul nominal:
62
1. Navigatorul nregistreaz lucrrile care l intereseaz ntr-un co virtual (vezi

cazul Cutarea lucrrilor).
2. Navigatorul cere accesul la coul su.
3. Sistemul afieaz starea coului su (vezi figura 4.3). Fiecare lucrare
selecionat este prezentat pe o linie, cu titlu, autor, numr ISBN. Este
afiat preul unitar, cantitatea este poziionat pe 1 i este calculat preul
total al liniei. Totalul comenzii este calculat i afiat n partea de jos a
coului, cu indicarea cheltuielilor de transport.
4. Navigatorul valideaz coul su cernd Efectuarea Comenzii.
Extensii:
3-4a: Coul este vid.
1: Sistemul afieaz un mesaj de eroare navigatorului (Coul este vid) i i

propune s revin pentru a Cuta o lucrare.
4a: Navigatorul modific cantitatea unei linii de co sau o suprim.
1: Navigatorul revalideaz coul, cernd recalculare total.

2: Sistemul actualizeaz totalul calculat al coului i cazul de utilizare se reia de
la etapa 4 a scenariului nominal.
4b: Navigatorul efectueaz o nou Cutare de lucrri (vezi cazul de utilizare
corespunztor).
1: Se reia etapa 1 a scenariului nominal.
4c: Navigatorul cere un deviz pentru a comanda prin curier.
1: Sistemul furnizeaz un deviz imprimabil care se ataeaz facturii,

recapitulnd comanda i totalul de plat (vezi figura 4.4).
Cerine suplimentare: Coul navigatorului este salvat pe ntreaga durat a
vizitei sale pe site-ul Web.
Figura 4.3
Exemplu de afiare a strii coului virtual
Observaie: O alt versiune a acestui scenariu a fost creat n cadrul

capitolului 11, pentru a putea reprezenta, cu ajutorul pachetului de programe
RRRT, comportamentul capsulelor GCos, PClient i SysCos.
Figura 4.4
Exemplu de afiare a devizului
"______________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
63
Efectuarea comenzii: secvena scenariului nominal

Fia-tip: Efectuarea comenzii

Obiectiv: n fiecare moment, clientul trebuie s poat accesa formularul bon de
64
comand n care s-i poat tasta coordonatele precum i informaiile necesare

plii i livrrii.
Precondiii: Coul navigatorului nu este vid i acesta a avut acces la formularul
de comand.
Postcondiii: O comand a fost nregistrat i transmis serviciului Comenzi.
Scenariul nominal:
1. Navigatorul tasteaz ansamblul informaiilor necesare plii i livrrii,
adic:
9 adresa de e-mail cu o parol pentru a putea urmri comenzile
proprii;
9 coordonatele adresei de facturare (nume, prenume, adresapotal
complet, telefonul);
9 coordonatele adresei de livrare, dac aceasta este diferit de adresa
de facturare (nume, prenume, adresa potal complet, telefonul);
9 numrul cartelei de credit, cu tipul i data de validitate.
2. Sistemul afieaz o recapitulare a comenzii, de exemplu: <<comanda,
adresa de facturare, adresa de livrare, expedierea. Comanda ar trebui s
ajung la dumneavoastr n 48-72 ore.>>
3. Navigatorul valideaz comanda.
4. Sistemul trimite comanda valid serviciului Clieni al Librriei X.
5. Sistemul confirm luarea comenzii navigatorului.
Extensii:
1a: Navigatorul este deja client.
1: Navigatorul se identific cu e-mailul i parola sa,

2: Sistemul afieaz datele salvate referitoare la adresa de facturare i cazul de
utilizare continu cu etapa 2 a scenariul nominal.
2a: Sistemul nu recunoate clientul. Sistemul avertizeaz navigatorul c e-mailul
i parola nu corespund celor ale unui client cunoscut i i propune s se
identifice din nou (ntoarcere la 1a.1).
1-3a: Navigatorul anuleaz comanda.
1: Sistemul revine asupra afiajului coului i cazul de utilizare este terminat.

2a: Navigatorul este deja client i vrea s-i modifice informaiile salvate.
1: Sistemul afieaz datele salvate, privind contul client (adresa de facturare,

parola etc).
2: Navigatorul modific unele informaii i valideaz.

3: Sistemul confirm validarea.
4: Navigatorul revine asupra fiei de comand i cazul de utilizare continu cu
etapa 2 a scenariului nominal.
Cerine suplimentare:
Pentru a garanta securitatea i confidenialitatea
schimburilor, trebuie ca trimiterea datelor s se fac ntr-o manier criptat

(protocol SSL Security Socket Layer). Cardurile acceptate sunt: Visa,
Eurocard-Mastercard i American Express.
Actualizarea diagramelor de caz de utilizare

Clientul va trebui s poat vedea n orice moment comenzile sale i chiar s le
poat eventual modifica nainte de expediere, ntr-o manier securizat.
Consultarea comenzilor n curs este deci un caz de utilizare complet
independent, care <<extinde>> opional Efectuarea comenzii.
Trebuie s avem n vedere c orice caz de utilizare dispune de o unitate de
legtur, de sesiune, n care prima operaie este identificarea navigatorului.
Aadar, cazul de utilizare Sesiune - identificare este <<inclus>> att n
Cutarea lucrrilor ct i n Efectuarea comenzii sau Consultarea comenzilor
n curs.
Din studiul scenariului pentru Cutarea lucrrilor a rezultat un singur caz
pentru Cutarea avansat, care <<extinde>> Cutarea lucrrilorceea ce a
condus la simplificarea schemei de generalizare din figura 2.8, capitolul 2.
Avnd n vedere cele de mai sus, diagrama principalelor cazuri de utilizare ale
navigatorului poate fi completat i modificat ca n figura 4.5 (a se compara cu
figura 2.9, capitolul 2).
"______________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
65

Figura 4.5
Principalele cazuri de utilizare ale navigatorului
66
Diagramele de secven
sistem (DSS)
n acest capitol:
Diagramele de secven sistem
Studiul de caz e-commerce diagramele de secven sistem pentru
cazurile de utilizare: cutarea lucrrilor, gestionarea coului, efectuarea
comenzii, ntreinerea catalogului
Diagramele de secven sistem

Diagramele de secven sistem (DSS) fac parte din categoria diagramelor care
exprim comportamentul sistemului proiectat. Se reprezint, de regul,
scenariul pentru fiecare caz de utilizare n parte.
Vom utiliza termenul de diagrame de secven sistem pentru a sublinia faptul c
sistemul informatic figureaz, n aceste diagrame, ca o cutie neagr.
Comportamentul sistemului este descris ca fiind vzut din exterior, fr a lua n
consideraie cum a fost realizat. Cutia neagr va fi detaliat cu ocazia
diagramelor de specificaii.
"______________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
67
Principalele caracteristici ale diagramei de secven sistem

Un rezumat al principalelor caracteristici ale diagramelor de secven sistem
este artat n figura 5.1.

Figura 5.1
Principalele caracteristici ale diagramelor de secven sistem
Diagrama UML de
Caracteristici
secven sistem
Reprezentare
68
Rol
Elemente
componente
Cnd se utilizeaz
Diagrama de secven sistem descrie comportamentul

instanelor actorilor i al sistemului (global) prin
intermediul mesajelor emise i primite de acetia
ntr-un caz de utilizare dat.
Diagrama
de
secven
sistem
reprezint
o
implementare posibil a scenariului cazului de utilizare
respectiv.
Instanele actorilor i ale sistemului global considerate
ca obiecte de sine stttoare, liniile lor de via,
mesajele emise i primite de fiecare obiect,
reprezentate secvenial.
Diagrama de secven se utilizeaz ori de cte ori se
dorete vizualizarea comportamentului mai multor
obiecte (ale actorilor, ale subsistemelor) n interiorul
unui caz de utilizare. Diagrama de secven sistem
consider sistemul n totalitatea sa ca pe o singur
clas i trateaz instanele sale ca atare.
Exemplu
S ne referim la exemplul scenariului de cumprare a

unui produs, reprodus dup Fowler n figura 4.1 din
cadrul capitolului 4, i s ncercm s-i reprezentm
diagrama de secven sistem.
Remarci:
9 n aceast diagram s-a reprezentat numai scenariul
nominal.
9 Clientul caut n catalog articolul dup cuvinte cheie.
9 Completarea formularului de comand include informaiile
privind livrarea (adresa de livrare, condiiile de livrare).
9 Autorizarea livrrii este reprezentat aici printr-o operaie
n interiorul sistemului. O alt variant ar fi expedierea
unui mesaj Serviciului Clieni care s preia aceast sarcin
(vezi studiul de caz e-commerce Efectuarea comenzii).
"______________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
69
Elementele diagramei de secven sistem

Elementele diagramei de secvan sistem sunt detaliate n figura 5.2.
Figura 5.2
Elementele diagramei de secven sistem
Elementele
diagramei de
secven sistem
Instanele
actorilor
Explicaii
Actorii care intervin ntr-o diagram de secven sunt

considerai drept clase iar instanele lor se reprezint
precum instanele claselor, adic:
<nume_instan> : <nume_actor>
Remarc. Numele instanei nu este obligatoriu.
Instana
sistemului
Sistemul se consider o singur clas (global) iar

instana sa se reprezint n modul clasic, adic:

<nume_instan> : <nume_sistem>
70
Remarc. Numele instanei nu este obligatoriu.
Liniile de via
Mesajele
Liniile de via ale fiecrui obiect se reprezint sub

forma unei linii ntrerupte verticale care pornete de la
simbolul obiectului respectiv i dureaz atta timp ct
exist obiectul, adic se termin mesajele care pleac
sau sosesc n acesta.
Mesajele se reprezint prin linii orizontale terminate cu
sgei, care pleac de la linia de via a obiectului
emitent i ajung la linia de via a obiectului receptor.
Mesajele se reprezint secvenial, de sus n jos,
urmrind etapele scenariului nominal.
Convenie de notaie:
De obicei, mesajele care pleac de la actori se noteaz
ca proceduri (de regul fr parametri sau cu
parametrii considerai eseniali pentru nelegerea
procedurii).
Exemplu: cutareArticole (cuv.cheie)
Mesajele care pleac de la sistem se reprezint cu linie
ntrerupt i se noteaz ca un simplu text.
Exemplu: articole gsite
Mesajele care pleac de la sistem se pot nchide n ele

nsele dac reprezint sarcini pe care le poate rezolva
numai sistemul. Detalierea ulterioar a diagramelor de
secven (cu ocazia specificaiilor de interfa) vor pune
n eviden subsistemele crora le revine obligaia s
rezove aceste sarcini.
Exemplu: autorizare a vnzrii
(Exemplele de mai sus se refer la diagrama de

secven sistem reprezentat n figura 5.1).
Studiul de caz e-commerce diagramele de

secven sistem pentru cazurile de utilizare:
cutarea lucrrilor, gestionarea coului, efectuarea
comenzii, ntreinerea catalogului
n cele ce urmeaz vom reprezenta diagramele de secven sistem pentru
principalele cazuri de utilizare ale studiului de caz e-commerce. Clasa care
reprezint sistemul va fi notat cu librariaX.com.
Pentru evenimentele proprii unui caz de utilizare, diagramele de secven
sistem (DSS) arat nu numai cum interacioneaz cu sistemul actorii externi, dar
chiar i cum intervin evenimentele-sistem declanate de actori. Ordinea
cronologic a derulrii evenimentelor este de sus n jos i urmrete, de regul,
secvena descris n cazul de utilizare.
Vom ilustra, n cele ce urmeaz, DSS-urile unor scenarii reprezentative pentru
cazurile de utilizare descrise n cadrul studiului de caz e-commerce:
9 Cutarea lucrrilor;
9 Gestionarea coului;
9 Efectuarea comenzii;
9 ntreinerea catalogului.
71
Cutarea lucrrilor
Pentru cazul de utilizare Cutarea lucrrilor (scenariul nominal), se pornete
de la descrierea textual detaliat a cazului de utilizare, fiecare etap
transformndu-se ntr-o sgeat care reprezint un mesaj.

Prima aciune este aceea a cutrii rapide sau cutrii avansate a lucrrii n
catalog. Am utilizat o not pe marginea diagramei (sau). Nu este neaprat
nevoie, dar aceasta permite creterea coninutului informativ al reprezentrii.
Sgeata ntrerupt care pleac de la instana sistem (:librariaX.com) la instana
actor (:Navigator) reprezint un retur n sens UML. Aceasta nseamn c
mesajul n cauz (lucrri gsite) este rezultatul direct al mesajului precedent,
printr-o relaie puternic de la cauz la efect. n general, nu se marcheaz dect
retururile interesante.
Aa cum am menionat, diagramele de secven ilustreaz interaciuni ntre
instane (obiecte) i nu ntre clase. Notaia :Navigatorul indic o instan a
actorului i nu clasa sa.
72
Urmtoarea aciune a navigatorului este selectarea lucrrii printre cele oferite de

sistem. Pentru facilitarea acestei decizii, de un real folos este fia lucrrii, cu
informaii detaliate, oferit de sistem.
n final, lucrarea selectat este pus n co.
Rezultatul reprezentrii acestor aciuni este prezentat n figura 5.3.
"______________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
Figura 5.3
Diagrama de secven sistem a cazului de utilizare Cutarea lucrrilor
Remarc. n figura 12.14 din capitolul 12 se arat modul de generare a diagramei de

secven sistem a cazului de utilizare Cutarea lucrrilor, cu ajutorul VP-UML.
Gestionarea coului
Pentru acest caz de utilizare, DSS reprezint mai mult dect scenariul nominal.
Am descris un exemplu mai complet de gestionare a coului pentru a ilustra
aciunile de accesare a coului, modificare a cantitii, de suprimare a liniilor etc.
(vezi figura 5.4).
A se nota, de asemenea, trimiterea la cazul de utilizare Cutarea lucrrilor
odat cu comanda punenCo () la nceputul diagramei, care arat un exemplu
de umplere a coului ca urmare a unei cutri.
73

Figura 5.4
Diagrama de secven sistem pentru cazul de utilizare Gestionarea coului
74
Efectuarea comenzii
Mesajul comandCoul() trimis sistemului la nceputul diagramei leag acest caz
de cazul de utilizare Gestionarea coului.
Ca urmare, sistemul trimite navigatorului formularul de comand. Acesta este
completat de navigator i trimis sistemului odat cu mesajul tasteaz
InfoComand().
Sistemul trimite navigatorului recapitularea comenzii, odat cu cererea de a

corecta, eventual, unele erori.
n cele din urm, navigatorul valideaz comanda pe care, odat cu mesajul
valideazComanda () este trimis sistemului.
Sistemul paseaz Serviciului Clieni comanda validat i trimite navigatorului
confirmarea comenzii.
Interesul diagramei de secven sistem apare din plin atunci cnd exist actori
secundari.
n efectuarea comenzii, interaciunea ntre site-ul Web i Serviciul Clieni apare
clar, cu poziionarea precis a secvenelor de mesaje (vezi figura 5.5).
Figura 5.5
Diagrama de secven sistem pentru cazul de utilizare Efectuarea comenzii
n aceast diagram de secven, instanele subsistemelor Nouti i
Gestionarea stocurilor trimit informaii instanei sistemului librariaX.com pentru
ca aceasta s actualizeze, n mod automat, Catalogul.
n diagrama de secven sistem pentru acest caz de utilizare, sgeata care
bucleaz i care reprezint actualizarea automat a Catalogului
(actualAutoCatal(), vezi figura 5.6) permite reprezentarea grafic a unui
comportament intern major pe care dorim s-l accentum. Nu trebuie s se
abuzeze totui de acest gen de reprezentri, deoarece nu acesta este primul
obiectiv al diagramei de secven sistem.
"______________________________________________________________
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
75

Figura 5.6
Diagrama de secven sistem pentru cazul de utilizare ntreinerea catalogului
76
La primirea catalogului actualizat din partea sistemului, librarul are opiunea de

a face apel la cazul de utilizare ntreinerea informaiilor editoriale prin
actualInfoEditoriale () i apoi s trimit sistemului noua versiune pentru validare
prin comanda valideazCatalog (). Versiunea catalogului, validat de sistem,
este retrimis n cele din urm librarului.
Operaii sistem rezultate din analiza cazurilor de utilizare

Evenimentele sistem trimise de actori site-ului Web librriaX.com declaneaz
prelucrri interne pe care le vom numi operaii sistem. Ansamblul operaiilor
sistem ale tuturor cazurilor de utilizare definete interfaa public a sistemului.
Aceasta vizualizeaz sistemul ca pe o entitate unic o cutie neagr oferind
servicii.
n UML, sistemul luat n ansamblu poate fi reprezentat printr-o clas avnd
cuvntul-cheie <<system>>.
Urmare a cererii diferitelor DSS i mbogirii acestei descrieri preliminare cu
extensiile cazurilor de utilizare, se obine lista operaiilor sistem din figura 5.7.
Figura 5.7
Operaii sistem ale site-ului Web librariaX.com
Lista operaiilor sistem prezentate n figura 5.7 nu este exhaustiv deoarece nu

am descris n detaliu toate cazurile de utilizare. Ea va fi completat progresiv,
prin iteraii succesive, pentru a ajunge la nivelul specificaiilor de interfa.
Chiar n stadiul actual, se pot vedea totui fcndu-i apariia funciile majore
ale site-ului Web, la un nivel de detaliu apropiat de ceea ce va fi disponibil n
final.
77

Uml

Încărcat de

Informații document

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

Uml

Încărcat de

Drepturi de autor:

Formate disponibile

Analiza i proiectarea orientat obiect

a sistemelor informatice cu UML

Analiza i proiectarea orientat obiect

Despre modelare, principii de modelare, limbaje

servicii, comer, politic, administraie. Proiectul unui sistem informatic

Modelul este, prin urmare, o reprezentare abstract a unui sistem, care

Sistemul proiectat este considerat ca subsistem (cutie neagr), care

Observaie. Este de preferat s se descopere o eventual eroare de concepie pe un

Lucrrile de specialitate menioneaz urmtoarele patru principii ale modelrii 1:

Primul principiu: Alegerea modelelor influeneaz esenial maniera de abordare

Analiza i proiectarea orientat obiect

Pstrnd un grad redus de interdependen, se micoreaz considerabil riscul

De ce un limbaj orientat obiect?

Iat cteva din motivaiile acestei alegeri:

[Fowler&Scott] Martin Fowler et Kendall Scott Le tout en poche - UML, 2002,

2. Pe de alt parte, atunci cnd pornim la construcia unui sistem avem

Metodologii de realizare a sistemelor informatice

Metodologia de realizare clasic a sistemelor

Vezi [LuChi-kw] Introduction to object-oriented systems development, B329 Unit 1,

Metoda SDLC (Systems Development Life Cycle)

Analiza i proiectarea orientat obiect

Metoda SDLC iterativ

Proiectarea orientat obiect

Proiectarea orientat obiect ncepe cu definirea actorilor umani i a funciilor

Caracteristicile abordrii obiect

ca de exemplu actualizarea unei liste sau trasarea unei linii. Tehnologia de

5. Motenirea. Permite mai multor tipuri de obiecte s reutilizeze proprieti

Vezi [Gutu1] S.Guu, UML Limbaj de modelare unificat destinat managementului

Analiza i proiectarea orientat obiect

Principiile de baz ale abordrii obiect sunt: ncapsularea, motenirea i

9 ncapsularea Abordarea obiect a unui sistem ncepe cu definirea

aceluiai nume pentru metoda de generare, s spunem genereaza, nu va

UML standard industrial de modelare obiect

A se vedea [RRRT] Rational Rose RealTime for Windows, pachet de programe

Analiza i proiectarea orientat obiect

11/1997: adoptarea de ctre

Metoda unificat 0.8

Conform UML, un concept derivat din cerinele utilizatorului n conformitate cu

De la UML 1.0 la UML 1.1

De la UML 1.2 (i 1.1) la UML 1.3

Pentru a nota o condiie, se poate utiliza un romb pentru a nota att o

Analiza i proiectarea orientat obiect

De la UML 1.3 la UML 1.4

Cea mai important schimbare adus de UML 1.4 const n adugarea

De la UML 1.4 la UML 1.5

Z Referitor la diagramele de clase: concepte eseniale

Multiplicitile discontinui (exemplu [2,4]) au fost abandonate. Nu mai exist

Z Referitor la diagramele de clase: concepte avansate

Z Diagramele de maini de stare

UML 1 trata diagramele de activiti ca pe un caz particular al diagramelor de

Analiza i proiectarea orientat obiect

Diagramele funcionale se bazeaz exclusiv pe cazurile de utilizare pentru

Capitolul 2 se ocup de specificarea cerinelor conform cazurilor de utilizare

Diagramele statice (sau structurale)

entitilor manipulate de utilizator.

9 n realizarea modelului, cu o diagram de clase se reprezint de obicei

structura programelor orientate obiect sau, mai precis, modulele

Analiza i proiectarea orientat obiect

Pe parcursul acestei lucrri, clasele au fost abordate de la simplu la complex.

Diagrama reprezint o ierarhie a unor obiecte aparinnd unor clase. Numele

Obiectele intervin n cadrul: diagramelor de secven (vezi capitolul 5 i

Analiza i proiectarea orientat obiect

Diagramele de pachete sunt tratate n capitolul 2 i capitolul 9.

Diagramele de structuri compozite