Introducere … 3 [610518]

1

2

Cuprins:
Introducere ……………………………………………………………………………………………. 3
Motivația, importanța și metodologia cercetării …………………………………………. 4

Cap.1. Analiza si cerintele unui sistem informatic
1.1. Specificarea cerintelor
1.2. Analiza bazei de date relationale. Modelul entitate-relatie
1.3. Diagrama necesare realizarii sistemului informatic
Cap.2. Realizarea sistemului informatic
2.1. Sectiunea 1
2.2. Sectiunea 2
2.3. Sectiunea 3
Cap.3. Implementarea sistemului informatic
3.1. Sectiunea 1
3.2. Sectiunea 2
3.3. Sectiunea 3
Cap.4. Studiu de caz
Cap. 5. Concluzii generale aferente lucrării
Bibliografie
3

INTRODUCERE
Schimbarile majore care s-au produs in mediul de afaceri in ultimele decenii s-au datorat
competitiei si adaptarii la nevoile pietei, dar mai ales dezvoltarii tehnologiei informationale. Dezvolatea
tehnologiei a adus cu sine o serie de transformari in ceea ce priveste modul de organizare si conducere
al intreprinderilor, scopul acestora fiind de a creste eficienta activitatilor realizate de catre intreprindere.
In acest scop s-au dezvoltat o serie de aplicatii de afaceri mai mult sau mai putin specifice domeniului
de activitate specific intreprinderii.
Indiferent de scopul final al acestor aplicatii: analiza de indicatori economici, optimizarea
proceselor interne ale intreprinderii, imbunatatirea relatiilor cu partenerii de afaceri, s.a., toate aceste
aplicatii utilizeaza baze de date si interfete grafice inteligibile. Prin intermediul interfetelor grafice
utilizatorii pot accesa baza de date a aplicatiei in scopul obtinerii de date care mai apoi pot fii utilizate
de catre intreprindere pentru luarea unor decizii.
Sintagma “Time is money” (Timpul inseamna bani) a lui Benjamin Franklin din lucrarea sa
intitulata “Advice to a young Tradesman, Written by an Old One” (Sfaturi pentru un comerciant tanar,
scrise de un comerciant batran) este mai adevarata ca oricand in cadrul societatii informationale
deoarece succesul unei intreprinderi se bazeaza pe capacitatea acesteia de a reactiona intr-un timp cat
mai scurt schimbarilor pietei, iar aceasta reactie trebuie sa aiba la baza date concrete obtinute in timp
real.
Regasim la ora actuala trei tipuri importante de aplicatii utilizate de catre mediul de afaceri:
aplicatii de tipul B2E (business-to-employee) care au ca si scop eficientizarea proceselor interne ale
intreprinderii, aplicatii de tipul B2B (business-to-business) al caror scop este imbunatatirea relatiilor cu
partenerii de afaceri ai intreprinderii si aplicatii de tipul B2C (business-to-client) care au ca si scop
cresterea nivelului de satisfactie al clientilor si obtinerea de date privind nevoile acestora.

4

