Teorei Parțial SIFC2

If Builders Built Buildings The Way Programmers Write Programs,
Then The First Woodpecker That Came Along Would Destroy Civilization.
Weinberg's Second Law
Proiectarea
formularelor/formatelor şi a
rapoartelor
Capitolul I
The quality of a software product is largely governed by the

quality of the software process used to develop and maintain it.
1
The Process Management Principle
Obiectivul principal:
Proiectarea 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.
2
1. Definirea formatelor/formularelor şi rapoartelor
Un formular/format – document primar care conţine:

▪ date constante – predefinite
▪ date variabile – urmează a fi completate
Un raport
▪ document pasiv
▪ document economic – include date predefinite
▪ folosit exclusiv pentru a fi citit sau vizualizat
Formularele/formatele apar ca intrări ale sistemului.
Rapoartele apar ca ieşiri ale sistemului.
3
2. Caracteristicile generale şi clasificarea ieşirilor
Caracteristica Descriere Clasificarea ieşirilor

Scopul Descrierea motivului - monitorizarea proceselor sau a
realizării fiecărei ieşiri. activităţilor
- controlul activităţilor
- luarea deciziilor
- transferul informaţiilor în afara firmei
- întocmirea altor documente sau
rapoarte
Destinatarii Identificarea şi descrierea - interne
persoanelor care vor - externe
utiliza ieşirile. - hibride (documente în circuit)
Frecvenţa Specificarea momentelor - rapoarte programate
la care trebuie generate - rapoarte generate de excepţii
ieşirile. - rapoarte la cerere
- analize ad-hoc
4

Formatul Descrierea modalităţii de - text
organizare şi prezentare a - tabelară
informaţiilor. - grafică
- zone predefinite
Conţinutul Descrierea informaţiilor - rapoarte detaliate
care vor fi furnizate în - rapoarte de sinteză
fiecare ieşire. - rapoarte dinamice
Sursa datelor Identificarea căilor de - baze de date
obţinere a datelor necesare - ieşirile din alte procese de
pentru generarea ieşirilor. prelucrare
- surse externe
5

Mediul de Alegerea modalităţii de - tipărite
transmitere generare şi transmitere a - afişate pe ecran
ieşirilor. - 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.
6
Scopul
Rapoartele pot avea utilizări diverse:

• monitorizarea proceselor sau a activităţilor din cadrul firmei
Situaţia comenzilor cu termen de onorare depăşit;
• controlul activităţilor economice

Balanţa analitică a stocurilor;
• luarea deciziilor pe diferite niveluri ierarhice

Situaţia vânzărilor pe zone geografice
• transferul informaţiilor în afara organizaţiei

Ofertele de produse; fisa analitica a clientului; extrasul de cont
• întocmirea unor documente sau a altor rapoarte

Jurnalul vânzărilor şi Jurnalul cumpărărilor; centralizatorul statelor de plata
7
Scopul
Scopul ieşirilor influenţează alte aspecte de proiectare:

• coloanele (datele) incluse in raport
• ordinea de prezentare a coloanelor
• filtrarea informaţiilor
• totalurile ce trebuie incluse
• frecvenţa ieşirilor
8
Destinatarii
Destinatarii – ieşirile se clasifică:
• interne - rezultat proces de prelucrare, rămân în sistem;
• externe - documente primare şi rapoarte care depăşesc graniţele sistemului, ale
firmei;
• hibride = documente în circuit - părăsesc sistemul şi revin sub o formă
îmbunătăţită, ca intrări.
Destinatarii ieşirilor – aspecte proiectare:

• mecanismelor pentru controlul generării şi distribuirii lor,
• alegerea mediilor de transmitere,
• numărul exemplare.
9
Frecvenţa
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
10
Formatul
Formatul ieşirilor – organizarea şi prezentarea informaţiilor
• tabelar - organizarea informaţiilor în linii şi coloane;

• zone predefinite - pe hârtie sau pe ecran, similar paginilor Web sau ziarelor
obişnuite;
• grafic - datele numerice prezentate prin tipuri de grafice.
Elemente de proiectare:
• dimensiunea paginii - standarde A3, A4 şi A5;
• rezoluţia de afişare - standard
• 640x480 pixeli (1996);
• 800x600 pixeli (2000);
• 1024x768 pixeli.
11
Conţinutul
Conţinutul – grad de detaliere
• detaliate - nivel minim de agregare, unul sau multe niveluri de total
“Situaţia lunară a vânzărilor” poate include totalul general, totalul

vânzărilor pe clienţi şi totalul valoric pentru fiecare document.
• de sinteză - informaţii agregate şi filtrate (clauza GROUP BY).
“Situaţia vânzărilor pe clienţi” poate conţine câte o linie pentru

fiecare client, în care sunt însumate toate documentele de livrare
pentru un client.
• dinamice - combinarea rapoartelor de sinteză cu cele detaliate.

Două tehnici: „drill up/drill down” şi bazată pe legare 12
Conţinutul
Tehnica drill/down
13
Conţinutul
Tehnica legării rapoartelor
14
Mediul de generare şi transmitere
➢ Ieşiri tipărite;
➢ Ieşiri afişate pe ecran;
➢ Mesajele electronice – poşta electronică, format XML şi sistemele EDI;
➢ Sistemele cu ieşiri bazate pe microfilme, COM (Computer Output
Microfilm):
• microfilme – stochează imaginile pe role de film şi
• microfişe – transpun imaginile pe o singură peliculă (diapozitive).
➢ Sistemele audio şi video – Voice–mail.
15
3. Recomandări generale de formatare
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 perioadei la care se referă.
• 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.
16
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.
17
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.
18
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.
19
Deplasarea lejeră prin document (navigarea)

• De indicat cum se pot efectua deplasările înainte şi înapoi.
• De arătat 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. 20
Uniformitatea
21
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ă.
Despărțirea în silabe: În textele ecranelor, ale rapoartelor nu se

recomandă despărţirea cuvintelor în silabe de pe un rând pe altul.
Abrevierile: Nu se recomandă folosirea abrevierilor pentru cuvinte care

