1

Cuprins
UNITATEA 8...........................................................................................................3
SISTEME INFORMATICE.....................................................................................3
U8.1. Scopul i obiectivele unitii...................................................................3
U8.2. Definire....................................................................................................3
U8.3. Ciclul de via al unui sistem informatic.................................................6
8. 3. 1. Modelul WATERFALL (n cascad)...................................................7
8. 3. 2. Modelul INCREMENTAL (RAPID-PROTOTYPING)......................8
8. 3. 3. Modelul ciclului de concepie n V.................................................10
8. 3. 4. Modelul OPERAIONAL.................................................................11
MODULUL 3.........................................................................................................15
UNITATEA 9.........................................................................................................16
METODA MERISE - PREZENTARE..................................................................16
U9.1. Scopul i obiectivele unitii.................................................................16
U9.2. Prezentare metoda MERISE..................................................................16
UNITATEA 10.......................................................................................................23
METODA MERISE CICLUL DE VIA.........................................................23
U10.1. Scopul i obiectivele unitii...............................................................24
U10.2. Elaborarea temei de realizare a sistemului informatic........................24
10. 2. 1. Tehnica documentrii.......................................................................25
10. 2. 2. Metoda analizei-diagnostic..............................................................26
10. 2. 3. Metoda diagramelor de flux informaional .....................................27
10. 2. 4. Metoda evidenei economice............................................................28
10. 2. 5. Metoda anchetelor............................................................................29
10. 2. 6. Metoda scenariilor ...........................................................................33
U10.3. Proiectarea logic (elaborarea concepiei............................................34
sistemului informatic).........................................................................34
U10.4. Proiectarea tehnic..............................................................................48
U10.5. Elaborarea programelor.......................................................................56
U10.6. Implementarea, exploatarea i ntreinerea..........................................66
UNITATEA 11.......................................................................................................67
METODA MERISE CICLUL DE ABSTRACTIZARE.....................................67
U11.1. Scopul i obiectivele unitii...............................................................68
U11.2. Modelul conceptual al datelor.............................................................68
U11.3. Modelul logic al datelor......................................................................77
U11.4. Modelul fizic al datelor.......................................................................83
U11.5. Modelul conceptual al comunicaiilor.................................................84
U11.6. Modelul conceptual al prelucrrilor....................................................86
U11.7. Modelul organizaional al prelucrrilor...............................................98
U11.8. Modelul operaional al prelucrrilor.................................................102
UNITATEA 12.....................................................................................................103
METODA MERISE CICLUL DE DECIZIE....................................................103
U12.1. Scopul i obiectivele unitii.............................................................103
U12.2. Ciclul de decizie................................................................................103

UNITATEA 8
SISTEME INFORMATICE
Durata medie de studiu individual - 2 ore

Cuprins:

pag.

U8.1. Scopul i obiectivele unitii .............................................................

U8.2. Definire ...............................................................................................
U8.3. Ciclul de via al unui sistem informatic .........................................
U8.4. Test de autoevaluare .........................................................................
U8.5. Rezumat .............................................................................................
Bibliografie minimal .................................................................................
Rspunsuri i comentarii la testul de autoevaluare .................................

89
89
92
100
101
101
102

U8.1. Scopul i obiectivele unitii

n aceast tem vei nva urmtoarele concepte fundamentale:

- definirea sistemului informatic;

- ciclul de via al unui sistem informatic.
U8.2. Definire
Din definiia sistemului informaional reiese c obiectivul global urmrit
este tratarea i valorificarea informaiei la toate nivelele sistemului n care se
creeaz i se dezvolt.
Metodele, mijloacele i tehnicile utilizate n realizarea obiectivului
caracterizeaz modul de prelucrare a datelor. Putem avea o prelucrare manual,
automat sau interactiv.
Dei la nceput calculatoarele electronice erau folosite n exclusivitate
pentru calcule tehnico-tiinifice, ncepnd cu cel de-al aptelea deceniu al
secolului nostru, acestea sunt utilizate pe o scar tot mai larg pentru prelucrarea
automat a datelor referitoare la procesele i fenomenele economice, la rezolvarea
pe cale automat a unor probleme generate n procesul decizional.
Prelucrarea automat a datelor a aprut odat cu utilizarea calculatoarelor
electronice n realizarea proceselor informaionale.
3

Pentru definirea sistemului informatic prezentm un set de trei definiii

unanim acceptate, dar care pun accentul pe una sau alta dintre trsturi,
completndu-se reciproc:
1.

Atunci

cnd

sistemul

informaional

predomin

utilizarea

calculatoarelor electronice, se spune c el este un sistem informatic.

2. Un sistem informatic poate fi definit ca un ansamblu tehnicoorganizatoric de automatizare a culegerii i prelucrrii informaiilor destinate
desfurrii procesului de conducere, n scopul asigurrii unei eficiene ct mai
mari a activitii economico-sociale respective.
3. Partea component a sistemului informaional prin care se asigur, pe
baza folosirii tehnicii de calcul i n primul rnd a calculatoarelor electronice,
tratarea raional a datelor i a informaiei, cu eficien sporit, constituie un
sistem informatic.
n timp ce prima definiie pune accentul pe aspectul tehnic, adic pe
utilizarea calculatoarelor, cea de-a doua vizeaz aspectul de organizare i
raionalizare a circuitului informaiilor destinate conducerii.
Ultima definiie este cea care reunete cele dou aspecte subliniate de
primele definiii adugnd i relaia de incluziune a sistemului informatic n
sistemul informaional.
Sistemul informatic se asociaz obligatoriu unui sistem informaional i
este subordonat unui proces decizional. Prin tratarea datelor cu tehnica de calcul
sunt eliminate erorile de informare care se repercuteaz negativ asupra calitii
desfurrii activitilor.
Sistemul informatic, ca parte a sistemului informaional, trebuie structurat
ca sistem cibernetic cu dou bucle de reglaj. Bucla principal de reglaj reflect
principalele influene cu mediul nconjurtor: legturile cu bncile, cu beneficiarii,
etc. Bucla secundar este ca o bucl de autoreglaj care face fa n principal
perturbaiilor interne din sistem. Structura cibernetic cu dou bucle de reglaj a
sistemului informatic este necesar i suficient pentru ca sistemul s poat fi
folosit ca instrument al conducerii.
n condiiile unei orientri a activitii spre pia, strategia ntreprinderii
poate suferi modificri substaniale, n funcie de situaiile conjuncturale aprute.
Dac, n urma unor perturbaii de acest fel, conductorul reevalueaz decizia sa
primar (planul iniial), poate s preconizeze o form modificat a obiectivului
iniial. n acest caz, cnd pe parcursul realizrii deciziei, att forma iniial ct i
4

cea final s-au modificat, putem vorbi despre sistemul informatic ca despre un
sistem bivariant.
Sistemul informatic este format, n esen, din urmtoarele categorii de
elemente:
1. calculatoare electronice i alte echipamente;
2. metode i tehnici de tratare a datelor i a informaiei;
3. colecii organizate de date;
4. proceduri i programe de tratare a datelor;
5. cadre de specialitate.
n cadrul sistemelor informatice, calculatorul electronic devine un factor
de sprijinire a analizei i deciziei de maxim importan, prin rezolvarea
problemelor de optimizare, att la nivelul elaborrii programelor de activitate, ct
i pe parcursul executrii lor.
Un sistem informatic este conceput prin colaborarea dintre specialiti din
domenii conexe iar realizarea unui sistem informatic este un proces complex, de
durat i care necesit activiti specifice de analiz, proiectare, programare i
implementare.
Sistemul informaional trebuie s devin, prin introducerea sistemului
informatic, instrument de reglare i autoreglare a sistemului economic. Obiectivul
global urmrit este creterea fiabilitii sistemului economic studiat.
Din activitatea practic de realizare a sistemelor informatice se desprind
urmtoarele principii pentru realizarea sistemelor informatice.
1. Sistemul este pentru beneficiar, ceea ce implic:
- participarea permanent a beneficiarului n toate etapele de realizare a
sistemului;
- ntocmirea documentaiilor orientate ctre beneficiar ntr-un limbaj
accesibil acestuia;
- aprobarea de ctre beneficiar a tuturor propunerilor fcute n proiect;
- responsabilitatea viitorului utilizator pentru implementarea sistemului,
pentru corectitudinea datelor folosite i pentru pregtirea personalului necesar
exploatrii sistemului.
2. Problema cheie este cea a oamenilor nu a echipamentelor, i n special a
analitilor-proiectani de sisteme, specialiti care au o influen hotrtoare asupra
modului de realizare a sistemelor.

3. Sistemele informatice trebuiesc justificate din punct de vedere cantitativ

i calitativ, deoarece reprezint investiii importante.
4. Realizarea sistemului informatic este un proces iterativ, ceea ce
nseamn c nti trebuie stabilit numai cadrul general, detalierea fcndu-se apoi
treptat, n mai multe iteraii.
5. Cnd nu putem s planificm ceva nu putem s facem corect acel lucru,
principiu valabil nu numai n informatic. n virtutea acestui principiu trebuie
permanent urmrite i reactualizate planificrile iniiale pe msura realizrii
sistemului. De asemenea, trebuie acordat o deosebit atenie modului de
etapizare a lucrrilor i mrimii etapelor pe care vrem s le realizm.
6. Procedurile manuale sunt la fel de importante ca i programele, de
corecta lor proiectare depinznd durata de implementare i modul de funcionare a
sistemului.
7. Trecerea de la vechiul sistem la noul sistem este ea nsi un sistem i
de aceea trebuie tratat cu mare atenie. Proiectantul de sistem are de fapt n fa
trei sisteme: cel vechi, cel nou i cel care face trecerea de la vechiul mod de lucru
la cel nou.
8. Sistemul trebuie s aib o bun documentaie n toate etapele de
realizare.

U8.3. Ciclul de via al unui sistem informatic

Din cele prezentate anterior se constat c restructurarea unui sistem
informaional este un proces complex. Analistul de sistem trebuie s parcurg o
serie de etape i s rezolve o mulime de probleme.
Analiza de sistem nseamn cunoaterea sistemului, cunoatere care se
traduce printr-o reprezentare la nivel cerebral a sistemului n ansamblul su. De
fapt prin analiz s-a transpus realitatea mai nti ntr-un model cerebral pe care
analistul l va transforma i l va prezenta sub forma unui model matematic, grafic
etc.
Aceast activitate de percepere i reprezentare a realitii nu este de loc
uoar i presupune participarea activ a tuturor membrilor echipei de proiectare
dar i a beneficiarului sistemului ntr-un context uman, material i organizatoric,
propice realizrii sistemului.

Mediul de proiectare al unui sistem informatic const n unitatea

proceselor de dezvoltare, a metodelor de definire, descriere, abstractizare,
modificare, rafinare i documentare precum i modalitatea de automatizare a
aplicrii metodelor.
Cnd vorbim despre procesul de reorganizare a unui sistem informaional,
trebuie s descriem un model care s prevad ceea ce va aprea n procesul de
dezvoltare. Aceast etapizare va arta ce trebuie fcut, cum va fi realizat, cnd va
fi terminat i cine va folosi ceea ce s-a realizat.
Un bun model al procesului de prelucrare trebuie s respecte trei cerine
principale:
- trebuie s aib o mare putere descriptiv, putnd s descrie esenialul n
mod realist;
- trebuie s permit descrierea nsui a procesului de dezvoltare i a
modului de conducere a dezvoltrii procesului;
- trebuie de asemenea s acopere cazurile neprevzute i schimbrile
continue care intervin ntr-un astfel de proces.
n general, modelul trebuie s aib capacitatea de a putea descrie o mare
varietate de sisteme i de subsisteme ale acestora. Exist un mare numr de
modele care descriu procesul de realizare a unui sistem informatic denumite
generic modele ale ciclului de via.
8. 3. 1. Modelul WATERFALL (n cascad)
Este cel mai vechi i cel mai cunoscut model. A fost dezvoltat n perioada
anilor '60, caracteristica principal constnd n parcurgerea unor etape numite
faze (Figura 8.1.):
1. Analiza cerinelor. Definirea i analiza necesitilor utilizatorului.
2. Specificaia. Translaia cerinelor ntr-o descriere general a sistemului.
3. Proiectarea. Crearea unei abstractizri a sistemului n concordan cu
specificaiile anterioare.
4. Implementarea. Crearea sistemului care implementeaz ceea ce s-a
proiectat.
5. Testarea. Determin dac implementarea satisface cerinele.
6. Mentenan. Modificarea sistemului necesar pentru a fixa problemele
aprute. Ciclul de via se repet n cadrul acestei faze.
7

Figura 8.1. Modelul Waterfall

Se constat c fiecare faz constituie o trecere de la un nivel de
abstractizare ridicat (puine detalii) la un nivel mai sczut de abstractizare (mai
multe detalii). Cu toate c exist o bogat experien i tradiie n aplicarea cu
succes a modelului, exist unele probleme.
n primul rnd modelul nu este suficient de descriptiv n ceea ce privete
activitile care interfer prin toate fazele ciclului de via cum ar fi: conducerea
proiectului, asigurarea calitii, verificarea i validarea. Spre exemplu o eroare de
specificare poate s nu fie descoperit dect foarte trziu, i este extrem de greu de
revenit la faza la care s-a produs eroarea.
n al doilea rnd modelul a fost dezvoltat ntr-o perioad cnd sistemele de
mici dimensiuni i cu arhitectur compact erau dominante.
n ultimul rnd modelul nu se preteaz la transpunerea sa pe calculator. El
a fost dezvoltat ntr-o perioad cnd proiectarea asistat de calculator nu era deloc
neleas.

8. 3. 2. Modelul INCREMENTAL (RAPID-PROTOTYPING)

Acest model (al prototipizrii rapide) a fost creat pentru a acoperi

deficienele modelului WATERFALL cu care se aseamn din mai multe puncte
de vedere. Diferena principal const n introducerea conceptului de dezvoltare
incremental.
Dezvoltarea incremental const n crearea unor mici salturi de la vechea
variant de sistem la noua variant care conine un plus de funciuni. Produsul
final nu este vzut ca un sistem monolit livrabil integral la o singur dat, ci este
realizat i livrat dintr-o serie de etape succesive corespunztoare fiecrei iteraii.
Numai la sfrit sistemul este disponibil integral, dar pn atunci fiecare
increment poate lucra ca un sistem de sine stttor (Figura 8.2.).

Figura 8.2. Modelul incremental

Modelul

incremental

elimin

necesitatea

furnizrii

cerinelor,

specificaiilor generale i a celor detaliate naintea nceperii etapei de proiectare.

Aceste specificaii numite builds (baselined intermediate software products)
sunt n mod formal specificate la nceputul fiecrui increment. Acest lucru permite
posibilitatea schimbrii cerinelor prin adugarea lor n pasul urmtor.
i n acest model exist posibilitatea erorilor n formularea cerinelor dar
spre deosebire de modelul Waterfall acestea pot fi corectate de la un pas la altul pe
parcursul realizrii sistemului. n plus se poate simula funcionalitatea sistemului,
scopul su fiind furnizarea unor feed-back-uri rapide proiectanilor i

conductorilor fr o pierdere inutil de timp, eliminndu-se posibilitatea

construirii unui sistem greit.
Fiecare increment realizat n fiecare pas de dezvoltare al sistemului se
poate constitui ntr-un prototip al viitorului sistem. Fiecare acest prototip poate s
se regseasc sau nu n sistemul final dar regula general care trebuie urmrit
const n planificarea eliminrii acestor prototipuri.
Acest model reuete s integreze corect activitile care acoper tot ciclul
de via al sistemului, cum ar fi:
- coordonarea proiectului const n capacitatea de a controla versiunile
sistemului de elaborat, pentru ca acestea s fie n realitate incrementri ale
versiunii anterioare i nu nite modificri arbitrare i neautorizate. Numai acele
modificri care vor determina schimbri favorabile n dezvoltarea sistemului vor
fi aprobate;
- verificarea const n stabilirea n continuu a corespondenei ntre ce s-a
solicitat i ce s-a realizat;
- validarea, trebuie s aib n vedere c sistemul construit s nu prezinte
goluri i incoerene.
Dezvoltarea incremental este ca o sabie cu dou tiuri, pentru c
permind etapizarea sistemului n versiuni succesive, orice problem aprut i
nerezolvat la un moment dat implic suspendarea etapelor urmtoare.
Dezavantajul implicat de aceast situaie este totui mult mai mic, dect
necazul produs de descoperirea erorii numai la finalizarea sistemului.
Un alt avantaj const n posibilitatea dezvoltrii simultane a mai multor
sisteme, fiecare n diferite stadii ale ciclului de via. Aceasta mrete capacitatea
conducerii de a acoperii un domeniu mai vast putndu-se aloca mai bine resursele,
dar trebuie inut cont c pot aprea situaii n care este greu de estimat necesarul
de resurse mai ales n situaiile neprevzute aprute n diferiii pai de dezvoltare
ai sistemelor coordonate.
8. 3. 3. Modelul ciclului de concepie n V
Dezvoltarea unui sistem urmrind abordrile anterioare poate fi
descompus ntr-o succesiune de faze: specificaii, concepie, programare i
mentenan dup unii autori sau, analiz preliminar, proiectare logic, proiectare

10

tehnic, programare, implementare, exploatare i ntreinere, dup alii (variante

ale modelului Waterfall).

Figura 8.3. Ciclul de concepie n V

Pentru evidenierea faptului c anumite faze ale ciclului de via sunt
condiionate de faze anterioare s-a propus reprezentarea ciclului de via al unui
sistem informatic ca un ciclu de concepie n V (Figura 8.3.). Se observ c
etapele din braul descendent sunt validate de cele situate pe braul ascendent.
Astfel, concepia arhitecturii aplicaiei va trebui s rspund testelor de
funcionare a componentelor luate fiecare n parte dar i n ansamblu.
Aceast schem pune clar n eviden principalul inconvenient al
abordrilor clasice. Nu se poate valida analiza fcut la nceputul proiectului dect
atunci cnd toate activitile de programare, testare i integrare sunt terminate.
8. 3. 4. Modelul OPERAIONAL
Acest model pornete de la o alt abordare dect modelele anterioare i
anume prin concentrarea efortului de definire asupra aspectului operaional.
Mecanismul implementrii nu este ascuns ci st la baza specificaiilor de definire.
Cu alte cuvinte, modelul operaional creeaz specificaii executabile (numite i
specificaii operaionale) care sunt ulterior transformate ntr-o eficient
11

implementare. Astfel comportamentul extern al sistemului exist implicit n cadrul

specificaiilor n timp ce structura intern nu.
n acest tip de model proiectarea se refer direct la condiiile de mediu n
timp ce celelalte modele pun accentul pe separarea cerinelor (comportamentul
extern) de structura intern a sistemului.
Prin realizarea legturii ntre specificaiile operaionale i structura intern
a sistemului, se constat c modelul operaional este orientat pe problem spre
deosebire de celelalte modele care sunt orientate pe implementare.
Analiza
problemei

Specificaii
operaionale

Specificaii

Specificaii
transformate

Transformare

Soluia
sistemului
Realizare

Figura 8.4. Modelul operaional

Unul dintre avantajele modelului operaional este marea sa putere
descriptiv orientat direct spre rezolvarea problemei. Spre deosebire de modelul
incremental care pornete de la o descriere liber a specificaiilor de definire,
modelul operaional are descrieri formale, riguroase i care pot fi uor analizate.
Acest fapt i permite s poat foarte uor s fie transpus pe calculator.
Ca dezavantaje se constat contradicia dintre necesitatea transformrii
cerinelor externe ntr-o structur intern nainte ca aceasta s fi fost definit.
Deoarece modelul nu este prea rspndit evaluarea posibilitilor sale este dificil
de fcut mai ales pentru sisteme de mari dimensiuni. El este n schimb mai folosit
pentru realizarea sistemelor mici.
Din parcurgerea sumar a acestor modele se observ c modelul Waterfall
este un model atractiv care se bazeaz pe o lung perioad de aplicare, fapt care i
confer avantajul numeroaselor experimentri n situaii dintre cele mai diferite.
Modelul Incrememtal include n ciclul de via activiti de conducere i
dezvoltare prin pai succesivi, realiznd un feed-back rapid ntre proiectani i
utilizatori.
Modelul de concepie n V pune n eviden faptul c o faz o valideaz
pe precedenta (similar modelului Waterfall) dar i faptul c numai fazele
terminale realizeaz adevrata validare a etapelor de nceput.
Modelul Operaional realizeaz specificaii executabile, mrete rolul
automatizrii i stabilete o strns legtur ntre specificaii i implementare.
12

Cu toate acestea se constat c un model perfect bazat pe ciclul de via al

sistemului informatic nu se poate realiza, mai ales datorit unor condiii
subiective. Adesea un proiect trebuie nceput de la dorinele unui viitor utilizator
care are o vag idee despre ceea ce va trebui s se realizeze, i numai dup ce
sistemul s-a realizat aproape integral se hotrte c nu este de fapt ceea ce a dorit.
Este extrem de greu de modelat aceast situaie: Nu tiu ceea ce vreau dar tiu
ceea ce nu doresc. Practica ne-a demonstrat c folosirea unui model imperfect i
incomplet este totui mult mai util dect renunarea la orice fel de model.
Dar modelul nu este totul. Avem nevoie de un set de prescripii pentru
desfurarea activitilor cerute de etapele unui model bazat pe ciclul de via,
prescripii utilizate pentru proiectarea sistemului. Am definit prin aceast metod
de proiectare. Metoda de proiectare are o dubl responsabilitate:
- de a crea produsul;
- de a implementa o parte din modelul ciclului de via.
ncercarea de a gsi cea mai bun metod de realizare a sistemelor
informatice este un subiect de cercetare deosebit de important. Problema cu cele
mai multe metode este c ele au att reguli implicite ct i explicite. Regulile
explicite sunt prezentate de obicei n documentaia de realizare dar cele implicite
nu sunt prezentate nicieri.
Cnd se realizeaz un sistem informatic apar o multitudine de probleme i
este aproape imposibil s se repete procesul original pentru crearea unui alt
sistem. Metoda nu furnizeaz numai paii care trebuie parcuri ci precizeaz i ce
decizii trebuiesc luate n paii respectivi. Este foarte important, n acest caz, ca la
livrarea proiectului s se furnizeze i metoda dup care a fost realizat.
Ultimul aspect care trebuie abordat este automatizarea metodei de
proiectare. Acest termen este preferat termenului de instrumente de dezvoltare
(software tools), care vizeaz punctual o anumit operaie. Automatizare nseamn
un suport pentru o metoda i este o parte integrat n procesul de dezvoltare a
sistemului informatic. Dar soluionarea cu succes a problematicii const n
integrarea coerent a metodelor folosite ntr-o metodologie, i nu n automatizarea
lor.
Automatizarea are o mulime de avantaje. Cel mai important const n
reducerea muncii n aplicarea metodelor, i ntr-un anume fel este cea mai realist
manier de aplicare a metodelor. Aspectul birocratic al celor mai multe metode

13

presupune pstrarea unei cantiti mari de informaii care este imposibil de

gestionat manual pentru sisteme de o anumit mrime.
Automatizarea implic o scdere a costurilor de dezvoltare i planificare
rezultnd o cretere calitativ a activitii creative deoarece proiectanii i
conductorii proiectului sunt degrevai de aspectele de rutin. De cele mai multe
ori automatizarea faciliteaz nvarea i comunicarea ntre membrii proiectului.

14

MODULUL 3
UNITATEA 9: Metoda MERISE Prezentare
UNITATEA 10: Metoda MERISE Ciclul de via
UNITATEA 11: Metoda MERISE Ciclul de abstractizare
UNITATEA 12: Metoda MERISE Ciclul de decizie

15

UNITATEA 9
METODA MERISE - PREZENTARE

Durata medie de studiu individual - 2 ore

Cuprins:

pag.

U9.1. Scopul i obiectivele unitii .............................................................

U9.2. Prezentare metoda Merise ................................................................
U9.3. Test de autoevaluare .........................................................................
U9.4. Rezumat .............................................................................................
Bibliografie minimal .................................................................................
Rspunsuri i comentarii la testul de autoevaluare .................................

104
104
111
112
113
113

U9.1. Scopul i obiectivele unitii

n aceast tem vei nva urmtoarele concepte fundamentale:
- metoda MERISE;
- tipuri de metode - metode tradiionale i metode orientate obiect
- nivel conceptual, organizaional i operaional.

U9.2. Prezentare metoda MERISE