MOTIV ATIA, IMPORTANTA SI
METODOLOGIA CERCETARII
Dorinta intreprinderilor de a-si eficientiza modul de desfasurare a activitatii prin facilitarea
accesului la informatii, dar si crearea unor structuri ierarhice cat mai eficiente au dus la implementarea
sistemelor informatice in cadrul acestora.
Una dintre prioritatile Uniunii Europene prevazute in “Tratatul privind functionarea Uniunii
Europente” este promovarea si raspandirea tehnologiei astfel incat mediu de afaceri, guvernele si
cetatenii sa aiba un rol decisiv in dezvoltarea si modelarea economiei globale. 01
Modificarile legislative din ultima perioada din Romania au generat o serie de obligatii pentru
intreprinderi, printre care obligatia tinerii evidentei orelor de munca prestate de catre angajat. Conform
articolului 119 din Codul Muncii, modificat prin Ordonanta de urgenta 53/2017 se mentioneaza faptul
ca: “Angajatorul are obligatia de a tine la locul de munca evidenta orelor de munca prestate zilnic de
fiecare salariat, cu evidentierea orei de incepere si a celei de sfarsit a programului de lucru si de a
supune controlului inspectorilor de munca aceasta evidenta, ori de cate ori se solicita aceasta
evidenta.”.
Pornind de la afirmatia de mai sus, lucrarea de fata isi propune realizarea unui sistem informatic
care sa permita intreprinderilor mici si microintreprinderilor sa gestioneze activitatea angajatilor si a
foilor de pontaj ale acestora la un cost minim. Totodata acest sistem va oferi o interfata grafica simpla
si sugestiva astfel incat utilizarea sistemului sa se poata realiza usor, fara a necesita cunostinte
suplimentare.
Avand ocazia de a munci intr-o microintreprindere o perioada relativ scurta de timp
(aproximativ 6 luni), am remarcat cu usurinta cateva dintre dezavantajele neutilizarii unui sistem
informatic de gestionare a timpului de lucru. Practic, incercandu-se a se urmari performantele de grup,
dar si cele individuale, la sfarsitul programului, seful de echipa era nevoit sa noteze intr-un asa numit
caiet de lucru activitatea prestata de fiecre angajat in parte si durata aproximativa a acesteia. Pe langa
faptul ca aceasta activitate presupunea o anumita perioada de timp, exista si posibilitatea ca anumite
actiuni realizate de catre angajat pe parcursul programului sa nu fie mentionate.
In ceea ce priveste intreprinderile in care domeniul de activitate se bazeaza mai mult pe
realizarea de activitati cu caracter intelectual, un astfel de sistem ar putea oferi o mai buna imagine
privind modul in care angajatul se implica in activitatile intreprinderii, felul in care acesta isi
organizeaza programul de lucru pentru a indeplini sarcinile primite, dar si calitatea muncii sale.
Pentru realizarea acestei aplicatii am facut apel la cunostiintele dobandite pe parcursul celor trei
ani de studiu, in special cele referitoare la administrarea datelor prin intermediul unei baze de date de
tip SQL (Structured Query Language), a cunostiintelor dobandite prin studiu individual privind modul
de utilizare a diferitelor tehnologii web cum ar fii: HTML, CSS si JavaScript si a limbajului PHP in
scopul crearii de aplicatii care sa poata rula in mediul virtual, denumit si web sau mediu online.

5

CAP. 1. ANALIZA SI CERINTELE
UNUI SISTEM INFORMATIC
1.1. Specificarea cerintelor
Sistemul informatic care urmeaza a fii realizat este creat pentru a ajuta intreprinderile din
diferite domenii de activitate la imbunatatirea calitatii activitatilor lor zilnice. Acest sistem va permite:
•managementul utilizatorilor (tot ce tine de creare, editare sau stergere),
•atribuirea de roluri si permisiuni utilizatorilor in functie de statutul acestora in cadrul
intreprinderii
•crearea si editarea departamentelor
•managementul operatiunilor efectuate de catre fiecare angajat in parte
Utilizatorul este principalul element al acestei aplicatii, iar in baza de date vor fii definite
urmatoarele campuri:
•id identificator unic, va fii utilizat ca si numar de marca
•name numele complet al utilizatorului
•password parola aferenta contului utilizatorului
•remember_token se va utiliza atunci cand utilizatorul doreste sa-si schimbe parola
•department_id va contine o valoarea numerica pozitiva care va reprezenta identificatorul unic
al departamentului din care utilizatorul face parte
•role_id va contine o valoare numerica pozitiva care va reprezenta identificatorul unic al rolului
pe care utilizatorul il are in cadrul intreprinderii.
Inainte ca un utilizator sa poata fii creat, este necesara definirea unui rol si a unui departament.
Aplicatia va contine implicit un utilizator cu drepturi depline denumit “superadministrator” care, in
functie de solicitarile clientului va putea sa creeze utilizatori carora sa le atribuie diferite roluri si
totodata sa stabileasca permisiunile fiecarui rol.
Principalele roluri ale aplicatiei vor fii:
•administrator
•angajat
Utilizatorul reprezinta prinicpala entitate a acestui sistem informatic. In functie de rolul pe care
il va avea in cadrul intreprinderii, diferiti utilizatori vor putea intreprinde diferite actiuni si vor avea
anumite drepturi de acces.
Permisiunea va determina daca utilizatorul curent poate accesa o anumita componenta a
sistemului informatic sau nu.
Task-ul sau sarcina de lucru, va reprezenta o structura prin intermediul careia angajatul va avea
posibilitatea sa justifice timpul efectiv de lucru in cadrul intreprinderii.
Departamentul va reprezenta o componenta a intreprinderii in care se desfasoara anumite
tipuri de activitati care au ca si scop realizarea unui proces economic. In functie de aceste procese
economice putem distinge mai multe tipuri de departamente: productie, aprovizionare, vanzare, livrare,
contabilitate, management, etc
Rolul va reprezenta functia pe care orice utilizator o poate avea in cadrul intreprinderii. Pentru
6

