Disciplina Sisteme informatice financiar-bancare si de ...se-b.spiruharet.ro/images/secretariat/licenta/fb/2016-2017/sinteze... · Sinteza curs: Sisteme informatice financiar-bancare

Sinteza curs: Sisteme informatice financiar-bancare 1

Universitatea SPIRU HARET Facultatea ȘTIINȚE ECONOMICE Specializarea FINANŢ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 financiar - 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 datelor 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


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


Prezentare 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ă poate 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 identifică 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 economic 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 structurat şi corelat de proceduri şi echipamente electronice de calcul care permit culegerea, transmiterea şi prelucrarea datelor, obţinerea de informaţii. Sistemul informatic lărgeşte câmpul de acţiune al sistemului informaţional, îi potenţează valenţele, îmbunătăţindu-l sub aspect calitativ.

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 documente. Î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 ei î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.

Documentele 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 contabile. Conţinutul documentelor justificative este format din următoarele elemente: denumirea, numărul şi data documentului, denumirea şi sediul unităţii patrimoniale,


menţionarea părţilor care participă la efectuarea operaţiei, conţinutul operaţiei economice, 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 condiţiile folosirii unor tehnici de prelucrare diferite, ceea ce diferenţiază un registru de altul este forma de prezentare a informaţiei, conţinutul rămânând acelaşi.

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, reconstituirea ş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, informaţ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, programe de aprovizionare şi vânzare de bunuri, servicii şi de marketing; programe de cercetare-dezvoltare, programe de producţie şi costuri, programe de salarizare şi personal, programe de impozite, taxe şi alte sume cuvenite bugetului statului şi celui de asigurări sociale, 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 acordate 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 metode 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 informaţ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 fluxurilor 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 actualizare 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 modelate împreună.


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 activităţ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 presupune 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 rezultatelor 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 evaluate 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) Principiul 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 necompensă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 neadecvate 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 pragului 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 constituie 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 financiară, 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 analiza 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ă statistice; 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.


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ă, informatizarea 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.

• perspectivă 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 cazurilor 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-contabil, 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 informaţ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 sistemului, 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 sistemului 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 lor 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 posteriori) ş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 eficienţ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.


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 indicatorilor 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 exploatare) 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 Efectele 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ţională ş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ăsurarea 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, precum ş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 bazelor 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, fluiditatea „catartică", dinamica actului de evaluare.


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 atuurile 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 din evaluare (exemple: compatibilitatea 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 metoda „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 informatice

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

Proliferarea 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 sistemice 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 aspectele 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ă Merise, şi metoda entitate-relaţie2.

1 Tardieu H. şi col., The Individual Model, International WorkShop on Data Structure Models for Informations

Systems, London, 1998.


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 sistem 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 apropiate, 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 sunt î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ătoarele î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 lor. 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 trei 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ărilor ş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 stabile î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 ele. 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 obiect ş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 sursa ş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, servicii etc.);

2 Chen P., The Entity-Relationship Model, „ALM Transaction of Database Systems”, 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.