Evoluia tehnologic presupune o anumit infrastructur care trebuie s
cuprind pe lng hardware, produse i sisteme informatice bazate pe noi sisteme
de gestiune a bazelor de date sau pe noiunea de teletransmisie materializat prin
reele naionale de date cu rate de transfer ct mai mari; posturi de lucru la toate
nivelele operaionale dintr-o unitate (sisteme interactive ommain).
Mediile economice trebuie s se adapteze rapid la aceste tehnologii care
presupun costuri relativ ridicate ocazionate de elaborarea i ntreinerea produsului
informatic, dar i dificultilor crescnde de meninere la anumite standarde a
nevoilor utilizatorilor.
Necesitatea adaptrii devine stringent n mediul financiarcontabil care
privete schimbrile ntr-un orizont de timp ca pe o protecie a investiiei.

16

Continua dezvoltare a domeniului tehnologiei informaiei impune

elaborarea de noi metodologii pentru realizarea sistemelor de aplicaii informatice,
cristalizndu-se n analiz i proiectare dou tipuri de metode utilizate:
tradiionale (structurate, orientate pe funcii/date, metode sistemice) i metode
orientate obiect.
Aportul fiecrei metode concretizat printr-un limbaj comun utilizator
informatician este manifestat pe parcursul ntregului proces de studiu prin apariia
i existena punctelor de validare.
Metoda, produs al reflexiei permanente, constituie un demers raional i
empiric, deductiv i inductiv. Conform unor specialiti, metoda reprezint un
ansamblu de mijloace industriale puse n practic pentru organizarea unei
fabricaii sau un ansamblu de reguli, principii normative care corespund
nvmntului, practicii i artei. Ea se aplic tuturor conceptelor create de
tehnologie, care observ i analizeaz practica cotidian din organizaii.
Retrospectiv se constat c evoluia tehnologiei informatice 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 activitii de producie
software, m conduc la ideea c n informatic o metod universal nu este
posibil.
Orice metod de concepie a unui sistem informatic trebuie s ia n
considerare factorii de natur tehnic i socio-economic. n domeniul tehnic
trebuie s permit derularea activitilor 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 ageni care urmresc descentralizarea deciziilor operative;
simplificarea sarcinilor i ameliorarea ergonomiei postului de lucru; securitate i
confidenialitate; dezvoltarea proceselor de gestiune prin creterea posibilitii de
supervizare la diverse nivele; suplee tehnic i comercial sau structural strict
necesar n situaii de fuziune, extindere.
Metoda vizeaz asocierea eficient a aspectelor organizaionale i
informatice; creterea calitii relaiilor utilizatoriinformaticieni, reprezentnd un
mijloc comun de studiu, concepie, dialog, formalizare a deciziilor i de control
17

preventiv. Cu alte cuvinte, metoda n cadrul unui organism economic trebuie s

fie un mijloc precis, eficace, suplu dar nu rigid.
Apariia metodei MERISE (Methode dEtude et Realisation Informatique
par le Sous Ensemble representatif) marcheaz o dat important n istoria
prelucrrii informaiilor. Aceast apariie rezult pe de o parte din contextul
generalizrii prelucrrilor conversaionale, consecin a salturilor tehnologice din
anii '70, i pe de alt parte, rezult n urma numeroaselor lucrri asupra bazelor de
date i asupra abordrii sistemice.
MERISE s-a nscut n Frana n jurul anilor 1978-1979 ca urmare a unei
vaste consultri lansate de ctre Ministerul Industriilor cu scopul de a realiza o
metod modern de concepere i realizare a sistemelor informatice.
ntre 1986 i 1989 metoda MERISE s-a impus cu adevrat devenind un
standard cu un numr de utilizatori n continu cretere att n domeniul public ct
i n cel privat. Statisticile publicate n Frana n 1990 au confirmat aceast
evoluie deoarece dintre ntreprinderile mari i mijlocii care foloseau o metoda de
analiz-proiectare, 60% aleseser deja MERISE.
MERISE acumuleaz continuu i completeaz cmpul su de aplicabilitate
integrnd noi extensii. Patru sunt direciile principale de evoluie:
- integrarea arhitecturilor client/server;
- o mai buna poziionare n raport cu metodele anglo-saxone;
- o abordare orientat pe obiecte;
- dezvoltarea unui mediu metodologic european concretizat astzi prin
proiectul EUROMETHODE.
Consftuirea cu tema MERISE et les autres desfurat la Versailles
ntre 5 i 7 octombrie 1994 a avut ca subtitlu Ce sisteme informatice pentru o
lume n schimbare? i i-a propus dezbaterea poziiei acestei metode n raport cu
alte abordri metodologice.
MERISE are numeroi adepi care o utilizeaz cu pasiune, dar i opozani
care o consider o metod greoaie. Dac anumite proiecte sunt uneori nereuite
aceasta este din cauza unei folosiri inadecvate a metodei. Folosirea metodei
MERISE implic o investiie personal care presupune o mare rigoare i folosirea
unor tehnici complexe. Aceast investiie personal nu a fost fcut, uneori, n
cele mai bune condiii i n aceast situaie, pentru anumii conductori de
proiecte, metoda pare greoaie.

18

Pentru a reui, un proiect MERISE trebuie s aib obligatoriu adeziunea i

participarea utilizatorilor.
Metoda

presupune

construirea

de

modele

la

nivel

conceptual,

organizaional i operaional furniznd astfel legturile existente n sistemele

informaionale (Figura 9.1.).
REALITATEA
Abstractizare
Nivelul
conceptual

MCD

MCP
Se introduc noiuni
legate de organizare

Nivelul
organizaional

MLD

MOP

Se introduc soluiile
tehnice de realizare

Nivelul
operaional

MFD

MOpP

Figura 9.1. Nivelele metodei Merise

NIVELUL CONCEPTUAL const n analiza sistemului informaional n
termenii obiectivelor, fr a ine cont de nici un concept legat de organizare (ce
trebuie fcut i cu ce date?).
Trebuie studiate separat n plan conceptual, pe de o parte datele i
organizarea lor i pe de alt parte prelucrrile.
n termeni de organizare a datelor se face apel la formalismul entitaterelaie i aceasta se traduce prin entiti de baza i relaii ntre aceste entiti. La
acest nivel, cu ajutorul unei grafici adecvate se constituie modelul conceptual al
datelor (MCD), care permite o descriere static a sistemului informaional cu
ajutorul conceptelor de entitate i asociaie.
19

MCD permite reprezentarea datelor din realitatea nconjurtoare

independent de opiunile tehnice, pentru a uura gndirea n timpul activitii de
concepie.
n termeni de organizare a prelucrrilor aceste entiti vor fi descrise prin
prelucrrile pentru care ele sunt cauze i consecine. Aceast etap are ca scop
definirea operaiilor principale care trebuie efectuate n domeniul studiat. Se va
stabili o diagram de flux (modelul conceptual al comunicaiilor MCC) care
permite descrierea informaiilor schimbate global n sistem prin intermediul
actorilor i fluxurilor.
Pornind de la aceast diagram, se va trece spre modelul conceptual al
prelucrrilor (MCP). Rezultatul su final se va concretiza sub form schematic
ntr-un model eveniment-operaie-rezultat care va trebui s rspund la
ntrebrile: ce trebuie fcut n interiorul sistemului informaional, sub impulsul
cror evenimente i ce rezultate se obin?
NIVELUL ORGANIZAIONAL const n integrarea n analiz a
criteriilor legate de organizare. Dup ce nivelul conceptual a exprimat realitatea
perceput n ansamblul su, nivelul organizaional exprim aceast realitate aa
cum este ea trit de actorii participani, indiferent care ar fi acetia. La acest nivel
nu se face nici o distincie ntre oameni i maini. La nivelul datelor este necesar
orientarea ctre o clas de soluii, i apare modelul logic al datelor (MLD) care
este o transcriere a modelului conceptual al datelor. Are loc, n privina datelor, o
transformare a lor dar nu o mbogire a lor. Nivelul conceptual al datelor este o
descriere complet a sistemului. Date noi pot fi create la nivele inferioare (crearea
unei redundane n vederea minimizrii numrului de accesri la una din entiti)
dar n nici un caz nu se pot crea informaii noi.
Situaia este diferit la nivelul prelucrrilor. Trecerea de la nivelul
conceptual (MCP) la nivelul organizaional (MOP) se concretizeaz prin ataarea
evenimentelor definite anterior, actorilor. n aceste proceduri globale vor apare
ntotdeauna actori care au n plus noiunea de restricie temporal i
organizatoric. La nivelul prelucrrilor evenimentele descrise au mai ales o
dominant spaial dect una temporal i se completeaz nivelul conceptual
rspunznd la ntrebrile cine? i unde?.
NIVELUL OPERAIONAL este o reprezentare a mijloacelor care vor fi
efectiv folosite pentru a gestiona datele i prelucrrile i const n furnizarea
soluiilor tehnice rspunznd la ntrebarea cum?.
20

La nivelul datelor se va trece de la o clas de soluii la una singur.

Aceasta se concretizeaz prin utilizarea unui anumit SGBD. Se face o alegere
privind metodele de stocare i de acces la informaii. Se construiete la acest nivel
modelul fizic al datelor (MFD) care este transformarea modelului logic al datelor
(MLD) prin echivalarea noiunilor de tablou i coloane cu noiunile de relaie i
atribute din modelul logic al datelor.
La nivelul prelucrrilor se procedeaz la mprirea proiectului n
programe. Modelul operaional va descrie arhitectura programelor care vor
executa anumite funcii, dar n nici un caz la acest nivel nu va exista o activitate
de programare efectiv.
Fiecare din aceste nivele are ca obiectiv principal furnizarea unui anumit
numr de documente care s permit sinteza procesului de gndire. Aceste
documente, indispensabile elaborrii, sunt legate de cele rezultate din analiza
datelor.
Punerea n aplicare a modelelor de prelucrare la orice nivel, conceptual,
organizaional sau operaional are nu numai scopul de a defini prelucrrile de
efectuat dar i opiunile alese n elaborarea modelelor datelor.
Abordarea analizei cu ajutorul metodei MERISE se face dup trei axe
constituind ceea ce numim cele trei cicluri (Figura 9.2.). Analistul trebuie s
parcurg toate cele trei cicluri pe parcursul realizrii sistemului. Aceste trei cicluri
se desfoar simultan.
1. Ciclul de abstractizare este realizat prin formalismul celor trei nivele
conceptual, organizaional i operaional i se va aplica asupra prelucrrilor i
datelor.
2. Ciclul de via presupune trei mari etape:
- concepia sau perioada studiului sistemului existent i apoi a noului
sistem;
- realizarea care acoper proiectarea i exploatarea sistemului;
- ntreinerea care va permite sistemului s evolueze i s se adapteze
modificrilor de mediu i noilor obiective pn n momentul n care nu va mai fi
capabil de adaptare i va fi nlocuit cu un nou sistem.
3. Ciclul de decizie care cuprinde toate deciziile luate pe parcursul
desfurrii proiectului, mai generale la nceput i apoi din ce n ce mai precise.

21

Figura 9.2. Cele trei cicluri ale metodei Merise

Aceste noiuni sumar prezentate se adreseaz att utilizatorilor (cei care
solicit serviciile) ct i informaticienilor (furnizorii de prestaii). Eficacitatea i
validitatea unei analize const n calitatea comunicaiei dintre beneficiar i
proiectant iar calitatea comunicaiei este obinut, n parte, graie utilizrii corecte
a unei metode de analiz.
MERISE separ studiul datelor de cel al prelucrrilor, dei acestea dou se
pot realiza n paralel.
MERISE are dou obiective principale:
1) reprezint o metod de concepie a SI;
2) propune o metodologie de dezvoltare a SI.
Avantajele metodei MERISE ca metod de concepie a SI sunt:
apropierea de sistemul informatic i de structura ideal a BD;
descrierea SI pe trei niveluri;
utilizarea unui formalism de reprezentare precis, simplu i riguros pentru
descrierea datelor. (Formalism, n sensul de mai sus, nseamn un set de definiii
i reguli, combinat cu un set de tipuri de diagrame i/sau de tabele.) Acest
formalism este reglementat pe plan internaional de standardul ISO sub numele de
ENTITATE-ASOCIERE;
descrierea amnunit la nivel conceptual, permind realizarea unui SI
independent de organizarea firmei i alegerea tehnicii de automatizare;

22

reprezentarea vizual folosit n modelul conceptual duce la uureaz

stabilirea unui dialog ntre toi partenerii implicai n realizarea SI.
Varianta a doua a metodei MERISE surprinde evoluiile tehnice i
organizaionale ale anilor 90 i nltur cteva carene ale modelului entitateasociere utilizat n prima versiune. Astfel, se introduc noiunile de generalizare i
specializare pentru a explica conceptele de motenire, regulile de integritate i
pentru noiunea de identificator relativ (ce permite identificarea unei entiti n
raport cu alt entitate).
n versiunea a doua a metodei MERISE modelul conceptual al
prelucrrilor (MCP) conine, n plus:

o diagram a fluxului de date (DFD);

un model analitic conceptual al prelucrrilor care acioneaz nc din

faza de concepie;

noiunea de ciclu de via al unui obiect surprinde toate etapele

parcurse de un obiect n cursul existenei sale, n funcie de evenimentele produse

i de evenimentele care urmeaz a se produce;
La nivelul organizaional sunt surprinse n structur toate resursele
materiale i umane implicate n realizarea SI. La nivel logic sunt definite
interfeele cu utilizatorii, resursele logice ale prelucrrilor, precum i depozitarea
i repartiia datelor, nivelul fizic rmnnd neschimbat.

UNITATEA 10
METODA MERISE CICLUL DE VIA

Durata medie de studiu individual - 3 ore

Cuprins:

pag.

U10.1. Scopul i obiectivele unitii ...........................................................

U10.2. Elaborarea temei de realizare a sistemului informatic ................
U10.3. Proiectarea logic (elaborarea concepiei sistemului informatic)
U10.4. Proiectarea tehnic ..........................................................................
U10.5. Elaborarea programelor .................................................................
23

114
114
124
138
146

U10.6. Implementarea, exploatarea i ntreinerea ..................................

U10.7. Test de autoevaluare .......................................................................
U10.8. Rezumat ...........................................................................................
Bibliografie minimal .................................................................................
Rspunsuri i comentarii la testul de autoevaluare .................................

156
157
158
159
159

U10.1. Scopul i obiectivele unitii

n aceast tem vei nva urmtoarele concepte fundamentale:
- elaborarea temei de realizare a sistemului informatic;
- proiectarea logic;
- proiectarea tehnic;
- elaborarea programelor;
- implementarea, exploatarea i ntreinerea programelor.

U10.2. Elaborarea temei de realizare a sistemului informatic

n aceast etap iniial se examineaz posibilitatea realizrii unui nou
sistem informatic, sau modificrii sistemului existent. Stimulul declanator al
acestei etape trebuie s fie de regul viitorul beneficiar.
Principala activitate n acest stadiu este cunoaterea general a problemei
i a obiectivelor care trebuie realizate, la un nivel care s permit s se stabileasc
dac este sau nu necesar s se treac la etapa urmtoare.
Elaborarea temei de realizare este etapa prin care se cunoate situaia
actual, se furnizeaz un diagnostic i se caut soluiile posibile. n aceast etap
trebuie elaborat o soluie independent de mijloacele de realizare.
Rezultatele acestei etape constau n caietul de sarcini i specificaiile
funcionale generale.
De obicei aceast etap, frecvent denumit i studiu de oportunitate sau
analiz preliminar implic timp i efort relativ redus, doar din partea unor
specialiti cu experien i care au mai ntocmit lucrri similare.
Obiectivul

principal

al acestei

etape este formularea

cerinelor

informaionale ale sistemului de conducere. Activitile din cadrul acestei etape

sunt:
- studiul sistemului existent;
- evaluarea sistemului existent;
24

- evaluarea gradului de pregtire a ntreprinderii;

- formularea cerinelor i a restriciilor pentru realizarea sistemului
informatic.
n cadrul acestei ultime activiti, cea mai important din prima etap
intr:
- definirea obiectivelor i performanelor noului sistem;
- stabilirea domeniului i funciunilor noului sistem informatic;
- definirea cerinelor i restriciilor informaionale pe probleme i
funciuni;
- estimarea resurselor disponibile pentru proiectarea, implementarea i
exploatarea noului sistem.
n realizarea etapizat a sistemului informatic trebuie, n primul rnd,
cunoscut sistemul existent. Echipa de proiectare trebuie s aib ca punct de
plecare un tablou de probleme elaborat mpreun cu conducerea ntreprinderii. Pe
baza acestuia se trece la studiul sistemului prin care se urmrete definirea
caracteristicilor generale i analiza activitilor desfurate.
De asemenea, studiul sistemului presupune i analiza modului n care
sistemul informaional asigur legturile ntre sistemul conductor i sistemul
condus.
Pe baza concluziilor rezultate din studiul sistemului, se evalueaz critic
sistemul informaional i se formuleaz cerinele i restriciile pentru realizarea
sistemului informatic.
Printre tehnicile i metodele de analiza a sistemului existent se numr:
1. Tehnica documentrii;
2. Metoda analizei-diagnostic;
3. Metoda diagramelor de flux informaional;
4. Metoda evidenei economice ;
5. Metoda anchetelor;
6. Metoda scenariilor.
10. 2. 1. Tehnica documentrii
Prin tehnica documentrii se urmrete culegerea i prelucrarea
informaiilor cu caracter teoretic i practic privind sistemul studiat.

25

Pentru atingerea acestui obiectiv, documentarea trebuie s se desfoare

ntr-o ordine logic folosind ca instrument principal de lucru documentele care
reglementeaz existena i funcionarea sistemului respectiv. Astfel de documente
sunt: organigrama, regulamentul de organizare i funcionare, alte acte normative.
Prin organigram sunt reprezentate grafic gruparea compartimentelor de munc
dup criterii funcionale, subordonarea acestora, repartizarea lor i legturile
dintre compartimente. n acest mod organigrama vizualizeaz natura i poziia
fiecrui

compartiment.

Ea

reflect

obiectivele

sistemului

economic,

responsabilitile, delegrile de autoritate i legturile funcionale. Informaiile cu

caracter general obinute prin analiza organigramei pot fi completate prin studiul
regulamentului de organizare i funcionare a sistemului. Aspecte de detaliu
asupra modului de desfurare a activitilor sunt completate prin parcurgerea
actelor normative care reglementeaz prestarea lor.
Analiza situaiei existente este completat prin documentarea asupra unor
studii i proiecte informatice elaborate n alte ntreprinderi cu profil apropiat.
Rezultatele documentrii urmeaz a fi sistematizate i sintetizate pe
domenii de probleme care apar n tabloul ntocmit pe baza comenzii
beneficiarului.
10. 2. 2. Metoda analizei-diagnostic
Aceast metod i propune s furnizeze informaii asupra sistemului
existent. Analiza-diagnostic este o metod colectiv de lucru aplicat de echipa de
proiectare. Diagnosticul const n relevarea anomaliilor manifestate n organizarea
i funcionarea sistemului i n stabilirea remediilor corespunztoare. Prin
cercetarea activitilor desfurate se stabilesc direciile de dezvoltare pentru
sistemul existent. Obiectivele analizei-diagnostic sunt:
Realizarea unui sistem de organizare i conducere perfecionat flexibil la
modificrile care apar. Prin analiza-diagnostic urmeaz s se stabileasc n ce
msur structura organizatoric satisface necesitile conducerii i posibilitile de
cretere a fiabilitii sistemului prin tratarea automat a datelor.
Prevenirea factorilor perturbatorii care genereaz efecte negative asupra
sistemului economic sub aspect structural, funcional i al nivelului de
performan.

26

 Identificarea cilor de restabilire a echilibrului, de compensare sau

eliminare a factorilor perturbatorii. Acest obiectiv, cumulat cu cel precedent, poate
fi ndeplinit prin abordarea global a ntreprinderii privit ca sistem dinamic,
nchis i adaptabil.
Concluziile analizei-diagnostic stau la baza analizei critice a sistemului
existent i sunt ghidul necesar realizrii sistemului informatic.
Realizarea presupune luarea n considerare a urmtoarelor aspecte:
- strategia de dezvoltare a ntreprinderii;
- condiiile de materializare pe baza resurselor disponibile;
- prioriti care se impun n funcie de condiii.
n aplicarea metodei se recomand parcurgerea urmtoarelor etape de
lucru:
- culegerea informaiilor privind organizarea i funcionarea sistemului
existent;
- formularea obiectivelor, care se realizeaz prin conturarea elurilor
urmrite i a modalitilor de realizare;
- enunarea instruciunilor privind desfurarea aciunilor;
- realizarea practic a instruciunilor;
- analiza informaiilor culese i evaluarea rezultatelor.
Dac soluiile rezultate nu sunt edificatoare asupra obiectivelor urmrite
atunci analiza diagnostic se reia. Concluziile analizei-diagnostic, corelate cu
rezultatele documentrii, constituie baza cunoaterii sistemului i a posibilitilor
de perfecionare.

10. 2. 3. Metoda diagramelor de flux informaional

Identificarea caracteristicilor sistemului de conducere necesit detalierea
analizei sistemului informaional. n acest scop se apeleaz la metoda diagramelor
de flux a documentelor i a momentelor lor de completare urmrind raionalizarea
sistemului informaional i ameliorarea funcionrii acestuia.
Diagramele de flux informaional dau o descriere sistemic a unui proces
sau a unui ciclu de munc cu suficiente detalii, care odat analizate pot duce la o
mbuntire a activitii respective.

27

Fiecare element component al diagramei este astfel reprezentat nct s

ajute pe analist s-i formeze o imagine clar asupra sistemului studiat.
Majoritatea diagramelor combin reprezentarea scris cu cea grafic i
figurativ pentru a se asigura participarea deplin a tuturor persoanelor interesate.
Schemele sunt instrumente excelente n prezentarea propunerilor de
ameliorare a metodelor de munc la toate nivelurile de conducere.
10. 2. 4. Metoda evidenei economice
Evidena economic reprezint un ansamblu de procedee i tehnici de
urmrire a fenomenelor i proceselor care au avu loc n domeniul vieii
economice. Prin coninut evidena economic este componenta major a
sistemului informaional economic. Orice operaie de flux real al valorilor
materiale i bneti trebuie s se gseasc consemnat n documentele de eviden
economic.
Dup procedeele i tehnicile folosite n investigarea realitii economice
evidena economic se constituie n trei forme distincte:
a) evidena tehnico-operativ;
b) evidena contabil;
c) evidena statistic.
a) Evidena tehnico-operativ const n consemnarea i centralizarea
datelor privind procesele i fenomenele economice la locul i n momentul
producerii lor. Evidena tehnico-operativ furnizeaz informaii necesare
conducerii operative.
b) Evidena contabil sau contabilitatea urmrete formarea existena i
folosirea mijloacelor economice i a surselor lor de formare. Prin coninut
contabilitatea este cea mai important component a evidenei economice. Ea
asigur continuitatea circuitului informaional ntre evidena tehnico-operativ i
cea statistic i este principala surs de informaii a conducerii tactice i strategice.
c) Evidena statistic sau statistica oglindete i caracterizeaz procesele
n ansamblul lor prin studierea unor fenomene social-economice de mas. Cu
ajutorul statisticii se poate studia evoluia unor fenomene n perioadele anterioare
pentru a determina evoluia lor viitoare.

28

10. 2. 5. Metoda anchetelor

Prin aceast metod se culeg informaii cantitative i calitative pe domenii
i probleme fiind o metod de investigare analitic. Pentru ca investigarea s duc
la rezultate concludente, n aplicarea tehnicilor este necesar s se aib n vedere
urmtoarele principii:
- selectarea persoanelor de interogat avnd n vedere poziia lor n sistem
i competena lor profesional;
- antrenarea subiecilor alei la emiterea de idei noi privind modul de
desfurare a activitilor;
- acceptare ideilor emise fr o judecat imediat a valorii lor;
- stimularea gndirii participanilor prin formularea de ntrebri adecvate;
- verificarea rezultatelor prin mbinarea modului de aplicare al tehnicilor.
Respectarea

acestor

principii

asigur

luarea

considerare

comportamentului subiecilor investigai, i n consecin, culegerea de informaii

