Capitol 7 DSI

Baze de date orientate obiect
Capitol 7
(BDOO)
7.1. Conceptul de BDOO
Pentru definirea unei BDOO vom pleca tot de la definirea unei baze de date la
modul general, i anume:
O baz de date orientat obiect este format dintr-una sau mai multe clase de
obiecte cu asocierile dintre acestea.
Ca i n alte tipuri de baze de date, o BDOO dispune de o schem i instane ale
acestuia.
Schema BDOO conine specificaiile fiecrei clase de obiecte ce pot fi stocate n
baza de date. Pentru fiecare clas C, aceasta include:
- tipul asociat clasei C. Acest tip determin structura fiecrui obiect al clasei C;
- semntura metodelor din cadrul clasei C, care precizeaz denumirea metodei,
tipul i ordinea argumentelor permise metodei i tipul rezultatului oferit de acea
metod;
- relaiile subclaselor care permit identificarea superclasei a lui C;
- restriciile de integritate i restriciile refereniale, sau mai mult afirmaii generale
care sunt similare constrngerilor din modelul bazelor de date relaionale.
O instan a unei BDOO este un set de obiecte pentru multitudinea claselor
specificate n cadrul schemei bazei de date.
7.2. Premisele BDOO

Utilizarea conceptului de obiect n informatic dateaz din jurul anilor 1960, cnd
au fost elaborate primele Limbaje de programare orientate obiect, dintre care amintim:
Simula, EIFFEL, SmallTalk, Ada, C, C++, Common LISP, CLOS, OPAL, O2C, O2SQL,
O2API, SQL++, ACTOR, Object Pascal etc.
De remarcat, faptul c aceste limbaje de programare nu i-au gsit o larg utilizare
pentru aplicaii ce lucreaz cu volume mari de date datorit faptului c nc nu existau
metode corespunztoare de organizare a datelor. O astfel de problem a fost rezolvat n
jurul anilor 1980 cnd au aprut primele sisteme de gestionare a bazelor de date orientate
obiect (SGBDOO) cum ar fi: ONTOS, ObjectStore, O 2, GemStore, ORION, ITASCA,
Objectivity/DB, VERSANT, POET etc. Nici n astfel de mprejurri, abordarea obiectual
121
Capitol 7
a sistemelor de gestiune a bazelor de date nu i-au gsit o utilizare extins pentru aplicaii
complexe sau pentru cele ce implicau volume mari de date. Acest lucru s-a datorat
faptului c nc nu existau Metode, tehnici i metodologii de analiz i proiectare
orientate obiect a sistemelor informatice. Acestea au aprut n jurul anilor 1990 i dintre
ele enumerm:
- Object Oriented Design (OOD), elaborat de Grady Booch, este o metodologie
similar metodologiei OMT, dezvolt aceeai idee analiza i proiectare iterativ
insistnd asupra prii de proiectare [BDOOC94];
- Object Oriented Analysis (OOA) elaborat de Peter Coad i Edward Yourdon;
- Object Oriented Structured Design (OOSD) elaborat de Wasserman;
- Object Oriented System Analysis (OOSA) este o metodologie de proiectare a
sistemelor n timp real propus de Sally Shaler i Steven Mellor. Autorii au
continuat s mbunteasc aceast metodologie, publicnd chiar i o lucrare
despre cum se pot utiliza notaiile UML n cadrul metologiei Shaler/Mellor;
- Responsability Driven Design (RDD), aparinnd lui Wirfs - Brock, Wilkesson i
Wienner;
- Object Oriented Role Analysis, Synthesis and Structuring aparinnd lui Reens
Kaugh;
- Object Oriented Systems Analysis (OOSA) aparinnd lui Embley;
- Object Modeling Techinque (OMT) elaborat de James Rumbaugh, Michael
Blaha i alii, prezentat n lucrarea [RUMB94]. Metodologia a fost iniial
utilizat de General Electric and Development Center;
- Object Oriented Software Engineering (OOSE) conceput de Ivar Jacobson.
n plus, multe organizaii i-au dezvoltat propria metodologie intern, utiliznd
diagrame i tehnici din diverse surse. Exemple de astfel de metodologii sunt Catalyst
creat de Computer Sciences Corporation (CSC) i Worldwide Solution Design and
Delivery Method (WSDDM), creat de IBM. Aceste metodologii difer, dar n general
combin analiza fluxurilor, identificarea cerinelor, modelarea proceselor de afaceri i
modelarea obiectual utiliznd diverse notaii (OMT, Booch etc.) i uneori includ tehnici
adiionale specifice modelrii orientate obiect, cum ar fi fiele CRC sau cazurile de
utilizare.
Toate aceste metodologii prezentau o serie de limite precum i multiple
diferenieri de simboluri, notaii sau tipuri de diagrame. Aceste aspecte generau dificulti
n privina nelegerii, prelurii i folosirii lor de diferite grupuri de utilizatori, n crearea
de noi sisteme sau n procesul de mentenan a sistemelor. Mare parte dintre aceste
deosebiri au fost nlturate n 1997 prin elaborarea unui standard cu privire la simboluri,
notaii, tipuri de diagrame, tipuri de modele etc., numit UML (Unified Modeling
Language).
Majoritatea corporaiilor au adoptat UML ca notaii pentru propria lor
metodologie. Unii utilizeaz doar un subset al UML-ului pentru a modela ceea ce i
intereseaz, de exemplu, doar diagrama claselor sau doar cazurile de utilizare. Alii au
preluat ntreg setul UML, utiliznd inclusiv diagramele de stare i de activitate pentru a
modela sisteme n timp real i diagrama de implementare pentru a modela sisteme
distribuite.
122

Dintre premisele ce au dus la abordarea obiectual, n general, a analizei i
proiectrii sistemelor informatice i n special, a bazelor de date orientate obiect,
enumerm:
- limitele abordrii structurate n analiza i proiectarea sistemelor informatice
(bazele de date fcnd parte dintr-o disciplin mai larg i anume sisteme
informatice);
- limitele modelului relaional de organizare a datelor;
- schimbrile n ceea ce privete orientarea aplicaiilor ce puneau accent pe stocarea
datelor, spre aplicaii care pun accent pe prelucrarea mai eficient a datelor cu
algoritmi mai performani;
- succesele dobndite de ctre sistemele expert sub aspectul stocrii cunotinelor;
- progresele dobndite n domeniul instrumentelor de tip CASE;
- multiplele avantaje oferite de limbajele de programare orientate obiect, dintre care
precizm: facilitile de refolosire a codului, modularitate crescut i
extensibilitate sporit;
- apariia unor noi tipuri de aplicaii, cu cerine i particulariti specifice, pentru
care sistemele de gestiune a bazelor de date relaionale (SGBDR) s-au dovedit
inadecvate. Dintre acestea enumerm: proiectarea asistat de calculator (CAD
Computer Aided Design), aplicaii din domeniul meteorologiei, sisteme
informaionale geografice (GIS Geographic Information Systems), ingineria
programrii asistate de calculator (CASE Computer Aided Software
Engineering), sisteme informaionale de birou (OIS Office Information
Systems), aplicaii multimedia n cinematografie i televiziune, extinderea
aplicaiilor informaticii n domeniul medicinei, cercetrii tiinifice etc. Toate
aceste tipuri de aplicaii presupun preluri, stocri, regsiri i prelucrri de
evenimente, tranziii, stri, imagine/poz, voce/sunet, culoare, animaie etc., care
la rndul lor presupun utilizarea i manipularea unor noi tipuri de date pe lng
cele tradiionale (primitive), dintre care amintim:
- tipuri de date abstracte (ADTs) definite de utilizator,
- tipuri structurate,
- tipuri de obiecte mari (LOB Large Object) cu cele dou variante numite BLOB
(Binary Large Object) i respectiv CLOB (Character Large Object).
Astfel de noi tipuri de date pot fi regsite i tratate n cadrul acestui capitol i
chiar n urmtoarele capitole.
7.3. Avantajele i dezavantajele BDOO

Ca orice alt mod de organizare a datelor i BDOO prezint avantaje i
dezavantaje. n cele ce urmeaz vom recurge la evidenierea celor dou aspecte:
Avantajele BDOO. ntr-o form sintetic, avantajele BDOO ar putea fi enunate
astfel:
- Ofer faciliti cu privire la extensibilitatea bazei de date. Extensibilitatea apare
ca un avantaj cheie a BDOO deoarece tipurile de date pot fi extinse folosind
proprietatea de motenire. Se pot aduga noi subtipuri fr a fi necesar
123
Capitol 7
restructurarea poriunilor existente ale bazei de date. Aa dup cum s-a mai artat,
n acest mod activitatea de programare se transform ntr-o activitate de
programare doar a diferenelor, sporind productivitatea muncii. Se are n atenie
valorificarea proprietii de motenire prin definirea, sau prin generalizarea, de
superclase de obiecte cu includerea n aceasta a tot ceea ce este comun, iar apoi
partajarea acestora n subclase de obiecte n care vor fi precizate doar elementele
prin care se difereniaz fiecare subclas de celelalte subclase de obiecte. Efectele
benefice rezultate dintr-o astfel de abordare constau n reutilizarea codului,
reducerea redundanei datelor din baza de date, ntreinerea facil a bazei de date,
uurin n dezvoltarea i implementarea de noi aplicaii etc.
-
Reflect mai bine realitile din mediul nconjurtor. Lumea real nu este format
dintr-o colecie de tabele, ci un model a lumii reale apare ca o ierarhie de
ansambluri concretizate n articole de prelucrat. Aici o parte e descompus n
prile ei constituente ca subpri, care la rndul lor sunt descompuse n alte
subpri mai mici. Astfel de structuri sunt greu de reprezentat i manipulat
utiliznd tabele. De fapt prin folosirea unui SQL standard, toate subprile unei
pri date nu pot fi determinate tipic cu o singur instruciune de cereri. n
contrast, o baz de date orientat obiect suport capacitatea obiectelor de a se
referi direct unele la altele ct i facilitatea de calcul a limbajelor orientate obiect
de a procesa obiecte.
Totodat, un model de ntreprindere ar trebui s fie un model ce descrie tipuri de
obiecte, de afaceri, subtipuri, comportarea lor, relaiile dintre obiecte, strile
obiectelor, evenimentele ce determin schimbrile de stri, reguli de afaceri etc.
Modelul ntreprinderii trebuie translatat direct n software care face ca
ntreprinderea s funcioneze. O astfel de situaie necesit baze de date care
stocheaz obiecte i fac metodele asociate s fie operative.
BDOO permit obiectelor s se refere direct unele la altele pe baz de pointeri. O

astfel de adresare (referire) face BDOO mai rapide n a ajunge de la obiectul X la
Y dect bazele de date relaionale, care trebuie s foloseasc un operator de JOIN
pentru a realiza acest lucru. Chiar un JOIN optimizat e tipic mai ncet dect o
referire direct la obiect pe baz de pointeri.
BDOO ofer performane sporite referitoare la clasterarea (cluster) fizic a

datelor. Majoritatea sistemelor de baze de date permit proiectantului s plaseze
structurile legate aproape una de alta pe suportul de memorie extern. Prin
clasterare se urmrete sporirea vitezei de rspuns la cererile utilizatorilor ce
implic operaia de jonciune a unor structuri de date. Se reduce astfel n mod
considerabil timpul de regsire pentru datele solicitate, prin reducerea numrului
de accese pentru citirea datelor de pe harddisc. Exemplu, pentru a da rspuns facil
la o cerere de aplicaie de forma: care sunt subpri la componente ale unui produs
oarecare sau care sunt salariaii unei societi comerciale ce lucreaz ntr-un
anumit departament?
n astfel de situaii proiectanii recurg la definirea de clastere (Clusters). n
condiiile BDOO clasterarea fizic se realizeaz la un singur nivel, de unde rezult
124

i performanele sporite sub aspectul timpului de regsire. Logica de clasterare se
bazeaz pe clase i ierarhii de agregare. Obiectele care formeaz grupe sunt
stocate laolalt cu obiectele compozite i ntr-un sistem bine proiectat, structurile
de clasificare sunt folosite ca baz natural de clasterizare. Pe cnd, n condiiile
BDR se impune un al doilea nivel de claster. Un prim nivel pentru a grupa
tuplurile reprezentnd obiectele individuale i un al doilea pentru grupurile de
tupluri reprezentnd obiectele referite.
-
BDOO sporesc extinderea domeniilor de aplicabilitate prin posibilitatea folosirii

diverselor structuri de stocare i prelucrare a datelor. ntr-o baz de date
relaional, datele care nu pot fi exprimate n form tabelar sunt dificil de stocat
i accesat eficient. Ori, exist o multitudine de aplicaii care implic date
complexe, sunet, imagini, text neformatat etc. Modul de stocare pentru BDOO
este nelimitat, din moment ce sistemul este extensibil prin natura sa. BDOO pot
asigura diferite mecanisme de stocare pentru diferite tipuri de date. Drept urmare
ele s-au dovedit foarte eficiente att pentru aplicaii multimedia ct i CAD.
n general, se poate spune c BDOO ofer o mai bun performan atunci cnd
avem de a face cu obiecte complexe i relaii complexe, deoarece nu este nevoie s
spargem obiectele mari n tabele normalizate i apoi s le reasamblm n momentul
execuiei programelor de aplicaii.
Dezavantajele BDOO. n ciuda unor multiple avantaje pe care le ofer BDOO
totui acestea nc nu au reuit s se impun sub aspectul ponderii implementrii lor n
diferite domenii de aplicabilitate. Acest lucru se datoreaz unor dezavantaje ale lor, dintre
care enumerm:
- Lipsa unor standarde ale arhitecturii de SGBDOO, de modelare a datelor sau de
limbaje de integrare standard orientate obiect. Exist totui preocupri i chiar
anumite realizri de standardizare pe domeniile amintite, n mare parte aparinnd
grupului de administrare a bazelor de date orientate obiect (ODMG).
- SGBDOO nu ofer o gam larg de instrumente (TOOLS) utilizatorilor firmei sau
proiectanilor de dezvoltri i ntreineri de aplicaii, comparativ cu SGBDR.
- SGBDOO nu ofer suficient siguran n ceea ce privete rezolvarea problemelor
de acces concurent n condiiile lucrului cu volume mari de date.
- Nu sunt rezolvate n suficient msur problemele referitoare la asigurarea
integritii bazei de date sub aspectul refacerii acesteia n caz de incident.
- ncapsularea poate genera dificulti sub aspectul optimizrii integrrii bazei de
date. Felul n care sunt definite i stocate datele i metodele precum i limitele
Limbajelor de interogare orientate obiect pot influena n sens negativ
performanele de ordin fizic ale bazei de date. Acelai lucru poate s apar i n
situaia n care avem de a face cu anumite cerine informaionale care nu au fost
prestabilite. Cu alte cuvinte, apare ntrebarea: Cum pot fi cutate i regsite
anumite obiecte a cror structur este ncapsulat (ascuns), dac o astfel de
cerin nu a fost prevzut nc din faza de proiectare. Remarcm faptul c unele
SGBDOO de dat mai recent accept interogrile de tip AD-HOC ns, acest
125
Capitol 7
lucru l realizeaz prin distrugerea ncapsulrii sau prin impunerea unor limite
privind interogrile posibile.
Lipsa de experien n domeniu, comparativ cu experien dobndit n sistemele
tradiionale. Aceast lips de experien poate fi datorat cel puin de urmtorii
factori:
este un domeniu mai nou de preocupare;
SGBDOO prin componentelor lor sunt mai mult orientate spre
programatori dect spre utilizatorii finali neinformaticieni;
se simte o trecere abrupt de la sistemele tradiionale la cele orientate
obiect, iar, nelegerea i nsuirea noului mod de abordare impune eforturi
sporite din partea proiectanilor i utilizatorilor. Acest aspect genereaz o
oarecare rezisten n acceptarea tehnologiei orientate obiect.
7.4. Comparaii ntre abodarea obiectual i cea

relaional privind modelarea datelor
Prezentarea asemnrilor i deosebirilor dintre modelarea relaional i modelarea
orientat obiect a datelor este semnificativ i de mare importan att pentru proiectanii
de baze de date ct i pentru utilizatori.
Proiectanii, cunoscnd foarte bine modelul relaional i apoi sesiznd asemnrile
i deosebirile dintre cele dou moduri de abordare a modelrii datelor, vor putea
valorifica i folosi experiena dobndit anterior ca baz substanial pentru nelegerea i
nsuirea metodologiei de proiectare a bazelor de date orientate obiect. Totodat, prin
cunoaterea asemnrilor i deosebirilor dintre cele dou moduri de abordare apare
posibilitatea conversiei unui model relaional n obiectual i invers. De altfel, o astfel de
practic o regsim n mod frecvent.
n cele ce urmeaz vom recurge la o prezentare comparativ a modelrii datelor,
lund n considerare conceptele folosite precum i obiectivele urmrite.
n tabelul 7.1 se prezint o comparaie ntre principalele concepte utilizate n
modelarea obiectual i relaional a datelor.
Tabelul 7.1. Compararea BDOO i BDR sub aspectul conceptelor folosite
Modelul orientat pe
Modelul
Diferene
obiecte
relaional
Obiect
Entitate
Obiectul precizeaz i comportamentul
Clasa de obiecte
Tipuri de entiti Clasa de obiecte include i comportamentul
comun obiectelor din clasa respectiv
Ierarhia de clase
Schema bazei de Ierarhia de clase implic motenirea iar schema
date
implic chei externe
Instan de clas
Entitate, tuplu
Instana poate avea un caracter mai restrictiv
sau nregistrare
Atribut
Atribut
Fr diferene
Relaii
Relaii
Fr diferene
126

Au semnificaia de descrieri, ns n BDOO
motenirea include att starea ct i
comportamentul
Mesaje / interfa
ncapsulare
Identificatorul de
obiect (OID)
Nu exist
Nu exist
Cheie primar
n modelul relaional dac nu se definete cheia

primar sistemul genereaz n mod automat un
identificator
Deosebirile dintre modelul BDOO i modelul BDR pot fi evideniate i sub

aspectul obiectivelor urmrite sau prin alte caracteristici, aa cum se poate observa din
tabelul 7.2.
Tabelul 7.2. Compararea BDOO i BDR sub aspectul obiectivelor urmrite
BDOO
BDR
Obiective principale: ncapsularea i
Obiectiv principal: asigurarea
independena datelor.
independenei datelor fa de programele
de aplicaii.
Independena claselor: pot fi reorganizate
Independena datelor: datele pot fi
fr a afecta modul de folosire a lor.
reorganizate i modificate fizic fr a
afecta modul de folosire.
BDOO stocheaz date i metode.
BDR stocheaz numai date.
ncapsularea: datele pot fi folosite numai
Partiionarea datelor: datele pot fi
prin metodele claselor.
partiionate n funcie de cerinele i
specificul aplicaiilor utilizatorilor.
Obiecte active: obiectele sunt active.
Date pasive: datele sunt pasive. Anumite
Cerinele cauzeaz obiectelor executarea
operaii limitate pot fi n mod automat
metodelor acestora.
antrenate cnd datele sunt folosite.
Complexitate: structura datelor poate fi
Simplicitate: utilizatorii percep datele sub
complex, implicnd multiple tipuri de date. form de coloane, rnduri / tupluri i
tabele.
Date nlnuite. Datele por fi nlnuite aa
Tabele separate: fiecare relaie / tabel este
nct metodele claselor ofer performane
separat. Operatorul de JOIN refer date
sporite. Datele structurate precum i BLOB din tabele separate.
(binary larrge objects) sunt folosite pentru
sunet, imagine, video etc.
Neredundana metodelor: neredundana
Neredundana datelor: Normalizarea
datelor i metodelor sunt realizate prin
datelor are ca scop de a elimina sau reduce
ncapsulare i motenire. Motenirea ajut
redundana datelor. Ea este folosit n faza
la reducerea redundanei metodelor.
de proiectare a bazei de date i nu n faz
de dezvoltare a aplicaiilor.
Optimizarea datelor: datele pentru un obiect Performana BDR este legat de nivelul de
pot fi inter legate i stocate mpreun, astfel complexitate a structurii datelor.
nct ele pot fi accesate mpreun de
mecanismul de acces.
Modul conceptul consistent: modelele
Model conceptul diferit: modelul structurii
127
Capitol 7
folosite pentru analiz, proiectare,
programare i accesul bazei de date sunt
similare. Conceptele aplicatiilor sunt in mod
direct reprezentate prin clasele de obiecte.
datelor i acces reprezentat prin tabele i

JOIN-uri este diferit de cel n analiz,
proiectare i programare. Proiectul trebuie
s fie convertit n tabele relaionale i
acces conform SQL.
Analiznd cele dou tipuri de baze de date, obiectuale i relaionale, por fi

desprinse o serie de concluzii, dintre care amintim [Date, Sabu, Kifer]:
- O baz de date relaional este format din relaii, care sunt seturi de tupluri, n
timp ce o baz de date orientata pe obiecte este format din clase, care sunt seturi
de obiecte;
- ntr-o baz de date relaional, componentele unui tuplu trebuie s fie tipuri
primitive (real, integer, strings etc.), n timp ce ntr-o baz de date orientat pe
obiecte, componentele unui obiect pot fi att tipuri primitive ct i tipuri complexe
(seturi, tupluri, liste, BLOB-uri etc.);
- Bazele de date orientate pe obiecte au anumite proprieti pentru care nu gsim
analogie n bazele de date relaionale, cum ar fi proprietatea de motenire i
metodele aparinnd obiectelor;
- n anumite sisteme de baze de date orientate pe obiecte, limbajul de manipulare a
datelor i limbajul gazd sunt aceleai;
- Bazele de date relaionale au ca obiectiv principal asigurarea independenei
datelor. Datele normalizate sunt separate de prelucrri iar, prelucrrile
corespunztoare satisfacerii cerinelor informaionale nu este obligatoriu s fie n
totalitate predefinite deci se accept i cerine ad-hoc;
- Bazele de date orientate obiect au ca obiectiv principal ncapsularea, fiind stocate
mpreun datele / i metodele. Ele sunt inseparabile. Se spune c avem de a face
cu independena claselor nu cu independena datelor;
- Nevoia unui SGBDOO i nu unul relaional apare atunci cnd n aplicaiile de
referin avem de a face cu date complexe;
- Limbajele de programare necesit o nou sintax; mixarea, reproducerea i noile
metode de acces necesit de asemenea continuarea cercetrilor; trebuie realizate
caracteristici mai solide ale limbajelor de interogare; se simte nevoia continurii
n domeniul controlului concurenei, semantica mrcilor de timp i concurenei
bazate pe obiectele [2, Oracle 2004 A];
- Limbajul C++ nu este un limbaj prea adecvat pentru implementarea bazelor de
date ntruct prezint probleme legate de mecanica definirii atributelor, mecanica
referirii la obiecte ntr-un mod sistematic. Totodat, SGBD actuale bazate pe
limbajul C++ duc lipsa unor importante funcii ale bazei de date i, pentru a
compensa aceasta s-a recurs la implementri simple ale funciilor standard ale
sistemelor de gestiune, cum ar fi: nregistrarea n jurnal a tranzaciilor pentru
refacerea prin derulare nainte; un monitor multifir al tranzaciilor, un limbaj de
interogare i un procesor de interogri [5,6];
- Piaa bazelor de date orientate obiect va continua s creasc, dar va rmne nc
doar o fraciune din piaa tradiional a bazelor de date [2I.S3];
- Se apreciaz c SGBDR dein ponderea cea mai mare pe piaa bazelor de date.
ns ca perspectiv ele vor coexista nc mult timp mpreun cu SGBDOO.
128
7.5. Moduri de abordare ale dezvoltrii sistemelor

de BDOO
innd seama de multitudinea avantajelor oferite de modelul BDOO, se pune
problema cum anume se poate trece de la ceva existent la BDOO sau alte variante ce pot
fi adoptate. Rspunsul la o astfel de ntrebare const n faptul c pot fi adoptate diverse
abordri, cum ar fi:
- Folosirea unui sistem de gestiune de baz de date convenional existent i
adugarea unui strat (layer) pentru procesarea cerinelor orientate obiect i
metodelor de stocare. ntr-o astfel de abordare sistemul de gestiune a bazei de date
nu se schimb, ceea ce nseamn c se pot folosi componentele software ale
acestuia precum i vechile persoane de aplicaii n curs de exploatare. Totodat, se
poate implementa o baz de date orientat obiect mult mai repede dect dac s-ar
porni de la conceperea i dezvoltarea tuturor componentelor sistemului de
gestiune a bazei de date.
- Adugarea de funcionaliti orientate obiect unui sistem de gestiune a bazei de
date relaional. ntr-o astfel de situaie se conteaz pe instrumentele, tehnicile i
experiena vast a tehnologiei relaionale care pot fi folosite pentru a reconstrui
un nou sistem de gestiune a bazelor de date. Pot fi adugai pointri (pointers) la
tabelele relaionale legndu-le de Obiectele mari lineare (BLOB Binary Large
Object).
- Regndirea n totalitate a arhitecturii sistemelor de gestiune a bazelor de date i
producerea unei noi arhitecturi care s fac fa noilor tehnologii orientate obiect.
Conform acestei variante se are n atenie sporirea substanial a performanelor
de ordin fizic a bazelor de date comparativ cu modelul relaional n ceea ce
privete stocarea informaiilor complexe.
7.6. Modelul conceptual al datelor obiect

(CDOM)
Modelarea reprezint un proces de abstractizare a mediului nconjurtor n scopul
simplificrii nelegerii i redrii mai facile a acestuia.
Abstractizarea presupune ignorarea anumitor aspecte considerate nesemnificative
n favoarea reinerii a celor mai interesante i reprezentative.
Mediul nconjurtor poate fi considerat ca un sistem, subsistem sau parte a
acestuia.
Pentru modelarea unor realiti, activiti, procese sau fenomene economice din
domeniul de interes se recurge la utilizarea a diferite metode, tehnici sau instrumente,
cum ar fi:
- utilizarea anumitor tipuri de diagrame sau grafice ;
CODM The Conceptual Object Data Model

129
Capitol 7
-
prezentarea textual a problematicii de referin;

redarea fenomenelor i proceselor economice n limbaje formale;
sintetizarea i redarea aspectelor de interes sub form de scheme logice etc.
n contextul sistemelor informatice n general, i n special al bazelor de date, se

poate recurge la modelarea i implicit elaborarea a o serie de modele, cum ar fi:
- Modelarea domeniului (The Domain Model),
- Modelarea proceselor de afaceri (The Business Process Model),
- Modelarea structurii statice a sistemului (The Static Model),
- Modelarea dinamicii sistemului (The Dynamic Model),
- Modelarea datelor (The Date Model).
Remarcm faptul c modelarea tuturor aspectelor amintite anterior se refer la
acelai sistem, ns prin fiecare tip de model se urmrete satisfacerea cerinelor
informaionale de interes a unei anumite categorii de utilizatori. Pentru a modela astfel de
procese sau activiti, in concepia abordrii orientate obiect, n cele ce urmeaz vom
evidenia i defini conceptele cu care se va opera n ideea realizrii acestui scop. Acest
lucru se va face n contextul UML (Unified Modeling Language).
7.6.1. Conceptul de obiect

Un obiect este o entitate cu un rol bine definit n sistem, caracterizat de
proprieti, stare, comportament i identitate. La modul general, prin obiect vom nelege
ceva asupra cruia se poate ntreprinde o aciune, sau care poate declana / efectua o
aciune.
Exemplu: persoan, main, factur, contract, salariat, chitan cas etc. Obiectul
poate fi concret (o entitate tangibil i vizil, de exemplu o persoan, o mas, o floare
etc.), o entitate abstract (un concept, un eveniment, idee, un departament etc.) sau un
artifact al procesului de proiectare (de exemplu, interfa cu utilizatorul, control,
planificare).
Proprietile unui obiect sunt date de atributele prin care se descriu caracteristicile
obiectului respectiv. Starea unui obiect este dat de valorile pe care le iau proprietile
sale la un moment dat.
Comportamentul arat modul n care un obiect acioneaz sau reacioneaz la
evenimente. O operaie este o simpl aciune pe care o execut un obiect asupra altui
obiect pentru a primi un rspuns.
Multitudinea operaiilor pe care le poate efectua un obiect sau se efectueaz
asupra acelui obiect implementate ntr-un limbaj de programare poart denumirea de
metode, iar multitudinea metodelor se spune c definirea comportamentul obiectului de
referin. Un obiect i expune comportamentul prin intermediul operaiilor care i pot
afecta starea.
S considerm cazul unui student ION, reprezentat de un obiect. Obiectul student
are urmtoarele atribute: nume, data-naterii, adresa i telefonul. Starea obiectului este
dat de valorile asociate acestor atribute: ,,ION, ,,23-03-85, ,,Mihai Braun
nr.6, ,,4438601. Comportamentul studentului este dat de operaii cum ar fi: schimbaredomiciliu, schimbare telefon, trecerea ntr-un nou an de studii etc.
130

Toate obiectele au o identitate, astfel c nu exist dou obiecte identice. Dac
exist dou obiecte (instante) de tip student cu aceleai valori asociate atributelor
(aceleai nume, aceeai adres, acelai telefon i aceiai dat de natere) este vorba,
totui, de dou obiecte diferite. Chiar dac obiectele au valori identice ale atributelor, ele
au identiti diferite. Un obiect i pstreaz identitatea de-a lungul existenei sale.
Exemplu, dac studentul ION se cstorete sau i schimb domiciliul, el va fi
reprezentat de acelai obiect.
n mod formal un obiect reprezint o pereche de forma Oid, Val, unde Oid
este identificatorul obiectului, iar val este o valoare aparinnd obiectului. Valoarea
Val poate lua una dintre urmtoarele forme:
- Valoarea primitiv. Un membru de tip de dat Integer, String, Float sau Boolean;
exemplu: ,,B 54 PDD;
- Valoare referin. Un OID a unui obiect, exemplu: 123;
- Valoare tuplu de forma A1 : v1 , , An : vn , unde A1 , , An sunt nume de
atribute distincte i v1 , , vn sunt valori asociate atributelor;
- Set de valori, de forma v1 , , vn unde v1 , , vn sunt valori. Exemplu , numere
de telefoane ale unei persoane: 021-3348601, 021-1234567.
Exemplu: presupunem un obiect, din cadrul sistemului bancar romnesc, BCR, cu
urmtoarea descriere:
( 11, [cod fiscal: 123456,
Denumirea: BCR,
Preedinte: Rdulescu,
Nr. telefon: 021-1234567, 021-7654321,
Sucursale: 333, 444, 555, 666,
Localitate: Bucureti])
unde:
- simbolul 11 reprezint OID-ul obiectului cu denumirea BCR;
- ntre paranteze drepte [ ] se definesc atributele cu valorile asociate acestora, ele pe
ansamblu reprezentnd o valoare a tupului;
- ntre parantezele acolade , se specific seturi de valori cum sunt numerele de
telefoane i OID-urile sucursalelor bncii;
- referinele ctre sucursalele ce aparin bncii mam-BCR, sunt precizate prin
OID-urile acestora 333, 444, 555, 666.
Obiectele pot fi simple sau complexe. Un obiect simplu apare ca un articol sau
entitate din mediul nconjurtor ce nu poate fi descompus sau nu se justific
descompunerea acestuia; el este tratat ca un ntreg.
Exemplu: persoana, porumbel, medicament etc. Un articol complex apare ca o
entitate sau articol din mediul nconjurtor care este privit ca un singur obiect ns acesta
se poate combina cu alte obiecte printr-un set de relaii, cum ar fi: B este parte a lui A
sau A este format din B, C, D . Obiectele B, C, D, coninute de A, la rndul lor pot
fi complexe, ceea ce n final face s asistm la o ierarhie de obiecte. Exemplu, un obiect
131
Capitol 7
complex, Automobil poate fi privit ca un obiect format dintr-o serie de componente
care la rndul lor sunt privite ca obiecte, de forma (figura 7.1).
Gruparea obiectelor n cele dou categorii prezint interes cel puin sub aspectul
manipulrii obiectului coninut. Un obiect coninut poate fi manipulat n dou moduri.
ntr-un prim mod, obiectul coninut poate fi ncapsulat n obiectul complex i astfel
formeaz o parte a acestuia. ntr-o astfel de situaie, structura obiectului coninut
reprezint o parte a structurii obiectului complex, iar obiectul coninut poate fi accesat
numai cu metodele obiectului complex. n al doilea mod, un obiect coninut poate fi
considerat ca avnd o existen independent de cea a obiectului complex. n acest caz, n
obiectul printe nu este stocat direct obiectul membru, ci doar identificatorul su OID.
Obiectul coninut are structura i metodele lui proprii i poate fi deinut de diverse obiecte
printe.
AUTOMOBIL
ROI
MOTOR
PISTOANE
CILINDRII
ASIU
BUJII
Fig. 7.1. Obiect complex
7.6.2. Identificatorii obiectelor

Aa dup cum s-a mai precizat, fiecare obiect are o identitate unic i stabil,
numit identificatorul obiectului OID (Object Identifier), care este independent de
valoarea actual a obiectului.
OID-ul este generat de ctre sistem i atribuit obiectului n momentul
crerii/ncrcrii bazei de date. El este invizibil pentru utilizatori, independeni de valorile
atributelor sale i stabil pe toat durata de existen a obiectului i chiar mai mult dect
att, dac obiectul respectiv este ters din baza de date OID-ul acelui obiect nu se atribuie
ulterior unui alt obiect.
Observm asemnarea i deosebirea dintre OID i cheia primar a unei relaii. Ca
i OID-ul cheia primar ofer posibilitatea identificrii unice a oricrui tuplu/obiect, ns
valoarea cheii primare este unic doar la nivelul unei tabele i nu la nivelul ntregului
sistem ca i OID-ul, iar pe de alt parte, valoarea cheii primare poate fi schimbat n timp.
Exemplu, presupunem un obiect automobil avnd cheia primar numrul de
nmatriculare n circulaie. Totodat presupunem faptul c proprietarul vinde
132

