Sinteza c urs: Sisteme informatice financiar -bancare 1 Universitatea SPIRU HARET [606757]

Sinteza c urs: Sisteme informatice financiar -bancare 1 Universitatea SPIRU HARET
Facultatea ȘTIINȚE ECONOMICE
Specializarea FINA NȚE ȘI BĂNCI

Disciplina

Sisteme informatice financiar -bancare si de asistare a deciziei

Prof univ. dr Mareș Marius Daniel

Conținut curs

Capitolul 1. Sisteme informatice financi ar – bancare.
 Sistem informațional, sistem informatic, sistem informatic integrat, sistem informatic de gestiune .
 Principii utilizate în proiectarea sistemelor informatice din domeniul economic.
 Structura și arhitectura unui sistem informatic de gestiune
 Metode de proiectare a sistemelor informatice.

Capitolul 2. Metoda sistemică Merise.
 Generalități privind abordarea Merise în proiectarea sistemelor informatice financiar bancare
 Modelarea datelor la nivel conceptual
 Realizarea modelului conceptual al da telor MCD
 Modelarea conceptuală a prelucrărilor
 Realizarea modelului conceptual al prelucrărilor
 Modelarea fizică și logică a datelor

Capitolul 3. Metoda orientată pe obiect Object Modeling Technique
 Abordarea obiectuală în informatică: concepte de bază, domenii de aplicare
 Nivele de modelare în proiectarea orientată obiect
 Modelare statică

Capitolul 4. Model dinamic și model funcțional. Limbajul Unificat de Modelare UML.
 Stare, tranziție, acțiune, scenariu
 Caracteristici și tipuri de modele
 Interfețe
 Modelarea comportamentului, diagrame

Sinteza c urs: Sisteme informatice financiar -bancare 2 Capitolul 5. Exemplificări și studii practice
 Dezvoltare și utilizare prin Visual Basic for Applications
 Dezvoltare și utilizare prin Access SQL

Bibliografie

Bibliografie obligatorie

1. Daniel Marius Mareș, Gabriel Mihai, Valerica Mareș, Sisteme informatice financiar -bancare,
Editura Fundației România de Mâine, București, 2008
2. Daniel Marius Mareș, Gabriel Mihai, Valerica Mareș, Sisteme informatice financiar bancare
si de asistare a deciziei , Editura Fundației Româ nia de Mâine, București, 2008
3. Victoria Stanciu și colectiv, Proiectarea sistemelor informatice , Editura Dual Tech, București,
2002 .

Bibliografie suplimentară

1. Dorin Zaharia, Ioan Roșca, Proiectarea obiectuală a sistemelor informatice , Editura Dual Tech,
Bucuresti, 2002.
2. Roșca, Ioan și colectiv, Proiectarea sistemelor informatice de gestiune. Studii de caz , Editura
Infomega, București, 2003.
3. Năstase Pavel și colectiv, Tehnologia bazelor de date. Access 2000 , Editura Economică,
București, 2000

Sinteza c urs: Sisteme informatice financiar -bancare 3
Prezentar e sintetică a lecțiilor

Capitolul 1. Sisteme informatice financiar – bancare

Introducere
Informația economică aduce cunoștințe cu privire la resursele economice și la producția, repartiția, schimbul și
consumul de rezultate. Informația contabilă , parte a informației economice vehiculează cunoștințe de reflectare
și control privitoare la situația patrimoniului, entitate economică și juridică de gestiune a valorilor materiale și
bănești.

Obiective :
Metode de proiectare a sistemelor informatice
Parametrii de performanță ai sistemelor informatice.
Perceperea corectă a noțiunilor – sistem informațional, sistem informatic, sistem informatic integrat.
Principii de elaborare și finalizare a lucrărilor de sinteză.

Cuvinte cheie
mijloace de
prelucrare a datelor lucrări de
sinteză criteriu de apreciere a
performanțelor coeficientul
eficienței globale metode structurate,
sistemice, obiect
sistem informațional
economic sistem
informatic abordare ascendentă,
descendentă durată recuperare
cheltuieli faza selectie,
interpretare, decizie

Planificarea, organizarea și controlul asupra activității economice și sociale se realizează în funcție de
aceste informații, obținute sub forma lor activă, pasivă, sau previzionară. După forma de reprezentare ,
informația contabilă poa te fi cantitativă , reflectând starea în care se află elementele patrimoniale, sau valorile
definite prin raportări, și calitativă , indicând felul și natura elementului patrimonial la care se referă informația.
În mod concret, informația contabilă se identi fică cu datele financiar -contabile furnizate de documentele
contabile și cu indicatorii economico -financiari privind resursele și rezultatele obținute.

1.1. Sistem informațional, sistem informatic, sistem informatic integrat
Sistemul informațional economi c poate fi definit ca un sistem integrat de oameni de specialitate,
mijloace și procedee adecvate , privind culegerea și înregistrarea datelor tehnico -economice și financiare, care
privesc patrimoniul unităților și economiei naționale în ansamblul acestora, prelucrarea și analiza acestora,
obținerea de informații utile în vederea conducerii și gestionării eficiente a acestuia, stocarea și păstrarea datelor
și a informațiilor pentru documentări și controale ulterioare.
Sistemul informatic este un ansamblu str ucturat ș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.
Suporturile datelor și al informațiilor sunt mijloace materiale cu ajutorul cărora sunt vehiculate și stocate
informații. Datele și informațiile proprii circuitului economic al patrimoniului sunt consemnate în document e. În
raport de modul de întocmire și rolul lor în cadrul sistemului informațional, documentele pot fi justificative, de
evidență contabilă sau de sinteză și raportare.
După cum se cunoște orice operație patrimonială se consemnează în momentul efectuării e i într -un act
înscris, care stă la baza înregistrărilor în contabilitate, dobândind astfel calitatea de document justificativ. Astfel
se asigură datele de intrare în sistemul informațional economic și se fundamentează înregistrarea proprie
contului.
Docume ntele justificative asigură datele de intrare în sistemul informațional contabil, consemnează
operațiile economice și financiare în momentul efectuării lor cu scopul de a servi ca dovadă a înfăptuirii lor și ca
instrument de fundamentare a înregistrării co ntabile. Conținutul documentelor justificative este format din
următoarele elemente: denumirea, numărul și data documentului, denumirea și sediul unității patrimoniale,

Sinteza c urs: Sisteme informatice financiar -bancare 4 menționarea părților care participă la efectuarea operației, conținutul operației econo mice, datele cantitative și
valorile aferente operației, semnăturile persoanelor care răspund .
Documentele de evidență financiar -contabilă realizează înregistrarea și stocarea datelor în structura
proprie contului și a sistemului de conturi. Datele surs ă privind operațiile economice consemnate în documentele
justificative sunt înregistrate în ordine cronologică și grupate în registrele contabile. Prin registrele contabile se
formează și materializează înregistrările proprii sistemului de conturi. În cond iț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.
Documentele de sinteză și raportare reprezintă un sistem de indicatori economico -financiari ce
caracterizează situația patrimoniului și rezultatele obținute. Prin intermediul lor, se centralizează și transmit
informațiile înregistrate în sistemul de conturi. Gestiunea documentelor, respectiv organizarea circulației lor,
utilizarea și evidența, r econstituirea și păstrarea, vizează constituirea lor într -un sistem unitar și rațional, care are
la bază reguli precise privind întocmirea, folosirea, circulația și evidența fiecărui document.
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ă, privind
existența diferitelor elemente de patrimoniu și activități desfășurate în perioada precedentă.
În general, in formațiile de programare, planificare și previziune au un caracter relativ sintetic, dar sunt
obținute de cele mai multe ori pe baza calculelor analitice. Cele mai importante programe la nivel de
întreprindere sunt următoarele: programe de investiții, prog rame 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 as igurări
sociale, inclusiv eventualele subvenții pe care unitatea le solicită de la bugetul statului; bugetul de venituri și
cheltuieli ; programe de creștere sau descreștere a capitalurilor proprii ; programe de încasări și plăți , de
credite obținute și acor date etc. Întocmirea acestor programe trebuie să respecte următoarele condiții: să fie
reale; să conțină suficiente detalii, astfel încât să se poată realiza definirea sarcinilor de realizare pe
compartimente, precum și răspunderi în caz de nerealizare.
Mijloacele de prelucrare a datelor economice reprezintă ansamblul de tehnici și echipamente de
culegere, prelucrare și transmitere a informațiilor. Apariția calculatorului electronic a determinat apariția
informaticii ca un sistem complex de tehnici și met ode de prelucrare logică și automată a datelor. Definirea
informaticii ca ‘știință a prelucrării raționale’, se bazează pe faptul că tratează informația prin structura ei
formală, și utilizează tehnici specifice neținând seama de aspectul semantic al infor mației, ci doar de modul de
reprezentare formală a acesteia (aspectul sintactic).
Metodele și procedurile de prelucrare se referă la
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ță.
Considerăm necesară corelația flux urilor de intrare –
ieșire cu sistemul de pilotaj al agenților economici fapt
materializat prin acțiunea în timp real a sistemului
informațional.
Apare evidentă activitatea de pilotaj cu sarcini de coordonare și decizie corelată cu obiectivele fixate. Se
va avea în vedere faptul că vor fi necesare mutații la nivelul cerințelor ca reacții la fluxurile de intrare -ieșire în și
din sistem.
Elementul nodal – sistemul informațional – permite alcătuirea unor magistrale de circulație prioritară cu
scopuri de actuali zare a deciziei și de dezagregare pe centre de responsabilitate. Sistemul operant urmărește
producerea rezultate pe baza intrărilor din mediul extern adaptându -și activitatea în funcție de deciziile specifice
primite.. Este evidentă descrierea activității sistemului operant orientată pe baza regulilor de funcționare, stabilite
prin sistemul de management, aplicate asupra intrărilor pentru a produce ieșirile dorite. În cadrul proiectării unui
sistem informatic, datele și prelucrările sunt studiate și modelat e împreună.

Sinteza c urs: Sisteme informatice financiar -bancare 5 Subansamblu reprezentativ în cadrul unui sistem operant este format din reuniunea de funcții care pune
în evidență cel mai bine comportamentul întregului sistem operant. Identificarea acestui ansamblu reprezentativ
este unul dintre pașii de baz ă pentru utilizarea metodei de proiectare optime.

1.2. Elaborarea celor mai importante lucrări de sinteză financiare și contabile
Prezentarea principalelor aspecte ale principiilor care se referă la lucrările de sinteză .
a) Principiul continuității activi tății presupune mai ales la finele anului de gestiune că unitatea își va
continua în viitor activitatea, fără a intra în faliment, fuziune, diviziune, sau fără importanta reducere a
activității..
b) Principiul permanenței sau a stabilității metodelor presu pune continuitatea pe perioade relativ
mari de timp a acelorași norme și reguli privind evaluarea, înregistrarea în evidențele curente și prezentarea lor
prin lucrările de sinteză, a elementelor patrimoniale, inclusiv a veniturilor, cheltuielilor și a rezu ltatelor
financiare, asigurând astfel în timp și spațiu comparabilitatea informațiilor economico -financiare și contabile.
c) Principiul prudenței presupune că atât elementele patrimoniale de activ și de pasiv, cât și cheltuielile
și veniturile vor fi evalu ate la valori reale, exacte, atât în contabilitatea curentă, cât și la bilanț.
d) Principiul independenței exercițiului necesită considerarea tuturor veniturilor și cheltuielilor
corespunzătoare exercițiului financiar încheiat, fără a se ține seama de date încasării sumelor sau a efectuării
plăților.
e) Principul evaluării separate a fiecărui element de patrimoniu constă în aceea că evaluarea
fiecărui element se realizează separat în contabilitatea curentă, cât și înainte de întocmirea bilanțului.
f) Prin cipiul intangibilității bilanțului constă în aceea că bilanțul de deschidere al unui exercițiu
financiar este necesar să corespundă cu exactitate cu bilanțul de închidere al exercițiului precedent, fără
modificarea elemente de patrimoniu.
g) Principiul nec ompensării constă în aceea că nu se admit compensări la bilanț dar nici în
contabilitatea curentă între diferite elemente de patrimoniu, sau între cheltuieli și venituri de aceeași natură sau
de naturii diferite, extracontabile sau contabile, nelegale și n eadecvate principiului imaginii fidele.
h) Principiul prevalenței economicului asupra juridicului constă în aceea că informațiile din situațiile
de sinteză trebuie să reflecte realitatea economico -financiară, nu numai forma lor juridică
i) Principiul pragu lui de semnificație constă în elementele de patrimoniu cu valori însemnate sunt
prezentate separat la lucrările de sinteză, iar cele cu funcții similare de volum redus se vor prezenta mai multe,
cumulativ.
Lucrările de sinteză financiare și contabile const ituie un sistem complex de prezentare periodică a
activității agenților economico -sociali (întreprinderi: regii autonome, respectiv societăți comerciale; instituții
publice).
Obiectivele acestor lucrări constau în a furniza informații despre poziția finan ciară, performanțele și
modificările patrimoniului unității, care sunt utile unei sfere largi de utilizatori: în primul rând conducerii și
salariaților proprii; unor persoane exterioare unității, cum ar fi: acționari, furnizori și clienți, organe fiscale
și sociale, bănci etc .
Lucrările de sinteză se pot clasifica din mai multe puncte de vedere și anume: al importanței; al
metodologiei de prelucrare a datelor și al perioadei pentru care se întocmesc .
Din punct de vedere al importanței pentru raportare și a naliza informațiilor deosebim: dări de
seamă de stat; dări de seamă departamentale; dări de seamă interne ale agenților economici.
În funcție de conținutul și metodologia de prelucrare a informațiilor deosebim: dări de seamă contabile; dări
de seamă statis tice; dări de seamă unice contabile și statistice.
În raport de perioadele la care se întocmesc și de sfera de cuprindere a indicatorilor există: dări de
seamă curente; lucrări trimestriale, semestriale și dări de seamă anuale.

1.3. Principii utilizate în proiectarea sistemelor informatice din domeniul economic
Proiectarea și realizarea unui sistem informatic sunt operațiuni dificile pentru că obligă la luarea în
considerare a tuturor factorilor sistemului om –mașină. Dacă acceptăm ideile că sunt mai multe modalități de
delimitare a domeniilor de studiu, că sunt nenumărate mijloace de documentare, că există multe metode de
concepție și punere în exploatare curentă rezultă că cele mai multe dintre ele se pot folosi în mod combinat sau
complementar.

Sinteza c urs: Sisteme informatice financiar -bancare 6 Amintim în acest context două mari viziuni de concepție a sistemelor informatice: abordarea ascendentă
cunoscută mai simplu sub numele de bottom -up și abordarea descendentă sau top–down .
Abordarea ascendentă are ca punct de plecare nivelul operațional (aflat la baza piramidei ierarhice) și
prin realizarea informatizării la fiecare nivel în parte, se ajunge la un sistem informatic care poate atinge nivelul
punctul extrem al piramidei. Este deci o consolidare a unui proiect care ne permite să avem în faza finală,
infor matizarea completă a unui sistem informațional –organizațional specific unui organism economic supus
analizei.
Abordarea descendentă constă în a coborî, pe scara piramidei ierarhice, până la bază și realizând
totodată și o analiză. Această viziune consider ă că un anumit domeniu este compus din părți corelate între ele și
cu legături cu exteriorul, caracteristică pentru toate sistemele informaționale.
Metoda permite observarea sistemelor informatice sub mai multe perspective:
 perspectivă sistemică . În aceast ă privință interesează totalitatea problemelor înainte de a da o soluția
globală, astfel spus întregul este altceva decât suma părților.
 perspectivă paralelă date–prelucrări. Față de alte metode care tratează în mod privilegiat datele sau
prelucrările, se ține cont în aceeași măsură de date și de prelucrări. Datele sunt elementele stabile într -o
organizație fiind luate în calcul într -o „optică statică” iar prelucrările sunt întotdeauna dinamice și sunt
reprezentate prin instrumentele de sincronizare.
 perspe ctivă orientată pe nivele . Există în cadrul metodei nivele de abstracție care corespund domeniilor de
preocupare și care, la rândul lor, determină viziuni descriptive. Nivelele de abstracție sunt ierarhizate
pornind de la situația conceptuală sau fizică pâ nă la cea organizațională sau logică. Această viziune
permite fixarea opțiunii gestiunii la nivel conceptual, opțiunii organizaționale la nivel logic și a celei
tehnice la nivel fizic.
 viziune globală asupra unui subansamblu reprezentativ. În majoritatea c azurilor vederea de ansamblu
poate considera un domeniu ca fiind cel mai important.
 perspectiva externă . Abordare date –prelucrări se simte la moment dat de la debutul proiectului evidențiind
obligația verificări coerenței dintre date și prelucrări. Aceast ă „reconciliere” dintre date și prelucrări se
face prin intermediul modelelor externe.

