SISTEMUL ECONOMIC (Modulul 1. U 1.

6)

Sistemul este un ansamblu de elemente dependente ntre ele ce opereaz ca un ntreg pentru
realizarea unui scop comun.
Sistemul este caracterizat prin faptul c e legat de mediul ambiant, are o anumit structur,
funcioneaz dup anumite reguli, urmrete un anumit scop.
Sistemul economic definete componente i ansambluri economice din punct de vedere al structurii
i al complexitii funciilor pe care le realizeaz. Astfel sistemele economice pot fi grupate n sisteme
economice simple i sisteme economice complexe sau macrosisteme.
Sistemul complex reunete ntr-o structur ierarhic un ansamblu de elemente considerate subsisteme
cu legturi reciproce. Este caracterizat prin:
existena unor componente separate pentru care se pot stabili scopuri funcionale distincte, dar subordonate
scopului ntregului sistem;
existena unor legturi funcionale ntre componente i legturi cu exteriorul;
prezena n sistemul economic a oamenilor, mainilor i a mediului nconjurtor, care asigur funcionarea
sistemului;
supunerea sistemului unor legi economice obiective.
Orice sistem economic se caracterizeaz prin;
- ansamblul intrrilor
- ansamblul ieirilor
- structura i starea intern
INTRRI

STRUCTURA

IEIRI

Sistemul economic este ansamblul de elemente interdependente prin intermediul crora se

realizeaz obiectul de activitate al unei uniti economice.
Intrri de resurse:
materiale
umane
financiare
informaionale

Transformrile sunt atribuiile:

managerului
planificrii
Ieirile care reprezint:
organizrii tehnologice
produse sau servicii
conducere
profit sau pierdere
control

Privit independent de structurile ierarhice superioare din care face parte o unitate economic este
considerat sistem i privit n raport cu structurile ierarhice superioare este un subsistem (structura ierarhic
din care face parte fiind considerat macrosistem).
Un sistem economic complex cuprinde:
1. Subsistemul de conducere format din ansamblul de specialiti care cu ajutorul unor metode i tehnici
specifice prognozeaz, planific, decid, organizeaz, coordoneaz, urmresc i controleaz funcionarea
sistemului condus n scopul ndeplinirii obiectivelor stabilite.
2. Subsistemul condus (de baz, operaional) este ansamblul de resurse materiale, umane, financiare i
ansamblul organizatoric, tehnic i funcional care realizeaz efectiv obiectul stabilirii prin decizii.
3. Subsistemul informaional este ansamblul informaiilor, fluxurilor i circuitelor informaionale, precum
i totalitatea mijloacelor, metodelor i tehnicilor prin care se asigur prelucrarea informaiilor necesare
sistemului de conducere i decizie.
Prin sistemul informaional se asigur legtura permanent i necesar ntre sistemul de conducere i
sistemul condus n dublu sens: prin prelucrarea i transmiterea deciziilor de la sistemul de conducere ctre
sistemul condus i prin nregistrarea, prelucrarea i transmiterea informaiilor privind starea i dinamica

sistemului condus, de la acesta ctre sistemul de conducere. Structura unui sistem economic este redat n
figurile urmtoare:

Un sistem economic este un sistem viabil. Aceasta presupune c toate fluxurile de resurse, s-au
tehnologice, dintr-un sistem economic, au la baz desfurarea unor activiti umane, implicnd, pe de o
parte, o succesiune de procese i fluxuri informaionale, iar pe de alt parte, conducnd la generarea
permanent de noi informaii i fluxuri informaionale.
Sistemul informaional asigur gestiunea tuturor informaiilor din cadrul unui sistem economic,
folosind toate metodele i procedeele de care dispune. Informaiile sunt sesizate i nregistrate n cadrul unui
sistem economic la nivelul unor verigi organizatorice i funcionale care se numesc posturi de lucru. O
secven de mai multe posturi de lucru, logic nlnuite, formeaz un circuit informaional.
Un post de lucru se individualizeaz prin urmtoarele elemente:
- Date de intrare
- Timp de staionare
- Operaii de prelucrare
- Date de ieire
Ansamblul informaiilor i deciziilor necesare desfurrii unei anumite activiti sau operaii care se
transmit ntre dou posturi de lucru, formeaz un flux informaional.
ntre circuitul informaional i fluxul informaional exist o strns interdependen n sensul c
circuitul informaional reflect traseul i mijlocul care asigur circulaia unei informaii de la generarea ei i
pn la arhivare, iar fluxul informaional reflect ansamblul informaiilor vehiculate, necesare unei anumite
activiti. Vehicularea acestora se realizeaz pe traseele definite de circuitele informaionale.
Sistemul informaional, cuprinde ntr-o concepie unitar, circuitele informaionale i fluxurile
informaionale, la care se adaug metodele i tehnicile de prelucrare a acestora.
Sistemul informatic este o component a sistemului informaional i anume, acea parte a acestuia
care preia i rezolv sarcinile de culegere, prelucrare, transmitere i stocare a datelor, cu ajutorul sistemelor
de calcul.
Pentru a-i ndeplini rolul n cadrul unui sistem informaional sistemul informatic cuprinde
ansamblul tuturor resurselor, metodelor i tehnicilor, prin care se asigur prelucrarea automat a datelor.
Aceste resurse sunt:
- Ansamblul de echipamente (HARDWARE)
- Sistemul de programe (SOFTWARE), care cuprinde programele sistemului de operare i
programele de aplicaii
- Baza de date
- Ansamblul de personal i cadrul organizatoric
Procesul de prelucrare automat a datelor, n cadrul unui sistem informaional, reprezint procesul
prin care datele sunt supuse operaiilor de culegere, prelucrare, transmitere i stocare.
Culegerea datelor const n sesizarea acestora la locurile unde sunt generate, i transpunerea lor pe
suporturi adecvate prelucrrii automate. La acest moment datele se numesc date primare.
Prelucrarea datelor const n transformarea acestora din date primare n date finale, n urma
parcurgerii unei succesiuni de operaii impuse de cerinele utilizatorilor i specificul echipamentelor de
calcul i a tehnologiei de prelucrare.
Transmiterea datelor asigur vehicularea att a datelor primare de la sursele generatoare, ctre
sistemele de prelucrare automat ct i a rezultatelor prelucrrilor ctre beneficiari.
Stocarea datelor const n memorarea i pstrarea (arhivarea) acestora, pe suporturi de memorie
specifice, n scopul unor consultri i prelucrri ulterioare.

CONCEPTUL DE ANALIZ SISTEMIC (Modulul 2, U 6.3)

Gndirea analitic, ca abordare preferenial n managementul tradiional, i-a epuizat rapid resursele
cognitive i normative ntruct, prin secionarea structurilor complexe n componente discrete, pentru a le
analiza n afara relaiilor i interdependenelor reale i prin reconstituirea hermeneutic a ntregului se
obinea, n ultim instan, o imagine deformat, artificial i cu o valoare practic destul de sczut1.
Descompunerea cunoaterii ntr-o succesiune liniar de cauze i efecte, principii i consecinele lor
logice, specific demersului raional-analitic, duce, mai curnd sau mai trziu, n impas. Divide et impera
mparte i stpnete se ciocnete rapid de o problem nc imposibil de rezolvat: ct de departe se poate
avansa n fragmentarea analitic fr a mutila imaginea ntregului? n gndirea analitic pdurea deseori nu
se vede din cauza copacilor!
Iniial gndirea sistemic n economie s-a orientat spre explorarea sistemelor stabile homeostabile
avnd ca principal instrument modelul sistemului n echilibru mecanic, stabilitatea cruia este meninut
prin opoziia manifestat fa de orice schimbri percepute ca abateri accidentale de la programul de
funcionare stabilit. Se convenea c procesele care decurg n interiorul unui sistem nu necesit explicaii, ci
interpretri complete, n funcie de cauz i efect, prezentnd relaiile dintre pri ntr-o manier holistic, ca
pe un ntreg. Msurrile, observrile i experiena sunt organizate astfel nct s poat surprinde ce intrri i
ce anume ieiri produc. Acest mod de raportare la realitate permite reducerea proceselor complexe la
simple procese de reglare2. Pentru analiza funcionrii sistemului se folosete conceptul de cutie neagr
(black box) cu ajutorul cruia sistemul studiat este descris ca un ansamblu unitar i nedifereniat structural,
fcndu-se abstracie de procesele sale interne.
Ulterior abordarea sistemic a dezvoltat, pe baza studiului buclelor de reacie sau a conexiunilor
inverse (feedback), modele homeostatice caracterizate prin existena unor circuite informaionale care au ca
punct de plecare anumite intrri (input-uri) pentru un proces care modific starea iniial a sistemului ntr-o
singur direcie sau spre o singur ieire. n aceste modele managementul apare ca reglare pe baz de
feedback a proceselor, prin alocarea resurselor disponibile n contextul meninerii sub control a tuturor
secvenelor de funcionare necesare pentru obinerea rezultatelor proiectate n structura praxiologic a
obiectivului sistemului. n aceast familie de modele, decizia managerial este definit ca exercitarea
controlului asupra dinamicii ntregului sistem. Limitele acestor modele rezult din incapacitatea de a oferi
explicaii privind schimbrile calitative din sistem, respectiv trecerea elementelor i a ntregului sistem de la
o anumit structur funcional (ordine) la alta. Caracterul static al acestor modele se datoreaz accentului
pus pe conexiunea invers negativ, care asigur stabilitatea sistemului, realiznd n acest scop reglarea
elementelor i funciilor.
Etapa contemporan de evoluie a metodologiei abordrii sistemice este dominat de modele
adaptabile cu autoorganizare. Aceste modele se bazeaz pe conexiunea invers pozitiv, destabilizatoare, dar
care realizeaz cutarea unor noi forme i combinaii funcionale: nu toate perturbrile trebuie considerate
disfuncii. Multe din aa-zisele patologii funcionale, n anumite condiii, pot constitui surse de creativitate
i inovaie, catalizatoare ale reorganizrilor sistemului pe noi repere funcionale.
Modelele din aceast generaie ofer o viziune mai bogat, mai complex despre schimbarea
organizaional a sistemelor economice, artnd c trecerea spre o nou ordine (stare), eventual una calitativ
superioar, este provocat nu doar de intrri sau de factorii externi, ci de o combinaie de fore att exogene,
ct i endogene, care se alimenteaz i se ntrein reciproc. n consecin, mediul are un rol determinant n
modelarea configuraiei structurale i a comportamentelor sistemului. Procesele de autoorganizare formeaz
mecanismele prin care dinamica intern este conectat la schimbrile din mediu, iar crizele i puseurile de
dezordine sunt convertite n bazele unui nou mod de organizare. Funcionarea sistemelor economice reale
are loc prin cuplarea unor fluxuri de reglare fie prin fluctuaii ntre perioadele de relativ stabilitate i
perioadele de restructurare, fie prin autotransformarea sistemului nsui, conservndu-i profilul normativ.
Aceste trei generaii de modele n gndirea sistemic nu numai c se succed n timp, ci alctuiesc un
ansamblu de argumente complementare care spulber iluzia c putem controla complexitatea organizaional
a fenomenului economic exclusiv prin abordri inginereti: n termeni de precizie, randamente i
1 Buzrnescu, t., Sociologia conducerii, Editura de Vest, Timioara, 2003, p. 248.
2 Blum, R., Un al treilea drum. Principii organizatorice ale economiei de pia, Editura Universitii Al. I. Cuza, Iai, 1994, p.
70.

