SISTEME INFORMATICE DE

GESTIUNE
1. Introducere în proiectarea sistemelor informatice
1.1. Sistem informaţional şi sistem informatic
Un proiect reprezintă un proces unic, constând într-o mulţime de activităţi
coordonate şi controlate, cu termene de începere şi de terminare, care garantează
realizarea unui obiectiv conform cerinţelor specificate incluzând restricţii de timp, cost
resurse[11]. Prin proiectare se înţelege ansamblul acţiunilor şi operaţiilor anticipate să se
realizeze conform finalităţilor asumate la nivel de sistem în vederea asigurării
funcţionării în cele mai bune condiţii a elementelor rezultate.
Un sistem reprezintă un ansamblu de elemente (componente) interdependente
între care se stabileşte o interacţiune dinamică, pe baza unor reguli prestabilite, cu scopul
atingerii unui anumit obiectiv[14].
Conform teoriei sistemelor, orice organism economic este un sistem, deoarece:
- prezintă o structură proprie, constând dintr-o mulţime de componente care
interacţionează între ele;
- fluxurile existente între aceste componente implică resursele entităţii economice:
- fluxuri materiale (de materii prime, semifabricate, produse finite,
consumabile, etc);
- fluxuri financiare (încasări, plăţi);
- fluxuri informaţionale (informaţii transmise de la un departament la altul,
de la conducere spre subordonaţi).
- mulţimea componentelor organizatorice şi interacţiunea dintre acestea urmăresc
realizarea unui anumit obiectiv global: funcţionarea firmei în condiţii optime, sau
atingerea unor obiective prestabilite.
Într-o organizaţie cu caracter economic se disting 3 subsisteme:
-subsistemul decizional;
-subsistemul informaţional;
-subsistemul operativ.
5
Subsistemul decizional
Subsistemul operational
Subsistemul informational
Informatii
Date
Decizii
Decizii
Flux informational
Flux material/financiar
Mediul Exterior
Figura 1 Subsistemele organizaţiei economice
Un sistem informațional reprezintă un ansamblu de procedee și mijloace de
colectare, prelucrare și transmitere a informației necesare procesului de conducere a
întreprinderilor, instituțiilor, organizaţiilor etc[4].
La nivelul operativ (în cadrul căruia este desfăşurată activitatea economică a
întreprinderii) are loc culegerea de date. Datele reprezintă atribute cantitative şi calitative
ale unei variabile ce se obţin în urma unor măsurători, sau a unor observaţii. În cazul
entităţii economice, aceste date sunt rezultate în urma fluxurilor materiale şi financiare
specifice organizaţiei economice. Ele sunt transmise în continuare către sistemul
informaţional în vederea stocării şi prelucrării, având ca finalitate obţinerea de informaţii
necesare top-managementului, informaţii ce sunt utilizate în fundamentarea deciziilor. Pe
lângă faptul că acest subsistem este principalul furnizor de informaţii necesare pentru
fundamentarea deciziei, conducere şi control, un alt rol important al sistemului
informaţional este realizarea legăturii dintre sistemul decizional şi cel operativ. Astfel,
deciziile formulate de către conducere sunt furnizare către nivelul executiv prin
intermediul subsistemului informaţional. Sistemul informaţional nu trebuie să fie văzut
doar ca o punte de legătură dintre celelalte două subsisteme, el putând fi considerat şi ca
un element de legătură dintre mediul intern al întreprinderii şi cel extern.
În concluzie, un sistem informaţional:
- colectează informaţiile din sistemele operaţional şi decizional, precum şi cele ce
vin din mediul exterior;
- memorează informaţiile colectate, precum şi cele rezultate din prelucrarea lor;
- asigură accesul la memorie în vederea furnizării de informaţii către celelalte
subsisteme ale unei companii, dar şi pentru mediul extern;
6
- prelucrează informaţii la cererea sistemului operativ şi decizional.
Sistemul informatic este acea parte parte a sistemului informaţional care permite
realizarea operaţiilor de culegere, stocare, prelucrare, transmitere a datelor şi difuzare a
informaţiilor obţinute prin intermediul unităţilor de calcul aferente tehnologiei
informaţiei (TI).
Diferenţele principale care apar între date şi informaţii sunt:
- datele reprezintă atribute colectate din diverse locuri, nedefinite sau
neorganizate într-o formă care să stea la baza luării deciziilor;
- informaţiile sunt obţinute prin prelucrarea datelor, rezultatul trebuind să fie
concis, actual, complet şi clar, astfel încât să răspundă cerinţelor informaţionale în scopul
cărora au fost prelucrate datele.
Relaţia dintre sistemul informatic şi cel informaţional poate fi observată în Tabel
1.
Tabel 1 Relaţia dintre sistemul informatic şi cel informaţional
Sistem informaţional
Tip sistem Sistem informatic
utomatizat
Manual
Instrumente culegere date Sistem informatic Electronice
Manuale
Procesor de informaţii Sistem informatic Calculatorul
Omul
Stocarea informaţiei Sistem informatic Fişiere informatice
Fişiere manuale
Transmiterea informaţiei Sistem
informatic Electronic
Documente scrise, viu grai
Reguli
Sistem informatic Programe şi structuri
de date
Reguli şi proceduri scrise
Sistemul informatic prezent în cadrul oricărei companii cuprinde:
- informaţiile externe şi interne, formale sau informale, utilizate în cadrul
companiei, precum şi datele care au stat la baza obţinerii acestor informaţii;
- produsele software, procedurile şi tehnicile de obţinere a datelor şi difuzare a
informaţiilor (eventual bazele de date necesare stocării datelor);
- echipamentele hardware necesare obţinerii, stocării, prelucrării datelor şi
disipării informaţiilor;
- personalul specializat în culegerea, stocarea, prelucrarea şi transmiterea datelor
în funcţie de necesităţi.
Obiectivul principal urmărit prin introducerea unor sisteme informatice în cadrul
unei organizaţii îl constituie asigurarea conducerii cu informaţii actualizate şi istorice,
7
complete, reale, clare, având diferite grade de detaliere şi diferite moduri de prezentare şi
în timp util, toate acestea fiind necesare fundamentării şi elaborării operative a deciziilor.
Din cele prezentate reiese că sistemul informatic este structurat astfel încât acesta
să poată fi utilizat de diferite categorii de persoane:
- persoane aflate la nivelul decizional;
- persoane aflate la nivelul operaţional;
- persoane implicate în culegerea şi prelucrarea datelor;
- persoane implicate în cercetare;
- alte persoane din mediul extern.
Într-o organizaţie sistemul informatic poate fi format din mai multe subsisteme
interdependente. Aceste subsisteme pot fi formate, la rândul lor, din mai multe aplicaţii,
care, de asemenea, pot fi alcătuite din mai multe programe. Un exemplu de sistem
informatic complex este prezentat în Figura 2 Exemplu de sistem informatic complex.
Sistem informatic
Subsistemul contabilitatii Subsistemul productiei Subsistemul resurselor
umane Subsistemul cercetarii
Aplicatia Gestiune Aplicatia Casa Aplicatia Salarii
Program de calcul al
salariilor
Program de creare
declaratie Somaj
Program de creare
declaratie CAS

Figura 2 Exemplu de sistem informatic complex