inceput sistemul informatic isi propune definirea a doua roluri de baza: administrator si angajat.
1.2. Analiza bazei de date relationale. Modelul entitate-relatie
Analiza unui sistem informatic incepe prin identificarea si analiza datelor pe care acesta
urmeaza a le procesa si a le stoca in baza de date aferenta acestuia.
O baza de date poate fii definita ca o multime de date care impreuna modeleaza un univers.
Acest univers este creat din obiecte legate intre ele, care, daca sunt de acelasi tip, formeaza o entitate,
in timp ce legatura dintre ele poarta denumirea de relatie. Atat entitatile cat si relatiile dintre acestea
prezinta o serie de caracteristici denumite atribute. Procesul de descriere a entitatilor si a relatiilor
dintre acestea poarta denumirea de modelare. Modelarea unei baze de date permite reprezentarea prin
date a unor fapte reale.
In 1976, Peter Pin-Shan Chen, inginer electronist la Universitatea Nationala din Taiwan, a
definit termenii: entitate, relatie, atribut si diagrama entitate-relatie. 02
Entitatea reprezinta un obiect concret sau abstract care este reprezentat prin proprietatile sale
denumite si “atribute”. Principalele caracteristici ale unei entitati sunt denumirea entitatii si descrierea
acesteia.
Denumirea unei entitati trebuie sa fie un substantiv expresiv si relevant pentru aceasta, utilizat
la forma de singular, unic in cadrul colectiei de entitati din care face parte. Totodata o entitate nu poate
avea mai multe denumiri.
Descrierea entitatii se realizeaza prin definirea atributelor aferente acesteia care trebuie sa redea
intr-un mod cat mai fidel structura acesteia. Orice entitate trebuie sa defineasca cel putin un atribut cu
valoare unica pentru fiecare obiect care intra in componenta acelei entitati astfel incat sa nu poata exista
doua obiecte identice. Acest atribut cu valoare unica este cunoscut sub denumirea de “cheie primara” si
trebuie sa indeplineasca anumite conditii: sa poata fii controlat de catre administratorul bazei de date,
sa nu contina date descriptive sau ambiguitati, sa fie usor de utilizat si sa nu permita duplicarea sa. In
Figura 1.2.1 se poate vedea reprezentarea grafica a entitatii “Utilizator”.
Figura 1.2.1: Reprezentarea grafica a entitatii “Utilizator”
Relatia este definita ca o legatura intre doua sau mai multe entitati, definirea acesteia
realizandu-se prin intermediul anumitor verbe.
Exista anumite conditii privind definirea unei relatii:
•orice relatie devine o tabela speciala sau o coloana speciala care va referentia una sau mai multe
chei primare;
•este permisa existenta relatiilor cu acelasi nume, diferentierea acestora realizandu-se prin
intermediul entitatilor participante;
•descrierea relatiei sa fie detaliata
Tipul unei relatii poate fii stabilit in functie de .optionalitatea acesteia, unde distingem doua
tipuri: relatie obligatorie si relatie optionala sau in functie de cardinalitatea acesteia.
7

Cardinalitatea unei relatii indica numarul de instante din fiecare entitate care poate participa in
relatie. In functie de acest criteriu distingem trei tipuri de relatii care rezulta din raspunsurile pentru
intrebarile: “Cate obiecte din prima entitate participanta in relatie pot afecta un obiect din a doua
entitate?”, “Cate obiecte din a doua entitate participanta in relatie pot fii afectate de un obiect din prima
entitate?” si “Este posibil ca un obiect din prima entitate participanta in relatie sa afecteze mai multe
obiecte din a doua entitate si in acelasi timp cel putin un obiect din a doua entitate afectat sa afecteze la
randul sau mai multe obiecte din prima entitate?”.
Cardinalitatea 1:1 (ONE to ONE) reprezinta o relatie directa dintre doua entitati, principiul de
baza al acesteia constand in faptul ca un obiect dintr-o entitate poate apartine sau detine doar un singur
obiect din entitatea relationata. Un foarte bun exemplu al acestui tip de relatie il constituie relatia dintre
un utilizator si datele sale personale. Acest tip de relatie se reprezinta prin utilizarea unei linii continue
sau intrerupte intre cele doua entitati, in functie de optionalitatea relatiei. In figura 1.2.2 putem observa
reprezentarea grafica a relatiei de cardinalitate 1:1, atunci cand aceasta este obligatorie.
Figura 1.2.2: Relatia de cardinalitate 1:1
Cardinalitatea 1:N (ONE to MANY) reprezinta o relatie directa intre doua entitati, principiul de
baza al acestei relatii constand in faptul ca un obiect din entitatea curenta poate detine mai multe
obiecte din entitatea relationata. Acesta este cel mai des intalnit tip de relatie. Pornind de la exemplul
de mai sus, presupunem ca utilizatorul este angajat al unei intreprinderi, unde are o anumita functie. In
acest caz relatia dintre utilizator si functia sa are o cardinalitate de 1:N deoarece utilizatorul poate avea
o singura functie, dar acea functie poate apartine mai multor utilizatori in acelasi timp. In figura 1.2.3
se poate observa reprezentarea grafica a relatiei de cardinalitate 1:N atunci cand aceasta este
obligatorie:
Figura 1.2.3: Relatia de cardinalitate 1:N
Cardinalitatea M:N (MANY to MANY) reprezinta o relatie complexa care pentru a putea fii
interpretata corect este descompusa in doua sau mai multe relatii de tipul 1:N (ONE to MANY). Am
putea lua ca si exemplu relatia dintre functie si permisiunile pe care aceasta le genereaza pentru
utilizator (persoana care detine functia respectiva). In aceasta situatie cardinalitatea relatiei este M:N
(MANY to MANY) deoarece o functie poate genera mai multe permisiuni, dar totodata o permisiune
poate fii generata de mai multe functii in acelasi timp. In figura 1.2.4 se poate observa reprezentarea
8