parametri de funcionare determinai strict cantitativ. Evenimentele i procesele din organizaiile economice,
ca fapte sociale, fiind grupate n funcii care iau valori ntr-un interval de autoritate, se preteaz mult mai
bine unor abordri calitative, inclusiv cu ajutorul teoriei sistemelor vagi (fuzzy) o direcie nc insuficient
valorificat.
inndu-se cont de complexitatea deosebit a celor mai multe sisteme existente n natur, economie
etc., studierea sistemelor se face ntr-o manier aparte numit abordare sistemic.
Abordarea cartezian const n a repera i a izola fiecare subproblem pentru o prelucrare ulterioar.
Prin aceasta nu se va putea rezolva ns ansamblul problemei. Abordarea sistemic propune o viziune unic
i global a problemei de rezolvat.
n loc de a se ncepe analiza prin divizarea sistemului n componente din ce n ce mai mici i mai
uor de stpnit, toate componentele sunt considerate n ansamblul lor (aspect spaial) att pe parcursul
analizei, proiectrii ct i al procesului de conducere (aspect temporal).
De fapt, numai n acest fel este posibil s se neleag i s se anticipeze corect comportarea posibil
a sistemului.
O caracteristic esenial a abordrii sistemice este accentul pe care l pune, n cazul analizei, pe
interdependenele dintre elementele sistemului i pe observarea critic a calitii acestora.
Abordarea sistemic s-a dovedit de mare utilitate n rezolvarea problemelor mari i complexe,
referitoare la oameni i maini. Abordarea sistemic este o noiune care reunete trei activiti importante:
- analiza sistemelor;
- proiectarea (ingineria) sistemelor;
- conducerea sistemelor.
Analiza de sistem poate fi considerat un mijloc de abordare a cercetrii, sau chiar disciplin n sine,
deoarece acest concept a nceput s fie folosit pe scar larg n mai toate domeniile.
Analiza sistemelor presupune parcurgerea urmtoarelor etape:
1. Prima etap const n formularea problemei. Pentru toate lucrrile ulterioare este important ca analistul s
examineze critic formularea problemei de ctre utilizator. Este bine s se aib n vedere c la acest prim
contact ntre analist i utilizator pot apare probleme de comunicare ntre cei doi, datorate unor
incompatibiliti de limbaj. Orice eroare minor n formularea problemei sau orice nelegere eronat poate
genera mari inconveniente prin amplificarea ei cu fiecare etap parcurs.
2. De asemenea este deosebit de important s se examineze minuios formularea obiectivelor pentru c n
acest domeniu sunt posibile inconsecvente: s se maximizeze eficiena concomitent cu ncadrarea n
cheltuielile minime.
3. Adeseori n optimizarea sistemelor apar dificulti cauzate de faptul c este greu sau chiar imposibil s se
analizeze ntreaga problem. Se poate recurge n astfel de situaii la optimizarea fiecrui subsistem analizat,
dar sistemul n ntregul su nu poate fi dect suboptimal fiind necesar deci precizarea clar a limitelor
problemei.
4. Analiza cerinelor utilizatorului const n identificarea i evaluarea necesitilor lui reale.
5. Precizarea criteriilor de msurare a eficienei sistemului trebuie fcut nainte de evaluarea soluiilor
propuse prin stabilirea unui grup de mrimi reprezentative.
6. Analiza funcional se concretizeaz ntr-o list amnunit a funciunilor i aprecierilor care trebuie
ndeplinite. La analizele funcionale o deosebit importan o are reprezentarea grafic n scheme bloc.
7. Pe msur ce se completeaz lista restriciilor care acioneaz asupra sistemului devine posibil cercetarea
efectelor interaciuni lor asupra ntregului sistem. Identificarea restriciilor i evaluarea efectului lor asupra
eficienei sistemului reprezint un alt aspect important.
8. Pe msura avansrii n analiza sistemului se contureaz diferitele soluii posibile care satisfac restriciile
impuse. Obiectivul acestei faze este de a identifica diversele variante fr a adncii analizele privind
cheltuielile pe care le implic. ntr-un sistem informatic, de exemplu, este necesar s se determine gradul n
care hardware-ul i software-ul avute n vedere ofer posibiliti de dezvoltare ulterioar.
9. Dup precizarea variantelor posibile se trece la compararea i evaluarea acestora. Este de dorit ca att
cheltuielile ct i eficiena s fie exprimate bnete.
Proiectarea sistemelor este un proces de concepie tehnic, asociat de obicei cu dezvoltarea sau cu
modificarea important a unui sistem.
Acest proces se mparte n:
- proiectarea propriu-zis a sistemelor; i
- proiectarea operrii sistemelor.

Proiectarea propriu-zis a sistemelor se mparte la rndul ei n:

- proiectarea preliminar;
- proiectarea de detaliu.
La proiectarea preliminar se evalueaz soluiile de proiectare a transpunerii specificaiilor
funcionale precizate n faza de analiz a sistemului i apoi se selecteaz soluia de proiectare.
Proiectarea de detaliu cuprinde transpunerea concepiei de proiectare, conturat n faza de proiectare
preliminar n specificaii de detaliu. Este necesar n aceast faz mprirea lucrrilor pe echipe dar
totodat trebuie s existe un grup de integrare a sistemului care s se ocupe exclusiv de problema asigurrii
funcionalitii corespunztoare a fiecrui subsistem nu numai n parte ci i n cadrul sistemului n ansamblu.
Un aspect oarecum neglijat n tehnica sistemelor este proiectarea operrii lor. Adeseori se consider c
proiectarea s-a terminat odat cu momentul n care sistemul este livrat beneficiarului. Un astfel de punct de
vedere poate contribui la eecul unui sistem tot att de mult ca i proiectarea lui defectuoas. Operarea
sistemelor este uneori neglijat din cauz c proiectanii sunt n mod firesc mai interesai s soluioneze
problemele tehnice ale proiectrii i n mai mic msur problemele legate de limitele fizice i psihice ale
personalului operaional i de ntreinere. n plus concepia de a adapta omul la main a creat obiceiul de a
angaja pentru operare i ntreinere acei oameni ale cror nsuiri fizice i psihice pot fi considerate
compatibile cu caracteristicile echipamentului. Pe msura sporirii complexitii sistemelor, trebuie acordat
o atenie deosebit noiunilor de fiabilitate i mentenabilitate.
Conducerea sistemelor cuprinde stabilirea metodologiei i a structurilor organizatorice pentru
planificarea, directivarea i controlul activitilor de proiectare a sistemelor ca i pentru funcionarea lor.
Conducerea funcionarii sistemelor se numete conducere operaional.
Pe de alt parte, exist conducerea nsi a proiectrii sau dezvoltrii sistemului.
Conducerea sistemelor nu reprezint o faz a proiectrii sistemelor ci este funciunea de comand i control
care se desfoar de-a lungul ciclului de via al sistemului. Cea mai mare contribuie la eficiena
conducerii unui sistem o are identificarea momentelor i criteriilor de efectuare a controlului, astfel nct s
se poat stpnii desfurarea activitilor. Pe lng controlul corespunztor principalelor etape conducerea
trebuie s efectueze o permanent urmrire i coordonare. Acest sistem de control poate fi mai eficient dac:
- se realizeaz previziuni asupra evoluiilor viitoare;
- se planific reexaminri periodice ale proiectelor.
Integrarea sistemului i controlul configuraiei sunt dou activiti de conducere care trebuie s-i
dovedeasc prezena pe parcursul fiecrei faze a proiectrii sistemelor. Pentru integrarea sistemului
conducerea trebuie s asigure compatibilitatea mecanic, electric etc. dar i compatibilitatea informaional.
Controlul configuraiei const din metodele folosite pentru a orienta i urmrii modificrile n diversele
etape ale ciclului de via al sistemului.
Am enumerat mai sus o serie de etape i de probleme pe care trebuie s le urmeze i s le rezolve
analistul de sistem. Analiza de sistem nseamn cunoaterea sistemului, cunoatere care se traduce printr-o
reprezentare la nivel cerebral a sistemului n ansamblul su. De fapt prin analiza 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 deloc uoara i presupune n mod
obligatoriu participarea activ a beneficiarului sistemului.
COMUNICAREA N SISTEMELE INFORMAIONALE (Modulul 2, U 7.2)
Noiunea de informaie este complex i de mare generalitate. La momentul apariiei sale, conceptul
de informaie a suscitat dispute filosofice pe tema caracterului material al acesteia. Norbert Winer spunea:
Informaia este informaie, nu este materie sau energie.
Informaia este un tip deosebit de raport ntre procesele materiale, raport ce nu exist n afara acestor
procese. Se poate afirma c informaia reprezint un atribut fundamental al materiei alturi de mas, cmp i
substan. Informaia ca atribut fundamental al materiei este prezent att n materia vie (informaia
genetic) ct i n cea nevie.
Pentru determinarea riguroas a cantitii de informaie se folosete un aparat matematic bazat pe
elemente din teoria probabilitilor.

