CAPITOL 2

METODE MODERNE DE PROIECTARE A UNUI

SISTEM INFORMATIC

2.1. Cerinţe generale în utilizarea unei metode de proiectare a sistemului

informatic

Evoluţia tehnologică presupune o anumită infrastructură care trebuie să cuprindă pe

lângă hardware, produse şi sisteme informatice bazate pe noi sisteme de gestiune a
bazelor de date sau pe noţiunea de teletransmisie materializată prin reţele naţionale
de date cu rate de transfer cât mai mari; posturi de lucru la toate nivelele
operaţionale dintr-o unitate (sisteme interactive om–maşină).

Mediile economice trebuie să se adapteze rapid la aceste tehnologii care presupun

costuri relativ ridicate ocazionate de elaborarea şi întreţinerea produsului
informatic, dar şi dificultăţilor crescânde de menţinere la anumite standarde a
nevoilor utilizatorilor.

Necesitatea adaptării devine stringentă în mediul financiar–contabil care priveşte

schimbările într-un orizont de timp ca pe o protecţie a investiţiei.

Continua dezvoltare a domeniului tehnologiei informaţiei impune elaborarea de noi

metodologii pentru realizarea sistemelor de aplicaţii informatice, cristalizându-se în
analiză şi proiectare două tipuri de metode utilizate: tradiţionale (structurate,
orientate pe funcţii/date, metode sistemice) şi metode orientate obiect.

34
Aportul fiecărei metode concretizat printr-un limbaj comun utilizator–informatician
este manifestat pe parcursul întregului proces de studiu prin apariţia şi existenţa
punctelor de validare.

Metoda, produs al reflexiei permanente, constituie un demers raţional şi empiric,

deductiv şi inductiv. Conform unor specialişti, metoda reprezintă un „ansamblu de
mijloace industriale puse în practică pentru organizarea unei fabricaţii” sau un
„ansamblu de reguli, principii normative care corespund învăţământului, practicii şi
artei” 14 . Ea se aplică tuturor conceptelor create de tehnologie, care observă şi
analizează practica cotidiană din organizaţii. Retrospectiv se constată că evoluţia
tehnologiei informatice15 are un impact important asupra metodelor de producere a
sistemelor informatice.

Un alt aspect care trebuie remarcat este faptul că o metodă nu poate servi scopuri
fundamentale divergente. Marea varietate de soft-uri disponibile (sisteme logice,
sisteme de gestiune în timp real) şi dezvoltarea activităţii de producţie software, mă
conduc la ideea că în informatică o metodă universală nu este posibilă.

Orice metodă de concepţie a unui sistem informatic trebuie să ia în considerare

factorii de natură tehnică şi socio-economică. În domeniul tehnic trebuie să permită
derularea activităţilor în timp real, utilizarea bazelor de date, a instrumentelor mini
şi micro-informatice pe fondul resurselor materiale, umane existente sau atrase.

În domeniul social şi economic metoda trebuie să integreze obiectivele unor

categorii de agenţi care urmăresc descentralizarea deciziilor operative; simplificarea
sarcinilor şi ameliorarea ergomiei postului de lucru; securitate şi confidenţialitate;
dezvoltarea proceselor de gestiune prin creşterea posibilităţii de supervizare la
diverse nivele; supleţe tehnică şi comercială sau structurală strict necesară în situaţii
de fuziune, extindere.

Metoda vizează asocierea eficientă a aspectelor organizaţionale şi informatice;

creşterea calităţii relaţiilor utilizatori–informaticieni, reprezentând un mijloc comun
de studiu, concepţie, dialog, formalizare a deciziilor şi de control preventiv. Cu alte

14
Le Nouveau Petit Le Robert, Edition 1993
15
O’Brien J. - Systèmes d’information de gestion, De Boeck Université

35
cuvinte, metoda în cadrul unui organism economic trebuie să fie un mijloc precis,
eficace, suplu dar nu rigid.

2.1.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. În cazul unor
schimbări apare problema determinării valorii informaţiei noi; definită prin efectul
deciziei posibile de adoptat. Existenţa stabilităţii mediului informaţional induce
aprecierea globală a sumei atuurilor sistemului informatic financiar-contabil
(S.I.F.C.).

Pentru un control eficient al modului de realizare al sarcinilor stabilite apreciez că

există două soluţii: funcţionarea controlului intern de gestiune; reconsiderarea rolul
tabloului de bord şi a bugetelor.

În acest context propun abordarea compartimentului financiar-contabil în trei

ipostaze (figura 2.1.):

Figura 2.1 Compartimentul financiar-contabil prin prisma costului, profitului, investiţiei

36
a) centru de costuri unde utilizatorii decidenţi şi managerul îşi asumă
responsabilităţi sporite în gestionarea a costurilor, iar performanţele vor fi judecate
prin capacitatea de a micşora ecarturile raportate la costurile previzionale, de a
sporii productivitatea şi de a propune soluţii (acţiuni) generatoare de profit.

b) centru de profit scoate în relief faptul că deşi profitul obţinut de contabilitatea

informatizată nu este autentificabil în sine, trebuie să considerăm că ea este un
prestator de servicii ce se adresează unor beneficiari bine identificaţi.

Opinia mea este că profitul mediului contabil este indus de beneficiile obţinute de
celelalte segmente ale firmei sau de aceasta ca urmare a folosirii produselor
informatice. Rezultatele obţinute pot fi apreciate, extrem de clar prin relaţia:

număr de lucrări (aspect cantitativ), « timp » conţinut lucrare (aspect calitativ).

c) centru de investiţie vizează contabilitatea informatizată care trebuie să câştige

autonomie în efectuarea investiţiilor (informatice) şi apoi se impune să le justifice.
Pentru zona contabilă informatizată putem vorbi de reliefarea unor plusuri
cantitative (economice) şi calitative (politice). În legătură cu primul aspect consider
că viteza de circulaţie a informaţiei, dar şi capacitatea ei de adaptare se pot constitui
în resurse importante. Remarc două faţete ale acestui tip de performanţă:

♦ Câştigurile directe de productivitate permit executarea unei aceleiaşi

atribuţii (decizii), cu mijloace reduse. De exemplu: o suprafaţă ocupată mai
mică, utilizatorii decidenţi mai puţini, costuri ale hardului, softului sau reţelei
mult diminuate.