nu au o recunoaştere generală. 22
23
5. Proiectarea rapoartelor sub formă tabelară
Reguli generale de concepere a tabelelor
• Folosirea unei linii cu spaţii după fiecare cinci rânduri atunci când există
prea multe coloane.
• Între coloane trebuie să existe cel puţin două spaţii.
• De lăsat loc suficient pe rapoartele tipărite care să permită adnotările.
• De folosit acelaşi gen de caractere, cu excepţia cazurilor care
informațiile prezentate trebuie să fie scoase în evidenţă.
• De evitat excesele de fonturi fanteziste, greu de citit.
• Toate coloanele şi rândurile să aibă nume (etichete) cât mai relevante.
• Numele respective vor fi scoase în evidenţă.
• Formatarea corespunzătoare a datelor de tip numeric, alfabetic sau
alfanumeric
24
Zonele specifice rapoartelor în format tabelar
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
Conţine
Cod client: elementele
1235, Nume care
client: BETA apar o singură dată, la
sa
5 începutul13-ian-2006
458891 raportului (titlul raportului,
1211 data obţinerii,
4-ian-2006 14.500.000
6 numele destinatarului)
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 25
Antet
Data: 15/03/2006
1 458992 13-ian-2006 1212 5-ian-2006 72.000.000
2 459025 13-feb-2006 1875 6-feb-2006 57.000.000
4 459758 23-feb-2006 2543 13-feb-2006 43.000.000
Include elementele raportului care apar
Cod client: 1235, Nume client: BETA sa
5
la începutul
458891
fiecărei pagini
13-ian-2006
(numele
1211 4-ian-2006 14.500.000
6 coloanelor,
458999 numărul paginii)
18-ian-2006 1256 10-ian-2006 29.850.000
7 459112 20-feb-2006 1301 10-feb-2006 44.000.000
Sfârsit pagina 26
Pagina 1 din 1
Antet
Data: 15/03/2006
1 458992 13-ian-2006 1212 5-ian-2006 72.000.000
2 459025 13-feb-2006 1875 6-feb-2006 57.000.000
4 459758 23-feb-2006 2543 13-feb-2006 43.000.000
5 458891 Este zona
13-ian-2006 principală
1211 a oricărui raport şi
4-ian-2006 14.500.000
6 458999 18-ian-2006 1256 10-ian-2006 29.850.000
conţine câmpurile care vor forma o
7 459112 20-feb-2006 1301 10-feb-2006 44.000.000
Total client
linie cu informaţii 88.350.000
Sfârsit pagina 27
Pagina 1 din 1
Antet
Data: 15/03/2006
1 458992 13-ian-2006 1212 5-ian-2006 72.000.000
2 459025 13-feb-2006 1875 6-feb-2006 57.000.000
Sunt incluse elementele raportului care apar Linie detaliu
3 459220 22-feb-2006 1899 11-feb-2006 112.000.000
la sfârşitul fiecărei pagini (numărul paginii,
4 459758 23-feb-2006 2543 13-feb-2006 43.000.000
totalurile
Total client
la nivel de pagină) 284.000.000 Sfârsit grup
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
Sfârsit pagina 28
Pagina 1 din 1
Antet
Data: 15/03/2006
1 458992 13-ian-2006 1212 5-ian-2006 72.000.000
2 Conţine
459025 elementele
13-feb-2006 care
1875apar o6-feb-2006
singură dată, la 57.000.000
3 sfârşitul
459220 22-feb-2006 1899
raportului (totalurile 11-feb-2006 numele112.000.000 Linie detaliu
generale,
4
persoanelor
459758
responsabile
23-feb-2006 2543
de generarea
13-feb-2006
şi 43.000.000
certificarea raportului)
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
Sfârsit pagina 29
Pagina 1 din 1
Antet
Data: 15/03/2006
1 458992 13-ian-2006 1212 5-ian-2006 72.000.000
2 459025 13-feb-2006 1875 6-feb-2006 57.000.000
4 459758 23-feb-2006 2543 13-feb-2006 43.000.000
Sfârsit grup
Apare în rapoartele în care se doreşte gruparea datelor284.000.000
Total client
după unul sau mai multe câmpuri de control. Include
5 458891 13-ian-2006 1211 4-ian-2006 14.500.000
elementele care apar o singură dată, la începutul fiecărui
6 458999 18-ian-2006 1256 10-ian-2006 29.850.000
7
grup459112
(datele 20-feb-2006
de identificare ale grupului)
1301 10-feb-2006 44.000.000
Sfârsit pagina 30
Pagina 1 din 1
Antet
Data: 15/03/2006
1 458992 13-ian-2006 1212 5-ian-2006 72.000.000
2 459025 13-feb-2006 1875 6-feb-2006 57.000.000
4 459758 23-feb-2006 2543 13-feb-2006 43.000.000
5 458891 13-ian-2006 1211 4-ian-2006 14.500.000
6 458999 în rapoartele
Apare 18-ian-2006 în care se doreşte
1256 gruparea datelor.
10-ian-2006 29.850.000
7 459112 20-feb-2006 1301 10-feb-2006 44.000.000
Include elementele care apar o singură dată, la sfârşitul
fiecărui grup (totalurile sau rezultatele altor operaţiuni Sfârsit raport
Total general 372.350.000
de agregare la nivelul grupului)
Sfârsit pagina 31
Pagina 1 din 1
6. Proiectarea graficelor
Avantajele graficelor
• O imagine este mai sugestivă decât 1 000 de cuvinte

• Marcarea celor mai importante elemente
• Excepţiile sunt uşor de sesizat
• Evidenţiază eventualele corelaţii dintre elemente
• Se pot efectua comparaţii multiple rapide.
• Se oferă şansa efectuării de prognoze.
32
6. Proiectarea graficelor
Recomandări generale pentru construirea graficelor
• un număr şi un titlu;
• referirea la grafice se va face ca la figuri;
• se va plasa cuvântul Figura şi numărul corespunzător la marginea din
stânga paginii sau centrat (poate include și numărul capitolului);
• titlul graficului va începe imediat după număr, fără a fi subliniat şi
fără a se pune punct după el;
• se va indica sursa datelor prin plasarea cuvântului Sursă sub numărul
şi numele graficului, urmat de citarea sursei.
33
7. Controlul confidenţialităţii, integrităţii şi
accesibilităţii ieşirilor
Principalele proceduri de control

• Limitarea accesului la sistemul informaţional - definirea
utilizatorilor autorizaţi şi a drepturilor de acces în sistem ale fiecăruia
• Controlul distribuirii ieşirilor - permiterea accesului la rapoarte doar
utilizatorilor cărora le sunt destinate
• Separarea responsabilităţilor - crearea unor activităţi separate care
să fie realizate de angajaţi diferiţi
▪ Exemplu: înregistrarea în sistem a comenzilor de la clienţi să
fie separată de generarea documentelor privind livrările.
34
7. Controlul confidenţialităţii, integrităţii şi
accesibilităţii ieşirilor
Alte proceduri de control a ieșirilor
• 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ă
• 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

35
8. Demersul proiectării ieşirilor
În proiectarea ieşirilor trebuie implicaţi în mod direct şi eficient utilizatorii, prin

adoptarea unui procedeu-cadru specific prototipizării iterative.
36
8. Demersul proiectării ieşirilor
Evaluarea ieşirilor de către utilizatori
Stabilitate – presupune folosirea aceloraşi termeni, abrevieri, formate,

titluri etc.
Comoditate – să nu se facă trimiteri la afişări anterioare.
Flexibilitate – 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.
37
9. Formularea specificaţiilor de proiectare a ieşirilor
Specificaţiile de proiectare pentru raportul
“Situaţia vânzărilor de produse finite pe gestiuni şi facturi”
a) Prezentare descriptivă
Scop: - Întocmirea şi verificarea notei contabile privind vânzările.
- Controlul ieşirilor de produse finite din depozite.
Utilizatori: Economistul responsabil cu evidenţa produselor finite.
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 utilizatorului.
- 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: Raportul 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
ARTICOLVANZARE 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 38
...
The user is always right unless proven otherwise by the developer.
Rule of Open-Source Programming #6
Proiectarea interfeţelor
utilizator
Capitolul II
A mature process empowers people to work effectively and efficiently.

1
Obiectivul principal
Proiectarea interacţiunilor dintre

utilizator şi calculator necesare
preluării intrărilor şi generării ieşirilor
din sistem, fie ele formulare/formate
sau rapoarte.
2
„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”
Boris Beizer
3
1. Definirea conceptului de interfaţă utilizator
Accepțiuni ale noțiunii de interfață:
• interfaţa dintre sistemul informațional şi mediul său extern relevant
• interfaţa dintre componentele software ale aplicației
• interfața dintre om şi calculator – interfața utilizator
Definirea interfeței utilizator:
• în sens restrâns – echipamentele de intrare-ieşire şi programele care le deservesc
• în sens larg – include şi alte componente: manualul de instruire şi alte

documentaţii
4
1. Definirea conceptului de interfaţă utilizator
În sens restrâns, interfața utilizator este formată din:
• componente hardware
• componente software
Componentele software ale interfeţei utilizator:
• ecranele pentru culegerea datelor (formularele)
• meniul
• dialogurile prin intermediul cărora utilizatorii pot iniţia diferite operaţiuni

5
2. Identificarea interfeţelor utilizator
Această activitate presupune analiza atentă a intrărilor și ieșirilor în/din sistem

• diagramelor fluxurilor de date
• a granițelor informatizării.
Exemple:
1. fluxul de intrare FACTURA sugerează proiectarea unui ecran prin intermediul căruia
utilizatorul să poată interacționa cu sistemul în vederea preluării datelor din facturi
2. fluxul de ieșire JURNALUL DE CUMPĂRĂRI impune proiectarea unui set de dialoguri
care să permită utilizatorului generarea acestui raport
Există două categorii de intrări/ieşiri în/din sistem:

• care solicită utilizatorul în mod direct şi hotărâtor - interfeţe utilizator
• care NU presupun intervenţia utilizatorului sau ea este minimală - interfeţe sistem
6
2. Identificarea interfaţelor utilizator
Tipuri de interfețe sistem
• Culegerea automată a datelor de intrare prin intermediul unor echipamente speciale
(scanerele, cititoarele de coduri bară – POS-uri, recunoasterea caracterelor scrise cu cerneala
magnetica, dispozitivele RFID, utilizarea chestionarelor)
• Intrări provenite de la alte aplicaţii, integrate prin:

o schimbul de mesaje - de exemplu, o comandă primită prin sistemul EDI
o partajarea unei baze de date comune - datele preluate şi stocate de o aplicaţie vor putea fi
accesate şi de alte aplicaţii, prin includerea în program a unei fraze SELECT SQL.
• Ieşiri automate către alte aplicaţii – de exemplu, î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ă – generarea şi transmiterea lunară a
situaţiei detaliate a soldului pentru clienţii importanţi.
7
3. Metode de interacţiune om – calculator
1. Limbaj-comandă
2. Meniuri
3. Ecrane pentru introducerea datelor (formulare)
8
Interacţiunea prin meniuri
Liste simple cu opţiuni

Zone cu comenzi şi linii-meniu
Meniuri de tip bară
Meniuri context
Meniuri prin imagini/pictograme (icons)
9
Interacțiunea prin meniuri. Meniuri context
Caracteristici
• conţine doar opţiunile de lucru specifice obiectului selectat, în funcţie de
contextul de lucru în care se află utilizatorul
• apare pe ecran lângă obiectul selectat
• este activat prin selectarea unui obiect şi apăsarea butonului dreapta al mouse-
ului
10
Interacţiunea prin meniuri. Meniuri context
11
Interacţiunea prin meniuri. Meniuri prin imagini (icons)

Caracteristici:
• acţiunile de întreprins sunt exprimate prin imagini (icons), nu prin cuvinte
• imaginile folosite funcţionează ca butoanele
Avantaje:
• imaginile sunt cât se poate de sugestive, facilitând utilizarea, memorarea şi
recunoaşterea comenzilor
Dezavantaje:
• sensurile simbolurilor diferă de la o cultură la alta
12
Interacţiunea prin meniuri. Meniuri prin imagini (icons)
Meniu prin imagini
13
Interacţiunea prin ecrane pentru introducerea datelor
• permit utilizatorilor să completeze câmpurile din ecrane cu date preluate din
documentele primare
• datele introduse sunt salvate în baza de date
• permit şi vizualizarea într-o formă logică, structurată, a datelor din bază
14
Obiecte de control pentru construirea formularelor
15
Obiecte de control pentru construirea formularelor
Cycle button
Expander
Slider
Spinner Progress bar
Group
box
16
Exemplu
de ecran
pentru
culegerea
datelor
(formular)
17
Funcţiuni ce trebuie incluse în formulare
• Facilităţi de ieşire
▪ Salvarea conţinutului formularului în baza de date
▪ Confirmarea salvării formei editate sau trecerea la un alt ecran
• Deplasarea în formular
▪ Deplasarea de la un câmp la următorul/precedentul/primul/ultimul
• Posibilităţi de editare
▪ Ştergerea unei linii dintr-o grilă (grid)
• Oferirea informaţiilor ajutătoare
▪ Furnizarea de informaţii despre orice câmp sau despre întregul formular
• Tehnici de validare a datelor introduse
▪ Testarea lipsei datelor în unele câmpuri
▪ Verificarea încadrării valorilor în anumite intervale 18
5. Principii de proiectare a interfeţelor utilizator
Standarde industriale
• Apple Computer (1992) -
https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHI
Guidelines/DesignPrinciples.html
• IBM (1992)
• Microsoft (1995) - https://msdn.microsoft.com/en-

us/library/windows/desktop/ff728831%28v=vs.85%29.aspx
Regulile de bază ale proiectării interfeţelor utilizator

1. Controlul aplicaţiei de către utilizator
2. Limitarea cantităţii de informaţii pe care utilizatorul o memorează
3. Uniformitatea interfeţelor utilizator 19
Regula 1 - Controlul aplicaţiei de către utilizator
Utilizatorul trebuie să simtă că el controlează aplicaţia, nu invers
Aplicarea acestei reguli depinde de:

• experienţa utilizatorilor în lucrul cu interfeţe grafice
şi
• experienţa utilizatorilor în domeniul problemei.
Exemplu de interfaţă în care utilizatorul este sub controlul aplicaţiei:
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:
560200
Doriţi sa salvaţi (d/n)?
d 20
Principii aplicate
• Utilizarea judicioasă a modurilor de lucru
• Păstrarea stilului de lucru al utilizatorilor
• Alegerea între utilizarea tastaturii şi/sau a mouse-ului
• Retroacţiunea (feed-back) imediată

• Asigurarea transparenţei detaliilor de proiectare a programelor şi a bazei
de date
21
Principiul utilizării judicioasă a modurilor de lucru

Mod de lucru - context în care se află o aplicaţie la un moment dat:
• în care utilizatorul poate efectua doar anumite operaţiuni
• de care depinde funcţia pe care o realizează un obiect al interfeţei
Exemple:
• modurile de lucru insert/overwrite din procesoarele de texte
• modul de lucru inserare obiect în Data Modeler
Moduri de lucru comune în aplicaţiile economice:

• vizualizare
• adăugare
• editare. 22
Principiul utilizării judicioasă a modurilor de lucru
• modurile de lucru limitează controlul utilizatorului asupra aplicaţiei
• utilizatorul va efectua un număr suplimentar de operaţiuni, pentru a trece de la un

mod de lucru la altul
• Utilizarea lor este recomandată atunci când:

• există diferite categorii de utilizatori cu drepturi diferite
• se urmăreşte simplificarea interfeţei
• realizarea unor operaţiuni critice
• frecvenţa redusă a operaţiunilor
23
Principiul retroacţiunii imediate
Aplicarea acestui principiu presupune ca interfaţa:
➢ să indice utilizatorului dacă acţiunea iniţiată de el a fost realizată

➢ să afişeze rezultatul acţiunii sale
➢ informarea despre starea operaţiunii în curs, dacă execuţia acesteia
durează mai mult timp
➢ precizarea modului în care o operaţiune poate fi suspendată sau anulată
24
Principiul retroacţiunii imediate
Lipsa retroacţiunii:
• crează utilizatorului o stare de nesiguranţă şi discomfort
• îl obligă la eforturi suplimentare pentru a se asigura că operaţiunea iniţiată a
fost finalizată
Moduri de informare a utilizatorului:

• prin actualizarea liniei de stare a ferestrei principale,
• prin afişarea unui mesaj,
• prin schimbarea culorilor
• prin iniţierea unei casete de dialog.
25
Principiul păstrării stilului de lucru al utilizatorilor
Interfaţa trebuie să reflecte:

• experienţa trecută a utilizatorilor
• aşteptările utilizatorilor
• părerile
• dorinţele utilizatorilor
26
Principiul alegerii între utilizarea tastaturii şi/sau a mouse-ului
• utilizatorii NU trebuie forţaţi să folosească mouse-ul

• interfaţa trebuie să fie optimizată pentru lucrul cu tastatura sau cu mouse-ul –
schimbarea tastaturii cu mouse-ul oboseşte utilizatorul şi îi diminuează
randamentul
• interfaţa trebuie optimizată pentru utilizarea tastaturii în cazul operaţiilor cu grad

mare de repetabilitate
• optimizarea interfeţei pentru lucrul cu tastatura implică acordarea unei atenţii

deosebite facilităţilor de deplasare
27
Principiul transparenţei interfeţei utilizator
Interfaţa trebuie sǎ ascundǎ detaliile privind:

• structura bazei de date
• logica prelucrǎrilor din modulele de program
Exemple:
• neafişarea codurilor interne din baza de date care nu interesează utilizatorii
• controlarea riguroasă a mesajelor de eroare
28
Regula 2 - Limitarea cantităţii de informaţii care trebuie memorată de utilizator
Limitele memoriei umane:
• memoria pe termen scurt este limitatǎ în ce priveşte perioada şi capacitatea

de memorare
• memoria pe termen lung este limitatǎ în ceea ce priveşte regǎsirea informaţiei
Principii aplicate
• Degrevarea utilizatorului de memorarea pe termen scurt a unor informaţii
• Orientarea interfeţelor pe recunoaştere, nu pe amintire
• Prevederea formelor scurte de lucru
• Relevanţa vizuală a obiectelor interfeţei

29
Principiul degrevării utilizatorului de memorarea pe termen scurt
Atunci când se trece de la un ecran la altul, aplicaţia trebuie să memoreze
informaţiile necesare pentru utilizator
Trebuie luate în considerare limitele memorării pe termen scurt:
• timp redus de păstrare - aproximativ 30 de secunde
• volum redus - circa 5 – 9 elemente
30
Principiul orientării interfeţelor pe recunoaştere, nu pe amintire
Metode de regăsire a informaţiei memorată:

• recunoaşterea – se bazează pe utilizarea sugestiilor
• amintirea – fără utilizarea sugestiilor
Exemple:
• utilizarea listelor în locul căsuţelor de text, atunci când este posibilă
• selectarea unei comenzi din meniu în locul tastării ei
• utilizarea metaforelor
31
Principiul prevederii formelor scurte de lucru
Modalitǎţi de definirea a formelor scurte de lucru:
• utilizarea comenzilor mnemonice - pentru selectarea unei opţiuni din meniu
sau a unui element dintr-o căsuţă de tip listǎ

• utilizarea tastelor speciale sau a combinaţiilor de taste - pentru iniţierea mai
directă operaţiunilor
32
Principiul relevanţei vizuale

▪ Sugestivitatea obiectelor - ele sǎ fie uşor de înţeles
• titluri explicite şi inteligibile pentru obiectele care conţin date
• nume sugestive pentru butoane şi grupurile de obiecte
▪ Organizarea obiectelor interfeţei - vizeazǎ gruparea şi aranjarea lor
•gruparea şi delimitarea prin linii sau chenare a obiectelor legate din punct de vedere
logic
• aranjarea obiectelor în concordanţǎ cu cerinţele funcţionale ale utilizatorilor

• reflectarea structurii documentului de pe care se preiau datele
▪ Simplitatea interfeţei - evitarea creării de ecrane încǎrcate
• NU trebuie sacrificatǎ funcţionalitatea aplicaţiei de dragul simplitǎţii 33
Regula 3 - Uniformitatea interfeţelor utilizator
Aplicarea aceloraşi convenţii de proiectare a interfeţelor:
• în cadrul aplicaţiei
• în cadrul sistemului, între diferitele aplicaţii
• cu cele ale sistemului de operare
Beneficii:
• învăţarea mai uşoară a noilor aplicaţii
• reducerea numărului erorilor în culegerea datelor
34
Regula 3 - Uniformitatea interfeţelor utilizator
Principii aplicate:
▪ Principiul uniformităţii în prezentarea interfeţei – utilizatorul să
vadă obiectele interfeţei în acelaşi mod d.p.d.v logic, fizic şi vizual
• comenzile similare din ecrane diferite să aibă aceleaşi nume
▪ Principiul uniformităţii în comportamentul interfeţei – acelaşi
obiect trebuie să aibă un comportament similar în situaţii şi ecrane diferite
• afişarea aceluiaşi mesaj de eroare pentru situaţiile similare ivite în locuri
diferite ale aplicaţiei
▪ Principiul uniformităţii interacţiunii cu interfaţa
• combinaţiile de taste trebuie sǎ aibǎ aceleaşi funcţiuni de la un ecran la altul
sau de la un program la altul
35
36
6. Demersul proiectării interfeţelor utilizator
Proiectarea interfeţelor trebuie să implice în mod direct utilizatorii.
Principiile proiectării orientate spre utilizator:

1. Orientarea spre utilizator şi atribuţiile sale de serviciu, încă de la
începutul dezvoltării sistemului informaţional
2. Evaluarea specificaţiilor de proiectare în vederea asigurării uşurinţei
învăţării şi utilizării noului sistem
3. Angajarea unui proces iterativ de dezvoltare
37
Fazele procesului iterativ de proiectare a interfeţelor utilizator:

1. Colectarea şi analiza informaţiilor privind utilizatorii șisarcinile lor de lucru
2. Proiectarea interfeţei utilizator
3. Implementarea interfeţei
4. Validarea interfeţei
2) Proiectarea 1) Analiza
3) Construirea 4) Validarea
38
Faza 1 Culegerea şi analiza informaţiilor privind utilizatorii
1. Determinarea profilului utilizatorilor

2. Analiza sarcinilor de lucru ale utilizatorilor
3. Identificarea cerinţelor de lucru ale utilizatorilor
4. Analiza mediului de lucru al utilizatorilor
5. Armonizarea cerinţelor utilizatorilor cu sarcinile lor de serviciu
39
Faza 1 Culegerea şi analiza informaţiilor privind utilizatorii
1. Determinarea profilului utilizatorilor – identificarea capacităţilor şi

cunoştinţelor utilizatorilor
Categorii de utilizatori:
• nu au cunoştinţe în domeniul lor de activitate şi nici experienţă în lucrul cu
calculatorul
• fără cunoştinţe în domeniul lor de activitate, dar sunt familiarizaţi cu
sistemele informatice
• au experienţă bogată în domeniul lor de activitate, dar mai puţină experienţă
în utilizarea calculatorului
• experimentaţi atât în domeniul lor de activitate, cât şi în utilizarea sistemelor
informatice
40
Faza 1 Culegerea şi analiza informaţiilor de la utilizatori
2. Analiza sarcinilor de lucru ale utilizatorilor
Oferă răspunsuri la unele întrebări, precum:

• Care sunt sarcinile realizate de utilizatori?
• Care atribuţii sunt mai importante pentru activitatea desfăşurată de utilizator?
• Care sunt operaţiunile necesare pentru realizarea unei atribuţii de serviciu?
• 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?

• 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?41
3. Identificarea cerinţelor de lucru ale utilizatorilor
• reducerea numărului de erori în culegerea datelor
• automatizarea unor activităţi
• sporirea vitezei de culegere a datelor
• efectuarea anumitor verificări asupra datelor introduse
• semnalarea unor situaţii de excepţie

42
4.Analiza mediului de lucru al utilizatorilor – culegerea de informaţii

despre:
➢ caracteristicile fizice ale mediului de lucru (luminozitate, zgomote, spaţiu etc.)
➢ aspectele de ergonomie a muncii
➢ nevoi speciale ale utilizatorilor cu diverse infirmităţi
5.Armonizarea cerinţelor utilizatorilor cu sarcinile lor de serviciu -

se verifică dacă cerinţele exprimate de utilizatori corespund cu caracteristicile
sarcinilor de lucru
43
Exemplu: Proiectarea ecranului pentru preluarea comenzilor primite de la clienţi
1. Profil utilizatori
- abilităţi minime în utilizarea calculatorului;
- o bună cunoaştere a produselor firmei;
- nivel mediu de experienţă în preluarea şi prelucrarea comenzilor.
2. Activităţile utilizatorilor
- înregistrarea unei comenzi noi;
- modificarea unei comenzi;
- anularea unei comenzi;
- vizualizarea datelor privind comenzile unui client.
44
3. 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. 45
4. 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.
4. 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. 46
Faza 2 Proiectarea interfeţei utilizator
1. Definirea obiectivelor de calitate a interfeţelor
2. Definirea scenariilor şi sarcinilor de lucru
3. Definirea obiectelor şi acţiunilor interfeţei
4. Determinarea reprezentărilor vizuale ale obiectelor interfeţei
47
Obiectivele generale privind calitatea interfeţelor utilizator:
• uşor de învăţat
• uşor de utilizat
Obiectivele se definesc în legătura cu patru factori:
▪ utilitatea - măsura în care interfaţa permite utilizatorului să-şi atingă scopul
▪ eficacitatea - uşurinţa şi rapiditatea realizării sarcinilor de lucru
▪ uşurinţa învăţării - timpului de instruire necesar
▪ atitudinea - percepţia şi opiniile utilizatorilor asupra celorlalţi trei factori

48

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
49
la 1 la 7.
• scenariu = descriere generală a unei atribuţii de serviciu ca o succesiune de

operaţiuni executate de utilizator
• scenariile definite trebuie să ghideze proiectarea interfeţelor, nu invers
• definirea de scenarii de lucru distincte, pentru fiecare categorie de utilizatori
50

Scenariul 1. Introducerea unei comenzi noi
➢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. 51


Scenariul 1. Introducerea unei comenzi noi (continuare)
➢ Adăugarea articolelor comandate - operaţie reluată pentru fiecare articol:

➢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.
52
➢ Verificarea valorii calculate pentru articolul respectiv.

Scenariul 1. Introducerea unei comenzi noi (continuare)
➢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). 53

Citirea descrierii scenariilor de lucru şi întocmirea unei liste care să conţină:
Substantivele Obiect Câmp de date (nume client, număr factură)
Verbele Acţiune Comandă (salvare date)
4. Determinarea reprezentărilor vizuale ale obiectelor interfeţei