1.3.1. Parametrii specifici de performanță pentru sistemele informatice
Calitatea informațiilor determină în mare măsură performanțele compartimentului financiar -contab il,
atingerea obiectivelor pe care firma și le -a propus. Există două abordări ale performanței: una ce dezvoltă o
situație stabilă a sistemului și o alta care pune în valoare dinamismul, noutatea în domeniul considerat. Existența
stabilității mediului info rmațional induce aprecierea globală a sumei atuurilor sistemului informatic financiar –
contabil (S.I.F.C.).
Prezentăm câteva criterii de apreciere a performanțelor zonei economice informatizate:
a. criteriile de natură tehnică au în vedere conținutul sistemulu i, capacitatea acestuia de a îndeplini funcții
specifice. Vor fi luate în considerare atât aspectele legate de producerea de informații utile, cât și cele ce
privesc gestiunea sistemului și a firmei.
b. criteriile organizaționale reduc incertitudinile sistemu lui informatic financiar -contabil și permit grefarea
pe structura acestuia. Creșterea capacității lui de prelucrare ori gradul său de deschidere va determina
modificări structurale ce se impun a fi pe deplin stăpânite.
c. criteriile economice – utilizarea lo r are în vedere tipul proiectului și etapa procesului de decizie. După
părerea autorilor există două mari categorii de repere în stabilirea dimensiunii contabilității
informatizate: unele ce își propun să urmărească costurile și avantajele (metode a poster iori) și altele
care doresc să efectueze demersuri pentru o analiză complexă în vederea alegerii investiției (metode a
priori).
Pentru zona contabilității informatizate, putem pune în evidență mai multe praguri și măsurări ale
eficienței:
 coeficientul efic ienței globale a sistemului informatic financiar -contabil (Keg):
Keg = (Ec + As) / (Chi + Che) unde:
Ec – economii rezultate prin introducerea tehnologiilor informatice și de comunicație; As – acumulările
suplimentare; Chi – cheltuieli de implementare; Che – cheltuieli de exploatare a sistemului.

Sinteza c urs: Sisteme informatice financiar -bancare 7 Calea principală de creștere a eficienței sistemelor informatice este reducerea cheltuielilor prin: utilizarea
de elemente standardizate și tipizate; elaborarea bugetului informatic și controlul realizării indicato rilor
prevăzuți; îmbunătățirea parametrilor de exploatare a aplicațiilor informatice.
Cu cât durata de recuperare a cheltuielilor cu caracter informatic (ce privesc echipamentele, programele,
rețelele) este mai mică, cu atât standardele vor fi mai mari și se vor înregistra acumulări suplimentare (implicit
profit net).
 durata de recuperare a cheltuielilor este invers proporțională față de coeficientul eficienței
globale.(Dr):
Dr = 1/Keg
Se va avea în vedere totalitatea cheltuielilor (de investiție, de exploa tare) iar sistemul informatic se va
aprecia ca fiind eficient dacă Keg >1, iar Dr <5.
Performanțele sunt direct legate și de dimensionarea optimă a sistemului informatic financiar – contabil
așa cum este prezentat mai jos:
Caracteristicile sistemului Efect ele economice
Abordare orientată client Efect de anvergură (eficiența partajării resurselor, eficacitatea utilizatorilor
decidenți)
Bază comună a prelucrărilor
și comunicației Efect de anvergură (cost al sistemului integrat < costurile a două neintegrate )
Evoluție progresivă Reducerea efectului de complexitate
Portabilitate Efect de anvergură (partajarea aplicațiilor pe platforme mai eficiente)
Convivialitate Efecte de învățare și experiență (reducerea costului de pregătire)
Performanța sistemului:
– optimizarea prelucrărilor
– optimizare traficului Efect de anvergură (diminuarea costului de prelucrare și transmitere)
Remarcăm anumite „forțelor motrice” care ajută la formarea rezultatului sistemului informatic financiar –
contabil: producția informațion ală și modalitățile de valorificare a acesteia; evoluția salariilor utilizatorilor
decidenți și/sau a managementului; etc. Contribuția fiecărui factor asupra evoluției profitului se determină
utilizând procedeul substituțiilor în lanț care permite măsurare a influențelor sau a alternativelor.

1.3.2. Necesitatea și structura procesului de evaluare a contabilității informatizate
Liniile de forță ale evaluării „economicului” informatizat
se bazează pe două puncte esențiale: eficacitatea și eficiența.
Există o raportare permanentă a laturii informatizate la un sistem
de referință și o legătură directă cu actul deciziei, fapt ilustrat în
figura 3.
Operația de evaluare în cadrul sistemului informatic
financiar -contabil va ține cont de trei elemente fundamentale:
resursa umană; raporturile de putere; referențialul.
Procesul de evaluare a unui sistem presupune
parcurgerea următoarelor faze: selecția, interpretarea și decizia .
A. Faza de selecție permite obținerea unei imagini sistemică a situației și pentru a nu lua decizii cu
consecințe negative se stabilesc foarte clar factorii de tip selectiv. Managerul trebuie să obțină maxim de
informații pentru a reduce incertitudinea în fața căreia se află, însă în unele situații consumă foarte mult timp cu
această preocupare și nu -i mai rămâne decât foarte puțin pentru activitățile de decizie efective (mai ales de tip
strategic).
Faza de selecție presupune înțelegerea comportamentului sistemului informatic financiar -contabil,
plecând de la tendințele existente în cadrul lui, p recum și de la liniile sale de forță. Apare evidentă evaluarea
strategică față de cea operațională. Considerăm că informatica, inteligența artificială (în special sistemele expert)
pot aduce un ajutor substanțial în faza de selecție, prin consultarea bazel or de cunoștințe îmbogățite cu
experiența trăită, utilizând și facilitățile procesoarelor de tabele.
B. Faza de interpretare. În cadrul „acesteia în procesul de evaluare a contabilității informatizate pot
apare probleme legate de: puterea simbolurilor, flu iditatea „catartică", dinamica actului de evaluare.

Sinteza c urs: Sisteme informatice financiar -bancare 8 Puterea simbolurilor reprezintă pentru mulți utilizatori decidenți sinonimă cu descentralizarea,
autonomia și creșterea productivității muncii. Ei își construiesc diverse agregate simbolice legate de atuu rile
folosirii calculatorului pe propriul birou. Fiecare agregat va poseda un conținut „catartic” specific, astfel pentru
unii indivizi rețelele de telecomunicație vor constitui punți spre o nouă eră a comunicației, în schimb pentru alții
vor fi doar surse a numeroase pericole.
Fluiditatea „catartică ” este o noțiune care a fost pusă în evidență de cercetătorul Bruno Lussato și se
referă la „mobilitatea mai mult sau mai puțin importantă a transferului de rezonanță a unei reprezentări R spre o
reprezentare RI , ignorată până atunci". Fluiditatea determină stabilirea unei anumite ponderi pentru fiecare
criteriu evaluat la un moment dat. Vom putea distinge în zona contabilă informatizată trei tipuri de criterii:
primordiale (exemple: mărimea intervalelor de timp, compatibilitatea resurselor); importante (exemple:
posibilitățile de adaptare la nou, capacitatea de a evita hipertrofierea configurațiilor informatice, inclusiv
alinierea acestora la obiectivele urmărite); eliminate d in evaluare (exemple: compatibilitate a mărcilor de
echipamente, posibilitatea de autoformare a utilizatorilor decidenți).
Dinamica actului de evaluare reliefează „cultura” sistemului mai ales „slăbiciunile” vizibile sau ascunse.
Uneori aceste minusuri pot fi imaginare, fiind vorba de fapt de lacune ale criteriilor, o greșită definire
(structurare), o percepție eronată, o varietate (incoerență) exagerată.
C. Faza de decizie – apare ca rezultat al unei cooperări și a unui limbaj comun între diferiții „actori” din
sistemul informatic financiar –contabil. Unele decizii admise în trecut nu mai puteau fi înțelese la un moment dat,
datorită modificării punctelor de vedere și a mediului, putând dobândi caracter ireversibil. Evaluarea elementelor
componente ale compartimentului financiar –contabil prin me toda „scenariilor” va avea în vedere, de fiecare dată
trei mari etape: stabilirea scenariilor și evaluarea efectelor previzibile; valorizarea acestora; alegerea soluției care
este considerată ca fiind cea mai bună.

1.4. Metode de proiectare a sistemelor i nformatice

Metodele de proiectare se pot clasifica în trei mari categorii: metode structurate; metode sistemice; metode
orientate obiect.
Metodele structurate folosesc descompunerea progresivă descendentă top-down , ele fiind în fapt carteziene.
Pornind de la cerințele inițiale, concepția constă în crearea, unui ansamblu unitar în interacțiune, având fiecare o funcție
clar definită. Diagramele de fluxuri de date descriu prelucrările logice ale datelor și arată maniera în care datele intrate
sunt modificate printr -o suită de transformări funcționale, pentru a ajunge la datele de ieșire. Cele mai cunoscute metode
aparținând acestei prime generații sunt: SADT ( Structured Analisys and Design Technique ), JSD ( Jackson System
Development ), Yourdon etc. Toate au la bază analiza funcțională a întreprinderii. Diagramele de structură permit
vizualizarea structurii ierarhice, descrierea programului sau a unui modul fiind stabilite pe mai multe niveluri, prin
rafinări succesive.
Metoda SADT propune un ansamblu de diagram e ordonate ierarhic, în care fiecare poate fi considerată fie ca o
diagramă – părinte (sinteză a diagramelor sale fiu), sau ca o diagramă – fiu (dezvoltare a unei părți a celei părinte). În
cazul metodei SADT, datele și prelucrările sunt examinate împreună , definindu -se actigrame (sau diagrama activităților)
și datagrame (diagrama datelor). Avantajele metodelor ierarhice constau în simplitate și o bună adaptare la cerințele
formulate de utilizator. Dezavantajele pornesc de la conceperea sistemelor informati ce conform cerințelor analizei
funcționale, ceea ce determină concentrarea efortului de analiză și proiectare asupra prelucrărilor în condițiile în care
acestea sunt cele mai supuse modificări în timp, modelarea datelor căzând pe un plan secund.
Proliferar ea aplicațiilor creează propriile lor fișiere, ducând la redun -danțe și mai ales la o incoerență a datelor în
sistemele de informare a organizațiilor.
Metodele structurate au fost integrate în S.G.B.D. prin limbajul de descriere a datelor .
Metodele sistemi ce permit vizualizarea și înțelegerea organizării datelor. Aceste metode se compun din
abstractizări care prezintă lumea reală ca pe o colecție de entități și de legături, stabilite între acestea. Majoritatea permite
definirea de restricții descriind aspec tele statice, dinamice sau chiar temporare ale entităților. În această calitate ele
constituie formalisme lizibile în cadrul specificațiilor de nevoi. Două metode constituie referința de reprezentare
semantică: metoda individuală1, care va fi integrată Mer ise, și metoda entitate -relație2.

1 Tardieu H. și col., The Individual Model, International WorkShop on Data Structure Models for Informations
Systems , London, 1998.

Sinteza c urs: Sisteme informatice financiar -bancare 9 Amintim printre metodele sistemice pe cele de concepție în timp real care asigură funcționarea corectă în funcție
de rezultatele produse prin sistem și de momentul la care ele sunt produse. Acestea reprezintă oarecum un s istem de
stimuli/răspuns; stimulii fiind generați de captatori sau de acționari. Atunci când stimulii sunt aperiodici se poate concepe
un sistem ca un ansamblu de procese paralele care cooperează de o manieră în care transferă controlul componentei
apropia te, de la recepția unui stimul. Se disting două clase active în timp real:
 sistemele de urmărire -control;
 sistemele de cumulare de date.
Sistemele de urmărire și control cercetează în permanență numărul de captatori, și, în funcție de valoarea lor,
declanș ează acțiuni care eficien -tizează acționarii (de exemplu, sistemele de alarmă antifurt din imobile).
Sistemele de cumulare de date culeg datele captate pentru procesare și analiză. Perioadele procesului de achiziție și
cele ale procesului de procesare nu s unt în armonie. Astfel, apar diferențe de viteză dictate de recurgerea la un mijloc de
stocare (tampon). Sistemul este organizat după modelul producător -consumator cu mecanisme de excludere mutuală,
pentru a evita cazul unde producătorul și consumatorul de date acced, în același timp, la elementul tampon. Aceste
metode recurg la diverse formalisme, de remarcat fiind cele din rețele Petri pentru aspectul dinamic, care au fost
dezvoltate de formalizări specifice.
Metodele sistemice cuprind de o manieră global ă sistemul informațional și reprezintă a doua generație a metodelor
de proiectare. Reprezentative sunt metodele Information Engeneering, Merise, AXIAL etc. Apropierea se realizează la
nivel conceptual3 și se disting patru niveluri de abstractizare.
1. Nivelul conceptual exprimă opțiunile de gestiune, formulând întrebarea: Ce facem?
2. Nivelul organizațional exprimă alegerile întreprinderii legate de resurse umane și materiale. Se integrează la
acest nivel noțiunile de timp, loc de actori și se pun următoare le întrebări: cine? unde? când? cum?
3. Nivelul logic permite alegerea mijloacelor și a resurselor informatice, făcând abstracție de caracteristicile lor
tehnice precizate.
4. Nivelul fizic este reprezentat prin alegerile tehnice, urmărind specificitatea l or. La fiecare nivel de abstractizare,
sistemul de informare este reprezentat prin trei modele: datele, prelucrările, comunicările.
Ceea ce este specific acestor metode este utilizarea teoriei sistemelor în analiza întreprinderii. Sistemul informatic
este abordat sub două aspecte complementare: datele și prelucrările analizate -modelate independent, cu reunirea lor cât
mai târziu posibil. Spre deosebire de metodele ierarhice, metodele sistemice acordă „prioritate datelor față de prelucrări și
respectă cele t rei niveluri de abstractizare introduse de raportul ANSI/SPARC: conceptual, logic și fizic”4. Avantajele
metodelor sistemice apar din promovarea tehnologiei bazelor de date. Dezavantajele sunt datorate deficiențelor care pot
apărea în modelarea prelucrăril or și a discordanțelor posibile între modelele datelor și prelucrărilor.
Metoda orientată obiect este caracterizată prin atenția deosebită acordată concomitent structurii datelor și
structurii funcționale. Această viziune permite construirea unei baze stab ile în procesul de dezvoltare a modelului și
utilizarea conceptului obiect, unitar de -a lungul întregului ciclu de viață. Toate celelalte concepte: funcții, asocieri,
evenimente gravitează în jurul obiectelor, astfel încât nu este necesară trecerea la alte notații sau interpretări de semantică
în diferite etape de dezvoltare. Metoda orientată obiect se caracterizează prin definirea a trei modele:
 Modelul obiectelor are rolul de a descrie obiectele care intervin în problema de rezolvat și relațiile dintre el e.
Modelul obiectual reprezintă descrierea structurii statice a obiectelor, claselor de obiecte, a operațiilor și atributelor,
precum și a legăturilor și a relațiilor dintre ele.
 Modelul dinamic are rolul de a descrie stările pe care le poate avea un obiec t și evenimentele la trecerea dintr -o
structură în alta. Modelul dinamic descrie interacțiunea dintre obiecte și este focalizat pe aspecte ce se schimbă în timp,
deoarece orice obiect are un ciclu de viață cu un punct de pornire și unul de sfârșit. Modelul dinamic descrie acest ciclu
de viață, ce se întâmplă de -a lungul său, și cum este influențat obiectul.
 Modelul funcțional are rolul de a descrie prelucrările și fluxurile de date. Modelul funcțional prezintă
transformările valorilor datelor, precizând sur sa și destinația lor.
Avantajele oferite de metoda OMT sunt valorificate pe deplin în proiectarea și realizarea de sisteme informatice
care trebuie să răspundă unor noi cerințe, și anume:
 Reprezentarea complexă a realității (firmă, clienți, produse, servic ii etc.);

2 Chen P., The Entity -Relationship Model , „ALM Transaction of Database Syst ems”, 1, mars 1976.
3 Nanci D. și col., Ingénierie des systèmes d’information avec Merise , Sybex, Paris, 1999.
4 Stanciu V. și col., Proiectarea sistemelor informatice , Editura Dual Tech, București, 2002.

Sinteza c urs: Sisteme informatice financiar -bancare 10  Informația gestionată în cadrul unui sistem informatic are tendința de creștere în complexitate, iar manipularea
ei trebuie să fie într -o formă ușor de perceput de către utilizatorul final;
 Sistemele informatice realizate trebuie să fie flexibile în raport cu modificarea structurilor de date și trebuie să
evolueze natural în timp, urmând astfel evoluția organismului economic, bancar, financiar pe care îl deservește;
 Sistemele informatice evoluează spre abordări multimedia, care combină text cu foi de calcul, grafice, animație
și voce.
Majoritatea metodelor orientate pe obiecte utilizează reguli sau operații semantice, după cum urmează:
generalizarea/specializarea, agregarea/descompunerea, combinate cu moștenirea și încapsularea.
Subiecte de autoev aluare

1. Prezentați, caracterizați și exemplificați noțiunile de sistem informațional, sistem informatic, sistem informatic
integrat.
2. Prezentați, caracterizați și exemplificați modul prin care documente justificative asigură datele de intrare în sistemul
informațional economic.
3. Care sunt și prin ce se remarcă cele mai importante programe la nivel de întreprindere?
4. Comentați și exemplificați principiile care stau la baza întocmirii lucrărilor de sinteză economice, financiare și
contabile.
5. Care sunt princi piile utilizate în proiectarea sistemelor informatice din domeniul economic?
6. Criteriile de apreciere a performanțelor zonei economice informatizate. Care sunt și prin ce se caracterizează
fiecare în parte?
7. Ce reprezintă și prin ce se caracterizează selec ția, interpretarea și decizia ca faze ale procesului de evaluare a
unui sistem?
8. Care sunt și prin ce se caracterizează strategiile de proiectare a sistemelor informatice de gestiune?
9. Comentați și exemplificați strategia de proiectare descendentă compar ativ cu cea ascendentă.
10. Structura unui sistem informatic de gestiune.
11. Principii utilizate în proiectarea sistemelor informatice din domeniul financiar -bancar.
12. Caracterizați principalele metode de proiectare a sistemelor informatice.