♦ Creşterea volumul activităţilor financiar-contabile, unde informaţia

suplimentară poate avea un impact pozitiv asupra domeniului contabil
informatizat, dar numai în măsura în care are „desfacerea asigurată”.
Performanţele politice (calitative) sunt mult mai greu de evidenţiat sau mai
ales de comensurat.

Consider că cele mai importante obiective ale unei metode sunt:

♦ flexibilitatea sistemului;

37
 ♦ satisfacţia utilizatorilor;

♦ calitatea produselor financiar-contabile.

Flexibilitatea reprezintă capacitatea de adaptare a structurii contabilităţii

informatizate la mediu. Un sistem deschis, cu numeroase puncte de „ascultare” şi cu
o grijă deosebită pentru comunicaţie (orală, scrisă sau electronică) va reacţiona
rapid la oportunităţi şi va putea să ţină cont de restricţii. Flexibilitatea se va aprecia
prin raportarea la un anumit obiectiv, fixat în cadrul unei evoluţii „istorice”.
Sistemul deschis va avea în vedere şi practicile agenţilor economici16.

Satisfacţia utilizatorilor decidenţi reprezintă criteriul de apreciere a performanţei

sociale stabilit de „actorii” participanţi la procesul productiv creativ.

Calitatea produselor financiar–contabile este apreciată subiectiv de diferiţii

beneficiari: clienţi, bancă, manageri etc., dar şi obiectiv - prin deducerea „deşeurilor
informaţionale”, a erorilor etc. Depinde foarte mult de aşteptările diverşilor
consumatori (din interiorul sau exteriorul firmei), dar şi de sistemul de producţie
financiar – contabil în „ansamblu (inclusiv modalităţile de control).

În continuare voi prezenta câteva criterii de apreciere a performanţelor zonei

contabile informatizate pe care, după părerea mea, le consider esenţiale:

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. Apreciez că fiind necesară analiza evoluţiei şi a
adaptărilor prin prisma următoarelor stări ale structurii:

- specializare - gradul în care activităţile financiar-contabile sunt divizate pe „roluri"

specializate, în funcţie de pregătirea utilizatorilor decidenţi.

38
- standardizare - măsura în care sunt stabilite reguli şi proceduri generale pentru a
defini sarcinile de executat şi a controla aplicarea lor. Informatizarea contabilităţii
duce la crearea de noi proceduri, le elimină pe cele redundante sau neutilizate.

- formalizarea - nu este legată implicit de noile tehnologii, depinzând uneori de

gradul de pregătire al utilizatorilor decidenţi.

- centralizarea - vizează importanţa acordată luării deciziilor de către manager,

urmărindu-se să nu se accentueze fenomenul birocratic. În categoria criteriilor
organizaţionale de apreciere a performanţelor segmentului financiar–contabil
informatizat cred că se impune a fi inclusă şi măsurarea gradului de schimbare. În
acelaşi timp este importantă şi cunoaşterea atitudinii utilizatorilor decidenţi, în
vederea anticipării unei eventuale reacţii de respingere (putându-se folosi în acest
sens metodologia CRIG).

c) criteriile economice - utilizarea lor are în vedere tipul proiectului şi etapa

procesului de decizie. După părerea mea 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).

Consider că, 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;

16
Transition from the „data/processing”, www.softeam.com/conseil_modelisation

39
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 şi
eficacitatea utilizatorilor decidenţi)
Bază comună a prelucrărilor şi Efect de anvergură (cost al sistemului integrat <
comunicaţiei 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: Efect de anvergură (diminuarea costului de
- optimizarea prelucrărilor prelucrare şi transmitere)
- optimizare traficului
Remarc anumite „forţelor motrice” care ajută la formarea rezultatului sistemului
informatic financiar–contabil: producţia informaţională şi modalităţile de

40
valorificare a acesteia; preţurile de aprovizionare cu diferite materiale; evoluţia
salariilor utilizatorilor decidenţi şi/sau a managementului; costul de întreţinere şi
reparare al reţelei sau echipamentelor 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.

2.1.2. Necesitatea şi structura procesului de evaluare a contabilităţii

informatizate

Liniile de forţă ale evaluării contabilităţii informatizate se bazează pe două puncte

esenţiale: eficacitatea şi eficienţa. Există o raportare permanentă a contabilităţii
informatizate la un sistem de referinţă (referenţial) şi o legătură directă cu actul
deciziei, fapt ilustrat în figura 2.2.

Figura 2.2 Legăturile aferente actului decizie

Operaţia de evaluare în cadrul sistemului informatic financiar-contabil va ţine cont
de trei elemente fundamentale:

• resursa umană;

• raporturile de putere;

• referenţialul.

41
Pentru o evaluare corectă şi completă a contabilităţii informatizate consider că se
impune să se cunoască foarte bine contextul, practicile existente, dar şi „cultura" sau
istoricul. După părerea mea soluţia apelării la experţii din exterior nu este
întotdeauna cea mai bună deoarece ei se interesează mai mult de analiza
disfuncţionalităţilor decât de efectele declanşate de comportamentul sistemului.

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.
Aceştia pot fi de natură economică, tehnică, organizaţională, politică sau
sociologică şi se referă la aspecte cantitative şi calitative între care apare o vie
concurenţă. În acest fel se va evita creşterea sarcinilor administrative şi a efectelor,
accentuarea complexităţii căutării şi selecţiei datelor, depăşirea unui nivel al
costurilor dificil de suportat.

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). J.C. Emery şi G.A. Miller arată că în mod
normal capacităţile cognitive ale unui om nu pot înţelege simultan mai mult de 5-9
informaţii noi - „chunks”17.

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

17
Associations – Links, www.macs.hw.ac.uk/ism/ug4

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

Orice metodologie de utilizare a unei anumite situaţii din cadrul contabilităţii

informatizate, inclusiv stabilirea unui diagnostic corespunzător va implica un
demers riguros cu trei laturi:

• evaluarea criteriilor ce determină parametrii obiectivi ai unei anumite

reprezentări (de tip cantitativ);

• evaluarea criteriilor care duc la stabilirea ordinii congruenţelor în gândirea

contabilului şef şi a utilizatorilor decidenţi;

• valorizarea soluţiilor prin implicarea noilor restricţii pentru sistem.

Paradigmă

Evaluare Evaluare Valorizare