grafica a relatiei de cardinalitate M:N atunci cand aceasta este obligatorie, iar in figura 1.2.5 se poate
observa descompunerea relatiei M:N in doua relatii de cardinalitate 1:N.

Figura 1.2.4: Relatia de cardinalitate M:N
Figura 1.2.5: Descompunerea relatiei de cardinalitate M:N in doua relatii de cardinalitate 1:N
Atributul este o caracteristica a unei entitati sau a unei relatii. Fiecare entitate detine un anumit
numar de atribute pentru care sunt inregistrate valori. In general numarul de atribute al unei entitati este
stabilit astfel incat orice obiect al entitatii sa fie unic si usor de selectat in aplicatie. In stabilirea
atributelor se tine cont de cateva reguli simple:
•orice atribut este un substantiv dar nu orice substantiv este si atribut al unei entitati
•denumirea atributului este unica in cadrul entitatii
•orice atribut trebuie sa contina o descriere, sa defineasca tipul de date stocat si dimensiunea
maxima a acestora
Desi nu este obligatoriu acest lucru, majoritatea aplicatiilor utilizeaza denumirea atributelor in
limba engleza, unele dintre acestea fiind comune entitatilor, indiferent de scopul final al aplicatiei din
care fac parte. Printre cele mai utilizate atribute regasim: id, name / username, password, created_at,
updated_at, email, etc. Inainte de a defini cateva atribute pentru una din entitatile de mai sus, trebuie
specificat faptul ca nu toate atributele sunt strict legate de proprietatile pe care un obiect al entitatii le
poate avea. Exista un tip special de atribute denumit “cheie primara” al carui singur rol este acela de a
oferi unicitate obiectelor entitatii. In exemplul anterior, pentru entitatea “Utilizator” am putea defini
urmatoarele atribute:
•id care va reprezenta o valoare care va fii unica pentru fiecare obiect. De precizat este faptul ca
in cele mai multe cazuri aceasta valoare va fii un numar natural nenul, dar exista si situatii in
care aceasta valoare poate fii un sir de caractere care sa nu fie neaparat numerice sau sa fie o
combinatie de caractere alfanumerice.
•username care va reprezenta numele cu care utilizatorul se poate loga in aplicatie
•password care va reprezenta parola aferenta utilizatorului
•email care va reprezeinta adresa de mail a utilizatorului
•gender care va reprezenta sexul utilizatorului (masculin sau feminin)
9

