Embed Size (px)
Citation preview
ROTARU SIMONA GHIȚĂ MIRELA CLAUDIA
SISTEME ȘI APLICAȚII
INFORMATICE ÎN ECONOMIE
Editura Revers Craiova 2015
2
Corectura aparține autoarelor
© Editura REVERS Craiova
Toate drepturile asupra acestei ediţii sunt rezervate autoarelor. Orice
reproducere integrală sau parţială, prin orice procedeu, a unor pagini din
această lucrare, efectuate fără autorizaţia editorului este ilicită şi
constituie o contrafacere. Sunt acceptate reproduceri strict rezervate
utilizării sau citării justificate de interes ştiinţific, cu specificarea
respectivei citări.
© 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 Naţionale a României
ROTARU, SIMONA; GHIȚĂ, MIRELA CLAUDIA
Sisteme și aplicații 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
3
Cuprins
Capitolul 1
Noțiuni generale despre sistemele informatice .................................................................. 7
1.1 Concepte de bază ale sistemelor informatice .......................................................... 7
1.2 Reprezentarea sistemică a unei organizații ........................................................... 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 soluţionat şi determinarea cerinţelor sistemului ....... 50
3.2 Structurarea cerinţelor 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 întreţinerea 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 performanţelor sistemului informatic proiectat ........................... 141
4
5.1.4 Elaborarea documentaţiei de utilizare a sistemului informatic proiectat. ...... 142
5.2 Exploatarea şi întreţinerea sistemului informatic ................................................. 143
5.2.1 Exploatarea sistemului informatic ..................................................................... 143
5.2.2 Procesul de întreţinere a sistemelor informatice ............................................... 144
5.2.3 Documentaţia necesară exploatării şi întreţinerii sistemului informatic ........ 146
Capitolul 6
Aplicațiile sistemelor informatice .................................................................................... 151
6.1 Selecția 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/funcţii ........................................................................................... 168
6.3. Structuri de control fundamentale în VBA........................................................... 175
6.3.1Tipuri de structuri de control .......................................................................... 176
6.3.2 Instrucţiuni pentru implementarea structurii alternative ................................ 178
6.3.3 Instrucţiuni pentru implementarea structurii repetitive .................................. 181
6.4 SQL pentru ACCESS .......................................................................................... 184
6.4.2 Limbajul de manipulare a bazei de date (SQL–LMD) .................................. 193
6.4.3 VEDERI ........................................................................................................ 202
Capitolul 7
Utilizarea SGBD Access în proiectarea aplicațiilor informatice ...................................... 208
7.1 Colecţii 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
5
7.1.5 Obiecte de tip Macro .................................................................................... 235
7.2 Dezvoltarea rapidă a unei aplicaţii ....................................................................... 238
7.3.2. Ataşarea tabelelor în aplicaţii ...................................................................... 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 Particularităţile procesului de audit al sistemului informatic ................................. 261
8.1.1 Operaţii specifice auditării sistemelor informatice ........................................ 261
8.1.2 Etapele auditării ........................................................................................... 267
8.1.3 Probleme de audit asociate cu utilizarea sistemelor informatice .................. 272
8.2 Analiza riscului auditării sistemelor informatice ................................................... 274
8.2.1 Riscurile asociate sistemelor informaționale ................................................ 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
6
7
Capitolul 1
Noțiuni generale despre sistemele informatice
Obiective:
Însușirea noțiunilor de bază legate de abordarea sistemică a unei organizații
Cunoașterea principaleleor elemente ale unui sistem informatic
Stabilirea locului și rolului unui sistem informatic într-o organizație
Cuvinte cheie: sistem informațional, sistem informatic, sistem informatic integrat, viziune
sistemică, resursele sistemului informatic.
1.1 Concepte de bază ale sistemelor informatice
Conceptul de bază al analizei şi proiectării sistemelor îl constituie noţiunea de sistem. Acest
concept este folosit în mod frecvent în diferite domenii de activitate existând astfel: sisteme de
afaceri, sisteme politice, sisteme informatice, sisteme de producţie, sisteme biologice, sisteme
educaţionale etc. Toate aceste sisteme au în comun faptul că sunt alcătuite dintr-un număr de
elemente ce interacţionează atât între ele cât şi cu mediul înconjurător în vederea realizării unui
obiectiv.
Noţiunea de sistem este una foarte generală, cuprinzătoare, practic, în orice domeniu de
activitate se are de a face, într-o formă sau alta, cu sisteme.
Conceptul de sistem a apărut într-o formă embrionară în filozofia antică greacă
afirmând că “întregul este mai mult decât suma părţilor componente”, Aristotel a dat o primă
definiţie a noţiunii de sistem.
Noţiunea de sistem are un caracter relativ, în sensul că orice sistem poate fi
descompus în subsisteme şi la rândul său, poate fi privit ca un subsistem al unui sistem mai
complex.
Astfel de exemplu, o întreprindere poate fi descompusă în sisteme (secţii, ateliere, locuri de
muncă) şi la rândul ei, întreprinderea poate fi privită ca un subsistem al unei ramuri, sau al
economiei naţionale. 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 funcţie de resursele existente. după care sunt
8
reintegrate într-un nou sistem mai performant, a cărui reproiectare constituie obiectivul principal
al analizei şi proiectării sistemelor.
Prima definiţie riguroasă a conceptului de sistem aparţine fondatorului teoriei generale
a sistemelor (TGS), Ludwing von Berthalanffy1, care considera că „sistemul este o mulţime de
elemente intre care există relaţii sau raporturi neîntâmplătoare care interacţionează în vederea
realizării unui obiectiv comun, care poate fi o lege a naturii sau un obiectiv stabilit de către 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 ştiinţifice.
Conform autorului teoria permite aplicarea aceloraşi principii, legi şi modele pentru toate tipurile
de sisteme, atât pentru cele fizico-naturale cât ş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 condiţii ca subsistem, fapt
ce evidenţiază 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 funcţionare
bine definite, în vederea îndepliniri unui anumit scop. Orice sistem este caracterizat prin aceea
că este legat de mediul ambiant. Are o anumită structură, funcţionează după anumite reguli şi
urmăreşte un anumit scop. Datele se găsesc într-o circulaţie permanentă intre oameni care
transmit informaţii şi cei care le primesc. Acest drum se numeşte flux informaţional. În ceea ce
priveşte scopul sau obiectivul sistemului, acesta trebuie văzut ca raţiunea pentru care a fost
construit sistemul, motivul pentru care au fost grupate elementele respective.
Un sistem, în absenţa obiectivului său, reprezintă numai o mulţime de elemente
interconectate. La rândul ei o mulţime de elemente neconectate nu va avea nici o semnificaţie
pentru analiza şi proiectarea sistemelor.
Elementele unui sistem sunt entităţi de tipuri şi caracteristici diferite, cum ar fi oameni
echipamente. Procese de producţie, tehnologii, organizare etc. implicate într-o mulţime de
activităţi specifice sistemului. Entitatea este un element de abstractizare a realităţii caracterizat
prin atributele care o descriu şi o definesc funcţional. Elementele sistemului pot fi ele însele
considerate ca sisteme în sensul definirii acestui concept.
1 Biolog şi filozof al ştiinţei, inovator al biologiei teoretice, fondator al TGS. American - 1901/1973
9
Sistemul alcătuit din unul sau mai multe elemente îl putem considera ca subsistem al
unui sistem mai complex (hipersistem/suprasistem). Apare astfel, problema existenţei ş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 celălalt 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ă răspunsul la cele două probleme este negativ, şi că numai în mod
abstract, imaginativ, din necesităţi practice de cercetare, vom considera existenţa acestor cazuri
- limită de sisteme.
Relaţiile dintre elemente includ şi comunicaţiile dintre ele şi limitează comportamentul acestora
în cadrul sistemului. În acest sens, sistemul trebuie izolat pentru a pune în evidenţă restricţiile
care există, care acţionează şi influenţează comportamentul elementelor din sistem. În
descrierea unui sistem se vor evidenţia totdeauna elementele componente, relaţiile dintre
acestea şi scopul sistemului.
Conexiunea sistemului cu mediul său este reliefată de mulţimea elementelor care
alcătuiesc vectorul de intrare (input-uri) şi vectorul de ieşire (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 schimbări permanente în cadrul ciclului de viaţă, care pun
în evidență conceptul de sistem dinamic. Această caracteristică provine din influenţa
schimbărilor asupra interacţiunilor dintre elementele componente şi a conexiunilor dintre sistem
şi mediu, în vederea atingerii obiectivelor sistemului.
Sistemul interacţionează cu mediul său, care este format din elemente ce nu fac parte
din sistem, dar care ii pot influenţa. Distincţia dintre sistem şi mediu este realizată de conceptul
de graniţă/frontieră, care la rândul ei poate fi considerată un sistem format dintr-o mulţime de
elemente al căror comportament este exclusiv determinat atât de obiectivele sistemului cât şi de
comportamentul unor elemente vecine din mediu sau din interiorul sistemului.
În timp ce graniţa 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 influenţe din afara sistemului. atunci acel aspect este în afara graniţelor sistemului.
În terminologia sistemică, tot ceea ce este în afara graniţelor sistemului, dar care îl
poate influenta, constituie mediul sistemului.
Cunoaşterea mediului ambiant, a factorilor de influenţă ai mediului asupra firmei, a
interdependenţelor dintre aceştia şi firmă, are o importanţă deosebită pentru atingerea
obiectivelor, în contextul mutaţiilor economice survenite în mediul firmelor, în procesul tranziţiei
10
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, concretizaţi în principal prin piaţa internă, piaţa externă şi pârghiile
economico-financiare. Studiul pieţei furnizează informaţii relevante despre nivelul şi structura
cererii. nivelul preţurilor, concurente etc. pe baza cărora conducerea firmei îşi poate fundamenta
deciziile referitoare la aprovizionare, producţie şi desfacere, precum şi unele aspecte ale
strategiei generale.
În cadrul pârghiilor economico - financiare, cointeresarea materială are un rol important
şi se realizează în principal prin intermediul sistemului de salarizare şi a profitului, firmele fiind
condiţionate să se încadreze în anumite limite cantitative controlate de instituţiile bancare şi
trebuind să respecte anumite modalităţi de repartizare a profitului.
Din categoria factorilor de management exogeni care influenţează funcţionalitatea şi
eficienţa firmei, fac parte mecanismul de planificare macroeconomică, sistemul de organizare a
economiei, modalităţile de coordonare, mecanismele motivaţionale şi de control, calitatea
metodelor şi tehnicilor manageriale etc.
Planificarea macroeconomică are un pronunţat caracter orientativ, de previziune şi
corectare a unor eventuale disproporţii, numărul de indicatori şi balanţe reducându-se
substanţial fată de cel necesar în economia centralizată, ceea ce conduce la creşterea
competiţiei intre firme într-un mediu dinamic care devine din ce în ce mai concurenţial.
Sistemul de organizare, prin volumul şi structura atribuţiilor, a deciziilor adoptate şi a
responsabilităţilor, precum şi prin numărul relativ mare al verigilor ierarhice superioare
întreprinderii. se poate constitui într-un factor blocant în calea descentralizării 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 fabricaţie şi a produselor, cu implicaţii
sensibile în managementul întreprinderii.
Importanţa factorilor demografici este justificată de poziţia prioritară pe care o au
resursele umane, de calitatea şi competenţa lor, depinzând calitatea şi succesul activităţilor
desfăşurate de întreprindere.
Dintre factorii socio-culturali, un rol decisiv îl are învăţământul, care trebuie să
contribuie atât la îmbunătăţirea structurii socio-profesionale cât şi la formarea unei mentalităţi
specifice economiei de piaţă.
11
Managementul microeconomic este de asemenea, influenţat de factorii politici, prin impactul
acestora asupra fundamentării strategiilor şi politicilor firmelor precum şi asupra deciziilor de
realizare a obiectivelor stabilite.
În condiţiile accentuării crizei de materii prime şi de resurse energetice are loc o diversificare şi o
creştere a complexităţii interdependentelor dintre factorii naturali (ecologici) şi unităţile
economice, fapt ce necesită un efort deosebit şi utilizarea unor tehnici moderne de investigare şi
de analiză pentru cunoaşterea şi valorificarea acestor interdependenţe de către managementul
microeconomic.
Cunoaşterea în detaliu de către organismele de conducere a firmelor, a caracteristicilor şi a
mutaţiilor survenite în mediul ambiant este necesară, dacă se au în vedere cel puţin următoarele
aspecte:
●analiza evoluţiei mediului, reprezintă o condiţie fundamentală a satisfaceri unor nevoi
sociale de către o unitate economică, şi în acelaşi timp, o condiţie necesară de supravieţuire şi
de dezvoltare a acesteia, prin elaborarea de strategii şi politici fundamentate ştiinţific prin
valorificarea conexiunilor cu factorii din mediu;
●analiza factorilor din mediul specific unităţii economice, permite asigurarea cu resursele
necesare în vederea funcţionării şi dezvoltării eficiente a acesteia;
●cunoaşterea evoluţiei factorilor din mediu, constituie o premisă de bază pentru
conceperea şi funcţionarea eficientă a unor subsisteme organizatorice şi informaţional
decizionale care să satisfacă necesităţile şi oportunităţile prezente şi de perspectivă ale
mediului.
Mediul unui sistem cuprinde toate elementele aflate în afara graniţelor sale, dar care au
influenţe directe sau indirecte în stabilirea obiectivelor, obţinerea resurselor necesare, adoptarea
şi aplicarea deciziilor etc., menite să favorizeze sau să perturbe desfăşurarea normală a
activităţilor sistemului considerat.
De exemplu mediul unei firme productive este format din piaţă, bănci, instituţii guvernamentale, alte firme, etc., cu care aceasta se află în relaţii economico-financiare(Figura 1.1).
12
Piaţă Instituţii
Guvernamentale
Alte firme Bănci
Fig. 1.1 Mediul unei firme În funcţie de probabilitatea producerii evenimentelor putem considera:
medii deterministe (certe), în care probabilitatea producerii evenimentelor poate fi
maxima (evenimente certe),
medii cu perturbaţii (riscante), în care probabilitatea de realizare a evenimentelor sunt
cunoscute;
medii turbulente (incerte), în care probabilităţile de realizare a evenimentelor sunt
necunoscute.
Majoritatea sistemelor economice reale au medii nedeterministe în care evenimentele se
produc cu probabilităţi 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 câtorva 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 dobânzi practicate de bănci, legile şi actele normative
existente în vigoare etc., rezultă în mod elocvent caracterul incert al mediului considerat.
În mediile supuse perturbărilor, sistemele îşi vor defini strategiile prin evaluarea
posibilităţilor de acţiune (alternativelor) pe bază de observaţii şi analize complexe.
În cadrul sistemului decizional, apare necesitatea estimării probabilităţilor pentru fiecare stare a
naturii şi a probabilităţilor de realizare a evenimentelor, precum şi a adoptări unor decizii în
condiţii 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ă;
evidenţierea stărilor naturii şi a probabilităţilor aferente;
Sistem
(firmă)
13
stabilirea strategiilor de acţiune, conform unor criterii (economice, tehnice, sociale,
ecologice) independente ca sens şi cauzalitate, specifice sistemului;
evidenţierea consecinţelor rezultate prin alegerea unei strategii din punct de vedere al
unui criteriu şi în condiţiile realizării unei anumite stări ale naturii;
stabilirea obiectivelor ca nivele ale consecinţelor ce se urmăresc a fi realizate din punct
de vedere al fiecărui criteriu în parte.
Sistemul îşi dezvoltă acele elemente capabile să acumuleze informaţii referitoare la natura
mediului. Printr-un proces continuu de învăţare, are loc adaptarea sistemului la mediul său.
Monitorizarea mediului devine astfel una din atribuţiile 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 cărora ele vor contribui, iar pe de altă parte, de legăturile sistemului cu mediul său.
Studierea mediului ambiant şi a multiplelor conexiuni dintre mediu şi unitatea economică,
facilitează cunoaşterea dependenţelor complexe existente între acestea, a
influenţelor/impactului mediului asupra eficienţei economico-sociale a unităţii 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 organizații
În cadrul lucrării de față prin organizație se va referi o întreprindere, instituție, societate
comercială.
În condiţiile societăţii informatizate o organizație nu poate supravieţui fără să dispună de
informaţii în timp real, atât din interior, cât şi din exteriorul său. Sarcina de colectare, prelucrare,
stocare şi furnizare ale informaţiilor şi cunoştinţelor revine sistemului informaţional al unei
întreprinderi. Drept urmare, din punct de vedere informaţional, o întreprindere modernă trebuie
să fie cuplată la cele mai moderne tehnologi informaţionale şi de comunicare ale momentului la
care ne raportăm.
În orice organizaţie un loc central în ansamblul operaţiunilor pe care le generează îl
ocupă prelucrările informaţionale. 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
informaţiilor după o anumită specificaţie. În noile condiţii, toate organizaţiile dispun de sisteme
informaţionale proprii, cu sau fără sisteme informatice foarte dezvoltate, care au ca scop operaţii
de colectare, prelucrare, depozitare şi transmitere ale datelor şi informaţiilor.
14
Prin sistem informaţional înţelegem ansamblul de resurse materiale şi financiare care
utilizează tehnologiile informaţionale pentru a culege, prelucra, stoca, regăsi, transmite şi
vizualiza informaţiile utilizate în procesele ce au loc în perimetrul unei întreprinderi.
În condiţiile în care ne referim la procesele economice care au loc într-o întreprindere,
atunci vom avea sisteme informaţionale economice.
Este cunoscut faptul că la baza unui sistem informaţional modern stă sistemul informatic ca
parte componentă esenţială şi cu o pondere în continuă creştere.
Sistemul informatic este definit de literatura de specialitate ca reprezentând un
ansamblu de metode, procedee, echipamente şi personal de specialitate, care asigură
culegerea, verificarea, transmiterea, stocarea şi prelucrarea informaţiilor destinate altor
subsisteme şi în special conducerii pentru luarea de decizii în timp util.
Atunci când se descrie un sistem informaţional se ţine cont de structura sa, adică de un
ansamblu de funcţii şi finalităţi şi de evoluţia acestuia în interacţiunea cu mediul.
Structura unui sistem informaţional presupune existenţa unei baze materiale (de cele mai multe
ori echipamente electronice, conectică şi consumabilele aferente), a unor proceduri/aplicaţii
specializate şi a unui personal specializat.
Funcţiile sistemului informaţional sunt analizate prin prisma activităţilor derulate prin crearea,
depozitarea, tratarea datelor şi transmiterea informaţiilor.
Finalitatea unui sistem de informare constă în faptul că membrii unei organizaţii sunt ajutaţi în
realizarea şi evaluarea sarcinilor lor. Cu alte cuvinte, se obţin informaţii care sunt necesare
pentru realizarea activităţilor operaţionale şi pentru gestiunea eficientă a resurselor.
O organizaţie se defineşte ca o formă structurată socială stabilă care ia resurse din
mediu şi le transformă în vederea obţinerii produselor sau serviciilor. Din punct de vedere
comportamental, organizaţia se defineşte ca fiind o colecţie de drepturi, de privilegii, de obligaţii
şi responsabilităţi, care sunt uşor echilibrate în timp prin conflicte şi rezolvarea acestora. Din
punct de vedere tehnic, organizaţia se prezintă sub forma unui sistem cu intrări, cu ieşiri, cu
prelucrări şi cu buclă de autoreglare.
Din punct de vedere organizaţional, o întreprindere poate fi structurată după una din
următoarele logici: ierarhic-piramidală, ierarhic-funcţională, funcţională, pe centre de venituri,
geografic, matricială, în reţea şi conglomerat. În ultimul timp, dintre toate acestea capătă o
importanţă deosebită modelul de organizare în reţea, datorită gradului mare de flexibilitate pe
care îl prezintă o asemenea organizaţie.
Altfel spus, un sistem informaţional este definit ca o combinaţie organizată de oameni,
echipamente, programe, reţele de comunicaţii şi resurse de date care colectează, transformă şi
distribuie informaţii într-o organizaţie.
15
Aşadar, putem considera ansamblul activităţilor din cadrul unei întreprinderi ca fiind
rezultatul acţiunii conjugate a trei subsisteme (pe care pentru simplificare le vom numi sisteme,
interschimbabilitatea noţiunilor fiind admisă):
● sistemul de conducere (de management sau decizional), ce are rolul de a conduce
activităţile ce se desfăşoară în cadrul întreprinderii pentru realizarea obiectivelor
stabilite, constituind regulatorul întregului sistem;
● sistemul operaţional (condus sau de execuţie), ce are menirea de a executa
operaţiunile din cadrul activităţii declanşate ca urmare a unei decizii, folosind resursele
stabilite conform obiectivelor;
● sistemul informaţional (de legătură), ce asigură legătura în ambele sensuri între cele
două sisteme
Organizaţiile pot fi considerate ca un sistem ce tratează fluxuri de materiale şi fluxuri
informaţionale în vederea atingerii obiectivelor impuse de obiectul de activitate. Totuşi, la rândul
său, acest sistem se poate descompune într-un anumit număr de subsisteme, fiecare având
drept scop să asigure un ansamblu de operaţii necesare pentru funcţionarea la nivel global a
organizaţiei. În cadrul fiecărui subsistem se pot identifica principalele subsisteme de informare
pe care acestea le implică, dar care reunite (privite în ansamblul lor) formează sistemul
informaţional al întreprinderii.(Figura 1.2).
Fig 1.2 Sistemul organizaţional
Sistem decizional
Sistem informaţional
Resurse economice
oameni
bani
materiale
utilaje
energie
Procese organizaţionale
realizare de produse şi
servicii marketing
desfacere alte procese
Produse şi servicii
produse
servicii
plăţi
informaţii
alte
rezultate
comunicare
feed-back
comunicare
control
16
Sistemul informaţional oferă elemente pentru cunoaşterea modului de desfăşurare a
fenomenelor şi proceselor de natură economică şi socială dintr-o organizaţie. Atunci când apare
o problemă care trebuie rezolvată, în domeniul producţiei, al vânzărilor, al personalului, sistemul
informaţional ajută la evaluarea situaţiei existente, la depistarea cauzelor care o provoacă. El
reprezintă un sprijin pentru managerii de la orice nivel ierarhic şi asigură o intervenţie operativă
şi competentă în organizarea şi dirijarea activităţilor, o exercitare corespunzătoare a controlului
aplicării deciziilor luate.
Un sistem informaţional modern trebuie să asigure:
● informarea la toate nivelele;
● operativitatea informării;
● selectarea informaţiilor;
● adaptabilitatea la modificări (modificarea cererilor de informaţii, modificarea datelor de
intrare, modificarea structurii organizatorice, modificarea metodelor de prelucrare a datelor);
● precizia şi exactitatea informaţiilor.
Sistemul informatic preia şi dezvoltă o parte din baza informaţională şi operaţiile de prelucrare
ale sistemului unităţii economice, putând fi privit din acest punct de vedere ca un subsistem
informaţional automatizat. Raportul dintre sistemul informaţional şi cel informatic fiind de întreg-
parte (Figura 1.3).
SISTEMUL DE MANAGEMENT
SISTEMUL OPERAŢIONAL
SIS
TE
MU
L
INF
OR
MA
ŢIO
NA
L
SISTEMUL
INFORMATIC
Fig. 1.3 Locul sistemului informatic în raport cu sistemul informaţional
17
Obiectivele principale ale sistemelor informatice economice constau în:
● creşterea operativităţii în informarea conducerii şi luarea deciziilor la toate nivelurile;
● creşterea eficienţei economice în toate domeniile de activitate.
reducerea volumului documentelor şi corespondenţei scrise
● utilizarea eficientă a personalului cu înaltă calificare prin eliberarea sa de activităţile de
rutină;
Sistemul informatic asigură memorarea şi prelucrarea automata a unei părţi a informaţiilor dintr-
o unitate economică, pentru a asigura următoarele cerinţe:
● asigurarea, simplificarea şi ameliorarea lucrărilor şi procedurilor informaţionale care
presupun simpla execuţie a unor operaţii şi prelucrări de rutină;
● asistarea şi sprijinirea procesului de conducere, şi în mod deosebit a procesului
decizional;
Având în vedere că decizia aparţine 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
informaţii. De asemenea, sistemul informatic poate servi ca instrument de simulare, permiţând
evaluarea rapidă a consecinţelor previzibile ale fiecărei decizii şi adoptarea celei mai eficiente.
Informatizarea poate cuprinde, în mod obiectiv, numai acele părţi din sistemul informaţional care
sunt formalizabile prin definirea unor funcţii de transformare a intrărilor în ieşiri.
Cercetările din domeniul modelării matematice a proceselor economice, cat şi cele din domeniul
inteligentei artificiale conduc la lărgirea continuă a ariei de utilizare a informaticii în cadrul
unităţilor economice.
Utilizarea calculatorului pentru rezolvarea unui grup omogen de lucrări sau probleme ale unităţii
beneficiare constituie o aplicaţie informatică cu menţiunea ca un sistem informatic poate
cuprinde una sau mai multe aplicaţii informatice. Aria unei aplicaţii informatice este determinată
de omogenitatea funcţională a prelucrărilor realizate şi de delimitarea dintre procesele
formalizabile şi cele neformalizabile.
În cadrul unui sistem informatic pot exista mai multe aplicaţii care folosesc aceleaşi informaţii
sau informaţii generate de alte aplicaţii. În asemenea situaţii, pentru a evita introducerea
repetată a informaţiilor comune, se apelează la integrarea sistemului.
Un sistem informatic integrat asigură preluarea unică a fiecărei informaţii şi difuzarea acestora
tuturor aplicaţiilor care o solicită.
Integrarea sistemelor informatice se poate realiza pe următoarele căi:
● memorarea fiecărei informaţii. astfel încât să corespundă integral tuturor cerinţelor
specifice ale aplicaţiilor şi să fie disponibilă pentru fiecare dintre ele;
18
● transmiterea informaţiilor între aplicaţii sub forma fişierelor de interfaţă prin care se
asigură joncţiunea dintre aplicaţii;
Integrarea poate fi realizată la nivelul unui sistem informatic specific unei unităţi economice, sau
între sisteme informatice aparţinând unor unităţi intre care există relaţii de subordonare-
coordonare şi care pot fi dispersate teritorial (de exemplu o sucursală cu filialele sale se găseşte
în relaţii de subordonare – coordonare ).
Din punct de vedere fizic integrarea poate fi realizată prin intermediul unei reţele de
calculatoare, să asigure distribuirea colecţiilor de date memorate între unităţile economice ce se
află în relaţii de subordonare, în vederea furnizării necesarului de informaţii pentru fiecare dintre
acestea.
În aceste condiţii, 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 activităţilor, un sistem informatic poate fi reprezentat prin triada:
intrări – prelucrări – ieşiri (Figura 1.4).
Feed - back
Fig. 1.4 Structura unui sistem informatic
Prelucrări▪
hardware
software
resurse
umane
▪ stocare
Intrări
date
informaţii
operaţiuni
Ieşiri▪
lista/raport▪
grafice▪
indicatori▪ alte
ieşiri
Control▪
analize▪ decizii
19
Din reprezentarea grafică se observă componentele de bază ale oricărui sistem
informatic, şi anume: resursele umane, resursele hardware, resursele software, resursele de
date şi resursele de reţele.
În tabelul 1.1 este prezentată o sinteză pe care am realizat-o cu privire la resursele sistemului
informatic şi produsele informaţionale.
Tabelul 1.1
Resurse umane
Specialişti – analişti 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 hârtie.
Resurse software
Programe – sisteme de operare, aplicaţii pentru procesarea textelor, calcul tabelar, prezentare, pachete de aplicaţii pentru gestiunea clienţilor, salariilor. Proceduri – proceduri pentru introducerea datelor, de corectare a erorilor.
Resurse de date
Descrieri ale produselor. Înregistrări privind clienţii. Fişe ale angajaţilor. Baze de date cu stocurile, partenerii firmei etc.
Resurse de reţele
Medii de comunicaţii – cabluri UTP, coaxiale sau din fibră optică, sisteme cu microunde, sisteme de comunicaţii prin satelit. Suport de reţea – procesoare de comunicaţii (modem, router, server, hub), software de control şi de acces la reţea (sisteme de operare de reţea, navigatoare Internet).
Produse informaţionale Rapoarte pentru management, documente şi situaţii cuprinzând text, grafice. Elemente audio şi video.
Tabelul 1.1 Resursele sistemului informatic şi produsele informaţionale.
20
Resursele hardware cuprind totalitatea mijloacelor tehnice de culegere, transmitere,
stocare şi prelucrare a datelor.
Resursele software includ totalitatea programelor pentru funcţionarea sistemului
informatic, în concordanţă cu funcţiunile şi obiectivele ce i-au fost stabilite. Se au în vedere atât
programele de bază (SOFTWARE-ul de sistem), cât ş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 prelucrării, fluxurile informatice, sistemele şi
nomenclatoarele de coduri. Principalele structuri ale acestuia sunt bazele de date ce se
regăsesc sub forma colecţiilor de fişiere, tabele şi alte depozite de date, precum şi relaţiile dintre
acestea.
Resursele de reţele se referă la totalitatea echipamentelor şi tehnologiilor de
comunicaţie a datelor între sisteme.
Analizând aceste componente, putem spune că performanţele unui sistem informatic se pot
aprecia în principal, pe baza următoarelor cerinţe:
● să fie o colecţie de date corect proiectată şi implementată;
● să conţină programe aplicative de transformare a datelor în informaţii;
● să ofere informaţii centralizate pentru managementul producţiei.
1.4 Clasificarea sistemelor informatice
Este evident că într-o organizaţie, şi în general în organizaţiile mari, funcţionează în
paralel şi în interdependenţa mai multe subsisteme informaţionale în funcţie de activităţile ce se
desfăşoară în întreprindere, de angajaţii care participă la aceste activităţi, de compartimentele
funcţionale implicate.
Din cauza interdependenţei acestor subsisteme, este dificil ca ele să fie delimitate,
mărimea şi structura lor fiind diferite de la întreprindere la întreprindere. Mulţi autori au încercat
totuşi să stabilească diverse tipuri de sisteme informaţionale însă părerile acestora diferă.
James A. Senn a făcut o astfel de determinare în lucrarea sa Informating Sistems în
Management şi a stabilit că există patru tipuri de sisteme informaţionale:
Sistemul de procesare a tranzacţiilor care presupune prelu-crarea datelor
referitoare la tranzacţii. Operaţiile la care sunt supuse aceste date sunt înregistrarea,
clasificarea, sortarea, calculaţia, totalizarea, stocarea şi listarea rezultatelor;
Sistemul informaţional pentru management (sistemul rapoartelor
manageriale) furnizează informaţii pentru fundamentarea deciziei unde informaţiile necesare pot
fi identificate în avans. Deciziile fundamentate prin acest sistem se repetă frecvent;
21
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 luaţi în considerare şi ce informaţie este
necesară;
Sistemul informaţional al de birou (office sistem) care combină procesarea
datelor, telecomunicaţii şi procesarea pe calculator a informaţiilor de birou redactate manual. În
general acest sistem informaţional este o reproducere în miniatură a sistemului informaţional de
la nivelul organizaţiei.
Un alt criteriu de clasificare al sistemelor informatice este în funcţie de nivelul ierarhic
ocupat de sistemul economic în structura organizatorică a organizaţiei:
Sisteme informatice pentru conducerea activităţii la nivelul organizaţiilor
economice. Acestea pot fi descompuse în subsisteme informatice asociate funcţiunilor
organizaţiilor economico-sociale sau chiar unor activităţi.
Sisteme informatice pentru conducerea activităţii la nivelul organizaţiilor
economico-sociale cu structură de grup. Sunt incluse sistemele informatice la nivelul regiilor
autonome.
Sisteme informatice teritoriale. Sunt constituite la nivelul unităţilor
administrativ-teritoriale şi servesc la fundamentarea deciziilor adoptate de către organele locale
de conducere.
Sisteme informatice pentru conducerea ramurilor, subramurilor şi
activităţilor la nivelul economiei naţionale. Se constituie la nivelul ramurilor, subramurilor şi
activităţilor individualizate în virtutea diviziunii sociale a muncii şi specificate în clasificarea
ramurilor economiei naţionale.
Clasificarea sistemelor informatice după scopul urmărit:
Automatizarea activităţilor de rutină;
Sprijinirea proceselor de comunicare;
Sprijinirea procesului decizional;
Sprijinirea top-managerilor;
Clasificarea sistemelor informatice după elementul supus analizei:
Sisteme informaţionale orientate spre funcţii;
Sisteme informaţionale orientate spre procese;
Sisteme informaţionale orientate spre date;
22
Sisteme informaţionale orientate spre obiecte;
Sisteme informaţionale orientate spre mesaje /comunicări;
Sisteme informaţionale orientate spre informaţii ştiinţifice.
Clasificarea sistemelor informatice după modul de organizare a datelor:
Sisteme bazate pe fişiere clasice;
Sisteme bazate pe tehnica bazelor de date: ierarhice, reţea, relaţional,
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 cunoștințelor
1. Structura de ansamblu a unui sistem informatic e formată din triada:
a. reprezentare –afişare - tipărire
b. introducere, memorare şi afişare date
c. adunare – scădere şi înmulţire date
d. intrări– prelucrări- ieşiri
e. prelucrare, calcule şi stocare
23
2. Relaţia existentă între sistemul informaţional şi sistemul decizional, precum şi legătura
stabilită între sistemul informaţional ş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 informaţional :
a. se defineşte ca fiind un ansamblu de procedee şi mijloace de colectare, prelucrare şi
transmitere a informaţiei necesare procesului de conducere
b. a adus o varietate de procedee pentru obţinerea şi prelucrarea datelor, în vederea
utilizării lor în gestionarea unei unităţi economice
c. asigură simularea lipsei evoluţiei diverşilor indicatori sub acţiunea factorilor de
influenţă
d. elimină concurenţa 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 execuţia şi
renunţă la utilizarea licenţei, sau când a fost depăşit 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, obţinerea de informaţii.
Sistemul informatic lărgeşte câmpul de acţiune al sistemului informaţional, îi
potentează valenţele, îmbunătăţindu-l sub aspect calitativ
24
b. supus procesului de prelucrare, ce constă în sortare pe operaţii
c. o premisă importantă pentru organizarea raţională a sistemului de evidenţă economică
d. bine organizat în cadrul fiecărei unităţi, care să deţină toată legislaţia şi literatura de
specialitate actuală, sub forma unei biblioteci de specialitate
e. completază literatura de specialitate, prin explicaţii, exemple, inclusiv calcule şi
modalităţi de înregistrare-prelucrare
5. Sistemul informational economic:
a. observă şi înregistrează activităţile care se desfăşoară, existenţa şi mişcarea bunurilor
şi a relaţiilor, obtinând date de bază pe care le prelucrează, le transformă în informaţii,
le prezintă conducerii pentru luarea deciziilor, iar apoi, acestea sunt transmise
organismelor interesate, urmărind, în continuare, aducerea lor la îndeplinire
b. a adus o varietate de procedee pentru obţinerea şi prelucrarea datelor, în vederea
utilizării lor în gestionarea unei unităţi economice
c. asigură simularea lipsei evoluţiei diverşilor indicatori sub acţiunea factorilor de
influenţă
d. elimină concurenţa 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 execuţia şi
renunţă la utilizarea licentei, sau când a fost depăşit intervalul de timp alocat
25
Capitolul 2
Metodologii de realizare a sistemelor informatice
Obiective:
Cunoașterea metodologiilor de realizare a sistemelor informatice
Selectarea și integrarea metodelor de abordare a sistemelor informatice
Însușirea tehnicilor și metodelor de realizare a sistemelor informatice
Identificarea etapelor ciclului de viață a dezvoltării sistemelor informatice
Cuvinte cheie: ciclul de viață a dezvoltării 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 desfăşura decât 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 toţi realizatorii de sisteme informatice. Nu se pune în discuţie denumirea
etapelor sau succesiunea lor, ci modul de grupare a activităţilor 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 apărut şi
în funcție de modul concret de realizare a unui sistem informatic.
Un aspect comun pentru aceste etape şi activităţi 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
avizării de către factorii de răspundere ai beneficiarului a rezultatelor obţinute.
De asemenea, orice etapă, parcursă deja, se finalizează cu activităţi de pregătire a etapei
următoare, 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 decât
apelând 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:
26
activităţi 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 mulţime de concepte
fundamentale, reguli de notaţie, ce sunt utilizate împreună cu mulţimea 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, constatăm că o metodologie de realizare
a unui sistem informatic trebuie să cuprindă:
modul de abordare a sistemelor informatice;
modalităţi de derulare a ciclului de viata a sistemelor informatice;
metode şi tehnici de realizare a sistemelor informatice;
modalităţi de conducere a proiectului (planificare, organizare, urmărire).
2.1 Metode de abordare a sistemelor informatice
Metodele de abordare a sistemelor informatice s-au transformat şi evoluat în paralel cu
dezvoltarea tehnologiilor informaţionale, a sistemelor informaţionale şi a organizaţiilor.
Multitudinea metodelor de abordare, determinată de caracteristicile activităţilor necesare
realizării sistemelor informatice, au fost comentate (caracterizate) de mulţi autori de specialitate,
dar le vom descrie pe cele considerate mai edificatoare.
Autorii Yourdon şi Argila efectuează o trecere în revistă nu a metodelor, aşa 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ţă înţelegerii de către majoritatea
utilizatorilor calculatoarelor a programelor scrise în cod – maşină sau în “criptatele” limbaje de
asamblare, s-a ajuns la un important moment de progres: modularizarea programelor.
Din curentul “gândirii modulare” s-a desprins şcoala descompunerii funcţionale. De fapt,
autorii consideră că aceasta ar fi prima şcoală veritabilă de abordare a sistemelor, în fiecare
modul existând câte o funcţie.
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ă
27
proiectanţii aplicaţiilor în timp real aveau altă opinie, şi anume: “Fiecare modul trebuie să
recunoască şi să răspundă unui eveniment”.
Analizând şcolile prezentate, putem spune că ele sunt orientate spre funcţii, 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 funcţie 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 modalităţi
de abordare a analizelor, considerate ca instrumente ale gândirii utilizate pentru a ajuta la
formularea cerinţelor. Cele patru metode sunt orientate spre funcţii, procese, informaţii (date),
ultima fiind cea orientată obiect. Autorii fac menţiunea că nu se pune problema desfiinţării
metodelor vechi, ci a incorporării celor mai bune idei ale primelor trei metode în una mai
cuprinzătoare, atotcuprinzătoare – 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-ieşiri (sfârşitul anilor 1960);
metode orientate-proces, prin apelarea la diagramele fluxurilor de date, DFD (anii
1970);
metode orientate-date, prin folosirea diagramelor entitate-relaţie, DER (anii1980);
metode orientate-obiect (anii 1990).
D. Oprea, consideră că metodele ar putea fi grupate, prin prisma celor mai mulţi autori, astfel:
metode orientate spre funcţii, numite şi metode ale descompunerii funcţionale;
metode orientate spre fluxuri de date, deci spre procese, deoarece diagramele
fluxurilor de date se întrebuinţează pentru descrierea proceselor. Deseori, în formă lapidară,
aceste metode sunt denumite orientate - date.
metode orientate spre informaţii sau date, orientate-informaţii, probabil şi datorită
popularizării puternice a ingineriei informaţiei a lui James Martin, dar şi a diagramelor entitate -
relaţie ale lui Chen;
metode orientate-obiect.
2 Modern Structured Analysis, Editura: Pearson Education, 1996
28
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
activităţii pot avea caracteristici diferite care să necesite moduri diferite de abordare. Provocarea
constă în selecţia şi integrarea acestor metode’’. De fapt, referindu-se numai la metodele
orientate-obiect, Hoffer, George şi Valacich, în 1996, inventariau cel puţin 13 sisteme de notaţie,
deşi, î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, citând cercetarea lui Ian Graham, în 1997, spune că au fost identificate
probabil 60 de metode complet orientate - obiect. Comentariile sunt de prisos.
Caracteristicile esenţiale ale principalelor metode de abordare a sistemelor
După prezentarea principalelor opinii exprimate în literatura de specialitate cu privire la
evoluţia şi clasificarea metodelor de abordare a sistemelor informaţionale, vom face o scurtă
prezentare a principalelor abordări în dezvoltarea sistemelor informaţionale. În acest sens, vom
urma gruparea prezentată în finalul paragrafului anterior şi care se regăseşte de altfel, în mod
explicit sau implicit, în majoritatea opiniilor exprimate în literatura de specialitate.
Metoda descompunerii funcţionale (orientate-funcţii)
Dintre autorii remarcabili care au abordat descompunerea funcţională îi enumerăm pe
câţiva, cum ar fi DeMarco, Yourdon şi Constantine, Jackson, Page-Jones, Warnier-Orr, Dahl,
Marco & Mc Gowan.
Descompunerea funcţională este cea care anunţă apariţia proiectării structurate şi analizei
structurate. Ea a fost concepută cu scopul controlării complexităţii prin operaţiuni de tipul devide
et impera. Fiecare funcţie este descompusă în subfuncţii ş.a.m.d., până când se obţin forme
uşor de transpus în instrucţiunile limbajelor de programare.
Şi în cazul descompunerii funcţionale conceptele specifice au fost introduse mai întâi în
programarea structurată (Dahl, 1972) şi apoi în proiectare, urmată de analiză. Aceeaşi situaţie
este întâlnită şi în varianta orientării - obiect.
Descompunerea funcţională (DF) este văzută ca o sumă de funcţii, subfuncţii şi interfeţe
funcţionale, sub forma unei ecuaţii:
DF=Funcţii
+Subfuncţii
+Interfeţe funcţionale.
29
Printr-o astfel de reprezentare se ilustrează modul în care recunoaştem o descompunere
funcţională. Obiectul îl constituie prelucrările necesare în noul sistem. Analistul va specifica
prelucrările şi interfeţele funcţionale.
Metoda are ceva puncte tari:
simplitate - fiind o cale naturală de rezolvare a unei probleme;
obţinerea destul de lejeră a cerinţelor utilizatorului;
generarea de soluţii pe diferite niveluri de abstractizare (sistem,
subsistem, funcţie, subfuncţie).
Ca puncte slabe sunt descrise:
concentrarea eforturilor spre funcţii conduce la culegerea multor
date redundante;
inexistenţa unor reguli precise de descompunere;
evidenţierea anevoioasă a interacţiunilor non-ierarhice din sistemele complexe.
Disfuncţionalităţile metodei au fost mult anihilate prin soluţii ingenioase de tipul coeziunii şi
cuplării, introduse spre sfârşitul anilor ’80 de Page & Jones şi Yourdon/Constantine.
Metoda descompunerii funcţionale (orientate-funcţii)
O altă metodă şi în acelaşi timp o altă modalitate de reprezentare a domeniului problemei şi
responsabilităţilor sistemului printr-o specificaţie tehnică este metoda orientată spre procese,
deseori descrisă ca ,,analiza structurată‘’.
Ecuaţia metodei este:
Metoda fluxului de date = Fluxul (şi controlul) datelor
+ Transformările (şi controlul) datelor
+ Stocarea (şi controlul) datelor
+ Terminatori
+ Specificaţii de proces
+ Dicţionarul datelor.
Prin această metodă, analiştii efectuează reprezentarea lumii reale prin linii ale
fluxurilor în analiza structurată. Se vorbeşte despre o metodă ,,veche”, cu reprezentanţii 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
lucrările 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ă răspundă, o formă embrionară a actualelor interacţiuni dintre utilizator şi
sistem, bazate pe mesaje. De asemenea, printr-o documentaţie suplimentară, sunt incluse
30
fluxurile datelor şi transformărilor la nivel inferior prin intermediul dicţionarului de date, respectiv
al specificaţiilor proceselor.
Cum metoda orientată pe procese are încă un mare grad de asemănare cu
descompunerea funcţională, 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
către metodele orientate-obiect.
Metode orientate spre informaţii (orientate-date)
Două realizări remarcabile în domeniu au dat tonul unei noi orientări în abordarea
sistemelor: modelarea datelor cu ajutorul diagramelor entitate-relaţie, de către Peter P. Chen
(1976) şi ingineria informaţiei, în viziunea lui James Martin. Acestora li s-au adăugat alte reuşite
de esenţă.
Termenul ,,obiect’’ este lansat la mijlocul anilor ‘70 într-o formă ,,originală‘’, nestandard, dacă ne
gândim fie la semnificaţiile anterioare ale lui , fie la cele curente , firesc , din domeniul abordării
sistemelor. Aşa cum este el folosit de Chen , de cei ce se ocupă cu modelarea informaţiilor (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 ,,ocurenţe’’ (cazuri) ale
,,entităţilor” lumii reale.
Metoda este identificată prin următoarea ecuaţie:
Modelarea informaţiilor = Obiecte
+Atribute
+Relaţii
+Supertipuri/Subtipuri
+Obiecte asociative
Coad şi Yourdon spun că şi în acest caz se poate vorbi despre existenţa a două strategii.
Strategia veche se bazează pe conceperea listei atributelor gruparea lor în obiecte,
stabilirea de relaţii între ,,ocurenţe” (cazuri), folosirea supertipurilor/subtipurilor pentru
extragerea atributelor comune şi definirea obiectelor asociative pentru reliefarea relaţiilor sigure.
Noua strategie este destul de apropiată de precedenta, cu excepţia primului pas, care îşi
propune mai întâi să identifice obiectele lumii reale şi apoi urmează descrierea lor cu ajutorul
atributelor.
Specialiştii apreciază salturile înregistrate, însă , în acelaşi timp fac inventarul conceptelor
inexistente, cum ar fi: servicii,moştenire,structură.
31
Metode orientate-obiect
Întrucât acest subiect necesită multe descrieri preliminare, deocamdată nu vom face
decât o foarte sumară prezentare. Sintagma ,,orientat - obiect” este destul de greu de definit din
cauza accepţiunilor diferite ce i-au fost date de diversele discipline. Numai în domeniul
informaticii există vreo trei variante: una folosită în modelarea informaţiilor , alta în programare şi
a treia, cea de faţă, utilizată în analiza şi proiectarea sistemelor, de cele mai multe ori identică
semnificaţiei din programare. Fiind un domeniu relativ nou, este normal să existe o mare
diversitate de opinii până şi asupra termenului ,,obiect”.
Pentru a continua regula prezentării ecuaţiei ce caracterizează metoda, o vom reda în cele ce
urmează:
Orientat-Obiect = Clase şi Obiecte
+ Moştenire
+ Comunicaţii prin mesaje.
Conceptele de obiect şi clasă sunt independente: un obiect aparţine unei clase (este o instanţă
a clasei), iar o clasă este o grupare logică a obiectelor care au aceeaşi 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, referinţe la alte obiecte
sau valori care sunt structurate ele însele.
Comportamentul unui obiect este definit printr-un set de operaţiuni ce-i pot fi aplicate şi
este descris în clasa căreia îi aparţine obiectul.
În concluzie, obiectul este o abstractizare a datelor elementare, caracterizat printr-un
identificator unic, invariabil, o clasă căreia îi aparţine şi o stare reprezentată printr-o valoare
simplă sau structură.
2.2 Modele ale ciclului de viaţă a sistemului informatic
Mutaţiile din domeniul tehnologiilor informaţionale şi al metodelor de abordare a
sistemelor s-au reflectat şi în ciclul de viaţă al dezvoltării sistemelor, fie prin schimbările
32
etapelor acestuia, fie prin modificarea ordinii de parcurgere a lor. Indiferent de numele şi de
numărul etapelor ciclului de viaţă al dezvoltării 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 viaţa a sistemului informatic”.
În practică se regăsesc următoarele tipuri de modele:
model cascadă;
model V;
model incremental;
model spirală;
model evolutiv;
model tridimensional;
model X;
model fântână arteziană;
model pinball;
model minge de baseball;
model piramidă.
Modelul cascadă este unul de referinţă asigurând trecerea de la o etapă la alta în ordinea
secvenţială a posibilităţii revenirii la etapele anterioare sau parcurgerii în paralel a mai multor
etape. (Figura 2.1)
Fig. 2.1Modelul cascadă
Definirea
cerinţelor
Analiză
Proiectare
Implementare
Testare
Utilizare şi
întreţinere
33
Utilizare şi întreţinere
Avantaje:
controlează toate fazele în sensul ca ele au o ordine strictă şi aria lor de
întindere e clară;
modelul este uşor de însuşit de membrii echipei de proiectare;
fiecare etapă este însoţită de documentaţie.
Dezavantaje:
sistemul informatic se predă după parcurgerea tuturoretapelor ceea ce
înseamnă un interval mare de timp, în care pretenţiile utilizatorului se pot
schimba;
modelul nu corespunde unei abordări dinamice;
nu este deschis schimbărilor.
Modelul V este o variantă a celui cascadă prin care se introduc conceptele de componente,
subsisteme, aplicându-se teste explicite la nivel ierarhic pentru creşterea controlului asupra
modului în care se desfăşoară etapele, obţinând în felul acesta o latură a literei V. (Figura 2.2).
Prima latură se parcurge descendent şi conţine etapele propriu-zise ale unui sistem informatic,
iar a II-a se parcurge ascendent şi cuprinde toate etapele de verificare şi validare.
Fig. 2.2 Modelul V
Codificare/Asamblare
componente
Proiectare subsistemelor
(componente)
Proiectare sisteme
Definirea cerinţelor
Testare
subsisteme
Testare sisteme
Validare
34
Modelul incremental este o altă formă a modelului cascadă: până la etapa de proiectare nu
există diferenţe. După aceea se efectuează descompunerea proiectului în subproiecte. Faţă de
modelul V, oferă posibilitatea atingerii scopului final în două variante: sistemul global livrat la
sfârşit 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 aplicării modelului în orice condiţii, uneori neexistând posibilitatea
descompunerii în componente;
costurile de asamblare sunt mult mai mari prin realizarea testelor multiple.
Fig 2.3 Modelul incremental
Modelul spirală (Figura 2.4) se bazează pe două convingeri:
natura iterativă a dezvoltării şi nevoia de planificare şi evaluare a riscurilor
fiecărei iteraţii.
deficienţa înregistrărilor la modelul V în care validarea se efectuează prea târziu.
Definirea
cerinţelor
Analiza
Arhitectura
sistemului
Proiectare
componenta 1
Proiectare
componenta n
Implementare
componenta 1
Implementare
componenta n
Instalare
componenta 1
Instalare
componenta n
Întreţinere
componenta 1
Întreţinere
componenta n
35
Fig. 2.4 Modelul spirală
În orice iteraţie se va regăsi modelul cascadă.
Avantaje:
posibilitatea evaluării riscurilor în diferite momente ale proiectului;
simplificarea etapei de evaluare în ceea ce este necesar în etapa (prototipul)
următoare, inclusiv prin prisma costurilor.
Dezavantaje:
echipa de realizare trebuie să aibă un înalt nivel de profesionalism;
flexibilitate în acţiune.
Modelul evolutiv constă în descompunerea proiectului în părţi, fiecare cu o valoare deosebită
pentru client. Aceste părţi sunt realizate şi livrate în mod iterativ şi contribuie la sporirea
performanţelor sistemului. (Fig 2.5)
Părţile obţinute pentru completare nu sunt foarte detaliate tocmai în vederea adaptărilor şi
modificărilor ulterioare.
Oricare din aceste segmente luate în studiu trece prin toate etapele de dezvoltare a sistemului.
Reuşita modelului constă în crearea unei arhitecturi deschise elaborării prin participarea tuturor
utilizatorilor.
Prototip 4
Prototip 3
Prototip 2
Prototip 1
36
Fig. 2.5 Modelul evolutiv
Modelul 3D redă dezvoltarea sistemului printr-o reprezentare grafică în spaţiu. Pe o axă avem
ciclul de viaţă al sistemului (CVS), pe a II–a ciclul de viaţă al proiectului (CVP) şi pe ultima ciclul
abstractizării (CA). (Figura 2.6)
Ciclul de viaţă al sistemului – principalele perioade după care se fac schimbări majore,
creşterea volumului de date, modificări tehnologice, modificări structurale.
Fig. 2.6 Modelul 3D
T1 T2 T3
Nivel conceptual
Nivel logic
Nivel fizic
Studiu preliminar
Studiu detaliat
Studiu tehnologic
Sistem generaţia I
Sistem generaţia II
Sistem generaţia III
CVP
CVS
CA
Def. cerinţe Implementare
Analiză Testare
Def. cerinţe Implementare
Analiză Testare
Studiul iniţial
Descompunere
în segmente
Segment 1 Segment n
37
Modelul minge de baseball (Figura 2.7) sau dezvoltare concurentă: principiul lui este acela al
proiectării în paralel a activităţilor: analiză orientată obiect, proiectare şi programare orientată
obiect.
Pentru ca modelul să dea rezultate echipa trebuie să fie formată din experţi în domeniul
analizei, administrării datelor, cel al interacţiunii umane şi medii şi limbaje de programare
Fig.2.7 Modelul minge de baseball Modelul X (Figura 2.8) îşi propune să extindă performanţele obţinute prin modelul cascadă şi
prin modelul V. Acesta introduce noţiunea de model al livrării, fiecare proces sau etapă a
dezvoltării sistemelor poate fi privit şi urmărit ca o iteraţie sau evoluţie spre soluţia acceptată.
Modelele livrării sunt independente. Din punct de vedere tehnic. Acest lucru a făcut posibilă
exprimarea în partea superioară a „X”-lui a responsabilităţilor 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 dobândirea sistemului şi a componentelor sale pentru o
posibilă reutilizare.
00A 00D
00P
38
Fig. 2.8 Modelul X
Modelul fântână arteziană (Figura 2.9) îşi are originea în cel cascadă, dar reprezintă o variantă
îmbunătăţită în sensul că perioada de timp pentru finalizare e mai scurtă şi componentele sale
pot fi reutilizate în modele similare.
Achiziţie
Livrare sisteme
Testare
sisteme
Constr, testare
componente Selecţie şi adaptare
Proiectare şi testare
arhitectură sistem
Specificaţia sistemului
Obţinerea viziunii şi cerinţelor
Asamblare
Restabilire domeniu
Biblioteca structură
Rafinare
componentă
Biblioteca
structură
Biblioteca
componentă
Biblioteca
domeniului
Biblioteca
aplicaţiei
39
Fond software
Studiu
Fig. 2.9 Modelul fântână 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.
PROIECT
Fig. 2.10 Modelul pinball
I
N
T
R
E
Ţ
I
N
E
RE
I
M
P
L
E
M
E
N
T
A
R
E
Definire
moştenire Testare
Gasire
relaţii
Codificare
Găsire
clase
Definire
agregări
Definire
colaborări
Determinare
atribute
Definire
subsistem Aflare
metode
40
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 planificării spre analiza domeniului, proiectarea şi construirea lui.
Fig. 2.11 Modelul piramidă
2.3 Clasificarea metodologiilor de realizare a sistemelor informatice
Folosirea eficientă a resurselor şi necesitatea realizării unor sisteme informatice
performante au impus ordonarea într-o succesiune bine stabilită pe etape şi subetape a acestui
proces determinând conturarea unor metodologii de realizare a sistemelor informatice.
O metodologie de realizare a unui sistem informatic stabileşte componentele procesului
de realizare: etapele, subetapele, activităţile şi conţinutul lor; fluxul executării 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,
activităţi şi sarcini;
Fluxul realizării acestor etape/procese;
Modalităţile de desfăşurare 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;
Modalităţile de conducere a proiectului şi modul de utilizare a resurselor
Planificarea
întreprinderii
Analiza domeniului
întreprinderii
Proiectare
sistem
Construcţia
componentelor
obiectului
41
financiare, umane şi materiale.
O primă clasificare a metodologiilor se poate face după gradul de generalizare:
Metodologii generale au un grad înalt de generalitate putând fi folosit pentru realizarea
sistemelor informatice din diferite domenii.
Enumerăm câteva metodologii generale:
SSADM (Stuctured System Analysis and Design Methodology);
MERISE (Methode d’Etude et de Realization, Informatique pour les Systemes
d’Entreprise);
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. Enumerăm câteva 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 împărţirea sistemului în
subsisteme pe baza funcţiilor sistemului sau în funcţie de date.
Aceste metodologii propun modelarea datelor separat de modelarea procedurilor.
Modelarea sistemului se face plecând de la ideea că sistemul nu este izolat, ci există în cadrul
unui mediu cu care interacţionează. Sistemul reacţionează la evenimentele transmise din mediu
printr-un răspuns. Sistemul este afectat de mediu, dar nu controlează mediul.
Sistemul este structurat după diverse criterii în subsisteme până când se ajunge la nivel
elementar, punându-se în evidenţă relaţiile dintre subsistemele identificate. Abordarea acestor
subsisteme se face din puct de vadere: static, funcţional şi dinamic. În final rezultă modelul logic
42
ş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 prezentăm câteva:
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 activităţi 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 apărut odată cu apariţia limbajelor de programare orientate pe
obiecte.
Dintre metodologiile orientate obiect de realizare sistemelor informatice enumerăm:
OOD (Object Oriented Design) – o metodologie similară metodologiei OMT,
dezvoltând 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 diferenţe de
simboluri, notaţii sau tipuri de diagrame. Aceste aspecte generau dificultăţi în privinţa înţelegerii,
preluării ş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, notaţii, tipuri de diagrame numit UML (Unified Modeling Language).
Unii analişti programatori utilizează doar un subset al UML-ului, alţii folosesc întreg setul UML,
utilizând 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 prezentăm câteva:
Datele şi prelucrările nu sunt reprezentate distinct, ci încapsulat în clase de obiecte,
mîrinduse coerenţa rezultatelor analizei;
43
Modele utilizate sunt flexibile şi uşor de întreţinut;
Îmbunătăţirea comunicaţiei între utilizatori, analişti, proiectanţi şi programatori;
Reutilizarea rezultatelor analizei, proiectării şi implementării;
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 analiştii de sistem, programatorii realizează procesul de analiză a sistemului
informaţional - decizional existent, proiectarea şi introducerea sistemului informatic. Metoda are
un caracter general, în cadrul ei aplicându-se anumite tehnici de lucru.
Tehnicile de lucru utilizate în proiectarea sistemelor informatice reprezintă felul în care
se acţionează eficient şi rapid, în cadrul unei metode, pentru soluţionarea diferitelor probleme ce
apar în procesul de proiectare.
În activitatea de realizare a sistemelor informatice unele dintre metode şi tehnici sunt
specifice activităţii 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 enumerăm:
Metoda descendentă (Top-Down);
Metoda ascendentă (Bottom-Up);
Metoda LCS/LCP (Logical Construction of System / Programs)
Tehnica concordanţei intrări-ieşiri
Tehnica HIPO;
Metoda descendentă (Top-Down)
Metoda constă în descompunerea unui sistem complex pe niveluri ierarhice, succesiv,
până 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
modularizării de sus în jos, rezultând şi obiectivele specifice: crearea posibilităţii de realizare în
paralel a componentelor sistemului informatic şi eliminarea din sistem a redundanţelor.
Rezultatul realizării modularizării este modulul.
Modulul terminal este cel care nu mai poate fi descompus. Orice modul se poate
integra cu un alt modul formând noi module şi poate fi integrat mediului din care provine.
Procesul de descompunere se repetă până când toate modulele sunt considerate terminale.
Descompunerea are la bază următoarele reguli:
44
Nivelul zero de descompunere sau punctul iniţial de pornire îl reprezintă modul
neterminal sau coordonator;
Pentru toate modulele neterminate ale unui nivel se aplică descompuneri succesive în
paşi de sus în jos;
Descompunerea este terminată când 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ă cunoaşterea apriorii a domeniului problemei, aceasta
realizându-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 relaţiilor dintre componentele sistemului afectând activitatea
până în momentul respectiv.
Metoda ascendentă (Bottom-Up)
Metoda constă în agregarea modulelor de jos în sus punând în evidenţă legăturile
dintre ele până se ajunge la un singur modul.
Modularea şi abordarea sistemică sunt conceptele care stau la baza acestei metode, aceleaşi
ca la metoda de abordare descendentă.
Regulile care stau la baza metodei sunt:
Nivelul de agregare iniţial este nivelul la care se află modulele terminale;
Agregarea se face succesiv de jos în sus;
Când se obţine un nivel de agregare se realizează integrarea modulelor de nivel inferior
în module de nivel superior;
Agregarea este terminată când la un nivel de agregare se obţine un singur modul.
Avantajul folosirii acestei metode ar fi acela că sistemul informatic se dezvoltă treptat, în
corelaţie cu cerinţele beneficiarului. Beneficiarul beneficiază de rezultatele prelucrării automate a
datelor mai repede, se familiarizează cu noul sistem gradat. Se reduce riscul realizării unui
sistem neoperaţional în momentul punerii în aplicaţie.
Dezavantajul acestei metode rezultă din gradul de integrare redus al modulelor datorită
lipsei unei concepţii iniţiale 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 funcţie de structura datelor de ieşire. Ea permite
45
specificarea condiţiei de executare şi a numărului de efectuări ale procedurilor care sunt
structurate până la nivelul elementar.
Tehnica concordanţei intrări-ieşiri este o tehnică ce se utilizează atât la analiză, cât şi la
proiectare.
Plecând de la informaţiile necesare fundamentării deciziilor se determină mulţimea
informaţiilor primare ale sistemului respectiv. Pe baza sistemului de decizii identificat se
determină în continuare informaţiile de ieşire din sistemul informaţional, necesare fundamentării
acestor decizii.
Această metodă de determinare a informaţiilor de intrare pe baza celor de ieşire este
utilă în cazul sistemelor complexe, cu multe informaţii.
Abordarea analizei poate fi făcută şi plecând de la intrări şi ajungând la ieşirile
sistemului informaţional.
Metoda prezintă dezavantajul că nu este posibilă punerea în evidenţă a tuturor
legăturilor dintre datele primare existente în sistem.
Tehnica HIPO este concepută pentru abordarea ierarhizată a sistemului informaţional urmărind
descrierea fluxului INTRĂRI – PRELUCRĂRI – IEŞIRI.
Această tehnică se concretizează în elaborarea unei documentaţii care este alcătuită din:
HIPO general;
HIPO de detaliu;
HIPO de întreţinere.
HIPO general prezintă structura funcţională a sistemului şi stă la baza proiectării şi a comunicării
în cadrul echipei de proiectare a sistemului.
HIPO de detaliu prezintă o descriere generală şi de detaliu a structurii tuturor
fişierelor/entităţilor/relaţiilor folosite.
HIPO de întreţinere prezintă documentaţia corectată şi completată după testarea şi
implementarea sistemului informatic.
Fiecare documentaţie în parte trebuie să conţină:
Tabela de conţinut care conţine structura funcţională ierarhică cu legături între
componente. Descompunerea ierarhică trebuie să respecte concepţia de bază a
acestei tehnici (INTRĂRI – PRELUCRĂRI – IEŞIRI) şi să permită asocierea, pentru
fiecare nivel descompus, a cel puţin o diagramă generală.
Diagrama generală prezintă funcţiile importante ale sistemului conţinând reprezentarea
grafică a fluxului INTRĂRI – PRELUCRĂRI – IEŞIRI cu detalierea acestor funcţii.
Diagrama de detaliu prezintă descrierea analitică a fiecărei funcţii majore din diagrama
46
generală, prin descompunerea acestora până la ultimul nivel de obţinere a tuturor
informaţiilor privind fluxurile INTRĂRI – PRELUCRĂRI – IEŞIRI şi ultimele relaţii de flux
de pe ultimul nivel de detaliere.
Teste de evaluare a cunoștințelor
1. În cadrul proiectării unui sistem informatic:
a. informaţiile de programare, planificare şi previziune au un caracter relativ sintetic
b. se prezintă toate legăturile 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 urmareşte afişarea în fereastra de bază Taskbar o serie de reprezentări grafice
e. datele şi prelucrările sunt studiate şi modelate împreună
2. Proiectarea sistemelor informatice prin abordarea descendenta:
a. constă în a coborî, pe scara piramidei ierarhice, până la bază, realizând totodată şi o
analiză
b. culegerea şi înregistrarea datelor tehnico-economice şi financiare, care privesc
patrimoniul unităţilor şi economiei naţionale
c. duce la realizarea gestionarului de reţea şi a celui de fişire şterse
d. aplicaţii Windows - aplicaţiile scrise pentru programele rezidente - programe de tip
Terminate and Stay Resident (TSR)
e. va permite utilizatorului executarea unei operaţiuni de instalare automată a unor
subansamble nou adaugate în configuraţia calculatorului
3. Într-un sistem informatic, metodele si procedurile de prelucrare se refera la:
a. partea logică a prelucrării datelor în vederea obţinerii informaţiilor
b. pentru producerea de imagini standard în spiritul teoriei valorii, antrenează o pierdere
de informaţie
c. costurile de fabricaţie a bunurilor, de executare a lucrărilor sau de prestare a serviciilor
d. obţinerea şi cercetarea unităţilor elementare de informaţie
e. rezolvarea unei variate problematici de natură economică
4. Metoda orientată obiect:
a. prezintă instrucţiuni SQL încapsulate în codul program
b. este caracterizată prin atenţia deosebită acordată concomitent structurii datelor şi
47
structurii funcţionale
c. are programe de investiţii, programe de aprovizionare şi vânzare de bunuri, servicii şi
de marketing
d. realizează fixarea opţiunii gestiunii la nivel conceptual, opţiunii organiza-ţionale la nivel
logic şi a celei tehnice la nivel fizic
e. este un proces simplu şi rapid de aşezare a tabelelor şi a câmpurilor strict necesare
5. Metodele de proiectare se pot clasifica in:
a. pilotajul şi execuţia operaţiunilor 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. operaţii de adăugare, modificare, ştergere, mutare şi copiere de sisteme informatice de
gestiune
e. descrierea activităţii sistemului operant, orientată pe baza regulilor de funcţionare,
sisteme de management, aplicate asupra intrărilor, pentru a produce ieşirile dorite
6. Proiectarea sistemelor informatice prin abordarea ascendentă:
a. presupune structurarea informaţiilor financiar-contabile, prelucrate potrivit procedeelor
metodei contabilităţii 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 adăugarea la desktop a unei funcţionalităţi specifice Internet-ului
d. are ca punct de plecare nivelul operaţional (aflat la baza piramidei ierarhice), şi, prin
realizarea informatizării la fiecare nivel în parte, se ajunge la un sistem informatic care
poate atinge nivelul extrem al piramidei
e. este format din reuniunea de funcţii care pune în evidenţă cel mai bine comportamentul
întregului sistem operant
7. Metodele de proiectare sistemice:
a. se compun din abstractizări care prezintă lumea reală ca pe o colecţie de entităţi şi de
legături, 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 „acţiune”
d. reprezintă ansamblul de tehnici şi echipamente de culegere, prelucrare şi transmitere a
48
informaţiilor
e. aduc o varietate de procedee pentru obţinerea şi prelucrarea datelor, în vederea
utilizării sistemelor informaţionale în gestionarea unei unităţi economice
8. Avantajul major al metodei de proiectare Merise este:
a. descrierea sistemelor informatice pe nivel conceptual, nivel logic sau organizaţional,
nivel fizic sau operaţional
b. obiectivul de strategie care permite managerului să adopte soluţii de dezvoltare a
activităţii firmei
c. prin acţiunea în timp real a sistemului informaţional economic
d. materializat prin modul de realizare a obiectivelor unităţii şi a sarcinilor fiecărui
compartiment
e. asigură o legătură directă între obiectele lumii reale şi entităţile definite, datele sunt
ierarhizate, manipulându-se legăturile între obiect şi componentele sale
9. Ciclul de viaţă al unui sistem informatic descrie cronologic:
a. toate principiile în domeniu, completându-se legislaţia românească cu două principii,
conform Recomandărilor IASC şi Reglementările Pieţei Comune
b. ansamblul activităţilor sistemului operant faţă de mulţimea funcţiilor sale
c. principiul relevanţei economicului asupra juridicului; principiului pragului de
semnificaţie a informaţiilor
d. evoluţia proiectului de-a lungul întregului parcurs de funcţionare a software-ului,
încercând să arate cum poate fi încorporată o informaţie în cadrul organizaţiei
e. delimitarea domeniilor de studiu, a nenumăratelor mijloace de documentare, a
metodelor de concepţie şi punere în exploatare curentă informaţională
10. Specializarea claselor are ca punct de plecare:
a. programe de investiţii, programe de aprovizionare şi vânzare de bunuri, servicii şi de
marketing
b. transmiterea şi prelucrarea datelor, obţinerea de informaţii
c. superclasa adăugând noi atribute relevante numai pentru anumite obiecte din clasă,
creând astfel subclasele
d. un sistem operant format din reuniunea de funcţii care pune în evidenţă cel mai bine
comportamentul întregului sistem operant
e. starea în care se află elementele patrimoniale, sau valorile definite prin raportări
49
Capitolul 3
Cadrul tehnologic de analiză și dezvoltare a sistemelor informatice
Obiective:
Cunoașterea metodelor de analiză și dezvoltare a sistemelor informatice
Identificarea problemelor de soluționat și structurarea cerințelor noului sistem informatic
Înțelegerea mecanismelor de modelare a datelor și realizarea trecerii succesive de laun model
la altul
Cuvinte cheie: analiză structurală, analiză dinamică, analiză funcțională, diagrame de flux,
diagrame de tranziție, 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 disfuncţionalităţi informaţionale şi consecinţele lor
manageriale, economice şi umane.
Concomitent se evidenţiază şi aspectele pozitive ale sistemului informaţional curent şi
se evaluează problemele pe care trebuie să le rezolve viitorul sistem.
În analiza sistemului informaţional trebuie să regăsim aspectele:
aria de întinderea a sistemului informaţional care va deveni sistemul obiect pentru
conceperea şi realizarea unui sistem informatic;
reflectarea activităţilor şi operaţiilor economice specifice sistemului informaţional;
surprinderea modificărilor ce se impun în organizarea şi funcţionarea unui sistem
informatic;
fundamentarea unei soluţii de principiu care să precizeze activitatea şi operaţiile ce
urmează a fi informatizate, costul antecalculat al sistemului.
Etapa de analiză trebuie să urmărească:
Identificarea problemelor de soluţionat şi determinarea cerinţelor sistemului;
Structurarea cerinţelor noului sistem;
Evaluarea sistemelor informatice;
Generarea şi alegerea variantelor de proiectare.
Tot în această etapă de analiză începe și modelarea datelor.
50
3.1 Identificarea problemelor de soluţionat şi determinarea cerinţelor sistemului
Identificarea problemelor de soluţionat începe cu activitatea de culegerea şi înregistrarea de
date şi informaţii referitoare la componentele sistemului informaţional.
Pentru identificarea problemelor de soluţionat este necesar un studiu al sistemului existent şi
care se realizează prin:
Definirea caracteristicilor generale ale unităţii:
Profilul şi obiectivele organizaţiei;
Locul ocupat în sfera serviciilor şi sfera producţiei;
Specificul activităţii de bază;
Principalii indicatori economici şi evoluţia lor;
Proiecte de modernizare, dezvoltare;
Structura organizatorică.
Identificarea activităţilor desfăşurate
Documentele de bază pot fi:
Regulamentul de organizarea funcţională (ROF);
Regulamentul de ordine interioară (ROI);
Statutul de funcţionare al organizaţiei.
Din aceste documente rezultă informaţii despre funcţiile, activităţile şi modul de realizare a lor,
relaţiile funcţionale dintre compartimente, sarcina ce revine fiecărui compartiment.
Depistarea deficienţelor informaţionale.
Studiile efectuate asupra sistemelor informaţionale din cadrul firmelor au reliefat
existenţa unor deficienţe tipice, relativ frecvente, reflectare a unor erori în conceperea şi
implementarea lor, a căror cunoaştere şi preîntâmpinare este esenţială.
Distorsiunea – prima dintre deficienţele tipice, constă în modificarea parţială
neintenţionată a conţinutului, a mesajului unei informaţii pe parcursul culegerii, prelucrării şi
transmiterii de la emiţător la receptor. Dintre cauzele multiple care generează distorsiunea
menţionăm ca foarte frecvente: diferenţele în pregătirea persoanelor implicate în vehicularea
informaţiei, folosirea de suporţi informaţionali necorespunzători pentru înregistrarea informaţiilor,
manipularea neglijentă a suporţilor de informaţii în procesul transmiterii lor beneficiarilor,
utilizarea de mijloace necorespunzătoare pentru înregistrarea şi transmiterea informaţiilor etc.
51
Filtrajul, a doua deficienţă informaţională majoră, se deosebeşte de distorsiune prin
aceea că modificarea parţială sau totală a mesajului sau conţinutului informaţiilor are loc în mod
intenţionat. Cauza filtrajului este una singură: intervenţia pe parcursul înregistrării, transmiterii şi
prelucrării informaţiilor a unor persoane, care au interesul ca beneficiarul informaţiei să
primească un mesaj schimbat. Această deficienţă cronică a sistemului informaţional se
manifestă în special când unii manageri sunt incorecţi sau nu-şi exercită integral atribuţiile de
control.
Efectul negativ atât al distorsiunii, cât şi al filtrajului este dezinformarea parţială sau integrală a
beneficiarului de informaţii. Când dezinformarea se produce la nivelul managerilor, aceasta se
reflectă în diminuarea calităţii deciziilor. Când dezinformarea se produce la nivelul executanţilor,
efectele immediate se resimt pe palnul realizării proceselor cu caracter operaţional, impietând
asupra cantităţii, calităţii şi perioadei de obţinere şi furnizare a produselor şi serviciilor. În ambele
situaţii, efectele pe termen lung sunt scăderea eficienţei, concomitent cu deteriorarea într-o
anumită măsură a climatului de muncă, a relaţiilor dintre personalul implicat ş.a.
Redundanţa este o altă deficienţă majoră tipică a sistemului informaţional, care constă
în înregistrarea, transmiterea şi prelucrarea repetată a unor informaţii. Cauza majoră a acestei
disfuncţionalităţi informaţionale o reprezintă absenţa coordonării sau coordonarea defectuoasă a
anumitro segmente ale sistemului managerial. Redundanţa se produce mai ales când nu se
respectă principiul unităţii de decizie şi acţiune, când mai mulţi manageri se adresează nemijlocit
cu cereri de informaţii unor compartimente, fără ca personalul managerial responsabil nemijlocit
de activitatea lor să fie informat şi să intervină. Efectele redundanţei, care se manifestă adesea
sub forma cererii aceloraşi informaţii de către diferiţi beneficiari, dar sub alte forme, constau într-
o apreciabilă risipă de timp şi adesea de mijloace materiale din partea celor implicaţi.
În categoria deficenţelor majore se înscrie şi supraîncărcarea circuitelor
informaţionale cu informaţii, prin care desemnăm vehicularea prin ele a unei cantităţi de
informaţii ce-i depăşeşte capacitatea de transport, ceea ce duce la blocarea şi/sau întârzierea
ajungerii unei părţi din informaţii la adresant. Printre cauzele care o generează menţionăm – în
afara redundanţei – nerespectarea caracterului piramidal al sistemului informaţional. Prin
caracter piramidal al sistemului informaţional înţelegem transmiterea şi agregarea selectivă a
informaţiilor pe verticala sistemului de management corespunzător sferei obiectivelor,
competenţelor şi responsabilităţilor circumscrise subdiviziunilor organizatorice. La originea
acestei situaţii se află proiectarea defectuoasă a sistemului informaţional, insuficienta pregătire a
unor manageri şi executanţi, tendinţa unora de a-şi “umfla” realizările, de a-şi populariza excesiv
acţiunile etc.
52
Fără îndoială că elementele menţionate nu epuizează gama deficienţelor cronice ale
sistemului informaţional, dar constiuie, de regulă, maladiile cele mai frecvente, a căror
cunoaştere, identificare şi eliminare constituie o componentă de bază a raţionalizării sistemului
informaţional al organizaţiilor.
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 execuţie implicat, consultanţii în
management, informaticienii, prestatorii de servicii specializate;
Resurse informaţionale – metodologii, instrucţiuni, cărţi, studii, documentaţii;
Resurse financiare – necesare plăţii onorariilor realizatorilor studiului, achiziţionării de
echipamente electronice şi consumabile.
Este foarte importantă analiza atentă a cerinţelor, deoarece ele pot fi incomplet exprimate sau
pot fi exprimate ca opinii, sugerând soluţia tehnică, fără să descrie cerinţele efective ale
problemei .
Cerinţele se pot împărţi în:
Cerinţe funcţionale – se referă la activităţile pe care trebuie să le realizeze noul sistem
(cerinţe referitoare la stocarea, modificarea datelor; cerinţe privind modul de obţinere a
rapoartelor);
Cerinţe nefuncţionale – se referă la modul în care sistemul realizează activităţile
prevăzute (cerinţe privind securitatea datelor; cerinţe privind refacerea datelor pierdute;
cerinţe de arhivare; cerinţe determinate de trecerea de la prelucrarea manuală la
prelucrarea automată).
Determinarea cerinţelor sistemului este o activitate esenţială în aflarea situaţiei existente şi a
ceea ce se doreşte în viitor. Culegerea informaţiilor este posibilă prin metode tradiţionale sau
moderne.
Metodele tradiţionale de colectare a cerinţelor 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 informaţiile pentru exercitarea sarcinilor de serviciu;
studierea documentaţiei firmei pentru a se cunoaşte conţinutul rapoartelor, al politicilor
53
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 comunicării directe de stabilire a unei relaţii cu o finalitate
precisa, predeterminata, proces conceput pe alternanta rolurilor si care implica formulări de
întrebări si obţinerea de răspunsuri.
Cuvântul proces semnifică dinamism, interacţiune continuă cu multe variabile de lucru, cu
acţiune înlănţuită, după un anumit sistem de derulare.
Cuvântul diadic, pornind de la diadă, scoate în relief faptul că interviul este o
interacţiune persoană-cu-persoană între două părţi sau două componente, evitându-se astfel
faptul că la interviu pot participa mai multe persoane, dar niciodată mai mult de două părţi: cea
care ia interviul şi cea intervievată.
Cuvântul relaţii sugerează o legătura interpersonală între părţile interviului.
Finalitate precisă, predeterminată înseamnă că cel puţin o persoană vine la interviu cu un
anumit scop şi vrea să abordeze un anumit subiect.
Alternanţa rolurilor are conotaţia împărtăşirii gândurilor, a simţămintelor şi informaţiilor printr-o
schimbare continuă a rolurilor.
Dacă numai una dintre părţi vorbeşte si cealaltă ascultă se poate vorbi despre un
discurs (speech), si nu despre interviu. Se consideră că aproximativ 70% din timpul total al
interviului aparţine 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 informaţii
sau promovarea unei vânzări.
Formularea de întrebări şi obţinerea răspunsurilor constituie procesele esenţiale ale interviului.
Puţine sunt interviurile care să nu necesite o structurare prealabilă a întrebărilor.
Chestionarele
Spre deosebire de interviuri, chestionarele sunt mai puţin costisitoare şi într-un timp
relativ scurt, pot oferi un volum mare de informaţii necesare analizei sistemului.
Deoarece conceperea chestionarului este mai mult o arta decât o ştiinţă, specialiştii s-au străduit
să-şi prezinte experienţa sub forma unor reguli, recomandate îndeosebi începătorilor, cei cu
state vechi le pot utiliza drept elemente de comparaţie pentru a-şi evalua paşii întregii proceduri.
54
Din aceste motive se consideră de bun augur descrierea paşilor parcurşi pentru conceperea
unui chestionar :
pasul 1 : Ce informaţii vor fi căutate ?
În primul pas al chestionarului se stabilesc informaţiile care trebuie să fie obţinute, operaţie
declanşată în faza embrionară a cercetării de întreprins. Neglijenţa manifestata în această etapă
va conduce la obţinerea unor informaţii nerelevante.
pasul 2 : Stabilirea tipului de chestionar şi a metodei de administrare
După identificarea informaţiilor de căutat, cel ce concepe chestionarul trebuie să specifice modul
în care le va obţine. Decizia se va referi la structura si modul de formulare a întrebării, după care
se va pune problema administrării chestionarului. : prin poştă, telefonic sau cu operator(o
persoană special desemnată pentru această operaţiune).
pasul 3 : Determinarea conţinutului fiecărei întrebări
pasul 4 : Stabilirea modului de redactare a răspunsului pentru fiecare întrebare
Dacă se merge pe o variantă fixă, proiectantul trebuie să decidă dacă va folosi întrebări închise
sau dacă va merge pe varianta opţiuni multiple, două opţiuni sau a scalei de valori.
pasul 5 : Formularea întrebărilor
De modul în care sunt formulate întrebările, practic depinde succesul chestionarului.
pasul 6 : Stabilirea secvenţei întrebărilor
pasul7: Validarea caracteristicilor tehnice ale chestionarului
pasul 8: Reevaluarea paşilor 1-7 şi revizuirea lor (dacă este cazul).
Pasul 9: Efectuarea pretestului şi revizuirea finală (dacă este cazul).
De regulă, chestionarele sunt administrate pe hârtie, dar ele pot fi efectuate cu sau fără
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 întrebări cu schemă fixă de răspuns,
iar atunci când conţin întrebări cu o formulare vagă au ca scop aflarea părerilor celor chestionaţi,
pentru a putea fi surprinse cât mau multe cazuri.
Eşantionarea
Întrucât colectivităţile depăşesc întotdeauna numărul celor ce sunt chestionaţi, o problema
esenţială o constituie stabilirea eşantionului chestionat. De regula, se folosesc următoarele 4
metode sau combinaţii ale lor :
cei adecvaţi eşantionului : ei pot fi oameni care îşi desfăşoară activitatea într-un anumit
loc, cei care sunt motivaţi să dea răspunsuri sau cei care vor să dea răspunsuri sau cei
care vor să fie intervievaţi.
un grup aleator : dacă exista o listă a utilizatorilor unui sistem simplu, se selectează
fiecare a n-a persoana, în care n este o raţie de selecţie. O altă modalitate constă în
55
selecţia persoanelor pe bază ordonării lor după a 2-a, a 3-a literă a numelui sau a
prenumelui sau prin generarea aleatoare a numerelor cu ajutorul calculatorului.
un eşantion precizat: pot fi numai persoanele care îndeplinesc anumite criterii.
un eşantion stratificat: dacă sunt mai multe categorii de persoane, din fiecare, după
criterii aleatoare, vor fi selectaţi cei eşantionaţi. De exemplu: dintre utilizatori,
conducători, informaticieni.
Observarea directă a utilizatorilor
Nu întotdeauna consultarea persoanelor conduce la obţinerea celor mai bune rezultate,
chiar si atunci când acestea afirmă ca oferă cele mai sigure informaţii sau au impresia ca deţin
adevărul absolut asupra sistemului analizat. Părerile sunt subiective.
Desfăşurarea operaţiunii de observare directa depinde si de acceptul sau bunele
intenţii ale organizaţiei supuse analizei. Uneori, chiar daca exista un astfel de accept, prezenta
analiştilor printre angajaţi ii determina pe aceştia din urma sa manifeste un comportament
anormal, cu scopul de a crea o anumita impresie. Astfel pot fi emoţionaţi, stresaţi, se pot forţa să
efectueze lucrările 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.
Aşadar, observarea presupune pentru analişti selecţia 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 organizaţiei, cunoaşterea obiectivelor
acesteia, a planurilor de afaceri, a studiilor de fezabilitate, a structurii organizatorice
(organigrama), a regulamentelor de organizare si funcţionare, a celor de ordine interioara, a
normelor interne de fabricaţie, 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 activităţile
individuale sau ale grupurilor. Prin ele se descrie modul in care se exercita o anumita activitate,
prezentându-se si datele si/sau informaţiile pe care le solicita sau le generează.
Un al doilea tip de documente ce este studiat de analiştii de sistem îl constituie formularele
utilizate de către unitate pentru toate tranzacţiile interne si externe care au loc.
Al treilea tip îl constituie rapoartele generate de sistemul actual.
56
Al patrulea tip se regăseşte numai in sistemele de prelucrare automata a datelor si se refera la
documentaţia folosită in sistemul informatic.
Ca efect al tendinţelor de mărire 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 puţine
elemente ale sistemelor existente.
Sesiunile JAD pun laolaltă toate forţele interesate în dezvoltarea sistemelor: utilizatorii cheie,
managerii şi analiştii de sistem implicaţi în analiza sistemului curent. Din acest punct de vedere
JAD este similar interviului la nivel de grup. Totuşi, în sesiunile JAD ce urmează o anumită
secvenţă de derulare a activităţilor pe baza unor roluri bine definite.
Prototipizarea este un proces iterativ prin care analiştii şi utilizatorii pun în discuţie o versiune
rudimentară a unui sistem informaţional, care va fi într-o continuă schimbare, în funcţie de
reacţia utilizatorului. Prototipul este văzut şi testat de utilizator, având posibilitatea să precizeze
ce ar mai dori, dar şi să-şi genereze această formă nouă, firesc, cu ajutorul specialiştilor din
preajmă.
RAD este o metodologie de realizare a sistemelor informaţionale care promite sisteme mai
bune, mai ieftine şi realizate mai rapid. O primă explicaţie constă în celor mai buni proiectanţi de
sisteme şi a celor mai reprezentativi utilizatori , care, împreună, în timp real, lucrează la
realizarea sistemului.
Diferenţa majoră a RAD faţă de JAD constă în faptul că prototipul devine elementul fundamental
al noului sistem - ecranele afişate în timpul prototipizării devin ecrane ale sistemului, şi nu
modele ale unui posibil sistem.
Plecând de la aceste obiective, suportul hardware şi software al noului sistem informatic trebuie
să îndeplinească următoarele cerinţe:
o Asigurarea suportului informaţional prin crearea şi întreţinerea 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 aplicaţii la această imagine;
crearea şi actualizarea în timp real a bazei de date cu evoluţia î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 informaţii;
57
arhivarea şi întreţinerea arhivelor cu istoricul procesului şi evenimentelor precum şi
accesul distribuit la datele din arhivă.
o Asigurarea unui flux informaţional coerent:
circulaţia selectivă a informaţiilor existente în imaginea internă a procesului către
utilizatori, în funcţie de specificul activităţilor;
gestiunea automată a fluxului de date pe orizontală şi pe verticală(în interiorul şi între
nivelele ierarhice) în vederea întreţinerii bazelor de date;
gestiunea dinamică a înregistrărilor în baza de date ţinând cont de durata de viaţa
impusă pentru acestea.
o Prezentarea informaţiilor către utilizatori
Prin intermediul staţiilor de lucru, utilizatorul poate avea acces la informaţiile din sistem în
concordanţă cu sarcinile pe care acesta la are în ierarhia de funcţii. Accesul la sistem se face
numai prin identificarea utilizatorului după nume şi parola de protecţie, numai pentru funcţiile
specifice postului său.
o Comunicarea transparentă pentru utilizatori între echipamentele din sistem
Suportul de comunicaţie trebuie astfel conceput încât pentru orice utilizator
echipamentele interconectate să fie văzute ca un singur calculator „uriaş”.
o Integrarea cu alte aplicaţii existente sistemului informaţional
Utilizarea unor legături de comunicaţie dedicate, pentru activităţile de conducere
operativă.
Accesul la informaţii, utilizând serviciile intranet.
o Disponibilitatea şi funcţionarea degradată în cazul căderii unor componente şi
siguranţa păstrării informaţiilor
Posibilitatea de intervenţie pentru întreţinere sau depanare asupra unor componente
ale sistemului fără afectarea funcţionării de ansamblu.
Funcţionarea în regim de rezervare activă a componentelor vitale ale sistemului: canale
de comunicaţie dublate, servere de baze de date cu mai multe procesoare şi memorii
externe RAID.
Replicarea componentelor vitale ale bazei de date în locaţii diferite, pentru a evita
pierderea datelor în caz de defect.
Accesul la funcţiile specifice de la orice staţie de lucru în cazul indisponibbilităţii celor
destinate implicit pentru funcţiile respective.
o Configurabilitatea şi posibilitatea de extindere
58
Abordarea realizării sistemului în etape succesive impune existenţa unor funcţii de bază care să
permită:
Extinderea sistemului prin adăugarea de noi componente fizice şi logice.
Modificarea interactivă a bazelor de date care descriu componentele logice din sistem
Adăugarea de noi aplicaţii care au acces la informaţiile din sistem
3.2 Structurarea cerinţelor sistemului
În structurarea unui sistem informatic se utilizează mai multe criterii de descompunere a
acestuia în subsisteme şi module componente:
Funcţiunile sistemului. - Sistemul informaţional este alcătuit din mai multe subsisteme
funcţionale: producţie, comercial, financiar-contabil, personal, cercetare-dezvoltare;
Activităţile sistemului – O serie de activităţi se desfăşoară în cadrul unui agent
economic, care respectă anumite proceduri bine stabilite în vederea realizării
obiectivelor. Activităţile variază ca tip şi număr 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 informaţional.
Indiferent de criteriul utilizat putem spune că structurarea cerinţelor sistemului e etapa
cea mai complexă din cadrul analizei şi se bazează pe 2 activităţi (Figura 3.2 ):
modelarea proceselor;
modelarea datelor.
Activitatea de analiză pentru modelarea conceptuală se poate realiza sub trei aspecte:
structural, dinamic şi funcţional.
Analiza structurală evidenţiază, la nivel conceptual, modul de structurare a datelor şi a
legăturilor dintre ele. Cea mai utilizată tehnică este entitate-asociere.
Aceasta conţine:
Identificarea entităţilor: fenomene, procese, obiecte concrete sau abstracte
(substantivele din prezentarea activităţii descrise) (exemple de entităţi: Persoane,
Produse, Beneficiari).
Identificarea asocierilor dintre entităţi ca fiind legăturile semnificative de un
anumit tip (verbele din prezentarea activităţii descrise).
59
Identificarea atributelor ce caracterizează fiecare entitate în parte (exemple de
atribute: Marca, Nume, Adresă).
Stabilirea atributelor de identificare unică a realizărilor entităţii, drept chei.
Rezultatul analizei structurale este modelul static (structural), numit şi diagramă
entitate-asociere.
Analiza dinamică evidenţiază comportamentul elementelor sistemului la anumite
evenimente. Una dintre tehnicile utilizate este diagrama stare-tranziţie.
Aceasta presupune:
Identificarea stărilor în care se pot afla componentele sistemului.
Identificarea evenimentelor care determină trecerea unei componente dintr-o
stare în alta.
Stabilirea tranziţiilor admise între stări
Construirea diagramei stare-tranziţie
Rezultatul analizei dinamice: modelul dinamic.
Analiza funcţională evidenţiază modul de asigurare a cerinţelor informaţionale (fluxul
prelucrărilor) din cadrul sistemului, prin care intrările sunt transformate în ieşiri. 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 circulaţie şi prelucrare a datelor.
Se identifică apoi rezultatele obţinute.
Rezultatul analizei funcţionale: modelul funcţional.
Urmare a operaţiunii de culegere a cerinţelor sistemului este activitatea de structurare a
cerinţelor prin metode specifice: modelarea proceselor, modelarea logicii proceselor şi
modelarea conceptuală a datelor.
Indiferent de metodologiile folosite în realizarea unui sistem, toate apelează la operaţiunea de
modelare logică a datelor şi prelucrărilor sub formă de diagrame.
Există mai multe tipuri de diagrame, utilizabile în diverse etape ale ciclului de viaţă al
sistemului sau pentru anumite activităţi. Î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 următoarele aspecte:
fluxuri de date redundante, apărute, de regulă, prin apelarea la nume diferite pentru
acelaşi tip de date;
date care intră în prelucrări dar nu sunt folosite;
datele ce sunt actualizate identic în mai multe locuri.
60
Fig. 3.2 Activităţile etapei de analiză
3.3 Evaluarea sistemelor informatice
Evaluarea sistemului existent se realizează sub două aspecte:
Evaluarea performanţelor şi limitelor sistemului existent se face ţinând cont de următoarele
criterii:
Măsura în care sistemul informaţional asigură realizarea obiectivelor,
îndeplinirea sarcinilor de bază ale unităţii şi exercitarea atributelor de conducere;
Operativitatea în culegerea şi trasmiterea informaţiilor şi datelor, ceea ce
caracterizează timpul de răspuns al sistemului infomaţional;
Calitatea şi siguranţa legăturilor informaţionale, a fluxurilor informaţionale;
Posibilităţi de control şi de efectuare a corecţiilor.
Evaluarea gradului de pregătire a unităţii economice pentru proiectarea şi implementarea
sistemului informatic presupune:
Stabilirea nivelului de pregătire a personalului şi a experienţei dobândite în
Sisteme – subsisteme
informaţionale/proceduri
informaţionale
Documentare şi analiză
Informaţii şi
legături dintre ele
Proceduri şi reguli de
gestiune
Modelare
Modelul conceptual al
datelor
Modelul conceptual al
prelucrărilor
61
prelucrarea automată a datelor;
Existenţa unei discipline tehnologice;
Existenţa fondului de date necesar pentru realizarea sistemului informatic.
3.4 Modelarea noului sistem informatic
Activitatea de modelare a unui sistem informatic se regăseşte în pricipalele activităţi 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, atât în memoria
internă, cât ş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 colecţii, precum
şi stabilirea legăturilor între elementele unei colecţii şi între colecţii.
Organizarea datelor a evoluat în paralel cu creşterea volumului de date prelucrat,
precum şi a gradului de complexitate a problemelor rezolvate cu ajutorul calculatorului.
Evoluţia organizării datelor a pornit de la fişiere simple, au urmat fişierele complexe şi, în final, s-
a ajuns la cea mai performantă formă de organizare a datelor – bazele de date.
Toate aceste forme de organizare a datelor se bazează pe noţiunea de colecţie de date.
Colecţia de date reprezintă un ansamblu de date organizat după anumite criterii şi format din
următoarele componente:
familie de caracteristici compusă din mai multe proprietăţi (atribute) care definesc
aspecte ale obiectelor din lumea reală prin valori;
un predicat aplicat asupra familiei de proprietăţi, care conduce la o submulţime ce
defineşte o relaţie de ordine între caracteristici, cu un anumit scop;
alte componente care iau în considerare timpul şi legăturile.
Investigare pleacă de la o viziune de ansamblu a structurii logice a datelor.
Datele sunt grupate în colecţii de date, după diverse criterii pentru fiecare subsistem sau la
nivelul întregului sistem.
Principalele criterii pe baza cărora se poate efectua gruparea fondului de date sunt:
Sfera de cunoaştere;
62
Domeniul de activitate;
Stabilitatea conţinutului datelor;
Rolul datelor în procesul prelucrării.
După sfera de cunoaştere se pot contura patru tipuri de colecţii mari de date cu valori de
întrebuinţare diferite, cu grad de agregare şi sintetizare diferenţiat, care pot constitui obiectul
stocării şi prelucrării automate:
Date primare;
Indicatori tehnico-economici cu caracter operativ;
Indicatori tehnico-economici cu centralizare medie;
Indicatori sintetici.
După domeniul de activitate, la nivelul unei unităţi productive, datele pot fi grupate în colecţii ce
reflectă entităţi, fenomene şi procese economice.
Din punct de vedere al stabilităţii datelor, putem delimita: colecţii de date convenţional –
constante şi colecţii de date variabile. Colecţiile da date convenţional – constante sunt cu
caracter normative, cu caracter descriptive, cu caracter de translatare sau de legătură.
Principalele colecţii de date cu caracter normativ sunt:
Normative de fabricaţie;
Normative tehnologice;
Normative de muncă;
Normative materiale.
Din punct de vedere al prelucrării datelor, colecţiile de date se clasifică în:
Colecţii de date de bază – au un conţinut omogen format din date primare care reflectă
stări, caracteristici, evenimente, fapte preluate din unul mai multe documente primare.
Se poate aprecia că datele îşi păstrează valabilitatea, relevanţa, autenticitatea, au o
utilitate pe o perioadă de existenţă a obiectelor pe care le reprezintă, le descrie, le
reflectă;
Colecţiile de date pentru tranzacţii - au un caracter temporar şi un conţinut format din
totalitatea modificărilor care pot interveni pe parcursul unui interval de timp asupra
conţinutului informaţional din colecţiile de date de bază;
Colecţiile de date intermediare – sunt obţinute pe baza unor operaţii de sortare, fuziune,
63
selectare din una sau mai multe colecţii obiect potrivit unor cerinţe furnizate de
utilizator;
Colecţiile de date statistice – au un rol de orientare, de previziune, de fundamentare a
unor decizii strategice;
Colecţii de date istorice – au un rol de arhivare a conţinutului unor colecţii obiect, de
tranzacţii sau statistice şi reflectă o stare trecută a fenomenelor şi proceselor
economice.
Structura de date constituie o colecţie de date între care s-au stabilit o serie de legături, care
conduc la un anumit mod de identificare şi de selectare a componentelor.
Baza de date poate fi definită ca fiind mai multe colecţii de date omogene, cu legături între ele,
stocate pe un suport de memorie externă şi care formează un ansamblu:
organizat ( pe niveluri de organizare a datelor);
coerent (prin respectarea restricţiilor de integritate şi asigurarea protecţiei datelor
împotriva incidentelor);
structurat (datele şi legăturile 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.
Apariţia bazelor de date, ca mod de organizare a datelor în memoria externă, a determinat
şi modificarea software-ului aferent stocării şi prelucrării datelor. Datele memorate în fişiere 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 aplicaţie scrise într-un sistem de
gestiune a bazelor de date (SGBD) ca software specializat.
Aşadar, realizarea bazei de date şi a programelor de aplicaţie 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 următoarele 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 reglementări
64
administrative, destinate bunei funcţionări a sistemului, dicţionarul bazei de date
(conţine informaţii despre date, structura acestora, elemente de descriere a semanticii,
statistici, documentaţii), mijloace hardware utilizate, personalul implicat, reprezentat de
diferite categorii de utilizatori finali şi personal de specialitate (administrator, analişti,
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 soluţie informatică se face
gradat, luând în considerare un anumit tip de soluţie şi apoi, în cadrul tipului respectiv, o soluţie
direct implementabilă.
Modelul Conceptual Al Datelor(MCD)
Modelul conceptual al datelor este o metodă abstractă de reprezentare a tipurilor de
date, a legăturilor dintre acestea, a dinamicii acestor legături şi a restricţiilor (constrângerilor
aferente).
Pe baza unei analize detaliate şi complete a intrărilor şi a unor notaţii şi simboluri standardizate
se va construi modelul conceptual al datelor.
Fundamentul teoretic al cestui model este că structura datelor dintr-o organizaţie poate
fi modelată folosind doar trei tipuri de obiecte: entităţi, atribute, asocieri.
Entitate
O entitate este un model de obiect sau eveniment care are o existenţă de sine
stătătoare şi poate fi identificat, în raport cu celelalte obiecte de acelaşi tip, prin caracteristici sau
proprietăţi specifice.
Exemplu: Produs, Furnizor, Intrări, Ieşiri, Beneficiar, Comandă, Factură.
Modul de reprezentare a unei entităţi este un dreptunghi în care se înscrie numele entităţii.
Realizare a unei entităţi se numeşte mulţimea formată din câte o valoare a fiecărui atribut al
entităţii.
Fiecare entitate va fi identificată prin proprietăţile care o caracterizează, numite atribute.
Atributul
Un atribut se defineşte ca fiind o proprietate a unei entităţi sau a unei corespondenţe,
caracterizat printr-un nume şi un tip. Fiecare atribut care a fost selecţionat la denumirea
conţinutului unei entităţi este o caracteristică semnificativă pentru domeniul studiat.
Un atribut poate fi :
65
simplu: atunci când 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 apărea într-o singură entitate (principiul nonredundanţei );
un atribut poate avea mai multe valori elementare.
În reprezentarea grafică, identificatorul entităţii se subliniază.
Un domeniu este o mulţime de valori scalare (atomice - care nu pot fi descompuse) de acelaşi
tip.
Exemple: mulţimea codurilor personale, mulţimea numelor de clienţi, mulţimea numelor de
localităţi ş.a.
Cu aceste valori se pot efectua mai multe operaţii:
cu majoritatea acestor valori se pot face comparaţii;
cu unele valori se pot face şi alte operaţii: o cantitate poate fi înmulţită cu un preţ
(rezultând o valoare), un preţ poate fi înmulţit cu o valoare (în cazul unei reaşezări)
ş.a.m.d.
Asocierea
O asociere reprezintă legătura sau corespondenţa existentă între două sau mai multe
realizări ale entităţii. O asociere nu are o existenţă de sine stătătoare, depinzând de existenţa
realizărilor entităţilor pe care le leagă, în consecinţă nu are identificatori specifici.
O asociere poate avea atribute proprii.
Mulţimea care participă la asociere formează colecţia acesteia; numărul acestora dă
gradul sau dimensiunea asocierii.
Între realizările atributelor din entităţi şi cele ale proprietăţilor din asocieri (corespondenţe) se
stabilesc cardinalităţi sau conectivităţi.
Putem vorbi de o conectivitate minimă (0 sau 1) şi una maximă (1 sau n)
Să clasificăm în continuare legăturile binare după cardinalitatea acestora (câte entităţi din
fiecare clasă intră în cadrul legăturii):
legături de tip 1:1 (one-to-one); observăm o astfel de legătură în cazul unei evidenţe a
personalului, care indică faptul că un departament este condus de un şef (un
departament nu poate fi condus de mai mulţi şefi, o persoană nu poate conduce mai
multe departamente);
legături de tip 1:n (one-to-many); în evidenţa personalului remarcăm o astfel de
legătură între angajaţii unui departament şi departamentul în cauză (la un departament
lucrează mai mulţi angajaţi, un angajat nu poate lucra în cadrul mai multor
66
departamente); la evidenţa facturilor remarcăm o legătură între Facturi şi Clienţi (unui
client i se pot întocmi mai multe facturi; nu se poate întocmi o aceeaşi factură pentru
mai mulţi clienţi);
legături de tip m:n (many-to-many); o astfel de legătură există între Clienţi şi Produse:
un client poate cumpăra mai multe produse, şi în acelaşi timp mai mulţi clienţi pot
cumpăra un acelaşi sortiment de produse.
După ce vor fi prezentate fundamentele modelului relaţional, vom prezenta şi tehnici de
implementare a acestor tipuri de legături.
Exemplu de construire a modelului conceptual al datelor:
Prezentarea activităţii de gestiune a materialelor
Se doreşte ca în cadrul acestui sistem să se evidenţieze furnizorii, facturile, magaziile,
tipurile de materiale şi bonurile de consum.
Pentru a micşora gradul de dificultate a aplicaţiei se consideră că toate materialele cuprinse pe
o factură sunt trimise unei singure magazii. Materialele sunt recepţionate de o magazie pe baza
facturii şi sunt eliberate secţiilor de producţie pe baza bonurilor de consum. Presupunem că
materialele au un preţ unitar de achiziţie fix, care nu depinde de furnizor.
Pe baza intrărilor (facturi) şi a ieşirilor (bonuri de consum) se doreşte determinarea
nivelului stocurilor de materiale. Intrările şi ieşirile se operează zilnic în fişa de magazie.
În urma analizei problemei rezultă entităţile: Furnizor, Factura, Material, Magazie şi Bon de
consum.
Identificarea corespondenţelor:
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 cantităţi, de unde rezultă o
corespondenţă LINIE FACTURĂ.
Factură - Magazie
O magazie poate primi de la 1 la n facturi, de unde rezultă o corespondenţă PRIMEŞTE.
Bon de consum - Material
Într-un bon de consum sunt cuprinse de la 1 la n materiale în diferite cantităţi, de unde
corespondenţa LINIE BON DE CONSUM.
Bon de consum - Magazie
O magazie emite de la 1 la n bonuri de consum, de unde rezultă corespondenţa REALIZEAZĂ.
Factură - Factură
67
O factură poate fi stornată de 0 sau n facturi de stornare, de unde rezultă corespondenţa SE
STORNEAZĂ.
Stabilirea cardinalităţilor:
Corespondenţa EMITE:
dinspre entitatea Furnizor (1, n)
un furnizor emite cel puţin 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 puţin şi de cel mult un furnizor (cardinalitate 1, 1).
Corespondenţa PRIMEŞTE
dinspre entitatea Magazie (1, n)
o magazie primeşte cel puţin 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 puţin o magazie (cardinalitate 1, 1).
Corespondenţa LINIE FACTURĂ
dinspre entitatea Factură (1, n)
o factură conţine cel puţin un material (cardinalitate minimă 1);
o factură poate conţine mai multe materiale (cardinalitate maximă n);
dinspre entitatea Material (1, n)
un material este inclus în cel puţin o factură (cardinalitate minimă 1);
un material poate fi inclus în mai multe facturi (cardinalitate maximă 1);
Corespondenţa 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 conţine cel puţin un material (cardinalitate minimă 1);
un bon de consum poate conţine mai multe materiale (cardinalitate maximă n).
Corespondenţa DESTINAT
dinspre entitatea Bon de consum (1, 1)
un bon de consum este destinat cel puţin şi cel mult unei magazii (cardinalitate
1, 1)
dinspre entitatea Magazie (1, n)
68
unei magazii îi este destinat cel puţin 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 construiește modelul conceptual al datelor (Figura 3.3)
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 prelucrării. Acestea se numesc restricţii de
integritate (RI). Ele pot fi structurale şi semantice, iar după momentul în care acţionează,
restricţiile de integritate sunt statice şi dinamice.
Restricţiile de integritate structurale sunt inerente conceptelor folosite la modelarea
datelor, în timp ce restricţiile de integritate semantice sunt introduse de utilizator pentru a
reflecta corect realitatea şi sunt expresia regulilor de gestiune aplicate în organizaţie, fiind o
FURNIZOR Cod furnizor Adresa Banca Cont
FACTURA
Nr factura
Data factura
se
storneaza
LINIE FACTURA
cant fact
primeste MAGAZIE
Cod magazie
Denumire magazie
Gestionar
destinat
BON DE CONSUM
Nr bon consum
Data
Den sectie
MATERIAL
Cod material
Den mat
Linie bon de comandă
emite 1,n 1,1 0,n
1,1 1,n
1,1
1,n 1,n
1,1
1,n
0,n
1,1
69
consecinţă a reglementărilor legislative şi normative în vigoare, cât şi a reglementărilor şi
normelor interne.
Restricţiile de integritate statice vizează starea sistemului informatic, independent de
timp, iar restricţiile de integritate dinamice privesc evoluţia în timp a datelor.
Restricţiile de integritate de domeniu sunt condiţii impuse asupra ansamblului de valori
acceptate pentru un atribut în cadrul tipului sau domeniului şi pot viza:
conţinutul unui atribut al aceleiaşi realizări;
corelaţii între valorile mai multor atribute ale aceleiaşi realizări;
corelaţii între atributele realizărilor mai multor entităţi diferite;
corelaţii între realizări distincte ale aceleiaşi entităţi.
Exemple de RI:
valorile atributelor cu rol de identificator trebuie să fie unice şi nenule;
existenţa unei asocieri este condiţionată de existenţa entităţilor participante (este vorba
de integritatea referenţială);
cardinalităţile minime şi maxime se stabilesc pe baza regulilor de desfăşurare a
activităţilor în sectorul vizat;
Exemplu:
0,n 1,1
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 restricţii de domeniu, cum ar fi:
data facturii să nu fie anterioară datei curente;
greutatea materialelor să fie cuprinsă în intervalul [0-500]
Corelaţii între atributele mai multor entităţi sau asocieri diferite, obţinute pe baza unor operaţii de
sintetizare (numărare, î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)
Furnizori emit Facturi
70
Client
se trimit se
primesc
Materiale Notă comandă
primeşte trimite
Incluziune de roluri
Se trimite Se primeşte
Fig. 3.4 Incluziunea de roluri
Excluziunea de roluri apare în situaţia în care rolurile ale aceleiaşi entităţi se exclud reciproc.
Simbol: r1 r2
Exemplu:
O agenţie imobiliară are ca obiect de activitate vânzarea - închirierea de apartamente. Pentru
evidenţa vânzărilor şi închirierilor trebuie să se ţină seama de faptul că un apartament nu poate
fi vândut şi închiriat în acelaşi timp, deci cele două roluri ale entităţii Apartament se exclud
reciproc. (Figura 3.5)
Apartament
Conţine
Cuprinde
#
Document încasare
Excluziune
de roluri
Se vinde Se închiriază
Se încasează Se încasează
Fig. 3.5 Excluziunea de roluri
71
Egalitatea de roluri înseamnă o resticţie de incluziune reciprocă între două roluri ale aceleiaşi
entităţi.
Simbol: r1 r2
Exemplu:
Un pensionar cu venituri mici plăteşte intreţinerea pentru apartamentul în care locuieşte
dar în acelaşi timp primeşte o subvenţie din partea statului pe timp de iarnă. Există egalitate
între roluri pe care entitatea Pensionar venituri mici le are în cadrul celor două
corespondenţe.(Figura 3.6)
Asemănător se stabilesc şi restricţiile de incluziune, excluziune şi egalitatea de asocieri
– dacă există sau care vizează atât asocierea (toate rolurile dintr-o asociere), cât şi toate
entităţile participante.
Dependenţe funcţionale
Presupunem că am proiectat o relaţie cu următoarea structură:
CLFACTURI(Nrf, Codc, Numec, Adresa, Dataf)
Observăm dependenţa atributelor Numec şi Adresa faţă de atributul Codc, şi de aici rezultă
că fiecare valoare a atributului Codc determină în mod univoc valoarea corespunzătoare a
celorlalte două atribute. Această structură (schemă de relaţie) introduce o redundanţă relativ la
atributele Numec şi Adresa, ale căror valori se repetă pentru fiecare factură a aceluiaşi client.
Această redundanţă conduce la următoarele anomalii:
la adăugare: nu se poate înregistra un potenţial client decît după ce se emite o factură
Pensionar venituri
mici
plăteşte primeşte
Întreţinerea Subvenţii
plăteşte
=
primeşte
egalitate
de roluri
Se reţine Se acordă
Fig. 3.6 Egalitate de roluri
=
72
pentru acesta;
la ştergere: dacă se şterg toate facturile emise pentru un anumit client se pierd toate
informaţiile despre acesta; ulterior, dacă acesta cumpără nişte produse, informaţiile pe
care tocmai le-am şters trebuie introduse din nou;
la modificare: dacă se modifică o informaţie despre un anumit client (numele, adresa),
este necesară parcurgerea întregii relaţii pentru a actualiza toate apariţiile acestui
client; în caz contrar apare pericolul introducerii unei inconsistenţe în baza de date
datorită faptului că pentru acelaşi client sînt înregistrate informaţii diferite.
Aceste anomalii pot fi evitate dacă se descompune relaţia CLFACTURI în două relaţii: CLIENTI
şi FACTURI, avînd structurile:
CLIENTI(Codc, Numec, Adresa)
FACTURI(Nrf, Codc, Dataf)
Un "dezavantaj" al descompunerii efectuate este acela că pentru a obţine informaţiile
despre un client pentru care am emis o factură este necesară efectuarea unei operaţii de
cuplare a celor două relaţii. Operaţia de cuplare (realizată printr-o instrucţiune Select care
extrage informaţii din cele două tabele) nu este atît de costisitoare pe cât ar putea părea la
prima vedere, dacă se aleg în mod corespunzător cheile primare şi modalităţile de indexare.
După cum rezultă din exemplul de mai sus problema alegerii unui model conceptual
corect pentru o bază de date relaţională este, de cele mai multe ori, formulată în termenii
determinării unor descompuneri pentru scheme de relaţii date, descompuneri care să izoleze
dependenţele existente şi prin aceasta să se evite anomaliile care decurg din ele.
Definiţia 1. Fie R(A1, A2,..., An) o relaţie, X şi Y două atribute (simple sau compuse) submulţimi
ale mulţimii de atribute (A1, A2,..., An). Atributul X determină atributul Y (sau Y depinde funcţional
de X) şi notăm XY dacă şi numai dacă orice valoare a atributului X determină în mod unic
valoarea atributului Y.
Observaţii:
dacă XY atunci pentru orice ZY avem XZ;
dacă XY atunci pentru orice VX avem VY.
Definiţia 2. Fie XY o dependenţă funcţională; spunem că avem dependenţă totală dacă nici o
submulţime VX nu induce o dependenţă funcţională VY; în caz contrar, dacă există o
submulţime VX care induce o dependenţă funcţională VY, spunem că avem dependenţă
parţială.
Existenţa în cadrul relaţiilor a dependenţelor funcţionale este un fapt natural. În orice
relaţie există o dependenţă funcţională a oricărui atribut faţă de atributul cheie (sau setul de
atribute care formează cheia primară): ştim că atributul cheie identifică în mod unic fiecare tuplu.
73
Dependenţele funcţionale existente în cadrul unei relaţii se datorează semanticii segmentului
din lumea reală care se modelează prin această schemă şi reprezintă restricţii referitoare la
realitatea modelată. Aceste restricţii constituie informaţii asociate relaţiei şi care nu pot fi
înglobate în reprezentarea relaţiei, deşi se reflectă indirect în această reprezentare prin valorile
concrete pe care le iau atributele relaţiei. Singura cale de a determina dependenţele funcţionale
din cadrul unei scheme de relaţie este aceea de a lua în considerare semnificaţia 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 soluţie informatică se face gradat,
luând în considerare un anumit tip de soluţie şi apoi, în cadrul tipului respectiv, o soluţie direct
implementabilă.
Expresia MCD în termenii unui anumit tip de soluţie informatică constituie modelul logic
al datelor (MLD)
MLD are asociate principii generale pentru gestionarea, respectiv definirea (structurarea)
datelor, manipularea şi asigurarea integrităţii datelor , fără să reflecte modul de reprezentare a
acestor date pe suportul de memorare.
MLD a cunoscut de-a lungul timpului mai multe generaţii, aşa cum se poate observa în
figura de mai jos (Figura 3.7):
Făcând o analiză a modelelor nerelaţionale comparativ cu modelul relaţional rezultă următoarele
avantaje în favoarea celui din urmă:
modelul relaţional este un model simplu care permite utilizatorului să vadă baza de date
ca o colecţie de tabele (relaţii) – o reprezentare mentală larg accesibilă atât
MLD
Fişier
Baze de date
SGBD
Ierarhizate
Reţea
Relaţionale
Orientate
obiect
Fig. 3.7 Evoluție MLD
74
informaticienilor cât şi neinformaticienilor;
asigură independenţa fizică şi logică a programelor de prelucrare faţă de structura
datelor, eliminând din schema conceptuală şi shemele externe toate detaliile privind
structura de memorare şi strategiile de acces;
operaţia de normalizare introdusă de modelul relaţional asigură găsirea structurii optime
a datelor prin înlăturarea anomaliilor de actualizare şi diminuare a redundanţei.
prin introducerea noţiunilor de dependenţă funcţională, dependenţă multivaloare şi
dependenţă joncţiune modelul relaţional depăşeşte stadiul limitat al reprezentării datelor
în calculator, avansând spre formalizarea elementelor de semantică ce guvernează
domeniul informaţiilor;
supleţe în comunicare prin intermediul limbajelor neprocedurale de nivel înalt.
MLD se obţine aplicând următoarele regulile de trecere de la MCD la MLD:
Fiecare entitate devine o relaţie. Identificatorul entităţii.devine cheia primară a relaţiei.
Atributele entităţii devin atribute ale relaţiei.
Asocierea non-ierarhică devine o relaţie. Atributele proprii ale asocierii (dacă există)
devin atribute ale relaţiei. Identificatorul asocierii.devine cheia primară a relaţiei, iar
identificatorii entităţilor participante la asociere devin chei externe. În cazul în care
asocierea nu are atribute, cheia primară se constituie prin concatenarea identificatorilor
entităţilor participante la asociere.
Asocierea ierarhică devine o legătură între relaţii. Concret, relaţia provenind din
entitatea pentru care cardinalităţile sunt 1,1 “absoarbe” identificatorul celeilalte entităţi,
care se transformă în cheie externă. Dacă se întâmplă ca asocierea să aibă proprietate
specifică, atributul respectiv este transferat şi devine câmp al relaţiei care provine din
entitatea cu cardinalitate maximă 1.
Modelul logic al datelor se poate prezenta astfel:
scriind numele relaţiei, 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, utilizând pentru relaţie simbolul din MCD pentru entitate, iar pentru evidenţa
legăturilor linii orientate; cheile primare şi externe se subliniază.
75
Exemplu de aplicare a regulilor de trecere de la MCD la MLD
Să considerăm modelul conceptual prezentat în Figura 3.3
Relaţiile obţinute din entităţi sunt: Factură, Furnizor, Magazie, Material, Bon de consum
Asocierile non-ierarhice Linie factură, Linie bon de consum se transformă în relaţii.
Relaţia Linie factură va avea cheia primară formată din concatenarea identificatorilor entităţilor
participante la relaţie (Număr factură, Cod material) şi proprietatea specifică asocierii ”Linie
factură” – (Cantitate intrată) care devine atribut al relaţiei. La fel se procedează şi în cazul
asocierii Linie bon de consum.
Asocierile ierarhice Emite, Primeşte, Destinat se transformă în legături şi transferă cheile
primare către relaţiile provenite din entităţi pentru care cardinalităţile sunt 1,1. Astfel, asocierea
Emite transferă din relaţia Furnizor cheia primară Cod furnizor în relaţia 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 ieşită)
Bon de consum (Nr bon de consum, Data bon de consum, Denumire secţie, Cod magazie)
Teste de evaluare a cunoștințelor
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
Furnizor
Cod furnizor
Denumire furnizor
Adresă furnizor
Cod fiscal
Banca
Cont
Factură
Număr factură
Dată factură Cod furnizor
Cod magazie
76
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 forţele interesate în dezvoltarea sistemelor: utilizatorii cheie, managerii şi analiştii de sistem implicaţi în analiza sistemului curent. Din acest punct de vedere fiind similar interviului la nivel de grup. Totuşi, se urmează o anumită secvenţă de derulare a activităţilor 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
interese comune; e. Prototipizarea.
c. RAD (Rapid Application Development).
4. ...................... este un proces iterativ prin care analiştii şi utilizatorii pun în discuţie o versiune rudimentară a unui sistem informaţional, care va fi într-o continuă schimbare, în funcţie de reacţia utilizatorului. a. Sesiunile JAD (Joint Application Design); d. Sistemele de sprijinire a grupurilor de
lucru; b. Intervievarea grupurilor de oameni cu
interese comune; e. Prototipizarea.
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
interese comune; e. Prototipizarea.
c. RAD (Rapid Application Development);
77
6........................ evidenţiază, la nivel conceptual, modul de structurare a datelor şi a legăturilor dintre ele. Cea mai utilizată tehnică este entitate-asociere. a. Modelarea proceselor; d. Analiza asocierilor; b. Analiza dinamică; e. Analiza funcţională. c. Analiza structurală;
7. ......................... evidentiază comportamentul elementelor sistemului la anumite evenimente. Una dintre tehnicile utilizate este diagrama stare-tranziţie. a. Modelarea proceselor; d. Analiza asocierilor; b. Analiza dinamică; e. Analiza functionala. c. Analiza structurală;
8........................... evidenţiază modul de asigurare a cerinţelor informa-ţionale (fluxul prelucrărilor) din cadrul sistemului, prin care intrările sunt transformate în ieşiri. Cea mai utilizată tehnică este diagrama de flux a datelor. a. Modelarea proceselor; d. Analiza asocierilor; b. Analiza dinamică; e. Analiza funcţională. c. Analiza structurala;
9. Considerând următorul MCD caracterizat prin faptul că ne confruntăm cu furnizori
specializaţi, aceştia putând livra doar o singură materie primă, livrarea realizându-se doar o singură dată:
10. Stabiliţi care este cardinalitatea pentru asocierea celor 2 tipuri de entităţi Furnizori-Materii prime:
a (n,1) - (1,1) b. (0,0) - (0,n) c. (1,1) - (1,1) d. (0,n) - (0,n) e. (0,1) - (0,n)
78
79
Capitolul 4
Proiectarea logică și fizică sistemelor informatice
Obiective:
Însușirea noțiunilor de bază legate de arhitectura şi specificaţiile logice ale sistemului informatic
Delimitarea componentelor sistemului informatic din punct de vedere structural și funcțional
Stabilirea necesarului de resurse şi a modului de implementare hardware şi software pentru noul
sistem informatic
Cuvinte cheie: proiectare logică, proiectare fizică, normalizarea relațiilor, formalizarea
atributelor, codificarea atributelor
Procesul de proiectare este o etapă importantă în realizarea sistemelor informatice, ea
urmând etapelor de investigare şi de modelare a sistemului informatic. În cadrul ei, utilizând
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 obţinute din analiza şi
interpretarea modelelor noului sistem informatic. Analiştii evaluează şi revizuiesc modelele
pentru a obţine specificaţiile logice de sistem, specificaţii care descriu în detaliu funcţiile
sistemului informatic şi care vor sta la baza soluţiilor tehnice alese de proiectant.
În funcţie de strategia de proiectare aleasă: proiectare structurată, proiectare orientată obiect,
prototipizarea, JAD (Join application development), RAD (Rapid application development)3,
activităţile 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
realizându-se un studiu detaliat şi un studiu tehnic.
Studiul detaliat se bazează pe rezultatele investigării şi presupune obţinerea specificaţiilor
funcţionale generale detaliate ale noului sistem.
Specificaţiile cuprind:
3 - https://en.wikipedia.org/wiki/Rapid_application_development
4 Merise Method and knowledge, www.cmi.univ-mrs.fr
80
Schema organizatorică;
Prezentarea activităţilor, proceselor din cadrul unităţii economice;
Prezentarea procedurilor utilizate pentru realizarea procedurilor;
Prezentarea sarcinilor manuale, total sau parţial automatizate;
Lista resurselor umane şi materiale implicate cu alocarea pe sarcini;
Prezentarea situaţiilor de ieşire;
Lista echipamentelor utilizate.
Studiul tehnic presupune proiectarea logică şi tehnică a bazei de date, descrierea arhitecturii
prelucrării 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 următoarelor activităţi:
- Descompunerea în subsisteme informatice. Subsistemele informatice obţinute sunt
formate dintr-un ansamblu de operaţii, evenimente, asocieri, mesaje, având o interfaţă
fixă cu restul sistemelor.
- Identificarea subsistemelor informatice concurente. Subsistemele informatice
concurente sunt identificate în scopul optimizării implementării prin utilizarea aceleaşi
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 prelucrărilor.
- Stabilirea condiţiilor limită, care se referă la iniţializări, terminarea normală sau
anormală, priorităţi.
Rezultatul proiectării sistemului informatic constă în realizarea arhitecturii de bază a
sistemului informatic şi elaborarea unor decizii la nivel global.
Proiectarea obiectelor rafinează modelele obţinute în faza de analiză, prin adăugarea detaliilor
de implementare. În cadrul acestei etape se desfăşoară următoarele activităţi:
identificarea operaţiilor;
proiectarea algoritmilor;
rafinarea, restructurarea modelului datelor;
implementarea controlului;
implementarea asocierilor;
gruparea datelor şi asocierilor în module.
81
Rezultatul acestei etape este detalierea celor trei modele: modelul obiectelor, modelul
dinamic şi funcţional.
Se poate observa că, indiferent de strategia de proiectare adoptată, activităţile principale pentru
proiectarea unui sistem informatic sunt:
stabilirea arhitecturii sistemului informatic /subsistemului informatic;
proiectarea listelor / situaţiilor de ieşire;
proiectarea bazei informaţionale;
proiectarea interfeţei cu utilizatorii;
proiectarea programelor.
În literatura de specialitate, aceste activităţi sunt grupate, conform gradului de detaliere, în
două categorii , care reprezintă de fapt, etapele proiectării sistemelor informatice: proiectarea de
ansamblu / generală / logică şi proiectarea de detaliu / fizică.
În cadrul proiectării de ansamblu / generale / logice se elaborează modelul de
ansamblu a sistemului informatic, adică se stabileşte ce trebuie sa se construiască şi care sunt
specificaţiile logice ale sistemului informatic.
Proiectarea de detaliu / fizică detaliază componentele sistemului informatic, arată cum
trebuie să fie construite şi cum să funcţioneze în mediul real, în funcţie de resursele disponibile.
4.1 Proiectarea de ansamblu / generală / logică
Proiectarea de ansamblu îşi propune să definească sistemul informatic din punct de
vedere funcţional şi structural. Aceasta înseamnă că se identifică componentele, după care se
vor descrie atât din punct de vedere structural, cât şi funcţional.
Structura de ansamblu a unui sistem informatic e formată din intrări, ieşiri şi prelucrări. (Figura
4.1)
PRELUCRĂRI
Documente
justificative SGBD Rapoarte
Intrări Ieşiri
Proceduri
Figura 4.1 Structura de ansamblu a unui sistem informatic
82
Intrările sunt reprezentate de:
tranzacţii externe care redau dinamica operaţiilor economice, provin din exteriorul
sistemului informatic electronic de calcul şi sunt furnizate de proceduri automate.
Exemplu: înregistrarea unei operaţii de aprovizionare cu marfă;
tranzacţii interne care redau modificările 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.
Prelucrările sunt asigurate de un ansamblu de proceduri automate care realizează actualizarea
şi exploatarea colecţiilor de date ca urmare a tranzacţiilor interne şi externe în vederea obţinerii
rapoartelor, listelor, situaţiilor de ieşire ale sistemului informatic.
Ieşirile sistemului informatic sunt rezultatul prelucrării bazei de date şi sunt redate în funcţie de
conţinutul lor şi de structura lor sub formă de indicatori sintetici, rapoarte, liste, situaţii de ieşire,
grafice, stocare pe suporturi.
Schema structurală a unui sistem informatic pune în evidenţă triada intrări prelucrări ieşiri.
Pentru determinarea necesarului de date de intrare se utilizează mai multe metodologii care
determină anumite variante de abordare a proiectării de ansamblu.
Astfel, în funcţie de complexitatea obiectivelor stabilite, de aria de cuprindere a noului sistem
informatic, de posibilităţile de modificare a ieşirilor, de costurile şi termenele de realizare a
sistemului informatic, se folosesc următoarelor variante de abordare a proiectării de ansamblu:
Prima variantă de abordare, pe baza principiului ieşiri-intrări asigură determinarea
conţinutului bazei informaţionale în funcţie de obiectivele stabilite de unitatea beneficiară. În
această variantă ieşirile sunt reflectate de obiectivele informaţionale solicitate, în timp ce intrările
sunt reflectate de conţinutul bazei informaţionale.
Avantajul acestei metode constă în furnizarea unui conţinut complet al bazei
informaţionale determinată iniţial şi pe baza stabilirii listelor de ieşire.
Dezavantajul este legat de imposibilitatea emiterii de noi situaţii de ieşire, deoarece
varianta nu poate genera la ieşire decât conţinutul bazei informaţionale De asemenea, nu poate
genera alţi indicatori rezultaţi ca urmare a aplicării unui algoritm de calcul asupra conţinutului
bazei informaţionale.
83
A doua variantă, pe baza principiului intrări - ieşiri determină conţinutul bazei
informaţionale independent de ieşirile solicitate urmând să se asigure atât cerinţele imediate cât
de perspectivă.
Avantajul constă în determinarea unei baze informaţionale complete, cu menţiunea
însă că unele atribute nu vor fi poate niciodată utilizate în prelucrările sistemului informatic.
Dezavantajul rezidă din cheltuielile mari de realizare a bazei informaţionale, cheltuieli
determinate de studierea tuturor activităţilor desfăşurate şi de supradimensionarea acesteia.
A treia variantă, mixtă îmbină avantajele celor două variante prezentate şi le
minimizează dezavantajele.
În practica economică, datorită vehiculării unui număr foarte mare de documente de intrare, la
proiectarea sistemelor informatice se foloseşte varianta de abordare pe baza principiului ieşiri -
intrări
Activităţile desfăşurate în cadrul proiectării de ansamblu sunt:
stabilirea obiectivelor noului sistem informatic.
proiectarea rapoartelor, listelor, situaţiilor de ieşire
proiectarea bazei informaţionale.
Stabilirea obiectivelor sistemului informatic
Obiectivele sistemului informatic reprezintă scopuri imediate şi de perspectivă care vor
determina structura, funcţionalitatea şi conexiunile noului sistem informatic şi care vor asigura
minimizarea perturbaţiilor apărute în desfăşurarea activităţilor, contribuind astfel la maximizarea
eficienţei economice şi a rentabilităţii unităţii beneficiare.
Determinarea obiectivelor noului sistem are la bază ideea potrivit căreia acest sistem
este dedicat procesului decizional, deoarece numai cu un management performant se pot obţine
efecte economice ridicate, cu eforturi cât mai reduse.
Din acest motiv, obiectivele unui sistem informatic pot fi grupate în două categorii:
Obiective generale ce trebuie să asigure cunoaşterea exactă şi operativă a activităţii
desfăşurate de unitatea economică;
Obiective specifice care vor sigura condiţiile necesare realizării obiectivelor generale.
Obiective generale
Obiectivele generale ale unui sistem informatic urmăresc generarea şi furnizarea operativă
şi selectivă, către toate nivelele de conducere, a unor date cu caracter strategic, tactic, operativ
şi funcţional, pentru asigurarea atributelor conducerii şi ale funcţiilor unităţilor economice. În
raport de aceste aspecte, obiective generale pot fi:
de conducere (manageriale);
84
funcţionale.
Obiectivele de conducere vizează probleme cu caracter global şi structural, de conducere ale
unităţii economice şi se axează pe:
realizarea în condiţii de maximă eficienţă a întregii activităţi;
realizarea globală şi structurală a indicatorilor economico-financiari (cifra de afaceri,
valoarea adăugată, profitul brut şi net, capitalul propriu, capacitatea de plată, rata
rentabilităţii, eficienţa utilizării fondurilor fixe etc.), calculul şi planificarea „rezultatelor”,
planificarea financiară a investiţiilor, previzionarea activelor circulante şi a surselor de
finanţare, previzionarea activităţii de trezorerie, inclusiv utilizarea bugetului general al
unităţii economice;
perfecţionarea structurilor şi a activităţii de producţie în vederea asigurării unui optim
global;
asigurarea unui fundament informaţional superior pentru fundamentarea şi
implementarea strategiilor şi politicilor unităţii economice;
realizarea unei funcţionalităţi superioare de ansamblu a sistemului decizional;
facilitarea introducerii şi utilizării anumitor tehnici, metode şi sisteme manageriale;
degrevarea conducerii de procesele decizionale de rutină, formalizarea prin noul sistem
a informaţiilor sintetice necesare derulării relaţiilor informaţionale cu organismele de stat
şi cu alte regii autonome sau societăţi comerciale;
creşterea operativităţii şi gradului de fundamentare şi adoptare a deciziilor.
Obiectivele funcţionale au în vedere informatizarea activităţilor esenţiale şi specifice ale unităţii
economice în vederea asigurării funcţiilor sale fundamentale: cercetare-dezvoltare, comercială,
producţie sau exploatare, financiar- contabilitate, personal.
1. Activitatea de cercetare-dezvoltare vizează strategiile de dezvoltare a produselor şi
tehnologiilor precum şi cele de dezvoltare a unităţii economice în ansamblul său. Informatizarea
acestor activităţi presupune informatizarea următoarelor subactivităţi:
proiectare produselor;
proiectarea în domeniul tehnologiilor şi echipamentelor;
determinarea capacităţii de producţie ş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 producţie desfăşurată în cadrul unor compartimente are în vedere elementele
specifice fiecărei subactivităţi, din punct de vedere informatic, după cum urmează:
definirea ingredientelor şi proceselor ce sunt utilizate în producţia continuă;
definirea secţiilor, operaţiilor şi ordonarea lor, care intervin în fabricarea unui produs;
85
definirea materialelor şi (sub)ansamblelor folosite pentru fabricarea unui produs;
gestiunea calităţii;
previziunea produselor;
program de producţie;
planificarea cerinţelor materiale;
planificarea cerinţelor capacităţii;
planificarea cerinţelor de manoperă;
planificare resurse.
3. Activitatea comercială este reprezentată prin trei subactivităţi: aprovizionare, desfacere,
marketing. Sistemul informatic va trebui sa soluţioneze optim următoarele aspecte specifice:
Subactivitatea de aprovizionare
determinarea necesarului de resurse materiale şi energetice;
contractarea necesarului de aprovizionat.
Subactivitatea de desfacere
situaţia necesarului de livrat conform contractelor;
situaţia cantitativ şi valorică a livrărilor ;
urmărirea ritmicităţii livrărilor în scopul onorării contractelor.
Subactivitatea de marketing
1. studierea caracteristicilor tehnico-economice, inclusiv a tehnicilor de comercializare a
produselor concurente, furnizate de alte societăţi comerciale din tară sau străinătate;
2. evoluţia pieţelor de desfacere în vederea realizării relaţiilor valutar-financiar şi de
distribuire a produselor proprii;
3. cooperarea cu alte societăţii comerciale din ţară sau străinătate în vederea promovării
produselor pe terţe pieţe
4. Activitatea financiar-contabilă desfăşurată în cadrul compartimentelor specifice presupune
rezolvarea din punct de vedere informatic a unor elemente specifice după cum urmează:
Subactivitatea financiară
elaborarea bugetului general al unităţii economice pe an financiar, şi desfacere pe
subunităţi.
gestiunea creditului clienţi pune în evidenţă sumele datorate de clienţi, ce rezultă din
datele generate de cumpărările şi plăţile acestuia;
gestiunea numerarului colectează informaţii privind toate intrările şi ieşirile de numerar
din organizaţie, în mod periodic sau chiar în timp real.
gestiunea portofoliului (titlurilor) de plasament evidenţiază surplusul de numerar investit
în hârtii de valoare pe termen scurt (fie cu un grad de risc scăzut-bonuri de tezaur,
certificate de trezorerie, fie cu un grad de risc mai ridicat dar şi cu posibilităţi mai mari
86
de câştig), astfel încât sumele rezultate să poată fi disponibile atunci când sunt
necesare fonduri.
Subactivitatea contabilă se desfăşoară în două circuite:
Contabilitatea financiară (sintetică), reflectă starea patrimonială a unităţii economice
prin intermediul activului, datoriile (obligaţiile), capitalul propriu şi rezultatele nete
obţinute pe parcursul unei perioade de gestiune.
Contabilitatea de gestiune (analitică), oferă informaţii care reflectă cheltuielile şi
veniturile pe purtători de valoare şi resursele repartizate spre gestionarea la nivelul
fiecărei structuri organizatorice.
Subactivitatea de control financiar, la nivelul unităţii economice urmăreşte analiza şi controlul
gestiunii patrimoniului regiei automate sau societăţii comercială prin instrumente proprii, în
scopul prevenirii şi sesizării încălcării normelor legale de utilizare a resurselor umane, materiale
şi băneşti.
5. Activitatea de personal acoperă întreaga gamă de activităţii legate de evidenţa personalului,
salarizarea, perfecţionarea calificării personalului şi presupune rezolvarea sub aspect informatic
a următoarelor sarcini:
Subactivitatea de evidenţă a personalului trebuie să asigure:
evidenţa personalului pe meserii, în funcţie de vechime, pe locuri de muncă, pe diferite
intervale de timp;
verificarea încadrării personalului pe meserii, funcţii şi locuri de muncă;
evidenţa mişcării de personal (angajării, promovări, transferări, pensionari, concedii)
Subactivitatea de salarizare asigură:
înregistrarea orelor lucrate pe baza fişelor de partaj sau a foilor colective de prezenţă,
prin care se determină numărul orelor care va fi luat în calcul la stabilirea salariilor
pentru o lună. Poate să apară situaţia în care se vor folosi fişele de manoperă;
calculul drepturilor salariale se particularizează în funcţie de modul de plată al fiecărei
organizaţii;
evidenţierea obligaţiilor de plată ale salariaţilor, fie sub forma impozitelor şi contribuţiilor
fie sub forma reţinerilor datorate către firme sau bănci.
Subactivitatea de perfecţionare a calificării personalului se particularizează de la o firmă la alta,
în funcţie de specificul obiectivului de activitate şi de criteriile de evaluare stabilite la nivelul
politicii de personal şi urmăreşte:
performanţele salariaţilor, pe faza unor criterii de evaluare stabilite în funcţie de
specificitatea activităţii desfăşurate. Pe baza evaluărilor de performanţe conducerea
poate stabili nivelul salariului pentru fiecare angajat, posibilitatea de promovare,
necesităţile de instruire ş.a.
87
înregistrarea pregătirilor profesionale şi a instruirilor la care au participat salariaţii,
urmărindu-se prelucrarea datelor necesare elaborării programului de îmbunătăţire a
aptitudinilor şi performanţelor profesionale ale salariaţilor;
stabilirea priorităţilor în angajarea a noi categorii de salariaţi, astfel încât activitatea
unităţii economice să se desfăşoare, la cel mai înalt grad de tehnicitate.
Obiectivele specifice
Obiectivele specifice asigură condiţiile realizării obiectivelor generale şi trebuie să ţină seama de
aspectele concrete din realitatea unităţii economice studiate, cum ar fii:
mărimea unităţii economice;
structura sa organizatorică;
ponderea acesteia într-o ramură de activitate;
gradul de participare al unităţii economice la derularea operaţiunii de export-import,
cooperarea internaţională;
alte elemente ce pot conduce la alte tipuri de obiective cu o nuanţare specifică.
Obiectivele generale şi specifice ale unui sistem informatic pot urmări şi alte aspecte, cum ar
fi:
asigurarea proiectării automate a datelor în condiţii de eficienţă economică;
optimizarea fluxurilor şi circuitelor informaţionale;
furnizarea automată a informaţiilor cu caracter sintetic şi analitic destinate conducerii şi
structurilor organizatorice pentru crearea condiţiilor informaţionale necesare realizării
obiectivelor de conducere, tehnologice şi informatice;
utilizarea eficientă a unităţilor centrale a calculatoarelor printr-o alocare dinamică a
spaţiului de memorie;
realizarea celei mai adecvate si operative metode de introducerea datelor în vederea
minimizării timpului de încărcare a colecţiilor de date, în vederea obţinerii la termenele
stabilite a tuturor situaţiilor de ieşire în care se concretizează obiectivele noului sistem.
Proiectarea rapoartelor/listelor/situaţiilor de ieşire
Datele de ieşire sunt informaţii livrate de sistemele de prelucrare autonomă a datelor
utilizatorului sub forma unor mesaje, rapoarte, grafice etc.
Ieşirile noului sistem informatic sunt stabilite de către conducerea unităţii economice, în
colaborare cu echipa de realizare a sistemului, ca urmare a analizei obiectivelor sistemului
proiectat, în proiectarea lor ţinându-se seama de următoarele aspecte:
88
1) Destinaţia situaţiei şi momentul când se estimează, se poate obţine nivelul de
detaliere al informaţiei, respectiv informaţii mai analitice pentru nivele de bază şi mai sintetice la
nivelele superioare.
2) Existenţa în situaţie a tuturor informaţiilor necesare, avându-se în vedere în acelaşi
timp, ca pe cât posibil, o informaţie să nu apară inutil în mai multe situaţii.
Structura informaţională şi formatul ieşirii sunt determinate, în principiu, de următoarele reguli:
respectarea specificaţiilor cadrului legislativ în vigoare
proiectarea se va face în concordanţă cu activităţile specifice obiectivelor sistemului;
conţinutul va fi redat sintetic sau analitic şi cu o frecvenţă precizată în legislaţie;
Formatul de afişare, dispozitivul periferic folosit şi beneficiile ieşirilor sistemului informatic sunt
stabilite în raport cu solicitările sistemului de management, sistemului operant, sistemelor
informatice externe.
Criteriile utilizate pentru determinarea formatului, conţinutului, dispozitivului periferic şi
beneficiarilor ieşirilor noului sistem, au impus structurarea acestora în următoarele categorii:
A. Rapoartele/listele/situaţiile de ieşire conţin indicatori sintetici şi analitici, al căror conţinut
reflectă starea, dinamica şi tendinţa 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 informării operative şi demersului decizional.
C. Graficele redau sub formă sinoptică starea şi evoluţia unui fenomen economico-financiar în
scopul informării conducerii sau compartimentelor unităţii economice, adoptării unor decizii
operative, prin care să asigure fenomenul de feed – back al activităţii economico-financiare
analizate.
D. Ieşirile către alte sisteme sunt de fapt transmisii de date on-line, prin intermediul unei reţele
locale de calculatoare, sau off-line, prin intermediul suporturilor magnetice(disc flexibil, disc
magnetic, bandă magnetică).
A. Rapoarte/liste/situaţii de ieşire
Rapoartele de ieşire reprezintă modul de concretizare practică a obiectivelor noului sistem, fiind
caracterizate prin următoarele elemente:
a1. tipologia rapoartelor
a2.structura informaţională
a3. realizarea rapoartelor
Schematic elementele ce caracterizează rapoartele sunt:
89
a1 Tipologia rapoartelor
Rapoartele/listele/situaţiile de ieşire ce urmează a se obţine în cadrul unui sistem informatic
pot fi clasificate în funcţie de o serie de factori obiectivi şi subiectivi cum ar fi:
După caracterul informaţiilor conţinute:
- liste cu caracter omogen specifice fiecărei activităţi (de exemplu, pentru activitatea
financiar contabilă putem întocmi situaţia “Balanţa de verificare”)
Unitatea……….
Balanţă de verificare
La data de …………… pag………
Simbolul conturilor
Denumire Sold precedent
Rulaje luna curentă
Sold final
D C D C D C
TOTAL *** *** *** *** *** ***
Întocmit, După destinaţie:
liste/situaţii de ieşire pentru alte sisteme informatice. Acestea asigură raportările şi
informările periodice cu privire la stadiul de realizare a indicatorilor tehnico-economici şi
au caracter de obligativitate pentru orice unitate economică(dări de seamă statistice şi
contabile, bilanţul contabil, bugetul de venituri şi cheltuieli);
Tipologia rapoartelor 1) specificul funcţiei - R pentru funcţia dezvoltare - R pentru funcţia producţie - indicatorii pentru funcţia comercială - R pentru funcţia Financiar-Contabilă - R pentru funcţia Personal 2) Mod de utilizare - R de stare - R statistice - R previzionale 3) Destinaţie - R. interne - R. externe 4) Grad de sintetizare date - R sintetice - R analitice
Structura informaţionala Antet
Titlu
Subiect
Predicat
Toatalizări
Algoritm de calcul
Disciplina informaţională
Viziuni de realizare Utilizatori
format tabelar SGBD
raport import calcul tabelar Excel, Lotus Sisteme de operare
specificator de fişier
(x.frm, x.frx)
90
liste/situaţii de ieşire destinate sistemului informatic propriu. Prin informaţiile furnizate
se asigură urmărirea curentă a desfăşurării activităţilor şi conducerea operativă în
vederea luării deciziilor eficiente.
După gradul de sintetizare a datelor:
liste/situaţii de ieşire cu caracter sintetic: cuprind date şi indicatori globali de urmărire şi
control a activităţii, fiind utilizate la conducerea de ansamblu a activităţii(de exemplu,
pentru activitatea financiar contabilă putem întocmi situaţia “Balanţa de verificare
sintetică”);
Unitatea……….
Balanţă de verificare
La data de …………… pag………
Simbolul conturilor
Denumire Sold iniţial Mişcare Sold final
D C D C D C
TOTAL RULAJ
*** *** *** *** *** ***
TOTAL SOLD
*** *** *** *** *** ***
Întocmit,
liste/situaţii de ieşire cu caracter analitic: cuprind datele şi indicatorii la nivel de detaliu
pentru elementele patrimoniale ale unităţii, operaţiilor economice legate de fondurile
unităţii şi circulaţia acestora(de exemplu: Situaţia contului analitic)
Unitatea………. Situaţia contului analitic nr…..
La data de …………… pag……… Debit Credit Sold iniţial *** ***
Număr Operaţii Cont corespondent Nr. Doc.
Data
*** *** *** *** *** *** ***
Total Tranzacţii: Sold actual:
*** ***
După modul de utilizare:
liste/situaţii de ieşire cu caracter de stare: conţin date ce reflectă elementele de
patrimoniu ale unităţii, date care evidenţiază nivelul şi disponibilul de resurse materiale
şi băneşti la un moment dat(de exemplu balanţa analitică a valorilor materiale);
91
liste/situaţii de ieşire cu caracter statistic cuprind date ce reflectă mai multe perioade
anterioare de activitate pentru a putea compara tendinţele evolutive sau involutive a
fenomenelor economice (de exemplu Dările de seamă statistice);
liste/situaţii de ieşire cu caracter previzional grupează date pe perioada în curs şi
reflectă siuaţia fenomenelor şi proceselor economice la nivelul unităţii. În funcţie de
această situaţie se vor stabili obiectivele de dezvoltare .
După intervalul de referinţă:
liste/situaţii de ieşire cu caracter operativ: sunt elaborate la frecvenţe mici de
prelucrare(schimb, zi, decadă) şi conţin date operative cu un grad redus de prelucrare,
necesare conducerii prin excepţie, deoarece prin conţinutul lor semnalează aspectele
pozitive sau negative de desfăşurare a activităţii(rapoarte de control al realizării
sarcinilor)
Unitatea………… Cod situaţie………
Serviciul…………
Fişă de urmărire operativă
a aprovizionării în luna………….
Materialul………………
Cod…………………….
Caracteristici………….
Preţ unitar……………..
Stoc normat……………
Stoc de siguranţă……….
Valoare………………….
SITUAŢIA SINTETICĂ
Dat
a
Necesar de aprov.
Contracte Alte surse Total acoperit
Modificări Obs.
92
liste/situaţii de ieşire cu caracter operativ: sunt elaborate la frecvenţe mai mari de timp
deoarece conţin date sintetice ce caracterizează evoluţia de ansamblu a proceselor şi a
fenomenelor economice. Acestea se caracterizează prin termene fixe de elaborare şi
sunt destinate anumitori factori de decizie, compartimente funcţionale sau altor sisteme
informaţionale (de exemplu: registru jurnal)
Unitatea………. Registrul - Jurnal
Nr. crt.
Data înreg.
Document Explicaţii Conturi Sume
D C D C
Report *** ***
De reportat: TOTAL GENERAL
*** ***
Întocmit, Verificat,
După modul de obţinere:
liste / situaţii de ieşire obţinute la imprimantă: se folosesc ca documente justificative şi
se îndosariază şi arhivează după consultarea datelor conţinute;
liste / situaţii de ieşire obţinute la videoterminal: se folosesc când nu este necesară
arhivarea documentelor, dar se folosesc pentru informările operative din sistemul
informaţional al unităţii(graficul de urmărire zilnic al materialelor aprovizionate).
liste / situaţii de ieşire obţinute pe suport magnetic: sunt utilizate pentru păstrarea
temporară, cu posibilitatea imprimării, multiplicării sau vizualizării;
liste / situaţii de ieşire obţinute la teletransmisie prin cuplarea a două reţele de
calculatoare în vederea listării, imprimării, vizualizării la o altă unitate economică.
SITUAŢIA ANALITICĂ
Fur
nizo
ri
Comenzi Contracte Term livrare
Modificări
Obs
Data Cant Data Cant Cant Doc Cant Doc
93
Forma listelor / situaţiilor de ieşire va trebui să fie simplă, concisă şi clară, fără amănunte
nesemnificative care ar îngreuna utilizarea lor.
În definitivarea conţinutului şi formei situaţiei de ieşire trebuie urmărită şi valorificarea cât mai
deplină a posibilităţilor oferite de sistemul electronic de calcul prin asocierea introducerii
sistemului informatic cu utilizarea conducerii prin excepţie şi eventual cu utilizarea unor decizii
programate.
a2 Structura informaţională
Indiferent de tipologia raportului, acesta trebuie să redea datele şi informaţiile sub o formă
inteligibilă, concisă şi sugestivă, ceea ce impune omiterea detaliilor nesemnificative ce nu
corespund scopului propus.
Structura informaţională conţine următoarele elemente:
Antetul raportului este redat sub numele unităţii economice pentru care se elaborează
raportul, însoţit de codul raportului;
Titlul raportului indică în mod sintetic conţinutul său informaţional, precum şi data sau
perioada calendaristică la care se referă informaţiile din raport;
Subiectul raportului prezintă efectiv conţinutul informaţional şi este format din:
număr pagini de raport;
secvenţă de atribute, ordonate de la stânga la dreapta, prin intermediul unor coloane.
Predicatul raportului este format din mulţimea finită a rândurilor de detaliu completate cu valori
reale pentru atributele specificate în rândul curent, completare realizată prin intermediul unor
proceduri automatizate;
Totalizarea înseamnă realizarea unor grade de total general şi, uneori, de subtotaluri pentru
1,2…n atribute, numai în situaţia când există o relaţie de subordonare ierarhică a atributelor;
Algoritmii de calcul reiau în mod implicit sau explicit relaţiile sau funcţiile financiare, statistice sau
de sistem pentru calculul unor indicatori cu caracter financiar contabil.
Realizarea rapoartelor
La definitivarea fiecărei situaţii de ieşire trebuie să se precizeze modul practic de utilizare a
viitoarei situaţii, prin următoarele elemente:
funcţia pentru care este dedicat modelul raportului (de exemplu funcţia financiar-
contabilă);
activitatea: este reprezentată de o parte componentă a unei funcţii, materializată prin
raportul respectiv (de exemplu activitatea contabilitate generală);
compartimente beneficiare: sunt structurile organizatorice care vor primi respectivul
94
raport (de exemplu Contabilitatea);
numărul de exemplare este stabilit în funcţie de numărul compartimentelor beneficiare;
frecvenţa este reprezentată de ritmicitatea elaborării respectivului raport;
termenul reprezintă data limită la care trebuie obţinut respectivul raport, fiind stabilit în
funcţie de frecvenţa prestabilită;
dispozitivul periferic de ieşire :este reprezentat simbolic perifericul respectiv.
Mai jos exemplificăm structura şi disciplina informaţională a unui raport.
Structura informaţională
Unitatea… Cod…..(antet) Balanţa de verificare la data de …………. (titlu)
Cont Sold iniţial Mişcare Sold final D C D C D C *** *** *** *** *** *** *** Total
Rulaj /c.s *** ***
Grad 1
Total sold/c.s
*** ***
Grad 1
***
Disciplina informațională
B. Indicatorii sintetici specifici unităţii economice au rolul de a caracteriza din punct de vedere
sintetic şi analitic activitatea economico-financiară prin intermediul unor informaţii care redau:
patrimoniul net al regiei autonome sau a societăţii comerciale prin intermediul
inventarierii patrimoniului şi a posturilor din bilanţul contabil elaborate la finele perioadei
de gestiune;
starea şi rezultatele economico-financiare ale unităţii economice pe o perioadă
determinată de gestiune;
calculul şi planificarea financiară a investiţiilor;
Funcţie : Fin-contabil
Activitate : contab generala
Compartimentele beneficiare : contabilitati, gestiuni
Numărul de exemplare : 2
Frecventa : lunar
Termen : 1 – 5
Dispozitiv periferic de ieşire : fişier, imprimanta
95
calculul şi planificarea rezultatelor economico-financiare;
calculul şi previzionarea activelor circulante şi surselor de finanţare;
calculul şi previzionarea activităţii de trezorerie.
Indicatorii sintetici sunt caracterizaţi de următoarele elemente:
b1 tipologia indicatorilor sintetici
b2 structura informaţională
b3 realizarea indicatorilor sintetici
Schematic elementele ce caracterizează indicatorii sintetici sunt:
b1 Tipologia indicatorilor sintetici
Selectarea tipurilor de indicatori sintetici obţinuţi în cadrul unui sistem informatic se face în
funcţie de :
1) Specificul funcţiei:
indicatorii pentru funcţia dezvoltare
indicatorii pentru funcţia producţie
indicatorii pentru funcţia comercială
indicatorii pentru funcţia Financiar - Contabilă
indicatorii pentru funcţia personal
2) Mod de utilizare:
indicatori cu date de stare
Tipologie 1) specificul functiei - indicatorii pentru functia dezvoltare - indicatorii pentru functia producţie - 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
Zone aditionale
Viziuni de realizare
Utilizatori format eticheta SGBD
report import calcul tabelar excel, lotus Sisteme de operare - specificator de fisier
(x.lbl)
96
indicatori cu date statistice
indicatori cu date previzionale
3) Tipul evidenţei
indicatori cu date de sinteza
indicatori din evidenţa operativ contabilă
indicatori cu date din evidenţa statistică
b2 Structura informaţională
Indiferent de tipologia raportului, acesta trebuie să redea datele şi informaţiile sub o formă
concisă şi sugestivă.
Structura informaţională conţine următoarele elemente:
Antetul indicatorului sintetic este redat sub numele unităţii economice pentru care se
elaborează indicatorul, însoţit de codul indicatorului;
Titlul indicatorului sintetic în mod sintetic conţinutul său informaţional, precum şi data
sau perioada calendaristică la care se referă informaţiile conţinute de indicator;
Zona fixă prezintă efectiv conţinutul informaţional şi este format din: secvenţă de
atribute, ordonate de la stânga la dreapta, prin intermediul unor coloane.
Zona variabilă este formată din mulţimea finită a rândurilor de detaliu completate cu
valori reale pentru atributele specificate în rândul curent, completare realizată prin
intermediul unor proceduri automatizate;
Zona adiţională redă informaţii 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
ZONE FIXE
..............................................................................................................................................................................................................................................................................................................................................................................................................................................................................
............VARIABILE
DATA AFIŞĂRII……………….ECONOMIST………
ZONE ADIŢIONALE
97
b3 Realizarea indicatorilor sintetici trebuie să respecte aceleaşi 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 evoluţia unui
fenomen în timp, dacă datele se rferă la perioade temporale succesive mari (luni, trimestre, ani).
Un exemplu de utilizare ar fi reprezentarea vânzărilor trimestriale realizate de fiecare agent de
vânzări. 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 vânzărilor
lunare. Figura 4.3
Fig. 4.3
Grafice de tip linie linii - frânte, care marchează fiecare valoare din tabelă asu fişier. Se
utilizează în specialîn analiza de tip trend, pentru a reprezenta modificările unei anumite serii de
date. Exemplu de utilizare: modificarea stocului unui produs pe zile ale unei luni. Figura 4.4
98
Fig. 4.4
Grafice de tip mixt se obţin prin combinarea a două tipuri de grafice, de exemplu, coloană şi
linie. Se obţine şi o sumarizare a valorilor care sunt comparate. De exemplu nivelul profitului
firmei lunar, cu reprezentarea creşterii firmei. Figura 4.5
Fig. 4.5
Graficul de tip “pie” (disc, plăcintă) este utilizat în aplicaţiile economice pentru a compara părţi
sau procente dintr-un întreg. Se pot prezenta vânzările unui produs pe diferite puncte de
desfacere sau cota parte de vânzare a fiecărui agent din totalul vânzărilor. Figura 4.6
Fig. 4.6
Grafice de tip scatter sunt folosite în cazul când se doreşte 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 vânzărilor realizate iar pe OY a
salariului unui aqgent de vânzări. Figura 4.7
99
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 proporţională cu durata ei.
Odată ce au fost listate toate activităţile şi reprezentate duratele lor prin linii proporţionale 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 reprezentându-se
intervale de valori diferite. De exemplu se pot vizualiza cheltuielile (pe o axă OY) şi încasările
(pe cealaltă axă OY), de-a lungul unei perioade de timp (axa OX).
D. Ieşiri către alte sisteme
Sistemul informaţional propriu unităţii economice se află în interconexiune cu sistemele
informaţionale ale altor unităţi economice sau organisme guvernamentale. Această
caracteristică impune şi necesitatea corelării sistemului informatic propriu unităţii economice
beneficiare cu alte sisteme informatice conexe. În acest sens, ieşirile sistemului informatic al
unităţii beneficiare pot constitui intrări în alte sisteme informatice, în timp ce ieşirile altor sisteme
informatice pot fi intrări în sistemul informatic propriu unităţii economice. Aceste intercondiţionări
se pot realiza prin intermediul reţelelor de calculatoare ce vor asigura conexiunea dintre bazele
informaţionale specifice, cărora le vor corespunde bazele de date asociate, între care se
realizează efectiv schimbul de date.
Proiectarea bazei informaţionale
Baza informaţională conţine nucleul informaţional format din totalitatea atributelor
necesare prelucrărilor specifice sistemului informatic şi structura informaţională reprezentată de
entităţi între care se stabilesc corespondenţe şi legături.
100
Proiectarea bazei informaţionale presupune:
A. Determinarea conţinutului bazei informaţionale şi a algoritmilor utilizaţi;
B. Determinarea structurii bazei informaţionale.
C. Normalizarea relaţiilor
A. Determinarea conţinutului bazei informaţionale şi a algoritmilor utilizaţi
Conţinutul bazei informaţionale se determină în funcţie de variantele de abordare a
proiectării generale alese.
În varianta ieşiri-intrări conţinutul bazei informaţionale se determină în funcţie de obiectivele
propuse concretizate în situaţiile de ieşire. Baza informaţională se va constitui pe baza ieşirilor
solicitate şi va fi modificată pe tot parcursul exploatării sistemului în concordanţă cu dinamica
fenomenelor şi proceselor din unitatea beneficiară.
Această variantă se aplică în cazul realizării sistemelor informatice mari şi mijlocii
caracterizate printr-o complexitate ridicată a ieşirilor informaţionale şi implicit a obiectivelor avute
în vedere.
În varianta intrări-ieşiri conţinutul bazei informaţionale presupune cunoaşterea datelor
de intrare şi dinamismul ieşirilor solicitate. Se aplică în cazul realizării sistemelor informatice de
dimensiuni mici.
Sistemele informatice din domeniul economic presupun realizarea unor obiective
delimitate şi fundamentate în strânsă legătură cu cadrul legislativ-normativ care impune natura
ieşirilor informaţionale, motiv pentru care în majoritatea cazurilor determinarea conţinutului şi
structurii bazei informaţionale se face pe varianta ieşiri-intrări.
Determinarea conţinutului bazei informaţionale prin varianta ieşiri-intrări presupune
studierea mulţimii atributelor din situaţiile de ieşire în funcţie de modul de obţinere în urma
prelucrării automate.
Atributul este o proprietate a unei entităţi, a unui grup de entităţi sau a unei
corespondenţe dintre acestea. Prin intermediul atributelor, entitatea poate fi descrisă din punct
de vedere informaţional - ca o componentă distinctă a structurării bazei informaţionale de
intrare. În această viziune, atributul poate fi considerat ca o variabilă, căreia i se poate asocia o
mulţime de valori prin intermediul unui indicator comun.
Atributele sunt reflectate printr-un conţinut concret denumit valoare, care redă nivelul real al
fenomenelor şi proceselor economice cuantificate prin intermediul entităţii.
Atributele bazei informaţionale de intrare pot fi privite din punct de vedere structural şi al
stabilităţii în timp.
101
a) Din punct de vedere structural atributele pot fi elementare şi compuse.
Atributele elementare sunt componente informaţionale deductibile ce nu mai pot fi descompuse
în alte atribute (de exemplu.: cod-mat, den-mat, preţ, stoc-init).
Atributele compuse sunt componente informaţionale 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 stabilităţii în timp atributele pot fi constante, variabile şi
de stare.
Atributele constante îşi menţin valoarea neschimbată o perioadă determinată fiind
invariabile în timp, în raport de semantica atributului din baza informaţională de intrare (de
exemplu: cod-furn, nr-contr, cod-prod, cod-um,preţul etc).
Atributele variabile îşi schimbă valoarea pe parcursul existenţei bazei informaţionale de
intrare fiind variabile în timp în funcţie de semantica atributului (de exemplu.: nr-doc, data-doc
etc,).
Atributele de stare îşi schimbă valoarea numai la anumite intervale de timp, ale
existenţei bazei informaţionale 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 conţinutului bazei informaţionale este necesară îndeplinirea
concomitentă a următoarelor condiţii:
mulţimea atributelor de ieşire este formată din submulţimea atributelor preluate reunită
cu submulţimea atributelor calculate;
submulţimea operanzilor primari intersectată cu submulţimea atributelor preluate
corespunde atributelor comune ce se găsesc în ambele submulţimi;
submulţimea atributelor de intrare este reprezentată corect de nucleul informaţional ce
constituie conţinutul bazei informaţionale.
B. Determinarea structurii bazei informaţionale
Structura bazei informaţionale de intrare reprezintă gruparea conţinutului acestuia
(atributele de intrare într-un ansamblu de entităţi inclusiv corespondenţele (legăturile) dintre
acestea).
Structura bazei informaţionale de intrare este efectuată prin intermediul unui model de
reprezentare care asigură independenţa logică şi fizică a prelucrărilor faţă de colecţiile de date
în care va fi transpusă baza informaţională. Această proprietate asigură implicit independenţa
relativă a proiectării generale faţă de soluţiile tehnice adoptată în cadrul proiectării de detaliu.
În mod concret, gruparea atributelor de intrare în entităţi informaţionale şi reflectarea
corespondenţelor (legăturilor) dintre acestea se realizează gradat printr-un proces de modelare
ce permite definirea riguroasă a structurii bazei informaţionale.
102
Acest proces de modelare are la bază modelul de reprezentare entitate – atribut –
corespondenţă. Acest model consideră baza informaţională de intrare ca un ansamblu finit de
entităţi informaţionale, caracterizate în mod unic, printr-o mulţime specifică de atribute şi un
ansamblu de corespondenţe (legături) stabilite între entităţi sau chiar în interiorul acestora. În
acest context corespondenţele pot fi definite ca asocieri între realizările aceleiaşi entităţi sau
realizările entităţilor 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 relaţional al datelor) din
care se definesc bazele de date şi are loc proiectarea fizică a acestora Definirea entităţilor,
atributelor, legăturilor dintre colecţiile de date au drept scop depistarea şi înlăturarea
disfuncţionalităţilor ce ar putea afecta performanţele bazei informaţionale.
C. Normalizarea relaţiilor
Procesul de normalizare a relaţiilor este util în activitatea de proiectare a structurii
logice şi a bazei de date relaţionale şi constă în eliminarea neajunsurilor ce apar în exploatarea
efectivă a bazei de date, neajunsuri introduse de dependente incorecte, existente între datele
relaţionale.
Din punctul de vedere al influenţei asupra performanţelor în exploatare a bazei de date,
normalizarea afectează negativ eficienţa cu care sînt rezolvate interogările. Aceasta pentru că
informaţiile care într-o bază de date nenormalizată ar putea fi regăsite într-o singură relaţie, în
cazul unei baze normalizate necesită, de cele mai multe ori, cuplarea a două sau mai multe
relaţii. De aceea normalizarea este considerată necesară şi utilă doar în ipoteza că operaţiile de
adăugare, ştergere şi actualizare sînt frecvent utilizate.
Aşadar normalizarea îmbunătăţeşte integritatea datelor prin reducerea redundanţei şi a
inconsistenţei în detrimentul eficienţei unor operaţii de regăsire a datelor.
E. F. Codd a arătat ca într-o anumită formă relaţiile posedă proprietăţi nedorite pe care le-a
numit anomalii de actualizare şi le-a structurat astfel:
anomalii de ştergere se referă la faptul că ştergând un tuplu dintr-o tabelă, pe lângă
datele ce trebuie eliminate se şterg şi cele necesare.
anomalii de adăugare 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
când ea apare în mai multe tupluri ale relaţiei.
Pentru a elimina aceste anomalii Codd a stabilit trei forme normale pentru relaţii şi a
introdus noţiuni de normalizare care se bazează pe dependenţa funcţională între atributele unei
103
relaţii. Ulterior, alţi cercetători au mai completat formele normale cu încă două forme normale
plus una suplimentară.
Primele patru nivele sînt definite în termenii dependenţelor funcţionale, ş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ă sînt definite în termenii
dependenţelor multivalorice. Diferitele nivele de normalizare impun condiţii din ce în ce mai
restrictive asupra relaţiilor. Astfel o relaţie aflată pe un anumit nivel de normalizare satisface
toate restricţiile cerute de nivele inferioare de normalizare. Deci o relaţie în FN4, este şi în FN3,
FN2 ş.a.m.d.
Formalizarea atributelor
Activitatea de formalizare a atributelor presupune studierea documentelor de intrare şi
adaptarea lor la cerinţele sistemului informatic, iar multitudinea de atribute sunt codificate.
A. Adaptarea documentelor de intrare la cerinţele sistemului informatic
Documentele de intrare reflectă starea şi dinamica fenomenelor şi proceselor economice
desfăşurate în unitatea respectivă. Ele reprezintă principala sursă de date pentru crearea şi
actualizarea colecţiilor de date.
Dacă aceste documente nu corespund integral din punct de vedere al conţinutului şi al formei cu
structura bazei informaţionale şi cu restricţiile impuse de sistemul informatic proiectat, vor suferi
modificări de conţinut şi de formă.
Modificările de conţinut constau în :
adăugarea rubricilor de coduri acolo unde nu sunt prevăzute, insistându-se pe codurile
ce specifică natura operaţiilor reflectate şi a celor care servesc pentru identificarea şi
asocierea colecţiilor de date(exemplu: cod_material, cod_produs, nr._marcă);
modificarea şi regruparea rubricilor aferente atributelor ce vor conţine date care să se
introducă în acelaşi loc în toate documentele. În acest mod se formează o zonă
nenormalizate
1 NF
2 NF
3 NF
5 NF
BCNF – Boice code normal form
4 NF
BCNF
104
comună tuturor documentelor, păstrându-se însă individualitatea fiecărui document.
Modificările de formă ale documentelor de intrare sunt impuse de necesitatea creşterii facilităţilor
de preluare directă a datelor prin intermediul videoterminalului şi vizează următoarele aspecte:
toate atributele care se introduc de la terminal se vor grupa astfel încât să fie înlăturată
dispersarea lor pe toată suprafaţa terminalului;
atributele se vor ordona asigurându-se întâi prezenţa atributelor de identificare, apoi a
celor informative şi terminând cu cele cantitativ-valorice;
atributele ce se preiau din colecţiile 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 măsură, inclusiv
atributele rezultate din calcule, deşi ele sunt consemnate în documentele pentru
efectuarea controlului în gestiune).
Pe lângă aceste modificări se vor stabili şi regulile de completare şi utilizare a documentelor de
intrare, se stabilesc numărul de exemplare, circuitul fiecărui exemplar, frecvenţa şi termenul de
introducere a datelor în colecţiile de date.
De asemenea, se precizează responsabiltăţile pentru completare şi verificare, semnăturile care
validează conţinutul documentelor de intrare, inclusiv persoanele împuternicite în acest sens.
Aceste specificaţii sunt folosite pentru proiectarea sistemului informatic şi sunt trecute în
documentaţia finalizată în etapa de implementare.
B. Codificarea atributelor
Activitatea de codificare trebuie să realizeze corelaţia între specificul activităţii unităţii beneficiare
şi particularităţile sistemului informatic proiectat.
Necesitatea de codificare este impusă de cerinţele de grupare si ierarhizare a atributelor care
oferea multiple soluţii (posibilităţi de prelucrare a datelor) regăsite in colecţiile de date care
constituie baza informaţională.
Codificarea atributelor constă în atribuirea, manuală sau automată, într-o formă sistematizată,
de coduri fiecărui element din sistemul informatic proiectat.
Prin codificarea atributelor se asigură următoarele avantaje:
folosirea intensivă a memoriei externe prin înlocuirea atributelor cu coduri numerice,
alfabetice sau alfanumerice;
realizarea unei ierarhizări a atributelor în funcţie de criteriile specifice prelucrării prin
care se poate obţine o ordonare a acestora în raport cu cerinţele de selectare a
atributelor din baza informaţională sau de obţinere a gradelor de total sau subtotal
pentru situaţiile de ieşire;
reducerea erorilor prin folosirea codului care simplifică scrierea în comparaţie cu
folosirea denumirilor explicite ale atributelor.
105
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 colecţii de date.
confidenţialitatea datelor, precum si integritatea acestora, ceea ce oferă bazei de
date(B.D) o securitate si o protecţie in timpul prelucrării
Pentru ca un sistem de codificare să fie eficient în procesul de prelucrare a datelor, se
urmăresc următoarele:
1) Cerinţele si funcţiile codificării.
2) Tipurile de coduri utilizate intr-un sistem informatic
3) Realizarea codificării propriu-zise
1) Cerinţele si funcţiile codificării
Cerintele codificării sunt redate de proprietăţile esenţiale 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 proprietăţi 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 utilizării codului-se refera la facilitatea operaţiilor de codificare şi de
detectare a erorilor, precum şi corectare a acestora.
Atribuirea codurilor trebuie să fie uşor de înţeles şi aplicat astfel încât personalul unităţii
beneficiare sa asimileze intr-un timp foarte scurt noul sistem de coduri
concizia codului se refera la necesitatea unui număr redus de caractere pentru
reprezentarea elementelor codificate, astfel încât să se asigure o viteză mare de
prelucrare şi o reducere a procentelor de erori în procedurile manuale de introducere a
datelor.
106
Fig. 4.7
Pentru realizarea acestor cerinţe codificarea atributelor constă în atribuirea manuală sau
automată, într-o formă sistematizată a unor coduri fiecărui atribut din baza informaţională.
Funcţiile codificării
Trebuie să permită caracterizarea directă a fiecărui atribut ce va fi supus codificării,
identificarea formală a acestora, controlul valorilor posibile atribuite, posibilitatea de manipulare
a atributelor codificate.
Funcţia de caracterizare, exprimă intr-o formă concisă, unică şi stabila în timp conţinutul
semantic al fiecărui atribut, prin intermediul codurilor asociate(exemplu: în loc de Facultatea de
Management Financiar Contabil se poate utiliza codul FMFC).
Funcţia de identificare, oferă posibilitatea regăsirii mai rapide a atributelor, decât prin folosirea
complexă a semanticii atributului. Aceasta funcţie crează posibilitatea ulterioara de selectare a
anumitor atribute prin intermediul cărora se vor identifica in mod unic atributele solicitate prin
intermediul cheilor primare si externe.
Funcţia de control asigură existenţa unui caracter care ataşează în ultimă poziţie din dreapta
structurii codului pe baza căruia prin metode matematice (aritmetica si geometrica) au algoritmi
specifici ,se poate verifica integral corectitudinea simbolurilor care intră în componenta codurilor.
Codificarea ATRIBUTELOR
Cerinţele
codificarii Functiile
codurilor
Tipologia
codurilor
Realizarea
codificarii
- unicitatea codului
- stabilirea şi supletea
în timp
- controlabilitatea
codului
- comoditatea
- concizia
- extensibilitatea
- 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
-determinarea
atributelor
codificabile
- pregatirea
codificarii
- realizarea
nomenclatoarel
or de codului
- întreţinerea
nomenclatoarel
or de coduri
107
Funcţia de manipulare a atributelor codificate, facilitează introducerea eficientă a codurilor in
memorie, reduce timpul de prelucrare a acestora, facilitează uşurinţa folosirii atributelor de către
toate compartimentele funcţionale implicate in realizarea sistemului informatic respectiv.
2) Tipologia codurilor
Diversitatea şi complexitatea conţinutului bazei informaţionale de intrare, precum şi
multitudinea proceselor de prelucrare a atributelor componente, au condus la apariţia unei game
variate de coduri, grupate în mai multe categorii, în funcţie de următoarele 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 componenţa codului determină următoarele 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 Semnificaţie
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 aceeaşi valoare atâta timp cât 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 existenţa caracterului de control care
asigură detectarea automată a erorilor introduse prin compararea caracterului de control care
însoţeşte codul respectiv cu caracterul de control determinat de calculator atunci când
respectivul cod este utilizat.
Pentru calculul caracterului de control se folosesc mai multe metode, dintre care cele mai
cunoscute sunt:
108
metoda aritmetică;
metoda geometrică;
metoda literei de control.
Metoda aritmetică constă în stabilirea caracterului de control (C ) prin intermediul unei cifre
obţinută pe baza sumei produselor rezultate din înmulţirea fiecărei cifre a codului (Ci) cu anumite
ponderi convenţional alese, denumite ponderi (Pi ) ale codului, ce urmează a fi scăzută din cifra
zecilor imediat superioară (Z).
Pentru aplicarea acestei metode se parcurg paşii:
1. asocierea ponderii Pi astfel:
Pi
2. calculele produselor CiPi poate duce la două situaţii distincte:
- dacă CiPi 10, atunci acest produs este dat de o singură cifră pe care o notăm 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 - n
i0 Ci Pi
De exemplu caracterul de control pentru codul 923764 se va calcula astfel:
9 8 7 6 5 4 3 2 1 0 I
0 0 0 0 9 2 3 7 6 4 Ci
0 0 0 0 1 2 1 1 2 2 Pi
9 4 3 7 3 8 CiPi
CiPi 34 Z40
k40-346 noul cod 9237646.
imparnri
parnri
.daca 1,
.daca 2,
109
Metoda aritmetică are avantajul simplităţii şi acurateţei, dar prezintă dezavantajul imposibilităţii
detectării erorilor de compensare.
Metoda geometrică constă în stabilirea caracterului de control (C) prin intermediul unei cifre
sau litere obţinută ca rest al împărţirii sumei produselor fiecărei cifre a codului, cu puterile
crescătoare ale lui 2, la un număr sau cu numere naturale în ordine crescătoare, par sau impar
ales convenţional(x).
Metoda geometrică se realizează în următorii paşi:
1) asocierea ponderilor Pi 2i, i0,1,2…n
2) calculul produselor CiPi
3)se calculează suma CiPi
4) se determină cifra de control (k).
kCiPi /x, unde x CiPi şi are aceeaşi lungime cu CiPi.
Practic, cifra de control se determină astfel:
CiPi / XQ +R, unde Q este partea întreagă a împărţirii iar R este restul împărţirii, R
fiind de fapt cifra de control.
Rk
De exemplu caracterul de control pentru codul 923764 se va calcula astfel:
9 2 3 7 6 4 Ci
2 2 2 2 2 2 Pi
288 32 24 28 12 4 CiPi
5
0i iiPC = 388 x = 386
5
0i iiPC / x = 388/386 = 1+2 k=2
Noul cod va fi : 9237642.
Metoda literei de control este asemănătoarea metodei geometrice, dar limitează posibilitatea
apariţiei erorilor de compensaţie şi evită mărirea lungimii codului prin faptul că numărul par ales
este 26 (cel mai mare număr natural asociat literelor alfabetului englez), iar caracterul de control
este o literă ce se obţine prin transformarea restului obţinut din aplicarea algoritmului metodei
geometrice în litera din alfabetul englez care are număr natural corespunzător valorii restului.
110
De exemplu, pentru codul 923764, litera de control va fi:
9 2 3 7 6 4 Ci
5 4 3 2 1 0 Pi
45 8 9 14 6 0 CiPi
5
0i iiPC = 82
5
0i iiPC /26=82/26=3+4 x = d
Noul cod va fi: 923764d.
Indiferent de metodele aplicate pentru stabilirea caracterului de control , principiul de
verificarea rămâne acelaşi. La fiecare citire a codului aplică algoritmul de calcul al caracterului
de control şi compară rezultatul obţinut cu caracterul de control introdus odată cu codul.
Dacă caracterul de control este diferit , se invalidează atributul respectiv. Posibilitatea
apariţiei erorilor este generată de inversarea sau însumarea greşită a cifrelor codului, scrierea
eronată a codului în documentele de intrare sau de introducere eronată de la terminal.
Codurile autocorectoare de erori asigură atât detectarea erorilor şi poziţia acestora cât şi
înlăturarea acestora. Pentru determinarea cifrei de control, codurilesunt aranjate într-o formă
matriceală, unde fiecare linie şi coloană are câte un caracter de control obţinut prin însumarea
cifrelor de linie sau coloană şi scăzând 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 obţinerea cifrei de control, se parcurg paşii:
se aranjează codul într-o matrice astfel încât:
cifra Co să ocupe elementul Cmn din matrice (colţul din dreapta jos al matricei);
eventualele poziţii neocupate se completează cu cifra 0.
2) se calculează suma elementelor, deci a cifrelor codului:
pe linie
m
j ijC1 ;
pe coloană
m
i ijC1
3) se determină cifrele de control:
pe linie Ci= Zm
m
j ijC1 -
m
j ijC1 ;
111
pe coloană: Cj = Zn
m
i ijC1 -
m
i ijC1
4) se calculează cifra de control (k):
pe linie k linie Zn
m
i ijC1 -
m
i ijC1
pe coloană: k coloană = Z
m
i ijC1 -
m
i ijC1
Dacă după aceste calcule k linie= k coloană atunci k linie devine cifră de control.
Structura codurilor
Elementară Complexă
Coduri secvenţiale
Coduri pe grupe
Coduri cu semnificaţie
Coduri numerice
Coduri cu semnificaţie descriptivă
Coduri ierarhizate:
liniar simplu
zecimal
Coduri juxtapuse
Coduri combinate
Coduri secvenţiale se formează prin atribuirea unui şir de caractere fiecărui element al
mulţimii stabilind o corespondenţă (in ordine crescătoare) între elementele acestora şi mulţimea
numerelor naturale. Fiecărui element supus codificării i se asociază un cod crescător, imediat
disponibil. De exemplu: unei persoane angajate i se atribuie marca 123, este precedată de
marca 122 şi succedată de marca 124.
Coduri secvenţiale pe grupe se formează prin rezervarea unui set maxim de simboluri
pentru fiecare tip de atribut omogen caracterizat prin particularităţi comune ce formează o grupă
specifica supusa codificării.Grupele atribuite sunt dependente de specificul economic al
atributelor si de exigentele prelucrării ale acestora. Exemplu: Fie studenţii Facultăţii de
Management Financiar Contabil. Fiecare student are un număr matricol:1457 –Ionescu Dan,
1458 –Popescu Ion, 1497 –Vasile Lazăr,. Studenţii sunt grupaţi pe grupe şi ani de studii.
1457 –Ionescu Dan
1458 –Popescu Ion Grupa 1404
Anul IV
1497 –Vasile Lazăr Grupa 1404
112
Codul de semnificaţie 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 oţel laminat).
Codul de semnificaţie descriptivă se formează prin combinarea iniţialelor desemnate pentru
denumirea elementului respectiv cu particularităţile tehnico-constructive ale acestuia. Acest tip
de coduri este utilizat in special in nomenclatoarele de coduri speciale cu posibilităţile de
extindere pentru particularităţile tehnice semnificative (de exemplu: Codurile complexe conţin
atribute ce aparţin unor mulţimi distincte, dar sunt folosite în comun în viitoarele prelucrări.
În această categorie se include codurile ierarhizate juxtapuse.
Codurile de ierarhizare redau numărul maxim de operaţii, al fiecărui tip de atribut în cadrul
treptelor de ierarhizare.
Exemplu: codificarea locurilor de muncă se poate face cu următoarea structură de cod:
Loc de muncă xx x xx ……atelier de producţie
secţie de producţie
societate comercială
Codurile juxtapuse se realizează prin concatenarea codurilor ierarhice sau secvenţiale in
vederea utilizării grupate sau utilizării individuale a atributelor codificate in raport de cerinţele
statice sau dinamice de prelucrare.
Exemplu: codificarea personalului unei unităţi economice poate avea un cod juxtapus, rezultat
din concatenare valorilor distincte ale atributelor (atelier de producţie, secţie de producţie,
marcă)
d) Lungimea codurilor este dată de numărul maxim de caractere folosite de un cod. Asfel
avem:
- coduri de lungime fixă: cu aceiaşi 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 societăţilor 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.
113
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 recunoaştere.
3) Realizarea codificării
Activitatea de codificare se realizează prin parcurgerea următoarelor faze:
- pregătirea activităţilor de codificare;
- codificarea atributelor bazei informaţionale;
- întocmirea nomenclatoarelor de coduri;
- întreţinerea nomenclatoarelor de coduri.
Pregătirea activităţilor de codificare presupune următoarele operaţii:
- analizarea conţinutului şi structurii bazei informaţionale î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 codificării.
În cazul unei codificării fără pregătire prealabilă, activitatea se reduce la o analiză sumară
asupra volumului de atribute. Dacă se optează pentru codificare cu pregătire prealabilă este
necesară ordonarea atributelor codificabile, analiza particularităţilor conţinutului bazei
informaţionale ş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 informaţională;
analiza particularităţilor conţinutului bazei informaţionale, presupune determinarea
dimensiunii mulţimii de codificat şi estimarea evoluţiei ulterioare. Pentru aceasta este
necesară să se precizeze responsabilităţile de gestionare a bazei informaţionale, modul
de utilizare concretă a codurilor în documente de intrare şi ieşire, frecvenţa de
utilizarea, precum şi gradul de acomodare a utilizatorilor cu sistemul de coduri propus;
alegerea codului se face în corespondenţă cu valorile efective potenţiale ale atributelor,
metoda de introducere şi validare a codurilor, metode de codificare, costul şi timpul de
realizare a activităţii de codificare;
codificarea este subordonată cerinţelor şi restricţiilor sistemului informatic, deoarece
acesta va stabili cerinţele 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 activităţii de codificare determină soluţia acelor tipuri de
coduri care implică cheltuieli reduse şi un timp minim de realizare a nomenclatoarelor
114
de coduri;
examinarea posibilităţii preluării în noul sistem informaţie a codurilor deja folosite, dată
fiind obişnuinţa 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 pregătire şi introducere a datelor, actualizare şi obţinere a rezultatelor, precum şi
reguli tehnice de utilizare şi exploatare a întregului sistem.
Proiectarea fizică a sistemelor informatice este caracterizată printr-o serie de trăsături
specifice:
Alegerea sistemului optim de gestiune a datelor şi a sistemului de calcul care vor
asigura realizarea funcţionalităţii sistemului informatic definit în proiectarea logică;
Transformarea entităţilor din baza informaţională definite în proiectarea logică, în
colecţii de date ce urmează a fi organizate în baze de date;
Proiectarea structurală şi funcţională a datelor organizate în baze de date la nivelul
aplicaţiilor;
Elaborarea strategiei de definire a procedurilor de actualizare şi exploatare-listare a
bazelor de date, precum şi specificarea măsurilor de securitate şi protecţie.
Proiectarea fizică a sistemelor informatice are un caracter preponderent tehnic şi solicită un
volum mare de muncă, iar activităţile desfăşurate sunt influenţate direct de soluţia aleasă de
gestiune a colecţiilor de date, sistemul electronic de calcul şi sistemul de operare.
Proiectarea fizică implică parcurgerea următorilor paşi:
Proiectarea fişierelor 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 strânsă concordanţă cu diagramele fluxurilor de date şi cu
celelalte piese ale documentaţiei realizate în etapele anterioare.
Proiectarea strategiilor de prelucrare distribuită - se vor prezenta modalităţile în care
utilizatorul poate să dispună de datele şi facilităţile de prelucrare oferite de reţelele de
calculatoare.
Proiectarea fişierelor fizice şi a bazelor de date îşi propune să asigure trecerea de la descrierea
logică a datelor la una tehnică, de stocare a datelor. Totuşi, proiectarea fizică se concretizează
în specificaţii folosite ulterior de programatori şi alţi specialişti implicaţi în construirea sistemului
115
(în timpul implementării), prin crearea fişierelor, defînirea modurilor de organizare a acestora,
precum şi a bazelor de date.
Proiectarea fizică a fişierelor şi bazelor de date are două obiective:
1. Transpunerea relaţiilor dintr-un model de reprezentare logică a datelor într-un proiect tehnic.
Un astfel de proiect va conţine formatele sub care vor fi reprezentate atributele, modul de
grupare a acestora din una sau mai multe relaţii în una sau mai multe înregistrări fizice, alegerea
modului de organizare a fiecărui fişier cu înregistrări fizice, precum şi proiectarea metodelor de
accesare a datelor din unul sau mai multe fişiere.
2. Selectarea tehnologiilor folosite pentru stocarea datelor
Tehnologiile includ diverse funcţii 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 activităţile din cadrul proiectării fizice sunt:
1. Alegerea tipului de suport şi modalităţilor de prezentare a ieşirilor informaţionale;
2. Proiectarea machetelor de editare/vizualizare a ieşirilor;
3. Proiectarea procedurilor şi a programelor.
Aceste activități vor fi descrise în capitolele 6 și 7.
4.3 Proiectarea orientată obiect a sistemelor informatice
Concepte utilizate în abordarea obiectuală a proiectării sistemelor informatice
Dintre conceptele care stau la baza modelării orientată obiect cele mai importante sunt:
obiectul;
încapsularea;
persistenţa;
tipul;
clasa;
moştenirea;
polimorfismul;
identitatea.
Obiectul
Obiectul este o abstractizare a entităţii 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
116
multiple referinţe spre alte obiecte, tipuri utilizatori etc.). Comportamentul unui obiect este definit
de setul de operaţii şi metode aplicabile obiectului respectiv.
Fiecare obiect are un nume care coincide, de obicei, cu numele entităţii reprezentate.
Metodele şi atributele nu sunt vizibile din exteriorul obiectului.
Un obiect răspunde la mesaje. Mesajul este unitatea de comunicaţie dintre obiecte.
Mesajele cuprind: numele mesajului, numele obiectului ţintă şi argumentele necesare, dacă
există. Când un obiect primeşte un mesaj una din procedurile sale este apelată. Procedura
realizează apoi o operaţie care poate returna un rezultat. Mesajele sunt implementate prin
intermediul metodelor.
Încapsularea
Încapsularea constă în capacitatea obiectelor de a conţine la un loc atât date cât şi operaţii
dintre care numai o parte sunt vizibile din exterior.
Un obiect este compus din două părţi:
- interfaţa – permite unui utilizator extern să solicite obiectului executarea unei acţiuni;
- 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 uşor problemele complexe.
Persistenţa
Persistenţa este proprietatea obiectelor care determină existenţa mai îndelungată a
acestora faţă de procesul care le-a creat; este proprietatea prin care starea bazei de date
asigură execuţia unui proces pentru a fi refolosit ulterior în alt proces.
Tipul
Tipul sintetizează elementele comune ale unui set de obiecte cu aceleaşi caracteristici.
Tipul abstract de date are două componente:
- interfaţa – este vizibilă utilizatorului şi constă într-o listă de operaţii
- implementarea – presupune descrierea structurii interne a datelor obiectului şi
realizarea procedurilor de implementare a operaţiilor interfeţei.
Clasa
Noţiunea de clasă are aceeaşi semnificaţie cu cea de tip, însă este deosebită de
aceasta, prin faptul că este asociată cu faza de execuţie. O clasă este un tip abstract de date
care defineşte atât structura obiectelor din clasa respectivă, cât şi mulţimea metodelor existente
pentru aceste obiecte.
Obiectele din aceeaşi clasă au aceleaşi atribute şi aceleaşi metode şi răspund la acelaşi mesaj.
117
Clasele sunt organizate ierarhic. Orice subclasă moşteneşte metodele şi structura clasei din
care face parte.
Moştenirea
Moştenirea 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 moştenite
se numeşte supraclasă.
Prin intermediul moştenirii se pot exprima relaţii deosebit de utile între clase: clasificarea,
generalizare, specializare.
Moştenirea poate fi implementată:
- static – presupune concatenarea câmpurilor moştenite în clasele respective;
- dinamic – presupune parcurgerea legăturilor de moştenire şi se realizează fără
recopierea câmpurilor moştenite.
Polimorfism
Polimorfismul semnifică posibilitatea unui obiect, instanţă a unei clase, să răspundă
diferit la primirea aceluiaşi mesaj.
Polimorfismul se poate asigura prin două căi:
- redefinirea metodelor moştenite în clasele derivate;
- crearea unor metode cu acelaşi nume dar cu parametrii deferiţi.
Identitatea
Identitatea unui obiect este proprietatea acestuia care îl distinge de alte obiecte. Astfel,
spre deosebire de modelul relaţional î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 acelaşi identificator, adică egalitatea obiectelor este
de fapt o egalitate de pointeri (se scrie a = b).
Două obiecte sunt egale dacă au aceleaşi valori (a = b). Aşadar
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ă atât date cât şi
comportament, ceea ce înseamnă că analistul poate folosi abordarea orientată obiect atât
pentru modelarea datelor, cât ş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 moştenirii şi reutilizarea codului, modelarea orientată obiect
118
oferă un mediu puternic pentru dezvoltarea sistemelor complexe. Teoria obiectelor,
încapsularea, moştenirea şi polimorfismul stau la baza dezvoltării obiectuale a sistemelor.
Referitor la consistenţa modelelor, în alte abordări - cum ar fi analiza şi proiectarea -,
structurată - modelele care se dezvoltă nu folosesc notaţii comune şi sunt slab conectate între
ele, tranziţia de la un model la altul făcându-se în mod abrupt. Abordarea orientată obiect oferă
continuitate în ceea ce priveşte tranziţia între modelele analizei, proiectării şi ale implementării.
De exemplu, trecerea de la analiza orientată obiect la proiectarea orientată obiect presupune
îmbogăţirea modelului de analiză cu detalii referitoare implementare şi nu dezvoltarea unui nou
model.
Modelarea domeniului (mediului) - Domain Model
Pentru a aprofunda înţelegerea contextului în care va funcţiona sistemul se utilizează
modelul mediului (domeniului). Acest model cuprinde cele mai importante clase întâlnite în
domeniul economic pentru care se realizează sistemul informatic şi are un caracter de
generalitate. Clasele se identifică fie din cerinţele exprimate de beneficiar, fie din intervievarea
unor experţi î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 informaţional
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 dispoziţie de UML.
Scopul principal al acestui model este înţelegerea contextului sistemului. De aceea la
realizarea modelului mediului (domeniului) este de preferat si participe atât specialişti în
modelare, cât şi experţi din domeniul analizat. Din acest punct de vedere se remarcă
asemănarea cu etapa de analiză specifică metodologiilor structurate Aşa cum ştim deja,
conform unui vechi principiu al analizei sistemelor, în acest proces este de preferat să fie
implicaţi cei mai buni specialişti în domeniu (experţii). Modelul mediului va conţine cele mai
importante clase ale domeniului. Odată cu întocmirea diagramei claselor se întocmeşte şi un
dicţionar al claselor în care se va preciza semnificaţia fiecărei clase pentru a se folosi o
terminologie unitară. Se preferă această formulă pentru a se evita obţinerea unui model prea
mare şi greu de utilizat.
119
Modelul mediului, format din diagrama claselor domeniului şi dicţionarul de termeni,
poate fi utilizat atât la dezvoltarea modelului cazurilor de utilizare, cât şi la identificarea claselor
sistemului în etapa de analiză.
Modelarea proceselor afacerii (prelucrărilor) - Business Model
Aceasta este o tehnică de modelare utilizată pentru a aprofunda înţelegerea proceselor
specifice unei organizaţii. Utilizând UML, modelarea afacerii se poate face din două perspective:
fie prin modelul cazurilor de utilizare, fie prin modelul obiectelor.
În cadrul modelării cazurilor de utilizare (business use-case model) se surprinde
funcţionarea sistemului din perspectiva utilizatorilor acestuia.
Modelul obiectelor (business-object model) surprinde prelucrările din interiorul
sistemului. Descrie în detaliu cum este tratat fiecare caz de utilizare. Realizarea cazurilor de
utilizare se poate evidenţia cu ajutorul diagramelor de interacţiune (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 utilizări. O
unitate de lucru este un set de astfel de entităţi care formează un întreg pentru utilizatorul final.
Entităţile şi unităţile de lucru sunt utilizate pentru a reprezenta aceleaşi 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 paşi:
1. Realizarea modelului cazurilor de utilizare
2. Detalierea modelului prin specificarea utilizatorilor, entităţilor şi a unităţilor lucru, dar şi
a regulilor care guvernează anumite procese sau obiecte.
Scopul este crearea unor utilizatori, entităţi şi unităţi de lucru care să rezolve problema
evidenţiată de cazul de utilizare, eficient - bine, rapid şi la cel mai scăzut cost posibil.
Modelarea mediului şi modelarea afacerii par întrucâtva asemănătoare, mai ale dacă ne gândim
că entităţile şi unităţile de lucru corespund claselor din modelul mediu.
Cele două abordări diferă în primul rând prin modul de documentare. Una se bazează
pe cunoştinţele unui expert în domeniu sau pe cunoştinţele despre sisteme similare, în timp ce a
doua are în vedere cerinţele beneficiarului. Orice clasă a modelului domeniului îşi regăseşte
originea în experienţa cunoscătorilor domeniului. Orice element al modelului afacerii (entitate
sau unitate de lucru) îşi regăseşte originea într-o cerinţă a beneficiarului. Acesta este şi motivul
principal pentru care utilizând cele două abordări, în mod normal, se obţin clase, atribute,
metode şi asocieri diferite.
120
O altă deosebire ar fi că pornind de la analiza domeniului vom obţine mai multe
informaţii despre atributele claselor şi mai puţine despre comportamentul acestora
Evident, în cazul modelării afacerii se vor identifica atât entităţile şi unităţile de lucru (clasele),
cât şi utilizatorii (şi operaţiile pe care aceştia 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 cerinţele sistemului.
Dacă modelul mediului abordează cu precădere funcţionarea sistemului în contextul
acestuia, modelul afacerii îşi focalizează atenţia asupra utili zatorilor şi a modului cum
sistemul îi deserveşte.
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 interacţionează cu sistemul (similar unei entităţi externe dintr-
o diagramă de flux a datelor). Actorul este ceva sau cineva care schimbă informaţie 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 interacţionează sau schimbă informaţii.
Un caz de utilizare este o secvenţă de acţiuni iniţiate de un actor, surprinzând un
anumit mod de a folosi sistemul. Nu trebuie făcută confuzie între actor al sistemului şi utilizator
al sistemului. Un utilizator este oricine foloseşte 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. Acelaşi utilizator poate juca mai multe roluri.
Actorii, fiind entităţi externe sistemului, nu pot fi descrişi în detaliu. Identificarea actorilor ajută la
identificarea cazurilor de utilizare - întrucât un caz de utilizare este iniţiat de un actor. Iată câteva
întrebări la care analistul de sistem trebuie să răspundă pentru a identifica cazurile de utilizare:
1. Care sunt principalele acţiuni executate de fiecare actor?
2. Actorul va citi sau va actualiza informaţia din sistem?
3. Actorul va informa sistemul despre modificările petrecute în afara acestuia?
4. Actorul va fi informat de modificările din sistem?
Să considerăm cazul unui sistem de înregistrare al studenţilor la cursurile oferite de un
centru de instruire. Entităţile externe sistemului sunt studentul care se înscrie la curs, secretara
care face înscrierea studenţilor la cursuri, casiera care încasează contravaloarea cursurilor şi
instructorul care predă cursurile
Un caz de utilizare este iniţiat întotdeauna de un actor şi poate interacţiona şi cu alţi
actori, nu numai cu cel care 1-a iniţiat. Cazul de utilizare trebuie să redea o funcţionalitate
completă şi nu numai o anumită acţiune a unei funcţionalităţi. Transmiterea unui formular de
înscriere la un curs este parte a procesului de înregistrare la curs, deci va fi inclus în cazul de
121
utilizare „înregistrare la curs" şi nu se va construi un caz separat pentru acţiunea 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 către actori. Modelul cazurilor de utilizare este
completat de o descriere textuală a fiecărui caz de utilizare, accentul punându-se pe
interacţiunea cu alţi actori şi mai puţin pe modul în care este executat în cadrul sistemului.
Modelarea cazurilor de utilizare permite analiza cerinţelor funcţionale ale sistemului,
insistând asupra a CE trebuie să facă un sistem existent sau un nou sistem, fără 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, având rolul de a ajuta dezvoltatorii să înţeleagă cerinţele
funcţionale ale sistemului. Procesul este iterativ iar, stabilirea cerinţelor se face în urma
discuţiilor cu beneficiarul sistemului. Cazurile de utilizare controlează toate celelalte modele.
Dacă cerinţele utilizatorului se modifică în timpul dezvoltării, aceste modificări sunt vizibile mai
întâi în modelul cazurilor de utilizare. Modificările în cazurile de utilizare implică modificări şi în
celelalte modele. Şi reciproca este valabilă, adică în momentul în care se fac modificări î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 relaţiile dintre acestea, nu şi modul în care interacţionează pentru a asigura un
anumit comportament. Diagrama claselor poate, de asemenea, evidenţia şi alte aspecte ale
structurii statice, cum ar fi pachetele.
Construirea diagramei claselor presupune în primul rând identificarea claselor din
sistem, acest proces reprezintă o parte esenţială a proiectării sistemelor orientate obiect, de
succesul acestuia depinzând î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 conţine (pe cât posibil) clase stabile din domeniul obiectual,
care nu depind de funcţionalitatea particulară cerută la momentul proiectării.
Poate fi utilizată orice tehnică de obţinere a claselor atâta timp cât modelul obţinut respectă
criteriile enunţate. Implicit, dacă modelul obţinut nu respectă criteriile, nu va fi nimeni interesat
de tehnica utilizată, oricât de profesionistă ar fi aceasta.
În literatura de specialitate se propun două metode:
modelarea orientată pe date (data driven design);
modelarea orientată pe funcţiuni (responsibility driven design).
122
Primul tip de metode presupune identificarea tuturor datelor din sistem şi împărţirea Ior pe
clase, înainte de a considera funcţiunile acestor clase. Tehnica identificării substantivelor este
cea mai utilizată astfel de metodă. Al doilea tip de metode, orientate pe funcţiuni, presupune
identificarea tuturor funcţiunilor sistemului şi împărţirea lor pe clase, înainte de a considera
datele acestor clase.
Tehnica identificării substantivelor presupune două etape:
Identificarea claselor candidate, selectând din specificarea cerinţelor sistemului toate
substantivele şi frazele substantivale (se consideră substantivele la singular şi nu se
aleg fraze ce conţin „sau" ca unici candidaţi).
Se elimină candidaţii consideraţi nepotriviţi din diverse motive şi se redenumesc clasele
rămase dacă este necesar.
Unele dintre motivele pentru care o clasă candidată ar putea fi considerată nepotrivită sunt:
Redundanţa - 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 conţinutul clasei.
Imprecizia - când nu se poate spune precis care e realitatea descrisă de substantivul respectiv.
Desigur, trebuie îndepărtată ambiguitatea înainte de a putea spune dacă substantivul reprezintă
o clasă.
Eveniment sau operaţie - când substantivul se referă la ceva ce este făcut de sistem. Uneori
această situaţie este bine modelată de o clasă, dar nu este acesta cazul obişnuit.
Metalimbaj - unde substantivul face parte din modul de definire a cerinţelor. Vom utiliza
substantive ca „cerinţe" sau „sistem" ca parte a limbajului de modelare şi nu pentru a reprezenta
obiecte din domeniul problemei.
Extern sistemului - atunci când substantivul este relevant pentru a descrie funcţionarea
sistemului, dar nu se referă la ceva din interiorul său.
Atribut - atunci când este clar că substantivul desemnează o realitate simplă, fără un
comportament interesant, care este de fapt un atribut al altei clase.
Diagrama obiectelor
Diagramele obiectuale conţin obiecte şi legături. Ca şi celelalte diagrame, pot conţine note şi
restricţii. Mai pot conţine anumite pachete sau subsisteme, fiecare fiind folosite pentru a grupa
elementele modelului.
123
Aceste diagrame se folosesc pentru modelarea statică a unui sistem, ca diagramele de
clase, dar din perspectiva unor instanţe reale sau prototip.
Crearea unei diagrame conceptuale se face într-un singur mod, modelând 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 – conțin o mulțime de clase, interfețe si colaborări,
precum și relațiile dintre ele. Sunt cele mai folosite diagrame în modelarea
sistemelor orientate obiect, și ilustreaza vederea statică de proiectare a unui
sistem.
Diagrame de obiecte – conțin o mulțime de obiecte si relațiile dintre ele.
Sunt folosite pentru a ilustra structurile de date, imagini statice ale instanțelor
elementelor din diagramele de clase.
Diagrame de componente - conțin o mulțime de componente si relațile dintre
ele. Se folosesc pentru a ilustra vederea statică de implementare a unui
sistem.
Diagrame de amplasare - conțin o mulțime de noduri si relațiile dintre ele,
ilustrând 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 modalităților
principale de a modela dinamica unui sistem. Din această categorie fac parte:
Diagrame ale cazurilor de utilizare - arată o mulțime de cazuri de utilizare,
de actori (un tip special de clase) si relațiile dintre ele.
Diagrame de secventa. - pun în evidență ordinea temporală a mesajelor. O
diagramă de secvență arata o mulțime de obiecte împreună cu mesajele
expediate si recepționate de către acestea.
Diagrame de colaborare. - pun în evidență organizarea structurală a
obiectelor care trimit și recepționează mesaje. O diagramă de colaborare
arată o mulțime de obiecte, legăturile dintre aceste obiecte, împreună cu
mesajele expediate și receptionate de către acestea.
124
Diagrame de tranziție a stărilor – conțin mașini cu stări, ce constau în stări,
tranziții, evenimente și activități. 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 activități, fluxul secvențial sau ramificat de
la o activitate la alta, si obiectele care acționează sau sunt acționate 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 obţine o diagramă din alta).
Acest tip de diagrame înlesneşte înţelegerea cazurilor de utilizare mai dificile. Ele pot,
de asemenea, susţine comunicarea în cadrul echipei de proiectare, în cazul în care de o
aceeaşi interacţiune se ocupă mai multe persoane sau grupuri de persoane. Nu e de aşteptat să
se dezvolte astfel de diagrame pentru fiecare caz de utilizare sau pentru fiecare operaţie, doar
dacă beneficiile depăşesc costurile. În cazul în care se dispune de un CASE ce poate utiliza
aceste diagrame la generarea de cod, atunci devine profitabil să dezvoltăm diagrame de
interacţiune şi diagrame de comportament.
Diagramele de secvenţă descriu modul în care obiectele interacţionează şi comunică
între ele. Aceste diagrame permit focalizarea atenţiei asupra secvenţelor de mesaje, mai precis
asupra mesajelor care sunt trimise şi recepţionate de către obiecte.
Avantajul major al diagramelor de secvenţă, faţă de diagramele de colaborare, este posibilitatea
de a reprezenta grafic trecerea timpului, fiind deci indispensabile în căzul proiectării de sisteme
în timp real.
Diagramele de colaborare permit evidenţierea atât a interacţiunilor, cât şi a legăturilor
dintre un set de obiecte care colaborează. Atât diagramele de secvenţă, cât şi cele de
colaborare vizualizează interacţiunile, dar diagrama de secvenţă ia în considerare timpul, pe
când cea de colaborare, spaţiul.
Ca şi diagramele de secvenţă, diagramele de colaborare pot fi utilizate pentru înscrierea
execuţiei unei operaţii, a unui caz de utilizare sau a unui scenariu de interacţiune în cadrul
sistemului. În acest tip de diagramă nu pot fi descrise mesajele concurente şi asincrone.
Până acum nu am amintit nimic despre modelarea „deciziei" unui obiect despre ceea
ce să facă la primirea unui mesaj. Diagramele de interacţiune pot reprezenta obiecte diferite ale
aceleiaşi clase care primesc acelaşi mesaj, dar răspund diferit. Acest comportament este
rezonabil de cele mai multe ori, întrucât comportamentul unui obiect poate fi afectat şi de valorile
125
atributelor sale. Pentru a putea implementa, întreţine sau testa o clasă este necesar să
înţelegem relaţiile de dependenţă care există între starea unui anumi: obiect şi reacţiile sale la
mesajele primite sau la alte evenimente.
Diagramele de stare sunt acelea care înregistrează aceste dependenţe.
Pornind de aici, se pot folosi aproximativ aceleaşi notaţii pentru a descrie activităţ complexe. Se
consideră că trecerea de la o activitate la alta atunci când prima activitate s-a încheiat este
similară cu trecerea unui obiect dintr-o stare într-alta, semnificativ diferită de prima, atunci când
acesta primeşte un mesaj. Diagramele de activitate sunt o variaţiune a diagramelor de stare,
adaptate pentru a evidenţia conexiunile şi dependenţele dintre activităţi. Ele sunt extrem de
folositoare atunci când se apreciază că o activitate trebuie să execute o serie de task-uri diferite
şi dorim să modelăm dependenţele esenţiale 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 stărilor în care se poate găsi un obiect şi a evenimentelor (mesaje
primite, erori, condiţii care devin adevărate) care-i afectează starea de-a lungul execuţiei. O
diagramă de stare poate fi ataşată oricărei clase care are stări clar identificabile şi un
comportament complex.
O diagramă de activitate constituie o variantă a diagramei de stare, cu un scop puţin
diferit, acela de a evidenţia acţiuni şi rezultate ale acestor acţiuni. De fapt, diagramele de
activitate constituie o cale alternativă de descriere a interacţiunilor.
Diagramele de activitate pot fi utilizate şi pentru a descrie cum se desfăşoară 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 acţiunilor care vor fi realizate atunci când este executată o operaţie. Acesta
este şi cel mai comun caz de utilizare a acestui tip de diagramă.
- Prezentarea activităţii interne a unui obiect.
- Identificarea acţiunilor care pot fi realizate în mod legat şi stabilirea modului în care
aceste seturi de acţiuni afectează obiectele din jur.
- Ilustrarea modului în care instanţa unui caz de utilizare poate fi realizată în termenii
acţiunilor sau modificărilor intervenite în starea obiectului.
- Ilustrarea modului în care este organizată munca actorilor, care este organizarea şi
obiectele folosite.
126
Dezvoltarea sistemelor informatice folosind procesul unificat(UML)
Proiectarea orientată obiect îşi găseşte justificarea în cerinţa imperioasă de a face faţă
şi a oferi soluţii superioare calitativ în special sistemelor informatice de mari dimensiuni şi nivel
ridicat de complexitate.
Interesul manifestat faţă de abordarea obiectuală, în programare mai întâi şi, prin forţa
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 cercetări şi metode. De altfel, documentul oficial defineşte UML drept o colecţie a
celor mai bune practici aplicate în modelarea sistemelor informatice de mari dimensiuni şi
complexitate.
UML a fost definit pornind de la rolul esenţial 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 notaţie şi un set de
reguli de utilizare. Pentru un plus de rigoare şi claritate a definirii, conceptele de bază sunt, la
rândul 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 notaţiei prin care sunt referite şi folosite acestea. În alţi termeni, fiecare
metamodel defineşte elementele de modelare şi regulile după care se compun acestea în
modele.
Notaţia 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, începând cu viziunea schematică iniţială şi
până la viziunea terminală, suficient de detaliată pentru a oferi toate amănuntele necesare
traducerii directe în program sursă. Aplicate în acest context, rigoarea şi consistenţa cu care
sunt definite conceptele sale au făcut din UML baza mai multor instrumente CASE, aşa cum
este Rational Rose. Acestea nu numai că asistă analiza şi proiectarea prin mijloace specifice,
dar sunt capabile şi de generarea automată a unei părţi 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 construcţiile specifice unui limbaj de programare sau altul.
127
Diversele metode obiectuale, inclusiv cele care ua stat la originea UML, preconizează
diferite procese de dezvoltare a sistemelor. Procesul este cel care prescrie activităţile şi ordinea
în care trebuie realizate, rezultatele de obţinut din fiecare activitate, criteriile de evaluare a
calităţii şi de măsurare ş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 rândul său, unificat.
Procesul unificat poate fi caracterizat prin următoarele trăsături cheie:
este iterativ şi incremental;
este dirijat de cazurile de utilizare;
este centrat pe arhitectură;
este pilotat de riscuri.
Conform primei trăsături, dezvoltarea are loc prin mai multe iteraţii succesive, în fiecare
dintre acestea abordându-se doar o porţiune a sistemului său doar anumite aspecte ale
proiectări şi realizării. În felul acesta se renunţă la ideea de a defini în totalitate detaliile aferente
unei anumite etape înainte de a trece la următoarea. De această dată, se acceptă o definire
parţială, pe baza căreia se construieşte un produs la care se revine, într-o nouă iteraţie, cu
modificări sau cu noi detalii sau funcţii – aspectul incremental – până la obţinerea sistemului
final. Progresul proiectului poate fi mai bine controlat, iar experienţa acumulată în cursul unei
iteraţii poate fi utilizată în cele care urmează.
Cazurile de utilizare constituie punctul central al edificiului: în stadiul iniţial, ele definesc
utilizatorii şi cerinţele acestora sub forma actorilor şi a interacţiunilor dorite ale acestora cu
sistemul. Aceleaşi cazuri de utilizare vor constitui punctul iniţial în definirea cerinţelor şi referinţa
pentru proiectare şi realizare, iar setul de teste prin care este verificat sistemul se va defini tot pe
baza lor. Prin posibilitatea de a regăsi permanent legătura cu cazul de utilizare în cursul
întregului ciclu de dezvoltare, se răspunde şi cerinţei de asigurare a trasabilităţii.
UML asigură prezentarea diferitelor aspecte ale sistemului modelat sub forma unor abstractizări
ce constau într-o secvenţă de diagrame5
5 Davidescu N. – Proiectarea Sistemelor Informatice prin limbajul UML, Editura ALL Back, Bucureşti
128
Înlănţuirea 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 următoarea, ceea ce conferă ansamblului un
caracter de confidenţialitate. Pentru fiecare fază, anumite rezultate sunt folosite drept balize de
evaluare şi servesc pentru a măsura progresul înregistrat de proiect.
Fazele ciclului de dezvoltare sunt următoarele: studiul preliminar, elaborarea, construcţia, şi
tranziţia.
Studiul preliminar (“inception” în terminologia de origine) urmăreşte definirea amplasării
viitorului sistem în cadrul activităţii organizaţiei. Aceasta include delimitarea ariei de cuprindere,
stabilirea obiectivelor, studiul fezabilităţii în contextul unuia sau mai multor modele de afaceri.
Rezultatul cheie al fazei este viziunea sistemului, care conţine o descriere foarte sintetică în
care se precizează ce este sistemul, cine îl va utiliza, ce facilităţi trebuie să asigure şi la ce
restricţii trebuie să răspundă. Viziunea constituie şi principala baliză de evaluare a studiului
preliminar.
Elaborarea asigură colectarea şi precizarea cerinţelor funcţionale şi nefuncţionale ale viitorului
sistem. Cum utilizatorii sistemului şi cerinţele acestora sunt specificate prin intermediul cazurilor
de utilizare, modelul detaliat al acestora constituie unul dintre “artefactele” de bază şi, în acelaşi
timp, baliză de evaluare a fazei. Un alt rezultat esenţial, strâns legat de precedentul şi inclus în
balizele de evaluare de bază, este reprezentat de arhitectura sistemului.
Construcţia asigură obţinerea sistemului, incluzând 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.
Tranziţia asigură introducerea în exploatare a sistemului la utilizator. Aici se regăsesc
configurarea, instalarea, furnizarea documentaţiei, instruirea şi eventual formarea personalului.
Principala baliză de evaluare este versiunea finală a sistemului.
Sistemul informatic obţinut în urma parcurgerii celor patru faze poate solicita modificări
ulterioare pentru asigurarea evoluţiei sale. Pentru referirea la asemenea stadii evolutive, se
Diagrame de
colaborare
Diagrame de
secvenţe
Diagrame de
clase
Diagrame de
activitate
Cazuri de
utilizare
129
foloseşte termenul de generaţie. În consecinţă, la terminarea primului ciclu de dezvoltare,
rezultă generaţia 1 a produsului software respectiv. Obţinerea unei noi generaţii presupune
reluarea ciclului, cu parcurgerea celor patru faze.
Activităţi şi iteraţii
Structurarea în cele patru faze ale ciclului de dezvoltare corespunde perspectivei
manageriale asupra procesului, în care atenţia este concentrată asupra aspectelor financiare,
strategice, de personal. Aspectele tehnice legate de conceperea şi realizarea sistemului sunt
proprii unei alte perspective a aceluiaşi proces, structură în activităţi şi iteraţii.
O activitate se realizează prin combinarea mai multor paşi. Pasul este componenta
elementară şi foloseşte anumite elemente de intrare pe care le modifică sau pe baza cărora
realizează alte elemente noi. Aceste intrări şi ieşiri sunt produse intermediare constând din
documente, modele, programe etc.
Există cinci activităţi de bază: definirea cerinţelor, analiza, proiectarea, implementarea şi
testarea.
Definirea cerinţelor se concentrează asupra identificării cerinţelor funcţionale şi nefuncţionale
ale sistemului. Această etapă furnizează imaginea exterioară a sistemului, adică imaginea
percepută de către utilizatorii săi.
Analiza urmăreşte obţinerea unui model al problemei de rezolvat, aşa cum apare aceasta la
nivelul activităţii reale de afaceri. Modelul este însă formulat în termeni informatici, prin clase de
obiecte, operaţii, interacţiuni etc. şi ignoră orice detaliu tehnic sau de implementare.
Proiectarea extinde sau adaptează modelul anterior pentru a răspunde cerinţelor tehnice şi
restricţiilor configuraţiei de calcul în care va funcţiona sistemul. Este etapa în care sunt luate în
considerare şi rezolvate problemele de persistenţă, de intefaţă, de comunicare etc. păstrând
î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 măsura în
care acestea corespund cerinţelor funcţionale şi nefuncţionale, sunt sigure în funcţionare.
Activităţile enumerate se bucură de o accepţiune aproape unanimă. Cu toate acestea
numeroşi autori le combină sau le completează.
Fiind vorba despre acelaşi proces privit din perspective diferite, există o suprapunere a fazelor şi
activităţilor. Deosebit de semnificativ este faptul că activităţile se pot regăsi în totalitate, chiar
dacă în proporţii diferite, în fiecare din cele patru faze. Spre exemplu, sunt posibile activităţi 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.
130
Teste de evaluare a cunoștințelor
1................... exprima doua categorii de cicluri de activitate: una derulanta inainte care
sintetizeaza sistemul nou si una inapoi pentru dobândirea sistemului si a componentelor sale
pentru o posibila reutilizare.
a. Modelul incremental; d. Modelul V;
b. Modelul X; e. Modelul evolutiv.
c. Modelul piramida
. 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. activităţii de cercetare-dezvoltare;
b. activităţii de producţie;
c. activităţii de comercializare.
4. Determinarea capacităţii de producţie şi utilizarea eficientă a acesteia reprezintă o
subactivitate a:
a. activităţii de producţie;
b. activităţii de cercetare-dezvoltare;
c. activităţii de comercializare;
d. activităţii de personal;
e. activităţii de desfacere.
5 Elaborarea normativelor şi normelor de consum pentru resursele materiale şi energetice este
o subactivitate a:
a. activităţii de producţie;
b. activităţii de desfacere;
131
c. activităţii de comercializare;
d. activităţii de cercetare-dezvoltare;
e. activităţii de personal.
6. Elaborarea normativelor şi normelor de muncă şi a consumurilor specifice de manoperă este
o subactivitatea a:
a. activităţii de cercetare-dezvoltare;
b. activităţii de producţie;
c. activităţii de comercializare.
7. Definirea ingredientelor şi a proceselor ce sunt utilizate în producţia continuă este o
subactivitatea a :
a. activităţii de producţie;
b. activităţii de cercetare-dezvoltare;
c. activităţii de comercializare.
8 Definirea secţiilor, operaţiilor şi ordinea lor, care intervin în fabricarea unui produs este o
subactivitate a:
a. activităţii de cercetare-dezvoltare;
b. activităţii de producţie;
c. activităţii de comercializare.
9.Specializarea claselor are ca punct de plecare:
a. programe de investitii, programe de aprovizionare si vânzare de bunuri, servicii si de
marketing
b. transmiterea si prelucrarea datelor, obtinerea de informatii
c. superclasa adaugând noi atribute relevante numai pentru anumite obiecte din clasa, creând
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
132
133
Capitolul 5
Implementarea, exploatarea şi întreţinerea sistemelor informatice
Obiective:
Identificarea fazelor de implementare a sistemelor informatice
Cunoașterea procedeelor de exploatare și întreținere a sistemelor infromatice
Elaborarea documentației de utilizare a sistemului informatic proiectat
Cuvinte cheie: metode de implementare a sistemelor informatice, metode de întreținere
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 dezvoltării
sistemelor informatice care se regăseşte î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
strânsă dintre realizatorii sistemului informatic şi beneficiarii acestuia. Este etapa în care
sistemul este supus la cea mai dificilă testare, cea a condiţiilor reale de funcţionare. Acum pot
apărea cazuri care nu au fost prevăzute de proiectanţi, la care sistemul nu este protejat.
Implementarea sistemului constă în punerea în practică a specificaţiilor logice şi are în vedere:
corelarea modulelor din punct de vedere al funcţiilor logice realizate (invocări, utilizări);
crearea interferenţei dintre module conform standardelor de intrare/ieşire;
ordinea în care modulele sunt codificate, testate şi implementate;
calitatea datelor şi destinaţia rapoartelor;
cerinţele fişierelor şi ale bazei de date (număr, conţinut, tipuri de date, tipuri de acces,
tipuri de înregistrări, etc.);
ordonanţa activităţilor de implementarea, instalarea şi de instruire specifice sistemului
considerat.
În cadrul acestei etape se testează, se verifică şi se asimilează de către beneficiar toate
soluţiile stabilite în etapele anterioare şi se validează rezultatele obţinute.
Mai întâi este necesară o pregătire a mediului în care va fi implementat sistemul informatic, ceea
ce poate însemna: instruirea personalului care urmează să exploateze sistemul, asigurarea
condiţiilor organizatorice necesare funcţionării sistemului, asigurarea resurselor hardware
necesare, asigurarea fondului informaţional.
134
Implementarea începe în momentul în care toate componentele au fost testate
individual şi permit asamblarea fiecărei aplicaţii şi a întregului sistem informatic. Aceste
componente înglobează, pe de o parte, procedurile manuale folosite pentru pregătirea şi
testarea documentelor în vederea prelucrării, efectuarea corecţiilor, interpretarea şi utilizarea
rezultatelor, iar, pe de altă parte, procedurile prin intermediul cărora are loc realizarea efectivă a
funcţionalităţii sistemului informatic.
În timpul implementării, numeroase activităţi vor fi executate simultan. De aceea, ele
trebuie să fie planificate şi programate de către o echipă de implementare formată din utilizatori,
manageri şi specialişti în proiectarea sistemelor.
Planificarea implementării, firesc, începe anterior demarării unei astfel de acţiuni. De
fapt, problemele implementării sunt abordate chiar la începutul proiectului, iar aspectele
conceptuale şi strategiile implementării şi conversiei sistemelor trebuie luate în discuţie în
fiecare stadiu al ciclului de viaţă al sistemelor. Totuşi, planurile detaliate de implementare nu pot
fi finalizate până când conducerea nu aprobă proiectul noului sistem.
Un plan de implementare evidenţiază toate activităţile necesare, ajutând pe cei ce-l
întocmesc să fie siguri că totul a fost prezentat corect. Prin el se vor consemna toate activităţile
de efectuat, precum şi timpul alocat. Responsabilităţile de execuţie trebuie să fie foarte clare. De
asemenea, trebuie estimate costurile fiecărei activităţi astfel încât să poată fi elaborat un buget
special. În acelaşi timp trebuie determinate reperele de execuţie în timp, pentru a se putea
exercita controlul. Mai dificil este de estimat momentul când se va finaliza implementarea. De
fiecare dată utilizatorii sunt cei care îşi dau acceptul final, iar procesul, teoretic, poate fi
considerat ca desfăşurându-se pe o perioadă nedefinită.
Planul de implementare este revizuit şi modificat la intervenţiile comitetului de
informatizare, ale utilizatorilor, ale conducătorilor sistemului, înainte de a începe operaţiunea de
implementare.
Fazele procesului de implementare a sistemelor sunt redate în figura de mai jos :
135
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 decât modul de testare a programelor
Etapa de testare a sistemului are ca scop eliminarea (pe cît posibil) a erorilor şi
neajunsurilor sistemului informatic. Ea se aplică atât programelor individuale ale sistemului, cât
şi sistemului în ansamblul său (pentru testarea legăturilor între module). Metodele de testare
depind atât de nivelul la care se aplică, cât şi de tipul erorilor căutate.
Într-un sistem informatic se pot distinge următoarele tipuri de erori:
Erori de sintaxă, sunt acele tipuri de erori ce sunt detectate în faza de compilare şi sunt
datorate construcţiei greşite a unei instrucţiuni (lipsa unei paranteze, scrierea greşită a numelui
unei funcţii etc.);
Planificarea implementarii
Realizarea şi
testarea
programelor
Pregătirea
locurilor de muncă;
instalarea şi testarea
Selectarea şi
instruirea
personalului
Finalizarea
documentaţiei
Testarea
sistemului
Conversia de la
vechiul la noul
136
Erori de rulare (de execuţie) care sunt detectate la rularea programului şi sunt datorate folosirii
incorecte a comenzilor şi funcţiilor limbajului (chiar scrise corect din punct de vedere sintactic).
Exemple de asemenea erori sunt: folosirea unei variabile neiniţializate, încercarea de a scrie
într-o fereastră la coordonate mai mari decât dimensiunea acesteia etc.;
Erori de algoritm – programul nu generează erori nici la compilare, nici la rulare, dar rezultatele
obţinute nu sunt cele aşteptate, corecte;
Erori de utilizare – sistemul funcţionează corect, dar utilizatorul îl foloseşte greşit.
Erorile cel mai simplu de detectat, sunt cele de compilare, ele fiind sesizate automat la
compilarea unui fişier sursă, urmează apoi erorile de rulare, care sunt de asemenea detectate şi
sesizate automat, dar la execuţia programului în cauză. La detectarea unei astfel de erori
compilatorul furnizează un mesaj de eroare care ne indică natura şi eventual cauza erorii
respective, cât şi linia din fişierul 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,
generând confuzie şi îngreunând depana-rea. Acest lucru se datorează unor erori care sunt
consecinţe ale altor erori nedetectate anterior.
Erorile de algoritm sunt mai greu de detectat decât 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 funcţionează corect, utilizatorul, fiind cel nemulţumit
de rezultatele obţinute.
Erorile de utilizare sunt acele erori datorate folosirii incorecte a sistemului, chiar dacă el este
corect conceput.
Sistemul informatic trebuie să fie cât maibine protejat contra unor astfel de erori, adică:
să nu permită utilizatorului introducerea unor date greşite, lucru posibil prin
implementarea unor proceduri de validare cât mai performante, mai compete;
să pună la dispoziţia utilizatorului numai acele opţiunicare au sens la un moment dat
(celelalte să fie dezactivate);
să avertizeze utilizatorul în cazul detectării intenţiei de execuţie a unor operaţii suspecte
a fi greşite (cele despre care avem certitudinea că sunt greşite să nu fie permise deloc);
să ofere cât mai multe informaţii de ajutor prin intermediul unul subsistem de ajutor
permanent;
să posede o documentaţiecât mai clară, explicită, completă, la nivelul celui mai slab
pregătit utilizator etc.
137
Cu toate măsurile de precauţie luate de proiectant aceste erori nu pot fi eliminate complet
datorită acelor situaţii de natură subiectivă, care nu pot fi controlate în totalitatede sistem, ci se
bazează, total sau parţial, pe gândirea 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 următoarele tipuri de erori:
la nivelul sistemului de operare – aceste erori se datorează configurării greşite a
sistemului de operare sau SGBD-ului, sau incompatibilităţii 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 legătura dintre module şi se
obţin atunci când fiecare modul în parte lucrează bine, dar când modulele sunt
încorporate în sistemul integrat între ele apar incompatibilităţi;
erorile sau neajunsurile de proiectare – sunt erori ce ţin de concepţia de ansamblu a
sistemului.
Un exemplu de astfel de erori, este omiterea unui câmp la proiectarea unei baze de date,
câmp î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 adăugare a unei noi
facilităţi sistemului, care solicită date noi, neprevăzute la proiectare, sau care nu se potriveşte cu
metodele şi tehnicile folosite în sistem.
Efortul necesar eliminării unei erori este direct proporţional cu nivelul erorii respective. Cu
alte cuvinte, cu cât nivelul la care apare eroarea este mai ridicat, cu atât efortul de detectare şi
de înlăturare 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ă corecţia.
Testarea nu se încheie decât atunci când se efectuează lansarea prelucrării de către
întreaga aplicaţie informatică cu un set complet de date. Acest set va include toate datele
posibile, corecte şi eronate pentru a urmări reacţia întregului pachet de programe. În această
testare globală se urmăreşte: validarea datelor de intrare şi a rezultatelor, dialogul din sistemul
informatic, modul de operare la execuţie. Se urmăresc atât aspectele formale cât şi cele de
fond.
138
În literatura de specialitate sunt enumerate şapte categorii de teste ale softului. Acestea
se diferenţiază în funcţie de modul în care acestea angajează tehnici dinamice sau statice,
precum şi în funcţie de modul de efectuare, automat sau manual.
Testarea statică înseamnă verificarea programelor sursă fără ca acestea să fie executate, iar
cea dinamică înseamnă şi execuţia programului sursă.
Testarea automată este efectuată sub controlul calculatorului, în timp ce testarea manuală se
desfăşoară sub controlul omului.
Sintetic, cele şapte categorii de teste sunt redate în tabelul de mai jos:
Examinările sunt activităţi prestate de grupuri de persoane cu scopul depistării manuale a
apariţiei unor erori binecunoscute în codurile programelor sursă. Prin urmărirea atentă a
instrucţiunilor programelor sursă se depistează între 60 şi 90% dintre erorile ce pot apărea în
acestea.
Execuţia de probă, spre deosebire de examinarea liniilor programelor sursă, care nu urmăreşte
şi efectul fiecărei instrucţiuni, îşi propune să descopere erorile regăsite în fiecare cod al
programului sursă. Execuţia de probă trebuie efectuată cât mai des, pe parcursul finalizării unor
părţi din lucrare(program). Rolul execuţiei 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
înţelege logica programului îl parcurge, linie cu linie, cu un creion şi o foaie de hârtie. Verificarea
nu presupune neaparat şi execuţia pe calculator, ci programatorul urmăreste cu atenţie efectul
fiecărei instrucţiuni a programului.
Validarea sintactică este singura tehnică de verificare automată statică executată, de regulă,
de către compilatoare. Rolul acestora este de a scoate la iveală erorile programului sursă fără
însă a-l executa. Toate celelalte tehnici automate presupun şi execuţia codului instrucţiunilor.
Testarea pe componente este, deseori, cunoscută şi ca testarea modulelor, deoarece fiecare
modul este testat de sine stătător.
Tip testare Manuală Automată
Statică Dinamică
Examinări Execuţia de probă Verificare de birou
Validarea sintactică Testarea pe componente Testarea integrităţii Testarea sistemului
139
Testarea integrităţii este o continuare a celei descrise anterior, întrucât ea se efectuează cu
scopul verificării modului în care se intercondiţionează modulele, cu alte cuvinte se testează un
grup de module. Testarea integrităţii este graduală. În primul rând, se testează modulul
coordonator, adică modulul-rădăcina dintr-o structură arborescentă, şi doar unul dintre modulele
subordonate. După ce sunt testate modulele subordonate aflate pe acelaşi 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. Operaţiunea este efectuată de personalul specializat în sisteme
informatice, sub coordonarea şefului de proiect, sau de către utilizatori, sub controlul
specialiştilor în informatică.
După ce testele sistemului au fost încununate cu succes, sistemul este supus testării de
acceptare, într-un mediu similar celui în care va fi pus în funcţiune şi de către persoanele care îl
vor întrebuinţa. Un test complet de acceptare constă în efectuarea testării alfa şi a testării 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 câteva teste edificatoare, dupa cum urmează :
testarea regenerării sau refacerii forţeaza execuţia softului astfel încât să înregistreze
eşecuri pentru a se verifica modul în care sistemul revine la normal ;
testarea securităţii verifică dacă mecanismele de protecţie aflate în sistem acţionează
corespunzator împotriva posibilelor atacuri ;
testarea la suprasolicitări determină modul în care sistemul execută operaţiunile în
condiţii de lucru diferite (cu configuraţii de echipamente variate, cu anumite reţele,
sisteme de operare ş.a.).
Testarea beta se derulează cu exerciţii proprii utilizatorilor şi cu datele concrete ale acestora. Ea
este un fel de repetiţie generală înaintea instalării.
Posibilele erori ale softului se pot datora :
incorectei contorizări a numărului de execuţii ale unor bucle ;
introducerii incomplete a datelor ;
realizării unor interfeţe eronate între module;
depăşirii dimensiunilor unor tablouri(masive) de date ş.a.
Pentru aprecierea calităţii softului s-au propus mai mulţi indicatori :
rata defectelor pe oră, zi, săptamână sau lună ;
140
rata defectelor pe echipamentele de bază ale softului;
timpul mediu între două defecţiuni;
mărimea zonei afectate de defecte;
numărul compilărilor sau al execuţiilor unor componente ale sistemului care
funcţionează corect din prima încercare ;
defecte cumulate pe versiune;
oportunitatea răspunsului la defecte sau a timpului afectat îndepărtării lor ;
satisfacţia beneficiarului privind calitatea intervenţiei pentru remedierea defectelor soft.
Din toate aceste modalităţi de evaluare, cantitativă şi calitativă, rezultă că preocupările pentru
utilizarea unui soft de calitate trebuie să existe la toate nivelurile ierarhice ale organizaţiei.
5.1.2 Instalarea sistemului
Această fază asigură verificarea funcţionalităţii sistemului cu date reale, motiv pentru care se pot
folosi anumite tactici şi strategii în funcţie 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 funcţie de aceste elemente funcţionarea experimentală poate funcţiona în cinci variante.
1)Implementarea directă cu date curente a sistemului proiectat, presupune renunţarea la
vechiul sistem brusc, în vederea reducerii termenului şi a minimizării cheltuielilor cu
implementarea. Avantajele acestei metode sunt costul mai scăzut şi o certitudine a
implementării, în schimb riscurile sunt mai mari, datorită faptului că activitatea sistemului
economic se bazează acum pe sistemul informatic, iar o defecţiune în acesta din urmă putând
duce la blocarea activităţii. De aceea această strategie nu se recomandă în cazul activităţilor
critice, în flux continuu, care nu suportă întârzieri.
2) Implementarea paralelă se face cu date curente sau anterioare pentru a se realiza o
comparaţie î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
funcţionarea sistemului informatic nu conduc la blocarea activităţii din unitatea economică, în
Vechiul sistem
Noul sistem
141
schimb este foarte costisitoare, toacmai datorită faptului că, pentru o perioadă de timp trebuie
suportate costurile funcţionării ambelor sisteme.
3) Implementarea pilotată urmăreşte lansarea în experimentare a sistemului proiectat începând
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ă decât cea
reală, dar care are caracteristicile definitorii ale acesteia. Această strategie se încadrează între
cele două anterioare, atât din punctul de vedere al costurilor, cât şi al riscurilor.
4) Implementarea compartimentală este utilizabilă în unităţile economice în care structurile
organizatorice prezintă autonomie prin prisma fluxurilor informaţionale.
În această variantă condiţia esenţială o constituie realizarea anterioară a proiectării de ansamblu
şi a celei de detaliu pe compartimente, caz în care rezultatele implementării pot fi comensurate
direct pe structurile organizatorice implicate.
5) Implementarea combinată poate fi abordată datorită avantajelor pe care le prezintă celelalte
variante prin folosirea implementării paralele cu cea pilotată.
Alegerea strategiei de implementare depinde de natura activităţii desfăşurate în sistemul
informatizat, de disponibilitaăţile materiale ale beneficiarului, de riscurile ce pot şi se acceptă a fi
asumate de beneficiar etc.
5.1.3 Verificarea performanţelor sistemului informatic proiectat
Această fază presupune exploatarea efectivă a sistemului cu date reale în vederea
îndeplinirii parametrilor proiectaţi, a termenelor de execuţie şi duratei de exploatare.
În finalul acestei faze se face evaluarea sistemului şi validarea rezultatelor obţinute, pentru a
verifica în ce măsură sunt satisfăcute obiectivele propuse şi dacă rezultatele noului sistem
justifică cheltuielile făcute cu introducerea şi realizarea lui.
Vechiul sistem
Noul sistem
Unitate pilot
Vechiul sistem
Noul sistem
142
Funcţionarea sistemului depinde de specificaţiile logice, care evidenţiază anumite
aspecte de natură logică ale funcţiilor sistemului (legături între intrări şi ieşiri, consideraţii asupra
volumului de date şi a frexvenţei lor, decizii de actualizare şi de întreţinere, modul de operare),
precum şi de specificaţiile fizice care în mod cert sunt mai importante pentru operatori.
Interpretarea şi transpunerea corectă a specificaţiilor logice pot să conducă la
îndeplinirea aşteptărilor scontate pentru viitor, în ciclul de viaţă al noului sistem, referitoare la
întreţinere, noile interfaţe lae sistemului, realocarea de funcţii în cadrul firmei etc, îsoţite de
reorganizarea corespunzătoare de personal calificat.
Evaluarea sistemului se face pe baza specificaţiilor logice şi fizice. Specificaţiile fizice
au în vedere volumul, frecvenţa, acurateţea, şi eroarea informaţiilor. Specificaţiile logice conţin
rareori indicatori necesari pentru evaluarea sistemului, însă arată modul în care sunt corelate
elementele resursei de informare şi evidenţiază unde şi când funcţionează aceste legături.
De exemplu, dacă specificaţiile logice arată că prelucrarea poate să înceapă numai
după ce s-a strâns un număr suficient de mare de facturi, acest fapt ne ajută să observăm cât
de bine este satisfăcut acest criteriu şi când este rezonabilă testarea pentru prelucrarea
facturilor.
De asemenea, detaliile legăturilor logice, cum ar fi succesiunea de intrări-ieşiri sau de invocări
de module, ne ajută să descoperim de unde provine ineficienţa.
Pe baza datelor provenite din exploaterea sistemului informatic, se determină eficienţa
economică şi se cuantifică raportul între performanţă şi cost.
Indicatorii eficienţei economice se calculează în toate etapele de realizare a sistemului
informatic, acordându-se o atenţie deosebită la sfârşitul primului an de exploatare efectivă.
În etapa de implementare se corectează indicatorii eficienţei economice estimaţi, în
timp ce în etapa de exploatare efectivă se calculează eficienţa economică reală pe baza
rezultatelor obţinute de unitatea beneficiară.
5.1.4 Elaborarea documentaţiei de utilizare a sistemului informatic proiectat.
În funcţie de modul de implementare a sistemului, pot apare anumite modificări în
concepţia acestuia, ca urmare a unor neajunsuri semnalate. Aceste modificări trebuie operate în
structura sistemului proiectat şi în documentaţia acestuia pentru a evita eventualele dificultăţi în
exploatarea şi întreţinerea ulterioară.
La terminarea fiecărei faze de dezvoltare a proiectului, liderul de proiect redactează un
raport care detaliază activităţile, constatările şi rezultatele acelei faze, precum şi planurile pentru
fazele următoare, document ce va fi supus spre avizare de către beneficiar.
Documentaţia se elaborează la momente specifice în timpul realizării proiectului, fie ca
urmare a directivelor utilizate, care în general sunt proceduri bazate pe documentaţie.
143
Definitivarea întregii documentaţii de utilizare şi exploatare a sistemului se concretizează în
întocmirea manualului de prezentare, utilizare şi operare.
Manualul de prezentare cuprinde concepţia generală a sistemului şi o prezentare
succintă a aplicaţiilor componente, făcându-se precizări în legătură cu restricţiile şi limitele
sistemului sau aplicaţiilor, inclusiv performanţele şi posibilităţile de extindere a acestora.
Manualul de utilizare este întocmit pentru fiecare aplicaţie, şi asigură descrierea
generală a aplicaţiei, datele de intrare, condiţiile de validare, restricţiile şi erorile ce pot apare,
condiţiile de reluare, şi se adresează personalului implicat în utilizarea noului sistem.
Manualul de operare conţine informaţii referitoare la exploatarea efectivă a sistemului
proiectat prin intermediul sistemului de calcul.
5.2 Exploatarea şi întreţinerea sistemului informatic
5.2.1 Exploatarea sistemului informatic
După ce implementarea a luat sfârşit, începe etapa de exploatare şi întreţinere a
sistemului informatic. Acum sistemul informatic funcţionează la parametri normali prevăzuţi de
proiectanţi. Activitatea de exploatare se reduce la execuţia curentă a operaţiilor de culegere a
datelor, transmitere, validare şi prelucrare a acestora, construirea şi consultarea situaţiilor de
informare-raportare.
Exploatarea curentă şi menţinerea în funcţiune a sistemului informatic presupun punerea în
stare operaţională a calculatorului şi a perifericelor, după care se continuă cu următoarele
operaţii:
restaurarea bibliotecilor de programe şi a bazei de date specifice noului sistem de pe
copiile de siguranţă obţinute la prelucrarea precedentă;
lansarea în execuţie a programelor pentru crearea şi actualizarea bazelor de date,
obţinerea listelor de control şi eliminarea erorilor;
exploatarea bazei de date în vederea obţinerii situaţiilor de ieşire;
verificarea corectitudinii rezultatelor obţinute prin control de verosimilitate sau sondaj;
stocarea pe dischete a ultimei versiuni a bazei de date în vederea conservării acestora
până la prelucrarea următoare.
În funcţie de experienţa dobândită în perioada exploatării noului sistem şi de rezultatele
obţinute ca urmare a informatizării activităţii unităţii beneficiare se pot efectua reorganizări în
structura serviciilor funcţionale, prin trecerea anumitor activităţi dintr-un compartiment într-altul,
reconsiderarea unor centre de decizie etc.
144
Exploatarea curentă şi menţinerea în funcţiune a sistemelor informatice, asigură
funcţionarea acestuia pe toată durata lui de execuţie. Ea încetează în situaţia în care se renunţă
la sistemul existent în funcţiune pentru a se trece la utilizarea altui sistem mai evoluat şi eficient.
5.2.2 Procesul de întreţinere a sistemelor informatice
Din totalul cheltuielilor generate de sistemele informaţionale ale unităţilor, cea mai mare
parte revine etapei de întreţinere, şi ca atare, personalul antrenat în întreţinere este cel mai
numeros. Întreţinerea începe odată cu instalarea sistemului şi se referă nu numai la
echipamente, ci şi la software şi la procedurile economice utilizate pe timpul exploatării
aplicaţiilor din sistem.
Întreţinerea sistemului informatic constă în totalul activităţilor desfăşurate pentru
asigurarea funcţionării sistemului la parametri normali, corectarea, eliminarea tuturor erorilor
care apar pe parcurs, dar şi introducerea în sistem a unor îmbunătăţiri, perfecţionări,
modernizări etc., menite să crească nivelul parametrilor de funcţionare ai sistemului economic.
Un aspect important se referă la durata etapei de întreţinere, după unele păreri ar fi de
5 ani, după altele 10 sau mai mulţi. Răspunsul poate varia de la un caz la altul, tendinţa fiind de
creştere a perioadei de întreţinere şi implicit a costurilor aferente.
Pe timpul întreţinerii un grup de persoane se va ocupa de colectarea cererilor de întreţinere
lansate de utilizatori sau de alte părţi implicate în exploatarea sistemului sau verificarea modului
în care acesta funcţionează.Activităţile implicate de întreţinerea sistemului sunt:
obţinerea cererilor de întreţinere;
transformarea cererilor în propuneri de schimbări;
proiectarea schimbărilor;
implementarea schimbărilor.
Perfecţionarea sistemului informatic presupune:
folosirea de tehnică de calcul care să permită înregistrarea directă a datelor de intrare
la locul şi-n momentul producerii lor;
perfecţionarea sistemului de operare prin optimizarea programelor şi a tehnicii de
operare;
optimizarea şi parametrizarea programelor care să asigure portabilitatea acestora;
utilizarea reţelelor de calculatoare pentru realizarea obiectivelor din unitatea economică
beneficiară.
Întrucât cheltuielile de întreţinere au o pondere substanţială în structura costurilor totale ale
sistemelor, considerăm relevantă prezentarea tipurilor de întreţinere: corectivă, adaptativă,
perfectivă, conform figurii 5.2
145
Întreţinerea corectivă constă în efectuarea unor lucrări de reparaţii pentru îndepărtarea
unor defecte produse în timpul proiectării, scrierii programelor sau implementării sistemului. În
majoritatea cazurilor, întreţinerea corectivă intervine imediat ce se pune în funcţiune noul sistem
sau o componentă a acestuia. Cât timp o astfel de întreţinere îşi propune doar să îndepărteze
defecte, ea nu adaugă valoare decât într-o pondere derizorie, în pofida celor 75 de procente
alocate întreţinerilor corective din totalul activitătilor de întreţinere a sistemului.
Întreţinerea adaptativă presupune efectuarea unor schimbări în sistem, condiţionate de:
intenţia de îmbunătăţire a performanţelor funcţionale; adaptarea la schimbările organizaţionale;
deplasarea sferei de activitate a unităţii în alt mediu.
Dacă întreţinerea corectivă presupune o intervenţie cât mai urgentă în urma sesizărilor
venite din sistem, cea adaptivă nu este la fel de presantă, întrucât factorii care o condiţionează
nu au apariţii spontane. O altă diferenţă constă în faptul că întreţinerea adaptivă, spre deosebire
de cea corectivă, adaugă valoare organizaţiei.
Întreţinerea perfectivă are ca scop efectuarea unor schimbări pentru îmbunătăţirea
diverselor prelucrări, modificarea cu scopul folosirii mai uşoare a interfeţelor sau pentru a i se
adăuga noi elemente, care însă nu sunt strict necesare. O astfel de operaţiune de întreţinere
constituie mai curând o dezvoltare a sistemului şi face parte din categoria activităţilor care
adaugă valoare organizaţiei.
Întreţinerea preventivă se efectuează cu scopul diminuării substanţiale a posibilităţilor
de defectare a sistemului, adaugă valoare organizaţiei.
Costurile mentenanţei unui sistem sunt influenţate de câteva elemente principale:
în fazele de evaluare / proiectare nu pot fi luate în considerare toate scenariile privind
funcţionarea sistemului;
un sistem mare este proiectat şi implementat de către mai multe echipe, în perioade
diferite, ceea ce implică o bună coordonare a activităţii lor şi poate conduce la
8% 12% 5%
75%
Fig. 6.2 Ponderile tipurilor de activitate de întreţinere în totalul activităţii deîntreţinere a sistemelor aferente
Adaptiva
Perfectiva
Preventiva
Corectiva
146
generarea unor soluţii a căror integrare ridică uneori probleme în timpul exploatării;
dezvoltarea unui sistem informatic este un proces de durată şi pe parcursul proiectării şi
implementării pot să apară modificări majore în ceea ce priveşte : legislaţia,
performanţele echipamentelor şi produselor programului, orientarea activităţii
organizaţiei, forma de proprietate, strategia managerială;
personalul care deserveşte sistemul, câştigă experienţă şi înţelege din ce în ce mai
bine ce ar trebui să facă, uneori în opoziţie cu ce face.
Activitatea de mentenanţă trebuie evaluată pentru a observa dacă, la un moment dat,
cheltuielile implicate nu depăşesc limitele acceptabile. Dacă la un moment dat se constată că
beneficiarele sunt puternic afectate de cheltuielile cu mentenanţa, se poate concluziona că
sistemul nu mai răspunde necesităţilor şi este necesară înlocuirea sa parţială sau totală. În felul
acesta se reia ciclul de viaţă al dezvoltării sistemului.
5.2.3 Documentaţia necesară exploatării şi întreţinerii sistemului informatic
Exploatarea noului sistem informatic se va realiza conform instrucţiunilor de exploatare
prevăzute în manualul de utilizare. Aceste instrucţiuni se adresează în principal utilizatorilor
finali, adică beneficiarilor propriu-zişi ai sistemului informatic şi pot fi completate cu procedurile
de autodocumentare cuprinse în produsul program.
Manualul de utilizare şi exploatare cuprinde următoarele instrucţiuni de utilizare şi exploatare:
Instrucţiuni de utilizare
- proceduri de codificare a datelor prin care se dau instrucţiuni 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
codificări automate pe care le face sistemul;
- proceduri de încărcare/validare date, prin care se dau instrucţiuni despre popularea
colecţiilor de date. Aici se precizează documentele primare din care se preiau datelor şi
modul de completare al acestora. Prin comparaţie se prezintă machetele de intrare şi
videoformatele aferente documentelor primare. Se precizează şi corelaţiile care trebuie
să existe între diferitele date încărcate. Toate aceste instrucţiuni sunt utile utilizatorului
pentru actualizarea datelor din colecţiile de date. Pentru alegerea colecţiei de date pe
care se va lucra, precum şi a operaţiei care se va efectua, utilizare a sistemului de
meniuri oferit de produsul program;
- proceduri de obţinere a situaţiilor de ieşire, prin care se dau instrucţiuni despre modul
de afişare şi interpretare a rapoartelor, listelor etc. Se prezintă pentru fiecare situaţie de
ieşire macheta, conţinutul, periodicitatea de obţinere şi se dau exemple. Instruţiunile
vizează nu numai modul de obţinere a situaţiilor de ieşire, dar şi interpretarea acestora.
147
Se precizează semnificaţia datelor conţinute în situaţia de ieşire şi eventualele corelaţii
dintre date şi cheile de control.. În final se indică modul de difuzare şi arhivare a
situaţiilor de ieşire;
- alte proceduri speciale prin care se dau instrucţiuni despre eventualel conversii,
interfeţe, comunicaţii cerute de produsul program.
Instrucţiuni de exploatare
- eşalonarea în timp a procedurilor utilizate. Rezultatul este un grafic de exploatare a
procedurilor care trebuie să semene cât mai mult cu sistemul de meniuri al produsului
program. Ambele trebuie să ghideze utilizatorul în exploatarea produsului program:
ordines operaţiilor, succesiunea lor în timp, semnificaţia lor etc.
- proceduri privind datele de intrare. Se dau instrucţiuni privind primirea, controlul,
restituirea şi păstrarea documentelor din care se preiau datele de intrare. De
asemenea, se indică modul de pregătire a datelor de intrare pentru încărcare: reguli de
încărcare, de validare, de verificare.
Proceduri de asamblare lucrări. Se dă o listă a procedurilor automate şi se dau legăturile
dintre acestea. Se ajunge astfel la o schemă funcţională a procedurilor. Schema va oferi
variante de prelucrare şi va indica facilităţi şi restricţii de exploatare a produsului program.
Proceduri de operare. Se dau instrucţiuni privind pregătirea rulării şi apelului produsului program
(mod de apel şi ieşire, parolă de acces, fişiere necesare etc). Se indică o listă a mesajelor
apărute la exploatare, precum şi modul de acţiune al utilizatorului(răspunsuri, reluări etc). Se
dau indicaţii privind operarea cu sistemul de meniuri, cu videoformatele şi ferestrele produsului
program.
Proceduri privind situaţiile de ieşire. Se dau instrucţiuni privind obţinerea rezultatului şi
controlul de formă şi fond. Se indică numărul de exemplare necesare şi suportul tehnic de
informaţie pe care se va obţine fiecare situaţie de ieşire. Se specifică destinaţia şi modul de
arhivare a rapoartelor.
Întreţinerea sistemului informatic va avea la bază documentaţia întocmită în fiecare fază de
realizare a acestuia. Documentaţia 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 întreţinerii sistemului de la specificaţia de cerinţe până la
planul de test şi testarea finală a acestuia, dintre care amintim:
Specificaţiile de cerinţe ale sistemului;
Arhitectura generală a sistemului cu evidenţierea intrărilor, procedurilor de control şi
validare a datelor, colecţiile de date, procedurile de editare a situaţiilor de
informare/raportare, ieşirile sistemului, resursele hardware/software folosite etc.;
148
Arhitectura programelor şi schemelor logice de realizare a fiecărui program;
Videoformatele de intrare/ieşire;
Programele sursă, listate şi comentate;
Specificaţiile de validare a datelor care descriu cum fiecare program e validat şi cum se
leagă informaţiile de validare cu cerinţele informaţionale ale utilizatorilor;
Un ghid de întreţinere de sistem care descrie care părţi din sistem depind de hardware
şi care de software.
Teste de evaluare a cunoștințelor
1. Fazele procesului de implementare a sistemelor informatice sunt:
a. realizarea şi testarea programelor;
b. pregătirea 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 următoarele tipuri de erori:
a. erori de sintaxă;
b. erori de execuţie;
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 apărea 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.
149
4. Testarea de acceptare a noului sistem informatic constă în:
a. testarea utilizatorilor;
b. testarea regenerării sau refacerii;
c. testarea securităţii;
d. testarea la suprasolicitări;
a. a+b+c+d;
b. b+c+d;
c. a+b+c
d. a+b+d
5. Care din următoarele tipuri de întreţinere deţine ponderea cea mai mare în totalul activităţii
de întreţinere :
a. întreţinerea adaptivă;
b. întreţinerea perfectivă;
c. întreţinerea preventivă;
d. întreţinerea 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.
150
151
Capitolul 6
Aplicațiile sistemelor informatice
Obiective:
Familiarizarea cu utilizarea facilităților 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 aplicaţii funcţionale
Cuvinte cheie:limbaj de programare, programare structurală, programare modulară,
programare dirijată de evenimente,linii de cod, variabile de memorie.
6.1 Selecția tehnicii de programare și a limbajului utilizat
Un program reprezintă o succesiune de instrucţiuni , realizată în conformitate cu
regulile limbajului de programare folosit, care rezolvă o anumită problemă, îndeplineşte o
anumită sarcină, printr-un anumit algoritm.
Scrierea unui anumit program înseamnă stabilirea instrucţiunilor care alcătuiesc
programul, a ordinii acestora în cadrul programului şi transmiterea lor spre calculator.
În proiectarea de aplicaţii se foloseşte tot mai mult programarea modulară. Dacă programarea
structurală oferea un program care îl dirija pe utilizator pas cu pas, fără posibilitatea alegerii altei
opţiuni, programarea modulară constă dintr–un ansamblu de subrutine (proceduri sau
subprograme) care pot fi apelate în ordinea dorită de utilizator.
Alegerea tehnicii de programare aparţine programatorului care va ţine cont de factorii
obiectivi (impuşi de realitatea care trebuie modelată) şi subiectivi (dictaţi de experienţa proprie
acumulată prin teme rezolvate în acelaşi domeniu care pot fi caracterizate ca asemănătoare cu
proiectul curent de rezolvat).
Limbajele de programare au apărut şi s-au dezvoltat în strânsă legătură cu evoluţia
hardware-ului. În prezent, o largă răspândire au dobândit 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ă generaţia a cincea a
calculatoarelor determină apariţia unor limbaje corespunzătoare modului de programare
“natural”, solicitând formarea unei noi generaţii de programatori.
Sistemele orientate-obiect reunesc însumarea unor avantaje obţinute de SGBD care
interoghează eficient datele şi limbajele procedurale care permit calcule complexe. Bazele de
152
date orientate pe obiecte permit crearea de obiecte complexe, din componente simple, fiecare
având 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 către
noi aplicaţii; facilitatea concepţiei realizată prin posibilităţi de generalizare şi agregare a relaţiilor;
evoluţia către multimedia (sunet, imagine, texte); posibilităţi de deducţie superioară (ierarhie de
clase, moştenire); ameliorarea interfeţei cu utilizatorul; posibilităţi de tratare pentru aspect
dinamic, integrarea descrierii structurale şi comportamentale.
Un SGBD-OO trebuie să satisfacă următoarele criterii fundamentale:
- Să fie un sistem orientat pe obiecte;
- Să indeplineasca cerinţele unui sistem de gestiune a bazelor de date.
Arhitectura unui SGBD-OO trebuie să conţină trei componente majore:
1. Gestionarul de obiecte care asigură interfaţa dintre procesele sau prelucrările
externe ale SGBD-OO.
2. Serverul de obiecte care este responsabil cu asigurarea serviciilor de bază ale
SGBD-urilor cum ar fi gestiunea tranzacţiilor, gestiunea stocului de obiecte.
3. Stocul rezident de obiecte.
În prezent SGBD-OO sunt accesate în primul rând prin limbajele de programare orientate pe
obiecte cum ar fi: C++, Visual Basic pentru aplicaţii (VBA) Access, SQL etc.
Figura 6. 1 Corelarea diferitelor soluţii 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 regăsirea şi actualizarea obiectelor. În opoziţie cu multe
SGBD convenţionale limbajul pentru baze de date al SGBD-OO este parte integrantă a
limbajului de programare orientat pe obiecte.
SGBD -OO
ACCESS
SQL
VBA
C ++
153
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 legăturilor de moştenire, definirea metodelor care
specifică comportamentul unui obiect;
- Limbajul de manipulare a datelor ( LMD) necesar pentru regăsirea, 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 regăsirea subseturilor unei baze de date şi
obiectelor individuale. Limbajul de cerere se bazează pe transmitere de mesaje pentru
selectarea şi regasirea obiectelor.
Alături de modelul programarii orientate spre obiecte a fost dezvoltat şi modelul programării
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 execuţie numai atunci când în sistem apar
anumite evenimente. Prin urmare, dacă în modelul clasic programarea era de tipul:
Vezi dacă... şi dacă da execută...
în modelul programării conduse de evenimente un program este o succesiune de secvente de
tipul:
Dacă apare evenimentul … execută ...
Apariţia evenimentelor este arbitrară pentru programul respectiv, el fiind învăţat cum să
răspundă atunci când survin acestea.
Programarea în Visual Basic pentru aplicaţii (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
împărţit în fragmente (blocuri) ataşate unui buton sau unei pictograme pentru a trata anumite
evenimente.
O dată cu avântul luat de mediile de dezvoltare de programe au apărut 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 opţiuni şi să construiasca tot
in mod interactiv diferite elemente, urmând 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 opţiunilor corespunzatoare.
154
Dintre sistemele de gestiune a bazelor de date existente astăzi, Access este unul dintre cele mai
complete şi performante. El nu este un simplu SGBD, ci este un mediu complex de dezvoltare
de aplicaţii pentru baze de date, construit pe principiile arhitecturii deschise. Access este
integrat în pachetul Microsoft Office, având facilităţi corespunzătoare de interacţiune cu celelalte
module (Word, Excel, Outlook etc).
Access încorporează un maximum de posibilităţi de abordare a unei baze de date,
având integrate cele mai importante modele de proiectare a acesteia. Sistemul Access oferă un
set complet de instrumente, unele suficient de sofisticate pentru programatorii profesionişti,
altele uşor de folosit de către utilizatorii noi.
Cu Access, orice utilizator îşi poate crea soluţiile cele mai convenabile prin care
accesul, organizarea şi distribuţia informaţiilor într-o organizaţie se poate face mai uşor şi mai
sigur ca niciodată.
În Visual Basic pentru Aplicaţii încorporat în Access există unelte vizuale pentru
construirea majorităţii elementelor unei aplicaţii, tabele, forme, interogări, rapoarte, controale,
module etc. De asemenea Visual Basic pentru Aplicaţii conţine 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 funcţii. Distingem momentul construirii
funcţiei de cel al apelului în vederea executării.
Construirea funcţiei presupune următoarele etape:
definirea algoritmului de prelucrare a datelor ;
codificarea algoritmului în limbajul VBA;
introducerea şi memorarea funcţiei într-un obiect tip modul;
compilarea funcţiei;
precizarea obiectului şi a evenimentului care declanşează executarea funcţiei.
Un modul este o colecţie de declaraţii şi proceduri( de tip Function sau Sub) VBA, descrise
împreună ca un întreg şi este structurat în două secţiuni:
secţiunea de declaraţii;
secţiunea 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 următoarele componente:
155
Module standard (denumite iniţial module de cod). Conţin declaraţii şi
proceduri generale. Există de asemenea şi module care conţin tratarea evenimentelor
specifice documentului de care este ataşat proiectul.
Module de clasă. Conţin definirea obiectelor create de utilizator.
Forme. Conţin definiţiile dialogurilor din interfaţa proiectată de utilizator ca şi
codul program necesar controlării dialogurilor.
Referinţe. Într-un proiect este menţinută lista altor proiecte, care sunt referite
în proiectul curent.
Un modul de cod poate începe cu o secţiune de declaraţii. Prin declaraţii înţelegem instrucţiuni
neexecutabile prin care se definesc constante, variabile şi proceduri externe. Utilizând Public,
Static, Private se precizează şi domeniul de vizibilitate a entităţilor definite.
Gestionarea (crearea, editarea, ştergerea etc.) obiectelor dintr-un proiect se face prin comenzi
ale mediului VBA, care este prezentat într-o secţiune separată.
6.1.1 Elementele componente ale sistemului Microsoft Access
Access este un sistem de gestiune a bazelor de date relaţionale pentru Microsoft Office
care funcţionează sub sistemul de operare Windows. Din punct de vedere al creatorului soft
realizarea sistemelor informatice este relativ facilă.
Modelul relaţional al datelor este obţinut rapid prin aplicarea regulilor de trecere la
modelele semantice. Utilizarea datelor stocate într-un singur fişier (MDB) asigură o „lipsă” de
redundanţă a tabelelor simultan cu integritatea şi accesibilitatea datelor.
Schema bazei de date este constituită din colecţiile de tabele şi poate fi exploatată prin
manipularea interogărilor. Baza acestor interogări o constituie limbajul standard SQL (Structured
Query Language).
Sistemul Access se bazează pe un sistem relaţional definit ca un ansamblu format din
structura relaţională a datelor şi mulţimea operatorilor relaţionali.
Prin folosirea limbajului de programare Visual Basic pentru aplicaţii (VBA) şi prin
adăugarea bibliotecilor legate dinamic (DLL), este posibilă scrierea unor aplicaţii care comunică
cu sistemul de gestiune a bazelor de date, trimiţând comenzi scrise în limbajul de manipulare a
datelor.
Sistemul Access are facilitatea de a exporta structuri de tabele, definiţii de interogări,
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.
156
De asemenea, acest sistem poate manipula şi date externe fie prin importul lor direct,
fie prin crearea unei legături la baza de date externă, datele rămânând în fişierele lor originale.
Construirea sistemelor informatice care modelează situaţii reale face ca cerinţa
componentelor standard care pot fi reutilizate, să crească. Pentru a răspunde acestor cerinţe,
utilizatorii Access au posibilitatea de a defini obiecte, entităţi cu identitate proprie, care respectă
tehnicile orientării pe obiecte. Astfel, acest sistem lucrează cu colecţii de obiecte.
Interfaţa Access permite monitorizarea modului de proiectare al câmpurilor, tabelelor şi de
exprimare a relaţiilor care formează structura unei baze de date. Prin intermediul formularelor,
interogărilor şi rapoartelor se uşurează operaţiile de extragere a datelor. Se va dezvolta ulterior
interfaţa utilizator, aprofundând proprietăţile şi evenimentele controalelor, formelor şi rapoartelor.
În cazul în care beneficiarul solicită activitatea simultană a mai multor utilizatori asupra bazei de
date, existând în structura organizatorică staţii de lucru nelipsite de conectare permanentă,
Access reprezintă o alegere corectă datorită acceptării duplicării bazei de date şi sincronizarea
acesteia. Prin filtrare şi sortare se permite ca setul curent de înregistrări să fie limitat.
Access permite răspunsul rapid la o întrebare formulată bazei de date. În momentul în
care se porneşte la construcţia unei interogări trebuie să existe o viziune de ansamblu asupra
datelor dorite a se regăsi exprimate prin câmpuri, tabele, criteriile de selecţie şi eventual ordinea
de sortare.
Construirea unei interogări în Access reprezintă un proces simplu şi rapid de aşezare a
tabelelor şi a câmpurilor necesare pe o grilă (Query by Example) care reprezintă o modalitate
facilă de regăsire a datelor. Deoarece transferarea datelor din baza de date se poate cere în
regim text, fiecare rând este considerat ca fiind o înregistrare iar caracterele care delimitează
sunt virgula sau marcajele tabulare.
Sistemul Access cuprinde următoarele 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 aplicaţii;
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ă informaţiile;
un limbaj macro procedural simplificat, cu ajutorul căruia se pot proiecta aşanumitele
macrocomenzi, deosebit de utile în etapele de administrare a bazei de date;
un set de instrumente pentru dezvoltare rapidă a interfeţei bază de date – utilizatori
obişnuiţi (formulare, rapoarte, panouri de comandă);
157
un set de instrumente pentru asigurarea interfeţei Access – alte medii (conversii de
date, transfer de date în/din, securitate, acces prin Web, compatibilităţi etc.);
un set puternic de instrumente de asistenţă interactivă („wizards”) pentru dezvoltarea
uşoară a aplicaţiilor.
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, interogările (cereri), rapoartele, panourile de
comandă, macrocomenzile şi modulele de aplicaţii 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 fişier. Acest lucru
asigură un control mai eficient al aplicaţiilor care privesc o anumită bază de date.
Colecții de date
Utilităţi Conversii de date Pagini de access Web Securitate date Întreţinere fişiere
Asistenţă Wizards
Help
Instrumente de gestionare Queries, Forms, Reports
Relationships QBE / SQL Language
Macrocomenzi Macros
language
Module de aplicaţii
VBA language
158
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 acelaşi timp, se poate
preciza faptul că VBA este un limbaj interpretat.
VBA are asociat un mediu de dezvoltare care este integrat în aplicaţii din pachetul Microsoft
Office, alte aplicaţii Microsoft (Microsoft MapPoint, Microsoft Visio) şi parţial integrat în alte
aplicaţii, cum ar fi, AutoCAD, WordPerfect.
VBA permite dezvoltarea de aplicaţii în cadrul programelor amintite, putându-se
controla aproape toate funcţionalităţile programului considerat, incluzând 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, posibilităţi de compilare condiţionată,
operaţii OLE extinse. VBA permite ca tipurile definite de utilizator să cuprindă la rândul lor alte
categorii (standard sau definite explicit) şi ca datele returnate prin răspuns al funcţiilor să fie
corespunzătoare acestor tipuri. Prin utilizarea tabloului de parametrii (ParamArray) dezvoltatorul
poate realiza funcţii cu argumente opţionale, funcţii cu un număr variabil de argumente
opţionale.
Supravegherea execuţiei în faza de testare este posibilă prin fereastra Watch existând
posibilităţi de anulare a comenzilor anterioare pe mai multe niveluri, reliefarea cuvintele cheie
prin selecţia culorilor, precum şi introducerea comentarilor, extrem de utile momentului depanării
şi dezvoltării soft.
Avantajul VBA oferit beneficiarului de sistem rezultă din cerinţele 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 programării în VBA sunt: obiectul, proprietatea, metoda,
evenimentul. Dintre obiectele bazei de date Access, modulul este singurul care conţine
proceduri definite de utilizator şi scrise în limbajul de programare VBA. În cadrul modulelor codul
este organizat în proceduri sau funcţii. În general, un modul are următoarea structură:
Declaraţii
Procedură sau funcţie
..................................
Procedură sau funcţie
Zona de declaraţii este rezervată declarării variabilelor şi constantelor accesibile
159
pentru toate procedurile şi funcţiile componente ale modulului şi una sau mai multe proceduri
sau funcţii.
După apartenenţa lor modulele se pot grupa în următoarele categorii (pot fi vizualizate prin
Object Browser):
module globale sau standard – sunt accesibile întregii aplicaţii;
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. Atât cuvintele cheie cât şi cele utilizator sunt automat transcrise în forma în care au
fost declarate, dacă sunt scrise corect. Editorul are, de asemenea, facilităţi de colorare a
cuvintelor cheie, declaraţiilor şi comentariilor utilizator, frazelor eronate.
Comentariile incluse constituie linii de cod care nu se execută, dar care, facilitează înţelegerea
programului. Pentru definirea comentariilor se utilizează un apostrof „ ’ ” la începutul
comentariului; în acest fel se pot scrie comentarii şi după o instrucţiune, pe acelaşi rând.
(Fig.6.4)
160
Fig.6.4
Instrucţiunile se scriu, în general, câte una pe un rând, însă există şi posibilitatea scrierii
a mai multor instrucţiuni pe acelaşi rând, separate prin delimitatorul „ : ”.
Dacă o instrucţiune se continuă pe mai multe rânduri, se utilizează, la sfârşitul fiecăruia, liniuţa
de subliniere ” _ ”, cu excepţia rândului care o încheie. (Fig.6.5)
Fig.6.5
Prin intermediul desfăşurătorului de obiecte, sistemul VBA evidenţiază proprietăţile şi
metodele posibile pentru un anumit obiect. Afişarea este contextuală, adică are loc în momentul
scrierii în VBA a elementelor care caracterizează un anumit context. (Fig.6.6)
161
Fig.6.6
Proprietăţile descriu un obiect prin caracteristici cum ar fi: dimensiunea, culoarea, poziţia
pe ecran şi se stabilesc, de regulă, în faza de proiectare, adică în momentul în care se
proiectează sau se modifică formele.
Proprietăţile stabilite în faza de proiectare devin operaţionale la prima lansare în execuţie
a aplicaţiei şi rămân valabile până la încheierea execuţiei aplicaţiei sau până la modificarea lor
prin program.
Metodele reprezintă procedurile sau funcţiile care se execută pentru a informa un obiect
despre acţiunile pe care le va efectua. Dacă proprietăţile sunt date, metodele sunt cod. Spre
deosebire de proprietăţi, metodele pot fi executate numai în momentul rulării programului, sau în
timpul unei sesiuni de depanare a programului.
Pe lângă proprietăţi şi metode, fiecare tip de obiect are prestabilit un număr de evenimente
posibile, dar cel puţin unul.
Evenimentele se produc ca urmare a unei acţiuni utilizatorului ori a execuţiei unui
program sau pot fi declanşate de calculator. Utilizatorul poate efectua acţiuni ca: click sau dublu
click de mouse, acţionarea unei taste, etc. În mod automat un eveniment poate fi declanşat de o
procedură inclusă în program. Pe de altă parte, evenimentele declanşează procedurile. O astfel
de programare este denumită „event–driven”, 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ă
specificăm natura acestora.
Există trei mari categorii de date: numerice, şir de caractere şi speciale. Încadrarea unei date
într–una din categorii este absolut necesară pentru a efectua calcule sau alte prelucrări. De
asemenea, VBA acceptă şi o clasificare a datelor din punct de vedere al utilizatorului, şi anume:
date standard (predefinite) şi date utilizator.
162
În tabelul următor se prezintă tipurile de date utilizate de Visual Basic. (Tabelul 6.7)
Tabelul 6.7
Tip de
date
Caracteristici
Double Număr memorat pe 64 biţi, virgulă mobilă, dublă precizie.
Valori posibile: de la – 1,797*10308 până la + 1,797*10308.
Single Număr memorat pe 32 biţi, virgulă mobilă, simplă precizie.
Valori posibile: de la –3,4*1038 până la
+ 3,4*1038.
Currency Număr memorat pe 64 biţi. Sunt memorate 15 caractere la
stânga virgulei şi 4 caractere la dreapta virgulei. Valori
posibile:
–922337203685477,5808 până la
922337203685477,5807.
Byte Număr întreg pe 8 biţi. Valori posibile: 0–255.
Integer Număr întreg pe 16 biţi. Valori posibile: –32768 până la
32767.
Long Număr întreg pe 32 biţi. Valori posibile:
–2147483648 până la 2147483647.
Boolean Poate conţine valoarea logică True (–1) sau False (0).
Date Poate conţine date calendaristice şi timp. Se utilizează
între #.
String Şir de caractere. Poate conţine 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 totuşi ca
să specificaţi tipul variabilei în momentul declarării pentru
a nu fi create confuzii.
Object Tip de date care referă un obiect. Pentru a asocia un
obiect propriu–zis unei asemenea variabile trebuie să se
utilizeze şi instrucţiunea Set.
163
6.2.2 Variabile şi constante
Variabile
O variabilă reprezintă numele unei porţiuni din memoria calculatorului în care sse stochează
temporar datele. O variabilă poate conţine o singură valoare la un moment dat dar care poate fi
modificată la acţiunea utilizatorului sau prin program.
O variabilă are un nume şi conţine 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
Într–un program, pentru a putea utiliza o variabilă, aceasta trebuie declarată,
specificând numele şi tipul de date pe care îl va conţine. Există două moduri de a declara
variabilele: implicită şi explicită.
Declararea implicită se face prin adăugarea unui caracter specific la sfârşitul 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 următor:
Nr_marcă = 547
Arată că variabila Nr_marcă este de tip Integer, dar declaraţia:
Nr_marcă = 547 #
impune variabilei Nr_marcă tipul de dată Double.
Declararea explicită a variabilelor se face utilizând instrucţiunea Dim la începutul unei proceduri.
Formatul instrucţiunii este:
Dim <NumeVariabilă> As <TipDată>
<NumeVariabilă> este definit de către utilizator;
<TipDată> este specificat explicit, (nu se pot defini două variabile cu acelaşi nume
într–o procedură).
164
Exemplu:
Dim Nr_marcă As Integer
Dim Prenume
Dim Nume As String 20
Dim Adresă As String
unde:
prima linie defineşte o variabilă de tip integer;
a doua linie defineşte o variabilă de tip variant;
a treia linie defineşte o variabilă de tip şir de caracter ce conţine maxim 20 de
caractere;
a patra linie defineşte 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ă instrucţiunea de declarare a variabilei este important pentru
că specifică modul în care se va lucra cu variabilele într–o aplicaţie.
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 declarăm variabila în
cadrul procedurii şi de instrucţiunile folosite pentru declarare.
Sintaxa generală de declararea a unei variabile este următoarea:
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 funcţie;
nivel formă;
nivel modul.
Dacă Dim este plasată la începutul unei proceduri (după declaraţia 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 dintr–un modul,
vom plasa instrucţiunea Dim în secţiunea generală a modulului. (Fig. 6.9)
165
Fig. 6.9
Folosirea instrucţiunii Private în secţiunea General a modulului determină vizibilitatea
variabilei în toate procedurile din modulul respective, nu şi din alte module sau form–uri. Nu se
poate folosi declaraţia Private într–o procedură delimitată prin Sub…End Sub.
O variabilă declarată Public sau Global la începutul unui modul este vizibilă din toate modulele
bazei de date. O astfel de variabilă se numeşte variabilă globală. Nici aceste declaraţii nu pot fi
folosite în proceduri delimitate prin Sub….End Sub.
Convenţii 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
166
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ă situaţii în care dorim să limităm lungimea textului
(să spunem că trebuie afişat într–o etichetă de lungime fixă), scop în care se utilizează opţiunea
* astfel:
Dim strNume As String * 18
Indicând că variabila strNume poate avea o lungime între 0 şi 18 caractere.
Pentru a declara mai multe variabile de acelaşi tip se poate utiliza o singură instrucţiune 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 printr–o singură instrucţiune 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 nu–şi pot modifica valoarae pe parcursul unui program. Constantele se grupează în două
categorii:
constante intrinseci sau definite de sistem care sunt furnizate de aplicaţii 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ă utilizăm un sufix la scrierea constantei.
Constantele simbolice se pot declara explicit cu instrucţiunea Const care are următoarea
167
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).
Când între ghilimele nu este specificat nici un caracter avem un şir nul.
Domeniul de vizibilitate, atât al constantelor, cât şi al variabilelor, în funcţie 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
doar în cadrul procedurii în
care apar
Nu se pot declara constante
publice în cadrul unei proceduri
La nivelul modului Variabilele sunt vizibile în
cadrul modului în care apar
Variabilele sunt vizibile pentru
toate modulele.
6.2.3 Operatori
Pentru construirea diverselor expresii (matematice, logice, de comparare) tematice cu datele
conţinute de program se utilizează operatorii.
Operatorii acceptaţi de VBA sunt de trei categorii: matemetici, de comparare, logici.
operatori matematici :
+ adunare
– scădere
* înmulţire
/ impărţire returnează partea întreagă
MOD împărţire (returnează numai restul)
^ exponent
operatori de comparare:
< mai mic
<= mai mic sau egal
> mai mare
>= mai mare sau egal
168
= egal
<> diferit
operatori logici:
o AND şi
o OR sau
o NOT negaţie
o XOR pentru sau exclusiv
operatori pentru concatenerea şirurilor : &, +
alţi operatori:
o IN pentru regăsirea de valori în cadrul unei liste;
o LIKE pentru comparare cu caractere de înlocuire;
o BETWEEN pentru regăsirea 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/funcţii
Procedurile reprezintă secvenţe de instrucţiuni care realizează o prelucrare bine definită din
punct de vedere funcţional. 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)]
[ <instrucţiuni>
End Sub
unde:
Static – variabilele locale sunt memorate între două execuţii;
Private – procedura este accesibilă numai din interiorul modulului;
Listă argumente – reprezintă variabilele ce sunt transmise în momentul apelării
procedurii;
Exit Sub – forţează ieşirea 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 funcţii şi au următoarea sintaxă:
169
[Static] [Private] Function nume_procedură [(listă argumente)] [As Tip_data]
<instrucţiuni>
[ExitFunction]
<instructiuni>
End Function
unde:
As Tip _data tipul rezultatului returnat de către funcţie.
Apelul unei funcţii se poate face astfel:
Variabila=nume_funcţie[(valoare_param_1, valoare_param_2,……….)]
Variabila preia rezultatul returnat de funcţie.
Funcţii
O funcţie reprezintă o secvenţă de instrucţiuni VBA care realizează o prelucrare bine
definită din punct de vedere funcţional şi care returnează o valoare.
Deoarece funcţia 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.
Atât funcţiile cât şi procedurile constau din linii de cod bine definite de utilizator sau generate de
VBA. Deosebirea dintre o funcţie şi o procedură este că funcţia returnează o valoare pe când
procedura nu.
Sintaxa generală a unei funcţii este:
Rezultat = nume_funcţie (listă argumente)
Între paranteze se scriu argumentele funcţiei, separate prin virgulă. Prezenţa parantezelor şi a
semnului egal sunt semnele care diferenţiază funcţia de procedură.
VBA fiind un mediu integrat de dezvoltare include două categorii de funcţii:
integrate (standard);
definite de utillizator.
Funcţiile integrate (standard)
VBA conţine un număr mare de funcţii integrate care pot fi utilizate pentru executarea
unor operaţii, pentru care altfel ar trebui scrise secvenţe de cod. Diversitatea problemelor pe
170
care le soluţionează, a determinat gruparea funcţiilor pe categorii.
Funcţii pentru preluarea şi afişarea datelor
Funcţiile încorporate ale programului, InputBox() şi MsgBox() permit efectuarea unor
operaţii simple de intrare/ieşire (I/O) prin utilizarea unor casete de dialog predefinite pe care le
putem adapta utilizând o gamă de pictograme şi combinaţii de butoane de răspuns.
Funcţia InputBox() afişează o invitaţie într–o casetă de dialog, aşteaptă ca utilizatorul să
introducă text sau să selecteze un buton, apoi returnează conţinutul casetei de text. Valoarea
introdusă de către funcţie este de tip Variant, fie de tip String, în funcţie de varianta utilizată.
Sintaxa funcţiei 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 afişat lângă caseta de text în care va
scrie utilizatorul.
Al doilea argument, titlu, este un şir de caractere afişat în bara de titlu a casetei de
dialog. Dacă se omite, în bara de titlu nu se va afişa nimic.
[<x>], [<y>] reprezintă expresii numerice care specifică distanţa pe orizontală, respectiv
pe verticală, a colţului din stânga sus al casetei de dialog faţă de colţul din stânga 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 înălţimea ecranului faţă de partea superioară.
Sintetizaţi sunt prezentaţi parametrii înstrucţiunii InputBox în tabelul 6.12
Tabelul 6.12
Parametru Descriere
<mesaj> Şir de cractere afişat în fereastra InputBox. Pot fi
maximum 1024 de caractere. Dacă se doreşte
afişarea unui mesaj pe mai multe rânduri trebuie
intercalat caracterul <ENTER> adică CHR (13) la
sfârşitul rândului.
<titlu> Titlul ferestei afişate (şir de caractere)
<val_implicită> Valoarea implicită afişată de fereastra InputBox pentru
introducere (şir de caractere).
171
<x> Poziţia feresteri InputBox faţă de marginea din stânga
a eranului (expresie numerică).
<y> Poziţia feresteri InputBox faţă de marginea de sus a
eranului (expresie numerică).
<fişier_help> Fişierul Help utilizat în cazul în care se foloseşte help
senzitiv la context (şir de caractere).
<context> Numărul care exprimă locul din fişierul Help care va fi
apelat.
Funcţia MsgBox() afişează un mesaj într–o casetă de dialog şi aşteaptă ca utilizatorul să
selecteze un buton. Funcţia MsgBox() returnează o valoare întreagă care indică butonul selectat
de utilizator.
Sintaxa funcţiei este:
MsgBox (<mesaj>, [<butoane>], [<titlu>, [<fisier_help>, <context>])
Mesaj este o expresie şir afişată ca mesaj în caseta de dialog.
Al doilea argument, titlu, este o expresie şir care apare în bara de titlu a casetei de
dialog.
Sintetizaţi sunt prezentaţi parametrii înstrucţiunii MsgBox în tabelul 6.13
Tabelul 6.13
Parametru Descriere
<mesaj> Şir de cractere afişat în fereastra MsgBox. Pot fi
maximum 1024 de caractere. Dacă se doreşte afişarea
unui mesaj pe mai multe rânduri trebuie intercalat
caracterul <ENTER> adică CHR (13) la sfârşitul
rândului.
<titlu> Titlul ferestei afişate (şir de caractere)
<butoane> Butoanele şi pictogramele afişate în fereastra MsgBox
(expresie numerică).
<fişier_help> Fişierul Help utilizat în cazul în care se foloseşte help
senzitiv la context (şir de caractere).
<context> Numărul care exprimă locul din fişierul Help care va fi
apelat.
172
Constantele acceptate de parametrul butoane sunt prezentate în tabelul 6.14
Tabelul 6.14
Constantă Valoare Explicaţie
vbOKOnly 0 Afişează numai un buton OK
vbOKCancel 1 Afişează un buton OK şi un buton
Cancel
vbAbortRetryIgnore 2 Afişează un buton Abort (Abandon
în caz de eroare), Retry (Forţează în
caz eroare), Ignore (Ignoră eroarea).
vbYesNoCancel 3 Afişează un buton Yes, un buton
No, un buton Cancel
vbYesNo 4 Afişează un buton Yes, un buton
No.
vbRetryCancel 5 Afişează un buton Retry, un buton
Cancel
vbCritical 16 Afişează o pictograma Critical
vbQuestion 32 Afişează un semn de întrebare
vbExclamation 48 Afişează un semn al exclamării
vbInformation 64 Afişează pictograma Information
Constantele ce pot fi returnate de instrucţiunea MsgBox sunt prezentate în tabelul 6.15
Tabelul 6.15
Constantă Valoare Explicaţie
vbOK 1 Butonul OK selectat
vbCancel 2 Butonul Cancel selectat
vbAbort 3 Butonul Abort selectat
vbRetry 4 Butonul Retry selectat
vbIgnore 5 Butonul Ignore selectat
vbYes 6 Butonul Yes selectat
vbNo 7 Butonul No selectat
Funcţii numerice
Cuprind funcţii matematice şi trigonometrice, având ca argumente şi ca rezultate valori
numerice. Câteva funcţii reprezentative sunt cuprinse în tabelul 6.16. Sunt utilizate în calcule
matematice şi inginereşti.
173
Tabelul 6.16
Funcţie Descriere
Abs
(<expresie_numerică>)
Returnează valoarea absolută a unei expresii
numerice, sau a unui număr.
Exp
(<expresie_numerică>)
Returnează valoarea constantei e ridicată la o putere
(expresie numerică sau număr).
Int
(<expresie_numerică>)
Returnează partea întreagă dintr–un număr sau dintr–o
expresie numerică.
Returnează primul număr negativ îmntreg mai mic sau
egal decât numărul specificat (sau numărul rezultat în
urma evaluării numerice)
Fix
(<expresie_numerică>)
Returnează partea întreagă dintr–un număr sau dintr–o
expresie numerică.
Returnează primul număr negativ întreg mai mare sau
egal decât numărul specificat (sau numărul rezultat în
urma evaluării expresiei numerice)
Funcţii pentru şiruri de caractere (Tabelul 6.17)
Funcţie Descriere
Chr (<cod_caracter>) Returnează caracterul corespunzător codului specificat.
Len (<şir_cractere/variabilă>) Returnează numărul de caractere al şirului de caractere
specificat sau numărul de octeţi necesari pentru a stoca
conţinutul unei variabile.
Space (număr) Returnează numărul de spaţii specificate
Str (expresie_numerică) Converteşte rezultatul evaluării expresiei numerice dintre
paranteze într–un şir de caractere
Val (şir_caractere) Returnează rezultatul evaluării şirului de caractee
specificat, într–un număr
Mid (şir_caractere, poziţie_start,
lungimea)
Extrage un şir de caractere dintr–un alt şir de caractere.
– şir_caractere – şirul de caractere din care se extrage;
– poziţie_start poziţia din şirul de caractere, de unde începe
extragerea;
– lungimea – numărul de caractere care se extrage.
174
Funcţii pentru dată şi oră (Tabelul 6.17)
Funcţii pentru conversii (Tabelul 6.18)
Funcţii diverse (Tabelul 6.19)
Funcţii Discriere
IsNull (<expresie>) Returnează valoarea adevărat (TRUE) dacă expresia
dintre paranteze conţine valoarea NULL (date invalide)
IsError (<expresie>) Returnează valoarea adevărat (TRUE) dacă expresia
dintre paranteze conţine o eroare.
IsEmpty (<expresie>) Returnează valoarea adevărat (TRUE) dacă expresia
dintre paranteze nu conţine o valoare. NULL este
considerat valoare.
Funcţii Descriere
Date () Returnează data sistemului
Day (<data_calendaristică>) Returnează numărul zilei din lună (1–31).
Month (<data_calendaristică>) Returnează numărul lunii din an (1–12).
Year (<data_calendaristică>) Returnează anul.
Hour (<expresie_timp>) Returnează numărul orei din zi (0–23)
Minute (<expresie_timp>) Returnează numărul minutului dintr–o oră (0–59).
Second (<expresie_timp>) Returnează numărul unei secunde dintr–un minut (0–59).
Funcţii 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
175
IsDate (<expresie>) Returnează valoarea adevărat (TRUE) dacă expresia
dintre paranteze este compatibilă cu o dată
calendaristică.
IsNumeric (<expresie>) Returnează valoarea adevărat (TRUE) dacă expresia
dintre paranteze poate fi evaluat ca număr.
IsObject (<identificator>) Returnează valoarea adevărat (TRUE) dacă
identificatorul dintre paranteze este de tip obiect.
Funcţii definite de utillizator
Sintaxa:
Private Public] Function nume_functie [([ByRef│ByVal] param_1 as tip_date, …)] [as
tip_date]
[instrucţiuni]
[nume_funcţie=expresie]
….
[Exit Function]
[instrucţiuni]
[nume_funcţie=expresie]
End Function
Unde:
Exit Function – permite ieşirea forţată dintr–o funcţie;
nume_funcţie = expresie, permite asocierea unui rezultat numelui funcţiei. Acest
rezultat va fi returnat în momentul terminării execuţiei funcţiei.
Apelul unei funcţii se poate face astfel:
Variabila = nume_funcţie [(valoare_param_1, valoare_param_2, …)]
Variabila preia rezultatul de funcţie.
6.3. Structuri de control fundamentale în VBA
Programele VBA sunt programe a căror evoluţie se modifică în mod prestabilit, previzibil,
controlat. Aceste facilităţi sunt posibile datorită structurilor de control care precizează ordinea în
care se vor executa instrucţiunile.
176
6.3.1Tipuri de structuri de control
Un progam structurat (concept introdus în anii ’70) se bazează pe următoarele structuri de
control: secvenţială, alternativă, repetitivă.
Structuri secvenţiale
În această structură, operaţiile sunt executate cosecutiv, în ordinea în care sunt indicate în
schemă, ordine în care vor fi stocate în memorie instrucţiunile maşină rezultate în urma
compilării. Sunt foarte rare cazurile când un întreg program este conceput utilizând numai o
structură secvenţială. (Fig.6.20)
Fig.6.20
Structuri alternative
Aceste structuri,numite şi condiţionate, sunt de două categorii: de selecţie şi de decizie.
şi se caracterizează prin executarea unui set de instrucţiuni sau a altuia, în funcţie de
îndeplinirea sau neîndeplinirea unei condiţii.
Structurile alternative permit astfel ramificarea ordinii de execuţie a instrucţiunilor unui
program. (Fig.6.21)
Instrucţiune 1
Instrucţiune 2
Instrucţiune n
177
Fig. 6.21
Structuri repetitive
În cadrul structurilor repetitive (sau iterative), un set de instrucţiuni se repetă în funcţie de o
condiţie specificată. (Fig. 6.22)
Structurile repetitive pot fi:
condiţionate anterior – caracterizate prin executarea repetată a setului de
instrucţiuni cît timp condiţia testată este adevărată;
condiţionate posterior caracterizate prin executarea setului de instrucţiuni cât timp
o condiţie este falsă;
condiţionate anterior sau posterior, cu contor. Cu această structură se execută
setul de instrucţiuni de un număr de ori, plecându–se de la valoarea iniţială a variabilei
contor până la valoarea finală a acesteia, incrementându–se automat variabila contor cu
+1
Instrucţiune 1
Cond
Instrucţiune 2 Instrucţiune 3
Fals Adevărat
178
Fig. 6.22
6.3.2 Instrucţiuni pentru implementarea structurii alternative
Instrucţiunile VBA utilizate în reprezentarea acestor structuri sunt : If pentru structurile
alternative de selecţie şi Select Case pentru structurile alternative de decizie.
Instrucţiunea If
Este utilizată sub următoarele formate :
A.
If <condiţie>Then
[secvenţă_instrucţiuni_1]
[Else
[secvenţă_instrucţiuni_2]]
End If
Unde:
Condiţie poate fi o expresie numerică sau o expresie şir de caractere, care poate fi
evaluată la adevărat (true) sau fals (False).
Dacă rezultatul evaluării expresiei din condiţie este adevărat, atunci este executată
secvenţă_instrucţiuni_1, astfel este executată secvenţă_instrucţiuni_2.
Exemplu:
Dacă media este egală cu 5 atunci studentul este considerat integralist, în caz contrar
este restanţier.
Instrucţiune 1
Condiţie
Instrucţiune 2 Fals
Adevărat
179
If Media = 5 Then
MsgBox „Student integralist”
Else
MsgBox „Student restanţier”
End If
B.
If <condiţie_1>Then
[secvenţă_instrucţiuni_1]
[Else lf<condiţie_2> Then
[secvenţă_instrucţiuni_2]]
……
[Else
[secvenţă_instrucţiuni_n]]
End If
Această variantă este utilă în cazul structurilor imbricate.
Exemplu:
Agenţii comerciali sunt premiaţi în funcţie de valoarea mărfurilor vândute.
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<condiţie> Then <instrucţiune_1> [Else <instrucţiune_2 >]
În această variantă, după evaluarea condiţiei, se poate executa o singură instrucţiune şi
trebuie scrisă pe un singur rând.
Exemplu:
În calculul valorii de plată corespunzătoare facturilor întocmite, firma X oferă o reducere
180
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
Instrucţiunea Select Case
În cazul în care o expresie trebuie comparată cu un număr mai mare de valori, nu este
recomandată folosirea repetată a instrucţiunii If…Then…Else, ci este performantă folosirea
instrucţiunii Select Case.
Formatul instrucţiunii este:
Select Case <expresie_selector>
[Case <listă_expresii_case_1>
[secvenţă_instrucţiuni_1]]
[Case <listă_expresii_case_1>
[secvenţă_instrucţiuni_2]]
[Case <listă_expresii_case_1>
[secvenţă_instrucţiuni_3]]
…….
[Case Else
secvenţă_instrucţiuni_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 conţine operatorii To şi Is cu următorul 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 condiţia impusă de operatorul de
comparare.
181
Exemplu:
Penalităţile percepute de firma X pentru întârzierea plăţi facturilor de către beneficiari, în
funcţie de numărul de zile de întârziate.
Select Case Penalităţi
Case 0
MsgBox „Penalităţi=0”
Case 1 To 5
MsgBox „Penalităţi= val_fact*0,01”
Case 6 To 10
MsgBox „Penalităţi=val_fact*0,05”
Case 11 To 15
MsgBox „Penalităţi=val_fact*0,1”
Case Else
MsgBox „Penalităţi=val_fact*0,5”
End Select
6.3.3 Instrucţiuni pentru implementarea structurii repetitive
Pentru reprezentarea acestei structuri se folosesc un număr de patru instrucţiuni:
While………Wend
Do…………...Loop
For………….Next
For Each…..Next
Instrucţiunea While………Wend
Este o structură repetitivă condiţionată anterior.
Formatul instrucţiunii este:
While <condiţie>
[secvenţă_instrucţiuni]
Wend
Condiţie poate fi o expresie numerică sau o expresie şir de caractere, care poate fi
evaluată la adevărat sau fals. Întâi se evaluează condiţia, dacă este adevărată, se repetă
182
secvenţa de instrucţiuni; dacă nu este adevărată se iese din structură şi se trece la următoarea
secvenţă de instrucţiuni de după Wend.
Exemplu:
Să se afişeze numerele mai mici decât 10.
Score = 0
While Score < 0
Score = Score + 1
Wend
Instrucţiunea Do………Loop
Formatul instrucţiunii este:
Do [{While│Until} <condiţie>]
[secvenţă_instrucţiuni]
[Exit Do]
[secvenţă_instrucţiuni]
Loop
În varianta Do While...Loop se repetă secvenţa de instrucţiuni atâta timp cât
condiţia este adevărată. Dacă evaluarea ei este Null, evaluarea condiţiei este False. Această
variantă funcţionează exact ca While...Wend, cu deosebirea că se poate ieşi forţat din structură
cu Exit Do.
Do
[secvenţă_instrucţiuni]
[Exit Do]
[secvenţă_instrucţiuni]
Loop [{While│Until} <condiţie>]
Exemplu:
Se va introduce Nr_Matricol al studenţilor până când Nr_ Matricol = 3456
Nr_ Matricol = 0
Do
Nr_ Matricol = Nr_ Matricol + 1
Loop Until Nr_ Matricol = 3456
183
În varianta Do Until...Loop se repetă secvenţa de instrucţiuni până când condiţia
devine adevărată. Deci se execută secvenţa de instrucţiuni atâta timp cât evaluarea condiţiei
este False.
Instrucţiunea Exit Do forţează ieşirea din structura repetitivă la instrucţiunea care urmează după
instrucţiunea Loop într–un moment anume ales de programator.
Instrucţiunea For………….Next
Codifică structura repetitivă cu un număr definit de paşi, în care o secvenţă de cod se repetă cu
un număr specificat de ori.
Formatul instrucţiunii este:
For <vb_contor>=<val_initiala> To <val_finala> [Step <Val_pas>]
[secvenţă_instrucţiuni]
[Exit For]
[secvenţă_instrucţiuni]
Next [<vb_contor>]
<val_initiala>,<val_finala> – reprezintă valoarea iniţială, 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 evaluării unor expresii.
Exemplu:
Se va afişa suma numerelor de la 10 la 100.
Suma = 10
For CONTOR = 11 To 100
Suma = Suma + CONTOR
Next CONTOR
Instrucţiunea For Each…..Next
Parcurge iterativ o colecţie de elemente, la fiecare iteraţie variabilei element I se atribuie un
element din colecţie. Se foloseşte la parcurgerea colecţiilor de obiecte Access.
Formatul instrucţiunii este:
184
For Each <vb_element> In <colectie>
[secvenţă_instrucţiuni]
[Exit For]
[secvenţă_instrucţiuni]
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 instrucţiunilor SQL
de la prompter;
cea modulară (Modul Language) – foloseşte anumite proceduri apelate de programele
aplicaţiei;
cea de tip încapsulat (Embedded SQL) – are în vedere instrucţiuni încapsulate în codul
de program, fiind de tip static sau dinamic.
Instrucţiunile SQL, în funcţie de rolul lor în manipularea datelor şi tranzacţiilor, pot fi grupate
astfel:
instrucţiuni de definire a datelor care permit descrierea structurii bazei de date;
instrucţiuni de selecţie a datelor care permit consultarea bazei de date;
instrucţiuni de manipulare a datelor, în sensul adăugării, modificării şi ştergerii
înregistrărilor;
instrucţiuni de procesare a tranzacţiilor care privesc unităţile logice de prelucrare şi
constituie în fapt operaţii multiple de manipulare a datelor;
instrucţiuni de control al cursorului;
instrucţiuni privind controlul accesului la date.
Cu ajutorul următoarelor reguli se pot construi instrucţiuni valide, uşor de citit şi de editat:
Instrucţiunile SQL pot fi scrise cu litere mari sau mici, în afară de cazurile indicate;
Instrucţiunile SQL pot fi introduse pe una sau mai multe linii;
Cuvintele cheie nu pot fi abreviate sau despărţite î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, instrucţiunile SQL sunt introduse de la prompterul SQL, iar
185
următoarele linii sunt numerotate. Acesta se numeşte un buffer SQL. O singură
instrucţiune poate fi curentă în orice timp în cadrul buffer–ului.
Executarea instrucţiunilor SQL
Poziţionarea punct şi virgulei (;) la sfârşitul ultimei clauze;
Poziţionarea unui slash (/) la sfârşitul ultimei linii din buffer;
Punerea unui slash la promterul SQL;
În cadrul SQL*Plus – comanda RUN la promterul SQL.
Pentru a crea şi executa interogări SQL în SGBD Access se parcurg etapele:
1. din fereastra Open, se deschide baza de date asupra căreia se vor efectua
interogările SQL (Fig.6.23);
Fig.6.23
2. din fereastra Database care se afişează se va selecta eticheta Query. Pentru a
crea interogarea SQL se va selecta opţiunea “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 interogării SQL. Din
fereastra Show Table se pot selecta mai multe tabele (interogări). (Fig.6.25);
186
4. pentru a scrie interogarea SQL ACCESS este necesar să se selecteze din meniul
View opţiunea SQL View. În această fereastră se vor scrie instrucţiunile SQL (Fig.6.26);
5. pentru a pune în execuţie comanda SQL din meniul Query se selectează opţiunea
Run. Pe ecran se va afişa rezultatul; acest rezultat va fi interpretat de utilizator.
Fig. 6.25
Fig.6.26
6.4.1 Limbaj de definire a datelor: SQL–LDD
Gestiunea schemei bazei de date
Schema unei baze de date descrie tabelele şi atributele aferente lor, domeniile în care
aceste atribute iau valori, restricţiile de integritate, drepturile de utilizare a relaţiilor, view–urile şi
detaliile relative la implementarea fizică a tabelelor.
187
Limbajul de definire a datelor LDD (Language Data Definition), parte componentă a
limbajului SQL, include instrucţiuni care permit realizarea acţiunilor specifice descrierii schemei
bazei de date.
Majoritatea implementărilor limbajului SQL conţin instrucţiuni 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ă, putând varia în funcţie de necesităţile utilizatorului şi de
S.G.B.D.–ul folosit. De exemplu ACCESS SQL nu acceptă o astfel de instrucţiune.
La crearea unei baze de date trebuie respectate anumite restricţii stabilite de
administratorul de sistem şi anume, cele referitoare la nivelul drepturilor de utilizare a
instrucţiunilor î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 Situaţia beneficiarilor:
CREATE DATABASE Situaţia_beneficiarilor
Crearea unei tabele
Sintaxa:
CREATE TABLE nume_tabelă
(câmp1 tip_dată [NOT NULL],
câmp2 tip_dată [NOT NULL],
câmp3 tip_dată [NOT NULL]...);
Exemplu:
Să se creeze tabela Beneficiar cu structura următoare: 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 adăugarea/ştergerea de atribute
şi prezintă următoarea sintaxă:
Sintaxa:
ALTER TABLE nume_tabelă {ADD COLUMN nume_atribut1
Tip_data [(mărime)] [NOT NULL][CONSTRAINT index] │DROP COLUMN
nume_atribut2 CONSTRAINT indexname};
188
Exemplu:
Să se adauge tabelei Beneficiar un nou câmp 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 relaţiilor dintr–o bază de date
Ştergerea unei tabele se realizează cu ajutorul comenzii DROP TABLE, odată cu
aceasta ştergându–se şi indecşii, view–urile definite pentru respectiva tabelă, neexistând nici o
posibilitate de recuperare a informaţiei şterse.
Sintaxa:
DROP TABLE nume_tabelă;
Exemplu:
Să se şteargă tabela Beneficiar din baza de date Situaţia beneficiarilor
DROP TABLE Beneficiar;
Ştergerea unei baze de date
Ştergerea unei baze de date determină ştergerea tuturor obiectelor conţinute de aceasta, a
copiei cataloagelor SQL din directorul bazei de date.
Sintaxa:
DROP DATABASE nume_bază de date;
Această instrucţiune nu este inclusă de anumite versiuni SQL, ştergerea făcându–se mai uşor
printr–o apăsare a mouse–lui. Într–o reţea de calculatoare nu poate fi ştearsă o bază de date
activată de către un alt utilizator. Comanda de ştergere nu poate acţiona asupra unei baze de
date active.
Gestiunea indecşilor
Un index este un obiect schemă care îmbunătaţeşte regăsirea înregistrărilor
folosind un pointer. Indecşii pot fi creaţi explicit sau automat.
Un index furnizează un acces direct şi rapid la înregistrarile unei baze de date.
Scopul utilizării indecşilor este reducerea numărului de citiri/scrieri pe disc, prin folosirea unei căi
indexate pentru a localiza mai rapid datele. Indexul este automat folosit si întreţinut de serverul
Oracle. Odată creat indexul, nu este necesară nici o intervenţie din partea utilizatorului.
Indecşii sunt logic si fizic şi sunt independenţi de bazele de date pe care le indexează. Acest
lucru înseamnă că indecşii pot fi creaţi sau şterşi oricând fără nici un efect asupra bazelor de
date sau a altor indecşi.
189
Nota:
Când este şters un tabel, indecşii corespunzători sunt de asemenea şterşi.
Indexul este un obiect din schemă.
Indexul este folosit de serverul Oracle pentru o mai bună regăsire a înregistrarilor
prin utilizarea unui pointer.
Indexul reduce numărul operaţiilor 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 întreţinut de serverul Oracle.
Indecşii sunt creaţi:
Automat – când este definită o cheie primara (PRIMARY KEY) sau unică
(UNIQUE KEY) în definiţia unui tabel.
Manual – utilizatorii pot crea indecşi mecanic pentru a accelera accesul la
înregistrările bazelor de date
Crearea unui index
Sintaxa:
CREATE INDEX index
ON table (column[, column]…);
Îmbunătăţirea accesului câmpului 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 câmpului în baza de date ce urmează a fi indexat
Crearea unui index se face pentru:
un câmp ce este folosit des în clauzele WHERE sau în condiţii de join;
câmpuri cu mare varietate de valori;
câmpuri cu un număr mare de valori NULL;
două sau mai multe câmpuri ce sunt folosite împreună frecvent într–o clauză
WHERE sau într–o condiţie join;
o bază de date mare şi majoritatea interogărilor nu vizează mai mult de 2–4% din
înregistrări.
Mai multi indecşi într–o bază de date nu înseamnă o optimizare a interogărilor. Fiecare
operaţie DML ce se realizează într–o bază de date ce conţine indecşi implică o actualizare a
190
indecşilor. Cu cât sunt mai mulţi indecşi asociaţi tabelului, cu atât va dura mai mult până când
serverul Oracle va actualiza indecşii dupa DML.
Nu este necesară crearea unui index atunci când:
baza de date este mică;
câmpurile nu sunt des folosite într–o condiţie;
majoritatea interogărilor vizeaza mai mult de 2–4% dintre înregistrari.
Confirmarea indecşilor
USER_INDEXES conţine numele indexului si unicitatea lui.
Componenta USER_IND_COLUMNS conţine numele indexului, numele bazei de date
si numele câmpului.
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 indecşilor
Confirmarea indecşilor existenţi se realizează prin vizualizarea lui USER_INDEXES. De
asemenea se pot verifica câmpurile implicate într–o indexare prin interogarea lui
USER_IND_COLUMNS.
Exemplul următor afişează toţi indecşii creaţi anterior, numele câmpurilor afectate şi
unicitatea în baza de date EMP.
INDEX_NAME COLUMN_NAME COL_POS UNIQUENES
EMP_EMPNO_PK EMPNO 1 UNIQUE
EMP_ENAME_IDX ENAME 1 NONUNIQUE
Nota: Ieşirea a fost formatată anterior.
Ştergerea unui index
Ştergerea unui index din dicţionarul de date.
Sintaxa:
SQL> DROP INDEX index;
Ştergerea indexului EMP_ENAME_IDX din dicţionarul de date.
Sintaxa:
191
SQL> DROP INDEX emp_ename_idx;
Index dropped
Ştergerea unui index poate fi realizată doar cel care l–a creat sau de cel care are privilegiul
Sintaxa:
DROP ANY INDEX.
Indecşi care aparţin unei legături dintre tabele
Clauza CONSTRAINT
Permite crearea unui index după numele unui câmp; indexul poate fi declarat drept
cheie primară (PRIMARY KEY) sau ca UNIQUE sau stabileşte o relaţie între câmpul nume de
index şi câmpul unei tabele externe (cu opţiunea 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ă existenţa unor valori unice la nivelul unei coloane. În plus,
PRIMARY KEY conţine automat o restricţie NOT NULL, pe când o coloană UNIQUE poate avea
valori NULL dacă nu este specificată in mod expres clauza NOT NULL.
Menţionăm 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 restricţii relaţionale şi care s–a
dovedit deosebit de practică. Această clauză pune in legătură două tabele. Ea specifică faptul
că valorile unei coloane aparţinând tabelei ( care serveăte la stabilirea de legături trebuie să
apară intr–o coloană din tabela referită al cărei nume este precizat în restricţie (CONSTRAINT
nume_index).
Observaţie: Restricţiile UNIQUE nu sunt acelaşi lucru cu INDEX UNIQUE. Un index UNIQUE nu
poate fi referit pentru că el aparţine unei singure tabele şi nu unei legături între tabele.
Exemplu:
CONSTRAINT idcod PRIMARY KEY (codp)
CONSTRAINT rcod REFERENCES vânzări (codp);
192
Comanda DROP CONSTRAINT permite ştergerea unei restricţii de unicitate sau de referinţă
utilizând sintaxa:
Sintaxa:
DROP CONSTRAINT nume_index;
3.2.3 Gestiunea drepturilor de utilizare
Utilizatorii bazei de date sunt repertorizaţi 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ă următoarea 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: toţi utilizatorii;
WITH GRANT OPTION: drepturi utilizatorilor de a acorda la rândul 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ă:
193
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 SGBD–urile, 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 view–urile:
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 (SQL–LMD)
Limbajul de manipulare a datelor (DML) este partea de bază a SQL. Când dorim să
adăugăm, să modificăm sau să ştergem date dintr–o bază de date, executăm o comandă DML.
O colecţie de comenzi DML care formează o unitate logică de lucru se numeşte tranzacţie.
Considerăm o bază de date din domeniul bancar. Atunci când un client al bancii doreşte
să transfere bani dintr–un depozit într–un cont curent, tranzacţia ar putea consta în 3 operaţii
separate: scade suma din depozit, creşte suma din contul curent, înregistrează tranzacţia în
jurnalul de tranzacţii. Serverul Oracle trebuie să garanteze că toate cele 3 comenzi SQL sunt
executate în aşa fel încât să menţină echilibrul necesar între conturi. Atunci când, din anumite
cauze, una dintre comenzile tranzacţiilor de mai sus nu se execută, atunci celelalte comenzi ale
tranzacţiilor trebuie să fie anulate.
Instrucţiuni pentru selectarea datelor
Cereri de interogare simple
Instrucţiunile de selecţie reprezintă una dintre categoriile cele mai importante ale limbajului de
interogare SQL ACCESS.
Pentru definirea interogarilor de selecţie simple avem instrucţunea SELECT cu următoarea
194
sintaxă :
SELECT [domeniu] listă_selecţie
FROM nume tabela 1, nume tabela 2;
[WHERE criteriul _de_selectie]
[ORDER BY campuri_criteriu [ASC/DESC]];
unde:
domeniu – determină stabilirea modalitaţii de manipulare a înregistrărilor din baza
de date asupra căreia se face selecţia
All – permite includerea tuturor înregistrărilor ce îndeplinesc condiţiile impuse;
Distinct – elimină înregistrările care prezintă valorile duplicate în câmpurile
selectate;
Distinctrow – vizează înregistrările duplicate care nu vor fi returnate în urma
executării cererii;
Listă_selecţie – cuprinde toate câmpurile care vor apărea în tabela cu rezultatele
interogării;
Clauza FROM – specifică numele tabelei sau tabelelor care vor forma suportul
interogării;
Clauza WHERE – face interogările mai selective, înregistrările care îndeplinesc
crieteriul descris vor fi afişate;
Clauza ORDER BY – se utilizează atunci când se doreşte ca rezultatele să fie
ordonate in mod crescător (ASC) sau descrescător (DESC).
Operatorii utilizaţi în cererile de interogare sunt:
operatori aritmetici:+,–,*,/
operatori logici: and, or, not
operatori de atribuire şi comparare: <, >, =, <=, >=.
În serierea interogărilor de selecţie simple SQL ACCESS este posibilă şi folosirea funcţiilor de
grup. Cele mai importante sunt:
COUNT – returnează numărul de înregistrări care respectă condiţia stabilită prin clauza
Where;
SUM – returnează suma valorilor dintr–un câmp; operează numai cu valori numerice;
AVG – calculează valoarea medie pentru câmpul precizat;
MAX – returnează cea rnai mare valoare dintr–un câmp;
MIN – returnează cea mai mică valoare dintr–un câmp
Exemplu:
dorim afişarea mediilor fiecărui student identificat după NrLeg
195
SQL> SELECT NrLeg, AVG(Nota) Media
from Note Group By NrLeg;
dorim afişarea numărului de note primite de fiecare student identificat după NrLeg
SQL> SELECT NrLeg, Count(Nota) NrNote
FROM Note
Group By NrLeg;
dorim afişarea studenţilor cu medii >=5 identificaţi după NrLeg
SQL> SELECT NrLeg, Avg(Nota) Media
FROM Note
group by NrLeg
HAVING avg(Nota)>=5;
dorim afişarea studenţilor cu medii <5 identificaţi după NrLeg
SQL> SELECT NrLeg, Avg(Nota) Media
FROM Note
group by NrLeg
HAVING avg(Nota)<5;
dorim afişarea 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 afişarea 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;
196
dorim afişarea 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 afişarea 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 afişarea studenţiilor ş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ă vizualizăm din tabela Produs (cod produs, den produs, um, pret) numai
acele produse cu preţuri cuprinse între 100000 lei şi 120000 lei
SQL>SELECT den produs
FROM Produs
WHERE pret BETWEEN 100000 AND 120000;
dorim să cunoaştem codul atribuit produsului "crema mâini" şi la ce preţ este
oferit.
SELECT cod produs, pret, den produs
FROM Produs
WHERE den produs "crema mâini";
Cereri de interogare complexe
197
Limbajul de interogare SQL ACCESS permite pe lângă definirea de interogări de selecţie
simple, crearea unor interogări cu o structură complexă, cum ar fi cele în care regăsim funcţiile
agregate, interogările JOIN sau interogările UNION;
Funcţiile de grup (agregat)
Permit construirea unor interogări SQL ACCESS complexe, prin care utilizatorul poate să
efectueze diverse calcule pentru grupuri de inregistrari care au câmpuri cu aceiaşi valoare,
SELECT [domeniu] [functie_agregata] (nume_câmp) AS alias, lista_seleetie]
FROM nume_tabela 1 nume tabela 2;
GROUP BY câmp_de _grupare
[HAVING criteriul_de_grupare]
[ORDER BY câmpuri_criteriu[ASC/DESC]];
Din structura instrucţiunii se observă anumite clauze care au fost întâlnite şi la definirea
interogărilor simple însă apar şi elemente mai de sinteză şi anume:
Listă selecţie – se referă la una sau mai multe funcţii agregate care au ca
argumente nume de câmpuri ale bazei de date
AS alias – asociază un pseudonim (nume) rezultatului utilizării funcţiei agregat
Clauza GROUP BY – precizeză câmpul sau câmpurile pe baza cărora se va
efectua gruparea înegistrărilor; se pot executa funcţiile agregate descrise în lista de
selecţie pentru fiecare dintre grupări. Echivalentul acestei clauze în macheta grafică QBE
de constucţie a interogării il reprezintă rândul Total
Clauza HAVINIG – se referă la criteriul care va fi aplicat câmpului definit ca
argument al funcţiei agregat
Exemplu:
Dorim să cunoaştem clienţii 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;
Interogările JOIN
Operaţiile de asociere induse de clauza JOIN au ca rezultat producerea tuturor
combinaţiilor posibile, pentru conţinutul infomaţional al fiecarei tabele. Noile înregistrări care
rezulă în urma joncţiunii vor deveni disponibile pentru selecţiile ulterioare. La o asociere pot
participa mai mult de două tabele.
198
Există mai multe categorii de joncţiuni:
CROSS – cu rol în ilustrarea elementelor specifice proprietăţilor 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 joncţiunile 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 instrucţiunile SQL, care descriu joncţiuni se utilizează câmpuri ce fac parte din
tabele diferite, este necesară întotdeauna specificarea tabelei de care aparţin.
Forma generală de descriere a unui astfel de câmp
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;
Interogările UNION
Când utilizatorul doreşte să vadă rezultatele a mai multor interogari SELECT în acelaşi timp,
prin combinarea ieşirilor lor, poate utiliza facilitatea UNION a limbajului de interogare SQL
ACCESS. Nu există echivalent QBE pentru această instrucţiune.
Sintaxa generală pentru interogările 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
199
Instrucţiuni pentru actualizarea bazei de date
Aceste instrucţiuni se implementează prin interogările de tip acţiune; efectele acţiunii lor sunt
permanente, influenţând inclusiv integritatea referenţială. Cele mai importante instrucţiuni sunt
CREATE, INSERT, UPDATE şi DELETE.
Crearea unei noi tabele plecând de la structura şi conţinutul unei tabele deja existente
Sintaxa:
SELECT [domeniu] (câmp 1, câmp 2...)
INTO tabela_nouă
FROM tabela_sursă
[WHERE criteriul_de_adăugare];
Exemplu:
Să se creeze o tabelă cu numele Beneficiari_teritoriali plecând de la tabela Beneficiari
în care să regăsim doar beneficiarii care au sediul în Craiova şi Timişoara.
SELECT DISTRICTROW Den_beneficiar, Adresa
INTO Beneficiari_teritoriali
FROM Beneficiari
WHERE Adresa = “Craiova” OR Adresa= “Timişoara”;
Adăugarea unei înregistrări dintr–o tabelă în alta
Există două forme ale instrucţiunii şi anume:
INSERT...VALUES
INSERT...SELECT
INSERT...VALUES
Sintaxa:
INSERT INTO nume_tabelă (câmp 1, câmp 2...)
VALUES (valoare 1, valoare 2...);
În acest caz se inserează o înregistrare într–o tabelă, menţionându–se câmpurile şi
valorile asociate acestora. Ca particularizare se remarcă inserarea unei singure înregistrări la un
moment dat.
Trebuie avut în vedere respectarea următoarelor reguli:
valorile menţionate în clauza VALUES vor avea aceeaşi natură cu câmpurile
specificate în clauza INTO;
mărimea valorii corespunzătoare fiecărui câmp va fi mai mică decât dimensiunea
200
câmpului;
nu va fi nevoie specificarea denumirii câmpurilor, deorece SQL ACCESS va
asocia listei de valori câmpurile în ordinea din structura înregistrării (prima valoare se va
introduce în primul câmp, a doua valoare în al doilea câmp, etc.)
dacă un câmp are definiţia 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, “Săpun”, “Buc”, 25000)
INSERT...SELECT
Sintaxa:
INSERT INTO tabelă_destinaţie (câmp 1, câmp 2...)
SELECT [domeniu] câmp 1, câmp 2...
FROM tabelă_sursă
WHERE criteriul_de_adăugare;
În acest caz este posibil să se copieze selectiv înregistrări dintr–o tabelă într–una sau în mai
multe tabele.
Regulile menţionate la instrucţiunea INSERT...VALUES rămân valabile, în plus se adaugă
următoarele:
fraza SELECT nu poate extrage înregistrări din tabela destinaţie;
numărul şi natura câmpurilor menţionate în clauza INTO trebuie să fie aceleaşi cu
numărul şi natura câmpurilor returnate de instrucţiunea SELECT;
dacă nu se introduce clauza WHERE, toate înregistrările din tabela sursă vor fi
adăugate în tabela destinaţie.
Exemplu:
Se inserează valorile câmpurilor: număr, nume, prenume şi studii doar pentru agenţii de
vânzare care sunt studenţi. Selecţia se face din tabela sursă Agent_vânzare, iar destinaţia 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);
201
Comanda propriu–zisă de inserare este:
INSERT INTO STUDII (nr, nume, pren, std)
SELECT nr, nume, pren, std
FROM Agent_vanzare
WHERE std=”student”;
Interogarea acţiune de ştergere parţială sau totală a înregistrărilor din tabele DELETE
Sintaxa:
DELETE FROM nume_tabela
[WHERE criteriul_de _stergere];
Nu este utilizată pentru ştergerea de valori din câmpuri individuale, ci va acţiona doar asupra
înregistrărilor în totalitatea lor. În acelaşi timp se va şterge doar conţinutul tabelei nu şi aceasta
(pentru eliminarea tabelei se va apela la instrucţiunea DROP TABLE).
Ca şi instrucţiunea INSERT, operaţia de ştergere a înregistrărilor dintr–o tabelă poate duce la
apariţia unor probleme de integritate referenţială în alte tabele. Clauza WHERE restricţionează
domeniul de ştergere în funcţie de cerinţele utilizatorului.
Exemplu:
Din tabela Produse să se şteargă înregistrările care au preţul mai mic de 20000.
DELETE FROM Produse
WHERE Pret < 20000;
Interogarea acţiune UPDATE;
Are scopul de a insera noi înregistrări cât şi de a modifica valorile câmpurilor din
înregistrările existente. Ca şi în cazul instrucţiunii INSERT, se va urmări dacă în câmpul cu valori
de actualizat sunt permise numai valori unice.
Sintaxa:
UPDATE nume_tabela
SET nume_câmp 1= valoare 1
[,nume_câmp 2 = valoare 2]...
[WHERE criteriul_de _actualizare];
Unele sisteme de baze de date pun la dispoziţie o extensie la sintaxa standard a instrucţiunii
UPDATE. De exemplu, limbajul Transact–SQL al sistemului SQL Server permite
programatorului să actualizeze conţinutul unui tabel pe baza conţinutului altor câteva tabele, prin
folosirea clauzei FROM. Sintaxa extinsă arată astfel:
202
UPDATE nume_tabela
SET nume_câmp 1= valoare 1
[,nume_câmp 2 = valoare 2]
FROM listă_tabele
[WHERE criteriul_de _actualizare];
Tipul datelor rezultate din evaluarea expresiei trebuie să fie acelaşi cu tipul de dată al câmpului
care este modificat. De asemenea, dimensiunea (lungimea) valorii trebuie să fie
corespunzătoare cu câmpul care este modificat.
La obţinerea rezultatelor în valoarea calculată pot rezulta două situaţii:
trunchierea – atunci când sistemul de baze de date converteşte, de exemplu un
număr fracţionar într–un număr întreg;
depăşirea zonei de memorie – atunci când valoarea rezultată este mai mare decât
capacitatea coloanei modificate. Aceasta va determina semnalarea unei erori de
depăşire 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 hard–disc. După crearea
vederii, se pot folosi următoarele comenzi SQL:
CREATE VIEW – crearea unei vederi;
SELECT – interogarea vederilor;
INSERT – adăugarea de noi date;
UPDATE – actualizarea datelor într–o vedere;
DELETE – ştergerea datelor dintr–o 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 opţional a denumirii atributelor din view, în
cazul când se doreşte redenumirea atributelor specificate în instrucţiunea SELECT;
SELECT – specificarea interogării;
WITH CHECK OPTION – specificarea opţională a unei condiţii suplimentare impuse
203
view–ului, astfel încât 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 afişarea codului, denumirii şi facultăţii studentului.
CREATE VIEW Date_stud AS
SELECT Cod, Nume, Facultate FROM Student;
Ulterior view–ul poate fi vizualizat ca orice tabelă. Date_stud reprezintă view–ul creat în
comanda anterioară. Se doreşte afişarea numai a studenţilor 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 afişarea studenţilor căsătoriţi.
CREATE VIEW Date_stud_C AS
SELECT * FROM Student WHERE Stare_civila='C'
Date_stud_C reprezintă view–ul 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ă view–ul creat în comanda anterioară.
SELECT * FROM Note1
Crearea unei vederi cu notele studenţilor al căror 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'
204
Note2 reprezintă view–ul creat în comanda anterioară.
SELECT * FROM Note2
Crearea unui view complex presupune utilizarea unor funcţii 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ă view–ul creat în comanda anterioară.
SELECT * FROM Medii
SQL plasează câteva restricţii la folosirea instrucţiunii SELECT pentru a formula o vedere.
Următoarele două reguli sunt valabile atunci când folosiţi instrucţiunea 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
205
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=Nota–5
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 studenţilor cu NrLeg par
UPDATE Notele1 SET Nota=Nota–1 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 într–o vedere poate fi un set de date dintr–un grup de tabele,
modificarea datelor în tabelele de bază nu este totdeauna la fel de directă. În continuarea este
prezentată o lista care conţine cele mai obişnuite lucruri pe care trebuie cunoscute atunci când
se lucrează cu o vedere:
Instrucţiunile DELETE nu sunt permise în vederi ale tabelelor multiple;
Instrucţiunea INSERT nu este permisă decât dacă toate coloanele cu atributul
NOT NULL folosite în tabelul de bază sunt incluse în vedere. Aceasta se datorează
206
faptului că procesorul SQL nu cunoaşte ce valori să insereze într–o coloană NOT NULL;
Dacă se inserează sau se actualizează înregistrări într–o vedere a unei combinări,
toate înregistrările care sunt actualizate trebuie să aparţină aceluiaşi tabel fizic;
Dacă se foloseşte clauza DISTINCT pentru crearea unei vederi, nu se mai pot
efectua actualizări sau inserări de înregistrări î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 cunoștințelor
Răspundeți 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 când
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 utilizând o gama de pictograme si combinatii de butoane de
raspuns
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
Încercuiți varianta de răspuns corectă
6. Care vor fi materialele selectate cu interogarea:
SQL> SELECT *
FROM MATERIALE
WHERE Mat LIKE ’C%’;
a. Cherestea, Cot, Con
b. Cot, Con
c. Cherestea
d. nu afiseaza nimic
e. Cot
207
7. Specificati care instructiune nu este folosită pentru implementarea structurii repetitive:
a. While………Wend
b. Do…………...Loop
c. For………….Next
d. For Each…..Next
e. 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 având 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 având urmatoarea structura:
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
208
Capitolul 7
Utilizarea SGBD Access în proiectarea aplicațiilor informatice
Obiective:
Însușirea teoriilor și metodelor de bază în proiectarea bazelor de date Access.
Cunoaşterea caracteristicilor complexe ale SGBD-ului Access și fundamentarea științifică a
utilizării acestuia în aplicațiile informatice financiar contabile.
Utilizarea sistemelor de gestiune a bazelor de date şi a programelor specifice. Conceperea de
machete pentru exploatarea bazelor de date Access utilizând programele și tehnicile studiate.
Cuvinte cheie:colecții de date, bază de date, colecții de obiecte tip, formular ,interogare, raport,
macro-uri.
7.1 Colecţii 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ă câmp, iar fiecare rând al tabelului constituie o înregistrare.
La crearea unui tabel se solicită definirea câmpurilor, atribuindu-se fiecăruia o denumire
unică, având 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 opţiunea
Table.
1. Datasheet View - permite crearea unui tabel în modul foaie de date; este utilizat
pentru inserarea datelelor şi vizualizare. Apoi executăm click pe butonul OK (Dacă se renunţă la
crearea tabelului executăm click pe butonul Cancel). Se va deschide un tabel cu câmpuri
generice: Field 1, Field2...
Pentru a schimba numele câmpurilor din meniul Fields se alege opţiunea
Name&Caption, se tastează noul nume şi se apasă tasta Enter. (Fig 7.1).
209
Fig.7.1
2. Design View - permite crearea unui tabel în modul de proiectare.
Pentru a realiza în acest mod un tabel efectuăm click pe meniul Create apoi selectăm
opţiunea Table design.
În fereastra apărută în coloana FieldName tastăm numele câmpului, în coloana
DataType precizăm tipul de dată pentru fiecare câmp iar în coloana Description se precizează
de către utilizator un text explicativ având ca scop să descrie câmpul. (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 câmp al tabelului cheie primară trebuie să
parcurgem etapele:
tabelul trebuie să fie deschis în modul Design View;
se selectează câmpul căruia vrem să-i atribuim această identificare;
se selectează meniul Design şi se alege opţiunea Primary Key;
Rezultatul acestor etape este apariţia unui simbol sub formă de cheie în dreptul
câmpului selectat.
210
Dacă se încearcă închiderea noului tabel în modul de vizualizare Design View fără a
specifica o cheie principală, apare un mesaj care anunţă că nu a fost atribuită nici o cheie
primară.
Executând click pe butonul Yes în caseta de mesaj determinăm Acces-ul să creeze un
nou câmp AutoNumber în tabel şi-l specifică drept cheie primară. Se poate schimba numele
acestui nou câmp după cum este necesar. Pentru a introduce înregistrări în tabelă selectăm
meniul View şi alegem opţiunea Datasheet View.
Tipurile de date disponibile pentru câmpurile Access sunt:
text - sunt cel mai des folosite, astfel încât Access consideră acest tip ca fiind
cel prestabilit. Un câmp 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 câmp Memo nu
poate fi cheie primară şi se poate indexa după el;
number - admite numai numere (nu poate conţine litere, sau o dată
calendaristică); poate fi la rândul său 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 număr destinat să indice o valoare
bancară, cu 15 cifre la partea întreagă, iar la partea zecimală până la sutimi de
cenţi;
autonumber - datele de acest tip conţin 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 afişate în una;
din formele True/False, respective On/Off;
OLE Object - include elemente grafice realizate din puncte, desene vectoriale,
fişiere cu semnale audio şi alte tipuri de date care pot fi create de o aplicaţie
OLE Server;
Hyperlink - este un text sau o combinaţie de text cu numere stocat(ă) ca un
text şi folosit(ă) ca adresă a unei pagini Web. Este format(ă) din trei părţi: -
textul afişat, adresă şi subadresă;
Lookup Wizard - creează câmpuri 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 câmp se definesc o serie de
proprietăţi (care diferă în primul rând de tipul de dată ales şi de cerinţele aplicaţiei).
Zona în care se stabililesc proprietăţile câmpurilor este formată din urmatoarele opţiuni
(Fig. 7.3).
211
Fig. 7.3
Field Size - această propietate stabileşte numărul maxim de caractere care
poate fi stocat în tipul de cîmp respectiv;
Format - această proprietate prezintă o listă derulantă cu formatele disponibile
pentru respectivul tip de câmp;
Decimal Places - proprietatea care se stabileşte pentru câmpurile numerice; se
pot stabili poziţiile zecimal afişate de un număr;
Input Mask - proprietatea prin care se controlează introducerea datelor;
Caption - proprietatea utilizată pentru a a afişa titlurile numelor de câmp în
modul de afişare 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 restricţiilor referitoare la
domeniul de valori;
Validation Text - proprietatea care permite specificarea conţinutului textului
care se va afişa, în cazul introducerii unei realizări ce nu respectă regula de
validare;
Requiered - proprietatea care se utilizează în momentul în care se doreşte
introducerea în câmpul respectiv a unei valori în mod expres, valoarea
câmpului nu poate fi nulă;
Indexed - proprietatea care permite definirea unui fişier index pe atributul
respectiv; indecşii asigură mecanismul de regăsire rapidă a datelor. Un atribut
se indexează în condiţiile în care atributul cuprinde valori cu gamă largă; de
variaţie şi atributul va fi folosit în mod semnificativ în criteriile de selecţie sau
sortare.
212
Relaţii între tabele
Relaţiile între tabele se formează prin precizarea legăturilor între un tuplu dintr-un tabel
şi tuplurile corespunzătoare din alt tabel.
Relaţiile standard pot fi de tip:
1. Relaţia unu la unu (1:1) corespunde situaţiei când unui tuplu dintr-o tabelă îi
corespunde un singur alt tuplu dintr-o altă tabelă. Se mai numeşte şi biunivocă;
Exemplu:
Considerăm tabela Furnizori şi tabela Produs
Codfurnizor Codprodus
Denfurnizor Denprodus
Adresa UM
Contbanca Preţprodus
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.
Relaţia unu la mai mulţi (1:n) corespunde situaţiei în care unui tuplu dintr-o înregistrare
îi corespund mai mutte tupluri dintr-o tabelă. Tabelul din partea unu a relaţiei trebuie să aibă o
cheie unică, numită cheie primară, iar tabelul din partea mai mulţi trebuie să conţină o cheie
străină numită cheie externă.
Exemplu:
Considerăm tabela Furnizori şi tabela Facturi
Codfurnizor Nrfactură
Denfunizor Codfurnizor
Adresa Codprodus
Contbancă Preţfactură
Bancă Datafactură
Cantitate
Relaţia 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ă decât de un furnizor.
3. Relaţia mulţi la mulţi (m:n) corespunde situaţiei când unui tuplu dintr-o tabelă îi pot
corespunde mai multe tupluri dintr-o altă tabelă. Aceste tipuri de relaţii sunt asocieri libere.
213
Exemplu:
Considerăm tabela Funizori şi tabela CentruComercial
Codfurnizor Codccom
Denfurnizor Denccom
Adresa Cod furnizor
Relaţia 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
mulţi furnizori. Descrierea procesului de construire a relaţiilor dintre tabele se face în fereastra
Relationships (Opţiunea 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 acţionând butonul Add sau click dublu pe tabelul respectiv. O relaţie
între tabele se realizează prin operaţia drag and drop de la cheia primară a tabelei principale la
cheia externă a tabelei secundare. Legătura între tabele este marcată printr-o linie care se
numeşte linie de corelare. Fereastra de dialog Edit Relationships (se deschide selectând meniul
Relationships, optiunea Edit Relationship) prezintă legătura î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 referenţială) în
cadrul aplicaţiei, înseamnă că în momentul când se introduce o nouă înregistrare în
tabela secundară, se verifică dacă valoarea cheii externe se găseşte în tabela
primară, în câmpul corespunzător cheii primare. Este necesară încărcarea datelor în
tabela principală mai întâi şi apoi în cea secundară;
214
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 înregistrărilor
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.
Câmpurile de legătură între două tabele trebuie să fie de acelaşi tip şi să aibă aceeaşi
dimensiune.
7.1.2 Obiecte de tip cerere. Interogarea bazelor de date
Interogarea unei baze de date înseamnă regăsirea şi extragerea informaţiilor. O cerere
are ca sursă una sau mai multe tabele sau chiar o altă cerere.
Clasificarea. interogărilor:
Interogări de selecţie - sunt cele mai utilizate interogări şi permit vizualizarea,
modificarea şi extragerea datelor din una sau mai multe tabele sau cereri.
Interogări de tip acţiune - au ca rol de a actualiza, de a şterge, a adăuga, a modifica
şi de a crea noi tabele. Interogările de tip acţiune sunt:
a. Make Table Query - permit crearea unui nou tabel;
b. Delete Query - permite ştergerea uneia sau mai multor înregistrări dintr-un tabel;
c. Append Query - permite adăugarea de noi înregistrări la un tabel dintr-un tabel sursă;
d. Update Query - permite modificarea unui grup de înregistrări selectate pe baza unui
criteriu dintr-un tabel.
Interogări parametrate - se utilizează atunci când este necesară modificarea
frecventă a criteriilor de selecţie în baza de date.
Interogări de tip “Analiză încrucişată” permit generarea unor tabele complexe sub
forma unei foi de calcul tabelar
Crearea interogărilor de selecţie
Atunci când se realizează o interogare selectăm meniul Create şi apoi din grupul
215
Queries se pot alege optiunile Query Wizard şi Query Design.
1. Query Design - reprezentând modul grafic de proiectare.
Pentru a crea o interogare în acest mod accesăm butonul OK şi se va afişa o fereastră
Select Query şi caseta de dialog Show Table. (Fig. 7.5)
Fig. 7.5
Fereastra Select Query este structurată în două părţi:
partea superioară, unde sunt afişate structurile tabelelor din baza de date
partea inferioară numită grilă de proiectare în care se construieşte 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 când este selectat butonul
Tables, interogările când este selectat butonul Queries şi la accesarea butonului Both sunt
prezentate şi tabelele şi interogăriile
Pentru adăugarea tabelelor în fereastra Select Query se acţionează butonul Add; după
ce tabelele sunt selectate caseta de dialog Show Table este inchisă. În cazul în care mai trebuie
adăugat un alt tabel fereastra Show Table va fi readusă pe ecran selectând meniul Query,
opţiunea Show Table. Selectarea unui câmp în grila interogării se face executând dublu click pe
numele câmpului. Numele câmpului va fi afişat în dreptul rândului Field iar tabelul sursa se
specifică în dreptul rândului Table.
Ordonarea se poate face crescator (Ascending) sau descrescător (Descending);
această sortare se face la intersecţia coloanei câmpului respectiv cu caseta Sort.
Criteriile de selecţie
Criteriile de selecţie reprezintă restricţiile pe care le stabilim într-o interogare, pentru a
216
identifica anumite înregistrări din baza de date. Criteriile se introduc în celula aflată la intersecţia
coloanei câmpului 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 doreşte vizualizarea facturile emise doar către beneficiarii care
au conturile la Banca BCR iar modul de vizualizare să se facă in mod descrescător după câmpul
Cod beneficiar.Fereastra Select Query corespunde cerinţelor impuse (Fig. 7.6).
Fig. 7.6
Tabelul 7.7. Principalele criterii simple
OPERAŢIA SEMNIFICAŢIA EXEMPLU
BETWEEN Apartenenţa la un interval de
valori
BETWEEN val_inf and val_super
IN Apartenenţa la lisă de valori IN(val 1, val2, ...)
>
<
>=
<=
=
Mai mare
Mai mic
Mai mare sau egal
Mai mic sau egal
Egal
NOT Operator de negaţie Not valoare
LIKE Comparare cu un nume generic LIKE ,, valoare”
217
Rezolvarea acestei interogări se regăseşte mai jos (Fig.7.8).
Fig. 7.8
Crearea unor câmpuri calculate
În prima linie Field liberă se introduce formula de calcul care are formula generală:
Nume_rezultat: [Câmp 1] Operator matematic [Câmp 2]...
Exemplu:
Se doreşte vizualizarea produselor cu codul (120, 121) şi calcularea câmpului 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 obţinut.
218
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 selectăm opţiunea Simple Query Wizard şi apoi
selectăm butonul OK.
Fereastra deschisă prezintă mai multe opţiuni:
din lista Tables / Query selectăm tabelul sau interogarea dorită;
din lista câmpurilor disponibile Available Field se selectează numele de câmp
şi apoi pentru a-l muta în lista câmpurilor selectate accesăm butonul “>” (Fig.
7.11); dacă se doreşte selectarea tuturor numelor de câmpuri selectăm butonul
“>>”. Când operaţia de selectare a numelor de câmpuri s-a încheiat executăm
click pe butonul Next;
În caseta de text What title do you want fot your query (Ce titlu doriţi pentru
interogarea dumneavoastră) introducem numele interogării şi executăm click
pe butonul Finish şi rezultatul interogării poate fi văzut (Fig. 7.12 ).
Fig. 7.11
219
Fig. 7.12
3. Crosstab Query Wizard - funcţionează similar cu opţiunea Simple Query Wizard cu
menţiunea că se va construi o interogare prin incrucişarea tabelelor.
4. Find Duplicates Query Wizard - compară două tabele şi se va construi o interogare
care va prezenta înregistrările comune.
5. Find Unmatched Query Wizard - este opusul opţiunii Find Duplicates Query Wizard,
adică compară două tabele şi va construi o interogare care va prezenta înregistările care nu
sunt comune celor două tabele.
Interogări de tip acţiune
a. Interogarea Make Table Query
Are ca scop crearea unui tabel format din datele aparţinând unui tabel sau mai multor
tabele. Pentru a transforma o interogare de selecţie în una de tip acţiune cu funcţia de creare a
unei noi tabele se parcurg etapele:
se trece în modul Design View;
se selectează meniul Query şi se alege opţiunea Make-Table ;
pe ecran se afişează fereastra de dialog Make Table unde se introduce noul
nume al tabelei. Se stabileşte dacă aceasta va face parte dintr-o bază de date
Access sau de alt tip şi dacă înlocuieşte o altă tabelă care este deja creată se
apasă apoi butonul OK;
Se selectează meniul Query şi se alege opţiunea Run; se afişează o casetă de
dialog în care se specifică numărul de înregistrări în tabela nou creată.
Tabela nou creată prin această interogare va fi în fereastra Database la obiectul Tables,
iar câmpurile vor moşteni numai tipurile şi dimensiunile din tabele sursă. Se recomandă ca după
executarea interogării cu funcţia de creare să se stabilească cheia primară şi proprietăţile
câmpurilor.
220
Exemplu:
Dorim să creem o nouă tabelă intitulată “Beneficiari din judeţ” în care să fie prezenţi toţi
beneficiarii cu excepţia celor din Craiova (Fig.7.13);
Fig.7.13
b. Interogarea Delete Query
Această interogare are ca scop eliminarea unui grup de inregistrări dintr-un tabel sau
mai multe tabele.
Pentru a crea o cerere de tip acţiune Delete Query în vederea ştergerii unui grup de
înregistrări trebuie să se plece de la interogarea de selecţie.
Se parcurg etapele:
se trece în modul Design View;
se selectează meniul Query şi se alege opţiunea Delete query care va afişa în
grila de proiectare linia Delete;
se selectează meniul Query şi se alege opţiunea Run; se afişează o casetă de
dialog care va prezenta numărul de înregistrări ce vor fi şterse. Se selectează
butonul Yes pentru ştergerea numărului de înregistrări care respectă condiţia
specifică.
Exemplu:
Dorim să ştergem din tabela Factura toate facturile care au numărul facturii mai mic de
124 (Fig. 7.14).
221
Fig. 7.14
c. Interogarea Append Query
Această interogare se foloseşte pentru a insera înregistrări din unul sau mai multe
tabele sursă într-un tabel destinaţie.
Pentru a transforma o interogare din selecţie în una de tip acţiune de adăugare se
parcurg etapele:
se trece la modul Design View;
se selectează meniul Query şi se alege opţiunea Append query, se va afişa
caseta de dialog Append unde se introduce numele tabelei de destinaţie şi se
selectează butonul OK;
se selectează meniul Query şi se alege opţiunea Run; se afişează o casetă de
dialog care va prezenta numărul de înregistrări ce vor fi adăugate. Se
selectează butonul Yes pentru adăugarea înregistrărilor.
Exemplu:
Dorim să adăugăm în tabela Beneficiari judeţ şi acei beneficiari din Craiova, dar care au
contul la banca “bcr”. Tabela Beneficiari din judeţ este tabela destinaţie iar tabela Beneficiari
este tabela sursă. (Fig 7.15)
222
Fig. 7.15
d. Interogarea Update Query
Acestă interogare se foloseşte pentru a efectua modificări globale într-un grup de
înregistrări
Pentru a transforma o interogare de selecţie în una de tip acţiune de modificare se
parcurg etapele:
se trece în modul Design View;
se selectează meniul Query şi se alege opţiunea Update Query; se va introduce în
grila de proiectare linia Update To şi se schimbă numele interogării într-o interogare
de modificare;
se introduc în linia Update To expresiile de calcul sau valorile cu care se vor face
modificările;
se selectează meniul Query şi se alege opţiunea Run; se afişează o casetă de
dialog în care sunt prezentate numărul de înregistrări ce vor fi modificate. Se
selectează butonul Yes pentru modificarea înregistrărilor.
Observaţie:
Nu se pot modifica valorile cheii primare sau aceasta nu poate primi valoarea
Null
Nu este permisă adăugarea sau modificarea unei înregistrări cu valoare
identică a unui câmp 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 decât data reală. Pentru a corecta această eroare se va realiza interogarea
conform Fig.7.16.
223
Fig. 7.16
Când se execută interogarea apare o fereastră de dialog (Enter Parameter Value) în
care introducem Nr. factura care se va actualiza, iar după apăsarea butonului OK apare un
mesaj de avertizare care întreabă dacă sunteţi siguri că vreţi să reactualizaţi înregistrările. Dacă
se apasă butonul Yes câmpul data factura din tabelul Factură va fi actualizat.
Interogări parametrate
Aceste interogări se utilizează atunci când într-o interogare este necesară modificarea
frecventă a Criteriilor de selecţie.
În grila Design pe coloana dorită Criteria în locul unei expresii se vor preciza între
paranteze drepte un mesaj ce este afişat în momentul executării interogării pentru ca utilizatorul
să introducă criteriul de selecţie dorit.
Interogări de tip analiză încrucişată
Aceste interogări 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 obţin prin aplicarea unei funcţii predefinite asupra unui câmp dintr-o tabelă,
Tabelul 7.17
C1 C2. CN
L1 V11 V12 V1n
L2
Lm Vm1 Vmn
Tabelul 7.17
224
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 utilizări:
afişarea şi editarea datelor - este permisă afişarea datelor în modul dorit de utilizator
iar datele pot fi modificate;
introducerea de date - este utilizată atunci când formularul introduce date într-un
tabel asociat;
afişarea de mesaje;
controlul operaţiilor realizate de aplicaţie;
tipărirea informaţiilor.
Formularele pot fi afişate în mai multe moduri:
modul Design - este modul utilizat pentru schimbarea modului de prezentare şi
proprietăţile formularului;
modul Form - este modul de afişare al unui formular în curs de utilizare;
modul Datasheet- este modul de afişare directă a tabelului sau interogării.
Realizarea formularelor
Atunci când 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 opţiunea
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 câmpuri conţinute din
tabele diferite.
Totuşi se poate construi un formular pe baza unei interogări care, la rândul ei, este
realizată prin folosirea mai multor tabele.
Pe ecran apare fereastra cu ecranul de proiectare a formularului.
Fereastra e prevăzută 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 câmpurilor (Field List) Fig.7.18.
225
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 conţinut fix care afişeaza text;
Text Box - caseta de text folosită pentru editarea şi afişarea datelor;
Option Group - crează o casetă de grup şi poate grupa mai multe controale (buton
de opţiune, butoane validare);
Toogle Button - crează un buton de comutare (Yes / No; On / Off; True / False);
Combo Box - îmbină priorităţile unei casete de text cu cele ale unei casete de tip
listă creând o casetă combinată. Această casetă combinată permite editarea datelor
şi selectarea unei valori dintr-o listă derulantă;
Option Button - crează un buton de opţiune; se utilizează mai multe butoane de
opţiune, alegerea unui buton duce la deselectarea celorlalte butoane;
Check Box - crează o casetă de validare; se utilizează mai multe casete de validare
putând accesa mai multe casete în acelaşi timp;
List Box – crează o casetă de tip listă şi afişează tot timpul valorile existente în topul
asociat;
Command Button - crează un buton de comandă, utilizat pentru întreprinderea unor
acţiuni;
226
Image - introduce în formular fişiere 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 adăuga controale din List Field pe formă selectăm câmpurile şi cu butonul
mouselui apăsat luăm câmpurile din Field List şi le aşezăm în fereastra de proiectare (prin
metoda drag and drop).
În mod automat se va realiza o casetă de text legată de câmp şi o etichetă indicând
numele câmpului respectiv.
În cazul în care dorim să adăugăm 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 colţul din stânga sus al controlului;
se deplasează mouseul până când controlul are dimensiuni dorite;
se dă drumul butonului de mouse.
Un alt mod de a adăuga controale din trusa de instrumente Toolbox este prin dublu click
pe caseta de text şi apoi făcând click pe caseta de text şi apoi făcând click de atâtea ori câte
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ă calculăm
câmpul valoare.
Formularul va arăta conform figurii următoare (Fig. 7.20)
Fig. 7.20
227
Pe lânga zona Detail cu care am lucrat, un formular mai conţine:
Secţiunea 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:
Secţiunea de antet (Form Header)
Această zonă este folosită pentru a afişa titlul formularului. Această zonă nu este
vizibilă în modul Datasheet. Pentru a vizualiza această zonă se selectează. meniul View şi apoi
opţiunea Form Header /Footer
Antetul de pagina (Page Header)
Această zona apare când formularul este scos la imprimantă. Pentru a fi disponibilă se
selectează meniul View şi apoi opţiunea Page Header/Footer.
Subsol de pagină (Page Footer)
Această zonă apare când formularul este scos la imprimantă. În această zonă se poate
specifica numărul de pagini, data curentă
Subsolul formularului (Form Footer)
Această zonă poate să conţină diferite informaţii 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 afişarea
228
datelor din mai multe tabele sau interogări, aflate în relaţii de tipul 1:1 sau 1:n.
În formularul principal vor fi afişate date din partea unu a relaţiei, iar în subformular cele
din partea mai mulţi.
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.
Prezentăm î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 având grijă ca acel câmp de legătură 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ă legătura şi apoi rezultatul.
Exemplu: Vom exemplifica construcţia ansamblului formular-subformular pe aplicaţia Facturile
emise beneficiarilor. (Fig.7.22).
Fig.7.22
Formularul principal - Beneficiari
229
Proprietăţile obiectelor - Forms
Fiecare obiect definit în modul Design View (fereastra de proiectare a formularului) are
nişte proprietăţi.
Aceste proprietăţi modifică comportamentul obiectului (Fig. 7.23)
Fig. 7.23
Proprietăţile formularului se pot modifica în cadrul ferestrei de proprietăţi care se
activează prin selectarea meniului View şi apoi opţiunea Properties.
În această fereastră proprietăţile formularului se grupează în 5 categorii:
1. Format - prezintă proprietăţile care se referă la culoare, dimensiune, mod de
vizualizare.
Cele mai folosite proprietăţi sunt:
Caption - se specifică numele formularului;
Default View - se specifică modul implicit de afişare;
Scroll Bars - se setează barele de defilare vizibile în cursul execuţiei;
Navigation Buttons - specifică dacă formularul are butoane de navigare în
cursul execuţiei;
Border Style - se specifică tipul bordurii;
Control Box - indică prezenţa meniului sistem în bara de titlu.
2. Data - prezintă proprietăţile care se referă la datele asociate controlului
Record Source - conţine sursa de date a formularului;
Filter - conţine criteriul de selecţie care se va aplica înregistrărilor din formular.
Pentru ca filtrul să fie activ, proprietatea din formular Filter On trebuie sa aibă
valoarea True;
230
Order By - permite specificarea câmpurilor după care vor fi sortate
inregistrările.
3. Event - grupează evenimentele ce pot fi tratate fie prin proceduri sau funcţii scrise în
limbajul VBA, fie prin macro-uri;
Există 3 posibilităţi:
evenimentul tratat printr-o funcţie - proprietatea evenimentului va conţine o
expresie de forma: Nume funcţie ([Lista parametrii]);
eveniment tratat printr-o procedură eveniment; editarea procedurii se face prin
acţionarea butonului Build Wizard;
eveniment tratat printr-un macrou - proprietatea eveniment va conţine numele
macro-ului.
4. Other - prezintă alte proprietăţi suplimentare.
5. All - prezintă toate proprietăţile care se regăsesc î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 selectăm câmpurile.
Din lista de câmpuri disponibile Available Fields se selectează câmpurile dorite în lista
câmpurilor selectate Selected Fields. (Fig. 7.24).
Fig. 7.24
231
În situaţia când vrem să adaugăm în formulare alte cârnpuri 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 următoare se alege stilul de vizualizare, iar la selectarea butonului Next se
ajunge în ultima fereastră unde se salvează formularul sub ce nume se doreşte.
AutoForm: Columnar
Se crează un formular cu câmpurile aşezate pe coloane.
7.1.4 Obiecte de tip Raport
Tabelele şi formularele furnizează diverse căi de introducere a înregistrărilor în baza de
date, iar interogările 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 când se crează un raport selectăm meniul Create şi apoi butonul REPORT
Report Design
Pentru a crea un raport în modul Design View trebuie să se selecteze opţiunea 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
interogări.
Pentru a crea un raport cu Report Wizard se parcurg următoarele etape:
se selectează opţiunea Report Wizard din fereastra New Report şi apoi butonul OK.
Din lista de câmpuri disponibile, Available Fields, selectăm câmpul dorit şi pentru a-l
muta în lista câmpurilor selectate Selected Fields se accesează butonul “>” (Fig.
7.25);
232
Fig. 7.25
pentru a trece la fereastra următoare se selectează butonul Next; în fereastra
afişată se grupează înregistrările după oricare din câmpurile selectate. Se
selectează câmpul 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 înregistrărilor din raport. Dacă se sortează
înregistrări după un anumit câmp sau după mai multe câmpuri se deschide fereastra
derulantă şi se pot selecta maxim patru câmpuri de sortare. Sortarea în ordine
ascendentă se face implicit (Ascending); dacă se doreşte schimbarea ordinii se
execută un click pe butonul Ascending şi se va afişa sortarea descendentă
(Descending);
233
Fig. 7.26
setarea butonului Next duce la apariţia următoarei 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 tipărit. Portrait - de-a lungul hârtiei sau
Landscape - de-a latul hârtiei; la următoarea 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 tipări raportul dacă
sunteţi multumiţi de felul cum arată. În modul Print Preview se poate mări sau micşora
dimensiunea de afişare a raportului pe ecran utilizând instrumentul Zoom (se execută click o
dată pe butonul mouse-ului pentru mărire şi se execută click din nou pentru micşorare).
Pentru tipărirea raportului se selectează meniul File şi apoi opţiunea Print. Dacă trebuie
schimbate marginile raportului sau să se modifice orientarea raportului pe pagină se selectează
meniul File şi opţiunea PageSetup. Se afişează caseta de dialog Page Setup (Fig. 7.27).
234
Fig. 7.27
În caseta de dialog Page Setup sunt etichetele:
Margins -permite setarea marginilor de sus, de jos, din stânga şi din dreapta ale
paginii;
Page - permite schimbarea orietării paginii raportului pe pagina tipărită;
Columns - permite schimbarea numărului de coloane din raport şi distanţa dintre
coloane.
Auto Report Columnar şi Auto Report Tabular
Se va crea un raport automat în care datele vor fi afişate î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 doreşte construirea unui raport care să aibă la bază mai multe tabele, mai întâi
trebuie creată o interogare pe baza acelor tabele şi apoi se crează raportul.
Chart Wizard
Crează un raport în interiorul căruia va fi prezentat un grafic.
Label Wizard
Crează etichete poştale care pot fi tipărite la imprimantă pe suporturi speciale de hârtie.
235
7.1.5 Obiecte de tip Macro
Un obiect tip macro este desemnat printr-un nume şi are ca scop automatizarea unor
acţiuni asupra unor obiecte ale bazei de date.
Macrourile definesc o serie de comenzi care se execută automat la apariţia unor
evenimente.
Macrourile pot fi ataşate unui formular sau control, în scopul automatizării unor operaţii
diverse (tipărirea rapoartelor, deschiderea şi inluderea formularelor, lansarea în execuţie 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ă acţiunea dorită;
în coloana Comment se tastează în dreptul fiecarei acţiuni eventualele explicaţii.
Aceste comentarii sunt opţionale;
în grila Action Arguments din partea inferioară se completează argumentele acţiunii
selectate. Conţinutul grilei de argumente se modifică în funcţie de elementul selectat
în lista Action, fiecare acţiune are propriile argumente.
Tipuri de acţiuni macro
În Microsoft Access utilizatorul are posibilitatea să aleagă în lista Action a ferestrei
Macro dintr-un număr de 56 acţuni prestabilite.
În continuare vor fi prezentate cele mai importante acţiuni macro grupate după criteriul
funcţionalităţii acestora:
236
1. Acţiuni macro pentru manipularea obiectelor de date:
Denumire Scop
OpenForm Deschide sau activează un formular într-unul din modurile
de afişare
OpenModule Deschide modulul specificat şi afişează procedura indicată
OpenQuery Deschide o interogare de selecţie sau încrucişată ori
execută o interogare
OpenReport Deschide un raport în modul de afişare specificat şi filtrează
înregistrările înainte de tipărire
OpenTable Deschide o tabelă
Close Închide un obiect deschis al bazei de date
DeteteObject Şterge obiectul specificat
SetValue Stabileşte valori sau modifică proprietăţile pentru câmpurile,
controalale şi proprietăţile formularelor şi rapoartelor.
GoToControl Deplasează cursorul la câmpul specificat sau la obiectul de
control din înregistrarea curentă dintr-un formular, tabelă
sau interogare
ApplyFilter Execută filtrarea înregistrărilor dintr-o tabelă sau raport.
Maximize Maximizează fereastra activă
Minimize Minimizează fereastra activă.
MoveSize Deplasează şi redimensionează fereastra activă
RenameObject Redenumeşte obiectul specificat
2. Acţiuni macro pentru navigarea în cadrul înregistărilor bazei de date
Denumire Scop
FindNext Identifică prima înregistrare care este identică cu cea
specificată de acţiunea
FindRecord Caută o înregistrare
GoToRecord Produce deplasarea la înregistrarea specificată
3. Acţiuni pentru controlul execuţiei aplicaţiei
Denumire Scop
Beep Produce un semnal de avertizare
CancelEvent Anulează evenimentul care a cauzat executarea
comezii macro
237
MsgBox Afişează o casetă cu un mesaj de avertizare şi
aşteaptă ca utilizatorul să execute un click pe butonul
OK
Quit Inchide execuţia programului Access
RunApp Execută o aplicaţie Windows sau MS-DOS
RunCode Execută o funcţie definită de ulilizator scrisă în limbajul
Visual Basic pentru aplicaţii (VBA)
RunMacro Execută comanda macro specificată
RunSQL Execută o instrucţiune SQL de tip acţiune
SetWarnings Activează sau dezactivează mesajele de control
prestabilite
StopMacro Opreşte comanda macro ce conţine acţiunea
StopAllMacros Opreşte toate comenzile macro aflate in acţiune
4. Acţiune pentru crearea şi modificarea intefeţei cu utilizatorul
Denumire Scop
AddMenu Adaugă un nou meniu pentru formular sau pentru
întreaga aplicaţie;
ShowToolbar Ascunde sau afişează pe ecran o bară de instrumente
SetMenuItem Setează starea (activă sau inactitvă) a unui element din
meniuri
5. Acţiuni pentru atomatizarea ieşirilor aplicaţiei şi facilitarea comunicării cu
alte programe
Denumire Scop
PrintOut Tipăreşte obiectul activ al bazei de date
TransferDatabase Permite importarea sau exportarea obiectelor
bazei de date
TransferSpreadsheed Exportă sau importă date din fişiere create cu
procesoare de tabele precumMicrosoft Excel
238
SendObject Include obiectul activ al bazei de date într-un
mesaj trimis prin poşta electronică.
7.2 Dezvoltarea rapidă a unei aplicaţii
Se dezvoltă rapid o aplicaţie de evidenţă a furnizorilor . Pentru a rezolva această
aplicaţie trebuie să realizam în baza de date (EvidFurniz) două tabele Furnizori şi Factura.
Tabela Furnizori are următoarea structură:
Furnizori (cod furniz., den furniz., adresa, banca, cont banca).
Iar tabela Factura are următoarea structură:
Factura (nr. Fact., data fact., val. Fact., cod furniz.).
Observaţie:
Câmpul subliniat cu linie continuă este cheie primară în tabel iar câmpul subliniat cu
linie punctată este cheie externă.
Etapele care trebuie parcurse sunt:
se alege opţiunea 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 afişează pe ecran fereastra New Table (Fig. 7.30)
239
Fig.7.30
se alege opţiunea Design View (Fig.7.31);
Fig.7.31
Apare fereastra Save As, se denumeşte tabelul şi apoi click pe butonul OK;
se afişează fereastra Table în care trebuie introduse câmpurile tabelului creat.
În coloana FieldName se tastează numele câmpului, în coloana DataType precizăm
tipul de dată şi în coloana Description se precizează un text explicativ.
În urma introducerii acestor elemente fereastra Table va arăta conform Fig.7.32
240
Fig.7.32
Observaţie:
Dacă nu se precizează câmpul ce constituie cheia primară, Access generează automat
câmpul ID tip AutoNumber care prin valorile sale, va identifica unic înregistrările de date.
După ce a fost creată structura tabelului trebuie introduse înregistrări. În fereastra
Database se selectează tabelul Furnizori şi se acţionează butonul Datasheet View şi apoi se
introduc înregistrările (Fig.7.33).
Fig 7.33
Parcurgând aceleaşi etape, se creează tabelul Factura.
Se doreşte 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:
241
se creează o cerere: din fereastra Database se selectează obiectul Queries şi apoi
se selectează butonul Create. Pe ecran se afişează 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 selectând tabela
Furnizori (Fig.7.35).
Fig.7.35
în interfaţa QBE, care se va afişa pe ecran sunt specificate câmpurile necesare:
Denumire furnizor, Adresa furnizor, Banca; aceste câmpuri sunt selectate prin dublu
click din tabela Furnizori aflată în partea de sus a ferestrei.
La intersecţia dintre câmpul Adresa şi linia Criteria se tastează "Craiova" iar la
intersecţia dintre Bancă şi linia Criteria se tastează “bcr” (Fig.7.36).
242
Fig. 7.36
Pentru a vedea rezultatul interogării se selectează meniul View şi apoi opţiunea
Datasheet View (Fig. 7.37).
Fig .7.37
Observaţie:
Microsoft Acces generează automat exprimarea cererii în limbajul SQL. Dacă se
selectează meniul View şi apoi opţiunea SQL View, pe ecran se afişează fereastra SQL al cărui
conţinut este Fig. 7.38
243
Fig.7.38
Cererea se poate simplifica de către 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 - condiţia care trebuie să o îndeplinească înregistrările pentru a fi selectate
Operaţiile de actualizare a bazelor de date sau de afişare 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, opţiunea FormWizard.
Pe ecran se afişează un formular tip coloană (Fig.7.39).
244
Fig.7.39
Formularul construit automat poate fi apoi modificat; pentru a fi modificat se alege
meniul Create, opţiunea Form şi apoi Design View
De exemplu, dorim să creem un control care să ne poziţioneze pe următoarea
î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 opţiuni disponibile "Categories” se selectează “Record Navigation” şi
apoi se selectează butonul Next.
245
Î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 acelaşi mod se creează şi butoane pentru ştergerea unei înregistrări , pentru
adăugarea unei înregistrări, etc. Se doreşte ca rezultatul interogării unei baze de date să fie
prezentat sub forma unei situaţii 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).
246
Fig.7.43
Modelul raportului generat poate fi îmbunătăţit: se selectează meniul Create, Report şi
apoi opţiunea Design View.
Pe ecran se afişează modelul raportului pe care utilizatorul îl poate modifica (Fig.7.44).
Fig. 7.44
7.3 Facilităţi Access pentru dezvoltarea de aplicaţii
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 fişiere 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 fişiere (de tip text, Excel, HTML etc.).
Pentru importarea datelor se va selecta Meniul External Data, Import&Link (Fig. 7.45)
247
Fig. 7.45
Dacă fişierul sursă este:
baza de date Access, atunci se pot importa toate tipurile de obiecte ale bazei de
date (tabele, interogări, formulare etc.);
un fişier bază de date dBase (.dbf)/FoxPro (.dbf)/Paradox (.db), atunci pentru a fi
importaţi şi indecşii, fişierele index asociate (.ndx sau .mdx pentru dBase, .idx sau
.cdx pentru FoxPro, .px pentru Paradox) trebuie să existe în acelaşi director cu
fişierul de date. De asemenea, dacă fişierul de date conţine câmpuri de tip memo,
atunci fişierele memo asociate (.dbt) trebuie să fie disponibile în acelaşi director;
foaie de calcul (Excel, Lotus etc.), atunci toate celulele importate trebuie să conţină
valori îngheţate (celulele care conţin formule vor fi importate sub formă de celule
goale);
un fişier de tip text, atunci utilizatorul trebuie să delimiteze datele ce vor forma
câmpurile 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ă opţiunea Export din meniul Access.
(Fig.7.46).
Fig. 7.46
248
7.3.2. Ataşarea tabelelor în aplicaţii
Tabelele legate pot fi folosite pentru a facilita lucrul în cadrul unei reţele de calculatoare.
Tabelele legate nu sunt tabele propriu-zise, ci legături dinamice către obiectele de tip tabel aflate
în alte baze de date. Se pot crea legături chiar şi spre fişiere de tipuri diferite (în general fişiere
de tipul celor suportate pentru importul de date): Access, dBase, FoxPro, Excel, Paradox, HTML
etc. Utilizatorii pot actualiza datele legate, dar nu pot face modificări de structură (nu pot
adăuga, modifica sau şterge câmpuri).
Această facilitate este frecvent folosită pentru crearea unor aplicaţii de tip front-
end/back-end: pe server-ul reţelei se vor afla tabelele sursă (componente back-end) fie într-o
bază de date Access, fie în fişiere de tipul celor recunoscute pentru importul de date, iar pe
staţiile de lucru (workstations) se vor regăsi fişierele Access ( componente front-end), ce conţin
celelalte obiecte ale aplicaţiei (interogări, formulare, rapoarte, module), precum şi legături către
tabelele aflate în baza de date de pe server. În felul acesta, toţi utilizatorii locali vor avea acces
la aceleaşi date, staţiile de lucru nu vor fi supraîncărcate cu baza de date completă, iar traficul
de pe reţea 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 (fişierul) ca conţine tabelele sursă: (Fig
7.47).
Fig.7.47
Se selectează tabelele pentru care se vor crea legături: (Fig 7.48). Dacă baza de date
sursă este mutată, ştearsă sau redenumită, atunci se impune refacerea legăturilor către tabelele
acesteia.
249
Fig. 7.48
Pictograma folosită pentru afişarea tabelelor legate în fereastra bazei de date, este
însoţită de o săgeată de culoare albastră , orientată spre dreapta. (Fig.7.49).
Fig.7.49
7.3.3 Replicarea bazelor de date
Access pune la dispoziţia utilizatorilor această facilitate, în special pentru asigurarea
unor copii de siguranţă ale bazei de date.
Prin replicare se obţin două baze de date: Design Master (derivată din baza de date
250
originală) şi copia, numită Replica. Numai baza Design Master va permite efectuarea
modificărilor asupra obiectelor replicate (obiectele comune celor două baze de date). Tabelele
replicate sunt sincronizate în ambele sensuri, adică orice actualizare făcută 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ă operaţie 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 operaţiei sau când operaţia de replicare a eşuat) şi se vor crea cele două baze de
date replicate (Master Design şi Replica). Baza de date Master Design va avea dimensiunea
mai mare decât baza de date originală, deoarece operaţia de replicare creează noi obiecte
sistem (tabele, câmpuri şi proprietăţi). Astfel, fiecare tabelă replicată va conţine în plus trei
câmpuri sistem, necesare sincronizării: s_Generation,s_GUID şi s_Lineage.
Baza Master Design nu va mai putea fi transformată într-o bază de date normală decât
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 posibilităţi 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 (protecţie 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 opţiunii Hide in this Group (Fig. 7.50)
251
Fig. 7.50
2. Conversia bazei de date în format MDE are ca scop prevenirea citirii sau modificării
obiectelor de tip formular, raport sau modul. Utilizatorul va putea modifica însă structura
tabelelor şi a macrouri-lor.
Prin operaţia de conversie se creează un nou fişier cu extensia .mde, baza de date
originală rămânând intactă.
Salvarea bazei de date în formatul MDE are drept efect:
inhibarea vizualizării, modificării sau realizarea formularelor, rapoartelor sau
modulelor în modul Design View;
blocarea importului de formulare, rapoarte şi module ale altor aplicaţii,
rămânând 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, excepţie făcând tabelele, query-urile şi macro-urile;
imposibilitatea modificării proprietăţilor şi metodelor obiectelor, deoarece o
bază de date de tip MDE nu mai conţine codul sursă;
prevenirea adăugării, ştergerii sau schimbării referinţelor la librăriile 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 conţine
252
codul compilat al modulelor, formularelor şi rapoartelor (fiind astfel şi mai rapid în execuţie decât
formatul standard)
3.Folosirea unei parole la deschiderea bazei de date este una din cele mai folosite
modalităţi de asigurare a securităţii bazelor de date individuale. Definirea unei parole este
posibilă numai dacă baza de date este deschisă în modul exclusiv, prin selectarea opţiunii
DatabasesTools->Encrytp with Password. (Fig.7.51) Dezactivarea parolei se poate realiza prin
selectarea opţiunii DatabasesTools->Decrytp Database numai atunci când baza de date este
deschisă în mod exclusiv.
Fig.7.51
Parola unei baze de date va deveni un atribut al acesteia, aşa încât fişierul respectiv nu
va putea fi accesat de utilizatori neautorizaţi, chiar dacă se procedează la reinstalarea sistemului
Access.
4. Protecţia la nivel de utilizator (user-level security) se realizează prin crearea unor
utilizatori cu drepturi (permisiuni) diferite asupra bazelor de date şi obiectelor conţinute de
acestea. Această metodă de protecţie este folosită în cazul reţelelor de calculatoare, caz în care
mai mulţi utilizatori pot accesa aceeaşi bază de date, dar cu drepturi diferite asupra acesteia.
Protecţia 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 protecţie
Un utilizator este identificat printr-un nume şi o parolă. Utilizatorii cu aceleaşi drepturi
sunt separaţi în grupuri de utilizatori.
Access pune la dispoziţie două grupuri predefinite de utilizatori:
Admins – utilizatorii acestui grup sunt numiţi administratori ai bazei de date şi
au drepturi depline de administrare-întreţinere 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 obişnuiţi, care implicit au drepturi depline asupra
253
obiectelor bazelor de date.
Pentru a activa procedura de protecţie user-level, este necesar ca utilizatorul Admin să
aibă atribuită o parolă.
Access permite crearea de noi grupuri şi utilizatori prin selectarea opţiunii
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 aparţine. 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 număr de identificare din
minimum 4 cifre (acest număr 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 moşteni drepturile .
Un utilizator trebuie să aparţină obligatoriu de grupul Users.
Pentru modificarea drepturilor aferente grupurilor sau utilizatorilor se va selecta
opţiunea 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. Informaţiile referitoare la user-i sunt salvate într-o bază de date sistem care va fi citită
automat la deschiderea unei sesiuni Access. Aşadar, o bază de date asupra căreia au fost
definite protecţii la nivel de utilizator poate fi utilizată fără nici o restricţie într-o sesiune Access în
care nu este activată procedura de securitate user-level (utilizatorul implicit este Admin)!
5. Criptarea presupune ascunderea informaţiilor din baza de date, astfel încât 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, când se doreşte păstrarea confidenţialităţii
datelor. Bazele de date criptate presupun operaţii suplimentare de decriptare automată, ceea ce
încetineşte execuţia programului Access.
Pentru a cripta/decripta o bază de date se selectează opţiunea Tools->Security-
>Encrypt/Decrypt Database.
254
7.3.5. Accesarea concurentă a bazelor de date
În regim multiuser, apare problema tratării accesului concurent la bazele de date, când
doi sau mai mulţi utilizatori doresc editarea în acelaşi timp a unei înregistrări. În acest caz,
sistemul nu poate proceda decât la tratarea secvenţială 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 conţine înregistrarea curentă în
timpul salvării acesteia de către un utilizator. Astfel, înregistrarea respectivă va fi read-only
pentru ceilalţi utilizatori, atâta timp cât operaţia de salvare nu este încheiată.
Această variantă de blocare a datelor poate fi realizată astfel:
Implicit, prin selectarea opţiunii Default Record Locking din meniul Tools-
>Options->Advanced;
La nivel de formular, prin setarea proprietăţii Record Locks pe valoarea No
Locks;
Pentru un obiect recordset, prin setarea proprietăţii LockEdits pe valoarea
False.
2. Blocare pesimistă – permite blocarea paginii ce conţine înregistrarea curentă, în
timpul editării acesteia de către un utilizator. Înregistrarea curentă nu va putea fi editată de un alt
utilizator până când ea nu va fi salvată de utilizatorul curent. Blocarea pesimistă se poate
realiza:
Pentru varianta implicită, prin selectarea butonului de opţiune Edited Record
pe meniul Tools->Options->Advanced;
La nivelul formularelor, prin setarea proprietăţii 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 situaţii î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 operaţia prin care se reduce dimensiunea bazei de date (nu trebuie
făcută confuzie între compactare şi comprimare, care este o operaţie 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 înregistrări, Access nu elimină şi spaţiul
afectat acestora, astfel că, după mai multe operaţii de acest gen, dimensiunea bazei de date
rămâne aceeaşi. Prin compactare se elimină din baza de date tocmai aceste spaţii neutilizate.
255
Pentru repararea şi compactarea unei baze de date, se selectează opţiunea
DatabasesTools->Compact and Repair Database. Utilizatorul va fi anunţat printr-un mesaj, dacă
operaţia de reparare şi compactare a fost sau nu încheiată cu succes.
7.3.7. Optimizarea bazelor de date
În general, o aplicaţie proiectată şi dezvoltată corect presupune nu numai obţinerea
rezultatelor cerute de beneficiar, ci şi asigurarea unui timp cât 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 opţiunii
DatabasesTools->Analyze->Analyze Performance din meniul Access. (Fig. 7.52).
Fig. 7.52
Analyze Performance furnizează recomandări în vederea optimizării bazei de date, dar
permite şi optimizarea propriu-zisă a acesteia.
Este indicat însă ca şi programatorul să ţină cont de următoarele recomandări în
vederea optimizării bazei de date:
1. Optimizarea tabelelor. În general, procesul de nominalizare conduce la obţinerea
unor tabele optimizate. Se mai pot avea în vedere şi următoarele recomandări:
Folosirea unor tipuri de date şi dimensiuni cât mai adecvate pentru câmpuri.
De exemplu, pentru câmpul UnitateDeMăsură este suficientă o dimensiune de
maximum 3 caractere.
Evitarea definirii cheilor primare pe câmpuri 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 câmpurilor care vor fi folosite în ordonări, criterii (filtre) sau în relaţii
(dacă pentru câmpurile de tip cheie externă, utilizatorul nu creează indecşi,
acest lucru va fi făcut automat de Access);
Utilizarea moderată a indecşilor. Chiar dacă aceştia permit realizarea unor
operaţii într-un timp mai scurt, nu se recomandă folosirea lor abuzivă,
256
deoarece operaţiile de actualizare vor fi mai lente.
2. Optimizarea interogărilor. Pentru obiectele de acest tip se au în vedere următoarele:
Folosirea în criterii (sau clauza SQL Where ) numai a câmpurilor indexate;
Se va evita folosirea în criterii a câmpurilor din partea n a unei relaţii;
Utilizarea în clauza Group By (dacă este posibil) a câmpurilor indexate şi
totodată a unui număr redus de câmpuri;
Pentru interogările destinate numai afişării datelor se poate recurge la folosirea
tipului Snapshot;
Salvarea interogărilor în timpul execuţiei.
3. Optimizarea formularelor.
În general, formularele sunt mari consumatoare de resurse, aşa încât sunt indicate
următoarele:
Evitarea supraîncărcării formularelor cu controale;
Renunţarea la utilizarea unor imagini grafice în cadrul formularelor;
Evitarea deschiderii mai multor formulare decât sunt necesare;
Setarea proprietăţii Data Entry pe Yes reduce timpul necesar încărcării unui
formular;
Evitarea folosirii unor proceduri complicate pentru evenimentul OnCurrent.
4. Optimizarea rapoartelor.
Pentru rapoarte se recomandă:
Renunţarea la ataşarea controalelor de tip imagine, butoane, casete
combinate, etc., deoarece acestea nu vor avea nici o utilitate într-un raport;
Utilizarea unor proceduri cât mai simple pentru evenimentul On Format sau
chiar renunţarea, dacă este posibil la aceste proceduri;
Sortarea şi gruparea datelor se va face, dacă este posibil, numai după câmpuri
indexate.
7.3.8. Analiza şi documentarea bazelor de date
Una dintre principalele etape parcurse în realizarea unei aplicaţii o constituie şi
elaborarea documentaţiei care trebuie să cuprindă descrierea tuturor obiectelor bazei de date şi
care este necesară pentru dezvoltări/modificări ulterioare.
Access pune la dispoziţia dezvoltatorilor de aplicaţii un utilitar numit Database
Documenter, care elaborează automat documentaţia fie pentru toate, fie pentru anumite obiecte
bazei de date. Apelarea acestui utilitar se realizează prin operaţiunea Tools->Analyze-
>Database Documenter. (Fig. 7.53)
257
Fig. 7.53
Documentaţia generală de Documenter conţine:
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:
Proprietăţi (condiţii de validare, numărul de înregistrări etc.);
Câmpurile cu proprietăţile aferente (denumire, tip, lungime, cheie primară etc.);
Indecşii (denumire, tip etc.);
Relaţiile cu celelalte tabele ale bazei de date;
Utilizatorii/grupurile de utilizatori ce au drepturi asupra tabelei.
3. Pentru obiecte de tip interogare:
Proprietăţi (tipul de interogare, data creării etc)
Comandă SQL aferentă;
Câmpurile conţinute de interogare, cu proprietăţile corespunzătoare;
Indecşii conţinuţi din interogare;
Drepturile aferente fiecărui utilizator asupra interogării respective.
4. Pentru obiecte de tip formular:
Proprietăţi (tipul formularului, sursa de date etc.);
Controale conţinute de formular, inclusiv secţiunile acestuia, cu proprietăţile
aferente;
Module incluse în formular;
Utilizatorii, cu permisiunile fiecăruia asupra formularului.
5. Pentru rapoarte:
Proprietăţi (titlul, sursa de date etc.);
258
Obiectele incluse (controale şi secţiuni), cu proprietăţile respective;
Utilizatorii ce pot executa sau modifica raportul.
6. Pentru obiectele macro:
Proprietăţi (data creării, proprietarul etc.);
Acţiunile conţinute;
Utilizatorii ce pot executa/modifica macro-ul.
7. Pentru obiecte modul:
Proprietăţi (data creării, proprietarul etc.);
Codul inclus (declaraţii, funcţii şi proceduri VBA);
Drepturile utilizatorilor asupra modulului.
8. Pentru relaţiile definite între tabele:
Tabelele ce formează relaţiile;
Tipul fiecărei relaţii etc.
Teste de evaluare a cunoștințelor
Încercuiți variantele de răspuns 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 câmpurilor unei tabele prezintă următoarele opţiuni:
a. FieldName, DataType, Description;
b. FieldName, DataName, LookUp;
c. FieldName, DataType, LookUp.
259
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 utilizăm fereastra Select Query care este
structurată în:
A. partea superioară, unde sunt afişate structurile tabelelor din baza de date;
B. partea inferioară numită grilă de proiectare în care se construieşte 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).
260
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, afişarea proprietăţilor unui obiect se face:
10. În Microsoft Access se utilizează şi criteriul de selecţie LIKE care semnifică:
a. Apartenenţa la un interval de valori;
b. Apartenenţa la listă de valori;
c. Comparare cu un nume generic;
d. Operator de negaţie.
a. pe grupe de proprietăţi, fiecare grupă de proprietăţi aflându-se pe câte o fişă;
b. pe grupe de activităţi, fiecare grupă de activităţi având semnificaţia descrisă printr-un
simbol ;
c. pe grupe de sarcini, fiecare sarcină având precizate numere de ordine ;
d.pe grupe de proprietăţi, fiecare grupă de proprietăţi indicând formatul unui obiect ;
d. pe grupe de proprietăţi, fiecare grupă de proprietăţi indicând o listă de acţiuni la care este
posibil a răspunde obiectul căruia îi sunt asociate, ca urmare a apariţiei unor evenimente.
261
Capitolul 8
Auditul sistemelor informatice
Obiective:
Însușirea conceptelor de audit al sistemelor informatice
Identificarea și evidențierea zonelor de expunere la risc, precum și a eventualelor deficiențe în
strategiile actuale de aborsare a riscurilor
Cunoașterea teoriilor și metodelor de bază pentru pregătirea informațiilor 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 Particularităţile procesului de audit al sistemului informatic
Auditul informatic reprezintă o formă esenţială prin care se verifică dacă un sistem informatic îşi
atinge obiectivul pentru care a fost elaborată. Standardele definesc clar domeniul, activităţile,
etapele, conţinutul auditării şi formele de finalizare. Respectând cerinţele standardelor, rezultatul
procesului de auditare informatică este eliberat de riscurile contestării.
Auditul informatic reprezintă un domeniu cuprinzător în care sunt incluse toate
activităţile de auditare pentru : specificaţii, proiecte, software, baze de date, procesele specifice
ciclului de viaţă ale unui program, ale unei aplicaţii informatice, ale unui sistem informatic pentru
management şi ale unui portal de maximă complexitate, asociat unei organizaţii virtual.
8.1.1 Operaţii specifice auditării sistemelor informatice
Într-un organism economic, funcţia de auditor al sistemului informatic trebuie să existe
separat şi distinct de funcţia 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 prelucrărilor şi distribuirilor automate de date, în
timp ce auditorii evaluează eficienţa prelucrărilor efectuate asupra datelor şi a controalelor
corespunzătoare, în ansamblu.
Auditorii sistemelor informatice trebuie să participe la proiectarea acestora pentru a se asigura
că:
262
sistemul creează un jurnal corect şi complet al prelucrărilor (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 prevăzute în proiect;
stabilesc dacă toate controalele interne implementate în sistem funcţionează aşa cum a fost
planificat;
iau măsurile necesare pentru corecţia erorilor de implementare şi funcţionare a controalelor
interne prevăzute în proiect;
identifică eventualele schimbări neautorizate efectuate în sistemul informatic şi iau măsurile
necesare pentru eliminarea sau autorizarea acestor schimbări.
Pentru asigurarea controlului intern, la nivelul solicitat de utilizatori, definit prin proiect, auditorii
îndeplinesc următoarele sarcini:
verifică separarea, din punct de vedere funcţional, a personalului de programare de personalul
de operare şi impun măsurile organizatorice necesare pentru realizarea acestei separări;
verifică documentaţia iniţială a sistemului informatic şi actualizarea acesteia, în cazul în care
sunt autorizate schimbări;
verifică îndeplinirea sarcinilor care au fost atribuite personalului autorizat sau grupului
de control al sistemului informatic;
urmăresc aplicarea măsurilor de siguranţă a sistemului informatic;
urmăresc funcţionarea efectivă a controlului, în cadrul organismului economic care
utilizează, pentru evidenţa activităţilor sale, un sistem informatic.
Funcţia 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, prezenţa permanentă a acestuia
la locul de muncă. Dacă volumul de activitate desfăşurat sau nivelul de eficienţă solicitat pentru
controlul intern al sistemului informatic utilizat este ridicat, organismul economic trebuie să
angajeze proprii săi auditori. În caz contrar, poate folosi, pentru îndeplinirea sarcinilor de audit,
colaboratori externi specializaţi, care pot ocupa funcţia 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
independenţi sau angajaţi ai organismelor financiare sau agenţiilor guvernamentale de control.
263
Auditorii pot folosi pentru testarea şi monitorizarea controalelor interne implementate într-
un sistem informatic aşa-numitul sistem integrat de testare, care constă în integrarea unui set de
fişiere de test, programe şi date de test în sistemul informatic respectiv. Aceste fişiere de test
permit ca datele de test pe care le conţin să fie prelucrate simultan cu datele reale, fără ca
datele reale respective şi rezultatul prelucrării lor să fie afectate. Datele de test, care cuprind
toată gama imaginabilă de date posibil a fi introduse în sistemul informatic respectiv, afectează
numai fişierele de test şi rezultatele prelucrărilor 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 prelucrărilor
datelor de test în vederea studierii efectelor produse de prelucrările efectuate asupra fişierelor
de test, listelor de erori şi ieşirilor sistemului informatic. Ei comunică concluziile personalului
autorizat sau grupului de control care efectuează controlul zilnic.
Spre exemplu, un sistem integrat de testare pentru aplicaţii de salarizare şi evidenţă
personal poate defini un departament fictiv pentru care înregistrează angajaţi fictivi în fişierele
de angajaţi ş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 ieşirile
aferente departamentului fictiv, inclusiv înregistrările de salarii, listele de erori şi cecurile emise.
În acest caz, e necesar un control strict al ieşirilor î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 fişierele fictive. Pentru eliminarea acestui dezavantaj,
auditorii trebuie să monitorizeze toate activităţile în fişierele fictive utilizate şi să impună măsuri
riguroase de prevenire a accesului neautorizat la aceste fişiere. De asemenea, proiectarea unui
astfel de sistem trebuie făcută cu atenţie, pentru a elimina riscul ca fişierele reale să fie
contaminate întâmplător cu date din fişierele de test.
Organismele economice, care folosesc sisteme manuale sau mecanice de prelucrare a
datelor, întocmesc documente de evidenţă, prezentare şi control al activităţilor desfăşurate pe
suport material (hârtie), pe care orice modificare de date (înregistrare, actualizare sau ştergere)
lasă urme, rămâne vizibilă.
Sistemele informatice, fiind sisteme automate de prelucrare, evidenţă şi stocare a
datelor, permit modificarea datelor introduse (înregistrate) în sistem (pe suport electronic), fără
nici o urmă vizibilă a schimbărilor făcute. La începutul dezvoltării sistemelor informatice, acest
lucru a produs o mare îngrijorare printre economişti (contabili, finanţişti, auditori etc.) care
264
considerau că prelucrările electronice de date vor ascunde, sau chiar vor elimina, înregistrările
de date necesare în procesul de audit.
Deşi, din punct de vedere tehnologic, este posibilă proiectarea unui sistem informatic în
care datele produse de activităţile efectuate de organismele economice să nu fie înregistrate, în
vederea efectuării 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
activităţilor desfăşurate de un organism economic de către factorii acestuia de decizie
(managerii săi); nevoia de reconstrucţie a fişierelor de date şi de program, distruse de
eventualele erori de prelucrare sau posibilele defecte tehnice; desfăşurarea activităţii de control
(audit) de către auditori independenţi sau agenţii guvernamentale.
În cazul sistemelor informatice sofisticate, dificultatea unui audit este dată de faptul că
înregistrările datelor rezultate din activităţile organismelor economice, folosite în procesul de
audit, pot exista numai pe suport electronic, într-un format cod-maşină, nu şi într-o formă tipărită.
Uneori, după ce sunt generate, datele pentru audit sunt transferate pe un mediu de stocare cu
preţ redus, cum ar fi microfişele.
Mai mult decât atât, anumite organisme economice folosesc aşa-numitul Electronic
Data Interchange (EDI), în care organismul economic respectiv, împreună cu clienţii şi furnizorii
săi folosesc legături de comunicaţii electronice (telecomunicaţii, comunicaţii radio sau pe fibră
optică etc.) pentru a schimba date pe cale electronică.
În astfel de cazuri, documentele sursă tipărite (facturi, ordine de plată, cecuri, avize de
expediţie etc.) sunt înlocuite cu documente similare în format electronic. Exemplu: într-un sistem
informatic de tip EDI, o tranzacţie de cumpărare poate fi iniţiată automat de către calculatorul
firmei care solicită cumpărarea prin trimiterea unui mesaj electronic, de tip comandă direct, la
calculatorul furnizorului său.
În aceste condiţii, auditorii trebuie să utilizeze controale de audit care să integreze
tehnici specifice de retenţie a datelor şi de prelucrare a lor, în vederea asigurării unui audit
adecvat.
Într-un sistem informatic, datele necesare auditului pot fi înregistrate:
pe documente tipărite din calculator;
în format electronic, citibil numai pe calculator.
În sistemele informatice, datele nu se înregistrează într-un format tradiţional, pe
documente sursă scrise de mână, ci numai în format electronic, care poate fi tipărit, la cerere, pe
suport material de tip hârtie sau poate fi urmărit direct pe ecranul calculatorului.
265
Prin urmare, teama economiştilor că utilizarea sistemelor informatice în desfăşurarea
activităţilor economice va elimina datele necesare auditului nu s-a materializat. Încă din faza de
proiectare a unui sistem informatic, auditorii interni şi, eventual, externi, urmăresc integrarea în
sistem a unor tehnici de audit care asigură păstrarea (memorarea) datelor necesare efectuării
unui control intern eficient al sistemului respectiv.
Indiferent de tipul sistemului de evidenţă (gestiune) a activităţilor economice şi de
prelucrare a datelor (manual, mecanic sau informatic) folosit de organismele economice,
auditorii trebuie să efectueze un control intern, pentru realizarea căruia este necesar:
să evalueze corect riscul de control (posibilitatea de existenţă a unor erori care nu pot fi
detectate);
să determine natura activităţilor desfăşurate de organismul economic auditat;
să stabilească tipul şi amploarea activităţilor de audit necesare;
să aprecieze timpul necesar pentru completarea auditului.
Pe baza celor stabilite în vederea completării auditului, auditorii pot face organismului
economic recomandări pentru îmbunătăţirea structurii de control intern. Indiferent de tipul
sistemului de gestiune şi prelucrare a datelor folosit de un organism economic, recomandările
pe care le fac auditorii cu privire la controlul intern se împart în patru categorii, corespunzătoare
următoarelor patru tipuri de activităţi:
planificarea auditului; pentru aceasta. auditorii trebuie să înţeleagă suficient de bine rolul
controlului intern, modalităţile 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 adiţionale pentru procedurile de
control ale sistemului informatic;
realizarea testelor adiţionale pentru procedurile de control ale sistemului informatic;
reevaluarea riscului de control al sistemului informatic şi modificarea corespunzătoare a
testelor de evaluare.
Planificarea auditului pentru un organism economic şi necesitatea proiectării de teste de
audit eficiente solicită auditorilor să aibă cunoştinţele de specialitate necesare înţelegerii
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ă
cunoştinţe despre:
procedurile şi tehnicile de audit disponibile;
266
proiectarea şi realizarea controalelor interne; trebuie să ştie ce se urmăreşte 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ă particularităţile fiecăruia, din punct de vedere al auditului;
tehnicile de integrare a controalelor interne în sistemele de gestiune şi prelucrare a datelor
disponibile;
natura activităţilor desfăşurate de organismele economice: caracteristicile şi particularităţile
acestora, din punctul de vedere al auditului;
legislaţia în vigoare.
Evoluţia tehnologică a microcalculatoarelor de tip PC, din ce în ce mai performante şi mai
ieftine, a condus la apariţia şi dezvoltarea continuă a aplicaţiilor 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 dispariţie, fiind înlocuite de
sisteme informatice. În aceste condiţii, auditorii trebuie să aibă cunoştinţe suplimentare de
informatică, minimul necesar care să le permită să îşi desfăşoare activitatea de control.
Pentru a stabili natura, durata şi amploarea activităţilor de audit, auditorul trebuie să aibă
suficiente cunoştinţe informatice pentru a face analiza procedurilor de prelucrare utilizate şi a
rezultatelor acestora.
Auditarea sistemelor informatice simple, care prelucrează datele folosind algoritmi de
calcul uşor de aplicat, nu impune testarea acestor sisteme folosind proceduri de test
implementate pe calculator; în acest caz, auditorii compară rezultatul prelucrărilor datelor de
test, obţinut manual, cu cel obţinut folosind sistemul informatic auditat şi analizează diferenţele;
această tehnică este denumită auditarea evitând 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.
Documentaţia întocmită de auditor, aşa-numitul raport de audit, variază în funcţie 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ă conţină:
a) Diagramele Sistemului Informatic, care descriu activităţile desfăşurate 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 documentaţia standard
a sistemului informatic, prin urmare nu mai trebuie întocmite de auditor; exemplu:
diagrama de vânzări, diagrama de credite, diagrame de încasări etc.;
- diagrame de program: prezintă, în detaliu, logica unui anumit program folosit de
sistemul informatic; auditorii care pot interpreta diagramele de program pot înţelege şi
interpreta controalele conţinute într-o anumită aplicaţie 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.
267
Proiectarea, realizarea şi utilizarea tehnicilor de audit asistate de calculator impun auditorilor, pe
lângă cunoştinţe temeinice din domeniul economic, cunoştinţe suplimentare din domeniul
informatic şi din domeniul de activitate al organismelor economice de auditat.
8.1.2 Etapele auditării
Că auditul sistemelor informaţionale îşi are rădăcinile în auditul contabil o dovedeşte şi figura 8.1
(Gallegos et al., 1987), prin care prezentăm etapele unei astfel de misiuni.
Planificarea auditului
Definirea structurii
controlului intern
Evaluarea riscurilor
controlului
Testarea controalelor
Reevaluarea riscurilor
Teste independente
Elaborarea raportului
de audit
Fig. 8.1 Etapele auditării
Dependența de controale?
Dependența de controale?
Limitarea testelor
independente
268
În etapa de planificare, auditorul extern trebuie să investigheze situaţia clientului său
pentru a decide dacă acceptă sau nu un astfel de angajament. El se va axa în principal pe
dimensiunea erorilor din raportările financiare, erori ce pot afecta capacitatea de decizie a
utilizatorilor unor astfel de informaţii.
Pentru auditorul intern, această etapă presupune înţelegerea obiectivelor misiunii sale şi
identificarea preliminară a zonelor cu riscuri potenţiale. El va avea în vedere mai ales pierderile
apărute sau care pot să apară ca urmare a utilizării 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 auditării. Probabil cea mai dificilă sarcină a auditorului o reprezintă
evaluarea riscurilor controlului. Standardele AICPA44 şiIFAC45 precizează că înainte de a
decide cât de riscante sânt controalele din cadrul unui sistem, auditorul trebuie să înţeleagă
controalele interne folosite în organizaţie.
Înţelegerea structurii controlului intern de către auditor presupune examinarea atât a
controalelor generale/manageriale, cât şi a controalelor de la nivelul aplicaţiilor sistemului
informaţional. In acest punct lucrurile nu mai pot fi generalizate, deoarece controalele generale,
de exemplu, diferă de la o firmă la alta în funcţie de dimensiunea şi organizarea sistemului
informaţional.
O firmă poate avea o organizare centralizată a sistemului informaţional, ceea ce
înseamnă că toate procesările se realizează în cadrul compartimentului de specialitate. In alte
firme se întâlneşte o organizare descentralizată, procesarea datelor fiind distribuită în întreaga
organizaţie.
Controalele aplicaţiilor pot fi de asemenea diverse, în funcţie de complexitatea afacerii:
aplicaţiile folosite de o firmă ce face comerţ nu vor avea aceeași complexitate ca una care face
producţie, de exemplu.
După ce a înţeles pe deplin controalele interne, auditorul trebuie să determine riscul fiecărui
control în parte :
• dacă riscul controlului este evaluat la un nivel mai mic decât nivelul maxim, auditorul
trebuie să testeze controalele care operează în mod eficient. Se porneşte de la ipoteza că,
269
în cazul în care testele indică o funcţionare 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 eficienţei acestora. Abordarea
diferă însă de la o categorie de specialişti la alta. Dacă, de exemplu, auditorul intern stabileşte
că anumite controale nu sânt eficiente, va căuta să înţeleagă cât mai bine natura şi implicaţiile
punctelor slabe pe care le-a identificat. Obiectivul său va fi să înlăture acele puncte slabe.
Auditorul extern tinde să-şi reducă însă investigaţiile într-o astfel de situaţie şi să-şi
asume responsabilitatea testărilor independente, prin prisma riscului ridicat pe care îl percepe.
In finalul demersului său, auditorul ajunge în etapa exprimării unei opinii cu privire la sistemul
auditat.
Profesioniştii din domeniul contabilităţii nu trebuie să fie mari specialişti în informatică pentru a
putea pune în practică avantajele oferite de tehnologiile informaţionale. Pe de altă parte însă,
aceste tehnologii ridică noi probleme cărora auditorii trebuie să le găsească soluţii.
Schimbările care au avut loc în domeniul tehnologiei informaţionale au modificat abordarea
conceptuală a auditării. Intr-o primă fază, auditorul ignora în esenţă calculatorul, tratîndu-l ca pe
o „cutie neagră", iar auditarea se efectua în jurul acestuia (Weber, 1988).
Dezvoltarea tehnologiilor informaţionale și gradul ridicat de specializare a auditorilor au
trasat două direcţii de utilizare a calculatoarelor:
__ca unealtă a auditorului, contribuind la realizarea auditării propriu-zise ;
__ca sarcină a auditării, acolo unde datele sânt supuse procesării calculatorului şi
rezultatele sânt analizate cu acurateţe şi sigur de către programele calculatorului.
Prima reacţie a auditorilor faţă de calculatoare a fost tratarea acestora similar simplelor
sisteme contabile manuale în care nu interesau decât datele de intrare şi cele de ieşire. în
aceste condiţii, auditorii nu au fost preocupaţi de mecanismele interne prin care se realizau
înregistrările contabile, deoarece le era de ajuns faptul că aveau acces rapid la documente şi
înregistrări (figura 8.2).
270
În plus, traseul auditării de la documentele sursă până la înregistrările făcute de maşină
era uşor de urmat. Chiar dacă auditorii acceptau „intrările" şi producerea „ieşirilor", calculatorul
era considerat o „cutie neagră", auditarea realizându-se „în jurul" său.
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 utilizării calculatorului ca un instrument de auditare, multe
firme au dezvoltat softuri de auditare generalizate. Un astfel de soft îndeplineşte sarcini cum ar
fi: compararea conţinutului a două fişiere, examinarea conţinutului unui fişier, 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 funcţionare ale
calculatorului şi de modul în care se realiza procesarea datelor.
Dezvoltările tehnologice şi implementarea pe scară largă a calculatoarelor în cadrul
organizaţiilor au condus la situaţia actuală:auditorii nu mai pot face abstracţie de realitate. Ei au
fost forţaţi să trateze calculatorul ca pe ţinta auditării şi să auditeze „prin" el şi implicit sistemul
informaţional (figura 8.3).
Fișiere Procesări cu
ajutorul
calculatorului
Date de ieșire
generate de
calculator
Date de
intrare
Date de
Ieșire Selectarea datelor de
intrare
Procesări
manuale
Compararea rezultatelor
re
Fig.8.2 Auditarea în jurul cacalculatorului
271
Această nouă abordare cere auditorului să introducă datele în calculator pentru procesare. El
verifică apoi modul în care sânt procesate datele de către calculator, structura fişierelor, a
bazelor de date. Rezultatele sânt, în final, analizate pentru a se constata dacă utilizatorii şi
conducerea organizaţiei se pot baza pe procesarea şi acurateţea programelor.
Dintre dezvoltările tehnologice care cer această ultimă abordare amintim:
introducerea datelor on-line. În unele sisteme, comenzile clienţilor sunt primite telefonic şi
introduse direct în sistem prin intermediul tastaturii, fără a se mai crea documentele sursă.
Auditorul este obligat să „intre" în sistem pentru a determina gradul de siguranţă şi acurateţe al
procesării şi controlului, deoarece nu mai poate parcurge traseul documente sursă-documente
de ieşire.
reducerea sau chiar eliminarea ieşirilor tipărite. Există cazuri în care ieşirile tipărite nu sânt
disponibile pentru iniţierea tranzacţiilor. Auditorul va fi obligat să intre în sistem pentru a
determina acurateţea procesării şi a conţinutului fişierelor.
actualizarea fişierelor în timp real. Cu această actualizare, tranzacţiile apar imediat ce au loc. O
ieşire tipărită, prezentând conţinutul unor astfel de fişiere şi furnizată auditorului, ar putea să nu
fie corectă. Acest lucru se întâmplă deoarece până când imprimanta ajunge la jumtatea listării
conţinutului unui fişier, datele de la începutul acestuia s-ar putea să fie schimbate. Prin urmare,
auditorul este obligat să intre în sistem pentru a face auditarea.
Fișiere
Procesarea tranzacțiilor de test
sub controlul auditorului
Date de ieșire generate de
sistemul informațional
Tranzacții de
test
Date de
Ieșire
Procesarea tranzacțiilor de test
de către auditor
Compararea rezultatelor
re
Fig.8.3 Auditarea prin calculator
272
În plus faţă de dezvoltările tehnologice care l-au obligat pe auditor să folosească calculatorul în
auditare, unii specialişti s-au decis să auditeze prin sistem din două motive:
pe de o parte, imposibilitatea de a localiza documentele sursă sau ieşirile tipărite din cauza
sistemului de fişiere utilizat;
pe de altă parte, îngrijorarea că ceea ce apare pe ieşirile tipărite s-ar putea să nu fie în
concordanţă cu ceea ce conţin în realitate fişierele. 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 informația și tehnologia
informației sunt cele mai importante valori, necesită astăzi sisteme de comunicație rapide, sigure
și fiabile care să-i asigure confidențialitatea, integritatea și disponibilitatea resurselor
informaționale.
În etapa de “Planificare” a auditului, auditorii trebuie să-și formeze o imagine asupra
semnificației și complexității mediului informatic, a accesibilității datelor în vederea
auditării. Această imagine este definită de caracteristicile:
Structura organizatorică a mediului informatic, ce pune un accent deosebit pe
necesitatea separării funcțiilor incompatibile adresate aceleiași persoane.
Complexitatea și importanța procesării automate a fiecărei aplicații semnificative. O
aplicație informatică poate fi considerată complexă atunci când:
volumul tranzacțiilor este considerat de utilizatorii aplicației ca fiind dificil pentru
identificarea și corectarea erorilor în timpul procesării;
aplicația poate genera automat tranzacții semnificative sau poate furniza intrări către
alte aplicații ;
complexitatea calculelor aritmetice;
tranzacțiile sunt schimbate electronic cu alte organizații, ceea ce implică controale
suplimentare asociate căii de comunicație.
Disponibilitatea datelor. Într-un mediu informatizat, anumite informații 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 /informațiilor.
Utilizarea tehnicilor de audit asistate de calculator pentru o creștere a performanței
procedurilor de audit.
Această analiză a importanței și complexității activităților mediului informatizat are un impact
favorabil în evaluarea riscurilor inerente și de control.
273
Într-un mediu informatizat, amploarea riscurilor ia o altă dimensiune, natura lor fiind influențată
de:
Densitatea informației este mult mai mare decât în sistemele clasice, bazate pe hârtie.
Dischetele, discurile optice și alte suporturi moderne ce sunt utilizate pentru salvarea acestui
volum mare de informații, însumând zeci de mii de pagini de hârtie, pot fi subtilizate mult
mai discret generând astfel fraude sau cel puțin afectând confidențialitatea acestor informații.
Transparența documentelor privind desfășurarea unor operațiuni.
a) Absența documentelor de intrare – datele pot fi introduse în sistem fără a avea la bază
documente justificative – este exemplul tranzacțiilor din sistemele on-line.
b) Lipsa unor “urme” vizibile a tranzacțiilor – Deși în practica prelucrării manuale, orice
tranzacție poate fi urmărită plecând de la documentul primar, apoi în registrele contabile, conturi
– în prelucrarea automată, traseul unei tranzacții poate exista o perioadă limitată , într-un format
electronic.
c) Lipsa unor ieșiri vizibile – anumite tranzacții sau rezultate, în special când acestea
reprezintă detalii, se pot regăsi memorate doar în fișierele aplicației (nu și într-o formă tipărită).
Autorizarea tranzacțiilor. Într-un mediu informatizat se poate include și capacitatea
calculatorului de a iniția și executa automat unele trazacții; altfel spus, este vorba de modul de
proiectare a aplicației informatice care poate avea încorporate anumite autorizări implicite și
funcții de generare automată.
Procesarea uniformă a tranzacțiilor. O aplicație informatică procesează în mod uniform
tranzacții similare, pe baza acelorași instrucțiuni program. În felul acesta, erorile de redactare a
documentelor asociate unei procesări manuale sunt în mod virtual eliminate. În schimb, erorile
de programare pot conduce la procesarea incorectă a tranzacțiilor, astfel încât auditorii își vor
concentra atenția asupra acurateței și consistenței ieșirilor.
Accesul neautorizat la date și fișiere se poate efectua cu o mai mare ușurință, ceea ce
implică un mare potențial de fraudă și eroare.
Remanența suporturilor de memorare a datelor, după ce au fost șterse poate constitui o
cale sigură de a intra în posesia unor informații de valoare.
Agregarea datelor. Noile sisteme de prelucrare automată a datelor, precum sunt cele de
asistare a deciziei, au condus la valorificarea unor informații importante ale entității, generând
prognoze, strategii și tactici de parcurs într-un anumit domeniu. Astfel, informațiile capătă
valențe suplimentare decât cele avute prin păstrarea lor în mai multe locuri, separate unele de
altele.
Evoluția tehnologiei informaționale a cunoscut în ultimii ani un ritm accelerat, dar nu
același lucru se poate spune despre progresele înregistrate în domeniul securității datelor.
274
Integrarea puternică a sistemelor apare ca o consecință a îmbunătățirii formelor de
comunicație și a proliferării rețelelor de calculatoare. Aplicațiile de comerț electronic sunt doar un
exemplu în acest sens, dar se poate afirma ca au deschis și mai mult apetitul “specialiștilor” în
ceea ce privește frauda informațională.
Lipsa urmelor eventualelor atacuri criminale constituie un alt element îngrijorător al
noului mediu de lucru ; în aces sens modificarea datelor, adăugarea sau chiar ștergerea lor au
devenit operații mult mai ușor de realizat, dar în același timp, destul de greu de depistat.
8.2 Analiza riscului auditării sistemelor informatice
În literatura de specialitate există mai multe definiţii ale conceptului de risc, pe care le
prezentăm în continuare. Riscul 6este definit ca fiind ameninţarea că o acţiune sau un eveniment
va afecta în mod nefavorabil abilitatea unei organizaţii de a-şi atinge obiectivele şi de a-şi
executa cu succes strategiile. Definiţia aceasta evidenţiază câţiva factori esenţiali, respectiv
riscul este în mod invariabil o ameninţare, adică ceva ce s-ar putea întâmpla, ameninţarea 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 organizaţiei.
La această definiţie observăm că riscul produce neapărat impact asupra obiectivelor într-un mod
negativ.
Riscul7 este posibilitatea sau şansa ca ceva să se întâmple care va avea efect asupra
obiectivelor firmei. Definiţia aceasta, are în plus faţă de avantajul de a fi o definiţie simplă şi uşor
de înţeles, cuvântul “posibilitate/şansă” care este unul foarte bine ales întrucât şansa poate fi
atât pozitivă cât şi negativă. Din punctul de vedere al unui auditor intern, riscul poate fi
considerat ca fiind pulsul organizaţiei. Această analogie ne permite să afirmăm că auditorii
interni trebuie să se asigure că organizaţia adoptă problematica riscului şi îl gestionează, mai
degrabă decât să tolereze ameninţările şi, drept urmare, să piardă oportunităţile. Considerăm
cu tărie că managementul riscului poate fi şi un proces pozitiv, riscul nu este numai ceea ce
decurge în mod greşit, ci activităţi despre care trebuie să te asiguri că sunt corecte sau că le-ai
înţeles corect.
Ce constituie riscuri pentru o firmă? Mai în glumă, mai în serios, putem spune că o
mulțime de lucruri sau evenimente din viața unei organizații sunt încadrate în categoria riscurilor:
costul de înlocuire a echipamentelor, despăgubirile acordate, primele de asigurare, diminuarea
producției, creșterea costurilor administrative, pierderea unor oportunități sau a credibilității,
reducerea calității produselor sau serviciilor oferite clienților etc.
6 Phil Griffiths – Risk-Based auditing, Gower Publishing Limited, England, 1998, definiţie dată de Economist Intelligence Unit, departament al guvernului britanic 7 Idem
275
Știm că activele unei organizații pot fi tangibile sau intangibile. Să aruncăm o privire
asupra sistemului informațional. Echipamentele și aplicațiile care alcătuiesc acest sistem
reprezintă active tangibile în timp ce datele procesate și informațiile obținute sunt intangibile.
Primul element ce trebuie avut în vedere atunci când discutăm despre riscuri în sistemele
informaționale îl reprezintă mediul acestui sistem, mediu care de fapt nu reprezintă altceva decât o
inventariere a activelor ce se doresc a fi protejate : infrastructura rețelei, sistemul de operare,
aplicațiile, informațiile procesate în sistem, suporți de memorare etc.
Următorul obiectiv pe care auditorul trebuie să îl reprezintă identificarea riscurilor asociate
acestor active, aici putând fi incluse :
__ pierderile financiare;
__ pericole de genul incendiilor, întreruperilor în alimentarea cu energie electrică sau
cataclismelor naturale;
__ frecvența și gravitatea erorilor (umane sau mecanice);
__ furtul sau alterarea aplicațiilor sau a datelor/informațiilor procesate ;
__ probleme cauzate de incompetența 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
276
Faptul că se recurge la calculator în conducerea activității unei întreprinderi constituie un
risc în sine. Acest risc este independent de riscul fizic sau logic.
Riscul fizic cuprinde defectarea calculatoarelor și a unităților periferice, precum și condițiile
nesatisfăcătoare ale mediului în care funcționează. Încă de la începutul dezvoltării informaticii,
progresele cele mai importante au fost obținute în materie de protecție contra riscului fizic.
Riscul logic provine din aplicarea greșită a anumitor proceduri, a unor instrucțiuni greșite sau
erori umane mai mult sau mai puțin intenționate.
Riscul economic este cel legat de utilizarea echipamentelor informatice în viața întreprinderii.
Pentru multe întreprinderi, calculatorul are un rol esențial, și orice anomalie în funcționarea sa
poate să aibă consecințe grave, ducând până la întreruperea parțială sau totală a exploatării
(băncile, companiile de asigurări, societățile de vânzări prin corespondență sunt vulnerabile în
fața defectării sau funcționării neadecvate a echipamentelor).
Managementul, prin activităţile de control prestabilite, identifică riscurile şi prin soluţii
adecvate, în funcţie 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 raportărilor
financiare, ca urmare a neregulilor descoperite pe parcursul desfăşurării auditului.
8.2.1 Riscurile asociate sistemelor informaționale
În general, riscurile asociate unui sistem informațional, 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 detectării.
Orice afirmaţie făcută de auditor trebuie susţinută de probe. Nu întotdeauna însă, testele
utilizate conduc la depistarea erorilor reale sau potenţiale din cadrul sistemului. Astfel, auditorii
se confruntă cu propriul risc: riscul auditării.
AICPA, organizaţie ce grupează auditorii externi de pe noul continent, a elaborat în
1988 un model de calcul al riscului auditării:
RA= RI * RC * RD ,unde:
RI – riscul inerent, RC – riscul controlului, RD – riscul detectării.
Acest model rămâne valabil şi în cazul auditării sistemelor informatice.
Riscurile inerente sunt reprezentate de totalitatea riscurilor care planează asupra organizaţiei
şi pot fi interne sau externe, măsurabile sau nemăsurabile.
De exemplu, RI asociat siguranţei accesului la reţea şi a comunicării datelor în reţea,
poate fi considerat un risc de gravitate mare, atâta timp cât nu există un responsabil desemnat
277
cu monitorizarea implementării procedurilor privind siguranţa accesului utilizatorilor în reţea.
Consecinţele acestei erori se poate propaga în întreaga organizaţie, prin modificarea şi
divulgarea datelor, situaţiilor, se poate schimba poziţia strategică a organizaţiei pe piaţa
tranzacţiilor.
În analiza riscurilor inerente, auditorul trebuie să aibă în vedere următoarele obiective:
Organizarea şi funcţionarea departamentului IT
Pentru îndeplinirea acestui obiectiv sunt desfăşurate activităţile:
- analizarea organigramei departamentului IT;
- analizarea managementului resurselor umane la nivelul departamentului IT;
- analizarea planurilor de pregătire profesională continuă;
- verificarea existenţei unui sistem de evaluare a cunoştinţelor dobândite după
efectuarea cursurilor;
- analizarea realizării pregătirii profesionale a salariaţilor conform atribuţiilor şi
responsabilităţilor stabilite prin fişa postului;
- analizarea sistemului de evaluare a riscului;
- verificarea existenţei şi actualizării Registrului riscurilor.
Implementarea sistemelor informatice
Activităţile sunt:
- verificarea realizării la termenele stabilite a subsistemelor informatice;
- analizarea activităţii de monitorizare a implementării subsistemelor informatice;
- evaluarea controlului datelor introduse în aplicaţie;
- evaluarea controlului pe parcursul procesării datelor;
- evaluarea controlului datelor rezultate în urma procesării;
- analizarea validităţii datelor transferate din alte aplicaţii;
- evaluarea controalelor care verifică înregistrările duble;
- verificarea autorizării electronice şi/sau manuale a tranzacţiilor;
- analizarea efectuării tranzacţiilor numai de la PC-uri definite în prealabil;
- verificarea situaţiei licenţelor pentru programele de calculator;
- asigurarea integrării subsistemelor componente;
- verificarea elaborării manualelor de utilizare şi a manualelor de operare;
- verificarea existenţei şi respectării programului de instruire a utilizatorilor
sistemelor informatice.
Securitatea sistemelor informatice
Activităţi:
278
- verificarea existenţei unei politici de securitate a sistemelor informatice;
- verificarea actualizării 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 dotării
camerelor în care se află servere-le cu echipamente adecvate);
- verificarea siguranţei accesului la reţea şi a comunicării datelor în reţea;
- verificarea implementării programelor anti-virus conform procedurilor;
- monitorizarea sistematică a funcţionalităţii programelor anti-virus;
- verificarea sistemului de actualizare a programelor anti-virus;
- verificarea elaborării planului de recuperare a datelor în caz de dezastru;
- verificarea desemnării responsabililor cu monitorizarea implementării procedurilor
privind recuperarea datelor în caz de dezastru;
- verificarea efectuării monitorizării sistematice.
Riscul controlului este strâns legat de mediul de control şi de activităţile de control
implementate şi reprezintă riscul ca o eroare ce nu poate fi prevenită sau corectată de către
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 informaţii înmagazinate.
Riscul detecţiei reprezintă riscul ca un test independent efectuat de auditor să nu detecteze o
eroare care există în zona supusă auditării.
De exemplu, riscul detecţiei asociat identificării funcţionalităţii programelor anti-virus, va fi
mare în cazul reţelelor mari de calculatoare, deoarece testarea se realizează pe un eşantion
care reprezintă un anumit procent din totalul de calculatoare.
279
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 discuție legată de riscuri, trebuie să facem o mențiune:
din punct de vedere practic este imposibil să cuantificăm corect pierderile cauzate de un anume
eșec. Putem face o estimare pe baza pierderilor din trecut și a experienței (proprii sau a altora),
dar nu putem face predicții cu caracter absolut..
Putem prezice posibilitatea de apariție a unui efect negativ sau probabilitatea sa de
apariție, dar nu putem afirma cu certitudine că acest lucru se va și întâmpla.
În calitate de auditori de sisteme informaționale, examinăm controalele existente în
cadrul unei organizații și, chiar dacă ne consultăm cu alți specialiști sau ne exprimăm propriile
opinii, căutăm să perfecționăm controalele analizate. Aceste consultări sau sugestii pe care le
facem trebuie să permită organizației să controleze mult mai eficient pierderile potențiale și să-și
poată conserva resursele de care dispune.
Activitatea de analiză a riscurilor se desfăşoară în următoarele etape:
a) Identificarea elementelor/obiectelor auditabile. În cazul sistemelor informatice se face o
inventariere a activităţilor ce se doresc a fi protejate: infrastructura reţelei, sistemul de
operare, aplicaţiile, informaţiile procesate în sistem, suporţii de memorare.
b) Stabilirea riscurilor pentru fiecare obiect auditabil pe baza analizei operaţiilor în funcţie
de anumite criterii concepute anticipat. Aici pot fi incluse: frecvenţa şi gravitatea
erorilor(fizice sau logice), pierderile financiare, pericole de genul incendiilor, întreruperi
în alimentarea cu energie electrică, cataclisme naturale, furtul sau alterarea aplicaţilor
sau a datelor/informaţilor procesate, probleme cauzate de incompetenţă profesională
sau managerială.
c) Măsurarea riscurilor care se face în funcţie de probabilitatea de apariţiei 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 cărora 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 experienţa
auditorului, modelele cantitative fac apel la formule matematice, încercând să introducă
mai multă rigoare în acest domeniu.
Cel mai utilizat model pentru măsurarea riscurilor este modelul factorilor de risc, care stabileşte,
în funcţie de importanţa şi greutatea factorilor de risc, ponderile şi nivelurile de apreciere ale
riscurilor.
280
Factori de risc
(Fi)
Ponderea
Factorilor de
risc
(Pi)
Nivelul de apreciere al riscului(Ni)
N1 N2 N3
Aprecierea
Controlului
Intern
F1
P1 – 50%
Există proceduri
şi se aplică
Există proceduri,
sun cunoscute,
dar nu se aplică
Nu există
proceduri
Aprecierea
cantitativă
F2
P2 – 30% Impact financiar
scăzut
Impact financiar
mediu
Impact financiar
ridicat
Aprecierea
calitativă
F3
P3 – 20%
Vulnerabilitate
mică
Vulnerabilitate
medie
Vulnerabilitate
mare
Tabel 8.1
Cei trei factori de risc sunt stabiliţi prin normele generale şi sunt acoperitori pentru domeniul
studiat, însă pot fi luaţi în calcul şi alţi factori de risc, cu nivel de apreciere corespunzător, 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
Existenţa controalelor generale la
subsistemele informatice
2 Mediu
Funcţionalitatea subsistemelor în reţea
1,5 Mic
Situaţia licenţelor 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.
281
- metode de clasificare relative - riscurile sunt clasificate utilizând o scară de valori
determinată în prealabil, spre exemplu: scăzut, mediu, ridicat.
- metode de clasificare matriceale - riscurile sunt clasificate în funcţie de diverse
combinaţii 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 activităţile de control şi constatările 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.
Existenţa controalelor
generale la
subsistemele informatice
Implicaţiile evoluţiilor
tehnologice în domeniul IT
Scăzut
Funcţionalitatea
subsistemelor în reţea
Modificarea cadrului legal şi
procedural ce reglementează
activităţile pentru care se
realizează subsistemele
informatice
Scăzut
Situaţia licenţelor pentru
programele
de calculator
Limitări bugetare pt. achiziţii
licenţe
Scăzut
Disfuncţionalităţi în procesul de
achiziţii
Mediu
Instruirea utilizatorilor Inexistenţa unui program de
instruire al utilizatorilor
Ridicat Nu
Neefectuarea instruirii
sistematice a utilizatorilor
sistemelor informatice
Mediu
Tabel 8.3
f) ierarhizarea riscurilor constă în evaluarea funcţionalităţii 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 nefuncţionale vor fi considerate „puncte slabe”. Pe baza acestora, se va întocmi
282
documentul: „Tematica în detaliu a misiunii de audit” în care vor fi preluate numai operaţiile
considerate a fi puncte slabe.
Odată identificate, riscurile trebuie evaluate atât din punct de vedere al probabilității de
apariție cât și al gravității 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 probabilității de apariție a riscurilor.
Problema aceasta are o mulțime de soluții. Una dintre acestea este matricea riscurilor (fig. 8.5)
Pentru construirea matricei se consideră o probabilitatea apariției cu două variabile:
- Frecvența/probabilitatea - stabilește într-un interval de timp stabilit;
- Impactul/gravitatea efectelor – măsoară impactul financiar al riscului.
Fig. 8.5 Matricea riscurilor
Dacă un anumit eveniment sau o anumită activitate din viața unei organizații 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 cât oportunitatea este mai mare, cu
mare
medie
mică
scăzut moderat ridicattt
Impact
Probabilitate
0
283
atât este mai mare și riscul, iar probabilitatea de apariție este destul de redusă. De aici se poate
trage concluzia că și reciproca acestei afirmații este valabilă.
Cât de mare poate fi efectul negativ pe care o organizație îi poate suporta? Acest lucru depinde
de puterea financiară a firmei. Dacă efectele exprimate monetar sânt mai mari decât 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 organizație se poate
aștepta la apariția unor pierderi cauzate de ineficiența unui sistem informatic, iar acest risc al
pierderilor, rezultă din impactul pe care îl au amenințările asupra resurselor organizației.
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,
încercând 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 același timp informații pentru
a le determina și controla.
Specialistul Alan Oliphant propune un model calitativ de determinare a nivelului de risc,
conform căruia sunt luați în calcul 4 factori de bază în aprecierea valorii riscului: impactul
financiar, vulnerabilitatea, complexitatea și încrederea (model reprezentat în figura 8.6).
Fig. 8.6 Factorii pentru aprecierea riscului9
9 Modelul prezentat este descris in articolul „Modeling information risk elements” („www.theiia.org/itaudit”)
Risc Complexita
te
Complexitatea sistemului
Complexitatea organizației
Riscul tehnologiei
Impact financiar
Vulnerabilitate
Nivel de încredere
Număr utilizatori
Accesibili-tate
284
În acest caz, valoarea riscului va fi exprimată prin valorile “Foarte Scăzut, Scăzut, Mediu, Înalt,
Foarte Înalt” și nu în valori absolute ; formula de determinare a valorii riscului este următoarea :
VR= VF * [( Cv*Wv )+( Cc*Wc )+( Ct*Wt )
unde:
VR - valoarea de risc
VF - impactul financiar asupra organizației; acesta reprezintă un cost potențial al
organizației în eventualitatea apariției unei erori, căderi de sistem, fraude sau alte evenimente
negative. Valoarea materială va fi dată de valoarea financiară sau valoarea activelor. Impactul
asupra organizației 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 autorizați au acces
în sistem și pe de altă parte la accesibilitatea sistemului și a activelor organizației de către
utilizatori neautorizați. Accesibilitatea unui sistem informațional se poate evalua în funcție de
restricțiile fizice implementate în cadrul organizației și de modalitățile de acces prin intermediul
rețelei de comunicatie.
Cc - complexitatea - are în vedere riscul asociat tehnologiei informaționale în sine, numărul
utilizatorilor din cadrul compartimentelor sau în termeni mai generici complexitatea
organizațională.
Ci - încrederea, reflectă comportamentul uman din organizație și vizează două aspecte:
integritatea personalului și gradul de implicare al managerilor.
Wv, Wc, Wi - reprezintă factori de greutate (importanța) care pot fi aplicați la discreția
auditorului, în funcție de condițiile specifice. Inițial, acești factori pot fi stabiliți la o valoare de
0.33 în vederea determinării unui multiplicator mediu general al riscului ; această valoare nu
este fixă și atunci când se consideră ca unul dintre elemente are un impact mai mare decât
celelalte, se pot folosi valori diferite.
Valoarea de risc calculată va fi transpusă într-un „tabel de traducere”, indicându-se nivelul de
risc; în proiectarea acestui tabel, auditorii au în vedere următoarele reguli: valoarea cea mai
scăzută de risc = 0 și valoarea cea mai ridicată se apreciază ca fiind valoarea totală (financiară)
a organizației multiplicată cu 3.
Impactul financiar reprezintă o estimare a valorii monetare pe care organizația o poate pierde
în eventualitatea apariției unui eveniment negativ. În cazul nostru, această valoare se referă la
285
activele tangibile și intangibile din cadrul sistemului informațional: echipamente,
procesări,aplicații, date.
Vulnerabilitatea se referă, pe de o parte, la modul în care utilizatorii autorizați au acces în
sistem și, pe de altă parte, la accesibilitatea sistemului și a activelor informaționale de către
utilizatorii ne autorizați.
Accesibilitatea unui sistem informațional se va evalua în funcție de Restricțiile fizice
implementate în interiorul organizației și de modalitățile de acces prin intermediul rețelei de
comunicație.
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 Stațiile de lucru și celelalte resurse informaționale sunt
accesibile
tuturor persoanelor care au acces în sediul organizației.
Mediu Resursele informaționale sunt localizate în birouri în care, în
mod
normal, persoanele din afara organizației nu au acces
Scăzut Resursele informaționale sunt localizate în zone în care nici o
persoană autorizată nu are acces
Tabel 8.4
Din punctul de vedere al accesului la rețeaua de comunicații, riscurile pot fi prezentate ca în
tabelul următor:
286
Riscurile asociate rețelei
Nivelul
riscului Descriere
Mare Conexiuni la rețeaua publică : orice tip de rețea publică de
comunicații la care sistemul organizației este conectat. Se
includ : rețeaua telefonică, conexiunile internet
Mediu Conexiuni private : orice conexiuni la o altă rețea în afară de cea
gestionată de către organizație, cu acces restricționat sau prin
folosirea unor linii dedicate/închiriate.
Scăzut Nici o conexiune, nici măcar linie telefonică.
Tabel 8.5
Riscul asociat accesibilității generale a sistemului este dat de combinarea celor două tipuri de
acces sub forma unei matrice de control ca în tabelul Următor:
Matrice de control
Acces fizic Acces rețea
Mare Mediu Scăzut
Mare Mare Mare Mediu
Mediu Mare Mediu Scăzut
Scăzut Mediu Scăzut Scăzut
Tabel 8.6
Numărul utilizatorilor autorizați împreună cu riscul asociat accesibilității sistemului contribuie la
identificarea nivelului de vulnerabilitate a acestuia :
Nivelul de vulnerabilitate
Număr utilizatori autorizați Riscul accesibilității
Mare Mediu Scăzut
Mare (majoritatea
utilizatorilor sunt autorizați)
Mare Mare Mediu
Mediu (50%) Mare Mediu Scăzut
Scăzut(număr limitat) Mediu Scăzut Scăzut
Tabel 8.7
287
Complexitatea sistemului are în vedere riscul asociat tehnologiei informaționale în sine,
numărul utilizatorilor din cadrul compartimentelor,departamentelor, precum și modulele prin
intermediul cărora se realizează procesarea datelor. Riscul asociat tehnologiei informaționale
implică, în principal, dependența crescută de profesioniștii domeniului și tehnologia în sine.
Dependența de specialiști se poate evalua în funcție de Angajați din
compartimentul/departamentul de specialitate și de riscul asociat documentației sistemului.
Auditorul trebuie să aibă în vedere și măsura în care organizația apelează la specialiști/firme din
afara acesteia.
Riscul asociat angajaților din compartimentul de specialitate
Nivelul
riscului Descriere
Mare Există o singură persoană (angajat sau consultant
independent)
ce se ocupă de funcționarea întregului sistem.
Mediu Există 2-3 persoane care asigură funcționarea și întreținerea
sistemului.
Scăzut Există mai mult de 3 persoane implicate în funcționarea
sistemului.
Tabel 8.8
Riscul documentației
Nivelul
riscului Descriere
Mare Nu există nici un fel de documentație
Mediu Documentația există, dar nu reflectă în totalitate
Realitățile din sistem
Scăzut Există documentație actualizată și disponibilă în orice
moment.
Tabel 8.9
Combinând cele două tipuri de riscuri vom obține o matrice a riscului asociat dependenței de
specialiști :
288
Matrice de control
Dependența de
specialiști
Nivelul documentației
Mare Mediu Scăzut
Mare Mare Mare Mediu
Mediu Mare Mediu Scăzut
Scăzut Mediu Scăzut Scăzut
Tabel 8.10
Pentru a putea evalua riscul asociat tehnologiei, acesta trebuie cumulat cu dependența de
specialiști, deoarece când vorbim despre tehnologie avem de fapt în vedere timpul necesar
punerii în funcțiune 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 puțin 20 de ani.
Mediu Sistemul are o durată de viață mai mare de 4 ani
Scăzut 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ă
dependența de specialiști și tehnologia în sine :
Riscul tehnologic
Riscul asociat
tehnologiei
Dependența de specialiști
Mare Mediu Scăzut
Mare Mare Mare Mediu
Mediu Mare Mediu Scăzut
Scăzut Mediu Scăzut Scăzut
Tabel 8.12
289
La rândul său, complexitatea organizațională se referă la numărul de utilizatori ai componentelor
sistemului informațional :
Riscul complexității organizaționale
Nivelul
riscului Descriere
Mare Erorile din sistem afectează întreaga organizație.
Mediu Erorile din sistem afectează activitatea din anumite
compartimente/departamente
Scăzut 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: numărul
funcțiilor pe care acesta le realizează :
Riscul asociat funcțiilor
Nivelul
riscului Descriere
Mare Funcții multiple și care interacționează unele cu altele.
Mediu Funcții multiple care acționează independent.
Scăzut Sistemul realizează o singură funcție.
Tabel 8.14
Combinând complexitatea organizațională și cea privind sistemul proiectat, se va obține o nouă
matrice de control, După cum urmează :
Matrice de control
Complexitatea
organizațională
Complexitatea sistemului
Mare Mediu Scăzut
Mare Mare Mare Mediu
Mediu Mare Mediu Scăzut
Scăzut Mediu Scăzut Scăzut
Tabel 8.15
290
În ceea ce privește complexitatea sistemului, aceasta va fi evaluată în funcție de riscul asociat
tehnologiei informaționale și de complexitatea organizațională și a proiectului:
Complexitatea organizațională
Complexitatea
organizațională și a
proiectului
Riscul asociat tehnologiei informaționale
Mare Mediu Scăzut
Mare Mare Mare Mediu
Mediu Mare Mediu Scăzut
Scăzut Mediu Scăzut Scăzut
Tabel 8.16
Factorul încredere a fost introdus în acest model calitativ pentru a reflecta comportamentul
uman din organizația studiată. Scopul său este de a cuantifica riscul atribuit, pe de o parte,
nivelului de încredere ce poate fi asociat angajaților din compartimentul de specialitate și, pe de
altă parte, nivelului de încredere al managerilor în sistemul supus verificării.
Încrederea vizează două aspecte : controlul angajaților și gradul de implicare al managerilor.
Controlarea angajaților 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
Scăzut Înainte de a fi angajată, orice persoană este temeinic
verificată.
Tabel 8.17
Șefii de compartimente/departamente sânt cei mai în măsură să evalueze riscul activelor
informaționale 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 preocupați să asigure securitatea
sistemului, dar nu există nici un fel de analize.
Scăzut Managerii sunt implicați în mod activ și constant în asigurarea
securității activelor ca urmare a evenimentelor din trecut.
Tabel 8.18
291
Acești doi factori pot fi la rândul lor combinați:
Matrice de control
Controlul
angajaților
Implicarea managerilor
Mare Mediu Scăzut
Mare Mare Mare Mediu
Mediu Mare Mediu Scăzut
Scăzut Mediu Scăzut Scăzut
Tabel 8.19
Auditorul își va putea forma o opinie cu privire la riscul sistemului informațional combinând toate
aspectele prezentate până în acest moment.
Cum acest model nu introduce nici o valoare financiară asociată riscului,evaluările făcute 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 recomandărilor auditorului în ceea ce
privește securitatea sistemului verificat. și, în lipsa unei aplicații care să conțină aceste
specificații, 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ă așteptată;
costul controlului și mșsurilor de precauție
incertitudinea.
Impactul generat de o singură amenințare sau pierderea potențială asociată unei singure apariții
se calculează astfel:
Impact=FV * VA
Sau
PPA = FV * VA
Pierderea anuală anticipată este influențată de rata anuală a apariției riscului și poate fi
determinată astfel:
292
PAA = PPA * RAA
unde: FV – factor de vulnerabilitate
VA – valoarea activului
PPA – pierderea potențială asociată unei apariții
PAA – pierdearea anuală anticipată
RAA - rata anuală a apariției
O astfel de analiză include de asemenea o evaluare a raportului cost/beneficii ce va facilita
proiectarea ratei de recuperare a investițiilor (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 prelucrărilor realizate în
interiorul său şi a distribuirii acestora numai către utilizatorii autorizaţi, în cazul în care distribuirea se
face automat folosind sisteme de calcul.
Pentru efectuarea controlului intern într-un sistem informatic se folosesc măsuri, metode şi
tehnici de verificare a corectitudinii rezultatelor prelucrărilor realizate în interiorul său, 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ă importanţa controlului
intern realizat în vederea asigurării corectitudinii rezultatelor prelucrărilor efectuate în interiorul
acestuia. Apariţia şi utilizarea sistemelor informatice determină însă folosirea unor măsuri şi metode
de control specifice, care se adaugă metodelor tradiţionale de auditare a sistemelor manuale şi/sau
mecanice de prelucrare a datelor, deoarece posibilitatea de folosire a unui singur calculator pentru
efectuarea tuturor operaţiunilor corelate din cadrul unui organism economic impune utilizarea unor
controale specifice pentru asigurarea protecţiei datelor la pierderi sau alterări şi pentru depistarea
prelucrărilor eronate, efectuate în interiorul calculatorului.
Exemplu: realizarea ștatului de salarii folosind calculatorul face posibilă rezolvarea tuturor
problemelor legate de evidenţa personalului prin adăugarea datelor de evidenţă respective la
293
înregistrarea aferentă fiecărui angajat; în acest caz, fişierul de personal cuprinde nu numai datele
necesare realizării ștatului de salarii (salariul de încadrare, vechimea în muncă, sporuri, obligaţii către
bugetul asigurărilor sociale de stat - CAS, şomaj, sănătate, impozit etc.), ci şi date legate de pontaj
(prezenţă, concedii de odihnă, concedii medicale), de distribuţia costurilor salariale pe
compartimente, de studii, de locul de muncă şi funcţia ocupată etc.; pentru protecţia datelor de
salarizare şi evidenţă personal împotriva pierderilor voite sau accidentale şi/sau modificărilor
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 aplicaţie.
8.3.1 Controale generale
Controalele generale sunt măsuri de protecţie a echipamentelor, datelor şi programelor care
privesc toate componentele unui sistem informatic (hardware şi software) şi pot fi de următoarele
tipuri:
- controale organizatorice: măsuri organizatorice folosite pentru protecţia la fraude, neatenţie
şi/sau neglijenţă;
- controlul dezvoltării și întreținerii sistemului, în conformitate cu cerinţele utilizatorului,
specificate în proiectul de execuţie;
- controale hardware (controale de echipament): măsuri de protecţie la defecţiunile tehnice;
- controale de siguranţă (echipamente şi fişiere): măsuri de protecţie la pierdere, distrugere sau
alterare, la accesul neautorizat sau la calamităţi (apă, foc etc.).
Fig. 8.7 Controale generale
Controale organizaționale
Controale generale
Controale hardware
Controlul dezvoltării și întreținerii
Controlul securității sistemului
294
A.Controale organizatorice în sistemul informatic
Controalele organizatorice sunt metode şi tehnici de organizare a activităţilor desfăşurate de
organismele economice, folosite pentru prevenirea pierderilor şi/sau alterărilor de date determinate
de fraudă, neatenţie şi/sau neglijenţă, în vederea asigurării unui control intern eficient în sistemele de
prelucrare a datelor utilizate de acestea. Principalele tipuri de controale organizatorice sunt:
definirea clară a funcţiilor, urmată de definirea şi separarea clară a sarcinilor angajaţilor
pentru fiecare funcţie;
rotaţia angajaţilor pe funcţii şi vacanţe obligatorii;
selecţia angajaţilor care au acces la echipamentele şi programele sistemului informatic şi
acordarea unui spor de fidelitate.
Definirea clară a funcţiilor, urmată de definirea şi separarea clară a sarcinilor şi
responsabilităţilor (răspunderilor) angajaţilor pentru fiecare funcţie, joacă rolul-cheie în asigurarea
controlului oricărui 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 prelucrărilor. 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 răspunderea completă pentru
efectuarea unei activităţi; operaţia executată de o persoană trebuie verificată de o altă persoană, care
îndeplineşte o altă sarcină, vizavi de activitatea respectivă. Separarea sarcinilor între angajaţi diferiţi
asigură corectitudinea înregistrărilor de date (pe hârtie sau suport magnetic) şi a rapoartelor,
protejând totodată organismul economic respectiv împotriva pierderilor de date determinate de fraude
sau neglijenţe.
Schimbările produse de utilizarea unui sistem automat de prelucrare a datelor în organizarea
activităţilor desfăşurate de un organism economic trebuie să urmărească atât folosirea eficientă a
echipamentelor şi programelor componente ale sistemului informatic, cât ş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 activităţilor şi integrarea funcţiilor dintr-un domeniu de activitate, deoarece
un singur calculator poate executa, cu uşurinţă, toate operaţiile corelate din cadrul unui organism
economic. Acest lucru este posibil, fără slăbirea controlului intern, pentru că un calculator programat
corect nu are posibilitatea sau interesul să ascundă erorile şi de aceea poate efectua orice
combinaţie de funcţii considerată incompatibilă de un control intern puternic într-un sistem tradiţional
de prelucrare a datelor (manual sau mecanic).
295
Ţinând cont şi de faptul că într-un calculator programele şi datele se pot modifica fără a putea
fi observat acest lucru, se impune folosirea unor controale organizatorice compensatoare pentru
asigurarea siguranţei programelor şi a datelor în vederea obţinerii unor rezultate corecte ale
prelucrărilor efectuate în interiorul sistemului informatic.
De exemplu, într-un sistem manual de prelucrare a datelor, funcţia de înregistrare a plăţilor,
în numerar, este incompatibilă cu funcţia de verificare a extraselor de cont, deoarece cea de-a doua
serveşte ca metodă de verificare pentru prima, atribuirea ambelor sarcini aceluiaşi funcţionar
permiţând acestuia să ascundă erorile. Dacă cele două funcţii, de înregistrare a plăţilor ş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 încât să
fie înregistrată o plată fără bază reală, motiv pentru care acesta nu trebuie să îndeplinească şi
funcţia de înregistrare a plăţilor.
Pentru folosirea eficientă a fiecărui calculator din dotare, organismele economice combină şi
concentrează funcţiile 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ă funcţiile 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, fără a
se observa modificarea lor.
Planul de organizare al departamentului informatic trebuie astfel conceput încât să prevină
intervenţia 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 funcţiilor în departament şi prin definirea şi
separarea clară a sarcinilor angajaţilor pentru fiecare funcţie.
De exemplu, un program ut ilizat să facă plăţi 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 recepţie. Dar un angajat care are dreptul să facă modificări în programul de
aplicaţie poate efectua plaţi, fără bază reală, către anumiţi furnizori, dacă planul de organizare al
departamentului informatic respectiv îi permite să facă şi plăţi.
Structura organizatorică a fiecărui organism economic şi numărul angajaţilor de specialitate
disponibili determină gradul de separare a sarcinilor legate de proiectarea şi/sau realizarea şi
exploatarea unui sistem informatic. Ca un minim necesar, funcţia de programator, care necesită
296
cunoştinţe detaliate despre programul de aplicaţie folosit, trebuie separată de funcţia de operator,
care deţine controlul intrărilor în programul respectiv.
Dacă structura organizatorică a unui organism economic, care foloseşte pentru evidenţa şi
controlul activităţilor sale un sistem informatic, permite unui angajat să realizeze atât sarcini de
programator, cât şi de operator, se slăbeşte controlul intern, existând permanent posibilitatea de
fraudă.
Separarea activităţii de exploatare de cea de programare este foarte importantă din punct de
vedere al asigurării unui control intern eficient, deoarece un angajat care realizează ambele funcţii
poate face schimbări neautorizate în programul sistemului informatic, producând fraude. Istoria
fraudelor computerizate arată că, de cele mai multe ori, persoanele implicate au intervenit în sistemul
informatic, ca programator şi operator, controlând folosirea lui.
De exemplu, dacă programatorul care a scris programul de identificare şi listare a tuturor
conturilor clienţilor ce extrag sume de bani mai mari decât limitele admise are acces la sistemul
informatic al băncii ca operator, el poate modifica programul astfel încât depăşirea limitei de extragere
admisă să fie ignorată, în cazul propriului său cont.
Programatorul operator poate astfel extrage sume de bani din contul său, fără ca sistemul informatic
utilizat să semnaleze administratorului acest lucru. Frauda nu poate fi descoperită până când
programul nu este revizuit de un alt programator sau până când calculatorul nu se defectează şi lista
conturilor cu depăşiri de limită trebuie pregătită manual.
Dacă structura organizatorică a unui organism economic permite accesul personalului de
exploatare a sistemului informatic la activele organismului economic respectiv, se slăbeşte, în mod
serios, controlul intern, în cazul în care nu sunt implementate măsuri de control (controale
organizaţionale) compensatorii. De exemplu, dacă acelaşi angajat ţine atât evidenţa activelor unui
organism economic folosind un sistem informatic, cât şi păstrarea (gestiunea) fizică a acestora, prin
combinarea responsabilităţilor corespunzătoare 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 evidenţa computerizată
a activelor trebuie să limiteze, pe cât posibil, accesul personalului de exploatare la activele respective.
Totuşi, personalul de exploatare al unui sistem informatic poate avea:
- acces direct la active; exemplu: dacă sistemul informatic este folosit pentru tipărirea
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 mărfii (acces direct la marfa de livrare).
297
Ca măsură de control compensatorie se pot folosi documente şi totaluri pe loturi, lista cu
numărul de documente şi totalul datelor semnificative pentru fiecare lot fiind pregătite în două
departamente diferite ale organismului economic respectiv, pentru compararea rezultatelor.
De exemplu, departamentul care autorizează tipărirea cecurilor trebuie să întocmească o listă cu
numărul total de cecuri şi suma autorizată pentru fiecare, tipărirea acestora făcându-se în alt
departament care, la rândul lui, întocmeşte o listă cu numărul de cecuri tipărite şi suma aferentă
fiecăruia.
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 decât în
alte cazuri.
Rotaţia, pe funcţii, a angajaţilor care au legătură cu sistemul informatic implementat de un
organism economic se face cu scopul de a evita schimbările neobservabile de date şi programe
efectuate în calculator, fie din interes (fraudă), fie din neatenţie sau neglijenţă.
Planul de organizare al unui departament de informatică trebuie să includă un mecanism de
rotaţie a sarcinilor şi vacanţe obligatorii pentru angajaţii săi, pentru că schimbarea programatorilor sau
operatorilor (între ei) facilitează descoperirea modificărilor accidentale sau neautorizate de date şi
programe.
Rotirea, pe funcţii, a angajaţilor care se ocupă cu prelucrarea şi evidenţa 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 corespunzându-le în sistemele tradiţionale
documentele scrise.
Selecţia angajaţilor 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 cât posibil, posibilităţile de fraudă şi producerea erorilor din lipsa
cunoştinţelor profesionale, din neatenţie sau neglijenţă; personalul de întreţinere şi exploatare trebuie
ales cu grijă, pentru a reduce posibilitatea de distrugere intenţionată produsă de un angajat
nemulţumit.
Principalele criterii de selecţie a personalului care are legătură cu sistemul informatic sunt:
298
- nivelul de pregătire profesională dovedit prin: diplome de studii, pregătire teoretică şi
îndemânare practică, experienţă dobândită în timp (vechime în domeniu), calificative
obţinute la locurile de muncă anterioare etc.;
- moralitate şi seriozitate demonstrate prin: cazier judiciar, înscrisurile din documentele de
angajare (frecvenţa şi motivele de schimbare a locurilor de muncă), recomandări de la
locurile de muncă anterioare şi/sau de la alţi specialişti în domeniu (profesori, colegi,
cunoştinţe) etc.;
- fidelitatea faţă de organismul economic la care lucrează.
Selecţia atentă a personalului care se ocupă cu prelucrarea şi evidenţa 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 fără departament de informatică,
trebuie să includă un spor de fidelitate pentru angajaţii săi care lucrează în domeniul informatic pentru
a evita fraudele computerizate, greu de depistat şi foarte periculoase pentru evoluţia organismului
economic respectiv.
Concluzie. Controalele organizaţionale joacă rolul-cheie în asigurarea unui control intern
puternic în cadrul unui sistem informatic, în vederea prevenirii fraudelor, care au implicaţii majore
asupra evoluţiei oricărui 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 alţi angajaţi în vederea comiterii unei
fraude, controalele organizaţionale interne care se bazează pe separarea sarcinilor şi rotirea
angajaţilor pe funcţii devin inoperante.
De exemplu, dacă persoane de conducere şi angajaţi ai unui organism economic fac tranzacţii fictive
şi întocmesc documente false care susţin aceste activităţi, 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 întreținere a sistemelor informatice
Mutaţiile din domeniul tehnologiilor informaţionale şi al metodelor de abordare a
sistemelor s-au reflectat şi în ciclul de viaţă al dezvoltării sistemelor, fie prin schimbările
etapelor acestuia, fie prin modificarea ordinii de parcurgere a lor. Indiferent de numele şi de
numărul etapelor ciclului de viaţă al dezvoltării sistemelor, o problemă mult mai importantă este
299
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 viaţa a sistemului informatic”.
Modelul cascadă este unul de referinţă asigurând trecerea de la o etapă la alta în ordinea
secvenţială a posibilităţii revenirii la etapele anterioare sau parcurgerii în paralel a mai multor
etape.
Figura 8.8 redă activităţile parcurse pentru obţinerea unui sistem informatic.
1.Definirea cerinţelor
În cadrul acestei etape se identifică problemele care trebuie soluţionate şi se
elaborează planul proiectului de dezvoltare a viitorului sistem informatic.
La început, se realizează un studiu complex privind activităţile, fluxurile informaţionale
existente, volumul informaţiilor prelucrate şi aria de cuprindere a sistemului. Se poartă discuţii cu
specialişti ai domeniului şi cu potenţialii utilizatori ai viitorului produs informatic.
Pe baza studiului realizat se obţin informaţii cu privire la cerinţele, restricţiile şi
obiectivele avute în vedere pentru asigurarea funcţionalităţii noului sistem.
Definirea clară a cerinţelor funcţionale şi tehnice reprezintă începutul formalizării
proiectelor: identificarea, organizarea şi iniţierea acestora.
Auditorul, în calitate de membru al echipei de proiectare, va analiza următoarele
aspecte:
- un utilizator din fiecare departament afectat de noul sistem a fost inclus în echipa de
proiectare;
- s-a făcut o planificare a proiectului;
Definirea
cerinţelor
Analiză
Proiectare
Implementare
Testare
Utilizare şi întreţinere
Fig. 8.8 Ciclul de viață a unui sistem informatic
300
- în proiect este implicat şi un reprezentant al conducerii;
- estimarea calitativ-cantitativă a costurilor şi beneficiilor s-a făcut pe baza unor studii de
fezabilitate;
- se are în vedere efectuarea unor studii de fezabilitate pe parcursul dezvoltării
proiectului;
- se cunoaşte impactul pe care îl are noul sistem asupra organizaţiei;
- s-au estimat costurile sociale datorate schimbării sistemului.
Pe parcursul dezvoltării sistemului, auditorul intervine în următoarele puncte de control:
a) realizează o revizie finală a planurilor, echipamentelor mecanice, costurilor
implicate pentru a selecta cea mai bună variantă de proiect;
b) revizuieşte documentaţia prin care sunt descrise fişierele, interfeţele de dialog,
formularele şi rapoartele, pentru a se asigura că sunt complete, clare şi în raport cu
standardele adoptate;
c) verifică respectarea specificaţiilor proiectării iniţiale sau dacă există posibilitatea
aplicării modificărilor intervenite pe parcursul derulării proiectului.
2. Analiza sistemului
Concluziile la care ajunge echipa de analişti, după parcurgerea etapei anterioare, se va regăsi în
proiectul de realizare a sistemului informatic.
În analiza sistemului informațional trebuie să regăsim aspectele:
- aria de întinderea a sistemului informațional care va deveni sistemul obiect pentru
conceperea şi realizarea unui sistem informatic.
- reflectarea activităților şi operațiilor economice specifice sistemului informațional
- surprinderea modificărilor ce se impun în organizarea şi funcționarea unui sistem
informatic.
- fundamentarea unei soluții de principiu care să precizeze activitatea şi operațiile ce
urmează a fi informatizate.
- costul antecalculat al sistemului.
În analiza sistemului economic ca etapă a ciclului de viaţă al unui sistem informatic auditorul
urmăreşte:
- întocmirea specificaţiilor de utilizator: definirea cerinţelor utilizatorului;
- întocmirea specificaţiilor sistemului informatic: prezentarea, în detaliu, a rezultatelor pe
care trebuie să le ofere sistemul informatic utilizatorilor săi; la acest nivel se stabileşte
ce trebuie să facă sistemul informatic;
- întocmirea specificaţiilor software: prezintă ce trebuie să facă produsul software de
aplicaţie şi condiţiile pe care trebuie să le respecte;
301
- 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 activități 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 poziționarea membrilor acesteia în posturile adecvate pentru a-și îndeplini sarcinile
cât 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. Neîncadrarea în buget poate conduce la reduceri ale profitului și
la rate de eficiență mai scăzută ale investiției.
Încadrarea în durata de realizare.
Trebuie urmărit ca toate etapele proiectului să se încheie la momentul prevăzut, pentru a
permite încheierea proiectului la sau înaintea datei prestabilite. Dacă se depășește durata de
realizare pot apărea două aspecte negative: se depășește, cu mare probabilitate bugetul alocat
și se afectează planificarea resurselor pentru următoarele 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 urmăreşte
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 funcţie de nevoile utilizatorului, ştiut fiind faptul că
volumul cel mai mare de muncă constă în culegerea datelor.
Pentru ca managementul unui proiect să fie cât mai eficient, elementele planului de realizare a
proiectului trebuie estimate cât mai corect și aranjate într-o secvență logică de derulare cât mai
coerentă și logică.
În primă fază se procedează la inventarierea și întocmirea listei de activități care trebuie
executate.
Lista de activități trebuie să fie cât mai cuprinzătoare și pentru elaborarea ei să se
poată recurge la o sesiune de braistorming cu alti conducători de proiecte și cu
conducerea firmei beneficiare. Cu această ocazie se va urmări în mod deosebit
menționarea activităților, nu și succesiunea acestora.
În faza următoare, activitățile inventariate vor fi descompuse în subactivități stabilind
succesiunea logică a lor și apoi planificate în timp.
302
Pe baza normativelor existente, dar mai ales a experienței acumulate, se trece la
stabilirea duratei activităților din listă. Durata fiecărei activități depinde de etapa de realizare în
care ne găsim. Unitatea de exprimare a duratei este, de regulă, ziua sau săptămâna și este
recomandată ca durata unei activități să fie multiplu de acea unitate
În cazul proiectelor foarte simple, este posibil ca durata acestora să fie egală cu suma
duratelor activităților componente. Aceasta se poate întâmpla când o singură persoană se
ocupă de analiză, proiectare, programare și implementare. Situația normală însă este când
lucrează o echipă formată din mai multe persoane și fiecare câte o sarcină distinctă. Durata
generală depinde de interconditionările dintre aceste sarcini și de ordinea în care sunt realizate.
Numărul de activități care se pot realiza în paralel depinde de numărul de membri care sunt în
echipă și de faza în care se găsește proiectul.
După estimarea duratei activităților, lista activităților se poate completa cu duratele
corespunzătoare și apoi se face cunoscută tuturor membrilor echipei astfel încât distribuirea
sarcinilor să fie pe cât 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 către
managerul de proiect, și anume:
resursele umane;
echipamentele și materialele;
serviciile;
transportul;
instalațiile 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 performanțele
oricărui proiect.
2. Controlul proiectelor
Prin controlul proiectelor trebuie să se urmărească progresele realizate în dezvoltarea
proiectelor, în raport de obiectivele stabilite. Trebuie să ne asigurăm că proiectul va fi finalizat la
data prevăzută în contract, că se încadrează în bugetul specificat și că furnizează ce s-a stabilit,
la o calitate ridicată.
303
Controlul iniţierii proiectului de dezvoltare a sistemului informatic asigură auditorii că decizia
privind realizarea sau achiziţia unui nou sistem este în conformitate cu obiectivele şi planurile
organizaţiei.
Controlul constă din două părţi:
- urmărirea;
- luarea masurilor.
Este cunoscut faptul că niciodată lucrurile nu evoluează așa cum sunt planificate.
Factorii care produc modificări în derularea proiectelor pot fi următorii:
- estimările făcute la planificarea proiectului pot fi greşite;
- cerinţele se pot schimba;
- termenul final se poate schimba (de obicei, mutându-se mai devreme);
- bugetul se poate micșora;
- prioritatea proiectului se poate schimba;
- rezistența la schimbări;
- greşelile oamenilor.
Gradul de complexitate a proiectelor sunt factori care determină metoda de control și raportare.
Din acest punct de vedere distingem mai multe situaţii 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 obţinute într-un interval mare de timp.
În realizarea sistemului informatic ca etapă a ciclului de viaţă auditorul urmăreşte:
- realizarea componentelor sistemului informatic din arhitectura sistemului informatic, pe
baza soluţiilor oferite de proiectarea în detaliu;
- testarea componentelor şi verificarea modului de funcţionare;
- verificarea îndeplinirii cerinţelor utilizatorului; verificarea fiabilităţii în utilizare;
- integrarea componentelor în sistemul informatic şi testarea finală a acestuia-reunirea
componentelor în produsul final şi verificarea funcţionării acestuia, în ansamblul său.
Dezvoltarea unui sistem informatic alegând soluţia outside, presupune că achiziţia
echipamentului se va face de către organizaţie, iar aplicaţiile vor fi dezvoltate si achiziţionate de
la furnizor.
Dezvoltarea unui sistem informatic alegând soluţia 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
304
strânsă dintre realizatorii sistemului informatic şi beneficiarii acestuia. Este etapa în care
sistemul este supus la cea mai dificilă testare, cea a condiţiilor reale de funcţionare. Acum pot
apărea cazuri care nu au fost prevăzute de proiectanţi, la care sistemul nu este protejat.
Implementarea sistemului constă în punerea în practică a specificaţiilor logice şi are în vedere:
corelarea modulelor din punct de vedere al funcţiilor logice realizate (invocări, utilizări);
crearea interferenţei dintre module conform standardelor de intrare/ieşire;
ordinea în care modulele sunt codificate, testate şi implementate;
calitatea datelor şi destinaţia rapoartelor;
cerinţele fişierelor şi ale bazei de date (număr, conţinut, tipuri de date, tipuri de acces,
tipuri de înregistrări, etc.);
ordonanţa activităţilor de implementarea, instalarea şi de instruire specifice sistemului
considerat.
În cadrul acestei etape se testează, se verifică şi se asimilează de către beneficiar toate
soluţiile stabilite în etapele anterioare şi se validează rezultatele obţinute.
Controlul implementării noului sistem informatic prevede:
- atribuirea responsabilităţilor persoanelor care se vor ocupa de implementare;
- stabilirea unor standarde prin care să se asigure eficienţa şi eficacitatea procesului de
implementare;
- existenţa unui plan al implementării, pe baza căruia să se poată evalua progresele făcute.
În timpul implementării, numeroase activităţi vor fi executate simultan. De aceea, ele
trebuie să fie planificate şi programate de către o echipă de implementare formată din utilizatori,
manageri şi specialişti în proiectarea sistemelor.
Planificarea implementarii, firesc, începe anterior demarării unei astfel de acţiuni. De fapt,
problemele implementării sunt abordate chiar la începutul proiectului, iar aspectele conceptuale
şi strategiile implementării şi conversiei sistemelor trebuie luate în discuţie în fiecare stadiu al
ciclului de viaţă al sistemelor. Totuşi, planurile detaliate de implementare nu pot fi finalizate până
când conducerea nu aprobă proiectul noului sistem.
Un plan de implementare evidenţiază toate activităţile necesare, ajutând pe cei ce-l
întocmesc să fie siguri că totul a fost prezentat corect. Prin el se vor consemna toate activităţile
de efectuat, precum şi timpul alocat. Responsabilităţile de execuţie trebuie să fie foarte clare. De
asemenea, trebuie estimate costurile fiecărei activităţi astfel încât să poată fi elaborat un buget
special. În acelaşi timp trebuie determinate reperele de execuţie în timp, pentru a se putea
exercita controlul. Mai dificil este de estimat momentul când se va finaliza implementarea. De
fiecare dată utilizatorii sunt cei care îşi dau acceptul final, iar procesul, teoretic, poate fi
considerat ca desfăşurându-se pe o perioadă nedefinită.
305
Planul de implementare este revizuit şi modificat la intervenţiile comitetului de
informatizare, ale utilizatorilor, ale conducătorilor sistemului, înainte de a începe operaţiunea de
implementare.
Ca membru al echipei ce răspunde 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 fişiere 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ă corecţia.
Testarea nu se încheie decât atunci când se efectuează lansarea prelucrării de către
întreaga aplicaţie informatică cu un set complet de date. Acest set va include toate datele
posibile, corecte şi eronate pentru a urmări reacţia întregului pachet de programe. În această
testare globală se urmăreşte: validarea datelor de intrare şi a rezultatelor, dialogul din sistemul
informatic, modul de operare la execuţie. Se urmăresc atât aspectele formale cât şi cele de
fond.
În urma testării, auditorul trebuie să se asigure că:
- sistemul funcţionează corect;
- în cazul întreruperii prelucrărilor, sistemul transmite mesaje de avertizare utilizate;
- nu există prelucrări neefectuate.
Un test complet de acceptare constă în efectuarea testării pilot şi a testării paralelă.
În cazul testării paralele datele vor fi preluate atât prin intermediul vechiului sistem cât ş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 obținut cunoașterea și prin documentare asupra :
Fluxului tranzacțiilor prin sistem
Controalele aplicate intrărilor, prelucrărilor, ieșirilor.
Auditorul trebuie să identifice ș i să cunoască orice documentație a aplicației existentă la
client.
306
6. Mentenanţa sistemului
Activitatea de mentenanţă include un proces de revizuire post-implementară pentru a se asigura
că sistemele informatice nou implementate corespund obiectivelor, cerinţelor şi performanţelor
prestabilite.
Pe timpul mentenanţei un grup de persoane se va ocupa de colectarea cererilor de întreţinere
lansate de utilizatori sau de alte părţi implicate în exploatarea sistemului sau verificarea modului
în care acesta funcţionează. Activităţile implicate de mentenanţa sistemului sunt:
obţinerea cererilor de întreţinere;
transformarea cererilor în propuneri de schimbări;
proiectarea schimbărilor;
implementarea schimbărilor.
Auditorul trebuie să verifice dacă există proceduri prin care se asigură executarea numai a
modificărilor autorizate în cadrul controlului întreţinerii sistemului.
Întrucât cheltuielile de mentenanţă au o pondere substanţială în structura costurilor totale ale
sistemelor, considerăm relevantă prezentarea tipurilor de mentenanţă: corectivă, adaptativă,
perfectivă, preventivă.
Mentenanţa corectivă constă în efectuarea unor lucrări de reparaţii pentru îndepărtarea unor
defecte produse în timpul proiectării, scrierii programelor sau implementării sistemului. În
majoritatea cazurilor, întreţinerea corectivă intervine imediat ce se pune în funcţiune noul sistem
sau o componentă a acestuia. Cât timp o astfel de întreţinere îşi propune doar să îndepărteze
defecte, ea nu adaugă valoare decât într-o pondere derizorie, în pofida celor 75 de procente
alocate întreţinerilor corective din totalul activitătilor de întreţinere a sistemului.
Mentenanţa adaptativă presupune efectuarea unor schimbări în sistem, condiţionate de:
intenţia de îmbunătăţire a performanţelor funcţionale; adaptarea la schimbările organizaţionale;
deplasarea sferei de activitate a unităţii în alt mediu.
Dacă întreţinerea corectivă presupune o intervenţie cât mai urgentă în urma sesizărilor venite
din sistem, cea adaptivă nu este la fel de presantă, întrucât factorii care o condiţionează nu au
apariţii spontane. O altă diferenţă constă în faptul că întreţinerea adaptivă, spre deosebire de
cea corectivă, adaugă valoare organizaţiei.
Mentenanţa perfectivă are ca scop efectuarea unor schimbări pentru îmbunătăţirea diverselor
prelucrări, modificarea cu scopul folosirii mai uşoare a interfeţelor sau pentru a i se adăuga noi
elemente, care însă nu sunt strict necesare. O astfel de operaţiune de întreţinere constituie mai
307
curând o dezvoltare a sistemului şi face parte din categoria activităţilor care adaugă valoare
organizaţiei.
Mentenanţa preventivă se efectuează cu scopul diminuării substanţiale a posibilităţilor de
defectare a sistemului, adaugă valoare organizaţiei.
Activitatea de mentenanţă trebuie evaluată pentru a observa dacă, la un moment dat, cheltuielile
implicate nu depăşesc limitele acceptabile. Dacă la un moment dat se constată că beneficiarele
sunt puternic afectate de cheltuielile cu mentenanţa, se poate concluziona că sistemul nu mai
răspunde necesităţilor şi este necesară înlocuirea sa parţială sau totală. În felul acesta se reia
ciclul de viaţă al dezvoltării sistemului
C. Controale hardware
Echipamentele digitale, componentele hardware ale sistemelor moderne de prelucrare automată şi
de evidenţă a datelor au, din construcţie, o precizie foarte mare şi o fiabilitate foarte bună; prin
urmare, toleranţa de calcul nu produce erori în rezultatele finale ale prelucrărilor efectuate, iar
defecţiunile tehnice care determină alterări şi/sau pierderi masive de date şi programe sunt puţine.
Pentru evaluarea corectă a fiabilităţii echipamentelor digitale utilizate la implementarea unui sistem
informatic, în vederea prevenirii pierderilor (de date şi programe) şi reducerii erorilor (în rezultatele
finale ale prelucrărilor) produse de posibilele defecţiuni tehnice ale acestor echipamente, economiştii,
inclusiv auditorii, trebuie să cunoască controalele integrate de fabricant în fiecare tip de echipament,
care sunt întâlnite în literatura de specialitate sub numele de controale hardware.
Cele mai întâlnite controale hardware sunt:
Ecoul: constă într-un semnal pe care echipamentul periferic îl trimite (returnează) către unitatea
centrală de prelucrare, dacă a recepţionat corect datele transmise de aceasta; prin ecou se verifică
dacă echipamentul periferic se comportă în conformitate cu instrucţiunile 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, conţin tehnici sau proceduri de autodiagnoză; exemplu: identificarea circuitelor de interfaţă
sau modulelor de memorie defecte, înainte ca sistemul să poată fi considerat valid, permiţând astfel
utilizatorului să evite utilizarea unui sistem defect (Post- Power On Self Test).
Verificarea prin duplicare: constă în realizarea fiecărei operaţii de două ori şi compararea rezultatelor;
în procesul dublu de verificare, cunoscut sub numele de citire după scriere, calculatorul citeşte datele,
după transferarea lor în sistem, şi le verifică corectitudinea.
308
Verificarea parităţii: constă în controlul sau verificarea parităţii într-un sistem de calcul digital, modern,
care prelucrează datele în serii de biţi (cifrele binare 1 şi 0); controlul parităţii se face prin compararea
valorilor bitului de paritate, calculate înainte şi după un transfer de date, pentru a verifica dacă biţi de
date s-au modificat pe durata transferului; bitul de paritate, care conţine suma tuturor biţilor de
1(unu) pari sau impari, în funcţie de construcţia fiecărui echipament digital, este adăugat de fabricant
la biţii de date folosiţi pentru reprezentarea numerelor sau caracterelor alfanumerice transferate între
componentele unui sistem digital de calcul.
Concluzie. Asigurarea funcţionării corespunzătoare a hardware-ului unui sistem modern de
prelucrare automată a datelor, în vederea evitării pierderilor sau alterării de date şi programe,
determinate de apariţia unor defecţiuni tehnice, impune nu numai folosirea controalelor hardware
prevăzute de fabricantul echipamentelor, ci şi aplicarea unui mecanism de întreţinere preventivă
conceput de către organismul economic care utilizează sistemul informatic respectiv. Auditorii de
sisteme informatice trebuie să cunoască nu numai controalele hardware integrate de fabricanţi în
echipamente, ci şi măsurile de întreţinere 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
siguranţei:
echipamentelor componente (hardware), pentru a nu fi deconfigurate (accidental sau voit),
descompletate şi/sau distruse;
programelor şi fişierelor 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 prelucrărilor efectuate automat şi în evidenţele computerizate, deoarece pot fi
distruse sau alterate cu uşurinţă, accidental sau voit, blocând accesul utilizatorilor la volumele mari de
date stocate în sistem şi, implicit, la informaţiile obţinute prin interpretarea rezultatelor prelucrărilor
efectuate asupra acestora; de asemenea, permit foarte uşor distrugerea, alterarea sau pierderea,
acciden-tală sau voită, a bazelor de date stocate şi gestionate de sistemul informatic, în condiţiile în
care cel mai mare volum de muncă rezidă în crearea şi întreţinerea acestora.
Principalele tipuri de controale de siguranţă utilizate pentru protecţia unui sistem informatic sau a
componentelor acestuia, hardware sau software, sunt:
Programarea sistemului de operare al fiecărui calculator:
să întocmească un jurnal al utilizării tuturor echipamentelor periferice accesibile (ultimele
utilizări); aceasta asigură identificarea momentului ultimei utilizări corecte şi apariţiei
primului incident în utilizarea fiecărui echipament periferic în parte; exemplu: indică
309
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 atenţionare, dacă se fac tentative de acces repetat în sistem, prin
folosirea unor parole incorecte, sau tentative de efectuare a unor operaţii care pot distruge
datele sau pot genera anomalii în funcţionarea sistemului respectiv; exemplu: utilizatorul
este atenţionat de sistemul de operare că operaţia de formatare a unui disc magnetic
(HardDisk, FloppyDisk etc.) determină pierderea programelor şi/sau datelor stocate pe
acesta, dându-i posibilitatea să le salveze înainte de efectuarea operaţiei 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 locaţie de unde
se poate accesa sistemul, la fiecare punct de lucru sunt necesare măsuri 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 informaţiile obţinute pe baza rezultatelor oferite
de întregul sistem.
Crearea funcţiei de administrator al bazei de date, pentru protejarea acesteia la accesul neautorizat,
de către 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 clienţilor (fişierul clienţilor), care conţine toate datele de identificare
şi despre activitatea fiecărui client în parte, folosite de secretariat (pentru întocmirea contractelor), la
departamentul de vânzări (pentru evidenţa activităţii clienţilor respectivi), la serviciul contabilitate
(pentru evidenţa plăţilor efectuate de acesta) etc., gestionează accesul utilizatorilor la baza de date
respectivă.
Programarea fiecărei componente a software-ului de aplicaţie utilizat de sistemul informatic:
să emită un semnal de atenţionare, dacă se fac tentative repetate de acces (prin folosirea
unor parole incorecte), dacă se încearcă efectuarea unor operaţii care pot distruge
datele sau pot genera anomalii în funcţionarea sistemului respectiv; exemplu: programul de
aplicaţie atenţionează utilizatorul, printr-un mesaj, că operaţia care urmează a se efectua
asupra datelor poate fi produsă de un virus care le distruge, lăsându-i posibilitatea de a
decide dacă operaţia respectivă este sau nu cea programată;
să întocmească o listă a celor mai recenţi utilizatori: nume, parolă, data şi ora accesului;
aceasta permite identificarea momentelor când s-au produs incidente şi a utilizatorilor care,
prin modul de operare, determină anomalii în funcţionarea Sistemului informatic, pierderi sau
310
alterări de programe sau date, cu scopul de a afla informaţii legate de incidentele respective,
în vederea stabilirii posibilităţilor de refacere a sistemului, şi de se ridica dreptul de acces
tuturor celor care nu-l exploatează corect;
să întocmească o listă cu ultimele operaţii efectuate de fiecare utilizator; prin consultarea
acestei liste se identifică operaţia sau secvenţa de operaţii care produce anomalii în
funcţionarea sistemului informatic, pierderi sau alterări de programe şi/sau date, în vederea
efectuării corecţiilor care se impun.
Crearea unor copii de siguranţă pentru toate componentele software utilizate de sistemul informatic
(fişiere 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 locaţii separate de original.
De exemplu:
benzile sau discurile magnetice, folosite pentru stocarea pe termen lung a datelor şi
programelor de aplicaţie, pot fi afectate de expunerea la căldură excesivă sau la un câmp
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 utilizării, orice fişier (de date sau program) poate fi şters, din greşeală, sau poate fi
distrus, în orice moment, de un virus; pentru refacerea rapidă a fişierelor pierdute sau
distruse accidental, se recomandă păstrarea (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, fişierele care sunt
actualizate periodic, numite fişiere master, se salvează respectând principiul de salvare
numit bunic – tată – fiu, potrivit căruia fişierul master curent actualizat este fiul, fişierul
master utilizat în actualizare (care a produs fiul) este tatăl şi fişierul anterior tatălui este
bunicul; cele trei generaţii de fişiere de date se vor depozita în locaţii diferite, pentru a
minimiza riscul pierderii tuturor;
în timpul funcţionării, orice sistem de calcul se poate defecta, producând pierderea/
distrugerea fişierelor stocate (memorate) în sistem (pe HardDisk); de aceea, pentru
prevenirea pierderilor masive de date şi programe produse de defecţiunile tehnice, se
recomandă arhivarea acestora pe suport magnetic extern (FloppyDisk, CD-ROM, CD-
RW, USB- flash etc.)
Măsuri de protecţie la accidente sau sabotaj (foc, apă, distrugere etc.), care previn distrugerea
accidentală sau deliberată a sistemului informatic, în întregul său, care constau, de regulă, în:
311
limitarea accesului, în aria de desfăşurare a activităţii, numai pentru personalul autorizat;
intrările în locaţiile destinate sistemului informatic trebuie să fie controlate de agenţi de
pază sau activate pe bază de cartelă de acces;
construirea locaţiilor destinate sistemului informatic (camera calculatorului) din materiale
rezistente la foc, deasupra nivelului probabil de inundaţie şi dotarea acestora cu aer
condiţionat, pentru a evita apariţia defectelor tehnice şi a preveni deteriorarea suporţilor
magnetici de stocare a datelor şi programelor (benzi sau discuri magnetice) prin
asigurarea unei temperaturi şi umidităţi corespunzătoare în spaţiul lor de funcţionare.
Concluzie. Fără implementarea măsurilor 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 atât sistemul, în ansamblul său, cât şi
componentele acestuia.
8.3.2 Controalele de aplicaţie
Controalele de aplicaţie sunt tehnici de control specifice, integrate în software-ul de aplicaţie
(utilizator) dintr-un sistem informatic, cu scopul de a asigura corectitudinea şi protecţia datelor
stocate în sistemul respectiv şi a rezultatelor prelucrărilor efectuate asupra acestor date. Se
proiectează şi se realizează o dată cu fiecare sistem informatic. Principalele tipuri de controale de
aplicaţie sunt:
A. controale de intrare: măsuri de asigurare a corectitudinii intrărilor sistemului;
B. controale de prelucrare: măsuri de asigurare a corectitudinii prelucrărilor efectuate în interiorul
sistemului;
C. controale de ieşire: măsuri de asigurare a corectitudinii ieşirilor sistemului.
Majoritatea erorilor identificate în rezultatele finale ale prelucrărilor efectuate de sistemele
informatice provin din software-ul de aplicaţie (de utilizator) folosit sau din introducerea eronată a
datelor. Din acest motiv, controalele de aplicaţie joacă un rol major în asigurarea unui control intern
eficient în sistemul informatic.
312
Fig. 8.9 Controalele de aplicație
A. Controlul intrarilor
Intrările sunt reprezentate de:
- tranzacţii externe care redau dinamica operatiilor economice, provin din exteriorul
sistemului informatic electronic de calcul şi sunt furnizate de proceduri automate.
Exemplu: înregistrarea unei operaţii de aprovizionare cu marfă;
- tranzacţii interne care redau modificările 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 funcţie de nevoile
utilizatorului în instrucţiuni primite şi accesibile procesorului.
Controlul intrărilor
Controale de aplicație
Controlul datelor de ieșire
Controlul prelucrărilor
313
Autorizarea
- Autorizarea controalelor reduce riscul erorilor, fraudei și tranzacțiilor 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 intrărilor:
- 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 intrărilor, 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 până când
sunt introduce.
Controlul datelor de intrare trebuie adaptat la modalitățile 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 tranzacțiilor (ex.: plăți planificate, calcularea lunară a
dobânzilor)
Nu toate intrările prezintă un suport material (documente pe suport hârtie), multe fiind în format
electronic. Folosirea anumitor dispozitive pentru introducerea datelor în sistem (cititoare de cod-
bara, ATM-uri, scanner, terminale POS) reduce posibilitatea aparițiilor erorilor în această etapă.
Î n cazul preluării automate sau generării automate există riscuri mai mici de eroare față de
preluarea datelor prin tastare.
Cu cât crește intervalul dintre identificarea existenței unei anumite stări de lucruri sau
evenimente și înregistrarea acestora în sistem, tot atât crește posibilitatea aparițiilor erorilor în
sistem.
Tipuri de controale aplicate asupra datelor de intrare
314
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 mulțime de valori prestabilită (ex.: abrevierile j udețelor, tipuri de
unități de măsură, tipuri de documente) ;
încadrarea într-un interval de valori prestabilit (ex.: salariul angajatilor ia valori în
intervalul [ 1.000, 3.000.] )
validări ale realizărilor unor atribute diferite numit și testul dependenței logice dintre
câmpuri. Ex.: validările privind corespondența conturilor – contul X se poate debita doar prin
creditarea conturilor A,B,C.
testul “ rezonabilității” datelor :
- aceste teste verifică dacă datele sunt rezonabile în raport cu un standard sau date
introduse anterior. Datele standard pot fi stocate într-un fișier sau pot reprezenta
constante definite la nivelul aplicației (ex.: un standard poate fi reprezentat de numărul
de ore lucrătoare într-o lună, stabilit în funcție de zilele lucrătoare și sărbătorile legale,
nivelurile de dobândă practicate de bancă etc.)
Controlul acurateței ari tmetice
Pe baza unor date de intrare introduse de operator pot fi verificate elementele calculate din
documentul primar.
Ex. : pe baza cantității și prețului 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 putând confrunta aceste sume calculate cu cele înscrise în
factura.
Controlul exi stenței datelor
Testul se referă îin principal la validarea datelor de intrare reprezentând coduri. Este
suficient să introduci codul unul client și pe ecran să se afișeze numele acestuia sau un
mesaj de eroare atentionand asupra introducerii unui cod incorect.
Testul ci frei de control
- se aplică asupra datelor de intrare reprezentând elemente codificate
- urmărește rejectarea codurilor eronate introduse
315
- cauza erorii la nivelul elementelor codificate poate fi :
Trunchierea
Adaugărea unui caracter suplimentar
Transcrierea incorecta a codului în documentul primar
Transpoziția caracterelor la introducerea codului.
- presupune determinarea cifrei de control aferente codului introdus prin aplicarea
algoritmului prestabilit. Î n măsura în care cifra de control determinată automat
nu corespunde celei incluse în codul introdus sistemul va trebui să atenționeze
printr-un mesaj corespunzător asupra erorii apărute.
Testul tranzacțiilor dupli cate
- sistemul admite introducerea repetată a acelorași date?
Ex. : introducerea repetată a unui aceluiași document (factura, bon de consum etc.).
Soluti onarea tranzacți i lor rejectate
- cum se soluționează tranzacțiile neacceptate de sistem (care nu au trecut testul
de
validare)?
- cine răspunde de verificarea acestor date de intrare și de reintroducerea lor?
- sunt generate liste conținând intrările rejectate?
- dacă aceste tranzacții sunt consemnate în documentele primare depistarea erorii
este mai ușoară și corectarea se poate face fără probleme deosebite. Probleme
particulare apar în cazul tranzactiilor online.
B. Controlul prelucrărilor
Prelucrările sunt asigurate de un ansamblu de proceduri automate care realizează actualizarea
şi exploatarea colecţiilor de date ca urmare a tranzacţiilor interne şi externe în vederea obţinerii
rapoartelor, listelor, situaţiilor 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 oricărui tip de organism
economic sau compartiment specializat al acestuia, ţinând cont de particularităţile specifice
fiecăruia şi de legislaţia în vigoare.
Auditorul ține seama de:
Tipologia sistemului informatic:
- Sisteme de procesare a tranzacțiilor (TPS – Transaction Processing Systems)
316
- 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 lucrărilor de birou (OAS – Office Automation
Systems)
Modalităților de introducere a datelor în sistem și procesarea acestora:
- I ntroducere pe loturi – procesare pe loturi
- I ntroducere on line – procesare pe loturi
Natura prelucrărilor:
Î 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 prelucrărilor.
În prelucrarea autonomă a datelor, următoarele funcții trebuie să fie exercitate de persoane
diferite :
- operare calculatoarelor – programare
- pregătire date – procesare date
- operare calculator – gestiune suporți materiale
- codarea programelor – administrarea bazei de date
Controlul fișierelor și al bazei de date
Se verifică:
- Continuitatea acestora
- Versiunea – Este ultima versiune? Cuprinde ea toate corecțiile?
- Transferul fișierelor în momentul trecerii la exploatarea unui nou sistem
informatic. Se verifică măsura în care au fost autorizate procedurile de transfer al fișierelor
din vechiul în noul sistem. Au fost aceste proceduri realizate de persoanele împuternicite? Se
verifică completitudinea și corectitudinea transferului.
- Soluția 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 eficiența distribuire a datelor
în nodurile rețelei? Î n ce măsură s-a ținut seama de respectarea următoarelor
cerințe:
317
Nevoile de informare a utilizatorilor locali
Asigurarea unui transfer minim al datelor prin rețea
Necesitatea protecției datelor transferate prin rețea.
- Care au fost criteriile pentru alegerea SGBD-ului? Ofera SGBD-ul toate facilitățile
privind implementarea controalelor automate, al controlului accesului la baza de date,
tabelele bazei de date etc.
Disponibilitatea datelor
Datele, în procesul prelucrării, datorită reprezentării binare sunt inaccesibile auditorului în
această formă. Mai mult, unele date sunt temporar stocate în memoria calculatorului
(datele intermediare de lucru).
Controlul prelucrărilor declanșate automat
- Auditorul trebuie să verifice care sunt evenimentele care declanășează aceste prelucrări;
- Controlul tranzacțiilor generate automat.
Funcționalitatea aplicației
- Există anumite prelucrări pe care aplicația trebuie să le execute, dar nu le realizează sau
le realizează greoi?
- Sunt funcționalități care lipsesc?
- Î n ce măsură aplicația răspunde stilului și metodei de lucru specifice utilizatorului?
- Determină aplicația un mod de lucru ineficient, o gândire rigidă, nenaturală?
Controlul fluxului prelucrărilor
- Presupune să verificăm ce prelucrări urmează să se declanșeze în anumite
circumstanțe.
- Controalele de aplicaţie asigură tehnicile de control, integrate în software-ul de aplicaţie
dintr-un sistem informatic, cu scopul de a asigura corectitudinea şi integritatea datelor stocate în
sistemul respectiv şi a rezultatelor prelucrărilor efectuate asupra acestor date .
- Testul oad conditions : un program poate funcționa nesatisfăcător când 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 ușor “să te pierzi” în program?
- Există opțiuni de lucru care pot fi confundate cu altele?
- Care sunt mesajele de eroare? Sunt utile, explicite?
318
- Ce informație este disponibilă pe ecran? Este suficientă, clară?
- Calitatea asistenței oferite utilizatorului (informația returnată de tasta HELP de exemplu).
Performanțe
În cazul sistemelor în timp real este foarte important timpul de răspuns
I ntegrarea prelucrărilor
In cazul defectării sistemul de procesare a datelor organizația poate încheia un contract cu o
altă organizație( sau mai multe) al cărei sistem de procesare a datelor are aceleași facilități și
care poate să suporte prelucrările firmei al cărei sistem nu mai este funcțional sau poate apela
la o altă firmă care oferă servicii în acest domeniu.
C. Controlul datelor de ieșire
Ieşirile sistemului informatic sunt rezultatul prelucrării bazei de date şi sunt redate în funcţie de
conţinutul lor şi de structura lor sub formă de indicatori sintetici, rapoarte, liste, situaţii de ieşire,
grafice, stocare pe suporturi.
Urmărește :
Completitudinea și acuratețea ieșirilor
Respectarea termenelor prevăzute pentru obținerea ieșirilor
Măsura în care ieșirile, la cererea utilizatorilor, pot fi dirijate către imprimantă, monitor
sau un fișier.
Distribuirea ieșirilor către persoanele autorizate :
- Cine primește situațiile? Există persoane împuternicite în acest sens?
- Situațiile conținând date sensibile sunt preluate pe bază de semnătură?
- Cum este asigurată protecția informațiilor confidențiale?
I eșirile către alte aplicații se realizează în formatul pe care acestea îl necesită?
Măsura în care se realizează înregistrarea, raportarea și corectarea erorilor identificate.
Î n ce măsură există din partea managementului un control asupra acurateței ieșirilor și
modului de distribuire a lor.
Controlul datelor de ieșire presupune măsuri și proceduri prin care se oferă asigurare cu privire
la :
- completitudinea și corectitudinea informațiilor generate cu ajutorul sistemului.
- distribuirea datelor doar persoanelor autorizate.
- jurnalizarea, urmărirea și corectarea erorilor raportate.
319
8.3.3. Raportul de auditare
Procesul de auditare se finalizează cu întocmirea unui raport care conţine propuneri de
măsuri de reducere şi de menţinere sub control a riscurilor importante ale noii aplicaţii. Raportul
de auditare este o lucrare de sinteză care are la bază o analiză a rezultatelor obţinute din
parcurgerea textelor sursă, din lansarea în execuţie a programelor şi din interpretarea
rezultatelor finale, mai ales prin interpretarea rezultatelor intermediare şi a celor de urmărire a
programului.
Raportul de audit este o lucrare cuprinzătoare care oferă o imagine privind siguranţa pe
care o dă produsul. Raportul de audit are un rol esenţial în angajamentele de audit şi asigurare,
deoarece comunică verdictul auditorului. Utilizatorii sistemului informatic se aşteaptă ca raportul
auditorului să ofere încredere în utilizarea sistemului informatic. Raportul de audit este un
element fundamental al auditării prin intermediul căruia se prezintă situaţia sistemului auditat
aşa cum a fost evaluată de auditori. Prin raportul de audit sunt comunicate, părţii auditate,
aprecierile şi concluziile auditorilor. Obiectivele raportului de audit sunt :
- redarea încrederii managerilor în sistemul informatic, imediat după terminarea misiunii de
audit;
- să ofere redomandări utile referitor la perfecţionarea procedurilor de control şi eficienţa
activităţii operative;
- să asigure o înregistrare oficială a activităţii de audit şi a răspunsului managerilor.
În practică, înainte de a prezenta un raport formal, în scris, auditorul are obligaţia de a
prezenta un raport verbal celor care răspund de activitatea analizată. Cu excepţia cazurilor de
fraudă, când este necesar uneori ca lucrurile să rămână secrete până la prezentarea raportului
oficial, în majoritatea cazurilor auditorul discută, în prealabil, cu managerul conţinutul raportului
de audit. În acest fel se reduce riscul ca rezultatele auditului să nu fie acceptate de către
manager.
Raportul de auditare este un text structurat care conţine:
- prezentarea contextului;
- rezultatul procesului de auditare;
- evaluările finale;
- înregistrările din fiecare etapă a procesului de auditare.
Raportul de auditare conţine detalii privind:
- descrierea produsului;
- stabilirea condiţiilor de utilizare normală;
- operaţiile interzise a fi efectuate folosind produsul;
- funcţiunile pe care le dezvoltă în condiţii normale, indicând intrările, respectiv output-urile;
- efectele secundare care apar atunci cînd intrările sunt complete şi corecte;
320
- riscurile care apar atunci când intrările sunt incomplete şi incorecte;
- modalităţi de reluare a procedurilor de utilizare.
Raportul de auditare arată că produsul este utilizabil sau produsul devine utilizabil dacă
se execută o serie de îmbunătăţiri. Raportul de auditare trebuie astfel întocmit astfel încât 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 alcătuieşte pas cu pas prin răspunsuri scurte şi clare la întrebările: cine? ce?
cum? de ce? Este obligatoriu ca raporul să includă secţiuni care abordează gradat problematica
de audit pentru un sistem informatic.
Prima secţiune include elemente de identificare pentru:
- sistemul informatic ce face obiectul auditării;
- baza în care se derulează procesul de auditare ;
- prezentarea echipei de auditori;
- prezentarea elaboratorilor sistemului informatic;
- prezentarea beneficiarului procesului de auditare.
A doua secţiune include elemente pentru:
- definirea obiectivului urmărit;
- stabilirea metodelor şi tehnicilor stabilite şi acceptate;
- structurarea procesului de auditare.
A treia secţiune defineşte planul de auditare şi conţţine descrieri pentru:
- etapele care trebuie parcurse;
- resursele alocate fiecărei etape:
- fluxurile care se generează;
- nivelul de exigenţă şi moduri de menţinere constantă a nivelului;
- comunicarea între membrii echipei de auditori, comunicarea auditorilor cu realizatorii
sistemului informatic, cumunicarea cu beneficiarii procesului de auditare.
A patra secţiune conţine detalierea tuturor surselor utilizate ca întrebări pentru procesul de
auditare:
- contracte;
- specificaţii;
- proiectul sistemului informatic;
- textele sursă;
- bazele de date;
- rezultatele testării efectuate de echipa care a elaborat sistemul informatic;
- documentaţii de proces;
- instrumente utilizate de către echipa care a dezvoltat sistemul informatic.
321
Sunt descrise listele elementelor utilizate cu comentarii privind calitatea textelor
întrebuinţate de auditori.
Raportul de audit trebuie să fie clar, concis, constructiv şi întocmit la timp. Raportul de
auditare reprezintă o probă importantă în orice acţiune declanşată de beneficiarul unui sistem
informatic atunci când sunt înregistrate diferenţe 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 interpretări.
Când se utilizează sintagma <<toate variantele>> înseamnă că pentru cele n noduri
terminale ale unei structuri arborescente au fost construite n seturi de date test, atingându-se
cele n noduri terminale. Pentru a nu lăsa loc interpretărilor, din enunţul raportului lipsesc
sintagme precum <<în majoritatea cazurilor>>, <<în general>>, <<numai în unele cazuri>>, <<în
celelalte situaţii>>, <<nu de puţine ori>>, <<este probabil să>>, <<există posibilitatea ca>> şi
toate celelalte construcţii care conduc la concluzii vagi.
Raportul de auditare:
- enumeră toate componentele;
- analizează toate variantele;
- include toate rezultatele;
- enumeră situațiile pe categorii de stări, fără a lăsa unele situații neclarificate;
- tratează cu aceeași măsură toate componentele;
- pentru fiecare situaţie creată se enumeră componentele identificate;
- utilizează pentru componentele aceluiaşi nivel, aceleaşi instrumente;
- este o construcţie consistentă;
- include ipoteze, constatări, măsurători care, prin profesionalismul cu care se realizează,
nu au un fundament pentru a fi contestate.
Transparenţa procesului de auditare, rigurozitatea cu care sunt aplicate cerinţele
standardelor şi claritatea cu care se prezintă rezultatul auditării dă o singură direcţie destinaţiei
raportului şi anume acceptarea concluziilor, indiferent care sunt acestea, de către cel care a
solicitat auditul sistemului informatic.
Raportul de auditare trebuie să fie convingător pentru a nu face obiectul comentariilor.
Trebuie să conţină descrierea unor aspecte evidente care nu fac obiectul comentariilor sau
negocierilor.
Structura anunţată trebuie respectată, iar textul trebuie să fie consistent. O afirmaţie făcută
trebuie cel mult susţinută. Ea nu trebuie nici nuanţată, cu atât mai mult nu trebuie contrazisă.
Este determinant pentru un raport de auditare să fie calitativ peste nivelul documentaţiei,
specificaţiilor sau oricărui alt text care provine de la elaboratorii sistemului informatic.
322
Teste de evaluare a cunoștințelor
Răspundeți 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 informaționale, examinăm controalele existente în cadrul unei
organizații și, chiar dacă ne consultăm cu alți specialiști sau ne exprimăm propriile opinii,
căutăm să perfecționăm controalele analizate.
3 Riscul fizic cuprinde defectarea calculatoarelor și a unităților periferice, precum și
condițiile nesatisfăcătoare ale mediului în care funcționează.
4. Riscul logic provine din aplicarea greșită a anumitor proceduri, a unor instrucțiuni
greșite sau erori umane mai mult sau mai puțin intenționate.
5. Dezvoltarea unui sistem informatic alegând soluţia outside, apelează la servicii externe pentru
tot ceea ce înseamnă sistem informatic.
Încercuiți răspunsurile 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.
323
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.
324
BIBLIOGRAFIE
1. Andone l., Ţugui A.
Baze de date inteligente în managementul firmei
Ed. Dosoftei, laşi, 2007
2. Arnold de Vos Utility Management Sistems Acces Facility
OMG TC Document dtc– 2014
3. Bara, I. Botha, V. Diaconiţa, I. Lungu, A. Velicanu
Baze de date. Limbajul PL/SQL Ed. ASE, Bucureşti, 2009.
4. Baron C., Sofronie Gh., Surcel Tr., Toma L.
Informatică economică Ed. Calipso 2000, Bucureşti, 2008
5. Benchimol G., Levine P., Pomerol J.C.
Sisteme expert în întreprindere Ed. Tehnică, Bucureşti, 2003
6. Biemans, F.P.M A Reference Model for Manufacturing Research and Technology
Elsevier Science Publishers, New York, 2000
7. Bouch G., Rumbaugh J., Jacobson I.
The Unified Modeling Language User Guide
Adisson Wesley, Reading, Massachusetts, 2009
8. Bouzeghoub M., Gardarin G., Valduriez P.
Objets : Concepts, Langages, Bases de Donees. Methodes, Interfaces, Deuxieme Tirages
Eyrolles, 2005
9. Celko J. Baze de date orientate obiect - Byte McGraw-Hill Inc., oct. 2007
10. Chichernea V. ş.a. Proiectarea sistemelor informatice - metode de realizare
Ed. Sylvi, Bucureşti, 2010
11. Coad P., Yourdon E.
Conception Orientee Object Masson, Paris, 2011
12. Connolly, T. and Begg, C.
Database Systems. A Practical Approach to Design, Implementation and Management
Addison Wesley, third edition, 2012
13. Coulouris G., Dolimore J., s.a.
Distributed systems – concepts and design
Ed. Addison Wesley, 2009
14. Curtis G., Cobham D.,
Bussiness Information Systems, Analysis, Design and Practice
Prentice – Hall, fourth editions, 2012
325
15. Davidescu N., Proiectarea sistemelor informatice financiar-bancare, vol. I+II
Ed. All Beck, Bucureşti, 2011
16. Diatcu E. ş.a. Elemente fundamentale ale teoriei sistemelor şi calculatoarelor
Ed. Hyperion XXI, Bucureşti, 2009
17. Evans N.D., Miller K., Spencer K.
Programming Microsoft Visual InterDev 6.0
Microsoft Press, 1999
18. Florescu V. ş.a., Baze de date Ed. Economică, Bucureşti, 2009
19. Flynn D., Information Systems Requirements: Determinations & Analysis
McGraw-Hill, 2008
20. Frăţilă, L .Proiectarea sistemelor informatice Editura InfoMega, Bucureşti, 2007
21. Gamache A., Modeles, Architectures, Langages de donnees
Ed. Griffon d'Argile, Quebec, 2012
22. Gherasim Z Programarea si Baze de date Ed. Fundaţiei România de Mâine, Bucureşti,2007
23. Grama A. ş.a. Medii de programare- metode şi instrumente de dezvoltare a aplicaţiilor economice
Ed. Sedcom Libris, laşi, 2008
24. Hurban C. Sisteme informatice pentru managementul firmei
Ed. Mirton, Timişoara, 2001
25. Ionescu A. Baze de date, curs universitar Facultatea de Automatică şi Calculatoare, Craiova 2001.
26. Lowe D. Tehnologia ClientlServer pentru toţi Ed. Teora, Bucureşti, 2006
27. Lungu l. ş.a. Baze de date- organizare, proiectare şi implementare
Ed. ALL, Bucureşti, 2011
28. Lungu l, Sabău Ghe.
Sisteme informatice şi baze de date Ed. A.S.E., Bucureşti, 2013
29. Lungu I., s.a.
Sisteme de baze de date evoluate Ed. A.S.E, Bucureşti, 2009
30. Munteanu A., Greavu V.
Reţele locale de calculatoare Ed. Polirom, Iaşi, 2004
31. Floarea Nastase (coord.), Razvan Daniel Zota (coord.), Carmen Timofte, Radu Constantinescu
Bazele tehnologiei informației Ed. ASE Bucureşti, 2013
32. S. Johnsons.
Microsoft Windows7 Ed Niculescu,București, 2010
326
33. Nicolescu O ş.a. Management Ed. Didactică şi Pedagogică, Bucureşti, 1992
34. Nicolescu O. (coordonator)
Sistemul informaţional managerial al organizaţiei
Ed. Economică, Bucureşti, 2001
35. Nicolescu O. , Verboncu I.
Fundamentele managementului organizației
Ed. Universitaria, 2008
36. Nicolescu O. , Ilies L.
Minidicționar de management – Sistemul Informațional
Ed. Pro Universitaria, 2011
37. O’Brien J. A., Introduction to Information Systems 8th Ed. Irwin, 2007
38. Oprea D. Analiza şi proiectarea sistemelor informaţionale economice
Ed. Polirom, laşi, 1999
39. Oprea D., Airinei D., Fotache M.
Sisteme informaţionale pentru afaceri Ed. Polirom, Iaşi, 2002
40. Oprea D., Meşniţă G.
Sisteme informaţionale pentru manageri
Ed. Polirom, Iaşi, 2002
41. Ora L., Ralph R. Swick
Resurce Description Framework [RDF] Model and Syntax Specification
W3C, Recomandation, 2002
42. Păun M. Analiza sistemelor economice Ed. ALL, Bucureşti, 2007
43. Peter R. Sch. The Leader’s Handbook New York 2008
44. Peterson L., Davie B.
Reţele de calculatoare Ed. All Educational, Bucureşti, 2008
45. Popescu I. ş.a. Noua economie şi societatea informaţională
Ed. MondoEc, Craiova, 2002
46. Radu l. Informatica managerială Ed. Economică, Bucureşti, 2006
47. Roşca I., Ţăpuş N., (coordonatori)
Internet & Intranet- Concepte şi aplicaţii
Ed. Economică, Bucureşti, 2006
48. Roşca J., Macovei E., Davidescu N., Răileanu V.
Proiectarea sistemelor informatice financiar-contabile
Ed. Didactică şi Pedagogică, Bucureşti, 2003
49. Rotaru S.
Sisteme informatice de gestiune economica
Ed. Universitaria, Craiova, 2010
50. Rotaru S., Ghiță M., Ghiță Șt.
Analiza si modelarea sistemelor informatice
Ed. Sitech, Craiova, 2006
51. Rotaru S., Ghiță M., Ghiță Șt.
Proiectarea și implementarea sistemelor informatice
Ed. Sitech, Craiova, 2006
327
52. Rotaru S., Ghiță M.,
Programarea în Access Ed. Universitaria, Craiova, 2006
53. Rîcu L, Rotaru S, Ghita M, Ghita St.
Baze de date S.G.B.D.Access 2002 Ed. Universitaria, Craiova, 2005
54. Saru D., loniţă A. D.
Sisteme de programe orientate pe obiecte
Ed. ALL Educational, Bucureşti, 2010
55. Steve Lambert, M. Dow Lambert III, and Joan Preppernau
Microsoft® Office Access™ 2007 Step by Step
Technology Microsoft Office Access 2007
56. Turban E., McLean E., Wetherbe J.
Information Tehnology for Management
John Willey Sous, 2011
57. Velicanu Manole ş.a.
Sisteme de gestiune a bazelor de date prin exemple
ASE, Bucureşti, 2013
58. Zaharie D., Roşca l.
Proiectarea obiectuală a sistemelor informatice,
Ed. DuaITech, Bucureşti, 2008
59. *** www.datawarehouse-training.com/Methodologies
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
