Suportcurs Sifc2 Psi Zi

DUMITRU OPREA
FLORIN DUMITRIU GABRIELA MEŞNIŢĂ
PROIECTAREA SISTEMELOR INFORMAŢIONALE

– Suport de curs –
Referenţi ştiinţifici:
Prof. univ. dr. Dinu AIRINEI

Prof. univ. dr. Marin FOTACHE
© Editura Universităţii „Alexandru Ioan Cuza” Iaşi, 2010

700109 – Iaşi, str. Pinului nr. 1A, tel./fax: 0232-314947
Dumitru Oprea
Florin Dumitriu Gabriela Meşniţă
PROIECTAREA SISTEMELOR
INFORMAŢIONALE
– Suport de curs –
EDITURA UNIVERSITĂŢII „ALEXANDRU IOAN CUZA”

IAŞI – 2010
CUPRINS
Mai mult decât proiectarea sistemelor ................................................................. 9
CAPITOLUL I Proiectarea formularelor/formatelor şi a rapoartelor .......... 11

1.1 Aspecte generale ale proiectării formularelor/formatelor şi a rapoartelor11
1.2 Caracteristicile generale şi clasificarea ieşirilor....................................... 12
1.2.1 Scopul ieşirilor............................................................................... 13
1.2.2 Destinatarii ieşirilor ....................................................................... 14
1.2.3 Frecvenţa ieşirilor .......................................................................... 15
1.2.4 Formatul ieşirilor ........................................................................... 16
1.2.5 Conţinutul ...................................................................................... 16
1.2.6 Sursa datelor .................................................................................. 19
1.2.7 Mediul de generare şi transmitere a ieşirilor ................................. 20
1.2.8 Controlul confidenţialităţii, integrităţii şi accesibilităţii ieşirilor.. 22
1.2.9 Caracteristicile informaţiilor şi nivelurile decizionale .................. 22
1.3 Reguli de proiectare a formularelor/formatelor şi a rapoartelor............... 22
1.3.1 Recomandări generale de formatare .............................................. 23
1.3.2 Scoaterea în evidenţă a informaţiilor............................................. 24
1.3.3 Reguli specifice de proiectare a rapoartelor în formă tabelară...... 27
1.3.4 Reguli specifice de proiectare a graficelor .................................... 30
1.3.5 Reguli pentru controlul confidenţialităţii, integrităţii şi accesibilităţii ieşirilor33
1.4 Demersul proiectării ieşirilor.................................................................... 34
1.5 Formularea specificaţiilor de proiectare a ieşirilor................................... 36
Rezumat .................................................................................................. 37
Întrebări recapitulative............................................................................ 38
Probleme ................................................................................................. 39
CAPITOLUL II Proiectarea interfeţelor utilizator ................................................. 40

2.1 Rolul interfeţelor utilizator în dezvoltarea sistemelor informaţionale ..... 40
2.1.1 Definirea conceptului de interfaţă ................................................. 41
2.1.2 Identificarea interfeţelor utilizator................................................. 43
2.2.2 Metode şi echipamente folosite în dialogul om-calculator............ 44
2.2.3 Metode de interacţiune om-calculator ........................................... 45
2.3 Principii de lucru în proiectarea interfeţelor utilizator ............................. 52
2.3.1 Controlul aplicaţiei de către utilizator ........................................... 53
2.3.2 Reducerea volumului de informaţii pe care trebuie sǎ le memoreze utilizatorul
...................................................................................................... 57
2.3.3 Uniformitatea interfeţelor utilizator .............................................. 59
2.4 Demersul proiectării interfeţelor utilizator............................................... 60
2.4.1 Culegerea şi analiza informaţiilor de la utilizatori ........................ 62
2.4.2 Proiectarea interfeţei utilizator ...................................................... 65
6
2.4.3 Construirea interfeţei utilizator ..................................................... 68

2.4.4 Evaluarea şi validarea interfeţei utilizator..................................... 70
2.5 Reguli de proiectare a meniurilor ............................................................. 71
2.6 Aspecte privind proiectarea interfeţelor web ........................................... 72
2.7 Controlul datelor în interfeţele utilizator.................................................. 72
2.8 Formularea specificaţiilor de proiectare a interfeţelor ............................. 74
Rezumat .................................................................................................. 75
Probleme ................................................................................................. 77
CAPITOLUL III Proiectarea logică a bazelor de date: modelarea logică a datelor78

3.1 Locul modelării logice a datelor în ciclul de viaţă al sistemelor .............. 78
3.2 Demersul proiectării logice a bazelor de date .......................................... 80
3.3 Transformarea diagramelor entitate-relaţie în relaţii................................ 81
3.3.1 Reprezentarea entităţilor................................................................ 82
3.3.2 Reprezentarea legăturilor............................................................... 83
Rezumat .................................................................................................. 91
Probleme ................................................................................................. 91
CAPITOLUL IV Proiectarea fizică a fişierelor şi a bazelor de date...................... 92

4.1 Aspecte generale ale proiectării fizice a fişierelor şi a bazelor de date.... 93
4.2 Analiza operaţiunilor de accesare a datelor.............................................. 93
4.2.1 Mecanismul tranzacţional al bazei de date .................................... 94
4.2.2 Analiza informaţiilor privind operaţiile de acces la date .............. 96
Rezumat .................................................................................................. 97
Probleme ................................................................................................. 98
CAPITOLUL V Proiectarea programelor şi a procedurilor ................................... 99

5.1 Aspecte generale ale proiectării programelor şi procedurilor .................. 99
5.1.1 Definirea arhitecturii programelor............................................... 100
5.1.2 Principiile de proiectare a programelor ....................................... 101
5.1.3 Structurile de control ale programelor......................................... 102
5.2 Organizarea ierarhică a programelor ...................................................... 105
5.3 Evaluarea obiectivelor proiectelor software ........................................... 106
5.3.1 Cuplarea....................................................................................... 107
5.3.2 Coeziunea .................................................................................... 109
5.3.3 Recomandări pentru proiectarea programelor ............................. 111
Rezumat ................................................................................................ 113
Întrebări recapitulative.......................................................................... 113
Probleme ............................................................................................... 114
7
CAPITOLUL VI Implementarea sistemului......................................................... 115

6.1 Planificarea implementării...................................................................... 116
6.2 Testarea sistemelor informaţionale......................................................... 117
6.2.1 Aspecte generale privind organizarea testării sistemelor ............ 117
6.2.2 Tehnici de testare......................................................................... 119
6.2.3 Strategia testării sistemelor informatice ...................................... 126
6.3 Documentarea sistemului........................................................................ 129
6.3.1 Consideraţii generale privind documentarea sistemului.............. 130
6.4 Conversia sistemului............................................................................... 132
Rezumat ................................................................................................ 134
Probleme ............................................................................................... 135
CAPITOLUL VII Exploatarea şi întreţinerea sistemelor informaţionale ............ 136

7.1 Sprijinirea utilizatorilor .......................................................................... 136
7.1.1 Rolul centrelor informaţionale în asistarea utilizatorilor ............ 137
7.1.2 Servicii automate de asistare a utilizatorilor ............................... 139
7.1.3 Sprijinirea utilizatorilor prin birouri speciale (help desk).............. 140
7.1.4 Comunicantul tehnic – o nouă profesie? ..................................... 142
7.2 Închiderea proiectului ............................................................................. 143
7.3 Întreţinerea sistemelor ............................................................................ 144
7.3.1 Realizarea operaţiunii de întreţinere a sistemelor ....................... 145
Rezumat ................................................................................................ 147
Probleme ............................................................................................... 148
CAPITOLUL VIII Particularităţi conceptuale şi tehnice ale analizei şi proiectării orientate-

obiect......................................................................................... 149
8.1 Concepte ale abordării orientate-obiect.................................................. 152
8.1.1 Obiecte şi clase ............................................................................ 153
8.1.2 Identitatea, starea şi comportamentul .......................................... 154
8.1.3 Relaţiile dintre elemente.............................................................. 157
8.1.4 Redefinire în abordarea obiectuală.............................................. 162
8.1.5 Alte concepte ale orientării obiectuale ........................................ 163
8.2 Modelarea orientată-obiect în timpul etapei de analiză.......................... 164
8.2.1 Diagrame ale claselor .................................................................. 164
8.3 Modelarea în etapa de proiectare orientată-obiect.................................. 167
8.3.1 Diagrame de secvenţă .................................................................. 168
Rezumat ................................................................................................ 169
Probleme ............................................................................................... 169
Bibliografie generală .................................................................................... 170
8
9
Mai mult decât proiectarea sistemelor
Lucrarea de faţă continuă demersul prezentării etapelor ciclului de viaţă al sistemelor

informaţionale, început prin volumul „Analiza sistemelor informaţionale”, apărut în 2005, la
Editura Universităţii „Alexandru Ioan Cuza”, Iaşi.
Pentru finalizarea proiectului de dezvoltare a unui sistem, după ce s-a identificat şi
analizat CE trebuie să facă el, este necesar să se stabilească CUM va face, astfel încât să se
atingă obiectivele planului iniţial. Ca sistemul să prindă viaţă, pe baza modelelor conceptuale
şi strategiilor de dezvoltare, se vor parcurge etapele de proiectare, implementare,
documentare, exploatare şi întreţinere, toate reprezentând subiectul acestei cărţi.
Dacă în cadrul primelor etape, cunoscute şi sub numele de microanaliză şi analiză a
sistemului, au fost identificate cerinţele sistemului, atenţia se deplasează către proiectare,
structurată în două subetape, respectiv proiectarea logică şi proiectarea fizică.
În timpul proiectării logice se face trecerea de la prezentarea sistemului existent către
ceea ce se intenţionează a se obţine. Analiştii şi utilizatorii vor prezenta punctul lor comun de
vedere prin specificaţiile tehnice întocmite.
Modul de percepere a noului sistem este redat prin prezentarea tuturor intrărilor, ieşirilor,
interfeţelor şi a dialogurilor. Ele se construiesc pe baza a ceea ce s-a identificat în etapele
anterioare, dar se vor completa cu cerinţele formulate în timpul desfăşurării activităţilor acestei
etape.
Proiectarea logică se derulează prin intermediul a trei subetape:
1. Proiectarea formularelor/formatelor (pentru preluarea datelor) şi a rapoartelor, pe baza
cărora utilizatorii vor avea imaginea intrărilor şi ieşirilor noului sistem.
Formularele/formatele şi rapoartele, indiferent că sunt intrări sau ieşiri, reprezintă piesele
cele mai importante pentru utilizatori. Principalul obiectiv urmărit la proiectarea ieşirilor
este de a prezenta informaţia solicitată într-o formă inteligibilă, locului potrivit, la
momentul oportun şi numai utilizatorilor îndreptăţiţi. În acest sens, la elaborarea
specificaţiilor de proiectare, trebuie avute în vedere următoarele caracteristici: scopul,
destinaţia, frecvenţa, conţinutul, sursa datelor, mediul de transmitere şi controlul.
2. Proiectarea interfeţelor şi a dialogurilor evidenţiază modul de comunicare a
utilizatorului cu softul de sistem. Preluarea intrărilor şi obţinerea ieşirilor se pot efectua în
mod automat, însă, în majoritatea situaţiilor, ele implică intervenţia omului, ceea ce
determină existenţa interacţiunilor dintre utilizator şi calculator. Pentru fiecare intrare se
va proiecta un ecran, care să permită utilizatorilor să introducă datele. Ieşirile, de regulă,
se obţin printr-o succesiune de dialoguri pe care utilizatorii le vor avea cu sistemul. De
asemenea, ei vor interacţiona cu calculatorul în vederea iniţierii operaţiunilor de
prelucrare, scop în care se va proiecta un sistem de meniuri.
3. Proiectarea logică a bazei de date ajută la descrierea structurii standard a acesteia. Spre
deosebire de modelul conceptual al datelor, modelarea logică apelează la tehnologii de
organizare şi prelucrare a datelor, precum şi la criterii de calitate specifice:
completitudine, reducerea redundanţei, reutilizare, flexibilitate. Obiectivul principal al
acestei subetape îl reprezintă elaborarea schemei logice a bazei de date, cu care vor
interacţiona proiectanţii şi programatorii în conceperea şi implementarea programelor. În
prezent, pentru organizarea datelor, modelul relaţional este cel mai utilizat, motiv pentru
care, la modelarea logică a datelor, au fost avute în vedere conceptele şi regulile acestuia.
Subetapele proiectării logice nu trebuie să fie parcurse secvenţial. Ele se află într-o strânsă
interdependenţă.
10
După parcurgerea etapei de proiectare logică, în multe metodologii cunoscută şi ca

proiectare conceptuală sau, adesea, mai simplu, proiectarea sistemelor, o formulare destul de
ambiguă, se trece la o nouă etapă, proiectarea fizică, la rândul ei numită şi proiectare de
detaliu. Ultimul nume este în legătură cu proiectarea generală, o altă variantă de definire a
proiectării logice. De fapt, printr-o astfel de referire se scoate în relief faptul că în timpul
proiectării logice se prezintă o imagine de ansamblu (generală) a sistemului, în timp ce
proiectarea fizică înseamnă o abordare detaliată a acestuia. Cu alte cuvinte, în etapa de
proiectare logică se acumulează informaţiile de natură să sintetizeze cerinţele utilizatorilor
noului sistem, operaţiune prestată de analiştii de sistem, iar în timpul proiectării fizice se
prezintă punctele de vedere ale specialiştilor, cum ar fi cei din domeniile bazelor de date,
securităţii sistemelor, reţelelor de calculatoare, controlului şi auditării sistemelor, programării
ş.a. – pe scurt, ale tehnicienilor.
Proiectarea fizică implică parcurgerea următoroarelor subetape:
1. Proiectarea fizică a fişierelor şi a bazelor de date are ca scop transpunerea schemei
logice a datelor într-un model care să poată fi implementat în SGBD-ul ales.
2. Proiectarea structurii sistemului şi a programelor, prin care se intră în domeniul de
activitate al proiectanţilor de software şi al programatorilor. Proiectantul are ca principală
misiune definirea şi structurarea componentelor care vor forma un tot unitar, astfel încât
să se obţină un proiect software operaţional. Pentru transpunerea în realitate a proiectului,
după proiectanţii de soft, intervin programatorii. Ei controlează intrările, prelucrările,
stocările şi ieşirile din sistem, prin intermediul programelor. În proiectarea programelor se
identifică două mari activităţi: proiectarea arhitecturii şi proiectarea logicii modulelor
programelor.
Urmează etapa de implementare, care începe cu o planificare riguroasă şi se continuă cu
realizarea şi testarea programelor (implementarea propriu-zisă), pregătirea locurilor de muncă
şi a spaţiilor în care vor fi instalate echipamentele, testarea acestora, selectarea şi instruirea
personalului care să asigure atât exploatarea sistemului, cât şi întreţinerea acestuia, finalizarea
documentaţiei, testarea finală, conversia de la vechiul sistem la cel nou.
În finalul etapei de implementare, se asigură trecerea stării componentelor vechiului
sistem în cel nou, prin operaţiunea de conversie.
După conversia sistemului, se trece la etapa de exploatare şi întreţinere. Ea începe
imediat ce sistemul devine operaţional şi continuă până când funcţionalităţile şi performanţele
lui nu mai corespund obiectivelor firmei şi cerinţelor utilizatorilor.
Şi pentru că sistemele se adaptează tendinţelor din lumea afacerilor, metodele şi
instrumentele folosite la dezvoltarea lor trebuie să se plieze şi ele pe cerinţele domeniului. În
acest context, se constată un mixaj al aşa-ziselor metode tradiţionale de dezvoltare cu cele
orientate-obiect, motiv pentru care, în ultimul capitol, am făcut o prezentare succintă a
principalelor particularităţi conceptuale şi tehnice ale analizei şi proiectării orientate-obiect.
Iaşi, 2010 Autorii,

Dumitru OPREA
Florin DUMITRIU
Gabriela MEŞNIŢĂ
PROIECTAREA FORMULARELOR/FORMATELOR ŞI A RAPOARTELOR 11
CAPITOLUL I
Proiectarea formularelor/formatelor
şi a rapoartelor
Obiective:
• Explicarea conceptelor formular/format şi raport
• Identificarea şi descrierea ieşirilor din sistem
• Clasificarea ieşirilor din sistem
• Înţelegerea importanţei controlului integrităţii ieşirilor din sistem
• Descrierea regulilor şi recomandărilor de proiectare a ieşirilor
• Prezentarea unor criterii de apreciere a calităţii informaţiilor incluse în formulare/formate şi
rapoarte
• Descrierea procesului de proiectare a formularelor şi rapoartelor
• Prezentarea unui model de întocmire a specificaţiilor de proiectare a formularelor şi rapoartelor
Aşa cum a fost finalizată etapa de analiză, rezultă că intrările şi ieşirile au fost identificate
şi prezentate în subfaza de structurare a cerinţelor. Oricum, în acel moment, nu s-au prezentat
toate detaliile privind formularele/formatele, rapoartele şi răspunsurile la întrebări. S-a insistat
mai mult asupra identificării acestora şi descrierii lor. De exemplu, fiecare formular/format va
fi asociat unui flux al datelor ce intră într-un proces al diagramelor fluxurilor de date (DFD),
iar fiecare formular/format de ieşire sau raport se poate regăsi într-un flux al datelor generate
de un proces al DFD.
Se poate concluziona că datele elementare conţinute de fluxurile de date asociate
înseamnă, în acelaşi timp, şi conţinuturile formularelor/formatelor de intrare sau ale rapoartelor
şi răspunsurilor la întrebări. De asemenea, datele formularelor/ formatelor sau rapoartelor pot
fi date elementare ale locurilor de stocare sau pot fi calculate pe baza acestora şi a altor
elemente generate de sistem.
În acest capitol ne vom concentra asupra proiectării intrărilor şi ieşirilor din sistem, fie ele
formulare/formate sau rapoarte, fără a ne preocupa de interacţiunile dintre utilizator şi
calculator, inerente în preluarea datelor de intrare sau în generarea ieşirilor. Această din urmă
categorie de aspecte vor fi dezbătute pe larg în capitolul următor.
1.1 Aspecte generale ale proiectării formularelor/formatelor şi a

rapoartelor
Un formular/format poate fi un document primar care conţine unele date predefinite,

cărora li se adaugă altele ce urmează a fi completate în rubrici special rezervate. Din punct de
vedere structural, un formular/format este un element tipărit/afişat, cu antet şi alte componente
pretipărite, precum şi cu spaţii (rubrici) pentru completarea cu date.
Într-un sistem de prelucrare automată a datelor, formatul este asociat imaginii afişate pe
ecran, identică formularului tipărit. Datele afişate din formate sunt cunoscute sub numele de
date constante, în timp ce elementele ce vor fi completate sunt numite date variabile.
Majoritatea formularelor au în structură patru elemente determinante: introducerea,
instrucţiunile, partea principală (corpul) şi concluziile.
12 PROIECTAREA SISTEMELOR INFORMAŢIONALE
Introducerea, în general, trebuie să apară la începutul formularului şi să conţină titlul

formularului, numărul formularului şi, dacă formularul trebuie distribuit altcuiva, numele şi
adresa destinatarului.
Instrucţiunile sunt, de regulă, de două tipuri. Ele precizează fie modul de completare a
formularului, fie destinaţia lui după completare. Uneori numele elementelor de completat sunt
atât de clare încât nu mai necesită informaţii speciale pentru completare. Formularele cu un
pronunţat caracter tehnic necesită mai multe informaţii în partea principală sau pe verso.
Instrucţiunile în legătură cu ceea ce trebuie făcut cu formularul trebuie să fie foarte clare,
specificându-se pentru fiecare exemplar unde trebuie să ajungă. În proiectarea acestor
formulare trebuie să se urmărească o formă cât mai simplă de realizare.
Partea principală este cea care concură la utilizarea unor formulare cât mai simple.
Relaţiile logice dintre căsuţe trebuie să fie grupate; căsuţele şi coloanele trebuie să fie foarte
clar conturate şi, evident, locul unde trebuie completate, mai ales când datele din ele vor fi
supuse prelucrării automate.
Concluziile apar la sfârşit şi se referă la înregistrarea informaţiilor cu privire la dispoziţiile
finale şi/sau la aprobările necesare în legătură cu operaţiile consemnate, incluzând semnăturile
şi data. Dacă este un formular cu operaţiuni financiare, acesta trebuie să conţină şi rubrici
pentru totaluri.
Un raport este un document economic în care sunt incluse, de regulă, date predefinite,
ceea ce înseamnă că poate fi numit şi document pasiv, fiind folosit exclusiv pentru a fi citit sau
vizualizat.
Obiectivul prezentării detaliate a ieşirilor este şi acela de a determina formatul şi
conţinutul tuturor rapoartelor imprimate/afişate şi ale documentelor furnizate de sistem, deşi,
după cum se va observa ulterior, sistemele flexibile trebuie să ofere şi tipuri de rapoarte cu
structuri definite ulterior implementării.
Formularele/formatele şi rapoartele pot fi regăsite în sistemele informaţionale economice
atât ca intrări, cât şi ca ieşiri, deşi, de regulă, documentele apar ca intrări, iar rapoartele ca
ieşiri. Intrările în sistem sunt mai puţin sub controlul echipei de proiectare, ele fiind primite în
forma transmisă de sistemul sursă. În schimb, echipa de proiectare trebuie să se preocupe, în
mod deosebit, de proiectarea ieşirilor, fie ele formate/formulare sau rapoarte. Sunt exceptate
acele ieşiri care au format şi conţinut reglementat, cum ar fi „Factura” sau „Jurnalul de
vânzări”. Din acest motiv, pe parcursul acestui capitol, formularele/formatele şi rapoartele vor
fi referite, adesea, ca ieşiri ale sistemului.
Dacă tratarea intrărilor şi obţinerea ieşirilor necesită interacţiunea om-calculator, atunci
echipa de proiectare trebuie să se preocupe şi de proiectarea dialogurilor. Acest subiect va fi
abordat separat, în capitolul următor.
1.2 Caracteristicile generale şi clasificarea ieşirilor
Proiectarea ieşirilor constituie poate cea mai importantă activitate în dezvoltarea

sistemelor informaţionale, deoarece obţinerea lor reprezintă scopul general al oricărui sistem
informaţional. Utilizatorii vor aprecia noul sistem mai ales prin prisma calităţii ieşirilor.
Obiectivul principal al proiectării ieşirilor este de a prezenta informaţia solicitată într-o formă
inteligibilă, unde trebuie, când trebuie şi cui trebuie.
Realizarea acestui obiectiv impune acordarea unei atenţii deosebite caracteristicilor
generale ale ieşirilor din sistem, prezentate sintetic în tabelul 1.1, majoritatea lor reprezentând
în acelaşi timp criterii de clasificare. În fapt, aceste caracteristici stau la baza formulării
specificaţiilor de proiectare a ieşirilor, după cum vom vedea ulterior.
Tabel nr. 1.1 – Caracteristicile generale şi clasificarea

ieşirilor din sistemele informaţionale
Caracteristica Descriere Clasificarea ieşirilor
Scopul Descrierea motivului realizării – monitorizarea proceselor sau a activităţilor
fiecărei ieşiri. – controlul activităţilor
– luarea deciziilor
– transferul informaţiilor în afara firmei
– întocmirea altor documente sau rapoarte
Destinatarii Identificarea şi descrierea persoanelor – interne
care vor utiliza ieşirile. – externe
– hibride (documente în circuit)
Frecvenţa Specificarea momentelor la care – rapoarte programate
trebuie generate ieşirile. – rapoarte generate de excepţii
– rapoarte la cerere
– analize ad-hoc
Formatul Descrierea modalităţii de organizare – text
şi prezentare a informaţiilor. – tabelară
– grafică
– zone predefinite
Conţinutul Descrierea informaţiilor care vor fi – rapoarte detaliate
furnizate în fiecare ieşire. – rapoarte de sinteză
– rapoarte dinamice (prin combinarea celorlalte două)
Sursa datelor Identificarea căilor de obţinere a – baze de date
datelor necesare pentru generarea – ieşirile din alte procese de prelucrare
ieşirilor. – surse externe
Mediul de Alegerea modalităţii de generare şi – tipărite
transmitere transmitere a ieşirilor. – afişate pe ecran
– transmise prin mesaje electronice
– sistemele COM
– audio
– video
– hypertext
Controlul Definirea procedurilor şi – cu restricţii de întrebuinţare
mecanismelor necesare pentru – publice
asigurarea confidenţialităţii,
integrităţii accesibilităţii controlate a
ieşirilor.
1.2.1 Scopul ieşirilor

Definirea scopului presupune cunoaşterea exactă a motivului pentru care a fost solicitată
şi pentru care va fi utilizată ieşirea respectivă. Dacă documentele primare sunt concepute
pentru consemnarea diferitelor tranzacţii, interne sau externe, rapoartele pot avea utilizări
diverse, în cadrul sistemului sau în afara acestuia:
• monitorizarea proceselor sau a activităţilor din cadrul firmei. „Situaţia vânzărilor
pe categorii de produse” poate fi utilizată în urmărirea şi evaluarea creşterii
vânzărilor în urma unei campanii de marketing.
• controlul activităţilor economice desfăşurate în cadrul firmei. „Balanţa analitică a
stocurilor” poate fi utilizată pentru verificarea corectitudinii şi completitudinii
înregistrării tranzacţiilor privind stocurile, atât în contabilitate, cât şi în evidenţa
organizată la nivelul depozitelor.
• luarea deciziilor pe diferite niveluri ierarhice. De exemplu, „Situaţia vânzărilor pe
zone geografice” este utilă în definirea strategiei de distribuţie.
• transferul unor informaţii în afara organizaţiei. În afara raportărilor statistice, aici
pot fi incluse şi ofertele de produse sau „Situaţia facturilor neachitate” transmise
clienţilor.
• prelucrarea informaţiilor conţinute în ieşiri, în vederea întocmirii unor documente
sau a altor rapoarte. Aici poate fi inclus „Centralizatorul statelor de salarii”, pe baza
căruia se întocmeşte „Ordinul de plată” pentru achitarea obligaţiilor legale către

bugetul statului, cel al asigurărilor sociale şi alte bugete. Un alt exemplu îl reprezintă
„Jurnalul vânzărilor”, utilizat împreună cu „Jurnalul cumpărărilor” pentru întocmirea
„Decontului TVA”.
În funcţie de scopul ieşirilor se vor defini unele aspecte de proiectare a lor, cum ar fi
ordinea de prezentare a coloanelor, sortarea informaţiilor, totalurile ce trebuie incluse, suportul
pe care va fi transmisă ieşirea şi frecvenţa lor.
1.2.2 Destinatarii ieşirilor

Cunoaşterea destinatarilor serveşte la o bună proiectare a ieşirilor din sistem. Identificarea
şi descrierea destinatarilor, precum şi a sarcinilor de lucru ale acestora, vor permite o mai bună
înţelegere a scopului în care va fi utilizată fiecare ieşire. În general, sistemele informaţionale
servesc o mare varietate de utilizatori, care realizează sarcini şi operaţiuni diverse în cadrul
firmei, ceea ce face dificilă personalizarea rapoartelor pentru fiecare utilizator în parte.
Analistul va trebui să ia în considerare eficienţa fiecărei ieşiri, respectiv raportul beneficii-
costuri, şi să combine cerinţele informaţionale ale utilizatorilor cu costurile în vederea
proiectării unor ieşiri cât mai apropiate de cerinţele acestora.
De asemenea, informaţiile despre destinatarii ieşirilor vor ghida proiectarea mecanismelor
pentru controlul generării şi distribuirii lor, precum şi alegerea mediilor de transmitere.
Destinatarii ieşirilor se regăsesc în diagramele fluxurilor de date sub forma entităţilor
externe către care se îndreaptă fluxurile de date, iar descrierea lor se regăseşte în depozitul
metadatelor din produsele CASE.
Din punctul de vedere al destinatarilor, pot fi identificate două tipuri principale de ieşiri:
interne şi externe. Ieşirile interne sunt rezultatul unui proces de prelucrare şi rămân în cadrul
sistemului, fiind folosite de utilizatori pentru luarea unor decizii sau controlul unor activităţi.
În Sistemul de evidenţă a relaţiilor cu furnizorii, „Situaţia datoriilor scadente faţă de furnizori”
poate servi în luarea deciziei privind plăţile ce se vor efectua, iar „Balanţa analitică a
furnizorilor” va permite controlul corectitudinii înregistrării operaţiunilor economice privind
furnizorii.
Ieşirile externe se referă la documentele primare şi acele rapoarte care depăşesc graniţele
sistemului şi, în unele cazuri, pe cele ale firmei. De cele mai multe ori, ele au rolul de
confirmare a realizării unei acţiuni sau de declanşare a unui proces în cadrul sistemului
destinatar. De exemplu, Sistemul de urmărire a producţiei întocmeşte „Raportul de producţie”
pentru a confirma Sistemului informaţional contabil producţia realizată în fiecare lună. „Avizul
de însoţire a mărfurilor” şi „Situaţia cheltuielilor materiale pe comenzi de producţie”, generate
de Sistemul de gestiune a stocurilor vor reprezenta intrări pentru Sistemul de desfacere,
respectiv Sistemul de calculaţie a costurilor, unde vor fi declanşate procesele de întocmire a
facturii, respectiv actualizarea fişelor de postcalcul.
O atenţie deosebită trebuie acordată proiectării ieşirilor destinate utilizatorilor din afara
firmei, deoarece ele reprezintă documente oficiale. În această categorie se cuprind ofertele
transmise clienţilor, rapoartele financiare destinate acţionarilor firmei sau documentele legale,
precum facturile şi poliţele de asigurare. Astfel de ieşiri trebuie obţinute în condiţii grafice şi
color de calitate înaltă.
O a treia formă ar putea fi una hibridă, cunoscută şi sub numele de documente în circuit,
ceea ce ar însemna producerea lor într-un sistem, părăsirea lui şi revenirea în sistem sub o
formă îmbunătăţită, ca intrări. Aici pot fi incluse cupoanele firmelor care combină oferta lor cu
potenţiala comandă a clientului (de regulă, detaşabilă sau returnabilă la emitent) sau carnetele
cu file CEC. În cele mai moderne forme se apelează la documente ce pot fi citite automat de
sistemele de prelucrare automată a datelor, care folosesc cititoare de coduri bară, de caractere
scrise cu cerneală magnetică sau recunoscute pe cale optică.
Un alt aspect de proiectare, strâns legat de destinatarii ieşirilor, îl reprezintă numărul de

exemplare. Atunci când pentru o aceeaşi ieşire există mai mulţi destinatari, ea trebuie generată
în mai multe exemplare. Dacă majoritatea documentelor sunt întocmite în mai multe
exemplare, de exemplu trei pentru „Factură” şi două pentru „Bonul de consum”, rapoartele
sunt generate, de regulă, într-un singur exemplar. Există şi excepţii: „Lista de inventar” şi
„Statul de salarii” sunt întomite în două exemplare.
1.2.3 Frecvenţa ieşirilor

Eficacitatea rapoartelor depinde de oportunitatea lor. Dacă ele nu sunt furnizate la timp,
atunci ele nu vor mai contribui la atingerea scopului pentru care au fost proiectate. Frecvenţa
rapoartelor poate varia de la cele solicitate la cerere, până la cele zilnice, săptămânale, lunare,
trimestriale sau anuale.
În funcţie de momentul elaborării lor, rapoartele pot fi clasificate în patru categorii:
rapoarte programate, analize neprogramate, rapoarte la cerere şi rapoarte declanşate de
excepţii. O prezentare sintetică a acestor tipuri de rapoarte este redată în figura 1.1.
Rapoarte ad-hoc (Analize neprogramate)
• Sprijină managerii în aflarea răspunsurilor
la întrebările What-If
• Realizate pe baza programelor statistice
de modelare
• Utile în planificarea decizională
Rapoarte de excepţii
• Semnalează doar cazurile ieşite de sub
control
• Pot fi liste de erori sau rapoarte obişnuite
Rapoarte la cerere
• Generate la cererea unei persoane
• Uşor de realizat prin limbaje de interogare
• Acoperă cererea spontană de informaţii
Rapoarte programate
• Realizate la termene prestabilite
• Pot fi zilnice, săptămânale, decadale,
chenzinale ş.a.
• Mult solicitate de utilizatori
Fig. 1.1 Caracterizarea tipurilor de rapoarte necesare procesului managerial

Rapoartele programate (la termen) sunt elaborate la anumite intervale regulate, au un
conţinut predeterminat şi formatul lor este dinainte stabilit. Aici se încadrează rapoartele
realizate zilnic, săptămânal, lunar, trimestrial sau annual. De exemplu, „Registrul de casă” se
întocmeşte zilnic, „Statul de plată al salariilor” şi „Centralizatorul statelor de plată al
salariilor” se întocmesc lunar, iar diferitele anexe la bilanţ se întocmesc anual. Alte exemple de
rapoarte programate sunt: analizele săptămânale ale vânzărilor, raportul lunar de producţie,
balanţa sintetică de verificare, situaţia amortizării lunare a mijloacelor fixe, dările de seamă
financiar-contabile.
Analizele neprogramate, cu rol special, deseori numite şi rapoarte ad-hoc, nu au
conţinutul şi forma dinainte stabilite şi nu sunt realizate conform unor programări anterioare.
De fapt, ele sunt elaborate ca răspuns la întrebările managerilor privind anumite probleme sau
cerinţe ce nu au putut fi identificate pe timpul dezvoltării sistemului, motiv pentru care ele nu
au fost proiectate anterior. Pentru a permite obţinerea unor astfel de rapoarte, sistemul trebuie
să ofere facilităţi grafice prin care utilizatorii să poată lansa interogări SQL şi construi
rapoarte.
Rapoartele declanşate de excepţii conţin informaţii filtrate în legătură cu anumite

evenimente sau tranzacţii care implică depăşirea unor valori prestabilite, şi care solicită o
atenţie specială. Ele au un conţinut predeterminat şi un format anume şi sunt generate în
momentul în care se realizează excepţia prevăzută. Un exemplu îl reprezintă „Situaţia depăşirii
costurilor”, în care sunt incluse poziţiile bugetare la care s-a înregistrat depăşirea cheltuielilor
planificate, şi pe baza căreia managerul va putea lua deciziile şi măsurile corective. Acest
raport va fi generat atunci când se înregistrează depăşirea cheltuielilor bugetate, însă, dacă
astfel de situaţii se petrec cu regularitate, atunci el va deveni un raport programat, ce va fi
solicitat periodic, eventual lunar. Aşadar, unele rapoarte generate de excepţii pot fi elaborate
periodic.
Alte exemple de rapoarte declanşate de excepţii sunt: „Lista stocurilor fără mişcare sau cu
mişcare lentă”, „Situaţia rebuturilor înregistrate în procesul de producţie”, „Lista clienţilor cu
creanţe scadente neachitate”, „Lista imputaţiilor pentru lipsă din gestiune”.
Rapoartele la cerere au, de asemenea, conţinut şi formă predeterminate, dar sunt
elaborate numai ca răspuns la cererea managerilor.
Rapoartele declanşate de excepţii şi cele la cerere dau puterea sistemelor informaţionale
de a fi eficiente în sprijinirea conducerii.
1.2.4 Formatul ieşirilor

Formatul ieşirilor defineşte modalitatea de organizare şi prezentare a informaţiilor, astfel
încât ele să fie atrăgătoare, uşor de înţeles şi utilizat. De multe ori, informaţii oportune, corecte
şi pertinente nu pot fi valorificate deplin, datorită unei prezentări inadecvate. Informaţiile
trebuie să fie clare, precise, ordonate, prezentate într-o modalitate adecvată şi pe un suport
accesibil. Cele mai utilizate forme de prezentare sunt:
• tabelară; este cea mai frecvent întâlnită şi presupune organizarea informaţiilor în linii
şi coloane; de cele mai multe ori această formă înlesneşte pe cea grafică;
• zone predefinite, caz în care informaţiile sunt organizate în mai multe zone predefinite
pe hârtie sau pe ecran, similar paginilor Web sau ziarelor obişnuite;
• grafică, în care datele numerice sunt prezentate prin unul din numeroasele tipuri de
grafice.
În unele situaţii, cea mai bună modalitate de prezentare a informaţiilor poate rezulta din
combinarea celor trei forme. Asupra regulilor de prezentare a informaţiilor în formă tabelară
sau grafică vom reveni în paragrafele următoare.
Un alt element de proiectare, legat de definirea formatului ieşirilor, priveşte dimensiunea
paginii, în cazul tipării lor, sau rezoluţia de afişare, atunci când ele vor fi vizualizate pe ecran.
Formatele de pagină standard utilizate frecvent sunt A3, A4 şi A5. În ceea ce priveşte rezoluţia
de afişare, deşi aceasta evoluează extrem de rapid, este recomandată utilizarea standardului
640x480 pixeli, pentru a fi siguri că toţi utilizatorii vor putea vizualiza ieşirile din sistem.
1.2.5 Conţinutul
Această caracteristică este considerată adesea drept cea mai importantă. Ea defineşte
informaţiile ce vor fi incluse într-un document sau raport, în funcţie de scopul utilizării lor.
Se spune că managerii au nevoie de şase categorii mari de informaţii1: curente, de
atenţionare, indicatori de bază, situaţionale, clevetiri (bârfe), externe.
Informaţiile curente sunt cele ce sintetizează starea generală a afacerii sau organizaţiei, pe
componente funcţionale (aprovizionare, desfacere, producţie ş.a.). Ele sunt informaţii care vin
de la subordonaţi sau colaboratori de birou.
1. Alter, S. – Op. cit., pp. 147-148; Mintzberg, H. – „The Manager’s Job: Folklore and Fact”, in Harvard Business
Review 53, nr. 4, July-August 1975, pp. 49-61.
Atenţionările sunt relatări despre lucruri care necesită intervenţia promptă a managerilor
sau schimbarea unui plan de acţiune.
Indicatorii de bază sunt măsuri ale principalelor aspecte privind performanţele
organizaţiei, cum ar fi vânzări/magazin, vânzări/vânzător, venituri/cheltuieli de reclamă ş.a. Se
pot folosi valori numerice sau grafice sau combinaţii ale lor.
Informaţiile situaţionale reflectă starea curentă a unor proiecte importante, a problemelor,
a comenzilor care trebuie să fie aduse la cunoştinţa managerilor.
Clevetirile (bârfele) sunt informaţii neformale ce pot fi culese din diverse locuri, dar care
pot fi utile managerilor.
Informaţiile externe, după cum au fost definite anterior, sunt cele din afara unităţii sau a
unui departament.
Principalele atribute calitative ale ieşirilor, din punctul de vedere al conţinutului, sunt
exactitatea şi exhaustivitatea informaţiilor. Utilizatorilor trebuie să li se furnizeze doar acele
informaţii de care are nevoie, fără a-i sufoca cu un şuvoi informaţional din care să fie
incapabili să deceleze informaţia necesară sau să le solicite eforturi inutile şi păguboase. De
asemenea, dacă se furnizează prea puţine informaţii, atunci raportul nu va mai fi de folos
utilizatorilor.
Prin prisma gradului de detaliere a informaţiilor conţinute, rapoartele pot fi detaliate, de
sinteză sau dinamice.
Rapoartele detaliate conţin informaţii cu un nivel minim de agregare şi filtrare, fiind
utilizate în activitatea de zi cu zi de către angajaţii din firmă. De regulă, în astfel de rapoarte se
include câte o linie pentru fiecare înregistrare prelucrată din baza de date. Unele rapoarte
detaliate pot conţine informaţii referitoare la o singură tranzacţie sau obiect; în „Fişa analitică”
a unui client se reţine câte o linie pentru fiecare înregistrare din baza de date care priveşte o
livrare sau o încasare pentru acel client. Alte rapoarte prezintă un grup de tranzacţii. De
exemplu, „Situaţia lunară a vânzărilor” poate conţine câte o line pentru fiecare document de
livrare emis în luna respectivă, şi pentru fiecare produs cuprins în document.
O bună proiectare a rapoartelor detaliate implică, de cele mai multe ori, prevederea unuia
sau mai multor niveluri de total. În „Situaţia lunară a vânzărilor”, datele pot fi grupate pe
clienţi şi pe documente, fiind prevăzute, în afara totalului general, totalul vânzărilor pe clienţi
şi totalul valoric pentru fiecare document, în literatura de specialitate fiind cunoscute ca sume
de control major, intermediar şi minor.
Rapoartele de sinteză sunt generate pentru a oferi utilizatorilor informaţii agregate şi
filtrate, fără a mai fi prezentate unele detalii, care nu le sunt necesare. Înformaţiile conţinute în
aceste rapoarte sunt obţinute prin prelucrarea şi însumarea înregistrărilor din baza de date, iar
fraza SELECT, prin care se extrag şi se prelucrează datele necesare, va include clauza GROUP
BY.
Rapoartele de sinteză sunt utilizate, de regulă, de către managerii de pe nivelurile
superioare de conducere. Directorul de vânzări poate fi interesat de „Situaţia lunară a
vânzărilor”, numai că informaţiile vor fi prezentate la un nivel de agregare superior celui
discutat anterior. Dacă este solicitată „Situaţia vânzărilor pe clienţi”, atunci raportul va conţine
câte o linie pentru fiecare client, în care sunt însumate toate documentele de livrare pentru un
client. „Raportul vânzărilor lunare” presupune un nivel de agregare şi mai mare, reţinându-se
câte o linie pentru fiecare lună calendaristică, care va conţine totalul vânzărilor din luna
respectivă.
Rapoartele dinamice presupun combinarea rapoartelor de sinteză cu cele detaliate, însă
ele pot fi afişate doar pe ecran. Aceste rapoarte oferă utilizatorului posibilitatea schimbării
interactive a nivelului de detaliere a informaţiilor, dacă ele sunt proiectate în acest sens.
Rapoartele dinamice pot fi create pe baza a două tehnici: „drill up-drill down” şi cea bazată pe
legare.
Prin tehnica drill up-drill down, informaţiile, organizate după o anumită ierarhie, pot fi
afişate pe diferite niveluri de detaliere, aranjate în cascadă. Aceste tipuri de rapoarte sunt
frecvent întâlnite în aplicaţiile OLAP (On-Line Analytical Processing), care extrag datele
stocate în depozite de date (data warehouse) sau baze de date multidimensionale, şi care sunt
utilizate în analize multidimensionale.
„Raportul privind situaţia profitului” din figura 1.2 este prezentat la nivelul maxim de
detaliere pentru primele trei trimestre, însă el poate fi reconfigurat de către utilizator, astfel
încât să fie afişate numai informaţiile la nivel de trimestre sau ani. Selectarea cu mouse-ul a
„minusului” din partea stânga va determina ascunderea detaliilor de pe nivelurile inferioare,
similar cu parcurgerea structurii de directoare în Windows Explorer, operaţiune numită drill-
up. În locul semnului „minus” va apărea semnul „plus” , prin selectarea căruia se va reveni la
afisarea detaliilor de pe nivelul imediat inferior, operaţiune numită drill-down. Afişarea datelor
detaliate pe lunile trimestrului IV se poate face prin selectarea cu mouse-ul a „plusului” din
dreapta. De exemplu, pentru afişarea doar a informaţiilor relative la cele patru trimestre ale
anului 1999 vor trebui selectate cele patru „minusuri”, situate în partea stângă a liniilor
aferente.
Fig. 1.2 Exemplu de raport ce utilizează tehnica „drill up-drill down”
Cea de-a doua tehnică presupune legarea rapoartelor, în mod asemănător cu documentele
accesate pe Internet cu ajutorul browser-elor. Această tehnică permite utilizatorilor să coreleze
informaţiile dintr-un raport cu un altul mai detaliat. În figura 1.3 este prezentată „Balanţa
analitică a stocurilor de materiale”, iar prin apăsarea tastei <ENTER> sau efectuarea „dublu
clic” pe linia curentă se poate declanşa afişarea „Fişei analitice” pentru materialul
corespunzător. În fişă pot fi vizualizate toate intrările şi ieşirile din stoc pentru acel material, în
perioada curentă. Aceeaşi tehnică poate fi utilizată pentru legarea unui raport sintetic, privind
vânzările lunare pe categorii de produse, de un altul, detaliat, în care să fie prezentate vânzările
lunare pentru o anumită categorie, însă pe fiecare produs în parte.
Un alt aspect dinamic al rapoartelor afişate pe ecran constă în posibilitatea vizualizării
datelor din perspective diferite. De exemplu, situaţia vânzărilor poate fi afişată pe regiuni şi
categorii de produse sau pe regiuni şi pe perioade de timp.
Rapoartele tipărite pot fi şi ele organizate într-o manieră asemănătoare celor dinamice,
însă costurile vor fi mult mai mari, ceea ce poate afecta eficienţa informaţiilor furnizate.
O altă specificaţie de proiectare, strâns legată de conţinutul rapoartelor, este secvenţa sau
ordinea de prezentare informaţiilor. Alegerea ordinii de prezentare depinde de scopul ieşirilor.
Optarea pentru criterii de ordonare neadecvate poate determina eşecuri în atingerea scopului
urmărit. De exemplu, ordonarea alfabetică a „Situaţiei costurilor” după denumirea elementelor

de cost nu va evidenţia elementele care înregistrează un nivel mare al costurilor, iar utilizatorul
poate fi indus în eroare dacă el trebuie să ia unele decizii privind reducerea costurilor. În plus,
oamenii au tendinţa de a acorda o atenţie mai mare acelor elemente care sunt prezentate în
prima parte a rapoartelor.
Biroul Contabilitate
Balanţa analitică a stocurilor pe luna aprilie 2005
Gestiunea: Materii prime şi materiale
Nr. Cod Denumire UM Pret Stoc Sold Intrari Ieşiri Stoc Sold
crt. material material iniţial iniţial Cantitativ Valoric Cantitativ Valoric final final
1 220006 Balama tip banda buc 188.500 122 22.997.000 75 14.137.500 112 21.112.000 85 16.022.500
2 220014 Ornament Bis buc 74.320 35 2.601.200 40 2.972.800 25 1.858.000 50 3.716.000
3 220022 Broasca simpla buc 98.100 50 4.905.000 88 8.632.800 98 9.613.800 40 3.924.000
4 220037 Furnir stejar mp 212.000 115 24.380.000 220 46.640.000 235 49.820.000 100 21.200.000
5 220045 Furnir cires mp 179.500 25 4.487.500 33 5.923.500 30 5.385.000 28 5.026.000
6 220053 Lac kg 23.500 360 8.460.000 864 20.304.000 982 23.077.000 242 5.687.000
7 220061 Bait luciu kg 31.200 88 2.745.600 110 3.432.000 120 3.744.000 78 2.433.600
Fig. 1.3 Exemplu de utilizare a tehnicii legării rapoartelor
De multe ori, satisfacerea unor cerinţe diverse impune ca în acelaşi raport datele să fie
ordonate după unele criterii sau altele. De exemplu, „Balanţa analitică a stocurilor” poate să
aibă datele ordonate pe gestiuni, dacă ea va fi utilizată pentru verificarea fişelor de magazie,
sau pe conturi de evidenţă, dacă se verifică corectitudinea înregistrărilor în contabilitate, prin
compararea ei cu „Balanţa de verificare sintetică”. Diferitele cerinţe de ordonare pentru acelaşi
raport necesită proiectarea unei secvenţe de dialoguri, prin care utilizatorul să poată alege
criteriile de ordonare. Problematica proiectării dialogurilor va fi tratată în capitolul următor.
1.2.6 Sursa datelor

În majoritatea cazurilor, sursa pentru obţinerea ieşirilor o constituie tabelele bazei de date,
reprezentate în diagrama fluxurilor de date prin locurile de stocare. Astfel, procesele de
prelucrare ce au drept scop obţinerea de rapoarte vor include una sau mai multe operaţiuni de
citire, puse în evidenţă prin fluxuri de date dinspre locurile de stocare către procesele
respective. Pentru fiecare flux de citire, în depozitul metadatelor, se vor specifica detaliile
privind câmpurile accesate şi înregistrările care vor fi extrase pentru prelucrare.
În alte situaţii, pentru generarea unei ieşiri, mai ales a documentelor, se folosesc drept
sursă ieşirile din alte procese de prelucrare. Întocmirea „Decontului TVA” se face pe baza
„Jurnalului de cumpărări” şi a „Jurnalului de vânzări”, obţinute prin alte două procese de
prelucrare.
Atunci când pentru obţinerea ieşirilor sunt necesare date din surse externe, analistul va
trebui să aleagă cea mai bună metodă de accesare şi prelucrare. Un asemenea caz va fi pus în
evidenţă, în diagrama fluxurilor de date, printr-un flux extern ce intră în procesul reţinut pentru
prelucrarea acestor date. Sursele externe pot face referire la locurile de stocare gestionate de
alte sisteme informaţionale din firmă sau de baze de date publice.
Din punctul de vedere al echipei manageriale, informaţiile pot fi văzute după sursele
acestora. Sintetic, ele sunt redate în tabelul 1.2.
Tabel nr. 1.2 – Surse comune ale informaţiilor

Surse de informaţii
Tip informaţie
Interne Externe
Formală (oficială), bazată Indicatorii principali obţinuţi din Baze de date publice
pe s.p.a.d. diverse sisteme de evidenţă ale
firmei
Formală (oficială), bazată Planuri, rapoarte, procese-verbale Rapoarte pe ramuri, cărţi, reviste
pe documente ş.a.
Formală (oficială), verbal şedinţe programate Forumuri pe domenii
Informală Conversaţiile la masă, culese pe Expoziţii, târguri, contacte
timpul deplasărilor ş.a. personale ş.a.
1.2.7 Mediul de generare şi transmitere a ieşirilor

Una dintre activităţile specifice proiectării ieşirilor priveşte alegerea modului de
prezentare a informaţiilor. Deşi majoritatea ieşirilor sunt tipărite pe hârtie sau sunt afişate pe
ecran, există şi alte medii de transmitere a informaţiilor, precum cele audio şi video, care au un
impact imens asupra modului în care utilizatorii comunică. Este posibil ca ieşirile să fie
solicitate în mai multe forme, caz în care analistul va trebui să aibă în vedere aspecte
suplimentare la proiectare, precum cele specifice fiecărui mediu de transmitere şi tehnologiilor
utilizate.
În continuare, vom face o succintă descriere a principalelor tipuri de ieşiri, în funcţie de
mediul utilizat pentru prezentarea lor.
Ieşirile tipărite
Deşi, de mai mulţi ani, se vorbeşte despre biroul „fără hârtie” sau biroul digital, având
drept argumente progresele înregistrate în domeniul tranzacţiilor şi al documentelor
electronice, forma tipărită rămâne cea mai frecvent utilizată. Ieşirile tipărite au avantajul de a fi
„portabile”, mai comode, motive pentru care cei mai mulţi utilizatori vizualizează mai întâi un
raport pe ecran, după care îl tipăresc. În unele cazuri tipărirea constituie încă singura formă
viabilă de generare a ieşirilor, cum este cazul facturilor sau cel al documentelor în circuit.
Desigur că utilizarea hârtiei pentru generarea ieşirilor creează unele probleme
organizaţiilor, dar şi mediului înconjurător. Cheltuielile privind obţinerea, arhivarea şi
regăsirea informaţiilor stocate pe hârtie sunt mult superioare celorlalte forme. De aceea, multe
firme îşi pun problema transpunerii documentelor din formatul pe hârtie în cel electronic, de
exemplu prin utilizarea scanner-elor, urmărind reducerea cheltuielilor şi regăsirea mai rapidă a
informaţiilor.
Datorită progreselor înregistrate în ultimii ani de tehnologia iprimării, astăzi există o
varietate mare de imprimante, în funcţie de preţ, rezoluţie, viteza de imprimare şi capacitatea
de memorie. Chiar dacă tehnologia imprimantelor cu jet de cerneală şi a celor bazate pe laser s-
a impus în ultimii ani, imprimantele matriciale rămân încă o soluţie viabilă, mai ales pentru
rapoartele mari sau solicitate des.
Ieşirile afişate pe ecran
Odată cu îmbunătăţirea performanţelor şi reducerea preţului monitoarelor, ecranul a
devenit, şi va rămâne, mediul preferat al utilizatorilor pentru generarea rapoartelor. Afişarea pe
ecran a ieşirilor prezintă numeroase avantaje, în comparaţie cu utilizarea hârtiei: posibilitatea
vizualizării rapoartelor dinamice, costuri de obţinere mult inferioare şi accesul mai rapid la
informaţii.
Mesajele electronice
Odată cu integrarea sistemelor informaţionale la nivel de organizaţie, dar şi inter-
organizaţii, generarea şi transmiterea ieşirilor în format electronic sunt din ce în ce mai
frecvent utilizate. Principalele tehnologii care facilitează schimbul electronic de informaţii sunt
Web-ul, poşta electronică şi sistemele EDI.
Extinderea utilizării Internetului, Intranet-ului, Extranet-ului şi a tehnologiei Web în
lumea afacerilor a creat condiţiile integrării sistemelor informaţionale. De exemplu, o firmă
poate permite accesul principalilor furnizori la sistemul său de gestiune a stocurilor,
transmiţînd acestora responsabilităţile privind activitatea de aprovizionare. Prin intermediul
tehnologiei Web, furnizorii vor putea oricând să acceseze baza de date şi să obţină anumite
rapoarte privind stocurile. De asemenea, prin intermediul unui site Web, clienţii vor putea
obţine on-line un catalog al produselor sau o ofertă.
Poşta electronică a devenit instrumentul esenţial de comunicare internă şi externă în
lumea afacerilor. Informaţiile despre produse noi, plăţi scadente, diverse notificări sau
confirmări, chiar documente, pot fi generate şi transmise în exteriorul firmei sub forma
mesajelor e-mail. Poşta electronică este utilizată din ce în ce mai mult şi în interiorul firmei,
înlocuind corespondenţa tradiţională bazată pe hârtie. Noile sisteme informaţionale pot genera
şi transmite automat, prin poşta electronică, diferite solicitări, înştiinţări sau confirmări către
angajaţii firmei sau decidenţi.
Sistemele cu ieşiri bazate pe microfilme, COM
(Computer Output Microfilm)
Ieşirile din sistem pot fi redate şi sub forma microfilmelor, care, prin instrumente oferite
de softul specializat, pot fi stocate, modificate şi transmise pe mai multe căi. Sistemele COM
permit utilizarea imaginilor în scopul arhivării şi consultării rapide a documentelor şi
rapoartelor generate iniţial pe hârtie, obţinându-se importante economii de spaţiu. Ele sunt utile
mai ales atunci când este necesară stocarea documentelor semnate, ştampilate sau cu alte
caracteristici vizuale. Totuşi, popularitatea acestor sisteme a scăzut în ultimul timp în favoarea
scanner-elor digitale.
Imaginea documentelor este captată şi stocată sub formă de microfilme sau microfişe.
Microfilmele stochează imaginile pe role de film, iar microfişele le transpun pe o singură
peliculă, sub forma diapozitivelor. Microfişele sunt preferate microfilmelor, datorită utilizării
mai eficiente a suportului de stocare şi pentru că ele permit indexarea şi regăsirea mai uşoară a
informaţiei.
Un sistem COM este conectat la un calculator şi poate transpune imaginile pe microfilme
sau microfişe în mod direct, pe măsură ce sunt generate. În afara acestui sistem, utilizarea
microfişelor şi a microfilmelor implică utilizarea unor echipamente auxiliare de developare,
copiere şi proiecţie.
Sistemele audio şi video
Tehnologiile audio şi video au înregistrat cele mai mari progrese în ultimii ani. Ieşirile
audio şi video oferă un potenţial de îmbunătăţire a comunicării pe care nici un alt mediu nu-l
poate realiza.
Audio înseamnă redarea sonoră a datelor. Mesajele vocale, fie şi cele gen Voice-Mail (V-
Mail), sunt destul de folosite în afaceri, îndeosebi în comerţul electronic. Aplicaţiile practice
ale ieşirilor audio sunt din ce în ce mai variate. Ele facilitează citirea ecranelor de către
utilizatorii cu probleme de vedere. De asemenea, ieşirile de tip audio pot fi generate automat de
către sistemul informatic pentru a înlocui personalul care preia telefonic comenzile clienţilor,
oferind astfel clienţilor un serviciu disponibil permanent, de tip 24/7/365 - 24 de ore din 24 ale
zilei, 7 zile din 7 ale săptămânii, 365 de zile din an, cu cheltuieli minime.
Video înseamnă combinarea imaginii şi a sunetului pentru a reda un anumit eveniment în
mişcare sub formă de film sau animaţie. Este forma specifică video-conferinţelor. O altă
utilizare a acestui tip de ieşire presupune crearea de simulări animate pentru a permite
utilizatorilor să vizualizeze o serie complexă de evenimente într-un timp scurt.
1.2.8 Controlul confidenţialităţii, integrităţii

şi accesibilităţii ieşirilor
În paragrafele anterioare, am consemnat o mare varietate de ieşiri, în funcţie de scop,
destinatari, format, mediu de transmitere, frecvenţă, conţinut şi sursa datelor. Pentru fiecare tip
de ieşire există proceduri şi mecanisme de control specifice, care vor trebui luate în
considerare la proiectarea lor. Însă, indiferent de tipul ieşirilor, prin control se vor urmări
confidenţialitatea, integritatea şi accesibilitatea ieşirilor, ceea ce înseamnă asigurarea
furnizării lor către destinatarii autorizaţi să le acceseze, precum şi a corectitudinii, oportunităţii
şi completitudinii informaţiilor conţinute. Oricum, nu trebuie să se omită problemele
referitoare la exercitarea controlului asupra sistemului, ele oferind motive de revizuire a
drepturilor de acces ale potenţialilor utilizatori, îndeosebi odată cu trecerea la sistemul on-line.
Problema controlului ieşirilor nu o vom detalia în acest paragraf, deoarece această
caracteristică nu constituie un criteriu de clasificare, iar obiectivul urmărit de noi în acest
paragraf vizează prezentarea principalelor tipuri de ieşiri, pornind de la caracteristicile lor
generale. Asigurarea controlul integrităţii ieşirilor solicită aplicarea unor reguli specifice de
proiectare, motiv pentru care ele vor fi prezentate într-un paragraf următor, special destinat
acestui subiect. Problema securităţii ieşirilor este una mult prea vastă pentru a putea fi epuizată
în lucrarea de faţă. Celor interesaţi de acest subiect le recomandăm lucrarea profesorului
Dumitru Oprea, Protecţia şi securitatea informaţiilor2.
1.2.9 Caracteristicile informaţiilor şi nivelurile decizionale

Cel mai adesea, ieşirile sunt generate în scopul luării deciziilor pe diferite niveluri
ierarhice. Pentru a-şi dovedi utilitatea, informaţiile trebuie să îndeplinească anumite
caracteristici relative la format, conţinut, sursa datelor, mediul de transmitere etc., aspecte
descrise în paragrafele anterioare. Caracteristicile pot fi văzute în mod diferit pe cele trei
niveluri decizionale, după cum este prezentat tabelul 1.3, care consemnează un punct de
vedere3 din literatura de specialitate.
1.3 Reguli de proiectare a formularelor/formatelor

şi a rapoartelor
Odată cu succesele înregistrate de tehnologiile informaţionale, pretenţiile utilizatorilor de

informaţii au crescut şi ele, datorită unei influenţe fireşti a educaţiei acestora în domeniul
calculatoarelor. Efectul se face simţit şi în privinţa calităţii rezultatelor prelucrării obţinute la
calculator. Paradoxal, chiar specialiştii în informatică trebuie să le cultive utilizatorilor gustul
pentru nou, pentru calitatea ieşirilor informatice. Într-un astfel de context, vom prezenta câteva
aspecte ce ţin de cultura bunului gust în privinţa proiectelor de formulare/formate şi rapoarte.
2. Oprea, D. – Protecţia şi securitatea informaţiilor, Editura Polirom, Iaşi, 2002.

3. Hicks Jr., J.O. – Management Information Systems: A User Perspective, Second Edition, West Publishing
Company, St. Paul, 1987, p. 25; Schulteis, R., Sumner, M., Bock, D. – Management Information Systems: The
Manager’s View, Second Edition, IRWIN, Homewood, Boston, 1992, pp. 312-329.
Tabel nr. 1.3 – Caracteristicile informaţiilor pe niveluri decizionale
Niveluri decizionale
Caracteristicile
informaţiilor/rapoartelor
Operativ Tactic Strategic
Dependenţa de sistemele de
prelucrare automată a datelor Ridicată Moderată Redusă spre moderată
Dependenţa de informaţiile interne Foarte ridicată Ridicată Moderată
Dependenţa de informaţiile externe Redusă Moderată Foarte ridicată
Gradul de sintetizare a informaţiilor Foarte redus Moderat Ridicat
Nevoia de informaţii on-line Foarte ridicată Ridicată Moderată
Nevoia de grafică pe calculator Redusă Moderată Ridicată
Folosirea informaţiilor în timp real Foarte ridicată Ridicată Moderată
Folosirea informaţiilor predictive* Redusă Ridicată Foarte ridicată
Folosirea informaţiilor din trecut Ridicată Moderată Redusă
Folosirea informaţiilor tip What-If Redusă Ridicată Foarte ridicată
Folosirea informaţiilor în etalon
bănesc Redusă Moderată Ridicată
Frecvenţa cererii de informaţii Regulat, repetitiv Aproape regulat Deseori ad-hoc
Efectul primirii informaţiei la Rezultat aşteptat Pot apărea unele surprize Rezultate pline de
utilizator (predictibil) surprize
Intervalul de timp acoperit Trecut Comparativ pe perioade Pentru perioade viitoare
sau faţă de anumite (predicţii)
standarde
Nivelul de detaliere a prezentărilor Foarte detaliate Sintetice Sintetice
Sursa datelor Interne Interne şi externe Majoritatea externe
Natura datelor utilizate Puternic structurate Unele date nestructurate Puternic nestructurate
Corectitudinea/Precizia datelor Foarte precise Unele date sunt subiective Foarte subiective
Utilizatorii tipici Supervizorii din prima Managerii de mijloc Top managerii
linie
Obiectul deciziei luate Activităţi prestabilite Orientate spre controlul Orientate spre obiective
şi alocarea resurselor strategice
* În accepţiunea autorului înseamnă informaţii obţinute prin tehnici de modelare statistică, cum ar fi regresia,
analiza seriilor de timp şi simularea. Ajută managerul în planificarea managerială, oferind răspunsuri la întrebările
What-If.
1.3.1 Recomandări generale de formatare

Descrierea detaliată a modului în care se reflectă calitatea ieşirilor în performanţele celor
ce le utilizează constituie un amplu subiect de discuţie în literatura de specialitate4. Din
multitudinea de păreri s-ar putea desprinde ca fiind cele mai elocvente sintezele realizate de
J.S. Dumas5 şi Cushing & Romney6.
• Introducere sugestivă (partea de titlu)
Prezentarea foarte clară a titlului ieşirii în partea superioară a paginii, central. Ea trebuie
să descrie cu fidelitate conţinutul.
Evidenţierea numărului şi/sau datei.
Dacă trebuie distribuit în alte locuri, care sunt acestea?
Specificarea datei de emitere a ieşirii, care poate să nu coincidă cu data sau perioada de
apartenenţă a informaţiilor oferite.
Dacă este cazul, va fi consemnată şi ora editării.
4. Shneiderman, B. – Designing the User Interface: Strategies for Effective Human-Computer Interaction, Addison-
Wesley, Reading, Massachusetts, 1992; Caroll, J.M. – Designing Interaction, Cambridge University Press,
Cambridge, 1991; Norman, K.L. – The Psychology of Menu Selection, Ablex, Norwood, New Jersey, 1991;
Benbasat. I., Dexter, A.S., Todd, P. – „The Influence of Color and Graphical Information Presentation in a
Managerial Decision Simulation”, in Human-Computer Interaction 2, 1986, pp. 65-92.
5. Dumas, J.S. – Designing User Interface for Software, Prentice Hall, Englewood Cliffs, 1988; Vezi şi Beizer, B. –
Personal Computer Quality, Van Nostrand Reinhold Company, New York, 1986.
6. Cushing, B.E., Romney, M.B. – Accounting Information Systems, Addison-Wesley Publishing Company, New
York, 1994.
• Informaţiile din instrucţiuni

Regulile de completare să fie foarte clare.
Să se specifice etapa ce urmează după editare.
De evitat comentariile lungi, prin rubrici cu nume sugestive.
De consemnat destinaţiile fiecărui exemplar al documentului/raportului tipărit.
Informaţiile să fie oferite fără modificări manuale.
• Partea principală (corpul ieşirii)
Să se facă o prezentare echilibrată, evitându-se aglomerările.
Folosirea corectă a spaţierilor, marginilor.
Numirea corectă a rubricilor.
Gruparea logică a rubricilor.
Scoaterea în relief a zonelor ce marchează rubrici diferite.
Accentuarea prin linii sau culori a zonelor-cheie.
• Concluziile (finalul ieşirii)
De plasat la sfârşitul paginii.
De alocat spaţiu suficient semnăturilor.
De prezentat ultimele indicaţii privind regimul de lucru cu documentul/ raportul.
Totalurile vor fi bine evidenţiate.
• Deplasarea lejeră prin document (navigarea)
De indicat, în faza de editare, cum se pot efectua deplasările înainte şi înapoi.
De arătat întotdeauna locul în care se află utilizatorul (de exemplu, pagina 5 din 15).
De specificat modul cum se poate efectua ieşirea din regimul de editare.
Semnalarea clară a ultimei pagini dintr-o secvenţă de mai multe pagini.
Tratarea ecranului după acelaşi regim cu documentul original (clasificarea informaţiilor
şi a accesului la ele).
Protejarea împotriva pierderii, modificării sau sustragerii ilegale sau din greşeală a
informaţiilor.
O regulă generală de proiectare a ieşirilor priveşte uniformitatea. La proiectarea tuturor
ieşirilor trebuie aplicate aceleaşi principii şi reguli, uşurând astfel procesul de învăţare. De
exemplu, data generării şi numărul de pagină trebuie să fie plasate în acelaşi loc pentru toate
ieşirile, abrevierile utilizate să fie menţinute de la o ieşire la alta etc.
Majoritatea regulilor prezentate anterior se aplică şi în cazul formularelor/formatelor
pretipărite: titlurile rubricilor trebuie să fie explicite şi să conţină doar abrevieri standard;
rubricile trebuie să fie grupate şi ordonate din punct de vedere logic; totalurile să fie bine
evidenţiate etc. Ca particularitate, apare necesitatea contactării furnizorului în vederea punerii
de acord asupra dimensiunii paginii, tipului şi dimensiunii fonturilor, culoarea cernelii, a altor
detalii. Formularul/formatul trebuie şă fie atractiv, uşor de citit şi la un preţ rezonabil.
1.3.2 Scoaterea în evidenţă a informaţiilor

Datorită progreselor semnificative înregistrate în domeniul tehnologiilor informaţionale,
punerea în evidenţă a informaţiilor din formulare/formate sau rapoarte se poate realiza sub
forme din ce în ce mai performante. Literatura recomandă mai multe forme de marcare a
anumitor informaţii, a grupurilor de informaţii aflate în interdependenţă, a totalurilor ş.a.m.d.
Dintre ele amintim:
• marcaj clipitor/intermitent;
• marcaj sonor;
• intensităţi diferite de culoare;
• culori diferite;
• diferenţieri prin mărimi variate ale caracterelor;
• diferenţieri prin fonturi;

• video invers;
• casete cu date grupate;
• subliniere;
• caractere majuscule;
• tipărirea informaţiilor nestandard cu caractere diferite de celelalte.
Evidenţierea unor informaţii dintr-o mulţime dată este recomandată îndeosebi în
următoarele situaţii:
• Atenţionarea utilizatorului, atunci când se introduc date eronate sau când, din
prelucrare, unele valori sunt eronate.
• Punerea în gardă a utilizatorului că datele introduse trebuie să aparţină unor intervale
de valori sau că anumite echipamente nu sunt în stare funcţională.
• Semnalarea, prin comenzi, cuvinte-cheie sau mesaje, că operarea a intrat într-un regim
anormal.
• Scoaterea în evidenţă a unor rubrici unde se înregistrează subtotaluri sau totaluri sau
unde se va afişa în curând o nouă valoare.
• Marcarea zonelor comune din pagină ş.a.
În figura 1.4 prezentăm o formă neinspirată pentru ecranul „Situaţie a personalului”, iar în
figura 1.5 este redată o altă formă, dar cu scoaterea în evidenţă a informaţiilor conţinute.
Citire dificilă: informaţii
Titlu vag prea înghesuite, nealiniate
Utilizarea exclusivă Lipsesc

Lipsa unor
a majusculelor este facilităţile de
totaluri
obositoare navigare
Fig. 1.4 Exemplu incorect de scoatere în evidenţă a informaţiilor

În ultima variantă, s-au folosit mai multe dintre modalităţile recomandate anterior pentru
scoaterea în evidenţă a unor informaţii importante: mărimi diferite ale caracterelor, fonturi
diverse, intensităţi variate, subliniere, caractere îngroşate (bold), folosirea doar pentru anumite
informaţii a majusculelor, apelarea la casete diferite, intensităţi diferite de scriere, comenzi
clare de navigare, prin butoane.
În privinţa marcării prin culori, părerile sunt împărţite. Deseori, culorile scot în evidenţă
în mod plăcut anumite elemente, alteori ele se folosesc doar pentru a fi altceva decât clasicele
imprimări alb-negru.
Titlu clar,
bine scos în evidenţă
Combinarea plăcută a Includerea unor Facilităţi pentru

majusculelor şi minusculelor. totaluri relevante navigare
Gruparea datelor. Evidenţierea Citire lejeră: aliniere,
prin caractere îngroşate. evidenţierea elementelor
variabile de cele constante
Fig. 1.5 Exemplu corect de scoatere în evidenţă a informaţiilor
Literatura este destul de reprezentativă în legătură cu folosirea sau nu a culorilor7. În
pofida disputelor aprige, concluzia a fost aceea că, totuşi, apelarea la culori ar putea oferi
avantaje, dar şi crea anumite probleme, astfel:
Avantaje:
• „Sar” în ochi, scot în evidenţă ceva anume.
• Accentuează ceea ce printr-o afişare normală ar fi irelevant.
• Prin nuanţări de culori se pot evidenţia situaţii specifice din afişări complexe.
• Subliniază organizarea logică a informaţiilor.
• Orientează atenţia spre zonele cărora trebuie să li se acorde o importanţă deosebită.
• Produc reacţii emoţionale mai mari.
• Ajută la citirea mai uşoară a liniilor din tabele.
Probleme ce apar la folosirea culorilor:
• Anumite suprapuneri de culori conduc la aşa-zisa „spălăcire” a elementelor tipărite sau
la apariţia unor culori-fantomă.
• Rezoluţia este diferită de la un mediu de lucru la altul.
• Fidelitatea culorii diferă de la un mediu la altul.
• Tipărirea sau conversia pe un alt echipament ar putea fi sortită eşecului.
• Imposibilitatea perceperii anumitor nuanţe de culori de către toţi utilizatorii – de
exemplu, culoarea roşie şi derivatele, pentru daltonişti.
• Manipularea mai lejeră a cititorilor prin colorarea stridentă a informaţiilor nerelevante
economic, cu scopul ascunderii altora importante.
7. Benbasat, I., Dexter, A.S., Todd, P. – op. cit.; Shneiderman, B. – op. cit.; Dumas, J. S. – op. cit.
Nu trebuie să se tragă concluzia că întotdeauna varianta color este mai bună decât cea alb-
negru. De exemplu, un stat de salarii, o calculaţie de cost, o situaţie a furnizorilor ar fi eronat
realizate în varianta color. În schimb, reprezentarea grafică a indicatorilor economici se
pretează la utilizarea marcării prin culori.
Cel puţin în privinţa monitoarelor, s-a constatat că 8% din bărbaţii Europei şi Americii de
Nord au probleme cu vederea din cauza folosirii culorilor. Varianta alb-negru este mult mai
odihnitoare pentru privire, dar nu şi mai plăcută întotdeauna. De aceea se sugerează proiectarea
în varianta alb-negru, rămânând la latitudinea utilizatorului ce culori foloseşte. Se recomandă,
de asemenea, apelarea la un număr cât mai redus de culori, doar pentru a evidenţia anumite
elemente şi pentru formatarea informaţiilor.
În ceea ce priveşte textele, care în orice condiţii de lucru au o pondere substanţială în
ieşirile sistemelor, se recomandă câteva reguli:
Caracterele: Se recomandă folosirea literelor mari şi mici, inclusiv respectarea regulilor
de punctuaţie.
Spaţierea: Dacă este posibil, este de dorit folosirea dublei spaţieri. Dacă nu, se
recomandă plasarea unei linii cu spaţii între paragrafe.
Alinierea: Se recomandă alinierea textului la stânga şi, dacă nu se poate rezolva altfel,
partea dreaptă poate fi neregulată.
Liniuţa de În textele ecranelor, ale rapoartelor nu se recomandă despărţirea cuvintelor
unire: în silabe de pe un rând pe altul.
Abrevierile: Nu se recomandă folosirea abrevierilor pentru cuvinte care nu au o
recunoaştere generală.
1.3.3 Reguli specifice de proiectare a rapoartelor în formă tabelară

Majoritatea ieşirilor din sistemele informaţionale economice au formă tabelară. Tabelele
au şi ele un tratament riguros, formatul de editare fiind foarte important. Ca şi informaţiile
prezentate prin text, şi cele din tabele trebuie să respecte anumite reguli, devenite în timp
standarde, prezentate în tabelul 1.4.
Tabel nr. 1.4 – Reguli generale de afişare a tabelelor
Folosirea unor nume semnificative:
• Toate coloanele şi rândurile să aibă nume (etichete) cât mai relevante.
• Numele respective vor fi scoase în evidenţă faţă de celelalte prin tehnicile
corespunzătoare, descrise anterior.
• Reafişarea numelor coloanelor sau rândurilor când datele depăşesc limitele paginii.
• Evitarea numelor lungi, a ambiguităţilor generate de sensul cuvintelor folosite.
• Pe cât posibil, de renunţat la despărţirea în silabe, recomandare întâlnită şi la texte.
• Centrarea, în cele mai multe cazuri, a numelor coloanelor şi alinierea la stânga a
numelor rândurilor.
Formatarea coloanelor, a rândurilor şi a textului:
• Sortarea într-o ordine logică a datelor prezentate, după una sau două chei, ascendent
sau descendent.
• Folosirea unei linii cu spaţii după fiecare cinci rânduri atunci când există prea multe
coloane.
• Informaţiile similare afişate în mai multe coloane trebuie să fie sortate pe verticală,
întrucât ordinea lor se urmăreşte pe coloană, deci de sus în jos, şi nu de la stânga la
dreapta, pe linie.
• Între coloane trebuie să existe cel puţin două spaţii.
• De lăsat loc suficient pe rapoartele tipărite care să-i permită utilizatorului să
introducă diverse adnotări.
• De folosit acelaşi gen de caractere, cu excepţia cazurilor care trebuie să fie scoase
în evidenţă.
• De evitat excesele de fonturi fanteziste, greu de citit.
Formatarea datelor de tip numeric, alfabetic sau alfanumeric:

• Datele numerice trebuie să fie aliniate la dreapta şi/sau pe marca zecimală,
coloanele fiind astfel uşor de citit.
• Datele de tip text vor fi aliniate la stânga.
• Se recomandă folosirea liniilor scurte de text, de regulă de 30-40 de caractere,
pentru o parcurgere uşoară prin citire. Aceasta este şi dimensiunea standard a
coloanelor de ziar.
• De evitat blocurile mari cu date alfanumerice. În astfel de cazuri trebuie găsite
criterii de descompunere a lor în grupuri mai mici, mai uşor de citit, deci şi mai
inteligibile, care să nu aibă mai mult de 3-4 caractere, gen numere auto sau de
telefon (0232-212-131).
La proiectarea rapoartelor în format tabelar se vor lua în considerare zonele specifice,

regăsite în toate generatoarele de rapoarte, întâlnite în multe sisteme de gestiune a bazelor de
date. Aceste zone, prezentate şi în raportul din figura 1.6, sunt (redăm şi denumirea lor în
limba engleză, pentru o mai bună recunoaştere a lor în generatoarele de rapoarte):
• Antetul şi sfârşitul raportului (Report Header şi Report Footer). Fiecare raport
trebuie să aibă un antet şi un sfârşit. Antetul raportului va conţine elementele care
apar o singură dată, la începutul raportului. Aici se includ, de obicei, titlul raportului,
data obţinerii şi numele destinatarului. În zona de sfârşit a raportului sunt prevăzute
totalurile generale pentru câmpurile numerice şi, eventual, numele persoanelor
responsabile de generarea lui, precum şi ale celor care îl certifică.
• Antetul şi sfârşitul paginii (Page Header şi Page Footer). În aceste zone vor fi incluse
elementele raportului care apar pe fiecare pagină, la începutul sau la sfârşitul ei.
Pentru fiecare raport, numele coloanelor trebuie prevăzute în antetul de pagină, astfel
încât ele să fie afişate la începutul fiecărei pagini. Numărul paginii şi numele
raportului pot să apară în zona de antet sau cea de sfârşit al paginii. Tot aici sunt
incluse totalurile la nivel de pagină.
• Antetul şi sfârşitul grupului (Group Header şi Group Footer). Aceste două zone vor
fi prevăzute numai în rapoartele în care se doreşte gruparea liniilor cu date după unul
sau mai multe câmpuri de control. În exemplul din figura 1.6, vânzările sunt grupate
pe clienţi, iar codul clientului reprezintă câmpul de control. Elementele incluse în
aceste zone apar o singură dată pentru fiecare grup de date, deasupra primei linii cu
date din grup, respectiv sub ultima linie din grup. În antet se includ, de regulă, datele
de identificare ale grupului adică, în exemplul nostru, codul şi numele clientului. În
zona de sfârşit se pot afişa totalurile sau rezultatele altor operaţiuni de agregare la
nivelul grupului, precum numărul elementelor, valoarea medie, minimă şi maximă
pentru câmpurile numerice.
• Linia de detaliu (Detail) . Este zona principală a oricărui raport şi conţine câmpurile
care vor forma o linie cu informaţii. În această zonă sunt afişate date extrase din bază
sau informaţii calculate pe baza acestora. Pentru fiecare înregistrare prelucrată din
baza de date se va crea câte o linie.
La construirea tabelelor se pot lua în considerare şi următoarele recomandări, adaptate
după Publication Manual of the American Psychological Association, ediţia a 3-a, care pot fi
urmărite şi cu ajutorul figurilor 1.7 şi 1.8. Există şi alte metode de prezentare a tabelelor, dar
cea a Asociaţiei Americane de Psihologie constituie referinţa.
Date identificare grup
Departamentul Desfacere
Antet
Situaţia vânzărilor pe clienţi în perioada 01/01/2006 - 28/02/2006 raport
Data: 15/03/2006
Nr. Factura Comanda Valoare
Antet pagina
crt. Număr Data Număr Data
Cod client: 1234, Nume client: ALFA srl Antet grup
1 458992 13-ian-2006 1212 5-ian-2006 72.000.000
2 459025 13-feb-2006 1875 6-feb-2006 57.000.000
3 459220 22-feb-2006 1899 11-feb-2006 112.000.000 Linie detaliu
4 459758 23-feb-2006 2543 13-feb-2006 43.000.000
Total client 284.000.000 Sfârsit grup
Cod client: 1235, Nume client: BETA sa
5 458891 13-ian-2006 1211 4-ian-2006 14.500.000
6 458999 18-ian-2006 1256 10-ian-2006 29.850.000
7 459112 20-feb-2006 1301 10-feb-2006 44.000.000
Total client 88.350.000
Total general 372.350.000 Sfârsit raport
Pagina 1 din 1 Sfârsit pagina
Fig. 1.6 Zonele întâlnite în rapoartele în format tabelar
În figura 1.7 sunt prezentate elementele componente ale unui tabel şi modul lor de
organizare, iar în figura 1.8 oferim un exemplu pentru a reliefa aspectele teoretice care stau la
baza construirii tabelelor.
(1) Numărul tabelului
(2) Titlul tabelului
(3) Linie desenată________________________________________
(6) Titlul coloanelor multiple
(4) Titlul cotorului (5) Titlul coloanei Titlul coloanei
(7) Titlul liniei
(8) Subtitlu Date Date
Subtitlu Date Date
Titlul liniei Date Date
(3) Linie desenată________________________________________
(9) Sursa:
(10) Note explicative
Fig. 1.7 Elementele de bază ale unui tabel
Pentru realizarea unui tabel, aşa cum se observă şi din figurile 1.7 şi 1.8, trebuie luate în
considerare zece elemente esenţiale, şi anume:
(1) Numărul tabelului: se va atribui consecutiv, în ordinea apariţiei, pe parcursul
întregului raport, sub forma numerelor arabe. Numărul se va scrie la marginea din stânga,
apelând la metoda numerelor duble (de exemplu, 2.3) numai în rapoartele lungi, care conţin
mai multe capitole, fără a se pune punct după ultimul grup de numere. Numărul şi titlul se vor
plasa deasupra tabelului, iar elementele suplimentare în zona imediat următoare sub tabel.
(2) Titlul tabelului trebuie să identifice, cât mai concis, datele înregistrate în tabel. Ca şi
numărul tabelului, titlul va fi scris la marginea din stânga, la două rânduri sub număr. Formatul
în care se va scrie titlul este următorul: prima literă a titlului şi pentru substantivele proprii se
vor scrie cu literă mare, iar celelalte cuvinte cu litere mici. Dacă titlul necesită şi o a doua linie,
se va începe tot din marginea din stânga, la două rânduri sub prima linie de titlu. Nu se va pune
punct după titlu.
(1) Tabel 1
(2) Costul de producţie pe produs
(3) ___________________________________________________
(6) Tipul produsului
(5) AC DC
(4) Costuri iniţiale
(7) Componenta de bază1 $ 76,000 $ 110,000
(8) Dispozitiv auxiliar-1 1,500 -
Dispozitiv auxiliar-2 2,000 -
Instalare 23,000 12,000
Total $ 102,500 $ 122,000
(3) ___________________________________________________
(9) Sursa: Smith, J.K., Speed Drives, Production Journal, iulie, 1977, 52.
(10) 1 în ambele variante se oferă un an garanţie
Fig. 1.8 Exemplu de tabel cu prezentarea elementelor componente
(3) Liniile tabelului. În general, tabelele au trei linii orizontale şi nici o linie verticală.
Dacă raportul este mai mult informal, se va apela la cât mai puţine linii sau chiar la nici una.
Ultima linie din tabel va delimita conţinutul acestuia de elementele suplimentare ataşate, cum
ar fi sursa tabelului şi notele explicative.
(4) Titlul cotorului (capetele de linii) este folosit pentru a denumi coloana în care vor fi
înregistrate numele variabilelor comparate în cadrul tabelului.
(5) Titlul coloanelor defineşte datele înscrise în coloanele respective.
(6) Titlul coloanelor multiple este folosit ca nume comun pentru coloanele situate sub el,
pentru a se reduce repetiţiile ce ar putea apărea în titlul fiecărei coloane.
(7) Titlul liniei identifică conţinutul rândului de date din dreapta primei coloane în care se
găseşte. Dacă este necesar, titlul liniei poate fi descompus în două sau mai multe subtitluri, caz
în care nu se vor înregistra date în dreptul liniei de titlu.
(8) Subtitlul defineşte conţinutul elementelor plasate pe rândurile imediat următoare
variabilei pe care o formează, fiind plasat sub titlul liniei şi evidenţiat prin indentare (scriere
adâncită, mai spre dreapta).
(9) Sursa este folosită pentru a indica originea datelor preluate. În cazul în care datele au
fost citate dintr-un material, se vor preciza cu exactitate autorul, titlul materialului, locul şi
anul apariţiei, eventual numărul paginii. Dacă datele provin dintr-o altă sursă decât materiale
publicate, se va specifica locul de unde au fost preluate (de exemplu, Sursa: Date preluate de la
Departamentul Producţie). Dacă sunt necesare comentarii asupra tabelului, acestea se vor
realiza între ultima linie trasată şi sursă, folosind cuvântul Notă, urmat de comentariile
respective.
(10) Notele explicative sunt destinate explicaţiilor privind anumite zone ale tabelului. Se
va face trimitere la aceste note prin litere mari sau mici atât în cadrul tabelului, cât şi la
începutul notei explicative.
1.3.4 Reguli specifice de proiectare a graficelor

Deseori, există dispute între specialişti privind superioritatea graficelor în comparaţie cu
tabelele. Din mai multe privinţe, graficele sunt mai edificatoare. Dintre acestea amintim:
• O imagine este mai sugestivă decât 1 000 de cuvinte, afirmă specialiştii.
• Se prezintă o sinteză riguroasă a datelor.
• Marcarea celor mai importante elemente.

• Excepţiile sunt uşor de sesizat.
• Evidenţiază eventualele corelaţii dintre elemente.
• Se poate aprecia tendinţa în timp.
• Se pot efectua comparaţii multiple rapide.
• Se oferă şansa efectuării de prognoze.
• Cu ajutorul unui grafic pot fi vizualizate mult mai simplu cantităţi imense de date
valorice.
Tipuri de grafice corelate cu datele reprezentate
Atunci când se apelează la forma grafică de reprezentare a informaţiilor este necesar să se
selecteze mai întâi tipul cel mai potrivit de grafic (histogramă, histogramă cumulată, linie,
diagramă de structură), care depinde de tipul informaţiilor pe care le va conţine. Datele pot să
aparţină fie unei serii discrete, fie unei serii continue. Diferenţa dintre cele două categorii
constă în faptul că seriile continue conţin date care se schimbă în timp (de exemplu, populaţia
unui oraş în momente diferite), iar seriile discrete – date similare de la entităţi diferite (de
exemplu, populaţia a trei oraşe la un anumit moment).
Graficele linie sunt cele mai potrivite pentru redarea seriilor continue. Graficele stivă de
bare (histogramă cumulată) şi tip pie sunt reprezentative pentru seriile discrete. Graficul tip pie
(diagramă de structură) este folosit pentru a scoate în evidenţă ponderea părţilor în întreg.
Recomandări generale pentru construirea graficelor
• În rapoarte, graficelor li se atribuie un număr şi un titlu, indiferent de tip.
• Referirea la grafice se va face, în general, ca şi la figuri, numerotându-le secvenţial de-
a lungul raportului, cu numere arabe.
• Se va plasa cuvântul Figura şi numărul corespunzător la marginea din stânga paginii,
numărul fiind urmat de punct şi alt număr, dacă se prezintă figurile pe capitole, de
genul x.y.
• Titlul graficului va începe imediat după număr, fără a fi subliniat şi fără a se pune
punct după el. Dacă sunt necesare două linii pentru redarea titlului, cea de-a doua linie
va începe tot din marginea din stânga, la două rânduri distanţă sub prima linie.
• Se va indica sursa datelor prin plasarea cuvântului Sursă sub numărul şi numele
graficului, urmat de citarea sursei.
• În rapoartele informale, realizatorii lor, deseori, plasează titlul dedesubt sau deasupra
figurii, după cum poate fi obţinută o imagine mai clară şi în funcţie de formatul
paginii.
De multe ori, graficele sunt folosite pentru a prezenta aceleaşi date statistice conţinute de
un tabel. Multe produse-program oferă posibilitatea generării automate a graficelor pe baza
datelor ce au fost introduse în diferite tabele. Graficele prezintă informaţiile într-un mod mult
mai concludent decât tabelele. Totuşi, sunt cazuri când graficele nu redau situaţia la fel de
exact aşa cum se întâmplă când se apelează la tabele. Altfel spus, uneori, graficele sunt mai
puţin elocvente decât tabelele, ceea ce impune alegerea celei mai bune variante, tabel sau
grafic, care să uşureze înţelegerea datelor de către utilizator.
Aşadar, tabelele nu pot lipsi din majoritatea aplicaţiilor economice, unde nu semnificaţia
unui fenomen sau a unui proces este relevantă, ci valoarea concretă a datelor. În acest caz, când
trebuie să fie descrise valori individuale, tabelele sunt de neînlocuit. În astfel de situaţii,
recomandăm apelarea la tabele landscape (pe lungimea foii A4). Numărul coloanelor poate fi
mai mare, iar regulile amintite anterior pot fi respectate mult mai uşor.
Un subiect prezent în literatura de specialitate, pe tema întocmirii rapoartelor, se referă la
prezentarea denaturată a informaţiilor, îndeosebi prin reprezentări grafice. Există mai multe
modalităţi prin care să se înşele percepţia utilizatorului, fie prin formatul datelor, fie prin tipul
lor, ca de exemplu:
• Oferirea informaţiilor fie prin tabele, fie prin grafice, care să-i facă utilizatorului
imposibilă sesizarea unor lucruri relevante. De exemplu, dacă am urmări conturile de
valori materiale pentru a stabili care este situaţia stocurilor supranormative, iar tabelul
ar fi realizat în ordinea alfabetică a materialelor şi s-ar afişa color stocurile cele mai
mici, ambele ar contribui la abaterea atenţiei utilizatorului de la realitate.
• Încărcarea reprezentărilor cu multe elemente, multe linii, multe culori, multe fonturi,
astfel încât percepţia unor comportamente anume ale unui lucru să nu fie posibilă.
• Apelarea la culori şi alte modalităţi de scoatere în evidenţă a altor date decât cele ce
ar trebui să aibă acest tratament.
• Manipularea percepţiei prin factorii de scalare din reprezentările grafice. O astfel de
tehnică este văzută la prezentarea performanţelor calculatoarelor, ale programelor, ale
automobilelor ş.a. Intenţia este fie de a ascunde ceva, fie de a scoate în relief altceva.
Prezentăm în figura 1.9 aceleaşi informaţii în trei moduri: a) normal, b) modificarea
bazei de pornire a reprezentării, c) exagerarea valorii maxime a parametrilor
reprezentaţi grafic.
Baza scalei = 0
Vârful scalei = aproape de valoarea maximă
50
45
40
35
30
25
20
15
10
5
0
Trim. I Trim. II Trim. III Trim. IV
a) Scală normală
Baza scalei
Baza scalei == 15
15
Vârful scalei = aproape de
Vârful scalei = aproape de valoarea
valoarea maximă
maximă
50
45
40
35
30
25
20
15
b) Grafic denaturat prin schimbarea bazei scalei

Baza scalei = 0
Vârful scalei = 100, mult mai mare decât valoarea maximă
100
90
80
70
60
50
40
30
20
10
0
c) Grafic denaturat prin schimbarea vârfului scalei
Fig. 1.9 Exemple de vizualizare diferită a informaţiilor

pe baza aceloraşi date
Din exemplele prezentate, rezultă că un rol deosebit în redarea fidelă a realităţii îi revine
analistului sau realizatorului ieşirilor sistemului. Cele mai multe denaturări ale scalelor se
întâlnesc în campaniile publicitare ale produselor.
1.3.5 Reguli pentru controlul confidenţialităţii, integrităţii şi

accesibilităţii ieşirilor
Aşa cum am văzut anterior, una dintre caracteristicile ieşirilor, care trebuie luată în
considerare la formularea specificaţiilor de proiectare, se referă la controlul ieşirilor.
Obiectivul urmărit la proiectarea ieşirilor constă în asigurarea completitudinii, oportunităţii şi
exactităţii informaţiilor conţinute, precum şi restricţionarea accesului pentru persoanele
neautorizate. Odată ce au fost generate, ieşirile sunt dificil de controlat, deoarece numărul
mecanismelor de control este redus, fiind aplicabile doar procedurile de control fizic. De aceea,
este recomandată aplicarea procedurilor de control înainte de generarea şi distribuirea ieşirilor.
Poate cea mai eficace procedură pentru controlul ieşirilor constă în limitarea accesului la
sistemul informaţional, prin definirea utilizatorilor autorizaţi şi a drepturilor de acces ale
fiecăruia. În acest fel, se asigură un anumit nivel de control în ceea ce priveşte ieşirile, ele
putând fi accesate doar de persoanele cu drepturi de acces în sistem.
Cu toate acestea, sunt necesare unele controale care să-i vizeze pe utilizatorii sistemului.
În acest sens, pot fi aplicate două proceduri: controlul distribuirii ieşirilor şi separarea
atribuţiilor.
Controlul distribuirii ieşirilor vizează permiterea accesului la rapoarte doar utilizatorilor
cărora le sunt destinate. În trecut, majoritatea ieşirilor erau tipărite pe hârtie, prin folosirea unei
singure imprimante la nivelul întregii firme. Controlul distribuirii ieşirilor era centralizat la
nivelul unui birou special, unde utilizatorii autorizaţi puteau solicita pe cele care le erau
destinate.
Progresele tehnologice înregistrate, dezvoltarea pe scară largă a sistemelor client/server,
au determinat unele mutaţii, precum integrarea sistemelor informatice, preferinţa pentru
afişarea rapoartelor pe ecran în detrimentul tipăririi lor, dotarea fiecărui departament cu
imprimante. În noile condiţii, controlul ieşirilor se bazează mai mult pe procedurile logice
decât pe cele fizice. Foarte utilă este întocmirea unei liste pentru controlul distribuirii, în care
se vor specifica utilizatorii autorizaţi pentru fiecare ieşire în parte, eventual şi staţia de lucru de
pe care poate fi generată şi accesată. Implementarea acestei liste impune gestionarea, în cadrul
aplicaţiei, a drepturilor de acces pentru fiecare ieşire, dar şi o bună coordonare între aplicaţie şi
sistemul de securitate din reţeaua de calculatoare a firmei.
Separarea responsabilităţilor presupune crearea unor activităţi separate care să fie
realizate de angajaţi diferiţi, identificându-se activităţile care, dacă ar fi realizate de acelaşi
angajat, ar crea condiţii pentru realizarea de fraude. Separarea atribuţiilor se realizează la
nivelul diferitelor funcţii ale sistemului, vizate fiind, în mod deosebit, cele care privesc crearea
şi generarea ieşirilor. De exemplu, preluarea comenzilor de la clienţi şi înregistrarea lor în
sistem ar trebui separată de generarea documentelor privind livrările, cele două activităţi
trebuind realizate de două persoane diferite. Altfel, va fi posibilă efectuarea unor livrări
frauduloase. De asemenea, înregistrarea anumitor tipuri de tranzacţii şi obţinerea rapoartelor,
pe baza cărora se va verifica corectitudinea şi completitudinea înregistrărilor care privesc acele
tranzacţii, trebuie realizate de persoane diferite. Un alt exemplu se referă la separarea funcţiei
de scriere a programului pentru generarea unei ieşiri, de cea care priveşte utilizarea
programului respectiv.
Corectitudinea, completitudinea şi oportunitatea informaţiilor furnizate de sistem depind,
în cea mai mare măsură, de procesele interne de prelucrare, şi mai puţin de aplicarea unor
proceduri de control. Totuşi, analistul are la dispoziţie câteva astfel de proceduri, pe care
trebuie să le ia în considerare la proiectarea fiecărei ieşiri, după cum urmează:
• includerea, în antetul rapoartelor, a datei la care au fost generate;
• formularea clară a titlului raportului, în care să fie precizată perioada de timp acoperită
de informaţiile conţinute;
• includerea numelui destinatarului în antetul rapoartelor;
• numărul de pagină să fie în formatul „pagina ___ din ___”;
• prevederea unor totaluri de control, ori de câte ori este posibil;
• afişarea numărului de înregistrări prelucrate.
1.4 Demersul proiectării ieşirilor
Atât formularele/formatele proiectate a fi realizate cu ajutorul calculatorului, cât şi

rapoartele constituie cele mai interesante piese ale sistemului pentru utilizatorii acestuia.
Demersul proiectării ieşirilor trebuie astfel conceput încât să permită implicarea directă şi
eficientă a utilizatorilor. De aceea, proiectarea ieşirilor trebuie să se realizeze după un anumit
procedeu-cadru, specific prototipizării8, conform figurii 1.10.
Identificarea Cerinţele iniţiale Realizarea
problemei prototipului
Conversia în Prototip în lucru

sistem operaţional
Alte cerinţe
Dacă prototipul
este eficient
Problema
Implementare Prototip revizuit
şi folosirea Altă versiune şi îmbunătăţit
prototipului
Fig. 1.10 Metodologia prototipizării
8. Naumann, J.D., Jenkins, A.M. – „Prototyping: The New Paradigm for Systems Development”, in MIS Quarterly,
6 (3), 1993, pp. 29-44.
În proiectarea ieşirilor, analistul trebuie să elaboreze un model demonstrativ al raportului

sau ecranului şi să întrebe utilizatorul dacă informaţiile din raport şi formatul acestuia sunt
acceptabile. Utilizatorului trebuie să i se acorde suficient timp pentru a studia ieşirile, astfel
încât să fie sigur că i se oferă ceea ce a cerut, că nu sunt adăugate informaţii de prisos şi că
ieşirile sunt redate în cea mai plăcută formă. Dacă ieşirile sunt inacceptabile, analistul trebuie
să le modifice şi să i le dea din nou utilizatorului pentru a le revedea. Acest pas este atât de
important încât multe organizaţii cer utilizatorilor să semneze un document prin care să se
consemneze că forma şi conţinutul rapoartelor propuse sunt acceptate de către ei. Procedura
asigură astfel evitarea cheltuielilor şi a timpului suplimentar impuse de eventualele schimbări
ulterioare.
În timpul procesului de proiectare a formularelor şi rapoartelor trebuie să se găsească
răspunsuri la întrebările: cine, ce, când, unde, cum, conform următorului model:
• Cine este beneficiarul formularului/formatului, raportului sau răspunsului la întrebări?
• Ce trebuie să conţină formularul/formatul, raportul sau răspunsul la întrebări?
• Când se solicită obţinerea ieşirilor?
• Unde să fie transmis formularul/formatul, raportul sau răspunsul la întrebări şi unde să
fie folosit?
• Cum se vor utiliza ieşirile respective? Câte persoane le vor folosi sau le vor vedea?
După culegerea tuturor informaţiilor în legătură cu ieşirea de proiectat, se va da forma
unui prototip al acesteia. Într-o astfel de fază, dialogul cu utilizatorul nu mai este atât de intens,
deşi unele păreri ale sale sunt luate în considerare. Totuşi, după obţinerea prototipului,
utilizatorul este cel ce se va pronunţa asupra calităţii acestuia, cerând fie acceptarea în forma
primită, fie efectuarea unor corecţii. În cazul corecţiilor, se parcurg paşii specifici
prototipizării: construcţie-evaluare-rafinare în ciclu, până când sunt rezolvate toate cerinţele
utilizatorului. De regulă, acest ciclu este reluat de câteva ori. De fiecare dată, utilizatorul este
cel ce va declanşa procesul.
Construcţia prototipului iniţial poate fi realizată în diverse medii. În faza în care ne aflăm,
se poate vorbi de o „ciornă” a formularelor/ formatelor, rapoartelor sau ecranelor, ele fiind
privite doar ca structură şi machetă. Ne aflăm doar în faza de proiectare logică, detaliile
privind modul de obţinere a ieşirilor respective vor fi oferite mai târziu. Ceea ce ne propunem
acum poate fi realizat cu un procesor de texte, un produs-program orientat spre grafică sau cu
un program de calcul tabelar. Opţiunea la modă se îndreaptă spre instrumentele CASE sau cele
standard pentru un astfel de obiectiv.
Nu trebuie uitate vremurile nu prea îndepărtate, când în cadrul acestei faze totul se efectua
manual. Pentru proiectarea formatului rapoartelor tipărite se utiliza macheta imprimantei. Ea
este o grilă formată din 50 de linii şi 150 de coloane, reprezentând numărul aproximativ al
spaţiului destinat tipăririi pe o pagină de imprimantă (folosind tipărirea normală sau cea
comprimată). Proiectantul de sistem putea folosi câteva machete de acest tip, pentru a reliefa
variantele posibile de formate pentru documentele şi rapoartele imprimate.
Şi în cazul rapoartelor obţinute pe ecranul unui monitor, în mod text, se foloseau machete
speciale pe hârtie. Se puteau face descrieri pe 80 de coloane şi 25 de rânduri – dimensiunea
standard pentru cele mai multe monitoare. În mediile de lucru grafice utilizate astăzi,
dimensiunile amintite sunt lăsate uitării. Mărimea fonturilor, dimensiunea ecranelor, culorile
folosite rămân la discreţia utilizatorului, prin faptul că poate solicita analiştilor şi
programatorilor orice doreşte.
şi acum se mai folosesc astfel de machete speciale pe hârtie, dar ele au scăzut mult în
comparaţie cu noile modalităţi de realizare a acestora. În cele mai noi medii de lucru se poate
proiecta în mod grafic, în regim on-line, devenind o activitate aproape standard.
Atunci când utilizatorul evaluează performanţele formularelor/formatelor sau rapoartelor,
operaţiunea se referă la câteva aspecte esenţiale, şi anume: viteza cu care se efectuează o
activitate, precizia rezultatelor obţinute, satisfacţia folosirii ieşirilor respective.
În afara performanţei, utilizatorul priveşte ieşirile şi din alte puncte de vedere, care pot fi
prezentate astfel:
• Stabilitate – Stabilitatea sau consistenţa presupune folosirea aceloraşi termeni,
abrevieri, formate, titluri şi metode de navigare în toate ieşirile sistemului.
• Eficienţa – Atunci când se efectuează formatarea ea trebuie să se deruleze în strânsă
concordanţă cu sarcinile de executat. Textele trebuie să fie aliniate, coloanele sortate,
deplasarea să fie uşor de realizat. Pe cât este posibil, ar trebui să fie evitate
introducerile de date necesare obţinerii ieşirilor.
• Comoditate – Să nu se facă trimiteri la afişări anterioare, să se folosească etichete
clare, precum şi factori de scală corespunzători.
• Format – Formatul informaţiilor trebuie să se menţină pentru aceleaşi tipuri de date şi
să scoată în evidenţă ceea ce este important. Se recomandă folosirea, printre
caracterele tipărite, a semnelor monetare, a mărcilor zecimale, a separatorilor ordinelor
de mărime şi a semnelor +, –, % în mod corespunzător.
• Flexibilitate – Trebuie să i se ofere utilizatorului posibilitatea de a lista în modurile
dorite de el, de a opri procesul şi de a naviga în locurile dorite.
În concluzie, specialiştii spun că satisfacţia în utilizare s-ar putea rezuma la: timpul de
învăţare (acomodare), viteza în execuţie, rata erorilor, persistenţa în timp (stabilitatea),
satisfacţii subiective. Culegerea informaţiilor despre toate aceste considerente o efectuează
echipa de proiectare şi realizare, prin tehnicile descrise anterior în etapa de analiză a
sistemelor.
1.5 Formularea specificaţiilor de proiectare a ieşirilor
Ca şi în cazul altor etape sau subetape, trebuie să luăm în discuţie şi produsele etapei de
faţă. Ele sunt sintetizate în specificaţii de proiectare a formularelor şi rapoartelor, structurate
astfel:
• prezentarea descriptivă a ieşirii;
• un model al proiectului;
• testarea şi evaluarea comportamentului în utilizare.
În secţiunea rezervată prezentării descriptive a ieşirii, trebuie specificate toate elementele
relevante de proiectare, care privesc caracteristicile discutate anterior, în acest capitol: scopul
şi destinatarii, frecvenţa, formatul şi conţinutul, sursa datelor, mediul de generare şi controlul.
În cea de-a doua secţiune este prezentat prototipul, din care reiese forma ieşirii respective. În
ultima secţiune, sunt prezentate rezultatele evaluării prototipului de către utilizatori. În acest
sens, va fi cuantificată percepţia utilizatorilor în legătură cu aspectele esenţiale ale ieşirii,
aspecte prezentate în finalul paragrafului anterior.
Un model de specificaţie pentru raportul „Situaţia vânzărilor …” este prezentat în figura
1.11.
Pentru sursa datelor, specificaţiile de proiectare pot fi completate prin descrierea
câmpurilor ce vor fi accesate din fiecare tabelă a bazei de date. Asupra acestui aspect vom
reveni în capitolul destinat proiectării fizice a bazei de date. De asemenea, specificaţiile de
proiectare a secvenţei de dialoguri, prin care utilizatorul va interacţiona cu sistemul pentru
obţinerea raportului, vor fi prezentate în capitolul următor.
Specificaţiile de proiectare pentru raportul

“Situaţia vânzărilor de produse finite pe gestiuni şi factur i”
a) Prezentare descripti vă
Scop: - Întocmirea şi verificarea notei contabile privind vânzările .
- Controlul ieşirilor de produse finite din depozite .
Utilizatori: Economistul r esponsabil cu evidenţa produselor f inite .
Conţinut: 1. Gruparea datelor - pe gestiuni şi facturi
- pe gestiuni şi produse .
2. Ordonarea datelor - pe gestiuni si facturi sau pe gestiuni şi produse,
în funcţie de modul de grupare dorit, şi apoi după denumirea
produsului sau numărul facturii.
3. Totaluri solicitate – la nivel de gestiuni, facturi/produse şi raport.
4. Alte menţiuni – raportul va conţine date privitoare la o singură
gestiune, aleasă de utilizator, sau pentru toate gestiunile;
perioada de timp va fi tot la alegerea utilizato rului.
- denumirea gestiunii va fi afişată o singură dată, în
prima linie a grupului, precum şi în prima linie de detaliu a fiecărei
pagini.
Mediul de generare: Raport ul va fi tipărit sau afişat pe ecran.
Frecvenţa: Raportul va fi generat lunar, în primele 5 zile ale lunii, sau la cerere.
Sursa datelor: Se vor accesa tabelele GESTIUNE, PRODUS, VANZARE şi
ARTICOLV ANZARE din baza de date.
b) Modelul proiectului
Departamentul Contabilitate
Situaţia vânzărilor pe gestiuni şi facturi

în perioada 01/01/2006 - 31/01/2006
Emis de Ionescu Ionela Data: 02.02.2006

Factura Produs Preţ Cantitate Valoare
Număr Data Cod Denumire UM unitar
Depozitul nr. 1
18795 05.ian.06 110220 Sacou tip A buc 124,00 10,00 1.240,00
110228 Costum Bărb. buc 322,00 8,00 2.576,00
110236 Pantaloni EST per 45,00 12,00 540,00
110250 Camaşă SV buc 81,00 12,00 972,00
Total factură 5.328,00
18801 09.ian.06 110220 Sacou tip A buc 124,00 5,00 620,00
110244 Sacou tip E buc 76,00 5,00 380,00
Total depozit 6.328,00
Depozitul nr. 2
21544 13.ian.06 110267 Pijama cod 21 set 67 25,00 1.675,00
110275 Rochie MD 11 buc 85 10,00 850,00
21545 20.ian.06 110283 Maieu barb. buc 15 100,00 1.500,00
110267 Pijama cod 21 set 67 20,00 1.340,00
110275 Rochie MD 11 buc 85 25,00 2.125,00
Total depozit 7.490,00
Total general 13.818,00
Pagina 1 din 1
c) Testarea şi evaluarea comportamentului la utilizare

Nivelul de percepţie al utilizatorilor (cca. 8 utilizatori):
Consistenţa (de la 1 – consistent la 5 – inconsistent): 1,60
Flexibilitate (de la 1 – flexibil la 5 – inflexibil): 1,85
Precizia (de la 1 – precis la 5 - imprecis): 1,53
...
Fig. 1.11 Model de specificaţie de proiectarea ieşirilor
Rezumat
Una dintre primele activităţi desfăşurate în faza de proiectare priveşte proiectarea ieşirilor din
sistem. În sistemele informaţionale economice, ieşirile se regăsesc, de cele mai multe ori, sub forma
formularelor/formatelor şi a rapoartelor. Un formular/format poate fi un document primar sau o machetă
de ecran care conţine unele date predefinite, numite şi date constante, cărora li se adaugă altele ce
urmează a fi completate, cunoscute şi sub numele de date variabile. Raportul este un document economic
în care sunt incluse doar date predefinite, fiind folosit în mod exclusiv pentru a fi citit sau vizualizat.
Principalul obiectiv urmărit la proiectarea ieşirilor constă în a prezenta informaţia solicitată într-o
formă inteligibilă, în locul potrivit, la momentul oportun şi numai utilizatorilor îndreptăţiţi. În acest sens,
la formularea specificaţiilor de proiectare, trebuie considerate următoarele caracteristici: scopul,
destinatarii, frecvenţa, conţinutul, sursa datelor, mediul de transmitere şi controlul.
Scopul ieşirilor determină unele aspecte de proiectare, cum ar fi ordinea de prezentare a coloanelor,
sortarea informaţiilor şi frecvenţa. Rapoartele generate de sistemele informaţionale economice pot fi
utilizate în luarea deciziilor, controlul activităţilor economice, transferul de informaţii în exteriorul firmei
sau întocmirea altor documente şi rapoarte.
Cunoaşterea destinatarilor constituie premise ale unei bune proiectări a ieşirilor, mai ales în ce
priveşte mecanismele de control, alegerea mediului de transmitere sau stabilirea numărului de exemplare
pentru fiecare ieşire. Din punctul de vedere al destinatarilor, pot fi identificate trei tipuri de ieşiri: interne,
externe şi documente în circuit.
Frecvenţa face referire la momentele la care se va genera fiecare ieşire din system, fie document, fie
raport. În funcţie de această caracteristică, rapoartele pot fi clasificate în patru categorii: rapoarte
programate, analize neprogramate, rapoarte la cerere şi rapoarte declanşate de excepţii.
Formatul ieşirilor defineşte modalitatea de organizare şi prezentare a informaţiilor. În acest sens,
cele mai utilizate forme de prezentare sunt: tabelară, zone predefinite şi grafică. Echipa de proiectare va
trebui să aibă în vedere regulile de proiectare specifice fiecărei forme.
Poate cea mai importantă caracteristică a ieşirilor o reprezintă conţinutul. Ea defineşte informaţiile
ce vor fi incluse într-un document sau raport, în funcţie de scopul pentru care ele sunt generate. În
legătură cu acestă caracteristică trebuie stabilite criteriile de ordonare a informaţiilor, precum şi nivelul
de detaliere, în funcţie de care putem avea trei tipuri de rapoarte: detaliate, sintetice şi dinamice.
Rapoartele dinamice se obţin prin combinarea rapoartelor sintetice cu cele detaliate, apelând la două
tehnici: „drill up-drill down” şi legarea rapoartelor. Acest tip de rapoarte oferă utilizatorului posibilitatea
schimbării interactive a nivelului de detaliere a informaţiilor afişate pe ecran.
Din punctul de vedere al sursei datelor, majoritatea ieşirilor se obţin prin accesarea bazei de date,
caz în care trebuie specificate tabelele, înregistrările şi câmpurile care vor fi citite. Alte surse pot fi
documente şi rapoarte primite de la alte sisteme sau baze de date publice.
Un alt element de proiectare a formularelor şi rapoartelor priveşte mediul de transmitere.
Majoritatea ieşirilor sunt tipărite pe hârtie sau afişate pe ecran, însă, astăzi sunt disponibile diverse alte
medii, precum cele audio şi video, schimbul electronic de date sau sistemele COM.
Pentru proiectarea formularelor/formatelor şi rapoartelor există numeroase reguli, recomandări şi
principii de lucru. Unele au caaracter general, altele sunt specifice unui anumit tip de ieşire. Pentru o mai
uşoară înţelegere şi reţinere a lor, ele au fost grupate în următoarele categorii: recomandări generale de
formatare a ieşirilor, reguli pentru evidenţierea informaţiilor, reguli de proiectare a tabelelor şi cele
pentru proiectarea graficelor.
O categorie aparte de reguli sunt cele care privesc controlul integrităţii ieşirilor. Din acest punct de
vedere, obiectivul urmărit la proiectarea ieşirilor constă în asigurarea completitudinii şi corectitudinii
informaţiilor conţinute, precum şi restricţionarea accesului la ele. În acest sens, cea mai eficace cale
constă în aplicarea procedurilor de control înainte de generarea şi distribuirea ieşirilor, cum ar fi limitarea
accesului la sistem, prin definirea utilizatorilor autorizaţi şi a drepturilor de acces. Alte două proceduri de
control sunt: separarea atribuţiilor şi controlul distribuirii ieşirilor.
Formularele/formatele şi rapoartele utilizate în sistem, indiferent că ele sunt intrări sau ieşiri,
reprezintă piesele cele mai importante pentru utilizatori. Acest fapt îi obligă pe specialişti să pună în
practică un demers de proiectare care să-i implice pe utilizatori. Demersul propus este unul iterativ şi
utilizează tehnica prototipizării. Principalele sale etape sunt: culegerea tuturor informaţiilor în legătură cu
documentele şi rapoartele solicitate, construirea câte unui prototip pentru fiecare ieşire, implementarea şi
utilizarea prototipului de către utilizatori, revizuirea prototipului pe baza observaţiilor utilizatorilor şi
conversia.
La finalul etapei de lucru trebuie întocmite specificaţiile de proiectare a formularelor şi
rapoartelor. Acest document conţine următoarele secţiuni: prezentarea descriptivă a ieşirii, modelul
proiectului şi testarea şi evaluarea comportamentului în utilizare.
Întrebări recapitulative
1. Explicaţi diferenţa dintre un formular/format şi un raport.
2. Care sunt obiectivele urmărite la proiectarea ieşirilor?
3. Care sunt sursele posibile pentru obţinerea ieşirilor din sistem.
4. Enumeraţi şi exemplificaţi tipurile de rapoarte în funcţie de frecvenţa de obţinere a lor.
5. Care sunt aspectele prin intermediul cărora se descrie conţinutul rapoartelor?
6. Explicaţi avantajele ieşirilor afişate pe ecran în comparaţie cu cele tipărite.
7. Efectuaţi o scurtă prezentare a mediilor de generare a ieşirilor din sistem.
8. Enumeraţi şi descrieţi 10 reguli de proiectare a rapoartelor tipărite.
9. Descriereţi zonele specifice rapoartelor în formă tabelară. Daţi un exemplu prin care să puneţi în
evidenţă aceste zone.
10. Explicaţi de ce este necesară şi în ce constă orientarea spre utilizator în procesul de proiectare a
ieşirilor.
Probleme
1. Daţi câte un exemplu de raport generat de sistemul analizat în studiul de caz în scopul luării unei
decizii, respectiv controlul unei activităţi.
2. Explicaţi conceptul de raport dinamic. Daţi un exemplu de raport construit pe baza tehnicii „drill up-
drill down”.
3. Prezentaţi un exemplu de grafic prin care să se reprezinte o serie de valori discrete. Precizaţi regulile
de proiectare folosite.
4. Prezentaţi trei exemple de rapoarte dintr-o firmă, pe tema propriului studiu de caz sau o alta la liberă
alegere, şi realizaţi o descriere critică a acestora.
5. Daţi un exemplu de aplicare a procedurii separării responsabilităţilor pentru controlul ieşirilor din
sistemul analizat în propriul studiu de caz.
6. Întocmiţi specificaţiile de proiectare pentru un raport.
CAPITOLUL II
Proiectarea interfeţelor utilizator
Obiective:
• Evidenţierea importanţei interfeţei utilizator în dezvoltarea sistemelor informaţionale
economice
• Definirea conceptului de interfaţă utilizator
• Prezentarea metodelor de interacţiune şi a echipamentelor folosite în dialogul om-calculator
• Înţelegerea diferenţei dintre interfeţele utilizator şi interfeţele sistem
• Explicarea manierei în care pot fi identificate interfeţele utilizator
• Descrierea principiilor de proiectarea şi a modului de aplicare a lor în scopul obţinerii unor
interfeţe utilizator de calitate
• Descrierea etapelor de lucru în proiectarea interfeţelor utilizator
• Prezentarea regulilor de proiectare a paginilor Web
• Descrierea mecanismelor pentru controlul corectitudinii şi validităţii datelor de intrare
• Formularea specificaţiilor de proiectare a interfeţelor utilizator
Intrările şi ieşirile în/din sistemele informaţionale au fost identificate şi descrise în faza de

analiză, iar elementele de proiectare a lor au fost discutate în capitolul anterior. Au fost
prezentate conţinutul specificaţiilor de proiectare a formularelor/formatelor şi a rapoartelor,
regulile şi demersul de proiectare a lor.
Preluarea intrărilor în sistem şi obţinerea ieşirilor se pot efectua în mod automat, însă, în
majoritatea situaţiilor, ele implică intervenţia omului, ceea ce determină existenţa
interacţiunilor dintre utilizator şi calculator. Pentru fiecare intrare se va proiecta un ecran care
să permită utilizatorilor să introducă datele de intrare. Fiecărei ieşiri îi va corespunde o
succesiune de dialoguri prin care utilizatorii vor putea să le genereze. De asemenea, utilizatorii
vor interacţiona cu calculatorul în vederea iniţierii operaţiunilor de prelucrare, scop în care se
va proiecta un sistem de meniuri. Toate aceste aspecte nu au fost luate în considerare anterior,
ele fiind tratate în acest capitol.
În practică, activităţile descrise în capitolul anterior şi cele care vor fi prezentate în acest
capitol sunt desfăşurate împreună. Noi am optat pentru tratarea lor separată, deoarece ele
solicită cunoştinţe şi abilităţi diferite.
2.1 Rolul interfeţelor utilizator în dezvoltarea

sistemelor informaţionale
Proiectarea interfeţelor reprezintă o activitate foarte importantă în dezvoltarea sistemelor

informatice, chiar critică, din perspectiva acceptării sistemului de către utilizatori. Acest lucru
este explicabil, dacă ţinem cont de faptul că interfaţa utilizator reprezintă acea parte a
sistemului pe care acesta o percepe în mod direct, cu care el interacţionează pentru a-şi realiza
sarcinile de lucru. Pe de altă parte, interactivitatea este una dintre caracteristicile esenţiale ale
sistemelor informaţionale economice, interfaţa utilizator constituind componenta cea mai
însemnată.
Proiectarea necorespunzătoare a bazei de date va afecta, în primul rând, proiectanţii de
programe şi programatorii, iar slaba proiectare a arhitecturii programelor şi a modulelor de
PROIECTAREA INTERFEŢELOR UTILIZATOR 41
program va face mai dificilă munca celor însărcinaţi cu testarea şi întreţinerea programelor.
Utilizatorii sistemului vor percepe mai puţin aceste carenţe în proiectarea sistemului, ei putând
fi nemulţumiţi de timpii de răspuns ai calculatorului la unele operaţii iniţiate de ei în timpul
exploatării. În schimb, proiectarea defectuoasă a interfeţelor utilizator va determina, de cele
mai multe ori, respingerea sistemului, chiar dacă acesta oferă mai multe funcţionalităţi decât
cele solicitate de utilizatori. Dimpotrivă, un sistem, care nu oferă toate cerinţele funcţionale
solicitate, ar putea fi acceptat de către utilizatori dacă dispune de interfeţe utilizator simple şi
prietenoase, care să ofere satisfacţie.
Boris Beizer, un pătimaş al umanizării relaţiilor cu calculatorul, precizează la un moment
dat că „toate relaţiile puternice sunt exprimate prin comunicare. Chiar mai mult, formele
comunicării dau expresie şi relaţiilor. Între dragoste şi ură nu e decât un pas: câteva cuvinte
neinspirate pot schimba prezentul cu trecutul – câteva comenzi necorespunzătoare pot
transforma dragostea faţă de un produs-program în ură. Mijloacele prin care trebuie să
comunicăm cu calculatorul şi cele prin care el comunică cu noi vor afecta în mod determinant
relaţia noastră cu acesta”9.
În acest capitol ne vom ocupa îndeosebi de proiectarea interfeţelor utilizator, nu înainte de
lămuri unele aspecte definitorii ale noţiunii de interfaţă, dată fiind complexitatea ei.
2.1.1 Definirea conceptului de interfaţă

Noţiunea de interfaţă este destul de des întâlnită în literatura informatică, deşi ea are şi o
accepţiune generală în limbajul curent, în sensul de element de legătură între două unităţi.
Dicţionarul explicativ al limbii române defineşte interfaţa foarte îngust, ca fiind
„suprafaţa de separare a porţiunilor care reprezintă faze diferite într-un sistem fizico-chimic”.
Din definiţie rezultă funcţia de separare, şi nu cea de legătură. Ulterior, în Dicţionarul
explicativ al limbii române – Supliment, apar termenii de interfaţare şi interfaţă.
Interfaţa, cu trimitere la domeniul electronicii, este „un dispozitiv care converteşte
semnalele electronice în aşa fel încât două aparate sau sisteme să poată comunica între ele”. Se
observă o schimbare radicală a poziţiei faţă de prima variantă, interfaţa fiind ceva care asigură
comunicarea între două sisteme. Aproape similar, interfaţarea este definită ca o
„interconectare a părţilor unui sistem sau a unor aparate astfel încât ele să îşi poată îndeplini
funcţia în mod corect, coordonat”.
Webster’s Encyclopedia Unbridged Dictionary of the English Language, Grammary
Books, New York/Avenal, New Jersey, ediţia din 1994, defineşte interfaţa astfel:
1. „O suprafaţă referitoare la o frontieră comună (sublinierea noastră) dintre două corpuri sau
spaţii.
2. Fapte, probleme, considerente, teorii, practici etc. avute în comun de două sau mai multe
discipline, proceduri sau domenii de studiu: interfaţa dintre fizică şi chimie.
3. O frontieră comună sau o interconexiune între sisteme, echipamente, concepte sau fiinţe
umane.
4. Computer Technology. a) echipament sau program conceput pentru a comunica informaţii
de la un sistem de echipamente electronice sau programe la altul.
b) orice reglementare privind astfel de comunicaţii…”.
Aşadar, pe scurt, interfaţa asigură comunicarea între două sau mai multe sisteme. În
informatică, o astfel de semnificaţie este des întâlnită, căpătând mai multe conotaţii.
Referindu-se la software-ul de sistem, Schulteis, Sumner şi Bock10 afirmă că „prin intermediul
echipamentelor electronice de calcul şi al unui timp anume destinat, software-ul sistemelor
acţionează ca o legătură sau interfaţă între sistemul de calcul şi programele de aplicaţii pe care
9. Beizer, B. – Personal Computer Quality: A Guide for Victims and Vendors, Van Nostrand Reinhold Company,
New York, 1986, p. 87.
10. Schulteis, R., Sumner, M., Bock, D. – Management Information Systems: The Manager’s View, Second Edition,
IRWIN, Homewood, Boston, 1992, p. 123.
utilizatorul doreşte să le execute”. Aceiaşi autori, la pagina 33, definesc interfaţa ca „o

conexiune la frontierele unui sistem sau subsistem. O interfaţă serveşte drept mediu de
conversie a ieşirilor unui sistem în intrări ale altuia”. De cele mai multe ori, funcţia de legare
între ele a două componente este realizată de un subsistem special proiectat în acest scop.
Pentru domeniul dezvoltării sistemelor informatice economice, prezintă interes următoarele
sensuri ale noţiunii de interfaţă:
• interfaţa dintre sistemul informaţional şi mediul său extern relevant, prin care se face
referire la intrările/ieşirile în/din sistem şi care pot să apară sub forma documentelor,
rapoartelor, a răspunsurilor la întrebări sau a unor simple structuri de date schimbate
cu alte sisteme informatice;
• interfaţa dintre componentele software ale sistemului informatic. Această accepţiune
face referire la legăturile dintre modulele unui program, care reflectă invocarea unui
modul de către un altul, şi parametrii transmişi între ele, sub formă de date elementare,
structuri de date sau informaţii de control;
• interfaţa dintre om şi calculator, în sensul unui mediu eficient de comunicare dintre
om şi calculator, pe baza căruia utilizatorii pot interacţiona cu calculatorul, pentru a
transmite comenzile şi datele, precum şi pentru a obţine informaţiile necesare. În
această accepţiune, interfaţa face referire la partea vizibilă a sistemului informaţional,
din punctul de vedere al utilizatorului.
Nu toate accepţiunile prezentate anterior vor fi tratate în acest capitol. Prima accepţiune
este utilizată în faza de analiză, la definirea ariei de întindere a sistemului, atunci când se
specifică funcţiile sistemului, intrările, ieşirile şi entităţile externe cu care interacţionează
sistemul. Acest sens a fost deja discutat, în volumul anterior, în capitolul destinat modelării
logice a prelucrărilor.
Cel de-al doilea sens este utilizat la proiectarea programelor şi procedurilor, iar cu el ne
vom întâlni în capitolul cinci. Atunci vom trata interfaţa ca unul dintre atributele de bază ale
modulelor de program.
Ultima accepţiune mai este referită şi sub denumirea de interfaţă a utilizatorului, definită
de Zwass11 ca „o combinaţie a mijloacelor prin care un utilizator interacţionează cu un sistem
electronic de calcul”. Ea constă din componente hardware şi software, care permit
utilizatorului să preia în sistem datale de intrare, în vederea stocării şi prelucrării lor, şi să
obţină informaţiile necesare în rezolvarea propriilor sarcini de lucru. Componentele hardware
se referă la echipamentele cu care interacţionează utilizatorii precum tastatura, mouse,
trackball, ecran, imprimantă etc. Componentele software ale interfeţei utilizator cuprind acele
elemente pe care utilizatorii le percep dintr-o aplicaţie, respectiv ecranele (formularele) pentru
culegerea şi introducerea datelor în calculator, meniurile şi dialogurile prin intermediul cărora
utilizatorii pot iniţia diferite operaţiuni, inclusiv afişarea şi tipărirea unor informaţii sub formă
de rapoarte.
Noţiunea de interfaţă utilizator ar putea fi definită într-un sens mai larg, prin includerea
altor componente care permit utilizatorilor să interacţioneze cu sistemul, precum documentaţia
utilizatorului, manualul de instruire, facilităţile de ajutor şi alte documentaţii, care sunt livrate
împreună cu echipamentele şi programele. Aceste elemente vor fi prezentate în capitolul 7 din
acest volum.
La o analiză mai atentă, şi subiectul capitolului următor (proiectarea logică a fişierelor
sistemului şi bazelor de date – pe scurt, modelarea logică a datelor) ar ţine tot de o astfel de
problematică: interfeţe om – calculator pentru culegerea datelor.
Ordinea în care sunt tratate cele trei capitole (proiectarea formularelor/ formate şi a
rapoartelor, proiectarea interfeţelor şi a dialogurilor, modelarea logică a datelor) poate fi
îndelung discutată. Secvenţa folosită în tratarea lor, de cele mai multe ori, este doar una logică:
11. Zwass, V. – Management Information Systems, WCB-Wm, C. Brown Publishers, Dubuque, 1992, p. 338.
precedentul capitol creează bazele celui ce urmează. În realitate, în practica de zi cu zi, ordinea
lor nu este secvenţială, ci, mai curând, paralelă sau iterativă.
O altă noţiune care prezintă importanţă în acest context este dialogul. În informatică, el
are aceeaşi semnificaţie ca şi în accepţiunea cotidiană: conversaţie între doi parteneri. Am
putea chiar afirma că proiectarea dialogurilor şi a interfeţelor reprezintă procesele de definire a
modalităţilor prin care oamenii şi calculatoarele schimbă informaţii.
În capitolul de faţă, ne vom ocupa de componentele software ale interfeţei utilizator, care
au rolul de a asigura dialogul între utilizator şi sistem. În capitolul anterior am descris aspectele
privind proiectarea formularelor/documentelor, care consemnează datele de intrare în sistem,
şi a rapoartelor, care conţin informaţiile solicitate de utilizator, obţinute în urma prelucrărilor.
Acum, vom urmări proiectarea ecranelor (formularelor), necesare pentru preluarea datelor de
pe formulare/documente şi salvarea lor în baza de date, a dialogurilor, care vor permite
utilizatorilor obţinerea rapoartelor, şi a meniurilor, prin intermediul cărora utilizatorii vor lansa
diferite operaţiuni, inclusiv cele pentru culegerea datelor şi obţinerea rapoartelor.
Pentru ecrane, în acest capitol, vom folosi şi noţiunea de formular, dar cu alt sens. Dacă în
capitolul anterior, prin formular se făcea referire la un document în care sunt consemnate
datele cu privire la diferite tranzacţii economice, în acest capitol el este sinonim cu cel de ecran
pentru culegerea datelor. Am optat pentru utilizarea ambelor noţiuni, deoarece unii sunt
familiarizaţi cu noţiunea de formular, de la englezescul „form”.
2.1.2 Identificarea interfeţelor utilizator

Identificarea interfeţelor utilizator este realizată în strânsă legătură cu prima accepţiune a
conceptului de interfaţă, cea care face referire la interacţiunile sistemului cu mediul său extern.
Această activitate presupune analiza atentă a intrărilor şi ieşirilor din sistemul informaţional,
pe baza diagramelor fluxurilor de date, elaborate în faza de analiză, şi a graniţelor
informatizării, stabilite la definirea strategiei de proiectare. Intrările şi ieşirile care depăşesc
graniţele pot prezenta interes din perspectiva proiectării interfeţelor utilizator. De exemplu,
fluxul de intrare FACTURA, primit de la entitatea externă FURNIZOR, sugerează necesitatea
proiectării unui ecran (formular) prin intermediul căruia utilizatorul să poată interacţiona cu
sistemul în vederea preluării şi stocării în baza de date a datelor din factură. De asemenea,
fluxul de ieşire JURNALUL DE CUMPĂRĂRI, transmis către entitatea externă
CONTABILITATE GENERALĂ, impune proiectarea unui set de dialoguri care să permită
utilizatorului generarea acestui raport.
Însă, nu toate intrările/ieşirile în/din sistem implică o interfaţă utilizator. Dacă unele
intrări şi ieşiri solicită utilizatorul, în mod direct şi hotărâtor, ele fiind referite ca interfeţe
utilizator, altele nu presupun intervenţia acestuia sau ea este minimală. De exemplu, unele date
sunt preluate automat în sistem cu ajutorul unor echipamente speciale, cum ar fi scanerele
optice sau cititoarele de coduri bară. Revenind la ciclul prelucrării datelor, discutat în volumul
anterior, este vorba despre metode de culegere automată a datelor.
De asemenea, unele rapoarte sau documente pot fi generate automat sau ca urmare a unei
intervenţii umane minime. De exemplu, generarea balanţei de verificare sintetică poate fi
realizată prin simpla selectare a unei opţiuni din meniul aplicaţiei. Aceste intrări şi ieşiri sunt
referite ca interfeţe sistem.
Principalele tipuri de interfeţe sistem sunt:
• Culegerea automată a datelor de intrare. Echipamente speciale, precum scanerele,
permit introducerea automată a datelor în sistem. Cititoarele de coduri bară, plasate în
punctele de vânzare – POS (point of sale), asigură preluarea automată în sistem a
datelor privind vânzările. Tot cu ajutorul cititoarelor de coduri bară, se poate
automatiza activitatea de inventariere a depozitelor de bunuri materiale.
• Intrări provenite de la alte sisteme informaţionale. Preocupările din ultimii ani,
privind integrarea sistemelor informaţionale, au determinat reducerea considerabilă a
redundanţei în culegerea datelor şi, ca o consecinţă, creşterea volumului de date

transferate între diferite sisteme. Integrarea poate fi realizată fie prin schimbul de
mesaje între sisteme, fie prin partajarea unei baze de date comune. În primul caz, o
intrare poate reprezenta un mesaj primit de la alt sistem prin intermediul schimbului
electronic de date – EDI (Electronic Data Interchange). Mesajul primit declanşează o
serie de prelucrări, exact ca şi cum utilizatorul le-ar fi iniţiat, dar fără ca acesta să
intervină. De exemplu, înregistrarea unei comenzi primite direct de la sistemul
informaţional al unui client poate declanşa procesul de livrare în vederea onorării
comenzii respective, fără ca utilizatorul să mai preia datele din comandă. În cel de-al
doilea caz, integrarea prin date a sistemelor informaţionale presupune accesarea unei
baze de date comune. Datele preluate şi stocate de un sistem vor putea fi accesate şi de
alte sisteme. De exemplu, informaţiile despre livrările efectuate, colectate şi stocate de
sistemul de gestiune a vânzărilor, pot fi accesate de către sistemul de încasări şi plăţi în
vederea verificării şi înregistrării operaţiunilor de încasare a clienţilor. O astfel de
intrare nu implică proiectarea unui ecran pentru introducerea datelor respective, ci
semnifică o operaţie de acces la un fişier întreţinut de un alt sistem. Ea poate sugera
doar includerea în program a unei fraze SELECT SQL.
• Ieşiri către alte sisteme informaţionale. Acest tip de interfeţe sistem reprezintă
imaginea în oglindă a tipului de interfeţe discutat la punctele anterioare. Înregistrarea
intrării în stoc a produselor finite poate determina generarea şi transmiterea automată a
unui mesaj către sistemul de gestiune a vânzărilor.
• Ieşiri care presupun intervenţie umană minimă. Există situaţii în care generarea şi
transmiterea rapoartelor se face automat, la anumite intervale de timp sau la date fixe,
sau în care interacţiunea cu sistemul este minimă, neimplicând proiectarea unor
dialoguri. De exemplu, situaţia detaliată a soldului pentru clienţii importanţi poate fi
generată şi transmisă periodic acestora, în mod automat.
În dezvoltarea sistemelor informaţionale este foarte importantă separarea clară a
interfeţelor utilizator de interfeţele sistem, deoarece proiectarea celor două tipuri de interfeţe
solicită expertiză şi tehnologii diferite. Dacă de proiectarea interfeţelor utilizator ne vom ocupa
în acest capitol, la proiectarea interfeţelor sistem ne vom referi în capitolul destinat proiectării
programelor, deoarece lor le corespund, adesea, module de programe speciale, pentru preluarea
automată a datelor sau generarea automată a informaţiilor.
2.2.2 Metode şi echipamente folosite

în dialogul om-calculator
Dacă interfaţa dintre utilizator şi calculator a fost, pe vremuri, practic imposibilă, făcând
referire la calculatoarele generaţiei inventatorilor, prin progresele din domeniu, în prezent se
vorbeşte despre o generaţie a utilizatorilor sau conducătorilor. Progresul înregistrat a fost atât
de rapid, încât a apărut nevoia atribuirii unui calificator pentru noua variantă, vorbindu-se
despre Graphical User Interface (GUI) – interfaţa grafică a utilizatorului.
Ar fi de ajuns doar să enumerăm câteva astfel de medii. Revoluţia s-a produs odată cu
lansarea pe piaţă a interfeţei grafice a utilizatorului de către Macintosh, bazată în mare parte pe
rezultatele înregistrate de Xerox Palo Alto Research Center. Noul mediu se bazează pe aşa-
zisele icons reprezentând obiecte sau acţiuni prin meniuri care să ajute la selectarea unei
acţiuni. Mouse-ul ajută la navigarea într-un astfel de mediu. Ulterior, au fost promovate alte
produse care încorporează elemente de interfaţă grafică a utilizatorului, dintre care le
enumerăm pe cele mai reprezentative: Windows (Microsoft), Presentation Manager din OS/2
(IBM şi Microsoft), Open Look (AT&T), GEM (Digital Research), NewWave (Hewlett-
Packard), NeXTStep (NeXT), Motif (Open Software Foundation).
Sunt progrese demne de semnalat în mediul grafic faţă de cel tradiţional, spunându-se că
munca utilizatorului se reduce cu 35%, datorită vitezei mai mari cu care se operează, iar erorile
scad cu 17%.
O altă soluţie a constituit-o noua interfaţă pentru calculatoarele dotate cu creioane
optice. Sistemul de operare PenPoint al firmei Go Corporation a însemnat o nouă modă în
interfeţele oferite utilizatorilor.
Interfeţele pentru preluarea/redarea vocii constituie încă un salt, deşi ca răspândire nu au
regimul celorlalte interfeţe. Mai nou, există interfeţele multimedia oferite utilizatorului pentru
acces la text, sunet, imagine.
2.2.3 Metode de interacţiune om-calculator

Literatura de specialitate oferă veritabile tratate ce descriu metodele de interacţiune dintre
om şi calculator, cu renumiţi autori, cum sunt: Steven Alter, Robert Buzzell, Robert Mann,
John Rockart, De Long David, Ralph Sprague, Eric Carlson, Edward Tufte, Efraim Turban, M.
Blattner, E. Schultz, J.S. Dumas, E.B. Fernandez, R.C. Summers, C. Wood, J.C. May, F.R.
McFadden, J.A. Hoffer, K.L. Norman, A. Porter, B. Shneiderman, V. Zwass, A. Varsegi, B.
Buzman, R. Schulteis, M. Sumner ş.a. Am prezentat această listă cuprinzătoare pentru a veni în
sprijinul acelora care, în noile variante de navigare prin bibliotecile Internet, să poată apela
direct numele susmenţionate. În aceeaşi idee, există şi zeci de reviste care, număr de număr,
oferă suficient material bibliografic pe tema interfeţei om – calculator.
Având în vedere varietatea metodelor de interacţiune, în continuare le vom descrie pe cele
mai utilizate dintre ele. Ulterior, vom analiza şi echipamentele cu o astfel de destinaţie.
2.2.3.1 Interacţiunea prin limbaj-comandă
Toate calculatoarele încep să funcţioneze prin comenzi, omul transmiţând calculatorului
ceea ce ar dori să execute. Se spune că un software bun este caracterizat prin multe opţiuni de
lucru, printr-o logică riguroasă, ceea ce ar însemna gramatica unui limbaj-comandă, precum şi
prin uşurinţa cu care intuim forma a ceea ce va genera comanda lansată în execuţie. Comenzile
trebuie să fie concepute astfel încât să răspundă cerinţelor tuturor categoriilor de utilizatori, de
la începători la avansaţi.
Există o mare varietate de tipuri de comenzi, enumerând aici pe cele mai cunoscute:
comenzi sintactice, comenzi mnemonice, comenzi-taste şi comenzi în limbajul natural.
Cea mai simplă comandă sintactică este cea prin care utilizatorul trebuie să tasteze mai
întâi toate informaţiile necesare, după o sintaxă foarte riguroasă, după care va lansa în execuţie
comanda respectivă, de regulă prin apăsarea tastei ENTER. Pentru exemplificare, să
considerăm comanda următoare:
DIR C:\SUBDIR\*.exe /p /w <ENTER>
Această comandă este familiară celor care au lucrat cu sistemul de operare MS-DOS şi are
ca efect afişarea condensată, ecran cu ecran, a informaţiilor despre fişierele cu extensia EXE
din subdirectorul SUBDIR de pe discul C.
Cele mai inteligibile şi mai simple comenzi sunt cele mnemonice, adică ele au un sens prin
cuvintele sau abrevierile utilizate. Este vorba despre formele folosite pentru comenzile
sistemelor de operare care pot fi utilizate fie prin numele lor în întregime, ca de exemplu
RENAME, fie prin primele trei litere, ceea ce înseamnă REN. Similar sunt utilizabile şi
comenzile VISUAL FOXPRO, cu diferenţa că, în aceste cazuri, formele abreviate înseamnă
utilizarea primelor patru caractere din comenzi.
Comenzile-taste constau în acţionarea unei taste anume, a unei taste funcţionale (F1, F2,
F3 etc.) sau a unei combinaţii de taste (se folosesc tastele CTRL, SHIFT, ALT) atunci când
programul este pregătit să accepte o nouă comandă. Diverse programe lansate în execuţie pot
redefini funcţiile tastelor funcţionale speciale, dându-le o semnificaţie dinamică. Sunt produse-
program care, pentru a uşura munca utilizatorului, oferă şabloane de carton ce pot fi ataşate
zonei tastelor funcţionale. Alteori, se lipesc mici etichete adezive pe taste, indicând noua lor
funcţiune.
Nu putem să nu consemnăm interacţiunea cu calculatorul prin limbaj natural, deşi ea se
află în stadiu incipient. Progresele se datorează cercetărilor din domeniul inteligenţei
artificiale, şi anume acelora referitoare la limbajul natural. Oricum, au fost concepute sisteme
care folosesc atât interfaţa prin voce, cât şi aceea care utilizează clasica tastatură a sistemelor
de calcul.
Spre deosebire de softul care comunică prin meniuri, în care opţiunile sunt afişate pe
ecran, comunicarea prin limbaj-comandă presupune ca opţiunile de lucru să se afle în mintea
utilizatorului. Acesta este motivul determinant pentru care softul orientat pe comenzi este mai
dificil de învăţat, pentru că trebuie însuşite comenzile ce pot fi utilizate. Dacă ele nu au o
logică, o oarecare apropiere de limbajul uman, misiunea de a le învăţa devine şi mai
anevoioasă. Totuşi, ele rămân încă bine apreciate în rândul multor informaticieni.
2.2.3.2 Interacţiunea prin meniuri
Interacţiunea prin meniuri este familiară majorităţii celor care utilizează astăzi
calculatorul. Aproape toate produsele-program dispun astăzi de meniuri.
Un meniu pune la dispoziţie o listă de opţiuni, relevante din punctul de vedere al
activităţii ce trebuie realizată, din care utilizatorul va selecta una, iar comanada
corespunzătoare va fi executată. Există mai multe modalităţi de selectare a unei opţiuni din
meniu, dintre care cel mai utilizat este cursorul, deşi operaţiunea poate fi realizată şi prin
atingerea cu degetul a unei zone anume, cu ajutorul mouse-ului, al unui creion special (light
pen) ş.a.
Opţiunile de selectat pot fi afişate în diverse moduri: prin coduri, cuvinte scurte (dar
foarte sugestive), fraze, imagini – icons, butoane sau combinaţii ale acestora, astfel că pot
exista multe tipuri de meniu. Vom prezenta în continuare cele mai utilizate dintre acestea.
Liste simple cu opţiuni
Unele produse-program folosesc meniurile într-o modalitate deosebit de simplă, cu
opţiuni multiple, de genul:
Creare fişier nomenclator
Salvare într-un fişier nou
Listare fişier nomenclator
…
Părăsire aplicaţie
Tastaţi opţiunea dumneavoastră şi apoi RETURN.
În acest tip de meniu, utilizatorul selectează opţiunea dorită, comanda este executată după
care se revine la meniu. În exemplul nostru, utilizatorul selectează o opţiune prin tastarea
literei evidenţiată cu caracter îngroşat. Un astfel de meniu prezintă avantajul simplităţii
navigării şi a memorării uşoare, însă ocupă porţiuni importante de ecran. De aceea, astăzi ele
nu mai sunt folosite.
Zone cu comenzi şi linii-meniu
Există produse-program care, imediat ce sunt lansate în execuţie, afişează comenzile într-
o anumită zonă sau, de cele mai multe ori, pe prima sau pe ultima linie a ecranului. Selecţia
uneia dintre comenzi se poate efectua prin câteva metode, cum ar fi: prima literă a cuvântului-
cheie, marcarea sau punctarea comenzii, apăsarea unei taste funcţionale. Astfel de meniuri se
regăseau în special în programele ce rulau sub sistemul de operare MS-DOS, mai cunoscute
fiind LOTUS 1-2-3 şi WORD PERFECT.
Cum cele mai multe calculatoare au tastele funcţionale pe linia de sus a tastaturii, în multe
produse-program comenzile se afişează pe ultima linie a ecranului, realizându-se astfel o
apropiere a lor. Se recomandă ca ordinea comenzilor să respecte şi ordinea tastelor funcţionale

de pe tastatură.
Liniile cu comenzi oferă câteva avantaje: nu ocupă mult loc pe ecran, pot fi păstrate în
permanenţă pe ecran, sunt uşor de folosit. Un dezavantaj constă în restricţia de a le condensa
într-un singur cuvânt care trebuie să fie sugestiv şi care, de cele mai multe ori, trebuie să
înceapă cu altă literă decât celelalte comenzi.
Meniuri de tip bară
Cele mai multe dintre produsele-program de astăzi dispun de meniuri-bară (menu bar).
Acest tip de meniu este plasat în prima linie a ecranului sau a unei ferestre a programului şi
oferă acces permanent la opţiunile sale, chiar şi atunci când utilizatorul lucrează în cadrul unui
ecran sau ferestre. Un meniu-bară constă dintr-o listă dinamică de categorii de acţiuni care
conduc utilizatorul la o listă de acţiuni specifice categoriei selectate, prezentată sub formă de
meniu drop-down. Figura 2.1(a) prezintă meniul de tip bară din procesorul de texte WORD şi
meniul drop-down aferent opţiunii FILE. Meniurile pot fi organizate pe niveluri, după cum se
poate observa în figura 2.1(b).
O caracteristică importantă a meniurilor se referă la definirea dinamică a opţiunilor
disponibile. Utilizatorul va avea acces numai la opţiunile potrivite acţiunii pe care o realizează
la un moment dat. Opţiunile care nu sunt disponibile la un moment dat sunt evidenţiate
distinct, de regulă prin utilizarea caracterelor de culoare gri. De exemplu, în meniul EDIT din
WORD, opţiunile CUT şi COPY nu vor fi active dacă nu este selectat un obiect sau o porţiune
de text din fereastra de lucru. Astfel, utilizatorul va şti ce acţiuni şi opţiuni sunt permise într-un
anumit context de lucru, determinând reducerea încărcării memoriei acestuia.
a) Exemplu de meniu drop-down
b) Exemplu de meniu în cascadă

Fig. 2.1 Exemple de meniuri pop-up şi drop-down
Meniuri context
Cel mai nou tip de meniu, utilizat în interfeţele utilizator, este meniul context, numele său
provenind de la faptul că opţiunile afişate depind de contextul de lucru în care se află
utilizatorul. El mai este numit şi meniu pop-up, deoarece apare pe ecran, lângă obiectul
selectat, imediat după apăsarea butonului dreapta al mouse-ului sau a unei taste anume. Figura
2.2 prezintă meniul context asociat unui obiect de tip căsuţă de text, din Power Point.
Un meniu context conţine doar opţiunile de lucru specifice obiectului selectat. De obicei,
se includ doar opţiunile utilizate mai frecvent, care sunt accesibile şi din meniul bară al
produsului-program. Astfel de meniuri pot fi proiectate pentru fiecare element din fereastra de
lucru care poate fi selectat de utilizator: imagine (icon), căsuţă de text etc.
Meniu prin imagini
Fig. 2.2 Exemple de meniu context şi icons
Meniuri prin imagini/pictograme (icons)

Meniurile prin imagini constituie, de fapt, meniuri cu linii de comenzi în care acţiunile de
întreprins sunt exprimate prin imagini (icons), şi nu prin cuvinte. Imaginile sunt cât se poate de
sugestive, facilitând utilizarea, memorarea şi recunoaşterea lor. Totuşi, simbolistica desenelor
rămâne deocamdată un element de studiu pentru specialişti, deoarece generalizarea lor necesită
mult timp, cu atât mai mult cu cât mulţimea simbolurilor se extinde continuu.
Prin imagini pot fi redate uşor substantivele, destul de mulţumitor verbele, dar foarte
dificil adjectivele şi aproape fără speranţă adverbele. Iată de ce meniurile prin imagini nu pot
lua forme prea performante. Până şi sensurile simbolurilor diferă de la o cultură la alta. Dacă
un chinez ar dori să creeze o imagine prin care să sugereze salvarea tuturor elementelor-
problemă (a se citi un necaz) lui i-ar veni foarte uşor, întrucât în simbolistica chineză necazul
se poate reprezenta prin imaginea a două femei sub acelaşi acoperiş. Câţi americani sau
europeni ar atribui sensul acesta imaginii respective?
Meniurile bazate pe imagini (icons) fac parte din categoria cunoscută în literatură ca
interacţiune bazată pe obiecte. Imaginile folosite funcţionează ca butoanele. La „apăsarea” lor
(a se citi selecţia lor) se activează o anumită funcţie sau comandă (salvare, imprimare, căutare
ş.a.). În figura 2.2 este prezentat meniul bazat pe imagini din Power Point.
2.2.3.3 Interacţiunea prin ecrane pentru introducerea datelor (formulare)

Cea mai utilizată metodă de interacţiune om-calculator este, probabil, cea bazată pe
ecrane pentru introducerea datelor, numite şi formulare (forms). Prin această metodă,
utilizatorii vor completa diferitele câmpuri din ecrane, cu date preluate adesea din documentele
primare (formate/formulare), a căror proiectare a fost discutată în capitolul anterior. Datele
introduse sunt, de obicei, salvate în baza de date. Ecranele sunt, de asemenea, utilizate pentru
vizualizarea într-o formă logică, structurată, a datelor din bază.
La construirea formularelor se apelează la o serie de obiecte de control, utilizabile pentru
introducerea datelor, referite adesea, pe scurt, prin controale. Forma celor mai utilizate obiecte
de control este prezentată în figura 2.3, iar descrierea lor se regăseşte în tabelul 2.1. În prima
coloană a tabelului am inclus, între paranteze, denumirea lor în limba engleză, întâlnită în
mediile de programare vizuale.
Fig. 2.3 Principalele tipuri de obiecte de control utilizate la construirea formularelor
Tabel nr. 2.1 – Principalele tipuri de controale regăsite în formulare

Obiect de control Descriere şi caracteristici principale
Căsuţă de text Este tipul de obiect cel mai utilizat în construirea formularelor. El este
(Text box) folosit pentru preluarea datelor introduse de la tastatură, pe o singură linie.
Căsuţele de text pot fi proiectate astfel încât datele introduse să fie limitate
la o anumită lungime sau un anumit format. Atunci când logica aplicaţiei o
permite, se recomandă scrierea unei valori implicite, pe care utilizatorul o
poate păstra sau modifica.
Etichetă Cu ajutorul etichetei se pot afişa texte în poziţii bine precizate din
(Label) formulare. Aceste texte însoţesc căsuţele de text sau alte tipuri de controale
şi se referă la titluri, explicaţii sau indicaţii referitoare la ceea ce trebuie să
introducă utilizatorul.
Căsuţă cu listă Ea este derivată din căsuţe de text, fiind utilizată pentru selectarea unui
(List box) element dintr-o listă de valori predefinite. Prin acest tip de obiect se evită
introducerea unei valori de la tastatură, oferindu-se utilizatorului o listă de
valori din care poate alege una. Se reduce astfel riscul introducerii de date
eronate deoarece utilizatorul specifică o valoare corectă de vreme ce ea
este afişată.
Căsuţă combinată Ea reprezintă o combinaţie între căsuţele de text şi cele de tip listă. O
(Combo box) căsuţă combinată conţine de asemenea o listă predefinită de valori din care
poate fi aleasă una, ca în cazul căsuţei cu listă, dar permite în acelaşi timp
Obiect de control Descriere şi caracteristici principale

adăugarea de valori noi, precum în căsuţele de text.
Grilă (grid) Acest tip de obiect este adesea utilizat în formularele concepute pentru
culegerea datelor din documentele primare. O grilă este formată din mai
multe coloane în care se introduc datele privind detaliile din documente,
cum ar fi denumirea, cantitatea, preţul şi valoarea mărfurilor dintr-o
factură. Coloanele apar sub formă de căsuţe de text, dar şi căsuţe
combinate.
Butoane de opţiune sau Acest tip de obiect asociază mai multe opţiuni din care utilizatorul poate
butoane radio alege una singură. Atunci când se dă clic pe una dintre opţiuni, cea care
(Option buttons sau Radio era anterior selectată va fi automat dezactivată, astfel că la un moment dat
buttons) o singură opţiune va fi activă. Deoarece toate opţiunile posibile sunt afişate
în formular, acest tip de obiect este utilizat atunci când numărul
alternativelor este mic şi ele nu se modifică în timp.
Căsuţă de validare O căsuţă de validare este asemănătoare cu butoanele de opţiuni, în sensul
(Check box) că ea conţine mai multe opţiuni, dar din care utilizatorul poate activa
oricâte şi nu doar una. Activarea/dezactivarea unei opţiuni din listă se
efectuează prin simpla selectare a ei de la tastatură sau mouse.
Cadru de pagină El permite crearea de pagini suprapuse într-un formular. Fiecare pagină va
(Page frame) avea nume, conţinut şi funcţionalitate proprii. Cadrele de pagini se
utilizează atunci când funcţionalitatea unui formular poate fi separată în
mai multe părţi strâns legate, pentru fiecare construindu-se câte o pagină.
O pagină va conţine obiecte de celelalte tipuri.
Buton de comandă El oferă utilizatorului posibilitatea declanşării unei acţiuni sau operaţiuni,
(Command button) cum ar fi tipărirea la imprimantă, salvarea datelor introduse, închiderea
formularului.
În figura 2.4 este prezentat un exemplu de formular pentru introducerea şi vizualizarea
datelor referitoare la achiziţia de mărfuri.
Fig. 2.4 Exemplu de formular pentru culegerea datelor privind cumpărările de la furnizor
Datele din formular privesc documentele primite de la furnizori, facturi şi/sau avize de
expediţie, şi cele de recepţionare a mărfurilor. Formularul prezentat conţine, în partea sa
superioară, o secţiune pentru filtrarea datelor afişate şi căutarea documentelor. Primele două
căsuţe de text, din partea stângă, permit utilizatorului să specifice intervalul de timp pentru
care se vor afişa date în formular, iar butoanele radio şi căsuţa de text din partea dreaptă vor fi
utilizate pentru a specifica tipul şi numărul documentului pe care utilizatorul doreşte să-l caute
şi să-l afişeze. De asemenea, formularul conţine două pagini, respectiv FACTURI/AVIZE şi
RECEPTII, în figura 2.4 fiind afişată prima pagină. Această pagină conţine două grile: prima
afişează date despre documentele (facturi şi avize) primite de la furnizori şi înregistrate în
perioada specificată anterior; cea de-a doua grilă prezintă detaliile documentului selectat din
prima grilă. După cum se poate observa, unele coloane din cele două grile sunt de tip căsuţe
combinate. Cele două grile pot fi utilizate şi pentru adăugarea datelor. În partea de jos a
paginii, se regăsesc butoanele, prin intermediul cărora se pot iniţia diferite acţiuni, precum
adăugarea sau salvarea unui document.
O problemă foarte importantă în construirea formularelor/ecranelor o constituie
proiectarea navigării între câmpuri şi în interiorul lor. Navigarea trebuie să fie de la stânga la
dreapta şi de sus în jos, însă cu posibilităţi de revenire, la cerere. Formularele pentru
introducerea datelor trebuie să încorporeze şi alte categorii de funcţiuni comune. O parte dintre
acestea sunt enumerate în tabelul 2.2.
Tabel nr. 2.2 – Funcţiuni ce trebuie incluse în interfeţele
din programele de introducere a datelor
Categorie de Exemple
funcţiune
Deplasarea în Deplasarea de la un câmp la următorul/precedentul/primul/ultimul.
formular
Posibilităţi de Ştergerea unei linii dintr-o grilă (grid), a tuturor datelor din formular.
editare Inserarea unor caractere printre cele existente
Salvarea conţinutului formularului în baza de date.
Confirmarea salvării formei editate sau trecerea la un alt ecran.
Facilităţi de ieşire
Ieşirea temporară într-un mediu de lucru ajutător (vizualizare ceas, folosire
calculator de buzunar etc.).
Oferirea Furnizarea de informaţii despre orice câmp sau despre întregul formular.
informaţiilor
ajutătoare
Restricţionarea accesului utilizatorilor.
Posibilităţi de Identificarea şi autentificarea utilizatorilor.
control al accesului Interzicerea modificărilor/ştergerilor înregistrărilor anterioare care au un regim
special.
Dacă este posibil, să se folosească valorile implicite (data curentă, preţul de
catalog al produselor).
Trecerea automată în câmpul următor, atunci când s-a introdus un anumit număr
de caractere.
Facilităţi oferite la
Nominalizarea prin titluri a conţinutului casuţelor de text şi a altor obiecte ce
introducerea
afişează date.
datelor
Indicarea unităţilor de măsură, atunci când este cazul.
Oferirea exemplelor de formate folosite, cum ar fi cele pentru numere de telefon,
sau date calendaristice.
Alinierea automată a datelor introduse.
Verificarea dacă datele sunt cele aşteptate (exemplu: sumele încasate sunt egale cu
cele de încasat?).
Tehnici de validare Testarea lipsei datelor în unele câmpuri.
a datelor introduse Verificarea încadrării valorilor în anumite intervale (exemplu: notele să fie în
intervalul 0-10).
Apelarea la tehnica cifrei de control.
2.3 Principii de lucru în proiectarea

interfeţelor utilizator
Importanţa calităţii interfeţelor utilizator, în succesul unui sistem informatic, a determinat
specialiştii să se preocupe de formularea unor principii de proiectare, care să ghideze
proiectanţii în obţinerea unor interfeţe de calitate.
În acest cadru se înscriu şi preocupările producătorilor de software, de a defini un set de
principii şi reguli pe care să le aplice în dezvoltarea produselor lor. Cei mai importanţi dintre
aceştia (mai ales furnizorii de sisteme de operare) au publicat propriile reguli încorporate în
produsele lor. Dintre acestea, amintim pe cele ale firmelor Apple Computer Inc (1992), IBM
Corporation (1992), UNIX OSF/Motif (Open Software Foundation, 1993), Microsoft
Corporation (1995).
În literatura de specialitate pot fi găsite numeroase opinii în legătură cu principiile şi
regulile de proiectare a interfeţelor utilizator. În privinţa interfeţelor grafice, există aspecte
comune tuturor mediilor de acest gen (Microsoft Windows12, Macintosh13 ş.a.), dar şi elemente
specifice fiecăruia dintre ele. Unii specialişti se limitează la prezentarea principiilor cu
aplicabilitate generală, alţii formulează reguli specifice, în funcţie de platformele hardware şi
sistemele de operare utilizate, cerinţele sistemului sau obiectivele definite pentru proiectarea
interfeţelor. De exemplu, Rubenstein şi Hersch au identificat şi prezentat în cartea lor, „The
Human Factor” (1984), nu mai puţin de 93 de principii de lucru14. Ben Shneiderman propune 8
reguli de bază aplicabile în majoritatea sistemelor interactive15, prezentate în tabelul 2.3. Noi
vom insista asupra principiilor general valabile, întrucât particularul este surprins în
materialele citate anterior.
Tabel nr. 2.3 –Regulile de bază ale proiectări

interfeţelor utilizator formulate de Shneiderman
Regula Descriere
1. Asigurarea uniformităţii Utilizarea aceleiaşi secvenţe de dialoguri în situaţii similare; a unei
terminologii unitare în meniuri, ecrane, mesaje etc.
2. Prevederea de comenzi Utilizarea tastelor funcţionale, a combinaţiilor de taste în locul
scurte accesării meniurilor sau a selectării unor butoane de comandă cu
mouse-ul, determină reducerea numărului de interacţiuni, cu efecte
imediate asupra productivităţii, mai ales în cazul operaţiunilor
repetitive.
3. Furnizarea retroacţiunii În cazul acţiunilor cu frecvenţă mică şi/sau de importanţă mare este
foarte importantă informarea utilizatorului în legătură cu rezultatele
acţiunilor iniţiate. Pentru acţiunile cu frecvenţă mare sau a celor de
importanţă redusă, mesajele de răspuns din partea sistemului pot fi
12. Porter, A. – C++ Programming for Windows, McGraw-Hill, Berkeley, 1993; Bachenski, B. – „GUI Builders
Pay Price for User Productivity”, in Software Magazine, April 1992; Greenbaum, J. – „The Evolution
Revolution”, in Information Week, March 14, 1994; Haarind, R. – „Software’s New Object Lesson”, in
Technology Review, February-March, 1992; Jalics, P.J. – „COBOL on a PC: A New Perspective on a Language
and Its Performance”, in Communications of ACM 30, nr. 2, February 1987; Mandelkern, D. – „Graphical User
Interfaces: The Next Generation”, in Communication of ACM 36, nr. 4, April 1993; Morse, A., Reynolds, G. –
„Overcoming Current Growth Limits in UI Development”, in Communications of ACM 36, nr. 4, April 1993;
Wiederhold, G., Wegner, P., Ceri, S. – „Toward Megaprogramming”, in Communications of ACM 35, nr. 11,
November 1992.
13. May, J.C. – Extended the Macintosh Toolbox: Programming Menus, Windows, Dialogues and More, Addison-
Wesley, Reading, Massachusetts, 1991.
14. Autorii sunt referiţi în Mandel, T. – The Elements of User Interface Design, John Wiley & Sons, 1997, New
York, p.49.
15. Shneiderman, B. – Designing the User Interface, Addison Wesley, 1998, Third Edition,
http://www.cs.utexas.edu/users/almstrum/cs370/elvisino/rules.html
Regula Descriere
simplificate sau chiar eliminate.
4. Marcarea sfârşitului Orice dialog trebuie să fie organizat ca o secvenţă de acţiuni în care să
dialogurilor existe un început, un mijloc şi un sfârşit.
5. Gestiunea simplă a erorilor Sistemul trebuie proiectat astfel încât să limiteze posibilitatea ca
utilizatorul să comită erori grave. Totuşi, dacă se întâmplă, sistemul va
oferi mecanisme simple şi inteligibile de detectare şi gestionare a
erorilor.
6. Prevederea operaţiunilor Interfaţa trebuie să-i permită utilizatorului să folosească acţiunea
reversibile inversă celei anterioare, cum ar fi readucerea unui element şters.
Unităţile de reversibilitate pot fi o acţiune simplă, o introducere de date
sau un grup complet de acţiuni.
7. Controlul aplicaţiei de Utilizatorii experimentaţi doresc ca ei să fie cei care controlează
către utilizator aplicaţia. Aplicaţia trebuie astfel proiectată încât utilizatorii să joace
rolul de iniţiatori ai acţiunilor şi nu pe cel de respondenţi.
8. Reducerea volumului de La proiectarea interfeţelor trebuie luate în considerare limitele
informaţii pe care memoriei umane pe termen scurt. Formularele vor fi simple, se vor
utilizatorul trebuie să-l evita trecerile de la un formular la altul etc.
memoreze pe termen scurt
O tratare mai completă a principiilor generale de proiectare a interfeţelor utilizator a fost

realizată de Mandel. El le grupează în trei reguli de bază (golden rules)16:
1. Controlul aplicaţiei de către utilizator,
2. Limitarea volumului de informaţii pe care trebuie să-l memoreze utilizatorul şi
3. Uniformitatea interfeţelor utilizator.
În continuare, ne vom folosi de această clasificare pentru a descrie principalele principii
de proiectare a interfeţelor, enumerate în tabelul 2.4.
Tabel nr. 2.4 –Principalele principii de proiectare a interfeţelor utilizator

Reguli de bază Principii de proiectare
Controlul aplicaţiei de 1. Utilizarea judicioasă a modurilor de lucru
către utilizator 2. Retroacţiunea (feed-back) imediată
3. Pǎstrarea stilului de lucru al utilizatorilor
4. Alegerea între utilizarea tastaturii şi/sau a mouse-ului
5. Asigurarea transparenţei detaliilor de proiectare a programelor şi a bazei de
date
Limitarea volumului de 1. Degrevarea utilizatorului de memorarea pe termen scurt a unor informaţii
informaţii pe care 2. Proiectarea de interfeţe orientate pe recunoaştere, nu pe amintire
trebuie să-l memoreze 3. Prevederea formelor scurte de lucru
utilizatorul 4. Relevanţa vizuală a interfeţelor
Uniformitatea 1. Uniformitatea modului de prezentare a interfeţei
interfeţelor utilizator 2. Uniformitatea în comportamentul interfeţei
3. Uniformitatea interacţiunii cu interfaţa utilizator
2.3.1 Controlul aplicaţiei de către utilizator

Conform acestei reguli, o interfaţă trebuie concepută astfel încât utilizatorul să simtă că el
este cel care controlează aplicaţia şi nu invers. Utilizatorul este cel care iniţiază diferitele
operaţiuni, controlând astfel derularea proceselor realizate cu calculatorul. El va juca un rol
activ şi nu unul reactiv.
Pentru a înţelege mai bine esenţa acestei reguli de bază, vom apela la o analogie. Să
considerăm că o persoană doreşte să asculte albumul „Innuendo” al formaţiei rock Queen şi are
16. Mandel, T. – The Elements of User Interface Design, John Wiley & Sons, New York, 1997, p. 48.
la dispoziţie două variante: să utilizeze un magnetofon sau o combină audio performantă, cu

unitate CD. În cazul utilizării magnetofonului, „melomanul” va trebui să potrivească banda
respectivă, să-l pornească, după care să se aşeze confortabil într-un fotoliu şi să asculte. Numai
că, el va fi obligat să asculte piesele de pe album în ordinea înregistrării lor, fără a-şi putea
alege o ordine preferată. Aşadar, el este sub controlul magnetofonului.
În cazul utilizării combinei audio, ascultătorul va putea să personalizeze audiţia
albumului, în sensul alegerii ordinii pieselor sau chiar a reluării unora dintre ele. De data
aceasta, audiţia albumului este sub controlul ascultătorului. Însă, pentru o astfel de audiţie,
persoana respectivă trebuie să îndeplinească două condiţii: 1) să cunoască comenzile combinei
audio, ceva mai complexe decât în cazul magnetofonului şi 2) să cunoască piesele de pe
albumul „Innuendo”, pentru a fi în măsură să stabilească ordinea preferată de ascultare a lor.
În mod asemănător se pune problema şi în cazul aplicaţiilor informatice. Ordinea de
execuţie a anumitor operaţii poate să fie sub controlul utilizatorului sau al aplicaţiei.
Aplicaţiile interactive, dezvoltate până în anii ’80, dispuneau de interfeţe „la modul caracter”,
în care utilizatorul era complet sub controlul acestora, el având un rol reactiv. O astfel de
interfaţă este prezentată în figura 2.5.
Doriţi să adăugaţi un nou material (d/n)? d
Introduceţi codul materialului: 108250
Introduceti denumirea materialului: Cherestea fag
Introduceti unitatea de măsură: mc
Introduceti preţul: 56,20
Doriţi sa salvaţi (d/n)? d
Fig. 2.5 Exemplu de interfaţă în care utilizatorul este sub controlul aplicaţiei
Când se aplică această regulă, se va lua în considerare categoria de utilizatori pentru care
este proiectată interfaţa, adică experienţa lor în lucrul cu calculatorul şi cea din domeniul de
activitate pentru care este dezvoltat sistemul. Revenind la analogia cu audiţia albumului
„Innuendo”, pentru ca „melomanul” să poată beneficia de avantajele oferite de combina audio,
el trebuie să cunoască comenzile acesteia şi conţinutul albumului. Transpunând aceste două
cerinţe în sfera proiectării interfeţelor, utilizatorul se va putea bucura de deţinerea controlului
asupra aplicaţiei numai dacă este familiarizat cu interfeţele grafice şi cu sarcinile de lucru din
sistemul informaţional.
În continuare, vom prezenta cele mai importante dintre principiile a căror aplicare
conduce la punerea în practică a acestei reguli.
2.3.1.1 Principiul utilizării judicioase a modurilor de lucru
Printr-un mod de lucru se înţelege un context în care se află aplicaţia la un moment dat, în
care utilizatorul poate efectua doar anumite operaţiuni sau de care depinde funcţia pe care o
realizează un obiect al interfeţei. De regulă, atunci când utilizatorul se află într-un mod de
lucru, nu i se permite să lucreze în altă parte a aplicaţiei.
Utilizatorii calculatoarelor sunt obişnuiţi cu modurile de lucru, deoarece ele pot fi
observate uşor în majoritatea programelor. Un exemplu comun este dat de modurile de lucru
insert/overwrite dintr-un procesor de texte, trecerea dintr-un mod de lucru în celălalt
realizându-se prin apăsarea tastei Insert.
În cele mai multe aplicaţii, formularele concepute pentru actualizarea bazei de date conţin
modul de lucru vizualizare, în care utilizatorii pot afişa informaţiile, dar nu le pot modifica.
Ecranul din figura 2.4 permite, la încărcarea acestuia, afişarea facturilor/avizelor primite de la
furnizori, dar nu şi adăugarea sau modificarea lor. Pentru a modifica datele referitoare la un
document, utilizatorul trebuie să-l selecteze şi să intre în modul de lucru modificare, prin
apăsarea butonului MODIFICA DOC. Intrarea în modul de lucru adăugare se face prin apăsarea
butonului DOC. NOU. Imediat după salvarea datelor modificate/adăugate, se revine la modul de
lucru vizualizare.
Modurile de lucru limitează controlul utilizatorului asupra aplicaţiei, deoarece acesta nu
poate realiza decât operaţiunile permise în contextul de lucru respectiv. În plus, utilizatorul va
fi nevoit să efectueze un număr suplimentar de operaţiuni, pentru a trece de la un mod de lucru
la altul. Din acest motiv, apelarea la modurile de lucru trebuie temeinic justificată.
Chiar dacă utilizarea modurilor de lucru limitează controlul utilizatorului asupra
aplicaţiei, ele se regăsesc în majoritatea aplicaţiilor. Ele trebuie utilizate numai atunci când
sunt necesare, evitându-se plasarea utilizatorului în moduri de lucru inutile. Întrebarea „Când
este justificată şi când nu utilizarea modurilor de lucru?” nu are un răspuns general valabil.
Câteva dintre cazurile care justifică utilizarea modurilor de lucru sunt:
• Utilizatorii sunt neexperimentaţi în lucrul cu interfeţele grafice sau în activităţile
derulate în cadrul sistemului, fiind de dorit un control mai bun al operaţiunilor
realizate de ei cu ajutorul calculatorului. Astfel, se evită apariţia erorilor datorate
iniţierii greşite a unor operaţiuni.
• Restricţionarea accesului, atunci când există categorii de utilizatori cu drepturi de
acces diferite. Unii utilizatori pot avea drepturi de modificare sau anulare a facturilor,
iar alţii doar pe cele de vizualizare a acestora.
• Simplificarea formularului, prin schimbarea funcţiilor unor butoane de la un mod de
lucru la altul, pentru a se evita includerea unui număr prea mare de butoane. De
exemplu, prin transformarea butoanelor de comandă ADAUGARE şi MODIFICARE, din
modul de lucru vizualizare, în SALVARE şi ABANDON, în modurile de lucru adăugare
şi modificare, formularul va conţine doar două butoane în loc de patru.
Un alt aspect, demn de luat în considerare, la analiza justeţei includerii modurilor de
lucru, se referă la numărul de operaţiuni suplimentare necesare pentru trecerea de la un mod de
lucru la altul. Dacă, la introducerea facturilor/avizelor, utilizatorul va fi nevoit să comute între
modurile de lucru adăugare şi vizualizare pentru fiecare document în parte, atunci el ar putea fi
nemulţumit de productivitatea muncii sale, mai ales dacă numărul de documente ce trebuie
operate este mare. Ar fi mai simplu ca ei să poată adăuga date fără a mai fi necesară selectarea
butonului ADAUGARE, pentru fiecare document în parte. Prin urmare, utilizarea modurilor de
lucru este neproductivă în cazul operaţiunilor de actualizare cu frecvenţă mare.
Atunci când sunt utilizate, este obligatorie semnalarea, în orice moment, a modului de
lucru în care se află utilizatorul. În acest sens, există mai multe posibilităţi. De exemplu, în
Microsoft Word, intrarea în modul de lucru „Draw” este semnalat prin schimbarea pointerului
de mouse în semnul „+”. Pentru diferenţierea între modurile vizualizare şi modificare, se pot
utiliza culori diferite pentru fundalul câmpurilor din formular, de regulă gri pentru vizualizare
şi alb pentru modificare. O altă modalitate priveşte introducerea unui mesaj în linia de stare,
care să arate în orice moment utilizatorului modul de lucru în care se află (vezi mesajul cu roşu
din formularul prezentat în figura 2.4).
Aşadar, aplicarea acestui principiu este strâns legată de cel care va fi discutat în
continuare, respectiv principiul retroacţiunii imediate.
2.3.1.2 Principiul retroacţiunii (feed-back) imediate
Acest principiu ar putea fi reformulat prin imperativul „Nu lǎsaţi utilizatorul în ceaţǎ!”.
Interfaţa trebuie sǎ indice utilizatorului, dupǎ caz, dacǎ acţiunea iniţiatǎ de el a fost realizatǎ,
fie sǎ afişeze rezultatul acţiunii sale. Dacă execuţia operaţiunii dureazǎ mai mult timp, atunci
utilizatorul trebuie să aibǎ confirmarea cǎ operaţiunea este în curs de execuţie şi sǎ fie informat
despre starea ei. Starea execuţiei unei operaţiuni poate fi afişată sub forma timpului rǎmas
pânǎ la finalizare sau sub forma procentelor din operaţiune care au fost executate. De
asemenea, este necesară precizarea modului în care operaţiunea poate fi suspendatǎ sau
anulatǎ. De exemplu, la descǎrcarea unui fişier de pe un site web, pe ecran va fi afişat în
permanenţǎ, în procente, partea din fişier care a fost transferată.
În general, informarea utilizatorului despre acţiunea iniţiatǎ de el poate fi fǎcutǎ în mai
multe moduri: prin actualizarea liniei de stare a ferestrei de lucru, prin afişarea unui mesaj sau
prin iniţierea unei casete de dialog.
Lipsa retroacţiunii creeazǎ utilizatorului o stare de nesiguranţǎ şi discomfort, şi-l obligǎ la
eforturi suplimentare, pentru a se asigura cǎ operaţiunea iniţiatǎ de el a fost realizatǎ. Dacă, în
formularul din figura 2.4, utilizatorul nu ar primi un mesaj de confirmare a operaţiunii de
anulare a unei facturi, el ar fi nevoit să verifice dacǎ operaţiunea respectivǎ a fost înregistratǎ
în baza de date, afectând astfel productivitatea muncii sale.
2.3.1.3 Principiul pǎstrării stilului de lucru al utilizatorilor
În general, la proiectarea unui nou sistem informatic trebuie menţinut stilul de lucru al
utilizatorilor, iar eventualele modificǎri să fie explicate acestora. Experienţa anterioarǎ,
aşteptǎrile, pǎrerile, convingerile şi dorinţele utilizatorilor trebuie să se regǎsească în interfaţă.
Experienţa anterioarǎ a utilizatorilor cu sistemele informatice determinǎ, în bunǎ mǎsurǎ,
aşteptǎrile lor privind modul de funcţionare a noului sistem. De cele mai multe ori, puşi în
situaţii noi sau complexe, oamenii încearcǎ sǎ simplifice lumea din jurul lor şi sǎ gǎseascǎ
similitudini cu lucruri pe care ei le înţeleg şi vor acţiona în maniera în care ei cred cǎ ar trebui
sǎ se desfǎşoare acele lucruri. Prin urmare, ei vor reacţiona în funcţie de aşteptǎrile lor.
Edificator în acest sens, este întâmplarea din urmă cu câţiva ani cu angajatul unei firme
americane, care utiliza unitatea de CD-ROM ca suport pentru ceaşca de cafea, plecând,
probabil, de la experienţa anterioară şi asemănarea relativă cu dispozitivul destinat acestui scop
din autoturismul propriu.
De aceea, membrii echipei de proiectare va trebui sǎ ştie cât mai multe despre utilizatorii
sistemului, despre sarcinile de lucru pe care ei trebuie sǎ le realizeze, despre cunoştinţele lor în
domeniul informaticii, despre experienţa pe care o au în lucrul cu sistemele informatice, cu
interfeţele grafice etc. Dupǎ cum vom vedea ulterior, una din primele etape ale procesului de
proiectare a interfeţelor vizeazǎ identificarea şi descrierea categoriilor de utilizatori din sistem.
2.3.1.4 Principiul alegerii între utilizarea tastaturii şi/sau a mouse-ului
Nu toţi utilizatorii sunt bucuroşi sǎ utilizeze mouse-ul, din motive subiective sau
obiective. Pe de o parte, unii utilizatori nu sunt familiarizaţi cu interfeţele grafice, ei formându-
şi unele deprinderi de lucru în utilizarea tastaturii, iar a-i forţǎ sǎ utilizeze mouse-ul le-ar putea
provoca disconfort şi, în final, insatisfacţii. Pe de altǎ parte, utilizarea tastaturii este uneori
justificatǎ de o mai mare productivitate a muncii, mai ales în cazul operaţiunilor de rutinǎ, cu
un grad mare de repetabilitate.
Sǎ ne imaginǎm că un utilizator trebuie să introducă câteva sute de documente pe zi. El va
relua operaţiunile specifice introducerii datelor pentru un document, de exemplu o facturǎ, de
câteva sute de ori. Prin utilizarea tastaturii, el îşi va forma deprinderile necesare astfel încât sǎ
piardǎ cât mai puţin timp cu privitul pe ecran şi sǎ se poatǎ concentra asupra citirii datelor de
pe document şi tastării lor. Altfel, dacǎ dupǎ fiecare facturǎ introdusǎ va trebui sǎ priveascǎ
ecranul şi sǎ utilizeze mouse-ul pentru deplasarea de la un câmp la altul sau pentru selectarea
butonului „Salvare”, randamentul sǎu se va diminua şi va creşte oboseala acumulatǎ. El va fi
nevoit sǎ schimbe mereu tastatura cu mouse-ul şi invers.
Proiectanţii trebuie sǎ conceapǎ interfeţele astfel încât utilizatorii sǎ poatǎ lucra cu ambele
echipamente. Însă, interfaţa trebuie să fie optimizată pentru utilizarea unuia dintre cele două
echipamente. Dacă sarcinile de lucru au frecvenţă mare, atunci interfaţa trebuie optimizată
pentru lucrul cu tastatura, ceea ce impune acordarea unei atenţii deosebite facilităţilor de
deplasare în formular, mai ales în ce priveşte ordinea de parcurgere a câmpurilor. Chiar dacǎ
interfaţa va fi optimizatǎ pentru utilizarea mouse-ului, vor fi create şi facilitǎţi de lucru cu

tastatura, fie şi numai de dragul utilizatorilor.
2.3.1.5 Principiul asigurării transparenţei detaliilor de proiectare
a programelor şi a bazei de date
Conform acestui principiu, interfaţa trebuie sǎ ascundǎ detaliile privind structura bazei de
date sau logica prelucrǎrii datelor din modulele de program. De exemplu, nu trebuie afişate în
formulare anumite coduri interne, cum ar fi codul tranzacţiilor, pe care proiectantul bazei de
date le-a inclus din anumite considerente de proiectare a bazei de date, şi al cǎror sens nu este
cunoscut şi nu intereseazǎ utilizatorii. De asemenea, aplicaţia trebuie sǎ controleze riguros
toate erorile care pot să apară în execuţia programelor, fie ele erori ale sitemului de operare, şi
sǎ furnizeze utilizatorului mesaje de eroare pe care acesta le înţelege sau, oricum, sǎ nu-l
sperie.
Un exemplu comun de încǎlcare a acestui principiu îl reprezintǎ utilitarul „Task
manager”, din sistemul de operare Windows 2000. Atunci când un program s-a blocat în
memorie, utilizatorul are posibilitatea închiderii acestuia prin intermediul utilitarului menţionat
(apǎsând tastele CTRL-ALT-DEL). Numai cǎ, acest utilitar afişeazǎ, pe lângǎ programele
lansate de utilizator, şi alte programe ale sitemului de operare, cu nume ciudate, despre care
utilizatorul nu ştie nimic. În plus, utilizatorul poate selecta şi închide oricare din programe,
ulterior el constatând funcţionarea necorespunzătoare a calculatorului.
2.3.2 Reducerea volumului de informaţii pe care trebuie sǎ le memoreze

utilizatorul
Cercetǎrile psihologice demonstreazǎ cǎ cele douǎ componente ale sistemului de
memorare uman sunt limitate: prima componentǎ, memoria pe termen scurt, asigurǎ regǎsirea
uşoarǎ a informaţiilor reţinute, însǎ este limitatǎ în ce priveşte perioada şi capacitatea de
memorare; cea de-a doua, memoria pe termen lung, este nelimitatǎ în ce priveşte capacitatea şi
perioada de memorare, însǎ este limitatǎ în ceea ce priveşte regǎsirea informaţiei
Aplicarea aceastei reguli presupune utilizarea calculatorului pentru acoperirea limitelor
memoriei umane. În acest sens, trebuie aplicate câteva principii de proiectare a interfeţelor,
prezentate în continuare.
2.3.2.1 Principiul degrevării utilizatorului de memorarea,
pe termen scurt, a unor informaţii
Memorarea pe termen scurt este utilǎ în reţinerea informaţiilor care pot fi regǎsite rapid,
dar care pot fi pǎstrate o perioadǎ scurtǎ de timp şi în volum redus (circa 5 – 9 elemente pentru
aproximativ 30 de secunde). De aceea, utilizatorii nu trebuie forţati sǎ memoreze unele
informaţii pe termen scurt, atunci când ei trec de la o operaţiune la alta, ci aplicaţia sǎ facǎ
acest lucru pentru ei.
Deşi atât de simplu, acest principiu este încǎlcat în practicǎ deseori. De multe ori,
utilizatorii deschid un formular pentru cautǎ o informaţie, iar dupǎ ce o gǎsesc o noteazǎ pe
hârtie, în vederea folosirii ei în alt formular.
Aşa se întâmplǎ la unele bǎnci, atunci când un client solicitǎ informaţii despre contul sǎu.
El este întrebat, mai întâi, de numǎrul contului, iar dacǎ nu-l cunoaşte i se solicitǎ numele.
Funcţionarul bǎncii deschide formularul pentru cǎutarea şi afişarea informaţiilor despre clienţii
bǎncii, unde va gǎsi numǎrul contului, pe care-l va nota pe hârtie. Apoi, el va închide
formularul respectiv şi va deschide un altul, pentru cǎutarea şi afişarea informaţiilor despre
conturile clienţilor bǎncii iar, pe baza numǎrului de cont notat anterior, va putea regǎsi şi afişa
informaţiile solicitate de client. Să reţinem sugestia funcţionarului de la ghişeu: „Vă rugăm ca
data viitoare sǎ aveţi notat numǎrul contului pentru mai multǎ operativitate!”.
2.3.2.2 Principiul interfeţei orientate pe recunoaştere, nu pe amintire

Problema majorǎ, în cazul memorării pe termen lung, este legatǎ de regǎsirea informaţiei,
iar aplicaţia trebuie sǎ sprijine utilizatorul în acest sens.
Existǎ douǎ metode principale de regǎsire a informaţiei din memorie: recunoaşterea şi
amintirea. Recunoaşterea presupune regǎsirea informaţiei pe baza unei sugestii, în timp ce
amintirea implicǎ regǎsirea informaţiei fǎrǎ existenţa vreunei sugestii. Evident, este mult mai
comod pentru utilizator sǎ recunoascǎ o informaţie, decât sǎ încerce sǎ şi-o aminteascǎ. De
exemplu, atunci când este posibil, este preferabilǎ furnizarea unei liste, din care utilizatorul sǎ
recunoascǎ şi sǎ selecteze elementul dorit, decât sǎ fie obligat sǎ şi-l aminteascǎ şi sǎ-l
introducǎ într-o cǎsuţǎ de text. De asemenea, este mai bine sǎ selecteze o comandǎ din meniu
decât sǎ o introducǎ de la tastaturǎ.
Un alt aspect important priveşte apelarea la metafore. Ele faciliteazǎ învǎţarea şi
exploatarea aplicaţiei, deoarece utilizatorii pot lucra mai uşor cu un obiect nou dacǎ îl asociazǎ
cu un alt obiect, din lumea realǎ, care îi este familiar, permiţându-i astfel transferarea
cunoştinţelor şi experienţei trecute. Apelarea la metafore dǎ încredere utilizatorilor, iar ei pot
învǎţa prin explorarea interfeţei. De exemplu, în sistemul de operare Windows, transferarea
unor fişiere în „Recycled” îl va determina pe utilizator sǎ înţeleagǎ aceastǎ operaţiune exact ca
aruncarea unui dosar la coş, de unde, pentru o perioadǎ de timp, îl mai poate recupera.
2.3.2.3 Principiul prevederii formelor scurte de lucru
Aplicarea acestui principiu presupune definirea unor cǎi mai directe de realizare a
diferitelor operaţiuni de cǎtre utilizator, prin reducerea numǎrului de apǎsǎri de taste sau de
acţiuni cu mouse-ul. Astfel, se reduce volumul de informaţii pe care utilizatorul trebuie sǎ-l
memoreze, pentru a lucra cu sistemul, şi va creşte productivitatea muncii sale.
Existǎ douǎ modalitǎţi de definirea a unor scurtǎturi:
• Utilizarea comenzilor mnemonice. Aceste comenzi pot fi întâlnite în majoritatea
programelor. Ele apar, de regulă, sub forma un singur caracter alfanumeric, şi
înlesnesc memorarea unor informaţii. Comenzile mnemonice pot fi utilizate pentru
selectarea unei opţiuni din meniul aplicaţiei sau a unui element dintr-o căsuţă de tip
listǎ. De exemplu, meniul tip bară din Microsoft Word conţine comenzile mnemonice
F pentru File, E pentru Edit, V pentru View sau H pentru Help.
• Utilizarea tastelor speciale sau a combinaţiilor de taste pentru iniţierea mai directă
operaţiunilor. Spre exemplu, tasta ALT, în mediul Windows, activeazǎ meniul; în
Visual FoxPro, combinaţia CTRL+W determinǎ salvarea ultimelor modificǎri
efectuate în tabela curentǎ şi închiderea ferestrei Browse.
2.3.2.4 Principiul relevanţei vizuale
Relevanţa vizualǎ este asiguratǎ de obiectele care compun interfaţa, şi se referǎ la:
sugestivitatea lor, modul de organizare şi simplitatea interfeţei.
Sugestivitatea obiectelor presupune ca ele sǎ fie uşor de înţeles şi sǎ reprezinte o
transpunere simplificatǎ a obiectelor reale. În acest sens, se va urmǎri nominalizarea
conţinutului obiectelor care conţin date (cǎsuţe de text, cǎsuţe combinate, căsuţe de tip listă
etc.), prin titluri explicite şi inteligibile, sau atribuirea unor nume sugestive butoanelor şi
grupurilor de obiecte din formulare.
Organizarea obiectelor interfeţei vizeazǎ gruparea şi aranjarea lor. Opţiunile, comenzile
şi obiectele de date legate între ele, din punct de vedere logic, trebuie grupate şi delimitate de
celelalte prin linii sau chenare. Aranjarea obiectelor trebuie sǎ fie în concordanţǎ cu cerinţele
funcţionale ale utilizatorilor, astfel încât sǎ le permitǎ acestora o navigare uşoarǎ de la un
obiect la altul, precum şi în interiorul lor. De asemenea, formularele pentru culegerea datelor
trebuie să reflecte structura documentului de pe care se preiau datele. Utilizatorul va învǎţa mai
uşor semnificaţia şi rolul câmpurilor din formular, va sesiza mai repede informaţiile afişate şi,
în consecinţă, va avea o productivitate sporită.
Prin simplitatea interfeţei se urmăreşte evitarea creării de ecrane încǎrcate, greu de
urmǎrit şi utilizat. Dacǎ un ecran conţine prea multe informaţii, atunci utilizatorul va fi derutat
şi nu va şti unde sǎ se uite, pentru a gǎsi informaţia dorită. Cu cât o interfaţǎ este mai simplǎ,
cu atât ea este mai uşor de învǎţat şi utilizat. Însǎ, nu trebuie sacrificatǎ funcţionalitatea
aplicaţiei de dragul simplitǎţii. Gǎsirea unui echilibru între cele douǎ caracteristici constituie o
provocare pentru proiectant şi impune participarea activǎ a utilizatorilor în activitatea de
proiectare.
2.3.3 Uniformitatea interfeţelor utilizator

Uniformitatea interfeţelor poate fi obţinută prin aplicarea aceloraşi convenţii de proiectare
a acestora, atât în cadrul unei aplicaţii, cât şi în aplicaţii diferite. Multe organizaţii au adoptat
standardizarea interfeţelor utilizator la nivelul tuturor aplicaţiilor, conştientizând beneficiile ce
pot fi obţinute17.
Uniformitatea interfeţelor permite utilizatorilor transferarea experienţei lor anterioare şi a
cunoştinţelor acumulate, ei fiind în mǎsurǎ sǎ înveţe mai uşor aplicaţiile noi. Interfaţa noii
aplicaţii va fi familiarǎ şi predictibilǎ, oferind utilizatorului sentimentul de stabilitate. Altfel,
procesul de învǎţare poate fi inhibat, iar utilizatorul nu va mai avea încredere nici în noua
aplicaţie, nici în ceea ce a învǎţat anterior. Un alt efect benefic al uniformităţii interfeţelor
priveşte reducerea erorilor în culegerea datelor.
Uniformitatea interfeţelor presupune luarea în considerare a următoarelor aspecte:
• Uniformitatea în cadrul aplicaţiei.
• Uniformitatea în cadrul sistemului, între diferitele aplicaţii existente. Funcţiunile
similare, din aplicaţii diferite, trebuie sǎ ofere interfeţe similare.
• Uniformitatea cu sistemul de operare. Respectarea standardelor de proiectare a
interfeţelor specifice sistemului de operare utilizat, cu care utilizatorul este deja
familiarizat, va asigura învǎţarea şi exploatarea mai facilǎ a aplicaţiei.
Uniformitatea interfeţelor utilizator este urmărită sub trei aspecte: al modului de
prezentare, al comportamentului şi al interacţiunii, fiecare fiind tratat, în continuare, ca
principiu dinstinct.
2.3.3.1 Principiul uniformitǎţii modului de prezentare a interfeţei
Aplicarea acestui principiu presupune ca utilizatorul sǎ vadǎ informaţiile şi obiectele
interfeţei în acelaşi mod, din punct de vedere logic, fizic şi vizual, în cadrul întregii
aplicaţii/sistem. Dacǎ într-un formular conţinutul unei cǎsuţe de text pe fond de culoare gri nu
poate fi modificat, această operaţiune fiind permisă numai în cazul în care culoarea de fond
este albǎ, atunci aceastǎ regulǎ trebuie respectatǎ în toate formularele aplicaţiei. Modificarea
acestei reguli, într-un formular, poate provoca o stare de nelinişte utilizatorului. De asemenea,
dacǎ pentru introducerea unui anumit tip de date se utilizeazǎ un anumit tip de obiect, atunci el
trebuie utilizat în toate ecranele care solicitǎ introducerea acelui tip de datǎ. Numele
comenzilor similare din formulare diferite trebuie sǎ fie aceleaşi pentru a încuraja învǎţarea
exploratorie.
Conform acestui principiu, trebuie respectatǎ şi uniformitatea esteticii interfeţei.
Utilizarea aceleiaşi scheme de culori, a aceloraşi fonturi şi a aceleiaşi strategii de plasare a
obiectelor va duce la obţinerea unei interfeţe mai plǎcute.
17. Marakas, G. – Systems Analysis and Design. An Active Approach, Prentice Hall, New Jersey, 2001, p. 347.
2.3.3.2 Principiul uniformitǎţii în comportamentul interfeţei

Acelaşi obiect trebuie sǎ aibă un comportament similar, în situaţii şi ecrane diferite.
Schimbarea comportamentului obiectelor interfeţei în cadrul aplicaţiei sau de la o aplicaţie la
alta, cum ar fi butoanele sau opţiunile din meniu, poate determina un comportament
superstiţios, mistic din partea utilizatorilor. Ei vor vedea cǎ, în urma realizǎrii aceleiaşi acţiuni,
obţin rezultate diferite. De exemplu, selectarea oricǎrei opţiuni dintr-un meniu-bară trebuie,
întotdeauna, sǎ afişeze un meniu „drop-down” , din care utilizatorul sǎ poatǎ iniţia operaţiunea
doritǎ, şi nu sǎ execute o acţiune în mod direct. Dacǎ utilizatorul este obişnuit sǎ se întâmple o
anumită acţiune la dublu clic pe un anumit tip de obiect, cum ar fi o cǎsuţǎ de text, atunci
aceeaşi acţiune trebuie sǎ se realizeze când face dublu clic pe un alt obiect de acelaşi tip.
Uniformitatea în comportament nu priveşte doar obiectele interfeţei, ci şi secvenţa
dialogurilor. Aceeaşi operaţiune, realizatǎ la momente diferite, trebuie sǎ implice aceeaşi
succesiune de paşi, cu aceleaşi opţiuni de lucru pentru fiecare pas în parte. Dacǎ totuşi acest
lucru nu este posibil, atunci utilizatorul trebuie informat.
O atenţie deosebitǎ trebuie acordatǎ mesajelor de informare sau de eroare. De câte ori este
posibil, se va încerca afişarea aceluiaşi mesaj, dacǎ utilizatorul se aflǎ în aceeaşi situaţie, dar în
locuri diferite ale aplicaţiei. În acest sens, este recomandată crearea unei biblioteci de mesaje,
în care sǎ se atribuie fiecǎrui mesaj un identificator. Un mesaj va putea fi apelat în orice parte a
aplicaţiei prin intermediul identificatorului său.
2.3.3.3 Principiul uniformităţii interacţiunii cu interfaţa utilizator
Utilizatorul nu trebuie forţat inutil ca într-o parte a aplicaţiei sǎ lucreze cu tastatura, iar în
altǎ parte sǎ utilizeze mouse-ul. De asemenea, comenzile mnemonice, tastele speciale şi
combinaţiile de taste trebuie sǎ aibǎ aceleaşi funcţiuni de la un program la altul. De exemplu,
astăzi în toate mediile de lucru, F1 este utilizată pentru activarea facilităţilor de ajutor (Help).
*
* *
Toate principiile prezentate anterior trebuie vǎzute ca un sistem, între multe dintre ele
existând relaţii de interdependenţǎ, dar şi antagonice. Proiectantul îşi va defini propriul sistem,
prin alegerea principiilor care se potrivesc cel mai bine platformelor hardware, sistemului de
operare şi altor categorii de software utilizate, cerinţelor funcţionale ale sistemului şi nevoilor
utilizatorilor. Respectarea acestor principii poate însemna eforturi suplimentare de proiectare,
programare şi testare a aplicaţiei, însǎ ele vor fi contrabalansate de satisfacţiile pe care le vor
avea utilizatorii şi, implicit, de reducerea riscului de neacceptare a sistemului.
2.4 Demersul proiectării interfeţelor utilizator

Proiectarea interfeţelor utilizator pune accentul pe definirea elementelor componente ale
interfeţei, cu care vor interacţiona utilizatorii, pentru a-şi realiza sarcinile de lucru.
Conştientizând importanţa interfeţelor în succesul noului sistem informaţional, specialiştii s-au
preocupat de găsirea unor tehnici de proiectare, care să plaseze în centrul atenţiei şi să implice
în mod direct utilizatorii în dezvoltarea sistemului informaţional. Aceste tehnici sunt referite
sub titulatura de proiectare orientată spre utilizatori.
Această abordare are la bază trei principii importante18:
• Orientarea spre utilizator şi atribuţiile sale de serviciu, încă de la începutul
dezvoltării sistemului informaţional. Dacă în abordarea tradiţională accentul era pus
pe cerinţele funcţionale ale sistemului, acum analiştii trebuie să axeze pe identificarea
categoriilor de utilizatori şi să înţeleagă cerinţele lor specifice. Ei trebuie să găsească
18. Satzinger J.W., Jackson, R.B., Burd, S.D. – Systems Analysis and Design in a Changing World, Course
Technology, Thomson Learning, 2002, Boston, p. 441.
răspunsuri la întrebări precum: Ce cunoştinţe şi experienţă au ei? Cum învaţă ei? Cum
ar dori ei să lucreze? Ce-i motivează?
• Evaluarea specificaţiilor de proiectare în vederea asigurării uşurinţei învăţării şi
utilizării noului sistem. Obţinerea acestei caracteristici reprezintă o sarcină dificilă,
datorită existenţei unor categorii diferite de utilizatori, cu preferinţe şi abilităţi
diversificate, dificil de armonizat. Dacă interfaţa este flexibilă, utilizatorii mai puţin
experimentaţi se pot simţi neliniştiţi, iar o interfaţă prea rigidă creează frustrări
utilizatorilor experimentaţi. De asemenea, uşurinţa în învăţare este adesea în conflict
cu uşurinţa în utilizare. O aplicaţie bazată pe un meniu, cu multe ecrane, mesaje de
dialog şi informaţii explicative detaliate este uşor de învăţat, însă greu de utilizat,
deoarece implică numeroase interacţiuni între utilizator şi calculator. O astfel de
interfaţă este indicată atunci când ea este utilizată rar. Utilizatorii care folosesc
sistemul zilnic, în mod intensiv, preferă o interfaţă mai flexibilă, cu comenzi apelabile
direct, prin combinaţii de taste, cu formulare mai încărcate. Interfaţa va fi mai greu de
învăţat, însă ea le va permite utilizatorilor să obţină un plus de eficacitate.
• Angajarea unui proces iterativ de dezvoltare. Implicarea utilizatorilor în procesul de
dezvoltare a sistemului poate fi obţinută, cel mai bine, prin organizarea activităţilor
într-un proces iterativ, utilizând tehnica prototipizării. Activităţile vor fi reluate de
mai multe ori, prototipul fiind supus modificării şi evaluării din partea utilizatorilor,
în cadrul fiecărei iteraţii. Procesul iterativ se va încheia după ce utilizatorii îşi vor da
acordul asupra interfeţei rezultate.
În continuare vom descrie un proces iterativ de proiectare a interfeţelor, care să pună în
aplicare cele trei principii discutate anterior. El se prezintă sub forma unei spirale (vezi figura
2.6), formată din patru faze19:
1. Colectarea şi analiza informaţiilor de la utilizatori,
2. Proiectarea interfeţelor,
3. Construirea interfeţelor şi
4. Validarea.
2) Proiectarea 1) Analiza
3) Construirea 4) Validarea
Fig. 2.6 Procesul iterativ de proiectare a interfeţelor utilizator
Modelul în spirală relevă faptul că, fiecare dintre fazele enumerate mai sus va fi reluată de
mai multe ori, astfel încât fiecare iteraţie va introduce noi cerinţe şi specificaţii de proiectare,
care vor fi implementate şi testate de fiecare dată. Procesul iterativ va continua până când toate
cerinţele identificate au fost înglobate în specificaţiile de proiectare ale interfeţei, iar
utilizatorul îşi va da acordul asupra rezultatului proiectării.
În paragrafele următoare, vom descrie activităţile specifice fiecăreia dintre cele patru faze.
De asemenea, vom relua modelul de studiu de caz privind sistemul de gestiune a clienţilor şi ne
vom ocupa de proiectarea ecranului pentru preluarea în sistem a comenzilor primite de la
19. Mandel, T. – The Elements of User Interface Design, John Wiley & Sons, New York, 1997, p. 251.
clienţi şi a secvenţei de dialoguri necesare pentru obţinerea raportului „Situaţia vânzărilor pe

gestiuni şi facturi”, proiectat în capitolul anterior.
Necesitatea proiectării unui ecran (formular) pentru actualizarea comenzilor poate fi
stabilită în urma studierii diagramelor fluxurilor de date. În diagrama de nivel 0 a sistemului de
gestiune a clienţilor pot fi observate trei fluxuri de intrare care provin de la entitatea externă
Client: Comandă nouă, Date de identificare şi Date modificare comandă. Ele se regăsesc şi în
diagrama de nivel 1 pentru procesul „Introducere comandă”, aşa cum este redată în caseta 2.1.
Cele trei fluxuri sugerează necesitatea preluării în sistem şi a actualizării datelor privind
comenzile clienţilor. Proiectantul îşi va continua munca prin studierea cu atenţie a cerinţelor
informaţionale culese şi structurate în faza de analiză, în partea din diagramele fluxurilor de
date care detaliază procesul corespunzător (în modelul nostru, diagrama de nivel 1 pentru
procesul „Introducere comandă”), precum şi în dicţionarul metadatelor.
Caseta nr. 2.1 – Diagrama de nivel 1 pentru funcţia „Introducere comandă”

Catalog
Comanda-noua
Client
Tranzactii comenzi
Date-
Date- produs
Nomenclator
modificare-
produse
comanda Date-comezi-
modificate
1.1
Date-comenzi-
Cantitate-
inregistrate
Date-client Verificare existenta
existenta produs Sistem vanzari
Clienti 1.3
Informatii-limita- Actualizare
Date-comenzi-noi creditare-clienti comenzi
Date-de-identificare si-modificate
Client Date-comenzi-modificate
Nota-confirmare- Cantitate-
comanda 1.2 Nomenclator comanda-
produse modificata
Nota-confirmare- Cantitate-comanda-noua
Inregistrare
modificare-comanda comanda noua Date-
comanda-noua Nomenclator
Comenzi-de-onorat Comenzi Date-
produse
comenzi-
existente
Date-
client Informatii-clienti-noi
Depozit-livrari Date-
comenzi- 1.4
Tip- inregistrate
comanda Date-client
Decizii-politici- Clienti
Generare
creditare-clienti rapoarte comenzi
Tranzactii comenzi Date-produs

Rapoarte-privind-
Conducere
comenzile
Catalog
Conducere
2.4.1 Culegerea şi analiza informaţiilor de la utilizatori

Dezvoltarea unui sistem informaţional trebuie să înceapă cu definirea clară a problemelor
pe care utilizatorul doreşte să le rezolve cu ajutorul noului sistem, înţelegerea şi descrierea
atribuţiilor de serviciu şi a modului în care utilizatorul le realizează. Prin urmare, proiectarea
interfeţelor utilizator va începe cu identificarea categoriilor de utilizatori şi formularea
cerinţelor acestora. Chiar dacă această fază este derulată în cadrul analizei sistemului, acum
vom prezenta câteva repere, care trebuie atinse în analiza sistemului, pentru a se asigura
premisele unei bune proiectări a interfeţelor utilizator.
În această fază sunt derulate cinci activităţi: determinarea profilului utilizatorilor, analiza
atribuţiilor de serviciu ale acestora, culegerea cerinţelor utilizatorilor, analiza mediului de
lucru şi armonizarea cerinţelor utilizatorilor cu atribuţiile lor de serviciu.
Determinarea profilului utilizatorilor
În cadrul acestei activităţi, analistul trebuie să identifice categoriile de utilizatori, să
înţeleagă percepţia fiecărei categorii asupra sistemului şi să formuleze cerinţele lor specifice.
Categoriile de utilizatori pot fi identificate pe baza unei matrice, rezultată prin combinarea
a două dimensiuni: cunoştinţele în domeniul de activitate, pentru care se dezvoltă sistemul
informaţional, şi experienţa în lucrul cu sistemele informatice. Rezultă patru categorii de
utilizatori:
• utilizatori care nu au cunoştinţe în domeniul lor de activitate şi nici experienţă în
utilizarea calculatorului;
• utilizatori fără cunoştinţe în domeniul lor de activitate, dar familiarizaţi cu sistemele
informatice;
• utilizatori care au o experienţă bogată în domeniul lor de activitate, dar mai puţină
experienţă în utilizarea calculatorului;
• utilizatori experimentaţi atât în domeniul lor de activitate, cât şi în utilizarea sistemelor
informatice.
Analiza atribuţiilor de serviciu ale utilizatorilor
Acum se urmăreşte identificarea şi descrierea atribuţiilor de serviciu ale utilizatorilor, a
modului în care ei realizează aceste sarcini. După descrierea situaţiei existente, se va încerca
reorganizarea sarcinilor de serviciu, astfel încât să se beneficieze din plin de avantajele oferite
de noile tehnologii angajate în dezvoltarea sistemului. Această problemă se pune, mai ales, în
situaţia trecerii de la interfeţe clasice la interfeţe grafice, de la un sistem manual la unul
informatizat, sau de la unul neintegrat la unul integrat.
Schimbările privind modul de realizare a sarcinilor de serviciu trebuie să fie bine
justificate din punctul de vedere al optimizării lor, iar efectele lor pozitive şi/sau negative să fie
aduse la cunoştinţa utilizatorilor. Mai mult, utilizatorii trebuie implicaţi activ în regândirea
sarcinilor lor de muncă. Altfel, modificările radicale şi nejustificate pot crea frustrări în rândul
utilizatorilor şi, implicit, sporirea riscului de neacceptare a noului sistem.
Această etapă de lucru trebuie să ofere răspunsuri la unele întrebări, precum:
• Care sunt sarcinile realizate de utilizatori?
• Ce atribuţii sunt cele mai importante pentru activitatea desfăşurată de utilizator?
• Care sunt operaţiunile necesare pentru realizarea unei atribuţii de serviciu?
• Cu ce scopuri realizează utlizatorul aceste atribuţii?
• Care sunt informaţiile de care are nevoie utilizatorul pentru a-şi îndeplini atribuţiile?
• Care sunt rezultatele obţinute pentru fiecare atribuţie de serviciu?
• Cum lucrează utilizatorii pentru îndeplinirea atribuţiilor lor (manual, pe calculator
etc.)?
• Care este frecvenţa de realizare a fiecărei sarcini de serviciu?
• Cum ar putea sistemul să-l ajute pe utilizator în realizarea atribuţiilor sale?
Identificarea cerinţelor de lucru
În acest moment, se vor culege informaţiile privind doleanţele utilizatorilor, cu privire la
ce trebuie să ofere şi cum trebuie să arate interfeţele. Cerinţele utilizatorilor vor putea fi culese
cu ajutorul tehnicilor specifice, cum ar fi interviul şi chestionarul. În cazul în care utilizatorii
nu sunt în măsură să-şi specifice cerinţele, proiectantul va construi un prototip al fiecărei
interfeţe, pe baza rezultatelor din primii doi paşi, pe care-l va supune apoi atenţiei acestora.
Având în faţă un astfel de prototip, utilizatorii vor putea să facă observaţii şi să-şi exprime
cerinţele.
În general, cerinţele utilizatorilor se pot referi la reducerea numărului de erori în culegerea
datelor, automatizarea unor activităţi manuale, sporirea vitezei de culegere a datelor, efectuarea
anumitor verificări asupra datelor introduse, semnalarea unor situaţii de excepţie etc.
Analiza mediului de lucru al utilizatorilor
Prin analiza mediului de lucru se urmăreşte determinarea caracteristicilor de mediu care
pot influenţa activitatea utilizatorilor. Vor fi culese informaţii cu privire la caracteristicile
fizice ale mediului de lucru (luminozitate, zgomote, spaţiu, temperatură etc.), aspectele de
ergonomie a muncii, nevoile speciale ale utilizatorilor cu diverse infirmităţi etc.
Armonizarea cerinţelor utilizatorilor cu sarcinile lor de serviciu
În finalul acestei faze, se va verifica dacă cerinţele exprimate de utilizatori corespund cu
caracteristicile sarcinilor de serviciu pe care ei trebuie să le realizeze. Analistul va încerca să
ofere utilizatorilor mai mult decât ceea ce au cerut ei, dar şi să explice acestora situaţiile în
care anumite cerinţe nu pot fi rezolvate. De exemplu, dacă utilizatorul are nevoie numai de
informaţii de tip text, atunci nu se justifică proiectarea unei interfeţe care să ofere facilităţi de
lucru multimedia.
În caseta 2.2 sunt prezentate rezultatele acestei faze pentru proiectarea ecranului de
actualizare a comenzilor.
Caseta nr. 2.2 – Rezultatele fazei de colectare şi analiză a informaţiilor necesare
proiectării ecranului pentru actualizarea comenzilor
Profil utilizatori
- abilităţi minime în utilizarea calculatorului;
- o bună cunoaştere a produselor firmei;
- nivel mediu de experienţă în preluarea şi prelucrarea comenzilor.
Activităţile utilizatorilor
- înregistrarea unei comenzi noi;
- modificarea unei comenzi;
- anularea unei comenzi;
- vizualizarea datelor privind comenzile unui client.
Cerinţele utilizatorilor
- timpi mici de răspuns, mai ales în cazul primirii comenzilor prin telefon;
- interfeţe asemănătoare cu cele din mediul Windows;
- posibilitatea de tipărire a comenzilor;
- posibilitatea de transmitere de notificări către client, cu privire la înregistrarea comenzii
sale, mai ales în cazul primirii ei prin telefon;
- oferirea de informaţii privind stocul disponibil;
- servirea simultană a mai multor utilizatori;
- flexibilitatea derulării dialogurilor pentru situaţia primirii comenzii prin telefon;
- întreruperea şi abandonarea unei activităţi.
Mediul de lucru al utilizatorului
- cerinţele standard pentru utilizarea desktop-urilor conectate la reţeaua firmei pentru
accesarea bazei de date, în condiţiile utilizării telefonului;

- utilizarea de laptop-uri conectate la Internet pentru accesarea bazei de date a firmei de la
sediul clienţilor;
- servirea simultană a mai multor utilizatori.
Armonizarea cerinţelor cu sarcinile utilizatorilor
- stocurile trebuie actualizate la timp pentru a oferi clienţilor informaţii corecte;
- reţeaua de calculatoare a firmei trebuie să fie capabilă să gestioneze simultan cererile mai
multor utilizatori, în timp cât mai scurt.
2.4.2 Proiectarea interfeţei utilizator

Mulţi sunt tentaţi ca, dupǎ parcurgerea activitǎţilor din faza anterioarǎ, sǎ ignore această
etapă de lucru şi să treacǎ direct la construirea interfeţelor şi scrierea programelor. Chiar dacǎ
aceastǎ fazǎ solicitǎ timp şi eforturi semnificative, parcurgerea ei va asigura obţinerea unor
interfeţe de calitate. În altă ordine de idei, ignorarea acestei faze ar face imposibilă punerea în
practică a procesului iterativ şi, implicit, angajarea directă a utilizatorilor în proiectarea
interfeţelor.
Paşii ce trebuie parcurşi în această fază sunt:
• definirea obiectivelor de calitate a interfeţelor,
• formularea scenariilor pentru fiecare sarcină de serviciu,
• definirea obiectelor şi acţiunilor interfeţei utilizator,
• stabilirea modului de reprezentare vizuală a obiectelor interfeţei.
Definirea obiectivelor
Obiectivele privind calitatea interfeţelor utilizator pot fi definite, de o manierǎ mai
generalǎ, sub forma sintagmelor uşor de învǎţat şi uşor de utilizat. Însǎ, ele trebuie definite
într-o manierǎ mai detaliatǎ şi mai concretǎ, în măsură sǎ permitǎ cuantificarea lor. Ele vor
servi mai bine nu doar la proiectarea interfeţelor, ci şi la testarea acestora.
Booth defineşte patru factori relativi la calitatea interfeţelor (usability) 20:
• utilitatea (usefulness) reprezintă măsura în care produsul (interfaţa) permite
utilizatorului să-şi atingă scopurile sale. Prin intermediul acestui factor, se evaluează
motivaţia utilizatorilor de a folosi produsul respectiv.
• eficacitatea se referă la uşurinţa şi rapiditatea cu care utilizatorii îşi pot realiza
sarcinile de lucru.
• uşurinţa învăţării este evaluată prin prisma timpului de instruire necesar pentru ca
utilizatorii să obţină un anumit nivel de competenţă în utilizarea sistemului.
• atitudinea priveşte percepţia şi opiniile utilizatorilor asupra celorlalţi trei factori,
enumeraţi anterior. În fapt, se ia în considerare ceea ce gândesc utilizatorii cu privire la
calitatea interfeţei.
Obiectivele privind calitatea interfeţei trebuie definite pentru fiecare din cei patru factori,
amintiţi anterior. În caseta 2.3 sunt prezentate obiectivele de calitate definite pentru ecranul de
culegere a datelor privind comenzile primite de la clienţi.
Definirea scenariilor de lucru
Un scenariu reprezintă o descriere generală unei atribuţii de serviciu, sub forma unei
succesiuni de operaţiuni pe care le realizează utilizatorul. Scenariile de lucru sunt utile nu doar
la proiectarea interfeţelor, ci şi la testarea lor. Neidentificarea tuturor scenariilor de lucru poate
20. Booth, P. – An Introduction to Human-Computer Interaction, Lawrence Erlbaum Associates, Londra, 1989, citat
în Mandel, T. – op. cit., p. 103.
determina creşterea probabilităţii de omitere a unui obiect sau a unei acţiuni şi, implicit,
obţinerea unei aplicaţii cu funcţionalitate incompletă. Se vor urmări identificarea şi definirea
de scenarii de lucru distincte, pentru fiecare categorie de utilizatori, ţinând cont de
caracteristicile lor.
Caseta nr. 2.3 – Obiectivele de calitate urmărite la proiectarea

ecranului pentru actualizarea comenzilor
Factorii calităţii Obiectivele de calitate
Utilitatea După 5 scenarii de lucru, 90% dintre utilizatori vor fi capabili să realizeze
cu succes o operaţiune.
Eficacitatea După 5 scenarii de lucru, 75% dintre utilizatori vor fi capabili să realizeze
cu succes o operaţiune, în mai puţin de 2 minute
Uşurinţa invăţării După o oră de instruire, toţi utilizatorii vor fi capabili să realizeze cele mai
importante sarcini de lucru.
Atitudinea După efectuarea a 5 scenarii de lucru, 85% dintre utilizatori vor aprecia
satisfacţia obţinută prin nivelul 5.5, pe o scară de la 1 la 7.
Este foarte important de reţinut că scenariile definite trebuie să ghideze proiectarea
interfeţelor şi nu invers, adică proiectarea mai întâi a interfeţelor şi definirea ulterioară a
scenariilor. Altfel, faza de testare va porni de la premise greşite, fiind testate scenariile care
oricum pot fi realizate prin intermediul interfeţei şi nu scenariile de lucru reale.
În caseta 2.4 sunt prezentate scenariile de lucru ale utilizatorilor pentru actualizarea şi
vizualizarea datelor privind comenzile primite de la clienţi.
Caseta nr. 2.4 – Scenariile de lucru pentru actualizarea şi vizualizarea comenzilor
Scenariul 1. Introducerea unei comenzi noi

Operaţiile de lucru sunt următoarele:
• Alegerea clientului. Utilizatorul introduce codul clientului după care va verifica dacă numele şi
adresa acestuia corespund cu datele înscrise pe document. În cazul în care utilizatorul nu ştie codul
clientului, şi nici nu este trecut în document, atunci el va selecta numele acestuia din lista clienţilor;
• Adăugarea unui client nou (dacă clientul dorit nu există în baza de date);
• Completarea datelor de individualizare a comenzii (numărul dat de client, numărul intern,
atribuit în mod automat de sistem, şi data înregistrării, preluată din sistem, dar care poate fi
modificată de utilizator);
• Completarea modalităţii de plată şi a termenului de livrare;
• Adăugarea articolelor comandate. Această operaţie va fi reluată pentru fiecare articol comandat, şi
presupune:
– Selectarea produsului. Utilizatorul introduce codul produsului după care va verifica dacă
denumirea acestuia corespunde cu cea înscrisă pe document. În cazul în care codul produsului
nu apare în document şi utilizatorul nu-l ştie sau acesta este incorect, atunci el va selecta
produsul respectiv dintr-o listă cu toate produsele;
– Verificarea unităţii de măsură, a stocului disponibil şi a preţului unitar;
– Completarea cantităţii comandate pentru articolul respectiv;
– Verificarea valorii calculate pentru articolul respectiv;
• Verificarea totalului valoric al comenzii, prin compararea totalului rezultat în urma adăugării
datelor cu totalul înscris în comandă;
• Salvarea comenzii;
• Transmiterea unei notificări către client. În cazul primirii comenzii prin telefon, clientul poate
solicita confirmarea înregistrării comenzii sale prin transmiterea unui email cu toate detaliile;
• Tipărirea comenzii, dacă utilizatorul doreşte acest lucru (în special în cazul comenzilor primite prin
telefon.
Scenariul 2. Modificarea datelor de pe o comandă

• Căutarea şi afişarea comenzii. Căutarea poate fi efectută în funcţie de numărul dat de client sau
numărul (codul) intern al comenzii, perioada în care a fost înregistrată, codul sau numele
clientului;
• Verificarea stării comenzii. Comenzile deja onorate nu mai pot fi modificate;
• Modificarea datelor de pe comandă. Se pot ivi următoarele situaţii: modificarea modalităţii de
plată, a perioadei de livrare, adăugarea sau ştergerea unui articol, modificarea cantităţii
comandate;
• Salvarea sau abandonarea modificărilor. Utilizatorul va confirma acţiunea aleasă;
• Transmiterea unei notificări către client privind modificările efectuate. În cazul în care clientul
solictă prin telefon efectuarea unor modificări asupra comenzii, acesta poate cere confirmarea
înregistrării modificărilor prin transmiterea unui mesaj email cu toate detaliile comenzii;
• Tipărirea comenzii, dacă utilizatorul doreşte acest lucru (mai ales în cazul comenzilor primite
anterior prin telefon).
Scenariul 3. Anularea unei comenzi

• Căutarea comenzii (vezi prima sarcină de lucru de la scenariul 2);
• Verificarea stării comenzii. Comenzile deja onorate nu mai pot fi anulate;
• Anularea comenzii. Utilizatorul va confirma anularea comenzii;
• Transmiterea unei notificări către client cu privire la anularea comenzii sale.
Scenariul 4. Vizualizarea comenzilor unui client

• Introducerea datelor de identificare a clientului. Se poate introduce codul clientului sau se alege
numele acestuia dintr-o listă;
• Verificarea corectitudinii identităţii clientului. Se va compara adresa clientului afişată cu cea
înscrisă pe comandă sau cea specificată de client prin telefon;
• Căutarea unei comenzi a clientului selectat. Căutarea poate fi realizată după numărul comenzii dat
de client sau data de înregistrare;
• Vizualizarea comenzii. Utilizatorul poate fi interesat de felul plăţii, data livrării, articolele şi
cantităţile comandate, valoarea totală a comenzii, starea acesteia etc;
• Tipărirea comenzii, dacă utilizatorul doreşte acest lucru.
Definirea obiectelor şi acţiunilor interfeţei

Pe baza scenariilor definite anterior, se vor defini obiectele şi acţiunile necesare în
interfaţă, pentru a putea fi realizate sarcinile de serviciu respective, în conformitate cu cerinţele
şi obiectivele de calitate definite. În acest sens, se va citi cu atenţie descrierea tuturor
scenariilor şi operaţiilor de lucru şi se vor sublinia toate substantivele şi verbele, urmând a fi
trecute într-o listă specială. Fiecare substantiv este susceptibil de a reprezenta un obiect, iar
fiecare verb poate corespunde unei acţiuni. Obiectele sunt reprezentate, de regulă, prin câmpuri
de date, precum numărul şi data facturii, numele furnizorului, denumirea marfii, iar acţiunile
prin operaţiunile iniţiate în interfaţă, cum ar fi adăugare factură, salvare date, căutare
document, încărcarea datelor.
În caseta 2.4, substantivele (obiectele) au fost evidenţiate cu caractere îngroşate (bold), iar
verbele (acţiunile) cu caractere înclinate (italice). Lista obţinută va fi revizuită pentru a se
elimina obiectele şi acţiunile duplicate, precum şi pentru a adăuga eventualele obiecte şi
acţiuni care nu au rezultat în mod explicit din descrieriea scenariilor de lucru. Lista finală
pentru exemplul nostru este prezentată în caseta 2.5.
Caseta nr. 2.5 – Lista obiectelor şi acţiunilor din ecranul

pentru actualizarea şi vizualizarea comenzilor
Obiectele ecranului Acţiunile ecranului
Client Adăugare client nou
Cod client Salvare comandă
Nume client (listă) Transmitere notificare
Adresă client Tipărire comandă
Comandă Căutare comandă
Numărul comenzii dat de client Modificare date
Cod intern al comenzii Adăugare articol
Data înregistrării comenzii Ştergere articol
Modalitatea de plată Abandonare
Termen de livrare Anulare comandă
Articol comandă
Cod produs
Denumire produs (listă)
Unitate de măsură
Stoc existent
Preţ unitar
Valoare articol
Total valoric comandă
Perioada de căutare/afişare comenzi
Stabilirea modului de reprezentare vizuală a obiectelor interfeţei
După identificarea şi definirea obiectelor interfeţei, se va trece la stabilirea modului de
reprezentare vizuală pentru fiecare obiect în parte. În acest sens, se va ţine cont de tipurile de
obiecte specifice interfeţelor grafice (căsuţe de text, butoane radio, casuţe combinate etc.).
Apoi, se va determina modul în care utilizatorii vor interacţiona cu obiectele interfeţei, luându-
se în considerare evenimentele asociate fiecărui obiect în parte. Dacă este necesar, vor fi
prevăzute meniuri de tip pop-up, asociate obiectelor, sau meniuri de tip bară, asociate
ecranelor. De exemplu, IBM recomandă utilizarea unui meniu de tip bară, atunci când un ecran
oferă mai mult de şase opţiuni de lucru.
2.4.3 Construirea interfeţei utilizator

Odată ce au fost formulate specificaţiile de proiectare, se trece la construirea interfeţelor
utilizator. Această fază este axată pe construirea prototipului interfeţei. Este indicată
construirea de prototipuri pentru mai multe variante de proiectare.
Construirea prototipurilor este o operaţiune foarte simplă, dacă se apelează la ajutorul
oferit de produsele CASE sau de mediile speciale de dezvoltare grafică. Se pot folosi programe
utilitare de proiectare a intrărilor şi ieşirilor (documente şi rapoarte), însă există instrumente
specializate, cunoscute sub numele de Prototypers (prototipizoare) sau Demo Builders
(constructori demo), care permit construirea rapidă a ecranelor şi vor demonstra cum va fi
folosită interfaţa în viitorul sistem. Prin ele se realizează şi evaluarea comportamentului în

utilizare. Avantajul principal al acestor medii constă în construirea uşoară şi rapidă a
prototipurilor şi a versiunilor demonstrative ale sistemului informatic, chiar de către
neprogramatori. Dezavantajele sunt legate de funcţionalitatea limitată şi utilizarea platformelor
proprietare pentru scrierea codului, ceea ce face dificilă încorporarea sa în produsul final.
Ca alternativă, se poate utiliza mediul de dezvoltare în care va fi implementată interfaţa,
de exemplu Visual Basic sau Java. Proiectantul va avea la dispoziţie toate facilităţile
disponibile la implementarea sistemului, în plus, fiind posibilă reutilizarea codului scris cu
ocazia construirii prototipului. Dezavantajul acestei alternative este legat de dificultatea
utilizării acestor medii de către cei care nu le stăpânesc.
Modelul final al prototipului pentru ecranul (formularul) de culegere, actualizare şi
vizualizare a datelor privind comenzile primite de la clienţi este prezentat în caseta 2.6.
Caseta nr. 2.6 – Prototipul ecranului pentru actualizarea
şi vizualizarea datelor privind comenzile
În caseta 2.7 este prezentată fereastra de dialog cu care va interacţiona utilizatorul pentru
generarea şi tipărirea raportului „Situaţia vânzărilor pe gestiuni şi facturi”, ale cărui specificaţii
de proiectare au fost prezentate în capitolul anterior.
Datorită simplităţii secvenţei de dialoguri, nu a mai fost necesară parcurgerea, fază cu
fază, a demersului de proiectare a interfeţelor utilizator. Oricum, construirea prototipului
pentru fereastra de dialog are la bază specificaţiile de proiectare ale raportului, cum ar fi
perioada de timp pentru care se generează raportul, modul de grupare şi ordonare, gestiunile
pentru care se vor lista datele etc. Scenariile de lucru sunt uşor de intuit şi de transpus în
prototip, fără a mai fi necesară definirea lor explicită.
Caseta nr. 2.7 – Fereastra de dialog pentru obţinerea raportului

„Situaţia vânzărilor pe gestiuni şi facturi
2.4.4 Evaluarea şi validarea interfeţei utilizator

După construirea prototipului, se trece la evaluarea acestuia, pentru a se stabili dacă el
satisface cerinţele utilizatorilor. În fapt, activitatea de evaluare este cea care determină
caracterul iterativ al procesului de proiectare al interfeţelor utilizator, prezentat în figura 2.7.
Utilizatorii vor evalua prototipul şi vor formula propriile observaţii cu privire la calitatea
interfeţei. Pe baza constatărilor şi a noilor cerinţe formulate de aceştia, proiectantul va
modifica specificaţiile de proiectare şi va construi un nou prototip. Noul prototip va fi supus
din nou operaţiunii de evaluare, acest ciclu continuând până când utilizatorii vor valida
interfaţa respectivă.
Proiectarea
preliminară
Construire
prototip nr. 1
Construire
prototip nr. N
Modificarea
Evaluarea
specificaţiilor
interfeţei
de proiectare
Analiza
rezultatelor
Interfaţă proiectată
complet
Fig. 2.7 Locul evaluării în procesul de proiectare a interfeţei utilizator

Obiectivele activităţii de evaluare vizează aprecierea comportamentului, performanţelor şi
satisfacţiei utilizatorilor în lucrul cu interfeţele. Testarea şi evaluarea interfeţei de către
utilizatori trebuie realizate cât mai devreme şi cât mai des cu putinţă. Dacă această activitate ar
fi realizată la sfârşitul procesului de proiectare, în cazul identificării unor probleme, s-ar putea
să fie prea târziu pentru a se mai putea efectua modificări asupra interfeţei, deoarece unele
modificări ar putea afecta programele şi baza de date. Chiar dacă aceste modificări pot fi
efectuate, nimeni nu va putea garanta că interfaţa astfel obţinută va corespunde cerinţelor
utilizatorilor.
2.5 Reguli de proiectare a meniurilor
Meniurile unei aplicaţii reflectă structura generală a sistemului informaţional, din punctul
de vedere al utilizatorului. Meniul conţine o ierarhie de opţiuni, grupate după diferite criterii.
Cel mai adesea, meniurile sunt structurate pe subsisteme (funcţii) sau acţiuni efectuate asupra
obiectelor. De exemplu, opţiunile principale din meniul unei aplicaţi privind gestiunea
relaţiilor cu clienţii pot fi: înregistrare tranzacţii, actualizare clienţi şi generare rapoarte
diverse. Meniurile pot fi aranjate şi pe baza obiectelor din sistem: comenzi, livrări, încasări,
clienţi, produse. În acest caz, unele funcţii vor fi redundante, întrucât fiecare dintre opţiunile
amintite va avea asociat un submeniu cu opţiuni precum actualizare sau rapoarte.
La proiectarea meniurilor trebuie analizate cu atenţie diagramele fluxurilor de date, în
special diagramele de nivel 0 şi 1. Structurarea meniurilor poate reflecta, în bună măsură,
structura funcţională a sistemului, rezultată prin procesul de descompunere a diagramelor
fluxurilor de edate. De regulă, proiectarea meniurilor se realizează în paralel cu proiectarea
arhitecturii programelor. Se va lua în considerare caracteristica generală a sistemului, adică
dacă el este orientat pe tranzacţii sau pe transformări. În acest sens, diagrama de structură,
instrumentul utilizat pentru descrierea arhitecturii programelor, va reflecta în partea sa
superioară structura meniului. De aceea, asupra proiectării meniurilor vom reveni în cadrul
capitolului destinat proiectării programelor.
În legătură cu proiectarea meniurilor, s-au conturat câteva convenţii standard, dintre care
le enumerăm pe cele mai importante:
• în cele mai multe aplicaţii se foloseşte poziţia File. În astfel de cazuri ea trebuie să fie
prima poziţie din linia meniului;
• poziţia Edit este întotdeauna a doua, dacă există;
• poziţia Window este întotdeauna penultima, dacă există;
• poziţia Help este întotdeauna ultima din linie, dacă există;
• o săgeată (¾) plasată în dreapta ultimului element înseamnă descompunerea acestuia
în submeniuri (vezi şi figura 2.2 a);
• elementele selectate sau activate vor fi marcate într-un anumit mod (de exemplu, bifare
în stânga numelui);
• prezentarea elementelor care, dacă sunt selectate, vor conduce la apariţia meniurilor
pop-up, marcate, de obicei, cu (…);
• afişarea pe prima linie a unui text-comentariu referitor la poziţia pe care se află
prompterul;
• ştergerea sau evidenţierea poziţiilor ce pot fi activate faţă de celelalte care nu pot fi
folosite (de exemplu, folosirea culorilor accentuate pe butoanele care pot fi activate, şi
aproape şterse pe celelalte);
• structura meniului trebuie să reflecte cât mai fidel succesiunea paşilor pe care
utilizatorul o foloseşte cel mai frecvent;
• oferirea a două sisteme de meniuri, unul pentru utilizatorii neexperimentaţi, care va
conţine un set minim de acţiuni, organizate în cascadă, şi unul pentru utilizatorii
experimentaţi, care va conţine toate opţiunile de lucru;
• gruparea opţiunilor astfel încât să se maximizeze similitudinea lor în cadrul categoriei
şi să se minimizeze similitudinea opţiunilor din categorii diferite;
• oferirea accesului direct la opţiunile critice sau utilizate frecvent;
• separarea opţiunilor care iniţiază acţiuni destructive de cele utilizate frecvent;
• includerea în meniu a unor opţiuni de lucru care nu se regăsesc în cerinţele funcţionale
(transpuse în diagrama fluxurilor de date). Astfel de opţiuni pot privi restaurarea sau
arhivarea bazei de date, întreţinerea conturilor de utilizatori, facilităţi de ajutor (help)
etc.
2.6 Aspecte privind proiectarea interfeţelor web
Internetul şi Web-ul oferă noi oportunităţi de desfăşurare a afacerilor şi de concepere a

sistemelor informaţionale. Tehnologia Web este, astăzi, larg utilizată în asigurarea comunicării
în cadrul firmei, pentru oferirea serviciilor informaţionale clienţilor firmei etc.
Regulile şi principiile generale de proiectare a interfeţelor, discutate anterior, sunt
aplicabile şi în proiectarea interfeţelor Web. Însă, tehnologia Web presupune unele
particularităţi faţă de interfeţele clasice. De exemplu, interfeţele Web oferă avantajul utilizării
hyper-link-urilor, ce uşurează navigarea de la o pagină la alta. Prin urmare, la proiectarea
interfeţelor şi site-urilor Web trebuie respectate unele principii de lucru specifice.
Jacob Nielsen a formulat 10 reguli care trebuie respectate la proiectarea interfeţelor Web.
Acestea sunt:
1. Includerea numelui şi a logo-ului firmei în fiecare pagină, iar logo-ul să fie o legătură
către pagina de început (home page).
2. Punerea la dispoziţie a funcţiei de căutare, dacă site-ul are mai mult de 100 de pagini.
3. Scrierea unor antete şi titluri de pagină directe şi simple, care să explice clar despre ce
este vorba în pagina respectivă, şi să fie relevante atunci când sunt citite în lista
obţinută prin intermediul unui motor de căutare.
4. Structurarea paginii astfel încât să faciliteze explorarea ei rapidă. De exemplu, se pot
utiliza gruparea şi subantetele, pentru a împărţi o listă lungă în câteva unităţi mai mici.
5. Utilizarea hypertext-ului pentru a structura spaţiul de afişare într-o pagină de început,
în care să fie prezentată o descriere succintă, şi mai multe pagini secundare, fiecare
orientată pe un anumit subiect (temă). Se evită astfel înghesuirea tuturor informaţiilor
într-o singură pagină uriaşă.
6. Evitarea construirii unor pagini cu multe fotografii, care să prezinte familii de
produse. Prima pagină de prezentare trebuie să fie încărcată şi deschisă în timp scurt.
7. Utilizarea de imagini miniaturale relevante, în locul imaginilor sau a fotografiilor prea
mari, minimizându-se astfel timpul de descărcare a paginilor. Pentru obţinerea
imaginilor miniaturale se vor utiliza, în combinaţie, ambele metode de reducere a unei
imagini, respectiv redimensionarea şi decuparea. Utilizarea uneia dintre cele două
metode poate reduce drastic calitatea imaginii obţinute. Aducerea la o scară redusă,
prin redimensionare, duce la pierderea unor detalii şi a clarităţii imaginii obţinute. Prin
decupare se păstrează detaliile, însă se pierde contextul întregii imagini, ceea ce poate
face nerelevantă imaginea miniaturală obţinută.
8. Utilizarea de titluri sugestive pentru legături, care să ofere utilizatorilor o imagine
corectă asupra conţinutului paginii ce va fi deschisă, înainte ca acesta să o acceseze.
9. Toate paginile importante trebuie să ofere facilităţi speciale de accesare pentru
utilizatorii cu diferite infirmităţi, îndeosebi pentru cei cu vederea slăbită.
10. Conceperea interfeţei în aceeaşi manieră în care o fac ceilalţi. Dacă cele mai multe
site-uri Web fac un anumit lucru într-o anumită manieră, atunci utilizatorii se vor
aştepta ca şi celelalte site-uri să funcţioneze similar.
2.7 Controlul datelor în interfeţele utilizator
În domeniul sistemelor informaţionale este arhicunoscut principiul GIGO (Garbage In,

Garbage Out – Gunoi Intră, Gunoi Iese), care evidenţiază importanţa corectitudinii,
consistenţei şi completitudinii datelor de intrare în obţinerea de informaţii relevante şi de înaltă
calitate. Respectarea acestui principiu constituie o miză extrem de importantă în proiectarea
interfeţelor utilizator, motiv pentru care este necesară definirea unor mecanisme de control,
care să realizeze verificarea datelor de intrare, înainte de salvarea lor în baza de date.
Erorile la introducerea datelor apar, de cele mai multe ori, ca urmare a adăugării de
caractere în plus sau a trunchierii datelor de intrare, a schimbării succesiunii a două sau mai
multor caractere. Deşi eliminarea completă a datelor eronate nu este posibilă, există totuşi o
serie de mecanisme de control care pot reduce considerabil apariţia erorilor. Aceste mecanisme
de control vor ajuta utilizatorii în identificarea anumitor tipuri de erori la culegerea datelor. În
tabelul 2.5 sunt enumerate şi descrise, succint, câteva mecanisme de control al datelor de
intrare, ce pot fi implementate la nivelul interfeţei utilizator.
Tabel nr. 2.5 – Mecanisme de control al datelor introduse în ecrane
Mecanisme de Explicaţii
control
Se verifică dacă datele dacă sunt de un anumit tip (numerice, alfanumerice, date
Tipul datelor
calendaristice etc.)
Verosimilitatea datelor depinde de la caz la caz. De exemplu, cantitatea vândută
Verosimilitate nu poate fi prea mare dacă preţul de vânzare este foarte mare. Nivelul salariului
sau al unei retrageri din cont bancar nu pot depăşi anumite limite.
Atunci când este posibil, aplicaţia va permite utilizatorului să aleagă o valoare
Selectarea unei
dintr-o listă, prin utilizarea căsuţelor combinate sau a celor de tip listă. De
valori, în locul
exemplu, pentru introducerea tipului de document se va prevedea în formular o
introducerii ei
căsuţă combinată sau butoane de opţiune.
Câmpurile din formulare, care sunt obligatoriu de completat, trebuie semnalate
Depistarea datelor
utilizatorilor, iar în momentul salvării datelor se va verifica dacă au fost
lipsă
completate toate câmpurile.
Această tehnică este utilizată pentru verificarea corectitudinii codurilor utilizate
Tehnica cifrei de
în aplicaţie, cum ar fi codul mărfii, al furnizorului etc. Un exemplu este prezentat
control
mai jos.
Pentru unele date pot fi definite şabloane, urmând a se verifica dacă datele
Formatul datelor introduse corespund acestora. Astfel de şabloane pot fi definite pentru datele
calendaristice, numere de telefon, numere de înmatriculare a autoturismelor etc.
Se verifică dacă datele introduse de utilizator se încadrează în intervalele de
Intervale de valori valori admise. De exemplu, notele obţinute la examen să fie în intervalul 0 – 10,
stocul să fie mai mare decât 0 etc.
Numărul de Numărul de caractere care trebuie introduse într-un câmp trebuie verificat atunci
caractere când este cunoscut. De exemplu, CNP-ul unei persoane este format din 13 cifre.
Validitatea datelor introduse în formulare poate fi determinată prin compararea
Compararea datelor lor cu datele stocate deja în baza de date. De exemplu, la introducerea codului
introduse cu cele sau a numelui clientului se va verifica dacă el există în baza de date. Acest
stocate mecanism permite utilizatorilor să verifice corectitudinea datelor introduse,
înainte de salvarea lor.
Dintre mecanismele de control enumerate în tabelul 2.5, tehnica cifrei de control este
ceva mai complex. Conform acesteia, codurile numerice utilizate pentru reprezentarea
diferitelor entităţi vor avea ultima cifră determinată pe baza unui algoritm. Acelaşi algoritm va
fi utilizat şi la introducerea codurilor respective în formulare, pentru a stabili validitatea lor.
Această tehnică este utilizată la stabilirea codului numeric personal (CNP) al unei persoane.
În caseta 2.8 sunt prezentate un exemplu de cod cu cifră de control şi algoritmul de
determinare a ei. Mai întâi, fiecărei cifre din cod i se atribuie câte un număr prim, în ordine
crescătoare, începând de la stânga spre dreapta. În cazul unui cod format din cinci cifre,
numerele prime utilizate vor fi 1, 2, 3, 5 şi 7. Primei cifre din stânga i se va atribui numărul 1,
celei de-a doua numărul prim 2 ş.a.m.d. Apoi, se va calcula suma ponderată a cifrelor din cod
cu numerele prime atribuite. Cifra de control se va determina prin aplicarea operaţiei „modulo
9” din suma ponderată rezultată. În final, se adaugă cifra de control la codul iniţial şi se va
obţine codul final.
Caseta nr. 2.8 – Exemplu de algoritm pentru calculul cifrei de control
Să considerăm codul numeric 12012.

Numerele cu care va fi ponderată fiecare cifră din cod sunt: 12012
12357
Suma ponderată va fi 1x1+2x2+0x3+1x5+2x7=24
Restul împărţirii sumei la 9 (modulo 9 din sumă): 24 : 9 = 2, iar restul este 6.
Cifra de control este 6, iar codul rezultat va fi 120126.
În tabelul 2.5 sunt prezentate doar mecanismele de control care realizează verificarea
automată a datelor introduse prin intermediul ecranelor. În afara acestora, pot fi prevăzute
mecanisme care să permită utilizatorilor să verifice ei înşişi corectitudinea datelor, în
momentul introducerii lor. Un astfel de mecanism îl reprezintă afişarea informaţiilor de
identificare a entităţilor în legătură cu care se introduc date, mai ales atunci când se folosesc
coduri. De exemplu, după introducerea codului pentru furnizorul care a emis factura, se vor
afişa, în câmpuri alăturate, datele sale de identificare, preluate automat din baza de date,
respectiv numele, adresa etc. Utilizatorul va avea posibilitatea să compare aceste informaţii cu
cele înscrise în factură şi să depisteze eventualele neconcordanţe. Aceeaşi procedură poate fi
utilizată şi pentru introducerea datelor privind mărfurile din factură.
O altă procedură constă în afişarea unor totaluri sau a altor câmpuri calculate. De
exemplu, în formularul pentru introducerea facturilor primite de la furnizori se va afişa
valoarea TVA şi totalul facturii. Dacă aceste valori diferă de cele înscrise în factură, atunci
este foarte probabil ca utilizatorul să fi introdus greşit cantitatea sau preţul pentru una sau mai
multe mărfuri.
2.8 Formularea specificaţiilor de proiectare a interfeţelor

Specificaţiile de proiectare a interfeţelor şi dialogurilor se pot concretiza într-o formă
similară celei prezentate în continuare.
1. Prezentare generală descriptivă
1.1. Numele interfeţei/dialogului
1.2. Caracteristicile utilizatorului
1.3. Caracteristicile activităţii
1.4. Caracteristicile sistemului
1.5. Caracteristicile mediului de lucru
2. Proiectele interfeţelor/dialogurilor
2.1. Proiectele formularelor/formatelor/rapoartelor
2.2. Diagramele secvenţelor de derulare a dialogurilor şi prezentarea descriptivă a
acestora
3. Testarea şi evaluarea interfeţelor/dialogurilor în utilizare
3.1. Obiectivele testării
3.2. Procedurile testării
3.3. Rezultatele testării
3.3.1. Timpul de învăţare
3.3.2. Viteza de execuţie
3.3.3. Rata erorilor
3.3.4. Rezistenţa în timp
3.3.5. Satisfacţia şi alte percepţii ale utilizatorului
Rezumat
Interactivitatea reprezintă una dintre caracteristicile esenţiale ale sistemelor informaţionale
economice, drept pentru care proiectarea interfeţelor utilizator reprezintă o activitate critică. Prin
interfaţă utilizator, în acest capitol, facem referire la componentele software ale aplicaţiei, care au rolul
de a asigura dialogul între utilizator şi sistem, în vederea culegerii şi salvării datelor (ecrane/formulare),
obţinerii rapoartelor necesare sau iniţierii diferitelor operaţiuni (meniuri).
Una dintre primele activităţi realizate în cadrul proiectării o reprezintă identificarea interfeţelor
utilizator. Această activitate, realizată pe baza rezultatelor fazei de analiză, presupune interpretarea
diagramelor fluxurilor de date şi a graniţelor informatizării, stabilite la definirea strategiei de proiectare.
Intrările şi ieşirile care depăşesc graniţele pot prezenta interes din perspectiva proiectării interfeţelor
utilizator. Însă, nu toate intrările/ieşirile în/din sistem implică intervenţia directă a utilizatorilor, caz în
care ele vor fi referite ca interfeţe sistem. Ele apar în cazul culegerii automate a datelor, a
intrărilor/ieşirilor provenite/transmise de la/către alte sisteme informaţionale, care nu presupun intervenţia
utilizatorilor, sau a ieşirilor pentru obţinerea cărora rolul oamenilor este redus. Aceste tipuri de interfeţe
vor fi tratate în capitolul destinat proiectării programelor.
La proiectarea interfeţelor utilizator trebuie alese cu grijă metodele şi echipamentele ce vor fi
folosite în dialogul om-calculator, cu atât mai mult cu cât ele sunt numeroase şi supuse direct evoluţiei
rapide din domeniul tehnologiilor informaţionale.
Cele mai utilizate metode de interacţiune om-calculator sunt: limbajul-comandă, meniurile şi
ecranele pentru culegerea datelor, referite de noi şi prin formulare. Interacţiunea prin limbaj-comandă
presupune ca utilizatorul să realizeze o anumită operaţiune prin transmiterea unei comenzi. Cele mai
cunoscute tipuri sunt: comenzile sintactice, comenzile mnemonice, comenzile-taste şi comenzile în
limbajul natural. Interfeţele bazate pe comenzi sunt mai greu de învăţat, întrucât utilizatorul trebuie să
cunoască foarte bine sintaxa acestora. Spre deosebire de acestea, interacţiunea prin meniuri solicită mai
puţin memoria utilizatorului, motiv pentru care ele sunt familiare tuturor celor care folosesc astăzi
calculatorul. Un meniu pune la dispoziţie o listă de opţiuni, din care utilizatorul va selecta pe cea dorită.
În funcţie de modul de afişare, meniurile pot fi de mai multe tipuri, dintre care amintim: liste simple cu
opţiuni, linii-meniu, meniu de tip bară, meniuri context şi meniuri prin imagini. Interacţiunea prin ecrane
(formulare) este folosită, în special, pentru culegerea datelor, dar şi pentru afişarea unor informaţii din
baza de date. În construirea formularelor se apelează la o serie de obiecte de control, dintre care amintim:
căsuţă de text, căsuţă cu listă sau combinată, butoane de opţiune sau butoane de comandă.
În literatura de specialitate au fost formulate numeroase principii, care să ghideze specialiştii în
proiectarea unor interfeţe utilizator de calitate. Mai mult, marii producători de software, precum
Microsoft, IBM şi Apple, şi-au definit propriul set de principii şi reguli, pe care le aplică în dezvoltarea
produselor lor. În prezentarea acestor principii, noi am optat pentru gruparea lor în trei reguli de bază:
controlul aplicaţiei de către utilizator, limitarea volumului de informaţii memorate de utilizator şi
uniformitatea interfeţelor.
Prima regulă presupune ca utilizatorul să joace un rol activ, şi nu unul reactiv, în sensul că acesta
trebuie să simtă că el este cel care controlează aplicaţia şi nu invers. El va fi cel care iniţiază operaţiunile,
controlând astfel derularea proceselor realizate cu calculatorul. Câteva dintre principiile utilizate în
aplicarea acestei reguli sunt: utilizarea judicioasă a modurilor de lucru, principiul retroacţiunii imediate,
menţinerea stilului de lucru al utilizatorilor.
Reducerea cantităţii de informaţii pe care trebuie să o memoreze utilizatorul, cea de-a doua regulă
enunţată, vizează utilizarea calculatorului pentru acoperirea limitelor memoriei umane, atât cea pe termen
scurt, cât şi cea pe termen lung. Pentru aceasta, avem la dispoziţie o serie de principii, precum: orientarea
interfeţei pe recunoaştere, prevederea formelor scurte pentru realizarea unor operaţiuni, principiul
relevanţei vizuale etc.
Cea de-a treia regulă, uniformitatea interfeţelor utilizator, presupune aplicarea aceloraşi convenţii de
proiectare a interfeţelor în cadrul sistemului. Uniformitatea vizează modalitatea de prezentare a interfeţei,
comportamentul acesteia şi interacţiunea cu utilizatorul.
Obţinerea unor interfeţe utilizator de calitate implică nu doar aplicarea unor principii de lucru, ci şi
urmărirea unui demers riguros, format din mai multe etape şi activităţi bine definite, şi care să fie orientat
spre utilizator. De aceea, procesul de proiectare a interfeţelor este unul iterativ, care utilizează tehnica
prototipizării. Etapele acestui demers sunt: culegerea şi analiza informaţiilor de la utilizatori,
proiectarea interfeţelor, construirea lor şi evaluarea de către utilizatori. În fapt, activitatea de evaluare
este cea care determină caracterul iterativ a procesului de proiectare al interfeţelor utilizator.
În acest capitol, sunt prezentate şi unele reguli specifice de proiectare a meniurilor şi a interfeţelor
web. Meniul unei aplicaţii trebuie să reflecte structura funcţională a sistemului, dar din punctul de vedere
al utilizatorilor, care poate fi regăsită în diagramele fluxurilor de date. De asemenea, la proiectarea
meniurilor trebuie respectate unele convenţii standard. Tehnologia web presupune unele particularităţi
faţă de interfeţele clasice, motiv pentru care există anumite reguli specifice de proiectare.
O problemă deosebit de importantă în proiectarea interfeţelor utilizator o reprezintă controlul
datelor, în vederea asigurării corectitudinii şi completitudinii lor. Pornind de la principalele tipuri de eori
întâlnite la culegerea datelor, au fost formulate mai multe mecanisme de control, dintre care amintim:
verosimilitatea, tehnica cifrei de control, tipul şi formatul datelor, compararea datelor introduse cu cele
stocate în baza de date.
În finalul capitolului, este prezentat un model de specificaţii de proiectare a interfeţelor şi
dialogurilor, ce conţine, în sinteză, rezultatele activităţilor parcurse.
1. Explicaţi importanţa proiectării interfeţelor utilizator în dezvoltarea sistemelor informaţionale.
2. Care este rolul diagramelor fluxurilor de date în proiectarea interfeţelor utilizator?
3. În ce constă diferenţa dintre interfaţa utilizator şi interfaţa sistem?
4. Enumeraţi şi descrieţi pe scurt principalele metode de interacţiune om-calculator.
5. Enumeraţi tipurile de meniu şi explicaţi avantajele şi dezavantajele specifice fiecărui tip în parte.
6. Care este diferenţa dintre butoanele radio şi căsuţele de validare? Dar între căsuţa de tip listă şi
căsuţa combinată?
7. Prezentaţi 8 funcţiuni pe care trebuie să le ofere un formular pentru introducerea datelor.
8. Ce tip de obiect trebuie utilizat în formular atunci când utilizatorul trebuie să aleagă una din cinci
opţiuni care nu se schimbă în timp? Dar dacă sunt 10 opţiuni posibile?
9. Care sunt avantajele utilizării unui standard în proiectarea interfeţelor utilizator?
10. Prezentaţi 5 reguli de proiectare a interfeţelor utilizator, a căror aplicare ar duce la creşterea
eficacităţii introducerii datelor în formulare.
11. Descrieţi cele mai importante 5 reguli de proiectare a interfeţelor pentru utilizatorii experimentaţi.
12. Descrieţi cele mai importante 5 reguli de proiectare a interfeţelor pentru utilizatorii neexperimentaţi.
13. Care sunt avantajele proiectării unor interfeţe în care utilizatorul să deţină controlul asupra
aplicaţiei? Care sunt dezavantajele?
14. Ce presupune optimizarea interfeţei pentru lucrul cu tastatura?
15. Enumeraţi şi descrieţi principiile de proiectare care duc la reducerea volumului de informaţii pe care
utilizatorul trebuie să le memoreze pe termen lung.
16. În ce constă uniformitatea interfeţei utilizator? Cum poate fi obţinută?
17. Enumeraţi şi descrieţi trei principii de proiectare a interfeţelor care asigură uşurinţa învăţării
acestora.
18. Enumeraţi şi descrieţi trei principii de proiectare a interfeţelor care asigură uşurinţa utilizării
acestora.
19. Explicaţi avantajele unui proces iterativ de proiectare a interfeţelor utilizator.
20. Descrieţi, pe scurt, etapele şi activităţile procesului de proiectare a interfeţelor utilizator.
21. Care sunt factorii de definire a calităţii interfeţelor?
22. Explicaţi de ce obiectivele generale privind calitatea interfeţelor utilizator, uşurinţa învăţării şi
uşurinţa în utilizare, se pot afla în contradicţie.
23. De ce credeţi că este necesară reorganizarea atribuţiilor de serviciu ale utilizatorilor când, prin
dezvoltarea noului sistem informţional, se trece de la unul neintegrat la unul integrat? Ce importanţă
ar avea această reorganizare asupra proiectării interfeţelor utilizator?
24. Descrieţi principiile proiectării orientate spre utilizator a interfeţelor?
25. Care este avantajul utilizării tehnicii cifrei de control?
26. Ce categorii de utilizatori ai sistemelor informaţionale pot fi identificate în general? De ce este

importantă luarea în considerare a categoriilor de utilizatori în activitatea de proiectare a interfeţelor?
27. Descrieţi 5 reguli de proiectare a sistemului de meniuri.
28. Care sunt regulile de proiectare a paginilor Web?
29. Enumeraţi elementele specificaţiei de proiectare a interfeţelor utilizator.
Probleme
1. Daţi câte 3 exemple de interfeţe sistem pentru următoarele sisteme informaţionale: Gestiunea
clienţilor, Urmărirea aprovizionării, Evidenţa cheltuielilor, Evidenţa încasărilor şi plăţilor.
2. Precizaţi ce tipuri de obiecte veţi utiliza la proiectarea unui formular pentru preluarea consumurilor
de materiale, ştiind că trebuie introduse următoarele date: tipul (bon de consum sau fişă limită de
consum), numărul şi data documentului, locul de consum (există 15 departamente, secţii şi ateliere),
codul, denumirea şi preţul materialelor (maxim 7 materiale pe un document), cantitatea solicitată,
cantitatea aprobată şi valoarea consumată, valoarea totală a documentului.
3. Alegeţi mecanismul cel mai potrivit pentru controlul datelor în vederea depistării următoarelor erori
de introducere a datelor:
• introducerea într-o căsuţă de text a valoarii 220459 în loc de 220549;
• specificarea datei 30 februarie;
• introducerea judeţului Vslui în loc de Vaslui;
• specificarea a 320 ore lucrate pentru un angajat, la preluarea datelor din centralizatorul lunar al
pontajelor;
• introducerea valorii Iasirad în loc de Iasiard, pentru numele clientului;
• nespecificarea cantităţii pentru un produs, la preluarea datelor de pe o factură;
• introducerea greşită cantităţii, pentru o marfă achiziţionată prin factură;
• introducerea valorii IS-289-GDF, pentru numărul de înmatriculare al unui camion;
• introducerea sumei de 2500 lei pentru plata unei facturi, deşi valoarea facturii este de numai
2000 lei.
CAPITOLUL III
Proiectarea logică a bazelor de date:

modelarea logică a datelor
Obiective:
• Definirea locului modelării logice a datelor în ciclul de viaţă al sistemelor
• Identificarea aspectelor calitative ale modelului logic al datelor
• Definirea strategiilor de proiectare logică a bazelor de date
• Descrierea demersului de proiectare logică a bazei de date
• Transformarea diagramei entitate-relaţie într-un set de relaţii normalizate
În timpul analizei sistemelor, s-a discutat despre dezvoltarea sistemului informaţional din
trei puncte de vedere:
• determinarea cerinţelor sistemului;
• structurarea cerinţelor;
• generarea şi selecţia variantelor noului sistem.
Componenta referitoare la structurarea cerinţelor a fost tratată astfel:
• modelarea logică a proceselor de prelucrare;
• modelarea logicii proceselor;
• modelarea conceptuală a datelor (diagrama entitate-relaţie).
Capitolul de faţă este în strânsă legătură cu modelarea conceptuală a datelor. Pentru o şi
mai bună clarificare, revenim la aplicarea principiului abstractizării, discutat şi în cadrul etapei
de analiză, conform căruia datele sunt modelate pe trei niveluri: conceptual, logic şi fizic.
Acum ne concentrăm asupra celui de-al doilea nivel de abstractizare, respectiv modelarea
logică a datelor. În timpul modelării conceptuale s-a urmărit reprezentarea modului de
organizare a datelor, independent de tehnologiile specifice de stocare şi prelucrare a bazelor de
date, fără să se înregistreze o preocupare anume referitoare la calitatea modelelor. Ultimului
aspect i se va acorda atenţia cuvenită abia acum, odată cu modelarea logică a datelor,
descriindu-se structurile datelor din bază.
3.1 Locul modelării logice a datelor

în ciclul de viaţă al sistemelor
Modelarea logică a datelor descrie datele cu ajutorul unei notaţii speciale, care
corespunde unui mod de organizare a acestora de către un sistem de gestiune a bazelor de date
relaţionale, numit şi model relaţional.
Diferenţa majoră dintre modelarea conceptuală şi cea logică a datelor este aceea că, după
modelarea logică a datelor, cerinţele structurate de date se concretizează în relaţii (tabele), şi
nu în entităţi. Din cauza unor criterii de calitate şi reguli de organizare diferite, cum ar fi
normalizarea, nu este necesară o corespondenţă biunivocă între mulţimea entităţilor şi cea a
relaţiilor.
Principalele criterii de calitate utilizate în evaluarea modelului logic al datelor sunt21:
21. Simsion, G.C. – Data Modeling Essentials. Analysis, Design, and Innovation, Second Edition, The Coriolis
Group, 2001, Scottsdale, Arizona, pp. 11-15.
PROIECTAREA LOGICĂ A BAZELOR DE DATE: MODELAREA LOGICĂ A DATELOR 79
• Completitudine. Modelul logic trebuie să conţină toate datele necesare prelucrărilor în

vederea obţinerii ieşirilor din sistem.
• Neredundanţă. Redundanţa datelor generează probleme privind integritatea lor (vezi
anomaliile la actualizare descrise în acest capitol) şi solicită procese suplimentare
pentru întreţinerea datelor. De aceea, modelul logic trebuie să fie format dintr-un set de
tabele normalizate.
• Reutilizare. Schema logică a bazei de date trebuie concepută astfel încât ea să satisfacă
nu doar cerinţele anticipate ale sistemului, ci şi pe cele ale altor potenţiali utilizatori
sau eventualele cerinţe viitoare care apar inevitabil. Dacă datele sunt organizate având
în minte doar cerinţele actuale, atunci reorganizarea datelor, determinată de apariţia
unor noi cerinţe funcţionale, poate fi foarte costisitoare.
• Stabilitate şi flexibilitate. Aceste criterii vizează uşurinţa adaptării bazei de date la
modificările ulterioare ale cerinţelor sistemului. Un model al datelor este considerat
stabil dacă eventualele modificări ale cerinţelor funcţionale nu determină schimbarea
structurii sale. Schema bazei de date va fi considerată mai stabilă sau mai puţin stabilă
în funcţie de amploarea modificărilor generate de schimbarea cerinţelor. Flexibilitatea
unui model al datelor este dată de uşurinţa extinderii sale pentru înglobarea noilor
cerinţe cu impact minim asupra structurii existente.
• Simplitate şi eleganţă. Modelul logic al datelor trebuie să ofere o clasificare naturală şi
elegantă a datelor. De exemplu, este inadecvată existenţa tabelelor FURNIZOR şi
CLIENT, atât timp cât unii parteneri de afaceri pot fi atât furnizori, cât şi clienţi.
Aceeaşi situaţie poate apărea în cazul facturilor, fiind neelegantă conceperea a două
tabele, una pentru facturi emise şi alta pentru facturi primite, atât timp cât ele au
structuri similare.
Tot acum facem menţiunea că relaţiile (tabelele) nu corespund fişierelor fizice realizate cu
calculatorul, operaţiune efectuată în timpul proiectării fizice, descrisă într-un capitol următor.
După cum vom vedea, obiectivele şi criteriile de calitate sunt diferite de cele vizate la
proiectarea logică a datelor.
Procesul de modelare logică a datelor se derulează în paralel cu celelalte activităţi ale
proiectării logice: proiectarea formularelor şi a rapoartelor, proiectarea dialogurilor şi
interfeţelor. Modelarea logică a datelor se realizează nu numai pe baza diagramei entitate-
relaţie, ci şi pe baza machetelor formularelor şi a rapoartelor. Se efectuează analiza datelor
elementare din intrările şi ieşirile sistemului, pentru a se desprinde legăturile dintre ele.
Procesul de modelare a datelor este complex. În fiecare etapă a ciclului de viaţă al
sistemelor se regăseşte câte o activitate specifică datelor, conform tabelului 3.1.
Tabel nr. 3.1 – Relaţia dintre etapele ciclului de viaţă al sistemelor şi modelarea datelor
Etapa din ciclul de Elemente de modelare a datelor
viaţă al sistemului
Identificarea şi selecţia Modelul general al datelor la nivel de întreprindere (DER doar cu entităţi).
proiectelor
Iniţierea şi planificarea Modelul conceptual al datelor. Prezentarea DER cu entităţile specifice unor
proiectului proiecte.
Analiza Modelele conceptuale ale datelor. Se prezintă DER în care se includ şi
atributele.
Proiectarea logică Modelul logic al datelor (relaţional).
Proiectarea fizică Proiectarea fişierelor şi bazelor de date fizice (organizarea fişierelor).
Implementarea Descrierea fişierelor şi bazelor de date (codificarea unor SGBD).
Întreţinerea Evoluţia modelului datelor.
Întrucât modelul relaţional reprezintă subiectul central al discuţiei noastre despre

modelarea logică a datelor, în paragraful următor, vom descrie conceptele sale de bază.
3.2 Demersul proiectării logice a bazelor de date

Proiectarea schemei logice a bazei de date poate fi realizată în mai multe moduri.
Abordarea tradiţională, aplicată, în special, în cazul bazelor de date relaţionale, presupune
constituirea relaţiei generale prin reunirea tuturor datelor elementare (atribute), identificate în
faza de analiză, şi repartizarea lor în tabele, pe baza analizei dependenţelor dintre atribute
(dependenţe funcţionale, dependenţe multivaloare şi de joncţiune) şi aplicarea procesului de
normalizare. Această abordare a înregistrat unele succese în proiectarea bazelor de date de
dimensiuni mici şi medii, însă ea devine foarte greoaie în cazul bazelor de date de dimensiuni
mari şi foarte mari.
Introducerea modelului entitate-relaţie a determinat reorientarea specialiştilor către o nouă
abordare în proiectarea bazelor de date. Aceasta presupune, mai întâi, modelarea conceptuală a
datelor, prin construirea diagramei entitate-relaţie, care evidenţiază entitaţile de date ale
sistemului, atributele acestora şi legăturile dintre entităţi. Ulterior, prin aplicarea unor reguli
simple, are loc transformarea DER în schema logică a bazei de date. Tabelele astfel rezultate
sunt, în final, analizate din perspectiva normalizării, cu posibilitatea obţinerii unor tabele noi.
Corespunzător celor două abordări, există două strategii de proiectare a schemei logice a
bazei de date:
• strategia bottom-up reprezintă abordarea tradiţională şi presupune constituirea relaţiei
generale care urmează a fi supusă normalizării pentru a se obţine tabelele bazei de
date;
• strategia top-down presupune construirea DER şi apoi transformarea ei într-un set de
tabele, prin aplicarea unor reguli. Tabelele rezultate vor fi analizate din perspectiva
normalizării.
Utilizarea strategiei top-down oferă o serie de avantaje, faţă de abordarea tradiţională22:
• diagrama entitate-relaţie reprezintă un instrument util de comunicare între analişti şi
utilizatori pe parcursul fazelor de analiză şi proiectare logică;
• modelul entitate-relaţie este uşor de înţeles şi conceput. În general, prezentarea grafică
permite exprimarea unui volum mare de informaţii sub o formă compactă, uşor de
urmărit şi înţeles;
• utilizează conceptul de abstractizare, ceea ce reduce considerabil numărul obiectelor
luate în considerare la analiza şi proiectarea bazei de date. Prin utilizarea noţiunii de
entitate (sau clasă de entităţi), ca abstractizare pentru datele elementare (atribute), se
vor analiza mai puţine obiecte (numărul entitaţilor de date este mult mai mic decât
numărul datelor elementare din sistem) şi mai puţine relaţii între obiecte (numărul
relaţiilor dintre entităţi este mult mai mic decât numărul relaţiilor de dependenţă
existente între atribute). Deşi datele elementare sunt reprezentate şi în modelul entitate-
relaţie, ca proprietăţi ale entităţilor, totuşi numărul dependenţelor ce trebuie analizate
este mult redus, fiind luate în considerare doar dependenţele dintre atributele unei
entităţi şi nu dependenţele dintre toate atributele bazei de date.
• Existenţa unui set complet de reguli de transformare a DER în tabele ale bazei de
date. Aceste reguli permit transformarea simplă şi rapidă a cerinţelor informaţionale
ale sistemului, structurate în DER, în baza de date. În acest sens, majoritatea
instrumentelor CASE oferă suport pentru generarea automată a bazei de date, în
funcţie de SGBD-ul dorit.
Pornind de la cele două strategii, pot fi identificate demersuri diferite de proiectare a bazei
de date, mai mult sau mai puţin riguroase. Două dintre ele corespund celor două strategii, ele
fiind descrise pe scurt anterior. Un demers mai riguros presupune combinarea celor două
22. Adaptare după Teorey, T.J. – Database Modeling & Design, Morgan Kaufmann Publishers, Inc, 1999, San
Francisco, p. 46.
strategii: se aplică ambele strategii, pentru obţinerea a două modele logice ale datelor, iar, din
compararea lor, va rezulta schema logică finală a bazei de date. În acest fel se combină
avantajele strategiei top-down, enumerate anterior, cu abordarea mai analitică, specifică
strategiei bottom-up. Chiar dacă este mai îndelungat şi mai costisitor, un astfel de demers oferă
garanţii suplimentare privind calitatea schemei logice a bazei de date, mai ales în ce priveşte
completitudinea.
Un asemenea demers presupune parcurgerea următorilor patru paşi:
1. Construirea câte unui model logic al datelor din perspectiva utilizatorului (formulare şi
rapoarte) privind aplicaţia, respectându-se principiile normalizării.
2. Integrarea tuturor perspectivelor normalizate ale utilizatorilor, obţinute prin
parcurgerea pasului anterior, într-un model logic consolidat al datelor.
3. Transformarea modelului conceptual al datelor (entitate-relaţie), realizat fără să se ţină
cont de perspectiva utilizatorului, într-un set de relaţii normalizate.
4. Compararea modelului logic consolidat al datelor, rezultat prin integrarea
perspectivelor utilizatorilor (pasul 2), cu cel obţinut prin transformarea DER (pasul 3),
în vederea definirii modelului logic final al datelor.
În practică, poate fi angajat un alt demers, mai simplu (uneori simplist!), de proiectare a
bazei de date, constând în transpunerea directă a cerinţelor sistemului în modelul logic al
datelor, fără parcurgerea unor paşi intermediari. Cu alte cuvinte, analistul va exprima cerinţele
funcţionale nestructurate ale sistemului direct în termenii tabelelor, coloanelor şi restricţiilor.
Un asemenea demers poate fi aplicat în cazul bazelor de date de dimensiuni foarte mici sau
dacă analistul are o mare experienţă în domeniul problemei. Oricum, alegerea unui demers sau
a altuia depinde de complexitatea bazei de date, de experienţa echipei de proiectare, de timpul
şi resursele financiare disponibile sau de cerinţele de calitate dorite.
În continuare, vom dezbate, pe rând, cele două strategii de proiectare, după care vom
prezenta căteva consideraţii legate de conţinutul celui de-al patrulea pas al demersului propus,
respectiv contopirea rezultatelor obţinute în paşii 2 şi 3.
3.3 Transformarea diagramelor

entitate-relaţie în relaţii
Din descrierile anterioare rezultă că normalizarea este un proces ascendent (bottom-up),

prin care se obţine un set de relaţii bine structurate, care să conţină toate datele solicitate din
exteriorul sistemului şi pe cele consemnate în ieşirile lui. Acum, vom prezenta principalele
reguli care se aplică în cadrul strategiei top-down, pentru transformarea DER într-un set de
relaţii normalizate, reunite într-un proces. El reprezintă conţinutul celui de-al treilea pas al
demersului propus pentru proiectarea logică a bazei de date.
Prin transformarea DER, pot rezulta patru tipuri de tabele:
1. Tabele care vor avea acelaşi conţinut ca entităţile originale. Acest tip de tabele
rezultă din transformarea (1) entităţilor implicate în relaţii binare de tipul „multe-la-
multe”, (2) a celor situate în partea „unu” a unei relaţii binare „unu-la-multe” sau (3) a
uneia dintre cele două entităţi aflate într-o relaţie „unu-la-unu”; acelaşi tip de tabele
poate rezulta şi din transformarea (4) entităţilor cu relaţii recursive de tipul „multe-la-
multe” sau (5) a entităţilor implicate în relaţii ternare. Cheia primară a acestor tabele
va fi reprezentată de cheia entităţii originale, iar celelalte proprietăţi ale entităţii vor
deveni atribute non-cheie în tabela rezultată. Tabelele de acest tip vor juca,
întotdeauna, rolul de părinte în legăturile cu tabele încadrate în celelalte tipuri.
2. Tabele care vor conţine cheia primară a entităţii părinte. Acest tip de transformări
apar în cazul (1) entităţilor aflate de partea „multe” a unei relaţii binare de tipul „unu-
la multe”, (2) a uneia dintre entităţile legate printr-o relaţie „unu-la unu”, precum şi (3)
a entităţilor cu legături recursive de tipul „unu-la-unu” sau „unu-la-multe”. Tabelele

rezultate în urma acestor transformări vor juca rolul de tabelă copil. Ele vor avea ca
atribute proprietăţile entităţii originale, la care se adaugă cheia principală a entităţii cu
care este legată şi care va juca rolul de cheie străină/externă.
3. Tabele care vor conţine cheile tuturor entităţilor asociate într-o relaţie. Aceste tabele
derivă din transformarea (1) legăturilor binare sau recursive de tipul „multe-la-multe”,
precum şi (2) a legăturilor ternare sau de un ordin mai mare de trei. Ele mai sunt
numite şi entităţi asociative, iar o tabelă de acest tip va conţine cheile primare ale
tuturor entităţilor asociate, fiecare jucând rolul de cheie străină, precum şi eventualele
proprietăţi ale relaţiei. Cheia principală a tabelei este formată, de regulă, prin
combinarea cheilor străine.
4. Tabele care vor conţine atributele multivaloare ale unei entităţi. În cazul în care o
entitate conţine unul sau mai multe atribute multivaloare, atunci se va constitui o
tabelă distinctă care va conţine atributele multivaloare, preluând şi cheia entităţii
originale. De regulă, cheia primară va fi formată din cheia entităţii originale la care se
adaugă unul sau mai multe din celelalte atribute. Acest caz a fost discutat în capitolul
10 din volumul 1, atunci când am prezentat entităţile atributive.
Regulile anterioare de transformare iau în considerare numai maximul cardinalităţii
relaţiilor dintre entităţi. Minimul cardinalităţii, care descrie caracterul obligatoriu/facultativ al
relaţiei dintre entităţi, indică dacă pentru cheile străine sunt permise valorile nule sau nu. În
acest sens, se va lua în considerare minimul cardinalităţii unei legături de partea entităţii
părinte (adică entitatea din partea în care maximul cardinalităţii este”unu”); dacă legătura este
opţională, atunci se vor permite valorile nule pentru cheia străină în tabela-copil; în cazul
legăturilor obligatorii, nu se vor permite valori nule pentru cheile străine.
Transformarea DER într-un set de tabele normalizate presupune parcurgerea a patru paşi:
1. Reprezentarea entităţilor, în care se obţin tabele din prima categorie;
2. Reprezentarea relaţiilor dintre entităţi, activitate în urma căreia vor rezulta tabele din
a doua şi a treia categorie.
3. Reprezentarea atributelor multivaloare, caz în care se vor obţine tabele din ultima
categorie.
4. Normalizarea relaţiilor. Tabelele create în paşii 1 şi 2 pot conţine redundanţe nedorite
şi vor constitui surse ale anomaliilor la actualizare.
Deoarece subiectul de la pasul 4 a fost tratat anterior, în cele ce urmează vom discuta doar
primii trei paşi.
3.3.1 Reprezentarea entităţilor

Fiecare entitate din diagrama entitate-relaţie este reprezentată ca o relaţie (tabelă) în
modelul logic al datelor. Identificatorul entităţii devine cheie primară a relaţiei, iar celelalte
proprietăţi ale entităţii devin atribute non-cheie. Ulterior, ca rezultat al transformării legăturilor
dintre entităţi, unele entităţi vor avea ca atribute cheile primare ale altor entităţi. Ele se mai
numesc şi entităţi slabe.
Reprezentarea unei entităţi ca relaţie se face în mod direct, după cum rezultă din figura
3.2, prin alegerea uneia dintre formele (b), (c) şi (d).
NUME
(a) MARCA ADRESA

ANGAJAT
(b) ANGAJAT (MARCA, NUME, ADRESA)
(c) ANGAJAT :MARCA, NUME, ADRESA

ANGAJAT
(d) Marca Nume Adresa
1111 Ion Ion Arini, 28, Iasi
1112 Ion Ionel Anini, 120, Blaj
Fig. 3.2 Entitatea ANGAJAT şi formele de reprezentare ca relaţie
3.3.2 Reprezentarea legăturilor

Am recurs la noţiunea de legătură în locul celei de relaţie (cu sensul de înrudire) pentru a
nu se confunda cu termenul relaţie (sub accepţiunea de tabelă), care preia conţinutul entităţilor
din DER.
Procedura de reprezentare a legăturilor depinde atât de gradul legăturii (unară, binară,
ternară), cât şi de cardinalitatea ei (1:1, 1:M, M:N).
3.3.2.1 Reprezentarea legăturilor binare 1:N şi 1:1
O legătură binară unu-la-multe dintr-o diagramă entitate-relaţie este reprezentată prin
adăugarea atributului/atributelor-cheie-primară al/ale entităţii aflate în partea „unu” a legăturii
ca cheie-străină în tabela corespunzătoare entităţii aflată în partea „multe” (vezi figurile 3.3 şi
3.4). Pentru cheia străină se acceptă valori nule numai dacă participarea entităţii de partea
„unu” a legăturii este facultativă.
În figura 3.3 este prezentată legătura „Onorare” dintre entităţile FACTURA şi COMANDA,
legătură de tip 1:N. Se vor constitui două relaţii, FACTURA şi COMANDA, aferente celor două
entităţi. Reprezentarea legăturii 1:N dintre cele două entităţi presupune ca Fact_nr, care este
cheie primară în tabela FACTURA (situată la capătul „unu” al legăturii), să fie adăugată drept
cheie-străină în tabela COMANDA (aflată la capătul „multe” al legăturii). Am evidenţiat cheia
străină nu doar prin scrierea cu caractere înclinate, ci şi prin specificarea „[FK]” („foreign
key”) în dreptul ei, întrucât această modalitate este frecvent întâlnită în produsele CASE.
Factura Fiecare comandă este onorata de
Fact_nr către furnizor prin intermediul a
Fact_data maxim o livrare (factură) sau nici Factura
una, în timp ce printr-o factură el Fact_nr
(0,1) Fact_data
poate onora mai multe comenzi.
Onorare
Comanda
Cmd_nr
(1,M) Cmd_data
Fact_nr [FK] NULL
Comanda
Cmd_nr
Cmd_data
Fig. 3.3 Transformarea relaţiilor 1:N în care

participarea entităţii din partea „unu” este facultativă
Observaţi că pentru cheia străină (atributul Fact_nr din tabela COMANDA) se admite
valoarea nulă, dat fiind cardinalitatea minimă 0 din dreptul entităţii FACTURĂ, care este
părinte (participarea entităţii părinte este facultativă). Deşi în realitate pot exista situaţii de
tipul prezentat anterior, trebuie să spunem că ele trebuie evitate, deoarece admiterea valorii
nule pentru cheia străină poate crea dificultăţi în menţinerea integrităţii datelor din bază.
Relaţiile (tabelele) rezultate sunt prezentate în partea dreaptă a figurii 3.3. O altă formă de
prezentare o redăm mai jos (cheia primară este subliniată cu o linie continuă, iar cheia străină
cu o linie întreruptă):
FACTURA(Fact_nr, Fact_data)
COM ANDA(Cmd_nr, Cmd_data, Fact_nr)
În figura 3.4 avem tot o relaţie 1:N, dar în care participarea entităţii de partea „unu” a
legăturii este obligatorie (cardinalitatea minimă este 1). Transformarea este asemănătoare cu
cea din exemplul anterior, singura diferenţă constând în faptul că nu se admit valori nule
pentru cheia străină. Observaţi, de asemenea, că participarea facultativă a entităţii aflate de
partea „multe” nu are efecte asupra transformării. Cele două relaţii rezultate sunt:
FURNIZOR (FURN_ID, FURN_NUME)
FACTURA(FACT_NR, FACT_DATA, FACT_ID)
O legătură binară de tip 1:1, dintre două entităţi A şi B, poate fi reprezentată în una din
următoarele modalităţi:
1. Adăugarea cheii-primare a entităţii A la entitatea B sub formă de cheie-străină.
2. Adăugarea cheii-primare a entităţii B la entitatea A, sub formă de cheie-străină.
3. Ambele cazuri (1 şi 2), dacă cerinţele de acces la date o cer.
4. Unirea celor două entităţi într-o singură tabelă, care va conţine atributele ambelor entităţi şi
a cărei cheie principală va fi aleasă dintre cheile celor două entităţi.
Furnizor
Furn_id
Furnizor
Furn_nume O factură este emisă obligatoriu Furn_id
(1,1) de un furnizor, în timp ce un Furn_nume
furnizor ne poate emite mai
multe facturi sau nici una.
Emite
Factura
Fact_nr
(0,M) Fact_data
Furn_id [FK] NOT NULL
Factura
Fact_nr
Fact_data
Fig. 3.4 Transformarea relaţiilor 1:N în care

participarea entităţii din partea unu este obligatorie
Dacă participarea unei entităţi într-o legătură 1:1 este opţională, atunci ea va reprezenta
tabela părinte, iar cheia sa principală va fi adăugată în tabela corespunzătoare celeilalte entităţi,
jucând rolul de cheie străină. În figura 3.5, participarea entităţii ANGAJAT în relaţia "conduce"
cu entitatea DEPARTAMENT este opţională (cardinalitatea minimă este 0), deci tabela
corespunzătoare ei va fi tabela-părinte, iar cheia sa, Ang_id va fi cheie străină în tabela
corespunzătoare entităţii DEPARTAMENT. Altfel formulată această regulă, cheia primară a
entităţii aflate în partea cu cardinalitatea minimă 1 va fi inclusă în tabela aferentă celeilalte
entităţi şi va reprezenta cheia străină. De asemenea, observaţi că pentru cheia străină nu se
admite valoarea nulă. Relaţiile rezultate sunt :
ANGAJAT (Ang_id, Ang_nume, Ang_saltf)
DEPARTAM ENT(Dep_id, Dep_nume, Ang_id)
Departament Fiecare departament trebuie să aibă

Dep_id un manager, iar un angajat poate fi
Dep_nume managerul unui singur departament Departament
dar nu este obligatoriu ca fiecare Dep_id
(0,1) angajat să conducă un depa rtament Dep_nume
Ang_id [FK] NOT
NULL
Conduce
(1,1) Angajat
Ang_id
Angajat Ang_nume
Ang_id Ang_saltf
Ang_nume
Ang_saltf
Fig. 3.5 Transformarea relaţiilor 1:1 în care

participarea uneia dintre entităţi este facultativă
3.3.2.2 Reprezentarea legăturile binare de tip M:N şi a celor ternare

Legăturile binare de tipul M:N şi legăturile ternare, indiferent de tipul cardinalităţii,
primesc acelaşi „tratament” la transformarea lor: pe lângă tabelele din prima categorie (vezi
începutul paragrafului 3.3), create pentru fiecare entitate implicată în legătura respectivă, se
mai introduce o tabelă, corespunzătoare legăturii dintre entităţi, numită şi asociativă, care va
avea drept atribute cheile primare ale entităţilor asociate (şi care vor juca rolul de chei străine)
şi eventualele proprietăţi ale legăturii.
Regulile de definire a cheii primare diferă, în funcţie de ordinul şi cardinalitatea legăturii.
Vom exemplifica şi vom discuta în continuare câteva situaţii.
În figura 3.6 este prezentată legătura binară "Conţine", dintre entităţile PRODUS şi
FACTURA, cu cardinalitatea M:N. În urma transformării rezultă tabelele PRODUS şi
FACTURA, corespunzătoare celor două entităţi, şi LINIE_FACTURA, derivată din legătura
dintre cele două entităţi. Cea din urmă va conţine cheile primare ale celor două entităţi
asociate, precum şi atributele Cantitate şi Pret, care erau iniţial proprietăţi ale legăturii
"Conţine". De regulă, cheia acestei tabele se formează prin combinarea cheilor celor două
entităţi.
Fiecare factură conţine unul sau mai Produs

Produs
multe produse, iar un produs se Prod_id
Prod_id
poate regăsi pe mai multe facturi Prod_den
Prod_den
sau niciuna.
(1,M)
Articol_factura
Cantitate Prod_id [FK]
Conţine Fact_nr [FK]
Cantitate
Pret
Pret
(0,M)
Factura Factura
Fact_nr Fact_nr
Fact_data Fact_data
Fig. 3.6 Transformarea relaţiilor M:N

Cele trei tabele rezultate sunt:

PRODUS (PROD_ID, PROD_DEN)
FACTURA(FACT_NR, FACT_DATA)
LINIE_FACTURA(FACT_NR, PROD_ID, CANTITATE, PRET)
În figura 3.6 nu s-a mai specificat restricţia „NOT NULL” pentru cele două chei străine
din tabela ARTICOL_FACTURA, fiind inutilă de vreme ce ambele chei străine fac parte din
cheia primară.
Pot exista situaţii când relaţia constituită pe baza legăturii M:N dintre două entităţi nu este
suficient definită printr-o cheie-primară care conţine doar cheile-primare ale entităţilor aflate în
legătură, fiind necesară utilizarea suplimentară a unuia sau mai multor atribute.
Să pornim de la exemplul prezentat în figura 3.7.
Data Nota
Student Profesor
Examinare
Nr_matricol Cod_profesor
(0,M) (0,M
Nume_student Nume_prof
Fig. 3.7 Exemplu de relaţie definită prin chei primare şi atribute proprii
Pentru diagrama de mai sus, atributul DATA trebuie să fie o parte a cheii relaţiei
EXAMINARE, astfel:
EXAMINARE (NR_MATRICOL, COD_PROFESOR, DATA, NOTA)
Dacă fiecare examinare ar avea un cod propriu de identificare, data ar fi de prisos, iar
NR_MATRICOL şi COD_PROFESOR ar deveni chei-referinţă-încrucişată, după cum urmează:
EXAMINARE (COD_EXAMINARE, NR_MATRICOL, COD_PROFESOR, DATA, NOTA)
Transformarea legăturilor ternare este asemănătoare cu cea aplicată legăturilor binare de

tip M:N. Deosebiri se înregistrează doar la definirea cheii primare a tabelei asociate legăturii.
În acest sens, se aplică următoarele reguli:
1. Dacă toate entităţile prezintă cardinalitatea maximă „unu”, atunci există trei posibilităţi
de formare a cheii primare (trei chei candidat), rezultate prin combinarea oricăror două
dintre cele trei chei ale entităţilor originale;
2. Dacă două dintre entităţi prezintă cardinalitatea maximă „unu”, atunci vor exista două
posibilităţi de formare a cheii: prin combinarea cheii primare a entităţii din partea
„multe” cu una dintre cheile entităţilor situate de partea „unu”;
3. Dacă o singură entitate prezintă cardinalitatea maximă „unu”, atunci cheia va fi
formată prin combinarea cheilor principale ale celor două entităţi situate de partea
„multe” a relaţiei;Dacă toate cele trei entităţi prezintă cardinalitatea maximă „multe”,
atunci cheia primară va fi formată prin combinarea cheilor tuturor celor trei entităţi
asociate.În figura 3.8 este prezentat un exemplu de transformare a unei legături ternare
cu cardinalitatea 1:M:N. Tabela EXAMEN, corespunzătoare legăturii dintre cele trei entităţi, va
avea ca atribute cheile primare ale celor trei entităţi, STUD_ID, PROF_ID şi DISC_ID, care vor
juca rolul de chei străine, precum şi atributele asociate legăturii, EXAM_DATA şi
EXAM_NOTA. Conform regulilor prezentate anterior (regula nr. 3), cheia primară a acestei
tabele ar trebui să fie formată din atributele STUD_ID şi DISC_ID. Însă, această combinaţie nu
este suficientă pentru a juca rolul de cheie primară, deoarece un student poate susţine acelaşi
examen de mai multe ori, situaţie în care vor exista mai multe linii (tupluri) în relaţia EXAMEN
care vor prezenta aceleaşi valori pentru cele două atribute. Din acest motiv, în compoziţia cheii
a fost inclus şi atributul EXAM_DATA.
Profesor
Prof_id
Prof_nume
1
Disciplina Examinare Student

M N
Disc_id Stud_id
Disc_den Stud_nume
Fiecare student susţine un anumit examen cu un singur profesor; un student

poate fi examinat de acelaşi profesor la mai multe discipline; un profesor
examinează la o anumită disciplină mai mulţi studenţi.
Profesor
Prof_id
Prof_nume
Disciplina Examen Student

Disc_id Stud_id [FK] Stud_id
Disc_den Disc_id [FK] Stud_nume
Exam_data
Prof_id [FK]
Exam_nota
Fig. 3.8 Transformarea legăturilor ternare de tipul 1:M:N
Relaţiile rezultate din transformarea legăturii "Examinare" sunt:

PROFESOR (PROF_ID, PROF_NUME)
STUDENT(MATRICOL, STUD_NUME)
DISCIPLINA(DISC_ID, DISC_DEN)
EXAMEN(MATRICOL, DISC_ID, EXAM_DATA, PROF_ID, NOTA)
3.3.2.3 Reprezentarea legăturilor unare

O legătură unară reprezintă o legătură între instanţele unei singure entităţi, numită şi
legătură sau asociere recursivă. În literatură sunt cele mai citate exemplele prin care entitatea
ANGAJAT are o legătură recursivă cu ea însăşi (un ANGAJAT „conduce” zero, unul sau mai
mulţi ANGAJAT(i)) sau structura unei reţete de fabricaţie în care ARTICOL „conţine” zero, unul
sau mai multe ARTICOL(e). Cele două exemple sunt prezentate în figurile 3.9 şi 3.10. În primul
exemplu avem o legătură recursivă de tipul 1:N, iar în cel de-al doilea o legătură de tipul M:N.
Pentru o legătură unară de tip 1:N, în care intră cazul entităţii ANGAJAT, diagrama este
prezentată în fig. 3.9.
ANGAJAT Un angajat poate conduce mai ANGAJAT
Marca_angajat mulţi angajaţi sau nici unul, Marca_angajat
(0,M) iar fiecare angajat are un
Nume Nume
Alte_date manager şi numai unul Alte_date
Marca_manager [FK]
(1,1)
Conduce
Fig. 3.9 Diagrama legăturilor unare de tip 1:N şi transformarea lor

Pentru legătura unară de tip M:N, în care intră entitatea ARTICOL, diagrama este redată în
figura 3.10.
ARTICOL
ARTICOL
Un articol poate conţine mai Cod_articol
Cod_articol
multe articole, iar un articol Denumire
(0,M ) poate intra în fabricaţia mai
Denumire Cost
Cost multor alte articole.
(0,M )
Contine
ARTICOL_COMPONENT
Cod_articol
Cod_componenta [FK]
Cantitate Cantitate
Fig. 3.10 Diagrama legăturilor unare de tip M:N
Pentru legătura unară 1:N, entitatea este modelată ca o relaţie, în care cheia primară este
cheia primară a entităţii. Relaţiei i se adaugă o cheie străină prin care se va face referire la
valoarea cheii-primare din aceeaşi relaţie.
O cheie-străină recursivă este o cheie-străină dintr-o relaţie care face referire la valorile
cheii-primare din aceeaşi relaţie. Reprezentarea legăturii unare 1:N din exemplul dat este:
ANGAJAT (MARCA_ANGAJAT, NUME, ALTE_DATE, MARCA_MANAGER)
în relaţia de mai sus, MARCA_MANAGER este o cheie-străină recursivă care îşi ia
valoarea din acelaşi domeniu cu MARCA_ANGAJAT.
Pentru legătura unară M:N, entitatea ARTICOL se va modela ca o relaţie, după care se va
crea o altă relaţie pentru scoaterea în relief a legăturii M:N. Cheia primară a acestei noi relaţii
este una compusă care va prelua cele două atribute, dar care nu trebuie să aibă acelaşi nume, în
schimb vor lua valori din acelaşi domeniu al cheii-primare. Orice alt atribut ce trebuie adăugat
noii legături (cum este CANTITATE) este inclus ca un atribut non-cheie.
Rezultatul poate fi prezentat astfel:
ARTICOL (COD_ARTICOL, DENUMIRE, COST)
ARTICOL_COMPONENT (COD_ARTICOL, COD_COMPONENTA, CANTITATE)
3.3.2.4 Legătura IS-A (Este un/o) (Clasă – Subclasă)

Modelul relaţional nu are o reţetă directă pentru legăturile clasă – subclasă (sau IS-A). În
schimb, sunt prezentate următoarele reguli:
1. Crearea unei relaţii distincte pentru clasă şi pentru fiecare subclasă.
2. Tabelul (relaţia) clasei este alcătuit doar din cheia primară şi atributele comune tuturor
subclaselor.
3. Tabelul fiecărei subclase conţine numai cheia-primară proprie şi coloanele unice acelei
subclase.
4. Cheile primare ale clasei şi ale fiecăreia dintre subclase sunt din acelaşi domeniu, dar
pot să nu aibă aceleaşi nume.
*
* *
Prin tot ceea ce s-a tratat în paragraful de faţă, s-a demonstrat modul în care se pot
transforma diagramele entitate-relaţie în relaţii. În tabelul 3.2 sunt descrise regulile de
transformare a DER în relaţii.
În Caseta 3.1 se pleacă de la exemplul sistemului de gestiune a clienţilor şi se reia
procesul de proiectare a bazei de date de la modelul conceptual al datelor (diagrama entitate-
relaţie), construit în timpul analizei sistemului. În casetă se regăseşte modul de aplicare a unora
dintre regulile descrise anterior.
Transformarea diagramei entitate-relaţie (DER) începe cu reprezentarea entităţilor.
Comparând figurile C3.1 şi C3.2, se poate constata că pentru fiecare entitate de date a fost
creată câte o tabelă în baza de date. Astfel, în fig. C3.2 se regăsesc tabelele CLIENT,
COMANDA, LIVRARE, RETURNARE, DEPOZIT şi PRODUS. Cele şase tabele au preluat cheile
primare şi atributele non-cheie ale entităţilor corespondente.
Tabel nr. 3.2 – Transformarea relaţională a structurilor entitate-relaţie
Structura
Reprezentarea relaţională
entitate-relaţie
Entităţi normale Se creează o relaţie care are o cheie primară şi atribute non-cheie.
Entitate slabă Crearea unei relaţii cu o cheie primară compusă (în care este inclusă cheia
primară a fiecărei entităţi de care depinde această entitate) şi cu atributele non-
cheie.
Legătura binară Plasarea cheii-primare a oricărei entităţi în relaţia creată din cealaltă entitate
sau unară 1:1 sau efectuarea acestui lucru pentru ambele entităţi.
Legătura binară Se plasează cheia-primară a entităţii aflate lângă partea „unu” a legăturii ca o
1:M componentă specială (cheie străină) a relaţiei care se află lângă partea „multe”
a legăturii.
Legăturile sau Crearea unei relaţii cu o cheie-primară compusă, folosind cheile primare ale
gerundivele binare entităţilor înrudite, plus orice atribute non-cheie ale legăturii sau gerundivei.
sau unare M:N
Legăturile sau Crearea unei relaţii cu o cheie primară compusă, folosind cheile primare ale
gerundivele binare entităţilor înrudite şi atribute suplimentare folosite drept cheie primară asociate
sau unare M:N cu legăturii sau gerundivei, plus orice alte atribute non-cheie ale legăturii sau
chei suplimentare gerundivei.
Legăturile sau Creare unei relaţii cu cheia primară asociată legăturii sau gerundivei, plus orice
gerundivele binare alte atribute non-cheie ale legăturii sau gerundivei, iar cheile primare ale
sau unare M:N cu entităţilor înrudite sunt folosite tot ca atribute non-cheie.
chei proprii
Legătura IS-A Crearea unei relaţii pentru clasa superioară care să conţină propria cheie
(clasă – subclasă) primară şi atributele comune tuturor subclaselor, plus crearea a câte unei relaţii
separate pentru fiecare subclasă cu aceeaşi cheie primară (cu nume identic sau
propriu) dar care să conţină numai atributele specifice subclasei respective.
În continuare, se trece la analiza legăturilor dintre entităţi, urmărindu-se ordinul şi
cardinalitatea acestora. Din punctul de vedere al ordinului, toate legăturile din DER sunt
binare, iar din cel al cardinalităţii maxime avem trei tipuri: 1:1, 1:N şi M:N.
Caseta nr. 3.1 – Proiectarea bazei de date plecând de la modelul conceptual

Comanda
Returnare
CodComanda
Livrare NrFactura
NrComanda (1,M) (0,1) NrFactura (1,1) (0,1) DataFactura
DataComanda Onorare Corespunde
DataFactura NrNotaRefuz
TermenLivrare
DataRefuz
StareComanda (0,M) (0,M) Motivatie
(0,M) (0,M)
Cantitate
Emite returnata
Emite Conţine
Stoc
(1,1) curent
(1,1) Depozit (1,M)
Client CodDepozit (1,M)
Produs
NumeDepozit Este în
CodClient CodProdus
NumeClient stoc DenProdus
(0,M)
Adresa UM
CodFiscal Conţine PretUnitar
Sold (1,M)
LimitaCredit
TipClient
Cantitate
comandata
Fig. C3.1 Modelul conceptual al datelor pentru sistemul de gestiune a clienţilor

Rezultatul transformării modelului conceptual este prezentat în figura c3.2.

Client
CodClient Livrare
NumeClient NrFactura
Adresa DataFactura
CodFiscal CodDepozit[FK] Not null
Sold
LimitaCredit
TipClient Returnare
NrFactura
Depozit DataFactura
CodDepozit NrNotaRefuz
NumeDepozit DataRefuz
Comanda Motivatie
CodComanda NrFacturaL[FK] Not null
NrComanda
DataComanda
TermenLivrare Stocuri
StareComanda CodDepozit [FK]
CodClient[FK] Not null CodProdus [FK]
NrFactura[FK] Null StocCurent
ProduseReturnate
NrFactura [FK]
CodProdus [FK]
CantitateReturnata
Produs
ProduseComandate
CodProdus
CodComanda [FK]
DenProdus
CodProdus [FK]
UM
CantitateComandata
PretUnitar
Fig. C3.2 Schema logică a bazei de date pentru sistemul de gestiune a clienţilor
Singura legătură de tipul 1:1 este Corespunde, dintre LIVRARE şi RETURNARE. Întrucât
participarea entităţii LIVRARE în acestă legătură este facultativă (cardinalitatea minimă este 0),
tabela corespondentă va fi părinte, iar cheia primară a acesteia, NrFactura, va fi inclusă în
tabela RETURNARE şi va juca rolul de cheie străină. Deoarece în tabela RETURNARE exista
deja un atribut cu acelaşi nume, atributul inclus se numeşte NrFacturaL.
Legăturile de tip 1:N sunt trei: emite, dintre CLIENT şi COMANDA; onorare, dintre
COMANDA şi LIVRARE; emite, dintre LIVRARE şi DEPOZIT. În cazul tuturor celor trei
legături, entitatea aflată de partea „multe” a preluat cheia primară a entităţii aflată de partea
„unu”. Astfel, tabela COMANDA are două chei străine, CodClient şi NrFactura, prin intermediul
cărora se stabilesc legăturile cu tabelele CLIENT, respectiv LIVRARE, iar tabela LIVRARE
conţine o cheie străină, CodDepozit, care asigură legătura cu tabela DEPOZIT. O particularitate
apare în cazul legăturii Onorare, deoarece participarea entităţii părinte, LIVRARE, este
facultativă. Prin urmare, se vor admite valori nule pentru atributul NrFactura din tabela
COMANDA, care este cheia străină rezultată din transformarea acestei legături. Pentru celelalte
chei străine nu se admite valoarea nulă, fapt specificat în fig. C3.1 prin adăugarea „Not null” în
dreptul lor.
Legăturile Conţine, dintre COMANDA şi PRODUS, Este în stoc, dintre DEPOZIT şi
PRODUS, şi Conţine, dintre RETURNARE şi PRODUS, sunt de tipul M:N. Pentru toate cele trei
legături s-a creat câte o tabelă nouă, rezultând tabelele PRODUSECOMANDATE, STOCURI şi
PRODUSERETURNATE. Fiecare tabelă conţine cheile primare ale entităţilor legate, ele jucând
rolul de cheie străină, precum şi atributele descriptive ale legăturii corespondente. Cheia
primară este formată, pentru toate cele trei tabele, din combinaţia cheilor străine.
În final să remarcăm că fiecare cheie străină apare ca urmare a unei legături dintre tabele,
iar fiecărei legături îi corespunde o cheie străină.
În practică, transformarea DER poate să nu fie chiar atât de simplă, uneori fiind necesară
modificarea bazei de date obţinute de către echipa de proiectare, pe baza experienţei şi a
regulilor euristice de care dispune.
Rezumat
Modelarea logică a datelor reprezintă o activitate deosebit de importantă, dacă avem în vedere că
baza de date reprezintă nucleul oricărui sistem informaţional economic. Spre deosebire de modelul
conceptual al datelor, modelarea logică ia în considerare tehnologiile de organizare şi prelucrare a
datelor, precum şi criteriile de calitate specifice, precum completitudine, neredundanţă, reutilizare,
flexibilitate.
Obiectivul principal al acestei activităţi îl reprezintă elaborarea schemei logice a bazei de date, cu
care vor interacţiona proiectanţii şi programatorii în conceperea şi implementarea programelor. În
prezent, cel mai utilizat mod de organizare a datelor este modelul relaţional, motiv pentru care conceptele
şi regulile acestuia au fost avute în vedere la modelarea logică a datelor. Astfel, dacă, la modelarea
conceptuală a datelor, cerinţele funcţionale se regăseau sub forma unui ansamblu de entităţi de date şi
legături între entităţi, modelul logic al datelor este format din relaţii şi legături între relaţii.
Proiectarea logică a bazei de date implică transformarea modelului conceptual al datelor, transpus
sub forma unei diagrame entitate-relaţie, prin aplicarea unor reguli ce iau în considerare entităţile de date,
cardinalitatea şi ordinul legăturilor dintre entităţi. Această manieră de proiectare mai este referită şi ca
strategia top-down. O altă strategie, numită bottom-up, presupune aplicarea procedurii de normalizare,
pornind de la relaţia generală iniţială, în care se cuprind toate datele elementare care corespund punctului
de vedere al unui utilizator sau categorii de utilizatori asupra bazei de date şi care trebuie stocate.
Fiecare din cele două strategii prezintă avantaje şi dezavantaje: strategia top-down este considerată
mai simplă, deoarece utilizează conceptul de abstractizare, ceea ce permite reducerea numărului de
obiecte şi legături ce trebuie analizate; strategia bottom-up este mai analitică, deoarece ea porneşte de la
datele elementare, regăsite în documente primare, rapoarte şi ecrane, ceea ce permite reducerea riscului
de a scăpa din vedere unele dintre ele.
Obţinerea unei scheme logice de calitate poate solicita punerea în practică a unui demers mai
riguros de proiectare logică a bazei de date, care să îmbine cele două strategii: se vor aplica, pe rând,
ambele strategii de proiectare, iar la sfârşit se vor compara şi integra rezultatele obţinute.
1. Explicaţi deosebirea dintre modelul conceptual şi modelul logic al datelor.
2. Descrieţi criteriile de calitate ale modelului logic al datelor.
3. Realizaţi o comparaţie între cele două strategii de proiectare logică a bazei de date (bottom-up şi top-
down).
4. Prezentaţi, într-o formă sintetică şi structurată, regulile de transformare a DER într-un set de relaţii.
5. În ce situaţii o legătură dintre două entităţi poate avea propriile atribute?
6. Explicaţi următoarele noţiuni, în legătură cu transformarea DER într-un set de relaţii: entitate slabă,
entitate atributivă, entitate asociativă, cheie străină recursivă. Daţi exemple prin care să puneţi în
evidenţă fiecare din noţiunile enumerate anterior.
Probleme
1. Daţi un exemplu prin care să puneţi în evidenţă transformarea unei legături binare M:N.
2. Daţi un exemplu prin care să puneţi în evidenţă transformarea unei legături ternare, indiferent de
cardinalitatea acesteia.
CAPITOLUL IV
Proiectarea fizică a fişierelor

şi a bazelor de date
Obiective
• Înţelegerea scopului şi obiectivelor urmărite la proiectarea fizică a bazelor de date
• Descrierea mecanismului tranzacţional al bazei de date
• Identificarea şi analiza informaţiilor necesare în proiectarea fizică a fişierelor şi bazelor de date
În etapele anterioare au fost tratate aspectele referitoare la proiectarea conceptuală şi

proiectarea logică a datelor, prin folosirea modelelor conceptuale, respectiv logice ale datelor.
Modelul conceptual surprinde structura globală de organizare a datelor, asigurându-se
independenţa totală faţă de orice tip de sistem de gestiune a bazelor de date sau de alte
considerente specifice implementării. Modelul conceptual este prezentat prin intermediul
diagramelor entitate-relaţie (DER) , motiv pentru care este cunoscut şi sub numele de modelul
entitate-relaţie al datelor. El scoate în evidenţă entităţile de date, asocierile (legăturile) dintre
entităţi şi datele elementare ale unei organizaţii sau ale unei părţi din ea. Modelul se realizează
în faza de analiză.
Modelul logic al datelor înseamnă descrierea datelor în concordanţă cu modul de
organizare a acestora de către un anumit tip de sisteme de gestiune a bazelor de date (SGBD).
În materialul de faţă s-a insistat asupra modelului relaţional, el fiind cel mai folosit în prezent.
Conform acestuia, datele sunt reprezentate sub forma tabelelor (relaţiilor) şi a legăturilor dintre
acestea, create pe baza diagramei entitate-relaţie obţinută în etapa anterioară, după anumite
proceduri, relevantă fiind normalizarea. Alte concepte utilizate în modelarea logică a datelor
erau: atribut (coloană), tuplu (linie), cheie primară, cheie străină, restricţii de integritate
referenţială.
Dacă etapele anterioare ale ciclului de viaţă al sistemelor se concentrează asupra
„efectuării lucrurilor care trebuie”, proiectarea fizică va fi orientată spre „efectuarea cum
trebuie a lucrurilor care trebuie”. Proiectarea fizică a bazelor de date are drept scop
transformarea schemei logice a bazei de date (tabele, atribute, legături între tabele, restricţii de
comportament al datelor) într-un set de specificaţii tehnice privind stocarea şi accesarea
datelor, care să poată fi implementate în SGBD-ul ales şi care să asigure confidenţialitataea,
integritatea, controlabilitatea şi performanţele dorite în accesarea datelor. Rezultatele acestei
etape vor fi utilizate de programatori şi alte categorii de specialişti în faza de implementare,
atunci când vor fi create şi încărcate obiectele bazei de date (tabele, indecşi, view-uri etc).
Activităţile proiectării fizice a bazei de date pot fi derulate numai după alegerea SGBD-
ului. Fiecare SGBD oferă opţiuni diferite în ce priveşte tipurile de date, organizarea fişierelor,
metodele de accesare a datelor, înlănţuirea înregistrărilor fizice etc, iar membrii echipei trebuie
să le aleagă pe cele mai potrivite cerinţelor sistemului. În acest sens, ei trebuie să cunoască
foarte bine funcţionalitatea şi facilităţile oferite de SGBD-ul respectiv. În acest capitol nu ne
vom concentra asupra particularităţilor unui anumit SGBD, ci vom prezenta cele mai
importante instrumente, tehnici, concepte şi reguli generale utilizate în proiectarea fizică.
PROIECTAREA FIZICĂ A FIŞIERELOR ŞI A BAZELOR DE DATE 93
4.1 Aspecte generale ale proiectării fizice a fişierelor

şi a bazelor de date
Proiectarea fizică a fişierelor şi bazelor de date are trei obiective principale:

• transpunerea schemei logice a datelor într-un model care să poată fi implementat în
SGBD-ul ales. Se va avea în vedere alegerea tipului de date pentru fiecare atribut,
definirea cheilor primare şi străine, declarearea restricţiilor etc;
• determinarea unei structuri optime de stocare a datelor care să asigure performanţe
acceptabile în ce priveşte accesarea datelor şi spaţiul utilizat. Pentru atingerea acestui
obiectiv, proiectanţii au la dispoziţie mai multe opţiuni de organizare a fişierelor,
utilizare a indecşilor şi modificare a schemei logice;
• definirea măsurilor de securitate care vor fi implementate, în funcţie de facilităţile
oferite de SGBD-ul ales.
Informaţiile necesare pentru proiectarea fizică a fişierelor şi bazelor de date se referă la:
• schema logică (relaţională) a datelor, sub forma unui set de relaţii normalizate, inclusiv
estimarea dimensiunii pentru fiecare relaţie din baza de date;
• descrierea atributelor şi a restricţiilor de integritate;
• specificarea momentului, a frecvenţei şi a locului utilizării datelor, sub forma
interogărilor sau tranzacţiilor (adăugarea, modificarea sau ştergerea datelor);
• timpul preconizat pentru obţinerea răspunsurilor la solicitările utilizatorilor.
O importanţă deosebită în această etapă de lucru prezintă informaţiile privind operaţiunile
de accesare a datelor, motiv pentru care în paragraful următor ne vom ocupa de analiza
acestora.
Pe baza informaţiilor amintite, analistul va lua câteva decizii-cheie, cu reflectare directă în
integritatea datelor şi performanţele aplicaţiilor. Ele privesc:
1. Selectarea formatului de stocare (tipul datei) pentru fiecare atribut al modelului logic
al datelor. Rolul formatului este de minimizare a spaţiului de stocare şi maximizare a
integrităţii datelor.
2. Gruparea atributelor din modelul logic al datelor în înregistrări fizice, numită şi
structura înregistrărilor/datelor stocate.
3. Alegerea tipului de organizare a fişierelor şi definirea structurilor de acces necesare,
astfel încât să se asigure un acces cât mai eficient.
4. Definirea soluţiilor privind protecţia datelor şi a reconstituirii lor după anumite
incidente.
Rezultatele proiectării fizice a fişierelor şi bazelor de date se concretizează într-un set de
specificaţii ce vor fi utilizate de programatorii sau analiştii bazelor de date pentru definirea
formatului şi structurii datelor stocate în memoria secundară, de regulă, discuri fixe. Pentru
cele mai multe sisteme moderne, specificaţiile vor conţine toate informaţiile necesare scrierii
sau generării enunţurilor de definire a datelor în SQL (un limbaj standard pentru baze de date
relaţionale).
4.2 Analiza operaţiunilor de accesare a datelor
Din punct de vedere fizic, există două tipuri de operaţiuni de accesare a datelor: scrierea
şi citirea. Din punct de vedere logic, adică din perspectiva utilizatorilor, operaţiunea fizică de
citire apare sub forma interogărilor bazei de date, exprimate cel mai adesea sub forma frazelor
SQL SELECT. Operaţiunea fizică de scriere are în corespondenţă trei operaţiuni logice:
adăugarea, modificarea şi ştergerea liniilor (înregistrărilor) în tabele. Operaţiunile de
actualizare mai sunt referite şi ca tranzacţii ale bazei de date, ele trebuind tratate cu foarte
multă atenţie, deoarece au impact direct asupra integrităţii datelor din bază. Vom reveni asupra
acestei probleme în paragraful următor.
Unul dintre obiectivele principale ale proiectării fizice a bazelor de date priveşte
îmbunătăţirea performanţelor operaţiilor de acces la date. Aceste performanţe sunt apreciate
prin intermediul unor indicatori, cei mai frecvent utilizaţi fiind numărul operaţiilor executate
într-o unitate de timp şi timpul de răspuns pentru realizarea unei singure operaţii de acces.
Obţinerea performanţelor dorite nu este o sarcină tocmai uşoară. Dificultatea ei este
sporită de faptul că, din punctul de vedere al performanţelor, operaţiile de citire şi scriere se
află în tabere opuse. În general, obţinerea de performanţe la interogarea datelor va însemna
contra-performanţe în cazul operaţiilor de actualizare. De exemplu, introducerea indecşilor va
determina creşterea performanţelor la citire şi, în acelaşi timp, diminuarea lor pentru operaţiile
de scriere.
În continuare, ne vom opri, mai întâi, asupra problematicii gestiunii tranzacţiilor, după
care vom identifica principalele categorii de informaţii utile în luarea deciziilor de proiectare
fizică.
4.2.1 Mecanismul tranzacţional al bazei de date
Pentru descrierea operaţiilor de actualizare a bazei de date se foloseşte noţiunea de
tranzacţie. Prin tranzacţie se înţelege un ansamblu de operaţiuni executate împreună asupra
bazei de date în vederea realizării unei activităţi, ea fiind tratată ca o unitate logică de
prelucrare care garantează consistenţa bazei de date. O tranzacţie poate fi încheiată în două
moduri: validarea ei, când toate operaţiunile au putut fi executate, sau anularea ei, dacă cel
puţin una dintre operaţiunile care o compun nu poate fi executată, caz în care toate operaţiunile
vor fi anulate.
Regulile şi procedurile de tratare a tranzacţiilor bazei de date formează mecanismul
tranzacţional. Rolul său este de a garanta menţinerea bazei de date în stare de consistenţă
atunci când o tranzacţie este executată în mod concurent cu altele sau că au apărut
disfuncţionalităţi în timpul execuţiei ei. Prin urmare, mecanismul tranzacţional trebuie să
rezolve următoarele două probleme:
1 Controlul concurenţei, adică sincronizarea acceselor astfel încât să fie menţinută
integritatea bazei de date. De regulă, această problemă este rezolvată prin intermediul
mecanismelor de blocare.
2 Rezistenţa la defecte se referă la asigurarea toleranţei sistemului faţă de apariţia unor
defecte şi a capacităţii acestuia de recuperare, adică revenirea la o stare consistentă în
urma apariţiei unui defect care a determinat rămânerea bazei de date într-o stare de
inconsistenţă.
O bază de date este într-o stare consistentă dacă datele respectă toate restricţiile de
integritate definite asupra lor: restricţii privind cheia, restricţii de integritate referenţială,
restricţii specifice afacerii.
Iată două exemple de tranzacţii pentru baza de date VANZARI. O tranzacţie simplă este
adăugarea unui nou client: ea implică inserarea unei linii în tabela CLIENT. O tranzacţie mai
complexă este adăugarea unei vânzări, formată din următoarele operaţii, a cărei descriere este
prezentată şi în tabelul 4.1:
• inserarea unei linii în tabela FACTURA;
• inserarea a câte o linie în tabela ARTICOLFACTURA, pentru fiecare produs vândut;
• actualizarea, în tabela CLIENT, a atributului Sold pentru clientul către care se face
vânzarea;
• actualizarea, în tabela PRODUS, a atributului Stoc pentru liniile corespunzătoare
produselor vândute.
Tabel nr. 4.1 – Model de descriere a unei tranzacţii în baza de date

Denumire Nume tabelă Tip Explicaţii
operaţiune accesată acces
Validare CLIENT Read Se citesc datele de identificare a clienţilor,
client respectiv codul şi numele lor, pentru a se verifica
existenţa în baza de date a clientului pentru care
se introduce factura.
Adăugare FACTURA Insert DataFactura ia valoarea datei din sistem, iar
factură celelalte valori sunt preluate din ecranul de
culegere a datelor.
Validare PRODUS Read Se citesc datele de identificare a produselor,
produs respectiv codul şi denumirea lor, pentru a se
verifica existenţa în baza de date a produselor
facturate.
Adăugare ARTICOLFACTURA Insert Toate datele se preiau din ecranul pentru
articole culegerea datelor.
factură
Actualizare CLIENT Update Se incrementează valoarea atributului Sold, cu
sold client valoarea facturii, preluată din ecranul de culegere
a datelor. Identificarea înregistrării se face în
funcţie de codul clientului pentru care s-a introdus
factura.
Actualizare PRODUS Update Se decrementează valoarea atributului Stoc cu
stocuri cantitatea vândută, pentru fiecare produs în parte.
Identificarea înregistrărilor actualizate se face pe
baza codului produsului.
Pe timpul execuţiei unei tranzacţii, baza de date poate fi într-o stare inconsistentă, însă ea
trebuie să fie într-o stare consistentă atât înainte, cât şi după execuţia tranzacţiei.
Pentru ca orice tranzacţie să garanteze consistenţa unei baze de date, ea trebuie să
satisfacă patru condiţii, referite în literatura de specialitate prin acronimul ACID:
• Atomicitatea consideră că o tranzacţie este unitatea elementară de prelucrare, adică
execuţia ei se face pe principiul totul sau nimic. O tranzacţie este validată numai dacă
toate operaţiunile care o compun au fost executate, altfel datele trebuie restaurate în
starea în care se aflau înainte de începerea tranzacţiei, deci ea este anulată (tranzacţia
nu poate fi parţial executată).
• Consistenţa se referă la corectitudinea tranzacţiei din punctul de vedere al respectării
restricţiilor de integritate definite asupra datelor. Trecerea de la o stare la alta a datelor
în urma unei tranzacţii nu trebuie să afecteze integritatea datelor din bază.
• Izolarea presupune ca orice tranzacţie să aibă acces doar la stările consistente ale bazei
de date. Altfel spus, efectele unei tranzacţii nu sunt percepute de o altă tranzacţie decât
după ce prima trazacţie a fost validată. De regulă, toate datele solicitate de o tranzacţie
sunt blocate până în momentul finalizării ei, astfel încât o altă tranzacţie să nu le poată
modifica.
• Durabilitatea se referă la faptul că, odată ce tranzacţia este validată, efectele sale devin
permanente şi vor fi înscrise în baza de date, chiar dacă, după momentul validării, apare
o defecţiune care împiedică scrierea rezultatelor tranzacţiei în baza de date.
Dintre cele patru proprietăţi, analistul va trebui să ia în considerare doar una: consistenţa.
El va avea responsabilitatea proiectării unor tranzacţii consistente. De exemplu, în cazul
tranzacţiei de adăugare a unei vânzări, dacă se omite actualizarea soldului clientului respectiv,
atunci tranzacţia nu este consistentă, deoarece nu este corectă înregistrarea unei facturi fără
înregistrarea creanţei faţă de clientul respectiv. De asemenea, dacă prin adăugarea unei vânzări
se ajunge în situaţia ca stocul pentru un produs să devină negativ, în urma operaţiei de
actualizare a sa, din nou tranzacţia nu îndeplineşte condiţia de consistenţă, atât timp cât este
afectată integritatea datelor din bază.
Rezolvarea celorlalte trei proprietăţi cade în sarcina SGBD-urilor. Atomicitatea este
rezolvată prin mecanismele de blocare şi cele de înseriere, iar durabilitatea, prin facilităţile de
jurnalizare a tranzacţiilor. În cazul sistemelor distribuite, apare problema asigurării atomicităţii
globale a tranzacţiilor distribuite, scop în care unele SGBD-uri au implementat mecanismul de
validare în două faze (two phase commit).
4.2.2 Analiza informaţiilor privind operaţiile de acces la date
O bună proiectare fizică a bazei de date impune analiza interogărilor şi a tranzacţiilor în
baza de date. O primă analiză a lor a fost realizată în etapa proiectării logice a bazei de date,
atunci când s-a verificat completitudinea schemei logice.
Analiza tuturor operaţiunilor de accesare a bazei de date este practic imposibilă, de aceea
vor fi investigate doar cele mai importante, din punctul de vedere al frecvenţei invocării lor. În
general, se poate aplica regula lui Fibonacci (80/20), adaptată domeniului informatic de către
Wiederhold23. Conform acesteia, 80% din totalul operaţiunilor de acces al datelor sunt invocate
numai de 20% din interogările utilizatorilor. Aşadar, analiza operaţiunilor de acces poate
începe cu identificarea celor mai reprezentative 20% dintre ele, din punctul de vedere al
frecvenţei.
În vederea luării deciziilor de proiectare fizică a bazei de date, sunt necesare următoarele
categorii de informaţii24:
A. Descrierea interogărilor şi tranzacţiilor bazei de date
Scopul descrierii interogărilor şi tranzacţiilor în baza de date constă în determinarea
tabelelor şi atributelor accesate cel mai frecvent. Fişierele accesate mai frecvent trebuie
analizate mai în detaliu pentru a se determina structurile de stocare şi căile de accesare cele
mai potrivite.
În acest context, sunt utile matricile CRUD, utilizate şi descrise de noi în faza de analiză.
Matricea CRUD arată tranzacţiile din sistem şi tabelele pe care le accesează, aşa cum este ea
construită în timpul analizei. Dacă în celulele matricei se va introduce şi frecvenţa de apariţie a
fiecărei operaţii de acces, sub forma numărului de accese pe unitatea de timp (oră, zi,
săptămână, lună etc), atunci ea va evidenţia şi tabelele pentru care se înregistrează un număr
mai mare de accese. Aceste tabele vor fi analizate mai atent din perspectiva performanţelor,
pentru a se lua deciziile optime de proiectare fizică. Informaţiile furnizate de matricea CRUD
pot fi completate cu cele privind descrierea interogărilor şi tranzacţiilor, obţinându-se o
imagine mai completă prin determinarea atributelor accesate mai frecvent.
Pentru fiecare interogare se vor specifica următoarele elemente:
1. fişierele (tabelele) accesate, incluse în clauza FROM;
2. atributele ale căror valori vor fi returnate ca rezultat al interogării, respectiv cele
specificate în clauza SELECT. Atributele derivate (calculate pe baza altor atribute din
tabele) sunt candidate pentru stocare în fişiere;
3. atributele incluse în condiţiile (predicatele) de selecţie a înregistrărilor din tabele ce
vor fi reţinute în rezultatul interogării (în clauza WHERE). Pentru aceste atribute se va
analiza oportunitatea prevederii unor structuri de acces (precum indecşii);
4. atributele incluse în condiţiile de joncţiune a tabelelor, ele fiind, de asemenea,
candidate pentru crearea structurilor de acces.
Pentru fiecare tranzacţie se vor specifica următoarele elemente:
23. Connoly, T.M., Begg, C.E. – Database Systems. A Practical Approach to Design, Implementation, and
Management, Third Edition, Addison-Wesley, Harlow, 2002.
24. Elmasri, R., Navathe, S.B. – Fundamentals of Database Systems, Third Edition, Addison Wesley, Reading,
Massachusetts, 2000.
1. tabelele care vor fi actualizate;

2. tipul operaţiunilor efectuate asupra fiecărei tabele (adăugare, modificare, ştergere);
3. atributele utilizate în condiţii (predicate) de selecţie a înregistrărilor afectate de
operaţiunile de modificare sau ştergere (incluse în clauza WHERE a frazelor UPDATE
sau DELETE).;
4. atributele ale căror valori vor fi schimbate prin operaţiunile de modificare (specificate
în clauza SET a frazei UPDATE). În cazul acestor atribute se va evita crearea unor
structuri de acces, deoarece modificarea valorii lor va determina actualizarea
structurilor de acces respective, ceea ce va duce la creşterea timpului de execuţie.
B. Estimarea frecvenţei de invocare a interogărilor şi tranzacţiilor.
Frecvenţa interogărilor şi tranzacţiilor este exprimată, cel mai adesea, sub forma
numărului mediu şi maxim pe o unitate de timp (minut, oră, zi, săptămână etc). De asemenea,
trebuie determinate zilele şi/sau perioadele de timp în care sunt invocate interogările şi
tranzacţiile, precum şi momentele lor de vârf. De exemplu, anumite interogări pot fi solicitate
la rata lor medie în cea mai mare parte a timpului, însă cu un maxim atins în fiecare zi de
vineri, între orele 14,00 şi 16,00.
Analiza acestor informaţii, împreună cu descrierile fiecărei operaţiuni de acces, poate
evidenţia perioadele de supra-solicitare a bazei de date sau a unei părţi a acesteia, generată de
suprapunerea unor tranzacţii şi interogări. Se pot determina tabelele şi atributele solicitate
frecvent, precum şi perioadele de timp critice.
Problemele potenţiale pot fi evitate prin proiectarea adecvată a fişierelor sau prevederea
unor structuri de acces pentru atributele regăsite în predicatele de selecţie sau joncţiune. În
cazul fişirelor actualizate frecvent, se va utiliza un număr minim de structuri de acces (cum ar
fi indecşii). O altă soluţie constă în replanificarea unor tranzacţii. De exemplu, unele solicitări
de raportare pot fi reprogramate în intervalele de timp în care baza de date este mai puţin
solicitată.
C. Determinarea restricţiilor de timp privind execuţia
interogărilor şi tranzacţiilor
Utilizatorii pot solicita ca unele interogări şi tranzacţii să fie executate într-un anumit
timp. De exemplu, adăugarea unei vânzări să fie efectuată în maxim 5 secunde. Astfel de
tranzacţii sunt considerate critice, iar atributelor şi fişierelor accesate li se va acorda prioritate
la proiectarea fizică a bazei de date.
Rezumat
Proiectarea fizică a bazei de date are drept scop transformarea schemei logice într-un set de
specificaţii tehnice care privesc stocarea şi accesarea datelor. Obiectivele principale urmărite constau în:
transpunerea schemei logice a datelor într-un model care să poată fi implementat în SGBD-ul ales,
obţinerea performanţelor dorite prin structura de stocare aleasă şi definirea măsurilor de securitate
privind accesul la date.
Atingerea obiectivelor enumerate anterior presupune parcurgerea unui demers, a cărui primă
activitate constă în alegerea SGBD-ului în care va fi implementată baza de date. Urmează transpunerea
schemei logice a bazei de date, în sensul alegerii tipurilor de date pentru fiecare atribut, a modurilor de
implementare a câmpurilor calculate şi a restricţiilor de integritate.
1. Realizaţi o comparaţie între proiectarea logică şi cea fizică a bazei de date din perspectiva scopului şi
obiectivelor urmărite.
2. Definiţi noţiunea de tranzacţie din perspectiva bazei de date.
3. Care este rolul mecanismului tranzacţional al bazei de date ?
4. Descrieţi proprietăţile tranzacţiilor.

5. Explicaţi, prin intermediul unui contra-exemplu, în ce constă proprietatea de consistenţă a
tranzacţiilor.
6. Care sunt categoriile de informaţii utile în deciziile de proiectare fizică a bazei de date?
7. Prezentaţi elementele descriptive ale interogărilor şi tranzacţiilor bazei de date.
Probleme
1. Pornind de la schema logică a bazei de date pentru sistemul de gestiune a clienţilor, prezentată în
figura C3.1, să se descrie tranzacţiile şi interogările enumerate mai jos. Pentru tranzacţii se va utiliza
modelul din tabelul 4.1., iar pentru interogări se va crea un tabel care să conţină coloanele: nume
tabelă accesată, atribute solicitate, atribute derivate(se va specifica şi formula de calcul), atribute
incluse în joncţiuni.
a) T1 - Adăugare vânzare;
b) T2 - Adăugare returnare produse;
c) T3 - Anulare vânzare;
d) T4 - Adăugare client;
e) T5 - Modificare date comandă;
f) I1 – Lista stocurilor şi soldurilor pe depozite (soldul se calculează ca produs între stocul şi preţul
produsului);
g) I2 – Situaţia comenzilor neonorate cu termenul de livrare depăşit;
h) I3 – Afişarea conţinutului unei facturi
i) I4 – Situaţia vânzărilor din ultimele trei luni pentru un anumit client (se va calcula valoarea
fiecărei facturi)
j) I5 – Situaţia agregată a vânzărilor din anul anterior pe fiecare produs şi fiecare lună
calendaristică.
k) I6 – Situaţia agregată a returnărilor din anul anterior pe fiecare client şi fiecare lună
calendaristică.
CAPITOLUL V
Proiectarea programelor şi a procedurilor
Obiective:
• Prezentarea principalelor concepte utilizate în proiectarea programelor
• Definirea arhitecturii programelor
• Descrierea principiilor de proiectare a programelor
• Descrierea organizării ierarhice a programelor
• Evaluarea obiectivelor proiectelor software prin intermediul cuplării şi coeziunii
• Formularea unor recomandări pentru rafinarea arhitecturii programelor
Până în această fază ne-am ocupat, mai întâi, de proiectarea interfeţelor sistemului, care
apar sub forma formularelor/formatelor sau rapoartelor, a ecranelor sau secvenţelor de dialog.
Apoi, ne-am ocupat de proiectarea bazei de date, urmărind transpunerea cerinţelor din modelul
conceptual al datelor în schema logică (modelul relaţional) şi, mai departe, în schema fizică de
stocare a datelor. Proiectarea intrărilor, ieşirilor şi a stocării datelor fiind rezolvată, nu ne
rămâne decât să ne aplecăm asupra cerinţelor privind prelucrările din sistem, în scopul
transpunerii lor în programe.
Prin problematica prezentată în capitolul de faţă intrăm în domeniul de activitate al
proiectanţilor de soft şi al programatorilor. Proiectantul de soft are ca principală misiune
definirea şi structurarea componentelor care vor forma un tot unitar, astfel încât prin acestea să
se obţină un proiect soft operaţional. După proiectanţii de soft vor interveni programatorii,
pentru transpunerea în realitate a proiectului. Ei vor controla intrările, prelucrările, stocările şi
ieşirile din sistem prin intermediul programelor.
5.1 Aspecte generale ale proiectării programelor

şi procedurilor
Programul, în concepţia diverşilor autori, are semnificaţii diferite. El este definit ca:
• o entitate ce poate fi executată pe calculator;
• un mijloc de comunicare cu calculatorul pentru rezolvarea unei probleme;
• o descriere a unui algoritm şi a datelor asociate în vederea execuţiei pe calculator, deci
o reprezentare a acestora (algoritmi şi date) ţinând cont de restricţiile impuse de
calculator;
• o realizare a unei funcţii f care, dată fiind o mulţime de date x, specifică o valoare y =
f(x); multitudinea datelor permise ca date de intrare formează domeniul programului,
iar mulţimea ieşirilor care pot fi obţinute prin intermediul programului constituie
codomeniul acestuia.
În continuarea acestui paragraf, vom urmări să definim noţiunea de arhitectură a
programelor, să descriem succint principiile de lucru aplicabile în proiectarea programelor şi să
trecem în revistă structurile fundamentale de control utilizate nu doar în descrierea logicii
modulelor, ci şi în descrierea arhitecturii programelor.
5.1.1 Definirea arhitecturii programelor

Arhitectura unui sistem informatic face referire la structura sa. Conform teoriei generale a
sistemelor, prin structură se descriu elementele componente ale sistemului, interconexiunile
între acestea, pe de o parte, între acestea şi sistem, pe de altă parte. Noţiunea de structură poate
fi definită din perspectiva transformărilor prin care trece sistemul în interacţiunea cu mediul
său, considerându-se că ea face referire la aspectul invariant al sistemului, dând identitatea
acestuia. Ea defineşte o ordine relativ stabilă, referindu-se la anumite caracteristici invariabile
în condiţiile variabilităţii intrărilor, ieşirilor şi stărilor sistemului.
Într-o manieră generică, arhitectura unui program defineşte componentele acestuia,
proprietăţile lor vizibile din exterior, precum şi relaţiile dintre componente. Concretizarea
definiţiei anterioare presupune specificarea semnificaţiei atribuite noţiunii componentă, după
care vor putea fi identificate proprietăţile lor şi natura relaţiilor dintre ele.
În cazul programelor, putem vorbi despre două categorii de componente: instrucţiunile (în
alte materiale fiind regăsite sub numele de enunţuri, în altele – declarative, de la cuvântul
englezesc statements) şi modulele. Ele constituie „materia primă” din care se realizează
programele aplicaţiilor.
Instrucţiunile sunt operaţiuni elementare executate de calculator prin gruparea şi selecţia
controlată a acestora pentru atingerea obiectivelor funcţiilor de prelucrare orientate pe
probleme. Instrucţiunile constituie cel mai de jos nivel al operaţiunilor ce pot fi executate de
către un limbaj de programare. Blocurile de instrucţiuni sunt astfel grupate încât să constituie
anumite structuri executabile de calculator. De modul în care sunt grupate instrucţiunile pentru
a da naştere unor structuri standard ale programelor, de relaţiile dintre instrucţiuni, de
aranjamentul acestora depinde calitatea softului proiectat.
Modulul este o unitate structurală de sine stătătoare, fie program, fie subprogram, ce apare
ca o colecţie sau o formă grupată de instrucţiuni program. El reprezintă o unitate de program ce
poate fi compilată separat. Modulele se pot grupa pentru a forma programele, deci, la nivelul
softului proiectat, modulul reprezintă componenta de bază.
Odată ce am clarificat semnificaţia noţiunii de componentă în arhitectura programelor,
acum va trebui să identificăm proprietăţile modulelor de program. Astfel, un modul prezintă
trei atribute (proprietăţi) de bază, prin intermediul cărora el poate fi descris: funcţia, logica şi
interfaţa.
Funcţia unui modul face referire la transformările realizate asupra datelor în urma
execuţiei acestuia. Funcţia este tratată în regimul cutiei negre, adică ea este văzută prin ceea ce
se percepe din exteriorul modulului, respectiv intrările, ieşirile şi rolul modulului, fără a privi
componentele interne ale modulului (instrucţiunile şi logica modulului).
Logica modulului descrie prelucrările care au loc în interiorul acestuia, ceea ce, spre
deosebire de funcţie – referită ca o cutie neagră, ar însemna tratamentul cutiei albe. La nivelul
programării, preocuparea este, în esenţă, legată de logica modulului. Algoritmii de prelucrare,
redaţi sub diverse forme – scheme logice, pseudocod, tabele de decizie, arbori de decizie sau
combinaţii ale acestora – sunt concepuţi pentru prezentarea modului de transformare a
intrărilor în ieşiri. Paşii algoritmilor se vor transforma în instrucţiuni ale limbajelor de
programare. Fiecare modul va avea un singur punct de intrare şi un singur punct de ieşire.
Interfeţele fac referire la structurile de date transferate între module. De cele mai multe
ori, pentru a-şi îndeplini funcţia, modulele trebuie să primească anumite date şi, la rândul lor,
să transmită rezultatele prelucrării altor module.
Aşa cum spuneam anterior, arhitectura unui program face referire numai la proprietăţile
componentelor vizibile din exterior, adică funcţia şi interfeţele modulelor. Proprietăţile interne
ale componentelor, reprezentate de detaliile logicii algoritmilor din module, nu sunt luate în
considerare la definirea arhitecturii programelor, ele nefiind vizibile din exterior.
Din acest punct de vedere, putem distinge două mari activităţi în proiectarea programelor:
proiectarea arhitecturală şi proiectarea logicii modulelor. Proiectarea arhitecturală presupune
PROIECTAREA PROCEDURILOR ŞI A PROGRAMELOR 101
găsirea soluţiilor privind descompunerea sistemului în părţi componente astfel încât fiecare
parte să fie mai puţin complexă decât sistemul ca întreg, iar prin integrarea acestor componente
sistemul să fie cât mai flexibil, să îndeplinească cerinţele funcţionale şi criteriile de calitate
specifice programelor. În condiţiile în care complexitatea modulelor este rezonabilă, este foarte
important ca interfeţele dintre acestea să nu fie prea complicate. Logica modulelor vizează
algoritmii de prelucrare ce vor fi implementaţi în vederea obţinerii funcţionalităţii prevăzută
pentru fiecare modul în parte.
Ultimul aspect relevant, din perspectiva arhitecturii programelor, se referă la natura
relaţiilor dintre componente. Relaţiile dintre modulele unui program se înregistrează pe două
planuri:
• al transferării controlului execuţiei de la un modul la altul;
• al transmiterii datelor de la un modul la altul.
Arhitectura programelor prezintă o mare importanţă în activitatea de proiectare din cel
puţin patru motive25:
• conceperea arhitecturii programului permite o mai bună comunicare între membrii
echipei de dezvoltare a sistemului informatic, pe baza ei putându-se discuta şi analiza
inclusiv aspectele calitative relevante ale programelor;
• arhitectura evidenţiază principalele decizii de proiectare care au un impact profund
asupra activităţilor ulterioare privind dezvoltarea programului şi în succesul acestuia;
• arhitectura oferă un model relativ simplu al modului în care este structurat sistemul şi
modul în care componentele sale interacţionează, facilitând repartizarea sarcinilor de
lucru privind proiectarea şi scrierea programelor pe fiecare membru al echipei;
• arhitectura reprezintă o unitate transferabilă a sistemului informatic, deoarece ea
facilitează reutilizarea componentelor atât în cazul unor sisteme similare, cât şi al
reproiectării sistemului.
În acest capitol ne vom concentra atenţia asupra proiectării arhitecturale a programelor,
cadru în care vom pune în discuţie organizarea modulelor de program, instrumentele şi
tehnicile de reprezentare a arhitecturii programelor, căile de obţinere a ei şi criteriile cantitative
şi calitative de evaluare a structurii programelor.
5.1.2 Principiile de proiectare a programelor

Ca programele să fie caracterizate prin eficienţă, fiabilitate, flexibilitate şi inteligibilitate,
în procesul proiectării lor trebuie să se aplice următoarele principii:
1. Principiul modularizării. El a fost introdus odată cu programarea modulară şi
reprezintă aplicarea vechiului dicton „divide et impera” („împarte şi stăpâneşte”) în
dezvoltarea programelor. Conform acestui dicton, rezolvarea unei probleme complexe
poate fi simplificată, prin descompunerea ei în mai multe probleme independente mai
simple, a căror înţelegere şi rezolvare sunt mai facile. Aplicarea acestui principiu
presupune descompunerea unui program în subdiviziuni logice (module) ce pot fi uşor
proiectate şi testate separat, fără a ţine seama de numeroasele detalii ale întregului
program.
2. Principiul abstractizării. Abstractizarea permite descrierea a ceea ce trebuie făcut şi
nu cum trebuie făcut, oferind soluţiile cele mai bune de rezolvare a problemei, fără
luarea în considerare a aspectelor de detaliu şi irelevante ale realităţii. Astfel, se
realizează o mai bună stăpânire a complexităţii, prin structurarea programelor pe mai
multe niveluri de abstractizare. Primul nivel al unui program este cel mai abstract şi
oferă o imagine simplificată a acestuia, exprimată printr-o singură funcţie sau
25. Presmann, R.S. – Software Engineering. A practitioner’s Approach, McGraw Hill Publishing Company,
London, 2000, p. 359.
instrucţiune, în timp ce pe ultimul nivel se găsesc detaliile. Parcurgând în jos

programul, componentele acestuia sunt descrise cu detalii din ce în ce mai multe.
3. Principiul ordonării ierarhice este strâns legat de principiul modularizării. El
presupune nu doar descompunerea programului în părţi componente, ci şi aranjarea lor
într-o structură ierarhică, sub formă arborescentă. Prin această ordonare se obţine un
plus de inteligibilitate a programelor elaborate. Structura ierarhică reprezintă un
mecanism puternic de creare a programelor uşor modificabile, deoarece permite
eventuala renunţare la modulele situate pe un nivel, astfel încât modulele situate pe
nivelurile inferioare să rămână utilizabile şi să constituie baza unui nou program.
4. Principiul conformării, potrivit căruia programele trebuie să fie elaborate în
conformitate cu cerinţele utilizatorului.
5. Principiul completitudinii constă în realizarea descrierilor complete ale obiectivelor
programului pe toate nivelurile ierarhice de descompunere.
5.1.3 Structurile de control ale programelor

După o perioadă de artizanat în activităţile de programare, analiză şi proiectare, s-a trecut
la abordarea structurată a acestora, ceea ce a însemnat impunerea unor restricţii de utilizare, cu
scopul creşterii strandardizării şi a eficienţei activităţilor susmenţionate. Controlul se referă la
relaţiile posibile dintre componentele programului. Structurile de control al logicii, cunoscute
şi sub numele de structuri de control fundamentale, reprezintă un set minim, dar necesar, de
reguli prin care să se controleze procesul de activare a componentelor de prelucrare dintr-un
program sau dintre modulele acestuia. Structurile sunt: secvenţa, selecţia şi iteraţia sau
repetiţia. Ele mai sunt cunoscute şi sub numele de structură secvenţială, alternativă (simplă şi
generalizată), repetitivă (condiţionată anterior sau la început şi condiţionată posterior sau la
sfârşit). Secvenţa asigură parcurgerea instrucţiunilor în ordinea în care apar. Selecţia defineşte
alegerea unui grup de instrucţiuni din două sau mai multe posibile. Iteraţia oferă posibilitatea
execuţiei repetate a unui grup de instrucţiuni.
În elaborarea programelor structurate este necesar să se respecte o serie de restricţii:
• fiecare element (secvenţa, selecţia, iteraţia) are un punct unic de intrare;
• fiecare element are un punct unic de ieşire;
• elementul de iteraţie permite şi o execuţie cu factor de repetiţie zero, adică excluderea
elementului respectiv din execuţie.
Fiecare element din cele enunţate (secvenţa, selecţia, iteraţia) care respectă restricţiile de
mai sus defineşte un bloc standard. De asemenea, orice combinaţie de blocuri standard care
respectă restricţiile precizate defineşte un bloc standard.
Structura secvenţială (liniară) se prezintă astfel (fig. 5.1):
S1
S2
Sn
Fig. 5.1 Structura secvenţială

Selecţia (structura de tip IF-THEN-ELSE) sau structura alternativă are următoarea formă
de reprezentare (fig. 5.2):
Nu Da
C
Bloc-2 Bloc-1
Fig. 5.2 Structura alternativă
Dacă se îndeplineşte condiţia C, se execută operaţiile din Bloc-1, altfel se execută

operaţiile din Bloc-2; după execuţia blocului, se continuă cu instrucţiunea următoare.
Când Bloc-2 nu conţine nici o operaţiune, rezultă o structură alternativă cu o ramură
vidă, de tip IF-THEN, redată în figura 5.3.
Nu Da
C
Bloc-1
Fig. 5.3 Structura alternativă cu o ramură vidă
Structura alternativă generalizată (de tip CASE-OF) este o generalizare a selecţiei. Ea

permite alegerea unei variante din mai multe posibile (fig. 5.4).
Bloc- 1 Bloc-2 Bloc-n
Fig. 5.4 Structura alternativă generalizată

Iteraţia sau structura repetitivă defineşte execuţia repetată a unei operaţii sau grup de
operaţii, funcţie de rezultatul evaluării unei condiţii. Evaluarea condiţiei se face fie înainte, fie
după executarea operaţiilor.
Structura repetitivă condiţionată anterior (de tip WHILE-DO) se reprezintă ca în figura
5.5, iar structura repetitivă condiţionată posterior (de tip DO UNTIL) are forma redată în
figura 5.6.
Bloc-1
C
Da
Nu
Fig. 5.5 Structura repetitivă condiţionată anterior
Bloc-1
C
Da
Nu
Fig. 5.6 Structura repetitivă condiţionată posterior
O formă particulară de structură repetitivă condiţionată posterior este structura repetitivă

cu număr definit de paşi (de tip DO FOR). Numărul de repetiţii este controlat de o variabilă,
numită variabilă de control. În reprezentarea grafică următoare, V este variabila de control, Vi
este valoarea iniţială a variabilei de control, Vf este valoarea finală a variabilei de control, iar
R este raţia (incrementul). O astfel de structură este redată în figura 5.7.
În literatura de specialitate, se consideră că structura secvenţială, structura alternativă de
tip IF-THEN-ELSE şi structura repetitivă condiţionată anterior sunt suficiente pentru a defini
structura de control a oricărui program Din acest motiv, cele trei structuri de control,
enumerate mai sus, sunt numite structuri fundamentale sau structuri de bază.
V:=Vi
Bloc-1
V:=Vi+R
V>Vf Nu
Da
Fig. 5.7 Structura repetitivă cu număr definit de paşi
5.2 Organizarea ierarhică a programelor

În afara identificării componentelor şi a naturii legăturilor dintre ele, orice sistem implică,
pe lângă componentele sale şi legăturile dintre ele, o formă de organizare. Deşi, până în
prezent, au fost dezvoltate sute de mii de programe informatice, marea lor majoritate au la bază
organizarea ierarhică a modulelor, prezentată sub forma unei structuri arborescente inverse
(vezi figura 5.8). Programarea orientată-obiect a păstrat acest model de organizare, clasele de
obiecte fiind aranjate ierarhic.
P Nivelul 1
P apelea za
nod
a b c
Nivelul 2
arc
adâncimea d e k l m Nivelul 3
f g h n o p q Nivelul 4
r este
r apelat
i j Nivel 5
lungimea
Fig. 5.8 Structura ierarhică a programelor
Organizarea ierarhică presupune gruparea modulelor pe niveluri ierarhice, în care un

modul poate fi apelat numai de modulele situate pe nivelul ierarhic superior. El este considerat
subordonat modulelor care-l apelează, în timp ce un modul care apelează module subordonate
este referit ca supervizor (sau modul de control). De exemplu, modulul P este supervizor
pentru modulele a, b şi c, iar modulul i este subordonat modulelor f,g şi h, iar în ultimă
instanţă, modulului P.
În scopul unei mai bune evaluări a structurii ierarhice a programelor au fost introduse
unele mărimi cantitative. Ele sunt considerate ca fiind de tip „cutia neagră”, deoarece nu
presupun cunoaşterea detaliilor interne ale modulelor. Cele mai simple mărimi, puse în
evidenţă în figura 5.8, sunt:
• Dimensiunea, calculată ca numărul de noduri din structură, numărul arcelor sau ca
suma acestora. Structura ierarhică a programelor poate fi văzută ca un graf, în care
modulele reprezintă nodurile grafului, iar arcele corespund legăturilor dintre module.
• Adâncimea (depth) indică numărul nivelurilor ierarhice din structură, luându-se în
calcul calea cea mai lungă de la rădăcină până la un nod frunză. Pentru structura din
figura 5.8, acest indicator are valoarea cinci.
• Lăţimea (width) reprezintă numărul nodurilor de pe nivelul ierarhic cu cele mai multe
noduri. Pe nivelul patru al arhitecturii din figura 5.8 se găsesc cele mai multe module,
respectiv şapte.
• Numărul modulelor apelate (fan-out) este calculat, pentru fiecare modul, ca numărul
modulelor apelate în mod direct de către modulul respectiv. Pentru modulul m acest
indicator are valoarea patru.
• Numărul modulelor apelante (fan-in), calculat, de asemenea, pentru fiecare modul şi
reprezintă numărul modulelor care apelează în mod direct modulul respectiv. De
exemplu, modulul i este apelat de trei module, respectiv f, g şi h.
Aceste mărimi elementare stau la baza calculării unor indicatori, care permit o evaluare
mai completă a structurii programelor. De exemplu, raportul dintre numărul arcelor şi numărul
nodurilor măsoară nivelul conectivităţii arhitecturii şi oferă o imagine generală asupra gradului
de cuplare a modulelor.
Numeroşi specialişti au propus chiar seturi de indicatori pe baza cărora să se analizeze
arhitectura programelor26. Card şi Glass au definit trei indicatori pentru aprecierea
complexităţii arhitecturale:
• Complexitatea structurală a unui modul, calculată după formula:
S(i) = A2(i),
în care A reprezintă numărul modulelor apelate de către modulul i.
• Complexitatea datelor se referă la complexitatea interfeţelor unui modul, fiind
calculată după formula:
D(i) = v(i) / [A(i) + 1],
în care v(i) reprezintă numărul variabilelor care intră/ies în/din modulul i.
• Complexitatea sistemului este definită ca suma celor două mărimi definite anterior,
respectiv C(i) = S(i) + D(i). Pe măsură ce aceste mărimi cresc, va creşte şi
complexitatea sistemului, deci şi probabilitatea ca efortul de programare, testare şi
întreţinere să crească.
5.3 Evaluarea obiectivelor proiectelor software
Evaluarea calităţii programelor se referă atât la caracteristicile externe, cât şi la cele

interne ale modulelor. Un soft de calitate trebuie să îndeplinească următoarele condiţii:
• să fie uşor de implementat şi testat;
• să fie uşor de întreţinut şi modificat.
Calităţile amintite se creează încă din faza de concepere a proiectelor programelor, scop în
care se utilizează conceptul independenţă funcţională. Acest concept derivă din principiul
„divide et impera” şi principiul abstractizării, discutate anterior, şi presupune ca fiecare modul
de program să fie proiectat să realizeze o singură funcţie sau subfuncţie a programului.
Avantajele creării de module independente funcţional constau în:
26. Vezi Hughes, B. – Practical software measurement, McGraw-Hill, 2000.

• uşurinţa dezvoltării programelor, mai ales în condiţiile lucrului în echipă, deoarece

proiectantul se poate concentra asupra realizării unei singure funcţii, independent de
membrii echipei care se ocupă de proiectarea modulelor care privesc alte funcţii ale
sistemului;
• limitarea efectelor secundare generate de modificarea codului sau a specificaţiilor de
proiectare;
• facilitarea definirii cazurilor de test;
• posibilitatea reutilizării unor module în cazul modificării sistemului.
Independenţa funcţională este măsurată prin intermediul a două criterii calitative: cuplarea
şi coeziunea. Cuplarea este măsura gradului în care modulele programelor sunt interconectate.
Pentru facilitarea implementării şi întreţinerii, legăturile dintre module trebuie să fie minime,
deci gradul cuplării să fie redus. Coeziunea este măsura legăturilor interne dintre componentele
de prelucrare sau instrucţiuni, la nivelul unui modul. Cu alte cuvinte, se va urmări modul în
care instrucţiunile dintr-un modul sunt folosite pentru realizarea aceleiaşi funcţii. Legăturile
interne ale modulului trebuie să fie cât mai puternice, deci coeziunea cât mai mare.
5.3.1 Cuplarea
Scopul cuplării este de reducere a interdependenţelor dintre module. Operaţiunea de
asigurare a independenţei modulelor nu este uşor de realizat, întrucât performanţa constă într-
un grad cât mai redus al cuplărilor. Cu cât gradul de cuplare este mai mare, cu atât este mai
mare probabilitatea propagării erorilor de la un modul la altul.
Page & Jones27 tratează cinci tipuri de cuplare (la nivel de date elementare – data
coupling, la nivel de date grupate – stamp coupling, la nivelul informaţiilor de control –
control coupling, la nivelul datelor comune – common coupling, la nivel de conţinut – content
coupling). Powers, Cheney şi Crow tratează doar primele patru tipuri.
Cuplarea prin date elementare (data coupling) trebuie să constituie obiectivul proiectului.
Modulele sunt total independente unele de altele, deoarece ele îşi transmit doar datele
elementare necesare pentru ca fiecare să-şi realizeze funcţia pentru care au fost proiectate.
Altfel spus, nici un modul nu va fi interesat de detaliile procedurale interne ale modulelor cu
care interacţionează.
Un exemplu este redat în fig. 5.9. Nici unul dintre cele două module nu este interesat de
detaliile interne de prelucrare ale celuilalt. Modulul INREGISTRARE_LIVRARE nu este
interesat de prelucrările la care vor fi supuse codul clientului şi valoarea facturii în modulul
CALCUL_DISCOUNT, ci doar de rezultatul prelucrărilor, respectiv valoarea discountului.
Inregistrare_livrare
vCodClient
vValDiscount
vValFactura
Calcul_discount
Fig. 5.9 Exemplu de module cuplate prin date elementare
Cuplarea prin date grupate (stamp coupling) presupune transferarea datelor grupate sub
formă de structuri de date sau chiar înregistrări întregi. O astfel de cuplare nu mai este la fel de
27. Page, J., Hooper, P. – Accounting and Information Systems, Fourth Edition, Prentice Hall, Englewood Cliffs,
New Jersey, 1992.
bună ca şi cea prin date elementare, întrucât complică sistemul. O simplă schimbare a unei
structuri de date dintr-un anumit modul va afecta, în lanţ, toate modulele cu care vine în
legătură, chiar şi atunci când acestea nu apelează la partea modificată. Se constată, astfel,
creşterea dependenţei modulelor de alte module, deoarece cuplarea prin date grupate oferă mai
multe date decât ar fi necesare. Ea nu ar fi criticabilă dacă toate datele elementare din structură
ar fi valorificate de către modulele care le preiau, conform fig. 5.10.
vValDiscount DateFactura = vCodClient+vValFactura
Calcul_discount
Fig. 5.10 Interfaţa dintre module cuplate prin date grupate,

valorificate în totalitate
Criticabil este exemplul din fig. 5.21, în care este valorificată doar o parte a datelor din
structură.
vValDiscount DateFactura = cNrFactura+dDataFactura+vCodClient+vCodMaterialv+

vCantitate+ValFactura+vValoareTVA
Calcul_discount
Fig. 5.11 Interfaţa dintre module cuplate prin date grupate,

nevalorificate în totalitate
Cuplarea prin informaţii de control (data coupling) apare când coordonatele prelucrărilor
se transmit de la un modul la altul, ceea ce înseamnă că un modul „se va interesa” despre
detaliile de prelucrare internă ale altuia. Din nou modulele devin dependente unele de altele.
Informaţiile de control, referite uneori şi prin englezescul flag, sunt acele date elementare
ce pot lua anumite valori bine definite dintr-un domeniu finit de valori. Cel mai comun
exemplu îl constituie datele de tip logic (boolean), care pot avea valorile TRUE sau FALSE. În
funcţie de valorile informaţiile de control, modulul căruia îi sunt transmise va executa un grup
de prelucrări (instrucţiuni) sau altul. Prin urmare, modulul apelant trebuie să cunoască în bună
măsură detaliile procedurale interne ale modulului apelat pentru a-i transmite controlul, gradul
de interdependenţă dintre cele două module este destul de mare.
Informaţiile de control pot fi transmise şi de la subordonat la superior, situaţie în care se
foloseşte noţiunea de inversare a autorităţii, deoarece subordonatul îi spune superiorului ce
trebuie să facă. Un asemenea exemplu este prezentat în figura 5.12. Modulul
INREGISTRARE_COMANDA este dependent de modulul VALIDARE_CLIENT întrucât va trebui
să testeze valoarea datei bStareClient, în funcţie de care va decide efectuarea unor prelucrări
sau a altora. O modificare a modulului VALIDARE_CLIENT care va avea ca efect returnarea
unei noi valori posibile (de exemplu, în afara valorilor „client valid” şi „client invalid” se mai
introduce valoarea „client-aprobare specială”), va determina modificarea şi a modulului
INREGISTRARE_COMANDA, prin introducerea unui nou grup de prelucrări (solicitarea unei
aprobări speciale printr-un mesaj transmis persoanei autorizate).
Cele trei tipuri de cuplare prezentate până acum sunt frecvent întâlnite în practică. Mai rar
întâlnite sunt ultimele două tipuri de cuplare.
Inregistrare_comanda
vCodClient
bStareClient
vValComanda
Validare_client
Fig. 5.12 Exemplu de cuplare prin informaţii de control

Cuplarea comună (common coupling) intervine atunci când două sau mai multe module
accesează în comun aceleaşi date elementare aflate într-un loc comun, cunoscut şi ca bloc de
date. Limbajele FORTRAN şi COBOL au performanţe deosebite pentru gestionarea acestui tip
de date aflate în blocuri.
Cuplarea prin conţinut (content coupling) este considerată ca fiind cea mai de nedorit
formă de cuplare. Ea presupune implicarea directă a unui modul în intimitatea prelucrărilor
altuia. De exemplu, un modul poate să schimbe datele altuia sau, mai grav, să schimbe
instrucţiunile acestuia. Se poate vorbi de o adevărată încrengătură a modulelor, fără să mai fie
pusă în discuţie limita independenţei acestora. Din fericire, limbajele performante nu acceptă
astfel de cuplări.
5.3.2 Coeziunea
Măsura în care toate instrucţiunile unui modul se referă la una şi aceeaşi funcţie se
numeşte coeziune. În timp ce cuplarea se referă la conexiunile externe dintre module,
coeziunea se preocupă de legăturile dintre elementele interne modulelor, ea fiind o măsură
internă a calităţii proiectului. Se spune că idealul ar consta într-o coeziune maximă, adică un
modul să realizeze o singură funcţie (sarcină).
Cercetătorii au sesizat şapte niveluri ale coeziunii. În ordinea valorii lor, de la cea mai
bună la cea mai slabă, aceste niveluri sunt: funcţională, secvenţială, comunicaţională,
procedurală, temporală, logică şi coincidentală. Scala valorilor coeziunii este neliniară, în
sensul că tipurile de coeziune cele mai slabe sunt mult mai „rele” decât tipurile de coeziune
medii care sunt „destul de bune” în comparaţie cu tipurile de coeziune cele mai bune.
Coeziunea funcţională
Un modul cu coeziune funcţională este cel mai dorit întrucât instrucţiunile lui au ca
obiectiv realizarea unei funcţii sau activităţi. Comportamentul acestor module este tipic cutiei
negre, în sensul că pentru folosirea lor trebuie cunoscute doar intrările şi ieşirile modulului,
fără să intereseze prelucrările lui interne.
O modalitate deosebită de testare a coeziunii funcţionale a unui modul o constituie
atribuirea numelui de modul. Dacă modulul poate fi descris ca realizând o singură funcţie
asupra unei singure structuri de date, atunci funcţionalitatea lui este asigurată. Astfel de
exemple sunt: CALCUL_DOBÂNDĂ, ACTUALIZARE_STOC, CALCUL_IMPOZIT_SALARIU,. La
numirea modulelor vor fi evitate elementele de legătură („şi”, „_”), ceea ce poate sugera că
modulul respectiv realizează mai mult decât o singură funcţie şi ar putea fi necesară
descompunerea acestuia.
Această caracteristică este valabilă pentru modulele aflate pe nivelurile inferioare ale
structurii ierarhice a programului, dar nu şi pentru modulele situate pe nivelurile superioare,
care au ca rol controlul execuţiei programului, în primul rând, şi nu realizarea unor sarcini
elementare. De exemplu, modulul CALCUL_SPORURI_REŢINERI_SALARII este un modul de
control a cărui funcţie constă în apelarea modulelor subordonate ierarhic într-o anumită
succesiune în vederea calculării salariului net, fiecare modul subordonat realizând calculul
unui anumit tip de spor sau reţinere. Prin urmare, se poate spune că modulul de control
CALCUL_SPORURI_REŢINERI_SALARII este coeziv funcţional.
Coeziunea secvenţială
Un modul este caracterizat de coeziune secvenţială atunci când realizează funcţii multiple
de prelucrare asupra aceloraşi structuri de date. Ordinea în care sunt apelate funcţiile este
foarte importantă. Rezultatele obţinute prin execuţia unei operaţiuni (funcţii) devin intrări
pentru următoarele. Aşadar, prima funcţie (operaţiune) va prelucra structura de date primită,
după care rezultatul transformării va constitui intrare pentru a doua funcţie, iar la rândul ei
ieşirea celei de-a doua funcţie va constitui intrarea pentru cea de-a treia funcţie ş.a.m.d.
Rezultatul obţinut prin aplicarea ultimei funcţii va reprezenta ieşirea modulului respectiv.
Un exemplu general de coeziune secvenţială este regăsit la modulele care citesc datele
dintr-un fişier, le prelucrează şi apoi le afişează/tipăreşte într-o anumită formă.
Multiplele funcţii pe care le realizează un modul caracterizat de coeziune secvenţială fac
dificilă întreţinerea acestuia. Însă, dezavantajul cel mai important este legat de limitarea
reutilizării unei funcţii interne a acestui modul de către celelalte module din sistem. Acceptarea
acestui tip de coeziune poate fi justificată de reducerea complexităţii interfeţelor dintre
modulele ce s-ar obţine prin descompunerea modulului, respectiv evitarea abuzului în
utilizarea de variabile globale. Oricum, eventualele probleme cauzate de coeziunea secvenţială
pot fi înlăturate prin descompunerea modulului respectiv în două sau mai multe module
subordonate ierarhic.
Coeziunea comunicaţională
Într-un modul caracterizat de coeziune comunicaţională, multiplele funcţii pe care le
realizează sunt legate între ele tot prin datele pe care modulul le utilizează, însă, spre deosebire
de coeziunea secvenţială, succesiunea funcţiilor nu este importantă.
De exemplu, un modul proiectat pentru înregistrarea unei facturi, va realiza următoarele
funcţii: inserarea facturii în baza de date, actualizarea soldului clientului, actualizarea stocului
pentru produsele vândute şi generarea notei contabile. El este caracterizat de o coeziune
comunicaţională, deoarece cele patru funcţii prelucrează aceleaşi date, dar ordinea de realizare
nu este importantă.
Coeziunea procedurală
Un modul prezintă coeziune procedurală atunci când conţine elemente grupate pe baza
fluxurilor de control din cadrul programului, adică funcţii independente, reunite doar pentru a
asigura transferul controlului de la o funcţie internă la alta, dar a căror secvenţă este
importantă.
Un exemplu de coeziune procedurală este cel al unui program de actualizare a
înregistrărilor, în cadrul căruia se realizează adăugarea, ştergerea sau modificarea unei
înregistrări. Astfel, în funcţie de codul operaţiunii care urmează să fie executată, programul
transmite controlul uneia din cele trei funcţii de prelucrare.
Coeziunea temporală
Modulele caracterizate de coeziune temporală grupează mai multe funcţii între care nu
există altă legătură decât cea legată de factorul timp, în sensul că toate trebuie executate la un
moment dat în execuţia programului, fără ca secvenţa de execuţie a lor să prezinte importanţă.
Cele mai cunoscute exemple sunt modulele de iniţializare şi cele de finalizare a programelor.
La lansarea unui program, un modul poate fi conceput pentru a realiza iniţializarea variabilelor
de memorie, conectarea la baza de date, deschiderea tabelelor necesare, configurarea mediului
de lucru etc.
Modulele cu coeziune temporală sunt dificil de întreţinut datorită nu numai multiplelor

funcţii pe care le realizează dar şi faptului acestea nu sunt dependente de fluxurile datelor sau
fluxurile de control.
Coeziunea logică
În acest tip de coeziune legăturile dintre instrucţiunile unui modul sunt foarte slabe.
Funcţiile unui astfel de modul sunt grupate împreună pe considerentul includerii lor într-o
categorie generală, urmărindu-se evitarea redundanţei în scrierea codului. Modulele cu
coeziune logică implică un grad mare de cuplare, ordinea de execuţie a instrucţiunilor dintr-un
astfel de modul fiind dictată din afară, prin intermediul unei informaţii de control.
Fişierele DLL din mediul WINDOWS sunt, în cele mai multe cazuri, proiectate să fie
logic coezive. De exemplu, fişierul COMMDLG.DLL conţine instrucţiunile pentru
configurarea căsuţelor de dialog activate la utilizarea opţiunilor File Open, File Save, Search şi
Print. Avantajul unei astfel de abordări constă în oferirea unei interfeţe unice pentru întreaga
aplicaţie şi scrierea de cod mai puţin. Numai că, dacă proiectanţii unei aplicaţii în mediul
WINDOWS doresc să nu se limiteze la facilităţile oferite de COMMDLG.DLL, vor trebui să
scrie propriul cod pentru a adăuga noi facilităţi. Ori, acest lucru este imposibil de realizat fără a
dezmembra o bună parte a logicii programului.
Coeziunea coincidentală
Este tipul de coeziune cel mai nedorit. Ea se manifestă atunci când între elementele unui
modul există puţine legături sau chiar nici o legătură. Toate funcţiile pe care le realizează
modulul au fost grupate cu totul întâmplător, ca urmare a neatenţiei proiectantului sau din
dorinţa acestuia de a economisi timp cu activităţile de proiectare şi programare. În mod normal,
modulele cu coeziune coincidentală sunt foarte rar întâlnite (sau cel puţin ar trebui).
Page-Jones a dezvoltat o diagramă foarte utilă pentru înţelegerea tipurilor de coeziune, el
ordonându-le într-un arbore decizional, redat în figura 5.13.
Da Funcţional?
Se poate considera că
modulul realizează o
Secvenţa Da Secvenţial?
singură funcţie? Datele prezintă
importanţă? Nu Comunicaţional?
Nu
Atunci ce leagă Secvenţa Da Procedural?

sarcinile interne Fluxul de prezintă
ale modulului? control importanţă?
Nu Temporal?
Sarcinile fac Da Logic?

Nici una parte din aceeaşi
categorie
generală? Nu Coincidental?
Fig. 5.13 Arborele de decizie privind tipurile de coeziune a modulelor
5.3.3 Recomandări pentru proiectarea programelor

În acest paragraf dorim să revenim la demersul proiectării arhitecturii programelor, mai
exact la ultima etapă – rafinarea structurii programelor.
Să ne reamintim că o primă formă a structurii programului, reprezentată cu ajutorul

diagramei de structură, a fost obţinută în urma aplicării celor două strategii: analiza
transformărilor şi analiza tranzacţiilor. Ele prezintă numeroase avantaje:
• Proiectarea ierarhică se realizează prin metoda top-down, similară descompunerii
funcţionale.
• Deoarece proiectele au la bază funcţiile de prelucrare din unitate, ca şi relaţiile dintre
ele, conexiunile dintre modulele programelor vor avea o formă similară. Schimbările
din structura funcţiilor se vor reflecta şi în structura programelor.
• Criteriile de descompunere a ramurilor aferente şi eferente sunt incluse în strategia
proiectării. Ca atare, procedurile de intrare şi ieşire sunt localizate în locuri diferite ale
sistemului, ceea ce va asigura o întreţinere performantă.
• Se oferă certitudinea că structura programului corespunde structurii problemei într-o
foarte mare măsură. Prin diagramele fluxurilor de date se poate realiza descrierea
fidelă a funcţiilor principale ale întreprinderii şi, în consecinţă, sistemul le va respecta
întocmai.
• Se asigură consistenţa proiectelor datorită uniformităţii criteriului de partiţionare. Pe
această cale, se ajunge ca doi sau mai mulţi proiectanţi să aibă rezultate comparabile.
Însă, dincolo de aceste avantaje, la proiectarea programelor trebuie să se urmărească
atingerea unor obiective de calitate, cum ar fi: funcţionare corectă, să fie sigur, uşor de folosit,
implementat, întreţinut şi testat, să folosească eficient resursele sistemului informatic, să fie
uşor adaptabil diverselor medii de operare ş.a. După cum am văzut în paragrafele anterioare, la
baza calităţii programelor stă conceptul de independenţă funcţională, apreciat cu ajutorul
cuplării şi coeziunii.
Cuplarea şi coeziunea prezintă o importanţă crucială în proiectarea sistemelor informatice,
demonstrată prin următoarele argumente28:
• Se reduce comunicarea între membrii echipei de dezvoltare a sistemului, deoarece
permite luarea unor decizii fără a lua în considerare deciziile şi activităţile care privesc
alte module;
• Se reduce probabilitatea propagării modificării unui modul către alte module, ceea ce
reduce costurile întreţinerii;
• Sporeşte gradul de reutilizabilitate a modulelor, în cazul reproiectării sistemului sau a
proiectării unui sistem asemănător;
• Creşte inteligibilitatea modulelor; simplitatea interfeţelor dintre module facilitează
înţelegerea unei componente a programului, independent de contextul în care este
utilizată;
• Studiile empirice arată că proiectele caracterizate de o coeziune puternică şi o cuplare
redusă sunt mai puţin supuse erorilor.
Cuplarea şi coeziunea se situează uneori pe poziţii contradictorii, în sensul că o coeziune
bună a modulelor unui program va determina un grad mare de cuplare a acestora. De aceea, la
rafinarea arhitecturii sistemului informatic cele două caracteristici trebuie analizate împreună.
În practică, nu este necesară stabilirea tipului de coeziune pentru fiecare modul, ci este
necesară înţelegerea deplină a conceptului în vederea recunoaşterii şi evitării tipurilor de
coeziune cele mai slabe. Ar fi ideal ca toate modulele unui program să fie caracterizate de
coeziune funcţională, însă practic acest lucru este imposibil.
Structura programului poate fi îmbunătăţită prin reanalizarea diagramei de structură şi
aplicarea următoarelor recomandări29:
28. van Vliet, H. – Software Engineering. Principles and Practice, John Wiley & Sons, Ltd., Chichester, 2000.
29. Presmann, R.S. – Software Engineering. A practitioner’s Approach, McGraw Hill Publishing Company,
London, 2000, p. 348-350.
• Evaluarea structurii programului în vederea reducerii cuplării şi îmbunătăţirii

coeziunii. În scopul sporirii independenţei funcţionale a modulelor, ele pot fi
descompuse sau recompuse. Necesitatea descompunerii modulelor apare atunci când
există prelucrări comune două sau mai multor module, ceea ce impune redefinirea
acestor prelucrări ca module separate coezive. De asemenea, în cazul modulelor cu un
grad mare de cuplare se poate realiza unirea lor în unul singur, în vederea reducerii
complexităţii interfeţei, a fluxurilor de control şi a referinţelor la date globale.
• Minimizarea structurilor în care un modul are în sfera sa de control prea multe module.
De regulă, odată cu creşterea nivelului de detaliere creşte şi numărul modulelor care
apelează un modul (fan-in).
• Menţinerea sferei efectelor unui modul în limita sferei sale de control. Sfera efectelor
unui modul cuprinde toate modulele care sunt afectate de o decizie localizată în
modulul respectiv. Sfera de control este formată din toate modulele subordonate
ierarhic modulului respectiv.
• Evaluarea interfeţelor dintre module în vederea reducerii complexităţii şi a
redundanţei. Complexitatea interfeţelor reprezintă principala cauză a erorilor de
programare. Interfeţele trebuie proiectate astfel încât să fie transmise de la un modul la
altul numai informaţiile semnificative pentru funcţiile celor două module.
Rezumat
La baza oricărui program stau noţiunile de instrucţiune (declarativă) şi modul. Instrucţiunile
constituie cel mai de jos nivel al operaţiunilor ce pot fi executate într-un limbaj de programare, ele fiind
astfel grupate încât să constituie anumite structuri executabile de calculator. Modulul este o colecţie sau o
formă grupată de instrucţiuni de programe sursă. Modulele se pot grupa pentru a forma programele.
În proiectarea programelor pot fi distinse două mari activităţi: proiectarea arhitecturii programelor
şi proiectarea logicii modulelor. Arhitectura unui program defineşte componentele acestuia, proprietăţile
lor vizibile din exterior, precum şi relaţiile dintre componente. Prin componentă facem referire la
modulele de program, iar proprietăţile lor vizibile din exterior sunt funcţia şi interfeţele. Relaţiile dintre
module asigură transmiterea controlului execuţiei şi transferul structurilor de date.
Rafinarea arhitecturii, presupune aplicarea unor concepte şi reguli practice de proiectare care
privesc îmbunătăţirea calităţii programului. Calitatea programelor este apreciată prin prisma uşurinţei
implementării, testării, întreţinerii şi modificării lor şi are la bază conceptul de independenţă funcţională.
Conform acestuia, fiecare modul de program să fie proiectat să realizeze o singură funcţie, bine definită, a
programului.
Independenţa funcţională este măsurată prin intermediul a doi indicatori calitativi: coeziunea şi
cuplarea. Coeziunea este măsura legăturilor interne dintre componentele de prelucrare sau instrucţiunile
unui modul, iar cuplarea reflectă gradul de interconectare a modulelor de program. Există mai multe
tipuri de coeziune şi cuplare, scopul oricărui proiect software fiind coeziunea funcţională şi cuplarea prin
date elementare. Rafinarea arhitecturii obţinute în urma transpunerii diagramelor fluxurilor de date constă
în recompunerea sau descompunerea unor module pentru a se obţine o coeziune maximă şi o cuplare
minimă.
După ce proiectarea structurii programului a fost finalizată, se trece la cea de-a doua activitate,
proiectarea logicii modulelor. Pentru redarea logicii modulelor se pot utiliza mai multe instrumente:
pseudocodul, tabelele sau arborii decizionali, diagrama stărilor de tranziţie etc.
1. Definiţi următoarele concepte: program, modul de program, arhitectura programelor, logica
modulului de program.
2. Care este diferenţa dintre o dată elementară şi o informaţie de control?
3. Explicaţi rolul coeziunii şi cuplării în proiectarea programelor.
4. Descrieţi cele cinci principii utilizate în proiectarea programelor.
5. Explicaţi de ce un modul cu coeziune funcţională este uşor de testat.
6. De ce modulele de program trebuie să fie independente funcţional?

7. Explicaţi de ce două module cuplate prin informaţii de control sunt dependente funcţional între ele.
Care sunt efectele negative ale acestui tip de cuplare?
8. Care este diferenţa între coeziunea secvenţială şi cea comunicaţională?
9. De ce, în unele situaţii, nu este eficientă descompunerea unui modul cu coeziune comunicaţională în
două sau mai multe module cu coeziune funcţională?
Probleme
1. Daţi un exemplu de pseudocod care să conţină o structură de control alternativă generalizată.
2. Daţi un exemplu de pseudocod care să conţină o structură de control repetitivă cu un număr definit
de paşi.
3. Daţi exemple din propriul studiu de caz de module caracterizate de următoarele tipuri de coeziune:
funcţională, secvenţială, comunicaţională.
4. Daţi câte un exemplu, din propriul studiu de caz, de cuplare prin date elementare şi prin informaţii
de control.
CAPITOLUL VI
Implementarea sistemului
Obiective:
• Înţelegerea importanţei planificării implementării
• Înţelegerea obiectivelor şi a principiilor testării sistemelor informaţionale
• Descrierea activităţilor din cadrul procesului de testare
• Clasificarea tehnicilor de testare
• Definirea strategiei de testare
• Conştientizarea importanţei şi rolului documentării sistemului
• Descrierea celor patru metode de conversie a vechiului sistem la noul sistem
Dintre toate etapele dezvoltării sistemului, implementarea are gradul de risc cel mai mare.
Acest lucru se datorează faptului că, în timpul etapelor anterioare (microanaliză, analiză,
proiectare), proiectul de dezvoltare este desfăşurat într-un mediu ce nu afectează activităţile
zilnice ale firmei. În schimb, implementarea presupune influenţarea operaţiunilor economice
reflectate de către sistemul dezvoltat, prin faptul că ea constă în înlocuirea efectivă a sistemului
vechi, ceea ce înseamnă că orice eroare nedepistată nici acum poate declanşa grave probleme.
De aceea, este necesar ca activităţile etapei de implementare să fie planificate şi gestionate cu
atenţie pentru a minimiza cât mai mult potenţialele efecte negative şi să se conceapă un plan de
acţiune pentru evenimentele neprevăzute.
Implementarea este procesul de transformare a componentelor proiectate într-un sistem
funcţional. De regulă, proiectarea fizică se concretizează într-un raport al proiectării fizice a
sistemelor, întocmit cu scopul furnizării informaţiilor necesare factorilor de decizie pentru a
efectua ultimele verificări şi pentru a-şi da sau nu acceptul de trecere la etapa de implementare.
Într-o formă destul de concentrată, în caseta 6.1, prezentăm conţinutul unui astfel de
raport pentru firma ABC.
Caseta nr. 6.1 – Conţinutul raportului proiectării fizice

S.C. ABC
Raportul proiectării fizice a sistemelor
I. Sinteza proiectării fizice a sistemelor
II. Prezentarea generală a scopului proiectului şi sinteza la zi a constatărilor de pe teren
III. Recomandările principale ale proiectării fizice
1. Proiectarea ieşirilor
2. Proiectarea intrărilor
3. Proiectarea bazelor de date
4. Proiectarea prelucrărilor (softului)
5. Proiectarea echipamentelor
6. Proiectarea controalelor
7. Proiectarea procedurilor de lucru
IV. Ipoteze de lucru şi probleme nerezolvate
V. Concluzii
VI. Anexe şi glosar de termeni
Implementarea sistemelor este procesul de instalare a echipamentelor şi softului, în
vederea finalizării sistemului şi dării lui în funcţiune. Operaţiunea se derulează printr-un set
bine definit de activităţi, redate în fig. 6.1.
6.1 Planificarea implementării
În timpul implementării, vor fi executate simultan mai multe activităţi. 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 să fie 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. 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.
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 executat în timp, pentru a putea
fi controlate. 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ă.
Planificarea implementării
Pregătirea
Realizarea şi Selectarea şi
locurilor de muncă;
testarea instalarea şi testarea instruirea
programelor echipamentelor personalului
Finalizarea Testarea
documentaţiei sistemului
Conversia de la
vechiul la noul
sistem
Fig. 6.1 Principalele activităţi ale etapei de implementare

Planificarea, coordonarea şi controlarea activităţii de implementare sunt cel mai des
realizate prin două tehnici cunoscute: diagramele Gantt şi PERT.
Dintre cele mai relevante aspecte ale planificării implementării, pot fi enumerate:
• începe odată cu luarea startului conceperii unui nou proiect;
• se încheie odată cu aprobarea dată pentru implementare;
• aprobarea planului de implementare, firesc, se obţine înainte de a începe această etapă;
• identificarea activităţilor principale, a desfăşurării lor calendaristice, a
responsabilităţilor, precum şi a rezultatelor finale ale acestora;
• urmărirea riguroasă a modului în care se respectă planul de implementare;
IMPLEMENTAREA SISTEMULUI 117
• identificarea factorilor de risc şi a modalităţilor strategice de eliminare sau de diminuare

a riscurilor;
• apelarea la diagramele Gantt pentru urmărirea modului de desfăşurare a etapei de
implementare;
• folosirea tehnicii PERT pentru identificarea activităţilor critice.
Planul de implementare are un rol esenţial în derularea activităţilor specifice şi de el
depind calitatea sistemului şi momentul în care poate dat în exploatare. Fără a face neapărat o
ierarhie, se consideră că planificarea implementării ocupă unul din primele locuri între factorii
de succes sau eşec al unui proiect, pentru că prin implementare se asigură, până la urmă,
funcţionarea sistemului.
6.2 Testarea sistemelor informaţionale
Dezvoltarea rapidă a tehnologiilor informaţionale a determinat extinderea rapidă a ariei de

informatizare, condiţii în care calitatea existenţei noastre depinde din ce în ce mai mult de
calitatea sistemelor informatice cu care lucrăm. De aceea, trebuie acordată o atenţie deosebită
activităţilor de testare. Testarea este ultima ocazie pentru revizuirea cerinţelor sistemului, a
specificaţiilor de proiectare şi a programelor sursă. Obiectivul general al testării îl reprezintă
identificarea numărului maxim de erori cu efort minim.
În general, cheltuielile asociate activităţii de testare pot ajunge până la o pondere de 30-
40% din totalul cheltuielilor necesare dezvoltării unui sistem informatic. În domeniile cu
activităţi critice (controlul traficului aerian, monitorizarea reactoarelor nucleare etc) aceste
cheltuieli pot fi de 3-5 ori mai mari decât toate celelalte cheltuieli cu dezvoltarea sistemului
informatic30.
6.2.1 Aspecte generale privind organizarea testării sistemelor

Testarea este un termen mai general care face referire la alte două noţiuni: verificarea şi
validarea. Verificarea reprezintă procesul de evaluare a sistemului sau a unei componente a lui,
pentru a se determina dacă o anumită funcţie a fost implementată corect, oferind răspunsul la
întrebarea: A fost construit bine sistemul? Validarea poate fi definită ca procesul de evaluare a
sistemului sau a unei componente a lui, pentru a se determina dacă sunt respectate cerinţele
funcţionale identificate în faza de analiză, răspunzând la întrebarea: A fost construit sistemul
care trebuie? Aşadar, verificarea vizează modul cum a fost construit sistemul, iar validarea se
referă la ce a fost construit. Atât verificarea, cât şi validarea trebuie desfăşurate pe parcursul
întregului proces de dezvoltare a sistemului, nu doar la sfârşitul acestuia.
Practic, testarea întregului sistem nu este posibilă, deoarece ea nu ar fi fezabilă economic
şi tehnic. Un exemplu simplu este edificator: dacă un program conţine două structuri de control
repetitive imbricate, fiecare din cele două structuri presupunând un număr de iteraţii cuprins
între 1 şi 20, iar structura de control interioară conţine patru structuri de control alternative
simple, atunci numărul ramurilor logice din program care trebuie testate va fi de 1014! Din
acest motiv, activitatea de testare trebuie organizată în mod riguros şi eficient.
În general, testarea implică elaborarea planurilor testelor, stabilirea standardelor testării,
precum şi încadrarea întregii activităţi de testare în ciclul de viaţă al sistemelor, în vederea
asigurării completitudinii planurilor de testare a programelor şi sistemului căruia aparţin. Într-o
formă schematică, principalele activităţi care formează procesul de testare sunt evidenţiate în
figura 6.2. P reprezintă obiectul supus testării, respectiv un modul de program, specificaţiile
procedurale sau întregul sistem.
30. Pressman, R.S. – Software Engineering. A Practitioner’s Approach, Fifth Edition, McGraw-Hill Publishing
Company, London, 2000, p.426.
subset al
datelor de Stabilirea rezultatele
intrare rezultatelor asteptate
P Strategia Compararea Rezultatele Documentatia

testarii rezultatelor testarii testarii
subset al P rezultatele
datelor de obtinute
intrare
Fig. 6.2 Schema generală a procesului de testare
(adaptare după van Vliet, H. – Software Engineering. Principles and Practicies,
John Wiley & Sons, LTD, Chichester, 2000, p. 401)
Prima activitate se referă la definirea strategiei, care are drept scop definirea setului
minim al datelor de test care să satisfacă cerinţele testării, cuantificate prin intermediul
criteriilor de acceptabilitate. De exemplu, criteriile de acceptabilitate pot fi exprimate astfel: la
testare se va urmări execuţia cel puţin o dată a tuturor instrucţiunilor din program; prin testare
se va urmări execuţia tuturor ramurilor logice din program etc. Evident că cele două exemple
nu sunt echivalente, întru-cât primul criteriu nu permite testarea ramurilor vide.
După stabilirea criteriilor de acceptabilitate, se va trece la generarea setului de teste care
să răspundă acestor criterii, adică a unui subset al datelor de intrare în P. Această activitate nu
se desfăşoară la întâmplare, ci de-o manieră sistematică, apelând la diferitele tehnici de testare
pe care le avem la dispoziţie. În funcţie de tehnicile de testare alese se va genera şi subsetul
datelor de test.
Odată definit setul de teste, se va trece la determinarea rezultatelor aşteptate pentru
fiecare test în parte şi apoi la execuţia componentei P. În final, se realizează compararea
rezultatelor obţinute în urma execuţiei cu cele aşteptate, eventualele diferenţe semnalând
existenţa unor erori, ce vor fi transmise spre rezolvare proiectanţilor sau programatorilor
responsabili de componenta testată. Rezultatele testării vor fi consemnate într-o documentaţie
specială.
Există câteva principii generale care ghidează activitatea de testare a programelor:
1. Testele trebuie concepute astfel încât să urmărească respectarea cerinţelor
utilizatorilor. Cele mai numeroase erori sunt legate de nesatisfacerea cerinţelor
sistemului, identificate şi formulate în faza de analiză.
2. Testele trebuie planificate cu mult timp înainte de începerea activităţii de testare.
Toate testele trebuie planificate şi proiectate înainte de scrierea/ generarea programelor
sursă, chiar din timpul analizei sistemului odată ce modelul cerinţelor sistemului este
complet. Definirea detaliată a cazurilor de test poate începe încă din timpul fazei de
proiectare, odată cu întocmirea specificaţiilor de proiectare.
3. Testarea trebuie să înceapă cu detaliile, desfăşurată la nivelul modulelor componente,
iar, pe măsură ce ea progresează, atenţia va fi îndreptată spre identificarea erorilor
de integrare a acestor componente şi, în final, asupra întregului sistem.
4. Testarea exhaustivă nu este posibilă. Numărul cazurilor de test, derivate din
combinarea tuturor situaţiilor posibile, este foarte mare chiar şi pentru programele de
dimensiuni mai mici. De aceea, este necesară utilizarea unor tehnici speciale de
definire a cazurilor de test care să corespundă criteriilor de acceptabilitate.
5. Pentru a fi eficientă, testarea trebuie să fie realizată de persoane care nu au fost
implicate în fazele anterioare de dezvoltare a sistemului. Chiar dacă acest principiu nu
trebuie interpretat în mod absolut, totuşi, de cele mai multe ori, persoanele implicate în
crearea sistemului nu sunt cele mai indicate în realizarea testării programelor, cu
excepţia aplicaţiilor de dimensiuni mai mici.
6. Testarea nu vizează numai produsul final, ci şi rezultatele fazelor intermediare ale

dezvoltării sistemului. Nu doar programele sunt supuse testării, ci şi cerinţele
informaţionale şi funcţionale ale sistemului (structurate în faza de analiză), soluţiile
generale de proiectare, specificaţiile detaliate de proiectare (întocmite în fazele
proiectării logice şi fizice), documentaţia sistemului etc. Cele mai grave erori sunt cele
derivate din identificarea incompletă sau formularea greşită a cerinţelor.
Insistăm asupra ultimului principiu prezentat, tocmai pentru că el este, adesea, ignorat în
practică, consecinţele fiind apariţia de costuri suplimentare. De aceea, una dintre activităţile
care trebuie realizată înainte de proiectarea şi implementarea sistemului priveşte verificarea
cerinţelor sistemului. Prin această activitate nu se urmăreşte a stabili dacă cerinţele sunt
corecte sau greşite, ci a determina dacă ele sunt complete. Altfel spus, se stabileşte dacă31:
cerinţele sunt detaliate suficient, astfel încât să permită proiectarea şi implementarea lor;
cerinţele nu intră în contradicţie unele cu altele.
Atingerea obiectivelor urmărite prin verificarea cerinţelor presupune utilizarea a două
metode de lucru: mai întâi se efectuează inspecţia cerinţelor, urmată de schiţarea planului de
testare. Inspecţia cerinţelor presupune efectuarea unor verificări simple asupra documentului
cerinţelor, întocmit la sfârşitul fazei de analiză, pentru a fi siguri că el conţine suficiente detalii
şi că nu există două cerinţe contradictorii. Acestă operaţiune trebuie realizată de autorul
documentului, împreună cu reprezentanţi ai echipelor de proiectare, implementare şi testare.
După finalizarea inspecţiei cerinţelor, echipa de testare va întocmi o schiţă a planului de
testare, prin care se stabileşte cât de detaliat sunt formulate cerinţele. Dacă se constată
dificultăţi în elaborarea testelor pe baza documentaţiei, atunci este de aşteptat că nici
proiectanţii sau programatorii să nu poată implementa aceste cerinţe. În cel mai bun caz, ei vor
încerca să citescă printre rânduri şi să deducă propriile soluţii, care ar putea fi în contradicţie
cu aşteptările utilizatorilor.
6.2.2 Tehnici de testare

Tehnicile de testare au un caracter preponderent euristic şi empiric, mai puţin
fundamentate teoretic, ceea ce explică multitudinea tehnicilor prezentate în literatura de
specialitate. Importantă este alegerea unei strategii prin care să se selecteze tehnicile cele mai
adecvate pentru atingerea obiectivelor definite în faza de planificare a testării. Pentru a fi în
măsură de a alege cele mai potrivite tehnici de testare, este necesară cunoaşterea modalităţilor
de clasificare a lor.
6.2.2.1 Clasificarea tehnicilor de testare
În literatura de specialitate, tehnicile de testare sunt grupate după diverse criterii. Mosley
diferenţiază testele în funcţie de modul în care acestea angajează tehnici dinamice sau statice,
precum şi în funcţie de modul de efectuare, automat sau manual32.
Testarea statică înseamnă verificarea programelor sursă fără ca acestea să fie lansate în
execuţie. Multe din aceste tehnici sunt aplicate la testarea rezultatelor fazelor de analiză şi
proiectare sau a documentaţiei sistemului. Testarea dinamică implică execuţia programelor.
Pornind de la un set de date de intrare se va lansa în execuţie programul şi se vor compara
rezultatele execuţiei programului cu rezultatele scontate.
Testarea automată este efectuată sub controlul calculatorului, în timp ce testarea manuală
se desfăşoară sub controlul omului.
Cele două moduri de clasificare sunt relativ redundante, în sensul că majoritatea tehnicilor
de testare manuală se regăsesc şi în categoria tehnicilor de testare statică, atât timp cât, în
31. Richard, L.K. – Testing Requirements, www.gantthead.com (accesat 18.01.2006).

32. Mosley, D.J. – The Handbook of MIS Application Software Testing, Yourdon Press, Englewood Cliffs, New
Jersey, 1993.
general, tehnicile manuale nu implică execuţia programelor33, iar tehnicile de testare automată
presupun de cele mai multe ori execuţia programelor, deci ele sunt considerate tehnici de
testare dinamică.
În mod tradiţional, există două abordări complementare în testarea programelor, în funcţie
de sursele de informaţii utilizate pentru generarea cazurilor de test. Celor două abordări le
corespund două categorii de tehnici de testare: tehnici tip „cutia neagră” sau tehnici tip „cutia
albă”.
Testarea tip „cutia neagră”, numită şi funcţională, nu ia în considerare detaliile
procedurale interne ale componentei testate, ci urmăreşte funcţiile acesteia. Se vor alege date
de test pentru fiecare funcţie în parte. În cazul unui modul de program, responsabilii testării nu
vor examina instrucţiunile acestuia, ei fiind interesaţi doar de datele de intrare şi rezultatele
aşteptate pentru fiecare funcţie a modulului.
Testarea tip „cutia albă”, numită şi structurală, presupune concentrarea atenţiei asupra
detaliilor procedurale ale componentei testate, pentru a putea determina cazurile de test şi
datele de intrare necesare. Ea implică identificarea cazurilor de test care permit execuţia
tuturor ramurilor programului, derivate din structurile de control alternative şi/sau repetitive.
Prin urmare, se va defini câte un caz de test pentru fiecare ramură logică a programului.
Tehnica testării căilor de bază, ce va fi prezentată în paragraful următor, se încadrează în
această categorie.
Deoarece porneşte de la analiza structurilor de control din specificaţiile procedurale de
proiectare sau codul program, s-ar putea crea impresia că aplicarea aceste testări, tip „cutia
albă”, ar conduce inevitabil către obţinerea de programe 100% corecte şi că testarea de tip
„cutia neagră” ar fi inutilă. Ar putea fi adevărat dacă ar fi posibilă testarea exhaustivă a
programelor (reamintiţi-vă unul din principiile testării enunţate anterior).
Problema poate fi formulată şi din cealaltă perspectivă: de ce trebuie să cheltuim atâta
timp şi energie cu testarea la nivelul detaliilor programelor, în loc să ne concentrăm atenţia
asupra testelor care să vizeze fiecare funcţie a programelor? Aşadar, de ce să ne complicăm cu
testarea tip „cutia albă”, în loc să consumăm toate resursele cu testarea tip „cutia neagră”?
Răspunsul la întrebarea anterioară derivă din natura erorilor întâlnite în programe. Multe
erori apar atunci când se proiectează şi implementează condiţii sau structuri de control care
privesc cazurile speciale ale funcţiei tratate şi care nu fac parte din fluxul logic principal al
programului. Se estimează că numărul erorilor logice este invers proporţional cu probabilitatea
de execuţie a unei ramuri logice a programului34. Erorile de scriere a programelor sursă pot
apărea oriunde în programe, atât în ramurile logice principale, cât şi în cele care tratează
cazurile speciale, ceea ce justifică necesitatea tehnicilor de testare de tip „cutia albă”.
Pe de altă parte, aplicarea tehnicilor de testare de tip „cutia albă” permite identificarea şi
localizarea mai uşoară a erorilor, tocmai datorită faptului că acest tip de testare se desfăşoară la
nivelul detaliilor procedurale. Să ne imaginăm ce dificilă ar fi localizarea unei erori identificate
la testarea unei funcţii a sistemului ce presupune execuţia mai multor module de program. În
plus, noi ştim că rezultatele obţinute nu sunt corecte, dar ar putea fi vorba de mai multe erori şi
nu doar de una singură. Acesta este unul din motivele pentru care strategia de testare trebuie
definită astfel încât să se aplice mai întâi tehnicile de testare tip „cutia albă” şi apoi cele tip
„cutia neagră”.
De regulă, testarea tip „cutia albă” urmăreşte generarea cazurilor de test astfel încât:
• execuţia fiecărei structuri de control alternative pe ambele ramuri;
• execuţia fiecărei structuri de control repetitive, atât la numărul minim, cât şi cel maxim
al iteraţiilor, dar şi a unuia intermediar;
33. van Vliet, H. – Software Engineering. Princples and Practice, Second Edition, John Wiley & Sons, LTD,
Chichester, 2002, p. 399.
34. Jones, T.C. – Programming productivity: Issues for the 80s, IEEE Computer Society Press, 1981, citat în
Presmann, R.S. – op. cit., p. 433.
• verificarea validităţii structurilor de date interne ale programelor.

Testarea de tip „cutia neagră” urmăreşte să răspundă la următoarele întrebări: Cum poate
fi testată validitatea funcţională a aplicaţiei? Cum pot fi testate performanţele aplicaţiei? Ce
volum de date şi ce rată a intrărilor poate accepta sistemul? Ce efect va avea asupra modului de
funcţionare a sistemului o anumită combinaţie a datelor de intrare?
În realizarea acestui tip de testare, un rol important îl au diagramele fluxurilor de date, pe
baza cărora se pot defini clasele de intrări care să permită testarea eficace a fiecărei
tranzacţii/transformări (în funcţie de orientarea sistemului) şi a fiecărui proces în realizarea ei.
Pornind de la diagramele fluxurilor de date, se poate realiza testarea pe baza unor grafuri, în
care nodurile reprezintă procesele necesare unei tranzacţii, iar legăturile reprezintă conexiunile
logice dintre acestea. În cazul sistemelor orientate pe transformări, nodurile reprezintă datele,
iar legăturile dintre noduri reprezintă transformările la care acestea sunt supuse.
În concluzie, testarea tip „cutia neagră” şi cea tip „cutia albă” sunt complementare,
ambele trebuind să fie utilizate pentru o bună testare. De asemenea, de reţinut că nu există o
tehnică de testare sau o categorie de tehnici catalogată drept cea mai bună. Fiecare tehnică este
orientată spre detectarea anumitor tipuri de erori sau atingerii anumitor obiective. Din acest
motiv, se va apela la utilizarea mai multor tehnici, în funcţie de obiectivele propuse, strategia
de testare, complexitatea sistemului informatic, resursele alocate etc.
6.2.2.2 Tehnica testării căilor independente de execuţie
Această tehnică de testare se încadrează în categoria celor tip „cutia albă”. Ea a fost
propusă pentru prima dată în 1976, de Tom McCabe, şi are drept criteriu de acceptabilitate
garantarea execuţiei cel puţin o dată a fiecărei instrucţiuni din program. Aplicarea ei
presupune determinarea indicatorului complexitatea logică a specificaţiilor procedurale, pe
baza căruia se va defini un set de bază al căilor independente de execuţie a programului.
Fiecare cale independentă de execuţie va reprezenta un caz (scenariu) de testare, urmând a fi
determinate datele de test (intrare).
În continuare vom prezenta un exemplu de aplicare a tehnicii testării căilor independente,
pornind de la pseudocodul pentru modulul EvaluareFIFO din caseta 6.2., şi vom urma cei
patru paşi specifici.
1. Construirea grafului fluxurilor logice de control din program,
pe baza pseudocodului sau a programului sursă
Fluxurile logice de control dintr-un program sunt puse în evidenţă într-un graf. Fiecare
nod al grafului, reprezentat printr-un cerculeţ, reprezintă una sau mai multe instrucţiuni
program, iar săgeţile dintre noduri reprezintă fluxurile logice de control din cadrul modulului
de program. Orice săgeată trebuie să aibă la capătul său un nod, chiar dacă este posibil ca unui
nod să nu-i corespundă nici o instrucţiune.
Printr-un nod se poate reprezenta un grup de instrucţiuni secvenţiale şi o instrucţiune care
codifică o structură de control. În cazul în care structura de control conţine o condiţie compusă,
se va crea câte un nod separat pentru fiecare condiţie elementară. O condiţie compusă
reprezintă o expresie logică în care se folosesc unul sau mai mulţi operatori logici (OR, AND).
În caseta 6.2 sunt evidenţiate nodurile care vor apare în graf. În construirea grafului apelează la
notaţiile din figura 6.3.
Caseta nr. 6.2 – Pseudocodul şi nodurile grafului fluxurilor

logice de control pentru modulul EvaluareFIFO
PROCEDURE EvaluareFIFO
* Acest modul realizeaza evaluarea stocurilor la iesire dupa metoda „First In – First Out”
INTERFACE INPUT cMatCod, vCantitate
INTERFACE OUTPUT aConsum, bConsValid
vCantConsum = 0
SELECT DataIntrare,Stoc,Pret;
FROM Stoc ;
INTO ARRAY aStocuri ;
1 WHERE MatCod = cMatCod and Stoc > 0;
ORDER BY DataIntrare
n = ALEN(aStocuri,’ROW’)
DIMENSION aConsum(n,3) 2
i=1
DO WHILE i <= n AND vCantConsum < vCantitate 3
4 IF vCantitate – vCantConsum >= aStocuri(i,2)
INCREMENT vCantConsum BY aStocuri(i,2)
5 aConsum(i,1) = aStocuri(i,1)
aConsum(i,2) = aStocuri(i,2)
ELSE
6 aConsum(i,2) = vCantitate – vCantConsum
vCantConsum = vCantitate
END IF
7
INCREMENT i BY 1
8 END DO
IF vCantConsum < vCantitate 9
bConsValid = FALSE
10
DISPLAY_MESSAGE(„Stocul este insuficient”)
ELSE
11
bConsValid = TRUE
ENDIF
12
END
Secvenţa If Then Else Do Case Do-While
...
..
.
Fig. 6.3 Construcţiile elementare pentru crearea grafului fluxurilor logice de control
Pentru pseudocodul din caseta 6.2, graful fluxurilor logice de control este prezentat în
figura din caseta 6.3.
2. Determinarea complexităţii logice a programului pe baza grafului
Complexitatea logică a programului (cyclomatic complexity) trebuie determinată în
vederea stabilirii numărului căilor independente de execuţie. O cale independentă de execuţie a
programului reprezintă orice cale din program care implică cel puţin un nod nou (adică un grup
nou de instrucţiuni sau o condiţie nouă), adică el nu a fost inclus în căile definite anterior.
Complexitatea logică poate fi determinată în mai multe moduri. Unul dintre acestea are la
baza formula: Cl = P + 1, în care P reprezintă numărul nodurilor predicative din graful
fluxurilor de control. Un nod predicativ este acela care conţine o condiţie logică (un predicat).
Prin urmare, în graf, din fiecare nod predicativ vor pleca cel puţin două săgeţi.
În exemplul luat, avem patru noduri predicative, respectiv nodurile 2, 3, 4 şi 9. În graful

din caseta 6.3 se observă că pentru fiecare din cele patru noduri există cel puţin două fluxuri
care pleacă din acel nod.
Caseta nr. 6.3 – Graful fluxurilor logice de control pentru modulul EvaluareFIFO
1
3
9
4
10 11
5 6
12
7
Aplicând formula prezentată anterior, rezultă că pentru modulul EvaluareFIFO,

complexitatea logică este 5 (adică 4 + 1).
Valoarea indicatorului complexitatea logică a programului determină numărul cazurilor de
test care trebuie efectuate astfel încât să fie garantată execuţia cel puţin o dată a fiecărei
instrucţiuni din program. Aşadar, pentru modulul EvaluareFIFO sunt necesare cinci cazuri de
test.
3. Determinarea căilor independente de execuţie
În graful fluxurilor de control, o cale independentă trebuie să conţină cel puţin un nod ce
nu a fost inclus într-o altă cale definită anterior. Cele cinci căi independente de execuţie sunt
prezentate în caseta 6.4.
Caseta nr. 6.4 – Căile independente de execuţie
pentru modulul EvaluareFIFO
Calea 1: 1-2-9-10-12
Calea 2: 1-2-9-11-12
Calea 3: 1-2-3-9-10-12
Calea 4: 1-2-3-4-5-7-8-2-.....
Calea 5: 1-2-3-4-6-7-8-2-.....
4. Definirea cazurilor de test pentru fiecare cale independentă

Definirea unui caz de test implică stabilirea datelor de intrare corespunzătoare condiţiilor
specificate în nodurile predicative şi a rezultatelor aşteptate. În modulul EvaluareFIFO se
observă că, în afara celor doi parametri, codul materialului (cMatCod) şi cantitatea consumată
(vCantitate), mai există o intrare, ce corespunde accesării tabelei STOCURI, realizată prin fraza
SELECT. Prin urmare, la definirea datelor de test vor fi avute în vedere şi starea bazei de date.
În caseta 6.5 sunt prezentate datele de test pentru calea 4 de execuţie.
Caseta nr. 6.5 – Datele de test a modulului EvaluareFIFO pentru testarea căii 4
1. Datele de intrare
cCodMat = „100001”
vCantitate = 100
În tabela STOCURI există următoarele înregistrări:
MatCod DataIntrare Stoc Pret
100001 20/01/2006 50 125.00
100001 06/02/2006 65 126.00
100001 13/02/2006 40 126.50
2. Rezultatele aşteptate
bConsValid = True
Valorile pentru tabloul aConsum: 20/01/2006 50 125.00
06/02/2006 50 126.00
În final, se vor executa toate cazurile de test, iar rezultatelor testării vor fi consemnate
într-o documentaţie.
6.2.2.3 Testarea structurilor de control repetitive.
Structurile repetitive stau la baza majorităţii algoritmilor implementaţi în programe. Din
punctul de vedere al testării, ele pot fi împărţite în trei categorii, prezentate în figura 6.4:
simple, imbricate şi concatenate. Regulile de testare a structurilor repetitive se încadrează în
tehnicile tip „cutia albă”.
structuri structuri structuri

repetitive repetitive repetitive
simple imbricate concatenate
Fig. 6.4 Tipuri de structuri de control repetitive

În cazul structurilor repetitive simple, considerând n – numărul maxim de iteraţii, trebuie
realizate următoarele teste: nici o iteraţie (adică nici o trecere prin bucla respectivă), o singură
trecere, două treceri, m treceri (unde m<n), n-1, n, n+1 treceri.
Pentru structurile repetitive imbricate, numărul testelor posibile creşte în progresie
geometrică cu nivelul de imbricare. Reducerea numărului de teste se poate realiza astfel:
1. Se porneşte cu structura repetitivă de pe nivelul cel mai mare de imbricare (prima din
interior), configurându-se celelalte structuri la numărul minim de iteraţii. Pentru
această structură de control se realizează testele specifice structurii repetitive simple,
amintită anterior.
2. Se continuă testele specifice structurii repetitive simple, pentru testarea structurii de
control situate pe nivelul următor de imbricare, păstrându-se structurile de control
situate deasupra sa la numărul minim de iteraţii şi valorile tipice pentru cele situate
dedesubt.
3. Se continuă în aceeaşi manieră până când se testează toate structurile de control.
Structurile repetitive concatenate pot fi testate în maniera descrisă în cazul structurilor

simple, dacă fiecare structură de control este independentă de celelalte, sau asemănător celor
imbricate, dacă structurile de control nu sunt independente. Două structuri de control
concatenate nu sunt independente atunci când condiţiile conţinute de cele două structuri sunt
legate între ele. Aşa este cazul a două structuri de tip FOR, în care contorul primei structuri de
control este utilizat ca valoare iniţială pentru cea de-a doua structură.
6.2.2.4 Examinările şi execuţiile de probă
Ambele tehnici de testare sunt manuale, iar aplicarea lor presupune constituirea unor
echipe speciale care vor evalua programele şi specificaţiile procedurale în cadrul unor sesiuni
formale de lucru, urmându-se anumite proceduri clar definite.
Examinările presupun evaluarea programelor linie cu linie în vederea depistării manuale a
unor erori frecvent întâlnite, fără a se urmări efectul fiecărei instrucţiuni. De aceea, este
necesară întocmirea unei liste de control cu erorile tipice întâlnite în activităţile de proiectare şi
programare. Exemple de erori sunt:
• Utilizarea greşită a structurilor de date: referirea unor variabile neiniţializate sau
chiar nedeclarate, depăşirea dimensiunii unui tablou de date etc;
• Erori în expresiile de calcul: împărţirea la 0, utilizarea unor variabile de tipuri diferite
în aceeaşi expresie fără a se apela la funcţiile de conversie, nerespectarea ordinii de
prioritate a operatorilor, plasarea eronată a parantezelor, rotunjirea zecimalelor şi nu
truncherea şirului de cifre pentru partea fracţionară (în calcule foarte exacte, cum sunt
cele ştiinţifice sau pentru stabilirea mediilor în sistemele educaţionale) etc;
• Erori legate de fluxul logic de control: structuri de control repetitive infinite, blocuri
de instrucţiuni ce nu vor putea fi executate niciodată etc;
• Erori la nivelul interfeţelor: utilizarea unui număr incorect de parametri sau a unor
parametri al căror tip nu este corespunzător etc.
În general, o echipă de examinare este formată din patru membri, fiecare cu roluri bine
definite. Moderatorul este responsabil pentru organizarea şedinţelor de lucru, le conduce,
asigură ca fiecare participant să urmeze procedurile stabilite astfel încât aceştia să lucreze ca o
echipă. Echipa mai conţine doi inspectori (examinatori) care vor interpreta programul sursă.
Din echipă va face parte şi programatorul, respectiv cel ce a scris codul (programul sursă),
deoarece acesta cunoaşte cel mai bine programul şi poate fi solicitat de inspectori să explice ce
a intenţionat să facă atunci când aceştia consideră că ceva este greşit, neclar sau nu
funcţionează corect.
Membrii echipei de examinare vor primi programele sursă, specificaţiile de proiectare şi
documentaţia asociată cu câteva zile înainte de desfăşurarea sesiunii de lucru. În timpul
şedinţelor de lucru, examinatorii vor interpreta liniile de program, mai multe linii deodată, iar
pe baza comentariilor şi întrebărilor formulate se vor descoperi eventualele greşeli. De
asemenea, programele vor fi analizate pe baza listei de control a erorilor tipice. Rezultatele
sesiunii de examinare vor fi consemnate într-o listă a problemelor identificate. Aceste
probleme nu vor fi rezolvate în cadrul şedinţelor de examinare pentru a nu distrage atenţia
membrilor echipei de la obiectivul principal, respectiv identificarea erorilor. Lista cu
problemele identificate va fi înmânată pentru rezolvare programatorilor care au scris codul.
Execuţia de probă, spre deosebire de examinări, presupune analiza programelor prin
urmărirea efectului fiecărei instrucţiuni pe baza unor date de test. Datele de test alese sunt de
cele mai multe ori simple, astfel încât să nu facă dificilă urmărirea programului. De fapt, datele
de test vor servi mai mult drept punct de pornire a discuţiilor decât unei testări riguroase. Pe
parcursul sesiunii de lucru, proiectantul poate fi solicitat să argumenteze şi să explice deciziile
sale.
Ambele tehnici de testare pot fi aplicate în cadrul tuturor fazelor de dezvoltare a

sistemului informatic, şi nu doar în faza de implementare, cu condiţia existenţei unei
documentaţii clare.
În afară de numărul mare de erori descoperite prin urmărirea atentă a programelor (după
unele estimări între 60% şi 90%)35, ambele tehnici prezintă şi alte avantaje: promovarea
spiritului de echipă; membrii unei echipe pot învăţa unii de la alţii şi pot acumula cunoştinţe
noi privind tehnicile şi stilurile de programare, erorile tipice care pot să apară la scrierea
programelor etc.
6.2.3 Strategia testării sistemelor informatice

Testarea presupune un grup de activităţi care trebuie planificate din timp şi realizate în
mod sistematic. În acest sens, este necesară definirea unui cadru de desfăşurare a fazei de
testare, ca parte a demersului dezvoltării sistemelor informatice. Acest cadru se concretizează
în strategia testării. Strategia testării sistemelor informatice integrează diferitele metode de
concepere a cazurilor de test, într-o succesiune de paşi bine planificaţi, astfel încât să fie
asigurată dezvoltarea unui sistem informatic de calitate.
Orice strategie de testare trebuie să aibă următoarele caracteristici generale:
1. Testarea începe de jos, de la nivelul modulelor, şi se încheie prin validarea sistemului
informatic ca un tot. În faza de proiectare, sistemul este descompus în mai multe module
organizate ierarhic, obţinându-se arhitectura sistemului, pe baza căreia se va realiza şi
faza de testare. Se va începe cu testarea modulelor, după care se va viza maniera de
integrare a acestora, conform arhitecturii definite în faza de proiectare, numită testarea
integrării. După testarea integrării, urmează testarea sistemului, moment în care
programele şi alte elemente componente ale sistemului sunt testate ca un tot, în funcţie de
cerinţele funcţionale şi restricţiile definite în faza de analiză. Se încheie cu testarea de
acceptare, prin implicarea directă a utilizatorilor. Cele patru etape vor fi prezentate
succint în paragrafele următoare.
2. Diferitele tehnici de testare trebuie aplicate în anumite momente ale testării. Dacă la
testarea modulelor se utilizează cu precădere tehnicile tip „cutia albă”, în timpul testării
integrării vor fi utilizate mai mult tehnicile tip „cutia neagră”. Testarea sistemului şi
testarea de acceptare implică aproape în exclusivitate apelarea la testarea tip „cutia
neagră”, urmărindu-se verificarea funcţionalităţii, comportamentului şi performanţelor
sistemului, precum şi dacă sistemul corespunde exigenţelor utilizatorilor.
3. Testarea este realizată de către o echipă independentă, în cazul proiectelor mari sau de
membrii echipei de dezvoltare a sistemului, în cazul proiectelor de mai mică amploare.
Pentru orice proiect de dezvoltare a sistemelor informatice, faza de testare implică
anumite conflicte de interese inerente. Pe de o parte, pare evident că cei mai potriviţi,
pentru a realiza testarea, sunt proiectanţii şi programatorii, adică cei care cunosc cel mai
bine sistemul. Pe de altă parte, aceştia vor încerca să demonstreze că programele nu
conţin erori, iar prin testele proiectate vor demonstra că sistemul funcţionează conform cu
cerinţele formulate.
În general, proiectanţii şi programatorii sunt responsabili atât pentru testarea modulelor,
cât şi pentru testarea integrării modulelor, iar ultimele două etape vor fi realizate de o echipă
independentă.
6.2.3.1 Testarea modulelor
Scopul principal urmărit prin testarea la nivelul modulelor constă în identificarea şi
corectarea unui număr cât mai mare de erori, înainte de integrarea modulelor în unităţi de
program mai complexe, în care erorile sunt mult mai greu de localizat şi corectat.
35. Oprea, D. – Analiza şi proiectarea sistemelor informaţionale economice, Editura Polirom, Iaşi 1999, p. 481.
În acest moment al testării sunt implicate mai multe tehnici de testare, în funcţie de
aspectele urmărite. De regulă, se începe cu testarea la nivelul interfeţelor modulului, pentru a
se asigura că intrările şi ieşirile în/din modul sunt corecte, înainte de a se efectua alte teste
asupra modulului. Urmează testarea structurilor de date locale, prin care se verifică
integritatea datelor memorate temporar de-a lungul ramurilor de execuţie din modulul
respectiv.
Cele mai importante teste, dintre cele efectuate la nivelul modulelor, sunt cele care
vizează căile de execuţie a programului. Prin testarea căilor de execuţie se urmăreşte
depistarea erorilor legate de calcule greşite, comparaţii greşite în expresiile logice, controlul
logic necorespunzător al execuţiei etc. Foarte utile, în acest scop, sunt tehnica testării căilor de
bază şi testarea structurilor de control repetitive. Testarea modulelor se încheie cu analiza
valorilor limită. Deşi sunt puţine explicaţii, majoritatea erorilor apar la extremităţile
domeniului de valori pentru datele de intrare şi nu în mijlocul acestui domeniu. De exemplu,
apar erori la execuţie, atunci când se invocă ultima iteraţie dintr-o structură repetitivă, se
prelucrează ultimului element dintr-un tablou de date etc. Din acest motiv, se impune reluarea
testelor privind structurile de date şi fluxul logic de control, însă vor fi utilizate alte cazuri de
test, prin care se va urmări exersarea valorilor limită ale domeniului.
Testarea modulelor mai are o particularitate. După cum se ştie, un modul nu este de sine-
stătător, el fiind plasat undeva în structura ierarhică a programului, de unde este apelat de
modulele de pe nivelul ierarhic superior, după cum, la rândul său, poate apela unele module
situate pe nivelul ierarhic inferior, pentru a-şi putea realiza funcţia. În aceste condiţii, aplicarea
tehnicilor de testare dinamică este de cele mai multe ori imposibilă. Pentru a se evita acest
neajuns, pentru fiecare modul testat, se vor concepe două tipuri speciale de module: module
subordonate (stub module) şi module director (drive module).
Un modul director este văzut ca un program principal al cărui rol constă în a simula
condiţiile normale de exploatare a programului în care va fi executat modulul testat. Funcţiile
lui privesc acceptarea datelor de test, transmiterea lor către modulul ce trebuie testat şi afişarea
rezultatelor relevante ale testării. Un modul subordonat are rolul de a înlocui un modul invocat
de modulul testat, el fiind un subprogram care va avea aceeaşi interfaţă ca şi modulul pe care-l
înlocuieşte, va realiza un minim de prelucrări, va semnala faptul că el a fost apelat, după care
va reda controlul modulului testat.
Testarea modulelor este simplificată, cu atât mai mult, cu cât coeziunea lor este mai mare.
Dacă un modul este caracterizat de o coeziune funcţională, deci el a fost proiectat să realizeze
o singură funcţie, atunci numărul testelor necesare este mai redus, iar erorile pot fi mai uşor
descoperite.
6.2.3.2 Testarea integrării
Ajunşi în această etapă, unii s-ar putea întreba: De ce mai este necesară testarea integrării
modulelor, atât timp cât fiecare modul a fost testat individual şi se presupune că ele
funcţionează ireproşabil? Răspunsul este cât se poate de simplu: pentru că pot apărea alte erori,
care nu pot fi depistate prin testarea la nivelul modulelor. Anumite date se pot pierde, prin
transmiterea lor de la un modul la altul, sau execuţia unui modul poate avea efecte negative
asupra altui modul. De asemenea, integrarea subfuncţiilor realizate de diferite module poate să
nu ducă la obţinerea funcţiei dorite sau se pot ivi unele probleme la utilizarea structurilor de
date globale. Lista ar putea continua.
Integrarea modulelor se poate face treptat, modul cu modul, sau deodată. Strategia
integrării treptate presupune construirea şi testarea programului în paşi mici, astfel încât erorile
să fie uşor de localizat şi corectat, interfeţele să fie cât mai complet testate, iar întreaga
activitate de testare a integrării modulelor să fie desfăşurată de o manieră sistematică. În
opoziţie cu această strategie, integrarea deodată a modulelor presupune construirea
programului prin integrarea modulelor componente urmată de testarea programului ca un tot.
Această strategie nu este recomandată deoarece face dificilă localizarea şi corectarea erorilor.
Testarea integrării se poate face atât de sus în jos (top-down) , cât şi de jos în sus (bottom-
up). Integrarea şi testarea modulelor de sus în jos (top-down) începe cu modulul principal,
după care se continuă, prin parcurgerea în jos a structurii ierarhice a programului, în două
modalităţi posibile: integrarea orientată pe verticală sau integrarea orientată pe orizontală.
Integrarea orientată pe verticală presupune integrarea tuturor modulelor componente pe
câte o ramură a structurii ierarhice. Integrarea orientată pe orizontală presupune reunirea mai
întâi a modulelor situate pe nivelul ierarhic imediat inferior modulului principal şi se continuă
cu fiecare nivel ierarhic.
Aplicarea integrării top-down impune utilizarea modulelor subordonate. Se începe prin
testarea modulului principal, considerat ca modul director, iar modulele de pe nivelul ierarhic
inferior vor fi înlocuite cu module subordonate. Acestea din urmă vor fi eliminate şi înlocuite
cu modulele reale, pe măsură ce se înaintează cu testarea
După cum sugerează şi numele, testarea integrării de-jos-în-sus presupune construirea şi
testarea treptată a programului, începând cu modulele de pe ultimele niveluri ierarhice. În acest
caz, se va apela la înlocuirea modulelor de program cu module director. Această abordare se
desfăşoară după următorul scenariu: modulele situate pe ultimele niveluri ierarhice sunt
grupate astfel încât fiecare grup de module să realizeze o subfuncţie a programului; apoi se
creează câte un modul director pentru fiecare grup de module şi pe baza căruia se va testa
fiecare grup în parte; după ce testarea fiecărui grup de module s-a încheiat, se elimină
modulele director şi se regrupează modulele prin înglobarea celor situate pe nivelul imediat
superior. Acest proces va fi reluat până la construirea şi testarea întregului program.
În practică, cele două abordări sunt utilizate împreună, fiecare prezentând avantaje şi
dezavantaje specifice. Principalul beneficiu obţinut poate consta în reducerea numărului de
module director şi subordonate care trebuie create.
6.2.3.3 Testarea la nivelul sistemului
Deşi testarea la nivelul sistemului poate părea similară cu testarea integrării, ea diferă prin
orientarea testelor spre acele caracteristici nespecifice componentelor programului, cum ar fi:
performanţele sistemului, securitatea, refacerea în cazul apariţiei unor căderi ale sistemului etc.
De asemenea, testarea sistemului diferă de testele anterioare prin luarea în considerare şi a
celorlalte componente ale sistemului, în afară de programe. Aceste teste vor verifica dacă
elementele componente ale sistemului – hardware, software, oameni şi date - sunt integrate
corespunzător şi realizează funcţiile prevăzute.
Testele concepute în această fază pot fi împărţite în patru categorii, în funcţie de scopul
urmărit36:
• Testarea refacerii urmăreşte să forţeze căderea sistemului din diferite cauze şi să
verifice dacă refacerea este realizată corespunzător. Dacă refacerea este realizată
automat de către sistemul însuşi, vor fi verificate reiniţializarea sistemului, refacerea
datelor şi alte aspecte. Dacă refacerea implică intervenţia beneficiarului, va fi evaluată
perioada de timp necesară pentru repunerea sistemului în funcţiune.
• Testarea securităţii urmăreşte să verifice dacă mecanismele de protecţie ale sistemului
funcţionează corespunzător împotriva încercărilor de atac asupra sistemului sau a
accesării neautorizate.
• Testarea solicitării sistemului presupune confruntarea sistemului cu situaţii anormale,
testele anterioare vizând modul de funcţionare a programelor în condiţii normale de
lucru. Prin testele concepute, execuţia programelor va solicita resurse în cantităţi,
volume sau frecvenţe anormale. De exemplu, pot fi concepute teste pentru situaţiile în
care volumul şi rata datelor de intrare creşte de un anumit număr de ori faţă de
situaţiile normale, teste în care timpul de căutare şi citire a datelor de pe disc este
foarte mare etc.
36. Presmann, R.S. – op. cit., pp. 483-485.

• Testarea performanţelor sistemului este adesea combinată cu testarea solicitării

sistemului şi ia în considerare performanţele tehnice ale hardware-ului şi software-ului.
În principiu, testarea sistemului va include toate activităţile specifice testării de acceptare,
însă va fi realizată fără implicarea utilizatorilor. Astfel, se oferă ocazia ultimelor verificări şi
modificări înainte de prezentarea sistemului în faţa beneficiarului.
6.2.3.4 Testarea de acceptare
Testarea de acceptare reprezintă ultima ocazie de verificare a sistemului, înainte de a fi
dat în exploatare. Spre deosebire de testele anterioare, testarea de acceptare trebuie să se
desfăşoare într-un mediu similar celui în care va fi pus în funcţiune şi de către persoanele care
îl vor utiliza. Ea este realizată din perspectiva utilizatorului, ceea ce înseamnă că, prin testele
concepute, vor fi exersate funcţiile aplicaţiei orientate spre utilizator.
Testarea de acceptare trebuie planificată încă din primele faze ale dezvoltării sistemului,
începând cu analiza. Dacă planificarea testării de acceptare începe din faza de analiză, atunci,
în paralel cu definirea cerinţelor sistemului, se va stabili şi modul în care fiecare cerinţă poate
fi testată cât mai bine. Mai mult, dacă o anumită cerinţă este dificil de testat şi de întreţinut,
atunci utilizatorului i se pot oferi unele explicaţii care să-l determine să renunţe la acea cerinţă.
Testarea de acceptare presupune, de regulă, două etape: testarea alfa şi testarea beta.
Testarea alfa este realizată de client la sediul producătorului, sub supravegherea specialiştilor
din echipa de dezvoltare a sistemului, şi sunt utilizate date nereale, dar reprezentative. În
schimb, testarea beta se desfăşoară la sediul clientului, fără ca utilizatorii să mai fie
supravegheaţi de membrii echipei de dezvoltare a sistemului, utilizându-se date reale. De fapt,
testarea beta reprezintă un fel de repetiţie generală înaintea exploatării propriu-zise a
sistemului.
6.3 Documentarea sistemului
Documentaţia sistemului informaţional reprezintă un element de comunicare, control şi

monitorizare a proiectului de dezvoltare, exploatare şi întreţinere. În acelaşi timp,
documentaţia trebui privită şi ca unul dintre rezultatele etapelor ciclului de viaţă al sistemului,
regăsind în structura sa: documentaţia microanalizei, specificaţiile de analiză, documentaţia
proiectării şi implementării, manualul de utilizare şi operare. Ca urmare, documentaţia
sistemului este importantă, atât din punct de vedere al managementului proiectelor, cât şi al
dezvoltării şi utilizării lui. Cel mai adesea, din nefericire, în practică, documentaţia fie este
incompletă, fie lipseşte în totalitate.
Nu de puţine ori auzim în rândul specialiştilor sistemelor informaţionale afirmaţii de
genul: „nu putem modifica programul, pentru că nu ştim cum a fost gândit”, „nu putem
interveni pe schema bazei de date, pentru că nu este clar modul în care a fost proiectată”, „nu
putem include un nou modul în aplicaţie, pentru că nu există nimic legat de structurarea
aplicaţiei” etc. Astfel de situaţii apar când sistemul aflat în exploatare necesită modificări sau
îmbunătăţiri, dificil de efectuat, luându-se, în majoritatea cazurilor, decizia de a se iniţia un
nou proiect de dezvoltare, ştiindu-se că e mult mai uşor să faci ceva de la început decât să
modifici ceva existent. Dar, care este motivul pentru care se trece, în contextul prezentat, la
dezvoltarea unui nou sistem? Unul din răspunsuri îl constituie documentaţia, în sensul că fie nu
există, fie este incompletă sau neactualizată, şi, ca atare, nu poate fi folosită în procesul de
întreţinere a sistemului. Mai mult, documentaţia sistemului se poate transforma într-un factor
de eşec al proiectelor, având în vedere că trecerea de la o etapă la alta, în cadrul ciclului de
dezvoltare, are loc pe baza informaţiilor colectate în cadrul specificaţiilor elaborate la sfârşitul
fiecărei etape, ca un rezultat parţial al proiectului.
Documentaţia este privită, deseori, numai din perspectiva existenţei unui volum
suplimentar de informaţii la dispoziţia organizaţiei şi a echipei proiectului, care, după părerea
unora, îngreunează şi prelungeşte derularea unui proiect. Această opinie ar putea fi acceptată
dacă se are în vedere viteza şi stringenţa cu care se solicită modificarea sau înlocuirea
sistemelor. Însă, o astfel de poziţie poate să aibă, pe termen lung, un efect destul de costisitor.
6.3.1 Consideraţii generale privind documentarea sistemului

Documentaţia unui proiect reprezintă atât un instrument de înregistrare a diferitelor
decizii şi acţiuni pe care le implică ciclul de viaţă al unui proiect, cât şi mijlocul prin care se
documentează şi justifică deciziile şi acţiunile. Crearea documentelor poate să ajute echipa
proiectului în desfăşurarea activităţilor şi atingerea obiectivelor stabilite, reprezentând suportul
pentru obţinerea aprobărilor necesare desfăşurării etapelor, alocării resurselor, efectuării
controlului din partea managerului de proiect sau a finanţatorului.
Aşadar, orice proiect, deci şi cel de dezvoltare a unui sistem informaţional, are la bază o
documentaţie, constituită dintr-o serie de documente, elaborată pe parcursul ciclului de viaţă al
proiectului. Fiecare etapă a proiectului, în mod normal, ar trebui să se finalizeze cu un set de
documente, folosit ca punct de plecare în luarea deciziilor de continuare a proiectului, a
modului în care se vor desfăşura activităţile specifice fazelor următoare, precum şi a măsurilor
necesare pentru încadrarea în timp şi buget, dacă se constată o depăşire a acestora, sau de
modificare a specificaţiilor iniţiale ale proiectului. Cu alte cuvinte, documentaţia fiecărei etape
permite, pe de o parte, realizarea monitorizării şi controlului proiectului, iar, pe de altă parte,
derularea etapelor prevăzute în planul iniţial.
Documentaţia proiectului poate fi structurată, în funcţie de etapa din proiect la care se
face referire, şi anume37:
Pentru etapa de concepere a planului proiectului specific este, după cum arată şi numele,
planul proiectului – document oficial, aprobat şi folosit pentru gestiunea şi controlul execuţiei
proiectului, fiind o colecţie de documente ce pot fi schimbate în timp, pe măsură ce se obţin
mai multe informaţii. Planul proiectului are o structură destul de elaborată, fiind elementul
esenţial în conducerea proiectului. Alături de planul proiectului, în urma conceperii lui, se mai
obţin şi alte detalii ajutătoare, care cuprind: documentaţia obţinută pe parcursul conceperii
proiectului (de exemplu, ipoteze ce nu au fost prevăzute anterior); specificaţii şi proiecte
tehnice, dacă sunt necesare; documentaţia pentru standardele folosite în aprecierea calităţii
proiectului.
În cadrul etapei de execuţie a proiectului se vor genera numeroase rapoarte, care scot în
evidenţă modul în care au fost parcurse activităţile, cum au fost respectate standardele de
calitate impuse, încadrarea în buget şi timp, cererile de efectuare a schimbărilor la nivel de
proiect, autorizările necesare pentru efectuarea lucrărilor etc. La acestea se adaugă toate
formularele şi documentele utilizate pentru evidenţa alocării şi utilizării resurselor, a
rezultatelor obţinute, pentru urmărirea contractelor etc.
Pentru etapa de control al schimbărilor, ca documente, sunt specifice planul proiectului
actualizat şi prognozele privind viitorul proiectului.
În cadrul închiderii proiectului apar ultimele reglări contractuale, inclusiv decizii pentru
unele probleme care au rămas nerezolvate, precum şi raportul de finalizare a proiectului, ce
conţine o prezentare sintetică a modului de desfăşurare a proiectului, a modificărilor ce au
apărut pe parcurs, a rezultatelor obţinute.
Conţinutul documentaţiei proiectului diferă şi în funcţie de categoriile de persoane
implicate, după cum urmează38:
37. Oprea, D. – Managementul proiectelor. Teorie şi cazuri practice, Editura Sedcom Libris, Iaşi, 2001, pp. 105-
109.
38. *** – Project Management – Guidelines, www.projectmanagement.tas.gov.au (accesat 06.07.2004).
• la nivelul comitetului de aprobare sau a finanţatorului proiectului ar trebui să se

regăsească propunerea de proiect, cu justificarea necesităţii lui, studiul de fezabilitate,
planul proiectului, rapoartele privind evoluţia proiectului;
• pentru beneficiarul rezultatelor proiectului apar ca necesare analiza cost/beneficiu,
schiţa şi planul proiectului, documentaţia privind modul de utilizare a rezultatelor;
• pentru echipa proiectului sunt necesare următoarele piese din documentaţie: planul
proiectului, documentele de justificare a resurselor folosite, rapoartele privind evoluţia
proiectului, documentaţia obţinerii rezultatelor prevăzute prin proiect, contractele cu
furnizorii sau firmele de consultanţă, cererile aprobate de modificare a anumitor
aspecte din planul de bază etc.
Documentaţia sistemului este un produs/rezultat al derulării unui proiect, al cărui scop
este de a comunica informaţiile despre proiect şi sistem tuturor celor interesaţi, de la
finanţatori, utilizatori, specialişti şi până la conducerea organizaţiei unde se va implementa
noul sistem.
Cu toate că există similitudini între documentaţia proiectului şi documentaţia sistemului
informaţional, este necesar să se facă distincţie între ele, chiar dacă cea din urmă face parte
integrantă din prima.
Şi în cazul documentaţiei sistemului informaţional, se poate apela la cele două criterii de
clasificare, respectiv etapele care se desfăşoară pentru construirea lui şi categoriile de persoane
care solicită sau cărora trebuie să li se transmită diferite informaţii despre stadiul de
dezvoltare.
După etapele ciclului de viaţă al sistemului, putem identifica39:
1. documentaţia microanalizei de sistem, care conţine un set de documente, obţinute în
timpul iniţierii proiectului sau existente deja, dintre care mai importante sunt: planul
strategic de dezvoltare a sistemului la nivelul organizaţiei, cererea de dezvoltare a
sistemului, rapoartele de prefezabilitate şi fezabilitate, planul detaliat al proiectului
iniţiat, planificarea calendaristică a proiectului, planul şi procedurile manageriale şi de
comunicare, planul resurselor, bugetul preliminar al proiectului;
2. specificaţiile sau documentaţia de analiză, reprezentând o formalizare a rezultatelor
obţinute în această fază. Scopul său îl constituie comunicarea rezultatelor celor
interesaţi, servind şi ca reper pentru etapele următoare, în primul rând pentru cea de
proiectare. Ca urmare, o descriere foarte precisă, chiar matematică, este preferată de
cele mai multe ori, dar trebuie să se ţină cont de faptul că specificaţia trebuie să fie
uşor de înţeles şi de către utilizatorii sistemului, ceea ce înseamnă apelarea la un
limbaj natural şi la o serie de imagini, mult mai uşor de perceput şi înţeles;
3. documentaţia de proiectare, prin care se detaliază modul de dezvoltare a sistemului
pentru a răspunde cerinţelor din specificaţiile de analiză. În setul de documente ale
acestei etape, ar trebui să se regăsească descrierea sau modelul tuturor intrărilor şi
ieşirilor sistemului, proceselor de prelucrare, interfeţelor-utilizator. Este indicat să fie
incluse, ori de câte ori este posibil, exemple de ecrane/formulare pentru preluarea
datelor, proceduri de control sau de interacţiune a utilizatorului cu sistemul. De
asemenea, sunt prezentate elementele privind modul de organizare a modulelor
programelor şi aplicaţiilor, a procedurilor de control şi asigurare a securităţii
aplicaţiilor şi datelor, structurarea bazei de date, procedurile de prelucrare distribuită
etc. Multe dintre componentele documentaţiei de proiectare sunt necesare specialiştilor
ce vor participa la desfăşurarea următoarei etape, având un pronunţat caracter tehnic,
dar ele se adresează şi utilizatorilor, pentru că pot ajuta la demonstrarea facilităţilor
oferite de sistem şi a modului în care se poate interacţiona cu el;
39. Oprea, D., Meşniţă, G. – „Documentaţia sistemelor informaţionale – problemă a managementului proiectelor?”,
în vol. Societatea informaţională: Educaţie, Cercetare, Sisteme informaţionale, Tehnologii Informaţionale,
Editura ETP Tehnopress, Iaşi, 2004, pp. 110-111.
4. documentaţia implementării, în care sunt cuprinse elementele specifice planificării

implementării, comentariile privind generarea codului programelor, tipurile de testări
şi rezultatele testelor, procedurile de conversie a sistemului etc. Tot acum se dezvoltă
şi documentaţia utilizatorului şi documentaţia tehnică a sistemului.
Din perspectiva participanţilor la proiectul de dezvoltare a sistemului, identificăm două
mari categorii de specificaţii :
1. documentaţia utilizatorului, care cuprinde documentele necesare stabilirii cerinţelor
sistemului şi pentru aprobarea diferitelor prototipuri sau specificaţii de proiectare,
precum şi manualul de utilizare. Prin manualul de utilizare sunt descrise principalele
elemente privind funcţionarea sistemului, modul în care se poate interacţiona cu el,
particularităţile fiecărui modul al aplicaţiei, apelarea la sistemul de ajutor, modul de
corectare a eventualelor erori, nivelurile de acces acordate diferitelor categorii de
utilizatori etc;
2. documentaţia tehnică a sistemului, în care sunt incluse manualul de prezentare adresat
conducerii, din care trebuie să rezulte imaginea generală a sistemului, însoţită de o
descriere succintă a fiecărei componente funcţionale, precum şi manualul de operare.
În manualul de operare sunt prezentate condiţiile de exploatare a sistemului, pe baza
cărora se poate intervine pentru eliminarea eventualelor erori nedepistate în timpul
testării sistemului, adăugarea unor componente noi sau îmbunătăţirea celor existente.
6.4 Conversia sistemului
Procesul de trecere de la vechiul la noul sistem se numeşte conversie. Ea se finalizează

când noul sistem devine perfect funcţional în unitate. Pentru a minimiza problemele,
planificarea conversiei trebuie să demareze de îndată ce se cunoaşte natura noului sistem,
înaintea fazei de implementare. Acţiunile fazei de conversie sunt similare celor din etapa de
implementare, ceea ce înseamnă că se vor stabili şi în acest caz responsabilităţi de execuţie a
fiecărei activităţi.
Există mai multe tipuri de conversii. Înlocuirea unor echipamente uzate cu altele noi
presupune conversia acestora. Dacă noul sistem va schimba atât tipurile de activităţi, cât şi
secvenţa lor de execuţie, se impune o procedură de conversie. Similar, programele pot fi
supuse operaţiunii de conversie. Dar ,cea mai dificilă problemă privind conversia este trecerea
datelor dintr-un sistem în altul.
Se utilizează patru metode de conversie: directă, paralelă, pe faze, pe module.
Conversia directă poartă şi denumirea de „arderea podului”. Ea constă în renunţarea, la
un moment dat, la vechiul sistem şi trecerea la cel nou. Există un mare risc: dacă noul sistem
nu funcţionează corect, vechiul sistem nu mai există. Un alt factor de risc constă în faptul că nu
există posibilitatea de a verifica funcţionalitatea noului sistem, în sensul că nu poate fi realizată
o comparaţie între ieşirile noului sistem cu ale celui vechi.
Firmele apelează la această metodă pentru implementarea produselor-program
achiziţionate, pentru că ele implică un risc de eşec mai mic. Pentru sistemele dezvoltate în
interior, majoritatea firmelor folosesc metoda, dacă instalarea sistemului nu ridică mari
probleme. De asemenea, este necesară atunci când mediile de exploatare ale celor două sisteme
(vechi şi nou) nu sunt compatibile. O altă situaţie care favorizează apelarea la metoda directă
este cea a sistemelor implementate în mijlocul unui exerciţiu de gestiune şi, pentru că trebuie
obţinute diferite rapoarte la perioade exacte de timp, sistemul trebuie să fie pregătit pentru
generarea lor.
Conversia paralelă constă în funcţionarea paralelă a celor două sisteme o perioadă de
timp. Ieşirile din cele două sisteme sunt supuse comparaţiilor. Prelucrările paralele se întrerup
când noul sistem funcţionează perfect (de regulă, după săptămâni sau luni de lucru). Avantajele
metodei sunt date de faptul că se elimină riscul în caz de eşec al noului sistem şi faptul că
utilizatorii au mai mare încredere în noul sistem, oferindu-li-se posibilitatea de a-l verifica
înainte de fi dat în exploatare definitiv. Dezavantajul principal îl constituie volumul dublu de
muncă şi o cantitate mai mare de resurse. Totuşi, în practică, este cea mai agreată metodă.
Conversia paralelă nu funcţionează în situaţia în care cele două sisteme nu sunt
compatibile tehnic sau când mediul de exploatare nu poate să suporte sarcina funcţionării lor în
paralel. De asemenea, nu se recomandă atunci când sistemele au funcţionalităţi diferite sau
noul sistem presupune o nouă metodă de derularea a operaţiilor economice.
Conversia pe faze sau graduală constă în înlocuirea treptată a elementelor sistemului,
evitându-se schimbările drastice, instalându-se câte un subsistem pe rând. În acest fel, noul
sistem poate să funcţioneze on-line cu o serie de componente funcţionale, logic ordonate, astfel
încât să elimine cât mai mult posibil perioadele de întrerupere a activităţii utilizatorilor şi a
fluxurilor economice. Principalul dezavantaj este creşterea costului prin crearea interfeţelor
temporare între vechiul şi noul sistem, precum şi timpul suplimentar impus de înlocuirea
treptată. Conversia pe faze nu poate fi folosită atunci când noul sistem nu permite separarea
modulelor sau subsistemelor.
Conversia modulară (pilot) presupune implementarea sistemului în unele componente din
unitate, cum ar fi un anumit număr de secţii, compartimente ş.a. Întâi se ia o staţie pilot în care
implementarea să se facă după una dintre cele trei metode prezentate, iar după testare va fi
extins fie în întregul sistem, fie în anumite locuri. Dezavantajul provine din intervalul de timp
mărit pentru conversie, precum şi din costul interfeţelor necesare între vechiul şi noul sistem
care coexistă până ce conversia se realizează în ultimul loc din unitate.
O sinteză a metodelor de conversie este redată în fig. 6.5.
Sistem vechi
Sistem vechi Sistem nou
Sistem nou
a) Conversia directă b) Conversia paralelă
Sistem vechi Sistem nou Sistem vechi Sistem nou
c) Conversia pe faze d) Conversia modulară (pilot)
Fig. 6.5 Metode de conversie a sistemelor
O altă problemă a conversiei se referă la datele stocate. Fişierele existente şi bazele de

date sunt convertite pe trei căi diferite:
a) datele trebuie să fie transferate de pe un suport pe altul;
b) conţinutul datelor trebuie modificat (câmpuri şterse sau adăugate);
c) formatul fişierului trebuie modificat.
O conversie anume poate fi concretizată sub toate cele trei forme.
Conversia fişierelor sau a bazelor de date constă în patru activităţi principale:
1) pregătirea datelor pentru conversie;
2) conversia datelor;
3) verificarea corectitudinii noilor date;
4) documentaţia şi efectuarea copiilor de siguranţă.
Din cele prezentate rezultă că trecerea de la un sistem la altul este un proces complex, iar
descrierile de mai sus nu reprezintă decât elemente ce marchează importanţa problemei.
Rezumat
Implementarea este una din etapele care include cel mai mare grad de risc pentru reuşita proiectului
de dezvoltare a sistemului informaţional. Până la această etapă, proiectul se desfăşoară fără să afecteze
activităţile curente al organizaţiei. Însă, implementarea presupune afectarea mediului de lucru al
utilizatorilor, implicit al organizaţiei, iar o proastă gestionare a activităţilor implementării poate conduce
la efecte dezastruoase.
Implementarea începe, mai întâi, cu o planificare riguroasă, după care se continuă cu realizarea şi
testarea programelor, pregătirea locurilor de muncă şi a spaţiilor în care vor fi instalate echipamentele,
testarea acestora, selectarea şi instruirea personalului care să asigure atât exploatarea sistemului, cât şi
întreţinerea acestuia, finalizarea documentaţiei, testarea finală, conversia de la vechiul sistem la cel nou.
Planificarea are loc înainte de demararea activităţilor propriu-zise de implementare, chiar de la
începutul proiectului. Se folosesc tehnicile cunoscute: diagramele Gantt şi PERT.
Una dintre etapele implementării priveşte testarea, ea fiind critică pentru calitatea sistemelor
informaţionale. Obiectivul general al etapei de testare îl reprezintă identificarea numărului maxim de
erori cu efort minim. Atingerea acestui obiectiv impune organizarea şi planificarea riguroasă a testării.
Principalele activităţi care formează procesul de testare sunt: definirea strategiei de testare, stabilirea
rezultatelor aşteptate, efectuarea testelor planificate, compararea rezultatelor testării şi întocmirea
documentaţiei.
Astăzi există o mulţime de tehnici de testare, clasificate după numeroase criterii. Se pot distinge
tehnici de testare dinamice sau statice, în funcţie de execuţia sau nu a programelor, automate sau
manuale, dacă testele sunt realizate sub controlul calculatorului sau a omului, tip „cutia albă” sau „cutia
neagră”, în funcţie de luarea în considerare sau nu a detaliilor procedurale interne ale componentei
testate.
Din punctul de vedere al organizării, testarea va începe la nivelul modulelor de program, fiind
vizate, în principal: interfeţele modulelor, structurile de date locale, şi algoritmii de prelucrare. Se
continuă cu testarea integrării modulelor, pentru depistarea unor categorii de erori specifice, şi testarea
la nivelul sistemului, în care testele sunt orientate spre acele caracteristici nespecifice componentelor
programului, cum ar fi: performanţele sistemului, securitatea, refacerea în cazul apariţiei unor căderi ale
sistemului. Se încheie cu testarea de acceptare, desfăşurată într-un mediu similar celui în care va lucra
utilizatorul.
Având finalizate activităţile care asigură funcţionalitatea sistemului se trece la finalizarea
documentaţiei sistemului, formată din mai multe componente, în funcţie de persoanele care vor beneficia
de ea. Astfel, se va regăsi documentaţia utilizatorului, formată din manualul de utilizare, ghidul general şi
tutorialele, şi documentaţia tehnică, adresată echipei ce va asigura întreţinerea sistemului, în care se
includ manualul de operare, manualul de instalare şi manualul dezvoltatorului.
În final, se poate trece la activitatea care asigură operaţionalitatea noului sistem, respectiv
conversia. Se utilizează patru metode de conversie: directă, paralelă, pe faze sau graduală, modulară sau
pilot. Fiecare metodă prezintă avantaje şi dezavantaje, iar decizia de a merge pe una din ele depinde de
mai mulţi factori, cum ar fi: complexitatea sistemului, urgenţa implementării, compatibilitatea celor două
sisteme (vechi şi nou), nivelul de descompunere a sistemului. Tot acum are loc şi conversia datelor,
operaţiune destul de anevoioasă şi riscantă.
1. Motivaţi de ce este necesară planificarea implementării.
2. Care sunt principalele activităţi ale etapei de implementare?
3. Prin ce diferă operaţiunile de verificare şi validare din perspectiva testării sistemelor informaţionale.
4. Descrieţi pe scurt demersul procesului de testare.
5. Care sunt principiile testării?
6. Comentaţi următoarea afirmaţie: Tehnicile de testare tip „cutia albă” şi cele tip „cutia neagră” sunt
complementare.
7. Definiţi criteriul de acceptabilitate la care răspunde tehnica de testare a căilor de bază.
8. Formulaţi cinci reguli de testare a structurilor de control repetitive.
9. Prezentaţi patru categorii de erori care pot fi urmărite în cadrul examinărilor.
10. Descrieţi execuţia de probă ca tehnică de testare.

11. Ce aspecte sunt urmărite în cadrul testării modulelor?
12. Care este scopul testării integrării modulelor? Cum se realizează ea?
13. Prin ce se diferenţiază testarea la nivelul sistemului de testarea integrării modulelor? Dar testarea alfa
de testarea beta?
14. Realizaţi o comparaţie a celor patru metode de conversie a sistemului.
Probleme
1. Pentru un sistem cunoscut, selectaţi o metodă de conversie şi motivaţi alegerea făcută. Dacă
recomandaţi conversia pe faze, specificaţi ordinea în care doriţi implementarea
subsistemelor/modulelor. Dacă apelaţi la metoda de conversie pilot, identificaţi departamentul cu
care să începeţi şi motivaţi alegerea.
CAPITOLUL VII
Exploatarea şi întreţinerea
sistemelor informaţionale
Obiective:
• Cunoaşterea modalităţilor de sprijinire a utilizatorilor în exploatarea sistemului
• Prezentarea caracteristicilor activităţii de închidere a proiectului de dezvoltare
• Înţelegerea principalelor aspecte ale etapei de întreţinere a sistemelor informaţionale
• Dobândirea cunoştinţelor necesare realizării operaţiunii de întreţinere a sistemelor
Exploatarea şi întreţinerea sunt două etape ale ciclului de viaţă al sistemului care încep
imediat ce acesta devine operaţional şi continuă până când funcţionalităţile şi performanţele lui
nu mai corespund obiectivelor firmei, cerinţelor utilizatorilor. În timpul acestor etape, echipa
de specialişti şi firmele furnizoare trebuie să vină în sprijinul utilizatorilor, prin oferirea
sprijinului necesar în utilizare, şi să rezolve eventualele cerinţe suplimentare, probleme sau
erori ce apar pe parcursul exploatării, adică să întreţină şi îmbunătăţească performanţele
acestuia. Tot acum este momentul în care echipa de dezvoltare a sistemului, împreună cu
conducerea firmei trebuie să conceapă planul de redresare a sistemului în caz de dezastre.
7.1 Sprijinirea utilizatorilor
După ce, în capitolul anterior, am prezentat preocupările pe linia instruirii utilizatorilor,

considerăm că de cel puţin aceeaşi importanţă este şi sprijinirea lor.
În timp, sprijinul acordat utilizatorilor a avut următoarele forme de concretizare: materiale
tipărite, versiuni on-line ale materialelor tipărite, consultanţă de specialitate asigurată de
furnizorii echipamentelor şi/sau produselor-program, precum şi de alte categorii de persoane
din interiorul organizaţiei. În pofida importanţei acţiunii de sprijinire a utilizatorilor, formele
enunţate, din nefericire, nu au dat cele mai bune rezultate, cu toate că statisticile arată că peste
un sfert din respondenţii anchetaţi au relevat faptul că au nevoie de aşa ceva.
Atunci când discutăm despre utilizatori, se cuvine să folosim şi unii calificatori pentru a
surprinde saltul înregistrat de-a lungul anilor. Astfel, am putea să vorbim despre utilizatori
finali ca o categorie distinctă, conturată o dată cu comercializarea serviciilor calculatoarelor,
îndeosebi din anii 1950, cu apogeul înregistrat în anii 1970. Categoria menţionată ştia să …
ceară într-un limbaj irelevant mediului prelucrării automate a datelor, îndeosebi la început, însă
prin facilitarea accesului a tot mai multe persoane la ştiinţa popularizată a calculatoarelor, dar
şi prin includerea în programele şcolare a cunoştinţelor elementare din domeniu, limbajul s-a
schimbat radical. Oricum, ei erau doar beneficiarii rezultatelor prelucrării şi doar în mică
măsură erau implicaţi şi în introducerea de la distanţă a datelor, în regim de teleprelucrare.
Când, în anii 1981, IBM s-a lansat în producţia de microcalculatoare, s-a conturat o a doua
categorie de utilizatori, citaţi de literatura de specialitate sub denumirea de computing end-
users, adică utilizatori finali înzestraţi cu suficiente cunoştinţe despre prelucrarea automată a
datelor, numiţi de noi utilizatori finali informatizaţi. Calificativul „informatizaţi” dorim să
sugereze mediul de lucru al utilizatorului final, dar şi cunoştinţele acestuia.
EXPLOATAREA ŞI ÎNTREŢINEREA SISTEMELOR INFORMAŢIONALE 137
Cel puţin din cel de-al doilea punct de vedere, al cunoştinţelor, utilizatorii finali
informatizaţi diferă semnificativ ca nivel de pregătire. Unii au studii medii, de tip colegiu, sau
universitare de specialitate. Alţii, au beneficiat doar de cursuri de scurtă durată, însă cea mai
mare parte a utilizatorilor finali sunt „nealfabetizaţi” în domeniul prelucrării automate a
datelor, deşi, cu sau fără voia lor, sunt incluşi în categoria potenţială de utilizatori finali
informatizaţi.
La structurile atât de eterogene enunţate, eforturile de sprijinire a lor sunt cu totul altele.
Iată de ce literatura adaugă, în ultimul deceniu, un nou concept, centrul informaţional, chiar
dacă el s-a născut în deceniul opt. Se pare că, la fel ca şi în lumea muzicii, şi în informatică,
unde se utilizează o mare diversitate de instrumente, se simte nevoia unui dirijor al activităţilor
care se bazează pe sprijinul calculatoarelor, iar sistemul să fie văzut ca o orchestră.
7.1.1 Rolul centrelor informaţionale în asistarea utilizatorilor

Din prezentarea strategiilor de abordare a problemei utilizatorilor informatizaţi rezultă că,
de cele mai multe ori, una din soluţiile ieşirii din eventualele stări de haos ar consta în
constituirea centrelor informaţionale. Termenul este încă nefolosit în literatura noastră, deşi s-
ar putea ca mulţi specialişti să constate că într-o oarecare măsură deja există aşa ceva în
unitatea lor. Deocamdată, ne interesează cum să facem funcţional un astfel de concept.
Nu ştim dacă informaticienii anilor 1970-1980 îşi mai amintesc de disputa, pe plan
informatic, dintre americani şi francezi. Ultimii, susţinuţi în forţă de o companie puternică,
ALCATEL, promovau infocentrul, în timp ce primii lansau ideea informatizării distribuite.
Chiar dacă information center, centrul informaţional despre care ne-am propus să discutăm, se
apropie din punct de vedere fonetic de infocentrul francez, semnificaţiile tehnice de lucru sunt
cu totul altele.
Infocentrul se baza pe concentrarea tuturor bazelor de date şi a resurselor fizice de calcul
într-un punct central, utilizatorilor oferindu-li-se accesul prin puternicele reţele de comunicaţie
create de ALCATEL. S-au lansat şi conceptele sisteme de prelucrare a datelor distribuite şi
sisteme de prelucrare distribuită a datelor. O analiză atentă a lor conduce la diferenţieri
evidente. În timp ce infocentrul se baza pe sisteme în care era exploatată, în primul rând,
puterea reţelelor de comunicaţie, apelându-se la terminale destul de simple, chiar neinteligente,
sistemul american se baza şi pe distribuirea puterilor de calcul în profil teritorial. Şi în acest
caz s-a ajuns la o soluţie de „compromis”, prin apariţia, în SUA, a aşa-ziselor X-terminale,
care, doar prin faptul că sunt mai simple din punct de vedere constructiv, lipsindu-le unităţile
de discuri magnetice de orice fel, difereau de microcalculatoarele puternice. În rest, ele au
substituit perfect pe cele din urmă şi au avut avantajul preţurilor mult mai scăzute.
De regulă, preocuparea centrală consta în definirea modului în care persoanele pot căpăta
informaţii din diverse domenii, prin substituirea birourilor clasice de informaţii şi trecerea lor
pe seama calculatoarelor, constituindu-se puternicele reţele de servicii de informare
computerizate sau, mai nou, de servicii cu valoare adaugată.
Centrele informaţionale sunt cu totul altceva, prin funcţiile lor fiind diferite net de
infocentrele descrise anterior. Ca rază de acţiune, centrele informaţionale sunt mai limitate,
deşi dimensiunea lor depinde de mărimea firmei în care se creează şi de gradul de dispersare a
acesteia. Oricum, rolul lor este de a orienta şi, uneori, de a controla activităţile utilizatorilor
informatizaţi.
Conceptul de centru informaţional a fost utilizat prima dată în 1974, de către filiala IBM
din Canada, în ideea de constituire a unei puternice componente organizatorice într-o unitate
deja existentă, cu rolul de a oferi unele servicii specializate utilizatorilor finali. Preluat şi de
alte firme, el şi-a consolidat poziţia, dar mutaţii majore s-au înregistrat o dată cu apariţia
microcalculatoarelor, utilizatorii familiarizându-se din ce în ce mai mult cu componentele
fizice şi logice ale sistemelor informatice. În astfel de condiţii, s-a simţit nevoia orientării
primilor paşi ai acestora în intenţiile lor de a se dota cu hard şi soft sau, şi mai mult, de iniţiere
în tehnicile realizării, controlării şi integrării propriilor sisteme.
Centrul informaţional reprezintă un concept creat pentru sprijinul acordat utilizatorilor de
către un grup specializat de persoane; el este şi o entitate funcţională, de cele mai multe ori sub
formă distinctă în cadrul componentelor organizatorice informatice ale firmelor (serviciul
sistemelor informaţionale, centrul de calcul, oficiul sau staţia de calcul). El este în acelaşi timp
şi un loc fizic, în care consultanţii aşteaptă să fie solicitaţi de către utilizatorii informatizaţi.
Referitor la noul concept şi la cadrul lui de aplicare, uneori ne punem întrebarea dacă,
alături de centrul informaţional, ţinând cont de modul de organizare a activităţii de informatică
din ţara noastră, nu s-ar putea folosi şi termenii de oficiu informaţional sau staţie
informaţională. Nu de altceva, dar ni se pare că ar suna ciudat ca în cadrul unei staţii de calcul
să existe un centru informaţional, fie şi numai din respect pentru greutatea semantică a
cuvintelor. Alt motiv ar fi conştientizarea trecerii de la centre, oficii şi staţii de calcul, la
centre, oficii şi staţii informaţionale – ca unităţi distincte sau ca părţi componente ale vechilor
forme de organizare. E doar un simplu punct de vedere.
Specialiştii centrelor informaţionale sunt analiştii de sistem, cu vaste cunoştinţe despre
componentele informatice, un fel de uomo universale, întrucât sunt solicitaţi într-o foarte
diversificată gamă de probleme. În plus, trebuie să posede calitatea de a transmite cunoştinţele
lor către utilizatorii informatizaţi. Deşi aceasta pare o problemă lipsită de importanţă, ea are un
rol determinant în asigurarea succesului centrului informaţional, deoarece pot fi specialişti de
înaltă clasă, dar cu mari carenţe în psihopedagogie. Simularea stărilor empatice va fi cheia
succesului, ceea ce sub accepţiune generală ar însemna „arta de a fi în pielea utilizatorului”.
Solicitările pot fi şi pe domenii generate de funcţiile întreprinderilor (aprovizionare, producţie,
personal, financiar, contabilitate ş.a.), ceea ce duce la concluzia că în echipa centrului
informaţional trebuie să existe specialişti care, parafrazându-l pe Pico della Mirandola, să ştie
tot ce-i pe lume despre sistemele informatice şi chiar… ceva mai mult.
În cadrul centrelor informaţionale, specialiştii trebuie să contribuie la realizarea unor
funcţii specifice, dintre care amintim:
• iniţierea utilizatorilor finali în tehnicile de evaluare, selecţie, instalare şi întreţinere a
microcalculatoarelor şi a pachetelor-program aferente;
• sprijinirea utilizatorilor finali în realizarea accesului la bazele de date. Aici intră tehnicile
de dialog cu calculatoarele medii-mari din reţea, protejarea de tip „numai citire” pentru
anumite părţi ale bazei de date ş.a. Se ştie că în lucrul cu bazele de date centrale, „citirea”
este mult mai simplă decât „scrierea”, care, de cele mai multe ori, nici nu este posibilă. Se
cuvine iniţierea utilizatorilor în tehnica protecţiei prin niveluri diferite de acces;
• instruirea utilizatorilor informatizaţi în domeniul proiectării sistemelor. În realitate, sunt
multe centre informaţionale care refuză să ofere aşa ceva, considerând că menirea lor este
doar de a acorda asistenţă de specialitate, în timp ce altele trec la acomodarea utilizatorilor
cu mijloacele de lucru ale generaţiei a patra de limbaje şi de produse-program, CASE
(Computer Aided/Assisted Software/Systems Engineering) fiind cel mai solicitat;
• acordarea sprijinului pentru instalarea şi întreţinerea aplicaţiilor;
• îmbunătăţirea metodelor şi tehnicilor puse în slujba utilizatorilor informatizaţi, realizatori
de sisteme proprii;
• asigurarea „asistenţei de birou”, în regim non-stop, prin coborârea de la nivelul centrului
informaţional la cel al birourilor, creându-se soft specializat de consultanţă pe teme hard şi
soft, de genul sistemelor expert de rezolvare a necazurilor ce pot apărea în viaţa sistemelor
informatice. Edificator este softul de „ajutor de birou” SupportMagic al firmei Magic
Solutions din Mahwah, statul New Jersey;
• susţinerea utilizatorilor informatizaţi în exercitarea controlului asupra propriilor sisteme
sau iniţierea controlorilor şi auditorilor interni în îndeplinirea sarcinilor ce le revin în noul
mediu de lucru, precum şi certificarea aplicaţiilor proiectate de către utilizatorii

informatizaţi;
• instruirea utilizatorilor finali. Instruirea poate fi destul de variată, de la cursuri de scurtă
durată privind tehnica de lucru cu programele de calcul tabelar, până la managementul
resurselor sistemelor. Important este ca utilizatorii să fie instruiţi în ceea ce priveşte modul
în care ar putea să-şi rezolve propriile lor probleme din punct de vedere economic,
cunoscând noile condiţii de lucru oferite de generaţia a patra de limbaje şi să nu fie învăţaţi
„şcolăreşte” cum să folosească o anumită tehnică. De asemenea, instruirile se vor referi şi
la modul în care utilizatorii informatizaţi pot colabora, constituindu-se aşa-numiţii power-
users, care pot chiar suplini specialiştii centrului informaţional.
Dacă s-ar oferi toate formele de ajutor enumerate anterior, utilizatorii ar putea deveni
chiar super-power-users, ipostază în care nu ar mai avea deloc nevoie de specialiştii centrului
informaţional. Deja sunt cunoscute astfel de cazuri, ceea ce duce la „dozarea” sprijinului oferit
de centrele nou create. Cine cunoaşte cât de uşor „discipolii” centrului de informaţional ai
Quaker Oats Company au făcut inutilă existenţa acestuia… poate să tragă concluziile de
rigoare. Dar noi, mai întâi, trebuie să fim preocupaţi de crearea centrelor informaţionale şi
aşteptăm cu nerăbdare apariţia noilor power-users. Ei sunt cei ce vor da viaţă noilor tipuri de
centre ale cunoaşterii (knowledge centers), interconectate la nivel mondial, într-o nouă formă
de reţea.
7.1.2 Servicii automate de asistare a utilizatorilor
Dintre cele mai recente preocupări pe linia asistării continue a utilizatorilor de

calculatoare, demne de a fi consemnate sunt cele ale furnizorilor. Datorită creşterii explozive a
numărului utilizatorilor s-au înmulţit şi solicitările de asistenţă din partea acestora. Din
raţionamente economice – reducerea costurilor cu astfel de servicii –, dar şi pentru a răspunde
cât mai repede solicitărilor, furnizorii au introdus serviciile automate de asistenţă.
Cele mai cunoscute metode sunt: forumuri de sprijin on-line, sistemul buletinelor
electronice informative, fax la comandă, sistemul voice-response (răspuns vocal înregistrat)
ş.a.
Forumurile de sprijin on-line sunt organizate pentru informarea utilizatorilor despre
modul în care au acces la noi versiuni, la rezolvarea unor eventuale probleme survenite în
timpul exploatării, precum şi pentru a oferi recomandări în vederea creşterii performanţelor
sistemului. Sunt cunoscute acţiunile întreprinse în majoritatea firmelor furnizoare de
echipamente şi software, cum ar fi Microsoft, Prodiggy, CompuServe, Dell Computers, Genie
etc.
Faxul la comandă permite utilizatorilor să solicite informaţii ajutătoare prin
arhicunoscutul sistem al telefoanelor cu taxă inversă sau aşa numitele linii verzi, prefix 800
(atât în SUA, cât şi la noi), şi primirea imediată a răspunsului pe propriul lor fax sau în regim
de convorbire.
Sistemul voice-response oferă utilizatorilor posibilitatea să navigheze printr-un meniu cu
opţiuni care îi conduc la anumite mesaje preînregistrate despre problema ce vor să o rezolve.
Un exemplu, de acum clasic şi pentru România, este cel folosit de firmele de telefonie mobilă,
care oferă suport pe bază de răspunsuri înregistrate şi numai în situaţia în care problema nu
este soluţionată sau utilizatorul nu este mulţumit de răspunsul obţinut se face transferul către
un operator uman.
La rândul lor, organizaţiile şi-au creat un sistem similar, bazat pe înregistrarea soluţiilor
de rezolvare a diferitelor probleme ce se pot ivi, dar şi privind echipamentele şi produsele-
program achiziţionate de unitate. Acestei forme i se pot adăuga serviciile interne de e-mail,
sistemele de sprijinire a grupurilor de lucru, precum şi cele de birotică.
Alte organizaţii apelează la un sistem de ajutor continuu oferit de furnizori. Costul variază
între 5.000 USD şi 20.000 USD. În schimbul sumei amintite, furnizorul oferă acces la toate
cunoştinţele posibile despre produsele lui, prestează servicii electronice ajutătoare şi asigură
personal specializat la dispoziţia clientului. Sunt mulţi furnizori care oferă întreaga
documentaţie tehnică şi pe CD-ROM, cu actualizarea ei periodică, de cele mai multe ori în
variantă online, prin intermediul paginilor web, a e-mailului sau a transferului de fişiere prin
ftp (file transfer protocol). De reţinut că toate serviciile menţionate anterior sunt adaptate
condiţiilor specifice fiecărei organizaţii. În cadrul unui program anunţat, de până la patru ore
zilnic, o persoană din partea furnizorului stă la dispoziţia acestora pentru orice problemă
cuprinsă în contract.
7.1.3 Sprijinirea utilizatorilor prin birouri speciale (help desk)

Indiferent de faptul că în unitate se oferă asistenţă de către furnizori sau de sistemul
propriu, elementul central pentru oferirea asistenţei celor ce lucrează cu diferite componente
informatice îl constituie biroul de ajutor (help desk) .
Un birou de ajutor este o funcţie a departamentului sisteme informaţionale sau o
componentă a centrului informaţional, în care este angajat personal specializat în sisteme
informatice. Biroul de ajutor este primul loc la care apelează utilizatorii când au nevoie de
sprijin în domeniul activităţilor informatice. La început, biroul nu avea credibilitate, maliţioşii
considerându-l chiar şi mai slab cotat decât biroul de reclamaţii. Cu timpul însă, şi-a dobândit o
adevărată prestanţă. Personalul angajat, în afara profundelor cunoştinţe tehnice, trebuie să
dispună de reale calităţi de comunicare cu utilizatorii şi de capacitatea de a oferi soluţii la
diversitatea de cereri.
Biroul de ajutor poate să dispună de câteva persoane, sau chiar de mai multe, astfel încât
el să dobândească statutul unui compartiment funcţional. Aşa cum am afirmat anterior, biroul
poate fi integrat într-un centru informaţional sau să se constituie ca o componentă distinctă a
unităţii.
Biroul de ajutor mai poate fi întâlnit şi sub denumirea de centru de apel (call center) ,
fiind de fapt şi denumirea cea mai des utilizată în ultimul timp chiar şi la noi40. Mai mult, odată
cu apariţia Internetului şi cu explozia fenomenului de externalizare (outsourcing) a serviciilor
informaţionale, aceste centre sunt şi ele supuse acestui fenomen. Astfel au început să se
dezvolte sistemele bazate pe Internet (sau Intranet), care oferă o serie de avantaje comparativ
cu cele ale sistemului bazat pe telefonie: disponibil 24/7/365, chiar dacă centrul este închis,
mult mai cuprinzător în posibilităţile de ajutor în regim propriu, pe baza răspunsurilor la cele
mai frecvente întrebări (FAQ's).
În cea mai extinsă formă de existenţă, biroul de ajutor poate să funcţioneze cu cinci
niveluri de specialişti41:
Primul nivel al biroului de ajutor este constituit din personal care primeşte apeluri
telefonice, le filtrează şi le direcţionează spre locurile de unde se pot primi răspunsurile
adecvate. În multe unităţi o astfel de activitate este înlocuită de sistemele interactive voice-mail
(v-mail).
Pe nivelul al doilea se situează persoanele în măsură să rezolve aproape toate problemele
cu care se confruntă utilizatorii.
Atunci când problemele sunt dificile, ele se transmit persoanelor situate pe nivelul trei al
biroului de ajutor, care pot rezolva aproape toate problemele utilizatorilor unităţii.
40. Potrivit unui raport al Datamonitor, numărul serviciilor din centrele de apel din Europa Centrală şi de Est ar
putea să ajungă la 13.700 în 2008, iar România este considerată un fel de al doilea Bangalore (oraşul din India
cu cele mai multe servicii externalizate) în privinţa oportunităţilor de dezvoltare a unor astfel de centre, prin
externalizare de către marile firme, îndeosebi din domeniul IT, în special cele franceze şi italiene.
41. Crowley, A. – „The Help Desk Gains Respect”, in PC Week, no. 10, November 15, 1993, p. 138.
Cel de-al patrulea nivel este ocupat de controlorii activităţii zilnice prestate de personalul
ce lucrează cu utilizatorii.
Nivelul final este reprezentat de şeful biroului de ajutor.
Pentru eficientizarea acestor niveluri se recomandă integrarea unor componente web care
sprijină biroul de ajutor să interacţioneze în mod dinamic cu softul de automatizare a
serviciilor. Pentru că interfeţele web sunt aplicaţii client ce nu solicită resurse importante şi
asigură conectarea paralelă a unui număr mare de utilizatori folosind orice browser, se asigură
şi o reducere a costului total de funcţionare a biroului. O astfel de soluţie poate să ofere
următoarele facilităţi:
• accesul la instrumente ce permit obţinerea directă a informaţiilor necesare, fără intervenţia
unei alte persoane, cum ar fi baza internă de cunoştinţe. Astfel, diferite categorii de
persoane pot să introducă informaţii tehnice care să sprijine primul nivel al biroului, iar
utilizatorii le pot folosi pentru a găsi rezolvarea problemei într-o manieră proactivă;
• interacţiunea dinamică cu baza de date a biroului. Clienţii sau personalul de sprijin pot
introduce sau modifica o serie de elemente, pot să ofere detalii legate de unele acţiuni
pentru soluţionarea unei probleme, ceea ce face ca baza de date să fie permanent
actualizată şi disponibilă. Astfel, nu se mai înregistrează dublarea eforturilor de actualizare
(preluarea de la clienţi a problemelor şi găsirea soluţiilor şi apoi încărcarea lor în cadrul
bazei de date). De asemenea, nu mai există timpi de aşteptare până la identificarea tipului
de problemă şi transmiterea către persoana cea mai indicată să o rezolve;
• scăderea costurilor de funcţionare, pentru că nu mai sunt necesare softuri specializate şi
licenţe specifice pentru întreţinerea bazei de date, bază de date la care are acces orice
utilizator autorizat, ea fiind dezvoltată cu ajutorul unui limbaj specific, iar informaţiile pot
fi obţinute cu ajutorul oricărui browser, care presupune un cost relativ redus sau poate fi
descărcat gratuit;
• asigurarea unei evidenţe clare a numărului de accesări ale utilizatorilor, a numărului de
probleme pentru care există soluţii, a timpului necesar pentru rezolvarea unei probleme,
numărul de reveniri ale utilizatorilor etc., ceea ce vin în sprijinul personalului care asigură
întreţinerea sistemului.
Deşi biroul de ajutor ar trebui să fie de un real folos pentru utilizatori, după cum îi spune
şi numele, dintr-un studiu realizat de Forrester42 a rezultat că doar 53% din utilizatori consideră
că este satisfăcător nivelul în care sunt sprijiniţi. Şi această poziţie poate genera destul de
multe probleme pentru firme, pentru că, prin reducerea sau pierderea credibilităţii, poate fi
afectată negativ percepţia utilizatorilor legată de aplicaţiile sistemului, ceea ce va conduce la o
restrângere a bugetelor de funcţionare, atât a biroului, cât şi a sistemului, o perioadă mai mare
de timp pentru aprobarea noilor proiecte şi reducerea rolului sistemelor în asigurarea
performanţei organizaţiei într-un mediu în continuă schimbare.
Acest nivel destul de redus al gradului de satisfacţie se datorează în primul rând
numărului tot mai mare de aplicaţii utilizate în cadrul firmelor. Dacă în trecut, biroul de ajutor
avea în structură posturi ce nu cereau calificări complexe, pentru că personalul era implicat,
cea mai mare parte a timpului, în oferirea de răspunsuri simple, repetitive, la probleme
comune, astăzi lucrurile s-au schimbat. Întrebările utilizatorilor sunt din ce în ce mai complexe,
iar rolul biroului a trecut din faza de soluţionare a defecţiunilor tehnice către înţelegerea şi
sprijinirea strategiilor de afaceri. Utilizatorii nu mai solicită ajutor pentru probleme de genul
„s-a blocat o hârtie în imprimantă” sau „nu reuşesc să introduc CD-ul în unitate”, ci solicită tot
mai multe informaţii despre aplicaţiile folosite şi procesele economice, care ies din sfera de
acţiune tradiţională a biroului de ajutor. De aici rezultă că personalul angajat trebuie să fie
orientat din ce în ce mai mult către componentele de afaceri şi legăturile cu aplicaţiile specifice
şi mai puţin către cele hardware şi software de sistem. Dar lucrul acesta nu este simplu,
42. Gliedman, C. – Thirty-one Best Practices for the Service Desk, June 28, 2005, http://i.i.com/cnwk.ld/itp, pp. 1-2,
accesat pe 25 octombrie 2005.
întrucât personalul specializat al biroului de ajutor trebuie să fie supus, să zicem, unei
reconversii profesionale, orientată către partea economică şi organizaţională a sistemelor
informaţionale. Pentru a asigura eficienţa personalului, au fost elaborate câteva recomandări43:
• angajarea persoanelor potrivite şi într-un număr suficient care să asigure oferirea
suportului într-un timp cât mai scurt din momentul solicitării;
• instruirea corespunzătoare a utilizatorilor;
• instruirea personalului din cadrul biroului pe componentele afacerii;
• asigurarea unei legături cu cel mai apropiat nivel managerial, pentru obţinerea cât mai
rapidă a aprobărilor şi resurselor necesare pentru modificări la nivelul sistemului,
atunci când ele se impun;
• motivarea personalului să accepte şi să se adapteze la schimbări;
• asigurarea mobilităţii personalului de pe un post pe altul, pentru a nu se ajunge la
starea de plafonare, prin implicarea lor, în perioade cu mai puţine solicitări, în proiecte
de dezvoltare a unor noi aplicaţii.
În final, trebuie să spunem că înfiinţarea sau păstrarea unui birou de ajutor trebuie să fie
atent analizată, întrucât presupune costuri, resurse şi o structură proprie de organizare. De
aceea, este necesar să se evalueze eficienţa activităţilor desfăşurate, pe baza numărului
apelurilor, timpului de răspuns, gradului de satisfacţie a utilizatorilor, tipurilor de probleme
apărute, a frecvenţei lor, monitorizării performanţei personalului implicat etc.
7.1.4 Comunicantul tehnic – o nouă profesie?

Preocuparea ofertanţilor de produse sau servicii informatice performante s-a concretizat
sub diverse forme, unele dintre ele fiind consemnate în paragrafele anterioare. Pentru
transmiterea informaţiilor tehnice s-a apelat la diverse forme de prezentare şi la diferite
persoane care să asigure realizarea documentelor şi transmiterea lor. Astfel că, în timpul celui
de-al doilea război mondial, şi-a făcut apariţia o nouă profesie pentru a sprijini, într-o manieră
profesională, transmiterea informaţiilor tehnice privind echipamentele complexe folosite.
Pentru domeniul informaticii, această profesie şi-a făcut simţită prezenţa odată cu dezvoltarea
industriei calculatoarelor (anii 1960-1970), cunoscând o evoluţie progresivă la începutul anilor
1990, prin influenţa asupra afacerilor a Internetului şi a noilor forme de comunicaţii44.
Propunerea este binevenită, însă, în intenţia de a-i găsi sensul etimologic, am căutat noul
concept, technical communicator, în Encyclopedia Webster. Aici nu există cuvântul
communicator, ci doar communicant, cu sensul de „o persoană care comunică”. La fel, doar în
Dicţionarul explicativ al limbii române – Supliment (DEX-S), am identificat cuvântul
comunicant, cu semnificaţia „persoană care comunică ceva; spec. persoană care dă răspunsul la
o anchetă lingvistică”. Aşadar, chiar dacă propunerea autorilor menţionaţi anterior este de
comunicator, noi am pledat pentru varianta consemnată de dicţionare, comunicant, iar noua
profesie ar fi cea consemnată în subtitlul nostru – comunicant tehnic.
Comunicantul tehnic este persoana special instruită pentru întocmirea documentaţiei
sistemului şi a utilizatorului, în cazul sistemelor complexe. Anterior, o astfel de persoană era
numită secretar tehnic (technical writer), dar noua persoană face mai mult decât simpla scriere
a documentaţiei tehnice, cum ar fi activităţile de instruire şi de oferire a ajutorului pentru
beneficiarii de servicii informatice din unitate în vederea creării propriei lor documentaţie.
Activităţile prestate de comunicantul tehnic sunt:
• tehnoredactare documentaţie;
• instruire;
43. Gliedman, C. – op. cit, pp. 3-6.

44. Craig, J.S., Beck, B.E. – „A New Look at Documentation and Training: Technical Communicator as Problem
Solver”, in Information Systems Management, 10 (Summer), 1993, pp. 47-55; Carliner, S. – Industry Report:
Overview of the Technical Communication Industry, 2002, www.stc.org (accesat 2.01.2006).
• programare în diverse medii de programare;

• verificarea noilor produse înaintea utilizării;
• tehnoredactare de materiale hypertext;
• tehnoredactare de Help-uri on-line;
• tehnoredactare broşuri de utilizare;
• tehnoredactare standarde;
• analiza în fazele incipiente pentru realizarea documentaţiei sau pentru proiectele de
instruire;
• realizarea de materiale didactice.
Noua profesie se va concentra îndeosebi pe asistenţa oferită analiştilor şi utilizatorilor
pentru realizarea documentaţiei, a materialelor ajutătoare şi a instruirilor. Specialiştii din
domeniu, pentru problemele susmenţionate, vor fi mai înzestraţi decât analiştii şi programatorii
unităţii.
Multe unităţi nu-şi permit să angajeze o persoană numai pentru exercitarea activităţilor de
comunicant tehnic, situaţie rezolvată fie prin profesiile existente (analişti, programatori), fie
prin apelarea la servicii externalizate (outsourcing), fie prin colaboratorii externi angajaţi
temporar, specialişti în comunicare tehnică.
7.2 Închiderea proiectului

Din prezentările anterioare s-a scos în evidenţă faptul că un proiect, după ce este selectat,
urmează a fi transpus, prin etape bine definite, în fapte, ceea ce în literatura de specialitate
poartă denumirea de managementul proiectelor, adică tot ce intervine de la iniţierea proiectului
şi până la închiderea lui. De fapt, cam tot ceea ce s-a prezentat până în acest paragraf se referă
la etapele din ciclul de dezvoltare a unui sistem pe bază de proiect. Într-un astfel de moment se
poate vorbi despre închiderea proiectului, în pofida faptului că nu am tratat încă etapa de
întreţinere – ultima din ciclul de viaţă. După cum se va vedea însă din paragraful următor,
dedicat în exclusivitate acestei probleme, întreţinerea înseamnă o serie de noi proiecte de
conceput, fiecare cu faze specifice managementului proiectelor.
Închiderea unui proiect presupune exercitarea mai multor activităţi, dintre care le vom
prezenta pe cele mai importante.
Prima activitate se va referi la personalul echipei proiectului. Se va efectua evaluarea
finală a rezultatelor tuturor membrilor echipei; se vor constitui echipe noi pentru alte proiecte
ce se vor lansa sau membrii echipei vor fi redistribuiţi la unele care se află în curs de execuţie.
Tot acum, şeful echipei de proiectare va aduce la cunoştinţă tuturor părţilor interesate că
proiectul s-a încheiat şi că se va trece la etapa de întreţinere a lui.
A doua categorie de activităţi surprinde operaţiunea de degrevare a responsabilităţilor.
Atât conducerea de care aparţine echipa de proiectare, cât şi beneficiarii vor efectua ultimele
inspecţii de evaluare. Uneori, operaţiunea este efectuată de specialişti în evaluare, dintre care
cei mai cunoscuţi sunt auditorii interni sau experţii. Scopul este clar: analiza critică a
proiectului, a metodelor folosite, a rezultatelor obţinute, a modului în care este asigurat
managementul proiectului.
A treia activitate conduce la închiderea contractului stabilit cu beneficiarul, cu alte
cuvinte obţinerea semnăturilor tuturor părţilor ce trebuie să fie implicate la punerea în
funcţiune (PIF). Pentru activităţile din timpul etapei de întreţinere se vor încheia noi contracte,
ce vor avea efect pe întreaga durată consemnată în ele.
Orice analist al echipei îşi va înceta activitatea odată cu închiderea proiectului. Totuşi, din
respect pentru domeniu, vom discuta în capitolul următor despre ultima etapă a ciclului de
viaţă al unui sistem, întreţinerea.
7.3 Întreţinerea sistemelor
Activităţile de întreţinere includ modificarea sistemului şi a documentaţiei pentru

asigurarea funcţionării corecte a acestuia, precum şi activităţile de adaptare a sistemului la
modificarea cerinţelor funcţionale sau tehnice. Tot aici se vor avea în vedere şi acţiunile pentru
realizarea planului de redresare în caz de dezastre, care sperăm să nu fie pus şi în aplicare.
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. Operaţiunea nu trebuie să fie văzută ca şi în cazul echipamentelor din secţiile de
producţie sau al clădirilor. Ea începe o dată 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.
Un alt aspect se referă la durata etapei de întreţinere. După unele opinii, ea ar fi optimă în
varianta de cinci ani, după altele – în zece sau mai mulţi. Răspunsul poate varia de la un caz la
altul. Tendinţa este 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 în
verificarea modului în care acesta funcţionează. Activităţile implicate de întreţinerea
sistemului sunt: primirea cererilor de întreţinere; transformarea cererilor în propuneri de
schimbări; proiectarea schimbărilor; implementarea schimbărilor.
Pentru a sesiza similitudinea dintre aceste activităţi şi etapele ciclului de viaţă al
dezvoltării sistemelor, prezentăm schema din fig. 7.1.
Etapele ciclului de viaţă Activităţile procesului de
al dezvoltării sistemelor ÎNTREŢINERE
Identificarea şi Obţinerea cererilor

selecţia proiectului de întreţinere
Iniţierea şi Transformarea
planificarea cererilor în
proiectului schimbări
Proiectarea
Analiza
schimbărilor
Proiectarea
logică
Proiectarea Implementarea
fizică schimbărilor
Implementarea
Fig. 7.1 Corespondenţa dintre etapele ciclului de viaţă

şi activităţile procesului de întreţinere
7.3.1 Realizarea operaţiunii de întreţinere a sistemelor

Întrucât cheltuielile de întreţinere au o pondere substanţială în structura costurilor totale
ale sistemelor, considerăm relevantă prezentarea tipurilor întreţinerii: corectivă, adaptivă,
perfectivă, preventivă – conform figurii 7.2, din care rezultă şi ponderea lor în totalul
activităţilor de întreţinere.
Preventivă (5%)
Perfectivă (12%)
Adaptivă (8%)
Corectivă (75%)
Fig. 7.2 Ponderile tipurilor de activităţi de întreţinere în

totalul activităţii de întreţinere a sistemelor
Î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, dar ea poate să apară şi pentru rezolvarea problemelor
create prin modificări anterioare. Pentru evitarea apariţiei de noi erori, toate activităţile de
întreţinere trebuie realizate cu mare atenţie, în sensul că trebuie aplicate aceleaşi principii, la o
scară mai redusă, specifice etapelor din ciclul de dezvoltare a sistemului.
Organizaţiile ar trebui să aibă reguli clare în privinţa modalităţilor de corectare a erorilor
minore, cum ar fi un titlu incorect al unui raport, formatul necorespunzător al unei date, mesaje
incorecte la validarea prelucrărilor etc. Prin astfel de reguli, un utilizator transmite o cerere
care este supusă evaluării şi planificată pentru soluţionare. Dacă cererea este aprobată, echipa
de întreţinere va proiecta, testa, documenta şi implementa o soluţie. În situaţia unor probleme
majore, cum ar fi un total greşit înregistrat într-un raport sau validări incorecte a datelor,
utilizatorii transmit cererea împreună cu evidenţe al erorilor identificate, iar echipa de
întreţinere va acţiona imediat pentru remedierea lor. Atunci când se înregistrează erori ce
conduc la căderea întregului sistem, se va acţiona pentru înlăturarea lor, urmând ca analiza
cauzelor şi proiectarea unei soluţii generale să fie făcută după ce sistemul funcţionează în
parametri normali.
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ăţilor de acest gen.
Întreţinerea adaptivă 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;
• sprijinirea operaţiunilor realizate prin intermediul paginilor web.
Procedurile pentru modificări minore sunt similare celor specifice corecţiilor de rutină.
Deşi procedurile sunt asemănătoare cu cele ale întreţinerii corective, întreţinerea adaptivă
solicită mai multe resurse.
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 adaptivă poate fi văzută ca un proiect mult mai mic de dezvoltare a unui
sistem, pentru că paşii de dezvoltare sunt similari. Întreţinerea adaptivă poate fi mult mai
dificilă decât realizarea unui nou sistem deoarece îmbunătăţirile sunt efectuate sub influenţa
restricţiilor impuse de sistemul existent.
Î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. Solicitările de acest gen vin, de cele mai
multe ori, din partea specialiştilor din departamentul de informatică. În timpul exploatării,
modificările din activitatea utilizatorilor sau a modelului datelor pot determina o reducere a
eficienţei sistemului, iar prin intermediul operaţiunilor de întreţinere perfectivă se poate
ameliora performanţa acestuia. De asemenea, se poate asigura o creştere a gradului de
siguranţă în exploatarea sistemului.
Acest tip de întreţinere se derulează, de obicei, după o perioadă mai mare de exploatare a
sistemului. Există şi două tehnici folosite: proiectarea în sens invers (reverse engineering) şi
reproiectarea (re-engineering). Proiectarea în sens invers este sprijinită de o serie de
instrumente CASE, prin care se asigură transpunerea aplicaţiilor existente sau a bazelor de date
într-un set de diagrame logice, diagrame de structură şi descrieri în dicţionarul metadatelor,
astfel încât analiştii pot examina aplicaţiile din perspectiva proiectării. Reproiectarea
presupune analiza calităţii sau performanţelor aplicaţiilor, iar, pe baza rezultatelor, un
specialist poate recomanda ca un program să fie actualizat, trecerea de la un mediu de
programare la altul etc.
În multe organizaţii, întreţinerea perfectivă nu este derulată destul de frecvent,
considerând că proiectele de dezvoltare a unui nou sistem sau de corectare şi adaptare a
sistemului au prioritate mai mare. Totuşi, operaţiunea 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. Adesea, o cerere pentru o astfel de activitate vine din partea
departamentului de informatică. Ca rezultat, poate să se obţină o creştere a satisfacţiei
utilizatorilor în exploatarea sistemului, o reducere a costurilor totale de exploatare. Ca şi
celelalte două operaţiuni anterioare de întreţinere – adaptivă şi perfectivă –, nici aceasta nu
este de o deosebită stringenţă. Ea adaugă valoare organizaţiei.
În sinteză, în tabelul 7.1 sunt prezentate cele mai întâlnite acţiuni realizate în cadrul
fiecărui tip de întreţinere.
Pentru iniţiaţii în managementul calităţii totale (TQM, Total Quality Management),
tipurile activităţilor de întreţinere descrise mai sus vin tocmai în întâmpinarea acestui concept.
Nu trebuie ignorat însă costul calităţii totale. Aşa cum afirmam anterior, 85% din costurile
sistemelor informaţionale sunt alocate activităţilor de întreţinere. Cu cât cheltuielile având
această destinaţie sunt mai mari, cu atât defectele sunt mai puţine, deci performanţele
sistemului vor fi mai bune. La rândul lor, costurile întreţinerii unui sistem sunt influenţate de
câteva elemente principale: numărul defectelor latente, numărul beneficiarilor sistemului şi
calitatea documentaţiei.
Numărul defectelor latente înseamnă numărul erorilor necunoscute existente în sistem
după instalarea acestuia. Ele vor conduce la apariţia costurilor corective.
Numărul beneficiarilor sistemului influenţează, în mod firesc, cheltuielile de întreţinere,
în sensul că un sistem cu un număr mai mare de beneficiari va avea de suportat un volum mai
mare de cheltuieli de întreţinere.
Calitatea documentaţiei joacă, de asemenea, un rol important în exercitarea activităţilor
de întreţinere. Cu cât documentaţia este mai bine întocmită şi mai amplă, cu atât lucrările de
întreţinere se vor efectua mai uşor.
În afara celor trei elemente menţionate, costurile întreţinerii sistemului mai pot fi
influenţate şi de calitatea personalului angajat cu acest scop. Instrumentele de lucru, la rândul
lor, influenţează calitatea lucrărilor de întreţinere, dar şi costurile aferente. Un ultim factor de
influenţă ar putea fi calitatea softului de întreţinut. Un soft realizat artizanal este mult mai
dificil de înţeles de către echipa de întreţinere.
Tabel nr. 7.1 – Acţiunile realizate în cadrul întreţinerii

Nr.
Tipul întreţinerii Acţiuni realizate
crt.
Identificarea şi eliminarea erorilor din programe
Înlocuirea cablurilor defecte de la nivelul reţelei
1. Întreţinere corectivă Refacerea configuraţiilor sistemului în cazul unei defectări a acestuia
Actualizarea driverelor
Instalarea update-urilor pentru sistemele de operare
Adăugarea de module pentru prelucrarea online
Crearea de noi rapoarte
2. Întreţinere adaptivă Adăugarea de noi câmpuri în formularele de introducere a datelor
Instalarea legăturilor către paginile web
Crearea unui portal pentru angajaţi
Instalarea de memorie suplimentară
Scrierea de macrouri pentru automatizarea sarcinilor repetitive
Comprimarea fişierelor de sistem
3. Întreţinere perfectivă Optimizarea setărilor şi configuraţiilor existente pe calculatoarele
utilizatorilor
Dezvoltarea bibliotecii pentru modulele de cod reutilizabile
Instalarea unui server mai puternic
Instalarea antiviruşilor
Întocmirea unui plan al procedurilor de realizare a copiilor de siguranţă
4. Întreţinere preventivă
Realizarea periodică a proceselor de defragmentare
Analiza problemelor raportate în privinţa modelelor folosite
Toate activităţile de întreţinere din organizaţiile care au sisteme informaţionale puternice

sunt prestate de un grup de întreţinere, altul decât grupul de dezvoltare a sistemelor. În
practică însă pot fi întâlnite următoarele situaţii:
1. grupul de întreţinere este format dintr-o parte a grupului care a realizat sistemul;
2. grupul de întreţinere este o entitate funcţională distinctă a organizaţiei;
3. fiecare grup de utilizatori finali ai sistemului îşi va constitui un personal propriu de
întreţinere.
Eficienţa activităţilor de întreţinere se poate exprima prin: numărul defecţiunilor din
sistem, timpul dintre două defecţiuni, tipul defecţiunilor.
Rezumat
Exploatarea şi întreţinerea sunt două etape ale ciclului de viaţă care încep imediat ce sistemul
devine operaţional şi continuă până când se impune înlocuirea lui. În timpul activităţii de exploatare,
specialiştii IT trebuie să asigure suportul utilizatorilor în utilizarea sistemului, iar în timpul întreţinerii
(care nu este o etapă secvenţială exploatării, ci paralelă), trebuie să corecteze erorilor apărute şi
nedepistate în timpul etapei de implementare sau să îmbunătăţească funcţionalităţile şi performanţele
sistemului.
Sprijinirea utilizatorilor se realizează sub diferite forme: materiale tipărite, versiuni online,
consultanţă de specialitate. Dintre cele mai întâlnite forme de organizare a activităţii de asistenţă a
utilizatorilor enumerăm: centrele informaţionale, serviciile automate de asistare, birourile de ajutor (help
desks) sau aşa numitele centre de apel (call centers). Odată cu sporirea complexităţii sistemelor şi a
creşterii vitezei de modificare sistemelor şi-a făcut apariţia şi o nouă profesie, comunicantul tehnic
(technical communicator), care asigură întocmirea şi transmiterea documentaţiei tehnice a sistemului şi a
utilizatorului.
Atunci când sistemul este dat în exploatare se atinge şi ultima etapă a ciclului de viaţă al proiectului,
din punct de vedere al managementului de proiect, respectiv închiderea proiectului, care presupune
desfăşurarea mai multor activităţi, dintre care mai importante sunt: evaluarea finală a echipei proiectului,
degrevarea de responsabilităţi prin care se face analiza critică a sistemului, finalizarea contractului cu
beneficiarul.
Chiar dacă proiectul de dezvoltare a sistemului s-a încheiat, ciclul de viaţă al celui din urmă
continuă, prin etapa de întreţinere, care este una din cele mai costisitoare. Activităţile implicate de
întreţinere sunt: primirea cererilor de întreţinere, transformarea acestora în propuneri de schimbări,
proiectarea modificărilor şi implementarea lor. Există patru tipuri de întreţinere: corectivă, adaptivă,
perfectivă şi preventivă.
1. Care sunt formele sub care se concretizează sprijinul acordat utilizatorilor?
2. Ce este centrul informaţional?
3. Prin ce se diferenţiază centrul informaţional de un infocentru?
4. Descrieţi cele mai întâlnite servicii automate de asistare a utilizatorilor.
5. Definiţi şi prezentaţi caracteristicile biroului de ajutor.
6. Care sunt avantajele integrării componentelor web în interacţiunea utilizatorilor cu biroul de ajutor?
7. Care sunt activităţile în care este implicat comunicantul tehnic?
8. Care sunt activităţile implicate de întreţinerea sistemului?
9. Prin ce se caracterizează cele patru tipuri de întreţineri: corectivă, adaptivă, perfectivă şi preventivă?
Probleme
1. Plecând de la informaţiile pe care le găsiţi pe diferite site-uri ale firmelor specializate, identificaţi
principalele servicii pe care le pot oferi birourile de ajutor, în regim de externalizare, pentru asistenţa
utilizatorilor.
2. Identificaţi principalele competenţe şi abilităţi pe care trebuie să le deţină persoanele angajate într-un
birou de ajutor.
3. Căutaţi informaţii privind tipurile de centre de apel existente în România şi prezentaţi serviciile
oferite.
4. Având la dispoziţie informaţii privind sistemul informaţional al unei firme, încercaţi să dezvoltaţi o
procedură care să fie respectată de către utilizatorii sistemului şi personalul tehnic atunci când
solicită o modificare a sistemului.
CAPITOLUL VIII
Particularităţi conceptuale şi tehnice ale analizei şi

proiectării orientate-obiect 45
Obiective:
• Înţelegerea principalelor concepte specifice orientării-obiect
• Cunoaşterea principalelor modalităţi de reprezentare grafică specifică UML (Unified Modeling
Language)
• Exemplificarea elementelor de analiză şi proiectare orientate-obiect în contextul aplicaţiilor
economice
Apariţia obiectelor în domeniul dezvoltării softului a fost pregătită de descoperirea

importanţei abstractizării datelor. Abstractizarea datelor sau programarea bazată pe obiecte
(object based programming) contrastează cu programarea procedurală prin evidenţierea în
egală măsură a prelucrărilor şi a datelor. Programarea bazată pe obiecte uneşte datele şi
procedurile în noi tipuri de date şi permite obiectelor să fie create şi manipulate ca şi instanţe
ale tipurilor definite de utilizator. Abstractizarea este procesul de îndepărtare a detaliilor
neimportante ale unui obiect, aşa încât acesta să rămână doar cu caracteristicile necesare
studiului la care este supus. Termenul de abstractizare este folosit în sensul ascunderii pentru
utilizatori a detaliilor de implementare ale procedurilor şi datelor.
Programarea orientată-obiect (object-oriented programming) adaugă abstractizării datelor
organizarea ierarhică a claselor şi obiectelor cu ajutorul moştenirii.
Metodele de analiză şi proiectare orientate-obiect au apărut ulterior programării orientate-
obiect, pe la sfârşitul anilor 1980, ca răspuns la extinderea şi amploarea pe care o luase aceasta
din urmă. Apariţia unor metode de analiză şi proiectare specifice acestui mod de programare a
fost necesară deoarece cele două etape din dezvoltarea unui sistem informaţional trebuiau să
folosească aceleaşi concepte şi viziuni.
Utilizarea unei metode de analiză şi proiectare orientate-obiect semnifică un proces
conceptual complex, subiectiv, independent de limbajul de programare utilizat. Numărul
metodelor de analiză şi proiectare orientate-obiect, publicate în literatura de specialitate, a
crescut considerabil în perioada scursă de la apariţia primei metode şi până în prezent, la care
se adaugă cele nepublicate, clasificate ca şi secrete de firmă.
În cadrul acestui capitol, pentru reprezentarea grafică a conceptelor specifice abordării
orientate-obiect, se va folosi standardul UML, pornind de la următoarele consideraţii.
Un limbaj de modelare, privit la modul general, poate fi definit ca o serie de concepte,
principii, procedee şi mecanisme de extensie utilizabile pentru abstractizarea unor probleme
din anumite domenii. Limbajul unificat de modelare, cunoscut şi prin acronimul UML (de la
Unified Modeling Language), este un limbaj grafic destinat analizei şi proiectării orientate-
obiect a sistemelor informaţionale.
În 1994, Grady Booch, de la Rational Corporation, autorul unei metode de proiectare
orientată-obiect ce îi poartă numele şi al unor cărţi de referinţă în domeniu, împreună cu James
Rumbaugh, de la General Electric, autorul principal al metodei OMT, pun bazele unei echipe
ce se va dovedi productivă. Rezultatele se văd după un an (în octombrie 1995, cu ocazia
45. Capitol realizat de asist. univ. drd. Florin Constantin SÎRBU de la Facultatea de Economie şi Administrarea
Afacerilor, Universitatea „Al. I. Cuza” Iaşi.
conferinţei OOSLA), când cei doi stabilesc caracteristicile de bază ale unei noi metode de
analiză şi proiectare, rezultată prin unificarea metodei lui Booch (OOD) cu OMT, metodă
denumită iniţial metoda unificată (The Unified Method).
La sfârşitul anului 1995, celor doi li se alătură Ivar Jacobson, un alt nume de referinţă din
domeniu, autorul metodei OOSE (Object-Oriented Software Engineering) .
În 1996, metoda unificată îşi schimbă numele în limbajul unificat de modelare (Unified
Modeling Language) datorită faptului că eforturile iniţiale de unificare au fost concentrate
asupra limbajului grafic de modelare, a semanticii lui şi abia după aceea a modului de utilizare
a conceptelor. Schimbarea denumirii a fost justificată şi prin faptul că acest efort ştiinţific nu a
tratat iniţial şi aspecte de metodologie, permiţând astfel separarea limbajului de modelare de
procesul aplicării metodologiei. Punerea accentului pe limbaj nu echivalează cu ignorarea
modului de folosire a acestuia.
În 1997, apare versiunea 1.0, ce conţinea o documentaţie mai detaliată decât versiunile
anterioare, versiune ce este propusă OMG-ului (Object Management Group) pentru
standardizare. Răspunsul pozitiv al celor de la OMG vine în acelaşi an, UML devenind astfel
un limbaj standard de modelare orientată-obiect.
De la standardizare şi până în prezent au mai apărut şi alte versiuni ale limbajului unificat
de modelare, cum ar fi: versiunea 1.5, din martie 2003, şi versiunea 2.0, din septembrie 2005.
UML nu este o metodă de proiectare, ci un limbaj universal pentru modelarea şi realizarea
oricărui tip de sistem, de orice mărime, asigurând posibilităţi unitare de reprezentare grafică în
toate fazele dezvoltării unui sistem informatic: definirea cerinţelor, analiză, proiectare,
implementare, testare, instalare, întreţinere.
Conform definiţiei date chiar de OMG46, UML este un limbaj vizual pentru specificarea,
construirea şi documentarea elementelor sistemelor. Este un limbaj de modelare universal ce
poate fi folosit cu toate metodele obiectuale şi în toate domeniile de aplicaţii (de exemplu,
economie, sănătate, telecomunicaţii, gestiunea fluxurilor de lucru) şi pe toate platformele de
implementare (de exemplu, J2EE, .NET).
Nu toate posibilităţile de modelare pe care le oferă sunt necesare în toate domeniile de
aplicaţii. Acest lucru sugerează că limbajul trebuie structurat modular, cu posibilitatea de a
selecta doar acele părţi ale limbajului care sunt de interes într-un anumit proces de modelare.
Pe de altă parte, un exces de flexibilitate creşte probabilitatea ca două instrumente diferite
UML să suporte subseturi diferite de limbaj, ducând la probleme de interacţiune între ele.
UML 2.0 conţine două specificaţii complementare: infrastructura UML (UML
Infrastructure) şi superstructura UML (UML Superstructure). Dacă prima specificaţie prezintă
componentele fundamentale ale limbajului, partea a doua prezintă constructorii accesibili
utilizatorilor acestui limbaj.
Metamodelul UML a fost creat ţinându-se cont de următoarele principii:
• principiul modularităţii se asigură printr-o coeziune strânsă şi cuplare slabă cu
ajutorul pachetelor şi organizarea metaclaselor;
• principiul stratificării presupune separarea conceptelor pe diferite niveluri de
abstractizare;
• principiul partiţionării folosit pentru a organiza zone în cadrul aceluiaşi nivel de
abstractizare;
• principiul extensibilităţii se asigură prin două modalităţi:
– definirea de profile (Profiles) pentru a adapta limbajul anumitor platforme (de
exemplu, J2EE sau .NET) şi domenii (de exemplu, economie, finanţe etc.);
– definirea unui nou limbaj, înrudit cu UML, prin reutilizarea unor elemente din
infrastructura UML şi adăugarea metaclaselor necesare;
• principiul refolosirii, asigurat de un metamodel flexibil.
46. *** – Unified Modeling Language (UML) Specification: Infrastructure, version 2.0, OMG, 2004, p. 10.
PARTICULARITĂŢI ALE ANALIZEI ŞI PROIECTĂRII ORIENTATE-OBIECT 151
În domeniul dezvoltării sistemelor informaţionale, UML poate fi aplicat oricărei metode

de analiză şi proiectare orientate-obiect ce respectă principiile de mai sus. Locul UML în
cadrul procesului de dezvoltare software este prezentat în specificaţiile OMG, denumite
Software Process Engineering Metamodel (SPEM), ca în figura 8.1.
MetaObject Facility M3 MOF
MetaModel M2 UML
Model M1 RUP
MetaObject Facility M0 Un anumit proiect
47
Fig. 8.1 Niveluri de modelare conform SPEM
Exemple de metode de analiză şi proiectare orientate-obiect ce ar putea folosi ca limbaj

grafic UML sunt: Rational Unified Process (RUP), DMR Macroscope, IBM Global Services
Method şi Fujitsu SDEM. Dintre aceste metode se remarcă RUP, denumit şi procesul unificat
(Unified Process), care îi are ca autori pe cei din grupul de cercetători de la Rational
Corporation, ce au participat şi la realizarea UML.
UML presupune o metodologie sistemică aplicată unui proces iterativ şi incremental,
condus prin cazuri de utilizare şi centrat pe o arhitectură, fiind principalele caracteristici ale
procesului unificat. Detaliile acestui proces se adaptează la factori cum ar fi: domeniul
aplicaţiei, experienţa şi organizarea echipei de dezvoltatori.
Un proces software iterativ presupune o detaliere succesivă a arhitecturii, astfel încât
fiecare nouă versiune a acesteia se bazează pe experienţa şi rezultatele obţinute din versiunea
anterioară.
Un proces software incremental presupune că fiecare trecere printr-un ciclu de viaţă, de la
culegerea cerinţelor şi până la întreţinere, conduce spre o detaliere treptată a deciziilor
strategice şi tactice, obţinându-se în ultimă instanţă soluţionarea cerinţelor reale ale
utilizatorului, sistemul rămânând însă simplu, fiabil şi adaptabil.
Una din iniţiativele OMG este Arhitectura Bazată pe Modele (Model Driven Architecture,
MDA), o arhitectură conceptuală evolutivă, destinată unui set de specificaţii tehnologice larg
răspândite, ce sprijină o abordare bazată pe modele a procesului de dezvoltare software.
Ideal ar fi ca pentru descrierea sistemului să se folosească un singur grup de diagrame,
însă, de cele mai multe ori, acesta nu poate să surprindă toate informaţiile necesare descrierii
sistemului sau ar amesteca diferite aspecte de urmărit în dezvoltarea unui sistem informaţional.
Astfel, în UML putem apela la următoarele tipuri de diagrame pentru modelarea sistemului:
• diagramele cazurilor de utilizare arată funcţiile de prelucrare la care au acces
diferitele categorii de utilizatori (actori);
• diagramele de clase conţin seturi de clase (inclusiv interfeţe) şi relaţiile dintre acestea,
reflectând aspectul static al sistemului;
• diagramele de obiecte conţin mulţimi de obiecte şi relaţiile acestora;
• diagramele stărilor de tranziţie arată o serie de stări, tranziţii, evenimente şi activităţi
ale obiectelor;
• diagramele de activitate un tip de diagramă de stări ce arată evoluţia de la o activitate
la alta într-un sistem;
47.*** – Software Process Engineering Metamodel, version 1.1, OMG, 2005, p. 1-2.
• diagramele de secvenţă sunt diagrame de interacţiune ce evidenţiază ordinea realizării

prelucrărilor (transmiterii mesajelor);
• diagramele de comunicare sunt diagrame de interacţiune ce evidenţiază organizarea
structurală a obiectelor ce trimit şi primesc mesaje;
• diagramele de componente arată organizarea şi dependenţa între un set de
componente;
• diagramele de amplasare arată configuraţia la rulare a nodurilor şi a componentelor ce
există în ele.
Aceste diagrame UML pot fi împărţite în două mari categorii: diagrame de structură şi
diagrame de comportament.
Diagramele de structură arată structura statică a elementelor unui sistem, prin prezentarea
acestora într-o specificaţie independentă de factorul timp. Elementele dintr-o diagramă de
structură reprezintă conceptele semnificative ale unei aplicaţii şi pot include concepte
abstracte, ale lumii reale sau de implementare. Diagramele de structură nu arată detaliile
comportamentului obiectelor, căci acestea sunt ilustrate în diagramele de comportament.
Diagramele de comportament prezintă dinamica unui sistem prin descrierea seriilor de
schimbări posibile ale acestuia în decursul timpului.
Această taxonomie asigură o organizare logică a tipurilor de diagrame, dar nu înlătură
mixarea lor, cum ar fi combinarea unor elemente structurale cu altele comportamentale, prin
prezentarea unor stări de tranziţie într-o structură internă. În consecinţă, graniţele dintre
diferite tipuri de diagrame nu sunt impuse în mod strict.
Figura 8.2 reflectă împărţirea tipurilor de diagrame în cele două categorii, aşa cum este ea
prezentată chiar în cadrul standardului UML.
Folosirea diagramelor UML ca modalitate de reprezentare a unui sistem informaţional
economic, nu exclude folosirea unor descrieri narative ale sistemului, în toate etapele de
dezvoltare a acestuia.
Diagrame
Diagrame Diagrame de
de structură comportament
Diagrame de clase
structură compusă
Diagrame stărilor
Diagrame cazuri
de interacţiune
Diagrame de
componente
Diagrame de
Diagrame de
Diagrame de
de utilizare
de tranziţie
amplasare
de pachete
de obiecte
Diagrame
Diagrame
activitate
Diagrame
Diagrame de
Diagrame de
comunicare
secvenţă
Fig. 8.2 Tipurile de diagramă de structură şi de comportament
8.1 Concepte ale abordării orientate-obiect

Conform metodelor orientate-obiect, în fiecare etapă de dezvoltare se construiesc modele,
reprezentate grafic cu ajutorul unor diagrame. Deşi, aceste modele sunt axate pe anumite
componente şi perspective diferite ale sistemului informaţional, între ele există legături
puternice. Conceptele cu care operează abordarea orientată-obiect, sunt: obiecte şi clase,

identitate, stare şi comportament, asocieri, dependenţe şi derivări, redefinire, componente.
8.1.1 Obiecte şi clase

În literatura de specialitate există numeroase definiţii ale termenului de obiect, dintre care
pe cele mai relevante le prezentăm în continuare:
• obiectele sunt principala unitate structurală a programării orientate-obiect. Clasele
sunt „template-uri” ale obiectelor. Clasele sunt ca şi tipurile de date din limbajele
tradiţionale de programare, iar obiectele sunt asemănătoare cu variabilele48;
• un obiect are o stare, un comportament şi o identitate; structura şi comportamentul
unor obiecte similare sunt definite în clasa lor comună. Termenii de instanţă şi obiect
sunt interschimbabili49;
• un obiect este o colecţie de date şi procedurile destinate prelucrării acestora50;
• un obiect este o încapsulare a stării (valorii datelor) şi comportamentului
(operaţiilor)51;
• un obiect este un element al unui sistem informatic ce are o identitate unică, o stare
(reprezentată de date publice sau private) şi operaţii (metode) publice şi private, ce
reprezintă comportamentul obiectului în decursul timpului52;
• un obiect este ceva distinct, identificabil, pentru care sistemul trebuie să stocheze date
pentru a realiza activităţile fundamentale în sistem53;
• obiectul este o componentă a descrierii bazei de date logice ce reprezintă o entitate a
lumii reale despre care sunt stocate informaţii54;
• obiectele sunt componente active ce prezintă un comportament când sunt stimulate de
mesaje sau tranzacţii55.
Din definiţiile de mai sus se desprind trei puncte de vedere folosite pentru descrierea
noţiunii de obiect:
1. structural, când obiectul este văzut ca o instanţă a unui tip de dată caracterizat de o
structură ascunsă prin operaţii (se prezintă ce conţine obiectul);
2. conceptual, când obiectul este văzut ca fiind corespondentul unui concept din lumea
reală (se prezintă ce abstractizează obiectul);
3. actor, când obiectul este văzut ca o entitate activă care răspunde la mesaje (se prezintă
ce face obiectul).
Noţiunea de mesaj dintre obiecte, folosit în abordarea obiectuală, înseamnă apelarea
procedurilor unui obiect de către alt obiect.
Prezentarea abordării obiectuale, în contextul aplicaţiilor economice, ne determină să
prezentăm uneori obiectul din punct de vedere conceptual, comparându-l cu un alt
corespondent al elementelor din lumea reală: entitatea din modelul relaţional de organizare a
datelor. În descrierea unui anumit sistem modelat orientat-obiect, nu trebuie însă minimalizată
prezentarea structurii şi funcţionalităţii fiecărei clase de obiecte.
48. Voss, G. – Object-Oriented Programming. An Introduction, Osborne McGraw-Hill, Berkeley, 1991, pp. 19-21.
49. Booch, G. – Object-Oriented Analysis and Design with Applications, Addison Wesley, New York, 1994, p. 516.
50. Marchesi, M. – Object-Oriented Programming with Smalltalk/V, Prentice Hall International Ltd, London, 1994,
p. 1.
51. Budd, T. – An Introduction to Object-Oriented Programming, Second Edition, Addison Wesley, Reading,
Massachusetts, 1998, p. 22.
52. Wilkie, G.– Object-Oriented Software Engineering, Addison Wesley, Reading, Massachusetts, 1993, p. 386.
53. Koval, J. A. – Analyzing Systems, Prentice Hall, Upper Saddle River, New Jersey, 1988, p. 184.
54. Martin, J. – Information Engineering: Book II – Planning & Analysis, Prentice Hall, Englewood Cliffs, New
Jersey, 1990, p. 474.
55. *** – Foundation of Business Systems, Second Edition, Andersen Consulting – Arthur A. Andersen & Co. S.C.,
Dryden, 1989, p. 233.
Clasele de obiecte sunt tipuri abstracte de date care definesc structura obiectelor din acea
clasă (setul de date şi prelucrările reunite). Clasele sunt aranjate într-o ierarhie, în aşa fel încât
ele pot moşteni o parte din structură (date şi prelucrări) de la propriii părinţi.
O clasă este considerată clasă abstractă dacă nu este folosită pentru a crea obiecte direct
prin ea, ci este folosită doar pentru a crea alte clase. Termenul de metaclasă desemnează clasa
unei clase.
Caracteristicile esenţiale ale metodei orientate-obiect sunt56:
• orice este un obiect;
• prelucrările sunt realizate de obiecte ce comunică între ele, cerând unul altuia să
execute anumite acţiuni. Obiectele comunică prin transmiterea şi primirea mesajelor.
Un mesaj este cererea pentru o acţiune, însoţită de anumite argumente ce pot fi
necesare îndeplinirii acesteia;
• fiecare obiect are propria memorie, ce este, la rândul ei, alt obiect;
• orice obiect este instanţa unei clase. O clasă reprezintă o grupare a unor obiecte
similare;
• clasa este dicţionarul comportamentului asociat unui obiect, aşa încât toate obiectele ce
sunt instanţe ale aceeaşi clase pot realiza aceleaşi acţiuni;
• clasele sunt organizate într-o singură structură arborescentă, numită ierarhia claselor
sau ierarhia moştenirii. Memoria şi comportamentul, asociate cu instanţele unei clase,
sunt disponibile automat oricărei clase descendente acesteia, în structura arborescentă.
În urma acestei incursiuni în câteva dintre elementele specifice orientării-obiect, putem
concluziona că:
• o clasă este o colecţie de date şi proceduri ce abstractizează un element al lumii reale.
• un obiect este o implementare a unei clase, de la aceasta luând structura şi
comportamentul.
Tipuri aparte de clase sunt cele ce reprezintă grupurile de utilizatori ai sistemului, inclusiv
alte sisteme cu care se interacţionează. Termenul folosit pentru desemnarea acestora este de
actor. Actorii nu fac parte din sistem, fiind doar generatori de evenimente, având acelaşi rol ca
şi entităţile externe (sursele sau destinaţiile fluxurilor de date) din modelarea structurată, cu
ajutorul diagramelor fluxurilor de date. În figura 8.3, se prezintă modalitatea de reprezentare
grafică a actorilor, propusă în UML.
Fig. 8.3 Simbolul UML de reprezentare a actorilor
8.1.2 Identitatea, starea şi comportamentul

Aşa cum am văzut, elementele prin care se caracterizează un obiect sunt: identitatea,
starea şi comportamentul.
Identitatea unui obiect este reprezentată printr-un identificator unic (UID), care permite
diferenţierea obiectelor între ele. Nu trebuie făcută nici o confuzie între identitatea unui obiect
şi noţiunea de cheie primară, întâlnită în cazul bazelor de date relaţionale, care se bazează pe
unicitatea valorilor unui atribut sau a unui grup de atribute (identificare în funcţie de conţinut).
În cazul obiectelor, avem de-a face cu identificatori interni, fără nici o legătură cu
identificatorii impliciţi, prin care se realizează diferenţierea obiectelor între ele.
Starea unui obiect este dată de valorile atributelor pe care le conţine. De exemplu,
obiectul „clientul SC ALFA SRL” are o anumită adresă, un anumit număr de telefon, nu este
incert etc. Când se schimbă starea obiectului, nu este afectată în nici un fel identitatea acestuia.
Atributele unui obiect nu trebuie să aparţină, în mod obligatoriu, unor tipuri scalare de date, ci
pot fi la rândul lor alte obiecte.
Comportamentul obiectului se referă la serviciile pe care le oferă altor obiecte. Aceste
servicii sunt asigurate prin operaţiile pe care le conţine datorită instanţierii sale dintr-o anumită
clasă. Cererile adresate unui obiect pentru a întoarce o valoare sau pentru a schimba o stare se
numesc mesaje. Un obiect primeşte mesaje de la alte obiecte şi răspunde acestora prin
intermediul serviciilor pe care le oferă. De exemplu: „afişează soldul curent” sau „schimbă
adresa” sunt o operaţii posibile asupra obiectului „clientul SC ALFA SRL”.
Dacă o metodă este văzută în mod asemănător cu o procedură dintr-un limbaj
convenţional, atunci trimiterea unui mesaj este similară cu apelarea unei proceduri. Diferenţa
între transmiterea mesajelor şi apelarea procedurilor este aceea că în transmiterea mesajelor
există un receptor, iar interpretarea (selecţia unei metode pentru a fi executată ca răspuns al
mesajului) poate varia de la un receptor la altul57.
Componentele unui mesaj sunt: receptorul (obiectul căruia i se cere să execute o metodă),
selectorul (metoda cerută a fi declanşată receptorului) şi argumentele (parametrii metodei).
Rezultatul mesajului este şi el o referire a unui obiect şi este trimis expeditorului
mesajului. Odată ce un mesaj a fost trimis unui obiect, obiectele din afară, nu pot şi nici nu ar
trebui să ştie cum, să prelucreze datele în obiect.
Metodele unui obiect pot fi de actualizare sau doar de citire. Metodele de actualizare sunt
cele ce modifică valorile atributelor propriului obiect, pe când metodele destinate citirii nu
afectează aceste valori, ci doar le citeşte în vederea realizării anumitor operaţii. În mod analog,
pot fi clasificate mesajele la care răspund obiectele, după metoda la care fac referire.
Metodele fără nici o implementare (care nu conţin cod) se numesc metode abstracte şi pot
apărea doar în clase abstracte.
Tipuri aparte de metode sunt constructorii şi destructorii.
Un constructor este o metodă care creează un obiect, în sensul ca îi alocă spaţiu şi/sau
iniţializează atributele acestuia şi nu întoarce nici o valoare. Constructorii sunt apelaţi automat
la instanţierea unui obiect. Prezenţa constructorilor în corpul unei clase nu este obligatorie, o
clasă poate să nu aibă nici un constructor, să aibă unul sau mai mulţi constructori. Dacă o clasă
are mai mulţi constructori, aceştia trebuie să difere prin semnătură (lista de argumente primite).
În felul acesta, sunt permise diverse tipuri de iniţializări ale obiectului la crearea sa, în funcţie
de numărul şi tipul parametrilor cu care este apelat constructorul.
Destructorul este o metoda care încheie ciclul de viaţă al unui obiect, eliberând spaţiul pe
care acesta l-a ocupat.
În vederea ascunderii detaliilor de implementare a atributelor unei clase şi a operaţiilor
acesteia, se poate controla accesul la aceste resurse prin definirea unor operaţii speciale.
Această ascundere se defineşte cu ajutorul unor atribute de vizibilitate, care se pot asocia
atributelor şi operaţiilor dintr-o clasă. Atributele de vizibilitate şi reprezentarea lor în UML
sunt prezentate în tabelul 8.1:
Tabel nr. 8.1 – Atributele de vizibilitate şi reprezentarea lor în UML

Vizibilitate Disponibilitate Simbol UML
Public oricărei clase +
Protejat numai în cadrul propriei clase şi subclaselor #
Privat numai înăuntrul propriei clase -
Practic, încapsularea maschează atributele unei clase, modul propriu de execuţie a

operaţiilor, dând posibilitatea clasei de a evolua în timp, fără să afecteze întregul sistem.
Încapsularea facilitează materializarea unui avantaj oferit de orientarea-obiecte, şi anume:
reutilizarea. Încapsularea este complementară abstractizării, aceasta din urmă ocupându-se de
partea exterioară, iar încapsularea împiedică accesul în interior, acolo unde este implementată
manifestarea abstractizării.
Pentru atributele de vizibilitate, se mai pot declara:
• tipul de dată – sub forma: tip_data;
• valoarea iniţială – sub forma: valoare_iniţială;
• cardinalitatea;
• lista de proprietăţi – se declară între acolade {} şi se utilizează pentru a reprezenta
caracteristici suplimentare, atunci când este cazul.
Operaţiile pot fi declarate împreună cu eventualii parametrii şi cu tipul de dată returnat.
Tipurile posibile de parametri sunt: In (parametri de intrare), Out (parametri de ieşire) şi InOut
(parametri de intrare/ieşire).
Simbolul folosit în UML pentru reprezentarea unei clase este un dreptunghi în care sunt
evidenţiate trei componente: numele clasei, atributele şi operaţiile clasei. Completarea acestor
trei părţi se face ţinând cont de următoarele reguli:
• dacă respectiva clasă este abstractă (neinstanţiabilă direct), numele ei se scrie cu
caractere italice;
• deasupra numelui clasei, se scrie stereotipul acesteia între caracterele „<< >>”, dacă
există;
• în faţa numelui clasei se scrie, dacă există, metaclasa specializată prin aceasta;
• în faţa numelor atributelor şi a operaţiilor se scrie simbolul de vizibilitate;
• numele fiecărui atribut este urmat de tipul de dată al acestuia;
• tipurile de dată ale atributelor pot fi precedate de valorile iniţiale ale acestora;
• dacă o operaţie este abstractă (nu are nici o metodă care să o implementeze), toate
proprietăţile ei se scriu cu caractere italice;
• operaţiile sunt urmate de lista de parametri, prezentată între paranteze rotunde „( )”;
• în faţa numelui fiecărui parametru se specifică tipul acestuia;
• după numele fiecărui parametru se scrie caracterul două puncte „:” şi tipul de dată al
acestuia;
• parametrii operaţiilor, cu toate proprietăţile acestora, se despart cu caracterul virgulă;
• chiar dacă o operaţie nu are nici un parametru, după numele acesteia, tot se scriu
parantezele rotunde;
• dacă o operaţie întoarce o valoare, după închiderea parantezei rotunde, destinate
specificării parametrilor, se scrie caracterul două puncte şi tipul de dată al valorii
întoarse.
«Stereotip»
Nume_MetaClasa::Nume_Clasa
+Atribut public : Tip_Data = Valoare_Initiala
#Atribut protejat : Tip_Data = Valoare_Initiala
-Atribut privat : Tip_Data = Valoare_Initiala
+Operatie publica(in Parametru_1 : Tip_Data = Valoare_implicita, out Parametru_N : Tip_Data) : Tip_Data
#Operatie protejata(in Parametru_1 : Tip_Data, inout Parametru_i : Tip_Data, out Parametru_N : Tip_Data) : Tip_Data
-Operatie privata() : Tip_Data
Fig. 8.4 Simbolul folosit în UML pentru reprezentarea claselor
Simbolul folosit în UML pentru reprezentarea unui obiect instanţiat dintr-o anumită clasă
este tot un dreptunghi în care sunt evidenţiate doar două din cele trei părţi: identitatea şi
starea. A treia parte, comportamentul, nu se reprezintă şi în simbolul fiecărui obiect, deoarece
acesta este comun tuturor obiectelor instanţiate din aceeaşi clasă. În partea destinată stării se
prezintă valorile curente ale fiecărui atribut, aşa cum este prezentat în figura 8.5.
«Stereotip»
Nume_Obiect : Nume_MetaClasa::Nume_Clasa
Atribut public : Tip_Data = Valoare_Curenta
Atribut protejat : Tip_Data = Valoare_Curenta
Atribut privat : Tip_Data = Valoare_Curenta
Fig. 8.5 Simbolul folosit în UML pentru reprezentarea obiectelor
În figura 8.6, se prezintă un exemplu de reprezentare grafică a clasei „Angajat” şi a

obiectului „Popescu Ion” instanţiat din această clasă.
Angajat Popescu Ion : Angajat
-Marca : Char Marca : Char = 1001
-Nume : Char Nume : Char = Popescu
-Prenume : Char Prenume : Char = Ion
-Functia : Char Functia : Char = agent vânzari
-CNP : Char CNP : Char
+Informeaza(in Raport : Char)
Fig. 8.6 Exemple de clase şi obiecte
Termenul de interfaţă desemnează serviciile oferite de clase sau componente. Interfaţa

unei clase se specifică prin operaţiile ce pot fi invocate de o clasă client. Operaţiile sunt
implementate cu ajutorul metodelor. Specificarea unei operaţii în cadrul unei clase se numeşte
semnătură, iar modul de implementare se numeşte corpul metodei.
Interfeţele descriu comportamentul vizibil din exterior al claselor sau componentelor; nu
specifică niciodată implementarea acestor operaţii. Interfeţele pun în practică unul din
conceptele abordării orientate-obiect, de separare a structurii unui obiect de implementarea sa.
Aşadar, o interfaţă poate fi privită ca un protocol de comunicare între obiecte. O clasă poate
implementa una sau mai multe interfeţe, depinzând de funcţionalităţile pe care le
implementează.
O interfaţă se reprezintă în UML cu un dreptunghi în care sunt prezentate: numele
acesteia şi operaţiile ei publice, ca în figura 8.7:
«interface»
Interfata
+Operatie1()
+Operatie2()
Fig. 8.7 Simbolul folosit în UML pentru reprezentarea interfeţelor
De exemplu, într-o aplicaţie economică, clasele de tranzacţii ce modifică patrimoniul

unităţii pot să implementeze următoarea interfaţă destinată contabilizării respectivelor
modificări:
«interface»
Contabilizare
+Get_Note_Contabile(out Debit, out Credit, out Suma)
+Set_Plan_de_conturi(in Plan_de_conturi)
Fig. 8.8 Exemplu de interfaţă
8.1.3 Relaţiile dintre elemente

Pentru a asigura funcţionalitatea aplicaţiilor între elementele specifice orientării-obiect se
stabilesc o serie de relaţii, şi anume: asocieri, dependenţe, derivări.
8.1.3.1 Asocieri
Asocierile sunt relaţii între două sau mai multe clase, prin care se modelează
interdependenţe între obiectele instanţiate din clasele respective. Un exemplu de asociere poate
fi: „un mijloc fix este în gestiunea unui anumit gestionar”.
O instanţă a unei asocieri poartă numele de legătură, ea descriind relaţia dintre două sau
mai multe obiecte. Un exemplu de legătură poate fi: „Mijlocul fix cu numărul de inventar
331265 este în gestiunea lui Gestionărescu Fix”.
Asocierile dintre clase au câte un rol (o explicaţie) pentru fiecare clasă participantă. Un
rol poate fi privit ca o imagine a unui obiect. Între două clase pot exista mai multe asocieri,
fiecare cu roluri distincte. De exemplu, între clasa „Bon_de_transfer” şi clasa „Gestiune” pot
exista două asocieri, una privind gestiunea în care se transferă şi cea de a doua asociere privind
gestiunea de la care se transferă.
Asocierile au pentru fiecare element pe care îl leagă o cardinalitate (multiplicitate)
corespunzătoare numărului de obiecte ce pot apărea la instanţiere sub forma:
- 1 – unul şi doar un obiect;
- 0..1 – nici unul sau maxim un obiect;
- 0..* – nici unul sau mai multe obiecte;
- * – tot zero sau mai multe obiecte;
- 1..* – unul sau mai multe obiecte;
- 1..n – unul sau maxim n obiecte;
- 0..n sau n – nici unul sau maxim n obiecte;
- nl, n2, n3 – înşiruire de numere, care exprimă numărul de obiecte;
- n - m – număr de obiecte cuprins între n şi m.
În funcţie de numărul de elemente pe care le leagă, asocierile pot fi: binare sau n-are. În
UML, o asociere binară se reprezintă grafic printr-o linie dreaptă ce uneşte cele două
elementele implicate. Când elementele unite sunt actori, cazuri de utilizare sau clase, pe aceste
linii se pot specifica rolurile şi cardinalităţile elementelor.
Fig. 8.9 Reprezentarea grafică în UML a unei asocieri binare
Asocierile n-are se reprezintă, în UML, cu ajutorul unui romb, de la care pleacă spre
fiecare element implicat în relaţie câte o linie dreaptă, pe care se poate ataşa cardinalitatea şi
rolul specific elementului respectiv.
* *
*
Fig. 8.10 Reprezentarea grafică în UML a unei asocieri n-are
Când un element se asociază cu el însuşi se obţine o asociere reflexivă. De exemplu, acest

tip de asociere poate arăta legăturile dintre obiectele aceleiaşi clase.
0..1
Doc_insotire
-Numar : Char
-Data : Date
-Doc_anterior : Doc_insotire -corespunde
+Get_Valoare_fara_TVA() : Decimal
+Get_TVA() : Decimal
+Get_Valoare_cu_TVA() : Decimal 0..1
Fig. 8.11 Reprezentarea grafică în UML a unei asocieri reflexive
Asocierea reflexivă din figura 8.11 arată faptul că unele documente însoţitoare (cum ar fi
avizele de expediţie) pot corespunde altor documente justificative (cum ar fi facturile). Tot
asocieri reflexive s-ar obţine şi la prezentarea asocierilor dintre un angajat şi şeful său ierarhic,
sau la asocierea dintre un document justificativ şi documentul său de stornare.
Când o asociere are caracteristicile unei clase ea este denumită clasă de asociere. De
exemplu, asocierea dintre clasa ce defineşte notele de recepţie şi clasa ce defineşte materialele
dintr-un sistem de gestiune a materiilor prime, poate avea propriile atribute (cantitatea şi preţul
fiecărui material) şi propriile operaţii (calcularea cantităţii rămase de consumat dintr-un anumit
material şi o anumită notă de recepţie necesară într-un sistem ce foloseşte metoda FIFO, ca
metodă de evaluare a stocurilor). Simbolul folosit în UML pentru reprezentarea unei clase de
asociere este cel al unei clase, unite de asocierea respectivă printr-o linie întreruptă.
Clasa de asociere
* *
Fig. 8.12 Reprezentarea grafică în UML a unei clase de asocieri binare
O clasă de asociere poate uni mai mult de două elemente, caz în care ea este denumită
clasă de asociere n-ară.
Clasa de asociere
* *
*
Fig. 8.13 Reprezentarea grafică în UML a unei clase de asocieri n-are

Uneori, asocierile dintre două elemente presupun o anumită ordine a obiectelor
instanţiate. De exemplu, mărfurile dintr-o anumită factură sunt ordonate într-un anumit mod, în
aşa fel încât reproducerea exactă a unei anumite facturi presupune şi persistenţa ordinii
mărfurilor referite. În aceste cazuri se vorbeşte de o asociere ordonată.
Când o clasă este implicată în mai multe asocieri şi nu pot exista instanţe simultane ale
claselor cu care se află în asociere, asocierile se conectează printr-o linie întreruptă, cu eticheta
XOR.
Un tip aparte de asociere este agregarea, cu ajutorul căreia o clasă poate fi modelată, ca
fiind parte a unei alte clase. O clasă agregat este o clasă ale cărei obiecte conţin alte obiecte.
De exemplu, o comandă conţine, pe lângă datele specifice acestui tip de tranzacţie, şi obiecte
de tipul produselor.
Agregările se pot clasifica în:

• agregări fixe: au număr fix de componente; de exemplu, un lot de produse poate avea
fix cinci tipuri de produse;
• agregări variabile: au un număr finit, dar variabil de componente; de exemplu, mai
multe produse pot face parte dintr-un lot pregătit pentru livrare, dar numărul acestora
nu este fix;
• agregări recursive: au componente de acelaşi tip; de exemplu, asocierea dintre un
departament şi birourile componente.
În cazul în care părţile componente au aceeaşi durată de viaţă cu a întregului şi se pot
regăsi fizic în cadrul acestuia, avem de-a face cu un caz particular de agregare, numit
compoziţie. În cadrul compoziţiei, clasa compusă nu poate să participe şi la alte agregări, pe
când operaţia clasică de agregare, numită şi agregare partajată, permite participarea unei clase
agregat la oricâte agregări.
Simbolul UML pentru agregare este rombul. În cazul agregărilor partajate acest romb este
gol la mijloc, iar în cazul agregărilor compuse acesta este plin.
-partajeaza
1 *
Fig. 8.14 Reprezentarea grafică în UML a unei agregări partajate
Fig. 8.15 Reprezentarea grafică în UML a unei compoziţii
Alt tip de asociere este comunicarea, care indică o asociere între un actor şi un caz de
utilizare, reprezentându-se grafic ca o asociere binară simplă, ce poate avea anumite
cardinalităţi şi anumite roluri.
Asocierea ce reprezintă trecerea unui obiect dintr-o stare într-o altă stare se numeşte
tranziţie. Ea se reprezintă grafic prin adăugarea la linia unei asocieri a unei săgeţi care arată
starea destinaţie.
Fig. 8.16 Reprezentarea grafică în UML a unei tranziţii
8.1.3.2 Dependenţe
Dependenţa este o relaţie între două elemente prin care schimbările într-un element sursă
pot determina schimbări în elementul destinaţie. O dependenţă leagă elementele fără a fi
necesară o instanţiere, de aceea nu are cardinalităţi. Relaţia de dependenţă este unidirecţională,
un element fiind considerat independent, iar celălalt, dependent. Modificările asupra
elementului independent se vor reflecta şi asupra elementului dependent.
De exemplu, dependenţa apare în cazul relaţiilor dintre două clase între care există relaţii
de încredere, denumite clase prieten (friend), în care o clasă oferă altei clase accesul la
elementele protejate, chiar dacă între ele nu există asociere directă. Simbolul folosit în UML
pentru reprezentarea dependenţelor este o linie întreruptă care are la un capăt o săgeată ce arată
elementul dependent.
Fig. 8.17 Reprezentarea grafică în UML a unei dependenţe

8.1.3.3 Derivări
Derivarea este o relaţie între două sau mai multe clase, prin care se modelează
similitudinile şi diferenţele specifice dintre acestea. Derivarea este capacitatea de a declara un
tip pe baza unor elemente (atribute şi operaţii) ale unui tip declarat anterior. Pornind de la o
clasă, se pot deriva noi clase ce adaugă diferenţe specifice.
Conceptul de derivare este probabil cel mai important concept al abordării orientate-
obiect, după conceptul de clasă. Aşa cum toate limbajele orientate-obiect sprijină conceptul de
clasă, toate aceste limbaje sprijină şi conceptul de derivare. Lipsa posibilităţii de derivare într-
un mediu de programare, ce foloseşte clase şi obiecte, împiedică folosirea în acest caz a
termenului de programare orientată-obiect, vorbindu-se doar de o programare bazată pe obiecte
sau, altfel spus, abstractizare a datelor.
Termenii de specializare, generalizare, moştenire se referă la relaţia de derivare.
Termenul de moştenire este folosit mai mult în legătură cu reutilizarea atributelor şi metodelor
clasei de bază. Prin intermediul acestei relaţii, obiectele unei clase derivate moştenesc atribute
şi metode ale clasei de bază la care se adaugă membrii clasei proprii.
Relaţia de derivare este reprezentată în UML printr-o linie dreaptă care are la un capăt un
triunghi gol, ce arată clasa generală ce este supusă specializării.
Fig. 8.18 Reprezentarea grafică în UML a unei relaţii de derivare
Un tip particular de derivare este extensia. Prin ea, un element (clasă, componentă sau caz
de utilizare) extinde comportamentul unui alt element prin adăugarea unor comportamente noi.
Extensia se reprezintă în UML prin specificarea stereotipului extends pe simbolul unei
derivări.
Fig. 8.19 Reprezentarea grafică în UML a unei relaţii de extensie
Termenul de ierarhie de clase desemnează clase între care există relaţii de derivare. Clasa
din care derivă o altă clasă poartă numele de metaclasă. După aceeaşi regulă morfologică, un
model din care derivă alt model poartă numele de metamodel. Clasa derivată dintr-o altă clasă
poartă numele de subclasă.
O clasă poate deriva dintr-o singură clasă, când apare moştenirea simplă, sau din mai
multe clase, vorbind de moştenire multiplă. Nu toate mediile de programare orientate-obiect au
implementată moştenirea multiplă, deoarece este dificil de utilizat şi dezvoltat în timp.
Problemele moştenirii multiple apar când metaclasele au atribute şi/sau operaţii cu acelaşi
nume, iar clasa specializată din acestea trebuie să facă referire numai la una sau la o
combinaţie a acestora. Când o clasă moşteneşte un element de la mai mult de o clasă, se
vorbeşte de generalizare suprapusă (overlapping). Opusul generalizării suprapuse poartă
numele de generalizare disjunctă (disjoint).
În funcţie de capacităţile de derivare, clasele pot fi clase rădăcină (root classes), în sensul
că nu pot avea predecesori, şi clase frunză (leaf classes), indicând faptul că nu pot avea
descendenţi.
Atunci când unei clase nu i se mai pot face alte specificaţii de subclase se vorbeşte de
generalizare completă. Generalizarea incompletă apare atunci când o clasă se mai poate
specializa şi în alte subclase.
Avantajele oferite de derivare sunt date de posibilităţile de reutilizare a codului şi de
extensibilitate a sistemului creat. O serie de resurse de bază, puse la punct în anumite aplicaţii,
pot fi uşor refolosite în alte aplicaţii, prin derivări succesive. Timpul de testare scade, aceste
resurse de pornire fiind probabil deja testate. Mai mult, pot fi refolosite resurse chiar şi fără o
înţelegere temeinică a implementării ce se ascunde în spatele lor.
O resursă existentă poate fi extinsă, atât prin versiune, adică prin adăugare de metode noi,
cât şi prin re-specializare, prin derivarea de noi ramuri în cadrul unei ierarhii de clase. Chiar şi
bibliotecile de clase, a căror implementare nu este disponibilă sub formă de fişiere sursă, pot fi
uşor extinse prin derivări (specializări) succesive.
Relaţia de derivare prezintă şi un dezavantaj: astfel de relaţii nu pot să apară pe parcursul
rulării unei aplicaţii.
8.1.4 Redefinire în abordarea obiectuală

Redefinirea se împarte în două categorii. Una statică (supraîncărcare, over-loading), ce
are loc în faza de compilare şi se aplică atât la metodele unei clase, cât şi la operatorii
predefiniţi ai limbajului. Cea de-a doua este redefinrea dinamică (polimorfism/supradefinire,
over-riding), desfăşurându-se în faza de rulare a aplicaţiilor.
8.1.4.1 Supraîncărcarea metodelor
În multe dintre limbajele de programare actuale se pot defini funcţii diferite, dar care au
acelaşi nume. Aceste funcţii au totuşi semnături diferite (număr, tip şi ordine a parametrilor),
astfel încât să poată fi desemnată funcţia ce trebuie efectiv apelată. Această alegere este făcută
în momentul compilării şi rămâne neschimbată pe parcursul rulării programului.
Din moment ce se pot supraîncărca funcţii, în general, este evident faptul că şi metodele
unei clase pot fi supraîncărcate. Avantajul adus de supraîncărcare este flexibilitatea, deoarece
cu ajutorul ei o clasă poate oferi implementări diferite pentru acelaşi aspect comportamental.
8.1.4.2 Supraîncărcarea operatorilor
Printr-o expresie se înţelege o secvenţă de operanzi şi operatori. Prin evaluarea unei astfel
de expresii se obţine un rezultat. În abordarea obiectuală, expresiile pot avea ca operanzi
obiecte instanţiate dintr-o anumită clasă. În aceste situaţii operatorii de bază ai limbajului pot fi
redefiniţi.
În cazul în care, într-o expresie, apare un operator aplicat unui obiect a cărui clasă a
redefinit acel operator, se apelează o funcţie care conţine noua semnificaţie a operatorului.
Supraîncărcarea operatorilor nu este posibilă pentru tipurile fundamentale de date.
Supraîncărcarea operatorilor nu aparţine doar tehnologiei orientate-obiect. Şi în
programarea structurată există operatori diferiţi, dar care se notează la fel.
Avantajul oferit de supraîncărcarea operatorilor constă în mărirea posibilităţilor de
exprimare oferite de limbaj.
8.1.4.3 Polimorfismul
Polimorfismul reprezintă abilitatea unor obiecte similare de a răspunde la acelaşi mesaj în
moduri diferite. El apare când o subclasă are o metodă cu acelaşi nume şi aceeaşi semnătură ca
şi o metodă din superclasă. Se spune că metoda din clasa derivată suprascrie metoda
superclasă. Polimorfismul este o facilitate a metodelor din clase diferite, dar aflate în relaţie de
derivare între ele, nefiind legat intrinsec de clase şi obiecte. Cu polimorfismul, fiecare element
al colecţiei primeşte acelaşi mesaj, dar fiecare este programat să reacţioneze în mod diferit.
Polimorfismul descrie posibilitatea unor obiecte de a se comporta diferit în funcţie de
condiţiile din momentul rulării, aşa încât decizia privind comportamentul nu se ia la compilare
ca în cazul supraîncărcării (cuvântul polimorfism a fost creat prin unirea a două cuvinte din
limba greacă: poli, ce înseamnă multe, şi morphos, ce înseamnă formă).
Metodele care nu ar trebui să mai poată fi supradefinite în subclasele clasei în care sunt
definite poartă numele de metode finale. O metodă trebuie declarată ca fiind finală atunci când
are o implementare care nu trebuie schimbată sub nici o formă în subclasele ei, fiind critică
pentru consistenţa stării unui obiect.
Avantajul legării dinamice, faţă de legarea statică, constă în faptul că oferă un grad mare
de flexibilitate. Astfel, ierarhiile de clase sunt mai uşor de realizat şi de întreţinut.
Dezavantajul legării dinamice constă în diminuarea performanţei de viteză. Legarea
dinamică presupune un efort suplimentar de alegere dintr-un tabel de funcţii, pe când o funcţie
legată static se apelează direct.
De obicei, se foloseşte legarea statică şi numai unde este esenţial se recurge la legarea
dinamică, dacă respectivul limbaj permite ambele tipuri.
Nici noţiunea de polimorfism nu aparţine întru-totul tehnologiei orientate-obiect. În
programarea structurată există operatori care lucrează în exact acelaşi mod pe mai multe tipuri
de date.
8.1.5 Alte concepte ale orientării obiectuale

În funcţie de durata de viaţă a obiectelor, ele pot fi: volatile sau persistente. Cu alte
cuvinte, dacă un obiect se poate salva pentru rulări ulterioare ale aplicaţiilor el este obiect
persistent. Un obiect volatil este un obiect care poate supravieţui cel mult pe perioadă rulării
programului care l-a creat. Sistemele de gestiune a bazelor de date orientate-obiect permit
combinarea tehnicilor de programare orientată-obiect cu caracteristicile bazelor de date, astfel
încât obiectele definite de utilizator pot fi stocate şi recuperate pentru prelucrare. Acolo unde
se întâlnesc volume mari de date, cum ar fi domeniul financiar-contabil, accesarea obiectelor
dintr-o bază de date orientată-obiect poate deveni o problemă spinoasă, datorită lipsei unor
metode rapide, neprocedurale şi descriptive de căutare şi regăsire a datelor (cum este de
exemplu, limbajul SQL, întâlnit în marea majoritate a sistemelor de gestiune a bazelor de date
relaţionale).
Pentru a putea exprima modele în cele mai diferite domenii şi pentru a detalia informaţia
prezentată în mod grafic, se pot folosi mecanisme de extensie, cum ar fi: stereotipuri, restricţii
şi valori ataşate.
Stereotipurile pot fi folosite atât în cazul elementelor, cât şi al relaţiilor şi trebuie văzute
ca subtipuri de elemente. Un stereotip reprezintă o clasă în cadrul metamodelului de modelare.
Astfel, un element sau o relaţie poate face parte dintr-un stereotip (dar nu în mod obligatoriu).
Unele stereotipuri sunt predefinite, dar proiectantul îşi poate defini propriile stereotipuri.
Restricţiile extind semantica elementelor prin adăugarea de reguli. De exemplu, putem
impune unei metode destinate prelucrării unei tranzacţii de vânzare să determine apariţia unui
mesaj de eroare sau de atenţionare atunci când soldul clientului depăşeşte limita de creditare,
ca urmare a tranzacţiei respective.
Valorile ataşate (tagged values) oferă elemente de descriere suplimentară unui element,
prin prezentarea unor proprietăţi, cum ar fi: autorul elementului, autorul ultimelor modificări,
versiunea curentă, data ultimei modificări sau motivul ultimei modificări.
În cazul sistemelor informaţionale de mărime medie sau mare, UML pune la dispoziţie un
mecanism general de organizare a elementelor în grupuri, şi anume pachetul.
Pachet
Fig. 8.20 Simbolul UML pentru pachete
Pachetele sunt doar elemente conceptuale (există doar în timpul dezvoltării),

neconcretizându-se obligatoriu în fişiere.
Dacă elementele de modelare specifice UML nu fac referire şi la informaţii mai greu de
structurat, ce se concretizează doar în note explicative sau comentarii, în cadrul reprezentărilor
grafice pot fi adăugate elemente pentru adnotări, redate prin simbolul utilizat în figura 8.21.
Nota explicativa:
Fig. 8.21 Simbolul UML pentru note explicative
*
* *
Pentru o înţelegere mai uşoară a termenilor, propunem în tabelul 8.2 o paralelă între
termenii folosiţi în abordarea structurată şi termenii folosiţi în cea orientată-obiect.
Tabel nr. 8.2 – Paralelă între termenii abordării structurate

şi cei ai abordării orientate-obiect
Abordarea structurată Abordarea orientată-obiect
Tip de dată Clasă
Modul Obiect
Procedură Metodă
Apelarea procedurilor Mesaj
Variabilă Atribut
Declarare la execuţie Instanţiere
Ascunderea informaţiei Încapsulare
În continuare, pe baza conceptelor definite, vom încerca să surprindem câteva din
particularităţile specifice etapelor de dezvoltare a sistemelor informaţionale, din perspectiva
abordării orientate-obiect.
8.2 Modelarea orientată-obiect

în timpul etapei de analiză
După prezentarea exterioară a funcţionalităţilor sistemului, echipa de dezvoltare are

nevoie şi de o descriere internă a acestuia, prin diagrame grupate în modelul domeniului.
Echipa încă se gândeşte la obiectele şi relaţiile din lumea reală, în detrimentul conceptelor
specifice programării. Modelul domeniului se realizează în etapa de analiză a sistemului şi este
de preferat ca la realizarea lui să participe şi economişti cu experienţă în domeniul afacerii
respective. El presupune crearea unor diagrame de clase (la nivel conceptual) şi eventual
definirea pachetelor de astfel de diagrame. Încă nu este luată decizia folosirii unui anumit
model de organizare a datelor cu care să se satisfacă nevoile de persistenţă, aşa încât acest
model conceptual nu respectă restricţiile nici unui model de organizare a datelor. Clasele
identificate şi, eventual, cazurile de utilizare pot fi asociate anumitor diagrame ale stărilor de
tranziţie şi/sau diagrame de activitate pentru a se înţelege ciclul de viaţă a obiectelor.
8.2.1 Diagrame ale claselor

Diagramele claselor prezintă clasele existente într-un sistem informatic şi relaţiile dintre
acestea. Într-o abordare top-down, se pot identifica toate elementele lumii reale specifice
domeniului afacerii studiat, urmând ca ulterior să fie adăugate relaţiile dintre ele şi detaliile din
structura lor.
Într-un sistem informaţional ce realizează gestiunea comenzilor primite de la clienţi pot fi

identificate anumite reguli ale afacerii, precum cele din tabelul 8.3.
Tabel nr. 8.3 –Reguli ale afacerii într-un sistem de gestiune a comenzilor clienţilor
Clase
Reguli ale afacerii Relaţii identificate
identificate
Clienţi pot fi anumite persoane (fizice sau juridice) Persoane Generalizare
Clienţi
Clienţii pot realiza tranzacţii, dar persistenţa Clienţi Agregare fixă partajată
clientului nu este strâns legată de o anumită Tranzacţie
tranzacţie
Un tip de tranzacţie este comanda Tranzacţie Generalizare
Comandă
O comandă conţine unul sau mai multe produse, iar Comandă Agregare variabilă
datele despre produsele conţinute într-o anumită Produs compozită
comandă nu pot avea o existenţă mai scurtă sau mai
lungă decât a comenzii din care fac parte
Despre fiecare produs conţinut într-o comandă Linie_Comanda Clasă de agregare
trebuie memorate anumite date şi chiar pot exista
prelucrări specifice
După cum se observă din tabelul 8.3, fiecare regulă ne ajută să identificăm clasele folosite
în cadrul sistemului şi relaţiile dintre acestea. Regulile pot fi modelate obiectual şi reprezentate
grafic, ca în diagrama claselor din figura 8.22.
Realizarea diagramei claselor în etapa de analiză orientată-obiect este un efort asemănător
realizării diagramei entitate-relaţie specifică abordării structurate.
Asemănarea dintre diagrama claselor şi diagrama entitate–relaţie provine din existenţa
unui model conceptual comun, bazat pe analiza directă a elementelor din lumea reală. Practic,
diagramei entitate–relaţie îi pot fi adăugate elementele de comportament specific obiectelor şi
relaţiile de generalizare pentru începerea procesului de construire a diagramei claselor.
Adăugarea modelului conceptual al unor elemente de comportament presupune
identificarea pentru fiecare clasă a unui set de operaţii, prin stabilirea principalelor acţiuni ce
pot fi atribuite claselor.
«metaclass» «metaclass»
Persoana Tranzactie
+CUI : Char +Tip_Document : Char
+Nume : Char +Numar_Document : Char
+Tip : Char +Data_Document : Date
+Adresa : Char +Operator : Char Linie_Comanda
+IBAN : Char +Observatii : Char +Cantitate : Double
+Telefon : Char +Aprobata : Boolean +Pret : Double
+Client : Client +Cantitate_Onorata : Double
-realizeaza * Produs
Tranzactie:: Comanda
Persoana:: Client * * +Cod : Char
+Stare : Char
+Limita_Credit : Double +Denumire : Char
1 +Valoare : Double
+Incert : Boolean +UM : Char
+Produs : Produs -contine +Cont : Char
Fig. 8.22 Diagrama claselor pentru gestiunea comenzilor clienţilor

În demersul următor încercăm să prezentăm raţionamentul folosit la adăugarea de operaţii
entităţilor de date din modelul conceptual.
Teoretic, fiecărui atribut al unei clase îi pot corespunde cel puţin două metode, una de
actualizare şi una de citire. Pentru simplitate, multe modele orientate-obiect permit citirea şi
modificarea variabilelor direct, fără a mai fi nevoie să se definească metode specifice. În aceste
cazuri, nevoia adăugării unor metode pentru citirea şi actualizarea propriilor atribuite se face
simţită numai în cazul atributelor calculate.
Atributele derivate (calculate, nenormalizate) ale unei entităţi din diagrama entitate-
relaţie, specifică modelului structurat, pot fi exprimate, în abordarea orientată-obiect, ca
mesaje read-only (numai citire). De exemplu, atributul Valoare_cu_TVA al entităţii
Doc_insotire poate fi exprimat ca mesajul Valoare_cu_TVA al obiectului Doc_insotire, iar
metoda care îl implementează poate obţine valoarea prin citirea atributelor Cantitate, Preţ şi
Procent_TVA din toate obiectele instanţiate din clasa Produs incluse în obiectul Doc_insotire.
În continuare, ne propunem să luăm un exemplu dintr-un model conceptual pe care să-l
transformăm atât cu elementele specifice modelului relaţional, cât şi cu cele specifice abordării
orientate-obiect.
Stoc curent
Firma
CodFirma Gestiune Material
DenFirma CodGestiune CodMaterial
CUI (1,1) (1,M) DenGestiune (0,M) Este în (0,M)
DenMaterial
Adresa stoc UM
IBAN PretUnitar
Fig. 8.23 Relaţia dintre Firma, Gestiune şi Material în modelul conceptual

În cadrul modelului conceptual al unui sistem ce gestionează materiale, putem spune că
relaţia dintre entitatea Gestiune şi entitatea Material este o relaţie multe-la-multe, deoarece un
material este în stoc la zero sau mai multe gestiuni, iar o gestiune are pe stoc zero sau mai
multe materiale.
În modelul relaţional, relaţia multe-la-multe se descompune în două relaţii unu-la-multe,
prin crearea unei entităţi-intersecţie. Astfel, apare entitatea Stoc, o entitate asociativă între
entitatea Material şi entitatea Gestiune.
Firma Material
Gestiune are Stoc [As]
CodFirma are CodMaterial
CodGestiune CodMaterial [FK]
DenFirma CodGestiune [FK] este DenMaterial
CUI CodFirma [FK] UM
Adresa DenGestiune StocCurent PretUnitar
IBAN
Fig. 8.24 Relaţia dintre Firma, Gestiune şi Material în modelul relaţional

În abordarea obiectuală, atributul StocCurent al entităţii Stoc poate fi înlocuit de:
• o metodă (Citeste_StocCurent) ce aparţine clasei Gestiune şi care are ca parametru
codul materialului pentru care se citeşte stocul curent;
• o metodă (Actualizeaza_StocCurent) ce aparţine aceleiaşi clase, Gestiune, şi care are
ca parametru codul materialului pentru care se actualizează stocul curent şi cantitatea
cu care se face această modificare.
Gestiune Stoc
+ CodFirma + CodMaterial
+ CodGestiune are
+ CodGestiune
+ DenGestiune + StocCurent
1
+ Actualizeaza_StocCurent
+ Citeste_StocCurent
*
1..* este
are
Firma Material
+ CodFirma + CodMaterial
+ DenFirma + DenMaterial
+ CUI + UM
+ Adresa + PretUnitar
+ IBAN
+ Actualizeaza_StocCurent
+ Actualizeaza_StocCurent + Citeste_StocCurent
+ Citeste_StocCurent
Fig. 8.25 Relaţia dintre Firma, Gestiune şi Material în modelul obiectual

În astfel de cazuri, nu este obligatoriu să existe o singură metodă de scriere şi o singură

metodă de citire. Exemplul poate continua cu apariţia şi a altor metode pentru acelaşi atribut
calculat:
• o metodă (Citeste_StocCurent) ce aparţine clasei Material şi care are ca parametru
codul gestiunii pentru care se citeşte stocul curent.
• o metodă (Actualizeaza_StocCurent) ce aparţine clasei Material şi care are ca
parametru codul gestiunii pentru care se actualizează stocul curent şi cantitatea cu care
se face această modificare.
• o metodă (Citeste_StocCurent) ce aparţine clasei Firmă şi are ca parametri codul
materialului şi codul gestiunii pentru care se citeşte stocul curent.
• o metodă (Actualizeaza_StocCurent) ce aparţine clasei Firmă şi care are ca parametri
codul materialului şi codul gestiunii pentru care se actualizează stocul curent şi
cantitatea cu care se face această modificare.
În modelul obiectual, atributul StocCurent poate să dispară (inclusiv operaţiile
Actualizeaza_StocCurent), urmând ca, la fiecare apelare a metodei Citeste_StocCurent, să se
recalculeze stocul curent, pe baza stocului iniţial, a intrărilor şi a ieşirilor. Modelul obiectual
oferă, în acest caz, un loc unic de calculare a acestei valori, fără a exista nevoia calculării
aceluiaşi lucru în diversele aplicaţii ce folosesc aceeaşi bază de date. Calculul stocului curent
de fiecare dată când este necesar poate avea şi dezavantajul standardelor impuse de
optimizarea aplicaţiei.
Într-o altă ordine de idei, pot exista şi metode care nu modifică valorile atributelor din
aceleaşi clase, ci, de exemplu, introduc sau şterg obiecte dintr-o colecţie de obiecte. Un
exemplu de colecţie de obiecte o reprezintă rândurile de pe o notă de recepţie şi constatare
diferenţe. Această colecţie este într-o relaţie de compoziţie faţă de întregul document,
manipularea acesteia la momentul operării fiind, evident, necesară.
De multe ori, doar diagrama claselor nu ajunge pentru a explica toate detaliile privind
clasele sistemului. De exemplu, în diagrama din fig. 8.28, atributul Tip al metaclasei Persoană
poate fi interpretat în mai multe feluri. El face referire la persoanele fizice şi persoanele
juridice, dar cel care citeşte această diagramă poate atribui alte sensuri acestui atribut fără
existenţa unor informaţii suplimentare. Există mai multe soluţii în astfel de cazuri. O soluţie ar
fi crearea unei clase dedicate tipurilor de persoane şi folosirea acesteia ca tip al atributului Tip
din clasa Persoană. Soluţia reuşeşte să impună restricţiile necesare în acest model de date, dar
în cadrul sistemelor mari, cu sute de clase, apare problema complexităţii, mai ales în cazul în
care denumirea fiecărui tip trebuie să fie memorată în mai multe limbi. O altă soluţie ar fi
gestiunea unitară a tuturor acestor stereotipuri într-o singură clasă. Această clasă ar prelua şi
sarcina traducerii denumirii în diferite limbi.
8.3 Modelarea în etapa de proiectare orientată-obiect
După înţelegerea cerinţelor (în modelul cazurilor de utilizare) şi a conceptelor (în modelul
domeniului), se poate trece la etapa de proiectare a sistemului, respectiv realizarea modelului
proiectării, prin introducerea de concepte specifice programării. Acest model descrie atât
structura internă a sistemului (clase, obiecte şi relaţii), cât şi colaborările care intervin când
obiectele transmit mesaje pentru a realiza funcţionalitatea dorită. Structura statică este descrisă
în diagrame de clase, iar dinamica sistemului este descrisă prin diagramele de comunicare sau
de secvenţă.
Descrierea dinamicii sistemului poate să înceapă tot printr-o descriere narativă a
secvenţelor de activităţi identificate, ce vor ajuta nu doar la realizarea diagramelor de
interacţiune (diagramele de secvenţă şi diagramele de comunicare), dar vor fi folosite şi la
rafinarea diagramei claselor.
8.3.1 Diagrame de secvenţă

Diagramele de secvenţă sunt diagrame de interacţiune ce evidenţiază ordinea realizării
prelucrărilor (transmiterii mesajelor). Ele se pregătesc în etapa de analiză a sistemului, iar
realizarea lor duce, de multe ori, la modificări ale structurii claselor identificate până în această
fază.
Elementele de bază ale unei diagrame de secvenţă sunt:
• obiectele ce intervin în prelucrări, prin transmiterea şi primirea de mesaje. Ele se
reprezintă prin dreptunghiuri, plasate orizontal, în partea de sus a diagramei, în care
sunt scrise numele acestora.
• liniile de viaţă a obiectelor evidenţiază duratele de existenţă a obiectelor. Ele se
reprezintă cu un dreptunghi ataşat unor linii verticale punctate ce vin de la fiecare
obiect.
• mesajele sunt elementele de comunicare dintre obiecte, cum ar fi apelurile de operaţii
şi se reprezintă cu săgeţi ce unesc liniile de viaţă ale obiectelor.
Mesajele pot fi însoţite de condiţii, pentru transmiterea sau nu a unui mesaj şi de
parametri. Mesajele transmise între obiecte (tabel 8.4) pot fi clasificate şi descrise astfel:
• mesaje sincrone: mesaje după care se aşteaptă terminarea completă a prelucrării
indicate de mesaj, prin furnizarea sau nu a unui răspuns;
• mesaje asincrone: mesaje care indică faptul că se poate iniţia o nouă prelucrare, chiar
dacă nu s-a finalizat cea curentă.
• mesaje simple: mesaje pentru care nu se specifică proprietatea de sincronizare.
În timpul realizării diagramelor de secvenţă, dezvoltatorii, cunoscând domeniul afacerii,
identifică mesajele ce au loc între diferite clase, fiind momentul în care există posibilitatea de
stabilire completă a operaţiilor specifice claselor.
Tabel nr. 8.4 – Simbolurile folosite în UML

pentru reprezentarea mesajelor
Element Simbol
Mesaj sincron
Mesaj asincron
Mesaj simplu
În urma culegerii cerinţelor, cu ajutorul cazurilor de utilizare, se pot crea scenarii

folositoare nu doar pentru a acumula date despre dinamica sistemului (mesajele dintre obiecte
şi ordinea acestora, stările obiectelor etc.), ci şi pentru a verifica şi completa clasele şi relaţiile
dintre acestea. De exemplu, următoarea secvenţă de activităţi poate fi prezentată în mod grafic
ca în figura 8.26:
1. Clientul introduce comanda în sistem;
2. Managerul consultă un raport cu ultimele comenzi neprelucrate şi datele despre
clienţii respectivi;
3. Managerul aprobă / respinge o parte din comenzi;
4. Distribuţia consultă stocurile curente specifice elementelor comandate;
5. Distribuţia expediază elementele comandate existente pe stoc;
6. Distribuţia creează facturile corespunzătoare elementelor vândute;
7. Contabilitatea înregistrează facturile trimise clienţilor;
8. Clientul achită o parte din debite;
9. Contabilitatea înregistrează documentele de încasare de la clienţi.
Diagrama de secvenţă anterioară ne sugerează (prin mesajele Expediţie, Facturare,

Documente de plata) existenţa şi a altor subclase ale clasei Tranzacţie, pe lângă subclasa
Comandă, cum ar fi: Expediţie, Facturare, Încasare.
Client Comanda Manager Distributie Financiar Contabilitate
1: Creare:=Creare()2: Informeaza(Raport:Char)
3 Aprobare: Set_Stare:=Set_Stare(Stare:Char)
{OR}
3 Respingere: Set_Stare:=Set_Stare(Stare:Char)
4: Informeaza(Raport:Char)
5: Expeditie()
6: Facturare() 7 NC facturi emise: Informeaza
8: Documente de plata
9 NC documente de plata: Informeaza(Raport:Char)
Fig. 8.26 Diagrama de secvenţă pentru gestiunea clienţilor
Rezumat
Prezentul capitol încearcă să facă o incursiune în abordarea orientată-obiect şi în influenţele ei
asupra procesului de analiză şi proiectare a aplicaţiilor economice, în speranţa acumulării noţiunilor de
bază.
Capitolul începe cu prezentarea principalelor concepte ale abordării orientate-obiect, concepte
valabile în orice metodă de analiză şi proiectare orientată-obiect, folosind, pentru reprezentarea grafică a
acestora, standardul UML.
Clasa de obiecte reprezintă un tip abstract de date care defineşte structura obiectelor din acea clasă.
Pentru a asigura funcţionalitatea aplicaţiilor, între elementele specifice orientării obiect se stabilesc o
serie de relaţii, şi anume: asocieri, dependenţe, derivări.
Plecând de la aspectele fundamentale ale abordării orientate-obiect, se poate trece la modelarea
specifică fiecărei etape de dezvoltare a unui sistem informaţional.
1. Care sunt elementele ce definesc un obiect? Dar pentru o clasă?
2. Ce relaţii pot exista între clase şi prin ce se particularizează ele?
3. Realizaţi o comparaţie între modul de redare a unei relaţii în modelul relaţional şi cel obiectual.
Probleme
1. Prezentaţi diagrama claselor pentru un sistem informaţional al unei firme despre care deţineţi
informaţii.
2. Prezentaţi exemple din fiecare tip de relaţie posibilă în abordarea orientată-obiect, folosindu-vă de
componentele cunoscute ale sistemului informaţional abordat în problema anterioară.
3. Transformaţi diagrama entitate-relaţie a unui sistem informaţional într-o diagramă a claselor şi
motivaţi fiecare modificare.
4. Prezentaţi diagrama de secvenţă specifică unui sistem informaţional şi argumentaţi rolul acesteia în
rafinarea diagramei claselor.
Bibliografie generală
1. Airinei, D., ş.a. – Medii de programare, Ediţia a IV-a, Editura Sedcom Libris, Iaşi, 2004
2. Alter, S. – Op. cit., pp. 147-148; Mintzberg, H. – „The Manager’s Job: Folklore and Fact”, in
Harvard Business Review 53, nr. 4, July-August 1975.
3. Bachenski, B. – „GUI Builders Pay Price for User Productivity”, in Software Magazine, April 1992;
4. Beizer, B. – Personal Computer Quality: A Guide for Victims and Vendors, Van Nostrand Reinhold
Company, New York, 1986.
5. Benbasat. I., Dexter, A.S., Todd, P. – „The Influence of Color and Graphical Information
Presentation in a Managerial Decision Simulation”, in Human-Computer Interaction 2, 1986.
6. Bidgoli, H. (editor) – Encyclopedia of Information Systems, vol. 4, Academic Press, Amsterdam,
2003.
7. Blattner, M., Schultz, E. – „User Interface Tutorial”, Proceedings of the International Conference
on System Sciences, Kona, Hawaii, January 1988.
8. Bloor, R. – „The Disappearing Programmer”, in DBMS 7(9) (august), 1994.
9. Booch, G. – Object-Oriented Analysis and Design with Applications, Addison Wesley, New York,
1994.
10. Booth, P. – An Introduction to Human-Computer Interaction, Lawrence Erlbaum Associates,
Londra, 1989.
11. Budd, T. – An Introduction to Object-Oriented Programming, Second Edition, Addison Wesley,
Reading, Massachusetts, 1998.
12. Carliner, S. – Industry Report: Overview of the Technical Communication Industry, 2002,
www.stc.org (accesat 2.01.2006).
13. Caroll, J.M. – Designing Interaction, Cambridge University Press, Cambridge, 1991.
14. Connoly, T.M., Begg, C.E. – Database Systems. A Practical Approach to Design, Implementation,
and Management, Third Edition, Addison Wesley, Harlow, 2002.
15. Coulouris, G., Dollimore, J., Kindberg, T. – Distributed Systems. Concepts and Design, Pearson
Education Limited, Addison Wesley, Reading, Massachusetts, 2001.
16. Craig, J.S., Beck, B.E. – „A New Look at Documentation and Training: Technical Communicator
as Problem Solver”, in Information Systems Management, 10 (Summer), 1993.
17. Crowley, A. – „The Help Desk Gains Respect”, in PC Week, no. 10, November 15, 1993.
18. Cushing, B.E., Romney, M.B. – Accounting Information Systems, Addison Wesley Publishing
Company, New York, 1994.
19. Date, C.J. – An Introduction to Database Systems, Seventh Edition, Addison Wesley, Reading,
Massachusetts, 2000.
20. Date, C.J. – Baze de date, Editura Plus, Bucureşti, 2005, traducere a lucrării Date, C.J. – An
Introduction to Database Systems, Eighth Edition, Pearson Education, Inc., Boston, 2004.
21. Davenport, T.H. – Process Innovation: Reengineering Work through Information Technology,
Harvard Business School Press, Boston, 1993.
22. Dollinger, R. – Baze de date şi gestiunea tranzacţiilor, Editura Albastră, Cluj-Napoca, 1999.
23. Dumas, J.S. – Designing User Interface for Software, Prentice Hall, Englewood Cliffs, 1988.
24. Elmasri, R., Navathe, S.B. – Fundamentals of Database Systems, Third Edition, Addison Wesley,
Reading, Massachusetts, 2000.
25. Fînaru, L., Brava, I.M. – Visual Basic. Primii paşi… şi următorii, Editura Polirom, Iaşi, 2001.
26. Flynn, D. – Information System Requirements: Determination & Analysis, McGraw-Hill, London,
1998.
27. Forward, A. – Software Documentation – Building and Maintaining Artefacts of Communication,
University of Ottawa, Ontario, Canada, 2002.
28. Fotache, M. – Proiectarea bazelor de date. Normalizare şi postnormalizare. Implementări SQL şi
Oracle, Editura Polirom, Iaşi, 2005.
29. Gliedman, C. – Thirty-one Best Practices for the Service Desk, June 28, 2005,
http://i.i.com/cnwk.ld/itp (accesat 25.10.2005).
30. Greenbaum, J. – „The Evolution Revolution”, in Information Week, March 14, 1994.
31. Haarind, R. – „Software’s New Object Lesson”, in Technology Review, February-March, 1992.
INDEX 171
32. Hall, G., Rosenthal, J., Wade, J. – „How to make reengineering really work”, in Harvard Business
Review, November-December 1993.
33. Halpin, T. – Information Modeling and Relational Databases, Kaufmann Publishers, Inc, San
Francisco, 2001.
34. Hammer, M. – „Re-engineering work: don’t automative, obliterate”, in Harvard Business Review,
July-August 1990.
35. Hayley, K., Plewa, J., Watts, M. – „Reengineering Tops CIO Menu”, in Datamation, vol. 38., nr.
6, April 15, 1993.
36. Hicks Jr., J.O. – Management Information Systems: A User Perspective, Second Edition, West
Publishing Company, St. Paul, 1987.
37. Hoffer, J.A., Prescott, M.B., McFadden, F.R. – Modern Database Management, Sixth Edition,
Pearson Education, Inc., Prentice Hall, Upper Saddle River, New Jersey, 2002.
38. Hoffer, J.A., George, J.F., Valacich, J.S. – Modern Systems Analysis and Design,
Benjamin/Cummings Publishing Company, Inc., Sand Hill Road, Menlo Park, 1996.
39. Hughes, B. – Practical software measurement, McGraw-Hill, London, 2000.
40. Jalics, P.J. – „COBOL on a PC: A New Perspective on a Language and Its Performance”, in
Communications of ACM 30, nr. 2, February 1987.
41. Jones, T.C. – Programming productivity: Issues for the 80s, IEEE Computer Society Press, 1981.
42. Kendall, K.E., Kendall, J.E. – Systems Analysis and Design, Fifth Edition, Prentice Hall, Upper
Saddle River, New Jersey, 2002.
43. Koval, J. A. – Analyzing Systems, Prentice Hall, Upper Saddle River, New Jersey, 1988.
44. Langer, A.M. – Analysis and Design of Information Systems, Second Edition, Springer – Verlag,
New York, 2001.
45. Madison, J. – Five “T’s” of Database Availability, www.standishgroup.com (accesat 20.10.2004).
46. Mandel, T. – The Elements of User Interface Design, John Wiley & Sons, New York, 1997.
47. Mandelkern, D. – „Graphical User Interfaces: The Next Generation”, in Communication of ACM
36, nr. 4, April 1993.
48. Marakas, G. – Systems Analysis and Design. An Active Approach, Prentice Hall, New Jersey, 2001.
49. Marchesi, M. – Object-Oriented Programming with Smalltalk/V, Prentice Hall International Ltd,
London, 1994.
50. Martin, J. – Information Engineering: Book II – Planning & Analysis, Prentice Hall, Englewood
Cliffs, New Jersey, 1990.
51. Martinsons, M.G., Revenaugh, D.L. – „Re-engineering is Dead; Long Live Re-engineering”, in
International Journal of Information Management, vol. 17, nr. 2, 1997.
52. May, J.C. – Extended the Macintosh Toolbox: Programming Menus, Windows, Dialogues and
More, Addison Wesley, Reading, Massachussetts, 1991.
53. McFadden, F.R., Hoffer, J.A. – Data Base Management, Second Edition, The
Benjamin/Cummings Publishing Company, Inc., Menlo Park, 1988.
54. McFadden, F.R., Hoffer, J.A. – Modern Database Management, Benjamin/Cummings Publishing
Company, Inc., Redwood City, 1994.
55. McLeod, Jr., R., Jordan, E. – Systems Development. A Project Management Approach, John
Wiley & Sons, Inc., New York, 2002.
56. Meşniţă, G. – „Reproiectarea proceselor economice (BPR)”, în Analele Ştiinţifice ale Universităţii
„Al. I. Cuza” Iaşi – Seria Ştiinţe Economice, Tomul XLVI, Editura Universităţii „Al. I. Cuza”, Iaşi,
2000.
57. Morris, D., Brandon, J. – Re-engineering Your Business, McGraw-Hill, New York, 1993.
58. Morse, A., Reynolds, G. – „Overcoming Current Growth Limits in UI Development”, in
Communications of ACM 36, nr. 4, April 1993.
59. Mosley, D.J. – The Handbook of MIS Application Software Testing, Yourdon Press, Englewood
Cliffs, New Jersey, 1993.
60. Naumann, J.D., Jenkins, A.M. – „Prototyping: The New Paradigm for Systems Development”, in
MIS Quarterly, 6 (3), 1993.
61. Nelson, R.R., Cheney, P.H. – „Training End Users: An Exploratory Study”, in MIS Quarterly 11,
December 1987.
62. Norman, K.L. – The Psychology of Menu Selection, Ablex, Norwood, New Jersey, 1991.
63. Oprea, D., Airinei, D., Andone, I. – Bazele informaticii economice, Editura Universităţii „Al. I.
Cuza”, Iaşi, 1990.
64. Oprea, D., Andone, I., Airinei, D. – Limbaje de programare şi bănci de date, Editura Universităţii
„Al. I. Cuza”, Iaşi, 1990.
65. Oprea, D. – Analiza şi proiectarea sistemelor informaţionale economice, Editura Polirom, Iaşi
1999.
66. Oprea, D. – Premisele şi consecinţele informatizării contabilităţii, Editura Graphix, Iaşi, 1994.
67. Oprea, D. – Protecţia şi securitatea informaţiilor, Editura Polirom, Iaşi, 2002.
68. Oprea, D. – Protecţia şi securitatea sistemelor informaţionale, Editura Polirom, Iaşi, 2002.
69. Oprea, D. – Managementul proiectelor. Teorie şi cazuri practice, Editura Sedcom Libris, Iaşi, 2001.
70. Oprea, D., Meşniţă, G. – „Documentaţia sistemelor informaţionale – problemă a managementului
proiectelor?”, în vol. Societatea informaţională: Educaţie, Cercetare, Sisteme informaţionale,
Tehnologii Informaţionale, Editura ETP Tehnopress, Iaşi, 2004.
71. Ozsu, M.T., Valduriez, P. – Principles of Distributed Database Systems, Second Edition, Prentice
Hall International, Inc., Upper Saddle River, New Jersey, 1999.
72. Page, J., Hooper, P. – Accounting and Information Systems, Fourth Edition, Prentice Hall,
Englewood Cliffs, New Jersey, 1992.
73. Porter, A. – C++ Programming for Windows, McGraw-Hill, Berkeley, 1993.
74. Post, G.V. – Database Management Systems. Designing and Building Business Applications,
McGraw-Hill, Boston, 1999.
75. Powers, M.J., Cheney, P.H., Crow, G. – Structured Systems Development: Analysis, Design,
Implementation, Boyd & Fraser Publishing Company, Boston, 1990.
76. Pressman, R.S. – Software Engineering. A Practitioner’s Approach, Fifth Edition, McGraw-Hill
Publishing Company, London, 2000.
77. Richard, L.K. – Testing Requirements, www.gantthead.com (accesat 18.01.2006).
78. Riordan, R.M. – Designing Relational Database Systems, Microsoft Press, Redmond, Washington,
1999.
79. Rodgers, U. – „Denormalization: Why, What and How?”, in Database Programming & Design,
2(12), December 1989.
80. Roman, D. – Ingineria programării obiectuale, Editura Albastră, Cluj-Napoca, 1996.
81. Satzinger J.W., Jackson, R.B., Burd, S.D. – Systems Analysis and Design in a Changing World,
Course Technology, Thomson Learning, Boston, 2002.
82. Schach, S. – Object-Oriented and Classical Software Engineering, Fifth Edition, McGraw-Hill,
Boston, 2002.
83. Schiesser, R. – IT Systems Management. Designing, Implementing, and Managing World-Class
Infrastructures, Prentice Hall PTR, Upper Saddle River, New Jersey, 2002.
84. Schulteis, R., Sumner, M., Bock, D. – Management Information Systems: The Manager’s View,
Second Edition, IRWIN, Homewood, Boston, 1992.
85. Shelly, G.B., Cashman, T.J., Rosenblatt, H.J. – Systems Analysis and Design, Fourth Edition,
Course Technology, Thomson Learning, Boston, 2001.
86. Shneiderman, B. – Designing the User Interface, Addison Wesley, 1998, Third Edition,
http://www.cs.utexas.edu/users/almstrum/cs370/elvisino/rules.html
87. Shneiderman, B. – Designing the User Interface: Strategies for Effective Human-Computer
Interaction, Addison Wesley, Reading, Massachusetts, 1992.
88. Sia, C.-L., Ian, B.C.Y., Teo, H.-H., Wei, K.-K. – „Applying Total Quality Concepts to Continuous
Process Redesign”, in International Journal of Information Management, vol. 17, nr. 2, 1997.
89. Simon, J.C., Chaney, L.H. – Systems and Procedures for the Modern Office –A Simulation
Approach, Second Edition, Regents/Prentice Hall, Englewood Cliffs, New Jersey, 1993.
90. Simsion, G.C. – Data Modeling Essentials. Analysis, Design, and Innovation, Second Edition, The
Coriolis Group, Scottsdale, Arizona, 2001.
91. Tanenbaum, A.S., van Steen, M. – Distributed Systems. Principles and Paradigms, Prentice Hall,
Inc., Upper Saddle River, New Jersey, 2002.
92. Teorey, T.J. – Database Modeling & Design, Morgan Kaufmann Publishers, Inc, San Francisco,
1999.
93. van Vliet, H. – Software Engineering. Princples and Practice, Second Edition, John Wiley & Sons,
LTD, Chichester, 2002.
INDEX 173
94. Văduva, I. ş.a. – Ingineria programării, Editura Academiei, Bucureşti, 1985 (vol. I), 1986 (vol. II).
95. Voss, G. – Object-Oriented Programming. An Introduction, Osborne McGraw-Hill, Berkeley, 1991.
96. Wiederhold, G., Wegner, P., Ceri, S. – „Toward Megaprogramming”, in Communications of ACM
35, nr. 11, November 1992.
97. Wilkie, G.– Object-Oriented Software Engineering, Addison Wesley, Reading, Massachusetts,
1993.
98. Yourdon, E. – Decline & Fall of the American Programmer, Englewood Cliffs, New Jersey,
Yourdon Press, 1993.
99. Zwass, V. – Management Information Systems, WCB-Wm, C. Brown Publishers, Dubuque, 1992.
100. *** – Foundation of Business Systems, Second Edition, Andersen Consulting – Arthur A. Andersen
& Co. S.C., Dryden, 1989.
101. *** – Software Process Engineering Metamodel, version 1.1, OMG, 2005.
102. *** – Unified Modeling Language (UML) Specification: Infrastructure, version 2.0, OMG, 2004, p.
10.
103. *** – Project Management – Guidelines, www.projectmanagement.tas.gov.au (accesat 06.07.2004).
104. *** – Oracle® Database Performance Tuning Guide 10g Release 2 (10.2), www.oracle.com.
105. *** – Incident Description Report, www.gantthead.com (accesat 12.01.2006).

Suportcurs Sifc2 Psi Zi

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Suportcurs Sifc2 Psi Zi

Încărcat de

Drepturi de autor:

Formate disponibile

DUMITRU OPREA

FLORIN DUMITRIU GABRIELA MEŞNIŢĂ

PROIECTAREA SISTEMELOR INFORMAŢIONALE

Prof. univ. dr. Dinu AIRINEI

© Editura Universităţii „Alexandru Ioan Cuza” Iaşi, 2010

Florin Dumitriu Gabriela Meşniţă

EDITURA UNIVERSITĂŢII „ALEXANDRU IOAN CUZA”

Mai mult decât proiectarea sistemelor ................................................................. 9

CAPITOLUL I Proiectarea formularelor/formatelor şi a rapoartelor .......... 11

CAPITOLUL II Proiectarea interfeţelor utilizator ................................................. 40

2.4.3 Construirea interfeţei utilizator ..................................................... 68

CAPITOLUL III Proiectarea logică a bazelor de date: modelarea logică a datelor78

CAPITOLUL IV Proiectarea fizică a fişierelor şi a bazelor de date...................... 92

CAPITOLUL V Proiectarea programelor şi a procedurilor ................................... 99

CAPITOLUL VI Implementarea sistemului......................................................... 115

CAPITOLUL VII Exploatarea şi întreţinerea sistemelor informaţionale ............ 136

CAPITOLUL VIII Particularităţi conceptuale şi tehnice ale analizei şi proiectării orientate-

Mai mult decât proiectarea sistemelor

Lucrarea de faţă continuă demersul prezentării etapelor ciclului de viaţă al sistemelor

După parcurgerea etapei de proiectare logică, în multe metodologii cunoscută şi ca

Iaşi, 2010 Autorii,

1.1 Aspecte generale ale proiectării formularelor/formatelor şi a

Un formular/format poate fi un document primar care conţine unele date predefinite,

Introducerea, în general, trebuie să apară la începutul formularului şi să conţină titlul

1.2 Caracteristicile generale şi clasificarea ieşirilor

Proiectarea ieşirilor constituie poate cea mai importantă activitate în dezvoltarea

Tabel nr. 1.1 – Caracteristicile generale şi clasificarea

1.2.1 Scopul ieşirilor

căruia se întocmeşte „Ordinul de plată” pentru achitarea obligaţiilor legale către

1.2.2 Destinatarii ieşirilor

Un alt aspect de proiectare, strâns legat de destinatarii ieşirilor, îl reprezintă numărul de

1.2.3 Frecvenţa ieşirilor

Fig. 1.1 Caracterizarea tipurilor de rapoarte necesare procesului managerial

Rapoartele declanşate de excepţii conţin informaţii filtrate în legătură cu anumite

1.2.4 Formatul ieşirilor

Fig. 1.2 Exemplu de raport ce utilizează tehnica „drill up-drill down”

urmărit. De exemplu, ordonarea alfabetică a „Situaţiei costurilor” după denumirea elementelor

Fig. 1.3 Exemplu de utilizare a tehnicii legării rapoartelor

1.2.6 Sursa datelor

Tabel nr. 1.2 – Surse comune ale informaţiilor

1.2.7 Mediul de generare şi transmitere a ieşirilor

1.2.8 Controlul confidenţialităţii, integrităţii

1.2.9 Caracteristicile informaţiilor şi nivelurile decizionale

1.3 Reguli de proiectare a formularelor/formatelor

Odată cu succesele înregistrate de tehnologiile informaţionale, pretenţiile utilizatorilor de

2. Oprea, D. – Protecţia şi securitatea informaţiilor, Editura Polirom, Iaşi, 2002.

Tabel nr. 1.3 – Caracteristicile informaţiilor pe niveluri decizionale

1.3.1 Recomandări generale de formatare

• Informaţiile din instrucţiuni

1.3.2 Scoaterea în evidenţă a informaţiilor

• diferenţieri prin fonturi;

Utilizarea exclusivă Lipsesc

Fig. 1.4 Exemplu incorect de scoatere în evidenţă a informaţiilor

Combinarea plăcută a Includerea unor Facilităţi pentru

1.3.3 Reguli specifice de proiectare a rapoartelor în formă tabelară

Formatarea datelor de tip numeric, alfabetic sau alfanumeric:

La proiectarea rapoartelor în format tabelar se vor lua în considerare zonele specifice,

Date identificare grup

Pagina 1 din 1 Sfârsit pagina

Fig. 1.6 Zonele întâlnite în rapoartele în format tabelar

1.3.4 Reguli specifice de proiectare a graficelor

• Marcarea celor mai importante elemente.

b) Grafic denaturat prin schimbarea bazei scalei

c) Grafic denaturat prin schimbarea vârfului scalei