• tipurile de obiecte specifice interfețelor
• utilizarea unui meniu de tip bară dacă un ecran oferă mai mult de şase
opţiuni de lucru (recomandare IBM) 54
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 55
Faza 3 Construirea prototipului interfeţei utilizator
Reguli fundamentale de construire a prototipului:
• Construirea prototipului cât mai devreme cu putinţă
• Construirea de prototipuri pentru mai multe alternative de proiectare
• Renunţarea la codul scris pentru un prototip, dacă el nu corespunde
specificaţiilor finale
Medii pentru crearea prototipurilor:
• produse CASE
• instrumente grafice specializate - Prototypers (prototipizoare) sau Demo
Builders (constructori demo)
• mediul de implementare – Visual Basic, C#, Java 56
Exemple intrumente pentru construirea interfețelor (GUI):
➢ Pidoco
➢ ForeUI
➢ AxureRP
➢ Pencil
➢ Moqups
Concepte folosite:
➢ Wireframe
➢ Mockup
➢ Prototype
57
58
Exemplu: Proiectarea ferestrei de dialog pentru obţinerea raportului

“Situaţia vânzărilor pe gestiuni şi facturi“
59
Faza 4 Evaluarea şi validarea interfeţei utilizator
Proiectarea
preliminară
Construire
prototip nr. 1
Construire
prototip nr. N
Modificarea
Evaluarea
specificaţiilor
interfeţei
de proiectare
Analiza
rezultatelor
Interfaţă proiectată
complet
• Obiective - aprecierea comportamentului, performanţelor şi satisfacţiei utilizatorilor
• Evaluarea să fie realizată cât mai devreme şi cât mai des cu putinţă 60
7. Reguli de proiectare a meniurilor
Meniul conţine o ierarhie de opţiuni, grupate:

o după criterii funcţionale
•Exemplu: Înregistrare tranzacţii, Actualizare date clienţi şi Generare rapoarte
o pe baza obiectelor din sistem
•Exemplu: Comenzi, Livrări, Încasări, Clienţi, Produse
Proiectarea sistemului de meniuri porneşte de la analiza DFD-urilor:
• se ia în considerare caracteristica generală a sistemului (orientare pe
tranzacţii sau pe transformări)

61
7. Reguli de proiectare a meniurilor
Convenţii de proiectare a meniurilor:
• poziţia Help este întotdeauna ultima din linie

• o săgeată (→) plasată în dreapta ultimului element înseamnă descompunerea acestuia în
submeniuri
• prezentarea elementelor care, dacă sunt selectate, vor conduce la apariţia meniurilor pop-up,
marcate cu (…)
• evidenţierea opţiunilor care pot fi activate la un moment dat
• structura meniului să reflecte succesiunea paşilor pe care o foloseşte utilizatorul
• oferirea accesului direct la opţiunile 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
(restaurarea sau arhivarea bazei de date, administrarea utilizatorilor) 62
8. Reguli de proiectare a interfeţelor Web
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. Oferirea 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
4. Facilitarea explorării rapide - utilizarea grupării şi sub-antetelor 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 - o pagină de

început şi mai multe pagini secundare, fiecare orientată pe un anumit subiect
63
8. Reguli de proiectare a interfeţelor Web
6. Evitarea construirii unor pagini cu multe fotografii
7. Utilizarea de imagini miniaturale relevante - se vor utiliza, în combinaţie,

redimensionarea şi decuparea.
8. Utilizarea de titluri sugestive pentru legături - care să ofere o imagine corectă

asupra conţinutului paginii înainte de a fi deschisă
9. Oferirea de facilităţi speciale de accesare utilizatorilor cu diferite infirmităţi
10. Conceperea interfeţei în aceeaşi manieră în care o fac ceilalţi

64
9. Controlul datelor în interfeţele utilizator
Erori tipice în culegerea datelor

Mecanisme pentru controlul automat al datelor:
Mecanism de control Explicații
Tipul datelor Se verifică dacă datele dacă sunt de un anumit tip (numerice,
alfanumerice, date calendaristice etc.)
Verosimilitate Verosimilitatea datelor depinde de la caz la caz. De exemplu,
cantitatea vândută 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.
Selectarea unei valori, Atunci când este posibil, aplicaţia va permite utilizatorului să
în locul introducerii ei aleagă o valoare dintr-o listă, prin utilizarea căsuţelor combinate
sau a celor de tip listă. De exemplu, pentru introducerea tipului de
document se va prevedea în formular o căsuţă combinată sau
butoane de opţiune.
65

Tehnica cifrei de Această tehnică este utilizată pentru verificarea corectitudinii
control codurilor utilizate în aplicaţie, cum ar fi codul mărfii, al
furnizorului etc. Un exemplu este prezentat mai jos.
Formatul datelor Pentru unele date pot fi definite şabloane, urmând a se verifica
dacă datele introduse corespund acestora. Astfel de şabloane pot fi
definite pentru datele calendaristice, numere de telefon, numere de
înmatriculare a autoturismelor etc.
Depistarea datelor Câmpurile din formulare, care sunt obligatoriu de completat,
lipsă trebuie semnalate utilizatorilor, iar în momentul salvării datelor se
va verifica dacă au fost completate toate câmpurile.
66

Numărul de caractere Numărul de caractere care trebuie introduse într-un câmp trebuie
verificat atunci când este cunoscut. De exemplu, CNP-ul unei
persoane este format din 13 cifre.
Compararea datelor Validitatea datelor introduse în formulare poate fi determinată prin
introduse cu cele compararea lor cu datele stocate deja în baza de date. De exemplu,
stocate la introducerea codului sau a numelui clientului se va verifica dacă
el există în baza de date. Acest mecanism permite utilizatorilor să
verifice corectitudinea datelor introduse, înainte de salvarea lor.
Intervale de valori Se verifică dacă datele introduse de utilizator se încadrează în
intervalele de valori admise. De exemplu, notele obţinute la
examen să fie în intervalul 0 – 10, stocul să fie mai mare decât 0
etc.
67
Exemplu de utilizare a tehnicii cifrei de control
Se consideră codul numeric 12012
Numerele prime cu care va fi ponderată fiecare cifră din cod sunt:
1 2 0 1 2
1 2 3 5 7
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.
68
Alte mecanisme de control
• afişarea informaţiilor de identificare
• afişarea unor totaluri sau a altor câmpuri calculate
69
10. Formularea specificaţiilor de proiectare a interfeţelor
Specificaţie de proiectare
1. Prezentare generală descriptivă
1. Numele interfeţei/dialogului
2. Caracteristicile utilizatorului
3. Caracteristicile activităţii
4. Caracteristicile sistemului
5. Caracteristicile mediului de lucru
2. Proiectele interfeţelor/dialogurilor
1. Proiectele formularelor/formatelor/rapoartelor
2. Diagramele secvenţelor de derulare a dialogurilor şi prezentarea descriptivă a lor
3. Testarea şi evaluarea interfeţelor/dialogurilor în utilizare
1. Obiectivele testării
2. Procedurile testării
3. Rezultatele testării
1. Timpul de învăţare
2. Viteza de execuţie
3. Rata erorilor
4. Rezistenţa în timp
5. Satisfacţia şi alte percepţii ale utilizatorului 70
“The difference between theory and practice is that in theory, there is no
difference between theory and practice, but in practice, there is.”
Jan van de Sneptscheut
An army of sheep led by a lion would defeat

an army of lions led by a sheep.
Arab Proverb
Information necessitating a change of design will be conveyed to the

designer after and only after the design is complete.
(Often called the 'Now They Tell Us' Law)
Fyfe's First Law of Revision
Capitolul III
Proiectarea logică a
bazelor de date
3.1 Locul modelării logice a datelor în CVS
Aplicarea principiului abstractizarii in modelarea datelor
Cerintele functionale ale sistemului
Nivelul conceptual al datelor

Regulile modelului
(modelul entitate-relatie) Cerintele de calitate
relational
(flexibilitate, stabilitate)
Nivelul logic al datelor

Cerintele nefunctionale (modelul relational pur)
Facilitatile SGBD-ului
si de performanta
Nivelul fizic al datelor

(modelul fizic al datelor)
3.1 Locul modelării logice a datelor în CVS
Criterii de calitate ale modelului logic al datelor
Completitudine - să conţină toate datele necesare prelucrărilor

