PROIECTAREA SISTEMELOR INFORMATICE

1. Managementul afacerii şi tehnologia informaŃiei

În desfăşurarea oricărei activităŃi economice, financiare sau bancare nu se poate
imagina fără utilizarea unui puternic suport informaŃional care să asigure avantajul
concurenŃial în raport cu ceilalŃi competitori de pe piaŃă. A dobândi cunoaştere prin
informaŃia obŃinută este rolul tehnologiei informaŃiei (TI).
De aceea o atenŃie sporită se acordă astăzi problemelor legate de managementul
sistemului informatic care se ocupă cu planificarea dezvoltării sistemului informatic la
nivel de firmă, şi folosirea TI cu scopul susŃinerii personalului specializat în prelucrarea
datelor în vederea obŃinerii informaŃiilor necesare luării deciziilor .
Plecând de la exemplul unei firme vom constata că modul de desfăşurare a
afacerii se schimbă ca urmare a acŃiunii conjugate a următorilor factori: globalizare,
competiŃie de nivel înalt, informaŃia devenită resursă cheie a oricărei firme, spaŃiul virtual
de muncă şi chiar derularea activităŃii în condiŃiile companiei virtuale, comerŃ electronic,
existenŃa în cadrul firmei a personalului specializat în procesarea datelor şi analiză
(knowledge workei), un nou tip de relaŃie cu banca prin care se obŃin servicii şi produse
noi ca urmare a promovării noilor soluŃii TI etc
FuncŃionarea firmei în condiŃii optime a condus la structurarea unui model
sistemic al întreprinderii format din trei componente: subsistemul decizional, subsistemul
informaŃional şi subsistemul operaŃional.

1
 Subsistemul decizional pune în valoare informaŃiile obŃinute de la subsistemul
informaŃional şi le foloseşte în derularea actului decizional. La nivelul subsistemului
decizional se restructurează modul de pregătire, adoptare, aplicare şi evaluare a deciziilor,
astfel încât fiecare manager, după implementarea sistemului de management al calităŃii,
ştie cu mai multa claritate care este poziŃia lui in cadrul subsistemului decizional al
organizaŃie.
Subsistemul informaŃional are un dublu rol:
- asigură tot suportul informaŃional necesar luării oricăror decizii la toate
nivelurile (conducere, control) – flux ascendent
- asigură căile de comunicare între subsistemul operaŃional şi subsistemul
decizional – flux descendent
La nivelul subsistemului informaŃional se produc schimbări in modul de colectare
a datelor si de structurare a informaŃiilor necesare pentru luarea deciziilor si pentru
desfăşurarea activităŃii, apar modificări ale circuitelor si fluxurilor informaŃionale astfel
încât sa crească viteza de luare a unor decizii precum si capacitatea de răspuns a
organizaŃiei la diverşii factori care influenŃează profitabilitatea organizaŃiei;
Subsistemul operaŃional este locul unde practic se culeg datele (din activităŃile
economice specifice fiecărui agent economic) ce sunt transmise (ascendent)
subsistemului informaŃional. Subsistemul organizatoric al organizaŃiei consta in
ansamblul elementelor de natura organizatorica ce asigura cadrul, divizarea, combinarea
si funcŃionalitatea proceselor de munca in vederea realizării obiectivelor previzionate.

2
 Exemplu organizarea procesuală a unei instituŃii

Exemplu: Noua relaŃie cu banca: în ultimii ani se constată efortul constant al

băncilor de a ridica la un nou standard relaŃia client-bancă. Internetul a devenit un
important canal de distribuŃie permiŃând diversificarea produselor şi serviciilor oferite
clienŃilor. Utilizarea noilor tehnologii asigură posibilitatea realizării transferurilor
electronice de fonduri, asistarea deciziilor clienŃilor în gestiunea portofoliului, mai buna
cunoaştere a clienŃilor şi adaptarea ofertei în funcŃie de nevoile acestora,
confidenŃialitatea informaŃiei gestionate, prevenirea şi blocarea tranzacŃiilor ilegale,
etc.Sunt utilizate astăzi servicii de tipul: home banking, internet-banking, mobile-
banking.

2. Sistem informaŃional, sistem informatic, sistem informatic integrat

Putem defini informatica ştiinŃa prelucrării automate a datelor, instrument al

conducerii. Conceptele de bază cu care operează informatica sunt:
- informaŃia (cunoştinŃa = informaŃia, după momentul aflării ei) este reflectarea
în conştiinŃa noastră a elementelor lumii reale, înconjurătoare; informaŃia este
sursa de date supuse prelucrărilor, pe de o parte şi interpretarea rezultatelor
obŃinute prin prelucrarea datelor, pe de altă parte.
- informaŃia de tip dată = data este informaŃia (cunoştinŃa) înregistrată,
respectiv reprezentarea scrisă sau grafică a informaŃiei obŃinută din lumea

3
 înconjurătoare; este materia primă din care se obŃine, prin prelucrarea şi
interpretarea rezultatelor acesteia, altă informaŃie.
Prelucrarea datelor reprezintă procesul de transformare a datelor în alte date care,
prin interpretare, devin informaŃii care stau la baza deciziilor. Prelucrarea datelor folosind
tehnica de calcul este cunoscută sub numele de prelucrarea automată a datelor.
Un sistem reprezintă un ansamblu de elemente (componente) interdependente,
între care se stabileşte o interacŃiune dinamică, pe baza unor reguli prestabilite, cu scopul
atingerii unui anumit obiectiv.

Sistemul informaŃional economic poale fi definit ca un sistem integrat de

oameni de specialitate, mijloace si procedee adecvate, privind culegerea şi înregistrarea
datelor tehnico-economice si financiare, care privesc patrimoniul unităŃilor şi economiei
raŃionale în ansamblul acestora, prelucrarea şi analiza acestora, obŃinerea de informaŃii
utile in vederea conducerii si gestionarii eficiente a acestuia, stocarea si păstrarea datelor
si a informaŃiilor pentru documentari si controale ulterioare.
Sistemul informatic este un ansamblu structurat si corelat de proceduri si
echipamente electronice de calcul, care permit culegerea, transmiterea si prelucrarea
datelor, obŃinerea de informaŃii.
Datele şi informaŃiile proprii circuitului economic al patrimoniului sunt
consemnate in documente. În raport de modul de întocmire şi rolul lor în cadrul
sistemului informational, documentele pot fi justificative, de evidenta contabila sau de
sinteza si raportare.
Documentele justificative asigura datele de intrare in sistemul informaŃional
contabil, consemnează operaŃiile economice şi financiare în momentul efectuării lor, cu
scopul de a servi ca dovada a înfăptuirii lor şi ca instrument de fundamentare a
înregistrării contabile
Prin registrele contabile se formează şi materializează înregistrările proprii
sistemului de conturi. în condiŃiile folosirii unor tehnici de prelucrare diferite, ceea ce
diferenŃiază un registru de altul este forma de prezentare a informaŃiei, conŃinutul
rămânând acelaşi. Principalele registre ce se folosesc în contabilitate sunt: registrul
jurnal, registrul inventar şi cartea mare.

4
 Documentele de sinteză şi raportare reprezintă un sistem de indicatori economico-
financiari, ce caracterizează situaŃia patrimoniului şi rezultatele obŃinute. Se compun din:
bilanŃul contabil, contul de rezultate, anexa la bilanŃ şi raportul de gestiune
InterfaŃa între documentele contabile se realizează prin forma de contabilitate,
reprezentată printr-un sistem de formulare, corelate între ele, care servesc la înregistrarea
şi prelucrarea, după anumite reguli, a datelor privind starea şi mişcarea elementelor
patrimoniale.
LegislaŃia şi literatura de specialitate economico-financiară este necesar să fie
bine cunoscute înainte de programarea şi desfăşurarea fiecărei activităŃi.
Programarea (planificarea) şi previziunea diferitelor activităŃi se bazează atât
pe cunoaşterea legislaŃiei şi literaturii economico-financiare, cât şi pe informaŃiile
obŃinute din evidenŃa economică.
Cele mai importante programe la nivel de întreprindere sunt următoarele: programe de
investiŃii, programe de aprovizionare şi vânzare de bunuri, servicii şi de marketing,
programe de cercetare-dezvoltare, programe de producŃie şi costuri, programe de
salarizare şi personal, programe de impozite, taxe şi alte sume cuvenite bugetului statului
şi celui de asigurări sociale,bugetul de venituri şi cheltuieli al unităŃii programe de
creştere sau descreştere a capitalurilor proprii, programe de încasări şi plăŃi, de credite
obŃinute şi acordate, etc
Pentru aplicaŃiile de proiectare există o legătură directă între obiectele lumii reale
şi entităŃile definite, datele sunt ierarhizate, manipulându-se legăturile între obiect şi
componentele sale.
Mijloacele de prelucrare a datelor economice reprezintă ansamblul de tehnici şi
echipamente de culegere, prelucrare şi transmitere a informaŃiilor.
Metodele şi procedurile de prelucrare referă partea logică a prelucrării datelor în
vederea obŃinerii informaŃiilor. EvoluŃia tehnicii de calcul a adus o varietate de procedee
pentru obŃinerea şi prelucrarea datelor, în vederea utilizării lor în gestionarea unei unităŃi
economice. Mai mult, se poate asigura simularea evoluŃiei diverşilor indicatori sub
acŃiunea factorilor de influenŃă.

5
 Studiul mediului concurenŃial demarează prin stabilirea firmelor concurente,
incluzând organizaŃiile care intenŃionează să pătrundă pe piaŃă şi producătorii de produse
substitute.
Analiza internă a organizaŃiei, prin implicarea funcŃiei birotice de prelucrare şi
comandă-control, permite managerului să cunoască punctele forte, dar şi cele slabe ale
firmei, elemente care influenŃează puterea competitivă a organizaŃiei.
3. Sistemul informatic
Sistemul Informatic are funcŃia de prelucrare automată a datelor pentru
obŃinerea informaŃiilor necesare procesului de conducere şi pentru informare.
Pornind de la funcŃia sa, sistemul informatic are următoarea structură generală:
• INTRĂRI: totalitatea datelor supuse prelucrărilor;
• PRELUCRĂRI: totalitatea operaŃiilor efectuate asupra datelor pentru
obŃinerea informaŃiilor care stau la baza deciziilor;
• IEŞIRI: rezultatele prelucrărilor efectuate asupra datelor, prin interpretarea
cărora se obŃin informaŃiile care fundamentează deciziile.
Ca arhitectură (model constructiv), sistemul informatic este alcătuit din:
• HARDWARE: Sistemul de calcul (calculator şi echipamente periferice);
• SOFTWARE: Sistemul de Operare (SO): Windows (98,ME,2000,XP), Apple MAC,.
- programe pentru dezvoltarea de aplicaŃii: Sisteme de Gestiune a
Bazelor de Date – SGBD-uri (Access, Fox, etc.) etc.
- limbaje de programare (Visual Basic, C++ etc.);
- programe sau aplicaŃii de utilizator (salarii, contabilitate, secretariat,
conturi clienŃi, valută etc.)
• COLECłII ORGANIZATE DE DATE: Baze de Date – BD;
• SISTEM DE COMUNICAłII: intranet, internet, telecomunicaŃii etc.;
• RESURSE UMANE: personal tehnic, personal de exploatare, utilizatori etc.;
• CADRU ORGANIZATORIC.

6
4. Principii utilizate in proiectarea sistemelor informatice

Desfasurarea unei activitati riguroase si performante de proiectare si realizare de

sisteme informatice de financiar bancare impune respectarea unor principii:

Abordarea globala a problemei de rezolvat. Fiind vorba de reali-
zarea unui sistem informatic al firmei se impune definirea mai intai
a unei solutii globale de informatizare ceea ce va conduce la reali-
zarea unei solutii informatice integrate, stabilirea unei structuri flexi-
bile a sistemului informatic, precizarea prioritatilor in realizarea
componentelor sistemului informatic;

Utilizarea unei metodologii unitare in proiectarea si realizarea sistemului
informatic;

Aplicarea celor mai moderne soiutii si metode de proiectare si reali-
zare a sistemului informatic;

Structurarea sistemului informatic relativ independent de structura
organizatorica din cadrul firmei. Acest lucru va asigura pe de o parte o buna
functionare a sistemului. Daca insa exista particula-ritati deosebite privitoare la
modul de organizare a activitatii si acest lucru se repercuteaza asupra fluxuiui
informational si procesului de prelucrare a datelor sistemul informatic va trebui sa
raspunda acestor particularitati;