criterii criterii soluţii
cantitative calitative decidenţi

Parametrii Gândire Restricţii

obiectivi decidenţi

Figura 2.3 Criteriile de analiză a unei situaţii

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ă

43
atunci". Fluiditatea parametrilor de interpretare a elementelor structurale ale
contabilităţii informatizate va fi influenţată de faptul că, interpretarea nu poate avea
valoare decât într-un spaţiu temporal definit prealabil. 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. Apreciez că 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ă. În figura 2.4 am redat aplicarea metodei
scenariilor asupra elementului structural financiar-contabil.

A imagina un „scenariu” presupune construirea de structuri, de sisteme decizionale

şi repartizarea pe roluri (stabilirea responsabilităţilor). Uneori decizia finală este
sinteza rezultatelor diferitelor decizii intermediare luate.

Valorizarea scenariilor va avea un caracter relativ dacă se opreşte doar la aspectul

pur informatic şi dacă nu va urmări şi noţiunea de utilitate. Aceasta din urmă este
dificil de stabilit, deoarece fiecare utilizator decident, plasat în faţa unei aceleiaşi
situaţii, va avea obiective şi scopuri diferite.

44
Figura 2.4 Evaluarea compartimentului financiar–contabil prin metoda scenariilor
Valorizarea va ţine cont de natura informaţiei (operaţională, tactică, strategică) şi va
impune exprimarea utilităţii producţiei şi difuzării acesteia. Optimul soluţiei nu este
obligatoriu cel mai bun raport performanţă/preţ (o sumă la nivel operaţional nu va
avea aceeaşi valoare cu cea de la nivelul strategic).

Apreciez că, nu există alegeri bune sau rele, totul depinde de sistemul de referinţă
(referenţialul) ales, dacă aceasta se schimbă rezultatele evaluării se vor modifica.

2.2. Metodele de concepţie şi de realizare a unui sistem informatic

Metodele de concepţie 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. Concepţia constă în crearea, pornind de la specificaţiile,
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

45
(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).

Figura 2.5 Diagrama fluxurilor de date pentru Clienţi

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 redundanţe şi mai ales
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.

46
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ă18
care va fi integrată Merise şi metoda entitate–relaţie19.

Amintesc 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 eficientizează 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.

18
Tardieu H. şi col. - The individual model, International WorkShop on Data Structure Models for
Informations Systems
19
Chen P.- The entity-relationship model, ALM transaction of database systems, 1, 1, mars 1976

47
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
conceptual20 şi se disting patru nivele 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 şi 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 nivele de abstractizare introduse de
raportul ANSI/SPARC: conceptual, logic şi fizic”21. 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:

20
Nanci D. şi col. - Ingénierie des systèmes d’information avec Merise, Sybex
21
Stanciu V. şi col. - Proiectarea sistemelor informatice, Editura Dual Tech, Bucureşti

48
 • 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.);

• 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 obiect utilizează reguli sau operaţii semantice:

generalizarea/specializarea, agregarea/descompunerea, combinate cu moştenirea şi
încapsularea.

49
 2.2.1. Caracterizarea metodei Merise

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

Utilizarea metodei MERISE trebuie să facă posibilă descompunerea problemelor de

organizare a muncii. Practica în acest domeniu a evoluat considerabil traversând un
curent de gândire numit sistemică sau, ceea ce altă dată, se numea teoria sistemelor.
Din raţiuni didactice, pe parcursul însuşirii metodelor sistemice se poate asocia
figurativ enunţul următor: „a se ridica pentru a vedea mai bine...a înţelege...pentru a
acţiona mai bine”. Acest curent de gândire care a cuprins şi alte discipline de
cercetare, a oferit garanţia stabilităţii şi evoluţiei metodei, fiind baza filosofiei
MERISE22 iar toate conceptele operatorilor sistemici pentru ştiinţa organizării sunt
asimilaţi şi în cadrul acestei metode. „A înţelege nu este suficient pentru a acţiona,
trebuie şi să...decizi” constituie al doilea „suport” al filosofiei MERISE. Pot fi
consecinţe importante legate de acest demers, pentru că, de cele mai multe ori, în
ultimă instanţă soluţia pentru informatizarea unui domeniu dat este în realitate o
problemă de luare a unei decizii adecvate.

Fundamentul metodei constă în utilizarea mijloacelor de reprezentare cumulativă a

structurii organismelor economice corelată cu domeniile de activitate proprii.

Consider 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. În figura 2.5 prezint implicarea sistemului de management şi a
sistemului informaţional.

22
Merise Method Standard, http://nextojects.sourceforge.net

50
Figura 2.6 Reprezentarea domeniilor unui organism economic

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. În acest context apare evidentă implicarea metodei MERISE în fixarea
descrierii activităţii sistemului operant şi a implicării sistemului informatic. 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. Ansamblul activităţilor sistemului operant formează
imaginea dinamică de nivel „acţiune”.

Implicarea sistemului informaţional apare evidentă prin necesitatea de fuziune a

datelor exprimată de pilotaj şi execuţia operaţiunilor productive. În cadrul
proiectării unui sistem informatic, datele şi prelucrările sunt studiate şi modelate
împreună.

Corelând elementele prezentate anterior constat invariaţia funcţiilor sistemului

operant care determină activităţi bine delimitate.

51
Figura 2.7 Funcţii şi activităţi într-un sistem operant

În figura 2.7 am disociat ansamblul activităţilor sistemului operant faţă de mulţimea

funcţiilor sale. 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 Merise.

Responsabilitatea conducerii, coordonării unui proiect de informatizare într-un

organism, ne situează în faţa realităţii următoare:

• termenele cuprinse în studiul de proiect trebuie respectate;

• decelarea problemelor legate de organizare şi informatizare necesită o anumită

„filozofie”;

• existenţa mijloacelor care să permită localizarea şi rezolvarea problemelor.

MERISE este o metodă cu ajutorul căreia se poate defini, analiza, concepe şi realiza
un proiect care acoperă activitatea unui domeniu bine definit. Ea are la bază o
filosofie proprie a derulării întregului proiect, urmărind detalierea fiecărei etapă de
studiu şi aplicarea unor instrumente specifice.

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.

52
Reamintesc î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. Apărătorii acestei abordări avansează
argumentul că este mai bine să acţionezi progresiv, decât să mizezi pe ipoteza
nerealistă că un proiect global poate fi ţinut permanent la zi.23

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.

