PREFAŢĂ

Proiectarea sistemelor informatice reprezintă astăzi o activitate deosebit de

complexă prin complexitatea problemelor abordate, care necesită deopotrivă
experienţă şi inventivitate, cunoştinţe despre ce s-a creat în domeniu şi despre
noile tehnologii informatice ce pot fi utilizate, despre succese şi eşecuri ale acestei
activităţi care este deopotrivă ştiinţifică, practică, imaginativă, creativă şi
aplicativă.
În condiţiile unei evoluţii spectaculoase, fără precedent, în domeniul hardware
şi software, a unor tehnologii moderne de comunicare, de prelucrare şi stocare a
datelor, proiectarea sistemelor informatice capătă noi valenţe, trebuie să ţină cont
de toate acestea la un loc şi, mai mult, de specificul activităţii beneficiarului, de
dorinţa acestuia de informatizare, dar şi de puterea sa financiară pentru susţinerea
acestora.
Dimensiunea nouă, impunătoare, atât a problematicilor abordate, cât şi a
costurilor antrenate pentru dotarea cu platforma hardware necesară şi pentru
proiectarea şi exploatarea sistemelor informatice impune cu necesitate o activitate
de proiectare a sistemelor informatice responsabilă, bine fundamentată, organizată
şi justificată economic. Spunem deci că responsabilitatea echipei de proiectare a
unui sistem informatic, a şefului de proiect creşte considerabil, cu atât mai mult
cu cât sumele de realizare antrenate sunt mai mari sau efectele colaterale mai
nocive.
În aceste condiţii specialiştii în informatică, alături de personalul implicat în
proiectarea şi realizarea sistemelor informatice trebuie să cunoască din punct de
vedere teoretic termeni, concepte, tehnici şi metode ce pot constitui instrumentarul
lor de lucru, dar şi modul de utilizare practică a acestora pentru modelarea corectă
a fenomenelor şi proceselor economice.
“Tehnologii informatice” reprezintă un termen actual, care defineşte
combinaţia dintre tehnologiile de calcul – formate din platforma hardware şi
software implicate – şi tehnologia informaţiei, reprezentată prin reţele de
transmitere a datelor, a imaginii, a sunetului.
Se ştie că sistemul informaţional este astăzi un element component al
sistemului de management, iar automatizarea sa prin introducerea prelucrării,
transmiterii şi stocării automate a datelor în diferite sectoare dă naştere sistemului
informatic. Practic orice sistem informaţional modern presupune includerea
tehnologiilor informatice în activităţile de culegere, prelucrare şi transmitere a
datelor. Cu alte cuvinte, mai mult ca oricând se pune azi problema proiectării unor
sisteme informatice integrate, a unor aplicaţii informatice sau produse program la
cheie, sau a reproiectării unora mai vechi, care nu mai corespund cerinţelor
actuale de informare şi posibilităţilor tehnice moderne de realizare a acestora.
Mutaţiile din domeniul tehnologiilor informaţionale şi cele din domeniul
metodelor de abordare a sistemelor se reflectă continuu în ciclul de viaţă al
5
sistemelor informatice, fie prin schimbări ale etapelor acestora, fie prin
schimbarea opticii de abordare şi parcurgere a acestora.
Noile tehnologii informatice influenţează direct proiectarea unui sistem
informatic nou sau fac necesară reproiectarea unui sistem existent, tocmai pentru a
ţine seama de ele.
În aceste condiţii – echipa de proiectare şi realizare a unui sistem informatic –
ţinând seama de ultimile noutăţi în domeniul tehnologiilor informatice, cunoscând
ultimile metode, tehnici şi strategii de realizare a sistemelor informatice – şi având
o bogată experienţă în domeniu, va trebui să analizeze, să modeleze şi să
reprezinte structura noului sistem.
Pe de altă parte, creşterea complexităţii problematicilor apărute, diversitatea
funcţiilor ce trebuie realizate, cerinţele ridicate faţă de calitatea prelucrărilor, au
impus necesitatea abordării sistemice, unitatea economico-socială fiind privită ca
sistem. Şi, cum metodele moderne se bazează pe aplicarea teoriei sistemelor în
analiza, proiectarea şi chiar realizarea efectivă a sistemelor informatice, se impune
prezentarea şi înţelegerea unor concepte de bază din teoria sistemelor.
Ţinând seama de toate acestea, manualul se adresează în primul rând
specialiştilor în informatică, oricare ar fi domeniul lor de competenţă, care doresc
să-şi clarifice aspecte legate de partea de proiectare propriu-zisă sau de
implementare a unui sistem informatic
Cartea se adresează într-un mod special studenţilor de la Facultatea de
Informatică Managerială din cadrul Universităţii Româno-Americane, care se
pregătesc acum să devină informaticieni de elită, specialişti în proiectarea
sistemelor informatice.
Cartea se adresează deasemenea tuturor celor care sunt sau vor fi implicaţi în
proiectarea sau reproiectarea sistemelor informatice singulare sau integrate, la
nivelul unei firme, grup de firme, administraţie publică sau la nivel naţional, ca
proiectanţi sau beneficiari ai sistemelor proiectate, deopotrivă.
Despre toate acestea, despre tehnici, tehnologii şi metode de abordare, de
proiectare şi realizare a sistemelor informatice veţi afla citind această carte.

Mult succes, vă doreşte

Autoarea

6
 1. SISTEMUL INFORMATIC – COMPONENTĂ A SISTEMULUI DE
MANAGEMENT
1.1.Unitatea economico-socială privită ca sistem

Teoria sistemelor îşi găseşte azi aplicarea în cea mai mare parte a domeniilor
vieţii economice şi sociale. Astfel, în prezent marea majoritate a teoriilor,
metodelor şi realizărilor societăţii umane sunt concepute, prezentate, proiectate,
realizate şi în general abordate prin prisma teoriei sistemelor.
La modul general, un sistem se poate defini ca un ansamblu de elemente
intercorelate funcţional, care acţionează într-un anumit scop. Orice sistem se
caracterizează prin următoarele:
a) intrările sistemului (Xi)
b) ieşirile sistemului (Yi)
c) obiectivele sistemului sau scopul final (Zi)
d) procesele ce au loc în cadrul sistemului (P)
e) starea sistemului la un moment dat
Putem reprezenta grafic un sistem ca în figura 1.1.

Fig.
1.1 Sistemul –
reprezentare grafică

Având în vedere
definiţia de mai sus,
putem spune că orice
unitate economică,
societate comercială individuală sau de grup, poate fi privită ca un sistem. Astfel,
în orice societate economică identificăm:
• Elementele sistemului, formate din compartimentele sau elementele
structurale ale acesteia (departamente, compartimente, birouri sau secţii, ateliere
etc..), între care se stabilesc relaţii (de subordonare sau colaborare) prevăzute prin
statutul societăţii, prin organigrama asociată acestuia şi/sau prin Regulamentul de
Organizare şi Funcţionare.

O societate economică oarecare poate fi privită şi prin prisma funcţiilor sale de

bază, ca elemente între care se stabilesc relaţii :
- Producţie sau Prestări Servicii
- Resurse Umane
- Financiar-Contabilitate
- Comercială (Aprovizionare-Desfacere)
- Cercetare –Dezvoltare
7
 - Marketing
• Scopul funcţionării oricărei societăţi este realizarea de produse sau
prestarea de servicii în vederea obţinerii unui profit;
• Intrările în sistem sunt reprezentate de resursele materiale, financiare şi
umane necesare pentru realizarea activităţilor din cadrul unei societăţi. O parte
dintre acestea se constituie de la început, sub formă de capital social, iar restul
constituie obiectul activităţilor de aprovizionare şi consum curente;
• Ieşirile din sistem sunt reprezentate de produsele şi serviciile vândute,
conform unor programe şi grafice de realizare şi desfacere, pe baza unor contracte
sau comenzi ferme;
• Procesele ce au loc în cadrul unei societăţi sunt reglementate şi descrise în
cadrul procesului tehnologic, a sarcinilor stabilite prin Regulamentul de Ordine şi
Funcţionare (ROF) pentru fiecare compartiment, birou sau post – prin Fişa
postului.
• Starea sistemului – unitate economică – este reflectată, în orice moment,
prin evidenţa financiară, contabilă, a personalului, prin indicatorii analitici şi
sintetici calculaţi în orice moment.
Putem reprezenta grafic sistemul oricărei unităţi economice ca în figura
1.2..

Fig. 1.2. Unitatea economică reprezentată ca sistem

Pe de altă parte, în cadrul unei unităţi economice identificăm două mari

subsisteme: subsistemul decizional sau de conducere şi subsistemul operativ sau
de execuţie.
Comunicarea între diferite subsisteme şi în cadrul acestora se realizează prin
intermediul sistemului informaţional. Dacă ne referim la o unitate economică ca
sistem cibernetic, sistemul informaţional se interpune între sistemul condus şi
sistemul de conducere, asigurînd comunicarea dintre ele (puntea de legătură) (fig.
1.3.).

8
 Orice sistem poate fi deci privit ca un ansamblu de elemente interconectate şi
intercondiţionate prin relaţii fizice, sociale şi de altă natură care funcţionează în
vederea realizării unui scop sau a finalizării unui obiectiv.
Procesele desfăşurate într-o activitate organizată nu au loc la întâmplare, ci
sunt declanşate de anumite informaţii, care prelucrate, servesc la luarea unor
decizii. Aceste decizii determină executarea unor serii de operaţii.
Deci, activitatea desfăşurată în vederea realizării unui obiectiv poate fi definită
ca fiind rezultatul acţiunii conjugate a trei subsisteme ce acţionează într-o strânsă
interdependenţă şi care la rândul lor pot fi considerate sisteme:
- sistemul de conducere, de management sau decizional (S.D.)
- sistemul condus, de execuţie sau operaţional (S.O.)
- sistemul informaţional.
Sistemul de conducere (de management) are rolul de a dispune şi îndruma
activitatea în vederea realizării obiectivelor fixate, cu eficienţă maximă.
Sistemul condus (operativ sau de execuţie) are rolul de a executa practic
deciziile luate şi de a furniza date privind acţiunile realizate sau în curs de
execuţie, folosind pentru aceasta resursele materiale, financiare şi umane
existente, repartizate pe obiective dinainte stabilite.
Pentru executarea activităţilor de bază ale procesului decizional: planificare,
urmărire, control şi decizie, sistemului de conducere îi sunt necesare informaţii
despre starea şi evoluţia sistemului de execuţie, despre legăturile acestuia cu
exteriorul. De la Sistemul de conducere spre sistemul condus vor circula
decizii. Acest circuit de informaţii şi decizii reprezintă un proces permanent care
se realizează prin existenţa Sistemului informaţional.
Sistemul informaţional este un instrument indispensabil conducerii, având
ca părţi componente mijloacele şi procedeele ce asigură legăturile între
elementele de execuţie şi elementele decizionale pentru conducere şi organizare.
În felul acesta prin sistemul informaţional se pot cunoaşte la timp şi în cantităţi
necesare toate elementele de caracterizare a activităţilor desfăşurate, el cuprinzând
fondul de informaţii, tehnicile de colectare şi stocare, mijloacele şi metodele
necesare în vederea prelucrării şi transmiterii informaţiilor.
Deci, sistemul informaţional este un ansamblu de fluxuri şi circuite
informaţionale organizate într-o concepţie unitară. El utilizează modele,
proceduri, resurse umane şi materiale pentru colectarea, înregistrarea, prelucrarea,
stocarea şi/sau transmiterea datelor şi a informaţiilor, prin intermediul cărora
asigură interconexiunile informaţionale dintre sistemul de conducere şi sistemul
condus, dintre elementele componente ale acestor sisteme, dintre organismul
social economic pe care îl serveşte şi mediul social economic extern. Sistemul
informaţional reprezintă deci un ansamblu de oameni, echipamente, software,
procese şi date destinate să furnizeze informaţii active sistemului decizional.

9
 Scopul final al sistemului Informaţional (SI) este realizarea obiectivelor proprii
organismului social-economic în concordanţă cu obiectivele generale ale societăţii
şi în condiţii de maximă eficienţă.
Sistemul informaţional primeşte intrări, le prelucrează şi furnizează ieşiri.
Intrările şi ieşirile unui Sistem informaţional sunt date, informaţii şi decizii.
Ansamblul operaţiilor la care sunt supuse intrările pentru a furniza ieşirile se
constituie în proceduri.
În funcţie de mijloacele şi procedeele utilizate pentru executarea operaţiilor,
acestea pot fi grupate în proceduri manuale, proceduri automate, proceduri
mecanizate sau mixte. În cazul când metodele, procedurile şi mijloacele utilizate
pentru colectarea, înregistrarea, prelucrarea, stocarea şi/sau transmiterea datelor şi
a informaţiilor sunt cu preponderenţă automatizate, sistemul informaţional
devine un sistem informatic.
De remarcat faptul că cele două noţiuni, cea de sistem informaţional şi cea de
sistem informatic nu sunt în mod substanţial diferite, din punct de vedere al
scopurilor urmărite şi al funcţiunilor îndeplinite, ele fiind identice (ca dovadă, în
limbajul de specialitate al altor ţări, pentru cele două noţiuni nu se utilizează
termeni diferiţi). Singura diferenţă se reduce la gradul de automatizare a
proceselor de prelucrare a datelor şi informaţiilor.
Sistemele informaţionale şi informatice, în plină expansiune de
acoperire/acaparare a activităţii umane prezente utilizează şi dezvoltă la rândul lor
teoria sistemelor, devenind din ce în ce mai complexe atât din punct de vedere
conceptual, dar şi din punct de vedere tehnic (echipamentele de prelucrare
automată a datelor având în prezent o dezvoltare explozivă).

Fig. 1.3. Unitatea economică ca sistem cibernetic

Putem privi sistemul informaţional al oricărei societăţi sub 2 aspecte:

a) static, în care caz presupune atât înregistrarea evenimentelor survenite în
baza informaţională cât şi înregistrarea structurilor de date, a regulilor şi a
restricţiilor în modelul datelor.

10
 b) dinamic, în care caz presupune procesarea informaţiilor (aducerea la zi a
datelor memorate) în baza de date şi schimbarea structurilor, regulilor şi
restricţiilor modelului de date.
În cadrul multora dintre societăţile comerciale confruntate cu concurenţa şi cu
apărarea segmentului de piaţă ocupat de acestea, problema unei organizări cât mai
bune a sistemului informaţional este una fundamentală, cu implicaţii majore în
buna organizare şi funcţionare a activităţii societăţii, în obţinerea de informaţii
valoroase, corecte, complete, oportune.
Mai buna organizare a sistemului informaţional ar putea duce, fără îndoială, la
eliminarea unor timpi “morţi” din activitatea factorilor responsabili, ar înlătura
redundanţa mare existentă în sistem, ar asigura condiţiile necesare obţinerii de
profituri mai mari. Şi astfel, sistemul informaţional reprezintă efectiv o
componentă de bază a sistemului de management; un sistem informaţional
modern, devenit practic un sistem informatic, aduce elemente noi, de
fundamentare ştiinţifică a deciziilor, de operativitate şi prelucrare complexă a
unor volume mari de date, ce pot fi acum stocate, accesate, interogate şi
transmise la distanţă prin noile tehnologii informatice.
Putem reprezenta schematic unitatea economică ca sistem, privită prin prisma
funcţiilor sale ca în fig. 1.4.:

1.4. Cele cinci funcţii ale unei întreprinderi

Orice post din cadrul unei societăţi bine organizate se află în unul din aceste
compartimente, şi, în acelaşi timp, la unul din nivelele de management ale
acesteia.
Nivelele Managementului
Se ştie că majoritatea oamenilor care lucreazã într-o societate nu sunt
manageri. La baza piramidei organizaţionale se află personalul de execuţie sau
operativ, care produce bunurile şi serviciile. La nivelele superioare se află diferite
nivele de manageri, specialişti deosebiţi în procesele ce se desfăşoară în
subordinea lor, atât ca mod de execuţie, cât şi ca mod de organizare (cum ar fi
supraveghetor, şef de echipă, maistru, şef de secţie, director, manager sau
preşedinte). Aceştia realizează planificarea, asigură conducerea, organizarea şi
verificarea necesarã , putând să intervină direct în executarea unor operaţii din
procesele de muncă, pentru a remedia deficienţele. În cadrul întreprinderilor,

11
managementul, aşa cum este văzut în literatura de specialitate, este împãrţit în trei
nivele: nivel operaţional (supraveghetori), nivel tactic (mediu) şi nivel strategic
(înalt) – fig. 1.5.

Fig .1.5. Cele trei nivele ale managementului

• Managerii de nivel operaţional, reprezentaţi de supraveghetori, şefi de
echipe, şefi de tură, şefi de colective, etc dau indicaţii şi monitorizeazã angajaţii,
personalul de execuţie din subordine, pe aceia care execută efectiv procesele de
muncă. Astfel, aceşti manageri au responsabilitatea numitã probleme operaţionale
(de fabricaţie). Ei monitorizeazã evenimentele de zi cu zi, informaţiile de detaliu
din timpul desfăşurării procesului de muncă şi imediat acţioneazã corespunzãtor,
dacã este necesar. De exemplu, la un hotel, şeful de etaj verifică dacă toate
camerele sunt curate şi au toate dotările necesare, dacă cele eliberate au fost
imediat curăţite, dacă există nemulţumiri ale clienţilor, dacă personalul din
subordine îşi respectă sarcinile şi programul de lucru din fişa postului. Dacă se
constată abateri sau nereguli, supraveghetorul trebuie sã acţioneze imediat, să
rezolve situaţia sau, dacă îl depăşeşte, să comunice mai departe, nivelului ierarhic
superior.
• Managerii de nivel mediu (tactic) sunt responsabili cu verificarea,
planificarea (care mai este numitã planificare tacticã) şi luarea-deciziilor. Ei
stabilesc obiectivele pe termen lung ale întreprinderii. De exemplu, managerul
local al unui hotel stabileşte politica de cazare şi de contractare pe termen lung a
hotelului, în timp ce managerul restaurantului, cunoscând şi datele de cazare, îşi
stabileşte propriile măsuri şi oferte de masă, astfel încât să aibă cît mai mulţi
clienţi la masă, să obţină deci un profit cât mai mare.
• Managerii de nivel înalt (strategic) sunt preocupaţi de planificarea pe
termen lung (denumitã şi planificare strategicã). Ei au nevoie de informaţii care îi
vor ajuta sã planifice creşterea viitoare şi direcţia de mers a întreprinderii. În
condiţiile actuale, când volumul mare de date care circulă nu mai poate fi stăpânit
şi prelucrat manual, se impune realizarea unor baze de date şi utilizarea unor
12
programe sau pachete de programe care să ajute sau doar să asiste managerul în
luarea unor decizii. Numai prelucrând volume mari de date se pot face estimări ale
evoluţiei viitoare a unui fenomen, se pot face previziuni fundamentate ştiinţific şi
se pot lua măsuri pentru bunul mers al societăţii în viitor.

1.2. Conceptul de sistem cibernetic

Un sistem cibernetic este un sistem cu autoreglare, deci un sistem care,

sesizând diferenţa dintre rezultate şi aşteptări (ieşiri şi obiective), are capacitatea
de a acţiona în consecinţă, pentru a elimina acele deficienţe.
Se ştie deasemenea că asupra oricărui sistem acţionează o serie de factori care
pot să perturbe desfăşurarea normală a activităţilor din sistemul de referinţă.
La nivelul oricărei societăţi economice managerii (factorii de decizie) caută să
intervină în scopul preîntâmpinării sau înlăturării factorilor perturbatori, astfel
încât să fie asigurate condiţiile unei bune desfăşurări a activităţilor din cadrul
sistemului.
În general, factorii de decizie vor interveni şi vor regla starea sistemului atunci
când se constată o neconcordanţă între ieşirile sistemului şi obiectivele stabilite
ale sistemului.
Intervenţia managerilor se manifestă printr-un factor de reglare, pe care îl vom
nota cu ΔX (fig. 1.6.). Forma de intervenţie poartă denumirea de buclă de reglare
(conexiunea inversă sau feed-back). Acţiunea (intervenţia) are loc atâta timp cât
există diferenţe între ieşirile obţinute şi obiectivele stabilite.
Ţinînd cont de aceste sarcini ale sistemului de management, atunci când îl vom
studia pentru realizarea unui sistem informatic, va trebui să identificăm metodele
şi stilul de conducere practicat, informaţiile necesare şi forma exactă de
prezentare a acestora, astfel încât prelucrarea automată să-i ofere mai repede,
mai corect şi cu gradul de sintetizare necesar acele informaţii de care are
nevoie, pentru ca actul decizional să fie oportun şi bine fundamentat.

Fig. 1.6. Un sistem cibernetic

Modul cibernetic de a aborda fenomenele şi procesele economice, de a

organiza şi conduce sistemele economice, de a realiza simbioza micro-

13
macroeconomie, reprezintă o realitate evidentă, a cărei valabilitate este confirmată
pe deplin de realizările concrete obţinute în practica economică. Aplicarea
metodelor ciberneticii economice în rezolvarea problemelor organizării şi
conducerii economice, în proiectarea traiectoriilor de creştere economică dorită, în
realizarea unui dialog continuu între comandă-decizie şi complementul ei control-
reglare, a devenit un element constitutiv al conducerii ştiinţifice.
Direcţia principală de dezvoltare este promovarea metodelor moderne bazate
pe mijloace de calcul şi prelucrare electronică a datelor, extinderea cercetărilor de
cibernetică economică şi a celor de informatică, de conducere şi de gestiune a
întreprinderilor.

1.3. Conceptul de sistem informaţional

Sistemul informaţional reprezintă un ansamblu de metode, tehnici,

metodologii şi proceduri de culegere, verificare, transmitere, stocare şi
prelucrare a datelor necesare factorilor de conducere în procesul de
fundamentare şi elaborare a deciziilor.
În cadrul sistemului informaţional apar o serie de alte concepte dintre care:
• conceptul de date – reprezintă mesaje, caractere sau simboluri prin
intermediul cărora se descriu fenomenele şi procesele economice sau se cuantifică
acestea.
• conceptul de informaţie – reprezintă un caz particular al datelor; pentru ca
datele să poată fi considerate informaţii acestea trebuie să îndeplinească 3
condiţii:
- să aibă semnificaţie.
- să prezinte interes.
- să aducă un spor de cunoaştere beneficiarului ei.
• conceptul de decizie – reprezintă un caz particular al informaţiei;
deosebirea dintre informaţie şi decizie constă în faptul că decizia va avea un
caracter imperativ, un rol de directivă pentru cei cărora se adresează şi asupra
cărora decidentul are autoritate.

1.3.1. Parametri de eficienţă

În orice activitate organizată de om există o permanentă circulaţie a infor-

maţiilor. Fiecare persoană angrenată în execuţia sau dirijarea unei activităţi
participă la această circulaţie şi utilizează informaţii pentru lucrările care sunt în
sarcina sa. Dacă pentru rezolvarea unei probleme există mai multe soluţii,
lucrătorul care prelucrează este nevoit să opteze pentru una din ele. Pentru aceasta
însă, el are nevoie de un criteriu de judecată.

14
 În cazul în care o astfel de alegere efectuată pe baza unui proces raţional în
vederea realizării unui obiectiv, are implicaţii în activitatea altor persoane,
avem de-a face cu o decizie.
Pentru ca aplicarea deciziei luate de o persoană să nu fie împiedicată sau chiar
anulată de împotrivirea acelora cărora le este destinată, cel ce ia decizia trebuie să
fie investit cu autoritatea necesară. Totodată, pentru ca să existe suficientă
garanţie că decizia luată este de bună calitate, asigurând realizarea în condiţii
optime a obiectivului propus, cel ce o elaborează trebuie să posede competenţa
profesională corespunzătoare naturii deciziilor sale.
În sistemul informaţional, deciziile pot constitui la rândul lor informaţii care
sunt stocate, prelucrate şi transmise pentru a fi utilizate la luarea altor decizii cu
implicaţii la nivelele inferioare, pentru transpunerea lor în practică.
O activitate este reprezentată de o sumă de acţiuni care sunt dependente sau
nu între ele, care se influenţează sau nu reciproc şi pentru a căror declanşare este
necesară luarea de decizii.
Sistemul informaţional furnizează permanent sistemului decizional
informaţii asupra modului de desfăşurare a unei activităţi în diverse sectoare
sau locuri de muncă din interiorul sau din exteriorul acesteia.
Sistemul decizional analizează aceste informaţii, le prelucrează şi pe baza lor
generează alte decizii. Aceste decizii se transmit sistemului de execuţie tot prin
sistemul informaţional şi pot duce fie la declanşarea unei alte acţiuni, fie la
modificarea sau stoparea celor ce sunt în plină desfăşurare.
În felul acesta ia naştere un adevarat ciclu informaţie – decizie - acţiune, ce
se poate descompune în două părţi principale, ţinând seama de faptul că
sistemul informaţional furnizează informaţii şi decizii atât sistemului
operaţional cât şi celui decizional.
Parametri de caracterizare a celor două părţi ale ciclului informaţie - decizie
- acţiune sunt:
a) timpul de elaborare a informaţiei, adică timpul dintre momentul în care
începe colectarea datelor din sistemul operaţional şi momentul transmiterii
informaţiilor sistemului decizional şi cuprinde:
. timpul de colectare a datelor şi de control al veridicităţii acestora;
. timpul de transmitere a datelor în sistemul informaţional şi de control al
acestora;
. timpul de prelucrare şi controlul prelucrării;
. timpul de transmitere a datelor sistemului de conducere.
b) timpul de reacţie, adică timpul care se scurge între momentul în care
informaţiile prelucrate ajung în sistemul operaţional şi momentul când acesta
acţionează, adică declanşează acţiunea la decizia primită.
Organizarea, reorganizarea sau îmbunătăţirea funcţionării unui sistem
informaţional trebuie să includă atât analizarea timpilor de elaborare a
informaţiilor cât şi timpii de reacţie a Sistemului Decizional şi Sistemului
15
Operativ. Deci nu se poate acţiona asupra unuia din cele 3 sisteme, fără a ţine
seama de reacţiile provocate asupra celorlalte două.
În analizarea etapelor de elaborare a informaţiilor, trebuie să se ţină seama de
următoarele considerente:
- erorile de colectare nu sunt eliminate de folosirea echipamentelor moderne,
care pot elimina aproape complet numai erorile de prelucrare;
- colectarea şi transmiterea datelor trebuie să fie precedate şi urmate de
controale;
- intervenţia omului va fi totdeauna în ciclul elaborării informaţiilor,
probabilitatea apariţiei erorilor putând fi redusă numai printr-o raţională proiectare
a sistemului informaţional.
Timpii de reacţie a Sistemului Decizional (S.D) şi Sistemului Operativ (S.O)
constituie un factor determinant al eficienţei funcţionării unui sistem
informaţional.

1.3.2. Principalele cerinţe ale unui sistem informaţional

La nivelul oricărei societăţi, sistemul informaţional trebuie să satisfacă o

serie de cerinţe, care pot fi sintetizate astfel:
a) Să asigure informaţiile necesare şi cu gradul de prelucrare dorit la
toate nivelele decizionale.
Relevant în privinţa acestui aspect este principiul piramidei informaţionale,
care reprezintă grafic volumul informaţiilor vehiculate la diferite nivele (fig. 1.9).
Nivelul inferior al piramidei deţine o multitudine de informaţii cu un grad înalt
de detaliere, ce se difuzează în principal pe orizontală.
Deasupra acestui nivel se găsesc, succesiv, alte nivele de decizie, fiecare din
acestea răspunzând pentru realizarea obiectivelor (sarcinilor) de către verigile
subordonate.Volumul informaţional se restrânge treptat de la nivelul inferior spre
nivelul superior, prin prelucrare şi sintetizare.
b) Operativitatea informării. Informaţiile necesare trebuie furnizate la
timp. Realizarea acestei cerinţe necesită stabilirea în prealabil atât a conţinutului şi
volumului informaţiilor cât şi a termenelor la care acestea trebuie să fie furnizate.
c) Selectarea informaţiilor. Aceasta cerinţă se referă la necesitatea ca
fiecare destinatar să primească numai acele informaţii de care are nevoie în
exercitarea atribuţiilor ce îi revin, în sensul de a primi numai informaţii utile,
selectarea acestora de informaţiile neutile făcându-se înainte de transmiterea către
destinatar.
d) Adaptabilitatea la modificări. Un sistem informaţional trebuie să fie
uşor adaptabil la modificările ce pot apare şi care pot fi:
- modificări ale cererilor de informaţie;
- modificări ale datelor de intrare;

16
 - modificări ale structurii organizatorice;
- modificări ale metodelor de prelucrare a datelor.

Observaţie:
Sistemul informaţional există deci la nivelul oricărei societăţi economice, de
orice tip, încă din momentul înfiinţării ei; se ştie că prin statutul societăţii sunt
prevăzute structura organizatorică şi sarcinile, responsabilităţile diferitelor nivele
de conducere, iar prin Fişa postului sarcinile individuale.

Sistemul informaţional este, altfel spus, ansamblul elementelor implicate în

procesul de colectare, transmisie, prelucrare, sintetizare şi valorificare de
informaţii în cadrul oricărei societăţi economico-sociale.
Rolul sistemului informaţional este de a transmite informaţia între diferitele
elemente implicate în prelucrare. De exemplu, în cadrul unei unităţi economice,
rolul sistemului informaţional este de a asigura persoanele din conducere cu
informaţii necesare pentru luarea diferitelor decizii economice sau de altă natură
şi de a transmite personalului de execuţie deciziile luate.
El se realizează practic prin cele trei forme de evidenţă existente la nivelul
oricărei societăţi, şi anume:
- evidenţa tehnic-operativă
- evidenţa contabilă
- evidenţa statistică.
Evidenţa tehnic-operativă are un caracter operativ, înregistrând fenomenele
economice în momentul şi la locul producerii lor, ceea ce înseamnă că încă se
poate interveni în desfăşurarea lor. Astfel, dacă ne referim la o activitate
comercială, evidenţa operativă înregistrează pe loc intrările de materiale, ieşirile
din magazie şi calculează stocurile curente de materiale sau produse. Dacă ne
referim la activitatea de recepţie din cadrul unui hotel, această evidenţă vizează
înregistrarea pe loc a cazărilor efectuate, a ieşirilor din hotel cu decontarea
serviciilor consumate, astfel încât să existe în orice moment o oglindă a camerelor
libere şi ocupate, a încasărilor efectuate şi a tuturor serviciilor consumate.
Evidenţa contabilă nu mai are carater operativ, ci unul istoric, deoarece
înregistrează fenomenele economice după ce ele s-au desfăşurat, deci fără a mai
putea interveni în desfăşurarea lor. Ea este însă necesară şi obligatorie, căci
prelucrând datele referitoare la intrările şi ieşirile din societate, de orice fel
(materii şi materiale, resurse umane sau financiare, etc) se obţine oglinda reală a
resurselor de care dispune societatea pentru a începe o nouă perioadă (ciclu) de
viaţă (o nouă lună). Evidenţa contabilă este reglementată prin acte normative
(legea contabilităţii), prin norme metodologice de aplicare a legii, deci este, în
mare parte, similară, pentru aceleaşi categorii de societăţi (cu activităţi
asemănătoare). Totuşi, asupra activităţii contabile îşi pune amprenta şi experienţa

17
contabilului şef (sau director economic), personalitatea şi stilul de conducere al
acestuia.
Evidenţa statistică, cu un caracter pronunţat istoric, serveşte pentru realizarea,
pe baza unor volume mari de date privind perioadele anterioare, a unor prognoze,
estimări, previziuni cu privire la evoluţia viitoare a fenomenelor. Aceasta
presupune însă existenţa unor baze de date şi programe care să le prelucreze în
mod automat, deci existenţa calculatorului în cadrul sistemului informaţional.

Pe de altă parte, sistemul informaţional cuprinde, legat de circulaţia

informaţiilor pe documente, următoarele elemente de structură:
- fluxuri informaţionale
- circuite informaţionale
Fluxul informaţional este ansamblul datelor, informaţiilor şi deciziilor
necesare desfăşurării unei anumite operaţii, acţiuni sau activităţi. Fluxul
informaţional este caracterizat prin conţinut, volum, frecvenţă, calitate, formă,
suport, proces de obţinere şi cost.
Fluxurile informaţionale sunt vehiculate pe trasee prestabilite, denumite
circuite informaţionale.
Circuitul informaţional reprezintă multitudinea compartimentelor
organizatorice prin care circulă documentele primare sau mesajele de la sursă
până la destinaţia finală.
Fluxul informaţional reprezintă deci cantitatea de informaţii (volumul de
date) care se vehiculează în cadrul circuitului informaţional; prin analogie,
circuitul informaţional poate fi asociat cu sistemul de conducte, iar fluxul
informaţional cu debitul apei ce circulă prin conducte.
Identificarea fluxului informaţional şi a caracteristicilor calitative şi cantitative
ale acestora constituie o activitate importantă pentru stabilirea cerinţelor
informaţionale şi realizarea sistemului informatic. Deasemenea raţionalizarea
circuitelor informaţionale în vederea eliminării redundanţei datelor şi a asigurării
unicităţii intrării lor în sistem sunt cerinţe prioritare ale activităţii de reproiectare
sau raţionalizare a unui sistem informaţional.

1.4. Conceptul de sistem informatic

1.4.1. Prezentare generală

În cadrul sistemului informaţional se regăsesc: informaţia vehiculată,

documentele purtătoare de informaţii, personalul, mijloace de comunicare,
sisteme de prelucrare a informaţiei, etc. Printre posibilele activităţi desfăşurate în
cadrul acestui sistem, pot fi enumerate: achiziţionarea de informaţii din sistemul
de bază, completarea documentelor şi transferul acestora între diferite
compartimente, centralizarea datelor, etc.

18
 J.C. Emery, vorbind despre sistemul informaţional, identifică în cadrul acestuia
componente ce execută funcţii bine stabilite: recunoaşterea, transmiterea,
stocarea, compararea şi distribuirea informaţiei.
H.C. Lucas arată că sistemul informaţional se referă la totalitatea procedurilor
organizate, astfel încât să permită furnizarea de informaţii necesare luării
deciziilor şi/sau controlului organizaţiei.
În cadrul sistemului informaţional, majoritatea activităţilor se pot desfăşura
acum cu ajutorul tehnicii de calcul. Se pot prelucra datele primare şi apoi,
rezultatul poate fi transferat mai departe, către alt compartiment spre prelucrare.
Transferul se poate face şi el pe cale electronică, prin intermediul unei reţele de
calculatoare sau cu ajutorul modemului.
Ansamblul de elemente implicate în tot acest proces de prelucrare şi
transmitere a datelor pe cale electronică alcătuiesc un sistem informatic. Acesta
poate fi astfel definit ca un ansamblu de principii, concepte, reguli şi tehnici
folosite pentru culegerea, înregistrarea şi transmiterea datelor în vederea
prelucrării automate, pentru a obţine informaţii care stau la baza luării deciziilor
Sistemul informatic reprezintă deci un ansamblu de metode, metodologii,
tehnici şi proceduri automate de culegere, verificare, transmitere, stocare şi
prelucrare a datelor în scopul satisfacerii cerinţelor informaţionale necesare
conducerii în procesul de fundamentare şi elaborare a deciziilor.
Comparând definiţia sistemului informaţional cu definiţia sistemului informatic
se poate deduce faptul că sistemul informatic reprezintă partea automatizată a
sistemului informaţional.
Trecerea la prelucrarea automată a informaţiilor, deci transformarea unui
sistem informaţional într-unul informatic este o problemă tehnică de înaltă
specialitate, laborioasă, ce necesită o perioadă relativ mare de timp de realizare.
Experienţa naţională şi internaţională arată că pentru a rezolva cu succes şi
optim această trecere e necesară parcurgerea unor etape bine definite.
S-au elaborat mai multe metodologii şi tehnici de investigare, de proiectare şi
realizare practică a unui sistem informatic, care stabilesc etapele şi documentaţia
necesară pentru finalizarea unei lucrări de acest gen.
Nu trebuie neglijat faptul că sistemul informatic, ca parte componentă a
sistemului informaţional, trebuie să satisfacă toate cerinţele unui sistem
informaţional şi chiar să ducă la raţionalizarea, la simplificarea acestuia prin
automatizarea unor proceduri manuale, să conducă la o creştere a calităţii
informării, a complexităţii şi operativităţii ei.
Prin realizarea unui sistem informatic sau produs-program se înţelege acea
parte a ciclului său de viaţă care constă din: elaborarea proiectului, a
programelor asociate, a documentaţiei de utilizare, exploatare şi întreţinere,
punerea în funcţiune la cel puţin o unitate beneficiară până la recepţionarea
sau omologarea sa.

19
 Fig. 1.7. Sistemul informaţional şi informatic

În ceea ce priveşte sfera de cuprindere a sistemului informatic se poate spune

că aceasta tinde să egaleze sfera de cuprindere a sistemului informaţional, însă
egalarea nu se va realiza niciodată. Există şi vor exista o serie de activităţi sau
proceduri care nu pot fi automatizate integral - de exemplu controlul formal
efectuat de C.F.I. (controlul financiar intern), etc.

Observaţie : În unele ţări se face distincţie între cei doi termeni: sistem
informaţional şi sistem informatic, dar în altele nu se mai face nici o distincţie. În
prezent orice sistem informaţional tinde să devină sistem informatic, iar sistemul
informatic tinde să cuprindă o parte din ce în ce mai mare din sistemul
informaţional.

Prezenţa sistemului informatic în cadrul sistemului informaţional imprimă

acestuia o serie de valenţe sporite de ordin cantitativ şi calitativ. Un sistem
informaţional modern nu poate fi conceput fără o parte semnificativă de culegere,
transmitere şi prelucrare automată a datelor, folosind noile tehnologii informatice,
deci fără un sistem informatic.
Elementele componente ale sistemului informatic sunt:
a). Baza tehnico-materială a sistemului
Include multitudinea echipamentelor de culegere, verificare, transmitere,
stocare şi prelucrare a datelor. În cadrul acestora rolul hotărâtor îl deţine
calculatorul electronic şi/sau reţeaua de calculatoare. Mai pot fi incluse liniile de
comunicaţii pentru sistemele informatice concepute în regim de teleprelucrare
precum şi echipamentele corespunzătoare transmisiei datelor, purtătorii tehnici de
informaţii (discuri magnetice, diskete, Cd-uri etc.).
b). Sistemul de programe ( software-ul sistemului)
Include sistemele de operare, S.G.B.D.-urile şi programele de aplicaţii ale
utilizatorilor.
20
 c). Baza informaţională
Include multitudinea datelor stocate ce urmează a fi prelucrate.
În cadrul sistemelor informatice baza informaţională este organizată sub formă
de fişiere sau baze de date.
d). Aparatul ştiinţific şi matematic
Include multitudinea metodelor, metodologiilor şi tehnicilor utilizate în
activităţile de realizare a sistemelor informatice, precum şi multitudinea modelelor
matematice implementate în cadrul acestora.
e). Factorul uman şi cadrul organizatoric
Factorul uman include categoriile de personal specializate în domeniul
informaticii (analişti, programatori, operatori, ingineri de sistem, administratori de
baze de date şi/sau de reţele). Cadrul organizatoric defineşte acele structuri
organizatorice capabile să asigure buna desfăşurare a activităţii de informatică la
nivelul unităţilor economice.
În prezent asistăm la o pronunţată descentralizare a activităţii de informatică,
însă la nivelul unei unităţi economice pot exista structuri organizatorice de forma :
oficii de calcul (staţii de calcul) şi departamente de informatică.

1.4.2. Clasificarea sistemelor informatice

Sistemele informatice se pot clasifica după mai multe criterii, astfel:

A.În funcţie de domeniul de aplicabilitate
1. sisteme informatice pentru conducerea activităţilor unităţilor
economico-sociale
2. sisteme informatice pentru conducerea proceselor tehnologice
3. sisteme informatice pentru activităţile de cercetare-proiectare
4. sisteme informatice speciale

Sistemele informatice pentru conducerea activităţilor unităţilor economico-

sociale au ca specific faptul că intrările sistemului sunt reprezentate în general de
date, culese de pe documente primare elaborate de factorul uman, iar ieşirile se
concretizează în date prelucrate, reprezentate sub formă de situaţii de informare-
raportare destinate tot factorului uman. Ele servesc pentru prelucrarea automată a
datelor din diverse domenii de activitate, mai rapidă, mai corectă, cu posibilităţi
de prelucrare, verificare, sintetizare mult sporite prin utilizarea calculatorului
electronic.
Sistemele informatice pentru conducerea proceselor tehnolgice au ca specific
faptul că intrările reprezintă mărimi fizice sub formă de impulsuri (temperatură,
presiune, umiditate) preluate de la instalaţii, maşini, agregate direct din procesul
tehnologic în timpul desfăşurării lui şi care apoi, prelucrate, au drept ieşiri tot
impulsuri care declanşează anumite dispozitive prin care se reglează automat

21
procesele tehnologice (temperatura, umiditatea, presiunea, etc). Această categorie
de sisteme informatice o regăsim în locurile unde este pereclitată intervenţia
factorului uman. Obiectivul unor astfel de sisteme constă în sporirea
randamentului maşinilor, instalaţiilor şi agregatelor, dar şi în creşterea
considerabilă a calităţii produselor fabricate. De exemplu, în centralele nucleare,
în petrochimie, în industria farmaceutică, dar şi în industria alimentară (fabricarea
berii, a drojdiei de bere, etc).
Sistemele informatice pentru activităţile de cercetare-proiectare sunt destinate
spre a uşura documentarea ştiinţifică, elaborarea proiectelor, efectuarea calculelor
ştiinţifice, elaborarea studiului tehnico-economic.
Ele sunt destinate să fie utilizate de către cercetătorii şi personalul care lucrează
în acest domeniu. Aceste categorii de personal folosesc pe lângă sistemele
informatice existente şi sisteme specializate, numite sisteme bazate pe cunoştinţe
pentru a crea informaţii în sectorul lor. De exemplu, inginerii implicaţi în
proiectarea produsului şi producerea lui folosesc sisteme informatice în proiectare,
sisteme informatice în procesul de fabricaţie. fabricaţie Aceste sisteme utilizează
calculatoare foarte performante, care rulează programe speciale care integrează
informaţia necesară activităţii de proiectare cu informaţia provenită din activităţile
de fabricaţie. Sistemele computerizate care ajută în proiectarea şi fabricarea
produsului sunt larg utilizate în producţia de automobile şi a altor produse.
Sistemele informatice speciale se referă la sistemele din domeniul evidenţei
populaţiei, poliţie, S.R.I.

B.În funcţie de specificul domeniului abordat, sistemele informatice pot fi

grupate astfel:
1. Sisteme informatice pentru conducerea activităţii comerciale
(aprovizionare-desfacere). În cadrul acestora putem identifica o serie de aplicaţii
de prelucrare automată a datelor, cum sunt:
- Gestiunea stocurilor de materii prime, materiale, servicii şi utilităţi;
- Gestiunea stocurilor de produse finite, semifabricate şi mijloace fixe;
- Controlul automat al gradului de lichidare a creanţelor şi a stadiului plăţii
furnizorilor;
- Cunoaşterea influenţei unor pîrghii de marketing asupra stabilităţii, pe piaţă,
a societăţii comerciale.
- Urmărirea modului de derulare a contractelor încheiate cu partenerii
societăţii şi evidenţierea cantităţilor restante sau livrate în avans acestora.

2. Sisteme informatice pentru conducerea activităţii de producţie.

În această categorie sunt incluse o serie de aplicaţii informatice care vizează
următoarele activităţi :
- lansarea în fabricaţie;
22
 - programarea producţiei;
- întreţinerea şi funcţionarea utilajelor;
- calculul necesarului de combustibil şi de energie electrică destinată
necesităţilor tehnologice.
Dintre aplicaţiile informatice care pot fi realizate în acest domeniu se pot
menţiona :
• Cele care vizează structura de producţie a societăţii comerciale, în cadrul
lor putând fi dezvoltate module informatice care urmăresc:
- amplasarea optimă a utilajelor în cadrul secţiilor de producţie;
- utilizarea raţională a capacităţilor de producţie prin corelarea cererii pieţei
cu dimensiunea optimă a nomenclatorului de fabricaţie;
- determinarea automată a susccesiunilor optime între fazele procesului de
producţie. Aplicaţiile informatice din acest modul urmăresc optimizarea
proceselor economice prin intermediul unui aparat economico-matematic adeseori
foarte complex.
• Aplicaţii informatice pentru activităţile de programare, lansare şi urmărire
a producţiei care conţin modulele :
- determinarea momentelor optime de lansare în fabricaţie a loturilor de
produse, urmărind încadrarea societăţii în obligaţiile contractuale asumate faţă de
clienţii săi;
- stabilirea loturilor optime ce urmează a fi lansate la un moment dat în
fabricaţie.
Aplicaţiile din această categorie sunt uzuale atunci când lansările în fabricaţie
se fac pe bază de comenzi şi sunt caracteristice îndeosebi societăţilor în care
producţia este de serie mică şi unicate.
- urmărirea automată a modului de derulare a procesului de producţie pe toată
durata fabricării cantităţilor dintr-un anumit lot. Pe plan mondial există preocupări
de extindere a acestor aplicaţii la prelucrări automate ale datelor care urmăresc
simularea desfăşurarii diverselor activităţi economice în timp.

3. Sisteme informatice privind forţa de muncă (personalul), cuprind aplicaţii

de tipul:
- Evidenţa personalului;
- Calculul salariilor;
- Fişe fiscale, etc..
4. Sisteme informatice pentru conducerea activităţii financiar-contabile, care
pot cuprinde aplicaţii informatice specifice activităţilor de evidenţă financiar–
contabilă, cum sunt:
- Elaborarea şi evidenţa automată a notelor contabile, soldurilor de materii
prime şi produse finite şi a balanţei de verificare analitică şi sintetică.

23
Trebuie subliniat faptul că această categorie de aplicaţii informatice ar trebui
completată cu o serie de proceduri automate care să asigure analiza asistată de
calculator a datelor din bilanţurile contabile.
- Evidenţa automată a plăţii şi încasării facturilor, urmărind evidenţierea şi
reflectarea în costuri a tuturor categoriilor de plăţi efectuate de societate sau către
societate. Este o categorie de aplicaţii foarte solicitate în prezent, deoarece
societăţile înregistrează în urma blocajului financiar creanţe care influenţează
negativ bugetul de venituri şi cheltuieli al acestora. În plus, achitarea între
societăţi poate fi făcută şi în regim de compensare, activitate imposibil de
evidenţiat într-un sistem manual de prelucrare a datelor.
- Dezvoltarea unor aplicaţii informatice care să asigure suportul logistic în
procesul de negociere a preţurilor. Aceste aplicaţii urmăresc crearea unor
instrumente decizionale care să permită societăţilor comerciale perfectarea unor
contracte prin negocieri în condiţiile păstrării profitului antecalculat într-o
anumită plajă de valori dorită. Esenţa acestor aplicaţii informatice constă în
elaborarea automată a unor costuri de producţie antecalculate prin variaţii
acceptabile ale elementelor care intră în structura costurilor (articole de calculaţie
sau elemente primare). Prin aceste costuri de producţie antecalculate
fundamentate pe o anumită tehnologie de fabricaţie a produselor, societatea
comercială are posibilitatea să cunoască aprioric în ce interval poate varia preţul
de vânzare cu amănuntul, astfel încât profitul total să ramână cel dorit.
- Elaborarea automată a jurnalelor de operaţii contabile. Aceste operaţii se
doresc a fi un suport în procesul de analiză economică, deoarece evidenţiază
variaţiile valorilor intrate în debitele şi creditele conturilor, precum şi influenţa lor
asupra soldurilor finale.
- Elaborarea activităţilor de postcalcul asistate de calculator, concomitent cu
evidenţierea cheltuielilor de producţie efective şi compararea acestora cu nivelele
planificate. În societăţile comerciale există deja implementate o serie de produse
software care permit evidenţierea acestor abateri şi defalcarea lor pe cauze
obiective şi subiective. Această categorie de aplicaţii a permis implementarea în
cadrul societăţilor comerciale a metodei de conducere de tip tablou de bord asistat
de calculator.
- Aplicaţii informatice integrate, care asigură intercorelarea activităţilor
financiar-contabile cu cele de producţie şi cu activităţile comerciale. Necesitatea
existenţei acestora este dată de faptul că esenţa activităţii economice din orice
societate comercială este definită prin tripletul: cerere, producţie, resurse, care
implică activităţi din funcţiunea financiar contabilă, de producţe şi comercială.
Toate aplicaţiile informatice complexe enumerate mai sus trebuie precedate de un
ansamblu de aplicaţii mai simple care urmăresc gestiunea contabilă a mijloacelor
fixe, obiectelor de inventar, pieselor de schimb, materiilor prime şi materialelor,

24
produselor finite etc., precum şi de o serie de produse informatice care asigură
calculul automat al salariilor.
5. Sisteme informatice de birou sunt proiectate, în primul rând, să ajute
personalul care lucrează cu datele din sistemul obiect (angajaţii care se ocupă cu
culegerea, stocarea, prelucrarea şi difuzarea datelor). Aceste sisteme se bazează în
principal pe procesarea documentelor, pe comunicaţii şi pe stabilirea planului de
muncă. Documentele sunt procesate utilizând un procesor de texte, programe de
calcul tabelar, tehnologii de preluare a imaginilor, etc. Comunicaţiile se realizează
prin e-mail, mesagerie vocală şi video-conferinţă.
Aceste sisteme informatice au atribuţii pe linia prelucrării şi comunicării
informaţiei în cadrul compartimentelor firmei şi între firmă şi mediul extern.
Principalii utilizatori sunt personalul din activităţile de secretariat, managerii etc.
Un produs software reprezentativ pentru această clasă de sisteme informatice este
produsul integrat MS OFFICE (cu componentele WORD, EXCEL, POWER
POINT, ACCESS şi altele care asigură servicii INTERNET).

C. În funcţie de poziţia ierarhică pe care se situează în cadrul societăţii :

1. sisteme informatice la nivelul unităţilor economico-sociale
(microeconomic) ;
2. sisteme informatice la nivelul unităţilor economice cu structură de grup
(regii autonome) ;
3. sisteme informatice la nivel teritorial (direcţii judeţene sanitare, comisii
judeţene de statistică) ;
4. sisteme informatice generale (ministere, comisia generală de statistică).

D. În funcţie de rolul său în procesul decizional din cadrul societăţii,

sistemul informatic poate fi:
• Sistem de prelucrare a tranzacţiilor (SPT), care înregistreazã operaţiunile
(tranzacţiile) curente din cadrul societăţii, le validează şi le memorează în baze de
date pentru a servi ulterior prelucrărilor de nivel înalt.
Aşa sunt comenzile clienţilor, facturile emise sau primite, nivelul stocurilor
(consumul de materii prime) şi ieşirile de produse din fabricaţie, încasările prin
casă sau bancă, intrările sau ieşirile de materii prime, materiale sau produse,
consumurile de energie, combustibil, etc.

• Sistem Informatic de Management (SIM), care prelucrează şi sintetizează

datele detaliate ale sistemului de prelucrare a tranzacţiilor în rapoarte standard
necesare managerilor de nivel mediu. Astfel de rapoarte ar putea conţine planul de
producţie sau prestări servicii, gama sortimentală a acestuia, cantităţile şi

25
termenele de execuţie, bugetul de venituri şi cheltuieli, stadiul îndeplinirii
contractelor şi valoarea acestora, etc..

• Sistem Suport de Decizie (SSD) oferã, prin natura datelor prelucrate,

instrumente corespunzătoare pentru analizã. Acest sistem serveşte managerilor de
nivel mediu în analize economico-financiare, în analiza diferitelor probleme din
cadrul societăţii, cum ar fi evenimente întâmplătoare sau de excepţie apărute fie
ca urmare a unor factori interni, fie legate de influenţa unor factori externi. Ca şi
Sistemul Informatic de Management, Sistemul suport de Decizie se bazeazã în cea
mai mare parte, pe datele detaliate ale sistemului de prelucrare a tranzacţiilor.

• Sistem Suport al Executivului (SSE), cunoscut şi sub numele de Sistemul

Informatic al Executivului, prezintã informaţiile în formulare prestabilite. El
ajutã managerii de nivel înalt sã supravegheze acţiunile întreprinderii şi sã creeze
sau să dezvolte proiecte strategice. Sistemul Suport al Executivului combinã
datele interne de la Sistemul de Prelucrare a Tranzacţiilor şi Sistemul Informatic
de Management cu datele externe, cum ar fi cele ale factorilor de mediu, de
conjunctură a pieţei, de legislaţie sau de contracte din afara societăţii.
O extensie a Sistemelor Suport de Decizii o constituie sistemele Expert. Un
sistem expert este un sistem informatic care colectează cunoştinţe şi expertize în
rezolvarea problemelor şi luarea deciziilor şi simulează gândirea unui expert care
are experienţă în domeniu. Sistemele expert imită logica şi motivaţia unor experţi
în domeniul respectiv cum ar fi de exemplu utilizarea unui sistem expert la un
producător de mase plastice pentru a determina cauzele care produc probleme în
zona controlului de calitate asociate cu fluxurile de fabricaţie.

1.4.3. Obiectivele sistemelor informatice

Obiectivele sistemelor informatice sunt subordonate obiectivelor conducerii

activităţilor unităţilor economice, întrucât sistemul informatic se defineşte ca un
instrument care deserveşte factorii de conducere în procesul de fundamentare şi
elaborare a deciziilor.

Clasificarea obiectivelor sistemelor informatice

Obiectivele unui sistem informatic, ca parte componentă a sistemului
informaţional, sunt practic subordonate obiectivelor sistemului informaţional din
domeniul abordat. De aceea, aceste obiective pot fi grupate astfel:
A. În funcţie de sfera de cuprindere:
1. obiective generale/principale
2. obiective secundare

26
 Obiectivele principale se exprimă prin indicatori sintetici ce caracterizează
activităţile din domeniul de referinţă.
De exemplu sistemul informatic poate avea ca obiective generale:
- creşterea vitezei de rotaţie a mijloacelor circulante
- creşterea rentabilităţii activităţii unităţii economice
- creşterea profitului
- creşterea prestigiului unităţii economice
Obiectivele secundare mai poartă denumirea de condiţii de realizare a
obiectivelor principale. Acestea trebuie să fie compatibile între ele şi compatibile
cu obiectivele generale în ideea de a acţiona în acelaşi sens.
De exemplu, sistemul informatic poate avea ca obiective secundare :
- sporirea gradului de încărcare a capacităţilor de producţie
- utilizarea raţională a forţei de muncă
- aplicarea şi transpunerea pe calculator a principiului selecţiei şi informării
prin excepţie
- reducerea cheltuielilor de aprovizionare cu materii prime şi materiale prin
implementarea unor modele matematice privind optimizarea rutelor şi
capacităţilor de transport.

B. În funcţie de subsistemul de activităţi la care se referă:

1. obiective referitoare la conducerea activităţii de comercializare
(aprovizionare-desfacere)
2. obiective referitoare la conducerea activităţii de producţie
3. obiective referitoare la forţa de muncă
4. obiective referitoare la conducerea activităţii financiar-contabile
5. obiective referitoare la conducerea activităţii cercetare-dezvoltare etc.
Astfel, un sistem informatic va cuprinde activităţile desfăşurate în cadrul unui
subsistem (definit de principalele funcţii ale societăţii), şi se va constitui astfel ca
un subsistem al sistemului informatic al întregii societăţi. Aceasta înseamnă că,
practic, fiecărei funcţii a unei societăţi, indiferent de specificul ei, îi poate
corespunde un subsistem informatic.
Vom putea vorbi astfel, la nivelul oricărei societăţi, de un subsistem informatic
pentru:
- activitatea de producţie sau prestări servicii;
- activitatea de personal – retribuire;
- activitatea financiar-contabilă;
- activitatea de cercetare-dezvoltare;
- activitatea de marketing;
- activitatea de aprovizionare-desfacere (comercială).

C. În funcţie de sistemul şi activitatea de referinţă:

27
 - obiective referitoare la activitatea de bază (sistemul condus)
- obiective referitoare la sistemul informaţional

D. În funcţie de posibilitatea de cuantificare a efectelor economice

dobândite:
- obiective calitative (necuantificabile)
- obiective cantitative (cuantificabile)
Efectele economice ale obiectivelor de ordin calitativ se estimează în mod
indirect. De foarte multe ori efectele economice ale obiectivelor de ordin calitativ
depăşesc cu mult efectele economice ale obiectivelor de ordin cantitativ.
Necesitatea clasificării obiectivelor sistemelor informatice şi identificarea
acestora provine din faptul că resursele umane, materiale, financiare disponibile la
nivelul unei societăţi comerciale sunt limitate. De aceea se impune identificarea
obiectivelor şi abordarea realizării acestora într-o ordine prioritară prestabilită.

1.4.4. Principii de realizare a sistemelor informatice

Realizarea sistemelor informatice presupune o activitate laborioasă, care

cuprinde mai multe etape, consumatoare de timp, de resurse umane şi financiare
uneori deosebit de mari. De aceea, la baza realizării unui sistem informatic trebuie
să stea o serie de principii, dintre care mai importante sunt:

1. Principiul eficienţei economice

Acesta presupune recuperarea cheltuielilor de realizare şi întreţinere a
sistemului informatic din economiile obţinute ca urmare a implementării şi punerii
lui în funcţiune. Termenul de recuperare a cheltuielilor este de dorit să fie de
maxim 4-5 ani, ţinând seama de dinamismul prin care se caracterizează domeniul
informaticii, precum şi posibilitatea unor schimbări majore în activitatea unor
unităţi economice.

2. Principiul structurării sistemului informatic

Acesta presupune structurarea sistemului informatic în subsisteme, module,
aplicaţii, abordate iniţial independent şi integrate apoi într-un sistem unitar.
Necesitatea structurării sistemului informatic provine din cel puţin două
considerente de ordin practic:
• complexitatea sistemului informatic
• resursele umane, materiale, financiare disponibile la nivelul unităţii
beneficiare sunt limitate.
Ţinând seama de cele două considerente, ca urmare a structurării sistemului
informatic se va putea trece la realizarea acestuia într-o ordine prioritară
prestabilită, ţinând seama de resursele disponibile.

28
 De exemplu, două activităţi deosebit de importante ale unei societăţi, indiferent
de specificul ei, pot fi: activitatea comercială şi cea de producţie. În mod
corespunzător, cele două subsisteme aferente, vor putea fi împărţite, la rândul lor
ca în fig. 1.8.

Fig. 1.8. Structurarea subsistemelor

În cadrul fiecărui subsistem am identificat astfel aplicaţiile de prelucrare

automată a datelor corespunzătoare.
3. Principiul unicităţii datelor de intrare
Acest principiu presupune preluarea datelor din documentele primare o singură
dată, chiar dacă acestea circulă prin mai multe compartimente. Acest lucru crează
premize pentru un control riguros al datelor, pentru asigurarea exactităţii lor,
precum şi pentru răspunderea celui care le furnizează, le introduce şi le
prelucrează.

4. Principiul selecţiei şi informării prin excepţie

Acesta presupune stabilirea indicatorilor necesari şi suficienţi pe fiecare nivel
ierarhic de conducere. Factorii de conducere vor fi informaţi cu acei indicatori
necesari, numai atunci când se constată abateri de la starea normală.
Ca urmare a aplicării acestui principiu se ajunge la definirea piramidei
informaţionale în cadrul unităţii beneficiare, care reprezintă cantitatea de
informaţii vehiculată în cadrul sistemului informaţional (fig. 1.9).

Fig. 1.9. Piramida informaţională

29
 Aceasta înseamnă că volumul informaţiilor se restrânge tot mai mult către
nivelul ierarhic superior, nu prin selecţia informaţiilor transmise, ci prin
sintetizarea lor, prin prelucrări superioare, care conduc către indicatori sintetici ce
caracterizează corect activităţile desfăşurate la nivelul sistemelor de execuţie.
Fiecare nivel de management are cereri diferite de informaţii. Managerii de
nivel înalt au nevoie de informaţii sintetice, cu grad ridicat de prelucrare, scrise în
formulare pentru a arãta starea generalã globalã a afacerii. Deasemenea, ei au
nevoie de o serie de informaţii dinafara societăţii, deoarece managerii de nivel
înalt trebuie sã prevadã şi sã planifice evenimentele pe termen lung. Managerii de
nivel mediu au nevoie de informaţii scurte şi precise – rapoarte săptămânale sau
lunare. Ei trebuie sã realizeze o alocare a bugetului, precum şi o evaluare a
performanţei, a profesionalismului şefilor subordonaţi.
Supraveghetorii, şefii de la nivelul operativ, au nevoie zi de zi de informaţii
detaliate şi foarte recente din cadrul societăţii, pentru a putea menţine un flux
constant al operaţiunilor de fabricare.

5. Implementarea unor modele matematice în cadrul sistemelor informatice

Acest principiu impune necesitatea documentării aprofundate a subsistemului
abordat în vederea identificării corecte a algoritmilor de prelucrare, a modelelor
matematice ce urmează a fi implementate pentru prelucrarea automată în
domeniul respectiv. Astfel de modele matematice pot fi realizate de echipa de
proiectare sau pot fi preluate şi implementate modele existente în teoria
matematică, cum sunt:
a. modele de programare liniară (algoritmul Simplex)
Se pot aplica cu succes pentru rezolvarea problemelor de optimizare a
transporturilor în vederea stabilirii rutelor corespunzătoare, optimizarea
costurilor, a producţiei şi, în general pentru probleme de determinare a unui
optim.
b. modele de programare neliniară, utilizate în probleme de determinare a
minimului unei funcţii reale, cu sau fără restricţii.
c. modele de programare dinamică (lanţurile Markov), utilizate în
probleme de programare dinamică a producţiei sau de stabilire a planului de
revizie şi reparaţie a utilajelor sau parcului de maşini.
d. modele de simulare, care cuprind o serie de modele statistice cu
aplicabilitate în diverse domenii ale activităţilor din cadrul unei societăţi
comerciale. Aceste modele servesc fie pentru simulări ale fenomenelor în viitor,
pe baza datelor stocate în perioade anterioare, fie pentru a studia valoarea unor
parametri şi a stabili valori dorite ale unor indicatori, prin mecanismul numit
‘jocuri de întreprindere‘.
e. modele de teoria grafurilor, care fac apel la algoritmii cunoscuţi din teoria
grafurilor, cum sunt algoritmul Foulkes, algoritmul Ford-Fulkerson, algoritmul

30
Ford, etc. utilizaţi în rezolvarea unor probleme pentru determinarea fluxului
maxim într-un graf fără circuite.
f. modele de gestiune a stocurilor utilizate pentru determinarea stocurilor
optime de produse şi/sau de materii şi materiale în vederea optimizării activităţilor
de aprovizionare, de desfacere şi prin aceasta şi a celei de producţie.
g. modele de teoria deciziilor, utilizate pentru fundamentarea deciziilor
multidimensionale, a deciziilor în condiţii de risc şi incertitudine şi rezolvarea
acelor probleme care au mai multe funcţii obiectiv.
h. modele de aşteptare, utilizate pentru rezolvarea acelor probleme care
vizează minimizarea timpului de aşteptare.
i. modele de tip PERT, folosite în rezolvarea problemelor de optimizare
cost-durată, deci de optimizare a perioadei de execuţie a unei lucrări şi de utilizare
optimă a resurselor disponibile.

6. Adoptarea unor soluţii performante de organizare şi prelucrare a datelor

Această cerinţă ţine de calificarea echipei de realizare a sistemului informatic,
de experienţa sa în domeniu, de condiţiile contractuale stabilite, de modul de
colaborare cu beneficiarul şi de implicare a acestuia în diferite etape (deci de o
serie de factori obiectivi şi subiectivi).
Pe parcursul proiectării şi realizării sistemului informatic beneficiarul va putea
lua cunoştinţă de toate acestea şi-şi va putea exprima opţiunea cu ocazia avizărilor
intermediare, prevăzute de regulă în contract. Toate sunt însă posibile numai dacă
beneficiarul se implică şi colaborează efectiv cu echipa de proiectare pe toată
durata de execuţie a sistemului.

7. Respectarea cadrului legislativ

Aceasta înseamnă că echipa de proiectare are datoria de a studia cadrul
legislativ care reglementează problematica abordată şi de a-l respecta întocmai,
răspunzând în mod direct de legalitatea modului de abordare şi rezolvare a
problemei respective.

Observaţie:
Tendinţa actuală este de a proiecta şi realiza sisteme informatice integrate,
caracterizate prin faptul că asigură introducerea unică a datelor pornind de la
documentele primare şi apoi prelucrarea complexă a acestora, pentru a răspunde
tuturor cerinţelor de informare ale utilizatorilor (la toate nivelele de management)

31
 1.5. Întrebări recapitulative

1. Definiţi conceptul de sistem şi sistem cibernetic.

2. Este o societate economică un sistem? Argumentaţi răspunsul.
3. Definiţi conceptele de Sistem informaţional, Sistem informatic şi
prezentaţi relaţia dintre ele.
4. Definiţi conceptele de dată, informaţie, decizie şi relaţia dintre ele.
5. Precizaţi obiectivele unui sistem informaţional (informatic).
6. Specificaţi cerinţele unui Sistem informatic.
7. Prezentaţi elementele componente ale unui sistem informatic.
8. Tipuri de sisteme informatice. Exemplificaţi.
9. Cum explicaţi definirea sistemului informatic ca o componentă a
sistemului de management?
10. Ce înseamnă modernizarea unui sistem informaţional şi ce implică ea?
11. Care sunt nivelele de management într-o societate economică şi atribuţiile
acestora?
12. Ce subsisteme informatice pot fi realizate la nivelul unei firme, oricare ar
fi specificul ei de activitate?
13. Ce aplicaţii de prelucrare automată a datelor puteţi realiza pentru
activitatea comercială?
14. Ce aplicaţii de prelucrare automată a datelor s-ar putea realiza pentru
activitatea de marketing?
15. Ce aplicaţii de prelucrare automată a datelor consideraţi că ar putea fi
realizate pentru activităţile desfăşurate într-o bancă?
16. Ce aplicaţii de prelucrare automată a datelor s-ar putea realiza pentru o
societate de asigurări?
17. Ce aplicaţii de prelucrare automată a datelor s-ar putea realiza pentru o
firmă de consultanţă şi realizare software?
18. Ce aplicaţii de prelucrare automată a datelor ar necesita un depozit de
marfă?
19. Cum se poate estima eficienţa unui sistem informatic?

32
 2. METODOLOGII DE REALIZARE A SISTEMELOR
INFORMATICE
2.1. Scurt istoric
În ultima perioadă am asistat la o dezvoltare explozivă în lumea
calculatoarelor. Acum câţiva ani, echipe alcătuite din doi / trei analişti-
programatori reuşeau să proiecteze şi să programeze cu succes diferite aplicaţii
pentru calculatoare. Cu timpul, mărimea şi complexitatea proiectelor software a
crescut, odată cu volumul de date manipulate şi cu cerinţele de securitate şi access
la acestea, ajungându-se în prezent la proiecte de mii de linii de cod program
sursă. Acest lucru a determinat necesitatea unei mai bune organizări şi planificări
a procesului de proiectare, realizare şi dezvoltare de software. Nu întâmplător,
firme şi organizaţii puternice pe piaţa de sofware precum Microsoft sau OMG
(Object Management Group) au început să investească tot mai mult în activităţi
legate de metodologiile de analiză şi proiectare de software. Pe de altă parte,
componenţa echipelor de proiectare s-a schimbat, reunind acum analişti,
programatori, ingineri de sistem şi administratori de reţea, având un şef de proiect
care poate utiliza cu succes produsul Microsoft Project pentru planificarea şi
împărţirea diferitelor sarcini în cadrul echipei.
Metodologiile de proiectare au apărut ca o necesitate de definire a unor paşi şi
reguli generale, ce trebuiesc îndeplinite pentru analiza, proiectarea şi realizarea
diferitelor tipuri de aplicaţii informatice. Pentru a nu "descoperi" de fiecare dată
procedeul care a dus la succesul realizării unui produs anterior, s-a căutat
definirea unor metode pragmatice de structurare a programelor şi ulterior de
analiză şi proiectare a acestora. "Reutilizarea" este un cuvânt cheie în dezvoltarea
aplicaţiilor din ultimii ani, iar aceasta nu se referă numai la reutilizarea părţilor de
cod, ci la toată experienţa acumulată pe parcursul dezvoltării produsului software.
Un factor important care a dus la apariţia conceptului de reutilizare în ingineria
software este timpul, termenele de realizare a proiectelor devenind tot mai scurte
(de ordinul săptămânilor sau lunilor). Produsul este dezvoltat adeseori "din mers",
în sensul că programatorul încearcă să ghicească şi să implementeze cerinţele
schematizate ale clientului. Acesta urmează să formuleze cerinţele efective
pornind adeseori de la un prototip furnizat de proiectant.
În prezent există o multitudine de metodologii de proiectare şi realizare a
sistemelor informatice. Toate metodologiile recurg la etapizarea activităţilor de
realizare a sistemelor informatice.
Aceste metodologii sunt asemănătoare în mare parte, dar diferenţiate fie prin
documentaţia realizată pentru fiecare etapă, fie prin modul de reprezentare grafică
a rezultatelor fiecărei etape, fie prin modul de abordare al acestora sau prin
metodele utilizate.
Prin metode de analiză şi proiectare înţelegem o mulţime de procedee, tehnici
şi recomandări utilizate în etapele ciclului de viaţă al unei aplicaţii având ca scop

33
final crearea unui model al aplicaţiei care urmează a fi construită. Specificarea
acestui model se realizează prin intermediul unui limbaj sau formalism vizual
compus dintr-un set de simboluri grafice şi adnotări textuale.
Spre deosebire de modele, o metodologie se defineşte ca o cale prin care
modelele şi tehnicile din diferite stadii ale ciclului de viaţă al realizării
sistemului sunt puse laolaltă pentru a crea un sistem.
Evoluţia lor poate fi structurată în trei generaţii de metode, determinată de:
- creşterea ariei de utilizare a tehnologiei informatice;
- creşterea gradului de complexitate a aplicaţiilor şi a cerinţelor de integrare;
- necesitatea diminuării costurilor, a creşterii productivităţii şi a reducerii
riscurilor de realizare;
- evoluţia structurii şi tipologiei aplicaţiilor de gestiune: SPT, SIM, SSD,
SSE, birotică, multimedia;
- influenţa exercitată de evoluţia limbajelor de programamre, a S.G.B.D-
urilor, a reţelelor de calculatoare, a tehnicilor de gestiune în timp real etc.

Se poate pune, în mod normal întrebarea “de ce nu există o singură

metodologie de proiectare” care să fie general valabilă şi aplicabilă în toate
cazurile? Un răspuns ar putea fi acela că metodologiile diferă între ele destul de
mult, unele fiind mai eficiente în anumite domenii sau cazuri şi mai puţin în altele.
Practic, aceste metodologii s-au născut din generalizarea soluţiilor testate pe
cazuri particulare.
O problemă decisivă pentru echipa de proiectare devine astfel alegerea
metodei ce urmează a fi aplicată pentru fiecare caz în parte. Se poate spune că
acesta este primul pas deosebit de important în realizarea proiectului. Dacă
alegerea făcută este bună, acest fapt va putea duce la rezultate pozitive din toate
punctele de vedere. În cazul în care s-a optat însă pentru o metodă nepotrivită
problemei, rezultatele proiectului pot fi pe măsură (adeseori la sfârşitul proiectului
se constată că aplicaţia trebuie proiectată şi implementată într-un mod diferit).
Alegerea unei metode pentru rezolvarea unei anumite probleme date depinde
de mai mulţi factori, printre care: tipul problemei de rezolvat, domeniul în care se
încadrează problema, pregătirea şi calificarea echipei de proiectare şi realizare a
produsului software, resursele hardware şi software disponibile, şi, nu în ultimul
rând, bugetul şi timpul alocat proiectului.
Făcând un scurt istoric al metodologiilor de proiectare a sistemelor informatice,
se poate face o grupare a acestora în trei mari categorii, astfel:

1. Metode ierarhice
Reprezintă prima generaţie a metodelor de proiectare, corespunzătoare anilor
1970, caracterizate în principal prin următoarele:

34
 - sistemul informaţional/informatic este structurat şi analizat pe baza
funcţiilor sale;
- sunt centrate pe analiza funcţională, adică fiecare funcţie identificată se
subdivide ierarhic în subfuncţii, continuând în acest fel până se ajunge la
componente suficient de mici încât să poată fi programate cu uşurinţă (fig. 1.1);
Exemple de astfel de metodologii: SADT (Structured Analysis and Design
Technique), JSD (Jackson System Development), Yourdon.

Fig. 2.1. Divizarea funcţiilor unei întreprinderi

Avantajele acestui mod de abordare în proiectare ar fi: simplitate, bună

adaptare la definirea cerinţelor utilizatorului;
Ca dezavantaj se poate considera faptul că se concentrează efortul de analiză
asupra funcţiilor (de prelucrare) neglijând coerenţa datelor, a căror structură este
mult mai stabilă. Ca efect, modificarea continuă a cerinţelor de prelucrare a
utilizatorilor (a funcţiilor) fac ca aplicaţiile să fie într-o continuă reproiectare
(reconsiderare).

2. Metode sistemice
Reprezintă generaţia a doua a metodelor de proiectare, corespunzătoare anilor
1980, caracterizate în principal prin următoarele:
- se bazează pe aplicarea teoriei sistemelor în analiza întreprinderii;
- sistemul informaţional/informatic este abordat şi analizat sub două aspecte
complementare: datele şi prelucrările, care sunt studiate şi modelate independent
şi reunite cât mai târziu cu putinţă;
- acordă prioritate datelor faţă de prelucrări;
- respectă cele trei nivele de concepţie introduse prin raportul
ANSI/SPARC/X31: extern, conceptual, intern;
Ca exemple se pot aminti : SSADM (Structured System Analysis and Design
Method ), MERISE, AXIAL, Information Engineering (J.Martin).
Avantaje: sistemele se axează pe conceptul de bază de date, care oferă mai
multă coerenţă, stabilitate şi elimină redundanţa datelor.
Dezavantaje: deficienţe în modelarea prelucrărilor, posibilitatea apariţiei de
discordanţe între modelele datelor şi ale prelucrărilor, analizate iniţial separat.

35
 3. Metode orientate obiect (obiectuale)
Reprezintă generaţia a treia, aparţinând perioadei de după anul 1990,
caracterizată prin următoarele:
- sistemul informaţional/informatic este perceput ca o structură de obiecte
autonome, care se organizează şi cooperează între ele;
- un obiect are un anumit comportament, definit prin ansamblul operaţiilor
(serviciilor) pe care le poate efectua; datele şi prelucrările prin care este
implementat acest comportament sunt încapsulate şi sunt inaccesibile celorlalte
obiecte;
- fiecare obiect poate participa la compunerea altor obiecte mai complexe;
- fiecare obiect poate interveni în mai multe funcţii sau scenarii funcţionale
diferite;
Ca exemplu, amintim metodologiile: OOD – Object Oriented Design (Grady
Booch, 1993), OMT – Object Modeling Technique (James Rumbaugh, 1991),
OOA – Object Oriented Analysis (Peter Coad şi Ed Yourdon), HOOD
(Hierarchical Object Oriented Design, 1999 ), OOM (Rochfeld).
Avantaje: permite reutilizarea componentelor de program, favorizează
modelarea şi utilizarea de obiecte complexe.
Dezavantaje: percepţia şi reprezentarea monolitică de tipul " totul este obiect "
nu corespunde întotdeauna realităţii reprezentate.

Observaţie:
În literatura de specialitate metodologiile de proiectare şi realizare a sistemelor
informatice mai sunt grupate în trei mari categorii astfel:
- clasice (IBM, ICI)
- moderne (SSADM, MERISE)
- orientate obiect (OMT, UML)

2.2. Ciclul de viaţă al sistemelor informatice

Un sistem informatic are, indiferent de evoluţia tehnicii de calcul, a

metodologiilor şi tehnicilor de realizare, a experienţei echipei de proiectare sau a
cerinţelor beneficiarului, un ciclu de viaţă, care începe cu momentul deciziei de
realizare a sa şi durează până la scoaterea din funcţiune sau înlocuirea cu un
altul. Prin urmare, un sistem informatic/aplicaţie informatică se realizează de
către echipa de proiectare (specialişti în informatică) la cererea unui beneficiar şi
în condiţiile prevăzute de acesta. Se impune astfel definirea unor termeni noi,
legaţi de utilizatorii sistemului proiectat.

36
 Utilizatorul este o persoană sau un grup de persoane pentru care proiectantul
de sistem construieşte şi menţine în exploatare aplicaţii sau sisteme informatice,
adică este client al sistemului informatic.
Remarcabilul autor şi consultant de sisteme informatice Ed. Yourdon observa
că utilizatorul este în fond clientul care formulează cerinţele (oricât de
contradictorii ar fi) şi este în ultimă instanţă persoana care plăteşte sistemul
informatic şi deci poate refuza plata dacă nu este mulţumit de produsul realizat.
Din această observaţie rezultă două categorii de utilizatori şi anume:
• utilizatorii sistemului;
• proprietarii sistemului.
Utilizatorii sistemului reprezintă acea categorie de personal care are contact
direct cu sistemul informatic sau cu aplicaţiile realizate, adică utilizează
calculatoarele pentru introducerea, stocarea sau transmiterea datelor sau
utilizează informaţiile furnizate în rapoartele sistemului.
Proprietarii sistemului sunt cei care asigură resursele financiare ale
sistemului informatic, adică ei plătesc costurile de realizare şi exploatare a
sistemului informatic.
Ciclul de viaţă al unui sistem informatic sau al unei aplicaţii reprezintă
totalitatea etapelor care sunt parcurse în procesul de dezvoltare a sistemului/
aplicaţiei respective. Dintre acestea, cele mai importante etape, întâlnite practic în
toate metodologiile de proiectare a sistemelor informatice, sunt:
- Culegerea de specificaţii (analiza funcţională) - presupune definirea
problemei; specificarea detaliată a funcţionalităţilor ce trebuie îndeplinite de către
sistemul informatic;
- Analiza - în cadrul căreia se realizează cunoaşterea şi apoi modelarea
sistemului existent (date, prelucrări), identificarea direcţiilor de perfecţionare a
acestuia, stabilirea caracteristicilor esenţiale pentru soluţiile corecte posibile;
- Proiectarea - care adaugă modelelor de analiză noi elemente prin care se
defineşte o soluţie particulară, pe baza optimizării anumitor criterii;
- Programarea – în care se realizează scrierea efectivă a programelor pe baza
specificaţiilor tehnice rezultate în urma celorlalte etape;
- Implementarea - în care se realizează un proiect executabil al soluţiei
particulare modelată în faza de proiectare. Se verifică astfel cu date reale aplicaţia
realizată, se fac ultimele corecţii şi se definitivează documentaţia de utilizare şi
exploatare a acesteia.
- Exploatarea curentă, întreţinerea şi dezvoltarea sistemului realizat
presupune adaptarea acestuia la modificările ce pot apare sau dezvoltarea cerută
de nevoi suplimentare de informare pentru fundamentarea deciziilor.

În funcţie de metodologiile, metodele, tehnicile şi instrumentele folosite,

etapele de realizare a sistemelor informatice comportă mai multe modele de
abordare, dintre care prezentăm câteva:
37
 1. modelul clasic (liniar) sau în cascadă;
2. modelul structurat
3. modelul cu prototip
4. modele orientate obiect
5. alte modele, precum: modelul V, modelul spirală, modelul evolutiv,
modelul tridimensional, modelul X, etc.

1. Modelul clasic (liniar)

Este specific metodologiilor clasice de realizare a sistemelor informatice, cum
ar fi ICI, IBM, AXIAL etc. În mod sugestiv modelul poate fi reprezentat ca în fig.
2.2.

Fig.2.2. Modelul clasic (liniar)

Prin forma sa de abordare modelul mai poartă denumirea de model în cascadă.

În prima etapă se realizează studiul sistemului existent sau fotografierea
acestuia. Obiectivul urmărit îl constituie cunoaşterea şi însuşirea sistemului
existent.
A doua etapă are ca obiectiv definirea unor criterii de apreciere (evaluare)
a stării sistemului în vederea stabilirii diagnosticului sistemului (dificultăţilor şi
neajunsurilor acestuia). În funcţie de concluziile desprinse se definesc variante de
soluţii cu privire la perfecţionarea sistemului existent. Acestea vor fi supuse spre
alegere factorilor de conducere. Soluţia aleasă va deveni obiect de preocupare
pentru următoarele etape.
În etapa a treia, în concordanţă cu varianta aleasă, se trece la proiectarea
logică şi fizică de detaliu a fiecărei componente din cadrul sistemului informatic.
38
 În etapa a patra se realizează asigurarea prin eforturi proprii sau prin
achiziţie a resurselor software necesare aplicaţiilor informatice.
În etapa a cincea se realizează testarea şi verificarea funcţionării sistemului
în condiţii concrete (în mediu real). În măsura în care se constată că sistemul
răspunde performanţelor şi obiectivelor prestabilite se trece la exploatarea şi
întreţinerea curentă a acestuia. În cadrul acestei etape se urmăreşte adaptarea
sistemului informatic la modificările, schimbările intervenite în cadrul unităţii
beneficiare.
Se observă că, în primele 2 etape se răspunde la întrebarea CE trebuie să facă
sistemul, adică: ce informaţii se prelucrează, ce funcţii şi performanţe se cer, ce
restricţii se impun, ce criterii de validare trebuie respectate.
În următoarele etape se răspunde la întrebarea CUM trebuie proiectată structura
datelor, cum va fi arhitectura sistemului, cum vor fi implementate procedurile şi
cum se face testarea sistemului cu date reale.
În ultima etapă se urmăreşte funcţionarea sistemului, adaptarea lui la
modificări, corectarea eventualelor erori.
Avantajul modelului clasic constă în faptul că oferă posibilitatea realizării
sistemului informatic într-o succesiune logică, gradată.
Dezavantajele modelului clasic ar putea fi următoarele:
• presupune surprinderea încă din start a tuturor cerinţelor informaţionale ca
situaţii de informare-raportare, ceea ce este destul de dificil.
• orice scăpare a unor cerinţe sau obiective ale conducerii implică reluarea
mai multor etape din cadrul modelului.
• ţinând seama de faptul că realizarea unui sistem informatic integrat poate
dura câţiva ani de zile, beneficiarul aşteaptă o durată îndelungată de timp pentru a
se convinge că sistemul realizat este performant şi răspunde cerinţelor şi
obiectivelor prestabilite.

2. Modelul structurat cu elemente de generaţia a patra (4 GL)

Specificitatea modelului (fig. 2.3) constă în utilizarea unor instrumente de
generaţia a patra în proiectarea şi realizarea sistemului, cum sunt:
• limbaje de generaţia a patra
• generatoare de aplicaţii
• instrumente CASE
• alte TOOLS-uri

Cu ajutorul unor astfel de elemente se reuşeşte să se reducă timpul de analiză-

proiectare, precum şi cel necesar elaborării programelor. Se reuşeşte în final să se
realizeze atât documentaţia de sistem, cât şi generarea totală sau parţială a
produselor program.

39
 Reuşita modelului depinde în mare măsură de dialogul şi relaţia proiectant –
utilizator.

Fig. 2.3. Modelul structurat

Avantajul acetui tip de model constă în creşterea productivităţii muncii în

activitatea de programare.

3. Modelul cu prototip (prototipizarea)

Se pleacă de la definirea cerinţelor şi obiectivelor globale formulate de

beneficiar. Pe baza acestora proiectantul realizează un model prototip de sistem
informatic, punând accent în mod deosebit pe evidenţierea interfeţelor sistemului
cu utilizatorul. Vor fi precizate intrările ca surse de date, apoi ieşirile ca situaţii de
informare-raportare prestabilite, necesare conducerii.
Modelul astfel elaborat nu se livrează beneficiarului ci se “aruncă” acestuia. Pe
baza demonstraţiei făcute se ajustează (se rafinează) modelul şi apoi se trece la
implementarea şi exploatarea curentă a acestuia.
Modelul prototip (fig. 2.4) poate fi prezentat în diferite variante:
• sub forma unor scheme privind circuitul şi fluxul informaţional pe
domenii de interes; în cadrul schemei vor fi evidenţiate intrările, procedurile şi
ieşirile sistemului.
• sub forma unui sistem prototip realizat în cadrul unităţii beneficiare
sau deja existent, evidenţiind problematica la modul parţial sau în totalitate.
• sub forma unui sistem deja existent, prezentându-se chiar problematica
în extenso, beneficiarul având posibilitatea să opteze sau nu pe extensiile
sistemului.

40
 Fig 2.4. Modelul proptotip

Avantajele modelului prototip sunt următoarele:

• se reduce mult timpul de realizare a sistemului informatic.
• oferă mari facilităţi de revenire în diferite etape.
Dezavantajele modelului prototip: tocmai datorită faptului că modelul oferă
facilităţi de revenire în diferite etape, beneficiarul are tendinţa de a sugera, de a
solicita mereu noi “mici modificări”. Proiectantul va ţine seama de acestea, va
efectua modificări, însă în situaţia efectuării unor multiple modificări este posibil
să se ajungă la îndepărtarea faţă de obiectivele iniţiale şi chiar de performanţele
prestabilite.

4. Metodele de analiză şi proiectare orientată-obiect permit parcurgerea

etapelor ciclului de viaţă a aplicaţiilor într-o manieră iterativă, foarte
asemănătoare cu cele funcţionale sau structurale (fig. 2.5).

Fig 2.5. Modelul iterativ de dezvoltare a unei aplicaţii în

cazul utilizării unei metode de analiză şi proiectare orientate-obiect
41
 Odată cu evoluţia metodelor de analiză şi proiectare orientate-obiect s-au
dezvoltat o serie de instrumente care permit automatizarea procesului de realizare
a aplicaţiilor având la bază aceste metode. Astfel de instrumente poartă numele
de instrumente CASE (Computer Aided Software Engineering) şi sunt formate
dintr-o colecţie de componente care sprijină realizarea operaţiilor ce trebuie
efectuate în cadrul uneia sau mai multor etape ale unei metode de analiză şi
proiectare.

2.3. Concepte de proiectare şi realizare a sistemelor informatice

Conceptul general după care se realizează un sistem informatic poate fi diferit,

de la caz la caz. În literatura de specialitate sunt definite mai multe concepte,
dintre care S. Blumenthal distinge şase tipuri şi anume:
a). Conceptul schemei organizatorice. În acest caz sistemul este proiectat ca o
imagine a funcţiunilor şi legăturilor din structura organizatorică a societăţii.
Ca dezavantaj, metoda păstrează tot ce este rău în această schemă şi ca urmare,
realizează în final automatizarea operaţiilor executate manual.
b). Conceptul colectării datelor. În acest caz toate datele care apar în fluxurile
informaţionale ale societăţii sunt colectate şi analizate, iar rezultatele analizei
constituie baza noului sistem. Metoda este de cele mai multe ori oportună şi
eficientă, dar practic este greu de realizat la sisteme complexe, cu volum mare de
date.
c). Conceptul cerinţelor conducerii. În acest caz se cere conducerii societăţii
să enumere ce crede că este necesar să se facă şi aceste cereri servesc ca bază
pentru proiectare. Teoretic conceptul e bun, dar în practică implică:
- conducători care să ştie exact ce este necesar pentru îmbunătăţirea
activităţii;
- un mod de formalizare a cererilor foarte exact;
- proiectanţi care, numai pe baza acestor cereri, să poată proiecta sistemul
necesar.
d). Conceptul băncii de date. Metoda impune crearea unei bănci de date care să
conţină toate datele importante referitoare la societate, structurate şi memorate
astfel încât să permită utilizatorilor interogarea sistemului în orice moment.
e). Conceptul integrării imediate, dorit de multă lume dar foarte greu de
realizat.
f). Conceptul integrării ulterioare. În acest caz datele sunt colectate, analizate
şi memorate treptat, pe măsura rezolvării unor probleme şi în speranţa integrării
ulterioare. Dacă însă planul de realizare şi integrare nu este bine urmărit şi realizat
întocmai, obiectivul nu se mai poate realiza sau implică eforturi foarte mari de
reproiectare a sistemului.

42
 Ţinând cont de toate aceste concepte, de avantajele şi dezavantajele fiecăruia,
se poate aprecia că realizarea sistemelor informatice e bine să se realizeze după
următorul concept:
- stabilirea, la început, a unei concepţii generale de realizare a sistemului, pe
baza obiectivelor şi cerinţelor informaţionale pe care acesta le va îndeplini, în
vederea realizării în final a unui sistem integrat;
- împărţirea sistemului în principalele sale componente – subsisteme şi
aplicaţii – cu determinarea legăturilor dintre acestea;
- analiza datelor semnificative din societate şi stabilirea modului de
organizare şi prelucrare a acestora;
- stabilirea, de comun acord cu beneficiarul, a priorităţilor în elaborarea
componentelor;
- planificarea, proiectarea, realizarea efectivă şi apoi implementarea treptată a
subsistemelor şi a aplicaţiilor, cu verificarea permanentă a modului de realizare a
interfeţelor între acestea şi cu utilizatorul.

Observaţie:
1. Trebuie precizată necesitatea reluării (reiterării) anumitor activităţi cu
reactualizarea corespunzătoare a planificărilor făcute şi, dacă e cazul, chiar a
conceptului stabilit pentru proiectarea sistemului informatic.
2. Este bine de ştiut că în proiectarea şi realizarea unui sistem informatic
pentru orice societate beneficiară sunt câteva etape în care este absolut obligatorie
participarea directă a viitorului utilizator, a specialistului în domeniu, care ţine în
mod curent evidenţa manuală. Dintre aceste etape, deosebit de importante prin
efectele lor ulterioare, sunt etapele de analiză şi apoi de implementare. Pentru ca
utilizatorul să-l înţeleagă pe proiectant, să-l asiste şi să-l îndrume pe toată
perioada analizei, să înţeleagă şi să aprobe gîndirea, soluţia proiectantului, este
necesar să ştie ce se aşteaptă de la echipa de proiectare în această etapă şi ce
trebuie să facă beneficiarul.

2.4. Strategii de investigare, metode de analiză şi proiectare a sistemelor

informatice

În activitatea de proiectare şi realizare efectivă a unui sistem informatic se

utilizează numeroase metode şi tehnici, care pot fi grupate, la o primă vedere, în
două mari categorii :
 metode specifice informaticii, cum sunt:
• descendentă (top-down) simbolizată prin TD;
• ascendentă (bottom-up), simbolizată prin BU;
• hibridă sau mixtă (top-down-bottom-up) simbolizată prin TDBU.

43
 • Tehnica concordanţei intrări-ieşiri, care presupune realizarea sistemelor
informatice pornind de la mulţimea informaţiilor necesare fundamentării
deciziilor. Ea este mai mult o tehnică de analiză a sistemului existent, pentru
determinarea datelor şi a prelucrărilor acestora necesare elaborării modelului
datelor şi prelucrărilor. Ea serveşte la analiza completitudinii datelor din sistem.
 metode generale ce pot fi aplicate şi în informatică, cum sunt :
• metodele de facilitare a “realităţii” (Breinstorming, Delphi, etc.),
• metodele de conducere a proiectelor (drumul critic, diversele metode
derivate din teoria deciziei, etc);
• metodele de reducere a costurilor (cuprinse în cele două discipline:
ingineria şi respectiv, analiza valorii);
• metodele de fundamentare a investiţiilor (metode specifice Marketing-
ului, metode de simulare etc.).
Având în vedere specificul activităţii de proiectare a sistemelor informatice,
vom prezenta în continuare metodele specifice acestei activităţi.
Conform definiţiei adoptate în literatura de specialitate, o metodă de analiză
şi/sau proiectare a unui sistem informatic este un ansamblu de concepte şi
reguli prin aplicarea căruia poate fi realizată această activitate. La baza tuturor
metodelor specifice informaticii stă conceptul de “modularitate”, iar modul de
abordare al sistemelor pentru investigare şi descompunere în module componente
se constituie ca o strategie de abordare a acestora.
Din acest punct de vedere se poate aprecia justificarea eficienţei aplicării celor
trei strategii de abordare astfel:
• Strategia descendentă (TD) – prin obiectivele sale specifice, este cea mai
indicată pentru analiza, conceperea şi proiectarea produsului în ansamblu, precum
şi pentru construirea fiecărui subsistem în parte;
• Strategia ascendentă (BU) – este extrem de utilă pentru verificarea şi
ajustarea unor rezultate obţinute în urma aplicării metodei TD precum şi pentru
implementarea de subsisteme sau componente a sistemelor informatice complexe.
• Strategia mixtă (TDBU) – este indicată la “stabilirea dimensiunilor
sistemului” prin abordarea prioritară a subsistemelor care sunt semnificative din
acest punct de vedere, precum şi la “Planificarea realizării lui” prin punerea
accentului pe componentele “critice”.
Se impune să facem precizarea că abordarea top-down presupune în mod
implicit conceptul de modularitate a sistemelor. Aceasta permite ca funcţiile
logice să poată fi grupate şi apoi subgrupate cât mai independent, ajutând de fapt
dezvoltarea separată a modulelor, adică a componentelor sale. Realizarea unei
bune modularităţi funcţionale cere însă din partea proiectantului un efort de
creaţie, o înţelegere corectă a conceptului şi o bună experienţă în proiectare.
Expresia concretă a modularităţii este noţiunea de modul care se caracterizează
prin :

44
  orice modul este ansamblu de module care reprezintă rafinări ale modulului
iniţial;
 se admite existenţa unor module care practic nu mai pot fi rafinate şi care
poartă numele de module terminale;
 orice modul se poate integra cu alte module, formând noi module;
 orice modul se adaptează la mediu.
Un modul ar trebui să fie conceput astfel încât să respecte următoarele reguli:
- Să îndeplinească o funcţie bine definită, unică, pentru a uşura eventualele
modificări;
- Să fie complet, pentru a putea fi realizat independent;
- Să aibă minimizate interfeţele de date cu celelalte module, pentru a face
posibilă o întreţinere uşoară;
- Să permită o înţelegere uşoară a problemelor pe care le rezolvă;
- Să se poată încadra şi utiliza în diversele nivele de modularitate ale
sistemului.
Ceea ce diferenţiază cele trei metode specifice informaticii sunt seturile de
reguli care caracterizează fiecare metodă în parte.
Din acest punct de vedere, cele 3 metode pot fi descrise astfel:

Strategia descendentă (TD) constă în descompunerea unui sistem complex pe

nivele ierarhice, succesiv, până la module elementare, simple şi relativ
independente, astfel:
A. Se consideră drept punct de pornire (nivel 0 de descompunere) o
componentă neterminală.
B. Se aplică descompuneri succesive, în paşi, de sus în jos, pentru toate
componentele neterminale ale unui nivel.
C. Un nivel de descompunere corespunde cu sfârşitul unui pas de sus în jos.
D. Descompunerea se consideră terminată atunci când toate componentele
unui nivel sunt module terminale.
E. a). Se înlocuiesc rezultatele obţinute la un nivel de descompunere cu
rezultatele obţinute la nivelul următor,
sau :
b). După terminarea descompunerii se aplică succesiv regula E a, începând de
la ultimul nivel (ce conţine numai componente / module terminale) şi terminând
cu nivelul 0 de descompunere.

Strategia ascendentă (BU) constă în agregarea modulelor de jos în sus,

evidenţiind legăturile dintre ele, până când se ajunge la un modul, astfel:
A. Se consideră drept punct de pornire (nivel 0 de agregare) un set de
componente (module) terminale.
B. Se realizează agregări succesive în paşi, de jos în sus.

45
 C. Un nivel de agregare corespunde unui pas de jos în sus; odată cu obţinerea
unui nivel de agregare se realizează, implicit, şi o integrare a componentelor
(modulelor) de nivel superior.
D. Agregarea se consideră terminată atunci când în cazul unui nivel (de
agregare) se obţine o unică componentă (modul).

Strategia mixtă (TDBU)

Se bazează pe diversele mixturi între regulile metodelor TD şi BU, oferind o
gamă largă de posibilităţi în funcţie de regula care fixează pornirea şi care poate
fi:
A. Se începe cu componentele (modulele) considerate critice din anumite
puncte de vedere, ca de exemplu : din punctul de vedere al realizării şi
implementării şi/sau al tipului de răspuns, al dimensiunilor sistemului, etc.
B. Se începe cu componentele (modulele) cele mai complexe.
C. Se începe cu componnentele (modulele) identice, indiferent de nivel, etc.
D. Se începe cu componentele (modulele) cele mai simple, indiferent de
nivel, etc.
Fiecare regulă de începere atrage dupa sine câte un set specific de reguli de
continuare şi terminare.

Precizare : Nu trebuie confundată strategia mixtă (TDBU) cu o înşirare

secvenţială, pe fluxul tehnologic, a metodelor descendentă (TD) şi ascendentă
(BU). O înşiruire secvenţială de metode care poate cuprinde şi metoda mixtă este
de fapt o strategie de realizare a produselor informatice.

Observaţie:
Oricare ar fi metodologia de proiectare utilizată, oricare ar fi strategia de
abordare, metodele şi tehnicile de investigare sau de proiectare, toate recurg la o
modelare coceptuală, logică şi fizică a datelor şi a prelucrărilor, aşa încât se
impune studiul acestora înainte de a descrie în detaliu, specificul fiecărei metode.

46
 3. MODELAREA CONCEPTUALĂ A DATELOR
3.1. Concepte utilizate în organizarea datelor

În orice domeniu de activitate crearea modelelor reprezintă o muncă creativă.

În timpul modelării, cele mai bune soluţii sunt obţinute printr-o muncă tenace, în
timpul căreia sunt propuse diferite soluţii, care sunt modelate şi apoi testate.
Modelele care ajung să fie utilizate trebuie să îndeplinească nişte condiţii
minimale, cum sunt:
• Fidelitate: modelul descrie în mod corect sistemul care trebuie construit;
• Consistenţă: modelul trebuie să reprezinte viziuni despre lucruri care nu
sunt în conflict cu altele;
• Uşurinţa de a comunica cu ceilalţi, de a fi sugestive;
• Uşurinţa de a fi schimbate, adaptate la modificări;
• De înţeles: simplu, intuitiv, sugestiv (altfel spus, mai simplu de atât nu se
poate).
În activitatea de anliză şi proiectare a unui sistem informatic se apelează la
tehnica modelării, care trebuie să se supună tuturor acestor reguli şi altora
suplimentare, cerute de specificul activităţii.
Proiectarea şi realizarea unui sistem informatic care presupune prelucrarea
automată a datelor necesită, pe lângă activităţile legate de formularea problemei,
de analiza acesteia în vederea găsirii algoritmului de rezolvare şi o altă activitate,
deosebit de importantă, legată de organizarea datelor, în concordanţă atât cu
caracteristicile tehnice ale echipamentelor de calcul, cât şi cu cerinţele de
prelucrare. Acestea trebuie să fie structurate astfel încât prin codificarea şi apoi
memorarea lor pe suporţi tehnici să permită prelucrările necesare, stocarea şi
regăsirea ulterioară a datelor după criteriile stabilite.
Organizarea datelor reprezintă deci un proces de structurare a datelor, de
organizare şi grupare a acestora în colecţii de date, între care se stabilesc relaţii şi
pentru care se definesc restricţii, condiţii de validare.
Organizarea datelor este ca urmare un proces deosebit de important în
cadrul proiectării unui sistem informatic şi cuprinde următoarele activităţi:
- Identificarea datelor;
- Clasificarea şi descrierea proprietăţilor, a caracteristicilor datelor;
- Gruparea datelor în colecţii de date destinate prelucrării automate;
- Reprezentarea externă pe suporturi tehnice;
- Identificarea, definirea şi descrierea procedurilor de prelucrare automată.
Eficienţa prelucrării automate a datelor, deci şi eficienţa unui sistem informatic
proiectat, succesul acestuia depind, în mare măsură, de organizarea internă şi
externă a datelor, de stabilirea unor structuri de date care să corespundă cerinţelor
de prelucrare, să satisfacă cererile de informare, de sintetizare sau grupare a
datelor, de regăsire şi ordonare a acestora după criteriile dorite.

47
 Organizarea datelor a evoluat odată cu componentele hardware şi software, cu
posibilităţile oferite de acestea, dar şi cu exigenţele crescute ale beneficiarilor sau
experienţa acumulată de proiectanţii de sisteme.
În etapa de analiză a sistemului se realizează practic identificarea şi
inventarierea cerinţelor sistemului, analiza şi structurarea acestora, definirea
direcţiilor de perfecţionare. Structurarea cerinţelor sistemului înseamnă realizarea
celor trei activităţi propri analistului şi anume:
- modelarea proceselor de prelucrare a datelor;
- modelarea logicii acestora;
- modelarea conceptuală a datelor.

3.1.1. Concepte de bază

Modelarea conceptuală a datelor este o modalitate de reprezentare a datelor

din domeniul analizat, cu scopul de a scoate în evidenţă toate regulile privind
identitatea şi legăturile existente între date.
Cea mai utilizată formă pentru modelarea conceptuală a datelor este modelul
entitate – asocire (sau entitate – relaţie). Acest model se crează printr-un proces
iterativ, utilizând iniţial un volum mare de date descrise care sunt apoi prelucrate
şi selectate astfel încât să răspundă cerinţelor benefiarului. Modelul entitate
asociere care se crează prezintă caracteristicile şi structura datelor din
domeniul analizat, independent de modul în care acestea vor fi memorate în
calculator.
Lumea care ne înconjoară este formată din obiecte concrete sau abstracte, care
se descriu în procesul cunoaşterii, aşa cum am văzut, prin informaţii. Dacă vom
numi obiectele entităţi, atunci proprietăţile acestora se vor numi atribute. Aceste
atribute pot lua diverse valori, definite astfel ca măsură a proprietăţilor.
Odată cu apariţia bazelor de date ca modele de structurare a datelor, în
terminologia curentă au fost introduse şi utilizate cele 3 concepte de bază în
organizarea datelor, şi anume: entitate, atribut şi valoare. Cele trei noţiuni sunt
strâns legate între ele: o entitate are mai multe atribute, iar unui atribut i se
asociază o mulţime de valori.

Entitatea este deci un obiect concret sau abstract, reprezentat prin proprietăţile
lui. Entitatea reprezintă astfel obiectul informaţiei, iar atributul o proprietate a
entităţii.
Pe de altă parte, orice proprietate a unui obiect poate fi descrisă printr-o
pereche (Atribut, Valoare). Prin urmare, o entitate poate fi reprezentată prin mai
multe proprietăţi, deci mai multe perechi de forma (Atribut, Valoare).
În lume există însă o infinitate de entităţi şi atribute. Responsabilitatea
analistului este de a determina subsetul cel mai relevant şi precis pentru problema
abordată.
48
 În concluzie, o entitate este reprezentarea unui "obiect" concret sau abstract
care:
- aparţine domeniului problemei de rezolvat (face parte sau este relevant
pentru realitatea observată);
- are o existenţă de sine stătătoare;
- poate fi identificat în raport cu celelalte obiecte de acelaşi tip.
Exemple: student, angajat, produs, mijloc fix, client, comandă, factură.

Entitatea este deci “un tip de obiecte“, iar fiecare obiect individual constituie
o realizare (o instanţă) a entităţii respective. O entitate este reprezentată printr-
un ansamblu de proprietăţi, de atribute.
Atributele sunt descriptori ai entităţilor; ele reprezintă informaţiile care trebuie
cunoscute despre entităţi. Altfel spus, atributele reprezintă modul în care
informaţia despre entităţi este stocată.

Atributul este deci o caracteristică sau proprietate a unei entităţi,

semnificativă pentru problema de rezolvat. Pentru fiecare realizare a unei entităţi
se cunosc aceleaşi atribute, dar pentru fiecare în parte valoarea atributelor diferă.

REALIZĂRI POPESCU ION

ale entităţii TURISM
4201254
501
NUME
STUDENTI
FACULTATE
ATRIBUTE POP VASILE
TELEFON
INFORMATICĂ
GRUPA
0748521478
602
..........................

De exemplu, un student X se poate reprezenta prin perechi (Nume, Popescu),

(Facultate, Turism), (Telefon, 4201254), (Grupa, 501), etc.
Practic, mulţimea atributelor Nume, Facultate, Telefon, Grupa poate fi asociată
mai multor studenţi; Aceasta înseamnă că un atribut nu caracterizează doar o
entitate, ci o clasă de entităţi, numită entitate grup. În exemplul nostru entitatea
grup se poate numi STUDENTI.

Observaţie:
Când identificăm o entitate, identificăm de fapt un grup de obiecte. În interiorul
grupului există instanţe individuale.
•Instanţele nu trebuie confundate cu entităţile;
•O entitate este o clasă sau o categorie de lucruri/obiecte (de exemplu Angajat);
•O instanţă este un lucru/obiect specific (de exemplu Ionescu Ion);

49
 Dacă o entitate nu are mai multe instanţe, atunci ea nu este practic o entitate, ci
mai degrabă un atribut al unei alte entităţi. În astfel de situaţii se impune o analiză
suplimentară.

De exemplu, într-o firmă există mai multe departamente; entitatea

Departament are mai multe instanţe: Personal, Contabilitate, Desfacere etc.
Fiecare are un set comun de atribute sau informaţii stocate, de exemplu fiecare are
un cod şi un nume.
Se ştie că o bază de date poate fi definită ca o mulţime de date ce modelează un
univers. Acest univers este format din obiecte legate între ele.
Obiectele de acelaşi tip constituie o entitate, iar legătura între două entităţi
defineşte o relaţie (asociere). Entităţile şi relaţiile au anumite caracteristici,
numite atribute.

Un atribut poate fi, după complexitatea sa:

- simplu sau elementar, dacă valorile lui nu pot fi descompuse (ex. Număr
matricol pentru student, an de studii,etc);
- complex sau decompozabil, dacă valorile sale pot fi descompuse în mai
multe valori semnificative (ex. Data naşterii, cu semnificaţia an/lună/zi, un cod
structurat pentru un produs, etc).
Un atribut poate fi analizat din punctul de vedere al realizărilor pe care le
reprezintă, astfel:
- obligatoriu, ceea ce înseamnă că trebuie să prezinte cel puţin o realizare,
deci să aibă o valoare Not Null (exemplu Numele studentului).
- opţional, dacă nu este obligatoriu să prezinte o valoare, cum ar fi: număr
telefon, fax, cont în bancă etc.
- monovaloare, atunci când pentru o entitate sau o asociere poate lua o
singură valoare; ex nume student, cod numeric personal, cod produs, denumire
produs, etc ;
- multivaloare (repetitiv), dacă pentru o entitate sau o asociere poate lua mai
multe valori (ex: limbi străine cunoscute -un student cunoaşte mai multe limbi
străine-, nume copil -un salariat are mai mulţi copii).
Atributele trebuie să respecte următoarele reguli minimale:
- fiecare atribut poate să apară într-o singură entitate (principiul
nonredundanţei)
- un atribut poate avea numai valori elementare.
Se numeşte tip de valori un anumit ansamblu de valori, definite fie printr-o
proprietate, fie printr-o enumerare. Aşa sunt de exemplu:
Stare civilă = (necăsătorit, căsătorit, văduv, divorţat)
An studii = (n : întreg, 1 ≤ n ≤ 5)

50
 Fiecare instanţă (realizare) a unei entităţi trebuie să fie unic identificabilă faţă
de alte instanţe ale aceleeaşi entităţi. Un atribut sau un set de atribute ce realizează
acest deziderat se numeşte Identificator Unic.

Identificatorul entităţii reprezintă deci un atribut sau un grup de atribute care

primeşte valori unice pentru fiecare realizare a entităţii respective şi poate servi
astfel pentru identificarea fără echivoc a acestora.
De regulă se recurge la coduri numerice care sunt atribute construite special
astfel încât să răspundă cerinţelor de identificare (ex: marcă salariat, număr
matricol studenţi, cod numeric personal pentru cetăţeni) sau la atribute de tip
"număr de ordine" sau "număr de apariţie" (ex: numărul de inventar al unui mijloc
fix). În reprezentarea grafică, identificatorul entităţii se subliniază.

CNP
NUME
NUME FACULTATE
STUDENTI
FACULTATE TELEFON
TELEFON GRUPA
GRUPA

Se numeşte tip de entitate mulţimea tuturor entităţilor care prezintă aceleaşi

caracteristici. De exemplu: Studenţi, Produse, Contracte, Mijloace fixe, Comenzi,
Furnizori, Clienţi, etc.
Exemplu:
Dacă ne gândim la activitatea unui spital, vom identifica grupe de obiecte cu
aceleaşi caracteristici, deci entităţi cum sunt:
- medici, care lucrează în secţii şi saloane;
- secţii;
- saloane;
- pacienţi, care vin la consult sau tratament;

51
 - proceduri de tratament;
- medicamente prescrise în anumite cantităţi.
Fiecare dintre aceste entităţi se poate caracteriza prin atribute proprii, cum ar fi
de exemplu:
Medici: Cod medic, nume, specialitate, adresă, telefon;
Pacienţi: CNP, Nume, adresă, act identitate.
Secţii: Cod secţie, denumire.
Medicamente: Cod medicament, denumire, preţ, formă de prezentare, etc

Problema de modelat, deci cea din domeniul ce urmează să fie informatizat

este adeseori foarte complexă, conţinând atât obiecte simple cât şi obiecte
complexe, compuse din obiecte simple legate între ele. În urma analizei lor,
informaticianul venit să modeleze acest univers, va identifica obiectele simple şi
pe cele compuse. În modelul Entitate-Asociere, ce urmează a fi realizat, el va
asocia fiecărui obiect simplu câte un tip de entitate cu atribute monovaloare.
Pentru obiectele compuse, funcţie de experienţa modelatorului, se pot
identifica de la început obiectele şi legăturile lor, fiecărui obiect corespunzându-i
un tip de entitate. De cele mai multe ori însă, se asociază iniţial obiectului
compozit, cu caracteristici multivaloare, o entitate cu atribute multivaloare;
modelul astfel obţinut va fi optimizat, astfel încât obiectului respectiv să-i
corespundă mai multe tipuri de entităţi, cu condiţia ca atributele multivaloare
să fie grupate într-un tip separat de entitate. Se ajunge astfel la un model cu
obiecte simple, cărora le corespund tipuri de entităţi cu atribute elementare
(simple).
De exemplu, dacă ne referim pentru activitatea de desfacere produse la o
factură, în cadrul ei se identifică o parte fixă, cu atribute elementare, şi anume: Nr
factură, data facturii, cod furnizor, banca furnizor, cont furnizor (plătitor) şi o
parte de atribute repetitive sau multivaloare, reprezentate practic de rândurile din
factură corespunzătoare produselor livrate (cumpărate). Grupând atributele
repetitive într-un tip de entitate, rezultă ca urmare, 2 tipuri de entităţi, şi anume:
Factura, cu primele atribute: Nr factură, data facturii, cod furnizor, banca
furnizor, cont furnizor (plătitor);
Rânduri factură, cu datele despre produsele vândute: cod produs, denumire
produs, preţ unitar, cantitate vândută.
Analizând mai atent cea de-a doua entitate, se vede că produsul este de fapt un
obiect al problemei de modelat, căruia trebuie să-i corespundă un tip de entitate
distinct şi anume Produse (Cod produs, denumire, caracteristici).

Observaţie:
În modelul relaţional, entităţile devin tabele. Pentru fiecare entitate este necesar
să se realizeze o descriere detaliată, cât mai completă.

52
 Într-un model relaţional, nu pot să existe două entităţi cu acelaşi nume sau o
entitate cu nume diferite. O entitate se identifică unic print-un identificator, numit
cheie primară, care face astfel distincţie între valori diferite ale entităţii.

Se ştie că în lumea care ne înconjoară obiectele, deci şi entităţile care le

modelează, sunt în legătură unele cu altele, se influenţează sau se condiţionează
reciproc. În procesul modelării aceste legături sunt reprezentate prin noţiunea de
asociere sau relaţie.
O relaţie este o asociere semnificativă, bi-direcţională, între două entităţi sau
între două instanţe diferite ale aceleeaşi entităţi.
Când luăm în considerare o relaţie, trebuie să o privim în ambele sensuri. De
exemplu, un curs are o relaţie cu un profesor şi un profesor are o relaţie cu un
curs:
•Un curs poate fi proiectat de un profesor.
•Un profesor poate preda un curs.
Asocierea (relaţia) se defineşte astfel ca o reprezentare a legăturii sau
corespondenţei existente între două sau mai multe realizări de entităţi şi a rolului
pe care îl joacă fiecare entitate participantă la legătură. O asociere nu are existenţă
de sine stătătoare, ea depinde de existenţa realizărilor de entităţi pe care le leagă;
ca urmare, asocierea nu are identificatori specifici.
O asociere poate avea atribute proprii, cu scopul de a caracteriza legătura dintre
entităţile participante la asociere. Entităţile care participă la o asociere constituie
colecţia acesteia.
Numărul de entităţi care participă la o asociere formează dimensiunea sau
gradul acesteia (mai mare sau egală cu numărul de entităţi al colecţiei).
Se numeşte tip de asociere ansamblul legăturilor care prezintă aceeaşi
semnificaţie dintre două sau mai multe entităţi.
Cardinalitatea cuplului entitate-asociere se defineşte ca o pereche de valori
întregi, de forma (m,M) care exprimă modul de participare al realizărilor fiecărei
entităţi la asociere, având următoarea semnificaţie:
- m – cardinalitate minimală – arată numărul minim de realizări ale
legăturii care există pentru o realizare a entităţii;
- M – cardinalitate maximală – arată numărul maxim de realizări ale
legăturii care pot exista pentru o realizare a entităţii.
Cele două cardinalităţi au valori uzuale: 0,1; 1,1; 0,n; 1,n .
Astfel, cardinalitatea minimală 0 arată că pot exista entităţi care să nu participe
la nici o asociere (legătură).
Exemplu:
0,n 1,1

CLIENT Emite COMENZI

53
 Interpretare: Un client poate exista chiar dacă nu a emis nici o comandă. Orice
comandă însă trebuie emisă de un client.
Cardinalitatea minimală 1 arată că toate realizările tipului de entitate trebuie să
participe la o realizare a tipului de asociere.
Din exemplul anterior: Orice comandă trebuie să fie emisă de un client.
Cardinalitatea maximală 1 arată că numărul maxim de apariţii ale asocierii
care poate exista pentru o realizare a entităţii este 1.
Din exemplul anterior: O comandă poate să fie emisă de un singur client (cel
mult unul). Odată ce a fost emisă, clientul nu mai poate fi schimbat.
Cardinalitatea maximală n arată că mai multe entităţi ale unui anumit tip
participă la o asociere; în acest caz se poate chiar preciza uneori valoarea lui n.

Observaţie:
Cardinalitatea minimă reprezintă deci acea regulă care specifică dacă o relaţie
trebuie să existe pentru toate instanţele unei entităţi (sau nu). Ea mai este
cunoscută sub numele de Opţionalitate (relaţia este opţională). Dacă identificăm o
relaţie cu gradul 0, atunci ea este o relaţie opţională.
Cardinalitatea maximă reprezintă acea regulă care precizează câte relaţii de
acelaşi tip pot exista: una singură sau mai multe. Ea mai este cunoscută sub
numele de Grad.

Între realizările aceloraşi entităţi pot exista mai multe asocieri diferite, cu
semantică şi cardinalităţi distincte.
Se numeşte rolul entităţii un nume care serveşte pentru a desemna participarea
entităţii la o asociere.
Exemplu:
Dacă ne referim la o entitate Angajat, identificată dacă analizăm activitatea
compartimentului (sau funcţiei) de resurse umane din cadrul unei societăţi
comerciale, atunci ea poate să fie descrisă cu atributele: Nume, marcă, functie,
compartiment, salariu de încadrare, data angajării, domiciliul, localitatea, CNP,
Asociere
sex, telefon,etc. Compartimentul constituie însă un alt obiect relevant al
Numecu
problemei, deci o entitate atributele sale:Cardinalitate
asociere cod şi denumire. Între cele două
entităţi se stabileşte o relaţie (asociere), minimalã maximalã
fiecare angajat fiind încadrat într-un
compartiment,
ANGAJAT la o anumită dată.
ÎNCADRAT -LA
COMPARTIMENT
Marcã 1,1 0,n
Nume Data încadrãrii Cod compartiment
Functie
CNP Den compartiment
Salariu…. Atribut al asocierii
54

Colectie: ANGAJ AT, COMPARTIMENT

Dimensiune: 2 (asociere binarã )
 1,1 0,n
ANGAJAT ÎNCADRAT -LA
COMPARTIMENT
Marcã Data încadrãrii
Nume Codcompartiment
0,1 1,1
Functie CONDUCE Dencompartiment
CNP
Salariu ….

Colectie: ANGAJAT, COMPARTIMENT

Dim ensiune:2(asocierebinarã )

Interpretarea cardinalităţilor :
În primul exemplu, cardinalitatea (1,1) arată că fiecare angajat este încadrat
neapărat la un compartiment şi la cel mult unul; cardinalitatea (o,n) privită din
partea entităţii Compartiment arată că un compartiment poate exista structural fără
a avea vreun angajat, dar poate avea (cel mult) n angajaţi.
În exemplul 2, cardinalitatea (0,1) arată că există angajaţi care nu conduc nici
un compartiment, iar cea maximală egală cu 1 arată că un angajat conduce cel
mult un compartiment. Privită dinspre entitatea Compartiment, cardinalitatea (1,1)
arată că fiecare compartiment este condus de un angajat şi cel mult unul.
În funcţie de numărul de tipuri de entităţi care participă la o asociere, aceasta
poate fi: reflexivă (unară), binară sau complexă.
Se numeşte Asociere reflexivă o asociere care leagă realizări diferite ale
aceleiaşi entităţi (colecţie = 1). În aceste cazuri, este indispensabilă specificarea
în schemă a rolurilor jucate de entitate.
Exemplu:
AN
AGAJA
NGAJT
AT
Marcã
0,1 Num e 0,1
Functie
CNP
Salariu ….
Sot Sotie

CÃSÃTORIT -
cu
Datacãsãtoriei
55
Rol
Colectie: PERSOANÃ; Dimensiune: 2
 Deci, în cadrul entităţii Angajat, există persoane căsătorite cu persoane din
aceeaşi colectivitate (entitate), fiecare jucând rolul său (soţ sau soţie).
Se numeşte Asociere binară o asociere care leagă realizări aparţinând la două
tipuri de entităţi diferite (colecţie = 2). Aşa a fost cazul asocierii prezentate între
entităţile Angajat şi Compartiment.
Se numeşte Asociere complexă (ternară) o asociere care leagă realizări
aparţinând la mai multe tipuri de entităţi diferite (colecţie >= 3). În acest caz se
impune descompunerea asocierii complexe în asocieri binare.

C
ANG AJAT
1,1 ÎNCADRAT-LA 0,n
Marcã Cod
Nume
Functie PE Den
CNP
Salariu….
Exemple de entităţi şi asocieri care se constituie practic ca fragmente ale unui
viitor model Entitate Asociere: FUNCTIE
Cod functie
Denumire

Colectie: ANGAJAT,COMPARTIMENT
-FU
Dimensiune: 3 (asociere ternarã)

56
 Este vorba despre o dispoziţie de livrare a unui/unor produse, de clienţi care îşi
deschid un depozit la o bancă sau de contribuabili care au câte un rol deschis la
Administraţia Financiară.

3.2 Modelul entitate – asociere (MEA)

3.2.1. Prezentare generală

Procesul de descriere a entităţilor şi a asocierilor se numeşte modelare şi este

realizat cu ajutorul unui model de date.
Modelarea unei baze de date permite trecerea de la percepţia unor fapte din
lumea reală la reprezentarea lor prin date. Modelul de date trebuie să reflecte fidel
fenomenele lumii reale, să urmărească evoluţia acestei lumi şi comunicarea între
fenomenele sale.
Modelul entitate – asociere (MEA) nu este un simplu model teoretic de
reprezentare a datelor, ci reprezintă un model neformalizat pentru reprezentarea
unor fenomene, a unui sistem din lumea reală. El devine astfel un instrument de
lucru şi de comunicare între proiectanţii unei aplicaţii informatice. Scopul lui este
de a stabili entităţile de date (obiectele despre care se impune stocarea datelor) şi
relaţiile care există între acestea. Pentru reprezentarea grafică a modelului
entitate-asociere este utilizată adeseori Diagrama entitate-asociere (DEA).
Modelul E/A împarte elementele unui sistem real în două categorii:
• Entităţi
• Legături (asocieri) între entităţi
Entitatea reprezintă: o persoană, un loc, un concept, o activitate sau eveniment
care este semnificativ pentru ceea ce modelăm. În modelul relaţional, entităţile
devin tabele. Pentru fiecare entitate este obligatoriu să dăm un nume şi o descriere
detaliată. Într-un model relaţional, nu pot să existe două entităţi cu acelaşi nume
sau o entitate cu nume diferite. O entitate se identifică unic printr-un identificator
care face distincţie între valori diferite ale entităţii; acesta devine în modelul
relaţional cheie primară.
Entităţile nu pot exista în mod izolat. Fiecare entitate trebuie să fie legată de cel
puţin o altă entitate printr-o relaţie.
Relaţia (asocierea) reprezintă o comunicare între două sau mai multe entităţi,
un raport care există între ele. O valoare a unei relaţii este o comunicare între
valorile entităţilor care le leagă. De regulă relaţiile se exprimă prin verbe şi se pot
simboliza printr-un cerc sau romb.
Alteori, în reprezentarea grafică lipseşte rombul sau cercul şi apare o linie cu
vârf simplu de săgeată pentru cardinalitate 1 sau linie cu vârf dublu de săgeată
pentru cardinalitate n.
P Chen, considerat creatorul modelului EA, utilizează rombul pentru a
specifica asocierea şi caracterele 1,0 sau m pentru tipul asocierii (plasate chiar pe
linia ce leagă entitatea de asociere).
57
 De exemplu:

R. G. Ros utilizează tot rombul pentru reprezentarea asocierii, dar pentru

redarea tipului ei foloseşte săgeata cu vârf unic pentru 1 şi cu vârf dublu pentru n.
Aceleaşi exemple devin acum reprezentate astfel:

3.2.2. Tipuri de relaţii

a). Relaţii (mai) Mulţi-la-Unu

Acestea sunt cele mai comune şi arată că o relaţie are un grad de unu sau mai
mulţi într-o direcţie şi unul singur în cealaltă direcţie. O astfel de relaţie este
privită ca o relaţie părinte - copil sau master – slave.
Majoritatea relaţiilor de tip mulţi-la-unu au entităţi copil opţionale şi entităţi
părinte obligatorii, ceea ce înseamnă că un exemplar de părinte poate exista fără a
fi asociat cu copilul, dar copilul nu poate exista fără părintele său.
Aceasta înseamnă că entitatea părinte trebuie creată prima, după care sunt
asociate şi entităţile copii.

Observaţie:
În cazul unei relaţii mulţi-la-unu complet opţionale, oricare dintre cele două
entităţi – părinte sau copil – poate fi creată prima.
Relaţiile mulţi-la-unu care sunt obligatorii la ambele capete sunt foarte rare şi
semnifică faptul că o entitate nu poate exista fără cealaltă.

b). Relaţii (mai) Mulţi-la-(mai) Mulţi

58
 Reprezintă un tip de relaţii foarte întâlnite îndeosebi în stadiul de creare a unui
model şi au un grad de unul sau mai mulţi în ambele direcţii.
Majoritatea relaţiilor mulţi-la-mulţi sunt opţionale în ambele direcţii, ceea ce
înseamnă că un exemplar din fiecare poate să existe fără nici o asociere. Practic
aceasta înseamnă că fiecare entitate poate fi creată, iar asocierea poate fi adăugată
mai târziu.

Observaţie:
Relaţiile mulţi-la-mulţi care sunt obligatorii la ambele capete sunt foarte rare,
ceea ce impune ca instanţele ambelor entităţi să fie create simultan.

O relaţie de tipul mulţi-la-mulţi se tratează prin descompunerea în două relaţii

de tip mulţi-la-unu, astfel:
- Se identifică şi se crează o nouă entitate.
- Se transformă entitatea nou creată într-o entitate de detaliu pentru celelalte
două entităţi.
- Se transformă relaţia mulţi-la-mulţi în două relaţii mulţi-la-unu cu noua
entitate la capătul mulţi, ca detaliu. Relaţiile cu entitatea de intersecţie sunt
obligatorii.
Dacă identificăm o entitate de intersecţie şi nu există atribute pentru ea, atunci
înseamnă că ea reprezintă doar o listă de referinţe încrucişate între instanţele
entităţilor; ea devine astfel o excepţie de la regula care spune că toate entităţile
trebuie să aibă atribute. Entităţile de intersecţie conţin de obicei informaţii
temporale precum cantităţi şi date.

c). Relaţii de tip Unu-la-Unu

Se caracterizează printr-un grad de unul singur în ambele direcţii. Relaţiile de
Unu-la-Unu sunt destul de rare, ele arătând că cele două entităţi sunt de fapt una şi
aceeaşi în cadrul modelului.
Notaţia uzuală reprezintă tipul de asociere 1 la mulţi printr-o linie cu terminaţie
în formă de laba gâştei:
Relaţia de tip 1 la 1 se reprezintă printr-o linie dreaptă simplă:

Observaţie:
Pentru a denumi o relaţie vom alege un nume semnificativ în contextul
problemei de modelat. Numele relaţiilor sunt adeseori perechi, cum ar fi:
conduce – şi – condus;
cumpărat de la – şi – furnizat de;
reprezentat de – şi – reprezentant al;
responsabil pentru – şi – responsabilitatea lui.

59
 Pentru a crea o relaţie trebuie parcurşi următorii paşi, în ambele direcţii ale
acesteia:
• Se stabileşte existenţa relaţiei.
• Se stabileşte numele relaţiei.
• Se determină gradul relaţiei.
• Se determină opţionalitatea relaţiei.
• Se modelează relaţia.
• Se validează relaţia prin citire.
Un model al relaţiilor între entităţi va putea fi pus apoi în orice format fizic, ca
de exemplu:
•Bază de date ierarhică
•Bază de date tip reţea
•Bază de date relaţională
•Fişiere clasice

Observaţie:
Modelarea conceptuală a datelor ar trebui să fie independentă de platforma
hardware şi software existente pentru implementare. Aceast lucru ne permite să
avem o privire obiectivă asupra cerinţelor informaţionale şi de prelucrare ale
problemei abordate, fără a avea constrângeri legate de dotarea firmei.
O modelare corectă a datelor va permite implementarea cererilor în medii
diferite. Dacă mediul trebuie schimbat după implementare, modelul original va fi
uşor aplicat noului mediu.

3.3. Restricţii de integritate

Modelarea conceptuală a datelor este un proces de documentare a cerinţelor

informaţionale ale problemei de rezolvat, concretizată pe de o parte în
identificarea structurii datelor, pe de alta în stabilirea regulilor prin care se câştigă
încrederea în integritatea acestora.
Astfel, cerinţele pe care datele trebuie să le respecte pentru a fi corecte şi
coerente în raport cu realitatea pe care o reprezintă se numesc restricţii de
integritate. Acestea se referă la:
• Integritatea entităţii
Fiecare instanţă a entităţii trebuie să aibă un identificator unic, adică o cheie
primară a cărei valoare nu poate fi valoarea Null. Identificarea unei entităţi se
realizează cu atributele proprii, împreună eventual cu rolurile jucate de alte tipuri
de entităţi.
Problemă: Analizaţi în acest sens entităţile Angajat şi Pontaj identificate în
cadrul compartimentului de retribuire resurse umane.

• Domenii
60
 Aceste restricţii privesc valorile pe care le pot lua atributele entităţilor,
eventualele corelaţii care trebuie să existe între acestea. Ele se pot referi la
realizările unor atribute care aparţin aceleeaşi entităţi sau asocieri şi se numesc
restricţii intraentitate, sau a unor atribute aparţinând la entităţi sau asocieri
diferite, caz în care se numesc restricţii interentitate. Prin precizarea domeniului
se stabilesc de regulă următoarele caracteristici ale atributelor:
-tipul datei;
-lungimea;
-formatul;
-semnificaţia;
-formatul;
-dacă se acceptă valoarea nul sau nu;
-intervalul de valori admise.
Prin aceste restricţii datele sunt validate, asigurându-se astfel încrederea în
operaţiunile executate şi uşurinţă în manipularea datelor.
Problemă : Daţi exemple de :
- corelaţii între valorile mai multor atribute ale aceleeaşi entităţi sau asocieri;
- corelaţii între atributele mai multor entităţi sau asocieri diferite;
- corelaţii cu valori obţinute pe baza unor operaţii de sintetizare (numărare,
însumare, medie etc) a unui ansamblu de entităţi.

• Rolurile jucate de entităţi în cadrul asocierilor

Un alt tip de restricţii de integritate stabilesc condiţii ce trebuie îndeplinite de
rolurile jucate de un tip de entitate în diverse asocieri, cum ar fi incluziunea,
egalitatea şi excluziunea de roluri.
Incluziunea: Dacă o entitate E care joacă un rol r1 într-o asociere a1 va juca
neapărat şi rolul r2 într-o asociere a2, atunci spunem că rolul r1 include sau
implică prin incluziune rolul r2.
Notaţia grafică:

R1 I
R2

Exemplu:
Un client al băncii depune o cerere pentru a primi un credit. Aceasta este
analizată şi, dacă este aprobată, clientul primeşte creditul.
Se impune observaţia că el poate beneficia de credit numai dacă a depus o
cerere pentru acesta. Spunem că între rolurile
depune depusa primeşte
CERERE- şi depune ale aceluiaşi
Depunere
client există o restricţie de
0,nincluziune. 1,1 CREDIT
0,1 analizata
I
I
CLIENT Aprobare
61
1,1 aprobat

0,n 1,1
Primire CREDIT
primeste acordat
 Faptul că un client al băncii depune o cerere pentru un credit nu implică şi
acordarea creditului, dar acordarea acestuia implică întotdeauna existenţa cererii
corespunzătoare.

Observaţie: RI de incluziune este redundantă atunci când cardinalitatea

minimală a rolului indus este mai mare de zero (analizată → depusă în exemplul
nostru).

Problemă: Analizaţi în mod asemănător cazul unei facturi achitate pentru

marfa de pe un document NIR (Notă de Intrare Recepţie). Identificaţi incluziunea
de roluri şi explicaţi.

Egalitatea: Egalitatea de roluri presupune că restricţia de incluziune între

rolurile r1 si r2 ale unei entităţi este reciprocă. Aceasta înseamnă că rolul r1 jucat
de entitatea E în asocierea a1 determină rolul r2 jucat de aceeaşi entitate în
asocierea a2 şi invers.
Notaţia grafică:
R1 =
R2

Exemplu:
Dacă mergem mai departe cu exemplul nostru de mai sus, atunci putem spune
că orice client care este beneficiarul unui credit trebuie să constituie o garanţie
pentru acesta şi, invers, constituirea unei garanţii de către un client se face atunci
când acesta primeşte un credit (considerăm cazul unui credit care impune
constituirea unei garanţii).
beneficiar acordat
Primire CREDIT
0,n
0,n

=
CLIENT

0,n
0,n
Garantare GARANTIE
constituie -garantie
garanteaza
62
 Excluziunea: Rolul r1 jucat de o entitate E în asocierea a1 exclude existenţa
rolului r2 jucat de aceeaşi entitate în asocierea a2. Notaţie grafică:
R1 #
R2

Exemplu:
Dacă ne gândim la un apartament proprietate particulară, putem spune că
acesta nu poate să aparţină simultan unei persoane fizice şi unei persoane juridice.

apartine -pers proprietar -p

Proprietate 0,n PERSOANA
persoană

0,1
APARTAMENT #

0,1
Proprietate 0,n SOCIETATE
Societate proprietar -s
apartine -soc

Problemă: Analizaţi în mod similar, entitatea factură, ştiind că o societate

poate primi o factură de la furnizori pentru plata produselor cumpărate sau poate
emite factură către clienţi pentru plata produselor/serviciilor livrate.

• Reguli de stabilire a asocierilor dintre entităţi

Acest set de restricţii numite restricţii de integritate pe asocieri se referă la
tipul de asociere, la rolurile determinate de asociere şi anume: incluziune,
egalitate şi excluziune de asocieri. Ele vizează deci asocierea şi toate entităţile
participante la ea.

Incluziunea de asocieri: Dacă o asociere A1 dintre 2 entităţi va determina

asocierea A2 în cadrul modelului EA, atunci aocierea A1 include A2.
Analizând exemplul nostru de mai sus, un client care a primit un credit începe
să plătească ratele, care în timp vor stinge creditul.
Problemă: Analizaţi, pentru o firmă de distribuţie produse pe bază de comenzi,
tipul asocierilor şi restricţiile de integritate a acestora.
Se precizează că orice produs livrat trebuie să corespundă unui produs
comandat. Deasemenea, unei comenzi îi pot corespunde mai multe livrări diferite.

63
 Egalitatea de asocieri arată că asocierile de tip A1 determină asocierile de tip
A2 şi invers. De exemplu, în cazul unui cititor de la o bibliotecă, fiecărui
împrumut făcut trebuie să-i corespundă o restituire şi invers, fiecărei restituiri
trebuie să-i corespundă un împrumut. Reprezentând grafic aceste asocieri, se
obţine :
Imprumut
Data imprumut CITITOR
existent 0,n 0,n Nr legitimatie
imprumutat imprumuta Nume
CARTE
Prenume
Nr exemp lar = Adresa
An editie Cat egorie
restituit restituie
0,n 0,n Data restituire
Restituire
Data restituire impr

Excluziunea de asocieri: Dacă o asociere A1 dintre 2 entităţi exclude

asocierea A2 în cadrul modelului EA, atunci aocierea A1 exclude A2.
De exemplu, într-o tranzacţie imobiliară, clientul firmei imobiliare vinde sau
cumpără un bun imobiliar (casă, vilă, apartament sau teren).
vanzator Vinde
vandut -prin
0,n
1,1 TRANZACTIE
CLIENT
#
1,1
0,n
cumparator cumparat -prin
Cumpara

Problemă: Analizaţi mişcările înregistrate de materiale într-o gestiune de

materiale, ştiind că documentul poate fi de intrare (NIR) sau de ieşire din gestiune
(BC), determinând în mod corespunzător creşterea sau micşorarea stocului
existent.

3.4. Dependenţe funcţionale

3.4.1.Caracteristici de bază

Se numeşte dependenţă funcţională o relaţie între două atribute, dintre care

unul este determinant şi celălalt este determinat, ambele atribute aparţinând
aceleeaşi entităţi.

Exemplu:
Marcă Nume angajat

64
 Cod numeric personal Nume persoană
Cod produs Denumire produs
Aceasta înseamnă că fiecărei realizări a atributului determinant îi va
corespunde întotdeauna aceeaşi realizare (valoare) a atributului determinat. Unei
anumite mărci îi va corespunde acelaşi nume, unui anumit cod numeric personal
acelaşi nume de persoană, unui cod produs aceeaşi denumire.
Dacă vorbim de o dependenţă funcţională X→ Y , unde X şi Y sunt atribute ale
unei entităţi, atunci pentru realizări ale entităţii care au aceleaşi valori pentru X
există aceleaşi valori ale atributului Y.
Determinantul poate fi compus din unul sau mai multe atribute.
De exemplu, dacă ne referim la activitatea de desfacere a unei firme, se ştie că
preţul unitar de vânzare este determinat de tipul produsului şi de numele clientului
(beneficiarului), deoarece acelaşi produs se poate vinde la preţuri diferite la
clienţi diferiţi (se acordă discount pentru cantitatea cumpărată, pentru fidelitatea
clientului, etc) .
Deci, Cod produs,Cod client→Preţ vânzare.
O dependenţă funcţională X→ Y se numeşte elementară dacă pentru orice
X1 strict inclus în X, dependenţa funcţională X1 →Y nu este adevărată.

Între două atribute X şi Y există o dependenţă funcţională multivaloare

(DFM), notată:
X→→Y
dacă o valoare a lui X determină mai multe valori pentru Y.
De exemplu, un anumit zbor al unei companii aeriene se efectuează în mai
multe zile din saptămână (luni, vineri, duminica).
Nr zbor →→Zi săptămână
În contextul modelului EA, DFM corespunde existenţei atributelor repetitive
sau multivaloare. De regulă acest tip de DF se întâlneşte atunci când entitatea are
cel puţin trei atribute notate X,Y şi Z între care se stabilesc următoarele
dependenţe: X→→Y, X→→Z, dar Y şi Z sunt independente.
X→Y se numeşte dependenţă funcţională completă dacă Y este dependent
funcţional de X şi nu este dependent de nici o componentă a lui X.
În mod asemănător, X→Y se numeşte dependenţă funcţională parţială dacă Y
este dependent funcţional atât de X cât şi de părţi ale acestuia.
Dacă însă Y ⊆ X atunci dependenţa funcţională se numeşte trivială.
X→Z se numeşte dependenţă funcţională tranzitivă dacă X→Y şi Y→Z şi Y
nu determină pe X.
De exemplu, analizând o factură, pot fi identificate următoarele dependenţe
funcţionale:
1. Nr factură → Cod furnizor
2. Nr factură→Data
65
 3. Nr factură →Cod produs
4. Cod produs→Cantitate vândută
5. Nr factură→Cantitate vândută
Dependenţa 4 este însă tranzitivă, corespunzând definiţiei date.

Proprietăţi ale dependenţelor funcţionale:

Reflexivitatea:
X→X.
Exemplu: Marca → Marca
Dezvoltarea:
Dacă X→Y atunci este valabilă şi X,Z→Y.
Exemplu: Marca → Nume angajat
Marca, Localitate→ Nume angajat
Tranzitivitatea:
Dacă X→Y şi Y→Z atunci X→Z.
Exemplu: Marca → Localitate, Localitate → Judeţ
Marca → Judeţ
Aditivitatea:
Dacă X→Y şi X→Z atunci X→Y,Z.
Exemplu: Marca → Nume angajat, Marca → Adresă angajat
Marca → Nume angajat, Adresă angajat
Proiecţia:
Dacă X→Y,Z atunci X→Y şi X→Z.
Exemplu: Marca → Nume angajat, Adresă angajat
Marca → Nume angajat,
Marca → Adresă angajat
Pseudo-tranzitivitatea:
Dacă X→Y şi W,Y→Z atunci X,W→Z.
Exemplu: Marca angajat → Compartiment;
Compartiment, Funcţie → Indemnizaţie conducere
Marca angajat, Funcţie → Indemnizaţie conducere

Observaţie:
Cardinalităţile 1,1 corespund întotdeauna unor dependenţe funcţionale.
Dependenţele funcţionale reprezintă restricţii de integritate.
Identificatorul unei entităţi este un atribut sau un grup de atribute faţă de care
toate celelate atribute sunt dependente funcţional.
Dependenţele funcţionale pot exista şi între entităţi şi asocieri.

66
 3.4.2. Studiul dependenţelor funcţionale

Studiul dependenţelor funcţionale se poate realiza cu ajutorul unor instrumente

specifice, dintre care amintim: matricea dependenţelor funcţionale şi diagrama
dependenţelor funcţionale.

A). Matricea dependenţelor funcţionale

Acest instrument de analiză a structurii datelor, deosebit de util, reprezintă

practic un tablou în care pe coloane se trec atributele cu rol de determinanţi ai
dependenţelor funcţionale, iar pe linii toate atributele identificate în procesul
modelării datelor.
Matricea poate fi elaborată în două formate şi anume: matricea simplificată,
care cuprinde pe coloane doar determinanţii dependenţelor funcţionale, şi
matricea completă, construită cu un număr egal de linii şi coloane (care cuprinde
şi pe coloane toate atributele identificate, nu numai pe cele cu rol de
determinanţi).
La intersecţia unei linii cu o coloană, acolo unde există o dependenţă
funcţională între atributul cu rol de determinant din coloană şi atributul înscris în
linia respectivă, se va înscrie valoarea 1. Existenţa mai multor valori de 1 pe o
linie pun în evidenţă dependenţe funcţionale tranzitive datorate unor asocieri
ierarhice (numite restricţii de integritate funcţională) sau necesitatea unei analize
în vederea stabilirii corecte a determinantului dependenţelor funcţionale descrise.
Se ştie că într-un model entitate-asociere atributele sunt unice, ceea ce
înseamnă că un atribut trebuie să aparţină unei singure entităţi (sau asocieri). În
funcţie de dependenţa funcţională la care atributul respectiv participă în legătura
cu identificatorul tipului de entitate, el va fi plasat într-o anume entitate.
Exemplu de matrice simplificată pentru evidenţa automată a activităţii de
spitalizare a pacienţilor.
Se pot identifica entităţile: medici, pacienţi, secţii, saloane, medicamente.
Reprezentând MDF se obţine :

67
 Atribute Determinanţi
1 3 7 9 9+3 1+7
1.Cod medic 1*
2.Nume medic 1
3.Cod pacient 1*
4.Nume pacient 1
5.Adresa 1
6.Act identitate 1
7.Cod secţie 1 1*
8.Denumire secţie 1
9. Număr salon 1 1 1*
10.Capacitate salon 1
11Data intrării 1 1

Analizând matricea, se observă că pe linia Cod secţie există două valori de 1,

iar pe cea de număr salon trei valori de 1, arătând că există dependenţe tranzitive.
Se impune crearea unor noi entităţi, astfel încât să fie eliminate aceste anomalii. În
acest caz se crează o entitate nouă, Internaţi, cu atributele: Cod internat, cod
medic, cod secţie, număr salon, data internării.

Atribute Determinanţi
1 3 7 9 1+3+9
1.Cod medic 1*
2.Nume medic 1
3.Cod pacient 1*
4.Nume pacient 1
5.Adresa 1
68
 6.Act identitate 1
7.Cod secţie 1*
8.Denumire secţie 1
9. Număr salon 1*
10.Capacitate salon 1
11Data internării 1
12.Cod Internat 1*
13 Data internării 1
În urma unei analize riguroase a matricei simplificată sau complexă, se vor
defini deci tipuri de entităţi optimizate, în care să nu mai existe decât dependenţe
funcţionale corecte (elementare sau neelementare).

B). Diagrama dependenţelor funcţionale

Diagrama dependenţelor funcţionale serveşte pentru reprezentarea grafică a
modelului de date sub forma unui graf, care se construieşte începând cu
dependenţele funcţionale identificate. Apoi, pe baza acestora, se pot defini
entităţile modelului Entitate-Asociere, astfel încât să nu existe dependenţe
funcţionale complexe între ele.
Practic, luând în considerare toate atributele identificate în cadrul problemei de
rezolvat, identificăm dependenţele funcţionale şi apoi le grupăm în cadrul
diagramei în funcţie de determinanţi. În cadrul diagramei sunt puse în evidenţă
dependenţele funcţionale tranzitive, care vor trebui apoi eliminate.

C). Reguli pentru trecerea de la diagrama dependenţelor funcţionale la

modelul Entitate-Asociere.

- Pentru fiecare dependenţă funcţională în care determinantul este elementar

se va crea un tip de entitate în care determinantul respectiv va avea rol de
identificator. Ex. Cod medic, Nume - se va crea entitatea Medici cu
identificatorul Cod medic.
- Toate atributele care au acelaşi determinant în cadrul dependenţelor
funcţionale vor fi grupate în acelaşi tip de entitate, având ca identificator atributul
cu rol de determinant în cadrul dependenţelor funcţionale
- Fiecare dependenţă funcţională dintre identificatorii tipurilor de entităţi va
avea corespondent, în cadrul modelului entitate-asociere, un tip de asociere.
- Pentru fiecare dependenţă funcţională neelementară, deci care are
determinantul format din mai multe atribute, se crează un tip de asociere
neierarhică, definită prin atributul care are rol determinant în cadrul dependenţei
funcţionale.
Respectând aceste reguli şi realizând încă o dată matricea dependenţelor
funcţionale se poate observa că, pe fiecare linie a acesteia a rămas înscrisă o

69
singură valoare de 1, ceea ce înseamnă că fiecare atribut are un singur
determinant.

3.5. Alte forme ale MEA

Un model entitate asociere poate fi dezvoltat ulterior, funcţie de condiţiile

concrete ale problemei date, prin:
- generalizare sau definire de supertipuri;
- specializare sau definire de subtipuri;
- introducerea timpului şi crearea unui model temporal.
Astfel, prin generalizare se grupează, în cadrul modelului EA, caracteristicile
comune într-un supertip de entitate, în timp ce elementele de descriere specifice
sunt grupate în subtipuri de entităţi. Ca exemplu, putem considera cazul
documentelor care circulă în cadrul compartimentului financiar-contabilitate şi
înregistrează diverse operaţii ce se execută aici, cum ar fi: factura, ca document
care însoţeşte o intrare de produse şi ordinul de plată, ca document de plată a
facturii respective (care se presupune că a fost confirmată şi acceptată la plată).
Se ştie că o factură cuprinde informaţii despre:
- număr factură (document);
- data facturii;
- unitatea beneficiară (denumire, banca şi cont);
- unitatea furnizoare (denumire, bancă şi cont);
- rândurile facturii, cu date despre produsele livrate, cantitatea şi preţul
acestora, valori calculate pentru Tva şi total.
În mod similar, un ordin de plată conţine în prima parte informaţii despre:
- numărul ordinului de plată (document);
- data documentului;
- unitatea beneficiară (denumire, banca şi cont);
- unitatea plătitoare (denumire, bancă şi cont);
- suma şi obiectul supus plăţii.
Prin generalizare, caracteristicile comune oricărui document care formează
practic antetul acestuia, şi anume: numărul, data, beneficiarul şi emitentul pot fi
grupate într-un supertip, numit Document, urmând ca datele din conţinutul
acestora (rândurile documentului) să formeze subtipuri sau subclase de entităţi
(rând factură). În mod firesc, subclasele moştenesc atributele supertipului, iar
atributele supertipului nu aparţin subtipului.
În practică sunt numeroase astfel de cazuri, când în ansamblul entităţilor care
aparţin unui anumit tip există subgrupuri cu o anumită relevanţă pentru realitatea
reflectată şi ca urmare, trebuie reprezentate explicit.

70
 Aceste grupuri de entităţi se numesc subclase ale tipului, acesta fiind, la rândul
sau, superclasa acestora.
Ca exemplu, entităţile aparţinând tipului ANGAJAT pot fi grupate în muncitor,
tehnician, inginer, economist etc. Fiecare entitate a unui asemenea grup este, în
acelaşi timp, o entitate a tipului ANGAJAT, care ne apare astfel ca o superclasă.
Definirea unor subclase se poate face în principal, astfel:
-pe baza valorilor unui anumit atribut ;
-pe baza unor criterii definite de utilizator.
Prin definirea de subclase se efectuează specializarea entităţilor superclasei
acestora (Angajat). Acestea moştenesc toate atributele superclasei şi pot avea
atribute proprii specifice, inexistente la nivelul superclasei.
În cazul exemplului nostru, în subclasele Muncitor şi Economist ale superclasei
Angajat dintr-o societate, pe lângă atributele comune, specifice oricărui angajat
(Marca, Nume, Loc de muncă, Data naşterii, etc), pentru muncitori pot exista,
suplimentar, atributele specifice Meserie şi Calificare iar pentru economişti
atributul Specialitate.
Reprezentând grafic modelul nostru, se obţine:
ANGAJAT
Marca ANGAJAT
Nume Marca
Loc munca Nume
Loc munca
Data nasterii Data nasterii
nasterii
………. ...
# 0,1 0,1
MUNCITOR ECONOMIST

Specialitate 1,1 este-un este-un 1,1

Meserie
Calificare MUNCITOR ECONOMIST

Meserie Specialitate
Calificare

Se poate observa existenţa unor asocieri Subtip, în care cardinalitatea subtipurilor

este 1,1 iar a supertipului (superclasei) este 0,1.
Generalizarea ne apare astfel ca procesul invers, prin care două sau mai multe
tipuri de entităţi sunt generalizate, pe baza proprietăţilor comune, într-un nou tip.
În această relaţie, tipurile iniţiale devin subtipuri ale tipului obţinut prin
generalizare (Angajat). Dacă ne gândim la o universitate, tipurile de entităţi
Angajat şi Student pot fi generalizate prin tipul PERSOANA, care va prelua astfel
atributele comune ale acestora: Nume, Prenume, Data naşterii, Adresa, Telefon,
Domiciliu, Cod Numeric Personal, etc.
Modalitatea de lucru adoptată în mod concret – specializare sau generalizare –
depinde de cerinţele unei reprezentări cât mai corecte a realităţii, dar şi de
experienţa şi stilul de lucru al echipei de proiectare a noului sistem.

71
 Se impune precizarea că specializarea poate fi totală, ceea ce înseamnă că
orice entitate a tipului face parte, obligatoriu, dintr-un subtip, sau parţială,
însemnând că pot exista entităţi care să nu aparţină nici unui subtip.
În exemplul nostru specializarea este parţială deoarece există şi alţi angajaţi în
afara muncitorilor şi economiştilor. Aceasta este o restricţie de integritate
specifică. În schimb generalizarea, obţinându-se prin gruparea tipurilor de
entităţi deja existente, nu poate fi decât totală.
Între subtipuri poate exista un raport de excluziune, ceea ce înseamnă că
fiecare entitate poate să aparţină unui singur subtip (în exemplul nostru persoana
ori este angajat ori este student). Există însă şi cazuri în care aceeaşi entitate poate
aparţine mai multor subtipuri diferite (altfel spus submulţimile entităţilor care
aparţin subclaselor respective nu sunt disjuncte). Această RI este reprezentată
grafic prin intermediul simbolului de excluziune. În cazul în care nu există
exclusivitate, este posibilă existenţa unei RI de incluziune, care să precizeze
condiţiile în care are loc "suprapunerea" entităţilor care aparţin fiecărui subtip.
De exemplu, dacă Economist şi Cadre de conducere sunt subtipuri ale tipului
de entitate ANGAJATI, se poate formula o restricţie de incluziune de forma: pot
fi cadre de conducere (la nivel mediu sau strategic) numai angajaţii economişti.
Cele doua restricţii de integritate sunt total independente.
Introducerea de subtipuri prin specializare şi/sau generalizare prezintă avantaje
legate de faptul că grupează proprietăţile comune la nivelul tipului (superclasei)
şi permite o reprezentare mult mai clară a unor tipuri de asocieri la care participă
numai o parte dintre entităţi.
CADRE DE
CONDUCERE

Număr nec

compus -din component -in

Economişti
0,n CNP 0,n
Numele
Specialitate
Funcţie

Un model EA de această formă necesită introducerea unor restricţii de

integritate cum ar fi:
- dacă pentru un angajat Specialitate nu este Economist, atunci el nu poate
juca rolul component-în;
Un anumit tip de entitate poate face obiectul mai multor specializări diferite,
dacă aceasta prezintă semnificaţie pentru problema modelată. De exemplu, un bun
oferit pentru o firmă imobiliară poate fi oferit spre vânzare sau închiriere, şi, la
rândul său, poate fi apartament, vilă (casă) sau teren.

72
 Timpul în cadrul MEA
Modelarea EA nu posedă formalisme specifice pentru aspectul temporal.
Totuşi, timpul este frecvent în numeroase probleme, cel mai adesea sub forma
datei calendaristice. Astfel, reprezentarea sa este aceeaşi atât pentru entităţi cu
caracter permanent cum ar fi de exemplu, nomenclatoarele de clienţi, produse,
angajaţi etc. cât şi pentru cele cu caracter aleator, care au semnificaţia unei
schimbări, modificări, asocieri produse la un moment dat, cum ar fi cele cu privire
la facturi, plaţi, încasări etc.
Reprezentarea evenimentelor cu caracter aleator nu prezintă probleme
deoarece, prin definiţie, acestea au o dată la care se produc. În activitatea curentă
de gestiune operativă acestea sunt reflectate în documente care au numere unice
ca identificatori, astfel că data apare ca un simplu atribut. De exemplu, o
comandă, o factură, o plată vor fi identificate prin numărul documentului în care
sunt consemnate şi vor avea un atribut care să specifice data producerii lor (data
comenzii, data facturării, data plăţii).
O problemă deosebită o ridică însă asocierile repetitive sau de scurtă durată
care apar între entităţile stabile. De exemplu, asocierea care apare între un student
şi facultatea la care învaţă. O soluţie ar putea fi cea reprezentată în schema de mai
jos, care prezintă însă dezavantajul de a nu arata decât ultima facultate a fiecărui
student. În cazul în care un student se transferă de la o facultate la alta (problema
fiind similară şi la trecerea de la o grupă la alta), asocierea corespunzătoare noului
loc de studiu o va înlocui pe cea anterioară, deci vechea facultate va fi uitată.

STUDENT
FACULTATE
Marcã ÎNVAŢĂ
1,1 0,n
Nume Data înscrierii
Cod facultate
Prenume îînvaţă-la loc-studiu
Data naşterii Den facultate
Adresa

Se pune însă întrebarea ce se întâmplă dacă trebuie să se cunoască în orice

moment toate facultăţile la care a studiat un student ?
În acest sens se poate introduce un nou tip de asociere între cele două
entităţi pentru a indica facultăţile anterioare. Aceasta nu este însă o soluţie bună,
căci realizările acesteia riscă să nu poată fi identificate: nimic nu împiedică un
student să revină la o facultate la care a mai învăţat cândva, dar pe care a
întrerupt-o. Aceasta înseamnă că aceeaşi pereche de valori "Marca, Cod
facultate", care ar trebui să identifice fiecare asociere, apare de mai multe ori.
STUDENT ÎNVAŢĂ FACULTATE
1,1 0,n
Marcã Data înscrierii
Nume învaţă-la facultatea Cod facultate
Prenume 0,n 0,n Den facultate
Data naşterii
Adresa A-ÎNVĂŢAT
a-învăţat-la
Data inceperii
facultate-anterioară 73
 Pentru a rezolva problema aceasta de evidenţă, este posibilă fie introducerea
unui nou tip de entitate DATA pentru reprezentarea timpului, ceea ce face ca Data
calendaristică să completeze Marca şi Codul facultăţii în identificarea asocierilor,
fie transformarea asocierii în entitate, aceasta având semnificaţia de istoric al
facultăţilor la care a studiat fiecare student. În acest caz identificarea entităţilor
ISTORIC-F se face prin atributul propriu Data inceperii şi prin rolurile entităţilor
STUDENT şi FACULTATE.
STUDENT ÎNVAŢĂ FACULTATE
1,1 0,n
Marcã Data
învaţă -la facultate
Nume încadrãrii Cod facultate
Prenume 0,n 0,n Den facultate
Data naşterii
Adresa A-ÎNVĂŢAT
a-învăţat -la facultate

0,n data incepere

DATA

Data calendaristică

STUDENT ÎNVAŢĂ FACULTATE

1,1 0,n
Marcã îînvaţă -la
Data înscrierii
facultatea
Nume Cod facultate
Prenume Den facultate
Data naşterii
Adresa
0,n
0,n
ISTORIC -FAC ISTORIC -
ISTORIC -
STUDENŢI 1,1 1,1 FACULTĂŢI
Data incepere
Data terminare

Din analiza acestor exemple se pot trage câteva concluzii cu privire la

reprezentarea timpului în cadrul modelului EA.
Astfel, o soluţie bună ar fi plasarea timpului sub formă de atribute în cadrul
entităţilor sau a asocierilor corespunzătoare; dacă acest lucru nu e posibil, se poate
introduce o entitate abstractă pentru reprezentarea timpului sau se transformă
asocierea dintre entităţile durabile într-un nou tip de entitate care să reflecte
derularea relaţiilor dintre acestea în timp (istoric).
O asemenea extensie introduce distincţia dintre "obiectele" conceptuale,
echivalente entităţilor şi cele temporale.
Entităţile reprezintă deci obiecte persistente care, odată apărute, nu dispar
niciodată. Obiectele temporale materializează rolurile active jucate de un obiect
conceptual în timp.

74
 De exemplu, o persoană este o entitate. De-a lungul vieţii sale, persoana a fost
elev, apoi student şi apoi angajat. Aceste stări sunt reflectate prin entităţi
temporale destincte.

Problemă:
Analizaţi în mod similar necesitatea de evidenţă a angajaţilor unei firme pe
locuri de muncă (compartimente), ştiind că un angajat poate trece de la un loc de
muncă la altul. În mod similar analizaţi problema de evidenţă a angajaţilor pe
funcţii, ştiind că aceştia îşi schimbă funcţia în timp.

3.6. Reguli privind Modelarea Conceptuală a Datelor

3.6.1. Reguli de validare a modelului

Criteriile de validare a modelului sunt reprezentate de cerinţele de informare

ale conducerii. Modelarea datelor s-a realizat iniţial independent de cerinţele
diferitelor aplicaţii, în principal pe baza proprietăţilor obiectelor identificate,
independent de aplicaţiile care operează cu obiectele respective.
Este însă necesar să se verifice în ce măsură modelul conceptual al datelor
satisface diferite aplicaţii, verificând practic completitudinea şi consistenţa sa. Se
efectuează adăugările şi corelaţiile necesare, se verifică dacă relaţiile dintre
entităţi sunt stabilite corect în vederea regăsirii informaţiilor din mai multe entităţi
şi editării unor situaţii complexe cu date agregate, dacă modul în care au fost
definite legăturile dintre entităţi asigură coerenţa informaţiilor din baza de date,
actualizarea concomitentă a datelor redundante acceptate etc.
De exemplu, din legăturile N:1 (compartimente – intreprindere) şi 1:N
(intreprindere – angajaţi) s-ar părea că legătura compartimente – angajatţi, prin
intermediul intreprindere ar face posibilă determinarea angajaţilor care lucrează
într-un anumit compartiment, ceea ce este fals.
Diagrama poate sugera existenţa unei legături între entităţi, fără să existe însă
legături între anumite realizări ale entităţilor respective (pentru relaţiile parţiale).
În concluzie, prin verificarea modelului se poate impune rearanjarea
anumitor componente ale modelului, adăugarea de relaţii suplimentare,
definirea unor relaţii complexe care în final înseamnă introducerea de noi
entităţi.
Există uneori tendinţa de a introduce în modelul de ansamblu al datelor mai
multe legături decât este necesar, eventual chiar toate legăturile posibile. Acest
lucru duce la creşterea nejustificată a complexităţii logice a modelului, a
redundanţelor, la creşterea timpului de realizare a proiectului. De aceea,
introducerea unor noi relaţii sau entităţi în modelul conceptual de ansamblu
trebuie făcută cu mulă atenţie şi numai atât cât este necesar.
Validarea unui MCD presupune deci o activitate care vizează pe de o parte
elementele sale de construcţie, pe de alta completitudinea sa.
75
 Pentru validarea unui model conceptual al datelor din punctul de vedere al
construcţiei se impune respectarea unui set de reguli, dintre care mai importante
sunt:
• Unicitatea numelor
Această regulă se aplică tuturor elementelor care apar în MCD: atribute, roluri,
restricţii de integritate. Prin urmare, se cere eliminarea eventualelor ambiguităţi
prin utilizarea de nume unice şi complete (ex: Nume angajat, Nume client, Nume
beneficiar şi nu, simplu, Nume, crezând că apartenenţa acestui atribut la un tip de
entitate sau altul înlătură de la sine ambiguitatea). În acest sens se impune
eliminarea omonimelor şi sinonimelor în cadrul modelului.
• Atribute derivabile
Atributele derivabile sunt cele ale căror valori se obţin din valorile altor
atribute, de regulă prin relaţii de calcul (ex: Valoarea produsului existent în stoc se
calculează înmulţind Cantitatea din stoc cu Preţul produsului respectiv).
În mod normal, acestea trebuie eliminate din modelul conceptual al
datelor, fiind redundante. Adeseori însă aceste atribute pot prezenta o semnificaţie
particulară deosebită pentru problema studiată, fiind necesare pentru prelucrări
ulterioare(listări, interogări complexe). În asemenea cazuri este posibilă
menţinerea lor în schemă, însoţite însă de precizarea relaţiilor de calcul sau
derivare sub formă de restricţii de integritate.
• Atribute repetitive sau decompozabile
Aceste atribute pot fi menţinute dacă prezenţa lor indică existenţa unor
structuri care trebuie reprezentate ca atare. De exemplu, pentru un student,
reprezentarea rezultatelor la examene constituie un atribut repetitiv şi
decompozabil care indică existenţa unei asocieri între student şi disciplinele
pentru care trebuie să susţină examene.
Această regulă se aplică pentru orice atribut repetitiv sau decompozabil
numai dacă el conduce la evidenţierea unor elemente, entităţi sau asocieri
semnificative pentru problema respectivă. De exemplu, descompunerea atributului
Adresa în Localitate, Strada, Numar se va face numai dacă delimitarea acestora
prezintă interes în raport cu problema modelată.
• Minimalitatea identificatorilor
Aceasta înseamnă că în cazul identificatorilor compuşi dintr-un grup de
atribute nu trebuie să existe un subgrup al acestora care să poată îndeplini funcţia
de identificator. Nerespectarea acestei reguli duce la existenţa dependenţelor
funcţionale parţiale.

• Valoarea NULL.
Atributele cu rol de identificatori ai entităţilor trebuie să aibă valori unice şi
nenule (diferite de NULL). Atributele care nu au rol de identificator pot lua valori
Null, ceea ce conduce la definirea unor subtipuri de entităţi.

76
 • Unicitatea asocierilor
Aceasta cere ca, pentru fiecare realizare a asocierii, să nu existe decât o
realizare a fiecărei entităţi participante la asociere şi invers.
Dacă pentru aceleaşi entităţi apar mai multe asocieri de acelaşi tip, înseamnă că
restricţia de unicitate este încălcată. În acest caz soluţia constă în transformarea
asocierii într-o nouă entitate.

Observaţie:
Ca şi entităţile, asocierile trebuie să fie identificabile iar identificarea lor se
face prin entităţile participante, mai exact prin identificatorii acestora. Condiţiile
impuse identificatorilor: valori nenule şi unice pentru fiecare element trebuie
respectate şi în cazul asocierilor.

De exemplu, dacă ne referim la împrumutatea unor exemplare de la o

bibliotecă de către un cititor, dacă acesta împrumută de mai multe ori acelaşi
exemplar, restricţia de unicitate este încălcată (fiecare restituire să corespundă
unui singur împrumut şi invers). Rezolvarea constă în introducerea unei entităţi
temporale Imprumutate care să caracterizeze împrumutul.

EXEMPLAR
Nr exemplar
An editie
imprumutat restituit
0,n 0,n
ÎMPRUMUT RESTITUIRE
=
Data restituire CITITOR
Nr legitimatie
1, n 1,n
conţine restituie Nume
Imprumutate Data nasterii
1,1 Împrumută 0,n
Data imprumut Categorie
facut -de imprumuta Limita impr

Aici, fiecare împrumut este identificat prin atributul Data împrumut şi prin
rolul împrumută al cititorului. Un împrumut este făcut de un singur cititor şi poate
cuprinde unul sau mai multe exemplare. Exemplarele împrumutate pot fi restituite
toate sau pe rând.
Aceeaşi soluţie este benefică şi atunci când participarea anumitor entităţi este
opţională. De exemplu, produsele comandate de clienţi sunt livrate şi facturate.
3.6.2. Reguli de normalizare a modelului

Modelul Entitate Asociere obţinut ca urmare a unei actitvităţi de analiză a

datelor din sistemul obiect, oferă o viziune macro asupra acestora, fiind rezultatul
77
unui proces iterativ care a dus la identificarea şi denumirea entităţilor, a
atributelor acestora, a relaţiilor dintre ele. Un asemenea model trebuie supus apoi
unei acţiuni de analiză specifică, pentru identificarea şi apoi înlăturarea
dependenţelor funcţionale nepermise şi a anomaliilor semnalate.
Acest proces prin care se analizează entităţile şi atributele lor, în scopul
eliminării anomaliilor, a redundanţelor acestora şi se înlătură dependenţele
funcţionale tranzitive sau multivaloare se numeşte normalizare. În procesul
normalizării pot lua naştere tipuri noi de entităţi sau se pot modifica cele existente.
În procesul normalizării, care poate fi abordat atât în varianta top-down cât şi
bottom-up, se pot aplica, pentru uşurinţă şi înţelegere, cel puţin următoarele trei
reguli:

R1. Fiecare entitate trebuie să aibă un identificator cu valori unice nenule şi

atribute elementare. Nu sunt acceptate deci atribute multivaloare (care se repetă)
sau compuse. Identificatorul poate fi format din unul sau mai multe atribute.
Se spune că modelul este în forma normală 1 (FN1).

R2. Toate atributele entităţii, altele decât identificatorul, trebuie să se afle în

dependenţă funcţională directă şi completă cu identificatorul. Aceasta înseamnă că
atributele trebuie să depindă de identificator luat în totalitatea sa şi nu de părţi ale
acestuia. Atunci când identificatorul este un atribut cerinţa este automat
respectată. Dacă însă identificatorul este format dintr-un grup de câmpuri, atunci
se cere o analiză mai atentă a atributelor definite, în vederea depistării
dependenţelor funcţionale parţiale şi înlăturării acestora. Un model care respectă
această regulă se află în forma normală 2 (FN2).

R3. Toate atributele unei asocieri trebuie să depindă complet de identificatorii

entităţilor participante la asociere (altfel spus de identificatorul asocierii) şi să
respecte regulile 1 şi 2. Aceasta înseamnă practic că modelul nu trebuie să conţină
dependenţe tranzitive.

Sintetizând aceste acţiuni de normalizare a unui MCD într-o formă grafică,

rezultă:

Start

Model nenormalizat
78
 Extragerea grupurilor
repetitive (FN1)

Extragerea dependenţelor
parţiale (FN2)

Extragerea dependenţelor
tranzitive (FN3)

Stop

Cercetările în domeniu au arătat că normalizarea poate continua şi după FN3,

pentru a îndepărta toate anomaliile care pot să apară. Astfel, forma normală
Boyce-Codd, după numele celor doi specialişti, R.F.Boyce şi E.F. Codd (FNBC)
cere ca fiecare determinant să fie o cheie candidat.

3.7. Modelul relaţional

3.7.1. Prezentare generală

Pornind de la modelele conceptuale ale datelor, mai exact de la modelul

Entitate/Asociere se poate trece relativ uşor, pe baza unor reguli precise, la
realizarea schemei conceptuale a bazei de date relaţionale.
Ideea este de a reprezenta entităţile şi legăturile dintre acestea sub formă de
tabele (relaţii). Modelul relaţional se bazează pe noţiunea matematică de relaţie,
aşa cum este definită în teoria mulţimilor, şi anume ca o submulţime a produsului
cartezian a unei liste finite de mulţimi numite domenii.
Regulile de conversie ale entităţilor, atributelor şi asocierilor au la bază ideea
minimizării numărului de valori null şi a redundanţei datelor.
Principalele caracteristici ale modelului relaţional sunt:
- nu există tupluri identice;
- ordinea liniilor şi coloanelor este arbitrară;
- articolele unui domeniu sunt omogene;
- fiecare coloană defineşte un domeniu distinct şi nu se poate repeta în
cadrul unei relaţii;
- toate valorile unui domeniu corespunzătoare tuturor cazurilor nu mai
pot fi descompuse în alte valori (sunt atomice).
Codd a introdus, în anul 1985, un set de 13 reguli în raport cu care un
sistem de gestiune a bazelor de date poate fi apreciat ca relaţional.
79
 Un model relaţional de baze de date cuprinde trei componente principale:
• Structura datelor prin definirea unor domenii (valori atomice) şi a relaţiilor
n-are (atribute, tupluri, chei primare, etc);
• Operatorii de prelucrare a datelor, prin operaţii din algebra relaţională sau
calculul relaţional.
• Integritatea datelor prin impunerea unor restricţii;

Noţiunea de atribut este cunoscută şi sub numele de câmp sau caracteristică.

Fiecare atribut poate lua valori într-un domeniu, fiecărei caracteristici
corespunzându-i o coloană în cadrul relaţiei. El este caracterizat de natura
valorilor pe care le poate lua. Astfel, un atribut este de tip numeric, alfanumeric,
şir de caractere, logic etc. Deci, fiecare câmp de date se caracterizează prin ceea
ce se numeşte tip.
Domeniul reprezintă un set de valori pe care le poate lua un atribut.
Relaţia (sau tabela) se defineşte ca o submulţime a produsului cartezian de n
domenii. Ea se prezintă sub forma unei tabele bidimensionale, formată din rânduri
numite tupluri şi coloane numite domenii.
Tuplul reprezintă o linie din cadrul tabelei, numită şi înregistrare.
Schema unei relaţii reprezintă lista atributelor care aparţin relaţiei cu
domeniile lor. Dacă relaţia numită R are atributele A1, A2, ... Ak , atunci schema
relaţională se notează R(A1, A2, ... Ak).
Cardinalitatea relaţiei defineşte numărul de tupluri care aparţin unei relaţii
(rânduri).
Gradul (aritatea) relaţiei este dat de numărul de coloane, deci atribute ale
relaţiei.
Cheia primară reprezintă un atribut sau grup de atribute ale cărui valori permit
identificarea unică a unui tuplu.
Cheie candidată este un atribut sau grup de atribute ale cărui valori pot
identifica un tuplu. Dintre cheile candidate se alege cheia primară a tabelei.
Cheie externă este un atribut sau grup de atribute care joacă rol de cheie
primară într-o altă tabelă. O cheie externă trebuie să respecte cerinţele de
integritate referenţială.
Pentru relaţiile (tabelele) ce constituie o bază de date se fac diferite presupuneri
iniţiale, cum ar fi: inexistenţa unor tupluri duplicate, neapariţia într-o ordine dată a
tuplurilor, neapariţia într-o ordine dată a atributelor, posibilitatea ca toate
atributele să aibă numai valori atomice (nedecompozabile) şi altele.
Tuplurile unei relaţii nu pot să conţină valoarea nulă în coloane ce aparţin
cheii primare.
Mulţimea tuturor schemelor relaţionale corespunzătoare unei aplicaţii se
numeşte schema bazei de date relaţionale, iar conţinutul curent al relaţiilor la un
moment dat se numeşte bază de date relaţională.

80
 Cele mai multe cereri privesc determinarea unor informaţii cu anumite
proprietăţi, iar răspunsul posibil este o relaţie care descrie toate elementele cu
aceste proprietăţi. Modul de prezentare al răspunsului depinde de interfaţa dintre
SGBD şi utilizator.
Algebra relaţională constă deci dintr-o colecţie de operatori ce au ca operanzi
relaţii. Rezultatul aplicării unui operator la una sau două relaţii este tot o relaţie.
Presupunem că toate relaţiile au un număr finit de tupluri distincte şi sunt
descrise printr-o mulţime ordonată de atribute. Atributele se deosebesc prin
poziţia pe care o ocupă în relaţie sau prin numele asociat, numărul atributelor
dând aritatea relaţiei. Cererile din algebra relaţională pot fi exprimate prin cinci
operaţii asupra relaţiilor (tabelelor) numite operaţii de bază, şi anume: Reuniune,
Diferenţă, Produs cartezian, Proiecţie, Selecţie .
Pe lângă cele cinci operaţii de bază, mai pot fi utilizate şi alte operaţii numite
operaţii derivate, ce se pot exprima în funcţie de operaţiile de bază. Utilizarea
acestora permite o mai simplă exprimare a cererilor şi, uneori, dacă sunt bine
implementate, obţinerea unui răspuns mai rapid.
Cele mai des utilizate operaţii derivate sunt următoarele : Intersecţia, Câtul,
Uniunea (join), Uniunea naturală (natural join).
Cu operatorii din algebra relaţională se pot defini noi relaţii ce pot fi utilizate
pentru : regăsirea unor informaţii din baza de date, definirea unor actualizări
(inserare, ştergere sau modificare) în baza de date, definirea unor date virtuale
(vederi), definirea unor rezultate intermediare, definirea unor drepturi de acces la
date, definirea unor cerinţe de stabilitate în cazul accesului concurent la date,
definirea constrângerilor de integritate şi altele .
Se poate obţine o eficienţă mai bună dacă se combină mai mulţi operatori ce
pot să apară într-o succesiune dată în diferitele cereri .

3.7.2. Trecerea de la MEA la schema conceptuală a bazei de date

Întreaga activitate de trecere de la MCD la schema conceptuală a unei baze de

date relaţionale se face pe baza unor reguli precise, care sunt însă intuitive pentru
un proiectant cu experienţă. Dintre acestea precizăm următoarele:
R1. Fiecare tip de entitate din MCD se va reprezenta printr-o relaţie (tabelă) în
modelul relaţional al datelor, iar identificatorul entităţii devine cheie primară
pentru tabelă. Se ştie că valoarea cheii trebuie să identifice în mod unic fiecare
înregistrare (tuplu), că nu se admit valori multiple şi nici valori nule ale acesteia.
R2. Asocierile unare sau binare de tip 1:1 şi 1:N dintre două tipuri de entităţi,
X şi Y, se reprezintă prin fie prin adăugarea cheii primare a lui X la entitatea Y ca
şi cheie străină, fie prin adăugarea cheii primare a lui Y la entitatea X ca şi cheie
străină, fie şi una şi alta.
R3. Asocierile binare de grad M:N se reprezintă prin trei relaţii, două
corespunzătoare entităţilor legate iar a treia corespunzătoare legăturii. Aceasta din
81
urmă va avea drept cheie primară cheile primare ale entităţilor legate, la care se
pot adăuga componente suplimentare.

3.8. Modelarea logică şi fizică a datelor

Am văzut că modelarea conceptuală a datelor defineşte reprezentarea modului

de organizare a datelor independent de tehnologiile de prelucrare a acestora şi fără
a acorda o atenţie deosebită calităţii modelului datelor. Modelul conceptual este
prezentat prin intermediul diagramelor EA şi evidenţiază reprezentarea logică,
detaliată a entităţilor, a asocierilor şi a datelor elementare din cadrul sistemului
obiect.
Modelarea logică a datelor înseamnă de fapt descrierea datelor în
concordanţă cu modul lor de organizare de către sistemele de gestiune a bazelor
de date. Ea urmăreşte, în cadrul modelului datelor, îndeplinirea mai multor
cerinţe, dintre care:
- o structurare performantă a datelor, prin procesul de normalizare;
- un model logic al datelor care să conducă la modelul relaţional de baze de
date şi să răspundă cerinţelor de prelucrare ale utilizatorilor (se poate opta şi spre
alte modele de baze de date, cum ar fi reţea, ierarhice sau orientate obiect).

Observaţie:
Utilizând diagramele EA se poate realiza şi o proiectare orientată obiect.
Obiectul, ca abstractizare a lucrurilor reale prin care datele şi procesele sunt puse
laolaltă, este văzut ca o structură care înglobează atributele (caracteristicile) şi
metodele ce operează asupra acestora. Prin urmare, tehnicile utilizate în analiză şi
proiectare vor fi orientate spre obiecte, nu spre date şi procese , aşa cum prevăd
metodele sistemice.

Procesul de modelare logică a datelor se desfăşoară în paralel cu celelalte

activităţi de proiectare, cum sunt proiectarea rapoartelor, a machetelor de
introducere a datelor, a interfeţei. În fiecare moment al proiectării se compară
modelul logic al datelor cu modelul entitate-asociere rezultat în urma normalizării,
în cadrul unui proces iterativ de corectare şi completare.
Derivarea modelului se realizează practic printr-o succesiune logică de
operaţii, şi anume:
- identificarea stocurilor logice de date;
- înlăturarea referinţelor fizice şi temporare;
- derivarea proceselor logice;
- derivarea fluxurilor logice;
- gruparea proceselor elementare.

Se impune aici să ne reamintim noţiunile de entitate normală şi entitate slabă.

82
 O entitate normală devine în modelul relaţional o tabelă care are o cheie
primară şi atribute non-cheie.
O entitate slabă devine în modelul relaţional o tabelă cu o cheie primară
compusă, în care este inclusă cheia primară a fiecărei entităţi de care depinde
această entitate şi atribute non-cheie. Sunt elemente deosebit de importante, atunci
când definim restricţiile de integritate a bazei de date, pentru a elimina anomaliile
la actualizarea acesteia. Astfel, fiecare cheie primară şi cheie externă din tabelele
unei baze de date relaţionale trebuie să satisfacă restricţiile de integritate:

- Integritatea entităţii (entity integrity) care cere ca nici un atribut care

participă la formarea cheii primare a unei tabele de bază să nu poată primi valori
nule (Not Null);

- Integritatea referenţială (referential integrity) care cere ca, dacă valoarea

unei unei chei externe nu este nulă, atunci ea trebuie să se regăsească printre
valorile cheii primare ale tabelei referite şi, dacă un tuplu referă un alt tuplu dintr-
o altă tabelă, atunci acel tuplu trebuie să existe.
Modelul logic al datelor prevede toate aceste caracteristici, defineşte
atributele, cheile, condiţiile de integritate.

De la modelul logic al datelor se trece la realizarea modelului fizic al datelor,

care este însă în strânsă dependenţă cu sistemul de gestiune a bazelor de date
(SGBD) ales. El trebuie să conducă astfel la schema bazei de date, adică să
precizeze tabelele, structura acestora şi relaţiile dintre ele.
Dată fiind importanţa alegerii SGBD-ului, se impune precizarea unor cerinţe
minimale pe care acesta să le îndeplinească, cum ar fi:
- timp de răspuns minim;
- confidenţialitatea şi securitatea datelor;
- uşurinţă în exploatare;
- portabilitatea aplicaţiilor şi a bazei de date;
- portabilitatea SGBD-ului;
- instrumente pentru generare automată de rapoarte, formulare, meniuri;
- facilităţi de gestionare şi refacere a bazei de date;
- facilităţi de administrare a bazei de date;
- facilităţi de ordin economic , etc.
Practic, odată ales SGBD-ul, se trece la proiectarea fizică a fişierelor şi a bazei
de date, la definirea caracteristicilor fiecărui atribut din modelul logic al datelor, la
descrierea tehnologiilor utilizate pentru crearea fişierelor şi a bazei de date, a
timpului de răspuns preconizat, a sistemului de indecşi creat în vederea grupării
datelor în rapoarte şi interogări, a ordonării lor pentru acces rapid la datele
necesare. Tot în această etapă se stabilesc structurile de stocare a datelor şi
suportul acestora.
83
 Specificaţiile realizate în această etapă vor fi de regulă orientate spre un limbaj
de descriere a datelor (SQL- limbaj standard pentru baze de date relaţionale) sau
spre un limbaj de programare, cum ar fi: Cobol, C, etc. şi vor servi
programatorilor pentru descrierea datelor. În acest sens, modelul fizic al datelor va
specifica, pentru fiecare atribut, următoarele:
- Numele - numele câmpului, servind pentru
identificarea acestuia;
- Tipul datei – formatul datei, inclusiv lungimea ei;
- Reguli de integritate a datelor – precizează limitele
între care se pot înscrie valorile câmpului respectiv;
- Formula de calcul – pentru câmpurile calculate;
- Cifra de control – dacă este cazul, se precizează
algoritmul de obţinere a acesteia;
- Integritatea referenţială – precizează dacă valoarea
câmpului respectiv trebuie să coincidă cu valoarea altui câmp din altă înregistrare.

Observaţie:
În cadrul unei tabele definite acum vom putea defini:
- atribute normale sau ordinare, care nu participă la formarea unei chei;
- atribute desemnate chei primare pentru identificarea unică a unui tuplu al
tabelei;
- atribute desemnate chei alternative, pentru definirea unor căi suplimentare
de acces la un tuplu şi diminuarea timpului de răspuns la interogări;
- atribute desemnate chei externe, de mare importanţă în materializarea
asocierilor dintre tuplurile tabelelor şi care trebuie să respecte o serie de restricţii,
pentru a asigura coerenţa logică a datelor din baza de date.

De aceea, la proiectarea bazei de date, se impune formularea precisă a unor

restricţii, în principal pentru atributele cu rol de chei primare şi chei externe, care
trebuie să fie specificate şi în cadrul documentaţiei puse la dispoziţia utilizatorilor.
Astfel, cheia primară din cadrul fiecărei tabele va respecta cel puţin
următoarele reguli:
- pentru fiecare atribut din cadrul cheii primare nu se acceptă valori nule;
- se impune crearea unui index care să permită doar valori unice pentru
atributul sau combinaţia de atribute care formează cheia primară;
- la fiecare inserare de noi tupluri sau modificare a valorii cheii primare se va
testa mai întâi acest index, pentru a nu permite valori duplicate ale cheii;

Cheia externă din cadrul fiecărei tabele va respecta cel puţin următoarele
reguli:
- pentru fiecare atribut din cadrul cheii externe nu se acceptă valori nule dacă
şi numai dacă pentru cheia externă nu se admit valori nule;
84
 - dacă este necesar, se poate crea un index pentru valorile cheii externe, care
va accepta, probabil, şi valori duplicate;
- se vor crea şi se vor preciza în specificaţiile tehnice de programare,
mecanisme de autorizare a accesului la baza de date, de întreţinere a acesteia,
astfel încât să nu fie violate restricţiile ce se impun acestor chei externe. Când
vorbim despre o cheie externă avem în vedere totdeauna două tabele: o tabelă care
referă – sau părinte - şi una care este referită – sau copil. În acest sens trebuie
precizate clar în ce condiţii se pot efectua asupra bazei de date operaţii cum sunt:
• adăugarea unui tuplu în tabela care referă;
• modificarea valorii cheii externe în tabela care referă;
• ştergerea unui tuplu în tabela referită (copil);
• modificare valorii cheii primare a tabelei referite.

3.9. Probleme

3.9.1. Probleme rezolvate

1. Să se realizeze modelul entitate asociere pentru activitatea de împrumutare

cărţi dintr-o bibliotecă.

Rezolvare:
Se identifică, în urma analizei activităţii respective, următoarele entităţi:
Clienţi
Autori
Cărţi
Domenii ale cărţilor
Edituri

85
 2. Să se realizeze modelul entitate asociere pentru activitatea de gestiune a
mijloacelor fixe din cadrul unei firme.
Precizare:
Se ştie că un mijloc fix este achiziţionat pe baza unei facturi şi este dus la un
anumit loc de folosinţă pentru a fi pus în funcţiune pe baza unui proces verbal de
punere în funcţiune.
De aici el poate fi casat – pe baza unui proces verbal de casare, poate fi vândut
– pe baza unei facturi de vânzare sau poate fi transferat la un alt loc de folosinţă
pe baza unui bon de mişcare.

Rezolvare:

86
 3. Se consideră o societate de valori imobiliare, care oferă clienţilor săi bunuri
imobiliare (apartamente, case, vile) pentru vânzare sau pentru închiriere. La
vânzare se cunosc preţul şi starea bunului (liber, disponibil ulterior). Pentru
închiriere, se cunosc chiria lunară, durata minimă a închirierii şi avansul ce trebuie
plătit.
Rezolvare:
Se observă că un bun al tranzacţiei imobiliare poate fi ofertat pentru vânzare
sau cumpărare. Pe de altă parte, orice bun imobiliar care se tranzacţionează poate
fi: imobil şi în acest caz – apartament, vilă sau casă – ori teren. Toate acestea duc
la specializări ale entităţii bun imobiliar. Astfel, un bun imobiliar face aici
obiectul unei duble specializări, în funcţie de tip (apartament la bloc sau casă/vilă)
87
şi în funcţie de natura ofertei făcute de proprietar (vânzare sau închiriere).
Specializarea elimină în acest caz necesitatea unui atribut care să precizeze natura
ofertei făcute şi a RI de rol care să precizeze că numai un bun oferit spre vânzare
poate fi vândut.
BUNURI
Cod bun 1,1 proprietate
Adresa
Suprafata

# #
APART. CASE VANZARE INCHIRIERE
Etaj Teren curte Pret cerut Chirie lunara
Terengradina Avans cerut
Nr camere Tip incalzir e Stare Durata minima
Nr etaje bloc
CLIENT

SE -VINDE 0,1 Nr client

Nume client
Adresa client
No telefon
1,1
proprietar
VANZARE SOLICITANT OFERTANT POSEDA
1,n
Nr tranzactie
Data vanzare 0,n cumparator vanzator

CUMPARA
# VI NDE

0,n
Notă:
Specializarea tipului de entitate CLIENT aduce avantajul că nu poate fi
ofertant decât un client care este proprietarul unui bun imobiliar, intermediarii
fiind astfel excluşi). Absenţa RI de excluziune dintre cele două specializări
precizează că aceeaţi persoană poate fi atât ofertant pentru un bun cât şi solicitant
pentru un alt bun. RI dintre asocierile CUMPARA si VINDE precizează că,
pentru o anumită vânzare, cumpărătorul şi vânzătorul trebuie să fie persoane
diferite.

4. Să se realizeze modelul entitate asociere şi DDF pentru activitatea de

recepţie hotelieră. Se face precizarea că există mai multe tipuri de camere, că un
client poate consuma şi alte servicii oferite de hotel (telefon, spălătorie,
tratamente, masaje, piscină etc) şi că există posibilitatea rezervării de la distanţă
(fax, telefon, etc)

88
 Sugestie:
Se pot identifica două activităţi mari:
- Cazarea clienţilor , care ocupă camere şi solicită diverse servicii;
- Rezervarea de camere făcută de diferite persoane, prin fax, telefon,etc.,

3.9.2. Probleme propuse

1. Să se realizeze modelul entitate asociere şi DDF pentru evidenţa activităţilor

dintr-un garaj auto. Se ştie că există un parc de maşini, fiecare maşină având
şoferul ei. Maşinile pleacă în curse şi înregistreză consumurile de carburanţi şi
alte cheltuieli ocazionate.

89
 2. Să se realizeze modelul entitate asociere şi DDF pentru activitatea de
evidenţă a stocurilor de produse dintr-o magazie, ştiind că firma cumpără produse
pe bază de factură şi vinde produsele emiţând facturi către clienţii săi. Firma
încasează un comision cuprins între 5 şi 20%.

3. Să se realizeze modelul entitate asociere şi DDF pentru activitatea de

rezervare locuri la avion. Se ştie că sunt mai multe companii aeriene la care se
poate solicita biletul, că aceeaşi companie are mai multe curse, mai multe tipuri de
avion. Se poate solicita bilet de mai multe tipuri, la diferite clase la o anumită
dată.

4. Să se realizeze modelul entitate asociere şi DDF pentru activitatea de calcul

şi evidenţă a salariilor pentru personalul unei firme. Se ştie că fiecare angajat este
încadrat pe un post din statul de funcţiuni, corespunzător nivelului de studii şi
specializare, cu un salariu de încadrare. Lunar se întocmeşte un pontaj cu prezenţa
la lucru. Se calculează drepturile salariale cuvenite, eventual şi cele pentru
concediul medical (mai multe tipuri de boli şi modalităţi de plată) şi se reţin, în
afara sumelor datorate la buget (impozit, şomaj, Cas, etc) şi eventualele reţineri
(rate, credite, penalităţi, etc).

5. Să se realizeze modelul entitate asociere şi DDF pentru activitatea de

creditare bancară. Se ştie că se pot acorda mai multe tipuri de credite, către
persoane fizice sau juridice. Pentru fiecare caz, se realizează o instruire a
clientului, se analizează dosarul acestuia şi, dacă sunt îndeplinite condiţiile de
venituri, de garanţie şi altele ce trebuie precizate, se acordă creditul respectiv.

6. Să se realizeze modelul entitate asociere şi DDF pentru activitatea de

gestiune a studenţilor de la universitatea noastră. Se ştie că un student este înscris
la o facultate (sau chiar 2), învăţământ de zi sau cu frecvenţă redusă, într-un an de
studiu, o grupă, o promoţie. El studiază astfel materiile cuprinse în planul de
învăţământ şi predate de un profesor titular de curs şi se prezintă la examene, unde
obţine diferite rezultate. Formulaţi restricţiile de integritate care se impun.

7. Să se realizeze modelul entitate asociere şi DDF pentru activitatea de

închiriere maşini de către turiştii străini de la o firmă specializată în aceste
activităţi.

8. Să se realizeze modelul entitate asociere şi DDF pentru activitatea de calcul

a manoperei realizate (suma cuvenită pentru operaţiile executate pe fluxul
tehnologic la toate pachetele la care a lucrat) de salariatele unei firme de confecţii,
ştiind că fiecare îşi consemnează toate operaţiile executate pe bonul de manoperă
lansat odată cu pachetul de produse pe flux tehnologic. O muncitoare poate
90
executa la un produs mai multe operaţii diferite. Un pachet lansat în fabricaţie
poate avea un anumit model, o mărime, poate aparţine unui anumit contract, deci
poate avea un unumit termen de livrare. . Fiecare operaţie are un tarif pe model
sau mărime.

9. Să se realizeze modelul entitate asociere şi DDF pentru activitatea de

evidenţă contabilă, ştiind că fiecare document de intrare sau ieşire valori, de
mişcare, de plăţi sau încasări generează o înregistrare în contabilitate (pe debitul
sau creditul unui cont).

10. Să se realizeze modelul entitate asociere şi DDF pentru evidenţa activităţii

de service a unei firme de calculatoare. Se face precizarea că firma prestează
service atât pentru perioada de garanţie şi postgaranţie, cât şi pentru clienţi care au
cumpărat calculatoarele de la alte firme.

11. Să se realizeze modelul entitate asociere şi DDF pentru evidenţa activităţii

curente a unui cabinet medical. Se cere o evidenţă clară a pacienţilor, a
diagnosticelor şi a tratamentelor acestora, a medicilor care îi tratează .

91
 4. MODELAREA CONCEPTUALĂ A PRELUCRĂRILOR
4.1. Concepte de bază

Se ştie că, în cadrul sistemului informaţional, datele circulă şi sunt supuse la

diferite prelucrări. Prelucrările reprezintă practic acţiunile exercitate asupra
datelor pentru obţinerea informaţiilor necesare. Aşa sunt de pildă algoritmii de
calcul a datelor, procedurile manuale sau automate executate asupra acestora.

Modelul Conceptual al Prelucrărilor (MCP) se defineşte astfel ca o

reprezentare schematică a activităţilor desfăşurate în cadrul sistemului obiect, a
prelucrărilor la care sunt supuse datele, independent de structura organizatorică şi
mijloacele de realizare. Modelul trebuie să răspundă la întrebarea: Ce prelucrări se
efectuează asupra datelor? Pentru aceasta analistul trebuie să identifice cât mai
complet şi corect care sunt acţiunile, cu toate operaţiile lor componente şi care
sunt evenimentele care le declanşează. În aceste condiţii MCP realizează
reprezentarea grafică a succesiunii operaţiilor, a condiţiilor necesare pentru
declanşarea lor şi a consecinţelor lor.
Modelul conceptual al prelucrărilor vede întreaga prelucrare ca o succesiune
ordonată şi logică de proceduri înlănţuite, toate acestea în strictă concordanţă cu
legislaţia în vigoare. În acest sens nu se poate neglija impactul utilizării
instrumentului informatic (SGBD) asupra MCP. Astfel, anumite validări pot fi
efectuate încă din faza de culegere a datelor, evitând să se constate ulterior că
datele sunt incomplete sau eronate; aceasta înseamnă că anumite operaţii din MCP
pot fi eliminate.
MCP realizează deci modelarea proceselor de prelucrare a datelor, redată prin
intermediul diagramelor de flux a datelor (DFD). DFD este deci o reprezentare
grafică a transformării datelor de intrare în date de ieşire.
Pentru ca MCP să fie cât mai stabil, trebuie să fie independent de aspectele
organizatorice, tehnologice şi chiar geografice. El operează cu noţiuni precum:
procesul, operaţia, evenimentul.

Evenimentul se defineşte ca un semnal receptat de sistem, la care acesta

trebuie să răspundă. Practic, el desemnează un fapt a cărui apariţie declanşează o
reacţie în cadrul organizaţiei; apariţia unui eveniment va determina derularea de
activităţi, de operaţii, reprezentând “motorul” unei acţiuni, al unei operaţii (de
exemplu, sosirea unui document, cum ar fi: o comandă, o cerere de credit din
partea unei persoane, etc).
Sosirea unei comenzi de la un client este un eveniment declanşator extern. A
satisface această cerere înseamnă pentru firmă să o transforme într-o livrare de
produse. Descrierea prelucrărilor necesare pentru aceasta constituie modelul
conceptual al prelucrărilor şi trebuie să fie independentă de:
- aspectele tehnologice (dacă se utilizează calculatorul sau nu);
92
 - aspectele geografice (comanda este prelucrată la depozit sau în altă parte);
- aspecte organizatorice (livrarea este facută de o persoană de la serviciul
comercial sau de la magazie);
- aspecte temporale (livrarea se face dimineaţa sau seara).
Evenimentele pot fi externe, dacă provin din afara sistemului obiect şi nu pot fi
controlate de acesta. Evenimentele generate de desfăşurarea unei operaţii se
numesc interne şi pot fi de tip rezultate, destinate mediului extern sau
intermediare, având rolul de a declanşa alte operaţii în sistem.
Pentru a vorbi de un eveniment trebuie să fie îndeplinite anumite condiţii:
- să se întâmple ceva (în afara sau în interiorul firmei);
- acest ceva trebuie să fie perceput de sistem;
- firma să fie interesată, văzând în el un posibil eveniment declanşator al
activităţii sale.
Operaţia reprezintă o succesiune de acţiuni elementare care generează
evenimente interne, împreună cu regulile de producere a acestora.
Se numeşte tip de operaţie o categorie de operaţii care prezintă aceleaşi
caracteristici. Un tip de operaţie se caracterizează prin următorii parametri
caracteristici:
- denumirea operaţiei;
- durata exprimată în unităţi de timp;
- acţiunile elementare componente;
- evenimentele emise şi condiţiile de emitere.
O operaţie se finalizează întotdeauna prin emiterea de evenimente funcţie
de situaţiile identificate pe parcurs şi de condiţiile exprimate de aceste situaţii
(aşa-numitele reguli de emisie).

Observaţie:
O operaţie se desfăşoară în timp, având o anumită durată. La un moment dat ea
poate fi :
- în aşteptarea execuţiei;
- în curs de execuţie;
- terminată.

Se numeşte rezultat sau eveniment emis produsul executării unei operaţii.

Întotdeauna este respectată regula conform căreia o operaţie produce unul sau mai
multe rezultate. Descompunerea unei operaţii în mai multe operaţii distincte
determină apariţia unor rezultate intermediare. Un eveniment emis poate fi în
acelaşi timp un eveniment declanşator pentru o altă operaţie (sau alte operaţii).
În MCP toate operaţiile trebuie să aibă rezultat.
În unele cazuri obţinerea rezultatelor poate fi condiţionată de îndeplinirea
anumitor condiţii. În acest caz este necesar să fie definite aşa numitele reguli de
emisiune sau reguli de acţiune.
93
 Spre exemplu, dacă valoarea facturată este mai mare de 2 milioane, atunci se
acordă un discount de 1o%. La lansarea unei livrări se impune verificarea
stocului existent, astfel: dacă stocul este insuficient, comanda este ţinută în
aşteptare (nu se întocmeşte dispoziţie de livrare), altfel se onorează livrarea.
Condiţia de stoc suficient defineşte în acest caz o regulă de emisiune a
rezultatului cu două cazuri diferite: stoc suficient şi stoc insuficient.
Se numeşte sincronizarea unei operaţii un ansamblu de condiţii care determină
declanşarea operaţiei, exprimate de fapt printr-un ansamblu de evenimente
declanşatoare. Ea se exprimă printr-o expresie logică. Sincronizarea reprezintă
deci concordanţa între două sau mai multe evenimente.
Conceptul de sincronizare exprimă o logică şi o dinamică a prelucrărilor. La un
moment dat, expresia logică poate fi verificată. Spunem atunci că sincronizarea
este activă şi operaţia este declanşată. La un alt moment însă este posibil ca un
singur eveniment declanşator să fie realizat; în acest caz sincronizarea este în
aşteptarea realizării altor evenimente participative care să declanşeze operaţia.
Dacă nici un eveniment nu are loc, sincronizarea este inactivă.
De exemplu, în procedura de acordare a unui credit, modelul conceptual al
prelucrărilor descrie ceea ce se face, fără a preciza nici cine face şi nici cu ce
instrument. Astfel, odată cu primirea cererii de credit (care este un eveniment
extern), are loc o operaţie de instruire a deschiderii unui dosar de creditare, care se
finalizează după caz (funcţie de regulile de emisiune concrete) printr-un refuz
(cerere nerezolvabilă), prin deschiderea efectivă a unui dosar de creditare şi în
sfârşit, printr-o cerere de informare suplimentară (vezi fig. 4.1).
Procesul se defineşte în acest context ca un subansamblu al unei activităţi în
care punctele de intrare şi ieşire nu depind de structura organizatorică a societăţii.
De exemplu, în activitatea comercială, procesul de gestiune a comenzilor.
Un proces descrie dinamica prelucrărilor dintr-o activitate determinată. El este
format din operaţii executate ca reacţie la evenimente şi care produc rezultate. Un
proces este:
- omogen, adică operaţiile şi rezultatele concură la o finalitate comună.
- limitat, având graniţe marcate de evenimentele declanşatoare şi de
rezultatele terminale.
Procesul este practic un MCP ce corespunde unui domeniu de activitate. El
este construit printr-un demers metodologic de modelare (analiză, abstractizare,
concepţie) care cuprinde următorii paşi:
- Stabilirea domeniului de investigat, a ariei sale de cuprindere;
- Identificarea evenimentelor declanşatoare, ştiind că fiecare flux de date
este asociat unui eveniment. Aici trebuie stabilite principalele evenimente externe
şi interne ale procesului, acestea fiind elementele cheie în realizarea modelului.
- Întocmirea tabelului Evenimente-Rezultate, care permite definirea
conţinutului procesului şi în care, pentru fiecare eveniment declanşator se

94
precizează acţiunea determinată şi evenimentele emise de aceasta. Avem de a face
cu un tabel de forma:
Evenimente Acţiuni Rezultate sau Evenimente
emise

- Identificarea şi descrierea operaţiilor; O analiză riguroasă a contextului

permite relevarea regulilor de gestiune, care sunt adesea elemente ale operaţiilor.
- Identificarea sincronizărilor; Aparent, mai multe evenimente distincte pot
să declanşeze aceeaşi operaţie. Odată stabilite aceste elemente se poate construi
schema de bază pentru fiecare operaţie, numită bloc operaţie.
- Identificarea regulilor de emisie ; Se caută, printre regulile de gestiune,
pe acelea care definesc condiţii de obţinere a rezultatelor şi se completează
schema de bază cu elementele respective.
- Ordonarea blocurilor-operaţie.
- Elaborarea modelului conceptual al prelucrărilor.
Structura generală a procesului decurge din cronologia evenimentelor. Prin
urmare evenimentele trebuie ordonate cronologic, ceea ce înseamnă că în
ordonarea diferitelor blocuri-operaţie şi legarea lor acţionează principiul : un
rezultat al operaţiei n-1 declanşează operaţia următoare (operaţia n).
- Verificarea şi validarea modelului. În acest sens se verifică dacă:
o orice operaţie duce la cel puţin un rezultat;
o orice operaţie este declanşată de cel puţin un eveniment;
o toate blocurile sunt legate.
Validarea modelului se face de către persoanele implicate în proces.

Observaţie:
Toate metodologiile de proiectare a unui sistem informatic utilizează
modelarea datelor şi proceselor de prelucrare a acestora şi recurg la diagrame de
flux pentru descrierea grafică a acestora.

Diagramele de flux pot fi realizate la nivelul unei componente funcţionale

(aprovizionare, vânzare produse finite, încasare produse sau servicii facturate, etc)
sau a unei componente organizatorice, cum ar fi un compartiment, o secţie de
producţie, de service auto, etc. Oricum, diagramele de flux trebuie să identifice şi
să menţioneze clar următoarele aspecte:
- sursa datelor;
- circuitul acestora;
- prelucrările ce au loc asupra lor în cadrul circuitului;
- destinaţia datelor prelucrate.
95
 Datorită complexităţii activităţilor analizate şi deci şi a datelor şi proceselor de
prelucrare pe care acestea le comportă, diagramele se pot elabora pe nivele de
detaliere, astfel încât să surprindă elementele de bază ale problemei şi să le poată
reprezenta sugestiv, intuitiv.
De aceea, în cadrul diagramelor, se pot identifica:
- diagramele de context;
- diagramele fluxurilor de date ale sistemului fizic existent;
- diagramele fluxurilor de date ale sistemului logic existent;
- diagramele fluxurilor de date ale sistemului logic nou;
Diagrama de context stabileşte aria de cuprindere a sistemului obiect,
precizând elementele din interiorul sistemului şi pe cele din exterior, ca entităţi
externe.
Diagrama fluxurilor de date ale sistemului fizic existent precizează care sunt
procesele de prelucrare a datelor (transfer, calcul, stocare), care sunt intrările şi
ieşirile din aceste procese, care sunt persoanele şi tehnologiile utilizate de fiecare
proces.
Diagrama fluxurilor de date ale sistemului logic existent identifică şi
precizează care sunt funcţiile de prelucrare a datelor, independent de tehnologiile
utilizate.
Diagrama fluxurilor de date ale sistemului logic nou reprezintă grafic
circuitul datelor, prelucrările acestora, structura şi cerinţele noului sistem, aşa cum
a fost gândit el în urma analizei sistemului existent şi a stabilirii direcţiilor de
perfecţionare.
Descrierea obiectelor din DFD se face în aşa numitele Dicţionare de date sau
depozite Case (repository).

Observaţie:
Diagrama Fluxurilor de Date reprezentând modul de transfer al datelor
(circuitul) între procesele de prelucrare a acestora se mai numeşte şi Model al
Proceselor de Prelucrare, iar activitatea se numeşte modelarea proceselor.

DFD reprezintă una din tehnicile de analiză structurată care datează din jurul
anilor 1980.
Dintre tehnicile de prezentare a diagramelor fluxurilor de date mai utilizate în
lumea proiectării sistemelor informatice sunt: Gane & Sarson şi Yourdon & De
Marco1 după numele celor care le-au realizat. Cele două tehnici de reprezentare
sunt foarte asemănătoare, folosind simboluri asemănătoare şi având la bază
acelaşi obiectiv: acela de prezenta cât mai fidel şi sugestiv, pentru o anumită
activitate, domeniu sau societate, sursa datelor, procesele de prelucrare a acestora,

1
DE Marco T- Structured Analysis and Design Specification, Prentice Hall, EnglewoodCliffs,
New Jersey, 1979.
96
destinaţia datelor obţinute în urma prelucrărilor şi eventual legătura existentă între
prelucrări şi activitatea de stocare a datelor.
Yourdon şi DeMarco recomandă însă ca nici o diagramă să nu conţină mai
mult de 7 procese de prelucrare, astfel că se ajunge ca, pentru un sistem sau
activitate complexă să se realizeze o descompunere, pe nivele, de sus în jos
(tehnica Top-Bottom) a diagramelor de flux a datelor până la procese sau operaţii
elementare. De aceea vom întâlni în reprezentările grafice diagrame din ce în ce
mai detaliate, de nivel 0, 1, 2 şi aşa mai departe.
Pentru reprezentarea fluxului de date şi a proceselor de prelucrare a acestora se
pot utiliza mai multe simboluri grafice, cum ar fi cele specifice metodologiei
SSADM, care vor fi prezentate în cadrul metodologiei respective, dar şi o serie de
alte simboluri consacrate, cum ar fi:

Descrierea unui proces: un dreptunghi cu

colţurile rotunjite, despărţit în două zone Nr proces
care specifică numărul şi respectiv denumirea
procesului de prelucrare descris. Denumire proces

Descrierea operaţiunii de stocare a datelor, indiferent de mediul manual sau

informatizat în care se realizează se reprezintă grafic printr-un dreptunghi alungit,
cu două zone: una specifică numele, identificatorul unic al locului de stocare şi
alta care precizează numele acestuia.
D1 Produse
Se ştie că entităţile pot fi surse de date, de unde pleacă datele în prelucrarea
lor, sau locuri de stocare a acestora. De aceea este posibil ca în cadrul unei
diagrame a fluxului de date numele unor entităţi să se regăsească şi ca locuri de
stocare a datelor.
La aceste simboluri se mai adaugă:
Pentru timpul de sincronizare a operaţiilor simbolul grafic:

logică
Propoziţie

Pentru o entitate externă un pătrat simplu sau îngroşat:

sau

Pentru fluxul de date se pot utiliza săgeţi sau arce de cerc de diferite forme:

97
 Un flux de date înseamnă practic un traseu, un circuit pe care datele
(elementare sau grupate) se deplasează în sistem sau din sistem.
Pentru procese se pot utiliza în reprezentarea grafică şi cercuri cu textul
explicativ scris în interior.
Cu privire la reprezentarea modelului prelucrărilor prin diagramele de flux a
datelor, pentru o bună înţelegere a acestora, se fac, în metodologiile de proiectare
utilizate, o serie de convenţii, dintre care mai importante sunt:
• procesele de prelucrare şi stocurile de date sunt numerotate secvenţial,
pentru a putea fi identificate. Numerele asociate lor nu semnifică ordinea de
execuţie a acestora;
• pentru a face diagramele mai uşor de înţeles, entităţile externe sunt plasate,
de regulă, în jurul diagramei iar stocurile de date în partea centrală ;
• pentru mai multă claritate, DFD nu conţine mai mult de 7- 9 procese;
• fluxurile de date de la sursă către stocurile de date sunt unidirecţionale (fie
de adăugare, fie de consultare) şi nu sunt etichetate.
• pentru a evita fluxurile de date întretăiate entităţile externe şi stocurile de
date pot fi duplicate. O entitate externã duplicată se reprezintã prin trasarea unei
linii oblice, iar un stoc duplicat printr-o linie suplimentară verticală în partea
stângă a cutiei

Exemplul 1:
Analizând procedura de acordare a unui credit, MCP ar putea fi realizat astfel:

98
 Exemplul 2.
Să se realizeze modelul conceptual al prelucrărilor pentru activitatea de
recepţie hotelieră (pentru care am realizat anterior şi modelul entitate asociere).

99
 Exerciţii propuse:

1. Realizaţi modelul conceptual al prelucrărilor şi apoi diagrama de flux

a datelor pentru toate problemele analizate sau propuse spre rezolvare
pentru realizarea modelului entitate asociere şi a diagramei dependenţelor
funcţionale (capitolul anterior).

100
 4.2. Descompunerea funcţională şi rafinarea DFD

Dacă sistemul analizat pe care-l descriem cu ajutorul DFD este complex, nu

vom putea realiza de la început o DFD detaliată. Pentru a descrie însă în detaliu
aceste sisteme, metodele sistemice propun o abordare Top - Down, adică o
descompunere funcţională a sistemului, prin descompunerea succesivă a
proceselor.
Se realizează mai întâi Diagrama Contextuală care defineşte aria de întindere
a sistemului analizat, stabilind graniţele acestuia, separarea lui de mediul extern.
Acesta este primul nivel – numit nivelul 0 - al DFD. Fluxul de legătură a
sistemului cu mediul său se numeşte interfaţă.
Nivelele următoare se obţin prin rafinarea (descompunerea) proceselor
complexe într-o diagramă de nivel inferior. Rafinarea poate continua până se
ajunge la operaţii elementare.
E bine ca în cadrul operaţiei de rafinare a DFD să respectăm următoarele
reguli1:

• fiecare proces va fi numerotat corespunzător nivelului de descompunere şi

poziţiei în cadrul diagramei. Astfel, dacă procesul 2 din diagrama de nivel 1 va fi
descompus, procesele de nivel inferior vor fi: 2.1, 2.2., ...
• fluxurile de intrare şi de ieşire pot fi şi ele descompuse în componente;
• o diagramă de pe orice nivel de descompunere nu trebuie să conţină mai
mult de 9 procese;
• descompunerea DFD se poate considera terminată atunci când ajungem la
procese elementare. Procesele elementare sunt marcate în colţul din dreapta jos
prin "*".
• pentru procesele elementare se realizează o descriere sau o specificaţie, sub
formă de text; se poate recurge însă şi la alte posibilităţi de reprezentare, cum
sunt: pseudocod, scheme logice, tabele de decizie sau chiar cod scris într-un
limbaj de programare;
• regula balansului cere ca intrările şi ieşirile unei diagrame de nivel inferior
să coincidă cu intrările şi ieşirile procesului pe care-l descompun.

Observaţie:
Alături de diagrame de flux a datelor pot fi utilizate cu succes şi alte forme
de reprezentare a sistemului obiect sau ale celui nou, cum ar fi de pildă schemele
logice de sistem, schemele de structură ale sistemului, etc.

4.3. Modelul fizic al prelucrărilor

1
Gh. Sabău, V. Avram, Sisteme informatice pentru management, Oscar Print, 1999 .
101
 Înainte de a realiza modelul logic al prelucrărilor din sistem se impune
construirea unui model organizaţional (fizic) al prelucrărilor, care să ţină seama de
particularităţile organizatorice din cadrul societăţii.

Diagrama fluxului de date fizice (DFDF) ca reprezentare schematică a

sistemului existent, pune în evidenţă entităţile interne, pe cele externe
sistemului, precum şi fluxul datelor între acestea. Practic ea răspunde astfel la
întrebările: Cine realizează prelucrarea, Unde se realizează şi Cum?

O entitate internă poate fi o persoană, un compartiment, o resursă hardware sau

software care participă la transformarea datelor. Toate aceste entităţi sunt
reprezentate în DFDF prin cercuri (cele externe sunt reprezentate prin pătrate) în
interiorul cărora este scris numele fiecărei entităţi (Cine?). Arcele de cerc
reprezintă fluxurile de date şi poartă numele documentului sau modalităţii
concrete prin care se transmit aceste date (Cum?). Locul unde se face prelucrarea
şi se amplasează fişierul este precizat în diagramă şi răspunde la întrebarea Unde?.
Diagramele de flux a datelor pot fi construite manual sau utilizând
instrumentele CASE, care sesizează mai uşor deficienţele ce pot apare în cadrul
acestora.
În literatura de specialitate s-a acordat o atenţie deosebită procesului de
construire a diagramelor, dată fiind importanţa lor în în etapa de analiză şi
proiectare ulterioară. Astfel, au fost stabilite reguli de construire şi validare a
diagramelor1 prelucrate şi prezentate ulterior şi de specialişti de clasă în
proiectarea sistemelor informatice din România2, pe care le voi prezenta pe scurt,
şi anume:
1). Despre procese:
• Nici un proces de prelucrare nu poate avea doar ieşiri, căci ar însemna să
obţină date din nimic. Dacă totuşi un obiect are numai ieşiri, atunci el este o sursă.
• Nici un proces nu poate avea doar intrări, altfel, el este o destinaţie.
• Un proces se denumeşte printr-o expresie care începe cu un verb urmat de
precizarea obiectului la care se referă verbul.
De exemplu, creare situaţie stocuri.

2). Despre stocare:

• Datele nu pot fi transferate direct dintr-un loc în altul; ele pot fi transferate
doar prin intermediul unui proces.

1
Celko J, Data Flow Diagrams, Computer Language 4, 1987.
2
Dumitru Oprea, Analiza şi proiectarea sistemelor informaţionale economice, Polirom 1999, pag
221
102
 • De la o sursă externă la un loc de stocare datele nu pot fi transferate direct,
ci prin intermediul unui proces.
• Datele nu pot transferate dintr-un loc de stocare spre o destinaţie externă,
decât prin intermediul unui proces.
• Un loc de stocare se denumeşte printr-un substantiv.
3). Despre Sursă/Destinaţie:
• Datele nu pot fi transferate direct de la sursă la destinaţie; trebuie folosit un
proces de trecere.
• O sursă sau o destinaţie se denumeşte printr-un substantiv.
4). Despre Fluxurile de date:
• Un flux de date are o singură direcţie de flux între simboluri. El poate fi şi
bidirecţional, între un proces şi un loc de stocare a datelor, pentru a sugera o citire
înainte de actualizare; se vor folosi însă pentru reprezentare două săgeţi de sensuri
contrare, deoarece procesul se execută la momente diferite.
• O ramificaţie într-un flux de date arată că aceleaşi date se transferă dintr-un
loc comun în două sau mai multe procese de prelucrare, locuri de stocare sau
surse/destinaţii (de regulă sunt copii ale aceloraşi date).
• Unirea mai multor fluxuri înseamnă că aceleaşi date vin din mai multe
procese sau locuri de stocare spre un loc comun de stocare.
• Un flux de date nu poate reveni direct la procesul pe care l-a părăsit, ci doar
prin intermediul a cel puţin unui alt proces de la care să revină apoi la cel iniţial.
• Un flux de date spre un loc de stocare înseamnă actualizare (modificare
valori, ştergere).
• Un flux de date dinspre un loc de stocare înseamnă restaurare sau folosire
date.
• Un flux de date se denumeşte printr-un substantiv sau mai multe,
semnificând transferul unui pachet de date.
Odată construite diagramele de flux a datelor (fizice), utilitatea lor în procesul
de analiză a sistemului, de identificare a deficienţelor sale funcţionale şi de
stabilire a direcţiilor de perfecţionare este deosebită, cu atât mai mult cu cât
experienţa analiştilor este mai mare.

Dar, pentru a ne baza pe analiza lor, diagramele de flux trebuie să fie corecte,
în sensul că trebuie să îndeplinească un set de cerinţe minimale, cum sunt:

• Diagramele trebuie să fie complete, adică să includă toate componentele

sistemului obiect (analizat). În acest sens se verifică dacă toate fluxurile de date au
o finalitate, duc undeva şi dacă nu au rămas entităţi sau procese în afara
diagramelor, deci nelegate de ceva.

103
 • Diagramele trebuie să fie consistente, adică descrierea unui nivel trebuie
să fie compatibilă cu descrierea nivelului superior sau a celor inferioare.
• Diagramele de flux a datelor să fie completate cu diagramele stărilor de
tranziţie, pentru a scoate astfel în evidenţă şi timpul, ca element determinant.
Contează în acest sens că un proces se produce la un moment sau altul, că un flux
de date are loc zilnic, săptămânal, lunar, etc.

Observaţie:
Procesul de descompunere a diagramelor este şi rămâne totuşi un proces
subiectiv, depinzând atât de complexitatea sistemului analizat, cât şi de experienţa
analistului sau a echipei de proiectare. Acesta va decide când se opreşte
descompunerea, ce nivel de detaliere este cel mai bun pentru analiza datelor şi a
proceselor de transformare a acestora.

Astfel, din analiza diagramelor, analistul poate identifica următoarele

deficienţe:
- fluxurile de date redundante, care vor putea fi apoi eliminate ;
- datele cerute de diverse procese, care nu sunt însă folosite (date nefolosite);
- date actualizate în mai multe locuri, ceea ce duce la inconsistenţa acestora în
sistem; ele vor trbui să fie corect preluate şi actualizate în mod unic în viitorul
sistem proiectat.

4.4 Modelul logic al prelucrărilor

Diagrama fluxului de date logice (DFDL) este o reprezentare simbolizată a

unui sistem, care evidenţiază procesele sistemului, precum şi intrările sau ieşirile
de date în/din procese. Prin ea se reprezintă natura logică a sistemului, ce
activităţi efectuează sistemul, fără să specifice cum, unde sau de către cine sunt
executate activităţile1. Prin urmare, DFDL pune în evidenţă funcţiile executate
de sistem.

Modelul logic al prelucrărilor descrie procedurile logice pe baza

următoarelor criterii: omogenitatea prelucrărilor, frecvenţa acestora, locul lor
de desfăşurare şi recursivitatea prelucrărilor. Procesele sunt reprezentate în
cercuri prin verbe, care descriu acţiunea de executat.

Astfel, în cadrul modelului logic al prelucrărilor vom identifica proceduri

pentru:
- actualizarea bazei de date;
1
Dumitru Oprea, Analiza şi proiectarea sistemelor informaţionale economice, Ed. Polirom 1999,
pag 217
104
 - exploatarea bazei de date;
- salvarea şi/sau restaurarea bazei de date;
- reorganizarea bazei de date;
- protecţia şi securitatea datelor;
- dirijarea tuturor acestor prelucrări.
Pentru fiecare procedură se descriu prelucrările ce trebuie executate:
- meniuri, submeniuri şi ecrane de introducere/extragere a datelor;
- validări, prelucrări asociate ecranelor;
- liste, rapoarte ce vor fi generate, etc

În modelul logic al prelucrărilor se acordă o atenţie deosebită succesiunii

operaţiilor de executat, grupării lor în proceduri de actualizare şi proceduri de
exploatare a bazei de date, precum şi interfeţei cu utilizatorul. Interfaţa reprezintă
o componentă deosebit de importantă a noului sistem, deoarece permite accesul
utilizatorului la funcţiile aplicaţiei, precum şi fluxul de informaţii de la calculator
la utilizator şi invers1. Caracteristicile interfeţei, accesibilitatea, forma ei
contribuie în mare măsură la succesul sau insuccesul unei aplicaţii.
Descompunerea DFD logice se face de sus în jos, sistemul analizat fiind
considerat ca un întreg alcătuit din mai multe subsisteme care interacţionează între
ele. Prin această descompunere succesivă se identifică tot mai multe detalii ale
sistemului obiect.

Observaţie:
Logica proceselor de prelucrare se poate reprezenta utilizând instrumente de
analiză precum:
- engleza structurată;
- tabele de decizie;
- arbori decizionali;
- diagrame sau tabele ale stărilor de tranziţie.

Problemă:

Se consideră o firmă de publicitate. Să se analizeze fluxul informaţional al

activităţii de Prestări servicii publicitate şi să se reprezinte diagrama fluxului de
date şi modelul prelucrărilor.

1
Victoria Stanciu, Proiectarea sistemelor informatice de gestiune, Ed.Cison, 2000, pag.154
105
106
Urmează, în mod firesc, descrierea procedurilor şi a documentelor.
Descrierea procedurilor:
1.Clientul trimite o cerere de ofertă către firma noastră, la departamentul de
publicitate.
2. Cererea este înregistrată în Registrul de cereri al firmei.
3. Se numerotează cererea clientului.
4.Oferta este trimisă directorului firmei .
5.Pe baza ofertei se încheie un contract de colaborare între cele două firme.
6. Dep de contabilitate al firmei noastre de publicitate emite factura pe baza
contractului încheiat.
7.Factura este trimisă către departamentul de plăţi al clientului.
8.Departamentul de plăţi emite ordinul de plată sau fila CEC.
9.Ordinul de plată sau fila CEC este trimisă departamentului de contabilitate al
firmei noastre de publicitate.
10.Departamentul de contabilitate emite chitanţa către client atunci când
primeşte ordinul de plată.

107
 5. METODOLOGII CLASICE ŞI MODERNE DE REALIZARE A
SISTEMELOR INFORMATICE
Sinteza etapelor de realizare a sistemelor informatice

Proiectarea şi realizarea unui sistem informatic presupune, din partea echipei

de proiectare, formată de regulă din specialişti în informatică (analişti,
programatori, ingineri de sistem şi administratori de baze de date) o activitate
laborioasă, grupată în mai multe etape, fiecare având sarcini şi finalităţi bine
stabilite.
Indiferent de metoda de proiectare şi realizare adoptată, pentru sistemele
complexe se impune o descompunere pe subsisteme, pe unul sau mai multe
nivele. Proiectarea unor astfel de sisteme informatice complexe necesită ca
urmare mai întâi o proiectare globală, de ansamblu, în care sunt identificate şi
precizate subsistemele, relaţiile dintre ele şi aplicaţiile componente, colecţiile de
date comune, intrările şi ieşirile din sistem. Proiectarea de detaliu şi realizarea
programelor se face la nivel de subsistem, pentru fiecare aplicaţie în parte, ţinând
cont de cadrul general trasat în proiectarea de ansamblu.
Date fiind importanţa şi specificul acestor activităţi, se impune să facem câteva
precizări cu privire la activitatea de proiectare şi realizare a sistemelor
informatice:
Proiectarea este prin esenţa ei, o activitate prospectivă, căci un proiectant îşi
imaginează un produs care este inexistent în acel moment. El pleacă de la
caracteristicile dorite ale sistemului pentru ansamblul de componente propuse şi
determină caracteristicile necesare acestor componente. În sarcina sa cade
determinarea structurii sistemului având cerinţele şi obiectivele definite iniţial. În
acest context, proiectarea constituie o activitate orientată spre un scop şi
desfăşurată în mod iterativ, prin verificări şi corectări succesive ale proiectului.
Prin conţinutul ei complex şi diversificat, prin natura dificultăţilor întâmpinate
în soluţionarea problemelor, activitatea de proiectare necesită specialişti cu
experienţă, cu aptutudini imaginativ-creative. Proiectantul trebuie să mai fi
participat la elaborarea altor proiecte informatice şi să aibă cunoştinţe de
programare, altfel ar fi dificil să propună structuri fezabile care să poată fi
programate uşor.
Participarea la proiecte anterioare similare poate, pe baza cunoştinţelor
acumulate, să-i ofere un prototip pe care să se bazeze noul proiect.
Oricum, multe din activităţile de proiectare necesită intuiţie şi elaborarea unor
decizii, mult mai uşor de luat dacă proiectantul a învăţat dintr-o experienţă
anterioară. Abordarea unor probleme din ce în ce mai complexe împreună cu
utilizarea de metode, tehnici şi instrumente evoluate, solicită proiectantul să
creeze noi elemente, combinaţii ale acestora, structuri noi, perfecţionate, cu alte
cuvinte să inoveze mereu. Pentru fiecare nou sistem proiectantul selectează şi
ajustează un model existent sau propune unul nou. Astfel, capacitatea creativă a
108
proiectantului îi permite acestuia alegerea tipului de model, a variantei
convenabile. Este semnificativ faptul că aici se construieşte mai întâi modelul şi
apoi se realizează produsul program corespunzător.
Astfel, dacă la proiectarea unui sistem informatic avem de-a face cu un
important potenţial de creativitate al proiectantului, dublat de cunoştinţe şi
experienţă în domeniu, atunci putem spera într-o calitate deosebită a proiectului şi
deci şi a sistemului proiectat.
Am văzut că există o serie de metodologii de proiectare a sistemelor
informatice / aplicaţiilor informatice, cu activităţi specifice şi documentaţie
corespunzătoare. Dintre acestea vom prezenta o metodologie clasică (IBM sau
ICI) şi dintre metodologiile moderne pe cea denumită SSADM.
Deşi ar părea că activitatea de proiectare şi realizare efectivă a unui sistem
informatic este doar sarcina proiectantului specialist, practica dovedeşte în mod
constant că reuşita unui sistem informatic, calitatea lui şi modul cum este primit şi
utilizat de beneficiar depinde, în mare măsură, de implicarea directă a acestuia în
diferitele etape ale proiectării. De modul de colaborare dintre echipa de proiectare
şi beneficiar depinde, în mare măsură, succesul final al sistemului proiectat.

5.1. Metodologia IBM (ICI)

Metodologiile clasice cuprind practic metodologia IBM, preluată şi impusă în

România sub denumirea de metodolodia ICI (Institutul Central de Informatică), ca
metodologie unitară şi obligatorie pentru toţi ofertanţii de produse software.
Practica şi experienţa în utilizarea acestei metodologii de către specialişti timp de
mulţi ani face ca ea să rămână în continuare o metodologie larg utilizată de către
proiectanţii de sisteme informatice şi produse program la cheie. Această
metodologie cuprinde, în succesiunea lor logică, următoarele etape:

ETAPA I. Studiul şi analiza sistemului existent sau Tema de realizare

Obiectivul etapei: definirea cerinţelor şi sferei de cuprindere a sistemului

informatic.
Documentaţia elaborată: Tema de realizare – care aparţine metodologiei ICI
sau Dosarul de studiu şi analiză a sistemului existent – care aparţine metodologiei
IBM.
Activităţi specifice:

A.Studiul sistemului existent, cuprinzând:

1. caracteristici generale
• profilul unităţii economice
• specificul activităţii unităţii economice
109
 • nomenclatorul de produse / servicii prestate
2. studiul cadrului organizatoric
• studiul structurii organizatorice
• studiul metodelor şi stilului de conducere
3. studiul activităţilor de bază (fluxul tehnologic)
4. studiul sistemului informaţional existent
• studiul ieşirilor
• studiul intrărilor
• studiul circuitelor şi fluxurilor informaţionale
• studiul sistemelor de codificare a datelor
5. studiul activităţii de informatică
• dotarea cu tehnică de calcul (numărul, structura şi amplasarea
calculatoarelor)
• personal de specialitate (număr analişti, programatori, operatori,
ingineri de sistem, administratori baze de date, etc)
• aplicaţii informatice în exploatare curentă
• aplicaţii informatice în curs de proiectare
• modul de organizare a datelor

B.Analiza (evaluarea) actualului sistem

Obiectiv: diagnosticarea sistemului existent, adică identificarea neajunsurilor
actualului sistem.
1. Definirea criteriilor de evaluare
• din punct de vedere al gradului de utilizare a capacităţilor de producţie
• din punct de vedere al productivităţii muncii
• din punct de vedere al costurilor de producţie
• din punct de vedere al utilizării forţei de muncă
• din punct de vedere al materiilor prime
• din punct de vedere al satisfacerii cerinţelor etc.
Se identifică şi se specifică aşa numitele puncte forte şi puncte slabe din punct
de vedere al cerinţelor informaţionale ale conducerii.
În concluzie se precizează punctele în care actualul sistem informaţional nu
satisface cerinţele informaţionale ale conducerii.
2. Elaborarea sugestiilor (direcţiilor) de perfecţionare.
În această etapă se stabilesc direcţiile de perfecţionare ale noului sistem
informaţional.

110
 C. Definirea variantelor de perfecţionare a actualului sistem
1. elaborarea variantelor
2. estimarea eficienţei economice pentru fiecare variantă
• costuri
• efecte economice (directe şi indirecte)
3. analiza şi alegerea variantei de sistem.

ETAPA II. Proiectarea de ansamblu (conceperea noului sistem)

Obiectivul etapei: elaborarea proiectului de ansamblu.

Activităţi specifice:
1. definirea obiectivelor sistemului informatic
2. structura sistemului informatic pe subsisteme
3. definirea ieşirilor (situaţii de informare / raportare)
4. definirea intrărilor (documente primare sau alte intrări)
5. definirea sau alegerea modelului matematic implementat
6. definirea sau alegerea modului de organizare a datelor
• fişiere
• baze de date
7. [ alegerea S.G.B.D.-ului ]
8. alegerea variantei tehnice de prelucrare a datelor
9. elaborarea schemei de ansamblu a sistemului informatic
10. [ arhitectura noului sistem ]
11. elaborarea planului de realizare a sistemului informatic

ETAPA III. Proiectarea de detaliu

Obiectivul etapei: Proiectarea logică şi fizică (tehnică) de detaliu a fiecărei

componente a sistemului informatic.
Documentaţia elaborată: 1. proiectul logic de detaliu
2. proiectul fizic (tehnic) de detaliu
Activităţi specifice:
1. proiectarea ieşirilor
2. proiectarea intrărilor
3. proiectarea organizării datelor
• fişiere
• nivel logic
• nivel fizic
111
 • baze de date
• nivel logic
• nivel conceptual (virtual)
• nivel fizic
4. proiectarea sistemului de codificare a datelor
5. proiectarea procedurilor de control şi validare a datelor
6. proiectarea fluxului tehnologic de prelucrare automată a datelor

ETAPA IV. Programarea

Obiectivul etapei: Asigurarea cu resurse software prin efort propriu sau

achiziţie necesare fiecărei aplicaţii. În această etapă este implicată de regulă
numai echipa de proiectare.

Documentaţia elaborată:
1. manualul de prezentare – apare ca o descriere a produsului software
sub aspectul resurselor hardware necesare, problemelor pe care le rezolvă,
performanţelor propuse a fi realizate, anumite restricţii referitoare la program.
2. manualul de utililizare – este destinat utilizatorilor finali ai sistemului.
3. manualul de exploatare – este destinat analiştilor sau programatorilor
din unitatea beneficiară în scopul de a putea întreţine şi dezvolta sistemul în
concordanţă cu modificările ce apar în cadrul unităţii beneficiare.

Activităţi specifice:
1. elaborarea specificaţiilor de programare
2. elaborarea schemelor logice de program cu datele de test necesare
3. elaborarea programelor
4. testarea programelor şi lanţurilor de programe
5. elaborarea documentaţiei de programare

ETAPA V. Implementarea noului sistem

Obiectivul etapei: Testarea şi verificarea performanţelor sistemului în condiţii

concrete de funcţionare (în mediu real).
Documentaţia elaborată: Comportă aspectul unui proces verbal de recepţie;
în cadrul raportului se precizează persoanele care au participat din partea
executantului şi a beneficiarului la implementarea sistemului, condiţiile în care a
avut loc implementarea.
Activităţi specifice:

112
 1. pregătirea personalului unităţii beneficiare pentru exploatarea curentă a
sistemului
2. asigurarea condiţiilor necesare pentru trecerea la starea de implementare
a sistemului
3. încărcarea fişierelor sau bazei de date sau conversia fişierelor
4. alegerea strategiei şi tacticii de implementare
5. implementarea propriu-zisă (testarea sistemului)
6. verificarea performanţelor noului sistem
7. actualizarea şi definitivarea documentaţiei de sistem în concordanţă cu
modificările efectuate pe parcursul perioadei de implementare
8. întocmirea raportului de implementare
9. elaborarea planului de implementare
10. [ omologarea sistemului ]

ETAPA VI. Exploatarea şi întreţinerea curentă a sistemului

Se are în vedere exploatarea curentă a sistemului precum şi adaptarea

sistemului la noile cerinţe ale utilizatorilor sau la modificările intervenite pe
parcurs în cadrul unităţii beneficiare.

5.2. Metodologia S.S.A.D.M. (Structured System Analysis and Design

Method)

Metodologia SSADM (Structured Systems Analysis and Design Method)

a fost elaboratã în Marea Britanie, servind iniţial pentru realizarea sistemelor
informatice din domeniul public. Ea a fost ulterior utilizată pe scară din ce în ce
mai largă, devenind astăzi o metodologie cunoscută şi aplicată cu succes în
domeniul proiectării şi realizării efective a sistemelor informatice.
Metodologia SSADM se poate caracteriza prin următoarele:
• este o metodologie modernă de proiectare sisteme informatice
• face parte din categoria metodelor sistemice de proiectare
• este orientată pe structurarea datelor
• se bazeazã pe specificarea clară a cerinţelor şi a unor reguli precise pentru
proiectarea celor două modele
Metodologia se caracterizează deasemenea prin faptul că pune în evidenţă
două modele: modelul logic şi modelul fizic, separând astfel proiectarea logică
de cea fizică. Ea face apel la utilizarea reprezentărilor grafice, folosind în acest
sens o multitudine de diagrame. Iniţial se defineşte o diagramă contextuală (de
nivel zero) prin care se pune în evidenţă aria de cuprindere a problematicii de
interes; din aproape în aproape diagrama se descompune până se ajunge la module

113
terminale, uşor de programat. Acestea se pot constitui ca module ale aplicaţiei sau
sistemului ce va fi realizat.
În cadrul acestei metodologii sunt definite mai multe etape, ale căror activităţi
sunt riguros precizate.

ETAPA I. Studiu de fezabilitate

În unele metodologii această etapă mai poartă denumirea de studiu preliminar,

studiu de oportunitate sau de diagnosticare. În cadrul ei se urmăreşte
identificarea globală a neajunsurilor sistemului existent şi stabilirea necesităţii şi
oportunităţii trecerii la proiectarea unui nou sistem informatic.
Studiul de fezabilitate se realizează pentru sistemele complexe sau pentru
aplicaţii extrem de severe sub aspectul exactităţii datelor, realităţii şi termenelor
de predare a lucrărilor.
Studiul precizează graniţele sistemului proiectat, cu alte cuvinte care este tema
de realizare, care sunt neajunsurile sistemului existent (să nu uităm faptul că
poate exista un sistem informatic sau o aplicaţie informatică, dar acestea să nu mai
satisfacă cerinţele informaţionale, să nu mai corespundă dotării actuale sau
structurii organizatorice actuale, deci să fie necesară reproiectarea sau chiar
înlocuirea lor), care trebuie să fie performanţele noului sistem şi timpul de
realizare a acestuia.

ETAPA II. Analiza cerinţelor sistemului

Această etapă poate fi asociată cu studiul şi analiza sistemului existent din

cadrul metodologiilor clasice. Are ca scop cunoaşterea sistemului fizic existent şi
identificarea problemelor şi deficienţelor acestuia. Se recurge la un studiu
complex privind activităţile şi fluxurile informaţionale existente, volumul
informaţiilor de prelucrat precum şi aria de cuprindere a sistemului informaţional.
Pe baza acestui studiu se elaborează diagramele de flux a datelor (DFD)
parcurgând următorii paşi:
• se întocmeşte o listă a documentelor fizice implicate în sistemul obiect
• se trasează diagrama fluxului documentelor (DFD)
• se elaborează primul nivel al DFD-urilor prin enumerarea proceselor
(prelucrărilor) care vor fi realizate pentru fiecare document.
Pe baza studiului realizat se recurge la analiza sistemului informaţional pentru
a fundamenta direcţiile de perfecţionare ale sistemului existent şi înlocuirea lui cu
un sistem informatic care să permită satisfacerea tuturor cerinţelor informaţionale
necesare conducerii.
Practic, în această etapă se prezintă, în urma documentării, a investigării şi
analizei efectuate, următoarele:

114
 a. Prezentarea societăţii, principalele sale activităţi, principalii indicatori ce
caracterizează activitatea acesteia, pentru a dovedi şi faptul că aceasta îşi poate
permite realizarea unei lucrări de informatizare într-un anumit domeniu sau în
toate, aşa cum s-a cerut.
b. Structura organizatorică a societăţii, reprezentată grafic prin organigrama
sa, va crea o imagine asupra structurii funcţionale şi organizatorice a societăţii, va
scoate în evidenţă principalele relaţii dintre compartimentele societăţii şi dintre
aceasta şi mediul extern.
c. Prezentarea activităţii sau sistemului obiect se realizează în urma unui
studiu aprofundat al activităţii domeniului sau subsistemului ce urmează a fi
informatizat din cadrul societăţii analizate, pentru a surprinde şi a descrie toate
documentele care circulă în sistem, toate datele şi procesele de prelucrare a
acestora, modelele matematice utilizate în prelucrarea datelor, termene de
realizare, condiţii de validare, etc.
d. Conducerea activităţii analizate descrie structura de conducere a
activităţii analizate, principalele atribuţii şi competenţe ale ale acesteia, încercând
să stabilească cerinţele informaţionale, termene, condiţii de prezentare.
e. Modelul fizic al sistemului existent
Se ştie că DFD este o reprezentare grafică a transformării datelor de intrare în
date de ieşire, folosind un set de simboluri de reprezentare şi având asociat un set
de reguli de completare si validare.
Utilizând metodologia SSADM diagramele de flux a datelor se pot realiza cu
ajutorul următoarelor simboluri:
Proces (prelucrare, transformare): Procesele sunt
etichetate cu text ce sugerează modul de transformare
a datelor şi sunt identificate printr-un număr. În DFD
fizică a sistemului existent, se precizează şi locaţia
(compartimentul / persoana) procesului.
Flux de date: este constituit din datele transmise
între două procese. Fluxul de date e etichetat printr-un
substantiv ce sugereazã informaţia sau pachetul de
informaţii transmise.
Entitate externă: poate fi o sursă sau un receptor de
date, sau poate fi un alt sistem (firmă, compartiment).

Stoc de date: un depozit temporar sau permanent de

date. El poate fi un depozit:
• manual, format din registre, dosare, arhivă de
documente
• pe suport magnetic, sub formă de fişiere sau
baze de date.
115
 Dacă sistemul analizat şi descris cu ajutorul DFD este complex, nu vom
putea realiza de la început o DFD detaliată. Şi, cum metodele structurate propun o
abordare de tip Top-Down, vom realiza o descompunere funcţională a sistemului,
prin rafinarea succesivă a proceselor de prelucrare.
Primul nivel (nivelul 0) îl constituie Diagrama Contextuală, care va defini
graniţele între sistemul analizat şi mediu. Nivelele următoare se vor obţine prin
rafinarea proceselor complexe în diagrame de nivel inferior, respectând regulile
de descompunere cunoscute.
În cadrul acestei etape se realizează mai întâi modelul datelor pentru sistemul
existent.
Modelul datelor pune în evidenţă pe de o parte datele din interiorul sistemului,
iar pe de alta legăturile care există între acestea. Analiza datelor astfel identificate
se realizează apoi independent de modul de utilizare a lor în cadrul sistemului
(procesele de prelucrare).
Pentru construirea modelului fizic al datelor se parcurg următorii paşi:
1. Identificarea entităţilor .
2. Identificarea relaţiilor dintre entităţi. Se poate construi în acest sens o
matrice a entităţilor pentru a analiza şi identifica relaţiile între entităţi.
3. Întocmirea modelului entitate - asociere.
Pentru fiecare asociere dintre entităţi se determină:
- semnificaţia, exprimată printr-un verb;
- tipul legăturii, dat de cardinalitatea acesteia (1:1, 1:M, M:M)

f. Modelul logic al sistemului existent

Pornind de la modelul fizic al sistemului existent, se va obţine prin derivare,
modelul logic al aceluiaşi sistem. Acesta este deosebit de util pentru analiza
sistemului existent şi identificarea cât mai corectă a direcţiilor sale de
perfecţionare, deoarece:
• pune în evidenţă funcţiunile de bază ale sistemului;
• permite identificarea şi eliminarea problemelor legate de redundanţa
datelor şi duplicarea proceselor de prelucrare;
• permite stabilirea cu o precizie mai mare a graniţelor sistemului prin
eliminarea proceselor manuale care nu pot fi automatizate complet.
• pune în evidenţă ce face sistemul, eliminând detaliile referitoare la modul
cum funcţionează sistemul în implementarea actuală;
Construirea modelului logic presupune transformarea diagramei de flux a
datelor fizică în diagrama de flux a datelor logică.
Procesul de derivare a modelului logic va începe de la ultimul nivel de
descompunere al proceselor şi va continua prin agregarea acestora către nivelele
superioare. Pentru aceasta se vor parcurge următorii paşi:

116
 1. Identificarea stocurilor logice de date - se face
pe modelul logic al datelor, prin gruparea într-un stoc logic de date a
entităţilor înrudite sau utilizate frecvent.
După identificarea stocurilor logice de date se construiesc:
- diagrama de corespondenţă între stocurile logice şi entităţile din modelul
logic;
- diagrama de corespondenţă între stocurile logice şi stocurile fizice de date.
2. Înlăturarea dependenţelor fizice şi temporale din cadrul proceselor şi a
fluxurilor de date (din DFD la nivel fizic)
3. Derivarea proceselor logice, care impune următoarele activităţi:
• scoaterea în afara graniţelor sistemului a proceselor manuale care nu pot fi
automatizate (deciziile);
• identificarea şi înlocuirea proceselor care nu realizează nici o transformare
asupra fluxurilor de date cu cele corecte, reale;
• combinarea proceselor care realizează prelucrări asemănătoare sau
multiple, care se execută împreună sau în secvenţă;
• înlăturarea proceselor care ţin de implementarea actuală şi a proceselor
redundante.
De exemplu, în cazul unei aplicaţii de gestiune stocuri de materiale, putem
avea: se combină procesele Ieşire de materiale din gestiune şi Intrare de
materiale în gestiune, deoarece realizează prelucrări asemănătoare. Se introduce
un atribut de genul: tip operaţie, de tip caracter, care va putea lua valorile I pentru
Intrare şi E pentru Ieşire.
4. Derivarea fluxurilor logice care presupune înlocuirea numelui de document
numai cu fluxul de informaţii utilizate efectiv de proces.
5. Gruparea proceselor elementare şi transformarea diagramei fizice în
diagramã logicã, aplicând cei 5 paşi.

g). Catalogul cerinţelor

Pe baza analizei modelului logic al sistemului existent, se poate elabora
catalogul cerinţelor pentru noul sistem, care pot fi descrise într-un tabel de forma:
Nr.crt. Cerinţa Sursa Soluţia
Înregistrarea comenzilor emise
1. clienţi COMENZI
de clienţi
Înregistrarea facturilor de Financiar-
2. FACTURI
desfacere contabilitate
3. Înregistrarea încasãrilor beneficiar ÎNCASÃRI
4. Securitatea datelor analizã SGBD
Refacerea datelor în caz de
5. analizã SGBD
incident

117
 ETAPA III. Specificarea cerinţelor pentru sistemul cerut

Activităţile din cadrul acestei etape se realizează în mai mulţi paşi. Iniţial se
înlătură deficienţele privind organizarea sistemului existent, se construieşte un
model al noului sistem prin modificarea DFD-urilor logice şi a structurii logice a
datelor. În final se construieşte un catalog al cerinţelor şi al entităţilor; pentru
fiecare entitate se prezintă evoluţia în timp a acesteia.
Prin urmare, se porneşte de la modelul logic al sistemului existent, realizat în
etapa de analiză şi de la catalogul cerinţelor formulat pe baza acestuia şi se vor
preciza în detaliu cerinţele noului sistem informatic, ce urmează a se realiza.
Această etapă realizează practic trecerea de la etapa de analiză la cea de
proiectare a noului sistem.
Metodologia SSADM prevede şi aici parcurgerea mai multor paşi, bine
identificaţi şi anume:

a). Definirea soluţiei de realizare a noului sistem (aplicaţii informatice)

În această etapă se realizează o descriere a noului sistem, atât din punct de
vedere al cerinţelor funcţionale ale acestuia, cât şi din punctul de vedere al
costurilor pe care le implică, al condiţiilor de dotare, de personal şi software pe
care le impune societăţii în vederea implementării lui ulterioare. Ca urmare, se vor
realiza următoarele activităţi:
• Descrierea noului sistem, prin prisma următoarelor aspecte:
Cerinţe funcţionale, care se referă la activităţile, la funcţiunile pe care
sistemul informatic trebuie să le realizeze. Se pot formula şi cerinţe noi, legate de
posibilităţile suplimentare de informare, de prelucrare pe care le oferă prelucrarea
automată. De exemplu:
- Se creazã fişierul Comenzi în care sunt înregistrate comenzile emise de
clienţi.
- Se creazã fisierul Facturi Desfacere în care sunt înregistrate facturile
pentru produsele livrate.
- Se creazã fisierul Incasări, în care se înregistreazã încasările în numerar si
prin virament de la clienţi, primite de la Serviciul Financiar - Contabilitate.
Cerinţe nefuncţionale, care precizează, de exemplu, cine sunt utilizatorii
sistemului, ce pregătire trebuie să aibă pentru a putea utiliza viitorul sistem, cum
se pot reface fişierele, baza de date în caz de incident, cum se arhivează şi cât timp
trebuie să fie ele păstrate, etc.
Restricţiile impuse de noul sistem, cum ar fi necesitatea unei dotări minime,
necesitatea asigurării legăturilor cu celelalte aplicaţii existente în funcţiune în
cadrul societăţii, necesitatea alinierii la sistemul de codificare existent sau
necesitatea reproiectării lui, restricţii de ordin legislativ, etc.

118
 • Analiza cost-beneficiu
Se ştie că proiectarea şi realizarea efectivă a unui sistem informatic
necesită o activitate laborioasă a unui număr adeseori mare de specialişti de înaltă
clasă în domeniul informaticii. În aceste condiţii, se va determina costul de
realizare a sistemului informatic, adică preţul plătit proiectantului pentru
realizarea sistemului informatic, la care se adaugă costurile suportate de societatea
respectivă pentru instruirea personalului care va utiliza sistemul, precum şi costul
determinat de achiziţionarea unor componente hardware performante
(calculatoare, plăci de reţea, componente multimedia,etc) şi software (licenţe
pentru sisteme de operare, programe utilitare, limbaje de programare sau sisteme
de gestiune a bazelor de date necesare).
Se va estima deasemenea costul de funcţionare a sistemului informatic în
cadrul societăţii; de regulă acesta nu este semnificativ dacă societatea respectivă
avea calculatoare şi lucrări în funcţiune, deci avea şi un minim de personal
calificat în domeniu.
Cunoscând aceste costuri, se impune calculul beneficiului obţinut prin
realizarea sistemului respectiv, a timpului de recuperare a investiţiei efectuate.
Adeseori, beneficiul constă în calitatea deosebită a informaţiilor furnizate şi
economia de timp pe care o aduce prelucrarea automată a datelor, cu efecte
benefice asupra fundamentării şi derulării actelor decizionale, reflectate într-o mai
bună relaţie cu furnizorii şi clienţii, cu personalul din interior şi cu piaţa şi
creşterea, în acest fel, a profitului realizat.
• Analiza impactului introducerii sistemului informatic
Analiza impactului noului sistem este în stânsă dependenţă cu stadiul societăţii
la momentul respectiv legat de existenţa sau inexistenţa altor aplicaţii informatice
în cadrul ei, ceea ce înseamnă practic existenţa sau nu a unui personal calificat în
domeniu. Deasemenea trebuie precizat dacă introducerea noului sistem atrage
după sine sau nu modificări în structura organizatorică a societăţii. Se specifică
deasemenea dacă este necesară o pregătire a personalului care va utiliza sistemul
în cadrul unor cursuri de lungă durată sau va fi suficientă instruirea făcută de
colectivul de proiectare la implementarea sistemului.

b). Definirea prelucrărilor sistemului

În această etapă se realizează diagrama de flux a datelor la nivel logic pentru
noul sistem. Se analizează cerinţele funcţionale ale noului sistem şi se stabileşte
dacă se păstrează toate funcţiunile acestuia sau nu, dacă apar funcţiuni
suplimentare. Se construieşte, în mod corespunzător, noua diagramă de flux a
datelor la nivel logic pentru noul sistem, care poate fi identicã cu cea pentru
sistemul existent sau poate să difere.
Se descriu apoi, într-o formă tabelară, fluxurile de intrare şi de
ieşire, se descriu entităţile externe, stocurile de date şi procesele
elementare de prelucrare.
119
Exemplu:
Descrierea fluxurilor de intrare / iesire
Nume
Sursa Destinatia Continutul fluxului
flux
Desfacere 1.Înregistrare facturã Codclient, Denclient, Adresac,
facturi desfacere desfacere Contc, Banca_C, Denprod, Um,
Cant, Pu, Tva, Datafactd, Nrfactd,
Totalfactd
Serv. 2. Înregistrare Situaţia Codclient, Denclient, Nrfactd,
Contabilitate încasãri încasãrilor în Datafactd, Sumaîncasatã,
financiarã numerar Dataîncasãrii

c). Definirea datelor din sistem

Dacă au fost stabilite funcţiile noului sistem, pe diagrama entitate asociere se
pot opera modificările care decurg din funcţiunile stabilite.
Dacă au fost eliminate unele funcţiuni, atunci trebuie eliminate şi datele
corespunzătoare acestora şi invers, dacă au fost introduse funcţiuni noi, trebuie
introduse şi noile date, aferente lor.
Se obţine astfel modelul logic al noului sistem, pentru care se realizează în
paralel şi descrierea entităţilor, într-o formă tabelară, cum ar fi de exemplu:

Entitatea CLIENTI
Atribut Natura Lungimea Cheia Primară Chei externe
CODCLIENT N 4 X
DENCLIENT C 15
ADRESAC C 20
CONTC N 18
BANCA_C C 5
SOLD N 9

d). Definirea funcţiilor

În metodologia SSADM funcţia reprezintă un concept de bază care se
referă la un set de procese sau prelucrări care, din punct de vedere al
utilizatorului, se executã împreună, de la început până la sfârşit.
Majoritatea funcţiilor de bază ale unui sistem se regăsesc în opţiunile din
meniul aplicaţiei; există însă şi funcţii care nu apar explicit în meniu, dar sunt
120
realizate în cadrul sistemului. Funcţiile sunt identificate în cadrul diagramei de
flux a datelor, fiecare proces elementar urmând să fie alocat cel puţin unei funcţii.
Clasificarea funcţiilor se poate realiza după mai multe criterii, cum sunt:
1. După modul de iniţiere, putem identifica:
• funcţii iniţiate de utilizator sau de o altă entitate externă sistemului;
• funcţii iniţiate de sistem fie la un anumit interval de timp, fie ca urmare a
rezultatelor unui proces de prelucrare.
2. Dupã efectul pe care îl au asupra sistemului, putem identifica:
• funcţii de actualizare, care modifică datele din cadrul sistemului;
• funcţii de interogare, care se regăsesc în catalogul cerinţelor şi parţial în
diagrama de flux a datelor.
3. După modul de operare, putem identifica:
• funcţii care se execută on-line, realizate în regim de lucru interactiv prin
dialog cu utilizatorul;
• funcţii care se execută off-line, care pot fi iniţiate fie de sistem, fie de
utilizator şi care sunt lăsate să-şi urmeze cursul fără alte intervenţii.
Corespondenţa dintre funcţii şi procesele de prelucrare este determinată de
gradul de detaliere a proceselor în cadrul diagramelor. Dacă diagrama este foarte
detaliată, atunci o funcţiune va grupa mai multe procese. Dacă diagrama nu este
detaliată, fiecare proces poate deveni o funcţie.
Dacă un proces se realizează întotdeauna împreună cu un alt proces, atunci ele
vor fi grupate într-o singură funcţie.
Odată definite funcţiile sistemului, se poate trece la realizarea
matricei de corespondenţă entitate-funcţii. Această matrice pune în evidenţă
aspectul dinamic al sistemului, adică efectul pe care îl au în timp funcţiile
sistemului asupra entităţilor din sistem. Acest efect pe care o funcţie îl poate avea
asupra unei entităţi poate fi:
• creare sau adăugare (inserare): C/I
• modificare: M
• ştergere: S
• arhivare: A
• consultare, interogare: R
• salvare, etc
Fiecare entitate are un ciclu propriu de viaţă, care pune în evidenţă viaţa
entităţii, din momentul creerii sale şi până în momentul distrugerii sau arhivării.
Se construieşte câte o astfel de diagramã pentru fiecare entitate din modelul
entitate asociere. De exemplu, pentru entitatea Produse:
PRODUSE

Actualizare Analiza
PRODUSE stocurilor de produse
121
 ETAPA IV. Specificarea sistemului logic

Această etapă poate fi asociată direcţiilor de perfecţionare a actualului sistem

din cadrul metodologiilor clasice. Astfel, se propun beneficiarului mai multe
variante, ca soluţii de realizare a viitorului sistem.
Acestea sunt analizate de beneficiar şi în urma discuţiilor purtate se alege o
anumită opţiune sau combinaţie de opţiuni pentru proiectarea noului sistem.
Opţiunea selectată va fi descrisă precizând:
• detalii tehnice referitoare la dotarea hardware şi software propusă;
• modul de lucru al noului sistem;
• costurile implicate de proiectarea, realizarea şi funcţionarea sistemului.
Se vor preciza aspecte legate de posibilităţile viitoare de perfecţionare, de
întreţinere şi de dezvoltare a sistemului. În urma aprobării de către beneficiar se
va trece la proiectarea logică de detaliu a datelor şi prelucrărilor (procedurilor).
Proiectarea datelor va duce în final la definirea entităţilor ce vor constitui baza de
date. Proiectarea procedurilor se va face elaborând mai întâi schiţe detaliate ale
proceselor, apoi agregarea acestora. Proiectarea datelor şi procedurilor se
realizează în paralel şi se intercondiţionează permanent.
În această etapă se realizează proiectarea şi descrierea noului sistem, prin
următoarele sale componente:

a). Proiectarea ieşirilor

Proiectarea ieşirilor la nivel logic presupune specificarea structurilor logice
pentru fluxurile de ieşire, adică a situaţiilor, a rapoartelor obţinute precum şi
specificarea caracteristicilor lor.
Acest lucru se realizează de regulă într-un tabel de forma:
Denumire Nr. de
Destinatia Periodicitate Frecventa
document exemplare
1 la cerere lunar
Situatia Serv.
clienţilor debitori Contab. Fin
Serv. Contab.
1 la cerere lunar
Situaţia facturilor Fin
achitate
Ordin de platã Furnizor
3 zilnic aleator
La nivel fizic, se întocmeşte macheta situaţiei de ieşire, formatul său fizic. De
exemplu, macheta pentru "Situaţia produselor vândute".

122
 b). Proiectarea sistemului de codificare
Pentru fiecare cod utilizat în cadrul entităţilor, fie drept cheie de identificare
unică (cheie primară) fie drept cheie externă sau candidat, se va preciza tipul
codului, lungimea şi eventual semnificaţia elementelor componente, în cazul
codurilor structurate. Toate aceste informaţii se pot grupa într-un tabel de forma:

Caracteristica Atribut Natura Lungimea Structura codului

COD_P N 4 cod numeric, structurat

Cod produs astfel: prima cifră arată
N 4 grupa, următoarea
subgrupa, ultimile 3 o
Cod client COD_CLIENT N 4 secvenţă

Număr operaţie NR_OP

Tip operaţie
TIP_OP C 1

c). Proiectarea intrărilor

Proiectarea intrărilor la nivel logic trebuie să prezinte, pentru fiecare document
de intrare, principalele caracteristici, cum sunt, de exemplu:
Denumire Sursa Periodicitate Frecventa
Comandă produse Clienţi
zilnic aleator
Factura aprovizionare Aprovizionare
zilnic aleator
Bon de consum Producţie
zilnic aleator
Situaţia încasărilor în Contabilitate
zilnic 1 / sãpt
numerar financiarã
La nivel fizic proiectarea intrărilor înseamnă proiectarea machetei fizice
pentru fiecare document de intrare proiectat logic. Pentru fiecare astfel de machetă
se va proiecta un ecran de introducere a datelor, se vor preciza în clar condiţiile de
validare a datelor, restricţii legate de domeniul admis al valorilor acestora, condiţii
de integritate a acestora. De exemplu, macheta documentului "Bon de consum".

d). Proiectarea bazei de date

Proiectarea bazei de date înseamnă, şi în cadrul acestei metodologii,
proiectarea bazei de date sub cele trei forme ale sale, anume:
• Proiectarea schemei conceptuale a bazei de date;
• Proiectarea schemei externe;
• Proiectarea schemei fizice a bazei de date.

123
 Se are în vedere realizarea schemei bazei de date rezultate în urma procesului
de normalizare a acesteia. Se prezintă fiecare tabelă a bazei de date, cu atributele
şi descrierea acestora, cu precizarea cheilor primare şi externe.
De exemplu, tabela CLIENTI:
Atribute Tip Lungime Cheie
CODCLIENT
DENCLIENT
ADRESAC
CONTC
BANCA_C
SOLD

e). Proiectarea interfeţei cu utilizatorul

În această etapă se proiectează şi se descrie interfaţa sistemului cu utilizatorul,
având în vedere ca toate funcţiunile identificate şi descrise în cadrul modelului
noului sistem să se regăsească printre opţiunile meniului principal sau ale
submeniurilor aferente.
Se poate realiza la acest nivel o diagramă de structură a noului sistem, pe baza
meniurilor şi submeniurilor proiectate, deci a principalelor funcţii ale sistemului.

f). Proiectarea funcţiunilor noului sistem

În aceastã etapă se prezintă în detaliu, atât la nivel logic, cât şi la nivel fizic,
toate componentele sistemului proiectat. Ca rezultat se obţin specificaţiile tehnice,
numite şi specificaţii de programare, pe baza cărora urmează să se realizeze
întreaga activitate de programare efectivă care urmează. Fiecare componentă va fi
practic descrisă prin: datele de intrare, procesele, algoritmii de prelucrare a
acestora, formatul şi conţinutul rapoartelor de ieşire, condiţii de validare, de
restaurare sau de arhivare. În final se obţine astfel arhitectura logicã a sistemului
nou care se va realiza.

ETAPA V. Proiectarea fizică

În această etapă se realizează, pe baza modelului logic bine pus la punct în
urma etapelor anterioare, mai întâi modelul fizic al datelor şi prelucrărilor pentru
noul sistem şi apoi elaborarea programelor. Se trece apoi la realizarea
documentaţiei pe baza căreia se realizează planul de testare şi implementare a
sistemului sau aplicaţiei proiectate.

Avantajele metodologiei S.S.A.D.M.:

124
 • are la bază o abordare sistemică a societăţii sau domeniului de activitate
informatizat;
• permite o abordare top-down a sistemului obiect;
• este orientată pe structura datelor;
• prezintă o abordare simplă a problemelor prin viziunea utilizatorului.
• pune în evidenţă cele două modele: logic şi fizic, separând iniţial
proiectarea logică de cea fizică;
• utilizează o multitudine de diagrame pentru reprezentarea grafică a
fluxurilor de date şi a prelucrărilor acestora;
• oferă o flexibilitate mare în analiză şi proiectare.
• permite implementarea uşoară a sistemului informatic.
• documentaţia de sistem este foarte sugestivă, completă şi este aproape în
întregime redată sub formă grafică.
• permite utilizarea instrumentelor Case pentru asistarea proiectantului;
• permite o realizare modulară a componentelor sale (programe, proceduri),
o testare modulară şi chiar implementarea sistemului pe module .

5.3. Metodologia MERISE

Cu siguranţă MERISE este numele cel mai puţin cunoscut printre

metodologiile de reazare a sistemelor informatice. Dezvoltarea metodei MERISE
se datorează iniţiativei ministerului francez al industriei, care a venit cu
propunerea realizării unei metodologii de analiză şi proiectare a sistemelor
informatice de timp real ce implică manipularea informaţiilor stocate în baze de
date.
În cadrul metodologiei sistemul informaţional este privit ca un obiect natural,
căci reflectă activităţile de comunicare, transformare şi memorare a datelor, aşa
cum sunt ele în realitate. Pe de altă parte, sistemul informaţional poate fi privit ca
un obiect artificial, dacă aceste activităţi sunt automatizate, deci dacă există
proceduri create pentru a fi prelucrate pe calculator. Astfel, conform acestei
metodologii, proiectarea sistemului informatic constă în analiza sistemului
informaţional obiect real şi proiectarea unui obiect artificial care să-l reprezinte
corect şi să-i crească eficienţa. În cadrul metodologiei putem distinge trei cicluri
majore: ciclul de viaţă al unui sistem, ciclul de decizie şi ciclul de abstractizare
(sau ciclul de modelare). Fiecare din aceste cicluri cuprinde mai mulţi paşi de
dezvoltare.
Astfel, ciclul de viaţă al sistemului cuprinde trei etape :

125
 - Concepţia sistemului, materializată într-o descriere a specificaţiilor
funcţionale şi tehnice de realizare.
- Realizarea propriu-zisă a sistemului, care constă în realizarea efectivă a
programelor şi documentaţiei de utilizare.
- Menţinerea sistemului, care are drept scop adaptarea continuă a sistemului
la evoluţia mediului.
Ciclul de abstractizare sau de modelare este alcătuit din următorii paşi:
realizarea modelului dinamic, a celui static şi a modelului proceselor din sistem.
Practic, avem de a face cu descrierea unei ierarhii cu trei nivele de abstractizare:
- nivelul conceptual;
- nivelul organizatoric pentru prelucrări şi logic pentru date;
- nivelul operaţional pentru prelucrări şi fizic pentru date.
Metodologia MERISE utilizează modelul entitate-relaţie pentru analiza şi
proiectarea modelelor statice, deci a structurilor de date şi reţelele Petri pentru
modelele dinamice.
MERISE nu utilizează diagramele de flux de date care fac legătura între
modelul static şi cel dinamic. De aceea, pentru o analiză şi o proiectare completă
şi eficientă a sistemelor informatice, se recomandă utilizarea acestei metodologii
în conjuncţie cu alte tehnologii. Elementele care stau la baza operaţiei de descriere
a unui proces dinamic sunt următoarele: evenimente, operaţii şi sincronizări.
Ciclul de decizie ţine seama de alegerile ce trebuie făcute în timpul ciclului său
de viaţă şi privesc:
- descompunerea sistemului în subsisteme;
- stabilirea orientărilor majore privind soluţiile tehnologice;
- planificarea realizării sistemului, stabilirea priorităţilor, a interfeţei, etc.
Etapele de realizare a sistemelor informatice corespunzător acestei metodologii
trebuie să abordeze cele trei cicluri (conceptual, organizatoric şi operaţional) şi se
prezintă astfel:
- Studiu preliminar
- Studiu de detaliu
- Studiu tehnic
- Realizarea programelor
- Implementarea
- Menţinerea sistemului în funcţiune
O schemă generală de construire a unui model MERISE cuprinde următorii
paşi:
- construirea diagramei de flux de date utilizând o altă tehnologie;
- ordonarea informaţiilor identificate şi selectate;
- construirea unui model liniar MERISE;
- verificarea sincronizărilor diferitelor operaţii.
Rezultatele utilizării MERISE constau în crearea unei vederi de ansamblu
asupra fluxului informaţiilor, a ordinii temporale şi a interdependenţelor dintre
126
acestea. Aceste informaţii vor fi utile atât la analiza, cât şi la proiectarea
sistemului.

5.4. Metodologii de analiză şi proiectare orientate obiect (A.P.O.O.)

Ideea abordării programării, analizei şi proiectării orientate obiect este apărută

la nivelul anilor 1960 când au fost concepute primele limbaje orientate obiect.
Limbajele orientate obiect nu au dobândit la început un succes prea mare întrucât
nu existau metode de organizare a datelor în concordanţă cu filosofia orientată
obiect.
După anii 1980 s-a conturat apariţia bazelor de date orientate obiect care au
oferit suport pentru aplicarea limbajelor de programare orientate obiect. Însă nici
în aceste condiţii limbajele de programare orientate obiect nu şi-au găsit o largă
aplicabilitate.
O.M.G. (Object Management Group), consorţiu american format din peste 800
de companii ce produc şi distribuie aplicaţii informatice la a căror realizare s-a
utilizat tehnologia orientată obiect, a hotărât să studieze posibilităţile de realizare
a unui standard în domeniul construirii sistemelor software.
Astfel, în 1997 a fost realizat Limbajul de Modelare Unificat (U.M.L. –
Unified Modelling Language).
Proiectarea şi analiza orientată obiect se bazează pe aşa numitul model
obiectual. Acesta a introdus principii precum abstractizarea, încapsularea datelor,
modularitatea, ierarhia şi persistenţa. Nici unul din aceste principii nu este nou,
dar ceea ce este important la acest model de programare, este faptul că aduce toate
aceste concepte împreună, încercând armonizarea lor prin diferite tehnici.
Proiectarea orientată obiect necesită un mod diferit de percepţie a problemelor,
de înţelegere a modului cum urmează să fie analizate, proiectate şi implementate
acestea. În centrul atenţiei se află noţiunea de obiect (respectiv de clasă), aceasta
punându-şi amprenta asupra întregului proces de proiectare şi implementare.
Trebuie specificat faptul că, în decursul timpului, au apărut mai multe metode
de analiză orientate obiect. Acestea sunt relativ asemănătoare, diferind de cele mai
multe ori prin detalii nesemnificative. Printre acestea putem enumera
următoarele :
- OOA/OOD (Object Oriented Analysis / Object Oriented Design); această
metodă a fost elaborată de Coad şi Yourdon şi cuprinde cinci paşi: găsirea claselor
şi a obiectelor, identificarea structurilor, identificarea entităţilor, definirea
atributelor şi, nu în ultimul rând, definirea serviciilor. Comportamentul dinamic al
diferitelor clase este specificat de diagramele de stare ale obiectelor. Această
metodă oferă totodată posibilitatea de măsurare a calităţii proiectării efectuate.
- DOOS (Designing Object Oriented Software), realizată de Wirfs şi Brock.
Metoda constă din două etape, una de identificare a entităţilor din sistem
(clase/obiecte, responsabilităţi şi legături dintre diferitele obiecte) şi o etapă de
127
analiză detaliată, fază în care se stabilesc ierarhii, subsisteme şi protocoale.
Metoda permite realizarea unor specificaţii exacte şi complete.
- OMT (Object Modeling Technique); această metodă a fost realizată de
Rumbaugh. Analiza şi proiectarea se desfăşoară în paralel, în patru etape (analiza,
proiectarea de sistem, proiectarea obiectelor şi implementarea). Este de remarcat
faptul că sistemul este văzut din trei perspective diferite: din punct de vedere
obiectual, dinamic şi funcţional. Această abordare permite realizarea a trei modele
diferite, facilitând traducerea acestora în limbajele de programare orientate obiect.
- OODA (Object Oriented Design with Attributes) a fost realizată de Booch şi
este împărţită în patru etape: identificarea claselor şi a obiectelor, identificarea
semanticii, identificarea relaţiilor dintre acestea şi implementarea claselor. Metoda
împrumută termeni şi concepte din limbajele de programare orientate obiect, cu
preponderenţă din C++, oferind patru perspective asupra problemei abordate (o
vedere logică şi una fizică; un model static şi unul dinamic pentru cele două
vederi).
- OOSA (Object Oriented Systems Analysis), realizată de Shlaer şi Mellor.
Această metodă constă din patru etape: analiză, specificările externe, proiectarea
sistemului şi implementarea proiectului. Faza de analiză este alcătuită la rândul ei
din realizarea modelului informaţional, a celui de stare şi a celui de proces.
- OOAD (Object Oriented Analysis and Design), metodă preponderent
teoretică, a fost realizată de Martin şi Odell pentru a integra aspectele structurale
şi comportamentale ale analizei orientate obiect. Metoda utilizează trei tehnici:
diagrame de flux pentru descrierea proceselor de nivel înalt, scheme de
evenimente pentru comportamentul obiectelor şi scheme de obiecte pentru a
descrie relaţiile şi tipurile acestora.
După cum se poate observa, există o multitudine de metodologii de analiză
orientate obiect, cele mai des utilizate fiind însă OMT şi UML. Tendinţa actuală
este de a unifica diversele metode, UML fiind practic rezultatul unei încercări de
unificare şi standardizare.

UML (Unified Modeling Language)

Metodologia UML se doreşte a fi o reunire a tuturor metodelor de modelare şi
analiză cunoscute până în prezent. Scopul principal a fost acela de a furniza un
mecanism eficient de dezvoltare a programelor, dar mai ales de a impune o unică
metodă de analiză. Practic, s-a căutat ca UML să preia toate aspectele pozitive
întâlnite la celelalte metodologii, şi, pe cât posibil, să elimine toate dezavantajele.
Câteva din avantajele şi dezavantajele implicate de operaţia de unificare a acestora
prin UML pot fi:
- eliminarea unor diferenţe de concepţie şi de notaţie;
- eliminarea conceptelor ce nu s-au dovedit viabile şi păstrarea celor care s-au
dovedit utile.
Printre dezavantajele introduse, amintim:
128
 - introducerea inevitabilă a unui număr de noi concepte, sporind astfel
complexitatea metodei;
- fiecare metodă prezentată până în acest moment ţinea cont de anumite
particularităţi ale problemelor, ceea ce nu mai este posibil în noul context.

Metodologia O.M.T. (Object Modelling Technology)

Este o metodologie modernă de proiectare, mai apropiată de utilizator, mai
uşor accesibilă şi intuitivă, datorită modelelor cu care operează.
Metodologia OMT, introdusă de J. Rumbaugh, este una dintre cele mai
răspândite tehnici de analiză şi proiectare orientată obiect.
Această metodă constă din crearea unui model care cuprinde aspectele
esenţiale ale domeniului problemei, model la care se adaugă într-un pas următor
detaliile necesare implementării, realizându-se astfel proiectarea completă a
aplicaţiei.
Etapele metodologiei O.M.T.:
• analiza sistemului
• proiectarea sistemului
• proiectarea obiectelor
• implementarea sistemului

I. Analiza sistemului

Obiectivul urmărit: construirea (definirea) modelului sistemului informatic în

concordanţă cu obiectivele şi cerinţele prestabilite. Se urmăreşte realizarea unui
model global care conţine obiectele din domeniul aplicaţiei, împreună cu o
descriere a proprietăţilor şi comportamentului acestora.
Analiza sistemului poate fi desfăşurată conform următoarei scheme:

129
 Într-un prim pas viitorii utilizatori formulează obiective şi cerinţe prin prisma
intereselor lor. Analiştii vor recurge la evaluarea obiectivelor şi cerinţelor
utilizatorilor şi vor formula domeniul problemei de referinţă construind pe baza
acestuia un prim model al sistemului. Modelul astfel conceput ar putea prezenta
însă o serie de lipsuri, evitări de situaţii datorate faptului că utilizatorilor le este
greu să formuleze din start tot ce şi-ar dori. Modelul elaborat într-o primă formă
va fi dezvoltat şi rafinat pe baza unor noi interviuri cu reprezentanţii unităţii
beneficiare pentru a lămuri anumite probleme, pentru a surprinde eventuale
scăpări.
Modelul va fi rafinat ţinând seama şi de experienţa dobândită de analişti, de
eventualele concluzii desprinse din documentare sau din concluziile desprinse cu
ocazia realizării unor sisteme asemănătoare. În funcţie de aceste situaţii se va
construi noul model într-o formă reală şi precisă.

Modelul sistemului conceput va cuprinde:

• modelul obiectelor
• modelul dinamic
• modelul funcţional.
Cele 3 tipuri de modele astfel realizate vor constitui suportul pentru trecerea la
proiectarea noului sistem.
Modelul obiectelor reflectă starea statică a sistemului de referinţă. Din acest
considerent modelul obiectelor mai este numit şi modelul static.
Modelul dinamic arată comportamentul sistemului şi al obiectelor dependent
de timp. Acest model este extrem de semnificativ pentru sistemele ce prezintă un
dinamism (schimbări de stări) pronunţat, cum ar fi sistemele informatice de
conducere a proceselor tehnologice (sisteme în timp real).
Modelul funcţional pune în evidenţă intrările şi respectiv procedurile privind
determinarea ieşirilor. Intrările, respectiv ieşirile pot fi mesaje, documente de
intrare, acţiuni concretizate în informaţii stocate pe un purtător tehnic de
informaţii.
Fluxurile dintr-o diagramă de date corespund obiectelor sau valorilor
atributelor. Procesele dintr-o diagramă de flux de date corespund activităţilor sau
acţiunilor din diagrama stărilor claselor de obiecte.

II. Proiectarea sistemului

În cadrul acestei etape se defineşte strategia adoptată cu privire la resursele

hardware şi software. Se precizează structura şi delimitarea sferei de cuprindere a
sistemului sau a fiecărui subsistem. Se defineşte concepţia de organizare a datelor
în fişiere sau baze de date.

130
 III. Proiectarea obiectelor din cadrul sistemului

Este etapa de proiectare şi realizare propriu-zisă a obiectelor, a claselor

definite, a procedurilor şi programelor aferente.

IV. Implementarea sistemului

Are ca obiectiv, ca şi la celelalte metodologii, testarea programelor şi

experimentarea sistemului în mediu real, până la punerea lui în funcţiune şi
intrarea în exploatare curentă.

131
 6. STUDIUL ŞI ANALIZA SISTEMULUI EXISTENT
6.1. Obiective şi activităţi specifice

În sensul general, cuvântul analiză înseamnă descompunerea unui tot în

elementele sale componente semnificative şi studiul relaţiilor dintre aceste
elemente sau altfel spus, totalitatea demersurilor efectuate pentru a cunoaşte o
problemă. În informatică sensul noţiunii s-a extins, astfel că ea nu reprezintă o
simplă fotografiere a unei situaţii, ci reprezintă în acelaşi timp o activitate de
concepţie, de găsire a unor soluţii, ceea ce obligă analistul la un bogat bagaj de
cunoştinţe, iniţiativă, putere de abstractizare şi sintetizare.
Studiul şi analiza sistemului existent reprezintă activitatea prin care se
realizează cunoaşterea sistemului-obiect şi a cerinţelor de informaţii ale
sistemului de conducere, analiza acestora în vederea evaluării performanţelor şi
a limitelor sistemului informaţional existent necesare pentru proiectarea noului
sistem informatic.
Astfel, pornind de la una sau mai multe probleme formulate, analiza trebuie să
stabilească cerinţele pe care trebuie să le îndeplinească noul sistem bazat pe
prelucrarea automată a datelor. Ea se finalizează, conform metodologiilor
moderne de proiectare a sistemelor informatice, într-un model al datelor şi
respectiv un model al prelucrărilor (conceptual, logic şi fizic).
Practic, în această etapă se desfăşoară următoarele activităţi:
a). Investigarea sistemului existent, constând în:
• culegerea de informaţii sau, altfel spus, documentarea;
• studiul sistemului existent sub următoarele aspecte:
- definirea caracteristicilor generale;
- studiul activităţilor de bază;
- studiul sistemului de conducere;
- studiul sistemului informaţional.

b). Analiza sistemului existent, cu următoarele activităţi:

• evaluarea performanţelor şi limitelor sistemului existent;
• evaluarea gradului de pregătire pentru proiectarea şi implementarea
sistemului;
• analiza critică a sistemului existent, cu identificarea punctelor forte şi a
celor slabe.

Abordări posibile:
- pornind de la analiza deciziilor;
- pornind de la analiza datelor;
- mixtă.

132
 c). Sistematizarea informaţiilor culese
d).Evaluarea sistemului existent şi definirea direcţiilor de perfecţionare.

În termenii Teoriei Sistemelor, cunoaşterea unui sistem înseamnă de fapt

cunoaşterea :
- elementelor sistemului şi a legăturilor între ele ;
- intrărilor sistemului;
- ieşirilor sistemului;
- stărilor sistemului;
- funcţiei de convertire (transformarea intrărilor în ieşiri);
- funcţiei de transfer (transformarea unei stări în alta).
Scopul cunoaşterii detaliate a sistemului-obiect şi a cerinţelor de informaţii
poate fi:
 proiectarea unui model al sistemului existent, adică un sistem omomorf cu
ajutorul căruia să se simuleze funcţionarea sistemului real, sau
 proiectarea unui sistem omomorf, care să înlocuiască sistemul existent,
având performanţe mai ridicate, sau
 proiectarea unui sistem raţionalizat :
• care pe baza aceloraşi intrări elaborează aceleaşi ieşiri, dar cu o structură
mai simplă (de exemplu raţionalizarea structurii organizatorice în paralel cu
raţionalizarea sistemului de evidenţă), sau
• care simplifică intrările, structura şi – în cazul în care se dovedeşte necesar
– ieşirile sistemului.
Există două concepte care stau la baza stabilirii elementelor sistemului-obiect,
care – aplicate la activitatea de analiză – identifică două tipuri de structuri:
 conceptul orientat pe organism, care determină structura organizatorică;
 conceptul orientat pe activitate, care determină structura funcţională
În general sunt studiate ambele tipuri de structură, accentul punându-se însă pe
activităţi, în timp ce elementele organizatorice interesează doar prin prisma
aportului lor la realizarea activităţilor.

Studiul sistemului existent cuprinde un grup de activitãţi care urmãresc, în

principal:
 cunoaşterea performanţelor tehnico-funcţionale ale sistemului
informaţional, atât în ansamblul său, cât şi pentru elementele de structură ale
acestuia;
 cunoaşterea cerinţelor informaţionale ale conducerii;
 cunoaşterea lipsurilor şi a restricţiilor pe care le prezintã sistemul existent
faţã de aceste cerinţe.

133
 De modul de realizare a acestor activităţi, de corectitudinea şi completitudinea
informaţiilor culese şi prelucrate depinde întregul proces de realizare a sistemului
informatic. Prin urmare, o bună cunoaştere a sistemului obiect crează premizele
unei proiectări bune a noului sistem informatic.
Pe de altă parte, acţiunile ce se realizeazã în cadrul acestei grupe de activităţi
sunt strâns legate de criteriile de evaluare a performanţelor şi limitelor sistemului
informaţional existent.
În aceste condiţii, cunoaşterea sistemului existent, specificarea cerinţelor de
perfecţionare ale acestuia de o manieră completă şi consistentă nu se poate realiza
făcând complet abstracţie de o anumită viziune structurală asupra “obiectului”
proiectat. Mai ales în condiţiile trecerii spre proiectarea asistată de calculator,
studiul sistemului existent, analiza acestuia şi specificarea cerinţelor rezultate din
analiză se contopesc tot mai mult cu proiectarea. De aceea, este tot mai greu să
separi complet metodele şi tehnicile de analiză de cele ale proiectării.
Totuşi, vom defini şi vom descrie principalele activităţi identificate în cadrul
etapei de proiectare denumită Studiul şi analiza sistemului existent.

6.2. Investigarea sistemului existent

Această activitate, deosebit de laborioasă, care înseamnă practic cunoşterea şi
studiul sistemului obiect, cuprinde o serie de acţiuni care pot fi grupate astfel:
a) Culegerea de informaţii , documentarea
b) Studiul sistemului existent

a). Culegerea de informaţii , documentarea - presupune o succesiune de

operaţii prin care:
- se studiază sistemul-obiect, în general, şi sistemul informaţional-decizional,
în particular, în ceea ce priveşte :
• organizarea sistemului (structura organizatorică);
• fluxul activităţilor;
• fluxul de informaţii;
- se identifică cerinţele şi restricţiile noului sistem, cum sunt:
• cerinţele de informare pentru decizii şi control;
• restricţiile şi cerinţele organizatorice.
b). Studiul sistemului existent presupune, în principal, următoarele activităţi:
 definirea caracteristicilor generale ale sistemului economic;
 studiul activitãţilor de bazã desfãşurate în sistem;
 studiul sistemului de conducere (decizional);
 studiul sistemului informaţional ;
 identificarea metodelor şi mijloacelor tehnice.

134
 Definirea caracteristicilor generale ale sistemului economic implicã, pentru
proiectantul sistemului informatic nou, o cunoaştere corectă a următoarelor
elemente:
 profilul, obiectivele agentului economic;
 locul în sfera serviciilor şi sfera producţiei pe care îl ocupă;
 relaţiile de colaborare sau de subordonare cu alţi agenţi economici;
 specificul activitãţii de bazã ( producţie, servicii);
 nivelul tehnic şi performanţele de calitate a produselor şi/sau serviciilor;
 principalii indicatori economici şi evoluţia lor;
 dezvoltarea, modernizarea, perspectivele pe piaţa concurenţială etc.

Studiul activităţilor de bază desfãşurate în sistemul economic, a modului de

realizare a funcţiunilor unităţii economice necesită următoarele acţiuni:
 Studiul funcţiunilor unităţii economice (sistemul obiect);
 Studiul funcţiei de bază a unităţii economice ;
Astfel, în cazul unei societăţi economice de producţie, trebuie cunoscute şi
descrise, pentru activitatea de producţie următoarele:
- fluxul de producţie ;
- amplasarea locurilor de muncă, a depozitelor, etc.;
- tipurile de produse, structura lor, ciclurile de fabricaţie;
- modul de organizare a producţiei, stocarea producţiei, transporturile
interne, controlul de calitate;
- resursele existente:
 capacităţi de producţie şi /sau depozitare ;
 asigurarea tehnică / proiectarea de produse noi;
 norme tehnice;
 asigurarea cu materiale necesare;
 sistemul existent de programare a producţiei ;
 cercetarea şi marketingul, ca elemente ale producţiei.

Studiul sistemului de conducere are ca scop, în principal :

 identificarea caracteristicilor sistemului de conducere existent ;
 sistemul de indicatori cantitativi şi valorici necesari actului decizional ;
 organizarea conducerii;
 caracteristicile rezultate din statutul de funcţionare a societăţii, tipuri de
decizii, modul de luare a deciziilor ;
 tipul de management practicat la nivelul societăţii respective, etc.

135
 Studiul sistemului informaţional existent reprezintă o etapă de investigare, de
cunoaştere exactă a sistemului informaţional existent, concretizată în
următoarele :
 studiul documentelor care circulă în sistem, a conţinutului informaţional al
acestora, al circuitului lor, al periodicităţii cu care se emit;
 elaborarea schemei fluxului informaţional global (cu punerea în evidenţă a
principalelor activităţi şi a legăturilor statice şi dinamice dintre acestea);
 estimarea cantitativă şi calitativă a informaţiilor de intrare-ieşire, modul de
culegere şi prelucrare;
 identificarea principalilor algoritmi, a regulilor de calcul şi a punctelor şi
regulilor de control;
 cunoaşterea principalelor restricţii ale sistemului informaţional;
 situaţia raţionalizării fluxurilor şi a documentelor din unitatea economică,
studii elaborate, stadiul lor de implementare;
 sistemul de codificare utilizat, restricţii;
 performanţele şi limitele sistemului informaţional existent.

Identificarea metodelor şi mijloacelor tehnice utilizate pentru prelucrarea

datelor în cadrul sistemului informaţional existent se face studiind şi analizând :
 mijloacele tehnice existente în dotarea unităţii economice (modul de
utilizare, cheltuielile de exploatare, personalul implicat, performanţe);
 existenţa unor aplicaţii proiectate şi/sau implementate.

6.3. Analiza sistemului existent

Odată terminată documentarea, investigarea sistemului existent, urmează

analiza sistemului existent, care constã în următoarele etape:
• evaluarea performanţelor, a limitelor sistemului informaţional existent în
raport cu cerinţele sistemului de conducere;
• evaluarea gradului de pregătire al unităţii economice pentru introducerea
noului sistem informatic.
Evaluarea performanţelor şi limitelor sistemului existent se face pe baza
următoarelor criterii:
• mãsura în care sistemul informaţional asigurã realizarea obiectivelor,
îndeplinirea funcţiilor şi sarcinilor de bază ale unităţii şi exercitarea atributelor de
conducere;
• gradul de asigurare cu informaţii necesare şi suficiente a conducerii la
diferite niveluri, a compartimentelor funcţionale;
• operativitatea în culegerea şi transmiterea informaţiilor şi datelor, ceea ce
caracterizează timpul de răspuns al sistemului informaţional;

136
 • calitatea informaţiilor obţinute din prelucrare, privitã sub aspectul preciziei
de exprimare şi sub aspectul flexibilitãtii;
• calitatea şi siguranţa legãturilor informaţionale, a fluxurilor
informaţionale;
• posibilitatea sistemului informaţional de a sesiza tendinţele în evoluţia
activităţii unităţii respective;
• posibilitãţile de control şi de efectuare a corecţiilor, reacţia la apariţia unor
evenimente externe, posibilităţile de corectare în timp util a abaterilor;
• gradul de integrare a sistemului informaţional, atât sub aspectul reducerii
informaţiei redundante, a compatibilităţii informaţiilor de ieşire cu cele de intrare,
a organizãrii datelor, cât şi sub aspectul asigurării unui cadru organizatoric
adecvat;
• gradul de automatizare a operaţiilor de culegere, transmitere, prelucrare şi
interogare a datelor, de valorificare intensivã a informaţiei obţinute din prelucrare,
de pregătire a personalului şi a sistemului informaţional pentru perfecţionări etc.
Evaluarea gradului de pregãtire a unitãţii economice pentru proiectarea şi
implementarea sistemului informatic presupune:
• stabilirea nivelului de pregãtire a personalului şi a experienţei dobândite în
prelucrarea automatã a datelor;
• existenţa unei discipline tehnologice;
• existenţa cadrului organizatoric adecvat;
• existenţa fondului de date necesar pentru realizarea sistemului informatic
etc.
Analiza criticã vizeazã organizarea şi funcţionarea sistemului informaţional -
decizional existent şi cautã sã identifice aspectele negative, sã surprindã cauzele
generatoare de "perturbaţii" ale sistemului şi în final să sistematizeze aspectele
negative prin gruparea lor în "puncte critice".
Un loc important în analiză îl ocupă analiza datelor şi analiza procedurilor.
Activitatea de analiză se desfăşoară iterativ. Se pot distinge, în acest sens, două
cazuri:
- Sistemul-obiect a fost deja delimitat de către beneficiar, delimitare rezultată
din anumite necesităţi ale acestuia. În acest caz analiza se desfăşoară iterativ
asupra sistemului-obiect precizat.
- Sistemul-obiect nu a fost delimitat de către beneficiar. În acest caz analiza
propriu-zisă este precedată de o analiză având scopul de a delimita aria
sistemului-obiect, care poate acoperi întregul sistem real sau părţi ale lui.
Domeniul analizat (obiectul analizei, la o iteraţie a activităţii de analiză)
poate fi deci întregul sistem-obiect sau părţi ale lui.

Observaţie:

137
 Analiza se poate desfăşura cu scopul determinării cerinţelor de informaţii la
nivelul întregului sistem informatic, caz în care se numeşte analiză de ansamblu
- sau a unor părţi (subsisteme sau domenii) ale acestuia, caz în care se numeşte
analiză de detaliu.

Activitatea de analiză se poate desfăşura, în cadrul ciclului de viaţă al

sistemelor informatice în etapele:
a. Elaborare temă de realizare sau studiu de fezabilitate :
În această etapă are scopul de a identifica sistemul-obiect, în cazul în care
delimitarea acestuia nu a fost făcută de către beneficiar şi de a stabili oportunitatea
analizei de ansamblu.
b. Elaborare proiect de ansamblu sistem informatic: constă în analiza de
ansamblu a sistemului-obiect delimitat anterior.
c. Elaborare proiecte de detaliu pe componentele sistemului informatic:
constă în analiza de detaliu, indiferent de tipul sistemului informatic.
Activitatea de analiză se realizează printr-o strânsă colaborare între
beneficiarul noului sistem şi analist, aportul beneficiarului, ca persoană care
cunoaşte direct problematica unităţii, fiind esenţial.

În cadrul activităţii de analiză, se pot identifica trei abordări în activitatea de

determinare a cerinţelor informatice, şi anume:
Abordarea pornind de la analiza deciziilor
Aceasta este o abordare care caută să obţină cerinţele de informaţii pornind de
la analiza obiectivelor şi/sau a deciziilor ce trebuie luate. Sunt culese şi raportate
doar acele informaţii care sunt necesare modelului de decizie. În această abordare,
fluxul activităţilor de identificare a cerinţelor informaţionale este :
o Identificarea obiectivelor şi/sau deciziilor curente şi potenţiale, precum şi a
atributelor conducerii corespunzătoare obiectivelor şi deciziilor.
o Identificarea sau construirea unui model de decizie (a unei proceduri de
elaborare a fiecărei decizii) sau a unui model al procesului de luare a deciziei.
o Identificarea datelor necesare luării deciziilor, pentru modelul de decizie
sau pentru cel al procesului de luare a deciziei (atât din sistemul informaţional
formal cât şi cel neformal).
o Testarea senzitivităţii modelului la acurateţea şi disponibilitatea datelor de
intrare, specificarea limitelor de acurateţe şi disponibilitate a datelor cerute de
model.
Această abordare conduce la un volum mic de date de stocat şi de
prelucrat.
Abordarea pornind de la analiza datelor
Aceasta este o abordare care caută să obţină cerinţele de informaţii prin analiza
datelor folosite curent în sistemul existent sau a datelor potenţial folosibile. Sunt
identificate datele colectate în sistemul existent, pentru care s-a perceput o
138
necesitate, precum şi datele necolectate în sistemul existent, dar semnalate ca fiind
valoroase (datele atât din sistemul informaţional formal cât şi cel neformal).
În această abordare, fluxul activităţilor de determinare a cerinţelor
informaţionale este:
o colectarea tuturor documentelor, rapoartelor, fişierelor etc. folosite în mod
curent şi identificarea datelor care sunt culese şi prelucrate în mod curent;
o identificarea datelor suplimentare, care nu sunt culese şi prelucrate în mod
curent, dar care se dovedesc a fi utile (prin interviuri, comparaţii cu alte sisteme
similare etc.);
o stabilirea inutilităţii anumitor date, pentru care nu a fost percepută (din
interviuri) nici o necesitate.
Acest mod de abordare pleacă de la premisa că toate datele utile trebuie să
facă parte din sistem, pentru a preîntâmpina schimbările ce pot apare în mediul
unităţii studiate, în stilul de decizie sau în cerinţele informaţionale ale
decidenţilor.
Din acest motiv, această abordare este cea folosită, de regulă, pentru
construirea bazei de date a sistemului. Ea conduce la un volum relativ mare de
date, dar are avantajul că deciziile care se vor lua pe baza acestor date vor fi mai
puţin afectate de modificările ce pot surveni pe parcurs.
Abordarea mixtă
Abordarea mixtă reprezintă o combinaţie între cele două abordări, care,
dacă este făcută în funcţie de specificul problemei de analizat, devine cea mai
recomandată cale de determinare a cerinţelor informaţionale. Fiecare dintre cele
două abordări „pure” este mai potrivită pentru un anumit tip de problemă:
o analiza deciziilor se recomandă în special pentru activităţile de
conducere, în cazul în care se doreşte proiectarea unui sistem care să constituie
suport pentru luarea deciziilor sau a unui sistem omomorf, mai performant decât
cel existent şi care să-l înlocuiască pe acesta.
o analiza datelor se recomandă în special pentru activităţile de rutină, în
cazul în care se doreşte proiectarea unui sistem de prelucrare a tranzacţiilor,
automatizarea unor prelucrări manuale sau proiectarea unui model al sistemului
existent.
Combinaţia între cele două abordări ar putea consta în definirea unui model de
decizie şi de prelucrare a datelor necesare în modelul de decizie, cu colectarea cel
puţin a unor date considerate utile pentru un decident care doreşte să depăşească
limitele respectivului model de decizie.

6.3.1. Tehnici de analiză

Tehnicile de analiză sunt tehnicile prin care se realizează activitatea de analiză
şi care servesc la elaborarea modelului infologic al produsului informatic.
Aceste tehnici diferă în funcţie de:

139
  etapa din ciclul de viaţă al produsului informatic în care se aplică;
 tipul de abordare folosit în determinarea cerinţelor informaţionale;
 modul de realizare a operaţiilor care compun activitatea de analiză.
Gradul de acoperire, de către tehnicile de analiză, a operaţiilor care alcătuiesc
activitatea de analiză, conduce la gruparea tehnicilor de analiză în două mari
categorii, şi anume :
A. tehnici elementare
B. tehnici complexe

A. Tehnici elementare de analiză

Aceste tehnici realizează practic numai operaţia de culegere de informaţii şi o
sistematizare redusă a acestora.
Culegerea informaţiilor este orientată spre un anumit domeniu, precizat
anterior. În acest caz problema eşantionării nu prezintă o importanţă deosebită,
deoarece se încearcă anchetarea tuturor surselor semnificative de informaţie,
numărul lor nefiind prea mare.
Sistematizarea datelor se realizează, în cadrul acestor tehnici de analiză, numai
parţial şi se concretizează în aranjarea coerentă a informaţiilor în cadrul
rapoartelor.
Din grupa tehnicilor elementare de analiză fac parte:
- observarea directă ;
- interviul ;
- chestionarul ;
- studiul documentar sau studiul documentelor din sistem, care înseamnă:
 studiul actelor normative, a reglementărilor privind organizarea şi
funcţionarea unităţii şi/sau activităţii analizate;
 studiul documentelor din sistemul de evidenţă al unităţii respective, ştiind
că acesta cuprinde evidenţa tehnico-operativă, evidenţa financiar - contabilă şi
evidenţa statistică.
 Studiul Regulamentului de Organizare şi Funcţionare, al statutului, etc.
Dintre toate aceste tehnici elementare, o importanţă deosebită în reuşita
activităţii de analiză şi o semnificaţie deosebită prin frecvenţa mare cu care sunt
utilizate, o au interviul şi chestionarul, pe care le voi prezenta mai detaliat.

B. Tehnici complexe de analiză

Aceste tehnici realizează practic analiza, prin operaţiile de culegere şi
sistematizare a informaţiilor, precum şi prin evaluarea sistemului informaţional-
decizional existent.
Culegerea informaţiilor se realizează utilizând tehnicile elementare de analiză.
Sistematizarea informaţiilor, care presupune atât reordonarea cât şi sintetizarea

140
lor, se realizează folosind una sau mai multe tehnici de reprezentare. Dintre
tehnicile de reprezentare, amintim:
- tehnica diagramelor;
- tehnica grilelor;
- tehnica tabelelor de decizie
Evaluarea sistemului informaţional decizional existent nu este de regulă pusă în
tipare, ci este lăsată mai mult pe seama puterii de analiză – sinteză a
proiectantului, a experienţei sale practice de analiză şi proiectare sisteme
informatice.
Trebuie precizat faptul că obiectul evaluării în cazul proiectării unui sistem
informatic îl reprezintă sistemul informaţional-decizional.
În completare, proiectantul poate face şi o evaluare a sistemului de conducere
şi/sau a sistemului condus, putând utiliza, în acest sens, studiul statistic al
indicatorilor tehnico-economici. Se face apel astfel la tehnica de analiză prin
indicatori şi indici.
Pentru evaluarea efectivă a sistemului informaţional-decizional, analistul va
putea calcula:
- indicatori specifici prelucrării datelor pentru domeniul studiat, cum ar fi:
volumul informaţiilor prelucrate manual (număr documente* conţinut
informaţional), costul prelucrării manuale, costul exploatării echipamentelor
existente, capacitatea echipamentului de prelucrare existent, etc;
- coeficienţi de evaluare a prelucrărilor realizate în cadrul sistemului
informaţional, cum ar putea fi coeficientul de utilizare a datelor pentru procesul de
prelucrare, coeficientul timpului de răspuns, coeficientul nivelului de
prelucrare,etc.
Trebuie precizat faptul că aceste tehnici nu dau proiectantului reţete de
evaluare a sistemului informaţional-decizional, dar precizează:
- direcţiile pe care s-ar putea face evaluarea;
- criterii de evaluare, atât a informaţiilor care circulă în sistem cât şi a
eficienţei sistemului informaţional propriu-zis.
Ca o simplă orientare, evaluarea eficienţei sistemului informaţional-decizional
se face prin compararea caracteristicilor acestuia cu necesităţile sistemului de
conducere.
Scopul principal al tehnicilor complexe de analiză este acela de a cunoaşte
sistemul informaţional-decizional existent, de a-i sesiza neajunsurile şi de a le
exprima într-o formă cuantificabilă, în măsura în care acest lucru este posibil.
Tehnicile complexe de analiză pot fi completate şi cu instrumente specializate,
de analiză asistată de calculator. Aceste tehnici sunt legate mult de analiza
economică a societăţii, căci evaluarea implică aspecte profund economice, iar
sistemul informaţional fiind un instrument al conducerii, problemele legate de
prelucrarea datelor nu pot fi desprinse de contextul economic. Astfel, dacă în
etapa elaborării temei de realizare avem de a face cu tehnici de analiză economică,
141
în proiectarea de ansamblu şi de detaliu se trece la adaptarea tehnicilor de analiză
economică la specificul activităţii de informatică, luând forma de analiză-
diagnostic sau la tehnici specializate pe analiza sistemului informaţional-
decizional, cum ar fi analiza celulară.

Din grupa tehnicilor complexe de analiză fac parte:

- analiza-diagnostic;
- analiza celulară;
- analiza concordanţei dintre intrări şi ieşiri;
- analiza prin decompoziţie funcţională;
- metoda HIPO, etc.

6.3.1.1. Interviul

Interviul este o tehnică elementară de analiză care realizează culegerea

informaţiilor despre sistemul-obiect – în general – şi despre sistemul
informaţional-decizional existent – în particular – direct de la cadrele de
conducere şi de execuţie care concură la deciziile şi la activităţile din domeniul
studiat, prin discuţii individuale purtate de către analist cu aceste cadre pe baza
întrebărilor formulate de analist.
În paralel cu desfăşurarea discuţiilor, analistul poate aduna exemple de
documente de intrare/ieşire folosite în sistemul existent, a căror studiere ulterioară
va completa informaţiile culese direct.
Interviul se poate folosi şi în combinaţie cu alte tehnici elementare de analiză,
în principal – cu studiul documentar.
Este o tehnică puţin riguroasă, care nu oferă o schemă fixă a culegerii
informaţiilor, ci doar câteva reguli utile analistului în purtarea discuţiei,
desfăşurarea efectivă a procesului de culegere a informaţiilor şi construirea
întrebărilor rămânând la latitudinea analistului. Completitudinea şi corectitudinea
informaţiilor culese depind astfel de îndemânarea şi inteligenţa analistului, de
capacitatea lui de a pune întrebări. Regulile oferite de o tehnică de culegere pot
suplini, într-o oarecare măsură, lipsa de experienţă, dar nu şi creativitatea
analistului.
Scopul interviului este de a obţine descrierea informaţională completă a unui
anumit domeniu sau problemă -delimitat anterior- precum şi a cerinţelor de
informaţii necesare elaborării deciziilor şi exercitării atributelor conducerii în
domeniul respectiv. Interviul este o tehnică de analiză folosită la realizarea
sistemelor informatice atât la nivel microeconomic, cât şi la nivel macroeconomic.
Serveşte deci, la obţinerea informaţiilor referitoare la o gamă variată de sisteme-
obiect, ceea ce dă caracterul de generalitate al tehnicii.

142
 Interviul este utilizat în analiza generală şi în cea de detaliu, deci la elaborarea
modelului infologic general şi a celui de detaliu, în etapele de Proiectare de
ansamblu a sistemului informatic şi Proiectare de detaliu.
Aria de cuprindere a interviului în sistemul-obiect este foarte variată – de la
activitatea unui post de lucru până la activitatea unei întregi unităţi economico-
sociale.

Reguli generale şi cerinţe ale aplicării interviului

• În momentul începerii interviului trebuie cunoscute:
- domeniul sau problema despre care se culeg informaţii (adică subiectul
interviului să fi fost delimitat şi chiar cunoscut, până la un anumit nivel, prin
studiu teoretic-documentar sau prin alte surse de informare);
- sursa de informaţii (persoanele potenţial anchetabile).
• Alegerea sursei de informaţii se face în funcţie de obiectul despre care se
doreşte obţinerea informaţiilor:
- pentru a obţine informaţii cu caracter general, privind activitatea de
ansamblu a unui domeniu sau politica unei unităţi, se apelează la cadre de
conducere;
- pentru informaţii de detaliu, privind activitatea unui punct de lucru, se
apelează la cadre de execuţie.
• Beneficiarul viitorului sistem informatic trebuie implicat în proiectarea lui.
Analistul nu va impune soluţii, ci va orienta discuţia astfel încât beneficiarul să-şi
definească singur sistemul cel mai eficient pentru nevoile sale.
• Informaţiile culese prin interviu trebuie verificate, pe cât posibil, prin
studiul documentelor şi actelor normative legate de problema analizată.
• Este necesară instruirea în tehnica interviului. S-a incetăţenit concepţia
falsă că a lua un interviu este un lucru uşor, pe care-l poate face oricine, după
propia sa inspiraţie. În realitate, deşi inspiraţia joacă şi ea un rol însemnat în
această tehnică – care nu oferă decât un set de reguli de ghidare a desfăşurării
interviului – este util, chiar şi pentru analişti cu oarecare experienţă, să cunoască
regulile oferite de tehnică.

Câteva reguli ale desfăşurării interviului:

a) Analistul va arăta permanent interes faţă de spusele interlocutorului său.
b) Analistul nu va introduce subiecte colaterale în discuţie şi va avea grijă ca
nici interlocutorul său să nu abordeze asemenea subiecte (fără a-l întrerupe cu
brutalitate, ci reorientând discuţia spre subiectul principal).
c) Analistul va acorda intervievatului timp de gândire, prin pauze între
întrebări.
d) Analistul nu va pune întrebări al căror răspuns să fie “DA” sau “NU”,
acestea neaducând un plus de informaţii.

143
 e) Analistul se va autochestiona (mintal), pe parcursul discuţiei, făcând astfel o
verificare a interpretării pe care o dă răspunsurilor şi o evaluare a acestora.
Autochestionarea este recomandată atât pentru a grăbi procesul de evaluare
finală, cât şi pentru a menţine atenţia asupra subiectului principal.
De asemenea se recomandă evaluarea răspunsurilor pentru a se evita
suprasaturaţia informaţională (care este la fel de dăunătoare ca şi lipsa de
informaţii). Evaluarea răspunsurilor, făcută prin autochestionare, acţionează ca
un al doilea filtru al informaţiilor recepţionate, alături de interesul creativ al
analistului.
Nu se poate da o schemă standard de evaluare a răspunsurilor primite de
analist, ci doar anumite criterii de evaluare:
- completitudinea răspunsului (“Răspunsul primit este complet?”; “A fost
omis vreun domeniu?De ce?”);
- noutatea răspunsului (“Am mai discutat acest lucru cu altcineva?” Dacă da
– “Cum corespunde acest răspuns cu cele primite deja?”);
- vârsta informaţiei primite (“Cât de recentă este informaţia?”);
- importanţa răspunsului (“Este o informaţie importantă sau este
colaterală?” – raportând la cunoştinţele prealabile referitoare la problema
analizată);
- fundamentarea răspunsului (“Ce fapte are la bază interlocutorul meu
pentru a face această afirmaţie?“);
- logica răspunsului (“Raţionamentul dezvoltat de interlocutorul meu este
logic sau nu?”).

Întocmirea raportului de analiză

Raportul de analiză reprezintă o sistematizare a notiţelor luate pe parcursul
interviului. Forma lui este narativă, iar tehnica de reprezentare folosită este
scrierea tehnică. La raportul de analiză se pot anexa mostrele de documente de
intrare/ieşire culese o dată cu desfăşurarea discuţiilor.
Raportul va conţine:
- toate întrebările puse şi sinteza răspunsurilor primite (răspunsurile evaluate
pe parcursul discuţiei);
- toate punctele neclare, cu specificarea neclarităţii. Nu e corect să se
specifice doar “nu am înţeles problema X”, ci trebuie descris în ceea ce constă
neclaritatea;
- opiniile intervievatului, separate de faptele prezentate de acesta.
Avantaje şi limite ale interviului
Avantajele interviului constau în larga lui aplicabilitate precum şi în faptul că,
nefiind o tehnică foarte riguroasă, lasă foarte multă libertate creativă analistului,
în construirea şi desfăşurarea efectivă a interviului.

144
 Interviul prezintă limitele oricărei tehnici elementare de analiză, respectiv
faptul că nu face analiza critică a sistemului informaţional-decizional.

6.3.1.2. Chestionarul

Chestionarual este o tehnică elementară de analiză împrumutată, ca şi

interviul, din practica cercetărilor sociologice.

Chestionarul este o tehnică prin care se realizează culegerea informaţiilor

prin răspunsuri date de persoanele anchetate (personalul de conducere sau de
execuţie din unitatea analizată) la întrebări formulate în scris de către analist.
Formularul de culegere, care conţine lista de întrebări, poartă acelaşi nume ca
şi tehnica -“chestionar”- şi este însoţit de o anexă conţinând instrucţiunile de
completare (“ghid de completare”). Spre deosebire de chestionarul sociologic, în
cadrul chestionarului ca tehnică de analiză pentru realizarea sistemelor
informatice nu interesează studiul fenomenelor de masă (pe baza indicatorilor
rezultaţi din prelucrări statistice ale chestionarelor), ci strict aspectul furnizării de
informaţii.
Chestionarele se pot clasifica după mai multe criterii.
După modul de administrare, chestionarele se pot clasifica în:
- chestionare autoadministrate (cu răspunsurile completate chiar de
subiecţii anchetaţi):
- chestionare poştale;
- chestionare distribuite prin operatorii de anchetă;
- chestionare apărute în publicaţii etc.
- chestionare administrate de operatori de anchetă (cu răspunsurile
completate de operatorii de anchetă – deci interviuri).
Chestionarele utilizate în activitatea de analiză efectuată pentru realizarea
sistemelor informatice fiind, după modul de administrare, de tipul celor
autoadministrate, se pot clasifica doar pe criteriile: tematică, conţinut şi formă.
Astfel, tipurile de chestionare utilizate în activitatea de analiză şi care
interesează deci un analist sunt grupate astfel:
a. După tematică:
- chestionare speciale, cu o singură temă;
- chestionare “omnibus”, cu mai multe teme, dar toate legate de domeniul
analizat.
Acestea din urmă permit surprinderea intercorelării temelor.
b. După conţinut:
- chestionare cu date factuale;

145
 - chestionare de opinie.
c. După forma întrebărilor:
- chestionare cu întrebări închise (precodificate), care presupun selectarea
unui răspuns dintr-o serie de variante de răspuns scrise tot pe formularul de
culegere, imediat după întrebare;
- chestionare cu întrebări deschise (libere).
Întrebările închise mai prezintă o serie de avantaje, cum ar fi:
• sprijină memoria celui anchetat;
• servesc drept “filtru” pentru întrebările următoare;
• sporesc senzaţia de anonimat a anchetatului, permiţându-i acestuia o mai
mare angajare în răspunsuri.
Chestionarele cu întrebări închise sunt de mai multe feluri:
- dihotomice (cu răspunsuri DA-NU);
- trihotomice (de regulă cu răspunsuri, DA, NU, NU ŞTIU);
- precodificate multiplu (cu n răspunsuri, unde n>3).
Chestionarele cu răspunsuri multiple se caracterizează prin următoarele:
- presupun cunoaşterea prealabilă, de către analist, a problemei anchetate,
pentru a oferi fie toate variantele posibile de răspuns, fie variantele de răspuns
semnificative;
- permit o nuanţare destul de bună a răspunsurilor;
- elimină tendinţa anchetaţilor – constatată experimental – de a evita în scris
răspunsurile extreme, tendinţă care se manifestă, în cazul chestionarelor
dihotomice, printr-o posibilitate crescută de apariţie a non-răspunsurilor, iar în
cazul chestionarelor trihotomice printr-o creştere nejustificată a numărului de
răspunsuri “NU ŞTIU”, ceea ce conduce la distorsionarea rezultatelor anchetei.
În consecinţă, tipul de chestionar care prezintă cele mai puţine dezavantaje este
cel cu întrebări închise, precodificate multiplu.
Obiectivele chestionarului
Chestionarul nu serveşte, în primul rând, culegerii de informaţii “noi”,
referitoare la sistemul informaţional-decizional sau la cerinţele informaţionale ale
conducerii unităţii analizate; el nu poate înlocui interviul, ca principală tehnică de
furnizare de informaţii “noi”, dar îl completează pe acesta.
Scopul chestionarului utilizat în activitatea de analiză este:
- verificarea informaţiilor, culese prin interviuri, referitoare la o anumită
problemă;
- sondarea opiniilor diferitelor categorii de beneficiari (în special ale
cadrelor de conducere) referitoare la anumite aspecte legate de prelucrarea
datelor;

146
 - detalierea informaţiilor, culese anterior prin interviuri, referitoare la o
anumită problemă (temă) bine conturată şi de dimensiuni restrânse .
Utilizarea chestionarelor este recomandată, în cazul în care obţinerea
informaţiilor nu este foarte urgentă, iar sursele de informaţii sunt greu de contactat
direct.
Limitele chestionarului, ca tehnică de analiză, constau în domeniile restrânse
la care poate fi aplicat (spre deosebire de interviu) precum şi în faptul că
presupune o cunoaştere prealabilă a domeniului sau a problemei care constituie
tema chestionarului. În acest sens, chestionarul, ca atare, reprezintă mai mult o
tehnică de verificare a acestor cunoştinţe prealabile decât o tehnică prin care să se
culeagă o cantitate însemnată de informaţii “noi”.

6.3.1.3. Analiza - diagnostic informaţională

Analiza–diagnostic informaţională constituie o adaptare a tehnicii analizei-
diagnostic – care este o tehnică de analiză economică – la studiul sistemului
informaţional-decizional, deci reprezintă un tip de analiză-diagnostic specializată.
Analiza-diagnostic, ca tehnică de anliză-diagnostic economică, este orientată
către problemele de organizare şi conducere ale unei unităţi economice şi constă
în controlarea şi evaluarea nivelului de funcţionare a sistemului de conducere şi a
celui condus, identificarea şi localizarea fenomenelor negative şi a cauzei apariţiei
lor (diagnostificarea), precum şi în elaborarea unor recomandări menite să permită
o funcţionare eficientă a sistemelor respective.
Studiul sistemului condus nu constituie un scop în sine al analizei-diagnostic,
ci este legat de studiul sistemului de conducere, deoarece un sistem de conducere
poate fi studiat:
- direct, prin analiza activităţii propriu-zisă a organelor de conducere;
- indirect, prin analiza activităţii şi a rezultatelor sistemului condus, plecând
de la premisa că acestea reprezintă reflectarea activităţii de conducere.
Se poate considera, deci, că anliza-diagnostic este alcătuită din două părţi:
- stabilirea diagnosticului (a “stării” sistemului studiat şi a “perturbaţiilor”
intervenite, care determină “starea”);
- elaborarea recomandărilor.
Analiza-diagnostic informaţională constă în cunoaşterea sistemului
informaţional-decizional şi evaluarea lui din punct de vedere al eficienţei şi al
utilităţii sale pentru sistemul de conducere.
- Ea realizează doar partea de diagnostic, în timp ce elaborarea măsurilor de
prevenire sau înlăturare a perturbaţiilor este inclusă, implicit, în proiectul noului
sistem .
Colectarea cerinţelor de informaţii în analiza-diagnostic informaţională se face
pornind de la analiza deciziilor.
Scopul analizei-diagnostic informaţionale este:
147
 - de a oferi o imagine completă a organizării şi funcţionării sistemului
informaţional-decizional existent;
- de a evidenţia defectele de funcţionare şi carenţele de organizare ale
acestui sistem;
- de a stabili cerinţele pentru realizarea sistemului informatic.
Analiza-diagnostic informaţională îşi propune stabilirea “stării” sistemului
informaţional-decizional şi a perturbaţiilor care conduc la aspecte negative.
Analiza-diagnostic informaţională, spre deosebire de analiza-diagnostic
economică, nu îşi propune elaborarea unor soluţii organizatorice menite să asigure
buna funcţionare a sistemului de conducere şi nici a unor soluţii economice care
să asigure buna funcţionare a sistemului condus. Soluţiile menite să asigure buna
funcţionare a sistemului informaţional-decizional depăşesc sfera activităţii de
analiză, intrând în cea a proiectării noului sistem, care include şi raţionalizarea
sistemului informaţional.
Analiza sistemului existent se poate realiza, în acest caz, folosind tehnicile
elementare de analiză, şi anume: studiul documentar, interviul şi chestionarul.
b. Sistematizarea informaţiilor culese.
Sistematizarea informaţiilor constă în:
- sistematizarea şi gruparea informaţiilor;
- reprezentarea grafică şi tabelară a grupelor de informaţii;
- verificarea exactităţii informaţiilor culese, prin diferite modalităţi.
Sistematizarea informaţiilor se realizează utilizând tehnicile de reprezentare:
- scrierea tehnică;
- tehnica diagramelor;
- tehnica grilelor;
- tehnica tabelelor de decizie.
c. Evaluarea sistemului existent
Evaluarea constă în:

c1). Evaluarea funcţionării sistemului informaţional-decizional existent.

În general, această evaluare se face prin prisma utilităţii sistemului informaţional-
decizional pentru sistemul de conducere. Nu se pot da tipare de evaluare a
sistemului informaţional-decizional, ci se pot indica:
• direcţii pe care se axează analiza critică;
• criterii de evaluare a informaţiilor din sistemul informaţional după modul
în care acestea răspund necesităţilor de informare ale conducerii.
Direcţiile pe care s-ar putea axa analiza critică şi evaluarea sistemului
informaţional-decizional ar putea fi:
- instrumente de conducere (de previziune şi control);
- principalele decizii luate pe diferite nivele de conducere;
- sistemul de evidenţă formal şi neformal;

148
 - organizarea sistemului informaţional, fluxul activităţilor de prelucrare a
datelor;
- modul de desfăşurare a activităţilor de prelucrare a datelor;
- fluxuri de informaţii şi circuitul suporţilor de informaţii;
- resursele utilizate pentru prelucrarea datelor(echipamente şi oameni).

Evaluarea sistemului informaţional se poate face pe baza:

- unor indicatori specifici prelucrării datelor sau referitori la sistemul de
evidenţă, cum sunt volumul informaţiilor prelucrate, capacitatea echipamentelor
utilizate, costul prelucrărilor etc.
- unor coeficienţi de evaluare a prelucrărilor efectuate în cadrul sistemului
informaţional, cum sunt coeficientul utilizării datelor, coeficientul timpului rămas,
coeficientul nivelului de prelucrare etc..
Greutatea constă în faptul că aceşti indicatori şi coeficienţi nu pot fi preluaţi
direct din evidenţele existente, ci trebuie calculaţi de către analist. Ca şi analiza
prin indicatori şi indici efectuată asupra indicatorilor tehnico-economici, cea
efectuată asupra indicatorilor specifici prelucrării datelor şi/sau referitori la
sistemul de evidenţă precum şi asupra coeficienţilor de evaluare a prelucrărilor se
poate referi fie la rezultatele anterioare, fie la perspectiva de dezvoltare (tendinţa
de evoluţie).
Criteriile de evaluare se pot referi la:
 sistemul informaţional-decizional:
• ca organizare şi funcţionare:
− gradul de organizare a sistemului (entropia);
− gradul de formalizare şi standardizare a evidenţelor şi a activităţilor de
prelucrare a datelor;
− gradul de utilizare a datelor introduse în sistem;
− existenţa circuitelor paralele în fluxul de informaţii şi existenţa unor
circuite neînchise de informaţii; gradul de paralelism şi cel de neînchidere a
circuitelor.
• ca utilitate pentru sistemul de conducere:
− gradul de concordanţă între prelucrările existente şi cele rezultate din
reglementările în vigoare;
− costul funcţionării sistemului existent;
− performanţa sistemului existent, exprimată prin viteza de răspuns,
nivelul de prelucrare;
− gradul de dificultate în introducerea datelor primare în sistemul
existent.
 informaţiile utilizate în procesul de decizie:
− volumul de informaţii în unitatea de timp considerată:
149
 − completitudinea/redundanţa informaţiilor;
− precizia;
− vârsta;
− frecvenţa de utilizare în unitatea de timp;
− gradul de agregare al informaţiilor.
c2). Stabilirea aspectelor critice ale sistemului informaţional-decizional
(analiza critică).
Analiza critică vizează atât organizarea cât şi funcţionarea sistemului
informaţional-decizional şi se efectuează încercând să dea răspuns la întrebări
cum sunt:
− metodele şi tehnicile de decizie sunt corespunzătoare obiectivelor
sistemului de conducere?
− procedurile/modelele de decizie sunt eficiente?
− procedurile de prelucrare a datelor sunt eficiente?
− care sunt cerinţele curente de informare a conducerii? Dar dificultăţile
previzibile în satisfacerea acestor cerinţe?
− informaţiile vehiculate în sistem sunt necesare şi suficiente?
Analiza critică constă în:
− relevarea aspectelor negative, legate de organizarea şi funcţionarea
sistemului informaţional-decizional, pe baza evaluării acestui sistem conform
criteriilor enunţate;
− relevarea, pe cât posibil, a cauzelor generatoare de “perturbaţii”;
− sistematizarea aspectelor negative prin gruparea lor în “puncte critice”:
• pe efecte în cadrul sistemului de conducere; Se vor evidenţia funcţiuni,
activităţi ale sistemului afectate de aspectele negative din circuitul informaţional-
decizional;
• pe probleme ; Se vor evidenţia activităţi de prelucrare a datelor
implicate în aspectele negative;
• pe locuri ; Se vor evidenţia compartimente, locuri de muncă unde s-au
constatat “perturbaţii”);
• pe urgenţe de rezolvare.
Activitatea de analiză-diagnostic informaţională se încheie practic cu o sinteză
sau raport de analiză, care cuprinde :
a. Generalităţi:
− prezentarea unităţii economice şi a obiectivelor ei;
− caracteristicile tipologice ale unităţii ;
− organizarea şi funcţionarea unităţii sau domeniului conform
reglementărilor în vigoare;
− prezentarea metodelor de organizare şi conducere folosite şi eficienţa
aplicării lor.

150
 b. Prezentarea sistemului informaţional-decizional:
− componentele sistemului şi structura lui;
− procesul de decizie şi principalele decizii, pe nivele;
− procedurile de prelucrare a datelor.
c. Analiza critică a sistemului informaţional-decizional:
− prezentarea aspectelor negative, grupate în “puncte critice”;
− prezentarea cauzelor generatoare.
d. Restricţii şi condiţii de introducere a noului sistem:
− modificările organizatorice necesitate de introducerea noului sistem;
− implicaţiile introducerii noului sistem asupra celorlalte domenii;
− componente ale sistemului organizaţional şi de conducere (compartimente,
persoane, activităţi) care se opun introducerii noului sistem;
− modul în care conducerea priveşte introducerea noului sistem.
Forma de redactare a raportului de analiză este aceeaşi ca în cazul analizei
diagnostic tehnico-economice. Avantajul analizei-diagnostic informaţionale
constă în faptul că, prin evidenţierea aspectelor negative şi gruparea lor în “puncte
critice”, facilitează şi orientează analizele din următoarele etape de realizare a
sistemului informatic. Restricţiile în aplicarea acestei tehnici sunt determinate de:
− necesitatea includerii în echipă a unor specialişti în problema sau domeniul
analizat, chiar în condiţiile în care analiştii sunt familiarizaţi cu această problemă;
− necesitatea delimitării prealabile a problemelor sau domeniilor de analizat.

6.3.1.4. Analiza celulară

Tehnica analizei celulare este o tehnică de analiză complexă, utilizată în cadrul
metodei de abordare descendentă a sistemului obiect, atât pe compartimente, cât şi
pe activităţi, care oferă informaţiile necesare:
− proiectării sistemelor informatice complexe pentru unităţi economico-
sociale, respectiv sisteme al căror număr de elemente este mare;
− raţionalizării sistemului informaţional al unităţii, respectiv reordonării
fluxului de informaţii şi standardizării evidenţelor din cadrul acestuia;
− simulării unor posibile reorganizări ale unităţii, precum şi a îndeplinirii
sarcinilor de serviciu pentru lucrătorii unităţii, după efectuarea acestor
reorganizări.
Tehnica analizei celulare este deci o tehnică de abordare de tip top-down a
sistemului-obiect. Utilizează ambele concepte de structurare – şi cel orientat pe
organism şi cel orientat pe activitate, analiza efectuându-se în trei trepte:
− treapta I - tratează structura organizatorică a întregului sistem studiat;
− treapta a II-a - tratează structura funcţională a sistemului şi/sau a
subsistemelor componente;

151
 − treapta a III-a - efectuează analiza informaţiilor vehiculate în sistem,
informaţii care constituie legătura între cele două structuri.
Tehnica analizei celulare foloseşte abordarea pornind de la analiza datelor în
determinarea cerinţelor de informaţii: pe fiecare nivel de descompunere a
sistemului-obiect, obţinut prin metoda top-down, sunt culese şi analizate toate
datele vehiculate în sistem.
Scopul utilizării tehnicii este obţinerea unor imagini analitice descriptive,
detaliate ale sistemului-obiect, în general, şi al sistemului informaţional-
decizional, în special, atât ca organizare cât şi ca funcţionare.
Conceptele folosite de tehnica analizei celulare sunt cele ale Teoriei Generale a
Sistemelor şi ale Teoriei Analizei Celulare, şi anume:
a. Sistemul de conducere este considerat un sistem cibernetic, alcătuit din
elemente legate atât între ele cât şi cu mediul. Fiecare element, la rândul său,
poate fi considerat un sistem care se poate analiza independent şi, deci,
descompune în elemente. Fiecărui element i se poate asocia o structură celulară.
Elementul de bază al unei asemenea structuri este celula, adică elementul
component de pe ultimul nivel de agregare, care nu se mai poate divide (sau a
cărui divizare nu mai prezintă interes).
O celulă este descrisă prin: - intrările (X);
- ieşirile (Y);
- operatorul (T).
Intrările celulei suferă o serie de transformări devenind ieşirile celulei.
Conceptele de structurare folosite sunt:
−conceptul orientat pe organism, care foloseşte, pentru descrierea structurii
organizatorice, descompunerea: Unitate – Subunitate –Compartiment - Post;
−conceptul orientat pe activitate, care foloseşte, pentru descrierea structurii
funcţionale, descompunerea: Funcţie – Activitate – Sarcină - Procedură.
• Funcţia se realizează prin una sau mai multe activităţi omogene.
• Fiecare activitate se conduce sau se execută prin sarcini.
• Sarcinile sunt un grup de proceduri de acelaşi fel: previziune, organizare,
dirijare, execuţie, control.
• Procedura este un complex de operaţii elementare care comportă luarea
unei decizii, efectuarea unui control, etc.
b. Problema procesului de conducere fiind considerată a fi cea a
deciziilor şi a comunicaţiilor, pentru modelarea acestora tehnica analizei celulare
utilizează terminologia din Teoria Informaţiilor, respectiv conceptele: emiţător,
receptor, canal, mesaj, suport de informaţii.
Descrierea sistemului este făcută iterativ pe principiul descompunerii top-
down, în următoarele etape:

152
  delimitarea sistemului analizat, care poate fi întreaga unitate sau un
domeniu al ei, în funcţie de etapa de realizare a sistemului informatic în care se
efectuează analiza;
 stabilirea structurii sistemului studiat: structura organizatorică şi
funcţională;
 stabilirea intrărilor, ieşirilor şi transformărilor succesive ale intrărilor şi
ieşirilor la nivelul subsistemelor.
Paşii de realizare a tehnicii corespund operaţiilor care compun activitatea de
analiză.
 Culegerea datelor
Sunt culese date referitoare la:
− structura organizatorică şi cea funcţională, pe componente;
− restricţii faţă de funcţionarea sistemului, prevăzute în acte normative;
− relaţiile între elementele organizatorice şi funcţionale;
− informaţiile de intrare/ieşire utilizate sau generate de proceduri, cu
atributele lor, cum sunt :volum, frecvenţă, etc.;
− suporţii informaţiilor vehiculate (documente, evidenţe, tabele, constatări,
vizuale, informări verbale şi telefonice) generate de elementele de structură
organizatorică (compartimente) şi de elementele de structură funcţională
(proceduri de lucru).
Culegerea datelor se face pe formulare speciale completate în mod asemănător
chestionarelor de către beneficiarii viitorului sistem informatic.
 Sistematizarea informaţiilor
Constă în:
a. Sistematizarea informaţiilor, obţinând cataloage ale:
− elementelor de structură organizatorică şi funcţională;
− restricţiilor;
− procedurilor;
− informaţiilor;
− suporţilor de informaţii.
b. Ordonarea informaţiilor culese:
b.1. – gruparea procedurilor:
• pe elemente de structură (compartiment şi tip sarcină);
• după frecvenţa executării lor;
• după volumul de muncă necesară.
b.2. – stabilirea unor relaţii între informaţiile din sistem:
• corespondenţa restricţii-proceduri;
• corespondenţa informaţii-suporţi;
• corespondenţa între elementele funcţionale şi cele organizatorice (legătura
proceduri-posturi), incluzând şi legăturile informaţionale între aceste elemente

153
 b.3. – descrierea canalelor de comunicaţie ale sistemului:
• intrările şi ieşirile procedurilor;
• circuitele de informaţii;
• încărcarea canalelor la intrare şi la ieşire.
 Evaluarea sistemului informaţional-decizional
Diagnosticarea sistemului existent constă în evidenţierea următoarelor:
- paralelisme în prelucrări;
- sarcini neconcretizate în proceduri;
- informaţii neutilizate de proceduri.
Această evidenţiere se realizează analizând:
- gradul de încărcare cu activităţi a compartimentelor;
- frecvenţa de executare a activităţilor;
- circuitul informaţional şi al suporţilor (documentelor);
• utilizarea informaţiilor;
• gradul de încărcare al canalelor de comunicaţie;
• paralelisme şi redundanţe.
Rezultatul aplicării tehnicii constă în imaginile descriptive ale sistemului-
obiect. Acestea constituie o bază pentru raţionalizarea sistemului informaţional
prin reproiectarea evidenţei şi eliminarea paralelismelor, depistarea procedurilor
care ar trebui automatizate, datorită volumului mare de muncă necesitat şi al
frecvenţei mare de execuţie.
Tehnica analizei celulare oferă o imagine completă şi foarte detaliată a
sistemului-obiect, ceea ce constituie un mare avantaj, în special în cazul
sistemelor complexe, de dimensiuni mari şi foarte mari, pentru care ar fi foarte
greu de obţinut o descriere la fel de detaliată fără ajutorul unui instrument de
analiză asistată de calculator. În schimb, tehnica analizei celulare, atunci când se
aplică în etapa de elaborare a proiectului tehnic este o tehnică laborioasă şi
necesită multă răbdare pentru completarea corectă şi completă a formularelor de
culegere specifice.

6.3.2. Tehnici de analiză ce pot fi utilizate în etapa de proiectare

Analiza este o activitate distribuită, cu diferite ponderi pe parcursul întregului

ciclu de realizare a sistemului informatic şi, ca urmare, o serie de tehnici ale
analizei pot fi aplicate, de la caz la caz, în diferite etape.
Analiza şi apoi proiectarea sunt văzute ca activităţi care implică o serie de
operaţii cum sunt: abstractizarea, elaborarea, operaţionalizarea, verificarea. În
aceste condiţii au fost elaborate o multitudine de metode şi tehnici de analiză şi
proiectare, care încearcă să ghideze efortul proiectanţilor şi totodată să micşoreze
dependenţa soluţiilor de inspiraţia şi talentul individual al acestora.

154
 Aceste metode şi tehnici pun accentul pe unul sau altul din aspectele relevate
din punctul de vedere al proiectantului, cum sunt:
• aspectul procedural
• fluxurile de control
• ierarhia funcţională
• structura datelor
• modificările de stare ale sistemului
• independenţa modulelor.

6.3.2.1. Analiza structurată prin decompoziţie funcţională

Una din actualele abordări în proiectarea de sisteme informatice este şi
proiectarea structurată.
Proiectarea structurată poate fi definită ca arta de a proiecta
componentele unui sistem şi relaţiile sau legăturile dintre aceste componente într-
o manieră cât mai bună, în condiţiile în care cerinţele funcţionale ale sistemului
au fost bine definite.
Proiectarea structurată constă într-un set de concepte, tehnici şi
instrumente care-l ajută pe proiectant să subdividă sistemul în module relativ
independente din punct de vedere funcţional, uşor de realizat şi întreţinut.
Modulul se caracterizează prin funcţie, logică şi relaţii (interfeţe) cu alte module.
Funcţia descrie transformările care se produc când modulul este apelat; ea este o
descriere a „exteriorului” modulului, în timp ce logica modulului este o descriere
a „interiorului” său.
Proiectarea structurată se referă la funcţia modulului, nu la logica sa.
Prin proiectarea structurată se determină caracteristicile majore ale sistemului,
limitele şi performanţele, calităţile pe care cea mai bună implementare a soluţiei le
poate atinge şi eventual costul final al sistemului.
Structurabilitatea este deci o caracteristică atât a produsului (rezultatul
proiectării) cât şi a procesului prin care s-a realizat proiectarea.

Proiectarea structurată are ca obiectiv crearea într-un mod structurat a unor

sisteme informatice, atât prin parcurgerea unui proces de proiectare structurat
cât şi prin crearea unui produs structurat. Ea înglobează la ora actuală o
multitudine de concepte, tehnici şi instrumente care au la bază următoarele
abordări:
- decompoziţie funcţională;
- decompoziţie prin date;
- decompoziţie hibridă (combinarea alternativă a primelor două abordări).

155
 Activitatea de proiectare integrează, de regulă, una sau mai multe din
următoarele operaţii1:
- analiză: divizarea sistemului în elemente componente, determinarea
caracteristicilor acestor elemente şi implicit ale sistemului;
- sinteză: agregarea acestor elemente, dintr-o colecţie de componente posibile
ale sistemului, care permit realizarea caracteristicilor cerute sistemului;
- operaţionalizarea: realizarea unui sistem care funcţionează fără erori, iar
informaţiile pe care le furnizează sunt utile din punctul de vedere al conţinutului şi
momentului de apariţie;
- abstractizarea: înlăturarea detaliilor nesemnificative şi extragerea
caracteristicilor esenţiale ca ceva general pentru toate elementele componente
luate în consideraţie. Principala funcţie a abstractizării este reducerea
complexităţii;
- elaborarea: divizarea unei entităţi în părţile sale componente prin punerea în
evidenţă a elementelor de detaliu;
- reprezentarea: transpunerea proiectării într-o formă inteligibilă, explicită şi
modificabilă;
- iterarea: corectarea continuă a unei soluţii (proiect) prin reproiectări
intermediare până când se ajunge la o soluţie finală acceptată;
- evaluarea: verificarea corectitudinii soluţiei în raport cu anumite criterii
(specificaţii, standarde, normative).
Din mulţimea tehnicilor de proiectare structurată, în continuare va fi prezentată
tehnica de proiectare structurată prin decompoziţie funcţională.
Tehnica constă din utilizarea unor principii de analiză pentru proiectarea
soluţiei, a unei scheme pentru reprezentarea grafică a structurii funcţionale, a unei
tabele de intrare/ieşire pentru reprezentarea fluxului de date şi unei modalităţi de
evaluare a soluţiei. Tehnica poate fi denumită şi „tehnica Chapin”, după numele
celui care a elaborat-o în cadrul Institutului de Tehnologie din Illinois.
Diferitele tehnici de proiectare structurată implică stiluri diferite de proiectare.
Pentru crearea unui sistem informatic viabil structura sa funcţională trebuie să
reflecte carateristicile funcţionale ale sistemului obiect. Duratele şi deci costurile
de implementare a proiectului, întreţinere şi modificare, în general, pot fi
minimizate când fiecare componentă mică a sistemului proiectat corespunde exact
unei componente mici bine definite din sistemul obiect, iar fiecare legătură dintre
componentele sistemului proiectat corespunde numai unei legături dintre
componentele sistemului obiect.
Utilizând abordarea prin decompoziţie funcţională, tehnica are în vedere
următoarele scopuri:
- realizarea unui proces de proiectare structurat;
- realizarea unui produs structurat care să se caracterizeze prin:
1
După unii autori (Naugton, Marker, Freeman, Thomas) aceste operaţii îşi propun să realizeze
anumite scopuri care sunt specificate în dreptul fiecăreia.
156
 • grad înalt de modularitate;
• ierarhizare funcţională;
• depanare uşoară în caz de eroare;
• adaptare la resurse specifice şi la cerinţe utilizator noi;
• întreţinere uşoară.
Tehnica de proiectare structurată prin decompoziţie funcţională poate fi
utilizată în activitatea de analiză şi proiectare din următoarele etape ale ciclului
de viaţă ale unui sistem informatic: proiectare de ansamblu, proiectare de detaliu
şi elaborare programe.
Dacă la un moment dat, se trage concluzia că este necesară revizuirea
structurii, fluxul de proiectare se reia. Fluxul de proiectare generat prin utilizarea
acestei tehnici implică înlănţuirea operaţiilor de proiectare astfel: analiză,
abstractizare, sinteză, elaborare, operaţionalizare, reprezentare, evaluare, iterare.

Caracteristici:
Tehnica este orientată pe funcţiuni şi abordarea top-down.
Datorită acestor caracteristici, tehnica implică un proces de analiză
decompoziţională. În procesul de analiză se examinează funcţia supusă analizei –
pentru identificarea unor subfunţii specifice a căror „sumă funcţională” să fie
echivalentă cu funcţia dată. Procesul de analiză poate fi descris astfel:
 Stabilirea funcţiei de analizat.
 Detalierea funcţiei prin analiză: funcţiile obţinute sunt toate părţi ale
funcţiei iniţiale.
 Reprezentarea rezultatului analizei, într-o formă grafică adecvată.
Procesul continuă, rezultând astfel o ierarhie funcţională care are pe ultimul
nivel al descompunerii funcţii care nu mai necesită o descompunere din punct de
vedere funcţional, numite funcţii terminale. În acelaşi timp, procesul de
proiectare este un proces de sinteză, deoarece componentele funcţionale (funcţiile
specifice) nu există apriori, ci proiectantul le creează pe parcursul procesului.
Procesul de proiectare începe întotdeauna cu o funcţie care caracterizează
sistemul sau cu mai multe, care pot fi însă tratate independent păstrând totuşi
legăturile dintre ele, dacă acestea există. Fiecare funcţie care se creează prin
procesul de analiză a funcţiei inţiale devine, la rândul ei, o funcţie de analizat,
reprezentând punctul de plecare pentru următorul nivel al procesului.

Principii de analiză

În literatura de specialitate sunt formulate o serie de principii care trebuie să

stea la baza activităţii de analiză, şi anume1:

1
I. Trandafir, R. Hrin, O. Iotici,V.Hărăbor,G Manolescu, C.Morandini, AMC 41,1984, pag 181
157
 1. Analiza trebuie să conducă la identificarea unei secvenţe liniare de
execuţie a funcţiilor.
În raport cu o funcţie, datele pot fi de intrare, asupra cărora acţionează funcţia,
sau de ieşire, care rezultă în urma transformărilor exercitate de funcţia respectivă
asupra datelor de intrare.
Prin aplicarea acestui principiu se creează subfuncţii care depind succesiv una
de alta. Intrările unei subfuncţii trebuie să fie ieşiri ale altei funcţii.
2. Analiza trebuie să conducă la selectarea funcţiilor alternative.
Funcţiile alternative dau sistemelor complexitate şi adaptabilitate. Inexistenţa
unor asemenea funcţii fac sistemele şi programele rigide.
3. Analiza trebuie să conducă la identificarea funcţiilor interactive.
4. Analiza trebuie să conducă la o delimitare precisă a intrărilor,
transformărilor şi ieşirilor.
Principiul permite identificarea funcţiilor distincte. Două funcţii sunt
considerate distincte dacă au intrări diferite şi ieşiri diferite. Sunt identificate
funcţiile care procură datele de intrare, cele care furnizează datele de ieşire,
precum şi cele care realizează transformarea datelor de intrare în date de ieşire.
Nu întotdeauna este necesară existenţa simultană a celor trei tipuri de funcţii.
Aplicarea acestui principiu imprimă claritate şi eleganţă soluţiei de proiectare.
5. Analiza trebuie să conducă la plasarea funcţiilor de acţiune într-o
poziţie subordonată funcţiilor de decizie care le afectează.
O funcţie de decizie este o funcţie care determină ce funcţii trebuie să fie
executate şi în ce succesiune în timp.
O funcţie de acţiune este o funcţie care introduce sau extrage, transformă sau
comunică date.
Efectul acestui principiu este concentrarea funcţiilor de decizie în partea
superioară a structurii funcţionale, iar în partea inferioară concentrarea funcţiilor
de intrare, a celor de ieşire şi a celor care execută transformări.
Funcţiile de pe nivelele inferioare trimit date „în sus”, în structura funcţională,
către funcţiile de decizie, în care unele din date au rol de control şi declanşare a
execuţiei funcţiilor de pe nivelele inferioare.
6. Analiza trebuie să conducă la izolare, ca subfuncţii specifice, a acelor
subfuncţii a căror realizare este condiţionată de o decizie ulterioară de
proiectare.
Prin „decizie ulterioară de proiectare” se înţelege existenţa mai multor
alternative de soluţii referitoare la tipul de echipamente şi configuraţii utilizate,
sistemul de operare disponibil, formatul intrărilor şi ieşirilor dorit de utilizator,
algoritmii selectaţi etc. Aceste alternative decurg de obicei din incertitudinea
tipului şi cantităţii de resurse avute la dispoziţie în momentul proiectării.
7. Analiza trebuie să conducă la minimizarea transferului de date dintre
funcţii prin prevederea de funcţii specifice pentru modificarea distanţei datelor.

158
 Comunicarea între funcţii necesită resurse - de timp, de hard şi de soft - şi
presupune existenţa datelor pentru realizarea ei în sistem. Tabela de concordanţă
intrări / ieşiri reprezintă o modalitate bună pentru aplicarea acestui principiu.
8. Analiza trebuie să conducă la prevederea unui singur punct de intrare şi
a unui singur punct de ieşire pentru fiecare funcţie.
9. Analiza trebuie să se desfăşoare în mod exhaustiv numai după
considerente funcţionale, astfel că, nivel cu nivel, trebuie să se definească
subfuncţii omogene din punct de vedere al gradului de abstractizare.
Prin abstractizare în acest context se înţelege o grupare a unor date pe baza
unor caracteristici comune. Întrebările care se pun la aplicarea acestui principiu
sunt:
• Ce trebuie să aibă comun funcţiile pentru a putea fi grupate pe nivelele
superioare?
• După ce criterii se descompun pe nivelele următoare?
Funcţiile de pe nivelele superioare au un grad înalt de generalitate
(abstractizare) sau, altfel spus, un grad relativ mare de imprecizie, fiind lipsite de
atribute de specificitate. Funcţiile de acest gen trebuie analizate şi descompuse în
subfuncţii pe nivelele inferioare ale structurii.
Subfuncţiile astfel definite trebuie să aibă un grad relativ omogen de
abstractizare (generalitate) care să fie însă mai mic decât cel al funcţiei de pe
nivelul imediat superior. Această decompoziţie continuă nivel cu nivel, până la
identificarea unor subfuncţii terminale, procesul de decompoziţie terminându-se
atunci când se consideră că funcţia iniţială de la care s-a pornit este complet
descrisă.
În concluzie, analiza unei funcţii date în contextul acestei tehnici este un
proces de decompoziţie funcţională, în care trecerea de la un anumit nivel la cel
inferior lui se face prin utilizarea principiilor prezentate.
Analiza prin decompoziţie funcţională presupune multă inventivitate, se
bazează pe o experienţă acumulată în timp. Ea constituie o latură sintetică şi
creativă în proiectarea structurată. Pentru reprezentarea structurii funcţionale se
poate utiliza fie arborele de structură, fie schema Chapin. Pentru reprezentarea
fluxului de date între module se utilizează tabela concordanţei intrări / ieşiri.
Proiectantul construieşte o tabelă de intrare/ieşire pentru un anumit modul,
numai după ce au fost analizate toate funcţiile subordonate funcţiei reprezentate
prin acel modul. Tabela de intrare/ieşire are forma de “T”. În partea stângă se
reprezintă intrările în modul, iar în partea dreaptă ieşirile din modul. Numărul de
intrări poate fi mai mare, mai mic, egal cu numărul de ieşiri sau poate fi zero.
Datele de intrare şi respectiv datele de ieşire sunt reprezentate în coloanele
corespunzătoare ale tabelei de intrare/ieşire prin numele de identificare, sub formă
de listă, fără o ordine prestabilită.

159
 Datele, ca mijloc de realizare a legăturilor dintre modulele structurii
funcţionale, pot avea unul din următoarele roluri în raport cu un anumit modul
analizat:
• Control (C) - realizează selectarea funcţiilor care se execută;
• Prelucrare(P) - participă la prelucrări sau la crearea unei date de ieşire
dorită;
• Transfer(T) - trec prin modul fără să-şi schimbe identitatea şi valoarea;
data este transmisă între două module prin modulul care este analizat;
• Modificată(M)- reprezintă rezultatul funcţiilor de prelucrare din modul;
poate fi o modificare fie din punct de vedere al indentităţii, fie din punct de
vedere al valorii.
Dacă pentru un modul nici una din date nu este de tip C, P sau M, atunci este
posibil ca modulul să nu aibă o funcţie utilă şi ar trebui eliminat. Excepţie poate să
facă numai modulul rădăcină.
Avantajele utilizarii tehnicii prezentate sunt următoarele:
- nu este exclusă creativitatea în procesul de proiectare:
- specificarea clară a funcţiilor:
- comunicarea explicită a concepţiei proiectantului relativă la funcţiile
reprezentate, în vederea implementării şi întreţinerii lor ;
- face posibilă reprezentarea clară, concisă, neambiguă a proiectării;
- permite crearea unui produs operaţional cu caracteristicile corespunzătoare;
Tehnica prezintă limite legate de faptul că nu dă nici o indicaţie relativă la
modul de structurare a datelor, ea punând accent numai pe fluxul datelor.
Această metodă de determinare a informaţiilor de intrare pe baza celor de ieşire
este foarte utilă îndeosebi în cazul sistemelor complexe care vehiculează multe
informaţii. Este uşor de aplicat şi totodatã permite nu numai identificarea
informaţiilor de intrare, ci şi a procedurilor sau operaţiilor din aceste proceduri.
Totodatã ea permite gruparea informaţiilor şi eliminarea celor redundante.
Abordarea analizei poate fi fãcutã şi plecând de la intrãri şi ajungând la ieşirile
sistemului informaţional. Acest mod de abordare presupune identificarea tuturor
informaţiilor primare din sistem şi a legăturilor logice dintre ele. Cunoscând
intrările sistemului se pot identifica diverse tipuri de informaţii de ieşire necesare
fundamentării deciziilor. Această abordare are dezavantajul că nu permite punerea
în evidenţă a tuturor legãturilor dintre datele primare existente în sistem, fapt care
genereazã la un moment dat neajunsul cã nu se pot obţine anumite date de ieşire.

6.3.2.2. Tehnica tabelelor de decizie

Tehnica tabelelor de decizie pleacã de la conceptul de tabelã de decizie. O

tabelã de decizie este o tabelă bidimensională cu dublã intrare. În funcţie de

160
valorile logice ale condiţiilor (intrãri –conditii ) şi de valorile booleene ale
acţiunilor (intrări – acţiuni), tabelele de decizie se clasificã în:
 tabele de decizie cu intrãri limitate;
 tabele de decizie cu intrãri extinse;
 tabele de decizie cu intrãri mixte.
În funcţie de tipul relaţiilor ce pot exista între diferite tabele diferenţiem:
 tabele de decizie deschise;
 tabele de decizie închise.
De cele mai multe ori, o problemã nu poate fi reprezentatã într-o singurã tabelã
din cauza numãrului mare de reguli, condiţii şi acţiuni. În acest caz, dacă este
posibil, problema se împarte în mai multe subprobleme ce pot fi reprezentate
separat prin câte o tabelă de decizie, legate apoi prin instrucţiuni.
Grila informaţională sau de decizie reflectă o problemă şi conţine informaţiile
de intrare, informaţiile de ieşire precum şi modul de obţinere a informaţiilor de
ieşire din cele de intrare
Aceastã grilã oferã posibilitatea gãsirii unei grupe de condiţii şi acţiuni ale unui
proces de decizie care să aibă o slabã legăturã între ele. Ea nu implicã neapărat
descrierea precisă a intrărilor, ci doar marcheazã dacã existã o legăturã logicã
între acţiuni şi condiţii. Construirea grilei se face în etapa de analiză a problemei
informaţionale. În urmãtoarea etapã se face analiza grilei informaţionale cu scopul
descompunerii şi transformării acesteia în tabele de decizie.
Grila informaţionalã este utilã deoarece prezintã:
 logica luãrii deciziilor într-o formã mai compactã;
 relaţia directă între fiecare acţiune şi fiecare condiţie

6.4. Sistematizarea informaţiilor culese

Pentru sistematizarea informaţiilor în urma studiului şi analizei sistemului

existent se utilizează aşa-numitele tehnici de reprezentare. De fapt, ele pot fi
utilizate în toate etapele de realizare a sistemelor informatice. Dintre aceste
tehnici, cele mai utilizate sunt :
 scheme organizatorice;
 scheme de sistem;
 scheme logice;
 scheme de prelucrare;

Schemele organizatorice (organigrame) reprezintã structura organizatoricã,

funcţionalã a unei unitãţi economice. Printr-o asemenea organigramã se pun în
evidenţã nivelele de conducere, serviciile funcţionale sau secţiile productive şi
modul de subordonare a acestora. Pot fi puse în evidenţã, de asemenea, tipurile de

161
decizii la nivelul fiecãrui factor de decizie. În cazul unei aplicaţii informatice
poate fi delimitatã structura organizatorică pe care este grefată aplicaţia
informatică.

Prin schemele de sistem se descriu purtătorii de informaţii, legătura dintre ei,

fluxul circulaţiei informaţiei între purtători. Schemele de sistem se utilizeazã în
etapa de analizã, concepere, proiectare tehnică, elaborarea programelor. Prin
intermediul lor se pun în evidenţă intrările, ieşirile şi prelucrările, fără a intra în
detaliu.
Procedura de prelucrare poate fi detaliată ulterior. Ele constituie o parte
componentã a documentaţiei sistemelor informatice. Se pot utiliza şi pentru a
pune în evidenţã intrările, ieşirile pentru o aplicaţie informatică.

Schemele logice descriu, cu un înalt grad de detaliere, algoritmul de rezolvare

a unei probleme; ele constituie un mod grafic, convenţional de reprezentare al
unui algoritm. O alternativã a utilizãrii schemelor logice clasice este utilizarea
diagramelor de structurã sau a altor forme echivalente.

Schemele de prelucrare (diagramele globale de flux) descriu prelucrările în

cadrul unui sistem informaţional sau informatic. Sunt larg utilizate datorită
simplităţii convenţiilor de reprezentare şi vizualizare a structurii şi funcţionării
sistemului. Ele constituie un mod eficient de comunicare între spoecialiştii din
domenii de activitate diferite. Reprezintă un instrument al cunoaşterii ansamblului
activităţilor desfăşurate în sistem. Pentru aspecte de detaliu privind circuitul
informaţional ele sunt insuficiente în reflectarea legăturilor informaţionale.

6.5. Evaluarea sistemului existent. Definirea direcţiilor de perfecţionare a

actualului sistem

Pe baza activitãţilor de evaluare şi analizã criticã se identificã neajunsurile

actualului sistem şi se propun soluţii de înlãturare a acestora, se formuleazã
variante de soluţii, iar în cadrul acestora se definesc cerinţele şi restricţiile de
realizare a sistemului informatic.

Definirea direcţiilor de perfecţionare presupune:

• specificarea obiectivelor şi a performanţelor sistemului informatic;
• stabilirea domeniilor de probleme şi a principalelor funcţiuni ale
sistemului informatic;
• definirea cerinţelor şi restricţiilor informaţionale pe domenii de probleme
şi funcţiuni care constã în:
- definirea principalelor intrãri/ ieşiri;
162
 - definirea soluţiei de organizare a datelor;
- definirea variantelor tehnologice de prelucrare;
- definirea restricţiilor informaţionale şi de control.

• formularea condiţiilor pentru realizarea sistemului informatic, care constã

în:
- specificarea termenelor şi duratelor solicitate;
- precizarea prioritãţilor în realizarea obiectivelor sistemului informatic;
- specificarea cerinţelor speciale privind flexibilitatea, compatibilitatea cu alte
sisteme, gradul de generalizare al sistemului.

Pentru fiecare variantã de soluţie informaticã se procedeazã la:

- evaluarea resurselor necesare (costurile de sistem);
- evaluarea efectelor economice directe şi indirecte;
- calculul indicatorilor de eficienţã economicã.

• avizarea şi alegerea variantei de sistem de cãtre beneficiar pe baza

indicatorilor de eficienţã economicã.

163
 7. PROIECTAREA DE ANSAMBLU A SISTEMELOR INFORMATICE
7.1. Prezentare generală

Proiectarea de ansamblu este o activitate distinctă în proiectarea unor sisteme

informatice sau aplicaţii complexe, care au structuri complexe, în care se pot
identifica subsisteme pe mai multe nivele. În această etapă se realizează practic
analiza globală şi specificarea cerinţelor noului sistem, modelul de ansamblu al
sistemului informatic, structurarea datelor şi specificarea soluţiilor de
administrare a datelor, proiectarea arhitecturii configuraţiei de echipamente şi
planificarea realizării noului sistem pe părţi componente.
Această proiectare la nivel global este urmată, în astfel de cazuri, de o
proiectare de detaliu a fiecărei componente în parte, cu cele două forme ale
sale : proiectare logică de detaliu şi proiectare tehnică de detaliu.
Dacă este vorba deci de realizarea unei aplicaţii în cadrul unui sistem existent
sau de realizarea unui produs program punctual, nu mai este necesară o proiectare
de ansamblu, ci se trece direct la proiectarea de detaliu.
Proiectarea de ansamblu, denumită şi etapa de concepere a sistemului
informatic, cuprinde o succesiune de activităţi, cum sunt: definirea obiectivelor
sistemului; structurarea sistemului informatic pe subsisteme şi componente;
definirea globală a ieşirilor; definirea globală a intrărilor; definirea colecţiilor de
date comune; alegerea soluţiilor tehnice; estimarea necesarului de resurse;
estimarea eficienţei economice; planificarea realizării sistemului; elaborarea
documentaţiei corespunzătoare.
În cadrul acestei etape se impune ca sistemele informatice proiectate să
îndeplinească o serie de cerinţe, cum sunt:
• Să conţină ca element central o bază de date în care sunt stocate date
intercorelate, provenind atât din surse interne cât şi externe, necesare conducerii
pentru fundamentarea deciziilor. Acestea pot fi atât date cu caracter normativ cât
şi date privind starea sistemului condus. Utlizarea bazei de date ca fond centralizat
de date nu exclude posibilitatea existenţei şi altor fişiere specifice unor aplicaţii
din cadrul sistemului;
• Informaţiile furnizate de sistem să fie corecte, autentice, exacte. Suportul
de prezentare, formatul şi gradul de sintetizare / agregare al datelor diferă de la un
nivel de conducere la altul, funcţie de cerinţele de informare ale fiecăruia ;
• Sistemul trebuie să asigure prelucrarea şi transmiterea informaţiilor la
conducere în timp util, adică informaţiile furnizate să fie operative ;
• Să înglobeze în procedurile de prelucrare a datelor modele matematice,
tehnico-economice şi statistice adecvate, în vederea unei fundamentări ştiinţifice a
informaţiilor oferite conducerii;
• Să fie conceput ca un sistem om-maşină care să ofere posibilitatea
interacţiunii imediate dintre utilizator şi sistem. Acest lucru se impune cu atât mai

164
mult cu cât decidentul uman este plasat mai sus în ierarhia conducerii, iar
distribuirea sarcinilor între om şi maşină derivă din capacităţile şi limitele
utilizatorului;
• Sistemul trebuie să prezinte un grad cât mai mare de integrare sub
următoarele aspecte: integrare internă prin asigurarea legăturilor dintre modulele
funcţionale ale sistemului şi integrare externă prin asigurarea legăturilor cu alte
sisteme atât pe orizontală cât şi pe verticală.
• Sistemul trebuie să aibă flexibilitate maximă, adică să fie uşor adaptat sau
modificat în cazul unor noi cerinţe ale sistemului de conducere. Pentru realizarea
unor sisteme informatice care să întrunească asemenea caracteristici este necesar
să ţinem seama de o serie de cerinţe încă din etapa de concepere, cum sunt:
- Conceperea sistemului informatic să fie fundamentată pe criterii de
eficienţă economică. Acesta presupune compararea cheltuielolor estimate ca
necesare pentru realizarea şi funcţionarea sistemului (proiectare, implementare,
exploatare şi dezvoltare) cu efectele economice directe şi indirecte ce se vor
obţine prin introducerea noului sistem informatic sau aplicaţie informatică. În
acest sens se va urmări ca termenul de recuperare al cheltuielilor să fie cât mai
scurt.
- Participarea nemijlocită a conducerii unităţii la conceperea sistemului
informatic, prin formularea cerinţelor informaţionale, prin definirea şi ierarhizarea
obiectivelor acestuia, prin stabilirea programului de realizare eşalonată a acestuia,
pe elemente componente.
- Asigurarea unui nivel tehnic înalt al soluţiilor adoptate. Proiectanţii au ca
sarcină utilizarea celor mai moderne şi adecvate metode, tehnici, instrumente,
soluţii tipizate şi tehnologii informatice în vederea creşterii calităţii produselor
informatice.
- Adoptarea unor soluţii de proiectare în concordanţă cu resursele disponibile
şi cu restricţiile impuse în legătură cu: echipamentele de calcul, programele,
personalul de specialitate, resursele financiare şi de timp etc.

7.2. Definirea obiectivelor sistemului informatic şi a ariei de cuprindere a

acestuia

Aria de cuprindere a sistemului informatic se stabileşte în strânsă legătură cu

obiectivele definite pentru acesta. Aceste obiective nu vor fi identice pentru toate
societăţile beneficiare, căci ele vor fi definite în urma unei analize complexe a
stării şi comportamentului sistemului economic respectiv, efectuată împreună cu
conducerea unităţii de la toate nivelele ierarhice.
O asemenea analiză globală a sistemului se efectuează pentru a cunoaşte:
evoluţia situaţiei economice şi financiare a unităţii, reflectate prin indicatori
sintetici; eficacitatea cu care sunt utilizate resursele financiare; eficienţa

165
economică a utilizării mijloacelor fixe; rentabilitatea produselor şi serviciilor, etc.
În urma acestei activităţi de documentare şi analiză critică se vor fi identifica
"punctele slabe" ale sistemului, eventualele rezerve interne, eventualele necorelări
şi contradicţii care ar putea fi eliminate sau diminuate prin introducerea noului
sistem informatic. Pe baza acestor constatări se formulează obiectivele sistemului
informatic ce se va proiecta, se identifică sarcinile ce vor fi preluate de acesta,
determinandu-se astfel aria de cuprindere a sistemului pentru diferitele stadii sau
etape de dezvoltare. Se formulează deci cerinţele şi restricţiile globale pentru
realizarea sistemului şi a subsistemelor componente, se justifică necesitatea,
oportunitatea şi fezabilitatea sistemului.
Urmează apoi elaborarea modelului de ansamblu al viitorului sistem
informatic.

7.3. Structurarea sistemului informatic

Necesitatea structurării sistemului în elemente componente, ierarhizate după

anumite criterii, este impusă, în practica de realizare a sistemelor informatice, de
considerente precum :
- procesul de realizare a unui sistem se desfăşoară în timp, etapizat, prin
dezvoltarea unor componente care ulterior sunt asamblate ;
- modul de organizare, conducere şi desfăşurare a lucrărilor de proiectare
necesită în diverse momente o diviziune a muncii, pe elemente componente ale
sistemului ;
- cerinţele unora dintre utilizatorii sistemului se referă doar la anumite părţi
ale acestuia.
Elaborarea modelului de ansamblu al sistemului informatic presupune deci
descompunerea sistemului informaţional-decizional în subsisteme relativ
autonome. Fiecare subsistem al sistemului informatic va avea funcţiunile, intrările
şi ieşirile sale, colecţii de date specifice, algoritmi de transformare a intrărilor în
ieşiri informaţionale.
Intrările unui subsistem de la alte subsisteme, precum şi ieşirile către alte
subsisteme constituie legăturile dintre ele, care vor fi materializate prin transferuri
de date. La nivelul sistemului va exista şi o colecţie de date comună tuturor
subsistemelor componente. În ceea ce priveşte legăturile externe, acestea vor fi
reprezentate prin transferuri de informaţii către alte sisteme sau de la alte sisteme.

Deci, prin structurarea sistemului informatic se vor evidenţia subsistemele

componente, legăturile dintre acestea precum şi conexiunile exterioare ale
sistemului cu alte sisteme, pe verticală şi pe orizontală. Se trece apoi la
proiectarea, la nivel global, a subsistemelor componente.

166
 Structurarea sistemului informatic se impune cel puţin din următoarele
considerente: numărul mare de elemente şi legături care compun, de regulă, un
sistem informatic face aproape imposibilă definirea şi precizarea până în cele mai
mici detalii a acestora, astfel încât sistemul să poată fi proiectat "în bloc";
implementarea simultană a tuturor componentelor sistemului informatic într-o
unitate economică, fără perturbarea activităţii acesteia, apare ca deosebit de
dificilă, datorită complexităţii şi dinamicii proceselor şi fenomenelor economice
din cadrul unităţii; stabilirea priorităţii unor obiective faţă de altele ; resurse
financiare, umane şi materiale limitate ; necesitatea acumulării experienţei în
domeniul proiectării sistemelor informatice.
Structurarea sistemului informatic pe elemente componente asigură astfel
posibilitatea realizării eşalonate a sistemului informatic.
O serie de cerinţe se vor avea în vedere la structurarea sistemului informatic.
Astfel :
- pe fiecare nivel al structurii se impune asigurarea unicităţii criteriului de
descompunere a sistemului;
- structura realizată trebuie să permită constituirea sistemului prin agregarea
modulelor;
- structura nu trebuie să conţină suprapuneri ale modulelor componente;
- structura trebuie să fie pe cât posibil naturală, ceea ce înseamnă că trebuie
să fie obţinută pe baza unui criteriu semnificativ şi esenţial.
Ţinând cont de toate aceste cerinţe, în structurarea unui sistem informatic se
utilizează o serie de criterii de descompunere în subsisteme şi module
componente, cum sunt :
a). Criteriul funcţional de structurare, potrivit căruia un sistem informatic
este structurat în mai multe subsisteme funcţionale. Potrivit acestui criteriu,
structura funcţională a unui sistem informatic pentru conducerea unei unităţi
economice, este grefat pe funcţiunile de bază ale acesteia, şi anume: Producţie sau
Prestări servicii, Comercială (Aprovizionare – Desfacere), Financiar –
Contabilitate, Resurse umane, Cercetare –Dezvoltare, Cercetare ştiinţifică şi
Marketing.
Fiecărei funcţii îi va corespunde, conform acestui criteriu de descompunere,
câte un subsistem funcţional.(fig 7.1). La rîndul lor, subsistemele funcţionale vor
fi descompuse în module sau aplicaţii informatice în concordanţă cu atributele
conducerii şi nivelul de conducere: strategic, tactic sau operativ.
b). Structura ierarhică/organizatorică poate constitui un alt criteriu de
structurare a sistemului în subsisteme la nivelul compartimentelor sau structurilor
organizaţionale ale societăţii.
c) În raport cu nivelele de decizie existente în cadrul societăţii se pot identifica
subsistemul strategic, subsistemul tactic şi subsistemul operativ.

167
 Prin urmare, în cadrul sistemului vom defini subsistemele componente, iar în
cadrul acestora, aplicaţiile informatice sau modulele componente, cu legăturile
informaţionale pe care le necesită, cu intrări, ieşiri, colecţii de date şi algoritmi de
prelucrare descrişi la nivel global.
Sistemul trebuie să urmărească realizarea obiectivelor generale ale societăţii,
fixate pe o perioadă mai lungă de timp. În fixarea şi eşalonarea obiectivelor
generale îşi găseşte expresia atributul de previziune al conducerii. De exemplu,
aceasta are ca obiectiv atingerea unui anumit nivel al producţiei într-un interval de
timp, creşterea rentabilităţii societăţii, etc.
Subsistemul corespunde de regulă unor obiective derivate din cele generale. De
exemplu, aprovizionarea cu materii şi materiale conform cerinţelor, politica de
vânzare a produselor, cercetarea şi proiectarea produselor şi tehnologiilor noi, etc.
Aplicaţia, ca unitate componentă a subsistemului, se dezvoltă de regulă la
nivelul unor activităţi sau compartimente din cadrul societăţii, cum ar fi:
programarea, lansarea şi urmărirea producţiei, urmărirea contractelor, etc
În cadrul sistemului informatic orice aplicaţie este alcătuită din programe,
proceduri manuale şi date care, utilizând echipamentele specificate în
documentaţia aplicaţiei, realizează prelucrarea automată a datelor şi conduc la
obţinerea performanţelor dorite.
Structurarea sistemului, împărţirea lui în subsisteme şi aplicaţii rămâne o
problemă a proiectantului, pe care acesta o rezolvă de la caz la caz, în funcţie de
mărimea, complexitatea şi specificul societăţii, de obiectivele şi cerinţele
beneficiarului, de criteriile de eficienţă adoptate.

Fig 7.1: Structura funcţională a unui sisteme informatic

la nivelul unei unităţi economice

7.4. Definirea ieşirilor sistemului

Obiectivele oricărui sistem informatic se concretizează practic în satisfacerea

cerinţelor informaţionale ale conducerii, pentru fundamentarea sau asistarea
deciziilor. Concret, aceasta înseamnă furnizarea la cerere sau periodic a situaţiilor,
168
a rapoartelor de ieşire care grupează informaţii, date necesare cunoaşterii realităţii
curente. Pe baza acestora se fundamentează deciziile pentru dirijarea funcţionării
viitoare a unităţii economice.
Utilitatea şi viabilitatea sistemului informatic este determinată de tipul,
conţinutul şi operativitatea cu care se transmit situaţiile de ieşire la factorii de
decizie.
Ieşirile sistemului vor fi definite pentru fiecare subsistem în parte.
Prin "ieşirile" unui subsistem informatic înţelegem totalitatea informaţiilor
furnizate de acesta beneficiarilor interni şi externi.
Definirea "ieşirilor" fiecărui subsistem informatic la nivel global presupune în
primul rând, stabilirea la nivel global a informaţiilor necesare conducerii pe
diferite trepte ierarhice, precizând, pentru fiecare în parte, conţinutul
informaţional, periodicitatea, numărul de exemplare, destinatarul. În definirea
ieşirilor vom ţine cont şi de restricţiile privind conţinutul şi forma de prezentare a
acestora, cum ar fi cazul unor rapoarte tipizate (bilanţ). Pe baza acestora se va
realiza apoi proiectarea logică şi fizică de detaliu a ieşirilor.

7.5. Definirea intrărilor sistemului

Definim "intrările" sistemului informatic ca fiind totalitatea datelor primare

necesare obţinerii informaţiilor de ieşire ale sistemului.
Datele primare reflectă starea şi dinamica fenomenelor şi proceselor economice
din unitatea economică, necesare pentru crearea, actualizarea bazei de date şi
obţinerea situaţiilor de ieşire. Acestea pot fi externe sau interne unităţii
economice.
Definirea intrărilor trebuie să includă toate elementele necesare realizării
tehnice ulterioare a documentelor de intrare şi să ofere soluţii pentru preluarea
datelor în sistemul informatic. Pe baza acestora se va face apoi proiectarea logică
şi tehnică de detaliu a intrărilor.
La nivelul fiecărui subsistem informatic "intrările" sunt condiţionate de
"ieşirile" sale pe două planuri: în plan logic, orice "ieşire" este un rezultat al
aplicării unuia sau mai multor operatori asupra unui ansamblu de date de intrare.
Odată definite "ieşirile" sistemului şi operatorii de transformare, "intrările" vor
apare ca determinate de aceste "ieşiri". În plan tehnologic, caracteristicile cerute
ieşirilor sistemului (obiectivitate, fiabilitate, precizie) condiţionează
caracteristicile cerute intrărilor, în particular în ceea ce priveşte datele elementare.
Rezultă deci că determinarea intrărilor presupune o analiză care are ca punct de
plecare informaţiile de ieşire din subsistem. După determinarea "intrărilor" sub
aspectul conţinutului global al acestora, pentru fiecare document de intrare se va
stabili sursa de provenienţă, periodicitatea, volumul, numărul de exemplare, etc.
De asemenea, se pot defini la nivel global posibilităţile şi modalităţile de culegere
şi verificare în vederea stocării lor. În acest sens trebuie subliniat faptul că există
169
un număr însemnat de documente primare tipizate, adaptate la prelucrarea
automată a datelor care pot fi utilizate în cadrul sistemelor informatice.

7.6. Stabilirea globală a colecţiilor de date

În această etapă se realizează proiectarea modelului conceptual de ansamblu

al datelor, se identifică tipurile de entităţi şi relaţiile dintre acestea, se definesc
astfel, la nivel global, colecţiile de date, se face analiza soluţiilor pentru
administrarea şi manipularea datelor.
Pornind de la datele definite global în toate aceste activităţi, se trece la
gruparea lor în colecţii de date pe baza unor criterii, pentru fiecare subsistem în
parte şi la nivelul întregului sistem. Se obţin astfel colecţiile de date specifice
fiecărui subsistem şi colecţiile de date comune sistemului. Aceste colecţii au un
caracter orientativ pentru proiectarea fişierelor şi/sau entităţilor bazei de date.
Sunt formulate o serie de criterii pe baza cărora se poate face gruparea datelor.
Dintre acestea mai cunoscute sunt: stabilitatea conţinutului datelor, domeniul de
activitate, sfera de cunoaştere, rolul datelor în procesul prelucrării etc.

a). Din punct de vedere al stabilităţii datelor se pot identifica:

- colecţii de date convenţional-constante ;
- colecţii de date variabile.
La colecţiile de date variabile actualizarea se face des şi conţinutul datelor se
schimbă frecvent.
În cadrul colecţiilor de date convenţional-constante o importanţă deosebită o
au datele cu caracter normativ care reprezintă, după cum arată practica, 50 – 60%
din volumul total de informaţii care circulă în procesul informaţional al unei
unităţi economice. Aceste colecţii de date se mai numesc şi nomenclatoare.
Coeficientul de stabilitate al acestor date, definit ca raport între numărul poziţiilor
neschimbate dintr-un nomenclator şi numărul total de poziţii, este foarte mare,
îndeosebi la unităţile cu producţie de masă, ajungând la valori chiar mai mari de
0,9.
Dintre colecţiile de date cu caracter normativ putem aminti următoarele:
- normative de fabricaţie, care memorează componenţa şi structura produselor,
numărul de subansamble şi repere care intră în fiecare unitate de produs, sursa
acestor informaţii fiind fişa produsului sau reţeta de fabricaţie;
- normative tehnologice, care determină fluxul tehnologic, succesiunea
operaţiilor pe diferite utilaje, categoria operaţiei şi calificarea executantului, sursa
acestor informaţii fiind fişa tehnologică;
- normative de muncă, acestea referindu-se la timpul consumat pentru
executarea unei operaţii sau reper ;
- normative materiale, care se referă la consumul de materie primă şi materiale
pe unitate de produs, semifabricat, subansamblu, reper etc.;
170
 - alte normative care memorează timpii de aşteptare interoperaţii, norma de
stoc de materiale, norma de stoc de produse, de mijloace circulante, de producţie
neterminată etc..
b). Din punct de vedere al prelucrării datelor, colecţiile de date se pot grupa
în: colecţii de date de bază; colecţii de date pentru tranzacţii; colecţii de date
intermediare; colecţii de date statistice; colecţii de date istorice etc.
Colecţiile de date de bază au un conţinut omogen, format din date primare care
reflectă stări, caracteristici, evenimente, fapte preluate din unul sau mai multe
documente primare. Ele formează fondul de bază al datelor din cadrul sistemelor
informaţionale şi au un caracter relativ permanent, în sensul că au o anumită
stabilitate în cadrul colecţiei funcţie de existenţa obiectului de referinţă. Dacă
dispare obiectul de referinţă dispar şi datele care îl caracterizează. Se poate
aprecia că datele îşi păstrează valabilitatea, relevanţa, autenticitatea, au o utilitate
pe perioada de existenţă a obiectelor pe care le reprezintă, le descriu, le reflectă.
Mărimea acestei perioade de timp este specifică fiecărei colecţii, este delimitată
cronologic de momentul apariţiei, înscrierii datelor şi de momentul dispariţiei. În
afara acestor limite datele îşi pierd valabilitatea, devin perimate, rămânând doar
cu o valoare istorică. Aceleaşi caracteristici cronologice şi acelaşi rol îl au şi
nomenclatoarele de coduri asociate lor. Aceste colecţii de date de bază vor fi
organizate de regulă în fişiere obiect sau în baze de date.
Colecţiile de date pentru tranzacţii au un caracter temporar şi un conţinut
format din totalitatea modificărilor care pot interveni pe parcursul unui interval de
timp asupra conţinutului informaţional din colecţiile de date de bază. Deci, aceste
colecţii de date sunt utilizate pentru actualizarea colecţiilor obiect şi a
nomenclatoarelor. De regulă, în cadrul sistemului, aceste colecţii sunt organizate
în fişiere pentru actualizări (tip jurnal).
Colecţiile de date intermediare sau de lucru sunt obţinute pe baza unor operaţii
de sortare, fuziune, selectare din una sau mai multe colecţii obiect potrivit unor
cerinţe furnizate de utilizator în vederea obţinerii unei situaţii cu rezultate finale
sau seturi de situaţii. Acestea vor constitui în sistem fişierele de lucru.
Colecţiile de date statistice au un rol de orientare, de previziune, de
fundamentare a unor decizii strategice. Datele din aceste colecţii au un grad mare
de sintetizare şi agregare astfel încât ele pot fi păstrate pe perioade mai mari de
timp. Aceste colecţii în sistemele informatice vor fi organizate în fişiere statistice.
Colecţiile de date istorice au rolul de arhivare a conţinutului unor colecţii
obiect, de tranzacţii sau statistice şi reflectă o stare trecută a fenomenelor şi
proceselor economice. Aceste colecţii de date vor fi stocate pe suporţi magnetici,
putând fi oricând interogate, verificate sau consultate.

c). După sfera de cunoaştere se pot identifica patru tipuri de colecţii mari de
date cu utilitate diferită, cu grad de agregare şi sintetizare a datelor diferit şi

171
anume: date primare; indicatori tehnico-economici cu caracter operativ; indicatori
tehnico-economici cu centralizare medie şi indicatori sintetici.
Includerea unor date din ultimele trei colecţii în structura logică a fişierelor
sau a entităţilor bazei de date nu este recomandată în mod normal, dar, dacă este
bine motivată şi controlată, dacă există o cunoaştere profundă a fenomenelor şi
proceselor economice descrise, şi dacă este folosită cu multă atenţie, ea ar putea
să conducă la reducerea costurilor de prelucrare automată a datelor, la creşterea
operativităţii sistemelor de prelucrare, la creşterea eficienţei sistemelor
informatice.

d). După domeniul de activitate la nivelul unei unităţi productive datele pot fi
grupate în colecţii ce reflectă entităţi, fenomene şi procese economice.
Aceste colecţii sunt întâlnite la nivel microeconomic în unităţile productive din
industrie, transporturi, agricultură, comerţ etc.
Astfel, vom putea întâlni colecţii de date cum sunt :
Angajaţi – cu datele ce caracterizează entitatea Angajaţi ;
Produse – cu datele ce caracterizează entitatea Produse ;
Comenzi – cu date ce caracterizează entitatea Comenzi ;
Gestiuni – cu date ce caracterizează entitatea Gestiuni ;
Materiale – cu datele ce caracterizează entitatea Materiale ;
Încasări – cu datele ce caracterizează entitatea Incasări ;
Beneficiari – cu datele ce caracterizează entitatea Beneficiari ;
Furnizori – cu datele ce caracterizează entitatea Furnizori ;
Plăţi – cu datele ce caracterizează entitatea Plăţi, etc
Odată cu stabilirea colecţiilor de date, în această etapă se stabilesc şi o serie de
caracteristici globale, cum sunt: conţinutul, stabilitatea, gradul de sintetizare şi
agregare a datelor, utilitatea colecţiei, frecvenţa de actualizare, volumul etc. Cu
aceste elemente se poate construi un dicţionar de date cu următoarea structură:
codul de identificare, semnificaţia datei, natura, lungimea, sursa, destinaţia.
Odată ce au fost determinate colecţiile de date şi principalele caracteristici
globale ale acestora, se poate alege soluţia de organizare şi manipulare a datelor în
fişiere, bază sau bancă de date.

7.7. Alegerea tipurilor de modele matematice ce urmeazã a fi utilizate

Pentru optimizarea proceselor economice dintr-o unitate economică sistemul

informatic trebuie să se bazeze pe folosirea metodelor şi tehnicilor din teoria
sistemelor şi cibernetica economică, pe introducerea unor modele economico-
matematice care să-i confere valenţe sporite în analiza proceselor economice şi
fundamentarea deciziilor. Toate acestea au ca scop descoperirea rezervelor
interne, creşterea volumului de producţie, reducerea costurilor, sporirea profitului,
172
creşterea productivităţii muncii. Alegerea tipului de model utilizat depinde de
domeniul în care urmează să se realizeze sistemul informatic, de specificul
problemei abordate, de echipamentele de calcul şi programele existente etc .
Modelele matematice folosite în fundamentarea ştiinţifică şi perfecţionarea
activităţii economice pot fi:
- Modele de programare liniară
- Modele de programare neliniară
- Modele de programare dinamică
- Modele de tip A.D.C.
- Modele de teoria grafurilor
- Modele de gestiune a stocurilor
- Modele de programarea producţiei
- Modele de simulare , Modele de teoria deciziilor
- Modele de aşteptare, Modele de tip INPUT, etc.
De exemplu, în domeniul comerţului exterior, alegerea ofertei optime
reprezintã una din principalele exigenţe la contractare şi se poate realiza prin
aplicarea unor modele de decizii multicriteriale în paralel cu asigurarea fondului
de date referitoare la dinamica preţurilor, documentaţia tehnică, performanţele
utilajelor sau maşinilor etc.

7.8. Alegerea tehnologiei de prelucrare şi estimarea necesarului de resurse

Alegerea tehnologiei de prelucrare automată a datelor se face în funcţie de

calitatea şi dimensiunile resurselor alocate, de specificul sistemului obiect, dar şi
de modul în care aceste resurse pot fi utilizate pentru satisfacerea cerinţelor
impuse sistemului informatic.
Tehnologiile se pot clasifica după diverse criterii cum ar fi : metodele, tehnicile
şi echipamentele utilizate; modul de organizare şi structurare a datelor; modalităţi
de culegere şi preluare a datelor; metode şi tehnici de prelucrare a datelor,
posibilităţi de redare a rezultatelor obţinute etc.
Astfel, ţinând cont de modul de preluare şi transmitere a datelor putem vorbi
de:
- Tehnologii fără procedee de teletransmisie şi teleprelucrare a datelor;
- Tehnologii cu procedee de teleprelucrare a datelor.
Tehnologia de teleprelucrare a datelor face posibilă asigurarea regimului de
lucru interactiv, conversaţional, care permite un dialog om-calculator la distanţă,
de forma întrebare-răspuns. Dialogul permite facilităţi de obţinere de la distanţă şi
de transmitere la distanţă a rezultatelor sau datelor cerute.
Ţinând cont de performanţele lor tehnico-funcţionale legate de viteza de
execuţie a operaţiilor de culegere, înregistrare, prelucrare şi afişare a datelor
obţinute din prelucrare, tehnologiile de prelucrare automată a datelor se mai pot
grupa în:
173
 - Tehnologii cu răspuns întârziat, specifice sistemelor informatice statistice,
de evidenţă, caracterizate prin faptul că oferă informaţii cu întârziere faţă de
momentul producerii fenomenului, procesului sau activităţii la care se referă.
- Tehnologii în timp real, care oferă informaţii practic instantaneu faţă de
momentul producerii procesului sau activităţii la care se referă datele prelucrate.
Aceste tipuri de tehnologii sunt, de fapt, tehnologii de teleprelucrare a datelor cu
înalte performanţe tehnico-funcţionale utilizate pe scară largă în conducerea
proceselor tehnologice, a unor procese cu viteză mare de desfăşurare, pentru
controlul operativ al stocurilor, pentru operaţiuni bancare etc.
Funcţie de modul de structurare şi organizare a datelor tehnologiile de
prelucrare automată a datelor pot fi grupate în: tehnologii care utilizează fişiere
clasice, tehnologii care utilizează fişiere clasice şi fişiere integrate; tehnologii care
utilizează baze de date (specifice, distribuite, relaţionale etc.).
Funcţie de modul de amplasare a calculatorului electronic în raport cu
punctele de generare a datelor şi cu cele de valorificare a informaţiilor obţinute
din prelucrare, tehnologiile mai pot fi grupate în :
- Tehnologii pentru sisteme informatice centralizate, caracterizate prin
centralizarea resurselor sistemului informatic.
- Tehnologii pentru sisteme informatice distribuite, o formă superioară din
punct de vedere tehnic şi funcţional de teleprelucrare a datelor. Aşa sunt, de
exemplu, tehnologiile utilizate în reţele interconectate de calculatoare electronice.

Alegerea tipului de tehnologie de prelucrare se va face după o analiză a

tuturor cerinţelor legate de prelucrarea datelor, formulate de beneficiar, a
posibilităţilor de organizare şi structurare a acestora, dar şi a posibilităţilor
financiare ale beneficiarului de a achiziţiona cele mai adecvate şi moderne sisteme
şi echipamente de comunicaţii necesare.
- Practic, proiectantul va trebui să stabilească mai întâi dacă va gândi sistemul
pentru prelucrare locală sau teleprelucrare. Aceasta ţine de dotarea existentă la
momentul respectiv sau de posibilităţile viitoare privind dotarea cu unul sau mai
multe calculatoare proprii.
- Apoi, proiectantul va decide dacă sistemul va realiza o prelucrare pe loturi
sau în regim conversaţional. Aceasta depinde de mai mulţi factori, precum :
caracterul operativ sau periodic al informaţiilor furnizate de sistem; modul de
obţinere al rapoartelor la termene prestabilite sau la cerere, pe hârtie sau pe
display; modul de culegere a datelor de către personal specializat sau direct de
către utilizatori.
În ultimul timp s-a optat tot mai mult pentru soluţia prelucrării interactive.
- Prelucrarea centralizată, descentralizată sau distribuită este cea de-a treia opţiune
a proiectantului în cadrul proiectului de ansamblu. În ultima perioadă apariţia
microcalculatoarelor şi scăderea rapidă a costurilor acestora favorizează realizarea
unor sisteme distribuite. Se ştie că în sistemele centralizate principalele funcţiuni
174
ale sistemului informatic - de prelucrare şi de stocare - sunt realizate pe un
calculator sau mai multe, amplasate într-un singur punct. Spre deosebire de
acestea, în sistemele distribuite aceste funcţiuni sunt executate descentralizat, de
regulă pe microcalculatoare amplasate în diferite puncte ale societăţii economice,
cât mai aproape de locurile de generare a datelor şi de factorii de decizie. Între
punctele de prelucrare şi stocare există legături de comunicaţie prin care se
transferă datele, funcţie de necesităţile de prelucrare la nivelul întregului sistem.
Se creează astfel un sistem ierarhizat pe două sau mai multe nivele, în funcţie de
complexitatea şi caracteristicile proceselor tehnico-productive şi de numărul de
puncte de prelucrare.
Alegerea tipului de sistem se poate face prin evaluarea modului în care
sistemul răspunde la o serie de criterii cum ar fi timpul de răspuns, siguranţa în
asigurarea funcţiunilor de prelucrare - stocare, adaptabilitate, flexibilitate, costuri
de realizare şi exploatare, costuri de întreţinere şi dezvoltare.
Odată stabilite toate aceste caracteristici ale tehnologiei de prelucrare adoptate,
se poate face o estimare a resurselor necesare pentru realizarea sistemului
informatic. Se au în vedere, în acest sens :
- resursele financiare necesare pentru achiziţionarea echipamentelor, a
softului de bază necesar şi a proiectării şi realizării efective a sistemului ;
- resursele umane, deci personalul de specialitate ;

Estimarea necesarului de personal de specialitate

Personalul de specialitate necesar realizării şi apoi exploatării curente a
sistemului informatic se determină funcţie de volumul de muncă cerut de
complexitatea proiectului, de volumul de muncă cerut de întreţinerea şi
exploatarea sistemului informatic. Astfel, pentru proiectarea şi realizarea
sistemului echipa va fi formată din analişti, programatori, ingineri de sistem,
administratori de baze de date, administratori de reţea, eventual designer Web, iar
pentru exploatare şi întreţinere operatori pentru diversele echipamente, ingineri de
sistem, administratori de baze de date sau administratori de reţea, după caz şi
personalul de întreţinere. Numărul concret va depinde şi de modul în care se
asigură, cu forţe proprii, proiectarea şi exploatarea sistemului informatic.

Estimarea necesarului de produse program

Produsele – program necesare sistemului informatic se referă la:
- soft de bază pentru calculatorul electronic, adică sistem de operare,
programe utilitare necesare;
- elemente tipizate cum ar fi proiecte de subsisteme cu pachetele de
programe asociate, diferite pachete de programe aplicative, programe
generalizabile etc care pot fi preluate;

175
 - programe de la alte firme de soft aplicate deja, cu performanţe bune în
domeniul nostru de interes;
- efort propriu pentru proiectare şi / sau realizare.
Recurgerea la utilizarea unor elemente tipizate necesită însă o analiză
aprofundată, în scopul alegerii unei soluţii dintre cele existente, în raport cu :
efortul necesar adaptării, transformării elementelor tipizate şi a programelor
preluate, conform specificului sistemului obiect; eficienţa utilizării lor estimată
prin economie la activitatea de proiectare; posibilitatea integrării cu alte elemente
tipizate utilizate în sistem sau cu elemente proprii, elaborate în etapa de
proiectare. Ca urmare a acestei analize, o parte din elementele schemei
funcţionale a sistemului informatic va fi acoperită cu elemente tipizate şi
programe generalizate, iar o altă parte, cu programe ce urmează a fi realizate prin
eforturi proprii.

Estimarea necesarului de resurse financiare presupune comensurarea tuturor

cheltuielilor necesare pentru dotarea hardware şi software corespunzătoare, pentru
proiectarea, realizarea şi exploatarea sistemului informatic. Cheltuielile pentru
achiziţionarea echipamentelor necesare este strict legată de dotarea existentă, dar
şi de soluţia aleasă pentru tehnologia de prelucrare, transmitere şi stocare a
datelor. Pe baza cuantificării efectelor economice directe şi indirecte ale
funcţionării noului sistem şi a cheltuielilor totale determinate de acesta, se
estimează eficienţa economică a sistemului informatic, care va fi inclusă în
proiectul de ansamblu al sistemului informatic respectiv.

7.9. Planificarea realizării sistemului informatic

Planificarea realizării unui sistem informatic are la bază principiul

eşalonării.
Prin eşalonare înţelegem ordinea în care vor fi abordate şi realizate
componentele sistemului informatic, începând cu proiectarea de detaliu,
programarea, implementarea, până la introducerea în exploatare curentă, cu
asigurarea condiţiilor pentru integrarea lor treptată. Atunci când se stabileşte
ordinea de prioritate în abordarea componentelor sistemului informatic pot fi luate
în considerare o serie de criterii, cum sunt:
- Prioritatea obiectivelor componente
- Asigurarea legăturilor dintre componente
- Disponibilitatea resurselor

Prioritatea obiectivelor componente poate fi stabilită ca cerinţă expresă a

beneficiarului, care şi-a stabilit o ordine de abordare a componentelor sistemului
sau poate să fie stabilită de echipa de proiectare. În acest din urmă caz acest

176
criteriu acordă, de regulă, cea mai mare prioritate componentelor subsistemului
pentru conducerea producţiei, apoi celor care abordează subsistemele referitoare
la resursele necesare producţiei.
Această ordine este determinată de faptul că producţia se consideră activitatea
de bază, iar celelalte activităţi care asigură direct sau indirect desfăşurarea
producţiei, cu resursele necesare, apar ca procese dependente sau secundare,
determinate integral de procesul de producţie. Se consideră astfel că aplicaţiile
informatice pentru conducerea producţiei conduc la însemnate efecte economice,
cum ar fi creşterea profitului, creşterea gradului de utilizare a capacităţilor de
producţie, creşterea productivităţii muncii etc. În acelaşi timp însă, ele ridică şi
cele mai dificile probleme de proiectare a soluţiilor de realizare a culegerii,
transmiterii şi prelucrării datelor.

Asigurarea legăturilor între componente este o problemă deosebit de

importantă, căci la nivel global ele se definesc chiar din etapa proiectării de
ansamblu. Legăturile dintre subsisteme înseamnă practic un sistem unitar de
codificare a datelor, transferuri de date între acestea, mijloace tehnice şi tehnologii
de transfer adecvate. În cadrul unui sistem informatic va exista astfel o colecţie de
date comună subsistemelor, dar şi colecţii de date specifice lor. În această etapă se
stabilesc şi se descriu practic la nivel global legăturile informaţionale şi forma
acestora între diversele subsisteme sau module componente.

Disponibilitatea resurselor reprezintă un criteriu care va influenţa în mod

direct ordinea de abordare şi realizare a componentelor sistemului informatic
depinzând de: limita fondurilor ce pot fi alocate în timp pentru realizarea
sistemului informtic; nivelul de dotare cu tehnică de calcul existent în etapa de
concepere şi cel prevăzut a fi realizat ; forţele de proiectare pe care le va antrena
proiectul; personalul de specialitate existent şi în curs de pregătire la beneficiar
necesar pentru implementarea şi exploatarea sistemului informatic.
Planificarea realizării sistemului informatic înseamnă de fapt precizarea
eşalonării, în timp, a proiectării şi realizării fiecărei componente, pe faze de
execuţie, cu resursele necesare (financiare, umane, materiale) şi termene precise
de realizare.
În funcţie de toate criteriile prezentate mai sus, planificarea se va realiza
utilizând ca instrumente de lucru : graficul de detaliu în formă tabelară, sub formă
de grafic GANTT sau sub formă de grafic de tip reţea PERT. Acestea din urmă
sunt mai explicite, căci pot prezenta şi condiţionările între activităţile de realizare
a componentelor şi activităţi nelegate de proiectare cum sunt pregătirea cadrelor,
raţionalizarea sistemului de evidenţă, etc.

177
 8. PROIECTAREA DE DETALIU A SISTEMELOR INFORMATICE

Am văzut că proiectarea de ansamblu este o etapă a proiectării sistemelor

informatice complexe, care necesită o descompunere pe mai multe nivele de
elemente componente: subsisteme, aplicaţii sau module informatice. Ea presupune
identificarea, definirea şi descrierea la nivel global a tuturor elementelor de
importanţă în proiectarea unui sistem informatic, cum sunt: funcţiunile şi structura
funcţională a subsistemelor sau aplicaţiilor componente, ieşirile, intrările, sistemul
de codificare, colecţiile de date comune şi specifice fiecărui subsistem, alegerea
modalităţii de organizare şi structurare a datelor, interfaţa cu utilizatorul,
estimarea eficienţei economice a noului sistem. Proiectarea de ansamblu precede
şi pregăteşte astfel proiectarea de detaliu.

Aceasta înseamnă că, prin proiectarea de detaliu se realizează practic

detalierea, pentru fiecare subsistem în parte sau aplicaţie informatică definită,
a tuturor elementelor implicate, pe baza cerinţelor formulate pentru noul sistem
şi a activităţii de studiu şi analiză a sistemului existent, concretizate în modelul
datelor şi modelul prelucrărilor. Se realizează astfel modelul de detaliu al
fiecărui subsistem sau componentă a sistemului şi se stabilesc soluţiile tehnice
de realizare ale fiecăruia.

La nivelul unei aplicaţii informatice este posibil ca etapa proiectării de

ansamblu să lipsească şi atunci se impune ca definirea şi proiectarea tuturor
elementelor componente să se facă direct în cadrul acestei etape, rezultând direct
modelul de detaliu al domeniului abordat.
Proiectarea de detaliu cuprinde două activităţi distincte realizate pentru
fiecare aplicaţie sau modul din cadrul sistemului, denumite sugestiv:
- proiectare logică de detaliu
- proiectare tehnică de detaliu.
Cele două activităţi se finalizează cu o documentaţie corespunzătoare,
denumită: Proiect logic de detaliu şi Proiect tehnic de detaliu.

Proiectul logic de detaliu cuprinde informaţii privind cerinţele de detaliu ale

componentei funcţionale, soluţia de organizare şi structurare a datelor, descrierea
intrărilor, ieşirilor, a interfeţei cu utilizatorul.

Proiectul tehnic de detaliu, adresat specialiştilor (programatori) prezintă, în

plus, specificaţii tehnice de realizare a programelor sau procedurilor automate,
permiţând astfel comunicarea în cadrul echipei de proiectare şi realizare a
sistemului.

178
 8.1. Detalierea funcţiunilor şi a structurii funcţionale a subsistemelor
şi/sau a aplicaţiilor informatice

În cadrul acestei activităţi se detaliază funcţiunile fiecărei aplicaţii până la

nivelul funcţiilor elementare, definind, acolo unde este posibil, chiar procedurile
care urmează să fie realizate. Se realizează deasemenea schema funcţională a
fiecărui subsistem sau aplicaţie informatică. Se întocmeşte apoi lista procedurilor
automate şi manuale pe care le implică realizarea aplicaţiei informatice, pornind
de la funcţiile elementare ale acesteia şi se descriu aceste proceduri. Pot fi puse în
evidenţă diverse variante funcţionale ale fiecărui subsistem sau aplicaţie
informatică, beneficiarul putând opta pentru una din ele.
Apoi, luând în considerare condiţiile, evenimentele externe şi interne care
declanşează procedurile, frecvenţa acestora, duratele şi termenele de realizare, se
poate realiza eşalonarea în timp a procedurilor şi graficul de exploatare
preliminară a aplicaţiei, punând în evidenţă şi legăturile funcţionale cu celelalte
subsisteme sau sisteme informatice.
Tot în cadrul acestei activităţi se definitivează modelele matematico-economice
utilizate şi algoritmii de calcul ce stau la baza prelucrării automate în cadrul
aplicaţiei sau modulului informatic. Pentru fiecare procedură în parte se descriu
apoi toate aceste elemente : funcţii elementare, modele utilizate, algoritmi de
calcul, legături cu alte proceduri, cu alte aplicaţii, alte subsisteme sau chiar alte
sisteme din exterior (cum ar fi raportări la circa financiară, la ministerul tutelar
etc).

8.2. Proiectarea de detaliu a ieşirilor

Ieşirile sistemului informatic au fost definite la nivel global în cadrul

proiectului de ansamblu, care precede şi pregăteşte proiectarea de detaliu. La
nivelul unei aplicaţii informatice însă este posibil ca etapa proiectării de ansamblu
să lipsească şi atunci se impune ca definirea şi proiectarea acestora să se facă în
cadrul acestei etape.
Se ştie că ieşirile sistemului informatic conţin rezultatul prelucrărilor efectuate
asupra datelor de intrare şi se pot prezenta sub forma unor rapoarte, a unor situaţii
de raportare afişate pe ecran, scrise pe hârtie sau înregistrate pe un suport extern
(disc hard sau flexibil, Cd, casetă magnetică,etc).
În funcţie de natura prelucrărilor care generează ieşirile se pot întâlni
următoarele tipuri de ieşiri informaţionale:
- ieşiri obţinute în urma unor operaţii de transfer a datelor (de exemplu
numărul şi data unei facturi, denumirea unui produs, numele unui salariat etc.);
- ieşiri obţinute în urma unor operaţii de calcul pe baza unor algoritmi de
calcul (de exemplu valoarea totală a facturii, valoarea vânzărilor pe un trimestru,
salariul net al unui angajat, etc.).
179
 Ieşirile sistemului informatic, denumite uzual rapoarte, pot fi reprezentate sub
forma unor indicatori sintetici care stau la baza unor tablouri de bord ce pot fi
consultate de managerii firmei sau sub forma unor rapoarte care regrupează mai
mulţi indicatori sintetici sau analitici sub formă tabelară.
Rapoartele se pot clasifica după mai multe criterii, cum ar fi:
a) Gradul de agregare :
- Rapoarte sintetice – care conţin indicatori sintetici şi sunt destinate
activităţii de fundamentare a deciziilor;
- Rapoarte analitice – care conţin date privind desfăşurarea unei activităţi pe
un anumit segment de timp. De exemplu: situaţia consumurilor de materiale pe
lună, situaţia cazărilor zilnice dintr-un hotel, situaţia camerelor din hotel, etc.
b) Natura informaţiilor conţinute :
- Rapoarte conţinând datele de stare ale sistemului condus (exemplu bilanţul
contabil);
- Rapoartele statistice cuprinzând informaţii cu caracter statistic necesare
raportărilor ierarhice;
- Rapoarte previzionale care permit anticiparea evoluţiei unor procese şi
fenomene economice.
c) Destinaţia rapoartelor :
- Rapoarte de uz intern destinat cerinţelor proprii de informare şi control;
- Rapoarte de uz general – cu un conţinut prestabilit (ex. Bilanţul contabil )
d) Frecvenţa de generare:
• Rapoarte periodice, întocmite la intervale regulate de timp, cum sunt:
- Rapoarte zilnice;
- Rapoarte lunare;
- Rapoarte trimestriale
- Rapoarte anuale
De exemplu, rapoartele săptămânale privind realizarea producţiei sau
rapoartele lunare privind vânzările din cadrul unei societăţi. Rapoartele de
vânzare ale managerilor de vânzări pe unităţi pot fi combinate într-un raport lunar
pentru managerii zonali de vânzări.
• Rapoartele de excepţie, care atrag atenţia prin intermediul unor indicatori
asupra acţiunilor sau evenimentelor neobişnuite. Un exemplu îl reprezintă un
raport de vânzare care arată că anumite articole sunt vândute semnificativ peste
sau sub previzionările departamentului de marketing. De exemplu, dacă sunt
vândute mai puţine bucăţi dintr-un articol decât s-a previzionat pentru o zonă,
managerul local va primi un raport de excepţie. Pentru o gestiune de stocuri un
raport al produselor cu stocul zero sau sub limita minimă admisă arată
managerului că trebuie să se aprovizioneze urgent cu respectivul produs, altfel
desfăşurarea procesului de producţie nu poate continua. Pentru o unitate hotelieră,
un raport de excepţie va anunţa dacă s-au ocupat toate locurile de cazare prin
rezervare automată sau dacă nu au fost solicitate deloc.
180
 • Rapoarte la cerere, careare reprezintă opusul unui raport periodic, este
realizat conform cerinţelor decidentului. Un exemplu este un raport asupra
numărului şi funcţiilor deţinute de femei în unitate. Astfel de raport nu este
necesar periodic, dar ar putea fi necesar atunci când este solicitat de administraţia
locală sau de guvern. Această informaţie este folosită pentru a demonstra că firma
are indicatori favorabili şi poate solicita anumite facilităţi. Un raport la cerere
pentru o unitate hotelieră ar putea fi, de exemplu, referitor la turiştii străini cazaţi,
pe categorii de vârste şi sex.

Rapoartele pot fi listate la imprimantă, vizualizate pe monitor sau memorate pe

un suport magnetic în vederea continuării prelucrărilor în cadrul altor subsisteme
informatice. Adeseori rapoartele de ieşire sunt însoţite de reprezentări grafice, sub
forme adecvate, pentru a se putea observa mai uşor evoluţia unui proces sau a
unui fenomen economic. Acestea se recomandă îndeosebi managerilor de nivel
înalt, care au nevoie de informaţii cu grad mare de sintetizare. Ele pot avea un
format predefinit, cu formatarea dorită a textului sau un format definit de
utilizator.
În această etapă de proiectare se definitivează practic proiectarea tuturor
ieşirilor sistemului informatic sau aplicaţiei informatice, în două faze: proiectarea
logică şi proiectarea fizică.

a). Proiectarea logică de detaliu a ieşirilor înseamnă de fapt detalierea

cerinţelor informaţionale stabilite în etapa proiectării de ansamblu şi stabilirea,
pentru fiecare situaţie în parte, a machetei corespunzătoare şi a specificaţiilor
tehnice de realizare care o însoţesc. Astfel, macheta fiecărui raport reprezintă
practic formatul de descriere al acestuia şi conţine un antet, date fixe, date de
identificare ale raportului, un cap de tabel, precum şi rândurile de date curente şi
eventual de totaluri, subtotaluri, indicatori calculaţi.
Machetele se înaintează beneficiarului, care, în urma analizei lor, poate
formula modificări ale formatului acestora.
Machetele rapoartelor, împreună cu specificaţii tehnice de realizare se
înaintează echipei de programare, pentru a scrie efectiv programele
corespunzătoare. În cadrul acestora sunt precizate informaţii precum: numărul de
exemplare, destinaţia, termene, criterii de validare a datelor, algoritmi de calcul.

b). Proiectarea fizică de detaliu a ieşirilor se realizează pe baza specificaţiilor

de ieşire şi presupune definitivarea formei şi formatului de prezentare a
rapoartelor, aşezarea în pagină, spaţierea rândurilor, stabilirea procedurilor de
interpretare a ieşirilor. Tot acum se alege tipul de suport fizic de ieşire
(imprimantă, monitor, disc magnetic fix sau flexibil, CD, bandă magnetică, etc)
funcţie de situaţia concretă a beneficiarului în ceea ce priveşte dotarea cu
calculatoare şi amplasarea acestora, modul de lucru (în reţea sau posturi
181
individuale), costul suportului ales şi măsura în care el răspunde cerinţelor
concrete de informare.
Atunci când se definitivează forma de prezentare a rapoartelor o serie de factori
pot influenţa în mod concret şi real alegerea făcută, cum sunt:
- formatul cerut de conducere, care poate fi unul existent, cu care s-a obişnuit
să lucreze, sau unul nou, cu informaţii suplimentare pe care le poate obţine din
baza de date;
- necesitatea utilizării unor formate (formulare) tipizate, utilizate de societate
în relaţia cu alţi parteneri sau realizarea unor formulare asemănătoare, cu aceeaşi
structurare a datelor;
- conţinutul informaţional al raportului, numărul de coloane pe pagină,
numărul de linii afişate pe ecran, posibilităţi de imprimare (negru, color) sau de
transmitere a rapoartelor sunt strâns legate de caracteristicile tehnice ale
echipamentelor de care dispune firma beneficiară şi de aceea le pot influenţa în
mod direct.
- considerente de eficienţă economică a rapoartelor obţinute pot influenţa
proiectarea acestora, şi anume: economia de hârtie şi/sau de consumabile la
imprimantă, reducerea timpului pentru obţinerea propriu-zisă a rapoartelor,
posibilitatea de listare în alt moment sau la alt calculator a rapoartelor, pentru a nu
întârzia execuţia lucrării, organizarea mai multor rapoarte pe o pagină, etc.
- necesitatea unei minime autodocumentări a oricărui raport printr-un titlu şi
un cap de tabel explicit, prin precizarea unor reguli privind citirea raportului,
interpretarea rezultatelor sau semnificaţia codurilor utilizate;
- asigurarea unei bune lizibilităţi a raportului, printr-o spaţiere şi o dispunere
corespunzătoare a datelor în cadrul paginii, prin sublinierea sau afişarea colorată a
rezultatelor importante sau a celor de excepţie;
- utilizarea, în mare măsură, a vizualizării unor rapoarte pe ecran, care, pe
lângă alegerea unor formate adaptate la dimensiunile acestuia, pot apela şi la
facilităţile oferite de monitoare sau ecranele video, cum sunt: afişare tip pagină
sau prin defilarea imaginii pe ecran, modul de afişare normal, video-invers,
luminos sau clipitor, scheme de culori prefabricate sau utilizarea unor culori
adecvate situaţiilor obţinute şi celor care le primesc; aceste rapoarte pot fi
proiectate să dialogheze cu beneficiarul, care va putea astfel să opteze pentru
diferite forme ale rapoartelor sau să ceară în mod expres anumite rapoarte prin
intermediul unor meniuri sau opţiuni afişate pe ecran la dipoziţia utilizatorului.
- utilizarea unor generatoare automate de rapoarte puse la dispoziţie de
majoritatea limbajelor de programare şi a sistemelor de gestiune a bazei de date.
Observaţie:
Se apreciază adeseori că numărul de rapoarte obţinute în cadrul unei aplicaţii
informatice este în strânsă legătură cu utilitatea, cu eficienţa ei. Cu cât numărul
rapoartelor de ieşire este mai mare, cu atât aplicţia este mai utilă, mai mulţi
decidenţi au nevoie de ele pentru fundamentarea sau asistarea actului decizional.
182
 Toate acestea, formatul şi conţinutul rapoartelor, reuşita dialogului cu
utilizatorul, plăcerea sau dimpotrivă reticenţa acestuia de a utiliza aceste facilităţi
oferite de aplicaţia proiectată depind, în mare măsură, de documentarea, dar şi de
inventivitatea, creativitatea şi experienţa în domeniu a echipei de proiectare.

8.3. Proiectarea de detaliu a intrărilor

Intrările unui sistem informatic reprezintă ansamblul datelor stocate,

gestionate şi prelucrate în cadrul sistemului, date care provin din dinamica
operaţiilor şi proceselor economice şi financiare derulate în cadrul firmei. Aceste
fluxuri informaţionale de date care însoţesc toate aceste operaţii şi procese (de
exemplu fluxul de date referitoare la aprovizionarea cu materii prime, fluxul de
date reflectând operaţiile de încasări şi plăţi, fluxul de date ce însoţeşte procesele
tehnologice de montaj etc.) se numesc tranzacţii. În cadrul unei firme se pot
identifica diverse fluxuri de tranzacţii, cum sunt:
- tranzacţiile care însoţesc operaţiile şi procesele curente din cadrul firmei
(Notele de Intrare Recepţie –NIR-, bonurile de consum, facturile emise clienţilor,
ştatele de plată, etc.) ;
- tranzacţiile care provin din mediul financiar-bancar (facturi primite de la
furnizori, ordine de plată onorate de clienţi, cotele de impozit etc);
- tranzacţiile provenite de la alte sisteme informatice din cadrul aceleeaşi
firme;
- tranzacţiile care provin de la alte sisteme informatice exterioare firmei.
Din punct de vedere fizic intrările în sistem trebuie să fie realizate utilizând
mijloacele moderne oferite de noile tehnologii informatice, cum sunt:
- proceduri specializate de preluare a datelor tastate de operator pe baza unor
machete videoformat de culegere şi de validare a acestora;
- scanarea documentelor cu ajutorul unui dispozitiv ce funcţionează pe
principii optice şi care permite preluarea unui volum mare de date aflate pe
formulare standardizate într-un timp foarte scurt;
- transfer de date din reţeaua locală a firmei (ex. Reţea Novell sau reţea
Extranet);
- transfer de date la distanţă (prin Internet sau prin reţele private).
Prelucrările sistemului informatic reprezintă un ansamblu omogen de operaţii
automate prin care se vor realiza următoarele operaţii:
- crearea şi actualizarea bazei de date (sau a fişierelor);
- prelucrări, interogări şi listări efectuate asupra datelor conţinute în baza
de date (fişiere);
- reorganizarea (întreţinerea) bazei de date (fişiere);
- salvarea/restaurarea bazei de date (fişierelor).
Proiectarea de detaliu a intrărilor cuprinde, ca şi la ieşiri, cele două etape:
proiectarea logică de detaliu şi proiectarea fizică de detaliu.
183
 În etapa de proiectare logică de detaliu se stabileşte lista completă a intrărilor,
pentru fiecare document de intrare descriindu-se elementele caracteristice cum
sunt conţinutul informaţional, natura şi structura datelor, frecvenţa de apariţie,
volumul, criteriile de control şi validare a datelor, etc.
Datele de intrare parcurg o succesiune de etape în cadrul sistemului informatic
- din momentul generării şi culegerii lor până la momentul utilizării şi prelucrării
lor efective. De aceea, în cadrul sistemului sau aplicaţiei proiectate se impune cu
stringenţă ca preluarea pe suport magnetic în vederea prelucrării lor automate să
aibă în vedere datele primare, deci cele înscrise pe documente primare, adică
acelea care consemnează fenomenul economic la locul şi în momentul producerii
lor, nu cele rezultate în urma unor procese de prelucrare. Prin urmare, datele de
intrare trebuie să fie date culese de pe documentele primare care atestă diferitele
procese economice. Acest lucru se impune în primul rând pentru a asigura
principiul nonredundanţei datelor în sistem, precum şi pentru a asigura
corectitudinea lor şi responsabilitatea celor care le gestionează în cadrul
sistemului.
De aceea, în prelucrarea lor automată, datele de intrare vor parcurge mai multe
etape intermediare, cum sunt: culegerea datelor de pe documentul de intrare pe
baza unei machete, a unui videoformat proiectat de informatician, conversia
acestora în formatul proiectat pentru transpunerea lor pe suportul tehnic,
verificarea sintactică şi logică a datelor de intrare, corecţia datelor eronate şi
reluarea procedeului până la eliminarea erorilor sau anomaliilor constatate în
cadrul lor.

În proiectarea fizică de detaliu numită şi proiectare tehnică de detaliu se

realizează toată această activitate de proiectare a documentelor de intrare şi a
machetelor (ecranelor, videoformatelor sau formularelor) datelor de intrare, se
stabilesc condiţiile de validare a datelor şi instrucţiuni de corectare a acestora, se
alege suportul tehnic pentru memorarea datelor, se definesc procedurile (manuale
sau automate) de culegere şi transmitere a datelor şi se reproiectează, dacă este
cazul, chiar documentele primare de înregistrare a datelor – pentru a răspunde
cerinţelor prelucrării automate.
Pentru fiecare document primar de intrare la nivel fizic se va recurge la
elaborarea machetei documentului primar şi la elaborarea instrucţiunilor de
completare şi utilizare a acestuia. Macheta documentului va reprezenta imaginea
concretă a documentului ce urmează a fi proiectat. Cu privire la elaborarea
machetei documentului primar se pot face următoarele sugestii:
• se va ţine seama de standardele sau normele interne şi internaţionale cu
privire la proiectarea documentelor primare, atât în ceea ce priveşte forma, cât şi
conţinutul.
Astfel, se pot întâlni următoarele situaţii:

184
 FORMĂ CONŢINUT
impusă impus
liber aleasă impus
liber aleasă liber ales
• indicatorii ce urmează a fi preluaţi în documentele primare pot fi precizaţi
prin includerea lor într-un chenar cu dimensionarea numărului de caractere şi
spaţiului rezervat. Dimensionarea spaţiului rezervat completării unui indicator va
depinde de o serie de factori cum sunt:
- mijlocul de completare (manual, maşină de scris, imprimantă);
- condiţiile ergonomice în care urmează să fie completat documentul
primar
- nivelul de pregătire al utilizatorilor de documente primare.
• la nivelul machetei documentului indicatorii pot fi grupaţi în chenare.
• se va recurge, dacă este posibil, la utilizarea formularelor pretipărite.
• se va ţine seama de facilităţile oferite de echipamentele de calcul şi de
pachetele software existente.
Machetele documentelor de intrare a datelor sunt însoţite de o documentaţie
denumită specificaţii de intrare, necesare atât programatorilor pentru scrierea
programelor corespunzătoare, cât şi utilizatorului. Aceste specificaţii trebuie să
conţină :
- macheta documentului de intrare, pe baza căruia se va proiecta
videoformatul de intrare sau formularul de introducere a datelor;
- instrucţiunile de culegere a datelor, de transmitere – dacă este cazul, de
utilizare şi transpunere pe suport tehnic;
- regulile de validare a datelor, posibilităţi de corectare a lor, restricţii de
completare, chei de control.
- reguli de salvare, de conversie sau de restaurare în caz de incident.
Proiectarea fizică (sau tehnică) de detaliu precizează deci în detaliu toate
condiţiile de preluare, validare, transmitere a datelor în vederea unor prelucrări
curente sau ulterioare, de corectitudinea, completitudinea şi operativitatea lor
depinzând, în cea mai mare parte, succesul aplicaţiei sau sistemului informatic.

Dată fiind această importanţă a activităţii, se impun unele precizări cu privire la

momentele cheie ale sale. Astfel:
a). Alegerea suportului tehnic pentru datele de intrare ia în considerare, în
ultima perioadă, din ce în ce mai mult, posibilitatea de introducere a datelor direct
de la terminal, cu posibilităţile de lucru în regim conversaţional pe care acesta le
oferă. Celelalte modalităţi de introducere a datelor utilizând alte suporturi tehnice
cum sunt cartelele magnetice, benzile magnetice, cititoarele optice etc se folosesc
mai rar.

185
 Odată introduse de la terminal, datele intră în circuitul de prelucrare şi
actualizare al unei baze de date sau fişier clasic, sunt transmise electronic (reţea,
e-mail, fax, internet, etc) la un punct central sau local de prelucrare sau sunt
stocate pe un suport magnetic în vederea prelucrării ulterioare.
b). Proiectarea machetelor documentelor de intrare este, indiferent de
metodele de prelucrare a datelor folosite ulterior sau de sistemul de gestiune a
bazei de date ales, o activitate deosebit de importantă prin efectul bun sau mai
puţin bun pe care îl poate avea asupra întregii aplicaţii.
În primul rând se impune precizarea că nu este permisă dublarea documentelor
primare, prin proiectarea unor documente destinate exclusiv preluării datelor în
cadrul aplicaţiei de prelucrare automată realizată.
De regulă, pentru fiecare document primar existent sau reproiectat şi acceptat
de beneficiar se proiectează o machetă corespunzătoare, care va conţine, cum este
şi firesc, următoarele elemente de structură:
- un antet care conţine datele de identificare ale firmei şi/sau a
compartimentului care-l emite (denumire, cod fiscal, adresa, după caz), plasat, de
regulă, în colţul din stânga sus;
- denumirea documentului, codul acestuia şi elemente de identificare (număr,
dată) plasate de regulă sus, în partea dreaptă (sau în centru);
- rânduri şi coloane pentru înscrierea informaţiilor cantitativ - valorice şi a
codurilor aferente, dimensionate şi spaţiate astfel încât datele să poată fi introduse
într-un mod agreabil, plăcut;
- rubrici şi rânduri speciale pentru semnături şi ştampile, plasate de regulă în
partea finală a documentului;
- text explicativ - eventual indicaţii de completare şi verificare a datelor, care
trebuie să fie foarte precis şi succint formulate.
Formatul documentului, aspectul şi regulile de completare a datelor depind în
mod direct de locul şi modalitatea de completare a documentului (manual,
dactilografiat sau automat) şi de nivelul de calificare a personalului care
completează acel document.
Proiectarea unui document (formular) de introducere a datelor trebuie să aibă
în vedere faptul că un operator, nespecialist în informatică şi cu un grad de
pregătire necunoscut, va urmări datele înscrise în document şi le va tasta în
vederea introducerii lor pentru prelucrare automată. De aceea, este important ca
aspectul formularului afişat pe ecran pentru a permite introducerea datelor de la
tastatură să fie asemănător cu cel al documentului de pe care se face citirea
datelor, să respecte întocmai ordinea datelor din document şi nu cea de prelucrare
din programe, să aibă (eventual) ordinea de culegere a datelor precizată prin
numerotarea casetelor, să permită un dialog de forma întrebare-răspuns sau
opţiuni ale unui mic meniu sau chiar butoane afişate pe ecran pentru a facilita
procesul de introducere şi validare a datelor.

186
 Ordinea firească de parcurgere a unui document este de sus în jos şi de la
stânga la dreapta, iar prelucrarea automată a datelor trebuie să o respecte în
momentul introducerii datelor.
O atenţie deosebită trebuie acordată în proiectarea acestor formulare regulilor
de validare a datelor, care se pot referi atât la o validare manuală, ce ţine de
verificarea corectitudinii datelor înscrise pe documentul primar, cât mai ales la
reguli de validare automată, prin programe, a acestora. Pentru aceasta se vor
verifica: încadrarea între limitele admise a unor valori sau indicatori, prezenţa
obligatorie a unor date, apartenenţa codurilor la nomenclatoarele aplicaţiei,
eventuale corelaţii (logice) ce pot exista între datele introduse, apartenenţa
valorilor la un anumit tip, etc menite să asigure consistenţa şi corectitudinea
datelor ce urmează a fi prelucrate apoi automat. Dacă este cazul, pentru unele
câmpuri de date se pot prelua valori implicite, atunci când acestea nu sunt
completate. Aceste valori se preiau din nomenclatoarele de coduri, fişierele bazei
de date sau din tabele special memorate pentru valorile asumate prin lipsă sau se
determină prin aplicarea unui algoritm de calcul asupra unor valori existente.
O validare specială şi cu rezultate deosebite a codurilor se realizează prin
verificarea automată a cifrei de control a acestora, dacă au fost definite astfel de
coduri. Se identifică şi se evită astfel erori de codificare a datelor care ar putea
avea urmări neplăcute în prelucrarea automată a datelor.
Documentele de intrare, machetele de introducere a datelor trebuie să fie
însoţite de instrucţiuni de emitere şi completare bine precizate.
Formatul machetei şi modul de introducere a datelor depind în mare măsură de
forma dialogului om-calculator, care se poate desfăşura fie:
a). sub forma întrebare – răspuns, cu defilarea liniilor ecranului.
Aceasta presupune un dialog continuu, operatorul introducând succesiv datele
de intrare ca răspuns logic la întrebările afişate anterior pe ecran.
Mai mult, operatorul nu poate trece la următoarea întrebare, dacă dintr-o eroare
s-au introdus date incorecte sau a fost sărit un anumit răspuns. În aceste cazuri
programul de validare, aflat la baza dialogului om-calculator, va solicita
reintroducerea datei eronate sau o opţiune corespunzătoare pentru răspunsul lipsă.
Mesajele de eroare pot fi afişate fie imediat sub informaţia greşită, fie într-o zonă
prestabilită a ecranului (de exemplu, dreapta-sus) însoţite, la redarea pe display,
de o avertizare sonoră sau luminoasă (blinking, video-invers).
La proiectarea videoformatelor de intrare este necesar ca proiectantul să aibă
în vedere şi o serie de aspecte practice utile, menite să nu obosească operatorul,
să-i uşureze activitatea de culegere a datelor, cum sunt:
- afişarea pe ecran, la un moment dat, a unui volum redus de informaţii;
- afişarea, la un moment dat, a unei cereri de răspuns ce se referă la o singură
informaţie;
- scurtarea răspunsului dat de operator, prin folosirea abrevierilor şi a
codificărilor numerice;
187
 - utilizarea unor formate clare şi precise pentru afişare;
- evitarea cuvintelor şi a caracterelor dificile de citit sau înţeles;
- existenţa unor rutine speciale de autodocumentare (help);
- dialogul trebuie să fie astfel proiectat încât să permită corectarea imediată a
erorilor intervenite în executarea programului.
b). prin afişarea pe ecran a machetei de introducere a datelor de intrare
În acest caz macheta de introducere trebuie să reproducă în totalitate sau
simplificat documentul de intrare, să respectele toate cerinţele de proiectare
formulate, să folosească toate facilităţile oferite de o afişare video, cum sunt:
combinaţie plăcută, caldă de culori, sunet, defilarea imaginii, efecte speciale de
imagine, precum şi avertizări sonore sau de culoare pentru cazurile speciale.
În proiectarea videoformatelor de intrare, pot fi utilizate componente
specializate ale sistemelor de gestiune a bazelor de date (SGBD), cum ar fi de
exemplu: FoxBase, FoxPro, Oracle, Paradox precum şi programe specializate
scrise în diverse limbaje de programare.

8.4. Proiectarea sistemului de codificare

8.4.1. Definiţii, caracteristici

Necesitatea codificării informaţiei derivă din considerente de ordin practic

privind procesul de culegere, verificare, transmitere, prelucrare şi stocare a
informaţiei.
În cazul procesului de prelucrare automată a datelor, codificarea informaţiei
conduce la reducerea dimensiunii fişierelor de date, a timpului în fazele de
culegere, verificare, transmitere şi prelucrare a datelor, crează condiţii optime
pentru valorificarea, gruparea şi sintetizarea cât mai complexă a datelor, utilizând
facilităţile de prelucrare automată.

Operaţia de codificare constă în stabilirea unei corespondenţe biunivoce între

obiectele supuse codificării (bunurile materiale) şi simbolurile (codurile) de
reprezentare a acestora, obţinute cu ajutorul unui limbaj de codificare.
Rezultatul codificării se concretizează într-un sistem de coduri.

Adeseori reuşita unei aplicaţii informatice, a unui sistem informatic în

ansamblul său, depinde de sistemul de codificare ales, de structura codului şi de
posibilităţile de grupare a informaţiilor pe care acesta le oferă.
Caracteristicile codurilor
• lungimea codului. Este dată de numărul de caractere prin care se descrie
codul respectiv.
• structura şi formatul codului. Se referă la semnificaţia fiecărui caracter din
structura codului. Formatul poate fi variabil sau fix.

188
 • capacitatea codului (Cc). Reflectă numărul maxim de combinări posibile
pentru codificarea elementelor mulţimii de interes ţinând seama de un format şi o
structură prestabilită. Cc se exprimă astfel:
Cc = 10N × 26A, unde:
10 - numărul de cifre (0-9)
26 - numărul de caractere (litere) ale alfabetului excluzând ş, ţ, î, â,ă
N - numărul de caractere numerice din structura codului
A - numărul de caractere alfabetice din structura codului.

Cerinţele (principiile) codificării datelor

Cu ocazia elaborării nomenclatoarelor de coduri trebuie să se ţină seama de o
serie de cerinţe care prin importanţa pe care o prezintă, sunt ridicate la rangul de
principii:
• unicitatea codurilor - codurile elaborate trebuie să ofere posibilitatea
identificării unice a oricărui element din mulţime. Unicitatea codului în cadrul
unei mulţimi codificate înseamnă că fiecărui element din mulţimea codificată îi va
fi asociat un cod care nu a mai fost asociat altui element din aceeaşi mulţime;
• conciziunea codurilor (minimalitatea) - codurile elaborate trebuie să fie
formate dintr-un număr cât mai redus de caractere, adică minimul necesar şi
suficient pentru a putea reprezenta prin coduri toate elementele mulţimii.
• stabilitatea codurilor - codurile elaborate trebuie să se menţină aceleaşi
pe o durată de timp cât mai îndelungată.
• semnificaţia codurilor - codurile elaborate trebuie să fie cât mai
semnificative (sugestive). În acest sens se impune folosirea unui limbaj de
codificare accesibil, astfel încât codificarea şi decodificarea informaţiei să se
realizeze cu uşurinţă. Dacă nu este îndeplinită această cerinţă, avem de a face cu
un sistem de codificare greoi, care poate constitui o sursă de erori permanentă în
introducerea datelor.
• operaţionalitatea codurilor - codurile elaborate trebuie să ofere facilităţi
cu privire la prelucrarea automată a datelor, manipularea datelor (codificare,
decodificare), sortare, interclasare etc. Structura codului trebuie să permită deci, în
procesul de prelucrare, sortarea şi formarea de grupe cu obiectele codificate, în
conformitate cu cerinţele utilizatorilor. Experienţa proiectantului şi colaborarea lui
cu utilizatorul pot asigura succesul în acest sens.
• flexibilitatea codurilor - nomenclatoarele de coduri trebuie astfel
elaborate încât să ofere posibilitatea adăugării sau excluderii de coduri fără a
afecta structura codurilor. Întreţinerea facilă a sistemului de coduri elaborat
reprezintă o activitate menită să asigure stabilitatea în timp şi posibilitatea de
extindere a sferei de cuprindere a acestuia. Stabilitatea derivă din necesitatea
utilizării informaţiilor codificate un timp mai îndelungat; de aceea, se impune ca
un cod, o dată stabilit, să aibă în vedere tendinţa de creştere a volumului de
189
informaţii, atât pe ansamblul colectivităţii, cât şi a subcolectivităţilor acesteia, în
scopul cuprinderii, pe un timp cât mai îndelungat, a tuturor informaţiilor ce
prezintă interes.
8.4.2. Clasificarea codurilor

Codurile pot fi clasificate în funcţie de mai multe criterii, cum sunt:

a). domeniul de referinţă
- coduri interne
- coduri externe
Codurile interne se referă la modul de codificare a datelor în memoria internă
sau pe purtătorii tehnici de informaţie.
Codurile externe sunt folosite de către utilizatori în diferite aplicaţii
informatice.
b) natura caracterelor ce intră în componenţa codului:
- coduri numerice - formate din secvenţe de numere naturale;
- coduri alfabetice - formate din caractere alfabetice;
- coduri alfanumerice - formate din caractere alfabetice şi numerice.
c) lungimea codurilor:
- coduri cu lungime fixă – care conţin acelaşi număr de caractere pentru toate
obiectele supuse codificării;
- coduri cu lungime variabilă – care nu conţin acelaşi număr de caractere
pentru toate obiectele supuse codificării.
În practică se preferă să se lucreze cu coduri de lungime fixă. De aceea
codurile de lungime variabilă vor fi convertite în coduri de lungime fixă prin
adăugarea de zerouri în faţa cifrei semnificative.
Exemplu:
coduri de lungime variabilă coduri de lungime fixă
1 0001
2 0002
3 0003

9 0009
10 0010
11 0011

99 0099
100 0100
101 0101

999 0999
1000 1000

d) posibilităţile de prelucrare existente:

- coduri elementare, care pot fi:

190
 - secvenţiale;
- secvenţiale cu formare de grupe;
- mnemonice;
- descriptive.
- coduri compuse, care pot fi:
- ierarhizate;
- juxtapuse;
- matriceale;
- binare.

Codurile secvenţiale se formează prin atribuirea unor numere în ordine

crescătoare elementelor de codificat. Se obţine astfel o corespondenţă între
mulţimea elementelor de codificat şi mulţimea numerelor naturale. Aceste coduri
pot avea lungime fixă sau lungime variabilă. Codurile secvenţiale au dezavantajul
că nu permit gruparea elementelor colectivităţii pe subcolectivităţi şi prelucrarea
corespunzătoare a acestora. Un exemplu elocvent în acest sens îl constituie
generatoarele de secvenţă sau atribuirea de coduri numerice strict crescătoare
elementelor supuse codificării (tabel 1).

Tabel 1
Nr. Crt. Denumirea elementelor Cod atribuit
1 ........ 0001
2 ........ 0002
3 ........ 0003

Codurile secvenţiale cu formare de grupe se bazează pe împărţirea elementelor

mulţimii de codificat în grupe, clase sau familii care, la rândul lor vor fi împărţite
în subgrupe, subsubgrupe. La nivelul grupelor, respectiv subgrupelor elementele
vor fi codificate în ordine secvenţială. În acest mod la nivelul fiecărei grupe,
subgrupe etc. vor rămâne coduri de rezervă.
Exemplu: Codificarea conturilor din planul de conturi.

191
 Avantajele acestui tip de coduri:
• sunt extrem de flexibile, în sensul că oferă posibilitatea adăugării de noi
coduri sau excluderii de coduri din cadrul nomenclatorului fără a afecta
caracteristica de grupare.
• oferă posibilitatea prelucrării automate a datelor cu obţinerea de totaluri la
nivelul fiecărei grupe, subgrupe etc.
Dezavantaj: comparativ cu codurile secvenţiale, codurile secvenţiale cu
formare de grupe se caracterizează printr-o dimensiune sporită.

Codurile mnemonice se formează prin prescurtarea denumirii elementulelor

mulţimii de codificat, astfel încât acestea să sugereze elementele corespunzătoare.
Exemplu:
PROF ROF - regulament de organizare şi funcţionare
CONF ROI - regulament de organizare internă
LECT
Avantaj: Codurile mnemonice sunt extrem de sugestive şi semnificative.
Grupa Coduri atribuite Sub- Codul Articol de Cod
de grupei grupa subgrupei materiale articol
materi
al
A 0001-0200 1 0001-0040 1 0001
2 0002
2 0041-0070 41 0041
42 0042
....
B 0201-0500 1 0201-0250 201 0201
202 0202
2 0251-0300 0251 0251

192
 Codurile descriptive îşi găsesc o largă utilizare în descrierea caracteristicilor
tehnico-constructive ale instalaţiilor, maşinilor, utilajelor.
Exemple:
PC-486 DACIA 1310
PC-586 DACIA 1410
HD-400 DACIA NOVA
Avantaj: aceste coduri sunt extrem de sugestive.

Codurile ierarhizate permit exprimarea relaţiilor ierarhice ce se stabilesc între

elementele unei structuri. Astfel, fiecărei trepte ierarhice i se atribuie una sau mai
multe cifre în funcţie de numărul elementelor componente imediat inferioare. Un
exemplu în acest sens este ilustrat în fig. 8.1.

Fig. 8.1

Cu ajutorul lor se codifică deci o serie de caracteristici ale elementelor mulţimii

de codificat între care există relaţii de ierarhizare / subordonare, deci relaţii de
incluziune.
Considerând mulţimea elementelor de codificat elementele structurii
organizatorice a unei unităţi, vom avea (fig 8.2):

193
 Fig. 8.2

Avantaj: oferă posibilitatea prelucrării automate a datelor cu obţinerea mai

multor grupe de totaluri.(pe ateliere, pe secţii şi pe întreprindere).

Codurile juxtapuse se formează prin alăturarea şi codificarea unor caracteristici

între care nu există nici o relaţie de subordonare. Modelul de formare a acestor
coduri este ilustrat în fig. 8.3.

Secţiune de plan
Obiectiv de investiţii
Beneficiar
Constructor

x xxx xxx xxx

Fig. 8.3

Alte exemple: codul numeric personal

codificarea fişelor tehnice în comerţul exterior

Codurile matriceale se formează prin asocierea elementelor unei matrici la

două însuşiri ale obiectului supus codificării, astfel încât permit caracterizarea a
două însuşiri ale unui element printr-o singură valoare a codului. Se referă în
special la caracteristicile tehnice ale unui obiect. Un exemplu privind formarea

194
unui cod matriceal este reprezentat de modul de dimensionare a produselor de
cherestea (tabelul 3).
Tabel 3
Lungime/ 1 2 3 4 5 6 7 8 9
Lăţime
(m)

0,10-0,20 1 2 3 4 5 6 7 8 9

0,21-0,30 11 12 13 14 15 16 17 18 19

0,31-0,40 21 22 23 24 25 26 27 28 29

0,41-0,50 31 32 33 34 35 36 37 38 39

Codurile binare constau în combinaţii posibile de cifre binare (0 şi 1) prin care

se pot codifica o serie de situaţii complexe. Un exemplu în acest sens îl constituie
codificarea stării civile:
0 0 0 - necăsătorit
1 1 0 - căsătorit
1 1 0 - casătorit fără copii
1 1 1 - căsătorit cu copii

În legătură cu codificarea datelor, o problemă deosebită o reprezintă

verificarea corectitudinii codului, în procesul de culegere, transmitere şi
prelucrare a datelor. De aceea, se impune găsirea unor metode de prevenire a
erorilor, metoda cel mai des folosită fiind cea a utilizării cifrei de control,
calculată în conformitate cu un algoritm prestabilit.

d) Etapele realizării unui sistem de codificare

Procesul de realizare a unui sistem de codificare cuprinde următoarea
succesiune logică de activităţi:
 identificarea (inventarierea) elementelor ce urmează a fi codificate
(stabilirea vocabularului de intrare);
 uniformizarea terminologiei şi precizarea denumirilor în vederea
elaborării nomenclatorului elementelor ce urmează a fi codificate (simbolurile de
reprezentare);
 analiza elementelor ce urmează a fi codificate, stabilirea
caracteristicilor acestora şi a relaţiilor de ierarhizare/subordonare, în vederea
identificării grupelor şi subgrupelor din cadrul unei colectivităţi; se estimează
numărul maxim de elemente din cadrul fiecărei grupe şi subgrupe şi evoluţia
probabilă a acestora;
 alegerea tipului de cod;
195
  estimarea capacităţii codurilor, stabilirea structurii şi dimensiunii
acestora;
 atribuirea codurilor elementelor mulţimii de codificat. Aceasta înseamnă
întocmirea nomenclatorului de coduri (alfabetul de ieşire) cu gruparea
elementelor în funcţie de tipul de cod ales;
 determinarea cifrei de control a fiecărui cod şi asocierea acesteia codului
respectiv (dacă este cazul);
 stabilirea unei modalităţi de întreţinere a nomenclatorului de coduri,
astfel încât pe măsura apariţiei de noi elemente neincluse în nomenclator, acestea
să fie codificate şi introduse în nomenclator.

Observaţie:
Pentru a putea fi codifcată efectiv, o mulţime de elemente trebuie mai întâi
ordonată prin introducerea unei relaţii de ordine. Se folosesc în acest scop
clasificări şi nomenclatoare.

Clasificarea reprezintă un procedeu ştiinţific de sistematizare a realităţii

obiective, prin care devine posibilă cunoaşterea proceselor şi fenomenelor.
Clasificarea realizează împărţirea conform unor criterii a unei mulţimi de
elemente de acelaşi tip în grupe (clase) de elemente, cu anumite caracteristici
diferite. Mulţimea caracteristicilor determină ierarhizarea elementelor pe mai
multe niveluri, sub formă de structuri arborescente, rezultând ierarhii de clase sau
tipuri. Caracteristicile se "moştenesc" de la un nivel la altul, astfel:
- prin substituţie: dacă clasa C2 de elemente este moştenită de la superclasa C1,
atunci asupra elementului de tip C2 se vor putea executa mai multe operaţii decât
asupra celui de tip C1;
- prin incluziune: o clasă C2 este o subclasă a lui C1, deci orice element de tip
C2 este în acelaşi timp şi un element de tip C1;
- prin restricţie, caz particular al incluziunii: o clasă C2 este o subclasă a clasei
C1, dacă conţine toate elementele de tip C1 ce satisfac o restricţie specificată;
- prin specializare: o clasă C2 este o subclasă a clasei C1, dacă elementele
aparţinând lui C2 aparţin şi lui C1, dar conţin un plus de informaţie specifică.

Elementele care au aceleaşi atribute şi acelaşi comportament pot fi

categorisite ca făcând parte din aceeaşi clasă.
O clasificare corectă presupune îndeplinirea următoarelor condiţii:
- fiecare clasă trebuie să conţină o parte din elementele mulţimii;
- nici un element nu poate aparţine la două clase diferite;
- asemănările pe baza cărora se grupează elementele dintr-o clasă sunt mai
importante decât deosebirile dintre ele;
- constituirea unei trepte de clasificare se face pe baza aceloraşi însuşiri.

196
 Nomenclatorul reprezintă lista elementelor unei mulţimi prezentate în ordinea
dată de o anumită clasificare.
Unei entităţi (unui element) care se include într-un nomenclator i se asociază:
- cod de identificare propriu;
- cod de identificare a entităţii (elementului) de pe nivelul ierarhic superior;
- denumirea entităţii (elementului) respective;
- coduri asociate din alte nomenclatoare (după caz).
La întocmirea nomenclatoarelor se caută eliminarea ambiguităţilor,
sinonimiilor şi asigurarea unicităţii înscrierii elementelor, prin determinarea
claselor de sinonime şi alegerea dominantei acestora.
Odată sistematizată mulţimea de entităţi (elemente), prin clasificări şi
nomenclatoare, ea poate fi supusă, în continuare, operaţiei de codificare propriu-
zise.

8.4.3. Metode de determinare a cifrei de control (cheia codurilor)

În procesul de vehiculare, de manipulare a codurilor acestea pot fi afectate

(modificate). Modificarea codurilor cu ocazia manipulării lor poate genera o serie
de neajunsuri, constituind o sursă de erori în prelucrarea ulterioară a datelor.
Exemplu: Dacă la introducerea de la tastatură a datelor referitoare la drepturile
şi reţinerile băneşti ale salariaţilor ar fi introdusă greşit marca unui salariat, atunci
toate drepturile şi reţinerile băneşti ar fi trecute în contul altui salariat.
Dacă într-o aplicaţie de gestiune a stocurilor de materii şi materiale pentru
producţie s-ar introduce de la tastatură codul unui material greşit, atunci din
stocul altui produs se va scădea cantitatea consumată, iar stocul consumat real ar
rămâne în baza de date neschimbat. Aplicaţia ar furniza informaţii eronate cu
privire la stocurile de materiale existente în magazie, managerii nu ar putea lua
decizii corecte cu privire la ce trebuie aprovizionat şi ce se poate produce, astfel
că producţia şi aprovizionarea ar fi influenţate în mod eronat.
Pentru preîntâmpinarea unor astfel de situaţii se recurge la determinarea cifrei
de control a codului (cheia codului).
În momentul elaborării nomenclatorului de coduri pe baza unui anumit
algoritm se determină pentru fiecare cod o cifră de control corespunzătoare care
va fi asociată codului respectiv şi-l va însoţi pe toată durata existenţei lui. Pe
parcurs, cu ocazia introducerii unui cod se va recurge la recalcularea cifrei de
control care va fi comparată cu cifra de control iniţială. În caz de diferenţă
înseamnă că acel cod este eronat şi printr-un mesaj pe monitor va fi atenţionat
operatorul care va reintroduce în mod corect codul.
Există o multitudine de metode de determinare a cifrei de control a codurilor.
1. Metoda mediei aritmetice ponderate
n

∑x y i i
rest
i =1
= cât + 197
N N
 xi – reprezintă şirul de caractere din care este format codul
yi – reprezintă un şir de ponderi prestabilit
N – reprezintă un număr prim prestabilit
Restul împărţirii va avea semnificaţia de cifră de control.

Exemplu: Fie codul 2138 (xi) şi şirul de ponderi 1234 (yi), N = 97.
1 × 2 + 2 ×1 + 3 × 3 + 4 × 8 45
=
97 97
Cifra de control 45 va fi ataşată codului: 213845.
Presupunem că la un moment dat se doreşte introducerea de la tastatură a
codului 2138 însă din greşeală se tastează 2188.
Se recalculează cifra de control.
1 × 2 + 2 ×1 + 3 × 8 + 4 × 8 60
=
97 97
Cifra de control veche (45) diferă de cifra de control nouă (60).
Metoda mediei aritmetice prezintă neajunsuri: în momentul în care cu ocazia
tastării codului s-ar greşi două sau mai multe caractere nu ar fi exclusă situaţia ca
prin compensare să rezulte acelaşi rest al împărţirii şi ca atare să nu fie identificate
erorile.
2. Metoda mediei geometrice ponderate
Diferă faţă de metoda mediei aritmetice ponderate prin faptul că şirul de
ponderi va fi format din puterile lui 2 (21, 22, 23, 24,…).
Metoda mediei geometrice ponderate înlătură neajunsul sesizat în cadrul
metodei mediei aritmetice ponderate.
3. Metoda conversiei restului împărţirii într-un caracter alfabetic
Metoda diferă de precedentele prin următoarele:
• numărul prim prestabilit luat în considerare va fi cel mai mare număr prim
din cadrul numărului de litere ale alfabetului de referinţă în care se va converti
restul excluzând ş,ţ,î,â,ă.
• restul împărţirii se va converti într-o literă corespunzătore cardinalităţii
acestuia.
Exemplu:
xi = 2138
yi = 1234
∑x yi i = 45
45 22
N = 23 ⇒ =1+
23 23
2138 V

198
 Avantajul metodei constă în faptul că întotdeauna cifra de control va fi formată
dintr-un singur caracter.

8.5. Proiectarea bazei de date

Proiectarea bazei de date este o activitate distinctă şi deosebit de importantă,

prin efectele ei în prelucrarea ulterioară a datelor, care se încadrează în
metodologia de proiectare a sistemelor informatice.
Corespunzător celor 3 niveluri de organizare a datelor în baze de date,
proiectarea bazei de date se va face la nivel logic, fizic şi virtual.

Activitatea de proiectare a bazei de date presupune realizarea următoarelor

activităţi:
a). Proiectarea structurii conceptuale a bazei de date :
b). Proiectarea structurii logice a bazei de date ;
c). Proiectarea structurii fizice a bazei de date ;
d). Alegerea sistemului de gestiune a bazei de date .

Aşadar, proiectarea unei baze de date înseamnă practic un proces de proiectare

a structurii conceptuale, logice şi fizice a acesteia. Acesta nu trebuie privit ca un
proces liniar de desfăşurare a activităţilor componente, deoarece în practică apar
frecvente situaţii când sunt necesare reveniri la activităţile anterioare de
proiectare. De exemplu, odată cu proiectarea structurii fizice pot apare cerinţe de
modificare în structura conceptuală a bazei de date.
În urma analizei sistemului existent au fost obţinute, aşa cum am văzut, modele
informaţionale, adică modele ale datelor şi prelucrărilor acestora în cadrul
sistemului. Aceste modele, numite modele conceptuale, sunt independente de
SGBD-ul ce va fi ales pentru implementarea lor.

Dacă ne referim la o bază de date relaţională, atunci ne reamintim că modelul

relaţional de baze de date cuprinde trei componente principale:
• Structura datelor ;
• Restricţii de integritate a datelor;
• Operatorii de prelucrare a datelor, prin operaţii din algebra relaţională sau
calculul relaţional.

De regulă relaţiile sunt reprezentate sub forma unor tabele bidimensionale în

care fiecare rând reprezintă un tuplu şi fiecare coloană reprezintă valorile
tuplurilor dintr-un domeniu dat al produsului cartezian.
În reprezentarea sub formă de tabel a unei relaţii, coloanelor şi, respectiv
domeniilor corespunzătoare lor li se asociază nume intitulate atribute.

199
 Observaţie:
Dacă ne reamintim că un atribut se mai numeşte câmp, că structura tabelei
memorează descrierea câmpurilor de date şi a relaţiilor dintre acestea, vom spune
că aritatea tabelei este dată de numărul de cîmpuri de date definite în structura
tabelei.

Mulţimea numelor de atribute ale unei relaţii se numeşte schemă relaţională.

Dacă relaţia numită R are atributele A1, A2, ... Ak , atunci schema relaţională se
notează R(A1, A2, ... Ak).
Practic, relaţia este o asociere stabilită între două sau mai multe câmpuri
comune care se găsesc în două tabele. O relaţie leagă astfel date aparent izolate.

Considerând două tabele, A şi B, relaţiile pot fi de mai multe feluri:

unu la unu (one-to-one ); În acest caz se cere ca valoarea câmpului cheie

dintr-o singură înregistrare a tabelei A să fie identică cu o singură valoare
corespondentă din câmpul asociat din tabela de legătură B. Cu alte cuvinte, fiecare
înregistrare din tabela A poate avea doar o singură înregistrare corespondentă în B
şi invers. Acest tip de relaţie este mai puţin utilizată, căci datele se pot afla, în
acest caz, într-o singură tabelă.

- unu la mulţi (one-to-many); În acest caz se cere unicitatea câmpului cheie

din tabela A, dar valorile lui să fie identice cu mai multe valori ale câmpului
asociat din tabela B. Cu alte cuvinte, o înregistrare din tabela A poate avea mai
multe înregistrări corespondente în tabela B, dar o înregistrare din B se potriveşte
cu o singură înregistrare din tabela A. Practic legătura se face între cheia primară
a tabelei de bază, A, şi cheile externe corespunzătoare din tabelele corelate.

- mulţi la mulţi (many-to-many). În acest caz nu există nici o relaţie unică

între câmpurile cheie ale tabelelor A şi B, fiecare dintre acestea conţinând valori
duplicat în cealaltă tabelă. Acest tip de relaţie este echivalenttă şi se poate
descompune în două relaţii de tip one-to-many. Relaţia este posibilă prin definirea
unei tabele noi, C, numită tabelă de joncţiune, a cărei cheie primară este formată
din cele două chei primare, devenite astfel chei externe ale celor două tabele care
trebuie corelate.

După toate acestea urmează, firesc, încărcarea bazei de date, prin încărcarea
tabelelor componente una câte una, în ordinea impusă de relaţiile stabilite între
acestea.
Restricţiile de integritate definite nu ne vor lăsa să greşim, în sensul că nu vom
putea completa de exemplu un contract dacă nu am introdus mai întâi datele în
nomenclatoarele existente de Produse şi respectiv Clienţi.

200
 8.5.1. Proiectarea structurii conceptuale a bazei de date

Este o activitate realizată de către echipa de proiectare a sistemului de

administrare a bazei de date, care pleacă de la colecţiile de date stabilite la nivel
global în etapa de concepere a sistemului informatic (proiectare de ansamblu),
când s-a schiţat şi un prim model conceptual de ansamblu al datelor.
Proiectarea structurii conceptuale a bazei de date presupune realizarea
următoarelor activităţi specifice:
a). Definirea detaliată a colecţiilor de date
b). Determinarea legăturilor dintre colecţii
c). Definirea modelului conceptual de ansamblu al datelor
d). Testarea modelului conceptual de ansamblu al datelor
e). Transpunerea modelului conceptual

Toate aceste activităţi pornesc de la Modelul Entitate Asociere, realizat în urma

activităţii de studiu şi analiză a sistemului obiect şi au fost prezentate, sub formă
de concepte şi de reguli în capitolul 3, intitulat Modelarea conceptuală a datelor.

Definirea detaliată a colecţiilor de date presupune analiza colecţiilor de date şi

normalizarea lor pentru a asigura creşterea performanţelor în stocarea,
actualizarea şi prelucrarea datelor. Definitivarea colecţiilor de date se face prin
descompunerea acestora în colecţii de date simple, în funcţie de descompunerea
obiectelor compuse în obiecte simple şi păstrând, dacă este cazul, o redundanţă
minimă şi controlată a datelor. De asemenea, se urmăreşte descrierea cât mai
precisă a caracteristicilor obiectelor identificate. Astfel, pentru un obiect simplu
caracteristicile vor fi cele care îl identifică şi îl descriu în modelul entitate –
asociere. Pentru un obiect compus, caracteristicile vor fi cele de identificare a
acestuia şi cele de descriere a obiectelor simple, legate de cele compuse.

Definirea modelului conceptual de ansamblu al datelor se realizează prin

integrarea tuturor entităţilor definite în Modelul Entitate Asociere prin intermediul
relaţiilor determinate într-un model unic, de ansamblu al datelor din baza de date.
Definirea modelului conceptual de ansamblu al datelor prezintă o serie de
particularităţi, în funcţie de tipul modelului de date pe care urmărim să-l obţinem.
Astfel, dacă în cazul modelelor de tip ierarhic şi reţea pentru definirea
modelului conceptual de ansamblu se reunesc toate entităţile şi relaţiile stabilite în
etapele anterioare, în cazul modelului relaţional se proiectează tabelele de date
care alcătuiesc baza de date şi prin care se reprezintă atât entităţile cât şi relaţiile
dintre acestea. Regulile de trecere de la Modelul Entitate Asociere la modelul
relaţional au fost prezentate în capitolul 3.7 intitulat Modelul relaţional.

201
 Proiectarea tabelelor de date ale unei baze de date relaţională se poate realiza
într-o abordare top-down sau într-o abordare bottom-up.
Proiectarea tabelelor de date în abordarea top-down se realizează prin definirea
unei tabele în care atributele devin coloane, iar liniile sunt realizări ale relaţiei.
Prin normalizare se pot obţine mai multe tabele de date din tabela iniţială. În acest
sens se recomandă tratarea diferenţiată a reprezentării fiecărui tip de relaţie.
• Reprezentarea relaţiei de tip 1:1
Dacă relaţia dintre două entităţi este totală (ambii membri sunt obligatorii),
atributele celor două entităţi se pot trece în aceeaşi tabelă. Relaţia de tip 1:1 e
reprezentată în mod implicit prin prezenţa atributelor ambelor entităţi într-o
singură tabelă. Nu este deci necesară introducerea unei tabele suplimentare pentru
explicitarea relaţiei.
Dacă însă relaţia este parţială astfel că numai unul din membrii relaţiei este
obligatoriu, atunci există posibilitatea definirii a două tabele corespunzătoare celor
două entităţi sau a unei singure tabele care va prezenta însă valori nule pentru
unele atribute.
Dacă relaţia e parţială astfel că ambii membrii ai relaţiei nu sunt obligatorii,
relaţia trebuie să fie reprezentată printr-o tabelă separată. Sunt necesare deci trei
tabele.
• Reprezentarea relaţiei de tip 1:N
Dacă partea cu mulţi a relaţiei este obligatorie, atunci reprezentarea relaţiei se
face prin două tabele.
• Reprezentarea relaţiei de tip M:N
Se realizează prin trei tabele: două pentru entităţile aflate în relaţie şi una
pentru relaţia M:N. Practic această relaţie se descompune în două relaţii de tip : 1
la N şi N : 1. Apoi se trece la completarea tabelelor cu noi atribute, astfel încât
tabelele să rămână normalizate. Dacă există mai multe posibilităţi de a adăuga
atributul (la mai multe tabele) se va avea în vedere aceea în care se introduc cât
mai puţine valori nule.
Tabelele rezultate iniţial sunt apoi rafinate, validate şi transpuse în termenii
SGBD-ului ales. Există în acest sens o întreagă activitate de definire şi redefinire a
tabelelor unei baze de date pe baza unor principii riguros stabilite în cadrul
procedeului numit normalizarea bazei de date. După cum obiectul reprezentat
printr-o tabelă este simplu sau complex, tot astfel caracteristicile lui, reprezentate
prin câmpuri (atribute) vor fi simple sau complexe. De exemplu, atributele
asociate obiectelor cărţi din bibliotecă vor fi: cod, titlu, autor, Isbn, data apariţiei,
editura etc.
O tehnică de proiectare a modelului conceptual al bazei de date într-o
abordare top-down este tehnica celor cinci forme normale.
Conform acestei tehnici, atributele entităţilor definite se organizează într-o
singură tabelă sau în mai multe şi apoi se urmăreşte descompunerea acestora în
alte tabele, fără pierdere de informaţii şi în scopul eliminării anomaliilor de ordin
202
logic şi fizic. Se parcurg astfel o serie de etape de normalizare, prin care se trece
de la o formă normală la alta. Prin parcurgerea acestor etape, se ajunge în mod
succesiv să se amelioreze structura bazei de date, înlăturându-se treptat o serie de
neajunsuri şi asigurând facilităţi sporite în privinţa încărcării, actualizării şi
exploatării bazei de date.
Nu se impune întotdeauna parcurgerea tuturor etapelor de normalizare, dar în
mod obligatoriu prima forma normală este obligatorie.
Se ştie că o tabelă (relaţie) este într-o formă normală dacă satisface anumite
restricţii. Necesitatea normalizarii progresive este dată de faptul că anumite relaţii
pot genera o serie de situaţii nedorite, aşa-numitele "anomalii de actualizare", cum
sunt: anomalia de adăugare, anomalia de modificare.

Anomalia de ştergere rezultă din faptul că ştergând un tuplu al unei relaţii,

odată cu ştergerea anumitor informaţii se pierd şi informatiile utile, existente în
tuplul respectiv.

Anomalia de adăugare rezultă din faptul ca nu pot fi incluse noi informaţii

într-o relaţie deoarece nu se cunosc şi alte informaţii cerute pentru adăugarea unui
nou tuplu la acea relaţie, în principal valorile pentru atributele din cheie.

Anomalia de modificare rezultă din faptul că e dificil de modificat o valoare a

unui atribut atunci când ea apare în mai mult decât într-un tuplu al relaţiei.

Anomaliile de actualizare apar nu numai la modelul relaţional, ci şi la celelalte

modele de date (ierarhice şi reţea) precum şi la fişierele clasice. Pentru modelele
ierarhice şi reţea nu există însă o teorie a înlăturării anomaliilor de actualizare.
Toate aceste anomalii trebuie rezolvate în etapa de proiectare a structurii bazei
de date şi nu după ce baza de date a fost încărcată cu date reale şi au fost scrise
aplicaţii pentru ea. În acest context, teoria normalizării îşi propune înlăturarea
acestor anomalii în faza de proiectare a structurii bazei de date, ducând astfel la
performanţe de ordin logic, dar şi fizic cum sunt: ocuparea optimă a spaţiului de
memorie sau reducerea timpului de răspuns al sistemului.

Enunţăm, pe scurt , regulile normalizării unei baze de date relaţionale:

1. O bază de date este în FN1 dacă toate tabelele sale sunt în FN1.
O tabelă e în FN1 dacă toate atributele ei sunt elementare (nedecompozabile) şi
nu conţine grupuri repetitive. Deci, în această etapă, structurile de date
arborescente sau reţea devin tabele cu atribute elementare.
O tabela în FN1 prezintă însă o serie de anomalii cum ar fi: anomalii în
modificarea unor elemente din tupluri datorită necesităţii modificării aceloraşi
elemente de mai multe ori; anomalii la ştergerea unor tupluri deoarece se distrug
raporturile existente între anumite relaţii. Deasemenea, într-o tabelă în FN1 pot să
203
apară aceleaşi date de mai multe ori. De aceea este necesară eliminarea
redundanţei datelor prin trecerea la forma normală FN2.
2. O bază de date este în FN2 dacă toate tabelele sale componente sunt în
FN2.
O tabelă este în FN2 dacă şi numai dacă este în FN1 şi fiecare câmp noncheie
al tabelei este dependent funcţional direct şi complet de câmpul cheie al tabelei.
Se ştie că un atribut B al unei relaţii depinde în mod funcţional de atributul A al
aceleiaşi relaţii dacă în orice moment fiecărei valori a lui A îi corespunde o
valoare a lui B. Dependenţa funcţională este completă sau parţială.
Un atribut sau un ansamblu de atribute B din cadrul unei relaţii este dependent
funcţional complet de un ansamblu de atribute A ale aceleiaşi relaţii, dacă B este
dependent funcţional complet de întreg ansamblul A de atribute şi nu numai de un
atribut din ansamblul A.
Un atribut B e dependent funcţional parţial de un ansamblu de atribute A dacă
e dependent funcţional de un atribut din ansamblul A.
În acest context proiectantul bazei de date relaţionale are sarcina de a identifica
dependenţele funcţionale dintre atributele tabelului şi a asigura dependenţa
funcţională completă între atributele noncheie şi atributele cheie din cadrul
fiecărui tabel. Acest lucru va determina proiectarea a două sau mai multe tabele,
eliminând astfel anomaliile la modificarea unor valori şi repetarea unor valori.
Toate acestea au ca efect utilizarea raţională a memoriei externe şi chiar reducerea
timpului de întreţinere a bazei de date, protejarea acesteia de ştergerea nedorită a
unor informaţii.
Cu toate acestea o tabelă în FN2 prezintă încă o serie de anomalii la crearea şi
exploatarea bazei de date din cauza dependenţelor tranzitive a atributelor noncheie
faţă de cheia relaţiei, motiv pentru care este necesară trecerea ei în forma normală
următoare.
3. O bază de date este în FN3 dacă toate tabelele ce o compun sunt în FN3.
O tabelă este în FN3 dacă fiecare atribut noncheie al tabelei depinde în mod
netranzitiv de cheia tabelei.
Fie A,B,C, trei atribute din cadrul unei tabele unde A e atribut cheie. Dacă B
depinde de A şi C depinde de B, spunem că C se află în dependenţă tranzitivă de
A. Asemenea dependenţe nu sunt acceptate şi se înlătură prin proiectarea a două
tabele care conţin : A B şi respectiv B C.
O tabelă în FN3 prezintă însă anomalii de actualizare, motiv pentru care se
impune trecerea în forma normală patru.
4. O bază de date este în FN4 dacă şi numai dacă este în FN3 şi nu conţine
două sau mai multe dependenţe multivaloare.
Acest neajuns se poate înlătura numai prin realizarea unei noi dependenţe de
tip "joncţiune". Dependenţa joncţiune este forma cea mai generală de dependenţă;
ea conduce la obţinerea unor tabele prin operaţii de proiecţie şi joncţiune. O tabelă

204
R(A,B,C) menţine dependenţa joncţiune A(AB,AC) dacă şi numai dacă R menţine
dependenţele multivaloare A->B/C.
Înseamnă deci că dependenţa multivaloare reprezintă un caz special al
dependenţei joncţiune.
5. O relaţie e în FN5 dacă şi numai dacă fiecare joncţiune e generată printr-
un candidat cheie a lui R şi e în FN4.
Testarea modelului conceptual de ansamblu al datelor se face pe baza
criteriilor formulate pentru validarea oricărui model conceptual al datelor şi poate
duce la adăugarea entităţilor şi/ sau a corelaţiilor necesare, la verificarea relaţiilor
dintre entităţi în vederea regăsirii informaţiilor necesare la un moment dat din mai
multe entităţi precum şi a editării unor situaţii complexe, cu date agregate, a
actualizării concomitente a datelor redundante acceptate etc.
Prin verificarea modelului se poate ajunge la rearanjarea unor componente ale
modelului, la adăugarea unor relaţii suplimentare care înseamnă practic
introducerea de noi entităţi. Dacă se vor introduce în modelul de ansamblu al
datelor toate legăturile posibile, se va ajunge la o creştere nejustificată a
complexităţii logice a modelului şi, pe această bază, la creşterea timpului de
realizare a proiectului. De aceea, introducerea unor noi entităţi sau relaţii în
modelul conceptual de ansamblu trebuie făcută cu multă atenţie.
Transpunerea modelului conceptual se face în termenii unui anumit SGBD şi
descrierea structurii sale în limbajul corespunzător acestui SGBD.
Modelul conceptual de ansamblu al datelor este un model de ansamblu al
datelor independent de instrumentul soft (SGBD) şi de aceea se va concretiza în
structură în mod diferit, funcţie de facilităţile tehnice oferite de SGBD, în special
de modalităţile de implementare a diferitelor tipuri de relaţii şi date.
Descrierea bazei de date se face în limbajul de care dispune SGBD-ul ales.
Rezultatul final al descrierii structurii bazei de date îl constituie schema bazei de
date.
Concluzii cu privire la proiectarea structurii conceptuale a bazei de date:
a). Proiectarea structurii conceptuale a bazei de date se realizează de regulă
într-o abordare top-down. Se pleacă de la un prim model conceptual de ansamblu,
realizat în etapa de concepere a sistemului informatic la nivel global, care în paşi
succesivi este realizat, detaliat şi corectat, până la obţinerea structurii conceptuale
a bazei de date. Pentru modelul relaţional al datelor este posibilă şi o abordare
bottom-up de proiectare, care porneşte de la nivelul logic de detaliu (atribute) şi
ajunge la o sinteză, abordare mai puţin utilizată.

b). Proiectarea structurii conceptuale are la bază o modelare a datelor relativ

independentă de aplicaţii, cu alte cuvinte nu este orientată exclusiv pe aplicaţii,
dar nici nu este complet independentă de acestea. Se ştie că modelarea orientată
pe aplicaţii complică artificial structura datelor şi oferă posibilităţi scăzute de
adaptare la noi cerinţe informaţionale, în timp ce modelarea independentă de
205
aplicaţii presupune o analiză complexă, consumatoare de resurse şi de timp, iar
aplicaţiile nu pot fi dezvoltate decât după detalierea conţinutului bazei de date.

c). Proiectarea structurii conceptuale a bazelor de date are la bază o modelare a

datelor independentă de instrumentul informatic de implementare (SGBD).
Modelarea datelor orientate spre conceptele proprii unui anumit SGBD prezintă o
serie de dezavantaje, cum sunt : schimbarea SGBD-ului presupune reproiectarea
bazei de date; conceptele tehnice ale SGBD-ului pot influenţa negativ activitatea
de modelare a datelor prin restricţiile lor specifice care pot încuraja sau descuraja
anumite reprezentări; pornind de la facilităţile unui SGBD, utilizatorul
neinformatician, care nu e specializat în SGBD-uri nu îşi poate exprima cerinţele
în deplină cunoştinţă de cauză.

8.5.2. Proiectarea structurii logice a bazei de date

Structura logică a bazei de date reprezintă forma sub care apare structura
conceptuală a bazei de date pentru un utilizator oarecare.
Programele de aplicaţie operează asupra elementelor structurii conceptuale prin
intermediul structurii logice, având acces doar la acele elemente ale structurii
conceptuale care sunt incluse în structura logică.
În general elementele care compun structura logică sunt similare celor care
compun structura conceptuală, totuşi depind de tipul de SGBD utilizat.
De regulă, fiecărei entităţi de grup identificate în analiza datelor şi a
prelucrărilor lor i se asociază iniţial câte o tabelă, definită prin caracteristicile ei.
În această etapă se denumesc tabelele componente ale bazei de date, se
defineşte practic structura logică a fiecărei tabele, se descriu relaţiile dintre ele şi
se stabilesc restricţiile de integritate a acestora. Numele dat tabelelor e bine să
sugereze conţinutul acestora. Pentru fiecare atribut din structură (câmp de date) se
specifică elementele de caracterizare, şi anume: tipul, lungimea, eventuale
restricţii privind domeniul valorilor admise sau corelaţiile implicate, rolul de
atribut non-cheie sau atribut cheie şi tipul acesteia (cheie primară, cheie externă,
cheie candidat). De exemplu, caracteristicile (atributele) asociate obiectelor
ANGAJAŢI ar putea fi: cod numeric personal (câmp numeric din 13 caractere, cu
o structură bine stabilită, ale cărei componente vor putea fi verificate la
introducere); nume angajat (câmp alfanumeric din 30 caractere); cod
compartiment (câmp numeric din 3 caractere); cod funcţie (câmp numeric format
din 4 caractere); salariu tarifar de încadrare (câmp numeric format din 9
caractere); data încadrării (câmp de tip dată calendaristică - 8 caractere); adresa
(câmp alfanumeric din 30 caractere).
Se poate spune că prin separarea nivelului logic de nivelul conceptual se separă
practic funcţia de administrare de funcţia de utilizare – exploatare a bazei de date.

206
 8.5.3. Proiectarea structurii fizice a bazei de date

Se ştie că structura conceptuală a bazei de date îmbracă diferite forme de

reprezentare: liniară, arborescentă, reţea, relaţională. Memorarea datelor pe un
suport fizic îmbracă însă numai forma unei structuri liniare. De aceea se pune
problema liniarizării structurii virtuale (conceptuale).
Metoda de liniarizare a structurii virtuale este specifică diferitelor SGBD-uri
utilizate. Astfel, unele SGBD-uri utilizează pentru realizarea structurii fizice
metode tipice de organizare a datelor folosite în cadrul sistemelor de operare
gazdă, altele utilizează metode proprii de organizare a datelor, independente de
cele folosite în cadrul sistemului de operare gazdă.
Această din urmă grupă de SGBD-uri depinde astfel mai puţin de sistemele de
operare gazdă, ceea ce le oferă o portabilitate sporită în comparaţie cu celelalte.

Principalele activităţi abordate în cadrul acestei faze sunt:

a. proiectarea machetelor de stocare a datelor
b. definirea caracteristicilor fizice la nivelul fişierelor bazei de date
c. calculul necesarului de suport tehnic de date

Toate acestea au însă o strânsă legătură cu SGBD-ul utilizat. De aceea alegerea

sistemului de gestiune a bazei de date reprezintă o problemă deosebit de
importantă în proiectarea unui sistem informatic. Pentru aceasta e necesară
parcurgerea următoarelor etape:
- stabilirea cerinţelor beneficiarului şi studiul acestora în ceea ce priveşte:
tipurile de structuri de date, timpul de răspuns cerut, metodele de acces,
confidenţialitatea datelor, tipul aplicaţiilor, obiectivele generale ale sistemului ;
- stabilirea criteriilor de alegere a unui SGBD din cadrul celor existente, în
funcţie de cerinţele beneficiarului.
- inventarierea SGBD-urilor existente, capabile să satisfacă cerinţele
prestabilite ale beneficiarului sistemului şi alegerea unui SGBD corespunzător.
În aceste condiţii alegerea sistemului de gestiune a bazelor de date se face pe
baza unor criterii riguroase, cum sunt:
• Cerinţele utilizatorilor, în legătură cu tipul de aplicaţii solicitate, timpul de
răspuns al sistemului, securitatea datelor, confidenţialitatea lor, uşurinţa de
utilizare, etc. E posibil uneori ca utilizatorul să impună chiar el un anume SGBD.
• Necesităţi de ordin tehnic, legate de portabilitatea colecţiilor de date, a
programelor şi a SGBD-ului ales pe diverse sisteme de calcul, facilităţi de
încărcare, de întreţinere şi de exploatare curentă a bazei de date.
Se ştie că, pentru realizarea unor programe portabile este necesar ca
programele să conţină cât mai puţine elemente legate de echipament, iar acele
părţi de program ce presupun elemente legate de echipament să fie izolate atât
funcţional cât şi fizic de celelalte părţi ale programului. Se recomandă în acest caz
207
ca programul să fie organizat în două părţi : un program principal independent de
echipament şi un program care conţine elemente dependente de echipament. La
trecerea de pe un sistem pe altul se va proceda doar la rescrierea subprogramelor
dependente, în funcţie de noul echipament.
Portabilitatea datelor se referă la posibilitatea de a folosi o serie de date
utilizate în cadrul unui sistem informatic de către un alt sistem informatic, deci
posibilitatea integrării fişierelor deja existente în cadrul unui alt sistem.
• Cerinţe de ordin economic, legate de încadrarea în totalul resurselor alocate
pentru realizarea noului sistem informatic, cum sunt cele financiare, de personal şi
de timp.
• Costul sistemului dat de timpul de ocupare a unităţii centrale, costul de
întreţinere şi dezvoltare al sistemului, resursele hardware imobilizate, costul de
adaptare şi trecere pe alt sistem de calcul, costul documentaţiei etc.
• Protecţia şi securitatea datelor din baza de date.
• Specificul aplicaţiei. Se ştie că programele sunt orientate pe aplicaţii, cum
sunt: programarea şi urmărirea producţiei, aprovizionare-desfacere, optimizări,
prognoze etc.
• Timpul şi costul pentru instruirea personalului care să utilizeze SGBD-ul şi
aplicaţia realizată
• Facilităţe de implementare, de întreţinere, exploatare a bazei de date.
Toate acestea ţin de modalitatea de descriere a datelor, de tehnicile de
organizare şi regăsire a datelor care să permită accesul rapid la acestea, timpul
pentru actualizare şi interogare, editarea operativă a situaţiilor solicitate,
posibilitatea de utilizare a unor programe de aplicaţie, programe de validare a
datelor, de actualizare a bazei de date, rutine statistice, rutine de sortare, rutine de
prezentare grafică a ieşirilor etc.
• Analiza comparativă a SGBD-ului ales cu altele existente, în funcţie de
principalele lor caracteristeici;
• Alegerea propriu-zisă a SGBD-ului care urmează să fie utilizat şi eventual
achiziţionat (ceea ce presupune cheltuieli pentru licenţa – dreptul de folosire – a
produsului respectiv).
Aceste criterii pot fi asociate cu altele, cum sunt: mentenanţa sistemului,
facilităţile de administrare a bazei de date, calitatea documentaţiei oferite de
proiectant, asistenţă în implementara sistemului, pregătirea utilizatorilor etc.

Se poate aprecia astfel că realizarea proiectării fizice concretizează

armonizarea datelor de intrare cu posibilităţile tehnice de prelucrare în raport
direct cu cerinţele informaţionale. De calitatea soluţiei obţinută în cadrul
proiectării logice depinde calitatea soluţiei tehnice şi implicit, calitatea proiectării
bazei de date.

8.6. Proiectarea interfeţei

208
 Un element deosebit de important al oricărei aplicaţii informatice este, pe
lângă capacitatea ei de a gestiona cât mai bine toate cerinţele de prelucrare a
datelor, interfaţa cu utilizatorul sau modul cum comunică aplicaţia proiectată cu
utilizatorul nespecialist în informatică .
În acest sens e necesar ca proiectantul să realizeze o interfaţă prietenoasă,
plăcută şi unitară, pentru a uşura munca utilizatorului.
Avem în vedere două aspecte importante ale interfeţei unei aplicaţii:
• caracteristicile vizuale ale interfeţei
• comportamentul interfeţei ca răspuns la acţiunea utilizatorului.
Aceste două caracteristici sunt puternic intercondiţionate. Astfel, multe acţiuni
ale utilizatorului sunt dictate de aspectul vizual al interfeţei; de asemenea, acţiuni
similare trebuie să fie reprezentate vizual în aceeaşi manieră.
În această etapă beneficiarul unei aplicaţii proiectate de o echipă de
informaticieni poate să ceară şi să aprecieze calitatea interfeţei proiectate funcţie
de nişte cerinţe minimale pe care aceasta trebuie să le îndeplinească. Practic,
interfaţa aplicaţiei reprezintă posibilitatea utilizatorului de a comunica direct cu
aceasta, deci de a înţelege cerinţele aplicaţiei în fiecare moment şi modalitatea în
care trebuie să-i răspundă. De reuşita acestui dialog permanent depinde în mare
măsură succesul execuţiei aplicaţiei, a corectitudinii datelor furnizate.

În acest sens interfaţa grafică trebuie să fie :

o Consistentă: Aceasta înseamnă că pentru o anumită operaţie să se
folosească acelaşi obiect vizual. Accesul la operaţii similare să se face deci prin
aceleaşi acţiuni ale utilizatorului (mouse, tastatură) şi folosind acelaşi obiect
vizual.
o Intuitivă: Interfaţa să fie sugestivă, să poată fi intuită chiar fără
documentaţie sau cursuri de instruire.
o Extensibilă: Aceasta înseamnă că ea trebuie să fie adaptabilă la noi
echipamente hard (de exemplu monitoare cu rezoluţie mai mare);
o Atractivă: Aceasta înseamnă că interfaţa trebuie să aibă caracteristici
estetice care să atragă utilizatorul, să-i facă plăcere să comunice cu ea. O interfaţă
aglomerată va îndepărta utilizatorul.
o Uşor de utilizat: Aceasta înseamnă că operaţiile simple trebuie să se
realizeze prin acţiuni simple ale utilizatorului. Operaţiile complexe trebuie să se
realizeze printr-o succesiune de acţiuni simple ale utilizatorului.
o Uşor de învăţat: Aceasta înseamnă că orice acţiune utilizator trebuie să fie
uşor de realizat. Experienţa acumulată în învăţarea unor acţiuni să poată fi folosită
la învăţarea altor acţiuni.
Aceste elemente definitorii ale interfeţei utilizator sunt rezultatul a 10 principii
(cerinţe) de proiectare a interfeţelor utilizator.
Aceste principii sunt prezentate adeseori ca “cele 10 porunci”:
209
 (1) Utilizatorul (U) controlează programul: U simte că el controlează
programul, şi nu invers (programul îl dirijează pe el)
Această cerinţă este caracterizată de rolul activ al utilizatorului,
personalizarea mediului de lucru, anumite caracteristici ale aplicaţiei
(programului). Rolul activ al utilizatorului înseamnă în special că:
• Utilizatorul iniţiază acţiuni ;
• Utilizatorul conduce aplicaţia: calculatorul doar execută comenzile
utilizatorului şi nu invers.
Personalizarea mediului de lucru ţine de caracteristicile personale ale
utilizatorului uman. Oamenii au preferinţe extrem de diverse, iar o interfaţă
utilizator bună trebuie să permită utilizatorului să se simtă cât mai comod. Între
aspectele de interfaţă supuse personalizării amintim fonturile, stilul formatării,
culorile, etc.
Caracteristicile programului pe care se sprijină această calitate se referă la:
• interactivitate
• reacţie (răspuns) la fiecare acţiune a utilizatorului
• flexibilitate
Regimul de lucru modal este prin excelenţă unul imperativ (calculatorul cere
utilizatorului să facă o anumită acţiune, aşteptând răspunsul acestuia, deci raportul
de forţe se schimbă: calculatorul devine activ, iar utilizatorul devine reactiv).
Se recomandă ca aplicaţiile să fie cât mai puţin modale, în sensul că utilizatorul
să se simtă cât mai liber (în sensul de a nu se simţi dirijat) în ceea ce face. În cazul
când se folosesc ferestre modale, integrarea lor în aplicaţie trebuie să fie naturală.
Deschiderea unei astfel de ferestre trebuie să fie rezultat direct al unei acţiuni
explicite a utilizatorului; în plus, acesta trebuie să o poată oricând abandona,
revenind la rolul său eminamente activ.

(2) Utilizatorul manipulează direct informaţia, cu alte cuvinte, U trebuie să

poată opera direct cu reprezentarea pe ecran a informaţiei. În acest fel, el poate
constata direct relaţia cauză-efect între acţiunile sale (efectuate prin intermediul
interfeţei) şi rezultatul acestora (modul în care programul reacţionează la acţiunile
sale).
Informaţia trebuie reprezentată în interfaţa utilizator într-o manieră cât mai
naturală. Astfel, fereastra, elementul esenţial al interfeţei utilizator în Windows,
este utilizat şi în cadrul interfeţelor cu utilizatorul a aplicaţiilor informatice. Într-o
fereastră, informaţia este reprezentată într-o formă cât mai naturală, în special prin
text. Faptul că de multe ori elementul primar, textul, este înglobat sau înlocuit de
obiecte vizuale mai sugestive nu face decât să uşureze capacitatea de percepţie şi
de acţiune a utilizatorului.
În aceste situaţii, informaţia cu care utilizatorul operează este reprezentată într-
o manieră naturală, iar acţiunea acestuia asupra interfeţei se realizează prin
210
comenzi (acţiuni) foarte simple. Fiecare acţiune (click sau mutare mouse)
provoacă o modificare în poziţia obiectului sau conţinutului informaţional al
acestuia.
Pentru satisfacerea acestei cerinţe, interfaţa utilizator trebuie să ofere
utilizatorului o manieră directă şi intuitivă de comunicare.

(3) Consistenţa.
Această proprietate a interfeţei utilizator permite utilizatorului să înveţe rapid
utilizarea unor noi aplicaţii, prin folosirea cunoştinţelor acumulate pe parcursul
învăţării şi utilizării altor aplicaţii Windows. Se obţine ceea ce se numeşte
stabilitate: interfaţa este familiară (chiar dacă este vorba de o nouă aplicaţie), iar
răspunsul aplicaţiei este previzibil (altfel spus, se mizează pe comportamentul
uniform al aplicaţiilor).
Putem identifica trei nivele la care se poate discuta consistenţa:
• consistenţă intra-aplicaţie
• consistenţă inter-aplicaţii
• consistenţă cu mediul/sistemul de operare
Consistenţa intra-aplicaţie (în interiorul aplicaţiei) statuează că operaţiile
(funcţiile) comune trebuie prezentate vizual prin folosirea unei mulţimi
consistente de comenzi şi interfeţe. De exemplu, pentru identificarea unei
înregistrări din oricare tabelă a bazei de date, să se deschidă aceleeaşi casetă de
dialog iar prescurtările folosite să fie asemănătoare şi sugestive în acelaşi timp.
Consistenţa inter-aplicaţii se referă la comportamentul similar al mai multor
aplicaţii atunci când utilizatorul iniţiază o aceeaşi acţiune. Spre exemplu
actualizarea unui fişier se face identic (ca acţiune utilizator), iar operaţia de
actualizare are nevoie de aceleaşi informaţii
Consistenţa cu sistemul/mediul de operare se realizează prin convenţiile de
interfaţă şi de interacţiune utilizator pe care sistemul de operare (Windows) le
impune. Trebuie accentuat aici rolul sistemului de operare în uniformizarea
interfeţei şi acţiunilor utilizator.
Orice nouă aplicaţie trebuie să se alinieze la standardele pe care sistemul de
operare le impune, iar efectul acestei constrângeri este benefic: utilizarea noului
produs va fi uşor de învăţat tocmai pentru că acesta respectă cerinţele mediului
sub care se execută. Nu este mai puţin adevărat că, la rândul lui, mediul de
execuţie pune la dispoziţia programatorului de aplicaţie majoritatea instrumentelor
de care acesta are nevoie pentru a realiza interfaţa.

(4) Claritate.
Această calitate a interfeţei utilizator poate fi discutată din trei puncte de
vedere: vizual, conceptual, lingvistic.
Claritatea vizuală a interfeţei este asigurată de elementele (obiectele) vizuale
care o compun. Acestea trebuie să fie sugestive, uşor de înţeles, ele reprezentând
211
în fapt o transpunere simplificată a unor obiecte reale. De asemenea, aranjarea
obiectelor vizuale pe ecran este importantă: ne referim aici la gruparea lor după
criteriul similarităţii comportamentului lor, care va uşura identificarea lor.
Claritatea conceptuală se caracterizează prin două atribute: simplu şi realist.
Simplitatea interfeţei înseamnă număr rezonabil de obiecte pe un ecran (pe o
fereastră). Caracterul realist al interfeţei se realizează prin similitudinile cu
obiectele reale (de exemplu, dacă o fereastră conţine un document - de exemplu o
factură - atunci obiectele care formează respectivul document trebuie să reproducă
cât se poate de exact aspectul acesteia).
Claritatea lingvistică se referă la textul care apare în interfaţă. Denumirile
opţiunilor de meniu, etichetele, mesajele, etc. trebuie să fie clare, neambigue, iar
exprimarea lor trebuie să folosească limba literară şi nu limbajul propriu
comunităţii informatice.

(5) Estetică
Interfaţa trebuie să atragă utilizatorul, să-i placă acestuia. Mediul vizual plăcut,
prietenos, contribuie la confortul utilizatorului şi la o mai bună înţelegere a
informaţiei prezentate. Nimic din ceea ce poate contribui la sporirea atributelor
estetice ale interfeţei nu trebuie neglijat - inclusiv recurgerea la serviciile unui
designer profesionist.
De asemenea, oricând este cazul, e bine ca utilizatorul să fie implicat în
proiectarea interfeţei. De multe ori lucruri care par evidente proiectantului sunt
ascunse pentru utilizator.

(6) Răspuns imediat la acţiunile utilizatorului

Această cerinţă contribuie la sporirea confortului utilizatorului şi impune ca
aplicaţia să confirme vizual că a preluat cererea utilizatorului şi că este în curs
execuţia acţiunii aferente cererii.
În unele situaţii, confirmarea este evidentă: spre exemplu, la iniţierea unei
cereri de adăugare de noi înregistrări într-un fişier pe ecran apare o casetă de
dialog şi utilizatorului i se cere să introducă informaţiile corespunzătoare.
În alte situaţii, confirmarea s-ar părea că nu este necesară: de exemplu când se
lansează o operaţie de prelucrare complexă într-un fişier mare sau când se
efectuează sortarea unui fişier cu zeci sau sute de mii de înregistrări. Este o părere
greşită, pentru că utilizatorul simplu ar putea crede (în lipsa afişării unei
informaţii privind starea operaţiei lansate de el) că sistemul s-a blocat (deoarece
interfaţa nu mai reacţionează la comenzile sale), sau, mai rău, că a efectuat o
operaţie interzisă ale cărei efecte pot fi catastrofale din punctul lui de vedere.
Când este vorba de acţiuni care durează mai mult, informaţia care trebuie
afişată ca răspuns la acţiunile utilizatorului trebuie să precizeze:
• starea (derularea) acţiunii în curs
• modul în care acţiunea poate fi suspendată sau abandonată.
212
 (7) Toleranţă la greşelile utilizatorului
Utilizatorul uman nu este o maşină, iar această cerinţă de toleranţă este cât se
poate de naturală. De multe ori însă, greşelile de operare pot avea efecte
irecuperabile. De exemplu, ştergerea unui fişier, efectuată din greşeală, sub
imperiul grabei, oboselii sau pur şi simplu din neatenţie. O astfel de greşeală are
efecte neplăcute asupra moralului utilizatorului, mai ales când nu există vreo
posibilitate de recuperare.
Când discutăm această cerinţă trebuie să plecăm de la premisa că utilizatorul
obişnuit poate face frecvent greşeli, mai ales la început, atât accidentale, cum ar fi
apăsarea neintenţionată a unei taste, cât şi de judecată. O bună interfaţă utilizator
trebuie să înţeleagă gama de erori potenţiale pe care utilizatorul este capabil să le
comită şi să aibă prevăzute posibilităţi de recuperare din astfel de situaţii nedorite.
Ea trebuie să atenţioneze utilizatorul în situaţiile (provocate prin comenzile pe
care acesta le dă) când starea aplicaţiei sau datele cu care acestea operează se pot
deteriora. De asemenea, o bună interfaţă utilizator are prevăzute proceduri de
recuperare din situaţiile de eroare şi, mai mult, face acţiunile reversibile.
Este un adevăr că învăţarea prin descoperire este una dintre principalele
modalităţi prin care se învaţă folosirea unei noi aplicaţii. Tocmai în faza de
învăţare numărul de greşeli pe care le face utilizatorul novice este mai mare. De
aceea poate că această observaţie are şi o utilitate: interfaţa să fie testată, în faza
de proiectare a acesteia, tocmai de către utilizatori novici, complet străini de
informatică şi de aplicaţia realizată.

(8) Atenţie acordată limitelor umane

Utilizatorul uman nu este o maşină, un automat. Pe lângă dispoziţia sufletească
schimbătoare, fiecare individ are o anumită capacitate de înţelegere, memorare şi
gândire. Cerinţa aceasta statuează că programul, aplicaţia, trebuie să ţină cont de
limitele umane, să le înţeleagă şi să le respecte. Acele aplicaţii care forţează
depăşirea limitelor umane normale nu au succes la publicul larg.
Cu alte cuvinte, aplicaţia nu trebuie să constrângă utilizatorul la:
• efectuarea de calcule manuale
• memorarea unor secvenţe lungi de comenzi sau operaţii pentru realizarea
unei acţiuni
• memorarea unor prescurtări criptografice pentru denumirile acţiunilor
Se recomandă ca toate opţiunile aplicaţiei să fie prezentate explicit, într-o
manieră ierarhică. Un rol important îl joacă, de asemenea, caracteristicile vizuale
ale interfeţei, având în vedere constatarea că recunoaşterea elementelor de
interfaţă este mai importantă decât memorarea acestora.

(9) Adaptare progresivă

213
 La proiectarea interfeţei utilizator trebuie găsit un echilibru între două criterii
contradictorii:
• maximizarea funcţionalităţii aplicaţiei şi
• minimizarea complexităţii aplicaţiei.
Adaptarea progresivă implică două aspecte:
• organizarea atentă a informaţiei din interfaţă, evitând aglomerarea acesteia
pe un singur ecran
• prezentarea fiecărei informaţii la momentul potrivit; când nu este nevoie
de ea, informaţia se ascunde.
O bună interfaţă va prezenta informaţia într-o manieră ierarhică. De exemplu,
informaţia de control (comenzile disponibile ale aplicaţiei) se înglobează, de
obicei, în meniuri.
Denumirile meniurilor trebuie să fie sugestive pentru gama de opţiuni grupate
în fiecare meniu.
În funcţie de contextul de utilizare, o parte dintre opţiunile unui meniu,
indisponibile la un moment dat, se pot ascunde sau inhiba. La proiectarea
meniurilor trebuie însă avut în vedere şi un alt aspect: sunt contraindicate prea
multe niveluri de submeniuri, deoarece utilizatorul este forţat să ţină minte prea
multe comenzi cu care ajunge la o anumită opţiune.
De regulă, comenzilor de meniu mai frecvent folosite li se asociază butoane,
tocmai în ideea ca accesarea acestor comenzi să se facă cât mai simplu.

(10) Metodologie
Regulile sau cerinţele enumerate sunt necesare, însă nu şi suficiente pentru
proiectarea interfeţei utilizator.

Atenţie!
Activitatea de proiectare a interfeţei trebuie să aibă în centrul ei utilizatorul.
Pe toată durata proiectării interfaţa trebuie gândită de pe poziţia utilizatorului şi
alături de acesta.

Astăzi, sistemele de dezvoltare rapidă de aplicaţii permit proiectarea rapidă a

interfeţelor - este bine ca acestea să fie realizate implicând direct utilizatorii
(cunoscuţi sau potenţiali) în realizarea primelor versiuni. În acest fel, utilizatorul
devine parte a procesului de proiectare, şi acest lucru poate contribui esenţial la o
mai bună receptare a aplicaţiei pe piaţă.

214
 9. REALIZAREA PROGRAMELOR
9.1. Definirea etapei, conţinut şi caracteristici

Realizarea programelor sau activitatea de programare este o etapă deosebit de

importantă în ciclul de viaţă al unui sistem informatic, chiar dacă denumirea ei nu
apare în clar menţionată, ci doar se subînţelege atunci când spunem realizarea
efectivă a sistemului sau construirea sistemului.
Activităţile care se desfăşoară în legătură cu elaborarea programelor pot fi
enumerate astfel:
a) Analiza şi însuşirea documentaţiei tehnice de realizare
b) Proiectarea programului
c) Programarea, codificarea sau scrierea propriu-zisă a programului
d) Testarea programului realizat
e) Realizarea documentaţiei corespunzătoare

a). Analiza şi însuşirea documentaţiei tehnice de realizare

Am văzut că încă din faza proiectării de ansamblu se realizează, utilizând
tehnica top-down, structurarea sistemului pe elemente componente – subsisteme –
şi a acestora în componentele specifice – aplicaţii informatice. Mergând mai
departe cu structurarea, pe nivelul 4 identificăm procedurile, ca elemente
componente ale aplicaţiilor informatice. Mai ştim că în cadrul unui sistem
informatic acestea pot fi: manuale, mecanizate sau complet automate.
În cadrul proiectării logice de detaliu se face descompunerea fiecărui subsistem
sau aplicaţie în proceduri, iar proiectarea şi descrierea acestora se realizează
practic în etapa proiectării tehnice de detaliu. Fiecare procedură va fi definită prin
caracteristicile sale:
- denumire, scop;
- funcţiuni realizate;
- intrări, ieşiri şi legături cu alte proceduri, aplicaţii, subsisteme sau sisteme;
- datele folosite;
- prelucrări, algoritmi de rezolvare, modele utilizate, reguli de validare;
- scheme funcţionale şi de prelucrare;
- modalităţi de intrare şi ieşire din procedură;
- locul în cadrul subsistemului ;
- mod de exploatare.
Toate aceste specificaţii tehnice sunt precizate în cadrul proiectului tehnic de
detaliu, pentru fiecare procedură în parte. Odată ce au fost definitivate tipurile de
proceduri, se trece la decuparea celor automate în unităţi de programe
independente, denumite module. Apare astfel în structura sistemului nivelul 5 de
detaliere, modulul.

215
 b). Proiectarea programului
Creşterea complexităţii programelor, diversitatea funcţiunilor pe care trebuie să
le realizeze acestea, cerinţele ridicate faţă de calitatea acestora, au impus
necesitatea abordării sistematice a activităţii de proiectare a programelor. Dacă în
etapa de proiectare se descrie soluţia sub forma unei reprezentări abstracte,
programarea va schimba această reprezentare într-o formă care poate fi executată
pe un calculator real. Cu alte cuvinte, proiectarea programului oferă o viziune din
exterior asupra componentelor programului, asigurând descompunerea acestuia în
module, subprograme sau proceduri independente, logica de înţănţuire a acestora,
corectitudinea descompunerii şi definirii lor.
Modularitatea, ca atribut general al oricărui sistem, permite ca funcţiile logice
să poată fi grupate şi apoi subgrupate cât mai independent, în module sau
proceduri automate ce vor fi concretizate apoi în programe sau module
independente.
Programarea modulară reprezintă un concept care permite efectuarea
programării pe module sau subprograme cu următoarele caracteristici:
- un singur punct de intrare;
- un singur punct de ieşire;
- îndeplinesc o funcţie perfect definită;
- sunt apelate printr-o instrucţiune sau interfaţă standard;
- oferă posibilitatea de compilare şi testare independentă.
Transferul datelor necesare fiecărui modul se realizează printr-un modul
monitor sau zonă comună de date.
Avantajele programării modulare pot fi:
- concepţia este uşoară, clară;
- descompunerea se face pe module funcţionale;
- scrierea şi testarea pe module este uşoară iar programatorii sunt mai
eficient utilizaţi;
- se facilitează exploatarea şi întreţinerea lor, dar şi a aplicaţiei sau
subsistemului care le conţine;
- timpul de realizare se poate aprecia mai bine şi se reduce considerabil.
O altă formă a programării, cea denumită programarea structurată presupune
existenţa unei concepţii bazate pe o schemă arborescentă a programelor, pe
blocuri sau componente, dublată de o structurare clară a datelor utilizate. Se
numeşte factorizare procesul de descompunere a programului într-o ierarhie de
module, obţinând astfel diagrama de structură a programului. Totdeauna va
exista, în cadrul unei astfel de structuri de programe, un modul central, aflat la
nivelul cel mai înalt şi o ierarhie de module funcţionale, între care se precizează
integral legăturile. În acest caz, proiectarea şi dezvoltarea modulelor, care au
aceleaşi caracteristici principale ca şi la programarea modulară, se face într-o

216
abordare top-down. Urmează apoi integrarea acestora, în mod treptat, pe măsura
realizării modulelor şi interfeţelor.
Un program are un grad mai ridicat de modularitate cu cât părţile sale
(modulele) sunt mai independente. O modularitate ridicată a programului se
obţine prin minimizarea relaţiilor între module şi maximizarea relaţiilor între
elementele modulului. Pentru minimizarea relaţiilor dintre module se utilizează
conceptul de cuplare, iar pentru maximizarea relaţiilor dintre elementele unui
modul conceptul de coeziune.

Cuplarea defineşte gradul de interconectare între module. Cu cât ea este mai

slabă, deci relaţiile dintre module sunt mai puţine, cu atât modularitatea
programului este mai mare. În realizarea unui program s-au identificat în literatura
de specialitate şase tipuri de cuplare şi anume:
- cuplare prin date – ceea ce înseamnă că toate comunicaţiile între module
se fac prin elemente de date;
- cuplare prin structură de date – atunci când comunicaţia între module
include un parametru care face referire la o structură de date;
- cuplare prin control – atunci când comunicaţia între module include un
parametru transmis de un modul prin care se controlează fluxul controlului din alt
modul;
- cuplare externă – atunci când comunicaţia între module se face printr-un
element de date declarat extern;
- cuplare prin zonă comună – atunci când comunicaţia între module se face
printr-o referinţă la o structură de date declarată extern;
- cuplare prin conţinut – atunci când comunicaţia între module se face
printr-o referinţă la conţinutul altui modul.

Coeziunea defineşte gradul de legătură funcţională între elementele

componente ale unui modul, înţelegând prin elemente componente: instrucţiuni,
un segment sau o parte din modul.
În mod normal, în proiectarea propriu-zisă a unui program se porneşte de la o
factorizare iniţială, reprezentată prin diagrama de structură a programului, care
pune în evidenţă modulele programului şi interfeţele dintre acestea. Aceasta va
avea un modul principal sau de control al aplicaţiei, care va apela modulele
imediat subordonate, acestea la rândul lor apelând alte module cărora le transmit
date şi de la care aşteaptă rezultate. Toate aceste apeluri sunt incluse în cadrul
modulelor în diferite structuri de decizie, iterative sau secvenţiale.
În funcţie de modul cum este realizată conexiunea între modulele unui program
putem avea:
• Conexiune normală sau secvenţială (fig. 9.1), când în modulul A există o
referinţă la modulul B, astfel încât B este un modul subordonat modulului A.

217
 A

Fig. 9.1.
B

•Conexiune prin flux de informaţii (fig. 9.2.) când modulul B este subordonat
modulului A de la care primeşte datele x şi y şi căruia îi transmite parametrul z.
A

x,y z Fig 9.2.

B

• Conexiune de tip iteraţie (fig 9.3) când referinţa la modul este inclusă într-o
buclă. Modulul B se execută în mod repetat prin apelarea sa de către modulul A.
A

Fig. 9.3.
B

• Conexiune de tip decizie (fig. 9.4) când referinţa la modul este inclusă într-o
structură de tip decizie. În funcţie de rezultatul unei decizii (a testării unei
condiţii) va fi apelat fie modulul B fie modulul G.

A Fig. 9.4

B G

c). Programarea sau codificarea programelor reprezintă activitatea prin care

se scriu efectiv programele sursă, utilizând un limbaj de programare. Un
program este o listă de instrucţiuni prin care se descrie un algoritm concret de
rezolvare a unei probleme date. El se poate constitui ca program, modul sau
procedură independentă. Scrierea programelor se face deci într-un limbaj de
programare. Adeseori acesta este impus (de beneficiar, de echipa de programatori,
de conjunctură), dar alteori el trebuie ales în etapa de proiectare tehnică. Funcţie
de modalitatea de structurare a datelor, de caracteristicile modelelor matematice
utilizate, de specificul problemei, de algoritmii de calcul ce trebuie descrişi, de
modalităţile de prezentare a situaţiilor de ieşire, se poate opta pentru limbajul de
programare care răspunde cel mai bine problematicii noastre.

218
 În această etapă se pune accent pe detalierea internă a componentelor, pe
asigurarea eficacităţii algoritmilor de prelucrare, pe optimizarea acestora.
Formularea corectă şi completă a algoritmului de rezolvare trebuie să fie urmată
de realizarea schemei logice a fiecărui modul în parte.
Se poate face apel la tehnici moderne de programare, la generatoare automate
de rapoarte, meniuri, formulare.
O proiectare structurată, modulară a programului va duce şi la o structură
modulară a programului efectiv obţinut.

d). Testarea programelor reprezintă o activitate importantă, ce poate fi

realizată atât de fiecare programator, cât şi de personal specializat, care
coordonează întreaga activitate.
Cei care răspund de această activitate stabilesc standardele testării, planifică
testarea şi se preocupă de încadrarea întregii activităţi de testare în ciclul de viaţă
al sistemelor.
Se impune o testare a fiecărui modul (procedură) în parte, urmată apoi de
integrarea lor în programul final şi testarea acestuia.
Problema testării unui program este în strânsă dependenţă cu complexitatea
acestuia, de corectitudinea şi completitudinea testării depinzând evaluarea
programului respectiv.
Se ştie că un program descrie, de regulă, pentru prelucrarea automată a datelor,
un algoritm de rezolvare a unei probleme date şi că, la rândul său, algoritmul
exprimă în mod explicit şi neambiguu calea de rezolvare a unei probleme.
Corectitudinea reprezintă o condiţie indispensabilă a oricărui algoritm şi, în
cadrul prelucrării automate a datelor, a oricărui program. Este de la sine înţeles că
un program incorect nu este utilizabil în scopul pentru care a fost creat.
Un program realizat trebuie să fie deci corect, clar, sigur în funcţionare, uşor de
modificat, portabil, eficient, însoţit de o documentaţie corespunzătoare, etc.
În literatura de specialitate sunt prezentate, în acest sens, numeroase tehnici de
verificare şi validare a algoritmilor, adresate în principal practicienilor, dar şi cu
elemente de fundamentare teoretică uşor accesibile unui începător în programare.
Dintre aceste tehnici, metode, amintim următoarele:
• testarea programelor şi depanarea programelor
• verificarea formalizată a programelor
• cea mai slabă precondiţie
• cea mai tare postcondiţie
• instrucţiuni generalizate
• Sintaxa expresiilor logice, etc

Acţiunea de testare a programelor se deosebeşte de celelalte faze prin care trec

acestea (proiectare, programare, documentaţie, etc.) prin caracterul ei în aparenţă

219
“demolator”. Astfel, în timp ce alte faze au o esenţă constructivă, testarea are în
aparenţă un caracter distructiv, deoarece scopul ei este de pune în evidenţă proasta
funcţionare a programului, de a găsi hibele acestuia şi nu părţile sale bune. Din
punct de vedere psihologic, programatorul însuşi trebuie să adopte în această
etapă o atitudine “duşmănoasă” faţă de propriul program, pentru a putea găsi
defectele acestuia.
Analizînd problema mai atent, realizăm de fapt că scopul testării este în
realitate tot constructiv, acela de a pune în funcţiune un program care să
funcţioneze la parametri prevăzuţi.
Se ştie că, într-un algoritm de calcul şi deci, într-un program, este oricând
posibilă prezenţa unei/unor erori, oricât de precisă şi laborioasă ar fi metodologia
de elaborare. Procesul de detectare şi apoi de eliminare a erorilor unui program
are două componente, numite:
• verificare
• validare
Aceste două activităţi ar trebui să caracterizeze practic toate etapele prin care
trece un program, de la formularea cerinţei de rezolvare a unei probleme, la
analiza acesteia, la identificarea şi apoi descrierea algoritmului de rezolvare a
problemei, a codificării datelor şi validarea rezultatelor obţinute.
Aceasta deoarece tot mai mulţi specialişti din diferite domenii arată că această
activitate de testare şi validare nu este specifică doar activităţii de programare, ci
se întâlneşte pretutindeni, acolo unde se produce sau se construieşte ceva; există
în acest sens controale efectuate la nivelul fiecărei operaţii sau grup de operaţii,
după cum există şi un control final, al produsului finit, pentru realizarea recepţiei
lui finale.

e). Elaborarea documentaţiei

Dacă un program a fost proiectat, scris, apoi testat şi depanat se trece la
realizarea documentaţiei aferente:
- Manual de prezentare;
- Manual de utilizare;
- Manual de exploatare.
Aceste documentaţii vor fi actualizate, modificate şi completate, după caz, în
etapa care urmează în viaţa unui sistem informatic sau aplicaţie informatică, şi
anume implementarea acestuia/acesteia.

9.2. Tehnici de testare a programelor

Prin testarea programului se înţelege deci executarea programului respectiv cu

scopul de a descoperi eventuale anomalii sau erori. Ea se bazează pe construirea

220
unor eşantioane de date de intrare care să conducă la depistarea unor erori în
funcţionarea programului, într-un timp cât mai scurt şi cu efort cât mai mic.
În acest sens, activitatea de verificare şi validare a unui produs program
urmăreşte în principal, următoarele:
• descoperirea defectelor programului
• certificarea faptului că programul va funcţiona corect în condiţii de
exploatare curentă
Practic, verificarea (testarea) programului urmăreşte dacă programul a fost
construit bine, dacă este compatibil cu cerinţa iniţială, iar validarea controlează
dacă programul respectiv este bun, dacă îndeplineşte condiţiile cerute de
beneficiar.
Tehnicile pentru testarea şi validarea programelor pot fi:
• dinamice
• statice

Tehnicile dinamice de verificare şi validare constau în experimentarea

programelor în condiţii asemănătoare cu cele din exploatarea curentă, reală,
pentru a verifica dacă acestea îndeplinesc toate condiţiile cerute de prelucrare.
Acest experiment efectuat asupra programului se numeşte testarea programului şi
înseamnă deci executarea propriu-zisă a programului respectiv.

Tehnicile statice de verificare şi validare constau în analiza şi examinarea

atentă a codului programului pentru a depista eventuale anomalii, a documentaţiei,
a metodologiei de proiectare utilizată, pentru a putea aprecia funcţionarea corectă
a programului.

Observaţie :
Procesul de testare a unui program poate semnala existenţa unor erori care vor
trebui apoi corectate. Dar, lipsa semnalării unor erori în testarea unui program nu
garantează absenţa lor. Acest lucru este posibil datorită faptului că, în general, nu
pot fi testate toate situaţiile (cazurile) posibile în exploatarea curentă, deci,
testarea este, prin natura sa, incompletă. Dacă ţinem seama de aceste considerente,
vom putea privi fiecare test al unui program ca fiind neconcludent dacă nu a
evidenţiat o eroare, nerelevant, căci nu a solicitat îndeajuns programul

Deasemenea, analiza programului fiind o activitate umană este predispusă la

erori, ca orice activitate umană şi deci nu poate garanta corectitudinea finală a
programului.
De aceea se recurge adesea la metode formalizate, care pot conduce la
depistarea în mai mare măsură a erorilor unui program. Metodele matematice de

221
verificare pot fi utilizate cu succes numai dacă există definiţii precise ale
semanticii limbajului de programare folosit.
Şi totuşi, testarea programului rămâne metoda de bază pentru verificarea
corectitudinii unui program, succesul ei fiind condiţionat în primul rând de
experienţa programatorului, de complexitatea şi completitudinea setului de date
folosite în procesul testării, de analiza riguroasă, atentă a rezultatelor obţinute în
urma fiecărui test.
Practic, pornind de la nişte date de test construite de el, programatorul aşteaptă
să obţină la final sau pe parcurs, anumite rezultate. Dacă acestea nu sunt corecte,
complete sau în formatul aşteptat avem cel puţin o eroare în execuţia programului.
Putem spune că succesul testării depinde de “arta” programatorului de a-şi
construi setul de date de test.

Observaţie :
Relevanţa testului depinde de numărul eşantioanelor de date de test, dar mai
ales de calitatea datelor alese.

În acest sens, au apărut, în ultimul timp, o serie de metode de elaborare a

datelor de test, care ajută programatorul, oferindu-i posibilitatea de a aborda
sistematic activitatea de testare a programelor, cu o probabilitate crescută de
depistare a erorilor.
Aceste metode pot fi denumite:
• testarea funcţională sau metoda cutiei negre, care presupune construirea
datelor de test astfel încât să permită testarea fiecărei funcţiuni a programului;
• testarea structurală sau metoda cutiei transparente, care presupune
construirea datelor de test astfel încât toate părţile programului să poată fi testate.

Metoda cutiei negre presupune testarea funcţiunilor programului cu ajutorul

datelor de test. În acest caz succesul activităţii de testare constă în conceperea
unor date de intrare prin prelucrarea cărora defectele algoritmului şi deci şi ale
programului să fie puse în evidenţă prin observarea şi analiza rezultatelor
obţinute.
De aceea el este în mare măsură dependent de experienţa şi îndemânarea
programatorului, de abilitatea lui de a-şi construi datele de test cât mai complete,
complexe, cuprinzătoare din punct de vedere al situaţiilor sau valorilor de excepţie
ce pot apare în execuţia curentă a programului.
Astfel, sunt luate în considerare trei categorii de date de intrare pentru testarea
programului, şi anume:
a). datele tipice de intrare (normale);
b). datele atipice (netipice);
c). datele ilegale, care nu aparţin domeniului.
222
 Un aspect deosebit în acest sens îl reprezintă considerarea valorilor netipice ale
domeniului datelor de intrare, numite adeseori valori “de la marginea
domeniului”. Astfel, vom acorda o atenţie deosebită în testarea programului
modului în care aceste valori sunt sau nu tratate şi a corectitudinii rezultatelor
obţinute. Ca exemplu, la parcurgerea şi prelucrarea unui şir de n elemente, vom
urmări în mod deosebit prelucrarea primului şi a ultimului element, pentru a nu fi
omise sau incorect prelucrate. La prelucrarea unui fişier, primul şi ultimul articol
prelucrat trebuie să stea în atenţia noastră, în mod special, pentru a nu fi omise sau
incorect prelucrate.
Atunci când, în urma testării se identifică o eroare de program (de algoritm de
prelucrare) se impune analiza cauzelor care provoacă funcţionarea
necorespunzătoare a programului şi eliminarea acestora. Această activitate se
numeşte depanarea programului, şi este urmarea imediată şi firească a unui test
concludent, care a evidenţiat o anomalie în funcţionarea programului, vizibilă în
neconcordanţa rezultatelor aşteptate cu cele obţinute prin execuţia programului.

Metoda cutiei transparente, care completează cu succes strategia de testare a

metodei cutiei negre, presupune examinarea laborioasă a detaliilor programului, a
instrucţiunilor şi datelor. Dificultăţile decurg din existenţa, în programe, a
instrucţiunilor de decizie (if, case), a celor iterative (while, for, repeat) sau a celor
de transfer al controlului de program (go). Toate acestea determină un număr
mare de combinaţii în care instrucţiunile elementare ale programului (de calcul, de
citire, de scriere, de atribuire sau de apel de proceduri) pot fi executate. Ideal ar fi
atunci ca în procesul testării să poată fi executate (solicitate) toate aceste
combinaţii de comenzi. Ori, practica dovedeşte că, cel puţin în cazul programelor
complexe (nu neapărat mari ca dimensiune), acest lucru este adeseori imposibil.
De aceea intervine experienţa, îndemânarea şi intuiţia programatorului în
realizarea eşantioanelor de date de test care trebuie să asigure cel puţin testarea
combinaţiilor considerate mai importante.
Există o serie de criterii, numite criterii de acoperire, care pot sta la baza
stabilirii numărului de combinaţii de comenzi testate efectiv. Acestea ar putea fi:
• acoperirea tuturor instrucţiunilor, care înseamnă de fapt că la testare pentru
fiecare instrucţiune elementară a programului, trebuie să existe un eşantion de
date care să provoace executarea sa;
• acoperirea tuturor arcelor, care cere ca testul să fie astfel construit, încât
pentru orice arc din graf să existe eşantioane care să provoace parcurgerea arcului
la executarea programului; criteriul are calitatea că impune alegerea unui test care
să provoace evaluarea fiecărei condiţii cel puţin o dată, atât cu rezultatul de
Adevărat, cât şi cu Fals.
• acoperirea tuturor condiţiilor simple, care cere ca testul să acopere toate
arcele şi să asigure evaluarea tuturor condiţiilor simple atât cu rezultatul Adevărat
cât şi cu Fals ; criteriul este practic echivalent cu acoperirea tuturor arcelor, dacă
223
programul conţine doar condiţii simple, în care nu apar operatorii logici And sau
Or.
• acoperirea tuturor drumurilor, care cere ca pentru fiecare drum al grafului
de control, testul să conţină eşantioane prin prelucrarea cărora executarea
programului să urmeze drumul ales în mod normal; criteriul acesta este mai tare
decât toate celelalte.
Testarea unui program trebuie să se finalizeze, pentru a fi utilă, cu semnalarea
erorii şi localizarea ei. De aceea, testarea programului este urmată de depanarea
lui.

Depanarea unui program constă în localizarea erorii, determinarea naturii

sale şi corectarea ei. Ea se poate face în mod:
• static, după executarea programului;
• dinamic, în timpul execuţiei acestuia.
Depanarea statică se poate face prin mai multe metode, dintre care mai
utilizată este cea denumită “storage dump”, care presupune analiza conţinutului
locaţiilor de memorie, afişate de sistem în sistem de numeraţie hexazecimal sau
octal. Este o metodă destul de dificil de utilizat.
Depanarea simbolică, o altă metodă de depanare, este mai uşor de utilizat,
deoarece oferă posibilitatea de a urmări executarea programului la nivel de limbaj
sursă. Limbajele de programare oferă, în ultimile lor versiuni, un depanator
simbolic integrat, care permite depanarea uşoară, plăcută şi eficientă a
programelor prin următoarele operaţii:
• executarea pas cu pas a programului (un pas înseamnă de fapt o
instrucţiune executabilă);
• observarea, în timpul execuţiei, a valorilor unor variabile sau expresii
specificate de programator (care apar într-o fereastră specială - Watch Window);
• specificarea unor puncte de suspendare a execuţiei programului;
• modificarea valorilor unor variabile.
În activitatea de testare şi depanare a programelor, erorile datorate variabilelor
neiniţializate sunt greu de semnalat şi de localizat, mai ales atunci cînd aparent
totul funcţionează corect. În acest sens putem vorbi de variabila cu rol de indice
(numărător) care asigură parcurgerea elementelor unui vector, de expresia care
stabileşte dacă un ciclu se execută sau nu, aşa cum necesită algoritmul de
prelucrare descris; este vorba de controlul acestei condiţii, de tipul ciclului – cu
testarea iniţială sau finală a condiţiei, etc.

Verificarea formalizată a programelor

Practica a dovedit, în timp, că oricât de numeroase ar fi testele efectuate asupra
unor programe foarte complexe, ele nu pot garanta funcţionarea corectă a
acestora. Ele rămân deosebit de utile pentru semnalarea multora dintre erori şi
224
deasemenea pentru familiarizarea programatorului cu algoritmul, cu modul său de
lucru.
Există o serie de metode de esenţă matematică, venite în completarea
metodelor de testare şi depanare a programelor, care pot demonstra, pentru un
program, că:
• Procesul de prelucrare şi calcul se termină în timp finit pentru orice date din
domeniul specificat în enunţul problemei;
• După terminarea procesului de calcul, datele de ieşire oferă soluţia
problemei pentru care a fost creat respectivul algoritm.
Metodologia a fost elaborată de informaticienii R.W.Floyd, C.A.R.Hoare, E.W.
Dijkstra şi are la bază analiza, instrucţiune după instrucţiune, a întregului text
sursă al programului. Acesta trebuie să fie însoţit de comentarii cu privire la datele
de intrare, la rolul variabilelor, la proprietăţile datelor de ieşire, la funcţiunile
procedurilor sau secvenţelor de program luate în discuţie.
Corectitudinea instrucţiunilor simple de program se stabileşte foarte uşor.
Probleme de testare apar îndeosebi atunci când avem de a face cu algoritmi
complecşi; dacă aceştia sunt descompuşi, pe baza unor reguli precise, în elemente
simple constitutive, uşor de testat, atunci problema poate fi mai uşor rezolvată.

Iată deci că nu numai proiectarea şi scrierea efectivă a programelor necesită o

realizare structurată, modulară ; testarea şi depanarea unui program complex
necesită deasemenea descompunerea lui, a problemei complexe pe care o descrie,
în elemente simple, constitutive care vor fi ulterior asamblate şi testate ca un
produs program unitar.

225
 10. IMPLEMENTAREA SISTEMELOR INFORMATICE şi a
produselor refolosibile

Implementarea reprezintă acea etapă de realizare a sistemelor informatice în

care se asigură testarea cu date reale, definitivarea şi punerea în funcţiune a
sistemului proiectat.
Principalele obiective ale etapei de implementare sunt:
• experimentarea sistemului proiectat;
• finisarea noului sistem;
• punerea în funcţiune;
• recepţia sistemului informatic proiectat.

Obiectivele pe care trebuie să le realizeze implementarea unui sistem sau a unei

componente de sistem informatic fac ca momentul punerii în funcţiune să se
identifice cu momentul trecerii în exploatare a componentei sau sistemului
respectiv. După momentul punerii în funcţiune nu mai este permisă întreruperea
exploatării curente a componentei sau sistemului respectiv, căci orice întrerupere
înseamnă în acest caz nereuşita acestei acţiuni.
Principalele grupe de activităţi care trebuie realizate în etapa de implementare
sunt următoarele:
- Asigurarea condiţiilor de implementare;
- Executarea procedurilor de conversie a colecţiilor de date, dacă este cazul;
- Testarea şi implementarea procedurilor manuale, mecanizate şi
automatizate;
- Verificarea performanţelor sistemului realizat;
- Definitivarea documentaţiei sistemului realizat;
- Omologarea şi recepţionarea sistemului realizat.

1. Asigurarea condiţiilor de implementare a sistemului proiectat

Implementarea sistemului informatic proiectat depinde în mod hotărâtor de
modul în care beneficiarul asigură condiţiile de implementare şi punere în
funcţiune.
Aceasta este o activitate complexă, care cuprinde o serie de activităţi, cum
sunt:
• Difuzarea instrucţiunilor de executare a procedurilor manuale,
mecanizate şi automatizate
Aceste instrucţiuni se pot grupa în două mari categorii, şi anume:
o Instrucţiuni pentru beneficiar, care trebuie să ofere acestuia posibilitatea
să cunoască procedurile manuale sau automatizate pe care trebuie să le execute. În
acest sens, documentaţia anexată trebuie să facă o prezentare a aplicaţiei şi

226
fluxurilor informaţionale, a rapoartelor şi machetelor de introducere şi validare
date, etc
o Instrucţiuni pentru unitatea de prelucrare, colectiv informatică sau oficiu
de calcul, care trebuie să cunoască modalitatea de primire/predare a documentelor
primare şi rapoartelor obţinute, procedurile de validare a datelor, de reluare în caz
de incident, modalităţile concrete de operare pe fluxul prelucrărilor.
• Instruirea personalului utilizator presupune, pentru reuşita implementării,
următoarele activităţi :
o Sensibilizarea beneficiarului în probleme de informatică, cu scopul de a
aduce la cunoştinţa acestuia posibilităţile şi avantajele tehnicii de calcul, dar şi
ordinea şi disciplina informaţională impusă de aceasta. Ea se poate face prin
cursuri de iniţiere de scurtă durată organizate de proiectant la sediul dorit.
o Atragerea personalului cu putere de decizie în activitatea de
implementare este necesară ca o garanţie pentru asigurarea la timp şi integrală a
condiţiilor necesare implementării sistemului realizat.
o Pregătirea psihologică a personalului unităţii beneficiare, care nu trebuie
să-şi simtă ameninţat postul de introducerea prelucrării automate a datelor
• Asigurarea condiţiilor organizatorice necesare
Condiţiile organizatorice necesare implementării noului sistem se referă în
primul rând la asigurarea transpunerii în practică a modificărilor organizatorice
preconizate în etapa de proiectare, la utilizarea efectivă a documentelor proiectate
şi la instituirea noilor fluxuri informaţionale. Deasemenea se impune constituirea
colectivului de informaticieni în cadrul unităţii beneficiare, care să preia şi să
dezvolte aplicaţia. Este necesară apoi planificarea activităţilor specifice acestei
etape, care se poate face cu ajutorul unor grafuri Gantt, a metodei ADC, PERT.
Activităţile se pot planifica în condiţiile stabilirii resurselor materiale şi de timp
ale utilizatorului, precum şi a modului cum este condiţionată succesiunea
activităţilor.
Asigurarea resurselor hard
O condiţie esenţială a implementării sistemului proiectat o constituie asigurarea
capacităţii de calcul necesare, care poate fi realizată prin dotarea unităţii
beneficiare cu unul sau mai multe sisteme de calcul. Se impune deasemenea
asigurarea unui spaţiu corespunzător desfăşurării activităţii de informatică, care să
permită realizarea unor lucrări de calitate, asigurarea integrităţii, securităţii şi
confidenţialităţii fondului de date manipulat precum şi asigurarea multiplicării
documentelor primare reproiectate. Este importantă de asemenea asigurarea
materialelor consumabile specifice funcţionării sistemelor informatice .
Asigurarea fondului informaţional
Acest lucru presupune pregătirea datelor reale şi încărcarea fişierelor sau bazei
de date în vederea testării şi punerii în funcţiune a noului sistem. Aceasta se face
prin:
o constituirea fişierelor sau entităţilor bazei de date;
227
 o culegerea fondului informaţional necesar şi stocarea acestuia pe purtători
tehnici de informaţie, prin proceduri de culegere şi validare a datelor;
o preluarea parţială sau integrală a datelor dintr-o serie de fişiere existente,
cu ajutorul unor programe de conversie special realizate, dacă efortul şi timpul
necesar justifică această operaţie.

2. Executarea procedurilor de conversie

Executarea unor astfel de proceduri se face dacă există un sistem
informatic sau aplicaţii informatice în funcţiune, care trebuie înlocuite sau pentru
realizarea legăturilor funcţionale dintre acestea, dacă se impun conversii de
fişiere, de programe sau de proceduri.

3. Testarea şi implementarea procedurilor manuale şi automatizate

Activitatea de testare cu date reale a aplicaţiei sau sistemului proiectat este o
activitate deosebit de complexă, cu urmări directe asupra desfăşurării activităţii
curente din cadrul societăţii. De aceea, ea se poate face prin strategii diferite, cum
sunt:
• implementarea în paralel cu date curente, care presupune
funcţionarea concomitentă a vechiului sistem de evidenţă manual cu cel automat.
În acest caz, avem de a face cu două evidenţe în acelaşi timp, care necesită un
efort deosebit din partea personalului implicat, ţinând cont de faptul că acesta
trebuie să asigure datele de intrare şi să verifice rezultatele obţinute pentru ambele
evidenţe. De aceea, în mod normal, se recomandă scurtarea pe cât posibil a acestei
etape. Avantajul constă însă în faptul că se pot testa cu date reale toate
procedurile, modulele, algoritmii de calcul, situaţiile de excepţie care pot apare,
cerinţele de informare ale conducerii, etc.
• implementarea în paralel cu seturi de date din perioada anterioară,
mai uşor de acceptat pentru conducerea unei societăţi, deoarece permite simularea
noului sistem, depistarea şi înlăturarea deficienţelor sale înainte de renunţarea la
vechiul sistem de evidenţă. Dezavantajul constă însă în faptul că implică o muncă
dublă din partea personalului implicat, pe de o parte, şi se poate prelungi în timp
mai mult decât ar dori proiectantul.
• implementarea directă sau imediată, care constă în renunţarea
imediată la vechiul sistem de evidenţă şi înlocuirea lui cu cel nou. Acest mod de
implementare este riscant pentru beneficiar, dar foarte eficient pentru proiectant.
Alegerea strategiei de implementare depinde de o multitudine de factori, cum
ar fi: gradul de cuprindere şi de complexitate al prelucrărilor, pregătirea
beneficiarului, gradul de implicare al acestuia pe tot parcursul proiectării şi
realizării noului sistem, volumul şi diversitatea datelor prelucrate, mulţimea
surselor de culegere a datelor, etc.

228
 În aceste condiţii, indiferent de strategia de implementare adoptată, se pot
utiliza tactici diferite, cum sunt:
• implementarea simultană a tuturor componentelor (aplicaţiilor), care
necesită o pregătire şi un efort mai mare din partea proiectantului şi a
beneficiarului, dar reduce considerabil timpul de implementare. Ea presupune şi
un risc crescut pentru beneficiar.

• implementarea în serie a componentelor sistemului proiectat, care

reduce riscul pentru utilizator, dar creşte considerabil perioada de implementare.

• implementarea mixtă sau combinată, care presupune implementarea

simultană pentru unele componente cu risc mai mic şi paralelă pentru altele,
funcţie deci de complexitatea şi specificul sistemului proiectat.

În momentul în care sistemul proiectat răspunde cerinţelor de testare, se pune

problema punerii lui în funcţiune, în vederea intrării în exploatare curentă.
Responsabilitatea pentru testarea şi punerea în funcţiune a unui sistem informatic
revine unor factori deosebiţi de importanţi, cum sunt:
• Conducerea unităţii beneficiare a sistemului informatic. Aceasta are
principala răspundere pentru asigurarea condiţiilor organizatorice necesare punerii
în funcţiune a sistemului informatic, pentru asigurarea numărului şi calităţii
personalului necesar, a informaţiei supuse prelucrării şi a celorlalte categorii de
resurse necesare;
• Proiectantul sistemului informatic. Acesta răspunde în principal de
calitatea proiectului, respectiv de performanţele sale tehnico-funcţionale şi
economice în concordanţă cu sarcinile stabilite de beneficiar, de execuţia
remedierilor şi completărilor stabilite de beneficiar, de instruirea tehnică a
personalului implicat în noul sistem şi de asistenţa tehnică pentru punerea în
funcţiune.
• Reprezentantul colectivului de informatică sau a colectivului care preia
sarcina prelucrării datelor din sistemul informatic. Acesta are sarcina de a
organiza procesul tehnologic şi de a executa operaţiile tehnologice de pregătire,
arhivare a datelor în concordanţă cu prevederile proiectului, respectiv cu condiţiile
impuse de beneficiar în etapele de elaborare a proiectului.
Dacă punerea în funcţiune a sistemului informatic este asigurată de către
unitatea beneficiară a sistemului informatic, atunci sarcinile conducerii unităţii
respective cresc în mod considerabil, ca urmare a cerinţelor de pregătire a
proceselor tehnologice de prelucrare a datelor.

4. Verificarea performanţelor sistemului informatic proiectat

229
 Este activitatea în care se verifică gradul în care sistemul informatic proiectat
atinge în exploatare parametrii proiectaţi. Această verificare se realizează prin
evaluarea rezultatelor obţinute la testarea şi implementarea tuturor produselor
informatice, în comparaţie cu cerinţele şi restricţiile formulate în etapa de
proiectare.
Se verifică astfel asigurarea condiţiilor necesare pentru exploatarea curentă, în
funcţie de soluţia adoptată pentru asigurarea capacităţii de prelucrare, de ritmul de
exploatare proiectat, siguranţa în funcţionare, etc. Verificarea performanţelor
sistemului proiectat presupune evaluarea şi validarea rezultatelor obţinute prin
calculul indicatorilor de eficienţă economică.

5. Definitivarea documentaţiei sistemului proiectat

Etapa de implementare a sistemului informatic se finalizează atunci când noul

sistem funcţionează în conformitate cu cerinţele stabilite prin proiect, adică atunci
când se realizează corelarea procedurilor manuale şi automate, se completează
corect documentele de intrare, se obţin în timp util informaţiile dorite pe toate
nivelele de conducere, se atinge ritmul de exploatare şi se obţin performanţele
aşteptate.
De aceea, pentru recepţionarea noului sistem de către beneficiar, proiectantul
trebuie să elaboreze o documentaţie care să cuprindă pe de o parte o prezentare
sumară a sistemului şi a condiţiilor în care s-a desfăşurat implementarea (resurse,
arie de cuprindere), iar pe de altă parte evaluarea rezultatelor implementării cu o
serie de indicaţii referitoare la trecerea în exploatare curentă şi eventual
generalizarea utilizării noului sistem.
Etapa de implementare nu poate fi considerată încheiată dacă nu se
definitivează întreaga documentaţie a sistemului, cuprinzând manualele de
prezentare şi cele de utilizare şi exploatare. Definitivarea documentaţiei se
realizează în paralel cu celelalte activităţi din cadrul etapei de implementare,
printr-o strânsă colaborare între beneficiar şi proiectant.

6. Omologarea / recepţionarea sistemului informatic

Omologarea presupune acceptarea în mod oficial, de către beneficiar a

sistemului informatic în vederea utilizării sau generalizării lui, în urma verificării
modului în care sistemul informatic se încadrează în normele stabilite prin proiect.
Sistemul informatic trebuie să funcţioneze ca un sistem cibernetic complex,
având capacitatea permanentă de autoreglare şi de autoperfecţionare, căci altfel,
sistemul se autodesfinţează.
Un sistem informatic odată dat în exploatare curentă trebuie să fie permanent
îmbunătăţit, întreţinut, completat şi dezvoltat, pentru a răspunde noilor cerinţe de
informare ale conducerii, noilor tehnologii ale informaţiei sau modificărilor
230
intervenite în structura organizatorică sau legislaţia ce guvernează domeniul de
activitate respectiv.
Dacă aceste modificări sunt majore, se ajunge la necesitatea reproiectării
sistemului informatic, care intră astfel într-un nou ciclu de viaţă. În cadrul
reproiectării unui sistem informatic unele etape pot lipsi sau pot fi scurtate,
datorită experienţei prealabile în domeniu a proiectantului.
În ultimul timp, datorită faptului că tot mai multe domenii de activitate ale
oricărei societăţi comerciale au fost informatizate, evoluţia fără precedent a
componentelor hardware şi software atrag după sine şi necesitatea reproiectării
celor mai multe sisteme informatice, pentru adaptare la noile facilităţi şi
performanţe ale acestora.
Dacă ne referim la o unitate hotelieră, existenţa unui site propriu pe reţeaua
Internet îi face cunoscută oferta de servicii la scara mondială şi face posibilă
rezervarea de locuri de cazare, de excursii şi alte servicii în regim on-line, cu
efecte directe asupra activităţii curente şi a profitului obţinut. În aceste condiţii,
aplicaţiile de rezervare cazări, recepţie hotelieră şi facturarea corespunzătoare a
serviciilor consumate de către clienţi ar trebui reproiectate, ţinând cont tocmai de
noile tehnologii informatice, de noile sisteme de gestiune a bazelor de date şi noile
limbaje de programare apărute.

231
 11. DEZVOLTAREA SISTEMELOR INFORMATICE
11.1. Etapizarea activităţilor de proiectare şi reproiectare

Se ştie că orice sistem informatic sau produs program are un ciclu de viaţă
propriu, care e declanşat de decizia realizării lui, continuă cu analiza, apoi cu
proiectarea şi realizarea lui efectivă, cu punerea în funcţiune, exploatarea şi
întreţinerea curentă. Acest ciclu se încheie atunci când sistemul informatic sau
produsul program nu mai corespunde cerinţelor pentru care a fost conceput sau se
impune o modernizare a acestuia. Ciclul va putea atunci să fie reluat prin decizia
realizării unui nou produs sau a dezvoltării sau modernizării sale. Spunem că se
trece la reproiectarea sistemului sistemului informatic.
Fie că se pune problema proiectării şi realizării unui sistem informatic nou, fie
că se realizează doar reproiectarea, modernizarea celui existent, în practică echipa
de proiectare poate întâlni multiple posibilităţi, care se pot încadra în una din
următoarele situaţii:
- Proiectarea sistemului se face pentru o societate în care se abordează pentru
prima dată introducerea unui astfel de sistem. În acest caz se impune parcurgerea
tuturor etapelor de proiectare şi realizare;
- Se proiectează doar unele componente ale sistemului – subsisteme sau
aplicaţii, sau se dezvoltă astfel de componente, în condiţiile existenţei unei
concepţii generale asupra sistemului. În acest caz se poate trece direct la
proiectarea de detaliu –logică şi tehnică – efectuând eventual o revedere şi o
actualizare corespunzătoare a documentaţiilor întocmite în fazele anterioare.
- Există unele aplicaţii izolate în funcţiune şi se cere rezolvarea în continuare a
unor probleme, fără a exista o analiză de ansamblu a societăţii şi o concepţie
unitară asupra sistemului. În acest caz se impune parcurgerea tuturor etapelor,
începând cu studiul de oportunitate, urmând să se decidă asupra oportunităţii
menţinerii aplicaţiilor existente, respectiv asupra posibilităţilor de integrare a
acestora în noul sistem propus.
-
Atenţie!
Toate acestea fac ca etapele activităţii de proiectare şi realizare a unui sistem
informatic sau produs program să nu se succeadă întotdeauna în secvenţa
cunoscută. Astfel, anumite activităţi se întrepătrund, se desfăşoară în paralel, se
condiţionează reciproc.

Dacă proiectarea sau reproiectarea solicitată modifică concepţia întregului

sistem, deci priveşte legăturile funcţionale dintre componente, platforma
hardware, modul de organizare şi administrare a datelor, tehnologia de culegere şi
transfer a acestora, atunci se impune reluarea ciclului de la prima sa etapă şi
continuarea cu proiectarea de ansamblu a noului sistem. O atenţie deosebită se
acordă procedurilor de conversie necesare, mai ales privind colecţiile de date
232
existente. De aceea e bine ca, în cadrul fiecărei etape, funcţie de condiţiile practice
concrete de lucru, să se elaboreze grafice de eşalonare a tuturor activităţilor,
adaptate permanent la specificul lucrării respective.

11.2. Strategii în dezvoltarea sistemului informatic

Atât în ce priveşte proiectarea şi realizarea iniţială, cât mai ales dezvoltarea

unui sistem informatic, funcţie de complexitatea procesului, de cantitatea şi
calitatea resurselor implicate pot fi aplicate diferite strategii, cu avantaje şi
dezavantaje în raport cu scopul urmărit.
Astfel, în literatura de specialitate se consideră ca strategii de bază în abordarea
proiectării sau reproiectării unui sistem informatic cele pe care deja le cunoaştem
denumite:
- strategia bottom-up sau evolutivă;
- strategia top-down.

Strategia bottom-up conduce la parcurgerea următorilor paşi:

- Realizarea de aplicaţii independente, fiecare având fişiere proprii de date şi
realizate de regulă ca suport pentru conducerea operativă a unor activităţi. Ele
constau practic din operaţii de prelucrare a tranzacţiilor, de actualizare a fişierelor,
furnizarea de rapoarte predefinite. E bine de ştiut faptul că aşa au început
majoritatea societăţilor beneficiare de soft aplicativ.
- Integrarea fişierelor între care există legături logice într-o bază de date
unică, alegerea unui SGBD corespunzător, care asigură gestionarea şi controlul
centralizat al datelor. În acest mod pot fi adăugate sistemului noi facilităţi privind
interogarea bazei de date pe baza unor cereri predefinite sau create pe loc ,
utilizând astfel performanţele SGBD-ului selectat.
- Conceperea şi adăugarea unor proceduri sau modele de decizie şi planificare,
suport pentru nivelul conducerii tactice, cu prelucrarea datelor din baza de date
creată anterior.
- Diversificarea modelelor de decizie şi planificare cuprinse în sistem şi
extinderea bazei de date şi includerea în cadrul acesteia a datelor necesare noilor
modele.
- Abordarea nivelului conducerii strategice, prin conceperea unor noi modele
de decizie destinate acestui nivel şi prin reutilizarea modelelor implementate
anterior. Noile cerinţe de informaţii pot conduce la extinderea bazei de date
existente sau chiar la crearea unei baze de date independente, destinată acestui
nivel (conţine multe date cu caracter conjunctural obţinute din mediul extern
sistemului obiect). Se va utiliza în continuare acelaşi SGBD, pentru a asigura
coerenţa şi integritatea sistemului în ansamblul său.
Avantajele utilizării acestei strategii pot fi formulate astfel:

233
 - dezvoltarea treptată a sistemului se realizează în mod natural şi în corelaţie
cu cerinţele reale ale utilizatorului, care pot fi definite astfel mai uşor;
- utilizatorul se familiarizează mai uşor cu implicaţiile introducerii
prelucrării automate a datelor şi poate beneficia mai rapid de primele rezultate.
Creşte astfel rolul său participativ-activ în dezvoltarea sistemului. Practica
demonstrează că utilizatorul va putea să-şi formuleze cerinţe mai precise după
primirea primelor rezultate de la calculator.
- echipa de proiectare se acomodează pas cu pas cu problematica societăţii
utilizatoare;
- se reduce riscul realizării unui sistem mare, care să se dovedească
neoperaţional la punerea în funcţiune.
O serie de dezavantaje au fost însă identificate la utilizarea acestei strategii,
dintre care amintim:
- gradul de integrare şi performanţele sistemului rezultat sunt, de obicei,
slabe, datorită lipsei unei concepţii de ansamblu iniţiale asupra obiectivelor şi
funcţiunilor sistemului.
- fiecare pas nou, deci fiecare adăugare de noi funcţiuni, atrage după sine
reproiectarea, completă sau parţială, a aplicaţiilor realizate anterior, ducând astfel
la creşterea efortului şi deci şi a costurilor totale de proiectare;
- nu se poate face de la început o evaluare globală a duratelor şi a resurselor
necesare;
- dacă se produc modificări în componenţa echipei de proiectare, ceea ce se
întâmplă foarte des ca urmare a duratei destul de mari a ciclului de realizare, pot
să apară probleme de comunicare între faze sau între membrii echipei;

Strategia top-down presupune parcurgerea următorilor paşi:

- analiza obiectivelor generale şi specifice ale sistemului obiect, a relaţiilor
sale cu mediul extern şi a restricţiilor;
- identificarea activităţilor principale şi a relaţiilor dintre acestea;
- identificarea principalelor decizii şi acţiuni întreprinse pe diferite nivele
de conducere: strategic, tactic şi operativ;
- identificarea tipurilor de date necesare pentru fiecare acţiune sau decizie,
la nivelul fiecărei activităţi sau funcţiuni;
- definirea modelului de ansamblu al sistemului, cu modelul conceptual al
datelor şi prelucrărilor;
- gruparea cerinţelor de informaţii în subsisteme şi module funcţionale,
definirea interfeţelor dintre acestea;
- stabilirea priorităţilor în realizarea bazei de date, a subsistemelor şi
modulelor funcţionale componente, ţinând cont de modalităţile de integrare
treptată a acestora;
- realizarea propriu-zisă a sistemului, prin realizarea componentelor sale
potrivit graficului de priorităţi stabilit.
234
 Avantajele aplicării acestei strategii pot fi:
- analiza globală a sistemului obiect permite definirea obiectivelor generale
ale sistemului informatic şi ale celor specifice fiecărui subsistem, ceea ce permite
o planificare a resurselor şi un control mai riguros al proiectului;
- sistemul informatic obţinut are un grad înalt de integrare, ceea ce duce la
creşterea utilităţii sistemului şi a performanţelor sale;
- prin definirea de la bun început a obiectivelor, funcţiunilor şi interfeţelor
dintre componente se evită reproiectarea succesivă a acestora (cum se întâmpla la
strategia evolutivă).
Ca dezavantaje pot fi enumerate:
- definirea modelului de ansamblu necesită, pentru a fi corect, o bună
cunoaştere a sistemului obiect sub toate aspectele sale, identificarea elementelor
componente şi a relaţiilor dintre acestea, decuparea corectă chiar din această fază
a subsistemelor şi modulelor sale funcţionale; aceasta devine astfel o etapă
deosebit de dificilă, căci orice eroare poate avea mai târziu implicaţii
imprevizibile.
- parcurgerea corectă a etapelor sale duce la creşterea timpului de aşteptare
a utilizatorului până la obţinerea primelor rezultate ale prelucrării automate.

În practică însă cele două strategii care par diametral opuse, nu sunt
implementate în forma lor pură, ci într-o formă hibridă, prin combinarea acestora.
Astfel, se recurge de regulă la o strategie de forma: se aplică strategia top-
down pentru definirea modelului de ansamblu al sistemului informatic, după care
stabilirea priorităţilor de realizare, realizarea efectivă şi implementarea
componentelor se face conform strategiei bottom-up.
Nu trebuie neglijat faptul că reproiectarea unui sistem, cerută adeseori de noile
tehnologii informaţionale, presupun din partea echipei de proiectare o bună
cunoaştere a sistemului sau domeniului obiect, presupun deasemenea existenţa
unui personal utilizator instruit şi a unui sistem de conducere cu rol participativ-
activ în realizarea sistemului.
Toate acestea influenţează în mod direct şi pozitiv reproiectarea noului sistem,
contribuind la creşterea calităţii softului realizat, la reducerea resurselor necesare
şi a timpului de realizare.
Observaţie:
În funcţie de condiţiile concrete ale fiecărei unităţi care solicită realizarea unui
sistem informatic, de starea ei din momentul iniţial în ceea ce priveşte dotarea
hardware, aplicaţii existente şi personal instruit sau de specialitate, în funcţie de
obiectivele, cerinţele şi restricţiile formulate pentru noul sistem, în funcţie de
posibilităţile financiare şi de timp de care dispune societatea, dar şi în funcţie de
componenţa echipei de proiectare, de experienţa în domeniu, de creativitatea,
spiritul novator şi motivarea acesteia depinde, la sfârşit de drum, reuşita
proiectării sau reproiectării unui sistem informatic sau produs program.
235
 11.3. Utilizarea instrumentelor CASE în proiectarea sistemelor
informatice

Instrumentele CASE (Computer Aided Systems Engineering) au apărut în

jurul anului 1970 din necesitatea de a implica utilizarea calculatorului ca un
mijloc de susţinere a activităţilor de planificare, de proiectare şi realizare a
sistemelor informatice. Dezvoltarea aplicaţiilor de dimensiuni medii sau mari,
începând cu faza de analiză şi terminând cu fazele de testare şi întreţinere nu poate
fi realizată eficient fără ajutorul unui instrument CASE adecvat. Aportul
instrumentelor CASE este vizibil în primul rând în fazele de proiectare şi
implementare, speranţele fiind ca în viitor el să fie semnificativ şi în faza de
testare. Adoptarea UML ca limbaj standard de modelare a influenţat benefic
evoluţia instrumentelor CASE şi a determinat o creştere sensibilă a interesului
proiectanţilor pentru ele.
Utilizarea instrumentelor CASE nu este o problemă de modă, ci este o
problemă de eficienţă. Instrumentele nu sunt şi nici nu pot fi creative. Ele sunt şi
trebuie să fie în cel mai înalt grad degrevative.
De aceea, automatizarea tuturor activităţilor potrivite reprezintă sarcina de
bază pentru orice instrument CASE. În acest fel, instrumentele sprijină
utilizatorii să se concentreze asupra activităţilor cu adevărat creative.
Instrumentele CASE au evoluat odată cu componenta hardware a
calculatoarelor electronice, dar şi cu limbajele de programare şi metodologiile de
modelare. În anii 70-80, nu exista nici suportul (limbaje şi metodologii de
modelare) şi nici mijloacele tehnice (limbaje de programare, medii de dezvoltare
şi calculatoare suficient de puternice) absolut necesare pentru construirea unor
"adevărate" instrumente CASE. Mai mult, nu mai departe de sfârşitul anului 1997
(în momentul adoptării UML ca standard) marea majoritate a instrumentelor erau
într-o măsură prea mare apropiate ca funcţionalitate de instrumentele de desenare.
Această imagine este însă într-o schimbare semnificativă, datorată pe de o parte
deciziei producătorilor mediilor de dezvoltare de a introduce în (sau de a încuraja
conectarea la) mediile lor a unor instrumente de modelare (CASE) iar pe de alta
atitudinii realizatorilor de instrumente de a favoriza o legare mai strânsă a
instrumentelor la mediile de dezvoltare. La toate acestea se adaugă standardizarea
limbajelor de modelare, cererea tot mai mare pentru aplicaţii complexe şi sigure,
evoluţia nivelului pregătirii profesionale a realizatorilor de sisteme informatice,
care au contribuit şi continuă să contribuie la schimbarea rolului şi implicit a
nivelului de utilizare a instrumentelor CASE în procesul dezvoltării softului.
Astăzi dezvoltarea unei aplicaţii de dimensiuni medii sau mari nu mai poate fi
realizată eficient fără instrumente CASE adecvate.
Prin instrumente CASE înţelegem acele aplicaţii soft care-i sprijină pe
analişti, proiectanţi, programatori, inclusiv personalul de testare şi întreţinere,

236
să analizeze, să proiecteze, să implementeze (cel puţin parţial), să modifice
(extindă), respectiv să construiască teste pentru sistemele informatice.
În ultimii ani, instrumentele CASE au fost tot mai mult folosite pentru a realiza
modele de intreprinderi sau activităţi economice, motiv pentru care, definiţia
precedentă trebuie extinsă cu această precizare.
Instrumentele CASE se bazează pe logica structurată, pe descompunerea
funcţională şi pe reprezentarea aplicaţiilor prin diagramele de flux a datelor.

Obiectivele generale ale unui instrument CASE sunt:

- Să permită specialiştilor (analişti, proiectanţi, personal de testare) să se
concentreze într-o cât mai mare măsură asupra problemelor cu adevărat
importante ce trebuie rezolvate în procesul dezvoltării aplicaţiilor. Acest deziderat
se realizează printr-un nivel înalt de automatizare a tuturor tipurilor de operaţii ce
pot fi gestionate de instrument;
- Să sprijine realizarea unor activităţi eficiente de verificare la toate nivelele (cu
condiţia ca aceste activităţi să nu fie stânjenitoare);
- Să-i ajute pe beneficiari (nespecialişti în informatică) să verifice încă din
primele faze consistenţa şi completitudinea descrierii problemei.
O serie de avantaje ale utilizării instrumentelor CASE sunt cunoscute pentru
realizatorii de soft, cum ar fi:
- reducerea complexităţii logicii de descriere a sistemului, prin
descompunerea lui;
- creşterea vitezei de realizare a sistemelor;
- realizarea succesivă a componentelor;
- posibilitatea de a alege între mai multe variante;
- uşurarea integrării componentelor în sistem;
- folosirea depozitelor modularizate;
- refolosirea unor componente din diagramele utilizate;
- simplificarea activităţilor de proiectare şi realizare, etc.
Astfel, se pot utiliza instrumente CASE specifice în diverse domenii ale
activităţii de proiectare şi realizare a sistemelor informatice, cum sunt:
- Proiectarea şi modelarea funcţională şi procedurală; primele instrumente
Case serveau pentru crearea automată a fluxurilor de date, construirea schemelor
logice structurate de program şi verificarea acestora.
- Modelarea datelor şi proiectarea bazei de date; instrumentele Case
sprijină proiectarea logică şi fizică a bazei de date.
- Generarea codurilor. În marea majoritate a cazurilor, modelul construit cu
ajutorul unui instrument CASE este transformat ulterior în cod executabil. Din
această cauză, transformarea automată a informaţiilor modelului în cod este cât se
poate de naturală. În cazul în care comportamentul sistemului este complet
specificat cu ajutorul limbajului de modelare, atunci întreg codul aplicaţiei poate
fi generat automat. Din această cauză, instrumentele care sprijină semnificativ
237
generarea codului sunt cunoscute şi sub denumirea de instrumente de programare
vizuală. Două din cele mai importante probleme care trebuie rezolvate la
generarea codului sunt:
(a) Identificarea celui mai potrivit formalism pentru descrierea
comportamentului unei entităţi. Există unele situaţii în care modalitatea cea mai
simplă şi sugestivă este utilizarea directă a limbajului de programare.
(b) Generarea codului trebuie să fie suficient de flexibilă încât să permită
obţinerea unui cod eficient şi adecvat aplicaţiei.
- Editoarele; În acest sens editorul inteligent de limbaje este un instrument
de editare care înţelege sintaxa unuia sau mai multor limbaje de programare şi
sprijină procesul de realizare a codului.
- Referinţe încrucişate; instrumentele de referire încrucişată controlează
riguros toate conexiunile prin existenţa depozitelor CASE.
- Instrumente de test; testarea poate fi automatizată, apelând la funcţia de
tezaurizare a sistemelor Case, pe baza căreia se pot obţine datele de test pentru a
verifica dacă sistemul realizat răspunde cerinţelor formulate de utilizatori.
- Instrumente de analiză a rezultatelor obţinute, care permit simulări pentru
identificarea posibilităţilor de optimizare a programelor realizate.
- Depanatoare de coduri sursă
- Instrumente pentru managementul proiectelor
- Instrumente de documentare, care permit generarea şi actualizarea
automată a documentaţiei proiectului realizat.
Mediul de lucru CASE trebuie să sprijine astfel tehnicile de modelare în
diferite stadii şi metodologia cea mai adecvată pentru o societate sau pentru un
domeniu anume. Ele au evoluat odată cu acestea şi îmbracă mai multe forme, cum
sunt:
- instrumente Lower CASE;
- instrumente Upper CASE;
- instrumente Expert CASE;
- instrumente OPEN CASE;
- instrumente I-CASE;
- instrumente CASE orientate –obiect.
Utilizarea instrumentelor CASE îmbunătăţeşte considerabil calitatea procesului
de realizare a sistemelor informatice, creşte viteza de proiectare şi realizare a
acestora, îmbunătăţeşte calitatea testării lor, a documentaţiei elaborate,
promovează reutilizarea unor componente şi simplifică întreţinerea programelor,
îmbunătăţeşte managementul proiectelor şi conduce spre standardizarea
procesului de dezvoltare a sistemelor.
Ele sunt din ce în ce mai utilizate în diferite etape de către echipele de
proiectare şi realizare a sistemelor informatice.

238
 12. MANAGEMENTUL ACTIVITĂŢII DE PROIECTARE ŞI
REALIZARE A SISTEMELOR INFORMATICE
12.1 Aspecte organizatorice

Dacă avem în vedere importanţa activităţii de proiectare şi realizare a unui

sistem informatic, prin obiectivele sistemului, prin cerinţele şi restricţiile impuse
acestuia, precum şi prin dimensiunea resurselor folosite (financiare, materiale,
umane şi de timp) este evidentă necesitatea unei conduceri atente şi competente, a
unui control riguros asupra execuţiei fiecărei etape.
Activitatea de conducere a efortului de realizare a unui sistem informatic este
de mare importanţă, ea trebuind să urmărească legarea corespunzătoare a tuturor
acţiunilor ce urmează a fi desfăşurate şi să asigure astfel că totul se execută la
termenele stabilite, în cadrul fondurilor aprobate, conform obiectivelor formulate
şi că rezultatele unei etape sunt corecte şi pot fi utilizate în etapele următoare.
Orice proiect serios care trebuie realizat la cererea unei societăţi beneficiare se
dă spre execuţie unei echipe de proiectare, organizată eventual pe subechipe,
condusă de un aşa numit şef de proiect.
În această structură de lucru este rolul celor care conduc lucrările să definească:
- obiectivele sistemului, exprimate eventual, cantitativ şi calitativ;
- limitele până la care se va întinde sistemul, având în vedere obiectivele şi
restricţiile;
- sarcinile şi responsabilităţile fiecărui membru în toate etapele de realizare;
- planificarea resurselor şi urmărirea continuă a consumului lor;
- criteriile de evaluare a performanţelor sistemului, etc
Mai trebuie făcută precizarea că în echipa de proiectare participă, de regulă,
specialişti din domeniul informaticii: analişti, programatori, ingineri de sistem,
administratori de reţea şi sau baze de date, operatori. La aceştia se adaugă
neapărat, în toate etapele de lucru, reprezentanţi ai beneficiarului, de obicei
reprezentanţi ai compartimentelor sau activităţilor implicate în realizarea şi
introducerea noului sistem.
Alegerea şefului de proiect este o problemă cheie pentru reuşita activităţii de
realizare a unui proiect, date fiind atribuţiile sale. Astfel, acesta planifică,
coordonează, controlează, raportează sarcinile membrilor echipei şi face propuneri
pentru suplimentarea sau reducerea echipei, pentru înfiinţarea sau desfinţarea unor
subechipe, pentru repartizarea resurselor, pentru evaluarea rezultatelor fiecăruia,
etc. Şeful de proiect întocmeşte graficul de desfăşurare a lucrărilor şi asigură
utilizarea soluţiilor celor mai eficiente, de înalt nivel tehnic , precum şi realizarea
integrării interne şi externe a sistemului. El asigură încadrarea lucrărilor în
limitele indicatorilor aprobaţi, respectarea performanţelor şi restricţiilor prevăzute,
rezolvarea observaţiilor făcute cu ocazia avizărilor.Tot şeful de proiect este cel
care asigură informarea membrilor echipei de proiectare cu privire la sarcinile şi
obligaţiile ce le revin, asigură instruirea acestora în vederea respectării unor
239
reglementări specifice unităţii beneficiare, asigură gestiunea şi evidenţa resurselor
antrenate.

S-au formulat chiar 9 reguli de aur pentru buna conducere a proiectelor, care
revine în principal şefului de proiect. Prezentate sumar, ele sunt:

1). Respectarea unei ordini riguroase. Proiectul poate începe doar dacă s-a
răspuns la întrebări fundamentale ca:
- este oportun?
- ştim ce vrem?
- care sunt implicaţiile?
2). Construirea unui cadru de lucru, de către şeful de proiect, care să conţină:
- fluxul informaţional;
- probleme legate de culegerea şi validarea datelor;
- rezultatele aşteptate;
- compartimente sau activităţi implicate;
- etapele de desfăşurare.
3). Prezentarea globală a proiectului, pentru a găsi răspuns la întrebările:
- ce vrem să facem?
- ce trebuie să facem?
- cu ce începem?
- cu cine?
4). Formarea şi coordonarea echipei de proiectare este sarcina şefului de
proiect, care trebuie să se încadreze în echipă, astfel ca membrii ei să se simtă
informaţi, implicaţi, consultaţi.
5). Dotarea cu mijloace de urmărire şi control care să permită şefului să
verifice, să urmărească în mod real cum este realizat planul. Se cunosc astăzi o
serie de metode şi instrumente în mâna şefului de proiect pentru planificarea şi
urmărirea activităţilor unui proiect (graficul Gantt, graficul Pert), pentru
identificarea activităţilor critice.
6). Avizarea tuturor fazelor importante de către beneficiar, deci nici o etapă nu
trebuie să înceapă fără o avizare prealabilă a celei anterioare.
7). Controlul avansării realizărilor, pentru a şti permanent unde suntem, care
sunt punctele critice şi dacă sunt necesare forţe suplimentare.
8). Controlul calităţii, care înseamnă nu numai rezultate corecte obţinute, ci şi
programe bine construite, documentaţie bine întocmită, atât pentru utilizatori cât
şi pentru specialişti, utilizarea unor tehnologii adecvate, etc.
9). Identificarea originii modificărilor, dacă acestea apar şi pot fi: omisiuni în
cadrul analizei, beneficar nou, schimbarea legislaţiei, etc. Este important, căci
modificările produc perturbaţii iar acestea pot să nu fie grave dacă proiectul este
bine condus.

240
 12.2. Documentaţia proiectului

Documentaţia proiectului, care trebuie să fie bine întocmită, completă, corectă

şi organizată corespunzător pentru toate etapele din ciclul de viaţă al unui sistem
informatic sau produs program este deosebit de importantă. Astfel, ea reprezintă
principalul mijloc de conducere al efortului de realizare a unui sistem informatic,
de comunicare între beneficiar şi echipa de proiectare şi în interiorul acesteia,
între specialişti.
Se cere ca documentaţia elaborată să asigure:
- comunicarea între etape şi activităţi;
- controlul lucrărilor realizate, inclusiv a calităţii acestora;
- referinţă istorică, mai ales pentru evidenţierea modificărilor apărute ;
- instrucţiuni complete pentru utilizarea, exploatarea curentă, întreţinerea şi
dezvoltarea sistemului.

Pentru a răspunde acestor cerinţe, documentaţia elaborată trebuie să respecte

anumite principii cum sunt:
- Să permită exploatarea sistemului fără intervenţia autorilor;
- Să permită realizarea relativ uşoară a modificărilor necesare pentru
adaptarea sistemului la cerinţele specifice ale utilizatorilor;
- Descrierea sistemului să se facă de la general la particular, conform
strategiei top-down;
- Fiecare componentă să se adreseze unei categorii bine precizate de cititori
sau utilizatori, pentru o bună înţelegere a acesteia;
- Documentaţia să conţină cât mai puţine informaţii redundante.

Astfel, fiecare etapă din ciclul de viaţă al unui sistem informatic este însoţită de
elaborarea unei documentaţii care de regulă poartă numele etapei respective şi,
atunci când este cazul, dacă se adresează unor categorii diferite de utilizatori are
nume diferite, cum ar fi: Proiectul logic de detaliu şi proiectul tehnic de detaliu.

Aceste documentaţii care însoţesc sistemul pe măsura realizării lui sunt:

- Studiu de oportunitate sau Studiu de fezabilitate elaborat în etapa cu acelaşi
nume sau în cea denumită analiză preliminară sau temă de realizare.
- Proiectul de ansamblu al sistemului informatic, rezultat al proiectării de
ansamblu.
- Proiectul logic de detaliu, rezultat al activităţii de proiectare logică de detaliu.
Se elaborează la nivelul fiecărui subsistem şi aplicaţie informatică sau modul
funcţional.
- Proiectul tehnic de detaliu, rezultat al activităţii de proiectare tehnică de
detaliu. Se elaborează la nivelul fiecărei aplicaţii informatice sau modul
funcţional. El conţine practic specificaţiile tehnice de realizare efectivă a
241
programelor, descriind pentru fiecare program/modul sau procedură automată:
intrările şi ieşirile cu formatul lor, fişierele sau baza de date, algoritmii de calcul şi
modelele matematice utilizate, formatul interfeţei,etc.
- Manual de prezentare şi utilizare a fiecărei aplicaţii informatice sau modul
realizat.
- Manual de exploatare a sistemului sau a subsistemului sau a aplicaţiei
realizate.

Fiecare etapă trebuie să fie avizată şi însoţită deci de documentaţia

corespunzătoare, care va descrie riguros rezultatele acţiunilor întreprinse în cadrul
acestora.

Ulterior, orice modernizare, dezvoltare sau reproiectare a sistemului informatic

sau a aplicaţiei informatice presupune studiul documentaţiei corespunzătoare
acestuia/acesteia şi trebuie însoţită deasemenea de corectarea, actualizarea sau
completarea documentaţiei respective cu modificările survenite.
Documentaţia trebuie întreţinută deci la zi, odată cu sistemul.

242
 13. EFICIENŢA SISTEMELOR INFORMATICE (produselor program)

Se ştie că eficienţa economică se măsoară, în general, printr-un raport între

efectele obţinute şi cheltuielile antrenate.
În mod corespunzător, eficienţa economică a unui sistem informatic se va
determina prin compararea efectelor obţinute în urma exploatării lui curente cu
cheltuielile necesare pentru realizarea şi funcţionarea sa. Estimarea celor două
elemente se face ţinând cont de caracterul deosebit de complex al efectelor
obţinute prin introducerea noului sistem şi de ansamblul factorilor în care
funcţionează sistemul informatic realizat.
Pentru estimarea eficienţei economice a unui sistem informatic concret trebuie
identificate sursele de date necesare pentru calculul indicatorilor de eficienţă.
Astfel, în majoritatea cazurilor se cunosc sau se pot estima costurile de realizare,
de întreţinere şi dezvoltare, dar efectele economice sunt greu de cuantificat.
În literatura de specialitate teoriile şi conceptele privind eficienţa economică a
sistemelor informatice se pot clasifica în funcţie de sursele de estimare a fluxurilor
de venituri în trei grupe.

În prima grupă sunt cuprinse teoriile şi conceptele care susţin utilitatea

sistemului informatic. În acest caz se rezolvă “vechile probleme cu noile
instalaţii” în condiţii de eficienţă. În cadrul acestor teorii se stabilesc criterii
privind selecţionarea corectă a fluxurilor informaţionale care necesită
informatizarea imediată, se aleg componentele cele mai performante ale
tehnologiei informaţiei (echipamente, produse program şi metodologii)
preocuparea principală constând în asigurarea stabilităţii şi funcţionalităţii
sistemului informaţional existent.

În cadrul grupei a doua privind eficienţa sistemelor informatice sunt incluse

teoriile care consideră că eficienţa provine din impactul sistemului informatic
asupra activităţii de conducere a sistemelor economico-sociale, exprimată prin
creşterea eficienţei deciziilor asupra sistemului condus. Valoarea informaţiilor pe
care sistemul informatic economic le furnizează se compară cu cheltuielile
necesare pentru obţinerea acestora. Pentru calculul valorii informaţiei se apelează
la componente privind caracteristicile tehnice cum ar fi: precizie, operativitate,
conţinut informaţional, durata de răspuns etc.

Grupa a treia de teorii privind eficienţa sistemelor informatice economice au la

bază evaluarea eficienţei sistemului informatic prin contribuţia sa adusă la
sporirea eficienţei activităţilor cu caracter tehnic, în special asupra activităţilor de
producţie şi economico – sociale. În cadrul acestei grupe se analizează un număr
de indicatori economici din care enumerăm:

243
 a) indicatori de fundamentare tehnico – economică a sistemului
informatic
b) indicatori sintetici de evaluare a eficienţei economice a sistemelor
informatice deja existente

Indicatori de eficienţă economică ai sistemului informatic

Atunci când se elaborează un sistem informatic, acesta poate fi selectat dintr-o

gamă de variante, diferenţiate între ele prin elemente de cheltuieli şi prin efecte
economice obţinute.
Selectarea unui sistem se face pe baza analizei variantelor posibile de realizat,
în raport cu resursele informatice existente atât la proiectant cât şi la utilizator, în
contextul unui aşa numit raport cost/performanţă. În acest context au fost elaboraţi
indicatori capabili să reflecte raportul dintre costul resurselor consumate şi
performanţele scontate ale sistemului informatic după cum urmează:

. Coeficientul de satisfacere a cerinţelor informaţionale

Un sistem informatic trebuie să satisfacă integral cerinţele informaţionale ale

unităţii economico – sociale. Acest indicator se calculează ca un raport dintre
cantitatea de informaţii proiecată a fi furnizată de sistemul informatic şi cantitatea
de informaţii reale pe diversele nivele ale piramidei ierarhice ale conducerii
existente în unitate.

2. Valoarea informaţiilor furnizate de sistemul informatic

Se calculează funcţie de două componente de bază ale sale, şi anume:

• Cantitatea de informaţie
• Calitatea informaţiilor furnizate

a). Dacă vorbim despre cantitatea de informaţii, se impune precizarea că, în

cazul sistemelor social-economice, comportamentul lor la diferite momente are un
caracter aleator datorită perturbaţiilor ce pot apare pe parcursul desfăşurării
proceselor tehnico-economice, conducând astfel la o anumită nedeterminare a
stării sistemului.
Cu cât gradul de nedeterminare a stării sistemului este mare, ca urmare a
perturbaţiilor, cu atât cantitatea de informaţie necesară pentru restabilirea
traiectoriei sistemului este mai mare. Altfel spus, cantitatea de nedeterminare este
egală cu cantitatea de informaţie necesară.
Presupunând că în urma interacţiunii unor elemente ale sistemului social-
economic va rezulta un număr n de rezultate posibile, am putea utiliza pentru
calculul cantităţii de informaţie necesară conducerii relaţia:
244
 1 1
i = −∑ log
n n
Dacă din calcul se obţine i=0, atunci înseamnă că rezultatele interacţiunii dintre
elementele sistemului condus sunt conforme planului, programelor, normelor şi
deci aceste informaţii normale ar trebui excluse din sistemul de informare
operativă a conducerii şi admise numai cele care depăşesc anumite limite admise.

b). Calitatea informaţiilor furnizate de sistemul informatic ar putea fi definită

prin ansamblul caracteristicilor acestora şi anume: acurateţe, timp de răspuns,
vârsta, etc determinate de caracteristicile sistemului informatic, cum ar
fi:concepţia şi structura acestuia, nivelul de dotare tehnică, metode şi proceduri
utilizate în culegerea, prelucrarea, transmiterea şi stocarea informaţiilor.
b1). Acurateţea informaţiilor furnizate de sistemul informatic poate fi
măsurată prin gradul de predicţie asupra modului de desfăşurare a proceselor şi
fenomenelor, asupra traiectoriei acestora în viitor.
Harkevici A. propune pentru calculul acurateţei informaţiilor formula:
P1
Prob I = log2 _---
P0
unde:
P1 = probabilitatea atingerii obiectivului după obţinerea informaţiei
P0 = probabilitatea atingerii obiectivului înainte de recepţionarea
informaţiei.

b2). Vârsta informaţiilor este o caracteristică ce determină în mod esenţial

calitatea informaţiilor furnizate de un sistem informatic, deoarece de actualitatea
informaţiilor depinde calitatea deciziilor luate de către sistemul de conducere.
Durata dintre două rapoarte succesive ce conţin acelaşi gen de informaţii
caracterizează vârsta informaţiilor respective.
Vârsta informaţiilor are două componente:
- intervalul , măsurat în unităţi de timp, dintre momentul în care s-au obţinut
informaţiile precedente şi momentul în care sunt colectate datele pentru
prelucrare, în vederea transmiterii noilor informaţii;
- timpul de răspuns al sistemului informatic, definit ca fiind intervalul de timp
dintre momentul formulării unei cereri de la un terminal de comunicaţie – date
şi obţinerea răspunsului în acelaşi loc.
Practic el măsoară:
- timpul de formulare a cererii de la un terminal la un calculator;
- timpul de prelucrare al calculatorului, inclusiv timpul de acces şi obţinere
a înregistrărilor din fişiere necesare formulării răspunsului la interogare;
- timpul de transmitere a răspunsului de la calculator la terminal.
245
Din analiza corelaţiei dintre timpul de răspuns, efectele economice şi costuri,
rezultă că:
- odată cu reducerea timpului de răspuns efectele economice cresc dar în
acelaşi timp cresc şi costurile pentru obţinerea informaţiilor. Se impune
precizarea: costurile pentru reducerea timpului de răspuns peste anumite limite
depăşesc cu mult efectele economice. De aceea, reducerea considerabilă a
timpului de răspuns astfel încât informaţiile să se obţină în timp real nu se justifică
din punct de vedere economic în cazul sistemelor social-economice, căci nu ar
conduce la o creştere considerabilă a valorii informaţiilor.

În aceste condiţii, pentru a determina valoarea informaţiilor furnizate de un sistem

informatic este necesar să admitem utrmătoarele ipoteze:
- informaţiile nu au o valoare în sine, deşi pentru obţinerea lor se consumă o
anumită cantitate de muncă socială;
- valoarea informaţiilor se materializează în efectele ce se obţin ca urmare a
deciziilor care se iau pe baza lor;
- informaţiile furnizate de noul sistem informatic sunt superioare celor furnizate
de vechiul sistem informaţional din punct de vedere al conţinutului şi al
calităţii;
- fiecărui tip de decizie îi sunt asociate anumite efecte economice.
Atunci valoarea informaţiilor furnizate de noul sistem informatic Vi , exprimată
prin efectele economice , se va calcula cu relaţia:
1 I
Vi = ∑ f (C , A, T , n) − g ( P, N )
I n =1
unde:
C – cantitatea de informaţie;
A – acurateţea informaţiilor;
T – timpul de răspuns al sistemului informatic;
I – intervalul acoperit de informaţiile furnizate (perioadele pentru care informaţiile
sunt utile);
N – numărul de decizii ce se iau pe o perioadă;
n – numărul de perioade acoperite de intervalul I;
P – probabilitatea de a lua o decizie corectă cu informaţiile furnizate de vechiul
sistem sau fără informaţii.

Creşterea cantităţii de informaţie ce rezultă ca urmare a informaţiilor noi furnizate

de sistemul informatic conduce în mod direct la obţinerea unor efecte economice
suplimentare, prin diminuarea pierderilor posibile, dar în acelaşi timp antrenează
şi cheltuieli suplimentare. Analizând corelaţia dintre cantitatea de informaţie,
efectele economice şi costuri se constată că până la un anumit nivel al cantităţii de
informaţie , viteza de creştere a efectelor economice este mai mare decât viteza de

246
creştere a costurilor, după care la o creştere în continuare a cantităţii de
informaţie, viteza de creştere a efectelor economice este mai mică decât viteza de
creştere a costurilor.
Corelaţia dintre costuri şi cantitatea de informaţie este dată de funcţia
exponenţială :
Y = ae bx , unde a>0 reprezintă valoarea iniţială a costurilor, iar b>0 reprezintă
coeficientul care determină viteza de creştere a costurilor.
Corelaţia dintre costuri şi acurateţea informaţiilor este dată de funcţia hiperbolică :
bx
Y =a + unde:
1− x
a>0 reprezintă coeficientul valorii iniţiale a costurilor, b>0 reprezintă coeficientul
care determină viteza de creştere a costurilor

3. Coeficientul eficienţei economice

Acest coeficient reprezintă raportul dintre suma efectelor economice potenţiale

însumate pe durata unui an şi totalitatea resurselor consumate (costurile) pe
aceiaşi durată. Acesta depinde, în mare măsură, de productivitatea programelor, a
echipamentelor, a sistemelor de operare, precum şi a operatorilor.
Astfel, la un an după punerea în funcţiune a unui sistem informatic, când se
face evaluarea acestuia, coeficientul eficienţei economice se poate calcula cu
relaţia:
E
Ke = , unde:
F f + Fc
Ke - coeficientul eficienţei economice;
E – efectele economice totale;
Ff – valoarea fondurilor fixe utilizate;
Fc – valoarea fondurilor circulante utilizate

Acest indicator se poate calcula la nivelul întregului sistem informatic, a

fiecărui subsistem sau modul (aplicaţie informatică) a acestuia, în diferite
momente ale realizării, cum sunt:
- pentru fundamentarea oportunităţii sale;
- pentru aprecierea funcţiunilor sale;
- pentru fundamentarea necesităţii dezvoltării, modernizării sau reproiectării
sale.

4. Coeficientul termenului de recuperare a cheltuielilor

Acest coeficient se calculează ca raport între cheltuielile antrenate şi efectele

economice totale pe durata ciclului de viaţă al sistemului informatic. Se calculează
în etapa de fundamentare a oportunităţii introducerii sistemului informatic. Se
247
poate calcula şi pentru fundamentarea fiecărui subsistem sau aplicaţie informatică
în parte, precum şi pentru fundamentarea modernizării acestora.
El se calculează ca raport între cheltuielile de realizare, introducere şi
dezvoltare a sistemului informatic sau a aplicaţiei informatice şi efectele
economice obţinute, astfel:

C
Tr = (ani) unde:
E
Tr – coeficientul termenului de recuperare
C – cheltuieli de realizare, introducere şi dezvoltare antrenate
E – efectele economice obţinute

La un an după punerea în funcţiune a sistemului, subsistemului sau modulului

informatic termenul de recuperare se recalculează raportând cheltuielile efective
ale beneficiarului la efectele economice efective .

5. Coeficientul economiei de personal

Prin introducerea noului sistem informatic timpul de muncă (t1) a personalului

se reduce faţă de timpul de muncă consumat anterior (t0) pentru executarea
aceloraşi lucrări informaţionale. Astfel, putem vorbi de o economie absolută de
personal, dar şi de o economie relativă de personal, care ţine de creşterea
numărului şi volumului lucrărilor de evidenţă şi calcul executate cu acelaşi număr
de personal.
Acest coeficient Kp se calculează:

Kp = (t0 –t1) / t0

6. Coeficientul tehnico - economic

În multe din situaţiile concrete de estimare a eficienţei economice a sistemelor

informatice cu ajutorul indicatorilor prezentaţi nu se ajunge la o soluţie
concludentă. În aceste cazuri se recurge la un indicator sintetic, cuantificat pe baza
criteriilor de importanţă acordată coeficienţilor enumeraţi anterior. Calculul se va
face la un consum minim de resurse necesare obţinerii anumitor efecte economice.

7. Coeficienţi tehnici ai sistemului informatic

Adeseori eficienţa unui sistem informatic nu poate fi uşor calculată şi atunci,

pentru a pune în evidenţă utilitatea şi performanţele tehnice ale acestuia, se
apelează la o serie de indicatori tehnici de caracterizare a acestuia, cum sunt:
- Coeficientul de utilizare a datelor Ku pentru procesul de prelucrare P:

248
 Dn ( P)
K u ( P) = unde:
I n ( P)
Dn – cantitatea de date ce se prelucrează cu procesul P
In - cantitatea de informaţie ce trebuie furnizată de componenta respectivă

- Coeficientul nivelului de organizare a fişierelor/bazei de date K0 :

T
K0 = 0 unde:
T

T – timpul total T= T0 + Ti + Ta + Tp
T0 – timpul pentru încărcarea şi actualizarea bazei de date
Ti - timpul pentru întreţinerea, salvarea şi refacerea fişierelor bazei de date
Ta – timpul de acces la fişiere
Tp – timpul de prelucrare propriu-zis

- Coeficientul nivelului de întreţinere a fişierelor bazei de date Ki

T
Ki = i
T
- Coeficientul nivelului de acces la fişierele bazei de date Ka
T
Ka = a
T
- Coeficientul nivelului de prelucrare a datelor Kp
Tp
Kp =
T
- Fiabilitatea sistemului, care exprimă capacitatea sistemului informatic de a-şi
îndeplini funcţiile sale o anumită perioadă de timp în anumite condiţii de
utilizare.

8. Calitatea serviciilor

Calitatea serviciilor de prelucrare automată a datelor se poate aprecia prin:

- siguranţă, robusteţe;
- fidelitate, acurateţe;
- integrare;
- operativitate;
- complexitatea prelucrărilor;
- fundamentare ştiinţifică prin utilizarea unor modele matematice;
- control şi acceptabilitate.

249
 Estimarea eficienţei economice a sistemului informatic cu ajutorul analizei
cost / beneficiu

Proiectarea şi realizarea unui sistem informatic implică un consum mare de

resurse (forţă de muncă, echipamente, produse program, consumabile, etc. ce pot
fi exprimate sub formă de costuri) pentru a obţine servicii exprimate sub formă de
venituri. Sistemul informatic având o durată de viaţă bine determinată, realizarea
lui poate fi asimilată cu o investiţie şi pe această cale putem estima eficienţa
economică cu ajutorul indicatorilor oferiţi de analiza cost beneficiu.
Metoda analizei cost beneficiu (ACB), elaborată de către Institutul Băncii
Mondiale (BIRD), se bazează pe aplicarea tehnicilor de actualizare şi pe folosirea
în analiză a unui număr restrâns de indicatori de eficienţă.
Atunci când se calculează costurile sistemului trebuie luate în considerare două
mari categorii:
- costurile iniţiale, determinate de costurile echipamentelor, ale cablării
şi ale softului; avem în vedere în acest sens costurile pentru softul de bază,
sisteme de operare şi programe utilitare, dar şi costul pentru softul de aplicaţii
proiectat şi realizat sau reproiectat, dezvoltat, modernizat.
- costuri operaţionale sau funcţionale, care cuprind costurile cu
personalul, cu funcţionarea şi întreţinerea calculatoarelor, cu distribuirea datelor –
dacă este cazul, cu întreţinerea şi dezvoltarea sistemului sau aplicaţiei informatice.
Se impune precizarea că adeseori costurile constituie aspecte fundamentale ale
proiectării unui sistem nou, dar uneori, indiferent de costuri, pentru realizarea unui
sistem informatic performant se acceptă orice efort, inclusiv financiar. Aşa ar
putea fi, de exemplu, un sistem care să asigure securitatea naţională.
De aceea nu se poate da o reţetă exactă de apreciere a eficienţei unui sistem
informatic, ea fiind influenţată de specificul, de importanţa şi necesitatea fiecărui
sistem în parte.

250