critice asupra strii i funcionrii sistemului.
Metoda anchetelor se constituie dintr-un complex de tehnici cu caracter
interogativ cum sunt:
A) tehnica chestionarului;
B) tehnica interviului;
C) tehnica observrii directe.
A. Tehnica chestionarului presupune utilizarea chestionarului ca
instrument de culegere a informaiilor referitoare la obiectivele analizei.
ntocmirea chestionarului cuprinde trei faze distincte:
1. Faza pregtitoare, n care se delimiteaz cu exactitate obiectivele
chestionrii.
Astfel de obiective pot fi:
a) analiza activitilor de baz;
b) principali indicatori economici folosii;
c) identificarea caracteristicilor sistemului de conducere;
d) identificarea metodelor i tehnicilor folosite n prelucrarea datelor.
n aceast faz este necesar s se indice gradul de detaliere a informaiilor
i modul de prelucrare ulterioar.
2. Faza de ntocmire a chestionarului.

29

n funcie de obiective i subiecii ce urmeaz a fi supui chestionrii, se

stabilesc numrul i tipul de ntrebri. Numrul mediu de ntrebri ntr-un
chestionar trebuie s fie cuprins ntre 15 i 20. Un numr prea mic de ntrebri nu
poate furniza informaiile dorite i nu justific efortul fcut pentru organizarea
chestionarului, iar un numr prea mare de ntrebri obosete subiectul chestionat
ceea ce duce la emiterea de rspunsuri pripite, neconcludente pentru analiza de
sistem.
Activarea subiecilor se poate asigura prin folosirea mai multor tipuri de
ntrebri, cum sunt:
- ntrebri nchise, cu un numr redus de rspunsuri precodificate prin care
subiecii se pronun asupra unor informaii culese prin alte metode i tehnici;
- ntrebri factuale asupra unor fapte obiective, de verificare a
aptitudinilor, de identificare a unei stri de fapt, de clarificare a unor aspecte ale
analizei;
- ntrebri deschise la care numrul rspunsurilor poate varia de la un
subiect la altul.
Dup locul ocupat n chestionar, ntrebrile se grupeaz astfel:
- introductive, n problema analizat;
- de filtru prin care se precizeaz condiionarea ntre ntrebri;
- de bifurcare prin care se identific numrul ntrebrilor la care se va
rspunde n continuare dac s-a rspuns afirmativ la ntrebarea anterioar i
numrul ntrebrilor nlnuite n cazul n care rspunsul anterior a fost negativ;
- de motivare a unor rspunsuri;
- de control a exactitii rspunsurilor i de identificare a subiectului
chestionat.
Pentru ca formularea ntrebrilor s fie corect i corespunztoare
realizrii obiectivelor, la aceast aciune trebuie s participe, pe lng
informaticieni sociologi, psihologi, statisticieni.
3. Faza de verificare a chestionarului.
Prin testri se urmrete modul n care rezultatele chestionrii concord cu
obiectivele investigaiei. n funcie de constatrile faptice, se corecteaz
formularea ntrebrilor i ordinea lor n chestionar. n ntocmirea i completarea
chestionarului este recomandat respectarea urmtoarelor reguli:
- formularea simpl, clar, concis i explicit a ntrebrilor;

30

- asigurarea libertii subiecilor de a completa sau nu chestionarul printr-o

ntrebare introductiv;
- evitarea formulrii de ntrebri tendenioase, ipotetice, prezumtive,
insuficient de clare;
- asigurarea unei succesiuni logice a ntrebrilor;
- schimbarea ordinii rspunsurilor precodificate n formulare pentru a se
elimina tendina de alegere a primului rspuns;
- includerea n chestionar a unor ntrebri de control prin care s se asigure
veridicitatea rspunsurilor.
Completarea chestionarului de un numr reprezentativ de subieci, asigur
obinerea de informaii relevante pentru analiza sistemului.
B. Tehnica interviului
Prin aceast tehnic se urmrete obinerea ntr-un interval de timp redus,
de informaii privind orientrile practice, metodele i strategiile existente sau
preconizate n rezolvarea problemelor analizate.
Interviul asigur obinerea de informaii recente i verificarea informaiilor
obinute prin alte metode sau tehnici.
Alegerea subiecilor de intervievat se face avnd n vedere urmtoarele
constatri practice:
- persoanele care ocup poziii medii n ierarhia structurii organizatorice
furnizeaz informaiile cele mai apropiate de realitate;
- colectarea de informaii corecte presupune intervievarea nu numai a
personalului de conducere ci i a celui de execuie;
- competena subiecilor trebuie verificat n prealabil;
- lipsa unei atitudini critice poate s semnifice reineri n exprimarea
ideilor.
Procedura de aplicare a interviului cuprinde trei etape:
1. Etapa pregtitoare const n urmtoarele:
- nsuirea terminologiei utilizate n domeniul studiat;
- formularea i coordonarea ntrebrilor;
- cunoaterea prealabil a subiecilor;
- alegerea momentelor propice pentru luarea interviului (de obicei, partea
medie a perioadei de activitate).
2. Etapa de desfurare a interviului. n aceast etap se cer a fi respectate
urmtoarele reguli:
31

- meninerea discuiei n limitele problemei analizate;

- acordarea unor momente de gndire;
- formularea de ntrebri ajuttoare;
- evitarea consemnrii de rspunsuri fr argumentaie;
- insistarea asupra aspectelor neclare;
- sesizarea strilor de reinere n a critica aspectele negative ale activitii
analizate;
- evitarea discuiilor n contradictoriu;
- solicitarea de recomandri i din partea altor persoane competente din
domeniul analizat.
3. Etapa de culegere i prelucrare a informaiilor se realizeaz prin
consemnarea n raportul de interviu a rspunsurilor cu precizarea aspectelor
neclarificate i a posibilitilor de completare a rezultatelor. Concluziile
interviului reflect starea elementelor sau a proceselor analizate i posibilitile de
remediere a deficienelor existente.
C. Tehnica observrii directe
Observarea direct a activitilor, asigur cunoaterea nemijlocit a
sistemului existent. Prin tehnica observrii directe se studiaz sarcinile care
formeaz coninutul unei activiti. n analiza activitii de producie, spre
exemplu, prin consemnarea operaiilor efectuate asupra produsului i a timpilor de
execuie se contureaz structura ciclului de fabricaie i alte aspecte ale produciei
cum sunt:
- tipuri de produse fabricate;
- tehnologii aplicate;
- locuri de munc;
- dotarea cu utilaje.
Dac obiectivele propuse prin observarea direct sunt clar precizate, atunci
aplicarea acestei tehnici duce la concluzii reale care nu pot fi obinute prin alte
metode. Tehnica observrii directe folosete instrumente specifice de lucru:
- sondaje;
- cronometrri;
- analiza posturilor (locurilor de munc).
Prin aplicarea acestora se relev stri de fapt i posibiliti pentru
ameliorarea funcionarii sistemului.

32

n cadrul anchetelor combinarea tehnicilor menionate asigur clarificarea

problemelor de rezolvat prin cunoaterea detaliat a sistemului i obinerea de
informaii privind posibilitile de raionalizare a activitilor. Rezultatele relev
deficienele existente i implicaiile tratrii automate a datelor.
10. 2. 6. Metoda scenariilor
Metoda scenariilor se bazeaz pe un ansamblu de procedee i instrumente
prin care se stabilete succesiunea logic a evenimentelor, n scopul de a arta
cum se poate evolua pas cu pas spre o situaie viitoare plecnd de la situaia
actual. Pentru fiecare alternativ se urmrete evoluia sistemului reperndu-se
noi puncte nodale.
Prin abordarea global a sistemului sunt elaborate scenarii calitative care
stau la baza elaborrii scenariilor cantitative.
Situaia cercetrilor previzionare la nivel global se justific prin aceea c
evenimentele care depind de fenomene generale sunt, pe termen lung, mai uor de
prevzut dect acelea care depind de circumstane particulare.
Obiectivele principale urmrite prin aplicarea metodei scenariilor sunt:
- predicia dezvoltrii, a evoluiei unor fenomene i procese;
- stimularea gndirii n studiul unei probleme decizionale;
- analiza detaliat a aspectelor dinamice.
n realizarea acestor obiective se urmrete parcurgerea urmtoarelor etape
de lucru:
1. Stabilirea obiectivelor concrete ale cercetrii:
- starea spre care se sper c pot fi dirijate evenimentele;
- alegerea variantelor ce se ramific din punctele nodale.
2. Studiul contextului n care se va dezvolta sistemul:
- reprezentarea factorilor de influen i impactul lor asupra sistemului;
- la baza elaborrii modelelor vor sta seriile dinamice ale indicatorilor ce
reflect aciunea factorilor.
3. Scrierea scenariilor prin abordare global i descrierea evoluiei
sistemului n dinamic, innd cont de modificrile care apar n structura
sistemului.
4. Stabilirea tendinelor n funcie de care va evolua sistemul, dac asupra
lui nu se exercit aciuni voluntare externe.
33

5. Extragerea rezultatelor prin reinerea acelor tendine manifestate care

corespund obiectivelor propuse.

U10.3. Proiectarea logic (elaborarea concepiei

sistemului informatic)
Obiectivul acestei etape l constituie elaborarea proiectului de ansamblu al
sistemului informatic, pe baza cerinelor i restriciilor formulate n tema de
realizare. Scopul acestei etape const n determinarea obiectivelor detaliate i
cerinelor noului sistem. Determinarea cerinelor se face prin studiul organizaiei
pe care o va servi sistemul, accentul punndu-se pe beneficiile pe care le va aduce
sistemul propus.
Principalele activiti care se desfoar n cadrul etapei de concepie a
sistemului informatic sunt urmtoarele:
- definirea sistemului informatic, cuprinznd delimitarea ariei i a
legturilor sale externe; estimarea dimensiunilor sistemului; definirea structurii
logice a datelor i definirea proceselor de prelucrare a datelor;
- adoptarea soluiei de principiu pentru codificarea datelor i conversia
fiierelor;
- proiectarea de principiu a noului flux informaional;
- stabilirea necesarului de echipamente, configuraiile necesare, precum i
modul de procurare a echipamentelor;
- stabilirea condiiilor de montaj, funcionare i exploatare;
- centralizarea cheltuielilor de dotare;
- stabilirea necesarului de produse program noi;
- structurarea sistemului informatic pe componente, cu luarea n
considerare a mai multor variante;
- definirea intrrilor, ieirilor, i prelucrrilor necesare;
- elaborarea graficului de ealonare pentru proiectarea i implementarea
componentelor sistemului;
- evaluarea efectelor pe care le va produce noul sistem informatic;
- estimarea eficienei economice;
- msuri pregtitoare pentru realizarea sistemului.

34

Activitatea cea mai important n cadrul elaborrii concepiei sistemului

informatic este analiza circuitului informaional. Aceasta nseamn c fluxurile
pariale urmeaz a primi coeren prin studiul legturilor i prelucrrilor nlnuite.
n acest fel este posibil s se delimiteze cu claritate graniele sistemului informatic
i legturile sale externe.
Aplicarea metodelor de analiz a circuitului informaional se bazeaz pe
urmtoarele constatri practice:
- fiecare activitate are un circuit informaional propriu; delimitarea
sistemului informatic presupune analiza distinct a fiecrei activiti;
- analiza fiecrei activiti este condiionat de cunoaterea obiectivelor
sistemului economic i de reglementrile care definesc sistemul informaional;
- n activitatea de gestiune economic operaiile de prelucrare a datelor nu
sunt diversificate i au caracter ciclic (operaiile aritmetice i logice simple
reprezint circa 80% din totalul operaiilor de prelucrare);
- pentru fiecare activitate, intrrile condiioneaz i sunt condiionate de
ieirile informaionale;
- prelucrarea datelor de intrare specifice unei activiti n scopul obinerii
ieirilor dorite definete transformrile informaionale i determin circuitul
informaional al activitii.
Stabilirea ieirilor i intrrilor informaionale sunt determinante n
organizarea datelor, n timp ce transformrile informaionale determin
organizarea prelucrrilor. Bazate pe aceste constatri, metodele de analiz a
sistemului informaional i de delimitare a ariei i a legturilor externe ale
sistemului informatic mai des utilizate sunt:
1 - metoda analizei ieirilor;
2 - metoda orientat pe activiti;
3 - metoda rspunsului la stimuli;
4 - metoda compartimental;
5 - metode analizei celulare
1. Metoda analizei ieirilor
Metoda analizei ieirilor const n parcurgerea fluxurilor informaionale
invers, de la informaia final (de ieire) spre informaia iniial (de intrare).
Aceasta analiz se face pe baza diagramelor de flux informaional. Prin
parcurgerea ntregului circuit informaional, se determin:
35

- volumul datelor de ieire;

- volumul datelor de intrare;
- prelucrrile efectuate pe parcursul circuitului;
- purttorii de informaie;
- caracteristicile datelor.
Metoda analizei ieirilor permite obinerea unei imagini complete asupra
circuitului informaional. Totodat, pot fi remarcate deficiene de circuit i
posibiliti de raionalizare a sistemului informaional.
2. Metoda orientat pe activiti
Prin aplicarea acestei metode se urmrete definirea complet a aspectelor
informaionale care caracterizeaz fiecare activitate. Parcurgerea fluxurilor
informaionale pe fiecare activitate asigur cunoaterea detaliat a sarcinilor i a
operaiilor care definesc activitile. Analiza unei activiti se face independent de
celelalte, rednd caracteristicile i intercondiionrile interne ale activitii.
Metoda orientat pe activiti este eficient n sisteme n care se manifest
autonomia activitilor prin relaii de interdependen reduse.
3. Metoda rspunsului la stimuli
Metoda rspunsului la stimuli are ca punct de plecare un stimul oarecare,
cum ar fi: o comand, un produs, o faz de fabricaie etc. Analiznd amnunit
stimulul, se stabilesc legturile dintre activiti i compartimentele ntreprinderii.
Dup identificarea stimulilor la care trebuie s se rspund, se determin
compartimentele implicate i documentele la care se refer stimulul. n continuare
se urmrete fluxul principal al informaiilor cu stabilirea punctelor n care apar
ramificaii i identificarea punctelor de control. Analiza se completeaz cu studiul
fluxurilor secundare.
Pentru activiti complexe, metoda rspunsului la stimuli asigur
observarea conexiunilor i demarcarea operaiilor principale de cele secundare.
4. Metoda compartimental
n aplicarea metodei compartimentale se stabilesc aciunile care se
realizeaz ntr-un compartiment i legturile compartimentului studiat cu celelalte
compartimente.

36

Pentru activiti sau pri din activitile desfurate n compartiment se

determin intrrile, prelucrrile i ieirile informaionale necesare realizrii
sarcinilor compartimentului.
Metoda compartimental este aplicabil n ntreprinderi n care
compartimentele

prezint

o autonomie

mai

mare

n cadrul

structurii

organizatorice.
5. Metoda analizei celulare
La baza metodei analizei celulare st principiul de ierarhizare a
componentelor sistemului informaional dup gradul lor de complexitate. Fiecrei
componente de tip subsistem i se asociaz un rang. Subsistemul de rang zero este
componenta elementar i se numete celul.
Pentru

celul

intrrile

X = { x1 , x 2 ,..., x n } ,

ieirile

Y = { y1 , y 2 ,..., y m } i transformrile T ale intrrilor n ieiri definesc celula

respectiv:
C ={ X , Y , T }

Dac ieirea celulei i constituie intrare pentru celula j , atunci Ci i

C j formeaz un lan notat simbolic:

L = Ci , C j

Figura 10.1. Lan de celule

Mrimile Yi i X

(ieirile din celula i i intrrile n celula j )

desemneaz acelai element. Aceast dubl semnificaie constituie o redundan

informaional. Reducerea unor astfel de redundane se face prin introducerea
conceptului de generaie. Elementul X

este un operand de generaia j . Ca

urmare a transformrii efectuate n celula j , apare generaia j +1 de operanzi

ceea ce se exprim prin relaia:
X

n care

j +1, r

=T X

j, r

semnific numrul de ordine al operandului n cadrul generaiei.

37

Figura 10.2. Generaii de operanzi

Dou sau mai multe lanuri de celule care au cel puin un punct comun,
formeaz un arbore de celule:
A = { Lk , Lm }

Doi sau mai muli arbori legai n serie, paralel sau mixt formeaz o
structur complex (Figura 5.3.).
Convenii:
- operanzii primari (datele primare) constituie operanzi de generaia zero.
(X01, X02, X03, X04);
- transformrile operanzilor de generaia zero formeaz familia de
operatori de generaia 1 (T11, T12, T13);
- celulele sunt reprezentate de operatorii lor prevzui cu doi indici; primul
indic generaia, iar al doilea numrul de ordine al operatorului n cadrul familiei;
- ieirile unui operator sunt de aceiai generaie cu operatorul, indiferent de
generaia intrrilor;
- operatorii n lan sunt de generaii monoton cresctoare;
- un operand poart o singur pereche de indici chiar i cnd constituie
intrri pentru mai muli operatori de aceiai generaie sau de generaii diferite.

Figura 10.3. Arbore de celule

La nivelul ntreprinderii un operator se constituie din reguli de lucru al
cror suport fizic poate fi material sau imaterial. Celula n care acioneaz un
operator se delimiteaz n funcie de necesitile analizei celulare.
Eficiena metodei crete prin combinarea aplicrii ei cu alte metode.
Codificarea datelor. Premiza principal a realizrii de componente viabile
ale sistemului informatic, cu parametri superiori de exploatare este codificarea
datelor care urmeaz a fi prelucrate cu echipamentele de calcul. O metodologie
38

adecvat de codificare contribuie n mare msur la realizarea eficienei scontate

pentru ntregul sistem informatic. Aceasta asigur eliminarea volumului mare de
redundan informaional i raionalizarea procesului de tratare a datelor.
Operaia de codificare a datelor const n stabilirea unei corespondente
biunivoce ntre elementele sistemului informaional (documente, operaii,
produse, materiale etc.) i o mulime de simboluri (cifre, litere etc.). Datele de
codificat constituie vocabularul de intrare, iar simbolurile de reprezentare
formeaz limbajul de codificare. Rezultatele codificrii se concretizeaz n
sisteme de coduri care semnific alfabetul de ieire.
Desfurarea operaiei de codificare presupune respectarea urmtoarelor
principii:
- adoptarea acelorai norme n determinarea vocabularului de intrare;
- folosirea unui limbaj de codificare accesibil, astfel nct interpretarea
alfabetului de ieire s se fac fr dificulti;
- respectarea biunivocitii ntre vocabularul de intrare i limbajul de
codificare. n finalul codificrii, la fiecare element al vocabularului trebuie s
corespund un cod unic determinat;
- previziunea evoluiei codurilor care s asigure posibilitatea actualizrii
sistemelor de coduri fr perturbaii;
- sistemele de coduri adoptate s fie sugestive n redarea legturilor dintre
fenomene, procese i documente;
- adaptarea codificrii n vederea prelucrrii electronice a datelor.
ntre codurile interne sistemului economic i codurile folosite n economia
naionala, urmeaz a se stabili modaliti de conversie care s asigure obinerea
ieirilor informaionale necesare n exterior.
ntr-o abordare metodologica, codificarea const n urmtoarele activiti:
A. Stabilirea caracteristicilor generale ale codurilor.
- Determinarea vocabularului de intrare i a caracteristicilor acestuia.
- Analiza structurii informaiilor din vocabularul de intrare pentru fixarea
structurii generale a codului pe grupe de elemente ale sistemului informaional.
Necesitile de prelucrare impun utilizarea de coduri prin care s se indice locul de
stocare sau de utilizare conturile n care se consemneaz natura i apartenena
elementelor codificate.

39

- Determinarea alfabetului de ieire n funcie de mrimea vocabularului

de intrare i de structura general a codurilor. Codurile care definesc alfabetul de
ieire, trebuie s conin un minimum de simboluri de reprezentare.
- Fixarea sistemelor de coduri astfel nct acestea s asigure maximum de
uniformitate a codificrii.
Principalele sisteme de coduri utilizate sunt:
1. Sistemul n ordine numeric (natural) este utilizat pentru elemente
temporare ale sistemului, fr periodicitate. Orice element nou aprut afecteaz
ntregul sistem de coduri.
2. Sistemul n serie este o dezvoltare a sistemului n ordine natural prin
rezervarea de numere pentru eventuale apariii de noi elemente n vocabularul de
intrare.
3. Sistemul pe grupe const n atribuirea unui anumit numr de coduri
fiecrei clase de elemente de reprezentat. n general codul ijk (i =1, m ; j =1, n ;
k =1, p ) indic grupa

i subgrupa

i sortimentul k

al elementului

reprezentat.
4. Sistemul zecimal presupune divizarea vocabularului de intrare n zece
grupe iar fiecare grup n zece subgrupe .a.m.d. n practica economic acest
sistem este adoptat pentru codificarea conturilor de eviden.
5. Sistemul n ah se bazeaz pe construirea de tabele n care fiecare
dimensiune specific o caracteristic a elementelor de reprezentat, iar elementele
tabelului sunt numere n ordine natural. Aplicarea sistemului este recomandabil
pentru clase de elemente care rmn neschimbate, ca spre exemplu, pentru
codificarea pieselor i subansamblelor unui utilaj.
6. Sistemul repetitiv const n realizarea codului din caracteristicile
elementelor de codificat. Sfera sistemului este limitat la un vocabular de intrare
mai puin complex.
7. Sisteme combinate cum ar fi: sistemul n ordine natural pentru clase
ale vocabularului de intrare, sistemul n serie pentru grupe i sistemul repetitiv
pentru elemente.
8. Sisteme binare prin care se asociaz cifre binare elementelor
vocabularului de intrare. Construirea codurilor se bazeaz pe algebra booleeana i
pe conceptele teoriei mulimilor. Sistemele binare au o larg aplicare n codicarea
datelor de intrare n prelucrarea electronic. Spre exemplu, sistemul EBCDIC de

40

reprezentare a datelor pe 8 biti i sistemul ASCII de reprezentare a datelor pe 7

biti sunt cele mai folosite.
Dat fiind importana codurilor n efectuarea prelucrrii datelor, o atenie
deosebit trebuie acordat corectitudini fiecrui cod utilizat. n acest scop la cod
se adaug o cifr de control care s permit verificarea corectitudinii acestuia n
orice moment al tratrii informaiei reprezentate. Cifra de control se stabilete
dup algoritmi diferii.
B. Clasificarea elementelor vocabularului de intrare de la general la
particular pn la nivel elementar cu respectarea normelor legale. Operaiile i
documentele se grupeaz dup locul i rolul lor n sistem, materialele dup natur,
proprieti, mod de gestionare.
C. Precizarea terminologiei standard de codificare la care se preteaz
fiecare clas de elemente a vocabularului de intrare.
D.

Codificarea

propriu-zis

prin

stabilirea

corespondenei

ntre

vocabularul de intrare i alfabetul de ieire.

E. Unificarea terminologiei i atribuirea codurilor. n toate documentele de
uz intern urmeaz a se atribui coduri elementelor sistemului informaional.
F. Actualizarea codurilor const n adugri de coduri pentru elementele
nou intrate n sistem i n eliminri de coduri perimate pentru elemente care nu se
mai utilizeaz.
Estimarea eficienei economice a sistemelor informatice. Asimilarea
lucrrilor de realizare a unui sistem informatic cu lucrrile de investiii, face ca
determinarea i urmrirea eficienei s fie un aspect major al realizrii sistemului
informatic. Obiectivul global urmrit este creterea efectului util al fiecrui leu
cheltuit.
Eficiena, ca raport ntre efectul util i efortul fcut pentru obinerea
efectului scontat, se urmrete sub aspecte multiple. (productivitatea muncii,
indici de utilizare ai resurselor, norme de consum etc.).
Din punct de vedere informaional, satisfacerea nevoilor de informare ale
conducerii, entropia informaional, costul informaiei, redau eficiena sistemului
informaional. n consecin, aspectele de eficien se refer nu numai la resursele
i efectele imediate ale realizrii unei investiii; prin studiul cheltuielilor necesare
i al efectelor directe i indirecte pe o perioad mai mare de timp. Ele includ i
urmrirea fiabilitii obiectivului investiiei dup darea lui n exploatare.

41

Evaluarea cheltuielilor. Cheltuielile de realizare a sistemului informatic se