Fie un experiment
independente
experimentul

rezultatele sale pun n eviden un numr finit de evenimente elementare

, avnd asociate probabilitile de realizare

. Presupunem c

reprezint un sistem complet de evenimente, adic prin efectuarea sa se va obine cu

siguran unul din evenimentele

, deci
;
. Realizarea unui eveniment nltur o
cantitate de nedeterminare, deci ntruct informaia reprezint o nedeterminare nlturat sensul variaiei
nedeterminrii este inversul sensului variaiei informaiei, unitatea de msur fiind aceiai.
Notnd cu
msura gradului de nedeterminare, care este egal cu cantitatea medie de
informaie furnizat de realizarea unui eveniment se poate scrie:
n anul 1948 Claude Shannon n lucrarea Teoria matematic a comunicaiei a dat expresia cantitii
de nedeterminare (i deci a informaiei):

Shannon a preluat cercetrile unui precursor al su n domeniul teoriei informaiei R. V. Hartley care
nc din anul 1928 a introdus noiunea de cantitate de informaie, definind-o astfel: Informaia obinut prin
precizarea unei variante din cele

echiprobabile este egal cu logaritmul lui

n baza

unde
reprezint probabilitatea de realizare a unei variante. Relaia stabilit de Hartley se obine ca
un caz particular din formula lui Shannon atunci cnd evenimentele sunt echiprobabile:
Msura informaiei calculat cu formula lui Shannon se numete i ENTROPIE
INFORMAIONAL prin analogie cu entropia termodinamic, care msoar de asemenea gradul de
nedeterminare al unui fenomen.
Transferul informaiilor, deciziilor, datelor i cerinelor ntre diferite procese i/sau ntre diferite
sisteme sau subsisteme creeaz o problematic complementar cantitii de informaie: problema
COMUNICRII.
Fie:

Figura 7.1. Modelul comunicrii

unde:

- este emitorul de informaie

- este receptorul de informaie

- este canalul de comunicaie
Caracterul esenial al procesului de comunicare este reprezentat de mesaj i aceast cantitate care
caracterizeaz mesajul - definit ca o secven de semne elementare - este legat de lungimea sa, de
dimensiunile n spaiu i timp ale suportului su, sau ale canalului de transfer (lungimea cuvntului,
suprafaa unui disc, a unui tablou, numrul de semne imprimate), dar mai ales de improbabilitatea ocurenei
(apariiei) sale, adic de combinaia pe care o realizeaz. Aceast cantitate de noutate sau originalitate
transportat de la E la R se adaug la sistemul de cunotine i de experien pe care l au att E ct i R i se
nscrie n memoria lor.

Semnele exist nainte de crearea mesajului sau a actului de comunicare. Este vorba aici de a
constitui un repertoriu, de a le clasa ntr-o ordine n funcie de frecvena de ntrebuinare; n pasul urmtor
vom deduce probabilitatea lor de apariie (de ocuren) i, n consecin, informaia pe care ele o transport.
Informaia depinde deci de repertoriul comun att al transmitorului ct i al receptorului. Aceast msur
presupune faptul c mesajul este decompozabil n mod obiectiv ntr-o serie de semne identificabile i
enunabile.
Procesul fundamental al comunicrii ntre emitor i receptor prin intermediul unui canal fizic
nseamn:
- a gsi semne care pot fi recunoscute ntr-un repertoriu prin intermediul unui canal fizic;
- a gsi semne care pot fi recunoscute ntr-un repertoriu deinut de emitor;
- a le aduce i ale transmite prin ceea ce numim un canal de comunicaie;
- identificarea de ctre receptor a fiecrui semn pe care l primete cu cele pe care le are deja n propriul su
repertoriu.
Comunicarea ideilor nu are loc dect n msur n care cele dou repertorii au o parte comun. Pe
msur ce acest proces continu n procesele dotate cu memorie i cu estimare statistic, cum este cazul
inteligenei umane, percepia semnelor mereu identice vine s modifice din ce n ce mai mult n repertoriul
receptorului, cruia i este subordonat. Este vorba de sistemul de nvare.
n comunicare emitorul creeaz o form, o imagine, o idee, pe care o codific apoi n momentul
emisiei. La rndul su, receptorul, plecnd de la mesaj construiete o alt form. Calitatea comunicrii se
msoar prin identitatea dintre forma perceput i forma creat.
Leibnitz a artat c orice mesaj poate fi considerat o alegere ntre o mulime de cazuri posibile,
alegere care se poate transforma ntr-un numr suficient de mare de dileme succesive. Fiecare dintre aceste
alternative, fiecare din aceste alegeri ntre dou posibiliti care se exclud (da-nu; 0-1), dac ele sunt egal
probabile pentru receptor, reprezint o unitate de informaie sau BIT (binary digit: cifr binar sau problem
binar). Avem astfel o unitate de msur a informaiei ncepnd cu numrul de dileme susceptibile a defini
mesajul fr ambiguitate.
Receptorul uman nu este capabil s sesizeze dect o cantitate limitat de originalitate pe unitatea de
timp, adic un anume debit de informaie, funcie de canalul de percepie (vz auz, pipit, telepatie etc.).
Caracterul optim al mesajelor nu este dat de maximul de informaie ci de maximul de impact adic
de probabilitatea de a nelege, deci de a proiecta forme asupra mesajului primit.
E necesar aici un exces, o risip de semne, i apare o alt mrime numeric, legat de mesaj, care
joac un rol important n comunicaie: REDUNDANA.
Ea nseamn excesul relativ al numrului de semne fa de cel care ar fi fost strict necesar pentru a
transmite aceiai cantitate de originalitate.

Figura 7.2. Alegerea optimului de redundan

Orice mesaj poate fi caracterizat prin coninutul su de informaie i poate s se situeze ntr-un punct
definit al unei scri care merge de la banalitatea total pn la originalitatea total.
Redundana variaz deci n raport invers proporional cu informaia. Inteligibilitatea unui mesaj este
legat de redundana sa. Ea reprezint maximul pentru un mesaj total banal i este nul pentru un mesaj
perfect original.
Valoarea mesajului se traduce atunci prin diferite rate de redundan, (Figura 2.2.) care prezint un
maxim n funcie de caracteristicile receptorului.

Fie:

Figura 7.3. Comunicarea n prezena perturbaiei

unde: E - este emitorul de informaie;
R - este receptorul de informaie;
C - este canalul de comunicaie;
P - este perturbaia.
Modelul matematic al unui sistem de transmitere a informaiei este format din dou mulimi finite
i o probabilitate condiionat
simbolurilor care se emit iar

, definit pe

pentru orice

este mulimea

mulimea simbolurilor ce se recepioneaz.

Probabilitatea
se numete probabilitatea de recepie condiionat de ceea ce se emite i
caracterizeaz perturbaia existent pe canalul sistemului respectiv. A cunoate canalul de comunicaie
nseamn a cunoate probabilitile
Mrimea
mulimea
probabilitatea

pentru toate simbolurile

reprezint cantitatea medie de informaie necesar pentru a se recepiona

i depinde de probabilitatea condiionat

, care la rndul ei, este determinat de

ce caracterizeaz perturbaia pe canal.

Nedeterminarea

apare datorit perturbaiei; ea este preul pe care trebuie s-l pltim

perturbaiei pentru ca s putem recepiona semnalele

Dac

reprezint cantitatea medie de informaie care se pierde pe canal i dac de la sursa se

transmite o cantitate de informaie

, la recepie va ajunge numai cantitatea de informaie

Mrimea denumit CAPACITATEA CANALULUI este dat de relaia:

i ea pune n eviden cantitatea de informaie care poate s circule n mod util prin canalul dat.
Diferena
raportat la unitatea de timp se mai numete vitez de transmitere a
informaiei.
Capacitatea canalului este deci viteza maxim de transmitere a informaie pe canalul respectiv.

DEFINIREA SISTEMELOR INFORMATICE (Modulul 2, U 8.2)

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 tehnicotiinifice, 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.
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 n sistemul informaional predomin utilizarea calculatoarelor electronice, se spune c
el este un sistem informatic.
2. Un sistem informatic poate fi definit ca un ansamblu tehnico-organizatoric 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 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.
CICLUL DE VIA AL UNUI SISTEM INFORMATIC (Modulul 2, U 8.3)
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.
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.

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.
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.
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 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.
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 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 transformate
Soluia sistemului

Specificaii

Transformare

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.

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 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.
PREZENTARE METODA MERISE (Modulul 3, U 9.2)
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.
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 utilizatorinformatician 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 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, pentruREALITATEA
anumii conductori de proiecte, metoda pare greoaie.
Pentru a reui, un proiect MERISE trebuie s aib obligatoriu adeziunea i participarea utilizatorilor.
Abstractizare
Metoda presupune construirea de modele
la nivel conceptual, organizaional i operaional furniznd

astfel legturile
existente
n sistemele informaionale (Figura 9.1.).
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 entitate-relaie 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.
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?.
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.

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;

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 entitate-asociere 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.
ELABORAREA TEMEI DE REALIZARE A SISTEMULUI INFORMATIC (Modulul 3, U 10.2)
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;
- 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.
1. Tehnica documentrii
Prin tehnica documentrii se urmrete culegerea i prelucrarea informaiilor cu caracter teoretic i
practic privind sistemul studiat.
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.
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.
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.
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.
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.
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.
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 n considerare a 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.
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 sa 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;
- 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:
- 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.
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.
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 repernduse 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.
5. Extragerea rezultatelor prin reinerea acelor tendine manifestate care corespund obiectivelor
propuse.
PROIECTAREA LOGIC (ELABORAREA CONCEPIEI SISTEMULUI INFORMATIC)
(Modulul 3, U 10.3)
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.
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:
- 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.
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 o celul

intrrile

, ieirile

i transformrile

