Sisteme Informatice de Gestiune

SISTEME INFORMATICE DE GESTIUNE
MANUAL PENTRU ID
Prof. univ. dr. M. Udrică

Lect. univ. dr. Martinov D.
UNITATEA DE ÎNVĂŢARE 1
SISTEMUL INFORMATIC AL ORGANIZAŢIEI
OBIECTIVE:
- introduce şi explică o serie de termeni (noţiuni) specifici pentru acest domeniu

al tehnologiei informaţiei.
- sunt puse în discuţie problemele actuale referitoare la locul şi rolul sistemelor
informatice în organizaţiile cu caracter social şi economic, etapele de dezvoltare
şi modelele de organizare a sistemelor informatice.
Cuvinte cheie: sistem informaţional-decizional, sistem informatic, ciclul de viaţă al

sistemului informatic, metode de proiectare, modele de organizare.
CONŢINUT:
1. SISTEMUL INFORMATIC AL ORGANIZAŢIEI
1.1 Sistem informaţional
1.2 Sistem informatic
1.3 Proiectarea sistemelor informatice
1.4 Ciclul de viaţă al unui sistem informatic
1.5 Metode de proiectare a sistemelor informatice
1. SISTEMUL INFORMATIC AL ORGANIZAŢIEI

Etapa actuală este etapa în care economia mondială trece de la societatea
predominant industrială la societatea informaţională, guvernată de un set nou de reguli, în
care tehnologiile digitale permite accesarea, procesarea, stocarea şi transmiterea
informaţiilor. Complexitatea activităţilor desfăşurate la nivelul firmelor reclamă o viziune
sistemică, în care fiecare componentă este parte a unui întreg.
Utilizat în toate domeniile de activitate, conceptul de sistem nu are o definiţie
unanim acceptată. La început a fost definit ca mulţime de elemente aflate în interacţiune.
Mai târziu, observând că această definiţie nu cuprinde sistemele logice formalizate, S.
Cleen a definit sistemul ca o mulţime pentru care sunt definite relaţii. Generalizând, o
mulţime formează un sistem dacă pe ea se realizează o relaţie dată, cu proprietăţi fixate.
Sistemele astfel definite pot fi clasificate în funcţie de caracterul proprietăţilor şi al
relaţiilor. W. Ashby a observat că definiţia este mult prea largă, dat fiind faptul că în
orice mulţime pot fi definite mai multe tipuri de relaţii şi a propus definirea sistemului
pornind de la comportamentul său. A afirmat că “sistemul se reprezintă ca posibilitate de
construcţie în sens larg, cu presupunerea că există capacitatea de a se da o anumită
apreciere rezultatelor construcţiei”.
2
Dificultăţile cognitive apărute în studiul obiectelor complexe din sfera cunoaşterii
ştiinţifice moderne, au determinat în timp constituirea teoriei generale a sistemelor,
disciplină ştiinţifică care elaborează principiile metodologice de investigare a sistemelor,
care asigură o bază formal metodologică unitară de cercetare.
1.1 Sistem informaţional
În cadrul teoriei sistemelor, un loc important îl ocupă sistemele deschise, sisteme
ce pot realiza o stare de echilibru dinamic cu mediul exterior. Principalele caracteristici
structurale rămân constante, în timp ce sistemul realizează un schimb continuu de
informaţii cu mediul. Sistemele economice sunt considerate cazuri particulare ale
sistemelor deschise.
Privită ca sistem, o firmă poate fi structurată la rândul ei în trei mari subsisteme:
subsistemul operaţional (condus), subsistemul decizional (de conducere) şi subsistemul
informaţional (de legătură). Fiecare din aceste subsisteme poate fi considerat ca un sistem
de sine stătător ( fig. 1.1.a).
SISTEM DECIZIONAL
Informaţii Decizii
SISTEM INFORMAŢIONAL MEDIUL
EXTERIOR
Date Decizii
SISTEM OPERAŢIONAL
Sistemul informaţional este fig. reprezentat
1.1a de totalitatea metodelor, procedurilor şi
mijloacelor folosite în procesul informaţional. El poate fi definit ca un ansamblu
organizat şi integrat de operaţii00 de culegere, transmitere, prelucrare, sistematizare,
analiză şi păstrare, difuzare şi valorificare a informaţiilor.
Permiţând actualizarea datelor de intrare şi legarea informaţiilor din toate
domeniile de activitate, sistemul informaţional trebuie să fie capabil să furnizeze rapoarte
periodice privind desfăşurarea activităţii, dar şi rapoarte la cerere, determinate de
semnalarea unor situaţii neobişnuite. Ele fundamentează activitatea de analiză şi
prognoză, permit luarea rapidă şi eficientă a măsurilor ce se impun.
Rolul determinant al informaţiilor în procesul conducerii a impus definirea unei
noi noţiuni, decizia, ca fiind o informaţie de comandă pentru sistemul operaţional.
Eficienţa deciziilor luate depinde de calitatea informaţiilor furnizate. Împreună cu datele
ce exprimă înregistrarea fenomenelor şi proceselor la momentul producerii lor,
informaţiile şi deciziile realizează legătura între sistemul operaţional şi cel de conducere.
Scopul principal al sistemului informaţional este de a furniza fiecărui utilizator
toate informaţiile necesare. Preluând datele de la sistemul operaţional, sistemul
informaţional asigură pe de o parte informaţiile necesare fundamentării deciziilor,
3
primeşte şi transmite deciziile formulate de sistemul de conducere, iar pe de altă parte
asigură legătura dintre mediul intern al firmei şi cel exterior ei.
Noua economie, specifică societăţii informaţionale, transformă informaţia digitală
în valoare economică şi socială, creează noi industrii modificându-le pe cele existente,
afectând profund viaţa cetăţenilor. Informaţiile traduse într-un limbaj universal
(computerizat) sunt privite ca o materie primă strategică, fundamentală dezvoltării
economice şi sociale. Cuplată cu reţelele de calculatoare, informaţia digitizată circulă în
timp real. Schimbă procesele de producţie, metodele de cercetare, organizarea muncii şi
obiceiurile consumatorilor.
În aceste condiţii, locul sistemul informaţional tradiţional este preluat de reţelele
Intranet. Intranet-ul este o reţea locală cu arhitectură bazată pe tehnologia Internet,
care permite comunicarea într-un grup închis de utilizatori care se raportează şi
construiesc o bază comună de informaţii. Schimbul de informaţii cu mediul exterior este
preluat de Extranet, o aplicaţie specială care permite altor organizaţii şi persoane
accesul la informaţia difuzată pe Intranet. Cu aceste consideraţii, subsistemele dintr-o
firmă pot fi reprezentate ca în figura 1.b.
SISTEM DECIZIONAL
Informaţii Decizii
INTRANET EXTRANET
Date Decizii
SISTEM OPERAŢIONAL
fig. 1.1b
1.2 Sistem informatic

Sistemul informatic este un ansamblu structurat şi corelat de proceduri şi
echipamente electronice de calcul care permit culegerea, transmiterea şi prelucrarea
datelor, obţinerea de informaţii.
Sistemul informatic lărgeşte câmpul de acţiune al sistemului informaţional, îi
potenţează valenţele, îmbunătăţindu-l sub aspect calitativ. Odată cu evoluţia sistemelor
electronice de calcul, sistemul informatic tinde să se suprapună sistemului informaţional
4
ca sferă de cuprindere. Mai mult, dacă se include în sfera sistemul informatic activitatea
de conducere a proceselor tehnologice cu ajutorul calculatoarelor de proces, sfera
sistemelor informatice depăşeşte sfera sistemelor informaţionale.
În activitatea economică, sistemele informatice privesc obţinerea informaţiilor pe
baza unor date de intrare şi a unor normative, procedeele de prelucrare fiind considerate
elemente intercondiţionate şi inseparabile ale procesului de conducere. Sunt sisteme
informatice integrate, caracterizate prin aplicarea principiului introducerii unice a
datelor şi prelucrării multiple a acestora în concordanţă cu cerinţele informaţionale
specifice fiecărui utilizator.
Utilizate în managementul firmei, sistemele informatice integrate (fig. 1.2) au la
bază sistemele tranzacţionale, concepute să eficientizeze şi să automatizeze prelucrarea,
să păstreze înregistrările şi să raporteze tranzacţiile. Acestea sunt în permanentă
interdependenţă cu sistemele de birotică şi comunicaţii, utilizate pentru automatizarea
muncii de birou. Împreună contribuie la definirea depozitelor de date, structuri pe care se
bazează sistemele informatice de analiză.
IN
SISTEME DE ANALIZĂ TE
R
DEPOZITE DE N
DATE ET
SISTEME
IN
TR
DE A
N
SISTEME TRANZACŢIONALE ET
BIROTICĂ
BAZE DE DATE BAZE DE DATE E
X
ŞI TR
A
fig. 1.2 N
1.2.1 Structura generală a unui sistem informatic COMUNICAŢI ET
I
Evidenţierea structurii generale a unui sistem informatic se obţine pornind de la
funcţia acestuia de a prelucra datele în vederea obţinerii informaţiilor necesare unei
desfăşurări normale a activităţilor într-o firmă. Principalele componente sunt: intrări,
prelucrări, ieşiri.
Intrările sunt reprezentate de mulţimea datelor încărcate, gestionate şi prelucrate
în cadrul sistemului.
Prelucrările reprezintă un ansamblu omogen de proceduri automate cu funcţie
de:
5
• creare şi actualizare a bazei de date;
• consultare a bazei de date;
• reorganizare a bazei de date;
• salvare/restaurare a bazei de date.
Ieşirile sistemului informatic sunt reprezentate de rezultatele prelucrărilor
desfăşurate. Ieşirile pot fi obţinute în urma unor operaţii de transfer a datelor, sau pot fi
obţinute în urma operaţiilor de calcul ce au la bază algoritmi prestabiliţi.
În funcţie de conţinutul şi forma lor de reprezentare, ieşirile pot fi clasificate
astfel:
• indicatori sintetici, regăsiţi în tablourile de bord oferite managerilor (cifra de
afaceri, profitul brut, profitul net).
• rapoarte, situaţii ce regrupează diferiţi indicatori sintetici sau analitici (balanţa
de verificare, bilanţul contabil, statul de plată).
• grafice, ce permit reprezentarea într-o formă sugestivă a dinamicii indicatorilor
sintetici şi analitici, a modificărilor de structură.
• foi de calcul electronice, generate cu ajutorul procesoarelor de tabele (Excel).
Rezultatul obţinut poate fi furnizat direct utilizatorilor, sau poate fi obiectul
importului/exportului către sisteme de gestiune a bazelor de date.
• ieşiri destinate altor sisteme, reprezentate de fişiere transmise on-line sau off-
line în vederea prelucrărilor ulterioare în cadrul altor sisteme informatice.
1.3 Proiectarea sistemelor informatice

În general proiectarea sistemelor informatice desemnează activitatea complexă
de dezvoltare de sisteme informatice. Indiferent de metodologie, proiectarea urmăreşte
întregul ciclu de viaţă al sistemului informatic. În etape distincte, pe diferite nivele de
abstractizare, sunt construite modele ce evidenţiază cele trei dimensiuni: statică, dinamică
şi funcţională.
În sens restrâns, proiectarea sistemelor informatice este una din etapele în care
sunt grupate activităţile desfăşurate pentru realizarea unui sistem informatic. Urmând
analizei şi precedând implementarea, proiectarea extinde sau adaptează modelele definit
în faza de analiză, ţinând cont de restricţiile impuse de mediul în care va funcţiona
sistemul. Introduce elemente noi necesare trecerii la implementare.
La ora actuală, tendinţa de standardizare în conceperea sistemelor informatice
determină o diminuare a fazei de proiectare, prioritate având modalităţile de
implementare şi identificarea efectele pe care noul sistem le poate avea asupra unităţii
beneficiare. Faza de proiectare se reduce la elaborarea unor specificaţii tehnice de
implementare.
6
1.3.1 Principiile proiectării şi realizării sistemelor informaţionale
Principiile ce trebuie respectate în activitatea de proiectare şi realizare a
sistemelor informatice sunt [SV03]:
1• Abordarea globală a problemei de rezolvat.
2• Utilizarea unei metodologii unitare în proiectarea şi realizarea sistemului
informatic
3• Aplicarea celor mai moderne soluţii şi tehnici de proiectare şi realizare a
sistemului informatic
4• Structurarea sistemului informatic independent de structura organizatorică a
firmei.
5• Participarea nemijlocită a viitorului beneficiar la activităţile de analiză, proiectare
şi implementare a sistemului informatic.
6• Respectarea cadrului legislativ.
7• Realizarea unor sisteme informatice în concordanţă cu resursele disponibile la
utilizator.
8• Anticiparea şi controlarea permanentă a schimbărilor survenite.
9• Explicitarea şi documentarea compromisurilor inerente în dezvoltarea de
software.
Conform acestor principii, se defineşte întâi o soluţie globală de informatizare, se
stabileşte structura flexibilă a sistemului şi se precizează priorităţile în realizarea
componentelor sale. Asigurând implicarea benefi-ciarului pe tot parcursul realizării
sistemului informatic, se iau în calcul particularităţile privitoare la modul de organizare a
activităţii, cadrul legislativ general şi reglementările interne aflate în vigoare.
1.3.2 Strategii de proiectare a sistemelor informatice

În funcţie de modalitatea de abordare a sistemelor informatice, strategiile de
proiectare a sistemelor informatice pot fi grupate în trei mari clase: strategii descendente,
strategii ascendente şi strategii mixte.
Strategia descendentă (top-down) porneşte de la principiul descompunerii
sistemului informatic complex în componente mai simple prin parcurgerea unor nivele
succesive de detaliere. Se defineşte astfel o structur00ă ierarhic-modulară în care fiecare
componentă îndeplineşte o anumită funcţie.
Strategia descendentă se aplică în cazul sistemelor informatice complexe
(sistemul informatic al unei bănci, sistemul informatic al Ministerului de Finanţe). Iniţial
se realizează o soluţie globală la nivelul întregului sistem. Componentele se proiectează
şi se realizează independent, într-o ordine de prioritate stabilită de cerinţele sistemului ca
un tot unitar şi în funcţie de cerinţele beneficiarului. Integrarea se realizează din treaptă în
treaptă pornindu-se de la componentele elementare.
7
Practic, strategia descendentă constă în:
• identificarea entităţilor, componente relevante, interesante prin structura şi
comportarea lor; entităţile trebuie să aibă cel puţin o realizare şi cel puţin un atribut;
• identificarea asocierilor dintre entităţi;
• identificarea asocierilor de tipul generalizare/specializare şi parte/întreg. După
realizarea generalizărilor/specializărilor se reactualizează lista entităţilor care urmează să
fie incluse în modelul datelor. Specializarea este necesară când o serie de asocieri între
entităţi au sens doar la nivelul unei specializări şi când nu toate atributele sunt valabile
pentru toate realizările de entitate. Generalizarea se impune când entităţi diferite prezintă
atribute similare sau asocieri analoage cu alte entităţi.
• identificarea proprietăţilor de entitate şi stabilirea cheilor;
• identificarea proprietăţilor de asociere;
• construirea modelului;
• verificarea modelului.
Strategia ascendente (bottom-up) presupune proiectarea şi realizarea
componentelor viitorului sistem informatic, fără a avea o imagine de ansamblu asupra
întregului sistem informaţional. Se tratează separat fiecare componentă a sistemului,
stabilirea corelaţiilor între componente şi integrarea lor în sistemul privit ca un tot
unitar urmând a se face ulterior. Lipsa unei strategii unitare aduce după sine riscul unui
grad redus de integrare a componentelor în sistem.
Practic, strategia ascendentă constă în:
• identificarea proprietăţilor ;
• c0onstruirea grafului dependenţelor funcţionale; În cadrul dependen-ţelor
funcţionale, arcele terminale obţinute plecând de la proprietăţile elementare definesc
entităţile. Originile arcelor constituie identificatorii de entitate. Arcele care rămân pun în
evidenţă asocierile. Proprietăţile nerezolvate ce rămân sunt atribuite asocierilor.
Proprietăţile izolate vor defini entităţile izolate.
• determinarea structurilor teoretice de acces la date;
• construirea modelului;
• verificarea modelului.
Strategia mixtă reprezintă o combinare a strategiei descendente cu strategia
ascendentă, împrumutând de la fiecare avantajele. Practic se foloseşte strategia
descendentă pentru definirea sistemului ca un tot unitar şi a componentelor lui, urmându-
se strategia ascendentă în proiectarea şi realizarea fiecărei componente.
8
1.4 Ciclul de viaţă al unui sistem informatic
1.4.1 Caracteristici
Definirea unui sistem informatic este o decizie determinată de avan-tajele
tehnologiilor informaţionale aduse mediului de afaceri. Împărţirea în subsisteme,
specificarea unor priorităţi sau schimbarea condiţiilor concrete de lucru, se regăsesc atât
în cerinţele legate de funcţiile sistemului (fundamentarea deciziilor imediate, urmărirea
producţiei) cât şi în cele nefuncţionale, ce referă proprietăţile calitative ale
sistemului( flexibilitate, portabilitate). Gruparea activităţilor pe etape, faze şi activităţi
specifice se face în funcţie de complexitatea modelului real, de cerinţele utilizatorului sau
de abilităţile echipei de realizare a sistemului informatic.
În „Proiectarea obiectuală a sistemelor informatice” ([ZR02]) autorii definesc ciclul de
viaţă al unui sistem informatic ca fiind perioada de timp cuprinsă între momentul
iniţierii acestuia şi momentul scoaterii din funcţiune. Această perioadă este împărţită în
două etape fundamentale: dezvoltarea şi exploatarea.
1. Dezvoltarea include perioada de timp necesară obţinerii sistemului, trecerea la
realizarea planului însemnând începutul perioadei de dezvoltare.
În timp ce proiectarea informaţională vizează modul de funcţionare a sistemului
din punctul de vedere al utilizatorilor, modul în care se va derula activitatea la intrarea în
funcţiune a sistemului, proiectarea informatică vizează arhitectura logică şi fizică,
mediul de dezvoltare sau de programare, programe, baze de date.
2. Exploatarea cuprinde perioada de timp în care sistemul este folosit în mod
curent.
În „ Sisteme informatice de gestiune”([SV03]), autoarea afirmă că ciclul de viaţă al
unui sistem informatic este perioada de timp cuprinsă între decizia de realizare a unui
nou sistem informatic mai performant şi decizia de înlocuire a sistemului existent cu unul
nou. Pentru a asigura conceperea, realizarea, implementarea, exploatarea şi întreţinerea
sistemului sunt parcurse mai multe etape descompuse la rândul lor în faze. Acestea sunt:
1. Definirea cerinţelor utilizatorilor, când se precizează obiectivele noului sistem,
criteriile de eficienţă, securitatea, performanţele.
2. Specificaţia cerinţelor sistemului, prezentarea detaliată a rezultatelor pe care
sistemul informatic le va asigura.
3. Specificaţia cerinţelor software, luând în calcul restricţiile sub care
funcţionalitatea sistemului urmează să fie asigurată.
4. Proiectarea generală, când se defineşte soluţia cadru, conceptuală.
5. Proiectarea de detaliu, fază în care se rafinează soluţia cadru şi se defineşte
soluţia finală.
6. Realizarea componentelor sistemului informatic rezultate din elaborarea
arhitecturii.
9
7. Testarea componentelor, când se verifică modul de funcţionare, modul de
îndeplinire a cerinţelor şi fiabilitatea în functionare.
8. Integrarea componentelor şi testarea finală a sistemului, fază ce presupune
realizarea produsului final şi verificarea funcţionalităţii lui.
9. Implementarea şi testarea produsului la beneficiar.
10. Exploatarea şi întreţinerea sistemului.
11. Dezvoltarea sistemului, ce implică realizarea şi integrarea de noi componente.
Etapele ciclului de viaţă se pot derula strict secvenţial, sau pot determina reveniri
la etapa anterioară (chiar la prima etapă), în funcţie de rezultatul validărilor intermediare.
În funcţie de complexitatea sistemelor reale, schimbările din domeniul tehnologiei
informaţiilor se reflectă fie în schimbarea etapelor, fie în modificarea opticii de
parcurgere a lor.
Ordinea şi felul în care se parcurg etapele se regăseşte în literatura de specialitate
sub numele de modele ale ciclului de viaţă al dezvoltării sistemelor.
1.4.2 Modele ale ciclului de viaţă

Dintre modelele ciclului de viaţă care au ocupat un loc important în teoria
sistemelor la vremea când au fost definite, şi ale căror avantaje au fost preluate chiar şi de
cele mai actuale modele, se pot menţiona modelul cascadă şi modelul spirală.
Modelul cascadă (Waterfall) a fost elaborat la începutul anilor 1970, de către
W.W. Royce. Ciclul de viaţă este descompus în faze secvenţiale, structurate în activităţi şi
subactivităţi. Trecerea la etapa următoare presupune parcurgerea în întregime a celei
curente.
Avantaje:
 fiecare etapă este însoţită de documentare şi se încheie cu verificarea soluţiei
oferite;
 prin ordonarea şi delimitarea clară a fazelor, se obţine un control total al fazelor;
 este uşor de însuşit de către membrii echipelor de analiză şi proiectare.
Dezavantaje:
 respectarea ordinii secvenţiale a etapelor nu este întotdeauna conformă cu
realitatea;
 necesitatea parcurgerii integrale a etapelor anterioare duce la prelun-girea
timpului de realizare al sistemului;
 nu ia în calcul eventualele schimbări intervenite pe parcurs .
Datorită acestor dezavantaje, în timp au fost propuse variante îmbunătăţite,
acceptând reluarea pasului anterior ( waterfall model with back flow) sau reluarea de la
faza iniţială ( „Da Capo” waterfall model), permiţând astfel corectarea erorilor ivite pe
parcurs.
10
Modelul spirală a fost elaborat de B. W. Boehm, în 1988. Dezvoltarea sistemului
se face în spirală. Pentru fiecare nivel se face analiza riscului şi se construiesc
prototipuri succesive. La fiecare iteraţie sunt reluate fazele de dezvoltare, ce includ
simularea şi testarea prototipului, determinarea şi validarea cerinţelor rezultate din
testare, planificarea ciclului următor, regăsindu-se modelul cascadă. După efectuarea
studiilor de fezabilitate, sistemul se realizează, se integrează şi se instalează în varianta
modelului cascadă.
Condiţionat de profesionalismul echipei de dezvoltare, avantajul acestui model
constă în faptul că oferă posibilitatea evaluării riscurilor în diferite momente.
1.5 Metode de proiectare a sistemelor informatice