constituie din cheltuielile de investiii necesare elaborrii i introducerii sistemului
informatic. n cheltuielile de exploatare se includ i cele necesare ntreinerii
sistemului n scopul creterii performanelor acestuia. n etapa de analiz i
proiectare a sistemului informatic, sunt angajate cheltuieli curente cu salariile
echipei de proiectare (n situaia cnd proiectarea se face cu fore proprii).
Declanarea activitilor de concepie, implic efectuarea de cheltuieli
pentru pregtirea cadrelor proprii de informatic ce vor asigura exploatarea
sistemului.
De asemenea, nc din aceast etap de lucru, apare necesar pregtirea
psiho-social a personalului ntreprinderii asupra utilitii sistemului informatic.
n acest scop sunt necesare cheltuieli cu desfurarea de prezentri demonstrative
privind avantajele prelucrrii automate a datelor i implicaiile scontate. Scopul
unor astfel de aciuni este de a se asigura din timp participarea activ a
personalului la realizarea schimbrilor pe care le va genera introducerea
sistemului informatic, evitndu-se opoziia surd a celor vizai s fie atini de
noua tehnologie.
O categorie important de cheltuieli este cea a cheltuielilor cu tehnica de
calcul, care cuprinde n afar de cheltuielile pentru achiziionarea i instalarea
echipamentelor (hardware) i cheltuieli cu procurarea i adaptarea unor aplicaii
tip i a unor produse-program generalizabile (software). Aceasta asigur nc de la
nceput, scurtarea perioadei de analiz-proiectare, reducerea efortului de
programare i creterea performanelor de exploatare a sistemului informatic.
Cheltuielile pentru realizarea sistemului informatic se mpart n:
1. cheltuieli iniiale ( Ci ) :
- cheltuieli pentru promovarea noii soluii;
- cheltuieli pentru analiz i proiectare;
- cheltuieli pentru procurarea i adaptarea produselor software tipizate;
- cheltuieli pentru procurarea configuraiei hardware;
- cheltuieli pentru amenajarea spaiilor necesare instalrii echipamentelor.
2. cheltuieli de exploatare (Ce ) :
- cheltuieli cu salariile personalului de informatic;
- cheltuieli pentru perfecionarea pregtirii personalului;
- cheltuieli cu materialele consumabile i cu amortizarea tehnicii de calcul;
- cheltuieli cu ntreinerea curent i reparaii;
42

- cheltuieli pentru ntreinerea software a sistemului informatic (adaptarea

sistemului informatic).
Din categoria cheltuielilor iniiale cea mai mare pondere o reprezint
cheltuielile cu proiectarea sau cu procurarea aplicaiilor tipizate grupate n
cheltuieli cu software-ul i cheltuieli cu achiziia echipamentelor care constituie
cheltuielile cu hardware-ul. Analiza evoluiei raportului acestor cheltuieli pe o
perioad lung de timp este consemnat n Figura 5.4.

100%

Cheltuieli cu
software-ul

80%
60%
40%
20%
0%
1970

Cheltuieli cu
hardware-ul
1980

1990

2000

2010

Figura 10.4. Ponderea cheltuielilor cu hardware-ul i software-ul

ntr-un sistem informatic
Din punctul de vedere al ealonrii pe parcursul ciclului de via al
sistemului cheltuielile cu hardware-ul sunt grupate preponderent la nceputul
perioadei de realizare a sistemului informatic, iar cheltuielile cu software-ul au o
repartizare diferit pe durata ciclului de viat. Tema de realizare consum
aproximativ 5% din totalul cheltuielilor cu proiectarea, proiectarea logic i
proiectarea tehnic mai consum nc 35% din resurse, pentru elaborarea
programelor i testarea lor se mai cheltuiesc 40% din fonduri iar pentru
implementare 20%. Aceste procente sunt relative la costurile de proiectare, care la
rndul lor reprezint doar 20% din totalul costului sistemului pe parcursul
ntregului ciclu de via. Cheltuielile pentru exploatare i ntreinere sunt n mare
msur dependente de stabilitatea mediului economic n care este implementat dar
se estimeaz c aceste cheltuieli se ridic la aproximativ 80% din costul total al
sistemului.
Evaluarea efectelor. Introducerea i exploatarea sistemului informatic
genereaz efecte directe i indirecte, care pot fi estimate prin indicatori cantitativi
i calitativi.
43

Stabilirea efectelor economice cantitative se realizeaz prin determinarea

factorilor care contribuie la modificarea mrimii cheltuielilor de producie pe
elemente primare sau pe articole de calculaie ale costului de producie ca urmare
a prelucrrii electronice a datelor pe perioada de via a sistemului informatic.
Aceste efecte se materializeaz n economii de resurse materiale i umane. La
materii prime i materiale de baz, rezult economii prin calcularea i urmrirea
normelor i a consumurilor specifice cu ajutorul tehnicii de calcul. Pentru
materialele auxiliare, economiile rezult printr-o mai bun dimensionare a
stocurilor i prin urmrirea exact a consumurilor.
Estimarea cheltuielilor de transport-aprovizionare se face n raport cu
implicaiile sistemului informatic asupra reducerii timpului pentru aprovizionare.
La salarii, calculul economiilor se bazeaz pe estimarea economiilor
relative de personal tehnic, economic, administrativ prin evaluarea volumului de
munc nainte i dup introducerea sistemului informatic.
Relaia de calcul este urmtoarea:
Ep = Ne ( Mn Mv 1) N T

n care: - Ep este economia de personal;

- Mv este volumul de munc nainte de introducerea sistemului
informatic;
- Mn este volumul de munc dup introducerea sistemului informatic;
- Ne este numrul de lucrtori pentru exploatarea i ntreinerea
sistemului informatic;
- N este numrul lunilor de funcionare a sistemului informatic;
- T este durata ciclului de prelucrare electronic a datelor, n luni.
Economia relativ de personal este privit pe durata de existen a
sistemului informatic, este exprimat i cu ajutorul ponderii lucrrilor din evidena
economic n condiiile prelucrrii electronice a datelor fa de prelucrarea n
sistem manual.
Prin centralizarea economiilor de personal rezult economii la fondul de
salarii. Coeficientul de reducere relativ a fondului de salarii se aplic i
contribuiei privind asigurrile sociale i fondului de omaj.
La suma economiilor enunate mai sus se adaug cele obinute ca urmare a
gestiunii raionale a tuturor resurselor financiare.
n categoria efectelor economice cantitative se adaug profitul
suplimentar. n calcule, punctul de plecare l constituie stabilirea sporului de
44

producie ca urmare a funcionrii sistemului informatic. Relaiile de calcul sunt

urmtoarele:
Sp = Q1 N Kf Q0 N + Spe

unde:

- Sp este sporul de producie ca urmare a funcionrii sistemului

informatic;
- Q0 , Q1 reprezint valoarea produciei nainte i respectiv dup
introducerea sistemului informatic;
- N

este numrul de ani estimat pentru funcionarea sistemului

informatic;
- Kf este coeficientul modificrii valorii mijloacelor de producie n
primul an de funcionare a sistemului informatic fa de anul precedent;
- Spe este sporul efectiv a valorii produciei pe durata exploatrii
sistemului informatic.
Calculul profitului suplimentar

( Ps )

datorat introducerii sistemului

informatic se face avnd n vedere profitul scontat ce se obine n primul an de

aplicare a sistemului informatic ( P1 ) profitul normat ( Pn ) exprimat n mrimi
relative:
Ps = P1 Sp Q1

sau
Ps = Pn Sp

Aplicarea modelelor de normare a costurilor permite ca determinarea

economiilor i a profitului suplimentar s se realizeze global prin abaterea dintre
preul normat i preul efectiv nainte i dup introducerea sistemului informatic.
La cheltuielile variabile, dup determinarea mrimii influenei factorilor
cantitativi i calitativi, abaterea suplimentar semnific influena introducerii
sistemului informatic asupra costului produciei.
Pentru cheltuielile fixe, creterea gradului de automatizare a produciei
duce la obinerea de economii prin accentuarea tendinei de scdere a cheltuielilor
fixe pe unitatea de produs.
Pe lng efectele economice cantitative menionate, funcionarea
sistemului informatic genereaz efecte indirecte (calitative) cum sunt:
- mbuntirea formei i a coninutului documentelor tehnice i
economice;
- raionalizarea sistemului de eviden economic;
45

- orientarea personalului din compartimentele funcionale de la activiti

de rutin spre activiti de concepie;
- mbuntirea controlului asupra activitii de gestiune economic;
- transformarea informaiei privind costul produciei n instrument de
reglare operativ;
- creterea posibilitilor de analiz economico-financiar.
Dat fiind amploarea i complexitatea lucrrilor din domeniul informaticii,
se impune elaborarea unui buget pentru aceast activitate constituit din:
- bugetul investiiilor;
- buget de exploatare;
- buget de ncasri i cheltuieli.
Bugetul informatic asigur estimarea detaliat a efortului i efectelor
elaborrii, introducerii i exploatrii sistemului informatic. De asemenea prin
buget se realizeaz ealonarea resurselor i a modului lor de utilizare pe etape,
perioade i responsabiliti.
Estimarea eficienei globale. Eficiena global a sistemului informatic este
exprimat prin indicatorii:
- coeficientul de eficien global ( Ke ) :
Ke = ( Ec + Ps ) ( Ci + Ce )

- durata de recuperare a cheltuielilor ( Dr ) :

Dr =1 Ke

unde: - Ec este suma economiilor rezultate din funcionarea sistemului

informatic;
- Ci sunt cheltuielile iniiale;
- Ce sunt cheltuielile de exploatare;
- Ps este profitul suplimentar.
Reducerea cheltuielilor cu caracter informatic constituie calea principal
de cretere a eficienei sistemului informatic. Cu ct durata de recuperare a
cheltuielilor cu caracter informatic este mai mic, cu att profitul suplimentar este
mai mare ca urmare a faptului c n perioada dintre momentul recuperrii
cheltuielilor i abandonarea folosirii sistemului informatic, economiile se
transform n profit. Eficiena global crete i ca urmare a prelungirii duratei de
via a sistemului informatic.
Din punct de vedere organizatoric, eficiena sistemului informatic se poate
determina cu ajutorul indicatorul entropia informaional ( H ) prin care se
46

msoar gradul de nedeterminare pe care l nltur informaiile din sistem.

Diferena dintre entropia informaional calculat nainte i dup introducerea
sistemului informatic, semnific, n cifre absolute, creterea gradului de
organizare a ntreprinderii.
Eficiena global a unui sistem informatic trebuie apreciat i prin prisma
implicaiilor introducerii prelucrrii electronice a datelor asupra conducerii:
- previziunea strilor i a funcionrii sistemului economic capt
determinri realiste ca urmare a elaborrii i a folosii unor modele adecvate;
- organizarea sistemului economic comport mbuntiri substaniale prin
raionalizarea structurii organizatorice i prin posibilitatea integrrii metodelor de
conducere previzionar;
- deciziile primesc noi determinri calitative prin sporirea gradului de
obiectivitate;
- coordonarea activitilor se bazeaz pe informaii necesare reglrii
funcionrii sistemului economic la diverse nivele;
- se asigur controlul prin informarea operativ i oportun asupra
dereglrilor care apar n funcionarea organismului economic.
Eficiena sistemului informatic se exprim i prin prisma timpului mediu
de rspuns. Timpul mediu de rspuns este diferena, n uniti de timp, dintre
momentul punerii la dispoziia utilizatorului a unei informaii i momentul cererii
informaiei respective.
Aprecierea eficienei economice cu ajutorul timpului mediu de rspuns se
realizeaz cu ajutorul coeficienilor:
K t = t m0 t m1

i
K c = Ct1 Ct 0

n care: t m0 , t m1 reprezint timpii medii de munc necesari nainte i dup

introducerea sistemului informatic;
- Ct 0 , Ct1 reprezint costurile totale nainte i dup introducerea
sistemului informatic.
Eficiena global a sistemului informatic se estimeaz prin raportul:
Eg = Kc Kt

care exprim corelaia dintre scurtarea timpului mediu i costul pe care aceasta l
genereaz. Sistemul informatic este performant dac raportul este subunitar i
apropiat de valoarea zero.
47

Se consider c o lucrare de concepie n domeniul informaticii este, n

primul rnd, o lucrare de creaie n domeniul conducerii, incluznd problematica
perfecionrii mecanismului economico-financiar i a interaciunilor micro i
macro economice. Activitile de informatic sunt menite s asigure condiii de
cretere a produciei prin reflectarea n sistemul informatic, a factorilor de
influen asupra rezultatelor financiare ale ntreprinderii.
Estimarea eficienei economice a sistemului informatic, avnd n vedere
implicaiile complexe ale realizrii i exploatrii componentelor informatice,
atest faptul c sistemul informatic concur la promovarea eficienei economice n
toate sectoarele de activitate prin creterea efectelor utile i concentrarea efortului
asupra aciunilor de concepie i de conducere a ntreprinderii.

U10.4. Proiectarea tehnic

Este etapa n care se definitiveaz mijloacele tehnice necesare
(echipamente, programe, proceduri manuale ....) prin care fluxul informaional
stabilit anterior este transformat ntr-un flux cu prelucrare automat a datelor.
Efortul principal este de proiectare pur.
Frecvent, datele furnizate din proiectarea logic pot fi gsite incomplete,
astfel c vor fi necesare iteraii i corecii care pot afecta soluia propus din punct
de vedere tehnologic, economic sau operaional.
n

aceast

etap

obiectivul

principal

reprezint

elaborarea

componentelor funcionale detaliate ale sistemului i a specificaiilor de definire a

programelor. Sarcina activitilor din aceast etap ce se desfoar la nivelul
subsistemelor sau chiar al aplicaiilor revine integral analitilor de sistem.
Activitile desfurate n aceast etap sunt:
- proiectarea funcional detaliat pe componente i a legturilor dintre
acestea;
- stabilirea cerinelor i a condiiilor tehnice de realizare a programelor;
- elaborarea programelor de lucru pentru etapa urmtoare i stabilirea
resurselor necesare.
Activitile de proiectare tehnic au ca obiectiv materializarea concepiei
sistemului informatic prin proiectarea funcional amnunit a componentelor
sistemului i a legturilor dintre componente. Pe baza definirii complete i precise
a sistemului informatic din etapele precedente, n etapa de proiectare tehnic sunt
48

concepute specificaiile de realizare pe componente (subsistem, aplicaie).

Proiectul tehnic rezultat din desfurarea activitilor etapei, pentru o component,
constituie baza programrii i a implementrii componentei respective.
Plecnd de la ieirile informaionale dorite de utilizator, sunt elaborate
modelele de obinere a ieirilor din intrrile disponibile prin definirea coleciilor
de date i a procedurilor de tratare a datelor din colecii. Aceste activiti urmresc
definirea detaliat a tehnologiei de prelucrare a datelor. n elaborarea tehnologiei
de prelucrare a datelor, o deosebit atenie trebuie acordat proiectrii fluxului
tratrii datelor urmrind ca, prin coleciile de date i fluxul prelucrrilor s se
reflecte fidel realitatea. De asemenea, prezint interes major verificarea
funcionalitii componentelor proiectate sub aspectul completitudinii i al
corectitudinii operaiilor de tratare a datelor. Performanele sistemului informatic
sunt determinate, n mare msur, de metodele de organizare a datelor.
Modalitile de constituire a coleciilor de date sunt determinante asupra
prelucrrilor, n timp ce organizarea coleciilor de date este condiionat la rndul
ei de definirea fluxului tehnologic al datelor.
n organizarea datelor sunt determinante: studiile pentru delimitarea ariei
i a legturilor externe ale sistemului informatic, modelele de obinere a ieirilor
din intrri, volumul datelor de prelucrat, cerinele de informare ale conducerii.
Metodele utilizate n organizarea datelor sunt:
- metoda fiierelor independente;
- metoda bazei de date.
Metoda fiierelor independente const n crearea de fiiere pe suport
accesibil prelucrrii automate a datelor, pentru nmagazinarea datelor prelucrate n
cadrul fiecrei componente a sistemului informatic. Un fiier este constituit dintro submulime de date omogene relative la o clas de elemente a sistemului
informaional (ex. fiierul de stocuri din aplicaia de gestiunea materialelor).
n general pentru fiecare entitate distinct a sistemului informaional
(materiale, produse, personal etc.) se constituie fiiere cu caracter permanent care
reflect starea elementelor la un moment dat. Operaiile curente din sistemul
economic constituie tranzacii i sunt reflectate n fiiere temporare. (ex: intrri i
ieiri de materiale). Prin aplicarea datelor operaionale coninute n fiierele
temporare asupra datelor de structur din fiierele permanente rezult ieirile
informaionale scontate i se asigur actualizarea fiierelor permanente. n urma
actualizrilor fiierele permanente vor cuprinde starea entitilor la zi.
49

Fiiere permanente (cartoteci, registre cataloage etc.) i fiiere temporare

(centralizatoare, jurnale ...) sunt utilizate i n condiiile prelucrrii manuale a
datelor.
Metoda fiierelor independente asigur rapiditate n organizarea datelor i
a prelucrrilor. n acelai timp efortul de definire complet i corect a sistemului
informatic este mai redus prin proiectarea tehnic detaliat a fiecrei componente
i integrarea ulterioar a componentelor proiectate n sistemul informatic. Aceast
metod este frecvent utilizat n practic pentru probleme de mici dimensiuni.
Creterea complexitii sistemului duce la creterea numrului de fiiere
necesare ceea ce genereaz dificulti sporite de ntreinere. Utilizarea de fiiere
independente conduce la o flexibilitate redus a sistemului informatic,
modificarea structurii fiierelor implicnd refacerea programelor care le utilizeaz.
Prin duplicarea datelor n mai multe fiiere se genereaz redundane
informaionale, utilizarea neraional a suporilor de informaie i dificulti n
actualizarea i controlul datelor.
Pornind de la aceste neajunsuri constatate la organizarea datelor n
fiierelor independente se poate folosi ca alternativ metoda bazelor de date.
Datele din sistemul informatic sunt organizate n colecii care se numesc baze de
date i care au o serie de proprieti i caracteristici ce vor fi artate ulterior.
Trecerea de la fiierele independente ctre bazele de date s-a fcut n timp prin
mai multe etape:
- fiecare program de calcul utiliza date i fiiere specifice, proprii pentru
obinerea rezultatelor dorite (metoda fiierelor independente);
- mai multe programe folosite n rezolvarea unor probleme similare,
utilizau date i fiiere comune, grupate n colecii mai mari specifice domeniului
respectiv;
- toate programele utilizate folosesc o colecie unic de date, o aa-zis
baz de date n care sunt incluse toate datele necesare.
Necesitatea unor mari baze de date comune a fost simit nu numai de
fabricanii de calculatoare i de proiectanii de sisteme informatice, ci i de
utilizatorii sistemelor elaborate. Toi au constatat c n sistemele de o anumit
mrime, n care se lucreaz cu volume mari de date, este nevoie s se gseasc o
serie de modaliti, tehnici i metode eficiente pentru definirea organizarea,
memorarea i actualizarea datelor n forme din ce n ce mai performante.

50

Sistemele informatice n care se utilizeaz conceptul de baz de date prezint

unele avantaje:
- reducerea considerabil a nivelului de redundan al datelor memorate.
Folosind bazele de date comune se pot obine informaii uniforme, att temporal
ct i fizic. Se evit actualizrile pariale a acelorai date n fiiere diferite;
- utilizarea acelorai date n mai multe activiti. Avnd un sistem unitar
pentru definirea i regsirea datelor, implementarea unor noi programe se face
relativ uor. Procedurile folosite pe msura construirii i dezvoltrii sistemului
fiind ct mai uniforme, exploatarea se face mult mai sigur i eficient;
- controlul centralizat, integritatea i securitatea datelor sunt posibile n
astfel de sisteme deoarece definirea structurilor de date, modul lor de gestionare i
accesul la acestea sunt n mna unui singur grup coordonator (denumit n general
administrator al bazei de date);
- independena datelor faa de programe i suporii fizici de memorare
genereaz creterea calitii i fiabilitii sistemului informatic.
Deoarece nu exist o definiie general acceptat, vom denumi o baz de
date un ansamblu unitar organizat i structurat de date a crui gestionare se face
printr-un sistem specializat denumit sistem pentru gestionarea bazelor de date
(SGBD). Prin gestionarea bazelor de date se nelege ndeplinirea unor funcii
specifice de operare asupra lor: creare/generare, actualizare/inere la zi, interogare
i reorganizare.
Ansamblul format din:
- baza de date;
- sistemul care o gestioneaz (SGBD);
- echipamentele de calcul utilizate pentru nregistrarea, memorarea i
pentru prelucrrile efectuate asupra datelor din baza de date;
- procedurile automate i neautomate suplimentare necesare pentru
gestionarea datelor, n afara celor din SGBD, reprezint BANCA DE DATE.
n concepia modern de realizare a sistemelor informatice banca de date
devine subsistemul central, prin el realizndu-se principalele legturi dintre
majoritatea celorlalte subsisteme i aplicaii n primul rnd a celor care lucreaz
cu datele din baza de date.
Un SGBD are trei componente principale:
- utilizatorul sistemului;
- administratorul bazei de date;
51

- gestionarul bazei de date.

Utilizatorul primete rspuns la cererile de informaii pe care le face direct
pentru el sau pentru alte persoane. Sunt mai multe categorii de utilizatori:
- utilizatorul profesionist care pentru a primi rspunsurile solicitate scrie
programe, deci are cunotine de programare;
- utilizatorul nespecialist, care pentru formularea unor ntrebri, scrie o
serie de comenzi sau instruciuni relativ simple, dar pentru a cror utilizare are
nevoie de un anumit instructaj (cteva zile);
- utilizatorul nespecialist, de cele mai multe ori un conductor, care nu
trebuie s fac dect nite operaii elementare pentru a obine informaiile dorite
(utilizatori press-button).
Administratorul bazei de date este o funcie absolut necesar pentru buna
funcionare a SGBD-ului. Se constat c administratorul bazei de date este
necesar totdeauna n cadrul sistemelor informatice chiar cnd nu folosim
conceptul de baz de date. El este reprezentat de o persoan sau un grup de
persoane care controleaz i coordoneaz modul de introducere a datelor,
modificrile ce li se aduc i accesul la ele.
Administratorul trebuie s acorde o deosebit atenie factorilor care
afecteaz memorarea i regsirea datelor i de aceea are nevoie de cunotine
aprofundate privind datele necesare n cadrul organizaiei i modul cum acestea
sunt folosite.
Gestionarul nu mai este o persoan sau un grup de persoane ca n cazul
primelor dou componente, ci o combinaie de echipamente de calcul i de
programe care asigur accesul la date conform instruciunilor primite de la
utilizatori i de la administrator. n acest scop gestionarul trebuie s aib o
interfa cu toate limbajele de programare convenionale admise de SGBD-ul
respectiv. Gestionarul ndeplinete unele funcii care n sistemele anterioare erau
ndeplinite de compilatoare, asambloare, editoare de legturi, programe utilitare
etc. Gestionarul formeaz un fel de grani ntre programele de aplicaie i
mecanismele de acces la date. Gestionarul interpreteaz cererile de date logice
ale diverilor utilizatori i cu ajutorul mecanismelor sale de acces extrage i
transfer datele solicitate de acetia. Utilizatorul nu tie cum i unde sunt
memorate datele. Se spune c tot acest proces este transparent utilizatorului, n
sensul c este parcurs fr a fi cunoscut de el n mod intim, ci numai n principiu.

52

Prin metoda bazei de date se urmrete organizarea datelor din sistem

astfel nct datele memorate pe suport magnetic de mare capacitate s rspund
necesitilor de prelucrare i utilizare ale tuturor componentelor sistemului
informatic i ale tuturor utilizatorilor. Respectarea principiilor privind unicitatea
datelor, independena datelor, consultarea concurent a datelor necesit efectuarea
analizei i proiectrii sistemului informaional prin abordare global i
structurarea lui detaliat.
Activitile ce ar trebui realizate pentru determinarea specificaiei logice
de definire a bazei de date sunt:
1. Trecerea n revist a tuturor cerinelor de informare necesare pentru
rezolvarea diverselor probleme. Cu acest prilej se va stabili o ordine de prioritate
n nlocuirea subsistemelor i lucrrilor manuale cu cele n care gestiunea datelor
i furnizarea rezultatelor se face prin intermediul tehnicii de calcul.
2. Se examineaz toate datele necesare pentru satisfacerea cerinelor de
informare cu stabilirea legturilor informaionale care trebuie s existe ntre
acestea.
3. Se realizeaz o serie de analize i studii detaliate privind datele care se
vor utiliza n sistem. Abia acum se poate vedea dac avem nevoie de un SGBD.
4. Se ntocmete pe baza rezultatelor obinute n activitile anterioare,
specificaia pentru baza de date, care este o documentaie ce cuprinde:
- datele i structurile de date propuse a fi incluse n baza de date;
- o schem care s reprezinte legturile informaionale dintre subsisteme i
aplicaii;
- schema cu structurile logice de date i legturile dintre ele;
- restriciile hardware i software avute n vedere;
- cerinele suplimentare pentru SGBD-ul care urmeaz s fie utilizat cum
ar fi: volumul intrrilor, al ieirilor, timpii de rspuns solicitai, principalele
prelucrri etc.
n funcie de datele de memorat i de relaiile dintre ele ntr-o baz de date
pot s apar urmtoarele tipuri de structuri:
- structura punctual pentru entiti independente;
- structura ierarhic liniar pentru entiti cu relaii liniare ntre ele;
- structura ierarhic arborescent pentru descrierea relaiilor dintre entiti
de tipul un tat are mai muli fii;

