ROTARU SIMONA

GHI MIRELA CLAUDIA

SISTEME I APLICAII
INFORMATICE N ECONOMIE

Editura Revers
Craiova 2015

Corectura aparine autoarelor

Editura REVERS Craiova
Toate drepturile asupra acestei ediii sunt rezervate autoarelor. Orice
reproducere integral sau parial, prin orice procedeu, a unor pagini din
aceast lucrare, efectuate fr autorizaia editorului este ilicit i
constituie o contrafacere. Sunt acceptate reproduceri strict rezervate
utilizrii sau citrii justificate de interes tiinific, cu specificarea
respectivei citri.
Editura REVERS Craiova
All rights reserved. This book is protected by copyright. No part of this
book may be reproduced in any form or by any means, including
photocopying or utilised any information storage and retrieval system
without written permision from the copyright owner.

Descrierea CIP a Bibliotecii Naionale a Romniei

ROTARU, SIMONA; GHI, MIRELA CLAUDIA
Sisteme i aplicaii informatice n economie /
ROTARU SIMONA; GHI MIRELA CLAUDIA. - Craiova :
Revers, 2015
Bibliogr.
ISBN 978-606-703-477-6

Editura Revers
ISBN: 978-606-703-477-6
2

Cuprins
Capitolul 1
Noiuni generale despre sistemele informatice .................................................................. 7
1.1 Concepte de baz ale sistemelor informatice .......................................................... 7
1.2 Reprezentarea sistemic a unei organizaii ........................................................... 13
1.3 Componentele i resursele sistemului informatic .................................................. 18
1.4 Clasificarea sistemelor informatice ........................................................................ 20

Capitolul 2
Metodologii de realizare a sistemelor informatice ............................................................ 25
2.1 Metode de abordare a sistemelor informatice ....................................................... 26
2.2 Modele ale ciclului de via a sistemului informatic ............................................... 31
2.3 Clasificarea metodologiilor de realizare a sistemelor informatice .......................... 40
2.4 Metode i tehnici de realizare a sistemelor informatice ......................................... 43

Capitolul 3
Cadrul tehnologic de analiz i dezvoltare a sistemelor informatice................................ 49
3.1 Identificarea problemelor de soluionat i determinarea cerinelor sistemului ....... 50
3.2 Structurarea cerinelor sistemului .......................................................................... 58
3.3 Evaluarea sistemelor informatice .......................................................................... 60
3.4 Modelarea noului sistem informatic ....................................................................... 61

Capitolul 4
Proiectarea logic i fizic sistemelor informatice ........................................................... 79
4.1 Proiectarea de ansamblu / general / logic ......................................................... 81
4.2 Proiectarea de detaliu/fizic ................................................................................ 114
4.3 Proiectarea orientat obiect a sistemelor informatice .......................................... 115

Capitolul 5
Implementarea, exploatarea i ntreinerea sistemelor informatice................................ 133
5.1 Implementarea sistemelor informatice ................................................................. 133
5.1.1 Realizarea i testarea programelor .............................................................. 135
5.1.2 Instalarea sistemului .................................................................................... 140
5.1.3 Verificarea performanelor sistemului informatic proiectat ........................... 141
3

5.1.4 Elaborarea documentaiei de utilizare a sistemului informatic proiectat. ...... 142

5.2 Exploatarea i ntreinerea sistemului informatic ................................................. 143
5.2.1 Exploatarea sistemului informatic ..................................................................... 143
5.2.2 Procesul de ntreinere a sistemelor informatice............................................... 144
5.2.3 Documentaia necesar exploatrii i ntreinerii sistemului informatic ........ 146

Capitolul 6
Aplicaiile sistemelor informatice .................................................................................... 151
6.1 Selecia tehnicii de programare i a limbajului utilizat ......................................... 151
6.1.1 Elementele componente ale sistemului Microsoft Access ............................ 155
6.1.2 Caracteristici Visual Basic for Application (VBA).......................................... 158
6.1.3 Editarea modulelor VBA ............................................................................... 159
6.2 Elementele limbajului VBA .................................................................................. 161
6.2.1 Tipuri de date ............................................................................................... 161
6.2.2 Variabile i constante ................................................................................... 163
6.2.3 Operatori ...................................................................................................... 167
6.2.4 Proceduri/funcii ........................................................................................... 168
6.3. Structuri de control fundamentale n VBA........................................................... 175
6.3.1Tipuri de structuri de control.......................................................................... 176
6.3.2 Instruciuni pentru implementarea structurii alternative ................................ 178
6.3.3 Instruciuni pentru implementarea structurii repetitive .................................. 181
6.4 SQL pentru ACCESS .......................................................................................... 184
6.4.2 Limbajul de manipulare a bazei de date (SQLLMD) .................................. 193
6.4.3 VEDERI ........................................................................................................ 202

Capitolul 7
Utilizarea SGBD Access n proiectarea aplicaiilor informatice ...................................... 208
7.1 Colecii de obiecte tip ntr-o baz de date Access ............................................... 208
7.1.1Obiecte de tip tabel ....................................................................................... 208
7.1.2 Obiecte de tip cerere. Interogarea bazelor de date ...................................... 214
7.1.3 Obiecte de tip form ....................................................................................... 224
7.1.4 Obiecte de tip Raport ................................................................................... 231
4

7.1.5 Obiecte de tip Macro .................................................................................... 235

7.2 Dezvoltarea rapid a unei aplicaii....................................................................... 238
7.3.2. Ataarea tabelelor n aplicaii ...................................................................... 248
7.3.3 Replicarea bazelor de date .......................................................................... 249
7.3.4 Protejarea bazelor de date ........................................................................... 250
7.3.5. Accesarea concurent a bazelor de date .................................................... 254
7.3.6. Repararea i compactarea bazei de date ................................................... 254
7.3.7. Optimizarea bazelor de date ....................................................................... 255
7.3.8. Analiza i documentarea bazelor de date ................................................... 256

Capitolul 8
Auditul sistemelor informatice ........................................................................................ 261
8.1 Particularitile procesului de audit al sistemului informatic ................................. 261
8.1.1 Operaii specifice auditrii sistemelor informatice ........................................ 261
8.1.2 Etapele auditrii ........................................................................................... 267
8.1.3 Probleme de audit asociate cu utilizarea sistemelor informatice .................. 272
8.2 Analiza riscului auditrii sistemelor informatice ................................................... 274
8.2.1 Riscurile asociate sistemelor informaionale ................................................ 276
8.2.2 Etape n analiza riscurilor ............................................................................. 279
8.2.3 Evaluarea calitativ i cantitativ a riscurilor ................................................ 283
8.3 Realizarea auditului sistemelor informatice ......................................................... 292
8.3.1 Controale generale....................................................................................... 293
8.3.3. Raportul de auditare................................................................................... 319

BIBLIOGRAFIE ......................................................................................... 324

Capitolul 1
Noiuni generale despre sistemele informatice
Obiective:
nsuirea noiunilor de baz legate de abordarea sistemic a unei organizaii
Cunoaterea principaleleor elemente ale unui sistem informatic
Stabilirea locului i rolului unui sistem informatic ntr-o organizaie
Cuvinte cheie: sistem informaional, sistem informatic, sistem informatic integrat, viziune
sistemic, resursele sistemului informatic.
1.1 Concepte de baz ale sistemelor informatice
Conceptul de baz al analizei i proiectrii sistemelor l constituie noiunea de sistem. Acest
concept este folosit n mod frecvent n diferite domenii de activitate existnd astfel: sisteme de
afaceri, sisteme politice, sisteme informatice, sisteme de producie, sisteme biologice, sisteme
educaionale etc. Toate aceste sisteme au n comun faptul c sunt alctuite dintr-un numr de
elemente ce interacioneaz att ntre ele ct i cu mediul nconjurtor n vederea realizrii unui
obiectiv.
Noiunea de sistem este una foarte general, cuprinztoare, practic, n orice domeniu de
activitate se are de a face, ntr-o form sau alta, cu sisteme.
Conceptul de sistem a aprut ntr-o form embrionar n filozofia antic greac
afirmnd c ntregul este mai mult dect suma prilor componente, Aristotel a dat o prim
definiie a noiunii de sistem.
Noiunea de sistem are un caracter relativ, n sensul c orice sistem poate fi
descompus n subsisteme i la rndul su, poate fi privit ca un subsistem al unui sistem mai
complex.
Astfel de exemplu, o ntreprindere poate fi descompus n sisteme (secii, ateliere, locuri de
munc) i la rndul ei, ntreprinderea poate fi privit ca un subsistem al unei ramuri, sau al
economiei naionale. Pe acest principiu de descompunere a sistemului real n subsisteme, se
bazeaz analiza i proiectarea sistemelor informatice pentru a studia conexiunile dintre
subsisteme n raport cu obiectivele lor i n funcie de resursele existente. dup care sunt

reintegrate ntr-un nou sistem mai performant, a crui reproiectare constituie obiectivul principal
al analizei i proiectrii sistemelor.
Prima definiie riguroas a conceptului de sistem aparine fondatorului teoriei generale
a sistemelor (TGS), Ludwing von Berthalanffy1, care considera c sistemul este o mulime de
elemente intre care exist relaii sau raporturi nentmpltoare care interacioneaz n vederea
realizrii unui obiectiv comun, care poate fi o lege a naturii sau un obiectiv stabilit de ctre om.
Principala sa lucrare, care poart chiar acest titlu Teoria general a sistemelor apare abia n
1969, dar principiile fundamentale ale teoriei sunt deja aplicate ntr-o serie de domenii tiinifice.
Conform autorului teoria permite aplicarea acelorai principii, legi i modele pentru toate tipurile
de sisteme, att pentru cele fizico-naturale ct i pentru cele fizice (sociale, psihice, logice).
n teorema general a sistemelor exist o legitate formulat pentru prima dat de
Churchmann, care afirm c orice sistem poate fi considerat n alte condiii ca subsistem, fapt
ce evideniaz caracterul relativ al acestor dou concepte de baz n analiza i proiectarea
sistemelor informatice.
n general pentru a putea defini un sistem din orice domeniu de activitate trebuie
stabilite cu precizie elementele componente i conexiunile existente ntre elementele sistemului
pe de o parte i ntre sistem i mediu pe de alt parte, precum i obiectivul sistemului.
Un sistem este un ansamblu de elemente care ascult de un pachet de reguli de funcionare
bine definite, n vederea ndepliniri unui anumit scop. Orice sistem este caracterizat prin aceea
c este legat de mediul ambiant. Are o anumit structur, funcioneaz dup anumite reguli i
urmrete un anumit scop. Datele se gsesc ntr-o circulaie permanent intre oameni care
transmit informaii i cei care le primesc. Acest drum se numete flux informaional. n ceea ce
privete scopul sau obiectivul sistemului, acesta trebuie vzut ca raiunea pentru care a fost
construit sistemul, motivul pentru care au fost grupate elementele respective.
Un sistem, n absena obiectivului su, reprezint numai o mulime de elemente
interconectate. La rndul ei o mulime de elemente neconectate nu va avea nici o semnificaie
pentru analiza i proiectarea sistemelor.
Elementele unui sistem sunt entiti de tipuri i caracteristici diferite, cum ar fi oameni
echipamente. Procese de producie, tehnologii, organizare etc. implicate ntr-o mulime de
activiti specifice sistemului. Entitatea este un element de abstractizare a realitii caracterizat
prin atributele care o descriu i o definesc funcional. Elementele sistemului pot fi ele nsele
considerate ca sisteme n sensul definirii acestui concept.

Biolog i filozof al tiinei, inovator al biologiei teoretice, fondator al TGS. American - 1901/1973
8

Sistemul alctuit din unul sau mai multe elemente l putem considera ca subsistem al
unui sistem mai complex (hipersistem/suprasistem). Apare astfel, problema existenei i definirii
unor elemente primare simple, despre care s nu mai putem afirma c sunt sisteme sau
subsisteme, ci doar elemente componente ale unui sistem/subsistem.
i evident, n cellalt sens, apare problema existentei i definirii unui hipersistem care
s includ toate sistemele existente iar el s nu mai fie inclus ntr-un alt sistem de ordin
superior. Este clar c rspunsul la cele dou probleme este negativ, i c numai n mod
abstract, imaginativ, din necesiti practice de cercetare, vom considera existena acestor cazuri
- limit de sisteme.
Relaiile dintre elemente includ i comunicaiile dintre ele i limiteaz comportamentul acestora
n cadrul sistemului. n acest sens, sistemul trebuie izolat pentru a pune n eviden restriciile
care exist, care acioneaz i influeneaz comportamentul elementelor din sistem. n
descrierea unui sistem se vor evidenia totdeauna elementele componente, relaiile dintre
acestea i scopul sistemului.
Conexiunea sistemului cu mediul su este reliefat de mulimea elementelor care
alctuiesc vectorul de intrare (input-uri) i vectorul de ieire (output-uri). Complexitatea
conexiunilor la nivel de sistem este data de complexitatea rezultatului compunerii conexiunilor
interne, existente intre subsisteme i mediu, respectiv, ntre sistem i mediul acestuia.
Orice sistem este supus unor schimbri permanente n cadrul ciclului de via, care pun
n eviden conceptul de sistem dinamic. Aceast caracteristic provine din influena
schimbrilor asupra interaciunilor dintre elementele componente i a conexiunilor dintre sistem
i mediu, n vederea atingerii obiectivelor sistemului.
Sistemul interacioneaz cu mediul su, care este format din elemente ce nu fac parte
din sistem, dar care ii pot influena. Distincia dintre sistem i mediu este realizat de conceptul
de grani/frontier, care la rndul ei poate fi considerat un sistem format dintr-o mulime de
elemente al cror comportament este exclusiv determinat att de obiectivele sistemului ct i de
comportamentul unor elemente vecine din mediu sau din interiorul sistemului.
n timp ce grania unui sistem poate fi de natur fizic, este mai bine s se determine o
grani n termenii cauz-efect. Dac un anumit aspect al unui sistem, este complet determinat
de influene din afara sistemului. atunci acel aspect este n afara granielor sistemului.
n terminologia sistemic, tot ceea ce este n afara granielor sistemului, dar care l
poate influenta, constituie mediul sistemului.
Cunoaterea mediului ambiant, a factorilor de influen ai mediului asupra firmei, a
interdependenelor dintre acetia i firm, are o importan deosebit pentru atingerea
obiectivelor, n contextul mutaiilor economice survenite n mediul firmelor, n procesul tranziiei
9

spre economia de pia. Factorii de influen din mediu pot fi de natur economic, tehnic,
tehnologic, demografic, ecologic, juridic, politic, socio-cultural i de management.
O categorie important de factori cu impact semnificativ asupra firmei o reprezint
factorii economici, concretizai n principal prin piaa intern, piaa extern i prghiile
economico-financiare. Studiul pieei furnizeaz informaii relevante despre nivelul i structura
cererii. nivelul preurilor, concurente etc. pe baza crora conducerea firmei i poate fundamenta
deciziile referitoare la aprovizionare, producie i desfacere, precum i unele aspecte ale
strategiei generale.
n cadrul prghiilor economico - financiare, cointeresarea material are un rol important
i se realizeaz n principal prin intermediul sistemului de salarizare i a profitului, firmele fiind
condiionate s se ncadreze n anumite limite cantitative controlate de instituiile bancare i
trebuind s respecte anumite modaliti de repartizare a profitului.
Din categoria factorilor de management exogeni care influeneaz funcionalitatea i
eficiena firmei, fac parte mecanismul de planificare macroeconomic, sistemul de organizare a
economiei, modalitile de coordonare, mecanismele motivaionale i de control, calitatea
metodelor i tehnicilor manageriale etc.
Planificarea macroeconomic are un pronunat caracter orientativ, de previziune i
corectare a unor eventuale disproporii, numrul de indicatori i balane reducndu-se
substanial fat de cel necesar n economia centralizat, ceea ce conduce la creterea
competiiei intre firme ntr-un mediu dinamic care devine din ce n ce mai concurenial.
Sistemul de organizare, prin volumul i structura atribuiilor, a deciziilor adoptate i a
responsabilitilor, precum i prin numrul relativ mare al verigilor ierarhice superioare
ntreprinderii. se poate constitui ntr-un factor blocant n calea descentralizrii manageriale
specifice economiei de pia.
Factorii tehnici i tehnologici au o influen direct asupra gradului de nzestrare
tehnic i a ritmului de modernizare a tehnologiilor de fabricaie i a produselor, cu implicaii
sensibile n managementul ntreprinderii.
Importana factorilor demografici este justificat de poziia prioritar pe care o au
resursele umane, de calitatea i competena lor, depinznd calitatea i succesul activitilor
desfurate de ntreprindere.
Dintre factorii socio-culturali, un rol decisiv l are nvmntul, care trebuie s
contribuie att la mbuntirea structurii socio-profesionale ct i la formarea unei mentaliti
specifice economiei de pia.

10

Managementul microeconomic este de asemenea, influenat de factorii politici, prin impactul

acestora asupra fundamentrii strategiilor i politicilor firmelor precum i asupra deciziilor de
realizare a obiectivelor stabilite.
n condiiile accenturii crizei de materii prime i de resurse energetice are loc o diversificare i o
cretere a complexitii interdependentelor dintre factorii naturali (ecologici) i unitile
economice, fapt ce necesit un efort deosebit i utilizarea unor tehnici moderne de investigare i
de analiz pentru cunoaterea i valorificarea acestor interdependene de ctre managementul
microeconomic.
Cunoaterea n detaliu de ctre organismele de conducere a firmelor, a caracteristicilor i a
mutaiilor survenite n mediul ambiant este necesar, dac se au n vedere cel puin urmtoarele
aspecte:
analiza evoluiei mediului, reprezint o condiie fundamental a satisfaceri unor nevoi
sociale de ctre o unitate economic, i n acelai timp, o condiie necesar de supravieuire i
de dezvoltare a acesteia, prin elaborarea de strategii i politici fundamentate tiinific prin
valorificarea conexiunilor cu factorii din mediu;
analiza factorilor din mediul specific unitii economice, permite asigurarea cu resursele
necesare n vederea funcionrii i dezvoltrii eficiente a acesteia;
cunoaterea evoluiei factorilor din mediu, constituie o premis de baz pentru
conceperea i funcionarea eficient a unor subsisteme organizatorice i informaional
decizionale care s satisfac necesitile i oportunitile prezente i de perspectiv ale
mediului.
Mediul unui sistem cuprinde toate elementele aflate n afara granielor sale, dar care au
influene directe sau indirecte n stabilirea obiectivelor, obinerea resurselor necesare, adoptarea
i aplicarea deciziilor etc., menite s favorizeze sau s perturbe desfurarea normal a
activitilor sistemului considerat.
De exemplu mediul unei firme productive este format din pia, bnci, instituii
guvernamentale, alte firme, etc., cu care aceasta se afl n relaii economico-financiare(Figura
1.1).

11

Pia

Instituii
Guvernamentale

Sistem
(firm)
Alte firme

Bnci
Fig. 1.1 Mediul unei firme

n funcie de probabilitatea producerii evenimentelor putem considera:

medii deterministe (certe), n care probabilitatea producerii evenimentelor poate fi

maxima (evenimente certe),

medii cu perturbaii (riscante), n care probabilitatea de realizare a evenimentelor sunt

cunoscute;

medii turbulente (incerte), n care probabilitile de realizare a evenimentelor sunt

necunoscute.
Majoritatea sistemelor economice reale au medii nedeterministe n care evenimentele se
produc cu probabiliti care sunt foarte greu de estimat.
Spre exemplu, dac pentru o firm se consider mediul descris n figura de mai sus, atunci,
numai prin considerarea ctorva variabile caracteristice, specifice acestora, cum ar fi cererea de
produse i servicii manifestat pe diferite segmente de pia, oferta de bunuri i servicii a firmei
respective i a celorlalte firme, preturile bunurilor i serviciilor practicate de firma i de firmele
competitoare, politicile de mprumuturi i dobnzi practicate de bnci, legile i actele normative
existente n vigoare etc., rezult n mod elocvent caracterul incert al mediului considerat.
n mediile supuse perturbrilor, sistemele i vor defini strategiile prin evaluarea
posibilitilor de aciune (alternativelor) pe baz de observaii i analize complexe.
n cadrul sistemului decizional, apare necesitatea estimrii probabilitilor pentru fiecare stare a
naturii i a probabilitilor de realizare a evenimentelor, precum i a adoptri unor decizii n
condiii de risc i incertitudine.
n acest sens, analiza i proiectarea sistemelor informatice va avea n vedere:

identificarea variantelor, din care managerul o va selecta pe cea

optim;
evidenierea strilor naturii i a probabilitilor aferente;
12

stabilirea strategiilor de aciune, conform unor criterii (economice, tehnice, sociale,

ecologice) independente ca sens i cauzalitate, specifice sistemului;
evidenierea consecinelor rezultate prin alegerea unei strategii din punct de vedere al
unui criteriu i n condiiile realizrii unei anumite stri ale naturii;
stabilirea obiectivelor ca nivele ale consecinelor ce se urmresc a fi realizate din punct
de vedere al fiecrui criteriu n parte.
Sistemul i dezvolt acele elemente capabile s acumuleze informaii referitoare la natura
mediului. Printr-un proces continuu de nvare, are loc adaptarea sistemului la mediul su.
Monitorizarea mediului devine astfel una din atribuiile de baz ale unui sistem. n general
sistemele fac fa cu greu mediilor nedeterministe dar celor puternic perturbate n care pot fi
distruse.
Specializarea acestor subsisteme este determinat, pe de o parte, de scopurile sistemului la
realizarea crora ele vor contribui, iar pe de alt parte, de legturile sistemului cu mediul su.
Studierea mediului ambiant i a multiplelor conexiuni dintre mediu i unitatea economic,
faciliteaz cunoaterea dependenelor complexe existente ntre acestea, a
influenelor/impactului mediului asupra eficienei economico-sociale a unitii economice
respective, de care trebuie s se in cont n procesul de management i de fundamentare a
strategiilor sale.

1.2 Reprezentarea sistemic a unei organizaii

n cadrul lucrrii de fa prin organizaie se va referi o ntreprindere, instituie, societate
comercial.
n condiiile societii informatizate o organizaie nu poate supravieui fr s dispun de
informaii n timp real, att din interior, ct i din exteriorul su. Sarcina de colectare, prelucrare,
stocare i furnizare ale informaiilor i cunotinelor revine sistemului informaional al unei
ntreprinderi. Drept urmare, din punct de vedere informaional, o ntreprindere modern trebuie
s fie cuplat la cele mai moderne tehnologi informaionale i de comunicare ale momentului la
care ne raportm.
n orice organizaie un loc central n ansamblul operaiunilor pe care le genereaz l
ocup prelucrrile informaionale. Astfel, este imposibil de conceput o activitate exercitat n
perimetru unei ntreprinderi care s nu necesite ntr-un anumit stadiu o prelucrare a datelor i
informaiilor dup o anumit specificaie. n noile condiii, toate organizaiile dispun de sisteme
informaionale proprii, cu sau fr sisteme informatice foarte dezvoltate, care au ca scop operaii
de colectare, prelucrare, depozitare i transmitere ale datelor i informaiilor.
13

Prin sistem informaional nelegem ansamblul de resurse materiale i financiare care

utilizeaz tehnologiile informaionale pentru a culege, prelucra, stoca, regsi, transmite i
vizualiza informaiile utilizate n procesele ce au loc n perimetrul unei ntreprinderi.
n condiiile n care ne referim la procesele economice care au loc ntr-o ntreprindere,
atunci vom avea sisteme informaionale economice.
Este cunoscut faptul c la baza unui sistem informaional modern st sistemul informatic ca
parte component esenial i cu o pondere n continu cretere.
Sistemul informatic este definit de literatura de specialitate ca reprezentnd un
ansamblu de metode, procedee, echipamente i personal de specialitate, care asigur
culegerea, verificarea, transmiterea, stocarea i prelucrarea informaiilor destinate altor
subsisteme i n special conducerii pentru luarea de decizii n timp util.
Atunci cnd se descrie un sistem informaional se ine cont de structura sa, adic de un
ansamblu de funcii i finaliti i de evoluia acestuia n interaciunea cu mediul.
Structura unui sistem informaional presupune existena unei baze materiale (de cele mai multe
ori echipamente electronice, conectic i consumabilele aferente), a unor proceduri/aplicaii
specializate i a unui personal specializat.
Funciile sistemului informaional sunt analizate prin prisma activitilor derulate prin crearea,
depozitarea, tratarea datelor i transmiterea informaiilor.
Finalitatea unui sistem de informare const n faptul c membrii unei organizaii sunt ajutai n
realizarea i evaluarea sarcinilor lor. Cu alte cuvinte, se obin informaii care sunt necesare
pentru realizarea activitilor operaionale i pentru gestiunea eficient a resurselor.
O organizaie se definete ca o form structurat social stabil care ia resurse din
mediu i le transform n vederea obinerii produselor sau serviciilor. Din punct de vedere
comportamental, organizaia se definete ca fiind o colecie de drepturi, de privilegii, de obligaii
i responsabiliti, care sunt uor echilibrate n timp prin conflicte i rezolvarea acestora. Din
punct de vedere tehnic, organizaia se prezint sub forma unui sistem cu intrri, cu ieiri, cu
prelucrri i cu bucl de autoreglare.
Din punct de vedere organizaional, o ntreprindere poate fi structurat dup una din
urmtoarele logici: ierarhic-piramidal, ierarhic-funcional, funcional, pe centre de venituri,
geografic, matricial, n reea i conglomerat. n ultimul timp, dintre toate acestea capt o
importan deosebit modelul de organizare n reea, datorit gradului mare de flexibilitate pe
care l prezint o asemenea organizaie.
Altfel spus, un sistem informaional este definit ca o combinaie organizat de oameni,
echipamente, programe, reele de comunicaii i resurse de date care colecteaz, transform i
distribuie informaii ntr-o organizaie.
14

Aadar, putem considera ansamblul activitilor din cadrul unei ntreprinderi ca fiind
rezultatul aciunii conjugate a trei subsisteme (pe care pentru simplificare le vom numi sisteme,
interschimbabilitatea noiunilor fiind admis):
sistemul de conducere (de management sau decizional), ce are rolul de a conduce
activitile ce se desfoar n cadrul ntreprinderii pentru realizarea obiectivelor
stabilite, constituind regulatorul ntregului sistem;

sistemul operaional (condus sau de execuie), ce are menirea de a

executa
operaiunile din cadrul activitii declanate ca urmare a unei decizii, folosind resursele
stabilite conform obiectivelor;

sistemul informaional (de legtur), ce asigur legtura n ambele sensuri ntre cele
dou sisteme
Organizaiile pot fi considerate ca un sistem ce trateaz fluxuri de materiale i fluxuri
informaionale n vederea atingerii obiectivelor impuse de obiectul de activitate. Totui, la rndul
su, acest sistem se poate descompune ntr-un anumit numr de subsisteme, fiecare avnd
drept scop s asigure un ansamblu de operaii necesare pentru funcionarea la nivel global a
organizaiei. n cadrul fiecrui subsistem se pot identifica principalele subsisteme de informare
pe care acestea le implic, dar care reunite (privite n ansamblul lor) formeaz sistemul
informaional al ntreprinderii.(Figura 1.2).
control

Sistem decizional
comunicare

feed-back

Sistem informaional
comunicare

Resurse economice
oameni
bani
materiale
utilaje
energie

Procese

organizaionale

realizare de produse i
servicii
marketing
desfacere alte procese

Fig 1.2 Sistemul organizaional

15

Produse i servicii
produse
servicii
pli
informaii
alte
rezultate

Sistemul informaional ofer elemente pentru cunoaterea modului de desfurare a

fenomenelor i proceselor de natur economic i social dintr-o organizaie. Atunci cnd apare
o problem care trebuie rezolvat, n domeniul produciei, al vnzrilor, al personalului, sistemul
informaional ajut la evaluarea situaiei existente, la depistarea cauzelor care o provoac. El
reprezint un sprijin pentru managerii de la orice nivel ierarhic i asigur o intervenie operativ
i competent n organizarea i dirijarea activitilor, o exercitare corespunztoare a controlului
aplicrii deciziilor luate.
Un sistem informaional modern trebuie s asigure:

informarea la toate nivelele;

operativitatea informrii;

selectarea informaiilor;

adaptabilitatea la modificri (modificarea cererilor de informaii, modificarea datelor de

intrare, modificarea structurii organizatorice, modificarea metodelor de prelucrare a datelor);

precizia i exactitatea informaiilor.

Sistemul informatic preia i dezvolt o parte din baza informaional i operaiile de prelucrare
ale sistemului unitii economice, putnd fi privit din acest punct de vedere ca un subsistem
informaional automatizat. Raportul dintre sistemul informaional i cel informatic fiind de ntregparte (Figura 1.3).

SISTEMUL
INFORMATIC

INFORMAIONAL

SISTEMUL

SISTEMUL DE MANAGEMENT

SISTEMUL OPERAIONAL

Fig. 1.3 Locul sistemului informatic n raport cu sistemul informaional

16

Obiectivele principale ale sistemelor informatice economice constau n:

creterea operativitii n informarea conducerii i luarea deciziilor la toate nivelurile;

creterea eficienei economice n toate domeniile de activitate.

reducerea volumului documentelor i corespondenei scrise

utilizarea eficient a personalului cu nalt calificare prin eliberarea sa de activitile de

rutin;
Sistemul informatic asigur memorarea i prelucrarea automata a unei pri a informaiilor dintro unitate economic, pentru a asigura urmtoarele cerine:

asigurarea, simplificarea i ameliorarea lucrrilor i procedurilor informaionale care

presupun simpla execuie a unor operaii i prelucrri de rutin;

asistarea i sprijinirea procesului de conducere, i n mod deosebit a procesului

decizional;
Avnd n vedere c decizia aparine omului, sistemul informatic are rolul de a-i furniza toate
elementele necesare i de a-i permite s fac alegerea deciziei optime pe baza unui maxim de
informaii. De asemenea, sistemul informatic poate servi ca instrument de simulare, permind
evaluarea rapid a consecinelor previzibile ale fiecrei decizii i adoptarea celei mai eficiente.
Informatizarea poate cuprinde, n mod obiectiv, numai acele pri din sistemul informaional care
sunt formalizabile prin definirea unor funcii de transformare a intrrilor n ieiri.
Cercetrile din domeniul modelrii matematice a proceselor economice, cat i cele din domeniul
inteligentei artificiale conduc la lrgirea continu a ariei de utilizare a informaticii n cadrul
unitilor economice.
Utilizarea calculatorului pentru rezolvarea unui grup omogen de lucrri sau probleme ale unitii
beneficiare constituie o aplicaie informatic cu meniunea ca un sistem informatic poate
cuprinde una sau mai multe aplicaii informatice. Aria unei aplicaii informatice este determinat
de omogenitatea funcional a prelucrrilor realizate i de delimitarea dintre procesele
formalizabile i cele neformalizabile.
n cadrul unui sistem informatic pot exista mai multe aplicaii care folosesc aceleai informaii
sau informaii generate de alte aplicaii. n asemenea situaii, pentru a evita introducerea
repetat a informaiilor comune, se apeleaz la integrarea sistemului.
Un sistem informatic integrat asigur preluarea unic a fiecrei informaii i difuzarea acestora
tuturor aplicaiilor care o solicit.
Integrarea sistemelor informatice se poate realiza pe urmtoarele ci:

memorarea fiecrei informaii. astfel nct s corespund integral tuturor cerinelor

specifice ale aplicaiilor i s fie disponibil pentru fiecare dintre ele;
17

transmiterea informaiilor ntre aplicaii sub forma fiierelor de interfa prin care se

asigur jonciunea dintre aplicaii;

Integrarea poate fi realizat la nivelul unui sistem informatic specific unei uniti economice, sau
ntre sisteme informatice aparinnd unor uniti intre care exist relaii de subordonarecoordonare i care pot fi dispersate teritorial (de exemplu o sucursal cu filialele sale se gsete
n relaii de subordonare coordonare ).
Din punct de vedere fizic integrarea poate fi realizat prin intermediul unei reele de
calculatoare, s asigure distribuirea coleciilor de date memorate ntre unitile economice ce se
afl n relaii de subordonare, n vederea furnizrii necesarului de informaii pentru fiecare dintre
acestea.
n aceste condiii, integrarea conduce la arhitecturi de sisteme informatice ierarhizate, cu
prelucrare, manipulare i stocare distribuit a datelor, n care prelucrarea interactiv i n timp
real are o pondere tot mai nsemnat.
1.3 Componentele i resursele sistemului informatic
Schematic, prin prisma activitilor, un sistem informatic poate fi reprezentat prin triada:
intrri prelucrri ieiri (Figura 1.4).

Intrri
date
informaii
operaiuni

Ieiri
lista/raport
grafice
indicatori alte
ieiri

Prelucrri
hardware
software
resurse
umane

stocare
Control
analize decizii

Feed - back

Fig. 1.4 Structura unui sistem informatic

18

Din reprezentarea grafic se observ componentele de baz ale oricrui sistem

informatic, i anume: resursele umane, resursele hardware, resursele software, resursele de
date i resursele de reele.
n tabelul 1.1 este prezentat o sintez pe care am realizat-o cu privire la resursele sistemului
informatic i produsele informaionale.
Tabelul 1.1
Resurse umane
Specialiti analiti de sistem, programatori, operatori.
Utilizatori finali orice alt persoan care utilizeaz sistemele informatice.
Resurse hardware
Calculatoare microcalculatoare (calculatoare personale), minicalculatoare, calculatoare
miniframe.
Alte dispozitive ecrane video, tastatur, mouse, scanner, imprimant, plotter
Medii de stocare dischete, benzi magnetice, discuri magnetice, optice, CD-ROM, DVD,
cartele de plastic, formulare de hrtie.
Resurse software
Programe sisteme de operare, aplicaii pentru procesarea textelor, calcul tabelar,
prezentare, pachete de aplicaii pentru gestiunea clienilor, salariilor.
Proceduri proceduri pentru introducerea datelor, de corectare a erorilor.
Resurse de date
Descrieri ale produselor.
nregistrri privind clienii.
Fie ale angajailor.
Baze de date cu stocurile, partenerii firmei etc.
Resurse de reele
Medii de comunicaii cabluri UTP, coaxiale sau din fibr optic, sisteme cu microunde,
sisteme de comunicaii prin satelit.
Suport de reea procesoare de comunicaii (modem, router, server, hub), software de
control i de acces la reea (sisteme de operare de reea, navigatoare Internet).
Produse informaionale
Rapoarte pentru management, documente i situaii cuprinznd text, grafice.
Elemente audio i video.
Tabelul 1.1 Resursele sistemului informatic i produsele informaionale.

19

Resursele hardware cuprind totalitatea mijloacelor tehnice de culegere, transmitere,

stocare i prelucrare a datelor.
Resursele software includ totalitatea programelor pentru funcionarea sistemului
informatic, n concordan cu funciunile i obiectivele ce i-au fost stabilite. Se au n vedere att
programele de baz (SOFTWARE-ul de sistem), ct i programele aplicative (SOFTWARE-ul
aplicativ).
Resursele umane reprezint toate categoriile de utilizatori care au acces la baza de
date n diverse faze ale ciclului de via al acesteia.
Resursele de date cuprind datele supuse prelucrrii, fluxurile informatice, sistemele i
nomenclatoarele de coduri. Principalele structuri ale acestuia sunt bazele de date ce se
regsesc sub forma coleciilor de fiiere, tabele i alte depozite de date, precum i relaiile dintre
acestea.
Resursele de reele se refer la totalitatea echipamentelor i tehnologiilor de
comunicaie a datelor ntre sisteme.
Analiznd aceste componente, putem spune c performanele unui sistem informatic se pot
aprecia n principal, pe baza urmtoarelor cerine:

s fie o colecie de date corect proiectat i implementat;

s conin programe aplicative de transformare a datelor n informaii;

s ofere informaii centralizate pentru managementul produciei.

1.4 Clasificarea sistemelor informatice

Este evident c ntr-o organizaie, i n general n organizaiile mari, funcioneaz n
paralel i n interdependena mai multe subsisteme informaionale n funcie de activitile ce se
desfoar n ntreprindere, de angajaii care particip la aceste activiti, de compartimentele
funcionale implicate.
Din cauza interdependenei acestor subsisteme, este dificil ca ele s fie delimitate,
mrimea i structura lor fiind diferite de la ntreprindere la ntreprindere. Muli autori au ncercat
totui s stabileasc diverse tipuri de sisteme informaionale ns prerile acestora difer.
James A. Senn a fcut o astfel de determinare n lucrarea sa Informating Sistems n
Management i a stabilit c exist patru tipuri de sisteme informaionale:
Sistemul de procesare a tranzaciilor care presupune prelu-crarea datelor
referitoare la tranzacii. Operaiile la care sunt supuse aceste date sunt nregistrarea,
clasificarea, sortarea, calculaia, totalizarea, stocarea i listarea rezultatelor;
Sistemul

informaional

pentru

management

(sistemul

rapoartelor

manageriale) furnizeaz informaii pentru fundamentarea deciziei unde informaiile necesare pot
fi identificate n avans. Deciziile fundamentate prin acest sistem se repet frecvent;
20

Sistemul de fundamentare a deciziei (sistemul suport) care asist managerii

n luarea unor decizii unice i nerepetabile care sunt relativ nestructurate. O parte a procesului
decizional este s se determine care factori sunt luai n considerare i ce informaie este
necesar;
Sistemul informaional al de birou (office sistem) care combin procesarea
datelor, telecomunicaii i procesarea pe calculator a informaiilor de birou redactate manual. n
general acest sistem informaional este o reproducere n miniatur a sistemului informaional de
la nivelul organizaiei.
Un alt criteriu de clasificare al sistemelor informatice este n funcie de nivelul ierarhic
ocupat de sistemul economic n structura organizatoric a organizaiei:

Sisteme informatice pentru conducerea activitii la nivelul organizaiilor

economice. Acestea pot fi descompuse n subsisteme informatice asociate funciunilor
organizaiilor economico-sociale sau chiar unor activiti.

Sisteme informatice pentru conducerea activitii la nivelul organizaiilor

economico-sociale cu structur de grup. Sunt incluse sistemele informatice la nivelul regiilor
autonome.

Sisteme informatice teritoriale. Sunt constituite la nivelul unitilor

administrativ-teritoriale i servesc la fundamentarea deciziilor adoptate de ctre organele locale
de conducere.

Sisteme informatice pentru conducerea ramurilor, subramurilor i

activitilor la nivelul economiei naionale. Se constituie la nivelul ramurilor, subramurilor i
activitilor individualizate n virtutea diviziunii sociale a muncii i specificate n clasificarea
ramurilor economiei naionale.

Clasificarea sistemelor informatice dup scopul urmrit:

Automatizarea activitilor de rutin;

Sprijinirea proceselor de comunicare;

Sprijinirea procesului decizional;

Sprijinirea top-managerilor;

Clasificarea sistemelor informatice dup elementul supus analizei:

Sisteme informaionale orientate spre funcii;
Sisteme informaionale orientate spre procese;
Sisteme informaionale orientate spre date;
21

Sisteme informaionale orientate spre obiecte;

Sisteme informaionale orientate spre mesaje /comunicri;
Sisteme informaionale orientate spre informaii tiinifice.
Clasificarea sistemelor informatice dup modul de organizare a datelor:
Sisteme bazate pe fiiere clasice;
Sisteme bazate pe tehnica bazelor de date: ierarhice, reea, relaional,
orientate-obiect, neuronale;
Sisteme mixte;
Clasificarea sistemelor informatice dup metoda folosit n analiza i proiectarea
sistemelor:
Sisteme dezvoltate dup metoda sistemelor;
Sisteme dezvoltate dup metoda clasic a ciclului de via a sistemelor;
Sisteme dezvoltate dup metoda structurat;
Sisteme dezvoltate dup metoda orientat obiect;
Sisteme dezvoltate dup metoda de realizare rapid (RAD Rapid Application
Development);
Sisteme dezvoltate dup metoda echipelor mixte (JAD Join Application
Design);
Sisteme dezvoltate dup metoda participativ;
Sisteme dezvoltate dup metoda prototipurilor.
Teste de evaluare a cunotinelor
1. Structura de ansamblu a unui sistem informatic e format din triada:
a. reprezentare afiare - tiprire
b. introducere, memorare i afiare date
c. adunare scdere i nmulire date
d. intrri prelucrri- ieiri
e. prelucrare, calcule i stocare

22

2. Relaia existent ntre sistemul informaional i sistemul decizional, precum i legtura

stabilit ntre sistemul informaional i sistemul condus este scos n eviden de:
a. abordarea sistemic
b. ciclul de abstractizare
c. ciclul de via
d. diagrama fluxului de date
e. nivelul conceptual

3. Sistemul informaional :
a. se definete ca fiind un ansamblu de procedee i mijloace de colectare, prelucrare i
transmitere a informaiei necesare procesului de conducere
b. a adus o varietate de procedee pentru obinerea i prelucrarea datelor, n vederea
utilizrii lor n gestionarea unei uniti economice
c. asigur simularea lipsei evoluiei diverilor indicatori sub aciunea factorilor de
influen
d. elimin concurena neloial practicat de unii distribuitori de sisteme de calcul, prin
oferirea de programe cu licen
e. retrage resursa n momentul n care procesorul a efectuat n totalitate execuia i
renun la utilizarea licenei, sau cnd a fost depit intervalul de timp alocat

4. Sistemul informatic este:

a. un ansamblu structurat i corelat de proceduri i echipamente electronice de calcul,
care permit culegerea, transmiterea i prelucrarea datelor, obinerea de informaii.
Sistemul informatic lrgete cmpul de aciune al sistemului informaional, i
potenteaz valenele, mbuntindu-l sub aspect calitativ

23

b. supus procesului de prelucrare, ce const n sortare pe operaii

c. o premis important pentru organizarea raional a sistemului de eviden economic
d. bine organizat n cadrul fiecrei uniti, care s dein toat legislaia i literatura de
specialitate actual, sub forma unei biblioteci de specialitate
e. completaz literatura de specialitate, prin explicaii, exemple, inclusiv calcule i
modaliti de nregistrare-prelucrare

5.

Sistemul informational economic:

a. observ i nregistreaz activitile care se desfoar, existena i micarea bunurilor

i a relaiilor, obtinnd date de baz pe care le prelucreaz, le transform n informaii,
le prezint conducerii pentru luarea deciziilor, iar apoi, acestea sunt transmise
organismelor interesate, urmrind, n continuare, aducerea lor la ndeplinire
b. a adus o varietate de procedee pentru obinerea i prelucrarea datelor, n vederea
utilizrii lor n gestionarea unei uniti economice
c. asigur simularea lipsei evoluiei diverilor indicatori sub aciunea factorilor de
influen
d. elimin concurena neloial practicat de unii distribuitori de sisteme de calcul, prin
oferirea de programe cu licen
e. retrage resursa n momentul n care procesorul a efectuat n totalitate execuia i
renun la utilizarea licentei, sau cnd a fost depit intervalul de timp alocat

24

Capitolul 2
Metodologii de realizare a sistemelor informatice
Obiective:
Cunoaterea metodologiilor de realizare a sistemelor informatice
Selectarea i integrarea metodelor de abordare a sistemelor informatice
nsuirea tehnicilor i metodelor de realizare a sistemelor informatice
Identificarea etapelor ciclului de via a dezvoltrii sistemelor informatice
Cuvinte cheie: ciclul de via a dezvoltrii sistemelor informatice, metode de abordare a
sistemelor informatice, metoda Merise, metodologii de realizare a sistemelor informatice.
Elaborarea unui produs informatic constituie o activitate deosebit de complex. O
asemenea activitate nu se poate desfura dect pe baze metodologice riguroase, generatoare
de eficienta i eficacitate n management i n plan economic.
Etapele de realizare a unui sistem informatic: analiz, proiectare, implementare sunt
unanim recunoscute de toi realizatorii de sisteme informatice. Nu se pune n discuie denumirea
etapelor sau succesiunea lor, ci modul de grupare a activitilor necesare procesului de
elaborare a unui sistem informatic. Din aceste considerente etapele de realizare a unui sistem
informatic sunt tratate n detaliu sau mai superficial, n functie de contextul n care au aprut i
n funcie de modul concret de realizare a unui sistem informatic.
Un aspect comun pentru aceste etape i activiti este faptul c trecerea de la o etap la alta se
face numai dupa o analiz de fond a modului de realizare a sarcinilor, etapelor parcurse i
avizrii de ctre factorii de rspundere ai beneficiarului a rezultatelor obinute.
De asemenea, orice etap, parcurs deja, se finalizeaz cu activiti de pregtire a etapei
urmtoare, prin elaborarea sau actualizarea planului de lucru.
Se desprinde concluzia, c realizarea unui sistem informatic impune folosirea unor resurse
materiale, umane i financiare, iar utilizarea eficient a acestora nu se poate realiza dect
apelnd la cele mai performante i moderne metodologii de realizare a sistemelor informatice.
Putem defini metodologia de realizare a unui sistem informatic ca o implementare fizic a
ciclului de via a sistemelor care include:
25

activiti pas cu pas pentru fiecare etap de lucru;

regulile individuale i de grup pentru fiecare activitate;

standardele de calitate n fiecare activitate;

tehnicile utilizate n fiecare activitate.

O metodologie de realizare a unui sistem informatic este o mulime de concepte

fundamentale, reguli de notaie, ce sunt utilizate mpreun cu mulimea proceselor i a regulilor
empirice recomandate pentru construirea modelelor i implementarea lor. Altfel spus, o
metodologie este o expresie a ciclului de viata considerat ca fiind cel mai adecvat pentru
dezvoltarea unui sistem dat.
Din aceste definitii, constatm c o metodologie de realizare
a unui sistem informatic trebuie s cuprind:

modul de abordare a sistemelor informatice;

modaliti de derulare a ciclului de viata a sistemelor informatice;

metode i tehnici de realizare a sistemelor informatice;

modaliti de conducere a proiectului (planificare, organizare, urmrire).

2.1 Metode de abordare a sistemelor informatice

Metodele de abordare a sistemelor informatice s-au transformat i evoluat n paralel cu
dezvoltarea tehnologiilor informaionale, a sistemelor informaionale i a organizaiilor.
Multitudinea metodelor de abordare, determinat de caracteristicile activitilor necesare
realizrii sistemelor informatice, au fost comentate (caracterizate) de muli autori de specialitate,
dar le vom descrie pe cele considerate mai edificatoare.
Autorii Yourdon i Argila efectueaz o trecere n revist nu a metodelor, aa cum le-am intitulat
noi anterior, ci a colilor.
De la forma incipient a anilor 1950-1960, ce ar putea fi botezat a programelor
inteligibile, referirea n mod evident fiind o trimitere la neputin nelegerii de ctre majoritatea
utilizatorilor calculatoarelor a programelor scrise n cod main sau n criptatele limbaje de
asamblare, s-a ajuns la un important moment de progres: modularizarea programelor.
Din curentul gndirii modulare s-a desprins coala descompunerii funcionale. De fapt,
autorii consider c aceasta ar fi prima coal veritabil de abordare a sistemelor, n fiecare
modul existnd cte o funcie.
Alta coal, concurent celei amintite anterior, pune la baza modulelor, datele. Crezul
ei este formulat astfel: Fiecare modul trebuie s aib ncapsulat o structur de date. Numai c
26

proiectanii aplicaiilor n timp real aveau alt opinie, i anume: Fiecare modul trebuie s
recunoasc i s rspund unui eveniment.
Analiznd colile prezentate, putem spune c ele sunt orientate spre funcii, spre date
i spre evenimente. Pe acest fond, Yourdon i Argila afirm c apare o a patra coal, cu crezul:
Fiecare modul corespunde unui i numai unui singur obiect din lumea real Autorii ajung la
concluzia c structurarea programelor nu va mai fi efectuat n funcie de metodele de analiz,
ci, n varianta orientat-obiect, ea se va efectua n concordan cu problema de rezolvat. Virtual,
orice component a ciclului de via al ingineriei softului poate fi ncapsulata ca un obiect
reutilizabil.
Istoricul colilor de mai sus este precedat de o alt grupare a metodelor de analiz,
realizat tot de Yourdon2, ns n echip cu Peter Coad. Cei doi autori prezint patru modaliti
de abordare a analizelor, considerate ca instrumente ale gndirii utilizate pentru a ajuta la
formularea cerinelor. Cele patru metode sunt orientate spre funcii, procese, informaii (date),
ultima fiind cea orientat obiect. Autorii fac meniunea c nu se pune problema desfiinrii
metodelor vechi, ci a incorporrii celor mai bune idei ale primelor trei metode n una mai
cuprinztoare, atotcuprinztoare analiza orientat obiect.
ntr-o versiune proprie, David Brown sistematizeaz metodele de abordare a sistemelor
informatice n:

metode timpurii nesistematizate (1950 nceputul anilor 1960);

metode orientate-ieiri (sfritul anilor 1960);

metode orientate-proces, prin apelarea la diagramele fluxurilor de date, DFD (anii

1970);

metode orientate-date, prin folosirea diagramelor entitate-relaie, DER (anii1980);

metode orientate-obiect (anii 1990).

D. Oprea, consider c metodele ar putea fi grupate, prin prisma celor mai muli autori, astfel:

metode orientate spre funcii, numite i metode ale descompunerii funcionale;

metode orientate spre fluxuri de date, deci spre procese, deoarece diagramele

fluxurilor de date se ntrebuineaz pentru descrierea proceselor. Deseori, n form lapidar,

aceste metode sunt denumite orientate - date.

metode orientate spre informaii sau date, orientate-informaii, probabil i datorit

popularizrii puternice a ingineriei informaiei a lui James Martin, dar i a diagramelor entitate relaie ale lui Chen;

metode orientate-obiect.

Modern Structured Analysis, Editura: Pearson Education, 1996

27

Oricum, dup cum afirm James Martin i James Odell: ,,exist multe metode de
realizare a sistemelor; ele vor exista ntotdeauna i trebuie s existe ntotdeauna. Diferite
activitii pot avea caracteristici diferite care s necesite moduri diferite de abordare. Provocarea
const n selecia i integrarea acestor metode. De fapt, referindu-se numai la metodele
orientate-obiect, Hoffer, George i Valacich, n 1996, inventariau cel puin 13 sisteme de notaie,
dei, n 1994, T.F. Hutt lansase deja o carte n care erau destul de detaliat descrise
caracteristicile a peste 20 de metode orientate-obiect.
Steve Skidmore, citnd cercetarea lui Ian Graham, n 1997, spune c au fost identificate
probabil 60 de metode complet orientate - obiect. Comentariile sunt de prisos.
Caracteristicile eseniale ale principalelor metode de abordare a sistemelor
Dup prezentarea principalelor opinii exprimate n literatura de specialitate cu privire la
evoluia i clasificarea metodelor de abordare a sistemelor informaionale, vom face o scurt
prezentare a principalelor abordri n dezvoltarea sistemelor informaionale. n acest sens, vom
urma gruparea prezentat n finalul paragrafului anterior i care se regsete de altfel, n mod
explicit sau implicit, n majoritatea opiniilor exprimate n literatura de specialitate.
Metoda descompunerii funcionale (orientate-funcii)
Dintre autorii remarcabili care au abordat descompunerea funcional i enumerm pe
civa, cum ar fi DeMarco, Yourdon i Constantine, Jackson, Page-Jones, Warnier-Orr, Dahl,
Marco & Mc Gowan.
Descompunerea funcional este cea care anun apariia proiectrii structurate i analizei
structurate. Ea a fost conceput cu scopul controlrii complexitii prin operaiuni de tipul devide
et impera. Fiecare funcie este descompus n subfuncii .a.m.d., pn cnd se obin forme
uor de transpus n instruciunile limbajelor de programare.
i n cazul descompunerii funcionale conceptele specifice au fost introduse mai nti n
programarea structurat (Dahl, 1972) i apoi n proiectare, urmat de analiz. Aceeai situaie
este ntlnit i n varianta orientrii - obiect.
Descompunerea funcional (DF) este vzut ca o sum de funcii, subfuncii i interfee
funcionale, sub forma unei ecuaii:
DF=Funcii
+Subfuncii
+Interfee funcionale.

28

Printr-o astfel de reprezentare se ilustreaz modul n care recunoatem o descompunere

funcional. Obiectul l constituie prelucrrile necesare n noul sistem. Analistul va specifica
prelucrrile i interfeele funcionale.
Metoda are ceva puncte tari:
simplitate - fiind o cale natural de rezolvare a unei probleme;
obinerea destul de lejer a cerinelor utilizatorului;
generarea

de

soluii

pe

diferite

niveluri

de

abstractizare

(sistem,

subsistem, funcie, subfuncie).

Ca puncte slabe sunt descrise:
concentrarea eforturilor spre funcii conduce la culegerea multor
date redundante;
inexistena unor reguli precise de descompunere;
evidenierea anevoioas a interaciunilor non-ierarhice din sistemele complexe.
Disfuncionalitile metodei au fost mult anihilate prin soluii ingenioase de tipul coeziunii i
cuplrii, introduse spre sfritul anilor 80 de Page & Jones i Yourdon/Constantine.
Metoda descompunerii funcionale (orientate-funcii)
O alt metod i n acelai timp o alt modalitate de reprezentare a domeniului problemei i
responsabilitilor sistemului printr-o specificaie tehnic este metoda orientat spre procese,
deseori descris ca ,,analiza structurat.
Ecuaia metodei este:
Metoda fluxului de date = Fluxul (i controlul) datelor
+ Transformrile (i controlul) datelor
+ Stocarea (i controlul) datelor
+ Terminatori
+ Specificaii de proces
+ Dicionarul datelor.
Prin aceast metod, analitii efectueaz reprezentarea lumii reale prin linii ale
fluxurilor n analiza structurat. Se vorbete despre o metod ,,veche, cu reprezentanii De
Marco - 1978 i Gane & Sarson - 1977, i despre o metod ,,modern de analiz structurat,
lansat n dezbateri la nivelul anului 1982 i prin materiale editate n 1984 - reprezentative fiind
lucrrile autorilor McMenamin & Palmer, din 1984, i a lui Yourdon, Analiza modern structurat,
din 1989. n ultima variant sunt definite cu claritate evenimentele din lumea real la care
sistemul trebuie s rspund, o form embrionar a actualelor interaciuni dintre utilizator i
sistem, bazate pe mesaje. De asemenea, printr-o documentaie suplimentar, sunt incluse

29

fluxurile datelor i transformrilor la nivel inferior prin intermediul dicionarului de date, respectiv
al specificaiilor proceselor.
Cum metoda orientat pe procese are nc un mare grad de asemnare cu
descompunerea funcional, criticile metodei descrise anterior se raporteaz i n cazul de fa.
Oricum, dup cum se va vedea ulterior, multe elemente ale acestei metode sunt preluate de
ctre metodele orientate-obiect.
Metode orientate spre informaii (orientate-date)
Dou realizri remarcabile n domeniu au dat tonul unei noi orientri n abordarea
sistemelor: modelarea datelor cu ajutorul diagramelor entitate-relaie, de ctre Peter P. Chen
(1976) i ingineria informaiei, n viziunea lui James Martin. Acestora li s-au adugat alte reuite
de esen.
Termenul ,,obiect este lansat la mijlocul anilor 70 ntr-o form ,,original, nestandard, dac ne
gndim fie la semnificaiile anterioare ale lui , fie la cele curente , firesc , din domeniul abordrii
sistemelor. Aa cum este el folosit de Chen , de cei ce se ocup cu modelarea informaiilor (cum
ar fi Flavin, n 1981) sau de cei ce trateaz modelarea semantic a datelor (Shlaer & Mellor, n
1988), obiectul este un simbol prin care se reprezint una sau mai multe ,,ocurene (cazuri) ale
,,entitilor lumii reale.
Metoda este identificat prin urmtoarea ecuaie:
Modelarea informaiilor = Obiecte
+Atribute
+Relaii
+Supertipuri/Subtipuri
+Obiecte asociative
Coad i Yourdon spun c i n acest caz se poate vorbi despre existena a dou strategii.
Strategia veche se bazeaz pe conceperea listei atributelor gruparea lor n obiecte,
stabilirea de relaii ntre ,,ocurene (cazuri), folosirea supertipurilor/subtipurilor pentru
extragerea atributelor comune i definirea obiectelor asociative pentru reliefarea relaiilor sigure.
Noua strategie este destul de apropiat de precedenta, cu excepia primului pas, care i
propune mai nti s identifice obiectele lumii reale i apoi urmeaz descrierea lor cu ajutorul
atributelor.
Specialitii apreciaz salturile nregistrate, ns , n acelai timp fac inventarul conceptelor
inexistente, cum ar fi: servicii,motenire,structur.

30

Metode orientate-obiect
ntruct acest subiect necesit multe descrieri preliminare, deocamdat nu vom face
dect o foarte sumar prezentare. Sintagma ,,orientat - obiect este destul de greu de definit din
cauza accepiunilor diferite ce i-au fost date de diversele discipline. Numai n domeniul
informaticii exist vreo trei variante: una folosit n modelarea informaiilor , alta n programare i
a treia, cea de fa, utilizat n analiza i proiectarea sistemelor, de cele mai multe ori identic
semnificaiei din programare. Fiind un domeniu relativ nou, este normal s existe o mare
diversitate de opinii pn i asupra termenului ,,obiect.
Pentru a continua regula prezentrii ecuaiei ce caracterizeaz metoda, o vom reda n cele ce
urmeaz:
Orientat-Obiect = Clase i Obiecte
+ Motenire
+ Comunicaii prin mesaje.
Conceptele de obiect i clas sunt independente: un obiect aparine unei clase (este o instan
a clasei), iar o clas este o grupare logic a obiectelor care au aceeai structur i un
comportament similar.
Un obiect este o abstractizare a datelor elementare i poate fi descris astfel:
Obiect = Identitate
+ Comportament
+ Stare.
Identitatea obiectului se realizeaz printr-un identificator al obiectului, care este un
atribut invariabil ce permite ca obiectul s fie referit independente de celelalte obiecte.
Identificatorul este generat de sistem la crearea obiectului.
Starea obiectului este o valoare care poate fi simpl (de exemplu, un literal) sau structur(de
exemplu, o list). n ultimul caz, ea poate fi compus din valori simple, referine la alte obiecte
sau valori care sunt structurate ele nsele.
Comportamentul unui obiect este definit printr-un set de operaiuni ce-i pot fi aplicate i
este descris n clasa creia i aparine obiectul.
n concluzie, obiectul este o abstractizare a datelor elementare, caracterizat printr-un
identificator unic, invariabil, o clas creia i aparine i o stare reprezentat printr-o valoare
simpl sau structur.
2.2 Modele ale ciclului de via a sistemului informatic
Mutaiile din domeniul tehnologiilor informaionale i al metodelor de abordare a
sistemelor s-au reflectat i n ciclul de via al dezvoltrii sistemelor, fie prin schimbrile
31

etapelor acestuia, fie prin modificarea ordinii de parcurgere a lor. Indiferent de numele i de
numrul etapelor ciclului de via al dezvoltrii sistemelor, o problem mult mai important este
aceea a ordinii i felului cum se parcurg etapele respective, ceea ce n literatura de specialitate
se trateaz sub numele de modele ale ciclului de viaa a sistemului informatic.
n practic se regsesc urmtoarele tipuri de modele:
model cascad;
model V;
model incremental;
model spiral;
model evolutiv;
model tridimensional;
model X;
model fntn artezian;
model pinball;
model minge de baseball;
model piramid.
Modelul cascad este unul de referin asigurnd trecerea de la o etap la alta n ordinea
secvenial a posibilitii revenirii la etapele anterioare sau parcurgerii n paralel a mai multor
etape. (Figura 2.1)
Definirea
cerinelor

Analiz

Proiectare
Implementare
Testare
Utilizare i
ntreinere

Fig. 2.1Modelul cascad

32

Utilizare i ntreinere
Avantaje:
controleaz toate fazele n sensul ca ele au o ordine strict i aria lor de
ntindere e clar;
modelul este uor de nsuit de membrii echipei de proiectare;
fiecare etap este nsoit de documentaie.
Dezavantaje:
sistemul informatic se pred dup parcurgerea tuturoretapelor ceea ce
nseamn un interval mare de timp, n care preteniile utilizatorului se pot
schimba;
modelul nu corespunde unei abordri dinamice;
nu este deschis schimbrilor.
Modelul V este o variant a celui cascad prin care se introduc conceptele de componente,
subsisteme, aplicndu-se teste explicite la nivel ierarhic pentru creterea controlului asupra
modului n care se desfoar etapele, obinnd n felul acesta o latur a literei V. (Figura 2.2).
Prima latur se parcurge descendent i conine etapele propriu-zise ale unui sistem informatic,
iar a II-a se parcurge ascendent i cuprinde toate etapele de verificare i validare.

Validare

Definirea cerinelor

Testare sisteme

Proiectare sisteme

Proiectare subsistemelor
(componente)

Fig. 2.2 Modelul V

Testare
subsisteme

Codificare/Asamblare
componente

33

Modelul incremental este o alt form a modelului cascad: pn la etapa de proiectare nu

exist diferene. Dup aceea se efectueaz descompunerea proiectului n subproiecte. Fa de
modelul V, ofer posibilitatea atingerii scopului final n dou variante: sistemul global livrat la
sfrit sau componente livrate distinct. (Figura 2.3)
Avantaje:
perioade de realizare scurte pentru c livrarea se face pe componente;
lucrul n echip ofer posibilitate de realizare a mai multor proiecte.
Dezavantaje:
imposibilitatea aplicrii modelului n orice condiii, uneori neexistnd posibilitatea
descompunerii n componente;
costurile de asamblare sunt mult mai mari prin realizarea testelor multiple.

Definirea
cerinelor

ntreinere
componenta 1

Implementare
componenta 1

Analiza

Arhitectura
sistemului

Instalare
componenta 1

Proiectare
componenta 1

Instalare
componenta n

Proiectare
componenta n

Fig 2.3 Modelul incremental

Implementare
componenta n

ntreinere
componenta n

Modelul spiral (Figura 2.4) se bazeaz pe dou convingeri:

natura iterativ a dezvoltrii i nevoia de planificare i evaluare a riscurilor
fiecrei iteraii.
deficiena nregistrrilor la modelul V n care validarea se efectueaz prea trziu.

34

Prototip 1
Prototip 2
Prototip 3

Prototip 4
Fig. 2.4 Modelul spiral
n orice iteraie se va regsi modelul cascad.
Avantaje:
posibilitatea evalurii riscurilor n diferite momente ale proiectului;
simplificarea etapei de evaluare n ceea ce este necesar n etapa (prototipul)
urmtoare, inclusiv prin prisma costurilor.
Dezavantaje:
echipa de realizare trebuie s aib un nalt nivel de profesionalism;
flexibilitate n aciune.
Modelul evolutiv const n descompunerea proiectului n pri, fiecare cu o valoare deosebit
pentru client. Aceste pri sunt realizate i livrate n mod iterativ i contribuie la sporirea
performanelor sistemului. (Fig 2.5)
Prile obinute pentru completare nu sunt foarte detaliate tocmai n vederea adaptrilor i
modificrilor ulterioare.
Oricare din aceste segmente luate n studiu trece prin toate etapele de dezvoltare a sistemului.
Reuita modelului const n crearea unei arhitecturi deschise elaborrii prin participarea tuturor
utilizatorilor.

35

Studiul iniial
Descompunere
n segmente

Segment 1

Segment n

Def. cerine Implementare

Def. cerine Implementare

Analiz

Analiz

Testare

Testare

Fig. 2.5 Modelul evolutiv

Modelul 3D red dezvoltarea sistemului printr-o reprezentare grafic n spaiu. Pe o ax avem
ciclul de via al sistemului (CVS), pe a IIa ciclul de via al proiectului (CVP) i pe ultima ciclul
abstractizrii (CA). (Figura 2.6)
Ciclul de via al sistemului principalele perioade dup care se fac schimbri majore,
creterea volumului de date, modificri tehnologice, modificri structurale.
CA
Sistem generaia I
Nivel conceptual
Sistem generaia II
Nivel logic
Sistem generaia III
Nivel fizic

Studiu preliminar

CVS
T1 T2 T3

Studiu detaliat
Studiu tehnologic

CVP

Fig. 2.6 Modelul 3D

36

Modelul minge de baseball (Figura 2.7) sau dezvoltare concurent: principiul lui este acela al
proiectrii n paralel a activitilor: analiz orientat obiect, proiectare i programare orientat
obiect.
Pentru ca modelul s dea rezultate echipa trebuie s fie format din experi n domeniul
analizei, administrrii datelor, cel al interaciunii umane i medii i limbaje de programare

00A

00D

00P
Fig.2.7 Modelul minge de baseball
Modelul X (Figura 2.8) i propune s extind performanele obinute prin modelul cascad i
prin modelul V. Acesta introduce noiunea de model al livrrii, fiecare proces sau etap a
dezvoltrii sistemelor poate fi privit i urmrit ca o iteraie sau evoluie spre soluia acceptat.
Modelele livrrii sunt independente. Din punct de vedere tehnic. Acest lucru a fcut posibil
exprimarea n partea superioar a X-lui a responsabilitilor softului curent i n cea inferioar a
componentelor fizice ale softului.
Modelul X exprim dou categorii de cicluri de activitate: una derulant nainte care sintetizeaz
sistemul nou i una napoi pentru dobndirea sistemului i a componentelor sale pentru o
posibil reutilizare.

37

Obinerea viziunii i cerinelor

Livrare sisteme

Specificaia sistemului
Proiectare i testare

Testare

sisteme

arhitectur sistem

Selecie i adaptare

Constr, testare
componente

Achiziie
Asamblare

Biblioteca
component
Biblioteca
domeniului

Rafinare
component

Biblioteca
structur

Biblioteca structur

Biblioteca
aplicaiei

Restabilire domeniu

Fig. 2.8 Modelul X

Modelul fntn artezian (Figura 2.9) i are originea n cel cascad, dar reprezint o variant
mbuntit n sensul c perioada de timp pentru finalizare e mai scurt i componentele sale
pot fi reutilizate n modele similare.

38

Studiu
Fond software

Fig. 2.9 Modelul fntn artezian

Modelul pinball (Figura 2.10) const n deplasarea aleatoare a unei bile n mediul orientat
obiect redat sugestiv sub forma unui teren de pinball.

I
M

L
E

Gsire
clase

M
E

Definire
agregri

Determinare

Aflare
metode

atribute

PROIECT

Definire Codificare
colaborri

Gasire
relaii

Definire
subsistem

Testare

Definire
motenire

E
RE

Fig. 2.10 Modelul pinball

39

Modelul piramid (Figura 2.11) se aplic n exclusivitate mediilor orientate obiect. Arat c
etapele unui ciclu de via nseamn trecerea spre mai multe detalii, pornindu-se de la nivelul
superior al planificrii spre analiza domeniului, proiectarea i construirea lui.
Planificarea
ntreprinderii

Analiza domeniului
ntreprinderii

Proiectare
sistem

Fig. 2.11 Modelul piramid

Construcia
componentelor
obiectului

2.3 Clasificarea metodologiilor de realizare a sistemelor informatice

Folosirea eficient a resurselor i necesitatea realizrii unor sisteme informatice
performante au impus ordonarea ntr-o succesiune bine stabilit pe etape i subetape a acestui
proces determinnd conturarea unor metodologii de realizare a sistemelor informatice.
O metodologie de realizare a unui sistem informatic stabilete componentele procesului
de realizare: etapele, subetapele, activitile i coninutul lor; fluxul executrii componentelor,
metodelor, tehnicile i instrumentele de realizare
O metodologie de realizare a unui sistem informatic trebuie s cuprind:

Etapele/procesele de realizare a sistemului infomatic cuprind subetape,

activiti i sarcini;

Fluxul realizrii acestor etape/procese;

Modalitile de desfurare a ciclului de via a sistemului informatic;

Modul de abordare al sistemelor;

Strategiile de lucru/metodele de realizare;

Tehnicile, procedurile, instrumentele, normele i standardele utilizate;

Modalitile de conducere a proiectului i modul de utilizare a resurselor

40

financiare, umane i materiale.

O prim clasificare a metodologiilor se poate face dup gradul de generalizare:
Metodologii generale au un grad nalt de generalitate putnd fi folosit pentru realizarea
sistemelor informatice din diferite domenii.
Enumerm cteva metodologii generale:
SSADM (Stuctured System Analysis and Design Methodology);
MERISE (Methode dEtude et de Realization, Informatique pour les Systemes
dEntreprise);
OMT (Object Modeling Technique);
RUP (Rational Unified Process).
Metodologiile cadru cuprind elemente aplicabile exclusiv numai unor produse software.
Metodologii specializate sunt cele dezvoltate i utilizate pentru implementarea unui singur
produs software. Enumerm cteva metodologii specializate:
AIM (pentru Oracle E Business Suite)<
POIS (pentru Sun Systems);
Extract (pentru Extract);
Signature (pentru Scala);
ASAP (pentru SAP).
A II-a clasificarea a metodologiilor se face dup modul de abordare a sistemelor:
Metodologiile cu abordare structurat
Metodologiile cu abordare orientat obiect
Metodologiile cu abordare structurat au ca principiu de lucru mprirea sistemului n
subsisteme pe baza funciilor sistemului sau n funcie de date.
Aceste metodologii propun modelarea datelor separat de modelarea procedurilor.
Modelarea sistemului se face plecnd de la ideea c sistemul nu este izolat, ci exist n cadrul
unui mediu cu care interacioneaz. Sistemul reacioneaz la evenimentele transmise din mediu
printr-un rspuns. Sistemul este afectat de mediu, dar nu controleaz mediul.
Sistemul este structurat dup diverse criterii n subsisteme pn cnd se ajunge la nivel
elementar, punndu-se n eviden relaiile dintre subsistemele identificate. Abordarea acestor
subsisteme se face din puct de vadere: static, funcional i dinamic. n final rezult modelul logic
41

i modelul fizic. Modelul fizic al sistemului prezint structura tehnic a sistemului, iar modelul
logic al sistemului arat ce face sistemul, fiind mai stabil n timp i independent de
implementare.
Metodologiile structurate prezint avantaje din care prezentm cteva:

planificarea proiectului n subsisteme;

un mediu bine structurat este flexibil din punct de vedere al coportamentului, are
obiective clare, o arie de cuprindere cunoscut;

modificarea unei activiti nu conduce la reluarea integral a studiului.

Metodologiile cu abordare orientat obiect permit construirea sistemelor informatice folosind
conceptele tehnologiei orientate pe obiecte.
Tehnologia orientat obiect a aprut odat cu apariia limbajelor de programare orientate pe
obiecte.
Dintre metodologiile orientate obiect de realizare sistemelor informatice enumerm:

OOD (Object Oriented Design) o metodologie similar metodologiei OMT,

dezvoltnd analiza i proiectarea iterativ elaborat de Gray Booch;

OOA (Object Oriented Analysis) elaborat de Peter Coad i Edward Yourdon;

OOSD (Object Oriented Structured Design) o metodologie elaborat de

Wasserman;

OOSA (Object Oriented System Analysis) o metodologie de proiectare a

sistemelor n timp real propus de Sally Shlaer i Steven Mellor;

OMT (Object Modeling Technique) eleborat de James Rumbaugh i Michael

Blaha.

Toate aceste metodologii prezentau o serie de neajunsuri precum multiple diferene de

simboluri, notaii sau tipuri de diagrame. Aceste aspecte generau dificulti n privina nelegerii,
prelurii i folosirii lor de diferite grupuri de utilizatori, n crearea de noi sisteme sau n procesul
de mentenan a sistemelor.
Marea parte a acestor probleme au fost rezolvate prin introducerea unui standard cu
privire la simboluri, notaii, tipuri de diagrame numit UML (Unified Modeling Language).
Unii analiti programatori utilizeaz doar un subset al UML-ului, alii folosesc ntreg setul UML,
utiliznd diagramele de stare i de activitate pentru a modela sisteme n timp real i diagrama de
implementare pentru a modela sisteme distribuite.
Metodologiile orientate obiect prezint avantaje din care prezentm cteva:
Datele i prelucrrile nu sunt reprezentate distinct, ci ncapsulat n clase de obiecte,
mrinduse coerena rezultatelor analizei;
42

Modele utilizate sunt flexibile i uor de ntreinut;

mbuntirea comunicaiei ntre utilizatori, analiti, proiectani i programatori;
Reutilizarea rezultatelor analizei, proiectrii i implementrii;
Reprezentarea explicit a elementelor comune tuturor componentelor sistemului.
2.4 Metode i tehnici de realizare a sistemelor informatice
Metodele utilizate n proiectarea sistemelor informatice reprezint modul unitar sau
maniera n care analitii de sistem, programatorii realizeaz procesul de analiz a sistemului
informaional - decizional existent, proiectarea i introducerea sistemului informatic. Metoda are
un caracter general, n cadrul ei aplicndu-se anumite tehnici de lucru.
Tehnicile de lucru utilizate n proiectarea sistemelor informatice reprezint felul n care
se acioneaz eficient i rapid, n cadrul unei metode, pentru soluionarea diferitelor probleme ce
apar n procesul de proiectare.
n activitatea de realizare a sistemelor informatice unele dintre metode i tehnici sunt
specifice activitii de analiz, proiectare sau programare,altele sunt generale i pot fi utilizate n
toate etapele de realizare a sistemelor informatice.
Dintre metodele i tehnicile utilizate n realizarea sistemelor informatice enumerm:
Metoda descendent (Top-Down);
Metoda ascendent (Bottom-Up);
Metoda LCS/LCP (Logical Construction of System / Programs)
Tehnica concordanei intrri-ieiri
Tehnica HIPO;
Metoda descendent (Top-Down)
Metoda const n descompunerea unui sistem complex pe niveluri ierarhice, succesiv,
pn la module elementare, simple i relativ independente care sunt controlate de module
coordonatoare.
Metoda are ca cerin de aplicare modularizarea sistemului, obiectivul principal fiind realizarea
modularizrii de sus n jos, rezultnd i obiectivele specifice: crearea posibilitii de realizare n
paralel a componentelor sistemului informatic i eliminarea din sistem a redundanelor.
Rezultatul realizrii modularizrii este modulul.
Modulul terminal este cel care nu mai poate fi descompus. Orice modul se poate
integra cu un alt modul formnd noi module i poate fi integrat mediului din care provine.
Procesul de descompunere se repet pn cnd toate modulele sunt considerate terminale.
Descompunerea are la baz urmtoarele reguli:
43

Nivelul zero de descompunere sau punctul iniial de pornire l reprezint modul

neterminal sau coordonator;
Pentru toate modulele neterminate ale unui nivel se aplic descompuneri succesive n
pai de sus n jos;
Descompunerea este terminat cnd modulele ultimului nivel sunt terminale.
Aceast metod prezint avantajul c ofer n orice moment o imagine de ansamblu asupra
problemei de rezolvat i nu este necesar cunoaterea apriorii a domeniului problemei, aceasta
realizndu-se pe parcurs.
Prezint dezavantajul unei analize complexe, laborioase, care antreneaz un personal numeros
i conduce la prelungirea timpului de realizare a sistemului iar strecurarea unor erori sau
imprecizii n definirea structurii i a relaiilor dintre componentele sistemului afectnd activitatea
pn n momentul respectiv.
Metoda ascendent (Bottom-Up)
Metoda const n agregarea modulelor de jos n sus punnd n eviden legturile
dintre ele pn se ajunge la un singur modul.
Modularea i abordarea sistemic sunt conceptele care stau la baza acestei metode, aceleai
ca la metoda de abordare descendent.
Regulile care stau la baza metodei sunt:
Nivelul de agregare iniial este nivelul la care se afl modulele terminale;
Agregarea se face succesiv de jos n sus;
Cnd se obine un nivel de agregare se realizeaz integrarea modulelor de nivel inferior
n module de nivel superior;
Agregarea este terminat cnd la un nivel de agregare se obine un singur modul.
Avantajul folosirii acestei metode ar fi acela c sistemul informatic se dezvolt treptat, n
corelaie cu cerinele beneficiarului. Beneficiarul beneficiaz de rezultatele prelucrrii automate a
datelor mai repede, se familiarizeaz cu noul sistem gradat. Se reduce riscul realizrii unui
sistem neoperaional n momentul punerii n aplicaie.
Dezavantajul acestei metode rezult din gradul de integrare redus al modulelor datorit
lipsei unei concepii iniiale de ansamblu, ceea ce face necesar reproiectarea unor
componente.
Metoda LCS/LCP (Logical Construction of System / Programs)
Aceast metod este cunoscut i sub denumirea de metoda Warnier sau Legi de
concepere/construire a sistemelor/programelor, aceast metod are la baz un ansamblu de
principii de structurare a modulelor n funcie de structura datelor de ieire. Ea permite

44

specificarea condiiei de executare i a numrului de efecturi ale procedurilor care sunt

structurate pn la nivelul elementar.
Tehnica concordanei intrri-ieiri este o tehnic ce se utilizeaz att la analiz, ct i la
proiectare.
Plecnd de la informaiile necesare fundamentrii deciziilor se determin mulimea
informaiilor primare ale sistemului respectiv. Pe baza sistemului de decizii identificat se
determin n continuare informaiile de ieire din sistemul informaional, necesare fundamentrii
acestor decizii.
Aceast metod de determinare a informaiilor de intrare pe baza celor de ieire este
util n cazul sistemelor complexe, cu multe informaii.
Abordarea analizei poate fi fcut i plecnd de la intrri i ajungnd la ieirile
sistemului informaional.
Metoda prezint dezavantajul c nu este posibil punerea n eviden a tuturor
legturilor dintre datele primare existente n sistem.
Tehnica HIPO este conceput pentru abordarea ierarhizat a sistemului informaional urmrind
descrierea fluxului INTRRI PRELUCRRI IEIRI.
Aceast tehnic se concretizeaz n elaborarea unei documentaii care este alctuit din:
HIPO general;
HIPO de detaliu;
HIPO de ntreinere.
HIPO general prezint structura funcional a sistemului i st la baza proiectrii i a comunicrii
n cadrul echipei de proiectare a sistemului.
HIPO de detaliu prezint o descriere general i de detaliu a structurii tuturor
fiierelor/entitilor/relaiilor folosite.
HIPO de ntreinere prezint documentaia corectat i completat dup testarea i
implementarea sistemului informatic.
Fiecare documentaie n parte trebuie s conin:

Tabela de coninut care conine structura funcional ierarhic cu legturi ntre

componente. Descompunerea ierarhic trebuie s respecte concepia de baz a
acestei tehnici (INTRRI PRELUCRRI IEIRI) i s permit asocierea, pentru
fiecare nivel descompus, a cel puin o diagram general.

Diagrama general prezint funciile importante ale sistemului coninnd reprezentarea

grafic a fluxului INTRRI PRELUCRRI IEIRI cu detalierea acestor funcii.

Diagrama de detaliu prezint descrierea analitic a fiecrei funcii majore din diagrama
45

general, prin descompunerea acestora pn la ultimul nivel de obinere a tuturor

informaiilor privind fluxurile INTRRI PRELUCRRI IEIRI i ultimele relaii de flux
de pe ultimul nivel de detaliere.
Teste de evaluare a cunotinelor
1. n cadrul proiectrii unui sistem informatic:
a. informaiile de programare, planificare i previziune au un caracter relativ sintetic
b. se prezint toate legturile dinamice create ntre un program i reprezen-tarea grafic
atribuit acestuia
c. se realizeaz o sintez a celorlalte programe, corelat cu cifra de afaceri, cu profitul i
cu modul de repartizare a acestuia
d. se urmarete afiarea n fereastra de baz Taskbar o serie de reprezentri grafice
e. datele i prelucrrile sunt studiate i modelate mpreun
2. Proiectarea sistemelor informatice prin abordarea descendenta:
a. const n a cobor, pe scara piramidei ierarhice, pn la baz, realiznd totodat i o
analiz
b. culegerea i nregistrarea datelor tehnico-economice i financiare, care privesc
patrimoniul unitilor i economiei naionale
c. duce la realizarea gestionarului de reea i a celui de fiire terse
d. aplicaii Windows - aplicaiile scrise pentru programele rezidente - programe de tip
Terminate and Stay Resident (TSR)
e. va permite utilizatorului executarea unei operaiuni de instalare automat a unor
subansamble nou adaugate n configuraia calculatorului
3. ntr-un sistem informatic, metodele si procedurile de prelucrare se refera la:
a. partea logic a prelucrrii datelor n vederea obinerii informaiilor
b. pentru producerea de imagini standard n spiritul teoriei valorii, antreneaz o pierdere
de informaie
c. costurile de fabricaie a bunurilor, de executare a lucrrilor sau de prestare a serviciilor
d. obinerea i cercetarea unitilor elementare de informaie
e. rezolvarea unei variate problematici de natur economic
4. Metoda orientat obiect:
a. prezint instruciuni SQL ncapsulate n codul program
b. este caracterizat prin atenia deosebit acordat concomitent structurii datelor i
46

structurii funcionale
c. are programe de investiii, programe de aprovizionare i vnzare de bunuri, servicii i
de marketing
d. realizeaz fixarea opiunii gestiunii la nivel conceptual, opiunii organiza-ionale la nivel
logic i a celei tehnice la nivel fizic
e. este un proces simplu i rapid de aezare a tabelelor i a cmpurilor strict necesare
5. Metodele de proiectare se pot clasifica in:
a. pilotajul i execuia operaiunilor productive
b. metode structurate; metode sistemice; metode orientate obiect
c. vizualizarea i eventuala activare a programelor care asigur monitorizarea i
mpiedic modificarea caracteristicilor modemului
d. operaii de adugare, modificare, tergere, mutare i copiere de sisteme informatice de
gestiune
e. descrierea activitii sistemului operant, orientat pe baza regulilor de funcionare,
sisteme de management, aplicate asupra intrrilor, pentru a produce ieirile dorite
6. Proiectarea sistemelor informatice prin abordarea ascendent:
a. presupune structurarea informaiilor financiar-contabile, prelucrate potrivit procedeelor
metodei contabilitii prin conturi i dubla nregistrare
b. se poate constitui sub forma unui ghid de abordare a unui sistem informatic, pus n
eviden sub form sintetic
c. permite adugarea la desktop a unei funcionaliti specifice Internet-ului
d. are ca punct de plecare nivelul operaional (aflat la baza piramidei ierarhice), i, prin
realizarea informatizrii la fiecare nivel n parte, se ajunge la un sistem informatic care
poate atinge nivelul extrem al piramidei
e. este format din reuniunea de funcii care pune n eviden cel mai bine comportamentul
ntregului sistem operant
7. Metodele de proiectare sistemice:
a. se compun din abstractizri care prezint lumea real ca pe o colecie de entiti i de
legturi, stabilite ntre acestea
b. este considerat invariabil sau relativ stabil n sistemele anterioare i gestionat
doar de administratorul bazei de date
c. operant formeaz imaginea dinamica de nivel aciune
d. reprezint ansamblul de tehnici i echipamente de culegere, prelucrare i transmitere a
47

informaiilor
e. aduc o varietate de procedee pentru obinerea i prelucrarea datelor, n vederea
utilizrii sistemelor informaionale n gestionarea unei uniti economice

8. Avantajul major al metodei de proiectare Merise este:

a. descrierea sistemelor informatice pe nivel conceptual, nivel logic sau organizaional,
nivel fizic sau operaional
b. obiectivul de strategie care permite managerului s adopte soluii de dezvoltare a
activitii firmei
c. prin aciunea n timp real a sistemului informaional economic
d. materializat prin modul de realizare a obiectivelor unitii i a sarcinilor fiecrui
compartiment
e. asigur o legtur direct ntre obiectele lumii reale i entitile definite, datele sunt
ierarhizate, manipulndu-se legturile ntre obiect i componentele sale
9. Ciclul de via al unui sistem informatic descrie cronologic:
a. toate principiile n domeniu, completndu-se legislaia romneasc cu dou principii,
conform Recomandrilor IASC i Reglementrile Pieei Comune
b. ansamblul activitilor sistemului operant fa de mulimea funciilor sale
c. principiul relevanei economicului asupra juridicului; principiului pragului de
semnificaie a informaiilor
d. evoluia proiectului de-a lungul ntregului parcurs de funcionare a software-ului,
ncercnd s arate cum poate fi ncorporat o informaie n cadrul organizaiei
e. delimitarea domeniilor de studiu, a nenumratelor mijloace de documentare, a
metodelor de concepie i punere n exploatare curent informaional
10. Specializarea claselor are ca punct de plecare:
a. programe de investiii, programe de aprovizionare i vnzare de bunuri, servicii i de
marketing
b. transmiterea i prelucrarea datelor, obinerea de informaii
c. superclasa adugnd noi atribute relevante numai pentru anumite obiecte din clas,
crend astfel subclasele
d. un sistem operant format din reuniunea de funcii care pune n eviden cel mai bine
comportamentul ntregului sistem operant
e. starea n care se afl elementele patrimoniale, sau valorile definite prin raportri
48

Capitolul 3
Cadrul tehnologic de analiz i dezvoltare a sistemelor informatice
Obiective:
Cunoaterea metodelor de analiz i dezvoltare a sistemelor informatice
Identificarea problemelor de soluionat i structurarea cerinelor noului sistem informatic
nelegerea mecanismelor de modelare a datelor i realizarea trecerii succesive de laun model
la altul
Cuvinte cheie: analiz structural, analiz dinamic, analiz funcional, diagrame de flux,
diagrame de tranziie, diagrama entitate asociere, model conceptual al datelor(MCD), model
logic al datelor(MLD).
Complexitatea i multitudinea sistemelor informatice impune efectuarea unor analize
prin care se determin principalele disfuncionaliti informaionale i consecinele lor
manageriale, economice i umane.
Concomitent se evideniaz i aspectele pozitive ale sistemului informaional curent i
se evalueaz problemele pe care trebuie s le rezolve viitorul sistem.
n analiza sistemului informaional trebuie s regsim aspectele:
aria de ntinderea a sistemului informaional care va deveni sistemul obiect pentru
conceperea i realizarea unui sistem informatic;
reflectarea activitilor i operaiilor economice specifice sistemului informaional;
surprinderea modificrilor ce se impun n organizarea i funcionarea unui sistem
informatic;
fundamentarea unei soluii de principiu care s precizeze activitatea i operaiile ce
urmeaz a fi informatizate, costul antecalculat al sistemului.
Etapa de analiz trebuie s urmreasc:
Identificarea problemelor de soluionat i determinarea cerinelor sistemului;
Structurarea cerinelor noului sistem;
Evaluarea sistemelor informatice;
Generarea i alegerea variantelor de proiectare.
Tot n aceast etap de analiz ncepe i modelarea datelor.

49

3.1 Identificarea problemelor de soluionat i determinarea cerinelor sistemului

Identificarea problemelor de soluionat ncepe cu activitatea de culegerea i nregistrarea de
date i informaii referitoare la componentele sistemului informaional.
Pentru identificarea problemelor de soluionat este necesar un studiu al sistemului existent i
care se realizeaz prin:
Definirea caracteristicilor generale ale unitii:
Profilul i obiectivele organizaiei;
Locul ocupat n sfera serviciilor i sfera produciei;
Specificul activitii de baz;
Principalii indicatori economici i evoluia lor;
Proiecte de modernizare, dezvoltare;
Structura organizatoric.
Identificarea activitilor desfurate
Documentele de baz pot fi:
Regulamentul de organizarea funcional (ROF);
Regulamentul de ordine interioar (ROI);
Statutul de funcionare al organizaiei.
Din aceste documente rezult informaii despre funciile, activitile i modul de realizare a lor,
relaiile funcionale dintre compartimente, sarcina ce revine fiecrui compartiment.
Depistarea deficienelor informaionale.
Studiile efectuate asupra sistemelor informaionale din cadrul firmelor au reliefat
existena unor deficiene tipice, relativ frecvente, reflectare a unor erori n conceperea i
implementarea lor, a cror cunoatere i prentmpinare este esenial.
Distorsiunea prima dintre deficienele tipice, const n modificarea parial
neintenionat a coninutului, a mesajului unei informaii pe parcursul culegerii, prelucrrii i
transmiterii de la emitor la receptor. Dintre cauzele multiple care genereaz distorsiunea
menionm ca foarte frecvente: diferenele n pregtirea persoanelor implicate n vehicularea
informaiei, folosirea de supori informaionali necorespunztori pentru nregistrarea informaiilor,
manipularea neglijent a suporilor de informaii n procesul transmiterii lor beneficiarilor,
utilizarea de mijloace necorespunztoare pentru nregistrarea i transmiterea informaiilor etc.

50

Filtrajul, a doua deficien informaional major, se deosebete de distorsiune prin

aceea c modificarea parial sau total a mesajului sau coninutului informaiilor are loc n mod
intenionat. Cauza filtrajului este una singur: intervenia pe parcursul nregistrrii, transmiterii i
prelucrrii informaiilor a unor persoane, care au interesul ca beneficiarul informaiei s
primeasc un mesaj schimbat. Aceast deficien cronic a sistemului informaional se
manifest n special cnd unii manageri sunt incoreci sau nu-i exercit integral atribuiile de
control.
Efectul negativ att al distorsiunii, ct i al filtrajului este dezinformarea parial sau integral a
beneficiarului de informaii. Cnd dezinformarea se produce la nivelul managerilor, aceasta se
reflect n diminuarea calitii deciziilor. Cnd dezinformarea se produce la nivelul executanilor,
efectele immediate se resimt pe palnul realizrii proceselor cu caracter operaional, impietnd
asupra cantitii, calitii i perioadei de obinere i furnizare a produselor i serviciilor. n ambele
situaii, efectele pe termen lung sunt scderea eficienei, concomitent cu deteriorarea ntr-o
anumit msur a climatului de munc, a relaiilor dintre personalul implicat .a.
Redundana este o alt deficien major tipic a sistemului informaional, care const
n nregistrarea, transmiterea i prelucrarea repetat a unor informaii. Cauza major a acestei
disfuncionaliti informaionale o reprezint absena coordonrii sau coordonarea defectuoas a
anumitro segmente ale sistemului managerial. Redundana se produce mai ales cnd nu se
respect principiul unitii de decizie i aciune, cnd mai muli manageri se adreseaz nemijlocit
cu cereri de informaii unor compartimente, fr ca personalul managerial responsabil nemijlocit
de activitatea lor s fie informat i s intervin. Efectele redundanei, care se manifest adesea
sub forma cererii acelorai informaii de ctre diferii beneficiari, dar sub alte forme, constau ntro apreciabil risip de timp i adesea de mijloace materiale din partea celor implicai.
n categoria deficenelor majore se nscrie i suprancrcarea circuitelor
informaionale cu informaii, prin care desemnm vehicularea prin ele a unei cantiti de
informaii ce-i depete capacitatea de transport, ceea ce duce la blocarea i/sau ntrzierea
ajungerii unei pri din informaii la adresant. Printre cauzele care o genereaz menionm n
afara redundanei nerespectarea caracterului piramidal al sistemului informaional. Prin
caracter piramidal al sistemului informaional nelegem transmiterea i agregarea selectiv a
informaiilor pe verticala sistemului de management corespunztor sferei obiectivelor,
competenelor i responsabilitilor circumscrise subdiviziunilor organizatorice. La originea
acestei situaii se afl proiectarea defectuoas a sistemului informaional, insuficienta pregtire a
unor manageri i executani, tendina unora de a-i umfla realizrile, de a-i populariza excesiv
aciunile etc.
51

Fr ndoial c elementele menionate nu epuizeaz gama deficienelor cronice ale

sistemului informaional, dar constiuie, de regul, maladiile cele mai frecvente, a cror
cunoatere, identificare i eliminare constituie o component de baz a raionalizrii sistemului
informaional al organizaiilor.
Identificarea resurselor existente.
Resursele necesare se mpart n 4 categorii:
Resurse materiale consumabile, toner, calculatoare, cablaje, prize electrice, scanere,
imprimante, mobilier.
Resurse umane personaql de conducere i execuie implicat, consultanii n
management, informaticienii, prestatorii de servicii specializate;
Resurse informaionale metodologii, instruciuni, cri, studii, documentaii;
Resurse financiare necesare plii onorariilor realizatorilor studiului, achiziionrii de
echipamente electronice i consumabile.
Este foarte important analiza atent a cerinelor, deoarece ele pot fi incomplet exprimate sau
pot fi exprimate ca opinii, sugernd soluia tehnic, fr s descrie cerinele efective ale
problemei .
Cerinele se pot mpri n:
Cerine funcionale se refer la activitile pe care trebuie s le realizeze noul sistem
(cerine referitoare la stocarea, modificarea datelor; cerine privind modul de obinere a
rapoartelor);
Cerine nefuncionale se refer la modul n care sistemul realizeaz activitile
prevzute (cerine privind securitatea datelor; cerine privind refacerea datelor pierdute;
cerine de arhivare; cerine determinate de trecerea de la prelucrarea manual la
prelucrarea automat).
Determinarea cerinelor sistemului este o activitate esenial n aflarea situaiei existente i a
ceea ce se dorete n viitor. Culegerea informaiilor este posibil prin metode tradiionale sau
moderne.
Metodele tradiionale de colectare a cerinelor sistemului sunt:
interviuri individuale;
anchete realizate prin chestionare;
intervievarea grupurilor de oameni cu interese comune;
observarea personalului in momente bine definite pentru a vedea modul n care sunt
folosite informaiile pentru exercitarea sarcinilor de serviciu;
studierea documentaiei firmei pentru a se cunoate coninutul rapoartelor, al politicilor
52

spre care se ndreapt prelucrarea datelor;

Metodele moderne mai des utilizate sunt:
sesiunile JAD (Joint Application Design) ;
sistemele de sprijinire a grupurilor de lucru;
prototipizarea;
RAD (Rapid Application Development) ;

Intervievarea
Interviul este procesul comunicrii directe de stabilire a unei relaii cu o finalitate
precisa, predeterminata, proces conceput pe alternanta rolurilor si care implica formulri de
ntrebri si obinerea de rspunsuri.
Cuvntul proces semnific dinamism, interaciune continu cu multe variabile de lucru, cu
aciune nlnuit, dup un anumit sistem de derulare.
Cuvntul diadic, pornind de la diad, scoate n relief faptul c interviul este o
interaciune persoan-cu-persoan ntre dou pri sau dou componente, evitndu-se astfel
faptul c la interviu pot participa mai multe persoane, dar niciodat mai mult de dou pri: cea
care ia interviul i cea intervievat.
Cuvntul relaii sugereaz o legtura interpersonal ntre prile interviului.
Finalitate precis, predeterminat nseamn c cel puin o persoan vine la interviu cu un
anumit scop i vrea s abordeze un anumit subiect.
Alternana rolurilor are conotaia mprtirii gndurilor, a simmintelor i informaiilor printr-o
schimbare continu a rolurilor.
Dac numai una dintre pri vorbete si cealalt ascult se poate vorbi despre un
discurs (speech), si nu despre interviu. Se consider c aproximativ 70% din timpul total al
interviului aparine intervievatului i 30% celui ce ia interviul (anchetator). Sunt i tipuri de
interviuri in care se pot inversa rolurile, cum ar fi cazul interviurilor pentru oferirea de informaii
sau promovarea unei vnzri.
Formularea de ntrebri i obinerea rspunsurilor constituie procesele eseniale ale interviului.
Puine sunt interviurile care s nu necesite o structurare prealabil a ntrebrilor.
Chestionarele
Spre deosebire de interviuri, chestionarele sunt mai puin costisitoare i ntr-un timp
relativ scurt, pot oferi un volum mare de informaii necesare analizei sistemului.
Deoarece conceperea chestionarului este mai mult o arta dect o tiin, specialitii s-au strduit
s-i prezinte experiena sub forma unor reguli, recomandate ndeosebi nceptorilor, cei cu
state vechi le pot utiliza drept elemente de comparaie pentru a-i evalua paii ntregii proceduri.

53

Din aceste motive se consider de bun augur descrierea pailor parcuri pentru conceperea
unui chestionar :
pasul 1 : Ce informaii vor fi cutate ?
n primul pas al chestionarului se stabilesc informaiile care trebuie s fie obinute, operaie
declanat n faza embrionar a cercetrii de ntreprins. Neglijena manifestata n aceast etap
va conduce la obinerea unor informaii nerelevante.
pasul 2 : Stabilirea tipului de chestionar i a metodei de administrare
Dup identificarea informaiilor de cutat, cel ce concepe chestionarul trebuie s specifice modul
n care le va obine. Decizia se va referi la structura si modul de formulare a ntrebrii, dup care
se va pune problema administrrii chestionarului. : prin pot, telefonic sau cu operator(o
persoan special desemnat pentru aceast operaiune).
pasul 3 : Determinarea coninutului fiecrei ntrebri
pasul 4 : Stabilirea modului de redactare a rspunsului pentru fiecare ntrebare
Dac se merge pe o variant fix, proiectantul trebuie s decid dac va folosi ntrebri nchise
sau dac va merge pe varianta opiuni multiple, dou opiuni sau a scalei de valori.
pasul 5 : Formularea ntrebrilor
De modul n care sunt formulate ntrebrile, practic depinde succesul chestionarului.
pasul 6 : Stabilirea secvenei ntrebrilor
pasul7: Validarea caracteristicilor tehnice ale chestionarului
pasul 8: Reevaluarea pailor 1-7 i revizuirea lor (dac este cazul).
Pasul 9: Efectuarea pretestului i revizuirea final (dac este cazul).
De regul, chestionarele sunt administrate pe hrtie, dar ele pot fi efectuate cu sau fr
operator uman, direct, prin telefon, sau chiar pe dischet, sau prin intermediul serviciilor oferite
de calculatoare.
Chestionarele, n cea mai mare parte, se bazeaz pe ntrebri cu schem fix de rspuns,
iar atunci cnd conin ntrebri cu o formulare vag au ca scop aflarea prerilor celor chestionai,
pentru a putea fi surprinse ct mau multe cazuri.
Eantionarea
ntruct colectivitile depesc ntotdeauna numrul celor ce sunt chestionai, o problema
esenial o constituie stabilirea eantionului chestionat. De regula, se folosesc urmtoarele 4
metode sau combinaii ale lor :
cei adecvai eantionului : ei pot fi oameni care i desfoar activitatea ntr-un anumit
loc, cei care sunt motivai s dea rspunsuri sau cei care vor s dea rspunsuri sau cei
care vor s fie intervievai.
un grup aleator : dac exista o list a utilizatorilor unui sistem simplu, se selecteaz
fiecare a n-a persoana, n care n este o raie de selecie. O alt modalitate const n
54

selecia persoanelor pe baz ordonrii lor dup a 2-a, a 3-a liter a numelui sau a
prenumelui sau prin generarea aleatoare a numerelor cu ajutorul calculatorului.
un eantion precizat: pot fi numai persoanele care ndeplinesc anumite criterii.
un eantion stratificat: dac sunt mai multe categorii de persoane, din fiecare, dup
criterii aleatoare, vor fi selectai cei eantionai. De exemplu: dintre utilizatori,
conductori, informaticieni.

Observarea direct a utilizatorilor

Nu ntotdeauna consultarea persoanelor conduce la obinerea celor mai bune rezultate,
chiar si atunci cnd acestea afirm ca ofer cele mai sigure informaii sau au impresia ca dein
adevrul absolut asupra sistemului analizat. Prerile sunt subiective.
Desfurarea operaiunii de observare directa depinde si de acceptul sau bunele
intenii ale organizaiei supuse analizei. Uneori, chiar daca exista un astfel de accept, prezenta
analitilor printre angajai ii determina pe acetia din urma sa manifeste un comportament
anormal, cu scopul de a crea o anumita impresie. Astfel pot fi emoionai, stresai, se pot fora s
efectueze lucrrile mai repede, s simuleze ocuparea complet a timpului de munc. Alteori,
dac au un alt obiectiv ei pot lucra mai ncet, pot bruia noul sistem s.a.
Aadar, observarea presupune pentru analiti selecia unei palete foarte largi de probleme.
Analiza procedurilor de lucru i a altor documente
Documentele ce pot fi studiate sunt de o mare diversitate. Dintre documentele mai des
solicitate fac parte : declararea misiunii i strategiei organizaiei, cunoaterea obiectivelor
acesteia, a planurilor de afaceri, a studiilor de fezabilitate, a structurii organizatorice
(organigrama), a regulamentelor de organizare si funcionare, a celor de ordine interioara, a
normelor interne de fabricaie, a standardelor folosite, a fiselor posturilor, a corespondentei
interne si externe, a rapoartelor de analiza rezultate din studii anterioare s.a.
Un prim tip de documente se refera la procedurile de lucru pentru activitile
individuale sau ale grupurilor. Prin ele se descrie modul in care se exercita o anumita activitate,
prezentndu-se si datele si/sau informaiile pe care le solicita sau le genereaz.
Un al doilea tip de documente ce este studiat de analitii de sistem l constituie formularele
utilizate de ctre unitate pentru toate tranzaciile interne si externe care au loc.
Al treilea tip l constituie rapoartele generate de sistemul actual.

55

Al patrulea tip se regsete numai in sistemele de prelucrare automata a datelor si se refera la

documentaia folosit in sistemul informatic.
Ca efect al tendinelor de mrire a timpului de analiz a sistemelor existente, n ultimii ani s-a
efectuat trecerea spre tehnicile moderne, unele dintre ele care preiau din ce n ce mai puine
elemente ale sistemelor existente.
Sesiunile JAD pun laolalt toate forele interesate n dezvoltarea sistemelor: utilizatorii cheie,
managerii i analitii de sistem implicai n analiza sistemului curent. Din acest punct de vedere
JAD este similar interviului la nivel de grup. Totui, n sesiunile JAD ce urmeaz o anumit
secven de derulare a activitilor pe baza unor roluri bine definite.
Prototipizarea este un proces iterativ prin care analitii i utilizatorii pun n discuie o versiune
rudimentar a unui sistem informaional, care va fi ntr-o continu schimbare, n funcie de
reacia utilizatorului. Prototipul este vzut i testat de utilizator, avnd posibilitatea s precizeze
ce ar mai dori, dar i s-i genereze aceast form nou, firesc, cu ajutorul specialitilor din
preajm.
RAD este o metodologie de realizare a sistemelor informaionale care promite sisteme mai
bune, mai ieftine i realizate mai rapid. O prim explicaie const n celor mai buni proiectani de
sisteme i a celor mai reprezentativi utilizatori , care, mpreun, n timp real, lucreaz la
realizarea sistemului.
Diferena major a RAD fa de JAD const n faptul c prototipul devine elementul fundamental
al noului sistem - ecranele afiate n timpul prototipizrii devin ecrane ale sistemului, i nu
modele ale unui posibil sistem.
Plecnd de la aceste obiective, suportul hardware i software al noului sistem informatic trebuie
s ndeplineasc urmtoarele cerine:
o
Asigurarea suportului informaional prin crearea i ntreinerea unei baze de
date sigure i complete:
crearea i actualizarea n timp real a imaginii procesului n memoria intern i accesul
transparent pentru utilizatori i aplicaii la aceast imagine;
crearea i actualizarea n timp real a bazei de date cu evoluia n timp a procesului
precum i accesul distribuit la datele nregistrate;
completarea n timp real a bazei de date cu evenimentele din sistem i accesul distribuit
la informaii;
56

arhivarea i ntreinerea arhivelor cu istoricul procesului i evenimentelor precum i

accesul distribuit la datele din arhiv.
Asigurarea unui flux informaional coerent:
circulaia selectiv a informaiilor existente n imaginea intern a procesului ctre
utilizatori, n funcie de specificul activitilor;
gestiunea automat a fluxului de date pe orizontal i pe vertical(n interiorul i ntre
nivelele ierarhice) n vederea ntreinerii bazelor de date;
gestiunea dinamic a nregistrrilor n baza de date innd cont de durata de viaa
impus pentru acestea.

o Prezentarea informaiilor ctre utilizatori

Prin intermediul staiilor de lucru, utilizatorul poate avea acces la informaiile din sistem n
concordan cu sarcinile pe care acesta la are n ierarhia de funcii. Accesul la sistem se face
numai prin identificarea utilizatorului dup nume i parola de protecie, numai pentru funciile
specifice postului su.
o Comunicarea transparent pentru utilizatori ntre echipamentele din sistem
Suportul de comunicaie trebuie astfel conceput nct pentru orice utilizator
echipamentele interconectate s fie vzute ca un singur calculator uria.
o Integrarea cu alte aplicaii existente sistemului informaional
Utilizarea unor legturi de comunicaie dedicate, pentru activitile de conducere
operativ.

Accesul la informaii, utiliznd serviciile intranet.

o Disponibilitatea i funcionarea degradat n cazul cderii unor componente i
sigurana pstrrii informaiilor
Posibilitatea de intervenie pentru ntreinere sau depanare asupra unor componente
ale sistemului fr afectarea funcionrii de ansamblu.
Funcionarea n regim de rezervare activ a componentelor vitale ale sistemului: canale
de comunicaie dublate, servere de baze de date cu mai multe procesoare i memorii
externe RAID.
Replicarea componentelor vitale ale bazei de date n locaii diferite, pentru a evita
pierderea datelor n caz de defect.
Accesul la funciile specifice de la orice staie de lucru n cazul indisponibbilitii celor
destinate implicit pentru funciile respective.
o Configurabilitatea i posibilitatea de extindere

57

Abordarea realizrii sistemului n etape succesive impune existena unor funcii de baz care s
permit:
Extinderea sistemului prin adugarea de noi componente fizice i logice.
Modificarea interactiv a bazelor de date care descriu componentele logice din sistem
Adugarea de noi aplicaii care au acces la informaiile din sistem
3.2 Structurarea cerinelor sistemului
n structurarea unui sistem informatic se utilizeaz mai multe criterii de descompunere a
acestuia n subsisteme i module componente:
Funciunile sistemului. - Sistemul informaional este alctuit din mai multe subsisteme
funcionale: producie, comercial, financiar-contabil, personal, cercetare-dezvoltare;
Activitile sistemului O serie de activiti se desfoar n cadrul unui agent
economic, care respect anumite proceduri bine stabilite n vederea realizrii
obiectivelor. Activitile variaz ca tip i numr de la o unitate la alta sau n timp.
Organizarea sistemului n fiecare agent economic se cunosc departamentele,
localizarea i rolul lor.
Natura componentelor din cadrul sistemelor subsistemele care pot fi identificate
potrivit acestui criteriu au n vedere componente de tipul: materii prime, materiale,
echipamente, resurse umane, produse finite, resurse financiare.
Orizontul de conducere se identific subsistemele: strategic, tactic, operativ. Se are n
vedere structurarea sistemului i n subsistemul decizional, subsistemul condus i
subsistemul informaional.
Indiferent de criteriul utilizat putem spune c structurarea cerinelor sistemului e etapa
cea mai complex din cadrul analizei i se bazeaz pe 2 activiti (Figura 3.2 ):
modelarea proceselor;
modelarea datelor.
Activitatea de analiz pentru modelarea conceptual se poate realiza sub trei aspecte:
structural, dinamic i funcional.
Analiza structural evideniaz, la nivel conceptual, modul de structurare a datelor i a
legturilor dintre ele. Cea mai utilizat tehnic este entitate-asociere.
Aceasta conine:
Identificarea entitilor: fenomene, procese, obiecte concrete sau abstracte
(substantivele din prezentarea activitii descrise) (exemple de entiti: Persoane,
Produse, Beneficiari).
Identificarea asocierilor dintre entiti ca fiind legturile semnificative de un
anumit tip (verbele din prezentarea activitii descrise).
58

Identificarea atributelor ce caracterizeaz fiecare entitate n parte (exemple de

atribute: Marca, Nume, Adres).
Stabilirea atributelor de identificare unic a realizrilor entitii, drept chei.
Rezultatul analizei structurale este modelul static (structural), numit i diagram
entitate-asociere.
Analiza dinamic evideniaz comportamentul elementelor sistemului la anumite
evenimente. Una dintre tehnicile utilizate este diagrama stare-tranziie.
Aceasta presupune:
Identificarea strilor n care se pot afla componentele sistemului.
Identificarea evenimentelor care determin trecerea unei componente dintr-o
stare n alta.
Stabilirea tranziiilor admise ntre stri
Construirea diagramei stare-tranziie
Rezultatul analizei dinamice: modelul dinamic.
Analiza funcional evideniaz modul de asigurare a cerinelor informaionale (fluxul
prelucrrilor) din cadrul sistemului, prin care intrrile sunt transformate n ieiri. Cea mai
utilizat tehnic este diagrama de flux a datelor.
Conform acestei tehnici se delimiteaz:
Aria de cuprindere a sistemului.
Se identific sursele de date.
Se identific modul de circulaie i prelucrare a datelor.
Se identific apoi rezultatele obinute.
Rezultatul analizei funcionale: modelul funcional.
Urmare a operaiunii de culegere a cerinelor sistemului este activitatea de structurare a
cerinelor prin metode specifice: modelarea proceselor, modelarea logicii proceselor i
modelarea conceptual a datelor.
Indiferent de metodologiile folosite n realizarea unui sistem, toate apeleaz la operaiunea de
modelare logic a datelor i prelucrrilor sub form de diagrame.
Exist mai multe tipuri de diagrame, utilizabile n diverse etape ale ciclului de via al
sistemului sau pentru anumite activiti. n practic, cele mai multe produse apeleaz la dou
tehnici de redare a diagramelor fluxurilor de date: Gane & Sarson i Yourdon & DeMarco.
Prin analiza diagramelor fluxurilor de date se pot reliefa urmtoarele aspecte:
fluxuri de date redundante, aprute, de regul, prin apelarea la nume diferite pentru
acelai tip de date;
date care intr n prelucrri dar nu sunt folosite;
datele ce sunt actualizate identic n mai multe locuri.
59

Sisteme subsisteme
informaionale/proceduri
informaionale

Documentare i analiz

Informaii i
legturi dintre ele

Proceduri i reguli de
gestiune

Modelare

Modelul conceptual al
datelor

Modelul conceptual al
prelucrrilor

Fig. 3.2 Activitile etapei de analiz

3.3 Evaluarea sistemelor informatice
Evaluarea sistemului existent se realizeaz sub dou aspecte:
Evaluarea performanelor i limitelor sistemului existent se face innd cont de urmtoarele
criterii:
Msura n care sistemul informaional asigur realizarea obiectivelor,
ndeplinirea sarcinilor de baz ale unitii i exercitarea atributelor de conducere;
Operativitatea n culegerea i trasmiterea informaiilor i datelor, ceea ce
caracterizeaz timpul de rspuns al sistemului infomaional;
Calitatea i sigurana legturilor informaionale, a fluxurilor informaionale;
Posibiliti de control i de efectuare a coreciilor.
Evaluarea gradului de pregtire a unitii economice pentru proiectarea i implementarea
sistemului informatic presupune:
Stabilirea nivelului de pregtire a personalului i a experienei dobndite n
60

prelucrarea automat a datelor;

Existena unei discipline tehnologice;
Existena fondului de date necesar pentru realizarea sistemului informatic.
3.4 Modelarea noului sistem informatic
Activitatea de modelare a unui sistem informatic se regsete n pricipalele activiti de
realizare a sistemului: analiz, proiectare, implementare, dar cel mai pregnant se manifest n
crearea sistemului de baz de date. Din acest motiv, dintre toate metodologiile utilizate pentru
modelarea sistemelor informatice ne vom referi, n cele ce urmeaz, la cele folosite pentru
realizarea unui sistem de baz de date.
Datele sunt stocate i structurate n cadrul sistemelor de calcul, att n memoria
intern, ct i n memoria extern. Prin caracteristicile de volum i complexitate, datele prezint
aspecte specifice de organizare n memoria extern.
Organizarea datelor este procesul de definire i structurare a datelor n colecii, precum
i stabilirea legturilor ntre elementele unei colecii i ntre colecii.
Organizarea datelor a evoluat n paralel cu creterea volumului de date prelucrat,
precum i a gradului de complexitate a problemelor rezolvate cu ajutorul calculatorului.
Evoluia organizrii datelor a pornit de la fiiere simple, au urmat fiierele complexe i, n final, sa ajuns la cea mai performant form de organizare a datelor bazele de date.
Toate aceste forme de organizare a datelor se bazeaz pe noiunea de colecie de date.
Colecia de date reprezint un ansamblu de date organizat dup anumite criterii i format din
urmtoarele componente:
familie de caracteristici compus din mai multe proprieti (atribute) care definesc
aspecte ale obiectelor din lumea real prin valori;
un predicat aplicat asupra familiei de proprieti, care conduce la o submulime ce
definete o relaie de ordine ntre caracteristici, cu un anumit scop;
alte componente care iau n considerare timpul i legturile.
Investigare pleac de la o viziune de ansamblu a structurii logice a datelor.
Datele sunt grupate n colecii de date, dup diverse criterii pentru fiecare subsistem sau la
nivelul ntregului sistem.
Principalele criterii pe baza crora se poate efectua gruparea fondului de date sunt:
Sfera de cunoatere;
61

Domeniul de activitate;
Stabilitatea coninutului datelor;
Rolul datelor n procesul prelucrrii.

Dup sfera de cunoatere se pot contura patru tipuri de colecii mari de date cu valori de
ntrebuinare diferite, cu grad de agregare i sintetizare difereniat, care pot constitui obiectul
stocrii i prelucrrii automate:
Date primare;
Indicatori tehnico-economici cu caracter operativ;
Indicatori tehnico-economici cu centralizare medie;
Indicatori sintetici.

Dup domeniul de activitate, la nivelul unei uniti productive, datele pot fi grupate n colecii ce
reflect entiti, fenomene i procese economice.
Din punct de vedere al stabilitii datelor, putem delimita: colecii de date convenional
constante i colecii de date variabile. Coleciile da date convenional constante sunt cu
caracter normative, cu caracter descriptive, cu caracter de translatare sau de legtur.
Principalele colecii de date cu caracter normativ sunt:

Normative de fabricaie;
Normative tehnologice;
Normative de munc;

Normative materiale.

Din punct de vedere al prelucrrii datelor, coleciile de date se clasific n:

Colecii de date de baz au un coninut omogen format din date primare care reflect
stri, caracteristici, evenimente, fapte preluate din unul mai multe documente primare.
Se poate aprecia c datele i pstreaz valabilitatea, relevana, autenticitatea, au o
utilitate pe o perioad de existen a obiectelor pe care le reprezint, le descrie, le
reflect;
Coleciile de date pentru tranzacii - au un caracter temporar i un coninut format din
totalitatea modificrilor care pot interveni pe parcursul unui interval de timp asupra
coninutului informaional din coleciile de date de baz;
Coleciile de date intermediare sunt obinute pe baza unor operaii de sortare, fuziune,
62

selectare din una sau mai multe colecii obiect potrivit unor cerine furnizate de
utilizator;
Coleciile de date statistice au un rol de orientare, de previziune, de fundamentare a
unor decizii strategice;
Colecii de date istorice au un rol de arhivare a coninutului unor colecii obiect, de
tranzacii sau statistice i reflect o stare trecut a fenomenelor i proceselor
economice.

Structura de date constituie o colecie de date ntre care s-au stabilit o serie de legturi, care
conduc la un anumit mod de identificare i de selectare a componentelor.
Baza de date poate fi definit ca fiind mai multe colecii de date omogene, cu legturi ntre ele,
stocate pe un suport de memorie extern i care formeaz un ansamblu:
organizat ( pe niveluri de organizare a datelor);
coerent (prin respectarea restriciilor de integritate i asigurarea proteciei datelor
mpotriva incidentelor);
structurat (datele i legturile dintre acestea sunt definite i descrise conform unui
model de date);
cu redundan minim i controlat a datelor;
accesibil mai multor utilizatori n timp util.
Apariia bazelor de date, ca mod de organizare a datelor n memoria extern, a determinat
i modificarea software-ului aferent stocrii i prelucrrii datelor. Datele memorate n fiiere sunt
prelucrate de programe scrise n diferite limbaje de programare universale, n timp ce datele
memorate n baze de date sunt gestionate prin programe de aplicaie scrise ntr-un sistem de
gestiune a bazelor de date (SGBD) ca software specializat.
Aadar, realizarea bazei de date i a programelor de aplicaie aferente (pentru descrierea i
manipularea datelor) sunt practic inseparabile, mpreun contribuind la realizarea unui sistem de
baz de date.
Un sistem de baz de date este format din urmtoarele componente:

baza/bazele de date, care reprezint componenta de tip date a sistemului;

sistemul de gestiune al bazei/bazelor de date, care constituie ansamblul de programe
prin care se asigur gestionarea i prelucrarea complex a datelor i care reprezint
componenta software a sistemului de baze de date;

alte componente, precum: proceduri manuale i automate, inclusiv reglementri

63

administrative, destinate bunei funcionri a sistemului, dicionarul bazei de date

(conine informaii despre date, structura acestora, elemente de descriere a semanticii,
statistici, documentaii), mijloace hardware utilizate, personalul implicat, reprezentat de
diferite categorii de utilizatori finali i personal de specialitate (administrator, analiti,
programatori, operatori).
Proiectarea unei baze de date presupune realizarea modelelor conceptual(MCD),
logic(MLD)i fizic, prin trecerea succesiv de la un model la altul.
Trecerea de la MCD, care este un model universal, spre o soluie informatic se face
gradat, lund n considerare un anumit tip de soluie i apoi, n cadrul tipului respectiv, o soluie
direct implementabil.
Modelul Conceptual Al Datelor(MCD)
Modelul conceptual al datelor este o metod abstract de reprezentare a tipurilor de
date, a legturilor dintre acestea, a dinamicii acestor legturi i a restriciilor (constrngerilor
aferente).
Pe baza unei analize detaliate i complete a intrrilor i a unor notaii i simboluri standardizate
se va construi modelul conceptual al datelor.
Fundamentul teoretic al cestui model este c structura datelor dintr-o organizaie poate
fi modelat folosind doar trei tipuri de obiecte: entiti, atribute, asocieri.
Entitate
O entitate este un model de obiect sau eveniment care are o existen de sine
stttoare i poate fi identificat, n raport cu celelalte obiecte de acelai tip, prin caracteristici sau
proprieti specifice.
Exemplu: Produs, Furnizor, Intrri, Ieiri, Beneficiar, Comand, Factur.
Modul de reprezentare a unei entiti este un dreptunghi n care se nscrie numele entitii.
Realizare a unei entiti se numete mulimea format din cte o valoare a fiecrui atribut al
entitii.
Fiecare entitate va fi identificat prin proprietile care o caracterizeaz, numite atribute.
Atributul
Un atribut se definete ca fiind o proprietate a unei entiti sau a unei corespondene,
caracterizat printr-un nume i un tip. Fiecare atribut care a fost selecionat la denumirea
coninutului unei entiti este o caracteristic semnificativ pentru domeniul studiat.
Un atribut poate fi :
64

simplu: atunci cnd pentru o entitate sau o asociere poate lua o singur valoare;
repetitiv: dac pentru o entitate sau o asociere poate lua mai multe valori.
Reguli privitoare la atribute:
fiecare atribut poate aprea ntr-o singur entitate (principiul nonredundanei );
un atribut poate avea mai multe valori elementare.
n reprezentarea grafic, identificatorul entitii se subliniaz.
Un domeniu este o mulime de valori scalare (atomice - care nu pot fi descompuse) de acelai
tip.
Exemple: mulimea codurilor personale, mulimea numelor de clieni, mulimea numelor de
localiti .a.
Cu aceste valori se pot efectua mai multe operaii:
cu majoritatea acestor valori se pot face comparaii;
cu unele valori se pot face i alte operaii: o cantitate poate fi nmulit cu un pre
(rezultnd o valoare), un pre poate fi nmulit cu o valoare (n cazul unei reaezri)
.a.m.d.

Asocierea
O asociere reprezint legtura sau corespondena existent ntre dou sau mai multe
realizri ale entitii. O asociere nu are o existen de sine stttoare, depinznd de existena
realizrilor entitilor pe care le leag, n consecin nu are identificatori specifici.
O asociere poate avea atribute proprii.
Mulimea care particip la asociere formeaz colecia acesteia; numrul acestora d
gradul sau dimensiunea asocierii.
ntre realizrile atributelor din entiti i cele ale proprietilor din asocieri (corespondene) se
stabilesc cardinaliti sau conectiviti.
Putem vorbi de o conectivitate minim (0 sau 1) i una maxim (1 sau n)

S clasificm n continuare legturile binare dup cardinalitatea acestora (cte entiti din
fiecare clas intr n cadrul legturii):
legturi de tip 1:1 (one-to-one); observm o astfel de legtur n cazul unei evidene a
personalului, care indic faptul c un departament este condus de un ef (un
departament nu poate fi condus de mai muli efi, o persoan nu poate conduce mai
multe departamente);
legturi de tip 1:n (one-to-many); n evidena personalului remarcm o astfel de
legtur ntre angajaii unui departament i departamentul n cauz (la un departament
lucreaz mai muli angajai, un angajat nu poate lucra n cadrul mai multor
65

departamente); la evidena facturilor remarcm o legtur ntre Facturi i Clieni (unui

client i se pot ntocmi mai multe facturi; nu se poate ntocmi o aceeai factur pentru
mai muli clieni);
legturi de tip m:n (many-to-many); o astfel de legtur exist ntre Clieni i Produse:
un client poate cumpra mai multe produse, i n acelai timp mai muli clieni pot
cumpra un acelai sortiment de produse.
Dup ce vor fi prezentate fundamentele modelului relaional, vom prezenta i tehnici de
implementare a acestor tipuri de legturi.
Exemplu de construire a modelului conceptual al datelor:
Prezentarea activitii de gestiune a materialelor
Se dorete ca n cadrul acestui sistem s se evidenieze furnizorii, facturile, magaziile,
tipurile de materiale i bonurile de consum.
Pentru a micora gradul de dificultate a aplicaiei se consider c toate materialele cuprinse pe
o factur sunt trimise unei singure magazii. Materialele sunt recepionate de o magazie pe baza
facturii i sunt eliberate seciilor de producie pe baza bonurilor de consum. Presupunem c
materialele au un pre unitar de achiziie fix, care nu depinde de furnizor.
Pe baza intrrilor (facturi) i a ieirilor (bonuri de consum) se dorete determinarea
nivelului stocurilor de materiale. Intrrile i ieirile se opereaz zilnic n fia de magazie.
n urma analizei problemei rezult entitile: Furnizor, Factura, Material, Magazie i Bon de
consum.
Identificarea corespondenelor:
Furnizor - Factur
Un furnizor poate emite de la 1 la n facturi, de unde rezult o coresponden EMITE.
Factur - Material
ntr-o factur sunt cuprinse de la 1 la n materiale n diferite cantiti, de unde rezult o
coresponden LINIE FACTUR.
Factur - Magazie
O magazie poate primi de la 1 la n facturi, de unde rezult o coresponden PRIMETE.
Bon de consum - Material
ntr-un bon de consum sunt cuprinse de la 1 la n materiale n diferite cantiti, de unde
corespondena LINIE BON DE CONSUM.
Bon de consum - Magazie
O magazie emite de la 1 la n bonuri de consum, de unde rezult corespondena REALIZEAZ.
Factur - Factur
66

O factur poate fi stornat de 0 sau n facturi de stornare, de unde rezult corespondena SE

STORNEAZ.
Stabilirea cardinalitilor:
Corespondena EMITE:
dinspre entitatea Furnizor (1, n)
un furnizor emite cel puin o factur (cardinalitate minim 1);
un furnizor poate emite mai multe facturi (cardinalitate maxim n).
dinspre entitatea Factur (1, 1)
factura este emis de cel puin i de cel mult un furnizor (cardinalitate 1, 1).
Corespondena PRIMETE
dinspre entitatea Magazie (1, n)
o magazie primete cel puin o factur (cardinalitate minim 1);
o magazie poate primi mai multe facturi (cardinalitate maxim n);
dinspre entitatea Factur (1, 1)
factura este trimis la cel mult i la cel puin o magazie (cardinalitate 1, 1).
Corespondena LINIE FACTUR
dinspre entitatea Factur (1, n)
o factur conine cel puin un material (cardinalitate minim 1);
o factur poate conine mai multe materiale (cardinalitate maxim n);
dinspre entitatea Material (1, n)
un material este inclus n cel puin o factur (cardinalitate minim 1);
un material poate fi inclus n mai multe facturi (cardinalitate maxim 1);
Corespondena LINIE BON DE CONSUM
dinspre entitatea Material (0, n)
un material poate s nu fie inclus n nici un bon de consum (cardinalitate
minim 0);
un material poate fi inclus n mai multe bonuri de consum (cardinalitate
maxim n);
dinspre entitatea Bon de consum (1, n)
un bon de consum conine cel puin un material (cardinalitate minim 1);
un bon de consum poate conine mai multe materiale (cardinalitate maxim n).
Corespondena DESTINAT
dinspre entitatea Bon de consum (1, 1)
un bon de consum este destinat cel puin i cel mult unei magazii (cardinalitate
1, 1)
dinspre entitatea Magazie (1, n)
67

unei magazii i este destinat cel puin un bon de consum (cardinalitate minim
1);
unei magazii i sunt destinate mai multe bonuri de consum (cardinalitate
maxim n).
Pe baza acestor reguli de gestiune se construiete modelul conceptual al datelor (Figura 3.3)

FURNIZOR
Cod furnizor
Adresa
Banca
Cont

FACTURA
1,n

emite

1,1

0,n

Nr factura

se
storneaza

Data factura

1,1
1,1

1,n
LINIE FACTURA

MAGAZIE

primeste
cant fact

Cod magazie
Denumire magazie 1,n

1,n
MATERIAL

Gestionar

Cod material
1,1

Den mat
BON DE CONSUM

destinat

1,1

Nr bon consum

0,n
1,n

Linie bon de comand

Data
Den sectie

Fig. 3.3 Modelul conceptual al datelor

Dup realizarea modelului conceptual este necesar s se stabileasc i regulile pe care
datele trebuie s le respecte pe tot parcursul prelucrrii. Acestea se numesc restricii de
integritate (RI). Ele pot fi structurale i semantice, iar dup momentul n care acioneaz,
restriciile de integritate sunt statice i dinamice.
Restriciile de integritate structurale sunt inerente conceptelor folosite la modelarea
datelor, n timp ce restriciile de integritate semantice sunt introduse de utilizator pentru a
reflecta corect realitatea i sunt expresia regulilor de gestiune aplicate n organizaie, fiind o
68

consecin a reglementrilor legislative i normative n vigoare, ct i a reglementrilor i

normelor interne.
Restriciile de integritate statice vizeaz starea sistemului informatic, independent de
timp, iar restriciile de integritate dinamice privesc evoluia n timp a datelor.
Restriciile de integritate de domeniu sunt condiii impuse asupra ansamblului de valori
acceptate pentru un atribut n cadrul tipului sau domeniului i pot viza:
coninutul unui atribut al aceleiai realizri;
corelaii ntre valorile mai multor atribute ale aceleiai realizri;
corelaii ntre atributele realizrilor mai multor entiti diferite;
corelaii ntre realizri distincte ale aceleiai entiti.
Exemple de RI:
valorile atributelor cu rol de identificator trebuie s fie unice i nenule;
existena unei asocieri este condiionat de existena entitilor participante (este vorba
de integritatea referenial);

cardinalitile minime i maxime se stabilesc pe baza regulilor de desfurare a

activitilor n sectorul vizat;
Exemplu:
Furnizori

0,n

1,1

Facturi

emit

cardinalitate minim 0: un furnizor poate exista, chiar dac ntr-o anumit perioad nu a
emis nici o factur;
cardinalitate maxim 1: orice factur este emis de un furnizor;
Respectarea unor restricii de domeniu, cum ar fi:
data facturii s nu fie anterioar datei curente;

greutatea materialelor s fie cuprins n intervalul [0-500]

Corelaii ntre atributele mai multor entiti sau asocieri diferite, obinute pe baza unor operaii de
sintetizare (numrare, nsumare, medie etc.):

cantitate facturat<=cantitate_n_stoc +10

Incluziunea de roluri: dac o entitate E joac un rol r1 ntr-o asociere, atunci trebuie s joace i
rolul r2 ntr-o a doua asociere.
Simbol:

r1

r2

Exemplu:
Un client poate primi materiale solicitate numai dac a trimis furnizorului respectiv nota
contabil. (Figura 3.4)

69

Client
trimite

primete
Incluziune
de roluri

se trimit

se
primesc

Se trimite

Se primete

Materiale

Not comand

Fig. 3.4 Incluziunea de roluri

Excluziunea de roluri apare n situaia n care rolurile ale aceleiai entiti se exclud reciproc.
Simbol:
r1
r2
Exemplu:
O agenie imobiliar are ca obiect de activitate vnzarea - nchirierea de apartamente. Pentru
evidena vnzrilor i nchirierilor trebuie s se in seama de faptul c un apartament nu poate
fi vndut i nchiriat n acelai timp, deci cele dou roluri ale entitii Apartament se exclud
reciproc. (Figura 3.5)
Apartament
Se vinde

Se nchiriaz
Conine

Cuprinde

Excluziune
de roluri

Se ncaseaz

Document ncasare

Fig. 3.5 Excluziunea de roluri

70

Se ncaseaz

Egalitatea de roluri nseamn o resticie de incluziune reciproc ntre dou roluri ale aceleiai
entiti.
Simbol:

r1

r2

Exemplu:
Un pensionar cu venituri mici pltete intreinerea pentru apartamentul n care locuiete
dar n acelai timp primete o subvenie din partea statului pe timp de iarn. Exist egalitate
ntre roluri pe care entitatea Pensionar venituri mici le are n cadrul celor dou
corespondene.(Figura 3.6)

Pensionar venituri
mici
primete

pltete

=
egalitate

primete

pltete
de roluri
Se reine

Se acord

ntreinerea

Subvenii

Fig. 3.6 Egalitate de roluri

Asemntor se stabilesc i restriciile de incluziune, excluziune i egalitatea de asocieri

dac exist sau care vizeaz att asocierea (toate rolurile dintr-o asociere), ct i toate
entitile participante.
Dependene funcionale
Presupunem c am proiectat o relaie cu urmtoarea structur:
CLFACTURI(Nrf, Codc, Numec, Adresa, Dataf)
Observm dependena atributelor Numec i Adresa fa de atributul Codc, i de aici rezult
c fiecare valoare a atributului Codc determin n mod univoc valoarea corespunztoare a
celorlalte dou atribute. Aceast structur (schem de relaie) introduce o redundan relativ la
atributele Numec i Adresa, ale cror valori se repet pentru fiecare factur a aceluiai client.
Aceast redundan conduce la urmtoarele anomalii:
la adugare: nu se poate nregistra un potenial client dect dup ce se emite o factur
71

pentru acesta;
la tergere: dac se terg toate facturile emise pentru un anumit client se pierd toate
informaiile despre acesta; ulterior, dac acesta cumpr nite produse, informaiile pe
care tocmai le-am ters trebuie introduse din nou;
la modificare: dac se modific o informaie despre un anumit client (numele, adresa),
este necesar parcurgerea ntregii relaii pentru a actualiza toate apariiile acestui
client; n caz contrar apare pericolul introducerii unei inconsistene n baza de date
datorit faptului c pentru acelai client snt nregistrate informaii diferite.
Aceste anomalii pot fi evitate dac se descompune relaia CLFACTURI n dou relaii: CLIENTI
i FACTURI, avnd structurile:
CLIENTI(Codc, Numec, Adresa)
FACTURI(Nrf, Codc, Dataf)
Un "dezavantaj" al descompunerii efectuate este acela c pentru a obine informaiile
despre un client pentru care am emis o factur este necesar efectuarea unei operaii de
cuplare a celor dou relaii. Operaia de cuplare (realizat printr-o instruciune Select care
extrage informaii din cele dou tabele) nu este att de costisitoare pe ct ar putea prea la
prima vedere, dac se aleg n mod corespunztor cheile primare i modalitile de indexare.
Dup cum rezult din exemplul de mai sus problema alegerii unui model conceptual
corect pentru o baz de date relaional este, de cele mai multe ori, formulat n termenii
determinrii unor descompuneri pentru scheme de relaii date, descompuneri care s izoleze
dependenele existente i prin aceasta s se evite anomaliile care decurg din ele.
Definiia 1. Fie R(A1, A2,..., An) o relaie, X i Y dou atribute (simple sau compuse) submulimi
ale mulimii de atribute (A1, A2,..., An). Atributul X determin atributul Y (sau Y depinde funcional
de X) i notm XY dac i numai dac orice valoare a atributului X determin n mod unic
valoarea atributului Y.
Observaii:

dac XY atunci pentru orice ZY avem XZ;

dac XY atunci pentru orice VX avem VY.

Definiia 2. Fie XY o dependen funcional; spunem c avem dependen total dac nici o
submulime VX nu induce o dependen funcional VY; n caz contrar, dac exist o
submulime VX care induce o dependen funcional VY, spunem c avem dependen
parial.
Existena n cadrul relaiilor a dependenelor funcionale este un fapt natural. n orice
relaie exist o dependen funcional a oricrui atribut fa de atributul cheie (sau setul de
atribute care formeaz cheia primar): tim c atributul cheie identific n mod unic fiecare tuplu.

72

Dependenele funcionale existente n cadrul unei relaii se datoreaz semanticii segmentului

din lumea real care se modeleaz prin aceast schem i reprezint restricii referitoare la
realitatea modelat. Aceste restricii constituie informaii asociate relaiei i care nu pot fi
nglobate n reprezentarea relaiei, dei se reflect indirect n aceast reprezentare prin valorile
concrete pe care le iau atributele relaiei. Singura cale de a determina dependenele funcionale
din cadrul unei scheme de relaie este aceea de a lua n considerare semnificaia tuturor
atributelor componente.
Modelarea Logic A Datelor(MLD)
Proiectarea unei baze de date presupune realizarea modelelor conceptual, logic i fizic,
prin trecerea succesiv de la un model la altul.
Trecere de la MCD, care este un model universal, spre o soluie informatic se face gradat,
lund n considerare un anumit tip de soluie i apoi, n cadrul tipului respectiv, o soluie direct
implementabil.
Expresia MCD n termenii unui anumit tip de soluie informatic constituie modelul logic
al datelor (MLD)
MLD are asociate principii generale pentru gestionarea, respectiv definirea (structurarea)
datelor, manipularea i asigurarea integritii datelor , fr s reflecte modul de reprezentare a
acestor date pe suportul de memorare.
MLD a cunoscut de-a lungul timpului mai multe generaii, aa cum se poate observa n
figura de mai jos (Figura 3.7):
Fiier

Ierarhizate

MLD
Baze de date
SGBD

Reea
Relaionale
Orientate
obiect

Fig. 3.7 Evoluie MLD

Fcnd o analiz a modelelor nerelaionale comparativ cu modelul relaional rezult urmtoarele

avantaje n favoarea celui din urm:
modelul relaional este un model simplu care permite utilizatorului s vad baza de date
ca o colecie de tabele (relaii) o reprezentare mental larg accesibil att
73

informaticienilor ct i neinformaticienilor;
asigur independena fizic i logic a programelor de prelucrare fa de structura
datelor, eliminnd din schema conceptual i shemele externe toate detaliile privind
structura de memorare i strategiile de acces;
operaia de normalizare introdus de modelul relaional asigur gsirea structurii optime
a datelor prin nlturarea anomaliilor de actualizare i diminuare a redundanei.
prin introducerea noiunilor de dependen funcional, dependen multivaloare i
dependen jonciune modelul relaional depete stadiul limitat al reprezentrii datelor
n calculator, avansnd spre formalizarea elementelor de semantic ce guverneaz
domeniul informaiilor;
suplee n comunicare prin intermediul limbajelor neprocedurale de nivel nalt.

MLD se obine aplicnd urmtoarele regulile de trecere de la MCD la MLD:

Fiecare entitate devine o relaie. Identificatorul entitii.devine cheia primar a relaiei.

Atributele entitii devin atribute ale relaiei.
Asocierea non-ierarhic devine o relaie. Atributele proprii ale asocierii (dac exist)
devin atribute ale relaiei. Identificatorul asocierii.devine cheia primar a relaiei, iar
identificatorii entitilor participante la asociere devin chei externe. n cazul n care
asocierea nu are atribute, cheia primar se constituie prin concatenarea identificatorilor
entitilor participante la asociere.
Asocierea ierarhic devine o legtur ntre relaii. Concret, relaia provenind din
entitatea pentru care cardinalitile sunt 1,1 absoarbe identificatorul celeilalte entiti,
care se transform n cheie extern. Dac se ntmpl ca asocierea s aib proprietate
specific, atributul respectiv este transferat i devine cmp al relaiei care provine din
entitatea cu cardinalitate maxim 1.

Modelul logic al datelor se poate prezenta astfel:

scriind numele relaiei, urmat de atributele sale ntre paranteze; cheia primar se
subliniaz cu linie continu, iar cheia extern cu linie punctat.
Exemplu:
Furnizor(Cod furnizor, Denumire furnizor, Adres furnizor, Cod fiscal, Banca,Cont)
sau
Factur(Numar factur, Data factur; Cod furnizor, Cod magazie)

grafic, utiliznd pentru relaie simbolul din MCD pentru entitate, iar pentru evidena
legturilor linii orientate; cheile primare i externe se subliniaz.

74

Furnizor
Cod furnizor
Denumire furnizor
Adres furnizor
Cod fiscal
Banca
Cont

Factur
Numr factur
Dat factur
Cod furnizor
Cod magazie

Exemplu de aplicare a regulilor de trecere de la MCD la MLD

S considerm modelul conceptual prezentat n Figura 3.3
Relaiile obinute din entiti sunt: Factur, Furnizor, Magazie, Material, Bon de consum
Asocierile non-ierarhice Linie factur, Linie bon de consum se transform n relaii.
Relaia Linie factur va avea cheia primar format din concatenarea identificatorilor entitilor
participante la relaie (Numr factur, Cod material) i proprietatea specific asocierii Linie
factur (Cantitate intrat) care devine atribut al relaiei. La fel se procedeaz i n cazul
asocierii Linie bon de consum.
Asocierile ierarhice Emite, Primete, Destinat se transform n legturi i transfer cheile
primare ctre relaiile provenite din entiti pentru care cardinalitile sunt 1,1. Astfel, asocierea
Emite transfer din relaia Furnizor cheia primar Cod furnizor n relaia Factur pe post de
cheie extern.
Modelul logic se va prezenta astfel:
Furnizor (Cod furnizor, Denumire furnizor, Adres furnizor, Cod fiscal, Banca,Cont)
Factur (Numar factur, Data factur, Cod furnizor, Cod magazie)
Magazie (Cod magazie, Denumire magazie, Gestionar)
Linie factur (Numar factur, Cod material, Cantitate intrat)
Material (Cod material, Denumire )
Linie bon de consum (Nr bon de consum, Cod material, Cantitate ieit)
Bon de consum (Nr bon de consum, Data bon de consum, Denumire secie, Cod magazie)
Teste de evaluare a cunotinelor
1. Tehnica entitate-asociere permite construirea modelului structural sub forma unei diagrame
entitate-asociere, prin parcurgerea urmatorilor pasi:
a. identificarea componentelor, identificarea asocierilor, stabilirea semnificatiei legaturii si
identificarea nodurilor-eticheta (sub forma de romb).
b. identificarea componentelor, identificarea asocierilor, codificarea asocierilor, identificarea
75

atributelor si stabilirea atributelor de identificare a entitatilor.

c. identificarea componentelor, identificarea atributelor, identificarea erorilor de asociere si
stabilirea atributelor de identificare a entitatilor.
d. identificarea asocierilor, identificarea atributelor, stabilirea atributelor de identificare a
entitatilor si marcarea acestora pentru operatia de stergere.
e. identificarea componentelor, identificarea asocierilor, identificarea erorilor de asociere si
stabilirea entitatilor pentru stergere.
2. Dependenta functionala reprezinta:
a. o structura ce permite vizualizarea structurii ierarhice, descrierea programului sau a unui
modul fiind stabilite pe mai multe niveluri
b. unei inregistrari din tabelul B ii corespunde cel mult o inregistrare din tabela A
c. demersul metodologic de dezvoltare a sistemelor informatice
d. o proprietate a semnificatiei sau a semanticii atributelor, indicand modul in care sunt legate
atributele unele de altele.
e. conceptprocesul de evaluare a unui sistem
3. ......................... pun laolalt toate forele interesate n dezvoltarea sistemelor: utilizatorii
cheie, managerii i analitii de sistem implicai n analiza sistemului curent. Din acest punct de
vedere fiind similar interviului la nivel de grup. Totui, se urmeaz o anumit secven de
derulare a activitilor pe baza unor roluri bine definite.
a. Sesiunile JAD (Joint Application Design) ;
d. Sistemele de sprijinire a grupurilor
de lucru;
b.
Intervievarea grupurilor de oameni cu e. Prototipizarea.
interese comune;
c. RAD (Rapid Application Development).
4.
...................... este un proces iterativ prin care analitii i utilizatorii pun n discuie o
versiune rudimentar a unui sistem informaional, care va fi ntr-o continu schimbare, n funcie
de reacia utilizatorului.
a. Sesiunile JAD (Joint Application Design); d. Sistemele de sprijinire a grupurilor de
lucru;
b. Intervievarea grupurilor de oameni cu
e. Prototipizarea.
interese comune;
c. RAD (Rapid Application Development);
5. ...........................este o metodologie de realizare a sistemelor informa-ionale care
promite sisteme mai bune, mai ieftine i realizate mai rapid.
a. Sesiunile JAD (Joint Application Design) ; d. Sistemele de sprijinire a grupurilor de
lucru;
b. Intervievarea grupurilor de oameni cu
e. Prototipizarea.
interese comune;
c. RAD (Rapid Application Development);

76

6........................ evideniaz, la nivel conceptual, modul de structurare a datelor i a legturilor

dintre ele. Cea mai utilizat tehnic este entitate-asociere.
a. Modelarea proceselor;
d. Analiza asocierilor;
b. Analiza dinamic;
e. Analiza funcional.
c. Analiza structural;
7. ......................... evidentiaz comportamentul elementelor sistemului la anumite
evenimente. Una dintre tehnicile utilizate este diagrama stare-tranziie.
a. Modelarea proceselor;
d. Analiza asocierilor;
b. Analiza dinamic;
e. Analiza functionala.
c. Analiza structural;
8........................... evideniaz modul de asigurare a cerinelor informa-ionale (fluxul
prelucrrilor) din cadrul sistemului, prin care intrrile sunt transformate n ieiri. Cea mai utilizat
tehnic este diagrama de flux a datelor.
a. Modelarea proceselor;
d. Analiza asocierilor;
b. Analiza dinamic;
e. Analiza funcional.
c. Analiza structurala;
9. Considernd urmtorul MCD caracterizat prin faptul c ne confruntm cu furnizori
specializai, acetia putnd livra doar o singur materie prim, livrarea realizndu-se doar o
singur dat:

10. Stabilii care este cardinalitatea pentru asocierea celor 2 tipuri de entiti Furnizori-Materii
prime:
a
b.
c.
d.
e.

(n,1)
(0,0)
(1,1)
(0,n)
(0,1)

- (1,1)
- (0,n)
- (1,1)
- (0,n)
- (0,n)

77

78

Capitolul 4
Proiectarea logic i fizic sistemelor informatice
Obiective:
nsuirea noiunilor de baz legate de arhitectura i specificaiile logice ale sistemului informatic
Delimitarea componentelor sistemului informatic din punct de vedere structural i funcional
Stabilirea necesarului de resurse i a modului de implementare hardware i software pentru noul
sistem informatic
Cuvinte cheie: proiectare logic, proiectare fizic, normalizarea relaiilor, formalizarea
atributelor, codificarea atributelor
Procesul de proiectare este o etap important n realizarea sistemelor informatice, ea
urmnd etapelor de investigare i de modelare a sistemului informatic. n cadrul ei, utiliznd
tehnici de proiectare conforme cu multidimensionalitatea i complexitatea sistemelor informatice,
se elaboreaz un proiect n care este configurat arhitectura noului sistemului, sunt prezentate
logic i fizic componentele sistemului informatic proiectat.
Proiectarea sistemelor informatice se bazeaz pe rezultatele obinute din analiza i
interpretarea modelelor noului sistem informatic. Analitii evalueaz i revizuiesc modelele
pentru a obine specificaiile logice de sistem, specificaii care descriu n detaliu funciile
sistemului informatic i care vor sta la baza soluiilor tehnice alese de proiectant.
n funcie de strategia de proiectare aleas: proiectare structurat, proiectare orientat obiect,
prototipizarea, JAD (Join application development), RAD (Rapid application development)3,
activitile de proiectare difer de la o metodologie la alta.
Astfel, conform metodologiei MERISE4, proiectarea sistemului informatic se face pe
subansambluri ale domeniilor ce urmeaz a fi informatizate, pentru fiecare subansamblu
realizndu-se un studiu detaliat i un studiu tehnic.
Studiul detaliat se bazeaz pe rezultatele investigrii i presupune obinerea specificaiilor
funcionale generale detaliate ale noului sistem.
Specificaiile cuprind:
3
4

- https://en.wikipedia.org/wiki/Rapid_application_development
Merise Method and knowledge, www.cmi.univ-mrs.fr
79

 Schema organizatoric;
Prezentarea activitilor, proceselor din cadrul unitii economice;
Prezentarea procedurilor utilizate pentru realizarea procedurilor;
Prezentarea sarcinilor manuale, total sau parial automatizate;
Lista resurselor umane i materiale implicate cu alocarea pe sarcini;
Prezentarea situaiilor de ieire;
Lista echipamentelor utilizate.
Studiul tehnic presupune proiectarea logic i tehnic a bazei de date, descrierea arhitecturii
prelucrrii datelor, descrierea arhitecturii produsului program.
Metodologia OMT, care utilizeaz un set de concepte orientate pe obiecte i care este i cea
mai utilizat metodologie orientat obiect, realizeaz o proiectare a sistemului informatic i o
proiectare a obiectelor.
- Proiectarea sistemului informatic presupune realizarea urmtoarelor activiti:
- Descompunerea n subsisteme informatice. Subsistemele informatice obinute sunt
formate dintr-un ansamblu de operaii, evenimente, asocieri, mesaje, avnd o interfa
fix cu restul sistemelor.
- Identificarea subsistemelor informatice concurente. Subsistemele informatice
concurente sunt identificate n scopul optimizrii implementrii prin utilizarea aceleai
platforme hardware.
- Stabilirea necesarului de resurse i a modului de implementare hardware i software
pentru fiecare subsistem.
- Alegerea modului de organizare a datelor i a tipurilor de acces la date.
- Stabilirea controlului intern i extern pe fluxul evenimentelor sau pe fluxul prelucrrilor.
- Stabilirea condiiilor limit, care se refer la iniializri, terminarea normal sau
anormal, prioriti.
Rezultatul proiectrii sistemului informatic const n realizarea arhitecturii de baz a
sistemului informatic i elaborarea unor decizii la nivel global.
Proiectarea obiectelor rafineaz modelele obinute n faza de analiz, prin adugarea detaliilor
de implementare. n cadrul acestei etape se desfoar urmtoarele activiti:
identificarea operaiilor;
proiectarea algoritmilor;
rafinarea, restructurarea modelului datelor;
implementarea controlului;
implementarea asocierilor;
gruparea datelor i asocierilor n module.
80

Rezultatul acestei etape este detalierea celor trei modele: modelul obiectelor, modelul
dinamic i funcional.
Se poate observa c, indiferent de strategia de proiectare adoptat, activitile principale pentru
proiectarea unui sistem informatic sunt:
stabilirea arhitecturii sistemului informatic /subsistemului informatic;
proiectarea listelor / situaiilor de ieire;
proiectarea bazei informaionale;
proiectarea interfeei cu utilizatorii;
proiectarea programelor.
n literatura de specialitate, aceste activiti sunt grupate, conform gradului de detaliere, n
dou categorii , care reprezint de fapt, etapele proiectrii sistemelor informatice: proiectarea de
ansamblu / general / logic i proiectarea de detaliu / fizic.
n cadrul proiectrii de ansamblu / generale / logice se elaboreaz modelul de
ansamblu a sistemului informatic, adic se stabilete ce trebuie sa se construiasc i care sunt
specificaiile logice ale sistemului informatic.
Proiectarea de detaliu / fizic detaliaz componentele sistemului informatic, arat cum
trebuie s fie construite i cum s funcioneze n mediul real, n funcie de resursele disponibile.
4.1 Proiectarea de ansamblu / general / logic
Proiectarea de ansamblu i propune s defineasc sistemul informatic din punct de
vedere funcional i structural. Aceasta nseamn c se identific componentele, dup care se
vor descrie att din punct de vedere structural, ct i funcional.
Structura de ansamblu a unui sistem informatic e format din intrri, ieiri i prelucrri. (Figura
4.1)
Intrri

Documente
justificative

PRELUCRRI

Ieiri

Rapoarte

SGBD

Proceduri
Figura 4.1 Structura de ansamblu a unui sistem informatic
81

Intrrile sunt reprezentate de:

tranzacii externe care redau dinamica operaiilor economice, provin din exteriorul
sistemului informatic electronic de calcul i sunt furnizate de proceduri automate.
Exemplu: nregistrarea unei operaii de aprovizionare cu marf;
tranzacii interne care redau modificrile structurale din cadrul bazei de date; sunt
asigurate exclusiv n cadrul sistemului informatic prin intermediul procedeului de
exploatare sau de actualizare a bazei de date. Exemplu: totalul facturilor primite de la
un furnizor care actualizeaz soldul furnizorului respectiv.

Prelucrrile sunt asigurate de un ansamblu de proceduri automate care realizeaz actualizarea

i exploatarea coleciilor de date ca urmare a tranzaciilor interne i externe n vederea obinerii
rapoartelor, listelor, situaiilor de ieire ale sistemului informatic.
Ieirile sistemului informatic sunt rezultatul prelucrrii bazei de date i sunt redate n funcie de
coninutul lor i de structura lor sub form de indicatori sintetici, rapoarte, liste, situaii de ieire,
grafice, stocare pe suporturi.
Schema structural a unui sistem informatic pune n eviden triada intrri prelucrri ieiri.
Pentru determinarea necesarului de date de intrare se utilizeaz mai multe metodologii care
determin anumite variante de abordare a proiectrii de ansamblu.
Astfel, n funcie de complexitatea obiectivelor stabilite, de aria de cuprindere a noului sistem
informatic, de posibilitile de modificare a ieirilor, de costurile i termenele de realizare a
sistemului informatic, se folosesc urmtoarelor variante de abordare a proiectrii de ansamblu:
Prima variant de abordare, pe baza principiului ieiri-intrri asigur determinarea
coninutului bazei informaionale n funcie de obiectivele stabilite de unitatea beneficiar. n
aceast variant ieirile sunt reflectate de obiectivele informaionale solicitate, n timp ce intrrile
sunt reflectate de coninutul bazei informaionale.
Avantajul acestei metode const n furnizarea unui coninut complet al bazei
informaionale determinat iniial i pe baza stabilirii listelor de ieire.
Dezavantajul este legat de imposibilitatea emiterii de noi situaii de ieire, deoarece
varianta nu poate genera la ieire dect coninutul bazei informaionale De asemenea, nu poate
genera ali indicatori rezultai ca urmare a aplicrii unui algoritm de calcul asupra coninutului
bazei informaionale.

82

A doua variant, pe baza principiului intrri - ieiri determin coninutul bazei

informaionale independent de ieirile solicitate urmnd s se asigure att cerinele imediate ct
de perspectiv.
Avantajul const n determinarea unei baze informaionale complete, cu meniunea
ns c unele atribute nu vor fi poate niciodat utilizate n prelucrrile sistemului informatic.
Dezavantajul rezid din cheltuielile mari de realizare a bazei informaionale, cheltuieli
determinate de studierea tuturor activitilor desfurate i de supradimensionarea acesteia.
A treia variant, mixt mbin avantajele celor dou variante prezentate i le
minimizeaz dezavantajele.
n practica economic, datorit vehiculrii unui numr foarte mare de documente de intrare, la
proiectarea sistemelor informatice se folosete varianta de abordare pe baza principiului ieiri intrri
Activitile desfurate n cadrul proiectrii de ansamblu sunt:
stabilirea obiectivelor noului sistem informatic.
proiectarea rapoartelor, listelor, situaiilor de ieire
proiectarea bazei informaionale.
Stabilirea obiectivelor sistemului informatic
Obiectivele sistemului informatic reprezint scopuri imediate i de perspectiv care vor
determina structura, funcionalitatea i conexiunile noului sistem informatic i care vor asigura
minimizarea perturbaiilor aprute n desfurarea activitilor, contribuind astfel la maximizarea
eficienei economice i a rentabilitii unitii beneficiare.
Determinarea obiectivelor noului sistem are la baz ideea potrivit creia acest sistem
este dedicat procesului decizional, deoarece numai cu un management performant se pot obine
efecte economice ridicate, cu eforturi ct mai reduse.
Din acest motiv, obiectivele unui sistem informatic pot fi grupate n dou categorii:
Obiective generale ce trebuie s asigure cunoaterea exact i operativ a activitii
desfurate de unitatea economic;
Obiective specifice care vor sigura condiiile necesare realizrii obiectivelor generale.
Obiective generale
Obiectivele generale ale unui sistem informatic urmresc generarea i furnizarea operativ
i selectiv, ctre toate nivelele de conducere, a unor date cu caracter strategic, tactic, operativ
i funcional, pentru asigurarea atributelor conducerii i ale funciilor unitilor economice. n
raport de aceste aspecte, obiective generale pot fi:
de conducere (manageriale);
83

 funcionale.
Obiectivele de conducere vizeaz probleme cu caracter global i structural, de conducere ale
unitii economice i se axeaz pe:
realizarea n condiii de maxim eficien a ntregii activiti;
realizarea global i structural a indicatorilor economico-financiari (cifra de afaceri,
valoarea adugat, profitul brut i net, capitalul propriu, capacitatea de plat, rata
rentabilitii, eficiena utilizrii fondurilor fixe etc.), calculul i planificarea rezultatelor,
planificarea financiar a investiiilor, previzionarea activelor circulante i a surselor de
finanare, previzionarea activitii de trezorerie, inclusiv utilizarea bugetului general al
unitii economice;
perfecionarea structurilor i a activitii de producie n vederea asigurrii unui optim
global;
asigurarea unui fundament informaional superior pentru fundamentarea i
implementarea strategiilor i politicilor unitii economice;
realizarea unei funcionaliti superioare de ansamblu a sistemului decizional;
facilitarea introducerii i utilizrii anumitor tehnici, metode i sisteme manageriale;
degrevarea conducerii de procesele decizionale de rutin, formalizarea prin noul sistem
a informaiilor sintetice necesare derulrii relaiilor informaionale cu organismele de stat
i cu alte regii autonome sau societi comerciale;
creterea operativitii i gradului de fundamentare i adoptare a deciziilor.
Obiectivele funcionale au n vedere informatizarea activitilor eseniale i specifice ale unitii
economice n vederea asigurrii funciilor sale fundamentale: cercetare-dezvoltare, comercial,
producie sau exploatare, financiar- contabilitate, personal.
1. Activitatea de cercetare-dezvoltare vizeaz strategiile de dezvoltare a produselor i
tehnologiilor precum i cele de dezvoltare a unitii economice n ansamblul su. Informatizarea
acestor activiti presupune informatizarea urmtoarelor subactiviti:
proiectare produselor;
proiectarea n domeniul tehnologiilor i echipamentelor;
determinarea capacitii de producie i utilizare eficient a acesteia;
elaborarea normativelor i normelor de consum pentru resurse materiale i energetice;
elaborarea normativelor i normelor de munc i a consumurilor specifice de
manoper.
2. Activitatea de producie desfurat n cadrul unor compartimente are n vedere elementele
specifice fiecrei subactiviti, din punct de vedere informatic, dup cum urmeaz:
definirea ingredientelor i proceselor ce sunt utilizate n producia continu;
definirea seciilor, operaiilor i ordonarea lor, care intervin n fabricarea unui produs;
84

 definirea materialelor i (sub)ansamblelor folosite pentru fabricarea unui produs;

gestiunea calitii;
previziunea produselor;
program de producie;
planificarea cerinelor materiale;
planificarea cerinelor capacitii;
planificarea cerinelor de manoper;
planificare resurse.
3. Activitatea comercial este reprezentat prin trei subactiviti: aprovizionare, desfacere,
marketing. Sistemul informatic va trebui sa soluioneze optim urmtoarele aspecte specifice:
Subactivitatea de aprovizionare
determinarea necesarului de resurse materiale i energetice;
contractarea necesarului de aprovizionat.
Subactivitatea de desfacere
situaia necesarului de livrat conform contractelor;
situaia cantitativ i valoric a livrrilor ;
urmrirea ritmicitii livrrilor n scopul onorrii contractelor.
Subactivitatea de marketing
1. studierea caracteristicilor tehnico-economice, inclusiv a tehnicilor de comercializare a
produselor concurente, furnizate de alte societi comerciale din tar sau strintate;
2. evoluia pieelor de desfacere n vederea realizrii relaiilor valutar-financiar i de
distribuire a produselor proprii;
3. cooperarea cu alte societii comerciale din ar sau strintate n vederea promovrii
produselor pe tere piee
4. Activitatea financiar-contabil desfurat n cadrul compartimentelor specifice presupune
rezolvarea din punct de vedere informatic a unor elemente specifice dup cum urmeaz:
Subactivitatea financiar
elaborarea bugetului general al unitii economice pe an financiar, i desfacere pe
subuniti.
gestiunea creditului clieni pune n eviden sumele datorate de clieni, ce rezult din
datele generate de cumprrile i plile acestuia;
gestiunea numerarului colecteaz informaii privind toate intrrile i ieirile de numerar
din organizaie, n mod periodic sau chiar n timp real.
gestiunea portofoliului (titlurilor) de plasament evideniaz surplusul de numerar investit
n hrtii de valoare pe termen scurt (fie cu un grad de risc sczut-bonuri de tezaur,
certificate de trezorerie, fie cu un grad de risc mai ridicat dar i cu posibiliti mai mari
85

de ctig), astfel nct sumele rezultate s poat fi disponibile atunci cnd sunt
necesare fonduri.
Subactivitatea contabil se desfoar n dou circuite:
Contabilitatea financiar (sintetic), reflect starea patrimonial a unitii economice
prin intermediul activului, datoriile (obligaiile), capitalul propriu i rezultatele nete
obinute pe parcursul unei perioade de gestiune.
Contabilitatea de gestiune (analitic), ofer informaii care reflect cheltuielile i
veniturile pe purttori de valoare i resursele repartizate spre gestionarea la nivelul
fiecrei structuri organizatorice.
Subactivitatea de control financiar, la nivelul unitii economice urmrete analiza i controlul
gestiunii patrimoniului regiei automate sau societii comercial prin instrumente proprii, n
scopul prevenirii i sesizrii nclcrii normelor legale de utilizare a resurselor umane, materiale
i bneti.
5. Activitatea de personal acoper ntreaga gam de activitii legate de evidena personalului,
salarizarea, perfecionarea calificrii personalului i presupune rezolvarea sub aspect informatic
a urmtoarelor sarcini:
Subactivitatea de eviden a personalului trebuie s asigure:
evidena personalului pe meserii, n funcie de vechime, pe locuri de munc, pe diferite
intervale de timp;
verificarea ncadrrii personalului pe meserii, funcii i locuri de munc;
evidena micrii de personal (angajrii, promovri, transferri, pensionari, concedii)
Subactivitatea de salarizare asigur:
nregistrarea orelor lucrate pe baza fielor de partaj sau a foilor colective de prezen,
prin care se determin numrul orelor care va fi luat n calcul la stabilirea salariilor
pentru o lun. Poate s apar situaia n care se vor folosi fiele de manoper;
calculul drepturilor salariale se particularizeaz n funcie de modul de plat al fiecrei
organizaii;
evidenierea obligaiilor de plat ale salariailor, fie sub forma impozitelor i contribuiilor
fie sub forma reinerilor datorate ctre firme sau bnci.
Subactivitatea de perfecionare a calificrii personalului se particularizeaz de la o firm la alta,
n funcie de specificul obiectivului de activitate i de criteriile de evaluare stabilite la nivelul
politicii de personal i urmrete:
performanele salariailor, pe faza unor criterii de evaluare stabilite n funcie de
specificitatea activitii desfurate. Pe baza evalurilor de performane conducerea
poate stabili nivelul salariului pentru fiecare angajat, posibilitatea de promovare,
necesitile de instruire .a.
86

nregistrarea pregtirilor profesionale i a instruirilor la care au participat salariaii,

urmrindu-se prelucrarea datelor necesare elaborrii programului de mbuntire a
aptitudinilor i performanelor profesionale ale salariailor;
stabilirea prioritilor n angajarea a noi categorii de salariai, astfel nct activitatea
unitii economice s se desfoare, la cel mai nalt grad de tehnicitate.

Obiectivele specifice
Obiectivele specifice asigur condiiile realizrii obiectivelor generale i trebuie s in seama de
aspectele concrete din realitatea unitii economice studiate, cum ar fii:
mrimea unitii economice;
structura sa organizatoric;
ponderea acesteia ntr-o ramur de activitate;
gradul de participare al unitii economice la derularea operaiunii de export-import,
cooperarea internaional;
alte elemente ce pot conduce la alte tipuri de obiective cu o nuanare specific.
Obiectivele generale i specifice ale unui sistem informatic pot urmri i alte aspecte, cum ar
fi:
asigurarea proiectrii automate a datelor n condiii de eficien economic;
optimizarea fluxurilor i circuitelor informaionale;
furnizarea automat a informaiilor cu caracter sintetic i analitic destinate conducerii i
structurilor organizatorice pentru crearea condiiilor informaionale necesare realizrii
obiectivelor de conducere, tehnologice i informatice;
utilizarea eficient a unitilor centrale a calculatoarelor printr-o alocare dinamic a
spaiului de memorie;
realizarea celei mai adecvate si operative metode de introducerea datelor n vederea
minimizrii timpului de ncrcare a coleciilor de date, n vederea obinerii la termenele
stabilite a tuturor situaiilor de ieire n care se concretizeaz obiectivele noului sistem.
Proiectarea rapoartelor/listelor/situaiilor de ieire
Datele de ieire sunt informaii livrate de sistemele de prelucrare autonom a datelor
utilizatorului sub forma unor mesaje, rapoarte, grafice etc.
Ieirile noului sistem informatic sunt stabilite de ctre conducerea unitii economice, n
colaborare cu echipa de realizare a sistemului, ca urmare a analizei obiectivelor sistemului
proiectat, n proiectarea lor inndu-se seama de urmtoarele aspecte:

87

1) Destinaia situaiei i momentul cnd se estimeaz, se poate obine nivelul de

detaliere al informaiei, respectiv informaii mai analitice pentru nivele de baz i mai sintetice la
nivelele superioare.
2) Existena n situaie a tuturor informaiilor necesare, avndu-se n vedere n acelai
timp, ca pe ct posibil, o informaie s nu apar inutil n mai multe situaii.
Structura informaional i formatul ieirii sunt determinate, n principiu, de urmtoarele reguli:
respectarea specificaiilor cadrului legislativ n vigoare
proiectarea se va face n concordan cu activitile specifice obiectivelor sistemului;
coninutul va fi redat sintetic sau analitic i cu o frecven precizat n legislaie;
Formatul de afiare, dispozitivul periferic folosit i beneficiile ieirilor sistemului informatic sunt
stabilite n raport cu solicitrile sistemului de management, sistemului operant, sistemelor
informatice externe.
Criteriile utilizate pentru determinarea formatului, coninutului, dispozitivului periferic i
beneficiarilor ieirilor noului sistem, au impus structurarea acestora n urmtoarele categorii:
A. Rapoartele/listele/situaiile de ieire conin indicatori sintetici i analitici, al cror coninut
reflect starea, dinamica i tendina fenomenelor i proceselor economice ce fac obiectul
procesului de prelucrare a datelor din sistemul proiectat. Reprezentarea datelor se face, de
regul , n format de tabel. Anumite rapoarte au formatul stabilit prin respectivul cadru legal.
B. Indicatorii sintetici redau fenomene i procese economico-financiare prin intermediul unor
date succinte utilizate n special informrii operative i demersului decizional.
C. Graficele redau sub form sinoptic starea i evoluia unui fenomen economico-financiar n
scopul informrii conducerii sau compartimentelor unitii economice, adoptrii unor decizii
operative, prin care s asigure fenomenul de feed back al activitii economico-financiare
analizate.
D. Ieirile ctre alte sisteme sunt de fapt transmisii de date on-line, prin intermediul unei reele
locale de calculatoare, sau off-line, prin intermediul suporturilor magnetice(disc flexibil, disc
magnetic, band magnetic).
A. Rapoarte/liste/situaii de ieire
Rapoartele de ieire reprezint modul de concretizare practic a obiectivelor noului sistem, fiind
caracterizate prin urmtoarele elemente:
a1. tipologia rapoartelor
a2.structura informaional
a3. realizarea rapoartelor
Schematic elementele ce caracterizeaz rapoartele sunt:

88

Tipologia rapoartelor
1) specificul funciei
- R pentru funcia dezvoltare
- R pentru funcia producie
- indicatorii pentru funcia
comercial
- R pentru funcia FinanciarContabil
- R pentru funcia Personal
2) Mod de utilizare
- R de stare
- R statistice
- R previzionale
3) Destinaie
- R. interne
- R. externe
4) Grad de sintetizare date
- R sintetice
- R analitice

Viziuni de realizare
Utilizatori
format tabelar
SGBD
raport
import calcul tabelar Excel, Lotus
Sisteme de operare
specificator de fiier
(x.frm, x.frx)

Structura informaionala
Antet
Titlu
Subiect
Predicat
Toatalizri
Algoritm de calcul
Disciplina informaional

a1 Tipologia rapoartelor
Rapoartele/listele/situaiile de ieire ce urmeaz a se obine n cadrul unui sistem informatic
pot fi clasificate n funcie de o serie de factori obiectivi i subiectivi cum ar fi:
Dup caracterul informaiilor coninute:
- liste cu caracter omogen specifice fiecrei activiti (de exemplu, pentru activitatea
financiar contabil putem ntocmi situaia Balana de verificare)
Unitatea.
Balan de verificare
La data de pag
Rulaje
luna
Sold precedent
Sold final
Simbolul
curent
Denumire
conturilor
D
C
D
C
D
C

TOTAL

***

***

***

***

***

***

ntocmit,
Dup destinaie:
liste/situaii de ieire pentru alte sisteme informatice. Acestea asigur raportrile i
informrile periodice cu privire la stadiul de realizare a indicatorilor tehnico-economici i
au caracter de obligativitate pentru orice unitate economic(dri de seam statistice i
contabile, bilanul contabil, bugetul de venituri i cheltuieli);
89

liste/situaii de ieire destinate sistemului informatic propriu. Prin informaiile furnizate

se asigur urmrirea curent a desfurrii activitilor i conducerea operativ n
vederea lurii deciziilor eficiente.
Dup gradul de sintetizare a datelor:
liste/situaii de ieire cu caracter sintetic: cuprind date i indicatori globali de urmrire i
control a activitii, fiind utilizate la conducerea de ansamblu a activitii(de exemplu,
pentru activitatea financiar contabil putem ntocmi situaia Balana de verificare
sintetic);
Unitatea.
Balan de verificare

Simbolul
conturilor

La data de pag
Sold iniial
Micare
Denumire
D
C
D
C

TOTAL
RULAJ
TOTAL
SOLD

Sold final
D
C

***

***

***

***

***

***

***

***

***

***

***

***

ntocmit,
liste/situaii de ieire cu caracter analitic: cuprind datele i indicatorii la nivel de detaliu
pentru elementele patrimoniale ale unitii, operaiilor economice legate de fondurile
unitii i circulaia acestora(de exemplu: Situaia contului analitic)
Unitatea.
Situaia contului analitic nr..
La data de pag

Sold iniial
Numr

Operaii

Cont corespondent

***

***

***

Nr.
Doc.
***

Debit
***

Credit
***

***

***

Data
***

Total Tranzacii:
***
***
Sold actual:
Dup modul de utilizare:
liste/situaii de ieire cu caracter de stare: conin date ce reflect elementele de
patrimoniu ale unitii, date care evideniaz nivelul i disponibilul de resurse materiale
i bneti la un moment dat(de exemplu balana analitic a valorilor materiale);
90

liste/situaii de ieire cu caracter statistic cuprind date ce reflect mai multe perioade
anterioare de activitate pentru a putea compara tendinele evolutive sau involutive a
fenomenelor economice (de exemplu Drile de seam statistice);
liste/situaii de ieire cu caracter previzional grupeaz date pe perioada n curs i
reflect siuaia fenomenelor i proceselor economice la nivelul unitii. n funcie de
aceast situaie se vor stabili obiectivele de dezvoltare .
Dup intervalul de referin:
liste/situaii de ieire cu caracter operativ: sunt elaborate la frecvene mici de
prelucrare(schimb, zi, decad) i conin date operative cu un grad redus de prelucrare,
necesare conducerii prin excepie, deoarece prin coninutul lor semnaleaz aspectele
pozitive sau negative de desfurare a activitii(rapoarte de control al realizrii
sarcinilor)
Unitatea
Cod situaie
Serviciul

Fi de urmrire operativ
a aprovizionrii n luna.
Materialul
Cod.
Caracteristici.
Pre unitar..
Stoc normat
Stoc de siguran.

Data

SITUAIA SINTETIC
Necesar
de aprov.

Contracte

Alte surse

Total
acoperit

Valoare.

91

Modificri

Obs.

liste/situaii de ieire cu caracter operativ: sunt elaborate la frecvene mai mari de timp
deoarece conin date sintetice ce caracterizeaz evoluia de ansamblu a proceselor i a
fenomenelor economice. Acestea se caracterizeaz prin termene fixe de elaborare i
sunt destinate anumitori factori de decizie, compartimente funcionale sau altor sisteme
informaionale (de exemplu: registru jurnal)
Unitatea.
Nr.
crt.

Data
nreg.

Registrul - Jurnal

Document

Explicaii

Report

Conturi

Sume

***

***

De reportat:
TOTAL GENERAL
ntocmit,

***

***

Verificat,

Dup modul de obinere:

liste / situaii de ieire obinute la imprimant: se folosesc ca documente justificative i
se ndosariaz i arhiveaz dup consultarea datelor coninute;
SITUAIA ANALITIC

Data

Cant

Contracte
Data

Term Modificri
livrare
Cant

Cant

Doc

Obs

Furnizori

Comenzi

Cant

Doc

liste / situaii de ieire obinute la videoterminal: se folosesc cnd nu este necesar

arhivarea documentelor, dar se folosesc pentru informrile operative din sistemul
informaional al unitii(graficul de urmrire zilnic al materialelor aprovizionate).
liste / situaii de ieire obinute pe suport magnetic: sunt utilizate pentru pstrarea
temporar, cu posibilitatea imprimrii, multiplicrii sau vizualizrii;
liste / situaii de ieire obinute la teletransmisie prin cuplarea a dou reele de
calculatoare n vederea listrii, imprimrii, vizualizrii la o alt unitate economic.

92

Forma listelor / situaiilor de ieire va trebui s fie simpl, concis i clar, fr amnunte
nesemnificative care ar ngreuna utilizarea lor.
n definitivarea coninutului i formei situaiei de ieire trebuie urmrit i valorificarea ct mai
deplin a posibilitilor oferite de sistemul electronic de calcul prin asocierea introducerii
sistemului informatic cu utilizarea conducerii prin excepie i eventual cu utilizarea unor decizii
programate.
a2 Structura informaional
Indiferent de tipologia raportului, acesta trebuie s redea datele i informaiile sub o form
inteligibil, concis i sugestiv, ceea ce impune omiterea detaliilor nesemnificative ce nu
corespund scopului propus.
Structura informaional conine urmtoarele elemente:
Antetul raportului este redat sub numele unitii economice pentru care se elaboreaz
raportul, nsoit de codul raportului;
Titlul raportului indic n mod sintetic coninutul su informaional, precum i data sau
perioada calendaristic la care se refer informaiile din raport;
Subiectul raportului prezint efectiv coninutul informaional i este format din:
numr pagini de raport;
secven de atribute, ordonate de la stnga la dreapta, prin intermediul unor coloane.
Predicatul raportului este format din mulimea finit a rndurilor de detaliu completate cu valori
reale pentru atributele specificate n rndul curent, completare realizat prin intermediul unor
proceduri automatizate;
Totalizarea nseamn realizarea unor grade de total general i, uneori, de subtotaluri pentru
1,2n atribute, numai n situaia cnd exist o relaie de subordonare ierarhic a atributelor;
Algoritmii de calcul reiau n mod implicit sau explicit relaiile sau funciile financiare, statistice sau
de sistem pentru calculul unor indicatori cu caracter financiar contabil.

Realizarea rapoartelor
La definitivarea fiecrei situaii de ieire trebuie s se precizeze modul practic de utilizare a
viitoarei situaii, prin urmtoarele elemente:
funcia pentru care este dedicat modelul raportului (de exemplu funcia financiarcontabil);
activitatea: este reprezentat de o parte component a unei funcii, materializat prin
raportul respectiv (de exemplu activitatea contabilitate general);
compartimente beneficiare: sunt structurile organizatorice care vor primi respectivul
93

raport (de exemplu Contabilitatea);

numrul de exemplare este stabilit n funcie de numrul compartimentelor beneficiare;
frecvena este reprezentat de ritmicitatea elaborrii respectivului raport;
termenul reprezint data limit la care trebuie obinut respectivul raport, fiind stabilit n
funcie de frecvena prestabilit;
dispozitivul periferic de ieire :este reprezentat simbolic perifericul respectiv.
Mai jos exemplificm structura i disciplina informaional a unui raport.

Structura informaional
Unitatea
Balana de verificare la data de . (titlu)
Cont
Sold iniial
Micare
D
C
D
C
***
***
***
***
***
Total
Rulaj /c.s
***
***
Grad 1
Total
***
***
sold/c.s
Grad 1
***

Cod..(antet)
Sold final
D
C
***
***

Disciplina informaional
Funcie
Activitate
Compartimentele beneficiare
Numrul de exemplare
Frecventa
Termen
Dispozitiv periferic de ieire

: Fin-contabil
: contab generala
: contabilitati, gestiuni
:2
: lunar
:15
: fiier, imprimanta

B. Indicatorii sintetici specifici unitii economice au rolul de a caracteriza din punct de vedere
sintetic i analitic activitatea economico-financiar prin intermediul unor informaii care redau:
patrimoniul net al regiei autonome sau a societii comerciale prin intermediul
inventarierii patrimoniului i a posturilor din bilanul contabil elaborate la finele perioadei
de gestiune;
starea i rezultatele economico-financiare ale unitii economice pe o perioad
determinat de gestiune;
calculul i planificarea financiar a investiiilor;
94

 calculul i planificarea rezultatelor economico-financiare;

calculul i previzionarea activelor circulante i surselor de finanare;
calculul i previzionarea activitii de trezorerie.
Indicatorii sintetici sunt caracterizai de urmtoarele elemente:
b1 tipologia indicatorilor sintetici
b2 structura informaional
b3 realizarea indicatorilor sintetici
Schematic elementele ce caracterizeaz indicatorii sintetici sunt:
Tipologie
1) specificul functiei
- indicatorii pentru functia
dezvoltare
- indicatorii pentru functia
producie
- indicatorii pentru functia
comerciala
- indicatorii pentru functia
Financiar-Contabila
- indicatorii pentru functia
personal
2) Mod de utilizare
- indicatori cu date de stare
- indicatori cu date statistice
- indicatori cu date
previzionale
3) Tipul evidentei
- indicatori cu date de sinteza
- indicatori din evidenta
operativ contabila
- indicatori cu date din ev.
statistica
- ordonarea datelor

Structura
informationala
Antet
Titlu
Zone fixe
Zone variabile

Viziuni de realizare
Utilizatori
format eticheta
SGBD
report
import calcul tabelar excel,
lotus
Sisteme de operare
- specificator de fisier
(x.lbl)

Zone aditionale

b1 Tipologia indicatorilor sintetici

Selectarea tipurilor de indicatori sintetici obinui n cadrul unui sistem informatic se face n
funcie de :
1) Specificul funciei:
indicatorii pentru funcia dezvoltare
indicatorii pentru funcia producie
indicatorii pentru funcia comercial
indicatorii pentru funcia Financiar - Contabil
indicatorii pentru funcia personal
2) Mod de utilizare:
indicatori cu date de stare
95

 indicatori cu date statistice

indicatori cu date previzionale
3) Tipul evidenei
indicatori cu date de sinteza
indicatori din evidena operativ contabil
indicatori cu date din evidena statistic
b2 Structura informaional
Indiferent de tipologia raportului, acesta trebuie s redea datele i informaiile sub o form
concis i sugestiv.
Structura informaional conine urmtoarele elemente:
Antetul indicatorului sintetic este redat sub numele unitii economice pentru care se
elaboreaz indicatorul, nsoit de codul indicatorului;
Titlul indicatorului sintetic n mod sintetic coninutul su informaional, precum i data
sau perioada calendaristic la care se refer informaiile coninute de indicator;
Zona fix prezint efectiv coninutul informaional i este format din: secven de
atribute, ordonate de la stnga la dreapta, prin intermediul unor coloane.
Zona variabil este format din mulimea finit a rndurilor de detaliu completate cu
valori reale pentru atributele specificate n rndul curent, completare realizat prin
intermediul unor proceduri automatizate;
Zona adiional red informaii despre data i persoana care a elaborat respectivul
indicator.

UNIT COD INDICATOR.

SERVICIU..

EXTRASUL DE CONT CU RULAJE

La data de..
NUMAR EXTRAS CONT
CONT TITULAR
DENUMIRE TITULAR
RULAJE DEBITOARE
RULAJE CREDITOARE
SOLDURI FINALE CREDITOARE
SOLDURI FINALE DEBITOARE

..................................................................
..................................................................
..................................................................
..................................................................
..................................................................
..................................................................
..................................................................
............VARIABILE

ZONE FIXE

DATA AFIRII.ECONOMIST
ZONE ADIIONALE
96

b3 Realizarea indicatorilor sintetici trebuie s respecte aceleai reguli ca rapoartele.

C. Grafice
Graficele se folosesc pentru prezentarea unor sinteze, unor analize comparative. Graficele cele
mai utilizate sunt :Coloan ; Bar ; Linie ; Mixt ; Cilindric ; Inel
Grafice de tip histograme sau coloane 3D se utilizeaz n analiza comparativ ntre diverse
categorii, prin coloane, pentru a compara mai multe serii de date care descriu evoluia unui
fenomen n timp, dac datele se rfer la perioade temporale succesive mari (luni, trimestre, ani).
Un exemplu de utilizare ar fi reprezentarea vnzrilor trimestriale realizate de fiecare agent de
vnzri. Figura 4.2

Fig. 4.2
Grafice de tip bar se utilizeaz n analiza compaativ intre diferite categorii, prin bare, pentru
a compara mai multe seturi de date, dispuse orizontal. De exemplu, reprezentarea vnzrilor
lunare. Figura 4.3

Fig. 4.3
Grafice de tip linie linii - frnte, care marcheaz fiecare valoare din tabel asu fiier. Se
utilizeaz n specialn analiza de tip trend, pentru a reprezenta modificrile unei anumite serii de
date. Exemplu de utilizare: modificarea stocului unui produs pe zile ale unei luni. Figura 4.4
97

Fig. 4.4
Grafice de tip mixt se obin prin combinarea a dou tipuri de grafice, de exemplu, coloan i
linie. Se obine i o sumarizare a valorilor care sunt comparate. De exemplu nivelul profitului
firmei lunar, cu reprezentarea creterii firmei. Figura 4.5

Fig. 4.5
Graficul de tip pie (disc, plcint) este utilizat n aplicaiile economice pentru a compara pri
sau procente dintr-un ntreg. Se pot prezenta vnzrile unui produs pe diferite puncte de
desfacere sau cota parte de vnzare a fiecrui agent din totalul vnzrilor. Figura 4.6

Fig. 4.6
Grafice de tip scatter sunt folosite n cazul cnd se dorete compararea perechii de valori (x,
y). Se utilizeaz pentru reprezentarea datelor, folosind dou axe, n principal pentru vizualizarea
abaterii standard. Exemplu: reprezentarea pe axa OX a vnzrilor realizate iar pe OY a
salariului unui aqgent de vnzri. Figura 4.7
98

Fig. 4.7
Grafice de tip Gantt se utilizeaz pentru vizualizarea datelor dintr-un proiect, de-a lungul unei
perioade de timp. Fiecare activitate este reprezentat de o linie proporional cu durata ei.
Odat ce au fost listate toate activitile i reprezentate duratele lor prin linii proporionale se
poate vedea durata total a proiectului sau a unei faze a acestuia.
Grafice de tip tabel este utilizat pentru reprezentarea datelor n format tabelar. De exemplu:
structura organizatoric a unui agent economic.
Grafice de tip Double-Y- se folosesc dou axe OY independente, pe fiecare reprezentndu-se
intervale de valori diferite. De exemplu se pot vizualiza cheltuielile (pe o ax OY) i ncasrile
(pe cealalt ax OY), de-a lungul unei perioade de timp (axa OX).
D. Ieiri ctre alte sisteme
Sistemul informaional propriu unitii economice se afl n interconexiune cu sistemele
informaionale ale altor uniti economice sau organisme guvernamentale. Aceast
caracteristic impune i necesitatea corelrii sistemului informatic propriu unitii economice
beneficiare cu alte sisteme informatice conexe. n acest sens, ieirile sistemului informatic al
unitii beneficiare pot constitui intrri n alte sisteme informatice, n timp ce ieirile altor sisteme
informatice pot fi intrri n sistemul informatic propriu unitii economice. Aceste intercondiionri
se pot realiza prin intermediul reelelor de calculatoare ce vor asigura conexiunea dintre bazele
informaionale specifice, crora le vor corespunde bazele de date asociate, ntre care se
realizeaz efectiv schimbul de date.
Proiectarea bazei informaionale
Baza informaional conine nucleul informaional format din totalitatea atributelor
necesare prelucrrilor specifice sistemului informatic i structura informaional reprezentat de
entiti ntre care se stabilesc corespondene i legturi.
99

Proiectarea bazei informaionale presupune:

A. Determinarea coninutului bazei informaionale i a algoritmilor utilizai;
B. Determinarea structurii bazei informaionale.
C. Normalizarea relaiilor
A. Determinarea coninutului bazei informaionale i a algoritmilor utilizai
Coninutul bazei informaionale se determin n funcie de variantele de abordare a
proiectrii generale alese.
n varianta ieiri-intrri coninutul bazei informaionale se determin n funcie de obiectivele
propuse concretizate n situaiile de ieire. Baza informaional se va constitui pe baza ieirilor
solicitate i va fi modificat pe tot parcursul exploatrii sistemului n concordan cu dinamica
fenomenelor i proceselor din unitatea beneficiar.
Aceast variant se aplic n cazul realizrii sistemelor informatice mari i mijlocii
caracterizate printr-o complexitate ridicat a ieirilor informaionale i implicit a obiectivelor avute
n vedere.
n varianta intrri-ieiri coninutul bazei informaionale presupune cunoaterea datelor
de intrare i dinamismul ieirilor solicitate. Se aplic n cazul realizrii sistemelor informatice de
dimensiuni mici.
Sistemele informatice din domeniul economic presupun realizarea unor obiective
delimitate i fundamentate n strns legtur cu cadrul legislativ-normativ care impune natura
ieirilor informaionale, motiv pentru care n majoritatea cazurilor determinarea coninutului i
structurii bazei informaionale se face pe varianta ieiri-intrri.
Determinarea coninutului bazei informaionale prin varianta ieiri-intrri presupune
studierea mulimii atributelor din situaiile de ieire n funcie de modul de obinere n urma
prelucrrii automate.
Atributul este o proprietate a unei entiti, a unui grup de entiti sau a unei
corespondene dintre acestea. Prin intermediul atributelor, entitatea poate fi descris din punct
de vedere informaional - ca o component distinct a structurrii bazei informaionale de
intrare. n aceast viziune, atributul poate fi considerat ca o variabil, creia i se poate asocia o
mulime de valori prin intermediul unui indicator comun.
Atributele sunt reflectate printr-un coninut concret denumit valoare, care red nivelul real al
fenomenelor i proceselor economice cuantificate prin intermediul entitii.
Atributele bazei informaionale de intrare pot fi privite din punct de vedere structural i al
stabilitii n timp.
100

a)
Din punct de vedere structural atributele pot fi elementare i compuse.
Atributele elementare sunt componente informaionale deductibile ce nu mai pot fi descompuse
n alte atribute (de exemplu.: cod-mat, den-mat, pre, stoc-init).
Atributele compuse sunt componente informaionale reductibile ce pot fi descompuse n atribute
elementare (de exemplu: atributul data-stoc poate fi descompus n atributele elementare zi-stoc,
luna-stoc, an-stoc).
b)
Din punct de vedere al stabilitii n timp atributele pot fi constante, variabile i
de stare.
Atributele constante i menin valoarea neschimbat o perioad determinat fiind
invariabile n timp, n raport de semantica atributului din baza informaional de intrare (de
exemplu: cod-furn, nr-contr, cod-prod, cod-um,preul etc).
Atributele variabile i schimb valoarea pe parcursul existenei bazei informaionale de
intrare fiind variabile n timp n funcie de semantica atributului (de exemplu.: nr-doc, data-doc
etc,).
Atributele de stare i schimb valoarea numai la anumite intervale de timp, ale
existenei bazei informaionale de intrare prin modificarea atributelor constante, variabile sau
chiar de stare (de exemplu stoc-init, stoc - final, sold - db, sold - cr etc). ).
Pentru proiectarea corect a coninutului bazei informaionale este necesar ndeplinirea
concomitent a urmtoarelor condiii:
mulimea atributelor de ieire este format din submulimea atributelor preluate reunit
cu submulimea atributelor calculate;
submulimea operanzilor primari intersectat cu submulimea atributelor preluate
corespunde atributelor comune ce se gsesc n ambele submulimi;
submulimea atributelor de intrare este reprezentat corect de nucleul informaional ce
constituie coninutul bazei informaionale.
B. Determinarea structurii bazei informaionale
Structura bazei informaionale de intrare reprezint gruparea coninutului acestuia
(atributele de intrare ntr-un ansamblu de entiti inclusiv corespondenele (legturile) dintre
acestea).
Structura bazei informaionale de intrare este efectuat prin intermediul unui model de
reprezentare care asigur independena logic i fizic a prelucrrilor fa de coleciile de date
n care va fi transpus baza informaional. Aceast proprietate asigur implicit independena
relativ a proiectrii generale fa de soluiile tehnice adoptat n cadrul proiectrii de detaliu.
n mod concret, gruparea atributelor de intrare n entiti informaionale i reflectarea
corespondenelor (legturilor) dintre acestea se realizeaz gradat printr-un proces de modelare
ce permite definirea riguroas a structurii bazei informaionale.
101

Acest proces de modelare are la baz modelul de reprezentare entitate atribut

coresponden. Acest model consider baza informaional de intrare ca un ansamblu finit de
entiti informaionale, caracterizate n mod unic, printr-o mulime specific de atribute i un
ansamblu de corespondene (legturi) stabilite ntre entiti sau chiar n interiorul acestora. n
acest context corespondenele pot fi definite ca asocieri ntre realizrile aceleiai entiti sau
realizrile entitilor diferite
Modelul conceptual al datelor redat sub forma diagramei entitate-asociere, este
rafinat nainte de a fi trecut ntr-un format logic (de regul, un model relaional al datelor) din
care se definesc bazele de date i are loc proiectarea fizic a acestora Definirea entitilor,
atributelor, legturilor dintre coleciile de date au drept scop depistarea i nlturarea
disfuncionalitilor ce ar putea afecta performanele bazei informaionale.
C. Normalizarea relaiilor
Procesul de normalizare a relaiilor este util n activitatea de proiectare a structurii
logice i a bazei de date relaionale i const n eliminarea neajunsurilor ce apar n exploatarea
efectiv a bazei de date, neajunsuri introduse de dependente incorecte, existente ntre datele
relaionale.
Din punctul de vedere al influenei asupra performanelor n exploatare a bazei de date,
normalizarea afecteaz negativ eficiena cu care snt rezolvate interogrile. Aceasta pentru c
informaiile care ntr-o baz de date nenormalizat ar putea fi regsite ntr-o singur relaie, n
cazul unei baze normalizate necesit, de cele mai multe ori, cuplarea a dou sau mai multe
relaii. De aceea normalizarea este considerat necesar i util doar n ipoteza c operaiile de
adugare, tergere i actualizare snt frecvent utilizate.
Aadar normalizarea mbuntete integritatea datelor prin reducerea redundanei i a
inconsistenei n detrimentul eficienei unor operaii de regsire a datelor.
E. F. Codd a artat ca ntr-o anumit form relaiile posed proprieti nedorite pe care le-a
numit anomalii de actualizare i le-a structurat astfel:
anomalii de tergere se refer la faptul c tergnd un tuplu dintr-o tabel, pe lng
datele ce trebuie eliminate se terg i cele necesare.
anomalii de adugare constau n faptul c anumite date noi care trebuie introduse ntr-o
tabel fac parte din tupluri incomplete, motiv pentru care nu pot fi introduse.
anomalii de modificare semnific faptul ca e dificil de schimbat o valoare a unui atribut
cnd ea apare n mai multe tupluri ale relaiei.
Pentru a elimina aceste anomalii Codd a stabilit trei forme normale pentru relaii i a
introdus noiuni de normalizare care se bazeaz pe dependena funcional ntre atributele unei

102

relaii. Ulterior, ali cercettori au mai completat formele normale cu nc dou forme normale
plus una suplimentar.
Primele patru nivele snt definite n termenii dependenelor funcionale, i sunt: prima, a
doua, a treia form normal i forma normal Boyce-Codd (notate FN1, FN2, FN3 i FNBC). A
patra form normal (FN4) i a cincea form (FN5) normal snt definite n termenii
dependenelor multivalorice. Diferitele nivele de normalizare impun condiii din ce n ce mai
restrictive asupra relaiilor. Astfel o relaie aflat pe un anumit nivel de normalizare satisface
toate restriciile cerute de nivele inferioare de normalizare. Deci o relaie n FN4, este i n FN3,
FN2 .a.m.d.
nenormalizate
1 NF
2 NF

3 NF

BCNF

4 NF

5 NF

BCNF Boice code normal form

Formalizarea atributelor
Activitatea de formalizare a atributelor presupune studierea documentelor de intrare i
adaptarea lor la cerinele sistemului informatic, iar multitudinea de atribute sunt codificate.
A. Adaptarea documentelor de intrare la cerinele sistemului informatic
Documentele de intrare reflect starea i dinamica fenomenelor i proceselor economice
desfurate n unitatea respectiv. Ele reprezint principala surs de date pentru crearea i
actualizarea coleciilor de date.
Dac aceste documente nu corespund integral din punct de vedere al coninutului i al formei cu
structura bazei informaionale i cu restriciile impuse de sistemul informatic proiectat, vor suferi
modificri de coninut i de form.
Modificrile de coninut constau n :
adugarea rubricilor de coduri acolo unde nu sunt prevzute, insistndu-se pe codurile
ce specific natura operaiilor reflectate i a celor care servesc pentru identificarea i
asocierea coleciilor de date(exemplu: cod_material, cod_produs, nr._marc);
modificarea i regruparea rubricilor aferente atributelor ce vor conine date care s se
introduc n acelai loc n toate documentele. n acest mod se formeaz o zon
103

comun tuturor documentelor, pstrndu-se ns individualitatea fiecrui document.

Modificrile de form ale documentelor de intrare sunt impuse de necesitatea creterii facilitilor
de preluare direct a datelor prin intermediul videoterminalului i vizeaz urmtoarele aspecte:
toate atributele care se introduc de la terminal se vor grupa astfel nct s fie nlturat
dispersarea lor pe toat suprafaa terminalului;
atributele se vor ordona asigurndu-se nti prezena atributelor de identificare, apoi a
celor informative i terminnd cu cele cantitativ-valorice;
atributele ce se preiau din coleciile de date nu se vor intercala cu atributele care au un
caracter constant sau rezult din calcule(de exemplu, din documentul de intrare bon de
consum nu se vor prelua atributele constante: pre unitar, unitate de msur, inclusiv
atributele rezultate din calcule, dei ele sunt consemnate n documentele pentru
efectuarea controlului n gestiune).
Pe lng aceste modificri se vor stabili i regulile de completare i utilizare a documentelor de
intrare, se stabilesc numrul de exemplare, circuitul fiecrui exemplar, frecvena i termenul de
introducere a datelor n coleciile de date.
De asemenea, se precizeaz responsabiltile pentru completare i verificare, semnturile care
valideaz coninutul documentelor de intrare, inclusiv persoanele mputernicite n acest sens.
Aceste specificaii sunt folosite pentru proiectarea sistemului informatic i sunt trecute n
documentaia finalizat n etapa de implementare.
B. Codificarea atributelor
Activitatea de codificare trebuie s realizeze corelaia ntre specificul activitii unitii beneficiare
i particularitile sistemului informatic proiectat.
Necesitatea de codificare este impus de cerinele de grupare si ierarhizare a atributelor care
oferea multiple soluii (posibiliti de prelucrare a datelor) regsite in coleciile de date care
constituie baza informaional.
Codificarea atributelor const n atribuirea, manual sau automat, ntr-o form sistematizat,
de coduri fiecrui element din sistemul informatic proiectat.
Prin codificarea atributelor se asigur urmtoarele avantaje:
folosirea intensiv a memoriei externe prin nlocuirea atributelor cu coduri numerice,
alfabetice sau alfanumerice;
realizarea unei ierarhizri a atributelor n funcie de criteriile specifice prelucrrii prin
care se poate obine o ordonare a acestora n raport cu cerinele de selectare a
atributelor din baza informaional sau de obinere a gradelor de total sau subtotal
pentru situaiile de ieire;
reducerea erorilor prin folosirea codului care simplific scrierea n comparaie cu
folosirea denumirilor explicite ale atributelor.
104

utilizarea intensiva a suporturilor direct admisibile a memoriei interne, ceea ce permite

optimizarea accesului de diverse valori a atributelor concomitent cu minimizarea
timpului de prelucrare a viitoarelor colecii de date.
confidenialitatea datelor, precum si integritatea acestora, ceea ce ofer bazei de
date(B.D) o securitate si o protecie in timpul prelucrrii
Pentru ca un sistem de codificare s fie eficient n procesul de prelucrare a datelor, se
urmresc urmtoarele:

1) Cerinele si funciile codificrii.

2) Tipurile de coduri utilizate intr-un sistem informatic
3) Realizarea codificrii propriu-zise
1) Cerinele si funciile codificrii
Cerintele codificrii sunt redate de proprietile eseniale ale unui cod pentru ca acesta s
asigure un sistem de codificare eficient i viabil. Schematic codificarea atributelor se realizeaz
conform fig. 4.7
Cele mai importante proprieti sunt:
unicitatea codului, presupune existenta unui singur simbol pentru un atribut al bazei
informationale si pentru atribuirea unei valori unice a fiecarui atribut,proprietate care
trebuie asigurata la nivelul intregului sistem informatic
stabilitate si suplete in timp, exprima necesitatea utilizarii unui tip de cod pe toata
perioada de utilizarii bazei de date (B.D) inclusiv posibilitatea extinderii expresiilor
valorice in functie de dinamica valorilor bazei informationale.
comoditatea utilizrii codului-se refera la facilitatea operaiilor de codificare i de
detectare a erorilor, precum i corectare a acestora.
Atribuirea codurilor trebuie s fie uor de neles i aplicat astfel nct personalul unitii
beneficiare sa asimileze intr-un timp foarte scurt noul sistem de coduri

concizia codului se refera la necesitatea unui numr redus de caractere pentru

reprezentarea elementelor codificate, astfel nct s se asigure o vitez mare de
prelucrare i o reducere a procentelor de erori n procedurile manuale de introducere a
datelor.

105

Codificarea ATRIBUTELOR

Cerinele
codificarii

- unicitatea codului
- stabilirea i supletea
n timp
- controlabilitatea
codului
- comoditatea
- concizia
- extensibilitatea

Fig. 4.7

Tipologia
codurilor

Functiile
codurilor

- descriptiva

totala i partiala
- identificare i
accesare
- control
- operativitatea
prelucrarilor

- naturale
a) numerice
b) alfabetice
c) alfanumerice
structura
complexa
a) ierarhizate
b) juxapuse
- modul atribuirii
a) manual
b) automat

Realizarea
codificarii

-determinarea
atributelor
codificabile
- pregatirea
codificarii
- realizarea
nomenclatoarel
or de codului
- ntreinerea
nomenclatoarel
or de coduri

Pentru realizarea acestor cerine codificarea atributelor const n atribuirea manual sau
automat, ntr-o form sistematizat a unor coduri fiecrui atribut din baza informaional.
Funciile codificrii
Trebuie s permit caracterizarea direct a fiecrui atribut ce va fi supus codificrii,
identificarea formal a acestora, controlul valorilor posibile atribuite, posibilitatea de manipulare
a atributelor codificate.
Funcia de caracterizare, exprim intr-o form concis, unic i stabila n timp coninutul
semantic al fiecrui atribut, prin intermediul codurilor asociate(exemplu: n loc de Facultatea de
Management Financiar Contabil se poate utiliza codul FMFC).
Funcia de identificare, ofer posibilitatea regsirii mai rapide a atributelor, dect prin folosirea
complex a semanticii atributului. Aceasta funcie creaz posibilitatea ulterioara de selectare a
anumitor atribute prin intermediul crora se vor identifica in mod unic atributele solicitate prin
intermediul cheilor primare si externe.
Funcia de control asigur existena unui caracter care ataeaz n ultim poziie din dreapta
structurii codului pe baza cruia prin metode matematice (aritmetica si geometrica) au algoritmi
specifici ,se poate verifica integral corectitudinea simbolurilor care intr n componenta codurilor.

106

Funcia de manipulare a atributelor codificate, faciliteaz introducerea eficient a codurilor in

memorie, reduce timpul de prelucrare a acestora, faciliteaz uurina folosirii atributelor de ctre
toate compartimentele funcionale implicate in realizarea sistemului informatic respectiv.
2) Tipologia codurilor
Diversitatea i complexitatea coninutului bazei informaionale de intrare, precum i
multitudinea proceselor de prelucrare a atributelor componente, au condus la apariia unei game
variate de coduri, grupate n mai multe categorii, n funcie de urmtoarele criterii de clasificare:
a) Natura caracterelor;
b) Controlul erorilor;
c) Structura simbolului;
d) Lungime;
e) Modul de elaborare(atribuire).
a) Natura caracterelor ce intr n componena codului determin urmtoarele coduri:
1.numerice: formate numai din cifre;
2.alfabetice: formate numai din litere:
3.alfanumerice: formate din cifre, litere i eventual caractere speciale.
Coduri dup natura caracterelor
Tip

Valoarea

Semnificaie

Numeric
Alfabetic
Alfanumeric

1301
FCF
FCF01

Grupa 1 din anul 3

Facul. de Management Financiar Contabil
FCF anul 1

b) Controlul erorilor se realizeaz prin intermediul unui caracter de control, cifr sau liter,
situat la dreapta structurii codului. Acest caracter de control face parte din structura codului i va
avea aceeai valoare atta timp ct valorile atributelor componente nu se modific.
De asemenea, caracterul de control asigur fie detectarea automat a erorilor introduse
(coduri autodetectoare de erori), fie i corectarea automat a acestora (coduri autocorectoare de
erori).
Codurile autodetectoare de erori se bazeaz pe existena caracterului de control care
asigur detectarea automat a erorilor introduse prin compararea caracterului de control care
nsoete codul respectiv cu caracterul de control determinat de calculator atunci cnd
respectivul cod este utilizat.
Pentru calculul caracterului de control se folosesc mai multe metode, dintre care cele mai
cunoscute sunt:
107

 metoda aritmetic;
metoda geometric;
metoda literei de control.
Metoda aritmetic const n stabilirea caracterului de control (C ) prin intermediul unei cifre
obinut pe baza sumei produselor rezultate din nmulirea fiecrei cifre a codului (Ci) cu anumite
ponderi convenional alese, denumite ponderi (Pi ) ale codului, ce urmeaz a fi sczut din cifra
zecilor imediat superioar (Z).
Pentru aplicarea acestei metode se parcurg paii:
1. asocierea ponderii Pi astfel:

2,
daca
inr
.par

1,
daca
inr
.impar

Pi

2. calculele produselor CiPi poate duce la dou situaii distincte:

- dac CiPi 10, atunci acest produs este dat de o singur cifr pe care o notm prin
Co;
- dac CiPi 10, atunci acest produs este format din dou cifre C1C0 i se va reda prin
suma lor C1 +C0.
De exemplu , dac C7 i P2 atunci CP14 i se va scrie 1+45.
3. se calculeaz suma produselor dintre cifrele codului i ponderile asociate CiPi

4. Se determin cifra de control(k ):

kZ ni0 Ci Pi - ni0 Ci Pi
De exemplu caracterul de control pentru codul 923764 se va calcula astfel:
9

Ci

Pi

CiPi

CiPi 34 Z40
k40-346 noul cod 9237646.
108

Metoda aritmetic are avantajul simplitii i acurateei, dar prezint dezavantajul imposibilitii
detectrii erorilor de compensare.
Metoda geometric const n stabilirea caracterului de control (C) prin intermediul unei cifre
sau litere obinut ca rest al mpririi sumei produselor fiecrei cifre a codului, cu puterile
cresctoare ale lui 2, la un numr sau cu numere naturale n ordine cresctoare, par sau impar
ales convenional(x).
Metoda geometric se realizeaz n urmtorii pai:
1) asocierea ponderilor Pi 2i, i0,1,2n
2) calculul produselor CiPi
3)se calculeaz suma CiPi
4) se determin cifra de control (k).
kCiPi /x, unde x CiPi i are aceeai lungime cu CiPi.
Practic, cifra de control se determin astfel:
CiPi / XQ +R, unde Q este partea ntreag a mpririi iar R este restul mpririi, R
fiind de fapt cifra de control.
Rk
De exemplu caracterul de control pentru codul 923764 se va calcula astfel:
9

Ci

Pi

288

32

24

28

12

CiPi

Ci Pi = 388 x = 386

Ci Pi / x = 388/386 = 1+2 k=2

5
i 0
5
i 0

Noul cod va fi : 9237642.

Metoda literei de control este asemntoarea metodei geometrice, dar limiteaz posibilitatea
apariiei erorilor de compensaie i evit mrirea lungimii codului prin faptul c numrul par ales
este 26 (cel mai mare numr natural asociat literelor alfabetului englez), iar caracterul de control
este o liter ce se obine prin transformarea restului obinut din aplicarea algoritmului metodei
geometrice n litera din alfabetul englez care are numr natural corespunztor valorii restului.

109

De exemplu, pentru codul 923764, litera de control va fi:

9

Ci

Pi

45

14

CiPi

Ci Pi = 82

Ci Pi /26=82/26=3+4 x = d

5
i 0

5
i 0

Noul cod va fi: 923764d.

Indiferent de metodele aplicate pentru stabilirea caracterului de control , principiul de
verificarea rmne acelai. La fiecare citire a codului aplic algoritmul de calcul al caracterului
de control i compar rezultatul obinut cu caracterul de control introdus odat cu codul.
Dac caracterul de control este diferit , se invalideaz atributul respectiv. Posibilitatea
apariiei erorilor este generat de inversarea sau nsumarea greit a cifrelor codului, scrierea
eronat a codului n documentele de intrare sau de introducere eronat de la terminal.
Codurile autocorectoare de erori asigur att detectarea erorilor i poziia acestora ct i
nlturarea acestora. Pentru determinarea cifrei de control, codurilesunt aranjate ntr-o form
matriceal, unde fiecare linie i coloan are cte un caracter de control obinut prin nsumarea
cifrelor de linie sau coloan i scznd rezultatul din ordinul zecilor imediat superior. Abaterea
dintre caracterul de control al liniilor n raport de cel determinat pe coloanele acesteia, constituie
valoarea absolut a erorii.
Practic, pentru obinerea cifrei de control, se parcurg paii:
se aranjeaz codul ntr-o matrice astfel nct:
cifra Co s ocupe elementul Cmn din matrice (colul din dreapta jos al matricei);
eventualele poziii neocupate se completeaz cu cifra 0.
2) se calculeaz suma elementelor, deci a cifrelor codului:

pe linie

pe coloan

j 1

Cij ;

i 1

Cij

3) se determin cifrele de control:

pe linie Ci= Zm

m
j 1

Cij -

m
j 1

Cij ;
110

pe coloan: Cj = Zn

C
i 1 ij -

i 1

Cij

4) se calculeaz cifra de control (k):

pe linie k linie Zn

pe coloan: k coloan = Z

i 1

Cij -

Cij

Cij -

i 1

i 1

i 1

Cij

Dac dup aceste calcule k linie= k coloan atunci k linie devine cifr de control.
Structura codurilor
Elementar
Coduri secveniale
Coduri pe grupe
Coduri cu semnificaie
Coduri numerice
Coduri cu semnificaie descriptiv

Complex
Coduri ierarhizate:
liniar simplu
zecimal
Coduri juxtapuse
Coduri combinate

Coduri secveniale se formeaz prin atribuirea unui ir de caractere fiecrui element al

mulimii stabilind o coresponden (in ordine cresctoare) ntre elementele acestora i mulimea
numerelor naturale. Fiecrui element supus codificrii i se asociaz un cod cresctor, imediat
disponibil. De exemplu: unei persoane angajate i se atribuie marca 123, este precedat de
marca 122 i succedat de marca 124.
Coduri secveniale pe grupe se formeaz prin rezervarea unui set maxim de simboluri
pentru fiecare tip de atribut omogen caracterizat prin particulariti comune ce formeaz o grup
specifica supusa codificrii.Grupele atribuite sunt dependente de specificul economic al
atributelor si de exigentele prelucrrii ale acestora. Exemplu: Fie studenii Facultii de
Management Financiar Contabil. Fiecare student are un numr matricol:1457 Ionescu Dan,
1458 Popescu Ion, 1497 Vasile Lazr,. Studenii sunt grupai pe grupe i ani de studii.
1457 Ionescu Dan
1458 Popescu Ion

Grupa 1404
Anul IV

1497 Vasile Lazr

Grupa 1404

111

Codul de semnificaie mnemonic se formeaz prin utilizarea unor simboluri recunoscute de

standardele n vigoare sau prin atribuirea unor consoane rezultate din abrevierea elementului
respectiv (de exemplu OL pentru oel laminat).
Codul de semnificaie descriptiv se formeaz prin combinarea iniialelor desemnate pentru
denumirea elementului respectiv cu particularitile tehnico-constructive ale acestuia. Acest tip
de coduri este utilizat in special in nomenclatoarele de coduri speciale cu posibilitile de
extindere pentru particularitile tehnice semnificative (de exemplu: Codurile complexe conin
atribute ce aparin unor mulimi distincte, dar sunt folosite n comun n viitoarele prelucrri.
n aceast categorie se include codurile ierarhizate juxtapuse.
Codurile de ierarhizare redau numrul maxim de operaii, al fiecrui tip de atribut n cadrul
treptelor de ierarhizare.
Exemplu: codificarea locurilor de munc se poate face cu urmtoarea structur de cod:
Loc de munc xx x xx atelier de producie
secie de producie
societate comercial
Codurile juxtapuse se realizeaz prin concatenarea codurilor ierarhice sau secveniale in
vederea utilizrii grupate sau utilizrii individuale a atributelor codificate in raport de cerinele
statice sau dinamice de prelucrare.
Exemplu: codificarea personalului unei uniti economice poate avea un cod juxtapus, rezultat
din concatenare valorilor distincte ale atributelor (atelier de producie, secie de producie,
marc)
d) Lungimea codurilor este dat de numrul maxim de caractere folosite de un cod. Asfel
avem:
- coduri de lungime fix: cu aceiai lungime efectiv pentru toate valorile atributelor
codificate (exemplu: Codul rilor RO, DL, SW).
- coduri de lungime variabil: au lungimi diferitepentru anumite valori efective ale
atributelor (exemplu: Acronimul folosit pentru codurile societilor comerciale cu lungimea
maxim de caractere).
e) Modul de atribuire a codului se refer la modalitatea n care se realizeaz practic
codificarea: manual sau automat.
Codificarea manual este utilizat pentru orice tip de cod i se realizeaz de operatori umani
prin scrierea codurilor pe documentele primare.
112

Codificarea automat este utilizat numai pentru acele tipuri de coduri pentru care se poate
defini un algoritm de codificare programabil. De asemenea , aceast modalitate de codificare
solicit standardizarea denumirii atributelor codificate i eventual redactarea unor programe sau
rutine de recunoatere.
3) Realizarea codificrii
Activitatea de codificare se realizeaz prin parcurgerea urmtoarelor faze:
- pregtirea activitilor de codificare;
- codificarea atributelor bazei informaionale;
- ntocmirea nomenclatoarelor de coduri;
- ntreinerea nomenclatoarelor de coduri.
Pregtirea activitilor de codificare presupune urmtoarele operaii:
- analizarea coninutului i structurii bazei informaionale n vederea stabilirii acestor
atribute ca sunt sau ar trebui codificate;
- studierea volumului atributelor codificabile, a tipului de cod utilizat, inclusiv a modului
de realizare a codificrii.
n cazul unei codificrii fr pregtire prealabil, activitatea se reduce la o analiz sumar
asupra volumului de atribute. Dac se opteaz pentru codificare cu pregtire prealabil este
necesar ordonarea atributelor codificabile, analiza particularitilor coninutului bazei
informaionale i alegerea codului:
ordonarea atributelor codificabile se poate realiza prin sortarea identificatorilor
atributelor, ceea ce presupune clasificarea atributelor pe nivele ierarhice n scopul
definirii grupelor de codificare precum i reguli precise de introducere a acestora n
baza informaional;
analiza particularitilor coninutului bazei informaionale, presupune determinarea
dimensiunii mulimii de codificat i estimarea evoluiei ulterioare. Pentru aceasta este
necesar s se precizeze responsabilitile de gestionare a bazei informaionale, modul
de utilizare concret a codurilor n documente de intrare i ieire, frecvena de
utilizarea, precum i gradul de acomodare a utilizatorilor cu sistemul de coduri propus;
alegerea codului se face n coresponden cu valorile efective poteniale ale atributelor,
metoda de introducere i validare a codurilor, metode de codificare, costul i timpul de
realizare a activitii de codificare;
codificarea este subordonat cerinelor i restriciilor sistemului informatic, deoarece
acesta va stabili cerinele de informare pe nivele ierarhice, elemente ce determin
fundamental tipul, aria de utilizare i gradul de generalitate al codului proiectat;
costul i timpul de realizare a activitii de codificare determin soluia acelor tipuri de
coduri care implic cheltuieli reduse i un timp minim de realizare a nomenclatoarelor
113

de coduri;
examinarea posibilitii prelurii n noul sistem informaie a codurilor deja folosite, dat
fiind obinuina folosirii acestor tipuri de coduri, dar i scurtarea perioadei de
implementare experimentare a sistemului informatic proiectat.

4.2 Proiectarea de detaliu/fizic

Proiectarea fizic a sistemelor informatice este concretizat ntr-un ansamblu de baze de date,
proceduri de pregtire i introducere a datelor, actualizare i obinere a rezultatelor, precum i
reguli tehnice de utilizare i exploatare a ntregului sistem.
Proiectarea fizic a sistemelor informatice este caracterizat printr-o serie de trsturi
specifice:
Alegerea sistemului optim de gestiune a datelor i a sistemului de calcul care vor
asigura realizarea funcionalitii sistemului informatic definit n proiectarea logic;
Transformarea entitilor din baza informaional definite n proiectarea logic, n
colecii de date ce urmeaz a fi organizate n baze de date;
Proiectarea structural i funcional a datelor organizate n baze de date la nivelul
aplicaiilor;
Elaborarea strategiei de definire a procedurilor de actualizare i exploatare-listare a
bazelor de date, precum i specificarea msurilor de securitate i protecie.
Proiectarea fizic a sistemelor informatice are un caracter preponderent tehnic i solicit un
volum mare de munc, iar activitile desfurate sunt influenate direct de soluia aleas de
gestiune a coleciilor de date, sistemul electronic de calcul i sistemul de operare.
Proiectarea fizic implic parcurgerea urmtorilor pai:
Proiectarea fiierelor fizice i a bazelor de date - descrierea modului n care vor fi
stocate i accesate datele n/din memoriile secundare i cum se va asigura controlul lor
pentru a oferi o securitate maxim.
Proiectarea structurii sistemelor i a programelor - se descriu programele sau modulele
acestora care s fie n strns concordan cu diagramele fluxurilor de date i cu
celelalte piese ale documentaiei realizate n etapele anterioare.
Proiectarea strategiilor de prelucrare distribuit - se vor prezenta modalitile n care
utilizatorul poate s dispun de datele i facilitile de prelucrare oferite de reelele de
calculatoare.
Proiectarea fiierelor fizice i a bazelor de date i propune s asigure trecerea de la descrierea
logic a datelor la una tehnic, de stocare a datelor. Totui, proiectarea fizic se concretizeaz
n specificaii folosite ulterior de programatori i ali specialiti implicai n construirea sistemului

114

(n timpul implementrii), prin crearea fiierelor, defnirea modurilor de organizare a acestora,

precum i a bazelor de date.
Proiectarea fizic a fiierelor i bazelor de date are dou obiective:
1. Transpunerea relaiilor dintr-un model de reprezentare logic a datelor ntr-un proiect tehnic.
Un astfel de proiect va conine formatele sub care vor fi reprezentate atributele, modul de
grupare a acestora din una sau mai multe relaii n una sau mai multe nregistrri fizice, alegerea
modului de organizare a fiecrui fiier cu nregistrri fizice, precum i proiectarea metodelor de
accesare a datelor din unul sau mai multe fiiere.
2. Selectarea tehnologiilor folosite pentru stocarea datelor
Tehnologiile includ diverse funcii ale sistemelor de operare, numite metode de acces i
sisteme de gestiune a bazelor de date. Fiecare tehnologie va fi specific unei anumite arhitecturi
a sistemului.
Concret activitile din cadrul proiectrii fizice sunt:
1. Alegerea tipului de suport i modalitilor de prezentare a ieirilor informaionale;
2. Proiectarea machetelor de editare/vizualizare a ieirilor;
3. Proiectarea procedurilor i a programelor.
Aceste activiti vor fi descrise n capitolele 6 i 7.
4.3 Proiectarea orientat obiect a sistemelor informatice
Concepte utilizate n abordarea obiectual a proiectrii sistemelor informatice
Dintre conceptele care stau la baza modelrii orientat obiect cele mai importante sunt:
obiectul;
ncapsularea;
persistena;
tipul;
clasa;
motenirea;
polimorfismul;
identitatea.
Obiectul
Obiectul este o abstractizare a entitii lumii reale i se caracterizeaz prin:
stare;
comportament.
Starea unui obiect este definit de valorile atributelor sale. Un atribut este definit printr-un
nume i poate lua valori elementare (numeric, alfanumeric, etc.) sau complexe (structuri de
115

multiple referine spre alte obiecte, tipuri utilizatori etc.). Comportamentul unui obiect este definit
de setul de operaii i metode aplicabile obiectului respectiv.
Fiecare obiect are un nume care coincide, de obicei, cu numele entitii reprezentate.
Metodele i atributele nu sunt vizibile din exteriorul obiectului.
Un obiect rspunde la mesaje. Mesajul este unitatea de comunicaie dintre obiecte.
Mesajele cuprind: numele mesajului, numele obiectului int i argumentele necesare, dac
exist. Cnd un obiect primete un mesaj una din procedurile sale este apelat. Procedura
realizeaz apoi o operaie care poate returna un rezultat. Mesajele sunt implementate prin
intermediul metodelor.
ncapsularea
ncapsularea const n capacitatea obiectelor de a conine la un loc att date ct i operaii
dintre care numai o parte sunt vizibile din exterior.
Un obiect este compus din dou pri:
- interfaa permite unui utilizator extern s solicite obiectului executarea unei aciuni;
- o parte ascuns, de implementare reprezentat de starea intern i de metodele
obiectului.
ncapsularea ascunde utilizatorului complexitatea unui obiect, oferind o imagine simplificat care
i permite s rezolve mai uor problemele complexe.
Persistena
Persistena este proprietatea obiectelor care determin existena mai ndelungat a
acestora fa de procesul care le-a creat; este proprietatea prin care starea bazei de date
asigur execuia unui proces pentru a fi refolosit ulterior n alt proces.
Tipul
Tipul sintetizeaz elementele comune ale unui set de obiecte cu aceleai caracteristici.
Tipul abstract de date are dou componente:
- interfaa este vizibil utilizatorului i const ntr-o list de operaii
- implementarea presupune descrierea structurii interne a datelor obiectului i
realizarea procedurilor de implementare a operaiilor interfeei.
Clasa
Noiunea de clas are aceeai semnificaie cu cea de tip, ns este deosebit de
aceasta, prin faptul c este asociat cu faza de execuie. O clas este un tip abstract de date
care definete att structura obiectelor din clasa respectiv, ct i mulimea metodelor existente
pentru aceste obiecte.
Obiectele din aceeai clas au aceleai atribute i aceleai metode i rspund la acelai mesaj.

116

Clasele sunt organizate ierarhic. Orice subclas motenete metodele i structura clasei din
care face parte.
Motenirea
Motenirea este procesul prin care toate atributele i metodele unei clase sunt preluate
de o alt clas nrudit, numit subclas. Clasa de la care atributele i metodele sunt motenite
se numete supraclas.
Prin intermediul motenirii se pot exprima relaii deosebit de utile ntre clase: clasificarea,
generalizare, specializare.
Motenirea poate fi implementat:
- static presupune concatenarea cmpurilor motenite n clasele respective;
- dinamic presupune parcurgerea legturilor de motenire i se realizeaz fr
recopierea cmpurilor motenite.
Polimorfism
Polimorfismul semnific posibilitatea unui obiect, instan a unei clase, s rspund
diferit la primirea aceluiai mesaj.
Polimorfismul se poate asigura prin dou ci:
- redefinirea metodelor motenite n clasele derivate;
- crearea unor metode cu acelai nume dar cu parametrii deferii.
Identitatea
Identitatea unui obiect este proprietatea acestuia care l distinge de alte obiecte. Astfel,
spre deosebire de modelul relaional n care datele sunt identificate prin valori ale cheii primare
desemnate de utilizator, n modelul orientat obiect identificarea obiectelor este asigurat
automat de sistem i este transparent utilizatorului.
Dou obiecte a i b sunt identice dac au acelai identificator, adic egalitatea obiectelor este
de fapt o egalitate de pointeri (se scrie a = b).
Dou obiecte sunt egale dac au aceleai valori (a = b). Aadar
a = = b implic a = b, reciproca este fals
Nivele de modelare n proiectarea orientat obiect
Un model orientat obiect are la baz obiecte. Un obiect ncapsuleaz att date ct i
comportament, ceea ce nseamn c analistul poate folosi abordarea orientat obiect att
pentru modelarea datelor, ct i pentru modelarea proceselor. Pentru c permite analistului de
sistem s surprind ambele aspecte ntr-o singur reprezentare i pentru c ofer i alte
beneficii, cum ar fi mecanismul motenirii i reutilizarea codului, modelarea orientat obiect

117

ofer un mediu puternic pentru dezvoltarea sistemelor complexe. Teoria obiectelor,

ncapsularea, motenirea i polimorfismul stau la baza dezvoltrii obiectuale a sistemelor.
Referitor la consistena modelelor, n alte abordri - cum ar fi analiza i proiectarea -,
structurat - modelele care se dezvolt nu folosesc notaii comune i sunt slab conectate ntre
ele, tranziia de la un model la altul fcndu-se n mod abrupt. Abordarea orientat obiect ofer
continuitate n ceea ce privete tranziia ntre modelele analizei, proiectrii i ale implementrii.
De exemplu, trecerea de la analiza orientat obiect la proiectarea orientat obiect presupune
mbogirea modelului de analiz cu detalii referitoare implementare i nu dezvoltarea unui nou
model.
Modelarea domeniului (mediului) - Domain Model
Pentru a aprofunda nelegerea contextului n care va funciona sistemul se utilizeaz
modelul mediului (domeniului). Acest model cuprinde cele mai importante clase ntlnite n
domeniul economic pentru care se realizeaz sistemul informatic i are un caracter de
generalitate. Clasele se identific fie din cerinele exprimate de beneficiar, fie din intervievarea
unor experi n domeniu. Este unul dintre primele modele utilizate n analiza orientat obiect i
are menirea de a sistematiza expertiza din domeniul analizat i a o transmite sistemului
informatic ce urmeaz a fi proiectat.
Sunt trei tipuri de clase care pot fi puse n eviden n acest model:
- clase ce modeleaz obiecte sau concepte utilizate n cadrul sistemului informaional
analizat, cum ar fi comand, contract, factur;
- obiecte sau concepte din lumea real pe care sistemul trebuie s le nregistreze i s
in cont de ele, cum ar fi cursul de schimb al monedei de referin;
- evenimente ce intervin i afecteaz starea sistemului, cum ar fi plasarea unei comenzi,
plata unei facturi.
Pentru descrierea acestui model vom utiliza preponderent diagrama claselor, dintre
instrumentele puse la dispoziie de UML.
Scopul principal al acestui model este nelegerea contextului sistemului. De aceea la
realizarea modelului mediului (domeniului) este de preferat si participe att specialiti n
modelare, ct i experi din domeniul analizat. Din acest punct de vedere se remarc
asemnarea cu etapa de analiz specific metodologiilor structurate Aa cum tim deja,
conform unui vechi principiu al analizei sistemelor, n acest proces este de preferat s fie
implicai cei mai buni specialiti n domeniu (experii). Modelul mediului va conine cele mai
importante clase ale domeniului. Odat cu ntocmirea diagramei claselor se ntocmete i un
dicionar al claselor n care se va preciza semnificaia fiecrei clase pentru a se folosi o
terminologie unitar. Se prefer aceast formul pentru a se evita obinerea unui model prea
mare i greu de utilizat.
118

Modelul mediului, format din diagrama claselor domeniului i dicionarul de termeni,

poate fi utilizat att la dezvoltarea modelului cazurilor de utilizare, ct i la identificarea claselor
sistemului n etapa de analiz.
Modelarea proceselor afacerii (prelucrrilor) - Business Model
Aceasta este o tehnic de modelare utilizat pentru a aprofunda nelegerea proceselor
specifice unei organizaii. Utiliznd UML, modelarea afacerii se poate face din dou perspective:
fie prin modelul cazurilor de utilizare, fie prin modelul obiectelor.
n cadrul modelrii cazurilor de utilizare (business use-case model) se surprinde
funcionarea sistemului din perspectiva utilizatorilor acestuia.
Modelul obiectelor (business-object model) surprinde prelucrrile din interiorul
sistemului. Descrie n detaliu cum este tratat fiecare caz de utilizare. Realizarea cazurilor de
utilizare se poate evidenia cu ajutorul diagramelor de interaciune (diagrama de secven,
diagrama de colaborare) sau al diagramei de activitate.
O entitate a sistemului existent (a afacerii) reprezint un lucru pe care utilizatori,
acceseaz, consult, manipuleaz, realizeaz sau utilizeaz n cadrul unui caz de utilizri. O
unitate de lucru este un set de astfel de entiti care formeaz un ntreg pentru utilizatorul final.
Entitile i unitile de lucru sunt utilizate pentru a reprezenta aceleai concepte ca i clasele
din modelul mediului (comand, produs, factur, cont).
Fiecare utilizator, entitate sau unitate de lucru poate participa la realizarea mai multor cazuri de
utilizare.
Un astfel de model se dezvolt n doi pai:
1. Realizarea modelului cazurilor de utilizare
2. Detalierea modelului prin specificarea utilizatorilor, entitilor i a unitilor lucru, dar i
a regulilor care guverneaz anumite procese sau obiecte.
Scopul este crearea unor utilizatori, entiti i uniti de lucru care s rezolve problema
evideniat de cazul de utilizare, eficient - bine, rapid i la cel mai sczut cost posibil.
Modelarea mediului i modelarea afacerii par ntructva asemntoare, mai ale dac ne gndim
c entitile i unitile de lucru corespund claselor din modelul mediu.
Cele dou abordri difer n primul rnd prin modul de documentare. Una se bazeaz
pe cunotinele unui expert n domeniu sau pe cunotinele despre sisteme similare, n timp ce a
doua are n vedere cerinele beneficiarului. Orice clas a modelului domeniului i regsete
originea n experiena cunosctorilor domeniului. Orice element al modelului afacerii (entitate
sau unitate de lucru) i regsete originea ntr-o cerin a beneficiarului. Acesta este i motivul
principal pentru care utiliznd cele dou abordri, n mod normal, se obin clase, atribute,
metode i asocieri diferite.

119

O alt deosebire ar fi c pornind de la analiza domeniului vom obine mai multe

informaii despre atributele claselor i mai puine despre comportamentul acestora
Evident, n cazul modelrii afacerii se vor identifica att entitile i unitile de lucru (clasele),
ct i utilizatorii (i operaiile pe care acetia le ntreprind).
i nu n cele din urm, modelul afacerii fiind mult mai detaliat, va fi mai bine valorificat n etapele
ce vor urma. Se pot identifica mai bine actorii i cazurile de utilizare ale sistemului proiectat, i
fiecare dintre acestea va putea fi mai bine pus n coresponden cu cerinele sistemului.
Dac modelul mediului abordeaz cu precdere funcionarea sistemului n contextul
acestuia, modelul afacerii i focalizeaz atenia asupra utilizatorilor i a modului cum
sistemul i deservete.
Modelarea cazurilor de utilizare
Un model al cazurilor de utilizare este format din actori i cazuri de utilizare
Un actor este o entitate extern ce interacioneaz cu sistemul (similar unei entiti externe dintro diagram de flux a datelor). Actorul este ceva sau cineva care schimb informaie cu sistemul.
Un actor nu este obligatoriu s fie un utilizator uman. El poate fi i un alt sistem sau un dispozitiv
hardware (exemplu, monitorul) cu care sistemul nostru interacioneaz sau schimb informaii.
Un caz de utilizare este o secven de aciuni iniiate de un actor, surprinznd un
anumit mod de a folosi sistemul. Nu trebuie fcut confuzie ntre actor al sistemului i utilizator
al sistemului. Un utilizator este oricine folosete sistemul. Un actor este un rol pe care utilizatorul
l poate juca. Numele actorului trebuie s indice acest rol. Un actor este un tip sau o clas de
utilizator. Acelai utilizator poate juca mai multe roluri.
Actorii, fiind entiti externe sistemului, nu pot fi descrii n detaliu. Identificarea actorilor ajut la
identificarea cazurilor de utilizare - ntruct un caz de utilizare este iniiat de un actor. Iat cteva
ntrebri la care analistul de sistem trebuie s rspund pentru a identifica cazurile de utilizare:
1. Care sunt principalele aciuni executate de fiecare actor?
2. Actorul va citi sau va actualiza informaia din sistem?
3. Actorul va informa sistemul despre modificrile petrecute n afara acestuia?
4. Actorul va fi informat de modificrile din sistem?
S considerm cazul unui sistem de nregistrare al studenilor la cursurile oferite de un
centru de instruire. Entitile externe sistemului sunt studentul care se nscrie la curs, secretara
care face nscrierea studenilor la cursuri, casiera care ncaseaz contravaloarea cursurilor i
instructorul care pred cursurile
Un caz de utilizare este iniiat ntotdeauna de un actor i poate interaciona i cu ali
actori, nu numai cu cel care 1-a iniiat. Cazul de utilizare trebuie s redea o funcionalitate
complet i nu numai o anumit aciune a unei funcionaliti. Transmiterea unui formular de
nscriere la un curs este parte a procesului de nregistrare la curs, deci va fi inclus n cazul de
120

utilizare nregistrare la curs" i nu se va construi un caz separat pentru aciunea transmitere

formular de nscriere.
Diagrama cazurilor de utilizare arat care sunt toate cazurile de utilizare din sistem. dar nu
indic modul n care acestea sunt realizate de ctre actori. Modelul cazurilor de utilizare este
completat de o descriere textual a fiecrui caz de utilizare, accentul punndu-se pe
interaciunea cu ali actori i mai puin pe modul n care este executat n cadrul sistemului.
Modelarea cazurilor de utilizare permite analiza cerinelor funcionale ale sistemului,
insistnd asupra a CE trebuie s fac un sistem existent sau un nou sistem, fr s considere
i CUM o s fac. Modelul cazurilor de utilizare este dezvoltat n faza de analiz a ciclului de
via al sistemelor orientate obiect, avnd rolul de a ajuta dezvoltatorii s neleag cerinele
funcionale ale sistemului. Procesul este iterativ iar, stabilirea cerinelor se face n urma
discuiilor cu beneficiarul sistemului. Cazurile de utilizare controleaz toate celelalte modele.
Dac cerinele utilizatorului se modific n timpul dezvoltrii, aceste modificri sunt vizibile mai
nti n modelul cazurilor de utilizare. Modificrile n cazurile de utilizare implic modificri i n
celelalte modele. i reciproca este valabil, adic n momentul n care se fac modificri n
modele, acestea trebuie s se reflecte i la nivelul cazurilor de utilizare.
Modelarea structurii statice (diagrama claselor, diagrama obiectelor)
Diagrama claselor documenteaz structura static a sistemului; mai exact precizeaz clasele
care exist i relaiile dintre acestea, nu i modul n care interacioneaz pentru a asigura un
anumit comportament. Diagrama claselor poate, de asemenea, evidenia i alte aspecte ale
structurii statice, cum ar fi pachetele.
Construirea diagramei claselor presupune n primul rnd identificarea claselor din
sistem, acest proces reprezint o parte esenial a proiectrii sistemelor orientate obiect, de
succesul acestuia depinznd n mare parte succesul proiectului.
Criteriile de apreciere a unui model al claselor sunt:
obiectele claselor din model trebuie s poat furniza ntregul comportament cerut
sistemului;
un bun model al claselor conine (pe ct posibil) clase stabile din domeniul obiectual,
care nu depind de funcionalitatea particular cerut la momentul proiectrii.
Poate fi utilizat orice tehnic de obinere a claselor atta timp ct modelul obinut respect
criteriile enunate. Implicit, dac modelul obinut nu respect criteriile, nu va fi nimeni interesat
de tehnica utilizat, orict de profesionist ar fi aceasta.
n literatura de specialitate se propun dou metode:
modelarea orientat pe date (data driven design);
modelarea orientat pe funciuni (responsibility driven design).

121

Primul tip de metode presupune identificarea tuturor datelor din sistem i mprirea Ior pe
clase, nainte de a considera funciunile acestor clase. Tehnica identificrii substantivelor este
cea mai utilizat astfel de metod. Al doilea tip de metode, orientate pe funciuni, presupune
identificarea tuturor funciunilor sistemului i mprirea lor pe clase, nainte de a considera
datele acestor clase.
Tehnica identificrii substantivelor presupune dou etape:
Identificarea claselor candidate, selectnd din specificarea cerinelor sistemului toate
substantivele i frazele substantivale (se consider substantivele la singular i nu se
aleg fraze ce conin sau" ca unici candidai).
Se elimin candidaii considerai nepotrivii din diverse motive i se redenumesc clasele
rmase dac este necesar.
Unele dintre motivele pentru care o clas candidat ar putea fi considerat nepotrivit sunt:
Redundana - o clas e prezent sub mai multe denumiri. Este important s ne amintim ns c
obiecte similare pot s nu fie identice. Proiectantul decide dac lucrurile sunt suficient de diferite
pentru a merita clase diferite.
De exemplu, dac a fost selectat o pereche de genul mprumut" i mprumut pe termen
scurt", acestea sunt diferite, dar numai la nivelul valorii atributelor. Se recomand n acest caz
alegerea unui nume care s desemneze ntreg coninutul clasei.
Imprecizia - cnd nu se poate spune precis care e realitatea descris de substantivul respectiv.
Desigur, trebuie ndeprtat ambiguitatea nainte de a putea spune dac substantivul reprezint
o clas.
Eveniment sau operaie - cnd substantivul se refer la ceva ce este fcut de sistem. Uneori
aceast situaie este bine modelat de o clas, dar nu este acesta cazul obinuit.
Metalimbaj - unde substantivul face parte din modul de definire a cerinelor. Vom utiliza
substantive ca cerine" sau sistem" ca parte a limbajului de modelare i nu pentru a reprezenta
obiecte din domeniul problemei.
Extern sistemului - atunci cnd substantivul este relevant pentru a descrie funcionarea
sistemului, dar nu se refer la ceva din interiorul su.
Atribut - atunci cnd este clar c substantivul desemneaz o realitate simpl, fr un
comportament interesant, care este de fapt un atribut al altei clase.
Diagrama obiectelor
Diagramele obiectuale conin obiecte i legturi. Ca i celelalte diagrame, pot conine note i
restricii. Mai pot conine anumite pachete sau subsisteme, fiecare fiind folosite pentru a grupa
elementele modelului.

122

Aceste diagrame se folosesc pentru modelarea static a unui sistem, ca diagramele de

clase, dar din perspectiva unor instane reale sau prototip.
Crearea unei diagrame conceptuale se face ntr-un singur mod, modelnd structura obiectelor.
Modelarea structurii obiectelor implic fotografierea obiectelor din sistem la un anumit moment.
Modelarea dinamicii sistemului
Pentru modelarea dinamicii sistemului, UML furnizeaz dou tipuri de diagrame i
anume,
A.Diagrame pentru modelarea structurii statice folosite pentru a vizualiza, specifica,
construi si documenta aspectele statice ale sistemului Acestea sunt organizate n jurul grupelor
majore de elemente ce pot fi gasite n modelarea unui sistem. Din aceast categorie fac parte :

Diagrame de clase conin o mulime de clase, interfee si colaborri,

precum i relaiile dintre ele. Sunt cele mai folosite diagrame n modelarea
sistemelor orientate obiect, i ilustreaza vederea static de proiectare a unui
sistem.

Diagrame de obiecte conin o mulime de obiecte si relaiile dintre ele.

Sunt folosite pentru a ilustra structurile de date, imagini statice ale instanelor
elementelor din diagramele de clase.

Diagrame de componente - conin o mulime de componente si relaile dintre

ele. Se folosesc pentru a ilustra vederea static de implementare a unui
sistem.

Diagrame de amplasare - conin o mulime de noduri si relaiile dintre ele,

ilustrnd vederea statica de amplasare a unei arhitecturi.
B.Diagrame comportamentale sunt folosite pentru a vizualiza, specifica, construi i
documenta aspectele dinamice ale unui sistem. Acestea sunt organizate n jurul modalitilor
principale de a modela dinamica unui sistem. Din aceast categorie fac parte:

Diagrame ale cazurilor de utilizare - arat o mulime de cazuri de utilizare,

de actori (un tip special de clase) si relaiile dintre ele.

Diagrame de secventa. - pun n eviden ordinea temporal a mesajelor. O

diagram de secven arata o mulime de obiecte mpreun cu mesajele
expediate si recepionate de ctre acestea.

Diagrame de colaborare. - pun n eviden organizarea structural a

obiectelor care trimit i recepioneaz mesaje. O diagram de colaborare
arat o mulime de obiecte, legturile dintre aceste obiecte, mpreun cu
mesajele expediate i receptionate de ctre acestea.
123

Diagrame de tranziie a strilor conin maini cu stri, ce constau n stri,

tranziii, evenimente i activiti. Aceste diagrame se folosesc pentru a ilustra
vederea dinamic a unui sistem.

Diagrame de activitate arat fluxul dintr-o activitate n alta n cadrul unui

sistem. O activitate arat un set de activiti, fluxul secvenial sau ramificat de
la o activitate la alta, si obiectele care acioneaz sau sunt acionate de
consecin.
Principala menire a acestor diagrame este de a arata cum realizeaz sistemul un caz de
utilizare sau un scenariu particular dintr-un caz de utilizare. Pentru fiecare caz de utilizare se pot
realiza mai multe scenarii (din descrierea cazului de utilizare). Pentru fiecare astfel de scenariu
se pot ntocmi, nu este obligatoriu, o diagram de secven sau o diagram de colaborare
(unele dintre instrumentele CASE pot obine o diagram din alta).
Acest tip de diagrame nlesnete nelegerea cazurilor de utilizare mai dificile. Ele pot,
de asemenea, susine comunicarea n cadrul echipei de proiectare, n cazul n care de o
aceeai interaciune se ocup mai multe persoane sau grupuri de persoane. Nu e de ateptat s
se dezvolte astfel de diagrame pentru fiecare caz de utilizare sau pentru fiecare operaie, doar
dac beneficiile depesc costurile. n cazul n care se dispune de un CASE ce poate utiliza
aceste diagrame la generarea de cod, atunci devine profitabil s dezvoltm diagrame de
interaciune i diagrame de comportament.
Diagramele de secven descriu modul n care obiectele interacioneaz i comunic
ntre ele. Aceste diagrame permit focalizarea ateniei asupra secvenelor de mesaje, mai precis
asupra mesajelor care sunt trimise i recepionate de ctre obiecte.
Avantajul major al diagramelor de secven, fa de diagramele de colaborare, este posibilitatea
de a reprezenta grafic trecerea timpului, fiind deci indispensabile n czul proiectrii de sisteme
n timp real.
Diagramele de colaborare permit evidenierea att a interaciunilor, ct i a legturilor
dintre un set de obiecte care colaboreaz. Att diagramele de secven, ct i cele de
colaborare vizualizeaz interaciunile, dar diagrama de secven ia n considerare timpul, pe
cnd cea de colaborare, spaiul.
Ca i diagramele de secven, diagramele de colaborare pot fi utilizate pentru nscrierea
execuiei unei operaii, a unui caz de utilizare sau a unui scenariu de interaciune n cadrul
sistemului. n acest tip de diagram nu pot fi descrise mesajele concurente i asincrone.
Pn acum nu am amintit nimic despre modelarea deciziei" unui obiect despre ceea
ce s fac la primirea unui mesaj. Diagramele de interaciune pot reprezenta obiecte diferite ale
aceleiai clase care primesc acelai mesaj, dar rspund diferit. Acest comportament este
rezonabil de cele mai multe ori, ntruct comportamentul unui obiect poate fi afectat i de valorile
124

atributelor sale. Pentru a putea implementa, ntreine sau testa o clas este necesar s
nelegem relaiile de dependen care exist ntre starea unui anumi: obiect i reaciile sale la
mesajele primite sau la alte evenimente.
Diagramele de stare sunt acelea care nregistreaz aceste dependene.
Pornind de aici, se pot folosi aproximativ aceleai notaii pentru a descrie activit complexe. Se
consider c trecerea de la o activitate la alta atunci cnd prima activitate s-a ncheiat este
similar cu trecerea unui obiect dintr-o stare ntr-alta, semnificativ diferit de prima, atunci cnd
acesta primete un mesaj. Diagramele de activitate sunt o variaiune a diagramelor de stare,
adaptate pentru a evidenia conexiunile i dependenele dintre activiti. Ele sunt extrem de
folositoare atunci cnd se apreciaz c o activitate trebuie s execute o serie de task-uri diferite
i dorim s modelm dependenele eseniale dintre acestea, nainte de a decide n ce ordine s
se execute.
Diagramele de stare au rolul de a captura ciclul de via al obiectelor, subsistemelor i
sistemelor, prin specificarea strilor n care se poate gsi un obiect i a evenimentelor (mesaje
primite, erori, condiii care devin adevrate) care-i afecteaz starea de-a lungul execuiei. O
diagram de stare poate fi ataat oricrei clase care are stri clar identificabile i un
comportament complex.
O diagram de activitate constituie o variant a diagramei de stare, cu un scop puin
diferit, acela de a evidenia aciuni i rezultate ale acestor aciuni. De fapt, diagramele de
activitate constituie o cale alternativ de descriere a interaciunilor.
Diagramele de activitate pot fi utilizate i pentru a descrie cum se desfoar cazuri de utilizare
individuale i cum depind de alte cazuri de utilizare.
Diagramele de activitate pot fi folosite n mai multe scopuri, i anume:
- Ilustrarea aciunilor care vor fi realizate atunci cnd este executat o operaie. Acesta
este i cel mai comun caz de utilizare a acestui tip de diagram.
- Prezentarea activitii interne a unui obiect.
- Identificarea aciunilor care pot fi realizate n mod legat i stabilirea modului n care
aceste seturi de aciuni afecteaz obiectele din jur.
- Ilustrarea modului n care instana unui caz de utilizare poate fi realizat n termenii
aciunilor sau modificrilor intervenite n starea obiectului.
- Ilustrarea modului n care este organizat munca actorilor, care este organizarea i
obiectele folosite.

125

Dezvoltarea sistemelor informatice folosind procesul unificat(UML)

Proiectarea orientat obiect i gsete justificarea n cerina imperioas de a face fa
i a oferi soluii superioare calitativ n special sistemelor informatice de mari dimensiuni i nivel
ridicat de complexitate.
Interesul manifestat fa de abordarea obiectual, n programare mai nti i, prin fora
lucrurilor, n proiectare i apoi n analiz au condus, odat cu acumularea de suficient
experien practic, la definirea de metode de dezvoltare orientate obiect. Printre acestea, cele
care s-au bucurat de cele mai bune aprecieri din partea utilizatorilor au fost OMT(Object
Modeling Tehnique), OOSE(Object-Oriented Software Engineering), UML(Unified Modeling
Language).
UML este rezultatul unui efort de unificare la care au contribuit elemente dezvoltate de
numeroase cercetri i metode. De altfel, documentul oficial definete UML drept o colecie a
celor mai bune practici aplicate n modelarea sistemelor informatice de mari dimensiuni i
complexitate.
UML a fost definit pornind de la rolul esenial pe care-l joac modelarea n conceperea
i realizarea de sisteme software. Un model este formulat ntr-un limbaj de modelare. Limbajul
de modelare include un ansamblu de concepte i semantici fundamentale, o notaie i un set de
reguli de utilizare. Pentru un plus de rigoare i claritate a definirii, conceptele de baz sunt, la
rndul lor modelate n UML. Aceast definire recursiv este denumit metamodelare.
Metamodelele ofer o descriere formal a tipurilor de elemente care pot participa la modelare
(sau din care pot fi compuse modelele) numite simplu elemente de modelare mpreun cu
sintaxa i semantica notaiei prin care sunt referite i folosite acestea. n ali termeni, fiecare
metamodel definete elementele de modelare i regulile dup care se compun acestea n
modele.
Notaia folosit este format din simboluri grafice. Aceasta conduce la utilizarea
sintagmei de modelare vizual pentru UML i justific declararea sa drept limbaj de
vizualizare. Paradigma obiectual, printre altele, avantajul c ofer un set de concepte ce pot fi
aplicate uniform pe toate nivelele de abstractizare, ncepnd cu viziunea schematic iniial i
pn la viziunea terminal, suficient de detaliat pentru a oferi toate amnuntele necesare
traducerii directe n program surs. Aplicate n acest context, rigoarea i consistena cu care
sunt definite conceptele sale au fcut din UML baza mai multor instrumente CASE, aa cum
este Rational Rose. Acestea nu numai c asist analiza i proiectarea prin mijloace specifice,
dar sunt capabile i de generarea automat a unei pri din codul surs, n mai multe limbaje la
alegere. Exist, prin urmare, posibilitatea, demonstrat practic, de a defini reguli i euristici de
trecere de la structurile UML la construciile specifice unui limbaj de programare sau altul.

126

Diversele metode obiectuale, inclusiv cele care ua stat la originea UML, preconizeaz
diferite procese de dezvoltare a sistemelor. Procesul este cel care prescrie activitile i ordinea
n care trebuie realizate, rezultatele de obinut din fiecare activitate, criteriile de evaluare a
calitii i de msurare i control a progresului proiectului etc. Dincolo de specificitatea oferit de
o metod sau alta, procesul trebuie adaptat de asemenea, la natura problemei de rezolvat, la
cultura managerial a utilizatorului, la caracteristicile echipei implicate n realizare .a.m.d. UML
nu este o metod de dezvoltare obiectual. Poate accepta i poate fi ns folosit n diverse
metode, chiar dac acestea aplic procese diferite. A fost astfel definit i un proces de aplicare a
UML n dezvoltarea de sisteme informatice, denumit, la rndul su, unificat.
Procesul unificat poate fi caracterizat prin urmtoarele trsturi cheie:
este iterativ i incremental;
este dirijat de cazurile de utilizare;
este centrat pe arhitectur;
este pilotat de riscuri.
Conform primei trsturi, dezvoltarea are loc prin mai multe iteraii succesive, n fiecare
dintre acestea abordndu-se doar o poriune a sistemului su doar anumite aspecte ale
proiectri i realizrii. n felul acesta se renun la ideea de a defini n totalitate detaliile aferente
unei anumite etape nainte de a trece la urmtoarea. De aceast dat, se accept o definire
parial, pe baza creia se construiete un produs la care se revine, ntr-o nou iteraie, cu
modificri sau cu noi detalii sau funcii aspectul incremental pn la obinerea sistemului
final. Progresul proiectului poate fi mai bine controlat, iar experiena acumulat n cursul unei
iteraii poate fi utilizat n cele care urmeaz.
Cazurile de utilizare constituie punctul central al edificiului: n stadiul iniial, ele definesc
utilizatorii i cerinele acestora sub forma actorilor i a interaciunilor dorite ale acestora cu
sistemul. Aceleai cazuri de utilizare vor constitui punctul iniial n definirea cerinelor i referina
pentru proiectare i realizare, iar setul de teste prin care este verificat sistemul se va defini tot pe
baza lor. Prin posibilitatea de a regsi permanent legtura cu cazul de utilizare n cursul
ntregului ciclu de dezvoltare, se rspunde i cerinei de asigurare a trasabilitii.
UML asigur prezentarea diferitelor aspecte ale sistemului modelat sub forma unor abstractizri
ce constau ntr-o secven de diagrame5

Davidescu N. Proiectarea Sistemelor Informatice prin limbajul UML, Editura ALL Back, Bucureti
127

Diagrame
de
colaborare
Cazuri
de
utilizare

Diagrame
de
clase

Diagrame
de
activitate

Diagrame
de
secvene

nlnuirea diagramelor UML

Ciclul de dezvoltare
Ciclul de dezvoltare este compus din patru faze. Fiecare faz produce un anumit set de
rezultate care sunt elemente de intrare pentru urmtoarea, ceea ce confer ansamblului un
caracter de confidenialitate. Pentru fiecare faz, anumite rezultate sunt folosite drept balize de
evaluare i servesc pentru a msura progresul nregistrat de proiect.
Fazele ciclului de dezvoltare sunt urmtoarele: studiul preliminar, elaborarea, construcia, i
tranziia.
Studiul preliminar (inception n terminologia de origine) urmrete definirea amplasrii
viitorului sistem n cadrul activitii organizaiei. Aceasta include delimitarea ariei de cuprindere,
stabilirea obiectivelor, studiul fezabilitii n contextul unuia sau mai multor modele de afaceri.
Rezultatul cheie al fazei este viziunea sistemului, care conine o descriere foarte sintetic n
care se precizeaz ce este sistemul, cine l va utiliza, ce faciliti trebuie s asigure i la ce
restricii trebuie s rspund. Viziunea constituie i principala baliz de evaluare a studiului
preliminar.
Elaborarea asigur colectarea i precizarea cerinelor funcionale i nefuncionale ale viitorului
sistem. Cum utilizatorii sistemului i cerinele acestora sunt specificate prin intermediul cazurilor
de utilizare, modelul detaliat al acestora constituie unul dintre artefactele de baz i, n acelai
timp, baliz de evaluare a fazei. Un alt rezultat esenial, strns legat de precedentul i inclus n
balizele de evaluare de baz, este reprezentat de arhitectura sistemului.
Construcia asigur obinerea sistemului, incluznd deci analiza, proiectarea, programarea i
testarea. Rezultatele ce servesc drept principale balize de evaluare cuprind ntregul set de
modele de analiz i proiectare, mpreun cu totalitatea programelor elaborate.
Tranziia asigur introducerea n exploatare a sistemului la utilizator. Aici se regsesc
configurarea, instalarea, furnizarea documentaiei, instruirea i eventual formarea personalului.
Principala baliz de evaluare este versiunea final a sistemului.
Sistemul informatic obinut n urma parcurgerii celor patru faze poate solicita modificri
ulterioare pentru asigurarea evoluiei sale. Pentru referirea la asemenea stadii evolutive, se
128

folosete termenul de generaie. n consecin, la terminarea primului ciclu de dezvoltare,

rezult generaia 1 a produsului software respectiv. Obinerea unei noi generaii presupune
reluarea ciclului, cu parcurgerea celor patru faze.
Activiti i iteraii
Structurarea n cele patru faze ale ciclului de dezvoltare corespunde perspectivei
manageriale asupra procesului, n care atenia este concentrat asupra aspectelor financiare,
strategice, de personal. Aspectele tehnice legate de conceperea i realizarea sistemului sunt
proprii unei alte perspective a aceluiai proces, structur n activiti i iteraii.
O activitate se realizeaz prin combinarea mai multor pai. Pasul este componenta
elementar i folosete anumite elemente de intrare pe care le modific sau pe baza crora
realizeaz alte elemente noi. Aceste intrri i ieiri sunt produse intermediare constnd din
documente, modele, programe etc.
Exist cinci activiti de baz: definirea cerinelor, analiza, proiectarea, implementarea i
testarea.
Definirea cerinelor se concentreaz asupra identificrii cerinelor funcionale i nefuncionale
ale sistemului. Aceast etap furnizeaz imaginea exterioar a sistemului, adic imaginea
perceput de ctre utilizatorii si.
Analiza urmrete obinerea unui model al problemei de rezolvat, aa cum apare aceasta la
nivelul activitii reale de afaceri. Modelul este ns formulat n termeni informatici, prin clase de
obiecte, operaii, interaciuni etc. i ignor orice detaliu tehnic sau de implementare.
Proiectarea extinde sau adapteaz modelul anterior pentru a rspunde cerinelor tehnice i
restriciilor configuraiei de calcul n care va funciona sistemul. Este etapa n care sunt luate n
considerare i rezolvate problemele de persisten, de intefa, de comunicare etc. pstrnd
ns neschimbat structura i comportamentul definite anterior, care exprim logica domeniului.
Implementarea const n scrierea, compilarea i documentarea programelor pentru proiectul
definit n etapa precedent.
Testarea asigur verificarea programelor realizate n etapa anterioar pentru a stabili msura n
care acestea corespund cerinelor funcionale i nefuncionale, sunt sigure n funcionare.
Activitile enumerate se bucur de o accepiune aproape unanim. Cu toate acestea
numeroi autori le combin sau le completeaz.
Fiind vorba despre acelai proces privit din perspective diferite, exist o suprapunere a fazelor i
activitilor. Deosebit de semnificativ este faptul c activitile se pot regsi n totalitate, chiar
dac n proporii diferite, n fiecare din cele patru faze. Spre exemplu, sunt posibile activiti de
implementare i testare chiar i n faza de studiu preliminar, pentru care metoda recomand, de
altfel, recurgerea la prototipaj, ceea ce indivizualizeaz suficient de clar demersul aplicat.

129

Teste de evaluare a cunotinelor

1................... exprima doua categorii de cicluri de activitate: una derulanta inainte care
sintetizeaza sistemul nou si una inapoi pentru dobndirea sistemului si a componentelor sale
pentru o posibila reutilizare.
a. Modelul incremental;
b. Modelul X;
c. Modelul piramida

d. Modelul V;
e. Modelul evolutiv.

. 2. .................... consta in modificarea partiala neintentionata a continutului, a mesajului unei

informatii pe parcursul culegerii, prelucrarii si transmiterii de la emitator la receptor.
a. Redundanta
d. Chestionarele;
b. Filtrajul;
e. Esantionarea.
c. Distorsiunea
3. Proiectarea n domeniul tehnologiilor i echipamentelor este o subactivitatea a :
a. activitii de cercetare-dezvoltare;
b. activitii de producie;
c. activitii de comercializare.
4. Determinarea capacitii de producie i utilizarea eficient a acesteia reprezint o
subactivitate a:
a.
b.
c.
d.
e.

activitii de producie;
activitii de cercetare-dezvoltare;
activitii de comercializare;
activitii de personal;
activitii de desfacere.

5 Elaborarea normativelor i normelor de consum pentru resursele materiale i energetice este

o subactivitate a:
a. activitii de producie;
b. activitii de desfacere;
130

c. activitii de comercializare;
d. activitii de cercetare-dezvoltare;
e. activitii de personal.
6. Elaborarea normativelor i normelor de munc i a consumurilor specifice de manoper este
o subactivitatea a:
a. activitii de cercetare-dezvoltare;
b. activitii de producie;
c. activitii de comercializare.
7. Definirea ingredientelor i a proceselor ce sunt utilizate n producia continu este o
subactivitatea a :
a. activitii de producie;
b. activitii de cercetare-dezvoltare;
c. activitii de comercializare.
8 Definirea seciilor, operaiilor i ordinea lor, care intervin n fabricarea unui produs este o
subactivitate a:
a. activitii de cercetare-dezvoltare;
b. activitii de producie;
c. activitii de comercializare.
9.Specializarea claselor are ca punct de plecare:
a. programe de investitii, programe de aprovizionare si vnzare de bunuri, servicii si de
marketing
b. transmiterea si prelucrarea datelor, obtinerea de informatii
c. superclasa adaugnd noi atribute relevante numai pentru anumite obiecte din clasa, crend
astfel subclasele
d. un sistem operant format din reuniunea de functii care pune in evidenta cel mai bine
comportamentul intregului sistem operant
e. starea in care se afla elementele patrimoniale, sau valorile definite prin raportari

131

132

Capitolul 5
Implementarea, exploatarea i ntreinerea sistemelor informatice
Obiective:
Identificarea fazelor de implementare a sistemelor informatice
Cunoaterea procedeelor de exploatare i ntreinere a sistemelor infromatice
Elaborarea documentaiei de utilizare a sistemului informatic proiectat
Cuvinte cheie: metode de implementare a sistemelor informatice, metode de ntreinere
adaptiv, perfectiv, preventiv, corectiv, metode de tastare a programelor
5.1 Implementarea sistemelor informatice
Implementarea sistemelor informatice este o etap a ciclului de via al dezvoltrii
sistemelor informatice care se regsete n toate metodologiile de realizare a sistemelor
informatice.
Implementarea sistemului informatic este acea etap n care se realizeaz efectiv trecerea de la
vechiul sistem de lucru la cel nou. Este o etap foarte dificil, deoarece necesit conlucrarea
strns dintre realizatorii sistemului informatic i beneficiarii acestuia. Este etapa n care
sistemul este supus la cea mai dificil testare, cea a condiiilor reale de funcionare. Acum pot
aprea cazuri care nu au fost prevzute de proiectani, la care sistemul nu este protejat.
Implementarea sistemului const n punerea n practic a specificaiilor logice i are n vedere:
corelarea modulelor din punct de vedere al funciilor logice realizate (invocri, utilizri);
crearea interferenei dintre module conform standardelor de intrare/ieire;
ordinea n care modulele sunt codificate, testate i implementate;
calitatea datelor i destinaia rapoartelor;
cerinele fiierelor i ale bazei de date (numr, coninut, tipuri de date, tipuri de acces,
tipuri de nregistrri, etc.);
ordonana activitilor de implementarea, instalarea i de instruire specifice sistemului
considerat.
n cadrul acestei etape se testeaz, se verific i se asimileaz de ctre beneficiar toate
soluiile stabilite n etapele anterioare i se valideaz rezultatele obinute.
Mai nti este necesar o pregtire a mediului n care va fi implementat sistemul informatic, ceea
ce poate nsemna: instruirea personalului care urmeaz s exploateze sistemul, asigurarea
condiiilor organizatorice necesare funcionrii sistemului, asigurarea resurselor hardware
necesare, asigurarea fondului informaional.

133

Implementarea ncepe n momentul n care toate componentele au fost testate

individual i permit asamblarea fiecrei aplicaii i a ntregului sistem informatic. Aceste
componente nglobeaz, pe de o parte, procedurile manuale folosite pentru pregtirea i
testarea documentelor n vederea prelucrrii, efectuarea coreciilor, interpretarea i utilizarea
rezultatelor, iar, pe de alt parte, procedurile prin intermediul crora are loc realizarea efectiv a
funcionalitii sistemului informatic.
n timpul implementrii, numeroase activiti vor fi executate simultan. De aceea, ele
trebuie s fie planificate i programate de ctre o echip de implementare format din utilizatori,
manageri i specialiti n proiectarea sistemelor.
Planificarea implementrii, firesc, ncepe anterior demarrii unei astfel de aciuni. De
fapt, problemele implementrii sunt abordate chiar la nceputul proiectului, iar aspectele
conceptuale i strategiile implementrii i conversiei sistemelor trebuie luate n discuie n
fiecare stadiu al ciclului de via al sistemelor. Totui, planurile detaliate de implementare nu pot
fi finalizate pn cnd conducerea nu aprob proiectul noului sistem.
Un plan de implementare evideniaz toate activitile necesare, ajutnd pe cei ce-l
ntocmesc s fie siguri c totul a fost prezentat corect. Prin el se vor consemna toate activitile
de efectuat, precum i timpul alocat. Responsabilitile de execuie trebuie s fie foarte clare. De
asemenea, trebuie estimate costurile fiecrei activiti astfel nct s poat fi elaborat un buget
special. n acelai timp trebuie determinate reperele de execuie n timp, pentru a se putea
exercita controlul. Mai dificil este de estimat momentul cnd se va finaliza implementarea. De
fiecare dat utilizatorii sunt cei care i dau acceptul final, iar procesul, teoretic, poate fi
considerat ca desfurndu-se pe o perioad nedefinit.
Planul de implementare este revizuit i modificat la interveniile comitetului de
informatizare, ale utilizatorilor, ale conductorilor sistemului, nainte de a ncepe operaiunea de
implementare.
Fazele procesului de implementare a sistemelor sunt redate n figura de mai jos :

134

Planificarea implementarii

Realizarea i

Pregtirea

Selectarea i

testarea

locurilor de munc;

instruirea

instalarea i testarea

personalului

programelor

Finalizarea

Testarea

documentaiei

sistemului

Conversia de la
vechiul la noul

Fig. 6.1 Fazele procesului de implementare a sistemelor

5.1.1 Realizarea i testarea programelor
Realizarea programelor a fost descris n capitolul anterior, motiv pentru care nu vom
descrie dect modul de testare a programelor
Etapa de testare a sistemului are ca scop eliminarea (pe ct posibil) a erorilor i
neajunsurilor sistemului informatic. Ea se aplic att programelor individuale ale sistemului, ct
i sistemului n ansamblul su (pentru testarea legturilor ntre module). Metodele de testare
depind att de nivelul la care se aplic, ct i de tipul erorilor cutate.
ntr-un sistem informatic se pot distinge urmtoarele tipuri de erori:
Erori de sintax, sunt acele tipuri de erori ce sunt detectate n faza de compilare i sunt
datorate construciei greite a unei instruciuni (lipsa unei paranteze, scrierea greit a numelui
unei funcii etc.);

135

Erori de rulare (de execuie) care sunt detectate la rularea programului i sunt datorate folosirii
incorecte a comenzilor i funciilor limbajului (chiar scrise corect din punct de vedere sintactic).
Exemple de asemenea erori sunt: folosirea unei variabile neiniializate, ncercarea de a scrie
ntr-o fereastr la coordonate mai mari dect dimensiunea acesteia etc.;
Erori de algoritm programul nu genereaz erori nici la compilare, nici la rulare, dar rezultatele
obinute nu sunt cele ateptate, corecte;
Erori de utilizare sistemul funcioneaz corect, dar utilizatorul l folosete greit.
Erorile cel mai simplu de detectat, sunt cele de compilare, ele fiind sesizate automat la
compilarea unui fiier surs, urmeaz apoi erorile de rulare, care sunt de asemenea detectate i
sesizate automat, dar la execuia programului n cauz. La detectarea unei astfel de erori
compilatorul furnizeaz un mesaj de eroare care ne indic natura i eventual cauza erorii
respective, ct i linia din fiierul surs n care apare. Nu ntotdeauna mesajul oferit de
compilator este unul explicit. De multe ori ni se indic un mesaj de eroare, oarecum incorect,
genernd confuzie i ngreunnd depana-rea. Acest lucru se datoreaz unor erori care sunt
consecine ale altor erori nedetectate anterior.
Erorile de algoritm sunt mai greu de detectat dect celelalte dou tipuri prezentate
anterior, datorit faptului c sistemul nu mai ofer nici un fel de mesaje de avertizare. Din
punctul de vedere al SGBD-ului, programul funcioneaz corect, utilizatorul, fiind cel nemulumit
de rezultatele obinute.
Erorile de utilizare sunt acele erori datorate folosirii incorecte a sistemului, chiar dac el este
corect conceput.
Sistemul informatic trebuie s fie ct maibine protejat contra unor astfel de erori, adic:
s nu permit utilizatorului introducerea unor date greite, lucru posibil prin
implementarea unor proceduri de validare ct mai performante, mai compete;
s pun la dispoziia utilizatorului numai acele opiunicare au sens la un moment dat
(celelalte s fie dezactivate);
s avertizeze utilizatorul n cazul detectrii inteniei de execuie a unor operaii suspecte
a fi greite (cele despre care avem certitudinea c sunt greite s nu fie permise deloc);
s ofere ct mai multe informaii de ajutor prin intermediul unul subsistem de ajutor
permanent;
s posede o documentaiect mai clar, explicit, complet, la nivelul celui mai slab
pregtit utilizator etc.

136

Cu toate msurile de precauie luate de proiectant aceste erori nu pot fi eliminate complet
datorit acelor situaii de natur subiectiv, care nu pot fi controlate n totalitatede sistem, ci se
bazeaz, total sau parial, pe gndirea utilizatorului.
Un alt criteriu de clasificare a erorilor dintr-un sistem informatic este acela al nivelului la care
apar aceste erori.
Din acest punct de vedere putem avea urmtoarele tipuri de erori:
la nivelul sistemului de operare aceste erori se datoreaz configurrii greite a
sistemului de operare sau SGBD-ului, sau incompatibilitii dintre acestea
n interiorul modulelor, programelor independente-pot fi erori de compilare, de
rulare sau de algoritm i pot fi depistate prin rularea independent a modului respectiv;
la nivelul sistemului de ansamblu sunt erorile ce in de legtura dintre module i se
obin atunci cnd fiecare modul n parte lucreaz bine, dar cnd modulele sunt
ncorporate n sistemul integrat ntre ele apar incompatibiliti;
erorile sau neajunsurile de proiectare sunt erori ce in de concepia de ansamblu a
sistemului.
Un exemplu de astfel de erori, este omiterea unui cmp la proiectarea unei baze de date,
cmp n care urmau s fie memorate date necesare sistemului. Aceste erori sunt mai mult
neajunsuri ale sistemului informatic. Ele apar mai ales la ncercarea de adugare a unei noi
faciliti sistemului, care solicit date noi, neprevzute la proiectare, sau care nu se potrivete cu
metodele i tehnicile folosite n sistem.
Efortul necesar eliminrii unei erori este direct proporional cu nivelul erorii respective. Cu
alte cuvinte, cu ct nivelul la care apare eroarea este mai ridicat, cu att efortul de detectare i
de nlturare a sa este mai mare.
Testarea este efectuat, de regul, de personal specializat, care coordoneaz ntreaga
activitate.
La testare un rol important revine efului echipei de programare care trebuie s
integreze fiecare modul testat separat i apoi s testeze ntregul program. ntotdeauna testarea
va produce mai multe versiuni de module i de produse program, ultima fiind cea acceptat. La
fiecare versiune se face o evaluare i se opereaz corecia.
Testarea nu se ncheie dect atunci cnd se efectueaz lansarea prelucrrii de ctre
ntreaga aplicaie informatic cu un set complet de date. Acest set va include toate datele
posibile, corecte i eronate pentru a urmri reacia ntregului pachet de programe. n aceast
testare global se urmrete: validarea datelor de intrare i a rezultatelor, dialogul din sistemul
informatic, modul de operare la execuie. Se urmresc att aspectele formale ct i cele de
fond.
137

n literatura de specialitate sunt enumerate apte categorii de teste ale softului. Acestea
se difereniaz n funcie de modul n care acestea angajeaz tehnici dinamice sau statice,
precum i n funcie de modul de efectuare, automat sau manual.
Testarea static nseamn verificarea programelor surs fr ca acestea s fie executate, iar
cea dinamic nseamn i execuia programului surs.
Testarea automat este efectuat sub controlul calculatorului, n timp ce testarea manual se
desfoar sub controlul omului.
Sintetic, cele apte categorii de teste sunt redate n tabelul de mai jos:
Tip testare

Manual

Static
Dinamic

Examinri
Execuia de prob
Verificare de birou

Automat
Validarea sintactic
Testarea pe componente
Testarea integritii
Testarea sistemului

Examinrile sunt activiti prestate de grupuri de persoane cu scopul depistrii manuale a

apariiei unor erori binecunoscute n codurile programelor surs. Prin urmrirea atent a
instruciunilor programelor surs se depisteaz ntre 60 i 90% dintre erorile ce pot aprea n
acestea.
Execuia de prob, spre deosebire de examinarea liniilor programelor surs, care nu urmrete
i efectul fiecrei instruciuni, i propune s descopere erorile regsite n fiecare cod al
programului surs. Execuia de prob trebuie efectuat ct mai des, pe parcursul finalizrii unor
pri din lucrare(program). Rolul execuiei de prob este de a depista, i nu de a corecta erori.
Verificarea de birou este un proces informal, prin care programatorul sau o alt persoan care
nelege logica programului l parcurge, linie cu linie, cu un creion i o foaie de hrtie. Verificarea
nu presupune neaparat i execuia pe calculator, ci programatorul urmreste cu atenie efectul
fiecrei instruciuni a programului.
Validarea sintactic este singura tehnic de verificare automat static executat, de regul,
de ctre compilatoare. Rolul acestora este de a scoate la iveal erorile programului surs fr
ns a-l executa. Toate celelalte tehnici automate presupun i execuia codului instruciunilor.
Testarea pe componente este, deseori, cunoscut i ca testarea modulelor, deoarece fiecare
modul este testat de sine stttor.

138

Testarea integritii este o continuare a celei descrise anterior, ntruct ea se efectueaz cu

scopul verificrii modului n care se intercondiioneaz modulele, cu alte cuvinte se testeaz un
grup de module. Testarea integritii este gradual. n primul rnd, se testeaz modulul
coordonator, adic modulul-rdcina dintr-o structur arborescent, i doar unul dintre modulele
subordonate. Dup ce sunt testate modulele subordonate aflate pe acelai nivel, se efectueaz
trecerea la alt nivel, inferior celui anterior. n final, se testeaz tot programul. n mod similar se
va proceda cu ntregul sistem.
Testarea sistemului difer de cele descrise anterior prin faptul c n locul modulelor se
testeaz programele. Operaiunea este efectuat de personalul specializat n sisteme
informatice, sub coordonarea efului de proiect, sau de ctre utilizatori, sub controlul
specialitilor n informatic.
Dup ce testele sistemului au fost ncununate cu succes, sistemul este supus testrii de
acceptare, ntr-un mediu similar celui n care va fi pus n funciune i de ctre persoanele care l
vor ntrebuina. Un test complet de acceptare const n efectuarea testrii alfa i a testrii beta.
Testarea alfa utilizeaz date reprezentative, dar nereale, iar testarea beta se bazeaz pe date
reale i se execut n mediul curent, concret de lucru al utilizatorului.
Testarea alfa, cuprinde cteva teste edificatoare, dupa cum urmeaz :
testarea regenerrii sau refacerii foreaza execuia softului astfel nct s nregistreze
eecuri pentru a se verifica modul n care sistemul revine la normal ;
testarea securitii verific dac mecanismele de protecie aflate n sistem acioneaz
corespunzator mpotriva posibilelor atacuri ;
testarea la suprasolicitri determin modul n care sistemul execut operaiunile n
condiii de lucru diferite (cu configuraii de echipamente variate, cu anumite reele,
sisteme de operare .a.).
Testarea beta se deruleaz cu exerciii proprii utilizatorilor i cu datele concrete ale acestora. Ea
este un fel de repetiie general naintea instalrii.
Posibilele erori ale softului se pot datora :
incorectei contorizri a numrului de execuii ale unor bucle ;
introducerii incomplete a datelor ;
realizrii unor interfee eronate ntre module;
depirii dimensiunilor unor tablouri(masive) de date .a.
Pentru aprecierea calitii softului s-au propus mai muli indicatori :
rata defectelor pe or, zi, sptamn sau lun ;
139

rata defectelor pe echipamentele de baz ale softului;

timpul mediu ntre dou defeciuni;
mrimea zonei afectate de defecte;
numrul compilrilor sau al execuiilor unor componente ale sistemului care
funcioneaz corect din prima ncercare ;
defecte cumulate pe versiune;
oportunitatea rspunsului la defecte sau a timpului afectat ndeprtrii lor ;
satisfacia beneficiarului privind calitatea interveniei pentru remedierea defectelor soft.
Din toate aceste modaliti de evaluare, cantitativ i calitativ, rezult c preocuprile pentru
utilizarea unui soft de calitate trebuie s existe la toate nivelurile ierarhice ale organizaiei.

5.1.2 Instalarea sistemului

Aceast faz asigur verificarea funcionalitii sistemului cu date reale, motiv pentru care se pot
folosi anumite tactici i strategii n funcie de succesiunea de implementare a componentelor
noului sistem.
Strategiile de implementare presupun compararea vechiului sistem cu cel proiectat sau cu un alt
sistem informatic luat drept etalon.
n funcie de aceste elemente funcionarea experimental poate funciona n cinci variante.
1)Implementarea direct cu date curente a sistemului proiectat, presupune renunarea la
vechiul sistem brusc, n vederea reducerii termenului i a minimizrii cheltuielilor cu
implementarea. Avantajele acestei metode sunt costul mai sczut i o certitudine a
implementrii, n schimb riscurile sunt mai mari, datorit faptului c activitatea sistemului
economic se bazeaz acum pe sistemul informatic, iar o defeciune n acesta din urm putnd
duce la blocarea activitii. De aceea aceast strategie nu se recomand n cazul activitilor
critice, n flux continuu, care nu suport ntrzieri.

Vechiul sistem
Noul sistem

2) Implementarea paralel se face cu date curente sau anterioare pentru a se realiza o

comparaie ntre sistemul vechi fa de cel nou, sau ntre noul sistem i sistemul etalon. Aceast
strategie asigur un risc minim pentru beneficiar, deoarece eventualele neajunsuri n
funcionarea sistemului informatic nu conduc la blocarea activitii din unitatea economic, n

140

schimb este foarte costisitoare, toacmai datorit faptului c, pentru o perioad de timp trebuie
suportate costurile funcionrii ambelor sisteme.

Vechiul sistem
Noul sistem
3) Implementarea pilotat urmrete lansarea n experimentare a sistemului proiectat ncepnd
cu acele subsisteme ce au frecven maxim de utilizare, folosindu-se date din perioade
anterioare i curente. Sistemul informatic se instaleaz pe o unitate pilot, mai mic dect cea
real, dar care are caracteristicile definitorii ale acesteia. Aceast strategie se ncadreaz ntre
cele dou anterioare, att din punctul de vedere al costurilor, ct i al riscurilor.

Unitate pilot
Vechiul sistem
Noul sistem
4) Implementarea compartimental este utilizabil n unitile economice n care structurile
organizatorice prezint autonomie prin prisma fluxurilor informaionale.
n aceast variant condiia esenial o constituie realizarea anterioar a proiectrii de ansamblu
i a celei de detaliu pe compartimente, caz n care rezultatele implementrii pot fi comensurate
direct pe structurile organizatorice implicate.
5) Implementarea combinat poate fi abordat datorit avantajelor pe care le prezint celelalte
variante prin folosirea implementrii paralele cu cea pilotat.
Alegerea strategiei de implementare depinde de natura activitii desfurate n sistemul
informatizat, de disponibilitaile materiale ale beneficiarului, de riscurile ce pot i se accept a fi
asumate de beneficiar etc.
5.1.3 Verificarea performanelor sistemului informatic proiectat
Aceast faz presupune exploatarea efectiv a sistemului cu date reale n vederea
ndeplinirii parametrilor proiectai, a termenelor de execuie i duratei de exploatare.
n finalul acestei faze se face evaluarea sistemului i validarea rezultatelor obinute, pentru a
verifica n ce msur sunt satisfcute obiectivele propuse i dac rezultatele noului sistem
justific cheltuielile fcute cu introducerea i realizarea lui.

141

Funcionarea sistemului depinde de specificaiile logice, care evideniaz anumite

aspecte de natur logic ale funciilor sistemului (legturi ntre intrri i ieiri, consideraii asupra
volumului de date i a frexvenei lor, decizii de actualizare i de ntreinere, modul de operare),
precum i de specificaiile fizice care n mod cert sunt mai importante pentru operatori.
Interpretarea i transpunerea corect a specificaiilor logice pot s conduc la
ndeplinirea ateptrilor scontate pentru viitor, n ciclul de via al noului sistem, referitoare la
ntreinere, noile interfae lae sistemului, realocarea de funcii n cadrul firmei etc, soite de
reorganizarea corespunztoare de personal calificat.
Evaluarea sistemului se face pe baza specificaiilor logice i fizice. Specificaiile fizice
au n vedere volumul, frecvena, acurateea, i eroarea informaiilor. Specificaiile logice conin
rareori indicatori necesari pentru evaluarea sistemului, ns arat modul n care sunt corelate
elementele resursei de informare i evideniaz unde i cnd funcioneaz aceste legturi.
De exemplu, dac specificaiile logice arat c prelucrarea poate s nceap numai
dup ce s-a strns un numr suficient de mare de facturi, acest fapt ne ajut s observm ct
de bine este satisfcut acest criteriu i cnd este rezonabil testarea pentru prelucrarea
facturilor.
De asemenea, detaliile legturilor logice, cum ar fi succesiunea de intrri-ieiri sau de invocri
de module, ne ajut s descoperim de unde provine ineficiena.
Pe baza datelor provenite din exploaterea sistemului informatic, se determin eficiena
economic i se cuantific raportul ntre performan i cost.
Indicatorii eficienei economice se calculeaz n toate etapele de realizare a sistemului
informatic, acordndu-se o atenie deosebit la sfritul primului an de exploatare efectiv.
n etapa de implementare se corecteaz indicatorii eficienei economice estimai, n
timp ce n etapa de exploatare efectiv se calculeaz eficiena economic real pe baza
rezultatelor obinute de unitatea beneficiar.
5.1.4 Elaborarea documentaiei de utilizare a sistemului informatic proiectat.
n funcie de modul de implementare a sistemului, pot apare anumite modificri n
concepia acestuia, ca urmare a unor neajunsuri semnalate. Aceste modificri trebuie operate n
structura sistemului proiectat i n documentaia acestuia pentru a evita eventualele dificulti n
exploatarea i ntreinerea ulterioar.
La terminarea fiecrei faze de dezvoltare a proiectului, liderul de proiect redacteaz un
raport care detaliaz activitile, constatrile i rezultatele acelei faze, precum i planurile pentru
fazele urmtoare, document ce va fi supus spre avizare de ctre beneficiar.
Documentaia se elaboreaz la momente specifice n timpul realizrii proiectului, fie ca
urmare a directivelor utilizate, care n general sunt proceduri bazate pe documentaie.

142

Definitivarea ntregii documentaii de utilizare i exploatare a sistemului se concretizeaz n

ntocmirea manualului de prezentare, utilizare i operare.
Manualul de prezentare cuprinde concepia general a sistemului i o prezentare
succint a aplicaiilor componente, fcndu-se precizri n legtur cu restriciile i limitele
sistemului sau aplicaiilor, inclusiv performanele i posibilitile de extindere a acestora.
Manualul de utilizare este ntocmit pentru fiecare aplicaie, i asigur descrierea
general a aplicaiei, datele de intrare, condiiile de validare, restriciile i erorile ce pot apare,
condiiile de reluare, i se adreseaz personalului implicat n utilizarea noului sistem.
Manualul de operare conine informaii referitoare la exploatarea efectiv a sistemului
proiectat prin intermediul sistemului de calcul.
5.2 Exploatarea i ntreinerea sistemului informatic
5.2.1 Exploatarea sistemului informatic
Dup ce implementarea a luat sfrit, ncepe etapa de exploatare i ntreinere a
sistemului informatic. Acum sistemul informatic funcioneaz la parametri normali prevzui de
proiectani. Activitatea de exploatare se reduce la execuia curent a operaiilor de culegere a
datelor, transmitere, validare i prelucrare a acestora, construirea i consultarea situaiilor de
informare-raportare.
Exploatarea curent i meninerea n funciune a sistemului informatic presupun punerea n
stare operaional a calculatorului i a perifericelor, dup care se continu cu urmtoarele
operaii:
restaurarea bibliotecilor de programe i a bazei de date specifice noului sistem de pe
copiile de siguran obinute la prelucrarea precedent;
lansarea n execuie a programelor pentru crearea i actualizarea bazelor de date,
obinerea listelor de control i eliminarea erorilor;
exploatarea bazei de date n vederea obinerii situaiilor de ieire;
verificarea corectitudinii rezultatelor obinute prin control de verosimilitate sau sondaj;
stocarea pe dischete a ultimei versiuni a bazei de date n vederea conservrii acestora
pn la prelucrarea urmtoare.
n funcie de experiena dobndit n perioada exploatrii noului sistem i de rezultatele
obinute ca urmare a informatizrii activitii unitii beneficiare se pot efectua reorganizri n
structura serviciilor funcionale, prin trecerea anumitor activiti dintr-un compartiment ntr-altul,
reconsiderarea unor centre de decizie etc.

143

Exploatarea curent i meninerea n funciune a sistemelor informatice, asigur

funcionarea acestuia pe toat durata lui de execuie. Ea nceteaz n situaia n care se renun
la sistemul existent n funciune pentru a se trece la utilizarea altui sistem mai evoluat i eficient.
5.2.2 Procesul de ntreinere a sistemelor informatice
Din totalul cheltuielilor generate de sistemele informaionale ale unitilor, cea mai mare
parte revine etapei de ntreinere, i ca atare, personalul antrenat n ntreinere este cel mai
numeros. ntreinerea ncepe odat cu instalarea sistemului i se refer nu numai la
echipamente, ci i la software i la procedurile economice utilizate pe timpul exploatrii
aplicaiilor din sistem.
ntreinerea sistemului informatic const n totalul activitilor desfurate pentru
asigurarea funcionrii sistemului la parametri normali, corectarea, eliminarea tuturor erorilor
care apar pe parcurs, dar i introducerea n sistem a unor mbuntiri, perfecionri,
modernizri etc., menite s creasc nivelul parametrilor de funcionare ai sistemului economic.
Un aspect important se refer la durata etapei de ntreinere, dup unele preri ar fi de
5 ani, dup altele 10 sau mai muli. Rspunsul poate varia de la un caz la altul, tendina fiind de
cretere a perioadei de ntreinere i implicit a costurilor aferente.
Pe timpul ntreinerii un grup de persoane se va ocupa de colectarea cererilor de ntreinere
lansate de utilizatori sau de alte pri implicate n exploatarea sistemului sau verificarea modului
n care acesta funcioneaz.Activitile implicate de ntreinerea sistemului sunt:
obinerea cererilor de ntreinere;
transformarea cererilor n propuneri de schimbri;
proiectarea schimbrilor;
implementarea schimbrilor.
Perfecionarea sistemului informatic presupune:
folosirea de tehnic de calcul care s permit nregistrarea direct a datelor de intrare
la locul i-n momentul producerii lor;
perfecionarea sistemului de operare prin optimizarea programelor i a tehnicii de
operare;
optimizarea i parametrizarea programelor care s asigure portabilitatea acestora;
utilizarea reelelor de calculatoare pentru realizarea obiectivelor din unitatea economic
beneficiar.
ntruct cheltuielile de ntreinere au o pondere substanial n structura costurilor totale ale
sistemelor, considerm relevant prezentarea tipurilor de ntreinere: corectiv, adaptativ,
perfectiv, conform figurii 5.2

144

12%

5%

Adaptiva

8%

Perfectiva
Preventiva
Corectiva

75%
Fig. 6.2 Ponderile tipurilor de activitate de ntreinere n
totalul activitii dentreinere a sistemelor aferente

ntreinerea corectiv const n efectuarea unor lucrri de reparaii pentru ndeprtarea

unor defecte produse n timpul proiectrii, scrierii programelor sau implementrii sistemului. n
majoritatea cazurilor, ntreinerea corectiv intervine imediat ce se pune n funciune noul sistem
sau o component a acestuia. Ct timp o astfel de ntreinere i propune doar s ndeprteze
defecte, ea nu adaug valoare dect ntr-o pondere derizorie, n pofida celor 75 de procente
alocate ntreinerilor corective din totalul activittilor de ntreinere a sistemului.
ntreinerea adaptativ presupune efectuarea unor schimbri n sistem, condiionate de:
intenia de mbuntire a performanelor funcionale; adaptarea la schimbrile organizaionale;
deplasarea sferei de activitate a unitii n alt mediu.
Dac ntreinerea corectiv presupune o intervenie ct mai urgent n urma sesizrilor
venite din sistem, cea adaptiv nu este la fel de presant, ntruct factorii care o condiioneaz
nu au apariii spontane. O alt diferen const n faptul c ntreinerea adaptiv, spre deosebire
de cea corectiv, adaug valoare organizaiei.
ntreinerea perfectiv are ca scop efectuarea unor schimbri pentru mbuntirea
diverselor prelucrri, modificarea cu scopul folosirii mai uoare a interfeelor sau pentru a i se
aduga noi elemente, care ns nu sunt strict necesare. O astfel de operaiune de ntreinere
constituie mai curnd o dezvoltare a sistemului i face parte din categoria activitilor care
adaug valoare organizaiei.
ntreinerea preventiv se efectueaz cu scopul diminurii substaniale a posibilitilor
de defectare a sistemului, adaug valoare organizaiei.
Costurile mentenanei unui sistem sunt influenate de cteva elemente principale:
n fazele de evaluare / proiectare nu pot fi luate n considerare toate scenariile privind
funcionarea sistemului;
un sistem mare este proiectat i implementat de ctre mai multe echipe, n perioade
diferite, ceea ce implic o bun coordonare a activitii lor i poate conduce la
145

generarea unor soluii a cror integrare ridic uneori probleme n timpul exploatrii;
dezvoltarea unui sistem informatic este un proces de durat i pe parcursul proiectrii i
implementrii pot s apar modificri majore n ceea ce privete : legislaia,
performanele echipamentelor i produselor programului, orientarea activitii
organizaiei, forma de proprietate, strategia managerial;
personalul care deservete sistemul, ctig experien i nelege din ce n ce mai
bine ce ar trebui s fac, uneori n opoziie cu ce face.
Activitatea de mentenan trebuie evaluat pentru a observa dac, la un moment dat,
cheltuielile implicate nu depesc limitele acceptabile. Dac la un moment dat se constat c
beneficiarele sunt puternic afectate de cheltuielile cu mentenana, se poate concluziona c
sistemul nu mai rspunde necesitilor i este necesar nlocuirea sa parial sau total. n felul
acesta se reia ciclul de via al dezvoltrii sistemului.
5.2.3 Documentaia necesar exploatrii i ntreinerii sistemului informatic
Exploatarea noului sistem informatic se va realiza conform instruciunilor de exploatare
prevzute n manualul de utilizare. Aceste instruciuni se adreseaz n principal utilizatorilor
finali, adic beneficiarilor propriu-zii ai sistemului informatic i pot fi completate cu procedurile
de autodocumentare cuprinse n produsul program.
Manualul de utilizare i exploatare cuprinde urmtoarele instruciuni de utilizare i exploatare:
Instruciuni de utilizare
- proceduri de codificare a datelor prin care se dau instruciuni despre modul de
ntocmire a codurilor. Aici se explic sistemul de codificare utilizat i structura codurilor.
De asemenea se precizeaz criteriile de validare pentru fiecare cod i eventualele
codificri automate pe care le face sistemul;
- proceduri de ncrcare/validare date, prin care se dau instruciuni despre popularea
coleciilor de date. Aici se precizeaz documentele primare din care se preiau datelor i
modul de completare al acestora. Prin comparaie se prezint machetele de intrare i
videoformatele aferente documentelor primare. Se precizeaz i corelaiile care trebuie
s existe ntre diferitele date ncrcate. Toate aceste instruciuni sunt utile utilizatorului
pentru actualizarea datelor din coleciile de date. Pentru alegerea coleciei de date pe
care se va lucra, precum i a operaiei care se va efectua, utilizare a sistemului de
meniuri oferit de produsul program;
- proceduri de obinere a situaiilor de ieire, prin care se dau instruciuni despre modul
de afiare i interpretare a rapoartelor, listelor etc. Se prezint pentru fiecare situaie de
ieire macheta, coninutul, periodicitatea de obinere i se dau exemple. Instruiunile
vizeaz nu numai modul de obinere a situaiilor de ieire, dar i interpretarea acestora.
146

Se precizeaz semnificaia datelor coninute n situaia de ieire i eventualele corelaii

dintre date i cheile de control.. n final se indic modul de difuzare i arhivare a
situaiilor de ieire;
- alte proceduri speciale prin care se dau instruciuni despre eventualel conversii,
interfee, comunicaii cerute de produsul program.

Instruciuni de exploatare
- ealonarea n timp a procedurilor utilizate. Rezultatul este un grafic de exploatare a
procedurilor care trebuie s semene ct mai mult cu sistemul de meniuri al produsului
program. Ambele trebuie s ghideze utilizatorul n exploatarea produsului program:
ordines operaiilor, succesiunea lor n timp, semnificaia lor etc.
- proceduri privind datele de intrare. Se dau instruciuni privind primirea, controlul,
restituirea i pstrarea documentelor din care se preiau datele de intrare. De
asemenea, se indic modul de pregtire a datelor de intrare pentru ncrcare: reguli de
ncrcare, de validare, de verificare.
Proceduri de asamblare lucrri. Se d o list a procedurilor automate i se dau legturile
dintre acestea. Se ajunge astfel la o schem funcional a procedurilor. Schema va oferi
variante de prelucrare i va indica faciliti i restricii de exploatare a produsului program.
Proceduri de operare. Se dau instruciuni privind pregtirea rulrii i apelului produsului program
(mod de apel i ieire, parol de acces, fiiere necesare etc). Se indic o list a mesajelor
aprute la exploatare, precum i modul de aciune al utilizatorului(rspunsuri, reluri etc). Se
dau indicaii privind operarea cu sistemul de meniuri, cu videoformatele i ferestrele produsului
program.
Proceduri privind situaiile de ieire. Se dau instruciuni privind obinerea rezultatului i
controlul de form i fond. Se indic numrul de exemplare necesare i suportul tehnic de
informaie pe care se va obine fiecare situaie de ieire. Se specific destinaia i modul de
arhivare a rapoartelor.
ntreinerea sistemului informatic va avea la baz documentaia ntocmit n fiecare faz de
realizare a acestuia. Documentaia astfel realizat va constitui, pe de o parte, un mijloc de
comunicare ntre diferitele categorii de personal de specialitate n informatic antrenate n
realizarea diferitelor etape de proiectare a sistemului, iar pe de alt parte, dup implementarea
acestuia va constitui suportul necesar ntreinerii sistemului de la specificaia de cerine pn la
planul de test i testarea final a acestuia, dintre care amintim:
Specificaiile de cerine ale sistemului;
Arhitectura general a sistemului cu evidenierea intrrilor, procedurilor de control i
validare a datelor, coleciile de date, procedurile de editare a situaiilor de
informare/raportare, ieirile sistemului, resursele hardware/software folosite etc.;
147

Arhitectura programelor i schemelor logice de realizare a fiecrui program;

Videoformatele de intrare/ieire;
Programele surs, listate i comentate;
Specificaiile de validare a datelor care descriu cum fiecare program e validat i cum se
leag informaiile de validare cu cerinele informaionale ale utilizatorilor;
Un ghid de ntreinere de sistem care descrie care pri din sistem depind de hardware
i care de software.

Teste de evaluare a cunotinelor

1. Fazele procesului de implementare a sistemelor informatice sunt:
a. realizarea i testarea programelor;
b. pregtirea locurilor de munc;
c. instalarea i testarea echipamentelor;
d. selectarea i instruirea personalului.
a. a+b+c+d;
b. a+c+d;
c. a+b+c
d. a+b+d
2. ntr-un sistem informatic se pot distinge urmtoarele tipuri de erori:
a. erori de sintax;
b. erori de execuie;
c. erori de utilizare;
d. erori de algoritm.
a. a+b+c+d;
b. a+c+d;
c. a+b+c;
d. a+b+d.
3. ntr-un sistem informatic pot aprea erori:
a. la nivelul sistemului de operare;
b. la nivelul sistemului de asamblu;
c. n interiorul modulelor;
d. la nivelul sistemului de supraveghere.
a. a+b+c+d;
b. a+c+d;
c. a+b+c;
d. a+b+d.
148

4. Testarea de acceptare a noului sistem informatic const n:

a. testarea utilizatorilor;
b. testarea regenerrii sau refacerii;
c. testarea securitii;
d. testarea la suprasolicitri;
a. a+b+c+d;
b. b+c+d;
c. a+b+c
d. a+b+d
5. Care din urmtoarele tipuri de ntreinere deine ponderea cea mai mare n totalul activitii
de ntreinere :
a. ntreinerea adaptiv;
b. ntreinerea perfectiv;
c. ntreinerea preventiv;
d. ntreinerea corectiv.
6. Planificarea proiectelor informatice are drept scop ndeplinirea obiectivelor proiectelor,
obiective precizate mai jos:
a) performan i calitate ;
b) ncadrarea n bugetul alocat;
c)ncadrarea n durata de realizare;
d) ncadrarea n planul de dezvoltare regional.
a. a+b+c+d;
b. b+c+d;
c. a+b+c;
d. a+b+d.

149

150

Capitolul 6
Aplicaiile sistemelor informatice
Obiective:
Familiarizarea cu utilizarea facilitilor unui mediu de programare i a unor programe de
exploatare a bazelor de date Access
Studierea comparativ i evaluarea critic a principalelor programe de eviden i raportare
financiar-contabil.
Utilizarea SGBD Access n tandem cu Visual Basic for Aplications pentru realizarea practic a
unei aplicaii funcionale
Cuvinte cheie:limbaj de programare, programare structural, programare modular,
programare dirijat de evenimente,linii de cod, variabile de memorie.
6.1 Selecia tehnicii de programare i a limbajului utilizat
Un program reprezint o succesiune de instruciuni , realizat n conformitate cu
regulile limbajului de programare folosit, care rezolv o anumit problem, ndeplinete o
anumit sarcin, printr-un anumit algoritm.
Scrierea unui anumit program nseamn stabilirea instruciunilor care alctuiesc
programul, a ordinii acestora n cadrul programului i transmiterea lor spre calculator.
n proiectarea de aplicaii se folosete tot mai mult programarea modular. Dac programarea
structural oferea un program care l dirija pe utilizator pas cu pas, fr posibilitatea alegerii altei
opiuni, programarea modular const dintrun ansamblu de subrutine (proceduri sau
subprograme) care pot fi apelate n ordinea dorit de utilizator.
Alegerea tehnicii de programare aparine programatorului care va ine cont de factorii
obiectivi (impui de realitatea care trebuie modelat) i subiectivi (dictai de experiena proprie
acumulat prin teme rezolvate n acelai domeniu care pot fi caracterizate ca asemntoare cu
proiectul curent de rezolvat).
Limbajele de programare au aprut i s-au dezvoltat n strns legtur cu evoluia
hardware-ului. n prezent, o larg rspndire au dobndit sistemele de gestiune a bazelor de
date, fundamentate pe limbaje de descriere a structurii bazei de date i pe limbaje de
manipulare sau interogare a bazei de date. Se poate afirma c generaia a cincea a
calculatoarelor determin apariia unor limbaje corespunztoare modului de programare
natural, solicitnd formarea unei noi generaii de programatori.
Sistemele orientate-obiect reunesc nsumarea unor avantaje obinute de SGBD care
interogheaz eficient datele i limbajele procedurale care permit calcule complexe. Bazele de
151

date orientate pe obiecte permit crearea de obiecte complexe, din componente simple, fiecare
avnd propriile atribute i comportamente.
Sistemul de gestiune al bazelor de date orientate pe obiect (SGBD-OO) are ca
principale obiective: modelarea superioar a datelor care se poate realiza prin:deschiderea ctre
noi aplicaii; facilitatea concepiei realizat prin posibiliti de generalizare i agregare a relaiilor;
evoluia ctre multimedia (sunet, imagine, texte); posibiliti de deducie superioar (ierarhie de
clase, motenire); ameliorarea interfeei cu utilizatorul; posibiliti de tratare pentru aspect
dinamic, integrarea descrierii structurale i comportamentale.
Un SGBD-OO trebuie s satisfac urmtoarele criterii fundamentale:
- S fie un sistem orientat pe obiecte;
- S indeplineasca cerinele unui sistem de gestiune a bazelor de date.
Arhitectura unui SGBD-OO trebuie s conin trei componente majore:
1. Gestionarul de obiecte care asigur interfaa dintre procesele sau prelucrrile
externe ale SGBD-OO.
2. Serverul de obiecte care este responsabil cu asigurarea serviciilor de baz ale
SGBD-urilor cum ar fi gestiunea tranzaciilor, gestiunea stocului de obiecte.
3. Stocul rezident de obiecte.
n prezent SGBD-OO sunt accesate n primul rnd prin limbajele de programare orientate pe
obiecte cum ar fi: C++, Visual Basic pentru aplicaii (VBA) Access, SQL etc.

ACCESS
C ++

SGBD -OO

SQL

VBA

Figura 6. 1 Corelarea diferitelor soluii de programare

SGBD-OO trebuie s posede un limbaj pentru baze de date pentru a putea permite accesul i
manipularea modelului de date obiect i regsirea i actualizarea obiectelor. n opoziie cu multe
SGBD convenionale limbajul pentru baze de date al SGBD-OO este parte integrant a
limbajului de programare orientat pe obiecte.
152

Limbajul pentru baze de date al SGBD-OO const din:

- Limbajul de definire a datelor (LDD) necesar pentru definirea schemei bazei de date.
El trebuie s permit definirea claselor, a legturilor de motenire, definirea metodelor care
specific comportamentul unui obiect;
- Limbajul de manipulare a datelor ( LMD) necesar pentru regsirea, crearea, tergerea
i actualizarea obiectelor individuale. n cadrul unui SCBD-OO acest lucru se realizeaz prin
mecanismul de transmitere a mesajelor .
- Limbajul pentru cereri necesar pentru regsirea subseturilor unei baze de date i
obiectelor individuale. Limbajul de cerere se bazeaz pe transmitere de mesaje pentru
selectarea i regasirea obiectelor.
Alturi de modelul programarii orientate spre obiecte a fost dezvoltat i modelul programrii
conduse de evenimente.
Conform acestui model un program reprezint un ansamblu de proceduri care nu sunt apelate
dup o anumit regul temporal, ci sunt lansate n execuie numai atunci cnd n sistem apar
anumite evenimente. Prin urmare, dac n modelul clasic programarea era de tipul:
Vezi dac... i dac da execut...
n modelul programrii conduse de evenimente un program este o succesiune de secvente de
tipul:
Dac apare evenimentul execut ...
Apariia evenimentelor este arbitrar pentru programul respectiv, el fiind nvat cum s
rspund atunci cnd survin acestea.
Programarea n Visual Basic pentru aplicaii (VBA) este diferit de programarea in
limbajele procedurale cu programe liniare i continue, deoarece n acest caz programele sunt
orientate spre obiecte i conduse de evenimente, ceea ce presupune c un program este
mprit n fragmente (blocuri) ataate unui buton sau unei pictograme pentru a trata anumite
evenimente.
O dat cu avntul luat de mediile de dezvoltare de programe au aprut multe unelte din
ce n ce mai complexe, care s ajute la scrierea, mai rapid a programelor, s preia sarcinile de
rutin ale programatorilor i s contribuie la organizarea muncii acestora. Unele dintre aceste
unelte permit programatorilor s specifice n mod interactiv diferite opiuni i s construiasca tot
in mod interactiv diferite elemente, urmnd ca pe baza acestora s fie generate programe.
Aceste unelte care permit scrierea programelor ntr-un mod cvasi-interactiv au condus
la un nou stil de programare numit programare vizuala. Prin urmare, programarea vizual const
, de fapt, n folosirea unor utilitare care permit programatorilor s nlocuiasc, acolo unde este
posibil, scrierea direct a codului cu specificarea interactiv a opiunilor corespunzatoare.

153

Dintre sistemele de gestiune a bazelor de date existente astzi, Access este unul dintre cele mai
complete i performante. El nu este un simplu SGBD, ci este un mediu complex de dezvoltare
de aplicaii pentru baze de date, construit pe principiile arhitecturii deschise. Access este
integrat n pachetul Microsoft Office, avnd faciliti corespunztoare de interaciune cu celelalte
module (Word, Excel, Outlook etc).
Access ncorporeaz un maximum de posibiliti de abordare a unei baze de date,
avnd integrate cele mai importante modele de proiectare a acesteia. Sistemul Access ofer un
set complet de instrumente, unele suficient de sofisticate pentru programatorii profesioniti,
altele uor de folosit de ctre utilizatorii noi.
Cu Access, orice utilizator i poate crea soluiile cele mai convenabile prin care
accesul, organizarea i distribuia informaiilor ntr-o organizaie se poate face mai uor i mai
sigur ca niciodat.
n Visual Basic pentru Aplicaii ncorporat n Access exist unelte vizuale pentru
construirea majoritii elementelor unei aplicaii, tabele, forme, interogri, rapoarte, controale,
module etc. De asemenea Visual Basic pentru Aplicaii conine o serie de ,,Vrajitori, care permit
construirea unor tipuri standard de elemente cu un minim de efort din partea utilizatorului.
Un program scris n VBA este construit din proceduri i funcii. Distingem momentul construirii
funciei de cel al apelului n vederea executrii.
Construirea funciei presupune urmtoarele etape:

definirea algoritmului de prelucrare a datelor ;

codificarea algoritmului n limbajul VBA;
introducerea i memorarea funciei ntr-un obiect tip modul;
compilarea funciei;
precizarea obiectului i a evenimentului care declaneaz executarea funciei.

Un modul este o colecie de declaraii i proceduri( de tip Function sau Sub) VBA, descrise
mpreun ca un ntreg i este structurat n dou seciuni:
seciunea de declaraii;
seciunea procedurilor.
Limbajul VBA este caracterizat prin:
este un subset al limbajului Microsoft Visual Basic;
este orientat pe obiecte;
este condus de evenimente.
ntr-un proiect VBA sunt identificabile urmtoarele componente:

154


Module standard (denumite iniial module de cod). Conin declaraii i
proceduri generale. Exist de asemenea i module care conin tratarea evenimentelor
specifice documentului de care este ataat proiectul.

Module de clas. Conin definirea obiectelor create de utilizator.

Forme. Conin definiiile dialogurilor din interfaa proiectat de utilizator ca i

codul program necesar controlrii dialogurilor.

Referine. ntr-un proiect este meninut lista altor proiecte, care sunt referite
n proiectul curent.
Un modul de cod poate ncepe cu o seciune de declaraii. Prin declaraii nelegem instruciuni
neexecutabile prin care se definesc constante, variabile i proceduri externe. Utiliznd Public,
Static, Private se precizeaz i domeniul de vizibilitate a entitilor definite.
Gestionarea (crearea, editarea, tergerea etc.) obiectelor dintr-un proiect se face prin comenzi
ale mediului VBA, care este prezentat ntr-o seciune separat.
6.1.1 Elementele componente ale sistemului Microsoft Access
Access este un sistem de gestiune a bazelor de date relaionale pentru Microsoft Office
care funcioneaz sub sistemul de operare Windows. Din punct de vedere al creatorului soft
realizarea sistemelor informatice este relativ facil.
Modelul relaional al datelor este obinut rapid prin aplicarea regulilor de trecere la
modelele semantice. Utilizarea datelor stocate ntr-un singur fiier (MDB) asigur o lips de
redundan a tabelelor simultan cu integritatea i accesibilitatea datelor.
Schema bazei de date este constituit din coleciile de tabele i poate fi exploatat prin
manipularea interogrilor. Baza acestor interogri o constituie limbajul standard SQL (Structured
Query Language).
Sistemul Access se bazeaz pe un sistem relaional definit ca un ansamblu format din
structura relaional a datelor i mulimea operatorilor relaionali.
Prin folosirea limbajului de programare Visual Basic pentru aplicaii (VBA) i prin
adugarea bibliotecilor legate dinamic (DLL), este posibil scrierea unor aplicaii care comunic
cu sistemul de gestiune a bazelor de date, trimind comenzi scrise n limbajul de manipulare a
datelor.
Sistemul Access are facilitatea de a exporta structuri de tabele, definiii de interogri,
formulare, rapoarte i module. De asemenea, poate s scrie direct n baza de date FoxPro,
dBASE, Paradox sau n foile de calcul de tip Lotus 1-2-3 sau Excel.

155

De asemenea, acest sistem poate manipula i date externe fie prin importul lor direct,
fie prin crearea unei legturi la baza de date extern, datele rmnnd n fiierele lor originale.
Construirea sistemelor informatice care modeleaz situaii reale face ca cerina
componentelor standard care pot fi reutilizate, s creasc. Pentru a rspunde acestor cerine,
utilizatorii Access au posibilitatea de a defini obiecte, entiti cu identitate proprie, care respect
tehnicile orientrii pe obiecte. Astfel, acest sistem lucreaz cu colecii de obiecte.
Interfaa Access permite monitorizarea modului de proiectare al cmpurilor, tabelelor i de
exprimare a relaiilor care formeaz structura unei baze de date. Prin intermediul formularelor,
interogrilor i rapoartelor se uureaz operaiile de extragere a datelor. Se va dezvolta ulterior
interfaa utilizator, aprofundnd proprietile i evenimentele controalelor, formelor i rapoartelor.
n cazul n care beneficiarul solicit activitatea simultan a mai multor utilizatori asupra bazei de
date, existnd n structura organizatoric staii de lucru nelipsite de conectare permanent,
Access reprezint o alegere corect datorit acceptrii duplicrii bazei de date i sincronizarea
acesteia. Prin filtrare i sortare se permite ca setul curent de nregistrri s fie limitat.
Access permite rspunsul rapid la o ntrebare formulat bazei de date. n momentul n
care se pornete la construcia unei interogri trebuie s existe o viziune de ansamblu asupra
datelor dorite a se regsi exprimate prin cmpuri, tabele, criteriile de selecie i eventual ordinea
de sortare.
Construirea unei interogri n Access reprezint un proces simplu i rapid de aezare a
tabelelor i a cmpurilor necesare pe o gril (Query by Example) care reprezint o modalitate
facil de regsire a datelor. Deoarece transferarea datelor din baza de date se poate cere n
regim text, fiecare rnd este considerat ca fiind o nregistrare iar caracterele care delimiteaz
sunt virgula sau marcajele tabulare.
Sistemul Access cuprinde urmtoarele componente principale (figura 6.2):

un modul VBA care include un limbaj procedural de programare independent, VBA

(Visual Basic for Applications), utilizabil pentru dezvoltarea de aplicaii;

un modul SGBD-R performant, care include dou dintre cele mai cunoscute limbaje de
prelucrare a datelor, QBE (Query-by-Example) i SQL (Structured Query Language); n
acest modul se creaz tabelele de date i se gestioneaz informaiile;

un limbaj macro procedural simplificat, cu ajutorul cruia se pot proiecta aanumitele

macrocomenzi, deosebit de utile n etapele de administrare a bazei de date;

un set de instrumente pentru dezvoltare rapid a interfeei baz de date utilizatori

obinuii (formulare, rapoarte, panouri de comand);

156

un set de instrumente pentru asigurarea interfeei Access alte medii (conversii de

date, transfer de date n/din, securitate, acces prin Web, compatibiliti etc.);

un set puternic de instrumente de asisten interactiv (wizards) pentru dezvoltarea

uoar a aplicaiilor.
Instrumente de gestionare
Queries, Forms, Reports
Relationships
QBE / SQL Language
Asisten
Wizards
Help

Macrocomenzi
Macros
language

Colecii de date
Utiliti
Conversii de date
Pagini de access Web
Securitate date
ntreinere fiiere

Module de aplicaii
VBA language

Fig.6.2 Elementele componente ale sistemului Microsoft Access

n Access, termenul de baz de date nu se refer numai la datele propriu-zise, ci
cuprinde i alte obiecte cum ar fi formularele, interogrile (cereri), rapoartele, panourile de
comand, macrocomenzile i modulele de aplicaii VBA.
O caracteristic specific, deosebit de alte SGBD cunoscute, este faptul c tabelele de date
mpreun cu toate obiectele de gestionare sunt memorate ntr-un singur fiier. Acest lucru
asigur un control mai eficient al aplicaiilor care privesc o anumit baz de date.

157

6.1.2 Caracteristici Visual Basic for Application (VBA)

Visual Basic for Application (VBA) reprezint o implementare a limbajului Microsoft
Visual Basic, fiind un limbaj de programare dirijat de evenimente. n acelai timp, se poate
preciza faptul c VBA este un limbaj interpretat.
VBA are asociat un mediu de dezvoltare care este integrat n aplicaii din pachetul Microsoft
Office, alte aplicaii Microsoft (Microsoft MapPoint, Microsoft Visio) i parial integrat n alte
aplicaii, cum ar fi, AutoCAD, WordPerfect.
VBA permite dezvoltarea de aplicaii n cadrul programelor amintite, putndu-se
controla aproape toate funcionalitile programului considerat, incluznd manipularea
elementelor de interfa cu utilizatorul, cum ar fi, meniuri i bare de instrumente, utilizarea
casetelor de dialog predefinite sau personalizate etc.
Programatorului i sunt oferite noi tipuri de date, posibiliti de compilare condiionat,
operaii OLE extinse. VBA permite ca tipurile definite de utilizator s cuprind la rndul lor alte
categorii (standard sau definite explicit) i ca datele returnate prin rspuns al funciilor s fie
corespunztoare acestor tipuri. Prin utilizarea tabloului de parametrii (ParamArray) dezvoltatorul
poate realiza funcii cu argumente opionale, funcii cu un numr variabil de argumente
opionale.
Supravegherea execuiei n faza de testare este posibil prin fereastra Watch existnd
posibiliti de anulare a comenzilor anterioare pe mai multe niveluri, reliefarea cuvintele cheie
prin selecia culorilor, precum i introducerea comentarilor, extrem de utile momentului depanrii
i dezvoltrii soft.
Avantajul VBA oferit beneficiarului de sistem rezult din cerinele moderate hard i
implicit costul echipamentelor. Cu un efort minimal persoanele cu sarcini de exploatare pot
interveni pentru personalizarea, modernizarea sistemului datorit programelor de asisten
disponibile implicit.
Conceptele de baz ale programrii n VBA sunt: obiectul, proprietatea, metoda,
evenimentul. Dintre obiectele bazei de date Access, modulul este singurul care conine
proceduri definite de utilizator i scrise n limbajul de programare VBA. n cadrul modulelor codul
este organizat n proceduri sau funcii. n general, un modul are urmtoarea structur:
Declaraii
Procedur sau funcie
..................................
Procedur sau funcie
Zona de declaraii este rezervat declarrii variabilelor i constantelor accesibile
158

pentru toate procedurile i funciile componente ale modulului i una sau mai multe proceduri
sau funcii.
Dup apartenena lor modulele se pot grupa n urmtoarele categorii (pot fi vizualizate prin
Object Browser):

module globale sau standard sunt accesibile ntregii aplicaii;

module specifice formularelor sau rapoartelor sunt accesibile numai formularelor

i rapoartelor n care au fost declarate;

module class permit definirea de module noi.

6.1.3 Editarea modulelor VBA
Pentru editarea modulelor, n fereastra Database, se selecteaz meniul Create,
eticheta Module din grupul Macros&Code (Fig. 6.3 )

Fig. 6.3
Scrierea codului din punct de vedere sintactic, se poate face cu caractere minuscule sau
majuscule. Att cuvintele cheie ct i cele utilizator sunt automat transcrise n forma n care au
fost declarate, dac sunt scrise corect. Editorul are, de asemenea, faciliti de colorare a
cuvintelor cheie, declaraiilor i comentariilor utilizator, frazelor eronate.
Comentariile incluse constituie linii de cod care nu se execut, dar care, faciliteaz nelegerea
programului. Pentru definirea comentariilor se utilizeaz un apostrof la nceputul
comentariului; n acest fel se pot scrie comentarii i dup o instruciune, pe acelai rnd.
(Fig.6.4)

159

Fig.6.4
Instruciunile se scriu, n general, cte una pe un rnd, ns exist i posibilitatea scrierii
a mai multor instruciuni pe acelai rnd, separate prin delimitatorul : .
Dac o instruciune se continu pe mai multe rnduri, se utilizeaz, la sfritul fiecruia, liniua
de subliniere _ , cu excepia rndului care o ncheie. (Fig.6.5)

Fig.6.5
Prin intermediul desfurtorului de obiecte, sistemul VBA evideniaz proprietile i
metodele posibile pentru un anumit obiect. Afiarea este contextual, adic are loc n momentul
scrierii n VBA a elementelor care caracterizeaz un anumit context. (Fig.6.6)

160

Fig.6.6
Proprietile descriu un obiect prin caracteristici cum ar fi: dimensiunea, culoarea, poziia
pe ecran i se stabilesc, de regul, n faza de proiectare, adic n momentul n care se
proiecteaz sau se modific formele.
Proprietile stabilite n faza de proiectare devin operaionale la prima lansare n execuie
a aplicaiei i rmn valabile pn la ncheierea execuiei aplicaiei sau pn la modificarea lor
prin program.
Metodele reprezint procedurile sau funciile care se execut pentru a informa un obiect
despre aciunile pe care le va efectua. Dac proprietile sunt date, metodele sunt cod. Spre
deosebire de proprieti, metodele pot fi executate numai n momentul rulrii programului, sau n
timpul unei sesiuni de depanare a programului.
Pe lng proprieti i metode, fiecare tip de obiect are prestabilit un numr de evenimente
posibile, dar cel puin unul.
Evenimentele se produc ca urmare a unei aciuni utilizatorului ori a execuiei unui
program sau pot fi declanate de calculator. Utilizatorul poate efectua aciuni ca: click sau dublu
click de mouse, acionarea unei taste, etc. n mod automat un eveniment poate fi declanat de o
procedur inclus n program. Pe de alt parte, evenimentele declaneaz procedurile. O astfel
de programare este denumit eventdriven, adic dirijat prin evenimente.
6.2 Elementele limbajului VBA
6.2.1 Tipuri de date
VBA este unul din limbajele de programare care impune, nainte de a manipula datele, s
specificm natura acestora.
Exist trei mari categorii de date: numerice, ir de caractere i speciale. ncadrarea unei date
ntruna din categorii este absolut necesar pentru a efectua calcule sau alte prelucrri. De
asemenea, VBA accept i o clasificare a datelor din punct de vedere al utilizatorului, i anume:
date standard (predefinite) i date utilizator.
161

n tabelul urmtor se prezint tipurile de date utilizate de Visual Basic. (Tabelul 6.7)
Tabelul 6.7
Tip de
date

Caracteristici

Double

Numr memorat pe 64 bii, virgul mobil, dubl precizie.

Valori posibile: de la 1,797*10308 pn la + 1,797*10308.

Single

Numr memorat pe 32 bii, virgul mobil, simpl precizie.

Valori posibile: de la 3,4*1038 pn la
+ 3,4*1038.

Currency

Numr memorat pe 64 bii. Sunt memorate 15 caractere la

stnga virgulei i 4 caractere la dreapta virgulei. Valori
posibile:
922337203685477,5808
pn
la
922337203685477,5807.

Byte

Numr ntreg pe 8 bii. Valori posibile: 0255.

Integer

Numr ntreg pe 16 bii. Valori posibile: 32768 pn la

32767.

Long

Numr ntreg pe 32 bii. Valori posibile:

2147483648 pn la 2147483647.

Boolean

Poate conine valoarea logic True (1) sau False (0).

Date

Poate conine date calendaristice i timp. Se utilizeaz

ntre #.

String

ir de caractere. Poate conine maximum 2 la puterea 31

de caractere. Se utilizeaz ntre .

Variant

Tip de date generic. O asemenea variabil se poate utiliza

pentru orice tip de date. Practic, toate variabilele utilizate
pot fi declarate de tip Variant. Este recomandat totui ca
s specificai tipul variabilei n momentul declarrii pentru
a nu fi create confuzii.

Object

Tip de date care refer un obiect. Pentru a asocia un

obiect propriuzis unei asemenea variabile trebuie s se
utilizeze i instruciunea Set.

162

6.2.2 Variabile i constante

Variabile
O variabil reprezint numele unei poriuni din memoria calculatorului n care sse stocheaz
temporar datele. O variabil poate conine o singur valoare la un moment dat dar care poate fi
modificat la aciunea utilizatorului sau prin program.
O variabil are un nume i conine un anumit tip de date pentru a o identifica la un moment dat
n memorie. Numele unei variabile poate avea maxim 256 caractere i trebuie s nceap cu un
caracter alfanumeric.
Declararea variabilelor
ntrun program, pentru a putea utiliza o variabil, aceasta trebuie declarat,
specificnd numele i tipul de date pe care l va conine. Exist dou moduri de a declara
variabilele: implicit i explicit.
Declararea implicit se face prin adugarea unui caracter specific la sfritul numelui
variabilei. Sufixurile utilizate sunt reprezentate n tabelul de mai jos. (Tabelul 6.8)
Tabelul 6.8
Sufix

Tip dat

Exemplu

Long

547 $

Single

547 !

Double

547 #

Currency

547 @

De exemplu, declararea variabilei Nr_marc n felul urmtor:

Nr_marc = 547
Arat c variabila Nr_marc este de tip Integer, dar declaraia:
Nr_marc = 547 #
impune variabilei Nr_marc tipul de dat Double.
Declararea explicit a variabilelor se face utiliznd instruciunea Dim la nceputul unei proceduri.
Formatul instruciunii este:
Dim <NumeVariabil> As <TipDat>
<NumeVariabil> este definit de ctre utilizator;
<TipDat> este specificat explicit, (nu se pot defini dou variabile cu acelai nume
ntro procedur).
163

Exemplu:
Dim Nr_marc As Integer
Dim Prenume
Dim Nume As String 20
Dim Adres As String
unde:

prima linie definete o variabil de tip integer;

a doua linie definete o variabil de tip variant;

a treia linie definete o variabil de tip ir de caracter ce conine maxim 20 de

caractere;

a patra linie definete o variabil ir de caracter cu lungimea cuprins ntre 0 i

65535 de caractere.
Domeniul unei variabile.Variabile locale i globale
Locul n care este plasat instruciunea de declarare a variabilei este important pentru
c specific modul n care se va lucra cu variabilele ntro aplicaie.
Modul n care se va lucra cu o variabil n cadrul unui program, sau durata ei de via,
sau sau zonele din program n care variabila este vizibil este cunosccut sub numele de
domeniul variabilei. Locul n care este declarat o variabil determin domeniul acesteia. VBA
este unul din limbajele care respect reguliile domeniului de valabilitate. Domeniul de valabilitate
al unei variabile VBA este determinat de dou elemente: locul n care declarm variabila n
cadrul procedurii i de instruciunile folosite pentru declarare.
Sintaxa general de declararea a unei variabile este urmtoarea:

Dim! Private! Public! Global! nume vb1as tip_date, nume vb2 as tip_date,.
Unde:
nume vbi este numele atribuit variabilei i;
as tip_date este unul din tipurile de date definite de utilizator.
Exist trei locuri diferite n care pot fi declarate variabilele:

nivel procedur sau funcie;

nivel form;

nivel modul.

Dac Dim este plasat la nceputul unei proceduri (dup declaraia Subnume_procedur),
atunci variabila declarat va cunoscut i va putea fi utilizat doar n procedura respectiv, fiind
o variabil local. Dac dorim ca variabilele s fie vizibile n toate procedurile dintrun modul,
vom plasa instruciunea Dim n seciunea general a modulului. (Fig. 6.9)
164

Fig. 6.9
Folosirea instruciunii Private n seciunea General a modulului determin vizibilitatea
variabilei n toate procedurile din modulul respective, nu i din alte module sau formuri. Nu se
poate folosi declaraia Private ntro procedur delimitat prin SubEnd Sub.
O variabil declarat Public sau Global la nceputul unui modul este vizibil din toate modulele
bazei de date. O astfel de variabil se numete variabil global. Nici aceste declaraii nu pot fi
folosite n proceduri delimitate prin Sub.End Sub.
Convenii de denumire a variabilelor
Ca i la numele de controale i pentru variabile se utilizeaz un prefix de 3 litere, care s indice
clar tipul de dat.
n tabelul 6.10 sunt prezentate prefixe utilizate pentru numele variabilei
Tabelul 6.10
Prefix

Tip dat

bln

Boolean

byt

Byte

cur

Currency

dte

Date

dbl

Double

int

Integer

lng

Long

obj

Object

sng

Single

str

String

vnt sau var

Variant
165

Exemple:
Dim lngDistan As Long
Dim objVedere As Object
Dim intLungime As Integer
Dim sngPret As Single
Dim strNume As String.
La declararea variabilelor de tip ir de caractere se poate ine seama i de lungimea
acestora, tiind c ea poate varia ntre 0 i 65400 de caractere. Variabila strNume poate avea
valoarea Ilie dar i Constantinescu. Exist situaii n care dorim s limitm lungimea textului
(s spunem c trebuie afiat ntro etichet de lungime fix), scop n care se utilizeaz opiunea
* astfel:
Dim strNume As String * 18
Indicnd c variabila strNume poate avea o lungime ntre 0 i 18 caractere.
Pentru a declara mai multe variabile de acelai tip se poate utiliza o singur instruciune Dim.
Astfel, n loc de:
Dim X As String
Dim Y As String
Dim Y As String
Se poate scrie:
Dim X As String, Y As String, Y As String
Dac se declar mai multe variabile printro singur instruciune Dim, ele pot fi i de
tipuri diferite:
Dim Z As String, Y As Long
Constante
Constantele sunt nume semnificative care in locul locul unor nume sau iruri de caractere i
care nui pot modifica valoarae pe parcursul unui program. Constantele se grupeaz n dou
categorii:

constante intrinseci sau definite de sistem care sunt furnizate de aplicaii sau
controale;

constante simbolice sau definite de utilizator.

VBA interpreteaz i atribuie automat tipurile de date pentru constantele numerice scrise de
utilizator, dar dac dorim ca o constant s aib un anumit tip de dat, trebuie, ca i variabilele,
s utilizm un sufix la scrierea constantei.
Constantele simbolice se pot declara explicit cu instruciunea Const care are urmtoarea
166

sintax:

Public! Private! Const nume constant As tip_dat = expresie

Exemplu:
Const Angajat = Manea Ion
Const Data_angaj = # 1/1 / 2002 #
Const Studii_super =
Constantele de tip String se scriu ntre ghilimele Manea Ion, 547
Constantele de tip Date se scriu ntre dou caractere # (diez).
Cnd ntre ghilimele nu este specificat nici un caracter avem un ir nul.
Domeniul de vizibilitate, att al constantelor, ct i al variabilelor, n funcie de modul de
declarare Privat sau Public, este prezentat sintetic n tabelul 6.11
Tabelul 6.11
Locul de declarare

Modul de declarare Privat

Modul de declarare Public

La nivelul procedurii

Constantele sunt vizibile Nu se pot declara constante

doar n cadrul procedurii n publice n cadrul unei proceduri
care apar

La nivelul modului

Variabilele sunt vizibile n Variabilele sunt vizibile pentru

cadrul modului n care apar
toate modulele.

6.2.3 Operatori
Pentru construirea diverselor expresii (matematice, logice, de comparare) tematice cu datele
coninute de program se utilizeaz operatorii.
Operatorii acceptai de VBA sunt de trei categorii: matemetici, de comparare, logici.

operatori matematici :
+ adunare
scdere
* nmulire
/ imprire returneaz partea ntreag
MOD mprire (returneaz numai restul)
^ exponent

operatori de comparare:
< mai mic
<= mai mic sau egal
> mai mare
>= mai mare sau egal
167

= egal
<> diferit

operatori logici:
o AND i
o OR sau
o NOT negaie
o XOR pentru sau exclusiv

operatori pentru concatenerea irurilor : &, +

ali operatori:
o IN pentru regsirea de valori n cadrul unei liste;
o LIKE pentru comparare cu caractere de nlocuire;
o BETWEEN pentru regsirea de valori n cadrul gamei;
o EQV pentru echivalarea logic a dou expresii;
o IMP pentru implicarea logic a dou expresii.
6.2.4 Proceduri/funcii
Procedurile reprezint secvene de instruciuni care realizeaz o prelucrare bine definit din
punct de vedere funcional. Procedurile sunt subprograme, la care un alt program face referire
prin numele lor.
Procedurile care nu returneaz nici o valoare sunt numite subrutine i au sintaxa:
[Static] [Private] Sub nume_procedur[(list argumente)]
[

<instruciuni>
End Sub

unde:
Static variabilele locale sunt memorate ntre dou execuii;
Private procedura este accesibil numai din interiorul modulului;
List argumente reprezint variabilele ce sunt transmise n momentul apelrii
procedurii;
Exit Sub foreaz ieirea din procedur.
Apelul unei proceduri se face astfel:
Call nume_procedur ([lista argumente])
sau
nume_procedur ([list argumente])
Procedurile care ntotdeauna returneaz o valoare se numesc funcii i au urmtoarea sintax:
168

[Static] [Private] Function nume_procedur [(list argumente)] [As Tip_data]

<instruciuni>
[ExitFunction]
<instructiuni>
End Function
unde:
As Tip _data tipul rezultatului returnat de ctre funcie.
Apelul unei funcii se poate face astfel:
Variabila=nume_funcie[(valoare_param_1, valoare_param_2,.)]

Variabila preia rezultatul returnat de funcie.

Funcii
O funcie reprezint o secven de instruciuni VBA care realizeaz o prelucrare bine
definit din punct de vedere funcional i care returneaz o valoare.
Deoarece funcia returneaz o valoare se poate considera c ea este egal cu valoarea pe care
o returneaz i, ca urmare, poate fi utilazat n expresii mai complicate.
Att funciile ct i procedurile constau din linii de cod bine definite de utilizator sau generate de
VBA. Deosebirea dintre o funcie i o procedur este c funcia returneaz o valoare pe cnd
procedura nu.
Sintaxa general a unei funcii este:
Rezultat = nume_funcie (list argumente)
ntre paranteze se scriu argumentele funciei, separate prin virgul. Prezena parantezelor i a
semnului egal sunt semnele care difereniaz funcia de procedur.
VBA fiind un mediu integrat de dezvoltare include dou categorii de funcii:

integrate (standard);

definite de utillizator.
Funciile integrate (standard)
VBA conine un numr mare de funcii integrate care pot fi utilizate pentru executarea
unor operaii, pentru care altfel ar trebui scrise secvene de cod. Diversitatea problemelor pe
169

care le soluioneaz, a determinat gruparea funciilor pe categorii.

Funcii pentru preluarea i afiarea datelor
Funciile ncorporate ale programului, InputBox() i MsgBox() permit efectuarea unor
operaii simple de intrare/ieire (I/O) prin utilizarea unor casete de dialog predefinite pe care le
putem adapta utiliznd o gam de pictograme i combinaii de butoane de rspuns.
Funcia InputBox() afieaz o invitaie ntro caset de dialog, ateapt ca utilizatorul s
introduc text sau s selecteze un buton, apoi returneaz coninutul casetei de text. Valoarea
introdus de ctre funcie este de tip Variant, fie de tip String, n funcie de varianta utilizat.
Sintaxa funciei este:
InputBox (<mesaj>, [<titlu>], [<val_implicit>, [<x>], [<y>], [<fisier_help>, <context>])
Singurul argument obligatoriu este primul mesaj. Acesta va fi o expresie de tip ir de caractere
(String) care invit utilizatorul s introduc ceva i va fi afiat lng caseta de text n care va
scrie utilizatorul.
Al doilea argument, titlu, este un ir de caractere afiat n bara de titlu a casetei de
dialog. Dac se omite, n bara de titlu nu se va afia nimic.
[<x>], [<y>] reprezint expresii numerice care specific distana pe orizontal, respectiv
pe vertical, a colului din stnga sus al casetei de dialog fa de colul din stnga sus al
ecranului. Dac se omite argumentul [<x>], trebuie s se omit i argumentul [<y>]. Dac
ambele argumente se omit, caseta de dialog va fi centrat pe orizotal, la aproximativ o treime
din nlimea ecranului fa de partea superioar.
Sintetizai sunt prezentai parametrii nstruciunii InputBox n tabelul 6.12
Tabelul 6.12
Parametru

Descriere

<mesaj>

ir de cractere afiat n fereastra InputBox. Pot fi

maximum 1024 de caractere. Dac se dorete
afiarea unui mesaj pe mai multe rnduri trebuie
intercalat caracterul <ENTER> adic CHR (13) la
sfritul rndului.

<titlu>

Titlul ferestei afiate (ir de caractere)

<val_implicit>

Valoarea implicit afiat de fereastra InputBox pentru

introducere (ir de caractere).
170

<x>

Poziia feresteri InputBox fa de marginea din stnga

a eranului (expresie numeric).

<y>

Poziia feresteri InputBox fa de marginea de sus a

eranului (expresie numeric).

<fiier_help>

Fiierul Help utilizat n cazul n care se folosete help

senzitiv la context (ir de caractere).

<context>

Numrul care exprim locul din fiierul Help care va fi

apelat.

Funcia MsgBox() afieaz un mesaj ntro caset de dialog i ateapt ca utilizatorul s

selecteze un buton. Funcia MsgBox() returneaz o valoare ntreag care indic butonul selectat
de utilizator.
Sintaxa funciei este:
MsgBox (<mesaj>, [<butoane>], [<titlu>, [<fisier_help>, <context>])
Mesaj este o expresie ir afiat ca mesaj n caseta de dialog.
Al doilea argument, titlu, este o expresie ir care apare n bara de titlu a casetei de
dialog.
Sintetizai sunt prezentai parametrii nstruciunii MsgBox n tabelul 6.13
Tabelul 6.13
Parametru

Descriere

<mesaj>

ir de cractere afiat n fereastra MsgBox. Pot fi

maximum 1024 de caractere. Dac se dorete afiarea
unui mesaj pe mai multe rnduri trebuie intercalat
caracterul <ENTER> adic CHR (13) la sfritul
rndului.

<titlu>

Titlul ferestei afiate (ir de caractere)

<butoane>

Butoanele i pictogramele afiate n fereastra MsgBox

(expresie numeric).

<fiier_help>

Fiierul Help utilizat n cazul n care se folosete help

senzitiv la context (ir de caractere).

<context>

Numrul care exprim locul din fiierul Help care va fi

apelat.

171

Constantele acceptate de parametrul butoane sunt prezentate n tabelul 6.14

Tabelul 6.14
Constant

Valoare

Explicaie

vbOKOnly

Afieaz numai un buton OK

vbOKCancel

Afieaz un buton OK i un buton

Cancel

vbAbortRetryIgnore

Afieaz un buton Abort (Abandon

n caz de eroare), Retry (Foreaz n
caz eroare), Ignore (Ignor eroarea).

vbYesNoCancel

Afieaz un buton Yes, un buton

No, un buton Cancel

vbYesNo

Afieaz un buton Yes, un buton

No.

vbRetryCancel

Afieaz un buton Retry, un buton

Cancel

vbCritical

16

Afieaz o pictograma Critical

vbQuestion

32

Afieaz un semn de ntrebare

vbExclamation

48

Afieaz un semn al exclamrii

vbInformation

64

Afieaz pictograma Information

Constantele ce pot fi returnate de instruciunea MsgBox sunt prezentate n tabelul 6.15

Tabelul 6.15
Constant

Valoare

Explicaie

vbOK

Butonul OK selectat

vbCancel

Butonul Cancel selectat

vbAbort

Butonul Abort selectat

vbRetry

Butonul Retry selectat

vbIgnore

Butonul Ignore selectat

vbYes

Butonul Yes selectat

vbNo

Butonul No selectat

Funcii numerice
Cuprind funcii matematice i trigonometrice, avnd ca argumente i ca rezultate valori
numerice. Cteva funcii reprezentative sunt cuprinse n tabelul 6.16. Sunt utilizate n calcule
matematice i inginereti.
172

Tabelul 6.16
Funcie

Descriere

Abs
Returneaz valoarea absolut a unei expresii
(<expresie_numeric>) numerice, sau a unui numr.
Exp
Returneaz valoarea constantei e ridicat la o putere
(<expresie_numeric>) (expresie numeric sau numr).
Int
Returneaz partea ntreag dintrun numr sau dintro
(<expresie_numeric>) expresie numeric.
Returneaz primul numr negativ mntreg mai mic sau
egal dect numrul specificat (sau numrul rezultat n
urma evalurii numerice)
Fix
Returneaz partea ntreag dintrun numr sau dintro
(<expresie_numeric>) expresie numeric.
Returneaz primul numr negativ ntreg mai mare sau
egal dect numrul specificat (sau numrul rezultat n
urma evalurii expresiei numerice)
Funcii pentru iruri de caractere (Tabelul 6.17)
Funcie

Descriere

Chr (<cod_caracter>)

Returneaz caracterul corespunztor codului specificat.

Len (<ir_cractere/variabil>)

Returneaz numrul de caractere al irului de caractere

specificat sau numrul de octei necesari pentru a stoca
coninutul unei variabile.

Space (numr)

Returneaz numrul de spaii specificate

Str (expresie_numeric)

Convertete rezultatul evalurii expresiei numerice dintre

paranteze ntrun ir de caractere

Val (ir_caractere)

Returneaz rezultatul evalurii irului de caractee

specificat, ntrun numr

Mid (ir_caractere, poziie_start, Extrage un ir de caractere dintrun alt ir de caractere.

lungimea)
ir_caractere irul de caractere din care se extrage;
poziie_start poziia din irul de caractere, de unde ncepe
extragerea;
lungimea numrul de caractere care se extrage.
173

Funcii pentru dat i or (Tabelul 6.17)

Funcii

Descriere

Date ()

Returneaz data sistemului

Day (<data_calendaristic>)

Returneaz numrul zilei din lun (131).

Month (<data_calendaristic>) Returneaz numrul lunii din an (112).

Year (<data_calendaristic>)

Returneaz anul.

Hour (<expresie_timp>)

Returneaz numrul orei din zi (023)

Minute (<expresie_timp>)

Returneaz numrul minutului dintro or (059).

Second (<expresie_timp>)

Returneaz numrul unei secunde dintrun minut (059).

Funcii pentru conversii (Tabelul 6.18)

Funcii

Descriere

Cbool (<expresie>)

Boolean

Cbyte (<expresie>)

Byte

Ccur (<expresie>)

Currency

Cdate (<expresie>)

Date

CDbl (<expresie>)

Double

Cdec (<expresie>)

Decimal

CINt (<expresie>)

Integer

CLng (<expresie>)

Long

CSng (<expresie>)

Single

CStr (<expresie>)

String

Cvar (<expresie>)

Variant

Funcii diverse (Tabelul 6.19)

Funcii

Discriere

IsNull (<expresie>)

Returneaz valoarea adevrat (TRUE) dac expresia

dintre paranteze conine valoarea NULL (date invalide)

IsError (<expresie>)

Returneaz valoarea adevrat (TRUE) dac expresia

dintre paranteze conine o eroare.

IsEmpty (<expresie>)

Returneaz valoarea adevrat (TRUE) dac expresia

dintre paranteze nu conine o valoare. NULL este
considerat valoare.

174

IsDate (<expresie>)

Returneaz valoarea adevrat (TRUE) dac expresia

dintre paranteze este compatibil cu o dat
calendaristic.

IsNumeric (<expresie>)

Returneaz valoarea adevrat (TRUE) dac expresia

dintre paranteze poate fi evaluat ca numr.

IsObject (<identificator>)

Returneaz valoarea adevrat (TRUE) dac

identificatorul dintre paranteze este de tip obiect.

Funcii definite de utillizator

Sintaxa:
Private Public] Function nume_functie [([ByRefByVal] param_1 as tip_date, )] [as
tip_date]
[instruciuni]
[nume_funcie=expresie]
.
[Exit Function]
[instruciuni]
[nume_funcie=expresie]
End Function
Unde:
Exit Function permite ieirea forat dintro funcie;
nume_funcie = expresie, permite asocierea unui rezultat numelui funciei. Acest
rezultat va fi returnat n momentul terminrii execuiei funciei.
Apelul unei funcii se poate face astfel:
Variabila = nume_funcie [(valoare_param_1, valoare_param_2, )]
Variabila preia rezultatul de funcie.
6.3. Structuri de control fundamentale n VBA
Programele VBA sunt programe a cror evoluie se modific n mod prestabilit, previzibil,
controlat. Aceste faciliti sunt posibile datorit structurilor de control care precizeaz ordinea n
care se vor executa instruciunile.
175

6.3.1Tipuri de structuri de control

Un progam structurat (concept introdus n anii 70) se bazeaz pe urmtoarele structuri de
control: secvenial, alternativ, repetitiv.
Structuri secveniale
n aceast structur, operaiile sunt executate cosecutiv, n ordinea n care sunt indicate n
schem, ordine n care vor fi stocate n memorie instruciunile main rezultate n urma
compilrii. Sunt foarte rare cazurile cnd un ntreg program este conceput utiliznd numai o
structur secvenial. (Fig.6.20)

Instruciune 1

Instruciune 2

Instruciune n

Fig.6.20
Structuri alternative
Aceste structuri,numite i condiionate, sunt de dou categorii: de selecie i de decizie.
i se caracterizeaz prin executarea unui set de instruciuni sau a altuia, n funcie de
ndeplinirea sau nendeplinirea unei condiii.
Structurile alternative permit astfel ramificarea ordinii de execuie a instruciunilor unui
program. (Fig.6.21)

176

Instruciune 1

Fals

Adevrat
Cond

Instruciune 2

Instruciune 3

Fig. 6.21

Structuri repetitive
n cadrul structurilor repetitive (sau iterative), un set de instruciuni se repet n funcie de o
condiie specificat. (Fig. 6.22)
Structurile repetitive pot fi:

condiionate anterior caracterizate prin executarea repetat a setului de

instruciuni ct timp condiia testat este adevrat;

condiionate posterior caracterizate prin executarea setului de instruciuni ct timp

o condiie este fals;

condiionate anterior sau posterior, cu contor. Cu aceast structur se execut

setul de instruciuni de un numr de ori, plecnduse de la valoarea iniial a variabilei
contor pn la valoarea final a acesteia, incrementnduse automat variabila contor cu
+1

177

Instruciune 1

Condiie

Adevrat

Fig. 6.22
Instruciune 2

Fals

6.3.2 Instruciuni pentru implementarea structurii alternative

Instruciunile VBA utilizate n reprezentarea acestor structuri sunt : If pentru structurile
alternative de selecie i Select Case pentru structurile alternative de decizie.

Instruciunea If
Este utilizat sub urmtoarele formate :
A.
If <condiie>Then
[secven_instruciuni_1]
[Else
[secven_instruciuni_2]]
End If
Unde:
Condiie poate fi o expresie numeric sau o expresie ir de caractere, care poate fi
evaluat la adevrat (true) sau fals (False).
Dac rezultatul evalurii expresiei din condiie este adevrat, atunci este executat
secven_instruciuni_1, astfel este executat secven_instruciuni_2.
Exemplu:
Dac media este egal cu 5 atunci studentul este considerat integralist, n caz contrar
este restanier.
178

If Media = 5 Then
MsgBox Student integralist
Else
MsgBox Student restanier
End If
B.
If <condiie_1>Then
[secven_instruciuni_1]
[Else lf<condiie_2> Then
[secven_instruciuni_2]]

[Else
[secven_instruciuni_n]]
End If
Aceast variant este util n cazul structurilor imbricate.
Exemplu:
Agenii comerciali sunt premiai n funcie de valoarea mrfurilor vndute.
If suma_de_ncasat<100000000 Then
MsgBox Prima=suma_de_ncasat * 5%
Elself suma_de_ncasat >=100000000 Then
MsgBox Prima=suma_de_incasat * 10%
Else pentru suma_de_ncasat> 200000000 Then
MsgBox Prima=suma_de_ncasat * 15%
End If
C.
If<condiie> Then <instruciune_1> [Else <instruciune_2 >]
n aceast variant, dup evaluarea condiiei, se poate executa o singur instruciune i
trebuie scris pe un singur rnd.
Exemplu:
n calculul valorii de plat corespunztoare facturilor ntocmite, firma X ofer o reducere
179

de 5% pentru facturile mai mari de 100 milioane lei.

If val_fact>100000000 Then val_de_plat=val_fat*0,95_
Else val_de_plat=val_fact

Instruciunea Select Case

n cazul n care o expresie trebuie comparat cu un numr mai mare de valori, nu este
recomandat folosirea repetat a instruciunii IfThenElse, ci este performant folosirea
instruciunii Select Case.
Formatul instruciunii este:
Select Case <expresie_selector>
[Case <list_expresii_case_1>
[secven_instruciuni_1]]
[Case <list_expresii_case_1>
[secven_instruciuni_2]]
[Case <list_expresii_case_1>
[secven_instruciuni_3]]
.
[Case Else
secven_instruciuni_n]
End Select

Unde:
expreresie_selector poate fi o expresie numeric sau o expresie ir de caractere.
Expresiile Case pot fi o list de expresii numerice sau o expresie ir de caractere
separate de , (virgul).
De asemenea pot conine operatorii To i Is cu urmtorul format:
<expresie_1> To <expresie_2>
Se tasteaz dac valoarea expresiei_selector se afl cuprins n intervalul de valori cuprins ntre
expresie_1 i expresie_2
Is <operator de comparare> <expresie>
Se tasteaz dac valoarea expresiei_selector satisface condiia impus de operatorul de
comparare.

180

Exemplu:
Penalitile percepute de firma X pentru ntrzierea pli facturilor de ctre beneficiari, n
funcie de numrul de zile de ntrziate.
Select Case Penaliti
Case 0
MsgBox Penaliti=0
Case 1 To 5
MsgBox Penaliti= val_fact*0,01
Case 6 To 10
MsgBox Penaliti=val_fact*0,05
Case 11 To 15
MsgBox Penaliti=val_fact*0,1
Case Else
MsgBox Penaliti=val_fact*0,5
End Select
6.3.3 Instruciuni pentru implementarea structurii repetitive
Pentru reprezentarea acestei structuri se folosesc un numr de patru instruciuni:
WhileWend
Do...Loop
For.Next
For Each..Next

Instruciunea WhileWend
Este o structur repetitiv condiionat anterior.
Formatul instruciunii este:
While <condiie>
[secven_instruciuni]
Wend
Condiie poate fi o expresie numeric sau o expresie ir de caractere, care poate fi
evaluat la adevrat sau fals. nti se evalueaz condiia, dac este adevrat, se repet
181

secvena de instruciuni; dac nu este adevrat se iese din structur i se trece la urmtoarea
secven de instruciuni de dup Wend.
Exemplu:
S se afieze numerele mai mici dect 10.
Score = 0
While Score < 0
Score = Score + 1
Wend

Instruciunea DoLoop
Formatul instruciunii este:
Do [{WhileUntil} <condiie>]
[secven_instruciuni]
[Exit Do]
[secven_instruciuni]
Loop

n varianta Do While...Loop se repet secvena de instruciuni atta timp ct

condiia este adevrat. Dac evaluarea ei este Null, evaluarea condiiei este False. Aceast
variant funcioneaz exact ca While...Wend, cu deosebirea c se poate iei forat din structur
cu Exit Do.
Do
[secven_instruciuni]
[Exit Do]
[secven_instruciuni]
Loop [{WhileUntil} <condiie>]
Exemplu:
Se va introduce Nr_Matricol al studenilor pn cnd Nr_ Matricol = 3456
Nr_ Matricol = 0
Do
Nr_ Matricol = Nr_ Matricol + 1
Loop Until Nr_ Matricol = 3456
182

n varianta Do Until...Loop se repet secvena de instruciuni pn cnd condiia

devine adevrat. Deci se execut secvena de instruciuni atta timp ct evaluarea condiiei
este False.
Instruciunea Exit Do foreaz ieirea din structura repetitiv la instruciunea care urmeaz dup
instruciunea Loop ntrun moment anume ales de programator.

Instruciunea For.Next
Codific structura repetitiv cu un numr definit de pai, n care o secven de cod se repet cu
un numr specificat de ori.
Formatul instruciunii este:
For <vb_contor>=<val_initiala> To <val_finala> [Step <Val_pas>]
[secven_instruciuni]
[Exit For]
[secven_instruciuni]
Next [<vb_contor>]
<val_initiala>,<val_finala> reprezint valoarea iniial, respectiv final pentru
<vb_contor>;
<Val_pas> reprezint valoarea pasului de incrementare/decrementare pentru variabila
contor, implicit are valoarea + 1;
<val_initiala>,<val_finala>,<Val_pas> pot fi rezultatul evalurii unor expresii.
Exemplu:
Se va afia suma numerelor de la 10 la 100.
Suma = 10
For CONTOR = 11 To 100
Suma = Suma + CONTOR
Next CONTOR

Instruciunea For Each..Next

Parcurge iterativ o colecie de elemente, la fiecare iteraie variabilei element I se atribuie un
element din colecie. Se folosete la parcurgerea coleciilor de obiecte Access.
Formatul instruciunii este:

183

For Each <vb_element> In <colectie>

[secven_instruciuni]
[Exit For]
[secven_instruciuni]
Next [<vb_element>]
6.4 SQL pentru ACCESS
Limbajul SQL (Structured Query Language) este cel mai frecvent utilizat limbaj de baze de date
folosit cu preponderenta de majoritatea creatorilor de aplicatii, administratorilor de baze de date,
proiectantilor de aplicatii web sau utilizatorilor de Microsoft Office.
Se cunosc trei metode de baz privind implementarea limbajului SQL, i anume:
cea prin apelare direct (Direct Invocation) const n introducerea instruciunilor SQL
de la prompter;
cea modular (Modul Language) folosete anumite proceduri apelate de programele
aplicaiei;
cea de tip ncapsulat (Embedded SQL) are n vedere instruciuni ncapsulate n codul
de program, fiind de tip static sau dinamic.
Instruciunile SQL, n funcie de rolul lor n manipularea datelor i tranzaciilor, pot fi grupate
astfel:
instruciuni de definire a datelor care permit descrierea structurii bazei de date;
instruciuni de selecie a datelor care permit consultarea bazei de date;
instruciuni de manipulare a datelor, n sensul adugrii, modificrii i tergerii
nregistrrilor;
instruciuni de procesare a tranzaciilor care privesc unitile logice de prelucrare i
constituie n fapt operaii multiple de manipulare a datelor;
instruciuni de control al cursorului;
instruciuni privind controlul accesului la date.
Cu ajutorul urmtoarelor reguli se pot construi instruciuni valide, uor de citit i de editat:

Instruciunile SQL pot fi scrise cu litere mari sau mici, n afar de cazurile indicate;

Instruciunile SQL pot fi introduse pe una sau mai multe linii;

Cuvintele cheie nu pot fi abreviate sau desprite n linii diferite;

Clauzele, de obicei, sunt plasate pe linii separate pentru a fi lizibile;

De obicei cuvintele cheie sunt introduse cu majuscule; iar toate celelalte cuvinte,
ca numele de tabele i coloane, sunt introduse cu litere mici;

n cadrul SQL*Plus, instruciunile SQL sunt introduse de la prompterul SQL, iar

184

urmtoarele linii sunt numerotate. Acesta se numete un buffer SQL. O singur

instruciune poate fi curent n orice timp n cadrul bufferului.
Executarea instruciunilor SQL

Poziionarea punct i virgulei (;) la sfritul ultimei clauze;

Poziionarea unui slash (/) la sfritul ultimei linii din buffer;
Punerea unui slash la promterul SQL;
n cadrul SQL*Plus comanda RUN la promterul SQL.

Pentru a crea i executa interogri SQL n SGBD Access se parcurg etapele:

1.
din fereastra Open, se deschide baza de date asupra creia se vor efectua
interogrile SQL (Fig.6.23);

Fig.6.23
2.
din fereastra Database care se afieaz se va selecta eticheta Query. Pentru a
crea interogarea SQL se va selecta opiunea Create query n Design View (Fig.6.24);

Fig.6.24
3.
se alege cu ajutorul butonului Add tabela (Tables), interogarea (Query) sau
ambele categorii de obiecte (Both) care vor prezenta suportul interogrii SQL. Din
fereastra Show Table se pot selecta mai multe tabele (interogri). (Fig.6.25);
185

4.
pentru a scrie interogarea SQL ACCESS este necesar s se selecteze din meniul
View opiunea SQL View. n aceast fereastr se vor scrie instruciunile SQL (Fig.6.26);
5.
pentru a pune n execuie comanda SQL din meniul Query se selecteaz opiunea
Run. Pe ecran se va afia rezultatul; acest rezultat va fi interpretat de utilizator.

Fig. 6.25

Fig.6.26
6.4.1 Limbaj de definire a datelor: SQLLDD
Gestiunea schemei bazei de date
Schema unei baze de date descrie tabelele i atributele aferente lor, domeniile n care
aceste atribute iau valori, restriciile de integritate, drepturile de utilizare a relaiilor, viewurile i
detaliile relative la implementarea fizic a tabelelor.
186

Limbajul de definire a datelor LDD (Language Data Definition), parte component a

limbajului SQL, include instruciuni care permit realizarea aciunilor specifice descrierii schemei
bazei de date.
Majoritatea implementrilor limbajului SQL conin instruciuni pentru crearea unei baze de date,
fie c acestea fac parte din setul de comenzi al versiunii SQL, fie sub form de programe
utilitare. Prima etap n administrarea datelor o reprezint crearea bazei de date. Sintaxa
comenzii nu este standardizat, putnd varia n funcie de necesitile utilizatorului i de
S.G.B.D.ul folosit. De exemplu ACCESS SQL nu accept o astfel de instruciune.
La crearea unei baze de date trebuie respectate anumite restricii stabilite de
administratorul de sistem i anume, cele referitoare la nivelul drepturilor de utilizare a
instruciunilor n sistem i cele care privesc stabilirea dimensiunilor predefinite pentru baza de
date.
Crearea unei baze de date
Sintaxa:
CREATE DATABASE nume_baza_de_date;
Exemplu: S se creeze baza de date Situaia beneficiarilor:
CREATE DATABASE Situaia_beneficiarilor
Crearea unei tabele
Sintaxa:
CREATE TABLE nume_tabel
(cmp1 tip_dat [NOT NULL],
cmp2 tip_dat [NOT NULL],
cmp3 tip_dat [NOT NULL]...);
Exemplu:
S se creeze tabela Beneficiar cu structura urmtoare: Cod beneficiar (tip numeric),
Denumire beneficiar (tip text), Adresa (tip text), Telefon (tip numeric).
CREATE TABLE Beneficiar
(Cod_beneficiar Number, Den_beneficiar Text, Adresa Text, Telefon Number);
Modificarea structurii unei tabele.
Comanda ALTER TABLE permite modificarea unei tabele prin adugarea/tergerea de atribute
i prezint urmtoarea sintax:
Sintaxa:
ALTER TABLE nume_tabel {ADD COLUMN nume_atribut1
Tip_data [(mrime)] [NOT NULL][CONSTRAINT index] DROP COLUMN
nume_atribut2 CONSTRAINT indexname};
187

Exemplu:
S se adauge tabelei Beneficiar un nou cmp numit Banca.
ALTER TABLE Beneficiar
ADD COLUMN Banca Text;
Exemplu:
S se realizeze tergerea atributului Adresa din tabela Beneficiar
ALTER TABLE Beneficiar
DROP COLUMN Adresa Text;
tergerea relaiilor dintro baz de date
tergerea unei tabele se realizeaz cu ajutorul comenzii DROP TABLE, odat cu
aceasta tergnduse i indecii, viewurile definite pentru respectiva tabel, neexistnd nici o
posibilitate de recuperare a informaiei terse.
Sintaxa:
DROP TABLE nume_tabel;
Exemplu:
S se tearg tabela Beneficiar din baza de date Situaia beneficiarilor
DROP TABLE Beneficiar;
tergerea unei baze de date
tergerea unei baze de date determin tergerea tuturor obiectelor coninute de aceasta, a
copiei cataloagelor SQL din directorul bazei de date.
Sintaxa:
DROP DATABASE nume_baz de date;
Aceast instruciune nu este inclus de anumite versiuni SQL, tergerea fcnduse mai uor
printro apsare a mouselui. ntro reea de calculatoare nu poate fi tears o baz de date
activat de ctre un alt utilizator. Comanda de tergere nu poate aciona asupra unei baze de
date active.
Gestiunea indecilor
Un index este un obiect schem care mbuntaete regsirea nregistrrilor
folosind un pointer. Indecii pot fi creai explicit sau automat.
Un index furnizeaz un acces direct i rapid la nregistrarile unei baze de date.
Scopul utilizrii indecilor este reducerea numrului de citiri/scrieri pe disc, prin folosirea unei ci
indexate pentru a localiza mai rapid datele. Indexul este automat folosit si ntreinut de serverul
Oracle. Odat creat indexul, nu este necesar nici o intervenie din partea utilizatorului.
Indecii sunt logic si fizic i sunt independeni de bazele de date pe care le indexeaz. Acest
lucru nseamn c indecii pot fi creai sau teri oricnd fr nici un efect asupra bazelor de
date sau a altor indeci.
188

Nota:

Cnd este ters un tabel, indecii corespunztori sunt de asemenea teri.

Indexul este un obiect din schem.

Indexul este folosit de serverul Oracle pentru o mai bun regsire a nregistrarilor
prin utilizarea unui pointer.

Indexul reduce numrul operaiilor de citire/scriere pe disc prin utilizarea unei

metode de accesare rapid, pentru o mai eficient localizare a datelor.

Indexul este independent de tabelele pe care le indexeaz.

Indexul este folosit i ntreinut de serverul Oracle.

Indecii sunt creai:

Automat cnd este definit o cheie primara (PRIMARY KEY) sau unic
(UNIQUE KEY) n definiia unui tabel.

Manual utilizatorii pot crea indeci mecanic pentru a accelera accesul la

nregistrrile bazelor de date
Crearea unui index
Sintaxa:
CREATE INDEX index
ON table (column[, column]);
mbuntirea accesului cmpului ENAME n baza de date EMP
SQL> CREATE INDEX emp_ename_idx
ON emp(ename);
Index created.
Unde:
index este numele indexului.
table numele bazei de date.
column numele cmpului n baza de date ce urmeaz a fi indexat
Crearea unui index se face pentru:

un cmp ce este folosit des n clauzele WHERE sau n condiii de join;

cmpuri cu mare varietate de valori;

cmpuri cu un numr mare de valori NULL;

dou sau mai multe cmpuri ce sunt folosite mpreun frecvent ntro clauz
WHERE sau ntro condiie join;

o baz de date mare i majoritatea interogrilor nu vizeaz mai mult de 24% din
nregistrri.
Mai multi indeci ntro baz de date nu nseamn o optimizare a interogrilor. Fiecare
operaie DML ce se realizeaz ntro baz de date ce conine indeci implic o actualizare a
189

indecilor. Cu ct sunt mai muli indeci asociai tabelului, cu att va dura mai mult pn cnd
serverul Oracle va actualiza indecii dupa DML.
Nu este necesar crearea unui index atunci cnd:

baza de date este mic;

cmpurile nu sunt des folosite ntro condiie;

majoritatea interogrilor vizeaza mai mult de 24% dintre nregistrari.

Confirmarea indecilor
USER_INDEXES conine numele indexului si unicitatea lui.
Componenta USER_IND_COLUMNS conine numele indexului, numele bazei de date
si numele cmpului.
SQL> SELECT ic.index_name, ic.column_name,
ic.column_position col_pos, ix.uniques
FROM user_indexes ix, user_ind_columns ic
WHERE ic.index_name = ix.index_name
AND ic.table_name = EMP;
Confirmarea indecilor
Confirmarea indecilor existeni se realizeaz prin vizualizarea lui USER_INDEXES. De
asemenea se pot verifica cmpurile implicate ntro indexare prin interogarea lui
USER_IND_COLUMNS.
Exemplul urmtor afieaz toi indecii creai anterior, numele cmpurilor afectate i
unicitatea n baza de date EMP.
INDEX_NAME

COLUMN_NAME

COL_POS

UNIQUENES

EMP_EMPNO_PK

EMPNO

UNIQUE

EMP_ENAME_IDX

ENAME

NONUNIQUE

Nota: Ieirea a fost formatat anterior.

tergerea unui index
tergerea unui index din dicionarul de date.
Sintaxa:
SQL> DROP INDEX index;
tergerea indexului EMP_ENAME_IDX din dicionarul de date.
Sintaxa:
190

SQL> DROP INDEX emp_ename_idx;

Index dropped
tergerea unui index poate fi realizat doar cel care la creat sau de cel care are privilegiul
Sintaxa:
DROP ANY INDEX.
Indeci care aparin unei legturi dintre tabele
Clauza CONSTRAINT
Permite crearea unui index dup numele unui cmp; indexul poate fi declarat drept
cheie primar (PRIMARY KEY) sau ca UNIQUE sau stabilete o relaie ntre cmpul nume de
index i cmpul unei tabele externe (cu opiunea REFERENCES foreign_tabele [foreign_field]).
Sintaxa:
CONSTRAINT nume_index
{PRIMARY KEY ! UNIQUE ! REFERENCES foreign_table
[foreign_field]};
Clauzele UNIQUE i PRIMARY KEY
Exist o diferen intre UNIQUE i PRIMARY KEY i anume: pe o tabel poate exista o singur
cheie primar, dar UNIQUE specific existena unor valori unice la nivelul unei coloane. n plus,
PRIMARY KEY conine automat o restricie NOT NULL, pe cnd o coloan UNIQUE poate avea
valori NULL dac nu este specificat in mod expres clauza NOT NULL.
Menionm faptul c indexul poate fi simplu (creat pe o singur) sau multiplu (creat pe mai multe
coloane).
REFERENCES
Este varianta cea mai simpl de definire a unei restricii relaionale i care sa
dovedit deosebit de practic. Aceast clauz pune in legtur dou tabele. Ea specific faptul
c valorile unei coloane aparinnd tabelei ( care servete la stabilirea de legturi trebuie s
apar intro coloan din tabela referit al crei nume este precizat n restricie (CONSTRAINT
nume_index).
Observaie: Restriciile UNIQUE nu sunt acelai lucru cu INDEX UNIQUE. Un index UNIQUE nu
poate fi referit pentru c el aparine unei singure tabele i nu unei legturi ntre tabele.
Exemplu:
CONSTRAINT idcod PRIMARY KEY (codp)
CONSTRAINT rcod REFERENCES vnzri (codp);

191

Comanda DROP CONSTRAINT permite tergerea unei restricii de unicitate sau de referin
utiliznd sintaxa:
Sintaxa:
DROP CONSTRAINT nume_index;
3.2.3 Gestiunea drepturilor de utilizare
Utilizatorii bazei de date sunt repertorizai de SGBD prin:

identificatorul sistem;

parol;

nume de utilizare de date drepturi asupra tabelelor sale.

Acordarea drepturilor de acces
Proprietarul unei tabele poate acorda altor utilizatori drepturi de a manipula tabela. Acordarea
acestor drepturi se realizeaz prin comanda GRANT care prezint urmtoarea sintax:
Sintax:
GRANT [ ALL/List de privilegii]
ON TABLE1,...,TABLE n
TO [PUBLIC/ List utilizatori]
[WITH GRANT OPTION]
Unde:
List privilegii: alter, delete, insert, update, select;
ALL: toate comezile;
Public: toi utilizatorii;
WITH GRANT OPTION: drepturi utilizatorilor de a acorda la rndul lor drepturi de acces
altor utilizatori.
Exemplu:
S se acorde tuturor utilizatorilor toate drepturile asupra tabelei BENEFICIAR:
GRANT ALL ON BENEFICIAR TO PUBLIC;
S se acorde utilizatorului tefan drepturi de actualizare i dreptul de tegere in tabela
BENEFICIAR:
GRANT UPDATE, DELETE
ON BENEFICIAR
TO TEFAN;
Retragerea drepturilor de acces
Retragerea (anularea) drepturilor de acces se realizeaz prin comanda REVOKE.
Sintax:
192

REVOKE [ALL/List de privilegii]

ON TABLE 1,..., TABLE n
FROM [PUBLIC/List utilizatori];
Exemplu:
S se retrag dreptul de actualizare a tablelei BENEFICIAR utilizatorului Ionescu:
REVOKE UPDATE
ON TABLE BENEFICIAR
FROM IONESCU;
n toate SGBDurile, administratorul bazei de date are, n mod implicit toate drepturile
asupra tuturor obiectelor bazei de date. Pentru a limita accesul la atributele i tuplurile unei
tabele se folosesc viewurile:
Exemplu:
CREATE VIEW LOG
AS SELECT Cod_beneficiar, Adresa, Telefon
FROM BENEFICIAR;
GRANT SELECT ON LOG TO PUBLIC;
Se acord dreptul de consultare a tabelei BENEFICIAR pe atributele: Cod_beneficiar,
Adresa, Telefon.
6.4.2 Limbajul de manipulare a bazei de date (SQLLMD)
Limbajul de manipulare a datelor (DML) este partea de baz a SQL. Cnd dorim s
adugm, s modificm sau s tergem date dintro baz de date, executm o comand DML.
O colecie de comenzi DML care formeaz o unitate logic de lucru se numete tranzacie.
Considerm o baz de date din domeniul bancar. Atunci cnd un client al bancii dorete
s transfere bani dintrun depozit ntrun cont curent, tranzacia ar putea consta n 3 operaii
separate: scade suma din depozit, crete suma din contul curent, nregistreaz tranzacia n
jurnalul de tranzacii. Serverul Oracle trebuie s garanteze c toate cele 3 comenzi SQL sunt
executate n aa fel nct s menin echilibrul necesar ntre conturi. Atunci cnd, din anumite
cauze, una dintre comenzile tranzaciilor de mai sus nu se execut, atunci celelalte comenzi ale
tranzaciilor trebuie s fie anulate.
Instruciuni pentru selectarea datelor
Cereri de interogare simple
Instruciunile de selecie reprezint una dintre categoriile cele mai importante ale limbajului de
interogare SQL ACCESS.
Pentru definirea interogarilor de selecie simple avem instrucunea SELECT cu urmtoarea
193

sintax :
SELECT [domeniu] list_selecie
FROM nume tabela 1, nume tabela 2;
[WHERE criteriul _de_selectie]
[ORDER BY campuri_criteriu [ASC/DESC]];
unde:

domeniu determin stabilirea modalitaii de manipulare a nregistrrilor din baza

de date asupra creia se face selecia

All permite includerea tuturor nregistrrilor ce ndeplinesc condiiile impuse;

Distinct elimin nregistrrile care prezint valorile duplicate n cmpurile

selectate;

Distinctrow vizeaz nregistrrile duplicate care nu vor fi returnate n urma

executrii cererii;

List_selecie cuprinde toate cmpurile care vor aprea n tabela cu rezultatele

interogrii;

Clauza FROM specific numele tabelei sau tabelelor care vor forma suportul
interogrii;

Clauza WHERE face interogrile mai selective, nregistrrile care ndeplinesc

crieteriul descris vor fi afiate;

Clauza ORDER BY se utilizeaz atunci cnd se dorete ca rezultatele s fie

ordonate in mod cresctor (ASC) sau descresctor (DESC).
Operatorii utilizai n cererile de interogare sunt:

operatori aritmetici:+,,*,/

operatori logici: and, or, not

operatori de atribuire i comparare: <, >, =, <=, >=.

n serierea interogrilor de selecie simple SQL ACCESS este posibil i folosirea funciilor de
grup. Cele mai importante sunt:
COUNT returneaz numrul de nregistrri care respect condiia stabilit prin clauza
Where;
SUM returneaz suma valorilor dintrun cmp; opereaz numai cu valori numerice;
AVG calculeaz valoarea medie pentru cmpul precizat;
MAX returneaz cea rnai mare valoare dintrun cmp;
MIN returneaz cea mai mic valoare dintrun cmp
Exemplu:

dorim afiarea mediilor fiecrui student identificat dup NrLeg

194

SQL> SELECT NrLeg, AVG(Nota) Media

from Note Group By NrLeg;

dorim afiarea numrului de note primite de fiecare student identificat dup NrLeg
SQL> SELECT NrLeg, Count(Nota) NrNote
FROM Note
Group By NrLeg;

dorim afiarea studenilor cu medii >=5 identificai dup NrLeg

SQL> SELECT NrLeg, Avg(Nota) Media
FROM Note
group by NrLeg
HAVING avg(Nota)>=5;

dorim afiarea studenilor cu medii <5 identificai dup NrLeg

SQL> SELECT NrLeg, Avg(Nota) Media
FROM Note
group by NrLeg
HAVING avg(Nota)<5;
dorim afiarea mediei pe fiecare grup
SQL> SELECT Grupa, Avg(N.Nota) Media
FROM Student S, Note N
WHERE S.NrLeg=N.NrLeg;
group by Grupa

dorim afiarea mediei >=5 pentru fiecare grup

SQL> SELECT Grupa, Avg(N.Nota) Media
FROM Student S, Note N
WHERE S.NrLeg=N.NrLeg
group by Grupa
HAVING avg(Nota)>=5;
195

dorim afiarea mediei pe fiecare materie

SQL> SELECT Denumire, Avg(N.Nota) Media
FROM Materii m, Note N
WHERE M.Cod_materie=N.Cod_materie
GROUP BY Denumire;

dorim afiarea mediei pe fiecare materie si grupa ordonata crescator dupa Grupa
SQL> SELECT Grupa, Denumire, Avg(N.Nota) Media FROM Student S, Materii m,

Note N
WHERE S.NrLeg=N.NrLeg and M.Cod_materie=N.Cod_materie
GROUP BY Grupa, Denumire
Order by Grupa

dorim afiarea studeniilor i a mediilor acestora

SQL> SELECT S.NrLeg, Nume, Prenume, Avg(N.Nota) Media
FROM Student S, Note N
Where S.NrLeg=N.NrLeg
GROUP BY S.NrLeg, Nume, Prenume;

dorim s vizualizm din tabela Produs (cod produs, den produs, um, pret) numai
acele produse cu preuri cuprinse ntre 100000 lei i 120000 lei
SQL>SELECT den produs
FROM Produs
WHERE pret BETWEEN 100000 AND 120000;

dorim s cunoatem codul atribuit produsului "crema mini" i la ce pre este

oferit.
SELECT cod produs, pret, den produs
FROM Produs
WHERE den produs "crema mini";
Cereri de interogare complexe
196

Limbajul de interogare SQL ACCESS permite pe lng definirea de interogri de selecie

simple, crearea unor interogri cu o structur complex, cum ar fi cele n care regsim funciile
agregate, interogrile JOIN sau interogrile UNION;
Funciile de grup (agregat)
Permit construirea unor interogri SQL ACCESS complexe, prin care utilizatorul poate s
efectueze diverse calcule pentru grupuri de inregistrari care au cmpuri cu aceiai valoare,
SELECT [domeniu] [functie_agregata] (nume_cmp) AS alias, lista_seleetie]
FROM nume_tabela 1 nume tabela 2;
GROUP BY cmp_de _grupare
[HAVING criteriul_de_grupare]
[ORDER BY cmpuri_criteriu[ASC/DESC]];
Din structura instruciunii se observ anumite clauze care au fost ntlnite i la definirea
interogrilor simple ns apar i elemente mai de sintez i anume:

List selecie se refer la una sau mai multe funcii agregate care au ca
argumente nume de cmpuri ale bazei de date

AS alias asociaz un pseudonim (nume) rezultatului utilizrii funciei agregat

Clauza GROUP BY precizez cmpul sau cmpurile pe baza crora se va

efectua gruparea negistrrilor; se pot executa funciile agregate descrise n lista de
selecie pentru fiecare dintre grupri. Echivalentul acestei clauze n macheta grafic QBE
de constucie a interogrii il reprezint rndul Total

Clauza HAVINIG se refer la criteriul care va fi aplicat cmpului definit ca

argument al funciei agregat
Exemplu:
Dorim s cunoatem clienii care au datorii mai mari de 12000000 lei.
SELECT denumire_client, SUM([valoare neachitat]) AS Total
FROM Creante
GROUP BY denumire_client
HAVING SUM (Valoare_neachitat) > 1200000;
Interogrile JOIN
Operaiile de asociere induse de clauza JOIN au ca rezultat producerea tuturor
combinaiilor posibile, pentru coninutul infomaional al fiecarei tabele. Noile nregistrri care
rezul n urma jonciunii vor deveni disponibile pentru seleciile ulterioare. La o asociere pot
participa mai mult de dou tabele.
197

Exist mai multe categorii de jonciuni:

CROSS cu rol n ilustrarea elementelor specifice proprietilor combinatorii ale

tuturor asocierilor

ECHIVALEN presupune folosirea clauzei WHERE asociat cu o egalitate

NEECHIVALENT face apel n clauza WHERE la oricare alt operator de

comparare n afara de semnul egal.
Sintaxa general pentru jonciunile echivalente i neechivalente este:
SELECT [domeniu] lista_ selectie
FROM nume_tabela 1,. Nume_tabela 2.,...
[WHERE criteriul_de_asociere]
[ORDER BY campuri_criteriu [ASC/DEESC]];
Deoarece n instruciunile SQL, care descriu jonciuni se utilizeaz cmpuri ce fac parte din
tabele diferite, este necesar ntotdeauna specificarea tabelei de care aparin.
Forma general de descriere a unui astfel de cmp
SELECT Factura. nr_factura, Client. cod_client, Factura.suma_factura, Incasari.
suma_incasata
FROM Factura, Client, Incasari
WHERE Factura. cod_client=Client. cod_client AND Client. cod_client=Incasari.
cod_client
ORDER BY Client. cod_client;
Interogrile UNION
Cnd utilizatorul dorete s vad rezultatele a mai multor interogari SELECT n acelai timp,
prin combinarea ieirilor lor, poate utiliza facilitatea UNION a limbajului de interogare SQL
ACCESS. Nu exist echivalent QBE pentru aceast instruciune.
Sintaxa general pentru interogrile UNION este:
SELECT lista_campuri FROM tabela 1
UNION SELECT lista_campuri FROM tabela 2
[GROUP BY camp_de_grupare]
[HAVING criteriul _de_grupare]
[UNION SELECT lista_campuri FROM tabela3 ]
[GROUP BY camp_de_grupare]
[HAVING criteriul_de_grupare]
[union......]
[GROUP BY camp_criteriu_de_sortare

198

Instruciuni pentru actualizarea bazei de date

Aceste instruciuni se implementeaz prin interogrile de tip aciune; efectele aciunii lor sunt
permanente, influennd inclusiv integritatea referenial. Cele mai importante instruciuni sunt
CREATE, INSERT, UPDATE i DELETE.
Crearea unei noi tabele plecnd de la structura i coninutul unei tabele deja existente
Sintaxa:
SELECT [domeniu] (cmp 1, cmp 2...)
INTO tabela_nou
FROM tabela_surs
[WHERE criteriul_de_adugare];
Exemplu:
S se creeze o tabel cu numele Beneficiari_teritoriali plecnd de la tabela Beneficiari
n care s regsim doar beneficiarii care au sediul n Craiova i Timioara.
SELECT DISTRICTROW Den_beneficiar, Adresa
INTO Beneficiari_teritoriali
FROM Beneficiari
WHERE Adresa = Craiova OR Adresa= Timioara;
Adugarea unei nregistrri dintro tabel n alta
Exist dou forme ale instruciunii i anume:
INSERT...VALUES
INSERT...SELECT
INSERT...VALUES
Sintaxa:
INSERT INTO nume_tabel (cmp 1, cmp 2...)
VALUES (valoare 1, valoare 2...);
n acest caz se insereaz o nregistrare ntro tabel, menionnduse cmpurile i
valorile asociate acestora. Ca particularizare se remarc inserarea unei singure nregistrri la un
moment dat.
Trebuie avut n vedere respectarea urmtoarelor reguli:

valorile menionate n clauza VALUES vor avea aceeai natur cu cmpurile

specificate n clauza INTO;

mrimea valorii corespunztoare fiecrui cmp va fi mai mic dect dimensiunea

199

cmpului;

nu va fi nevoie specificarea denumirii cmpurilor, deorece SQL ACCESS va

asocia listei de valori cmpurile n ordinea din structura nregistrrii (prima valoare se va
introduce n primul cmp, a doua valoare n al doilea cmp, etc.)

dac un cmp are definiia NOT NULL, va fi obligatorie introducerea unei valori
pentru acesta.
Exemplu:
S se adauge n tabela Produse o nregistrare care respect structura: Cod produs,
Denumire produs, UM, Pret.
INSERT INTO Produse
(Cod_produs, Denumire_produs, UM, Pret)
VALUES (100, Spun, Buc, 25000)
INSERT...SELECT
Sintaxa:
INSERT INTO tabel_destinaie (cmp 1, cmp 2...)
SELECT [domeniu] cmp 1, cmp 2...
FROM tabel_surs
WHERE criteriul_de_adugare;
n acest caz este posibil s se copieze selectiv nregistrri dintro tabel ntruna sau n mai
multe tabele.
Regulile menionate la instruciunea INSERT...VALUES rmn valabile, n plus se adaug
urmtoarele:

fraza SELECT nu poate extrage nregistrri din tabela destinaie;

numrul i natura cmpurilor menionate n clauza INTO trebuie s fie aceleai cu

numrul i natura cmpurilor returnate de instruciunea SELECT;

dac nu se introduce clauza WHERE, toate nregistrrile din tabela surs vor fi
adugate n tabela destinaie.
Exemplu:
Se insereaz valorile cmpurilor: numr, nume, prenume i studii doar pentru agenii de
vnzare care sunt studeni. Selecia se face din tabela surs Agent_vnzare, iar destinaia o
constituie tabela Studii (care trebuie creat n prealabil). Comanda de creare a tabelei STUDII
este:
CREATE TABLE STUDII
(nr Number, nume Text, pren Text, std Text);
200

Comanda propriuzis de inserare este:

INSERT INTO STUDII (nr, nume, pren, std)
SELECT nr, nume, pren, std
FROM Agent_vanzare
WHERE std=student;
Interogarea aciune de tergere parial sau total a nregistrrilor din tabele DELETE
Sintaxa:
DELETE FROM nume_tabela
[WHERE criteriul_de _stergere];
Nu este utilizat pentru tergerea de valori din cmpuri individuale, ci va aciona doar asupra
nregistrrilor n totalitatea lor. n acelai timp se va terge doar coninutul tabelei nu i aceasta
(pentru eliminarea tabelei se va apela la instruciunea DROP TABLE).
Ca i instruciunea INSERT, operaia de tergere a nregistrrilor dintro tabel poate duce la
apariia unor probleme de integritate referenial n alte tabele. Clauza WHERE restricioneaz
domeniul de tergere n funcie de cerinele utilizatorului.
Exemplu:
Din tabela Produse s se tearg nregistrrile care au preul mai mic de 20000.
DELETE FROM Produse
WHERE Pret < 20000;
Interogarea aciune UPDATE;
Are scopul de a insera noi nregistrri ct i de a modifica valorile cmpurilor din
nregistrrile existente. Ca i n cazul instruciunii INSERT, se va urmri dac n cmpul cu valori
de actualizat sunt permise numai valori unice.
Sintaxa:
UPDATE nume_tabela
SET nume_cmp 1= valoare 1
[,nume_cmp 2 = valoare 2]...
[WHERE criteriul_de _actualizare];
Unele sisteme de baze de date pun la dispoziie o extensie la sintaxa standard a instruciunii
UPDATE. De exemplu, limbajul TransactSQL al sistemului SQL Server permite
programatorului s actualizeze coninutul unui tabel pe baza coninutului altor cteva tabele, prin
folosirea clauzei FROM. Sintaxa extins arat astfel:
201

UPDATE nume_tabela
SET nume_cmp 1= valoare 1
[,nume_cmp 2 = valoare 2]
FROM list_tabele
[WHERE criteriul_de _actualizare];
Tipul datelor rezultate din evaluarea expresiei trebuie s fie acelai cu tipul de dat al cmpului
care este modificat. De asemenea, dimensiunea (lungimea) valorii trebuie s fie
corespunztoare cu cmpul care este modificat.
La obinerea rezultatelor n valoarea calculat pot rezulta dou situaii:

trunchierea atunci cnd sistemul de baze de date convertete, de exemplu un

numr fracionar ntrun numr ntreg;

depirea zonei de memorie atunci cnd valoarea rezultat este mai mare dect
capacitatea coloanei modificate. Aceasta va determina semnalarea unei erori de
depire din partea sistemului de baze de date.
6.4.3 VEDERI
O vedere este un tabel virtual. Vederile permit programatorului SQL s creeze imagini
ale datelor care pot fi diferite de imaginile fizice ale acestora situate pe harddisc. Dup crearea
vederii, se pot folosi urmtoarele comenzi SQL:

CREATE VIEW crearea unei vederi;

SELECT interogarea vederilor;

INSERT adugarea de noi date;

UPDATE actualizarea datelor ntro vedere;

DELETE tergerea datelor dintro vedere.

Crearea unei vederi
Permite definirea unei ferestre prin care se pot consulta datele stocate din tabel..
Sintaxa:
CREATE VIEW nume_view [<lista atribute>]
AS SELECT secventa_select
[WITH CHECK OPTION];
unde:
nume_view reprezint numele vederii i opional a denumirii atributelor din view, n
cazul cnd se dorete redenumirea atributelor specificate n instruciunea SELECT;
SELECT specificarea interogrii;
WITH CHECK OPTION specificarea opional a unei condiii suplimentare impuse
202

viewului, astfel nct s poat fi realizat actualizarea sau inserarea datelor n view.
Exemple:
Crearea unui view simplu. Sursa de date o va reprezenta tabela Student iar
rezultatul returnat const n afiarea codului, denumirii i facultii studentului.
CREATE VIEW Date_stud AS
SELECT Cod, Nume, Facultate FROM Student;
Ulterior viewul poate fi vizualizat ca orice tabel. Date_stud reprezint viewul creat n
comanda anterioar. Se dorete afiarea numai a studenilor care ncep cu Pop.
SELECT * FROM Date_stud WHERE Nume like 'Pop%'
Crearea unui view simplu. Sursa de date o va reprezenta tabela Student iar rezultatul
returnat const n afiarea studenilor cstorii.
CREATE VIEW Date_stud_C AS
SELECT * FROM Student WHERE Stare_civila='C'
Date_stud_C reprezint viewul creat n comanda anterioar.
SELECT * FROM Date_stud_C
Crearea unei vederi cu notele mai mari decat 5. Sursa de date o va reprezenta tabela Note.
CREATE VIEW Note1 AS
SELECT * FROM Note WHERE Nota>5
Note1 reprezint viewul creat n comanda anterioar.
SELECT * FROM Note1
Crearea unei vederi cu notele studenilor al cror nume se termin n 'escu'.
CREATE VIEW Note2 AS
SELECT * FROM Student S, Note N WHERE S.NrLeg=N.NrLeg AND S.Nume like
'%escu'
203

Note2 reprezint viewul creat n comanda anterioar.

SELECT * FROM Note2
Crearea unui view complex presupune utilizarea unor funcii agregat n fraza Select.
CREATE VIEW Medii(NrLeg, Student, Grupa, Media) AS
SELECT S.NrLeg, Nume+' '+Initiala+'.'+Prenume,Grupa, AVG(Nota) FROM
Student AS S,Note AS N
WHERE S.NrLeg=N.NrLeg
GROUP BY S.NrLeg, Nume+' '+Initiala+'.'+Prenume,Grupa
Medii reprezint viewul creat n comanda anterioar.
SELECT * FROM Medii
SQL plaseaz cteva restricii la folosirea instruciunii SELECT pentru a formula o vedere.
Urmtoarele dou reguli sunt valabile atunci cnd folosii instruciunea amintit:

Nu poate fi folosit operatorul UNION;

Nu poate fi folosit clauza ORDER BY.

Eroare la crearea unei vederi nu puteti folosi n SELECT clauzele ORDER BY si UNION
CREATE VIEW Note_stud_err AS
SELECT S.NrLeg, Nume+' '+Initiala+'.'+Prenume Student,Grupa, Denumire, Nota FROM
Student AS S,Note AS N, Materii AS M
WHERE S.NrLeg=N.NrLeg AND N.Cod_materie=M.Cod_materie
ORDER BY S.NrLeg
CREATE VIEW Medii_Bursieri AS
SELECT S.NrLeg, Nume+' '+Initiala+'.'+Prenume Student,Grupa, AVG (Nota) Media
FROM Student AS S,Note AS N
WHERE S.NrLeg=N.NrLeg
GROUP BY S.NrLeg, Nume+' '+Initiala+'.'+Prenume,Grupa
HAVING AVG(Nota) >7.5
SELECT * FROM Medii_Bursieri
CREATE VIEW Varste AS
204

SELECT NrLeg, Nume, Prenume,Datediff(year,Data_nastere,getdate()) Varsta

FROM Student
SELECT * FROM Varste
Modificarea datelor folosind vederile se folosesc comenzile UPDATE, INSERT i DELETE
CREATE VIEW Notele AS
SELECT * FROM Note
SELECT * FROM Notele
Exemple:
Scade 5 puncte la toate notele din vederea Notele
UPDATE Notele SET Nota=Nota5
SELECT * FROM Note
DELETE FROM Notele WHERE NrLeg='116'
CREATE VIEW Notele1 AS
SELECT NrLeg, Nota FROM Note
SELECT * FROM Notele1
Adaug 5 puncte la toate notele din vederea Notele1
UPDATE Notele1 SET Nota=Nota+5
Scade un punct la toate notele studenilor cu NrLeg par
UPDATE Notele1 SET Nota=Nota1 WHERE NrLeg%2=0
SELECT * FROM Note
INSERT INTO Notele1 VALUES('120',8)
CREATE VIEW Notele2 AS
SELECT NrLeg, Nota, Cod_materie FROM Note
SELECT * FROM Notele2
INSERT INTO Notele2 VALUES('120',8,'1')
SELECT * FROM Note
Probleme care apar la modificarea datelor folosind vederile
Deoarece ceea ce se vede ntro vedere poate fi un set de date dintrun grup de tabele,
modificarea datelor n tabelele de baz nu este totdeauna la fel de direct. n continuarea este
prezentat o lista care conine cele mai obinuite lucruri pe care trebuie cunoscute atunci cnd
se lucreaz cu o vedere:

Instruciunile DELETE nu sunt permise n vederi ale tabelelor multiple;

Instruciunea INSERT nu este permis dect dac toate coloanele cu atributul

NOT NULL folosite n tabelul de baz sunt incluse n vedere. Aceasta se datoreaz
205

faptului c procesorul SQL nu cunoate ce valori s insereze ntro coloan NOT NULL;

Dac se insereaz sau se actualizeaz nregistrri ntro vedere a unei combinri,

toate nregistrrile care sunt actualizate trebuie s aparin aceluiai tabel fizic;

Dac se folosete clauza DISTINCT pentru crearea unei vederi, nu se mai pot
efectua actualizri sau inserri de nregistrri n cadrul vederii respective;

Coloana virtual (o coloan care este rezultatul unui calcul sau al unei expresii)
nu poate fii actualizat.
Teste de evaluare a cunotinelor
Rspundei prin Adevarat/ Fals:
1. Conceptele de baza ale programarii in VBA sunt numai obiectul si proprietatea
2. Deosebirea dintre o functie si o procedura este ca functia returneaza o valoare pe cnd
procedura nu.
3. Functiile incorporate ale limbajului VBA, InputBox() si MsgBox() permit efectuarea unor
operatii simple de intrare/iesire (I/O) prin utilizarea unor casete de dialog predefinite pe
care le putem adapta utiliznd o gama de pictograme si combinatii de butoane de
raspuns

a.
b.
c.
d.
e.

4. Limbajul de definire a datelor LDD (Language Data Definition), parte componenta a

limbajului SQL, include instructiuni care permit realizarea actiunilor specifice descrierii
schemei bazei de date.
5. SQL_statement reprezinta conditia (conditiile) si actiunea (actiunile) declansatorului
ncercuii varianta de rspuns corect
6. Care vor fi materialele selectate cu interogarea:
SQL> SELECT *
FROM MATERIALE
WHERE Mat LIKE C%;
Cherestea, Cot, Con
Cot, Con
Cherestea
nu afiseaza nimic
Cot
206

a.
b.
c.
d.
e.

7. Specificati care instructiune nu este folosit pentru implementarea structurii repetitive:

WhileWend
Do...Loop
For.Next
For Each..Next
Select Case

8. Functia Year() din cadrul limbajului VBA:

a. Returneaza data sistemului
b. Returneaza numarul zilei din luna
c. Returneaza anul
9. Se considera tabela Note avnd urmatoarea structura: Note(NrLeg, Den_student,
Nota).
Comanda SQL> SELECT NrLeg, COUNT(Nota) NrNote
From Note
Group By NrLeg;
a. contine erori de sintaxa
b. se realizeaza afisarea mediilor fiecarui student identificat dupa NrLeg
c. afisarea numarului de note primite de fiecare student identificat dupa NrLeg
10.
Se
considera
tabela
Beneficiar
avnd
Beneficiar(Cod_beneficiar, Den_beneficiar, Adresa, Telefon ).
Comanda SQL>DROP TABLE Beneficiar:
a. se sterge baza de date Beneficiar
b. contine erori de sintaxa
c. se sterge tabela Beneficiar

207

urmatoarea

structura:

Capitolul 7
Utilizarea SGBD Access n proiectarea aplicaiilor informatice
Obiective:
nsuirea teoriilor i metodelor de baz n proiectarea bazelor de date Access.
Cunoaterea caracteristicilor complexe ale SGBD-ului Access i fundamentarea tiinific a
utilizrii acestuia n aplicaiile informatice financiar contabile.
Utilizarea sistemelor de gestiune a bazelor de date i a programelor specifice. Conceperea de
machete pentru exploatarea bazelor de date Access utiliznd programele i tehnicile studiate.
Cuvinte cheie:colecii de date, baz de date, colecii de obiecte tip, formular ,interogare, raport,
macro-uri.

7.1 Colecii de obiecte tip ntr-o baz de date Access

7.1.1Obiecte de tip tabel
Reprezint obiectele bazei de date n care se stocheaz datele. Fiecare coloan a
tabelei este denumit cmp, iar fiecare rnd al tabelului constituie o nregistrare.
La crearea unui tabel se solicit definirea cmpurilor, atribuindu-se fiecruia o denumire
unic, avnd un tip de dat i o dimensiune bine precizat
O modalitate de a crea un tabel este aceea de a selecta meniul Create i apoi opiunea
Table.
1. Datasheet View - permite crearea unui tabel n modul foaie de date; este utilizat
pentru inserarea datelelor i vizualizare. Apoi executm click pe butonul OK (Dac se renun la
crearea tabelului executm click pe butonul Cancel). Se va deschide un tabel cu cmpuri
generice: Field 1, Field2...
Pentru a schimba numele cmpurilor din meniul Fields se alege opiunea
Name&Caption, se tasteaz noul nume i se apas tasta Enter. (Fig 7.1).

208

Fig.7.1
2. Design View - permite crearea unui tabel n modul de proiectare.
Pentru a realiza n acest mod un tabel efectum click pe meniul Create apoi selectm
opiunea Table design.
n fereastra aprut n coloana FieldName tastm numele cmpului, n coloana
DataType precizm tipul de dat pentru fiecare cmp iar n coloana Description se precizeaz
de ctre utilizator un text explicativ avnd ca scop s descrie cmpul. (Fig. 7.2).

Fig.7.2
Cheia primar reprezint un identificator unic pentru un tabel; aceasta reprezint un
atribut sau un grup de atribute. Pentru a stabili un cmp al tabelului cheie primar trebuie s
parcurgem etapele:

tabelul trebuie s fie deschis n modul Design View;

se selecteaz cmpul cruia vrem s-i atribuim aceast identificare;

se selecteaz meniul Design i se alege opiunea Primary Key;

Rezultatul acestor etape este apariia unui simbol sub form de cheie n dreptul
cmpului selectat.
209

Dac se ncearc nchiderea noului tabel n modul de vizualizare Design View fr a

specifica o cheie principal, apare un mesaj care anun c nu a fost atribuit nici o cheie
primar.
Executnd click pe butonul Yes n caseta de mesaj determinm Acces-ul s creeze un
nou cmp AutoNumber n tabel i-l specific drept cheie primar. Se poate schimba numele
acestui nou cmp dup cum este necesar. Pentru a introduce nregistrri n tabel selectm
meniul View i alegem opiunea Datasheet View.
Tipurile de date disponibile pentru cmpurile Access sunt:

text - sunt cel mai des folosite, astfel nct Access consider acest tip ca fiind
cel prestabilit. Un cmp text are implicit 50 de caractere, dar se poate alege
lungimea de la 1 la 255;

memo - sunt utilizate pentru a oferi comentarii descriptive. Un cmp Memo nu

poate fi cheie primar i se poate indexa dup el;

number - admite numai numere (nu poate conine litere, sau o dat
calendaristic); poate fi la rndul su de tip: Byte, Integer, Long Integer,
Single, Double, Replication ID, Decimal;

date/time - indic data calendaristic i/sau ora;

currency - indic tipul valut, fiind un numr destinat s indice o valoare

bancar, cu 15 cifre la partea ntreag, iar la partea zecimal pn la sutimi de
ceni;

autonumber - datele de acest tip conin o valoare numeric pe care Access o

introduce automat pentru fiecare nregistrare adaugat ntr-o tabel;

yes/no - datele de acest tip pot primi valorile True/False i pot fi afiate n una;
din formele True/False, respective On/Off;

OLE Object - include elemente grafice realizate din puncte, desene vectoriale,
fiiere cu semnale audio i alte tipuri de date care pot fi create de o aplicaie
OLE Server;

Hyperlink - este un text sau o combinaie de text cu numere stocat() ca un

text i folosit() ca adres a unei pagini Web. Este format() din trei pri: textul afiat, adres i subadres;

Lookup Wizard - creeaz cmpuri care permit utilizatorului s aleag valori din
cadrul altor tabele sau dintr-o list de valori.
n afar de definirea tipului de dat, pentru fiecare cmp se definesc o serie de
proprieti (care difer n primul rnd de tipul de dat ales i de cerinele aplicaiei).
Zona n care se stabililesc proprietile cmpurilor este format din urmatoarele opiuni
(Fig. 7.3).
210

Fig. 7.3

Field Size - aceast propietate stabilete numrul maxim de caractere care

poate fi stocat n tipul de cmp respectiv;

Format - aceast proprietate prezint o list derulant cu formatele disponibile

pentru respectivul tip de cmp;

Decimal Places - proprietatea care se stabilete pentru cmpurile numerice; se

pot stabili poziiile zecimal afiate de un numr;

Input Mask - proprietatea prin care se controleaz introducerea datelor;

Caption - proprietatea utilizat pentru a a afia titlurile numelor de cmp n

modul de afiare Datasheet;

Default Value - proprietatea care permite definirea unei valori implicite care va
fi generat automat n ecranele de culegere a datelor;

Validation Rule - proprietatea care permite definirea restriciilor referitoare la

domeniul de valori;

Validation Text - proprietatea care permite specificarea coninutului textului

care se va afia, n cazul introducerii unei realizri ce nu respect regula de
validare;

Requiered - proprietatea care se utilizeaz n momentul n care se dorete

introducerea n cmpul respectiv a unei valori n mod expres, valoarea
cmpului nu poate fi nul;

Indexed - proprietatea care permite definirea unui fiier index pe atributul

respectiv; indecii asigur mecanismul de regsire rapid a datelor. Un atribut
se indexeaz n condiiile n care atributul cuprinde valori cu gam larg; de
variaie i atributul va fi folosit n mod semnificativ n criteriile de selecie sau
sortare.
211

Relaii ntre tabele

Relaiile ntre tabele se formeaz prin precizarea legturilor ntre un tuplu dintr-un tabel
i tuplurile corespunztoare din alt tabel.
Relaiile standard pot fi de tip:
1. Relaia unu la unu (1:1) corespunde situaiei cnd unui tuplu dintr-o tabel i
corespunde un singur alt tuplu dintr-o alt tabel. Se mai numete i biunivoc;

Exemplu:
Considerm tabela Furnizori i tabela Produs
Codfurnizor
Codprodus
Denfurnizor
Denprodus
Adresa
UM
Contbanca
Preprodus
Banc
Cod furnizor
Relatia 1:1 ntre cele dou tabele se poate transpune prin faptul c: un furnizor poate
livra doar un singur produs, iar produsul este livrat doar de un singur funizor.
Relaia unu la mai muli (1:n) corespunde situaiei n care unui tuplu dintr-o nregistrare
i corespund mai mutte tupluri dintr-o tabel. Tabelul din partea unu a relaiei trebuie s aib o
cheie unic, numit cheie primar, iar tabelul din partea mai muli trebuie s conin o cheie
strin numit cheie extern.
Exemplu:
Considerm tabela Furnizori i tabela
Codfurnizor
Denfunizor
Adresa
Contbanc
Banc

Facturi
Nrfactur
Codfurnizor
Codprodus
Prefactur
Datafactur
Cantitate
Relaia 1: n ntre cele dou tabele se poate transpune prin faptul c un furnizor poate
emite mai multe facturi, iar o factur nu poate fi emis dect de un furnizor.
3. Relaia muli la muli (m:n) corespunde situaiei cnd unui tuplu dintr-o tabel i pot
corespunde mai multe tupluri dintr-o alt tabel. Aceste tipuri de relaii sunt asocieri libere.
212

Exemplu:
Considerm tabela Funizori i tabela CentruComercial
Codfurnizor
Codccom
Denfurnizor
Denccom
Adresa
Cod furnizor
Relaia m:n ntre cele dou tabele se poate transpune prin faptul c: un funizor poate
aproviziona mai multe centre comerciale, iar un centru comercial se poate aproviziona de la mai
muli furnizori. Descrierea procesului de construire a relaiilor dintre tabele se face n fereastra
Relationships (Opiunea Relationships se afl n meniul DatabaseTools). Plasarea tabelelor n
aceast fereastr se face prin intermediul ferestrei Show Table din meniul Relatioships.
Selectarea tabelelor se face acionnd butonul Add sau click dublu pe tabelul respectiv. O relaie
ntre tabele se realizeaz prin operaia drag and drop de la cheia primar a tabelei principale la
cheia extern a tabelei secundare. Legtura ntre tabele este marcat printr-o linie care se
numete linie de corelare. Fereastra de dialog Edit Relationships (se deschide selectnd meniul
Relationships, optiunea Edit Relationship) prezint legtura ntre cheia primar i cheia extern.
(Fig. 7.4)

Fig. 7.4
n partea de jos a casetei de dialog Edit Relatioships exist trei casete de validare;
validarea acestora are urmatoarele efecte:
validarea casetei Enforce Referential Integrity (Impune integritate referenial) n
cadrul aplicaiei, nseamn c n momentul cnd se introduce o nou nregistrare n
tabela secundar, se verific dac valoarea cheii externe se gsete n tabela
primar, n cmpul corespunztor cheii primare. Este necesar ncrcarea datelor n
tabela principal mai nti i apoi n cea secundar;
213

 validarea casetei Cascade Update Related Fields - modificarea unei valori a unei
chei primare din tabela principal duce la modificarea valorilor cheii externe
corespondente din tabela secundar.
Exemplu:
Dac se modific codul unui beneficiar din tabela Beneficiari, se modific i facturile
corespondente.
validarea casetei Cascade Delete Related Recors - tergerea unei valori a cheii
primare din tabela principal duce automat la tergerea nregistrrilor
corespondente din tabela secundar (cele care au valoarea cheii exteme egale cu
valoarea cheii primare).
Exemplu:
Dac se terge un beneficiar, automat se terg i facturile corespondente.
Cmpurile de legtur ntre dou tabele trebuie s fie de acelai tip i s aib aceeai
dimensiune.
7.1.2 Obiecte de tip cerere. Interogarea bazelor de date
Interogarea unei baze de date nseamn regsirea i extragerea informaiilor. O cerere
are ca surs una sau mai multe tabele sau chiar o alt cerere.
Clasificarea. interogrilor:
Interogri de selecie - sunt cele mai utilizate interogri i permit vizualizarea,
modificarea i extragerea datelor din una sau mai multe tabele sau cereri.
Interogri de tip aciune - au ca rol de a actualiza, de a terge, a aduga, a modifica
i de a crea noi tabele. Interogrile de tip aciune sunt:
a. Make Table Query - permit crearea unui nou tabel;
b. Delete Query - permite tergerea uneia sau mai multor nregistrri dintr-un tabel;
c. Append Query - permite adugarea de noi nregistrri la un tabel dintr-un tabel surs;
d. Update Query - permite modificarea unui grup de nregistrri selectate pe baza unui
criteriu dintr-un tabel.
Interogri parametrate - se utilizeaz atunci cnd este necesar modificarea
frecvent a criteriilor de selecie n baza de date.
Interogri de tip Analiz ncruciat permit generarea unor tabele complexe sub
forma unei foi de calcul tabelar
Crearea interogrilor de selecie
Atunci cnd se realizeaz o interogare selectm meniul Create i apoi din grupul
214

Queries se pot alege optiunile Query Wizard i Query Design.

1. Query Design - reprezentnd modul grafic de proiectare.
Pentru a crea o interogare n acest mod accesm butonul OK i se va afia o fereastr
Select Query i caseta de dialog Show Table. (Fig. 7.5)

Fig. 7.5
Fereastra Select Query este structurat n dou pri:
partea superioar, unde sunt afiate structurile tabelelor din baza de date
partea inferioar numit gril de proiectare n care se construiete interogarea din
punct de vedere structural. Aceasta gril de proiectare este cunoscut i sub
denumirea QBE (Query By Exemples).
Caseta de dialog Show Table prezint tabelele existente cnd este selectat butonul
Tables, interogrile cnd este selectat butonul Queries i la accesarea butonului Both sunt
prezentate i tabelele i interogriile
Pentru adugarea tabelelor n fereastra Select Query se acioneaz butonul Add; dup
ce tabelele sunt selectate caseta de dialog Show Table este inchis. n cazul n care mai trebuie
adugat un alt tabel fereastra Show Table va fi readus pe ecran selectnd meniul Query,
opiunea Show Table. Selectarea unui cmp n grila interogrii se face executnd dublu click pe
numele cmpului. Numele cmpului va fi afiat n dreptul rndului Field iar tabelul sursa se
specific n dreptul rndului Table.
Ordonarea se poate face crescator (Ascending) sau descresctor (Descending);
aceast sortare se face la intersecia coloanei cmpului respectiv cu caseta Sort.
Criteriile de selecie
Criteriile de selecie reprezint restriciile pe care le stabilim ntr-o interogare, pentru a
215

identifica anumite nregistrri din baza de date. Criteriile se introduc n celula aflat la intersecia
coloanei cmpului cu linia Criteria din grila de interogare.
Principalele criterii simple sunt prezentate n tabelul 7.7. Criteriile complexe se vor
construi prin utilizarea operatorilor logici And sau Or, care permit legarea criteriilor simple.
Exemplu:
S presupunem c se dorete vizualizarea facturile emise doar ctre beneficiarii care
au conturile la Banca BCR iar modul de vizualizare s se fac in mod descresctor dup cmpul
Cod beneficiar.Fereastra Select Query corespunde cerinelor impuse (Fig. 7.6).

Fig. 7.6
Tabelul 7.7. Principalele criterii simple
OPERAIA

SEMNIFICAIA

EXEMPLU

BETWEEN

Apartenena la un interval de
valori

BETWEEN val_inf and val_super

IN

Apartenena la lis de valori

IN(val 1, val2, ...)

>
<
>=
<=
=

Mai mare
Mai mic
Mai mare sau egal
Mai mic sau egal
Egal

NOT

Operator de negaie

Not valoare

LIKE

Comparare cu un nume generic

LIKE ,, valoare

216

Rezolvarea acestei interogri se regsete mai jos (Fig.7.8).

Fig. 7.8
Crearea unor cmpuri calculate
n prima linie Field liber se introduce formula de calcul care are formula general:
Nume_rezultat: [Cmp 1] Operator matematic [Cmp 2]...
Exemplu:
Se dorete vizualizarea produselor cu codul (120, 121) i calcularea cmpului valoare
pentru tabela Produs (Codprodus, Den produs, um, Pre produs, Cantitate)
Se prezint fereastra Select Query care corespunde cerintelor impuse. (Fig. 7.9).

Fig.7.9
n figura 7.10 se prezint rezultatul obinut.

217

Fig. 7.10
2. Simple Query Wizard - este cea mai simpl metod de a crea o interogare.
Pentru a crea o interogare n acest mod selectm opiunea Simple Query Wizard i apoi
selectm butonul OK.
Fereastra deschis prezint mai multe opiuni:

din lista Tables / Query selectm tabelul sau interogarea dorit;

din lista cmpurilor disponibile Available Field se selecteaz numele de cmp

i apoi pentru a-l muta n lista cmpurilor selectate accesm butonul > (Fig.
7.11); dac se dorete selectarea tuturor numelor de cmpuri selectm butonul
>>. Cnd operaia de selectare a numelor de cmpuri s-a ncheiat executm
click pe butonul Next;

n caseta de text What title do you want fot your query (Ce titlu dorii pentru
interogarea dumneavoastr) introducem numele interogrii i executm click
pe butonul Finish i rezultatul interogrii poate fi vzut (Fig. 7.12 ).

Fig. 7.11

218

Fig. 7.12
3. Crosstab Query Wizard - funcioneaz similar cu opiunea Simple Query Wizard cu
meniunea c se va construi o interogare prin incruciarea tabelelor.
4. Find Duplicates Query Wizard - compar dou tabele i se va construi o interogare
care va prezenta nregistrrile comune.
5. Find Unmatched Query Wizard - este opusul opiunii Find Duplicates Query Wizard,
adic compar dou tabele i va construi o interogare care va prezenta nregistrile care nu
sunt comune celor dou tabele.
Interogri de tip aciune
a. Interogarea Make Table Query
Are ca scop crearea unui tabel format din datele aparinnd unui tabel sau mai multor
tabele. Pentru a transforma o interogare de selecie n una de tip aciune cu funcia de creare a
unei noi tabele se parcurg etapele:

se trece n modul Design View;

se selecteaz meniul Query i se alege opiunea Make-Table ;

pe ecran se afieaz fereastra de dialog Make Table unde se introduce noul

nume al tabelei. Se stabilete dac aceasta va face parte dintr-o baz de date
Access sau de alt tip i dac nlocuiete o alt tabel care este deja creat se
apas apoi butonul OK;

Se selecteaz meniul Query i se alege opiunea Run; se afieaz o caset de

dialog n care se specific numrul de nregistrri n tabela nou creat.
Tabela nou creat prin aceast interogare va fi n fereastra Database la obiectul Tables,
iar cmpurile vor moteni numai tipurile i dimensiunile din tabele surs. Se recomand ca dup
executarea interogrii cu funcia de creare s se stabileasc cheia primar i proprietile
cmpurilor.

219

Exemplu:
Dorim s creem o nou tabel intitulat Beneficiari din jude n care s fie prezeni toi
beneficiarii cu excepia celor din Craiova (Fig.7.13);

Fig.7.13
b. Interogarea Delete Query
Aceast interogare are ca scop eliminarea unui grup de inregistrri dintr-un tabel sau
mai multe tabele.
Pentru a crea o cerere de tip aciune Delete Query n vederea tergerii unui grup de
nregistrri trebuie s se plece de la interogarea de selecie.
Se parcurg etapele:

se trece n modul Design View;

se selecteaz meniul Query i se alege opiunea Delete query care va afia n

grila de proiectare linia Delete;

se selecteaz meniul Query i se alege opiunea Run; se afieaz o caset de

dialog care va prezenta numrul de nregistrri ce vor fi terse. Se selecteaz
butonul Yes pentru tergerea numrului de nregistrri care respect condiia
specific.

Exemplu:
Dorim s tergem din tabela Factura toate facturile care au numrul facturii mai mic de
124 (Fig. 7.14).

220

Fig. 7.14
c. Interogarea Append Query
Aceast interogare se folosete pentru a insera nregistrri din unul sau mai multe
tabele surs ntr-un tabel destinaie.
Pentru a transforma o interogare din selecie n una de tip aciune de adugare se
parcurg etapele:

se trece la modul Design View;

se selecteaz meniul Query i se alege opiunea Append query, se va afia

caseta de dialog Append unde se introduce numele tabelei de destinaie i se
selecteaz butonul OK;

se selecteaz meniul Query i se alege opiunea Run; se afieaz o caset de

dialog care va prezenta numrul de nregistrri ce vor fi adugate. Se
selecteaz butonul Yes pentru adugarea nregistrrilor.

Exemplu:
Dorim s adugm n tabela Beneficiari jude i acei beneficiari din Craiova, dar care au
contul la banca bcr. Tabela Beneficiari din jude este tabela destinaie iar tabela Beneficiari
este tabela surs. (Fig 7.15)

221

Fig. 7.15
d. Interogarea Update Query
Acest interogare se folosete pentru a efectua modificri globale ntr-un grup de
nregistrri
Pentru a transforma o interogare de selecie n una de tip aciune de modificare se
parcurg etapele:
se trece n modul Design View;
se selecteaz meniul Query i se alege opiunea Update Query; se va introduce n
grila de proiectare linia Update To i se schimb numele interogrii ntr-o interogare
de modificare;
se introduc n linia Update To expresiile de calcul sau valorile cu care se vor face
modificrile;
se selecteaz meniul Query i se alege opiunea Run; se afieaz o caset de
dialog n care sunt prezentate numrul de nregistrri ce vor fi modificate. Se
selecteaz butonul Yes pentru modificarea nregistrrilor.
Observaie:

Nu se pot modifica valorile cheii primare sau aceasta nu poate primi valoarea
Null

Nu este permis adugarea sau modificarea unei nregistrri cu valoare

identic a unui cmp care este declarat n structura tabelei ca fiind index unic.

Exemplu:
n urma unei erori, anumite facturi (nu toate) au fost introduse cu data emiterii cu trei
zile mai devreme dect data real. Pentru a corecta aceast eroare se va realiza interogarea
conform Fig.7.16.

222

Fig. 7.16
Cnd se execut interogarea apare o fereastr de dialog (Enter Parameter Value) n
care introducem Nr. factura care se va actualiza, iar dup apsarea butonului OK apare un
mesaj de avertizare care ntreab dac suntei siguri c vrei s reactualizai nregistrrile. Dac
se apas butonul Yes cmpul data factura din tabelul Factur va fi actualizat.
Interogri parametrate
Aceste interogri se utilizeaz atunci cnd ntr-o interogare este necesar modificarea
frecvent a Criteriilor de selecie.
n grila Design pe coloana dorit Criteria n locul unei expresii se vor preciza ntre
paranteze drepte un mesaj ce este afiat n momentul executrii interogrii pentru ca utilizatorul
s introduc criteriul de selecie dorit.
Interogri de tip analiz ncruciat
Aceste interogri permit generarea unor tabele complexe sub form matriceal n care
numele liniilor (Li) i a coloanelor (Cj) reprezint criterii mixte de grupare, iar valorile din celulele
tabelului (Vij) se obin prin aplicarea unei funcii predefinite asupra unui cmp dintr-o tabel,
Tabelul 7.17
L1

C1

C2.

CN

V11

V12

V1n

L2
Lm

Vm1

Vmn
Tabelul 7.17

223

7.1.3 Obiecte de tip form

Formularele reprezint obiecte ale bazei de date ce permit introducerea sau extragerea
datelor dintr-o tabel. Formularele au mai multe utilizri:
afiarea i editarea datelor - este permis afiarea datelor n modul dorit de utilizator
iar datele pot fi modificate;
introducerea de date - este utilizat atunci cnd formularul introduce date ntr-un
tabel asociat;
afiarea de mesaje;
controlul operaiilor realizate de aplicaie;
tiprirea informaiilor.
Formularele pot fi afiate n mai multe moduri:
modul Design - este modul utilizat pentru schimbarea modului de prezentare i
proprietile formularului;
modul Form - este modul de afiare al unui formular n curs de utilizare;
modul Datasheet- este modul de afiare direct a tabelului sau interogrii.
Realizarea formularelor
Atunci cnd se realizeaz un formular se selecteaz meniul Create i apoi butonul Form
Design
Pentru a crea formularul folosind modul Design View trebuie s se selecteze opiunea
Form Design din fereastra New Form.
Din caseta cu lista derulant pentru a realiza un formular pentru introducere de date
trebuie ca pentru nceput s asociem formularului respectiv un tabel sau o interogare.
Acest mod nu permite includerea ntr-un formular a mai multor cmpuri coninute din
tabele diferite.
Totui se poate construi un formular pe baza unei interogri care, la rndul ei, este
realizat prin folosirea mai multor tabele.
Pe ecran apare fereastra cu ecranul de proiectare a formularului.
Fereastra e prevzut pe margini cu dou rigle (pe vertical i pe orizontal) ce ajut
proiectantul s alinieze obiectele.
Obiectele care fac parte din formular se numesc controale.
Pentru a aduce controalele pe form avem nevoie de trusa de instrumente Toolbox
i/sau lista cmpurilor (Field List) Fig.7.18.

224

Fig. 7.18
Principalele tipuri de controale din trusa de instrumente Toolbox sunt: (Fig 7.19)

Fig. 7.19
Indicator - instrument folosit la proiectarea controalelor;
Control Wizards activeaz/dezactiveaz utilitarele Wizards folosite la generarea
unor controale- mai complexe;
Label - control cu coninut fix care afieaza text;
Text Box - caseta de text folosit pentru editarea i afiarea datelor;
Option Group - creaz o caset de grup i poate grupa mai multe controale (buton
de opiune, butoane validare);
Toogle Button - creaz un buton de comutare (Yes / No; On / Off; True / False);
Combo Box - mbin prioritile unei casete de text cu cele ale unei casete de tip
list crend o caset combinat. Aceast caset combinat permite editarea datelor
i selectarea unei valori dintr-o list derulant;
Option Button - creaz un buton de opiune; se utilizeaz mai multe butoane de
opiune, alegerea unui buton duce la deselectarea celorlalte butoane;
Check Box - creaz o caset de validare; se utilizeaz mai multe casete de validare
putnd accesa mai multe casete n acelai timp;
List Box creaz o caset de tip list i afieaz tot timpul valorile existente n topul
asociat;
Command Button - creaz un buton de comand, utilizat pentru ntreprinderea unor
aciuni;
225

 Image - introduce n formular fiiere grafice cu extensia .bmp, .wmf, .emf .gif, etc;
Subform / Subraport - creaz un subformular n cadrul unui alt formular;
Page Group - delimitator de pagin, mparte formularul n mai multe pagini.
Pentru a aduga controale din List Field pe form selectm cmpurile i cu butonul
mouselui apsat lum cmpurile din Field List i le aezm n fereastra de proiectare (prin
metoda drag and drop).
n mod automat se va realiza o caset de text legat de cmp i o etichet indicnd
numele cmpului respectiv.
n cazul n care dorim s adugm controale calculate n formular din trusa de
instrumente Toolbox trebuie desenat un control caset de text.
Pentru acest lucru trebuie parcurse etapele:
se execut click pe caseta de text;
se mut cursorul deasupra formularului i cursorul are o form de cruce cu forrna
casetei de text;
se plaseaz cursorul n locul unde va fi colul din stnga sus al controlului;
se deplaseaz mouseul pn cnd controlul are dimensiuni dorite;
se d drumul butonului de mouse.
Un alt mod de a aduga controale din trusa de instrumente Toolbox este prin dublu click
pe caseta de text i apoi fcnd click pe caseta de text i apoi fcnd click de attea ori cte
casete de text avem nevoie; apoi se dezactiveaz caseta de text printr-un click al mousului n
Toolbox pe caseta de text.
Exemplu:
Avem tabela Produse (Cod produs, Den produs; Pret, Cantitate). Dorim s calculm
cmpul valoare.
Formularul va arta conform figurii urmtoare (Fig. 7.20)

Fig. 7.20
226

Pe lnga zona Detail cu care am lucrat, un formular mai conine:

Seciunea de antet (Form Header);

Antetul de pagin (Page Header);
Subsol de pagin (Page Footer);
Subsolul formularului (Form Footer).

n figura 7.21 sunt prezentate elementele formularului:

Seciunea de antet (Form Header)
Aceast zon este folosit pentru a afia titlul formularului. Aceast zon nu este
vizibil n modul Datasheet. Pentru a vizualiza aceast zon se selecteaz. meniul View i apoi
opiunea Form Header /Footer
Antetul de pagina (Page Header)
Aceast zona apare cnd formularul este scos la imprimant. Pentru a fi disponibil se
selecteaz meniul View i apoi opiunea Page Header/Footer.
Subsol de pagin (Page Footer)
Aceast zon apare cnd formularul este scos la imprimant. n aceast zon se poate
specifica numrul de pagini, data curent
Subsolul formularului (Form Footer)
Aceast zon poate s conin diferite informaii ca de exemplu totalul general sau
diverse controale.

Fig. 7.21
Subformulare
Un subformular este un formular inclus ntr-un alt formular, pentru a permite afiarea
227

datelor din mai multe tabele sau interogri, aflate n relaii de tipul 1:1 sau 1:n.
n formularul principal vor fi afiate date din partea unu a relaiei, iar n subformular cele
din partea mai muli.
Crearea unui ansamblu formular - subformular se poate face:
Crearea separat a celor dou i apoi combinarea;
Crearea formularului si subformularului concomitent;
Crearea subformularului i adaugarea lui la un formular existent.
Prezentm n continuare realizarea ansamblului formular -subformular n prima
variant; crearea separat a celor dou i combinarea este varianta cea mai simpl.
Se parcurg etapele:
se creaz formularul principal;
se creaz subformularul avnd grij ca acel cmp de legtur s nu fie inclus
deoarece exist deja n formularul principal;
se face legatura ntre formularul principal i subformular;
se deschide formularul principal n modul Design View i se trage cu mouse-ul
numele subformularului din fereastra Database n cadrul formularului principal;
se verific legtura i apoi rezultatul.
Exemplu: Vom exemplifica construcia ansamblului formular-subformular pe aplicaia Facturile
emise beneficiarilor. (Fig.7.22).

Fig.7.22
Formularul principal - Beneficiari

228

Proprietile obiectelor - Forms

Fiecare obiect definit n modul Design View (fereastra de proiectare a formularului) are
nite proprieti.
Aceste proprieti modific comportamentul obiectului (Fig. 7.23)

Fig. 7.23
Proprietile formularului se pot modifica n cadrul ferestrei de proprieti care se
activeaz prin selectarea meniului View i apoi opiunea Properties.
n aceast fereastr proprietile formularului se grupeaz n 5 categorii:
1. Format - prezint proprietile care se refer la culoare, dimensiune, mod de
vizualizare.
Cele mai folosite proprieti sunt:

Caption - se specific numele formularului;

Default View - se specific modul implicit de afiare;

Scroll Bars - se seteaz barele de defilare vizibile n cursul execuiei;

Navigation Buttons - specific dac formularul are butoane de navigare n

cursul execuiei;

Border Style - se specific tipul bordurii;

Control Box - indic prezena meniului sistem n bara de titlu.

2. Data - prezint proprietile care se refer la datele asociate controlului

Record Source - conine sursa de date a formularului;

Filter - conine criteriul de selecie care se va aplica nregistrrilor din formular.

Pentru ca filtrul s fie activ, proprietatea din formular Filter On trebuie sa aib
valoarea True;
229

Order By - permite specificarea cmpurilor dup care vor fi sortate

inregistrrile.
3. Event - grupeaz evenimentele ce pot fi tratate fie prin proceduri sau funcii scrise n
limbajul VBA, fie prin macro-uri;
Exist 3 posibiliti:

evenimentul tratat printr-o funcie - proprietatea evenimentului va conine o

expresie de forma: Nume funcie ([Lista parametrii]);

eveniment tratat printr-o procedur eveniment; editarea procedurii se face prin

acionarea butonului Build Wizard;

eveniment tratat printr-un macrou - proprietatea eveniment va conine numele

macro-ului.
4. Other - prezint alte proprieti suplimentare.
5. All - prezint toate proprietile care se regsesc n grupele prezentate.
Form Wizard
Pentru a crea un formular n modul Form Wizard trebuie parcurse etapele:
n fereastra Databases se selecteaz meniul Create i apoi butonul Form Wizard. Din
lista derulat Tables/Queries alegem tabelul sau interogarea din care selectm cmpurile.
Din lista de cmpuri disponibile Available Fields se selecteaz cmpurile dorite n lista
cmpurilor selectate Selected Fields. (Fig. 7.24).

Fig. 7.24

230

n situaia cnd vrem s adaugm n formulare alte crnpuri din alt tabel ne ntoarcem la
lista derulant Tables / Queries. Se selecteaz butonul Next pentru a trece la fereastra unde
alegem modul de prezentare Columnar, Tabular, Datasheet sau Justified.
n fereastra urmtoare se alege stilul de vizualizare, iar la selectarea butonului Next se
ajunge n ultima fereastr unde se salveaz formularul sub ce nume se dorete.
AutoForm: Columnar
Se creaz un formular cu cmpurile aezate pe coloane.

7.1.4 Obiecte de tip Raport

Tabelele i formularele furnizeaz diverse ci de introducere a nregistrrilor n baza de
date, iar interogrile permit sortarea i filtrarea datelor n baza de date.
Rapoartele reprezint un alt obiect al unei baze de date utilizat pentru a rezuma datele
i a oferi un rezultat care poate fi vizualizat pe ecran sau care se poate lista la imprimant.
Realizarea rapoartelor
Atunci cnd se creaz un raport selectm meniul Create i apoi butonul REPORT
Report Design
Pentru a crea un raport n modul Design View trebuie s se selecteze opiunea Report
Design.
Din caseta cu lista derulant pentru a crea un raport trebuie ca pentru nceput s se
asocieze formularului respectiv un tabel sau o interogare. Se execut click pe butonul OK dup
ce s-a ales tabelul sau interogarea dorit.
Ca i la modul Form Design aici exista o trus de instrumente Toolbox iar modul de
lucru este identic (selectarea obiectelor, mutarea i redimensionarea obiectelor).
Report Wizard
Cu Report Wizard se poate construi un raport care utilizeaz mai multe tabele i
interogri.
Pentru a crea un raport cu Report Wizard se parcurg urmtoarele etape:
se selecteaz opiunea Report Wizard din fereastra New Report i apoi butonul OK.
Din lista de cmpuri disponibile, Available Fields, selectm cmpul dorit i pentru a-l
muta n lista cmpurilor selectate Selected Fields se acceseaz butonul > (Fig.
7.25);

231

Fig. 7.25
pentru a trece la fereastra urmtoare se selecteaz butonul Next; n fereastra
afiat se grupeaz nregistrrile dup oricare din cmpurile selectate. Se
selecteaz cmpul respectiv i apoi se selecteaz butonul >. Se pot avea mai
multe niveluri de grupare. (Fig. 7.26) Pentru a continua se selecteaz butonul Next.
n noua fereastr se realizeaz sortarea nregistrrilor din raport. Dac se sorteaz
nregistrri dup un anumit cmp sau dup mai multe cmpuri se deschide fereastra
derulant i se pot selecta maxim patru cmpuri de sortare. Sortarea n ordine
ascendent se face implicit (Ascending); dac se dorete schimbarea ordinii se
execut un click pe butonul Ascending i se va afia sortarea descendent
(Descending);

232

Fig. 7.26
setarea butonului Next duce la apariia urmtoarei casete de dialog unde se alege
tipul raportului. Sunt enumerate mai multe stiluri i se alege cel dorit. Se poate alege
i orientarea pe care o poate avea raportul tiprit. Portrait - de-a lungul hrtiei sau
Landscape - de-a latul hrtiei; la urmtoarea caset de dialog se alege un stil pentru
raport;
n ultima fereastr se alege un titlu pentru noul raport i apoi se selecteaz butonul
Finish.
Raportul poate fi vizualizat n modul Print Preview i de aici se poate tipri raportul dac
suntei multumii de felul cum arat. n modul Print Preview se poate mri sau micora
dimensiunea de afiare a raportului pe ecran utiliznd instrumentul Zoom (se execut click o
dat pe butonul mouse-ului pentru mrire i se execut click din nou pentru micorare).
Pentru tiprirea raportului se selecteaz meniul File i apoi opiunea Print. Dac trebuie
schimbate marginile raportului sau s se modifice orientarea raportului pe pagin se selecteaz
meniul File i opiunea PageSetup. Se afieaz caseta de dialog Page Setup (Fig. 7.27).

233

Fig. 7.27
n caseta de dialog Page Setup sunt etichetele:
Margins -permite setarea marginilor de sus, de jos, din stnga i din dreapta ale
paginii;
Page - permite schimbarea orietrii paginii raportului pe pagina tiprit;
Columns - permite schimbarea numrului de coloane din raport i distana dintre
coloane.
Auto Report Columnar i Auto Report Tabular
Se va crea un raport automat n care datele vor fi afiate ntr-o coloan pentru
AutoReport Columnar sau sub form de tabel pentru Auto Report Tabular.
Cu instrumentul Auto Report se pot crea rapoarte pornind de la un singur tabel sau o
singur interogare.
Dac se dorete construirea unui raport care s aib la baz mai multe tabele, mai nti
trebuie creat o interogare pe baza acelor tabele i apoi se creaz raportul.
Chart Wizard
Creaz un raport n interiorul cruia va fi prezentat un grafic.
Label Wizard
Creaz etichete potale care pot fi tiprite la imprimant pe suporturi speciale de hrtie.
234

7.1.5 Obiecte de tip Macro

Un obiect tip macro este desemnat printr-un nume i are ca scop automatizarea unor
aciuni asupra unor obiecte ale bazei de date.
Macrourile definesc o serie de comenzi care se execut automat la apariia unor
evenimente.
Macrourile pot fi ataate unui formular sau control, n scopul automatizrii unor operaii
diverse (tiprirea rapoartelor, deschiderea i inluderea formularelor, lansarea n execuie a unor
programe, executarea unei fraze SQL).
Pentru realizarea unei comenzi trebuie parcurse etapele:
din fereastra Database se selecteaz obiectul Macros i apoi butonul New i se
deschide fereastra Macro (Fig. 7.28 );

Fig. 7.28
n coloana Action se selecteaz din list aciunea dorit;
n coloana Comment se tasteaz n dreptul fiecarei aciuni eventualele explicaii.
Aceste comentarii sunt opionale;
n grila Action Arguments din partea inferioar se completeaz argumentele aciunii
selectate. Coninutul grilei de argumente se modific n funcie de elementul selectat
n lista Action, fiecare aciune are propriile argumente.
Tipuri de aciuni macro
n Microsoft Access utilizatorul are posibilitatea s aleag n lista Action a ferestrei
Macro dintr-un numr de 56 acuni prestabilite.
n continuare vor fi prezentate cele mai importante aciuni macro grupate dup criteriul
funcionalitii acestora:

235

1. Aciuni macro pentru manipularea obiectelor de date:

Denumire
Scop
OpenForm
Deschide sau activeaz un formular ntr-unul din modurile
de afiare
OpenModule
Deschide modulul specificat i afieaz procedura indicat
OpenQuery
Deschide o interogare de selecie sau ncruciat ori
execut o interogare
OpenReport
Deschide un raport n modul de afiare specificat i filtreaz
nregistrrile nainte de tiprire
OpenTable
Deschide o tabel
Close
nchide un obiect deschis al bazei de date
DeteteObject
terge obiectul specificat
SetValue
Stabilete valori sau modific proprietile pentru cmpurile,
controalale i proprietile formularelor i rapoartelor.
GoToControl
Deplaseaz cursorul la cmpul specificat sau la obiectul de
control din nregistrarea curent dintr-un formular, tabel
sau interogare
ApplyFilter
Execut filtrarea nregistrrilor dintr-o tabel sau raport.
Maximize
Maximizeaz fereastra activ
Minimize
Minimizeaz fereastra activ.
MoveSize
Deplaseaz i redimensioneaz fereastra activ
RenameObject Redenumete obiectul specificat
2. Aciuni macro pentru navigarea n cadrul nregistrilor bazei de date
Denumire
Scop
FindNext
Identific prima nregistrare care este identic cu cea
specificat de aciunea
FindRecord
Caut o nregistrare
GoToRecord
Produce deplasarea la nregistrarea specificat

3. Aciuni pentru controlul execuiei aplicaiei

Denumire
Scop
Beep
Produce un semnal de avertizare
CancelEvent
Anuleaz evenimentul care a cauzat executarea
comezii macro
236

MsgBox

Quit
RunApp
RunCode
RunMacro
RunSQL
SetWarnings
StopMacro
StopAllMacros

Afieaz o caset cu un mesaj de avertizare i

ateapt ca utilizatorul s execute un click pe butonul
OK
Inchide execuia programului Access
Execut o aplicaie Windows sau MS-DOS
Execut o funcie definit de ulilizator scris n limbajul
Visual Basic pentru aplicaii (VBA)
Execut comanda macro specificat
Execut o instruciune SQL de tip aciune
Activeaz sau dezactiveaz mesajele de control
prestabilite
Oprete comanda macro ce conine aciunea
Oprete toate comenzile macro aflate in aciune

4. Aciune pentru crearea i modificarea intefeei cu utilizatorul

Denumire

Scop

AddMenu

Adaug un nou meniu pentru formular sau pentru

ntreaga aplicaie;

ShowToolbar

Ascunde sau afieaz pe ecran o bar de instrumente

SetMenuItem

Seteaz starea (activ sau inactitv) a unui element din

meniuri

5. Aciuni pentru atomatizarea ieirilor aplicaiei i facilitarea comunicrii cu

alte programe
Denumire

Scop

PrintOut

Tiprete obiectul activ al bazei de date

TransferDatabase

Permite importarea sau exportarea obiectelor

bazei de date

TransferSpreadsheed

Export sau import date din fiiere create cu

procesoare de tabele precumMicrosoft Excel

237

SendObject

Include obiectul activ al bazei de date ntr-un

mesaj trimis prin pota electronic.

7.2 Dezvoltarea rapid a unei aplicaii

Se dezvolt rapid o aplicaie de eviden a furnizorilor . Pentru a rezolva aceast
aplicaie trebuie s realizam n baza de date (EvidFurniz) dou tabele Furnizori i Factura.
Tabela Furnizori are urmtoarea structur:
Furnizori (cod furniz., den furniz., adresa, banca, cont banca).
Iar tabela Factura are urmtoarea structur:
Factura (nr. Fact., data fact., val. Fact., cod furniz.).
Observaie:
Cmpul subliniat cu linie continu este cheie primar n tabel iar cmpul subliniat cu
linie punctat este cheie extern.
Etapele care trebuie parcurse sunt:
se alege opiunea BlankDatabase din panoul pentru taskuri Microsoft Access ;

Fig. 7.29
Numele bazei de date (EvidFurniz)se tasteaz n rubrica File name i apoi se
selecteaz butonul Create.
n baza de date trebuie incluse cele dou tabele (Furnizori i Factura). Acest lucru se
poate face prin exploatarea ferestrei Database i anume:
eticheta Tables este implicit selectat;
se afieaz pe ecran fereastra New Table (Fig. 7.30)

238

Fig.7.30
se alege opiunea Design View (Fig.7.31);

Fig.7.31
Apare fereastra Save As, se denumete tabelul i apoi click pe butonul OK;
se afieaz fereastra Table n care trebuie introduse cmpurile tabelului creat.
n coloana FieldName se tasteaz numele cmpului, n coloana DataType precizm
tipul de dat i n coloana Description se precizeaz un text explicativ.
n urma introducerii acestor elemente fereastra Table va arta conform Fig.7.32

239

Fig.7.32
Observaie:
Dac nu se precizeaz cmpul ce constituie cheia primar, Access genereaz automat
cmpul ID tip AutoNumber care prin valorile sale, va identifica unic nregistrrile de date.
Dup ce a fost creat structura tabelului trebuie introduse nregistrri. n fereastra
Database se selecteaz tabelul Furnizori i se acioneaz butonul Datasheet View i apoi se
introduc nregistrrile (Fig.7.33).

Fig 7.33
Parcurgnd aceleai etape, se creeaz tabelul Factura.
Se dorete s se selecteze din tabela Furnizori numai aceia care sunt din Craiova i au
contul la banca "bcr".
Pentru rezolvarea acestei probleme se parcurg etapele:
240

 se creeaz o cerere: din fereastra Database se selecteaz obiectul Queries i apoi

se selecteaz butonul Create. Pe ecran se afieaz caseta de dialog New Query.
Pentru cereri simple se selecteaz butonul OK. (Fig.7.34)

Fig.7.34
se precizeaz sursa de date din caseta de dialog Show Table selectnd tabela
Furnizori (Fig.7.35).

Fig.7.35
n interfaa QBE, care se va afia pe ecran sunt specificate cmpurile necesare:
Denumire furnizor, Adresa furnizor, Banca; aceste cmpuri sunt selectate prin dublu
click din tabela Furnizori aflat n partea de sus a ferestrei.
La intersecia dintre cmpul Adresa i linia Criteria se tasteaz "Craiova" iar la
intersecia dintre Banc i linia Criteria se tasteaz bcr (Fig.7.36).

241

Fig. 7.36
Pentru a vedea rezultatul interogrii se selecteaz meniul View i apoi opiunea
Datasheet View (Fig. 7.37).

Fig .7.37
Observaie:
Microsoft Acces genereaz automat exprimarea cererii n limbajul SQL. Dac se
selecteaz meniul View i apoi opiunea SQL View, pe ecran se afieaz fereastra SQL al crui
coninut este Fig. 7.38

242

Fig.7.38
Cererea se poate simplifica de ctre utilizator folosind limbajul SQL Standard.
Cererea din Fig. .9 se poate scrie SQL Standard astfel:
SELECT Denumire furniz, Adresa furniyori, Banca
FROM furnizori
WHERE adresa = craiova AND banca = bcr
Unde:
SELECT precizeaz ce se selecteaz
FROM - din ce tabel
WHERE - condiia care trebuie s o ndeplineasc nregistrrile pentru a fi selectate
Operaiile de actualizare a bazelor de date sau de afiare se pot face folosind machete
numite formulare.
Pentru a crea automat un formular se selecteaz tabela sau interogarea dorit n
fereastra Database i apoi se alege din meniul Create, opiunea FormWizard.
Pe ecran se afieaz un formular tip coloan (Fig.7.39).

243

Fig.7.39
Formularul construit automat poate fi apoi modificat; pentru a fi modificat se alege
meniul Create, opiunea Form i apoi Design View
De exemplu, dorim s creem un control care s ne poziioneze pe urmtoarea
nregistrare. Pentru a crea un astfel de control trebuie parcurse etapele:
Plasarea i definirea unui buton de comand din trusa de instrumente Toolbox.
(Fig.7.40);

Fig.7.40
Prin glisare se va plasa butonul de comand folosind asistentul Command Buton
Wizard.
Din lista de opiuni disponibile "Categories se selecteaz Record Navigation i
apoi se selecteaz butonul Next.
244

 n noua fereastr se alege simbolul specificat pentru controlul respectiv i apoi se

selecteaz butonul Next. (Fig.7.41).

Fig.7.41
n ultima fereastr se cere un nume pentru butonul de comand i apoi se
selecteaz butonul Finish.
n final grila de proiectare arat conform Fig.7.42.

Fig.7.42
n acelai mod se creeaz i butoane pentru tergerea unei nregistrri , pentru
adugarea unei nregistrri, etc. Se dorete ca rezultatul interogrii unei baze de date s fie
prezentat sub forma unei situaii finale. Pentru aceasta utilizatorul trebuie s construiasc un
obiect tip raport.
Din fereastra Database se alege obiectul Reports , se alege meniul Create i apoi
butonul Report. Pe ecran apare fereastra New Reports (Fig. 7.43).

245

Fig.7.43
Modelul raportului generat poate fi mbuntit: se selecteaz meniul Create, Report i
apoi opiunea Design View.
Pe ecran se afieaz modelul raportului pe care utilizatorul l poate modifica (Fig.7.44).

Fig. 7.44
7.3 Faciliti Access pentru dezvoltarea de aplicaii
7.3.1 Importul i exportul de date
Una dintre caracteristicile principale ale unui S.G.B.D. const n posibilitatea acestuia
de a importa/exporta date din/n fiiere de formate diferite. Access permite importarea datelor
dintr-o serie de S.G.B.D.-uri (Access, dBase III, dBase IV, dBase5, FoxPro sau orice baz de
date disponibil prin ODBC), precum i din alte fiiere (de tip text, Excel, HTML etc.).
Pentru importarea datelor se va selecta Meniul External Data, Import&Link (Fig. 7.45)

246

Fig. 7.45

Dac fiierul surs este:

baza de date Access, atunci se pot importa toate tipurile de obiecte ale bazei de
date (tabele, interogri, formulare etc.);
un fiier baz de date dBase (.dbf)/FoxPro (.dbf)/Paradox (.db), atunci pentru a fi
importai i indecii, fiierele index asociate (.ndx sau .mdx pentru dBase, .idx sau
.cdx pentru FoxPro, .px pentru Paradox) trebuie s existe n acelai director cu
fiierul de date. De asemenea, dac fiierul de date conine cmpuri de tip memo,
atunci fiierele memo asociate (.dbt) trebuie s fie disponibile n acelai director;
foaie de calcul (Excel, Lotus etc.), atunci toate celulele importate trebuie s conin
valori ngheate (celulele care conin formule vor fi importate sub form de celule
goale);
un fiier de tip text, atunci utilizatorul trebuie s delimiteze datele ce vor forma
cmpurile din noua tabel.
Exportarea datelor este posibil n orice format din care se poate face i importul.
Pentru a exporta un obiect al bazei de date, se selecteaz opiunea Export din meniul Access.
(Fig.7.46).

Fig. 7.46

247

7.3.2. Ataarea tabelelor n aplicaii

Tabelele legate pot fi folosite pentru a facilita lucrul n cadrul unei reele de calculatoare.
Tabelele legate nu sunt tabele propriu-zise, ci legturi dinamice ctre obiectele de tip tabel aflate
n alte baze de date. Se pot crea legturi chiar i spre fiiere de tipuri diferite (n general fiiere
de tipul celor suportate pentru importul de date): Access, dBase, FoxPro, Excel, Paradox, HTML
etc. Utilizatorii pot actualiza datele legate, dar nu pot face modificri de structur (nu pot
aduga, modifica sau terge cmpuri).
Aceast facilitate este frecvent folosit pentru crearea unor aplicaii de tip frontend/back-end: pe server-ul reelei se vor afla tabelele surs (componente back-end) fie ntr-o
baz de date Access, fie n fiiere de tipul celor recunoscute pentru importul de date, iar pe
staiile de lucru (workstations) se vor regsi fiierele Access ( componente front-end), ce conin
celelalte obiecte ale aplicaiei (interogri, formulare, rapoarte, module), precum i legturi ctre
tabelele aflate n baza de date de pe server. n felul acesta, toi utilizatorii locali vor avea acces
la aceleai date, staiile de lucru nu vor fi suprancrcate cu baza de date complet, iar traficul
de pe reea se va reduce suficient de mult.
Pentru a crea tabele legate se procedeaz astfel:
Se selecteaz Meniul External Data-> Import&Link din meniul Access.
n fereastra Link se selecteaz baza de date (fiierul) ca conine tabelele surs: (Fig
7.47).

Fig.7.47
Se selecteaz tabelele pentru care se vor crea legturi: (Fig 7.48). Dac baza de date
surs este mutat, tears sau redenumit, atunci se impune refacerea legturilor ctre tabelele
acesteia.
248

Fig. 7.48
Pictograma folosit pentru afiarea tabelelor legate n fereastra bazei de date, este
nsoit de o sgeat de culoare albastr , orientat spre dreapta. (Fig.7.49).

Fig.7.49
7.3.3 Replicarea bazelor de date
Access pune la dispoziia utilizatorilor aceast facilitate, n special pentru asigurarea
unor copii de siguran ale bazei de date.
Prin replicare se obin dou baze de date: Design Master (derivat din baza de date
249

original) i copia, numit Replica. Numai baza Design Master va permite efectuarea
modificrilor asupra obiectelor replicate (obiectele comune celor dou baze de date). Tabelele
replicate sunt sincronizate n ambele sensuri, adic orice actualizare fcut asupra datelor (fie n
Master Design, fie n replic) se va realiza automat i n cealalt baz de date. Dac utilizatorul
creeaz noi obiecte n baza Design Master, poate decide dac acestea vor fi create automat i
n baza Replica. Aceast operaie nu este posibil, dac se creeaz noi obiecte n baza replic.
Pentru crearea unei replici a bazei de date curente, se va selecta Meniul
DatabaseTools->Create Replica din meniul Access. Pentru aceast procedur, baza de date
curent este salvat ntr-o arhiv de siguran (folosit pentru restaurare n cazul n care se
revine asupra operaiei sau cnd operaia de replicare a euat) i se vor crea cele dou baze de
date replicate (Master Design i Replica). Baza de date Master Design va avea dimensiunea
mai mare dect baza de date original, deoarece operaia de replicare creeaz noi obiecte
sistem (tabele, cmpuri i proprieti). Astfel, fiecare tabel replicat va conine n plus trei
cmpuri sistem, necesare sincronizrii: s_Generation,s_GUID i s_Lineage.
Baza Master Design nu va mai putea fi transformat ntr-o baz de date normal dect
numai prin importarea/exportarea obiectelor sale dintr-o/ntr-o astfel de baz de date!
7.3.4 Protejarea bazelor de date
Protejarea are ca scop prevenirea accesului neautorizat la obiectele unei baze de date.
Access ofer mai multe posibiliti de protejare a bezelor de date prin:

Ascunderea obiectelor bazei de date;

Conversia bazei de date n format MDE;
Stabilirea unei parole de acces la baza de date;
Crearea unor catogorii diferite de utilizatori (protecie la nivel de utilizator);
Criptarea bazei de date.

1.Ascunderea unui obiect al bazei de date se poate realiza prin selectarea clic dreapta
a mousului pe denumirea obiectului respectiv si alegerea opiunii Hide in this Group (Fig. 7.50)

250

Fig. 7.50
2. Conversia bazei de date n format MDE are ca scop prevenirea citirii sau modificrii
obiectelor de tip formular, raport sau modul. Utilizatorul va putea modifica ns structura
tabelelor i a macrouri-lor.
Prin operaia de conversie se creeaz un nou fiier cu extensia .mde, baza de date
original rmnnd intact.
Salvarea bazei de date n formatul MDE are drept efect:

inhibarea vizualizrii, modificrii sau realizarea formularelor, rapoartelor sau

modulelor n modul Design View;

blocarea importului de formulare, rapoarte i module ale altor aplicaii,

rmnnd viabil posibilitatea de a importa obiecte de tipul tabele, query i
macro din alte baze de date;

nu se vor putea exporta spre o alt baz de date rapoartele, formularele i

modulele, excepie fcnd tabelele, query-urile i macro-urile;

imposibilitatea modificrii proprietilor i metodelor obiectelor, deoarece o

baz de date de tip MDE nu mai conine codul surs;

prevenirea adugrii, tergerii sau schimbrii referinelor la librriile de obiecte

sau la alte baze de date;
Bazele de date replicate nu pot fi convertite n format MDE.
Formatul MDE este frecvent folosit pentru bazele de date front-end, deoarece conine
251

codul compilat al modulelor, formularelor i rapoartelor (fiind astfel i mai rapid n execuie dect
formatul standard)
3.Folosirea unei parole la deschiderea bazei de date este una din cele mai folosite
modaliti de asigurare a securitii bazelor de date individuale. Definirea unei parole este
posibil numai dac baza de date este deschis n modul exclusiv, prin selectarea opiunii
DatabasesTools->Encrytp with Password. (Fig.7.51) Dezactivarea parolei se poate realiza prin
selectarea opiunii DatabasesTools->Decrytp Database numai atunci cnd baza de date este
deschis n mod exclusiv.

Fig.7.51
Parola unei baze de date va deveni un atribut al acesteia, aa nct fiierul respectiv nu
va putea fi accesat de utilizatori neautorizai, chiar dac se procedeaz la reinstalarea sistemului
Access.
4. Protecia la nivel de utilizator (user-level security) se realizeaz prin crearea unor
utilizatori cu drepturi (permisiuni) diferite asupra bazelor de date i obiectelor coninute de
acestea. Aceast metod de protecie este folosit n cazul reelelor de calculatoare, caz n care
mai muli utilizatori pot accesa aceeai baz de date, dar cu drepturi diferite asupra acesteia.
Protecia user-level a unei baze de date nu va avea nici un efect ntr-un sistem Access
n care nu este activat acest tip de protecie
Un utilizator este identificat printr-un nume i o parol. Utilizatorii cu aceleai drepturi
sunt separai n grupuri de utilizatori.
Access pune la dispoziie dou grupuri predefinite de utilizatori:

Admins utilizatorii acestui grup sunt numii administratori ai bazei de date i

au drepturi depline de administrare-ntreinere a tuturor bazelor de date.
Programul de instalare Setup creeaz automat un utilizator n cadrul acestui
grup, numit Admin, care va fi i utilizatorul implicit;

Users grupeaz utilizatorii obinuii, care implicit au drepturi depline asupra

252

obiectelor bazelor de date.

Pentru a activa procedura de protecie user-level, este necesar ca utilizatorul Admin s
aib atribuit o parol.
Access permite crearea de noi grupuri i utilizatori prin selectarea opiunii
DatabasesTools-> User And Group Accounts. Crearea grupurilor este permis numai
administratorilor.Caseta Users permite crearea/tergerea unui utilizator, tergerea parolei
utilizatorului sau modificarea grupurilor de care acesta aparine. Tag-ul Groups poate fi utilizat
pentru crearea/tergerea unui grup.
Nu este permis tergerea utilizatorului Admin i nici a grupurilor implicite Admins,
respectiv Users.
Tag-ul Change Logon Password permite modificarea parolei utilizatorului curent (cel
care a deschis sesiunea Access). Pentru a modifica parola unui anumit utilizator, trebuie
redeschis o sesiune Access pentru acel utilizator.
La crearea uni utilizator/grup se va specifica numele i un numr de identificare din
minimum 4 cifre (acest numr nu este asimilat parolei).
Dup ce a fost creat un utilizator, se vor selecta grupurile din care acesta va face parte
i de la care va moteni drepturile .
Un utilizator trebuie s aparin obligatoriu de grupul Users.
Pentru modificarea drepturilor aferente grupurilor sau utilizatorilor se va selecta
opiunea DatabasesTools->User And Group Permissions.
Se pot acorda/revoca drepturi fie asupra unor baze de date, fie asupra obiectelor bazei
de date curente. Tot n aceast fereastr se pot modifica proprietarii obiectelor bazei de date
curente (proprietarul unui obiect fiind utilizatorul care a creat obiectul respectiv).
Utilizatorii i grupurile de utilizatori nu sunt proprii unei baze de date, ci unei sesiuni
Access. Informaiile referitoare la user-i sunt salvate ntr-o baz de date sistem care va fi citit
automat la deschiderea unei sesiuni Access. Aadar, o baz de date asupra creia au fost
definite protecii la nivel de utilizator poate fi utilizat fr nici o restricie ntr-o sesiune Access n
care nu este activat procedura de securitate user-level (utilizatorul implicit este Admin)!
5. Criptarea presupune ascunderea informaiilor din baza de date, astfel nct aceasta
s nu poat fi citit cu ajutorul unui editor de texte sau altor programme utilitare. Criptarea
bazelor de date se recomand n mediile multiuser, cnd se dorete pstrarea confidenialitii
datelor. Bazele de date criptate presupun operaii suplimentare de decriptare automat, ceea ce
ncetinete execuia programului Access.
Pentru a cripta/decripta o baz de date se selecteaz opiunea Tools->Security>Encrypt/Decrypt Database.
253

7.3.5. Accesarea concurent a bazelor de date

n regim multiuser, apare problema tratrii accesului concurent la bazele de date, cnd
doi sau mai muli utilizatori doresc editarea n acelai timp a unei nregistrri. n acest caz,
sistemul nu poate proceda dect la tratarea secvenial a utilizatorilor.
Spre deosebire de alte S.G.B.D.-uri (dBase, FoxPro), sistemul Access rezolv automat
aceast problem, prin dou metode:
1. Blocarea optimist presupune blocarea paginii ce conine nregistrarea curent n
timpul salvrii acesteia de ctre un utilizator. Astfel, nregistrarea respectiv va fi read-only
pentru ceilali utilizatori, atta timp ct operaia de salvare nu este ncheiat.
Aceast variant de blocare a datelor poate fi realizat astfel:

Implicit, prin selectarea opiunii Default Record Locking din meniul Tools>Options->Advanced;

La nivel de formular, prin setarea proprietii Record Locks pe valoarea No

Locks;

Pentru un obiect recordset, prin setarea proprietii LockEdits pe valoarea

False.
2. Blocare pesimist permite blocarea paginii ce conine nregistrarea curent, n
timpul editrii acesteia de ctre un utilizator. nregistrarea curent nu va putea fi editat de un alt
utilizator pn cnd ea nu va fi salvat de utilizatorul curent. Blocarea pesimist se poate
realiza:

Pentru varianta implicit, prin selectarea butonului de opiune Edited Record

pe meniul Tools->Options->Advanced;

La nivelul formularelor, prin setarea proprietii Record Locks pe valoarea

Edited Record;

Pentru un obiect recordset, prin atribuirea valorii True pentru proprietatea Lock
Edits.

7.3.6. Repararea i compactarea bazei de date

Apar situaii n care baza de date poate fi alterat datorit unor evenimente imprevizibile
(Exemplu: oprirea brusc a calculatorului n timpul scrierii n baza de date).
Compactarea este operaia prin care se reduce dimensiunea bazei de date (nu trebuie
fcut confuzie ntre compactare i comprimare, care este o operaie realizabil prin intermediul
unor programe specializate n acest scop). n urma tergerii diferitelor obiecte ale bazei de date
(tabele, formulare, rapoarte, etc.) sau chiar a unor nregistrri, Access nu elimin i spaiul
afectat acestora, astfel c, dup mai multe operaii de acest gen, dimensiunea bazei de date
rmne aceeai. Prin compactare se elimin din baza de date tocmai aceste spaii neutilizate.
254

Pentru repararea i compactarea unei baze de date, se selecteaz opiunea

DatabasesTools->Compact and Repair Database. Utilizatorul va fi anunat printr-un mesaj, dac
operaia de reparare i compactare a fost sau nu ncheiat cu succes.
7.3.7. Optimizarea bazelor de date
n general, o aplicaie proiectat i dezvoltat corect presupune nu numai obinerea
rezultatelor cerute de beneficiar, ci i asigurarea unui timp ct mai redus pentru prelucrarea
datelor i furnizarea rezultatelor finale. Optimizarea bazei de date poate fi realizat automat prin
apelarea i furnizarea programului Analyze Performance, apelabil prin selectarea opiunii
DatabasesTools->Analyze->Analyze Performance din meniul Access. (Fig. 7.52).

Fig. 7.52
Analyze Performance furnizeaz recomandri n vederea optimizrii bazei de date, dar
permite i optimizarea propriu-zis a acesteia.
Este indicat ns ca i programatorul s in cont de urmtoarele recomandri n
vederea optimizrii bazei de date:
1. Optimizarea tabelelor. n general, procesul de nominalizare conduce la obinerea
unor tabele optimizate. Se mai pot avea n vedere i urmtoarele recomandri:

Folosirea unor tipuri de date i dimensiuni ct mai adecvate pentru cmpuri.

De exemplu, pentru cmpul UnitateDeMsur este suficient o dimensiune de
maximum 3 caractere.

Evitarea definirii cheilor primare pe cmpuri de tip Text, Numeric (Single),

Numeric (Double). Cele mai recomandate tipuri pentru astfel de chei sunt cele
de tip AutoNumber, Numeric (Byte, Integer sau LongInteger).

Indexarea cmpurilor care vor fi folosite n ordonri, criterii (filtre) sau n relaii
(dac pentru cmpurile de tip cheie extern, utilizatorul nu creeaz indeci,
acest lucru va fi fcut automat de Access);

Utilizarea moderat a indecilor. Chiar dac acetia permit realizarea unor

operaii ntr-un timp mai scurt, nu se recomand folosirea lor abuziv,
255

deoarece operaiile de actualizare vor fi mai lente.

2. Optimizarea interogrilor. Pentru obiectele de acest tip se au n vedere urmtoarele:

Folosirea n criterii (sau clauza SQL Where ) numai a cmpurilor indexate;

Se va evita folosirea n criterii a cmpurilor din partea n a unei relaii;

Utilizarea n clauza Group By (dac este posibil) a cmpurilor indexate i

totodat a unui numr redus de cmpuri;

Pentru interogrile destinate numai afirii datelor se poate recurge la folosirea

tipului Snapshot;

Salvarea interogrilor n timpul execuiei.

3. Optimizarea formularelor.
n general, formularele sunt mari consumatoare de resurse, aa nct sunt indicate
urmtoarele:

Evitarea suprancrcrii formularelor cu controale;

Renunarea la utilizarea unor imagini grafice n cadrul formularelor;

Evitarea deschiderii mai multor formulare dect sunt necesare;

Setarea proprietii Data Entry pe Yes reduce timpul necesar ncrcrii unui
formular;

Evitarea folosirii unor proceduri complicate pentru evenimentul OnCurrent.

4. Optimizarea rapoartelor.
Pentru rapoarte se recomand:

Renunarea la ataarea controalelor de tip imagine, butoane, casete

combinate, etc., deoarece acestea nu vor avea nici o utilitate ntr-un raport;

Utilizarea unor proceduri ct mai simple pentru evenimentul On Format sau

chiar renunarea, dac este posibil la aceste proceduri;

Sortarea i gruparea datelor se va face, dac este posibil, numai dup cmpuri
indexate.

7.3.8. Analiza i documentarea bazelor de date

Una dintre principalele etape parcurse n realizarea unei aplicaii o constituie i
elaborarea documentaiei care trebuie s cuprind descrierea tuturor obiectelor bazei de date i
care este necesar pentru dezvoltri/modificri ulterioare.
Access pune la dispoziia dezvoltatorilor de aplicaii un utilitar numit Database
Documenter, care elaboreaz automat documentaia fie pentru toate, fie pentru anumite obiecte
bazei de date. Apelarea acestui utilitar se realizeaz prin operaiunea Tools->Analyze>Database Documenter. (Fig. 7.53)
256

Fig. 7.53
Documentaia general de Documenter conine:
1. Pentru baza de date:

Versiunea;

Utilizatorii i grupurile de utilizatori ce pot accesa baza de date etc.

2. Pentru un obiect de tip tabel:

Proprieti (condiii de validare, numrul de nregistrri etc.);

Cmpurile cu proprietile aferente (denumire, tip, lungime, cheie primar etc.);

Indecii (denumire, tip etc.);

Relaiile cu celelalte tabele ale bazei de date;

Utilizatorii/grupurile de utilizatori ce au drepturi asupra tabelei.

3. Pentru obiecte de tip interogare:

Proprieti (tipul de interogare, data crerii etc)

Comand SQL aferent;

Cmpurile coninute de interogare, cu proprietile corespunztoare;

Indecii coninui din interogare;

Drepturile aferente fiecrui utilizator asupra interogrii respective.

4. Pentru obiecte de tip formular:

Proprieti (tipul formularului, sursa de date etc.);

Controale coninute de formular, inclusiv seciunile acestuia, cu proprietile

aferente;

Module incluse n formular;

Utilizatorii, cu permisiunile fiecruia asupra formularului.

5. Pentru rapoarte:

Proprieti (titlul, sursa de date etc.);

257

Obiectele incluse (controale i seciuni), cu proprietile respective;

Utilizatorii ce pot executa sau modifica raportul.

6. Pentru obiectele macro:

Proprieti (data crerii, proprietarul etc.);

Aciunile coninute;

Utilizatorii ce pot executa/modifica macro-ul.

7. Pentru obiecte modul:

Proprieti (data crerii, proprietarul etc.);

Codul inclus (declaraii, funcii i proceduri VBA);

Drepturile utilizatorilor asupra modulului.

8. Pentru relaiile definite ntre tabele:

Tabelele ce formeaz relaiile;

Tipul fiecrei relaii etc.

Teste de evaluare a cunotinelor

ncercuii variantele de rspuns corecte
1. In definirea unei baze de date se folosesc urmatoarele notiuni:
1)

Colectia de date

2)

Limbajul Visual Basic

3)

Descrierea datelor

4)

Relatiile dintre date

5)

Programare

2. n Access, zona de declarare a cmpurilor unei tabele prezint urmtoarele opiuni:

a.

FieldName, DataType, Description;

b.

FieldName, DataName, LookUp;

c.

FieldName, DataType, LookUp.

258

3. Pentru a schimba numele unui camp dintr-un tabel in modul Datasheet View

a.

se selecteaza meniul Format, optiunea Rename Column;

b.

se selecteaza meniul Format, optiunea Hide Columns;

c.

se selecteaza meniul Insert, optiunea Column.

4. Pentru a crea o interogare n modul Design View utilizm fereastra Select Query care este
structurat n:
A. partea superioar, unde sunt afiate structurile tabelelor din baza de date;
B. partea inferioar numit gril de proiectare n care se construiete interogarea din
punct de vedere structural. Aceasta gril de proiectare este cunoscut i sub
denumirea QBE (Query By Exemples);
C. partea superioar numit gril de proiectare
5. In Microsoft Access interogarile se clasifica in:
A. Interogari de selectie;
B. Interogari de tip actiune;
C. Interogari parametrate;
D. Interogari de tip Analiza incrucisata.
6. Zona folosita pentru a afisa titlul unui formular poarta denumirea de:
a. Sectiunea de antet (Form Header);
b. Antetul de pagina (Page Header);
c. Subsol de pagina (Page Footer);
d. Subsolul formularului (Form Footer).

259

7. Crearea unui ansamblu formular - subformular se poate face prin:

A. Crearea separata a celor doua si apoi combinarea;
B. Crearea formularului si subformularului concomitent;
C. Crearea subformularului si adaugarea lui la un formular existent.
8. Cu ajutorul controlului Text Box din cadrul trusei de instrumente Toolbox se insereaza:
a. o caseta de text folosita pentru editarea si afisarea datelor;
b.

o caseta de grup si poate grupa mai multe controale (buton de optiune, butoane validare);

c.

o eticheta.

9. n Access, afiarea proprietilor unui obiect se face:

a.

pe grupe de proprieti, fiecare grup de proprieti aflndu-se pe cte o fi;

b.

pe grupe de activiti, fiecare grup de activiti avnd semnificaia descris printr-un

simbol ;

c.

pe grupe de sarcini, fiecare sarcin avnd precizate numere de ordine ;

d.pe grupe de proprieti, fiecare grup de proprieti indicnd formatul unui obiect ;

d.

pe grupe de proprieti, fiecare grup de proprieti indicnd o list de aciuni la care este
posibil a rspunde obiectul cruia i sunt asociate, ca urmare a apariiei unor evenimente.

10. n Microsoft Access se utilizeaz i criteriul de selecie LIKE care semnific:

a. Apartenena la un interval de valori;
b.

Apartenena la list de valori;

c.

Comparare cu un nume generic;

d.

Operator de negaie.

260

Capitolul 8
Auditul sistemelor informatice
Obiective:
nsuirea conceptelor de audit al sistemelor informatice
Identificarea i evidenierea zonelor de expunere la risc, precum i a eventualelor deficiene n
strategiile actuale de aborsare a riscurilor
Cunoaterea teoriilor i metodelor de baz pentru pregtirea informaiilor necesare ntocmirii
raportului de audit al sistemelor informatice
Cuvinte cheie: planificarea auditului, controalele sistemelor informatice, evaluarea riscurilor,
matrice de control, tehnic de audit asistat de calculator(CAAT), plan de audit.
8.1 Particularitile procesului de audit al sistemului informatic
Auditul informatic reprezint o form esenial prin care se verific dac un sistem informatic i
atinge obiectivul pentru care a fost elaborat. Standardele definesc clar domeniul, activitile,
etapele, coninutul auditrii i formele de finalizare. Respectnd cerinele standardelor, rezultatul
procesului de auditare informatic este eliberat de riscurile contestrii.
Auditul informatic reprezint un domeniu cuprinztor n care sunt incluse toate
activitile de auditare pentru : specificaii, proiecte, software, baze de date, procesele specifice
ciclului de via ale unui program, ale unei aplicaii informatice, ale unui sistem informatic pentru
management i ale unui portal de maxim complexitate, asociat unei organizaii virtual.
8.1.1 Operaii specifice auditrii sistemelor informatice
ntr-un organism economic, funcia de auditor al sistemului informatic trebuie s existe
separat i distinct de funcia de control atribuit personalului autorizat sau grupului de control din
Departamentul de informatic, dac acesta este constituit, deoarece personalul autorizat sau
grupul de control efectueaz controlul zilnic al prelucrrilor i distribuirilor automate de date, n
timp ce auditorii evalueaz eficiena prelucrrilor efectuate asupra datelor i a controalelor
corespunztoare, n ansamblu.
Auditorii sistemelor informatice trebuie s participe la proiectarea acestora pentru a se asigura
c:
261

sistemul creeaz un jurnal corect i complet al prelucrrilor (jurnal de activitate);

se implementeaz controalele necesare pentru asigurarea unui control intern, la nivelul solicitat
de utilizatori.

Auditorii testeaz sistemul informatic, n momentul n care acesta devine operativ:

verific dac au fost implementate toate controalele interne prevzute n proiect;

stabilesc dac toate controalele interne implementate n sistem funcioneaz aa cum a fost
planificat;

iau msurile necesare pentru corecia erorilor de implementare i funcionare a controalelor

interne prevzute n proiect;

identific eventualele schimbri neautorizate efectuate n sistemul informatic i iau msurile

necesare pentru eliminarea sau autorizarea acestor schimbri.

Pentru asigurarea controlului intern, la nivelul solicitat de utilizatori, definit prin proiect, auditorii
ndeplinesc urmtoarele sarcini:

verific separarea, din punct de vedere funcional, a personalului de programare de personalul

de operare i impun msurile organizatorice necesare pentru realizarea acestei separri;

verific documentaia iniial a sistemului informatic i actualizarea acesteia, n cazul n care
sunt autorizate schimbri;

verific ndeplinirea sarcinilor care au fost atribuite personalului autorizat sau grupului
de control al sistemului informatic;
urmresc aplicarea msurilor de siguran a sistemului informatic;
urmresc funcionarea efectiv a controlului, n cadrul organismului economic care
utilizeaz, pentru evidena activitilor sale, un sistem informatic.

Funcia de auditor al sistemului informatic utilizat de un organism economic poate fi

atribuit unui angajat permanent sau unui colaborator extern al acestuia, dup cum sarcinile pe
care trebuie s le ndeplineasc auditorul impun, sau nu impun, prezena permanent a acestuia
la locul de munc. Dac volumul de activitate desfurat sau nivelul de eficien solicitat pentru
controlul intern al sistemului informatic utilizat este ridicat, organismul economic trebuie s
angajeze proprii si auditori. n caz contrar, poate folosi, pentru ndeplinirea sarcinilor de audit,
colaboratori externi specializai, care pot ocupa funcia de auditor la mai multe organisme
economice.
Din acest punct de vedere, auditorii sistemelor informatice pot fi interni sau externi
organismului economic care utilizeaz un sistem informatic. Auditorii externi pot fi auditori
independeni sau angajai ai organismelor financiare sau ageniilor guvernamentale de control.

262

Auditorii pot folosi pentru testarea i monitorizarea controalelor interne implementate ntrun sistem informatic aa-numitul sistem integrat de testare, care const n integrarea unui set de
fiiere de test, programe i date de test n sistemul informatic respectiv. Aceste fiiere de test
permit ca datele de test pe care le conin s fie prelucrate simultan cu datele reale, fr ca
datele reale respective i rezultatul prelucrrii lor s fie afectate. Datele de test, care cuprind
toat gama imaginabil de date posibil a fi introduse n sistemul informatic respectiv, afecteaz
numai fiierele de test i rezultatele prelucrrilor acestora. Sistemul integrat de testare poate fi
implementat n toate tipurile de sisteme informatice, inclusiv n sistemele informatice on-line, n
timp real.
Sistemul integrat de testare poate fi folosit de auditori i pentru monitorizarea prelucrrilor
datelor de test n vederea studierii efectelor produse de prelucrrile efectuate asupra fiierelor
de test, listelor de erori i ieirilor sistemului informatic. Ei comunic concluziile personalului
autorizat sau grupului de control care efectueaz controlul zilnic.
Spre exemplu, un sistem integrat de testare pentru aplicaii de salarizare i eviden
personal poate defini un departament fictiv pentru care nregistreaz angajai fictivi n fiierele
de angajai i salarii. Datele de la departamentul fictiv vor fi introduse n sistem simultan cu
datele de la departamentele reale. Auditorii, externi sau interni, vor monitoriza toate ieirile
aferente departamentului fictiv, inclusiv nregistrrile de salarii, listele de erori i cecurile emise.
n acest caz, e necesar un control strict al ieirilor n vederea prevenirii folosirii neautorizate a
cecurilor fictive.
Folosirea sistemelor integrate de testare prezint riscul de manipulare eronat a datelor
reale, prin transferarea lor n sau din fiierele fictive. Pentru eliminarea acestui dezavantaj,
auditorii trebuie s monitorizeze toate activitile n fiierele fictive utilizate i s impun msuri
riguroase de prevenire a accesului neautorizat la aceste fiiere. De asemenea, proiectarea unui
astfel de sistem trebuie fcut cu atenie, pentru a elimina riscul ca fiierele reale s fie
contaminate ntmpltor cu date din fiierele de test.
Organismele economice, care folosesc sisteme manuale sau mecanice de prelucrare a
datelor, ntocmesc documente de eviden, prezentare i control al activitilor desfurate pe
suport material (hrtie), pe care orice modificare de date (nregistrare, actualizare sau tergere)
las urme, rmne vizibil.
Sistemele informatice, fiind sisteme automate de prelucrare, eviden i stocare a
datelor, permit modificarea datelor introduse (nregistrate) n sistem (pe suport electronic), fr
nici o urm vizibil a schimbrilor fcute. La nceputul dezvoltrii sistemelor informatice, acest
lucru a produs o mare ngrijorare printre economiti (contabili, finaniti, auditori etc.) care
263

considerau c prelucrrile electronice de date vor ascunde, sau chiar vor elimina, nregistrrile
de date necesare n procesul de audit.
Dei, din punct de vedere tehnologic, este posibil proiectarea unui sistem informatic n
care datele produse de activitile efectuate de organismele economice s nu fie nregistrate, n
vederea efecturii unui control, un astfel de sistem nu este nici practic, nici de dorit.
Exist motive reale de integrare a unui sistem de audit, chiar i n cele mai sofisticate
sisteme informatice, determinate, n principal, de: necesitatea de coordonare i controlare a
activitilor desfurate de un organism economic de ctre factorii acestuia de decizie
(managerii si); nevoia de reconstrucie a fiierelor de date i de program, distruse de
eventualele erori de prelucrare sau posibilele defecte tehnice; desfurarea activitii de control
(audit) de ctre auditori independeni sau agenii guvernamentale.
n cazul sistemelor informatice sofisticate, dificultatea unui audit este dat de faptul c
nregistrrile datelor rezultate din activitile organismelor economice, folosite n procesul de
audit, pot exista numai pe suport electronic, ntr-un format cod-main, nu i ntr-o form tiprit.
Uneori, dup ce sunt generate, datele pentru audit sunt transferate pe un mediu de stocare cu
pre redus, cum ar fi microfiele.
Mai mult dect att, anumite organisme economice folosesc aa-numitul Electronic
Data Interchange (EDI), n care organismul economic respectiv, mpreun cu clienii i furnizorii
si folosesc legturi de comunicaii electronice (telecomunicaii, comunicaii radio sau pe fibr
optic etc.) pentru a schimba date pe cale electronic.
n astfel de cazuri, documentele surs tiprite (facturi, ordine de plat, cecuri, avize de
expediie etc.) sunt nlocuite cu documente similare n format electronic. Exemplu: ntr-un sistem
informatic de tip EDI, o tranzacie de cumprare poate fi iniiat automat de ctre calculatorul
firmei care solicit cumprarea prin trimiterea unui mesaj electronic, de tip comand direct, la
calculatorul furnizorului su.
n aceste condiii, auditorii trebuie s utilizeze controale de audit care s integreze
tehnici specifice de retenie a datelor i de prelucrare a lor, n vederea asigurrii unui audit
adecvat.
ntr-un sistem informatic, datele necesare auditului pot fi nregistrate:
pe documente tiprite din calculator;
n format electronic, citibil numai pe calculator.
n sistemele informatice, datele nu se nregistreaz ntr-un format tradiional, pe
documente surs scrise de mn, ci numai n format electronic, care poate fi tiprit, la cerere, pe
suport material de tip hrtie sau poate fi urmrit direct pe ecranul calculatorului.
264

Prin urmare, teama economitilor c utilizarea sistemelor informatice n desfurarea

activitilor economice va elimina datele necesare auditului nu s-a materializat. nc din faza de
proiectare a unui sistem informatic, auditorii interni i, eventual, externi, urmresc integrarea n
sistem a unor tehnici de audit care asigur pstrarea (memorarea) datelor necesare efecturii
unui control intern eficient al sistemului respectiv.
Indiferent de tipul sistemului de eviden (gestiune) a activitilor economice i de
prelucrare a datelor (manual, mecanic sau informatic) folosit de organismele economice,
auditorii trebuie s efectueze un control intern, pentru realizarea cruia este necesar:
s evalueze corect riscul de control (posibilitatea de existen a unor erori care nu pot fi
detectate);
s determine natura activitilor desfurate de organismul economic auditat;
s stabileasc tipul i amploarea activitilor de audit necesare;
s aprecieze timpul necesar pentru completarea auditului.
Pe baza celor stabilite n vederea completrii auditului, auditorii pot face organismului
economic recomandri pentru mbuntirea structurii de control intern. Indiferent de tipul
sistemului de gestiune i prelucrare a datelor folosit de un organism economic, recomandrile
pe care le fac auditorii cu privire la controlul intern se mpart n patru categorii, corespunztoare
urmtoarelor patru tipuri de activiti:
planificarea auditului; pentru aceasta. auditorii trebuie s neleag suficient de bine rolul
controlului intern, modalitile de realizare a acestuia i tehnicile de integrare a controalelor n
sistemul de gestiune i prelucrare a datelor folosit de un organism economic;

evaluarea riscului de control i proiectarea testelor adiionale pentru procedurile de

control ale sistemului informatic;
realizarea testelor adiionale pentru procedurile de control ale sistemului informatic;
reevaluarea riscului de control al sistemului informatic i modificarea corespunztoare a
testelor de evaluare.
Planificarea auditului pentru un organism economic i necesitatea proiectrii de teste de
audit eficiente solicit auditorilor s aib cunotinele de specialitate necesare nelegerii
structurii unui control intern, indiferent de tipul sistemului de gestiune i prelucrare a datelor
utilizat (manual, mecanic sau electronic) i de complexitatea acestuia.
Pentru planificarea auditului i proiectarea de teste de audit eficiente, auditorii trebuie s aib
cunotine despre:

procedurile i tehnicile de audit disponibile;

265

proiectarea i realizarea controalelor interne; trebuie s tie ce se urmrete prin auditul intern i
cum se poate realiza un audit complet;

sistemele de gestiune i prelucrare a datelor utilizate de organismele economice; trebuie s

cunoasc particularitile fiecruia, din punct de vedere al auditului;

tehnicile de integrare a controalelor interne n sistemele de gestiune i prelucrare a datelor

disponibile;
natura activitilor desfurate de organismele economice: caracteristicile i particularitile
acestora, din punctul de vedere al auditului;
legislaia n vigoare.

Evoluia tehnologic a microcalculatoarelor de tip PC, din ce n ce mai performante i mai

ieftine, a condus la apariia i dezvoltarea continu a aplicaiilor software i, implicit, la utilizarea,
pe scar larg, a sistemelor informatice bazate pe mediu PC. Practic, sistemele de gestiune i
prelucrare a datelor clasice (manual sau mecanic) sunt pe cale de dispariie, fiind nlocuite de
sisteme informatice. n aceste condiii, auditorii trebuie s aib cunotine suplimentare de
informatic, minimul necesar care s le permit s i desfoare activitatea de control.
Pentru a stabili natura, durata i amploarea activitilor de audit, auditorul trebuie s aib
suficiente cunotine informatice pentru a face analiza procedurilor de prelucrare utilizate i a
rezultatelor acestora.
Auditarea sistemelor informatice simple, care prelucreaz datele folosind algoritmi de
calcul uor de aplicat, nu impune testarea acestor sisteme folosind proceduri de test
implementate pe calculator; n acest caz, auditorii compar rezultatul prelucrrilor datelor de
test, obinut manual, cu cel obinut folosind sistemul informatic auditat i analizeaz diferenele;
aceast tehnic este denumit auditarea evitnd calculatorul, deoarece auditorii evit
calculatorul n realizarea auditului.
Auditarea sistemelor informatice complexe impune ns folosirea procedurilor de audit
implementate pe calculator i proiectarea unor teste suplimentare pentru controlul acestor
proceduri.
Documentaia ntocmit de auditor, aa-numitul raport de audit, variaz n funcie de
complexitatea sistemului informatic auditat. Pentru un sistem cu structur simpl de control
intern, poate fi suficient o descriere. De regul, ns, raportul de audit trebuie s conin:
a)

Diagramele Sistemului Informatic, care descriu activitile desfurate de sistemul informatic

utilizat de organismul economic auditat i care pot fi:

diagrame de sistem: sunt folosite, n mod curent, n procesul de audit, ca tehnic de

descriere a controlului intern; prezint avantajul c fac parte din documentaia standard
a sistemului informatic, prin urmare nu mai trebuie ntocmite de auditor; exemplu:
diagrama de vnzri, diagrama de credite, diagrame de ncasri etc.;
diagrame de program: prezint, n detaliu, logica unui anumit program folosit de
sistemul informatic; auditorii care pot interpreta diagramele de program pot nelege i
interpreta controalele coninute ntr-o anumit aplicaie software, folosit de Sistemul
Informatic auditat.

b)

Chestionare, special proiectate, pentru a fi folosite n procesul de control al sistemului

informatic; exemplu: chestionare de control al accesului ntr-un sistem informatic.
266

Proiectarea, realizarea i utilizarea tehnicilor de audit asistate de calculator impun auditorilor, pe

lng cunotine temeinice din domeniul economic, cunotine suplimentare din domeniul
informatic i din domeniul de activitate al organismelor economice de auditat.
8.1.2 Etapele auditrii
C auditul sistemelor informaionale i are rdcinile n auditul contabil o dovedete i figura 8.1
(Gallegos et al., 1987), prin care prezentm etapele unei astfel de misiuni.
Planificarea auditului
Definirea structurii
controlului intern

Evaluarea riscurilor
controlului

Dependena de
controale?

Testarea controalelor

Reevaluarea riscurilor

Dependena de
controale?

Teste independente

Elaborarea raportului
de audit

Limitarea testelor
independente

Fig. 8.1 Etapele auditrii

267

n etapa de planificare, auditorul extern trebuie s investigheze situaia clientului su

pentru a decide dac accept sau nu un astfel de angajament. El se va axa n principal pe
dimensiunea erorilor din raportrile financiare, erori ce pot afecta capacitatea de decizie a
utilizatorilor unor astfel de informaii.
Pentru auditorul intern, aceast etap presupune nelegerea obiectivelor misiunii sale i
identificarea preliminar a zonelor cu riscuri poteniale. El va avea n vedere mai ales pierderile
aprute sau care pot s apar ca urmare a utilizrii ineficiente a sistemului.
Tot n aceast etap auditorul trebuie s decid care va fi riscul la care se va supune n
timpul misiunii sale: riscul auditrii. Probabil cea mai dificil sarcin a auditorului o reprezint
evaluarea riscurilor controlului. Standardele AICPA44 iIFAC45 precizeaz c nainte de a
decide ct de riscante snt controalele din cadrul unui sistem, auditorul trebuie s neleag
controalele interne folosite n organizaie.
nelegerea structurii controlului intern de ctre auditor presupune examinarea att a
controalelor generale/manageriale, ct i a controalelor de la nivelul aplicaiilor sistemului
informaional. In acest punct lucrurile nu mai pot fi generalizate, deoarece controalele generale,
de exemplu, difer de la o firm la alta n funcie de dimensiunea i organizarea sistemului
informaional.
O firm poate avea o organizare centralizat a sistemului informaional, ceea ce
nseamn c toate procesrile se realizeaz n cadrul compartimentului de specialitate. In alte
firme se ntlnete o organizare descentralizat, procesarea datelor fiind distribuit n ntreaga
organizaie.
Controalele aplicaiilor pot fi de asemenea diverse, n funcie de complexitatea afacerii:
aplicaiile folosite de o firm ce face comer nu vor avea aceeai complexitate ca una care face
producie, de exemplu.
Dup ce a neles pe deplin controalele interne, auditorul trebuie s determine riscul fiecrui
control n parte :
dac riscul controlului este evaluat la un nivel mai mic dect nivelul maxim, auditorul
trebuie s testeze controalele care opereaz n mod eficient. Se pornete de la ipoteza c,

268

n cazul n care testele indic o funcionare eficient, se va reduce dimensiunea testelor

independente.
dac riscul controlului este evaluat la nivelul maxim, controalele nu vor mai fi testate i,
prin urmare, nu pot fi considerate de ncredere. Auditorul va aborda controalele prin prisma
testelor independente.
Testarea controalelor l ajut deci pe auditor n evaluarea eficienei acestora. Abordarea
difer ns de la o categorie de specialiti la alta. Dac, de exemplu, auditorul intern stabilete
c anumite controale nu snt eficiente, va cuta s neleag ct mai bine natura i implicaiile
punctelor slabe pe care le-a identificat. Obiectivul su va fi s nlture acele puncte slabe.
Auditorul extern tinde s-i reduc ns investigaiile ntr-o astfel de situaie i s-i
asume responsabilitatea testrilor independente, prin prisma riscului ridicat pe care l percepe.
In finalul demersului su, auditorul ajunge n etapa exprimrii unei opinii cu privire la sistemul
auditat.
Profesionitii din domeniul contabilitii nu trebuie s fie mari specialiti n informatic pentru a
putea pune n practic avantajele oferite de tehnologiile informaionale. Pe de alt parte ns,
aceste tehnologii ridic noi probleme crora auditorii trebuie s le gseasc soluii.
Schimbrile care au avut loc n domeniul tehnologiei informaionale au modificat abordarea
conceptual a auditrii. Intr-o prim faz, auditorul ignora n esen calculatorul, tratndu-l ca pe
o cutie neagr", iar auditarea se efectua n jurul acestuia (Weber, 1988).
Dezvoltarea tehnologiilor informaionale i gradul ridicat de specializare a auditorilor au
trasat dou direcii de utilizare a calculatoarelor:
__ca unealt a auditorului, contribuind la realizarea auditrii propriu-zise ;
__ca sarcin a auditrii, acolo unde datele snt supuse procesrii calculatorului i
rezultatele snt analizate cu acuratee i sigur de ctre programele calculatorului.
Prima reacie a auditorilor fa de calculatoare a fost tratarea acestora similar simplelor
sisteme contabile manuale n care nu interesau dect datele de intrare i cele de ieire. n
aceste condiii, auditorii nu au fost preocupai de mecanismele interne prin care se realizau
nregistrrile contabile, deoarece le era de ajuns faptul c aveau acces rapid la documente i
nregistrri (figura 8.2).

269

Fiiere

Procesri cu
ajutorul
calculatorului

Date de ieire
generate de
calculator

Date de
intrare

Compararea
rezultatelor

re

Selectarea
datelor de
intrare

Procesri
manuale

Date de
Ieire

Fig.8.2 Auditarea n jurul cacalculatorului

n plus, traseul auditrii de la documentele surs pn la nregistrrile fcute de main
era uor de urmat. Chiar dac auditorii acceptau intrrile" i producerea ieirilor", calculatorul
era considerat o cutie neagr", auditarea realizndu-se n jurul" su.
Folosirea calculatorului ca instrument al auditorului n ndeplinirea sarcinilor acestuia este
cunoscut n literatura de specialitate ca fiind auditarea cu ajutorul calculatorului". Auditorii
folosesc calculatorul pentru a-i ndeplini sarcinile imediat ce utilizatorii proceseaz automat
datele contabile. Pentru nlesnirea utilizrii calculatorului ca un instrument de auditare, multe
firme au dezvoltat softuri de auditare generalizate. Un astfel de soft ndeplinete sarcini cum ar
fi: compararea coninutului a dou fiiere, examinarea coninutului unui fiier, calcularea unor
deprecieri etc.
Auditarea cu un astfel de soft este mult mai eficient, deoarece nu trebuie scrise
programe separate de auditare pentru fiecare utilizator sau client auditat. Trebuie remarcat
faptul c nici n aceast faz auditorul nu era interesat de mecanismele de funcionare ale
calculatorului i de modul n care se realiza procesarea datelor.
Dezvoltrile tehnologice i implementarea pe scar larg a calculatoarelor n cadrul
organizaiilor au condus la situaia actual:auditorii nu mai pot face abstracie de realitate. Ei au
fost forai s trateze calculatorul ca pe inta auditrii i s auditeze prin" el i implicit sistemul
informaional (figura 8.3).
270

Fiiere

Procesarea
tranzaciilor de test
sub controlul
auditorului

Date de ieire
generate de
sistemul
informaional

Tranzacii de
test

Compararea
rezultatelor

re

Procesarea
tranzaciilor de test
de ctre auditor

Date de
Ieire

Fig.8.3 Auditarea prin calculator

Aceast nou abordare cere auditorului s introduc datele n calculator pentru procesare. El
verific apoi modul n care snt procesate datele de ctre calculator, structura fiierelor, a
bazelor de date. Rezultatele snt, n final, analizate pentru a se constata dac utilizatorii i
conducerea organizaiei se pot baza pe procesarea i acurateea programelor.
Dintre dezvoltrile tehnologice care cer aceast ultim abordare amintim:

introducerea datelor on-line. n unele sisteme, comenzile clienilor sunt primite telefonic i
introduse direct n sistem prin intermediul tastaturii, fr a se mai crea documentele surs.
Auditorul este obligat s intre" n sistem pentru a determina gradul de siguran i acuratee al
procesrii i controlului, deoarece nu mai poate parcurge traseul documente surs-documente
de ieire.

reducerea sau chiar eliminarea ieirilor tiprite. Exist cazuri n care ieirile tiprite nu snt
disponibile pentru iniierea tranzaciilor. Auditorul va fi obligat s intre n sistem pentru a
determina acurateea procesrii i a coninutului fiierelor.

actualizarea fiierelor n timp real. Cu aceast actualizare, tranzaciile apar imediat ce au loc. O
ieire tiprit, prezentnd coninutul unor astfel de fiiere i furnizat auditorului, ar putea s nu
fie corect. Acest lucru se ntmpl deoarece pn cnd imprimanta ajunge la jumtatea listrii
coninutului unui fiier, datele de la nceputul acestuia s-ar putea s fie schimbate. Prin urmare,
auditorul este obligat s intre n sistem pentru a face auditarea.

271

n plus fa de dezvoltrile tehnologice care l-au obligat pe auditor s foloseasc calculatorul n

auditare, unii specialiti s-au decis s auditeze prin sistem din dou motive:

pe de o parte, imposibilitatea de a localiza documentele surs sau ieirile tiprite din cauza
sistemului de fiiere utilizat;

pe de alt parte, ngrijorarea c ceea ce apare pe ieirile tiprite s-ar putea s nu fie n
concordan cu ceea ce conin n realitate fiierele. Tehnologia trebuie s fie controlat de om i
nu viceversa.

8.1.3 Probleme de audit asociate cu utilizarea sistemelor informatice

Societatea actual, o societate informatizat pentru care informaia i tehnologia
informaiei sunt cele mai importante valori, necesit astzi sisteme de comunicaie rapide, sigure
i fiabile care s-i asigure confidenialitatea, integritatea i disponibilitatea resurselor
informaionale.
n etapa de Planificare a auditului, auditorii trebuie s-i formeze o imagine asupra
semnificaiei i complexitii mediului informatic, a accesibilitii datelor n vederea
auditrii. Aceast imagine este definit de caracteristicile:
Structura organizatoric a mediului informatic, ce pune un accent deosebit pe
necesitatea separrii funciilor incompatibile adresate aceleiai persoane.
Complexitatea i importana procesrii automate a fiecrei aplicaii semnificative. O
aplicaie informatic poate fi considerat complex atunci cnd:

volumul tranzaciilor este considerat de utilizatorii aplicaiei ca fiind dificil pentru

identificarea i corectarea erorilor n timpul procesrii;

aplicaia poate genera automat tranzacii semnificative sau poate furniza intrri ctre
alte aplicaii ;

complexitatea calculelor aritmetice;

tranzaciile sunt schimbate electronic cu alte organizaii, ceea ce implic controale

suplimentare asociate cii de comunicaie.

Disponibilitatea datelor. ntr-un mediu informatizat, anumite informaii solicitate de auditor

pot exista doar pentru o scurt perioad i/sau doar ntr-o form electronic; n legatur cu acest
aspect se impune a fi amintit i vulnerabilitatea mediilor de stocare a datelor /informaiilor.
Utilizarea tehnicilor de audit asistate de calculator pentru o cretere a performanei
procedurilor de audit.
Aceast analiz a importanei i complexitii activitilor mediului informatizat are un impact
favorabil n evaluarea riscurilor inerente i de control.

272

ntr-un mediu informatizat, amploarea riscurilor ia o alt dimensiune, natura lor fiind influenat
de:
Densitatea informaiei este mult mai mare dect n sistemele clasice, bazate pe hrtie.
Dischetele, discurile optice i alte suporturi moderne ce sunt utilizate pentru salvarea acestui
volum mare de informaii, nsumnd zeci de mii de pagini de hrtie, pot fi subtilizate mult
mai discret genernd astfel fraude sau cel puin afectnd confidenialitatea acestor informaii.
Transparena documentelor privind desfurarea unor operaiuni.
a) Absena documentelor de intrare datele pot fi introduse n sistem fr a avea la baz
documente justificative este exemplul tranzaciilor din sistemele on-line.
b) Lipsa unor urme vizibile a tranzaciilor Dei n practica prelucrrii manuale, orice
tranzacie poate fi urmrit plecnd de la documentul primar, apoi n registrele contabile, conturi
n prelucrarea automat, traseul unei tranzacii poate exista o perioad limitat , ntr-un format
electronic.
c) Lipsa unor ieiri vizibile anumite tranzacii sau rezultate, n special cnd acestea
reprezint detalii, se pot regsi memorate doar n fiierele aplicaiei (nu i ntr-o form tiprit).
Autorizarea tranzaciilor. ntr-un mediu informatizat se poate include i capacitatea
calculatorului de a iniia i executa automat unele trazacii; altfel spus, este vorba de modul de
proiectare a aplicaiei informatice care poate avea ncorporate anumite autorizri implicite i
funcii de generare automat.
Procesarea uniform a tranzaciilor. O aplicaie informatic proceseaz n mod uniform
tranzacii similare, pe baza acelorai instruciuni program. n felul acesta, erorile de redactare a
documentelor asociate unei procesri manuale sunt n mod virtual eliminate. n schimb, erorile
de programare pot conduce la procesarea incorect a tranzaciilor, astfel nct auditorii i vor
concentra atenia asupra acurateei i consistenei ieirilor.
Accesul neautorizat la date i fiiere se poate efectua cu o mai mare uurin, ceea ce
implic un mare potenial de fraud i eroare.
Remanena suporturilor de memorare a datelor, dup ce au fost terse poate constitui o
cale sigur de a intra n posesia unor informaii de valoare.
Agregarea datelor. Noile sisteme de prelucrare automat a datelor, precum sunt cele de
asistare a deciziei, au condus la valorificarea unor informaii importante ale entitii, genernd
prognoze, strategii i tactici de parcurs ntr-un anumit domeniu. Astfel, informaiile capt
valene suplimentare dect cele avute prin pstrarea lor n mai multe locuri, separate unele de
altele.
Evoluia tehnologiei informaionale a cunoscut n ultimii ani un ritm accelerat, dar nu
acelai lucru se poate spune despre progresele nregistrate n domeniul securitii datelor.

273

Integrarea puternic a sistemelor apare ca o consecin a mbuntirii formelor de

comunicaie i a proliferrii reelelor de calculatoare. Aplicaiile de comer electronic sunt doar un
exemplu n acest sens, dar se poate afirma ca au deschis i mai mult apetitul specialitilor n
ceea ce privete frauda informaional.
Lipsa urmelor eventualelor atacuri criminale constituie un alt element ngrijortor al
noului mediu de lucru ; n aces sens modificarea datelor, adugarea sau chiar tergerea lor au
devenit operaii mult mai uor de realizat, dar n acelai timp, destul de greu de depistat.
8.2 Analiza riscului auditrii sistemelor informatice
n literatura de specialitate exist mai multe definiii ale conceptului de risc, pe care le
prezentm n continuare. Riscul 6este definit ca fiind ameninarea c o aciune sau un eveniment
va afecta n mod nefavorabil abilitatea unei organizaii de a-i atinge obiectivele i de a-i
executa cu succes strategiile. Definiia aceasta evideniaz civa factori eseniali, respectiv
riscul este n mod invariabil o ameninare, adic ceva ce s-ar putea ntmpla, ameninarea se
refer la un eveniment, adic ceva ce trebuie s se petreac pentru ca riscul s se cristalizeze,
iar dac se produce evenimentul, va avea impact asupra ndeplinirii obiectivelor organizaiei.
La aceast definiie observm c riscul produce neaprat impact asupra obiectivelor ntr-un mod
negativ.
Riscul7 este posibilitatea sau ansa ca ceva s se ntmple care va avea efect asupra
obiectivelor firmei. Definiia aceasta, are n plus fa de avantajul de a fi o definiie simpl i uor
de neles, cuvntul posibilitate/ans care este unul foarte bine ales ntruct ansa poate fi
att pozitiv ct i negativ. Din punctul de vedere al unui auditor intern, riscul poate fi
considerat ca fiind pulsul organizaiei. Aceast analogie ne permite s afirmm c auditorii
interni trebuie s se asigure c organizaia adopt problematica riscului i l gestioneaz, mai
degrab dect s tolereze ameninrile i, drept urmare, s piard oportunitile. Considerm
cu trie c managementul riscului poate fi i un proces pozitiv, riscul nu este numai ceea ce
decurge n mod greit, ci activiti despre care trebuie s te asiguri c sunt corecte sau c le-ai
neles corect.
Ce constituie riscuri pentru o firm? Mai n glum, mai n serios, putem spune c o
mulime de lucruri sau evenimente din viaa unei organizaii sunt ncadrate n categoria riscurilor:
costul de nlocuire a echipamentelor, despgubirile acordate, primele de asigurare, diminuarea
produciei, creterea costurilor administrative, pierderea unor oportuniti sau a credibilitii,
reducerea calitii produselor sau serviciilor oferite clienilor etc.
Phil Griffiths Risk-Based auditing, Gower Publishing Limited, England, 1998, definiie dat de
Economist Intelligence Unit, departament al guvernului britanic
7
Idem
6

274

tim c activele unei organizaii pot fi tangibile sau intangibile. S aruncm o privire
asupra sistemului informaional. Echipamentele i aplicaiile care alctuiesc acest sistem
reprezint active tangibile n timp ce datele procesate i informaiile obinute sunt intangibile.
Primul element ce trebuie avut n vedere atunci cnd discutm despre riscuri n sistemele
informaionale l reprezint mediul acestui sistem, mediu care de fapt nu reprezint altceva dect o
inventariere a activelor ce se doresc a fi protejate : infrastructura reelei, sistemul de operare,
aplicaiile, informaiile procesate n sistem, supori de memorare etc.
Urmtorul obiectiv pe care auditorul trebuie s l reprezint identificarea riscurilor asociate
acestor active, aici putnd fi incluse :
__ pierderile financiare;
__ pericole de genul incendiilor, ntreruperilor n alimentarea cu energie electric sau
cataclismelor naturale;
__ frecvena i gravitatea erorilor (umane sau mecanice);
__ furtul sau alterarea aplicaiilor sau a datelor/informaiilor procesate ;
__ probleme cauzate de incompetena managerial.
n acest sens, figura 8.4 pune n coresponden diferite elemente ce necesit a fi luate n calcul
pentru reducerea riscului.

Fig.8.4 Analiza riscului IT8

8

Prelucrare dup INTOSAI IT AUDIT COMMITTEE IT Security, note de curs, www.intosai.com

275

Faptul c se recurge la calculator n conducerea activitii unei ntreprinderi constituie un

risc n sine. Acest risc este independent de riscul fizic sau logic.
Riscul fizic cuprinde defectarea calculatoarelor i a unitilor periferice, precum i condiiile
nesatisfctoare ale mediului n care funcioneaz. nc de la nceputul dezvoltrii informaticii,
progresele cele mai importante au fost obinute n materie de protecie contra riscului fizic.
Riscul logic provine din aplicarea greit a anumitor proceduri, a unor instruciuni greite sau
erori umane mai mult sau mai puin intenionate.
Riscul economic este cel legat de utilizarea echipamentelor informatice n viaa ntreprinderii.
Pentru multe ntreprinderi, calculatorul are un rol esenial, i orice anomalie n funcionarea sa
poate s aib consecine grave, ducnd pn la ntreruperea parial sau total a exploatrii
(bncile, companiile de asigurri, societile de vnzri prin coresponden sunt vulnerabile n
faa defectrii sau funcionrii neadecvate a echipamentelor).
Managementul, prin activitile de control prestabilite, identific riscurile i prin soluii
adecvate, n funcie de gama de riscuri, caut s le elimine sau s le reduc impactul negativ.
Departamentul de audit intern, fiind o structur independent, reia analiza riscurilor stabilite de
manageri i caut s identifice care sunt pierderile materiale sau erorile din cadrul raportrilor
financiare, ca urmare a neregulilor descoperite pe parcursul desfurrii auditului.
8.2.1 Riscurile asociate sistemelor informaionale
n general, riscurile asociate unui sistem informaional, pe care orice auditor trebuie s le
analizeze i evalueze (tehnica frecvent utilizat n acest caz este chestionarul), n vederea
aprecierii sistemului n sine, vizeaz: riscul controlului i al detectrii.
Orice afirmaie fcut de auditor trebuie susinut de probe. Nu ntotdeauna ns, testele
utilizate conduc la depistarea erorilor reale sau poteniale din cadrul sistemului. Astfel, auditorii
se confrunt cu propriul risc: riscul auditrii.
AICPA, organizaie ce grupeaz auditorii externi de pe noul continent, a elaborat n
1988 un model de calcul al riscului auditrii:
RA= RI * RC * RD

,unde:

RI riscul inerent, RC riscul controlului, RD riscul detectrii.

Acest model rmne valabil i n cazul auditrii sistemelor informatice.
Riscurile inerente sunt reprezentate de totalitatea riscurilor care planeaz asupra organizaiei
i pot fi interne sau externe, msurabile sau nemsurabile.
De exemplu, RI asociat siguranei accesului la reea i a comunicrii datelor n reea,
poate fi considerat un risc de gravitate mare, atta timp ct nu exist un responsabil desemnat
276

cu monitorizarea implementrii procedurilor privind sigurana accesului utilizatorilor n reea.

Consecinele acestei erori se poate propaga n ntreaga organizaie, prin modificarea i
divulgarea datelor, situaiilor, se poate schimba poziia strategic a organizaiei pe piaa
tranzaciilor.
n analiza riscurilor inerente, auditorul trebuie s aib n vedere urmtoarele obiective:
Organizarea i funcionarea departamentului IT
Pentru ndeplinirea acestui obiectiv sunt desfurate activitile:
- analizarea organigramei departamentului IT;
analizarea managementului resurselor umane la nivelul departamentului IT;
- analizarea planurilor de pregtire profesional continu;
- verificarea existenei unui sistem de evaluare a cunotinelor dobndite dup
efectuarea cursurilor;
- analizarea realizrii pregtirii profesionale a salariailor conform atribuiilor i
responsabilitilor stabilite prin fia postului;
- analizarea sistemului de evaluare a riscului;
- verificarea existenei i actualizrii Registrului riscurilor.
Implementarea sistemelor informatice
Activitile sunt:
verificarea realizrii la termenele stabilite a subsistemelor informatice;
analizarea activitii de monitorizare a implementrii subsistemelor informatice;
evaluarea controlului datelor introduse n aplicaie;
evaluarea controlului pe parcursul procesrii datelor;
evaluarea controlului datelor rezultate n urma procesrii;
analizarea validitii datelor transferate din alte aplicaii;
evaluarea controalelor care verific nregistrrile duble;
verificarea autorizrii electronice i/sau manuale a tranzaciilor;
analizarea efecturii tranzaciilor numai de la PC-uri definite n prealabil;
verificarea situaiei licenelor pentru programele de calculator;
asigurarea integrrii subsistemelor componente;
verificarea elaborrii manualelor de utilizare i a manualelor de operare;
verificarea existenei i respectrii programului de instruire a utilizatorilor
sistemelor informatice.
Securitatea sistemelor informatice
-

Activiti:

277

verificarea existenei unei politici de securitate a sistemelor informatice;

verificarea actualizrii politicii de securitate a sistemelor informatice;
analizarea modului de ntocmire i transmitere sistematic a rapoartelor de
monitorizare;
- evaluarea controalelor fizice n domeniul sistemelor informatice(verificarea dotrii
camerelor n care se afl servere-le cu echipamente adecvate);
- verificarea siguranei accesului la reea i a comunicrii datelor n reea;
- verificarea implementrii programelor anti-virus conform procedurilor;
- monitorizarea sistematic a funcionalitii programelor anti-virus;
- verificarea sistemului de actualizare a programelor anti-virus;
- verificarea elaborrii planului de recuperare a datelor n caz de dezastru;
- verificarea desemnrii responsabililor cu monitorizarea implementrii procedurilor
privind recuperarea datelor n caz de dezastru;
- verificarea efecturii monitorizrii sistematice.
Riscul controlului este strns legat de mediul de control i de activitile de control
implementate i reprezint riscul ca o eroare ce nu poate fi prevenit sau corectat de ctre
sistemul de control intern ntr-o perioad scurt de timp.
-

De exemplu, riscul pe care-l implic verificarea manual a tabelelor de audit realizate de un

server Oracle va fi considerat mare, din cauza volumului mare de informaii nmagazinate.
Riscul deteciei reprezint riscul ca un test independent efectuat de auditor s nu detecteze o
eroare care exist n zona supus auditrii.
De exemplu, riscul deteciei asociat identificrii funcionalitii programelor anti-virus, va fi
mare n cazul reelelor mari de calculatoare, deoarece testarea se realizeaz pe un eantion
care reprezint un anumit procent din totalul de calculatoare.

278

8.2.2 Etape n analiza riscurilor

n orice misiune de audit, analiza riscurilor reprezint unul dintre principalele obiective ale
auditorului. Dar, nainte de a porni orice discuie legat de riscuri, trebuie s facem o meniune:
din punct de vedere practic este imposibil s cuantificm corect pierderile cauzate de un anume
eec. Putem face o estimare pe baza pierderilor din trecut i a experienei (proprii sau a altora),
dar nu putem face predicii cu caracter absolut..
Putem prezice posibilitatea de apariie a unui efect negativ sau probabilitatea sa de
apariie, dar nu putem afirma cu certitudine c acest lucru se va i ntmpla.
n calitate de auditori de sisteme informaionale, examinm controalele existente n
cadrul unei organizaii i, chiar dac ne consultm cu ali specialiti sau ne exprimm propriile
opinii, cutm s perfecionm controalele analizate. Aceste consultri sau sugestii pe care le
facem trebuie s permit organizaiei s controleze mult mai eficient pierderile poteniale i s-i
poat conserva resursele de care dispune.
Activitatea de analiz a riscurilor se desfoar n urmtoarele etape:
a) Identificarea elementelor/obiectelor auditabile. n cazul sistemelor informatice se face o
inventariere a activitilor ce se doresc a fi protejate: infrastructura reelei, sistemul de
operare, aplicaiile, informaiile procesate n sistem, suporii de memorare.
b) Stabilirea riscurilor pentru fiecare obiect auditabil pe baza analizei operaiilor n funcie
de anumite criterii concepute anticipat. Aici pot fi incluse: frecvena i gravitatea
erorilor(fizice sau logice), pierderile financiare, pericole de genul incendiilor, ntreruperi
n alimentarea cu energie electric, cataclisme naturale, furtul sau alterarea aplicailor
sau a datelor/informailor procesate, probleme cauzate de incompeten profesional
sau managerial.
c) Msurarea riscurilor care se face n funcie de probabilitatea de apariiei riscurilor i de
gravitatea efectelor pe care le produc. n timp s-au dezvoltat mai multe modele de
cuantificare(calitative sau cantitative) a diferitelor tipuri de riscuri crora trebuie s le
fac fa o ntreprindere, de la simple la complexe. n timp ce modelele cantitative sunt
cunoscute n literatura de specialitate ca fiind cele care se bazeaz pe experiena
auditorului, modelele cantitative fac apel la formule matematice, ncercnd s introduc
mai mult rigoare n acest domeniu.
Cel mai utilizat model pentru msurarea riscurilor este modelul factorilor de risc, care stabilete,
n funcie de importana i greutatea factorilor de risc, ponderile i nivelurile de apreciere ale
riscurilor.

279

Ponderea
Factorilor de
risc
(Pi)

Factori de risc
(Fi)
Aprecierea
Controlului
Intern
F1

P1 50%

Aprecierea
cantitativ
F2
Aprecierea
calitativ
F3

Nivelul de apreciere al riscului(Ni)

N1

N2

N3

Exist proceduri Exist proceduri, Nu

exist
i se aplic
sun cunoscute, proceduri
dar nu se aplic

P2 30%

Impact financiar
sczut

Impact financiar
mediu

Impact financiar
ridicat

P3 20%

Vulnerabilitate
mic

Vulnerabilitate
medie

Vulnerabilitate
mare

Tabel 8.1
Cei trei factori de risc sunt stabilii prin normele generale i sunt acoperitori pentru domeniul
studiat, ns pot fi luai n calcul i ali factori de risc, cu nivel de apreciere corespunztor, dar
trebuie s se aib n vedere c suma ponderilor factorilor de risc trebuie s fie 100.
d) Clasificarea riscurilor se realizeaz n practic prin 3 metode, i anume:
- metode de clasificare absolut riscurile sunt clasificate n ordinea scorului total,
valorile riscului fiind exprimate n procente sau printr-o medie, conform tabelului
de mai jos:
Obiecte auditabile

Scor

Risc

Existena controalelor generale la

subsistemele informatice

Mediu

Funcionalitatea subsistemelor n reea

1,5

Mic

Situaia licenelor pentru programele

de calculator

2,3

Mare

Instruirea utilizatorilor

2,5

Mare

Tabel 8.2
De regul, riscurile mici vor fi ignorate temporar, iar riscurile semnificative(mari i medii) vor intra
n faza de ierarhizare.

280

metode de clasificare relative - riscurile sunt clasificate utiliznd o scar de valori

determinat n prealabil, spre exemplu: sczut, mediu, ridicat.
- metode de clasificare matriceale - riscurile sunt clasificate n funcie de diverse
combinaii posibile. n acest sens, se aleg criterii diverse aplicabile domeniilor care
vor fi evaluate, tot pe o scal cu 3 nivele: slab, mediu i mare.
e) stabilirea controlului intern se realizeaz prin completarea tabelului realizat n exemplul
de mai sus cu activitile de control i constatrile dac acestea sunt sau nu
implementate n practic, conform modelului de mai jos.
-

Obiecte auditabile

Riscuri

Grad de
ncredere al
auditorului n
controlul intern

Obs.

Existena
controalelor Implicaiile
evoluiilor Sczut
generale la
tehnologice n domeniul IT
subsistemele informatice
Funcionalitatea
subsistemelor n reea

Modificarea cadrului legal i Sczut

procedural ce reglementeaz
activitile pentru care se
realizeaz
subsistemele
informatice

Situaia licenelor pentru Limitri bugetare pt. achiziii Sczut

programele
licene
de calculator
Disfuncionaliti n procesul de Mediu
achiziii
Instruirea utilizatorilor

Inexistena unui program de Ridicat

instruire al utilizatorilor

Nu

Neefectuarea
instruirii Mediu
sistematice a utilizatorilor
sistemelor informatice
Tabel 8.3
f)

ierarhizarea riscurilor const n evaluarea funcionalitii sistemelor de control intern, care

limiteaz efectele riscurilor i care dau posibilitatea auditorilor interni s aprecieze acele obiecte
auditabile ca fiind puncte tari, celelalte riscuri pentru care nu exist activitate de control sau
acestea sunt nefuncionale vor fi considerate puncte slabe. Pe baza acestora, se va ntocmi

281

documentul: Tematica n detaliu a misiunii de audit n care vor fi preluate numai operaiile
considerate a fi puncte slabe.

Odat identificate, riscurile trebuie evaluate att din punct de vedere al probabilitii de
apariie ct i al gravitii efectelor pe care le produc. Pentru aceasta este nevoie de o estimare
financiar a impactului pe care fiecare risc n parte l are, precum i de o determinare a
costurilor implicate i a probabilitii de apariie a riscurilor.
Problema aceasta are o mulime de soluii. Una dintre acestea este matricea riscurilor (fig. 8.5)
Pentru construirea matricei se consider o probabilitatea apariiei cu dou variabile:
Frecvena/probabilitatea - stabilete ntr-un interval de timp stabilit;
Impactul/gravitatea efectelor msoar impactul financiar al riscului.

Probabilitate

mare

medie

mic
Impact
0

sczut

moderat

ridicattt

Fig. 8.5 Matricea riscurilor

Dac un anumit eveniment sau o anumit activitate din viaa unei organizaii pare a avea
un efect pozitiv asupra acesteia, mai mult ca sigur exist i un efect negativ. Nu exist
evenimente care s aib numai efecte pozitive. Exist, n schimb, evenimente care pot s aib
doar efecte negative. Aceste evenimente sunt referite ca riscuri. Celor pozitive li se spune ans
sau, n termeni mai diplomatici, oportunitate. n general, cu ct oportunitatea este mai mare, cu
282

att este mai mare i riscul, iar probabilitatea de apariie este destul de redus. De aici se poate
trage concluzia c i reciproca acestei afirmaii este valabil.
Ct de mare poate fi efectul negativ pe care o organizaie i poate suporta? Acest lucru depinde
de puterea financiar a firmei. Dac efectele exprimate monetar snt mai mari dect puterea
financiar a firmei, atunci probabilitatea de sucombare a acesteia este destul de mare.
8.2.3 Evaluarea calitativ i cantitativ a riscurilor
Literatura de specialitate abordeaz dou modele de analiz a valorii riscului: modelul
cantitativ i modelul calitativ ; acestea pornesc de la premisa c orice organizaie se poate
atepta la apariia unor pierderi cauzate de ineficiena unui sistem informatic, iar acest risc al
pierderilor, rezult din impactul pe care l au ameninrile asupra resurselor organizaiei.
Modelele calitative sunt cunoscute n literatura de specialitate ca fiind cele ce se bazeaz
ndeosebi pe agilitatea auditorului, modelele cantitative fac apel la formule matematice,
ncercnd s introduc mai mult rigoare n acest domeniu.
Modelele de risc, fie ele cantitative sau calitative, reprezint instrumente deosebit de utile
auditorilor IT pentru identificarea diferitelor tipuri de risc, oferind n acelai timp informaii pentru
a le determina i controla.
Specialistul Alan Oliphant propune un model calitativ de determinare a nivelului de risc,
conform cruia sunt luai n calcul 4 factori de baz n aprecierea valorii riscului: impactul
financiar, vulnerabilitatea, complexitatea i ncrederea (model reprezentat n figura 8.6).
Impact financiar

Vulnerabilitate

Accesibilitate

Numr
utilizatori

Complexita
te

Risc

Nivel de
ncredere

Complexitate Complexitatea
Riscul
a sistemului
organizaiei tehnologiei

Fig. 8.6 Factorii pentru aprecierea riscului9

Modelul prezentat este descris in articolul Modeling information risk elements (www.theiia.org/itaudit)
283

n acest caz, valoarea riscului va fi exprimat prin valorile Foarte Sczut, Sczut, Mediu, nalt,
Foarte nalt i nu n valori absolute ; formula de determinare a valorii riscului este urmtoarea :
VR= VF * [( Cv*Wv )+( Cc*Wc )+( Ct*Wt )
unde:
VR - valoarea de risc
VF - impactul financiar asupra organizaiei; acesta reprezint un cost potenial al
organizaiei n eventualitatea apariiei unei erori, cderi de sistem, fraude sau alte evenimente
negative. Valoarea material va fi dat de valoarea financiar sau valoarea activelor. Impactul
asupra organizaiei poate fi sporit prin intermediul unui multiplicator non financiar:
[(Cv*Wv)+(Cc*Wc)+(Ci*Wi)
Acest model de calcul poate fi privit ca un punct culminant al analizei factorilor de risc:
vulnerabilitate, complexitate i incredere.
Cv - vulnerabilitatea, se refer pe de o parte la modul n care utilizatorii autorizai au acces
n sistem i pe de alt parte la accesibilitatea sistemului i a activelor organizaiei de ctre
utilizatori neautorizai. Accesibilitatea unui sistem informaional se poate evalua n funcie de
restriciile fizice implementate n cadrul organizaiei i de modalitile de acces prin intermediul
reelei de comunicatie.
Cc - complexitatea - are n vedere riscul asociat tehnologiei informaionale n sine, numrul
utilizatorilor din cadrul compartimentelor sau n termeni mai generici complexitatea
organizaional.
Ci - ncrederea, reflect comportamentul uman din organizaie i vizeaz dou aspecte:
integritatea personalului i gradul de implicare al managerilor.
Wv, Wc, Wi - reprezint factori de greutate (importana) care pot fi aplicai la discreia
auditorului, n funcie de condiiile specifice. Iniial, aceti factori pot fi stabilii la o valoare de
0.33 n vederea determinrii unui multiplicator mediu general al riscului ; aceast valoare nu
este fix i atunci cnd se consider ca unul dintre elemente are un impact mai mare dect
celelalte, se pot folosi valori diferite.
Valoarea de risc calculat va fi transpus ntr-un tabel de traducere, indicndu-se nivelul de
risc; n proiectarea acestui tabel, auditorii au n vedere urmtoarele reguli: valoarea cea mai
sczut de risc = 0 i valoarea cea mai ridicat se apreciaz ca fiind valoarea total (financiar)
a organizaiei multiplicat cu 3.
Impactul financiar reprezint o estimare a valorii monetare pe care organizaia o poate pierde
n eventualitatea apariiei unui eveniment negativ. n cazul nostru, aceast valoare se refer la
284

activele

tangibile

intangibile

din

cadrul

sistemului

informaional:

echipamente,

procesri,aplicaii, date.
Vulnerabilitatea se refer, pe de o parte, la modul n care utilizatorii autorizai au acces n
sistem i, pe de alt parte, la accesibilitatea sistemului i a activelor informaionale de ctre
utilizatorii ne autorizai.
Accesibilitatea unui sistem informaional se va evalua n funcie de Restriciile fizice
implementate n interiorul organizaiei i de modalitile de acces prin intermediul reelei de
comunicaie.
Din punctul de vedere al accesului fizic, riscurile pot fi prezentate ca n tabelul de mai jos:
Riscurile asociate accesului fizic
Nivelul
riscului

Descriere

Mare

Staiile de lucru i celelalte resurse informaionale sunt

accesibile
tuturor persoanelor care au acces n sediul organizaiei.

Mediu

Resursele informaionale sunt localizate n birouri n care, n

mod
normal, persoanele din afara organizaiei nu au acces

Sczut

Resursele informaionale sunt localizate n zone n care nici o

persoan autorizat nu are acces

Tabel 8.4
Din punctul de vedere al accesului la reeaua de comunicaii, riscurile pot fi prezentate ca n
tabelul urmtor:

285

Riscurile asociate reelei

Nivelul
riscului

Descriere

Mare

Conexiuni la reeaua public : orice tip de reea public de

comunicaii la care sistemul organizaiei este conectat. Se
includ : reeaua telefonic, conexiunile internet

Mediu

Conexiuni private : orice conexiuni la o alt reea n afar de cea

gestionat de ctre organizaie, cu acces restricionat sau prin
folosirea unor linii dedicate/nchiriate.

Sczut

Nici o conexiune, nici mcar linie telefonic.

Tabel 8.5

Riscul asociat accesibilitii generale a sistemului este dat de combinarea celor dou tipuri de
acces sub forma unei matrice de control ca n tabelul Urmtor:
Matrice de control
Acces reea

Acces fizic

Mare

Mediu

Sczut

Mare

Mare

Mare

Mediu

Mediu

Mare

Mediu

Sczut

Sczut

Mediu

Sczut

Sczut

Tabel 8.6
Numrul utilizatorilor autorizai mpreun cu riscul asociat accesibilitii sistemului contribuie la
identificarea nivelului de vulnerabilitate a acestuia :
Nivelul de vulnerabilitate
Riscul accesibilitii

Numr utilizatori autorizai

Mare

Mediu

Sczut

Mare
(majoritatea Mare
utilizatorilor sunt autorizai)

Mare

Mediu

Mediu (50%)

Mare

Mediu

Sczut

Sczut(numr limitat)

Mediu

Sczut

Sczut

Tabel 8.7

286

Complexitatea sistemului are n vedere riscul asociat tehnologiei informaionale n sine,

numrul utilizatorilor din cadrul compartimentelor,departamentelor, precum i modulele prin
intermediul crora se realizeaz procesarea datelor. Riscul asociat tehnologiei informaionale
implic, n principal, dependena crescut de profesionitii domeniului i tehnologia n sine.
Dependena de specialiti se poate evalua n funcie de Angajai din
compartimentul/departamentul de specialitate i de riscul asociat documentaiei sistemului.
Auditorul trebuie s aib n vedere i msura n care organizaia apeleaz la specialiti/firme din
afara acesteia.
Riscul asociat angajailor din compartimentul de specialitate
Nivelul
riscului

Descriere

Mare

Exist o singur persoan (angajat sau

independent)
ce se ocup de funcionarea ntregului sistem.

consultant

Mediu

Exist 2-3 persoane care asigur funcionarea i ntreinerea

sistemului.

Sczut

Exist mai mult de 3 persoane implicate n funcionarea

sistemului.
Tabel 8.8

Riscul documentaiei
Nivelul
riscului

Descriere

Mare

Nu exist nici un fel de documentaie

Mediu

Documentaia exist, dar nu reflect n totalitate

Realitile din sistem

Sczut

Exist documentaie actualizat i disponibil n orice

moment.

Tabel 8.9
Combinnd cele dou tipuri de riscuri vom obine o matrice a riscului asociat dependenei de
specialiti :

287

Matrice de control
Nivelul documentaiei

Dependena de
specialiti

Mare

Mediu

Sczut

Mare

Mare

Mare

Mediu

Mediu

Mare

Mediu

Sczut

Sczut

Mediu

Sczut

Sczut

Tabel 8.10
Pentru a putea evalua riscul asociat tehnologiei, acesta trebuie cumulat cu dependena de
specialiti, deoarece cnd vorbim despre tehnologie avem de fapt n vedere timpul necesar
punerii n funciune a sistemului i ciclului de via:
Riscul asociat ciclului de via
Nivelul
riscului

Descriere

Mare

Sistemul a fost implementat cu cel mult un an n urm

i are o durat de via de cel puin 20 de ani.

Mediu

Sistemul are o durat de via mai mare de 4 ani

Sczut

Ciclul de via al sistemului este ntre 1 i 4 ani.

Tabel 8.11
Riscul tehnologic va putea fi identificat cu ajutorul unei matrice de control ce combin
dependena de specialiti i tehnologia n sine :
Riscul tehnologic
Dependena de specialiti

Riscul asociat
tehnologiei

Mare

Mediu

Sczut

Mare

Mare

Mare

Mediu

Mediu

Mare

Mediu

Sczut

Sczut

Mediu

Sczut

Sczut

Tabel 8.12

288

La rndul su, complexitatea organizaional se refer la numrul de utilizatori ai componentelor

sistemului informaional :
Riscul complexitii organizaionale
Nivelul
riscului

Descriere

Mare

Erorile din sistem afecteaz ntreaga organizaie.

Mediu

Erorile din sistem afecteaz activitatea din anumite

compartimente/departamente

Sczut

Erorile din sistem afecteaz un singur

utilizator/compartiment.

Tabel 8.13
Un alt aspect ce trebuie avut n vedere se refer la complexitatea sistemului proiectat: numrul
funciilor pe care acesta le realizeaz :
Riscul asociat funciilor
Nivelul
riscului

Descriere

Mare

Funcii multiple i care interacioneaz unele cu altele.

Mediu

Funcii multiple care acioneaz independent.

Sczut

Sistemul realizeaz o singur funcie.

Tabel 8.14
Combinnd complexitatea organizaional i cea privind sistemul proiectat, se va obine o nou
matrice de control, Dup cum urmeaz :
Matrice de control
Complexitatea sistemului

Complexitatea
organizaional

Mare

Mediu

Sczut

Mare

Mare

Mare

Mediu

Mediu

Mare

Mediu

Sczut

Sczut

Mediu

Sczut

Sczut

Tabel 8.15

289

n ceea ce privete complexitatea sistemului, aceasta va fi evaluat n funcie de riscul asociat

tehnologiei informaionale i de complexitatea organizaional i a proiectului:
Complexitatea organizaional
Complexitatea
organizaional i a
proiectului

Riscul asociat tehnologiei informaionale

Mare

Mediu

Sczut

Mare

Mare

Mare

Mediu

Mediu

Mare

Mediu

Sczut

Sczut

Mediu

Sczut

Sczut

Tabel 8.16
Factorul ncredere a fost introdus n acest model calitativ pentru a reflecta comportamentul
uman din organizaia studiat. Scopul su este de a cuantifica riscul atribuit, pe de o parte,
nivelului de ncredere ce poate fi asociat angajailor din compartimentul de specialitate i, pe de
alt parte, nivelului de ncredere al managerilor n sistemul supus verificrii.
ncrederea vizeaz dou aspecte : controlul angajailor i gradul de implicare al managerilor.
Controlarea angajailor are n vedere asigurarea unui anumit nivel de ncredere n activitatea
acestora:
Riscul asociat personalului
Nivelul
riscului

Descriere

Mare

Personalul nu a fost verificat nainte de angajare

Mediu

Personalul este verificat imediat Dup angajare

Sczut

nainte de a fi angajat, orice persoan este temeinic

verificat.

Tabel 8.17
efii de compartimente/departamente snt cei mai n msur s evalueze riscul activelor
informaionale pe care le au sub control:
Riscul asociat managerilor
Nivelul
riscului

Descriere

Mare

Nu exist nici un fel de preocupare din partea managerilor

Mediu

Managerii sunt preocupai s asigure securitatea

sistemului, dar nu exist nici un fel de analize.

Sczut

Managerii sunt implicai n mod activ i constant n asigurarea

securitii activelor ca urmare a evenimentelor din trecut.
Tabel 8.18
290

Aceti doi factori pot fi la rndul lor combinai:

Matrice de control
Implicarea managerilor

Controlul
angajailor

Mare

Mediu

Sczut

Mare

Mare

Mare

Mediu

Mediu

Mare

Mediu

Sczut

Sczut

Mediu

Sczut

Sczut

Tabel 8.19
Auditorul i va putea forma o opinie cu privire la riscul sistemului informaional combinnd toate
aspectele prezentate pn n acest moment.
Cum acest model nu introduce nici o valoare financiar asociat riscului,evalurile fcute nu au
valoare absolut. Dincolo de faptul c este relativ greu de utilizat, un alt dezavantaj al unui astfel
de model l reprezint faptul c, n lipsa unor rezultate cantitative, nu exist o baz pentru
analize cost/beneficiu.
Un astfel de model este folosit mai mult n fundamentarea recomandrilor auditorului n ceea ce
privete securitatea sistemului verificat. i, n lipsa unei aplicaii care s conin aceste
specificaii, este dificil de utilizat.
Modelul cantitativ se bazeaza pe urmatoarele elementele:

valoarea monetar credibil a activelor;

impactul ca procent din valoarea activelor;

probabilitatea pierderilor anuale;

pierderea anual ateptat;
costul controlului i msurilor de precauie

incertitudinea.

Impactul generat de o singur ameninare sau pierderea potenial asociat unei singure apariii
se calculeaz astfel:
Impact=FV * VA
Sau
PPA = FV * VA
Pierderea anual anticipat este influenat de rata anual a apariiei riscului i poate fi
determinat astfel:

291

PAA = PPA * RAA

unde:

FV factor de vulnerabilitate
VA valoarea activului
PPA pierderea potenial asociat unei apariii
PAA pierdearea anual anticipat
RAA - rata anual a apariiei

O astfel de analiz include de asemenea o evaluare a raportului cost/beneficii ce va facilita

proiectarea ratei de recuperare a investiiilor (ROI) pentru un anumit set de controale.
ROI=Benefiii nete/Cost
Aceste modele matematice furnizeaz un rezultat concret, dar care trebuie inclus n mediul
economic i observat dac el reprezint realitatea.
8.3 Realizarea auditului sistemelor informatice
Auditarea (auditul) unui sistem informatic const, n principal, n efectuarea controlului intern
n sistemul informatic respectiv pentru verificarea corectitudinii rezultatelor prelucrrilor realizate n
interiorul su i a distribuirii acestora numai ctre utilizatorii autorizai, n cazul n care distribuirea se
face automat folosind sisteme de calcul.
Pentru efectuarea controlului intern ntr-un sistem informatic se folosesc msuri, metode i
tehnici de verificare a corectitudinii rezultatelor prelucrrilor realizate n interiorul su, cunoscute, n
literatura de specialitate, sub denumirea de controale. Altfel spus, controlul intern ntr-un sistem
informatic se realizeaz cu ajutorul controalelor.
Utilizarea unui sistem automat de prelucrare a datelor nu diminueaz importana controlului
intern realizat n vederea asigurrii corectitudinii rezultatelor prelucrrilor efectuate n interiorul
acestuia. Apariia i utilizarea sistemelor informatice determin ns folosirea unor msuri i metode
de control specifice, care se adaug metodelor tradiionale de auditare a sistemelor manuale i/sau
mecanice de prelucrare a datelor, deoarece posibilitatea de folosire a unui singur calculator pentru
efectuarea tuturor operaiunilor corelate din cadrul unui organism economic impune utilizarea unor
controale specifice pentru asigurarea proteciei datelor la pierderi sau alterri i pentru depistarea
prelucrrilor eronate, efectuate n interiorul calculatorului.
Exemplu: realizarea tatului de salarii folosind calculatorul face posibil rezolvarea tuturor
problemelor legate de evidena personalului prin adugarea datelor de eviden respective la
292

nregistrarea aferent fiecrui angajat; n acest caz, fiierul de personal cuprinde nu numai datele
necesare realizrii tatului de salarii (salariul de ncadrare, vechimea n munc, sporuri, obligaii ctre
bugetul asigurrilor sociale de stat - CAS, omaj, sntate, impozit etc.), ci i date legate de pontaj
(prezen, concedii de odihn, concedii medicale), de distribuia costurilor salariale pe
compartimente, de studii, de locul de munc i funcia ocupat etc.; pentru protecia datelor de
salarizare i eviden personal mpotriva pierderilor voite sau accidentale i/sau modificrilor
neautorizate, accesul n sistemul automat de eviden i prelucrare a acestor date este controlat, prin
parol i nivel de acces, form de control specific sistemelor automate de prelucrare a datelor.
n literatura de specialitate, controalele sistemelor informatice sunt clasificate n controale
generale i controale de aplicaie.
8.3.1 Controale generale
Controalele generale sunt msuri de protecie a echipamentelor, datelor i programelor care
privesc toate componentele unui sistem informatic (hardware i software) i pot fi de urmtoarele
tipuri:
- controale organizatorice: msuri organizatorice folosite pentru protecia la fraude, neatenie
i/sau neglijen;
- controlul dezvoltrii i ntreinerii sistemului, n conformitate cu cerinele utilizatorului,
specificate n proiectul de execuie;
- controale hardware (controale de echipament): msuri de protecie la defeciunile tehnice;
- controale de siguran (echipamente i fiiere): msuri de protecie la pierdere, distrugere sau
alterare, la accesul neautorizat sau la calamiti (ap, foc etc.).
Controale
organizaionale

Controale hardware

Controale generale

Controlul securitii
sistemului

Controlul dezvoltrii i
ntreinerii
Fig. 8.7 Controale generale
293

A.Controale organizatorice n sistemul informatic

Controalele organizatorice sunt metode i tehnici de organizare a activitilor desfurate de
organismele economice, folosite pentru prevenirea pierderilor i/sau alterrilor de date determinate
de fraud, neatenie i/sau neglijen, n vederea asigurrii unui control intern eficient n sistemele de
prelucrare a datelor utilizate de acestea. Principalele tipuri de controale organizatorice sunt:

definirea clar a funciilor, urmat de definirea i separarea clar a sarcinilor angajailor

pentru fiecare funcie;

rotaia angajailor pe funcii i vacane obligatorii;

selecia angajailor care au acces la echipamentele i programele sistemului informatic i

acordarea unui spor de fidelitate.
Definirea clar a funciilor, urmat de definirea i separarea clar a sarcinilor i
responsabilitilor (rspunderilor) angajailor pentru fiecare funcie, joac rolul-cheie n asigurarea
controlului oricrui tip de sistem de prelucrare i eviden a datelor (manual, mecanic, semiautomat
sau automat), deoarece protejeaz organismul economic mpotriva pierderilor de date, care conduc
la alterarea rezultatelor prelucrrilor. Pentru asigurarea unui control intern puternic ntr-un sistem de
prelucrare i eviden a datelor (manual, mecanic, semiautomat sau automat) din cadrul unui
organism economic, nici un angajat nu trebuie s aib sarcina i rspunderea complet pentru
efectuarea unei activiti; operaia executat de o persoan trebuie verificat de o alt persoan, care
ndeplinete o alt sarcin, vizavi de activitatea respectiv. Separarea sarcinilor ntre angajai diferii
asigur corectitudinea nregistrrilor de date (pe hrtie sau suport magnetic) i a rapoartelor,
protejnd totodat organismul economic respectiv mpotriva pierderilor de date determinate de fraude
sau neglijene.
Schimbrile produse de utilizarea unui sistem automat de prelucrare a datelor n organizarea
activitilor desfurate de un organism economic trebuie s urmreasc att folosirea eficient a
echipamentelor i programelor componente ale sistemului informatic, ct i asigurarea unui control
intern puternic n cadrul acestuia.
Trecerea de la prelucrarea manual sau mecanic a datelor la prelucrarea automat a
acestora permite unificarea activitilor i integrarea funciilor dintr-un domeniu de activitate, deoarece
un singur calculator poate executa, cu uurin, toate operaiile corelate din cadrul unui organism
economic. Acest lucru este posibil, fr slbirea controlului intern, pentru c un calculator programat
corect nu are posibilitatea sau interesul s ascund erorile i de aceea poate efectua orice
combinaie de funcii considerat incompatibil de un control intern puternic ntr-un sistem tradiional
de prelucrare a datelor (manual sau mecanic).
294

innd cont i de faptul c ntr-un calculator programele i datele se pot modifica fr a putea
fi observat acest lucru, se impune folosirea unor controale organizatorice compensatoare pentru
asigurarea siguranei programelor i a datelor n vederea obinerii unor rezultate corecte ale
prelucrrilor efectuate n interiorul sistemului informatic.
De exemplu, ntr-un sistem manual de prelucrare a datelor, funcia de nregistrare a plilor,
n numerar, este incompatibil cu funcia de verificare a extraselor de cont, deoarece cea de-a doua
servete ca metod de verificare pentru prima, atribuirea ambelor sarcini aceluiai funcionar
permind acestuia s ascund erorile. Dac cele dou funcii, de nregistrare a plilor i de verificare
a extraselor de cont, sunt efectuate de un calculator, ele devin compatibile, deoarece calculatorul,
programat corect, nu ascunde erorile. Dar, un programator poate modifica programul astfel nct s
fie nregistrat o plat fr baz real, motiv pentru care acesta nu trebuie s ndeplineasc i
funcia de nregistrare a plilor.
Pentru folosirea eficient a fiecrui calculator din dotare, organismele economice combin i
concentreaz funciile de prelucrare a datelor la nivelul unui compartiment specializat, numit
departament de informatic sau centru de calcul sau centru de prelucrare automat a datelor.
Dac funciile combinate i/sau concentrate la nivelul departamentului de informatic sunt
considerate incompatibile din punctul de vedere al unui control intern puternic, se realizeaz
controale organizatorice compensatoare la nivelul planului de organizare al departamentului
informatic respectiv, deoarece ntr-un sistem informatic programele i datele pot fi schimbate, fr a
se observa modificarea lor.
Planul de organizare al departamentului informatic trebuie astfel conceput nct s previn
intervenia neautorizat a factorului uman n procesul de prelucrare automat a datelor, s previn
accesul neautorizat al personalului la echipamentele, programele sau datele sistemului informatic.
Acest lucru poate fi realizat prin definirea clar a funciilor n departament i prin definirea i
separarea clar a sarcinilor angajailor pentru fiecare funcie.
De exemplu, un program ut ilizat s fac pli poate fi proiectat s aprobe plata unui furnizor
de materiale sau servicii numai dac factura de plat a fost emis pe baza unei comenzi i dac
exist o not de recepie. Dar un angajat care are dreptul s fac modificri n programul de
aplicaie poate efectua plai, fr baz real, ctre anumii furnizori, dac planul de organizare al
departamentului informatic respectiv i permite s fac i pli.
Structura organizatoric a fiecrui organism economic i numrul angajailor de specialitate
disponibili determin gradul de separare a sarcinilor legate de proiectarea i/sau realizarea i
exploatarea unui sistem informatic. Ca un minim necesar, funcia de programator, care necesit

295

cunotine detaliate despre programul de aplicaie folosit, trebuie separat de funcia de operator,
care deine controlul intrrilor n programul respectiv.
Dac structura organizatoric a unui organism economic, care folosete pentru evidena i
controlul activitilor sale un sistem informatic, permite unui angajat s realizeze att sarcini de
programator, ct i de operator, se slbete controlul intern, existnd permanent posibilitatea de
fraud.
Separarea activitii de exploatare de cea de programare este foarte important din punct de
vedere al asigurrii unui control intern eficient, deoarece un angajat care realizeaz ambele funcii
poate face schimbri neautorizate n programul sistemului informatic, producnd fraude. Istoria
fraudelor computerizate arat c, de cele mai multe ori, persoanele implicate au intervenit n sistemul
informatic, ca programator i operator, controlnd folosirea lui.
De exemplu, dac programatorul care a scris programul de identificare i listare a tuturor
conturilor clienilor ce extrag sume de bani mai mari dect limitele admise are acces la sistemul
informatic al bncii ca operator, el poate modifica programul astfel nct depirea limitei de extragere
admis s fie ignorat, n cazul propriului su cont.
Programatorul operator poate astfel extrage sume de bani din contul su, fr ca sistemul informatic
utilizat s semnaleze administratorului acest lucru. Frauda nu poate fi descoperit pn cnd
programul nu este revizuit de un alt programator sau pn cnd calculatorul nu se defecteaz i lista
conturilor cu depiri de limit trebuie pregtit manual.
Dac structura organizatoric a unui organism economic permite accesul personalului de
exploatare a sistemului informatic la activele organismului economic respectiv, se slbete, n mod
serios, controlul intern, n cazul n care nu sunt implementate msuri de control (controale
organizaionale) compensatorii. De exemplu, dac acelai angajat ine att evidena activelor unui
organism economic folosind un sistem informatic, ct i pstrarea (gestiunea) fizic a acestora, prin
combinarea responsabilitilor corespunztoare celor dou sarcini se creeaz posibilitatea ca
angajatul respectiv s ascund sustragerea de active (bani, marf etc.).
De aceea, organismele economice care folosesc sisteme informatice pentru evidena computerizat
a activelor trebuie s limiteze, pe ct posibil, accesul personalului de exploatare la activele respective.
Totui, personalul de exploatare al unui sistem informatic poate avea:
- acces direct la active; exemplu: dac sistemul informatic este folosit pentru tiprirea
cecurilor (acces direct la sume de bani);
- acces indirect la active; exemplu: dac sistemul informatic este folosit pentru a genera
ordine de livrare cu autorizarea de eliberare a mrfii (acces direct la marfa de livrare).

296

Ca msur de control compensatorie se pot folosi documente i totaluri pe loturi, lista cu

numrul de documente i totalul datelor semnificative pentru fiecare lot fiind pregtite n dou
departamente diferite ale organismului economic respectiv, pentru compararea rezultatelor.
De exemplu, departamentul care autorizeaz tiprirea cecurilor trebuie s ntocmeasc o list cu
numrul total de cecuri i suma autorizat pentru fiecare, tiprirea acestora fcndu-se n alt
departament care, la rndul lui, ntocmete o list cu numrul de cecuri tiprite i suma aferent
fiecruia.
Pentru fiecare lot, se compar totalurile realizate independent de cele dou departamente
diferite ale organismului economic respectiv: totalul calculat nainte i dup eliberarea cecurilor.
Controalele compensatorii nu pot elimina, n ntregime, riscul rezultat din faptul c personalul de
exploatare a sistemului informatic are acces, direct sau indirect, la activele organismului economic.
Din acest motiv, auditorii trebuie s tie c, acolo unde personalul de exploatare a sistemului
informatic are acces la active, frauda care implic utilizarea calculatoarelor poate fi mai mare dect n
alte cazuri.
Rotaia, pe funcii, a angajailor care au legtur cu sistemul informatic implementat de un
organism economic se face cu scopul de a evita schimbrile neobservabile de date i programe
efectuate n calculator, fie din interes (fraud), fie din neatenie sau neglijen.
Planul de organizare al unui departament de informatic trebuie s includ un mecanism de
rotaie a sarcinilor i vacane obligatorii pentru angajaii si, pentru c schimbarea programatorilor sau
operatorilor (ntre ei) faciliteaz descoperirea modificrilor accidentale sau neautorizate de date i
programe.
Rotirea, pe funcii, a angajailor care se ocup cu prelucrarea i evidena datelor asigur un
control intern eficient n orice tip de sistem de prelucrare i eviden a datelor folosit de un organism
economic, programelor din sistemele informatice corespunzndu-le n sistemele tradiionale
documentele scrise.
Selecia angajailor care au acces la echipamentele i programele sistemului informatic folosit
de un organism economic, precum i la datele vehiculate n cadrul acestuia, trebuie f cut pe baza
unor criterii care elimin, pe ct posibil, posibilitile de fraud i producerea erorilor din lipsa
cunotinelor profesionale, din neatenie sau neglijen; personalul de ntreinere i exploatare trebuie
ales cu grij, pentru a reduce posibilitatea de distrugere intenionat produs de un angajat
nemulumit.
Principalele criterii de selecie a personalului care are legtur cu sistemul informatic sunt:

297

nivelul de pregtire profesional dovedit prin: diplome de studii, pregtire teoretic i

ndemnare practic, experien dobndit n timp (vechime n domeniu), calificative
obinute la locurile de munc anterioare etc.;
- moralitate i seriozitate demonstrate prin: cazier judiciar, nscrisurile din documentele de
angajare (frecvena i motivele de schimbare a locurilor de munc), recomandri de la
locurile de munc anterioare i/sau de la ali specialiti n domeniu (profesori, colegi,
cunotine) etc.;
- fidelitatea fa de organismul economic la care lucreaz.
Selecia atent a personalului care se ocup cu prelucrarea i evidena datelor din cadrul
unui organism economic este foarte important n realizarea unui control intern eficient, indiferent de
tipul sistemului de prelucrare i eviden a datelor utilizat (manual, mecanic, semiautomat sau
automat). Planul de organizare al unui organism economic, cu sau fr departament de informatic,
trebuie s includ un spor de fidelitate pentru angajaii si care lucreaz n domeniul informatic pentru
a evita fraudele computerizate, greu de depistat i foarte periculoase pentru evoluia organismului
economic respectiv.
-

Concluzie. Controalele organizaionale joac rolul-cheie n asigurarea unui control intern

puternic n cadrul unui sistem informatic, n vederea prevenirii fraudelor, care au implicaii majore
asupra evoluiei oricrui tip de organism economic. Ele sunt destul de eficiente n prevenirea
fraudelor produse de un singur angajat, dar nu pot preveni fraudele n complicitate, foarte dificil de
depistat.
Dac un angajat-cheie al organismului economic conspir cu ali angajai n vederea comiterii unei
fraude, controalele organizaionale interne care se bazeaz pe separarea sarcinilor i rotirea
angajailor pe funcii devin inoperante.
De exemplu, dac persoane de conducere i angajai ai unui organism economic fac tranzacii fictive
i ntocmesc documente false care susin aceste activiti, cu scopul de a induce n eroare auditorii i
organismele de control abilitate, orice structur organizatoric de control este ineficient. Dac nu
sunt descoperite n timp util, fraudele n complicitate conduc la falimentul organismului economic
respectiv.
B. Controale de dezvoltare i ntreinere a sistemelor informatice
Mutaiile din domeniul tehnologiilor informaionale i al metodelor de abordare a
sistemelor s-au reflectat i n ciclul de via al dezvoltrii sistemelor, fie prin schimbrile
etapelor acestuia, fie prin modificarea ordinii de parcurgere a lor. Indiferent de numele i de
numrul etapelor ciclului de via al dezvoltrii sistemelor, o problem mult mai important este

298

aceea a ordinii i felului cum se parcurg etapele respective, ceea ce n literatura de specialitate
se trateaz sub numele de modele ale ciclului de viaa a sistemului informatic.
Modelul cascad este unul de referin asigurnd trecerea de la o etap la alta n ordinea
secvenial a posibilitii revenirii la etapele anterioare sau parcurgerii n paralel a mai multor
etape.
Figura 8.8 red activitile parcurse pentru obinerea unui sistem informatic.
Definirea
cerinelor
Analiz
Proiectare
Implementare
Testare
Utilizare i
ntreinere

Fig. 8.8 Ciclul de via a unui sistem informatic

1.Definirea cerinelor
n cadrul acestei etape se identific problemele care trebuie soluionate i se
elaboreaz planul proiectului de dezvoltare a viitorului sistem informatic.
La nceput, se realizeaz un studiu complex privind activitile, fluxurile informaionale
existente, volumul informaiilor prelucrate i aria de cuprindere a sistemului. Se poart discuii cu
specialiti ai domeniului i cu potenialii utilizatori ai viitorului produs informatic.
Pe baza studiului realizat se obin informaii cu privire la cerinele, restriciile i
obiectivele avute n vedere pentru asigurarea funcionalitii noului sistem.
Definirea clar a cerinelor funcionale i tehnice reprezint nceputul formalizrii
proiectelor: identificarea, organizarea i iniierea acestora.
Auditorul, n calitate de membru al echipei de proiectare, va analiza urmtoarele
aspecte:
- un utilizator din fiecare departament afectat de noul sistem a fost inclus n echipa de
proiectare;
- s-a fcut o planificare a proiectului;
299

n proiect este implicat i un reprezentant al conducerii;

estimarea calitativ-cantitativ a costurilor i beneficiilor s-a fcut pe baza unor studii de
fezabilitate;
- se are n vedere efectuarea unor studii de fezabilitate pe parcursul dezvoltrii
proiectului;
- se cunoate impactul pe care l are noul sistem asupra organizaiei;
- s-au estimat costurile sociale datorate schimbrii sistemului.
Pe parcursul dezvoltrii sistemului, auditorul intervine n urmtoarele puncte de control:
a) realizeaz o revizie final a planurilor, echipamentelor mecanice, costurilor
implicate pentru a selecta cea mai bun variant de proiect;
b) revizuiete documentaia prin care sunt descrise fiierele, interfeele de dialog,
formularele i rapoartele, pentru a se asigura c sunt complete, clare i n raport cu
standardele adoptate;
c) verific respectarea specificaiilor proiectrii iniiale sau dac exist posibilitatea
aplicrii modificrilor intervenite pe parcursul derulrii proiectului.
-

2. Analiza sistemului
Concluziile la care ajunge echipa de analiti, dup parcurgerea etapei anterioare, se va regsi n
proiectul de realizare a sistemului informatic.
n analiza sistemului informaional trebuie s regsim aspectele:
- aria de ntinderea a sistemului informaional care va deveni sistemul obiect pentru
conceperea i realizarea unui sistem informatic.
- reflectarea activitilor i operaiilor economice specifice sistemului informaional
surprinderea modificrilor ce se impun n organizarea i funcionarea unui sistem
informatic.
- fundamentarea unei soluii de principiu care s precizeze activitatea i operaiile ce
urmeaz a fi informatizate.
- costul antecalculat al sistemului.
n analiza sistemului economic ca etap a ciclului de via al unui sistem informatic auditorul
urmrete:
- ntocmirea specificaiilor de utilizator: definirea cerinelor utilizatorului;
- ntocmirea specificaiilor sistemului informatic: prezentarea, n detaliu, a rezultatelor pe
care trebuie s le ofere sistemul informatic utilizatorilor si; la acest nivel se stabilete
ce trebuie s fac sistemul informatic;
- ntocmirea specificaiilor software: prezint ce trebuie s fac produsul software de
aplicaie i condiiile pe care trebuie s le respecte;
300

se utilizeaz un model abstract de reprezentare, care las libertatea de proiectare,

implementare i dezvoltare ulterioar a sistemului informatic respectiv

1. Proiectarea i realizarea sistemului

Planificarea i coordonarea ntregii activiti privind realizarea proiectului informatic

revine managerului de proiect. Acesta reprezint persoana cea mai autorizat s decid care
este cea mai bun strategie pentru realizarea proiectului, care este cea mai bun organizare a
echipei, prin poziionarea membrilor acesteia n posturile adecvate pentru a-i ndeplini sarcinile
ct mai bine i mai eficient.
Planificarea are drept scop ndeplinirera obiectivelor proiectelor, obiective precizate mai jos:

Performan i calitate. Rezultatul final trebuie s corespund scopului. n acest sens,

standardele de calitate joac un rol important.

ncadrarea n bugetul alocat. Nencadrarea n buget poate conduce la reduceri ale profitului i
la rate de eficien mai sczut ale investiiei.
ncadrarea n durata de realizare.

Trebuie urmrit ca toate etapele proiectului s se ncheie la momentul prevzut, pentru a

permite ncheierea proiectului la sau naintea datei prestabilite. Dac se depete durata de
realizare pot aprea dou aspecte negative: se depete, cu mare probabilitate bugetul alocat
i se afecteaz planificarea resurselor pentru urmtoarele proiecte.
Ca principiu de proiectare i realizare a a unui sistem informatic, aplicarea celor mai
moderne tehnici de proiectare i folosirea celor mai noi echipamente i programe urmrete
realizarea unui sistem informatic performant i cu un ciclu de via maxim.
Proiectarea i realizarea unui sistem informatic integrat trebuie s permit introducerea
unic i exploatarea multipl a datelor, n funcie de nevoile utilizatorului, tiut fiind faptul c
volumul cel mai mare de munc const n culegerea datelor.
Pentru ca managementul unui proiect s fie ct mai eficient, elementele planului de realizare a
proiectului trebuie estimate ct mai corect i aranjate ntr-o secven logic de derulare ct mai
coerent i logic.
n prim faz se procedeaz la inventarierea i ntocmirea listei de activiti care trebuie
executate.
Lista de activiti trebuie s fie ct mai cuprinztoare i pentru elaborarea ei s se
poat recurge la o sesiune de braistorming cu alti conductori de proiecte i cu
conducerea firmei beneficiare. Cu aceast ocazie se va urmri n mod deosebit
menionarea activitilor, nu i succesiunea acestora.
n faza urmtoare, activitile inventariate vor fi descompuse n subactiviti stabilind
succesiunea logic a lor i apoi planificate n timp.

301

Pe baza normativelor existente, dar mai ales a experienei acumulate, se trece la

stabilirea duratei activitilor din list. Durata fiecrei activiti depinde de etapa de realizare n
care ne gsim. Unitatea de exprimare a duratei este, de regul, ziua sau sptmna i este
recomandat ca durata unei activiti s fie multiplu de acea unitate
n cazul proiectelor foarte simple, este posibil ca durata acestora s fie egal cu suma
duratelor activitilor componente. Aceasta se poate ntmpla cnd o singur persoan se
ocup de analiz, proiectare, programare i implementare. Situaia normal ns este cnd
lucreaz o echip format din mai multe persoane i fiecare cte o sarcin distinct. Durata
general depinde de interconditionrile dintre aceste sarcini i de ordinea n care sunt realizate.
Numrul de activiti care se pot realiza n paralel depinde de numrul de membri care sunt n
echip i de faza n care se gsete proiectul.
Dup estimarea duratei activitilor, lista activitilor se poate completa cu duratele
corespunztoare i apoi se face cunoscut tuturor membrilor echipei astfel nct distribuirea
sarcinilor s fie pe ct posibil echitabil.
Analizele utilizate pentru planificarea timpului nu pot pune n eviden i volumul resurselor
necesare la un moment dat pentru derularea proiectului.
n general exist ase categorii de resurse care trebuie evaluate i planificate de ctre
managerul de proiect, i anume:

resursele umane;

echipamentele i materialele;

serviciile;

transportul;

instalaiile necesare pentru realizarea proiectului;

resursele financiare.
Unele proiecte pot necesita numai o parte din aceste resurse, altele pot necesita toate cele ase
categorii de resurse .a.m.d.
Resursele umane, echipamentele i materialele sunt de mare importan pentru performanele
oricrui proiect.
2. Controlul proiectelor
Prin controlul proiectelor trebuie s se urmreasc progresele realizate n dezvoltarea
proiectelor, n raport de obiectivele stabilite. Trebuie s ne asigurm c proiectul va fi finalizat la
data prevzut n contract, c se ncadreaz n bugetul specificat i c furnizeaz ce s-a stabilit,
la o calitate ridicat.

302

Controlul iniierii proiectului de dezvoltare a sistemului informatic asigur auditorii c decizia

privind realizarea sau achiziia unui nou sistem este n conformitate cu obiectivele i planurile
organizaiei.
Controlul const din dou pri:
- urmrirea;
- luarea masurilor.
Este cunoscut faptul c niciodat lucrurile nu evolueaz aa cum sunt planificate.
Factorii care produc modificri n derularea proiectelor pot fi urmtorii:
- estimrile fcute la planificarea proiectului pot fi greite;
cerinele se pot schimba;
- termenul final se poate schimba (de obicei, mutndu-se mai devreme);
bugetul se poate micora;
- prioritatea proiectului se poate schimba;
rezistena la schimbri;
greelile oamenilor.
Gradul de complexitate a proiectelor sunt factori care determin metoda de control i raportare.
Din acest punct de vedere distingem mai multe situaii posibile: proiecte simple, proiecte de
dimensiune medie i proiecte complexe.
Auditorul verific dac metodele de proiectare a sistemelor informatice reduc prelucrarea unor
volume mari de date obinute ntr-un interval mare de timp.
n realizarea sistemului informatic ca etap a ciclului de via auditorul urmrete:
- realizarea componentelor sistemului informatic din arhitectura sistemului informatic, pe
baza soluiilor oferite de proiectarea n detaliu;
- testarea componentelor i verificarea modului de funcionare;
- verificarea ndeplinirii cerinelor utilizatorului; verificarea fiabilitii n utilizare;
integrarea componentelor n sistemul informatic i testarea final a acestuia-reunirea
componentelor n produsul final i verificarea funcionrii acestuia, n ansamblul su.
Dezvoltarea unui sistem informatic alegnd soluia outside, presupune c achiziia
echipamentului se va face de ctre organizaie, iar aplicaiile vor fi dezvoltate si achiziionate de
la furnizor.
Dezvoltarea unui sistem informatic alegnd soluia outsourcering, apeleaz la servicii externe
pentru tot ceea ce nseamn sistem informatic.
3 . Implementarea i testarea sistemului
Implementarea sistemului informatic este acea etap n care se realizeaz efectiv trecerea de la
vechiul sistem de lucru la cel nou. Este o etap foarte dificil, deoarece necesit conlucrarea
303

strns dintre realizatorii sistemului informatic i beneficiarii acestuia. Este etapa n care
sistemul este supus la cea mai dificil testare, cea a condiiilor reale de funcionare. Acum pot
aprea cazuri care nu au fost prevzute de proiectani, la care sistemul nu este protejat.
Implementarea sistemului const n punerea n practic a specificaiilor logice i are n vedere:

corelarea modulelor din punct de vedere al funciilor logice realizate (invocri, utilizri);

crearea interferenei dintre module conform standardelor de intrare/ieire;

ordinea n care modulele sunt codificate, testate i implementate;

calitatea datelor i destinaia rapoartelor;

cerinele fiierelor i ale bazei de date (numr, coninut, tipuri de date, tipuri de acces,
tipuri de nregistrri, etc.);

ordonana activitilor de implementarea, instalarea i de instruire specifice sistemului

considerat.
n cadrul acestei etape se testeaz, se verific i se asimileaz de ctre beneficiar toate
soluiile stabilite n etapele anterioare i se valideaz rezultatele obinute.
Controlul implementrii noului sistem informatic prevede:
- atribuirea responsabilitilor persoanelor care se vor ocupa de implementare;
- stabilirea unor standarde prin care s se asigure eficiena i eficacitatea procesului de
implementare;
- existena unui plan al implementrii, pe baza cruia s se poat evalua progresele fcute.
n timpul implementrii, numeroase activiti vor fi executate simultan. De aceea, ele
trebuie s fie planificate i programate de ctre o echip de implementare format din utilizatori,
manageri i specialiti n proiectarea sistemelor.
Planificarea implementarii, firesc, ncepe anterior demarrii unei astfel de aciuni. De fapt,
problemele implementrii sunt abordate chiar la nceputul proiectului, iar aspectele conceptuale
i strategiile implementrii i conversiei sistemelor trebuie luate n discuie n fiecare stadiu al
ciclului de via al sistemelor. Totui, planurile detaliate de implementare nu pot fi finalizate pn
cnd conducerea nu aprob proiectul noului sistem.
Un plan de implementare evideniaz toate activitile necesare, ajutnd pe cei ce-l
ntocmesc s fie siguri c totul a fost prezentat corect. Prin el se vor consemna toate activitile
de efectuat, precum i timpul alocat. Responsabilitile de execuie trebuie s fie foarte clare. De
asemenea, trebuie estimate costurile fiecrei activiti astfel nct s poat fi elaborat un buget
special. n acelai timp trebuie determinate reperele de execuie n timp, pentru a se putea
exercita controlul. Mai dificil este de estimat momentul cnd se va finaliza implementarea. De
fiecare dat utilizatorii sunt cei care i dau acceptul final, iar procesul, teoretic, poate fi
considerat ca desfurndu-se pe o perioad nedefinit.

304

Planul de implementare este revizuit i modificat la interveniile comitetului de

informatizare, ale utilizatorilor, ale conductorilor sistemului, nainte de a ncepe operaiunea de
implementare.
Ca membru al echipei ce rspunde de implementarea noului proiect, auditorul are
sarcina de a proiecta i evalua controalele implementate la nivelul sistemului.
Testarea este efectuat, de regul, de personal specializat, care coordoneaz ntreaga
activitate.
Auditorii pot folosi pentru testarea i monitorizarea controalelor interne implementate ntr-un
sistem informatic sistem integrat de testare, care const n integrarea unui set de fiiere de
testare, programe i date de testare n sistemul informatic respectiv.
La testare un rol important revine efului echipei de programare care trebuie s integreze
fiecare modul testat separat i apoi s testeze ntregul program. ntotdeauna testarea va
produce mai multe versiuni de module i de produse program, ultima fiind cea acceptat. La
fiecare versiune se face o evaluare i se opereaz corecia.
Testarea nu se ncheie dect atunci cnd se efectueaz lansarea prelucrrii de ctre
ntreaga aplicaie informatic cu un set complet de date. Acest set va include toate datele
posibile, corecte i eronate pentru a urmri reacia ntregului pachet de programe. n aceast
testare global se urmrete: validarea datelor de intrare i a rezultatelor, dialogul din sistemul
informatic, modul de operare la execuie. Se urmresc att aspectele formale ct i cele de
fond.
n urma testrii, auditorul trebuie s se asigure c:
- sistemul funcioneaz corect;
- n cazul ntreruperii prelucrrilor, sistemul transmite mesaje de avertizare utilizate;
- nu exist prelucrri neefectuate.
Un test complet de acceptare const n efectuarea testrii pilot i a testrii paralel.
n cazul testrii paralele datele vor fi preluate att prin intermediul vechiului sistem ct i cu
ajutorul sistemului nou.
Testarea pilot presupune c noul sistem va procesa o cantitate mare de date reale sau de test.
Auditorul trebuie sa produca dovezi ca a inteles modul de functionare a SI si controalele
acestuia.
- Aceasta a obinut cunoaterea i prin documentare asupra :

Fluxului tranzaciilor prin sistem

Controalele aplicate intrrilor, prelucrrilor, ieirilor.

Auditorul trebuie s identifice i s cunoasc orice documentaie a aplicaiei existent la
client.
305

6. Mentenana sistemului
Activitatea de mentenan include un proces de revizuire post-implementar pentru a se asigura
c sistemele informatice nou implementate corespund obiectivelor, cerinelor i performanelor
prestabilite.
Pe timpul mentenanei un grup de persoane se va ocupa de colectarea cererilor de ntreinere
lansate de utilizatori sau de alte pri implicate n exploatarea sistemului sau verificarea modului
n care acesta funcioneaz. Activitile implicate de mentenana sistemului sunt:
obinerea cererilor de ntreinere;
transformarea cererilor n propuneri de schimbri;
proiectarea schimbrilor;
implementarea schimbrilor.
Auditorul trebuie s verifice dac exist proceduri prin care se asigur executarea numai a
modificrilor autorizate n cadrul controlului ntreinerii sistemului.
ntruct cheltuielile de mentenan au o pondere substanial n structura costurilor totale ale
sistemelor, considerm relevant prezentarea tipurilor de mentenan: corectiv, adaptativ,
perfectiv, preventiv.
Mentenana corectiv const n efectuarea unor lucrri de reparaii pentru ndeprtarea unor
defecte produse n timpul proiectrii, scrierii programelor sau implementrii sistemului. n
majoritatea cazurilor, ntreinerea corectiv intervine imediat ce se pune n funciune noul sistem
sau o component a acestuia. Ct timp o astfel de ntreinere i propune doar s ndeprteze
defecte, ea nu adaug valoare dect ntr-o pondere derizorie, n pofida celor 75 de procente
alocate ntreinerilor corective din totalul activittilor de ntreinere a sistemului.
Mentenana adaptativ presupune efectuarea unor schimbri n sistem, condiionate de:
intenia de mbuntire a performanelor funcionale; adaptarea la schimbrile organizaionale;
deplasarea sferei de activitate a unitii n alt mediu.
Dac ntreinerea corectiv presupune o intervenie ct mai urgent n urma sesizrilor venite
din sistem, cea adaptiv nu este la fel de presant, ntruct factorii care o condiioneaz nu au
apariii spontane. O alt diferen const n faptul c ntreinerea adaptiv, spre deosebire de
cea corectiv, adaug valoare organizaiei.
Mentenana perfectiv are ca scop efectuarea unor schimbri pentru mbuntirea diverselor
prelucrri, modificarea cu scopul folosirii mai uoare a interfeelor sau pentru a i se aduga noi
elemente, care ns nu sunt strict necesare. O astfel de operaiune de ntreinere constituie mai
306

curnd o dezvoltare a sistemului i face parte din categoria activitilor care adaug valoare
organizaiei.
Mentenana preventiv se efectueaz cu scopul diminurii substaniale a posibilitilor de
defectare a sistemului, adaug valoare organizaiei.
Activitatea de mentenan trebuie evaluat pentru a observa dac, la un moment dat, cheltuielile
implicate nu depesc limitele acceptabile. Dac la un moment dat se constat c beneficiarele
sunt puternic afectate de cheltuielile cu mentenana, se poate concluziona c sistemul nu mai
rspunde necesitilor i este necesar nlocuirea sa parial sau total. n felul acesta se reia
ciclul de via al dezvoltrii sistemului

C. Controale hardware
Echipamentele digitale, componentele hardware ale sistemelor moderne de prelucrare automat i
de eviden a datelor au, din construcie, o precizie foarte mare i o fiabilitate foarte bun; prin
urmare, tolerana de calcul nu produce erori n rezultatele finale ale prelucrrilor efectuate, iar
defeciunile tehnice care determin alterri i/sau pierderi masive de date i programe sunt puine.
Pentru evaluarea corect a fiabilitii echipamentelor digitale utilizate la implementarea unui sistem
informatic, n vederea prevenirii pierderilor (de date i programe) i reducerii erorilor (n rezultatele
finale ale prelucrrilor) produse de posibilele defeciuni tehnice ale acestor echipamente, economitii,
inclusiv auditorii, trebuie s cunoasc controalele integrate de fabricant n fiecare tip de echipament,
care sunt ntlnite n literatura de specialitate sub numele de controale hardware.
Cele mai ntlnite controale hardware sunt:
Ecoul: const ntr-un semnal pe care echipamentul periferic l trimite (returneaz) ctre unitatea
central de prelucrare, dac a recepionat corect datele transmise de aceasta; prin ecou se verific
dac echipamentul periferic se comport n conformitate cu instruciunile primite de la unitatea
central de prelucrare.
Autodiagnoza: const n folosirea unor tehnici i proceduri hardware pentru testarea propriilor
circuite; majoritatea echipamentelor moderne, care fac parte din sistemele de prelucrare automat a
datelor, conin tehnici sau proceduri de autodiagnoz; exemplu: identificarea circuitelor de interfa
sau modulelor de memorie defecte, nainte ca sistemul s poat fi considerat valid, permind astfel
utilizatorului s evite utilizarea unui sistem defect (Post- Power On Self Test).
Verificarea prin duplicare: const n realizarea fiecrei operaii de dou ori i compararea rezultatelor;
n procesul dublu de verificare, cunoscut sub numele de citire dup scriere, calculatorul citete datele,
dup transferarea lor n sistem, i le verific corectitudinea.

307

Verificarea paritii: const n controlul sau verificarea paritii ntr-un sistem de calcul digital, modern,
care prelucreaz datele n serii de bii (cifrele binare 1 i 0); controlul paritii se face prin compararea
valorilor bitului de paritate, calculate nainte i dup un transfer de date, pentru a verifica dac bii de
date s-au modificat pe durata transferului; bitul de paritate, care conine suma tuturor biilor de
1(unu) pari sau impari, n funcie de construcia fiecrui echipament digital, este adugat de fabricant
la biii de date folosii pentru reprezentarea numerelor sau caracterelor alfanumerice transferate ntre
componentele unui sistem digital de calcul.
Concluzie. Asigurarea funcionrii corespunztoare a hardware-ului unui sistem modern de
prelucrare automat a datelor, n vederea evitrii pierderilor sau alterrii de date i programe,
determinate de apariia unor defeciuni tehnice, impune nu numai folosirea controalelor hardware
prevzute de fabricantul echipamentelor, ci i aplicarea unui mecanism de ntreinere preventiv
conceput de ctre organismul economic care utilizeaz sistemul informatic respectiv. Auditorii de
sisteme informatice trebuie s cunoasc nu numai controalele hardware integrate de fabricani n
echipamente, ci i msurile de ntreinere preventiv folosite, mpreun cu modul de aplicare a
acestora.
D. Controale de siguran
Fiecare sistem automat de prelucrare a datelor trebuie s dispun de controale pentru asigurarea
siguranei:

echipamentelor componente (hardware), pentru a nu fi deconfigurate (accidental sau voit),

descompletate i/sau distruse;

programelor i fiierelor de date, pentru a nu fi pierdute, alterate, distruse sau accesate de

personal neautorizat; aceste evenimente se pot produce accidental sau voit.
Programele, componentele software ale sistemelor informatice moderne pot produce erori n
rezultatele finale ale prelucrrilor efectuate automat i n evidenele computerizate, deoarece pot fi
distruse sau alterate cu uurin, accidental sau voit, blocnd accesul utilizatorilor la volumele mari de
date stocate n sistem i, implicit, la informaiile obinute prin interpretarea rezultatelor prelucrrilor
efectuate asupra acestora; de asemenea, permit foarte uor distrugerea, alterarea sau pierderea,
acciden-tal sau voit, a bazelor de date stocate i gestionate de sistemul informatic, n condiiile n
care cel mai mare volum de munc rezid n crearea i ntreinerea acestora.
Principalele tipuri de controale de siguran utilizate pentru protecia unui sistem informatic sau a
componentelor acestuia, hardware sau software, sunt:
Programarea sistemului de operare al fiecrui calculator:

s ntocmeasc un jurnal al utilizrii tuturor echipamentelor periferice accesibile (ultimele

utilizri); aceasta asigur identificarea momentului ultimei utilizri corecte i apariiei
primului incident n utilizarea fiecrui echipament periferic n parte; exemplu: indic
308

momentul n care s-a utilizat pentru ultima dat o imprimant i momentul n care aceasta
a fost deconectat de la calculator (descompletarea sistemului);

s emit un semnal de atenionare, dac se fac tentative de acces repetat n sistem, prin
folosirea unor parole incorecte, sau tentative de efectuare a unor operaii care pot distruge
datele sau pot genera anomalii n funcionarea sistemului respectiv; exemplu: utilizatorul
este atenionat de sistemul de operare c operaia de formatare a unui disc magnetic
(HardDisk, FloppyDisk etc.) determin pierderea programelor i/sau datelor stocate pe
acesta, dndu-i posibilitatea s le salveze nainte de efectuarea operaiei respective.

Accesul utilizatorilor n sistemul informatic pe baz pe nivele de acces i parol individual secret;
permite numai personalului autorizat s utilizeze programele componente i datele stocate n sistem;
exemplu: ntr-un sistem de prelucrare distribuit, n care datele pot fi alterate din orice locaie de unde
se poate accesa sistemul, la fiecare punct de lucru sunt necesare msuri suplimentare de control al
accesului, pe baz de parole i nivele de acces, pentru a preveni distrugerea datelor stocate n
sistem i a evita pierderea ncrederii utilizatorilor n informaiile obinute pe baza rezultatelor oferite
de ntregul sistem.
Crearea funciei de administrator al bazei de date, pentru protejarea acesteia la accesul neautorizat,
de ctre organismele economice care utilizeaz sisteme informatice tip baz de date,
administratorul unei baze de date are sarcina principal de administrare a accesului la baza de date,
deoarece, din punctul de vedere al controlului intern ntr-un astfel de sistem, este foarte
important ca baza de date s fie protejat mpotriva accesului neautorizat; exemplu:
administratorul bazei de date a clienilor (fiierul clienilor), care conine toate datele de identificare
i despre activitatea fiecrui client n parte, folosite de secretariat (pentru ntocmirea contractelor), la
departamentul de vnzri (pentru evidena activitii clienilor respectivi), la serviciul contabilitate
(pentru evidena plilor efectuate de acesta) etc., gestioneaz accesul utilizatorilor la baza de date
respectiv.
Programarea fiecrei componente a software-ului de aplicaie utilizat de sistemul informatic:

s emit un semnal de atenionare, dac se fac tentative repetate de acces (prin folosirea
unor parole incorecte), dac se ncearc efectuarea unor operaii care pot distruge
datele sau pot genera anomalii n funcionarea sistemului respectiv; exemplu: programul de
aplicaie atenioneaz utilizatorul, printr-un mesaj, c operaia care urmeaz a se efectua
asupra datelor poate fi produs de un virus care le distruge, lsndu-i posibilitatea de a
decide dac operaia respectiv este sau nu cea programat;

s ntocmeasc o list a celor mai receni utilizatori: nume, parol, data i ora accesului;
aceasta permite identificarea momentelor cnd s-au produs incidente i a utilizatorilor care,
prin modul de operare, determin anomalii n funcionarea Sistemului informatic, pierderi sau
309

alterri de programe sau date, cu scopul de a afla informaii legate de incidentele respective,
n vederea stabilirii posibilitilor de refacere a sistemului, i de se ridica dreptul de acces
tuturor celor care nu-l exploateaz corect;

s ntocmeasc o list cu ultimele operaii efectuate de fiecare utilizator; prin consultarea

acestei liste se identific operaia sau secvena de operaii care produce anomalii n
funcionarea sistemului informatic, pierderi sau alterri de programe i/sau date, n vederea
efecturii coreciilor care se impun.
Crearea unor copii de siguran pentru toate componentele software utilizate de sistemul informatic
(fiiere de date i programe etc.), lucru care permite refacerea acestora, dac sunt pierdute sau
alterate. Din motive de securitate, copiile de siguran se depoziteaz n locaii separate de original.
De exemplu:

benzile sau discurile magnetice, folosite pentru stocarea pe termen lung a datelor i
programelor de aplicaie, pot fi afectate de expunerea la cldur excesiv sau la un cmp
magnetic sau, pur i simplu, de trecerea timpului; de aceea, se recomand crearea a 2
(dou) copii de siguran simultan i transferul periodic al arhivelor de date i programe de
pe un suport magnetic pe altul; pentru siguran, bazele de date trebuie mutate, la intervale
regulate de timp, pe alte discuri sau benzi magnetice; cel mai fiabil suport pentru stocarea
pe termen lung este, n prezent, CD-ul;

n timpul utilizrii, orice fiier (de date sau program) poate fi ters, din greeal, sau poate fi
distrus, n orice moment, de un virus; pentru refacerea rapid a fiierelor pierdute sau
distruse accidental, se recomand pstrarea (salvarea) unei copii de siguran (ultima
versiune corect i/sau complet) n sistem (pe HardDisk) i/sau n exteriorul acestuia (pe
FloppyDisk sau pe CD); exemplu: n sistemele de procesare n loturi, fiierele care sunt
actualizate periodic, numite fiiere master, se salveaz respectnd principiul de salvare
numit bunic tat fiu, potrivit cruia fiierul master curent actualizat este fiul, fiierul
master utilizat n actualizare (care a produs fiul) este tatl i fiierul anterior tatlui este
bunicul; cele trei generaii de fiiere de date se vor depozita n locaii diferite, pentru a
minimiza riscul pierderii tuturor;

n timpul funcionrii, orice sistem de calcul se poate defecta, producnd pierderea/

distrugerea fiierelor stocate (memorate) n sistem (pe HardDisk); de aceea, pentru
prevenirea pierderilor masive de date i programe produse de defeciunile tehnice, se
recomand arhivarea acestora pe suport magnetic extern (FloppyDisk, CD-ROM, CDRW, USB- flash etc.)

Msuri de protecie la accidente sau sabotaj (foc, ap, distrugere etc.), care previn distrugerea
accidental sau deliberat a sistemului informatic, n ntregul su, care constau, de regul, n:
310

limitarea accesului, n aria de desfurare a activitii, numai pentru personalul autorizat;

intrrile n locaiile destinate sistemului informatic trebuie s fie controlate de ageni de
paz sau activate pe baz de cartel de acces;

construirea locaiilor destinate sistemului informatic (camera calculatorului) din materiale

rezistente la foc, deasupra nivelului probabil de inundaie i dotarea acestora cu aer
condiionat, pentru a evita apariia defectelor tehnice i a preveni deteriorarea suporilor
magnetici de stocare a datelor i programelor (benzi sau discuri magnetice) prin
asigurarea unei temperaturi i umiditi corespunztoare n spaiul lor de funcionare.
Concluzie. Fr implementarea msurilor de siguran adecvate (controale de siguran) nu este
posibil asigurarea unui control intern eficient ntr-un sistem informatic, deoarece acestea
protejeaz la distrugere, alterare sau acces neautorizat att sistemul, n ansamblul su, ct i
componentele acestuia.
8.3.2 Controalele de aplicaie
Controalele de aplicaie sunt tehnici de control specifice, integrate n software-ul de aplicaie
(utilizator) dintr-un sistem informatic, cu scopul de a asigura corectitudinea i protecia datelor
stocate n sistemul respectiv i a rezultatelor prelucrrilor efectuate asupra acestor date. Se
proiecteaz i se realizeaz o dat cu fiecare sistem informatic. Principalele tipuri de controale de
aplicaie sunt:
A.
B.

controale de intrare: msuri de asigurare a corectitudinii intrrilor sistemului;

controale de prelucrare: msuri de asigurare a corectitudinii prelucrrilor efectuate n interiorul
sistemului;

C.
controale de ieire: msuri de asigurare a corectitudinii ieirilor sistemului.
Majoritatea erorilor identificate n rezultatele finale ale prelucrrilor efectuate de sistemele
informatice provin din software-ul de aplicaie (de utilizator) folosit sau din introducerea eronat a
datelor. Din acest motiv, controalele de aplicaie joac un rol major n asigurarea unui control intern
eficient n sistemul informatic.

311

Controlul intrrilor

Controale de
aplicaie

Controlul
prelucrrilor

Controlul datelor de
ieire

Fig. 8.9 Controalele de aplicaie

A.

Controlul intrarilor

Intrrile sunt reprezentate de:

- tranzacii externe care redau dinamica operatiilor economice, provin din exteriorul
sistemului informatic electronic de calcul i sunt furnizate de proceduri automate.
Exemplu: nregistrarea unei operaii de aprovizionare cu marf;
- tranzacii interne care redau modificrile structurale din cadrul bazei de date; sunt
asigurate exclusiv n cadrul sistemului informatic prin intermediul procedeului de
exploatare sau de actualizare a bazei de date. Exemplu: totalul facturilor primite de la
un furnizor care actualizeaz soldul furnizorului respectiv.
Este folosit pentru a asigura ca toate tranzactiile sunt :
- introduse corect
- complete
- valide
- autorizate
- aferente perioadei de gestiune curente
- inregistrate corect in conturi (in cazul aplicatiilor contabile).
Auditorul unui sistem informatic trebuie s verifice dac gestiunea unui organism
economic are n vedere introducerea i exploatarea multipl a datelor, n funcie de nevoile
utilizatorului n instruciuni primite i accesibile procesorului.

312

Autorizarea
- Autorizarea controalelor reduce riscul erorilor, fraudei i tranzaciilor ilegale
- Autorizarea poate fi controlat prin identificarea utilizatorului, care a introdus datele n
sistem, pe baza privilegiilor asociate I D-urilor utilizatorilor
- Se introduc doar date autorizate? Cine i cum autorireaz datele de intrare?
Validarea intrrilor:
- se poate realiza manual sau automat
- controalele de validare trebuie s asigure ndeplinirea criteriilor de validare a
datelor
stabilite
- reduce riscul introducerii incorecte de date de la tastatur, dar nu se reduce
probabilitatea aparitiilor erorilor.
Validarea intrrilor, prin aplicarea unor tehnici de verificarea asupra datelor n sistem, asigur:
- corectitudinea datelor: sunt acceptate numai datele corecte care trec testele de verificare;
- completitudinea datelor: sunt identificate datele care lipsesc i sunt solicitate pn cnd
sunt introduce.
Controlul datelor de intrare trebuie adaptat la modalitile diferite de introducere a
datelor n sistem :
- de la tastatur (unde riscul erorilor este mai mare)
- scanarea documentelor
- utilizarea perifericelor senzoriale
- citirea barelor de cod
- ATM-uri i terminale POS
- EDI (ELECTRONI C DATA I NTERCHANGE)
- generarea automat a tranzaciilor (ex.: pli planificate, calcularea lunar a
dobnzilor)
Nu toate intrrile prezint un suport material (documente pe suport hrtie), multe fiind n format
electronic. Folosirea anumitor dispozitive pentru introducerea datelor n sistem (cititoare de codbara, ATM-uri, scanner, terminale POS) reduce posibilitatea apariiilor erorilor n aceast etap.
n cazul prelurii automate sau generrii automate exist riscuri mai mici de eroare fa de
preluarea datelor prin tastare.
Cu ct crete intervalul dintre identificarea existenei unei anumite stri de lucruri sau
evenimente i nregistrarea acestora n sistem, tot att crete posibilitatea apariiilor erorilor n
sistem.
Tipuri de controale aplicate asupra datelor de intrare
313

Controlul formatului
- Se verifica :

Natura datelor

Lungimea datelor ; trunchieri

Numarul de zecimale admis

Acceptarea valorilor negative sau doar a celor pozitive

Formatul datei calendaristice

Aplicarea semnului monetar

Controlul domeniului de definitie a atributelor

ncadrarea ntr-o mulime de valori prestabilit (ex.: abrevierile j udeelor, tipuri de

uniti de msur, tipuri de documente) ;

ncadrarea ntr-un interval de valori prestabilit (ex.: salariul angajatilor ia valori n

intervalul [ 1.000, 3.000.] )

validri ale realizrilor unor atribute diferite numit i testul dependenei logice dintre
cmpuri. Ex.: validrile privind corespondena conturilor contul X se poate debita doar prin
creditarea conturilor A,B,C.

testul rezonabilitii datelor :

- aceste teste verific dac datele sunt rezonabile n raport cu un standard sau date
introduse anterior. Datele standard pot fi stocate ntr-un fiier sau pot reprezenta
constante definite la nivelul aplicaiei (ex.: un standard poate fi reprezentat de numrul
de ore lucrtoare ntr-o lun, stabilit n funcie de zilele lucrtoare i srbtorile legale,
nivelurile de dobnd practicate de banc etc.)
Controlul acurateei ari tmetice
Pe baza unor date de intrare introduse de operator pot fi verificate elementele calculate din
documentul primar.
Ex. : pe baza cantitii i preului unitar al unui articol inscris ntr-o factur sistemul
genereaz automat pe ecran valoarea produsului, TVA-ului, valoarea cu TVA i apoi
totalul facturii operatorul putnd confrunta aceste sume calculate cu cele nscrise n
factura.
Controlul exi stenei datelor
Testul se refer in principal la validarea datelor de intrare reprezentnd coduri. Este
suficient s introduci codul unul client i pe ecran s se afieze numele acestuia sau un
mesaj de eroare atentionand asupra introducerii unui cod incorect.
Testul ci frei de control
- se aplic asupra datelor de intrare reprezentnd elemente codificate
- urmrete rejectarea codurilor eronate introduse
314

- cauza erorii la nivelul elementelor codificate poate fi :

Trunchierea
Adaugrea unui caracter suplimentar
Transcrierea incorecta a codului n documentul primar
Transpoziia caracterelor la introducerea codului.
- presupune determinarea cifrei de control aferente codului introdus prin aplicarea
algoritmului prestabilit. n msura n care cifra de control determinat automat
nu corespunde celei incluse n codul introdus sistemul va trebui s atenioneze
printr-un mesaj corespunztor asupra erorii aprute.
Testul tranzaciilor dupli cate
- sistemul admite introducerea repetat a acelorai date?
Ex. : introducerea repetat a unui aceluiai document (factura, bon de consum etc.).
Soluti onarea tranzaci i lor rejectate
- cum se soluioneaz tranzaciile neacceptate de sistem (care nu au trecut testul
de
validare)?
- cine rspunde de verificarea acestor date de intrare i de reintroducerea lor?
- sunt generate liste coninnd intrrile rejectate?
- dac aceste tranzacii sunt consemnate n documentele primare depistarea erorii
este mai uoar i corectarea se poate face fr probleme deosebite. Probleme
particulare apar n cazul tranzactiilor online.
B. Controlul prelucrrilor

Prelucrrile sunt asigurate de un ansamblu de proceduri automate care realizeaz actualizarea

i exploatarea coleciilor de date ca urmare a tranzaciilor interne i externe n vederea obinerii
rapoartelor, listelor, situaiilor de iesire ale sistemului informatic.
Auditorul unui sistem informatic trebuie s verifice dac sistemul informatic de gestiune
prelucreaz automat datele de eviden i control vehiculate n cadrul oricrui tip de organism
economic sau compartiment specializat al acestuia, innd cont de particularitile specifice
fiecruia i de legislaia n vigoare.
Auditorul ine seama de:
Tipologia sistemului informatic:
- Sisteme de procesare a tranzaciilor (TPS Transaction Processing Systems)
315

- Sisteme destinate conducerii curente (MI S Management I nformation Systems)

- Sisteme suport de decizie (DSS Decision Support Systems)
- Sisteme destinate conducerii strategice (EI S Executive Support Systems)
- Sisteme pentru automatizarea lucrrilor de birou (OAS Office Automation
Systems)
Modalitilor de introducere a datelor n sistem i procesarea acestora:
- I ntroducere pe loturi procesare pe loturi
- I ntroducere on line procesare pe loturi
Natura prelucrrilor:
n cadrul TPS-urilor, de exemplu, pot fi identificate proceduri de:
- Actualizare a bazei de date
- Sortare
- Calcul
- Consultare
- Salvare i restaurare a bazei de date etc.
- Nivelul de descentralizare a prelucrrilor.
n prelucrarea autonom a datelor, urmtoarele funcii trebuie s fie exercitate de persoane
diferite :
- operare calculatoarelor programare
- pregtire date procesare date
- operare calculator gestiune supori materiale
- codarea programelor administrarea bazei de date
Controlul fiierelor i al bazei de date
Se verific:
- Continuitatea acestora
- Versiunea Este ultima versiune? Cuprinde ea toate coreciile?
- Transferul fiierelor n momentul trecerii la exploatarea unui nou sistem
informatic. Se verific msura n care au fost autorizate procedurile de transfer al fiierelor
din vechiul n noul sistem. Au fost aceste proceduri realizate de persoanele mputernicite? Se
verific completitudinea i corectitudinea transferului.
- Soluia aleas pentru arhitectura bazei de date este cea mai bun (varianta baza
de date centralizat sau baza de date distribuit)?
- n cazul bazelor de date distribuite s-a realizat o corect i eficiena distribuire a datelor
n nodurile reelei? n ce msur s-a inut seama de respectarea urmtoarelor
cerine:
316

Nevoile de informare a utilizatorilor locali

Asigurarea unui transfer minim al datelor prin reea

Necesitatea proteciei datelor transferate prin reea.

- Care au fost criteriile pentru alegerea SGBD-ului? Ofera SGBD-ul toate facilitile
privind implementarea controalelor automate, al controlului accesului la baza de date,
tabelele bazei de date etc.
Disponibilitatea datelor
Datele, n procesul prelucrrii, datorit reprezentrii binare sunt inaccesibile auditorului n
aceast form. Mai mult, unele date sunt temporar stocate n memoria calculatorului
(datele intermediare de lucru).
Controlul prelucrrilor declanate automat
- Auditorul trebuie s verifice care sunt evenimentele care declaneaz aceste prelucrri;
- Controlul tranzaciilor generate automat.
Funcionalitatea aplicaiei
- Exist anumite prelucrri pe care aplicaia trebuie s le execute, dar nu le realizeaz sau
le realizeaz greoi?
- Sunt funcionaliti care lipsesc?
- n ce msur aplicaia rspunde stilului i metodei de lucru specifice utilizatorului?
- Determin aplicaia un mod de lucru ineficient, o gndire rigid, nenatural?
Controlul fluxului prelucrrilor
- Presupune s verificm ce prelucrri urmeaz s se declaneze n anumite
circumstane.
- Controalele de aplicaie asigur tehnicile de control, integrate n software-ul de aplicaie
dintr-un sistem informatic, cu scopul de a asigura corectitudinea i integritatea datelor stocate n
sistemul respectiv i a rezultatelor prelucrrilor efectuate asupra acestor date .
- Testul oad conditions : un program poate funciona nesatisfctor cnd este
suprasolicitat (volum mare de date de prelucrat ntr-un interval scurt de timp sau ncarcare
maxim ntr-un anumit moment).
Comunicarea sistemului cu utilizatorul
- Este uor s te pierzi n program?
- Exist opiuni de lucru care pot fi confundate cu altele?
- Care sunt mesajele de eroare? Sunt utile, explicite?
317

- Ce informaie este disponibil pe ecran? Este suficient, clar?

- Calitatea asistenei oferite utilizatorului (informaia returnat de tasta HELP de exemplu).
Performane
n cazul sistemelor n timp real este foarte important timpul de rspuns
I ntegrarea prelucrrilor
In cazul defectrii sistemul de procesare a datelor organizaia poate ncheia un contract cu o
alt organizaie( sau mai multe) al crei sistem de procesare a datelor are aceleai faciliti i
care poate s suporte prelucrrile firmei al crei sistem nu mai este funcional sau poate apela
la o alt firm care ofer servicii n acest domeniu.
C. Controlul datelor de ieire

Ieirile sistemului informatic sunt rezultatul prelucrrii bazei de date i sunt redate n funcie de
coninutul lor i de structura lor sub form de indicatori sintetici, rapoarte, liste, situaii de ieire,
grafice, stocare pe suporturi.
Urmrete :
Completitudinea i acurateea ieirilor
Respectarea termenelor prevzute pentru obinerea ieirilor
Msura n care ieirile, la cererea utilizatorilor, pot fi dirijate ctre imprimant, monitor
sau un fiier.
Distribuirea ieirilor ctre persoanele autorizate :
- Cine primete situaiile? Exist persoane mputernicite n acest sens?
- Situaiile coninnd date sensibile sunt preluate pe baz de semntur?
- Cum este asigurat protecia informaiilor confideniale?
I eirile ctre alte aplicaii se realizeaz n formatul pe care acestea l necesit?
Msura n care se realizeaz nregistrarea, raportarea i corectarea erorilor identificate.
n ce msur exist din partea managementului un control asupra acurateei ieirilor i
modului de distribuire a lor.
Controlul datelor de ieire presupune msuri i proceduri prin care se ofer asigurare cu privire
la :
- completitudinea i corectitudinea informaiilor generate cu ajutorul sistemului.
- distribuirea datelor doar persoanelor autorizate.
- jurnalizarea, urmrirea i corectarea erorilor raportate.

318

8.3.3. Raportul de auditare

Procesul de auditare se finalizeaz cu ntocmirea unui raport care conine propuneri de
msuri de reducere i de meninere sub control a riscurilor importante ale noii aplicaii. Raportul
de auditare este o lucrare de sintez care are la baz o analiz a rezultatelor obinute din
parcurgerea textelor surs, din lansarea n execuie a programelor i din interpretarea
rezultatelor finale, mai ales prin interpretarea rezultatelor intermediare i a celor de urmrire a
programului.
Raportul de audit este o lucrare cuprinztoare care ofer o imagine privind sigurana pe
care o d produsul. Raportul de audit are un rol esenial n angajamentele de audit i asigurare,
deoarece comunic verdictul auditorului. Utilizatorii sistemului informatic se ateapt ca raportul
auditorului s ofere ncredere n utilizarea sistemului informatic. Raportul de audit este un
element fundamental al auditrii prin intermediul cruia se prezint situaia sistemului auditat
aa cum a fost evaluat de auditori. Prin raportul de audit sunt comunicate, prii auditate,
aprecierile i concluziile auditorilor. Obiectivele raportului de audit sunt :
- redarea ncrederii managerilor n sistemul informatic, imediat dup terminarea misiunii de
audit;
- s ofere redomandri utile referitor la perfecionarea procedurilor de control i eficiena
activitii operative;
- s asigure o nregistrare oficial a activitii de audit i a rspunsului managerilor.
n practic, nainte de a prezenta un raport formal, n scris, auditorul are obligaia de a
prezenta un raport verbal celor care rspund de activitatea analizat. Cu excepia cazurilor de
fraud, cnd este necesar uneori ca lucrurile s rmn secrete pn la prezentarea raportului
oficial, n majoritatea cazurilor auditorul discut, n prealabil, cu managerul coninutul raportului
de audit. n acest fel se reduce riscul ca rezultatele auditului s nu fie acceptate de ctre
manager.
Raportul de auditare este un text structurat care conine:
- prezentarea contextului;
- rezultatul procesului de auditare;
- evalurile finale;
- nregistrrile din fiecare etap a procesului de auditare.
Raportul de auditare conine detalii privind:
- descrierea produsului;
- stabilirea condiiilor de utilizare normal;
- operaiile interzise a fi efectuate folosind produsul;
- funciunile pe care le dezvolt n condiii normale, indicnd intrrile, respectiv output-urile;
- efectele secundare care apar atunci cnd intrrile sunt complete i corecte;
319

- riscurile care apar atunci cnd intrrile sunt incomplete i incorecte;

- modaliti de reluare a procedurilor de utilizare.
Raportul de auditare arat c produsul este utilizabil sau produsul devine utilizabil dac
se execut o serie de mbuntiri. Raportul de auditare trebuie astfel ntocmit astfel nct s fie
o imagine fidel a programului de auditare, a resurselor, a input-urilor, a output-urilor i a
metodelor utilizate. Calitatea raportului este dat de modul n care se construiesc componentele.
Textul structurat se alctuiete pas cu pas prin rspunsuri scurte i clare la ntrebrile: cine? ce?
cum? de ce? Este obligatoriu ca raporul s includ seciuni care abordeaz gradat problematica
de audit pentru un sistem informatic.
Prima seciune include elemente de identificare pentru:
- sistemul informatic ce face obiectul auditrii;
- baza n care se deruleaz procesul de auditare ;
- prezentarea echipei de auditori;
- prezentarea elaboratorilor sistemului informatic;
- prezentarea beneficiarului procesului de auditare.
A doua seciune include elemente pentru:
- definirea obiectivului urmrit;
- stabilirea metodelor i tehnicilor stabilite i acceptate;
- structurarea procesului de auditare.
A treia seciune definete planul de auditare i conine descrieri pentru:
- etapele care trebuie parcurse;
- resursele alocate fiecrei etape:
- fluxurile care se genereaz;
- nivelul de exigen i moduri de meninere constant a nivelului;
- comunicarea ntre membrii echipei de auditori, comunicarea auditorilor cu realizatorii
sistemului informatic, cumunicarea cu beneficiarii procesului de auditare.
A patra seciune conine detalierea tuturor surselor utilizate ca ntrebri pentru procesul de
auditare:
- contracte;
- specificaii;
- proiectul sistemului informatic;
- textele surs;
- bazele de date;
- rezultatele testrii efectuate de echipa care a elaborat sistemul informatic;
- documentaii de proces;
- instrumente utilizate de ctre echipa care a dezvoltat sistemul informatic.
320

Sunt descrise listele elementelor utilizate cu comentarii privind calitatea textelor

ntrebuinate de auditori.
Raportul de audit trebuie s fie clar, concis, constructiv i ntocmit la timp. Raportul de
auditare reprezint o prob important n orice aciune declanat de beneficiarul unui sistem
informatic atunci cnd sunt nregistrate diferene semnificative ntre ceea ce trebuia s execute
sistemul
Informatic i ceea ce execut n realitate. Raportul de auditare trebuie s fie clar, concis, s nu
lase loc la interpretri.
Cnd se utilizeaz sintagma <<toate variantele>> nseamn c pentru cele n noduri
terminale ale unei structuri arborescente au fost construite n seturi de date test, atingndu-se
cele n noduri terminale. Pentru a nu lsa loc interpretrilor, din enunul raportului lipsesc
sintagme precum <<n majoritatea cazurilor>>, <<n general>>, <<numai n unele cazuri>>, <<n
celelalte situaii>>, <<nu de puine ori>>, <<este probabil s>>, <<exist posibilitatea ca>> i
toate celelalte construcii care conduc la concluzii vagi.
Raportul de auditare:
- enumer toate componentele;
- analizeaz toate variantele;
- include toate rezultatele;
- enumer situaiile pe categorii de stri, fr a lsa unele situaii neclarificate;
- trateaz cu aceeai msur toate componentele;
- pentru fiecare situaie creat se enumer componentele identificate;
- utilizeaz pentru componentele aceluiai nivel, aceleai instrumente;
- este o construcie consistent;
- include ipoteze, constatri, msurtori care, prin profesionalismul cu care se realizeaz,
nu au un fundament pentru a fi contestate.
Transparena procesului de auditare, rigurozitatea cu care sunt aplicate cerinele
standardelor i claritatea cu care se prezint rezultatul auditrii d o singur direcie destinaiei
raportului i anume acceptarea concluziilor, indiferent care sunt acestea, de ctre cel care a
solicitat auditul sistemului informatic.
Raportul de auditare trebuie s fie convingtor pentru a nu face obiectul comentariilor.
Trebuie s conin descrierea unor aspecte evidente care nu fac obiectul comentariilor sau
negocierilor.
Structura anunat trebuie respectat, iar textul trebuie s fie consistent. O afirmaie fcut
trebuie cel mult susinut. Ea nu trebuie nici nuanat, cu att mai mult nu trebuie contrazis.
Este determinant pentru un raport de auditare s fie calitativ peste nivelul documentaiei,
specificaiilor sau oricrui alt text care provine de la elaboratorii sistemului informatic.
321

Teste de evaluare a cunotinelor

Rspundei prin Adevarat/ Fals:
1. n orice misiune de audit, evaluarea riscurilor reprezint unul dintre principalele
obiective ale auditorului.
2.

n calitate de auditori de sisteme informaionale, examinm controalele existente n cadrul unei

organizaii i, chiar dac ne consultm cu ali specialiti sau ne exprimm propriile opinii,
cutm s perfecionm controalele analizate.

3 Riscul fizic cuprinde defectarea calculatoarelor i a unitilor periferice, precum i

condiiile nesatisfctoare ale mediului n care funcioneaz.
4.

Riscul logic provine din aplicarea greit a anumitor proceduri, a unor instruciuni
greite sau erori umane mai mult sau mai puin intenionate.

5.

Dezvoltarea unui sistem informatic alegnd soluia outside, apeleaz la servicii externe pentru
tot ceea ce nseamn sistem informatic.

ncercuii rspunsurile corecte

6.

Auditul sistemului informatic este o activitate de:

a. control;
b. expertizare;
c. analiza si sinteza.
7.

Care din operatiile de mai jos sunt esentiale in cadrul procesului de audit?

a. delimitarea ariei mediului informatic;

b. planificarea si definirea metodei de audit;
c. verificarea si evaluarea administrarii mediului informatic.
8.

Elementele controlului intern sunt:

a. mediul controlului, evaluarea riscurilor, separarea sarcinilor si atributiilor de serviciu,

autorizari;
b. procedee de control, revizii, monitorizare, informare / comunicare;
c. mediul controlului, evaluarea riscului, procedee de control, monitorizare,
informare/comunicare.
322

9.

Controlul initierii proiectului de dezvoltare a sistemului informatic asigura auditorii ca:

a. decizia privind realizarea sau achizitia unui nou sistem este in conformitate cu obiectivele si
planurile organizatiei;
b. documentatia de sistem, folosita pentru verificarea functiilor sistemului, este in conformitate
cu cerintele utilizatorului;
c. deservirea sistemului informatic este realizata conform normelor si procedurilor
standardizate.
10. Auditorul trebuie sa verifice daca exista proceduri prin care se asigura executarea numai a
modificarilor autorizate in cadrul:

a. controlului conversiei sistemului;

b. controlului implementarii sistemului;
c. controlului intretinerii sistemului.

323

BIBLIOGRAFIE

1.
2.
3.

4.

5.
6.
7.
8.
9.

Andone l., ugui

A.
Arnold de Vos
Bara, I. Botha, V.
Diaconia, I.
Lungu, A.
Velicanu
Baron C.,
Sofronie Gh.,
Surcel Tr., Toma
L.
Benchimol G.,
Levine P.,
Pomerol J.C.
Biemans, F.P.M
Bouch G.,
Rumbaugh J.,
Jacobson I.
Bouzeghoub M.,
Gardarin G.,
Valduriez P.
Celko J.

Baze de date inteligente n

managementul firmei
Utility Management Sistems Acces
Facility
Baze de date. Limbajul PL/SQL

Ed. Dosoftei, lai, 2007

Informatic economic

Ed. Calipso 2000,

Bucureti, 2008

Sisteme expert n ntreprindere

Ed. Tehnic, Bucureti,

2003

A Reference Model for Manufacturing

Research and Technology

Elsevier Science
Publishers, New York,
2000
Adisson Wesley, Reading,
Massachusetts, 2009

The Unified Modeling Language User

Guide
Objets : Concepts, Langages, Bases
de Donees. Methodes, Interfaces,
Deuxieme Tirages
Baze de date orientate obiect - Byte

10. Chichernea V. .a. Proiectarea sistemelor informatice metode de realizare

11. Coad P., Yourdon Conception Orientee Object
E.
12. Connolly, T. and
Database Systems. A Practical
Begg, C.
Approach to Design, Implementation
and Management
13. Coulouris G.,
Distributed systems concepts and
Dolimore J., s.a.
design
14. Curtis G.,
Bussiness Information Systems,
Cobham D.,
Analysis, Design and Practice

324

OMG TC Document dtc

2014
Ed. ASE, Bucureti, 2009.

Eyrolles, 2005
McGraw-Hill Inc., oct.
2007
Ed. Sylvi, Bucureti, 2010
Masson, Paris, 2011
Addison Wesley, third
edition, 2012
Ed. Addison Wesley, 2009
Prentice Hall, fourth
editions, 2012

15. Davidescu N.,

Proiectarea sistemelor informatice

financiar-bancare, vol. I+II

16. Diatcu E. .a.

Elemente fundamentale ale teoriei

sistemelor i calculatoarelor
17. Evans N.D., Miller Programming Microsoft Visual
K., Spencer K.
InterDev 6.0
18. Florescu V. .a.,
Baze de date
19. Flynn D.,
20. Fril, L
21. Gamache A.,
22. Gherasim Z
23. Grama A. .a.

Information Systems Requirements:

Determinations & Analysis
.Proiectarea sistemelor informatice
Modeles, Architectures, Langages de
donnees
Programarea si Baze de date

25. Ionescu A.

Medii de programare- metode i

instrumente de dezvoltare a
aplicaiilor economice
Sisteme informatice pentru
managementul firmei
Baze de date, curs universitar

26. Lowe D.

Tehnologia ClientlServer pentru toi

27. Lungu l. .a.

Baze de date- organizare, proiectare

i implementare
Sisteme informatice i baze de date

24. Hurban C.

28. Lungu l,
Sabu Ghe.
29. Lungu I., s.a.
30. Munteanu A.,
Greavu V.
31. Floarea Nastase
(coord.), Razvan
Daniel Zota
(coord.), Carmen
Timofte, Radu
Constantinescu
32. S. Johnsons.

Ed. All Beck, Bucureti,

2011
Ed. Hyperion XXI,
Bucureti, 2009
Microsoft Press, 1999
Ed. Economic, Bucureti,
2009
McGraw-Hill, 2008
Editura InfoMega,
Bucureti, 2007
Ed. Griffon d'Argile,
Quebec, 2012
Ed. Fundaiei Romnia de
Mine, Bucureti,2007
Ed. Sedcom Libris, lai,
2008
Ed. Mirton, Timioara,
2001
Facultatea de Automatic i
Calculatoare, Craiova 2001.
Ed. Teora, Bucureti, 2006
Ed. ALL, Bucureti, 2011

Sisteme de baze de date evoluate

Ed. A.S.E., Bucureti,

2013
Ed. A.S.E, Bucureti, 2009

Reele locale de calculatoare

Ed. Polirom, Iai, 2004

Bazele tehnologiei informaiei

Ed. ASE Bucureti, 2013

Microsoft Windows7

Ed Niculescu,Bucureti,
2010

325

33. Nicolescu O .a.

Management

34. Nicolescu O.
(coordonator)
35. Nicolescu O. ,
Verboncu I.
36. Nicolescu O. ,
Ilies L.
37. OBrien J. A.,
38. Oprea D.

Sistemul informaional managerial al

organizaiei
Fundamentele managementului
organizaiei
Minidicionar de management
Sistemul Informaional
Introduction to Information Systems
Analiza i proiectarea sistemelor
informaionale economice
Sisteme informaionale pentru afaceri

39. Oprea D., Airinei

D., Fotache M.
40. Oprea D.,
Meni G.
41. Ora L., Ralph R.
Swick

Ed. Didactic i
Pedagogic, Bucureti,
1992
Ed. Economic, Bucureti,
2001
Ed. Universitaria, 2008
Ed. Pro Universitaria,
2011
8th Ed. Irwin, 2007
Ed. Polirom, lai, 1999
Ed. Polirom, Iai, 2002

Sisteme informaionale pentru

manageri
Resurce Description Framework
[RDF] Model and Syntax Specification

Ed. Polirom, Iai, 2002

42. Pun M.

Analiza sistemelor economice

Ed. ALL, Bucureti, 2007

43. Peter R. Sch.

The Leaders Handbook

New York 2008

44. Peterson L.,

Davie B.
45. Popescu I. .a.

Reele de calculatoare

Ed. All Educational,

Bucureti, 2008
Ed. MondoEc, Craiova,
2002
Ed. Economic, Bucureti,
2006
Ed. Economic, Bucureti,
2006

46. Radu l.
47. Roca I.,
pu N.,
(coordonatori)
48. Roca J.,
Macovei E.,
Davidescu N.,
Rileanu V.
49. Rotaru S.
50. Rotaru S., Ghi
M., Ghi t.
51. Rotaru S., Ghi
M., Ghi t.

Noua economie i societatea

informaional
Informatica managerial
Internet & Intranet- Concepte i
aplicaii

W3C, Recomandation,
2002

Proiectarea sistemelor informatice

financiar-contabile

Ed. Didactic i
Pedagogic, Bucureti,
2003

Sisteme informatice de gestiune

economica
Analiza si modelarea sistemelor
informatice
Proiectarea i implementarea
sistemelor informatice

Ed. Universitaria, Craiova,

2010
Ed. Sitech, Craiova, 2006

326

Ed. Sitech, Craiova, 2006

52. Rotaru S., Ghi

M.,
53. Rcu L, Rotaru S,
Ghita M, Ghita
St.
54. Saru D., loni A.
D.
55. Steve Lambert,
M. Dow Lambert
III, and Joan
Preppernau
56. Turban E.,
McLean E.,
Wetherbe J.
57. Velicanu Manole
.a.
58. Zaharie D.,
Roca l.
59. ***

Programarea n Access

60. ***

www.webopedia.com

61. ***

www.infoit.com

62. ***

www.intel.com

63. ***

www.isaca.org

64. ***

www.microsoft.com

65. ***

www.guill.net

66.

www.scritube.com

67.

http://www.theiia.org

68. ***

www.uqah.uquebec.ca

Baze de date S.G.B.D.Access 2002

Ed. Universitaria, Craiova,

2006
Ed. Universitaria, Craiova,
2005

Sisteme de programe orientate pe

obiecte
Microsoft Office Access 2007 Step
by Step

Ed. ALL Educational,

Bucureti, 2010
Technology Microsoft
Office Access 2007

Information Tehnology for

Management

John Willey Sous, 2011

Sisteme de gestiune a bazelor de date

prin exemple
Proiectarea obiectual a sistemelor
informatice,
www.datawarehousetraining.com/Methodologies

ASE, Bucureti, 2013

327

Ed. DuaITech, Bucureti,

2008