Dupa adaugarea atributelor de mai sus, entitatea “Utilizator” se va prezenta ca in figura 1.2.6 de
mai jos. De obicei cheia unica se defineste prima data, urmata de celelalte atribute definite in ordinea
importantei acestora din punct de vedere al programatorului.
Figura 1.2.6: Reprezentarea grafica a entitatii “Utilizator” dupa definirea a trei atribute
In continuare vom analiza diagramele procesului de lucru pe care sistemul informatic propus le
va implementa.
1.3. Diagramele necesare realizarii sistemului informatic
1.3.1 Diagrama Entitate-Relatie
Cunoscand modul de reprezentare a unei entitati, tipurile de relatii care pot exista intre doua
entitati ale aceluiasi sistem si modul in care acestea se pot reprezenta grafic, in continuare se va
prezenta prin intermediu unei scheme grafice structura si legaturile sistemului informatic propus. Mai
trebuie specificat faptul ca aceasta diagrama se va utiliza in crearea bazei de date a aplicatiei.
Principalele etape pentru crearea acestei diagrame sunt:
•identificarea entitatilor care intra in componenta sistemului
•identificarea tipului de relatii existent intre entitati
•identificarea cheilor primare ale entitatilor sistemului
In figura 1.3.1 definita mai jos este reprezentata Diagrama Entitate-Relatie, tinand cont de
etapele enumerate anterior privind modul de realizare al acesteia si totodata si de urmatoarele reguli de
reprezentare:
•entitatile sistemului se reprezinta prin dreptunghiuri
•legaturile dintre entitati se reprezinta prin arce neorientate
•se defineste cardinalitatea legaturilor perin intermediul verbelor
10

Figura 1.3.1: Diagrama Entitate – Relatie
1.3.2. Diagrama Procesului de Afaceri
Odata cu terminarea analizei bazei de date relationale, urmatorul pas consta in analizarea
aplicatiei software care urmeaza a fii creat. Aplicatia software trebuie sa utilizeze baza de date descrisa
anterior, iar analiza sistemului in acest punct consta in determinarea proceselor care au loc in cadrul
sistemului informatic si a factorilor care influenteaza modul de functionare al sistemului. Pentru aceasta
se va realiza Diagrama Procesului de Afaceri.
Diagrama Procesului de Afaceri ( en. Business Process Model Diagram) descrie in mare
vocabularul afacerii sau a unei parti dintr-o afacere, in acest caz, pe care sistemul informatic urmeaza
sa o implementeze si reprezinta punctul de pornire in realizarea oricarui sistem informatic. Aceasta
diagrama are o contributie foarte mare la intelegerea modului de functionare a afacerii pe care sistemul
informatic urmeaza sa o implementeze.
Procesul de afaceri ( en. business process) reprezinta o colectie de activitati care au ca si scop
comun producerea unui rezultat. Activitatile in cadrul procesului de afaceri trebuie sa fie bine definite,
ordinea acestora in timp si spatiu sa fie una riguroasa, iar datele de intrare si datele de iesire sa fie si
acestea bine definite si sa nu permita ambiguitati.
Diagrama Procesului de Afaceri trebuie sa contina urmatoarele componente:
•actorii
•evenimentul declansator
•procesul de lucru
•scopul procesului de lucru
•date auxiliare
•resursele necesare procesului
•rezultatul obtinut
11

Actorii
Un actor reprezinta o entitate care poate interactiona cu sistemul informatic si nu un individ.
Acesta nu este componenta a sistemului, ci mai degraba pot fii considerat ca fiind componenta umana a
unei activitati economice sau de alta natura care intra in interactiune cu sistemul informatic.
Reprezentarea grafica a unui actor se realizeaza sub forma unui mic personaj care are propriul
sau nume. In figura 1.3.2 se poate vedea reprezentarea grafica a actorului.
Figura 1.3.2: Reprezentarea grafica a actorului
Evenimentul declansator
Evenimentul declansator reprezinta evenimentul care duce la pornirea (declansarea) procesului
de lucru si, in general, este un eveniment declansat de catre actor in mod direct sau indirect.
Reprezentarea grafica a evenimentului declansator se poate observa in figura 1.3.3 de mai jos
Figura 1.3.3: Reprezentarea grafica a unui eveniment declansator
Procesul de lucru
Procesul de lucru reprezinta o activitate bine definita care are ca si scop principal obtinerea unui
rezultat. Pentru atingerea scopului (obtinerea rezultatului), procesul de lucru utilizeaza una sau mai
multe resurse. Reprezentarea grafica a procesului de lucru se realizeaza de obicei prin intermediul unei
sageti in interiorul careia se defineste denumirea procesului de lucru, asa cum se poate observa si in
figura 1.3.4. de mai jos.
Figura 1.3.4: Reprezentarea grafica a unui proces de lucru
Scopul procesului de lucru
12