Este mai bine să se creeze şi să se realizeze din start un sistem informatic care să
ţină cont de obiectivele planificate, abordate într-o maniere globală, decât să se
încerce a se integra a posteriori, subsisteme informatice independente. MERISE este
o metodă de concepţie de sisteme informatice care se poate înscrie în această
abordare descendentă.

În esenţă, filosofia MERISE se poate constitui sub forma unui ghid de abordare a
unui sistem informatic pus în evidenţă sub forma sintetică utilizând o semantică
bazată pe cuvinte cheie cât mai sugestive. MERISE poate realiza sisteme
informatice din mai multe perspective:

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

23
Marciniak R. şi col. – Systèmes d’Information dynamique et organisation, Editura Economica, Paris

53
• MERISE perspectivă paralelă date–prelucrări. Faţă de alte metode care tratează
în mod privilegiat datele sau prelucrările, MERISE ţ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 în MERISE prin instrumentele de sincronizare.

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

• MERISE viziune globală asupra unui subansamblu reprezentativ. În majoritatea

cazurilor vederea de ansamblu poate considera un domeniu ca fiind cel mai
important. Grija de a nu lungi prea mult studiul domeniul respectiv şi pretenţia
acestui studiu de fi exhaustiv, sunt deseori contradictorii. Subansamblu
reprezentativ (SREP) este soluţia oferită de metoda MERISE pentru a concilia
aceste două nuanţe contradictorii. Subansamblu reprezentativ presupune cu
necesitate un studiu prealabil.

• MERISE din 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 externe24.

Demersul metodei 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”25. Î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.

24
Reix R. – Systemes d’information et management des organisations, Editura Vuilbert, Paris
25
Merise Method and knowledge, www.cmi.univ-mrs.fr

54
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 2.8 am reprezentat cerinţele la care răspunde metoda MERISE constatând
interdependenţele externe, interne şi fundamentale.

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

Sub formă tabelară prezint etapele acestei metodei sintetizând rezultatele fiecărui
stadiu.

STUDIU FUNCŢIUNI REZULTAT DECIZIA

după studiu
Studiu Studiu situaţiei actuale Dosar de opţiuni conţinând Decizia
prealabil Degajarea unui mijloacele de punere în pentru o
lucru soluţie
subansamblu reprezentativ
Studiu Studierea detaliată a Specificaţii funcţionale Acordul

55
 STUDIU FUNCŢIUNI REZULTAT DECIZIA
după studiu
detaliat diferitelor domenii pentru „externe” generale şi utilizatorilor
soluţia reţinută detaliate
Realizarea Studiul tehnic Sistem de criterii de piaţă Recepţia
Realizarea programelor privind „jocul” de probă al provizorie
utilizatorilor
Punerea în Studiul de ansamblu al Sistem implantat în Recepţia
lucru problemelor legate de ambientul real şi definitivă
utilizarea noilor funcţiuni funcţionând în regim
automate normal.
În momentul descompunerii subansamblul 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 2.9 reprezint iniţierea şi derularea paşilor care privesc studiul prealabil.

Figura 2.9 Studiu prealabil în cadrul metodei Merise

Metoda MERISE în contextul unei unităţi bancare pentru un subansamblu

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 subetape26:

» iniţializare;

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

56
 » 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 nivele de modele de date şi prelucrări după cum se deduce din sinteza
supusă atenţiei în continuare:
Alegere Obiect Nivel de Exemplu de
descris abstracţie modele
Ce se GESTIUNE Date CONCEPTUAL MODELUL
doreşte CONCEPTUAL AL
Relaţii DATELOR
să se facă (invariant static)
în fond Reguli de
gestiune MODELUL
CONCEPTUAL AL
Înlănţuiri PRELUCRĂRILOR
de (invariant dinamic)
prelucrări
Cine face ORGANIZAŢIONAL Oameni LOGIC SAU MODELUL LOGIC
Cu ce şi Maşini ORGANIZAŢIONAL DE DATE
Când Reţele MODELUL LOGIC
diferite DE PRELUCRARE
Repartiţie
geografică
Cum se TEHNIC Entităţi FIZIC MODELUL FIZIC
face AL DATELOR
Programe SAU
MODELUL FIZIC
OPERAŢIONAL
Proceduri AL
PRELUCRĂRILOR

Pot concluziona că la întrebarea „cum se face?” din punct de vedere tehnic prin
modelul fizic al datelor, modelul fizic al prelucrărilor pot răspunde prin entităţi
programe proceduri. La întrebarea „cine, cu ce şi când?“ din punct de vedere

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

În continuare supun atenţiei sintetiza nivelelor de abstractizare corelate cu

ansamblul date-prelucrări.

DATE PRELUCRĂRI
CONCEPTUAL Modelul conceptual al datelor Modelul conceptual al prelucrărilor
MCD MCP
- Concepte fundamentale - Descrierea macroscopică (noţiunea
- Relaţii semantice de proces)

LOGIC Modelul logic de date Modelul logic al prelucrărilor

MLD MLP
Integrarea restricţiilor de - Integrarea alegerii opţiunii
organizare - Repartiţia om - maşină
- Traducerea în SGBD - Timp real – timp diferit
’ entitate Desfacerea proceselor Æ proceduri
’ relaţie Æ Faze Æ sarcini
’ instanţă (realizare)
FIZIC Modelul fizic al datelor Modelul fizic al prelucrărilor
MFD MFP
Descrierea bazelor de date Descrierea programelor
Noţiuni de înregistrare Descrierea procedurilor
Corelând figura 2.8 referitoare la „Merise Ce-cum-cu cine se realizează?”,
nivelurile de abstracţie, modelele rezultate, deduc şi prezint următoarele expresii:

Viziunea exterioară: model extern=o vedere a unui utilizator FORMALISM

= =
Ansamblul informaţiilor operaţionale pentru o prelucrare 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.

58
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. Mai multe concepte de bază caracterizează acest model:

- proprietatea este o modelare a informaţiei elementare, de exemplu funcţia

exercitată de un salariat: vânzător, contabil, informatician etc.

- identificatorul permite modelarea unui ansamblu de obiecte concrete sau abstracte,