ale

intrrilor n ieiri definesc celula respectiv:

Dac ieirea celulei

simbolic:

constituie intrare pentru celula

, atunci

formeaz un lan notat

Figura 10.1. Lan de celule

Mrimile

(ieirile din celula

i intrrile n celula

) desemneaz acelai element. Aceast

dubl semnificaie constituie o redundan informaional. Reducerea unor astfel de redundane se face prin

introducerea conceptului de generaie. Elementul

transformrii efectuate n celula

n care

, apare generaia

este un operand de generaia

. Ca urmare a

de operanzi ceea ce se exprim prin relaia:

semnific numrul de ordine al operandului n cadrul generaiei.

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:

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

indic grupa

subgrupa

i sortimentul

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

- 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

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

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

n care: -

este economia de personal;

este volumul de munc nainte de introducerea sistemului informatic;

este volumul de munc dup introducerea sistemului informatic;

este numrul de lucrtori pentru exploatarea i ntreinerea sistemului informatic;

este numrul lunilor de funcionare a sistemului informatic;

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 producie ca urmare a funcionrii sistemului informatic. Relaiile
de calcul sunt urmtoarele:

unde: -

este sporul de producie ca urmare a funcionrii sistemului informatic;

reprezint valoarea produciei nainte i respectiv dup introducerea sistemului informatic;
este numrul de ani estimat pentru funcionarea sistemului informatic;
este coeficientul modificrii valorii mijloacelor de producie n primul an de funcionare a

sistemului informatic fa de anul precedent;

-

este sporul efectiv a valorii produciei pe durata exploatrii sistemului informatic.

Calculul profitului suplimentar

datorat introducerii sistemului informatic se face avnd n

vedere profitul scontat ce se obine n primul an de aplicare a sistemului informatic

profitul normat

exprimat n mrimi relative:

sau

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;

- 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

- durata de recuperare a cheltuielilor

unde: -

este suma economiilor rezultate din funcionarea sistemului informatic;

-

sunt cheltuielile iniiale;

sunt cheltuielile de exploatare;

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

prin care se 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:

n care:

reprezint timpii medii de munc necesari nainte i dup introducerea sistemului

informatic;
-

reprezint costurile totale nainte i dup introducerea sistemului informatic.

Eficiena global a sistemului informatic se estimeaz prin raportul:

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

PROIECTAREA TEHNIC (Modulul 3, U 10.4)

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 l 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 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 dintr-o 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.
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. 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;
- 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.
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;
- 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
2. intrri ale condiiilor

; combinaii ale intrrilor posibile redau reguli n luarea deciziilor

3. decizii (aciuni) posibile

; succesiunea vertical a denumirii deciziilor indic

ordinea n care urmeaz a fi executate deciziile;

4. intrrile deciziilor

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

(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

i dac se realizeaz condiia

i dac ... atunci se ia decizia

Se solicit materialul X de

Da

Da

Da

Da

calitatea I
Depozitul dispune de

Da

Nu

Nu

Nu

Da

Da

Nu

Da

Nu

materialul X de calitatea I
Depozitul dispune de

Nu

Da

Nu

Nu

Nu

Da

Da

Nu

Nu

Nu

Nu

Da

Nu

materialul X de calitatea II n
cantitate Q
Solicitantul accept
schimbarea calitii
Elibereaz materialul X de

calitatea I n cantitate Q
Elibereaz materialul X de
calitatea II n cantitate Q
Emite comanda de

*
*

*
*

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

ELABORAREA PROGRAMELOR (Modelul 3, U 10.5)

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

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

nivelul rdcinii structurii

i punnd convenional

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

B
da

SELECIA
X

nu

A
A

ITERAIA
X
C
A

nu

da
A

Figura 10.7. Structuri elementare n programarea structurat

TEOREMA DE STRUCTUR: Oricare ar fi schema logic

aparinnd mulimii schemelor logice

clasice i care reprezint structura logic a unui proces de prelucrare, exist cel puin o transformare

pentru care

astfel nct:

1.

este echivalent cu S;

2.

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

, 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

. Aproape imediat apar i partizanii fanatici ai OOP-

ului aflat acum la a doua tineree. Termenul de OOP provine din Object 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
face nimic altceva dect s-i dea un nou avnt unuia dintre cele mai la moda limbaje ale momentului

nu
.

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
putem defini o alt clas

care s moteneasc sau s preia toate caracteristicile clasei

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

IMPLEMENTAREA, EXPLOATAREA I NTREINEREA (Modulul 3, U 10.6)

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 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.
MODELUL CONCEPTUAL AL DATELOR (Modulul 3, U 11.2)
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

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

salariai, adic mai muli salariai.

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:
- niciunul sau unul singur;
- unul i unul singur;
- niciunul sau mai muli;
- 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

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

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 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 LEGTURIDENTIFICATOR, 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 subtip n snul unei aceleiai entiti.
n plus ea permite utilizatorului s genereze un MFD care ine cont ntr-adevr 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. Un simbol n form de semicerc este desenat n mijlocul legturii i servete ca punct de ntlnire
pentru alte legturi venind de la alte entiti fiic.

ANGAJAT
ANGAJAT
MASCULIN
FEMININ
concediu
obligaiide
ceteneti
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.
Aceast prezentare se traduce n urmtorul MCD.
SALARIAT
nume
adresa
proiect_1
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 o nou
proprietate denumit MARC care identific fr ambiguitate fiecare salariat din ntreprindere, iar
DEN_SECIE depinde direct de MARC. Se obine urmtorul MCD:

SALARIAT
marca
nume
cod_proiect
strada
oras
den_sectie

PROIECT
nume_proiect
1,2

PARTICIP

1,n

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.
MODELUL LOGIC AL DATELOR(Modulul 3, U 11.3)
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;
- 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 tat-fii 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.
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

sau

apare o migraie a cheilor entitii legate de legtura de cardinalitate

i o alta de cardinalitate
sau

sau

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

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
COD_FISCAL
NUME_BENEFICIAR

FACTURA

1,n

BENEFICIAR
COD_FISCAL
NUME_BENEFICIAR

PRIMETE 1,1
DATA

NUMAR_FACTURA
VALOARE_FACTURA
FACTURA
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

sau

asociaia devine

un tabel n MLD, n care migreaz cheile entitilor.

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
produs poate s nu fie cumprat sau s fie cumprat de
n Figura 6.18.

clieni , modelele conceptual i fizic vor arta ca

CLIENT
COD_FISCAL
DENUMIRE_CLIENT

CLIENT
COD_FISCAL
DENUMIRE_CLIENT

produse, iar un

PRODUS
CUMPARA

0,n

0,n

CUMPARA
CUMPARA
COD_FISCAL
COD_PRODUS

COD_PRODUS
DENUMIRE_PRODUS

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

sau

apare o dubl migraie a

identificatorilor entitilor.
Fie urmtorul MCD i corespunztor acestuia urmtorul MLD.
AGENT_ECONOMIC
COD_FISCAL
DENUMIRE

CERTIFICAT_INMATRICULARE
ARE

1,1

1,1

NUMAR
DATA

AGENT_ECONOMIC

CERTIFICAT_INMATRICULARE
NUMAR
COD_FISCAL
DATA

COD_FISCAL
NUMAR
DENUMIRE

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

n MLD se pstreaz cele dou entiti provocndu-se n fiecare din ele migrarea reciproc a
identificatorilor. Cnd asociaia binar are dou legturi

sau

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:

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
MARCA
SALARIU
OBLIGAII_CETENETI

FEMEIE
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.
MODELUL FIZIC AL DATELOR (Modulul 3, U 11.4)
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 Barbore 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 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.

MODELUL CONCEPTUAL AL COMUNICAIILOR (Modulul 3, U 11.5)

Acest model, numit i graf actori-flux, permite descrierea informaiilor schimbate la nivel global n
sistem. Conceptele utilizate sunt:
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.
f) graful fluxurilor
Graful fluxurilor este un graf ale crui noduri sunt actori iar arcele orientate sunt fluxurile schimbate.
FLUX1
ACTOR1

FLUX3

ACTOR2

FLUX2

FLUX4

ACTOR3

Figura 11.22. Modelul conceptual al comunicaiilor

MODELUL CONCEPTUAL AL PRELUCRRILOR (Modulul 3, U 11.6)

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

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

OPERATIE
ACTIUNE 1
ACTIUNE
2 2
EVENIMENT
(B)

EVENIMENT 1
(A)

Figura 11.27. Condiia de sincronizare

EVENIMENT 3
(C)

OPERATIE
ACTIUNE 1
ACTIUNE 2
REGULA DE EMISIE 1

EVENIMENT 4
(D)

REGULA DE EMISIE 2

EVENIMENT 5
(E)

Figura 11.28. Regula de emisie

EVENIMENT 2
(B)
EVENIMENT 1
(A)

EVENIMENT 3
(C)

O operaie poate s nu aib regul de emisie. n acest caz emisia evenimentelor este necondiionat i
se traduce cu ajutorul cuvntului totdeauna. O regul de emisie poate avea un alias pentru uurarea afirii
simbolului operaiei n cazul n care textul care definete regula este prea lung.
OPERATIE 1
ACTIUNE 1
ACTIUNE 2
REGULA DE EMISIE 1

REGULA DE EMISIE 2

EVENIMENT 4
(D)

EVENIMENT 5
(E)

OPERATIE2
ACTIUNE3
TOTDEAUNA

EVENIMENT 6
(F)

Figura 11.29. Modelul conceptual al comunicaiilor - exemplu

Evenimentele 1, 2 i 3 declaneaz operaia 1 punndu-se condiia de 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 operaia 1.
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).
Cu titlu de exemplu s ncercm modelarea procesului de selecie a unui candidat la ocuparea unui
post. Aceast modelare se sprijin pe urmtoarea prezentare sub form de text.
La primirea dosarului, un angajat efectueaz controlul documentelor din 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 favorabile, se trimite o convocare pe adresa candidatului.
DOSAR DEPUS
CONTROL ACTE
CONTROL ACTE DEPUSE
CORECT

INCORECT

DOSAR DUP PRIMUL CONTROL