Neredundanţă - să fie format dintr-un set de tabele normalizate
Stabilitate – schimbarea cerinţelor funcţionale să nu determine modificarea
structurii logice a datelor
Flexibilitate - uşurinţa extinderii structurii logice a datelor pentru înglobarea unor
noi cerinţe
Simplitate şi eleganţă - să ofere o clasificare naturală şi elegantă a datelor (de
exemplu, să nu existe două tabele FURNIZOR şi CLIENT)
3.2 Modelul relaţional
Concepte utilizate
Bază de date relaţională - un ansamblu de relaţii (tabele) aflate în

legătură
• este identificată printr-un nume propriu

• este formată din linii (tupluri) şi coloane (atribute)
Relaţie (tabelă)
• la intersecţia cărora se introduc valori atomice (date
elementare)
Domeniu - mulţimea tuturor valorilor pe care le poate lua o dată

elementară
3.2 Modelul relaţional
Concepte utilizate (cont.)
Cheie - ansamblul minimal de atribute prin care se poate identifica în mod unic orice
tuplu dintr-o relaţie
Cheie candidat - un atribut sau o combinaţie de atribute care să joace rolul de cheie
Cheie primară – o cheie candidat aleasă special
Cheie secundară – o cheie candidat care nu a fost aleasă cheie primară
Cheie străină (externă) - un atribut care apare într-o tabelă şi care este cheie
primară în altă tabelă. Ea este utilizată pentru stabilirea legăturilor între tabele.
Restricţie de integritate referenţială - pentru cheia străină se admite orice valoare
nenulă care se regăseşte între valorile cheii primare din tabela-părinte
3.2 Demersul de proiectare a bazei de date
Strategii de proiectare a schemei bazei de date
1. strategia bottom-up, reprezintă abordarea tradiţională şi presupune

▪ constituirea relaţiei generale
▪ analiza relaţiilor de dependenţă dintre atribute şi parcurgerea
paşilor normalizării
2. strategia top-down, presupune următoarele activităţi:
▪ analiza cerinţelor funcţionale şi întocmirea modelului conceptual
(DER)
▪ transformarea modelului ER prin aplicarea unui set de reguli
▪ analiza tabelelor obţinute din perspectiva normalizării
Strategii de proiectare a schemei bazei de date (cont.)
Avantajele strategiei top – down:

➢ DER reprezintă un instrument util de comunicare între analişti şi
utilizatori
➢ DER este uşor de înţeles şi conceput
➢ Utilizează conceptul de abstractizare - se reduce considerabil
numărul obiectelor analizate. Numărul entitaţilor de date este mult
mai mic decât numărul datelor elementare din sistem.
➢ Existenţa unui set complet de reguli de transformare a DER în
schema logică a bazei de date - suport pentru generarea automată a
bazei de date
Paşii demersului
1. Construirea unor modele logice ale datelor corespunzatoare
perspectivelor diferitelor categorii de utilizatori
2. Contopirea tuturor perspectivelor normalizate ale utilizatorilor
3. Transformarea DER intr-un set de tabele normalizate
4. Obţinerea modelului logic final prin compararea modelului logic
consolidat (pasul2) cu modelul obţinut prin transformarea DER
(pasul 3)
3.3 Transformarea diagramelor entitate-relaţie
Prin transformarea DER, pot rezulta patru tipuri de tabele:

1. Tabele care vor avea acelaşi conţinut ca entităţile originale.
2. Tabele care vor conţine cheia primară a entităţii părinte.
3. Tabele care vor conţine cheile tuturor entităţilor asociate într-
o relaţie.
4. Tabele care vor conţine atributele multivaloare ale unei
entităţi.
Activităţile specifice transformării DER
▪ Reprezentarea entităţilor - se vor obţine tabele din prima categorie

▪ Reprezentarea relaţiilor de asociere dintre entităţi - vor rezulta
tabele din categoriile a doua şi a treia
▪ Reprezentarea relatiilor de mostenire – exista trei strategii
▪ Reprezentarea atributelor multivaloare - se vor obţine tabele din
categoria a patra
▪ Normalizarea relaţiilor - tabelele obţinute anterior pot conţine
redundanţe nedorite
3.3.1 Transformarea entităţilor

Reguli de transformare:
▪ fiecare entitate/clasa din DER este reprezentată ca o relaţie (tabelă) în
modelul logic
▪ identificatorul entităţii devine cheie primară a relaţiei
▪ celelalte proprietăţi ale entităţii devin atribute non-cheie ale relaţiei
NUME
(a) MARCA ADRESA

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

ANGAJAT
Marca Nume Adresa
(d)
1111 Ion Ion Arini, 28, Iasi
1122 Ion Ionel Anini, 120, Blaj
3.3.2 Reprezentarea legăturilor
Se ia în considerare cardinalitatea/multiplicitatea legăturilor dintre

entităţi:
▪ maximul cardinalităţii indică tabela care va conţine cheia străină
✓ ea se va numi entitate slabă (tabelă copil)
▪ minimul cardinalităţii descrie caracterul obligatoriu/facultativ al
legăturii
✓ indică dacă pentru cheile străine sunt permise valorile nule
sau nu
Exemple de relații
3.3.2.1 Transformarea legăturii binare de tipul 1:1
1. Tabela părinte este cea aflată de partea cu cardinalitatea minimă 1 a legăturii
2. Există patru variante posibile de transformare:
➢ adăugarea cheii primare a entităţii A la entitatea B ca cheie străină

➢ adăugarea cheii primare a entităţii B la entitatea A ca cheie străină
➢ unirea celor două entităţi într-o singură tabelă
➢ combinarea cazurilor 1 şi 2, dacă cerinţele de acces la date o cer
3.3.2.1 Transformarea legăturii binare de tipul 1:1 (cont.)

Factura
Fact_id Factura
Fact_nr Fiecărei facturi îi va Fact_id
Fact_data corespunde cel mult o Fact_nr
recepţie sau nici una, iar Fact_data
(1,1)
o recepţie are la bază
exact o factură.
Corespunde
Receptie
(0,1) Rec_id
Receptie Rec_nr
Rec_id Rec_data
Rec_nr Fact_id [FK] NOT NULL
Rec_data
3.3.2.1 Transformarea legăturilor 1:N
(participarea entităţii de partea “unu” este obligatorie)
Furnizor
Furn_id Fiecare factura este emisă Furnizor
Furn_nume de un singur furnizor, în Furn_id
(1,1) timp ce un furnizor poate Furn_nume
emite mai multe facturi
sau nici una.
Emitere
Factura
Fact_nr
(0,M) Fact_data
Factura Furn_id [FK] NOT NULL
Fact_nr
Fact_data
➢ entitatea aflată de partea “M” va conţine cheia străină
➢ NU se admit valori nule pentru cheia străină
3.3.2.1 Transformarea legăturilor 1:N
(participarea entităţii de partea “unu” este facultativă)
AgentComercial Fiecare agent comercial

agentId
agentNume
poate incheia una sau AgentComercial
mai multe comenzi, însă agentId
(0,1) nu este obligatoriu ca o agentNume
comanda să fie incheiata
Incheie de un agent – clientul
poate veni direct in firma
sau lanseaza comanda
Comanda
prin intermediul site-ului
(0,M) cmdId
firmei. cmdNumar
Comanda
agentId [FK] NULL
cmdId
cmdNumar
➢ entitatea aflată de partea “M” va conţine cheia străină
➢ se admit valori nule pentru cheia străină
3.3.2.2 Transformarea legăturilor binare de tip M:N
➔ se creează câte o tabelă aferentă celor două entităţi
➔ se creează a treia tabelă, aferentă legăturii M:N, numită entitate asociativă
▪ conţine cheile primare ale celor două entităţi şi eventualele atribute ale
legăturii M:N
▪ cheia primară este formată, de regulă, prin combinarea celor două chei
străine
▪ sunt situaţii când în compoziţia cheii primare trebuie introduse şi alte
atribute, pe lângă cele două chei străine
➔ nu se admit valori nule pentru cheile străine
Atentie! Tabela asociativa se creeaza chiar daca relatia nu are atribute proprii –
ea va contine doar cheile straine
Să fiți sănătoși si să aveți multe,
multe bucurii!
3.3.2.2 Transformarea legăturilor binare de tip M:N
Fiecare factura poate contine mai multe produse, iar