Participarea nemijlocita a viitorului beneficiar la activitatile de analiza,
proiectare si implementare a sistemului informatic. O astfel de participare
asigura formularea clara a specificatiilor necesare proiectarii si validarea
esalonata a solutiilor propuse de proiectant toate acestea asigurand in final un
produs care sa corespunda
deplin cerintelor utilizatorului;

Respectarea cadrului legislativ. Fiind vorba de sisteme informatice
devine obligatorie realizarea evidentelor in cadrul
firmei, calcularea indicatorilor si intocmirea lucrarilor de sinteza in
conformitate cu reglementarile aflate in vigoare.

7
5. Arhitectura sistemelor informatice

Arhitectura sistemului informatic reprezinta solutia generica privitoare la
procesele de prelucrare a datelor ce trebuie sa se realizeze si modul de integrare a
datelor si prelucrarilor.

In definirea arhitecturii sistemului informatic s-au cristalizat in timp trei strategii
 Strategia descendenta
 Strategia ascendenta
 Stategia mixta

Strategia descendenta numita top-down pleaca de la principiul descompunerii
sistemului informatic complex in componente prezentand o complexitate mai
redusa parcurgandu-se succesiv mai multe nivele de detaliere in cadrul fiecarei
componente definite

Strategia ascendenta numita si bottom up promoveaza initiativa la nivelul fiecarui

domeniu. Strategia ascendentă (botton-up) este opusă metodei top-down având la bază
principiul agregării şi constă în identificarea de jos în sus a componentelor unui sistem şi

8
asamblarea succesivă a modulelor definite pe diferite nivele ierarhice şi a relaŃiilor dintre
acestea astfel încât se ajunge la un singur modul corespunzător sistemului. Combinată cu
metoda ascendentă a condus la „ strategia mixtă”care îmbină elemente de la ambele
promovează iniŃiativa la nivelul fiecărui domeniu de gestiune. Această strategie
presupune identificarea problemelor organizaŃiei şi a posibilităŃilor oferite pentru
definirea proiectelor. Se dezvoltă soluŃii informatice la nivelul fiecărui domeniu de
gestiune (contabilitate, comercial, producŃie etc.) fără a exista o soluŃie cadru şi o
arhitectură definită pentru sistemul informatic global la nivel de organizaŃie.
Sistemele de gestiune se realizează şi exploatează independent pe măsura
finalizării lor, răspunzând cerinŃelor de gestiune ale domeniilor pentru care au fost
realizate, urmând ca ulterior să se treacă la integrarea acestora în cadrul sistemului
informatic global al organizaŃiei. Metoda cere un timp mai scurt şi este mai ieftină, având
avantajul de a se şti cu exactitate problemele cu care se confruntă unitatea. Datorită lipsei
unei strategii unitare în plan hardware şi software, a unei soluŃii unitare de proiectare şi
realizare există riscul unui grad redus de integrare a subsistemelor de gestiune cuprinse în
cadrul sistemului informatic al organizaŃiei. Ca dezavantaj se consideră lipsa unui punct
de vedere de ansamblu, la nivel de unitate.

Stategia mixta reprezinta o combinare a celor doua strategii, descendenta si
ascendenta, retinandu-se punctele lor forte. În această abordare se optează pentru o
definire a componentelor sistemului informatic în conformitate cu cerinŃele strategiei
descendente, urmând ca proiectarea, realizarea şi integrarea acestor componente să se
realizeze urmând cerinŃele strategiei ascendente.

6. Strategii de dezvoltare a sistemelor informatice

Considerăm că dacă s-ar porni de la conceptul filosofic de “ExistenŃă
Fundamentală”, ceea ce DeMarco numea „forma solidului" - cu trimitere la obiectele
palpabile - ajungem la SubstanŃă, Energie, InformaŃie. InformaŃia este văzută de
DeMarco, în 1982, ca fiind posibil de abordat prin trei perspective specifice sistemelor
informaŃionale sau prin trei dimensiuni: date, funcŃii, comportament.
Datele sunt surprinse prin prisma structurii lor sub formă de atribute şi înseamnă,
de fapt, ceea ce sistemul are stocat şi-şi poate „reaminti" oricând despre fenomenele sau
procesele studiate. Ele reflectă structura statică a sistemului informaŃional.

9
 FuncŃiile scot în evidenŃă, în mod limitat, ceea ce face sistemul. Ele pot fi văzute
şi ca procese, întrucât elementele sistemului despre care se păstrează datele de rigoare
sunt supuse unor transformări funcŃionale, prin intermediul proceselor.
Comportamentul este invocat pentru a reda o altă modalitate de percepŃie a
sistemului, tot limitată, pentru surprinderea stărilor comportamentale prin care acesta ar
trece, reliefându-se influenŃa evenimentelor, ceea ce ar sugera dinamica lui.
Pornind de la aspectul tridimensional al sistemelor informaŃionale, se poate afirma
că acestea pot fi axate pe una, două sau toate cele trei dimensiuni, ceea ce îndreptăŃeşte pe
Whitmire25 să spună că, atunci când aplicaŃiile sunt net dominate de una dintre cele trei
dimensiuni, ele sunt data-strong, function-strong sau control-strong. Tot el adaugă că,
atunci când dimensiunea dominantă, nu este clară, ele pot fi considerate aplicaŃii hibride.
Preluând comportamentul hologramelor, la care însă nu face nici o referire, reŃine că
obiectele luate individual păstrează caracteristicile întregii aplicaŃii.

Strategia descompunerii funcŃionale (orientate-funcŃii)

Strategia descompunerii funcŃionale a sistemelor informatice, care este orientată pe
funcŃii, nu poate să conducă la conceperea unor sisteme suficient de stabile. Totuşi, pe
lângă problema complexităŃii, stabilitatea arhitecturii programelor este una din
principalele mize ale acestei abordări. În acest sens, trebuie amintit conceptul de
independenŃă funcŃională care stă la baza proiectării arhitecturale a programelor.
Descompunerea funcŃională este cea care anunŃă apariŃia proiectării structurate şi
analizei structurate. Fiecare funcŃie este descompusă în subfuncŃii etc., până când se obŃin
forme uşor de transpus în instrucŃiunile limbajelor de programare.
Descompunerea funcŃională (DF) este văzută ca o sumă de funcŃii, subfuncŃii şi
interfeŃe funcŃionale, sub forma unei ecuaŃii:
DF = FuncŃii+ SubfuncŃii + InterfeŃe funcŃionale.
Metoda are ca puncte tari simplitatea, obŃinerea destul de uşoară a cerinŃelor
utilizatorului şi generarea de soluŃii pe diferite niveluri de abstractizare (sistem,
subsistem, funcŃie, subfuncŃie).
Ca puncte slabe putem considera concentrarea eforturilor spre funcŃii (ceea ce
conduce la culegerea multor date redundante), inexistenŃa unor reguli precise de

10
descompunere şi evidenŃierea anevoioasă a interacŃiunilor non-ierarhice din sistemele
complexe.
Strategia fluxurilor de date (orientate-proces)
O altă metodă şi în acelaşi timp o altă modalitate de reprezentare a domeniului
problemei şi responsabilităŃilor sistemului printr-o specificaŃie tehnică este metoda
orientată spre procese, deseori descrisă ca „analiza structurată".
EcuaŃia metodei este:
Metoda fluxului de date = Fluxul (şi controlul) datelor + Transformările (şi
controlul)datelor + Stocarea (şi controlul) datelor + Terminatori + SpecificaŃii de
proces + DicŃionarul datelor.
Prin această metodă, analiştii efectuează reprezentarea lumii reale prin linii ale
fluxurilor de date şi cerculeŃe pentru procese. În timp, s-au conturat două strategii în
analiza structurată. Se vorbeşte despre o metodă „veche" şi despre o metodă „modernă"
de analiză structurată, lansată în dezbateri la nivelul anului 1982 şi prin materialele
editate în 1984 - reprezentative fiind lucrările autorilor McMenamin&Palmer, din 1984,
şi a lui Yourdon, “Analiza modernă structurată” din 1989. În ultima variantă sunt definite
cu claritate evenimentele din lumea reală la care sistemul trebuie să răspundă, o formă
embrionară a actualelor interacŃiuni dintre utilizator şi sistem, bazate pe mesaje. Sunt
incluse de asemenea, fluxurile datelor şi transformările la nivel inferior prin intermediul
dicŃionarului de date, respectiv al specificaŃiilor proceselor.
Cum metoda orientată pe procese are încă un mare grad de asemănare cu
descompunerea funcŃională, criticile metodei descrise anterior se reportează şi în cazul de
faŃă. Oricum, după cum se va vedea ulterior, multe elemente ale acestei metode sunt
preluate de către metodele orientate-obiect.
Strategii orientate spre informaŃii (orientate-date)
Majoritatea specialiştilor consideră ca se poate obŃine un plus de stabilitate dacă
structura propriu-zisă a sistemului informatic se limitează la descrierea datelor şi a bazei
de date, presupunându-se că tipurile de date utilizate în cadrul organizaŃiei sunt supuse
mai puŃin schimbării decât prelucrările din sistem.
Această orientare a dus la apariŃia strategiei orientate pe date. Chiar dacă
valoarea datelor se schimbă în mod constant, structura datelor nu presupune modificări

11
esenŃiale, dacă ea a fost bine proiectată de la început. De regulă, clasele de entităŃi în
legătură cu care se vor memora datele în sistem nu se schimbă, rareori fiind necesară
introducerea unei noi clase de entităŃi, caz în care structura nu suferă transformări
esenŃiale, ci presupune doar adăugarea noii clase la structura existentă.
Termenul „obiect", folosit în modelarea informaŃiilor sau modelarea semantică a
datelor, este un simbol prin care se reprezintă una sau mai multe „ocurenŃe" (cazuri) ale
„entităŃilor" lumii reale. Metoda este identificată prin următoarea ecuaŃie28:
Modelarea informaŃiilor = Obiecte + Atribute + RelaŃii + Supertipuri/Subtipuri
+Obiecte asociative.
Coad şi Yourdon spun că şi în acest caz se poate vorbi despre existenŃa a două
strategii. Strategia veche se bazează pe conceperea listei atributelor, gruparea lor în
obiecte, stabilirea de relaŃii între „ocurenŃe" (cazuri), folosirea supertipurilor/subtipurilor
pentru extragerea atributelor comune şi definirea obiectelor asociative pentru reliefarea
relaŃiilor sigure.
Noua strategie este destul de apropiată de precedenta, cu excepŃia primului pas,
care îşi propune mai întâi să identifice obiectele lumii reale şi apoi urmează descrierea lor
cu ajutorul atributelor. Specialiştii apreciază salturile înregistrate însă, în acelaşi timp, fac
inventarul conceptelor inexistente, cum ar fi: servicii, mesaje, moştenire, structură.
Strategii orientate-obiect
Strategia orientată-obiect pune în centrul atenŃiei noŃiunea de obiect, considerată
drept o entitate care se poate distinge dintre alte entităŃi şi care are o semnificaŃie în
contextul aplicaŃiei modelate. Obiectul asociază datele şi prelucrările în cadrul aceleiaşi
entităŃi, rămânând vizibilă doar interfaŃa obiectului.
Un obiect comportă un aspect static, reprezentat prin intermediul unor variabile de
stare numite atribute şi un aspect dinamic, reprezentat de comportamentul obiectului.
Aspectul static este ascuns de aspectul dinamic.
Sintagma „orientat-obiect" este destul de greu de definit din cauza accepŃiunilor
diferite care i s-au atribuit de diverse discipline. Numai în domeniul informaticii există
vreo trei variante: una folosită în modelarea informaŃiilor, alta în programare şi a treia
este cea de faŃă, utilizată în analiza şi proiectarea sistemelor. Fiind un domeniu relativ