La realizarea şi utilizarea unui sistem informatic trebuie avute în vedere
următoarele componente hard şi soft: reţele, echipamente, produse software[7].
Reţelele se pot clasifica după aria de întindere în:
- LAN (Local Area Network) – reţele mici, cu cel mult câteva sute de
calculatoare, aflate de cele mai multe ori în aceeaşi clădire, fiind direct conectate între
ele;
- MAN (Metropolitan Area Network) – reţele mari, care împânzesc oraşe întregi;
- WAN (Wide Area Network) – de mare întindere geografică, între două oraşe,
într-o ţară, pe un continent;
- PAN (Personal Area Network) – acoperă 10 metri, fiind des utilizată în birouri,
făcând posibilă comunicaţia, fie prin wireless, fie prun USB.
După accesibilitate, reţelele se pot împărţi în:
8
- reţeaua Intenet – reprezintă o colecţie de reţele interconectate la nivel global;
- reţeaua Intranet – un sit Web, sau grup de sit-uri care aparţin unei entităţi, ce pot
fi accesate, la un moment dat, numai de membrii entităţii;
- reţeaua Extranet – reprezintă o reţea intranet care este parţial accesibilă
utilizatorilor externi prin autentificare.
Echipamentele utilizate în cadrul unui sistem informatic pot fi:
- echipamente de calcul (calculatoare, staţii grafice, echipamente pentru serverele
de reţea, servere de baze de date, staţii de lucru);
- echipamente de comunicaţie (router, modem, hub, switch);
- altele (imprimanta, scaner, cititoare, etc.).
În ceea ce priveşte produse software, acestea pot fi:
- produse de bază:
- sisteme de operare pentru serverul de reţea: Unix, Windows NT,
Windows Server 2003;
- sisteme de operare pentru staţiile de lucru: Windows, Linux, Ubuntu,
Solaris;
- sisteme de gestiunea a bazelor de date: Oracle, SQL SERVER, MySQL,
Access, FoxPro, PostgreSQL;
- limbaje de programare: C, C++, C#, Java, VisualBasic, Php.
- produse – aplicaţii – reprezintă aplicaţiile ce alcătuiesc subsistemele informatice.
1.2. Clasificarea sistemelor informatice
Sisteme informatice se clasifică după mai multe criterii:
- în funcţie de domeniul de utilizare[9]:
- pentru conducerea activităţilor economico-sociale;
- pentru conducerea proceselor tehnologice;
- pentru cercetare ştiinţifică şi proiectare tehnologică;
- alte activităţi speciale.
- după aria de cuprindere[14]:
- sisteme informatice ce acoperă arii distincte în cadrul organizaţiei;
- sisteme interorganizaţionale.
- din punct de vedere al relaţiei cu alte sisteme[8]:
9
- sisteme deschise – interacţionează cu alte sisteme din acelaşi mediu;
- sisteme închise – nu interacţionează cu alte sisteme;
- după modul de organizare a datelor[9]:
- sisteme bazate pe fişiere;
- sisteme bazate pe tehnica bazelor de date;
- sisteme mixte.
- în funcţie de natura activităţilor susţinute[14]:
- sisteme destinate conducerii;
- sisteme destinate nivelului operaţional.
- după gradul de centralizare[9]:
- centralizate;
- descentralizate.
- după gradul de dispersie a resurselor[9]:
- sisteme informatce locale;
- sisteme informatice distribuite.
- după metoda folosită în analiza şi proiectarea sistemelor[9]:
- sisteme dezvoltate după metoda sistemelor;
- sisteme dezvoltate după metoda clasică a ciclului de viaţă;
- sisteme dezvoltate după metoda structurată;
- sisteme dezvoltate după metoda orientată-obiect;
- sisteme dezvoltate după metoda rapidă;
- sisteme dezvoltate după metoda echipelor mixte;
- sisteme dezvoltate după metoda prototipurilor.
1.3. Principiile proiectării şi realizării sistemelor informatice
Realizarea unei bune proiectări şi implementări a unui sistem informatic impune
respectarea unor principii şi anume[14]:
1. Abordarea globală a problemei de rezolvat. Fiind vorba de realizarea unui sistem
informatic al firmei se impune definirea mai întâi a unei soluţii globale de
informatizare, ceea ce va conduce la realizarea unei soluţii informatice integrate,
stabilirea unei structuri flexibile a sistemului informatic, precizarea priorităţilor în
realizarea componentelor sistemului informatic;
10
2. Utilizarea unei metodologii unitare în proiectarea şi realizarea sistemului informatic;
3. Aplicarea celor mai moderne soluţii şi metode de proiectare şi realizare a sistemului
informatic;
4. Structurarea sistemului informatic relativ independent de structura organizatorică
din cadrul firmei. Acest lucru va asigura pe de o parte o bună funcţionare a
sistemului chiar după desfăşurarea unor eventuale modificări organizatorice în
cadrul firmei, iar pe de altă parte posibilitatea generalizării implementării sistemului
informatic şi în cadrul altor firme cu acelaşi profil. Dacă există particularităţi
deosebite privitoare la modul de organizare a activităţii şi acest lucru are efecte
asupra fluxului informaţional şi procesului de prelucrare a datelor, sistemul
informatic va trebui să răspundă acestor particularităţi;
5. Participarea nemijlocită a viitorului beneficiar la activităţile de analiză, proiectare şi
implementare a sistemului informatic. Acest lucru asigură formularea clară a
specificaţiilor necesare proiectării şi validarea eşalonată a soluţiilor propuse de
proiectant, toate acestea asigurând, în final, un produs care să corespundă deplin
cerinţelor utilizatorului;
6. Respectarea cadrului legislativ. Fiind vorba de sisteme informatice devine
obligatorie realizarea evidenţelor în cadrul firmei, calcularea indicatorilor şi
întocmirea lucrărilor de sinteză în conformitate cu reglementările aflate în vigoare;
7. Realizarea unor sisteme informatice în concordanţă cu resursele disponibile la
utilizator;
8. Anticiparea şi controlul schimbărilor apărute la nivel tehnologic;
9. Explicitarea şi documentarea compromisurilor.
1.4. Ciclul de viaţă al unui sistem informatic
Sistemele informatice, ca orice entitate ce funcţionează în lumea reală, prezintă un
ciclu de viaţă care începe cu decizia de realizare a unui nou sistem informatic, sistem care
să corespundă mai bine noilor cerinţe ale utilizatorilor, şi se încheie cu decizia de
înlocuire a sistemului existent cu unul nou, mai performant, mai bine adaptat cerinţelor.
Încă de la început facem menţiunea că, indiferent de etapa istorică sau
metodologică, sistemele sunt abordate prin prisma ciclului lor de viaţă. Ele apar, se
dezvoltă şi pier, sau printr-un nou ciclu, se perfecţionează, dând naştere unei alte versiuni
sau chiar unui nou sistem. Sistemul informatic parcurge astfel etapele oricărui ciclu de
viaţă[15]: adolescenţa (concepere şi realizare), maturitate (implementare, exploatare,
întreţinere, dezvoltare), declin (sistem nu face faţă cerinţelor utilizatorilor, în cele mai
multe cazuri din cauza evoluţiei tehnologiei, astfel că se recurge la înlocuirea lui cu un alt
sistem informatic).
Prin parcurgerea materialelor de specialitate, se poate constata că numărul
fazelor/etapelor variază de la trei (de exemplu analiza, proiectarea, implementarea) la
peste douăzeci. Există mai multe modele ale ciclului de viaţă, multe dintre ele cunoscând
o evoluţie în timp. Numărul, numele, chiar şi înlănţuirea fazelor diferă de la model, la
model, însă încercând a se face o sinteză, se pot reţine următoarele faze ca fiind comune
diferitelor abordări[15]:
11
1. Definirea cerinţelor utilizatorilor. În cadrul acestei faze sunt stabilite
obiectivele ce doresc a fi atinse de către sistemul informatic. Toate aceste obiective
trebuiesc a fi atinse prin respectarea anumitor restricţii, criterii de securitate şi perfomanţă
ce se impun în cazul noului sistem. Aceste cerinţe sunt definite astfel încât să poată fi
înţelese atât de către viitorii utilizatori, cât şi de către echipele de proiectare şi
implementare.
2. Specificaţia cerinţelor sistemului. În această etapă are loc o prezentare
detaliată a rezultatelor pe care sistemul informatic urmează să le asigure. Se va evidenţia
ce anume trebuie să facă sistemul şi nu cum se va realiza acest lucru. Această etapă este
un răspuns la specificaţia dorinţelor utilizatorilor, fiind utilizată în faza de proiectare a
sistemului.
3. Specificaţia cerinţelor software. În acest moment se evidenţiază ce urmează
să facă produsul software şi restricţiile sub care funcţionalitatea sa urmează să fie
asigurată. Se realizează folosind metode de analiză a cerinţelor formulate în fazele
anterioare şi eventual a instrumentelor de tip CASE (Computer Aided Software
Engineering)
4. Proiectarea generală. În cadrul acestei etape se definesc soluţii cadru,
conceptuale cu privire la viitorul sistem informatic. Tot în această etapă are loc
elaborarea arhitecturii generale a sistemului.
5. Proiectarea de detaliu. În această fază se rafinează soluţiile cadru definite în
faza anterioară, urmărindu-se definirea soluţiei finale a sistemului informatic. Analiza şi
proiectarea sunt considerate faze cheie în realizarea unui proiect software, ele acoperind
în jur de 40% din timpul necesar realizării proiectului respectiv.
6. Realizarea componentelor sistemului informatic rezultate din faza
proiectării generale, pe baza soluţiilor oferite de proiectarea de detaliu.
7. Testarea componentelor sistemului informatic. Se verifică modul de
funcţionare, modul de îndeplinire a cerinţelor şi fiabilitatea în utilizare.
8. Integrarea componentelor sistemului informatic şi testarea finală. Are loc
reuniunea componentelor în cadrul unui produs final şi verificarea funcţionării lui în
ansamblu.
9. Implementarea şi testarea produsului final la beneficiar. În acest moment,
în funcţie de rezultatele acestei etape ar putea avea loc acceptarea sau refuzul, de către
beneficiar, a sistemului informatic.
10. Exploatarea şi întreţinerea sistemului. Se referă la utilizarea curentă a
sistemului informatic şi întreţinerea acestuia.
11. Dezvoltarea sistemului informatic. Realizarea şi integrarea de noi
componente care să îmbunătăţească şi/sau să dezvolte funcţionalitatea şi performanţele
sistemului.
În diferite surse bibliografice din literatura de specialitate aceste etape sunt reunite
în faze. În Tabel 2, avem prezentate şi alte abordări în ceea ce priveşte ciclul de viaţă a
unui sistem informatic.
12
Tabel 2 Diferite abordări în ceea ce priveşte ciclul de viaţă a sistemului informatic
Ciclul de viaţă al unui
sistem informatic(1)
Ciclul de viaţă al unui
sistem informatic(2)
Ciclul de viaţă al unui sistem
informatic inspirat din
managementul proiectului[9]
1. Identificarea şi
selectarea
proiectului Micro
2. Iniţierea şi analiza
planificarea
proiectului
1. Analiza sistemului existent
şi definirea diferitelor
categorii de cerinţe
3. Analiza
1. Definirea cerinţelor
utilizatorilor
2. Specificaţia cerinţelor
sistemului
3. Specificaţia cerinţelor
software
4. Proiectarea generală 2. Proiectarea generală 4. Proiectarea logică
5. Proiectarea de detaliu 3. Proiectarea de detaliu 5. Proiectarea fizică
6. Realizarea
componentelor
sistemului informatic
4. Realizarea sistemului
informatic
6. Implementarea
7. Testarea
componentelor
sistemului informatic
8. Integrarea
componentelor
sistemului informatic şi
testarea finală
9. Implementarea şi
testarea produsului final
la beneficiar
5. Instalarea sistemului
informatic la beneficiar
10. Exploatarea şi
întreţinerea sistemului
6. Exploatarea şi întreţinerea
sistemului 7. Întreţinerea
11. Dezvoltarea
sistemului informatic
7. Dezvoltarea sistemului
informatic
8. Dezvoltarea sistemului
informatic
Teste rezolvate
1. Subsistemelor organizaţiilor sunt:
a. Decizional, extern, operativ, informaţional
b. Informatic, decizional, informaţional, operativ
c. Informaţional, decizional, operativ A
d. Operativ, informatic, decizional
13
2. Care din următoarele elemente nu sunt considerate componente ale sistemului
informatic:
a. Echipamentele hardware
b. Tehnicile de obţinere a datelor
c. Conducerea organizaţiei A
d. Personalul specializat
3. Access este un:
a. Sistem de operare
b. Sistem de gestiune a bazelor de date A
c. Limbaj de programare
d. Produs – aplicaţie
4. În proiectarea şi realizarea sistemelor informatice nu este recomandat:
a. Să se utilizeze o metodologie unitară în toate fazele parcurse
b. Să se aplice cele mai moderne soluţii şi metode existente
c. Să se ţină cont de structura organizatorică din cadrul firmei A
d. Să se respecte cadrul legislativ
Întrebări
1. Care este definiţia unui sistem?
2. Care sunt caracteristicile activităţilor unui proiect?
3. Cum se clasifică reţelele după aria de întindere?
4. Ce reprezintă un router?
5. Enumeraţi etapele din ciclul de viaţă a unui sistem informatic.
14
2. Identificarea, selectarea, iniţierea şi planificarea
realizării unui sistem informatic
2.1. Identificarea şi selectarea proiectului
Identificarea şi selectarea proiectului reprezintă, conform modelului inspirat din
managementul proiectelor, prima etapă din ciclul de viaţă a sistemelor informatice.
Fiecare etapă din ciclul sistemului informatic se împarte într-un număr de
activităţi. Identificarea şi selecţia proiectelor înseamnă poate fi împărţită în:
- identificarea tuturor sistemelor informatice ce pot fi dezvoltate la un moment
dat;
- clasificarea şi ierarhizarea acestora în scopul selecţiei celor care vor fi
implementate;
- selecţia propriu-zisă.
2.1.1. Identificarea potenţialelor proiecte de dezvoltare în vederea
clasificării şi ierarhizării acestora
Identificare proiectului reprezintă punctul de plecare al oricărui proiect şi constă
în parcurgerea a 4 etape iniţiale:
- analiza tuturor problemelor ce ar putea fi rezolvate;
- analiza părţilor interesate în rezolvarea anumitor proiecte;
- analiza obiectivelor ce se doresc a fi atinse prin soluţionarea proiectului;
- analiza strategiilor organizaţiei.
Prin etapa de analiză a tuturor problemelor ce ar putea fi rezolvate se încearcă o
identificarea a acestora. Acest proces de analiză trebuie să conducã la ierarhizare a
problemelor şi selecţia acelei probleme, a cărei rezolvare este percepută ca fiind cea mai
importantă şi a cărei rezolvare va avea impact favorabil asupra beneficiarului. În analiza
acestor probleme vor fi identificate cauzele, dimensiunile şi efectele ce pot fi produse de
către acestea, precum şi corelaţiile acestor probleme cu alte posibile probleme ale
beneficiarului.
Odată detectată şi analizată problema ce se doreşte a fi rezolvată, se va trece la
identificarea părţilor interesate de soluţionarea problemei respective, realizându-se în
acest mod o listă a personajelor relevante care ar obţine un beneficiu direct sau indirect
din soluţionarea acestui proiect. Aceste persoane vor fi contactate în vederea implicării
lor în soluţionarea problemei şi se va încerca, în funcţie de complexitatea problemei,
construirea de parteneriate cu aceştia în vederea realizării şi implementării proiectului.
În faza de analiză a obiectivelor ce se doresc a fi atinse prin soluţionarea
problemei se realizează o reîntoarcere la analiza problemei cheie, pe marginea acesteia
15
generându-se ipoteze, alternative de soluţionare şi se stabilesc rezultatele ce se doresc a fi
atinse, toate acestea fiind sintetizate ulterior într-un set de obiective.
Ultimul pas al acestui proces de identificare presupune analiza compatibilităţii
proiectului cu strategia generală de acţiune a beneficiarului şi generarea de soluţii
strategice şi metodologice de atingere a obiectivelor proiectului, ca parte a strategiei
generale a beneficiarului.
În parcurgerea acestor paşi se poate apela la o serie de metode şi instrumente de
structurare a gândirii şi viziunii în ceea ce priveşte proiectul, dintre ele, cele mai
importante două fiind Arborele problemelor şi Matricea Cadru Logic.
Figura 3 Arbore problemă
2.1.2. Selectarea proiectului
După parcurgerea fazelor ce ţin de identificarea proiectelor ce ar putea fi
dezvoltate şi realizarea unei ierarhizări a acestora în funcţie de rezultatele ce se pot obţine
prin implementarea lor se recurge la alegerea acelui proiect ce atinge cât mai multe din
obiective pe termen scurt, mediu şi lung al organizaţiei.
Pentru aprobarea oricărui proiect trebuie, ca într-o prima etapă, să existe nevoile
identificate. Această identificare nu este uşoară pentru că, în general, nu putem specifica
o necesitate ştiinţifică decât printr-o aproximare a rezultatului dorit. Urmează apoi
compararea nevoilor identificate cu preţurile de cost estimate, obiectivul fiind justificarea
investiţiei. Mai este necesar ca proiectul să fie realizabil din punct de vedere tehnic.
Întrebarea este dacă tehnologia actuală permite realizarea acestuia, iar în cazul în care
există aceste tehnologii, dacă sunt accesibile, ţinând cont de cunoştinţe, competenţe,
bugete, resurse umane şi materiale.
2.2. Iniţierea şi planificarea proiectelor
Pentru realizarea acestei faze este nevoie de comunicarea efectivă între toate
părţile implicate în proiect: analişti, programatori, clienţi, utilizatori, etc.
16
2.2.1. Iniţierea proiectului
Din momentul selecţiei unui anumit proiect se trece la faza de iniţiere, ceea ce
presupune desfăşurarea unei activităţi laborioase prestate de o persoană cu calităţi
speciale, numită manager de proiect. Managerul de proiect trebuie să fie o persoană care
să fie capabilă să jongleze cu elemente cum sunt:
- schimbările tehnologice apărute;
- ciclul de viaţă a sistemului informatic;
- clienţi, utilizatori şi furnizori de echipamente sau servicii;
- resursele umane interne organizaţiei implicate în proiect;
- metodologii şi instrumente de lucru diferite;
- restricţii de timp, de spaţiu, de cost, de resurse, etc.;
- comunicare.
Activităţile efectuate în faza iniţierii proiectului sunt :
- stabilirea echipei de iniţiere a proiectului;
- stabilirea bunelor relaţii cu beneficiarii;
- stabilirea planului iniţierii proiectului;
- stabilirea regulilor manageriale;
- stabilirea cadrului de desfăşurare a proiectului.
2.2.2. Planificarea proiectului
Planificarea proiectului este procesul prin care are loc definirea clară a
activităţilor şi a eforturilor necesare înfăptuirii lor în cadrul fiecărui proiect.
Tipurile de activităţi executate în cadrul planificării proiectului cuprind[9]:
- descrierea ariei de întindere, a variantelor şi fezabilităţii proiectului;
- descompunerea proiectului în activităţi uşor executabile şi controlabile;
- estimarea resurselor şi crearea unui plan al resurselor - managerul de proiect este
responsabil atât de corectitudinea alocării resurselor, cât şi de urmărirea folosirii lor cu
scopul obţinerii rezultatului convenit;
- realizarea unei prime planificări calendaristice;
- realizarea unui plan al comunicărilor;
- determinarea standardelor şi procedurilor proiectului - descrie în mod exact
acţiunile ce trebuie întreprinse în situaţii specifice şi reprezintă modul în care politicile
sunt implementate în mod frecvent. Procedurile standard reprezintă instrucţiuni detaliate
menite să îl orienteze pe angajatul care trebuie să îndeplinească o sarcină şi să asigure
abordarea coerentă în cadrul organizaţiei a situaţiilor recurente;
- identificarea şi evaluarea riscului;
- crearea unui buget preliminar;
- întocmirea rapoartelor de activitate;
- definitivarea planului de bază a proiectului.
17
2.2.3. Studiile de fezabilitate
Elaborarea unui sistem informatic poate costa milioane de dolari şi se poate
realiza pe parcursul a trei până la şase ani pentru a fi complet. Din aceste motive, este
normal ca factorii de conducere să demareze proiectarea unui nou sistem după ce se
efectuează studii de fezabilitate[7].
Un studiu de fezabilitate are rolul de a asigura informaţiile obiective necesare
pentru a cunoaşte dacă un proiect poate fi demarat sau nu, sau dacă un proiect deja
început mai poate fi continuat. Proporţiile şi durata studiilor de fezabilitate variază, în
funcţie de mărimea şi natura sistemului implementat. În cazul sistemelor bazate pe
calculatoare mari, studiul are cu totul alte dimensiunifaţă de varianta utilizării
microcalculatoarelor[9].
Fezabilitatea proiectului poate fi studiată în orice fază în orice fază a elaborării
lui, dar studiile, de regulă, se efectuează în momente certe. Când este propus un proiect,
se efectuează un studiu preliminar de fezabilitate pentru a se stabili dacă proiectul atinge
obiectivele propuse de unitate. Analiza, în prima ei fază, poate fi oricât de subiectivă,
întrucât proiectul nu este reprezentat cu lux de amănunte. Însă, îndată ce se obţine o
situaţie mai clară despre sistem, despre natura problemei de rezolvat, precum şi despre
doleanţele utilizatorilor, măsurarea preliminară a fezabilităţii poate fi determinată odată
cu faza de analiză a sistemului. Când proiectanţii oferă două sau trei variante de elaborare
a sistemului, numai studiile de fezabilitate o pot scoate în relief pe cea optimă[7].
După ce a avut loc proiectarea primară a sistemului, pot fi determinate în detaliu
elementele de cost ale proiectării, implementării şi exploatării. Este ultima şansă a
unităţilor de a mai putea renunţa la sistem, înaintea implementării lui[7].
Pe parcurs, odată cu progresul înregistrat în dezvoltarea sistemului informatic, se
obţin informaţii din ce în ce mai certe, oferindu-se posibilitatea unor analize de
fezabilitate mult mai concludente, ceea ce atrage studierea fezabilităţii în diverse faze ale
ciclului de viaţă al sistemelor. De fiecare dată, studiile de fezabilitate trebuie să aibă la
bază o foarte bună documentaţie. Aceasta va conţine[9]:
- Definirea problemei ( o scurtă descriere a proiectului şi explicarea a ceea ce-şi
propune el să realizeze);
- Descrierea cerinţelor sistemului;
- Descrierea soluţiilor sistemului propus;
- Explicaţia critică a motivării studiului întreprins;
- Cuantificarea tuturor costurilor materiale şi beneficiilor aferente;
- O listă a costurilor şi beneficiilor necuantificabile.
2.2.4. Tehnici de reprezentare a planurilor şi programarea
calendaristică
Managerul proiectului dispune de o mare varietate de tehnici pentru reprezentarea
şi descrierea planurilor proiectelor. Documentaţia planificării poate fi alcătuită din[7]:
- rapoarte grafice - cele mai folosite;
18
- rapoarte sub formă de text.
O diagrama Gantt este o modalitate de reprezentare grafică a proiectului. Cu
ajutorul barelor orizontale sunt prezentate activităţile planificate. Lungimea barelor este
proporţională cu timpul alocat activităţilor reprezentate. Se pot folosi diferite culori,
umbre sau forme pentru a scoate în relief anumite activităţi. Ceea ce s-a planificat şi
realizat, de asemenea, pot fi evidenţiate prin bare paralele de culori, forme sau umbre
diferite. Diagramele Gantt nu indică ordinea activităţilor (precedenţa lor), ci indică data
începerii şi pe cea a finalizării. Se recomandă pentru descrierea proiectelor simple sau a
unor componente ale proiectelor mari, sau a activităţilor prestate doar de o singură
persoană, precum şi pentru monitorizarea modului în care se efectuează activităţile în
comparaţie cu cele planificate (ca dată)[7].
Întrebări
1. Care sunt principalele tipurile de activităţi executate în cadrul planificării
proiectului?
2. Care sunt activităţile efectuate în faza iniţierii proiectului?
19
3. Analiza sistemului existent şi definirea cerinţelor
noului sistem
3.1. Studiul sistemului informaţional existent
Prin sistem existent se înţelege realitatea obiectivă din organizaţia pentru care
urmează a se realiza sistemul informatic solicitat printr-o comandă numită cererea
beneficiarului[7].
Analiza sistemului existent şi definirea cerinţelor noului sistem este prima etapă
din ciclul de viaţă al dezvoltării sistemelor informatice, etapă prin care se determină
modul în care funcţionează sistemul informaţional curent şi se evaluează ceea ce ar dori
utilizatorii să realizeze noul sistem. Studiul şi analiza sistemului existent are ca obiectiv
principal stabilirea cerinţelor informaţionale ale conducerii în vederea realizării unui
sistem informatic[7].
Studiul sistemului existent cuprinde un grup de activităţi care urmăresc
cunoaşterea performantelor tehnico-funcţionale ale sistemului informaţional, atât în
ansamblul său, cât şi pentru elementele de structura ale acestuia, a cerinţelor
informaţionale ale conducerii, cunoaşterea lipsurilor şi restricţiilor pe care le prezintă
sistemul existent faţă de aceste cerinţe. De modul de realizare a acestor activităţi depinde
întregul proces de realizare a sistemului informatic[2].
Studiul sistemului existent constă în[2]:
- definirea caracteristicilor generale ale sistemului economic;
- studiul activităţilor de bază desfăşurate în sistem;
- studiul sistemului de conducere;
- studiul sistemului informaţional;
- identificarea metodelor şi mijloacelor tehnice utilizate pentru prelucrarea
datelor.
a. Definirea caracteristicilor generale ale sistemului economic implică :
- cunoaşterea profilului, obiectivelor agentului economic;
- cunoaşterea locului în sfera serviciilor şi sfera producţiei;
- cunoaşterea relaţiilor de cooperare cu alţi agenţi economici;
- cunoaşterea specificului activităţii de bază ( producţie, servicii);
- cunoaşterea nivelului tehnic;
- cunoaşterea principalilor indicatori economici şi evoluţia lor;
- dezvoltarea, modernizarea etc.
b. Studiul activităţilor desfăşurate în sistemul economic, modul de realizare a
funcţiunilor unităţii economice se face pe baza statutului de funcţionare a societăţii şi
anume se studiază[2]:
- activităţile şi sarcinile din cadrul acestor funcţiuni;
20
- atribuţiile ce revin compartimentelor;
- modul de realizare a activităţilor funcţionale din cadrul unităţii economice.
c. Studiul sistemului de conducere se referă la[2]:
- identificarea caracteristicilor sistemului de conducere existent;
- sistemul de indicatori cantitativi şi valorici;
- organizarea conducerii;
- caracteristicile rezultate din statutul de funcţionare a societăţii, tipuri de decizii,
modul de lucru a deciziilor.
d. Studiul sistemului informaţional presupune[2]:
- elaborarea schemei fluxului informaţional global (cu punerea în evidenţă a
principalelor activităţi şi a legăturilor statice şi dinamice dintre acestea);
- estimarea cantitativă şi calitativă a informaţiilor de intrare-ieşire, modul de
culegere şi prelucrare;
- identificarea principalilor algoritmi, regulilor de calcul şi a punctelor si regulilor
de control;
- cunoaşterea principalelor restricţii ale sistemului informaţional;
- situaţia raţionalizării fluxurilor şi a documentelor din unitatea economica, studii
elaborate, stadiul lor de implementare;
- sistemul de codificare utilizat, restricţii;
- performanţele şi limitele sistemului informaţional existent.
e. Identificarea metodelor şi mijloacelor tehnice[2] utilizate pentru prelucrarea
datelor în cadrul sistemului informaţional existent se face evidenţiind: mijloacele tehnice
existente în dotarea unităţii economice (modul de utilizare, cheltuielile de exploatare,
personalul implicat, performante); existenţa unor aplicaţii proiectate şi/sau implementate.
3.2. Ciclul prelucrării datelor pentru sistemul informatic
Operaţiunile care se execută asupra datelor, din momentul apariţiei lor, pentru a
genera informaţii semnificative şi relevante sunt referite la un loc prin noţiunea de ciclul
prelucrării datelor. Ciclul cuprinde cinci faze: culegerea datelor, pregătirea datelor,
prelucrarea datelor, întreţinerea fişierelor şi obţinerea informaţiilor de ieşire[7].
Faza de culegere a datelor cuprinde două activităţi fundamentale[9]:
- observarea mediului care generează datele, fie printr-un observator uman, fie
prin diverse echipamente;
- înregistrarea datelor, fie prin scrierea lor în documentele sursă, fie prin captarea
lor sub diferite forme cu ajutorul unor echipamente speciale.
Pregătirea datelor constă într-un număr de operaţii executate asupra datelor
pentru a facilita prelucrarea lor ulterioară. Ele sunt[9]:
21
- clasificarea datelor, care implică atribuirea de coduri de identificare (simbol
cont, cod secţie, etc.), astfel încât datele să fie incluse în submulţimile corespunzătoare;
- gruparea datelor, adică acumularea intrărilor similare, pentru a fi prelucrate în
grup;
- verificarea datelor cuprinde o mare varietate de proceduri pentru controlul
corectitudinii datelor, înainte ca ele să fie prelucrate;
- sortarea datelor, prin care grupurile de date sunt aranjate în loturi de înregistrări,
după criterii de ordonare numerică, alfabetică, alfanumerică sau de timp;
- cuplarea a două sau mai multe loturi de înregistrări într-unul singur;
- transmiterea datelor de la un punct la altul;
- transcrierea datelor dintr-o formă în alta, astfel încât să se efectueze trecerea de
la scrierea de mână la cea tipizată sau de la documentele scrise la mediile specifice.
Pregătirea datelor este o activitate realizată în toate tipurile de sisteme
informaţionale, dar capătă o semnificaţie deosebită în sistemele de prelucrare automată a
datelor; partea informatizată a acestora fiind cunoscută ca sistem/subsistem informatic.
Prelucrarea datelor, poate să includă activităţi, cum sunt[9]:
- calculaţiile cuprind unele forme de tratare matematică a datelor;
- compararea supune unei examinări simultane două sau mai multe tipuri de date
între care există o legătură logică (ex. soldul iniţial şi cel final);
- sintetizarea este o activitate importantă prin care se comasează informaţiile;
- filtrarea este o altă operaţiune prin care se extrag datele ce vor fi supuse
prelucrărilor următoare;
- restaurarea, prin care sunt aduse datele din memorie într-o formă accesibilă
omului, pentru prelucrarea umană în continuare, sau într-o formă prelucrabilă tot pe
calculator.
În faza de întreţinere a fişierelor există mai multe activităţi, dintre care
amintim[9]:
- memorarea (stocarea) datelor în vederea utilizării lor viitoare;
- actualizarea datelor memorate astfel încât să surprindă cele mai recente
evenimente;
- indexarea datelor pentru a înlesni o uşoară regăsire a lor;
- protecţia datelor memorate, care cuprinde o mare varietate de proceduri şi
tehnici pentru prevenirea distrugerii lor sau a accesului neautorizat.
Ultima fază a ciclului de prelucrare a datelor este obţinerea informaţiilor de
ieşire[9]. Informaţiile de ieşire pot fi regăsite în una din următoarele trei forme:
documente, rapoarte ori răspunsuri la întrebări.Termenul ieşiri le cuprinde pe toate .
De cele mai multe ori, datele nu parcurg toate activităţile, iar unele dintre ele pot
chiar să nu treacă prin cele cinci faze.
22
3.3. Determinarea cerinţelor sistemului
Determinarea cerinţelor sistemului este activitate esenţială în aflarea situaţiei
existente şi a ceea ce se doreşte în viitor. Rezultatul activităţii de determinare a cerinţelor
sistemului se concretizează în diferite forme ale informaţiilor colectate, cum sunt copii
ale interviurilor, însemnări efectuate în timpul observării şi analizei documentelor,
interpretări ale răspunsurilor la chestionare, seturi de formulare, rapoarte, descrieri ale
posturilor de lucru ş.a., precum şi rezultate ale prelucrărilor efectuate de calculator, cum
ar fi prototipurile[2].
Rezultatele prezentate după această activitate pot fi rezumate astfel[2]:
1. Informaţii obţinute în urma conversaţiilor cu utilizatorii sau prin observarea
activităţilor prestate de aceştia: copii sau sinteze ale interviurilor, răspunsurile la
chestionare sau interpretări ale acestora, însemnări şi rezultate din observarea
activităţilor, procese verbale ale şedinţelor ce au avut loc în acest scop;
2. Informaţii scrise care există în unitate: misiunea şi strategia afacerii, exemplare
ale formularelor, rapoartelor şi machetelor de ecrane, manuale ale procedurilor, descrieri
ale posturilor de lucru, manuale de instruire, scheme de sisteme şi documentaţia
sistemului existent, rapoartele consultanţilor;
3. Informaţii obţinute cu ajutorul calculatorului: rezultate ale sesiunilor JAD,
copii ale fişierelor sesiunilor grupului de sprijinire a sistemului, conţinutul depozitelor şi
rapoartele existente în CASE, ecrane şi rapoarte rezultate din prototipurile sistemului, ş.a.
3.3.1. Metode tradiţionale utilizate în analiza şi determinarea
cerinţelor sistemului
Analiza sistemului informaţional-decizional fiind, în general, axată pe sistemul
obiect, metodele utilizate sunt în general comune cu cele ale analizei economice[9].
Metodele utilizate frecvent în analiza sistemului existent sunt[7]:
- Interviul;
- Chestionarul.
Interviul este o metodă foarte răspândită pentru culegerea informaţiilor din
sistemul informaţional. Utilizatorii acestei metode sunt în general analiştii care nu sunt
familiarizaţi cu unitatea studiată şi cu problemele ei. Prezintă avantajul că lasă foarte
multă libertate creativa analistului în construirea şi desfăşurarea lui[9]. În alegerea
persoanelor de intervievat trebuie avute în vedere următoarele constatări[1]:
- persoanele care ocupă poziţii medii în ierarhia structurii organizatorice
furnizează informaţiile cele mai apropiate de realitate;
- colectarea de informaţii corecte necesită intervievarea atât a personalului de
conducere, cât şi a celui de execuţie;
- în prealabil trebuie verificată competenţa subiecţilor intervievaţi;
- lipsa unei atitudini critice poate să denote reţineri în exprimarea ideilor.
23
Se vor efectua interviuri la nivelul conducerii şi interviuri la nivelul posturilor de
lucru. Rezultatul interviului este consemnat în raportul de interviu care trebuie semnat de
către persoanele intervievate.
Chestionarul poate fi utilizat atât de către analiştii începători, cât şi de către cei
avansaţi, familiarizaţi sau nu cu problemele informaţionale-decizionale ale unităţii. Prin
utilizarea lui dispare “filtrul de informaţii” care este analistul iar cel care furnizează
informaţii are posibilitatea să se concentreze mai bine asupra răspunsurilor. Utilizând
această metodă, participă un număr mare de “furnizori de informaţii”[7].
Limitele chestionarului constau în faptul că este o metodă de verificare a unor
cunoştinţe prealabile, fapt ce implică cunoaşterea prealabilă a domeniului. Această
metodă necesită timp relativ îndelungat pentru întocmirea chestionarului precum şi de
culegere şi prelucrare a răspunsurilor. Chestionarul nu are o arie largă de utilizare[9].
3.3.2. Metode moderne de analiză şi determinare a cerinţelor
sistemului
Ca efect al tendinţelor de mărire a timpului de analiză a sistemelor existente, în
ultimii ani, s-a efectuat trecerea spre analiza mai puţin pronunţată a sistemelor ce
urmează a se realiza. Tehnicile moderne, JAD şi prototipizarea, preiau tot mai puţine
elemente din sistemele existente, ca urmare a analizei efectuate. Altele mai radicale
renunţă aproape total la analiza sistemului existent, este cazul proceselor controlate prin
RAD, care apelează la JAD, prototipizare şi alte instrumente de tip CASE[2].
Joint Application Design(JAD)
Spre sfârşitul anilor 1970, specialiştii în realizarea de sisteme de la IBM au
elaborat un nou proces de culegere a cerinţelor informaţionale ale sistemelor şi de
revizuire a proiectelor sistemelor, numindu-se JAD[2].
Ideea principală a lui JAD o constituie punerea laolaltă a tuturor forţelor interesate
în dezvoltarea sistemelor: utilizatori-cheie, managerii şi analiştii de sistem implicaţi în
analiza sistemului curent. Din acest punct de vedere JAD este similar interviului la nivel
de grup. Totuşi în sesiunea JAD se urmăreşte o anumită secvenţă de derulare a
activităţilor, pe baza unor roluri bine stabilite[7].
Prototipizarea şi determinarea cerinţelor sistemelor
Prototipizarea este un proces interactiv prin care analiştii şi utilizatorii pun în
discuţie o versiune rudimentară a unui sistem informaţional, care va fi într-o continuă
schimbare, în funcţie de reacţia utilizatorilor. Prototipizarea renunţă la ciclul de viaţă al
dezvoltării sistemelor sau la creşterea rolului său[2].
Pentru culegerea informaţiilor despre cerinţele utilizatorilor încă se apelează la
interviuri, dar prin prototipizare, operaţiunea va fi mai simplă şi va solicita un timp mai
scurt. Prototipul este văzut şi testat de utilizator, având posibilitatea să precizeze ce ar
mai dori, dar şi să-şi genereze această formă nouă, cu ajutorul specialiştilor[2].
Prototipizarea este facilitată de câteva limbaje sau produse program, inclusiv
instrumentele de tip CASE.
Prototipizarea este foarte utilă în determinarea cerinţelor sistemului când[2]:
24
- cerinţele utilizatorului nu sunt prea clar formulate sau bine înţelese;
- unul sau mai mulţi utilizatori sau susţinători sunt implicaţi în sistem;
- anumite mijloace de lucru (formulare şi rapoarte predefinite).
Prototipizarea generează şi deficienţe, cum ar fi[2]:
- tendinţa de evitare a unui cadru formal de elaborare a documentaţiei privind
cerinţele sistemului, ceea ce va îngreuna în viitor orice control;
- fiind conceput de un număr mic de utilizatori va fi probabil respins de viitorii
utilizatori;
- fiind conceput izolat este puţin probabil ca el să fie integrat în sistemul existent;
- nerespectându-se etapele ciclului de viaţă al dezvoltării sistemelor pot fi omise
aspecte esenţiale, cum ar fi securitatea, controlul datelor introduse şi standardizarea la
nivel de sistem.
Paşii prototipizării sunt[2]:
- Identificarea cerinţelor principale ale sistemului;
- Realizarea prototipului iniţial;
- Proces iterativ de adaptare a sistemului la cerinţele utilizatorului;
- Folosirea sistemului aprobat de utilizatori.
După determinarea cerinţelor sistemului urmează structurarea acestora prin
utilizarea unor instrumente specifice de modelare logică.
3.4. Cazuri de utilizare
Unul dintre aspectele importante în înţelegerea şi definirea cerinţelor unui sistem
este acela al interacţiunii dintre sistem şi utilizatori sau alte componente externe.
Modelul cazurilor de utilizare (“Use cases”) a fost introdus de Jacobson în 1992.
El a fost adoptat într-o măsură remarcabilă, devenind un instrument folosit în mod
frecvent în specificarea cerinţelor aferente sistemelor informatice[6].
Modelul cazurilor de utilizare include[6]:
• actorii,
• scenarii,
• cazurile de utilizare
• diagramele de cazuri de utilizare.
Un actor este un rol pe care o entitate externă îl joacă în raport cu un sistem[6].
Actorii se determină observând utilizatorii direcţi ai sistemului, cei care sunt
responsabili de exploatarea sau de interogarea sa. Aceeaşi persoană fizică poate juca rolul
mai multor actori (de exemplu vânzator şi client). Mai multe persoane pot să joace acelaşi
rol, şi deci sa acţioneze ca acelaşi actor. Un actor poate fi de asemenea un echipament
extern sistemului sau un alt sistem[6].
25
Actorii se reprezintă sub forma unor mici personaje care declanşează cazuri de
utilizare. De exemplu[6]:
Figura 4 Caz de utilizare
Linia care conectează un actor de un caz de utilizare se numeşte legatură de
comunicare[6].
Determinarea actorilor permite precizarea limitelor sistemului într-o manieră
progresivă: vagi la început, ele se precizează pe masura elaborării diferitelor cazuri de
utilizare. Această activitate de delimitare este extrem de importantă. Ea permite stabilirea
a ceea ce trebuie sa realizeze viitorul sistem, ceea ce face parte din sistemul de dezvoltat
şi ceea ce nu face parte din el[6].
Cazurile de utilizare sunt abstracţii ale dialogului între actori şi sistem. Ele
descriu interacţiuni potenţiale fără a intra în detalii ale fiecărui scenariu[6].
Un scenariu este o secvenţă de paşi care descrie o posibilă interacţiune dintre un
sistem şi un actor[6].
Să considerăm un sistem de gestiune electronică a cărţilor din mai multe
biblioteci, de exemplu din întreaga ţară. Sistemul urmează să fie utilizat de două categorii
de utilizatori: bibliotecarii şi abonaţii. Bibliotecarii accesează sistemul pentru a înregistra
abonaţi şi cărţi noi sau pentru a elimina cărţi din evidenţă. Abonaţii pot cere informaţii
despre diferite cărţi şi pot cere împrumutarea unei cărţi. Sistemul trebuie să păstreze
evidenţa abonaţilor, a cărţilor împrumutate de fiecare abonat şi alte informaţii. Deoarece
sistemul realizează o gestiune centralizată, pentru accesul său se propune o interfaţă
Web[6].În acest exemplu, actorii sunt: abonatul şi bibliotecarul[6].
Cazurile de utilizare ar putea fi[6]:
Figura 5 Caz de utilizare Imprumut
Figura 6 Caz de utilizare Inregistrare abonat
26
Scenarii de “Imprumut”[6]:
(1)
1. Un utilizator care doreşte să împrumute o carte completează rubricile afectate
numelui şi prenumelui său, apoi apasă butonul “Submit”.
2. Sistemul preia datele şi verifică dacă utilizatorul este înregistrat ca abonat.
3. Utilizatorul primeşte mesajul: „Nu sunteţi înregistrat ca abonat. Efectuaţi
procedura de înregistrare”.
(2)
1. Un utilizator care doreşte să împrumute o carte completează rubricile afectate
numelui şi prenumelui său, apoi apasă butonul “Submit”.
2. Sistemul preia datele şi verifică dacă utilizatorul este înregistrat ca abonat.
3. Utilizatorul primeşte mesajul: „Aţi depăşit numărul maxim de cărţi
împrumutate. Restituiţi o parte dintre ele”.
(3)
1. Un utilizator care doreşte să împrumute o carte completează rubricile afectate
numelui şi prenumelui său, apoi apasă butonul “Submit”.
2. Sistemul preia datele şi verifică dacă utilizatorul este înregistrat ca abonat.
3. Sistemul afisează următoarea pagină, conţinând formularul de împrumut.
4. Abonatul completează formularul de împrumut, cu titlul cărtii, numele şi
prenumele autorului şi codul ISBN al cărţii apoi apasă butonul “Submit”.
5. Sistemul preia datele şi caută cartea.
6. Utilizatorul primeşte mesajul: „Cartea nu există în bibliotecile noastre”.
Un caz de utilizare descrie un set de scenarii corelate, de exemplu, toate scenariile
de acces la sistem în scopul împrumutului unei cărţi[6].
Formatul descrierii constă dintr-o secvenţă tipică de paşi şi alternativele, ca
variante ale secvenţei tipice. Exemplu[6]:
Cazul de utilizare :”Imprumut”
1. Un utilizator care doreşte să împrumute o carte completează rubricile afectate
numelui şi prenumelui său, apoi apasă butonul “Submit”.
2. Sistemul preia datele şi verifică dacă utilizatorul este înregistrat ca abonat.
3. Sistemul afişează următoarea pagină, conţinând formularul de împrumut.
4. Abonatul completează formularul de împrumut, cu titlul cărţii, numele şi
prenumele autorului şi codul ISBN al cărţii apoi apasă butonul “Submit”.
5. Sistemul preia datele şi caută cartea.
6. Sistemul înregistrează împrumutul.
7. Sistemul afisează datele necesare împrumutului.
Alternativa “Acces ne-autorizat”:
27
La pasul 2: Utilizatorul nu este înregistrat ca abonat şi atunci sesiunea este
încheiată de sistem cu un mesaj în care utilizatorul este invitat să se inregistreze.
Alternativa “Imprumutul nu este posibil”
La pasul 5:
5a) Cartea nu este găsită. Sistemul afişeaza un mesaj şi sesiunea este încheiată.
5b) Cartea este găsită, dar abonatul a împrumutat deja numărul maxim admis de
cărţi. Sistemul afişează un mesaj şi încheie sesiunea.
UML (Unified Modeling Language) admite variaţii în privinţa descrierii cazurilor
de utilizare. De exemplu, o descriere mai exactă a cazului de utilizare prezentat anterior
este[6]:
Tabel 3 Descrierea cazului de utlizare Imprumut
Actori: Abonat
Scop: Împrumutul unei cărţi
Descriere generală: Un abonat accesează pagina Web a
sistemului de gestiune electronică a
cărţilor din bibliotecile existente în ţară.
El işi introduce identitatea şi datele de
identificare ale cărţii pe care doreşte să o
împrumute. Sistemul validează identitatea
abonatului şi caută cartea. Dacă acea
carte există şi abonatul are dreptul să
obţină un nou împrumut atunci sistemul
autorizează împrumutul.
Pre-condiţie: Dacă este necesar, abonatul tebuie să
execute mai întâi procedura de acces la
sistem (log-in).
Post-conditie: În baza de date a sistemului există o
înregistrare a împrumutului către abonat
Cazuri de utilizare referite: Înregistrarea unui nou abonat
Urmeaza o descriere similara cu cea anterioară[6]:
1. Un utilizator care doreste sa imprumute o carte completeaza rubricile afectate
numelui si prenumelui sau apoi apasa butonul “Submit”.
2. Sistemul preia datele si verifica daca utilizatorul este inregistrat ca abonat.
Daca utilizatorul nu este inregistrat ca abonat atunci executa alternativa “Acces neautorizat”.
3. Sistemul afiseaza urmatoarea pagina, continand formularul de imprumut.
4. Abonatul completeaza formularul de imprumut, cu titlul cartii, numele si
prenumele autorului si codul ISBN al cartii apoi apasa butonul “Submit”.
5. Sistemul cauta cartea.
28
6.
5a) Daca sistemul nu gaseste cartea, se executa alternativa “Cartea nu exista”.
5b) Daca autorul are deja imprumutat numarul maxim de carti admis, se executa
alternativa “Restrictia numarului de carti imprumutate”.
7. Sistemul inregistreaza imprumutul.
8. Sistemul afiseaza utilizatorului datele necesare imprumutului.
Alternativa “Acces ne-autorizat”
1. Sistemul afiseaza un mesaj prin care invita utilizatorul sa se inregistreze ca abonat
apoi incheie sesiunea.
Alternativa “Cartea nu exista”
1. Sistemul afiseaza mesajul “Cartea solicitata nu ese inregistrata in bibliotecile noastre”,
apoi incheie sesiunea.
Analog pentru alternativa 5b.
Pre-conditia este un predicat (in cazul de fata exprimat ne-formal) care exprima conditia
care trebuie sa fie satisfacuta inainte de inceperea cazului de utilizare.
Post-conditia exprima conditia care este satisfacuta dupa executia cazului de utilizare
(conform descrierii secventei tipice!).
Un caz de utilizare este imaginea unei funcţionalităţi a sistemului, declanşată ca
răspuns la stimularea unui actor.
Descrierea unui caz de utilizare trebuie sa precizeze:
• cum si cand incepe si se termina cazul de utilizare – evenimente care marcheaza
inceputul si sfarsitul cazului;
• cand au loc interactiunile cu actorii si informatiile schimbate (comunicate intre
actori – sistem) in timpul fiecarei interaciuni;
• fluxul de baza (comportamentul de baza) si alternativele fiecarei interactiuni;
• repetarile de comportament.
Cand si cum se foloseste modelul cazurilor de utilizare?[6]
Cazurile de utilizare definesc comportarea unui sistem fara a da informatii despre
modul de realizare a comportarii. Se folosesc ca mijloc de vizualizare, specificare si
documentare a unui sistem, subsistem, parte sau element.
 In fazele initiale ale dezvoltarii, cazurile de utilizare se folosesc ca mijloc de