percepute ca fiind pertinente pentru sistemul informatic studiat, de exemplu
identificatorul salariatului sau identificatorul produsului. Elementele din acest
ansamblu sunt ocurente, de exemplu în cazul salariatului ocurenţa este exprimată
astfel: „Georgescu, 28 ani, manager”.

Regulile de pertinenţă, de identificare, de evidenţiere, de verificare şi omogenitate

conduc la modelizarea termenilor identificării.

- relaţia între mai mulţi indivizi este un ansamblu de produse carteziene de ocurenţă
a acestora. De exemplu produsul cartezian vânzător * client reprezentat prin toate
cuplurile vânzător/client, va fi modelat prin ansamblul de legături care exprimă
aceeaşi natură între mai mulţi indivizi. Bineînţeles, aceste relaţii trebuie să fie
pertinente în raport de sistemul informatic studiat.

- cardinalitatea reprezintă cuplul entitate–relaţie. În spatele cardinalităţilor se găsesc

reguli de gestiune reale.

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

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

60
Construcţia modelelor organizaţionale 27 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.

În figura 2.10 vă supun atenţiei reprezentarea cumulată a MOP-MOD-MOC care

încearcă să evidenţieze circuitul „sarcini-prelucrări”, „date” şi „mesaje”.

Figura 2.10 Traseul „sarcini-prelucrări”, „date”, mesaje”

Problematica modelului organizaţional este sintetizată în tabelul următor:

Problematica MOP Problematica MOD Problematica
MOC
- Repartizarea prelucrărilor pe centre, - Repartizarea datelor: - Schimburile de
unităţi şi posturi de lucru pe centre, unităţi şi mesaje între centre
- Caracterizarea sarcinilor: posturile posturi de lucru
raportate, gradul de automatizare, - Volumetrie
termenul de răspuns, modul de - Istoric
funcţionare, regulile şi procedurile
- Securitate
aplicabile, frecvenţa, durata, capacitatea
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 externe28 privesc datele drept mesajele legate la
evenimente–rezultate. Continuarea studiului presupune modelarea sistemului şi se

27
Nextobjects is based on the Merise Method, www.nextobjects.sourceforge.net
28
Information Systems Group UG2, www.cee.hw.ac.uk/ism/ug2/ass3

61
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ă supun atenţiei sinteza reunirii modelelor logice şi fizice ale
datelor, prelucrărilor, comunicaţiei.

Problematica MLP şi al MFP Problematica MLD şi Problematica MLC şi

al MFD al MFC

- Repartizarea prelucrărilor - Transformare MOD - Mesaje între centre

informatizate: centre, unităţi după tipul SGBD prin magistrale
logice de prelucrare. - Dimensiunea MLD informatice
- Modularizare - Optimizarea

Concluzionând ideile prezentate pe parcursul acestui subcapitol, afirm 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.

2.2.2. Metoda OMT de proiectare a sistemelor informatice

OMT – Object Modeling Tehnique – este bazată pe modele ca abstracţii ale

problemelor din lumea reală, care urmăresc focalizarea aspectelor importante ale

62
problemei şi omisiunea celor irelevante. Această metodă a fost creată de James
Rumbaugh şi este cea mai cunoscută şi utilizată metodă de proiectare orientată
obiect (POO). 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. Noţiunea de „obiect” 29 este dependentă de implementarea metodei în
limbajele de nivel înalt cum ar fi: ADA, MODULA, SMALLTALK, C++, CLOS
(Common Lisp Object System).

Această metodă are în vedere trei aspecte importante:

• abstractizarea realităţii, ceea ce înseamnă că pentru aceeaşi problemă se pot

crea mai multe modele care să focalizeze diferite aspecte;

• scopul modelului este să se focalizeze ceva cunoscut;

• comunicarea între membrii echipei de analiză-proiectare şi între utilizatori.

Metodele orientate obiect propun modelarea concomitentă a datelor şi a funcţiilor

obţinând ierarhii de clase de obiecte care înglobează atât datele cât şi
comportamentul, spre deosebire de modelarea datelor separată de a funcţiilor,
element structural al metodelor tradiţionale.

Comparativ cu metodele tradiţionale, abordarea orientată-obiect mută centrul de

greutate al soluţionării problemei în faza de analiză, fapt compensat printr-un minim
de efort necesar a fi depus în faza de implementare. O bună înţelegere a cerinţelor
problemei reale va conduce la construirea unui model fiabil, adaptabil, care suportă
uşor modificările ulterioare.

Metodele obiect integrează modelarea de structură cu cea comportament30. 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.

29
Rational whitepaper, www.rational.com
30
Ayache R. N. - The management control function, Boston: the Harvard Business School Press

63
 Corespunzător metodologiei31 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. Această metodă de proiectare susţine strategia
prototipizări de structurare a procesului de realizare a produselor informatice.

Supun atenţiei câteva dintre avantajele acestei abordări:

• software-ul este asamblat (construit) din componente care au o calitate

probată în implementările anterioare;

• obiectele individuale pot fi modificate fără a le afecta pe celelalte, rezultând

că software-ul construit modular poate fi modificat şi dezvoltat cu eforturi
minime;

• reutilizarea componentelor soft existente, tehnologie care asigură realizarea

de aplicaţii într-un timp scurt şi la costuri reduse.

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. Existenţa şi necesitatea acestor modele solicită şi realizează o strânsă
conexiune între ele. Fiecare model în OMT poate fi reprezentat prin diagrame
distincte32:

31
Rumbaugh's Method, www.iconixsw.com/Rumbaugh.html
32
Castellani X. - Méthodologie générale d’analyse et de conception des systèmes d’objects. 1. L’ingénierie
des besoins, Masson

64
 • 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).

În reprezentarea ciclului de viaţă al unui proiect se utilizează mai multe modele, dar
flexibilitatea metodelor orientate-obiect permite lucrul într-un ciclu de viaţă
„spirală”. Ciclul de viaţă spirală sau modelul spirală, spre deosebire de modelul în
cascadă, specific metodelor structurate, presupune faptul că doar o parte a
modelului trebuie să fie finalizat înainte de a trece la faza următoare. Aceasta
înseamnă că versiunii parţiale ale sistemului pot fi livrate în timp scurt, evaluate şi
validate de către utilizator, proiectantul realizând extrem de rapid analiza pentru
completarea modelelor.

Feed-back-ul permite găsirea de soluţii convenabile, iar flexibilitatea modelelor