53

- structura de tip reea pentru entiti cu relaii complexe ntre ele, rezultat
prin generalizarea structurilor ierarhice liniare i arborescente;
- structura relaional cnd datele nu mai sunt privite ca nregistrri ci ca
relaii.
Buna funcionare a unui sistem informatic lucrnd cu conceptul de baza de
date depinde n mare msur de modul cum se proiecteaz aceast baz de date.
Alegerea variantei de proiectare a circuitului informaional este
condiionat de modul n care aceasta asigur funcionalitatea componentei
respective. Verificarea funcionalitii necesit stabilirea posibilitilor de obinere
a datelor de ieire din datele de intrare ale componentei proiectate. Descrierea
condiiilor logice i a regulilor de obinere a datelor de ieire din datele de intrare
este realizat eficient folosind tehnica tabelelor de decizii.
Aceast tehnic se bazeaz pe constatarea c vederea este cel mai
dezvoltat sim uman. Un tabel de decizii se bucur de toate avantajele pe care le
ofer un tabel oarecare provenind din faptul c sunt clare, concise i uor de citit.
Plecnd de la ideea c orice operaie sau ansamblu de operaii poate fi
condiionat sau necondiionat, tehnica tabelelor de decizii d o form tabelara
procesului de prelucrare a datelor.
O tabel de decizii este constituit din patru pri (cadrane):
1. condiii (criterii) pentru luarea deciziilor ( C1 , C 2 ,..., C m ) ;
2. intrri ale condiiilor ( IC ) ; combinaii ale intrrilor posibile redau
reguli n luarea deciziilor ( R ) ;
3. decizii (aciuni) posibile

( D1 , D2 ,..., D p ) ;

succesiunea vertical a

denumirii deciziilor indic ordinea n care urmeaz a fi executate deciziile;

4. intrrile deciziilor ( ID ) prin care se specific ce decizii urmeaz a fi
luate pentru fiecare regul.

CADRANUL I

CADRANUL II

(condiii)

(intrri ale
condiiilor)

CADRANUL III

CADRANUL IV

54

(decizii)

(intrri ale deciziilor)

Figura 10.5. Cadranele unei tabele de decizii

Tabela de decizii descrie toate variantele posibile ale valorilor condiiilor
i deciziile corespunztoare fiecrei combinaii a acestor valori n soluionarea
unei probleme. Citirea tabelei de decizii se face de sus n jos astfel: dac se
realizeaz condiia C1 i dac se realizeaz condiia C 2 i dac ... atunci se ia
decizia Dk .
R1

R2

R3

R4

R5

R6

R7

R8

Nu

Nu

Nu

Nu

Da

Da

Nu

Nu

Nu

Nu

Da

Nu

C1

Se solicit materialul X de

Da

Da

Da

Da

C2

calitatea I
Depozitul dispune de

Da

Nu

Nu

Nu

C3

materialul X de calitatea I
Depozitul dispune de

Da

Da

Nu

Da

Nu

Da

materialul X de calitatea II n

C4

cantitate Q
Solicitantul accept

D1

schimbarea calitii
Elibereaz materialul X de

D2

calitatea I n cantitate Q
Elibereaz materialul X de

D3

calitatea II n cantitate Q
Emite comanda de

*
*

*
*

aprovizionare pentru

D4

materialul X de calitatea I
Emite comanda de

aprovizionare pentru
materialul X de calitatea II

Figura 10.6. Tabel de decizii

n funcie de valorile ntlnite pentru intrrile condiiilor tabelele de decizii
pot fi:
a) cu intrri limitate; cnd intrrile condiiilor sunt explicitate numai prin
valori DA sau NU (0 sau 1);
b) cu intrri extinse; cnd intrrile fiecrei condiii ale unei tabele de
decizii sunt explicitate prin mai multe valori (0, 1, 2, ...);
c) cu intrri mixte; cnd din necesitile analizei problemei rezult condiii
cu intrri explicitate, fie prin valori DA sau NU fie prin mai mult de dou valori.

55

U10.5. Elaborarea programelor

Dup ce specificaiile de realizare au fost ntocmite i aprobate, ele vor fi
repartizate diverselor grupe de specialiti care au responsabilitatea s le execute i
ulterior s le asambleze. Etapa este consacrat elaborrii programelor i
procedurilor manuale, aferente componentelor sistemului informatic, precum i
testrii componentelor. n funcie de necesitile problemei dar i de cunotinele
proiectanilor, n aceast etap se pot folosi tehnici de programare ca:
- programarea modular;
- programarea structurat;
- programarea orientat pe obiecte,
sau, eventual soluii hibride conform nivelului de stpnire a tehnicilor respective.
Programarea modular. Operaia de mprire a unei probleme complexe,
conceput din punct de vedere logic ca un tot unitar, nu este uoar pentru c
ntotdeauna trebuie avut n vedere ca prile n care a fost descompus ntregul s
nu-i schimbe scopul iniial i totodat s permit, relativ uor, reconstituirea
ntregului atunci cnd este necesar. n acest sens trebuie respectate dou reguli:
- fiecare component trebuie s ndeplineasc o anumit funcie bine
precizat n cadrul ntregului;
- ntre componente este necesar s se stabileasc foarte exact legturile,
astfel ca fiecare parte s-i poat realiza relativ independent funcia specificat i
n acelai timp s poat contribui la funciile generale ale ntregului.
Prin modularitate nelegem proprietatea sau posibilitatea ca un proces s
poat fi descompus n pari componente, cu legturi bine stabilite ntre ele, astfel
ca obiectivul general al procesului s poat fi ct mai eficient realizat. Una din
definiiile date noiunii generale de modularitate aparine lui Russel Armstong,
care considera c un sistem este modular atunci cnd este realizat dintr-o mulime
de elemente creia i este asociat o lege de structur. A gsi legea de structur
nseamn a prospecta interfaa dintre module. Dup acelai autor, proiectarea
interfeei dintre module este simplificat dac modulele au fost concepute astfel
nct s aib o funcionalitate bine definit.
Modularizarea sistemelor informatice ine seam de unele caracteristici ale
acestora:
- sunt realizate i implementate ntr-un timp ndelungat (de ordinul anilor);
56

- introducerea sistemelor informatice conduce la cheltuieli importante;

- sistemele informatice sunt folosite de un numr mare de utilizatori,
rspndii uneori pe zone ntinse;
- cerinele utilizatorilor sunt mereu schimbate i completate.
innd seama de cele de mai sus se poate face o modularizare pe trei
nivele a sistemelor informatice:
a) nivelul 1 - sistem;
b) nivelul 2 - subsistem;
c) nivelul 3 - aplicaie.
a) Sistemul informatic trebuie s urmreasc i s contribuie la realizarea
obiectivelor generale ale ntreprinderii, fixate pe o perioad lung de timp.
Deoarece obiectivele i restriciile generale se pot schimba n timpul realizrii
sistemului informatic este necesar o revedere i o redefinire periodic a acestora.
Acolo unde planurile de perspectiv ale ntreprinderii, sunt cunoscute pentru o
perioad mai scurt dect cea prevzut pentru realizarea i implementarea
sistemului informatic, pot aprea neconcordane imprevizibile, care pot conduce la
efecte negative.
b) Subsistemul corespunde, de regul, unor obiective derivate din cele
generale, rezultate prin detalierea acestora. Exist unele tendine de mprire a
sistemelor informatice n subsisteme dup structura ierarhic i organizatoric
astfel:
- strategic;
- tactic;
- operativ,
sau dup precizarea funciilor sale:
- producie;
- comercial;
- financiar-contabil;
- personal;
- cercetare-dezvoltare.
ntre aceste componente (subsisteme) trebuie s existe legturi (interfee)
clare, ct mai puine i ct mai rigide, n sensul c odat stabilite s nu mai fie
practic modificate.
c) Aplicaia, ca unitate component a subsistemului, contribuie n general
la satisfacerea unor obiective specifice i se dezvolt de obicei la nivelul unor
57

compartimente sau activiti din cadrul ntreprinderii. n structura sistemului pe

trei nivele aplicaia se gsete pe ultimul nivel, i construirea sistemului
informatic se face treptat prin realizarea de aplicaii asamblate n cadrul
nivelurilor superioare.
Adncind nivelul de detaliere al sistemului informatic putem aduga nc
dou nivele:
a) program;
b) modul de program.
d) Aplicaia la rndul ei este constituit dintr-o serie de programe i
proceduri manuale legate ntre ele i care ndeplinesc funciile cerute.
e) La rndul lor programele sunt de cele mai multe ori divizate n mai
multe pri, numite module program independente din punct de vedere logic.
Modulele sunt compuse din instruciuni scrise ntr-un limbaj de programare.
La nivelul programelor modularitatea se mai numete i micro
modularitate. Corelarea modulelor sau cuplarea modulelor este o msura a
independenei modulelor, i poate avea mai multe forme:
- corelarea extern, cnd modulele utilizeaz aceleai date globale ale
sistemului;
- corelarea prin control, cnd unul din module controleaz execuia
celorlalte n mod explicit, prin chei de control sau variabile de control a cror
valoare indic modul de continuare a execuiei;
- corelarea intern sau prin coninut, cnd un modul refer direct alt
modul;
- corelarea prin date, cnd la apelarea unui modul de ctre altul toate datele
de intrare sau de ieire ale modulului apelat sunt comunicate sub form de
parametrii.
Un alt element caracteristic este ponderea sau tria modulelor care reflect
modul de formare i coninutul modulului. Exist mai multe posibiliti de
divizare a programelor n module i anume:
- divizarea ntmpltoare, care d tria cea mai slab modulelor cci
programul este mprit arbitrar n module;
- divizarea logic, are ca rezultat module ce efectueaz o funcie la fiecare
apelare;
- divizarea clasic, prin care modulul efectueaz mai multe funcii
necorelate ntre ele prin date;
58

- divizarea prin comunicare, cnd modulele efectueaz mai multe funcii

corelate prin date;
- divizarea funcional, cnd modulele efectueaz o singur funcie care le
este specific.
Modularizarea este una din sarcinile principale ale proiectanilor de
sisteme informatice i este n cele mai multe cazuri, o operaie complicat de care
depinde n mare msur modul cum va funciona n final sistemul. n acest scop,
n cadrul proiectelor mari, pe baza unor experiene anterioare, adaptate la
specificul respectiv, se elaboreaz reguli i chiar norme care trebuie avute n
vedere la mprirea n componente la toate nivelurile. n fond, aceste reguli
decurg din conceptul general de modularitate, stabilind n principal c un modul
trebuie:
- s ndeplineasc o funcie unic, lucru extrem de avantajos atunci cnd se
fac modificri;
- s fie complet;
- s aib ct mai puine interfee cu ale module;
- s permit o nelegere uoar a problemelor pe care le rezolv;
- s se poat ncadra n diversele tipuri de modularitate ale sistemului.
Avantaje ale modularizrii:
1) Posibilitatea divizrii ntregului n pri mai simple i mai uor de
realizat.
2) Independena modulelor permite elaborarea i testarea separat a
acestora.
3) Fiecare modul poate fi realizat prin tehnicile (limbajele) cele mai
adecvate funciei pe care o ndeplinete.
4) Posibilitatea construiri a unei biblioteci de module testate (module
standard) disponibile tuturor proiectanilor.
5) Simplificarea ntreinerii sistemului (programului).
6) Permite abordarea de la simplu la complex i permite o ncrcare
echilibrat a fiecrui membru din echipa de proiectare.
Dezavantajele modularizrii:
1) Muli proiectani nu neleg modularizarea sau nu se pot acomoda cu ea.
2) Modularitatea cere eforturi suplimentare n faza de proiectare.
3) Proiectanii nu cunosc problema n ansamblu ci numai pari ale ei.

59

4) Concepia modular duce la realizarea de programe care ncarc

suplimentar unitatea central a calculatorului cu funciile de dispecerizare i
comunicare ntre module.
Noiunea de modularitate este nsoit aproape ntotdeauna de un alt
concept, cel de top-down. Top-down nseamn de sus n jos sau
descendent. n linii mari el ar putea fi explicat astfel: n procesul general de
cunoatere se ncepe cu aspectul general, n mare al fenomenului, dup care,
treptat, acesta se detaliaz, se cunoate n profunzime, pn la un anumit nivel,
considerat suficient pentru scopul urmrit. Dac modularizarea nseamn procesul
de descompunere a unui ntreg n pri componente, metoda cea mai obinuit,
pentru ca mprirea s fie corect fcut, este tocmai cea top-down.
Trgnd o concluzie mai general, se poate spune c n orice fel de proces
de cunoatere din lumea real, metoda universal valabil este cea a analizei
descendente, top-down.
Programarea structurat. Pentru abordarea unei probleme complexe n
realizarea a unui sistem informatic se impun preocupri pentru scderea raportului
cost/ performan, prin aplicarea unor principii de structurare att n fazele de
proiectare ct i n cele de realizare a sistemelor informatice. Principiile generale
privind realizarea acestor produse informatice trebuie aplicate n mod consecvent
n toate fazele de realizare. Aceste principii se refer n primul rnd la:
- identificarea funciilor necesare pentru realizarea produsului, analog cu
determinarea prilor componente ale unui produs industrial;
- descompunerea consecvent descendent (top-down) n procesul de
identificare a funciilor componente ale proiectului. Introducnd noiunea de
nivel al funciilor ( Nf ) i punnd convenional nivelul rdcinii structurii
Nf = 0 ,

putem defini nivelul unei funcii oarecare ca fiind egal cu nivelul funciei

din care descinde plus unu. Funciile cu nivelul cel mai ridicat se mai numesc i
primitive ale structurii iar cea cu nivelul zero se numete rdcina structurii;
- realizarea modular a produsului, presupune izolarea funciilor gsite n
faza de identificare, apoi determinarea interfeelor dintre module.
Normalizarea primitivelor structurilor funcionale (primitivele structurii).
La un anumit nivel de descompunere n ierarhia funciilor unei structuri se
gsesc algoritmii de rezolvare ai subproblemelor. Pentru realizarea oricrui
algoritm este suficient utilizarea unui set restrns de structuri funcionale
primitive. Aceste structuri vor fi considerate structuri elementare.
60

Tehnica de programare care i propune s respecte aceste principii i care

va fi tratat n continuare este numit programarea structurat.
Pentru a crea o imagine general a efortului de definire a programrii
structurate prezentm o serie de definiii posibile aprute pe o perioad mai lung
de timp, cu meniunea c cele din anii de nceput ai conceptului prezint mai mult
constatri de circumstan i au o not uor ironic:
1. Este o ntoarcere la bun-simt.
2. Este metod general dup care programeaz cei mai buni programatori.
3. Este programarea fr GO TO.
4. Este procesul prin care se controleaz numrul de interaciuni dintre un
proces i contextul su, astfel nct numrul de interaciuni s fie o funcie liniar
depinznd de civa parametrii ai procesului.
5. Este programarea TOP-DOWN.
6. Programarea structurat se ocup de convertirea unor scheme logice
arbitrar de mari i complexe n forme standard, astfel nct s poat fi reprezentate
prin iterarea i compunerea unui numr mic de structuri logice de control
standard.
7. Este o manier de a organiza i codifica programe astfel nct s fie ct
mai uor de neles i de modificat.
8. Scopul programrii structurate este de a controla complexitatea prin
teorie i disciplin.
9. Programarea structurat poate fi caracterizat nu prin absena
instruciunii GO TO ci prin prezena structurii.
10. O funcie major a structurii programelor este de a face posibil
demonstrarea corectitudinii lor.
11. Programarea structurat nu este o soluie total, ea const, de fapt, n
folosirea unor notaii formale pentru a gndi ordonat.
12. Procesul de organizare a gndirii care duce la o expresie inteligibil a
procesului de calcul ntr-un timp rezonabil.
13. Arta simplitii.
Sintetiznd se poate ajunge la urmtoarea definiie: Programarea
structurat const dintr-o mulime de restricii i reguli de programare care
foreaz programul s urmeze o form strns, n acest fel eliminndu-se muli din
factorii care conduc la erori i care complic activitatea de testare i ntreinere.

61

Examinarea structurii interne a unui program, evideniaz existenta unei

structuri ierarhice ntre componentele unui program, fiecare component fiind
coordonat de componenta de nivel superior i coordonnd componenta de nivel
inferior. Ideea structurilor ncuibate (nested-logic) conduce la o dispunere a
elementelor componente ntr-o form n care s se poat distinge nivelele
ierarhice, astfel nct fiecare nivel de prelucrare s reprezinte o detaliere a
nivelelor precedente. Pentru definirea structurii nested-logic a unui program se
utilizeaz ca instrument de lucru diagrama de structur. Blocurile nested-logic
folosite n diagrama de structur sunt:
- SECVENA care marcheaz grupul de enunuri care se execut n
ordinea n care au fost scrise;
- SELECIA care marcheaz separarea enunurilor n dou grupe i
executarea unei sau alteia din aceste grupe n funcie de o anumit condiie;
- ITERAIA care marcheaz un grup de enunuri cu execuie repetat de
un numr de ori (inclusiv repetarea de zero ori ceea ce echivaleaz cu eliminarea
grupului de enunuri).
Regulile de structurare ale blocurilor sunt:
- punctul de intrare ntr-un bloc este unic;
- punctul de ieire dintr-un bloc este unic;
- blocul iterativ ncepe prelucrarea prin testarea condiiei de ieire din
ciclu;
- un bloc poate conine orice combinaie de blocuri care satisfac condiiile
de mai sus.
Blocurile diagramei de structur sunt reprezentate prin dreptunghiuri
identificate printr-un nume nscris n interior.
Diagrama de structur este reprezentarea grafic a unei structuri de
prelucrare pe nivele de detaliere conform urmtoarelor reguli:
- nivelele de detaliere se parcurg de sus n jos;
- fiecare nivel reprezint o detaliere a nivelului precedent;
- blocurile situate pe un acelai nivel ierarhic se parcurg de la stnga la
dreapta;
- terminarea parcurgerii unui nivel presupune parcurgerea urmtorului bloc
din nivelul anterior.
Regulile de citire a diagramei de structur sunt:

62

- citirea operaiei de trecere de la un nivel superior ctre un nivel inferior

se face utiliznd expresia const din;
- citirea operaiei de trecere de la un bloc la alt bloc de pe acelai nivel se
face utiliznd expresia urmat de;
- citirea operaiei de trecere de la un nivel inferior ctre un nivel superior
se face prin trecerea la urmtorul bloc al nivelului superior utiliznd expresia
urmat de;
- un cercule marcat n colul din dreapta sus al unui bloc identific un bloc
opional i se citete utiliznd expresia sau;
- un asterisc marcat n colul din dreapta sus al unui bloc identific un bloc
cu execuie repetat i se citete utiliznd expresia mai multe.
Reprezentarea blocurilor nested-logic utilizate n diagrama de structura
i corespondena lor cu reprezentarea din schemele logice clasice este prezentat
n Figura 10.7.
SECVENA
X
A
A

SELECIA

da
X

nu

A
A

ITERAIA
X
C

da

nu

Figura 10.7. Structuri elementare n programarea structurat

TEOREMA DE STRUCTUR: Oricare ar fi schema logic S aparinnd
mulimii schemelor logice clasice i care reprezint structura logic a unui proces
de prelucrare, exist cel puin o transformare T pentru care

S ' =T ( S )

astfel

nct:
1. S ' este echivalent cu S;
2. S ' este o schem cu structur nested-logic.
Programarea orientat pe obiecte. Pentru problemele de natur
economic, n limbajele de programare clasice, cea mai mare parte a ateniei era
acordat descrierii structurilor de date deoarece, practic, prelucrrile efectuate
63

asupra lor sunt destul de simple i nu necesit un efort de programare deosebit.

Spre exemplu n limbajul COBOL aproximativ 79% din lungimea codului surs
este ocupat de descrierea structurilor de date. n timp, odat cu creterea
complexitii programelor, a aprut necesitatea unei organizri riguroase a muncii.
Ca o etap superioar capabil s rezolve n bun msur problemele ivite, s-a
impus programarea structurat. De-a lungul anilor, n special datorit creterii
dimensiunii produselor software, i acest instrument a devenit la rndu-i depit.
Sporirea complexitii programelor aducea dup sine dificulti reale legate de
ntreinerea unor programe mamut. Cu alte cuvinte, dei preul produselor era n
cretere, calitatea lor tindea s scad.
n cutarea unei soluii care s scoat informatica din situaia dificil n
care se afla, s-a pornit de la ideea c o bun reprezentare a temei de rezolvat este
deseori cauza transformrii unei probleme complexe ntr-una deosebit de simpl.
n urma diversificrii cutrilor, au aprut limbaje avnd la baz noiunea de
cadru (frame) i cele care pornesc de la ideea de aciune, ambele noiunii
folosite n inteligena artificial. Prima categorie implementeaz operaii asupra
unor modele de entiti iar cea de a doua susine faptul c obiectele nu sunt
simple elemente pasive asupra crora se fac prelucrri, ci, dimpotriv, menirea
obiectelor rezid n a activa prelucrrile ce le vor suporta ele nsele.
Dei teoria programrii orientate pe obiecte era bine fundamentat de peste
20 de ani, ideea nu a prins cu adevrat dect n ultimii ani. Programarea pe obiecte
n loc s separe iremediabil datele de cod nu face altceva dect s contopeasc
cele dou elemente.
Primele limbaje cu adevrat demne de acest nume au fost SIMULA (1965)
i SIMULA-2 (1967), iar prin anii '70 SMALLTALK.
Cel mai mare dezavantaj al lor, din punct de vedre al penetrrii pe pia, a
fost nsui faptul c au aprut ca limbaje de sine stttoare, avnd o rspndire
relativ redus. Din acest motiv puini programatori erau dispui s abandoneze
limbajele consacrate n acele momente, doar de dragul de a lucra obiectual. O
bun perioad de timp metoda programrii obiectuale a fost uitat.
n anii '80 n urma acceptrii definitive a limbajului C , un colectiv
condus de Bjarne Stroustrup ncearc introducerea conceptului de clas ntr-un
dialect numit C with classes. Ideea prinde contur i n 1983 ia natere prima
versiune a noului limbaj C + + . Aproape imediat apar i partizanii fanatici ai
OOP-ului aflat acum la a doua tineree. Termenul de OOP provine din Object
64

Oriented Programming care desemneaz disciplina programrii obiectuale sau

orientat-obiect.
Profitnd deci de marea popularitate n rndul soft-itilor i de
multitudinea domeniilor de aplicaie (de la grafica interactiv la exploatarea
reelelor de calculatoare i chiar pn la proiectarea compilatoarelor) moftul
devine mod i moda certitudine. Acest succes extraordinar s-a datorat faptului c
limbajul C + + nu face nimic altceva dect s-i dea un nou avnt unuia dintre cele
mai la moda limbaje ale momentului C .
OOP introduce conceptul de NCAPSULARE prin care se ating
urmtoarele obiective:
- facilitatea deosebit de localizare a erorilor;
- modularizarea problemei de rezolvat.
Noiunea de clas conine declaraii de variabile i declaraii de funcii
care opereaz asupra variabilelor. Funciile se numesc funcii membru sau metode
iar variabilele variabile membru. Cu ajutorul claselor, un programator i poate
defini orice tip de dat dorit, mpreun cu setul de operaii. Toate aceste informaii
sunt ncapsulate ntr-o clas. Astfel prin clas vom nelege un tip abstract de
dat, definit de utilizator.
Un obiect este o variabil declarat ca fiind de tipul clas. Altfel spus
un obiect este o instaniere (o realizare) a unei clase. Prin intermediul claselor se
pot separa informaiile de implementare (mecanism intern) de cele de utilizare
(mecanism extern).
Un alt termen introdus de OOP, este motenirea. n urma definirii unei
clase, cu un minim de efort i timp se pot preciza seturi de clase asemntoare,
avnd totui o trstur distinctiv. Avnd o clas B putem defini o alt clas

D care s moteneasc sau s preia toate caracteristicile clasei B la care s se