12
nou, este normal să existe o mare diversitate de opinii până şi asupra termenului „obiect".
EcuaŃia ce caracterizează metoda, o redăm în cele ce urmează29:
Orientat-Obiect = Clase şi Obiecte + Moştenire + ComunicaŃii prin mesaje.
Conceptele de obiect şi clasă sunt interdependente: un obiect aparŃine unei clase
(este o instanŃă a clasei), iar o clasă este o grupare logică a obiectelor care au aceeaşi
structură şi un
comportament similar. Un obiect este o abstractizare a datelor elementare şi
poate fi descris astfel30:
Obiect = Identitate + Comportament + Stare.
Identitatea obiectului se realizează printr-un identificator al obiectului, care este
un atribut invariabil ce permite ca obiectul să fie referit independent de celelalte obiecte.
Identificatorul este generat de sistem la crearea obiectului.
Starea obiectului este o valoare care poate fi simplă (de exemplu, un literal) sau
structurată (de exemplu, o listă). In ultimul caz, ea poate fi compusă din valori simple,
referinŃe la alte obiecte sau valori care ele însăşi sunt structurate.
Comportamentul unui obiect este definit printr-un set de operaŃiuni ce-i pot fi
aplicate şi este descris în clasa căreia îi aparŃine obiectul.

Concluzionând, putem afirma că obiectul este o abstractizare a datelor elementare,
caracterizat printr-un identificator unic, invariabil, o clasă căreia îi aparŃine şi o
stare reprezentată printr-o valoare simplă sau structurată.

Deschiderea catre utilizarea tehnologiilor moderne este urmarea intelegerii
necesitatilor bancare:

Regandirea relatiei cu clientii

Reorganizarea interna a activitatii privind procesele legate de exploatarea
si limitarea restrictiilor spatio-temporale in raport cu clientii

Capitalizarea si difuzarea cunostintelor in cadrul bancii

Schimbarea planului managementului bancar

Cresterea operativitatii, sigurantei si eficientizarii tranzactiilor intra si
interbancare

Alinierea la standardele europene si mondiale privind efectuarea
tranzactiilor bancare si a schimbului de informatii

13

Arhitectura noilor sisteme informatice bancare are la baza o noua abordare
caracterizata prin orientarea pe client, nu pe conturi sau produse si vizeaza in
principal obiectivele bancii:
introducerea la timp a noilor produse si servicii specificate in strategia de dezvoltare,
posibila datorita parametrizarii si flexibilitatii deosebite ale solutiei
standardizarea produselor oferite prin intermediul tuturor canalelor de distributie,
posibila datorita modului de lucru centralizat
automatizarea tranzactiilor complexe, posibila prin caracteristica de STP a solutiei
posibilitatea de a raspunde la cerinte unicat venite din partea clientilor individuali sau
corporate, utilizarea de valori specifice pentru parametrii definiti la nivel de client,
contract sau chiar operatiune
minimizarea riscurilor operationale, prin utilizarea politicilor multiple de securitate si
a urmaririi modificarilor din sistem
capacitatea de procesare a volumelor mari de tranzactii, prin scalabilitatea dovedita a
solutiei
oferirea de servicii bancare non-stop, prin posibilitatea de a genera tranzactii in regim
24x7 integrarea tuturor proceselor bancare intr-un singur sistem, prin functionalitatea
extinsa, end-to-end a solutiei.

OPERATIUNI

Conturi curente

Home banking

Decontari electronice

Depozite

Certificate de depozit

Carduri

Casa

Alte operatii (decontari facturi, incasari facturi etc)

CLIENTI, subsistem ce permite actualizarea permanenta a datelor privind clientii
bancii, prin gestiunea unica a clientilor

CREDITE, asigurand gestiunea contractelor de credite cu doua module

Gestiunea riscului

Gestiunea propriu-zisa

JURIDIC, dezvoltat pe doua module

Legislativ

Gestiunea creditelor litigioase

14

CONTABILITATE, cu urmatoarele functiuni de baza:

Actualizarea planului de conturi

Definirea conditiilor de dobanda la nivelul conturilor sintetice si analitice

Definirea monografiei de operatiuni bancare

Deschiderea si inchiderea conturilor interne

Calculul, inregistrarea si plata/incasarea dobanzilor

Situatii contabile de sinteza si raportare

PERSONAL, asigurand gestiunea personalului si calculul salariilor

MARKETING, oferind informatii specifice activitatii de conducere

MANAGEMENT BANCAR, subsistem specializat in determinarea si
monitorizarea indicatorilor de rating bancar

7. Ciclul de viaŃă a unui sistem informatic

Sistemul informatic (SI) ca orice entitate a lumii reale prezintă propriul său ciclu
de viaŃă. Ciclul de viaŃă presupune parcurgerea unor etape, descompunerea la rândul lor
în faze, care asigură: conceperea, realizarea, implementarea, exploatarea şi întreŃinerea
sistemului.
Diferitele abordări au condus la precizarea unor faze comune ale ciclului de viaŃă:
1. Definirea cerinŃelor utilizatorului
2. SpecificaŃia cerinŃelor sistemului
3. SpecificaŃia cerinŃelor software
4. Proiectarea generală
5. Proiectarea de detaliu
6. Realizarea componentelor SI
7. Testarea componentelor
8. Integrarea componentelor
9. Implementarea şi testarea produsului
10. Exploatarea şi întreŃinerea sistemului
11. Dezvoltarea SI

15
 8. Strategii de parcurgere a etapelor din ciclul de viaŃă în realizarea sistemelor
informatice
Pornind de la ciclul de viaŃă al sistemelor spre cel al obiectelor, surprindem o
sintagmă esenŃială în activitatea de analiză şi proiectare a sistemelor, respectiv ciclul de
viaŃă al dezvoltării sistemelor (CVDS) sau ciclul dezvoltării sistemelor (CDS).
Ciclul de viaŃă al dezvoltării sistemelor este „o metodologie comună de dezvoltare
a sistemelor din multe organizaŃii, caracterizată prin câteva faze care marchează evoluŃia
eforturilor de analiză şi proiectare a sistemelor".
Prin parcurgerea materialelor de specialitate, am putut constata că numărul
fazelor/etapelor variază de la trei (de exemplu: analiză, proiectare, implementare) la peste
douăzeci. Firesc, în cel de-al doilea caz, nici simpla enumerare a lor nu este edificatoare.
Totuşi, s-ar putea formula o concluzie: în fazele incipiente de abordare a sistemelor,
numărul etapelor se situa la aproximativ şase. Ele erau descompuse pe activităŃi,
subactivităŃi, operaŃiune firească, apreciem noi, datorită influenŃei gândirii bazate pe
descompunerea funcŃională, care era la modă. Prin trecerea la orientarea-procese şi
orientarea-date, considerăm că s-au înregistrat două fenomene: diversificarea etapelor;
revizuirea modelului sub care se manifestă ciclicitatea.
Datorită marii diversităŃi a opiniilor, considerăm binevenită o descriere sumară a
mai multor modele, cu atât mai mult cu cât în literatura noastră subiectului de faŃă nu i se
acordă importanŃa cuvenită.
Modelul cascadă este unul de referinŃă, asigurând trecerea de la o etapă la alta,
ce-i drept mai mult teoretică, în ordine secvenŃială. Realitatea a demonstrat că
parcurgerea etapelor/fazelor într-o astfel de ordine nu este o regulă, întrucât, de cele mai
multe ori, se înregistrează reveniri la etapele anterioare sau parcurgerea în paralel a unora
dintre ele.

16
 Modelul V este o variantă a modelului cascadă, prin care se introduc conceptele
de sistem şi componente (subsisteme), aplicându-se teste explicite la un sistem ierarhic
pentru creşterea controlului asupra modului în care se desfăşoară etapele.
Tocmai această înlesnire constituie o latură a literei V. Prima este latura din
stânga, parcursă descendent, şi conŃine treptele propriu-zise, iar cea de-a doua latură, din
dreapta, se parcurge ascendent, pe ea realizându-se verificările şi validările elementelor
create anterior. Acest model punctează cu mai multă claritate separările dintre ceea ce
implică participarea utilizatorului, modelul arhitectural şi cel al implementării.
Utilizatorul este implicat doar în fazele din partea superioară a V-ului.

Modelul incremental, este o altă variantă a modelului cascadă care promovează ideea
proiectării şi realizării independente a componentelor după definirea arhitecturii globale a
SI. Proiectarea şi realizarea SI se face astfel în conformitate cu principiile metodelor top-

17
down. Sistemul va putea fi livrat beneficiarului şi etapizat pe măsura realizării
componentelor (în funcŃie de priorităŃile formulate de beneficiar) dar, într-o astfel de
abordare pot apărea dificultăŃi legate de integrarea componentelor în sistemul final.

Modelul spirală este lansat de unul dintre specialiştii cu preocupări mai vechi
legate de ciclul de viaŃă, B.W. Boehm. Acesta s-a ocupat de aşa-zisele modele
tradiŃionale încă din anul 1981, iar în 1986 anunŃă modelul spirală şi publică rezultatele
cercetării sale în 1988. El se bazează pe două convingeri: natura iterativă a dezvoltării şi
nevoia de planificare şi evaluare a riscurilor fiecărei iteraŃii; deficienŃa înregistrată la
modelul V, în care validarea se efectuează prea târziu, îl face să propună, dimpotrivă,
realizarea acesteia cât mai devreme posibil, de cât mai multe ori, prin construirea
prototipurilor, conform modelului simplificat din figura de mai jos:

In principiu, modelul evolutiv constă în efectuarea unei investigaŃii iniŃiale, elaborarea

unei strategii pentru descompunerea proiectului în părŃi/segmente, fiecare cu o valoare
deosebită pentru client. Ele sunt realizate şi livrate în mod iterativ şi contribuie la sporirea
treptată a performanŃelor sistemului. Formele obŃinute pentru părŃile componente nu sunt
foarte puternic detaliate, lăsându-se loc pentru adaptări şi modificări ulterioare.

18
 Modelul tridimensional a fost lansat în FranŃa şi susŃinut de adepŃii acestei şcoli.
El a fost introdus odată cu metoda Merise. SusŃinători ai modelului (Bouzeghoub,
Gardarin, Valduriez) aceştia consideră că este singurul model care Ńine cont de aspectele
impuse de bazele de date, prin încorporarea clară a nivelurilor ANSI/SPARC. Modelul
surprinde dezvoltarea sistemelor printr-o redare grafică bazată pe trei axe, descriind ciclul
de viaŃă al sistemului, ciclul de viaŃă al proiectului şi ciclul de viaŃă al abstractizării .

19
Modelul X îşi propune să extindă aria performanŃelor obŃinute prin modelele cascadă şi
V, ambele fiind considerate ca exemple de modele ale procesului de dezvoltare care, la
rândul lui, ar fi parte integrantă a unui proces mai larg, al livrării sistemelor, pentru care
Hodgson, în 1991, propune un model special. Modelul X exprimă două mari categorii
de cicluri de activităŃi: una derulată înainte (forward activity), care sintetizează sistemul
nou (sau modificat) şi o activitate derulată înapoi (reverse activity) pentru dobândirea
sistemelor şi a componentelor lor, pentru catalogarea diverselor modele, arhitecturi şi
componente ale activităŃii finalizate pentru o posibilă reutilizare. Ingineria preventivă
(forward engineering) de la nivelul fiecărui stadiu al procesului încearcă să reutilizeze -
prin selecŃie, adaptare, rafinare - acumulările anterioare care se regăsesc în bibliotecile
sistemelor. Schematic, modelul X este prezentat în figura de mai jos.

20
 Modelul fântână arteziană îşi are originea în modelul spirală şi în altele care au
reprezentat îmbunătăŃiri ale acestuia. Ne referim la modelul spirală ierarhic şi vârtej de
apă.

21
Tema - exemplu Etape de proiectare în ciclul de viaŃă al unui SI.
1. Proiectarea generală (conceptuală) a SI

În conceperea şi realizarea SI, proiectarea generală (PG) deŃine o

pondere deosebită, deoarece aceasta defineşte structura şi funcŃionalitatea
noului sistem în raport cu obiectivele şi cerinŃele solicitate de către
beneficiar.

Etapa de PG a unui SI are ca obiectiv elaborarea concepŃiei logice a

SI, adică defineşte SI atât structural, cât şi funcŃional.

Cu alte cuvinte, proiectarea generală asigură modelarea conceptuală a

noului sistem, inclusiv stabilirea componentelor de sistem (subsisteme şi
unităŃi funcŃionale), a legăturilor dintre acestea şi a funcŃionalităŃii
structurii sale în aşa fel, încât întregul sistem să acŃioneze ca un tot unitar.
Astfel, la etapa de proiectare generală sunt definite obiectivele noului SI, se
determină structura bazei informaŃionale, se asigură formalizarea
atributelor de intrare şi se proiectează organigrama noului sistem.