Întrebări de autoevalu are

1. Mijloacele de prelucrare a datelor economice reprezintă:
a. partea logică a prelucrării datelor în vederea obținerii informațiilor.
b. ansamblul de tehnici și echipamente de culegere, prelucrare și transmitere a informațiilor
c. ansamblul aplicațiilor de pr oiectare
d. ansamblul structurat și corelat de proceduri și echipamente electronice de calcul care permit culegerea,
transmiterea și prelucrarea datelor, obținerea de informații.
e. ansamblul integrat de oameni de specialitate, mijloace și procedee adecvate, pri vind culegerea și
înregistrarea datelor tehnico -economice și financiare
raspuns corect b vezi Sisteme informatice financiar -bancare pag 14

2. Principiul pragului de semnificație:
a. constă în elementele de patrimoniu cu valori însemnate prezentate separat la lucrările de sinteză, iar
cele cu funcții similare de volum redus se vor prezenta mai multe, cumulativ.
b. constă în aceea că nu se admit compensări la bilanț dar nici în contabilitatea curentă între diferite
elemente de patrimoniu, sau între cheltuieli și v enituri de aceeași natură sau de naturii diferite,
extracontabile sau contabile, nelegale și neadecvate principiului imaginii fidele.
c. constă în aceea că evaluarea fiecărui element se realizează separat în contabilitatea curentă, cât și
înainte de întocmire a bilanțului.
d. constă în aceea că informațiile din situațiile de sinteză trebuie să reflecte realitatea economico –
financiară, nu numai forma lor juridică
e. presupune că atât elementele patrimoniale de activ și de pasiv, cât și cheltuielile și veniturile vor f i
evaluate la valori reale, exacte, atât în contabilitatea curentă, cât și la bilanț.

Sinteza c urs: Sisteme informatice financiar -bancare 11 raspuns corect a vezi Sisteme informatice financiar -bancare pag 19

3. Abordarea descendentă:
a. constă în a coborî, pe scara piramidei ierarhice, până la bază și realizând tot odată și o analiză
b. are ca punct de plecare nivelul operațional (aflat la baza piramidei ierarhice) și prin realizarea
informatizării la fiecare nivel în parte, se ajunge la un sistem informatic care poate atinge nivelul
punctul extrem al piramidei
c. reduce i ncertitudinile sistemului informatic financiar -contabil și permit grefarea pe structura acestuia
d. are în vedere conținutul sistemului, capacitatea acestuia de a îndeplini funcții specifice.
e. această viziune permite fixarea opțiunii gestiunii la nivel concept ual, opțiunii organizaționale la nivel
logic și a celei tehnice la nivel fizic.
raspuns corect a vezi Sisteme informatice financiar -bancare pag 23

4. Diagramele de structură ce permit vizualizarea structurii ierarhice, descrierea programului sau a unui
modul fiind stabilite pe mai multe niveluri, prin rafinări succesive caracterizează:
a. metoda Merise
b. metoda orientată obiect
c. metoda entitate –relație
d. metoda SADT (Structured Analisys and Design Technique)
e. metoda sistemică
raspuns corect d vezi Sisteme informatice financiar -bancare pag 34

Capitolul 2. Merise – metodă de studiu și realizare a sistemelor informatice

Introducere
Metoda Merise asigură proiectarea de sisteme de gestiune ambițioase permițând dualitatea între tratamentul
evenimentelor trecute și furnizare a elementelor de previziune aplicabile centrelor de responsabilitate. Ea dispune
de toate instrumentele care să permită realizarea etapizată a unui sistem informatic cu grad mare de
integrabilitate, pornind de la localizarea unui subansamblu reprezentativ. Numele metodei este abrevierea de la
„Methode d’Etude et de Realisation Informatique par le Sous – Ensemble representatif”.

Obiective :
Merise – metodă de proiectare a sistemelor informatice.
Componente stucturale ale Merise.
Ciclul de decizie, viață, a bstractizare
Reingineria sistemelor informatice

Cuvinte cheie
abordare sistemică ciclul de decizie plan strategic ciclul de abstractizare
modelul prelucrărilor studiu preliminar, detaliat ciclul de viață nivel de abstractizare

2.1. Apariția și dezvolta rea Merise ca metodă de proiectare a sistemelor informatice
Dezvoltată de Centrul Tehnic de Informatica (CTI) din cadrul Ministerului de industrie francez ca o unealtă
pentru metodele inginerești de proiectare. Aceasta trebuia să permită echipelor de ingin eri angrenate în realizarea
diferitelor proiecte, încheierea cu success a acestora, cu costuri planificate și în timpul stabilit. Acest proiect a
început în anul 1977 numindu -se Merise, în cadrul realizării acestui proiect fiind implicate un număr de șase
societăți și Centrul de informatică francez.
Inițial scopul metodei Merise a fost de a realiza o metodologie de proiectare și dezvoltare a sistemelor
informatice care putea fi folosită atât de firmele private cât și de serviciile publice, pentru a realiza mai multe
aplicații de procesare a datelor care foloseau baze de date într -un mediu « timp real ».
Punctele de vedere ale prime variante Merise sunt:
a. o abordare sistemică care își are originile în teoria sistemelor introdusă in Franța de J. L Lemoigne.
Această teorie scoate în evidență relația existentă între sistemul informational și sistemul decizional pe de o

Sinteza c urs: Sisteme informatice financiar -bancare 12
parte, precum și legătură sau relația stabilită între sistemul informational și sistemul condus pe de altă parte.
Sistemul informațional pune la dispoziția actorilor (sistemului condus) și a decidenților (sistemului decizional)
toate informațiile necesare pentru a acționa și a decide.
b. o acoperire a întregului ciclu de viață a sistemului informatic cuprinzând schema directoare, studiul
prealabil, st udiul de detaliu, studiul tehnic, realizarea, implementarea și mentenanța sistemului informatic.
c. un ciclu de abstractizare corespunzător celor trei nivele: conceptual (răspunzând la întrebarea Ce?) ;
logic sau organizațional.
d. separarea între modelul datel or (analizate prin prisma modelului entitate -asociere) și modelul
prelucrărilor (prezentând un formalism apropiat celui dezvoltat de graficele Petri).
În timp, Merise a devenit un model dinamic de modelare, care reușește să surprindă comportamentul unui
sistem informatic din faza de analiză și proiectare.
In cadrul metodei Merise se disting două obiective principale: reprezintă o metodă de concepție a sistemelor
informatice; propune un demers metodologic de dezvoltare a sistemelor informatice.
Avantajele ma jore ale Merise ca și metodă de concepție sunt:
 apropiere globală de sistemul informatic și de structura ideală a bazei de date
 descriere a sistemelor informatice pe: nivel conceptual, nivel logic sau organizațional, nivel fizic sau
operațional
 descriere a sistemului informatic utilizând un formalism de reprezentare precis, simplu și riguros pentru
descrierea datelor. Acest formalism este reglementat de standardul ISO sub numele de modelul
ENTITATE – ASOCIERE
 descriere amănunțită a nivelului conceptual perm ițând realizarea unui sistem informatic nou pe baze
solide, independent de organizarea firmei și de alegerea tehnicii de automatizare.
 reprezentarea vizuală folosită în modelul concepual, contribuie într -o mare măsură la stabilirea unui
dialog constructiv între toți partenerii care contribuie la realizarea noului sistem.

2.2. Metoda Merise /2
Proiectul Merise/2 a fost lansat de SEMA Group pentru a surprinde evoluțiile tehnice și organizaționale
ale anilor 90, precum și pentru înlăturarea câtorva carențe ale modelului entitate asociere, utilizat pentru
modelarea datelor în prima versiune. Un grup de studiu a publicat la sfârșitul anului 1990 extensiile modelului,
introducând noțiunile de generalizare și de specializare pentru a explica conceptele de moșten ire, regulile de
integritate și pentru noțiunea de identificator relativ ce permite identificarea unei entitati în raport cu altă entitate.
În cazul metodei Merise/2, modelul prelucrărilor a fost îmbogățit la nivel conceptual prin introducerea :
a. unei dia grame a fluxului de date
b. unui model conceptual al prelucrărilor analitic care acționează încă din faza de concepție
c. noțiunii de ciclul de viață al unui obiect, pentru a surprinde toate etapele parcurse de un obiect în cursul
existen ței sale, în funcție de evenimentele produse.
d. noțiunii de ciclu de viață al unui obiect, introdusă cu scopul de a surprinde toate etapele pe care le
parcurge un obiect în funcție de evenimentele care urmează a se produce.
După nivelul conceptual, se tratează sistemul informatic la nivel organizațional, în care sunt surprinse în
structură toate resursele materiale și umane care contribuie la realizarea sistemului informatic.
La nivelul logic sunt definite interfețele cu utilizatorii, resursele logice ale prelucrărilor precum și
depozitarea, repartiția datelor, nivelul fizic rămânând neschimbat.

2.3. Componente structurale ale metodei Merise
Împrumutând elemente concepuale din teoria sistemelor, autorii metodelor de realizare a sistemelor
informatice au scos în evidență trei ciclu ri în realizarea unui sistem informatic, reprezentarea acestora făcâdu -se
în mod clasic printr -un grafic tridimensional.
2.3.1 Ciclul de decizie
Ciclul de decizie este constituit din toate mecanismele de
decizie inclusiv acele opțiuni de alegere de pe p arcursul dezvoltării
sistemului informatic El permite organizației de a definii mediul și
bazele sistemului informatic, precum și modalitățile de exploatare
ale acestuia. Luarea deciziilor în contextul dezvoltării sau

Sinteza c urs: Sisteme informatice financiar -bancare 13 implementării unui nou sistem informat ic, este un proces care pune față în față managerii, angajații (ca
beneficiari finali ai sistemului informatic) și dezvoltatorii de sisteme informatice. Este esențial să se cunoască
persoanele care participă la adoptarea deciziilor, în particular, este bin e de știut, toate acele persoane implicate în
validarea diferitelor modele folosite de acestă metodă, precum și momentul în care se încheie o etapă și începe
următoarea etapă.
O descriere detaliată a structurii grupurilor de lucru (apare în norma Z67 -101 ANFOR – Recomandări
pentru conducerea proiectelor informatice), în care se menționează existența unui Comitet Director cu rolul de a
stabili orientarea proiectului și de a lua deciziile importante; a unui Grup de proiect, aceasta fiind singura
structură pe rmanentă disponibilă pe parcursul realizării sistemului informatic. Acest grup, responsabil cu
realizarea documentației și a sistemului informatic, este format din șeful de proiect, persoane care se ocupă de
concepția și realizarea sistemului informatic și reprezentanți ai grupului de utilizatori. Comitetul utilizatorilor
participă la elaborarea de soluții și la validarea documentației realizate de grupul de proiect.
Deciziile care vor fi luate, vor face referință la aspecte variate cum ar fi:
a. Decizii de ordin tehnic legate de echipamentele hardware și software
b. Decizii legate de modul de procesare a datelor
c. Decizii ale utilizatorilor finali legate de interfața sistemului
d. Decizii referitoare la identificarea principalilor actori ai sistemului informațional și organizatoric
e. Decizii financiare referitoare la costuri și beneficii
f. Decizii manageriale legate de funcționalitatea sistemului informatic.
Grupurile de lucru vor discuta variantele de opțiuni, responsabilitatea utilizatorilor finali fiind de a
realiza u n raport care să reflecte corect aceste deliberări. Odată întocmit acest raport, el este discutat într -o
întrunire extinsă formată din manager, utilizatori și dezvoltatorii de sisteme informatice, în scopul de a se lua o
decizie finală în ceea ce privește realizarea sistemului informatic și definirea colectivă a unei strategii.
Ca o concluzie putem enunța faptul că metoda Merise identifică automat fiecare punct de decizie
evidențiind chiar și sugestiile procesului decizional precum și persoanele care vor f i implicate în luarea unei
decizii particulare. Merise oferă numeroase oportunități pentru participarea activă a utilizatorilor finali pe toată
aria de cuprindere a ciclului de decizie.

2.3.2 Ciclul de viață
În metoda Merise, ciclul de viață descrie crono logic evoluția proiec -tului de -a lungul întregului parcurs de
funcționare a software -ului, încer -când să arate cum poate fi incorporată o informație în cadrul organizației.
Un prim pas care trebuie realizat îl reprezintă analiza organizației și identificar ea grupurilor și a compartimentelor
sale, scoțându -se în evidență impactul pe care îl va avea sistemul informatic asupra organizației. În urma acestei analize,
se întocmește un raport detaliat, menționându -se aspectele funcționale și tehnice ale sistemului . Finalizarea constă în
realizarea documentației privind modul în care se va implementa, administra și întreține sistemul informatic la nivelul
organizației.
Sub formă tabelară, prezentăm etapele metodei, sintetizând rezultatele fiecărui stadiu.
STUDIU FUN CȚIUNI REZULTAT DECIZIA după
studiu
Studiu
prealabil Studiul situației actuale
Degajarea unui subansamblu reprezentativ Dosar de opțiuni conți -nând mijloacele de
punere în lucru Decizia pentru o
soluție
Studiu
detaliat Studierea detaliată a dife -ritelor domenii pentru
soluția reținută Specificații funcționale „externe” generale
și detaliate Acordul
utilizatorilor
Realizarea Studiul tehnic
Realizarea programelor Sistem de criterii de piață privind „jocul”
de probă al utiliza -torilor Recepția
provizorie
Punerea în
lucru Studiul de ansamblu al problemelor legate de
utilizarea noilor funcțiuni automate Sistem implantat în ambientul real și func –
ționând în regim nor -mal Recepția
definitivă

Ciclul de viață presupune existența a patru etape:
a. Realizarea unui p lan strategic – acesta trasează obiectivele țintă ale organizației din punct de vedere al colectării
informațiilor necesare pentru îndeplinirea obiectivelor strategice și împarte organizația pe domenii sau pe departamente
pentru o mai bună analiză viitoare . Astfel, se asigură premisele unei analize viitoare a fiecărui departament, precum și o mai
bună înțelegere a modului în care departamentele interacționează între ele. Pentru fiecare departament este gândită o schemă

Sinteza c urs: Sisteme informatice financiar -bancare 14 a aplicațiilor, care să includă o poli tică pentru resursele umane, produsele hardware și software , precum și o metodologie
pentru implementarea unei îmbunătățiri viitoare a sistemului.
b. Realizarea unui studiu preliminar – acesta este realizat pentru fiecare domeniu și implică descrierea sistem ului
informatic propus, impactul acestuia asupra organizației, costurile antrenate și beneficiile aduse. Studiul preliminar va
trebui să fie concordant cu planul strategic stabilit anterior. Activitățile care stau la baza realizării acestui studiu sunt :
culegerea de informații despre activitatea organizației, cu menționarea și scoaterea în evidență a particularităților care o
guvernează, realizarea diagramelor de flux, în care sunt evidențiați actorii participanți și schimburile de informații care
survin în tre ei, elaborarea modelului conceptual al datelor și a modelului organizațional al prelucrărilor, analizarea
punctelor slabe ale modelului conceptual al datelor și a modelului operațional al prelucrărilor, în urma cărora se vor face
propuneri de îmbunătăț ire a acestora, alegerea unui model conceptual al datelor și a unui model organi -zațional al
prelucrărilor (prezentarea unei soluții), evaluarea soluției propuse.
c. Realizarea unui studiu detaliat – acesta urmează studiului preliminar și presupune specifica rea detaliată a
cerințelor, precum și specificarea arhitecturii noului sistem. În această fază, se vor avea în vedere toate aspectele care vo r
fi automatizate, incluzând specificațiile de detaliu pentru modelul tehnic și funcțional. În cadrul acestei etape , se vor
realiza, la nivel general, MCD, MCP, MLD, MOP (modelul organizațional al prelucrărilor) pentru soluția aleasă;
definirea mediului de dezvoltare (logic și material); definirea dicționarului de atribute; punerea în practică a studiului
preliminar pr in elaborarea planurilor de lucru, realizarea docu -mentației și a planului de recepție. La nivel detaliat, se vor
stabili fazele de realizare, validarea datelor și prelucrărilor (optimizarea MLD, realizarea unei prime variante a MFD),
evaluarea timpului de realizare a bazei de date, realizarea unui plan cu necesarul de echipamente și materiale.
d. Realizarea sistemului informatic – se execută în doua etape. Studiul tehnic care privește descrierea logică a
arhitecturii sistemului și descrierea modelului fizic al datelor. Cea de -a doua etapă privește realizarea efectivă a
sistemului prin scrierea liniilor de cod, testarea unitară a acestuia și integrarea lui în sistemul informațional al organiza ției
Demersul metodei Merise este în concordanță cu definiția acest ui cuvânt din zona de proveniență a metodei
(Larousse – Franța), care semnifică: „O manieră de a conduce un raționament, de a progresa spre un scop”5. În cadrul
metodei Merise, există o descompunere în etape, precum: studiul prealabil, studiu detaliat, rea lizarea și punerea în lucru.
O etapă poate fi, la rândul ei, descompusă în subetape, fiecare terminându -se cu luarea unei decizii, apărând vizibilă o
selecție a posibilităților.
Demersul metodei se poate reprezenta sintetic astfel:
 Ce trebuie făcut ?– Etape