un produs se poate regasi pe mai multe facturi
Produs
Produs Prod_id
Prod_id Prod_den
Prod_den
(1,M)
Articol_factura
Cantitate Prod_id [FK]
Contine Fact_nr [FK]
Cantitate
Pret Pret
(0,M)
Factura Factura
Fact_nr Fact_nr
Fact_data Fact_data
3.3.2.3 Transformarea legăturilor recursive de tip 1:M
ANGAJAT
Marca_angajat Un angajat poate conduce ANGAJAT
(0,M)
Nume Marca_angajat
Alte_date
mai mulţi angajaţi sau nici
Nume
unul, iar fiecare angajat are Alte_date
((0,1)
1)
un manager şi numai unul Marca_manager [FK] NULL
Conduce
3.4.2.2 Transformarea legăturilor recursive de tip M:N
ARTICOL
ARTICOL Cod_articol
Cod_articol (0,M ) Denumire
Denumire Cost
Cost
Un articol poate conţine mai
(0,M ) multe articole, iar un articol
poate intra în fabricaţia mai
multor alte articole.
Contine
ARTICOL_COMPONENT
Cod_articol
Cod_componenta [FK]
Cantitate Cantitate
3.3.2.2 Transformarea legăturilor ternare
➔ se creează câte o tabelă aferentă celor trei entităţi
➔ se creează a patra tabelă, aferentă legăturii ternare, numită entitate
asociativă (tabelă copil)
➔ tabela copil conţine cheile primare ale celor trei entităţi, ce vor fi chei
străine, şi eventualele atribute ale legăturii ternare
3.3.2.2Transformarea legăturilor ternare
Reguli de transformare (continuare):

➔ formarea cheii primare a tabelei copil:
✓ dacă toate entităţile prezintă cardinalitatea maximă „unu”, cheia primară se
formează prin combinarea oricăror două din cele trei chei străine
✓ dacă două dintre entităţi prezintă cardinalitatea maximă „unu”, cheia primară
se formează prin combinarea cheii entităţii din partea „multe” şi una dintre cheile
entităţilor situate de partea „unu”
✓ dacă o singură entitate prezintă cardinalitatea maximă „unu”, cheia primară va
fi formată prin combinarea cheilor celor două entităţi situate de partea „multe”
✓ dacă toate cele trei entităţi au cardinalitatea maximă „multe”, cheia primară va
fi formată din cheile tuturor celor trei entităţi
3.3.2.2 Transformarea legăturii ternare (tipul „unu-la-unu-la-unu”)
Tehnician
Ang_id
Ang_nume
1
Proiect Documentatie
1 Intocmeste 1
Pr_id Doc_nr
Pr_den Doc_termen
Un tehnician poate lucra la mai multe proiecte insa el intocmeste o singura documentatie pentru
fiecare proiect in parte; fiecare documentatie este intocmita de un singur tehnician pentru un
singur proiect; un proiect poate avea mai multe documentatii, dar fiecare documentatie va fi
intocmita de un singur tehnician. Tehnician
Ang_id
Ang_nume
Proiect Doc_proiect Documentatie

Pr_id Pr_id [FK] Doc_nr
Pr_den Doc_nr [FK] Doc_termen
Ang_id [FK]
In tabela Doc_proiect exista trei variante pentru stabilirea cheii: Pr_id si Doc_nr; Pr_id si
Ang_id; Doc_nr si Ang_id.
3. Transformarea diagramelor entitate-relaţie
3.3.2.2 Transformarea legăturii ternare (tipul „unu-la-multe-la-multe”)
Profesor Fiecare student sustine un examen cu

Prof_id
un singur profesor, insa el poate fi
Prof_nume
examinat de acelasi profesor la mai
1
multe discipline. De asemenea, un
profesor examineaza la o disciplina
Disciplina M N Student mai multi studenti.
Disc_id Examin Stud_id
eaza
Disc_den Stud_nume
Profesor
Prof_id
Exam_data Exam_nota 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
3.3.2.2 Transformarea legăturii ternare (tipul „multe-la-multe-la-
multe”)
Angajat
Ang_id M – un angajat poate lucra la
Ang_nume un loc de munca in cadrul
P
mai multor formatii.
N – un angajat poate lucra
Formatie M N Loc_munca intr-o formatie, dar la mai
Form_id Lucreaza Locm_id multe locuri de munca.
Form_nrang Locm_den P – o formatie care lucreaza
intr-un loc de munca poate fi
Angajat alcatuita din mai multi
Nr_ore Ang_id angajati.
Ang_nume
Formatie Pontaj Loc_munca

Form_id Ang_id [FK] Locm_id
Form_nrang Form_id[FK] Locm_den
Locm_id [FK]
Nr_ore
3.3.2.3 Transformarea atributelor multivaloare
Carte Atributele multivaloare Carte

ISBN Copie
ISBN Cota si Stare sunt
Titlu Cota
Titlu separate într-o tabelă
Stare
Cota distinctă. Ea se mai
ISBN [FK]
Stare numeşte şi entitate
atributivă.
Recomandări privind proiectarea BD
1. Utilizarea conventiilor in atribuirea de nume – numeTabel –

opus NumeTabel
2. Stabilirea unui prefix unic pt fiecare tabela, care sa fie utilizat
ca parte a numelor atributelor
3. Pastrarea numelor pt atributele cheie straina – ramane cu
prefixul de la tabela parinte
4. Evitarea cheilor primare compuse sau chiar a celor cu
semnificatie pentru utilizator (utilizatorul ar putea sa modifice
valoarea). Numele atributului cheie primara PrefixTabelaID, cu
valori atribuite automat ca secventa.
Rezultatul transformării
NORMALIZAREA BAZELOR DE DATE
- pe scurt -
3.4 Simplificarea structurii datelor prin normalizare
De ce normalizarea?
Anomalii la actualizare - dificultăţi în

ceea ce priveşte efectuarea operaţiilor de:
• Inserare;
• Modificare;
• Ştergere.
De ce normalizarea?
Anomaliile la inserare - dificultatea, uneori chiar imposibilitatea, introducerii unor noi

date în bază, datorită încălcării uneia dintre cele trei restricţii privind cheia primară –
neadmiterea valorilor nule.
De ce normalizarea?
2. Anomaliile la modificare se referă la dificultatea modificării valorii unui atribut

care se repetă în mai multe linii.
Baza de date normalizată
De ce normalizarea?
3. Anomaliile la ştergere se manifestă atunci când prin ştergerea unei linii din tabelă
se pierd involuntar şi informaţii care prezintă încă interes pentru utilizatorii
aplicaţiei.
Forme ale normalizării
Normalizarea
• „Situaţia lunară a vânzărilor”, care conţine ca date

elementare NrFactura, DataFactura, CodClient,
NumeClient, CodProdus, DenProdus, UM, Cantitate,
PretVanzare şi Valoare.
• „Lista stocurilor de produse finite”, care are drept date
elementare CodProdus, DenProdus, UM, PretVanzare şi
Stoc.
• „Situaţia clienţilor firmei”, având ca date elementare
CodClient, NumeClient, Adresa şi Sold.
Cheia primară
Prima formă normalizată (1FN)
O relaţie este considerată în prima formă

normalizată (1FN), dacă şi numai dacă toate
atributele care o formează sunt atomice, deci
relaţia nu conţine grupuri repetitive.
La intersecţia fiecărei linii cu o coloană

trebuie să existe întotdeauna exact o valoare,
niciodată un grup de mai multe valori.
A doua normalizată (2FN)
O relaţie este în forma a doua normalizată dacă şi

numai dacă ea se află deja în prima formă şi nu
conţine dependenţe funcţionale parţiale.
Fiecare atribut non-cheie este dependent total

de cheia primară.
• dependenţă funcţională: X Y
• dependenţă funcţională parțială: X Y și Z Y

Transformarea unei relaţii în 2FN presupune

descompunerea acesteia, prin constituirea a câte
o relaţie pentru fiecare grup de dependenţe
funcţionale parţiale, şi a unei relaţii care va
conţine numai dependenţele totale.
Ce s-a rezolvat?
• Anomalii la adăugare. Poate fi adăugat un nou produs, chiar dacă acesta nu
este implicat încă în nici o operaţiune de vânzare, prin simpla adăugare a unui
tuplu (linie) în relaţia PRODUS.
• Anomalii la modificare. Datele care privesc un anumit produs apar o singură