automobilul unei alte persoane. Cu aceast ocazie poate fi schimbat numrul de
nmatriculare, deci implicit valoarea cheii primare, dei automobilul rmne fizic
acelai i chiar n aceiai baz de date la poliie. n contextul bazelor de date orientate
obiect OID-ul automobilului rmne acelai doar c se schimb proprietarul.
Faptul c OID-ul este unic la nivelul ntregului sistem i invariabil n timp
prezint o importan deosebit sub aspectul asigurrii mai facile a integritii entitilor
i a celor refereniale.
Dac n urma tergerii unui obiect din baza de date OID-ul acelui obiect ar fi
atribuit unui alt obiect, o referin anterioar la OID-ul obiectului ters s-ar putea
menine, ns de aceast dat OID-ul referit ar aparine unui alt obiect. Deci n realitate nu
ar fi respectat i meninut integritatea referenial. Exemplu: presupune o relaie
referenial ntre obiectul Parinte i Copil. Dac Printele unui copil ar fi ters din
baza de date i OID-ul acestui ulterior ar fi atribuit altui Printe, n contextul posibil de a
se menine relaia referenial s-ar ajunge la situaia n care un copil ar aparine unui alt
printe dect cel iniial declarat.
O alt problem ce merit a fi prezentat, izvorete din faptul c identificatorii
OID ca mecanism pentru identitatea obiectelor sunt independente de coninut, n sensul
c identificatorii OID nu depind n nici un fel de datele coninute n obiect. ntr-o astfel
de situaie, dou obiecte pot prea utilizatorului aceleai (ele avnd toate valorile
atributelor aceleai) i totui au identificatori OID diferii, fiind astfel obiecte diferite.
innd seama de faptul c identificatorii OID sunt vizibili pentru utilizatori, atunci ne
ntrebm cum poate distinge utilizatorul aceste dou obiecte? Dintr-o astfel de stare
putem desprinde concluzia c sunt nc necesare cheile primare, pentru a permite
utilizatoului s disting obiectele.
n ncheierea acestui paragraf, facem precizarea c exist o serie de mecanisme,
tehnici i algoritmi pentru identitatea obiectelor, cum ar fi: identitatea obiectelor bazate
pe valoare, identitatea folosind numele variabilelor i pointerii sau adresele de memorie
virtual, identificatoi OID logici i fizici, tehnici de mixare a pointerilor etc. Despre astfel
de probleme, i chiar mai multe, cei interesai pot consulta o serie de alte materiale [1, 2,
3, 4].
7.6.3. Atribute proprieti ale obiectelor

Fiecare obiect din mediul nconjurtor comport o anumit descriere ce se
realizeaz cu ajutorul atributelor. Multitudinea atributelor prin care se descrie un obiect
definesc proprietile acelui obiect.
Atributele pot fi simple sau complexe, care la rndul lor pot fi refereniale, de
colecii i derivate.
Pentru exemplificarea ne vom referi la descrierea a dou entiti, astfel (figura
7.2.):
DEPARTAMENT
1,
are
1.1
apartine de
DEPARTAMENT:
133
SALARIAT
Capitol 7
Denumire: STRING;
Cod - dep: INTEGER;
ef - dep: SALARIAT;
Nr. telefoane: SET [STRING];
Angajai: LIST [SALARIAT]
SALARIAT:
Marca: INTEGER;
Nume: STRING;
Prenume: STRING;
Profesia: STRING;
Data-naterii: DATE;
Funcia: STRING;
Loc-munc: DEPARTAMENT
Fig. 7.2. Exemple de atribute
Atributele simple pot fi un tip de date atomic, care include tipurile de date clasice
prezente n limbaje de programare, cum ar fi: ntreg real, boolean iruri de caractere. n
exemplul din fig. ., denumire, cod-dep, marca, funcia pot fi considerate ca atribute
simple.
Atributele refereniale sau de asociere, sunt folosite pentru a defini relaii
refereniale ntre obiecte. Ele sunt echivalente pointerilor din limbajele de programare sau
cheilor externe n cazul sistemelor relaionale, ns prezint i diferene importante, astfel:
- Contrar pointerilor, atributele refereniale sunt incoruptibile sau nealterabile, n
sensul c dac obiectul referit a fost ters din baza de date atunci atributul
referenial n mod automat va fi invalidat;
- Contrar cheilor externe, atributele refereniale nu sunt asocieri de valori vizibile
utilizatorilor. n exemplul nostru din figura 7.2., atributele Sef-dep: SALARIAT
i Loc-munc: DEPARTAMENT sunt atribute refereniale.
Atributele colecii fcnd parte din categoria atributelor complexe pot fi la rndul
lor grupate n seturi, liste i tablouri de valori.
Atributele colecii vor conine fie valori ale atributelor simple fie referine.
n exemplul din figura 7.2. Nr.-telefoane este un atribut de tip SET i va conine
multitudinea numerelor de telefon pe care le are un Departament, iar Angajai este un
atribut de tip LIST i va conine ca valori multitudinea identificatorilor OID ale
Salariailor ce lucreaz ntr-un anumit Departament.
Atributele derivate le mai regsim i cu denumirea de atribute de proceduri.
Uneori, n practic, in loc de a stoca n mod explicit valoarea unui atribut, este de preferat
de al determina sau calcula printr-o procedur oarecare i apoi a-l da disponibil i a-l face
cunoscut celor interesai. Pe considerentul c valoarea unui atribut derivat se determin
printr-o metod de tip procedur sau funcie, atributul respectiv mai poart denumirea
de atribut procedur. n exemplul nostru de referin nu apare un atribut derivat, ns ar
putea fi definit unul cu denumirea sugestiv Vrsta salariatului. ntr-o astfel de situaie
Vrsta ar putea fi determinat cunoscnd Data-naterii i apoi prelund data curent de
sistem. Prin diferen se obine vrsta.
134
7.6.4. Tipuri i clase de obiecte

7.6.4.1. Tipuri de obiecte
n literatura de specialitate nu exist o unanimitate de preri cu privire la definirea
i semnificaia conceptelor de tipuri i clase de obiecte. Astfel, ntlnim situaii n care
unii autori folosesc doar conceptul de tipuri, ali de clas iar o alt categorie folosesc att
conceptul de clas ct i conceptul de tipuri, aa dup cum se va putea vedea n cele ce
urmeaz.
R.G.G. Catell [10] folosete doar conceptul de tip dei recunoate i conceptul de
clas, ns pentru a nltura anumite ambiguiti n lucrare, renun la folosire termenului
de clas, acesta avnd cel puin urmtoarele semnificaii:
- O clas definete un tip care este o intensie, adic structura i comportamentul
obiectelor de un tip particular. Conceptul de tip este folosit pentru a proiecta o
intensie. Intensia va regrupa structura (atributele i relaiile obiectului) precum i
comportamentul (metodele asociate tipului);
- O clas definete o extensie, adic un ansamblu de obiecte de un tip particular;
- O clas la rndul ei poate fi considerat ca fiind tot un obiect sau meta-obiect
dispunnd de atribute, relaii i metode proprii. Aceste proprieti, relaii i
metode au semnificaie doar la nivelul ntregii clase i nu la nivelul obiectelor ce
fac parte din clas. Exemplu, un atribut avnd semnificaia de suma valorilor
tuturor factorilor din clasa FACTURI, are semnificaie doar la nivelul ntregii
clase de obiecte i nu la nivelul fiecrui obiect.
R.G.G. Catell pentru a defini conceptul de tip recurge la o analogie cu modelul
relaional, considernd c tabelele din modelul relaional sunt definiri de tipuri iar
tuplurile (liniile) unei tabele sunt instane de tupluri.
Thomas Connolly [81] precizeaz c, adesea, n literatura de specialitate, termenii
de tip i clas sunt sinonimi, cu toate c anumii autori fac o distincie ntre ei, aa
cum se va preciza n continuare. Un tip corespunde noiunii de tip de date abstract [ ]
Attkinson i Buneman, [1989]. Pe de alt parte, o clas definete modul de creare a
obiectelor i formeaz metode care pot fi aplicate acestora. n acest mod o clas se refer
mai degrab la modul de implementare a proprietilor i comportamentului obiectelor.
ntr-un astfel de context, pe parcurs au fost create dou modele de sisteme de gestiune a
bazelor de date orientate obiect, astfel:
- unele care folosesc ca termen de baz clasa, dintre care amintim Smalltalk, Orion,
ITASCA, Object Store, Vision etc.;
- altele care folosesc ca termen de baz conceptul de tip, dintre care amintim:
Versant, Ontos, Simula, O2 etc.
O astfel de situaie o ntlnim i la nivelul limbajelor de programare. De exemplu,
limbajul C++ folosete conceptul de clas, pe cnd SQL3 recurge la utilizarea
conceptului de tip. n acest fel definirea tipului n SQL3 este similar cu definirea
simplificat a clasei n C++.
Susintorii i realizatorii lui SQL3 folosesc conceptul de tip preferabil celui de
clas pe considerentul c cel din urm a fost suprancrcat pentru a se referi la un tip
sau la o colecie de instane de un anumit tip.
135
Capitol 7
Din cele constatate se pare c exist o mare majoritate de autori care consider c
tipurile i clasele de obiecte sunt nrudite (legate) ns concepte distincte. Din aceast
categorie amintim civa [Michael Kifer, Pool Alzeni ]
ntr-o baz de date orientat obiect tipurile permit definirea proprietilor
obiectelor, att cele statice (descrierea structurii obiectelor) ct i dinamice (descrierea
comportamentului obiectelor ca metode aplicabile obiectelor). Referitor la partea static a
tipurilor, aceasta este construit utiliznd constructorii de tip i un set larg de tipuri de
date atomice, care includ tipurile de date clasice prezente n limbajele de programare,
cum ar fi: ntreg, real, boolean i iruri. Tipurile de date atomice includ i identificatorii
de obiecte (OID).
Constructorii de tipuri permit definirea tipurilor numii tipuri de date complexe,
care dicteaz structura instanelor (numite obiecte complexe) a unei baze de date obiect.
Reprezentarea unui tip se face conform unei expresii de forma:
[CNP: integer, Nume: String, Nr. telefon: string, copii: PERSOANA]
Aceast definire de tip precizeaz faptul c atributele: CNP accept valori de tip
integer, Nume accept valori din domeniul primitiv string (ir de caractere), Nr.
telefon trebuie s ia valori ce sunt set de iruri de caractere, iar valorile atributului
copii sunt seturi de obiecte ce aparine clasei PERSOANA. Totodat, se poate observa
c expresia anterioar descrie un tip (model) n care structuri complexe pot fi incluse n
interiorul altor structuri. De exemplu, valorile pentru Nr. telefon sunt seturi de valori
primitive, n timp ce valorile pentru copii sunt seturi de obiecte provenite din clasa
PERSOANA.
n mod intuitiv se poate deduce faptul c, tipul unui obiect este tocmai colecia
tipurilor componentelor acestuia. Constructorii tip permit definirea de tipuri numite tipuri
de date complexe, care dicteaz structura instanelor numite obiecte complexe a unei baze
de date obiect. Mai precis, o definire recursiv a tipurilor de date complexe
corespunztoare structurii obiectelor complexe, bazat pe constructori de tip, apare astfel:
- tipuri de baz (valori primitive): ntreg, ir, real i boolean; exemplu: B10XYZ
ar putea fi valoarea asociat atributului numrului de nmatriculare n circulaie a
autovehiculului descris astfel Nr. MAINA: STRING;
- tipuri referin: Numele claselor definite de utilizator, cum ar fi SALARIAI i
ECONIMITI, unde ECONOMITII refer SALARIAII, sau un alt exemplu ar
pute fi de forma unui OID al unui obiect.
- tipuri set i liste: Constructorii de tip SET i LISTE permit definirea de tipuri ale
cror instane sunt colecii de valori (posibil complexe) de acelai tip. Seturile
sunt colecii neordonate ce nu accept duplicri, iar listele sunt colecii ordonate
cu posibile duplicri. Valorile din cadrul setului pot fi de orice tip. n exemplul
anterior au fost ntlnite urmtoarele seturi:
Nr. telefon: string, reprezint un set de iruri de caractere cu
semnificaia c stocheaz multitudinea numerelor de telefoane pe care le
are o persoan, de forma: 040-021-334861, , 040-021-3359211;
Copii: PERSOANA, reprezint un set de obiecte aparinnd clasei
PERSOANA.
136

-
tipuri nregistrare / tuplu: un constructor nregistrare permite definirea de tipuri a