Ansamblul modelelor pentru un sistem informatic este elaborat conform unei
metode, definită printr-un proces, o notaţie şi un set de instrumente informatice [ZR02].
Metoda, cunoscută sub numele de metodă de proiectare, specifică activităţile ce
trebuie efectuate pentru conceperea sistemului, ordinea în care se execută şi modul lor
de corelare. Pentru fiecare activitate sunt definite intrările, ieşirile şi sunt formulate
instrucţiunile de realizare.
1.5.1 Clasificări
Într-o primă clasificare, metodele de proiectare pot fi grupate în metode hard şi
metode soft.
Metodele hard pun accentul pe abordarea ştiinţifică şi consideră că realitatea,
independentă de oameni, poate fi modelată, înţeleasă şi transformată în funcţie de
dorinţele acestora. Consideră că toate problemele pot fi formalizate pe baze matematico-
logice şi acordă proiritate datelor, funcţiilor şi proceselor.
Metodele soft, dintre care cea mai cunoscută este metoda SSM (Soft System
Methodology) introdusă de P Checkland în 1981, încearcă să rezolve probleme legate de
aspectele sociale ale dezvoltării sistemelor, de cerinţele utilizatorilor. Din punctul lor de
vedere, analistul se confruntă cu situaţii problemă şi nu cu probleme clar definite şi gata
de rezolvare. Măsurile luate într-o situaţie sunt rezultatul schimbării organizaţionale,
analistul de sistem fiind văzut nu ca un expert în domeniu ci ca un agent al schimbării,
capabil să-i stimuleze pe ceilalţi în obţinerea unor noi percepţii asupra contextului
problemei.
O altă clasificare, recunoscută mai ales în literatura franceză, împarte metodele în
funcţie de modalitatea în care este perceput sistemul. Există astfel metode de analiză şi
descompunere ierarhice (funcţionale), metode de analiză şi reprezentare orientate-
sistemic şi metode de analiză şi proiectare orientate-obiect.
11
Metodele ierarhice iau în calcul fiecare funcţie şi subfuncţie a sistemului. Se defineşte o
ierarhie până se ajunge la componente suficient de mici astfel încât să fie programate cu
uşurinţă (fig.2.2).
F1
F11 F12 F13
F111 F121 ………

F112 F123
fig. 2.2
Caracterizate prin simplitate şi o bună adaptare la cerinţele utilizatorului, aceste

metode prezintă dezavantajul că orice schimbare de funcţie a sistemului presupune
reconsiderarea aplicaţiilor. În plus, efortul este centrat asupra funcţiilor de prelucrare,
neglijându-se coerenţa datelor.
Cele mai cunoscute metode ierarhice sunt: SADT (Structurated Analysis and
Design Technique), JSD (Jackson System Development, Yourdon.
Metodele sistemice reprezintă cea de-a doua generaţie a metodelor de analiză şi
proiectare a sistemelor informatice. Bazându-se pe teoria generală a sistemelor, în cadrul
acestor metode datele şi prelucrările asupra datelor sunt modelate şi studiate
independent. Împreună formează un sistem. Axându-se pe conceptul de bază de date, care
oferă coerenţă şi elimină redundanţele, metodele sistemice acordă prioritate datelor faţă
de prelucrări. Dezavantajele acestor metode rezultă din existenţa deficienţelor în
modelarea prelucrărilor, în prezenţa unor discordanţe între modelele datelor şi cele ale
prelucrărilor.
Metodele sistemice respectă cele trei nivele de abstractizare introduse prin
metodologia ANSI/SPARC: conceptual, logic şi fizic. Principalele metode sistemice sunt:
MERISE, AXIAL, Information Engineering.
Metodele orientate obiect reprezintă cea de-a treia generaţie, utilizate astăzi în
cazul sistemelor cu comportament dinamic, dependent de timp. Se definesc entităţi de
sine stătătoare, în care sunt încapsulate date (proprietăţi) şi prelucrări (operaţii).
Avantajul acestor metode rezultă din faptul că oferă posibilitatea reutilizării
componentelor. Existând o integrare mult mai bună a datelor cu prelucrările, aduc o
rezolvare coerentă a aspectelor dinamice. Dezavantajul este însă că nu întotdeauna
modelarea corespunde realităţii reprezentate.
12
Cele mai utilizate metode sunt: Object Modeling Technologie (OMT), Object
Oriented Design (OOD). Succesul utilizării metodelor orientate obiect a determinat
definirea unui limbaj standard de modelare, Unified Modeling Language.
Probleme şi soluţii
1 Care din afirmaţiile următoare este adevărată ?
a) Sistemul informaţional este reprezentat de totalitatea metodelor, procedurilor şi
mijloacelor folosite în procesul informaţional.
b) Sistemul informatic se defineşte ca un ansamblu organizat şi integrat de operaţii de
culegere, transmitere, prelucrare, sistematizare, analiză şi păstrare,difuzare şi valorificare
a informaţiilor.
c) Decizia este o informaţie de comandă pentru sistemul de conducere.

a) Internet-ul este o reţea locală care permite comunicarea într-un grup închis de
utilizatori care se raportează şi construiesc o bază comună de informaţii.
b) Intranet-ul este o reţea locală care permite comunicarea într-un grup închis de utilizatori care
se raportează şi construiesc o bază comună de informaţii.
c) Intranet-ul este o aplicaţie specială care permite altor organizaţii şi persoane accesul la
informaţia difuzată pe Intranet.

a) Sistemul informatic integrat este un ansamblu structurat şi corelat de proceduri şi
echipamente electronice de calcul care permit culegerea, transmiterea şi prelucrarea
datelor, obţinerea de informaţii.
b) Sistemele informaţionale sunt caracterizate prin aplicarea principiului introducerii
unice a datelor şi prelucrării multiple a acestora în concordanţă cu cerinţele
informaţionale specifice fiecărui utilizator.
c) Funcţia unui sistem informatic este de a prelucra datele în vederea obţinerii
informaţiilor necesare unei desfăşurări normale a activităţilor într-o firmă.
4 Care din afirmaţiile următoare nu este adevărată ?

a) Strategia descendentă porneşte de la principiul descompunerii sistemului informatic
complex în componente mai simple prin parcurgerea unor nivele succesive de detaliere.
b) Strategia ascendentă porneşte de la principiul descompunerii sistemului informatic
complex în componente mai simple prin parcurgerea unor nivele succesive de detaliere.
c) În cadrul strategiei descendente se defineşte o structură ierarhic-modulară în care
fiecare componentă îndeplineşte o anumită funcţie.
13
a) Strategia ascendentă presupune proiectarea şi realizarea componentelor viitorului
sistem informaţional, fără a avea o imagine de ansamblu asupra întregului sistem
informaţional.
b) În cadrul strategiilor ascendente se tratează separat fiecare componentă a sistemului,
stabilirea corelaţiilor între componente şi integrarea lor în sistemul privit ca un tot unitar
urmând a se face ulterior.
c) Strategia descendentă presupune proiectarea şi realizarea componentelor viitorului
sistem informaţional, fără a avea o imagine de ansamblu asupra întregului sistem
informaţional.

a) Ciclul de viaţă al unui sistem informatic se defineşte ca fiind perioada de timp cuprinsă
între momentul iniţierii acestuia şi momentul scoaterii lui din funcţiune.
b) Ordinea şi felul în care se parcurg etapele ciclului de viaţă se regăseşte în literatura de
specialitate sub numele de modele ale ciclului de viaţă al dezvoltării sistemelor.
c) Un model al ciclului de viaţă specifică activităţile ce trebuie efectuate pentru
conceperea sistemului.

a) În cazul metodelor ierarhice se defineşte o ierarhie a funcţiilor până se ajunge la componente
suficient de mici astfel încât să fie programate cu uşurinţă.
b) Metode orientate-obiect acordă prioritate datelor în raport cu prelucrările.
c) În cazul metodelor orientate-date sistemele reale sunt împărţite în entităţi de sine
stătătoare, care înglobează proprietăţi şi comportament.

a) În cadrul metodelor sistemice datele şi prelucrările asupra datelor sunt modelate şi
studiate independent.
b) Dezavantajele metodelor ierarhice rezultă din existenţa deficienţelor în modelarea
prelucrărilor, în prezenţa unor discordanţe între modelele datelor şi cele ale prelucrărilor.
c) Metodele sistemice sunt utilizate în cazul sistemelor cu comportament dinamic,
dependent de timp.

a) Avantajul metodelor sistemice rezultă din faptul că oferă posibilitatea reutilizării
componentelor.
b) Avantajul metodelor orientate-obiect rezultă din faptul că oferă posibilitatea reutilizării
componentelor
14
c) Dezavantajele metodelor orientate-obiect rezultă din existenţa deficienţelor în
modelarea prelucrărilor.

a) Proiectarea sistemelor informatice desemnează activitatea complexă de dezvoltare de
sisteme informatice şi nu una din etapele în care sunt grupate activităţile desfăşurate
pentru realizarea unui sistem informatic.
b) Modelul ciclului de viaţă al unui sistem informatic specifică activităţile ce trebuie
efectuate pentru conceperea sistemului, ordinea în care se execută şi modul lor de
corelare.
c) Metoda de proiectare a unui sistem informatic specifică activităţile ce trebuie efectuate
pentru conceperea sistemului, ordinea în care se execută şi modul lor de corelare.
Rezolvare
1-a 2-b 3-c 4-b 5-c 6-c 7-a 8-a 9-b 10-c
15
METODE SISTEMICE
OBIECTIVE:
- prezintă, explică şi exemplifică principiile metodologice, procedeele tehnologice

şi instrumentele caracteristice unei clase de metode de proiectare a sistemelor
informatice de gestiune (Merise) ;
- discutarea unor exemple de rezolvare a problemelor de gestiune în modelarea şi
proiectarea sistemelor informatice.
Cuvinte cheie:modelul conceptual al datelor, modelul conceptual al prelucrărilor, Merise,

metode sistemice.
CONŢINUT:
2. METODE SISTEMICE
2.1 Nivele de descriere
2.2 Modele pentru date şi prelucrări
2.3 Modelarea conceptuală şi organizaţională a datelor
2.4 Modelarea logică şi fizică a datelor
2.5 Modelarea Conceptuală a Prelucrărilor
2.6 Modelul Organizaţional al Prelucrărilor
2.7 Descrierea logică şi operaţională a prelucrărilor
2. METODE SISTEMICE
Dintre metodele sistemice, cea mai reprezentativă este metoda Merise, aplicată
pentru prima dată în 1979 în Franţa. Perfecţionată continuu, este utilizată şi astăzi cu
prioritate în informatica de gestiune. Este motivul pentru care, în lucrarea de faţă,
principalele particularităţi ale metodelor sistemice sunt prezentate prin prisma acestei
metode.
2.1 Nivele de descriere
În “Merise vers OMT et UML” ([GJ99]), prezentând descrierea sistemului de la

abstract la concret, autorii grupează nivelele de abstractizare în două mari clase. Într-o
primă clasă, nivelul conceptual şi nivelul organizaţional, corespund descrierii sistemului
informatic independent de soluţia informatică. Nivelul logic şi nivelul fizic constituie a
doua clasă, în care este luată în calcul soluţia informatică aleasă.
16
Nivelul conceptual urmăreşte obţinerea unei reprezentări fidele a realităţii, făcând
abstracţie de restricţiile informatice sau organizatorice. Surprinde cu ajutorul unor
abstracţii aspectul static şi dinamica în timp a activităţii desfăşurate.
Nivelul organizaţional leagă funcţionalitatea sistemului de organizarea firmei şi
de postul de lucru. Executate în timp real sau nu, procedurile manipulează date din
diferite compartimente funcţionale. La acest nivel, procedurile sunt descompuse în faze
executate pe posturi de lucru.
Nivelul logic vizează alegerea soluţiei informatice pentru culegerea datelor şi
furnizarea informaţiei. Procedurile sunt detaliate la nivel de module, a căror descriere
logică implică şi datele incluse într-un sistem relaţional.
Nivelul fizic este nivelul concret la care sunt definite mijloacele tehnice de
realizare efectivă a sistemului.
Cele patru nivele presupun construirea unor modele separate pentru date şi
prelucrări, constituind împreună ciclul de abstractizare al sistemului informatic.
2.2 Modele pentru date şi prelucrări
Pentru fiecare nivel există un model al datelor şi un model al prelucrărilor.

Nivelului conceptual îi sunt asociate modele rezultate din analiza sistemului real. Se
regăsesc în documentele redactate în urma proiectării generale.
Modelul Conceptual al Datelor (MCP) defineşte structura globală de organizare a
datelor, asigurând independenţă totală faţă de orice sistem de gestiune a bazelor de date.
Acordând prioritate datelor, pentru reprezentarea lor foloseşte un formalism precis,
normalizat pe plan internaţional de ISO (International Standard Organization) sub numele
de model “Entitate–Asociere”. Este realizat cu ajutorul conceptelor de entitate (obiect),
relaţie, proprietăţi, proprii formalismului Entitate-Asociere.
Modelul Conceptual al Prelucrărilor (MCP) descrie latura dinamică a sistemului,
evidenţiind înlănţuirea operaţiilor şi condiţiile declanşării acestora. Utilizează conceptele
de proces, operaţie şi eveniment.
La nivel organizaţional modelele definite apropie concepţia de ansamblu a
sistemului de structura organizatorică. Utilizând un formalism identic cu cel al modelelor
conceptuale, se definesc modele separate pentru date şi prelucrări.
Modelul Organizaţional al Datelor se construieşte în cazul sistemelor
informatice complexe, în care datele sunt distribuite pe diferite nivele organizatorice. El
prezintă mulţimea datelor grupate pe unităţi organizatorice. Existenţa tehnologiilor
client-server au crescut importanţa distincţiei între datele culese şi valorificate la nivelul
staţiilor de lucru şi datele gestionate de server.
Modelul Organizaţional al Prelucrărilor (MOP) se construieşte în situaţiile în
care operaţiile definite la nivel conceptual sunt executate în diferite compartimente
17
funcţionale. Prezintă procedurile descompuse în faze şi sarcini corespunzătoare posturilor
de lucru.
Modelele logice fixează o soluţie direct implementabilă, stabilesc realizarea
efectivă a sistemului informatic cu o bază de date relatională şi un sistem de gestiune a
bazelor de date corespunzător, sau cu ajutorul fişierelor de date exploatate cu limbaje
procedurale. În cazul informaticii de gestiune, demersul metodologic conduce la
implementare cu ajutorul bazelor de date relaţionale, datele fiind înmagazinate în
structuri stabile (tabele) şi manipulate cu un Sistem de Gestiune a Bazelor de Date
performant.
Modelul Logic al Datelor (MLD) se obţine conform standardelor Modelului
Relaţional al Datelor.
În cazul prelucrărilor, pentru că nu există o normalizare a descrierii logice a
prelucrărilor, nu există un Modelul Logic al Prelucrărilor ci o Descriere Logică a
Prelucrărilor (DLP).
La nivel fizic sunt specificate efectiv modalităţile de realizare a soluţiei
informatice alese. Ne existând un standard pentru definirea modelelor fizice de date şi
prelucrări, acest nivel este reflectat în Descrierea Fizică a Datelor (DFD) şi respectiv în
Descrierea Fizică a Prelucrărilor (DFP).
Descrierea fizică a datelor este legată de sistemul de gestiune al bazelor de date
ales pentru crearea bazei de date. Evidenţiază modul în care datele vor fi stocate şi
accesate la nivelul memoriei externe, sistemele care asigură securitatea păstrării şi
regăsirii datelor.
Descrierea fizică a prelucrărilor presupune realizarea soluţiei stabilite în cadrul
modelului logic al prelucrărilor, apelând la un anumit sistem de gestiune a bazelor de
date.
2.3 Modelarea conceptuală şi organizaţională a datelor

În această etapă, cînd nu se pune problema unei soluţii informatice, conceptele
sunt abstracţii ce reprezintă lumea reală ca o colecţie de entităţi şi de legături între
acestea.
Construirea Modelului Conceptual al Datelor este primul pas în reprezentarea
sistemelor reale în care se vehiculează un volum mare de date. Modelul Conceptual al
Datelor este un mijloc de comunicare între modelator (proiectantul sistemului informatic)
şi viitorul utilizator al sistemului. Împreună stabilesc obiectele lumii reale şi proprietătile
lor, împreună cuantifică restricţiile impuse de condiţiile concrete ale desfăsurării
activitătii sub forma simplă a unor reguli de gestiune.
În cazul în care există mai multe compartimente funcţionale, când datele sunt culese,
prelucrate sau utilizate în posturi de lucru diferite, Modelul Conceptual al Datelor se
18
detaliază conform structurii organizatorice. Se obţine astfel Modelul Organizaţional al
Datelor.
La ora actuală, când majoritate firmelor beneficiază de tehnică de calcul
performantă, de reţele Intranet, construirea modelului organizaţional al datelor
presupune:
 repartizarea datelor pe compartimente funcţionale;
 asigurarea vizibilităţii datelor pe diferite nivele organizatorice;
 stabilirea drepturilor de acces la date conform unui protocol determinat de arhitectura
sau de topologia reţelei existente;
 stabilirea volumului de date active, a volumului şi a condiţiilor de arhivare pentru datele
pasive.
2.3.1 Modelul Entitate-Asociere
Aşa cum am mai afirmat, modelarea conceptuală şi organizaţională a datelor se

face pe baza formalismului modelului Entitate-Asociere. Principalele concepte sunt:
entitate, asociere, atribut. Modelul Entitate-Asociere prezintă lumea reală ca o colecţie
de clase şi de legături de diferite tipuri între ele. Fiind reprezentarea unui sistem real, în
model trebuie evidenţiate şi modul în care realizările fiecărei entităţi sunt implicate într-o
asociere, numărul entităţilor care participă la o asociere. Vorbim astfel de cardinalitatea
cuplului Entitate-Asociere, de tipul de asociere şi de dimensiunea unei asocieri.
2.3.1.2 Caracteristici
entitate
ENTITATEA (E) este o reprezentare conceptuală a unui obiect sau
fenomen din sistemul real. Are existenţă proprie şi este conformă cu regulile
de gestiune ale firmei.
În activitatea de modelare nu interesează obiectele individuale, ci clasele în care
ele pot fi grupate în funcţie de caracteristici comune. Existenţa unei entităţi este
subordonată apartenenţei la o clasă, numele clasei fiind folosit pentru a referi elementele
unei clase. Componentele individuale sunt numite instanţe (realizări) ale claselor. Între
instanţă şi clasa sa se stabileşte astfel, prin grupul verbal ,,este membru în”, o relaţie.
Exemple:
FURNIZORI, este o clasă ce defineşte mulţimea persoanelor fizice/juridice de la
care s-a cumpărat sau s-a comandat cel puţin un articol.
“4011-Remex” este membru în clasa ,, FURNIZOR”
CLIENŢI, este o clasă ce defineşte mulţimea persoanelor fizice/juridice care au
comandat sau au cumpărat cel puţin un produs.
19
“4112-Amis” este membru în clasa “CLIENŢI ”
PRODUSE, este o clasă ce defineşte mulţimea bunurilor materiale cuprinse în
catalogul de vânzări al firmei.
“ calculator” este membru în clasa “PRODUSE”
Prin abuz de limbaj, în multe din lucrările ce vizează modelarea conceptuală se
foloseşte termenul de entitate în locul celui de clasă de entităţi. Convenim ca şi în
lucrarea de faţă să acceptăm că o entitate este o clasă generică de obiecte având
aceleaşi caracteristici pentru un modelator plasat într-un context dat. În toate aceste
situaţii, entitatea este reprezentată cu ajutorul unui dreptunghi în care este scris numele
entităţii şi proprietăţile ei.
asociere
ASOCIEREA (A) între entităţi exprimă o legătură existentă sau posibilă între obiecte
individuale. Clasele de asocieri sunt asocieri între clasele de obiecte individuale.
Respectând convenţia stabilită la definirea entităţii, vom spune că o asociere
este o clasă generică de legături recunoscute sau posibile între obiecte aparţinând
entităţilor din sistem.
În cadrul modelului conceptual al datelor, asocierea este reprezentată printr-o
elipsă care face legătura între entităţile participante la asociere.
Exemple:
FURNIZORI furnizează MATERII PRIME
atribut
ATRIBUTUL defineşte o proprietate distinctă a unei entităţi sau a unei
asocieri. Un atribut este considerat o mulţime de valori posibile.
Identitatea unei entităţi este exprimată printr-un atribut sau un grup
minimal de atribute care permit identificarea unică a realizărilor ei. Altfel
spus, fiecare entitate posedă un identificator, sau o cheie a entităţii. Pentru
o entitate pot exista mai multe atribute care să servească drept cheie. Acestea
se numesc chei candidate. Selectarea se face în funcţie de necesităţile
impuse de context, cheia principală putând fi formată din unul sau mai multe
atribute. Atributele cheie se marchează prin subliniere sau printr-o săgeată
spre entitatea căreia îi aparţin şi ale căror instanţe le identifică.
Celelalte atribute, care exprimă caracteristicile entităţii sunt şi ele
specificate în cadrul entităţii. Fiecare realizare a unei entităţi posedă valori
proprii pentru atribute.
Exemplu:
20
Pentru entitatea Furnizor, codul fiscal sau denumirea pot fi considerate
chei candidate. De cele mai multe ori, codul fiscal este ales cheie primară.
Entitatea FURNIZORI are ca atribute: CodFurnizor, Nume, Localitate; se reprezintă
astfel:
FURNIZORI
CodFurnizor
Nume
Localitate
O asociere poate avea atribute proprii. Atributele asocierii se specifică în elipsa ce
cuprinde numele asocierii (CantitateCumpărată).
CLIENŢI cumpără PRODUSE

CantitateCumpărată
Atributele pot fi clasificate în funcţie de mai multe criterii:

1. după realizările pe care le pot prezenta
• atribute cu realizări obligatorii, pentru care la momentul definirii se specifică “
NOT NULL”.
Exemplu: CodFurnizor, MaracSalariat.
• atribute opţionale, care pot să nu prezinte realizări în cazul unor entităţi.
Exemplu: adresa_e-mail a furnizorului, nr_telefon pentru angajaţi.
• atribute monovaloare, care prezintă o singură valoare în cadrul unei entităţi.
Exemplu: NumeClient, CantitateLivrată.
• atribute multivaloare, care prezintă mai multe valori în cadrul aceleiaşi entităţi.
Exemplu: în cazul în care o persoană cunoaşte mai multe limbi străine ce trebuie
evidenţiate, atributul LimbăStrăină este un atribut multivaloare; atributul numele
autorului este atribut multivaloare în cazul în care o carte are mai mulţi autori.
2. după complexitatea atributelor
• atribute elementare, cu realizări atomice. Exemplu: MarcăSalariat,
NumărMatricol, PreţUnitar.
• atribute decompozabile, ale căror realizări sunt formate dintr-un grup de valori
de tipuri diferite, care pot fi descompuse în realizări atomice. Exemplu: atributele ce
definesc Adresa sau DataCalendaristică.
Dintre atributele ce caracterizează entităţile definite în modelele sistemelor
informatice economice, o atenţie deosebită trebuie acordată factorului timp, care apare
sub forma datei calendaristice. Raportate la acest atribut, entităţile pot fi grupate în
entităţi permanente (CLIENŢI, PRODUSE, CREDITE) şi entităţi eveniment, ce
evidenţiază schimbări, modificări, produse la un moment dat (COMENZI, FACTURI,
21
PLĂŢI). Acestea din urmă, pe lângă atributele ce le identifică unic, posedă un atribut
care specifică data producerii lor (DataComenzii, DataFacturii, DataPlăţii.).
cardinalitate
Cardinalitatea dă informaţii despre numărul minim şi numărul maxim de apariţii ale
unei asocieri A între o entitate E1 şi o alta E2. Referind entitatea, (mulţimea legată prin
aplicaţie), şi asocierea, (aplicaţia mulţimii în altă mulţime), se vorbeşte de cardinalitatea
cuplului Entitate-Asociere (EA). Se defineşte ca un cuplu de întregi (x,y), unde:
 x reprezintă numărul minim de legături ce pot exista pentru o realizare dată a