dată, deoarece în relaţia PRODUS există câte un tuplu pentru fiecare produs.
Astfel, actualizarea atributului Stoc, pentru a reflecta o operaţiune de vânzare,
implică modificarea acestui atribut doar într-un singur tuplu, respectiv cel din
relaţia PRODUS, care conţine datele privitoare la produsul respectiv.
• Anomalii la ştergere. Putem şterge datele despre vânzarea consemnată prin

factura 81005, din relaţia VANZARE_2FN, fără a pierde datele relative la
produsul „Bibliotecă Livia”, care rămân neşterse în tabela PRODUS.
Ce NU s-a rezolvat?
• Anomalii la adăugare. Nu este posibilă adăugarea unui client

nou până în momentul emiterii unei facturi pentru clientul
respectiv.
• Anomalii la modificare. Dacă se doreşte modificarea datelor

despre un client, de exemplu adresa, atunci trebuie căutate şi
modificate toate liniile în care apare clientul respectiv.
• Anomalii la ştergere. În cazul ştergerii datelor privitoare la o

factură, există posibilitatea pierderii şi a datelor relative la
clientul respectiv
A treia normalizată (3FN)
O relaţie se află în a treia formă normalizată dacă şi numai dacă

ea se află în cea de-a doua formă normalizată şi nu conţine
dependenţe funcţionale tranzitive.
Dependenţă funcţională tranzitivă: X Y și Y Z => X Z:

X Y Z
Transformarea unei relaţii din 2FN în 3FN se poate realiza în

următoarea manieră:
1. identificarea grupurilor de dependenţe tranzitive în relaţia

analizată;
2. extragerea grupurilor de dependenţe tranzitive şi constituirea a

câte o relaţie nouă pentru fiecare grup în parte;
3. atributele rămase în relaţia iniţială (respectiv cele care depindeau

în mod direct de cheie) vor forma o nouă relaţie.
Ce s-a rezolvat?
Anomalii la adăugare. Adăugarea unui client nou poate fi efectuată chiar dacă nu
s-a emis încă o factură pentru acel client, prin inserarea unei linii în tabela CLIENT.
Anomalii la modificare. Datele privitoare la un client anume vor apărea o singură

dată, în tabela CLIENT, iar modificarea unei anumite informaţii despre acesta, de
exemplu adresa, va presupune actualizarea unei singure linii.
Anomalii la ştergere. În cazul ştergerii unei facturi nu mai există posibilitatea

pierderii informaţiilor despre clientul respectiv, deoarece această operaţiune implică
ştergerea unei linii din tabela FACTURA, nu şi a liniei corespunzătoare clientului
respectiv din tabela CLIENT.
Baza de date normalizată
Graful dependenţelor funcţionale pentru relaţia VANZARE
6. Mecanismul tranzacţional al BD
6.1 Definirea mecanismului tranzacţional
Tranzacţie
➔ ansamblu de operaţiuni executate împreună asupra bazei de date
➔ o unitate logică de prelucrare care garantează consistenţa bazei de date
O bază de date este într-o stare consistentă dacă datele respectă toate restricțiile
de integritate definite asupra lor.
Mecanismul tranzacţional trebuie să rezolve următoarele două probleme:
• Controlul concurenţei - mecanismele de blocare
• Rezistenţa la defecte - toleranţa sistemului la defecte şi capacitatea de

recuperare a acestuia
6.2 Exemplu tranzacţie – Adăugare factură
Denumire Nume tabelă accesată Tip acces Explicaţii

operaţiune
Adăugare FACTURA Insert DataFactura ia valoarea datei din
factură sistem, iar celelalte valori sunt preluate
din ecranul de culegere a datelor.
Adăugare ARTICOLFACTURA Insert Toate datele se preiau din ecranul

articole factură pentru culegerea datelor.
Actualizare sold CLIENT Update Se incrementează valoarea atributului

client Sold, cu 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

stocuri Stoc cu cantitatea vândută, pentru
fiecare produs în parte. Identificarea
înregistrărilor actualizate se face pe
baza codului produsului.
6.3 Proprietăţile tranzacţiilor
• Atomicitate -o tranzactie este considerata o unitate elementara de

prelucrare, adica executia unei tranzactii se face pe principiul totul sau nimic.
• Consistenţa - se refera la corectitudinea tranzactiei din punctul de vedere

al restricțiilor de integritate definite asupra datelor.
• Izolarea - presupune ca orice tranzactie sa aiba acces doar la starile

consistente ale bazei de date.
• Durabilitatea - odată ce tranzacția este validata, efectele sale devin

permanente si vor fi înscrise în baza de date.

Teorei Parțial SIFC2

Încărcat de

Informații document

Titlu original

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

Teorei Parțial SIFC2

Încărcat de

Drepturi de autor:

Formate disponibile

If Builders Built Buildings The Way Programmers Write Programs,

The quality of a software product is largely governed by the

Proiectarea intrărilor şi ieşirilor din sistem,

Un formular/format – document primar care conţine:

Caracteristica Descriere Clasificarea ieşirilor

Caracteristica Descriere Clasificarea ieşirilor

Caracteristica Descriere Clasificarea ieşirilor

Rapoartele pot avea utilizări diverse:

• controlul activităţilor economice

• luarea deciziilor pe diferite niveluri ierarhice

• transferul informaţiilor în afara organizaţiei

• întocmirea unor documente sau a altor rapoarte

Scopul ieşirilor influenţează alte aspecte de proiectare:

Destinatarii ieşirilor – aspecte proiectare:

• tabelar - organizarea informaţiilor în linii şi coloane;

“Situaţia lunară a vânzărilor” poate include totalul general, totalul

“Situaţia vânzărilor pe clienţi” poate conţine câte o linie pentru

• dinamice - combinarea rapoartelor de sinteză cu cele detaliate.

Introducere sugestivă (partea de titlu)

Informaţiile din instrucţiuni

Partea principală (corpul ieşirii)

Concluziile (finalul ieşirii)

Deplasarea lejeră prin document (navigarea)

Caracterele: Se recomandă folosirea literelor mari şi mici, inclusiv

Spaţierea: Dacă este posibil, este de dorit folosirea dublei spaţieri.

Alinierea: Se recomandă alinierea textului la stânga şi, dacă nu se poate

Despărțirea în silabe: În textele ecranelor, ale rapoartelor nu se

Abrevierile: Nu se recomandă folosirea abrevierilor pentru cuvinte care

• O imagine este mai sugestivă decât 1 000 de cuvinte

Recomandări generale pentru construirea graficelor

Principalele proceduri de control

Alte proceduri de control a ieșirilor

• includerea, în antetul rapoartelor, a datei la care au fost generate

• formularea clară a titlului raportului, în care să fie precizată perioada de timp

• 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

În proiectarea ieşirilor trebuie implicaţi în mod direct şi eficient utilizatorii, prin

Evaluarea ieşirilor de către utilizatori

Stabilitate – presupune folosirea aceloraşi termeni, abrevieri, formate,

Situaţia vânzărilor pe gestiuni şi facturi

Emis de Ionescu Ionela Data: 02.02.2006

c) Testarea şi evaluarea comportamentului la utilizare

A mature process empowers people to work effectively and efficiently.

Proiectarea interacţiunilor dintre

Accepțiuni ale noțiunii de interfață:

• interfaţa dintre sistemul informațional şi mediul său extern relevant

• interfaţa dintre componentele software ale aplicației

• interfața dintre om şi calculator – interfața utilizator

Definirea interfeței utilizator:

• în sens restrâns – echipamentele de intrare-ieşire şi programele care le deservesc

• în sens larg – include şi alte componente: manualul de instruire şi alte

În sens restrâns, interfața utilizator este formată din:

Componentele software ale interfeţei utilizator:

• ecranele pentru culegerea datelor (formularele)

• dialogurile prin intermediul cărora utilizatorii pot iniţia diferite operaţiuni

Această activitate presupune analiza atentă a intrărilor și ieșirilor în/din sistem

Există două categorii de intrări/ieşiri în/din sistem:

• Intrări provenite de la alte aplicaţii, integrate prin:

3. Ecrane pentru introducerea datelor (formulare)

Interacţiunea prin meniuri

Liste simple cu opţiuni

• numărul de pagină să fie în formatul “pagina _ din _”