poat aduga altele noi, proprii doar acesteia din urm. Prima clas se va numi
clas de baz iar cea de-a doua clas derivat. Motenirea st la baza altor
concepte novatoare cum ar fi polimorfismul dar elementul esenial al
programrii obiectuale rmne ncapsularea.
Polimorfismul const n faptul c ntr-o ierarhie de clase obinute prin
motenire, o metod poate avea forme diferite de la un nivel la altul, specifice
respectivului nivel din ierarhie. Aa cum n lumea vie hrnirea este universal
valabil ea deosebindu-se de la o clas la alta de vieti, tot aa i n cazul OOP
metoda poate avea forme diferite de la o clas la alta.
65

n momentul de fa piaa informatic este invadat de biblioteci i colecii

de clase. Menirea lor este de a permite un coeficient ct mai ridicat de reutilizare a
codului scris. Pe de alt parte, pornind de la aceste clase, utilizatorul poate crea
prin motenire alte clase, care s-l ajute s-i rezolve problema n mod optim. n
plus, programatorul are garania folosirii unor proceduri scurte, inteligibile i nu
n ultimul rnd corecte.
Un alt domeniu de utilizare a bibliotecilor de clase este cel al realizrii
prototipurilor unor produse software. Prin prototip se nelege un program
funcional, simplificat i care s dea o imagine clar a produsului final. Utilitatea
lor const n faptul c, ntr-un timp foarte scurt i cu un efort minim din partea
productorului, clientul poate avea o imagine destul de clar asupra produsului
final. Pentru o aplicaie oarecare prototipul nu trebuie s conin algoritmul optim,
clientul urmnd s poat nlocui doar acele module care sunt deficitare din
anumite puncte de vedere.

U10.6. Implementarea, exploatarea i ntreinerea

Implementarea este etapa n care sistemul se testeaz n condiii reale.
Etapa ncepe cnd componentele individuale, care au fost testate i acceptate, pot
fi asamblate pentru testarea i includerea n sistem pe baza specificaiilor i
manualelor elaborate n etapa anterioar.
Circuitul informaional existent este nlocuit cu noul circuit prin lansarea
n execuie a programelor i verificarea practic a modului de obinere a
rezultatelor, acestea constituind activitile de implementare a sistemului
informatic.
Etapa se consider terminat cnd sistemul este acceptat de beneficiar.
Unele activiti pregtitoare ale implementrii pot ncepe nc din etapa
precedent. Activitile aferente implementrii sunt urmtoarele:
- pregtirea implementrii;
- executarea procedurilor de conversie;
- testarea n condiii reale;
- evaluarea rezultatelor obinute i verificarea performanelor sistemului;
- definitivarea documentaiei.
Etapa de exploatare ncepe cnd informaiile din sistem sunt furnizate n
mod curent beneficiarului. n paralel cu exploatarea sistemului se desfoar
66

ntreinerea sistemului. Exploatarea este legat de problemele curente zilnice ale

meninerii sistemului n stare de funcionare, n timp ce ntreinerea const n
activiti de evaluare periodic legate de modificrile ce trebuiesc fcute pentru a
menine sistemul viabil.

UNITATEA 11
METODA MERISE CICLUL DE ABSTRACTIZARE
Durata medie de studiu individual - 3 ore

Cuprins:

pag.

U11.1. Scopul i obiectivele unitii ...........................................................

U11.2. Modelul conceptual al datelor ........................................................
U11.3. Modelul logic al datelor ..................................................................
U11.4. Modelul fizic al datelor ...................................................................
U11.5. Modelul conceptual al comunicaiilor ...........................................
U11.6. Modelul conceptual al prelucrrilor ..............................................
U11.7. Modelul organizaional al prelucrrilor .......................................
U11.8. Modelul operaional al prelucrrilor .............................................
U11.9. Test de autoevaluare .......................................................................
U11.10. Rezumat .........................................................................................
Bibliografie minimal .................................................................................
Rspunsuri i comentarii la testul de autoevaluare .................................

67

160
160
169
175
177
178
191
195
196
197
199
199

U11.1. Scopul i obiectivele unitii

n aceast tem vei nva urmtoarele concepte fundamentale:
- modelul conceptual al datelor;
- modelul logic al datelor;
- modelul fizic al datelor;
- modelul conceptual al comunicaiilor;
- modelul conceptual al prelucrrilor;
- modelul organizaional al prelucrrilor;
- modelul operaional al prelucrrilor.

U11.2. Modelul conceptual al datelor

Pentru realizarea unui model conceptual al datelor este necesar folosirea
unei reprezentri sub forma de text a realitii aa cum a fost ea neleas de
analist. Ea se rezum la descrierea literar ca urmare a analizei, putndu-se deduce
din aceasta entitile, asociaiile etc. care vor constitui mai departe modelul
conceptual al datelor.
Concepte utilizate n MCD
a) entitate - este reprezentarea n sistemele informaionale a unui obiect
material sau imaterial avnd o existen proprie i conform cu necesitile
gestiunii ntreprinderii.
n general se utilizeaz un substantiv comun ca nume de entitate, nume
ales astfel nct s sublinieze ct mai bine relaia cu componenta din sistem pe
care o reprezint;
b) realizarea unei entiti - este un element individualizat aparinnd
entitii. Spre exemplu informaiile relative la salariatul Popescu sunt o realizare a
entitii SALARIAT;
c) asociaia - reprezint o relaie ntre entiti. Numrul entitilor care
intervin n relaie caracterizeaz dimensiunea asociaiei:
- asociaii binare ntre dou entiti;
- asociaii ternare ntre trei entiti;
- asociaii n-are ntre

n entiti.

n general se utilizeaz ca nume de asociaie un verb care s sublinieze ct

mai bine relaia dintre entiti.
Spre exemplu asociaia LUCREAZ permite s se neleag faptul c un
SALARIAT lucreaz ntr-o SECIE.
68

SALARIAT

SECIE

LUCREAZ

Figura 11.1. Asociaie

d) realizarea unei asociaii - este o asociaie individualizat adic o
pereche, triplet etc. constituit dintr-o singur apariie a fiecrei entiti participante
la relaie.
Spre exemplu n afirmaia salariatul Ionescu lucreaz n departamentul
Resurse Umane cuplul Ionescu/Resurse Umane este o realizare a asociaiei
LUCREAZ;
e) asociaie reflexiv - este o relaie care exist ntre realizarea unei
entiti i o alt realizare a aceleiai entiti. Spre exemplu asociaia NCADRAT
este o asociaie reflexiv care traduce faptul c un anumit SALARIAT are
posibilitatea de a ncadra (angaja) ali salariai.

SALARIAT
NCADRAT

Figura 11.2. Asociaie reflexiv

f) legtura - reprezint o relaie ntre o entitate i o asociaie. Ea este
caracterizat prin cardinalitatea sa. Se poate distinge printr-un nume, ceea ce este
foarte practic n cazul asociaiilor reflexive;
g) cardinalitate - permite s se exprime funcionalitatea i totalitatea sau
parialitatea unei relaii:
- cardinalitatea minimal - este numrul minim de participri ale realizri
unei entiti la realizrile unei asociaii;
69

- cardinalitatea maximal - este numrul maxim de participri ale realizrii

unei entiti la realizrile unei asociaii.

ENTITATE
cardinalitate
minim

cardinalitate
maxim

ASOCIAIE

Figura 11.3. Cardinalitate

Spre exemplu dac se examineaz MCD-ul urmtor:

SALARIAT

SECIE

1,1

LUCREAZ

1,n

Figura 11.4. Exemplu cu entiti, asociaie i cardinaliti

se poate spune c aceste cardinaliti indicate ntre entitile SALARIAT i
asociaia LUCREAZ se traduc astfel:
- orice salariat lucreaz n cel puin o secie;
- orice salariat lucreaz n cel mult o secie;
- adic orice salariat lucreaz ntr-o singur secie. n acelai fel
cardinalitile dintre SECIE i asociaia LUCREAZ se traduc prin: ntr-o secie
lucreaz cel puin un salariat i ntr-o secie lucreaz cel mult
mai muli salariai.

70

n salariai, adic

Se constat c toate cardinalitile permit s transpun realitatea i n

consecin alegerea lor este primordial. n plus, dup cum se va vedea n
continuare, ele au o influen deloc neglijabil asupra MFD.
Cardinalitile principale sunt constituite din urmtoarele combinaii:
0,1

- niciunul sau unul singur;

1,1

- unul i unul singur;

0, n

- niciunul sau mai muli;

1, n

- cel puin unul sau mai muli.

Este posibil s se genereze i alte cardinaliti dect acestea, spre exemplu

0,2 dar n modelul fizic al datelor cardinalitile superioare lui 1 sunt transformate
n cardinaliti

n;

h) informaia - este componenta elementar a sistemelor informaionale.

(ex. nume, prenume, cod potal etc.);
i) domeniul - permite s se formalizeze ansamblul valorilor care stau la
baza informaiilor. Toate valorile luate de informaii i care sunt transferate
entitilor constituie ansamblul valorilor din sistemele informaionale.
Exemple: domeniul dobnzilor - numere pozitive cu 7 ntregi i 2
zecimale; domeniul numelor - alfabetic cu majuscule;
j) proprietate - este informaia care se ataeaz unei entiti sau unei
asociaii. Ea poate referi un domeniu deci ea i poate motenii caracteristicile (tip,
lungime, list de valori).
Numele fiecrei proprieti poate fi nscris n simbolul entitii sau
asociaiei atunci cnd acestea sunt purttoare de atribute.
Exemplu: entitatea SALARIAT are proprietile marca, nume, prenume,
iar asociaia NCADRAT are proprietile data de nceput i data de sfrit.
SALARIAT
marca
nume
prenume

LUCREAZ
data nceput
data sfrit

Figura 11.5. Proprieti

71

k) identificatorul unei entiti - este constituit din una sau mai multe
proprieti particulare ale unei entiti astfel nct la fiecare valoare a
identificatorului corespunde o singura realizare a entitii.
Toate entitile trebuie s posede un identificator care poate fi compus din
una sau mai multe proprieti. Prin convenie proprietile cu rol de identificator
sunt subliniate.
De exemplu proprietatea MARCA este identificatorul entitii SALARIAT
adic poate defini fr ambiguitate fiecare salariat.
SALARIAT
marca
nume
prenume

Figura 11.6. Identificator

l) identificatorul unei asociaii - este ntotdeauna obinut prin
concatenarea

identificatorilor

entitilor

participante

la

asociaie.

Acest

identificator nu figureaz n MCD.

m) legtur-identificator. S-a vzut necesitatea ca fiecare entitate s aib
un identificator, dar n anumite cazuri acesta nu este suficient.
Dac se urmrete MCD-ul urmtor:
PROIECT

LUCRARE

cod_proiect

cod_lucrare
1,n

COMPUS

1,1

Figura 11.7. Legtur identificator

se constat c cele dou entiti sunt legate printr-o relaie de compoziie.
S-ar putea dori s se defineasc identificatorul cod lucrare din entitatea
elementar LUCRARE, relativ la identificatorul cod proiect din entitatea
72

compus PROIECT. Dar cum este posibil ca dou lucrri s aib acelai cod dac
ele aparin unor proiecte diferite, se va putea identifica fr ambiguitate o lucrare
prin codul su i prin codul proiectului cruia i aparine.
n acest caz legtura care pornete de la entitatea elementar este numit
LEGTUR-IDENTIFICATOR, i are obligatoriu cardinalitatea 1,1.
Pe grafic aceast cardinalitate apare ntre paranteze, difereniindu-se n
acest fel de o legtur 1,1 normal.
n) legtura de motenire. Motenirea poate fi exprimat ca o legtur
particular ntre entiti n acelai timp foarte apropiate dar totui diferite. Datorit
acestui concept de entitate general sau mam, se exprim caracteristicile comune
mai multor entiti formnd o aceiai familie.
Conceptul complementar de entiti specializate, particulare sau fiice ale
unei entiti generale exprim caracteristicile proprii fiecrui membru al familiei.
Se vorbete de asemenea de legturi generice ntre entiti tip i sub-tip. Toate
proprietile definite pentru entitatea general sunt motenite de ctre entitile
specializate. n acelai timp toate asociaiile unei entiti generale sunt valabile
pentru entitile specializate.
Aceast noiune permite mbogirea considerabil a MCD punnd n
eviden noiunile de tip i sub-tip n snul unei aceleiai entiti.
n plus ea permite utilizatorului s genereze un MFD care ine cont ntradevr de specificaiile artate. Se evit astfel, fie redundana informaional fie
nlocuirea coloanelor care au valori nule.
Fie de exemplu entitatea ANGAJAT, care cuprinde angajaii de gen
masculin i pe cei de gen feminin. Se poate reprezenta aceast particularitate prin
noiunea de motenire considernd entitile ANGAJAT MASCULIN i
ANGAJAT FEMININ ca entiti specializate ale entitii generale ANGAJAT.
Reprezentarea const ntr-o legtur cu sgeat care pleac din entitatea
fiic i puncteaz entitatea mam. ANGAJAT
Un simbol n form de semicerc este desenat n
mijlocul legturii i servete ca cod
punct
de ntlnire pentru alte legturi venind de la
angajat
nume angajat
alte entiti fiic.
adresa

ANGAJAT
MASCULIN
obligaii
ceteneti

73

ANGAJAT
FEMININ
concediu de
maternitate

Figura 11.8. Motenire

Reguli de normalizare a MCD
Elaborarea unui MCD se realizeaz n mai multe etape, i este adesea
supus modificrilor pe parcursul realizrii proiectului informatic. Una din etapele
eseniale ale realizrii unui MCD este verificarea modelului aplicnd un numr de
reguli numite reguli de normalizare. Se obine n acest fel un modelul cu
redundan minim n stocarea datelor.
REGULA 1 - Toate entitile trebuie s posede un identificator.
REGULA 2 - Toate proprietile unei entiti sau unei asociaii trebuie s
fie elementare, adic nedecompozabile.
REGULA 3 - Pentru fiecare realizare a unei entiti sau asociaii, dou
proprieti nu pot reprezenta aceiai informaie real, adic nu pot s aib valori
repetate pentru o aceiai realizare a entitii sau asociaiei.
REGULA 4 - Toate proprietile, altele dect identificatorul, trebuie s
depind n ntregime de identificator i nu numai de o parte din el.
REGULA 5 - Fiecare proprietate trebuie s depind direct de identificator
i nu prin intermediul uneia sau mai multor proprieti.
Dac modelul ndeplinete regulile 1,2 i 3 este n PRIMA FORM
NORMAL.
Dac ndeplinete i regula 4 modelul este n A DOUA FORM
NORMAL.
Dac ndeplinete i regula 5 modelul este n A TREIA FORM
NORMAL.
Exemplu: Un salariat al unei ntreprinderi, mprit n secii, lucreaz
ntr-o singur secie i particip la minim dou proiecte. Fiecare secie are un cod
i o denumire.

SALARIAT

Aceast prezentare se traduce n urmtorul MCD.

nume
adresa
proiect_1
74
proiect_2
cod_sectie
den_sectie

Figura 11.9. Model nenormalizat

Regulile normalizrii nu sunt respectate, i nu se poate spune nici mcar
dac este n prima form normal. De altfel:
- nici o proprietate nu este identificator (R1);
- proprietatea ADRESA nu este elementar (R2);
- este o repetare a numelor de proiect (R3).
Dac se admite c pentru o secie dat nu exist doi salariai avnd acelai
nume, se va putea alege ca identificator cuplul COD_SECIE, NUME.
Proprietatea ADRESA se descompune de exemplu n dou proprieti
elementare STRADA i ORA.
Repetarea numelui de proiect se va traduce cu ajutorul unei entiti
PROIECT i a unei asociaii PARTICIP.
Se obine astfel urmtorul MCD.
SALARIAT
nume
cod_proiect
strada
oras
den_sectie

PROIECT
nume_proiect
1,2

PARTICIP

1,n

Figura 11.10. Model n prima form normal

Acest MCD este acum n prima form normal.
Se poate constata c nu este respectat regula 4. Cuplul COD_SECIE,
NUME identific fr ambiguitate fiecare salariat, dar proprietatea DEN_SECIE
nu depinde dect de o parte a identificatorului, proprietatea COD_SECIE. Pentru
a respecta
a doua form normal, se adaug entitii SALARIAT
SALARIAT
PROIECT o nou
proprietate denumit MARC care identific fr ambiguitate fiecare salariat din
marca
nume_proiect
ntreprindere,
Se obine urmtorul
nume iar DEN_SECIE depinde direct de MARC.
PARTICIP
1,2
1,n
MCD: cod_proiect
strada
oras
75
den_sectie

Figura 11.11. Model n a doua form normal

Acest model este acum n a doua form normal dar nu este n a treia
form normal pentru c nu este respectat regula 5. Se constat c proprietatea
DEN_SECIE nu depinde direct de identificator, dar depinde mai curnd de
proprietatea COD_SECIE. Dependena de identificator nu este direct ci mai
degrab tranzitiv prin intermediul proprietii COD_SECIE.
Pentru a elimina acest inconvenient este suficient s se introduc o nou
entitate SECIE i o asociaie LUCREAZ care arat faptul c un salariat
lucreaz ntr-o secie. Se obine urmtorul MCD care este acum n a treia form
normal.
SALARIAT
marca
nume
strada
oras

PROIECT
PARTICIP

1,n

1,2

den_proiect

SECIE
1,1

LUCREAZ

1,n

cod_sectie

Figura 11.12. Model n a treia form normal

n concluzie prima form normal este suficient pentru implementarea
unui ansamblu de date, dar trebuie urmrit atingerea celei de-a treia forme
normale pentru a minimiza redundana informaional i n consecin riscurile
discordanelor dintre date.
Normalizarea este deci un proces prin excelen intelectual, cci bazat pe
analiza semantic a proprietilor i plecnd de la un ansamblu amorf de date se
obine un model conceptual n a treia form normal.

76

U11.3. Modelul logic al datelor

n timp ce modelul conceptual al datelor este independent de sistemul de
gestiune al fiierelor utilizat, la nivel organizaional trebuiesc integrate soluiile de
organizare a datelor astfel nct formalismul entitate/relaie s poat fi transcris ct
mai exact, la nivelul fizic, n termenii limbajului de gestiune a datelor ales.
Alegerea depinde de tipul software-ului avut la dispoziie, i noul model
rezultat (modelul logic al datelor - MLD) trebuie s in cont de posibilitile
acestui software fr ns s intre n detaliile tehnice ale metodelor de stocare i de
acces specifice urmtorului nivel, nivelul fizic. Alegerea sistemului de gestiune a
datelor se poate face ntre fiiere i baze de date.
Utilizarea fiierelor const n nmagazinarea pe suport accesibil prelucrrii
automate, a datelor prelucrate n cadrul fiecrei componente a sistemului
informatic. Un fiier se constituie dintr-o submulime de date relativ omogene
relative la o clas de elemente a sistemului informaional. Identificatorul unui
fiier este o proprietate aleas astfel nct la fiecare valoare a acestei proprieti s
corespund o singur realizare a unui articol din fiier. Articolul dintr-un fiier
este o colecie de proprieti care se refer la acelai element. O realizare a
articolului reprezint ansamblul proprietilor pentru un articol individualizat.
Se pot distinge dou feluri de fiiere:
- fiiere clasice de tip BASIC, FORTRAN, COBOL etc.;
- fiiere secvenial-indexate multicriteriale tip DBASE.
Cu fiierele clasice accesul dup criterii multiple este dificil i sisteme de
gestiune a fiierelor ca de exemplu cel din COBOL nu permit dect funcii de
adugare, cutare, modificare i tergere. Orice alt operaie rmne n sarcina
programatorului.
La fiierele secvenial-indexate multicriteriale accesul se face dup mai
multe chei, este mult mai uor i sunt oferite mai multe posibiliti de prelucrare.
Metoda fiierelor prezint inconveniente majore, idiferent de tipul de
fiiere folosit:
- existena renundanelor;
- apariia unor probleme de coeren;
- procedurile de securitate trebuiesc programate;
- programatorul trebuie s gestioneze el nsui relaiile ntre fiiere;
77

- programatorul trebuie s cunoasc metodele de stocare i de acces;

- creterea complexitii sistemului duce la dificulti sporite de ntreinere.
Ca urmare a persistenei acestor inconveniente n informatica mondial s-a
impus un nou concept care a devenit dominant nc din anii '70. Acesta este
conceptul de baz de date. n sistemele de o anumit complexitate sunt necesare
metode performante pentru definirea, organizarea memorarea i actualizarea
datelor. Astfel o baz de date poate fi definit ca un ansamblu de date organizat
unitar i structurat a crui gestionare se face printr-un sistem specializat denumit
sistem pentru gestionarea bazelor de date (SGBD).
Noiunea de baz de date este caracterizat de urmtoarele:
- structurarea datelor;
- redundan minim;
- coerena datelor;
- acces dup criterii multiple;
- date legate ntre ele conform cu MCD;
- independena programelor i datelor;
- securitatea datelor;
- actualizare i interogarea concurent.
n funcie de datele de memorat i de relaiile dintre ele ntr-o baz de date
pot s apar urmtoarele tipuri de structuri:
- structura arborescent; cnd exist o singur legtur ntre dou entiti
ale bazei de date, de la tat la fiu, exploatarea fcndu-se fie pe traseul tatfii fie invers fiu-tat;
- structura reea; cnd o nregistrare fiu poate avea mai multe nregistrri
tat, care permite cutarea n toate direciile pornind de la orice entitate. Trebuie
menionat aici modelul CODASYL (Conferance on Data Systems Languages)
elaborat la nceputul anilor '70, i ale crui norme sunt respectate de numeroase
sisteme de baze de date;
- structura relaional; cnd entitatea este privit ca o relaie ntre
proprieti i nu ca o nregistrare, asigurndu-se o independen total a
programelor fa de date.
Trecerea de la MCD la MLD se poate face ctre toate tipurile de
organizare a datelor, inclusiv ctre organizarea n fiiere clasice, dar mai utilizate
sunt MLD CODASYL i MLD relaional. n cele ce urmeaz vom dezvolta
trecerea ctre MLD relaional.
78

Modelul logic al datelor utilizeaz concepte ale modelului relaional i

presupune dispunerea datelor sub form de tablouri cu dou dimensiuni numite
tabele sau relaii.
Pentru a facilita nelegerea regulilor de trecere de la MCD la MLD
trebuiesc definite urmtoarele concepte:
a) tabel. Un tabel corespunde unei entiti sau unei asociaii din MCD i
este alctuit din linii i coloane;
b) linie. O linie corespunde noiunii de realizare a entitii sau asociaiei;
c) coloana. Noiunea de coloan corespunde noiunii de proprietate;
d) cheie primar. Noiunea de cheie primar corespunde noiunii de
identificator;
e) cheie strin. O coloan a unui tabel este numit cheie strin dac ea
corespunde unei chei primare dintr-un alt tabel. Cheia primar permite accesul la
coloanele tabelului de referin evitnd repetiiile.
Reguli de trecere de la MCD la MLD
REGULA 1. Entitile devin tabele. Proprietile devin coloane de tabele.
Identificatorii entitilor devin chei primare ale tabelelor.
REGULA 2. Cnd o asociaie binar are o legtur 0,1 sau 1,1 i o alta
de cardinalitate 0, n sau 1, n apare o migraie a cheilor entitii legate de
legtura de cardinalitate 0, n sau 1, n spre cealalt entitate.
Fie MCD-ul din Figura 6.13, care prezint faptul c un beneficiar
caracterizat prin proprietile cod fiscal (identificator) i nume beneficiar
primete una sau mai multe facturi caracterizate printr-un numr factur
(identificator) i valoare factur. O factur este primit de un singur beneficiar.
BENEFICIAR
COD_FISCAL
NUME_BENEFICIAR

FACTURA

1,n

PRIMETE

1,1

NUMAR_FACTURA
VALOARE_FACTURA

Figura 11.13. Reguli de trecere de la MCD la MLD - exemplu

Asociaia nu se transform ntr-un tabel la nivelul MLD, dar este explicitat
plasnd n tabelul factura cheia primar a tabelului beneficiar care devine o cheie
strin. Se obine astfel urmtorul MLD:
BENEFICIAR

FACTURA

COD_FISCAL
NUME_BENEFICIAR

NUMAR_FACTURA
COD_FISCAL
VALOARE_FACTURA

79

Figura 11.14. Reguli de trecere de la MCD la MLD - exemplu

