Sisteme Informatice

Capitol 7
Baze de date orientate obiect

(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
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.
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:
122

-
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.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.
CODM The Conceptual Object Data Model
123

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 ;
- 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.
124

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.
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;
A1 : v1 , , An : vn
A1 , , An
- Valoare tuplu de forma
, unde
sunt nume de atribute
v1 , , vn
distincte i
sunt valori asociate atributelor;
v1 , , vn
v1 , , vn
- Set de valori, de forma
unde
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.
125

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
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
126

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
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.
127

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
are
1,
1.1
apartine de
SALARIAT
DEPARTAMENT:
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.
128

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.
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.;
129

-
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.
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
130

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.
- 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;
131

-
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
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] ],
132

[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.
133
CARTE
1,2
urmat de
urmeaz
mprumutat d
1,
gestioneaz
100,
gestionat de
ofer
BIBLIOTECAR
1,
are
1,*
se afl n
are
1,
frecventat de
angajat la
1,
aparine de
1,1
UNIVERSITATE
PROFESOR
este la 1,1
134
1,1
BIBLIOTECA
dispune de
1, are
1,
1,
dispune aparine de
de
1,1 apa
dispu
coordonate de
1,1
CATEDRA
FACULTATE
coordoneaz
1, orientate obiect
Baze de date
Fig. 7.3. Diagrama claselor de obiecte

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
1,1
specialist n
definire de tip obiect complex va apare astfel (figura 7.5):
SECIE
Universitate: record of
(Denumire: string,
Nume-rector: string,
Adresa: record of (
Ora: string,
Strada: string,
are 10,
Numr: integer),
set of1,*
( Faculti),
predatla
set of (Biblioteci))
Faculti:
Biblioteci:
Faculti: record of
specializeaz
1, frecve
CURS
(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] >
135

Fig. 7.6. Exemplu de instan n care apar i referiri
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
+ schimb-adresa ( )
+ nregistrare la curs ( )
- Cod
- Denumire
- Sala
- Ora
+ 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
136

despre fiecare student. ntr-o astfel de situaie apare posibilitatea convertirii unei baze de
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.
137
descriere / atribute
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,
138

Profil: string,
Bibliotecari: set of ( Bibliotecari))
add class Bibliotecari
type tuplu (nume: string,
studii: string)
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:
139

-
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.
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;
140

self Numr = Numr par;
return (sefl);$
Referitor la definirea semnturilor i implementrii metodelor, n cele ce urmeaz
vom cuta s facem anumite precizri.
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:
public

p1 , p2 , , pn
private
Method den-metod
n class den-clasa
unde:
- partea mai pronunat reprezint cuvinte rezervate;
p1, 2 , , pn
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:
d1.d 2 , , d n
Body denn-metod
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.
141

Urmrind cele dou aspecte referitoare la metode i anume, semntura i
implementarea metodei, observm c ambele presupun precizarea unei liste de parametri.
pi
di
Cu privire la cele dou liste de parametri
i
se pot face anumite precizri, astfel:
pi
- parametrii
poart denumirea de parametri efectivi sau actuali, respectiv
di
parametri
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;
- 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;
pi , i 1,2, , n
d i , i 1,2, , n
- corespondena dintre parametrii
i
, se face prin
locul ocupat n lista de parametri i nu prin numerele lor; ntr-o astfel de situaie
pi
di
denumirile parametrilor
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
di
li se rezerv memorie, parametrii
utilizeaz aceleai zone de
pi
memorie ca i .
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.
142

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:
- 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.
143