SCRISOARE DE RESPINGERE 1

STUDIERE DOSAR

CORECT

INCORECT

DOSAR DUP AL DOILEA CONTROL

SCRISOARE DE RESPINGERE 2

EDITARE CONVOCARE
EDITARE SCRISOARE DE CONVOCARE
TOTDEAUNA
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:
1. nici un eveniment extern, dup venirea dosarului, nu justific mprirea 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 ntrun anumit loc de munc unei operaii conceptuale;
n general, atunci cnd o serie de operaiuni se nlnuie fr evenimente externe sau interne
justificate cu adevrat, nu trebuie s aib loc o detaliere a operaiunilor.
Se poate propune urmtorul MCP:
DOSAR DEPUS

STUDIERE DOSAR
STUDIUL AUTOBIOGRAFIEI
CONTROLUL DOCUMENTELOR
CORECT

INCORECT

SCRISOARE DE CONVOCARE

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

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)

Figura 11.33. MCP cu incoerene

EVENIMENT 1 (A)

OPERATIE 1
ACTIUNE
ACTIUNE
ACTIUNE
ACTIUNE

4
3
1
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 n care funcionarea modelului este imposibil sau nedeterminat, adic vor fi
EVENIMENT
1 (A)
abordate noiunile
de conflict
i de ciclu.

EVENIMENT 2 (B)

EVENIMENT 3 (C)

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:

OPERATIE 1

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;
- condiiile de participare ale evenimentului 2 la cele dou operaii sunt exclusive.
b) Noiunea de ciclu
Cnd o operaie are ca eveniment declanator un eveniment pe care ea l 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
(D)(Figura 11.36.) este controlat i condiiile sale de pornire i de terminare
MCP-ului. Un astfelSTART
de ciclu

trebuie s fie clare. Astfel pornirea ciclului se face cu ajutorul evenimentului start i oprirea se face cu
ajutorul evenimentului stop. Aceste evenimente 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

OPERATIE 1

Validarea modelelor are ca obiectiv sinteza ntre analiza datelor i analiza prelucrrilor. Ea permite
verificarea ntre MCD i MCP.
Verificarea acestei coerene are ca regul esenial verificarea ca toate entitile i asociaiile MCDului s fie utilizate de cel puin o operaie a MCP.
EVENIMENT 3 (E) EVENIMENT 1 (B)

OPERATIE 2

EVENIMENT 2 (C)

STOP (A)

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.

MODELUL ORGANIZAIONAL AL PRELUCRRILOR (Modulul 3, U 11.7)

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:

NUMELE FAZEI I
TASK 1
TASK 2
CONDITIE 1

CONDITIE 2

Figura 11.37. Faza

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

MODELUL OPERAIONAL AL PRELUCRRILOR (Modulul 3, U 11.8)

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.);
- 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.
CICLUL DE DECIZIE (Modulul 3, U 12.2)
Ciclul de decizie cuprinde toate deciziile luate pe parcursul desfurrii proiectului, mai generale la
nceput i apoi din ce n ce mai precise. Deciziile 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.
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 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 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
Impactul strategic al sistemelor viitoare

maxim

Figura 12.1. Modelul strategic gril

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
Proiect realizat
Conducerea proiectrii

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.

Dreptunghiurile reprezint stri sau grupuri de stri legate ntre ele n diferite moduri, iar intrrile i
ieirile sunt evenimente care permit tranziia de la o stare la alta. Strile, permit conductorului de proiect
comunicarea i msurarea activitii asociate proiectului n dezvoltare. Se observ c evenimentele sau
condiiile de ieire asociate strilor sunt stabilite pentru ca managerul s tie cnd o anumit faz este
complet astfel nct s poat ncepe urmtoarea.
AC (Asigurarea Calitii) reprezint semnalul prin care s se garanteze c produsul se conformeaz
unor standarde IEEE Standard for Software Quality. Calitatea produsului const n totalitatea trsturilor sau

caracteristicilor sale care i permit s se conformeze necesitilor utilizatorului. Controlul calitii const n
aciunile necesare pentru msurarea caracteristicilor produsului i compararea lor cu specificaiile. Calitatea
nu poate fi testat n produs dar ea trebuie s fie construit n interiorul produsului. Procesul trebuie s
nceap din primele etape i s continue pn la sfritul ciclului de via, pentru c fiecare etap constituie o
nou ocazie pentru alte tipuri de erori.
CM (Componena Managementului) este aspectul care permite identificarea n timp a acelor puncte
pentru efectuarea controlului modificrilor, pentru monitorizarea integritii i trasabilitii produsului pe
parcursul ciclului de via. Aceasta permite conductorului s cunoasc ce s-a fcut, ce se realizeaz acum i
cu ce se va continua mai departe.
V+V (Verificarea i Validarea) se refer la ct de bine produsul corespunde din punct de vedere
funcional, al cerinelor de performan i al interpretrii corecte a cerinelor. Punctul principal al verificrii
i validrii este clientul adic dac ceea ce i s-a furnizat corespunde cerinelor sale.
Aa cum s-a vzut din cele prezentate conducerea proiectului este activitatea care traverseaz
ntregul ciclu de via. Conductorul trebuie s fie atent n deciziile luate, trebuie s posede informaiile
corecte pentru luarea deciziilor i s nu ia decizii compensatorii atunci cnd s-a greit. Mai mult chiar,
conducerea proiectului nu implic numai manipularea resurselor bani i timp ci i a resursei umane.
n procesele de decizie, chiar n stabilirea obiectivelor intervin puternic motivaiile personale i
interpersonale. Complexul de atitudini, motivaii, intenii, stri afective etc. constituie mpreun
comportamentul uman care trebuie avut n vedere de conductor n cele dou accepiuni ale sale:
- factorul uman din interiorul echipei de proiectare;
- comportamentul uman din sistemul studiat ca obiect de analiza al echipei de proiectare.

ABORDRI ORIENTATE SPRE DATE I SPRE PRELUCRRI (Modulul 4, U 13.2)

Realizarea unui sistem informaional-decizional performant este rezultatul unui cumul de factori.
Este cert c nu factorii individuali sunt cei cu influen hotrtoare ci ansamblul interaciunii lor. Acest
ansamblu de factori trebuie analizat i modelat n aa fel nct s se obin performana maxim. Dac prin
extensie spunem c modelarea efectuat pentru realizarea sistemului este ea nsi un factor, putem afirma c
ntr-adevr acesta este unul important. Modelarea situaiei existente sau a celei dorite trebuie s fie capabil
s reprezinte realitatea la un moment dat dar i s se poat adapta la modificrile pe care ea nsi le
preconizeaz.
Analiznd modelele de reprezentare a realitii propuse de metoda Merise, se observ dou tipuri de
reprezentare.
Prima este bazat pe postulatul c un sistem trebuie s realizeze anumite funcii (existena unui
material n stoc, nlnuirea etapelor pentru construcia unei case etc.). Aceast abordare este cea a
descompunerii funcionale.
A doua se preocup de faptul c un sistem informatic este un sistem de relaii ntre entiti. Spre
exemplu se descrie un individ ca un ansamblu compus dintr-un nume, unul sau mai multe prenume, un cod

numeric personal i avnd unul sau mai muli copii. n acelai sens o cas este un ansamblu de fundaii,
perei, ui i ferestre.
Sosirea buldozerului

Sosirea muncitorilor

Pregtirea buldozerului
verificarea combustibilului
verificarea prezenei ofer
nclzirea motorului

nceput activitate buldozer

Pregtirea echipei
verificarea prezenei
repartizarea sarcinilor

nceput activitate buldozer

Sparea fundaiilor
sptur brut
finisaj sptur
OK
non OK

Anunare proiectant

Beton disponibil

Sptur terminat

Turnarea betonului
pregtire cofraj
pregtire armtur
turnare beton
ateptare ntrire
Terminare turnare fundaii

Figura 13.1. Exemplificare cu modelul conceptual al datelor

Descompunerea funcional i propune s abordeze sistemul ca un prestator de servicii care s
rspund la anumite ntrebri. De exemplu Ci clieni au fost vizitai de la nceputul lunii?. Furnizarea
rspunsului presupune desfurarea unei serii de aciuni: determinarea primei zi lucrtoare din lun, gsirea
clienilor vizitai de la acea dat i pn la zi i afiarea rezultatului. Funcia gsirea clienilor vizitai de la
nceputul lunii i pn la zi se descompune ea nsi n acces la fiierul de clieni, selecionarea numrului
de clieni vizitai ncepnd de la acea dat, eliminarea clienilor vizitai de dou ori etc. Acest demers ar
prea natural n msura n care ar reproduce ceea ce face un salariat cruia i se pune aceast ntrebare. Se
poate distinge o dubl aciune.
O mprire temporal prin care sarcinile trebuiesc ndeplinite unele dup altele. n exemplul dat nu
pot fi selecionai clienii nainte de stabilirea primei zi lucrtoare din lun. Aceast dimensiune temporal
pune n relief secvenialitatea sarcinilor i sincronizarea lor.

 mprirea procedurilor n subproceduri prin care sarcinile globale sunt mprite n activiti care