Scopul procesului de lucru reprezinta motivul pentru care procesul de afaceri functioneaza si
trebuie sa fie exprimat clar, fara ambiguitati si fara sa lase loc de interpretari. O alta formulare a
definirii scopului procesului de lucru poate fii: beneficiul rezultat in urma realizarii procesului de lucru.
Reprezentarea grafica a scopului procesului de lucru se realizeaza prin intermediul unui
dreptunghi. In figura 1.3.5. se poate vedea reprezentarea grafica a scopului procesului de lucru.
Figura 1.3.5: Reprezentarea grafica a scopului procesului de lucru
Datele auxiliare
Datele auxiliare sunt utilizate de procesul de lucru pentru a-si atinge scopul. Acestea pot fii
furnizate de catre actori, surse externe sau pot fii chiar si rezultatul unui alt proces de lucru.
Reprezentarea grafica a datelor auxiliare se realizeaza prin intermediul unor sageti intrerupte, pe care se
regaseste textul “supply” ( ro. ofera ).
Figura 1.3.6: Reprezentarea grafica a unui segment de date auxiliare
Rezultatul procesului de lucru
Rezultatul procesului de lucru reprezinta ceea ce se obtine in urma realizarii procesului de lucru.
Reprezentarea grafica a rezultatului procesului de lucru se realizeaza prin intermediul unui dreptunghi
care este direct legat printr-o sageata continua de procesul de lucru. In figura 1.3.7 se poate observa
modul de reprezentare al rezultatului procesului de lucru.
Figura 1.3.7: Reprezentarea grafica a rezultatului procesului de lucru
Cunoscand elementele de mai sus si modul acestora de reprezentare, in coontinuare se va crea
13

Diagrama Procesului de Afaceri ( en. Business Process Model Notation) pentru aplicatia prezentata la
inceputul acestui capitol. In diagrama din figura 1.3.8 se poate observa structura sistemului informatic
realizata folosind principille Diagramei Procesului de Afaceri.
Figura 1.3.8: Diagrama Procesului de Afaceri pentru sistemul informatic
de gestiune a timpului de lucru al angajatilor
1.3.3 Diagrama cazurilor de utilizare (Use Cases Diagram)
Definirea cazurilor de utilizare ( en. use cases) a fost initial realizata de catre suedezul Ivar
Jacobson in 1992 prin lucrarea sa intitulata “Object-Oriented Software Engineering – A Use Case
Diven Approach”, editura Addison-Wesley, in care defineste use case ca fiind o actiune, o lista de
actiuni, un eveniment sau o serie de evenimente care definesc interactiunile dintre un actor si un sistem
in scopul obtinerii unui rezultat 1. Conform definitiei date de Ivar Jacobson, un actor poate fii un
utilizator dar si un sistem extern.
Teoria cazurilor de utilizarea a fost preluata in mai multe sisteme de modelare a proceselor
printre care: UML (Unified Modeling Language), OUM (Oracle Unified Method) sau RUP (IBM
Rational Unified Process)2.
Diagramele cazurilor de utilizare descriu comportamentul sistemului, oferind o imagine de
ansamblu asupra modului in care acesta poate fii utilizat din punct de vedere functional. Descrierea
1Sursa https://en.wikipedia.org , use case
2Sursa https://en.wikipedia.org
14

tuturor cazurilor de utilizare ale unui sistem din punct de vedere functional, alcatuiesc diagrama
cazurilor de utilizare a sistemului respectiv.
Diagrama cazurilor de utilizare este utilizata atat in etapa de proiectare a sistemului informatic,
atunci cand se culeg date privind cerintele sistemului informatic, cat si in etapa de creare si testare a
sistemului informatic. Este foarte recomandat ca in cadrul echipei care construieste diagrama cazurilor
de utilizare sa existe cel putin un viitor utilizator al sistemului informatic. In cazul unui sistem
informatic care permite definirea mai multor cazuri de utilizare, crearea diagramei cazurilor de utilizare
va fii precedata de o descriere narativa a cerintelor functionale si a cerintelor nefunctionale ale
sistemului informatic care urmeaza a fii creat. Aceasta descriere trebuie sa contina urmatoarele:
•standarde de securitate
•modul de clasificare a utilizatorilor
•cerinte minime de functionare a sistemului informatic
•functionalitatile sistemului identificate de utilizatori
Dupa realizarea descrierii narative a sistemului se poate crea diagrama cazurilor de utilizare,
care poate contine:
•actori
•cazurile de utilizare
•relatii intre actori si cazurile de utilizare
•eventuale relatii intre actori
Anterior vorbeam despre actor ca fiind componenta umana care intra in contact cu sistemul
informatic. Identificarea actorilor se poate realiza prin definirea raspunsurilor la intrebari precum:
•Unde se va utiliza sistemul informatic?
•Cine sunt beneficiarii sistemului informatic?
•Cine va furniza date sistemului informatic?
•Cine va administra sistemul informatic?
•Ce fel de date va utiliza sistemul informatic?
•Cu ce alte sisteme informatice va interactiona noul sistem informatic?
La identificarea actorilor sistemului informatic trebuie avut in vedere faptul ca exista
posibilitatea ca uni actori sa fie omisi sau chiar sa fie repetati. Exista posibilitatea ca in timp un actor
sa-si modifice modul in care acesta interactioneaza cu sistemul informatic, iar aceasta poate crea
confuzie, ceea ce poate duce la duplicarea actorului respectiv. Pentru a evita aceste situatii, elementele
structurale prezentate in diagramele cazurilor de utilizare sunt legate de cele mai multe ori cu elemente
comportamentale din cadrul unor diagrame de activitate.
Instantierea unui caz de utilizare poarta denumirea de scenariu si reprezinta un anumit mod de
utilizare a sistemului informatic de catre un actor.
Toate cerintele functionale sau nefunctionale ale unui sistem informatic se pot reprezenta prin
intermediul cazurilor de utilizare (scenariilor). Reprezentarea grafica a unui scenariu se realizeaza prin
definirea unui oval (elipse) in interiorul caruia se defineste actiunea pe care acesta o reprezinta. In
figura 1.3.9. se poate vedea modul de reprezentare grafica a unui scenariu.
15