orientate–obiect permite armonizarea cerinţelor utilizatorului cu soluţiile propuse de
echipa de realizatori. Modelul „în cascadă”, chiar în varianta care cuprinde iterarea
fazelor, permite detectarea şi corectarea erorilor înainte de trecerea la faza
următoare şi impune ca în fiecare fază să se producă un document şi produse valide.

Corectarea erorilor în fazele următoare celei în care s-au produs este foarte
costisitoare (timp, efort), aducând importante prejudicii prin faptul că utilizatorul
trebuie să aştepte până la sfârşitul implementării pentru a vedea dacă sistemul
corespunde necesităţilor exprimate.

65
2.2.2.1. Etapele ciclului de realizare a unui proiect în abordarea orientată–obiect

Etapele ciclului de realizare în abordarea orientată – obiect sunt în mare parte

comune cu viziunea Merise, dar apar şi elemente specifice.

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 2.11
am reprezentat o secvenţă a activităţi analizei şi modelării evenimentului studiat.

Figura 2. 11 Circuitul analiză-modelare evenimente

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 (figura 2.12) se
materializează prin definirea unui model precis, concis, inteligent şi corect al
viitorului sistem.

66
Figura 2. 12 Obţinerea modelului de analiză

O reprezentare sintetică a activităţilor şi rezultatelor este supusă atenţiei în tabelul

următor:
Faze şi activităţi Mod de reprezentare Descriere
A.1. Analiza şi modelarea evenimentelor
Scrierea declaraţiei Text liber Declaraţia problemei (de către client
problemei (formularea sau elaborator)
problemei)
Analiza evenimentelor Diagrama de Trasare a Scenarii de evenimente pentru
problemei Evenimentelor (DTE) evenimentele complexe ale aplicaţiei
Modelarea Diagrama de Comunicare Diagrama de Comunicare între Clase
evenimentelor între Clase (DCC) cu mesaje şi interacţiunile dintre
Diagrama de clase
Generalizare a Mesajelor Diagrama de Generalizare a
(DGM) Mesajelor specifică interacţiunii
între clase
A.2. Construirea modelului de analiză
Definirea modelului Diagrama de Asociere a Model de obiecte cu clasele
obiectual Claselor (DAC) aplicaţiei atributele, operaţiile şi
asocierile lor.
Definirea modelului Diagrama de Tranziţie a Modelul dinamic (DTS) pentru clase
dinamic Stărilor (DTS) importante şi modelul de obiecte
care încorporează rezultate din DTS
Definirea modelului Diagrama de Flux de Modelul funcţional cu
funcţional Date (DFD) funcţionalitatea operaţiilor complexe
şi completarea lor în DAC
Reiterarea şi Verificări Se completează modelul de obiecte
verificarea din celelalte iteraţii şi se verifică
consistenţa

67
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ă mari faze şi anume: construirea arhitecturii

sistemului; modelarea detaliilor subsistemelor.

În faza de construire a arhitecturii sistemului se dezvoltă aşa numitele 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.

Soluţia de sistem proiectată va include pe lângă clasele de bază şi clasele de

interfeţe grafice, clasele de acces la bazele de date. Suma acestora reprezintă soluţia
generală de organizare.

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

Sintetizarea fazelor şi activităţilor etapei de proiectare de sistem este relevată de

tabelul de mai jos:

68
 Faze şi activităţi Modalităţi de Descriere
reprezentare
1. Construirea arhitecturii sistemului
1.1. Organizarea sistemului în subsisteme
a) Importul sistemului DCC Se utilizează din etapa de analiză DCC şi DAC
claselor de bază DAC
b) Alegerea unei arhitecturi Text Se stabileşte arhitectura sistemului
c) Crearea unui Model de DCC la În DAC din etapa de analiză, actorii vor fi
Comunicare între Clase de nivel de înlocuiţi cu subiecţi, clasele de bază vor fi
Nivel de Proiect proiect grupate, se adaugă şi se conectează subiectul
„Clase de Interfaţă”
d) Crearea sistemelor Text Fiecare subiect din diagramă va fi descompus
pentru fiecare subiect într-un sistem cu acelaşi nume.
1.2. Definirea interfeţelor DGM Completarea modelului de comunicare a
DCC claselor la nivel de proiect cu mesajele compuse
nou definite
1.3. Identificarea obiectelor Text Identificarea obiectelor care sunt active în
active concurente şi acelaşi timp şi a celor care au un comportament
exclusive exclusiv
1.4. Alocarea Text Se alocă subsistemele la procesoare, astfel încât
subsistemelor pe să asigure satisfacerea cerinţelor de performanţă
procesoare şi task-uri şi minimizarea comunicării
1.5. Alegerea strategiei de Text Se aleg structurile de date, fişierele sau bazele
bază pentru implementarea de date corespunzătoare
datelor memorate
1.6 Identificarea resurselor Text Identifică resursele globale şi determină
globale şi determinarea mecanismele pentru controlarea accesului
mecanismelor pentru
asigurarea accesului la
date.
1.7. Alegerea variantei de Text
implementare a controlului
1.8. Stabilirea condiţiilor Text
limită
1.9. Stabilire priorităţi
2. Modelarea detaliilor de subsistem
2.1 Definirea modelului de DCC Definirea modelului de comunicare între clase
comunicare a claselor la nivel de sistem din modelul de comunicare la
nivel de proiect
2.2. Detalierea modelului DAC Detalierea modelului obiectual din faza de
obiect analiză
Proiectarea obiectuală – are drept scop alegerea modului de implementare pentru
fiecare clasă, proiectându-se algoritmi şi implementându-se asocierile. Se realizează

69
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.
Scopul etapei este de a adăuga la modelul obiectual rezultat al etapelor de analiză şi
proiectare de sistem, detaliile de implementare necesare fie pentru generarea
automată de cod, fie pentru dezvoltarea ulterior fără generare automată. Când se
trece la etapa de implementare prin generare automată de cod, atunci modelul obiect
este singurul utilizat, una din activităţile etapei de proiectare obiectuală
Plecând de la aceste obiective în 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ării33. Astfel:

• modelul obiectelor determinat în etapa de analiză va fi acum rafinat prin

introducerea de noi clase (care păstrează rezultatele intermediare ale calculului),
operaţii (descoperite abia acum) şi atribute.

• modelul funcţional va descrie operaţiile pe care proiectantul trebuie să le