entităţii.
 y reprezintă numărul maxim de legături ce pot exista pentru o realizare dată a
entităţii .
Pentru cardinalităţi, valorile semnificative utilizate în activitatea de modelare sunt
fie 0 şi 1 pentru cardinalitatea minimală, fie 1 şi n pentru cardinalitatea maximală. Se
evită astfel schimbarea modelului pe măsura ce se dezvoltă relaţia între două entităţi:
Dacă la momentul modelării potenţial există o legătură între realizările a două
entităţi, aceasta este reprezentată prin valoarea 0 a cardinalităţii minimale. Situaţiile în
care pot exista mai multe legături pentru o realizare dată a unei entităţi sunt reprezentate
de la început prin valoarea n a cardinalităţii maximale. Se evită astfel schimbarea
modelului pe măsura ce se dezvoltă relaţia între două entităţi.
Cardinalitatea minimală 0 precizează realizări de entităţi care nu participă efectiv
la asociere.
Exemplu:
Produsele obţinute în activitatea de producţie pot fi stocate în depozit sau pot face
obiectul vânzării, fiind înscrise pe dispoziţii de livrare. Altfel spus, un produs se poate
afla sau nu pe o dispoziţie de livrare (cardinalitatea minimală 0).
DISPOZIŢIE LIVRARE se întocmeşte 0,n PRODUS
Cardinalitate minimală 1 este în cazul în care toate realizările entităţii participă la

o realizare a asocierii;
Cardinalitatea maximală 1 defineşte situaţia în care realizările entităţii care
participă la asociere nu se pot modifica, în care legătura exprimată de asociere nu se
poate modifica;
Exemplu:
În activitatea de aprovizionare cu mărfuri, factura care însoţeşte marfa conţine
datele furnizorului. Nu există factură care să nu aibă un emitent (cardinalitate minimală
22
1). În acelaşi timp, pentru o factura nu pot exista mai mulţi furnizori cardinalitatea
maximală 1).
1,1
FACTURĂ FURNIZOR
corespunde
• cardinalitate maximală n se declară dacă numărul maxim de apariţii ale unei

asocieri nu este restricţionat de condiţii suplimentare, când o simplă descriere de stare
poate deveni restricţie de cardinalitate.
Exemplu:
În aprovizionarea cu mărfuri, de la un furnizor se pot primi mai multe facturi.
Numărul lor fiind nedefinit, se consideră cardinalitatea maximală n.
FACTURĂ FURNIZOR
corespunde 1,n
tip de asociere
O asociere poate lega între ele două sau mai multe entităţi. Tipul de asociere este
cuplul determinat de numărul de instanţe de entităţi care pot fi asociate de o parte şi de
cealaltă a asocierii.
Pentru asocierile binare, tipurile de asociere se stabilesc pornind de la
cardinalităţi, pe baza următoarei reguli.
Fie A o asociere binară legând două entităţi E1 şi E2. Fie (x1,y1) şi respectiv (x2,y2)
cardinalităţile cuplului (E1,A) şi (E2,A).
dacă y1=y2=1, atunci A este de tip 1:1
dacă y1>1 şi y2=1
sau
y1=1 şi y2>1 atunci A este de tip 1:n
dacă y1>1 şi y2>1 atunci A este de tip n:m
Există trei tipuri de asocieri.
Asocierea de tip ,,unu la unu” este asocierea în care unei realizări a entităţii E1
poate să-i corespundă prin asocierea A cel mult o realizare a entităţii E2, şi reciproc, unei
realizări din E2 nu poate să-i corespundă decât cel mult o realizare din entitatea E1.
Asocierea de tip ,,unu la mulţi” este asocierea în care unei realizări a entităţii E1
pot să-i corespundă prin asocierea A mai multe realizări ale entităţii E2, dar unei realizări
din E2 îi corespunde cel mult o realizare din E1. Acest tip de asociere se mai numeşte şi
asociere de ierarhizare, subordonarea prin ierarhie putînd fi reprezentată grafic printr-o
arborescentă.
23
Asocierea de tip ,,mulţi la mulţi” este asocierea în care unei realizări a entităţii E1
pot să-i corespundă prin asocierea A mai multe realizări din E2, şi reciproc. În practică,
această asociere se descompune în asocieri de tipul ,,unu la multi”, prin introducerea unei
entităţi intermediare.
dimensiune
Numărul de entităţi care participă la o asociere formează dimensiunea

(gradul) acesteia.
Asocierile pot fi unare (fig. 2.1.a), binare (fig. 2.1.b) şi ternare (fig. 2.1.c)
PRODUS
CodProdus
0,1 DenProdus 0,1
Gabarit
DataOmologării
este_format
NrComponente
fig. 2.1. a
FURNIZOR furnizeazå MATERII PRIME
fig. 2.1.b
CONTRIBUABIL DOCPLATĂ
CodCntribuabil plăteşte NrDoc
Nume DataDocument
TAXE
TipTaxă
sumă
fig. 2.1.c
24
2.3.1.2 Construirea modelului conceptual al datelor
Modelarea este un proces complex şi subiectiv, astfel că soluţia aleasă este

întotdeauna o variantă perfectibilă, imaginea modului în care modelatorul înţelege
realitatea. Metoda Merise propune în definirea modelului conceptual al datelor două
tehnici pentru definirea entităţilor şi a relaţiilor: modelarea prin entităţi (modelarea
directă) şi modelarea prin atribute.
Entităţile şi asocierile sunt principalele componente ale modelului conceptual al
datelor. După stabilirea lor conform uneia din tehnicile de modelare aleasă, modelul este
completat cu restricţiile ce-i asigură corectitudinea în raport cu sistemul real.
1 modelare prin entităţi
În cadrul acestei tehnici, entităţile şi relaţiile sunt identificate direct din rezultatele
etapei de proiectare generală, exprimate într-un limbaj simplu, comun modelatorilor
(Univers du discours). Pentru fiecare entitate se determină identificatorul şi celelalte
atribute. Cardinalităţile şi restricţiile se deduc în continuare din context.
PRACTIC, sunt formulate în limbaj simplu, comun, faptele şi evenimentele
apărute. Substantivele vor da naştere la entităţi şi verbele la relaţii.
Exemplu :
În cadrul activităţii de aprovizionare, facturile sunt emise de furnizori. Facturile
conţin mărfuri. Entităţile şi asocierile sunt:
emise FACTURI conţin MĂRFURI

cantitate
FURNIZORI
2 modelarea prin atribute

În cadrul acestei tehnici se examinează atributele (proprietăţi exprimate prin
valori) din documentele primare ce conţin datele de intrare în sistem, se identifică
dependenţele funcţionale dintre ele şi se decide cea mai bună cale de a le combina. Din
descrierea activităţii desfăşurate se stabilesc asocieri între entităţi, se evidenţiază modul
de implicare al entităţilor în asocieri.
PRACTIC se parcurg mai multe etape, pe care le prezentăm în continuare
însoţite de exemple din sistemul informatic privind acordarea unui credit pentru o firmă:
1 se structurează sub forma simplă a unor reguli de gestiune rezultatele fazei de
proiectare generală.
Exemplu:
25
 pentru a obţine un credit, o firmă trebuie să depună la bancă o informare privind
situaţia ei financiară. Această situaţie conţine, printre altele, valoarea capitalului
social şi profitul ultimului an.
 decizia de acordare a creditului este urmată de întocmirea unui dosar de credit, care
conţine informaţii privind suma acordată, termenul şi dobânda corespunzătoare
creditului. O firmă, devenită client al bancii, are pentru fiecare credit acordat un
dosar de credit.
 pentru creditul acordat, se deschide şi se actualizează la fiecare rată plătită de client,
o fişă de credit.
 ratele sunt plătite cu documente care, pe lângă propriile date de identificare, conţin
suma plătită
2  se alcătuieşte un tabel al atributelor conţinute în documentele primare .
Exemplu:
DOSAR CEDIT : Număr dosar, Data întocmirii dosarului, Termenul final al creditului,
Suma acordată, Dobânda calculată
FIŞA CREDIT : Număr fişă, Suma totală încasată, Dobânda, Penalităţi
DOCUMENT PLATĂ : Tip document, Număr document, Data document, Suma plătită
3 se construieşte dicţionarul atributelor, prin eliminarea atributelor calculate şi a
atributelor sinonime. Se adaugă atribute necesare codificării interne a firmei.
Exemplu:
Nr.Crt ATRIBUT Nr.Crt ATRIBUT
1 CodClient 10 NumarDosar
2 DenumireClient 11 DataDosar
3 AdresaClient 12 TermenFinal
4 CapitalSocial 13 SumaCredit
5 ProfitUltimulAn 14 DobindaCredit
6 TipDocument 15 NumărFişă
7 NumărDocument 16 SumaÎncasată
8 DataDocument 17 Dobânda
9 SumaDocument 18 Penalităţi
4 se stabilesc dependenţele funcţionale între atribute şi se construieşte matricea
simplificată a dependenţelor funcţionale în care:
. liniile sunt reprezentate de determinanţii dependenţelor funcţionale
. în coloane se înscriu atributele determinate (celelalte atribute din dicţionarul atributelor)
. în matrice se înscrie cifra 0 la intersecţia determinantului (linie) cu atributul determinat
(coloană)
Exemplu:
1 2 13 14 15 6+7 8 6+7  9
26
10 11 10 12 10 13 1014 15 16
1517 15 18
Matricea simplificată a dependentelor funcţionale este:
2 3 4 5 8 9 11 12 13 14 16 17 18
1 0 0 0 0
6+7 0 0
10 0 0 0 0
15 0 0 0
5 se creează entităţi distincte ce conţin câte un determinant şi atributele determinate de
el. În entităţi nu se includ atributele care au doi determinanţi (atributele cu două cifre 0
pe coloană). Atributele determinant constituie cheile entităţilor construite.
6 se stabilesc asocierile şi cardinalităţile pe baza regulilor de gestiune şi a dicţionarului
atributelor. Atributele care au doi determinanţi, sunt atribute ale asocierii dintre
entităţile ale căror identificatori sunt detrminanţii respectivi.
Entităţile, asocierile şi cardinalităţile sunt cele din figura 2.2.
CLIENT DOSAR CREDIT

CodClient 1,n corespund NrDosar
DenumireClient
e
DatăDosar
1,1
AdresaClient
TermenFinal 1,1
SumăCredit
are aparţine
DobândăCredit
1,1 1,1
SITUAŢIE FIŞĂ CREDIT
NrFişă
FINANCIARĂ SumaÎncasată
Dobândă
Penalităţi 1,n
CodClient
CapitalSocial actualizează
ProfitUltimAn 1,1
RATE
TipDocume
nt
NrDocumen
t
fig.2.2 DataDocument
SumaPCredit
Observaţii: SumaPDobânda
1 Am optat pentru entităţi distincte CLIENT şi SITUATIE FINANCIARA, pentru
faptul că atributele grupate în a doua entitate sunt analizate împreună în perspectiva
acordării unui credit.
27
2 Entitatea FISA CREDIT conţine câmpuri calculate: Suma Incasată, Dobânda,
Penalităţi, ceea ce contravine cerinţei conform căreia în Modelul Conceptual de Date nu
sunt incluse câmpuri calculate. S-a optat totuşi pentru această soluţie, deoarece fişa
creditului deschisă imediat după aprobarea creditului se utilizează permanent în urmărirea
rambursării creditului, şi e preferabil să consultăm un tebel cu datele actualizate la zi în
locul execuţiei repetate a procedurilor ce calculează valoarea acestor câmpuri.
În baza de date se crează un tabel corespunzător entităţii FISA CREDIT, cu
valoarea 0 în aceste câmpuri. Valorile corespunzătoare sumelor încasate, dobânzii şi
penalităţilor nu se încarcă de către operatori, ci se actualizează pin proceduri scrise
special.
2.3.1.3 Verificare. Normalizare. Descompunere
Indiferent de tehnica de modelare, asupra modelului se aplică operaţiile de

verificare, normalizare şi descompunere:
 verificarea presupune asigurarea că:
1. numele elementelor ce apar în modelul conceptual al datelor sunt unice.

2. identificatorii compuşi dintr-un grup de atribute trebuie să nu conţină un subgrup în
interiorul acestora care să poată fi folosit ca identificator.
3. o asociere nu poate exista decât o singură dată între aceleaşi entităţi. Dacă apar mai
multe asocieri, soluţia este transformarea asocierii într-o nouă entitate.
4. atributele derivate, cele ale căror valori se obţin din calcule, nu apar în modelul
conceptual al datelor. (excepţie fac situaţiile în care acestea prezintă o semnificaţie
particulară pentru problema studiată, făcând parte din restricţii de integritate).
 normalizarea este un proces care asigură:
• eliminarea redundanţelor fără pierdere de informaţie;
• eliminarea anomaliilor în procesul de actualizare.
În cazul entităţilor, normalizarea permite asigurarea că nu există atribute
repetitive sau compuse într-o entitate.
Exemplu:
În sistemul informatic privind aprovizionarea cu mărfuri, pentru fiecare furnizor
există un atribut care conţine informaţii despre obiectul aprovizionării (tipul de marfă,
denumirea, cantitatea aprovizionată)
FURNIZOR
CodFiscal
Nume
Marfa
28
Normalizarea impune definirea unei noi entităţi, MARFA, şi a unei asocieri aduce
, cu atributul cantAprov (canitate aprovizionată)
FURNIZOR aduce MARFA

CodFurnizor 1,n cantAprov 0,n CodMarfa
Nume DenMarfa
În cazul asocierilor, normalizarea permite asigurarea că atributele unei asocieri

depind în totalitate de identificatorii entităţilor participante.
Exemplu:
FACTURI 0,n conţin 0,n MATERIALE

NrFactura cantitate CodMaterial
Data preţ Denumire
De asemenea în exemplul anterior, cantAprov este atribut care depinde de ambele

entităţi. El apare ca atribut al asocierii.
 descompunerea permite definirea, fără pierdere de informaţie, a mai multor

relaţii de dimensiune doi dintr-o relaţie de dimensiune mai mare.
Descompunerea se bazează pe dependenţe funcţionale şi este posibilă în
următoarele condiţii:
• există cel puţin o dependenţă funcţională între roluri;
• există o cardinalitatea 0,1 sau 1,1, toate celelalte fiind 0,n sau 1,n.
Descompunerea se face în două asocieri, una exprimând raportul determinant --
determinat, iar cealaltă preluând restul asocierii iniţiale.
Exemplu:
În cazul:
CONTRIBUABIL DOC PLATĂ

CodContribuabil 1,n plăteşte 1,1 NrDoc
Nume DataDocument
Adresă 0,n
29
TAXE
TipTaxă
Sumă
descompunerea este:
CONTRIBUABIL DOC PLATĂ
CodContribuabil 1,n 1,1 NrDoc
Nume plăteşte DataDocument
Adresă
1,1
TAXE
TipTaxă 1,n corespund
Sumă
2.3.1.4 Restricţii
Pe lângă definirea entităţilor şi asocierilor, în modelul Entitate-Asociere trebuie
luate în calcul cerinţe ce asigură corectitudine şi coerenţă în raport de realitatea pe care
modelul o reflectă. În general sunt restricţii ce privesc domeniul de definiţie al atributelor
sau evoluţia lor în timp.
Restricţiile de integritate sunt reguli suplimentare, nereprezentate direct în
modelul conceptual al datelor, dar care trebuie respectate permanent de date.
Într-o primă clasificare, restricţiile de integritate se împart în două mari grupe:
restrictii statice (se verifică permanent), şi restricţii dinamice (privesc evoluţia în timp
a datelor).
Exemple :
 restricţii statice:
. DataOmologării unui produs obţinut în secţiile de producţie proprii este
întotdeauna anterioară datei documentului cu care produsul este vândut (DataDoc)
. cota_tva=19% .
 restricţii dinamice:
. o persoană poate să-şi completeze studiile şi implicit să-şi schimbe ocupaţia.
Dacă în entitatea PERSOANE se specifică atributul Ocupaţie, acesta poate lua în timp
diferite valori
30
. pentru entitatea CITITOR, dacă specificăm atributul CategorieCititor, acesta
poate lua valorile: student, cadru didactic, doctorand.
Intr-o altă clasificare, restricţiile pot fi grupate în restrictii structurale şi restricţii
semantice.
Restricţiile de integritate structurale se referă la:
 integritatea entităţilor, vizând faptul că fiecare entitate trebuie identificată
în mod unic;
 integritatea referenţială, vizând faptul că pentru orice realizare a unei
asocieri este obligatoriu să existe realizări pentru entităţile participante;
 cardinalităţi, vizând respectarea condiţiilor în cazul cardinalităţilor
minimale şi maximale.
Restricţiile de integritate semantice sunt introduse de utilizator pentru a reflecta
corect realitatea. Sunt expresia regulilor de gestiune aplicate în firmă, consecinţă a
reglementărilor legislative şi normative în vigoare, a regulamentelor şi normelor interne.
Aceste restricţii nu apar explicit în modelul conceptual al datelor, fiind implementate în
procesul creării relaţiilor aparţinând bazei de date.
Ele pot implica:

•1• valorile pe care le pot lua atributele entităţilor şi asocierilor;
Domeniul, ca mulţime de valori pentru atribute, poate fi definit printr-o
proprietate sau prin enumerarea valorilor posibile. Restricţiile de domeniu sunt condiţii
care privesc ansamblul de valori acceptate pentru un atribut în cadrul tipului sau
domeniului său. Ele pot viza:
• conţinutul unui singur atribut al unei entităţi sau asocieri
Exemplu( fig.2.3) :
um = {kg,buc,m}
cota_tva = 19%
produsul cel mai vechi din catalog a fost omologat în 12.12.96;
• corelaţii între valorile mai multor atribute ale aceleiaşi entităţi sau asocieri
Exemplu (fig.2.3) :
în codificare, gestiunea poate lua valori în mulţimea M, unde M={ 01,12,22}.
În gestiunea cu codul 01, se stochează doar produsele care au codurile specificate
în mulţimea {1000,1001,1104}
• corelaţii între atributele mai multor entităţi sau asocieri diferite
Exemplu(fig.2.3) :
în cazul unui produs obţinut în secţiile proprii de producţie şi depozitat într-o
gestiune, data stoc > data omologării
în cazul înregistrării oricărui document primar, data_document trebuie să fie
anterioară datei curente
31
• corelaţii cu valori obţinute pe baza unor operaţii de sintetizare (însumare,medie)
a unui ansamblu de entităţi
Exemplu(fig.2.3) :
suma cantităţii livrate pentru un produs nu poate depăşi stocul de la o anumită
dată.
DISPLIVRARE PRODUS
NrDoc priveşte CodProdus
DataDoc 1,n cant_livrată 0,n DenProdus
NrContr DataOmologarii
CotaTva
1,n 1,1
modifică stabilesc
1,n data_stoc
STOC 1,1
CodGestiune
Stoc
fig. 2.3
•2• asocierile stabilite între entităţi.

Restricţiile de integritate ce vizează asocierile dintre entităţi, pot determina relaţii
de incluziune, egalitate sau excluziune între asocieri.
Incluziunea relaţiilor
Exemplu:
Pentru a fi livrată, orice marfă trebuie să fie facturată. Acest fapt determină o
relaţie de incluziune între asocierile facturare şi livrare.
livrare
MARFĂ dataL CLIENT
CodMarfă 1,1 0,n CodClient
I
32
0,1 facturare 1,1
d ataF
Excluziunea relaţiilor
Exemplu:
Având în vedere că un acelaşi produs nu poate fi vândut şi donat în acelaşi timp,
între asocierile vânzare şi donare există o relaţie de excluziune.
0,n vânzare 1,1

PRODUS vândut cumpărat CLIENT
CodProd # CodClient
Denumire Nume
donat obţinut Adresă
0,n donare 1,1
Egalitatea relaţiilor
Exemplu:
Admitând că depozitarea în gestiune se face concomitent cu înscrierea în fişa de
magazie, între asocierile depozitare şi înscriereFm există o relaţie de egalitate.
depozitare
MATERIAL 1,n 1,n GESTIUNE
CodMat = CodGest
Nume Nume
1,n înscriereFm 1,n
2.4 Modelarea logică şi fizică a datelor
Modelarea logică depinde de particularităţile datelor vehiculate şi de posibilităţile