Subetape
 Cum se face ? – (Legături, Reguli)
 Cu cine se face ? – (Participanți)
În figura, am reprezentat cerințele la care răspunde metoda Merise, constatând interdependențele externe, interne și
fundamentale .

Merise – Ce-cum-cu cine se realizează?
Realizarea studiului prealabil și a celui de detaliu nu presupun neapărat crearea de elemente noi, singurele eforturi
fiind acelea de a adapta metodele de realizare deja folosite la etapele propuse.

5 Merise Method and knowledge, www.cmi.univ -mrs.fr

Sinteza c urs: Sisteme informatice financiar -bancare 15 Ciclul de via ță al unui sistem informatic, așa cum este surprins de metoda Merise, poate fi comparat și cu alte
metodologii, observându -se destule asemănări, dar, în particular, această metodă prezintă o fază suplimentară, care face
referire la planificarea strategică.

2.3.3 Ciclul de abstractizare
După NANCI, axa ciclului de abstractizare este constituită din diferite raționamente făcute in scopul de a realiza
un sistem informatic. Această arhitectura este organizată sub forma unei ierarhii de niveluri, corespunzătoa re diferitelor
percepții ale bazei de date. Grupul de normalizare Nord American ANSI , a elaborat Standard Planing and Requirment
Committee (SPARC), ce -și propune o distincție între cele trei niveluri de abstractizare: nivelul conceptual, nivelul logic și
nivelul fizic.
Putem spune că ciclul de abstractizare este cea mai esențială fază a metodei Merise. Aceasta conține șase niveluri
de abstractizare, împărțite în două mari categorii: niveluri de abstractizare care fac referință la date și niveluri de
abstrac tizare care fac referire la prelucrări.
Nivelurile de abstractizare ale datelor sunt realizate în trei etape: modelul conceptual al datelor (cunoașterea
problemei de rezolvat), modelul logic al datelor, modelul fizic al datelor. Asemănător nivelurilor de abstractizare ale
datelor, prelucrările sunt modelate în trei etape, rezultând un model conceptual al prelucrărilor, un model organizațional
și unul operațional.
În momentul descompunerii subansamblului reprezentativ (SREP) pe subproiecte, apare evidentă s oluția chiar
înainte de a se studia adecvarea „specificațiilor funcționale pentru nevoile utilizatorilor” cu compatibilitatea „întregului”
alcătuit din specificații funcționale, tehnice și restricții financiare definite înainte de studiul prealabil.
În fig ura este prezentată inițierea și derularea pașilor care privesc studiul prealabil .

Studiu prealabil în cadrul metodei Merise
Metoda Merise, în contextul unei unități bancare pentru un sub -ansamblu reprezentativ,pune în evidență unul sau
mai multe subproi ecte care vor intra sub incidența studiului prealabil.
În cadrul studiului prealabil, se pot distinge mai multe subetape6:
» inițializare;
» studiul existent;
» concepția;
» organizarea punerii în lucru;
» bilanțul cantitativ și calitativ;
» concluziile studiului prea labil.
Metoda se utilizează pentru toate proiectele de organizare a unui domeniu de activitate, chiar dacă nu conțin
elemente de informatizare, situație în care nu apare contextul informatic. Se poate constitui într -un instrument al metodei
orice mijloc „c are permite să se execute un lucru: o muncă, o operație” (Larousse).
În metoda Merise se regăsesc instrumente generale (interviul, ancheta), cât și proprii (formalizări individuale și ale
prelucrărilor). Instrumentele specifice Merise sunt utilizate pentru reprezentarea sistemelor informaționale și a diferitelor
niveluri de modele de date și prelucrări, după cum se deduce din sinteza supusă atenției în continuare:

6 Euromethod, www.unl.ac.uk/simt/im251/eumeths.html

Sinteza c urs: Sisteme informatice financiar -bancare 16 Alegere Obiect
descris Nivel de
abstracție Exemplu de modele
Ce se
dorește
să se
facă în
fond? Gestiune Date
Relații
Reguli de
gestiune
Înlănțuiri de
prelucrări Conceptual Modelul Conceptual al
Datelor (invariant static)
Modelul Conceptual al
Prelucrărilor (invariant di –
namic)
Cine
face? Cu
ce?
Când? Organiza –
țional Oameni
Mașini
Rețele
diferite
Repartiție
geografică Logic
sau
Oganiza –
țional Modelul Logic de Date
Modelul Logic de Prelu –
crare
Cum se
face? Tehnic Entități
Programe
Proceduri Fizic
sau
Operațional Modelul Fizic al datelor
Modelul Fizic al prelucră –
rilor
Putem concluziona că la în trebarea „cum se face?” din punct de vedere tehnic, prin modelul fizic al datelor, MFP
poate răspunde prin entități, programe, proceduri . La întrebările „cine? cu ce? când?”, din punct de vedere
organizațional, răspunde modelul logic al datelor și cel al p relucrărilor. La interogarea „ce se dorește a se realiza?”,
datele, relațiile, regulile de gestiune, înlănțuirile de prelucrări apar ca răspuns dedus din modelul conceptual al datelor ș i
al prelucrărilor.
La nivelul Merise, ciclul de abstractizare urmăreșt e o apropiere descendentă, începând cu modelele conceptuale.
Fie că este vorba despre date, fie că este vorba despre prelucrări, aceasta implică acumularea de cunoștințe și analizarea
organizației ca un întreg, luându -se astfel un prim contact cu aspectele reale ale organizației.
Următorul pas al acestui ciclu îl reprezintă evaluarea modelelor logice și organizaționale, fiind necesare luarea
unor decizii cu privire la: cine și ce va face? (ce sarcini vor fi desemnate și cărui departament sau angajat?), când și cum?
Tot în cadrul acestei etape, modelul conceptual al datelor este transformat in modelul logic al datelor.
O ultimă etapă a acestui ciclu o reprezintă realizarea modelelor fizice și operaționale. Aceasta implică identificarea
alternativelor tehnice de realizare a sistemului informatic. Nivelul fizic privește constrângerile de ordin tehnic și material,
această fază fiind, din punct de vedere cronologic, ultima etapă de realizare a sistemului informatic. Putem spune că din
această cauză Merise este ind ependentă de tehnologie până în faza finală. Acest nivel fizic este nivelul la care vor fi luate
în considerare constrângerile legate de sistemul de operare, sistemul de management al bazei de date, precum și de
limbajul de programare folosit. Astfel, sunt identificate toate alternativele de ordin tehnic care fac posibilă definirea
nevoilor informatice. Obiectivele acestui nivel ar trebui să răspundă la întrebarea: cu ce mijloace?
De obicei, un model fizic al datelor poate fi reprezentat de o descriere amăn unțită a motivelor pentru care a fost
ales un anumit SGBD, sau poate fi reprezentat de o serie de definiții SQL. Diagrama de reprezentare a proceselor și
interogărilor pot lua forma unei diagrame a fluxului de date
La toate nivelurile de abstractizare ale ciclului, informațiile care rezultă apar sub formă de grafice sau diagrame, cu
excepția câtorva cazuri, cum ar fi modelul fizic al datelor. Poate cel mai important aspect al metodei Merise îl reprezintă
regulile de transformare sau de deducere a unui mode l din modelul anterior.
În continuare, supunem atenției sinteza nivelurilor de abstractizare, corelate cu ansamblul date -prelucrări.
DATE PRELUCRĂRI
CONCEPTUAL Modelul conceptual al datelor
MCD
– Concepte fundamentale
– Relații semantice Modelul concept ual al prelucrărilor
MCP
– Descrierea macroscopică (noțiunea de
proces)
LOGIC Modelul logic de date
MLD
Integrarea restricțiilor de organizare
– Traducerea în SGBD
 entitate
 relație
instanță(realizare) Modelul logic al prelucrărilor
MLP
– Integrarea a legerii opțiunii
– Repartiția om -mașină
– Timp real -timp diferit
Desfacerea proceselor  proceduri  faze 
sarcini
FIZIC Modelul fizic al datelor
MFD Modelul fizic al prelucrărilor
MFP

Sinteza c urs: Sisteme informatice financiar -bancare 17 DATE PRELUCRĂRI
Descrierea bazelor de date
Noțiuni de înregistrare Descrierea program elor
Descrierea procedurilor
Corelând cele prezentate anterior referitoare la „Merise – Ce, cum, cu cine se realizează?” nivelurile de abstracție,
modelele rezultate, deducem și supunem atenției următoarele expresii:

Viziunea exterioară: model extern = o vedere a unui utilizator = Ansamblul
informațiilor operaționale pentru o prelucrare FORMALISM
= Model individual
Conceptele adecvate pentru fiecare nivel al modelării datelor și prelucrărilor sunt caracterizate printr -un grad mare
de generalitate, dar, î n același timp, și de relevanță, surprinzând aspecte semnificative din realitatea supusă modelării.

2.4. Merise metologie de dezvoltare sistemică

Merise reprezintă o metodologie de dezvoltare a sistemelor informatice care urmareste o abordare
sistemica a firmei. Merise încurajează cooperarea și comunicarea intre diferitele grupuri responsabile cu
dezvolarea sistemului, acordand tuturor actorilor implicati in realizarea proiectului, la exprimarea unei opinii.
Merise tine seama de capabilitatile organizati ei, asigurandu -se ca sistemul care va fi realizat va fi utilizabil,
folositor, și relevant.
Metoda Merise modelează datele la trei nivele de abstractizare :, conceptual, logic și fizic. Similar,
prelucrările vor fi modelate asemănător, cele trei nivele de abstractizare vor fi: conceptual, organizațional și
operațional.
Un alt aspect important al metodei Merise este acela că această metodologie a fost desemnată să reflecte
schimbările de ordin general, noile direcții și nevoi pot fi incluse în proiect pe măsură ce sistemul informatic se
dezvoltă. In plus, față de metodologiile convenționale de proiectare și analiză a bazelor de date care sunt
orientate spre aspectul static al unui sistem informatic, Merise include pe lângă analiza evenimentelor, operațiilo r
și sincronizărilor, toate aspectele dinamice ale unui sistem informatic.
Subiecte de autoevaluare
1. Care sunt și prin ce se caracterizează punctele de vedere ale metodei Merise asupra procesului de proiectare și
realizare a sistemelor informatice?
2. Prezentați și exemplificați obiectivele principale, avantajele, dar și dezavantajele pe care le oferă metoda
Merise.
3. Ce este și prin ce se caracterizează ciclul de decizie și decizia?
4. Ciclul de viață al unui sistem informatic și principalele etape de existen ță.
5. Ciclul de abstractizare și nivelurile sale de acțiune.

Întrebări de autoevaluare

1. Relația existentă între sistemul informational și sistemul decizional, precum și legătura stabilită între
sistemul informational și sistemul condus este scos în evidenț ă de:
a. abordarea sistemică
b. ciclul de abstractizare
c. ciclul de viață
d. diagrama fluxului de date
e. nivelul conceptual
raspuns corect a vezi Sisteme informatice financiar -bancare pag 41

2. În cadrul metodei MERISE /2 s -au stabilit extensiile modelului care se referă la:
a. generalizare și de specializare
b. separarea între modelul datelor și modelul prelucrărilor
c. demersul metodologic de dezvoltare a sistemelor informatice
d. abordarea sistemică
e. descriere a sistemului informatic utilizând un formalism numit ENTITATE -ASOCIERE

Sinteza c urs: Sisteme informatice financiar -bancare 18 raspuns corect a vezi Sisteme informatice financiar -bancare pag 42

3. Realizarea unui studiu preliminar
a. este realizat pentru fiecare domeniu și implică descrierea sistemului informatic propus, impactul
acestuia asupra organizației, costurile antrenate și bene ficiile aduse
b. trasează obiectivele țintă ale organizației din punct de vedere al colectării informațiilor necesare
pentru îndeplinirea obiectivelor strategice și împarte organizația pe domenii sau pe departamente
pentru o mai bună analiză viitoare
c. asigură premizele unei analize viitoare a fiecărui departament precum și o mai bună înțelegere a
modului în care departamentele interacționează între ele
d. presupune specificarea detaliată a cerințelor precum și specificarea arhitecturii noului sistem
e. care priveste descrierea logica a arhitecturii sistemului și descrierea modelului fizic al datelor
raspuns corect b vezi Sisteme informatice financiar -bancare pag 46-47

4. Un aspect important al metodei Merise este acela că:
a. această metodologie a fost desemnată să reflect e schimbările de ordin general, noile direcții și nevoi
pot fi incluse în proiect pe măsură ce sistemul informatic se dezvoltă
b. utilizează reguli sau operații semantice, după cum urmează: generalizarea/specializarea,
agregarea/descompunerea, combinate cu mo ștenirea și încapsularea
c. concepția sa constă în crearea, pornind de la specificațiile, unui ansamblu unitar în interacțiune
având fiecare o funcție clar definită
d. are ca punct de plecare nivelul operațional (aflat la baza piramidei ierarhice) și prin realiz area
informatizării la fiecare nivel în parte
e. consideră că un anumit domeniu este compus din părți corelate între ele și cu legături cu exteriorul ,
caracteristică pentru toate sistemele informaționale
raspuns corect a vezi Sisteme informatice financiar -bancare pag 53

Capitolul 3. Elemente definitorii în modelarea bazelor de date cu ajutorul metodei Merise

Introducere
Pentru definirea modelului conceptual al datelor se apelează la modele intermediare care sunt folosite ca suport
al unei metodologii de proi ectare. Modelul conceptual utilizează o abstractizare prin relație, recunoscută de ISO
fiind o apropiere de modelul entitate -relație.

Obiective :
Clarificare noțiuni de bază – atibut, entitate, asociere, cardinalitate
Prezentarea și realizarea modelului c onceptual al datelor
Prezentarea și realizarea modelului conceptual al prelucrărilor

Cuvinte cheie
enititate model conceptual al datelor dependență funcțională model conceptual al prelucrărilor
asociere atribut, domeniu cardinalitate operație

3.1. Mode lul conceptual al datelor
Modelul conceptual al datelor este un ansamblu de concepte și reguli de combinare care permit
reprezentarea realității circumscrise domeniului supus informatizării. Pentru definirea modelului conceptual al
datelor se apelează la m odele intermediare care sunt folosite ca suport al unei metodologii de proiectare.
Modelul conceptual utilizează o abstractizare prin relație, recunoscută de ISO fiind o apropiere de modelul
entitate -relație.
Modelul conceptual al datelor corespunde unei s tructuri generale ale datelor acceptabilă de toți
utilizatorii potențiali, el depozitând semantica bazei de date, scopul său final fiind de a realiza o reprezentare
abstractă cât mai fidel posibilă a universului modelat. Modelul conceptual permite trecerea de la un concret

Sinteza c urs: Sisteme informatice financiar -bancare 19 inaccesibil din punct de vedere informatic, la un abstract manipulabil. Putem spune că modelarea datelor
reprezintă o activitate care constă în determinarea obiectelor sistemului informatic, activitate care ne permite să
obținem o imagine statică a structurii acestui sistem. De menționat este faptul că rezultatul final al activității de
modelare nu este o reprezentare a unui sistem informatic real, ci reprezintă o viziune abstractă a acestuia,
reprezentare ce poate lua fie o formă grafică, fie matematică, verbală sau mentală.
La baza activității de modelare stă observarea sistemului, observare care în urma unor procese deductive,
inductive, previzionare și descriptive ar trebui să conducă la o viziune și o reprezentare a sistemului cât mai
redusă și cât mai abstractă.
Identificarea principalelor obiecte care stau la baza modelului conceptual de date, din punct de vedere al
metodei Merise se referă la noțiunile de entitate și asociere .
În literatura de specialitate există mai multe definiții cu privire la noțiunea de entitate, unele dintre ele
reușind într -o manieră mai mare sau mai mică să surprindă toate aspectele caracteristice ale acesteia. Considerăm
că o definiție cuprinzătoare a fost formulată de Stanciu V. care enunța entitatea ca fii nd „un obiect material sau
abstract al realității modelate caracterizat de o existență proprie,
cu o identitate proprie, obiect caracterizat de anumite proprietăți
care-l fac identificabil în raport cu alte obiecte ce prezintă același
comportament”.
Un exe mplu concret în cazul entității pot fi obiectele
apartamentul meu, studentul Georgescu, firma X, etc. Fiecare
obiect menționat mai sus este caracterizat de anumite proprietăți.
“Studentul Georgescu” este caracterizat de o anumită vârstă,
înălțime, adresă d e domiciliu, posedă un anumit număr de
identificare în actul de identitate; deci putem spune că proprietățile care definesc obiectul student Georgescu
sunt: nume, prenume, vîrsta, înălțimea, adresa de domiciliu, codul numeric personal. Toate aceste proprie tăți
definitorii ale unui obiect poartă denumirea de atribute .
Din definiția conceptului de entitate și din exemplele anterioare putem să extragem o definiție a
atributului în sensul că acesta reprezintă una sau o mulțime a caracteristicilor unei entități, care ajută la
identificarea unui obiect din mulțimea obiectelor asemănătoare ce fac parte din realitatea modelată.
La o observare mai atentă a realității se constată că atributele nume, prenume, vârstă, înălțime, adresă de
domiciliu, cod numeric persona l, reprezintă caracteristici care pot fi asociate mai multor obiecte (entități). Faptul
că atributele sau caracteristicile unui obiect aparținând realității de modelat, nu caracterizează doar o singură
entitate ci o multime de entități, ne duce spre conclu zia că mulțimea acestor entităților caracterizate de aceeiași
tipologie constructivă formează un tip de entitate
Atributele sunt percepute din punct de vedere informatic ca variabile ale datelor, caracterizate prin
natura valorilor pe care le pot lua acest ea la un moment dat. Din acest punct de vedere, al naturii valorilor pe
care le poate lua, atributul poate fi: numeric, alfanumeric, șir de caractere.
Dacă luăm în considerare datele (ca model de reprezentare a informației) putem prezenta o clasificare a
atributelor în: elementare – reprezentarea datei este indivizibilă în raport cu informația pe care o reprezintă. Se
mai numesc și atribute atomice; compuse – formate din mai multe atribute elementare. Ex: atributul adresa se
poate descompune în mai multe at ribute cum ar fi: oraș, stradă, număr.
Dacă facem referire la realitatea modelată putem identifica următoarele categorii de atribute:
a. optionale – în cazul în care anumite entitățti nu pot prezenta la un moment dat o anumită valoare pentru
un atribut. Ex: a tributul limbi străine cunoscute de o persoană – nu toate persoanele cunosc o limbă straină;
b. obligatorii – sunt asociate în special acelor atribute care contribuie la identificarea univocă a unei
entități, aceste atribute trebuind să prezinte neapărat o va loare.
Din punct de vedere al valorilor pe care le poate lua un atribut la un moment dat putem distinge atribute:
a. multivaloare – atunci când valoarea pe care o poate lua un atribut la un moment dat, prezintă mai multe
realizări concomitente pentru ace iași entitate. Ex: atributul limbi străine cunoscute de o persoană – la un moment
dat o persoană poate cunoaște atât limba engleză cât și limbile franceză și germană;
b. monovaloare – așa după cum îi sugerează și numele, atributele monovaloare prezintă doar o singură
valoare pentru acel atribut.
Din punct de vedere al rolului pe care îl îndeplinește acel atribut în cadrul modelului distingem atribute
cu rol de:

Sinteza c urs: Sisteme informatice financiar -bancare 20 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: atributu l 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
Student;
c. cheie externă – reprezintă un atribut sau o
multime de atribute de finite 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 poa te 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 . Dacă atributele reușeau să surprindă partea statică a unei entități sau implicit a
tipului de entitate (puțin probabil ca mulțimea caracteristicilor unui obiect să se modifice în timp), valorile
atributelor implicit domeniul acestora reușesc să surprindă partea dinamică a unei entități. În acest sens luăm ca
exemplu atributul vârsta ce caracterizează entitatea Georgescu. Faptul că la un moment dat acest atribut ia
valoarea 20, scoate în evidență realitatea că la momentul respectiv entitatea Georgescu are vârsta de 20 de ani.
Dar aceiași realitate ne confirmă faptul, că odată cu trecerea timpului entitatea Georgescu îmbătrânește adăugând
câte o unitate la valoarea atributului vârsta. Se observa pe baza acestui raționament, că de -a lungul timpului
atributul vârsta, în sine ca și caracteristică și denumire nu s -a modificat (rămânând staticâ ), valoarea pe care o
poate lua acest atribut este una schimbatâ reușind să surprindă evoluția entități Georgescu prin prisma procesului
de îmbătrânire.
3.2. Relații sau asocieri între date
În ceea ce privește relațiile între date, apar în discuție două as pecte.
Un prim aspect se referă la apartenența datelor la un anumit tip de entitate. Întreaga teorie legată de
formele structurale sub care se pot lua modelarea datele stă sub patronajul cercetătorului american E.F.Codd.
Datorită acestuia, ca urmare a lucr ării sale A Relational Model of Data for Large Shared Data Banks publicată în
anul 1970, a apărut conceptul de bază de date relatională. Fiind un matematician ca formare profesională, acesta
se folosește de conceptele matematice de algebra relatională pent ru a grupa datele în mulțimi omogene având ca
obiectiv definirea relațiilor între submulțimile comune. Conform acestei teorii, Codd ajunge la concluzia că
informația poate fi grupată natural în mulțimi diferite asemănătoare cu structura unui tabel.
Astfe l, într -un SGBD relațional, datele sunt organizate și percepute de către utilizator sub forma unor
tabele bidimensionale, care corespund modelului abstract tip de entitate. Rândurile acestui tabel corespund unui
tuplu, având drept corespondent în modelul a bstract entitatea; iar coloanele corespund atributelor.
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 de pendență 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ă atribut e 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ă pri ntr-o săgeată având o
orientare de la atributul A către atributul B.

Sinteza c urs: Sisteme informatice financiar -bancare 21 Pentru exemplificare să luam relatia Persoane, relatie care este formata din multimea atributelor Cod
numeric personal, Nume, Prenume, Varsta, Adresa. Pentru o anumita valoare a atribu tului Cod numeric personal
(1831103463023) ii va corespunde intodeauna aceiasi valoare pentru atributul Nume (Marinescu), putand spune
ca atributul Nume este dependent functional de atributul Cod numeric personal.
Ca o conventie, dar și prin natura a ceea ce reprezintă atributele din partea stanga a sagetii poarta
denumirea de atribute determinante. Atributele din partea dreapta a sagetii denumindu -se atribute determinate.
Un tip aparte de dependenta functionala o reprezinta dependenta functionala multival oare.
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, mult imile 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

Un al doilea aspect pe care trebuie să -l avem in vedere se referă la 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 .
3.2.1. Tipologia asocierilor
1.Relația unu -la-unu (one -to-one), se mai numește și biunivocă . Două ta bele unite printr -o relație unu la
unu sunt similare, în practică, cu un tabel care cuprinde toate câmpurile celor două tabele. Fie doua tabele,
tabelul A si tabelul B aflate intr -o asociere, prin definiție, într -o asociere de acest tip o înregistrare din tabelul A
poate avea cel mult o înregistrare corespunzătoare în tabelul B și invers, o înregistrare din tabelul B îi
corespunde cel mult o înregistrare în tabelul A.
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 uz ual reprezentarea grafică a unei asocieri între două
tipuri de entități se simbolizează printr -o elipsă în care se trece numele asocierii.
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 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ă , desmnând obligativitatea unei realizăr i de a participa la o
asociere, iar Y se numește cardinalitate maximală fiind percepută ca volumul participării la asociere.

3.2.2. Diagramele modelului conceptual. Cardinalitatea unei asocieri.
Fie o relație biunivocă de unu -la-unu, considerăm cazul în care ne confruntăm cu furnizori specializați,
aceștia putând livra doar o singură materie primă, livrarea realizându -se doar o singură dată. În urma acestor
condiții putem spune ca tipul de asociere care pune în legătură cele două tipuri de entități este d e unu -la-unu.

Sinteza c urs: Sisteme informatice financiar -bancare 22 Pentru o relație de unu-la-mulți, să luăm exemplul unor persoane care dețin apartamente. Restricțiile
considerate asupra acestui model fac referire la faptul că fiecare persoană deține cel puțin un apartament sau mai
multe; conform legii un apartament aparține unei singure persoane.

Exemplul studenților care frecventează cursuri scoate în evidență o relație de mulți -la-mulți. Condițiile
luate în considerare pentru această relație se referă la faptul ca există cel puțin un student care poate frecventa
mai multe cursuri, și evident, la un curs pot participa mai mulți studenți .

3.3. Modelul logic al datelor
După cum s -a observat din capitolele anterioare, realizarea modelului
conceptual al datelor este independentă de modelul logic a l datelor. Trecerea de la
MCD la MLD ține seama două tipuri de regululi principale, reguli care se referă la
distribuția datelor pe tipuri de entitați, precum și de cardinalitățile prezentate de
asocierile tipului de entitate. Aceste elemente metodologice poartă denumirea de
reguli de transformare.
Regula 1. Fiecare tip de entitate se transformă într -un tabel, primind ca
denumire a coloanelor, numele atributelor din care este format acel tip de entitate.
Numele tabelului prezentat va prelua numele tipului de entitate iar identificatorul tipului de entitate se va
transforma in cheia primară a tabelului respectiv. Astfel un tabel este perceput ca o relație între mai multe
atribute care caracterizează același obiect (entitate).
Conform aplicării primei reguli tipul de entitate autovehicole se va transforma într -o relație de forma:
R_Autovehicole = ( Nr înmatriculare , Marcă, Serie motor, Tip, Culoare)
Regula 2 . În cazul în care două entități prezintă pentru o asociere cardinalitatea de (1,1), în mod normal
fiecare entitate poate primi ca și cheie externă, cheia
primară a celeilalte entități.
În realitate trebuie realizat un raționament logic
asupra ordinii de apariție a tipurilor de entitați.
Din punct de vedere teoretic cheia primară CNP
poate deveni cheie ext ernă în tabela Impozit pe venit, dar
și Cod impozit poate deveni cheie externă pentru tabela
Angajat (nu simultan). Considerăm totuși a fi corect ca
identificatorul CNP să devină cheie externă în tabela Impozit pe venit deoarece pentru a putea fi plătit un impozit
pe venit ar trebui să existe mai întâi o entitate angajat.
R_Angajat = ( CNP , Nume, Prenume, Adresă, Venit)
R_Impozit pe venit = ( Cod impozit , Dat ă de plată, Valoare, CNP )

Sinteza c urs: Sisteme informatice financiar -bancare 23 Cheile externe, în modelul logic de date se simbolizează prin subliniere cu o linie punctată.
Regula 3 . În cazul în care două entități, au o asociere de tipul (1,n), cheia primară a tabelei care
prezintă la asociere o cardinalitate (1,n), va devenii cheie externă în tabela care prezintă în cadrul
asocierii cardinalitatea (1,1).
Aplicând această regulă, modelul logic al datelor
pentru acest model conceptual al datelor va fi:
R_Angajat = (Marcă , Nume, Prenume, Adresă, Cod
sucursală )
R_Sucursală = ( Cod sucursală , Adresă, Telefon)
Același raționament se aplică și în cazul în care
una dintre tipuri de entități prezintă în cadrul
asocierii o cardinalitate (0,1). Cheia primară a
tipului de entitate din partea asocierii care prezintă
o cardinalitate (0,1), va deveni cheie externă pentru
celălalt tip de entitate.
Regula 4 . În cazul în care două entități
prezintă o asociere de tipul (n,m), relația în sine se
transformă într -o tabelă avănd obligatoriu ca și chei externe, cheile primare ale celor două tabele.
Modelul logic aferent modelului conceptual din figura va fi următorul:
R_Contra cte de asigurare = ( Nr contr , Dată semnare, Dată început)
R_Riscuri = (Cod risc , Denumire risc, Franciză)
R_Prevăd = ( Nr contr , Cod risc )
Aceiași regulă se aplică și în cazul în care relația deține atribute, indiferent de cardinalitățile pe care le
prezin tă la asociere tipurile de entități.
3.4. Model organizațional
Inspirat din rețelele Petri, modelul conceptual al prelucrărilor (MCP) are menirea ca în funcție de
domeniul investigat să răspundă la întrebarea: Ce prelucrări se realizează?
Fluxurile, recept orii (stimulii) și emițătorii (reacții) prin domeniu sunt modelări ale evenimentelor și
rezultatelor. Evenimentele și rezultatele pot fi externe sau interne. Cele externe provin sau sunt destinate unui
actor extern, iar cele interne rămân în domeniu pentru a asigura continuitatea procesului, urmărind satisfacerea
sistemului de pilotaj.
Operația descrie comportamentul domeniului la declanșarea produsă prin mai multe evenimente. Ea
este o secvență continuă de acțiuni elementare producătoare de evenimente care se execută neîntrerupt din
momentul declanșării acesteia de către unul sau mai multe evenimente. Operația constituie un bloc de prelucrare
cuprinzând acțiuni elementare generatoare de evenimente interne, înlăturând posibilitatea de generare a
evenimentelo r intermediare între acțiunile ce aparțin operației. Operația emite, în contrapardidă retur rezultate în
funcție de condițiile traduse prin expresii logice.
Prelucrările reprezintă partea dinamică a sistemului informațional. Ele descriu acțiunile exercitat e
asupra datelor cu scopul obținerii informațiilor dorite, reprezentând materializarea sub formă de acțiuni a
regulilor de gestiune specifice activității întreprinderii. MCP urmărește reprezentarea înlănțuirii operațiilor cu
definirea condițiilor necesare pentru declanșare dar și consecințele derulării operațiilor respective. În
reprezentarea acestei înlănțuiri de operații și evenimente declanșatoare în cadrul modelului, se impune
respectarea unor cerințe determinate de regulile de gestiune. Asocierea MCP ↔ eveniment indică faptul că ceva
anume s -a întâmplat și în consecință sistemul trebuie să reacționeze.
Sincronizarea reprezintă o condiție prealabilă a unui flux de operații în care mai multe evenimente
participă la declanșare. Sincronizarea se traduce pri n expresii logice. Regulile de sintaxă și de funcționare permit
verificarea coerenței MCP.
Modelul conceptual de comunicație (MCC) are drept
scop reprezentarea fluxurilor de informații sau mesaje între
diferitele subsisteme omogene ale întreprinderii, num ite
domenii. Domeniile privesc marile funcțiuni sau procese
majore din întreprindere. Un mesaj este trecerea de informații
între domenii sau între un partener (factorul extern) al

Sinteza c urs: Sisteme informatice financiar -bancare 24 întreprinderii și un domeniu. Mesajul este emis de o parte (partener sau dom eniu, emițător) și recepționat de alt
element structural (receptorul).
Construcția modelelor organizaționale reprezintă o etapă delicată și deseori complexă datorită varietății
și interacțiunii parametrilor de luat în considerație: organizarea intrărilor, varietatea soluțiilor organizaționale
posibile, criterii de evaluare (economice, sociale, ergonomice, tehnice). Totodată poate fi considerată ca o etapă
accesibilă, deoarece nu apar dificultăți induse de abstractizare.
Problematica MOP Problematica MOD Problematica
MOC
– Repartizarea prelucrărilor pe centre, unități și posturi de
lucru
– Caracterizarea sarcinilor: posturile raportate, gradul de
automatizare, termenul de răspuns, modul de funcționare,
regulile și procedurile aplicabile, frecvența, durata,
capacitatea – Repartizarea datelor:
pe centre, unități și posturi
de lucru
– Volumetrie
– Istoric
– Securitate – Schimburile de
mesaje între centre
Modelarea privește sistemul de informații organizațional care se finalizează prin confruntarea
modelelor; aplicând următoarele tehnici: abordarea participativă, abordarea printr -o grilă de coerență MCD –
MOP – MOD, machetare și validarea MCD – modele externe. Modelele externe privesc datele drept mesajele
legate la evenimente –rezultate. Continuarea studiului p resupune modelarea sistemului și se surprind în acest
moment delimitările de modele care apar utilizând percepția de gestionare (modele organizaționale) și viziunea
specialistului informatic (modelele logice și fizice).
În cele ce urmează supunem atenției sinteza reunirii modelelor logice și fizice ale datelor, prelucrărilor,
comunicației.
Problematica MLP și al MFP Problematica MLD și
al MFD Problematica MLC și al
MFC
-Repartizarea prelucrărilor informatizate:
centre, unități logice de prelucrare.
– Modul arizare – Transformare MOD
după tipul SGBD
– Dimensiunea MLD
– Optimizarea – Mesaje între centre prin
magistrale informatice
Concluzionând ideile prezentate pe parcursul acestui subcapitol, afirmăm că utilizarea metodei Merise în
contextul cadrului metodo logic al conducerii proiectelor informatice este oportună deoarece:
 determină limitele nivelelor de preocupare (conceptual, logic, fizic);
 permite exprimarea unor concepte complementare legate de conducerea studiilor detaliate;
 propune un plan de lucru de taliat pentru derularea fiecărei etape pentru a facilita conducerea proiectelor
în concepția sistemelor informatice;
 furnizează documentele tip ISO pentru constituirea documentației aferente fiecărei etape.
Se poate afirma că este o metodă „deschisă”, susc eptibilă să se integreze într -un cadru metodologic mai
larg.
Subiecte de autoevaluare

1. Modelarea datelor la nivel conceptual.
2. Ce este și prin ce se caracterizează modelul conceptual al datelor?
3. Prezentați, caracterizați și exemplificați entitatea și as ocierea.
4. Clasificați, caracterizați și exemplificați atributul.
5. Ce reprezintă și prin ce se caracterizează domeniul. Exemplificări economice?
6. Relații sau asocieri între date.
7. Dependență funcțională, caracterizare, clasificare și reprezentare specifică.
8. Relații între tabele de tip unu -la-unu. Exemplificări comentate.
9. Relații între tabele de tip unu -la-mulți. Exemplificări comentate.
10. Relații între tabele de tip mulți -la-mulți. Exemplificări comentate.
11. Conceptul de cardinalitate. Serii de valori acceptat e. Exemplificări.
12. Modelul logic al datelor.

Sinteza c urs: Sisteme informatice financiar -bancare 25 13. Trecerea prin reguli de transformare de la MCD la MLD. Exemplificări de natură economică.
14. Modelul organizațional al datelor și prelucrărilor.

Întrebări de autoevaluare