comunicare intre analist si client precum si experti ai domeniului, pentru determinarea
contextului sistemului si pentru desprinderea cerintelor. Ele pot fi incluse in documentele
de specificare a cerintelor utilizatorilor si a cerintelor software.
29
 Pe parcursul dezvoltarii se folosesc pentru validarea arhitecturii sistemului. Se
folosesc, de asemenea, in procesul de testare a sistemului executabil. Colectia de scenarii
pentru un caz de utilizare poate sugera o suita de cazuri de test.
Modelul cazurilor de utilizare poate include si un set de diagrame de cazuri de
utilizare.
Diagramele de cazuri de utilizare se folosesc pentru a reprezenta relatiile intre
cazurile de utilizare ce descriu un system[6].
Exista trei tipuri de relatii intre cazurile de utilizare[6]:
Figura 7 Relaţiile dintre cazurile de utilizare
 Relatia de generalizare
Are acelasi rol ca şi relaţia de generalizare între clase. Un caz de utilizare copil
mosteneste comportarea si intelesul cazului de utilizare parinte: copilul poate adauga noi
aspecte ale comportarii sau poate redefini partial comportarea parintelui.
 Relatia de includere
Un caz de utilizare poate incorpora comportarea reprezentata printr-un alt caz de
utilizare, intr-un punct specificat al sau. Cazurile de utilizare “incluse” nu pot fi folosite
independent, ci doar ca parti ale cazurilor de utilizare care le includ.
Relatia de includere se foloseste pentru a evita descrierea de mai multe ori a aceluiasi
flux de evenimente. Un astfel de flux, care apare in mai multe cazuri de utilizare, se
defineste ca un caz de utilizare separat, care factorizeaza o comportare comuna.
 Relatia de extindere
Un caz de utilizare poate extinde, in anumite conditii, comportarea reprezentata
printr-un alt caz. Cazul extins poate fi folosit si singur. El este extins numai in anumite
puncte. Relatia de extindere se foloseste[6]:
30
- pentru a modela parti ale cazurilor de utilizare pe care utilizatorii le pot vedea ca
optiuni ale comportarii sistemului; in acest caz se separa comportamentul principal de
cele optionale.
- pentru a modela sub-fluxuri de evenimente, care sunt executate numai in anumite
conditii.
Relatiile de includere si extindere favorizeaza structurarea cazurilor de utilizare
prin factorizarea comportamentului comun si separarea variantelor.
 O diagrama de cazuri de utilizare reda un set de cazuri de utilizare, actori si
relatii. In diagramele de cazuri de utilizare, actorii se reprezintă sub forma unor mici
personaje care declansează cazuri de utilizare.
 Diagramele de cazuri de utilizare pot fi utile pentru a reprezenta contextul in care
functioneaza un sistem. Contextul unui sistem cuprinde tot ceea ce este exterior
sistemului si interactioneaza cu sistemul. El defineste mediul sistemului.
 O diagrama de caz de utilizare care modeleaza contextul evidentiaza actorii care
interactioneaza cu sistemul. Un astfel de exemplu este redat in figura urmatoare[6]:
Figura 8 Sistem de validare a cartelelor de credit
 Sistemul este reprezentat printr-un dreptunghi iar numele său este scris în
interiorul dreptunghiului.
 Cazurile de utilizare şi diagramele de cazuri de utilizare pot reda comportamentul
unui sistem la diferite nivele de abstractizare.
Astfel, cazul de utilizare anterior poate fi detaliat pentru a reda participarea
diferitelor componente ale sistemului în cazul de utilizare. O astfel de detaliere apare
necesară în etapele de proiectare ale sistemului. În aceste modele actori pot fi: baze de
date, programe, componente, etc.
Un alt exemplu de diagrame de cazuri de utilizare este prezentate în Figura 9,
Figura 10, Figura 11 şi Figura 12.
31
Figura 9 Sistem de alegere a temei de licenţă (login, logout, propune proiect)
Figura 10 Sistem de alegere a temei de licenţă (alege, renunţă proiect)
Figura 11 Sistem de alegere a temei de licenţă (actori şi tipuri de relaţii)
32
Figura 12 Sistem de alegere a temei de licenţă –varianta finală
3.5. Structurarea cerinţelor sistemului
Indiferent de metodologiile folosite în realizarea unui sistem/aplicaţie, toate
apelează la operaţiunea de modelare logică a datelor şi prelucrărilor sub formă de
diagrame, diferenţele constând doar în folosirea mai pronunţată a diagramelor pentru
descrierea sistemului, încadrându-le în diagrame de context, diagrame ale fluxurilor de
date fizice şi diagrame ale fluxului de date logice. Altele apelează la combinaţii de
diagrame, tabele şi forme descriptive[9].
3.5.1. Diagrama fluxurilor de date(DFD)
Diagrama fluxului de date ale nivelului logic curent, independentă de tehnologie,
reliefează funcţiile de prelucrare a datelor executate de către sistemul informaţional
curent[7].
Diagrama de flux de date ale sistemului logic nou va prezenta circuitul datelor,
structura lor şi cerinţele funcţionale ale noului sistem[7].
33
Descrieri ale obiectelor DFD se regăsesc în aşa-zisele dicţionare ale proiectelor
sau depozitele CASE (repository)[9].
Diagramele fluxului de date DFD au ca obiectiv urmărirea modului de transfer al
datelor între procesele de prelucrare a lor, astfel de diagrame se mai numesc şi modele ale
proceselor de prelucrare, iar operaţiunea se numeşte modelarea proceselor[7].
DFD reprezintă doar una din tehnicile de analiză structurată[7].
Tehnica de redare a proceselor de prelucrare prin intermediul diagramelor
fluxurilor de date a căpătat noi accepţiuni prin încorporarea ei în instrumentele de analiză
şi proiectare cu ajutorul calculatorului, adică în instrumente CASE[9].
Înainte de a se încerca construcţia unei DFD iniţiale, este obligatoriu să se strângă
şi să se prelucreze informaţia care ne-ar ajuta să înţelegem cum sunt procesate datele în
sistemul curent. Rezultatele obţinute în urma interviurilor, chestionarelor, etc. vor ajuta,
împreună, la înţelegerea, de către analist, a tuturor proceselor. În cazul în care sistemul
trebuie să fie dezvoltat de la 0, analiştii vor realiza DFD cu ajutorul utilizatorilor.
În momentul în care informaţiilor despre sistemul curent sunt colectate, se trece la
construirea DFD pentru a evidenţia:
- informaţia care intră sau iese din sistem;
- persoanele/ alte sisteme care generează sau primesc această informaţie;
- procesele care apar în sistem şi care se ocupă cu manipularea informaţiei;
- informaţia stocată în sistem;
- limitele sistemului (ceea ce este/nu este inclus în sistem).
DFD sunt utilizate pentru:
- a discuta cu utilizatorul folosind interpretarea vizuală a proceselor în cadrul
sistemului şi pentru a clarifica ce s-a realizat până la un moment dat;
- pentru a determina ce ar trebui să facă noul sistem şi ce informaţii sunt necesare
pentru fiecare proces diferit care trebuie executat;
- verifică modul în care sistemul complet este conform cu cerinţele de proiectare.
3.5.2. Simboluri utilizate în diagrama fluxurilor de date (Gane Sarson)
Tabel 4 Simboluri utilizate în DFD
Definiţie Elementul din
cadrul DFD
Trăsături CASE Simbol
Proces:
-sugerează
modul de
transformare a
datelor (acţiuni
care sunt
executate cu
datele care
Fiecare proces are:
- un număr;
- un nume (de
obicei verb);
- o descriere;
- unul sau mai
multe fluxuri de
date de ieşire;
- etichetă (nume);
- tip (proces);
- descrierea
procesului (ce face?
– de obicei în
engleza structurată);
- numărul
procesului;
Nume
34
circulă prin
sistem)
- unul sau mai
multe fluxuri de
date de intrare.
- alte informaţii.
Flux de date:
-este constituit
din datele
transmise între
două procese
(dar nu numai)
Fiecare flux de date
are:
- un nume (un
substantiv);
- o descriere
- una sau mai multe
conexiuni către un
proces.
- etichetă (nume);
- tipul (flux);
- descriere;
- alias (nume
alternativ);
- elemente
componente
(descrierea datelor);
- alte informaţii.
Nume
Stoc de date:
-depozit
temporar sau
permanent de
date
Fiecare stoc de date
are:
- un număr;
- un nume (un
substantiv);
- o descriere;
- unul sau mai
multe fluxuri de
date de intrare;
-unul sau mai multe
fluxuri de date de
ieşire.
- etichetă (nume);
- tip (stoc);
- descriere;
- alias (nume
alternativ);
- elemente
componente
(descrierea datelor);
- alte informaţii;
Entitate externă:
-sistem
sursă/receptor de
date
Fiecare entitate
externă are:
- un nume (un
substantiv);
- o descriere.
- etichetă (nume);
- tip (entitate);
- descriere;
- alias (nume
alternativ);
-alte informaţii
Nume
Exemple:
-procese :
- 1. introducere informaţii clienţi (contabilitate);
- 2. înregistrare studenţi (secretariat);
- 3. validarea cererilor (contabilitate).
- flux de date:
- numele utilizatorului;
- detalii despre client;
- informaţii despre angajaţi;
- factură.
35
- stoc de date:
- Registru facturi;
- Clienţi;
- Catalog produse.
- entităţi externe:
- manager;
- administrator;
- cititor de coduri.
3.5.3. Convenţii folosite în diagramele de reprezentare a fluxurilor de
date DFD
Pentru o reprezentare fidelă a situaţiei datelor din cadrul unei organizaţii se poate
reurge la diverse convenţii în realizarea DFD[7]:
- procesele şi stocurile de date sunt numerotate secvenţial, pentru a putea fi
identificate. Numerele asociate proceselor nu semnifică ordinea de execuţie a acestora;
- pentru a evita fluxurile de date întretăiate şi aspectul de păienjeniş al diagramei,
entităţile externe şi stocurile de date pot fi duplicate. O entitate externă duplicată se poate
reprezenta prin trasarea unei linii oblice, iar un stoc duplicat printr-o linie suplimentară
verticală în partea stângă a cutiei;
- pentru a face diagramele mai lizibile, entităţile externe sunt plasate, pe cât
posibil, în jurul diagramei, iar stocurile de date, în partea centrală a diagramei;
- fluxurile de date de la/către stocurile de date sunt unidirecţionale (fie de
adăugare, fie de consultare) şi pot să nu fie etichetate.
- fluxurile de date pot fi:
- dinspre entităţile externe spre proces şi vice-versa;
- dinspre proces spre proces;
- dinspre proces spre stocul de date şi vice-versa.
3.5.4. Dezvoltarea DFD
Diagramele fluxurilor de date sunt construite, de cele mai multe ori, în mulţimi de
diagrame. O mulţime de diagrame presupune existenţa unui număr de nivele pentru
respectiva diagramă.
Paşii ce trebuie parcurşi în realizarea unei DFD sunt:
- construirea diagramei contextuale;
- construirea fragmentelor DFD pentru fiecare scenariu posibil al sistemului;
36
- organizarea fragmentelor în diagrama de nivel 1;
- descompunerea nivelului 1 în subnivele, în funcţie de necesităţi;
- validarea DFD cu utilizatorul.
Primul nivel este reprezentat de diagrama contextuală (exemple în figurile 1,2 şi
3). Aceasta arată oamenii şi/sau sistemele ce interacţionează cu sistemul, aflat în
construcţie. Prin interacţionare înţelegem punerea la dispoziţie/preluarea de informaţii
cu/de la actualul sistem. Diagrama oferă o imagine de ansamblu despre informaţiile ce
intră sau ies în/din sistem.
În cadrul acestei diagrame, sistemul este reprezentat printr-un dreptunghi. În
nivelul contextual al DFD, procesele şi stocurile de date nu sunt reprezentate.
Forum dedicat unei comunitati
Programatori de programatori
Subiecte
Mesaje
Formular inscriere
Formular creare subiect
Formular scriere mesaj
Formular cautare
Raspuns cautare
Date afisare mesaj
Date afisare subiect

Figura 13 Diagrama contextuală Forum programatori

Sistem de
gestiune a
pacientilor
Pacienti Doctori
Informatii pacienti
Detalii pacient
Informatii pacienti
Figura 14 Diagrama contextuală Sistem de gestiune a pacienţilor
37
Sistem
vanzari
Agenti vanzari
Clienti
Operatori
calculator
Manageri
comenzi
facturi
Produse sterse
Modificari produse
Noi produse
Rapoarte periodice
Figura 15 Diagrama contextuală Sistem vânzări
O altă diagramă (cea de nivel 1) se poate crea pe bază diagramei contextuale. În
cazul diagramei de nivel 1 sunt evidenţiate procesele care au loc şi care participă la
conversia intrărilor, descrise prin diagrama contextuală, în ieşiri. În această nouă
diagramă avem detalii despre procesele care sunt responsabile pentru diferitele intrări şi
ieşiri aferente sistemului informaţional. Fiecare proces evidenţiat în acest mod poate fi
rafinat şi împărţiti în subprocese într-un alt nivel al DFD (nivelul 2). În cadrul acestui nou
nivel, pe lângă subprocesele aferente, sunt evidenţiate şi stocurile de date temporare sau
permanente ce sunt prezente în sistem. În funcţie de necesităţi, această descompunere a
unei diagrame de la un anumit nivel poate continua.
Sistem
Entitate2
Entitate1 Entitate3
X
YZ
Q
W

Figura 16 Descompunerea unei diagrame DFD

38
Proces 2
Entitate2
Entitate1
Entitate3
X
Y
Z
Q
W
Proces 1
Proces 4 Proces 3
U
O
I
T
E
R

Figura 17 Descompunerea unei diagrame DFD – obţinerea diagramei de nivel 1