oferite de tehnica de calcul a momentului. În [GJ99] se afirmă chiar că “expresia
Modelului Conceptual al Datelor în termenii unui anumit tip de soluţie informatică
constituie Modelul Logic al Datelor”.
Prin modelarea logică se urmăresc trei obiective[OD99]:
1. structurarea performantă a datelor prin procesul de normalizare.
33
2. realizarea unui model al datelor care răspunde cerinţelor impuse de formularele şi
documentele prin care se preiau datele de la utilizator (perspectiva sistemului prin prisma
utilizatorului).
3. obţinerea unui model logic al datelor din care să se poată realiza proiectul bazei de date
fizice.
În cazul sistemelor informatice ce vizează activitatea economică, volumul mare
de date cu care se vehiculează este caraterizat printr-o organizare uniformă, constituită
din tipuri de înregistrări cu caracteristici asemănătoare, determinate de structura
documentelor primare. Operaţiile de prelucrare automată au un caracter repetitiv şi o
frecvenţă mare de executare. Operatorii sunt simplii şi execută în majoritatea cazurilor
prelucrări succesive asupra caracteristicilor de acelaşi tip. Aceste observaţii au condus la
alegerea sistemelor relaţionale drept soluţie direct implementabilă .
Faţă de metodele tradiţionale care utilizau fişiere strict dependente de aplicaţii,
bazele de date relaţionale şi sistemele de gestiune corespunzătoare prezintă câteva
avantaje care le-au impus în aplicaţiile de gestiune. Dintre acestea amintim:
• redundanţă minimă şi controlată a datelor;
• integritate şi accesibilitate deosebită la ele;
• posibilitatea introducerii standardelor la nivelul bazelor de date;
• posibilitatea partajării între diverşi utilizatori.
Modelarea fizică a datelor presupune trecerea de la descrierea logică a datelor
la una tehnică, de stocare a datelor. Rezultatele modelării fizice se concretizează într-un
set de specificaţii tehnice folosite ulterior de programatorii bazelor de date pentru
definirea formatului şi structurii datelor stocate în memoria secundară. Studiul tehnic
conţine formatele sub care vor fi reprezentate atributele, modul de gruparea al acestora
din una sau mai multe relaţii, în una sau mai multe înregistrări fizice, precum şi
metodele de accesare a datelor.
Selectarea tehnologiilor folosite pentru stocarea datelor se face ţinând cont că
fiecare tehnologie este specifică unei anumite arhitecturi a sistemului.
Descrierea fizică a datelor este legată de sistemul de gestiune al bazelor de date
ales pentru crearea bazei de date. Vizează modul în care datele vor fi stocate şi accesate
la nivelul memoriei externe, sistemele care asigură securitatea păstrării şi regăsirii
datelor.
2.4.1 Trecerea de la modelul Entitate-Asociere la Modelul Relaţional
După cum am mai afirmat, la nivel logic există un standard pentru descrierea
datelor: Modelul Relaţional al Datelor. Mai mult există reguli stricte de obţinere a
Modelului Relaţional al Datelor pornind de la modelul Entitate-Asociere. Respectând
aceste standarde, din punctul de vedere al datelor, proiectarea sistemelor informatice se
34
reduce la parcurgerea unor etape clar definite, cu respectarea unor formalisme unanim
recunoscute. Este un pas important spre automatizarea trecerii de la concepţie la realizare.
Pentru trecerea de la modelul Entitate-Asociere la Modelul Relaţional s-au stabilit

următoarele reguli [DL92]:
1.- fiecărei entităţi i se asociază o schemă de relaţie compusă din toate atributele
entităţii.
2.- dacă într-o asociere A există o entitate E pentru care cardinalitatea maximală
a cuplului (E,A) este 1, se adaugă la schema de relaţie R definită pentru E cheia entităţii
ce participă la asocierea A şi atributele asocierii.
Exemplu: Presupunînd că un anume tip de materii prime este aprovizionat de la
un furnizor, şi că un furnizor poate furniza mai multe tipuri de materii prime, modelul
conceptual al datelor este :
FURNIZORI 1,n furnizează 1,1 MATERIIPRIME

CodFurnizor CodMatPrime
Nume Cantitate
Localitate Preţ
Aplicînd regula 1 se crează două scheme de relaţie:

R-Furnizori = ( CodFurnizor, Nume, Localitate )
R-MatPrime = ( CodMatPrime, Cantitate, Pret).
Cardinalitatea cuplului (MATERIIPRIME, furnizează ) este (1,1). Aplicînd regula
2 avem următoarele scheme de relaţie:
R-Furnizori = (CodFurnizor, Nume, Localitate )
R-MatPrime = (CodMatPrime, Cantitate, Pret, CodFurnizor)
CodFurnizor de la relaţia R-Furnizori este acelaşi cu CodFurnizor de la relaţia R-
MatPrime. Această restricţie se numeşte restricţie de integritate referenţială.
3.-dacă într-o asociere A, pentru ambele entităţi cardinalitatea maximală este n,
se crează o nouă schemă de relaţie conţinînd cheile entităţilor ce participă la asociere şi
atributele asocierii.
Exemplu:
Presupunînd că un acelaşi tip de materii prime este aprovizionat de la mai mulţi
furnizori, şi că un furnizor poate furniza mai multe tipuri de materii prime, modelul
conceptual al datelor este :
FURNIZORI 1,n 1,n MATPRIME

CodFurnizor furnizează CodMatPrime
35
Nume Cantitate
Localitate Pret
Aplicând regula 1 se crează două scheme de relaţie:

R-Furnizori = ( CodFurnizor, Nume, Localitate)
R-MatPrime =(CodMatPrime, Cantitate, Pret)
Aplicâd regula 3, se crează o nouă schemă de relaţie, ce cuprinde cheile celor
două entităţi şi atributul asocierii:
R-Furnizează = ( CodFurnizor, CodMatPrimel)
Exemplu :
Aplicând regulile prezentate anterior pentru Modelul Conceptual de Date din figura 2.2,
rezultă următorul Model Logic de Date:
R-Client = (CodClient, DenumireClient, AdresaClient)
R-DosarCredit=(NrDosar,DataDosar,TermFin,SumăCredit,DobCredit, CodClient)
R-FisaCredit = (NrFisă, SumaIncasată, Dobândă, Penalităţi, NrDosar)
R-Rate = (TipDoc, NrDoc, DataDoc, SumaPCredit, SumaPDobândă, NrFisă)
2.5 Modelarea Conceptuală a Prelucrărilor
Modelul Conceptual al Prelucrărilor permite descrierea activităţilor din sistemul real prin
descompunerea unui proces în operaţii. Permite reprezentarea înlănţuirii operaţiilor şi
precizarea condiţiilor declanşării acestora. Conceptele de bază sunt: proces, operaţie şi
evenimet.
proces
Procesul este constituit dintr-o submulţime de activităţii independente de
structura organizatorică a firmei, care au puncte de intrare şi de ieşire stabile.
Exemple:
Cerere de credit Comanda acceptată
Acordarea Gestiunea
unui credit facturilor
36
Cerere respinsă Factură emisă
Credit acordat Factură încasată
eveniment
Evenimentul indică faptul că “ceva” anume s-a întâmplat şi în consecinţă
sistemul trebuie să reacţioneze. Este o circumstanţă, un semnal adus la cunoştinţa
sistemului şi la care acesta trebuie să răspundă.
Pentru a fi considerat eveniment, semnalul trebuie să fie perceput de sistem,
trebuie să fie declanşatorul posibil al unei activităţi.
Exemplu:
Într-un sistem de evidenţă a personalului, faptul că pentru un angajat se
completează foaie de pontaj constituie un eveniment, deaorece el declanşează
activitatea de evidenţă a salariaţilor, dar acest fapt nu constituie un eveniment pentru
sistemul informatic de gestiune a clienţilor.
În funcţie de poziţia faţă de sistemul informatic, în cadrul modelului
conceptual al prelucrărilor se identifică evenimente interne şi evenimente externe.
Evenimentele externe provin din exteriorul sistemului studiat şi declanşează
în interiorul lui executarea unor activităţi. Evenimentele externe nu pot fi controlate,
asupra lor neputându-se interveni.
Exemplu: modificarea cursului leului, modificarea procentului de TVA,
modificarea procentului în cazul impozitului pe salarii.
Evenimentele interne survin la încheierea unei operaţii din cadrul sistemului
studiat şi se grupează în evenimente rezultat şi evenimente intermediare.
Evenimentele rezultat, reprezentate de ieşiri ale prelucrării în cadrul
sistemului informatic proiectat, sunt destinate mediului extern al sistemului.
Exemple:
Evenimentele reprezentate de: factura întocmită remisă clientului, ordinul de
plată întocmit şi depus la bancă, declaraţia de TVA întocmită şi depusă la organul
fiscal.
Evenimentele intermediare sunt pe de o parte rezultate din executarea unor
operaţii şi pe de altă parte declanşează alte operaţii în cadrul sistemului.
Exemple:
Întocmirea Notei de Receptie şi Constatare de Diferenţe în urma recepţionării
mărfurilor, întocmirea Bonului de Consum, a Bonului de Predare-Primire.
Reprezentarea grafică a evenimentelor utilizează următoarele simboluri:
37
Ee Ei E
Eveniment Eveniment Eveniment

extern intern rezultat
Evenimente contributive Evenimente emise

(declanşează acţiuni (de sistem)
în cadrul sistemului)
operaţia
Operaţia reprezintă o secvenţă continuă de activităţi producătoare de
evenimente. Operaţia constituie “un bloc de prelucrare”, o succesiune de activităţi
elementare care se execută neîntrerupt din momentul declanşării.
Operaţiile sunt declanşate de evenimente externe sau de evenimente
intermediare şi conduc la producerea de evenimente intermediare sau rezultat, în
funcţie de respectarea unor anumite condiţii, numite reguli de emisie. Condiţiile sunt
expresia unor situaţii determinate de contextul în care are loc derularea operaţiei,
cunoscute în momentul derulării operaţiei.
sincronizare
O operaţie nu se poate declanşa decât dacă se realizează anumite condiţii, deci
se produc anumite evenimente, numite evenimente contributive. Ansamblul
condiţiilor care determină declanşarea unei operaţii este cunoscut sub denumirea de
sincronizare. Într-o manieră generală, sincronizarea se exprimă sub forma unei
propoziţii logice care trebuie să respecte următoarele reguli:
• condiţiile trebuie să privească evenimentele declanşatoare (contributive)
• condiţiile nu trebuie să se refere la informaţia din baza de date;
• trebuie să existe cel puţin o situaţie care permit declanşarea operaţiilor.
O operaţie se reprezintă astfel:
E1 E2 Evenimente
declanşatoare
Propoziţia logică
numele sincro-
nizării Sincronizare
38
Nr. Operaţia
Descrierea operaţiei Operaţia
Reguli de emisie
Ei3 Ei4
Eveniment rezultat Eveniment intern

Intermediar
2.5.2 Construirea Modelului Conceptual al Prelucrărilor
În construirea Modelului Conceptual al Prelucrărilor se parcurg următoarele

etape:
a• delimitarea domeniilor de activitate şi a proceselor corespunzătoare. În cazul
sistemelor complexe, se analizează activităţile desfăşurate şi se grupează într-un procese
cele care, independent de structura organizatorică, sunt determinate de aceleaşi
evenimente externe (au puncte de intrare stabile) şi au aceeaşi finalitate (au puncte de
ieşire stabile) ;
b• identificarea evenimentelor interne şi identificarea sincronizării
Se specifică evenimentele declanşatoare şi dacă este cazul, durata sincronizării. Se au în
vedere condiţiile reciproce de determinare a evenimentelor declanşatoare, faptul că
trebuie să existe cel puţin o situaţie care să permită declanşarea operaţiilor.
c• definirea operaţiilor. Se analizează acţiunile şi se precizează condiţiilor de
obţinere a rezultatelor, adică se identifică regulile de gestiune care conduc la obţinerea
rezultatelor. Se are în vedere că o operaţie este o succesiune neântreruptă de prelucrări, că
în interiorul unei operaţii nu se admite producerea unui rezultat intermediar care să
condiţioneze derularea operaţiei.
După parcurgerea acestor etape se poate trece la prezentarea înlănţuirii operaţiilor
din cadrul fiecărui proces. Se are în vedere faptul că o operaţie este declanşată de cel
puţin un eveniment şi că orice operaţie declanşează la rândul ei cel puţin un eveniment.
Modelului Conceptual al Prelucrărilor este rezultatul reprezentării tuturor

proceselor identificate în cadrul sistemului real.
Exemplu pentru sistemul informatic privind acordarea unui credit:

. înlănţuirea operaţiilor şi a evenimentelor declanşatoare în cazul procesului de întocmire
a dosarului de credit este prezentată în figura 2.4
39
.înlănţuirea operaţiilor şi a evenimentelor declanşatoare în cazul procesului de avizare a
dosarului de credit este prezentată în figura 2.5
.înlănţuirea operaţiilor şi a evenimentelor declanşatoare în cazul procesului de urmărire a

creditului acordat este prezentată în figura 2.6
Cerere credit Documentaţie

E1 E2
E1 si
E2
01 Preluare documente
Incărcare date despre client şi situaţia

lui financiară
DA NU
Cerere inregistrată
02 Analiză situaţie financiară
Calcul coeficienţi Cuantificare risc
Coeficienti risc Posibila acordare

ridicat de credit
Cerere respinsă Cerere admisă
03 Analiza nivel de responsabilitate
DA
Suma < 100.000.000 NU
40
Dosar intocmit Dosar respins

Dosar de credit
intocmit
fig.2.4
01 Avizare conducere
Semnarea dosarului de către
conducere
DA NU
Dosar avizat Dosar neavizat
02 Avizare client
Semnarea dosarului de către client
DA NU
Dosar semnat Dosar nesemnat
03 Deschidere fişăcredit
Deschiderea fişei de evidenţă
operativă a creditului
DA NU
41
Fişă credit deschisă
fig.2.5
Fişă de
Document Termen
credit
de plată scadent
deschisă
Fişă de credit
actualizata Credit restant
^
1 Operaţii legate de scadenta

Inregistrarea ordinelor de plata
Da Nu
42
Fişă credit
actualizată
2 Calcul penalităţi
Penalităţi, intarzieri
Calcul dobanda
Da Nu
Penalităţi
calculate
3 Actualizare fişa credit

Inscriere penalităţi
Inscriere dobandă
Da Nu
fig.2.6
2.6 Modelul Organizaţional al Prelucrărilor
Modelul Organizaţional al Prelucrărilor prezintă mulţimea operaţiilor luînd în

calcul structura organizatorică a firmei, posturile de lucru ce reprezintă unităţi de
acţiune elementare dotate cu mijloace de execuţie. Postul de lucru este reprezentat prin
ansamblul format din echipamentele de prelucrare automată a datelor şi persoana ce le
utilizează.
Modelarea organizaţională prezintă prelucrările din punctul de vedere al
utilizatorului, care îşi desfăsoară activitatea în condiţiile concrete ale firmei, ale
compartimentelor ei funcţionale. Înlănţuirea procedurilor, descompunerea lor în faze
se face în concordanţă cu structura organizatorică a firmei, cu legislaţia în viguare, dar
fără a considera o anume soluţie informatică de implementare.
Principalele concepte sunt: procedură, fază, sarcină.

procedura
O procedură este constituită dintr-un ansamblu de prelucrări declanşate de unul
sau mai multe evenimente externe. Producând unul sau mai multe rezultate, procedura
corespunde executării de către firmă a unui ansamblu de reguli de gestiune.
Exemplu:
. procedura de acordare a creditelor într-o instituţie bancară
. procedura de gestionare a facturilor
faza
43
Faza este o succesiune neîntreruptă de prelucrări, cu aceeaşi periodicitate,
executate într-un post de lucru. O succesiune de faze aparţinând aceluiaşi proces
alcătuiesc o procedură.
sarcina
Sarcina este reprezentată de o mulţime de prelucrări elementare, executate în
interiorul unei faze.
2.6.2 Construirea Modelului Organizaţional al Prelucrărilor
Modelului Organizaţional al Prelucrărilor se obţine din Modelul Conceptual al
Prelucrărilor, luând în calcul structura organizatorică a firmei. Fiecărui proces din
Modelul Conceptual al Prelucrărilor îi corespund una sau mai multe proceduri în Modelul
Organizaţional al Prelucrărilor. Pentru fiecare operaţie din Modelul Conceptual al
Prelucrărilor, în Modelul Organizaţional al Prelucrărilor corespund una sau mai multe
faze.Client Conducere Creditare Calculaţie
contabilitatepentru un sistem
Cu aceste consideraţii, Modelul Organizaţional al Prelucrărilor
informatic este rezultatul reprezentărilor corespunzătoare tuturor proceselor din Modelul
Conceptual al Prelucrărilor 01 Preluare
Exemplu
Cerere D document
In cazul sistemului informaticTimp
credit 02
de acordare a creditelor, seCalcul
construieşte câte un
real Timp coeficienti
Model Organizaţional de Prelucrări pentru fiecare proces delimitat în Modelul
real
Conceptual al Prelucrărilor:
.. înDocume
figura 2.7 este reprezentat Modelul Organizaţional al Prelucrărilor pentru procesul de
n
întocmiretaţiea dosarului de credit
Cerere
inregistrata
.. în figura 2.8 este reprezentat Modelul Organizaţional al Prelucrărilor pentru procesul de
avizare a creditului Coeficienti
calculati
.. în figura 2.9 este reprezentat Modelul Organizaţional al Prelucrărilor pentru procesul
de urmărire a creditului acordat
03 Cuantificare
risc
Timp
real
NU DA
Cerere Cerere
respinsa admisa
04
Analiza
manual nivel
r NU DA
respon-
44
Dosar Dosar
respins sabilitate
intocmit
Client Conducere Creditare Calculatie
contabilitate
Dosar
intocmit
1 fig. 2.7
Avizare
Man
Dosar ual
neavizat condu-
NU DA
cere
Dosar
avizat
Dosar
aprobat
2
Semnarea
dosarului
manu 3
alNU de Deschidere
DA Timp
catre fisa
real
credit
c
Dosarclient
nesemna
t
Fisa
credit
deschisa
45
Fig.4.6
fig.2.8
Client Creditare Calculatie
01 Verificare termen
Timp scadent
Docum
ent de real Da Nu
plata
Credit
restant
Document
de plata la 03 Calcul
termen Timp penalitati
real Da Nu
02 Inregistrarea
Timp documentelor de
Penalitati plata
real
calculate
Da Nu
E2
Documen
t de plata
E1
46
04 Calcul dobanda
Timp
E1 sau real Da Nu
(E2 şi
E3)
Doband
05 Actualizare fisa a
Timp credit calculată
real Da Nu E3
Fisa de
credit
actualizata
Fig. 2.9
2.7 Descrierea logică şi operaţională a prelucrărilor
La nivel logic şi operaţional sunt luate în calcul problemele tehnice şi restricţiile

impuse de mediul de programare existent la nivelul firmei:
. tipul de reţea utilizat ;
. particularităţile server-ului şi ale posturilor de lucru ;
. SDBD-ul utilizat ;
. sistemul informatic actual, posibilităţile de extindere.
Dezvoltarea rapidă a tehnologiei informaţiei, libertatea de a alege cea mai bună
soluţie în funcţie de context, au limitat definirea unor modele standard de descriere a
prelucrărilor la nivel logic şi operaţional. La ora actuală nu există un formalism unanim
recunoscut pentru descrierea prelucrărilor la nivel logic şi operaţional. Există însă un
principiu general, admis momentan de toţi proiectanţii de sisteme informatice, conform
căruia o fază descrisă la nivel organizaţional se poate descompune în trei tipuri de
sarcini, ce vizează:
1 prezentarea datelor conform cerinţelor utilizatorilor.
2 calcule, actualizări, validări
3 accesul la date
Indiferent de tipul de sarcină, la acest nivel prelucrările sunt prezentate în
legătură directă cu datele. Dacă în primul caz accentul cade pe modul de afişare a
informaţiilor, în ultimele două cazuri prioritară este reprezentarea internă a datelor, în
47
funcţie de care se definesc proceduri standard de consultare, actualizare, de citire sau
scriere în baza de date.
În primul caz un loc important îl ocupă definirea interfeţei cu utilizatorul,
inserarea unor obiecte vizuale predefinite care să faciliteze afişarea informaţiilor
conform unor criterii de selecţie stabilite la momentul interogării.
În cazul al doilea, formulele de calcul, expresie a regulilor de gestiune, sunt
aplicate împreună cu proceduri de control privind respectarea restricţiilor de integritate.
Consultarea sau actualizarea bazei de date este precedată de execuţia unor proceduri ce
vizează drepturile de acces, care sunt determinate de restricţiile impuse de mediul de
programare. Există proceduri pentru gestionarea drepturilor de acces şi proceduri pentru
soluţionarea eventualelor incidente sau erori apărute la execuţie.
Pentru toate aceste proceduri, modul concret de implementare depinde de soluţia
informatică aleasă, de performanţele tehnicii de calcul existente şi de capacitatea
proiectanţilor de a alege cele mai bune soluţii. În cazul sistemele informatice de
gestiune, corespunzător sistemul relaţional de reprezentare a datelor, pentru
manipularea lor se utilizează un SGBD relaţional. Se poate apela şi la un limbaj de
programare ce oferă facilităţi în definirea interfeţei cu utilizatorul, în codificarea
regulilor de validare sau în efectuarea unor calcule laborioase.

a) Nivelul conceptual urmăreşte obţinerea unei reprezentări fidele a realităţii, ţinând
cont de restricţiile informatice sau organizatorice.
b) Nivelul organizaţional leagă funcţionalitatea sistemului de strucura organizatorică
a firmei şi de postul de lucru.
c) Nivelul organizaţional urmăreşte obţinerea unei reprezentări fidele a realităţii,
făcând abstracţie de restricţiile informatice sau organizatorice.

a) Nivelul organizaţional leagă funcţionalitatea sistemului de soluţia informatică
adoptată
b) Nivelul logic vizează alegerea soluţiei informatice pentru culegerea datelor şi
furnizarea informaţiei.
c) Nivelul fizic este nivelul concret la care sunt definite mijloacele tehnice de
realizare efectivă a sistemului.
48
a) Modelul Conceptual al Datelor surprinde cu ajutorul unor abstracţii aspectul static
şi dinamica în timp a activităţii desfăşurate.
b) Modelul Conceptual al Datelor defineşte structura globală de organizare a datelor,
asigurând independenţă totală faţă de orice sistem de gestiune a bazelor de date.
c) Modelul Conceptual de Date foloseşte un formalism precis, normalizat pe plan
internaţional de ISO sub numele de model “Entitate–Asociere”.

a) Modelul Conceptual al Prelucrărilor descrie latura dinamică a sistemului,
evidenţiind înlănţuirea operaţiilor şi condiţiile declanşării acestora.
b) Modelul Organizaţional al Datelor prezintă mulţimea datelor grupate pe unităţi
organizatorice.
c) Modelul Conceptual al Prelucrărilor se construieşte în situaţiile în care operaţiile
definite la nivel conceptual sunt executate în diferite compartimente funcţionale.

a) Entitatea este o reprezentare conceptuală a unui obiect sau
fenomen din sistemul real.
b) Entitatea are existenţă proprie şi este conformă cu regulile de
gestiune ale firmei.
c) O entitate este considerat o mulţime de valori posibile.

a) Asocierea între entităţi exprimă o legătură existentă sau posibilă
între obiecte individuale.
b) Identitatea unei entităţi este exprimată printr-un atribut care
permite consultarea realizarilor de entitate.
c) Atributul defineşte o proprietate distinctă a unei entităţi sau a
unei asocieri.
a) Fiecare realizare a unei entităţi posedă aceleaşi valori pentru
atribute.
b) O asociere nu poate avea atribute proprii.
c) Cardinalitatea dă informaţii despre numărul minim şi numărul maxim de apariţii
ale unei asocieri A între o entitate E1 şi o alta E2.

a) În construirea Modelului Conceptual al Datelor există două tehnici pentru
definirea entităţilor şi a relaţiilor: modelarea prin entităţi şi modelarea modelarea directă.
49
b) Normalizarea este un proces care asigură eliminarea redundanţelor fără pierdere
de informaţie;
c) Normalizarea este un proces care asigură eliminarea anomaliilor în procesul de
actualizare.