1. Modelul conceptual al datelor este:
a. un ans amblu de concepte și reguli de combinare care permit reprezentarea realității circumscrise
domeniului supus informatizării
b. realizat pentru fiecare domeniu și implică descrierea sistemului informatic propus, impactul acestuia
asupra organizației, costurile antrenate și beneficiile aduse
c. constituit din toate mecanismele de decizie inclusiv acele opțiuni de alegere de pe parcursul
dezvoltării sistemului informatic
d. caracterizat prin atenția deosebită acordată concomitent structurii datelor și structurii funcțio nale
e. o consolidare a unui proiect care ne permite să avem în faza finală, informatizarea completă a unui
sistem informațional –organizațional specific unui organism economic supus analizei
raspuns corect a vezi Sisteme informatice financiar -bancare pag 54

2. Operația reprezinta
a) o suma de sarcini de coordonare și decizie corelată cu obiectivele fixate
b) o secvență continuă de acțiuni elementare producătoare de evenimente care se execută neîntrerupt
din momentul declanșării acesteia de către unul sau mai multe evenimente
c) un proces simplu și rapid de așezare a tabelelor și a câmpurilor necesare
d) optimul sistemului informatic financiar – contabil
e) instrucțiuni SQL încapsulate în codul program
raspuns corect b vezi Sisteme informatice financiar -bancare pag 73

Capito lul 4. Metoda Object Modeling Technique de proiectare a sistemelor informatice

Introducere
OMT – Object Modeling Tehnique – este bazată pe modele ca abstracții ale problemelor din lumea reală, care
urmăresc focalizarea aspectelor importante ale problemei și omisiunea celor irelevante.

Obiective :
Perceperea corectă a metodologiei OMT de proiectare a sistemelor informatice.
Prezentarea mijloacelor specifice de reprezentare corelat cu etapele de realizare a unui proiect.
Detalierea și exemplificarea modu lui de realizare a modelului obiect, dinamic și funcțional în accepțiunea
OMT

Cuvinte cheie
diagramă analiză proiectare obiectuală scenariu proces
model proiectare de sistem atribut -multiplicitate flux actor

Un sistem informatic este privit ca un ansam blu de obiecte care cooperează între ele și tratează obiectele
ca instanțe ale unei clase în interiorul unei ierarhii.
Metodele obiect integrează modelarea de structură cu cea comportament. Obiectul reprezintă o entitate
(reală sau abstractă) a lumii supu se modelării, caracterizată prin identitate, stare și comportament. În fapt,
obiectul reprezintă un element identificabil, concret sau abstract, caracterizat prin structură, atributele și metode
proprii.
Corespunzător metodologiei se parcurg următorii pași : definirea problemei; elaborarea unei modalități
informale de identificare a datelor și a funcțiilor relevante corespunzătoare problemei; formalizarea strategiei
prin identificarea obiectelor și atributelor, operațiilor asupra obiectelor, stabilirea insta nțelor și implementarea
operațiilor.

Sinteza c urs: Sisteme informatice financiar -bancare 26 Metoda OMT, folosită pentru proiectarea software -lui contează pe mijloacele de reprezentare: diagrama
de flux de date pentru surprinderea comportamentului dinamic și diagrama modulară (arhitectura produsului)
pentru sur prinderea comportamentului static.
OMT propune trei tipuri de modele, obiect, dinamic și funcțional pentru scopuri și descrieri diferite de
obiecte, interacțiuni, transformări. Cele trei tipuri de modele sunt de fapt proiecții ale unei singure informații,
fiecare prezentând un anumit specific. Fiecare model în OMT poate fi reprezentat prin diagrame distincte:
pentru modelul de obiecte – CAD (Class Association Diagram sau DAC Diagrama de Asociere a Claselor);
pentru modelul dinamic – ETD (Event Trace Diagra m sau DTE Diagrama de Trasare a Evenimentelor), precum
și STD (State Transition Diagram) sau DTS (Diagrama de Tranziție a Stărilor); pentru modelul funcțional se
apelează la DFD (Diagrama de Flux de Date – Data Flow Diagram); DCC (Diagrama de Comunicare a Claselor,
CCD Class Comunication Diagram); DGM (Diagrama de Generalizare a Mesajelor – MGD Message
Generalization Diagram).
4.1. Etapele ciclului de realizare a unui proiect în abordarea orientată –obiect
Analiza are drept obiectiv modelarea problemei din l umea reală sau definirea Domeniului Aplicației
(Application Domain). Proiectantul creează modele de obiecte și funcții fără a lua în considerare aspectele de
implementare. În figura am reprezentat o secvență a activități analizei și modelării evenimentului studiat.

Modelul de analiză trebuie înțeles și validat de utilizator. Această etapă are ca rezultat formularea problemei,
modelul obiectual, modelul dinamic și cel funcțional.
Analiza este utilă clarificării cerințelor, realizării conexiunii benefic iar-producător bazată pe înțelegere,
reprezentând în același timp cadrul pentru proiectarea ulterioară și implementare. Finalizarea etapei analiză –
modelare se materializează prin definirea unui model precis, concis, inteligent și corect al viitorului siste m.
Proiectarea de sistem – împarte modelul de analiză în părți mai mici, ușor de înțeles și construiește
arhitectura sistemului prin identificarea subsistemelor și transpunerea lor pe hardware -ul disponibil. Proiectarea
de sistem pornește de la domeniul ap licației și ia în considerare conceptele de implementare adică optimizarea,
rafinarea și extinderea celor trei modele până la nivelul de detaliu care să permită implementarea. Se poate spune
că, analiza descrie problema iar proiectarea de sistem descrie so luția. Rezultatul acestei etape este realizarea
arhitecturii de bază a sistemului și adoptarea deciziilor privind strategia la nivel global.
Scopul acestei etape este transpunerea declarației problemei așa cum a fost definită în etapa de analiză
într-o arh itectură adecvată, bazată pe divizarea în subsisteme precum și decizii de implementare la nivel global.
Rezultatul este un concept de implementare care rafinează, optimizează și extinde cele trei modele preluate din
etapa de analiză, până la etapa de proie ctare obiectuală care să permită implementarea propriu -zisă.
Proiectarea de sistem presupune două faze: construirea arhitecturii sistemului; modelarea detaliilor
subsistemelor.
În faza de construire a arhitecturii sistemului se dezvoltă clase de bază, pe s eama cărora se studiază
funcționalitatea sistemului și se decide privitor la configurația sistemului hardware -software; sistemul de
gestiune al bazelor de date; interfața grafică de conexiune cu utilizatorul.
În a doua fază se modelează în detaliu fiecare sistem individual, accentul pus pe diferitele modele fiind
diferit de la un tip de sistem la altul. Se creează așa numitele clase container organizate pe sistem.

Sinteza c urs: Sisteme informatice financiar -bancare 27 Proiectarea obiectuală – are drept scop alegerea modului de implementare pentru fiecare clasă,
proiectându -se algoritmi și implementându -se asocierile. Se realizează gruparea claselor în superclase pentru
ușurarea implementării și pentru îmbunătățirea performanțelor. În urma acestei etape se obțin: modelul obiectual
detaliat, modelul dinamic detali at și modelul funcțional detaliat.
In etapa de proiectare obiectuală operațiile identificate în etapa de analiză sunt transpuse în algoritmi iar
clasele, atributele și asocierile sunt implementate în structuri de date specifice. Modelele utilizate sunt ide ntice
cu cele din etapa de analiză, diferența constând în faptul că acum clasele sunt descrise din punct de vedere al
implementării. Fluxul de control din cadrul unui program trebuie realizat fie explicit (printr -un planificator
intern, care recunoaște eve nimentele și le transformă în apeluri de proceduri), fie implicit (alegând algoritmii
care realizează operațiile în ordinea specificată de modelul dinamic).
Rezultatul final al acestei etape îl constituie modelul obiectual, modelul dinamic și modelul funcț ional
rafinate și detaliate. Deciziile de proiectare luate trebuie susținute de o documentație adecvată care alcătuiește o
extensie a cerințelor de documentație realizate în etapa de analiză.
Se poate concluziona că deciziile de proiectare trebuie documen tate pornind de la modelul de analiză,
prin adăugarea de detalii modelelor obiectual, dinamic și funcțional. În acest scop se vor folosi construcții
specifice de implementare: pointeri (pentru modelul obiectual) pseudocod structurat (pentru modelul dinamic ) și
expresii funcționale (pentru modelul funcțional).
4.2. Modelul obiect în metodologia OMT
Cele trei tipuri de modele recomandate de OMT sunt utilizate începând din etapa de analiză când se
realizează o prima versiune a acestora, apoi în etapa de proiec tare (de sistem obiectuală) când sunt detaliate și
completate și până la implementarea de cod. Simbolul utilizat în metodologia OMT pentru reprezentarea unei
clase de obiecte este:
Nume_Clasă
Atribute
Operații
Numele clasei trebuie să fie sugestiv în co ntextul aplicației și să identifice clasa în mod unic. De
exemplu, pentru o aplica ție de evidență a facturilor pentru fiecare document utilizat se definește un obiect care
conține caracteristicile facturii relevante pentru aplicația informatică.
În OMT atr ibutele sunt reprezentate sub numele clasei, fiind menționat numele atributului și opțional
tipul său și o valoare implicită.
Obiectele se diferențiază între ele prin valorile atributelor la un moment dat, care constituie starea
obiectului în acel moment. Atributul unei clase va descrie o proprietate comună a tuturor obiectelor din clasă și
nu proprietatea unei clase instanțe. El apare ca atribut al obiectelor din clasă având pentru fiecare aceeași
valoare. O categorie aparte de atribute sunt cele derivate a căror valoare se calculează, reprezentate prin
caracterul „/” plasat în fața numelui.
Reprezentarea operațiilor unei clase se face prin specificarea numelui operației, urmat opțional de
parametrii și de tipul rezultatului returnat.
Implementarea operați ilor unei clase se numește metodă . O aceeași operație poate fi implementată în
mod variat în clase diferite. Această proprietate se numește polimorfism. De exemplu clasa „Comandă_marfă”
are operația „Emite”, care va fi implementată în mod diferit față acee ași operație care aparține clasei „Factură”.
Fiecare operație care se aplică unui anumit obiect devine parametru implicit. O operație este recunoscută
după semnătura să (numele, lista de argumente și tipul returnat). Dacă operația poate fi accesată din afa ra clasei
semnătura acesteia este publică spre deosebire de implementare care nu are acest caracter.
Conform metodologiei OMT pentru reprezentarea grafică a unei clase se utilizează o formă
dreptunghiular ă având una sau trei regiuni. În cazul în care se ap elează la reprezentarea cu trei regiuni se
menționează numele clasei, atributele și operațiile clasei. Reprezentarea cu o singură regiune conține doar
numele clasei.
Deoarece obiectele sunt abstractizate în clase atunci legăturile vor consta în asocieri. E ste indicat să se
modeleze asocierile dintre clase și nu legăturile dintre obiectele acestora, motivat prin faptul că obiectele
reprezintă instanțe ale asocierii claselor.

Sinteza c urs: Sisteme informatice financiar -bancare 28 Asocierea claselor se realizează printr -un verb înscris deasupra liniei de conectare . Spre exemplificare
clasele „Factură” și „Furnizor” vor fi conectate prin intermediul asocierii „Emisă_de” care indică și sensul
acesteia:
Factură Emisă_de Furnizor

Multiplicitatea – caracteristică a asocierii – reprezintă numărul de instanțe
ale un ei clase care poate avea
legături cu o instanța a altei clase
asociată. Multiplicitatea poate fi:
„unu la unu”, „unu la zero sau
mai mulți”, „unu la zero sau
unu”, „unu la unu sau mai
mulți”.
Atunci când legăturile devin subiecți ai unor operații apare aso cierea
modelată ca o clasă. În cazul în care se realizează asocierea între „Client” –
„Bancă” apare evidentă asocierea „Împrumut” modelată ca o clasă având în structură atributele Nume_bancă,
Nume_client preluate.
În figura care exemplifică asocierea modelat ă ca o clasă, apare „Suma_împrumutat” care nu aparține
clasei „Client” și nici „Bancă”.
Operațiile efectuate de „Împrumut” sunt de restituire sau amânare.
Presupunând intervenția clasei „Investiție”, apare evidentă asocierea ternară „Împrumută”. În figura se
sintetizează acordarea împrumutului de către bancă unui client pentru anumite investiții. Se observă că asocierea
„Împrumută” nu poate fi divizată fără pierderi de informații între clase.
Nume de rol reprezintă un concept prin care se identifică capete le unei asocieri. În cazul în care o clasă
are mai mult de o asociere, cu siguranță că va avea
roluri diferite față de fiecare dintre acestea. Spre
exemplificare, utilajul achiziționat de o societate
reprezintă pentru ea un mijloc de producție, dar din
punct de vedere al băncii care acordă creditul
constituie o garanție.
Pot exista și asocieri calificate reprezentate
sub forma unu –mulți sau mulți –mulți la care
calificatorul reduce multiplicitatea efectivă. Un
calificator distinge seturile de obiecte de la c apătul
„mulți” al unei asocieri. Generalizarea sub OMT
presupune identificarea atributelor și/sau a operațiilor
comune claselor și crearea superclase. Opusă
generalizării apare specializarea claselor care are ca
punct de plecare superclasa adăugând noi atr ibute
relevante numai pentru anumite obiecte din clasă, creând astfel subclasele.
Avantajele utilizării generalizării sunt: reutilizarea claselor create în cadrul altor proiecte;
standardizarea reprezentată prin specificarea unică a aspectelor comune și ob ținerea unei calități superioare a
proiectului deoarece reutilizarea aduce avantajele oferite de testarea anterioară.
Moștenirea în OMT este un mecanism care dă posibilitatea partajării atributelor și operațiilor utilizând
relația de generalizare. Se utili zează termenul de superclasă , clasă, subclasă cu elementele specifice operații și
atribute. Atributele și operațiile superclasei nu mai apar în cadrul subclaselor atașate, dar aparțin acestora prin
moștenire. În clase se descriu numai atributele și/sau op erațiile specifice fiecăreia dintre ele. Subclasele și clasele
pot fi exprimate prin relația părinți/copii sau strămoși/descendenți. Clasele constituite special pentru a fi
moștenite se numesc abstracte fiind lipsite de instanțe și conținând cel puțin o op erație abstractă care va fi
transmisă claselor descendente.
În cazul în care o clasă este construită pentru a avea instanțe apare noțiunea clasă concretă . Moștenirea
poate fi ierarhizată pe mai multe nivele. Influența generalizării apare evidentă prin prel uarea atributelor și
operațiilor elementare intersectate obținându -se atribute și operații comune. Reprezentare modelului de obiecte

Sinteza c urs: Sisteme informatice financiar -bancare 29 se exprimă prin Diagrama de Asociere a Claselor (DAC) ale cărei noduri sunt clasele de obiecte iar legăturile
între clasele de obiecte sunt reprezentate prin asocieri.
Agregarea este un tip special de asociere între clasa „întreg” și una sau mai multe clase „parte”. Supunen
atenției spre exemplificare, diagrama de asociere între clase pentru „problema” de urmărire a clienților ,
comenzilor și stocurilor.
Este evidentă agregarea client_cash client_virament în superclasa „client” care execută operația
„Achită”.
4.3. Modelul dinamic în accepțiunea metodei OMT
Evidențierea temporală a succesiunii operaților este redată în modelul d inamic. Conceptele utilizate sunt:
eveniment, scenariu, stare, tranziție, condiție, operație .
Evenimentul reprezintă o situație de moment care precede sau succede logic unui alt eveniment.
Evenimentele similare pot fi grupate în clase de evenimente caracte rizate printr -un nume care indică structură și
un comportament comun. Două evenimente care nu au efect unul asupra altuia sunt concurente.
Scenariul este secvență care include evenimentele care apar în timpul execuției sistemului. Scenariul
identifică obie ctele emițătoare, receptoare specifice fiecărui eveniment. Reprezentarea cumulativă a secvenței de
evenimente și obiecte se realizează prin Diagrama de Trasare a Evenimentelor (DTE). Rolul diagramei este de a
indica actorii, evenimentele, obiectele și reun irea acestora în scenarii.
Interpretarea DTE se produce de la bază spre partea superioară și de la stânga la dreapta. Pentru un
eveniment al aplicației se poate modela un singur scenariu, numit principal , iar dacă evenimentul aplicației este
complex, pe l ângă acesta se mai pot modela mai multe scenarii alternative . Utilizând spre exemplificare actorul
„Client” și obiectele „Comandă” până la
”Element_in_stoc” prin evenimentele
„creează comanda”, „citește client”, până
la „cost total al comenzii” se reprezin tă
DTE aferentă aplicației Clienți.
Se observă că evenimentele sunt
trimise de la un obiect emițător la un
obiect receptor și că obiectul care startează
evenimentul este inițiator .
Starea este răspunsul unui obiect
la un eveniment și în același timp abstra ctizarea valorilor atributelor și a legăturilor unui obiect. Unei stări i se
asociază un element valoric al obiectului care satisface o anumită condiție.
Tranziția reprezintă modificarea stării printr -un
eveniment.
Condiția este o funcție booleană bazată pe
valorile obiectului, validată pe o perioadă de timp dacă
apare evenimentul și dacă tranziția este adevărată.
Operația este atașată stării și tranziției și descrie
comportamentul unui obiect ca răspuns la eveniment.
Operațiile pot fi de două feluri: acti vități sau acțiuni.
Activitățile – reprezintă operații care necesită
timp pentru a se executa și sunt asociate unei stări care o controlează până când un eveniment o întrerupe și se
produce o tranziție a stării.
Acțiunea este o operație instantanee, asocia tă unui eveniment, a cărei structură internă nu este interesantă
(nu este modelată ca o activitate cu eveniment de început, de sfârșit și eventual eveniment intermediar).