Dac ASOCIAIA din MCD prezentat anterior are proprietatea data
(data primirii facturii) atunci MCD i MLD corespunztor arat astfel:
BENEFICIAR

FACTURA

1,n

COD_FISCAL
NUME_BENEFICIAR

PRIMETE

1,1

DATA

NUMAR_FACTURA
VALOARE_FACTURA

BENEFICIAR

FACTURA

COD_FISCAL
NUME_BENEFICIAR

NUMAR_FACTURA
COD_FISCAL
VALOARE_FACTURA
DATA

Figura 11.15. Reguli de trecere de la MCD la MLD - exemplu

Dac se utilizeaz conceptul de LEGTUR-IDENTIFICATOR ca n
MCD-ul urmtor care arat c o factur este constituit din una sau mai multe
poziii (rnduri n factur), iar o poziie aparine unei singure facturi,
FACTURA
NUMAR_FACTURA
VALOARE_FACTURA

POZITII

1,n

CONTINE

[1,1]

NUMAR_POZITIE
VALOARE_POZITIE

Figura 11.16. Reguli de trecere de la MCD la MLD - exemplu

identificatorul entitii poziii va fi format din concatenarea identificatorilor
entitilor participante la asociaie, conform MLD de mai jos:
FACTURA

POZITII

NUMAR_FACTURA
VALOARE_FACTURA

NUMAR_FACTURA
NUMAR_POZITIE
VALOARE_POZITIE

Figura 11.17. Reguli de trecere de la MCD la MLD - exemplu

REGULA 3.
Dac o asociaie binar este purttoarea a dou legturi de cardinalitate
0, n

sau 1, n asociaia devine un tabel n MLD, n care migreaz cheile

entitilor.
80

Asociaia devine un tabel, n care cheia primar este obinut prin

concatenarea identificatorilor entitilor participante la asociaie.
Dac asociaia are proprieti, acestea devin coloane n tabelul care rezult
din asociaie.
Considernd urmtoarea situaie: un client poate s nu cumpere sau s
cumpere
de

n produse, iar un produs poate s nu fie cumprat sau s fie cumprat

n clieni , modelele conceptual i fizic vor arta ca n Figura 6.18.

CLIENT

PRODUS

COD_FISCAL
DENUMIRE_CLIENT

0,n

CUMPARA

0,n

COD_PRODUS
DENUMIRE_PRODUS

CUMPARA
CUMPARA

CLIENT

COD_FISCAL
COD_PRODUS

COD_FISCAL
DENUMIRE_CLIENT

PRODUS
COD_PRODUS
DENUMIRE_PRODUS

Figura 11.18. Reguli de trecere de la MCD la MLD - exemplu

Noiunea de asociaie din MCD poate fi deci tradus n funcie de
cardinalitile asociate, n dou feluri:
- prin utilizarea conceptului de cheie strin (regula 2);
- prin utilizarea unui nou tabel (regula 3).
Cardinalitile alese la nivel conceptual determin deci n mare parte
structura fizic, fiind necesar o mare atenie n alegerea lor.
REGULA 4.
Atunci cnd o asociaie binar are dou legturi de cardinalitate 0,1 sau
1,1

apare o dubl migraie a identificatorilor entitilor.

Fie urmtorul MCD i corespunztor acestuia urmtorul MLD.

AGENT_ECONOMIC
COD_FISCAL
DENUMIRE

CERTIFICAT_INMATRICULARE

1,1

ARE

1,1

AGENT_ECONOMIC

NUMAR
DATA

CERTIFICAT_INMATRICULARE
NUMAR
COD_FISCAL
DATA

COD_FISCAL
NUMAR
DENUMIRE

Figura 11.19. Reguli de trecere de la MCD la MLD - exemplu

81

n MLD se pstreaz cele dou entiti provocndu-se n fiecare din ele

migrarea reciproc a identificatorilor. Cnd asociaia binar are dou legturi 0,1
sau 1,1 i o proprietate, atunci asociaia se transform ntr-un tabel prin trecerea
de la MCD la MLD.
REGULA 5.
Aceast regul privete n special entitile generatoare i entitile
specifice. Fie MCD urmtor:
SALARIAT
MARCA
SALARIU

BARBAT

FEMEIE

obligaii_ceteneti

concediu_de_maternitate

Figura 11.20. Reguli de trecere de la MCD la MLD - exemplu

Exist mai multe posibiliti de a obine MLD din care o prezentm pe cea
mai simpl, adic crearea unui tabel pentru fiecare entitate, ceea ce se traduce prin
migrarea identificatorului i a proprietilor de la entitatea generatoare (mam) n
fiecare entitate fiic:
SALARIAT
MARCA
SALARIU

BARBAT

FEMEIE

MARCA
SALARIU
OBLIGAII_CETENETI

MARCA
SALARIU
CONCEDIU_DE_MATERNITATE

Figura 11.21. Reguli de trecere de la MCD la MLD - exemplu

Atunci cnd entitatea generatoare este n asociaie cu o alt entitate, apare
o combinaie ntre REGULA 2 i regulile menionate mai nainte, rezultatele
obinute fiind n funcie de cardinalitile asociaiei.

82

U11.4. Modelul fizic al datelor

Descrierea unui model fizic este strns legat de sistemul de gestiune a
datelor ales. n practic se ntlnesc frecvent trei tipuri de soluii tehnice:
1. Utilizarea unui sistem de gestiune a fiierelor clasic avnd ca metod
principal accesul secvenial-indexat.
Fiierele indexat secveniale sau cu index rar presupun memorarea
nregistrrilor ntr-un fiier numit fiier principal, n ordinea cresctoare a cheilor
i grupate pe pagini. Se adaug un fiier de index, ce conine pentru fiecare pagin
din fiierul principal cte o nregistrare cu valoarea celei mai mari chei din pagin
i adresa de nceput a paginii. Fiierul de index este ordonat cresctor n raport cu
valoarea cheii. De cele mai multe ori pagina corespunde unui bloc, nlnuirea
blocurilor n ordine cresctoare a cheilor permite parcurgerea secvenial ordonat
a fiierului. Atunci cnd n fiierul de index se gsete acelai numr de
nregistrri cu cele din fiierul principal fiierul se numete cu index dens.
Pentru fiierele de dimensiuni foarte mari, se poate considera fiierul de index din
organizarea secvenial indexat ca fiier principal cruia i se ataeaz un fiier cu
index rar. Procednd recursiv pn se obine un fiier index ce conine un singur
bloc, se obine o structur indexat pe mai multe nivele, foarte flexibil i
eficient, numit structur B-arbore de la denumirea din limba englez balanced
trees.
2. Utilizarea unui sistem de baze de date de tip CODASYL;
Sistemul CODASYL este unul reprezentativ pentru modelul de organizare
tip reea. Acesta se poate implementa uor prin asocierea a cte unui fiier la
fiecare entitate. nregistrrile fiierului corespund realizrilor entitii i cmpurile
nregistrrii corespund atributelor entitii. Modelul reea este apropiat de forma
de reprezentare a bazelor de date sub forma diagramelor entitate-asociaie.
Deosebirea const doar n faptul c toate relaiile ce apar pot fi numai binare de
tipul unu-la-unu i mai-muli-la-unu. Aceast restricie permite reprezentarea
grafic a unei baze de date de tip reea sub forma unui graf direcionat numit reea.
ntr-o reea nodurile corespund entitilor i relaiile sunt reprezentate prin sgei
ntre noduri de la tat la fiu. Structura de reprezentare reea este dezvoltarea
structurii arborescente permind ca orice colecie de date s aib mai multe
colecii de date superioare. O relaie R de forma mai-muli-la-unu de la entitatea
E1 la entitatea E2 se implementeaz ca o mulime de liste circulare numite inele
83

avnd capetele n fiierul asociat lui E2. Un inel de capt e2 aparinnd lui E2
conine toate elementele e1 aparinnd lui E1 care sunt n relaie cu e2.
Modelul reea este folosit din ce n ce mai puin, fiind eficient doar n
cazul unor baze de date foarte mari. De aceea acest tip de baze de date nu mai sunt
studiate i dezvoltate.
3. Utilizarea unui sistem de baze de date de tip relaional.
Modelul relaional se bazeaz pe noiunea matematic de relaie, aa cum
este ea definit de teoria mulimilor, i anume ca o submulime a produsului
cartezian al unei liste finite de mulimi numite domenii. Elementele unei relaii se
numesc tupluri, iar numrul de domenii (nu toate distincte) din produsul cartezian
se numete aritatea relaiei. De obicei relaiile sunt reprezentate sub forma unor
tabele n care fiecare rnd reprezint un tuplu i fiecare coloan reprezint valorile
tuplurilor dintr-un domeniu dat al produsului cartezian. n reprezentarea sub
form de tabel a unei relaii, coloanelor i respectiv domeniilor corespunztoare
lor li se asociaz nume intitulate atribute. Mulimea atributelor unei relaii se
numete schem relaional. Un alt mod de a defini relaiile este urmtorul: prin
relaie nelegem o mulime de funcii definite pe o mulime de atribute cu valori
n reuniunea unor domenii, cu restricia ca valoarea corespunztoare fiecrui
atribut s se afle n domeniul asociat acelui atribut. Mulimea tuturor schemelor
relaionale corespunztoare unei aplicaii se numete schema bazei de date
relaionale, iar coninutul curent al relaiilor la un moment dat se numete baz de
date relaional. n modelul relaional entitile sunt reprezentate sub form de
relaii n care schema relaional conine toate atributele entitii i fiecare tuplu al
relaiei corespunde unui element al entitii. La atributele entitii se pot aduga n
relaie i alte atribute suplimentare utilizate pentru exprimarea relaiilor ntre
entiti.
Descrierea modelului fizic al datelor (MFD) va fi fcut n limbajul
sistemului de gestiune corespunztor soluiei alese. n plus, mediul de dezvoltare
va influena i el foarte mult MFD.

U11.5. Modelul conceptual al comunicaiilor

Acest model, numit i graf actori-flux, permite descrierea informaiilor
schimbate la nivel global n sistem. Conceptele utilizate sunt:
84

a) actor
Se nelege prin actor tot ceea ce joac un rol n transmiterea unei
informaii i care produce un flux informaional (persoan fizic, juridic, cldire,
servicii) Actorii se mpart n dou categorii:
- actori interni, care fac parte din organizaie;
- actori externi organizaiei sau domeniului studiat.
b) flux
Un flux este un schimb de bunuri, bani sau informaii ntre un actor
emitor i unul receptor. Se disting n particular urmtoarele fluxuri:
- fluxuri fizice;
- fluxuri monetare;
- fluxuri de informaii.
Printre fluxurile de informaii, n funcie de natura suportului se va vorbi
de flux informaional oral, documentar sau informatic. O alt clasificare a
fluxurilor este n funcie de locul emitorului n raport cu domeniul studiat:
- flux intern, atunci cnd este emis de un actor intern domeniului;
- flux extern, atunci cnd este emis de un actor extern domeniului.
c) ordonarea fluxurilor
Aceast operaie permite observarea nlnuirii fluxurilor, putndu-se
deosebi fluxurile primare de fluxurile secundare.
d) flux primar
Un flux primar este un flux care apare la cel mai sczut nivel organizatoric
ntr-un domeniu de gestiune. ntr-un domeniu contabil, un flux primar va fi de
exemplu un borderou de micri, document situat n amonte de fluxuri ca
jurnalele, cartea mare, balana, bilanul etc.
e) flux secundar
Un flux secundar este un flux a crui emisie este subordonat preexistentei
unuia sau mai multor fluxuri primare sau secundare. De exemplu, emiterea unei
facturi este subordonat recepiei unei comenzi.
FLUX1
f) graful fluxurilor
Graful fluxurilor este un graf ale crui noduri sunt actori iar arcele
ACTOR1
orientate sunt fluxurile schimbate.

FLUX3

FLUX2

85
ACTOR3

FLUX4
ACTOR2

Figura 11.22. Modelul conceptual al comunicaiilor

U11.6. Modelul conceptual al prelucrrilor

Prelucrrile constituie partea dinamic a sistemului informaional. Ele
descriu aciunile ce trebuie executate asupra datelor pentru obinerea rezultatelor
scontate. Prelucrrile nu sunt de fapt dect traducerea regulilor de gestiune care
compun activitatea sistemului economic. Reprezentarea schematic face apel la
urmtoarele concepte:
1) domeniu
Noiunea de domeniu n sensul de domeniu de gestiune corespunde unei
pri a sistemului care conine subansamble coerente.
Exemplu: domeniul comercial, domeniul financiar, domeniul personal.
2) procese
Procesele reprezint subansamble ale unui domeniu. Se recurge la aceast
mprire atunci cnd sistemul de studiat este foarte vast.
Exemplu: Domeniul comercial al unei ntreprinderi poate cuprinde trei
procese: urmrire reprezentani, primire comenzi i urmrire comenzi.
3) operaie
O operaie este o activitate prin care se produc fluxuri informaionale. O
operaie este definit imaterial, fr restricii organizatorice. Ea descrie la fel de
bine gestiunea manual ct i pe cea automat.
O operaie poate utiliza una sau mai multe entiti i/sau asociaii pentru
aciuni de creare, modificare, tergere sau consultare.
O operaie se descompune n aciuni.
Exemplu: O operaie n domeniul Evidena personalului ar putea fi
Obinerea adeverinei de salariu. Simbolul pentru operaie este:
OPERATIE
86

Figura 11.23. Operaie

4) aciune
O aciune este o funcie elementar. ntre aciunile unei operaii nu exist
ateptare, i derularea lor este secvenial.
O aciune poate referi una sau mai multe REGULI DE GESTIUNE
O operaie poate utiliza una sau mai multe entiti i/sau asociaii pentru
aciuni de creare, modificare, tergere sau consultare. Simbolul este:
OPERATIE
ACTIUNE 1
ACTIUNE 2
Figura 11.24. Aciune
5) reguli de gestiune
O regul de gestiune este o reglementare care la nivelul ntreprinderii se va
aplica sistematic. Regulile de gestiune vor servi la definirea ansamblului de reguli
care trebuiesc respectate pentru aciuni. O aceeai regul de gestiune se poate
aplica uneia sau mai multor aciuni.
Exemple:
1. Trebuie aplicat 2% reducere clienilor ale cror comenzii din anul
precedent au depit 40.000 lei;
2. Comenzile ctre furnizor trebuie s fie vizate de ctre eful serviciului
aprovizionare.
6) eveniment
n timpul analizei unei operaii trebuie ntotdeauna s se pun ntrebarea
care sunt evenimentele care concur la declanarea unei operaii?. Un
eveniment se definete ca un flux de orice natur, sau un fapt care permite
lansarea unei operaii. Un eveniment va fi n general desemnat printr-un verb la
participiu document, ci trebuie conservat aspectul dinamic al descrierii. Se va
spune mai bine comanda primit dect comanda.
Exemple: Cererea unui deviz este un eveniment. Faptul c suntem n a
cincia zi din lun este de asemenea un eveniment.
87

Simbolul pentru eveniment este:

EVENIMENT
(A)

Figura 11.25. Eveniment

Un eveniment are un nume, un cod, i un alias care apare ntre paranteze.
Se vor distinge:
- evenimente declanatoare, care declaneaz o operaie sub controlul unei
condiii de sincronizare;
- evenimente rezultate, produse de ctre o operaie ca urmare a unei reguli
de emisie.
Declanarea unei operaii este n general condiionat de prezena mai
multor evenimente declanatoare. Aceste evenimente nu apar n acelai moment,
deci apare necesitatea condiionrii declanrii operaiei cu o condiie de
sincronizare a evenimentelor declanatoare. n acelai fel, operaiile, nu genereaz
ntotdeauna aceleai evenimente rezultante. Producerea evenimentelor rezultante
va fi deci supus regulilor de emisie.

EVENIMENT 1
(A)

EVENIMENT 2
(B)
OPERATIE
ACTIUNE 1
ACTIUNE 2

EVENIMENT 3
(C)

EVENIMENT 4
(D)

Figura 11.26. Evenimente declanatoare i rezultante

Evenimentele 1 i 2 declaneaz o operaie alctuit din dou aciuni 1 i
2, iar evenimentele 3 i 4 sunt rezultatul operaiei.
88

7) condiia de sincronizare
Condiia de sincronizare este exprimat printr-o condiie boolean care
leag evenimentele declanatoare prin operaii logice I, SAU, NU. Operaia nu
este declanat dect atunci cnd condiia este ndeplinit. Este recomandat
folosirea alias-ului pentru descrierea condiiei de sincronizare.
n exemplul din figura 11.27., operaia nu va fi declanat dect dac
evenimentul A se produce n acelai timp cu evenimentul B sau C.
Dac un singur eveniment este necesar pentru declanarea operaiei,
condiia de sincronizare dispare din reprezentarea grafic.
8) regula de emisie
O regul de emisie definete condiia sub care evenimentele rezultate vor
fi produse de ctre o operaie. O operaie poate avea una sau mai multe reguli de
emisie, o regul gestionnd emisia unuia sau a mai multor evenimente rezultate.

EVENIMENT 2
(B)
EVENIMENT 1
(A)

EVENIMENT 3
(C)

EVENIMENT 2
(B)

EVENIMENT 1
(A)

EVENIMENT 3
(C)

A ( B C)
OPERATIE

()

ACTIUNE 1
A B C 2
ACTIUNE
OPERATIE
Figura
ACTIUNE
1 11.27. Condiia de sincronizare
ACTIUNE 2
REGULA DE EMISIE 1

EVENIMENT 4
(D)

89

REGULA DE EMISIE 2

EVENIMENT 5
(E)

EVENIMENT 2
(B)
EVENIMENT 1
(A)

EVENIMENT 3
(C)

Figura 11.28. Regula de emisie

O operaie poate s nu aib regul de emisie. n acest caz emisia

()

evenimentelor este necondiionat iA B C se traduce cu ajutorul cuvntului

totdeauna. O regul de emisieOPERATIE
poate avea 1un alias pentru uurarea afirii
simbolului operaiei
n cazul
ACTIUNE
1 n care textul care definete regula este prea lung.
ACTIUNE 2
REGULA DE EMISIE 1

EVENIMENT 4
(D)

REGULA DE EMISIE 2

EVENIMENT 5
(E)

Figura 11.29. Modelul conceptual al comunicaiilor - exemplu

OPERATIE2
Evenimentele 1, 2 i 3 declaneaz operaia 1 punndu-se condiia de
ACTIUNE3
sincronizare a I (b SAU c). Operaia
1 este constituit din aciunile 1 i 2 care
conduc la regula 2 de emisie. Evenimentele
4 i 5 sunt rezultate produse de
TOTDEAUNA
operaia 1.

90

EVENIMENT 6
(F)

Operaia 2 compus din aciunea 3 este declanat de evenimentul 5.

Evenimentul 6 este ntotdeauna emis de operaia 2.
9) reguli de creare a unui MCP
Crearea unui MCP poate prea uoar la prima vedere, dar se poate
constata c exist tendina de a se comite dou tipuri de erori:
- erori de modelare;
- erori de validare a modelului.
10) erori de modelare
Erorile de modelare sunt datorate n general dificultilor pe care le
ntlnim n timpul analizei unui proces n separarea prii conceptuale de partea
organizaional.
Trebuie s ne amintim tot timpul c MCP trebuie s exprime ce trebuie
fcut, dar nu arat cnd trebuie fcut i nici unde trebuie fcut (concepte
organizaionale) i nc i mai puin cum trebuie fcut (concept operaional).
DOSAR

Cu titlu
de exemplu s ncercm modelarea procesului de selecie a unui
DEPUS
candidat la ocuparea unui post. Aceast modelare se sprijin pe urmtoarea
CONTROL ACTE

prezentare sub form de text.

CONTROL ACTE DEPUSE

La primirea dosarului, un angajat efectueaz controlul documentelor din

CORECT

INCORECT

dosar. Dup care se studiaz curriculum vitae-ul redactat de candidat i care face
parte din documentele depuse n dosar. Atunci cnd aceste controale sunt
DOSAR
favorabile, DUP
se trimite
PRIMUL
CONTROL

o convocare pe adresa candidatului.

SCRISOARE
DE
RESPINGERE
1

STUDIERE DOSAR

CORECT

INCORECT

DOSAR
DUP AL
DOILEA
CONTROL

SCRISOARE
DE
RESPINGERE
2

EDITARE CONVOCARE
EDITARE SCRISOARE DE CONVOCARE
TOTDEAUNA

91

SCRISOARE
DE
CONVOCARE

Figura 11.30. MCP - Erori de modelare

Fr a putea spune c acest model este fals se pot formula totui
urmtoarele observaii:

DOSAR

1. nici un eveniment extern, dup

venirea dosarului, nu justific mprirea
DEPUS
prelucrrilor aa de detaliat (scrisoarea de respingere reprezint de fapt numai un
singur eveniment);
2. s-a inut cont n acest model de o restricie organizaional, asimilnd o
operaie desfurat ntr-un anumit loc de munc unei operaii conceptuale;
DOSAR
n general, atunci cnd oSTUDIERE
serie de operaiuni
se nlnuie fr evenimente
STUDIUL AUTOBIOGRAFIEI

externe sau interne justificate

cu adevrat,
nu trebuie s aib loc o detaliere a
CONTROLUL
DOCUMENTELOR
operaiunilor.

CORECT

INCORECT

Se poate propune urmtorul MCP:

SCRISOARE
DE
CONVOCARE

92

SCRISOARE
DE
RESPINGERE

Figura 11.31. MCP corectat

11) erorile legate de validarea modelului
Dup conceperea unui MCP, este posibil s se aplice cteva reguli de
validare. Aceste reguli, elementare, fac apel mai ales la bunul sim.
a) Reguli legate de operaiuni
Cnd s-a plasat o operaie n model trebuie verificate urmtoarele:
- o operaie este un ansamblu de aciuni nentreruptibile, adic nu sunt
supuse ateptrii unor evenimente. Dac acest lucru nu este posibil, trebuie
folosite mai multe operaii;
- o operaie trebuie s fie omogen, adic fr prelucrri alternative
dezechilibrate n interior. O operaie neomogen poate s ascund producerea
unor evenimente interne neprevzute care ar antrena mprirea operaiei n mai
multe operaii omogene;
- trebuie s se obin un rezultat n toate situaiile;
- o operaie este ntotdeauna precedat de cel puin un eveniment;
- o regul de emisie trebuie s coexiste ntotdeauna cu contrariul su (afar
de cazul totdeauna);
b) Reguli legate de condiiile de sincronizare
Cnd se introduce n model o condiie de sincronizare, este preferabil s se
verifice s nu fie ntotdeauna fals i s nu existe posibilitatea ca sincronizarea s
fie activat de evenimente care sosesc la momente diferite, acesta fiind cazul
93

operaiei care depinde de mai mult dect de un singur eveniment i cnd operaia
este declanat de fapt de sosirea unui singur eveniment.

EVENIMENT 1
(A)

EVENIMENT 2
(B)

A B
OPERATIE

Figura 11.32. MCP - Sincronizare nerecomandat

Acest tip de operaie nu este recomandat pentru c prin condiia de
sincronizare A SAU B producerea evenimentului 1 sau a evenimentului 2 va
declana operaia fr nici o ateptare, fapt care contrazice definiia sincronizrii.
n acest sens modelul din Figura 11.33. prezint o anume incoeren pentru c
producerea evenimentului b declaneaz imediat i necondiionat operaia 2,
ceea ce nseamn c operaiile 1 i 2 sunt n realitate una singur. Este de preferat
n acest caz modelul din Figura 11.34.
EVENIMENT 1
(A)

OPERATIE 1
ACTIUNE 1
ACTIUNE 2

EVENIMENT 2
(B)

OPERATIE 2
ACTIUNE 4
ACTIUNE 3

EVENIMENT 3
(C)

94

Figura 11.33. MCP cu incoerene

EVENIMENT 1
(A)

OPERATIE 1
ACTIUNE 4
ACTIUNE 3
ACTIUNE 1
ACTIUNE 2

EVENIMENT 3
(C)

Figura 11.34. MCP corectat

12) reguli legate de funcionarea unui MCP
MCP nu este numai un model static de reprezentare a prelucrrilor, dar
este n acelai timp un model dinamic a crui funcionare este supus anumitor
reguli care depind n cea mai mare parte de context. Se vor aborda numai cazurile
EVENIMENT
1
EVENIMENT
2 sau nedeterminat,
EVENIMENT
3
n
care funcionarea
modelului este
imposibil
adic vor fi
(A)

(B)

(C)

abordate noiunile de conflict i de ciclu.

a) Noiunea de conflict