a) În cazul entităţilor, descompunerea permite asigurarea că nu există atribute
repetitive sau compuse într-o entitate.
b) În cazul asocierilor, normalizarea permite asigurarea că atributele unei asocieri
depind în totalitate de identificatorii entităţilor participante.
c) Descompunerea permite definirea, fără pierdere de informaţie, a mai multor relaţii
de dimensiune doi dintr-o relaţie de dimensiune mai mare.

a) Restrictii de integritate statice sunt restricţii care se verifică permanent
b) Restricţiile de integritate sunt reguli suplimentare, reprezentate direct în modelul
conceptual al datelor, dar care nu trebuie respectate permanent de date.
c) Restrictii de integritate dinamice sunt restricţii care privesc evoluţia în timp a
datelor.
a) Restricţiile de integritate structurale se referă la integritatea entităţilor, vizând
faptul că fiecare entitate trebuie identificată în mod unic;
b) Restricţiile de integritate semantice se referă la integritatea referenţială, vizând
faptul că pentru orice realizare a unei asocieri este obligatoriu să existe realizări pentru
entităţile participante;
c) Restricţiile de integritate structurale se referă la cardinalităţi, vizând respectarea
condiţiilor în cazul cardinalităţilor minimale şi maximale.
12
Se considera urmatorul fragment de model conceptual al datelor:
facturare
cantitate
PRODUS 1,n 1,1 FACTURA
CodProdus NrFactura
Denumire 1,n livrare 1,1 Data
cantitate
Faptul ca livrarea produselor este precedată de facturarea lor constituie :
50
b) o restrictie de integritate de incluziune intre asocieri ;
c) o restrictie de integritate de excluziune intre asocieri ;
e) o restrictie de integritate de domeniu.
13
Se consideră următorul fragment de Model Conceptual de Date:
PRODUS 0,n produs_facturat 1,n FACTURA

CodProdus cantitate NrFactura
Denumire pretVinzare DataFactura
Care din următoarele afirmaţii este adevărată ?

a) un produs se regăseşte pe cel puţin o factură .
b) fiecare factura contine câte un produs .
c) cantitate şi pretVinzare sunt atribute ce trebuie să apară la entitatea Produs .
14
Se consideră următorul fragment de Model Conceptual de Date:
PRODUS 0,n produs_facturat 1,n FACTURA

CodProdus cantitate NrFactura
Denumire pret_vinzare DataFactura
1,1
CLIENT 1,1
CodClient primeste corespunde
DenClient DOCINCAS
AdresaClientn NrDocIncas
1,n 1,1
FelDocIncas
t
plateste DataDocIncas
1,n 1,1 SumaIncas
Care este Modelului Logic al datelor corespunzător ?

a) Produs = (CodProdus, DenProdus, cantitate, pret_vinzare) ;
Factura = (NrFactura, DataFactura, CodClient, CodProdus, cantitate,
pret_vinzare) ;
Client = (CodClient, DenClient, AdresaClient, NrDocIncas) ;
DocIncas = ( NrDocIncas, FelDocIncas, DataDocIncas, SumaIncas, CodClient) ;
ProdusFacturat = ( CodProdus, NrFactura, cantitate, pret_vinzare).
b) Produs = (CodProdus, DenProdus) ;
51
Factura = (Nrfactura, DataFactura, CodClient) ;
Client = (CodClient, DenClient, AdresaClient) ;
DocIncas = ( NrDocIncas, FelDocIncas, DataDocIncas, SumaIncas, CodClient,
NrFactura) ;
ProdusFacturat = ( CodProdus, NrFactura, cantitate, pret_vinzare).
c) Produs = (CodProdus, DenProdus, pret_vinzare) ;
Factura = (Nrfactura, DataFactura, CodClient, NrDocIncas, FelDocIncas) ;
Client = (CodClient, DenClient, AdresaClient) ;
DocIncas = ( NrDocIncas, FelDocIncas, DataDocIncas, SumaIncas, NrFactura) ;
ProdusFacturat = ( CodProdus, NrFactura, cantitate).

15
Pentru proiectarea sistemului informatic privind vânzarea produselor se cunosc
următoarele:
.. produsele sunt identificate printr-un cod;
.. facturile sunt identificate prin număr şi dată;
.. pe o factură pot fi înregistrate mai multe produse; pentru fiecare produs se consemnează
cantitatea şi preţul de vânzare;
.. un produs se regăseşte pe mai multe facturi ;
.. unui client îi pot fi destinate una sau mai multe facturi.
Care din variantele următoare reprezintă Modelul Conceptual al Datelor ?
a)
PRODUS FACTURA
CodProdus
1,n produs_facturat 0,n NrFactura 1,1
DataFactura
Cantitate
Pret_vânzare
1,1
1,n
Clienţi 1,n
CodClient
destinata
DenClient
Adresã
52
b)
Produs Factura
CodProdus 1,n produs_facturat 1,n 1,1
NrFactura
Preţ_vânzare cantitate DataFactura
1,1
Clienţi
1,n
destinata
CodClient
DenClient
Adresã
c)
PRODUS produs_facturat Factura
CodProdus 1,n cantitate 1,n NrFactura
pret_vinzare DataFactura
1,1
Clienţi
1,n
destinata
CodClient
DenClient
Adresã
a) Prelucrările surprind parte dinamică, modificările în timp ale unui sistem
informatic.
b) Prelucrările traduc regulile de gestiune ale firmei.
c) Prelucrările sunt constituite dintr-o submulţime de activităţii independente de
structura organizatorică a firmei, care au puncte de intrare şi de ieşire stabile.
a) Modelul Organizaţional al Prelucrărilor permite descrierea activităţilor din
sistemul real prin descompunerea unui proces în operaţii.
b) Modelul Conceptual al Prelucrărilor permite descrierea activităţilor din sistemul
real prin descompunerea unui proces în operaţii.
c) Modelul Conceptual al Prelucrărilor permite reprezentarea înlănţuirii operaţiilor şi
precizarea condiţiilor declanşării acestora.
53
a) Evenimentul este o circumstanţă, un semnal adus la cunoştinţa sistemului şi la
care acesta trebuie să răspundă.
b) Un semnal că ceva s-a întâmplat în sistem este considrat eveniment chiar dacă el
nu este declanşatorul posibil al unei activităţi.
c) Evenimentele externe provin din interiorul sistemului studiat şi declanşează în
exteriorul lui executarea unor activităţi.
a) Evenimentele externe pot fi controlate, asupra lor putându-se interveni din
sistem.
b) Exemple de evenimente externe: modificarea cursului leului, modificarea
procentului de TVA, modificarea procentului în cazul impozitului pe salarii.
c) Exemple de evenimente externe: modificarea cursului leului, ordinul de plată
completat, modificarea procentului în cazul impozitului pe salarii.
a) Evenimentele intermediare survin la încheierea unei operaţii din cadrul
sistemului studiat şi se grupează în evenimente rezultat şi evenimente externe.
b) Evenimentele externe sunt rezultate din executarea unor operaţii şi sunt
destinate mediului extern.
c) Evenimentele externe declanşează operaţii în cadrul sistemului.
a) Exemplu de evenimente intermediare: întocmirea Notei de Receptie şi
Constatare de Diferenţe în urma recepţionării mărfurilor, factura întocmită remisă
clientului.
b) Evenimentele rezultat, reprezentate de ieşiri ale prelucrării în cadrul sistemului
informatic proiectat, sunt destinate mediului extern al sistemului.
c) Exemple de evenimente interne: ordinul de plată întocmit şi depus la bancă,
declaraţia de TVA întocmită şi depusă la organul fiscal, modificarea procentului de
TVA.
a) Operaţia reprezintă o secvenţă continuă de activităţi producătoare de
evenimente.
b) Operaţia constituie “un bloc de prelucrare”, o succesiune de activităţi
elementare care se execută neîntrerupt din momentul declanşării.
c) Operaţiile sunt declanşate în funcţie de respectarea unor anumite condiţii, numite
reguli de emisie.
a) Operaţiile conduc la producerea de evenimente intermediare sau externe, în
funcţie de respectarea unor anumite condiţii, numite reguli de emisie.
54
b) Operaţiile sunt declanşate de evenimente externe sau de evenimente intermediare
c) O operaţie declanşează în anumite condiţii evenimente numite evenimente
contributive.
a) Modelul Organizaţional al Prelucrărilor prezintă mulţimea operaţiilor luînd în
calcul structura organizatorică a firmei.
b) Postul de lucru este reprezentat de echipamentele de prelucrare automată a datelor
dintr-un compartiment funcţional.
c) În cadrul Modelului Organizaţional al Prelucrărilor descompunerea procedurilor
în faze se face luînd în consideraţi o anume soluţie informatică de implementare.
a) La ora actuală există un formalism unanim recunoscut pentru descrierea
prelucrărilor la nivel logic şi operaţional: Modelul Relaţional.
b) Fiecărei proceduri din Modelul Conceptual al Prelucrărilor îi corespund una sau
mai multe procese producătoare de rezultat în Modelul Organizaţional al Prelucrărilor.
c) Pentru fiecare operaţie din Modelul Conceptual al Prelucrărilor, în Modelul
Organizaţional al Prelucrărilor corespund una sau mai multe faze.
26 Se consideră următorul fragment din sistemul informatic pentru acordarea unui
credit.
Cerere credit
admisă
S3
O2
3 Deschid fişă credit
Deschiderea fişei de evidenţă operativă a creditului
DA NU
Fişă Termen Ordin

credit scadenţă de plată
S4
4 Operaţii legate de scadenţă

4
Urmărirea încasării ratei scadente
55
NU DA
Credit Fişa
restant actualizată
Care din urmatoarele afirmatii este adevărată ?

a) Evenimentul “Termen scadenţă “ este eveniment rezultat
b) Evenimentul “Termen scadenţă “ este eveniment extern
3.Chiar dacă operaţiile legate de scadenţă nu se pot efectua, fişa de credit este actualizată
27
În cadrul sistemului informatic privind acordarea unui credit, analiza dosarului
de credit este o operaţie declanşată de înregistrarea unei cereri de creditare şi a unei
documentaţii corespunzătoare. Analiza dosarului de credit presupune cuantificarea
riscului creditului. Dacă există un coeficient de risc ridicat, nu se acordă creditul şi
dosarul este respins.
Care din următoarele variante este secvenţa corectă a modelului conceptual al
prelucrărilor construit pentru secventa de activitate descrisa mai sus.
a)
Cerere
credit
2 Analiză dosar credit

Cuantificarea riscului creditului
Coef. de risc ridicat Credit posibil de acordat
Cerere Dosar Cerere credit

credit închis admisă
respinsã
56
b) Cerere
credit
S1

coef. de risc ridicat Credit posibil de acordat
Cerere Cerere credit

credit admisă
respinsã
c) Cerere
Documentaţie înregistrată
S1

coef. de risc ridicat Credit posibil de acordat
Cerere Dosar Cerere credit

credit închis admisă
respinsã
Rezolvare teste
1-b 2-a 3-a 4-c 5-c 6-b 7-c 8-a 9-a 10-b 11-b
12—b 13-a 14-b 15-c 16-c 17-a 18-a 19-b 20-c 21-b 22-c
23-b 24-a 25-c 26-b 27-c
57
METODE ORIENTATE OBIECT
OBIECTIVE:
- prezintă, explică şi exemplifică principiile metodologice, procedeele tehnologice

şi instrumentele caracteristice unei clase de metode de proiectare a sistemelor
informatice de gestiune (OMT) ;
- discutarea unor exemple de rezolvare a problemelor de gestiune în modelarea şi
proiectarea sistemelor informatice.
Cuvinte cheie: clase şi obiecte, UML, diagrame UML, model orientat obiect
CONŢINUT:
3. METODE ORIENTATE OBIECT
3.1 Metodologia orientată obiect
3.2 Modelul obiect
3.3 UML – limbaj standard de modelare
3.4 Diagrame UML
3.5 Modelul sistemului real şi diagramele UML
3. METODE ORIENTATE OBIECT
3.1 Metodologia orientată obiect
Dezvoltarea sistemelor orientate obiect cuprinde întregul ciclul de viaţă al

sistemului, împărţit în trei faze: analiză, proiectare, implementare. În aceste faze se
întâlnesc, în planuri conceptuale diferite, elemente orientate obiect, notaţii din domeniul
aplicaţiei şi al computerelor.
Metodologia orientată obiect presupune construirea unui model al unui domeniu
de aplicaţie şi adăugarea detaliilor de implementare în timpul proiectării. În faza de
analiză se construieşte un model pentru abstractizarea aspectelor esenţiale din domeniul
aplicaţiei. Modelul nu cuprinde detalii de implementare. Pentru a descrie şi optimiza
implementarea, acestea sunt adăugate în etapa de proiectare.
analiza
În faza de analiză, metodologia orientată obiect cere construirea unui model
precis, concis şi inteligibil al lumii reale, construirea unui model complet al aplicaţiei.
Analistul descrie ce trebuie să facă sistemul şi nu cum o face, urmăreşte definirea a ceea
ce urmează să realizeze, şi nu a algoritmilor care vor fi folosiţi. Obiectele sunt concepte
58
din domeniul aplicaţiei, şi nu din domeniul programării. Atenţia este îndreptată asupra
conceptelor care vor forma nucleul unei soluţii ce utilizează tehnici orientate obiect.
Analiza este selectivă, neacordându-se aceeaşi importanţă tuturor componentelor
şi însuşirilor. Lumea reală se descompune în entităţi distincte, se stabilesc legăturile
dintre ele şi funcţiile îndeplinite. Sunt examinate cerinţele, analizate implicaţiile, reţinute
doar aspectele esenţiale. Rezultatul este un model cu clase şi asocieri eficient prezentate,
folosirea acestora făcându-se în partea de proiectare şi implementare.
proiectarea
Scopul principal al proiectării orientate obiect este să maximizeze posibilitatea
reutilizării claselor în proiecte ulterioare, să identifice în relaţiile de moştenire
superclasele care facilitează reutilizarea în cadrul aceluiaşi proiect.
În “Object-Oriented Modeling and Design” ([R*96]), autorii consideră că
proiectarea se efectuează în două etape: proiectarea sistemului şi proiectarea obiectelor.
Proiectarea sistemului implică împărţirea sa în subsisteme, şi alocarea resurselor
hardware şi software.
Proiectarea obiectelor continuă strategia aleasă în etapa de proiectare a sistemului
şi rafinează detaliile.
Se păstrează structura claselor stabilită în partea de analiză, luând în consideraţie
minimizarea timpului de execuţie şi folosirea raţională a memoriei.
Operaţiile identificate în etapa de analiză sunt exprimate algoritmic, cele
complexe sunt descompuse în operaţii interne simple. Atributele şi asocierile sunt
prezentate într-o formă ce permite ulterior implementare ca structuri de date specifice.
Clasele sunt rearanjate prin evidenţierea unor relaţii de agregare sau de
generalizare, sunt completate cu noi operaţii şi noi atribute, rezultate din abstractizarea
comportamentului comun.
Modelul claselor poate fi rafinat prin introducerea de noi clase, care păstrează
rezultate intermediare de calcul.
Considerând clasele ca nişte ,,cutii negre” a căror interfaţă externă este publică,
dar ale căror detalii interne sunt ascunse, proiectantul decide atributele care sunt vizibile
din exterior. Ascunderea informaţiei interne permite ca implementarea unei clase să fie
modificată, fără a cere clienţilor clasei să-şi modifice codul. Este necesară o nouă
documentare a claselor, pe baza celei din partea de analiză, care să conţină şi modificările
care au apărut în faza de proiectare.
Într-o ultimă fază a proiectării, clasele şi asocierile se regrupează în module.
59
implementarea
În timp ce primele două etape sunt independente de mediul de programare, în
această etapă trebuie aleasă soluţia informatică pentru realizarea efectivă a sistemului.
Clasele şi relaţiile sunt translatate într-un limbaj de programare, de regulă orientat obiect.
În cele mai multe cazuri, scrierea secvenţelor de cod într-un limbaj orientat obiect se face
aproape automat, pe baza deciziilor luate în fazele anterioare.
Spre deosebire de limbajele procedurale pentru care un program cuprindea o serie
de proceduri care se apelau reciproc, procedura reprezentând unitatea de calcul ce
transmite valori pentru date sau actualizează parametrii de intrare, pentru limbajele
orintate obiect există obiecte capabile să trimită mesaje de la unul la celălalt, să proceseze
cereri recunoscute ca mesaje, să răspundă unei colecţii predefinite de mesaje care
formează interfaţa obiectului. Noţiunea de mesaj este o abstracţie, care poate fi
implementată ca apel de procedură, eveniment discret, întrerupere.
Caracteristicile esenţiale ale limbajelor de programare orientate obiect au fost
definite în anii ‘70-’80 de şcoala Smalltalk şi apoi de limbajul C ++. În acelaşi timp,
noţiunea de entitate din modelele semantice a fost preluată în modelele orientate obiect,
punând însă accentul pe comportamentul datelor, încapsulând în conceptul de obiect atât
datele, cât şi operaţiile posibile asupra lor.
Primele limbaje orientate obiect au fost limbajele folosite pentru rezolvarea
problemelor de simulare şi au definit noţiunea de clasă, ce regrupează o structură de date
şi procedurile necesare pentru manipularea ei. Rând pe rând au fost reluate şi amplificate
tendinţele de uniformizare ale mediului de programare, unde totul se reduce la obiect, au
apărut limbaje care oferă funcţionalităţi ale programării orientate obiect, conservând
structurile de control clasice ale limbajelor imperative.
Obţinând o însumare a avantajelor sistemelor de gestiune a bazelor de date, care
interoghează eficient datele, şi a limbajelor procedurale care permit calcule complexe,
programarea orientată obiect permite abordarea naturală a lumii reale, folosind
componente modularizate şi eliminând restricţiile impuse de mediul de programare.
3.2 Modelul obiect
Modelul obiect s-a dezvoltat pe baza principiilor preluate din programarea

orientată obiect încă de la sfârşitul anilor ‘60. Implicarea unor date complexe (documente
electronice, date în format multimedia), necesitatea definirii unor tipuri de date-utilizator
şi reutilizarea componentelor existente, sunt doar câteva din realităţile care au impus în
proiectarea sistemelor informatice modelele obiect. Elementul central al modelului îl
constituie obiectul.
60
3.2.1 Obiecte
Un obiect este o abstracţie, un concept, folosit pentru reprezentarea lumii reale şi

furnizarea unei baze practice pentru implementarea cu ajutorul tehnicii de calcul.
Descompunerea sistemului real în obiecte depinde de modelator şi de natura concretă a
problemei.
Exemple:
persoana IONESCU, produsul CALCULATOR, factura AS-1234 din 12/03/04 sunt
obiecte din lumea reală, ce se regăsesc în sistemul informatic privind personalul angajat,
gestiunii resurselor şi respectiv vânzării de produse.
Caracteristicile unui obiect sunt: identitate, stare, comportament. Şi astfel,
modelul orientat obiect este o reprezentare directă a realităţii cu ajutorul unor
componente elementare cu identitate proprie şi caracterizate prin stare şi comportament.
Identitatea unui obiect este acea proprietate a obiectului care îl distinge de alte
obiecte. Obiectul este definit de un identificator intern unic, independent de valoarea sau
de adresa de memorie a obiectului. Identificatorul nu este controlat direct de programator
şi nu se confundă cu diferitele nume utilizate de programator pentru a-l numi.
Identitatea organizează obiectele într-un spaţiu manipulat de limbajele orientate
obiect. Spaţiul obiectelor se construieşte pornind de la obiecte de bază. Ca entităţi
complexe, obiectele sunt constituite din alte obiecte şi/sau din valori. Ele sunt create de
utilizatori, prin derivare din tipuri de obiecte create anterior, sau printr-o operaţie
explicită de creare.
Starea este o abstracţie a valorilor atributelor şi a legăturilor unui obiect. Starea
obiectului reprezintă mulţimea valorilor tuturor atributelor şi legăturilor sale la un
moment dat. Starea este adesea asociată cu valoarea unui obiect satisfăcând anumite
condiţii.
Exemple:
▪ persoana IONESCU aparţinând unui sistem informatic de evidenţă a personalului poate
fi în starea angajat cu carte de muncă sau pensionar, în funcţie de valorile atributului
vârstă. Prin raportare la o firmă, poate fi în starea angajat sau şomer.
▪ factura AS-1234 din 12/03/04 poate fi în starea achitată sau neachitată, stare
determinată de factori externi, reprezentaţi prin încasarea sau nu a contravalorii sale.
Comportamentul este determinat de ansamblul operaţiilor pe care obiectul le poate
executa. Exprimă modul în care un obiect acţionează şi reacţionează.
Exemple:
▪ pentru persoana IONESCU, operaţia afişează permite calcularea şi afişarea pe ecran
valorii atributului vechime în muncă. Prin operaţia valoare, se pot calcula reţinerile din
salariu sau sporurile.
61
▪ pentru factura AS-1234 din 12/03/04, cu ajutorul operaţiilor definite se pot afişa datele
de identificare ale furnizorului sau se poate calcula valoarea totală în funcţie de articolele
facturate şi de cota tva.
Comportamentul este cel care alterează starea unui obiect, determină schimbarea stării
sale. Corespunzătoare comportamentului global al obiectului, mulţimea valorilor grupate
într-o stare, specifică răspunsul obiectului la evenimentul primit.
3.2.2 Instrumente ale modelului orientat obiect
Pornind de la componentele elementare (obiecte), modelul obiect al sistemului

real se obţine folosind instrumente specifice tehnicilor orientate obiect. Acestea sunt:
abstractizarea, încapsularea şi ierarhizarea.
3.2.2.1 Abstractizare
Abstractizarea este o operaţie a gândirii prin care se desprind şi se reţin caracteristicile şi