Figura 1.3.9: Reprezentarea grafica a unui scenariu
Odata identificati toti actorii se poate incepe identificarea cazurilor de utilizare utilizand
raspunsurile obtinute la urmatoarele intrebari pentru fiecare actor in parte:
•Ce functionalitati ale sistemului informatic va putea accesa actorul?
•Este necesar ca actorul sa poata citi date din sistemul informatic?
•Este necesar ca actorul sa poata modifica date in sistemul informatic
•Exista evenimente din sistemul informatic care trebuie aduse la cunostiinta actorului? Care?
•Sistemul informatic va usura munca actorului intr-o masura semnificativa?
Descrierea scenariilor se realizeaza de obicei prin intermediul unor paragrafe de text care
prezinta succint modul de interactiune dintre actori si cazurile de utilizare. Aceaste descriere va
surprinde comportamentul sistemului informatic si nu modul de implementare a acestuia si va contine
urmatoarele date:
•obiectivele scenariilor
•actorul / actorii care initiaza un anumit scenariu
•situatiile in care se initiaza si executa un anumit scenariu
•mesajele generate de sistemul informatic privind interactiunea dintre actori si scenarii
•comportamentul sistemului informatic in cazul exceptiilor
•comportamentul sistemului informatic la terminarea unui scenariu
•modul in care sunt transmise datele catre actor la terminarea scenariului
Pentru o mai buna percepere a scenariilor, acestea pot fii si reprezentate grafic prin intermediul
unei diagrame. In acest caz relatia dintre un actor si un scenariu se va reprezenta prin intermediul unei
linii continue si nu prin intermediul unei sageti deoarece aceasta relatie va fii mereu o relatie de tip unu
la unu, iar comunicarea se va realiza in ambele sensuri. In figura 1.3.10 se poate observa reprezentarea
grafica a relatiei dintre actor si scenariu.
Figura 1.3.10: Reprezentarea grafica a legaturii dintre actor si scenariu
Pe baza acestor cunostiinte se va crea diagrama cazurilor de utilizare pentru sistemul informatic
propus la inceputul acestui capitol. Pentru realizarea acesteia se va utiliza o aplicatie online denumita
Gliffy. Structura restransa a acesteia poate fii regasita in imaginea 1.3.11.
16

Figura 1.3.11: Diagrama restransa a legaturilor dintre actori si scenarii
In Diagrama restransa a legaturilor dintre actori si scenarii s-au prezentat principalele scenarii
din sistemul informatic propus. Orice scenariu care presupune administrarea unei entitati reprezinta
forma prescurtata de creare, editare, modificare sau stergere de date apartinand respectivei entitati.
Capitolul urmator isi propune prezentarea fazei de proiectare a sistemului informatic, in special
arhitectura acestuia si design-ul.
17