implementeze. În timpul proiectării acesta va alege algoritmii de implementare a
unei operaţii şi va descompune operaţiile mai complexe în operaţii mai simple.

• modelul dinamic descrie felul în care sistemul răspunde stimulilor externi.

Structura de control a programului derivă din acest model. 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ă.

33
Object-Oriented Development Interactive Systems, http://citeseer.nj.nec.com/aalto94objectoriented.htm

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

2.2.2.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ă.
Nume_Clasă
NumeAtribut[:tip=valoare_implicită]
Obiectele se diferenţiază între ele prin valorile atributelor la un moment dat, care
constituie starea obiectului în acel moment. O categorie specială de atribute sunt
cele ale clasei. Un atribut al clasei, simbolizat prin „$” are o valoare comună clasei
de obiecte şi nu unei instanţe specifice.
NumeClasa
/Nume atribut
$Nume_atribut
....

71
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. Toate aceste elemente
sunt trecute în partea inferioară a simbolului clasei, sub partea destinată atributelor.
NumeClasă
...
NumeOperaţie(lista_argumente):tip_rezultat
$Numeoperaţie
O operaţie este o funcţie sau o transformare aplicată obiectelor unei clase. O
modificare a unui obiect al unei clase acţionează asupra stării obiectului prin
transformarea/consultarea acesteia, asupra altui obiect aparţinător clasei sau asupra
obiectelor incluse altei clase.

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 sa (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.
Operaţia clasei utilizează simbolul „$” în faţa numelui şi are forma generală:
NumeClasă
NumeAtribut_1:tip_1=valoare_implicită_1
NumeAtribut_2:tip_2=valoare_implicită_2
...
NumeAtribut_m:tip_m=valoare_implicită_m
NumeOperaţie_1(lista_argumente_1):tip_rezultat_1
NumeOperaţie_2(lista_argumente_2):tip_rezultat_2
...
NumeOperaţie_n(lista_argumente_n):tip_rezultat_n

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

Corespunzător unei asocieri apare o valoare ataşată fiecărei legăturii. Există situaţii
în care este necesar ca o asociere să fie modelată drept clasă, identificată prin
reprezentarea:

Figura 2. 13 Forma generală de reprezentare a unei asocieri modelate ca o clasă

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 2.14 care exemplifică asocierea modelată ca o clasă, apare

„Suma_împrumutat” care nu aparţine clasei „Client” şi nici „Bancă”.

73
Figura 2. 14 Asociere „Împrumut” modelată ca o clasă
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 2.15 se sintetizează acordarea împrumutului de către bancă unui client

pentru anumite investiţii.

Figura 2. 15 Asociere „Client”-„Bancă”-„Investiţie”

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

74
obiecte de la capătul „mulţi” al unei asocieri. Asocierea calificativă este exprimată
sub forma:

Nume_clasă1 Calificator Nume_clasă2

Generalizarea 34 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. În figura 2.16 am realizat reprezentarea
generală a moştenirii, observându-se că intervine şi mecanismul de specializare
descendent, cu o acţiune opusă celui de generalizare.

34
Doc’s submitted to World Scientific, www.geocities.com/siliconvalley/9219/resume.htm

75
Figura 2. 16 Reprezentarea generală a „moştenirii”
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”. Pot prezenta spre exemplificare, (figura 2.17) diagrama de asociere
între clase pentru „problema” de urmărire a clienţilor, comenzilor şi stocurilor.

Figura 2. 17 Monitorizarea simultană a clienţilor, comenzilor şi a stocurilor

Este evidentă agregarea client_cash client_virament în superclasa „client” care
execută operaţia „Achită”.

76
2.2.2.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 (figura 2.18)
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.

Figura 2. 18 DTE a aplicaţiei Clienţi

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

78
Figura 2. 19 Forma generală a unei DTS

Diagrama de Tranziţie a Stărilor pentru clasa de obiecte „element-în_stoc” este

reprezentată ca în figura 2.20 î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.

Figura 2. 20 DTS pentru clasa de obiecte „Element_în_stoc”

Diagrama de Tranziţie a Stărilor poate fi privită în mod dinamic, descriind structura
de control a sistemului şi unde stările interacţionează unele cu altele prin
evenimente partajate.

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

35
A Survey of OO Methods, http://students.cs.byu.edu/~pbiggs/survey.html

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

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.

36
N. Yoshida, Object-Oriented Extension for Reuse of Models, 6-th Conf. on Asia-Pacific Design Language

80
2.3 Unified Modeling Language – cale de reunire a conceptelor orientate-obiect

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.37) care propun
structuri ale sistemului în raport cu implementarea acestuia, implementarea fiind
privită ca o activitate secundară. Astfel la întrebarea fundamentală “Ce este
programarea, mai mult o artă, sau mai mult o ştiinţă”, s-a răspuns prin
primordialitatea explicită a arhitecturii sistemului. 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;

37
Usige UML-based Framework, www.omg.org/news/meetings/worksshops/presentations

81
• 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 diagrame38.

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

Figura 2. 21 Ierarhia de modele, vederi şi diagrame utilizate de UML

38
Davidescu N. – Proiectarea Sistemelor Informatice prin limbajul UML, Editura ALL Back, Bucureşti

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

2.3.1 Avantajele oferite de UML

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.

2.3.2 Obiectivele fundamentale ale UML

UML are un spectru larg de utilizare putând fi utilizat î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;

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

Consider 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. În figura 2.22 am reprezentat vederile specifice cazului de utilizare
(Use-Case VIEWS) fiind o descriere generică a utilizării sistemului prin intermediul
funcţiilor.

84
Figura 2. 22 Proiecţia viziunilor cazului Use Case

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.

2.4. Comparaţii între metodele de proiectare

Având în vedere faptul că structura datelor, aplicaţiilor cât şi relaţiile dintre acestea
sunt mult mai puţin vulnerabile la schimbarea, comparativ cu funcţiunile,
organizarea sistemului în jurul obiectelor acordă o mare stabilitate de-a lungul
întregului ciclu de dezvoltare. Totodată proprietatea de încapsulare, specifică
orientării obiect, cât şi interfeţele care ascund implementările interne ale obiectelor,
constituie un înalt nivel de protecţie oferit sistemului astfel modelat.