pot fi din nou mprite la rndul lor. Procesul se repet pn cnd sarcinile elementare sunt suficient de
simple.
Descompunerea funcional va fi exemplificat cu ajutorul modelului conceptual al prelucrrilor din
metoda Merise.
Indiferent de modalitatea practic de realizare a diagramei funcionale particularitatea acestei
abordri const n urmrirea unei aplicaii prin toate transformrile pe care le exercit asupra datelor. Este
vorba de o structurare a prelucrrilor. Analiza prin descompunerea funcional permite s se gseasc subproceduri comune, putndu-se atunci s se construiasc o singur procedur care va fi utilizat de mai multe
ori n mai multe locuri. Avantajul const n faptul c a fost scris o singur dat iar eventualele modificri se
vor face ntr-un singur loc aplicndu-se tuturor funciilor la care procedura comun particip.
Ca o alternativ la structurarea prelucrrilor s-a lansat spre sfritul anilor 80 analiza structurilor de
date. O problem este reprezentat printr-un sistem de relaii dintre elementele care-l compun. Abordarea se
canalizeaz spre definirea elementelor de model i spre stabilirea reelei de relaii care le leag.
Prezentarea acestui sistem de relaii se face cu ajutorul diagramei entitate-relaie. Entitile reprezint
fiine sau obiecte purttoare a anumitor proprieti iar relaiile reprezint interaciunile dintre entiti. O
relaie se poate exprima printr-o fraz al crui complement sunt entitile iar verbul este relaia dintre ele.
Pentru exemplificare s-a folosit modelul conceptual al prelucrrilor din metoda Merise pentru aceiai
problem a construciei unei case.
Figura 13.2. introduce noiunea de cardinalitate (un ofer face parte dintr-o echip i numai una iar
ntr-o echip pot fi Sofer
zero sau mai muli oferi) dar spre deosebire de structurarea prelucrrilor situaia
1,1
face parte
prezentat de diagrama
nu se precizeaz dac ele sunt n
nume entitate-relaie este static (se prezint datele dar Echipa
0,n

micare sau n repaus). Diagrama entitate-relaie explic ce sunt fundaiile

i ce este necesar pentru a le
sef de echipa
numar de membri

0,1 maniera prin care se poate face. Tot pe lista minusurilor se poate aduga, c unui
construi dar nu explic
0,n

singur model i corespunde un numr infinit de realizri posibile exprimndu-se un ansamblu de relaii
conduce

posibile fr a se impune un sens de lectur.

definit de

1,1

Buldozer
numr

0,n

1,n

sapa

Groapa
1,n locul in teren
adancimea
suprafata
0,1

construita

Cofraj
Fundatia
cod
data terminarii
suprafata

1,1
0,1

cofrata

1,1 tip
material
marca beton

Figura 13.2. Exemplificare cu modelul conceptual al prelucrrilor

Pe de alt parte modelul este recunoscut ca durabil n msura n care reprezint realitatea
fundamental a domeniului de activitate modelat i este extrem de adaptabil. nlocuirea unui ef de echip
sau introducerea unei noi maini (entiti) cu ajutorul creia se vor spa gropile nu schimb major sistemul.
Abordrile orientate spre date i spre prelucrri i au rdcina n dou sisteme de gndire diferite:
Analiza prin prelucrri i gsete sursa n noiunea de metod n sensul n care aceasta i propune
s rezolve o problem printr-un cadru procedural. Acest cadru fixeaz etapele i nlnuirea lor astfel nct
intrrile i ieirile corespund fiecrei etape. Aceast gndire este esenialmente cartezian i analiza prin
structura prelucrrilor este legat de acest curent de gndire.
Analiza structurilor de date studiaz problema modelrii punndu-se accentul pe relaiile dintre
elementele din model. Aceast abordare este cea inaugurat de coala sistemic. Software-ul este nainte de
toate conceptualizat ca un component al sistemului de organizare global al ntreprinderii. Conceperea sa
ncepe prin analiza definirii sistemului i a frontierelor sale.
Trebuie remarcat totui c nsi metoda de dezvoltare, procesul sau metodologia, pune n eviden o
abordare cartezian chiar dac aceasta se refer preponderent la o modelare orientat spre structurarea
datelor
Ceea ce trebuie remarcat este faptul c aceste dou concepte au stat la baza metodelor actuale de
proiectare. Cu toate c metoda MERISE realizeaz prin modelele de date i prelucrri o dubl abordare a
sistemului, persist totui unele inconveniente.
Fazele de studii sunt prea lungi i neproductive. mprirea lucrului ce decurge din abordarea prin
sarcini specializate i din ciclul de concepie n V fac dificil obinerea de rezultate notabile. Aceast
abordare impune o nelegere global a concepiei anterioare programrii. Adesea pn cnd grupul de studii
s termine caietul de sarcini necesitile s-au schimbat iar n proiectele de o anumit dimensiune lungimea
fazelor face foarte posibil frecventa schimbare a analitilor. Presiunea este foarte mare la nceputul
proiectului, atunci cnd deciziile cele mai importante trebuiesc luate plecndu-se de la un minim de
elemente. Deci, abordrile tradiionale sunt caracterizate printr-o dificultate ridicat o primelor etape cnd
orice eroare poate avea consecine grave.

 Comunicarea este dificil mai ales cu neinformaticienii. Implicarea utilizatorilor n proiect este
adesea dificil, principala dificultate constnd n formularea cerinelor ntr-un format propriu modelrii.
Comunicarea n sens invers nu este nici ea mai uoar, pe de o parte din cauza necunoaterii de ctre client a
limbajului informatic dar mai ales datorit necunoaterii suportului de comunicaie. De la un anumit nivel de
complexitate verificarea diagramelor entitate-relaie i de structurare a prelucrrilor de ctre un
neinformatician devine imposibil.
Abordrile orientate spre date i funciuni sunt ireconciliabile. Analiza structurii datelor permite
obinerea de programe mai evoluate dar ea nu permite reprezentarea scopului aplicaiei a ceea ce utilizatorul
atepta de la ea. Trebuie deci ca mai trziu s se descrie aceasta prin modelarea prelucrrilor. Din aceast
cauz n marile proiecte era necesar o dubl abordare. O echip trebuie s se ocupe de structurarea datelor
i alta de serviciile pe care sistemul urmeaz s le ofere utilizatorilor, adic de structurarea prelucrrilor.
Problemele cu adevrat dificile apar la integrarea datelor cu prelucrrile n procesul de realizare dar mai ales
n faza de mentenan cnd apare frecvent fenomenul de regresie. Acesta const n faptul c modificarea
prelucrrilor ntr-o zon a aplicaiei afecteaz datele utilizate de ntreg sistemul. Se poate demonstra c
aceast problem decurge tocmai din contradicia dintre date i prelucrri.
Abordarea prin prelucrri impune ca o funcie utilizat n mai multe locuri s nu existe dect ntr-un
singur exemplar. n arborescena programului ea va fi ridicat ctre vrful arborescenei pentru a putea fi
utilizat de toate celelalte funcii care o apeleaz.
Securitatea datelor impune ca accesul la ele s fie fcut de un numr minim de funcii. Deci atunci
cnd o dat este modificabil de mai multe proceduri este imposibil de a gsi originea modificrilor. Exist
deci tendina de coborre a funciei de acces pentru a evita modificrile intempestive.
Aceste considerente au stat la baza nateri unei noi abordri, numit orientat obiect, care are la
origine rezolvarea problemelor de simulare. ntr-o astfel de abordarea nu mai este vorba de analiza funciilor
sau de studierea relaiilor dintre elemente ci mai curnd de situarea n interiorul lor reproducnd
comportamentul la anumite evenimente. Din aceast abordare se nate conceptul de obiect ca entitate ce
reacioneaz singur i este independent. Dei metoda MERISE preia unele aspecte ale abordrii obiectuale
rmne n sarcina viitoarelor cercetri integrarea real a conceptului obiectual.

NECESITATEA I OBIECTIVELE UML (Modulul 4, U 14.2)

Astzi, standardul industrial de modelare obiect este UML (Unified Modeling Language), dezvoltat
sub directa responsabilitate a OMG (Object Management Group) un grup industrial interesat n unificarea
metodologiei de proiectare i standardizarea tehnologiilor obiect, pentru a putea garanta interoperabilitatea
sistemelor importante. OMG cuprinde actualmente peste 800 membri, printre care Sun, IBM, Microsoft etc.,
dar i mari ntreprinderi utilizatoare din toate sectoarele de activitate.
Prinii acestui limbaj sunt considerai a fi Grady Booch, James Rumbaugh i Ivar Jacobson datorit
unor prime lucrri n acest domeniu Object Management Technology (OMT) i Object Oriented System

Engineering (OOSE) - nc din anul 1994. n anul 1995 se consemneaz o prim tentativ de unificare a
conceptelor ncercat de Booch i Rumbaugh, la care se altur i Jacobson n anul 1996.
Lucrarea comun este naintat OMG n ianuarie 1997 cnd apare i prima versiune UML 1.0.
adoptat la sfritul acestui an, dup anumite completri, sub numele UML 1.1. Eforturi susinute de
standardizare din parte a OMG duc la apariia unor versiuni din ce n ce mai complete, aplicabile n
industrie: 1.3 n anul 1999 i UML 1.4 n septembrie 2001 3. Astzi se aplic pe scar larg versiunea 2.0 i,
de curnd, i-au fcut apariia versiunile 3.0, 3.1 i 3.2 n cadrul unor pachete de programe promovate de
firmele specializate n grafic pe calculator4.
Conform UML, un concept derivat din cerinele utilizatorului n conformitate cu cazurile lui de
utilizare este proiectat mai departe n realizarea modelului i n programare. Invers, plecnd de la program,
putem descoperi crei necesiti i corespunde acesta i, n consecin, care este ideea care a stat la baza
proiectului (reverse engineering).
VERSIUNILE UML5 (Modulul 4, U 14.3)
Din anul 1997 pn n prezent, UML a cunoscut numeroase modificri, acestea fiind concretizate n
versiuni mai mult sau mai puin cunoscute publicului. Este de notat faptul c principiile UML au rmas, n
general, neschimbate, versiunile UML opernd n special n domeniul formalismelor utilizate (notaii,
simboluri, convenii).
De la UML 1.0 la UML 1.1
ntre versiunile UML 1.0, aprut n ianuarie 1997 i UML 1.1 propus n luna septembrie a aceluiai
an, nu s-au semnalat deosebiri importante. Rolul de ngheare (frozen) al asocierilor de tip compunere a
fost desfiinat. El se aplic, de la caz la caz, anumitor asocieri ale claselor i atributelor lor. Returul n
diagramele de secven a fost stabilit s se reprezinte cu linie ntrerupt.
De la UML 1.2 (i 1.1) la UML 1.3
UML 1.2 a aprut n anul 1998 iar UML 1.3 n anul 1999. Pentru aceast versiune s-au semnalat
unele modificri importante.
Cazurile de utilizare
Dac versiunea UML 1.1 recunotea dou tipuri de relaii ntre cazurile de utilizare, use i extends,
ambele sub form de stereotipuri, versiunea UML 1.3 nlocuiete use prin include, introduce generalizarea i
definete extensia ca pe un stereotip de dependen form mai controlat dect relaia de generalizare.
Diagramele de activiti
3 A se vedea [RRRT] Rational Rose RealTime for Windows, pachet de programe comercializat de IBM, http:/www.
downseek.com/download/19186.asp