cror instane sunt tupluri de valori de diferite tipuri posibile. Constatm faptul c
i n aceast privin unii autori folosesc doar conceptul de constructor tuplu nu i
nregistrare [40], ns sub aspectul formalizrii matematice lucrurile sunt foarte
apropiate. Dac T1, , Tn, sunt denumiri de tipuri i A1, , An sunt denumiri de
atribute distincte, atunci: T = nregistrare de [A 1:T1, , An:Tn] este un tip
nregistrare.
Deosebirea dintre cele dou alternative se observ doar la nivelul limbajelor de
definire a datelor, n funcie de specificul acestora.
Exemplu:
[CNP: ntreg, Nume: string, An-studii: integer, Adresa:
[Localitate: string, Strada: string, Numr: integer]]
Aceast definire reprezint un tip nregistrare (RECORD) n care primele trei
componente (atribute) au tipuri de date de baz, iar al patrulea (Adresa) este de tip tuplu.
Deci, se poate constata faptul c avem de a face cu un tip tuplu n cadrul cruia apare un
subtip tuplu Adresa, n mod intuitiv se poate desprinde concluzia c puteam avea de a
face cu subtipul i supertipuri de date complexe, corespunztoare obiectelor complexe.
Totodat precizm faptul ca n mod obinuit n cele mai multe sisteme obiect o definire
de tip de dat are constructorul nregistrare (RECORD) la nivelul cel mai nalt.
Din punctul de vedere al bazelor de date orientate obiect, o clas poate fi
considerat ca un tip nregistrare constnd din metadata care asigur ntreaga informaie
necesar pentru a construi i a folosi un anume obiect. Totodat e posibil de a considera
instanele unei clase ca fiind nregistrri stocate ntr-un fiier. Noile nregistrri avnd
diferite valori pot fi adugate n fiier. Un dicionar de date pentru SGDB poate conine
descrieri a mai multor tipuri diferite de nregistrri, fiecare cu un set diferit de atribute,
aa dup cum se va putea constata i n exemplul ce urmeaz.
Pentru exemplificare vom considera un obiect complex referitor la structura unei
Universiti, unde:
- O universitate poate avea cel puin dou faculti regsite n aceeiai localitate cu
sediul Universitii sau n localiti diferite;
- O facultate poate avea sau nu specializari pe secii;
- n cadrul unei Universiti pot exista unul sau mai multe laboratoare pe care le pot
folosi oricare dintre faculti, dac prezint interes i exist un acord n acest sens;
- La nivelul unei Universiti pot exista una sau mai multe biblioteci, amplasate
ntr-un singur corp sau n mai multe corpuri de cldiri;
- Catedrele ca departamente, din punct de vedere administrativ i al coordonrii
acestora sunt arondate facultilor;
- O Universitate dispune de un corp didactic propriu, organizai pe Catedre de
specialitate;
- Un profesor poate preda una sau mai multe discipline la o facultate sau la mai
multe faculti.
n situaia n care la nivelul Ministerului nvmntului i Cercetrii ar prezenta
interes proiectarea unei baze de date care s permit evidenierea multitudinei unitilor
137
Capitol 7
de nvmnt superior din Romnia, precum i a altor aspecte, necesare elaborrii unor
studii de analiz, prognoze, evaluri comparative etc., diagrama claselor de obiecte ar
putea fi redat astfel (figura 7.3.).
Pe baza diagramei claselor de obiecte, se poate trece la definirea structurii bazei
de date orientate obiect, ns ne vom limita doar la o parte a acesteia, astfel (figura7.4.).
Universitate: racord of (
Denumire:
Nume-rector:
Adresa:
Faculti;
Secii:
Biblioteci:
string,
string,
record of (
Ora: string,
Strada: string,
Nr,: string)
set of (
record of (
Denumire: string
Nume decan: string
Ora: string))
set of (
record of (
Denumire: string
Nr - studeni: string))
set of (
record of (
Corp - cldire: string
Profil: string
Bibliotecari: set of (
record of (
Nume: string
Studii: string))]
Fig. 7.4. Exemplu de definire de tip de obiect complex

Asociind valori compatibile cu definirea tipului, situaia ar putea apare de forma:
I1: [ASE, Brbulescu, [Bucureti, Piaa Roman, 6]
[CSIE, Popescu, Bucureti, Informatic, 600], [Cibernetic, 500],
[Statistic, 500], [Economie, 400],
[Dorobani 2700, Informatic, [Dan, superioare], [Vasile, medii] ],
[Eminescu 1000, Management, [Barbu, superioare], [Tudor,
medii] ]]
unde:
- nregistrrile sunt definite prin paranteze drepte iar seturile prin acolade;
- I1 reprezint o instan din cadrul definirii tipului de obiect complex.
138

CARTE
CITITOR
mprumutat de
0,
1,
gestioneaz
gestionat de
ofer carte
BIBLIOTECAR
1,
are
1,
PROFESOR
1,
angajat la
1,1
BIBLIOTECA
1,
dispune de
1, are
solicit carte
1,
are
1,*
se afl n
1,
aparine de
1,1
1,1 aparine de
dispune de
1,
UNIVERSITATE
este la 1,1
LABORATOR
0,
dispune
de
aparine de
1,1
CATEDRA
coordonate de
1,1
coordoneaz
1,
folosete
folosit de
FACULTATE
1,
1,2
urmat de
urmeaz
1,1
100,
specialist n
SECIE
STUDENT
specializeaz
25,
are 10,
1,* predatla
1, frecventeaz
CURS
frecventat de
Fig. 7.3. Diagrama claselor de obiecte

139
25,
Capitol 7
De remarcat faptul c un obiect poate include referiri explicite la un alt obiect, pe
baz de OID (Object Identifications). Incluznd referiri n structura din figura 7.4., noua
definire de tip obiect complex va apare astfel (figura 7.5):
Universitate: record of
(Denumire: string,
Nume-rector: string,
Adresa: record of (
Ora: string,
Strada: string,
Numr: integer),
set of ( Faculti),
set of (Biblioteci))
Faculti:
Biblioteci:
Faculti: record of
(Denumire: string,
Nume-decan: string,
Ora: string
Secii: set of ( Secii))
(Denumire: string,
Nr - studeni: integer),
(corp cldire: string,
Profil: string,
Biblioteci: set of ( Bibliotecari))
(nume: string,
studii: string)
Secii: record of
Biblioteci: record of
Bibliotecari: record of
Fig. 7.5. Exemplu de definire implicnd i referine de obiecte

Un set de instane pentru definirile de mai sus, implicnd i referinele la alte
obiecte, apare astfel (fig. 7.6.):
01:
02:
03:
04:
05:
06:
07:
08:
09:
10:
11:
12:
13:
<OID1,
<OID2,
<OID3,
<OID4,
<OID5,
<OID6,
<OID7,
<OID8,
<OID9,
<OID10,
<OID11,
<OID12,
<OID13,
[ASE, Brbulescu, [Bucureti,Piaa Roman, 6], OID2, OID7]>

[CSIE, Bucureti, OID3, OID4m OID5, OID6]>
[Informatic, 600] >
[Cibernetic, 500] >
[Statistitic, 500] >
[economie - matematic, 400] >
OID8, OID11>
[Dorobani - 2700, Informatic, OID9, OID10],
[Dan, superioare] >
[Vasile, medii] >
[Eminescu, Management, OID12, OID13],
[Barbu, superioare] >
[Tudor, medii] >
Fig. 7.6. Exemplu de instan n care apar i referiri
140
7.6.4.2. Clase de obiecte

Multitudinea obiectelor ce se bucur de aceleai proprieti i comportament
formeaz o clas de obiecte.
Obiectele din cadrul unei clase constituie instanieri ai clasei respective. n UML
o clas se reprezint printr-un dreptunghi cu trei compartimente separate prin linii
orizontale: numele clasei n primul compartiment, lista de atribute n al doilea
compartiment i lista de operaii n al treilea compartiment.
Diagrama claselor indic structura static a modelului orientat obiect, surprinznd
clasele componente i relaiile dintre acestea. n figura 7.7. sunt reprezentate clasele
STUDENT i CURS.
O diagram de obiecte este un graf de instane compatibile cu o diagram de clase
dat. ntr-o diagram de obiecte, un obiect este reprezentat de un dreptunghi cu dou
compartimente. Numele obiectului este dat sub forma numeobiect: numeclasa, unde
numeobiect poate lipsi.
Student
Curs
- Nume
- Data Natere
- Adres
- Telefon
- Cod
- Denumire
- Sala
- Ora
+ schimb-adresa ( )
+ nregistrare la curs ( )
+ nscrierecurs ( )
Fig. 7.7. Exemplu de clase

n figura 7.8. este reprezentat diagrama de obiecte asociat diagramei claselor de
mai sus.
Ion: Student
Curs
- Nume = Ion
- Data Natere = 23-03-1981
- Adres = Bd. Magheru nr.5
- Telefon =4646306
- Cod = 22
- Denumire = Multimedia
- Sala = 2314
- Ora = 12.00
Fig. 7.8. Exemplu de instane

Clasele joac acelai rol n CODM (Conceptual Object Data Model) ca i relaiile
n baze de date relaionale (BRD). n modelul relaional baza de date este format dintrun set de relaii i fiecare relaie include un set de tupluri iar in CODM o baz de date este
format dintr-un set de clase i fiecare clas include un set de obiecte. Aadar n BDR
putem avea o relaie numit STUDENT cu tupluri coninnd informaii despre fiecare
student iar in CODM putem avea o clas STUDENT cu obiecte coninnd informaii
despre fiecare student. ntr-o astfel de situaie apare posibilitatea convertirii unei baze de
141
Capitol 7
date relaionale ntr-o baz de date orientat obiect cu ataarea unui OID fiecrui tuplu i
invers.
O clas are un tip, care descrie structura comun a tuturor obiectelor ce fac parte
din aceiai clas, i semnturi de metode, care sunt declaraii de operaii ce pot fi aplicate
clasei de obiecte. De remarcat faptul c numai semnturile metodelor sunt parte a
CODM, implementrile nu sunt. Implementarea unei metode este o procedur scris ntrun limbaj gazd, ce este memorat pe serverul bazei de date.
Multitudinea obiectelor ce aparin unei clase formeaz un set de obiecte i
constituie extensia (extent) clasei. [Michael Kifer, Arthur, Datey].
ntr-un astfel de context, prin analogie, se poate spune c o clas are rolul de
container de obiecte n / din care obiectele n mod dinamic pot fi adugate sau terse.
n limbajele de definire a datelor (DDL) ex. n O2 definirile tipurilor sunt incluse
ca parte a definirilor claselor de obiecte.
n general, definirea unei clase este separat n dou pri, i anume, partea de
interfa i partea de implementare.
- interfaa descrie tipul obiectelor aparinnd clasei, care include semnturilor
tuturor metodelor. Fiecare semntur conine denumirea i tipul fiecrui
parametru a metodei. Parametrii de intrare / ieire n / din metod fac posibil
invocare metodei n cadrul programelor de aplicaii.
- implementarea descrie implementarea metodelor adic, transpunerea operaiilor
ntr-un limbaj de programare.
Interfaa descrie numai operaiile aplicabile asupra obiectelor n timp ce
implementarea ascunde programul corespunztor operaiilor. De remarcat faptul c unele
SGDBOO ofer posibilitatea abaterii de la interpretarea strict a ncapsulrii permind
accesul de date i prin alte forme / interfee i nu numai prin intermediul metodelor, de
exemplu utiliznd limbajul de cereri.
Din cele prezentate se poate desprinde ideea c tipurile sunt abstractizri ce
permit att descrierea proprietilor (strilor) ct i comportamentul, n timp ce clasele
descriu att partea extensional a obiectelor ct i implementarea metodelor referitoare la
un tip. Tipul descrie proprietile abstracte n timp ce clasa descrie implementarea acelor
proprieti abstracte utiliznd structuri de date i programe.
Aa dup cum s-a mai artat i n paragrafele anterioare, unii autori de SGBDOO
sau de cri folosesc cu precdere conceptul de clas, alii conceptul de tip iar alii
utilizeaz ambele concepte, ele fiind nrudite ns distincte. Paolo Atzeni, Stefano Ceri,
Rcardo Torlone, Michael Kifer i Arthur Bernstein, se situeaz pe o astfel de poziie [
], preciznd c:
- tipurile i clasele sunt concepte distincte;
- fiecare clas este asociat la un singur tip;
- conceptul de clas descrie att implementarea ct i extensia unui tip;
- clasele ajut la organizarea obiectelor ntr-o categorie.
n figura 7.9 se sugereaz relaiile ntre clas, tip, obiect, valori, extensie, intensie
etc.
142
Clasa
conine
un set de
Obiecte
are un
extensie
Tip
intensie
au
descriere / atribute
Valori
Fig. 7.9. Relaia ntre clas i tip

Din figura 7.9 se poate desprinde concluzia c tipul, clasa, extensia i intensia
sunt nrudite ns diferite ca noiuni i semnificaie. Fiecare obiect are valori, asociate
unor atribute ce aparinnd unui tip. Fiecare obiect aparine unei clase care are un tip.
n cele ce urmeaz vom exemplifica modul de descriere a claselor de obiecte ce
includ i definirile de tipuri. n acest scop vom face referiri la clasele, tipurile i
conceptele redate n figurile 7.3., 7.4., 7.6 folosind limbajul O2, astfel :
add class Universitate
type tuplu (Denumire: string,
Nume rector: string
Adresa: tuplu (Ora: string,
Strada: string,
Numr: integer)
Faculti: set of (Faculti),
Biblioteci: set of (Biblioteci))
add class Faculti
Nume decan: string
Ora: string
Secii: set of ( secii)
add class Secii
Nr studeni: integer)
add class Biblioteci
type tuplu (Corp - cldire: string,
Profil: string,
Bibliotecari: set of ( Bibliotecari))
add class Bibliotecari
type tuplu (nume: string,
studii: string)
143
Capitol 7
De remarcat faptul c n O2 avem de a face, pe de o parte, cu schema bazei de
date, care include definirea proprietilor i metodelor claselor, iar pe de alt parte cu
baza de date propriu-zis ce include datele efective. In acest context prin comanda " add "
se adaug o clas la schema bazei de date, presupus c a fost declarat anterior.
7.6.5. Metode
7.6.5.1. Conceptul de metod i aspecte de ordin general
Aa dup cum s-a mai precizat, multitudinea operaiilor pe care le poate efectua
un obiect sau se efectueaz asupra acelui obiect implementate ntr-un limbaj de
programare poart denumirea de metode.
O metod are o semntur, care descrie parametrii metodei i include toate
informaiile ce permit invocarea acesteia i o implementare, care conine codul metodei
(programul corespunztor metodei), elaborat ntr-un limbaj de programare. Semntura
metodei este o component a definirii clasei de obiecte.
n general, fiecare metod este asociat unei clase specifice de obiecte. n acest
caz, metoda are ca inut (target) o anume clas de obiecte. Exist i sisteme ce permit
definirea de metode multi-int (multi-target), care se aplic la un numr arbitrar de
obiecte fr a favoriza vreunul ntr-un anumit mod. n acest caz, definirea acestora este
dat n mod separat de definirea clasei. Totodat, precizm faptul c fiecare metod are
un numr arbitrar de parametrii de intrare i un singur parametru de ieire.
Metodele corespunztoare operaiilor pe care le implementeaz pot fi grupate
astfel:
- metode constructor (operaii de tip constructor), destinate a crea o nou instan,
un nou obiect al clasei. De exemplu, n cla sa Student putem avea metoda
(operaia) CREAZ-STUDENT care creeaz un nou obiect de tip student i i
iniiaz starea. De remarcat faptul c toate clasele trebuie s aib o metod
constructor;
- metode destructor, folosite pentru tergerea / abandonarea obiectelor i posibil
altor obiecte legate de acestea;
- metode de regsire / accesare folosite numai pentru preluarea valorilor asociate
atributelor obiectului. Exemplu: pentru clasa STUDENT, metoda
CALCULEAZ-VRSTA studentului plecnd de la data naterii sale. O astfel de
metod nu afecteaz starea obiectului;
- metode de actualizare, folosite pentru actualizarea strii obiectului. Exemplu,
metoda posibil schimb adresa din clasa student are menirea de a actualiza /
modifica valoarea atributului adresa.
Metodele mai pot fi clasificate i n funcie de specificul cerinelor de aplicaii,
astfel:
- metode publice, ce reprezint particularitatea c pot fi apelate din oricare program
de aplicaie;
- metode private, ce prezint particularitatea c pot fi apelate numai din interiorul
altor metode ale aceleai clase.
144
7.6.5.2. Definirea semnturilor i implementarea metodelor

n cele ce urmeaz vom recurge la un exemplu de definire de semntur i
implementare a unei metode n O2. Totodat, facem precizarea c o baz de date O2 este
format din dou componente i anume: schema bazei i baza de date propriu-zis.
Schema conine informaii despre structura de date a fiecrei clase, atributele i metodele
ei, drepturi i privilegii de acces etc. Baza conine date actuale n concordan cu schema.
Procedura de lucru cu O2 prevede pentru inceput crearea schemei bazei de date,
de forma:
CREATE SCHEM denumire schema;
CREATE BASE
denumire baz;
apoi activarea schemei i bazei, de forma:
SET SCHEM denumire schema;
SET BASE
denumire baz;
Dup aceste operaii se poate trece la definirea claselor i metodelor
corespunztoare Schemei setate. Ulterior pot fi fcute noi adugri de clase de obiecte.
Presupunem ca dorim s adugm o metod init schemei bazei n care este
inclus Clasa Universitate, din figura 7.3. Definirea semnturii metodei va apare astfel:
add method init (Denumire par: string,
Nume rector par: string,
Ora par: string,
Strada par: string,
Numr par: integer)
in Class Universitate is public
iar definirea implementrii metodei init implic urmtoarea sintax:
Body method init
CO2
(Denumire par: string,

Nume rector par: string,
Ora par: string,
Strada par: string,
Numr par: integer)
in Class Universitate
self Denumire = Denumire par;
self Nume = Nume par;
self Ora = Ora par;
self Strada = strada par;
self Numr = Numr par;
return (sefl);$
Referitor la definirea semnturilor i implementrii metodelor, n cele ce urmeaz

vom cuta s facem anumite precizri.
145
Capitol 7
Metoda init face parte face parte din categoria metodelor constructor (de creare)
de clas; ea genereaz partea de stare a unui nou obiect creat n cadrul clasei Universitate.
Structura de definire a semnturii apare astfel:
Method den-metod p1 , p2 , , pn n class den-clasa
unde:
public
private
- partea mai pronunat reprezint cuvinte rezervate;

- p1, 2 , , p n reprezint parametrii actuali de apel.
n ceea ce privete partea de implementare a metodei, ea este precizat prin
cuvntul rezervat body i este scris n CO2 (o extensie a limbajului de programare C)
care permite accesul direct i transparent la obiectele stocate n baza de date. La nivelul
corpului metodei (body init) se precizeaz lista de parametrii, conform urmtoarei
sintaxe:
Body denn-metod d1 .d 2 , , d n in class den-clas
unde:
- partea mai pronunat reprezint cuvinte clasice;
- d1 , d 2 , , d n reprezint lista de parametrii formali de comunicare.
Implementarea este inclus ntr-un bloc de iniializare delimitat de cuvntul cheie
CO2 i terminat cu simbolul $.
Cuvntul self are semnificaia de variabil de adres ce indic obiectul clasei
int la care metoda se aplic. Cu alte cuvinte, invocarea unei metode pe un obiect dat
este similar cu trimiterea unui mesaj la acel object; self indicnd obiectul primitor,
adic obiectul ce va primi mesajul.
Simbolul este echivalent cu semnificaia punctului () folosit frecvent i n
alte limbaje de programare n scopul de a face o calificare de atribut/cmp, cu ocazia unei
anumite referire la acel atribut. Exemplul:
self Nume-persoan = Nume-paremetru
echivaleaz cu descrierea de forma:
self Nume-persoan = Nume-parametru
unde atributul / cmpul Nume-persoan de la variabila self este iniializat cu o valoare
dat de atributul / cmpul Nume-parametru.
Urmrind cele dou aspecte referitoare la metode i anume, semntura i
implementarea metodei, observm c ambele presupun precizarea unei liste de parametri.
Cu privire la cele dou liste de parametri pi i d i se pot face anumite precizri, astfel:
- parametrii pi poart denumirea de parametri efectivi sau actuali, respectiv
parametri d i poart denumirea de parametrii formali;
- o parte dintre parametrii efectiv i formali pot avea semnificaia de parametrii de
intrare pentru metod, iar, o parte pot fi parametrii de ieire prin care metoda
returneaz rezultatele;
146

-
cele dou liste ofer raportul pentru asigurarea comunicrii ntre semntur i
implementare, n sensul c prin listele de parametrii se transfera datele (valorile)
solicitate de metod;
corespondena dintre parametrii pi , i 1,2, , n i d i , i 1,2, , n , se face prin
locul ocupat n lista de parametri i nu prin numerele lor; ntr-o astfel de situaie
denumirile parametrilor pi i d i pot s coincid sau s difere, ns numrul
parametrilor n cele dou liste, precum i tipul lor trebuie s fie acelai.
Necesitatea acestei identiti rezult din faptul c numai parametrilor
pi , i 1,2, , n li se rezerv memorie, parametrii d i utilizeaz aceleai zone de
memorie ca i pi .
Invocarea metodei init, ntr-un program scris n CO2 apare astfel:
execuie CO2
O2 Universitate X;
X = new (Universitate);
[X init (ASE, Roca, Bucureti, Roman, 1)];$
unde:
execute CO2 marcheaz lansarea n execuie a metodei init;
pentru declararea variabilelor locale se folosete cuvntul cheie CO2;
linia a doua de program definete o variabil local cu denumirea X i un tip
Universitate;
linia a treia definete instruciunea de crearea a unui obiect ce aparine clasei
Universitate, invocnd totodat metoda new, metod valabil tuturor claselor
pentru crearea unui nou obiect i inserarea acestuia ntr-o clas corespunztoare;
instruciunea de pe linia final a metodei init aplicat la acel obiect, atribuie valori
iniiale proprietilor obiectului nou creat. Se poate observa c n apelarea metodei
se indic obiectul int i numele metodei, urmat de o list de valori actuale ale
parametrilor de intrare.
La sfritul execuiei metodei, obiectul pentru care metoda nsi este invocat
este returnat ca un parametru de ieire.
De remarcat faptul c n cadrul unei metode poate fi invocat i o alta metod,
existnd astfel posibilitatea de a genera invocri de lanuri de metode, cu precizarea c nu
este permis ca o metod s se invoce pe sine nsi n mod direct sau indirect.
7.6.5.3. Considerente de ordin practic cu privire la proiectarea

metodelor
Unul dintre principalele avantaje ale programrii orientate obiect l constituie
posibilitatea reutilizrii n mod facil a anumitor pri sau componente software. Dac
metodele vor fi definite /proiectate cu mare grij, atunci pri de programe sau programe
ntregi vor fi concepute o singur dat, ns vor putea fi incluse n metode i apoi folosite
de diverse aplicaii. Pentru a proiecta astfel de metode este de dorit s se in seama de o
serie considerente de ordin practic [Runbabgh 71], cum ar fi:
147
Capitol 7
-
Metodele trebuie s fie scurte; ele nu trebuie s depeasc circa dou pagini de
text. Metodele mai lungi este de preferat s fie descompuse;
Metodele trebuie s fie coerente i consecvente n folosirea notatiilor sau unui stil
comun de definire a denumirilor de variabile;
Metodele trebuie s constituie cerine anticipate pentru viitoarele aplicaii i chiar
mai mult dect att, ele nu trebuie s se limiteze la satisfacerea unor cerine
minimale pentru aplicaii curente ci ele vor fi mai largi, de o ntindere mai mare i
vor include cazuri generale.
Metodele vor fi independente. Ele vor folosi informaii definite local sau acceptate
ca parametrii, evitnd folosirea variabilelor globale;
Motenirea va fi folosit ct mai mult posibil. Este de preferat ca metodele s fie
definite n superclase i refolosite n subclase de obiecte.
7.6.6. ncapsularea i interfaa

Operaiile formeaz interfaa clasei pentru ca prin intermediul ei clasa i expune
altor clase funcionalitatea fr s i dezvluie structura. Aceast tehnic de ascundere a
detaliilor de implementare a unui obiect poart numele de ncapsulare. Se ascunde att
structura care memoreaz datele ct i implementarea operaiilor. Deci, pentru un
utilizator oarecare clasa de obiecte, sub aspectul coninutului informaional, apare ca o
cutie neagr. Utilizatorii au acces la date prin interfee sau mesaje. Interfaa nu este nimic
altceva dect un mesaj / stimul prin care se citeaz denumirea unei metode dintre
multiplele metode ale unei clase de obiecte. Deci, operaii care arat numai ceea ce face
obiectul, nu i cum face.
Denumirea unei metode reprezint tocmai denumirea unei proceduri elaborate
ntr-un limbaj de programare oarecare. Prin citarea denumirii metodei va fi lansat n
execuie programul care n derularea lui va accesa datele conform structurii clasei de
obiecte, figura 7.10.
FACTURA
mesaj
- Data-emiterii: Date
- Emitent: string
- Material: string
.
.
.
proprieti
+ Emite - factura()
+ ncaseaz - factura()
+ ncasare - parial()
+ Calculeaz - factura()
metode
Fig. 7.10. Exemplu de ncapsulare
148

Asupra metodelor i atributelor unei clase de obiecte pot fi instituite anumite
restricii de acces la ele, care mai poart denumirea de restricii de vizibilitate. n funcie
de modul de restricionare instituit, vizibilitatea poate fi: public, privat, i protejat.
Forma implicit de vizibilitate este public (PUBLIC), situaie n care vizibilitatea
i atributele sunt vizibile pentru toi utilizatorii autorizai, i se noteaz cu semnul (+).
Forma privat (PRIVATE) marcat prin semnul (-), restricioneaz n totalitate
vizibilitatea altor clase. Atributele i metodele sunt vizibile numai nuntrul clasei, ce
conine restricia.
Forma protejat (PROTECTED), notat cu simbolul (#), restricioneaz doar
parial vizibilitatea. Atributele i metodele protejate sunt vizibile att din interiorul clasei
n care se definesc ct i din toate celelalte subclase ce-i aparin.
Precizm i faptul c, o metod invocat poate invoca la rndul ei o alt metod
dintr-o alt clas, deci apeluri in cascad. Situaia este similar cu lucrul cu programe
principale i apelri de subprograme de tip Procedur sau Funcie, din alte limbaje de
programare.
7.6.7. Polimorfismul
Polimorfismul presupune faptul c un acelai mesaj poate fi adresat uneia sau mai
multor clase de obiecte primind rspunsuri diferite, cu semnificaii diferite. Exemplu,
presupunem drept mesaj comanda PRINT, din meniul de sistem. Ea va avea ca efect
imprimarea unei figuri geometrice dac se adreseaz unui fiier (prin analogie clase) de
figuri; va imprima un text preselectat dintr-un fiier de tip text etc.
7.6.8. Asocierile ntre clase

Legtura este o conexiune ntre obiecte. Asocierea reprezint descrierea unui grup
de legturi cu aceiai structur i semantic. Legturile sunt abstractizate n asocieri aa
cum obiectele sunt abstractizate n clase. Deoarece legturile dintre obiecte sunt instane
ale asocierii dintre dou clase, este util s se modeleze asocierile dintre clase i nu
legturile dintre obiectele acestora.
Asocierile prezint o serie de caracteristici, astfel:
Denumirea asocierii. O asociere dintre dou clase este reprezentat printr-o linie
care conecteaz dou clase (fig. 7.11). Denumirea asocierii, este de regul un verb
care se trece deasupra liniei, indicnd semnificaia asocierii, iar prin sgei se
precizeaz sensul asocierii. Denumirea trebuie s fie ct mai sugestiv.
Numeclasa
nume asociere
Numeclas
Fig. 7.11. Reprezentarea asocierii

n cele ce urmeaz vom enumera cteva exemplificri de verbe ce pot indica
asocierea ntre clase de obiecte.
149
Capitol 7
Categorie verb
A e parte fizic din
A e fizic coninut n
A e logic coninut n
A e o descriere pentru
A e un rnd dintr-un raport
A este membru a lui
A este o subunitate organizatoric a lui
A este subaltern a lui
A conduce
A comunic cu
A este legat la o tranzacie
A este o tranzacie n legtur cu o alt
tranzacie
A aparine lui
B
B
B
B
B
B
B
B
B
B
B
Exemple de asociere
salcurs
- corpcldire
elev
- clas / sal
sal
- orar
pagin web - pagin web Hotel
articol
- comand
juctor
- echip
atelier
- secie
angajat
- manager
ofer
- main
profesor
- student
pasager
- bilet
rezervare
- anulare
autoturism
- proprietar
Aceste exemplificri ajut n alegerea / definirea ct mai sugestiv a denumirii

asocierii.
Multiplicitatea asocierii. Multiplicitatea reprezint numrul de instane ale unei
clase care pot avea legturi cu o instan a celeilalte clase dintr-o asociere. Multiplicitatea
corespunde cardinalitii asocierilor n raport cu instanele claselor. Ea poate fi de mai
multe feluri i poate comporta multiple forme de notare. n continuare se redau dou
dintre acestea.
Varianta 1
A
1,1
0,1
0,
1,
O instan din clasa A are ntotdeauna n

coresponden o instan din clasa B (unu la
unu)
O instan din clasa A poate avea 0 sau 1

instane n corespondena din clasa B (unu la
zero sau unu)
O instan din clasa A poate s aib 0 sau N

corespondene de instane din B (unu la zero
sau mai muli).
O instan din clasa A poate avea 1 sau N

corespondene de instane din B (unu la unu
sau mai muli)
150

Multiplicitatea unei asocieri se exprim printr-un interval de valori de forma (x,y)
unde x reprezint valoare minim, iar y valoarea maxim.
Exemple:
Legtura de tipul unu la unu. Specificul legturilor de tipul unu la unu const
n faptul c fiecare instan are n coresponden obligatoriu o alt instan din clasa cu
care intr n asociere.
LOCALITATE
1,1
are
1,1
PRIMAR
Sugereaz faptul c o localitate poate avea unul i numai un singur primar, iar n
sens invers o persoan poate fi primar la una i numai o localitate.
Legtura de tipul unu la zero sau unu. Specificul acestui tip de legtur const
n faptul c o instan din clasa A poate sau nu corespunde unei instane din clasa B.
PERSOANA
1,
este nscris
0,1
PARTID
Sugereaz faptul c un partid politic poate avea mai muli membrii, ns o

persoan poate s nu fac parte din nici un partid, sau s fac parte din cel mult un partid.
Legtura de tipul unu la zero sau mai muli
are nscrii
0,
CURS FACULTATIV
0,
STUDENT
O altfel de legtur exprim faptul c la un curs facultativ poate s nu fie nscris

nici un student sau pot s fie mai muli studeni pentru frecventare.
Legtura de tipul muli la muli
MATERII PRIME
1,
sunt furnizate de
1,
FURNIZORI
Legtura de tipul muli la muli de mai sus exprim faptul c un material poate
fi livrat de unul sau mai multefurnizori iar un furnizor poate livra unul sau mai multe
materiale.
O multiplicitate de forma (2,5) semnific faptul c la realizarea legturii pot
participa minim 2 i maxim 5 instane dintr-o clas de obiecte. Cnd limita superioar a
intervalului este ,, nseamn c avem de-a face cu o limit superioar infinit.
151
Capitol 7
Varianta 2
B
O instan din clasa A are n coresponden o

instan din clasa B (unu la unu)
O instan din clasa A poate avea 0 sau 1

instane n corespondena din clasa B (unu la
zero sau unu)
O instan din clasa A poate s aib 0 sau N

corespondene de instane din B (unu la zero
sau mai muli).
O instan din clasa A poate avea 1 sau N

corespondene de instane din B (unu la unu
sau mai muli)
Tipul asocierii. Tipul asocierii este dat de numrul claselor participante la o

asociere exist mai multe tipuri de asocieri: unare, binare, ternare .a.m.d. Acestea pot fi
notate astfel:
Asocierea unar, presupune faptul c a o clas de obiecte intr n asociere cu ea
nsi. O astfel de asociere este recursiv.
Exemplu: Presupunem o clas numit PERSOANE, la nivelul unei societi
comerciale. n cadrul acestei clase poate fi definit o asociere cu denumirea
CSTORIE, astfel nct s se poat da rspuns la o ntrebare de genul ,,Care sunt
persoanele so soie ce lucreaz n aceeai societate comercial? O astfel de asociere
este redat n figura 7.12.
PERSOANE
0,1
0,1
so
soie
CSTORI
E
Fig. 7.12. Exemplu de asociere unar
Asocierea binar, presupune existena a dou clase de obiecte de forma (figura
7.13):
152
1,
SALARIAT
ANGAJAT IN
1,1
DEPARTAMENT
Fig. 7.13. Exemplu de asociere binar

Interpretarea asocierii din figura 7.13 apare astfel: un salariat poate fi angajat cel
puin ntr-un departament i cel mult ntr-un departament. n sens invers, ntr-un
departament pot lucra unul sau mai muli salariai.
Asocierea ternar, presupune existena a trei clase de obiecte. n figura 7.14 se
prezint forma generic a unei astfel de asocieri.
Nume clas 1
Nume
asocie
re
Nume clas 2
Nume clas 3
Fig. 7.14. Exemplu general de asociere ternar

Un exemplu pentru reliefarea asocierii ternare este prezentat n figura7.15
Client
mprum
u-t
Banc
Investiie
Fig. 7.15 Exemplu concret de asociere ternar

Asocierea ,,mprumut este o asociere ntre trei clase: Client, Banc i Investiie,
banca acordnd mprumutul unui client pentru o anumit investiie. Se observ c
asocierea ,,mprumut nu poate fi divizat n asocieri ntre dou clase fr a pierde din
informaie.
Rolul clasei n cadrul asocierii. Prin rol se indic semnificaia fiecrei clase n
cadrul asocierii. Numele de rol este un concept prin care se identific n mod unic
capetele unei asocieri. O clas, care are mai mult de o asociere, poate juca roluri diferite
fa de fiecare dintre acestea.
153
Capitol 7
Mijloc de
producie
Firm
Proprietar
Utilaj
deine
1,n
Garanie
1,n
Banc
Fig. 7.16. Evidenierea rolului fiecrei clase

n figura 7.16 se poate observa c un utilaj, din punct de vedere al bncii, poate
reprezenta o garanie, n timp ce din punct de vedere al firmei, el reprezint un mijloc de
producie. Numele de rol se reprezint prin intermediul unei etichete ataat captului
asocierii. Firma are rolul de proprietar de utilaj.
Atribute i clase ale asocierii. Cnd o asociere are atribute i operaii proprii, sau
cnd particip la asocieri cu alte clase, asocierea se modeleaz ca o clas i poart numele
de clas a asocierii (figura 7.17).
Asocierea dintre clasele mprumut i Banca este caracterizat de urmtoarele
atribute: suma mprumutat, data acordrii mprumutului, data rambursrii mprumutului,
dobnd i operaia de rambursare mprumut. Toate aceste atribute i operaii sunt
atribute i operaii ale asocierii i vor fi reunite n clasa mprumut; ele nu apartinin
totalitate nici clasei Client si nici clasei Banca ci aparin ambelor clase.
Client
1,
1,
Banc
mprumut
Sum mprumut
Data mprumut
Data rambursare
Dobnda
Rambursare ( )
Fig. 7.17. Exemplu de asociere cu atribute i operaii

Atribut derivat. Un atribut derivat este un atribut care poate fi calculat sau derivat
plecnd de la alte atribute. Un astfel de atribut se reprezint grafic prin simbolul / pus
n faa denumirii acestuia.
154

Student
Nume
Data Natere
/Vrsta
Fig. 7.18. Reprezentarea unui atribut derivat

n figura 7.18. atributul Vrsta este un atribut derivat al clasei Student, ntruct se
poate calcula plecnd de la atributul Data Natere i data curent.
Atribut al clasei. Obiectele se difereniaz ntre ele prin valorile pe care le iau
atributele lor la un moment dat, valori care constituie starea obiectului n acel moment. O
categorie special de atribute sunt atributele clasei.
Un atribut al clasei reprezint un atribut a crui valoare este comun clasei de
obiecte i nu unei instane specifice. Simbolul folosit pentru acest tip atribut este
caracterul $ plasat n faa denumirii atributului, aa cum se poate observa n figura 7.19
Factura
$ Nr.TotalFacturi
Fig. 7.19. Atribut al clasei

Clasa Factura, pe lng atributele specifice unei facturi cum ar fi data emiterii,
valoare fr TVA, TVA, valoare cu TVA etc., are i atributul NrTotalFacturi care este o
caracteristic a clasei i nu a instanei.
Ordonare. n cazul unei asocieri n care la unul din capete se specifica ,,muli,
setul de obiecte poate s nu fie ordonat (fiind ca un set de obiecte), sau poate fi ordonat
explicit. Mesajul ordonrii n cazul cnd acest lucru este important, se face prin
meniunea ordered lng semnul care indic multiplicitatea. Ordonarea este un tip
special de constrngere aplicabil asocierilor. S lum exemplul alctuit din clasele Ghieu
i Persoan (figura 7.20).
Ghieu
deservete
1,n
ordered
Persoan
Fig. 7.20. Ordonarea ntr-o asociere

Calificarea. Numim asociere calificat o asociere, care leag dou clase, i un
calificator, care are rolul de a reduce multiplicitatea efectiv a unei asocieri. Asocierile de
tipul ,,unul la multi i ,,muli la muli trebuie s fie calificate. Calificarea permite ca din
155
Capitol 7
multitudinea de obiecte aflate la captul ,,muli al asocierii s se identifice unic un
anumit obiect. Considernd exemplul alctuit din clasele Companie i Angajat, i
asocierea lucreazpentru, vom aveam o relaie ,,unu la muli; o companie are mai muli
angajai i un angajat nu poate lucra dect pentru o singur companie. Calificatorul
numeangajat permite reducerea asocierii ,,unu la muli la o asociere ,,unu la unu,
ntruct o companie i un nume angajat permit identificarea unic a unui angajat (figura
7.21):
COMPANIE
COMPANIE
lucreazpentru
1,n
numeangajat
lucreazpentru
ANGAJAT
ANGAJAT
Fig. 7.21. Calificarea asocierii
7.6.9. Motenirea
Motenirea este un mecanism ce d posibilitatea partajrii atributelor i operaiilor
utiliznd relaia de generalizare.Motenirea poate fi redat astfel: (figura 7.22.):
A
cu semnificaia c o clas B motenete de la o

alt clas A proprietile i comportamentul
B
Fig. 7.22. Motenirea
Motenirea poate fi simpl sau multipl. Motenirea simpl presupune faptul c o
subclas B motenete proprietile i comportamentul doar de la o singur superclas A
(este cazul din figura 7.22.).
Motenirea multipla presupune faptul c o subclas B poate moteni proprietile
i comportamentul de la dou sau mai multe superclase, aa dup cum reiese din figura
7.23.
Se observ c subclasa E motenete proprietile i comportamentul att de la
superclasa A ct i de la B. Clasele constituite special pentru a fi motenite se numesc
clase abstracte i acestea nu au instane, iar numele lor se scrie cu format cursiv (italic ).
O clas construit pentru a crea instane se numete clas concret. Clasele abstracte
conin cel puin o operaie abstract, adic o operaie neimplementat i care urmeaz s
fie implementat n clasele descendente.
Motenirea ofer marele avantaj cu privire la reutilizarea codului i definirea de
ierarhii de clase. n acest mod sporete considerabil de mult productivitatea muncii n
activitatea de programare.
156
Fig. 7.23 Exemplu de motenire multipl
7.6.10. Generalizarea i specializarea

Generalizarea i specializarea sunt mecanisme care permit partajarea
caracteristicilor comune ntre clase, pstrnd totodat diferenele dintre acestea.
Generalizarea presupune identificarea atributelor i/sau operaiilor comune mai multor
clase i izolarea lor n superclase. Specializarea claselor este opus generalizrii i are ca
punct de plecare o superclas ce urmeaza a fi descompusa in subclase si la care se pot
adaug noi atribute i/sau operaii relevante numai pentru anumite obiecte din acea clas,
crend astfel subclase de obiecte. Atributele i operaiile superclasei nu mai apar n cadrul
subclaselor ataate ei, dar ele aparin acestora prin motenire. n subclase se descriu
numai atributele i/sau operaiile specifice fiecruia dintre ele. Subclasa rafineaz,
specializeaz clasa. Superclasele i subclasele se mai numesc prini / copii sau strmoi /
descendeni. n figura 7.24 se prezint operaiile de generalizare si specializare.
Un alt exemplu extrem de sugestiv l-ar putea constitui mulimea studenilor din
cadrul unei universiti. Studenii ar putea fi privii ca formnd o singur colectivitate
(clas) la nivelul ntregii universiti i apoi pe subcolectiviti (subclase) n funcie de
specializarea urmat (faculti i secii), deci subclase, ca n figura 7.25.
STUDENTI-ASE apare ca o superclas ce conine proprietile i comportamentul
comun tuturor studenilor, apoi la nivelul fiecrei subclase se precizeaz doar ceea i
specific fiecrei subclase i care permite diferenierea subclaselor.
Se poate deduce faptul c pentru generalizare se pleac de la nite clase deja
existente, din care vor fi desprinse aspectele comune claselor, definind cu acestea o
superclas, iar specializarea presupune existena unei singure clase din care vor fi
desprinse specializri.
De remarcat faptul c generalizarea se implementeaz prin relaia de motenire
ns n cadrul limbajelor de programare orientate obiect, ea capt un aspect mai abstract.
Avantajele utilizrii generalizrii sunt urmtoarele:
- Reutilizarea codului n proiectul n lucru pot fi folosite clase create n cadrul
altor proiecte;
- Standardizarea aspectele comune sunt specificate o singur dat;
157
Capitol 7
-
Calitatea superioar reutilizarea claselor create pentru alte proiecte presupune i

faptul c ele au fost testate deja n cadrul acelor proiecte.
Superclas
CLASA 1
Atribute comune
Operaii comune
Subclas
Subclas
generalizare
specializare
CLASA 2
CLASA 3
Atribute specifice
Atribute specifice
Operaii specifice
Operaii specifice
Fig. 7.24. Generalizarea si specializarea

STUDENI - ASE
STUDENI
REI
STUDENI
CSIE
INFORMATIC
...
STUDENI
MANAGEMEN
T
CIBERNETIC
STATISTIC
Fig. 7.25. Exemplu 2 de generalizare/specializare
7.6.11. Agregarea, compunerea i descompunerea

Agregarea i descompunerea sunt operaii care permit reprezentarea relaiilor de
tipul parte-ntreg dintre obiecte. Agregarea descrie un obiect ca fiind constituit din mai
multe obiecte. De asemenea, agregarea se folosete la gruparea claselor ntr-o nou clas.
158

Ea este folosit la construcia unui obiect complex prin compunerea lui din prile
componente. Agregarea este un tip special de asociere ntre o clas ntreg i una sau
mai multe clase parte (figura 7.26.).
Universitate
1
1,
1,
Uniti
administrative
Secii
Cldire
Departamente
Camere
Fig. 7.26. Agregare, descompunere

Agregarea i compunerea se reprezint grafic prin intermediul unui romb. Un
romb plin semnific o relaie de compunere. ntr-o relaie de compunere, spre deosebire
de relaia de agregare, obiectul parte aparine unui singur obiect ntreg, de exemplu, o
camer este parte a unei singure cldiri, din aceast cauz multiplicitatea prii ntreg
dintr-o astfel de relaie este ntotdeauna 1. Un alt exemplu de agregare si descompunere
este redat n figura 7.27.
Agregare
Explozie
TRACTOR
ROI
MOTOR
...
CARBURATOR
CABINA
CILINDRII
...
Implozie
PISTOANE
Descompunere
Fig. 7.27. Exemplu de agregare i descompunere
159
Capitol 7
Conceptele de baz ale modelului obiectual sunt utilizate pentru reprezentarea
acestuia. Modalitatea de reprezentare utilizat de modelul de obiecte este Diagrama de
Asociere a Claselor (DAC), o diagram a claselor de obiecte. Diagrama este practic un
graf al crui noduri sunt clasele de obiecte i ale crui arce sunt asocierile dintre obiecte
i clase de obiecte.
7.7. Standardul ODMG pentru baze de date

orientate obiect
7.7.1. Aspecte generale referitoare la standardizare
n condiiile exploziei informaionale cu privire la abordarea obiectuala n
domeniul informaticii i legat de apariia i distribuirea unor multitudini de produse
softwer si hardwer, pentru a veni in sprijinul realizatorilor i utilizatorilor de astfel de
produse s-a conturat din ce n ce mai mult preocuparea pentru elaborarea unor standarde
n acest domeniu de interes. Astfel, n 1989 s-a format OMG (Object Management
Group) ca un consoriu non-profit avnd ca principal scop promovarea orientrii spre
obiecte n ingineria programrii i dezvoltarea de standarde. Grupul reuete peste 700 de
uniti membre, ce includ aproape toi realizatorii de produse software i hardware din
lume, cum ar fi: Microsoft, ORACLE, IBM, SAP, SUN, Apple, NCR, DEC, HwlettPackard, Object Design Inc., Objectivity etc.
De remarcat faptul c OMG nu este un grup sau organizaie recunoscut pentru
standarde aa cum sunt: Organizaia Internaional de Standardizare (ISO), Institutul
Naional American pentru Standarde (ANSI) sau Institutul de Inginerie Electric i
Electronic (IEEE) ci Consoriul OMG face propuneri de Standarde care ulterior sunt
supuse spre acceptare de ISO sau ANSI.
Dintre realizrile consoriului OMG precizm faptul c n anul 1990 a elaborat i
publicat o documentaie intitulat Object Management Arhitecture Guide. Ghidul are
menirea de a specifica:
- o terminologie unitar pentru limbaje, sisteme i baze de date orientate obiect;
- un cadru abstract pentru sistemele orientate spre obiecte;
- un set de scopuri tehnice i arhitecturale;
- un model de referin pentru aplicaiile distribuite utiliznd tehnicile orientrii
spre obiecte.
n cadrul modelului de referin pentru aplicaii distribuite au fost identificate
urmtoarele domenii ale standardizrii:
- modelul de obiecte OM (Object Model);
- brockerul de cereri de obiecte ORB (Object Request Brooker), pe baza cruia s-a
definit Arhitectura brockerului de cereri comune cunoscut sub denumirea de
CORBA (Common Request Brocker Arhitecture);
- serviciile de obiecte (memorie, administrarea tranzaciilor, integrrii, realizarea
versiunilor i securitatea sistemului);
- faciliti comune (help, E-mail i browser).
160

n 1989 civa productori de software pentru baze de date s-au reunit i au format
un grup pentru administrarea bazelor de date orientate obiect ODMG Object Database
Management Grup, avnd ca obiectiv de a defini standarde pentru SGBDOO. Din cadrul
grupului faceau parte producatorii: Gemstone Systems, Object Design, O2 Technology,
Versant Object Technology, UniSQL, POET Software, Objectivity, IBEX Computing SA,
Lockheed Martin, Ontos, Itaca, Servio, Hewelt-Packard etc.
Grupul de lucru a conceput un model standard incluznd urmtoarele componente
pentru SGBDOO:
- modelul de obiecte (OM),
- limbajul de definire a obiectelor (ODL Object Definition Language),
- limbajul de interogare a obiectelor (OQL Object Query Language),
- interfa cu limbajul C++,
- interfa cu limbajul Smalltalk,
- interfa cu limbajul Java.
Actualmente, sistemele comercializate ce suport standardul ODMG 3.0 includ
GemStone (http://www.gemstone.com), Objectstore (http://www.odi.com.), Poet
(http://www.poet.com) etc.
n cele ce urmeaz ne propunem s facem o trecere n revist doar a primelor trei
componente iar pentru celelalte trei recomandm cititorilor interesai cteva surse mai
nsemnate de documentare (Catell and Barry 2000, www.odmg).
7.7.2. Modelul de obiecte

Modelul ODMG de obiecte reprezint un superset al modelului OMG de obiecte,
urmrind n mod deosebit de a asigura portabilitatea proiectrii i implementrii
aplicaiilor pe diverse SGBDOO care accept modelul de obiecte.
Elementele fundamentale care constituie suportul pentru modelare sunt:
- Modelul ODMG este bazat pe obiecte, fiecare obiect avnd un identificator unic;
- Obiectele pot fi clasificate n tipuri. Multitudinea obiectelor de un tip dat prezint
un comportament i o stare comun;
- Starea obiectului este dat de valorile pe care le iau proprietile obiectului. O
proprietate poate fi un atribut sau o relaie dintre unul sau mai multe alte obiecte;
- Multitudinea operaiilor pe care le poate efectua un obiect sau alte obiecte asupra
lui implementate ntr-un limbaj oarecare de programare poart denumirea de
metod;
- Multitudinea metodelor aparinnd unui obiect definesc comportamentul acelui
obiect;
- Fiecare metod este nsoit de o semntur prin care se precizeaz denumirea
operaiei, denumirea i tipul tuturor parametrilor de intrarea i ieire i situaii de
excepie ce pot interveni (condiii de eroare);
- Baza de date ce stocheaz obiectele n concordan cu schema acestuia, descris
cu ajutorul unui limbaj de definirea a obiectelor (ODL).
Despre toate aceste elemente fundamentale gsim detalii n paragrafele anterioare,
precum i alte lucrri de referin (Craig Laorman UML 98, Cattell).
161
Capitol 7
7.7.3. Limbajul de definire a obiectelor

Limbajul de definire a obiectivelor ODL (Object Definition Language) este
destinat descrierii schemei bazei de date orientate obiect. El descrie tipuri i nu clase i
este independent de limbajul de programare ales pentru implementarea claselor. El
definete atributele, relaiile dintre tipuri i specific semntura operaiilor (metodelor).
De reinut faptul c el nu se refer la implementarea semnturilor. ODL a fost conceput
de ODMG. Sintaxa ODL se bazeaz pe limbajul de Definire a Interfeei IDL (Interface
Definition Language), fiind o extensie a acestuia. IDL aparine OMG-ului i este parte
integrant a lui CORBA (Common Object Request Broker).
ODMG a ales IDL ca baz de referin, n loc de a inventa o nou sintax, pe
considerentul c prin aceast alegere se asigur un grad sporit de compatibilitate cu
recunoscutul i importantul standard CORBA pentru sisteme de baze de date distribuite.
Terminologia utilizat n ODL difer n anumite privine de cea utilizat de
CODM. Aceast diferen i gsete explicaia, ntr-o oarecare msur, tocmai n
obiectivul urmrit de ODMG i anume acela de a asigura o maximizare a portabilitii
schemei de date pentru mai multe limbaje de programare.
Ideea avut n vedere de ODMG const n faptul c schema bazei de date definit
de ODL trebuia s permit accesarea obiectelor n mai multe limbaje de programare
gazd. Acest lucru, pentru moment, este posibil n limbajele C++, Java i Smalltalk.
n semnificaia ODMG, pentru fiecare legtur cu limbajele de programare gazd
se prevede extinderea documentaiei sau adaptarea acesteia n contextul respectrii
structurii comune ODMG.
Comunicarea se face printr-un set de variabile din limbajul gazd i un
preprocesor special care modific cadrul surs pentru a nlocui afirmaiile ODL cu apelri
la rutinele SGBD. Codul surs poate fi apoi compilat i linkeditat n mod normal.
Faptul c ODL definete tipuri ce pot fi implementate n numeroase limbaje de
programare ofer numeroase avantaje, astfel:
- ODL permite ca o aceiai baz de date s fie partajat pe multiple limbaje de
programare, sau cu alte cuvinte, o aceiai aplicaie s fie portabil pe numeroase
limbaje de programare fr rescrierea definirii schemei bazei de date.
- ODL este utilizat pentru analiza i conceperea schemei bazei de date naintea
descrierii datelor i operaiilor unei aplicaii independent de un limbaj de
programare. Concepia rezultat poate fi utilizat fie n mod direct fie translatat
ntr-un limbaj de descriere a datelor ales de programator;
- Schema descris n ODL este acceptat de toate SGBD compatibile cu concepia
ODMG.
De remarcat faptul c nu este posibil ntotdeauna obinerea unei compatibiliti de
100% a schemei bazei de date cu alte produse software, datorit unor diferenieri
intrinseci a modelelor limbajelor de programare. Deci, ODL va comporta coloratura i
specificul limbajului gazd cu care realizeaz legtura.
De exemplu, n cazul legturii cu Java, ODL distinge dou feluri de clase. Prima
este numit interfa iar a doua clas. Pentru a evita confuzia cu clasele CODM recurge
la numirea acestora interfa ODMG i respectiv clas ODMG.
n termenii CODM, definiia interfeei i clasei ODMG specific:
162

-
un nume de clas (n sens CODM) mpreun cu partea relevant a ierarhiei de

motenire;
un tip asociat clasei de referin.
O colecie de astfel de definiii specific schema ntregii baze de date ODMG.
Principalele diferene dintre interfeele ODMG i clasele ODMG sunt:
O interfa ODMG nu poate include codul (programul) pentru metode; ceea ce
nseamn ca sunt permise doar semnturile metodei, acest aspect constituie tocmai
motivul pentru care se numete interfa. Clasele ODMG includ codul pentru
metodele claselor de referin. Semntura i codul pot fi explicite specificate prin
folosirea unui limbaj gazd sau pot fi motenite de la o clas din cadrul unei
ierarhii de clase de obiecte;
O interfa ODMG nu poate avea propriile ei obiecte membre, adic instanele de
obiecte ale interfeei nu pot fi create. Din contr, o clas ODMG poate avea
obiecte membre;
O interfa ODMG nu poate moteni dintr-o clas ODMG dar poate moteni doar
din alt interfa ODMG;
O clas ODMG poate moteni din multiple interfee ODMG dar nu poate avea
dect cel mult o superclas ODMG imediat.
Distincia dintre clase i interfee se face din urmtoarele dou considerente:
n primul rnd aceast distincie face ODL-ul un superset al IDL-ului CORBA,
prin aceasta asigurnd un grad sporit de compatibilitate cu acest important
standard pentru sisteme distribuite.
n al doilea rnd aceast difereniere permite ODL-ului s depeasc cteva
dintre problemele asociate cu motenirea multipl care apare cnd o clas
motenete dou definiri diferite pentru o aceiai metod din superclase diferite.
Precizm faptul c o prezentare complet a sintaxei unui limbaj ODL depete

scopul acestei cri. Totui, urmtorul exemplu va ilustra unele elemente ale limbajului.
Cititorului interesat i recomandm, pentru o definiie complet a ODL-ului, s consulte
[Catell-1997].
Pentru exemplificarea modului de utilizare a ODL ne vom referi la schema
parial prezentat n figura 7.3.
Interface UNIVERSITATE
// Definete interfaa pentru
// entitatea Universitate
/ Urmeaz definirea atributelor
/
atribute string Denumire;
atribute structure Nume-rector (string nune, string prenume);
atribute string Ora;
atribute string Strada;
atribute Set < string Numr-telefon;
/ Urmeaz definirea relaiilor
/
relationship BIBLIOTECA are
inverse BIBLIOTECA:: aparinede;
relationship PROFESOR are
inverse PROFESOR:: estela;
163
Capitol 7
relationship LABORATOR dispunede
inverse LABORATOR:: aparinede;
/ Urmeaz definirea semnturilor /
Void adaugunnounr.tel (in string Numr-telefon);
Interface FACULTATE: UNIVERSITATE

// entitatea/obiectul Faculti
// care motenete obiectul
// Universitate
/ Urmeaz definirea atributelor/proprietilor

/
atribute string Nume-decan;
atribute string Ora
/
relationship Set <Catedr coordoneaz
inverse Catedra :: coordonatde;
relationship Laborator folosete
inverse Laborator :: folositde ;
relationship Student urmat de
inverse Student :: urmeaz;
Interfaa SECIE: UNIVERSITATE

// obiectul secie care
// motenete obiectul
// Facultate
/ Urmeaz definirea atributelor/proprietilor

/
atribute string Nume-serii;
/
relationship STUDENT specializeaz
inverse STUDENT :: specialistn;
relationship CURS are
inverse CURS :: sepredla;
Interface STUDENT
// entitate/obiectul STUDENT
(extent
STUDENT);
Key CNP)

/
struct Nume-Prenume (string nume, string prenume);
atribute Nume-Prenume nume;
atribute integer CNP;
164

atribute integer an-studii;
atribute string Adresa;
atribute date Datadenatere;
atribute enum genul m, f sex;
/
relationship FACULTATE urmeaz
inverse FACULTATE:: urmatde;
relationship SECIE specialist n
inverse SECIE:: specializeaz;
relationship CURS frecventeaz
inverse CURS:: frecventat de;
/ Urmeaz definirea operaiilor
/
nscrielacurslasecia (n CURS, n SECIE) raises;
(cererenesatisfcut, cursplin, nrlocuriocupate);
Void transferstudent (in from : SECIE, in to:
SECIE) raises (nuexitlocuridisponibile);
Interface CURS
// Definete interfaa CURS

/
atribute integer codcurs;
atribute string Denumirecurs;
atribute integer Nr.credite;
/
relationship SECIE sepredla
inverse SECIE:: are;
relationship STUDENT frecventat de
inverse STUDENT :: frecventeaz;
/
Void tergecurs ( ) raises (nu exist acest curs):
Interface LABORATOR
// Definete interfaa LABORATOR

/
atribute string DenumireLaborator;
atribute string efLaborator;
/
relationship FACULTATE folositde
inverse FACULTATE:: folosete;
relationship UNIVERSITATE aparinede
inverse UNIVERSITATE :: dispunede;
Interface PROFESOR
// Definete interfaa profesor
(extent PROFESORI;
KEYS CNP)
165
Capitol 7

/
atribute integer CNP;
atribute string NUNE-PRENUME;
atribute integer MARCA;
atribute string SPECIALIZAREA;
atribute enum grad-didactic prof, conf, lector, asist;
atribute integer salariu;
/
relationship UNIVERSITATE estela
inverse UNIVERSITATE:: are;
relationship CATEDARA aparinede
inverse CATEDARA:: dispune de;
/
Void majoraresalariu (in float);
---------------------------------------------------------------------------------------------------
n cele ce urmeaz vom cuta s facem cteva precizri pe marginea exemplului

de utilizare a Limbajului de Definire a Obiectelor, astfel:
- Cuvntul cheie interface este utilizat pentru a defini o clas i a asigura
compatibilitatea cu OMG IDL. Pentru fiecare interfa se poate declara un
extent i specifica anumite Key. Extent-ul precizeaz denumirea pentru setul
curent de obiecte a acelei clase. El est analog cu instana unei relaii i interfaa
este analog schemei relaiei. Dac utilizatorul nu anticipeaz nevoia sa lucreze cu
seturi de obiecte ale unei clase date, deci c ar fi suficient s manipuleze
individual obiectele, atunci declararea Extent-ului poate fi omis. Distincia
dintre numele interfeei (i numele extent-ului ntr-un limbaj de definire a datelor
este mai degrab folosit din punctul de vedere al uni SGBD relaionale. Deci,
ntrim precizarea c numele interfeei ar fi similar cu a da un nume schemei unei
relaii (folosind comanda CREATE TABLE nume) i un nume diferit instanei
relaiei actuale peste acea schem. Oricum, se apreciaz c din punctele de vedere
practic i conceptual, valoarea clauzei extent rmne o problem de discutat.
- Clauza Key specific faptul c extent-ul are o cheie cu o anumit denumire.
Exemplu, extent STUDENT are definit i o cheie cu denumirea CNP care nu
permite existena a dou instane cu o aceiai cheie n cadrul extent-ului.
- Proprietile claselor de obiecte sunt specificate utiliznd ODL i sunt de trei
feluri: atributele, relaii i metode.
- Atributele sunt definite ca fiind de tip integer, string, date, enum (pentru liste de
valori) etc.
- Relaiile dintre clasele de obiecte sunt specificate prin clauzele Relationships i
corespondena acesteia inverse relationships; deci observm c avem de a face
cu o definire bidirecional.
166

-
La nivelul fiecrei interfee a fost precizat cu scop exemplificativ cte o

"semntur de metod, n cadrul crora apar specificate i situaiile de excepie
folosind clauza raises.
n cadrul descrierii structurii BDOO se mai pot desprinde i alte aspecte
evideniate prin comentarii.
7.7.4. Limbajul de cereri obiect OQL

Limbajul de cereri obiect (Object Query Language) constituie o extensie a SQL,
chiar dac asemnrile dintre cele dou limbaje sunt mai mult aparente dect reale, n
mare msur depind de utilizarea acelorai cuvinte-cheie.
OQL ca i SQL, este un limbaj pur pentru cereri. El nu include, de exemplu,
controlul structurilor. Din OQL este posibil s se invoce metode care sporesc puterea
expresiv a acestora. n mod curent OQL nu include primitive pentru actualizarea strii
obiectelor coninute n baza de date, aceste actualizri urmnd a se realiza cu ajutorul
metodelor .
De remarcat faptul c limbajul OQL iniial a fost elaborat pentru O2, apoi a fost
adaptat de ctre ODMG, printr-o serie de modificri, astfel nct actualmente este
considerat ca un limbaj de cereri standard pentru SGBDOO. El poate fi utilizat att ca un
limbaj autonom, ct i ca un limbaj nglobat n alt limbaj, pentru care este definit o
legtur de tip ODMG. Limbajele acceptate n mod curent sunt Smalltalk, C++ i Java.
Totodat este de precizat faptul c limbajul OQL poate invoca operaii programate n
limbajele amintite anterior.
O cerere/interogare OQL este o funcie care furnizeaz un obiect, al crui tip
poate fi dedus din operatorul care contribuie la expresia de interogare. i de aceast dat
facem precizarea c rezultatul unei cereri OQL nu este obligatoriu s fie un obiect sau o
tabel, aceasta poate fi chiar un ntreg, o list de referin a obiectelor, o structur, un
ansamblu de numere reale sau ntreaga structur de date definind un obiect.
O integrare poate fi compusa dintr-o mulime, posibil vid, de expresii, cum ar fi:
expresii de obiecte, de tip atomic, elementare, de definire a interogrii (de forma:
DEFINE Q AS e; definete o interogare cu denumirea Q, pentru o expresie de interogare
e dat), de mulimi diverse, de conversii etc.
Expresiile pot fi compuse n diferite forme, cum ar fi: prin utilizarea
cuantificatorului universal (for all), cuantificarea existenial (exists), testul de
apartenen (in), clauza select from where, operatorul de sortare (sort), operatorii unari
pentru mulimi (min, max, count, sum, avg) i operatorul de grupare (group).
Formatul clauzei SELECT este foarte apropiat de cel din limbajul standard SQL,
i anume:
SELECT [DISTINCT]
<expresie>
FROM
<din-list>
[WHERE
<extensie>]
[GROUP BY
<atribute>]
[HAVING
<predicat>]
[ORDER BY
<expresie>]
unde, ntr-o form succesiv, elementele din <din-list>:: =
<denumire_variabil> IN <expresie>]
167
Capitol 7
<denumire_variabil> IN <expresie>,
<din-list>]
<expresie] AS <denumire_variabil>]
<expresie] AS <denumire_variabil>,
<din-list>]
n cele ce urmeaz vom cuta s oferim cteva exemplificri pentru a observa
modul de utilizare a limbajului OQL; referirile fcndu-se la structura bazei de date
orientate obiect din figura 7.3.
Exemplul 1, evideniaz faptul c nu ntotdeauna este necesar utilizarea clauzei
SELECT FROM WHERE; Este suficient a specifica doar: STUDENT, aceasta este o
cerere complet i are ca efect obinerea / listarea tuturor studenilor (ca obiecte cu
identitate).
Exemplul 2, evideniaz modul n care este utilizat clauza DISTINCT din fraza
SELECT:
SELECT DISTINCT X.Adresa
FROM
X IN
STUDENT
WHERE
X. Nume = IONESCU
are ca efect returnarea setului adreselor tuturor studenilor ce au numele de IONESCU.
Mai exact, datorit clauzei DISTINCT, se va returna o valoare de tip SET <ADRESE> n
care valoarea unei adrese apare o singur dat. Cu alte cuvinte, vor fi listate toate adresele
la care se afl studeni cu numele IONESCU, fiecare adres fiind luat o singur dat. n
modelul relaional, mai precis n algebra relaional, clauza DSTINCT are semnificaia de
operator de proiecie a relaiei STUDENI pe atributul Adresa.
Dac, n cererea de mai sus, ar fi omis clauza DISTINCT din fraza SELECT,
cererea ar returna o valoare de tip Bag <ADRESE>; un Bag de adrese este similar cu un
SET ns poate avea elemente duplicate.
Tipul SET vine cu metodele ncorporate nuntru, care d programatorului accesul
la elementele setului pentru a obine funcionalitatea asigurat de cursori n SQL
(identificator/pointer, cu ajutorul cruia se manipuleaz o zon de memorie alocat i
gestionat de sistem pentru a se executa o comand).
Exemplul 3 evideniaz modul de invocare a unei metode n faza SELECT:
SELECT
FROM
WHERE
T. adaug_un_nou_nr_tel (031_456789)
T IN UNIVERSITATE
T. Denumire =
A.S.E.
Are ca efect adugarea unui nou numr de telefon n setul de numere. Cererea
actualizeaz baza de date ns nu returneaz nimic apelantului metodei.
Exemplu 4 are ca scop evidenierea unei expresii de definire a unei interogri. Se
cere s se gseasc toi studenii ce au domiciliul stabil n Bucureti:
DEFINE
Bucureteni
AS
168