Proces 4.1.
Proces 4.2.
Proces 4.3.
O
I
P
A
U
T
Figura 18 Descompunerea unei diagrame DFD – obţinerea diagramei de nivel 2
I Proces 4.1.3.
U2
Proces 4.1.1.
U1
U
S Proces 4.1.2.
P1
P2
P
D
Figura 19 Descompunerea unei diagrame DFD – obţinerea diagramei de nivel 3
3.5.5. Erori ce pot apărea la DFD
În momentul desenării diagramelor DFD pot apărea o multitudine de erori. Pentru
a încerca evitarea acestora trebuie avute în vedere următoarele aspecte:
39
- entităţile externe trebuie să fie persoane sau sisteme care trimit sau primesc
informaţii la/de la sistemul avut în vedere;
- fluxurile de date trebuie să fie întotdeauna etichetate cu datele pe care acestea le
conţin. A se încerca evitarea introducerii verbelor în descrierea fluxurilor de date.
- diagramele părinte sau copil trebuie să fie consistente. A nu se analiza un flux de
date care vine sau se îndreaptă spre o entitate externă, dacă acest lucru nu a fost
reprezentat şi-n diagrama contextuală (şi vice-versa).
- să se verifice direcţia fluxurilor de date spre şi dinspre stocurile de date;
- trebuie să se verifice ca fiecare proces să aibă cel puţin o intrare şi o ieşire;
- fiecare stoc de date trebuie să aiba, de asemenea, o intrare şi o ieşire;
- fiecare nume de proces ar trebui să înceapă cu un verb;
Proces 1
(Miracol)
Proces 2
(Gaura
neagra)
Entitate 1
Proces 3
DS2
DS1
Proces 3
(Gaura gri)

Figura 20 Erori ce pot apărea la DFD

Faţă de erorile ce mai pot apărea fie din neatenţie, fie din neştiinţă, în cazul
diagramelor DFD mai pot apărea anumite aspecte legate de fluxurile de date, aspecte ce
nu respectă cele mai elementare reguli. Aceste aspecte sunt prezentate în Tabel 5
Tabel 5 Ilegalităţi ce pot apărea în cazul diagramei DFD
Incorect Corect
Entitate 1 Entitate 2 Entitate 1 Proces 1 Entitate 2
Entitate 1 DS 1 Entitate 1 Proces 1 DS 1
DS 1
Entitate 1
DS 1
Entitate 1
Proces 1
40
DS 1 DS 2 DS 1 Proces 1 DS 2
În ceea ce urmează vom prezenta un exemplu de diagramă de nivel 1 pentru
Figura 14 Diagrama contextuală Sistem de gestiune a pacienţilor
1.Adauga
pacient
Pacienti Doctori
2.Sterge
pacient
3.Actualizeaza
date pacient
4. Cauta
pacient
5. Printeaza
pacient
Info despre pacient
Numele pacientului Numele pacient
Date noi pacient
Informatii despre pacientul actualizat
Baza date
pacient
Date despre pacientul actualizat
Date actualizate despre pacient
Info pacient
Informatii pacient de sters
Informatii pacient
Raport despre pacient
Informatii despre pacient
Informatii pacient sters
Info pacient nou
Figura 21 Diagrama nivel 1 Pacienti
3.6. Modelarea conceptuală a datelor
Un model conceptual este un ansamblu de concepte şi reguli de combinare a
acestor concepte permiţând reprezentarea realităţii circumscrise domeniului supus
informatizării[15]. În cadrul modelării conceptuale a datelor se va renunţa la abordarea
proceselor şi se va trece la abordarea sistemelor prin prisma datelor. La fel ca şi în cazul
modelării proceselor şi modelării logicii proceselor elementele esenţiale vor fi
diagramele[7].
Obiectivul principal al ingineriei informaţiei este crearea unui set de metodologii
care să poată fi folosite în cele mai diverse medii de lucru, astfel încât să se construiască
modele ale datelor la nivele de întreprindere, iar sistemele proiectate izolat să se integreze
în aceste modele[7].
Datele trebuie să fie unice. Asupra lor, la nivel de întreprindere, pot fi văzute două
categorii mari de operaţiuni[7]:
- asigurarea datelor (creare, actualizare);
41
- utilizarea datelor (obţinere de documente, de diverse rapoarte, analize „What-
If”, sprijin decizional, diferite căutări de informaţii, control şi auditare întreprindere).
Metodele de determinare a cerinţelor trebuie să fie orientate, prin întrebările puse,
prin anchetele efectuate, şi asupra datelor, nu numai asupra proceselor şi logicii lor. La
început, chiar fără utilizarea unei terminologii de specialitate, analistul va fi preocupat de
modul în care va afla cât mai multe informaţii despre datele necesare viitorului sistem
pentru a funcţiona la parametrii proiectaţi. Întrebările vor fi astfel formulate încât să se
realizeze o bună înţelegere a regulilor după care vor fi folosite datele în noul sistem, ce
politici vor fi utilizate. Nu trebuie, încă, să se intre în detalii de genul: când şi cum sunt
prelucrate sau folosite datele, pentru a se realiza modelarea datelor[9].
Modelarea datelor se realizează printr-o combinaţie a punctelor de vedere. Un
prim punct de vedere, formulat în literatură sub numele de metoda top-down, va scoate în
evidenţă regulile derulării activităţii firmei, printr-o înţelegere foarte clară a naturii
afacerii, şi nu se va opri asupra detaliilor privind modul în care ecranele, rapoartele sau
documentele sunt folosite în organizaţie[9].
În afara metodei top-down, informaţiile necesare construirii modelului datelor se
pot obţine şi prin urmărirea documentaţiei firmei, ecrane, rapoarte, formulare, din
interiorul sistemului. Acest proces este cunoscut în literatura de specialitate sub numele
de metoda bottom-up[9].
Elementele rezultate vor figura în diagramele fluxurilor de date prin care vor fi
evidenţiate datele prelucrate în sistem şi de aici va rezulta necesarul de date menţinute în
baza de date a sistemului[7].
3.6.1. Obiectivele unei proiectări de calitate
Obiectivele ce se doresc a fi atinse în momentul proiectării unei baze de date
sunt[5]:
 Baza de date permite regăsirea atât la cerere, cât şi ad-hoc a
informaţiilor. Baza de date trebuie să stocheze datele necesare pentru
satisfacere cerinţelor informaţionale definite pe durata procesului de
proiectare, precum şi toate interogările ad-hoc posibile care pot fi
formulate de către un utilizator.
 Tabelele sunt construite în mod corespunzător şi eficient. Fiecare tabel din
baza de date reprezntă un singur subiect, este compus din câmpuri relativ
distincte, reduce la un minimum absolut cantitate de date redundante şi
este identificat în cadrul bazei de date prin intermediul unui câmp cu
valori unice.
 Integritatea datelor este impusă la nivel de câmp, tabel şi relaţie. Aceste
niveluri de integritate contribuie la garantarea faptului că structurile de
date şi valorile acestora vor fi în permanenţă valabile şi precise.
 Baza de date se conformează regulilor de desfăşurare a activităţii
relevente pentru organizaţie. Datele trebuie să furnizeze informaţii
42
valabile şi precise care să fie întotdeauna relevante pentru domeniul de
activitate respectiv.
 Baza de date se pretează la dezvoltări ulterioare. Structura bazei de date
trebuie să fie uşor de modificat sau de dezvoltat, pe măsură ce necesităţile
informaţionale ale întreprinderii se schimbă sau se extind.
3.6.2. Modelul entitate relaţie (entitate asociere)
Modelul conceptual al datelor înseamnă o modalitate de reprezentare a datelor
organizaţiei. Rolul său este de a scoate în relief toate regulile privind identitatea şi
legăturile existente între date[9].
Cea mai cunoscută formă utilizată pentru modelarea datelor este diagrama
entitate-relaţie (DER). O modalitate aproape identică este folosită şi în analiza şi
proiectarea orietată-obiect[7].
Modelarea datelor prin DER prezintă caracteristicile şi structura datelor
independent de modul în care acestea sunt memorate în calculator. Modelul se creează
iterativ. De cele mai multe ori, operaţiunea are loc la nivel de întreprindere, prin apelarea
la o categorie foarte largă de date neglijându-se detaliile exagerate. Doar în etapele
următoare, în speţă când se trece la definirea proiectului, are loc construirea unui model
anume entitate-relaţie prin care să fie scoasă în evidenţă aria de întindere a proiectului. În
timpul structurării cerinţelor, un model entiatate-relaţie reprezintă cerinţele conceptuale
de date pentru sistemul luat în discuţie. După ce sunt descrise complet intrările şi ieşirile
sistemului în cadrul proiectării logice, modelul conceptual al datelor, redat sub forma
entitate-relaţie, este rafinat înainte de a fi trecut într-un format logic (de regulă, un model
relaţional al datelor) din care se definesc bazele de date şi are loc proiectarea fizică a
acestora[9].
Entitatea
Entităţile sunt obiecte sau evenimente (fenomene sau procese economice, în cazul
nostru) apărute prin modelarea realităţii, fiind caracterizate printr-o existenţă de-a lungul
timpului (obiectul), sau o apariţie la un moment dat (evenimentul), având o mulţime de
caracteristici specifice (proprietăţile acestuia).
Exemple: Entitatea Clientul cu codul 7 este definit prin următoarele realizări ale
caracteristicilor: „Popescu Ion”(denumire client) , 0745676876 (numărul de telefon),
Suceava (adresa clientului). Entitatea Clientul 7 are propria identitate , distingându-se
clar de celelalte entităţi de acelaşi tip (ceilalţi clienţi) prin numărul atribuit şi are o
existenţă de sine-stătătoare.
La fel putem spune şi despre evenimente. Ele reprezintă asocieri între două sau
mai multe obiecte[7].
Exemplu: CLIENT COMANDĂ PRODUS.
O entitate poate fi o persoană, un loc, un obiect, un eveniment sau un concept din
domeniul de activitate a utilizatorului despre care organizaţia doreşte să păstreze anumite
date. Totuşi, în activitatea de modelare interesul nu este concentrat pe entitate, ci pe tip de
entitate, concept ce aparţine problemei ce se studiază.
43
Tipul entităţii, cunoscut şi sub numele de clasa entităţii, este o colecţie de entităţi
care au proprietăţi sau caracteristici comune. Fiecărui tip de entitate i se atribuie un nume.
Cât timp numele reprezintă o clasă sau un set de cazuri, el este singular. Şi încă o
convenţie. Cum referirea generală la elementele ce pot fi catalogate ca entităţi se poate
face prin noţiunea de obiect (deşi sensul lui poate fi altul în contextul analizei şi
proiectării orientate obiect), referirea la acesta se va realiza printr-un substantiv la
singular. Se vor folosi litere majuscule, plasate în interiorul dreptunghiului corespunzător
entităţii[7].
Exemplu:CLIENŢI, COMENZI, DOSAR, REZERVĂRI etc.
Deosebirea dintre entitate şi tip de entitate poate fi observată în Figura 22.
CODC
NUME
TELEFON
ADRESA
1
Pop Ion
0973846712
Bucuresti
2
Atomei Gheorghe
0748286002
Iasi
58
Ionescu Vasile
0897237248
Craiova
CLIENTI
ENTITATI
ATRIBUTE
TIP DE ENTITATE
REALIZARI
ALE
ATRIBUTELOR
Figura 22 Entităţi aparţinând aceluiaşi tip de entitate
44
CODC
NUME
TELEFON
ADRESA
2
Atomei Gheorghe
0748286002
Iasi
CLIENTI
ENTITATI
ATRIBUTE
TIP DE ENTITATE
REALIZARI
ALE
ATRIBUTELOR
CODF
NUME
TELEFON
ADRESA
FURNIZORI
Figura 23 Entitate aparţinând diferitelor tipuri de entităţi
De remarcat că în literatura de specialitate se defineşte mai întâi conceptul de
mulţime de entităţi (tip de entităţi), pentru ca apoi să se adopte pentru uşurinţa exprimării
prescurtarea de entitate pentru acest concept. Deci în cele ce urmează, entitatea va fi un
obiect generic care reprezintă mulţimea tuturor instanţelor sale.
O instanţiere a entităţii sau instanţă, denumită de noi în continuare, caz al
entităţii sau caz, este o manifestare singulară a unui tip de entitate. Un tip de entitate se
descrie o singură dată prin modelul datelor, în timp ce mai multe cazuri ale acelui tip de
entitate pot fi reprezentate prin datele stocate în bazele de date. De exemplu, există o
singură entitate CLIENT, dar ea poate să aibă sute sau mii de cazuri/instanţe ale acestei
entităţi stocate în baza de date[7].
Entităţile pot fi împărţite în funcţie de gradul de dependenţă faţă de alte entităţi în:
 Entităţi independente (tari) – au existenţa independentă de alte entităţi;
 Entităţi dependente (slabe) – sunt formate din instanţe care îşi justifică
încadrarea în clasa respectivă atâta timp cât într-o altă entitate există o
anumită instanţă de care sunt dependente.
Atributele
Fiecare tip de entitate are un set de atribute asociate lui. Un atribut este o
proprietate sau o caracteristică a unei entităţi care prezintă interes pentru organizaţie.
ANGAJATI COPII
Figura 24 Entitate tare/ Entitate
slabă
45
Fiecare atribut al unei entităţi prezintă un domeniu, adică o mulţime de valor ice pot fi
admise de către acesta.
Exemplu de entitate pentru aplicaţia DECONTĂRI şi unele dintre atributele
posibile: CLIENT : CodClient, DenClient, AdresaC
Ca şi numele tipurilor entităţilor, numele atributelor sunt substantive scrise cu
majuscule (eventual + minuscule), plasate în interiorul elipselor (diagrama ER), legate de
entitatea căreia i se asociază. De multe ori însă, chiar şi în cazul folosirii produselor
CASE, pentru a nu se încărca o diagramă entitate-relaţie, se evită prezentarea atributelor.
Atributele pot fi clasificate în funcţie de mai multe criterii[15]:
1. după complexitate:
a. elementare (simple) - ale căror realizări nu pot fi descompuse (ex:
preţ unitar, lungime, cantitate);
b. decompozabile (complexe) - ale căror realizări sunt decompozabile
(ex: data naşterii, cnp-ul, adresa etc.).
2. după realizările pe care le pot prezenta atributele:
a. după obligativitate:
i. obligatorii - trebuie să prezinte obligatoriu o realizare,
NOT NULL (ex: cnp-ul, cui, art_ctb, etc.);
ii. opţionale – pot să nu prezinte nici o valoare (realizare) în
cadrul unei entităţi (ex: adresa, telefon, observatii, etc.).
b. după numărul de valori componente:
i. monovaloare – prezintă o singură realizare în cadrul unei
entităţi (ex: nume_student, cnp, serie_ci, etc.);
ii. multivaloare – prezintă mai multe realizări în cadrul
aceleiaşi entităţi (ex: putem avea 2-n valori la atributul
telefon, 2-n la maşini, etc.).
Într-o bază de date slab proiectată sau proiectată inadecvat, vom întâlni trei tipuri
de atribute (câmpuri)[5]:
1. un câmp multiplu (câmp compozit, câmp decompozabil) – ce conţine două
sau mai multe elemente distincte în cadrul valorii acestuia.
2. un câmp cu valori multiple (multivaloare)– ce conţine mai multe apariţii
ale aceluiaşi tip de valoare;
3. un câmp calculat – care conţine o valoare de text concatenat, sau
rezultatul unei expresii matematice
46
Figura 26 Câmpuri ce se doresc a fi evitate într-o bază de date
Chei
Cheile sunt acele câmpuri speciale care îndeplinesc roluri foarte bine determinate
în cadrul unui tabel, iar tipul cheii defineşte rolul acesteia în interiorul tabelului. Un tabel
poate conţine numeroase tipuri de chei, dar cele mai importante sunt cheia primară şi
cheia externă[5].
Ansamblul minimal de atribute prin care se poate identifica în mod unic orice
tuplu (înregistrare) reprezintă cheia tabelului ( tabel=relaţie în concepţia lui E.F.Codd).
Fiecare tip de entitate trebuie să aibă un atribut sau un set de atribute prin care să se
efectueze diferenţierea unui caz de acelaşi tip[7].
Cheie:
- simplă – construită dintr-un singur atribut;
- compusă – formată din mai multe atribute.
O relaţie poate avea două sau mai multe atribute sau combinaţii de atribute care să
joace rolul de cheie. O cheie candidat este un atribut sau o combinaţie de atribute prin
care se poate identifica în mod unic un caz (o instanţă) al tipului entităţii respective. Sunt
entităţi care pot avea două sau mai multe chei-candidat. De exemplu, într-o relaţie, pot fi
chei candidat CodClient, NumeClient, AdresaC (presupunând că ele identifică în mod
unic un angajat). Atunci când sunt mai multe chei-candidat, proiectantul trebuie să decidă
care din ele va fi folosită drept cheie primară[7].
O cheie-primară este o cheie-candidat care a fost selectată pentru a servi ca
identificator de cazuri în cadrul unui tip de entitate[9]. Celelate chei candidat, care nu au
fost selectate drept cheie primară se vor numi chei secundare. De exemplu, dacă se alege
cheia primară – CodClient, atunci NumeClient şi AdresaC vor fi chei secundare,
deoarece valorile lor ar putea identifica în mod unic fiecare linie.
La alegerea cheii primare, analistul trebuie să aibă în vedere trei restricţii[10]:
1. unicitatea – o cheie identifică un singur tuplu al relaţiei;
2. compoziţia minimală – atunci când cheia primară este compusă, nici un
atribut din cheie nu poate fi eliminat fără distrugerea unicităţii tuplului în
cadrul relaţiei;
3. valori nenule – valorile atributului sau ale ansamblului de atribute ce
desemnează cheia primară sunt întotdeauna specificate, deci nenule; nici
un atribut din compoziţia cheii primare nu poate avea valori nule.
În mulţimile matematice nu este permis ca un obiect să apară de mai multe ori.
Cât timp o relaţie este o mulţime de înregistrări, teoretic nici o linie a unei relaţii nu poate
Câmp calculat
Câmp multiplu Câmp multivaloare
47
fi duplicatul altei linii. Dacă o coloană sau o combinaţie de coloane nu poate să identifice
în mod unic o linie, atunci trebuie inventată o coloană-cheie specială[10].
Legătura între tupluri din relaţii diferite se realizează prin intermediul unei
coloane comune, utilizându-se noţiunea de cheie străină (cheie externă). O cheie străină
este un atribut care apare într-o tabelă şi este cheie primară în cealaltă tabelă.
În legătură cu cheia străină, apare conceptul de restricţie de integritate
referenţială. Ea presupune că, pentru o cheie străină, se admite orice valoare nenulă care
se regăseşte între valorile cheii primare din tabela-părinte.
În reprezentările din DER, în elipsa sau elipsele aferente atributului sau atributelor
ce formează cheia primară, numele respectiv se subliniază (vezi CodClient din entitatea
CLIENT)[7].
Relaţiile entităţilor
Relaţiile reprezintă legăturile între componentele unei diagrame entitate-relaţie. O
relaţie este o asociere între cazurile/instanţele uneia sau mai multor tipuri de entităţi care
prezintă interes pentru organizaţie. Ele se pot simboliza printr-un romb. De regulă,
relaţiile sunt redate prin verbe[7].
Cardinalitatea relaţiilor
Presupunem că există două tipuri de entităţi, A şi B, între care există o linie de
legătură pentru a marca relaţia. Cardinalitatea unei relaţii este dată de un număr al
cazurilor/instanţelor entităţii B care pot sau care ar putea să fie asociate cu fiecare caz al
entităţii A. Cardinalitatea este sugerată prin 0 (zero), 1, M (“multe”), cu menţiunea că ele
pot avea prezenţă obligatorie sau opţională. Trimiterea la cardinalitate se face în moduri
destul de diferite, în funcţie de notaţia folosită. Recomandăm citirea cu atenţie a
diagramelor şi descifrarea elementelor strict necesare înţelegerii, îndeosebi pentru
reflectarea cardinalităţii. De exemplu, ea poate fi notată cu semne (0, 1, M, N) sau prin
simboluri (linie cu vârf simplu de săgeată pentru 1, linie cu vârf dublu de săgeată pentru
M. Alteori, 1 se reprezintă prin linie simplă şi M prin vârf de săgeată). În multe materiale,
inclusiv produse CASE, se foloseşte notaţia model-date, cunoscută mai mult sub numele
laba-gâştei, conform cărei cardinalitatea se reprezintă prin următoarele simboluri[9]:
Figura 27 Reprezentări cardinalitate
48
Entităţi compuse sau asociative (gerundive)
Atributele pot fi asociate cu o relaţie multe-la-multe sau cu o entitate. Un
exemplu, din lumea cursurilor-credit, transferabile în cadrul unei perioade. Un student
poate lua mai multe cursuri dintr-o listă, dar finalizarea cu notă se poate efectua în
momente (la date) diferite. Prezentăm, mai jos, câteva dintre datele concrete[9]:
MATRICOLA STUDENT NUME CURS DATA PROMOVĂRII
1111 Informatică Iulie 1999
1177 Informatică Septembrie 1999
1155 Informatică Septembrie 1999
1111 Drept comercial Ianuarie 2000
Din analiza cazurilor rezultă că atributul DATA_PROMOVĂRII nu este o
proprietate a entităţii STUDENT, cât timp examenele pot fi date la momente diferite. Dar
nu este nici o proprietate a entităţii CURS, cât timp acelaşi curs poate fi susţinut la date
diferite. În schimb, DATA_PROMOVĂRII este o proprietate a relaţiei dintre STUDENT
şi CURS[7]. Atributul se asociază relaţiei şi se prezintă sub formă de diagramă, ca în
Figura 28.
Figura 28 Asocierea unui atribut la relaţie
De aici rezultă un caz aparte de entitate, numită gerundivă sau compusă sau
asociativă care, de fapt, este o relaţie folosită de analist în model ca un tip de entitate. În
astfel de cazuri, se foloseşte un simbol special: dreptunghi cu romb în interior, în care se
scrie numele entităţii (Figura 29)[9].
49
Figura 29 Reprezentarea unei entităţi gerundive
Scopul diagramelor entitate-relaţie este de a surprinde cele mai complete sensuri
posibile ale datelor necesare sistemului informaţional din organizaţie[7].
Tipuri de relaţii
Din cele prezentate mai sus, rezultă că între entităţile descrise, luate două câte
două, se pot identifica trei tipuri de relaţii (legături): unu-la-unu, unu-la-multe, multe-
lamulte.
În diagrame, descrierea relaţiilor se face de-a lungul liniilor care leagă cele două
entităţi. Simbolul vârf-de-săgeată este cunoscut ca indicator al cardinalităţii (cardinality
indicator). În cele ce urmează sunt prezentate exemple de tipuri de relaţii[9].
1. Relaţia unu-la-unu (1:1)
„Fiecare BIROU este condus de un, şi numai un, MANAGER”
„Fiecare MANAGER conduce un, şi numai un, BIROU”.
Figura 30 Relaţie 1 la 1
2. Relaţia unu-la-multe (1:M)
„Fiecare VÂNZARE implică unul sau mai multe ATRICOL(e)_VÂNDUT(e) “
„Fiecare ATRICOL_VÂNDUT face parte din numai o VÂNZARE”
Figura 31 Relaţie unu la multe
50
3. Relaţia multe-la-multe
“Fiecare FURNIZOR livrează unul sau mai multe PRODUS(e)”
“Fiecare PRODUS este livrat de unul sau mai mulţi FURNIZOR(i)”
Figura 32 Relaţie multe-la-multe
În anumite cazuri, între două entităţi pot exista mai multe relaţii[7]. De exemplu,
s-ar putea spune că “FURNIZOR oferă PRODUS”, dar şi “PRODUS este cumpărat de la
FURNIZOR”, ceea ce s-ar putea reprezenta ca în Figura 33.
Figura 33 Asocieri multiple între entităţi
4. Relaţii opţionale şi obligatorii
Alteori, relaţiile dintre entităţi nu-şi fac simţită prezenţa în toate situaţiile. Chiar
cazul cu studiile la care lucrează diverse persoane este destul de elocvent; o persoană
poate să lucreze la un singur studiu sau la câteva, sau la niciunul şi, invers, un studiu
poate fi efectuat de o persoană, de mai multe sau de nici una. În astfel de situaţii, se
apelează la următoarea formă de reprezentare[7]. (Figura 34)
Figura 34 Asocieri opţionale
Cercul suprapus pe latura entităţii indică, de fapt, poziţia 0 (valoarea minimă
poate fi şi zero), conferind relaţiei caracterul opţional[7].
Un alt aspect se referă la caracterul obligatoriu al relaţiilor. Cu alte cuvinte, o
entitate poate exista fără cealaltă?[7]
Să luăm exemplul vânzărilor. În relaţia 1:M, dintre VÂNZARE şi
ARTICOL_VÂNDUT. Ar fi total eronat ca o entitate să existe fără cealaltă: nu poate fi o
vânzare fără cel puţin un articol vândut şi, invers, un articol nu poate fi vândut fără o
vânzare (operaţiunea nu ar avea sens).Simbolul folosit pt a marca relaţiile obligatorii este
acelaşi cerc, cu deosebirea că este haşurat[7].
51
Figura 35 Asocieri obligatorii
5. Relaţia unei entităţi cu ea însăşi
În practică, apar şi situaţii în care o entitate este pusă în relaţie cu ea însăşi[7]. Ne
oprim la exemplul entităţii ANGAJAT. Unii dintre ei dobândesc statutul de coordonatori
ai activităţii celorlalţi, situaţii în care se poate apela la o diagramă de genul celei din
Figura 36.
Figura 36 Relaţia entităţii cu ea însăşi
Reprezentarea anterioară se citeşte astfel[7]:
“Un angajat poate fi coordonatorul unuia sau mai multor angajaţi”
“Oricare angajat întotdeauna raportează altui angajat”
6. Relaţii alternative (sau/sau)
Uneori se ivesc situaţii când relaţiile posibile se redau alternative[7]: fie o variantă
este de urmat, fie cealaltă. De exemplu, o marfă destinată vânzării poate fi realizată de
unitatea care o vinde sau poate fi procurată din afară. În ambele cazuri, obiectul
comercializat, MARFA, care este o entitate, va fi pusă în legătură cu cele două surse
posibile, PRODUCŢIA_ALTORA şi PRODUCŢIA_PROPRIE, printr-un punct comun,
dar nu cu linii de relaţii distincte, aşa cum este prezentat în figura Figura 37.
Figura 37 Relaţie aternativă
52
Interpretarea diagramei este[7]:
“O marfă se poate asocia sau cu un producător din afară, sau cu producţia unităţii”
“Un producător din afară poate livra mai multe mărfuri”
“O linie proprie de producţie poate livra mai multe mărfuri”
Deşi diagramele entitate-relaţie se cunosc de către mulţi specialişti din lumea
bazelor de date, ele constituie unul din conceptele esenţiale ale analizei şi proiectării
structurate şi, ca atare, provin din acest domeniu[9].
După cum reiese şi din citirea cu atenţie a numelui diagramei, scopul ei este de a
evidenţia entităţile de date (obiectele despre care se solicită păstrarea datelor) şi relaţiile
ce există între ele. De remarcat diferenţa dintre diagrama fluxului de date şi diagrama
entitate-relaţie. În timp ce diagrama fluxurilor de date indică atât procesele de prelucrare,
cât şi entităţile de date (redate fie sub forma fluxurilor de date, fie a locurilor de stocare),
DER tratează doar entităţile de date. Din această cauză, DER poate fi considerată şi ca
diagrama modelului datelor sau diagrama conceptuală a datelor[9].
În sistemul analizat pentru descrierea DER se apelează la simbolul dreptunghi,
pentru fiecare entitate. Se recomandă ca numele entităţii să fie redat printr-un substantiv
la singular (CLIENT, PRODUS, SALARIAT, FACTURA_DESFACERE,
ÎNCASĂRI)[7].
După ce se identifică entităţile se continuă cu împerecherea lor, fiecare cu fiecare,
pentru a descrie relaţiile dintre ele[7].
Teste rezolvate
1. Nu intră în ciclul prelucrării datelor:
a. Prelucrarea datelor
b. Distrugerea datelor A
c. Întreţinerea de fişiere
d. Obţinerea de informaţii
2. Printre activităţile specifice etapei de culegere a datelor se numără şi:
a. Clasificarea datelor
b. Observarea mediului A
c. Sintetizarea
d. indexarea datelor
3. O metodă foarte răspândită, utilizată în analiza şi determinarea cerinţelor
sistemului este:
a. Chestionarul
b. Prototipizarea
c. Interviul A
d. JAD
4. Care este cea mai rapidă metodă ce poate fi utilizată în analiza şi determinarea
cerinţelor sistemului din punctul de vedere al unui singur viitor utilizator?
a. Chestionarul A
b. Prototipizarea
c. Interviul
53
d. JAD
5. Metoda tradiţională utilizată în analiza şi determinarea cerinţelor sistemului care
nu are o arie largă de utilizare este:
a. Chestionarul A
b. Interviul
c. JAD
d. Prototipizarea
6. Un pas al prototipizării îl constituie:
a. Prelucrarea datelor
b. Adaptarea iterativă a sistemului la cerinţele utilizatorilor A
c. Captarea datelor sub diferite forme cu ajutorul unor echipamente speciale
d. Elaborarea schemei fluxului informaţional global
7. Câte relaţii de generalizare avem în figura:
a. 1
b. 2 A
c. 3
d. 4
8. Simbolul ce nu apare în cadrul Diagramei Fluxurilor de Date este:
a. Actor A
b. Entitate externă
c. Flux de date
d. Proces
9. În cadrul unei DFD, un cititor de coduri poate fi considerat:
a. Entitate externă A
b. Flux de date
c. Proces
d. Stoc de date
10. În cadrul unei DFD, managerul poate fi considerat:
a. Entitate externă A
b. Flux de date
c. Proces
d. Stoc de date
11. Entităţile tari:
a. Au existenţa independenţă de alte entităţi A
b. Sunt formate din instanţe care îşi justifică încadrarea în clasa respectivă
atâta timp cât într-o altă entitate există o anumită instanţă de care sunt
dependente
54
c. Sunt persoane, obiecte, evenimente sau concepte din domeniul de
activitate a utilizatorului despre care organizaţia doreşte să păstreze
anumite date
d. Sunt manifestări singulare a unor tipuri de entităţi
12. Un atribut este :
a. Format din instanţe care îşi justifică încadrarea în clasa respectivă atâta
timp cât într-o altă entitate există o anumită instanţă de care sunt
dependente
b. Un obiect din domeniul de activitate a utilizatorului despre care
organizaţia doreşte să păstreze anumite date
c. O proprietate sau o caracteristică a unei entităţi care prezintă interes pentru
organizaţie A
d. O colecţie de entităţi care au proprietăţi sau caracteristici comune
13. Într-un tabel cu date despre studenţi cnp-ul poate fi un atribut:
a. Simplu
b. Opţional
c. Multivaloare
d. Decompozabil A
14. Într-un tabel se recomandă evitarea atributelor:
a. Decompozabile A
b. Simple
c. Elementare
d. Obligatorii
15. Într-un tabel echivalentul noţiunii de atribut este:
a. Înregistrarea
b. Câmpul A
c. Linia
d. Tuplul
Întrebări
1. Care sunt etapele parcurse în cadrul ciclului de prelucrare a datelor?
2. Ce este JAD?
3. Care sunt relaţiile specifice diagramei USE CASES(cazurilor de utilizare)?
4. Care sunt paşii parcurţi în construirea DFD?
5. Ce este un atribut?
6. Ce categorii de atribute nu sunt recomandate în construirea tabelelor?
55
4. Proiectarea logică a sistemelor informatice
4.1. Proiectarea formularelor şi a rapoartelor
4.1.1. Aspecte generale ale proiectării formularelor şi a rapoartelor
Într-o aplicaţie informatică, prin formular se înţelege acel document primar care
conţine unele date predefinite, cărora li se adaugă altele, ce urmează a fi completate în
rubrici special rezervate. Într-o formă mai restrânsă, formularul poate fi considerat
interfaţa care permite utilizatorului, în special, introducerea de date în cadrul sistemului
informatic.
Datele ce sunt afişate în cadrul formularelor sunt cunoscute sub numele de
constante, iar cele ce vor fi completate sunt denumite variabile.
Principalele părţi componente ale unui formular sunt:
– Introducere (titlu, numărul, eventual destinatarul)
– Instrucţiunile:
• Modul de completare a formularului
• Destinaţia lui după completare
– Partea principală (sau corpul formularului) – parte componentă, în cadrul
căreia utilizatorul va putea să vadă, dar să şi introducă principalele
elemente ce se vor regăsi, în final, în cele mai multe cazuri, într-o bază de
date
– Concluziile (dispoziţii finale, data, semnături, etc)
Raportul reprezintă acel document economic, ce are anumite date predefinite în
corpul său, scopul final al acestuia constând în citirea şi/sau printarea acestuia pentru a fi
utilizat în luarea deciziilor, sau poate chiar pentru arhivare.
4.1.2. Clasificare ieşiri
Pentru o proiectarea corespunzătoare a celor două elemente grafice prezentate mai
sus se recomandă o parcurgere şi o înţelegere a principalelor categorii de ieşiri. Astfel, în
cele ce urmează vom realiza o clasificare a ieşirilor din mai multe puncte de vedere.
 După scopul ieşirilor:
• Monitorizarea proceselor sau a activităţilor din cadrul firmei (Ex:
“Situaţia vânzărilor” poate fi utilizată în urmărirea şi evaluarea
vânzărilor în urma unei campanii de marketing)
56
• Controlul activităţii economice desfăşurate în cadrul firmei (Ex:
“Balanţa analitică a stocurilor” – corectitudinea înregistrării
tranzacţiilor privind stocurile)
• Luarea deciziilor pe diferite niveluri ierarhice (Ex: “Situaţia
vânzărilor pe diferite arii geografice”)
• Transferul unor informaţii în afara organizaţiei (Ex: “Situaţia
facturilor neachitate”)
• Prelucrarea informaţiilor conţinute în ieşiri, în vederea întocmirii
unor altor rapoarte sau document
 După destinatarii ieşirilor:
• Ieşiri interne
– Folosite pentru luarea unor decizii sau controlul unor activităţi
• Ieşiri externe
– Destinate unui entităţi externe din DFD (Ex: “raport de
producţie”, “oferte”)
• Ieşiri hibride
– Documente în circuit: se produc într-un sistem, îl părăsesc şi
revin, ulterior, ca şi intrări
– Documente ce pot fi citite automat (folosind tehnologii cum ar
fi RFID, coduri de bare, cerneală magnetică)
 După frecvenţa ieşirilor:
• Ad-hoc
– Răspuns la întrebările managerilor privind anumite probleme
sau cerinţe
– Se obţin de cele mai multe ori folosind limbajul SQL, sau
mecanisme asemănătoare
• Programate
– Pot fi extrase zilnic, săptămânal, lunar, trimestrial, anual, etc
• Declanşate de excepţii
– Conţin informaţii filtrate, în legătură cu anumite evenimente
sau tranzacţii, care implică depăşirea anumitor limite şi care
necesită o atenţie deosebită
• La cerere
– Conţinut şi formă predeterminată, dar sunt elaborate la cererea
managerilor
57
 După categoriile de informaţii ce se doresc a fi transmise:
• Informaţii curente
– Sintetizează starea generală a afacerii sau organizaţiei, pe
componente funcţionale
• Atenţionările
– Relatări despre lucruri care necesită intervenţie promptă
• Indicatorii de bază
– Măsuri ale principalelor aspecte privind performanţelor
organizaţiei
• Informaţiile situaţionale
– Starea curentă a unor unor proiecte importante, a problemelor,
a comenzilor
• Clevetirile
– Informaţii neformale
• Informaţiile externe
 După gradul de detaliere a conţinutului:
• Rapoarte detaliate
– Prezintă un nivel minim de agregare şi filtrare
– Sunt utilizate zilnic de către angajaţi
– Exemplu: “fişa analitică a unui client”
– De cele mai multe ori prezintă unul sau mai multe niveluri de
total
• Rapoarte de sinteză
– Informaţii agregate şi filtrate
– Folosind limbajul SQL, aceste rapoarte se pot obţine utilizând
clauza GROUP BY
– Datorită capacităţii ridicate de sintetizare a informaţiei, aceste
rapoarte sunt destinate managerilor de pe nivelurile superioare
ale conducerii
58
– Un exemplu de un astfel de raport ar putea fi “Situaţia
vânzărilor pe clienţi”, raport în care am putea avea câte o linie
cu informaţii pentru fiecare client
• Rapoarte dinamice
– Aceste rapoarte realizează o combinare între rapoartele de
sinteză cu cele detaliate
– Printre instrumentele grafice utilizate în cadrul acestor rapoarte
se evidenţiază:
• Tehnica drill-up/drill-down (elemente grafice de tip “+” şi
“-” ce permit extinderea sau restrângerea unei structuri de
tip arborescent)
• Tehnica bazată pe legături (“link-uri”)
 Sursa datelor
• Ieşiri generate din surse interne
– Indicatori principali obţinuţi din sisteme de prelucrare
automată a datelor
– Planuri, rapoarte, procese verbale
– Şedinţe programate
– Diverse conversaţii (informaţie informală)
• Ieşiri generate din surse externe
– Baze de date publice
– Cărţi, reviste
– Forumuri
– Expoziţii, târguri (informaşie informală)
 Mediul de generare şi transmitere a ieşirilor