FACTURA
- Data-emiterii: Date
- Emitent: string
- Material: string
.
.
.
+ Emite - factura()
+ ncaseaz - factura()
+ ncasare - parial()
+ Calculeaz - factura()
mesaj
proprieti
metode
Fig. 7.10. Exemplu de ncapsulare

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
144

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.
145

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
O instan1,1
din clasa A are ntotdeauna n coresponden o instan din clasa B
B
O instan din clasa A poate avea 0 sau 1 instane n corespondena din clasa B (un
0,1
A
B
O instan din clasa

0, A poate s aib 0 sau N corespondene de instane din B (unu la
A
B
O instan din clasa

A poate avea 1 sau N corespondene de instane din B (unu la u
1,
A
B
146

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
CURS FACULTATIV
0,
are nscrii
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.
147

Varianta 2
A
O instan din clasa A are n coresponden o instan din clasa B (unu l

B
O instan din clasa A poate avea 0 sau 1 instane n corespondena din clasa B (un
A
B
O instan din clasa A poate s aib 0 sau N corespondene de instane din B (unu la
A
B
O instan din clasa A poate avea 1 sau N corespondene de instane din B (unu la u
A
B
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
CSTORIE
Fig. 7.12. Exemplu de asociere unar
Asocierea binar, presupune existena a dou clase de obiecte de forma (figura
7.13):
148

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 2
Nume clas 1
Nume
asociere
Nume clas 3
Fig. 7.14. Exemplu general de asociere ternar

Un exemplu pentru reliefarea asocierii ternare este prezentat n figura7.15
mprumu-t
Banc
Client
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.
149
Firm
Mijloc de
producie
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.
150

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
151

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
1,n
lucreazpentru
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.
152
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;
153

-
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
specializa
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
MANAGEMENT
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.
154

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
155

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.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
156

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
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.
157

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.
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 R EA 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 til iz 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 ra m a d e d e sf u ra re
D i a g r a m a p a c h e te l o r
Fig 7.28. Diagramele UML
158
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
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.
159
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
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.
160

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.
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
161

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.
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
162

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;
- 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
163

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:
[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.
164
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.
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
165

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
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.
166
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
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
167

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
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
168

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
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).
169
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.
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.
170
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
disponibil pentru o aciune urmtoare. Cnd se ntmpl acest lucru, activitatea s-a mutat
ctre starea sa de aciune urmtoare.
171

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)
172
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.
173

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.
174
Fig. 7.40. Diagrama pachet (Package Diagram)
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
175

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.
176
proiectarea GUI
Interfata
grafica
Cerinte
Diagrama
claselor
M
d
Inginerie inversa
Posibila generare de cod
Diagrame de interactiune
Cazuri de
utilizare
Modele de
date relationale
Codificarea
Diagrama de
secventa
Diagrame de implementare
Diagrama de
stare
Diagrama de
colaborare
Diagrama de
stare
Diagrama de
stare
Posibila translatare d
Carduri CRC
Specificarea procesului de afaceri
Diagrama de
activitate
Test
Fig. 7.41: Interaciunea dintre diagramele UML, tehnica fielor CRC i modelul enti
177

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.
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.

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
suma
data facturii
termen plat
cumparator
1
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
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.
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.
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.
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.

-
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
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
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
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.):
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.

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
STOCURI
PLANUL DE
PRODUSE
ELABORAREA PL. I GRAFICULUI DE DESFACERE
DESF.
CONTRACTE
COMENZI
NOM. PROD.
CAP. DE
PROD.
ELABOR. PLAN
PROD.
PLANUL DE
PROD..
FIA PROD. DETER. STRUCTURII PRODUSULUI-REPERE

SIST. NECESARULUI DE REPERE
GRAF.DE APROV.
NECESAR
REPERE
APROV.
DETER.
NECES. DE MAT. PRIME PTR. REPERE DIN PROD.PLAN
PROPRIE
FIA PROD.
SIST. NECESARULUI DE MATERII PRIME
FIA TEHNOLOG.
PL. PROD.
SIST. STOC
EXIST.
DETER. NECES. DE APROVIZIONAT SIST. NECES. DE APROVIZIONAT
IDENT. FURNIZ. POTENIALI
SIST. FRNIZORILOR
POTENIALI
FURNIZORI
LANSAREA CERERILOR DE OFERTE
--------
CERERI DE OFERTE
--------
ALEGEREA OFERTEI OPTIME
OFERTE
SIST. COMPARATIV
A OFERTELOR

A
AVIZ DE EXPED.
CONTRACTAREA
I PERFECTAREA CONTRACT
CONTRACTE FERME
DERULAREA CONTRACTELOR
/ LANSARE COMENZI
COMENZI
RECEPIA MATERII PRIME
NIR
STOCURI
FACTURA
RULAJE INTRRI
FIA LIMITA
STOCURI
DAREA N CONSUM
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).
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.
Contractare
manag.
benef.
manag.
furnizor
dir. ec.
benef.
jurist
benef.
Funcionar financiar
Funcionar aprovizionare
Funcionar contabilitate
dir. ec.
furnizor
jurist.
furnizor
1+

Fig. 7.53. Diagrama cazurilor de utilizare
1+
1+
Fig. 7.54. Diagrama claselor de obiecte Modelul static
FURNIZOR
- Den-furnizor:
string
- Adresa-furnizor:
string
- cod-fiscal:
integer
- Den-banc:
string
- cont-banc:
string
- telefon:
integer
- fax:
integer
MATERIAL
- cod-mat:
number
- den-mat:
string
- UM:
string
- pret mediu
integer
+ 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:
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 ( )
197
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
198
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.
199

Sisteme Informatice

Î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

Sisteme Informatice

Încărcat de

Drepturi de autor:

Formate disponibile

Capitol 7

Baze de date orientate obiect

7.2. Premisele BDOO

Baze de date orientate obiect

Baze de date orientate obiect

limitele abordrii structurate n analiza i proiectarea sistemelor informatice

7.6. Modelul conceptual al datelor obiect

CODM The Conceptual Object Data Model

Baze de date orientate obiect

7.6.1. Conceptul de obiect

Baze de date orientate 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

Baze de date orientate obiect

7.6.4. Tipuri i clase de obiecte

Baze de date orientate obiect

Baze de date orientate obiect

Baze de date orientate obiect

Catedrele ca departamente, din punct de vedere administrativ i al coordonrii

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

Baze de date orientate obiect

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

Baze de date orientate obiect

Fig. 7.9. Relaia ntre clas i tip

Baze de date orientate obiect

Baze de date orientate obiect

metode publice, ce reprezint particularitatea c pot fi apelate din oricare program

7.6.5.2. Definirea semnturilor i implementarea metodelor

(Denumire par: string,

Baze de date orientate obiect

Baze de date orientate obiect

Invocarea metodei init, ntr-un program scris n CO2 apare astfel:

Baze de date orientate obiect

7.6.5.3. Considerente de ordin practic cu privire la proiectarea

7.6.6. ncapsularea i interfaa

Baze de date orientate obiect

Fig. 7.10. Exemplu de ncapsulare

7.6.8. Asocierile ntre clase

Baze de date orientate obiect

Fig. 7.11. Reprezentarea asocierii

Baze de date orientate obiect

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

O instan din clasa

O instan din clasa

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

Baze de date orientate obiect

O instan din clasa A are n coresponden o instan din clasa B (unu l

Tipul asocierii. Tipul asocierii este dat de numrul claselor participante la o

Baze de date orientate obiect