SELECT
X
FROM
X
IN
STUDENI
WHERE
X.Adresa = Bucureti
SELECT X. Nume_Prenume FROM X IN Bucureti.
Exemplul 5 are ca scop evidenierea modului de creare/cunoatere a unui obiect.
Precizm faptul c OQL accept dou tipuri de obiecte n concepia modelului ODMG:
cu identitate sau mutabile, avnd un OID i fr identitate sau literali, fr OID, n funcie
de care difer i modul de creare sau selecie.
n cele ce urmeaz vom exemplifica modul de creare a unui obiect cu identitate:
PROFESOR (CNP: 1012644400237, NUME-PRENUME: BARBU DAN,
MARCA: 12233, SPECIALITATE: INFORMATIC,
GRAD-DIDACTIC: PROFESOR, SALARIU: 3500)
n situaia n care anumite proprieti/atribute nu sunt iniializate, ele vor lua
valori implicite.
Un obiect cu identitate mai poate fi creat/construit i n alte variante, dintre care
una ar poate fi aceea care presupune un tip obiect predefinit, care apoi se va iniializa cu
valori preluate prin selecie dintr-un alt tip de obiecte. Astfel, presupunem c ar prezenta
interes de a avea i pstra separat un tip/clas de obiecte referitoare la toate cadrele
didactice avnd specializarea informatic i descrise prin proprietile: CNP, NUMEPRENUME i GRAD-DIDACTIC. ntr-o astfel de situaie, tipul de obiecte cu denumirea
sugestiv de INFORMATICIAN ar putea fi iniializat/populat cu valori preluate din tipul
PROFESOR, de forma:
INFORMATICIAN (SELECT STRUCT (CNP;XNUME-PRENUME: XNUMEPRENUME, GRAD-DIDACTC: XGRAD-DIDACTIC)
FROM
X IN PROFESOR
WHERE
X SPECIALIZAREA = INFORMATIC)
Cazuri asemntoare regsim i n modelul relaional.
Obiectele fr identitate sunt create cu ajutorul tipurilor literale structurate, de
forma:
STRUCT (a : 7, b : 10, c : BAZE DE DATE)
Deci, se creeaz o structur cu trei cmpuri a, b i c.
7.8. Sisteme de gestiune a bazelor de date orientate

obiect (SGBDOO)
n domeniul bazelor date orientate obiect pe piaa mondial au aprut o serie de
Sisteme de gestiune a bazelor de date orientate obiect. Unele dintre ele au rezistat
169
Capitol 7
timpului i concurenei, altele au disprut. n cele ce urmeaz vom recurge la o prezentare
a unor dintre SGBDOO.
7.8.1. GEMSTOME
GEMSTOME este unul dintre primele i probabil cel mai pur sistem de gestiune a
bazelor de date orientate obiect care a existat ca produs comercial [Maier 86; Maier i
Stein 1987; Brett .a. 1989]. Este construit pe o extensie a lui Smalltalk numit OPAL.
Spre deosibire de ObjectStore, Ontos i Versant, care sunt strns legate de C++,
OPAL nu este strns legat de un limbaj anume dei, limbajul GemStone poate fi accesat i
din alte limbaje cum ar fi Smaltalk i C++.
GemStone este orientat n principal pe aplicaii CAD/CAM i nu trateaz
motenirea multipl.
7.8.2. ONTOS
ONTOS a fost realizat i comercializat n 1990 de catre Ontos Billerica,
Massachesetts. Utilizeaza C++ ca limbaj de programare pentru baza de date orientate
obiect. Ontos este succesorul unui produs mai vechi numit VBase care utiliza un model
orientat obiect cu prorpiile sale limbaje COP(C Object Processor o extensie orientat
obiect a limbajului C pentru acces la baza de date) i TDL (Type Definition Language).
Ulterior, n Versiunea 2.0 TDL este nlocuit cu o extensie orientat obiect a SQL, numit
Object SQL sau ONTOS SQL, care adaug sintaxa cererilor obiect la SQL standard.
Limbajul COP este nlocuit i el cu C++.
Dei este strns legat de C++, Ontos este accesibil i din alte limbaje. Versiunea
2.0 a introdus un 4GL numit Shorthand, un front-end windows, un raport i generator de
forme numit Studio. De asemenea, are un browser grafic i un instrument (tool) grafic
capabil s genereze n C++ fiiere i schema bazei de date.Metodele nu sunt stocare n
baza de date aa c trebuie meninute legturi ntre metode i date. Schema este stocat n
baza de date i este accesibil programatorilor. Clasele speciale sunt prevzute s
modeleze structurile de compunere.
Este suportat n LAN-uri utiliznd un model de arhitectur Client/Server.
Performana produsului este accentuat de posibilitatea clasterizrii discului i utilizrii
tehnicilor Caching. ncepnd cu Versiunea 2.2 (1993) ofer suport extins pentru aplicaii
de grup de lucru precum i o mai bun notificare a evenimentelor.
ONTOS posed i alte caracteristici, dintre care enumerm:
- trateaz foarte bine motenirea multipl;
- folosete perechi de atribute inversate, n sensul c menine n mod automat
atribute inverse, deci valorile sunt atribute care reprezint o asociere (valori unice
sau multiple);
- trateaz obiecte mari de tip BLOB-uri. Pentru inerea n pagin, atributele foarte
voluminoase sunt stocate cu ajutorul unei reprezentri n arbori B;
- gestioneaz versiuni ale obiectelor;
- dispune de utilitare pentru administrare, cum ar fi: un browser interactiv pentru
examinarea i modificarea schemei bazei de date, comenzi de modificare i
170

regrupare fizic a datelor i un utilitar, numit Make, pentru sincronizarea
programelor cu o schem modificat.
7.8.3. VERSANT
VERSANT este un alt SGBD orientat obiect realizat de Versant Object
Technology la Menlo Park n California. Este implementat pe platforma de sistem UNIX,
utiliznd C++ ca limbaj de acces primar ns este posibil i accesul din Smalltalk sau din
Object SQL.
VERSANT este cunoscut i folosit n mod deosebit pentru aplicaii multi-user n
mediu de baze de date distribuite. Este bazat pe o arhitectur multi-client/multi-server.
Totodat, ofer posibiliti de comunicare cu alte sisteme, cum ar fi ORACLE, cu
instrumente de dezvoltare pentru GUI (Grafic User Interface) sau generatoare de
rapoarte. El poate asigura i un Depozit de date (Repository) pentru un mediu CASE cum
ar fi Rational ROSE CASE. Alte caracteristici ale sistemului VERSANT constau n faptul
c trateaz structurile compuse, motenirea multipl i variantele de versiuni.
7.8.4. ORION
ORION este un sistem orientat obiect realizat de MCC din Austin, Texas. El ofer
posibilitatea identificrii obiectelor, tratarea motenirii multiple, obiectelor compuse,
gestiunii versiunilor, indecilor pentru acces i tranzacii. De asemenea ofer suport
pentru baze de date distribuite, gestioneaz evoluia dinamic a bazei de date i accesul
autorizat la date. Este implementat n limbajul LISP, versiunea extins orientat obiect a
acestuia.
O particularitate mai deosebit a proiectului de cercetare ORION de la MCC
const n faptul c se concentreaz pe evoluia schemei bazei de date. Schema unei baze
de date orientate obiect e dinamic i poate evolua n diferite feluri fr a necesita o
recompilare, astfel ca permite [Ivan Graham]:
- Schimbri in descrierea unui obiect prin adugare, tergere, actualizare de atribute
sau metode;
- Schimbri fa de reprezentarea obiectelor de ctre sistem, de genul: adugare,
tergere sau schimbare de identitate a unui obiect. tergerea unei clase de obicei
are mai degrab efect asupra tuturor subclaselor sale care motenesc proprietile
i comportamentul superclaselor;
- Schimbri n structurile bazei de date ca: adugare, tergere sau modificare a unei
moteniri, compuneri sau relaie asociativ.
n general, evoluia sau dezvoltarea structurii baze de date e complicat datorit
prezenei motenirii, n sensul c dac o superclas comport schimbri atunci trebuie
verificate toate implicaiile dependente de acea schimbare. Este important de observat c
identitatea obiectului e pstrat i trebuie s fie pstrat pe parcursul tuturor schimbrilor
schemei bazei de date orientate obiect. Pentru acest motiv se presupune c schimbrile
schemei trebuie s fie rezonabile i nu n totalitate. Aceast problem este strns legat de
cea a controlului de versiune i majoritatea bazelor de date orientate obiect ofer un mod
de control de versiune la nivel de instan, clas i schem. n acest scop, se poate defini
o clas cu semnificaie de istoric care ar conine ca atribute: versiunea precedent,
171
Capitol 7
versiunea urmtoare i membru de set de versiune, care pot fi motenite de orice obiect
care necesit control de versiune [Kim 1988].
Dei ORION a fost n mare parte inspirat dup modelul SMALLTALK exist un
numr important de extensii n model. De exemplu, motenirea multipl e suportat i
exist trei metode prevzute pentru rezoluia de conflict. Se folosete fie o regul left
first (nti stnga) prin care este folosit prima superclas dintr-o list de superclase de la
care se moteneste metoda sau atributul conflictual; sau utilizatorul poate specifica
alegerea pe care ar trebui s o fac obiectul; sau utilizatorul poate specifica c obiectul
trebuie s moteneasc ambele proprieti i s redefineasc una dintre ele.
7.8.5. ITASCA
ITASCA este realizat si comercializat de Itasca Systems Inc din Minesota,
Minneapolis. Este un produs softwer bazat pe prototipurile de cercetare ORION, ns
mult dezvoltat i perfecionat (1993).
ITASCA ca i ORION utilizeaz limbajul LISP ns accept i alte limbaje de
programare cum ar fi: CLOS, C, C++ i Fortran. Ruleaz pe staii de lucru UNIX.
ITASCA se bazeaz pe o arhitectur multi-clinet/multi-server distribuit i nu are
nume centralizat sau server de date aa c nu exist un singur punct de eec (de cdere).
Ofer posibilitatea urmririi evoluiei schemei dinamice i a unor servicii bune de
securitate i concuren. Trateaz structurile compuse iar notificarea evenimentului poate
fi bazat pe marcare (flag-based) sau mesaj (message-based).
ITASCA ofer facilitile de partiionare a bazei de date i distribuirea acestor
partiii n spaiu geografic, fr a fi nevoie ca utilizatorul s tie unde anume sunt
stocate/localizate datele. Se folosete indexarea claselor pentru a spori performana, iar
unde e posibil cererile se execut n paralel pe diferite maini din cadrul reelei.
7.8.6. O2
Sistemul de gestiune a bazelor de date orientate obiect O2 a fost realizat n Frana
de Consoriul de cercetare Altair ntre 1986 i 1990 [F. Baucilhon 1988; F. Baucilhon i
C. Delobel 1989; 1991]. Dup 1991 el a fost dezvoltat i comercializat de O2 Technology
la Versailles. O2 este implementat n C++ ns anumite pri sunt implementate ntr-un
limbaj propriu numit O2C. Este disponibil pe platformele UNIX SUN , HP, IBM, BULL
i DEC.
O2 constituie un motor de baze de date, O2 Engine, n interiorul cruia sunt
disponibile trei niveluri de utilizare:
- Limbajele de interfa: C i C++, un L4G, O2C, limbajul de cereri obiect O2SQL
i o interfa de programare a aplicaiilor de nivel de baz O2APL:
- Utilitare GUI: un generator a interfeei O2LOOK i un dispozitiv de manipulare
de grafice O2Graph ;
- Utilitare de mediu: un mediu de programare grafic O2Tools i un ansamblu de
componeni O2Kit.
O2Engine completeaz toate funciunile unui motor de baze de date: rspunde
cerinelor de lucru ntr-un sistem distribuit, arhitectura sa rspunde cerinelor unui model
172

client-server, distinge gestiunea logic i gestiunea fizic a datelor, furniznd
mecanismele de acces concurent i de reprize, de indexare, de optimizare a cerinelor, de
plasament i de regrupare a datelor. De asemenea, ofer metode de stocare, de
manipulare, de execuie i prelucrare a datelor.
n esen, O2Engine este compus i privit la trei niveluri:
- Managerul schemei (schema Manager) este nivelul superior al schemei. El este
responsabil cu cererea, cercetarea, modificarea i suprimarea claselor de obiecte,
metodelor i supervizare la nivel global al schemei bazei de date. n aceeai
msur el este responsabil de respectarea constrngerilor de motenire i
verificarea coerenei schemei;
- Managerul obiectelor (Object Manager) este situat la nivel intermediar. El
rspunde de asigurarea identitii obiectelor i de transmiterea mesajelor lor. El
asigur modelul de persisten prin ataarea i implementarea strategiilor de
indexare i de regrupare, bazate pe obiectele complexe i motenire;
- Managerul hardisc (Disk Manager), componenta O2Store genereaz fiiere
secveniale de nregistrri structurale, de fiiere de index de tip Arbore B. Toate
aceste structuri sunt pliate n pagini, unitatea persistent de baz.
O2Store asigur controlul localizrii fizice a paginilor pe disc. Totodat, O2
asigur ncapsularea la trei niveluri: clase, scheme i baze de date.
7.8.7. Object Store

Object Store este conceput la Burlington, Massachusetts, fiind orientat pe limbajul
de programare a bazelor de date C++. Este primul sistem de gestiune a bazelor de date
orientate obiect ce ruleaz mai degrab n mediul MS Windows dect n mediul UNIX.
Object Store se bazeaz pe o arhitectur multi-client/multi server pentru a suporta
sistemul de lucru distribuit. Bibliotecile de clase sunt prevzute s suporte versiunile de
clase de obiecte, managementul configurrii i structurile compuse. Totodat, bibliotecile
de clase suport indexarea, clusterizarea, cererile asociative managementul relaiilor i
iterarea peste seturi.
n activitatea de programare, pentru adresare se utilizeaz unele tehnici de pointeri
swizzling. Conform unei astfel de tehnici, referinele de obiecte globale sunt convertite n
adrese de memorie local n momentul n care s-a ncrcat un obiect n memoria
principal i invers. [white 1994; Cattell; Thomas Conndy]. O astfel de tehnic ofer
reducerea timpului de regsire a datelor solicitate de aplicaii.
7.8.8. OBJECTIVITY/DB
Objectivity (Objectivity Data System Overview; Objectivity, Inc., Menlo Park,
California, 1990) utilizeaz un limbaj de programare de baze de date orientate obiect
bazat pe C++. Este analog cu Object Store, ONTOS i cu VERSANT. Arhitectura sa este
de tip client/server distribuit cu un server central, toate operaiile efectundu-se de o
manier transparent asamblnd baze de date, scheme, utilizatori i calculatoare ntr-un
mediu material de sisteme de exploatare i reele heterogene. Limbajul de interfa
cuprinde o bibliotec de clase n C++, o bibliotec de funcii C i SQL++, suportnd SQL
ANSI complet i numeroase extensii obiect ale lui SQL3.
173
Capitol 7
Un limbaj de nivel nalt, Object Definition Language (ODL), permite declararea
conceptelor de modelare precum i a asocierilor bidirecionale (relaii bazate pe atribute
inverse). Trateaz comportamentul asocierilor ntre obiecte atunci cnd avem de a face cu
mai multe sesiuni i programarea metodelor de traversare a asocierilor. Toate acestea au
ca rezultat generarea automat de metode i de declaraii C++ i C.
Punctul forte a lui Objectivity/DB este arhitectura sa client/Server distribuit, care
ofer o imagine logic unicat pe multiple baze de date instalate pe maini heterogene.
Utilizatorul va avea o imagine logic a obiectelor conectate i el nu va fi preocupat de
faptul c un obiect este ntr-o baz de date pe o staie de lucru SUN sau c un altul se
gsete ntr-o baz de date sub Windows sau VMS. Toate operaiile se desfoar la
modul transparent n acest mediu, unde tranzaciile atomice implic i validarea n dou
faze a metodelor de propagare i versionare a strii sistemului. n acest mod se accept
sub control deplasarea obiectelor dintr-o baz n alta i de pe o platform pe alta fr
afectarea aplicaiilor n curs de desfurare i nici nu reclam modificarea lor. Schemele
multiple sunt create fr afectarea altor utilizatori sau baze de date i sunt utilizabile
simultan cu schemele partajate, permind grupurilor locale s-i defineasc propriile lor
modele.
Bazele de date sunt detaabile de acest mediu partajat (baze de date federale)
pentru a fi utilizate pe periferice portabile, reconectri sau deplasate ctre un mediu
(compatibil) diferit sau nc distribuite ca pri separate sau biblioteci de imagini.
Objectivity/DB este comercializat de Digital Corporation sub numele de DEC
Object/DB i este suportat de platformele SUN, DEC, HP/900, IBM, RS/6000, NCR
3300, SGI, Windows 3.1., Windows 95, Windows NT etc.
7.9. Reguli de evaluare a unui SGBDOO

Aa dup cum Codd E.F. [3,4] a definit o serie de reguli pentru ca un SGBD s fie
cu adevrat relaional, tot la fel un grup de lucru de mare influen a publicat, sub
denumirea de Manifestul sistemelor de baze de date orientate pe obiecte, o serie de
cerine sau principii pe care trebuie s le ndeplineasc un SGBD pentru a putea fi
considerat obiectual [3]. n concordan cu Manifestul sistemelor de baze de date
orientate pe obiecte, sunt definite 13 principii ale SGBDOO , dintre care unele sunt
obligatorii iar altele opionale.
Posibilitatea definirii structurilor complexe. O astfel de cerin presupune
capacitatea de a defini structuri complexe plecnd de la tipuri de date atomice folosind o
serie de tipuri de constructori, iar acetia s fie ortogonali, n sensul c fiecare constructor
trebuie s se aplice oricrui obiect. Exemplu, dac folosim constructori de forma SET
(TUPLE( )), LIST (TUPLE ( )) atunci trebuie s avem posibilitatea de a folosi i formele
TUPLE (SET ( )) i TUPLE (LIST ( )). Dintre cei mai folosii constructori amintim:
- ROW n1 , t1 , , nn , t r , unde un tip reprezint un rnd sau tuplu cu cmpurile
n1 , , nr de tipurile t1 , , t r ;
- ARRAY: Tipurile array suport o metod array index pentru a permite
utilizatorilor s acceseze articolele array (colectiei);
174