• Tipărite (pe hârtie)
• Afişate pe ecran
• Mesaje electronice
– Web, poşta electronică
• Sisteme cu ieşiri bazate pe microfilme (Computer Output
Microfilm)
59
– Utile când este necesară stocarea documentelor semnate,
ştampilate sau cu alte caracteristici vizuale
– Utilizarea a scăzut în favoarea scanner-elor digitale
• Sisteme audio şi video
4.1.3. Reguli de proiectare a formularelor şi rapoartelor
Recomandări generale
Pentru a obţine formulare şi/sau rapoarte uşor de utilizat, puţin obositoare ar
trebui respectate anumite principii de proiectare ce fac referire la formatul acestora.
Începând chiar cu partea introductivă, se recomandă o folosirea unor formulări
sugestive, în orice interfaţă de felul acesta neputând lipsi informaţii precum titlul,
numărul, data la care au fost generate, dar poate chiar şi ora generării acestora. Toate
acestea ar putea fi destul de importante pentru o prelucrare ulterioară a acestor
rapoarte/formulare.
Tot în cadrul acestor rapoarte/formulare am putea avea o secţiune destinată
prezentării de informaţii cu rol de instruire a utilizatorului final. Aceste informaţii
constau, în cele mai multe cazuri, în reguli ce ar trebui completate clar, fără a se folosi
fraze foarte lungi, făcându-se referiri la nume sugestive ce sunt folosite în aceste
documente. Necesitatea folosirii unui limbaj adecvat în cadrul secţiunii de instrucţiuni
aferente formularelor/rapoartelor este explicată de nivelul diferit de cunoştinţe în
domeniul IT pe care poate să-l aibă utilizatorul final al acestor instrumente informatice.
În ceea ce priveşte partea principală a acestor tipizate electronice se recomandă
evitare aglomerărilor, o grupare logică a rubricilor, dar şi o accentuare a zonelor ce ar
putea fi considerate importante pentru destinatarul final al informaţiei.
Concluziile apar, mai în toate cazurile, la sfârşit de pagină, putând oferi spaţiu
pentru semnături, dar şi pentru evidenţierea eventualelor totaluri ce se impun a fi
furnizate prin elementul grafic construit.
Pe lângă aceste cerinţe ce ţin de conţinutul elementului grafic ce se doreşte a fi
construit ar trebui să avem în vedere şi alte reguli ce ar uşura munca utilizatorului final.
Astfel, se recomandă construirea acestor elemente grafice astfel încât acestea să permită o
deplasare lejeră în cadrul documentului indiferent de locul în care s-ar afla. Indiferent de
numărul de formulare/rapoarte existent într-o aplicaţie informatică se recomandă
păstrarea unei anumite uniformităţi, dorindu-se folosirea unui număr satisfăcător de
elemente grafice, având ca rezultat final un grad ridicat de similaritate în ceea ce priveşte
aspectul lor. Lizibilitatea, dar şi eficienţa din punctul de vedere a resurselor utilizate, ar
putea fi alte criterii ce ar trebui luate în seama în momentul proiectării unor formulare sau
rapoarte.
Scoaterea în evidenţă a informaţiilor
În anumite cazuri apar situaţii în care informaţiile ar trebui scoase în evidenţă.
Astfel de situaţii pot fi fel şi fel de atenţionări a utilizatorilor, puneri în gardă a acestora
(de ex: vrem să-i trasmitem că datele trebuie să aparţină unui domeniu, sau un
echipament nu funcţionează), sau poate chiar semnalări precum că operarea/procesarea a
intrat într-un regim anormal, etc.
60
Scoaterea în evidenţă a unor situaţii de genul celor prezentate se poate face îrin
mai multe modalităţi, cum ar fi: utilizarea unui marcaj intermitent la apariţia unei astfel
de situaţii, utilizarea unor culori diferite pentru mesaje de importanţă diferită, utilizarea
„marcajului sonor” în situaţii care ar impune un astfel de acţiune, dar şi diferenţieri prin
fonturi, mărimi de caractere, majuscule, sublinieri, intensităţi, etc. a textului utilizat
pentru transmiterea unei anumite informaţii.
Reguli de proiectare a rapoartelor în formă tabelară
În proiectarea unui raport, ar trebui să plecăm de la premisa că acesta poate să
afişeze informaţiile dorite pe mai multe pagini. În primul rând în cadrul unui raport vom
avea antet şi sfârşit de raport, antet şi sfârşit de pagină, antet şi sfârşit de grup, precum
şi linia de detaliu. De aceste lucruri ar trebui să ţinem cont în momentul în care dorim să
proiectăm un raport, care pe lângă informaţii de tip text, mai conţine şi informaţii aranjate
sub formă tabelară. În ceea ce priveşte prezenţa unui tabel într-un raport trebuie să ţinem
cont de elementele esenţiale ce se impun a fi utilizate în cadrul acestor elemente grafice,
şi anume:
– Număr tabel – numerotare care începe de la 1, dar în anumite cazuri putem
ataşa la acest număr şi un număr de capitol/subcapitol;
– Titlu tabel – prezent în partea superioară a tabelului, centrat, cu bold,
pentru a scoate în evidenţa informaţia transmisă prin tabel;
– Linii tabel – practic, reprezintă informaţia trasnmisă prin cadrul tabelului
construit;
– Titlul cotorului (capetele de linie) – denumirea sintetizează denumirile
prezente în cadrul titlurilor fiecărei linii;
– Titlul coloanelor – prezent în cele mai multe tabele;
– Tiltul coloanelor multiple – apare în momentul în care o coloană se divide
în două sau mai multe coloane;
– Titlul liniei – prezent în cadrul tabelelor „încrucişate”, unde informaţia din
celule capătă semnificaţie în momentul în care se identifică atât linia, dar
şi coloana de care aparţine;
– Subtitlu – este opţional, fiind utilizat în cazuri speciale;
– Sursa – pentru tabelele care sunt preluate din diferite surse, chiar dacă ele
nu sunt electronice;
– Note explicative – necesare, de cele mai multe ori, pentru clarificare
informaţiilor prezentate în tabele.
Reguli de proiectare a graficelor
În cazul graficelor părţile componente pe care ar trebui să le prezentăm într-un
raport sunt:
– Un număr – ca şi în cazul tabelelor;
– Un titlu – sugestiv pentru ceea ce se reprezintă prin intermediul figurii
(alături de numărul figurii el va fi în partea inferioară a întregului element
grafic);
61
– Un grafic – reprezentat printr-o figură, care ar putea fi o sinteză a datelor
din cadrul unei baze de date;
– Titlu – fără subliniere sau cu punct la final, prezent în cadrul figurii, de
cele mai multe ori deasupra ei;
– Sursa - de asemenea, doar în cazurile în care respectiva figura a fost
preluată din alte surse.
Referirea la grafice existente într-un anume raport se va face, de-a lungul lui, prin
precizarea , fie a numărului graficului, fie a numărului, dar şi a titlului acestuia.
4.1.4. Regulile privind controlul confidenţialităţii, integrităţii şi
accesibilităţii ieşirilor
În orice aplicaţie informatică se pot prelucra fel şi fel de date, se pot obţine
diverse informaţii, astfel încât trebuie să tratăm cu atenţie utilizatorii finali ce pot avea
acces la funcţionalităţile ei. Aplicaţiile pot fi de două feluri, aplicaţii care odată instalate
pot fi utilizate de toate persoanele care au acces la o anumită unitate de calcul, precum şi
aplicaţii, care, după instalare, obligă eventualul utilizator să introducă detalii de
autentificare (de cele mai multe ori un user şi o parolă).
În cadrul organizaţiilor există o multitudine de aplicaţii, instalate pe diverse
sisteme de calcul, ele putând fi accesate doar de pe calculatorul unde au fost instalate, sau
chiar în reţea. Indiferent de modul de acces, mare parte din aceste aplicaţii ar trebui să
furnizeze informaţiile pe categorii de utilizatori. Astfel, chiar dacă se accesează aceeaşi
aplicaţie, de doi sau mai mulţi utilizatori diferiţi, date la care ar putea avea acces aceştia
ar putea diferi în funcţie de rolurile atribuite de către administrator pentru fiecare
utilizator în parte. Astfel, putem spune că există anumite limitări de acces la nivel de
utilizator. Drepturile depline le poate avea doar administratorul care se ocupă de aplicaţia
respectivă.
Pentru un bun control al accesibilităţii utilizatorilor la date electronice furnizate
de către o aplicaţie informatică se recomandă separarea responsabilităţilor pe roluri.
Astfel, ar fi indicat ca fiecare rol să fie configurat astfel încât să se separe funcţiile pe
fiecare departament din cadrul firmei fizice. De exemplu, utilizatorul care se ocupă cu
preluarea comenzilor să aibă acces la funcţionalităţi diferite faţă de personalul care s-ar
ocupa de livrări.
De asemenea, pentru a suplimenta controlul asupra informaţiilor furnizate de către
sistem se recomandă ca, eventualul raport ce se listează, să aibă, pe lângă datele dorite şi
alte elemente de identificare, cum ar fi: data la care a fost generat, perioada de timp
acoperită de informaţii, numele destinatarului, numărul de pagină, totaluri de control,
numărul de înregistrări prelucrate.
62
4.1.5. Demersul proiectării ieşirilor
În faza incipientă a proiectării ieşirilor, ar trebui să studiem cu atenţie mediul în
care va funcţiona respectiva aplicaţie şi să încercăm să răspundem la următoarele
întrebări:
• Cine este beneficiarul formularului?
• Ce trebuie să conţină formularul?
• Când se solicită obţinerea ieşirilor?
• Unde trebuie să fie transmis formularul şi unde să fie folosit?
• Când se vor utiliza ieşirile respective?
• Câte persoane le vor folosi sau le vor vedea?
După găsirea unor răspunsuri la aceste întrebări, putem recurge la proiectarea
elementelor grafice ce vor fi suportul ieşirilor necesare bunei desfăşurări a activităţii.
Totuşi, în momentul proiectării ar trebui să ne aigurăm că rezultatul obţinut va atinge
performanţe superioare în ceea ce priveşte viteza de obţinere a datelor dorite, precizia cu
care se vor obţine aceste date, dar şi gradul de utilizare a acestor ieşiri. Alte caracteristici
ce se doresc a fi atinse ar fi:
• Stabilitate (sau uniformitate) – aceeaşi termeni, abrevieri, formate, etc.
• Eficienţă la formatare – texte aliniate, coloane sortate, etc
• Comoditate – fără trimiteri la afişări anterioare, etichete clare – elemente
care ar putea duce la o organizare haotică a rezultatelor
• Format – evidenţierea elementelor importante, format (font, culoare, stil )
identic pentru acelaşi tip de dată
• Flexibilitate – în listare, în navigare, etc
4.1.6. Formularea specificaţiilor de proiectare a ieşirilor
După efectuarea primelor demersuri legate de proiectarea ieşirilor se trecere la
stabilirea specificaţiilor de proiectare a formatelor elementelor ce vor constitui suport
pentru ieşirile noastre. În primul rând se realizează o prezentare descriptivă a ieşirii, cu
specificarea scopului, dar şi a destinatarilor ieşirilor, frecvenţa acestor ieşiri, dar şi
formatul şi conţinutul lor. După această prezentare se încearcă crearea unui model al
proiectului (realizarea unui prototip) ce ar putea fi supus validării vitorilor utilizatori. În
funcţie de rezultatele obţinute în urma evaluării acesstui prototip, se va anula prototipul,
se vor efectua modificările cerute de utilizatorii finali, sau, în cazul unei evaluări pozitive,
se vor pune în funcţiune toate formatele verificate.
63
4.2. Proiectarea interfeţelor utilizator
4.2.1. Metode de interacţiune om calculator
Înainte de a trece la prezentarea anumitor aspecte legate de proiectarea interfeţelor
utilizator, facem o trece în revistă a principalelor metode de interacţiune om-calculator.
Astfel, în momentul de faţă se cunosc mai multe metode prin care omul interacţionează
cu calculatorul, primul dintre acestea fiind prin intermediul limbajului-comandă. Acest
mijloc presupune fie utilizarea unor comenzi sintactice, ceea ce presupune respectarea
unei sintaxe impuse de produs, fie utilizarea unor mnemonice (cum ar fi RENAME,
ADD, SUB, etc), dar şi prin intermediul comenzilor prin intermediul tastelor (F1, F2,
etc., sau CTRL, SHIFT; ALT). Aceste metode de interacţiune om-calculator au fost
primele utilizate în istoricul calculatoarelor. În aceste momente, ele pot fi considerate
depăşite, în locul lor fiind introduse alte metode mult mai uşor de utilizat, care oferă o
interfaţă mult mai atrăgătoare. Aceste noi metode sunt prezentate în cele ce urmează.
O primă metodă, ce a apărut în acelaşi timp cu dezvoltarea interfeţelor grafice,
este reprezentată de interacţiunea prin meniuri. În primul rând, aceste meniuri pot fi
simple liste cu o varietate de opţiuni. Acest lucru determină o navigare simplă, dar totuşi
poate ocupă porţiuni destul de mari din ecran. O altă variantă de meniuri a apărut mai
târziu şi a presupus existenţa unei zone de comenzi şi linii meniu. Toate opţiunile ce
putea fi accesate în cadrul acestor meniuri se aflau fie pe prima, fie pe ultima linie a
ecranului. Ele puteau fi apelate printr-o literă, sau chiar printr-o tastă funcţională. Faţă de
primul caz, aceste meniuri nu ocupau mult loc pe ecran, fiind mai uşor de utilizat. Ele au
fost des întâlnite în cadrul aplicaţiilor ce rulau sub sistemul de operare MS-DOS. Meniuri
de tip bară au fost cele care s-au dezvoltat în momentul apariţiei primelor sisteme de
operare cu o interfaţă grafică destul de dezvoltată. Opţiunile de meniu din cadrul acestor
meniuri erau organizate într-o bară de meniu, fiidn grupate sub formă de meniuri dropdown.
Ele puteau fi organizate pe diferite niveluri, opţiunile disponibile pe fiecare nivel
depindeau de operaţiunile pe care le puteau efectua, astfel se oferea posibilitatea navigării
mult mai rapide în cadrul aplicaţiei. Asemănătoare cu aceste meniuri sunt şi meniurile
contextuale. Spre deosebire de primele, acestea din urmă se apelează folosind butonul
dreapta a mouse-ului, iar opţiunile ce apar prin afişarea acestor meniuri sunt mai puţine
decât cele prezente în cadrul meniurilor drop-down. Aceste meniuri contextuale sub
meniul pop-up, astfel, nu se poate accesa nici un element grafic al aplicaţiei, decât după
accesarea unei opţiuni a meniului, sau după închiderea lui. O altă categorie de meniuri ce
pot fi întâlnite în cadrul aplicaţiilor informatice sunt meniuri prin imagini (pictograme,
icons). Aceste opţiuni oferă un acces rapid către comanda dorită, desigur doar dacă se
cunoaşte semnificaţia fiecărei pictograme.
Interacţiunea prin ecrane pentru introducerea datelor reprezintă o altă categorie
de interacţiune om-calculator. Când vorbim de o astfel de interacţiune ne referim la
formulare şi controale. Dacă despre formulare am mai discutat în subcapitolele
anterioare, în cele ce urmează voi face o scurtă enumerare a principalelor controale
utilizate într-o interfaţă grafică, cu precizarea anumitor caracteristici ale acestora:
a. Căsuţă de text (Text box)
64
o Des utilizat;
o Permite preluarea datelor de la tastatură;
o Dimensiunea textului introdus poate fi limitat;
o Permite introducerea textului sub un anumit format;
o Poate avea valoare implicită.
b. Etichetă (Label)
o Însoţesc căsuţele text, dar nu numai;
o Pot fi utilizate pentru titluri, explicaţii sau diverse indicaţii.
c. Căsuţa listă (List box)
o Derivată din Text box;
o Nu permite introducerea unei valori de la tastatură;
o Utilizată pentru selectarea unuia, sau mai multor elemente dintr-o anumită
listă.
d. Căsuţa combinată (Combo box)
o O combinaţie între căsuţele text şi cele listă;
o Conţine o listă de valori, din care poate fi selectată numai una, dar pot fi
introduse şi valori noi în listă.
e. Control Grilă (Grid)
o Utilizat în cazul formularelor ce presupun culegere de date dintr-o bază de
date;
o Are mai multe linii şi mai multe coloane.
f. Butoane de opţiune (Radio buttons)
o Permite alegerea unei singure opţiuni din mai multe posibile .
g. Căsuţa de validare (Check box)
o Asemănătoare cu Radio Buttons, dar în acest caz utilizatorul poate alege
un număr variabil de opţiuni.
h. Cadru de pagină (Page frame)
o “pagină” suprapusă într-un formular;
65
o Utilizate când funcţionalitatea unui formular poate fi separată în mai multe
părţi, fiecare dintre ele având elemente interconectate.
i. Buton de comandă (Command button)
o Permite declanşarea unei acţiuni sau operaţiuni.
În Figura 38, avem un formular cu mai multe controale pe el.
Figura 38 Exemplu de formular
4.2.2. Reguli de proiectare a meniurilor
Convenţiile standard, ce se impun a fi respectate în momentul proiectării meniului
unei aplicaţii, sunt:
– Se impune prezenţa meniului File (sau Fisier – în variantele în limba
română). Aceasta cerinţă se doreşte a fi respectată, deoarece, în acest
moment, multe aplicaţii ce folosesc meniuri au ca primă secţiune de meniu
acestă rubrică;
66
– Pe a doua poziţie ar trebui să avem Edit ( desigur dacă e necesară în cadrul
aplicaţiei noastre). Explicaţia utilizării acestei opţiuni e asemănătoare cu
cea de la opţiunea File;
– Opţiunea Window – ar trebui plasată penultima în bara de meniu;
– Opţiunea Help – ar trebui să ocupe ultima poziţie pe bara de meniu (mai
toate aplicaţiile cu meniuri utilizează o astfel de opţiune, având ca
subopţiuni elemente ca About, Contact Us, Updates, etc.)
– Fiecare opţiune a meniului poate avea subopţiuni. La rândul lor, aceste
subopţiuni pot avea incluse alte categorii de opţiuni. Pentru a evidenţia
aceste lucruri, în meniurilor, vom avea câte o săgeată în dreapta fiecărei
opţiuni, săgeată care va indica faptul că acolo se realizează o
descompunere a opţiunii în alte opţiuni dependente de prima;
– Elementele selectate sau activate în cadrul unui meniu pot fi evidenţiate
prin anumite marcaje (checkbox-uri);
– Se recomandă evidenţierea opţiunilor ce vor duce la afişarea unor ferestre
pop-up cu (...);
– În funcţie de acţiunile curente asupra aplicaţiei, se va face o evidenţiere a
poziţiilor din meniuri ce pot fi activate faţă de cele care nu pot fi folosite
(enabled-disabled);
– Se recomandă o structurare a opţiunilor de meniu în mod logic – se preferă
aranjarea acestora în funcţie de frecvenţa apelării opţiunilor de către
utilizator;
– Oferirea a unor sisteme de meniuri diferenţiate (în funcţie de nivelul de
înţelegere a utilizatorului)
– Se realizează o grupare a opţiunilor în funcţie de similitudine (opţiuni care
realizează acţiuni asemănătoare asupra aplicaţiei vor fi grupate în aceeaşi
opţiune de meniu);
– Acces direct către opţiunile de bază sau cele des utilizate (se preferă
utilizarea combinaţiilor de taste, sau poate chiar o serie de pictograme ce
pot fi inserate pe bara de tassk-uri);
– Separarea opţiunilor care iniţiază acţiuni distructive (acestea ar trebui
grupate şi inserate într-un loc la care să nu aibă acces orice utilizator – se
recomandă obligarea utilizatorului la navigare folosind un număr
corespunzător de paşi);
– În anumite cazuri se pot introduce în meniu şi a unor opţiuni neprevăzute
în DFD.
4.2.3. Aspecte privind proiectarea interfeţelor web
Într-o lume a calculatoarelor domină de Internet, proiectarea corespunzătoare a
interfeţelor web a devenit scopul principal al celor care creează astfel de aplicaţii. Astfel,
se pune accent pe o grafică atractivă, o interfaţă cât mai uşor de utilizat. Totuţi, în foarte
multe cazuri se exagerează, obţinându-se pagini nerecomandate publicului larg. În ceea
ce urmează prezentăm nişte reguli ce ar trebui respectate în creare unei pagini web:
67
– Pentru a creşte vizibilitatea proprietarului respectivei pagini web se
recomandă includerea numelui şi a logo-ului firmei în fiecare pagină ce va
fi afişată;
– În cazul site-urilor complexe este obligatorie punerea la dispoziţia
utilizatorului a funcţiei de căutare;
– Scrierea unor antete şi titluri de pagină directe şi simple (care să explice
clar despre ce este vorba în pagina respectivă)
– Structurarea paginii astfel încât să faciliteze explorarea ei rapidă (de
exemplu – împărţirea unei liste în unităţi mai mici)
– Utilizarea hypertext-ului pentru a structura spaţiul de afişare într-o pagină
de început şi mai multe pagini secundare (pentru a se evita supraaglomerarea)
– Evitarea construirii unor pagini cu multe fotografii (pagina de prezentare
trebuie să fie deschisă cât mai repede)
– Utilizarea unor imagini miniaturale relevante (în locul imaginilor mari) –
astfel acele imagini se vor încărca mult mai repede, ducând la creşterea
gradului de satisfacţie a vizitatorului;
– Utilizarea de titluri sugestive pentru legături, astfel încât navigarea să se
realizeze într-un timp cât mai scurt;
– În cazul paginilor cu informaţii importante să se ofere facilităţi speciale de
accesare pentru utilizatorii cu diferite infirmităţi (ex: vedere slabă)
– Se recomandă păstrarea unei uniformităţi în conceperea interfeţei, datorită
faptului că utilizatorii se aşteaptă ca toate site-urile ce deservesc capitole
similare să poate fi accesate şi explorate în acelaşi mod.
4.2.4. Controlul datelor în interfeţele utilizator
Anumite interfeţe oferă utilizatorului posibilitatea să intervină asupra datelor
aflate într-o bază de date. Când spunem „intervină”, vrem să menţionăm că acel utilizator
final ar putea vizualiza date, şterge date, introduce sau modifica diferite date, desigur, în
funcţie de rolul atrinuit utilizatorului. În momentul în care interfaţa oferă suport pentru
vizualizarea şi ştergere date, iar utilizatorul are astfel de drepturi, atunci el va putea
acţiona asupra bazei de date fără a avea mari restricţii. Dar în momentul în care interfaţa
permite şi operaţii de adăugare sau modificare a datelor prin intermediul anumitor
controale aranjate pe un formular, iar utilizatorul are aceste drepturi, atunci trebui să
avem grijă să se respecte anumite reguli la nivelul datelor ce constiutuie obiectul acestor
acţiuni. Astfel, printre principalele mecanisme de control automat, la nivel de interfaţă
utilizator, ce se pot impune putem avea:
– Permiterea introducerii datelor folosind tipuri de dată diferite. În acest caz
putem avea date numerice, alfanumerice, date calendaristice, etc.
68
– Datele introduse trebuie să respecte un anume grad de verosimilitate. De
de exemplu, retragerea unei sume prea mari dintr-un cont bancar poate să
nu fie considerată plauzibilă;
– În anumite cazuri putem avea domenii restrânse pentru datele ce e doresc a
fi introduse/modificate. În acest caz se recomandă folosirea unor controale
specifice, care să permită selectarea acestor valori, în locul introducerii
lor. Printre controalele uzuale, ce pot fi folosite în acest caz, menţionăm
combobox-ul, listbox-ul, sau chiar checkbox-ul. Un exemplu concret ce
impune o astfel de situaţie ar putea fi întâlnit într-o aplicaţie ce permite
introducerea unor note studenţilor (notele fiind de la 1 la 10);
– Un alt mecanism de control ce poate fi impus în cadrul formularelor ar
puta fi depistarea datelor lipsă. Acest lucru presupune introducerea
obligativităţii completării acelor câmpuri cu date valide ce urmează a fi
stocate. Pentru a uşura etapa de completare cu date a acestor câmpuri, ele
sunt, de cele mai multe ori, semnalate în diferite moduri (de exemplu
putem avea caracterul „*” în faţa controlului utilizat pentru editare de tip
Text box).
– O altă variantă de control al datelor ce se introduc folosind interfaţa
utilizator este tehnica cifrei de control. Astfel, această tehnică presupune
existenţa unei legături între cifrele ce alcătuiesc şirul de caractere final. Un
exemplu de utilizare al acestei tehnici îl întâlnim chiar la CNP (ultima
cifră se calculează în funcţie de celelalte 12 caractere);
– Formatul datelor este destul de important în anumite cazuri. Pentru a
respecta acest format se definesc şabloane ce obligă utilizatorul să
introducă aceste date respectând anumite caracteristici. Exemple de astfel
de date preformatate pot fi datele calendaristice, numerele de telefon,
numere de înmatriculare, etc.;
– Anumite câmpuri sunt definite folosindu-se domenii restrânse. Pentru
acest lucru trebuie să limităm datele introduse de utilizator prin stabilirea
unor intervale de valori (de exemplu, notele de la examen pot fi între 1 şi
10);
– Numărul de caractere permis poate duce, de asemenea, la un control
ridicat al datelor introduse de utilizator. De exemplu, în cazul CNP-ului
putem obliga utilizatorul să introducă 13 caractere;
– Compararea datelor introduse cu cele stocate într-o bază de date. Acest
mecanism îl întâlnim destul de des la logarea utilizatorului într-o aplicaţie,
astfel userul şi parola acestuia se compară cu fiecare înregistrare dintr-un
tabel din baza de date.
69
4.3. Proiectarea logică a bazelor de date
4.3.1. Caracteristici generale
Într-un sistem informatic datele sunt modelate pe 3 nivele: conceptual, logic şi
fizic. Modelarea conceptuală presupune reprezentarea datelor independent de tehnologiile
specifice de stocare şi prelucrare a bazelor de date. Proiectarea logică a bazelor de date
este în strânsă legătură cu modelarea conceptuală a datelor, aceasta însemnând
reprezentarea modului de organizare a datelor, independent de tehnologiile specifice de
prelucrare a bazelor de date, fără să se înregistreze o preocupare anume referitoare la
calitatea modelelor datelor.
Principalele criterii de calitate utilizate în evaluarea modelului logic sunt:
• Completitudinea – modelul trebuie să cuprindă toate datele necesare generării
ieşirilor;
• Neredundanţa – modelul trebuie să fie format dintr-un set de tabele normalizate;
• Stabilitate şi flexibilitate:
– model stabil – eventualele modificări ale cerinţelor funcţionale nu
determină schimbarea structurii sale;
– model flexibil – uşurinţa extinderii cu impact minim asupra structurii
existente.
• Simplitate şi eleganţă – modelul trebuie să ofere o clasificare naturală şi elegantă
a datelor (Furnizori + Clienti = Parteneri, sau Facturiemise + Facturiprimite =
Facturi, etc.) .
Tabel 6 Exemplu de relaţie cu redundanţă crescută
cods nume_pren specializare an localitatecodddend data notacodpnume_pren_profcatedra localitate_prof telefon
1 Antipa George AF I Radauti 1 Economie 1 2/13/20135 1 Ion Pentelescu EAFTS Iasi 0232845294
1 Antipa George AF I Radauti 3 Bazele
Contabilitatii
6/13/20137 2 Mihai Maciuc DCFIE Suceava 0230174098
2 Ifrimescu Andrei AMS II Falticeni 2 Drept 2/13/20137 3 Ilie Irimescu APD Suceava 0230619402
2 Ifrimescu Andrei AMS II Falticeni 4 Statistica 2/13/20134 4 Ion Bratescu EAFTS Suceava 0230819472
3 Berar Mihai CIG III Suceava 3 Bazele
Contabilitatii
2/13/20139 2 Mihai Maciuc DCFIE Suceava 0230174098
Redundanţa prezentă în cadrul bazelor de date provoacă efecte negative. Ca să
înţelegem aceste efecte mai bine, prezentăm în cele ce urmează anomaliile ce pot să
apară la actualizarea bazelor de date. Prin actualizare a bazelor de date trebuie să
înţelegem toate operaţiunile ce duc la modificarea componenţei acestor baze de date.
Exemplele prezentate în cadrul acestor anomalii fac referire la datele din Tabel 6.
70
Anomalii de inserare
Apar în momentul în care dorim să introducem date în baza de date. Astfel,
întâmpinăm dificultăţi sau chiar ne este imposibil să introducem noi date în baza de date
De exemplu, ce s-ar întâmpla dacă s-ar dori introducerea unei noi note, dar nu se
cunoaşte profesorul care e titular la acea disciplină?
Anomalii la modificare
Întâmpinăm dificultăţi la modificarea valorii unui atribut care se repetă în mai
multe linii. Ca să înţelegem mai bine acest tip de anomalie să încercăm să răspundem la
întrebare: Se poate modifica catedra din cea de-a 5-a înregistrare? Dacă răspunsul ar fi
DA, şi am trece la această modificare, ar rezulta un tabel cu date incorecte. De ce? Pentru
că la înregistrarea a doua ar rămâne vechea catedra (deci vor fi două catedre diferite la
acelaşi profesor).
Anomalii la ştergere
Se manifestă atunci când prin ştergerea unei linii se pierd invonluntar informaţii
care prezintă interes pentru utilizatori. De exemplu, ce se întâmplă dacă se şterge a patra
înregistrare din tabel? Practic, prin această ştergere se pierde şi informaţiile despre
titularul disciplinei Statistică.
4.3.2. Simplificarea structurii datelor prin normalizare
Formele normale reprezintă scheme de relaţie echivalente obţinute prin
descompunerea unor scheme de relaţie în vederea eliminării redundanţei datelor şi
anomaliilor la adăugare, actualizare, ştergere înregistrări în baza de date.
Printre formele normale cunoscute enumerăm: FN1, FN2, FN3, FNBC, FN4,
FN5. În cele ce urmează vom trata pe scurt dor FN1, FN2 şi FN3.
Forma normală 1 (FN1)
O relaţie R este în prima formă normală dacă şi numai dacă toate atributele sale
iau numai valori atomice. Un atribut este atomic dacă el nu mai poate fi descompus în
alte atribute (la intersecţia fiecărei linii cu o coloană trebuie să existe întotdeauna o
valoare, niciodată un grup de mai multe valori).
Printre situaţiile care duc la încălcări ale FN1 avem:
 Prezenţa mai multor valori semnificative în acelaşi câmp;
 Prezenţa mai multor coloane reprezentând acelaşi tip de date/obiecte.