Organizarea şi conducerea proiectării generale presupune stabilirea

unui colectiv pentru realizarea proiectării generale şi elaborarea unui plan
de realizare a acestei etape. Managerul de proiect asigură planificarea,
organizarea, coordonarea şi urmărirea întregii activităŃi, elaborează
graficul de desfăşurare a fazelor proiectării generale, stabileşte, pentru
fiecare fază, termenul de realizare, obiectivele specifice şi personalul
implicat.
PG presupune folosirea unor variante de abordare, utilizate în
funcŃie de următorii factori:
• Complexitatea obiectivelor stabilite;
• Aria de cuprindere a noului SI;
• PosibilităŃile de modificare a ieşirilor solicitate de unitatea
beneficiară (UB).
Aceste variante sunt bazate pe aplicarea anumitor principii, şi anume:
• IEŞIRI – INTRĂRI;
• INTRĂRI – IEŞIRI;
• MIXTĂ.

22
 Varianta IEŞIRI – INTRĂRI începe cu precizarea obiectivelor
noului SI, în raport cu cerinŃele UB. Obiectivele sunt concretizate în ieşirile
sistemului ale căror atribute formează baza informaŃională (BI) de ieşire
care este analizată în raport de modul de obŃinere a atributelor de ieşire, în
scopul definirii BI de intrare.
Prin urmare, această variantă presupune parcurgerea următoarelor
faze:
• Definirea obiectivelor SI;
• Definirea ieşirilor SI;
• Definirea BI;
• Formalizarea atributelor, care include:
o Codificarea atributelor;
o Adaptarea documentelor de intrare.
• Definirea structurii funcŃionale a SI;
• Elaborarea documentaŃiei PG.
Avantajul acestei variante se explică prin furnizarea unui conŃinut
complet al BI de intrare, determinat strict pe baza ieşirilor solicitate.
Dezavantajul – imposibilitatea obŃinerii de noi rapoarte sau
indicatori. În cazul schimbării conŃinutului şi setului de ieşiri
informaŃionale de către UB, este necesară o reexaminare a conŃinutului BI
de intrare.
Varianta INTRĂRI – IEŞIRI porneşte de la determinarea
obiectivelor, iar apoi se determină mulŃimea intrărilor necesare, structurate
sub forma BI de intrare, care este analizată în vederea BI de ieşire.
Adică, această variantă include următoarele faze:
• Definirea obiectivelor SI;
• Inventarierea tuturor atributelor de intrare şi a legăturilor sau
corespondenŃelor dintre acestea pe baza documentelor de intrare
utilizate;
• Definirea BI de intrare;
• Formalizarea atributelor, care include:
o Codificarea atributelor;
o Adaptarea documentelor de intrare.
• Definirea ieşirilor SI;

23
 • Definirea structurii funcŃionale a SI;
• Elaborarea documentaŃiei PG.
Avantajul acestei variante – flexibilitatea conŃinutului BI de intrare în
condiŃiile apariŃiei de modificări ale ieşirilor informaŃionale.
Dezavantajul – BI este supradimensionată, ceea ce implică timp mare
de realizare , costuri ridicate de proiectare, realizare şi o sporire a
complexităŃii prelucrărilor SI.
Varianta MIXTĂ are în vedere definirea modelului conceptual al SI
folosind avantajele celor două variante prezentate.
Varianta include următoarele faze:
• Definirea obiectivelor SI;
• Definirea iniŃială a BI;
• Formalizarea atributelor de intrare şi ieşire, care include:
o Codificarea atributelor;
o Adaptarea documentelor de intrare;
o Definirea BI de ieşire şi stabilirea ieşirilor prezente
şi previzibile;
• Redefinirea BI iniŃiale şi stabilirea structurii finale a
acesteia;
• Definirea structurii funcŃionale a SI;
• Elaborarea documentaŃiei PG.
Analizând variantele prezentate rezultă că, fazele PG sunt comune
tuturor variantelor de abordare, dar succesiunea lor este diferenŃiată de la
o variantă la alta. În general, se optează pentru una dintre variante, având
în vedere:
• Obiectivele SI;
• Dimensiunea SI;
• Volumul atributelor BI;
• Costurile şi termenul de realizare a SI, etc.
În concluzie, buna desfăşurare a etapei de proiectare conceptuală
obligă conducerea unităŃii beneficiare să analizeze pe parcurs stadiul
lucrărilor, să sintetizeze toate cerinŃele utilizatorului într-un mod cât mai
eficient, să evalueze toate variantele, să selecteze şi să avizeze cea mai bună
cale de obŃinere a informaŃiilor necesare.

24
2. Proiectarea de detaliu a sistemului informatic.

Obiectivul proiectării de detaliu (PD) presupune transformarea

modelului conceptual al noului sistem într-un model operaŃional (tehnic, de
detaliu), în concordanŃă cu un sistem de gestiune a datelor şi un sistem
electronic de calcul.
Proiectarea de detaliu este una din cele mai dificile etape a ciclului
de viaŃă al sistemului informatic, de aceea necesită un deosebit efort
managerial privind organizarea, urmărirea şi controlul activităŃilor vizate.
Acesta presupune organizarea colectivelor de specialişti şi repartizarea
sarcinilor, atribuŃiilor şi responsabilităŃilor, supravegherea activităŃilor de
proiectare de detaliu a unităŃilor funcŃionale şi unităŃilor de prelucrare,
supravegherea termenelor, respectării metodologiilor de elaborare,
evaluarea soluŃiei optime de gestiune a datelor şi a sistemului electronic de
calcul, validarea rezultatelor obŃinute în raport cu cerinŃele, normativele şi
standardele prestabilite.
Astfel, printre activităŃile etapei de PD pot fi enumerate
următoarele:
• Proiectarea ieşirilor şi intrărilor SI;
• Proiectarea BI;
• Definirea sistemului de fişiere şi / sau bazei de date;
• Realizarea programelor;
• Organizarea procesului tehnologic de prelucrare a datelor.

Notă: Caracteristica detaliată a acestor activităŃi, va fi prezentată în tema

ce va urma.

9. Implementarea şi exploatarea sistemului informatic.

În literatura de specialitate se menŃionează că etapa de implementare

este “piatra de încercare” a sistemului informatic. Obiectivul implementării
presupune testarea (verificarea) sistemului proiectat şi realizat fizic în
condiŃiile reale din unitatea beneficiară şi aducerea la stadiul de funcŃionare
şi exploatare efectivă.
25
 Această etapă include multe aspecte specifice care impun deosebite
activităŃi manageriale, materializate prin planificarea implementării şi prin
asigurarea condiŃiilor organizatorice, financiare, materiale, informaŃionale şi
informatice necesare implementării, inclusiv asigurarea operativităŃii,
calităŃii şi acurateŃei datelor de intrare. De asemenea, aceste activităŃi includ
şi verificarea performanŃelor sistemului informatic proiectat. Elaborarea
planului de implementare asigură repartizarea în timp a lucrărilor, resurselor
şi sarcinilor personalului care realizează punerea în funcŃiune a sistemului
proiectat. De asemenea, se stabileşte succesiunea procedurilor şi activităŃilor
presupunând realizarea implementării şi conversiei în condiŃii de maximă
eficienŃă şi minime de timp.
Exploatarea curentă şi menŃinerea în funcŃiune a sistemului
informatic include activităŃile vizând utilizarea propriu-zisă a sistemului
informatic din unitatea beneficiară şi activităŃile de perfecŃionare şi
menŃinere în stare funcŃională şi operaŃională a acestuia, până la înlocuirea
sa cu un alt sistem informatic mai performant, adică până la finele ciclului
de viaŃă al sistemului.

Exemplu ConcepŃia şi optimizarea sistemelor informatice financiar

bancare
ConcepŃia şi optimizarea sistemelor informatice financiar bancare trebuie să
se realizeze pe 3 niveluri:
- decizional
- datawarehouse & reporting
- front office – back office

1. Decizional (nivelul conducerii)

PriorităŃile sunt reprezentate de flexibilitatea structurilor de date, serverele
puternice, prelucrările au ca scop actualizarea permanentă a datelor.
2. Datawarehouse & reporting (nivelul conducerii)
Datawarehouse
– depozite de date (baze de date multidimensionale)

26
 - permite prin instrumentele sale specifice (analiza multidimensională)
explorarea informaŃiilor stocate şi crearea legăturilor dintre datele
actuale şi cele istorice.
- structurile de date oferă o interogare performantă a cererilor multiple.
Exemplu: Orice bancă dispune de o colecŃie mare de date despre clienŃii
săi, dar este gestionată dispersat.
3. Front office / Back office
Front office
– relaŃia clientului cu banca (telefon, suport de hârtie, e-mail, web)
- interfaŃa utilizatorului pentru operaŃiuni de cont curent, gestionarea
portofoliului, asistenŃă
Middle office
- permite circulaŃia datelor în dublu sens reŃinându-le prin două
imagini separate ale datelor
- rolul de bază este a) colectarea, agregarea şi consolidarea
informaŃiilor
b) asigurarea managementului calităŃii
c) asigurarea distribuŃiei informaŃiei şi
raportarea
Back office
- stocarea şi prelucrarea datelor
- locul unde se execută procesele tranzacŃionale
- aici se găsesc aplicaŃiile şi bazele de date
- locul de unde îşi i-a informaŃia Front office-ul

10. DefiniŃia şi conŃinutul metodologiilor

Metodele şi conceptele fundamentale de realizare a sistemelor informatice

financiar bancare au la bază termenii de metodă şi metodologie asociaŃi
direct domeniului financiar bancar. Aceşti termeni se definesc Ńinând cont
de:
- specificul domeniului financiar bancar
- evoluŃia cadrului legislativ
- dinamica activităŃii de informatică şi tendinŃele fundamentale de
evoluŃie a sistemelor financiar bancare.
27
Metoda – reprezintă totalitatea conceptelor, modelelor, nivelelor, etapelor
şi tehnicilor specifice de formalizare necesare pentru definiŃiile, listele,
comunicaŃiile, datele şi prelucrările specifice unui sistem informatic
financiar bancar.
Metodologia – reprezintă setul finit particular definitoriu al unei metode
prin intermediul unui sistem coerent de formulare şi/sau de procese
informatice prin care se modelează şi formalizează unu sistem informatic
financiar bancar.
Metodele de proiectare se pot clasifica în trei mari categorii: metode
structurate, metode sistemice şi metode orientate obiect.
Metodele structurate sau ierarhice folosesc descompunerea progresivă
descendentă top-down. ConcepŃia constă în crearea unui ansamblu unitar în
interacŃiune, având fiecare o funcŃie clar definită.
Avantajele acestor metode constau în simplitatea şi buna adaptare la
cerinŃele utilizatorului.
Dezavantajele pornesc de la conceperea sistemelor informatice conform
cerinŃelor analizei funcŃionale, ceea ce determină un efort de analiză şi
proiectare mai mare asupra prelucrărilor în condiŃiile în care acestea sunt
cele mai supuse modificări în timp, iar modelarea datelor este trecută în
planul secund.
Cea mai reprezentativă dintre metode este SADT (Structured Analisys and
Design Tehnique).
Metodele sistemice permit vizualizarea şi înŃelegerea organizării datelor.
Specific acestor metode este utilizarea teoriei sistemelor în abordarea
întreprinderii. Sistemul informatic este abordat sub două aspecte
complementare – datele şi prelucrările – analizate şi modelate independent,
reuniunea lor făcându-se cât mai târziu posibil.
Metodele sistemice acordă o mai mare importanŃă datelor care trebuie să
respecte următoarele niveluri de abstractizare:
- Nivelul conceptual
- Nivelul logic
- Nivelul fizic.

Nivelul conceptual are ca obiectiv identificarea regulilor de gestiune şi

definirea modelului conceptual al datelor şi prelucrărilor.
28
 Nivelul logic urmăreşte validarea modelului conceptual al datelor şi
evidenŃierea particularităŃilor organizatorice.
Nivelul fizic fixează reguli de ordin tehnic privitoare la sistemul informatic,
definitivează soluŃia de implementare a modelului datelor şi definirea
procedurilor.

MCD – modelul conceptual al datelor

MLD – modelul logic al datelor

DATELOR

MFD – modelul fizic al datelor

MODELUL