Se spune c exist un conflict relativ la un eveniment dac acest eveniment

contribuie la mai multe sincronizri. Astfel urmtorul MCP prezint o situaie
conflictual:

A B
OPERATIE 1

BC
95

OPERATIE 1

Figura 11.35. MCP cu conflict

Apariia evenimentului 2 va putea ntr-un mod nedeterminat s contribuie
la activarea operaiilor 1 i 2. Acest conflict poate fi rezolvat n dou feluri:
- cardinalitatea producerii evenimentului 2 este 2 i n acest caz cele dou
apariii ale evenimentului 2 sunt folosite n cele dou sincronizri;
START de participare ale evenimentului 2 la cele dou operaii sunt
- condiiile

exclusive.

(D)

b) Noiunea de ciclu

DC

Cnd o operaie are ca eveniment declanator un eveniment pe care ea l

OPERATIE 1
produce nemijlocit sau prin intermediul
mai multor operaii, ne gsim n prezena

unui ciclu.
Folosirea ciclurilor, cu condiia s fie valide, este o tehnic ce permite s
se reduc sensibil mrimea MCP-ului. Un astfel de ciclu (Figura 11.36.) este
controlat i condiiile sale de pornire i de terminare trebuie s fie clare. Astfel
pornirea ciclului
se face cu 3ajutorul
evenimentului
startSTOP
i oprirea se face cu
EVENIMENT
1
EVENIMENT
(B)
(A)
(E)stop. Aceste evenimente
ajutorul evenimentului
nu sunt fictive,
dar corespund

n general n practic evenimentelor care introduc restricii temporale de tipul:

nti ale lunii, nceputul perioadei, 15 ale lunii ...
Validarea modelelor

B non A

Validarea modelelor are ca obiectiv sinteza ntre analiza datelor i analiza

OPERATIE 2

prelucrrilor. Ea permite verificarea ntre MCD i MCP.

Verificarea acestei coerene are ca regul esenial verificarea ca toate
entitile i asociaiile MCD-ului s fie utilizate de cel puin o operaie a MCP.

EVENIMENT
2
96
(C)

Figura 11.36. MCP cu ciclu

Entitatea sau asociaia trebuie atunci s fie asociat unui eveniment
declanator sau rezultant, sau s intervin ntr-o regul de gestiune sau un calcul.
Cnd lipsa coerenei este constatat se poate interveni asupra MCD.
Aceasta se poate traduce prin:
- adugarea de proprieti care reprezint informaii a cror necesitate nu a
fost bnuit;
- adugarea de noi asociaii care stabilesc dependene ntre entiti care nu
erau corect precizate.
Asocierea modelului datelor cu modelul prelucrrilor este unica operaie
care permite validarea MCD. Operaia de validare permite trecerea de la un MCD
brut la un MCD validat.
97

U11.7. Modelul organizaional al prelucrrilor

Anumite concepte au fost definite la modelul conceptual al prelucrrilor,
deci se vor prezenta numai conceptele noi specifice MOP.
1) procedura
O procedur este o succesiune de faze aparinnd aceluiai proces i
executat de actori. Este un subansamblu al unui proces din MCP declanat de unul
sau mai multe evenimente.
MOP trebuie s fie stabilit cu grija cci el constituie prima viziune global
i coerent a sarcinilor efectuate de ctre actori, schimburile dintre actori, datele la
care fac apel actorii i restriciile organizaionale.
2) actorii
Un actor este o entitate organizaional nsrcinat s efectueze un anumit
numr de faze. Un actor aparinnd domeniului studiat este numit actor intern, iar
n caz contrar este numit actor extern. Actorii sunt coloanele principale n MOP.
O coloan actor dintr-o procedur constituie o procedur actor. Astfel
fiecare procedur actor trebuie s pun n eviden contribuia actorului n cadrul
unui proces dat. Procedura actor cuprinde ansamblul sarcinilor efectuate de ctre
un actor, MOP permind astfel stabilirea lucrrilor executate de fiecare actor.
3) faza
O faz este o nlnuire nenteruptibil de task-uri cu aceiai periodicitate,
executate de un actor intern sau extern. O faz este reprezentat grafic prin
simbolul:

A B
NUMELE FAZEI I
TASK 1
TASK 2
CONDITIE 1

CONDITIE 2

Figura 11.37. Faza

98

Acest formalism permite s se vizualizeze imediat:

- denumirea fazei;
- numele prelucrrilor sau task-urilor care compun faza;
- condiiile de sincronizare ale evenimentelor declanatoare;
- regulile de emisie ale evenimentelor rezultante.
n plus, o faz relev caracteristicile urmtoare:
- natura sau tipul prelucrrii;
- derularea prelucrrii;
- locul unde se desfoar.
O faz poate utiliza una sau mai multe tabele ale unui MLD, pentru
consultare, creare, modificare sau tergere.
4) tipul unei faze
Tipul unei faze este gradul su de automatizare. O faz este manual sau
automat. O faz poate fi n ntregime automat sau interactiv.
5) derularea unei faze
Derularea unei faze se caracterizeaz prin periodicitatea sa i prin durata
sa. Pentru durat se va indica ora de nceput i durata maxim a fazei.
6) locul de desfurare a activitii
Locul de desfurare a activitii nglobeaz conceptul de actor cruia i se
atribuie caracteristici organizaionale. Aceste caracteristici sunt tipul locului de
desfurare, responsabilul i resursele.
Tipul locului reprezint ansamblul locurilor unde aciunile unei operaii
conceptuale se pot efectua.
Resursele sunt ansamblul mijloacelor care permit realizarea anumitor
aciuni ale unei operaii. Resursele pot fi consumabile sau reutilizabile.
Caracteristicile legate de desfurarea unei faze sunt indicate n coloana
perioad a MOP iar tipul este indicat n coloana tip. Actorul sau locul de
desfurare a activitii relativ la o faz este indicat prin coloana unde figureaz
faza. La fiecare operaie conceptual din MCP i corespunde una sau mai multe
faze.
7) task
O faz este descompus n task-uri. Un task reprezint o funciune
elementar. Un task poate folosi una sau mai multe reguli de organizare.
Conceptul de task este foarte important pentru c el st la baza
dezvoltrilor ulterioare.
99

8) eveniment
Conceptul de eveniment este acelai care a fost definit n MCP, cu
deosebirea c noiunea cuprinde i alte tipuri de evenimente care mbrac mai ales
aspectul organizaional (introducerea unei comenzi, decizia superiorului etc.).
Aceste evenimente, iniiate prin regulile de organizare, vor avea un efect
deloc neglijabil asupra mpririi operaiilor conceptuale n faze.
9) reguli de organizare
O regul de organizare decurge dintr-o alegere organizatoric. O regul de
organizare poate fi aplicat unuia sau mai multor task-uri. Ele corespund adesea
unei reguli de gestiune creia i se d o dimensiune organizatoric.
Exemplu: O regul de gestiune spune c orice client trebuie s fie
solvabil. La nivel organizaional, se mbogete aceast regul preciznd modul
de calcul prin care s se permit verificarea solvabilitii clientului. Astfel, orice
regul de calcul poate fi o regul organizaional.
10) modul
Conceptul de modul permite s se arate cu ce mijloc (n general
informatic) poate s se execute un task. Un modul const din: un ecran de
culegere, un program de editare etc.
Un acelai modul poate fi utilizat de unul sau mai multe task-uri. Un
modul poate utiliza unul sau mai multe tabele ale unui MLD, n consultare, creare,
modificare sau tergere.
Reguli de concepere a unui MOP
MOP poate fi dedus din MCP. Analiza restriciilor organizaionale
condiioneaz n ntregime trecerea de la MCP la MOP. El se caracterizeaz prin
luarea n considerare a restriciilor organizaionale. Se trece ntr-adevr de la un
ansamblu de lucrri finalizate (operaiile conceptuale), la un ansamblu de lucrri
organizate (task-urile), avnd numeroase restricii organizaionale.
Metoda va consta n analiza restriciilor organizaionale i n mprirea
fiecrei operaiuni conceptuale.
1) Analiza restriciilor organizaionale
Analiza restriciilor organizaionale va permite punerea n eviden a
noilor actori i a noilor evenimente.
Evenimentele unui MOP pot fi conceptuale sau numai organizaionale. Un
eveniment este conceptual dac el decurge direct dintr-un MCP i este
organizaional n caz contrar.
100

Evenimentele organizaionale pot fi purttoare sau nu de date. n cazul n

care ele sunt purttoare de informaii, ele fac obiectul unei descrieri, care va servi
la validarea modelelor de date. n cazul cnd ele nu sunt purttoare de date,
acestea sunt evenimente de tipul resurs disponibil i nu este necesar s se
reprezinte n MOP. n acest caz, se vor regsi n coloana perioad sau tip.
2) mprirea fiecrei operaiuni conceptuale
Punerea n eviden a unor noi actori i/sau a unor noi evenimente va
permite mprirea fiecrei operaii conceptuale n faze. Fiecrei operaiuni
conceptuale din MCP i va corespunde:
- o faz unic n MOP; este cazul unei operaii conceptuale care poate fi
complet executat de un actor ntr-o aceiai unitate de timp;
- mai multe faze n MOP; este cazul unei operaii conceptuale care trebuie
s fie mprit n mai multe subansamble de periodiciti diferite pentru unele
aciuni sau o mprire rezultnd dintr-o restricie organizatoric.
Pentru mai buna descompunere a unei operaii conceptuale, este necesar s
se procedeze la o analiz ascendent plecnd de la rezultate spre evenimente.
Astfel, o operaie conceptual d ntotdeauna cel puin o faz de producere
a unui rezultat. Eventual, dac sunt necesare calcule prea lungi pentru producerea
rezultatului se poate defini o faz de calcul specific. Se vor distinge attea faze de
achiziie de date cte fluxuri informaionale necesit o introducere de date.
Ansamblul fazelor astfel obinute, prin descompunerea procedurii
funcionale, pot fi eventual din nou combinate dac:
- la ele nu particip dect un singur actor;
- nu necesit dect resurse identice;
- nu au loc dect n acelai moment;
- nu sunt supuse unei ateptri de natura organizaional.
n cursul descompunerii unei operaii conceptuale, este frecvent obinerea
unei faze care a fost deja determinat anterior. n acest caz nu se va reine dect o
singur faz.
Se constat c metoda nu const n analiza restriciilor organizaionale i
apoi mprirea fiecrei operaii conceptuale, ci mai curnd mprirea operaiilor
n acelai timp cu analiza restriciilor organizaionale.
Orice faz trebuie s fie caracterizat de o unitate de loc, o unitate de timp
i o unitate de resurse.

101

Validarea modelelor are ca obiectiv sinteza ntre analiza datelor i analiza

prelucrrilor. Ea permite verificarea coerenei ntre MLD i MOP. Verificarea
acestei coerene se efectueaz la dou niveluri:
- toate tabelele din MLD sunt necesare;
- orice coloan din MLD este utilizat de cel puin o operaie din MOP.
Coloana trebuie s figureze la un eveniment declanant sau rezultant, sau
s intervin ntr-o regul organizatoric.
Un al doilea nivel mult mai detaliat care verific dac accesul la o tabel
este necesar n raport cu obiectivele task-ului care se efectueaz.
Cnd se constat o lips de coeren poate fi necesar intervenia n
modelele de date i chiar modificarea la nivelul MCD. Aceasta se poate traduce
prin:
- adugarea de proprieti care reprezint informaii a cror necesitate nu a
fost bnuit; aceasta poate conduce la o anumit denormalizare a modelului de
date;
- adugarea de noi asociaii care stabilesc dependene ntre entiti care nu
erau corect precizate;
- adugarea la nivelul MLD a unor noi indeci care asigur timpi de
rspuns mai bun.

U11.8. Modelul operaional al prelucrrilor

Scopul modelului operaional al prelucrrilor (MOpP) este de a descrie
arhitectura programelor care vor fi realizate pornind de la fazele descrise n MOP.
Aceste programe vor fi: programe batch sau programe de prelucrare a
tranzaciilor (pentru faze n timp real).
Se recomand respectarea ctorva reguli n funcie de tipul programelor.
Astfel pentru programele batch:
- mprirea acestora dup periodicitatea de prelucrare;
- mprirea dup tipul de prelucrare (validare, calcul, actualizare, editare).
Pentru prelucrarea tranzaciilor se recomand urmtoarele reguli:
- fiecrui ecran i va corespunde o tranzacie;
- fiecare tranzacie va fi structurat n afiare ecran, introducere date,
prelucrare ecran (normalizare I.S.O.);
102

- stabilirea normelor ergonomice pentru afiarea ecranului i introducerea

datelor;
- mprirea prelucrrilor n validri, calcule, actualizri i editri.
Descrierea nivelului operaional al prelucrrilor va evolua foarte mult n
urmtorii ani prin utilizarea limbajelor de baze de date ca SQL i prin
generalizarea programrii orientate pe obiecte.

UNITATEA 12
METODA MERISE CICLUL DE DECIZIE
Durata medie de studiu individual - 2 ore

Cuprins:

pag.

U12.1. Scopul i obiectivele unitii ...........................................................

U12.2. Ciclul de decizie ...............................................................................
U12.3. Test de autoevaluare .......................................................................
U12.4. Rezumat ...........................................................................................
Bibliografie minimal .................................................................................
Rspunsuri i comentarii la testul de autoevaluare .................................

200
200
208
209
209
209

U12.1. Scopul i obiectivele unitii

n aceast tem vei nva urmtoarele concepte fundamentale:
- ciclul de decizie;
- ierarhia deciziilor;
- procese de decizie.

U12.2. Ciclul de decizie

Ciclul de decizie cuprinde toate deciziile luate pe parcursul desfurrii
proiectului, mai generale la nceput i apoi din ce n ce mai precise. Deciziile

103

globale trebuie luate de directorul general, dar la fiecare nivel trebuie consultat
personalul implicat. Ierarhia deciziilor care se pot lua este urmtoarea:
- mprirea sistemului informaional n domenii;
- orientrile generale n ceea ce privete gestiunea, organizarea i soluiile
tehnice;
- planificarea dezvoltrii;
- alegerea ntre procedurile manuale i automate;
- alegerea procedurilor ce se vor executa n timp real;
- determinarea locurilor de munc i a sarcinilor respective;
- conceperea ecranelor, listelor etc.
n responsabilitatea conducerii cade n mod normal iniierea proiectului i
ulterior terminrii acestuia evaluarea reuitei proiectului. Aceast observaie ne
duce spre ideea c o corect abordare a ciclului de decizie trebuie nceput de la
nivelul sistemului informaional, prin mprirea sistemului n zone de interes i
prin stabilirea orientrilor generale.
Totodat trebuie fcut o diferen ntre atitudinea decizional pasiv, care
las lucrurile s evolueze n mod natural i o politic managerial consecvent
n direcia informatizrii.
Din constatrile practice se observ o etapizare natural n introducerea
prelucrrii automate a datelor.
Aceast etapizare depinde de condiiile obiective existente n economie:
- starea tehnologiei hardware;
- starea tehnicilor de rezolvare a problemelor fundamentale;
- riscul pe care-l implic deficienele de organizare.
Dei tehnologia hardware este uniform n cea mai mare parte a lumii,
tehnica rezolvrii problemelor fundamentale, variaz de la industrie la industrie i
de la ntreprindere la ntreprindere.
Valoarea riscului pe care-l implic, deficienele de organizare variaz de la
caz la caz. Pragul de la care o anumit activitate devine riscant este o problem
subiectiv i se stabilete n funcie de nivelul acceptat al probabilitii de
producere a evenimentelor nefavorabile.
Dar miza depirii eventualelor dificulti este mare deoarece un succes
mai nsemnat realizat de o ntreprindere va strni un ecou rapid n rndul
celorlalte.

104

Etapizarea ptrunderii calculatoarelor ntr-o ntreprindere, sintetizat pe

baza mai multor constatri practice este urmtoarea:
1. aplicaii de baz ale calculatoarelor;
2. aplicaii intradivizionare ale calculatoarelor;
3. aplicaii interdivizionare ale calculatoarelor;
4. aplicaii avansate ale calculatoarelor.
Aceast etapizare nu presupune o intervenie coordonat n direcia
informatizrii. Bineneles c n cazul unei opiuni ferme de realizare a unui sistem
informatic se va putea aborda direct etapa final n utilizare a calculatoarelor.
1. Prima arie de aplicaii ntr-o ntreprindere productiv este aceea n care
se cere un efort individual, sau cel mult, cooperarea ntre grupuri mici.
Ca rezultat, aplicaiile iniiale sunt limitate la proiecte de proporii i
complexiti reduse. n plus hard-ul se alege dintre cele mai ieftine alternative, din
cauza tendinei normale de limitare a riscului financiar n introducerea unei
tehnologii noi i nu prea cunoscute.
Accentul n primele aplicaii se pune pe nlocuirea muncii umane n
activiti de sortare, raportri scrise i rezolvri de ecuaii.
2. O alt etap este aceea cnd se utilizeaz personalul dintr-un singur
compartiment i este caracterizat prin ntreinerea i punerea la zi a fiierelor i
printr-un nivel mai ridicat al complexitii.
Aplicaiile includ state de plat, stocuri, registre contabile generale,
balane, calculul dividendelor, evidena mijloacelor fixe etc.
3. Cea de-a treia etap se caracterizeaz prin ncercarea de rezolvare a unor
probleme economice care cer un numr limitat de cooperri ntre sectoare.
Exist un interes crescnd pentru optimizarea sistemelor complexe i de
regul, majoritatea ntreprinderilor urmresc s ctige maximum prin optimizarea
planificrii i utilizrii echipamentelor electronice.
Dup cum sarcinile de lucru cresc pentru echipamentele de calcul ale
ntreprinderii, exist tendina de a favoriza aplicaiile mai urgente, astfel nct apar
cozi de ateptare n vederea punerii la punct a celorlalte aplicaii. O rezolvare a
acestei probleme este descentralizarea responsabilitilor de calcul.
n aceast etap se ncearc i cteva din aplicaiile cele mai simple de
comand a proceselor de producie. Comanda proceselor i-a ctigat o larg
apreciere n industriile unde produsele sunt elaborate fie n flux continuu sau
proces intermitent i unde controlul permanent al materiei prime, mpreun cu
105

controlul condiiilor de funcionare, determin mbuntirea produselor i

reducerea cheltuielilor de producie.
4. La sfritul etapei a treia devine clar pentru multe ntreprinderi c
apropierea treptat de rezolvarea problemei i de pstrarea nregistrrilor nu ine
pasul cu cerina ntreprinderii pentru informare i rspuns. Un rspuns la aceast
problem este implementarea unui sistem informatic integrat. n industriile care au
o producie de mas, cu utilizarea unei tehnologii omogene, aceste sisteme pot fi
introduse fr prea mari dificulti. Totui, majoritatea ntreprinderilor productive
au o tehnologie extrem de diversificat n ceea ce privete primirea comenzilor,
achiziionarea de materii prime, distribuirea, depozitarea i mecanismul de
desfacere. Un element simplu ce exemplific eterogenitatea schimburilor de
informaii este numrul de formulare diferite utilizate n interiorul ntreprinderii.
Cu toate c aceste sisteme sunt deseori denumite sisteme informatice de
conducere, elementul lor comun este necesitatea unei baze de date integrate.
n opoziie cu atitudinea pasiv se afl aciunea contient prin care
strategia ntreprinderii trebuie s beneficieze de o serie de orientri generale care
s-i permit ctigarea unor avantaje competitive. n acest sens modelul urmtor
permite corelarea scopurilor ntreprinderii cu avantajele poteniale dar i cu efortul
necesar.
Conductorul este pus aadar n faa unei probleme foarte importante i
deloc uoar. Este evident c are nevoie de o tehnologie informatic, dar care
aplicaii informatice din cele existente sau dintre cele oferite pe pia au o
importan strategic i pot influena n mod decisiv potenialul firmei? El trebuie
s tie cnd tehnologia informatic este un element critic pentru ntreprinderea sa.
O cale posibil pentru o investigaie de acest fel o constituie Modelul strategic tip
gril (The Strategic Gril Model; Figura 11.1.) care permite determinarea
importanei i impactului strategic prin situarea firmei ntr-un cadran cu dou
dimensiuni:
- impactul strategic al sistemelor existente;
- impactul strategic al dezvoltrii sistemelor (sistemele viitoare).
n cadranul 1 suport (de sprijin) sistemele informatice sunt vzute ca
avnd un impact redus asupra activitii firmei i tind s rmn aa i n viitor.
Dependena activitii firmei de sistemele informatice este considerabil sczut.
Tehnologia informatic este perceput ca un sprijin funcional fr s implice

106

investiii semnificative i sunt coordonate de la un nivel ierarhic mijlociu i

sczut.
n cadranul 2 factory (de fabricaie) dei sistemele informatice sunt
importante n afacerile firmei ele nu sunt n centrul dezvoltrii strategice. Un
posibil exemplu l-ar putea constitui o ntreprindere n care producia este condus
prin sisteme de control n timp real dar viitoarele dezvoltri ale sistemului
informatic nu vor influena semnificativ activitatea firmei.
n cadranul 3 turnaround (revenire) sistemele informatice nu au fost
foarte importante n trecut dar realizarea de noi sisteme a nceput s devin critic
pentru activitatea viitoare a firmei. Firma realizeaz aceast schimbare de optic
nu numai datorit unei creteri a activitii ci mai ales pentru meninerea pe pia
ntr-un mediu economic perturbat. Se poate exemplifica aceast situaie cu o
ntreprindere n care planurile de dezvoltare sunt puternic legate de tehnologia
informatic.
n cadranul 4 strategic se reprezint firmele a cror activitate depinde n
mod critic de existena sistemelor informatice. O performan sczut ori cderea
acestor sisteme poate fi cauza unor disfuncionaliti majore. Mai mult,
dezvoltarea sistemului informatic este critic pentru activitatea firmei i trebuie s
cad n sarcina conducerii executive a firmei. Rolul important al tehnologiei
informatice este remarcat i de volumul semnificativ de investiii din acest
domeniu. Exemple de firme din acest cadran sunt bncile, companiile de asigurri,
firme de brokeraj, ziare, institute de cercetri de marketing etc. Situarea
ntreprinderii n acest cadran trebuie s vizeze lanul producie-desfacere, existnd
posibilitatea ca diferite alte activiti s se gseasc n celelalte cadrane.
maxim

Impactul
strategic al
sistemelor
existente

FACTORY

STRATEGIC

SUPPORT

TURNAROUND

minim
minim

maxim
Impactul strategic al sistemelor viitoare

Figura 12.1. Modelul strategic gril

107

Acest model permite o privire static asupra prezentului i viitoarei

dependene de sistemele informatice. De altfel este important de urmrit micarea
n timp n interiorul grilei. Trecerea din cadranul suport n strategic se poate
face sub presiunea progresului tehnologic, a competiiei de pe piaa sau a unor noi
obiective n dezvoltarea firmei.
La fel de important este aciunea conductorului i la nivelul dezvoltrii
componentelor sistemului informatic, cu observaia c n acest caz este vorba de o
conducere de nivel inferior. O proast conducere poate afecta succesul proiectului
mai mult dect ali factori, dar acest fapt, n mod surprinztor, este mai puin
neles n procesul de dezvoltare a software-ului. Toate modelele anterioare ale
ciclului de via nu trateaz conducerea ca un model distinct ci privesc conducerea
proiectului ca o parte inseparabil a procesului de dezvoltare a software-ului.
Pentru clarificarea acestui aspect s-a recurs la urmtoarele diagrame care
evideniaz implicarea factorului de conducere n realizarea proiectului (Figura
12.2.).
La acest nivel de prezentare condiia iniial este iniierea proiectului i
rezultatul este proiect realizat. Resursele reprezint tot ceea ce s-a consumat
pentru realizarea proiectului. Pentru furnizarea mai multor amnunte aceast
diagram poate fi detaliat pentru ase etape ale ciclului de via al proiectului:
analiza

preliminar,

proiectarea

logic,

proiectarea

tehnic,

construcia,

implementarea i testarea.
Resurse (timp, for de munc, finanare, ...)

Iniierea proiectului

Conducerea
proiectrii

Proiect realizat

Figura 12.2. Conducerea proiectului

n figura 12.3. este prezentat modelul conducerii procesului pe parcursul
ciclului de via al sistemului. Modelul este numit model comportamental sau
model de conducere pe baz de evenimente. El arat strile n care se poate afla
sistemul i este folosit pentru descrierea dependenelor, pentru alocarea resurselor
i pentru finanare.

108

109

110

111