De asemenea, FN1 cere ca fiecare înregistrare să fie definită astfel încât să fie
identificată în mod unic.
A doua formă normală (FN2)
O relaţie R este în a doua formă normală (FN2), dacă este în FN1 şi orice atribut
neprim este total dependent faţă de orice cheie a relaţiei.
O relaţie aflată în FN1 se poate transforma în FN2 prin descompunerea ei,
rezultând relaţii pentru fiecare grup de dependenţe funcţionale.
71
Fie X şi Y atribute simple sau compuse în relaţia R. Se spune că Y este dependent
funcţional de X (X → Y) dacă fiecărei valori a atributului X îi este asociată exact o
valoare a atributului Y
Sau,
fiind date două tupluri în r, dacă valorile atributelor X concordă, atunci valorile
atributelor Y trebuie de asemenea să concorde (X şi Y pot fi seturi de atribute)
Tabel 7 Relaţia Studenţi, obţinută prin descompunerea relaţiei redundante
cods nume_pren specializarean localitate
1 Antipa
George
AF I Radauti
2 Ifrimescu
Andrei
AMS II Falticeni
3 Berar Mihai CIG III Suceava
Tabel 8 Relaţia Discipline, obţinută prin descompunerea relaţiei redundante
codddend codpnume_pren_profcatedralocalitate_proftelefon
1 Economie 1 1 Ion Pentelescu EAFTS Iasi 0232845294
3 Bazele
Contabilitatii
2 Mihai Maciuc DCFIE Suceava 0230174098
2 Drept 3 Ilie Irimescu APD Suceava 0230619402
4 Statistica 4 Ion Bratescu EAFTS Suceava 0230819472
Tabel 9 Relaţia Note, obţinută prin descompunerea relaţiei redundante
cods codd data nota
1 1 2/13/2013 5
1 3 6/13/2013 7
2 2 2/13/2013 7
2 4 2/13/2013 4
3 3 2/13/2013 9
A treia formă normală (FN2)
O relaţie R este în a treia formă normală dacă este în FN2 şi nici un atribut neprim
nu este funcţional dependent faţă de un alt atribut neprim al relaţiei
Dependenţă funcţională tranzitivă: Fie X,Y,Z trei atribute a unei relaţii; dacă în
cadrul relaţiei sunt valabile dependenţele funcţionale X->Y şi Y->Z, atunci se va verifica
şi dependenţa X->Z (Z este dependent tranzitiv de X)
În exemplele noastre avem dependenţele funcţionale codd -> codp şi codp ->
nume_pren_prof.
Tabel 10 Relaţia Discipline
codddend codpnume_pren_profcatedralocalitate_proftelefon
1 Economie 1 1 Ion Pentelescu EAFTS Iasi 0232845294
3 Bazele
Contabilitatii
2 Mihai Maciuc DCFIE Suceava 0230174098
2 Drept 3 Ilie Irimescu APD Suceava 0230619402
72
4 Statistica 4 Ion Bratescu EAFTS Suceava 0230819472
Tabel 11 Relaţia Discipline1 obţinută din descompunerea relaţiei Discipline
codd dend codp
1 Economie 1 1
3 Bazele
Contabilitatii
2
2 Drept 3
4 Statistica 4
Tabel 12 Relaţia Profesori obţinută din descompunerea relaţiei Discipline
codpnume_pren_profcatedralocalitate_proftelefon
1 Ion Pentelescu EAFTS Iasi 0232845294
2 Mihai Maciuc DCFIE Suceava 0230174098
3 Ilie Irimescu APD Suceava 0230619402
4 Ion Bratescu EAFTS Suceava 0230819472
Teste rezolvate
1. Care dintre următoarele afirmaţii nu este adevarată în cazul unui formular?
a. Este document economic, având date predefinite, putând fi citit şi/sau
printat A
b. Datele afişate sunt cunoscute sub numele de constante, iar cele ce vor fi
completate sunt denumite variabile
c. Este document primar care conţine date predefinite, cărora li se adaugă
alte date, ce vor fi completate în rubrici special rezervate
d. Poate conţine introducere, instrucţiuni, partea principală şi concluziile
2. După gradul de detaliere, ieşirile unui sistem informatic pot fi:
a. Curente
b. De sinteză A
c. Programate
d. Externe
3. Pentru a realiza un raport de sinteză folosind SQL, este obligatorie folosirea:
a. ORDER BY
b. WHERE
c. GROUP BY A
d. UNION
4. Într-un formular o căsuţă combinată (Combobox):
a. Poate fi utilizată pentru titluri, explicaţii sau diverse indicaţii
b. Conţine o listă de valori din care poate fi selectată numai una A
c. Este asemănătoare butonului de opţiune
d. Permite separarea funcţionalităţii unui formular în mai multe părţi
5. Într-un formular, o căsuţă listă (ListBox):
a. Însoţesc căsuţele text, dar nu numai
b. Pot fi utilizate pentru titluri , explicaţii sau diverse indicaţii
73
c. Poate avea mai multe linii A
d. Conţine o listă de valori din care poate fi selectată numai una
6. Pentru o mai bună proiectare a unei interfeţe web nu se recomandă:
a. Utilizarea unor imagini de dimensiuni mari A
b. Utilizarea de titluri sugestive pentru legături
c. Uniformitatea în conceperea interfeţei
d. Scrierea unor antete şi titluri de pagină directe şi simple
Întrebări
1. Ce este un raport?
2. Cum se clasifică ieşirile din punct de vedere al frecvenţei?
3. Care sunt caracteristicile unui TextBox?
4. Care sunt caracteristicile CheckBox-ului?
5. Când poate fi o relaţie în FN3?
74
5. Proiectarea fizică a sistemelor informatice
5.1. Proiectarea fizică a bazelor de date şi fişierelor
Proiectarea fizică a bazelor de date transformă schema logică a bazei de date întrun
set de specificaţii tehnice privind stocarea şi accesarea datelor, care să poată fi
implementate într-un anumit SGBD şi care să asigure confidenţialitatea, integritatea,
controlabilitatea şi performanţele dorite în accesarea datelor. Rezultatele acestei etape
sunt utilizate de programatori în faza de implementare.
5.1.1. Aspecte generale ale proiectării fizice
Obiective generale ce se doresc a fi atinse în această etapă constau în:
 Transpunerea schemei logice a datelor într-un model care să poată fi
implementat în SGBD-ul ales (se are în vedere: tipul de date pentru fiecare
atribut, definirea cheilor primare, definirea restricţiilor, etc.);
 Determinarea unei structuri optime de stocare a datelor (care să ofere
performanţe acceptabile în ce priveşte accesarea datelor şi spaţiul utilizat);
 Definirea măsurilor de securitate care vor fi implementate.