Sinteza c urs: Sisteme informatice financiar -bancare 30 Corelând stare -tranziție -condiție -operație se obține Diagrama de Tranziție a Stărilo r (DTS) pentru
obiectele din sistem cu comportament dinamic.
Diagrama de Tranziție a Stărilor este un graf în care
nodurile sunt stări, iar arcele sunt tranziții datorate
unor evenimente. Toate tranzițiile din aceeași stare
trebuie să corespundă la evenime nte diferite. Toate
realizările unei clase partajează aceeași DTS, așa
cum partajează și aceleași caracteristici ale claselor.
Diagramele de Tranziție a Stărilor pot fi
structurate pentru a descrie sisteme complexe.
Structurarea se face prin generalizare ș i agregare.
Generalizarea permite aranjarea structurii stărilor și
evenimentelor într -o ierarhie care să permită moștenirea structurii și a comportamentului comun, echivalentă cu
concurența stărilor.
Diagrama de Tranziție a Stărilor pentru clasa de obiecte „element -în_stoc” în care punctul inițial îl
reprezintă stocul sub nivel minim (este recomandabil a se reaproviziona) iar starea finală mesajul „cantitate
insuficientă” pentru a onora comanda.
4.4. Modelul funcțional al metodei OMT
Modelul funcțional are ca scop descrierea algoritmilor sistemului evidențiind modul în care sunt obținute
ieșirile pe baza intrărilor și a altor valori intermediare. Modalitatea grafică de reprezentare a modelului
funcțional este Diagrama de Flux a Datelor (DFD). Specific acestu i model se folosesc termenii: proces, flux de
date, flux de control, actor, depozit de date .
Procesul corespunde unei operații care indică „ce date de intrare sunt transformate” și „ce date de ieșire
se obțin”.
Fluxul de date permite conectarea proceselor la intrarea unui alt obiect sau proces, putând fi transmis în
mai multe locuri.
Fluxul de control apare în diagrama de comunicare printr -un mesaj.
Actorul constă într -un obiect care produce sau consumă date, numit terminator atașat intrării sau ieșirii
DFD-ului
Depozitul de date este materializat ca fișier ce îndeplinește funcția de stocare urmărind o accesare
ulterioară. Actorii și depozitele de date au comportament și utilitate diferită.
Diagramele de flux de date evidențiază pe lângă fluxurile de date d intre terminatori, procesele și
depozitele de date (interfața sistemului modelat cu mediul respectiv) și efectul proceselor asupra datelor care
afectează execuția unui proces.
Procesele din DFD trebuie implementate ca operații ale obiectelor. Operațiile se regăsesc în: funcțiile
matematice; ecuațiile intrări -ieșiri; tabele de corespondență intrări -ieșiri; tabele de decizie; pseudocod și limbaj
structurat.
Modelul funcțional este format din DFD -uri, adică din grafuri ale căror noduri sunt procesele, iar arce le
fluxurile de date și de control.
În concluzie, relațiile între cele trei modele sunt:
1. Modelul static descrie structura datelor pe care se va baza modelul dinamic și funcțional.
Operațiile din modelul obiectual corespund evenimentelor din modelul dinamic și funcțiilor din modelul
funcțional.
2. Modelul dinamic descrie structura de control și evidențiază deciziile care determină acțiuni,
apelează funcții și schimbă valorile obiectelor.
3. Modelul funcțional conectează modelul static și dinamic afectând valorile atributelor din
modelul obiect și evidențiind restricțiile.
Subiecte de autoevaluare

1. Caracterizați metoda de proiectare obiect și produceți comparații între metodele tradiționale și cele orientate
obiect.

Sinteza c urs: Sisteme informatice financiar -bancare 31 2. Exprimați avantajele oferite de metoda OMT core lat cu cele trei tipuri de modele specifice.
3. Care sunt și prin ce se caracterizează etapele ciclului de viață în abordarea orientată obiect?
4. Cum caracterizați clasa, atributul, operația, asocierea, multiplici -tatea? Exemplificați și comentați.
5. Diagrama de asociere a claselor, moștenirea și generalizarea.
6. Ce reprezintă și cum se redau evenimentele, scenariile, stările, tranzițiile, condițiile și operațiile? Exemplificări de
natură economică comentate.
7. Ce reprezintă și cum se realizează modelul funcțio nal în metoda OMT?

Întrebări de autoevaluare

1. Proiectarea de sistem
a. împarte modelul de analiză în părți mai mici, ușor de înțeles și construiește arhitectura sistemului prin
identificarea subsistemelor și transpunerea lor pe hardware -ul disponibil
b. are dr ept obiectiv modelarea problemei din lumea reală sau definirea Domeniului Aplicației (Application
Domain)
c. are drept scop alegerea modului de implementare pentru fiecare clasă, proiectându -se algoritmi și
implementându -se asocierile
d. în cadrul ei, proiectant ul creează modele de obiecte și funcții fără a lua în considerare aspectele de
implementare
e. în cadrul ei modelele utilizate sunt identice cu cele din etapa de analiză, diferența constând în faptul că
acum clasele sunt descrise din punct de vedere al implem entării
raspuns corect a vezi Sisteme informatice financiar -bancare pag 83

2. Numărul de instanțe ale unei clase care poate avea legături cu o instanța a altei clase asociată reprezintă
a. multiplicitatea
b. asocierea
c. standartizarea
d. generalizarea
e. specializarea
raspuns corect a vezi Sisteme informatice financiar -bancare pag 88

3. Apariția unui eveniment care modifică starea unui obiect definește conceptul de:
a. tranziție
b. stare
c. scenariu
d. condiție
e. operație
raspuns corect a vezi Sisteme informatice financiar -bancare pag 93

4. Descrie structura de control și evidențiază deciziile care determină acțiuni, apelează funcții și schimbă
valorile obiectelor
a. modelul dinamic
b. fluxul de control
c. modelul datelor
d. modelul static
e. fluxul de date
raspuns corect a vezi Sisteme informatice financi ar-bancare pag 96

Capitolul 5. Unified Modeling Language – cale de reunire a conceptelor orientate -obiect

Introducere

Sinteza c urs: Sisteme informatice financiar -bancare 32 Arhitectura sistemelor informatice complexe a fost revăzută sub incidența unui curent privind formalizarea unui
limbaj standard de model are datorat unor personalități (Meyer, Rumbaugh, Jacobson, Booch, Coad, Mellor etc.)
care propun structuri ale sistemului în raport cu implementarea acestuia, implementarea fiind privită ca o
activitate

Obiective :
Arhitectura sistemelor informatice form alizată cu ajutorul UML. Avantajele oferite de UML
utilizatorului și proiectantului.
Mecanisme utilizate pentru inserare de informații
Reingineria sistemelor informatice

Cuvinte cheie
ierarhie de modele, vederi și diagrame stereotip valori etichete reingi nerie informatică
elememtele modelului constringeri timp de răspuns dimensionare economică

S-au dezvoltat mecanisme/șabloane de proiectare(design patterns) și diferite instrumente CASE
(Computer Aided Software Engeneering) de natură să asigure construir ea unor “modele” necesare proiectării.
Aceste considerente au condus la apariția unui “Limbaj unificat de modelare” denumit UML :Unified Modeling
Language caracterizat prin:
 UML este un limbaj “universal” dedicat construirii, manipulării și vizualizarea com ponentelor
sistemului informațional;
 UML este un limbaj pentru specificarea,
vizualizarea, construcția și documentația sistemelor software,
acest limbaj fiind o colecție omogenă de practici engineering
utilizabile pentru modelarea și realizarea sistemelor complexe.
 UML asigură înțelegerea semanticii
sistemului prin materializarea deciziilor;
 UML nu conține limitări impuse de
metodologia/metoda de proiectare, domeniul de activitate unde
este utilizat sau mediul utilizat pentru dezvoltare
 UML realizează unif icarea conceptelor
orientate -obiect sub forma unui standard de proiectare , prin
care se asigură definiția semanticii conceptelor utilizate,
notațiile asociate acestora și documentația necesară pentru
dezvoltarea unui sistem informatic ;
 UML este folosit pen tru modelarea
sistemelor informatice de tip discret;
UML permite dezvoltarea ierarhiei de modele, vederi
și diagrame asigurând „viaductul” modele  vederi 
diagrame  fișiere de cod sursă  date/cazuri de test . Vederile( Views ) asigură prezentarea diferite lor aspecte
ale sistemului modelat sub forma unor abstractizări ce constau într -o secvență de diagrame.
 UML utilizează elemente de modelare vizuale sub forma unor instrumente CASE , care pot
asigura următoarele funcții :
o generarea modelelor de analiză, proie ctare și implementare;
o generarea vederilor asociate modelelor de mai sus, diagramelor specifice vederilor;
o posibilitatea utilizării unor generatoare de cod prin care se poate asigura implementarea sistemului
realizat;
o posibilitatea includerii unor generat oare de rapoarte;
o posibilitatea prezenței instrumentelor de tip reverse engineering etc.
 UML permite dezvoltarea și utilizarea modelării vizuale asigurând înțelegerea semanticii
sistemelor lumii reale cu participarea actorilor (analiști, programatori, expe rți, design -eri, implementatori etc.);

Sinteza c urs: Sisteme informatice financiar -bancare 33  UML utilizează termenul de model care realizează abstractizări ce descriu problemele complexe
specifice.
 UML folosește în etapa de modelare abordarea obiectuală care asigură optimizarea realizării
programelor.
5.1 Obi ectivele fundamentale și avantajele oferite de UML
UML prin obiectivele sale are un spectru larg de utilizare putând fi folosit în toate fazele de dezvoltare și
pentru toate tipurile de sisteme. Modelare optimală a arhitecturii sistemelor prin UML își prop une următoarele
scopuri: asigurarea modelării sistemelor de orice tip, inclusiv a sistemelor software orientate -obiect;
fundamentează explicit „binomul” conceptual -soluția operațională; asigură definirea unui limbaj de modelare
utilizat atât de factorul um an cât și de suportul fizic utilizat în realizarea sistemului; descrierea oricărui tip de
sistem prin intermediul diagramelor orientate obiect; realizează specificații pentru domeniul Business
Engineering prin care procesele de afaceri pot fi analizate, îm bunătățite și implementate prin tehnici adecvate
(TQM -Total Quality Management , BPR -Business Process Reengineering ) realizând sisteme informatice la nivel
micro, mezo sau macroeconomic; permite definirea unor soluții pentru diferite tipuri de sisteme (sisteme
informatice, tehnice, în timp -real, distribuite, software sau de “business”).
Fiecare aspect particular specific sistemului realizat va fi reflectat separat printr -o diagramă/schemă
aferentă sistemului construit. Aceste vederi vor asigura legături cu l imbajul de modelare specific UML.
Modelarea unui sistem este o sarcină extensivă și de aceea acesta nu poate fi descris printr -un singur graf
definit integral, fără ambiguități, simplu și inteligibil. Se va descrie prin intermediul aspectelor: funcționale care
au în vedere structura statică, dinamică și interacțiunile; nonfuncționale legate de coordonare/sincronizare,
fiabilitate, amplasament; organizaționale legate de specificul activității.
Consideram că orice sistem poate fi descris printr -un set de vede ri, în care fiecare va reprezenta o
proiecție completă a descrierii sistemului, inclusiv vederea particulară a aspectelor sistemului. Mai mult, fiecare
vedere particulară va fi descrisă printr -un număr de diagrame care conțin informații și diferite aspecte particulare
ale sistemului.
Modelarea prin UML are următoarele avantaje: permite construirea de modele complexe prin
intermediul unui limbaj riguros de modelare standard ; acest limbaj este considerat lingua franca pentru
modelarea sistemelor informatice; limbajul UML nu asigură în mod automat succesul în realizarea sistemelor
informatice însă permite ameliorarea și îmbunătățirea multor elemente specifice modelării; acest limbaj de
modelare conține elementele modelului (model elements) notațiile modelului și modul de utilizare expresia
idiomatică în interiorul tranzacțiilor.
5.2. UML – limbaj universal
Astfel în UML conceptele utilizate în diagrame se numesc elementele modelului (Model Elements) și
sunt definite ca semantici, definiții formale asociate elem entului, neambigue. Elementele modelului corespund
vederii elementelor și sunt reprezentate prin simboluri grafice în cadrul diagramei elementelor dar regulile de
utilizare sunt specifice fiecărui tip de diagrame. În aceste diagrame pot fi reprezentate și relațiile indicând
proprietatea potrivit căreia un element depinde de unul sau mai multe elemente. Asocierea semnifică proprietatea
potrivit căreia un element este conexat cu un altul, inclusiv legăturile dintre instanțele respectivelor elemente.
Alte elem ente posibile pot fi mesaje, acțiuni și stereotipuri.
UML utilizează o serie de mecanisme generale folosite în toate diagramele pentru inserarea unor
informații adiționale în structura lor. Aceste mecanisme generale sunt următoarele:
 Precizările auxiliare( Adornments) care permit atașarea unor elemente particulare modelului în diagramele
specifice având următoarele variante:
o Reprezentarea diferită a tipului apare atunci când elementul reprezintă un tip, fiind notată specific. Pentru o
instanță vizibilă atunc i când elementul este instanță a unui tip se va utiliza alăturarea identificator -tip.
o Clasa și obiectul vor fi reflectate prin notație distinctă..
o Nodurile (ex. Printer) și instanța nodului (ex. imprimantă HP 2000) au pe lângă nume menționată valoarea
exactă utilizată.

Sinteza c urs: Sisteme informatice financiar -bancare 34  Note adiționale (Notes) au un caracter neinterpretabil pentru UML, dar reprezintă în același timp elemente
cu rol semantic folositor numai utilizatorului. Notele sunt plasate în diagramele UML și sunt simbolizate prin
linii discontinue.
 Spec ificații (Specifications ) reprezintă elementele modelului cu proprietăți dependente de valoarea datelor,
definite prin: tagged value (nume -valoare).
Extinderea limbajului UML care
urmărește satisfacerea operatorului economic se
realizează printr -un mecanis m de extensie care
conține: stereotipurile (stereotypes), valorile
etichetelor (tagged value) și
constrângerile (constraints).
Stereotipul (stereotypes) este format prin
extinderea unui model element cu semantici
absente în formatul standard. Stereotipurile sunt
bazate pe toate tipurile de elemente (clase,
noduri, componente și note, dar și pentru relații
cum ar putea fi asocieri, generalizări și
dependențe). Numărul stereotipuri este predefinit
în UML putând fi utilizate în vederea ajustării
modelului eleme nt existent.
Valorile etichetelor (tagged value ) sunt utile pentru a adăuga informații cu caracter de reglare
administrativă informații specifice metodei, informații necesare utilizatorului în cazul folosirii unui instrument
CASE. Valorile etichetelor sunt specifice elementelor care conțin proprietăți ca perechi nume -valoare , aceste
valori ale etichetelor fiind predefinite în UML.
Constrângerile (constraints) reprezintă restricții de utilizare a elementelor menționate printr -un
instrument CASE sau prin decl arații atribuite la diagramă.
Proiectarea unui sistem informatic se realizează cu ajutorul unor faze, modele și diagrame. Structura
modelului sistemului conține modelul de analiză (Analysis model ), modelul design (Design model ), modelul de
implement are (Implementation model) și modelul de amplasare (Deployment model ).
Finalizarea analizei modelului oglindește cerințele sistemului dar și modelul de bază. Faza design se
materializează prin orientarea către soluția tehnic operațională. Modelul de implementarea permite generarea
codului, compilarea, actualizarea și testarea componentelor sistemului. Modelul de amplasare permite definirea
arhitecturii fizice a sistemului și reprezintă finalizarea ultimei faze de realizare a sistemului.
Vederile au rolul de a desc rie sistemul prin intermediul percepției actorilor externi (client al sistemului,
design -eri, dezvoltatori și personal de testare ) particularizându -se prin intermediul diagramelor cazului de utilizare
(use-case diagrams) și eventual diagrama activităților (activity diagrams). Actorul extern intracționează cu
sistemul fiind un utilizator sau un sistem extern.
5.3. De la Merise la UML
A putea realiza o tranziție de la Merise la UML presupune, înainte de toate, o analiză a celor două
metode, analiză care ar p utea scoate în evidență principalele avantaje oferite de aceste metode. Această analiză
trebuie să aibe în vedere toate aspecte definitorii ale celor două metode: principiile de bază, modul în care se
realizează modelarea și administrarea modelării unui si stem informatic.
Analiza comparativă a principiilor de bază, scoate în evidență abordarea sistemică a ambelor metode,
abordare care în cazul metodei UML se traduce prin modelarea unor cazuri de utilizare (totalitatea lor descriind
comportamentul sistemul ui informatic). Ca și metoda Merise, UML prezintă câteva nivele de abstractizare
ajutându -se de un formalism care se referă la: cazurile de utilizare, clase, diagrame, etc. Interesant este faptul ca
în cazul metodei UML nu se face referire la conceptul de ciclu de viată.
5.4. Reingineria informatică – proces integrat în strategie
Reingineria produsele sau analiza valorii bunurilor existente operează eficient în etapa constructivă când
reprezintă 75% din cheltuielile de proiectare și exploatare. Similar se procedează pentru analiza comparativă a