relaţiile esenţiale ale obiectului cercetat [DEX]. În cazul sistemelor reale complexe, prin
abstractizare se poate ajunge la modele inteligibile, uşor de studiat, ce permit simularea
desfăşurării activităţii folosind tehnica de calcul electronică. Caracteristicile selectate
diferă în funcţie de scopul urmărit. Pot astfel exista mai multe abstractizări pentru acelaşi
sistem real.
În cazul tehnicilor orientate obiect, prin abstractizare se evidenţiază caracteristicile
esenţiale ale unui obiect, cele care-l disting de alte obiecte. Practic, problema se
abstractizează prin gruparea obiectele în clase. Abstractizarea dă putere modelării şi
capacitate de generalizare de la câteva cazuri particulare la cazuri similare. Definiţiile
comune (numele atributelor) sunt memorate o singură dată pentru clasă, în loc să fie
memorate pentru fiecare instanţă. Operaţiile pot fi scrise o singură dată şi toate obiectele
beneficiază de codul reutilizat.
clase şi obiecte
O clasă de obiecte descrie o mulţime de obiecte cu aceleaşi proprietăţi (atribute),
acelaşi comportament (operaţii) şi relaţii similare faţă de alte obiecte. Fiecare obiect se
mai numeşte instanţă a clasei. În termeni implementaţionali, fiecare obiect conţine un
pointer la clasa din care provine, deci are acces la toate caracteristicile clasei sale.
Clasa serveşte la definirea şi manipularea mulţimii instanţelor, similar relaţiilor
din bazele de date relaţionale, şi aminteşte noţiunea de clasă de la modelele semantice,
care descrie însă doar structura, nu şi comportamentul instanţelor.
Spre deosebire de bazele de date relaţionale, în cazul modelării orientate obiect nu
există o teorie matematică ce asigură un set standard de operatori. Aceştia sunt
reprezentaţi de operaţiile definite la nivelul claselor, şi pot fi grupaţi în patru categorii:
constructori, destructori, modificatori şi selectori.
O clasă este definită prin:
• numele clasei
62
• atributele, expresie a valorilor diferitelor stări ale instanţelor de clasă
• operaţiile pentru manipularea instanţelor de clase, numite metode. Specificarea
metodei poartă numele de semnătură, iar codul care implementează operaţiile constituie
corpul metodei.
Noţiunea de clasă este mai mult utilizată de faza de execuţie, presupunând două
aspecte: generarea de obiecte şi stocarea setului de obiecte care reprezintă instanţele
claselor. Cu ajutorul clasei se descriu obiectele. Obiectul posedă propriile lui valori, lista
atributelor şi metodele fiind gestionate de clasă.
3.2.2.2 Încapsulare
Încapsularea este un proces de grupare a elementelor unei clase în elemente

accesibile din exterior şi elemente proprii. Permite separarea aspectului extern, accesibil
altor obiecte, de implementarea internă. Oferă posibilitatea de a masca atributele proprii
ale unui obiect, precum şi modul în care se execută operaţiile. Implementarea poate fi
astfel schimbată fără a afecta aplicaţia.
Fiecărei clase îi este asociată o mulţime de operaţii, care constituie interfaţa cu
utilizatorul, şi prin care obiectele acesteia pot fi manipulate. Corespunzător, obiectul este
divizat în două: conţinut şi interfaţă. Conţinutul, dat de structura şi modul de acţiune al
operaţiilor este cunoscut numai de obiectul însuşi, neputând fi accesibil din afară.
Interfaţa, mulţime a atributelor şi operaţiilor vizibile din exterior, permite schimbul de
mesaje între obiecte, asigură funcţionalitatea modelului.
În “Conception orientee objets et application” [BG94], autorul defineşte
încapsularea ca fiind procesul de compartimentare a elementelor unei abstracţii, afirmând
chiar că “prin încapsulare se separă interfaţa contractuală a unei abstracţii de
implementarea sa”.
În timp ce interfaţa priveşte numai aspectul extern, abstractizare a
comportamentului comun al tuturor instanţelor clasei, implementarea priveşte
reprezentarea abstracţiei şi mecanismul ce realizează comportamentul dorit, detaliile pe
care utilizatorul nu trebuie să le cunoască.
Separarea între conţinut şi interfaţă permite claselor să ascundă detaliile de
realizare. Datele încapsulate sunt protejate de accese nedorite, garantându-se astfel
integritatea lor. Un obiect poate evolua în timp fără a afecta restul sistemului.
Încapsularea constituie astfel una din premisele de bază ale reutilizării.
Abordând construirea modelului din diferite puncte de vedere, Grady Booch
afirmă că abstractizarea şi încapsularea sunt complementare, prima concentrându-se
asupra aspectului extern, cealaltă împiedicând să se vadă interiorul, acolo unde
comportamentul abstractizării este implementat. Abstractizare evidenţiază caracteristicile
esenţiale ale unui obiect, încapsularea serveşte la separarea comportamentului esenţial al
63
unui obiect de implementarea sa. Abstractizarea pune bariere explicite între diferite
abstracţii, încapsularea ascunde toate detaliile unui obiect care nu participă la stabilirea
legăturilor cu alte obiecte.
3.2.2.3 Ierarhizare
Ierarhizarea este o operaţia de ordonare a abstracţiilor. Ajută la identificarea

relaţiilor într-o ierarhie, la clarificarea şi buna înţelegere a problemei.
Agregarea este o relaţie de tip parte-întreg, în care obiecte care reprezintă
componente ale unui întreg, sunt asociate cu întregul.
Agregarea este o formă de asociere în care există un obiect agregat, format din
componentele sale, componentele fiind văzute ca parte a agregatului. O aceeaşi parte
poate aparţine mai multor agregări. Semantic agregatul este văzut ca un obiect, tratat ca o
unitate în multe operaţii, deşi fizic este format din mai multe obiecte.
Agregarea nu este un concept independent, ci o formă specială de asociere.
Adaugă conotaţii semantice unor anumite cazuri particulare:
. Dacă două obiecte sunt legate prin relaţia parte-întreg, avem agregare.
. Dacă obiectele sunt independente, avem asociere.
Generalizarea este o relaţie dintre o clasă de bază şi una sau mai multe clase
derivate ale ei. Atributele şi operaţiile comune sunt grupate în superclasă, fiind moştenite
de clase.
În timp ce în cazul agregării una din clase are un rol predominant în raport cu
celelalte, în cazul generalizării clasele sunt integral coerente, subclasa aducând eventuale
informaţii adiţionale, specifice.
Agregarea implică două clase, una fiind parte a celeilalte. Generalizarea este un
mijloc de structurare a descrierilor pentru o clasă. Superclasa şi clasa specifică
proprietăţile unui obiect, obiectul fiind instanţă a superclasei şi instanţă a clasei.
Amândouă dau naştere la arbori prin tranzitivitate. Un arbore al agregării este
compus din instanţe obiect, toate parte al unui obiect compus. Arborele generalizării este
compus din clase care descriu un obiect.
Privite amândouă drept cazuri speciale de asocieri, agregarea este numită “şi-
relaţie”, iar generalizarea este numită “sau-relaţie”.
moştenire
Partajarea atributelor şi operaţiilor de-a lungul unei ierarhii între clase şi subclase
este evidenţiată cu ajutorul conceptului de moştenire.
Moştenirea permite constituirea de noi tipuri de obiecte şi clase, evitând
rescrierea şi recodificarea. Noua clasă poate moşteni atât operaţii (metode), cât şi
64
variabile de instanţă (atribute). În primul caz se poate vorbi de partajarea codului între
metode (code sharing), iar în al doilea caz, de partajarea structurii între atribute
(structure sharing). Împreună furnizează o puternică strategie de modelare, un mecanism
natural de organizare a informaţiei, care prezintă clasele într-un graf de moştenire ce
permite vizualizarea legăturilor dintre ele.
Conceperea unei aplicaţii constă în a grupa informaţiile generale în clase care sunt
apoi specializate din aproape în aproape în subclase cu comportament particular. În faza
de implementare, subclasa este autorizată să redefinească implementarea.
Exemplu:
în sistemul informatic privind contractarea şi vânzarea produselor, documentele pe cere
se consemnează activităţile desfăşurate sunt contractul şi factura de vânzare. Prin
generalizare se poate defini o clasă DOCUMENT, care are drept atribute
NumărDocument şi DatăDocument. Operaţiile sunt: CautăDată(NrDoc) şi
StergeDocument(NrDoc). Clasele CONTRACT şi FACTURĂ moştenesc atributele şi
operaţiile clasei DOCUMENT. În plus, clasa CONTRACT are atributele TermenContract
şi ValoareContract, iar clasa FACTURĂ are în plus atributul StareFactură.
DOCUMENT
NumărDocument
DatăDocument
CautăDată(NrDoc)
ŞtergeDocument(NrDoc)
CONTRACT FACTURĂ
TermenContract StareFactură
Valoarecontract
Moştenirea între clase poate fi privită sub două aspecte:

•• structural, când o clasă are atribute moştenite de la superclasă. Instanţele unei clase
trebuie să reţină acelaşi tip de informaţie ca instanţele de la supraclasa sa. Metodele din
clasă pot manipula variabilele de instanţă (atributele) din superclasă fără restricţii.
În cazul în care o clasă are mai multe superclase, atributele unei clase sunt
reuniunea atributelor superclaselor sale, plus cele specifice ei.
•• comportamental, când o clasă are metode moştenite de la superclasă.
Comportamentul este specificat în metodele superclasei şi în metodele specifice ei..
65
Metodele sunt operaţii care pot regăsi sau actualiza starea unui obiect. Sunt parte a
interfeţei ce manipulează instanţele clasei.
Similar cu aspectul structural, în cazul existenţei mai multor superclase, colecţia
de metode aplicabile instanţelor unei clase este reuniunea metodelor definite în
superclase, plus cele specifice ei.
Moştenirea poate fi implementată static sau dinamic. Moştenirea statică
presupune adăugarea câmpurilor moştenite. În timp ce execuţia este rapidă neimplicând
parcurgerea legăturilor de moştenire, redefinirea unei clase este dificilă, implicând
actualizarea tuturor subclaselor. Moştenirea dinamică se realizează fără copierea
câmpurilor moştenite, şi presupune parcurgerea legăturilor de moştenire. Actualizarea
este mai uşoară, dar execuţia este mai puţin eficientă.
Generalizarea şi moştenirea sunt abstracţii puternice folosite pentru transmiterea
similarităţilor de la o clasă la alta, păstrând totuşi diferenţele dintre acestea. Sunt
tranzitive, traversând un număr arbitrar de nivele. Subclasele moştenesc trăsăturile
superclasei, dar pot avea propriile lor atribute şi operaţii.
În timp ce generalizarea se referă la relaţia dintre aceeaşi clasă şi subclasele
sale, moştenirea se referă la mecanismul de a transmite atribute şi operaţii de-a lungul
unei relaţii de generalizare. În implementare, moştenirea este sinonimă cu noţiunea de
reutilizare a codului. Trăsăturile reutilizabile sunt grupate în superclase. Fiecare
programator încearcă gruparea claselor cu trăsături comune şi folosirea secvenţelor de
cod comune, implementând subclase proprii specifice aplicaţiei.
polimorfism
În strânsă legătură cu moştenirea, polimorfismul defineşte caracteristica unei
operaţii de a se comporta în mod diferit în funcţie de clasa de obiecte căreia îi aparţine.
Polimorfismul permite invocarea pentru obiecte de diferite tipuri a operaţiilor cu acelaşi
nume (semnătură), dar semantică şi implementare diferită. La primirea mesajului,
stabilirea metodei care se aplică se face în mod dinamic, în funcţie de clasa obiectului în
cauză. Instanţe ale unor clase diferite pot fi adresate uniform, primind aceleaşi mesaje,
dar manifestă comportamente diferite.
3.3 UML – limbaj standard de modelare
3.3.1 Descrierea limbajului
Unified Modeling Language (UML) este succesorul unui val de metode de analiză
şi proiectare orientate obiect, apărute la sfârşitul anilor 80 şi începutul anilor 90. Este un
limbaj unificat de modelare, rezultatul unui proces de introducere a standardizării în
66
analiza şi proiectarea orientate obiect. Este punctul de pornire în dezvoltarea viitoarelor
limbaje grafice.
Contribuţii esenţiale în definirea limbajului unificat de modelare au avut Grady
Booch, Jim Rumbaugh şi Ivar Jacobson.
Grady Booch, cercetător ştiintific la Rational Software Corporation a construit
numeroase exemple pentru dezvoltarea sistemului Ada. A definit o metodă de analiză şi
proiectare a sistemelor orientate obiect Object Oriented Design (OOD).
Jim Rumbaugh a condus o echipă de cercetare în laboratorul General Electric,
punând bazele metodei Object Modeling Technique (OMT).
Ivar Jacobson, în urma experienţei dobândite în domeniul telefoniei, a introdus
pentru prima dată diagramele de utilizare, în lucrarea “Object-Oriented Software
Engineerig - A Use Case Driven Approach”.
Metodele existente în acea perioadă erau similare, dar conceptele de bază apăreau
cu mici diferenţe de notaţii ce dădeau naştere la confuzii între utilizatori.
La OOPSLA’95 Grady Booch şi Jim Rumbaugh au prezentat public versiunea 0.8
a documentaţiei pentru o metodă standard de modelare, Unified Method (UM). Metoda
consta într-un limbaj de modelare şi un proces. Limbajul de modelare era (în special cel
grafic) notaţia folosită de metodă. Procesul exprima paşii făcuţi.
Studiul acestei metode i-au determinat să considere că partea de proces a metodei
este nesemnificativă, că nu e nevoie şi de un proces standard, deşi armonizări în
vocabular sunt necesare. În acelaşi timp, au considerat că un limbaj de modelare standard
este necesar şi important. Şi astfel, începând cu 1966, cei doi împreună cu Ivar Jacobson,
au lucrat pentru un limbaj de modelare standard, Unified Modeling Language (UML).
La 17 noiembrie 1997, Object Management Group (OMG) a anunţat adoptarea
specificaţiei UML ca limbaj standard de modelare.
Afirmând că “UML este experienţă, experiment şi adoptare gradată a standardului
care dezvăluie adevăratul potenţial al sistemului şi permite realizarea beneficiilor”, au
definit UML ca “un limbaj de modelare pentru a specifica, vizualiza, construi şi
documenta componentele unui sistem dinamic, în care o metodă este aplicată ca un
proces pentru a defini şi dezvolta sistemul”. Mai mult, au demonstrat că UML:
• este limbaj folosit pentru comunicare, mijloc de a prezenta cunoştinţe (semantică)
despre sistemul studiat şi de a exprima cunoştinţele (sintactic) privind sistemul studiat în
scopul comunicării.
• este limbaj de modelare ce accentuează înţelegerea sistemului prin definirea unui model
al său şi al contextului în care se dezvoltă.
• îmbină teoria sistemele informatice şi practica domeniilor de activitate concrete;
specifică cerinţele sistemului şi modul în care pot fi ele realizate.
• aplicat în prezentare, poate fi folosit pentru vizualizarea sistemului înainte de a fi
realizat.
67
• aplicat în construirea sistemului, poate fi folosit ca ghid în realizarea unui sistem similar
modelului.
• aplicat în documentarea sistemului poate fi folosit pentru includerea cunoştinţelor
despre sistem în timpul ciclului de viaţă.
Pentru a demonstra că UML nu priveşte doar sistemele orientate obiect, putând fi
aplicat sistemelor în general, în “The Visual Modeling of Software Architecture for the
Enterprise”[BG99], Grady Booch a arătat că modelarea este partea centrală a activităţii
care conduce la proiectarea eficientă a oricărui sistem informatic. Indiferent de domeniu,
pentru rezolvarea problemelor din sistemele reale se construiesc modele pentru o mai
bună înţelegere a sistemului, pentru vizualizarea şi controlul arhitecturii sistemului.
Vizualizarea, specificarea, construirea şi documentarea permit ca el să fie văzut din
diferite perspective. Analiza, dezvoltarea, interogările şi testele referă sistemul în diferite
etape. UML ajută programatorii să înglobeze deciziile semnificative luate la nivel de
sistem şi proiectanţii să controleze dezvoltarea iterativă a sistemului în ciclul său de viaţă.
3.3.2 Definirea limbajului
Pentru definirea limbajului sunt folosite trei documente: UML Semantics, UML
Notation Guide şi UML Extetions.
a) UML Semantics este un model logic, cuprinzând semantica declarativă fără
detaliile de implementare, este documentul principal care descrie limbajul în trei
secţiuni:
• Sintaxa abstractă (Abstract syntax), în care diagramele claselor UML sunt folosite
pentru a defini metamodelul UML, conceptele sale (metaclase), relaţiile şi restricţiile.
Sunt incluse şi definiţiile conceptelor. Metamodelul, modelul elementelor modelate, este
prezentat ca un limbaj pentru specificarea modelului obiect. Scopul metamodelului UML
este să furnizeze un singur, comun şi definitiv sens al sintacticii şi semanticii elementelor
UML.
• Regulile de corectitudine (Well-formedness rules), în care sunt definite regulile şi
restricţiile modelului. Object Constraint Language (OCL) este un limbaj specific care
foloseşte logica simplă pentru specificarea proprietăţilor invariante ale sistemului şi
relaţiile. Este prima contribuţie IBM la UML, dezvoltată în cadrul limbajului de modelare
pentru sistemele informatice din mediile de afaceri. Furnizează facilităţi pentru
formalizarea semanticii limbajului, pentru exprimarea structurii modelului şi a
restricţiilor.
• Semantica (Semantics), în care semnificaţia modelului şi cerinţele suplimentare, non-
funcţionale, sunt specificate ca cerinţe textuale.
În descrierea semanticii sunt folosite tehnici formale, definiţiile sunt prezentate
riguros matematic şi fără ambiguităţi, folosind elemente de calculul predicatelor. Totuşi
68
valoarea acestor definiţii nu are înţeles universal. Chiar dacă se pot demonstra
specificaţiile matematice, nu există căi de a proba aceste specificaţii în contact cu
cerinţele reale din sistem.
b) Notaţia este partea grafică văzută în model, este sintaxa limbajului de modelare.
Notaţia din diagrama claselor defineşte modul în care sunt reprezentate conceptele de
clasă, asociere şi multiplicitate.
UML Notation Guide este un document utilizat practic în toate metodele de
analiză şi proiectare. Este structurat în conformitate cu documentele principale
(diagramele) ce pot fi construite în procesul de aplicare a metodei. UML Notation Guide
descrie notaţiile UML şi furnizează exemple. Face sumarul semanticii UML, definiţiile
fiind însă în UML Semantics. Este o reprezentare la nivelul modelului utilizatorului, care
e semantic o instanţă a metamodelului UML.
c) UML Extensions cuprinde definirea extensiilor UML care sunt posibile prin
folosirea stereotipurilor (Stereotypes), valorilor etichetate (Tagged values) şi restricţiilor
(Constraints). Sunt definite două extensii: UML Extension for the Objectory Process for
Software Engineeering şi UML Extension for Business Modeling.
Se apelează la extensii doar când este necesară introducerea de noi notaţii şi
terminologii. Extensiile nu sunt universal acceptate, înţelese şi suportate. Chiar fără
extensii, UML este complet aplicabil pentru multe tipuri de sisteme, domenii, metode sau
procese. Defineşte un set de concepte pentru dobândirea, partajarea şi utilizarea
cunoştinţelor împreună cu mecanismele de extensibilitate.
Ca limbaj de modelare standardizat este deschis la extensibilitate pe scară largă,
permite îmbunătăţirea tacticii şi strategiei pentru creşterea valorii prin calitate şi reducere
de cost. Permite practicienilor creşterea eficienţei având consistenţă, standardizare şi
instrumente suportate de limbaj de modelare.
3.4 Diagrame UML
Diagramele UML sunt mijloacele de reprezentare şi vizualizare a elementelor de

modelare. În acest subcapitol diagramele UML sunt construite cu OBJECTEERING,
aflat pe Internet la adresa www.objecteering.com.
In funcţie de rolul lor în specificarea aplicaţiilor, diagramele UML se pot clasifica în:
Dinamice (comportament)
Statice (structură)
Diagrame de cazuri de utilizare Diagrame de colaborare
Diagrame de clase Diagrame de secvenţe
Diagrame de obiecte Diagrame de stare/tranziţie
Diagrame de componente Diagrame de activităţi
Diagrame de implementare
69
3.4.1 Diagrama cazurilor de utilizare
Funcţionalitatea completă a sistemului este dată de diagrama cazurilor de

utilizare, care include actorii şi cazurile de utilizare. Fiecare diagramă conţine un set
complet de evenimente iniţiate de unul sau mai mulţi actori şi specifică interacţiunea care
are loc între actori şi sistem.
Cazurilor de utilizare descriu comportamentul unui sistem din punctul de vedere
al utilizatorului, care poate astfel să-şi structureze cerinţele, să definească modul în care
va interacţiona cu sistemul pentru a obţine rezultatul dorit. Precizează limitele sistemului,
relaţiile dintre sistem şi mediu, ceea ce face parte din sistemul de dezvoltat şi ceea ce nu
face parte din el.
Pentru descrierea unui caz de utilizare, trebuie prezentate variantele de
execuţie posibile pentru secvenţa de acţiuni corespunzătoare acestui caz, aşa zisele
scenarii.
Un scenariu este deci o instanţă a unui caz de utilizare, un flux de evenimente.
Un scenariu este creat de fiecare dată când un actor declanşează un caz de
utilizare : acest scenariu va urma un drum particular în descrierea unui caz de utilizare.
Un scenariu nu conţine ramuri de tipul « dacă condiţia X este îndeplinită, atunci
… », pentru că în timpul execuţiei condiţia este sau adevărată sau falsă, dar întotdeauna
va avea o valoare.
Nu este posibil să descriem un caz de utilizare scriind toate scenariile ; se descriu
cele reprezentative şi mai ales cele care comportă un risc.
In practica modelării există două nivele de descriere :
1. Descrierea generală a unui caz de utilizare evidenţiind diferite drumuri ce pot fi
reunite în acelaşi caz
2. Descrierea celor mai semnificative scenarii
Ca abstracţii ale dialogului între actori şi sistem, cazurile de utilizare descriu
interacţiuni potenţiale fără a intra în detaliile fiecărui scenariu. Specifică doar cine
declanşează evenimentele şi ce acţiuni determină, fără a cuprinde detalii funcţionale. Un
caz de utilizare este iniţiat întotdeauna de un actor şi exprimă o funcţie a sistemului,
declanşată ca răspuns.
Actorii sunt elementele din sistem care generează sau primesc evenimente. Se
determină dintre utilizatorii direcţi ai sistemului, dintre cei care-l interoghează sau
exploatează. Alături de utilizatori, pot fi actori alte sisteme sau chiar un eveniment.
70
Reprezentare:
Actor participare caz de utilizare
Livrare marfă
Furnizor
Aceeaşi persoană poate juca rolul mai multor actori, iniţiind mai multe cazuri de
utilizare.
Exemplu:
gestionarul unui depozit recepţionează marfa şi o înregistrează în fişa de magazie:
Receptionează
marfa
Gestionar
Inregistrează
marfa
Un caz de utilizare poate avea mai mulţi actori, fiecare cu rolul său.
Exemplu: la încheierea unui contract pentru livrarea mărfurilor participă clientul
şi inginerul de vânzări.
Client Inginer de vânzări
Incheiere
contract
UML recunoaşte patru categorii de actori:

• actori principali, persoane care utilizează funcţiile principale ale sistemului;
• actori secundari, persoane care efectuează sarcini administrative sau de
întreţinere;
• echipamente externe, echipamentele care fac parte din domeniul aplicaţiei şi
care trebuie să fie utilizate;
• celelalte sisteme, categorie care grupează sistemele cu care viitorul sistem
trebuie să interacţioneze.
După definirea actorilor şi a cazurilor de utilizare este utilă restructurarea
mulţimii cazurilor de utilizare prin evidenţierea comportamentului partajat, a cazurile
particulare şi a relaţiei de generalizare.
UML defineşte trei tipuri de relaţii între actori şi cazurile de utilizare:
•• Relaţia de comunicare: actorul participă direct la cazul de utilizare;
71
Exemple: clientul achită, funcţionarul comercial recepţionează marfa
•• Relaţia de incluziune: o instanţă a cazului de utilizare sursă include şi
comportamentul descris de un alt caz de utilizare. Acest tip de relaţie se foloseşte pentru
simplificarea diagramei cazurilor de utilizare în situaţii complexe.
Exemple: în diagrama cazurilor de utilizare corespunzătoare aprovizionării cu
mărfuri (fig 2.1),
cazul de utilizare – Incheie contract - include şi cazul de utilizare
- Semneaza contract –
cazul de utilizare – Livrare marfa - include şi cazul de utilizare
– Receptioneaza marfa –
cazul de utilizare – Intocmeste Nir- este inclus în cazul de utilizare
– Receptioneaza marfa –
cazul de utilizare –Încheiere contract- definit în sistemul informatic privind
aprovizionarea cu mărfuri include şi cazul de utilizare
-Semnare contract- din acelaşi sistem informatic.
•• Relaţia de extensie: cazul de utilizare sursă poate fi extins cu comportamentul
unui alt caz de utilizare destinaţie. Prin relaţia de extensie, care specifică o posibilitate, o
opţiune, poate fi introdus, sub forma unui caz de utilizare distinct, un nou caz de utilizare.
Exemplu: în diagrama cazurilor de utilizare corespunzătoare aprovizionării cu
mărfuri (fig 2.1 ), cazul de utilizare – Receptioneaza marfa –poate fi extins cu cazul de
utilizare – Returneaza marfa-
Descrierea unui caz de utilizare constă în unul sau mai multe “scenarii”, numite instanţe
ale cazului de utilizare.
Aprovizionare
Incheie contract
<<include>>
Semneaza contract
Furnizor
Livreaza marfa
<<include>>
Recep tioneaza marfa
<<extend>>
<<include>> Returneaza marfqa
Gestionar Intocmeste NIR
Fig 3.1
72
În majoritatea lucrărilor din literatura de specialitate, autorii propun ca descrierea
cazurilor de utilizare să cuprindă:
▪ denumire sau titlu
▪ scop
▪ actori
▪ punct iniţial
▪ punct final
▪ descriere derulare
▪ rezultat măsurabil
Exemplu:
Considerăm cazul de utilizare Analiza documentaţiei depuse din activitatea de
acordare a unui credit pentru o firmă, prezentată în 2.3.1.2.
PCredit
Analiza documentatiei depuse
Inspector de credit
Fig.3.2
Descrierea cazului de utilizare -Analiza documentaţiei depuse- este:
Denumire : Analiza documentaţiei depuse
Scop : Calcularea coeficientului de risc
Actori: Inspectorul de credite
Punct iniţial: Inspectorul de credite solicită documentaţia depusă de firmă
Punct final: Obţinerea valorii coeficientului de risc
Descriere derulare:
• inspectorul de credite solicită documentaţia depusă de firmă;
73
• dacă firma este un client al băncii se verifică informaţiile existente despre client;
dacă nu, baza de date este actualizată cu datele generale ale clientului;
• din documentaţie se selectează informaţia care contribuie la calcularea
coeficientului de risc;
• în cazul unui coeficient de risc ridicat, cererea este respinsă;
• se analizează suma cerută de firmă prin comparaţie cu posibilităţile băncii de a
acorda creditul solicitat;
Fig. 3.3
• dacă rezultatul este favorabil (nivel de responsabilitate < 100.000.000) cererea
de credit este admisă şi înregistrată;
Rezultat măsurabil
Cererea de credit este admisă şi înregistrată, sau respinsă
După prezentarea scenariului anterior, cazul de utilizare „Analiza documentaţiei
depuse” poate fi delaliat ca în figura 3.3
74
3.4.2 Diagrama claselor şi diagrama obiectelor
Clasa corespunde semantic entităţilor din sistemul real. O clasă desemnează un
grup de obiecte care au proprietăţi similare (atribute), un comportament comun (operaţii),
relaţii comune cu alte obiecte şi o aceeaşi semantică.
Obiectele sunt considerate instanţe ale clasei, fiind construite pornind de la clase,
printr-un proces de instanţiere. Un obiect are o identitate ce-l distinge de celelalte obiecte
şi este caracterizat printr-un ansamblu de atribute şi un anumit comportament.
Structura sistemului este reprezentată cu ajutorul a două tipuri de diagrame:

diagrama claselor şi diagrama obiectelor.
Diagrama claselor prezintă structura statică a sistemului, privită ca ansamblu al
claselor de obiecte şi al relaţiilor dintre clase. În strânsă legătură cu ea, diagrama
obiectelor evidenţiază obiectele şi legăturile dintre ele. Diagramele obiectelor prezintă
cazuri particulare, facilitează înţelegerea structurilor de date complexe.
Reprezentarea unei clase presupune specificarea atributelor ce-i definesc
structura, a operaţiilor ce-i definesc comportamentul şi a relaţiilor cu celelalte clase.
În UML, o clasă este reprezentată printr-un dreptunghi în care se specifică numele
clasei, atributele şi operaţiile.
Nume clasă Furnizori
Atribute cod
nume
Operaţii CitesteCod
ScrieNume
Desemnarea obiectelor se face prin nume individuale sau prin nume generice în
locul numelor individuale; numele obiectului este subliniat.
75
401_furnizor : Furnizori
Fiecare atribut poate lua o valoare dintr-un domeniu de definiţie specificat în

reprezentarea clasei. Implicit, atributele sunt încapsulate în obiecte, interacţiunile având
loc numai prin intermediul operaţiilor. Nivelul de vizibilitate al fiecărui atribut (privat,
protejat şi public) se precizează în reprezentările grafice ale claselor cu ajutorul
caracterelor -, #, respectiv +.
Operaţiile sunt reprezentate împreună cu numărul, ordinea şi tipul argumentelor
necesare definirii acţiunii lor. În cazul când operaţia este o funcţie, se specifică şi tipul
valorii returnate.
Asocierea este o conexiune semantică bidirecţională între clase. Ea este
reprezentată printr-o linie continuă între clasele implicate, de-a lungul căreia se scrie
numele asocierii. Dacă sensul de transmitere a mesajelor este unic, acesta se evidenţiază
printr-o săgeată de la emiţător la receptor.
Dacă între două clase există o singură asociere, numele asocierii este suficient
pentru a preciza relaţia. Atunci când între două clase există mai multe asocieri, se
foloseşte noţiunea de rol, care exprimă felul în care o clasă vede o altă clasă în cadrul
unei asocieri. Fiecare rol al unei asocieri evidenţiază ordinul de multiplicitate care arată
câte obiecte ale unei clase pot fi legate unui obiect al celeilalte clase.
Dintre proprietăţile unei asocieri, multiplicitatea este cel mai des întâlnită în
diagramele de structură. Este determinată de context şi evidenţiază numărul instanţelor
unei clase ce se pot asocia cu o singură instanţă a altei clase. Multiplicitatea restrânge
numărul de obiecte ce se află în legătură, de aceea, când mai multe instanţe ale unei clase
sunt legate la o instanţă a clasei asociate se foloseşte cazul general (n). În aplicaţii cea
mai importantă distincţie se face între multiplicitatea “zero” şi multiplicitatea “mai
mulţi”.
76
Fig. 3.4
În diagrama claselor, multiplicitatea se specifică printr-o cifră urmată eventual de

semnul “+”, printr-un interval sau printr-o succesiune de cifre.
Astfel, 1 înseamnă că o instanţă a unei clasei este legată la o singură instanţă a
clasei asociate; 1+ înseamnă că una sau mai multe instanţe ale unei clase sunt legate cu o
instanţă a clasei asociate; 2-5 înseamnă că două până la cinci instanţe ale unei clase sunt
legate cu o instanţă a clasei asociate; 1,2,3 înseamnă că una, două sau trei instanţe ale
unei clase sunt legate cu o instanţă a clasei asociate.
Asocierile pot fi caracterizate prin atribute şi pot avea propriile lor operaţii. În
acest caz se reprezintă ca o clasă, ce are acelaşi nume cu asocierea şi se conectează printr-
o linie întreruptă de asociere.
Agregarea şi generalizarea, ca forme de asociere prezente în procesul de
ierarhizare a claselor, sunt reprezentate în diagramele de structură cu simboluri specifice.
Agregarea, ca relaţie de tip “parte-întreg”, evidenţiază o asociere între o clasă cu
rol predominant (clasa agregat) şi componentele sale (agregate). Relaţia de agregare este
o relaţie între clasa întregului şi clasa unei componente. Unui întreg cu mai multe
componente îi corespund mai multe relaţii de agregare. Definind apartenenţa
77
componentei la întreg se poate specifica şi multiplicitatea fiecărei componente faţă de
întreg. Acest mod de a defini agregarea îi conferă statutul de formă specială a asocierii.
În finalul acestui subcapitol prezentăm în figura 3.5 diagrama claselor în cazul

sistemului informatic privind aprovizionarea cu mărfuri
CContract
NrContract : integer
contracteaza DataContract : integer
CFurnizor TermenContract : integer
* contineC
IncarcaContract()
FDenumire : string ConsultaContract() 1..* MarfaContract
FLocalitate : string ValoareContract() CantContract : integer
AdaugaFurnizor() PretContractttribute : integer
AfiseazaLocalitate()
corespunde ValM arfaContract()
M odificaFurnizor()
* corespundeC
livreaza
CMarfa
CFactura
* DenumireM arfa : string
NrFactura : integer UM M arfa : string
DataFactura : string ModificaDenumire()
TvaFactura()
ValFactura()
corspundeF
contineF
*
MarfaFactura
1..*
CantFactura : real
Pretfactura : real
ValM arfaFactura()
fig 3.5
3.4.3 Diagrama de colaborare

Diagrama de colaborare prezintă un grup de obiecte şi interacţiunile dintre ele.
Obiectele şi legăturile dintre ele sunt reprezentate ca în diagramele obiect. Mesajele
schimbate între obiecte sunt reprezentate de-a lungul legăturilor. Ordinea de trimitere a
diferitelor mesaje este indicată printr-un număr amplasat la începutul mesajului.
Numele mesajului corespunde unei operaţii definite în clasa obiectului destinatar
al mesajului, argumentele sale corespunzând parametrilor actuali ai operaţiei.
Argumentele mesajelor sunt reprezentate în diagrame fie în pseudocod fie în sintaxa
limbajului de programare.
De exemplu (fig.3.6), diagrama de colaborare definită pentru a evidenţia

aprovizionarea cu materiale şi păstrarea lor în gestiune este:
1:se primeşte factura Furnizor
78
Materiale 3: transfer(BPTR)
2: depozitare (NRCD)
Gestiune
Fig3.6
Pentru a evidenţia declanşarea interacţiunilor de către un element extern
sistemului, în diagramele de colaborare pot fi cuprinşi actori. Fără a se intra în detaliile
obiectelor de interfaţă cu utilizatorul, în acest caz primul mesaj de interacţiune este trimis
de actor.
În faza de analiză, diagramele de colaborare urmăresc scenarii definite pornind de
la cazurile de utilizare.
Exemplu:
în sistemul informatic privind vânzarea produselor, se poate defini o diagramă de
colaborare între obiectele claselor Clienţi, Facturi şi DocumenteÎncasare, pentru a
reprezenta modul în care au fost încasate facturile emise pentru clienţi (fig.3.7 )
Clienti
Facturi
DenumireClient : string *
NrFactura : integer
ContBanca : integer
Datafactura : string
StareFactura : char
ValoareFactura()
DocIncasare
IdDocument : integer
Suma : real
IdClient : undefined
AfiseazaClient()
Afiseaza Factura()
Fig 3.7
În faza de proiectare, diagrama de colaborare furnizează un punct de vedere
complet al dinamicii sistemului, evidenţiind comportamentul claselor ca răspuns la
apariţia unor evenimente, noi operaţii şi clasele cărora le aparţin.
Colaborările definite pentru a urmării anumite cerinţe ale utilizatorilor pot
conduce la apariţia sau dispariţia unor obiecte, la modificarea proprietăţilor unui obiect,
la actualizarea restricţiilor de integritate sau la modificarea relaţiilor dintre obiecte. În
cazul în care obiecte aparţinând aceleiaşi clase participă la colaborări diferite, în funcţiile
79
de scenarii diferite ale aceluiaşi caz de utilizare, se pot specifica împreună cu mesajele
condiţii ce aduc detalii suplimentare pentru implementare.
3.4.4 Diagrama de secvenţă a operaţiilor
Diagrama de secvenţe ilustrează interacţiunile dintre obiecte din punct de vedere

temporal. Este întocmită pentru scenarii ale unui caz de utilizare, arată obiectele şi
interacţiunile dintre ele de-a lungul unui scenariu.
În diagrama de secvenţe apar doar obiecte ale căror clase sunt reprezentate în
diagrama claselor şi între care au fost definite relaţii. Mesajele corespund operaţiilor prin
care obiectele comunică. Reprezintă apeluri ale operaţiilor descrise la nivelul claselor.
Pentru fiecare mesaj, în clasa obiectului destinatar trebuie să existe o operaţie
corespunzătoare, reacţia obiectului la mesajul primit.
Fiecare obiect este reprezentat printr-un dreptunghi în care se înscrie numele.
Linia de viaţă a obiectului se specifică printr-o bară verticală.
Mesajele sunt reprezentate prin săgeţi orizontale de la emiţător la receptor.
Convenind că timpul se scurge de sus în jos, ordinea de trimitere este dată de poziţia pe
axa verticală.
Împreună cu diagramele de colaborare, diagramele de secvenţe alcătuiesc aşa
zisele diagrame de interacţiune, ce evidenţiază mesajele trimise între obiecte. În timp ce o
diagramă de secvenţe se construieşte pentru un singur scenariu în care pot fi implicate
mai multe obiecte, diagramele de colaborare conţin un grup restrâns de obiecte, ce pot fi
implicate în mai multe scenarii.
Exemplu:
în sistemul informatic privind aprovizionarea cu mărfuri, succesiunea operaţiilor de la
formularea unei cereri de marfă şi până la livrarea efectivă a mărfii poate fi prezentată în
diagrama de secvenţe din figura 3.8
Aprovizionare: Furnizor: Factura: Marfa:
CereMarfa
Confirma
TrimiteFactura
LivreazaMarfa
80
fig 3.8
3.4.5 Diagrama de stare
Diagrama schimbărilor de stare descrie comportamentul obiectelor unei clase prin

stări şi evenimente. Se construieşte doar pentru clasele cu comportament interesant
dinamic, completând descrierea unui caz de utilizare.
Diagramele de stări modelează ciclul de viaţă al unei singure clase, evidenţiind şi
eventualele evenimente trimise de ea la altă clasă din sistem.
Fiecare obiect este la un moment dat într-o stare particulară. Starea este definită
de valorile atributelor şi de legăturile sale cu alte obiecte. Este un răspuns la apariţia unui
eveniment extern.
Exemplu:
în sistemul informatic privind gestiunea stocurilor, starea curentă a unui tip de material
poate fi: în aprovizionare, depozitat în gestiune, sau în consum la secţie. Este determinată
de valoarea atributului document, ce conţine numele documentului pe care materialul este
consemnat la un moment dat.
Dacă documentul este “Nir”, clasa Material este asociată cu clasa Gestiune prin asocierea
Depozitat în.
Gestiune <Depozitat în Material
81
1..* document
În diagrama de stare sunt descrise operaţiile ce reprezintă răspuns la evenimente

externe clasei. Corespund unor operaţii descrise în diagrama claselor, vizibile din afara
clasei (publice).
Starea este descrisă printr-un nume care o identifică şi o listă de acţiuni/activităţi

ce sunt executate la apariţia unui eveniment. Într-o diagrama de stare există o singură
stare iniţială şi una sau mai multe stări finale, determinate de condiţiile de apariţie ale
evenimentelor.
Tranziţia de stare reprezintă schimbarea stării datorită unui eveniment.

Evenimentul corespunde apariţiei unei situaţii date în domeniul problemei. El nu are
durată. Trecerea dintr-o stare în alta este instantanee, sistemul fiind întotdeauna într-o
stare cunoscută.
Tranziţia de stare este reprezentată printr-o săgeată de la starea sursă la starea

destinaţie etichetată cu:
▪ numele evenimentului care a generat tranziţia
▪ condiţia de apariţie a evenimentului
▪ acţiunea ce se execută la apariţia evenimentului
Exemplu:
în sistemul informatic privind aprovizionarea, diagrama de stări pentru o factură este cea
din figura 3.9
:
acceptare
82
Sosita Inregistrata
Do: ConsultaFz livrare Do: IncarcaDateFz
: VerificaFz : IncarcaDateFact
[sume OP<ValFact]
In curs de achitare
achitare parţială Do: CalcValFact
:AfisezAchitat
: SumePartiale
[sume OP=ValFact]
Achitată
Do: ListaSume
: AfiseazaData
: SeteazaStare
fig 3.9
3.4.6 Diagrama de activităţi
Diagrama de activităţi descrie comportamentul sistemului introducând elemente

de implementare. Ataşată unui caz de utilizare, îi detaliază acţiunile şi procesele
corespunzătoare. Ataşată unei clase cu comportament dinamic semnificativ, descrie
tranziţia de la o stare la alta sau algoritmul de prelucrare al operaţiilor.
Foloseşte următoarele elemente: acţiune, tranziţie, decizie.
Acţiunea corespunde unei etape în execuţia unui algoritm. Fiecare operaţie, privită ca o înlănţuire
de acţiuni, poate fi detaliată în operaţii elementare. Pentru simplificarea diagramelor, acţiuni omogene pot
fi grupate în subactivităţi.
Tranziţia de la o acţiune la alta se reprezintă printr-o săgeată etichetată eventual cu:
▪ numele evenimentului care determină tranziţia
▪ condiţia de apariţie a evenimentului
Decizia indică ramificarea unei tranziţii în funcţie de îndeplinirea unei condiţii.
În faza de analiză, diagramele de activităţi completează descrierea cazurilor de utilizare. Pentru
prezentarea derulării acţiunilor sunt folosiţi termeni apropiaţi utilizatorului.
Exemplu: ▪ diagrama de activităţi din figura 3.10 evidenţiază activităţile desfăşurate pentru aprovizionarea
cu marfă şi înregistrarea ei în gestiune. Poate folosi pentru completarea descrierii cazurilor de utilizare din
83
sistemul informatic privind aprovizionarea, sau poate însoţi diagrama de secvenţe din cadrul aceluiaşi
sistem informatic.
se inregistreaza factura
se verifica marfa
marfa inregistrata in Nir marfa refuzata
se intocmeste OP factura stornata
Fig 3.10
În faza de proiectare, diagramele de activităţi apar ataşate unei clase şi conţin

elemente de implementare ale operaţiilor descrise în clase. Acţiunile pot fi descrise în
limbaj natural, în pseudocod sau într-un limbaj de programare (C++, Visual Basic).
Echivalente schemelor logice utilizate în programarea structurată, diagramele de activităţi
conţin structurile fundamentale de programare: liniară, repetitivă sau alternativă.
În cazul unei clase cu comportament dinamic semnificativ, pentru cazul în care
modificările de stare au o determinare internă, rezultată din efectuarea sau încheierea
unor operaţii, starea este descrisă printr-o listă de acţiuni/activităţi, ce se execută la
apariţia unui eveniment. Tranziţia de la o stare la alta este determinată de încheierea
acestor acţiuni sau subactivităţi (tranziţii interne). În aceste cazuri, diagramele de
activităţi însoţesc diagramele de stare.
84
3.5 Modelul sistemului real şi diagramele UML
Fiecare tip de diagramă redă un anumit aspect al sistemului modelat: structura

statică, interacţiunile între obiecte, componentele fizice ale unei aplicaţii, interacţiunile
dintre utilizatori şi sistem. Împreună constituie un model al lumii reale, văzut din puncte
de vedere diferite şi în momente de timp diferite.
diagramele prezintă structura şi comportamentul sistemului
Structura sistemului este evidenţiată în diagrama claselor şi diagrama obiectelor.

Acestea conţin clase şi relaţii dintre ele, sau obiecte şi legăturile dintre ele, atunci când
comportamentul obiectelor individuale impun modificări de structură. În acest ultim caz,
structura este evidenţiată în plus prin diagramele de colaborare.
Pentru o clasă, simularea comportamentului înseamnă prezentarea stărilor
posibile şi a evenimentelor care determină tranziţia de la o stare la alta. Se realizează cu
ajutorul diagramei de stări, care cuprinde şi eventualele restricţii apărute pe parcursul
înlănţuirii stare-eveniment-stare.
În cele mai multe situaţii, modificările de stare sunt determinate de evenimente
survenite în afara obiectului şi la care acesta reacţionează. În cazul în care modificările au
o determinare internă, rezultată din efectuarea sau încheierea unor acţiuni proprii unei
stări, pentru reprezentarea comportamentului se definesc în plus diagrame de activităţi.
Pentru sistem, simularea comportamentului înseamnă evidenţierea
interacţiunilor dintre clase şi obiecte. Se realizează cu ajutorul a trei tipuri de diagrame:
de colaborare, de secvenţe şi de activităţi. Aceste diagrame prezintă schimbul direct de
mesaje, prin definirea unor asocieri între clase. Pentru fiecare mesaj, în clasa destinatar
trebuie să existe o operaţie corespunzătoare, reacţia obiectului la mesajul primit.
În timp ce diagrama de activităţi descrie un caz de utilizare, diagramele de
secvenţe şi de colaborare sunt întocmite pentru scenarii ale unui caz de utilizare, arată
clasele şi interacţiunile dintre ele de-a lungul unui scenariu.
Pentru clasele cu comportament dinamic semnificativ, diagrama de stări
completează descrierea unui caz de utilizare.
diagramele urmăresc funcţionalitatea sistemului şi cerinţele