4 A se vedea [VP3.2UG] Visual Paradigm for UML 3.2 Users Guide Copyright 1999-2004 by Visual Paradigm,
http:/www.apache.org Apache Software Foundation.

5 [Fowler2] Martin Fowler - UML 2.0 CampusPress, 2004, pp.181-189 (trad. lb. engl. UML Distilled Third Edition, Addison
Wesley, 2003).

Pentru a nota o condiie, se poate utiliza un romb pentru a nota att o ramificaie ct i o fuziune
(condiia se menioneaz n parantez).
Bara de sincronizare poate fi sau o ramificaie sau o jonciune. Nu se pot aduga condiii arbitrare
jonciunilor. Oricrei ramificaii trebuie s-i corespund o jonciune care s reuneasc threads create prin
acea ramificaie. Se pot imbrica ramificaiile i jonciunile i se pot elimina din diagram ramificaii i
jonciuni atunci cnd threads pleac direct de la o ramificaie la alta sau de la o jonciune la alta.
Jonciunile nu sunt activate dect atunci cnd toate threads care intr sunt terminate. Dar putei avea
o condiie asupra unui thread care pleac dintr-o ramificaie. Dac aceast condiie este fals, se consider c
thread este terminat pentru nevoile jonciunii.
S-a considerat c urmtoarele versiuni ale UML ar putea modifica total diagramele de activiti (vezi
UML 2.0).
De la UML 1.3 la UML 1.4
Cea mai important schimbare adus de UML 1.4 const n adugarea profilurilor, ceea ce permite
colectarea unui grup de extensii ntr-un ansamblu coerent. Documentaia UML conine dou exemple de
profiluri. Totodat, formalismul definirii de stereotipuri a crescut i elementele modelului au putut avea mai
multe stereotipuri, n timp ce n UML 1.3 exista unul singur.
A fost adugat artefact-ul manifestare fizic a unei componente, s-a lucrat asupra vizibilitii
pachetelor Java n metamodele i asupra marcrii asincronismelor prin sgei n diagramele de secven.
De la UML 1.4 la UML 1.5
Principala modificare a fost adugarea unei semantici de aciune, etap necesar pentru a face din
UML un limbaj de programare.
Principalele caracteristici ale UML 2.0
Una din schimbrile cele mai evidente privete tipurile de diagrame. Diagramele de obiecte i
diagramele de pachete devin diagrame oficiale. Diagramele de colaborare devin diagrame de comunicare.
UML 2.0 introduce, de asemenea, noi tipuri de diagrame: vedere de ansamblu a interaciunilor, timing i
structuri compozite.
Referitor la diagramele de clase: concepte eseniale
Atributele i asocierile unidirecionale devin dou notaii esenial diferite pentru a reprezenta
conceptul sub-adiacent de proprietate.
Multiplicitile discontinui (exemplu [2,4]) au fost abandonate. Nu mai exist proprietatea frozen. Sau adugat noi cuvinte cheie pentru dependene.
Cuvintele cheie <<parameter>> i <<local>> nu se mai utilizeaz.
Diagramele de secven
Modificarea cea mai important este notaia cadrelor de interaciune, care permite gestionarea
structurilor iterative, condiionale i a altor structuri de control ale comportamentului. Putei exprima
aproape n ntregime algoritmii n diagramele de secven. Vechile marcaje de iteraii i notaiile lor au fost

abandonate. Antetele de linii de via nu mai sunt instane, acestea fiind definite prin termenul participant.
Diagramele de colaborare se numesc acum diagrame de comunicare.
Referitor la diagramele de clase: concepte avansate
Stereotipurile sunt definite de o manier mai strict. n consecin, exist cuvinte cheie pentru a
defini expresiile ntre ghilimele, numai unele dintre acestea din urm fiind stereotipuri. n diagramele de
obiecte, instanele sunt acum specificaii de instane. Clasele pot solicita interfee i le pot realiza.
Clasificarea multipl utilizeaz ansambluri de generalizare pentru a regrupa generalizrile.
Componentele nu mai sunt reprezentate printr-un simbol special.
Obiectele active au linii duble verticale n loc de linii groase.
Diagramele de maini de stare
Dac UML 1 fcea distincia ntre aciuni (momentane) i activiti (continue), UML 2 numete cele
dou activiti i utilizeaz acest termen n toate cazurile.
Diagramele de activiti
UML 1 trata diagramele de activiti ca pe un caz particular al diagramelor de stare. UML 2 a rupt
legtura ntre acestea i a suprimat regulile de coresponden a ramificaiilor i jonciunilor pe care le
instaurase UML 1.
Au aprut noi notaii, printre care acelea de semnale temporale i de acceptare, parmetri, specificaii
de jonciune, conectori, transformatori de fluxuri, greble de sub-diagrame, regiuni de expansiune i
terminaii de fluxuri.
UML 1 considera mai multe fluxuri de intrare ntr-o activitate ca pe o fuziune implicit, n timp ce
UML 2 le trateaz ca pe o jonciune implicit. Pentru a evita confuziile, recomandm utilizarea fuziunilor i
jonciunilor explicite n diagramele de activiti.
TIPURI DE DIAGRAME (Modulul 4 , U 14.4)
UML este un limbaj esenialmente grafic, ce se definete n jurul mai multor categorii de diagrame,
fiecare dintre acestea fiind dedicat reprezentrii unor concepte particulare ale unui sistem informatic: prima
categorie descrie serviciile funcionale, a doua privete structura static a sistemului iar cea de-a treia se
refer la dinamica funcionrii sistemului.
1. Diagramele funcionale
Diagramele funcionale se bazeaz exclusiv pe cazurile de utilizare pentru specificarea cerinelor
sistemului. Paradigma de reprezentare este ilustrat n figura 14.1 i are urmtoarea semnificaie: Actorul
particip la Cazul de utilizare reprezentat n diagram. Att actorii ct i cazurile de utilizare trebuie s
poarte denumiri unice, ntre cazurile de utilizare existnd i anumite relaii de care ne vom ocupa ulterior.
Cazurile de utilizare arat ce anume trebuie proiectat, fr a da vreo indicaie cum s se fac acest lucru.

Fig. 14.1 - Diagrama UML. Cazuri de utilizare

2. Diagramele statice (sau structurale)
Diagramele statice, numite i diagrame structurale, arat legturile ntre diferitele elemente de
structur ale modelului i se refer la: diagramele de clase; diagramele de obiecte; diagramele de pachete;
diagramele de structuri compozite; diagramele de componen; diagramele de desfurare.
Diagramele de clase
Diagramele de clase, a cror paradigm de reprezentare este ilustrat n figura 14.2, constituie
punctul central al dezvoltrii obiect. n figura menionat, clasa B caracterizat prin atributele atribut2 i
atribut3 i operaiile operaie2 i operaie3 este asociat clasei A caracterizat prin atribut1 i operaie1
printr-o relaie de agregare. Cu alte cuvinte, un numr neprecizat de instane ale clasei B (notat cu 0..*) intr
n compunerea unei instane aparinnd clasei A. Pe de alt parte, clasa A este legat printr-o relaie de
generalizare/particularizare de sub-clasa A1 care i motenete proprietile (atribut1 i operaie1) avnd n
plus operaie4.
Pentru analiz, diagrama de clase este util deoarece descrie structura entitilor manipulate de
utilizator.
n realizarea modelului, cu o diagram de clase se reprezint de obicei structura programelor
orientate obiect sau, mai precis, modulele limbajului de dezvoltare.

Fig. 14.2 - Diagrama de clase UML

Diagramele de obiecte
O diagram de obiecte este o fotografie a obiectelor unui sistem la un moment dat. Ele reprezint
instane ale claselor (nu clase), de aceea se mai numesc i diagrame de instane.
Un exemplu al acestui tip de diagram este prezentat n figura 14.3.

Fig. 14.3 - Diagrama de obiecte UML

Diagrama reprezint o ierarhie a unor obiecte aparinnd unor clase. Numele clasei (obligatoriu) este
menionat dup semnul : (obligatoriu). Numele obiectului (opional) este menionat naintea semnului :.
Din diagram se observ c:
1. Filialele sunt tot ntreprinderi, prin urmare motenesc proprietile acestei clase, singura diferen
fiind localitatea n care funcioneaz;
2. Angajaii ntreprinderii motenesc i ei proprietile ntreprinderii care i remunereaz, indiferent
de localitate. Angajaii posed caracteristici proprii care nu sunt evideniate n diagram.
Elementele unei diagrame de obiecte sunt specificaii de instane ale claselor i se utilizeaz n
cazurile complexe, acolo unde diagramele de clas sunt greu de neles i pot da natere la interpretri
diferite.
Obiectele intervin n cadrul: diagramelor de secven, diagramelor de colaborare, diagramelor de
stare i diagramelor de activiti.
Diagramele de pachete
Clasele reprezint structura de baz a unui sistem orientat obiect. Totui, atunci cnd avem de-a face
cu sisteme mari, cu sute de clase, acestea devin dificil de neles i necesit gruparea elementelor UML n
pachete.
Orice construcie UML (cazuri de utilizare, clase, obiecte) poate fi grupat n uniti de nivel mai
nalt sub form de pachete.
ntr-un model UML, fiecare clas aparine unui singur pachet i poart un nume distinct n cadrul
pachetului.
Pachetele pot fi, n acelai timp, membre ale altor pachete, ceea ce conduce la o structur ierarhizat
de pachete i clase.
Un pachet poate conine, totodat, sub-pachete i clase independente.
n UML, numele pachetului este urmat de semnul :: care l desparte de numele sub-pachetului sau
de numele clasei componente.