-
seturi i multiseturi (Sets and multisets) . Obiectele set pot fi comparate utiliznd
setul de metode tradiional <, , =, , >. Totodat, dou obiecte set (avnd
elementele de acelai tip) pot fi combinate pentru a forma un nou obiect folosind
operatorii
, i (diferen).
Liste: Operaiile de liste tradiionale includ capul de list (head) care returneaz
primul element, coada listei (tail) care returneaz adresa ultimului element din
list; inserare sau adugare de noi elemente n list i respectiv excluderea unui
element din list.
Mai exist o serie de operatori, cum ar fi operatorii agregai (COUNT, SUM,
AVG, MAX, MIN), i operatori pentru conversia de tipuri (exemplu, pentru conversia
unui obiect multiset ntr-un obiect set prin eliminarea duplicatelor).
Identitatea obiectului, adic SGBD trebuie s ofere posibilitatea identificrii, fr
ambiguitate, a oricrui obiect din baza de date. n acest sens cu ocazia ncrcrii oricrui
obiect n baza de date se va recurge la generarea unui identificator unic al obiectului,
numit OID.
ncapsularea, presupune faptul c SGBD trebuie s dispun de capacitatea de a
ncapsula datele i metodele aparinnd obiectelor iar utilizatorii pot avea acces la ele
doar printr-o interfa ce citeaz o anumit metod. La rndul su att metodele ct i
datele pot fi definite publice (+), protejate (#) sau private (-).
Tipuri i/sau clase. Cele dou concepte trebuie s fie ambele prevzute. Primul
concept reprezint un mecanism de verificare pentru acurateea programelor n timpul
compilrii. Al doilea concept reprezint un mecanism care colecteaz extensiile de
obiecte i le definete implementarea lor. Invers, nu e necesar s fie dou forme diferite
de a exprima tipuri i clase i astfel e posibil s exprimm un concept n contextul
celuilalt.
Clase i/sau tipuri de ierarhii, n contextul motenirii, evideniaz faptul c un
SGBDOO trebuie s asigure ca un subtip sau subclas s poat moteni atributele i
metodele de la superclasele sau supertipurile lor.
SGBD trebuie s ofere suport pentru legarea dinamic, n sensul c metodele
trebuie s se aplice la obiecte de diferite tipuri iar implementarea unei metode va depinde
de tipul de obiect cruia i se aplic. Acest aspect presupune faptul c sistemul nu poate
lega denumirea metodelor pn n momentul execuiei (legare dinamic).
SGBD trebuie s ofere un limbaj de manipulare a datelor LMD cu completitudine
de calcul. n acest sens, de exemplu, se apreciaz c standardul SQL3 posed
completitudine de calcul.
Extensibilitatea mulimii tipurilor de date, ceea ce presupune capacitatea de a
defini noi tipuri bazate pe cerinele utilizatorilor.
Durabilitatea sau persistena datelor, ceea ce presupune capacitatea sistemului de
a asigura/suporta persistena datelor. La fel precum i n situaia SGBD convenionale,
datele trebuie s rmn dup finalizarea aplicaiei care le-a creat. Deci utilizatorul nu
trebuie s deplaseze sau s copieze explicit datele, pentru a le putea refolosi.
SGBD trebuie s fie capabil i s ofere faciliti n ceea ce privete operarea i
gestionarea unor volume mari de date (baze de date de mari dimensiuni).
Asigurarea accesului concurent la aceleai resurse.
Asigurarea capacitii de refacere a bazei de date n cazul unor cderi fizice de
hardware sau software, asemntor sistemelor convenionale.
175
Capitol 7
Asigurarea unor limbaje de cereri de nivel nalt cu multiple faciliti de integrare
a bazei de date.
Manifestul bazelor de date orientate obiect mai face referiri la cteva caracteristici
opionale, care sunt interesante i folositoare dar nu eseniale pentru un SGBDOO. Dintre
acestea enumerm: motenirea multipl, distribuia datelor ntr-o reea, posibilitatea
verificrii unui program n timpul compilrii, managementul tranzaciilor i mecanisme
pentru managementul versiunii lor.
7.10. Limbaj unificat de modelare (UML )

7.10.1. Ce este UML-ul?
Tendina actual din industria software impune dezvoltarea de sisteme extrem de
complexe i n cel mai scurt timp posibil. Se impune cu necesitate adaptarea procesului
de dezvoltare a sistemelor informatice la cerinele din ce n ce mai complexe fa de
produsele informatice.
n plus, odat cu impunerea pe pia a limbajelor orientate obiect i a mediilor
vizuale de programare, au aprut n ultimii ani mai multe propuneri de procese de
dezvoltare orientat obiect a sistemelor informatice, ceea ce a introdus nc o pictur de
haos n ecuaie.
n aceste condiii, trei dintre cei mai importani autori din domeniul proiectrii de
software orientat obiect Ivar Jacobson, Grady Booch i James Rumbaugh au conlucrat
pentru realizarea unui limbaj de modelare standard i a unui proces standard de
dezvoltare a produselor informatice. Limbajul pus la punct de acetia UML (Unified
Modeling Language) nregistreaz un mare succes, fiind adoptat ca standard de Object
Management Group (OMG), organismul de standardizare pentru comunitatea orientat
obiect. Deci, UML nu reprezinta un standard de metodologie de realizare a sistemelor
informatice ci un standard de notatii, concepte,simboluri folosite, diagrame utilizate,
modele concepute etc.
Apariia acestui standard reprezint un mare avantaj dac ne gndim la
multitudinea de notaii i metode utilizate pn nu de mult n proiectarea orientat obiect
i pe care UML le substituie cu succes. n prezent este suficient ca proiectanii s
cunoasc acest unic sistem de notaii.
UML-ul reprezint o sintez a celor mai multe notaii i concepte utilizate n
proiectarea orientat obiect. A nceput ca o coroborare a activitii lui Grady Booch,
James Rumbaugh, i Ivar Jacobson, creatorii a trei dintre cele mai cunoscute metodologii
orientate obiect.
n 1996 Object Management Group (OMG) a emis o cerere de ofert pentru un
model semantic i notaii standard pentru analiza orientat obiect. Versiunea UML 1.0 a
fost trimis ca rspuns la aceast cerere n ianuarie 1997. Au existat i alte cinci proiecte
concurente. n cursul anului 1997 toi cei ase rivali s-au unit i au prezentat o versiune
revizuit organizaiei OMG, cunoscut ca UML versiunea 1.1. Acest document a fost
aprobat de OMG n noiembrie 1997 sub denumirea OMG UML versiunea 1.1.
UML propune notaii standard i semantic corespunztoare pentru modelarea
sistemelor orientate obiect. nainte de aceasta un proiect orientat obiect putea fi descris
176

utiliznd una dintre zecile de metodologii disponibile, ceea ce fcea ca n cazul unei
revizuiri cei responsabili de aceasta s piard mult timp cu analiza notaiilor i semanticii
metodologiei nainte de a ptrunde logica proiectrii. n acest moment, utiliznd UML,
diferii proiectani ce lucreaz la diverse sisteme pot nelege cu uurin munca celuilalt.
7.10.2. Componentele limbajului unificat de modelare

UML-ul prescrie un set standard de diagrame i notaii pentru analiza i
proiectarea orientat obiect a diverselor tipuri de sisteme (sisteme software, sisteme
hardware sau organizaii), descriind totodat i semantica acestor diagrame i simboluri.
Limbajul unificat de modelare ofer pentru aceasta zece tipuri de diagrame ce pot
fi grupate astfel:
- Diagrame pentru modelarea proceselor de afaceri, respectiv:
Diagrama cazurilor de utilizare n cazul metodologiilor orientate pe cazuri
de utilizare, aceast diagram dirijeaz ntreg procesul de dezvoltare al
sistemului
- Diagrame pentru modelarea structurii statice, respectiv:
Diagrama claselor pentru modelarea structurii statice a claselor sistemului
Diagrama obiectelor pentru modelarea structurii statice a obiectelor
sistemului
- Diagrame pentru modelarea dinamicii:
Diagrame de interaciune, respectiv:
Diagrama de secven pentru modelarea circuitului mesajelor ntre obiecte
Diagrama de colaborare pentru modelarea interaciunilor ntre obiecte
Diagrame de comportament, respectiv:
Diagrama de stare pentru modelarea comportamentului obiectelor din
sistem
Diagrama de activitate - pentru modelarea comportamentului cazurilor de
utilizare, obiectelor sau operaiilor
- Diagrame de implementare, respectiv:
Diagrama componentelor pentru modelarea componentelor
Diagrama de desfurare pentru modelarea distribuirii sistemului
Diagrama pachetelor mijloc de grupare a elementelor diagramelor n
pachete
n figura 7.28. se prezint grafic aceast clasificare a diagramelor UML.
Mecanismele de extensibilitate incluse permit ca n UML s poat fi abordate aspecte
care nu sunt specificate n standard. Aceste mecanisme permit extinderea notaiilor i
semanticii UML.
Stereotipul este cel mai utilizat dintre mecanismele de extensibilitate ale UMLului. Un stereotip reprezint un mecanism de calificare din punct de vedere al utilizrii.
El se poate aplica oricrui element de modelare, inclusiv claselor, pachetelor, relaiilor de
motenire, etc. De exemplu, o clas cu stereotipul <<actor>> este o clas utilizat ca
agent extern n modelarea proceselor de afaceri. O clas ablon (template) este modelat
ca o clas cu stereotipul <<parameterized>>, cu semnificaia c aceasta cuprinde
parametrii.
177
Capitol 7
Exist o seciune special n specificaiile UML care prevede stereotipuri specifice
pentru clasele i asocierile utilizate n modelarea proceselor de afaceri. Aceasta prevede
stereotipuri ca actor, executant sau entitate pentru o clas i stereotipuri de genul
comunicare simpl sau cale ntre surs i destinaie pentru o asociere.
M O D ELA REA PRO C ESELO R D E A FA CER I
D i a g r a m a c a z u r i l o r d e u ti l i z a r e
M O D E L A R E A S T R U C T U R II S T A T IC E
D ia g ra m a c la s e lo r
D i a g r a m a o b i e c te l o r
M O D E L A R E A D IN A M IC II
D ia g ra m a d e s e c v e n
D ia gra m a d e c o la b o ra re
D i a g r a m a d e s ta r e
D i a g r a m a d e a c ti v i ta te
IM P L E M E N T A R E A
D i a g r a m a c o m p o n e n te l o r
D ia g ram a d e d e sfu ra re
D i a g r a m a p a c h e te l o r
Fig 7.28. Diagramele UML

Un model grafic nu poate descrie dect o anumit parte din comportament, dup
care alte detalii trebuie specificate n cuvinte. De multe ori ns, utilizarea cuvintelor
induce ambiguitate. Object Constraint Language (OCL) este standardul UML pentru
specificarea detaliilor suplimentare sau precizarea constrngerilor modelului. Dezvoltat n
cadrul diviziei de asigurri a IBM ca un limbaj de modelare a proceselor de afaceri, OCL
este un limbaj formal uor de utilizat. OCL este mai formal ca un limbaj natural, dar nu la
fel de precis ca un limbaj de programare, ceea ce nseamn c nu poate fi utilizat pentru a
descrie logica programului sau pentru controlul fluxurilor. Cum acesta este un limbaj
178

destinat expresiilor, frazele sale nu au efecte secundare, ele furnizeaz pur i simplu o
valoare fr a schimba starea sistemului.
O tehnic extrem de utilizat pentru a deslui funcionarea modelului orientat
obiect este analiza orientat pe responsabiliti cu fie CRC (CRC cards - Class
Responsibility and Collaborator cards). Cu ajutorul acestei tehnici clasele identificate n
cursul etapei de analiz sunt analizate i selectate pentru a obine doar clasele cu adevrat
necesare pentru modelarea sistemului.
Dei bazele de date orientate obiect devin din ce n ce mai populare, bazele de
date relaionale rmn modalitatea curent de stocare a datelor. Diagrama claselor poate fi
utilizat pentru a modela baza de date relaional pe care se bazeaz sistemul, cu toate
astea tehnicile tradiionale de proiectare a bazelor de date relaionale cuprind mai mult
informaie i sunt mult mai nimerite pentru astfel de sarcini. Aceast lucrare propune
modelul entitate asociere (Entity Relationship - ER) ca extensie a UML-ului pentru
proiectarea bazelor de date relaionale.
7.10.3. Diagrama cazurilor de utilizare

Cu ajutorul acestei diagrame analistul stabilete aria de cuprindere a sistemului.
Simbolurile folosite ntr-o diagram a cazurilor de utilizare sunt redate n figura 7.29.
Diagrama cazurilor de utilizare este reprezentarea grafic a cazurilor de utilizare i

a actorilor (figura 7.30.) i este adesea nsoit de o descriere textual. Aceast diagram
documenteaz interaciunile sistemului cu mediul, care pot fi interaciuni cu factorul
uman, interaciuni cu alte sisteme i interaciuni ntre calculatoare.
Fig. 7.30. Diagrama cazurilor de utilizare (Use Case Diagram)

Diagrama cazurilor de utilizare furnizeaz un mecanism de colectare a cerinelor
de exploatare a sistemului. Ea identific utilizrile solicitate i comportamentul necesar
179
Capitol 7
pentru a susine aceste utilizri i ajut la identificarea cerinelor sistemului. Atunci cnd
este utilizat n legtur cu diagrama claselor determin limita antrenrii unui proiect n
soluii dezvoltate concurenial, de la sumar la descrieri detaliate, care sunt apoi
transformate n scenarii de cazuri de utilizare multiple.
Un scenariu de caz de utilizare este o instan a unui caz de utilizare, aa cum un
obiect este instan a unei clase. O diagram a unui caz de utilizare nu reprezint un
scenariu de caz de utilizare cu un element model, adic o reprezentare grafic. Un
scenariu de caz de utilizare este alctuit din informaii text care detaliaz evenimentele i
rspunsurile la acele evenimente pentru a satisface cazul de utilizare. Fiecare scenariu de
caz de utilizare furnizeaz o legtur vital pentru nelegerea soluiei de afaceri i a
soluiilor tehnice posibile care o susin.
Fiecare diagram a cazurilor de utilizare are cel puin un caz i un actor. Un caz
de utilizare reprezint secvena aciunilor pe care sistemul le realizeaz pentru a produce
ceva de valoare pentru actorul care interacioneaz cu sistemul. Cu alte cuvinte, un caz de
utilizare poate fi privit ca un serviciu, o utilitate sau functionalitate oferita de un sistem,
subsistem sau de o componenta a acstuia unui utilizator oarecare. Intr-o astfel de situatie,
multitudinea serviciilor sau functiunilor oferite de sistem utilizatorilor definesc
functionalitatea acelui sistem. Actorul / utilizatorul poate fi o persoan sau un alt sistem
extern. Un actor poate participa la mai mult de un caz i, invers, la acelai caz de utilizare
pot participa mai muli actori.
Entitatea ofertant de servicii privita ca sistem, subsistem sau o component a
acestuia pentru utilizatori apare ca o cutie neagr, n sensul c nu este nevoie ca ei s
cunoasc ce conine sau cum este organizat acea entitate. Utilizatorii trebuie s cunoasc
doar ce servicii i poate oferi acea entitate. Exemplu, utilizatorii finali ai unui sistem
informatic trebuie s cunoasc doar ceea ce le poate oferi sistemul, cum ar fi: elaborarea
i editarea balanei de verificare, bilanul contabil, rulajul intrrilor, rulajul ieirilor etc. i
nu cum sunt organizate datele n cadrul sistemului, metodele de acces folosite etc. Alte
exemple i mai simple ar putea fi cele referitoare la seviciile oferite de un Bancomat
(eliberare de numerar, consultare sold cont, efectuare de pli, alimentarea bancomatului
cu numerar etc.) sau un Automat de vnzare de bilete de cltorie pentru transporturi
feroviare, redat n figura 7.31.
In ambele cazuri utilizatorii nu sunt interesai s cunoasc organizarea fizic
intern a celor dou aparate ci doar serviciile posibile oferite de ele.
O diagram a cazurilor de utilizare poate conine trei tipuri de asocieri/relatii i
anume:
- asocieri de comunicare (<<communicate>>, <<comunic>>);
- asocieri de utilizare (<<uses>>, <<utilizeaz>>) sau in UML incluziune <<
include>>;
- asocieri de extindere(<<extends>>, <<extinde>>).
O asociere de comunicare arat care actor particip ntr-un caz de utilizare. Este
tipul implicit de asociere astfel nct nu este obligatorie precizarea acestuia prin
stereotipul <<comunicate>>.
Asocierea de utilizare arat c un caz de utilizare trebuie s includ
comportamentul altui caz de utilizare. Cu ajutorul stereotipului <<uses>> se evideniaz
un comportament obligatoriu, uneori mprtit n comun de mai multe cazuri de
utilizare.
180

Asocierea de extindere arat c un caz de utilizare poate include opional, n
anumite condiii, un alt caz de utilizare (de extindere) i arat dependena dintre ele.
ELIBERARE
BILETE
CONSULTARE
MERSUL
TRENURILOR
Client
CONSULTARE
CONDIII
DE TARIFARE
PRELUARE
NUMERAR
Casier
Fig. 7.31. Sistem automat de cumprare bilete
7.10.4. Diagrama claselor

Diagrama claselor este cea mai important diagram n cadrul analizei i
proiectrii orientate obiect. Scopul diagramei claselor este de a structura natura static a
claselor n termeni de atribute, operaii i asocieri (figura 7.32). Majoritatea
instrumentelor de modelare orientate obiect genereaz codul surs numai din diagrama
claselor.
Celelalte diagrame UML furnizeaz diferite puncte de vedere din care s fie
identificate atributele, operaiile i asocierile dintre clase. Ele ajut la validarea diagramei
claselor, putnd servi la clarificarea unei probleme specifice pentru o audien specific.
Celelalte diagrame din UML exist, n principal, pentru a alimenta creterea i
modificarea diagramei claselor, fiecare cu o intenie diferit.
Diagrama claselor conine clase i asocieri ntre clase. O clas este un model
pentru obiecte cu structur, comportament i relaii similare. Fiecare clas are un nume,
atribute i operaii. n general numele claselor se scriu cu litere mari.
181
Capitol 7
Fig. 7.32. Diagrama claselor (Class Diagram)

Proprietile atributelor definesc datele i pot include:
Vizibilitate (public (+), protejat (#) sau privat (-))
Tip (implementare specific limbajului tipului de atribut, cum ar fi caracter sau
ntreg)
- Valoare iniial (valoare cu care se iniializeaz obiectul)
- irul de proprieti (valori care se aplica atributului, cum ar fi o serie de numere)
Proprietile operaiilor definesc comportamentul i pot include:
- Vizibilitate (public, protejat sau privat)
- Lista parametrilor (elemente transmise operaiei care includ tipul su propriu i
valoarea iniial)
- Tipul de rezultat (implementare specific limbajului tipului de atribut a valorii
rezultate dintr-o operaie)
- irul de proprieti (valori care se aplic argumentului n lista de parametri)
O clas reprezint cel mai important bloc (structur) dintr-un sistem orientat
obiect. i totui, n UML clasele sunt doar un tip de clasificatori denumire dat mai
multor structuri (blocuri) UML. Un clasificator este un mecanism care descrie
caracteristicile structurale i funcionale (comportamentale). Clasificatorii includ clase,
interfee, tipuri de date, semnale(signal), componente, noduri, cazuri de utilizare i
subsisteme.
O clas este o descriere a unui set de obiecte care au aceleai atribute, operaii,
relaii i semantic. UML mai are i ali clasificatori n afar de clase i anume:
- Interfaa (interface) - o colecie de operaii care sunt folosite pentru a specifica un
serviciu al unei clase sau componente;
- Tip de date (data type) - un tip cu valori care nu au o anumita identitate, inclusiv
tipurile de date primare (cum ar fi numeric sau string), ca de altfel i enumerrile;
- Semnal (signal) - specificaia unui stimul asincron comunicat ntre instane;
- Componenta (component) - partea fizic i substituibil a unui sistem din care
face parte i care asigur realizarea unui set de interfee;
- Nod (node) - elementul fizic care exist la execuie i care reprezint o resurs de
calcul, de obicei avnd memorie si procesor;
-
182

-
Cazuri de utilizare - descrierea unui set de secvene a aciunilor;

Subsistem - un grup de elemente care constituie specificaia comportamental.
n UML, clasificatorii, deci implicit i clasele, se caracterizeaz prin urmtoarele
proprieti: vizibilitatea, scopul i multiplicitatea.
Vizibilitatea unui clasificator este acea caracteristic care specific dac acesta
poate fi folosit sau nu de ali clasificatori.
Exist trei niveluri de vizibilitate n UML:
- public (+) - are acces orice alt clasificator;
- protected (#) - are acces orice descendent;
- private (-) - numai clasificatorul nsui poate folosi aceast caracteristic.
Scopul determin dac elementul apare n fiecare instan a clasificatorului sau
exista o singur instan a elementului pentru toate instanele clasificatorului.
n UML, dup acest scop, se pot specifica doua tipuri de clasificatori:
- instance valori distincte ale elementului pentru fiecare instan a
clasificatorului;
- classifier o singur valoare pentru toate instanele.
n UML se indic faptul c o clas este abstract scriindu-i numele italic. O clas
concret (normala) este scrisa cu fonturi normale. O clas care nu are descendeni (o clas
frunz) este specificat scriind leaf sub numele clasei. O clas care nu are ascendeni se
numete clasa rdcin i se specific scriind root sub numele clasei.
Operaiile au proprieti similare (vizibilitatea i scopul). De obicei o operaie e
polimorf, ceea ce nseamn c ntr-o ierarhie de clase poi specifica operaii cu aceeai
semntur n puncte diferite din ierarhie. Operaiile din clasele copii suprancarc
operaiile din clasele printe. Operaiile, deci, pot fi: abstracte (ex.: funciile virtuale din
C++) i concrete (leaf) operaia nu poate fi suprascris (ex.: operaii nonvirtuale din C+
+).
Multiplicitatea reprezint numrul de instane al unei clase. Exist clase:
- cu zero instane, este o clas utilitar care confer doar atribute i operaii;
- cu o singur instan, singleton class;
- cu un numr dat de instane;
- cu multe instane (cazul implicit).
Atragem atenia c n acest context multiplicitatea are o alt semnificaie fa de
aceeai proprietate aplicat asocierilor .
Multiplicitatea se specific scriind un numr n colul dreapta al clasei. Ea se
poate aplica i atributelor scriind n paranteze o expresie dup numele atributului.
n UML sintaxa unui atribut este:
[vizibilitate] nume [multiplicitate] [:tip] [=valoare iniial] [(ir-de-proprieti }]
Exist trei tipuri de proprieti definite pentru atribute:
- changeable, fr restricii de modificare;
- addOnly, pentru atribute cu multiplicitate mai mare ca unu odat creat nu mai
poate fi ters sau modificat;
- frozen - valoarea atributului nu poate fi modificat (ex.: constante din C++).
Sintaxa unei operaii n UML este:
[vizibilitate] nume [(lista-parametri)] [:tip-returnat] [{ir-de-proprieti}]
n semntura unei operaii se pot specifica unul sau mai muli parametrii conform
urmtoarei sintaxe:
183
Capitol 7
[direcie] nume :tip [=valoare implicit]
Direcia poate fi: in (parametru de intrare), out (parametru de ieire), in-out
(parametru de intrare care poate fi modificat).
Exist patru proprieti care pot fi folosite pentru operaii:
- isQuery, starea sistemului rmne neschimbat;
- sequential, trebuie coordonat apelul operaiei astfel nct s se execute doar una la
un moment dat,
- guarded, semantica i integritatea obiectu1ui este garantat n prezena mai multor
fluxuri (operaii executate n acelai timp), este redus la un ape1 secvenial
executndu-se cte una pe rnd,
- concurrent se pot apela de mai multe ori din fluxuri concurente.
Ultimele trei proprieti sunt relevante doar n prezena obiectelor active,
proceselor i fluxurilor de execuie (threads).
Clasele template sunt elemente parametrizate (figura 7.33). Rezultatul instanierii
unei clase template este o clas care poate fi folosit ca orice alt clas.
Fig. 7.33. Notaii UML pentru clasele template

Figura 7.33 indic modul de scriere n UML a claselor template. Clasele template
se pot specifica implicit prin nume sau utiliznd bind care arat c sursa instaniaz
template-ul pentru parametrii actuali.
7.10.5. Diagrama obiectelor

Diagrama obiectelor modeleaz instanele elementelor coninute n diagramele de
clase. O diagram obiectual reprezint un set de obiecte i relaiile dintre acestea la un
anumit moment.
O instan este o manifestare concret a unei abstractizri a crui set de operaii
poate fi aplicat i care are o stare care arat efectele operaiilor. Instana i obiectul sunt
sinonime. Grafic, o instan este reprezentat subliniindu-i numele.
Cele mai multe instane modelate cu UML sunt instane ale claselor (i se numesc
obiecte), dei exist i instane de componente, noduri, cazuri de utilizare, asocieri.
Instanele modelate se plaseaz n diagrame obiectuale.
Operaiile care se fac asupra unui obiect sunt definite n abstractizarea obiectului.
184

n funcie de motenire operaiile pot sau nu fi polimorfe.
Un obiect are o stare care reprezint proprietile obiectului (cele statice de
obicei) i valorile curente (dinamice) ale acestor proprieti. Aceste proprieti includ
atributele obiectului i prile lui agregate. Deci, starea unui obiect este dinamic.
UML definete dou stereotipuri standard care se aplic relaiilor de dependen
ntre obiecte i ntre clase:
- instanceOf - obiectul client este o instan a clasificatorului furnizor;
- instantiate - clasa client creeaz o instan a clasei furnizor.
Exist dou stereotipuri relativ la obiectele care se aplic mesaje i tranziii:
- become - clientul este acelai obiect cu furnizorul, dar la un moment ulterior i cu
valori, stri sau roluri diferite;
- copy - obiectul client este o carie exacta, dar independenta a obiectului furnizor.
UML definete restricii standard care se aplic obiectelor:
tranzient - o instan a unui rol este creat n timpul execuiei, dar e distrus naintea
terminrii execuiei.
Diagramele obiectuale conin obiecte i legturi. Ca i celelalte diagrame, poate
conine note i restricii. Mai pot conine anumite pachete sau subsisteme, fiecare fiind
folosite pentru a grupa elementele modelului.
Aceste diagrame se folosesc pentru modelarea static a unui sistem, ca diagramele
de clase, dar din perspectiva unor instane reale sau prototip.
7.10.6. Diagrama de secven

Scenariile cazurilor de utilizare se dezvolt n mod natural din diagrama de
secven. Diagramele de secven transform evenimentele identificate n scenariile
cazurilor de utilizare ntr-o reprezentare grafic a utilizrilor sistemului de ctre actor
(figura 7.34). Fiecare eveniment are ca rezultat un mesaj trimis unui obiect cu perspectiva
c acel obiect va realiza o operaie. Rafinarea operaiei i a atributelor utilizate n
semntura operaiei (ca argumente) actualizeaz clasa n diagrama claselor. Identificarea
i definirea operaiilor bazate pe evenimente furnizeaz capacitatea de urmrire napoi la
cazul de utilizare.
Diagrama de secven descrie cronologic interaciunea obiectelor, identificnd
mesajele schimbate ntre obiecte ca rspuns la un eveniment, mpreun cu secvena
mesajelor. Intenia este de a stabili limitele contextuale ale scenariului cazurilor de
utilizare. Este prima vizualizare a intercomunicrii claselor pentru un anumit scenariu al
cazurilor de utilizare. Scopul nu este captarea imediat a operaiilor, ci nelegerea ordinii
evenimentelor pentru a parcurge ntregul scenariu. Pe msur ce ordonarea devine stabil,
un eveniment devine o operaie specific pe care o iniializeaz obiectul receptor.
Diagramele de secven sunt recomandate pentru realizarea de specificaii n timp
real i pentru scenarii complexe. O diagram de secven avansat arat, de asemenea,
execuia condiional.
Diagrama de secven listeaz obiectele diagramelor de secven implicate ntr-un
scenariu al cazurilor de utilizare n partea superioar de la stnga ctre dreapta. Cnd se
include numele clasei cu numele obiectului, se separ clasa de obiect prin ":".
Se plaseaz mesajele schimbate ntre obiecte, pe vertical de sus n jos. Perioada
de existen se propag n jos, de la fiecare obiect. Pentru fiecare pas n scenariul
185
Capitol 7
cazurilor de utilizare, un obiect trimite mesajul din linia sa de viaa ctre linia de viaa a
unui alt obiect. Mesajul conine informaii necesare obiectului doi s acioneze. Cu alte
cuvinte, mesajul declaneaz o aciune n obiectul receptor. Un obiect poate s fie att
receptor ct i emitor (recursiv). Opional se poate include un actor care s participe n
scenariul cazurilor de utilizare ca fiind un obiect care trimite i primete mesajele. Un
singur pas n timpul scenariului cazurilor de utilizare uneori poate crea sau distruge un
obiect. Linia de via a obiectului se monitorizeaz prin alinierea vertical a obiectului cu
pasul su de instaniere. Se marcheaz cu X sfritul liniei de via, adic pasul n care
obiectul este distrus.
Fig. 7.34. Diagrama de secven (Sequence Diagram)

Dreptunghiul de-a lungul liniei de via a obiectului arat durata aciunii, numit
activare sau amplificarea controlului, ncepnd cu mesajul primit i terminnd cu mesajul
trimis.
Forma diferit a sgeilor reprezint tipuri diferite ale mesajelor. Mesajul sincron,
unde obiectul care l-a trimis ateapt rspunsul de la obiectul care l-a recepionat, este
reprezentat prin urmtoarea sgeat:
Sgeata mesajului de rspuns are aceeai form. Cnd obiectul care trimite
mesajul nu ateapt rspunsul, cazul mesajului asincron, sgeata are urmtoarea forma:
Se spune c procedura are vrful de sgeat substituit. Mesajul de rspuns nu are

nici un vrf pe sgeat i n schimb are liniua vertical plasat n apropierea mesajului
186

original trimis. Daca paii se repet, mesajele se plaseaz n interiorul unui dreptunghi. Se
poate aduga textul iteraiei pentru indicarea numrului de iteraii i a condiiei de ieire.
Textul are forma: [i:=1..n] cu semnificaia: repetare folosind variabila i, de la 1 pn la
un numr n.
7.10.7. Diagrama de stare

Modeleaz starea dinamic a unui obiect specific. Diagrama de stare const din
stri, aciuni, activiti i tranziii (figura 7.35).
Fig. 7.35. Diagrama de stare (Statechart Diagram)

Diagrama de stare identific evenimentele care fac tranziia unui obiect dintr-o
stare n alta. Conform UML, o stare este o condiie sau o situaie din momentul
existenei unui obiect care satisface n acel moment anumite condiii, efectueaz anumite
activiti sau ateapt anumite evenimente. Diagrama de stare descrie toate operaiile i
atributele unei clase n timpul unui eveniment. Diagrama identific stimulii care
declaneaz aciunea. Diagrama include numele strii, oricrei variabile, n timp ce
obiectul este n funciune, i evenimentul care declaneaz tranziia la o nou stare.
Dreptunghiul cu marginile rotunjite reprezint stri distincte. Orice diagram de
stare include o stare iniial reprezentat printr-un cerc mic de culoare neagr i o stare
final reprezentat prin acelai cerc dar inclus ntr-un cerc puin mai mare. Starea iniial
apare la crearea obiectului. Starea final apare la dispariia obiectului.
Diagrama de stare identific evenimentele care fac tranziia unui obiect dintr-o
stare n alta. Conform UML, o stare este o condiie sau o situaie din momentul
existenei unui obiect care satisface n acel moment anumite condiii, efectueaz anumite
activiti sau ateapt anumite evenimente. Diagrama de stare descrie toate operaiile i
atributele unei clase n timpul unui eveniment. Diagrama identific stimulii care
187
Capitol 7
declaneaz aciunea. Diagrama include numele strii, oricrei variabile, n timp ce
obiectul este n funciune, i evenimentul care declaneaz tranziia la o nou stare.
Dreptunghiul cu marginile rotunjite reprezint stri distincte. Orice diagram de
stare include o stare iniial reprezentat printr-un cerc mic de culoare neagr i o stare
final reprezentat prin acelai cerc dar inclus ntr-un cerc puin mai mare. Starea iniial
apare la crearea obiectului. Starea final apare la dispariia obiectului.
Cu excepia strii iniiale i a celei finale fiecare stare are un nume, atributele
proprii unei stri, aciunile i activitile efectuate. Acestor aciuni i activiti le este
atribuit un nume de eveniment, precum i argumente i expresii ale aciunii. Slash-ul "I",
separ expresiile aciunii de la numele evenimentului i argumentele. Aciuni speciale
includ:
- Entry / intrare - aciune efectuat la intrare ntr-o stare
- Exit / ieire - aciune efectuata la ieire dintr-o stare
- Do / aciune efectuat aflndu-se ntr-o stare; evenimentele externe pot ntrerupe
aciunile Do.
Obiectul tranziteaz dintr-o stare n alta cnd apare un eveniment i cnd sunt
ndeplinite anumite condiii. Tranziia este artat cu liniue simple de la o stare existent
ctre o stare de intrare / int. Tranziia conine:
- semntura unui eveniment care include un nume i argumentele separate de
virgule care se afl ntre paranteze
- o condiie de securitate opional care interzice tranziia de stare pn cnd nu
sunt ndeplinite toate condiiile
- o aciune introdus cu slash /
n timpul tranziiei se execut o aciune. Aciunea poate s fie o operaie efectuat
de obiect, un mesaj trimis altui obiect, sau o condiie n cadrul obiectului care
declaneaz schimbarea strii. Aciunea nsi poate include o semntur cnd aciunea
trimite un mesaj altui obiect. Expresia aciunii poate include obiectul receptor i
parametrii transmii acelui obiect receptor. O sgeat reprezint trimiterea unui mesaj
ctre un alt obiect. Acest mesaj poate fi trimis de la obiect n timp ce este ntr-o anumit
stare sau n timpul tranziiei.
7.10.8. Diagrama de colaborare

Diagrama de colaborare descrie o examinare non-secvenial a modului n care
interacioneaz obiectul. Diagrama de colaborare suport multiple modaliti de modelare
a obiectului. O modalitate arat modul n care obiectele colaboreaz n cadrul unui singur
scenariu al cazurilor de utilizare similar cu diagrama de secven. O interaciune
interesant se produce ntre diagramele de secven i diagramele de colaborare,
rezultnd operaiuni intensificate i descoperirea unor atribute adiionale. Ambele
diagrame furnizeaz puncte de vedere diferite ale aceleiai informaii. Ambele arat
implementarea unui scenariu al cazului de utilizare. Diagrama de colaborare filtreaz
timpul sau examinarea secvenial a scenariului pentru a studia asocierile statice i
comportamentele dinamice ale obiectelor implicate n interaciune. Avem tendina s
gndim secvenial, dar cteodat, procesele nu sunt att de procedurale cum ni le
imaginm. Utilizarea diagramei de colaborare poate ajuta la clarificarea contextului.
Diagrama de colaborare poate fi utilizat pentru a arta legtura tuturor
188

operaiunilor unei anumite clase. Pentru fiecare operaie, este artat obiectul int al
operaiei i orice alt obiect pe care l solicit pentru a implementa operaia. Diagrama de
colaborare, astfel, devine un context al tuturor obiectelor i al asocierilor care
interacioneaz cu un obiect (figura 7.36).
Fig. 7.36. Diagrama de colaborare (Collaboration Diagram)

Deoarece permite focalizarea asupra unei anumite clase, diagrama de colaborare
ajut la rafinarea diagramei claselor, adugnd atribute i operaii. Furnizeaz, de
asemenea, informaii cu privire la ceea ce face o clas atunci cnd valideaz codul asociat
acesteia.
Notaia UML a diagramei de colaborare este asemntoare cu diagrama de
secven cu obiecte, mesaje i semnturi. Fiecare mesaj poate include un numr
secvenial care s ordoneze etapele colaborrii. Virgulele separ secvenele i se
termina cu un slash /. Un predecesor n numrul secvenei indic faptul c alt mesaj
trebuie completat naintea transmiterii acestui mesaj.
Diagrama de colaborare poate arta un comportament repetat cu un asterisc, *,
urmat de numrul de iteraii i de condiia de ieire ncadrat ntre paranteze, de exemplu,
[i:= 1..n].
7.10.9. Diagrama de activitate

O diagram de activitate permite o mai bun nelegere a operaiilor, n special a
celor foarte complexe. Diagramele de activitate permit mai buna nelegere a detaliilor
din cadrul unei operaii a unei clase. Diagramele de secvena i de colaborare nu capteaz
acest nivel de detaliere suficient de exact pentru ca ele arat doar mesajele schimbate
ntre obiecte, nu i detaliile asociate acestor obiecte. Alte activiti complexe pot necesita
un mai mare rafinament ntr-o alt diagram de activitate care s arate strile subaciunilor i sub-tranziiile.
Diagrama de activitate este un tip de grafic de stare care specific activitatea unei
anumite clase (figura 7.37).
Diferena consta n faptul ca un grafic de stare reprezint ntregul obiect, n timp
ce o diagram de activitate reprezint n mod tipic doar o operaie n cadrul unui obiect.
189
Capitol 7
Terminologia diagramei de activitate este uor confundat eu terminologia diagramei de
stare ntruct ambele utilizeaz termenul stri. Starea din cadrul diagramei de activitate
este stare a unei aciuni, noiune distinct de stare a obiectului.
Fig.7.37. Diagrama de activitate (Activity Diagram)

Starea aciunii reprezint starea unei activiti n cadrul unei operaii. Descrie
descompunerea strii de aciune i tranziiile n cadrul unei anumite stri a obiectului, mai
mult dect de la o stare la alta. Descompunerea strii nu nseamn c obiectul i modific
starea. O aciune a strii reprezint mai degrab, prelucrarea intern care intervine n
timpul aciunii sau activitii surs. Procesarea intern, mai mult dect un eveniment
extern, declaneaz tranziia de la o stare a aciunii la alta. Diagrama de activitate este
utilizat pentru a arata aceast prelucrare intern.
S lum, drept exemplu, un automat. Cnd consumatorul introduce banii ntr-un
automat, activitatea de a da consumatorului un produs poate traversa mai multe aciuni de
stare. De exemplu, oferirea restului, lsarea produsului s cad n tav, avansarea liniei de
produse. Totui, nici una dintre aceste stri ale aciunii nu reprezint stare a obiectului
automatului (ateptarea seleciei, livrarea produsului).
Starea aciunii poate fi declanat de :
- Completarea unei operaii,
- Completarea unei stri, a unei aciuni anterioare sau
- Disponibilitatea unui obiect (starea necesar unei aciuni pentru a ncepe).
Activitatea const n etape procedurale sau operaii declanate mai degrab de
prelucrarea intern dect de evenimente externe. O stare specific unui obiect sau
completarea uneia din operaiile sale declaneaz o operaie, o aciune n cadrul unei stri
a aciunii este deseori ea nsi o operaie. Cnd se termin o aciune, poate face un obiect
190

disponibil pentru o aciune urmtoare. Cnd se ntmpl acest lucru, activitatea s-a mutat
ctre starea sa de aciune urmtoare.
Un dreptunghi cu colurile rotunjite nconjoar aciunea; capetele deschise ale
sgeilor indic fluxul controlului. Poate include atributele utilizate de o aciune, dar
poate doar s utilizeze atributele i link-urile obiectului care le deine (de exemplu,
obiectul pentru care se definete activitatea).
O diagram de activitate poate avea ramuri de control comune sau separate.
Aceste fluxuri de aciune au drept etichet condiia care declaneaz fluxul. Un diamant
deschis furnizeaz notaia pentru o decizie n care fluxurile multiple de control ale
aciunilor diferite eticheteaz condiiile deciziei.
7.10.10. Diagrama componentelor

Diagrama componentelor adun informaiile din diagrama claselor pentru a crea
componente. Diagrama componentelor modeleaz dependena componentei software n
funcie de codul sursa, codul binar i componentele executabile (figura 7.38).
Notaia UML pentru componente este dreptunghiul cu dou dreptunghiuri mai
mici scoase n afar, pe una din pri. O component are un nume i opional un tip
separate prin :. Componenta poate include obiectele pe care le conine.
Un vrf de sgeat deschis de la o component la alta indic o dependen a sursei
de int. O relaie de dependen reprezentat de un cerc deschis i o eticheta de interfa
pot fi trasate ctre interfaa obiectului; aceasta este iniierea dependenei. O dependen
poate fi de asemenea trasat direct ctre component fr trecerea printr-o interfa;
aceasta este o dependen de compilare.
Fig. 7.38. Diagrama componentelor (Component Diagram)
191
Capitol 7
7.10.11. Diagrama de desfurare

Componentele sunt "plasate" pe echipamente hardware prin intermediul diagramei
de desfurare. Diagrama de desfurare modeleaz procesoare i echipamente fizice,
securitatea i componentele care sunt plasate pe procesoarele fizice (figura 7.39).
Fig.a 7.39. Diagrama de desfurare (Deployment Diagram)

Diagrama de desfurare reprezint partiionarea componentelor i a obiectelor
active (de exemplu, o baza de date) pe locaia lor fizic. Acest tip de diagram detaliaz
locul de amplasare a componentelor n cadrul infrastructurii sistemului. Cel mai adesea
sunt definite mai multe diagrame de desfurare independente.
Diagrama de desfurare utilizeaz noduri pentru a reprezenta procesoare i
echipamente. Fiecare nod are un nume i, opional, un tip, separate de dou puncte, :.
O linie continu de la un nod la altul indic faptul c nodurile comunic, de
exemplu, printr-un canal sau o reea. Un vrf de sgeat deschis indic faptul c o
component comunic cu un obiect activ.
7.10.12. Diagrama pachetelor

UML furnizeaz mijloace de grupare a elementelor din cadrul diagramelor,
numite pachete. ntr-un pachet pot fi ambalate alte pachete, clase, cazuri de utilizare,
colaborri etc. Un pachet arat doar structurile pe care le conine (figura 7.40).
Un pachet nu arat comportamentul elementelor sale. Un element de modelare
aparine unui singur pachet, dar alte pachete pot consulta acest element. Dac se arat
explicit coninutul pachetului, atunci numele pachetului se trece pe etichet. Un pachet
este un mecanism destinat unor scopuri generale, care organizeaz elementele n grupuri.
192

Fiecare pachet are un nume care poate fi simplu sau cu cale (path name). De exemplu:
nume simplu -client
nume cale
-senzori :: viziuni
Un pachet poate conine clase, interfee, componente, noduri, colaborri, cazuri de
utilizare, diagrame i chiar alte pachete. A conine este o relaie compus, ceea ce
nseamn c fiecare element este declarat n pachet. Din punct de vedere al vizibilitii,
pachetele se comport precum clasele.
Importul unui pachet - Presupunem ca avem clasa A n pachetul A i clasa B n
pachetul B. Fiecare sunt elemente publice ale pachetului su. Daca pachetul A import
pachetul B, A poate vedea B, dar B nu poate vedea A. Importul acord o permisiune eu un
singur sens elementelor unei clase asupra elementelor altei clase.
Exist dou tipuri de relaii ntre pachete: importul i dependenele acces, folosite
pentru a importa ntr-un pachet elementele exportate de altul i generalizrile, folosite
pentru a specifica familii de pachete. Un pachet specializat poate fi folosit oriunde este
folosit un pachet.
UML definete cinci stereotipuri care se aplic pachetelor:
- facade - un pachet care este doar o vizualizare a altui pachet;
- framework - un pachet care conine n principal modele (patterns);
- stub - este un proxy pentru coninutul public al altui pachet;
- subsystem - un pachet ce reprezint o parte independent a sistemului modelat;
- system - un pachet ce reprezint tot sistemul modelat.
Fig. 7.40. Diagrama pachet (Package Diagram)
193
Capitol 7
7.10.13. Interaciunea dintre diagramele UML

Pe parcursul ciclului de via al unui sistem informatic diagramele UML
interacioneaz ntre ele sau cu alte modele (modelul entitate asociere), figura 7.41.
Cazurile de utilizare i diagramele de interaciune. Toate procesele care trebuie
executate de sistem se regsesc ntr-un caz de utilizare. Procesele sunt descrise apoi
textual sau printr-o succesiune de pai. Pentru modelarea grafic a scenariilor poate fi
utilizat diagrama de activitate. Odat ce comportamentul sistemului a fost astfel
surprins, cazurile de utilizare sunt mai departe analizate pentru a identifica cum
interacioneaz obiectele pentru a modela acest comportament. Diagramele de secven i
de colaborare sunt utilizate pentru a modela aceast interaciune ntre obiecte.
Clasele, obiectele i diagramele de implementare. Pe msur ce sunt identificate
obiectele, acestea pot fi grupate i clasificate n cadrul diagramei claselor i a obiectelor.
Diagrama claselor devine astfel elementul central al procesului de proiectare orientat
obiect, fiind diagrama care descrie structura static a sistemului. Diagrama claselor poate
fi mprit pe trei straturi care s evidenieze clasele ce descriu interfaa cu utilizatorul
(business layer), clasele responsabile de logica aplicaiei (application layer) i clasele
pentru stocarea datelor (data layer). Diagrama componentelor este utilizat pentru a grupa
clasele n componente sau module. Distribuirea fizic n ansamblul sistemului este
modelat cu ajutorul diagramei de desfurare.
Fie CRC o extensie informal a UML-ului. Ca extensie a UML-ului, tehnica
fielor CRC poate fi utilizat pentru a supune sistemul analizei orientate pe
responsabiliti. Clasele sunt analizate, selectate i rafinate pe baza responsabilitilor lor
n cadrul sistemului i a claselor cu care acestea trebuie s colaboreze pentru a-i
ndeplini aceste responsabiliti.
Diagramele de stare. Cu ajutorul diagramelor de stare se modeleaz
comportamentul n timp real al fiecrei clase cu un comportament semnificativ dinamic.
Diagrama de activitate poate fi i ea folosit, de aceast dat ca extensie a diagramei de
stare, pentru a detalia aciunile de rspuns ale obiectelor la evenimente interne acestora.
Diagrama de activitate poate fi utilizat i pentru a reprezenta grafic aciunile metodelor
claselor.
Implementarea proiectrii (realizarea sistemului). Realizarea sistemului
presupune transformarea informaiei cuprins n mai multe modele UML n cod i
structur a bazei de date. n cazul unui sistem de mari dimensiuni este extrem de util
descompunerea acestuia n trei subsisteme: subsistemul afacerii, care include i
elementele de interfa cu utilizatorul (business layer), subsistemul aplicaiei, care include
obiectele de implementare a funcionalitii sistemului (application layer) i subsistemul
datelor, care include structura bazei de date i obiectele de acces la aceast structur (data
layer).
Implementarea aplicaiei (codificarea). Diagrama claselor este utilizat pentru a
genera scheletul aplicaiei n limbajul de programare ales cu ajutorul unui CASE.
Diagramele de interaciune, de stare i de activitate furnizeaz informaii suplimentare
pentru detalierea prii procedurale a codului.
194
Baza de date
obiectuala
proiectarea GUI
Interfata
grafica
Cerinte
Diagrama
claselor
Modele de
date fizice
Inginerie inversa
Baza de date
relationala
Metode de acces
Posibila generare de cod
Diagrame de interactiune
Cazuri de
utilizare
Modele de
date relationale
Codificarea
Diagrama de
secventa
Metode de acces
Diagrame de implementare
Diagrama de
stare
Diagrama de
colaborare
Diagrama de
stare
Diagrama de
stare
Posibila translatare de cod
Carduri CRC
Specificarea procesului de afaceri
Diagrama de
activitate
Test
Fig. 7.41: Interaciunea dintre diagramele UML, tehnica fielor CRC i modelul entitate asociere
Capitol 7
Proiectarea bazei de date. Stratul datelor (data layer) din diagrama claselor poate fi
utilizat pentru a proiecta direct o baz de date orientat obiect sau pentru a construi
corespunztor un model entitate asociere (ER - Entity Relationship) pentru o analiz mai
detaliat a relaiilor. Pe baza modelului entitate asociere se poate construi apoi modelul fizic al
bazei de date relaionale.
Testarea cerinelor. Diagrama cazurilor de utilizare este folosit i pentru a testa dac
sistemul rspunde cerinelor iniiale. Se parcurg toate cazurile de utilizare pentru a vedea dac
sistemul corespunde cerinelor clientului.
7.10.14. Avantajele utilizrii UML

Dei nu garanteaz succesul unui proiect informatic, UML poate contribui la reducerea
costurilor de instruire i schimbare a instrumentelor de lucru atunci cnd se face trecerea de la
un proiect la altul sau de la o organizaie la alta. UML ofer o baz pentru integrarea
instrumentelor, proceselor i domeniilor. n primul rnd, UML asigur o terminologie unic i
permite realizatorilor de sisteme s se concentreze asupra obiectivelor proiectelor i nu asupra
instrumentelor de modelare.
Aa cum a fost precizat n documentul UML Summary, Version 1.1, elaborat la 1
septembrie 1997 de Rational Software i ceilali realizatori, scopurile pentru care a fost creat
UML sunt urmtoarele:
- s pun la dispoziia utilizatorilor un limbaj de modelare vizual uor de folosit,
expresiv. Este foarte important ca standardul pentru analiz i proiectare s suporte un
limbaj de modelare care s fie folosit pentru realizarea de taskuri generale de
modelare. Dac standardul ofer numai o descriere de meta-nivel care reclam
ajustarea la un anumit set de concepte de modelare, atunci nu se poate realiza
schimbul de modele fr pierdere de informaii;
- s asigure extensibilitatea precum i mecanismele de specializare prin care s fie
extinse conceptele de baz;
- s permit formularea de specificaii independente de un anumit limbaj de programare
i de procesele de realizare a sistemului;
- s ofere o baz formal pentru nelegerea limbajului de modelare;
- s ncurajeze creterea pieei instrumentelor orientate pe obiecte;
- s suporte concepte, precum: componente, colaborri, cadre;
- s permit diseminarea celor mai bune practici n domeniul realizrii sistemelor
software.
UML reunete conceptele din Booch, OMT i OOSE. Rezultatul l reprezint un
limbaj de modelare posibil de utilizat de ctre utilizatorii acestor metode, dar i a altor metode
orientate pe obiecte.
n plus, UML extinde posibilitile oferite de metodele menionate mai sus. De
exemplu, prin utilizarea UML se poate realiza modelarea sistemelor concurente i a celor
distribuite.
UML asigur un standard de limbaj, nu i de proces. Dei UML poate fi folosit n
cadrul unei metodologii, experiena echipei de proiect i specificitatea domeniului pot reclama
utilizarea unor procese specifice. UML asigur un acelai meta-model, care unific semantica
i o aceeai notaie, pentru interpretarea acestei semantici. UML promoveaz construirea
iterativ i incremental a sistemelor software dirijat de cazurile de utilizare i centrat pe
arhitectura acestor sisteme.
196
7.11. Modelarea orientat obiect

Un model orientat obiect are la baz obiecte. Un obiect ncapsuleaz att date cat i
comportament, ceea ce nseamn c analistul poate folosi abordarea orientat obiect att
pentru modelarea datelor ct i pentru modelarea proceselor. Pentru c permite analistului de
sistem s surprind ambele aspecte ntr-o singur reprezentare i pentru c ofer i alte
beneficii cum ar fi mecanismul motenirii i reutilizarea codului, modelarea orientat obiect
ofer un mediu puternic pentru dezvoltarea sistemelor complexe. Teoria obiectelor,
ncapsularea, motenirea i polimorfismul stau la baza dezvoltrii obiectuale a sistemelor.
Exist o varietate larg de metodologii i tehnici utilizate de ctre un analist de sistem
n procesul de analiz i proiectare orientat obiect.
Referitor la consistena modelelor, n alte abordri cum ar fi analiza i proiectarea
structurat modelele care se dezvolt nu folosesc notaii comune i sunt slab conectate ntre
ele, tranziia de la un model la altul fcndu-se n mod abrupt. Abordarea orientat obiect
ofer continuitate n ceea ce privete tranziia ntre modelele analizei, proiectrii i ale
implementrii. De exemplu, trecerea de la analiza orientat obiect la proiectarea orientat
obiect presupune mbogirea modelului de analiz cu detalii referitoare la implementare i nu
dezvoltarea unui nou model.
7.11.1. Modelarea domeniului (mediului) Domain Model

Pentru a aprofunda nelegerea contextului n care va funciona sistemul se utilizeaz
modelul mediului (domeniului). Acest model cuprinde cele mai importante clase ntlnite n
domeniul economic pentru care se realizeaz sistemul informatic i are un caracter de
generalitate. Clasele se identific fie din cerinele exprimate de beneficiar, fie din
intervievarea unor experi n domeniu. Este unul dintre primele modele utilizate n analiza
orientat obiect i are menirea de a sistematiza expertiza din domeniul analizat i a o transmite
sistemului informatic ce urmeaz a fi proiectat.
Sunt trei tipuri de clase care pot fi puse n eviden n acest model:
- clase ce modeleaz obiecte sau concepte utilizate n cadrul sistemului informaional
analizat, cum ar fi comand, contract, factur;
- obiecte sau concepte din lumea real pe care sistemul trebuie s le nregistreze i s
in cont de ele, cum ar fi cursul de schimb al monedei de referin;
- evenimente ce intervin i afecteaz starea sistemului, cum ar fi plasarea unei comenzi,
plata unei facturi.
Pentru descrierea acestui model vom utiliza preponderent diagrama claselor, dintre
instrumentele puse la dispoziie de UML. Aa cum am vzut n capitolul anterior diagrama
claselor reprezint att entitile domeniului (clasele) ct i relaiile dintre acestea (asocierile),
figura 7.42.
Aa cu am mai precizat scopul principal al acestui model este nelegerea contextului
sistemului. De aceea la realizarea modelului mediului (domeniului) este de preferat s
participe att specialiti n modelare ct i experi din domeniul analizat. Din acest punct de
vedere se remarc asemnarea cu etapa de analiz specific metodologiilor structurate. Aa
cum tim deja, conform unui vechi principiu al analizei sistemelor, n acest proces este de
preferat s fie implicai cei mai buni specialiti n domeniu (experii). Modelul mediului va
conine cele mai importante clase ale domeniului. Odat cu ntocmirea diagramei claselor se
ntocmete i un dicionar al claselor n care se va preciza semnificaia fiecrei clase pentru a
se folosi o terminologie unitar. Se prefer aceast formul pentru a se evita obinerea unui
model prea mare i greu de utilizat.
197
Capitol 7
Uneori, pentru sistemele de mici dimensiuni, se renun chiar la diagrama claselor
pentru modelul mediului, ntocmindu-se doar acest dicionar de termeni.
Dicionarul este deosebit de important i pentru asigurarea unui limbaj comun n
cadrul proiectului. Cu toii intuim problemele ce pot apare n comunicare datorit utilizrii
unei terminologii necunoscute de toi cei implicai n proiect.
n final trebuie s atragem atenia c la acest nivel analistul nu trebuie s insiste prea
mult pe clasele interne sistemului, acest model fiind destinat identificrii i nelegerii
cerinelor ce deriv din contextul sistemului. Modul n care sistemul va trata aceste probleme,
logica intern, urmeaz s fie detaliate n alte etape, cu ajutorul altor modele.
Modelul mediului, format din diagrama claselor domeniului i dicionarul de termeni,
poate fi utilizat att la dezvoltarea modelului cazurilor de utilizare ct i la identificarea
claselor sistemului n etapa de analiz.
Comand
1..*
descriere
foto
cost
data comenzii
adresa livrare
1..*
Produs
pltit
Factur
cumparator
1
suma
data facturii
termen plat
vnztor
1
Cont
balan
proprietar
Fig. 7.42. Diagram a claselor ce modeleaz domeniul aplicaiei
7.11.2. Modelarea proceselor afacerii (prelucrrilor) Business

Model
Aceasta este o tehnic de modelare utilizat pentru a aprofunda nelegerea proceselor
specifice unei organizaii. Dei denumirea ar putea prea ntructva limitativ se folosete
acelai termen i pentru sistemele care nu informatizeaz o afacere, cum ar fi un sistem de
alarm sau un controler hardware.
Utiliznd UML, modelarea afacerii se poate face din dou perspective: fie prin
modelul cazurilor de utilizare, fie prin modelul obiectelor.
n cadrul modelrii cazurilor de utilizare (business use-case model) se surprinde
funcionarea sistemului din perspectiva utilizatorilor acestuia. Procesele se modeleaz prin
cazuri de utilizare, iar iniiatorii acestor procese prin actori (figura 7.43).
Modelul obiectelor (business-object model) surprinde prelucrrile din interiorul
sistemului. Descrie n detaliu cum este tratat fiecare caz de utilizare. Realizarea cazurilor de
utilizare se poate evidenia cu ajutorul diagramelor de interaciune (diagrama de secven,
diagrama de colaborare) sau al diagramei de activitate.
O entitate a sistemului existent (a afacerii) reprezint un lucru pe care utilizatorii l
acceseaz, consult, manipuleaz, realizeaz sau utilizeaz n cadrul unui caz de utilizare. O
unitate de lucru este un set de astfel de entiti care formeaz un ntreg pentru utilizatorul
198

final. Entitile i unitile de lucru sunt utilizate pentru a reprezenta aceleai concepte ca i
clasele din modelul mediului (comand, produs, factur, cont).
Sistem
Login / Logout
Utilizator
Administrator
Comand articole
Administrare
<< extends >>
<< extends >>
Actualizare baz de
date
Fig. 7.43. Modelarea proceselor afacerii cu ajutorul diagramei

cazurilor de utilizare
Fiecare utilizator, entitate sau unitate de lucru poate participa la realizarea a mai
multor cazuri de utilizare. De exemplu n figura 7.43. Utilizatorul particip la realizarea a
dou cazuri de utilizare, la fel i Administratorul.
Un astfel de model se dezvolt n doi pai:
- Realizarea modelului cazurilor de utilizare
- Detalierea modelului prin specificarea utilizatorilor, entitilor i a unitilor de lucru,
dar i a regulilor care guverneaz anumite procese sau obiecte.
Scopul este crearea unor utilizatori, entiti i uniti de lucru care rezolv problema
evideniat de cazul de utilizare eficient bine, rapid i la cel mai sczut cost posibil.
Modelarea mediului i modelarea afaceri par ntructva asemntoare, mai ales dac
ne gndim c entitile i unitile de lucru corespund claselor din modelul mediului. Exist
totui o serie de diferene, dintre care evideniem trei.
Cele dou abordri difer n primul rnd prin modul de documentare. Una se bazeaz
pe cunotinele unui expert n domeniu sau pe cunotinele despre sisteme similare, n timp ce
a doua are n vedere cerinele beneficiarului. Orice clas a modelului domeniului i regsete
originea n experiena cunosctorilor domeniului. Orice element al modelului afacerii (entitate
sau unitate de lucru) i regsete originea ntr-o cerin a beneficiarului. Acesta este i
motivul principal pentru care utiliznd cele dou abordri, n mod normal, se obin diferite
clase, atribute, metode i asocieri.
O alt deosebire ar fi c pornind la analiza domeniului vom obine mai multe
informaii despre atributele claselor i mai puine despre comportamentul acestora (clasele
domeniului vor fi srace n metode). Evident n cazul modelrii afacerii se vor identifica att
entitile i unitile de lucru (clasele), ct i utilizatorii (i operaiile pe care acetia le
ntreprind).
i nu n cele din urm, modelul afacerii fiind mult mai detaliat va fi mai bine
valorificat n etapele ce vor urma. Se pot identifica mai bine actorii i cazurile de utilizare ale
sistemului proiectat, i fiecare dintre acestea va putea fi mai bine pus n coresponden cu
cerinele sistemului.
199
Capitol 7
Dac modelul mediului abordeaz cu precdere funcionarea sistemului n contextul
acestuia, modelul afacerii i focalizeaz atenia asupra utilizatorilor i a modului cum
sistemul i deservete.
7.11.3. Modelarea cazurilor de utilizare

Un model al cazurilor de utilizare este format din actori i cazuri de utilizare. Un
actor este o entitate extern ce interacioneaz cu sistemul (similar unei entiti externe dintr-o
diagram de flux a datelor). Actorul este ceva sau cineva care schimb informaie cu sistemul.
Un actor ne este obligatoriu s fie un utilizator uman. El poate fi i un alt sistem sau un
dispozitiv hardware (ex. monitorul) cu care sistemul nostru interacioneaz sau schimb
informaii.
Un caz de utilizare este o secven de aciuni iniiate de un actor, surprinznd un
anumit mod de a folosi sistemul. Nu trebuie fcut confuzie ntre actor al sistemului i
utilizator al sistemului. Un utilizator este oricine folosete sistemul. Un actor este un rol pe
care utilizatorul l poate juca. Numele actorului trebuie s indice acest rol. Un actor este un
tip sau o clas de utilizator. Acelai utilizator poate juca mai multe roluri. De exemplu, dac
domnul Y joac dou roluri, unul de instructor iar cellalt de consultant, va fi reprezentat ca
instan a unui actor numit Instructor i ca instan a unui alt actor numit Consultant.
Actorii fiind entiti externe sistemului, ei nu pot fi descrii n detaliu. Identificarea
actorilor ajut la identificarea cazurilor de utilizare ntruct un caz de utilizare este iniiat de
un actor. Iat cteva ntrebri la care analistul de sistem trebuie s rspund pentru a
identifica cazurile de utilizare:
- Care sunt principalele aciuni executate de fiecare actor?
- Actorul va citi sau va actualiza informaia din sistem?
- Actorul va informa sistemul despre modificrile petrecute n afara acestuia?
- Actorul va fi informat de modificrile din sistem?
S considerm cazul unui sistem de nregistrare a studenilor la cursurile oferite de un
centru de instruire. Entitile externe sistemului sunt studentul care se nscrie la curs, secretara
care face nscrierea studenilor la cursuri, casiera care ncaseaz contravaloarea cursurilor i
instructorul care pred cursurile. Cazurile de utilizare asociate sistemului sunt redate n figura
7.44.
Un caz de utilizare este iniiat ntotdeauna de un actor i poate interaciona i cu ali
actori, nu numai cu cel care l-a iniiat. Cazul de utilizare trebuie s redea o funcionalitate
complet i nu numai o anumit aciune a unei funcionaliti. Transmiterea unui formular de
nscriere la un curs este parte a procesului de nregistrare la curs deci va fi inclus n cazul de
utilizare nregistrare la curs i nu se va construi un caz separat pentru aciunea transmitere
formular de nscriere.
Observm n exemplul anterior etichetarea cu simbolul <<extends>> a asocierii dintre
cele dou cazuri de utilizare ceea ce semnific faptul c opional cazul de utilizare
nregistrare la curs special extinde cazul nregistrare la curs, adugndu-i noi aciuni i
comportamente. nregistrarea unui student la un curs special necesit i permisiunea
instructorului (aciune suplimentar), pe lng paii normali de nscriere la orice curs.
Este evideniat i o relaie de utilizare prin etichetarea cu simbolul <<uses>> a
asocierii dintre cazul nregistrare la curs i cazul nepromovare cursuri obligatorii ceea ce
semnific faptul c un caz de utilizare folosete cellalt caz de utilizare atunci cnd se
execut. nscrierea la cursul Y nu este posibil dect dac studentul a promovat cursurile
pregtitoare acestuia. Cazul nregistrare la curs folosete cazul nepromovare cursuri
obligatorii pentru a verifica dac studentul a promovat cursurile pregtitoare cursului Y.
200
Diagrama cazurilor de utilizare arat care sunt toate cazurile de utilizare din sistem dar
nu indic modul n care acestea sunt realizate de ctre actori. Modelul cazurilor de utilizare
este completat de o descriere textual a fiecrui caz de utilizare, accentul punndu-se pe
interaciunea cu ali actori i mai puin pe modul n care este executat n cadrul sistemului.
Descrierea cazului de utilizare nregistrare la curs sub forma unei succesiuni de pai se face
ca n figura 7.45:
Modelarea cazurilor de utilizare permite analiza cerinelor funcionale ale sistemului,

insistnd asupra a CE trebuie s fac un sistem existent sau un nou sistem, fr s se ia n
seam i CUM o s se fac. Modelul cazurilor de utilizare este dezvoltat n faza de analiz a
ciclului de via al sistemelor orientate obiect, avnd rolul de a ajuta dezvoltatorii s neleag
cerinele funcionale ale sistemului fr s intereseze n aceast faz cum vor fi implementate
acestea. Procesul este iterativ iar stabilirea cerinelor se face n urma discuiilor cu
beneficiarul sistemului. Cazurile de utilizare controleaz toate celelalte modele. Dac
cerinele utilizatorului se modific n timpul dezvoltrii, aceste modificri sunt vizibile mai
nti n modelul cazurilor de utilizare. Modificrile n cazurile de utilizare implic modificri
i n celelalte modele. i reciproca este valabil, adic n momentul n care se fac modificri
n modele, acestea trebuie s se reflecte i la nivelul cazurilor de utilizare.
201
Capitol 7
7.11.4. Modelarea structurii statice (diagrama claselor, diagrama

obiectelor)
Diagrama claselor documenteaz structura static a sistemului; mai exact precizeaz
clasele care exist i relaiile dintre acestea, nu i modul n care interacioneaz pentru a
asigura un anumit comportament. Diagrama claselor poate de asemenea evidenia i alte
aspecte ale structurii statice, cum ar fi pachetele care ns vor fi prezentate mai trziu n cadrul
acestui capitol.
Construirea diagramei claselor presupune n primul rnd identificarea claselor din
sistem, acest proces reprezint o parte esenial a proiectrii sistemelor orientate obiect, de
succesul acestuia depinznd n mare parte succesul proiectului.
n acest sens, criteriile de apreciere a unui model al claselor sunt:
- obiectele claselor din model trebuie s poat furniza ntregul comportament cerut
sistemului;
- un bun model al claselor conine (pe ct posibil) clase stabile din domeniul obiectual,
care nu depind de funcionalitatea particular cerut la momentul proiectrii.
Poate fi utilizat orice tehnic de obinere a claselor atta timp ct modelul obinut
respect criteriile enunate. Implicit dac modelul obinut nu respect criteriile nu va fi nimeni
interesat de tehnica utilizat, orict de profesionist ar fi aceasta.
n practic e puin probabil s reueti din prima. Clasele selectate n modelul de
proiectare se vor modifica pe parcursul desfurrii procesului iterativ de dezvoltare a
sistemului.
n literatura de specialitate se propun dou metode: proiectarea orientat pe date (data
driven design) i proiectarea orientat pe funciuni (responsibility driven design). Primul tip
de metode presupune identificarea tuturor datelor din sistem i mprirea lor pe clase, nainte
de a considera funciunile acestor clase. Tehnica identificrii substantivelor este cea mai
utilizat astfel de metod. Al doilea tip de metode, orientate pe funciuni, presupune
identificarea tuturor funciunilor sistemului i mprirea lor pe clase, nainte de a considera
datele acestor clase.
Tehnica identificrii substantivelor presupune doua etape:
- Identificarea claselor candidate, selectnd din specificarea cerinelor sistemului toate
substantivele i frazele substantivale (se consider substantivele la singular i nu se
aleg fraze ce conin sau ca unici candidai).
- Se elimin candidaii considerai nepotrivii din diverse motive i se redenumesc
clasele rmase dac este necesar.
Unele dintre motivele pentru care o clas candidat ar putea fi considerat nepotrivit
sunt:
- Redundana o clas e prezent sub mai multe denumiri. Este important s ne
amintim ins c obiecte similare pot s nu fie identice. Proiectantul decide dac
lucrurile sunt suficient de diferite pentru a merita clase diferite. De exemplu, dac a
fost selectat o pereche de genul mprumut i mprumut pe termen scurt, acestea
sunt diferite, dar numai la nivelul valorii atributelor. Se recomand n acest caz
alegerea unui nume care s desemneze ntreg coninutul clasei.
- Imprecizia cnd nu se poate spune precis ce care e realitatea descris de substantivul
respectiv. Desigur, trebuie ndeprtat ambiguitatea nainte de a putea spune dac
substantivul reprezint o clas.
- Eveniment sau operaie cnd substantivul se refer la ceva ce este fcut de sistem.
Uneori aceast situaie este bine modelat de o clas, dar nu este acesta cazul obinuit.
202

-
Metalimbaj unde substantivul face parte din modul de definire a cerinelor. Vom
utiliza substantive ca cerine sau sistem ca parte a limbajului de modelare i nu
pentru a reprezenta obiecte din domeniul problemei.
Extern sistemului atunci cnd substantivul este relevant pentru a descrie funcionarea
sistemului, dar nu se refer la ceva din interiorul su.
Atribut atunci cnd este clar c substantivul desemneaz o realitate simpl, fr un
comportament interesant, care este de fapt un atribut al altei clase. Numele unui
client ar putea fi un astfel de exemplu.
Diagrama obiectelor modeleaz instanele elementelor coninute n diagramele de

clase. O diagram obiectual arat un set de obiecte i relaiile dintre acestea la un anumit
moment.
Diagramele obiectuale conin obiecte i legturi. Ca i celelalte diagrame, poate
conine note i restricii. Mai pot conine anumite pachete sau subsisteme, fiecare fiind
folosite pentru a grupa elementele modelului.
Aceste diagrame se folosesc pentru modelarea static a unui sistem, ca diagramele de
clase, dar din perspectiva unor instane reale sau prototip.
Crearea unei diagrame conceptuale se face intr-un singur mod, modelnd structura
obiectelor. Modelarea structurii obiectelor implic fotografierea obiectelor din sistem la un
anumit moment.
In figura 7.46. se prezint o posibil diagram a claselor pentru un sistem de gestiune
a comenzilor. Unii dintre clieni pot beneficia de credit comercial, dar alii trebuie s achite
nainte de livrarea comenzii (aceia pentru care operaia ClientEvaluareSituatie returneaz
valoarea slab).
Fig. 7.46. Diagrama claselor pentru sistemul de gestiune a comenzilor
203
Capitol 7
7.11.5. Modelarea dinamicii sistemului

Pentru modelarea dinamicii sistemului, UML furnizeaz dou tipuri de diagrame, i
anume diagramele de interaciune (diagrama de secven i diagrama de colaborare) i
diagramele de comportament (diagrama de stare i diagrama de activitate) . Principala menire
a acestor diagrame este de a arata cum realizeaz sistemul un caz de utilizare sau un scenariu
particular dintr-un caz de utilizare. Pentru fiecare caz de utilizare se pot realiza mai multe
scenarii (din descrierea cazului de utilizare). Pentru fiecare astfel de scenariu se pot ntocmi,
nu este obligatoriu, o diagram de secven sau o diagram de colaborare (unele dintre
instrumentele CASE pot obine o diagram din alta).
Acest tip de diagrame nlesnete nelegerea cazurilor de utilizare mai dificile. Ele pot
de asemenea susine comunicarea n cadrul echipei de proiectare, n cazul n care de o aceeai
interaciune se ocup mai multe persoane sau grupuri de persoane. Nu e de ateptat s se
dezvolte astfel de diagrame pentru fiecare caz de utilizare sau pentru fiecare operaie, doar
dac beneficiile depesc costurile. n cazul n care se dispune de un CASE ce poate utiliza
aceste diagrame la generarea de cod, atunci devine profitabil s dezvoltam diagrame de
interaciune i diagrame de comportament.
Diagramele de secven descriu modul n care obiectele interacioneaz i comunic
ntre ele. Aceste diagrame permit focalizarea ateniei asupra secvenelor de mesaje, mai precis
asupra mesajelor care sunt trimise i recepionate de ctre obiecte.
Avantajul major al diagramelor de secven, fa de diagramele de colaborare este
posibilitatea de a reprezenta grafic trecerea timpului, fiind deci indispensabile n cazul
proiectrii de sisteme n timp real.
n figura 7.47 este reprezentat un scenariu al cazului de utilizare Comand articole
dintr-un sistem de comer electronic. Scenariul presupune c validarea utilizatorului se
finalizeaz cu succes i c exist un stoc nelimitat de produse.
Diagramele de colaborare permit evidenierea att a interaciunilor ct i a legturilor

dintre un set de obiecte care colaboreaz. Att diagramele de secven ct i cele de
204

colaborare vizualizeaz interaciunile, dar diagrama de secven ia n considerare timpul, pe
cnd cea de colaborare, spaiul.
Ca i diagramele de secven, diagramele de colaborare pot fi utilizate pentru
descrierea execuiei unei operaii, a unui caz de utilizare sau a unui scenariu de interaciune n
cadrul sistemului. n acest tip de diagram nu pot fi descrise mesajele concurente i asincrone.
Pentru a putea realiza o comparare a celor dou tipuri de diagrame n figura 7.48. a fost
reprezentat acelai scenariu ca i n figura 7.47.
Pn acum nu am amintit nimic despre modelarea "deciziei" unui obiect despre ceea
ce sa fac la primirea unui mesaj. Diagramele de interaciune pot reprezenta obiecte diferite
ale aceleiai clase care primesc acelai mesaj, dar rspund diferit. Acest comportament este
rezonabil de cele mai multe ori ntruct comportamentul unui obiect poate fi afectat i de
valorile atributelor sale. Pentru a putea implementa, ntreine sau testa o c1as este necesar s
nelegem relaiile de dependen care exist ntre starea unui anumit obiect i reaciile sale la
mesajele primite sau la alte evenimente. Diagramele de stare sunt acelea care nregistreaz
aceste dependene.
Pornind de aici, se pot folosi aproximativ aceleai notaii pentru a descrie activiti
complexe. Se consider c trecerea de la o activitate la alta atunci cnd prima activitate s-a
ncheiat este similar cu trecerea unui obiect dintr-o stare ntr-alta, semnificativ diferit de
prima, atunci cnd acesta primete un mesaj. Diagramele de activitate sunt o variaiune a
diagramelor de stare, adaptate pentru a evidenia conexiunile i dependenele dintre activiti.
Ele sunt extrem de folositoare atunci cnd se apreciaz c o activitate trebuie s execute o
serie de task-uri diferite i dorim s modelm dependenele eseniale dintre acestea, nainte de
a decide n ce ordine s se execute.
Diagramele de stare au rolul de a captura ciclul de via al obiectelor, subsistemelor i

sistemelor, prin specificarea strilor n care se poate gsi un obiect i a evenimentelor (mesaje
primite, erori, condiii care devin adevrate) care-i afecteaz starea de-a lungul execuiei. O
diagram de stare poate fi ataat oricrei clase care are stri c1ar identificabile i un
comportament complex.
Presupunnd c este vorba despre un sistem contabil, diagrama ce descrie
205
Capitol 7
comportamentul clasei Factur este reprezentat n figura 7.49.
O diagram de activitate constituie o variant a diagramei de stare, cu un scop puin

diferit, acela de a evidenia aciuni i rezultate ale acestor aciuni. De fapt, diagramele de
activitate constituie o cale alternativ de descriere a interaciunilor, cu posibilitatea de
specificare a aciunilor care se vor realiza, prin precizarea urmtoarelor elemente:
- Ce fac aciunile? (modificrile strilor obiectului),
- Cnd au loc aciunile? (secvena de aciuni) i
- Unde au loc aciunile?
Diagramele de activitate pot fi utilizate i pentru a descrie cum se desfoar cazuri de
utilizare individuale i cum depind de alte cazuri de utilizare.
Diagramele de activitate pot fi folosite n mai multe scopuri i anume:
- Ilustrarea aciunilor care vor fi realizate atunci cnd este executat o operaie. Acesta
este i cel mai comun caz de utilizare a acestui tip de diagram.
- Prezentarea activitii interne a unui obiect.
- Identificarea aciunilor, care pot fi realizate n mod legat i stabilirea modului n care
aceste seturi de aciuni afecteaz obiectele din jur.
- Ilustrarea modului n care instana unui caz de utilizare poate fi realizat n termenii
aciunilor sau modificrilor intervenite n starea obiectului.
- Ilustrarea modului n care este organizat munca actorilor, care este organizarea i
obiectele folosite.
Activitile realizate la biroul de recepie a unui hotel se pot modela cu ajutorul
diagramei de activitate astfel (figura 7.50.):
206
7.12. Proiectarea BDOO component a sistemului

informatic
Este tiut faptul c orice sistem informatic sau aplicaie informativ ce opereaz cu
volume mari de date face apel la un mod sau altul de organizare a datelor. De modul de
organizare a datelor depinde n mare msur i performanele sistemului de organizare.
Organizarea datelor n baze de date orientate obiect constituie cel mai evoluat mod de
organizare. ntr-o astfel de situaie se poate spune c BDOO constituie o component
semnificativ a sistemului informatic iar proiectarea acesteia are loc n cadrul general de
proiectare a sistemului informatic.
Pentru moment ne vom referi doar la proiectarea strict a BDOO ntr-o form
simplificat privind sistemul de aprovizionare cu materii prime i materiale iar ntr-un
urmtor paragraf vom recurge la proiectarea BDOO ntr-o form extins, mult mai
cuprinztoare, pe exemplul unui sistem de rezervare i vnzri de bilete n transporturile
aeriene n concordan cu metodologia RUP.
n activitatea de proiectare a BDOO pentru aprovizionarea cu materii prime i
materiale vom adopta varianta de proiectare plecnd de la identificarea/cunoaterea cerinelor
sistemului n funcie de care vom recurge la identificarea claselor de obiecte cu structura
corespunztoare.
n concordan cu UML succesiunea pailor de urmat va fi: modelarea produselor de
afaceri, modelarea cazurilor de utilizare i modelarea structurii statice a sistemului.
7.12.1. Modelarea proceselor de afaceri

Aa dup cum s-a mai precizat, prin modelarea proceselor de afaceri se va urmri
aprofundarea i nelegerea modului de derulare a proceselor ocazionate de activitatea de
aprovizionare cu materii prime i materiale pentru ndeplinirea planului de producie. Sinteza
i succesiunea logic de derulare a acestor procese este redat n figura 7.51. Din schema
prezentat pot fi reinute dou aspecte eseniale i anume, pe de o parte, succesiunea logic a
proceselor iar, pe de alt parte, faptul c planul de aprovizionare se face separat pentru
achiziionarea de repere i separat pentru achiziionarea de materii prime i materiale necesare
confecionrii reperelor prin producie proprie.
n figura 7.52. sunt redate ntr-o form mai detaliat aspectele cu privire la activitatea
de aprovizionare. Urmrind figura 7.52. pot fi deduse trei aspecte eseniale i anume:
- pe axul schemei sunt precizate procesele de afaceri (proceduri),
- pe partea din stnga axului schemei sunt specificate intrrile sistemului (documente
primare sau alte surse de intrare) pe baza crora se efectueaz procedurile,
- pe partea din dreapta axului schemei sunt specificate ieirile sistemului (documente
primare de ieire) ca rezultate ale procedurilor efectuate.
n cele ce urmeaz vom cuta s facem o scurt prezentare a procedurilor evideniate
n figura 7.51, fr a avea pretenia unei lecii de managementul aprovizionrii.
- Elaborarea planului i graficului de desfacere lund n considerare ca intrri
informaiile preluate din nomenclatorul de produse finite, stocurile de produse finite
existente, contractele sau comenzile ferme ncheiate cu beneficiarii precum i
capacitile de producie. Ca rezultate ale procedurii se vor obine Planul de desfacere
i Graficul de desfacere.
- Elaborarea planului de producie avnd ca intrri Planul de desfacere, Graficul de
desfacere i alte informaii, rezultnd ca ieire Planul de producie.
207
Capitol 7
NOMENCLATOR DE
PRODUSE FINITE
ELABORARE PLAN
DESFACERE
ELABORARE PLAN
PRODUCIE
DETERMINAREA
STRUCTURII
PRODUSELOR
DETERMINAREA
NECESARULUI DE REPERE
REPERE DIN PRODUCIA

PROPRIE
REPERE
ACHIZIIONATE
NECESAR DE
MATERII PRIME
PLAN APROVIZIONARE DE
REPETE
PLAN APROVIZIONARE
DE MATERII PRIME
PROSPECTARE
PIAA
PROSPECTARE
PIAA
CONTRACTARE
CONTRACTARE
DERULARE
CONTRACTARE
DERULARE
CONTRACTARE
Fig.7. 51. Diagrama sintetic a fluxului informaional pentru activitatea de aprovizionare

208
STOCURI
PRODUSE
CONTRACTE
ELABORAREA PL. I
GRAFICULUI DE
DESFACERE
PLANUL DE
DESF.
COMENZI
NOM. PROD.
CAP. DE
PROD.
FIA PROD.
NECESAR
REPERE
FIA PROD.
FIA
TEHNOLOG.
ELABOR. PLAN
PROD.
DETER. STRUCTURII
PRODUSULUI-REPERE
PLANUL DE
PROD..
SIST. NECESARULUI
DE REPERE
GRAF.DE APROV.
DETER. NECES. DE
MAT. PRIME PTR.
REPERE DIN PROD.
PROPRIE
PLAN APROV.
SIST. NECESARULUI
DE MATERII PRIME
PL. PROD.
SIST. STOC
EXIST.
FURNIZORI
DETER. NECES. DE
APROVIZIONAT
IDENT. FURNIZ.
POTENIALI
LANSAREA
CERERILOR DE
OFERTE
-------OFERTE
ALEGEREA OFERTEI
OPTIME
A
209
SIST. NECES. DE
APROVIZIONAT
SIST. FRNIZORILOR
POTENIALI
-------CERERI DE OFERTE
SIST.
COMPARATIV
A OFERTELOR
Capitol 7
AVIZ DE EXPED.
CONTRACTAREA
I PERFECTAREA
CONTRACT
CONTRACTE
FERME
DERULAREA
CONTRACTELOR
/ LANSARE COMENZI
COMENZI
RECEPIA MATERII
PRIME
FACTURA
NIR
STOCURI
RULAJE
INTRRI
FIA LIMITA
DAREA N CONSUM
STOCURI
BON DE
CONSUM
RULAJE
IEIRI
Fig. 7.52. Diagrama de detaliu a fluxului informaional pentru

activitatea de aprovizionare
-
Determinarea structurii produsului finit pe baza informaiilor preluate din Fia

produsului i Planul de producie rezultnd Situaia necesarului de repere.
Pe baza Situaiei necesarului de repere se va proceda la determinarea necesarului de
repere de achiziionat i necesarului de repere obinute din producie proprie. Planul
de aprovizionare va fi elaborat separat pe cele dou categorii de repere aa cum se
sugereaz i n figura 7.52.
Determinarea necesarului de materii prime pentru reperele din producia proprie pe
baza informaiilor de intrare preluate din Situaia necesarului de repere, Planul de
producie, Fia produsului (consumurilor specifice de materii prime pe reper) i Fia
tehnologic rezultnd ca ieire Situaia necesarului de materii prime.
Determinarea necesarului de aprovizionare i elaborarea Planului i Graficului de
aprovizionare, innd seama de Situaia necesarului de materii prime, Situaia
stocurilor existente i preliminare (finale).
210

-
Identificarea furnizorilor poteniali. Pe baza Situaiei necesarului de materii prime i a

informaiilor despre furnizorii poteniali preluate din Baza de date - furnizorii va fi
elaborat Situaia furnizorilor poteniali.
Lansarea cererilor de oferte. Pe baza informaiilor privind Situaia furnizorilor
poteniali se va proceda la lansarea cererilor de oferte. Cu ct vom cunoate mai muli
furnizori poteniali i crora le vom lansa cereri de ofert cu att vom avea anse
sporite de a realiza o tranzacie comercial mai fericit (mai avantajoas).
Alegerea ofertei optime fcnd apel la un model de alegere bazat pe teoria deciziilor
multicriteriale, cum ar fi metoda Von Neumann-Morgenstern, sau o alta dintre cele
cca. 20.
Se va obine Situaia comparativ a ofertelor (Matricea decizional), care nu nseamn
altceva dect un clasament al ofertelor realizat pe baza punctajului global (criteriu
global) acordat fiecrei oferte, lund n considerare o serie de criterii cu ponderi de
importan difereniate. Procedura poate fi extins cu simularea tratativelor
comerciale, modificnd valorile anumitor parametrii din cadrul Materiei decizionale
ca urmare a unor faciliti scontate a fi dobndite pe parcursul desfurrii tratativelor
comerciale. Cu modificrile astfel efectuate se ntocmete noul clasament al ofertelor.
Vor fi reinute primele dou sau trei oferte mai bine clasate, pentru care se vor purta
tratative comerciale cu furnizorii. n funcie de rezultatele obinute n urma
negocierilor se va alege oferta optim.
Contractarea i perfectarea contractului. Pentru oferta optim se va elabora contractul
care apoi va fi perfectat de ctre factorii de decizie ai unitilor beneficiare i
furnizoare.
Derularea contractelor/lansarea comenzilor de aprovizionare n concordan cu
Planul de producie i Graficul de aprovizionare.
Recepia materiilor prime pe baza Facturii Avizului de expediie i ntocmirea NIR.
NIR-ul va constitui documentul justificativ pe baza cruia se va opera, pe de o parte
asupra stocurilor de materii prime iar, pe de alt parte, se va consemna intrarea de
materii prime n contabilitate Rulaje intrri.
Darea n consum a materiilor prime pe baza Fiei limit de consum sau Bonurilor de
consum. Totodat se va opera n Rulajul ieirilor i asupra Stocurilor cu diminuarea
acestora corespunztor cantitilor eliberate.
Observaie. n mod asemntor se va proceda i pentru achiziionarea reperelor.
7.12.2. Modelarea cazurilor de utilizare

Pe baza modelrii proceselor de afaceri au fost desprinse cazurile de utilizare a cror
diagrame sunt redate n figura 7.53. Pentru fiecare caz de utilizare se precizeaz denumirea i
actorii ce declaneaz cazul de utilizare. Pot fi observate situaiile n care un actor particip la
unul sau mai multe cazuri de utilizare sau situaia n care la un caz de utilizare particip unul
sau mai muli actori.
Totodat, n figura 7.53. pot fi observate utilizarea relaiilor de generalizare (situaiile
Refuz marf i Achitare facturi), de incluziune <include> sau de extensie <extend> ntre
cazuri de utilizare.
De remarcat faptul c fiecare caz de utilizare poate fi extins cu o descriere detaliat pe
baza creia s poat fi elaborate alte tipuri de diagrame necesare.
211
Capitol 7
Elab. plan
desfacere
func. dep.
desfacere
funcionar
marketing
include
Elab. plan
producie
func. dep.
producie
Det. struct.
prod. pe repere
funcionar
aproviz.
tehnolog
Det. neces. de mat.

prime ptr. repere
din prod. intern
funcionar
serv. plan
Det. neces.
de aproviz.
gestionar
Identif.
furniz.
poteniali
Prospectarea
pieei
funcionar
marketing
include
include
Lansare
oferte
Primire
oferte
Evaluarea
ofertelor
funcionar
aprovizionare
Contractare
Contractare
include
Simularea
tratativelor
comerciale
extend
A
212
Alegerea
ofertei
optime
manag.
benef.
manag.
furnizor
Perfectarea
contractelor
dir. ec.
benef.
dir. ec.
furnizor
jurist
benef.
jurist.
furnizor
gest.
Lansare
comenzi
nreg. n
fia mag.
extend
extend
extend
Derulare
contracte
Recepie
materiale
Refuz
marf
extend
extend
Achitar
e total
Achitar
e
parial
nreg. n
contabilitate
Achitar
e facturi
Funcionar
financiar
Funcionar
aprovizionare
Funcionar
contabilitate
Fig. 7.53. Diagrama cazurilor de utilizare
213
Paria
l
Total
COMENZI
SECIE-PROD.
PRODUS
1+
CONTRACTE
DESFACERE
CANT-COMANDAT
1+
1+
STRUCTURA-PRODUS
- REPERE -
BON-CONSUM
CANT-CONSUM.
GESTIUNE
1+
1+
1+
STOC
1+
MATERIAL
1+
CANT-RECEPIONAT
CANT-CONTRACT
TERMEN-LIVR.
1+
FURNIZOR
CANT-FACTUR
PRE-APROV.
COT-TVA
1+
NIR
1+
FACTUR
Fig. 7.54. Diagrama claselor de obiecte Modelul static
COMENZI
CONTRACTE
FURNIZOR
- Den-furnizor:
string
- Adresa-furnizor:
string
- cod-fiscal:
integer
- Den-banc:
string
- cont-banc:
string
- telefon:
integer
- fax:
integer
- cod-mat:
- den-mat:
- UM:
- pret mediu
+ creeaz ( )
+ actualizeaz ( )
+ calc. pre. mediu ( )
+ tergere ( )
+ vizualizare ( )
+ creeaz ( )
+ actualizeaz ( )
+ tergere ( )
+ vizualizare ( )
STOC
- cod mat:
- cod gest:
- stoc iniial:
- rata-stoc-iniial:
- stoc-normat:
- stoc-siguran:
- stoc-exist:
MATERIAL
number
string
string
integer
GESTIUNE
- den-gestiune:
string
- cod-gestiune:
integer
- nume-gestionar: string
- garan-gest:
number
integer
integer
integer
integer
integer
integer
integer
+ creare gest ( )
+ actualizare ( )
+ vizualizare ( )
+ creeaz ( )
+ calc. stoc. ex. ( )
+ calc. imobilizri ( )
+ calc-necesar-aproviz. ( )
+ actualizare
NIR
- nr. NIR:
- data NIR:
- cant. recep.:
BON CONSUM
- Nr. bon:
number
- data bon:
date
- cant. eliberat: integer
number
date
integer
+ creeaz ( )
+ vizualizeaz ( )
+ creare ( )
+ adugare ( )
+ vizualizare ( )
215
Capitol 7
FACTURA
- Nr. fact.:
number
- Data fact.:
Date
- Explicaie:
text
- Suma facturat: number
SECIE PROD.
- den. secie:
string
- ef secie:
string
+ creare ( )
+ adugare ( )
+ tergere ( )
+ modificare ( )
+ valoare TVA ( )
+ valoare Factur
COMAND
nr. comand:
number
data:
date
den-furnizor:
string
cod-fiscal:
number
adresa:
string
den-banc:
string
cont-banc:
string
telefon:
number
termen-livrare:
date
destinaia-livr.:
string
COMANDA - MATERIAL
cod mat.:
number
nr. comand:
number
cant. comand:
integer
cant.-livrat:
integer
ternem-livrare:
integer
+ creare ( )
+ modificare ( )
+ adugare ( )
+ creare ( )
+ modificare ( )
+ adugare ( )
FACTURA MAT.
nr. factur:
number
cod-mat:
number
cant.-fact.:
integer
pre-aprov.:
integer
cota-tva:
integer
+ creare ( )
Fig. 7.55. Clasele de obiecte modelarea claselor de obiecte
216
7.12.3. Modelarea structurii statice a sistemului

Rezultatul modelrii structurii statice va consta n Modelul static care va
reflecta multitudinea claselor de obiecte cu asocierile dintre ele. Clasele de obiecte pot fi
identificate din modelarea proceselor pe baza diagramelor cazurilor de utilizare.
Pentru exemplul de referin, clasele de obiecte i diagrama acestora sunt redate n
figura 7.54. Din considerente de lips de spaiu, descrierea detaliat a fiecrei clase este
redat separat n figura 7.55.
Diagrama claselor de obiecte astfel elaborat poate fi completat i cu alte
elemente desprinse din modelarea dinamic pe baza altor tipuri de diagrame. n final,
diagrama claselor de obiecte poate fi transpus ntr-un limbaj de programare
corespunztor, rezultnd astfel structura bazei de date orientate obiect pentru activitatea
de aprovizionare cu materii prime i materiale.
7.13. Procese de realizare a sistemelor informatice

conform RUP
Rational Unified Process (RUP) este un proces general pentru dezvoltarea
orientat obiect de produse informatice. Este un ghid care arat cum se poate utiliza
practic UML (Unified Modeling Language) pentru a dezvolta un sistem informatic.
Aa cum a fost prezentat i n capitolul 2, n RUP ciclul de via al proiectului este
descompus n patru faze, fiecare avnd asociat un rezultat final (determinarea
obiectivelor, definirea arhitecturii, implementarea funcionalitii i lansarea finala). La
sfritul fiecrei faze este efectuat o analiz pentru a determina dac obiectivele au fost
ndeplinite. Trecerea la urmtoarea faz se realizeaz numai n momentul satisfacerii
obiectivelor fazei curente. Fazele descrise de RUP sunt: explorarea iniial, elaborarea,
construcia i tranziia (figura 7.56.). Pe parcursul fiecrei faze se desfoar procese
primare (identificarea cerinelor, analiza sistemului, proiectarea sistemului,
implementarea i testarea) i procese suport (managementul proiectului, managementul
schimbrii, controlul mediului). n ceea ce privete procesele primare, n fazele iniiale
predomin procesele de identificarea cerinelor i analiz. Pe msura dezvoltrii iterative
a fazelor accentul se mut succesiv pe proiectare, implementare i testare. Procesele
suport sunt prezente ntr-o proporie constant pe parcursul ciclului de dezvoltare, cu
excepia procesului de management al schimbrii. Acesta este mai sczut n fazele iniiale
(cnd modificrile nu sunt cazuri de excepie, ci mai degrab regula) dar i intensific
prezena n final, cnd necesitatea unei modificri trebuie atent analizat i integrat
pentru a nu periclita succesul proiectului (cu ct proiectul este mai avansat cu att este
mai dificil de realizat modificri).
217
Capitol 7
7.13.1. Cele mai bune practici de realizare a sistemelor

informatice
Un proces este un o succesiune ordonat de pai necesari pentru atingerea unui
obiectiv. n cazul industriei software scopul este realizarea unui nou produs software sau
dezvoltarea unuia existent. RUP descrie o familie de subprocese corelate care folosesc o
structur i o arhitectur comun. Scopul procesului este acela de a asigura crearea unui
sistem informatic robust care ndeplinete criteriile impuse de utilizator, ntr-un orizont de
timp predictibil i n limitele bugetului alocat. Din acest punct de vedere UP respect
ntocmai teoria clasic a managementului proiectelor care insist asupra acestor trei
restricii: calitate, timp i buget. RUP surprinde cele mai bune practici folosite n industria
software (dezvoltarea iterativ, managementul cerinelor, arhitectura bazat pe
componente, modelarea vizual, verificarea continu a calitii, controlul schimbrilor )
ntr-o form care poate fi adaptat pentru o plaj foarte larg de proiecte i organizaii. De
asemenea, UP mbuntete comunicarea n cadrul echipelor descriind un limbaj i un
proces comun pentru toate persoanele implicate n proiect.
Unified Process descrie cum pot fi aplicate efectiv practici care s-au dovedit a fi
eficiente pentru echipele de dezvoltare software. Am utilizat acest termen de cele mai
bune practici nu att pentru c ar fi uor de cuantificat valoarea lor, ci pentru c sunt
practici utilizate n mod obinuit de organizaiile de succes din industria software.
Dezvoltarea iterativ. Abordarea tradiional n care se parcurg secvenial etapele
de definire a problemei, analiz, proiectare, realizare i testare pare s nu mai fie cea mai
potrivit dat fiind complexitatea actual a sistemelor informatice. Este necesar
dezvoltarea iterativ care asigur o mai bun cunoatere i nelegere a problemei pe
msur ce soluia efectiv se dezvolt pe parcursul a mai multor iteraii. UP suport o
astfel de abordare iterativ care permite tratarea elementelor cu un grad ridicat de risc la
fiecare etap a ciclului de dezvoltare al proiectului, ceea ce reduce semnificativ riscul
ntregului proiect. Riscul pe ansamblu este combtut prin realizarea frecvent de versiuni
executabile ale sistemului prin care se poate obine implicarea i feedback-ul
218

beneficiarului. ntruct fiecare iteraie se finalizeaz cu o aplicaie executabil echipa
rmne concentrat pe rezultate, iar verificrile frecvente de stare asigur ncadrarea n
timp. Dezvoltarea iterativ asigur i o mai bun integrare a modificrilor care apar
ulterior n cerine, funcionalitate sau planificare.
Managementul cerinelor. UP descrie cum se pot obine, organiza i documenta
cerinele funcionale i restriciile, cum se pot urmri negocierile i deciziile, cum se pot
identifica i comunica cu uurin cerinele procesului de afaceri. Noiunile de caz de
utilizare i scenariu s-au dovedit instrumente deosebit de eficiente n identificarea
cerinelor funcionale i transmiterea acestora la nivelul proiectrii, implementrii i
testrii produsului software, ceea ce a crescut considerabil ansele ca produsul final s
corespund nevoilor beneficiarului. Cu ajutorul cazurilor de utilizare se pot verifica att
pe parcurs ct i n final respectarea cerinelor formulate de beneficiar.
Arhitectura bazat pe componente. Procesul se concentreaz pe realizarea ct mai
devreme a unei arhitecturi robuste executabile, nainte de alocarea tuturor resurselor
pentru dezvoltarea aplicaiei. Structura dezvoltat n fazele iniiale va constitui nucleul pe
care se va dezvolta sistemul n continuare. UP descrie cum se poate dezvolta o arhitectur
flexibil, adaptabil, uor de neles i care s susin utilizarea efectiv a reutilizrii. UP
suport dezvoltarea orientat pe componente. Componentele sunt module non-triviale,
subsisteme ce ndeplinesc o funcie clar. UP ofer posibilitatea definirii unei arhitecturi
pe baza componentelor existente i a altora noi. Acestea sunt asamblate ntr-o arhitectur
bine definit ad-hoc sau ntr-o infrastructur bazat pe componente cum ar fi Internet,
CORBA i COM (pentru care exist o industrie nfloritoare de componente reutilizabile).
Modelarea vizual. UP promoveaz modelarea vizual a structurii i
comportamentului arhitecturii i componentelor sistemului. Mediile speciale de proiectare
asistat (CASE) ofer posibilitatea verificrii continue a consistenei i completitudinii
modelului proiectat. Utilizarea standardului UML, creat de Rational Software, reprezint
certitudinea unei modelri vizuale de succes.
Verificarea calitii. Performane i fiabilitate sczut a aplicaiilor este motivul
principal pentru care proiectele software sunt refuzate. Astfel calitatea trebuie verificat
pe parcurs cu insistnd asupra fiabilitii, funcionalitii, performanelor aplicaiei
(software i hardware). UP asist dezvoltatorul n planificarea, proiectarea,
implementarea, execuia i evaluarea acestor teste. Evaluarea calitii este integrat n
proces, n toate activitile, implic toi membrii echipei, utilizeaz obiective msurabile
i criterii, ea nu este tratat ca o activitate separat ce trebuie s se desfoare la final de
ctre un grup restrns de oameni.
Controlul schimbrilor. Posibilitate de gestiune eficient a schimbrii asigurarea
unui mediu n care orice schimbare e posibil i posibilitatea de a urmri schimbrile
fcute este esenial ntr-un mediu n care schimbarea e inevitabil. UP asigur
controlul, urmrirea i monitorizarea schimbrilor.
219
Capitol 7
7.13.2. Individualizarea RUP

Dintre toate cele menionate mai sus, procesul unificat de dezvoltare de software
este individualizat de trei sintagme - orientat pe cazuri de utilizare, centrat pe arhitectura
sistemului, iterativ i incremental.
Proces orientat pe cazuri de utilizare
Scopul central al unui sistem informatic l reprezint satisfacerea cerinelor
utilizatorilor. Fie c acesta aduce noi funcionaliti sau doar mbuntete funcionaliti
existente el se dezvolt pornind de la cerinele utilizatorilor. Dac dorim un sistem care s
fie apreciat drept performant trebuie s acordm o atenie deosebit identificrii acestor
cerine.
n cazul acesta termenul de utilizator nu se refer strict la utilizatorul uman. Orice alt
sistem care interacioneaz cu sistemul pe care urmrim s-l construim este un utilizator
din punctul de vedere al sistemului nostru. Un exemplu de astfel de interaciune ar putea
fi considerat efectuarea unei rezervri prin intermediul unui sistem de rezervri on-line.
Persoana interesat solicit o rezervare, n urma unui schimb de informaii ntre utilizator
i sistem (persoana i definete mai precis cererea, sistemul de rezervare prezint mai
multe opiuni posibile), dar i n urma unei verificri a crii de credit (verificare ce este
fcut de un alt sistem specializat, utilizator al sistemului de rezervare) se obine
confirmarea de rezervare. O astfel de interaciune poart denumirea de caz de utilizare.
Un caz de utilizare reprezint o funcionalitate a sistemului care furnizeaz un rezultat
utilizatorului. Cu ajutorul cazurilor de utilizare se surprind cerinele funcionale ale
sistemului. Totalitatea cazurilor de utilizare formeaz modelul cazurilor de utilizare, care
descrie ntreaga funcionalitate a sistemului. Acest model nlocuiete tradiionala
specificare a cerinelor funcionale, dar nu numai att. Se obine cu ajutorul modelului
cazurilor de utilizare o mai bun focalizare pe client i cerinele acestuia i nu doar o
identificare a funciunilor pe care ar fi bine s le ofere sistemul. Dac n trecut cerinele se
identificau ca rspuns la ntrebarea: Ce trebuie s fac sistemul?, acum accentul cade pe:
Ce trebuie s fac sistemul pentru fiecare dintre utilizatorii si?
Este important de precizat faptul c modelul cazurilor de utilizare nu este doar un
instrument de identificare a cerinelor, ci el urmeaz s dirijeze ntreg procesul de
dezvoltare software, controlnd proiectarea, implementarea i testarea sistemului. Pe
parcursul ntregului proces modelul cazurilor de utilizare rmne ca un model de
referin, proiectanii dezvolt modele care implementeaz cazurile de utilizare, verific
modelele succesive i conformitatea acestora cu modelul cazurilor de utilizare, iar testerii
se asigur c modelul de implementare respect funciunile cazului de utilizare. n acest
mod cazul de utilizare nu este doar un punct de pornire ci este elementul de legtur al
procesului unificat de dezvoltare. Cazurile de utilizare sunt specificate, apoi proiectate i
n final sunt surs de construire a modelelor de testare. La fel de adevrat este ns c ele
nu sunt alese independent ci n corelaie cu arhitectura sistemului. Cazurile de utilizare
impun o anumit arhitectur, iar arhitectura sistemului influeneaz selectarea cazurilor
de utilizare, astfel cele dou se dezvolt n tandem pe msura parcurgerii ciclului de via
al sistemului.
220

Proces centrat pe arhitectur
Rolul arhitectului de sistem este similar aceluia de arhitect ntr-un proiect de
construcii. Arhitectul surprinde cldirea din mai multe puncte de vedere: structur,
amenajri, detalii, instalaii i toate acestea permit constructorului s aib o imagine de
ansamblu asupra cldirii nainte ca aceasta s fie construit. n mod similar arhitectul de
sistem descrie din diferite puncte de vedere sistemul ce urmeaz a fi construit.
Arhitectura de sistem cuprinde cele mai semnificante aspecte statice i dinamice
ale sistemului. Arhitectura sistemului i are originea n cerinele utilizatorilor, reflectate
n cazurile de utilizare, dar este influenat de mult mai multe aspecte, cum ar fi:
platforma software pe care va rula aplicaia (arhitectura calculatoarelor, sistemul de
operare, sistemul de gestiune a bazei de date, protocoale de reea i de comunicaie
utilizate), blocuri reutilizabile disponibile (GUI, DAO), consideraii de structur,
reglementri legale, cerine nefuncionale (performan, fiabilitate). Arhitectura este o
imagine a ntregului proiect ce evideniaz prile eseniale, ignornd detaliile. Cum
identificarea a ceea ce este esenial se face n mod subiectiv, calitatea arhitecturii
sistemului depinde de experiena celor implicai n realizarea ei. Cu toate acestea,
procesul unificat stabilete obiective de urmat pentru a optimiza calitatea arhitecturii
sistemului (lizibilitate, uurin n modificare, reutilizare).
Aa cum am mai evideniat n paragraful precedent, cazurile de utilizare i
arhitectura sunt puternic legate. Orice produs are o funciune i o form, n cazul
produselor informatice cazurile de utilizare reprezint funcionalitatea produsului, iar
arhitectura, forma acestuia. Cele dou pri trebuie armonizate pentru a obine un produs
calitativ. Funciunea ns, poate determina o anumit form (n cazul proiectului de
construcii dac se dorete realizarea unei sli de sport aceasta implic o form
predefinit) i forma poate restriciona funciunea (dup 1989 multe spaii de locuit au
fost amenajate ca spaii pentru birouri, faptul c ulterior a existat o cerere semnificativ
de cldiri cu destinaie de birouri susine faptul c reamenajarea, modificarea superficial
a formei, nu a susinut modificarea funciunii). n aceeai msur n cazul unui sistem
software, cazurile de utilizare trebuie s se potriveasc n arhitectur, iar arhitectura
trebuie s ofere cadrul general de utilizare al tuturor cazurilor de utilizare, nu numai a
celor iniiale ci i a cazurilor de utilizare posibile viitoare. Pentru a identifica acea form
care s permit sistemului s evolueze se practic identificarea funciunilor cheie ale
sistemului, a cazurilor de utilizare cheie. Chiar dac de cele mai multe ori acestea nu
reprezint dect 5-10% din totalul cazurilor de utilizare, ele reprezint esena sistemului.
Proces iterativ i incremental
Procesul de dezvoltare al aplicaiilor complexe din zilele noastre poate dura pn
la civa ani, motiv pentru care se practic n mod uzual mprirea proiectelor n
subproiecte. Un subproiect reprezint o iteraie i fiecare iteraie aduce un plus de valoare
(un increment) produsului final. De la o iteraie la alta produsul se mbogete, fie sub
aspect calitativ (mai ales n fazele iniiale ale proiectului, cnd se poate trece de la o
abordare superficial la o abordare mai n detaliu), fie cantitativ (n fazele finale ale
proiectului, cnd produsul dobndete noi funciuni).
Fiecare iteraie trateaz un set de cazuri de utilizare care mpreun sporesc gradul
de utilizare al produsului, dar i riscurile specifice asociate proceselor respective. n
cadrul fiecrei iteraii se vor identifica i specifica n detaliu cazurile de utilizare
221
Capitol 7
corespunztoare, se va trece la proiectare lund n considerare i arhitectura sistemului, se
va implementa proiectul n componentele sistemului i n final se vor testa componentele
dac ndeplinesc cerinele surprinse de cazurile de utilizare de la care s-a pornit.
Avantajele unui astfel de proces iterativ sunt multiple. Dintre acestea amintim:
- reducerea costurilor de neconcordan cu cerinele iniiale; dac la un moment dat
este necesar reluarea unei iteraii, atunci pierderile sunt limitate la costurile
iteraiei respective;
- reducerea riscului de a lansa / finaliza produsul cu ntrziere, prin identificarea din
timp a riscurilor majore. n abordarea tradiional abia n momentul testelor finale
erau identificate probleme pentru a cror rezolvare proiectul era ntrziat;
- accelerarea n ansamblu a ritmului de dezvoltare al proiectului; echipa este mai
bine focalizat pe rezultate i pe respectarea unui plan pe termen scurt;
- o mai bun implicare a beneficiarului, precum i rafinarea iterativ a cerinelor
acestuia. n plus acest mod de abordare permite un mai bun control al
schimbrilor datorate att mediului proiectului ct i modificrii specificaiilor
acestuia.
Iteraiile se planific iniial i rareori suport modificri (tiut fiind c orice
abatere de la un plan iniial implic costuri suplimentare). Acest mod de abordare nu
reprezint o scuz pentru un management haotic i nu implic o dezvoltare aleatoare.
Dezvoltare iterativ nu nseamn reproiectarea la infinit a aceluiai modul pn cnd n
sfrit se nimerete o variant care funcioneaz. Aceasta reprezint, din contr, un
instrument de planificare ce reduce, nc din fazele iniiale, riscurile ce ar putea afecta
buna desfurare a proiectului. Versiunile intermediare permit obinerea unui feedback
din partea tuturor celor interesai de proiect i corectarea din timp a eventualelor abateri
nregistrate.
Dac am reprezenta evoluia riscului ntr-o abordare iterativ, fa de evoluia
riscului n cazul modelului de dezvoltare n cascad, se observ c n abordarea iterativ
riscurile majore sunt eliminate nc din fazele iniiale ale proiectului, n timp ce n cazul
modelului n cascad riscurile scad substanial abia n momentul integrrii i testrii
aplicaiei figura 7.57.
Conform RUP, pentru realizarea unui sistem informatic, trebuiesc parcurse n
cadrul unei iteraii urmtoarele procese primare: identificarea cerinelor, analiza,
proiectarea, implementarea i testarea. n cele ce urmeaz vom prezenta mai pe larg
coninutul proceselor de identificarea cerinelor, analiz i proiectare. Pentru
exemplificarea diagramelor i tehnicilor de modelare UML a fost ales un sistem simplu
de rezervare a biletelor pentru o linie aerian. Au fost atinse urmtoarele probleme:
- organizarea sistemului utiliznd pachete;
- identificarea cerinelor sistemului cu ajutorul cazurilor de utilizare;
- modelarea cu diagrame de secven i de colaborare;
- analiza i proiectarea cu diagrama claselor i utilizarea tehnicii fielor CRC;
- modelarea comportamentului cu diagrame de stare i de activitate;
- modelarea componentelor software, distribuirii i implementrii;
- extinderea UML-ului cu diagrama entitate asociere pentru proiectarea bazelor de
date relaionale.
222
7.13.3. Identificarea cerinelor

-
Principalele activiti ce trebuiesc parcurse n aceast etap sunt:

Identificarea cerinelor candidate (n documentaia de iniiere a proiectului, care n
acest caz poart denumirea de viziune);
Structurarea sistemului (utiliznd pachetele);
Aprofundarea nelegerii contextului (utiliznd fie modelul mediului, fie modelul
afacerii);
Identificarea cerinelor funcionale (utiliznd modelul cazurilor de utilizare);
Identificarea cerinelor non-funcionale.
Identificarea cerinelor candidate

n documentaia de iniiere a proiectului (viziune) se identific cerine posibilie
pentru sistemul respectiv. Acestea se completeaz fie pe baza experienei, fie din notele
de interviu sau alte documente. Cel mai important document pentru identificarea acestor
cerine candidate rmne viziunea. n cazul sistemului de rezervare cerinele candidate ar
putea fi: rezervarea de bilete direct la companie sau prin intermediari (ageni de turism),
calculul automat al celei mai avantajoase rute (din punct de vedere al costului sau al
timpului), gestiunea automat a situaiilor speciale (anularea unei curse).
Organizarea sistemului utiliznd pachete
Una dintre sarcinile cheie ale modelrii sistemelor software de mari dimensiuni
este mprirea acestora n arii de mici dimensiuni, mai uor de manevrat. Fie c se
numesc domenii, categorii sau subsisteme, ideea de baz e aceeai: mprirea sistemului
n arii ce mprtesc o problematic similar.
UML introduce noiunea de pachet ca entitate de grupare a elementelor, permind
proiectanilor s mpart i s clasifice sistemele complexe. Pachetele pot fi utilizate la
223
Capitol 7
orice nivel, de la cel mai nalt, unde sunt utilizate pentru a mpri sistemul n domenii,
pn la cel mai de jos nivel, unde se utilizeaz pentru a grupa cazuri de utilizare, clase sau
componente. n RUP, ca i n cazul altor metodologii orientate pe cazuri de utilizare,
aceasta poate constitui o prim etap. Sistemul de rezervare a fost structurat n cinci
subsisteme (reprezentate printr-o diagram a pachetelor, figura 7.58.): ntreinerea flotei,
sistem de urmrire a zborurilor, sistem de rezervare, sistem contabil, personal.
Sistem de urmerire a zborurilor
Intretinerea flotei
Sistem de rezervare
Sistem contabil
Personal
Fig. 7.58. Organizarea sistemului cu ajutorul pachetelor

Identificarea cerinelor sistemului cu ajutorul cazurilor de utilizare
Modelarea cu ajutorul cazurilor de utilizare este tehnica cea mai uoar i mai
eficient pentru identificarea cerinelor din perspectiva utilizatorului. Cazurile de utilizare
sunt folosite pentru a modela modul de funcionare al sistemului actual sau modul de
funcionare al sistemului dorit de utilizatori. Nu utilizeaz o abordare orientat obiect,
este mai degrab o modelare a proceselor, dar cu toate astea este o tehnic excelent de
iniiere a analizei orientat obiect a sistemului. Cazurile de utilizare sunt n general
punctul de pornire n analiza orientat obiect utiliznd UML.
Diagrama cazurilor de utilizare const din actori i cazuri de utilizare. Actorii
reprezint utilizatorii i alte sisteme ce interacioneaz cu sistemul analizat. Ele reprezint
n fapt un tip de utilizator i nu o instan a acestuia. Cazurile de utilizare reprezint
comportamentul sistemului, scenariile pe care acesta le execut ca rspuns la stimulii din
partea actorilor. Acestea se reprezint prin elipse.
n cazul exemplului nostru cazurile n care se face apel la sistemul de rezervare
sunt atunci cnd un pasager dorete s fac o rezervare sau atunci cnd acesta dorete s
anuleze o rezervare fcut anterior. O prim diagram a cazurilor de utilizare este
reprezentat n figura 7.59. ntr-o iteraie ulterioar aceast diagram va putea fi rafinat,
fiind identificate i alte cazuri de utilizare, cum ar fi confirmarea unui zbor.
Fiecare caz de utilizare este documentat printr-o descriere a scenariului.
Descrierea poate fi textual sau pe pai. n figura este prezentat i o descriere sub forma
unei succesiuni de pai pentru cazul de utilizare Rezervare zbor. Fiecare caz de
utilizare poate avea i alte proprieti, cum ar fi pre- sau post- condiii ale scenariului
condiii care trebuie ndeplinite nainte de nceperea execuiei scenariului sau condiii
care trebuie ndeplinite dup executarea scenariului. Diagrama de activitate reprezint un
instrument grafic pentru modelarea proceselor cazurilor de utilizare. Aceasta va fi
detaliat ntr-o seciune ce urmeaz.
Obiectivul final al oricrui proiect software este o aplicaie care rspunde tuturor
cerinelor beneficiarului. Prin identificarea i verificarea cerinelor se urmrete ca toate
cerinele s fie luate n considerare i sistemul s fie proiectat conform cerinelor
beneficiarului. Cel mai adesea cerinele sunt cuprinse ntr-un document (documentaia de
iniiere a proiectului sau viziunea), iar cazurile de utilizare sunt folosite pentru a corela
224

fiecare scenariu cu cerina pe care o trateaz. Modelarea sistemului cu ajutorul cazurilor
de utilizare ajut la identificarea cerinelor, dac acestea nu au fost identificate anterior.
Descrierea cazului de utilizare sub forma unei
succesiuni de pasi
1. Pasagerul solicita o anumita cursa vazatorului de bilete
2. Vanzatorul verifica disponivilitatea la linia aeriana
3. Linia aeriana comunica disponibilitatea biletului, furnizeaza detalii
despre cursa
4. Vanzatorul comunica pasagerului detaliile zborului
5. Pasagerul solicita un loc, preferinte
6. Vanzatorul rezerva locul
7. Vanzatorul confirma rezervarea pasagerului
8. Vanzatorul solicita plata pasagerului
9. Pasagerul face plata catre vanzator
10. Vanzatorul face plata catre linia aeriana
11. Linia aeriana face confirmarea finala vanzatorului
12. Vanzatorul emite biletul pasagerului
Substantivele
sunt posibile clase
Verbele sunt
posibile operatii
Actor
Rezervare Zbor
Pasager
Anulare Rezervare
LinieAeriana
Caz de utilizare
Fig. 7.59. Modelarea cu ajutorul cazurilor de utilizare
7.13.4. Analiza orientat obiect

-
Principalele activiti ce trebuiesc parcurse n aceast etap sunt:

Rafinarea diagramei cazurilor de utilizare;
Modelarea dinamicii sistemului (utiliznd diagrama de secven sau diagrama de
colaborare);
Modelarea structurii statice (utiliznd diagrama claselor).
Rafinarea diagramei cazurilor de utilizare

n aceast etap se pot identifica i alte cazuri de utilizare i ali actori, la un alt
nivel de detaliu. n exemplul nostru am identificat n plus agenia de voiaj, ca intermediar
ntre pasager i companie. Odat cu introducerea acestui nou actor am mai luat n calcul
i necesitatea achitrii biletului pentru validarea rezervrii i alte situaii speciale care ar
trebui acoperite (achitare prin carte de credit, plat neacceptat). De asemenea n cursul
analizei proceselor de afaceri se poate dezvolta modelul al cazurilor de utilizare pentru
ntreg sistemul i se pot construi mai multe pachete pentru reprezentarea unor diverse arii
ale afacerii. Fiecare pachet poate fi apoi descompus i reprezentat printr-o diagram ce
conine cazurile de utilizare corespunztoare domeniului i interaciunile cu actorii.
Scopul este de a construi cte o diagram a cazurilor de utilizare pentru fiecare
scenariu al sistemului. Fiecare scenariu descrie o succesiune diferit de interaciuni ntre
actori i sistem, fr condiii SAU.
Modelarea structurii alternative prin relaii de tip Extends
n mod obinuit fiecare caz de utilizare se construiete dintr-o secven de aciuni,
dup care pentru fiecare pas se construiesc condiii de tip "what if" i se realizeaz noi
225
Capitol 7
cazuri de utilizare pe baza acestor activiti alternative. Secvenele alternative sunt
cuprinse n cazuri de utilizare distincte conectate printr-o relaie de tip "Extends" de cazul
de utilizare iniial. Relaia de tip "Extends" poate fi privit ca relaie de motenire ntruct
cazul de utilizare ce extinde un alt caz de utilizare motenete i suprascrie
comportamentul acestuia. Presupunnd c achitarea biletului se face implicit prin
numerar, dar opional plata se poate face i prin carte de credit, cazul de utilizare
Achitare prin carte de credit extinde cazul de utilizare Achitare zbor (figura 7.60.).
Eliminarea comportamentului redundant cu ajutorul relaiilor de tip Uses
Pentru a elimina o secven de comportament redundant ce apare n cazuri de
utilizare diferite se poate modela acea secven ntr-un caz de utilizare distinct conectat
de cazurile de utilizare iniiale prin relaii de tip Uses. Relaia de tip "Uses" poate fi
privit ca fiind echivalent cu relaia de agregare. n exemplul nostru, fie c rezervarea se
face direct la linia aerian sau printr-o agenie de voiaj, o rezervare trebuie achitat pentru
a fi validat. Cazul de utilizare achitare zbor este utilizat att de Rezervare zbor, ct
i de Rezervare zbor prin agent (figura 7.60.).
Rezervare Zbor
<<uses>>
Pasager
Achitare Zbor
<<extends>>
Achitare prin
carte de credit
<<extends>>
<<uses>>
LinieAeriana
Rezervare Zbor
prin Agent
<<extends>>
Plata neacceptata
Agentie de Voiaj
Fig. 7.60. Relaii de extindere i de utilizare ntre cazuri de utilizare
Cazurile de utilizare sunt folosite i pentru a construi scripturi de testare pentru a

verifica satisfacerea cerinelor beneficiarului de ctre aplicaie. Cnd se atinge nivelul cel
mai fin de descompunere, pentru fiecare caz de utilizare se poate realiza o diagram de
secven. Cu diagramele de secven i de colaborare se modeleaz implementarea
scenariului.
Modelarea dinamicii sistemului Diagramele de secven
Diagrama de secven este una dintre cele mai potrivite pentru a modela
interaciunile ntre obiectele sistemului. Se realizeaz cte o diagram de secven pentru
fiecare caz de utilizare. n timp ce cazul de utilizare modeleaz un scenariu din puntul de
vedere al utilizatorului, diagrama de secven conine detalii de implementare ale
226

scenariului, incluznd clasele i obiectele ce vor implementa scenariul i mesajele
transmise ntre obiecte. n mod obinuit se analizeaz descrierea cazului de utilizare
pentru a determina care sunt obiectele necesare pentru implementarea scenariului. Dac
descrierea a fost fcut sub forma unei succesiuni de pai obiectele se determin prin
parcurgerea acestor pai. ntr-o diagram de secven obiectele implicate n scenariu sunt
reprezentate prin linii punctate verticale, iar mesajele transmise ntre acestea prin vectori
orizontali. Mesajele se reprezint cronologic de sus n jos, spaierea pe orizontal a
obiectelor fiind arbitrar. Pentru cazul de utilizare descris mai sus prin pai (Rezervare
zbor) diagrama de secven este prezentat n figura 7.61. Se observ c paii din
descrierea cazului de utilizare se regsesc n secven de sus n jos.
Ionescu : Pasager
Vlad : Vanzator
Linie Aeriana
solicitare zbor
verifica disponibilitatea
rezervare disponibila
detalii zbor
detalii zbor
transmite preferinte loc
rezerva loc
confirma rezervarea
solicita plata
face plata
face plata
confirmare finala
eliberare bilet
Fig. 7.61. Diagrama de secven pentru un scenariu

n cursul analizei mesajul poart denumirea din sistemul existent. Mai trziu, n
cursul proiectrii acesta este nlocuit cu denumirea metodei obiectului apelat. Metoda
apelat sau invocat aparine clasei instaniate de obiectul ce recepioneaz mesajul.
Modelarea dinamicii sistemului Diagramele de colaborare
Diagrama de colaborare reprezint o alternativ la diagrama de secven pentru
modelarea interaciunilor ntre obiectele sistemului. n timp ce n diagrama de secven
accentul cade pe succesiunea cronologic a mesajelor, n diagrama de colaborare accentul
cade pe identificarea i nelegerea tuturor efectelor pe care scenariul le are asupra unui
obiect (figura 7.62). Obiectele sunt conectate, fiecare legtur fiind o instan a asocierii
ntre clasele implicate. Legtura evideniaz mesajul transmis ntre obiecte, tipul
227
Capitol 7
mesajului (sincron, asincron, simplu, opional -balking sau time-out) i vizibilitatea
obiectelor unele fa de altele.
5: detalii zbor
8: confirma rezervarea
9: solicita plata
13:eliberare bilet
Ionescu : Pasager
Vlad : Vanzator
3: rezervare disponibila
4: detalii zbor
12: confirmare finala
1: solicitare zbor
6: preferinte loc
10: face plata
2: verifica disponibilitatea
7: rezerva loc
11: face plata
Linie Aeriana
Fig. 7.62. Diagrama de colaborare pentru un grup de obiecte
Modelarea structurii statice cu ajutorul diagramei claselor

Diagrama claselor este instrumentul principal de analiz i proiectare a structurii
statice a sistemului. n ea se precizeaz structura claselor sistemului, relaiile ntre clase i
structurile de motenire. n timpul analizei diagrama este construit urmrind obinerea
unei soluii ideale. La proiectare se utilizeaz aceeai diagram i se modific pentru a fi
conform cu detaliile de implementare.
Dezvoltarea diagramei claselor pe parcursul analizei
Abordarea orientat pe cazuri de utilizare
n cazul analizei orientat pe cazuri de utilizare, diagrama claselor se construiete
pe baza informaiilor furnizate de cazurile de utilizare, diagramele de secven i
diagramele de colaborare. Obiectele identificate pe parcursul analizei sunt modelate n
termenii claselor instaniate de acestea, iar interaciunile ntre obiecte sunt transpuse n
relaii ntre clasele instaniate (figura 7.63).
228
Linie Aeriana
+DisponibilitateRezervare : boolean
+FurnizareDetaliiZbor() : void
+ConfirmareRezervare() : Boolean
numar zbor
1
programeaza
rezerva zbor
Vanzator
1..*
numar rezervare
+RezervaZbor()
+VerificaDisponibilitate()
Rezervare Zbor
NumePasager : char
NumarZbor : int
NumarRezervare : int
1..*
Zbor
+Destinatie : char
+Plecare : char
+DataZbor : char
+OraZbor : char
+Pret : int
+NumarZbor : int
1..*
1..*
este rezervat cu
Agentie Voiaj
-NumeAgentie : char
-AdresaAgentie : char
Bilet
NumeCompanie : char
PretBilet : int
DataZbor : char
OraZbor : char
NumarZbor : int
NumarBilet : char
Agentie Linie Aeriana
-LinieAeriana : char
+AdresaLinieAeriana : char
Fig. 7.63. Diagrama claselor n etapa de analiz
Pasager
-NumePasager : char
#AdresaPasager : char
-CNP : unsigned long
+SolicitaZbor() : void
+FacePlata() : void
Capitol 7
Abordarea orientat pe responsabiliti
Tehnica fielor CRC este utilizat uneori ca extensie a UML-ului pentru o analiz
orientat pe responsabiliti. Definiiile claselor sunt rafinate pe baza responsabilitilor lor i
a altor clase cu care acestea colaboreaz pentru a ndeplini aceste responsabiliti. Pentru
fiecare clas se ntocmete o fi pe care se evideniaz responsabilitile clasei i care sunt
clasele cu care ea colaboreaz pentru a ndeplini aceste responsabiliti. Aceste informaii se
transpun direct ntr-o diagram a claselor, responsabilitile corespund metodelor, iar
colaborrile corespund asocierilor dintre clase (figura 7.64.).
Pasager
Superclas: <none>
Subclase: <none>
Responsabiliti Colaboratori
Plata biletului
Vanzator_bilet
Solicitare zbor
Vanzator_bilet
Pentru a afl preul trebuie

s colaborez cu pasagerul
i compania aerian
Bilet
Superclas: <none>
Subclase: <none>
Responsabiliti
Afl pretul
Companie
Zbor
Superclas: <none>
Subclase: <none>
Responsabiliti
Furnizeaz detalii zbor
Confirm rezervarea
Superclas: <none>
Subclase: <none>
Responsabiliti
Locuri disponibile
Colaboratori
Vanzator_bilet, Zbor
Vanzator_bilet, Zbor
Colaboratori
Companie, Pasager
Colaboratori
<none>
Vanzator_bilet
Superclas: <none>
Subclase: <none>
Responsabiliti
Verific disponibilitatea
Rezerv zbor
Colaboratori
Companie, Zbor
Companie, Pasager
Fig. 7.64. O extensie informal a UML tehnica fielor CRC

pentru analiza orientat pe responsabiliti
7.13.5. Proiectarea orientat obiect

Exist dou obiective principale pe care le urmrim n proiectarea unui sistem
informatic:
- obinerea ct mai rapid a sistemului care s respecte toate cerinele actuale la un pre
ct mai sczut;
- construirea unui sistem uor de ntreinut i adaptat pentru a rspunde unor viitoare
cerine.
Aceste obiective sunt vzute n mod tradiional ca fiind conflictuale; unul dintre
motivele pentru care tehnicile de proiectare orientate obiect au cucerit cu rapiditate piaa este
i concilierea acestor obiective conflictuale.
Ca i n cazul analizei principalele activiti ce trebuiesc parcurse n aceast etap
sunt:
- Modelarea structurii statice (utiliznd diagrama claselor);
- Modelarea dinamicii sistemului (utiliznd diagrama de stare sau diagrama de
activitate);
- Rafinarea diagramei cazurilor de utilizare (utiliznd diagrama de activitate);
230

-
Modelarea arhitecturii sistemului (utiliznd diagrama componentelor i diagrama de

desfurare);
- Proiectarea bazei de date.
Accentul cade de aceast dat pe detaliile concrete ale implementrii sistemului.
Fiecare dintre modele abordate vin s completeze diagrama claselor / obiectelor care n final
va sta i la baza proiectrii bazei de date.
Proiectarea sistemului cu ajutorul diagramei claselor
Pe parcursul proiectrii diagrama claselor este modificat pentru a lua n considerare
detalii concrete ale implementrii sistemului.
Diagrama claselor poate fi dezvoltat ntr-o manier iterativ, printr-o succesiune
repetat a analizei, proiectrii i implementrii. Acest proces este adesea referit ca round-trip
engineering. Utilizarea unui CASE poate facilita acest proces oferind posibilitatea
implementrii ntr-un limbaj de programare cum ar fi C++ sau Java i invers, reactualizarea
diagramei claselor pornind de la cod (reverse engineering).
Fig. 7.65. Analiza i proiectarea iterativ, documentarea

cu ajutorul diagramei claselor
O preocupare esenial pe parcursul proiectrii este stabilirea arhitecturii sistemului.
Se poate opta ntre o aplicaie simpl ce va rula pe o singur main, un sistem client-server
sau un sistem multi-tier cu obiecte specializate pentru interfaa cu utilizatorul, logica aplicaiei
i pentru baza de date, fiecare putnd potenial s ruleze pe o alt platform. O posibilitate de
a gestiona o astfel de arhitectur complex este mprirea diagramei claselor n trei seciuni
diferite care s evidenieze clasele ce descriu interfaa cu utilizatorul (business layer), clasele
responsabile de logica aplicaiei (application layer) i clasele pentru stocarea datelor (data
layer). Aceasta se poate realiza fizic fie prin segmentarea diagramei claselor i utilizarea unei
diagrame distincte pentru fiecare seciune sau prin adugarea unei proprieti fiecrei clase,
proprietate care s identifice crei seciuni (tier) aparine clasa.
231
Capitol 7
O component este un grup de obiecte sau componente care interacioneaz cu scopul
de a furniza un serviciu. O component este similar unei cutii negre pentru care serviciile
sunt specificate prin interfaa sau interfeele sale, fr a se preciza nimic despre componena
sau implementarea intern a componentei. Dezvoltarea bazat pe componente este procesul
care urmrete asamblarea componentelor celor mai potrivite n configuraia cea mai bun
pentru a obine funcionalitatea dorit pentru sistem. Componentele sunt reprezentate n
diagrama claselor din UML prin specificarea interfeei clasei sau pachetului. Exist dou
posibiliti de reprezentare pentru interfa, ca o clas cu stereotipul <<interface>> i lista
operaiilor suportate de interfa n seciunea destinat metodelor sau n variant prescurtat,
ca un mic cerc ataat printr-o linie continu de clas i preciznd denumirea interfeei n
dreptul cercului.
Exemplul din figura 7.66. arat c interfaa Afiabil a clasei Pasager pune la dispoziie
o operaie mut(x coord, y coord) pentru afiarea n GUI. Sunt evideniate ambele modaliti
de reprezentare. Interfaa Persistent a clasei Pasager ofer o operaie salveaz(store at) care ar
putea fi folosit de o clas sau component de acces la baza de date.
interface
Afisabil
+mut(x coord, y coord) ()
Afisabil
<<uses>>
<<uses>>
Persistent
Pasager
+mut(x coord, y coord) ()
+salveaz(store at) ()
GUI
Fig. 7.66. Proiectarea componentelor specificarea interfeei unei clase

Modelarea comportamentului cu diagrame de stare
n timp ce diagramele de interaciune i de colaborare modeleaz comportamentul
dinamic reprezentat de o secven de aciuni ntre grupuri de obiecte ale sistemului, diagrama
de stare este utilizat pentru a modela comportamentul dinamic al unui singur obiect sau clas
de obiecte. Se realizeaz cte o diagram de stare pentru fiecare clas cu comportament
dinamic semnificativ. ntr-o astfel de diagram se surprinde secvena strilor pe care le
parcurge un obiect al clasei pe parcursul ntregului su ciclu de via ca rspuns la stimulii
primii, dar i propriile rspunsuri i aciuni ale obiectului. Mai concret, comportamentul unui
obiect este modelat pornind de la starea sa iniial i determinnd care sunt strile pe care le
tranziteaz atunci cnd intervin diverse evenimente. Se urmresc i aciunile pe care obiectul
le efectueaz atunci cnd se afl ntr-o anumit stare. Strile reprezint suma condiiilor
obiectului la un moment dat. Evenimentele sunt ntmplri care determin trecerea unui obiect
dintr-o stare n alta. Strile de tranziie caracterizeaz micarea dintr-o stare n alta. Fiecare
stare de tranziie (reprezentat printr-o linie continu ce leag cele dou stri ntre care se
efectueaz tranziia) este etichetat cu evenimentul care determin tranziia. Aciunile sunt
efectuate de obiect atunci cnd acesta sosete ntr-o stare (figura 7.67.).
Diagrame de activitate
Diagrama de activitate este o diagram de flux utilizat pentru a modela
comportamentul sistemului. Ea poate fi folosit n mai multe situaii: pentru a modela un caz
de utilizare, o clas sau o metod mai complicat. Aa cum am mai spus ea este similar unei
diagrame de flux, diferena esenial fiind accea c o diagram de activitate poate reprezenta
procese paralele. Acest lucru este deosebit de important atunci cnd diagramele de activitate
232

sunt utilizate pentru a modela procesele de afaceri (multe din acestea executndu-se n
paralel) sau pentru a modela fire multiple de execuie n programarea concurent.
Rezervare loc
Anulare
Locuri
disponibile
Zbor rezervat
Locuri rezervate
Locuri
disponibile la
clasa I
Zbor rezervat
Locuri clasa I
rezervate
Zbor
programat
Soseste ora plecarii
Gata de
decolare
Locuri la clasa I
Permite
modificari la
clasa I
Anulare
Toate locurile ocupate
Fig. 7.67. Modelarea comportamentului dinamic al obiectului Zbor

cu ajutorul diagramei de stare
Utilizarea diagramelor de activitate pentru a modela cazuri de utilizare
Diagrama de activitate ofer un instrument grafic pentru a modela procesele unui caz
de utilizare. Aceasta poate fi folosit n completarea, sau n locul, unei descrieri textuale / liste
de pai a cazului de utilizare. O descriere textual, cod sau o alt diagram de activitate poate
prezenta mai multe detalii.
Utilizarea diagramelor de activitate pentru a modela clase
Pentru modelarea comportamentului unei clase diagrama de stare este utilizat atunci
cnd predomin evenimentele asincrone. Diagrama de activitate se folosete cnd toate sau
majoritatea evenimentelor sunt urmare a unor aciuni interne. ntr-o astfel de diagram
activitile trebuiesc ataate claselor (figura 7.68.).
Modelarea componentelor software
Diagrama componentelor este utilizat pentru a modela structura software-ului,
incluznd dependenele ntre componentele software, componentele n cod binar i
componentele executabile. n diagrama componentelor se modeleaz componentele
sistemului, grupate uneori n pachete, i dependenele care exist ntre componente (i pachete
de componente) (figura 7.69.).
233
Capitol 7
Pasager
Vanzator
Linie aeriana
Solicitare zbor
Verifica disponibilitatea
Furnizeaza detalii zbor
Furnizeaza optiuni si preturi
Alege zbor
Solicita plata
Rezerva zbor
Achita bilet
Confirma rezervarea
Emite bilet
Fig. 7.68. Diagrama de activitate

Sistem de rezervare
SGBD
Print Server
Plan de zbor
Statie de lucru
Fig. 7.69. Modelarea componentelor cu ajutorul diagramei

componentelor
234
Modelarea distribuirii i implementrii

Diagrama de desfurare este utilizat pentru a modela configuraia elementelor de
procesare la momentul execuiei i distribuia componentelor software, proceselor i
obiectelor pe aceste elemente de procesare. Se pornete de la identificarea nodurilor fizice i a
comunicaiilor ce exist ntre acestea. Pentru fiecare nod se precizeaz instanele
componentelor care se stocheaz sau se execut pe nodul respectiv. Se pot evidenia i
obiectele componentei respective. Diagrama de desfurare modeleaz doar componentele
existente la momentul execuiei, ea nu surprinde i componentele folosite doar la compilare
sau linkeditare. Se pot modela i componentele care migreaz dintr-un nod n altul, sau
obiectele ce migreaz dintr-o component ntr-alta, utiliznd relaia de dependen cu
stereotipul <<becomes>> (figura 7.70).
Imprimanta
bilete
Statie de
lucru in
aeroport
Server
LAN
Conexiune
Statie de
lucru la
agentia de
turism
Firewall
Imprimanta
bilete
Internet
Acces read-only
Calculatoare
clienti (acasa)
Fig. 7.70. Modelarea distribuirii sistemului cu ajutorul diagramei de desfurare
Proiectarea bazelor de date relaionale o extensie UML

Diagrama claselor prezint un mecanism neutru de implementare pentru modelarea
aspectelor ce in de stocarea datelor sistemului. Clasele persistente, atributele acestora i
relaiile dintre ele pot fi implementate direct ntr-o baz de date orientat obiect. Cu toate
acestea, n prezent, bazele de date relaionale rmn modalitatea de stocare a datelor cea mai
uzual. Diagrama claselor din UML permite modelarea unor aspecte specifice proiectrii
bazelor de date relaionale, dar nu acoper n ntregime aceast problematic, de notat faptul
c nu prevede noiunea de atribute cheie care sunt mecanismul principal de relaionare a
tabelelor. Pentru a surprinde mai bine aceste aspecte este bine s se apeleze la diagrama
entitate asociere (ER), n completarea setului de diagrame propus de UML. Diagrama claselor
poate fi utilizat pentru a modela logic baza de date, independent de faptul c se alege o
implementare relaional sau orientat obiect, prin clase reprezentndu-se tabelele, iar prin
atribute coloanele acestora. Dac se alege pentru implementare un mediu relaional, atunci
diagrama claselor poate fi uor translatat ntr-o diagram logic entitate asociere. Claselor
persistente i atributelor acestora le corespund entitile logice i atributele lor, iar relaiilor
dintre clase le corespund relaii ntre entiti (figura 7.71).
235
Capitol 7
Diagrama claselor - UML

Logica
aplicatiei
Interfata cu
utilizatorul
Implementare OO
Datele
SGBDOO
Translatare obiectual/relational
Schema fizica
SGBDR
Schema fizica
SGBDR
Diagrama entitate
asociere
Translatare logic /
fizic
Fig. 7.71. Proiectarea bazelor de date relaionale cu ajutorul diagramei entitate

asociere
Odat ntocmit aceast diagram se poate trece la proiectarea bazei de date

relaionale conform tehnicii normalizrii (prezentat ntr-un alt capitol).
236

Capitol 7 DSI

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Capitol 7 DSI

Încărcat de

Drepturi de autor:

Formate disponibile

Baze de date orientate obiect

7.2. Premisele BDOO

Baze de date orientate obiect

7.3. Avantajele i dezavantajele BDOO

BDOO permit obiectelor s se refere direct unele la altele pe baz de pointeri. O

BDOO ofer performane sporite referitoare la clasterarea (cluster) fizic a

Baze de date orientate obiect

BDOO sporesc extinderea domeniilor de aplicabilitate prin posibilitatea folosirii

7.4. Comparaii ntre abodarea obiectual i cea

Baze de date orientate obiect

n modelul relaional dac nu se definete cheia

Deosebirile dintre modelul BDOO i modelul BDR pot fi evideniate i sub

datelor i acces reprezentat prin tabele i

Analiznd cele dou tipuri de baze de date, obiectuale i relaionale, por fi

Baze de date orientate obiect

7.5. Moduri de abordare ale dezvoltrii sistemelor

7.6. Modelul conceptual al datelor obiect

CODM The Conceptual Object Data Model

prezentarea textual a problematicii de referin;

n contextul sistemelor informatice n general, i n special al bazelor de date, se

7.6.1. Conceptul de obiect

Baze de date orientate obiect

Fig. 7.1. Obiect complex

7.6.2. Identificatorii obiectelor

Baze de date orientate obiect

7.6.3. Atribute proprieti ale obiectelor

Baze de date orientate obiect

7.6.4. Tipuri i clase de obiecte

Baze de date orientate obiect

tipuri nregistrare / tuplu: un constructor nregistrare permite definirea de tipuri a

Fig. 7.4. Exemplu de definire de tip de obiect complex

Baze de date orientate obiect

Fig. 7.3. Diagrama claselor de obiecte

Fig. 7.5. Exemplu de definire implicnd i referine de obiecte

[ASE, Brbulescu, [Bucureti,Piaa Roman, 6], OID2, OID7]>

Baze de date orientate obiect

7.6.4.2. Clase de obiecte

Fig. 7.7. Exemplu de clase

Fig. 7.8. Exemplu de instane

Baze de date orientate obiect

Fig. 7.9. Relaia ntre clas i tip

Baze de date orientate obiect

7.6.5.2. Definirea semnturilor i implementarea metodelor

(Denumire par: string,

Referitor la definirea semnturilor i implementrii metodelor, n cele ce urmeaz

- partea mai pronunat reprezint cuvinte rezervate;

Baze de date orientate obiect

7.6.5.3. Considerente de ordin practic cu privire la proiectarea

7.6.6. ncapsularea i interfaa

Fig. 7.10. Exemplu de ncapsulare

Baze de date orientate obiect

7.6.8. Asocierile ntre clase

Fig. 7.11. Reprezentarea asocierii

Aceste exemplificri ajut n alegerea / definirea ct mai sugestiv a denumirii

O instan din clasa A are ntotdeauna n

O instan din clasa A poate avea 0 sau 1

O instan din clasa A poate s aib 0 sau N

O instan din clasa A poate avea 1 sau N

Baze de date orientate obiect

Sugereaz faptul c un partid politic poate avea mai muli membrii, ns o

O altfel de legtur exprim faptul c la un curs facultativ poate s nu fie nscris

O instan din clasa A are n coresponden o

O instan din clasa A poate avea 0 sau 1