85
Un alt avantaj oferit de abordarea orientată obiect îl constituie liniaritatea
procesului de dezvoltare a sistemului. Deoarece metodologia orientată-obiect
defineşte din primele faze obiectele pe care continuă să le folosească şi să le extindă
de-a lungul întregului proces, separarea dintre fazele ciclului de viaţă este mai puţin
perceptibilă.

În Object Modeling Technique obiectul modelat în timpul fazei de analiză este

utilizat şi în fazele de proiectare şi implementare, unde este rafinat şi extins
progresiv 39 . Procesul este liniar pentru că nu există discontinuităţi a notaţiilor
utilizate pe tot parcursul derulării activităţii. Această liniaritate permite reluarea
procesului de modelare iterativ, fiecare iteraţie adăugând sau clarificând anumite
detalii, obţinându-se în final un model consistent, cu grad redus de eroare.

Deosebiri substanţiale între diversele metodologii orientate-obiect nu există,

majoritatea celor utilizate în prezent fiind mai mult o colecţie de tehnici şi convenţii
grafice de reprezentare care au ca obiectiv principal îmbunătăţirea sistemelor
complexe40 plecând de la funcţie, comportament, date.

O comparaţie între OMT şi unele dintre cele mai răspândite metode orientate obiect,
din punct de vedere al conceptelor utilizate, este prezentată în continuare:

Concepte OMT41 OOAD42 Booch OOSE43

Rumbaugh Jacobson
Clasă * * Obiect
Clasă abstractă * * *
Clasă concretă * * *
Metaclasă * * *
Clasă generică Clasă parametrizată
Obiect * * *
Obiect activ *
Obiect pasiv *
Obiect entitate *
Obiect de interfaţă *

39
Booch method – Wikipedia, www.wikipedia.org/wiki/Booch
40
Project management, www.icaen.uiowa.edu/~softeng/SElinks.html
41
OMT Object Modelling Technique
42
OOD Object Oriented Design
43
OOSE- Object-Oriented Software Engineering

86
 Concepte OMT41 OOAD42 Booch OOSE43
Rumbaugh Jacobson
Obiect de control *
Obiect de interfaţă *
central
Cheie/identificator Cheie candidată Cheie
Atribut * Câmp *
Atribut derivat * *
Atribut al asocierii * *
Atribut calificator *
Atribut discriminator *
Restricţii pentru atribut * *
Se poate concluziona că metodologiile orientate-obiect analizate nu se deosebesc
substanţial, ele prezintă de fapt aceleaşi concepte văzute din puncte de vedere
diferite şi cu notaţii diferite.

OMT comparativ cu celelalte metode orientate-obiect prezintă avantajul că

utilizează aceleaşi notaţii pentru modelare în întregul ciclu de viaţă, astfel încât nu
este necesară o trecere brutală la alte notaţii sau interpretări ale semanticii în etapele
următoare ale proiectării. Principalul dezavantaj este acela că nu oferă o ghidare
metodologică încă din etapele timpurii ale procesului de dezvoltare.

87
CAPITOL 2...................................................................................................................... 34
METODE MODERNE DE PROIECTARE A UNUI SISTEM INFORMATIC
............................................................................................................................................. 34
2.1. Cerinţe generale în utilizarea unei metode de proiectare a sistemului informatic.... 34
2.1.1. Parametrii specifici de performanţă pentru sistemele informatice .................... 36
2.1.2. Necesitatea şi structura procesului de evaluare a contabilităţii informatizate... 41
2.2. Metodele de concepţie şi de realizare a unui sistem informatic ............................... 45
2.2.1. Caracterizarea metodei Merise .......................................................................... 50
2.2.2. Metoda OMT de proiectare a sistemelor informatice........................................ 62
2.2.2.1. Etapele ciclului de realizare a unui proiect în abordarea orientată–obiect . 66
2.2.2.2. Modelul obiect în metodologia OMT......................................................... 71
2.2.2.3. Modelul dinamic în accepţiunea metodei OMT......................................... 77
2.2.2.4. Modelul funcţional al metodei OMT.......................................................... 79
2.3 Unified Modeling Language – cale de reunire a conceptelor orientate-obiect.......... 81
2.3.1 Avantajele oferite de UML................................................................................. 83
2.3.2 Obiectivele fundamentale ale UML ................................................................... 83
2.4. Comparaţii între metodele de proiectare .................................................................. 85

Figura 2.1 Compartimentul financiar-contabil prin prisma costului, profitului, investiţiei 36

Figura 2.2 Legăturile aferente actului decizie ..................................................................... 41
Figura 2.3 Criteriile de analiză a unei situaţii...................................................................... 43
Figura 2.4 Evaluarea compartimentului financiar–contabil prin metoda scenariilor .......... 45
Figura 2.5 Diagrama fluxurilor de date pentru Clienţi ........................................................ 46
Figura 2.6 Reprezentarea domeniilor unui organism economic.......................................... 51
Figura 2.7 Funcţii şi activităţi într-un sistem operant.......................................................... 52
Figura 2.8 MERISE – Ce-cum-cu cine se realizează?......................................................... 55
Figura 2.9 Studiu prealabil în cadrul metodei Merise ......................................................... 56
Figura 2.10 Traseul „sarcini-prelucrări”, „date”, mesaje”................................................... 61
Figura 2. 11 Circuitul analiză-modelare evenimente........................................................... 66
Figura 2. 12 Obţinerea modelului de analiză....................................................................... 67
Figura 2. 13 Forma generală de reprezentare a unei asocieri modelate ca o clasă.............. 73
Figura 2. 14 Asociere „Împrumut” modelată ca o clasă...................................................... 74
Figura 2. 15 Asociere „Client”-„Bancă”-„Investiţie” ......................................................... 74
Figura 2. 16 Reprezentarea generală a „moştenirii”............................................................ 76
Figura 2. 17 Monitorizarea simultană a clienţilor, comenzilor şi a stocurilor..................... 76
Figura 2. 18 DTE a aplicaţiei Clienţi................................................................................... 77
Figura 2. 19 Forma generală a unei DTS............................................................................. 79
Figura 2. 20 DTS pentru clasa de obiecte „Element_în_stoc” ............................................ 79
Figura 2. 21 Ierarhia de modele, vederi şi diagrame utilizate de UML............................... 82
Figura 2. 22 Proiecţia viziunilor cazului Use Case ............................................................. 85

88