n exemplul din figura 14.4 este reprezentat pachetul java din care face parte sub-pachetul util care
conine, la rndul su, clasa Date.

Fig. 14.4 - Diagrama de pachete UML

Ceea ce este reprezentat n figura 14.4 va putea fi notat java::util::Date sau Date (de java::util)6.
Diagramele de structuri compozite
Una din noile caracteristici ale UML 2.0 const n posibilitatea de a descompune ierarhic o clas ntro structur intern. Aceasta permite subdivizarea unui obiect complex n diferitele sale pri componente.
n figura 14.5, de exemplu, este reprezentat clasa Telecomand mpreun cu interfeele sale.

a). reprezentarea global

b). reprezentarea compozit

Fig. 14.5 - Diagrama de structuri composite UML (dup Jim Rumbaugh)

Din figura 14.5 a)., nu rezult dect c aceast clas are dou feluri de interfee: realizate i cerute,
precum i denumirea acestora.
Din figura 14.5 b)., aflm c aceast clas se descompune, de fapt, n dou pri: controlor i
generator iar interfeele sunt cuplate astfel:
- comanda TV om-main la partea numit controlor, iar
- comanda TV aplicaii, mpreun cu afiarea, reglajul i fluxul de imagini, la partea numit
generator.
Observaii privind notaiile:
6 Aceast notaie a fost introdus de firma Rational Rose i nu face parte din standardul UML.

1. Pentru a arta c o parte implementeaz o interfa, am desenat un conector sub form de cerc i o
sgeat cu linie ntrerupt care sosete n partea respectiv.
2. Pentru a arta c o parte necesit o interfa, am desenat un cuplor sub form de semicerc i o
sgeat cu linie ntrerupt care pleac din partea respectiv.
Structurile compozite sunt noi n UML 2.0 i, datorit acestei nouti, este prematur s se prevad
pn la ce punct se vor dovedi ele eficace n practic.
Diagramele de componen
Diagramele de componen, a cror paradigm de reprezentare este dat n figura 14.6, constituie
concepte de configurare a programelor n pachete de programe, n fiiere surs sau n biblioteci. Aceste
concepte arat cum se leag ntre ele fiierele surs, pachetele de programe i bibliotecile, n cadrul
sistemului informatic proiectat. Astfel, n figura menionat sunt reprezentate pachetul de programe de tip
<<Applet>>, care cuprinde toate programele de interfa om-main (IOM) i care comunic cu pachetul de
programe de tip <<Baza de date>> numit Clieni. Cele dou pachete de programe pot fi amplasate pe maini
diferite sau n biblioteci diferite n cadrul sistemului informatic.

Fig. 14.6 - Diagrama de componen UML

Diagramele de desfurare
Diagramele de desfurare, a cror paradigm de reprezentare este ilustrat n figura 14.7, corespund
structurii de reea informatic ce preia sistemul de programe i modul n care sunt instalate componentele de
reea. Astfel, din figura 1.8 rezult c sistemul local este constituit din serverul central, la care sunt legate un
server de nlnuire i un server Web.

Fig. 14.7 - Diagrama de desfurare UML

Diagramele dinamice (sau comportamentale)
Diagramele dinamice, numite i diagrame comportamentale, arat cum interacioneaz ntre ele
diferitele elemente ale modelului. Diagramele dinamice sunt alctuite din:
- diagramele de activiti;
- diagramele de stare;
- diagramele de secven;

- diagramele de colaborare;
- diagramele de vedere de ansamblu a interaciunilor;
- diagramele de timing.
Diagramele de activiti
Diagramele de activiti, a cror paradigm de reprezentare este ilustrat n figura 14.8, reprezint
regulile de nlnuire ale activitilor n cadrul sistemului (de exemplu, navigarea ntr-un site Web).
Activitile sunt reprezentate prin dreptunghiuri ovalizate iar trecerea de la o activitate la alta prin sgei,
care se ntlnesc n noduri de stare marcate prin linii verticale. Ansamblul activitilor are un punct de intrare
i un punct de ieire, marcate ca n figur.

Fig. 14.8 - Diagrama de activiti UML

Diagramele de stare
Diagramele de stare, a cror paradigm de reprezentare este ilustrat n figura 14.9, reprezint ciclul
de via comun obiectelor unei aceleiai clase i permit completarea cunotinelor claselor, att n cadrul
analizei ct i n cazul concepiei. Convenia de reprezentare este invers ca la diagramele de activiti, cu
alte cuvinte strile sunt marcate prin dreptunghiuri cu coluri rotunjite iar drumul de la o stare la alta prin
sgei reprezentnd aciuni specifice. Ca i la diagramele de activiti, exist mai multe ci prin care se poate
ajunge de la o stare la alta. Alegerea unei ci sau a alteia depinde de condiiile n care se afl sistemul la
momentul respectiv. n diagramele din figurile 14.8 i 14.9 nu sunt menionate condiiile de alegere a cilor
prin care se poate ajunge de la o stare la alta.

Fig. 14.9 - Diagrama de stare UML

Diagramele de secven
Diagramele de secven, a cror paradigm de reprezentare este ilustrat n figura 14.10, servesc, n
primul rnd, dezvoltrii de scenarii n cadrul analizei utilizrii sistemului. n diagramele de secven
mesajele sunt reprezentate orizontal, pe o ax a timpului de sus n jos, de attea ori de cte ori apar.

Fig. 14.10 - Diagrama de secven UML

Diagramele de colaborare
Diagramele de colaborare, a cror paradigm de reprezentare este ilustrat n figura 14.11, servesc
aceluiai scop ca i diagramele de secven. n diagramele de colaborare exist o singur cale, care unete
dou elemente (clase, actori), mesajele care circul pe aceast cale mpreun cu sensul lor fiind marcate pe
marginea cii cu sgei. De obicei, diagramele de colaborare se construiesc pe baza diagramelor de secven
i ilustreaz schimburile de mesaje ntre obiecte n cazul anumitor funcionri particulare ale sistemului. Att
diagramele de secven ct i diagramele de colaborare fac parte din subclasa diagramelor de interaciune
UML.

Fig. 14.11 - Diagrama de colaborare UML

Diagramele de vedere de ansamblu a interaciunilor
Diagramele de vedere de ansamblu a interaciunilor (ineraction overview diagrams) sunt o
combinaie ntre diagramele de activiti i diagramele de secven.
Ele se pot considera fie diagrame de activiti n care activitile sunt nlocuite prin mici diagrame de
secven, fie diagrame de secven divizate, notaiile avnd menirea s uureze citirea acestor diagrame.
n figura 14.12 este prezentat un exemplu simplu al acestui tip de diagrame.

Fig. 14.12 - Diagrama de vedere de ansamblu a interaciunilor

Se dorete producerea i formatarea unei liste recapitulative a comenzilor. Dac clientul este extern,
obinem informaii ntr-un formular XML. Dac clientul este intern, l obinem dintr-o baz de date. Cele
dou diagrame de secven ne arat cele dou posibiliti. Odat obinute datele, putem emite lista
recapitulativ a comenzilor.
Acesta este un nou tip de diagram UML 2.0 i este nc prematur de a emite o idee referitoare la
modul n care va fi el utilizat n practic.
Diagramele de timing
Diagramele de timing reprezint o alt form de diagrame de interaciune, n care accentul este pus
pe constrngerile de timp, fie pentru un obiect, fie pentru un grup de obiecte.
S lum, pentru exemplificare, scenariul de funcionare al unei cafetiere electrice. Aceasta se
compune, n principal, din dou automate: cel al pompei de evacuare al preparatului de cafea i cel al plcii
nclzitoare. S presupunem c ntre activarea pompei i cea a plcii nclzitoare trebuie s treac un interval
de minimum 10 secunde. Atunci cnd rezervorul se golete, pompa se oprete, ns placa poate continua s
funcioneze nc 15 minute7.
n figura 14.13 este reprezentat diagrama de timing pentru acest caz.

7 Vezi [Fowler2] UML 2.0 CampusPress, 2004, pp. 181-189 (trad.l.engl. UML Distilled Third Edition, Addison Wesley, 2003),
pp. 171-172.

Fig. 14.13 - Diagrama de timing

Funcionarea celor dou pri principale, pompa i placa nclzitoare, este reprezentat pe aceeai
diagram a timpului. Modificrile de stare sunt semnalate prin schimbri de nivel ale liniilor continue care
urmresc procesul.
Liniile ntrerupte verticale sunt opionale i ajut la precizarea momentului n care are loc
evenimentul.
Diagramele de timing reprezint, de asemenea, o inovaie adus de UML 2.0.
Ele sunt utile pentru reprezentarea restriciilor temporale ntre schimbrile de stare ale diferitelor
obiecte.
n ncheiere, v prezentm n figura 14.14 o schem de clasificare a diagramelor UML 2.0 care
utilizeaz simbolul de generalizare/ particularizare promovat de acest standard 8. Spre deosebire de aceast
clasificare, care plaseaz diagramele cazuri de utilizare n clasa diagramelor comportamentale, noi am
preferat s ridicm acest tip de diagrame la un nivel superior, deoarece prezint att caracteristici de grupare
structural ct i proprieti comportamentale.
Printre caracteristicile structurale amintim:
- un caz de utilizare concentreaz n jurul su tot ce este semnificativ dintr-o aplicaie i care produce
un rezultat semnificativ pentru un anumit actor, adic obiecte, clase i proprietile acestora care prin
interaciune conduc la rezultatul vizat;
- gruparea claselor i obiectelor implicate ntr-un caz de utilizare seamn foarte mult cu aceea de
pachet de nivel superior, dar semnificaia sa este diferit, fiind legat esenial de comportament i scopul
final al acestuia.
Caracteristicile comportamentale rmn totui acelea eseniale i rezult din faptul c la baza
separrii elementelor proiectului st comportamentul care conduce la realizarea artefact-ului pentru actorul
n cauz.

8 Vezi [Fowler2] UML 2.0 CampusPress, 2004, pp. 181-189 (trad.l.engl. UML Distilled Third Edition, Addison Wesley, 2003),
p. 22.

Fig. 14.14 - Diagrama UML. Cazuri de utilizare