MCP – modelul conceptual al prelucrărilor

PRELUCRĂRILOR MLP – modelul logic al prelucrărilor

MFP – modelul fizic al prelucrărilor

Metodele obiectuale a treia generaŃie de metode de proiectare. Primele

concepte apărute în 1980 privea tehnologia OO (orientate obiect).
Caracteristic acestor metode este faptul că sistemul informatic este gândit ca
un ansamblu de obiecte autonome care se organizează şi cooperează între
ele. Datele şi prelucrările (metodele) se găsesc încapsulate (inaccesibile
celorlalte obiecte) în cadrul aceleiaşi structuri – obiectul.

29
Avantajele metodelor obiectuale sunt reutilizarea componentelor de
program şi posibilitatea utilizării obiectelor complexe.
Dezavantajele acestor metode decurg din aspectul că nu totdeauna realitatea
poate fi reprezentată prin obiecte.
11. MODELAREA CONCEPTUALĂ A DATELOR
Modelul Entitate-Asociere (EA)
Modelul conceptual al datelor este un ansamblu de concepte şi reguli de
combinare a acestora permiŃând reprezentarea realităŃii.
Modelul Entitate-Asociere (EA) urmăreşte obŃinerea unei reprezentări fidele
a realităŃii.
Conceptele de bază utilizate de către modelul EA
ENTITATEA – reprezintă un obiect al realităŃii modelate, caracterizat de o
existenŃă proprie, cu o identitate proprie şi o mulŃime de caracteristici care
exprimă proprietăŃile acestuia.
Ex. În gestiunea produselor finite putem defini entităŃi ca: un produs, un
bon de comandă, , o comandă.
În activitatea de modelare interesul se focalizează pe definirea tipului de
entităŃi aparŃinând problemei de rezolvat şi nu pe entităŃi care reprezintă
realizările tipurilor de entităŃi.
TIP DE ENTITATE – reprezintă un concept generic desemnând mulŃimea
tuturor entităŃilor prezentând aceleaşi caracteristici constructive.
Ex contract, depozit bancar, ordin de tranzacŃionare.
ATRIBUTUL – defineşte o proprietate distinctă a unei entităŃi. Fiecare
atribut are un domeniu, adică un set de valori posibile admise.
Clasificarea atributelor.
a) după complexitate
- elementare (simple) ale căror realizări nu mai pot fi descompuse
Ex. unitate monetară, numărul de cont
- decompozabile (complexe)
Ex data calendaristică se descompune în zi, lună, an
b) după realizări
- obligatorii: să prezinte obligatoriu o valoare NOT NULL
- opŃionale: pot să nu aibă nici-o realizare Ex telefon, e-mail
- monovaloare: are o singură valoare în cadrul entităŃii Ex. CNP, nr
cont
30
 - multivaloare: prezintă mai multe realizări în cadrul aceleiaşi entităŃi
Ex conturi la bănci

Din punct de vedere al rolului pe care îl îndeplineşte acel atribut în

cadrul modelului distingem atribute cu rol de:
a. chei candidate – sunt acele atribute care prin natura lor sunt
susceptibile de a juca rolul de cheie primară sau de identificator în cadrul
unui tip de entitate;
b. cheie primară sau identificator – reprezintă acel atribut sau grup de
atribute, care în cadrul tipului de entitate reuşeşte, prin valorile pe care le ia,
să scoată în evidenŃă o anumită entitate din mulŃimea entităŃilor care
prezintă acelaşi comportament. Rezultă că o cerinŃă esenŃială pentru valorile
pe care le poate lua acest gen de atribut, este ca acestea să fie unice în toată
mulŃimea valorilor pe care le poate lua acel atribut. Ex: atributul cod
numeric personal, prin valorile pe care le poate lua poate conduce la
identificarea în mod unic a entităŃii Georgescu din mulŃimea entităŃilor care
formează tipul de entitate Client;
c. cheie externă – reprezintă un atribut sau o multime de atribute
definite pe aceiasi multime de valori ca şi cheia primară, rolul său fiind
acela de a putea stabili o asociere între două sau mai multe tipuri de entităŃi
care în realitatea modelată, interacŃionează între ele.
Atributul este perceput ca o variabilă care poate lua valori într-un
anumit domeniu.
Putem spune că domeniul reprezintă mulŃimea tuturor valorilor posibile pe
care le poate lua un atribut într-o anumită perioadă de timp.
Câteva precizări cu privire la cheile candidate şi cheile primare sunt
prezentate în cele ce urmează. Să considerăm că în realitatea modelată
putem identifica un tip de entitate numit SocietăŃi comerciale. MulŃimea
atributelor care definesc acest tip de entitate sunt Codul unic de înregistrare,
Numărul de înregistrare, Cod IBAN, Numele societăŃii, Adresa societăŃii.
Modul de reprezentare a acestui tip de entitate

SocietăŃi comerciale

Cod unic de înregistrare

Numărul de înregistrare 31
Cod IBAN
Numele societăŃii
Adresa societăŃii
 MCD-ul care se realizează folosind conceptele prezentate reprezintă, în
mod grafic-schematic, modelul semantic, abstract, al domeniului de
informatizat: organismul economic sau compartimentul specializat al
acestuia pentru care seproiectează sistemul informatic de gestiune. Prin
urmare, la realizarea acestuia se folosesc simbolurile grafice ale conceptelor
de bază, rolul fundamental în construirea acestuia revenind cuplului ET -
AST.
Două cupluri ET - AST, formate din două ET diferite care participă la
aceeaşi AST, definesc un bloc conceptual elementar, care se notează sub
forma ET - AST - ET. MCD-ul construit pentru un domeniu de gestiune al
unui organism economic este practic format dintr-o succesiune de blocuri
conceptuale elementare. Figura 5.2 prezintă schema unui bloc conceptual
elementar dintr-un MCD.

ET (entitate tip) soc ET (entitate tip)

AST (asqcierc tip)
1
Nume AST
(verb) X,Y Nunie ET ,
Nunie F.T (cardinalitate) (substantiv)
X,Y
Nume AT
{atribute tip) r
Nume AT-* (substantiv)
jt i i hut tip) en rol
de identificator

Nume AT
(a tribute tip X (cardinalirate
(substantiv) .: in ii I ■ Nume AT
{cardinalitate) (atribute tip) cu rol
Nunie AT (atribute tip) X (cardinalitate dc idcntificator
(substantiv)
mini mala)
Y (cardinalimtc
mini mala)
RolA roluri ETAsiBtnASTR RolB

32
În modelul EA obiectelor le corespund entităŃi. Obiectele sunt de mai multe feluri:
- obiecte simple cărora le corespund un tip de entitate
- obiecte compozite cu atribute multivaloare
- obiecte compuse ce sunt decompozabile dar au in structura lor tot atribute simple

Asocierea dintre entităŃi arată legătura dintre acestea şi rolul entităŃii participante la legătură.

33
Tipul de asociere reprezintă ansamblul legăturilor cu aceeaşi semnificaŃie dintre entităŃile
aparŃinând la două sau mai multe tipuri de entităŃi .

11. RelaŃii sau asocieri între date

Prin natura a ceea ce reprezintă atributele interactionează, relaŃionează între ele

formând un tot unitar numit entitate. Conceptul care descrie această relaŃie între atribute
poartă denumirea de dependenŃă functională.
DependenŃa funcŃională reprezintă o proprietate a semnificaŃiei sau a semanticii
atributelor, indicând modul în care sunt legate atributele unele de altele.
Numim dependenŃă funcŃională simplă o legătură stabilită între două atribute notate
A şi B apartinand unei relatii R, pentru fiecare valoare cunoscută a atributului A se
antrenează în mod sistematic asocierea aceleiaşi valori pentru atributul B.
Reprezentarea grafică pentru o astfel de dependenŃă funcŃională este simbolizată
printr-o săgeată având o orientare de la atributul A către atributul B.

Un tip aparte de dependenta functionala o reprezinta dependenta functionala

multivaloare.
Fie atributele A, B, si C aflate intr-o relatie R, exista o dependenta functionala
multivaloare atunci cand pentru fiecare valoare a atributului A exista o multime de valori
pentru atributul B si o multime de valori pentru atributul C. Totusi, multimile de valori ale
atributelor B si C sunt independente unele de altele.
Vom reprezenta o dependenta functionala multivaloare printr-o săgeata dubla de la
determinant catre determinat

Legăturile sau asocierile care se stabilesc între mai multe tipuri de entităŃi.
Într-o bază de date relaŃionlă, datele sunt stocate în mai multe tabele, deci este
importnt ca sistemul să poată reuni corect informaŃiile între care există legături. Astfel
relaŃiile se constituie prin precizarea unei legături între un câmp sau o combinaŃie de
câmpuri ale unui tabel şi câmpurile corespunzătoare din alt tabel.

34
 Tipologia asocierilor
1.RelaŃia unu-la-unu (one-to-one), se mai numeşte şi biunivocă. Două tabele unite
printr-o relaŃie unu la unu sunt similare, în practică, cu un tabel care cuprinde toate câmpurile
celor două tabele.
2. RelaŃia unu-la-mulŃi (one-to-many). În practică acest tip de asociere este cel mai des
întâlnit. Într-o asociere de tipul unu-la-mulŃi o înregistrare din tabelul A îi corespunde mai
multe înregistrări din tabelul B, iar unei înregisrări din tabelul B îi corespunde cel mult o
înregistrare din tabela A.
3. RelaŃia mulŃi-la-mulŃi (many-to-many). Acest tip de relaŃie are un caracter mai
general, unei înregistrări din tabelul A îi pot corespunde mai multe înregisrări din tabelul B,
iar unei înregistrări din tabelul B îi pot corespunde, de asemenea, mai multe înregistrări din
tabelul A.
În mod uzual reprezentarea grafică a unei asocieri între două tipuri de entităŃi se simbolizează
printr-o elipsă în care se trece numele asocierii.

A B A B A B

a x a x a x
d b y b y
b y c z c z
e d t d t
c z e w e w

Asociere 1:1 Asociere 1:n Asociere m:n

Strâns legat de asocieri îl reprezintă conceptul de cardinalitate. Putem defini

cardinalitatea ca fiind un cuplu de numere întregi de forma (x,y), care exprimă numărul

35
minim (x) şi numarul maxim (y) de realizări ale unei instanŃe (realizări) ale tipului de entitate
care participa la o asociere.
X se numeşte cardinalitate minimală, desemnând obligativitatea unei realizări de a
participa la o asociere, iar Y se numeşte cardinalitate maximală fiind percepută ca volumul
participării la asociere.

12. CARDINALITATEA

Cardinalilatea unui cuplu entitate-asociere se defineşte ca fiind cuplul de valori

întregi (x,y), astfel încât:
- x reprezintă cardinalitatea minimală şi exprimă numărul minim de realizări ale
legăturii (asocierii) ce există pentru o entitate.
- y reprezintă cardinalitatea maximală şi exprimă numărul maxim de apariŃii ale
corespondenŃei ce pot exista pentru o entitate.
Valorile uzuale sunt:
a) Cardinalitatea minimală 0, va putea exista în cazul în care există entităŃi care să nu
participe la nici-o asociere. Exemplu există potenŃiali clienŃi ai unei firme cărora
încă nu li s-a încheiat poliŃe de asigurare, deci cardinalitate minimală 0.

b) Cardinalitate minimală 1, va putea exista în cazul în care toate realizările tipului de

entitate trebuie să participe la o realizare a tipului de asociere. Exemplu orice
contribuabil aflat în evidenŃa administraŃiei financiare are deschis un rol şi numai
unul singur.

36
c) Cardinalitate maximală 1, arată faptul că toate entităŃile participă la o asociere şi
numai la una. Exemplu numărul de roluri deschis unui contribuabil nu poate fi mai
mare de 1.
d) Cardinalitate maximală n, indică faptul că mai multe entităŃi de un anumit tip
participă la o ascociere. Un client emite unul sau mai multe ordine de plată.

Furnizori 1,n Furnizează 0, n Mat_prime

1,n 0,n
ClienŃi Cumpără Produse
Cantit_cumpărat

37
 13. Reguli de verificare a Modelului Conceptual al Datelor:
1. Unicitatea numelor – se aplică tuturor elementelor ce participă la definirea MCD: ET,
AST, AT, roluri: se elimină din model omonimele şi sinonimele. Ex.: un atribut tip şi o
entitate tip nu pot avea acelaşi nume Produs, entitatea tip o vom numi Produs iar atrib
Nume_produs
2. Unicitatea atributelor (neredondanŃa) – AT trebuie să def o sg ET sau AST
3. Unicitatea asocierilor –fiecărei asocieri îi corespunde o sg. entitate a ET participante la
AST; o asociere nu poate exista decat o sg data intre aceleasi entitati;
4.Atributul tip al unei asocieri tip – este atributul determinat de mai mulŃi determinanŃi, ID
ai ET def de aceştia (caracterizează AST creată între ET definite de determinanŃii săi)
5. Evitarea includerii în MCD a atributelor rezultate din calcule- prez ac tipuri de atribute
se justifică numai dacă sunt relevante şi frecvent utiliz; Ex: la app salarii e utilă def unei entit
tip ( Salarii) care are ca atrib tip calculate Salariul brut, Baza de calcul, Baza de
impozitare, Deduceri personale, necesare pt realiz lunară a stetelor de sal, a unor rap
statistice, întocmirea fişelor fiscale, elib de adeverinŃe, etc.
6.Atributele decompozabile – se pot menŃine în MCD dacă prelucrările nu impun desc lor pe
componente; Ex: atrib tip Adersa într-un Si pt. AdministraŃia Financiară se desc pe
componente deoarece contribuabilii sunt adesea select pe sect, străzi şi nr; în cazul unui Si pt.
secretariatul unei Fac ac atrib nu se desc pt că nu interesează componentele lui.
7. Identificatorii ET – trebuie să fie formaŃi din nr. min de atribute, trebuie sa aiba val unice
si nenule
8. Val NULL (NULL înseamnă nici o valoare/realizare/înregistrare, e dif de zero sau spaŃiu):
- AT cu rol de ID sunt obligatorii ( trebuie să aibă val/realizări);
- există ET care au AT opŃionale ( tel, eMail); în cadrul tipului de entit se pot def subtipuri de
entit care cuprind doar atrib tip specifice acelei submulŃimi de entit;

14. RestricŃii de integritate

RestricŃiile de integritate definesc cerinŃele pe care datele trebuie să le respecte pentru a fi
corecte şi coerente în raport cu realitatea de modelat.
RestricŃiile de integritate surprind următoarele aspecte:
- valorile atributelor entităŃii şi asocierile
- valorile identificatorilor entităŃilor
- rolurile entităŃilor în asocieri
- asocierile stabilite între entităŃi

38
RestricŃiile de integritate pot fi
- statice (se verifică permanent)
- dinamice (privesc evoluŃia în timp a datelor)
Exemple de restricŃii:
• restricŃii de domeniu (condiŃiile valorile admise ale atributelor în cadrul domeniului)
Exemplu Unitatea Măsura – KG, BUC
• restricŃii structurale ( implica două aspecte a)identificarea entităŃilor, b) tipul de
entitate prezentă
• restricŃii de integritate de roluri
• restricŃii de integritate de asocieri

15. MODELAREA CONCEPTUALĂ A PRELUCRĂRILOR (MCP)

Prelucrările reprezintă partea dinamică a sistemului informaŃional.
Pentru modelarea conceptuală, abstractă, a prelucrărilor se foloseşte un model semantic de
reprezentare a prelucrărilor. Acest model se bazează pe semnificaŃia acestora în lumea reală.
Întrebarea la care trebuie să răspundă sistemul informatic economic este CE ? prelucrări au
loc pentru a descrie corect şi complet ceea ce face sistemul vis-a-vis de obiectivul economic
propus.
Modelul conceptual al prelucrărilor prezintă:
- activităŃile desfăşurate de sistemul economic pentru realizarea obiectivului propus
- evenimentele şi succesiunea lor de declanşare a
acestora
- operaŃiile pe care le presupune fiecare dintre Cerere de
activităŃile desfăşurate şi înlănŃuirea lor în timp
- sincronizarea timpului cu legislaŃia şi regulile în credit
vigoare
- rezultatele obŃinute în urma execuŃiei operaŃiilor

Modelul conceptual al prelucrarilor este modelul

"eveniment-rezultat" al metodei Merise, ce repune in
discutie procedurile (elementele) abordate de MCD Operati
formuland pentru fiecare element intrebari de forma:
a
- acest element este indispensabil si ce se intampla daca Reguli de emisiune
il suprimam;
- exista posibilitatea de a-l suprima (atentie la normele
juridice si reglemantarile legale;
- cat costa mentinerea acestui elemet in procedura sau ce
avantaje se obtin din mentinerea lui. Credit
Modelul conceptual al prelucrarilor, vede acordat
intreaga prelucarare ca o succesiune ordonata si logica
de proceduri inlantiute, toate in concordanta stricta cu

39
A si B
legislatia in vigoare (este vorba de un demers tipic de analiza a valorilor).

Nu se poate trece cu vederea impactul utilizarii instrumentului informatic (SGBD) asupra

MCP. Astfel, anumite validari pot fi efectuate inca de la culegerea datelor, in loc sa se
constate ulterior ca datele sunt complete sau eronate, deci anumite operatii din MCP pot fi
eliminate.

Concepte de baza

Ca si în cazul modelului conceptual al datelor, formalismul modelelor de prelucrare se

bazeaza pe construirea unei diagrame având trei elemente de baza:

a) evenimentul declansator, reprezentat grafic printr-o elipsa, de la care pleaca o

sageata de legatura pentru simplificare, daca este necesar, elipsa poate fi omisa
b) operatia, reprezentata grafic printr-un dreptunghi ;
c) rezultatul (evenimentul emis), reprezentat tot printr-o elipsa
d) sincronizarea, reprezentata grafic printr-un triunghi orientat catre operatie.

Evenimentul declansator

Desemneaza un fapt a carui aparitie declanseaza o reactie în cadrul organizatiei;

aparitia unui eveniment va antrena derularea de activitati, de operatii, reprezentând
“motorul” unei actiuni, al unei operatii ( de ex. sosirea unui document).
Pentru ca MCP sa fie cât mai stabil, el trebuie sa fie independent de aspectele
organizatorice si tehnologice, chiar geografice.
De ex. Sosirea unei comenzi de la un client este un eveniment declansator, de
natura extern. A satisface aceasta cerere înseamna a o transforma într-o livrare de
produse. Descrierea continutului prelucrarilor necesare trebuie sa fie independenta de:

 aspectele tehnologice (se utilizeaza calculatorul sau nu ?)

 aspectele “geografice” (comanda este prelucrata la depozit sau în
alta parte ?)
 aspecte organizatorice (livrarea este facuta de X la serviciul
comercial sau de Y la magazie ?)
 aspecte temporale (livrarea se face dimineata sau seara ?).
Tip eveniment

Este un concept generic descriind toate aparitiile

evenimentelor de aceeasi natura. Capacitatea sistemului de a
percepe aceste aparitii este exprimata de doi parametri :
capacitatea : indica numarul maxim de aparitii ale acestui tip de eveniment care pot fi
percepute de sistem si
frecventa : indica legea de manifestare a acestor aparitii.

Categorii de evenimente

Un eveniment poate fi :

 extern (receptionat din exterior) : primirea unui CEC, a unui aviz

de plata, solicitarea unui credit, etc.

40
  intern (generat de activitatea sistemului întreprindere) : pana unei
masini, gasirea unei solutii, etc.

Pentru a avea un eveniment trebuie sa coexiste anumite conditii:

- sa se întâmple ceva (în afara sau în interiorul întreprinderii)

- acest ceva trebuie sa fie perceput de sistem (care trebuie sa fie
dotat cu mijloace capabile sa îl perceapa) - întreprinderea sa fie interesata, vazând în el
un posibil eveniment declansator al activitatii sale.

Operatia

Se numeste operatie orice actiune (sau secventa continua de actiuni),

producatoare de evenimente rezultat, care se executa fara întrerupere, ca reactie la un
eveniment declansator (sau a mai multor evenimente declansatoare sincrone). O
operatie constituie un bloc neîntrerupt (nu trebuie sa apara rezultate intermediare în
interiorul unei operatii).
Tip de operatie

O categorie de operatii ce prezinta aceleasi caracteristici. Un anumit numar de

parametri caracteristici permit specificarea unui anumit tip de operatie:

- desemnarea operatiei însasi;

- durata exprimata în unitati de timp
- actiunile elementare constitutive
- evenimentele emise si conditiile de emitere.

O operatie se finalizeaza întotdeauna prin emiterea de evenimente functie de

situatiile identificate pe parcurs si de conditiile exprimate de aceste situatii (asa-numitele
reguli de emisiune).
Remarca. O operatie se desfasoara în timp, având o anumita durata. La un
moment dat ea poate fi :

- în asteptarea executiei;
- în curs de executie si
- terminata.

41
 cod Denumire
operatie operatie
Actiune ( Actiuni)
Reguli de emisiune

Rvenimente emise - rezultate

Rezultatul (evenimentul emis) .

Numim rezultat produsul executarii unei operatii. Întotdeauna trebuie respectata

urmatoarea regula: o operatie produce unul sau mai multe rezultate. Descompunerea
unei operatii în mai multe operatii distincte implica aparitia unor rezultate
intermediare. Un eveniment emis poate fi în acelasi timp un eveniment declansator
pentru o alta operatie ( sau alte operatii). De aceea se si utilizeaza acelasi formalism.
Reguli de obtinere a rezultatului

În MCP toate operatiile trebuie sa aiba rezultat. În anumite cazuri obtinerea

unuia sau mai multor rezultate poate fi supusa îndeplinirii anumitor conditii. În aceasta
situatie este necesar sa fie definite, formulate asa numitele reguli de emisiune sau reguli
de actiune. (vezi fig. de mai sus).
Exemple :
- Relatia date-rezultate este supusa anumitor conditii logice : daca valoarea facturata
este mai mare de 1 milion, atunci se acorda o remiza de 1o%, daca nu, se acorda un
scont de 2%.
- Lansarea unei livrari poate fi diferita daca stocul este insuficient. În acest caz comanda
este plasata în asteptare (nu se întocmeste dispozitie de livrare). Conditia “stoc
suficient” defineste o regula de emisiune a rezultatului cu doua cazuri diferite (“stoc
suficint”; “stoc insuficient”).
Reprezentarea regulilor de emisiune

Conform figurii de mai jos, diferitele reguli de emisiune sunt reprezentate

în partea inferioara a dreptunghiului ce descrie operatia.
Reprezentarea este analoga unei formulari de genul :
Daca regula de emisiune 1
atunci Rezultat A si Rezultat B
altfel (regula de emisiune 2)
Rezultat B si Rezultat C

42
 Operatie
Regula de Regula de
emisiune 1 emisiune 2

A B C

Sincronizarea

În anumite cazuri, declansarea unei operatii poate solicita producerea simultana

a mai multor evenimente. Cu alte cuvinte, o anumita operatie nu poate avea loc decât
daca sunt îndeplinite anumite conditii privind manifestarea evenimentelor ce concura la
declansarea operatiei respective. Expresia acestor conditii se numeste sincronizare.

Principiul sincronizarii

Sincronizarea exprima sub forma unei propozitii logice faptul ca operatia poate fi
declansata sau nu. Ea se exprima printr-o expresie booleana ce leaga evenimentele ce
declanseaza operatia.
Modul de functionare

Daca E1, E2 si E3 sunt evenimente declansatoare pentru operatia Oi si daca a, b,

c sunt aparitii corespunzatoare evenimentelor E1, E2 sI respectiv E3, atunci
sincronizarea :

a si ( b sau c) , adica a ∧ ( b ∨ c)

indica faptul ca operatia Oi este declansata daca o aparitie a evenimentului E1 exista

simultan cu una din aparitiile evenimentelor E2 sau E3.
Sincronizarea se exprima deci sub forma unei propozitii logice care trebuie sa respecte
anumite reguli, dintre care cele mai importante sunt:

- conditia trebuie pusa pe evenimentele participative conjugate si

- trebuie sa existe situatii care permit declansarea.

Conceptul de sincronizare exprima o logica si o dinamica a prelucrarilor. La un

moment dat, propozitia logica poate fi verificata. Atunci sincronizarea este activa si
operatia este declansata. La un alt moment este posibil ca un singur eveniment
declansator sa fie realizat; în acest caz sincronizarea este în asteptarea realizarii altor
evenimente care sa declanseze operatia. Daca nici un eveniment nu are loc,
sincronizarea este inactiva.