utilizatorilor
Definirea cerinţelor funcţionale ale sistemului sunt evidenţiate în cazuri de
utilizare, ce corespund unor acţiuni întreprinse de o anumită entitate (actor) pentru un
grup de utilizatori. Prin evidenţierea cazurilor de utilizare se delimitează domeniul de
studiu, se stabileşte o legătură directă între utilizatori şi analiştii de sistem.
85
Funcţionalitatea întregului sistem este dată de mulţimea cazurilor de utilizare, grupate
într-o diagramă a cazurilor de utilizare.
Diagrama cazurilor de utilizare, reprezentare a legăturii între actori şi cazurile de
utilizare corespunzătoare, constituie o descriere funcţională a cerinţelor, structurată în
raport cu unul sau mai mulţi actori. În etapa definirii cazurilor de utilizare nu există
obiecte. Trecerea la o structură obiect se face determinând obiectele care colaborează
pentru a obţine funcţionalitatea descrisă de diferitele cazuri de utilizare. Pentru aceasta se
urmăresc diferite scenarii posibile, privite ca instanţe ale cazurilor de utilizare. Se obţin
diagrame obiect şi diagrame de secvenţe. Pentru cazurile algoritmilor complecşi se
definesc diagrame de stare şi diagrame de activităţi.
Abordând modul în care funcţionalitatea sistemului este realizată cu ajutorul
diagramelor UML, mulţi autori consideră că există două importante diagrame: diagrama
cazurilor de utilizare şi diagrama claselor. Cerinţele utilizatorilor se regăsesc în diagrama
cazurilor de utilizare. Funcţionalitatea sistemului exprimată în aceste cerinţe este
transformată de analiştii de sistem într-un model alcătuit din clase şi relaţii între ele.
Celelalte diagrame sunt subordonate diagramei claselor şi folosesc elemente şi
instrumente ale metodologiei orientate obiect pentru a completa modelul claselor:
▪ diagramele de activităţi şi de stări aduc detalii suplimentare privind
comportamentul obiectelor din clase.
▪ diagramele de colaborări şi de secvenţe detaliază interacţiunea între clase.
▪ diagramele de activităţi cuprind elemente necesare pentru implementarea claselor.
diagramele conduc la modele statice, dinamice şi funcţionale ale

sistemului real
Diagrama cazurilor de utilizare asigură legătura între cerinţele utilizatorilor şi
realizarea acestora prin intermediul abstracţiilor definite şi evidenţiate în diferite alte
diagrame. Aceste alte diagrame definesc împreună un model al sistemului real sub aspect
static, dinamic şi funcţional. Grupate după aspectul evidenţiat, diagramele pot constitui la
un moment dat pentru sistem un model static, unul dinamic sau unul funcţional.
Între modele există o strânsă legătură:
▪ modelul dinamic arată succesiunea în care operaţiile definite în clasele modelului static
sunt executate. Acţiunile din modelul funcţional corespund operaţiilor din modelul static,
actorii şi cazurile de utilizare prefigurează obiectele modelului static care sunt legate prin
funcţii.
▪ actorii sunt obiecte explicite din modelul obiectelor, cel care le prezintă structura.
Fluxurile de date de la sau spre actori reprezintă operaţii pentru obiecte. Pentru un obiect
actor, modelul dinamic arată când acţionează. Modelul dinamic al acestor obiecte este
necesar pentru a determina ordinea operaţiilor.
86
▪ modelul funcţional prezintă înţelesul operaţiilor şi al restricţiilor din modelul obiect,
înţelesul acţiunilor şi activităţilor din modelul dinamic
Toate cele trei modele sunt supuse unor restricţii, ce arată relaţiile fie dintre două
obiecte la un acelaşi moment de timp, fie între valori ale aceluiaşi obiect la momente de
timp diferite. Restricţiile pot fi asupra obiectelor, caz în care arată dependenţa parţială sau
totală a unor obiecte de altele, pot fi asupra stărilor din modelul dinamic, sau pot
specifica restricţii asupra operaţiilor din modelul funcţional.
Dimensiunea statică vizează structura sistemului, componentele şi relaţiile dintre
ele. Este evidenţiată prin diagrama claselor şi diagrama obiectelor. Aceste diagrame
suferă modificări de-a lungul ciclului de viaţă al sistemului, conducând în final la un
model al sistemului real, complet implementabil cu ajutorul limbajelor orientate obiect
(C++ , Visual Basic).
Înţelegerea unui sistem nu se poate însă limita doar la evidenţierea componentelor
şi a relaţiilor dintre ele. Pentru a surprinde partea dinamică, dependentă de timp, se
definesc noi diagrame: diagrame de colaborare, diagrame de stare şi diagrame de
secvenţe. Pentru obiectele care colaborează, acestea arată care sunt şi cum se modifică
stările unui obiect, evenimentele care cauzează în timp tranziţia de la o stare la alta.
Evidenţiază secvenţele de operaţii ce apar ca răspuns la stimuli externi, fără a lua în
calcul ce face operaţia şi cum este ea implementată.
Dimensiunea dinamică a sistemului este prezentată prin prisma evenimentelor
percepute de sistem. Apariţia sau dispariţia unor obiecte, modificarea proprietăţilor unui
obiect, actualizarea restricţiilor de integritate sau schimbarea relaţiilor dintre obiecte, sunt
doar câteva din modificărilor generate în timp de apariţia unor evenimente.
Aspectul funcţional vizează fluxurile de date care circulă între diferiţi actori ai
sistemului. Descrie ce se întâmplă în sistem şi este reprezentat cu ajutorul diagramelor
cazurilor de utilizare, al diagramelor de activităţi şi de componente.
În plus, evidenţierea aspectului funcţional presupune identificarea datelor de
intrare şi a datelor de ieşire din sistem, definirea procedurilor de prelucrare a datelor,
identificarea restricţiilor şi precizarea criteriilor de optimizare.
diagramele urmăresc ciclul de viaţă al sistemului pe parcursul etapelor de

analiză, proiectare şi implementare
Realizarea unui sistem informatic presupune parcurgerea mai multor etape.
Rezultatul se regăseşte de fiecare dată într-un model. Legătura între modele se păstrează,
pentru că se porneşte de la elementele domeniului din sistemul real şi se introduc detalii
necesare implementării pe parcursul etapei de proiectare. Sunt reprezentate aceleaşi
elemente, însă din puncte de vedere diferite.
87
Parcurgerea ciclului de viaţă al sistemului înseamnă revedere, detaliere,
completare a modelelor existente la un moment dat. Confirmă faptul că modelele
orientate obiect se dezvoltă în spirală.
Definite pentru sisteme noi, sau pentru a permite evoluţia celor existente,
diagrama cazurilor de utilizare constituie pe parcursul etapelor de analiză şi proiectare
cadrul de referinţă comun. Constituie punctul iniţial în stabilirea cerinţelor proiectării şi
formează bază pentru testarea şi verificarea sistemului obţinut.
Modelele obţinute în diferite etape sunt reprezentate prin diagrame de diferite
tipuri, între care există legături de moment determinate de context. În faze care se succed,
fiecare model aduce o perspectivă diferită asupra sistemului, adaugă noi elemente
imaginilor precedente, până în final, când se ajunge la o viziune de ansamblu a stadiilor
prin care va trece sistemul.
Definirea modelelor nu este o activitate liniară, în sensul că diagramele definite într-o
etapă pot fi modificate în alta. Înlănţuirea şi interacţiunea modelelor are loc pe tot
parcursul definirii sistemului:
▪▪ în faza de definire a cerinţelor se stabilesc cerinţele funcţionale ale sistemului cu
ajutorul diagramelor cazurilor de utilizare
▪▪ rezultatele etapei de analiză se concretizează într-o diagramă a claselor şi în diagrame
de comportament (de secvenţe şi de activităţi)
▪▪ în etapa de proiectare sunt definite noi clase, se renunţă la clase care nu au relevanţă,
sunt evidenţiate relaţii suplimentare între clase. Clasele definite pentru mai multe cazuri
de utilizare sunt integrate într-o structură unică. Se definesc diagrame de stare, se adaugă
detalii necesare implementării în modelul claselor.
O aceeaşi diagramă poate fi folosită în scopuri diferite pe parcursul ciclului de
viaţă:
▪ diagrama de activităţi este ataşată în faza de analiză unui caz de utilizare şi serveşte în
faza de implementare la definirea schemelor logice de program, la descrierea detaliată a
operaţiilor. Componentele se traduc în fraze SQL sau în instrucţiuni de program şi
contribuie la definirea structurii claselor.
▪ diagramele obiect sunt folosite în etapa de analiză pentru abstractizarea modelului, şi în
faza de proiectare pentru introducerea detaliilor necesare implementării.
1. Care din afirmaţiile următoare nu este adevărată ?

a) În faza de proiectare se alege soluţia informatică pentru realizarea efectivă a
sistemului.
b) Un obiect este o abstracţie, un concept, folosit pentru reprezentarea lumii reale şi
c) O clasă este o abstracţie, un concept, folosit pentru reprezentarea lumii reale şi
88
2. Care din afirmaţiile următoare este falsă ?
a) Identitatea unui obiect este acea proprietate a obiectului care îl distinge de alte
obiecte.
b) Obiectul este definit de un identificator intern unic, independent de valoarea sau
de adresa de memorie a obiectului.
c) Identificatorul este controlat direct de programator. Se exprimă prin diferitele
nume utilizate de programator pentru a-l numi.
]
3. Care din afirmaţiile următoare este adevărată ?
a) Identitatea este o abstracţie a valorilor atributelor şi a legăturilor unui obiect.
b) Starea obiectului reprezintă mulţimea valorilor tuturor atributelor şi legăturilor
sale la un moment dat.
c) Identitatea este adesea asociată cu valoarea unui obiect satisfăcând anumite
condiţii.

a) Comportamentul este determinat de ansamblul operaţiilor pe care obiectul le
poate executa.
b) Starea exprimă modul în care un obiect acţionează şi reacţionează.
c) În cazul tehnicilor orientate obiect, prin ierarhizare se evidenţiază caracteristicile
esenţiale ale unui obiect, cele care-l disting de alte obiecte.

a) Abstractizează înseamnă gruparea obiectele în clase.
a) Prin abstractizare definiţiile comune sunt memorate o singură dată pentru clasă, în
loc să fie memorate pentru fiecare instanţă.
c) Prin definirea claselor, obiectele nu beneficiază de codul reutilizat, operaţiile fiind
rescrise pentru fiecare obiect.

a) O clasă de obiecte descrie o mulţime de obiecte cu aceleaşi proprietăţi şi acelaşi
comportament.
b) O clasă conţine obiectele cu aceleaşi operaţii şi relaţii similare faţă de alte obiecte.
c) O clasă de obiecte descrie o mulţime de obiecte cu aceleaşi proprietăţi, acelaşi
comportament şi relaţii similare faţă de alte obiecte.
89
a) Încapsularea este un proces de grupare a elementelor unei clase în elemente
accesibile din exterior şi elemente proprii.
b) Moştenirea permite separarea aspectului extern, accesibil altor obiecte, de
implementarea internă.
c) Abstractizarea oferă posibilitatea de a masca atributele proprii ale unui obiect,
precum şi modul în care se execută operaţiile.

a) Datorită încapsulării, implementarea poate fi schimbată fără a afecta aplicaţia.
b) Încapsularea constituie una din premisele de bază ale reutilizării.
c) Abstractizarea constituie una din premisele de bază ale reutilizării.

a) Ierarhizarea este o operaţia de ordonare a abstracţiilor.
b) Agregarea este o relaţie de tip parte-întreg, în care obiecte care reprezintă
componente ale unui întreg, sunt asociate cu întregul.
c) Generalizarea este o formă de asociere în care există un obiect format din
componentele sale, componentele fiind văzute ca parte a întregului.

a) Semantic agregatul este văzut ca un obiect, tratat ca o unitate în multe operaţii,
deşi fizic este format din mai multe obiecte.
b) Prin generalizare, propagarea operaţiilor întregului la părţi este automat aplicată
componentelor.
c) În cazul generalizării una din clase are un rol predominant în raport cu cealaltă.

a) Agregarea este o relaţie dintre o clasă de bază şi una sau mai multe clase derivate
ale ei.
b) Prin agregare, atributele şi operaţiile comune sunt grupate în superclasă, fiind
moştenite de subclase.
c) Generalizarea este o relaţie dintre o clasă de bază şi una sau mai multe clase
derivate ale ei.

a) În cazul agregării clasele sunt integral coerente, subclasa aducând eventuale
informaţii adiţionale, specifice.
90
b) Partajarea atributelor şi operaţiilor între clase, de-a lungul unei ierarhii între clase
şi subclase este evidenţiată cu ajutorul conceptului de generalizare.
c) Moştenirea permite constituirea de noi tipuri de obiecte şi clase, evitând rescrierea
şi recodificarea.

a) Prin agregare, clasele pot moşteni atât operaţii (metode), cât şi variabile de
instanţă (atribute).
b) Între clasele din figura următoare există o relaţie de agregare.
DOCUMEN
CONTRACT FACTURĂ
c) Între clasele din figura următoare există o relaţie de generalizare
DOCUMEN
CONTRACT FACTURĂ

a) În timp ce generalizarea se referă la relaţia dintre aceeaşi clasă şi subclasele sale,
moştenirea se referă la mecanismul de a transmite atribute şi operaţii de-a lungul unei
relaţii de generalizare.
b) În timp ce moştenirea se referă la relaţia dintre aceeaşi clasă şi subclasele sale,
generalizarea se referă la mecanismul de a transmite atribute şi operaţii de-a lungul unei
relaţii de generalizare.
c) Polimorfismul defineşte caracteristica unei operaţii de a se comporta în mod
diferit în funcţie de clasa de obiecte căreia îi aparţine.

a) Un caz de utilizare este iniţiat întotdeauna de un actor şi exprimă o funcţie a
sistemului, declanşată ca răspuns.
b) Funcţionalitatea completă a sistemului este dată de diagrama claselor.
91
c) Actorii sunt elementele din sistem care generează sau primesc evenimente.

a) Diagrama obiectelor prezintă un grup de obiecte şi interacţiunile dintre ele.
b) În faza de analiză, diagrama claselor urmăreşte scenarii definite pornind de la
cazurile de utilizare.
c) Diagramele de interacţiune evidenţiază mesajele trimise între obiecte

a) Împreună cu diagramele de secvenţe, diagramele de colaborare alcătuiesc aşa
zisele diagrame de interacţiune, ce evidenţiază mesajele trimise între obiecte.
b) În timp ce o diagramă de colaborare se construieşte pentru un singur scenariu în
care pot fi implicate mai multe obiecte, diagramele de secvenţe conţin un grup restrâns de
obiecte, ce pot fi implicate în mai multe scenarii.
c) În faza de proiectare, diagrama de colaborare evidenţiază comportamentul
claselor ca răspuns la apariţia unor evenimente.

a) Diagramele de secvenţe ilustrează interacţiunile dintre obiecte din punct de vedere
temporal.
b) Diagramele de secvenţe arată obiecte şi interacţiunile dintre ele de-a lungul unui
scenariu.
c) Pentru fiecare mesaj din diagrama de secvenţe, în clasa obiectului destinatar
trebuie să existe un atribut corespunzătoare, reacţia obiectului la mesajul primit.

a) Diagramele schimbărilor de stare descriu comportamentul obiectelor unei clase
prin stări şi evenimente.
b) Diagramele schimbărilor de stare se construiesc doar pentru clasele cu
comportament interesant dinamic, completând descrierea unui caz de utilizare.
c) Diagramele de stări modelează ciclul de viaţă al unei singure clase, fără a
evidenţia şi eventualele evenimente trimise de ea la altă clasă din sistem.

a) Diagrama de activităţi descrie comportamentul sistemului introducând elemente
de implementare.
92
b) Ataşată unei clase, diagrama de activităţi detaliază acţiunile şi procesele unui caz
de utilizare
c) Ataşată unui caz de utilizare, diagrama de activităţi descrie tranziţia de la o stare
la alta sau algoritmul de prelucrare al operaţiilor.

a) În faza de proiectare diagramele de activităţi completează descrierea cazurilor de
utilizare.
b) În faza de analiză diagramele de activităţi apar ataşate unei clase şi conţin
elemente de implementare a operaţiilor descrise în clase.
c) Împreună, diagramele UML constituie un model al lumii reale, văzut din puncte
de vedere diferite şi în momente de timp diferite.

a) Structura statică sistemului este evidenţiată în diagrama claselor şi diagrama
obiectelor.
b) Diagrama de stări nu cuprinde restricţiile apărute pe parcursul înlănţuirii stare-
eveniment-stare.
c) Comportamentul sistemului se prezintă cu ajutorul a trei tipuri de diagrame: de
colaborare, de secvenţe şi de activităţi.
a) Diagramele de secvenţe şi de colaborare sunt întocmite pentru scenarii ale unui
caz de utilizare
b) Diagrama de stări arată clasele şi interacţiunile dintre ele de-a lungul unui
scenariu.
c) Pentru clasele cu comportament dinamic semnificativ, diagrama de colaborări
completează descrierea unui caz de utilizare.
a) Prin evidenţierea cazurilor de utilizare se delimitează domeniul de studiu.
b) Prin evidenţierea obiectelor din diagrame se stabileşte o legătură directă între
utilizatori şi analiştii de sistem.
c) Cerinţele utilizatorilor se regăsesc în diagrama cazurilor de utilizare.
a) Diagramele de activităţi şi de stări aduc detalii suplimentare privind
comportamentul obiectelor din clase.
b) Diagramele claselor şi diagrama obiectelor detaliază interacţiunea între clase
c) Diagramele de activităţi cuprind elemente necesare pentru implementarea
claselor.
93
a) Diagrama de stări vizează structura sistemului, componentele şi relaţiile dintre
ele.
b) Dimensiunea statică este evidenţiată prin diagrama de activităţi şi diagrama de
secvenţe.
c) Diagrama cazurilor de utilizare constituie pe parcursul etapelor de analiză şi
proiectare cadrul de referinţă comun.
a) Aspectul funcţional este reprezentat cu ajutorul diagramelor cazurilor de utilizare
şi al diagramelor obiect.
b) Diagrama cazurilor de utilizare constituie punctul iniţial în stabilirea cerinţelor
proiectării şi formează bază pentru testarea şi verificarea sistemului obţinut.
c) O aceeaşi diagramă poate fi folosită în scopuri diferite pe parcursul ciclului de
viaţă al unui sistem.
Rezolvare
1-c 2-c 3-b 4-a 5-c 6-c 7-a 8-c 9-c 10-a 11-a 12-c
13-c 14-b 15-b 16-c 17-b 18-c 19-c 20-a 21-c 22-b 23-a
24-b 25-b 26-c 27-b
94
BIBLIOGRAFIE
[GJ99] Merise vers OMT et UML. InterEdition, Paris,1999.
[OD99] Oprea D. Analiza şi proiectarea sistemelor informationale

economice.Ed. Polirom, Iaşi, 1999.
[PI02] Popa G, Iliescu M, Udrică M. Baze de date Access. Culegere de

probleme. Ed. Cison, Bucureşti, 2004.
[SV03] Stanciu V. Proiectarea sistemelor informatice. Ed. DualTech,

Bucureşti, 2003.
[UM00] Udrică M. Modelare orientată obiect. Ed. Cison, Bucureşti,

2000.
[UM03] Udrică M. Date şi prelucrări în conducerea operativă a firmei.

Ed. best publishing, Bucureşti, 2003.
[UM04] Udrică M. Date şi prelucrări în conducerea strategică a firmei.

Ed. best publishing, Bucureşti, 2004.
[UM05] Udrică M., Martinov D. Sisteme informatice – metode şi

modele, Ed. Titu Maiorescu, Bucureşti, 2007.
[ZR02] Zaharie D, Roşca I. Proiectarea obiectuală a sistemelor. Ed.

DualTech, Bucureşti, 2002.
95

Sisteme Informatice de Gestiune

Î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 de Gestiune

Încărcat de

Drepturi de autor:

Formate disponibile

SISTEME INFORMATICE DE GESTIUNE

Prof. univ. dr. M. Udrică

SISTEMUL INFORMATIC AL ORGANIZAŢIEI

- introduce şi explică o serie de termeni (noţiuni) specifici pentru acest domeniu

Cuvinte cheie: sistem informaţional-decizional, sistem informatic, ciclul de viaţă al

1. SISTEMUL INFORMATIC AL ORGANIZAŢIEI

1.2 Sistem informatic

1.3 Proiectarea sistemelor informatice

1.3.2 Strategii de proiectare a sistemelor informatice

1.4.2 Modele ale ciclului de viaţă

1.5 Metode de proiectare a sistemelor informatice

F11 F12 F13

F111 F121 ………

Caracterizate prin simplitate şi o bună adaptare la cerinţele utilizatorului, aceste

2 Care din afirmaţiile următoare este adevărată ?

3 Care din afirmaţiile următoare este adevărată ?

4 Care din afirmaţiile următoare nu este adevărată ?

6 Care din afirmaţiile următoare nu este adevărată ?

7 Care din afirmaţiile următoare este adevărată ?

8 Care din afirmaţiile următoare este adevărată ?

9 Care din afirmaţiile următoare este adevărată ?

10 Care din afirmaţiile următoare este adevărată ?

- prezintă, explică şi exemplifică principiile metodologice, procedeele tehnologice

Cuvinte cheie:modelul conceptual al datelor, modelul conceptual al prelucrărilor, Merise,

2.1 Nivele de descriere

În “Merise vers OMT et UML” ([GJ99]), prezentând descrierea sistemului de la

2.2 Modele pentru date şi prelucrări

Pentru fiecare nivel există un model al datelor şi un model al prelucrărilor.

2.3 Modelarea conceptuală şi organizaţională a datelor

2.3.1 Modelul Entitate-Asociere

Aşa cum am mai afirmat, modelarea conceptuală şi organizaţională a datelor se

FURNIZORI furnizează MATERII PRIME

CLIENŢI cumpără PRODUSE

Atributele pot fi clasificate în funcţie de mai multe criterii:

DISPOZIŢIE LIVRARE se întocmeşte 0,n PRODUS

Cardinalitate minimală 1 este în cazul în care toate realizările entităţii participă la

• cardinalitate maximală n se declară dacă numărul maxim de apariţii ale unei

Numărul de entităţi care participă la o asociere formează dimensiunea

FURNIZOR furnizeazå MATERII PRIME

Modelarea este un proces complex şi subiectiv, astfel că soluţia aleasă este

emise FACTURI conţin MĂRFURI

2 modelarea prin atribute

CLIENT DOSAR CREDIT

2.3.1.3 Verificare. Normalizare. Descompunere

Indiferent de tehnica de modelare, asupra modelului se aplică operaţiile de

 verificarea presupune asigurarea că:

1. numele elementelor ce apar în modelul conceptual al datelor sunt unice.

FURNIZOR aduce MARFA

În cazul asocierilor, normalizarea permite asigurarea că atributele unei asocieri

FACTURI 0,n conţin 0,n MATERIALE

De asemenea în exemplul anterior, cantAprov este atribut care depinde de ambele

 descompunerea permite definirea, fără pierdere de informaţie, a mai multor

CONTRIBUABIL DOC PLATĂ

Ele pot implica:

•2• asocierile stabilite între entităţi.

0,n vânzare 1,1

2.4 Modelarea logică şi fizică a datelor

Modelarea logică depinde de particularităţile datelor vehiculate şi de posibilităţile

2.4.1 Trecerea de la modelul Entitate-Asociere la Modelul Relaţional

Pentru trecerea de la modelul Entitate-Asociere la Modelul Relaţional s-au stabilit

FURNIZORI 1,n furnizează 1,1 MATERIIPRIME

Aplicînd regula 1 se crează două scheme de relaţie:

FURNIZORI 1,n 1,n MATPRIME