CAP. 2. REALIZAREA SISTEMULUI INFORMATIC
In acest capitol se va prezenta faza de proiectare a sistemului informatic, in special arhitectura si
design-ul acestuia.
Design-ul sistemului informatic
Design-ul sistemului informatic specifica modul in care acesta isi atinge obiectivele si este
alcatuit din trei componente de baza:
•interactiunea cu utilizatorul
•datele utilizate
•procesul de lucru
Interactiunea cu utilizatorul sau interfata utilizator a sistemului informatic trebuie sa fie una
intuitiva, usor de utilizat si care sa permita utilizatorului sa-si desfasoare activitatea in conditii cat mai
apropiate de conditiile ideale.
Datele utilizate de catre sistemul informatic au in vedere structura bazei de date si a fisierelor
utilizate. Probabil aceasta este cea mai importanta componenta a design-ului deoarece o baza de date
neperformanta poate ruina oricand un sistem informatic.
Design-ul procesului de lucru are in vedere resursele utilizate de sistemul informatic si anumite
proceduri prin care acestea vor fii accesate de catre sistem.
Deoarece interfata utilizator a sistemului informatic depinde foarte mult de preferintele
utilizatorului, iar realizarea acesteia se bazeaza foarte mult pe tehnologii precum HTML, CSS si
JavaScript care nu presupun o logica foarte elaborata, vom studia in continuare modelarea bazei de date
a sistemului informatic.
2.1. Proiectarea bazei de date relationale
Pentru a proiecta baza de date a sistemului informatic este necesara transformarea Diagramei
Entitate-Relatie realizata in capitolul anterior (vezi figura 1.3.1: Diagrama Entitate – Relatie) prin
respectarea unor reguli de conversie intr-o baza de date. Aceste reguli de conversie sunt:
•o entitate devine o tabela in baza de date
•un atribut al entitatii devine coloana in tabela aferenta entitatii respective
•o relatie intre doua entitati se implementeaza prin intermediul unei chei straine sau chiar prin
crearea unei tabele intermediare.
2.1.1. Cheia unei entitati
O cheie a unei entitati este un atribut sau in unele cazuri un set de atribute care permite
delimitarea unei instante a unei entitati de celelalte instante ale aceleiasi entitati. Desi exista mai multe
tipuri de “chei” care pot fii definite pentru o entitate, cele mai utilizate tipuri de chei sunt: cheia
primara, cheia unica si cheia straina.
Cheia primara (en. primary key) reprezinta un atribut al entitatii care identifica in mod unic o
inregistrare (o linie) dintr-o tabela. In general aceasta cheie este reprezentata de o valoare numerica
pozitiva nenula cunoscuta si sub denumirea generica “ id”, dar nu numai. In functie de natura entitatii si
de atributele pe care aceasta le detine, pot exista si alte tipuri de chei primare. De exemplu: pentru
entitatea “Carte” am putea utiliza ca si cheie primara ISBN-ul; pentru entitatea “Student” am putea
utiliza ca si cheie primara “numar matricol” daca respectiva entitate reprezinta studentii unei singure
facultati / universitati; pentru entitatea “Angajat” se poate utiliza ca si cheie primara “numar de marca”.
18

Cheia unica (en. unique key) reprezinta un atribut al unei entitati care trebuie sa aiba o valoarea
diferita pentru fiecare instanta a acelei entitati. Spre deosebire de cheia primara care nu poate avea
valoare nula, in cazul cheii unice este permisa si valoarea nula. De obicei cheia unica este utilizata in
cadrul unor atribute care pot reprezenta: adresa de email, numar de telefon, etc.. Deoarece in cazul cheii
unice se permit si valoarea nula, utilizarea acesteia ca si cheie primara nu este recomandata.
Cheia straina (en. foreign key) este utilizata pentru a face legatura intre doua instante care
apartin la doua entitati diferite. Privind din perspectiva unei baze de date, cheia straina este utilizata
pentru a face legatura intre doua tabele care apartin acelei baze de date. Deoarece atributul care
reprezinta “cheie straina” pentru o entitate, este “cheie primara” pentru cealalta entitate, singurele
conditii pe care trebuie sa le indeplineasca o “cheie straina” sunt:
•sa fie definita in cadrul primei entitati;
•sa identifice o singura instanta a entitatii reprezentate
2.1.2. Transforamarea entitatilor
De regula, in baza de date, entitatea va deveni o tabela, iar atributele acesteia vor deveni
coloane in tabela respectiva. Desi nu este o regula, ci mai degraba o conventie, denumirea tabelei
aferente unei entitati este un substantiv care reprezinta forma de plural a denumirii entitatii.
19

Surse:
1. http://www.euractiv.ro/uniunea-europeana/articles%7CdisplayArticle/articleID_12577/Politicile-
Uniunii-Europene.html
2.https://www.atestateinformatica.ro/tutoriale/relatii-intre-entitati
3.https://go.gliffy.com/go/html5/launch
4.http://www.bazededate.org
5.
20