Sinteza c urs: Sisteme informatice financiar -bancare 35 costului conceperii produselor informatice cu evaluarea rezultatelor. Această abordare presupune luarea în
considerare a situațiilor în care funcționează societatea comercială. Printre cele mai importante amintesc:
maximizarea profitului în contextul pieței concurențiale.
Orice întreprinzător vizează nu numai succesul imediat, dar și cel de perspectivă implicând adaptarea
continuă a condițiilor de funcționare la cerințele în schimbare specifice mediului social -economi c; complexitate
ridicată de implicațiile interdependențelor care se creează, de penuria sau raritatea unor resurse necesare
desfășurării activităților; extinderea automatizării și a robotizării producției implică mutații importante în
exercitarea funcțiilo r de conducere, dar și a celor de execuție afirmând creativitatea factorului uman;
managementul și marketingul realizate științific bazate pe raționalitate și luciditate contribuie decisiv la
afirmarea întreprinzătorilor.
În prima etapă a reingineriei valo rii unui produs informatic este necesar să se delimiteze, scopurile
concrete vizate, urmărind adaptarea produsului potențialilor utilizatorii. Pentru aceasta este necesară
reconsiderarea cerințelor informaționale și a restricțiilor de funcționare, stabilit e prin proiectul director și tema
de realizare a sistemului informatic.
Dimensionarea tehnică și economică a produsului informatic presupune detalierea analizei în vederea
stabilirii posibilităților de măsurare a modului de realizare și a costurilor implic ate. Privite din prisma
întreprinzătorului funcțiile unui produs informatic și parametrii cuantificabili sunt:
Mutațiile structurale induse în cadrul organizației prin reconsiderarea sistemului informațional –
decizional sunt măsurabile prin indicele entropi ei informaționale înainte și după reorganizări. O valoare
supraunitară relevă influența pozitivă a realizării produsului asupra organizării și conducerii organizației, fiind
perceput prin reducerea gradului de nedeteminare a fenomenelor și a proceselor din sistem.
Rapiditatea în luarea deciziilor este o funcție importantă a informaticii aplicative. Timpul de răspuns
înainte și după introducerea produsului în sistem arată aportul adus la creșterea operativității de informare.
Contribuția produsului la antren area și mobilizarea resurselor potențiale se datorează, în parte, informaticii
economice prin semnalarea stocurilor, soldurilor care grevează rezultatele financiare ale întreprinderii.
Controlabilitatea sistemului de reglare este o funcție de bază a produs elor informatice asigurând
conducerea după principiului excepției, prin care pot fi aplicate conceptele ciberneticii de reglare și autoreglare a
funcționării unității. Indicatorii variaționali ai dispersiei valorilor efective de la cele scontate, înainte ș i după
introducerea produsului informatic relevă măsura în care se exercită controlul asupra sistemului.
Dimensionarea tehnică a produsului informatic solicită fixarea parametrilor și a funcțiilor specifice prin
compararea cu cerințele și restricțiile util izatorului. Fiabilitatea echipamentelor de calcul, flexibilitatea software –
lui de bază, eficacitatea și adaptabilitatea software -lui aplicativ și altele pot fi elemente determinante ale
procesului de proiectare a unor produse proprii, performante.
Dimensio narea economică a unui produs necesită asocierea funcțiilor și parametrilor cu cheltuielile
implicate de creare și realizare. Pentru analiza echilibrelor „unități -costuri” se rețin cheltuielile variabile și
cheltuielile de exploatare și întreținere.
În pro cesul de reflexie și creație se urmărește maximizarea efectelor utile, în condițiile menținerii sau a
diminuării efortului de realizare și exploatare a produsului.
Soluția indică varianta care asigură venitul maximal, cheltuielile minimale și abaterea min imă a
rezultatelor individuale de la media rezultatului.
În formularea modelului pot fi considerate și alte funcții scop, cum sunt: maximizare costului total,
minimizarea cheltuielilor de exploatare și întreținere, maximizarea venitului total brut.
Conside răm că analiza valorii sistemului informatic de ansamblu se produce pe baza indicilor calitativi
globali calculați pentru variantele de realizare posibile.
Ca indicatori de măsurare a performanțelor și a eficienței pot fi considerați: timpi medii de răspun s la
cereri; cheltuieli anuale variabile; entropia și energia informațională; economiile anuale; coeficientul de variație
a realizărilor față de obiective; ponderea cheltuielilor de natură informațională în costul producției; indicatorii
variaționali privi nd veniturile realizate sau realizabile.
Varianta cu nivelul calitativ cel mai ridicat este cea care urmează a fi adoptată și implementată în sistem.
Refacerea totală a sistemului informațional spre o arhitectură de servicii se aseamănă cu o revoluție cul turală. Se
pune problema cum să reunim în același proiect competențele în tehnologia informației, marketing și
management?

Sinteza c urs: Sisteme informatice financiar -bancare 36 Reingineria este redefinirea radicală a proceselor operaționale urmărind câștiguri spectaculoase de
performanțe materializate astăzi prin costuri, calitatea serviciilor și rapiditate.
Subiecte de autoevaluare

1. Ce reprezintă și prin ce se caracterizează limbajul unificat de modelare?
2. Care sunt principalele obiective și avantaje oferite de UML? Comentarii.
3. Care sunt mecanismele genera le ce acționează la momentul realizării diagramelor?
4. Cum caracterizați stereotipul, etichetele, constrângerile, vederile și actorul?
5. Care sunt și prin ce se caracterizează etapele parcurse în cazul reingineriei unui produs informatic?

Întrebări de aut oevaluare

1. Funcțiile instrumentelor CASE sunt
a. generarea modelelor de analiză, proiectare și implementare;
b. posibilitatea utilizării unor generatoare de cod prin care se poate asigura implementarea sistemului
realizat;
c. posibilitatea prezenței instrumentelor de tip reverse engineering
d. asigură înțelegerea semanticii sistemului prin materializarea deciziilor
e. permite dezvoltarea și utilizarea modelării vizuale asigurând înțelegerea semanticii sistemelor lumii
reale cu participarea actorilor
I (a, b, c); II (b, c , d); III (a, d, e); IV ( b, d, e); V (c, d, e,)
raspuns corect I vezi Sisteme informatice financiar -bancare pag 98

2. Fiecare aspect particular specific sistemului realizat va fi reflectat:
a. printr -o diagramă/schemă aferentă sistemului construit
b. prin note ad iționale (Notes)
c. prin specificații (Specifications)
d. prin precizările auxiliare(Adornments)
e. prin stereotipul (stereotypes)
raspuns corect a vezi Sisteme informatice financiar -bancare pag 100

3. Variantele precizărilor auxiliare sunt:
a. Reprezentarea diferită a tipului
b. Clasa și obiectul
c. Nodurile și instanța nodului
d. Valorile etichetelor
e. Constrângerile
I (a, b, c); II (b, c, d); III (a, c, d); IV (b, c, e); V(c, d, e)
raspuns corect I vezi Sisteme informatice financiar -bancare pag 101

Capitolul 6. Exemplificări și studii de caz

Introducere
Visual Basic pentru Aplicații (VBA) este mult mai puternic decât AccessBasic, își face simțite facilitățile oferite
dezvoltatorului software dar și utilizatorului. Programatorului îi sunt oferite noi tipuri de date, posibilități de
compilare condiționată, operații OLE

Obiective :
Clarificări privind impactul Visual Basic pentru Aplicații, Access, ca limjaje de programare ce urmăresc
punerea în operă a arhitecturii și studiilor aneterior prezentate.

Sinteza c urs: Sisteme informatice financiar -bancare 37 Conectarea logică dar și fizi că a VBA cu Access prin intermediul SQL
Exemplificări economice multiple

Cuvinte cheie
schemă bază de date interogare static SQL model conceptual al datelor
structură bază de date SQL încapsulat dependențe funcționale interogare

6.1. Capabilitățile și restricțiile Visual Basic for Application (VBA)
VBA permite ca tipurile definite de utilizator să cuprindă la rândul lor alte categorii (standard sau
definite explicit) și ca datele returnate prin răspuns al funcțiilor să fie corespunzătoare acestor tipur i. Prin
utilizarea tabloului de parametrii (ParamArray) dezvoltatorul poate realiza funcții cu argumente opționale,
funcții cu un număr variabil de argumente opționale.
Avantajul VBA oferit beneficiarului de sistem rezultă din cerințele moderate hard și im plicit costul
echipamentelor. Cu un efort minimal persoanele cu sarcini de exploatare pot interveni pentru personalizarea,
modernizarea sistemului datorită programelor de asistență disponibile implicit. Cu siguranță vor apare disensiuni
între proiectant ex ecutant al sistemului și beneficiar. În acest moment suita de avantaje oferite beneficiarului se
exprimă pe poziția ”programatorului” ca puncte conflictuale.
6.2. Posibilități de utilizare a SGBD ACCESS
Access este un sistem de gestiune a bazelor de date r elaționale pentru Microsoft Office care funcționează
sub sistemul de operare Windows. Din punct de vedere al creatorului soft realizarea sistemelor informatice este
relativ facilă. Modelul relațional al datelor este obținut rapid prin aplicarea regulilor d e trecere la modelele
semantice. Utilizarea datelor stocate într -un singur fișier (MDB) asigură o „lipsă” de redondanță a tabelelor
simultan cu integritatea și accesibilitatea datelor.
Schema bazei de date este constituită din colecțiile de tabele și poate fi exploatată prin manipularea
interogărilor . Baza acestor interogări o constituie limbajul standard SQL (Structured Query Language).
Sistemul Access se bazează pe un sistem relațional definit ca un ansamblu format din structura
relațională a datelor și m ulțimea operatorilor relaționali.
Sistemul Access are facilitatea de a exporta structuri de tabele, definiții de interogări, formulare, rapoarte
și module.
Interfața Access permite monitorizarea modului de proiectare al câmpurilor, tabelelor și de exprima re a
relațiilor care formează structura unei baze de date. Prin intermediul formularelor, interogărilor și rapoartelor se
ușurează operațiile de extragere a datelor. Se va dezvolta ulterior interfața utilizator, aprofundând proprietățile și
evenimentele co ntroalelor, formelor și rapoartelor.
Access permite răspunsul rapid la o întrebare formulată bazei de date. În momentul în care se pornește la
construcția unei interogări trebuie să existe o viziune de ansamblu asupra datelor dorite a se regăsi exprimate
prin câmpuri, tabele, criteriile de selecție și eventual ordinea de sortare. Construirea unei interogări în Access
reprezintă un proces simplu și rapid de așezare a tabelelor și a câmpurilor necesare pe o grilă (Query by
Example) care reprezintă o modalitat e facilă de regăsire a datelor.
Deoarece transferarea datelor din baza de date se poate cere în regim text, fiecare rând este considerat ca
fiind o înregistrare iar caracterele care delimitează sunt virgula sau marcajele tabulare.
6.3. Conectarea VBA – ACC ESS prin SQL
SQL -pune la dispoziția programatorului sau a administratorului de baze de date următoarele facilități:
Posibilitatea de modificare a structurii bazei de date; Posibilitatea schimbării valorilor de configurare pentru
securitatea sistemului; Per mite stabilirea și modificarea drepturilor date utilizatorilor asupra bazelor de date sau a
tabelelor; Permite interogarea unei baze de date; Oferă facilități multiple referitoare la actualizarea conținutului
unei baze de date.
Primul standard utilizat pen tru SQL a fost ANSI care definea tipurile de realizare a unei interfețe SQL și
anume: limbajul modular, presupune utilizarea de proceduri în cadrul programelor, proceduri care pot fi apelate
de programul de aplicații și care returnează valori în program pr in transmitere de parametri; SQL încapsulat ,
care folosește instrucțiuni SQL încapsulate în codul program. Datorită acestui fapt apare necesitatea utilizării

Sinteza c urs: Sisteme informatice financiar -bancare 38 unui precompilator pentru procesarea instrucțiunilor SQL; apelul direct, care presupune că alegere a este făcută
de cel ce implementează programul.
Cea mai utilizată formă de SQL este cea încapsulată, cunoscută sub denumirea de static SQL și care
presupune că instrucțiunea SQL este compilată în cadrul aplicației și nu poate fi modificată în timpul execu ției
programului.
SQL asigură programatorului de aplicații un grad sporit de flexibilitate, conectivitate într -o interfață de
nivel apel (ODBC) și biblioteca bazei de date Sybaze. Când se utilizează ODBC se completează o variabilă cu
instrucțiunea SQL a ut ilizatorului, după care se apelează funcția pentru transmiterea instrucțiunilor SQL bazei de
date.
6.4. Probleme rezolvate
Proiectarea unui sistem informatic presupune, pe lângă realizarea arhitecturii sistemului informatic în
sine, și elaborarea unui proi ect sau manual de utilizare în care se va descrie principalele componente ale
sistemului informatic. De menționat că acest proiect se va livra beneficiarului odată cu produsul software.
Realizarea acestui proiect presupune parcurgerea etapelor prezentate d etaliat in manualul „Sisteme
informatice financiar bancare” subcapitolul 6.4.
Exemplul 1 Realizarea unui subsistem informatic privind gestiunea stocurilor de materiale
Realizarea dicționarului de atribute:
Nr.
crt Denumirea atributului Identificator Tip/Lungime Restricții
1 Codul materiei prime Cod_mp N/9 Not Null
2 Denumirea materiei prime Den_mp T/10
3 Unitate de măsură UM T/3
4 Număr factură Nr_fact N/11 Not Null
5 Data facturii Data_fact D/Short
…. ….. …… …… …..
29 Stoc final la sfârșitul ge stiunii Stoc_sf N/3

Stabilirea dependențelor funcționale :
Cod_furniz Nr_fact
Nr_fact .. Data_fact
Nr_fact , Cod_mp Cant_fact
…… …….
Nr_cmd_a Dată_cmd_a
Nr_cmd_a Cant_cmd_a

Diagrama dependențelor funcționale : Realizarea modelului conceptual al datelor

Sinteza c urs: Sisteme informatice financiar -bancare 39

Exemplificare creare tabela Furnizori Stabilirea legăturilor între tabelele întregului proiect

Realizare interogare pentru acualizare date în tabelele Furnizori și Factura

Sinteza c urs: Sisteme informatice financiar -bancare 40

Codul sursă SQL aferent interogării proi ectate

Execuția interogării proiectate

Exemplul 2
Realizarea unui subsistem informatic privind evidența clienților și a
contractelor de asigurare CASCO încheiate de aceștia la o societate de
asigurări
Realizarea dicționarului de atribute:
Nr. crt Denumirea atributului Identificator Tip / Lungime Restricții
1 Numărul contractului de asigurare Nr_ctr N/10 Not Null
2 Data la care se semnază contractul Data_semn_ctr D/Short
3 Data începutului de contract Data_încep_ctr D/Short Data_semn_ctr + 48h
…. ……. …… …… ……
32 Cotă uzură Cotă N/2 Procent

2. Stabilirea dependențelor funcționale :
Cod_cl Nume_cl
Cod_cl Pren_cl
Cod_cl Adresa_cl
Cod_cl Tip_cl
Cod_cl, Nr_înmatric Nr_ctr
Cod_cl Nr_înmatric
…….. …….
Nr_doc_const Data_const

Sinteza c urs: Sisteme informatice financiar -bancare 41

Exemplul 3
Realizarea unui subsistem informatic privind evidența clienților și a contractelor de închiriere
autovehicule de la o societate de profil.
Modelul conceptual al datelor Modelul fizic al datelor

Sinteza c urs: Sisteme informatice financiar -bancare 42

Exemplul 4
Realizarea unui subsistem informatic privind evidența comenzilor înaintate de clienți unui
magazin virtual.
Modelul conceptual al datelor Modelul fizic al datelor

Sinteza c urs: Sisteme informatice financiar -bancare 43

Subiecte de autoevaluare

1. Comentați și exemplificați „economic” modul î n care VBA permite programatorului definirea tipurilor de
entități
2. Modul în care SGBD Access permite proiectarea câmpurilor, tabelelor și exprimarea relațiilor care formează
structura unei baze de date.
3. Ce reprezintă SQL, care sunt facilitățile oferite d e acesta comparativ cu VBA și Access
4. Realizați modelul conceptual al datelor și modelul fizic al datelor pentru evidența clienților unei case de schimb
valutar. Implementați modelul conceptual și fizic prin SGBD Access și proiectați 2 interogări a căror structură trebuie să
fie semnificativă.
5. Realizați modelul conceptual al datelor și modelul fizic al datelor pentru evidența pasagerilor care au rezervare
de loc în cazul unei societăți comerciale care are ca obiect de activitate transportul de persoane pe distanță mare.
Implementați modelul conceptual și fizic prin SGBD Access și proiectați 2 interogări a căror structură trebuie să fie
semnificativă.

Întrebări de autoevaluare

1. Schema bazei de date este constituită din
a. colecțiile de tabele
b. colecții de vari abile
c. colecții de atribute
d. colecții de asocieri

Sinteza c urs: Sisteme informatice financiar -bancare 44 e. colecții de domenii
raspuns corect a vezi Sisteme informatice financiar -bancare pag 110

2.În cazul în care în modelul fizic al datelor întâlnim notația Cod client: Numeric (10) acest fapt semnifică
a. atributul Cod client poate accepta maxim 10 caractere
b. atributul Cod client poate accepta maxim 10 valori
c. atributul Cod client poate participa cu maxim 10 realizări la asociere
d. atributul Cod client prezintă maxim 10 dependențe funcționale
e. atributul Cod client prezint ă cardinalitatea maximală 10
raspuns corect a