43
 Evenimentul A Evenimentul B Sfarsit
operatie

Timp
t1 t2 t3

Sincronizare Sincronizare
in asteptare activa (operatie Sincronizare
Sincronizare
declansata) inactiva
inactiva
Exemplu

Vom considera ca exemplificare procedura de acordare a unui credit.

Utilizând formalismul de mai sus vom defini modelul din figura 1.

Schema din figura din dreapta constituie un model conceptual al prelucrarilor tipic; el
descrie ceea ce se face, fara a preciza nici cine face si nici cu ce instrument.

44
 Cerere
de credit

OP 1 Instruire formala

c1 c2 c3

Scrisoare Dosar Informatii

de refuz deschiz suplimentare

Analiza
OP 2 solvabilitatii

c4 c5

Credit Credit
refuzat acordat

Comentarii la figura 1

O data cu primirea cererii de credit (eveniment) , are loc o operatie de instruire

formala a deschiderii unui dosar de creditare care se finalizeaza dupa caz (functie de
regulile de emisiune care au valorile c1 si respectiv c2 si c3) printr-un refuz (cerere
nerezolvabila), prin deschiderea efectiva a unui dosar de creditare si în sfârsit, printr-o
cerere de informare suplimentara.
c1 : nu exista plafon de credite
c2 : exista plafon de credite pe termen scurt c3 : exista plafon de credite pe
termen lung

Acest dosar face sistematic obiectul unei operatii de instruire, care, functie de
solvabilitatea clientului (c4 - client nesolvabil sau C5 - client solvabil) se finalizeaza
printr-o respingere sau acceptare a dosarului.
Notiunea de “Proces”

45
 Un proces descrie dinamica prelucrarilor dintr-o activitate determinata. El este
format din operatii executate ca reactie la evenimente si producând rezultate.

Un proces este:

- omogen : operatiile si rezultatele concura la o finalitate comuna.

- limitat : are granite marcate de evenimentele de origine si de rezultatele
terminale.
Etapele elaborarii unui proces.

Procesul este MCP ce corespunde unui domeniu de activitate. El este

construit printr-un demers metodologic de modelare (analiza, abstractizare,
conceptie), ce cuprinde urmatoarele etape:
1. Delimitarea obiectului de activitate
În cadrul acestei etape trebuie precizate granitele domeniului
de care sunt legate activitatile care intereseaza.
2. Identificarea principalelor evenimente.
Aici trebuie revazute principalele evenimente externe si interne ale
procesului; acestea sunt elemente cheie în realizarea modelului.
3. Construirea tabelului evenimente-rezultate.
Acest tablou permite definirea continutului procesului , precizând
pe coloane, evenimentele, actiunile induse si rezultatele.
4. Identificarea si descrierea operatiilor.
Tabloul evenimente-rezultate, în coloana centrala, permite deja identificare
actiunilor induse de evenimentele declansatoare. O analiza mai complecta a
contextului permite relevarea regulilor de gestiune, care sunt adesea elemente ale
operatiilor.
5. Reperarea sincronizarilor.
Aparent, mai multe evenimente distincte pot sa declanseze aceeasi
operatie. O data stabilite aceste elemente se poate construi schema de baza
pentru fiecare operatie. Aceasta schema se numeste bloc
operatie.
6. Precizarea conditiilor de obtinere a rezultatelor.
Se cauta, printre regulile de gestiune, acelea care definesc conditii
de obtinere a rezultatelor. Se completeaza apoi schema de baza cu
elementele respective.
7. Ordonarea blocurilor-operatie.
Structura generala a procesului decurge din cronologia
evenimentelor. Deci evenimentele trebuie ordonate cronologic. Acest
fapt permite ordonarea diferitelor blocuri-operatie si legarea lor conform
principiului : un rezultat ( al operatiei n-1) declanseaza operatia urmatoare
(operatia n).
8. Verificarea si validarea modelului.
Se verifica daca:
- orice operatie duce la cel putin un rezultat;
- orice operatie este declansata de cel putin un eveniment;
- toate blocurile sunt legate.
Validarea modelului se face de catre persoanele implicate în proces. Numai ele
pot judeca pertinenta modelului propus.

46
 Exemplu.

Etapa 1.
Domeniul care ne intereseaza este gestiunea clientilor privind comenzile pentru
produse de panificatie (figura 2). Deci nu vor fi luate în considerare nici actualizarea
stocurilor, nici activitatile contabile, întrucât nu apartin strict de gestiunea clientilor.

Etapa 2.
Pot fi identificate în principal:
trei evenimente externe :
1. Sosirea unei comenzi de la un client.
2. Existenta unui mijloc de transport disponibil în care sa se încarce
marfa.
3. Sfârsitul zilei;
trei evenimente interne:
1. Acceptarea comenzii.
2. Decizia de livrare.
3. Sfârsitul activitatii de livrare.
Etapa 3. Tabloul evenimente -rezultate

Evenimente Actiuni induse Rezultate

1. Sosirea Controleaza identitatea Comanda acceptata
comenzii de la si pretul sau nu
client
2. Existenta unui Efectueaza livrarea Livrare efectuata
mijloc de transport
disponibil
3. Sfârsitul zilei Examineaza comenzile Comanda de
în asteptare fabricatie
1.Acceptarea Consultarea stocurilor Comanda livrabila
comenzii de produse sau nu
2.Decizie de Pregatirea livrarii Marfa gata de
livrare plecare
3. Sfârsitul Expedierea marfii si Livrare expediata
activitatii de pregatirea facturii Factura
livrare
4. Comanda în Examinarea Comanda de
asteptare comenzilor în asteptare fabricatie

47
Etapa 4.

Se regasesc 6 operatii si anume:

OP 1 - Controleaza identitate client si pret;

OP 2 -Examineaza stoc
OP 3 - Pregateste livrarea
OP 4 - Factureaza
OP 5 - Expediaza marfa
OP 6 - Examineaza comenzile în asteptare

Obs. Au fost retinute doar aspectele conceptuale, eliminându-se operatiile de tip

organizational sau tehnic.
Sosirea
comenzii

OP1 Controlea
za
identitate
N D

Coman Comand
da a

Op Examineaza
Sufucue Insufucue

Comand Comanda Sfarsitul zilei

a in
a b
Pregatir A si B
OP
ea
Examinea
Livrar Mijloc OP
za
e de comenzi
c d
C si
OP Factura Comanda
de
OP Expediaza
Factu Catre alt
proces
Livrare
efectuata

48
Etapa 5

Vom exemplifica lucrul din aceasta etapa doar pentru un singur bloc operatie, si
anume cel corespunzator operatiei 2 (“efectueaza livrarea”).

Livrare pregatita Mijloc de transport

a
b

A si b

Efectueaza
OP 5 livrarea

Livrare
efectuata

Etapa 6.
Putem avea de ex. urmatoarele reguli de gestiune:
a) “daca comanda este acceptata”. Aceasta regula defineste
controlul de identitate si pret si conditioneaza rezultatul (comanda acceptata ,
respectiv refuzata);
b) “daca stocul este suficient”, regula asemanatoare
referitoare la marimea stocurilor.

Etapa 7.
Schema procesului este prezentata în figura 2.

Etapa 8.
Se constata în figura de mai sus ca sunt îndeplinite regulile de modelare în
sensul ca orice operatie este declansata de cel putin un eveniment sI fiecare
operatie are cel putin un rezultat (eveniment emis)
Descrierea detaliata a procesului

Schema procesului prezentata în figura 3 permite o perceptie rapida a

ansamblului prelucrarilor. Daca se doreste însa o prezentare mai detaliata atunci este
recomandat ca aceasta detaliere sa se faca la nivel de bloc operatie, fara sa mai urmeze o
înlantuire a blocurilor detaliate, întrucât o schema detaliata a procesului ar fi greu de
urmarit, de perceput. În acest caz se utilizeaza pentru eveniment urmatorul formalism.
Descrierea detaliata a blocului corespunzator operatiei “examinarea comenzilor în
asteptare” este prezentata în continuare :

49
 Nume
eveniment
Nr max de Termen
aparitii limita

Aceasta maniera de abordare aduce complemente asupra restrictiilor de timp si volum.

Schema poate fi completata cu descrierea continutului operatiei, dar de aceasta data sub
forma de “fisa a operatiei”, al carei continut este prezentat în continuare
Comanda
in asteptare

20 1 zi Sfarsitul
zilei
a b
a si b

OP 6 Examinarea
comenzilor in
asteptare

Cerere de
fabricatie

30 1 zi

Descrierea operatiei Denumire: Examinarea comenzilor în asteptare

Numar : 6

50
 Proces : Gestiunea clientilor
________________________________________________________________

Mod de sincronizare

- la sfârsitul zilei (ora 17)

- pentru toate comenzile în asteptare
________________________________________________________________

Descrierea regulilor de gestiune

R1. Pentru fiecare produs:

- daca totalul cerut este mai mic decât cantitatea din stoc
solicitati livrarea;
- daca nu, cereti fabricarea.
R2. Comenzile de fabricatie sunt emise cel mai târziu a doua zi dupa examinarea
comenzilor.
________________________________________________________

Descrierea regulilor de emisiune

R1. Starea cererilor de fabricatie

Astfel de scheme trebuie elaborate pentru fiecare operatie. Se aplica aici
principiul cunoscut al ierarhizarii, mergând de la general (schema procesului) catre
particular (descrierea operatiei).
Revenind la reprezentarea grafica de mai sus putem afirma ca parametri exprimând
dinamica procesului puneau restrictii doar la nivelul “nodurilor” si anume:

- la nivelul sincronizarii (propozitia logica, durata limita) si

- la nivelul operatiilor pentru emisiunea de rezultate (reguli de emisiune care
orienteaza fluxurile catre o cale sau alta).

Acesti parametri pot fi completati cu altii plasati pe sagetile de legatura, în

amonte si în aval de operatie. Astfel vom avea ca parametri suplimentari:

- participarea si durata limita (pe sageata eveniment -->

sincronizare) si
- cardinalitatea (pe arcul operatie --> rezultat)
Participare si durata limita (reglarea în amonte)

Uneori sincronizarea, pentru a fi activata, are nevoie de existenta unui “lot” de

aparitii ale evenimentului declansator. Acest numar constituie participarea tipului de
eveniment la tipul de sincronizare. Timpul de activabilitate a acestui lot se numeste
durata limita.

Cardinalitatea evenimentelor (reglarea în aval)

Operatiile emit rezultate (evenimente emise). Uneori este posibil ca acestea sa fie
emise în mai multe exemplare identice. Numarul de exemplare exprima cardinalitatea
tipului de eveniment rezultat al operatiei.

51
16. Validarea modelelor

Modelele externe ale datelor

Fiecare prelucrare are propriul/propriile sale modele externe (subscheme) de date ≡

MCD construit prin prisma unei singure prelucrari. MED se construieste independent
de MCD.

prel MED1
Realitate modelare MCD

prel MED2

O prelucrare are ME distincte pentru fiecare consultare si pentru fiecare actualizare.

Atât pentru consultare cât si pentru actualizare, ME se construiesc pe baza blocurilor
logice de date corespunzatoare.

Loturi logice de date: fluxurile de date vehiculate de o anumita prelucare.

Evenimentele care activeaza o sincronizare si care nu constituie o cerere de consultare

constituie un BLD.

Combinatia de evenimente produse printr-o regula de emitere a rezultatelor constituie un

BLD.
e1 e2 BLD E1 E2

e3 e4 BLD E3 E4

Reguli pentru construirea ME

1) Un ME pentru fiecare consultare sau actulaizare efectuata de o

prelucrare. 2) Fiecare ME se construieste pe baza BLD folosind formalismul
EA.
3) Entitatile din ME pot sa nu aiba identificatori.

52
 4) Atributele, entitatile si asocierile externe pot sa nu fie atribute, entitati
sau asocieri conceptuale. 5) Atributele externe echivalente atributelor
conceptuale trebuie sa aiba acelasi nume.
Ex: modele externe pentru OP1
consultare : verificare identitate client

NUME
DenClient
1,n

CORESP

1,1
CLIENT
CodClient
AdresaClient
Cod fiscal
Star
e
actualizare: acceptare comanda de la client

53
 COMANDA
Nr
Data
comandac-da
De clien
nAdresa-
t
Val-
livr
totala 1,n