5.1.2. Analiza operaţiunilor de accesare a datelor
Din punct de vedere fizic, când vorbim despre accesare a datelor avem de-a face
cu 2 operaţiuni principale: scriere şi citirea. Când vorbim de operaţia de scriere într-o
bază de date vorbim despre adăugare (introducerea unei noi înregistrări în baza de date),
modificare (suprascrierea anumitor câmpuri de baza de date) şi ştergere (suprascriere cu o
înregistrare nulă). Citire datelor se realizează fie prin instrucţiuni SQL SELECT, fie cu
ajutorul unei interfeţe grafice (care de cele mai multe ori generează o instrucţiune SQL
SELECT).
Printre indicatorii ce trebuie avuţi în vedere în momentul proiectării fizice a unei
baze de date, pentru a se obţine performanţe ridicate, am putea lua în considerare număr
de operaţiuni/unitate de timp, care ar trebuie să fie cât mai mare, dar şi timpul de
răspuns/operaţie de acces, care ar trebui să fie cât mai mic. Un alt aspect de care trebuie
să ţinem cont este legătura dintre viteza de scriere şi cea de citire. Astfel, în cele mai
multe medii o scriere rapidă, poate determina o citire lentă, de aceea se încearcă o
echilibrare a acestei balanţe, în funcţie de necesităţi.
75
5.1.3. Proiectarea securităţii fişierelor şi bazelor de date
În ultima perioadă se observă o continuă dezvoltare a aplicaţiilor care pot fi
accesate la distanţă. Toate acest aplicaţii au, în cele mai multe cazuri, baze de date ce
constituie suportul pentru extragerea de informaţiile necesare unui anumit utilizator.
Toate aceste aplicaţii sunt contruite astfel încât să ofere un grad ridicat de stabilitate, de
siguranţă pentru utilizatorii lor. Totuşi, indiferent de gradul de siguranţă oferit, se
recomandă implemetarea unor mecanisme care să ajute la reconstituirea datelor în urmă
anumitor probleme neprevăzute ce ar putea să apară. O modalitate de reconstituire a
datelor o reprezintă implementare back-upului, operaţie ce presupune o „reconstituire
înainte”, adică o salvare, la momente prestabilite, sau nu numai, a datelor dintr-o bază de
date, pentru a putea fi refolosite în momentul în care, datorită unei defecţiuni de orice fel,
se pot pierde date din baza de date originală. „Reconstituirea înapoi” este un alt
mecanism care asigură coerenţa bazelor de date, ea presupunând reluarea efectului invers
al tranzacţiilor până la ultima tranzacţie eronată, acest lucru petrecându-se în momentul
apariţiei unei erori într-o mulţime de operaţiuni ce afectează o bază de date şi sunt legate
între ele.
Criptarea datelor reprezintă un alt mecanism ce trebuie tratat în momentul
proiectării sistemelor informatice. Acest proces presupune asigurarea transformării
datelor într-o formă neinteligibilă pentru ceilalţi receptori. Foarte multe persoane
confundă criptarea cu un alt proces presupune înlocuirea unui mesaj complet cu un
anumit simbol, proces denumit codificare. Spre deosebire de un cod, un cifru presupune
existenţa unei corespondenţe biunivoci, unu-la-unu (mesajul în clar se transformă într-un
text criptat).
5.1.4. Demersul proiectării fizice a bazelor de date
Principalele operaţii ce se impun a fi efectuate în etapa de proiectare fizică a
bazelor de date sunt:
• Alegerea SGBD-ului care va fi folosit pentru crearea bazei de date. În cadrul
acestei etape se va ţine cont de factori economici, organizaţionali, etc.;
• Transpunerea schemei logice a bazei de date - alegere tipurilor de date ce se vor
utiliza pentru fiecare câmp în parte, restricţiile de integritate ce se impun a fi
respectate, etc.;
• Analiza interogărilor şi tranzacţiilor – scopul final al acestui pas fiind optimizarea
acestor elemente în vederea obţinerea unor timpi de răspuns cât mai mici;
• Îmbunătăţirea performanţelor prin alegerea opţiunilor de organizare fizică a
datelor – se referă la organizarea fişierelor, crearea de indecşi etc.;
• Denormalizare – proces opus normaţizării care se utilizează în funcţie de
necesităţi;
• Proiectarea măsurilor de securitate – măsuri considerate vitale atât în cazul
bazelor de date on-line, dar şi pentru cele off-line;
76
• Analiza datelor statistice privind operaţiunile de acces – analize ce pot fi utilizate
pentru diverse optimizări, dar şi pentru crearea de rapoarte ce ar putea fi des
accesate de către utilizatorul normal.
5.2. Proiectarea programelor şi a procedurilor
5.2.1. Aspecte generale ale proiectării programelor şi procedurilor
Această etapă din viaţa oricărui sistem este realizată de către proiectantul de
software. O proiectarea necorespunzătoare a acestor componente va determina apariţia
unui număr mare de erori pe parcursul utilizării sistemului informatic, erori ce ar putea
obliga deţinătorul sistemului să recurgă fie la o reproiectare a anumitor module, fie la
crearea unui sistem informatic nou. Pentru a înţelege mai bine această etapă vom defini,
în continuare, termeni de bază ce sunt utilizaţi în cadrul acestei etape.
Programul este o entitate ce poate fi executată pe un calculator. De asemenea,
poate fi considerat un mijloc de comunicare cu calculatorul pentru rezolvarea unei
probleme. El reprezintă o descriere a unui algoritm şi a datelor asociate în vederea
execuţiei pe calculator, sau poate fi considerat chiar o realizare a unei funcţii f (datele de
intrare formând domeniul, iar datele de ieşire reprezentând codomeniul acestuia).
O instrucţiune poate fi definită ca fiind o operaţiune elementară ce poate fi
executată de un calculator.
Modulul reprezintă unitatea structurală de sine stătătoare, fie program, fie
subprogram, ce apare ca o colecţie de intrucţiuni.
Funcţia modulului face referire la transformările realizate asupra datelor în urma
execuţiei acestuia . Poate fi considerată ”cutia neagră” a modului, deoarece ea nu priveşte
componentele interne (instrucţiunile şi logica), ci doar intrările, ieşirile şi rolul modulului.
Logica modulului descrie prelucrările care au loc în interiorul modulului (“cutia
albă”). De obicei, în etapa de proiectare aceasta se reprezintă prin scheme logice,
pseudocod, etc.
Interfeţele – fac referire la structurile de date transferate între module. Practic,
reprezintă conexiunile sau cuplajele dintre module.
Având definite aceste elemente, putem împărţi proiectarea programelor şi
procedurilor în proiectare arhitecturală, cea care se ocupă de funcţia modulului şi
interfeţe; şi proiectare a logicii modulelor.
5.2.2. Structuri de control ale programelor
Structurile de control al logicii cunoscute şi sub numele de structuri de control
fundamentale, reprezintă un set minim, dar şi necesar, de reguli prin care să se controleze
procesul de activare a componentelor de prelucrare.
O clasificare a acestor strucutri este prezentată în cele ce urmează:
• Secvenţa – sau structura secvenţială (liniară)
77
i=3 //i ia valoarea 3
i=i+2 //i va lua valoarea 5
i=i-3 //i va lua valoarea 3
i=i*0 //i va lua valoarea 0
afiseaza i-va determina afişarea valorii 0
• Selecţia – sau structură alternativă
– Simplă
• Cu două ramuri (IF-THEN-ELSE)
i=8 //i va lua valoarea 8
i=i-2 //i va lua valoarea 6
if i>5 then //condiţia este adevărată, deoarece 6 >5
i=9 //i ia valoarea 9
else //aceasta secventa nu se executa, deoarece s-a executat IF
i=i-2
endif
i=i-3//i ia valoarea 6
afiseaza i-va determina afişarea valorii 6
• Cu o ramură vidă (IF-THEN)
Exemplu:
i=0// i ia valoarea 0
i=i+2//i ia valoarea 2
if i>5 then//IF nu se executa, deoarece nu-I adevarata conditia
i=9
endif
i=i+0 //i ia valoarea 2
afiseaza i-va determina afişarea valorii 2
– Generalizată
• (CASE-OF)
• Iteraţia (repetiţia) - sau structură repetitivă
– Condiţionată anterior (WHILE-DO)
i=5
i=i-2
while i>5 do
i=9
wend
i=i+3
afiseaza i-va determina afişarea valorii 6
78
– Condiţionată posterior (DO-UNTIL)
i=3
i=i+2
do
i=3 -va determina blocarea secvenţei, deoarece nu va putea ieşi din
bucla do – condiţia i>5 nu e adevărată
until i>5
i=i+3
afiseaza i
5.3. Proiectarea sistemelor informaţionale distribuite
Un sistem distribuit ce prelucrează date presupune existenţa a două sau mai multe
sisteme independente de prelucrare a datelor, ce sunt numite noduri, interconectate într-o
configuraţie de reţea. O procesare distribuită presupune existenţa datelor şi programelor
pe diferite calculatoare, rezultatul final fiind obţinut printr-o colaborare a acestora.
5.3.1. Aspecte generale privind dezvoltarea sistemelor distribuite
Într-o definiţie dată de Tanenbaum şi van Steen, un sistem distribuit reprezintă “o
colecţie de calculatoare independente percepute de utilizatori ca un singur sistem
coerent”. Din punct de vedere harware calculatoarele componente ale unui sistem distribuit
sunt autonome, iar din punct de vedere software toţi utilizatorii au impresia că lucrează
cu un singur sistem.
Coulouris ş.a. a definit sistemele distribuite ca fiind acele sisteme “în care
componentele hardware şi software, localizate într-o reţea, comunică şi îşi coordonează
acţiunile lor prin transmiterea de mesaje”.
Aceste sistem informatice se împart, în funcţie de modul de prelucrare a datelor şi
modul de distribuire a datelor, în:
– Sisteme cu prelucrări distribuite
– Sisteme cu date distribuite
– Sisteme mixte
Internetul este cel mai mare sistem distribuit din lume. Acest serviciu prezintă
următoarele caracteristici:
– Cea mai vastă colecţie de calculatoare autonome, de tipuri diferite,
interconectate;
– Programele rulează pe calculatoare diferite şi interacţionează prin
schimbul de mesaje;
– Localizarea resurselor hard şi soft este ascunsă utilizatorilor;
79
– Serviciile disponibile pot fi utilizate în acelaşi mod de către toţi
utilizatorii;
– Setul de servicii poate fi extins în orice moment;
– Aceeaşi pagină poate fi accesată de mai mulţi utilizatori
5.3.2. Avantajele şi dezavantajele sistemelor distribuite
Astfel de sisteme prezintă atât avantaje, cât şi dezavantaje. Avantajele prezentate
de către sistemele informatice distribuite sunt:
– Creşterea disponibilităţii şi siguranţei resurselor (observabil în cazul
apariţiilor unor disfuncţionalităţi);
– Reducerea costurilor de comunicaţie şi a limitelor specifice mediilor de
comunicaţie (influenţe pozitive asupra traficului de reţea);
– Flexibilitatea dezvoltării sistemelor distribuite (determinat de dezvoltarea
firmei);
– Reflectarea schimbărilor din mediile de afaceri (alinierea cu structura
organizatorică a firmei - evident la multinaţionale);
– Timpi de răspuns mai buni;
– Independenţa faţă de tehnologiile unui singur furnizor.
Dezavantaje ce apar în cazul acestor sisteme sunt:
– Complexitatea mare;
– Sporirea dificultăţilor în controlul resurselor informaţionale;
– Probleme legate de asigurarea integrităţii datelor;
– Sporirea dificultăţilor în testarea şi detectarea erorilor.
5.3.3. Modelul client-server
Sistemele client-server pot fi considerate ca un caz special al sistemelor
distribuite. Mai exact, un sistem client-server este un sistem în care clienţii sunt
consumatorii de servicii, iar serverele sunt furnizorii de servicii. Acest model reprezintă o
modalitate de dezvoltare a aplicaţiilor distribuite, aplicaţii care sunt descompuse într-un
număr de funcţii server, executate pe una sau mai multe platforme hardware, care
furnizează servicii comune unui număr de funcţii client, rulate pe platforme hardware
diferite. În cadrul unor astfel de sisteme componentele server-client comunică prin
schimb de mesaje de tip cerere-răspuns. Relaţia de client-server este una de colaborare,
nu ca în cazul master-slave, unde am o relaţie de subordonare.
Din punct de vedere arhitectural, în cazul acestui model avem o organizare pe trei
straturi:
80
• Gestiunea interfeţei utilizator – priveşte dialogul cu utilizatorii;
• Logica aplicaţiei – cuprinde operaţiile de prelucrare;
• Gestiunea datelor – rezolvă cererile de date.
5.3.4. Particularităţi în proiectarea bazelor de date distribuite
Principiul fundamental al bazelor de date distribuite a fost enunţat de către C.J.
Date. Astfel, el spune că ”o bază de date distribuită ar trebui să apară utilizatorilor exact
ca o bază de date nedistribuită”.O bază de date distribuită poate fi definită ca o colecţie
de date integrate din punct de vedere logic, dar distribuite fizic pe mai multe platforme,
conectate printr-o reţea, în condiţiile asigurării transparenţei naturii distribuite a
datelor[3].
Principiul fundamental de mai sus duce la o serie de reguli sau de obiective
subsidiare, în număr de douăsprezece:
1. Autonomia locală – nodurile să fie autonome, adică toate operaţiile efectuate pe
acel nod să fie controlate de el (în practică mai greu de atins);
2. Sistemul nu trebuie să se bazeze pe un nod central (legat de primul obiectiv) – sar
transforma în sistem centralizat;
3. Funcţionare neîntreruptă;
4. Independenţa (transparenţa) localizării – nu este necesar ca utilizatorul să
cunoască nodurile pe care sunt stocate datele;
5. Independenţa (transparenţa) fragmentării;
6. Independenţa (transparenţa) replicării;
7. Prelucrarea distribuită a interogărilor – vizează optimizarea interogărilor
distribuite ;
8. Gestiunea tranzacţiilor distribuite;
9. Independenţa hardware – putem avea calculatoare de diferite tipuri;
10. Independenţa sistemului de operare – putem avea platforme software diferite;
11. Independenţa reţelei – putem avea mai multe tipuri de reţele de comunicaţie;
12. Independenţa sistemului de gestiune a bazei de date – putem avea sisteme
eterogene, două sau mai multe SGBD-uri.
O operaţie importantă în cadrul sistemelor distribuite se numeşte replicarea
datelor. Aceasta reprezintă procesul de copiere şi întreţinere a obiectelor specifice unei
baze de date (tabele). Acest proces presupune copierea datelor pe mai multe noduri din
cadrul sistemului distribuit. Această copiere aduce anumite avantaje unor astfel de
sisteme, printre care putem aminti de creşterea disponibilităţii datelor, îmbunătăţirea
performanţelor de accesare a datelor, acordarea posibilităţii de efectuare de operaţiuni cu
o parte a bazei de date în condiţiile deconectării de la baza de date centrală, precum şi
reducerea încărcării reţelei.
Replicarea poate fi de două feluri: asincronă şi sincronă. Relicarea asincronă
presupune memorarea datelor şi transmiterea lor mai departe, către alte noduri la anumite
intervale de timp (pentru stocarea mesajelor se folosesc anumite cozi de aşteptare).
81
Replicarea sincronă presupune propagarea imediată (în timp real) a actualizărilor către
celelalte noduri ce ar trebui să conţină astfel de informaţii.
În procesul de replicare a datelor în cadrul sistemelor distribuite pot să apară o
serie de conflicte. Astfel, putem avea conflicte la update, în momentul în care încercăm
modificarea aceleiaşi informaţii pe două noduri diferite; la insert, de exemplu, atunci
când sunt obligaţi să stabilim o valoare validă pentru cheia primară; dar şi la delete, de
exemplucând încercăm să ştergem informaţia de pe un nod, încercând, în acelaşi timp să
actualizăm aceeaşi informaţie de pe alt nod.
Pentru evitarea unor astfel de conflicte putem recurge la limitare numărului de
noduri pe care se pot face actualizări simultane, utilizarea secvenţelor pentru evitarea
conflictelor de unicitate a cheilor, precum şi înlocuirea operaţiunii de ştergere cu
operaţiunea de marcare a ştergerii.
Teste rezolvate
1. Nu este un tip de modelare a datelor:
a. Modelare relaţională A
b. Modelare logică
c. Modelare fizică
d. Modelare conceptuală
2. Ultima etapă întâlnită în proiectarea bazelor de date este:
a. Proiectarea fizică A
b. Proiectarea logică
c. Proiectarea sistematică
d. Proiectarea conceptuală
3. Din punct de vedere fizic, operaţiunea de modificare este o operaţiune de:
a. Scriere A
b. Adăugare
c. Ştergere
d. Citire
4. Structura alternativă cu o ramură vidă este de forma:
a. DO-UNTIL
b. WHILE-DO
c. IF-THEN A
d. IF-THEN-ELSE
5. Structura repetitivă condiţionată posterior este de forma:
a. DO-UNTIL A
b. WHILE-DO
c. IF-THEN
d. IF-THEN-ELSE
6. Avem secvenţa de cod (i=3 i=i+2 do i=9 until i>5 i=i+3 afiseaza i). Valoarea
afişată va fi:
a. 9
b. 12 Α
c. 8
82
d. Programul se blochează
7. Avem secvenţa de cod (i=??? i=i+3 do i=10 until i>5 i=i-3 afiseaza i). Ce
valoare trebuie să avem în locul ??? pentru ca rezultatul afişat să fie 7:
a. 10
b. Orice valoare Α
c. 8
d. Orice valoare am avea programul se va bloca
8. Avem secvenţa de cod (i=3 i=i+2 while i>2 do if i=3 then i=0 endif i=i-5 wend
i=i+3 afiseaza i). Valoarea afişată va fi:
a. -2
b. 3 A
c. 1
d. Programul se blochează
9. Avem secvenţa de cod (i=0 i=i+6 if i>5 then do i=9 until i<9 endif i=i+3
afiseaza i). Valoarea afişată va fi:
a. 9
b. 12
c. 6
d. Programul se blochează A
10. Avem secvenţa de cod (i=3 i=i+2 if i>5 then afiseaza i endif i=i+3 afiseaza i).
Valoarea afişată va fi:
a. 5 8
b. 5
c. 8 A
d. 8 8
11. Avem secvenţa de cod (i=3 i=i+2 while i>5 do afiseaza i wend i=i+3 afiseaza
i). Valoarea afişată va fi:
a. 5 8
b. 5 5 8
c. 8 A
d. Programul se blochează
12. Nu este considerat un avantaj al unui sistem distribuit:
a. Creşterea disponibilităţii şi siguranţei resurselor
b. Complexitatea sistemelor distribuite A
c. Flexibilitatea sistemelor distribuite
d. Independenţa faţă de tehnologiile unui singur furnizor
13. În modelul client-server avem
a. Relaţie de coordonare
b. Relaţie master-slave
c. Relaţie de colaborare A
d. Relaţie condiţionată
14. Care dintre următoarele afirmaţii nu reprezintă un avantaj al replicării datelor?
a. Creşterea disponibilităţii datelor
b. Îmbunătăţirea performanţelor de accesare a datelor
c. Efectuarea de operaţiuni cu o parte a bazei de date în condiţiile
deconectării de la baza de date centrală
83
d. Creşterea încărcării reţelei A
15. Ce se înţele prin replicare sincronă?
a. Înregistrare locală imediată a efectelor unei tranzacţii
b. Folosirea cozilor de aşteptare în scopul propagării tranzacţiilor
c. Propagarea imediată a actualizărilor către celelate noduri ce conţin o copie
a datelor A
d. Transmiterea efectelor tranzacţiilor către celelate noduri la anumite
intervale de timp
Întrebări
1. Care este ultima etapă din cadrul proiectării bazelor de date?
2. Care este forma structurii alternative cu două ramuri?
3. Enunţaţi principiul fundamental al bazelor de date distribuite.
84
6. Securitatea în cadrul sistemelor informatice
6.1. Securizarea accesului la sistemele informatice
Scopul fundamental al securității informației constă în crearea unui anumit nivel
protecție a unei organizații luate în calcul în fața eventualelor atacuri, fie voluntare, fie
involuntare, care ar putea afecta informații, părți a sistemelor informatice, sau chiar părți
ce țin de instrumentele de comunicație electronică din cadrul organizației. Activele
informaționale, fie ele stocate, prelucrate, partajate, transmise sau extrase de pe un suport
electronic trebuie să fie protejate de toate amenințările care pot duce la distrugerea,
divulgarea, sau chiar ascunderea lor(cum ar fi transformarea într-un tipar indescifrabil).
În orice moment informația trebuie să fie disponibilă (accesul utilizatorilor abilitați să fie
garantat în anumite condiții bine determinate de timp și perfomanță), să fie caracterizată
prin integritate (exactitate, nealterată), să fie confidențială (prin stabilirea unor reguli
utilizate în accesarea ei), dar și ușor de controlat (prin garantarea trasabilității acesteia).
Referitor la partea de securitatea a informațiilor și nu numai, în 2013 a fost adoptat de
către Uniunea Europeană un regulament care preciza: „În sensul prezentului regulament,
prin „securitatea rețelelor și a informațiilor” se înțelege capacitatea unei rețele sau a unui
sistem informatic de a rezista, la un nivel de încredere dat, la evenimente accidentale sau
la acțiuni ilegale sau răuvoitoare care compromit disponibilitatea, autenticitatea,
integritatea și confidențialitatea datelor stocate sau transmise și a serviciilor conexe
oferite sau accesibile prin respectivele rețele și sisteme.”[12]
Managementul securității informației reprezintă un proces prin care se asigură
ducerea la îndeplinire a tuturor activităților referitoare la partea de gestionare a
informației și a sistemelor informatice astfel încât să fie asigurat un anumit nivel de
protecție, în timp și spațiu, considerat adecvat pentru organizație. Obiectivul principal al
acestui management constă în prevenirea compromiterii patrimonului organizației datorat
apariției riscurilor din domeniul IT, dar și recuperarea rapidă a pierderilor ce apar ca
urmare a manifestării acestor riscuri. Chiar dacă ar fi să privim din punctul de vedere
echipamentelor tehnice pe care le utilizăm în securitatea informației, nu putem exclude și
contribuția viziunii manageriale la stabilirea normelor privind accesul și controlul
accesului la sistemele informatice existente într-o organizație.
Controlul accesului într-un sistem informatic este implementat în scopul reducerii
riscului la care sunt supuse aceste sisteme și pentru eliminarea eventualelor pierderi
apărute ulterior. Ținând cont de aceste precizări, putem spune că în cadrul sistemelor
informatice, acest control ar putea fi de mai multe feluri[13]: un control preventiv, unul
detectiv și unul corectiv. Controlul preventiv al accesului într-un sistem informatic are ca
scop preîntâmpinarea apariției unor incidente, probleme, evenetuale atacuri în cadrul
acestui sistem. Cel de-al doilea tip de control, și anume cel detectiv, presupune
descoperirea unor manifestări ciudate în cadrul sistemului, iar ultimul, cel corectiv, este
folosit pentru readucerea la normalitate a sistemului după anumite incidente la care a fost
expus (refacerea datelor, eliminarea problemelor apărute,etc.).
Ținând cont de modul în care se execută acest control de acces la sistem, am putea
spune că întâlnim controale bazate pe politici, diverse proceduri, verificări generale,
supravegheri diverse. Acestea sunt specifice controlului administrativ. Dacă ne gândim la
85
impunerea unor restricții legate de accesarea sistemului (cum ar fi sisteme de criptare,
carduri de acces, liste de control etc.) vorbim de un control logic sau tehnic. Ultimul tip
de control pe care îl putem întâlni este controlul fizic, și anume cel care ar putea
presupune existența unor gărzi de pază și protecție, diverse sisteme de închidere a ușilor,
protecția cablurilor, etc.
Controlul accesului unui subiect (o entitate activă, cum ar fi o persoană fizică sau
proces) la un obiect (o entitate pasivă, cum ar fi un fișier) implică configurarea unui set
de reguli. Aceste reguli pot fi clasificate în trei categorii sau modele[13]:
• Controlul obligatoriu a accesului (MAC – Mandatory access control).
Autorizarea accesului unui subiect la un obiectul depinde de etichete, care
indică nivelul de autorizare a subiectului și clasificarea sau senzitivitatea
obiectului. De exemplu, armata clasifică documentele drept neclasificate,
confidențiale, secrete și top-secret. În mod similar, o persoană poate primi o
autorizare de confidențial, secret sau top-secret și poate avea acces la
documente clasificate la același nivel sau sub nivelul ei de autorizare
specificat. Astfel, un individ cu o autorizare de „Secret” poate avea acces la
documente secrete și confidențiale cu o restricție. Această restricție este
aceea că individul trebuie să aibă nevoie de accesul la aceste documentele
clasificate. De aceea documentele trebuie să fie utilizate de către persoana
respectivă pentru completarea unei sarcini atribuite. Chiar dacă individul are
un anumit nivel de autorizare a accesului, dacă nu este necesar ca acesta să
cunoască anumite informații, nu ar trebui să i se permită accesul la aceste
informații. Controlul accesului bazat pe reguli este un tip de control
obligatoriu a accesului, deoarece regulile respective determină dacă accesul
poate avea loc sau nu.
• Controlul discreționar al accesului (DAC - Discretionary Access Control).
Subiectul este autorizat cu anumite limitări ce specifică care dintre obiecte
sunt accesibile. De exemplu, se pot utiliza liste de control pentru acces. O
listă de control pentru acces (ACL) este o listă în care avem precizate ce
utilizatori au anumite privilegii pentru o anumită resursă. De exemplu, avem
o listă tabulară ce va arăta subiecții sau utilizatorii care au acces la un
obiect, de exemplu un fișier, și ce privilegii au în ceea ce privește fișierul
respectiv. Un control al accesului triplu pune față în față utilizatorul,
programul și fișierul cu privilegiile de acces corespunzătoare fiecărui
utilizator. Acest tip de control al accesului este utilizat în situații locale,
dinamice, în care subiecții trebuie să aibă discreția de a specifica ce resurse
sunt permise anumitor utilizatori. Atunci când un utilizator, cu anumite
limitări, are dreptul de a modifica controlul accesului la anumite obiecte,
acesta control este denumit controlul accesului discreționar bazat pe
utilizator. Un control al accesului identity-based este un tip de control
discreționar bazat pe identitatea unei persoane. În unele cazuri, se utilizează
o abordare hibridă, care combină caracteristicile control acces discreționar
bazat pe utilizator și cel bazat pe identitate.
• Control non-discreționar al accesului. O autoritate centrală determină ce
subiecți pot avea acces la anumite obiecte în funcție de politica de securitate
a organizației. Controlul accesului poate fi bazat pe rolul individului în
86
organizație (bazat pe rol) sau pe responsabilitățile și îndatoririle lui (bazat
pe sarcini). Într-o organizație unde există modificări frecvente de personal,
controlul non-discreționar al accesului este util, deoarece acesta se bazează
pe rolul individului în cadrul acesteia. Aceste reguli de acces nu trebuie
modificate ori de câte ori o nouă persoană preia acel rol.
Printre componentele de bază a controlului accesului într-un sistem informatic
putem aminti identificarea și autentificarea. Identificarea este actul unui utilizator de
conectare la un sistem, de obicei, folosind o interfață grafică corespunzătoare. Procesul
de identificare presupune responsabilizarea utilizatorului pentru acțiunile sale din sistem.
Autentificarea este o verificare a validității utilizatorului, apărând, de obicei, lîn
momentul utilizării unei parole de către un utilizator, în încercarea de conectare la un
anumit sistem. Autentificarea se bazează pe analiza următorilor factori:
• Ceva ce utilizatorul cunoaște (Knowledge factors), cum ar fi un cod PIN,
username, sau o parolă. Când se utilizează parole, este important ca acestea
să puternice (sigure). O parolă puternică are un amestec de litere mari,
minuscule, numere și caractere speciale. În trecut, specialiștii în securitate
recomandau ca parolele să aibă cel puțin opt caractere. Totuși, cu puterea
din ce în ce mai mare a softurilor de „spart” parole, frecvent auzim
profesioniști care recomandă parole mai lungi. De exemplu, multe
organizații obligă ca parolele de administrator să aibă cel puțin 15 caractere.
Parolele mai lungi sunt mai greu de reținut, dacă nu sunt introduse având în
spate o anumită logică. De exemplu, o frază de genul „Securitatea crește
succesul” poate deveni o parolă de la „S3cur17a73aCr3$73Succ3$ul”.
Observați că fiecare cuvânt începe cu majusculă, fiecare literă mică „s” este
schimbată în $, fiecare literă mică „e” este schimbată în 3, fiecare caracter
„i” este înlocuit cu „1” și spațiile sunt eliminate. Parola este mai ușor de
reținut, însă este foarte complexă. Cu toate acestea, dacă un utilizator este
obligat să-și amintească o parolă lungă fără niciun sens, cum ar fi „19qd9h l
7cpw #”, este mult mai probabil să noteze parola într-o altă locație, slăbind
securitatea. Parolele nu ar trebui să includă date personale precum numele
unui utilizator sau id-ul acestuia. În plus, o parolă nu trebuie să fie un
cuvânt care poate fi găsit într-un dicționar. Anumite atacuri utilizează o
bază de date cu cuvinte similare cu un dicționar, încercând toate cuvintele
din acea bază de date pentru o potrivire. Putem să afirmăm, pe bună
dreptate, că în mediul online atacatorii au acces chiar și la dicționare în alte
limbi. Cu alte cuvinte, o parolă care folosește un cuvânt dintr-o altă limbă
este la fel de simplu de spart, precum o parolă folosită în limba maternă a
utilizatorului.
• Ceva ce utilizatorul posedă (Possession factors), cum ar fi un card smart, un
token. Cardul inteligent (smart) este un card de dimensiunea cardului de
credit care are un certificat încorporat utilizat pentru identificarea titularului.
Utilizatorul poate introduce cardul într-un cititor de carduri inteligente
pentru a se autentifica. Cardurile inteligente sunt utilizate în mod obișnuit
cu un PIN care oferă un plus de siguranță sistemului. Cu alte cuvinte,
utilizatorul trebuie să aibă ceva (cartela inteligentă) și să știe ceva (codul
PIN). Un token este un dispozitiv portabil cu un afișor (LED-ul fiind din ce
87
în ce mai utilizat) care afișează un număr, iar numărul este sincronizat cu un
server de autentificare. Numărul afișat pe token se schimbă regulat, cum ar
fi la fiecare 60 de secunde, iar serverul de autentificare cunoaște întotdeauna
numărul afișat în prezent. De exemplu, la 15:54, numărul afișat pe LED
poate fi 534375 și, în același timp, serverul știe că numărul este 534375. Un
minut mai târziu, numărul afișat pe LED poate fi 526624 și, la autentificare,
serverul ar cunoaște și acest nou număr. Un mod obișnuit de a utiliza tokenurile
pentru autentificare în site-urile web. Utilizatorul scrie numărul afișat
în token pe o pagină web. Dacă utilizatorul scrie numărul cunoscut și de
server la acel moment, autentificarea are loc. În multe aplicații se
obișnuiește să se folosească autentificarea bazată pe token în cadrul unei
autentificări multifactor. Pe lângă introducerea numărului afișat în token,
utilizatorul este adesea obligat să introducă un nume de utilizator și o
parolă. Acest lucru dovedește că au ceva (tokenul) și știu ceva (parola și
chiar userul lor).
• Ceva ce caracterizează un utilizator (fizic - Inherence factors), cum ar fi
amprenta, retină, voce etc. Amprentele sunt elementele ce țin de biometrie
cel mai larg utilizate astăzi. Multe laptop-uri și chiar unități USB-flash
includ cititoare de amprente. Amprentele sunt utilizate și în multe parcuri de
distracții care vând abonamente de sezon sau abonamente de mai multe zile.
În timp ce biometria oferă cea mai puternică autentificare, este și ea
susceptibilă la erori. O eroare falsă de respingere (numită și eroare de tip 1)
apare atunci când un sistem respinge, în mod fals, un utilizator cunoscut și
indică faptul că acesta nu este cunoscut. O eroare falsă de acceptare (numită
și eroare de tip 2) apare atunci când un sistem identifică în mod fals un
utilizator necunoscut ca utilizator cunoscut. Sistemele biometrice pot fi de
obicei ajustate la capitolul sensibilitate, dar sensibilitatea poate afecta
precizia. Cu alte cuvinte, un sistem mai puțin sensibil autentifică în mod fals
utilizatorii necunoscuți. În schimb, rata de respingere falsă crește pe măsură
ce sensibilitatea crește - utilizatorii cunoscuți sunt respinși, fiind considerați
necunoscuți.
6.2. Protecţia şi securitatea bazelor de date
Bazele de date constituie unul din componentele cele mai importante a oricărui
sistem informatic. Ele sunt resurse de valoare ce trebuie controlate și gestionate într-un
mod optim. Acestea sunt utilizate pentru stocarea datelor din cadrul unei organizații, date,
care printr-o prelucrare ulterioară, vor putea genera informații necesare luării deciziilor.
Aceste sisteme pot fi utilizate în diverse domenii, printre aplicații des întâlnite putând
enumera: sisteme de gestiune a documentelor și a evidenței contabile, sisteme de billing
și de management al conținutului (CMS), sisteme de gestiune a proceselor tehnologice
etc. Dimensiunea bazelor de date depinde, în mare parte, de activitățile desfășurate de
către o organizație. Ele pot cuprinde detalii ce ar putea genera informație mai puțin sau
mai importantă atât pentru mediul intern, cât și pentru cel extern organizației. Indiferent
de nivelul de importanță atribuit informației generate, lucrul cu baze de date determină
cerințe sporite de confidențialitate, integritate și acces la date.
88
Protecția și securitatea bazelor de date se referă la totalitatea mijloacelor,
metodelor și a mecanismelor destinate prevenirii distrugerilor, modificărilor sau
folosirilor neautorizate a datelor protejate din bazele de date de către utilizatori autorizați
sau neautorizați. Astfel, o organizație ce implementează sisteme cu baze de date trebuie
să asigure măsuri de protecție împotriva distrugerii accidentale sau voite, a modificărilor
sau poate chiar a afișărilor neautorizate a datelor stocate. În anumite cazuri, se are în
vedere și caracterul secret a datelor ce ar aparține unei persoane sau organizații
colaboratoare, astfel, proprietarul are dreptul de a decide ce informații se vor folosi și în
ce scop. În strânsă legătură cu cele precizate mai sus, sistemul trebuie să asigure și un
nivel ridicat de confidențialitate a datelor, astfel se va preveni posibilitatea de acces la
date a persoanelor care nu au acest drept. O ultimă caracteristică a bazelor de date, în
strânsă legătură cu securitatea datelor, este integritatea, aspect ce se referă la
corectitudinea informațiilor, presupunând detectarea, corectarea și prevenirea diferitelor
erori care pot afecta datele introduse în bazele de date.
Securitatea datelor este adeseori menționată în același context ca integritatea
datelor, dar cele două aspecte sunt destul de diferite; securitatea se referă la protecția
datelor față de accesul neautorizat, în timp ce integritatea se referă la corectitudinea
acestora. Mai fluent, putem spune că[3] :
• Securitatea înseamnă protejarea datelor față de utilizatorii neautorizați;
• Integritatea înseamnă protejarea datelor față de utilizatorii autorizați!
Problemele care pot interveni, în momentul în care vorbim despre securitatea
datelor, sunt generate atât de mediul extern (viruși, hackeri, concurenți etc.), cât și cel
intern (acțiuni ale personalului necinstit, erori și scăpări din vedere ale personalului
propriu și a utilizatorilor ș.a.). De asemenea, în cadrul acestei problematici trebuie luată
în considerare și fiabilitatea sistemelor de gestiune a bazelor de date, aspect ce poate fi
afectat de anumiți factori, cum ar fi: calamități naturale, incendii, diferite defecțiuni
hardware, etc. La o primă privire asupra securității datelor stocate în baze de date putem
observa că diversele breșe de securitate pot afecta și alte părți din sistem/organizație, care
în mod indirect afectează baza de date. Astfel, când vorbim despre securitatea unui
anumit sistem trebuie să facem referire și la partea hardware, cât și software, dar să nu
uităm de personal, elemente care, împreună sau separat, pot afecta datele din cadrul
oricărei organizații.
Există multe aspecte ale problemei securității. În încercarea de a răspunde la niște
întrebări legate de securitate, C.J. Date a enumerat câteva din ele[3]:
• Aspecte legale, sociale și etice (de exemplu, persoana care a efectuat o
interogare, cum ar fi contul de creidt a unui client, are dreptul legal de a
cunoaște informațiile cerute?);
• Elemente de control fizic (de exemplu, camera cu serverul este încuiată și
păzită?);
• Problemele de politică (de exemplu, cum decide întreprinderea care deține
sistemul cui să acorde accesul și la ce?);
• Problemele operaționale (de exemplu, dacă se utilizează o schemă de
parole, cum sunt ținute secrete și cât de des ar trebui schimbate?);
• Elemente de control hardware (de exemplu, serverul pune la dispoziție
caracteristici de securitate, cum ar fi cheile de protecție a capacității de
stocare sau un mod de operare protejat?);
89
• Suportul sistemului de operare (de exemplu, sistemul de operare aflat la
bază șterge conținutul memoriei principale ți fișierele de pe disc atunci când
nu mai sunt necesare și care este situația jurnalului de refacere?);
• Aspecte care reprezintă o preocupare specifică a sistemului de baze de date
de baze de date însuși (de exemplu, sistemul respectiv are un concept de
prioritate asupra datelor?).
Pentru a spori protecția datelor stocate este necesară detectarea aspectelor precare
care pot influența această caracteristică. Potențialele riscuri asupra sistemelor de calcul ce
pot afecta și datele stocate sunt datorate:
• Rețelelor de comunicații (comunicații interceptate, cabluri deteriorate,
radiații, fel și fel de interferențe);
• Hardware (calamități, pene de curent, furt de echipamente, defecțiuni fizice
ale echipamentelor);
• SGBD (Sistem de Gestiune al Bazelor de Date) și sistem de operare (furt de
programe, deteriorare de programe, eliminarea mecanismelor de securitate);
• Personalul implicat în dezvoltarea sistemului (modificare programe,
personal slab calificat, politici și proceduri de securitate inadecvate);
• Utilizatori (utilizarea informațiilor de acces aferente altor persoane,
introducere de viruși, vizualizare și dezvăluire de date neatorizate, încercare
de deteriorare a bazei de date);
• Baza de date (copiere și modificare neautorizată a datelor, furt de date);
• Administratorul de date și DBA-ul (administratorul bazei de date)
(nerespectarea politicilor și procedurilor de securitate).
Pentru a găsi soluții pentru sporirea protecției datelor, ținând cont chiar de
riscurile existente, ar trebui o concentrare sporită a atenției asupra următoarelor aspecte:
• limbajul SQL – un instrument de interogare a datelor, însă poate constitui și o
unealtă ce aduce efecte negative asupra bazelor de date prin:
a. spargerea parolelor utilizatorilor bazelor de date, mărirea privilegiilor
utilizatorilor existenți;
b. atacurile de tip SQL injection;
c. modificarea/înlocuirea datelor existente etc.
• controlul accesului la Sistemul de Gestiune a Bazelor de Date (SGBD)/server:
a. erori ce ar putea veni din partea personalului, dar și a utilizatorilor;
b. diverse acțiuni răuvoitoare;
c. furtul fizic, distrugerea datelor etc.
• atacurile asupra informației care circula în rețea:
a. utilizarea, de către persoane neautorizate, a conexiunilor existente la
baza de date prin rețea, stabilite de utilizatorii autentificați;
b. interceptarea datelor în momentul transmiterii lor prin rețea.
• alte tipuri de atacuri:
a. asupra sistemului de operare;
b. blocarea accesului către date;
c. hackeri, viruși.
90
Întrebări
1. Care sunt factorii pe care se bazează autentificarea?
2. Care sunt elementele ce pot sta la baza potenţialelor riscuri asupra sistemelor de
calcul?
91
Bibliografie
[1] Brânzei R. – Sisteme informatice, Ed. Universităţii “Al. I. Cuza”, Iaşi, 1995
[2] Chindea M. E. – Proiectarea sistemelor informatice economice, Bucureşti,
1999
[3] Date C.J. – Baze de date, Ediţia a opta, Ed. PLUS, 2005
[4] DEX online, http://dexonline.ro/definitie/sistem
[5] Hernandez, M., Proiectarea bazelor de date, Ed. Teora, 2003
[6] Moldoveanu F. – Ingineria programării, note de curs, 2008
[7] Morariu, N., Vlad, S. – Proiectarea sistemelor informatice. Metode, modele,
tehnici şi instrumente utilizate, Ed. Infodata, Cluj, 2008
[8] Onete, B. – Sisteme informatice – Elemente fundamentale, curs în format
digital, http://www.biblioteca-digitala.ase.ro/biblioteca/carte2.asp?id=225&idb=
[9] Oprea, D. – Analiza şi proiectarea sistemelor informaţionale economice, Ed.
Polirom, Iaşi, 1999
[10] Oprea, D., Dumitriu, F., Meşniţă, G., Proiectarea sistemelor informaţionale,
Ed. Universităţii “Alexandru Ioan Cuza”, Iaşi, 2006
[11] Planificarea şi controlul proiectelor, http://www.asecib.ase.ro/
mttp/Capitolul_1.pdf
[12]Regulamentul (UE) Nr. 526/2013 al Parlamentului European și al Consiliului
din 21 mai 2013 privind Agenția Uniunii Europene pentru Securitatea Rețelelor și a
Informațiilor (ENISA) și de abrogare a Regulamentului (CE) nr. 460/2004
[13] Ronald L. Krutz, Russell Dean Vines. The CISSP Prep Guide: Golden
Edition. Wiley Publishing, Inc. 2003
[14] Stanciu V. – Proiectarea sistemelor informatice de gestiune, Ed. Cison,
Bucureşti 2000
[15] Stanciu, V., Gavrilă, A., Mangiuc, D., Sahlean, B.G., Proiectarea sistemelor
informatice, Ed. DualTech, 2000
92