• 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 autoevaluare

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 principiile 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ă comparativ 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 autoevaluare

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 proiectare 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, privind 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 venituri 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 întocmirea 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 fi evaluate la valori reale, exacte, atât în contabilitatea curentă, cât şi la bilanţ.


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 totodată ş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 incertitudinile 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 conceptual, 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 furnizarea 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ţă, abstractizare 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 dezvoltarea 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 ingineri 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


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, studiul 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 datelor (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 majore 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 permiţâ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ştenire, 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 diagrame 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 cicluri î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 parcursul 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


implementării unui nou sistem informatic, 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 bine 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ă permanentă 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 un 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 fi 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 cronologic 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 identificarea 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 FUNCŢ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 plan 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ă


a aplicaţiilor, care să includă o politică 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 sistemului 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 între 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 specificarea detaliată a cerinţelor, precum şi specificarea arhitecturii noului sistem. În această fază, se vor avea în vedere toate aspectele care vor 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 prin 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 acestui 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, realizarea ş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


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ătoare 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 abstractizare 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ă soluţ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 figura 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 subproiecte 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 prealabil. 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 „care 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


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 întrebarea „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 prelucră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şte 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 independentă 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ănunţ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 model 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 conceptual 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 alegerii 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


DATE PRELUCRĂRI Descrierea bazelor de date Noţiuni de înregistrare

Descrierea programelor 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 organizatiei, 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ţiilor şi sincronizărilor, toate aspectele dinamice ale unui sistem informatic.


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.


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


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



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 beneficiile 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ă reflecte 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 realizarea

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 proiectare. 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 conceptual 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. Modelul 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 modele 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 structuri 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


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 fiind „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 exemplu 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ă de 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 proprietăţ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 personal, 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 concluzia 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 acestea 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 atribute 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: atributul 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 valoare. 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 aceiaş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:


a. chei candidate – sunt acele atribute care prin natura lor sunt susceptibile de a juca rolul de cheie primară sau de identificator în cadrul unui tip de entitate;

b. cheie primară sau identificator – reprezintă acel atribut sau grup de atribute, care în cadrul tipului de entitate reuşeşte, prin valorile pe care le ia, să scoată în evidenţă o anumită entitate din mulţimea entităţilor care prezintă acelaşi comportament. Rezultă că o cerinţă esenţială pentru valorile pe care le poate lua acest gen de atribut, este ca acestea să fie unice în toată mulţimea valorilor pe care le poate lua acel atribut. Ex: atributul cod numeric personal, prin valorile pe care le poate lua poate conduce la identificarea în mod unic a entităţii Georgescu din mulţimea entităţilor care formează tipul de entitate Student;

c. cheie externă – reprezintă un atribut sau o multime de atribute definite pe aceiasi multime de valori ca şi cheia primară, rolul său fiind acela de a putea stabili o asociere între două sau mai multe tipuri de entităţi care în realitatea modelată, interacţionează între ele.

Atributul este perceput ca o variabilă care poate lua valori într-un anumit domeniu. Putem spune că domeniul reprezintă mulţimea tuturor valorilor posibile pe care le poate lua un atribut

într-o anumită perioadă de timp. 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ă aspecte. 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ă pentru 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.

Astfel, î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 abstract 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 dependenţă functională. Dependenţa funcţională reprezintă o proprietate a semnificaţiei sau a semanticii atributelor, indicând

modul în care sunt legate atributele unele de altele.

Numim dependenţă funcţională simplă o legătură stabilită între două atribute notate A şi B apartinand

unei relatii R, pentru fiecare valoare cunoscută a atributului A se antrenează în mod sistematic asocierea

aceleiaşi valori pentru atributul B.

Reprezentarea grafică pentru o astfel de dependenţă funcţională este simbolizată printr-o săgeată având o orientare de la atributul A către atributul B.


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 atributului 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 multivaloare. Fie atributele A, B, si C aflate intr-o relatie R, exista o dependenta functionala multivaloare atunci cand

pentru fiecare valoare a atributului A exista o multime de valori pentru atributul B si o multime de valori pentru

atributul C. Totusi, multimile de valori ale atributelor B si C sunt independente unele de altele. Vom reprezenta o dependenta functionala multivaloare printr-o săgeata dubla de la determinant catre determinat

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ă tabele 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 uzual 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ări 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 de unu-la-unu.


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 al 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 externă î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)


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_Contracte 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 prezintă 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, receptorii (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 evenimentelor 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 exercitate 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 prin 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, numite 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


întreprinderii şi un domeniu. Mesajul este emis de o parte (partener sau domeniu, 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 presupune 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.

- Modularizare

- 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 metodologic 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 detaliat 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ă”, susceptibilă să se integreze într-un cadru metodologic mai larg.


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 asocierea. 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 acceptate. Exemplificări. 12. Modelul logic al datelor.


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.


1. Modelul conceptual al datelor este:

a. un ansamblu 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ţionale 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

Capitolul 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 modului 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 ansamblu 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 supuse 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 instanţelor şi implementarea operaţiilor.


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 surprinderea 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 Diagram 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 lumea 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 beneficiar-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 sistem.

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 aplicaţ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 soluţ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 arhitectură 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 proiectare 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 seama 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.


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 detaliat ş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 identice 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 evenimentele ş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 documentate 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 proiectare (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 contextul 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 atributele 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ţiilor 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ţă aceeaş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 afara 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 apelează 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. Este 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.


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 unei 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 asocierea 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ă capetele 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 capă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 atribute 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 utilizează 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 operaţ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 operaţ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 preluarea atributelor şi operaţiilor elementare intersectate obţinându-se atribute şi operaţii comune. Reprezentare modelului de obiecte


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 dinamic. 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 caracterizate 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ă obiectele 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 reunirea 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 reprezintă 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 abstractizarea 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: activităţ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, asociată 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).


Corelând stare-tranziţie-condiţie-operaţie se obţine Diagrama de Tranziţie a Stărilor (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 evenimente 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 acestui 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 dintre 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 arcele 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.


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

obiect.


2. Exprimaţi avantajele oferite de metoda OMT corelat 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ţional în metoda OMT?


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 drept 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, proiectantul 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 implementă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


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


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


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

Introducere


Arhitectura sistemelor informatice complexe a fost revăzută sub incidenţa unui curent privind formalizarea unui limbaj standard de modelare 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 formalizată 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 reinginerie 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 construirea 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 componentelor 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ă unificarea 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 pentru 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 diferitelor 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ă, proiectare ş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 generatoare 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, experţi, design-eri, implementatori etc.);


• 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 Obiectivele 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 propune 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 uman 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, îmbună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 limbajul 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 vederi, î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 elementului, 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 elemente 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ă atunci 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ă.


• 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. • Specificaţ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 mecanism 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 element 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 declaraţ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

implementare (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 descrie 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 putea 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 sistem 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 sistemului 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


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-economic; 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ţiilor 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 valorii 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, stabilite 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 implicate. 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 entropiei 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 antrenarea ş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 produselor 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 utilizatorului. 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.

Dimensionarea 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 procesul 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 minimă 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.

Consideră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ăspuns 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 privind 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 culturală. Se pune problema cum să reunim în acelaşi proiect competenţele în tehnologia informaţiei, marketing şi management?


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.


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 generale 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?


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


Conectarea logică dar şi fizică 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 tipuri. 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 implicit 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 executant 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 relaţ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 de 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 mulţ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 exprimare 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 controalelor, 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 modalitate 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 - ACCESS 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; Permite 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 pentru 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 prin transmitere de parametri; SQL încapsulat, care foloseşte instrucţiuni SQL încapsulate în codul program. Datorită acestui fapt apare necesitatea utilizării


unui precompilator pentru procesarea instrucţiunilor SQL; apelul direct, care presupune că alegerea 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 utilizatorului, 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 proiect 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 detaliat 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 gestiunii 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


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

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


Codul sursă SQL aferent interogării proiectate

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


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


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



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


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


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

Documents

Disciplina Sisteme informatice financiar-bancare si de ...se-b.spiruharet.ro/images/secretariat/licenta/fb/2016-2017/sinteze... · Sinteza curs: Sisteme informatice financiar-bancare