CUPRIND
E

1,1
LINIE-COMANDA
Cod
Den
produs
UM
produs
Cantitate c-data
Pret vânz
Valoar
e
Principiul validarii modelelor

Fiecare model extern trebuie sa fie deductibil din MCD

Model extern

calcul echivalenta

Model conceptual

54
 CLIENT PRODU
S produs
Cod
CodClient Den produs
DenClient U
AdresaClient P
Mret vânz
CodFiscal
Stare
0,n
0,n

TRANSMITE PRODUS-C-
DAT
Cantitate c-data

COMAND
1,1 A comanda 1,n
Nr
Data c-da

corespondenta directa: Cod produs, Den produs, Cantitate c-data ...

-calcul: Valoare = Cantitate c-data * Pret vânz
∑Valoare
Val-totala =∑
-echivalenta: Adresa-livr ≡ AdresaClient

17. Reguli de validare în consultare

Atributele externe trebuie sa fie atribute conceptuale.

Daca nu:
- omisiuni ⇒ se completeaza MCD;
- date calculate ⇒ se înlocuieste în ME cu atributele conceptuale necesare calcularii sale;
daca acestea nu apar în totalitate în MCD, se adauga;
- date ce nu trebuie memorate ⇒ se elimina din ME, urmând sa fie tastate direct
Trebuie sa existe posibilitatea de-a avea acces la date în structura necesara

Accesul poate fi facut:

- pe baza identificatorului;
- prin parcurgerea entitatilor sau asocierilor, una câte una
⇒ se verifica existenta criteriilor de selectie necesare si se compeleteaza
MCD daca este nevoie.

Daca se fac consultari pentru care criteriul de acces nu este identificatorul,

se adauga în MCD o noua entitate al carei identificator este acest criteriu de acces si
asocierea necesara pentru consultare (cai de acces impuse de utilizare si nu de DF).

55
 Cardinalitatile asocierilor externe trebuie sa fie incluse în cardinalitatile
asocierilor conceptuale ce le corespund semantic.

18. Reguli de validare în actualizare

Orice atribut extern trebuie sa serveasca fie la identificarea elementului

conceptual de actualizat fie la obtinerea valorii de adaugat sau de modificat a unui
atribut conceptual:
-se suprima atributele externe care nu servesc nici unuia din
scopurile amintite;
-se adauga cele absente.

Cardinalitatile asocierilor externe trebuie sa fie incluse în cardinalitatile

asocierilor conceptuale ce le corespund semantic.

Orice atribut conceptual trebuie sa poata fi inserat (modificat sau sters)

prin cel putin un model extern. Daca nu, se adauga modelele externe adecvate.
Ex: entitati si asocieri inserate prin ME acceptare comanda de la client
CLIEN PRODU
T S
Cod
CodClien
produs
Den
DenClien produs
U
AdresaClien
t M
Pret
tCodFisca vânz
lStar
e
0,
0,
n
n
TRANSMITE
PRODUS-C-
DAT
Cantitate c-
data
COMAND
1, A 1,
Nr
1 n
comanda
Data c-
da
Trebuie adaugate MCP si ME corespunzatoare pentru actualizarea produselor si
clientilor.

56
19. Modelarea logica a datelor

Cadru general
Trecerea de la MCD, care este un model universal, spre o solutie informatica se face
gradat, luând în considerare un anumit tip de solutie si apoi, în cadrul tipului respectiv, o
solutie direct implementabila.

Expresia MCD în termenii unui anumit tip de solutie informatica

constituie modelul logic al datelor (MLD).
Deoarece aplicatiile informatice de gestiune se caracterizeaza prin stocarea
si prelucrarea relativ simpla a unor volume mari sau foarte mari de date, tipurile de
solutii luate în considerare vizeaza modalitatile de gestionare a datelor pe suporturile de
memorie externa.
COMAND PROD-C-
CUPRINDE
ANr 1, 1,
n 1
Data Cant
comanda 0, comandata
1,
1
1
CORESPUNDE SE-REFERA-LA

0,
n
0, PRODU
n
FACTUR PROD- S
Cod
1, 0,
A FACTURAT Den
produs
Nr n Cantitate n U
produs
Data
factura Pret
facturata
M
factura unitar
Modelul relational

Domeniu: o multime de elemente de tip similar.

Exemple:

57
 NUME ZILE ORARE

Ionescu luni Bucuresti

Mateescu marti Timisoara
Vasilescu miercuri Arad
Popescu joi Paris
Bunescu vineri Barcelona
Costescu sâmbata Madrid
Dumitrescu duminica Roma

Atribut:
- o submultime a unui domeniu careia i s-a atribuit un nume. Numele
exprima rolul sau semnificatia atribuite elementelor domeniului respectiv.
Ex:
- pentru domeniul Orase, pot fi definite atributele aeroport origine, aeroport
destinatie, aeroport escala etc

Aeroport origine Aeroport destinatie Escala

Bucuresti Arad
Bucuresti Barcelona
Paris Bucuresti Timisoara

Relatie: o multime

R = {(a1,a2,..,an):(a1 ∈ A1, a2 ∈ A2, ...an ∈ An) ∧ P(a1,a2,...an) = adevarat}

unde A1,A2...An sunt domenii.

Ex 1: A1: domeniul compozitorilor; A2: domeniul simfoniilor;

P(a1,a2) = "a1 est autorul simfoniei a2".
P(Beethoven,Eroica)=adevarat;
P(Vivaldi,Simfonia fantastica)=fals.
Ex 2:
personal(MARCA,NUME,PRENUME,DATA-NASTERII)
daca (m,n,p,d) ∈ personal
atunci o persoana cu marca (m), numele (n), prenumele (p) este nascuta la data (d).

58
Relatiile se reprezinta grafic sub forma de tabele, în care se disting:

• gradul relatiei: numarul de atribute utilizate

• cardinalitatea relatiei: numarul de tupluri (linii în tabel).
Cardinalitatea unei relatii este variabila în timp datorita operatiilor de actualizare care
pot adauga sau sterge tupluri.

Pentru o relatie pot exista 3 tipuri de chei:

• cheie primara: cel mai mic ansamblu de atribute (eventual
unul singur) care permite identificarea fara univoc al fiecarui tuplu al
unei relatii; atributele care compun cheia primara nu pot
avea valori nule.
• cheie candidat: o alta posibila cheie primara, care nu a
fost însa retinuta ca atare.
• cheie externa: un ansamblu de atribute (eventual unul
singur) care este cheie primara într-o alta relatie.

Restrictie de integritate referentiala:

daca între un atribut A si o cheie primara B exista o RIR atunci A nu
poate lua decât valori care exista si în B. Prin definitie, cheile externe sunt
supuse RIR în raport cu cheile primare corespunzatoare.
Gra
Atribut
d
e
MARC NUM PRENUM DATA
A 12 PE opesc E Vasil NAST
22/10/6
512 u
Popesc eAdrian 817/5/6
833 u
C o ste aIo 58/12/6
641 aIonesc n
Ma r i 330/4/6
7 u a 4
Cardinalitat Tupl
e u

59
20. Trecerea de la MCD la MLD relational

a. ENTITATI
Fiecare entitate devine o relatie.
Atributele entitatii devin atribute ale relatiei.
Identificatorul entitatii devine cheia primara a relatiei.

E
Ae11
A
1 e1
.2.
.
E1 Ae1 ,Ae12,
( 1 ...)
b. ASOCIERI
b.1 Cazul general

1) Asocierea devine o relatie.

2) Atributele proprii ale asocierii (daca exista) devin atribute ale
relatiei.
3) Cheile primare ale entitatilor participante la asociere devin chei
externe.
4) Identificatorul asocierii devine cheia primara a relatiei.

_,n _,n
Ae11 ASO Ae21
Ae12 CA1 Ae22
... ...

ASOC Ae11 ,A1

( ,Ae21 )
E1( Ae11 ,Ae12, ...)

E2( Ae21 ,Ae22, ...)

60
 Ex 1 :

STUDENT EXAMEN DISCIPLINA

1,n 0,n
Nr matricol Data examen Cod discipl
Nume sustine Nota cursant Nume discipl
Prenume

STUDENT(Nr matricol, Nume, Prenume)

DISCIPLINA(Cod disciplina, Nume disciplina)

EXAMEN(Nr matricol*, Cod disciplina*, Data examen, Nota)

Ex : 2
STRUCTURA
-FABRICATI
ECantitate
nec
compus- component-
din ARTICO in
0, L
Cod 0,
n Den
articol n
Tip
articol
U
articol
M
ARTICOL(Cod articol, Den articol, Tip articol, UM)

STRUCT-FABRICATIE(Cod articol compus*, Cod articol component*,

Cantitate necesara)
b.2. Asocieri binare având cel putin o cardinalitate maximala 1.

Se adauga la atributele relatiei corespunzatoare entitatii cu cardinalitatea maximala 1

identificatorul celeilalte entitati (cheia primara a relatiei corespunzatoare acesteia), care
devine cheie externa.
Daca asocierea are atribute proprii, acestea se adauga la rândul lor relatiei care
reprezinta entitatea cu cardinalitate maximala 1.

61
 E _,1 _,n E
1 ASO 2
Ae11 Ae21
Ae12 C A1 Ae22
... ...

E1 Ae1 ,
( 1 Ae12,...,Ae21,A1)
E2 Ae2 ,Ae22,...
( 1 )
Ex 1

ANGAJA COMPARTIMEN
T
Marc LUCREAZ T
Num 1, 0, Cod
ã A
Data
Prenum
e 1
lucreaza- loc- n compartiment
încadrãrii Den
Data
e la munca
Salariul compartiment
nasterii
lunar

COMPARTIMENT(Cod compartiment, Den compartiment)

ANGAJAT(Marca,Nume, Prenume, Data nasterii, Salariul lunar, Cod compartiment*, Data

încadrarii)

62
 Ex 2
0,n FILIATIE
1,1

tat copil
a

PERSOAN
Ã
Cod
persoanã
Num
e
Prenum
e
Data
nasterii
Se
x
PERSOANA(Cod persoana, Nume, Prenume, Data nasterii, Sex, Cod persoana
tata*)
c. SUBTIPURI DE ENTITATI (Generalizarea/specializarea)

c.1. Reprezentarea simpla a legaturilor dintre tip si subtip

Se aplica regulile de la b.2. conform urmatoarei schemei generale:
Entitat Entitat
e e

≡ 0, 0,

Subti Subti
p p 1,
1,
Subti Subti
p p

c.2. Reprezentarea mostenirii

Reprezentarea mostenirii ca proces de transfer al proprietatilor generice ale

tipului spre subtipuri nu beneficiaza de o solutie relationala dedicata. Din aceasta cauza,
este necesar sa se recurga la defactorizarea proprietatilor comune.

63
 a) se favorizeaza specializarea: tipul de entitate generica dispare
iar atributele sunt adagate la fiecare dintre subtipuri.
BUN-
proprietat IMOBILIAR
Nr bun
e 1, Adres
1 Suprafat
POSED
A #
DE- DE-
VANZARE INCHIRIAT
Chirie
proprieta 1, Pret
n Star Avans
r CLIEN solicitat Durata
minimal
e
T
Nr
Nume
Adresa
client
No
telefon
BUN-DE-VANZARE( Nr bun , Adresa, Suprafata, Pret solicitat, Stare, Nr
Client)
BUN-DE-INCHIRIAT( Nr , Adresa, Suprafata,
bun Chirie lunara, Avans minimal, Durata minima, Nr
Client)

b) se favorizeaza generalizarea:

• tipul de entitate generica preia si atributele specializate care, în

functie de subtipul reprezentat, primesc valori nule.

BUN-IMOBILIAR(Nr bun, Adresa, Suprafata, Pret solicitat, Stare,

Chirie lunara, Avans minimal, Durata minima, Nr client*)
• atât tipul cât si subtipurile sunt conservate ca atare.

BUN-IMOBILIAR(Nr bun, Adresa, Suprafata, Nr client*)

BUN-DE-VÂNZARE(Nr bun vânzare, Pret solicitat, Stare)

BUN-DE-ÎNCHIRIAT(Nr bun inchiriat, Chirie lunara, Avans

minimal, Durata minima)

Nr bun vânzare si Nr bun inchiriat trebuie sa respecte restrictiile de

integritate referentiala în raport cu Nr bun.

64