INTRODUCERE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [616772]

UNIVERSITATEA BUCUREȘTI
FACULTATEA DE MATEMATICĂ ȘI
INFORMATICĂ

– LUCRARE DE LICENȚĂ –
Aplicație web pentru gestiunea
activității unei companii

Coordonator științific ,
Conf. Dr. Boriga Radu
Absolvent: [anonimizat]
2017

– 1 –
CUPRINS

INTRODUCERE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Capitolul 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1. ARHITECTURA APLICAȚIEI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
1.1 Arhitectura unei aplicații web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Arhitectura multi -stratificată . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
1.2.1 Arhitectura pe trei niveluri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1.1 Nivelul de prezentare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1.2 Nivelul de aplicație . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.1.3 Nivelul de date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Modelul arhitectural MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.1 Modelul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.2 Vizualizarea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.3 Controlerul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 11
1.4 Baza de date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . … 12
1.4.1 Schema bazei de date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 13
1.4.2 Modelul bazei de date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
1.5 Modele de proiectare software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.6 Limbajul UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.6.1 Diagrama cazurilor de utilizare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
1.6.2 Diagrama de clase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Capitolul 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
2. PREZENTAREA TEHNOLOGIILOR UTILIZATE . . . . . . . . . . . . . . . . . . . . . . . . .25
2.1 Java ca limbaj și framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
2.1.1 Librării în Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
2.1.2 Java Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 26
2.1.3 Java Quartz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . …. 27
2.1.4 Diferența între Java SE/EE/ME/FX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

– 2 –
2.1.5 Platforma Java EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.1.5.1 Framework -ul de aplicații JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
2.1.5.1.1 Librăria PrimeFaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
2.1.5.1.2 Tehnologia AJAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..30
2.1.5.2 Specificația JPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..31
2.1.5.3 Arhitectura EJB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..31
2.1.5.4 Standardul CDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..31
2.1.5.5 Serializarea bean -urilor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
2.1.6 Framework -ul Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..32
2.1.6.1 Persistența datelor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . …34
2.1.6.2 Conexiunea cu baza de date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..34
2.1.6.3 L imbajul HQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.2 Apache Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.2.1 Apache Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.2.1.1 Containerul Catalina . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
2.2.1.2 Conectorul HTTP Coyote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
2.2.1.3 Mecanismul Jasper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
2.2.2 Apache TomEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.2.3 Apache Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..38
2.2.4 Apache POI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.2.5 Apache FOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
2.2.6 Apache XML Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
2.3 Limbajul de markup HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.3.1 Structura unui document HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.3.2 Standardul HTML5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.3.3 Extensia XHTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
2.4 Limbajul de stilizare CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
2.4.1 Structura unui fișier CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.4.2 Foi de stiluri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43

– 3 –
2.5 Limbajul de scripting JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.5.1 Caracteristicile limbajului . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.5.2 Plat forma jQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.6 Framework -ul Materialize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.6.1 Componente CSS și JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.6.2 Avantajele utilizării Materialize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Capitolul 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3. PREZENTAREA APLICAȚIEI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.1 Introducere în aplicația „Cronos” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.1.1 Funcționalitatea aplicației . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.1.2 Caracteristici tehnice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2 Structura internă a aplicației . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2.1 Modulul de autentificare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
3.2.1.1 Autentificarea într -un cont existent . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
3.2.1.2 Ieșirea din cont . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.1.3 Înregistrarea unui cont nou . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.1.4 Editarea datelor personale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.1.5 Recuperarea parolei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.2 Modulul de gestiune a l taskurilor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.2.2.1 Adăugarea unui nou task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.2.2.2 Editarea unui task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.2.2.3 Ștergerea unui task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.2.2.4 Vizualizarea taskurilor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.2.2.4.1 Taskurile unui angajat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.2.2.4.2 Notificările unui angajat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2.2.4.3 Vizualizarea taskurilor în așteptare . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2.2.4.4 Afișarea detaliată a unui task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
3.2.2.5 Căutarea unui task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.2.3 Modulul de gestiune al ședințelor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

– 4 –
3.2.3.1 Vizualizarea ședințelor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.2.3.2 Adăugarea unei noi ședințe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.2.3.3 Editarea unei ședințe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.2.3.4 Ștergerea unei ședințe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.2.4 Modulul de întocmire al rapoartelor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.2.4.1 Rapoartele taskurilor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.2.4.2 Raportul utilizatorilor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.2.4.3 Raportul departamentelor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.2.4.4 Rapoartele ședințelor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
3.2.5 Modulul de mentenanță al platformei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.2.5.1 Editarea departamentelor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
3.2.5.2 Editarea descrierilor succinte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
3.2.5.3 Gestiunea utilizatorilor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
3.2.5.3.1 Modificarea drepturilor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
3.2.5.3.2 Ștergerea unui utilizator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.2.5.4 Mentenanță automată . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
3.2.5.4.1 Procesul de ștergere al conturilor temporare . . . . . . . . . . . . . . . . . . 66
3.2.5.4.2 Procesul de ștergere al taskurilor și ședințelor. . . . . . . . . . . . . . . . . .66
3.3 Cazuri de utilizare ale aplicației . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.3.1 Din perspectiva angajatului . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.3.2 Din perspectiva managerului . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.3.3 Din perspectiva super -userului . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
3.3.4 Din perspectiva administratorului . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
CONCLUZII . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
LISTĂ DE FIGURI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
BIBLIOGRAFIE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

– 5 –
INTRODUCERE
Pentru susținerea lucrării de licență, am ales implementarea unei pl atforme web de
gestiune a proiectelor, sarcinilor sau ale problemelor apătute în dezvoltare , permițând astfel
unei companii să urmărească orice fel de unitate de lucru printr -un flux predefinit. Atât
unitatea, adică elementul de lucru intern, fie el o ceri nță, o ședință sau un raport , cât și fluxul
de lucru , adică pașii pe care un element îi parcurge, pot fi personalizați pentru nevoile
specifice, mai simple sau mai complexe, ale unui departament din cadrul companiei.
Aplicația intitulată „Cronos”, nume in spirat după Zeul Timpului din mitologia greacă,
dispune de o interfață user-friendly prin care utilizatorii pot urmări cu ușurință eforturile de
dezvoltare în cadrul unu proiect. Un nou angajat poate fi adaugat ca membru pe platforma
internă a companiei, d oar de către un alt angajat înregistrat cu drepturi de manager,
administrator sau super -user. Un utilizator poate identifica un anumit task prin căutarea
acestuia după numele persoanei căreia îi este asignat, categoria din care face parte,
comentariile adă ugate sau codul acestuia, iar apoi poate aplica diferite criterii de filtrare
pentru fiecare coloană a tabelului cu date. De asemenea, se permite partajarea problemelor
prin e -mail, cât ș i gestiunea departamentelor, drepturilor angajaților, timpului acorda t
rezolvării unei cerințe, parcursului etapelor intermediare ale unui task de la inițiere până la
soluționare, ședințelor planificate și a statisticilor periodice ale angajaților sau ale diferitelor
evenimente introduse pe platformă .
Pentru implementarea f uncționalităților adaptate la nevoile companiei am folosit
framework -ul Java Enterprise Edition (JEE) care folosește o coleclție de tehnologii si API -uri
(Application Programming Interface ) pentru platforma Java concepută pentru a sprijini
aplicațiile enterprise , care pot fi în general clasificate ca aplicații la scară largă, distribuite,
tranzacționale și extrem de accesibile, concepute pentru a susține cerințele de afaceri critice.
Precum „Cronos”, există numeroase astfel de platforme ce permit gestiunea activității
unei companii, fiecare dintre aceastea fiind adaptată la necesitățile acesteia. Printre cele mai
cunoscute astfel de aplicații se numără: „JIRA”, „Bugzilla”, „GitHub Issues”, „Footprints”,
„Bitrix24”, „Zendesk” sau „Support Bee”. În continuare, umează a fi prezentate
caracteristicile implementate și principiile care stau la baza aplicației și care fac posibilă
funcționarea eficientă a platformei și concureța acesteia cu alte aplicații de renum ite
aparținând acest ui domeniu.

– 6 –
1. ARHITECTURA APLICAȚIE I

1.1 Arhitectura unei aplicații web
Poate varia foarte mult în funcție de scopul aplicației pentru care se dezvoltă. Unele
caracteristici nu pot lipsi din implementare, cum ar fi partea de front -end deoarece doar prin
intermediul acesteia un utilizator po ate interacționa cu mediul dezvoltat, în timp ce altele
reprezintă necesități fundamentale sau chiar opționale .
1.2 Arhitectura multi -stratificată
Este cunoscută și sub denumirea de „arhitectur ă multi -terță” sau „arhitectură
client -server” în care func țiile de prezentare și prelucrare a aplicațiilor sunt separate fizic de
gestiunea datelor. Prin împărțirea unei aplicații pe straturi, dezvoltatorii dobândesc opțiunea
de a modifica sau adăuga un anumit strat, ceea ce este mult mai puțin costisitor decât a
reconstrui întreaga aplicație. Cea mai răspandită utilizare a arhitecturii multi -stratificate este
arhitectura pe trei niveluri , ce oferă un model prin care se pot crea aplicații flexibile și
reutilizabile.
1.2.1 Arhitectura pe trei niveluri
Reprezintă un mode l de arhitectură software client -server în care interfața
utilizatorului, logica proceselor funcționale, stocarea și accesul la date sunt dezvoltate și
menținute ca module independente, cel mai adesea platforme separate (Figura 1.1). Acesta a
fost dezvolta t de John J. Donovan în „Open Enviroment”, o companie pe care a fondat -o la
Cambridge, Massachusetts. Altfel spus, reprezintă un model de design software și o
arhirectură software foarte bine definită atât din perspectivă conceptuală, cât și funcțională.
În afară de avantajele obișnuite ale software -ului modular cu interfețe bine definite,
arhitectura pe trei niveluri are rolul de a permite oric ăruia dintre cele trei niveluri să fie
modernizat sau înlocuit în mod independent, ca răspuns la modificările ceri nțelor sau
tehnologiei. De exemplu, o schimbare a sistemului de operare în nivelul de prezentare ar
afecta numai codul interfeței utilizatorilor. De obicei, interfața utilizatorul ui este
implementată pe un calculator desktop și utilizează o interfață grafi că standard cu diferite
module care rulează pe serverul de aplicații. Sistemul de gestiune a l bazelor de date
relaționale de pe serverul de baze de date conține logica de stocare a datelor din computer.

– 7 –

1.2.1.1 Nivelul de prezentare
Acesta este cel mai importa nt nivel al aplicației. Cunoscut și ca „nivelul client” sau
„front -end”, acesta oferă informații referitoare la servicii, cum ar fi în cazul de față
vizualizarea taskurilor, ședințelor sau rapoartelor. Acesta comunică cu celelalte două niveluri
prin care afișează rezultatele la nivel de browser. În termeni simpli, este un strat prin
intermediul căruia utilizatorii pot avea acces direct în aplicație.
După cum am menționat anterior, nivelul de prezentare este ceea ce se mai numește și
„front -end”. Datele din acest strat trebuie să ajungă la browserul utilizatorului , care
transformă apoi sursa codului într -o pagină accesibilă utilizatorului. Acesta este de obicei
scris în limbajul de markup HTML, limbajul CSS pentru stilizarea paginilor și JavaScript
pentru fu ncționalitate. Desigur există mai multe tehnologii front -end disponibile, spre
exemplu : Adobe Flash.
Din punct de vedere arhitectural, aceste fișiere sunt serv ite dintr -o varietate de surse
cache ale unei aplicații web la scară largă . În sensul că limbaju l HTML ar putea fi livrat de la
diverse acceleratoare web sau cache -uri proxy , cum ar fi Varnish, în timp ce fișierele CSS și
JavaScript pot fi livrate dintr -o altă sursă precum CDN ( Content Delivery Network ). Aceasta
este o rețea distribuită global de ser vere proxy implementate în mai multe centre de date, care
are scopul de a oferi utilizatorilor produsul cu disponibilitate și performanță ridicată. Printre
sursele de distrib uire cunoscute se numără Akamai, care este unul dintre cele mai vechi CDN,
conside rat chiar cel mai cuprinzător la nivel global, ce are servere pretutindeni și o gamă largă
de produse și servicii.
Figura 1.1 Arhitectura pe trei niveluri

– 8 –
1.2.1.2 Nivelul de aplicație
Acest nivel mai este cunoscut și sub denumirea de „nivelul server” sau „back -end”,
adică partea din spate în care se u tilizează în mod normal un limbaj de programare , precum :
Java, Python, Ruby sau PHP, dar lista posibilitățior este mult mai vastă. Partea din spate
decide, de obicei, modul de redare a l front end-ului în funcție de logica de afaceri c are este
implementată p e serverul de aplicații.
Nivelul server implementează logica serv iciului web care se dorește a fi oferită
utilizatorilor. Nivelul logic este scos din nivelul de prezentare și, ca strat propriu, controlează
funcționalitatea unei aplicații prin efectuarea un or procesări detaliate. Rolul acestui strat este
de a stoca date persistente, efectua toate activitățile de actualizare a bazelor de date sau
transmiterea datelor stocate către interfața utilzatorului. Acest nivel nu este vizibil
utilizatorilor, putând răs punde doar la cererile HTTP (HyperText Transfer Protocol ) pentru o
anumită adresă URL ( Uniform Resource Locator ), nu la orice tip de accesare a utilizatorului.
Rolul serverului este de a accepta solicitarea unei cereri HTTP, cum ar fi interogarea
bazei de date, un script dinamic sau o cerere pentru descărcare de fișier și de a o executa. De
aici provine și denumirea de server, fiind destinat sa servească. Pentru ca toate acestea să fie
posibile, există diverși furnizori, spre exemplu: Apache, JBoss sau Glas sFish, permițând astfel
îmbinarea acestor servere pe diferite straturi, în funcție de nevoile de dezvoltare.
1.2.1.3 Nivelul de date
Acesta include atât mecanismele de persistență a datelor , precum servere de baze de
date sau dosare de fișiere, cât și stratul d e acces la date care încapsulează mecanismele de
persistență și expune datele. Stratul de acces la date trebuie s ă furnizeze API -uri pentru
nivelul aplicațiilor pe care expune sau să creeze dependențe de mecanismele de stocare a
datelor. Evitarea dependenț elor permite actualizări sau modificări, fără ca utilizatorii la nivel
de aplicație să afectați sau chiar conștienți. Ca și în cazul separării oricărui nivel, există
costuri de i mplementare și, adesea, costuri pentru performanță, în vederea obținerii unei mai
bune mentenanțe a aplicației.
Pentru ca majoritatea aplicațiilor web sa funcționeze, trebuie să poată stoca datele de
obicei într -o bază de date , care este critică în dezvoltarea atât în medi ul academic, cât și în
industria software . Printre sistemele de gestiune a bazelor de date relaționale se numără :
MySQL, Oracle, PostgreSQL, SQL Server sau HBase. Fiecare dintre acestea salvează datele

– 9 –
într-o manieră unică și oferă caracteristici diferite. Unele dintre ele stochează date tabelare, în
timp ce altele rețin chiar perechi de chei -valoare simple, depinzând de nevoile clientului.
Abstractizarea bazei de date este o interfață de programare a aplicațiilor , care unifică
comunicarea dintre o aplicație informatică și o bază de date. Fiecare furnizor de baze de date
oferă o interfață proprie adaptată la produsele sale, lăsând utilizatorul să implementeze codul
pentru toate interfețele pe care acesta dorește să le sprijine. Straturile de abstractizare a le bazei
reduc cantitatea de lucru , prin furnizarea u nui dezvo ltator API consecvent care ascund e
specificațiile bazei de dat e din spatele acestei interfețe.
O modalitate de a crea o abstractizare este aceea de a folosi ceea ce se numește în
general o mapare ORM ( Object Relational Mapping ). Acest strat presupune separ area codului
necesar datelor , de sursa de date propriu -zisă, permițând astfel modificări asupra unui nivel,
fără a afecta celelalte niveluri și oferind astfel o mentenanță mai ușoară a aplicației. Un
exemplu foarte bun este JDO ( Java Data Objects ). De asem enea, majoritatea framework -urilor
moderne furnizează propriile ORM -uri, care implementează configurații stabile pentru
furnizorii de baze de date obișnuite. Desigur, ORM -ul fiecărui framework este implementat și
configurat doar pentru dezvolta rea în acel framework .
1.3 Modelul arhitectural MVC
Model -View -Controller, prescurtat MVC, este un model architectural software pentru
implementarea interfețelor utilizatorilor. Acesta împarte o aplicație dată în tre i părți
interconectate (Figura 1 .2) pentru a separa rep rezentările interne ale informațiilor , de
modalitățile în care acestea sunt prezentate și acceptate de utilizator i. Modelul de design
MVC decuplează aceste componente majore, permițând reutilizarea eficientă a codului și
dezvoltarea independentă a modulelo r.
Acest model este popular în practică deoarece izolează logica aplicației de stratul de
interfață a utilizatorului și susține separarea intereselor . Deși inițial a fost dezvoltat pentru
computere desktop, MVC a fost adoptat pe scară largă ca arhitectură pentru aplicațiile World
Wide Web (WWW) în limbaje de programare importante, precum: Java, C#, PHP sau Ruby.
Aceste limbaje utilizează arhitecturi populare MVC care sunt folosite în prezent în
dezvoltarea aplicațiilor web out-of-the-box. Acest principiu e ste cunoscut și ca off-the-shelf ,
reprezentând o caracteristică a unui produs de a funcționa imediat după instalare, fără a fi
necesară o configurație sau modificare ulterioară .

– 10 –
Pentru dezvoltarea arhitecturii MVC au fost create mai multe framework -uri web, atât
comerciale, cât și necomerciale, c are să pună în aplicare modelul : Django, ASP.NET sau
Rails. Aceste framework -uri software variază în interpretările lor, în principal în modul în
care responsabilitățile MVC sunt împărțite între client și server. Î ncă de la început a existat o
abordare bazată pe client, care a plasat întregul model, vizualizarea și logica controlerului pe
server. În această abordare, clie ntul trimite fie o solicitare hyperlink , fie o execuție de
formular web, primind înapoi o pagină web completă și actualizată sau alt document. Pe
măsură ce tehnologiile clientului au ajuns la maturitate, au fost create framework -uri precum
AngularJS sau JavaScriptMVC , care permit componentelor MVC să fie executate pe
partea client ului.
1.3.1 Modelul
Modelul reprezintă componenta centrală a arhitecturii, exprimând comportamentul
aplicației în ceea ce privește domeniul de activitate , independent de interfața utilizatorul ui.
Acesta administrează direct atât datele, logica și regulile aplicației, cât și accesul la date și
actualizările acestora. În software -ul unei întreprinderi, un model funcționează deseori ca o
aproximare a unui proces din lumea reală.
În cazul de față, modelul reprezintă un JavaBean care transportă date și urmează un set
de reguli. Ce l mai frecvent, bean -urile folosesc metode accesor de tip „getter” și „setter”
pentru a își proteja variabilele membre, care sunt în mod obișnuit private, și au un constructor
public fără argumente, spre deosebire de POJO ( Plain Old Java Object ) care este folosit
pentru a descrie aceleași lucruri ca o clasă normală. De asemenea, modelul poate implementa
un proces logic pentru a actualiza controlerul , dacă se solicită schimbarea datelor acestuia.
Modelul este responsabil pentru gestiunea datelor sale și de a răspunde solicitărilor sau
instrucțiunilor primite din vizualizare , prin actualizarea datelor cerute.
1.3.2 Vizualizarea
Această componentă facilitează prezentarea datelor conținute în model și răspunde
eficient la cererea operatorului de a vizualiza datele î ntr-un anumit format. O vizualizare
poate fi orice reprezentare de ieșire a informațiilor, precum o diagramă sau o pagină web,
generând o nouă ieșire pentru utilizator pe baza modificărilor apărute în model.
Vederea redă conținutul unui model, specificând exact modul în care vor fi prezentate
datele sale. Dacă modelul se modifică, vizualizarea va actualiza prezentarea dup ă cum este
necesar. Acest lucru poate fi reali zat prin utilizarea unui model push , în care vizualizarea este

– 11 –

responsabilă pentru a apel a modelul atunci când trebuie să actualizeze datele. Acestea sunt
sisteme bazate pe script, precum : JSF, JSP, ASP sau PHP, care sunt foarte ușor de integrat cu
tehnologia AJAX.
1.3.3 Controlerul
Această componentă este responsabilă pentru a răspunde solicitării utilizatorului și
pentru efectuarea interacțiunilor asupra obiectelor modelului de date. Controlerul primește
intrarea, o validează, o convertește în comenzi și apoi efectuează operația care modifică starea
modelului de date. Acesta acționează atât asupra modelului, cât și a vizualizării, controlând și
actualiz ând fluxul de date în model ori de câte ori datele acestuia se modifică.
Controlerul traduce interacțiunile utilizatorului cu vizualizarea, în acțiunile pe care
modelul le va efectua. Într -un client G UI (Graphic User Interface) autonom, interacțiunile
utilizatorilor ar putea fi apăsări de butoane sau s elecții de meniuri, în timp ce într -o aplicație
web enterprise apar ca solicitări HTTP de tip GET și POST . De asemenea, în funcție de
context, un control er poate să aleagă o nouă vizualizare, spre exemplu o pagină web de
rezultate, pentru a le prezenta înapoi utilizatorului.

Figura 1.2 Modelul arhitectural MVC

– 12 –
1.4 Baza de date
O bază de date reprezintă o colecție organizată de date. Mai exact , aceasta redă
colecția de schem e, tabele, interogări, rapoarte, vizualizări și a altor obiecte. Datele sunt de
obicei organizate pentru a modela aspecte ale realității într -un mod care susține procesele și
care necesită informații, precum modelarea activității angajaților unei companii într-un mod
care să susțină evidența timpului acordat rezolvării unei sarcini sau a dificultăților
întâmpinate. Formal, o bază de date se referă la un set de date c onexe și la modul în care
aceste a sunt organizate . Accesul la aceste date este, de obi cei, furnizat de un sistem de
gestiune a bazelor de date (SGBD) format dintr -un set integrat de software care permite
utilizatorilor să interacționeze cu una sau mai multe baze de date, oferind acces la
toate datele înregistrate în aceasta.
Un sistem de gestiune a bazelo r de date reprezintă , de fapt, o aplicație software care
interacționează cu utilizatorul, cu alte aplicații și cu baza de date pentru a capta și analiza
anumite date. Un SGBD cu scop general este conceput pentru a permite defini rea, crearea,
interogarea, actualizarea și administrarea bazelor de date. Sistemele SGBD cunoscute includ :
MySQL, PostgreSQL, Micros oft SQLServer, Oracle sau MemSQ. Î n cazul de față eu am ales
MySQL pentru gestiunea datelor. O bază de date nu este, în gene ral, portabilă între diferite
SGBD -uri, dar acestea pot comunica utilizând standarde precum: SQL ( Structured Query
Language), ODBC (Open Database Connectivity ) sau JDBC ( Java Database Connectivity )
pentru a permite unei singure aplicații să funcționeze cu mai multe SGBD -uri. Sistemele de
gestiune a bazelor de date sunt deseori clasificate în funcție de modelul de bază de date pe
care îl susțin, cele mai populare sisteme de baze de date începând cu anii 1980 , facilitând
modelul relațional așa cum este reprez entat de limbajul SQL.
Sistemele de gestiune a bazelor de date existente oferă diferite funcții care permit
gestiunea unei baze de date și a datelor acesteia, care pot fi clasificate în patru grupuri
funcționale principale: definirea datelor adică crearea , modificarea și eliminarea definițiilor
care caracterizează organizarea datelor, actualizarea care presupune introducerea, modificarea
și ștergerea datelor reale, recuperarea , care are rolul de a furniza informații într -o formă direct
utilizabilă sau care va necesita prelucrare ulterioară prin intermediul altor aplicații, iar ultimul
grup funcțional îl reprezintă administrarea care presupune înregistrarea și monitorizarea
utilizatorilor, consolidarea securității datelor, monitorizarea performanței, menține rea
integrității datelor, gestiunea controlului concurenței și recuperarea informațiilor.

– 13 –
1.4.1 Schema bazei de date
O schemă a unei baze de date reprezintă structura sa descrisă într -un limbaj formal,
susținut de sistemul de gestiune a l bazelor de date. Ter menul schemă se referă la organizarea
datelor ca un model al manierei în care este construită baza de date, împărțită în tabele de
baze de date în cazul bazelor de date relaționale. Definirea formală a unei scheme de bază de
date este un set de formule num ite constrângeri de integritate impuse unei baze de date.
Aceste constrângeri de integritate asigură compatibilitatea între părți ale schemei. Toate
constrâ ngerile sunt exprimabile în acel ași limbaj . O bază de date poate fi considerată o
structură în reali zarea limbajului bazei de date. Stările unei scheme conceptuale create sunt
transformate într -o mapare explicită ce descrie modul în care entitățile din lumea reală sunt
modelate în baza de date.
Schema relațională a unei baze de date este alcatuită din nu mele tabelelor scrise cu
majuscule, fiind specificate pentru fiecare tabel, între paranteze rotunde, cheia primară
precedată de simbolul #, atributele sale care devin coloane în tabel, urmate apoi de cheile
externe ce reprezintă legaturi cu tabelele ascoci ate. Schema bazei de date pe care apliația
„Cronos” o are implementată este descrisă în cele ce urmează:
MODEL_ENTITY (#id, date_entered, version)
USER (#id, name, surname, username, password, email, receive_log, temporary, manager_id,
department_id, model _entity_id)
USER_PROFILE (#id, address, phone, date_of_birth, postal_code, user_id, model_entity_id)
ROLE (#id, name, description, model_entity_id)
USER_ROLE (#user_id, #role_id)
TASK (#id, status, priority, type, approved_date, brief_id, owner_id, departm ent_id)
DEPARTMENT (#id, name, model_entity_id)
MEETING (#id, subject, start_date, end_date, model_entity_id)
DEPARTMENT_MEETING (#department_id, #meeting_id)
COMMENT (#id, text, task_id, user_id, model_entity_id)
TIME_TRACKING (#id, time_worked, status, t ask_id, user_id, model_entity_id)
LOG (#id, action, task_id, user_id, model_entity_id)
BRIEF_DESCRIPTION (#id, name, model_entity_id)
DESCRIPTION (#id, instructions, resolution, task_id, model_entity_id)
MAIL_RECIPIENT (#id, subject, content, user_id, mode l_entity_id)

– 14 –

1.4.2 Modelul bazei de date
Reprezintă un tip de model de date care decide structura logică a unei baze de date și
determină fundamental modul în care datele pot fi stocate, organizate și manipulate. Un
sistem de gestiune a bazelor de date poate furniza unul sau mai multe modele. Str uctura
optimă depinde de organizarea naturală a datelor aplicației și de cerințele aplicației, care
includ viteza, fiabilitatea, întreținerea, scalabilitatea și costul operațiilor. Cele mai multe
sisteme de gestiune a le bazelor de date sunt construite în j urul unui model particular de date,
deși este posibil ca produsele să ofere suport pentru mai multe modele. Diferite modele de
date fizice pot implementa orice model logic dat. Majoritatea software -urilor de baze de date
oferă utilizatorului un anumit nive l de control în reglarea implementării fizice, deoarece
alegerile făcute au un efect semnificativ asupra performanței.
În funcție de modelul de bază de date utilizat, acesta poate include entități, relații,
fluxul de date, tabele, cardinalitatea și opționa litatea. Unele dintre modelele de baze de date
utilizate în practică includ modele de entitate -relație, modele relaționale, modele ierarhice,
modele de fișiere, modele orientate pe obiecte și modele de rețele. Cel mai popular exemplu al
unui model de bază de date este modelul entitate -relație. Entitatea se referă de obiecei la o
persoană, obiect, concept, eveniment, activitate care este semnificativ ă pentru ceea ce se
dorește a fi modelat. Relația reprezintă o comunicare între două sau mai multe entități,
existența acesteia fiind subordonată existenței entităților pe care le leagă.
Pentru proiectarea diagramei entitate -relație au fost stabilite un set de reguli, dar
acestea nu sunt unice. Entitățile (tabelele) sunt reprezentate prin dreptunghiuri, relațiile dintre
entități sunt reprezentate prin arce la capătul carora este reprezentată cardinalitatea și
opționalitatea (Figura 1.3) , atributele care reprezintă chei primare sunt precedate de
abrevierea PK sau de simbolul #, iar atributele obligatorii sunt scri se cu font îngroșat.

Figura 1.3 Legenda diagramei entitate -relație

– 15 –

Figura 1.4 Diagrama entitate -relație

– 16 –
În diagra ma prezentată anterior (Figura 1 .4) sunt evidențiate toate entitățile în care ,
prin intermediul aplicației „Cronos” , sunt stocate date esențiale pentru funcționarea eficientă a
acesteia. Tabela „Model Entity” este mo ștenită ca „schelete” de toate entitățile care nu
reprezintă tabele asociative, aceasta având rolul de a le generaliza, fiind necesară cunoașterea
versiunii și a datei intrării in baza de date a fiecărui obiect.
Tabela „User” reține datele angajaților înre gistrați pe platformă, date care sunt
necesare autentificării (username, password), date personale esențiale identificării (name,
surname, email) și date necesare trimiterii de e-mailuri. De asemenea, de observă asocierea
acestei tabele cu ea însăși prin c oloana „manager_id”, care este populată cu valoarea cheii
primare a managerului sau valoarea null dacă angajatul este manager în departament și
asocierea cu entitatea „Department” prin coloana „department_id”, fiind necesară cunoașterea
departamentului în care angajatul activează. În această din urmă tabelă se regăsește pe lângă
cheia primară, doar coloana care redă denumirea departamentului (name). Tabela „User
Profile” este asociată tabelei „User” prin coloana „user_id” și reține date personale ale
angaj atului, care nu sunt vitale pentru activitatea sa pe platformă (city, street, address,
date_of_birth). Tabela „Mail Recipient” conține date necesare trimiterii unui e -mail de
notificare (subject, content) unui anumit angajat (user_id).
Tabela „Task” stoche ază datele fiecărei sarcini înregistrate pe platformă, fie acestea
date descriptive (status, priority, type, brief_description), date necesare managerilor
(approved, approved_date) sau date de identificare a departamentului, creatorului sau
deținătorului a sociat (department_id, assignee_id, owner_id). Tabela „Brief Description”
reține un atribut ce reprezintă o scurtă descriere, generală, a scopului pentru care a fost
deschisă această sarcină, fie ea o problemă sau o dezvoltare. Tabela „Description” conține
instrucțiunile necesare rezolvării unei cerințe, iar dacă aceasta a fost rezolvată va deține și
modul în care a fost soluționată.
Tabela „Comment” stochează actualizarea pe care un utilizator a efectuat -o asupra
unei cerințe (text), pentru a se cunoaște întotdeauna cum a decurs rezolvarea acesteia. Tabela
„Time Tracking” reține date necesare pentru a se cunoaște cât timp a petrecut un utilizator
(time_worked) în rezolvarea unui pas intermediar al cerinței. Tabela „Log” reține acțiunea
care a intervenit î n actualizarea unei cerințe (action), fie aceasta o schimbare a priorității, a
statusului, a categoriei sau a departamentului asociat unei cerințe.
Tabela „Meeting” stochează date necesare pentru ca o ședință sa aibă loc (subject,
start_date, end_date). T abela „Role” păstrează rolurile, sau altfel spus drepturile, pe care un

– 17 –
utilizator le poate avea pe platformă cu scopul de a determina asupra căror acțiuni îi este
permis accesul (name, description). Entitatea „User Role” a fost creată cu scopul de a elim ina
dependențele redundante dintre cheia primară a tabelei „User” și atributul ce reține rolul,
aducând astfel modelul entitate -relație în „a doua formă normală”. Tabela „Department
Meeting” are rol de tabel ascociativ, altfel spus aceasta elimină legătura „Many -To-Many”
dintre tabelele „Department” și „Meeting” pentru a aduce modelul bazei de date în „a treia
formă normală”, având cheia primară compusă din cheia străină a departamentului
(department_id) și cea a ședinței (meeting_id).
1.5 Modele de proiec tare software
Când vorbim de modele de proiectare software, cunoscute și ca modele de d esign
software (din eng.: design patterns) , în general ne referim la componente individuale ale
sistemului, la modul în care acestea pot interacționa cu alte componente software, la modul în
care va acționa sistemul, l a cum entitățile interacționează cu celelalte componente si interfețe
sau la interfața utilizator externă.
În ingineria software, un astfel de model reprezintă o soluție generală, reutilizabilă a
unei probl eme care se produce în mod obișnuit într -un anumit context la proiectarea
software -ului. Acesta nu constituie un design finit care să poată fi transformat direct în cod
sursă, ci este o descriere sau un șablon pentru a rezolva o problemă care poate fi ut ilizată în
diferite situații. Modelele de design software sunt cele mai bune practici formalizate pe care
programatorul le poate utiliza pentru a rezolva probleme comune atunci când proiectează o
aplicație sau un sistem, acestea putând fi văzute ca o abord are structurată a programării pe
calculator între nivelurile unei paradigme de programare și algoritmul concret.
1.6 Limbajul UML
O modalitate de a vizualiza planurile arhitecturale ale unui sistem într -o diagramă este
prin limbajul general, de dezvoltare UML ( Unified Modeling Language ), care este destinat să
ofere o modalitate standard de a vizualiza proiectarea unui sistem. Deși nu este o metodă de
dezvoltare în sine, a fost conceput astfel încât să fie compatibil cu metodele de dezvoltare
software orient ate spre obiect ale zilelor noastre, de exemplu metodele: OMT ( Object
Modeling Technique ) sau RUP ( Rational Unified Process ). Pentru ca acestea să fie posibile,
UML a fost extins la un set cuprinzător de diagrame: diagrama de componente, diagrama de
clase, diagrama use -case, diagrama de stări, diagrama de pachete, diagrama de obiecte și
diagrama de colaborare.

– 18 –
Este important să se facă distincția între modelul UML și setul de diagrame ale unui
sistem. O diagramă reprezintă o reprezentare grafică parțială a modelului unui sistem. Setul de
diagrame nu trebuie să acopere complet modelul, iar ștergerea unei diagrame nu va afecta
restul modelul ui. Acesta poate conține, de asemenea, documentația care conduce elementele
modelului și diagramele, de exemplu redactare a cazurilor de utilizare.
Schemele UML reprezintă două vederi diferite ale unui sistem: afișarea statică și
afișarea dinamică. Afișarea statică sau structurală accentuează structura statică a sistemului
folosind obiecte, atribute, operații și relații, inc luzând diagrame de clasă și diagrame
structurale compuse, spre deosebire de afișarea dinamică sau comportamentală care
accentuează comportamentul dinamic al sistemului, prezentând colaborări între obiecte și
schimbări ale stărilor interne ale acestora , inc luzând vizualizare a diagrame lor de secvențe,
diagrame lor de activitate și diagrame lor de stare .
1.6.1 Diagrama cazurilor de utilizare
O diagramă a cazurilor de utilizare este o reprezentare a interacțiunii unui utilizator cu
sistemul care arată relația dintre a cesta și diferitele cazuri de utilizare în care este implicat,
identificând diferitele tipuri de utilizatori ai unui sistem. Diagramele de caz sunt folosite
pentru a strânge cerințele unui sistem care să includă atât influențele interne, cât și pe cele
externe. Aceste cerințe sunt în mare parte cerințe de proiectare, iar atunci când un sistem este
analizat pentru a clarifica funcționalitățile acestuia, se pregătesc cazuri de utilizare și se
identifică tipurile de utilizatori.
Datorită naturii lor simpliste, utilizarea diagramelor de cazuri poate fi un bun
instrument de comunicare pentru părțile interesate. Componentele diagramei au fost
concepute pentru a imita lumea reală și a oferi părții interesate posibilitatea de a înțelege cum
va fi proiectat sistemul. Siau Sing și Joshua Lee au efectuat cercetări pentru a determina dacă
există o situație valabilă în cazul urmăririi schemelor de cazuri de utilizare sau dacă acestea
nu sunt necesare, constatând că diagramele cazurilor de utilizare au transmis intenția
sistemului într -o manieră simplificată.
În timp ce un caz de utilizare în sine ar putea detalia despre fiecare posibilitate, o
diagramă de caz poate ajuta la furnizarea unei vizualizări mai înalte a sistemului, aceasta
oferind o reprezentare grafică simplifi cată a funcționalităților pe care sistemul trebuie să le
îndeplinească.

– 19 –

Pentru a descrie sistemul din punct de vedere al utilizatorului, a fost creat un set de
reguli ce trebuie respectate în reprezentarea elementelor principale de proiectare (Figura 1.5).
Dintre acestea fac parte cazurile de utilizare care sunt unități coerente de funcționalitate, fiind
alcătuie dintr -un set de cerințe ce reies din specificațiile inițiale si modelate pe parcurs.
Actorii pot fi clase de utilizatori uman i sau aplicații care interacționează cu sistemul, fiecare
reprezentând un rol pe care îl are un utilizator în cadrul acestuia. În cazul aplicației „Cronos”,
cele trei tipuri de actori principali sunt: angajatul, managerul si administratorul.
Un aspect important al reprezentă rii diagramei îl constituie relațiile dintre un actori si
cazuri de utilizare. Relația include arată că secvența de evenimente descrisă în cazul de
utilizare inclus se găsește și în secvența de evenimente a cazului de utilizare de bază. Săgeata
care marche ază această relație este reprezentată printr -o linie discontinuă orientată către cazul
de utilizare inclus și este marcată cu expresia <<include>> . Relația extend este folosită
pentru separarea diferitelor comportamente ale cazurilor de utilizare. În gener al, este folosită
pentru a evidenția excepțiile care apar atunci când un caz frecvent întâlnit, adică principal,
trebuie separat de un caz mai rar întâlnit, adică excepțional, condiționat de un anumit aspect.
Săgeata care exprimă această relație este repre zentată printr -o linie discontinuă, orientată către
cazul principal și marcată cu expresia <<extend>> . Relația de generalizare poate exista atât
intre două cazuri de utilizare, cât și între doi actori, evidențiând o anumită versiune a unei
cerințe. General izarea unui caz de utilizare, reprezintă faptul că acesta are un comportament
asemănător unui alt caz de utilizare. Generalizarea unui actor, indică faptul că acesta
moștenește comportamentul și structura unui alt actor. Săgeata care marchează această rela ție
este reprezentată printr -o linie continuă, orientată către elementul de la care se pornește
generalizarea.

Figura 1.5 Legenda diagramei UML a cazurilor de utilizare

– 20 –

Figura 1.6 Diagrama UML a cazurilor de utilizare

– 21 –
1.6.2 Diagrama de clase
În ingineria software, o diagramă UML de clase reprezintă un tip de diagramă a
structurii statice care descrie stru ctura unui sistem prin afișarea claselor sistemului, a
atributelor acestora, a metodelor și a relațiilor dintre obiecte.
Diagrama de clase este blocul principal de modelare orientată pe obiecte, fiind folosit
atât pentru modelarea conceptuală, generală a f uncționalității aplicației, cât și pentru
modelarea detaliată a traducerii modelelor în susrsa codului. Diagramele de clasă pot fi de
asemenea utilizate pentru modelarea datelor. Clasele dintr -o diagramă de clasă reprezintă atât
elementele principale și in teracțiunile din aplicație, cât și clasele care urmează a fi scrise.
Schema de clase este în principiu o reprezentare grafică a vederii statice a sistemului și
reprezintă diferite aspecte ale aplicației. O colecție de diagrame de clasă trebuie să reprezinte
întregul sistem. Pentru a proiecta și înțelege o astfel de diagramă au fost stabilite un set de
reguli ce trebuie respectate în realizarea acesteia. În diagramă, clasele sunt reprezentate prin
casete împărțite în trei compartimente: compartimentul supe rior care conține numele clasei și
este scris centrat, în caractere aldine, având prima literă capitalizată, compartimentul din
mijloc care conține atributele clasei, acestea fiind scrise aliniate la stânga, având prima literă
mică și compartimentul inferi or care conține metodele pe care le poate executa un obiect al
clasei, fiind de asemenea scrise aliniate la stânga și având prima literă mic ă. Pentru fiecare
membru al unei clase, fie el atribut sau metodă, trebuie specificată vizibilitatea pe care acesta
îl are in cadrul sistemului, putând fi public, privat, protejat, derivat sau vizibil doar în
interiorul pachetului de care aparține (Figura 1.7 ).
Figura 1.7 Legenda vizibilității Figura 1.8 Legenda tipurilor de relații
membrilor unei clase a unei diagrame UML de clase

– 22 –
Pentru a înțelege cum interacționează clasele unui sistem, a fost de asemenea c reat un
set de relații (Figur a 1.8) care acoperă tipurile specifice de conexiuni logice găsite în
diagramele de clasă și obiect. Relația de dependență reprezintă o legătură semantică între
elementele de model dependente și independente. Relația de asociere constituie o familie de
legături și de obicei este bidirecțională sau uni -direcțională, putând fi însoțită de indicatori de
proprietate, multiplicitate sau vizibilitate. Relația de agregare poate apărea atunci când o clasă
reprezintă o colecție sau un container de clase, dar care nu au o dependență puternică pe
durata ciclului de viață în container. Relația de moștenire, sau de generalizare, indică faptul că
o subclasă este considerată a fi o formă specializată a unei superclase. Relația de
implementare reprezintă o relație între două elemente de model, în care un element model
(clientul), implementează sau execută comportamentul specificat de al doilea element model
(furnizorul). Ultima, dar nu cea din urmă, este relația de compoziție care conectează două
clase, una din ele incluzând -o pe cealaltă. Respectând regulile menționate anterior, am realizat
diagrama de clase corespunzătoare aplicației „Cronos”, descriind structura sistemului și
modul în care clasele din pac hete interacționează (Figura 1.9 ).
Figura 1.9 Diagrama UML de clase

– 23 –
În continuare, voi prezenta mai d etaliat rolul fiecăruia dintre cele pat ru pachete:
controller (Figura 1 .10), entities (Figura 1 .11), util (Figura 1 .12) și user (Figura 1 .13), prin
evidențierea tuturor atributelor și metodelor implementate de sistem .
Figura 1.10 Diagrama de clase a pachetului controller

– 24 –

Figura 1.11 Diagra ma de clase a pachetului entities

Figura 1.12 Diagrama de clase a pachetului util

Figura 1.13 Diagrama de clase a
pachetului user

– 25 –
2. PREZENTAREA TE HNOLOGIILOR UTILIZATE

2.1 Java ca limbaj și framework
Java este un limbaj de programare de nivel înalt, dezvoltat de Sun Microsy stems astfel
încât să conțină câ t mai puține dependențe de implementare posibil. Acesta a fost inițial
conceput pentru dezvolta rea de aplicații desktop și dispozitive portabile, dar mai târziu a
devenit o alegere populară pentru crearea de aplicații web.
Sintaxa Java este similară cu cea C++, dar utilizează strict limbajul de programa re
orientat pe obiecte (Figura 2 .1). Majoritate a programelor Java conțin clase care sunt folosite
pentru a defini obiecte și metode care reprezintă atribuite ale unor clase individuale. În Java,
variabilele și funcțiile trebuie definite explicit, acest lucru producând adesea mai multe erori
sau excepți i decât alte limbaje de programare, dar totodată limitează și alte tipuri de erori care
pot fi cauzate de variabilele nedefinite sau de tipurile de date neinițializate .
Este greu să expunem un singur motiv pentru care acest limbaj de programare a
devenit atât de des întâlnit în practică, dar putem enumera câteva dintre elementele și
principiile care au avut un rol important în obținerea succesului: este un limbaj strict orientat
obiect, oferă portabilitate în rețea, instrucțiunile nu conțin adrese ale spa țiului de memorie,
aplet -urile (aplicațiile mici) oferă flexibilitate, iar developerii pot învăța usor acest limbaj.
Figura 2.1 Exemplu de cod în Java

– 26 –
2.1.1 Librării în Java
Java Class Library (JCL) este un set de biblioteci încărcate dinamic pe care aplicațiile
Java le pot apela la momentul ex ecuției. Deoarece platforma Java nu depinde de un anumit
sistem de operare, aplicațiile nu se pot baza pe nici una dintre bibliotecile native ale
platformei. În schimb, platforma Java oferă un set complet de biblioteci de clasă standard,
care conțin funcți ile comune sistemelor de operare moderne.
JCL servește în cadrul platformei Java trei mari caracteristici: spre deosebire de alte
biblioteci standard, acesta oferă programatorului un pachet bine -cunoscut de facilități, spre
exemplu: clasele de containere s au prelucrarea expresiilor regulate. De asemenea, acesta
dezvoltă o interfață abstractă pentr u cerințe care în mod normal depinde în mare măsură de
hardware și de sistemul de operare, cum ar fi accesul la rețea sau la fișiere. Unele platforme
nu pot accept a toate funcțiile pe care le așteaptă o aplicație Java, în aceste cazuri
implementarea bibliotecii poate fie să emuleze acele caracteristici, fie să ofere o modalitate de
a verifica prezența unei caracteristici specifice.
Facilitățile JCL sunt accesate pri n intermediul claselor furnizate în pachete precum:
java.lang ce conține clase si interfețe fundamentale strâns legate de execuție și de sistemul de
operare, java.io sau java.net ce fac posibilă citirea, scrierea și accesarea în rețea a platformei
sau a fi șierelor, pachetul java.math ce oferă expresii și evaluări matematice sau pachetele
java.security ce oferă servicii de securitate sau criptare.
2.1.2 Java Mail
Java Mail este , de fapt , un API ce oferă un framework independent de protocol și
platformă pentru a co nstrui aplicații cu transmitere de mesaje electronice. Acesta pune la
dispoziție un set de clase abstracte care definesc obiecte constituite dintr -un sistem de e -mail.
Pachetele javax.mail și javax.mail.activation conțin clasele de bază ale API -ului
JavaM ail, prin care este facilitată citirea, compunerea și trimiterea mesajelor electronice.
JavaMail este este integrat în platforma Java EE, dar oferă și un pachet opțional pentru
utilizarea în Java SE, a prot ocoalelor SMTP, POP sau IMAP. Simple Mail Transfe r Protocol
(SMTP) este unul dintre cele mai dese protocoale utilizate în practică, oferind un mecanism
de livrare a e -mailurilor sigur și eficient. Dac ă se achiziționează spațiul de host, un server
SMTP va fi oferit de către furnizor, fiind apoi necesară a utentificarea pentru trimiterea și
primirea de e -mailuri.

– 27 –

2.1.3 Java Quartz
Un planificaor de sarcini constituie , de fapt, o aplicație care rulează independent de
programul de lucru și care furnizează de obicei un singur punct de control pentru definirea și
monitorizarea execuțiilor din back -end într-o rețea distribuită de computere. Acesta poate
executa diferite tipuri de sarcini: interogări asupra bazei d e date, plugin -uri sau trimiterea de
e-mailuri asincron.
Din această categorie face parte Java Quartz, ce dezvoltă un framework de planificare
puternic și avansat pentru a ajuta utilizatorul să planifice o metodă care să ruleze la un anumit
moment de timp. Acest framework este scris în întregime în Java, conceput pentru utilizarea
aplicațiilor implementate atâ t pe platforma J2SE, cât și pe J2EE, oferind flexibilitate și
păstrând simp litatea. Planificatorul de tip Quartz oferă două tipuri de declanșatoare:
declanșatorul simplu și declanșatorul cron. În cazul în care programul se bazează pe intervale
specificate, atunci un declanșator simplu va fi suficient, dar dacă metoda trebuie rezolvată pe
baza unor noțiuni asemănătoare calendarului, atunci trebuie să utilizat e declanșatoarele cron
(Figura 2 .2), care sunt puternice, dar pot fi și destul de confuze.

2.1.4 Difere nța între Java SE/EE/ME/FX
Există patru platforme ale limbajului de programare Java: platforma Java Standard
Edition (Java SE), platforma Java Enterprise Edition (Java EE), platforma Java Micro Edition
(Java ME) și platforma Java Special Effects (Java FX). Toate platformele Java sunt alcătuite
dintr -o mașină virtuală Java (VM) și o interfață de programare a aplicațiilor (API). Mașina Figura 2.2 Exem plu de Quartz declanșat la fiecare cinci minute

– 28 –
virtuală Java este un program dezvoltat pentru o anumită platformă hardware și software, care
rulează aplicații Java. Un API reprezintă o colecție de componente software care pot fi
utilizate pentru a crea alte componente sau aplicații software, ce pot fi rulate pe orice sistem
compatibil.
Atunci când ne referim la limbajul de programare Java, de obicei ne gândim la
platforma Ja va SE. API -ul Java SE oferă funcționalitatea de bază a limbajului de programare
Java, definind totul, de la tipurile și obiectele de bază ale limbajului de programare Java, la
clasele de nivel înalt care sunt utilizate pentru crearea de rețele, securitate, accesul la baze de
date, dezvoltarea grafică a interfeței utilizator (GUI) și parsarea fișierelor XML. Pe lângă
API-ul de bază, platforma Java SE constă într -o mașină virtuală, instrumente de dezvoltare,
tehnologii de implementare și alte biblioteci de cl asă și seturi de instrumente utilizate în mod
obișnuit în aplicațiile dezvoltate cu tehnologia Java.
Platforma Java EE este construită pe platforma Java SE. Platforma Java EE oferă un
mediu API și un mediu de execuție pentru dezvoltarea și funcționarea apl icațiilor de rețea la
scară largă, multi -nivel, scalabile, fiabile și securizate. Platforma Java ME oferă un API și o
mașină virtuală cu amprentă mică pentru a rula aplicații de limbaj de programare Java pe
dispozitive mici, cum ar fi telefoanele mobile. A PI-ul este un subset al API -ului Java SE,
împreună cu bibliotecile de clasă speciale, utile pentru dezvoltarea aplicațiilor de mici
dimensiuni. Aplicațiile Java ME sunt adesea clienți ai serviciilor de platformă Java EE.
JavaFX este o platformă pentru crea rea de aplicații grafice, bazate pe un API user-friendly .
Aplicațiile JavaFX oferă grafică și suport clienților cu performanțe, dar care la rândul lor pot
fi clienți ai serviciilor de platformă Java EE.
2.1.5 Platforma Java EE
Java Enterprise Edition, sau pe sc urt Java EE, constă într -o colecție de tehnologii și
API-uri ( Application Program Interface ) pentru platforma Java concepută cu scopul de a
dezvolta și implementa aplicațiile realizate pentru întreprinderi ce pot fi clasificate ca aplicații
distribuite, tr anzacționale si accesibile, în vederea susținerii cerințelor de afaceri. În general,
aplicațiile pentru întreprinderi se referă la software -ul găzduit pe servere care furnizează
serviciile pe care le suportă compania.
Furnizorul de produse Java EE este de obicei un furnizor de aplicații server,
web-server sau bază de date care pune la dispoziție clase ce implementează interfețele definite
în specificații. Acești furnizori concurează cu privire la implementările specificațiilor

– 29 –

platformei JEE. Ca ș i în cazul altor specificații JCP ( Java Community Process ), furnizorii
trebuie sa îndeplinească anumite cerințe de conformitate pentru a declara produsele lor ca
fiind compatibile cu JEE.
Cele treisprezece tehnologii ce alcatuiesc Java EE sunt: JDBC ( Java Database
Connection ), JNDI ( Java Naming and Directory Interface ), EJB ( Enterprise Java Bean s), RMI
(Remote Method Invocation ), JSP ( Java Server Pages ), Servlets, XML ( Extensible Markup
Language ), JMS ( Java Message Service ), IDL ( Interface Definition Langu age), JTS ( Java
Transaction Service ), JTA (Java Transaction API), JavaMail și JAF ( Java Activation
Framework ). Versiunea curentă a platformei JEE a suferit numeroase modificări de când a
fost lansată pentru prima dată în primăvara anului 1998, sub denumirea de JPE ( Java
Professional Edition ), până în prezent la pr oaspăta lansare a versiunii JEE 8.
2.1.5.1 Framework -ul de aplicații JSF
JavaServer Faces (JSF) este o specificație Java dezvoltată pentru construirea
interfețelor pentru utilizatori, bazate pe componente pentru aplicații web și formalizată ca
standard prin inte rmediul procesului comunitar Java, care face parte din Platforma JEE. Este,
de asemenea, un framework web MVC care simplifică construirea de interfețe utilizator (UI)
pentru aplicațiile bazate pe server, utilizând componente UI reutilizabile.
Ultima vers iune de JSF folosește Facelets ca sistem de template -uri implicit, dar care
poate utiliza și alte tehnologii de vizualizare. În schimb, versiunea anterioară de JSF utilizează
JavaServer Pages (JSP) ca sistem de template -uri implicit.

2.1.5.1.1 Librăria PrimeFa ces
PrimeFaces reprezintă o bibliotecă alcatuită din componente pentru interfața
utilizatorului și de asemenea este open source pentru aplicațiile dezvoltate în JSF. Pe lângă
aspectul deosebit, evoluat față de HTML5, dar compatibil cu acesta, componentele Figura 2.3 Exemplu de pagină JSF

– 30 –

PrimeFaces dezvoltă capabilități AJAX, independente de browserul folosit. În plus, acesta
aduce PrimeFaces Push, bazat pe framework -ul Atmosphere, PrimeFaces Extensions, care
este o bibliotecă uș or de implementat, de asemenea open -source în JSF , colecția v astă de
widget -uri JavaScript bazate pe interfața jQuery și ultima, dar nu cea din urmă este biblioteca
add-on PrimeElements, bazată pe componente web și dezvoltată pentru a crea interfețe pentru
utilizator cu elemente de HTML personalizate.
De când a apă rut pentru prima dată în 2008, a fost mult imbunatățită prin introducerea
de componente dinamice, verificări Captcha, facilități AJAX, iteratoar e, componente de tip
media sau drag&drop , elemente specifice pentru dezvoltarea mobile, componente de
securitate , diagrame sau rapoarte, dar și alte caracteristici aduse elementelor deja existente.
2.1.5.1.2 Tehnologia AJAX
Asynchronous JavaScript și XML (AJAX) utilizează obiecte JavaScript pentru a
trimite date către server și pentru a primi date de la acesta în mod asincro n. Astfel, folosind
tehnologia Ajax, codul JavaScript schimbă datele cu serverul și actualizează componente ale
paginii web fără a reîncărca întreaga pagină.
Framework -ul JSF oferă suport pentru efectuarea de apeluri Ajax, oferind un tag f:ajax
pentru a g estiona aceste apeluri (Figura 2 .4). Componentele de referință cu utilizatorul din
Mojarra (implementarea de referință JSF) și Apache MyFaces au fost inițial dezvoltate doar
pentru HTML, iar tehnologia Ajax trebuia integrată prin JavaScript. Acest aspect s -a
schimbat, JSF suportând în prezent mai multe formate de ieșire, compatibile cu Ajax, ce pot fi
ușor integrate pentru a îmbunătăți interfețele utilizatorilor. Specificația JSF 2.x oferă suport
integrat pentru Ajax, permițând evenimentelor declanșate de cl ient să treacă prin validare
înainte de a returna rezultatul înapoi la browser prin intermediul unei actualizări XML. Acest
lucru este facilitat de biblioteca de resurse JavaScript prin care componentele JSF precum
butoane, link -uri sau câmpuri de text, po t fi activate cu ajutorul Ajax. De asemenea metodele
sale pot fi apelate direct din codul sursă al unui JavaBean. În plus, modelul de componente al
framework -ului JSF poate fi extins, personalizarea fiind efectuată cu tehnica Ajax.

Figura 2.4 Exemplu de tag JSF pentru gestiunea apelurilor Ajax

– 31 –
2.1.5.2 Specificația JPA
Java Persistence API (JPA) reprezintă nu un produs, ci o specificație Java, pentru
accesarea, persistența și gestiunea datelor între obiectele Java și o baza de date relațională,
fiind considerată în prezent abordarea standard a industriei pentru ORM în indu stria Java.
JPA a fost definită ca parte a arhitecturii EJB, printr -un set de interfețe ce necesită o
impleme ntare. Există dezvoltări JPA open -source pentru alegerea oricărui tip de server de
aplicații, oferind suport pentru utilizarea acestuia. De asemen ea, aceasta permite ca obiectele
Java obișnuite (POJO) să fie ușor persistente, fără a fi necesare clase care să implementeze
interfețe sau metode suplimentare. JPA permite maparea obiectelor relaționare prin adnotări
standard sau fișiere XML care definesc modul în care o clasă Java este asociată unei tabele
din baza de date. Din pachetul javax.persistence fac parte adnotările ce reprezintă cele patru
moduri de relaționare: @ManyToMany , @ManyToOne, @OneToMany și @OneToOne.
Totodată, JPA definește un API EntityManager (Figura 2.1), pentru executarea interogărilor și
tranzacționarea obiectelor în baza de date.
2.1.5.3 Arhitectura EJB
Enterprise Java Beans (EJB) este o arhitectură de dezvoltare pentru construirea
aplicațiilor la nivel de întreprindere, scalabile și ro buste care urmează să fie implementate pe
serverul de aplicați i compatibil cu J2EE, precum: TomEE, JBoss sau WebLogic.
Arhitectura EJB, una dintre multele API -uri Java pentru construcția modulară a
software -ului unei întreprinderi, este o componentă softw are de server care încorporează
logica de afaceri a unei aplicații. Un container web EJB oferă un mediu de rulare pentru
componentele software legate de web, în care este facilitează gestiunea ciclului de viață al
servletului Java sau procesarea tranzacții lor primite de la server.
2.1.5.4 Standardul CDI
Context Dependency Injection (CDI) reprezintă standardul Java ce simplifică API -ul
pentru injecția de dependență (DI) și interceptare (AOP) și care poate fi încorporat în orice
aplicație Java. Printre caracteristic ile CDI se regăsesc procesarea adnotărilor pentru
configurare precum @Inject sau @Qualifiers și crearea de componente pluggable . CDI este
un aspect fundamental al Java EE și este susținut de un număr mare de servere de aplicații
printre care se numără: IBM's WebSphere, Glassfish Oracle sau Red Hat's JBoss.

– 32 –
2.1.5.5 Serializarea bean -urilor
Prin definiție Java bean -urile sunt clase care încap sulează mai multe obiecte într -un
singur obiect, cu proprietatea că sunt serializabile, au un constructor cu argument fără
parametrii și permit accesul la proprietăți prin utilizarea de metode accesor de ti p getter și
setter (Figura 2 .1).
Un bean are prop rietatea de persistență atunci când câmpurile și informațiile de stare
sunt salvate și extrase din spațiul de stocare. Modelele componente oferă un mecanism de
persistență ce permite stocarea componentelor într -un loc nemodificabil pentru recuperarea
ulterioară. Mecanismul care face posibilă persistența se numește serializare. Serializarea unui
obiect înseamnă convertirea acestuia într -un flux de date și scrierea sa în memorie. Orice
aplicație sau instrument care utilizează bean -uri poate reconstitui inform ația prin deserializare,
aducând obiectul la starea inițială.
Pentru ca un bean să poată fi persistat, acesta trebuie să accepte serializarea prin
implementarea interfe ței java.io.Serializable sau java.io.Externalizable . Aceste interfețe oferă
opțiunile de serializare automată și serializare personalizată. Dacă o clasă din ierarhia de
moșten ire a unei clase implementează Serial izable sau Externalizable , atunci acea clasă este
la rândul ei serializabilă. Printre clasele notabile care nu ac ceptă serializarea se regăsesc
Thread sau Socket , iar încercarea de a serializa aceste clase sau o clasă moștenită din acestea
va genera o excepție de tip NotSerializableException .
2.1.6 Framework -ul Hibernate
Object Relational Mapping (ORM) în știința informaticii este o compone ntă software
dezvoltată pentru reprezentarea și conversia datelor între limbajul de programare orientat
obiect și sistemul de gestiune al bazei de date, prin intermediul căreia se creează o „bază de
date virtuală” care sa comunice cu limbajul. O astfel de soluție open -source este reprezentată
de framework -ul Hibernate ORM , prescurtat doar Hibernate, care permite dezvoltatorilor să
scrie mai ușor aplicații ale căror date depășesc un anumit nivel de complexitate.
Ca fra mework de mapare a obiectelor, Hibernat e se aplică bazelor de date relaționale
având grijă de procesul de persistență a datelor, rezolvând problemele de nepotrivire a
obiectelor -relaționale prin înlocuirea accesărilor directe și permanente ale bazei de date cu
funcții de manipulare a obiectelor la nivel înalt. Funcția principală Hibernate este maparea de
la clase Java la tabele în baze de date și maparea de la tipurile de date Java la tipurile de date

– 33 –
SQL. Hibernate oferă, de asemenea, facilități de interogare și de recuperare a datelor prin
generarea de apeluri SQL, evitând manevrarea și conversia manuală a setului de rezultate.
Maparea claselor Java în tabelele de baze de date este implementată prin configurarea
unui fișier XML sau prin utili zarea adnotărilor Java (Figura 2 .5). Prin intermediul unui fișier
XML, Hibernate poate genera cod sursă pentru clasele persistente, dar aceasta devine doar o
funcție opțională atunci când se utilizează adnotări. Hibernate poate folosi fișierul XML sau
adnotările Java pentru a organiza schema bazei de date. Î n plus față de gestiunea asocierilor
între obiecte, acesta poate gestiona obiecte care sunt în relație cu unul sau mai multe
instanțe ale claselor.
În practică, framework -ul Hibernate oferă multiple avantaje: mapaează enumerațiile
Java în coloane și le interpretează ca proprietăți obișnuite, are o performanță rapidă, deoarece
memoria cache este utilizată intern, implementează un limbaj independent de interogare a
bazei de date (HQL), care ese versiunea orientată obiect a limbajului SQL, oferă posibili tatea
de a crea automat tabelele bazei de date, fără a fi necesară crearea manuală a acestora,
simplifică interogările complexe care preiau date din mai multe tabele și dispune de statistici
ale interogării stării bazei de date.
Figura 2.5 Exemplu de entitate mapată în Hibernate

– 34 –
2.1.6.1 Persistența datelor
Întregu l concept de Hibernate se rezumă la a lua valorile atributelor clasei Java și de a
le persista într -o tabelă a bazei de date. Clasele Java ale căror obiecte sau instanțe vor fi
stocate în tabelele bazei de date se numesc clase persistente care urmează prin cipii orientate
obiect, incluzând moștenirea, asocierea, compoziția. Hibernate nu necesită interfețe sau clase
de bază, permițând oricărei clase sau structuri de date să fie persistente.
Totodată acesta funcționează cel mai bine atunci când respectă un se t de regu li,
cunoscute sub denumirea de POJO : toate clasele Java ce urmează a fi persistate au nevoie de
un constructor implicit și de o un cod unic ce va fi mapat ca și cheie primară pentru a permite
identificarea ușoară a obiectelor bazei de date, toate atributele ce vor fi persistate trebuie
declarate private și să di spună de metode accesor de tip getter și setter , toate clasele care nu
extind sau nu implementează alte clase sau interfețe speciale trebuie integrate in cadrul EJB.
2.1.6.2 Conexiunea cu baza de d ate
JPA, ca specificație Java API care descrie gestiunea datelor relaționale în aplicații
utilizând platforma Java, în timp ce Hibernate este o bibliotecă ORM care urmează
specificațiile JPA. Ne putem gândi la JPA ca la un set de reguli implementat de Hibe rnate. În
concluzie, JPA nu este o implementare și nu va oferi niciun fel de funcționalitate
concretă aplicației, ci are scopul de a furniza un set de reguli și orientări care să poată fi
urmate de furnizorii de implementare din cadrul JPA pentru a crea o dezvoltare ORM într -o
manieră standardizată.
Toate implementările JPA acceptă caracteristicile definite în specificații și adesea pot
extind e funcții personalizate. Un furnizor JPA este Hibernate. Când apar modificări ale
specificațiilor, Hiberna te va lansa implementarea actualizată a specificațiilor JPA. Alți
furnizori populari ai JPA sunt EclipseLink (EL) sau OpenJPA (OJPA) .
Fișierul persistence.xml (Figura 2.6) se bazează pe o structură definită de standardul
JPA și furnizează configurația fur nizorului de persistență, driver -ul bazei de date și
informațiile de conectare. Fișierul persistence.xml este în multe feluri similar cu fișierul
hiberante.cfg.xml , în măsura în care deține informațiile pe care implementarea JPA o va folosi
pentru a se con ecta la baza de date. Atunci când se solicită framework -ului de persistență al
JPA să furnizeze aplicației noastre o componentă care să gestioneze entitățile noastre, va
returna atributul din campul name al tag -ului <persistence -unit> .

– 35 –
Algoritmul Hibernat e de conexiune este considerat desul de rudimentar, în măsura în
care nu este destinat utilizării într -un sistem de producție sau pentru testarea performa nțelor.
Java Database Connectivity (JDBC) definește modul în care clientul poate accesa baza de
date și este distribuit împreună cu Hibernate, prin intermediul pachetului
org.hibernate.connection .
2.1.6.3 Limbajul HQL
Hibernate oferă un limbaj personalizat de tip SQL, numit Hibernate Query Language
(HQL), care permite ca interogările SQL să fie scrise pentru ob iectele de date Hiber nate. HQL
este un super -set al Java Persistence Query Language (JPQL), în care orice interogare
JPQL este validă pentru HQL, dar nu și invers, acesta dezvoltând un limbaj cu o sintaxă
și gramatică proprie.
Criteriile de inte rogare sunt independente de baza de date și folosite pentru a modifica
obiectele și pentru a oferi restricții pentru acestea, evitând problemele de mentenanță. Deși
similar cu SQL, în loc să opereze pe tabele și coloane, HQL lucrează cu obiecte persistente și
proprietățile acestora. Interogările HQL sunt traduse de Hibernate în cereri SQL
convenționale care, în schimb, efectuează acțiuni asupra bazei de date. Hibernate oferă de
asemenea un API prin intermediul căruia se pot emite instrucțiuni SQL native, da r este
recomandat să fie folosit HQL ori de câte ori este posibil pentru a evita eventualele probleme
ale portabilității bazei de date și pentru a profita de strategiile de generare ale SQL Hibernate.
Hibernate acceptă named parameters în interogările HQL (Figura 2 .5), furnizând
nume pentru parametrii din cererea HQL cu scopul de a evita indexarea parametrilor după
ordinea în care apar in interogare, facilitând persistența în baza de date a informațiilor primite
de la client și evitând injectarea automată c u cod SQL.
Figura 2.6 Conexiunea cu MySQL prin fișierul pe rsistence.xml

– 36 –
2.2 Apache Web Server
Un server web este , de fapt , un software care primește cererea HTTP de a accesa o
pagină web, rulează anumite verificări de securitate asupra acesteia și apoi întoarce pagina
web spre vizualizare. În funcție de pagina care a fo st solicitată, aceasta poate cere serverului
să ruleze câteva module suplimentare în timp ce se generează documentul pentru vizualizare.
Apache este cel mai popular software de server web. Acesta permite unui computer să
găzduiască una sau mai multe platfo rme care pot fi accesate prin Internet utilizând un browser
web. Din 1999, grupul Apache a devenit Apache Software Foundation, o organizație non –
profit care susține în prezent dezvoltarea software -ului de server Apache Web. Pe piața web,
Apache a câși gat o popularitate mare, fiind open -source , având o documentație cuprinzătoare
și suportând, de asemenea, mai multe platforme, inclusiv sisteme de operare Linux, Windows
și Macintosh. Deoarece majoritatea di stribuțiilor Linux sunt și ele open-source,
implementa rea server ului Apache pe sistemul de operare Linux a devenit cea mai populară
configurație de host web.
Apache poate găzdui atât site -uri web statice, precum și site -uri dinamice care
utilizează limbaje de scripting din partea serverului, cum ar fi PHP, Py thon sau Perl. Suportul
pentru aceste și alte limbaje este implementat prin module sau pachete de instalare care extind
instalarea standard Apache și care oferă opțiuni de securitate avansate sau instrumente de
gestiune a fișierelor.
2.2.1 Apache Tomcat
Tomcat este un server de aplicații distribuit de Apache Software Foundation care
execută servlet -uri Java și redă pagini web care pot include pagini JS P sau JSF. Descrisă ca o
implementare de referință a specificațiilor Java Servlet, Java ServerPages, Java Expres sion
Language (JEL) și Java WebSocket , Tomcat este rezultatul unei colaborări deschise a
dezvoltatorilor, putând fi folosit ca produs independent, cu propriul server web intern sau
împreună cu alte servere web, inclusiv Apache, Netscape Enterprise Server s au Microsoft
Personal Web Server .
Software -ul Apache Tomcat este dezvoltat într -un mediu deschis, oferind
numeroaselor aplicații web pe scară largă și cu scopuri complexe o gamă variată de industrii
si organizații în care să poată dezvolta aproape orice ti p de produs .

– 37 –
2.2.1.1 Containerul Catalina
Catalina este containerul de servlet al Tomcat. Acesta implementează specificațiile
Sun Microsystems pentru servlet și JSP. În Tomcat, un element Realm reprezintă o bază de
date cu nume de utilizator, parole și roluri atribuite utilizatorilor. Implementările diferite ale
Realm permit containerului Catalina să fie integrat în medii în care astfel de informații ale
autentificării sunt deja create și întreținute, urmând apoi să folosească aceste inf ormații pentru
a implem enta un Container Managed Security (CMS) .
2.2.1.2 Conectorul HTTP Coyote
Coyote este o componentă conector pentru Tomcat care acceptă protocolul HTTP ca
server web. Ac est lucru îi permite lui Catalina , denumit în mod obișnuit un servlet Java sau un
container JS P, să acționeze ca un server web simplu care interpretează fișierele locale ca
documente HTTP. Coyote primește conexiunile de intrare la server de pe un port TCP speci fic
și transmite cererea către T omcat Engine pentru a procesa cererea și a trimite un răs puns
înapoi clientului solicitant, oferind o performanță rapidă.
2.2.1.3 Mecanismul Jasper
Jasper este mecanismul JSP al lui Tomcat. Acesta analizează fișierele JSP pentru a le
compila în cod Java ca servlet -uri, care pot fi gestionate de containerul Catalina. În timpul
execuției, Jasper detectează modificările aduse fișierelor JSP și le recompilează. Fiecare
marcaj de etichete din fișierul JSP este gestionat de o clasă handler de etichete, ce poate fi
reutilizat în întregul servlet. Paginile pot fi inserate și incluse într -un fișier JSP în timpul
rulării, nefiind recompilat decât cu modificări ale fișierelor JSP, ci și cu modificările paginii
incluse.
2.2.2 Apache TomEE
Apache TomEE (Tomcat + EE) este un server Java EE certifica t web, compatibil cu
profilul Java Ente rprise, care combină multiple proiecte Java, precum: OpenEJB, OpenJPA,
MyFaces sau WebBeans cu serverul Tomcat . TomEE e ste, de fapt , o extensie a server ului
Tomcat, fiind asamblat din fișiere Tomcat și biblioteci suplimentare ce permit folosirea
mediului J ava EE, facilitând integrarea cu Tomcat si reducând timpul suplimentar de muncă.
TomEE necesită un mediu Java Enterprise Runtime care să respecte specificațiile JRE.

– 38 –

2.2.3 Apache Maven
Apache Maven este un instrument de gestiune și de înțelegere a proiectelor software,
bazat pe conceptul unui POM (Project Object Model) ce poate manageria construirea,
raportarea și documentarea unui proiect dintr -o informație centrală.
Maven este văzut ca procesul de automatizare a l creării unui software și a proceselor
asociate , utilizat în principal pentru proiecte Java. Acesta abordează două aspecte legate de
construirea de software: în primul rând, descrie modul în care este construit software -ul și, în
al doilea rând, descrie dependențele acestuia. Un fișier XML, creat cu de numirea de pom.xml
(Figura 2.8), descrie proiectul software construit, dependențele acestuia de alte module și
componente externe, ordinea de construire, directoarele și plug -in-urile necesare. Acesta vine
cu obiective predefinite pentru a efectua anumite sarcini, spre exemplu: compilarea codului
sau interprerarea pachetelor.
Maven descarcă în mod dinamic bibliotecile Java și plug -in-urile Maven di n unul sau
mai multe repository și le stochează într -un cache local. Pe lângă Java, Maven poate fi de
aseme nea, utilizat pentru a construi și administra proiecte scrise în C#, Ruby, .NET și
alte limbaje avansate de programare.
Figura 2 .7 Structura unui proiect Maven Figura 2 .8 Dependențele din fișierul pom.xml

– 39 –
2.2.4 Apache POI
Apache POI (Poor Obfuscation Implementation ) este o librărie denstinată pentru a
crea și menține Java API -uri, manipu lând diferite formate de fișiere bazate pe standardele
Office Open XML (OOXML). Cu ajutorul acestei librării este posibilă citirea și scrierea
fișierelor Microsoft Office Excel, Word sau PowePoint utilizând programe Java,
complexitatea acestora depinzând d e tipurile de date care se doresc a fi scrise.
Apache POI este un API popular, open -source dezvoltat și distribuit de Apache
Software Foundation , care pentru proiectarea sau modificarea fișierelor Microsoft Office
folosește clase și metode ce decodează da tele introduse de utilizator într -un document MS
Office. Pachetul org.apache.poi conține clasele necesare pentru decodificarea acestui format.
2.2.5 Apache FOP
Apache FOP (Formatting Objects Processor) este o librărie car e facilitează programele
Java să converte ască fișierele XSL FO (Formatting Object) în format PDF sau alte formate
imprimabile. FOP este un software open -source, făcând parte din proiectul Apache XML
Graphics și distribuit sub licența Apache.
O aplicație Java care implementează această librărie po ate citi un arbore de obiecte
formatate, interpretându -l de obicei într -un document PDF. Arborele citit poate fi sub forma
unui document XML sau poate fi trecut în memorie ca un document DOM. Un obiectiv
secundar al software -ului FOP este de a furniza o ve rsiune ulterioară a formatului în
conformitate cu standardul descris în XSL FO. Un alt scop al utilizării FOP într -o aplicație
Java este îmbunătățirea conversiei fișierelor SVG în format PDF.
2.2.6 Apache XML Beans
Dezvoltat de Apache Software Foundation , XMLBea ns este o librărie care permite
accesul la fișiere XML prin intermediul aplicațiilor Java. Scopul acesteia este de a avea
caracteristicile acestor fișiere mapate cât se poate de natural și eficient în limbajul Java.
XML Beans utilizează schema XML pentru a compila interfețe și clase Java care pot fi
apoi folosite pentru a accesa și modifica datele de instanțelor XML. Atunci când o instanță
XML este parsată, ea va fi păstrată pentru utilizarea ulterioară de către dezvoltator. XML
Beans sprijină lucrul cu fi șiere XML și clasele asociate acestora, oferind metode pentru toate
funcționalitățile schemei.

– 40 –
2.3 Limbajul de markup HTML
Oricine folosește mediul online a întâlnit cel puțin câteva instanțe de HTML și s -ar
putea ca nici să nu fi știut măcar despre aceasta. Acronimul HTML (Hyper Text Markup
Language) , reprezintă limbajul de markup primar, utilizat pentru a scrie conținut web. Orice
pagină web vazută în browser, include cel puțin un marcaj HTML inclus în codul sursă.
Informațiile sunt partajate indiferent de locul în care a fost localizat un computer, prin
utilizarea de hyperlink -uri HTML sau HTTP (Hyper Text Transfer Protocol) care reprezintă
un protocol de comunica re pentru serverele web printr -un sistem de adrese URL (Uniform
Resource Locator), simplificat pentru fiecare pagină web de pe Internet. Browserele web
primesc documentele HTML structurate semantic de la un server web sau de la o adresă
locală, interpretându -le ca pagini web multimedia.
Ca limbaj de markup, HTML constă în mai multe componente cheie , numite tag -uri,
atribute ale acestora, tipuri de date bazate pe caractere, referințe de caractere sau de entități.
Tag-urile HTML sunt scrise cel mai frecvent în perechi, având între tag -ul de deschidere și cel
de închidere conținut text ( <p> … </p> ), dar există și elemente fără conținut intern ( <img> ).
2.3.1 Structura unui document HTML
Elementele html, head și body au fost parte a specificațiilor HTML încă de la apariția
acestuia, iar până la dezvoltarea standardului HTML5 care a adăugat o colecție de elemen te
cu înțeles semantic bogat, au fost considerate elemente principale folosite pentru a reda
structura documentelor HTML.
Orice element HTML trebuie să fie incadrat de tag -ul <html>, care se deschide la
începutul documentului și se închide la sfârșitul ac estuia. Orice element care apare în afara
acestuia poate produce erori în interpretarea codului HTML de către browserul web.
Elementul <head> apare imediat după eticheta de deschidere html. În interiorul acestuia sunt
plasate elemente precum: titlul, meta date, link -uri către foi de stil CSS sau fișiere de scripting
JavaScript. Tot conținutul care este vizibil pe o pagină web este încadrat între etichetele de
deschidere și închidere ale tag -ului <body> , acesta fiind containerul principal al conținutului
care formează o pagină web. Browserele web interpretează sursa HTML conținută de paginile
web, dar nu afișează codul acestora, în schimb codificarea HTML va fi tradusă în conținut
lizibil uti lizatorilor.

– 41 –
2.3.2 Standardul HTML5
HTML5 este o colaborare între World Wide Web Consortium (W3C) și Web
Hypertext Appli cation Technology Working Group (WHATWG). Acest standard include
caracteristici precum redarea video sau funcția de drag& drop , care a u fost dependente de
plugin-uri ale browserelor, cum ar fi Adobe Flash sau Microsoft Silverlight. Un apect
important al HTML5 este acela că nu reprezintă o singură entitate. Este alcătuită din multiple
componente, printre care cea de -a cincea versiune a HTML, CS S3 și multe API -uri
JavaScript, permițând utilizarea experienței multimedia a platformei web.
Cu ajutorul HTML5 se pot crea aplicații și site -uri care să funcționeze ca aplicații
desktop, permițând utilizarea platformei web simultan de către mai mulți uti lizatori. Aceștia
nu mai sunt nevoiți să descarce aplicații externe pentru diferite dispozitive sau să verifice dacă
dispun de ultima versiune . Un alt aspect i nteresant al HTML5, este acela că permite crearea
de aplicații care funcționează chiar și atunci când sistemul este offline, având capacitatea de a
stoca date în memoria cache și de a le păstra chiar dacă pagina va fi reîncărcată. Pentru ca un
document să fie interpretat în HTML5, ace sta trebuie să conțină declarați a
<!DOCTYPE html> la încep utul acestuia (Figura 2 .9).
HTML5 introduce în plus o serie de elemente și atribute care ajută la construirea unui
site web modern, atât din perspectiva design -ului, cât și a funcționalității. O importanță
deosebită pentru înțelegerea conținutului HTML este adusă de tag -urile semantice, noi în
HTML5, printre care se regăsesc: <header>, <footer>, <article> sau <nav> . Pentru a obține
mai multe informații prin intermediul unui formular web, au fost adăugate noi atribute
tag-ului <input> . De asemenea, oferă imple mentare pentru WebSocket , o tehnologie avansată
de comunicare bidirecțională a aplicațiilor web, dar și pentru elemente grafice precum canvas
sau geolocation , care facilitează interacți unea cu JavaScript.

Figura 2 .9 Exemplu de document HTML5

– 42 –
2.3.3 Extensia XHTML
Extensible Hypertext Markup Language (XHTML) face parte din familia limbajelor
de marcare XML. Acesta exti nde versiunile limbajului HTML utilizat pe scară largă și în care
sunt formulate paginile web. În timp ce HTML, înainte de HTML5, a fost definit ca o
aplicație a Standard Generalized Markup Language (SGML) care reprezintă, de fapt,
un framework de limbaj flexibil pentru markup, XHTML prezintă o aplicație XML ca un
subset mai restrictiv al SGML.
Documentele XHTML sunt conforme cu XML deoarece sunt ușor de analiz at, editat și
validat prin metode de interpretare standard XML. Acestea sunt scrise pentru a funcționa în
orice browser web și pot utiliza aplicații precum scripturile sau applet -urile care se bazează fie
pe modelul obiect al documentului HTML, fie pe cel al documentului XML.
2.4 Limbajul de stilizare CSS
Cascading Style Sheets (CSS) este un limbaj de programare utilizat pentru prezentarea
și stilizarea unui document scris într -un limbaj de markup, de obicei HTML sau XHTML.
Deși limbajul CSS este ușor de învă țat și de înțeles, acesta oferă un control puternic asupra
prezentării unui document HTML. Cascading este partea specială a limbajului, permițând
paginii web sa fie trecută ca în cascadă printr -o varietate de stiluri, păstrând întotdeauna
ultimul stil vali dat pentru un anumit element.
2.4.1 Structura unui fișier CSS
Limbajul CSS dispune de o sintaxă simplă, usor de învățat, utilizând cuvinte sugestive
ale limbii engleze pentru a specifica diferitele proprietăți ale stilului. O foaie de stil scrisă în
acest limb aj este alcătuită după un set de reguli format dintr -unul sau mai mulți selectori și un
bloc declarativ (Figura 2.10), acestea putând fi combinate în diferite moduri pentru a obține o
mare flexibilitate și specificitate.
În CSS, selectorii reprezintă elem ente care specifică cărei părți a documentului HTML
i se va aplica un anumit stil, prin potrivirea etichetelor și atributelor. Un bloc declarativ constă
într-o listă de declarații, scrisă între acolade, prin intermediul căreia este specificat stilul ce
urmează a fi aplicat selectorilor. Pseudo -clasele sunt folosite în selectorii CSS pentru a
permite formatarea pe baza informațiilor care nu sunt conținute în arborele documentului,
având rolul de a clasifica elementele documentului, în timp ce un pseudo -eleme nt face o
selecție care poate consta din elemente parțiale, spre exemplu prima linie sau prima literă a

– 43 –
unui paragraf. Un exemplu de pseudo -clasă utilizată pe scară largă este hover , care identifică
conținutul doar în momentul în care utilizatorul plasea ză cursorul mouse -ului peste acesta.
2.4.2 Foi de stiluri
Foile de stil sunt specificații tehnice pentru a reda aspectul doumentului web
vizualiz at, putând de asemenea utiliza media queries pentru a schimba felul în care pagina
este prezentată pe diferite device -uri. Orice pagină web este afectată de cel puțin un
style sheet , chiar dacă creatorul nu a aplicat nici o stilizare. Acest lucru se datorează
browserelor web moderne care dispun de stiluri prestabilite, ce pot fi suprascrise, pentru
afișarea ele mentelor HTML sau XHTML. Spre exemplu, hiperlink -urile sunt afișate cu text
subliniat în culoare albastră, iar daca acesta este accesat, culoarea sa va fi schimbată în violet.
Folosind CSS se poate controla culoarea textului, stilul fonturilor, distanța di ntre paragrafe,
modul în care sunt dimensionate și dispuse coloanele, variațiile de afișare pentru diferite
dispozitive și dimensiunile ecranului, precum și o varietate de alte efecte.
Odată scrisă, o foaie de stil CSS poate fi reutilizată în mai multe pa gini HTML.
Stilurile definite pentru elemente HTML se vor aplica în toate paginile în care aceasta este
inclusă. Pentru a face o modificare globală, se va schimba stilul doar din fișierul CSS, urmând
ca la reîncărcarea paginii toate elementele afectate de acel stil să își actualizeze aspectul
automat. Limbajul CSS are o gamă mult mai largă de atribute decât HTML, prin utilizarea
acestora fiind redat un aspect mai plăcut, în comparație cu rezultatul folosirii atributelor
HTML. Ca și HTML, CSS are definită pr oprietatea de a stoca aplicațiile web la ni vel local cu
ajutorul memoriei cache offline , oferind o încărcare rapidă și o performanță îmbunătățită.
2.5 Limbajul de scripting JavaScript
JavaScript (JS) este un limbaj de progr amare utilizat în mod obișnuit pen tru
dezvoltarea aplicațiilor web și pentru adăugarea elementelor dinamice și interactive. La fel ca
alte limbaje de scripting, cum ar fi PHP sau ASP, codul JavaScript poate fi inserat oriunde în
Figura 2 .10 Exemplu de stilizare cu CSS

– 44 –
documentul paginii web. Cu toate acestea, doar codul de pe se rver este afișat în codul HTML,
în timp ce codul JS rămâne vizibil numai în sursa paginii web.
JavaScript este un limbaj de scripting client -side ceea ce înseamnă că procesarea
codului sursă nu este făcută de serverul web, ci de b rowserul web al clientului . Ace st lucru
face posibil ca funcțiile JS să poată fi executate după încărcarea paginii web, fără a comunica
cu serverul. Spre exemplu, o funcție JavaScript poate verifica un formular web înainte de a fi
trimis, pentru a se asigura că toate câmpurile obli gatorii au fost completate, în caz contrar
poate produce un mesaj de eroare înainte ca orice informație să fie transmisă serverului.
2.5.1 Caracteristicile limbajului
JavaScript este aproape în întregime un limbaj orientat pe obiecte. În JS, un obiect este
văzut ca o matrice asociativă, îmbogățită cu un prototip. Fiecare șir cheie furnizează numele
proprietății unui obiect printr -o modalitate sinctatică de a face ref erire la aceasta, folosind
notația dot sau bracket . JavaScript utilizează prototipuri, în timp ce alte limbaje orientate
obiect folosesc clase pentru a extinde alte instanțe, dar aceste prototipuri pot simula
comportamentul unei clase. Prefixarea unui a pel al unei funcții cu notația new va crea o
instanță a unui prototip, moștenind proprietățile și met odele acestuia. În JS nu există nici o
distincție între definiția unei funcții și cea a unei metode, diferențierea având loc în timpul
apelului funcțional.
În general, JavaScript se bazează pe un mediu de rulare, cum ar fi un browser web,
pentru a furniza obiecte și metode prin care scripturile pot interacționa cu documentul web.
De asemenea, prin intermediul mediului de execuție acesta dispune de capacitatea de a
include elemente de scripting. JavaScript procesează mesajel e primite urmând principiul de
coadă. La încărcarea unui mesaj nou, JavaScript va apela funcția asociată acelui mesaj, creând
un cadru de stivă a apelurilor, ce se va micșora sau crește pe baza nevoilor funcției. După
terminarea funcției, atunci când stiva este goală, JavaScript va trece l a următorul mesaj din
coadă. Acest proces este cunoscut sub denumirea de event loop .
2.5.2 Platforma jQuery
jQuery reprezintă un set de instrumente JavaScript proiectat cu scopul de a scrie un
volum mai mic de cod, prin simplificarea anumitor sarcini. Prin inter mediul framework -ului
jQuery este simplificată parcurgerea documentelor HTML, manipularea evenimentelor și
interacțiunilor Ajax, obținând o încărcare rapidă a paginilor web.

– 45 –
Această platformă permite dezvoltatorilor să construiască plugin -uri, în plus față de
librăria JavaScript, pentru modelarea widget -urilor de nivel înalt sau a ef ectelor complexe. De
asemenea, jQuery poate fi utilizat în toate aplicațiile dezvoltate pentru web în diferite limbaje
de programare precum: JSF (Figura 2 .11), ASP sau PHP. Fram ework -ul jQuery facilitează
selectarea, parcurgerea și modificarea conținutului elementelor DOM. De asemenea, acesta
oferă o modalitate simplă de a interacționa cu elementele HTML printr -o gamă vastă de
evenimente, evitând aglomerarea documentului HTML.

2.6 Framework -ul Materialize
„Material Design” este un limbaj de design care creează un mediu vizual pentru
utilizator ii care se bazează pe principiile clasice de design, aducându -le în plus inovația
tehnologiei și a științei. Dezvoltat de compania Google în anul 2014, acesta facilitează
utilizarea layout -urilor bazate pe grilă, a tranzițiilor, anim ațiilor și efectelor speciale.
Materialize reprezintă un framework pentru interfața utilizatorului, dezvoltat cu CSS,
JavaScript și HTML. Acesta este una dint re librăriile moderne de proiectare ale design -ului,
dintre care fac parte și Bootstrap sau Foundation , dar se diferențiază de acestea prin
implementarea de limbaj dedicat device -urilor portabile. De asemenea, Materialize dezvoltă
principii de bază dif erite ale schemelor de culori, formelor, modelelor sau texturilor
șabloanelor, putând adăuga chiar și elemente dinamice acestora, păstrând totodată
portabilitatea browserului web și independența dispozitivului.
2.6.1 Componente CSS și JavaScript
Materia lize include numeroase versiuni, adaptate pentru a urma un material design ,
ale componentelor interfeței utilizatorului, precum: casetele de text sau meniuri selectabile. O
foaie de s till CSS adaptată principiului Materialize definește clasele ajutătoare care pot f i
utilizate pentru layout -uri și componente UI, cum ar fi: butoan ele sau formularele. Fișierul
Materialize JavaScript are rolul de a detecta automat momentul în care interfața utilizatorului
Figura 2.11 Exemplu de metodă jQu ery în JSF

– 46 –
este integrată în modelul obiect al documentului și de a spori e lementele interactive, cum ar fi:
notificările sau elementele selectabile.
Cu scopul de a face framework -ul ușor de u tilizat de către dezvoltatori, Materialize
utilizează funcțiile CSS3 pentru a detecta momentul în care componentele MUI (Material
User Inte rface) sunt integrate în D OM, prin inserarea automată de event handler . Pentru a
oferi dezvoltatorilor control complet asupra implementării, MUI nu utilizează importuri și nu
descarcă fișiere externe. Prin urmare, dacă se dorește utilizarea unui anumit fon t personalizat,
acesta trebuie adăugat în mod explicit paginii și configurat prin CSS.
2.6.2 Avantajele utilizării Materialize
Framework -ul Materialize este construit pe principiul unei arhitecturi responsive ,
astfel încât orice aplicație web dezvoltată folosin d acest framework va fi redimensionată în
funcție de dispozitivul pe care este vizualizată. Site -urile create folosind Materialize sunt pe
deplin compatibile cu laptop -urile, tabletele sau dispozitivele mobile, acest fapt datorându -se
specificațiilor deja implementate ale claselor aparținând acestui framework.
Materialize oferă o stilizare implicită care include componente personalizate și care
perfecționează elementele dinamice integrate într -un document HTML, oferind o experiență
interactivă utilizatorilo r. Prin utilizarea principiilor de material design , s-a creat un sistem
compatibil cu majoritatea platformelor și mediilor de dezvoltare are tehnologiei moderne. De
asemenea, framework -ul furnizează o documentație amănunțită, cu exemple de cod și efecte
ale acestora, pentru a atrage cât mai mulți utilizatori către acesta. Integrarea fișierelor externe
Materialize care descriu implementări ale metodelor CSS și JavaScript, se poate face local
prin descărcarea fișierelor sursă ale acestor componente sa u prin r eferirea la acestea în
Content Delivery Network (CDN), care este o rețe a gobal distribuită de servere proxy
implementată în mai multe centre de date.

– 47 –
3. PREZENTAREA APLICAȚIEI

3.1 Introducere în aplicația „Cronos”
Aplicația constă într -o platfomă web, d estinată gestiunii evenimentelor apărute în
cadrul unei companii , fie acestea probleme sau îmbunătățiri ale funcționalităților .
Monitorizarea timpului de lucru alocat acestor evenimente de către fiecare utilizator și a
parcursului ședințelor de dezvoltare planificate au dus la alegerea denumirii „Cronos” pentru
această platformă internă.
3.1.1 Funcționalitatea aplicației
Nu orice utilizator poate avea acces pe platformă, ci doar un angajat al companiei al e
cărui date au fost introduse î n sistem fie de un manager de depar tament, fie de administratorul
front-end care are acces deplin asupra mentenanței platforme i sau de către administratorul
back -end, care are acces direct pentru a opera asupra bazei de date. Acest lucru este necesar
deoarece în cadrul aplicației s unt discutate aspecte importante ale funcționării sale, produselor
oferite clienților sau chiar ale datel or confidențiale ale acestora.
Pentru înregistra rea din interfața aplicației a unui nou utilizator, va fi necesară trecerea
unei validări C aptcha, evit ând astfel „injectarea” automată a informațiilor în baza de date.
Odată înregistrat un utilizator, acesta va primi un e -mail de înștiințare cu datele noului său
cont, activarea sa fiind necesară în cel mult o zi de la primirea mesajului, în caz contrar con tul
va fi șters automat din sistem.
Aplicația dispune de toate unele necesare gestiunii activității companiei. Oricărui
utiliza tor îi este permisă crearea sau editarea de taskuri, vizualizarea ședințelor și taskurilor la
care este asignat el sau departamen tul căruia aparține, căutare avansată cu filtrare după fiecare
atribut al unui task, vizualizarea notificărilor sau editarea profilului. În plus față de simplii
angajați, utilizatorii cu roluri superioare precum managerii, administratorii sau super -userii, au
acces la mentenanța platformei prin adăugarea sau mutarea departamentelor, administrarea
categoriilor de utilizatori sau vizualizarea de rapoarte ale întregii companii.
3.1.2 Caracteristici tehnice
Platforma este dezvoltată folosind tehnologii de ultimă gen erație în domeniul
aplicațiilor web, acest aspect aducând o performanță superioară și o experiență plăcută
utilizatorilor acesteia.

– 48 –
Pe lângă aspectul vizual deosebit al interfeței web, pe care le oferă framework -urile
PrimeFaces și Materialize , aplicația răspunde eficient acțiunilor utilizatorilor. Acest lucru este
esențial, deoarece angajații au nevoie de eficiență și rapiditate pe parcursul dezvoltării unui
produs sau al rezolvării unei probleme.
De asemenea, prin intermediul unui scheduler Java, aplica ția rulează independent de
platformă metode cu scopuri importante, dar costisitoare ca timp de execuție. C ât timp
serverul este pornit, metodele sunt declanșate la intervale prestabilite de timp pentru a efectua
anumite sarcini, în cazul de față acestea el imină din baza de date de taskurile și ședințele
încheiate în urmă cu mai mult de trei luni, șterg con turile utilizatorilor ale căror conturi sunt
inact ive sau trimit asincron mesaje electronice.
3.2 Structura internă a aplicației
Platforma „Cronos” este îm părțită în cinci module principale, fiecare dintre acestea
fiind implementat pentru a urma în mod eficient sarcini bine stabilite. De asemenea , fiecare
pagină web care este redată în browser interpretează un document XHTML, mapat cu
extensia jsf, dar care este construit urmând principiul Java Bean.
3.2.1 Modulul de autentificare
Aș putea spune că acesta este , de fapt, modulul care stă la baza aplicației , deoarece un
utilizator poate avea acces la informațiile și acțiunile disponibile pe platformă doar dacă
acesta este autentificat în contul său curent.
3.2.1.1 Autentificarea în tr-un cont existent
Acesta este primul pas pe care un utilizator îl va face pentru a putea urmări demersul
taskurilor atribuite lui și pentru a se implica activ în dezvoltare a acestora. Autentifi carea are
log din pagina index.jsf care aduce în interfața web un obiect Java Bean de tip UserSession în
care se vor reține timp de 30 de minut e, dacă nu este apelată metoda de logout , numele de
cont și rolul pe care utilizatorul îl are mapat în cadrul pla tformei.
Definirea clasei UserSession este precedată de anotația @SessionScoped , marcând
faptul că metoda @PostConstruct va fi invocată o singură dată pe sesiune, deși aceasta este de
obicei apelată în momentul în car e un câmp al clasei este adus în interfața web. După
completarea câmpurilor necesare autentificării (username, parolă), la apăsarea butonului de
login , se va apela metoda care mai întâi va cripta parola introdusă , iar apoi va verifica dacă
datele introduse corespund cu cele reținute în baza de date, în caz afirmativ userul va fi

– 49 –
redirecționat către interfața implementată pentru drepturile sale, iar în caz negativ se va afișa
un mesaj corespunzător tipului de eroare .
Numim utilizator temporar un user care și -a uitat parola și a primit un cod de
recuperare prin e -mail sau un user al cărui cont nu a fost încă activat de la înregistrare. Atunci
când un utilizator temporar se autentifică, acesta va fi redirecționat către pagina
changePassword.jsf , unde i se va cere introducerea unei noi parole și va primi în mod dinamic
un review al complexității acesteia , îndrumând astfel utilizatorii să aleagă o parolă complexă
atât din perspectiva dimensiunii, cât și a caracterelor folosite, fără a îi obliga către
această acțiune.
De asemenea, pentru a evita pierderea tuturor conturilor și a datelo r din sistem, la un
eventual atac al bazei de date, am optat pentru a nu reține parola în clar, ci asupra textului
introdus de utilizator în caseta de intrare se va aplica algoritmul de criptare „SHA -256”, iar
apoi se va stoca rezultatul returnat , ca parol ă în baza de date. Am ales utilizarea acestui
algoritm, deoarece se bazează pe criptarea la nivel de biți, mai exact pe 256 biți, pentru fiecare
bit fiind valabile două valori posibile : 0 sau 1. Numărul de hash -uri unice care se pot genera
pentru a atinge toate valorile posibile este egal cu 2 ⁿ, unde n are valoarea 256 , altfel spus,
acest algo ritm este aproape imposibil de spart .
3.2.1.2 Ieșirea din cont
Precum este firesc oricărei platfor me web care deține funcția de autentificare
implementată, sa aibă implementată și funcția care scoate utilizatorul din cont, la fel se
regăsește și în cadrul aplicației „Cronos” . La acționarea butonului de logout , se va apela
metoda care caută instanța cure ntă a sesiunii pe care este mapat utilizatorul, o invalidează și
apoi redirecționează userul către pagina index.jsf , de unde se va putea face din nou
autentificarea. De asemenea, dupa un interval de treizeci de minute , invalidarea sesiunii se va
face automat și va fi necesară o reau tentificare pentru a continua utilizarea aplicației. Această
caracteristică se regăsește implementată în librăria javax.faces , cu scopul de a nu ține prea
multe sesiuni inutil ocupate odată, dacă utilizatorul a închis browserul fără să treacă
prin funcția de logout .
3.2.1.3 Înregistrarea unui cont nou
Spre deosebire de alte platforme web, unde un utilizator își poate crea singur un cont
nou, pentru a avea acces în aplicația „Cronos”, datele acestuia trebuie introduse de către un alt
utilizator cu dreptu ri asupra acestei acțiuni, cum ar fi: managerul, super -userul sau

– 50 –
administratorul. În pagina addUser.jsf este prezent un formular (Figura 3 .1) cu multiple
validatoare pentru datele introduse , asigurându -se astfel că utilizatorul este unic sau că adresa
de e-mail introdusă este una care verifică o anumită expresie regulat ă și de asemenea, un
validator Captcha pentru a evita adăugarea conturilor prin intermediul unui proces automat.
Datele ce trebuiesc a fi completate pentru adăugarea unui cont , sunt strict cele
necesare identificării acțiunilor sale pe platformă: numele, prenumele , adresa de e -mail,
departamentul din care face parte și poziția ocupată în cadrul companiei. Prin intermediul
acestui formular un manager poate adăuga doar un simplu angajat, în ti mp ce un administrator
sau super -user poate adăuga și un manager. Urmând regula după care sunt construite
departamentele, și anume de a dispune de un singur manager la un moment dat, atunci când se
va adăuga un nou manager într -un departament, acesta îl va înlocui pe cel deja existent, iar un
mesaj aferent va apărea în mod dinamic în interfața web.
De asemenea, trebuie cunoscute datele necesare autentificării, username -ul
completându -se automat prin concatenarea numelui cu primul prenume, iar parola, care v a fi
una temporară, va fi completată de către creatorul contului. Datele de autentificare vor fi
transmise prin e -mail, la adresa introdusă, noului utilizator, urmând ca acesta să activeze
contul în cel mult o zi de la primirea înștiințării, în caz contrar contul său va fi șters automat
din baza de date, fiind necesară reînregistrarea sa.

Figura 3 .1 Formularul de înregistrare

– 51 –

3.2.1.4 Editarea datelor personale
Pentru a avea acces la această funcționalitate, din motive de securitate a utilizatorilor,
se va cere confirmarea parolei pen tru contul curent autentificat. Pagina myProfile.jsf aduce în
interfața web un obiect Java Bean în care sunt reținute atât da tele utilizatorului din tabela
„User”, cât și din cea „User Profile”, pentru a putea modifica orice informație personală a sa.
În plus față de datele introduse la înregistrarea contului, un utilizator poate completa și
alte informații personale, precum : data nașterii, orașul și strada de domiciliu, codul poștal sau
numărul de telefon. Pentru validarea numărului de telefon am evitat fo losirea unei expresii
regulate, verificarea făcându -se prin intermediul unei clase Java, ce acționează precum un
validator, apelul metode i personalizate de verificare făcându -se din interfața web .
Deoarece uneori căsuța poștală electronică devine prea aglo merată cu notificări ,
utilizatorului i se oferă posibilitatea de a dezactiva opțiunea implicit adăugată la crearea
contului, de a primi prin e -mail întregul istoric al unui task atribuit lui, la apariția unei
modificări al acestuia. În afară de a evita mod ificarea datelor personale de către un utilizator
căruia nu îi aparține contul autentificat, c onfirmarea parolei la intrarea pe pagină se datorează
și faptului că din interiorul acesteia este permisă schimbarea parolei necesară la autentificare .
3.2.1.5 Recupera rea parolei
În prezent, pe majoritatea platformelor web este necesară autentificarea în cont
folosind un username și o parolă. Dacă nu obișnuim sa folosim aceeași parolă pentru toate
conturile, ceea ce este chiar recomandat, atunci memorarea unui volum mar e de date de cont
poate duce la uitarea acestora sau confundarea lor. Platforma „Cronos” dispune de soluția
evidentă pentru acesastă situație, și anume : recuperarea parolei.
Pentru a primi pe e -mail un nou cod ce se va folosi ca parolă la următoarea
auten tificare, este necesară introducerea adresei de e -mail și trecerea unei validări Captcha .
Dacă adresa de e -mail există înregistrată în baza de date, atunci un cod format din șase
caractere va fi generat și trimis la adresa introdusă. Acest cod, cât și cont ul pentru care s -a
solicitat recuperarea parolei, vor fi valabile 24 de ore de la trimiterea mesajului. Dacă nu a
fost activat în acest interval de timp, atât contul, precum și toate informațiile asignate acestuia
spre exemplu : taskuri, comentarii sau rapo arte vor fi șterse automat din baza de date.

– 52 –
3.2.2 Modulul de gestiune a l taskurilor
Acesta este și cel mai cuprinzător modul al aplicației, având implementate toate
funcționalitățile necesare pentru buna gestiune a taskurilor. Aplicația se bazează pe
diminua rea timpului de lucru alocat identificării unei cerințe, a utilizatorilor care au depășit
termenul limită alocat soluționării unui task sau a întocmirii rapoartelor lunare.
3.2.2.1 Adăugarea unui nou task
Doar un utilizator autentificat cu drepturi de editare a listei de taskuri va avea acces în
pagina addT ask.jsf , de unde se pot să introduce direct o noi sarcini în sistem. Pagina dispune
de un formular concis , dar suficient , ale cărui câmpuri sunt necesare a fi completate în
întregime de către inițiator pentru a adăuga un nou task. Acesta poate alege categoria din care
sarcina face parte, fie aceasta o problemă sau o îmbunătățire a funcționalităților, prioritatea cu
care trebuie rezolvată, o scurtă descriere generală, departamentul care trebuie să se ocupe de
rezolvarea sarcinii , cât și poate completa un set de instrucțiuni care ar trebui urmate de către
cel care se va o cupa de soluționarea taskului. Dacă utilizatorul care dorește să adauge sarcina
este autentificat cu drepturi de manager, acesta nu va avea opțiu nea de a selecta și
departamentul, taskul fiind atribuit automat departamentului pe care acesta îl manageriază. La
adăugarea unei noi sarcini, toți utilizatorii din departamentul respectiv vor fi înștiințați
automat prin e -mail cu toate detaliile taskului .
Similar cu adăugarea unei sarcini, este propunerea acesteia. Diferența este că u n task
poate fi propus doar de către un utilizator autentificat cu drepturi de angajat, evitând astfel
aglomerarea platformei cu taskuri c onsiderate inutile. Din pagina propo seTask.jsf , angajatul
poate completa un formular pentru a evidenția scopul, prioritatea și modul în care trebuie
soluționată sarcina, urmând ca aceste date să fie transmise automat managerului său prin
e-mail. Odată aprobat, taskul va putea fi urmări t de către angajat din pagina „ My Tasks ”.
Dacă un task nu este aprobat în cel mult trei luni de la data intrării în sistem, atunci acesta va
fi automat eliminat din baza de date.
3.2.2.2 Editarea unui task
Accesul in pagina editTask.jsf (Figura 3.2) , de unde es te posibilă modificarea tuturor
detaliilor unei sarcini, îi este permis doar unui utilizator din departamentul asignat sarcinii sau
cu drepturi de mentenanță asupra platformei . Acest lucru menține individualitatea
departamentelor, fiind necesară o permisiu ne pentru ca un angajat dintr -un anumit
departament să intervină asupra deciziilor luate într -un alt departament.

– 53 –

Din conținutul acestei pagini se po ate modifica categoria din care face parte taskul,
deoarece dintr -o dezvoltare a unui produs se poate prod uce o problemă, prioritatea cu care
trebuie rezolvat deoarece aceasta poate varia în funcție de evenimentele apărute în dezvoltare,
statusul în care se află deoarece acesta poate prelua un task , devenind „PROCESS”, îl poate
preda pentru a fi preluat de căt re un alt angajat, devenind „OPEN” sau îl poate închide,
devenind „CLOSE”. De asemenea, deși un utilizator care nu are drepturi de mentenanță , nu
poate adăuga un task în alt departament decât al său, acesta îl poate asigna unui alt
departament la editare, considerând că deja este o problemă serioasă și acesta a ajuns la un
anumit punct în dezvoltare care nu mai intră în atribuțiile sale.
La trecerea unui task în statusul de închidere, utilizatorului i se va cere să introducă o
scurtă descriere a modului în care s -a soluționat problema, pentru ca în cazul apariției unei
sarcini similare, să se identifice pașii de rezolvare sau implement are. Odată acționat butonul
de submit , toți utilizatori i din acel departament vor primi automat o notificare prin e -mail c u
actualizarea efectuată și toate detaliile curente ale taskului, inclusiv cu tot istoricul acestuia,
dacă utilizatorii nu au dezactivat această opțiune.

3.2.2.3 Ștergerea unui task
Această opțiune este disponibilă unui utilizator doar din pagina ce co nține vizualizarea
detaliată a sarcinii. Deși un utilizator cu rol de super -user are drepturi depline asupra
mentenanței platformei acesta nu poate interveni în parcursul unui task pe platformă, deci nu
îl poate șterge. Chiar dacă taskul aparține unui depa rtament și managerul este cel responsabil
de soluționarea acestuia, nici un manager nu are dreptul de a elimina un task din sistem.
Singurul căruia îi revine acest drept, este administratorul. Figura 3 .2 Pagina de editare a unui task

– 54 –
La acționarea butonului de ștergere, acestuia i se va cere con firmarea, pentru a nu
comite din neatenție această acțiune, iar apoi se va transmite un e -mail de notificare către toți
utilizatorii din departament. De asemenea, taskurile închi se cu mai mult de 3 luni în urmă vor
fi ștere periodic de către un proces auto mat.
3.2.2.4 Vizualizarea taskurilor
După parcurgerea etapei de autentificare, utilizatorul va fi redirecționat către pagina de
home , în conținutul căreia se regăsesc două mari componente . Prima componentă este formată
dintr -un widget , care la rândul său este î mpărțit în două categorii, anume afișarea numărului
de taskuri din fiecare departament și a numărului de taskuri grupate după statusul în care
acestea sunt înregistrate. A doua componentă din interfața web este afișată sub forma unui
tabel, care dispune de paginație pentru a nu încărca pagina web și ale cărui date sunt
reprezent ate de toate taskurile aprobate, sortat e în ordinea crescătoare a intră rii în sistem,
îndemnând astfel angajații să le rezolve mai întâi pe cele vechi.
Prin acționarea unui link din prima componentă, userul va fi redirecționat către pagina
unde poate vizualiza toate taskurile dintr -un anumit departament sau care se regăsesc într -un
anumit status. Acestea vor fi afișate tot sub forma unui tabel care dispune de paginație și ale
căror date vor fi sortate în ordinea crescătoare a înregistrării în sistem. Prin acționarea unui
link din cea de -a doua componentă, în care deja sunt afișate câteva detalii ale taskurilor
precum : prioritatea cu care trebuie rezolvate, categoria din care fac parte, statusul în care se
află, numele creatorului și al deținătorului curent, precum și o scurtă descriere generală,
utilizatorul va fi redirecționat către pagina ce conține toate detaliile acelui task.
3.2.2.4.1 Taskurile unui angajat
Ca utilizator al platformei acesta poate avea taskuri asignate unui alt utilizator ,
deținute sau propuse de către el. În schimb, un utilizator cu drepturi superioare, care poate
introduce direct un task în sistem fără a fi nevoie de aprobare, nu va avea taskuri propuse, ci
doar asignate lui sau unui alt utilizator.
Toate aceste taskuri pot fi vizualizate în conținutul pagin ii myTasks.jsf , care este
alcătuită din trei mari componente, a treia fiind disponibilă doar utilizatorilor cu drepturi de
angajat. Fiecare dintre cele trei componente al e paginii JSF este reprezentantă de un element
p:dataGrid , specific framework -ului PrimeFaces, dar pe care browserul web îl interpret ează
sub forma unui tabel care moșten ește stilizarea și funcționalitatea elementului JSF. Datele
primei componente sunt rep rezentate de taskurile pe care utilizatorul curent autentificat le -a

– 55 –
creat și le -a asignat pentru soluționare unui anunit departament. În a cea de -a doua
componentă sunt încărcate datele taskurilor pe care utilizatorul și le -a asignat lui însuși pentru
a le soluționa sau actualiza, iar în cea de -a treia componentă se regăsesc datele taskurilor pe
care acesta le -a propus pentru deschidere și care așteaptă aprobarea managerului. Prin
acționarea link -ului See more din interiorul uneia dintre componente, utiliz atorul va fi
redirecționat către pagina ce conține toate detaliile task ului respectiv .
3.2.2.4.2 Notificările unui angajat
În cadrul aplicației „Cronos” , notificările reprezintă, de fapt, taskuri pe care un
utilizator și le -a asignat, dar la care nu a mai lucrat d e mai mult de trei zile. Acest lucru duce
la îngreunarea procesului de dezvoltare al companiei, împiedicând alți utilizatori să lucreze la
rezolvarea acelei sarcini. În afară de un utilizator cu drepturi de super -user, care nu poate
vizualiza sau asigna ta skuri, orice alt utilizator poate ajunge în situația ca, din cauza
volumului mare de sarcini sau a timpului prea scurt, să dețină taskuri la care nu a lucrat timp
de trei zile sau mai mult . Odată autentificat pe platformă, utilizatorul va primi înștiințare a că
se află în această situație prin intermediul unei iconițe, care devine vizibilă și care
atenționează userul că trebuie să actualizeze acele taskuri.
Prezentarea paginii notificationTasks.jsf este similară cu cea a taskurilor asignate unui
angajat, ace asta conținând o componentă de tip p:dataGrid ce redă doar aspecte esențiale
identificării unui task și a statusului în care se află. Totodată, pentru a atrage atenția
utilizatorului, este evidențiat în culoare roșie, perioada de timp de la realizarea ulti mei
actualiză ri. Prin acționarea unui link din această componentă va fi acționată redirecționarea
userului pe pagina ce conține toate detaliile taskului respectiv.
3.2.2.4.3 Vizualizarea taskurilor în așteptare
Această op țiune este disponibilă doar unui utilizator c u drept de manager, acesta fiind
singurul căruia i se poate propune de către un angajat, aprobarea unei anumite sarcini. În
pagina pendingTasks.jsf , sunt afișate sub forma unui tabel, câteva detalii ale taskurilor ce
așteaptă aprobare din departamentul pe care acesta îl manageriază . Prin acționarea link -ului
dintr -o linie a tabelului, utilizatorul va fi redirecționat către pagina cu detaliile taskului
respectiv, unde va vedea toate detaliile adăugate sarcinii și o va putea aproba, caz în care
angajatul care a propus taskul va fi automat și deținătorul acestuia, urmând ca și restul
angajaților din departament să fie notificați prin e -mail de deschiderea sa, sau va putea
respinge cererea adăugării taskului , urmând ștergerea automată a acestuia din baza de date .

– 56 –
3.2.2.4.4 Afișarea detaliată a unui task
În această pagină se regăsesc două mari componente ce conț in toate detaliile unei
sarcin i, dar și întregul istoric al acțiunilor care s -au efectuat asupra acesteia . Prima
componentă a paginii taskView.jsf (Figura 3 .3) integ rează detalii esențiale ale sarcinii
respective precum: statusul, prioritatea și categoria în care se află, departamentul căreia îi este
asignată, numele creatorului și al deținătorului, dar și cu cât timp în urmă a fost creată sau
cine a făcut ultima actu alizare și cât timp a trecut de la acel eveniment. De asemenea, în
această componentă se regăsește un barcode , adică o imagine sub forma unui cod QR, care
poate fi scanat cu orice telefon mobil modern, pentru a descărca toate detaliile taskului direct
pe telefonul mobil.
A doua componentă a paginii este, de fapt, și cea mai cuprinzătoare. Aceasta își
schimbă conținutul în funcție de opțiunea selectată de către utilizator, care are disponibil trei
acțiuni posibile: viz ualizarea instrucțiunilor și a tuturor a ctualizărilor adăugate de la începutul
deschiderii taskului, cât și posibilitatea de a șterge un comentariu dacă acesta îi aparține sau
dacă are drepturi de mentenanță , vizualizarea întregului istoric al acțiunilor care s -au efectuat
asupra taskului respec tiv, dar și vizualizarea timpului alocat soluționării sarcinii de către
fiecare utilizator în parte. De asemenea, dacă utilizatorul face parte din departamentul în care
este deschis taskul, acesta va avea acces la editarea detaliilor taskului, dar numai un utilizator
cu drepturi depline îl va putea elimina din sistem .

3.2.2.5 Căutarea unui task
Această funcționalitate consider că este esenț ială oricărei aplicații care dorește să
reducă timpul alocat identificării unui eveniment și să eficientizeze m unca utilizator ilor.
Aplicația „Cronos” dispun e de o căutare avansată, după numeroase criterii de filtrare, precum:
Figura 3 .3 Vizualizarea detaliată a unui task din perspectiva adminului

– 57 –
statusul, prioritatea și categoria în care se găsește un anumit task, departamentul căruia îi este
asignat, numele deținătorul ui sau inițiat orului sarcinii , instrucțiunile adresate la deschidere,
actualizările utilizatorilor sau chiar după codul de identificare, care din motive de integritate
nu este cheie primară în tabel elul ce reține taskurile.
Inspirat d upă criteriul de căutare de la Googl e, am reușit cu ajutorul framework -ului
PrimeFaces, a tehnologiei Java și a framework -ului Materialize , ca la introducerea a min im
două caractere în caseta de input afișată în bara de meniu, utilizatorului s ă i se ofere sugestii
de căutare care conțin crit eriul int rodus (Figura 3 .4), iar pe măsură ce acesta va schimba
criteriul și sugestiile vor fi recalculate și afișate în mod dinamic.
La acționarea butonului de search din bara de navigare, utilizatorul va fi redirecționat
către pagina searchTasks.jsf care conține datele tututror taskurilor ce respectă criteriul, sau
chiar ale tututor taskurilor aprobate din sistem, în cazul în care caseta de input a fost vidă la
căutare. În acest tabel de rezultate , este posibilă aplicarea unor filtre suplimentare , simultan pe
mai m ulte coloane din tabel (Figura 3 .5) pentru a identifica exact sarcina căutat ă. Filtrul nu
este case-sensitive , acesta căutând chiar și în interiorul șirului de caractere din acea coloană și
făcând abstracție de scrierea cu majuscule sau minu scule. O dată introdus un filtru pe o
coloană, în tabel vor rămâne doar intrările care respectă c riteriul pe coloana respectivă, dar se
poate reveni la starea anterioară prin simpla eliminare a filtrării.

3.2.3 Modulul de gestiune a l ședințelor
Acest modul a fos t implementat cu scopul de a evita folosirea altor aplicații externe,
care nu țin de procesul companiei, pentru a organiza ședințe de dezvoltare între departamente.
În orice firmă, indiferent de domeniul de activitate al acesteia, este nevoie de organi zarea unor
întâlniri periodice, pentru ca angajații să poată comunica liber, neconstrânși de formalitatea
mesajelor electronice, ideile și problemele care pot apărea în dezvoltarea unui produs.
Figura 3 .4 Căutarea avansată Figura 3 .5 Filtrarea coloanelor din tabel

– 58 –
3.2.3.1 Vizualizarea ședințelor
Această opțiune este disponibilă tuturor tipurilor de utilizatori ai platformei. Dac ă
userul autentificat are rol de angajat sau m anager, prin accesarea paginii meetings.jsf , acesta
va putea vizualiza doar ședințele la care trebuie să ia parte departamentul din care acesta face
parte, respeciv p e care îl manageriază. În schimb, dacă utilizatorul are drepturi de mentenanță ,
acesta va putea vizualiza toate ședințele programate pentru orice departament. Conținutul
acestei pagi ni dispune de un aspect modern și intuitiv, sub forma unui calendar (Figur a 3.6) ,
organizat pe luni ale anului, în care sunt încărcate ședințele companiei. Pagina JSF integrează
un element p:scheduler , specific framework -ului PrimeFaces, facilitând interacțiunea cu
obiectul Java Bean, dar care în browserul web este interpretat s ub forma unui tabel HTML ce
moștenește stilizarea și funcționalitatea elementului JSF.
La acționarea unui eveniment, se va deschide un pop-up cu toate detaliile ședinței:
subiectul întâlnirii, departamentele care trebuie să participe la aceasta, precum și data și ora la
care începe și la care se termină ședința, presupunând că un subiect de discuție se poate
întinde pe mai multe zile într -un anumit interval orar.
3.2.3.2 Adăugarea unei noi ședințe
Această opțiune este disponibilă tot din pagina de vizualizare a ședințelor, însă doar un
utilizator autentificat cu drepturi superioare are posibilitatea de a adăuga un nou eveniment.
Prin acționarea unei casete necompletate a calendarului, utilizatorului îi va apărea o fereastră
unde i se va cere completarea unui for mular cu date necesare identificării ședinței, iar care
apoi vor fi disponibile vizualizării.
Figura 3 .6 Calendarul ședințelor planificate

– 59 –
La acționarea butonului de adăugare, o metodă Java va verifica ca numele introdus să
fie unic, pentru a nu face confuzia între două ședințe înregistrate, data înc eperii să fie înainte
de data încheierii, ora începerii să fie, de asemenea, înainte de ora încheierii și desigur, să fie
cel puțin un departament asinat ședinței. Se permite introducerea a două ședințe în aceeași zi,
dar nu la aceeași oră, deoarece compan ia dispune de o singură sală de ședințe.
În cazul nerespectării oricăreia dintre aceste situații, utilizatorului îi va apărea un
mesaj corespunzător, fiind necesară reintroducerea acelor date. Odată validată și introdusă în
sistem, userului îi va apărea u n mesaj de co nfirmare, iar un e-mail de înștiințare cu toate
detaliile ședinței va fi transmis automat tuturor utilizatorilor ce fac parte din departamentele
asignate ședinței noi adăugate.
3.2.3.3 Editarea unei ședințe
Această opțiune este , de asemenea, disponi bilă utilizatori lor autentificați cu drepturi
superioare, din conținutul paginii manageMeetings.jsf . Datorită framework -ului PrimeFaces,
este posibilă schimbarea datei la care are loc o ș edință prin simpla funcție de drag&drop a
evenimentului , fără a fi ne voie introducerea datelor manual. Desigur, prin această
funcționalitate nu se va putea schimba nici durata ședinței și nici subiectul sau departamentele
asignate, acestea fiind necesare să fie efectuate manual.
Un manager poate edita doar datele ședințelo r la care participă departamentul său , în
schimb un user cu drepturi de mentenanță poate edita datele tututor ședințelor înregistrate, cu
condiția de a respecta anumite criterii de validare, ca și la adăugarea unei ședințe : subiectul
întâlnirii trebuie să fie unic, intervalul orar trebuie să fie u nul valid, la ședință trebuie să fie
asignat cel puțin un departament care să participe și să nu mai existe o altă ședință programată
la aceeași oră sau care să se suprapună cu aceasta . La acționarea butonului de c onfirmare, va
fi apelată metoda Java care verifică dacă datele introduse sunt valide, caz în care un mesaj de
confirmare va apărea în interfața web și un e -mail de înștiințare cu toate detaliile ședinței va fi
transmis automat tuturor utilizatorilor ce fac parte din departamentele participante.
3.2.3.4 Ștergerea unei ședințe
Precum editarea unei ședințe, acțiunea de ștergere a acesteia este dis ponibilă tot din
conținutul paginii manageMeetings.jsf . Pentru a avea acces la această opțiune, utilizatorul
trebuie să fie autentificat cu drepturi de mentenanță . Deși un manager are acces la editarea
tuturor informațiilor aferente ședințelor din departamentul său, odată adăugate acestea nu vor
mai putea fi eliminate din sistem de către el, ci va trebui confirmarea unui ad min pentru a

– 60 –
efectua această operație. La acționarea unui eveniment deja stabilit , o fereastră cu toate
detaliile sale va apărea în interfața web, iar în partea de jos va fi disponibil butonul de
ștergere. Dacă acesta este acționat, utilizatorului i se va cere confirmarea, evitând astfel
anularea unei ședințe din neatenție, iar urmând apoi ca un e -mail de înștiințare să fie transmis
tuturor angajaților care erau asignați acelei ședințe.
3.2.4 Modulul de întocmire a l rapoartelor
Am implementat acest modul pentru a diminua eforturile unui manager de a superviza
munca angajaților. Deși în fiecare pagină care conține vizualizarea detaliată a progesului unui
task este redat timpul de lucru alocat de fiecare angajat în parte, acest lucru nu este suficient
pentru a întoc mi un raport general al activității utilizatorilor . Pentru a determina dacă un
angajat trebuie promovat sau dacă acesta merită o mărire de salariu sau o descreștere a
acestuia, pe lângă evaluările periodice prin care trece fiecare angajat, se ține seamă și de
rezultatele acestor rapoarte ale utilizatorilor. De asemenea, dacă un departament alocă prea
mult timp rezolvării unor sarcini sau apar prea multe probleme asignate acestuia, se va ști că
în acel departament trebuie să se facă noi angajări.
Această pag ină conține rapoarte ale ședințelor, taskurilor, angajaților și
departamentelor. Fiecare dintre aceste rapoarte este integrat în pagina web într -o componentă
JSF care dispune de 4 file, câte una pentru fiecare raport, și de asemenea, reprezentată în mod
diferit în funcție de conținutul pe care îl evidențiază .
3.2.4.1 Rapoartele taskurilor
Această pagină integrează cinci rapoarte generale ale taskurilor despre starea acestora
sau despre timpul alocat rezolvării sarcinilor . Primele două rapoarte sunt repre zenta te prin
intermediul a două componente grafic e de tip pie-chart (Figura 3.7).

Figura 3 .7 Rapoartele taskurilor din perspectiva administratorului

– 61 –
În prima componentă , care este disponibilă doar utilizatorilor cu drepturi de
administrator sau super -user, se poate alege dintr -un meniu „drop -down” din care lună a
anului se dorește a afla timpul alocat de către fiecare departament în rezolvarea sarcinilor,
graficul fiind redat în procente care reprezintă timpul d e lucru. În a doua componentă, se
poate alege , de asemenea de către un admin sau super -user, din care lună a anulu i se dorește
calcularea, de data aceasta a numărului de taskuri de tip problemă, respectiv îmbunătățiri, au
fost deschise în întreaga companie. Dacă utilizatorul este manager, acesta va vedea raportul
departamentului său, iar un angajat doar pe cel al task urilor sale.
Următoarele componente ale paginii sunt reprezentate de trei grafice liniare, fiecare
dintre acestea reprezentând numărul de taskuri deshise, finalizate sau în așteptare ale
departamentelor din anul curent. Dacă utilizatorul are drepturi de m entenanță , în aceste
componente vor fi integrate rapoartele generale ale întreg i compani i, împărțite pe
departamente. Dacă utilizatorul are drept de manager acesta va vedea raportul
departamentului său din anul în curs , împărțit pe luni, iar un angajat va putea vizualiza
raportul propriu ale taskurilor deținute, rezolvate sau asignate de către el.
3.2.4.2 Rapo rtul utilizatorilor
Această pagină integrează, de asemenea, un raport și este disponibilă oricărui tip de
utilizator. Diferențierea o face meniul selecta bil, pe care îl vede doar un user autentificat cu
drepturi superioare , meniu din care se poate alege numele angajatului pentru care se d orește
vizualizarea raportului și în care se regăsesc toți utilizatorii platforme i. În schimb, un manager
poate alege do ar un anga jat din departamentul , iar un angajat își va putea vizualiza doar
raportul propriu. În acest raport sunt încărcate și împărțite pe luni ale anului, numărul de
taskuri deschise, închise sau în așteptare, cât și timpul de lucru alocat soluționării sarcinilor în
fiecare lună de către angajatul selectat.

Figura 3 .8 Raportul unui utilizator din perspectiva administratorului

– 62 –

De asemenea, folosind librăriile Apache despre care am redactat anterior, am făcut
posibilă exportarea acestor date în diferite formate (Figura 3 .8). Cu ajutorul librăriei Apache
POI și a framework -ului PrimeFaces , datele din tabel pot fi descărcate, pe calculator dar și pe
telefonu l mobil, în format suportat de Microsoft Office Excel, și anume cu extensia xls sau
csv. Folosind librăria Apache FOP și de asemenea, cu ajutorul tehnologiei pe care Prim eFaces
o pune la dispoziție, raportul tabelar poate fi d escărcat in format suportat de Adobe Acrobat
Reader , și anume cu extensia pdf. Pentru a facilita procesarea acestor date, independent de
starea bazei de date, de un program Java, am implementat export area acestor date tabelare în
format xml.
3.2.4.3 Rapo rtul departamentelor
Această pagină este disponibilă doar unui utilizator autentificat cu drepturi superioare .
Similar cu raportul utilizatorilor, este cel al departamentelor, în acesta fiind redate de
aseme nea, numărul taskurilor deschise, finalizate sau care așteaptă aprobarea managerului,
dintr -un anumit departament. Un admin poate selecta departamentul pentru care dorește
întocmirea raportului, în timp ce un manager va putea vizualiza doar raportul taskur ilor din
departamentul său. Această pagină se folosește, de asemenea, de librăriile Apache pentru a
exporta datele din tabel în diferite formate.
3.2.4.4 Rapoartele ședințelor
Această pagină este disponibil ă spre vizualizare oricărui tip de utilizato r. Scopul
acesteia este de a analiza cât de multe probleme a întâmpinat unul sau mai multe
departamente în dezvoltare și cât de des au fost necesare întâlniri pentru soluționarea acestora.
În conținutul paginii se regăsesc două componente: prima este reprezentată de u n grafic liniar,
iar a doua conține date dispuse sub forma unui tabel.
În prima componentă un administrator sau un super -user va vedea un grafic împărțit
pe luni ale anului, cu numărul de ședințe deschise din fiecare departament (Figura 3 .9), iar un
manage r sau angajat va vedea doar raportul ședințelor departamentului său. În cea de -a doua
componentă, utilizatorul poate alege o anumită lună a anului pentru care dorește să
vizualizeze ședințele programate și detalii ale acestora precum data și ora la care în cepe,
respectiv se termină întâlnirea, dar și care sunt departamentele asignate acelei ședințe. Datele
tabelare ale acestei componente po t fi, de asemenea exportate în diferite formate de fișiere.

– 63 –
3.2.5 Modulul de mentenanță al platformei
Platforma dispune d e editarea anumitor caracteristici ale sale direct din interfața web.
Nu oricărei categorii de utilizatori i se permite acces ul la aceste pagini, deoarece prin
intermediul acestora se pot schimba aspecte importante ale utilizării sau accesului în aplicație .
3.2.5.1 Editarea departamentelor
Această opțiune este disponibilă din pagina „maintenance.jsf”, care integrează un
element specific framework -ului PrimeFaces, de tip p:tabView care la rândul său dispune de
două componente. În prima componentă sunt listate toa te departam entele înregistrate pe
patformă, în dreptul fiecăruia dintre acestea fiind disponibil un buton de ștergere. Dacă se
dorește eliminarea unui departament, aceasta implică automat și ștergea tuturor angaj aților din
acel departament, a taskurilor, a ctualizărilor și rapoartelor asignate. L a acționarea acestui
buton, va apărea pe ecran o fereastră pop-up care oferă două opțiuni utilizatorului: fie va
șterge departamentul și toate intrările care au legătură cu acest departament, fie va putea
elimina de partamentul din sistem, urmând ca toți utilizatorii și toate taskurile să fie asignate
unui alt departament pe care îl poate alege dintr -un meniu selectabil.
Odată șters sau mutat un departament, un mesaj de confirmare va apărea în interfața
web, iar toți utilizatorii vor fi automat înștiințați prin e -mail de modificarea efectuată, pentru a
nu apărea confuzii din partea acestora în activitatea pe platformă. De asemenea, în această
componentă este disponibilă o casetă de text din care se permite introducerea unui nou
departament în sistem. La adăugarea acestuia, doar utilizatorii cu drepturi de administrator sau
manager vor fi notificați prin e -mail.

Figura 3 .9 Raportul ședințelor din perspectiva adm inistratorului

– 64 –
3.2.5.2 Editarea descrierilor succinte
În plus față de categoria din care face parte un task, fie aceasta problem ă sau
îmbunătăție, oricare nouă sarcină adăugat ă trebuie să aibă asignată o descriere succintă.
Aceasta este o caracteristică în plus pentru a ajuta utilizatorul să cunoască motivul pentru care
s-a deschis taskul fără a intra pe pagina detaliată a acestuia . A doua componentă a paginii
maintenance.jsf dispune de editarea listei acestor scurte descrieri (Figura 3 .10), deoarece pot
apărea unele noi în funcție de produsul dezvoltat, iar altele pot ajunge a fi considerate inutile
după o anumită perioadă de timp. Dacă se va elimina o descriere de care dispun unul sau mai
multe taskuri, acestora li se va seta automat descrierea „General”. Am ales să nu înștiințez
utilizatorii prin e -mail la efectuarea acestei acțiuni, deoarece acest lucru va fi vizibil în lista
descrierilor, care nu este una foarte numeroasă, la adăugarea unui task.

3.2.5.3 Gestiunea utilizatorilor
Aplicația „Cronos” oferă , în conținutul paginii manageUsers.jsf (Figura 3 .11),
utilizatorilor cu drepturi asupra mentenanței platformei, posibilitatea de e dita drepturile de
vizualizare și de acces ale altor utilizatori, cât ș i ștergerea acestora din sistem.
3.2.5.3.1 Modificarea drepturilor
Pe platformă sunt disponibile patru categorii de utilizatori, cu drepturi diferite asupra
acțiunilor în aplicație: angajat, ma nager, administrator și super -user. În pagina de editare a
rolurilor sunt dispon ibile patru componente JSF, de tip pickList , fiecare dintre aceasta având
la rândul său integrate două liste. Din prima componentă este posibilă promovarea unui
angajat la rolu l de manager, dar și depromovarea unui manager la rol de angajat. Dacă un
angajat devine manager într -un departament care dispune deja unul, managerul actual va fi
Figura 3 .10 Editarea descrierilor succinte

– 65 –
automat depromovat la rolul de angajat, iar un e -mail de înștiințare a acțiunii efectuate, v a fi
transmis automat ambilor utilizatori. Dacă un manager va fi depromovat la rol de angajat,
atunci se va efectua promovarea unui alt angajat, de obicei cel mai vechi din acel
departament, la rol de manager, iar apoi se va transmite, de asemenea, un e -mail de înștiințare
angajaților în cauză.
Din interiorul celei de -a doua componente este posibilă promovarea unui utilizator la
drepturi de administrator, dar nu și invers. Un utilizator care este admin va apărea în listă, dar
rolul său nu va putea fi modi ficat. De asemenea, userul curent autentificat nu își va putea
schimba singur rolul . A treia componentă este similară cu a doua, prin intermediul acesteia un
utilizator va putea fi promovat la rolul de super -user, dar nu și invers. La efectuarea unei
acțiu ni din prima sau a doua componentă, toți utilizatorii în cauză, cât și cei cu drepturi de
administrator vor fi automat notificați prin e -mail.

3.2.5.3.2 Ștergerea unui utilizator
Această opțiune este disponibilă prin intermediul celei de -a patra componente a
paginii de manageriere a utilizatorilor, care permite doar ștergerea unui user înregistrat cu
drepturi de angajat sau manager. Odată șters un utilizator, toate datele sale personale,
taskurile, comentariile și rapoartele asignate vor fi, de asemenea, elimin ate din sistem, iar
acest a va primi un e -mail de înștiințare a acțiuni efectuate.
3.2.5.4 Mentenanță automată
Există trei procese care rulează independent de platformă, la intervale stabilite de
timp, pentru a invoca metode cu scopuri diferite. Primul proces es te însărcinat cu trimiterea de
e-mailuri asincron, iar celelalte două se ocupă de mentenanță, mai exact de „curățarea”
intrărilor inutile sau care nu mai sunt de actualitate, din baza de date. Dacă un proces dorește
să pornească în timp ce un altul rulează deja, acesta va aștepta terminarea execuției primului
Figura 3 .11 Conținutul paginii de gestiune a utilizatorilor

– 66 –
proces, evitând astfel efectul de deadlock , care apare atunci când două procese doresc să
utilizeze aceleași resurse.
3.2.5.4.1 Procesul de ștergere a l conturilor temporare
Numim cont temporar al unui utilizat or, un cont la care s -a cerut recuperarea parolei,
dar nu a fost introdus codul de verificare în cel mult o zi de la data primirii acestuia sau un
cont care a fost introdus în sistem, dar nu a fost activat, de asemenea, în 24 ore. Acest proces
are rolul de a elimina din sistem conturile temporare ale utilizatori lor. Fiind implementat cu
ajutorul unui Quartz Java (Figura 2 .2), acesta este programat să ruleze o dată la o oră pentru a
verifica dacă un utilizator a depășit timpul alocat activării contului, caz în care contul său va fi
automat șters din si stem ș i un e-mail de înștiințare va fi transmis acestuia.
3.2.5.4.2 Procesul de ștergere a l taskurilor și ședințelor
Atât ș edințele care au avut loc cu mai mult de trei luni în urmă , cât și taskurile care au
fost soluți onate dup ă trecerea acestei perioade, sunt considerate a fi inutile și prin urmare, vor
fi automat eliminate din sistem. Proces ul facilitează automat această acțiune, fiind
implementat, de asemenea, cu ajutorul unui Quartz Java. Metoda de verificare a exis tenței
taskurilor sau ședințelor în această situație este invocată o dată pe zi, iar ștergerea unui astfel
de eveniment va implica automat și ștergerea comentariilor , actualizărilor sau a rapoartelor
acestuia. În această situație, utilizatorii nu vor fi n otificați prin e -mail, considerându -se că un
eveniment de mult încheiat nu mai prezintă interes pentru aceștia.
3.3 Cazuri de utilizare ale aplicației
În domeniul software, un caz de utilizare este reprezintat de o colecție de posibile
secvențe de acțiuni sa u evenimente, care definesc de obicei interacțiunile unui anumit rol
pentru un anumit scop, clarificând astfel cerințele sistemului. Fiecare interfață a utilizatorului
este redată în culori diferite, în funcție de drepturile pe care le are.
3.3.1 Din perspectiva angajatului
Platforma dispune de un set cuprinzător de acțiuni pentru ca un utilizator autentificat
cu drepturi de angajat să poată participa activ la proiectele și ședințele companiei, cât și să își
poată urmări periodic raportul de activitate. Meniul de navigare, dar și conținutul paginilor
web ale acestei categorii de utilizatori este afișa tă în culoare albastră (Figura 3 .12).

– 67 –

Un angajat poate v izualiza taskurile deschise în oricare departament , întregul istoric al
acestora și activitatea altor utilizatori în rezolvarea sarcinii , atât din pagina princip ală, cât și
din selectarea unui task care se află într -o anumită categorie. Deși un angajat poate asigna un
task altui departament decât al său, a cesta are permisiunea de a edita detaliile unui tas k doar
dacă aparține departamentului în care sarcina este deschisă, deoarece nu se dorește ca un
angajat al altui departament să intervină peste decizile luate în acesta. Dacă sarcina nu mai
aparține departamentului său, dar utilizatorul cu drepturi de ang ajat a intervenit cu actualizări
în conținutul taskului , atunci acesta va putea șterge comentariile c are îi aparțin.
De asemenea, un utilizator din această categorie dispune de o pagină separată din care
poate urmări parcusul taskurilor pe care le -a asigna t altor utilizatori sau chiar lui însuși, cât și
al taskurilor „în așteptare” . Acestea reprezintă, de fapt, sarcinile pe care angajatul le -a trimis
pentru aprobare managerului său, deoarece un angajat nu are permisiunea de a introduce
direct un task un sis tem. Astfel se evită aglomerarea departamentelor cu sarcini pe care un
angajat ar putea să le rezolve de unul singur.
Un utilizator cu drepturi de angajat dispune de o căutare avansată, care îi oferă sugestii
de căutare, ajutându -l astfel să identifice mai ușor un task pe care îl are asignat. Odată aplicat
un criteriu de căutare, din pagina cu rezultate acesta poate să filtreze datele returnate după
multiple criterii, pentru a identifica exact sarcina căutată. Printre aceste date nu se vor regăsi
și taskuri le trimise spre aprobare, a cestea fiind considerate încă irelevante pentru platformă.
De asemenea, la autentificarea pe site, angajatului îi este calculat numărul taskurilor la care a
întarziat cu actualizările mai mult de trei zile . În caz că acest număr este pozitiv, utilizatorul
va primi o notificare în bara de navigare , la acționarea căreia acesta va fi redirecționat către
pagina în care îi vor fi prezentate aceste sarcinile întârziate, îndemnând astfel angajații să își
actualizeze taskurile la care au început să lucreze.
Totodată, un angajat dispune de vizualizarea ședințelor la care departamentul său este
asignat. Aceștia pot vizualiza întâlnirile organizate într -un calendar împărțit pe luni ale anului,
care integrează toate detaliile adăugate unei șed ințe.
De asemenea, utilizatorul de acest tip poate dezactiva opțiunea de a primi întregul
istoric al unui task prin e -mail, cât și poate edita informațiile personale pe care le are Figura 3 .12 Bara de navigare a angajatului

– 68 –
înregistrate pe platformă, lucru esențial deoarece la crearea contului ace sta va primi doar
câteva date precum: nume, prenume sau e -mail.
Un alt aspect important de care dispune un utilizator cu drepturi de angajat este
vizualizarea de rapoarte. Prin inermediul acestora, angajatul își poate urmări activitatea pe
care o văd și su periorii lui, ambiționându -l astfel să se implice mai mult pentru a avea
rezultate cât mai bune. Angajatul poate vedea procentajul de probleme sau îmbunătățiri în
care s -a implicat într -o anumită lună a anului, cât și un raport anual al numărului de taskur i pe
care acesta le -a deschis, asignat, propus sau la care a lucrat. Raportul care redă timpul de lucru
alocat rezolvării unei sarcini într -o anumită lună și a numărului de taskuri din diferite
categorii, poate fi descărcat de utilizator în diferite format e, precum: XLS, CSV, PDF sau
XML. Totodată, unui angajat i se permite vizualizarea raportului ședințelor la care a participat
departamentul său, pe parcusul anului în curs sau într -o anumită lună, raport care poate fi, de
asemenea, descărcat în diferite fo rmate de fișiere.
3.3.2 Din perspectiva managerului
Pe platforma „C ronos”, managerul este principalul răspunzător de organizarea
departamentului său. Pentu un utilizator autentificat cu drepturi de manager aplicația dispune
de numeroase acțiuni pentru a gestio na activitatea angajaților săi. Interfața web a acestei
categorii de utilizatori este re dată în culoare violet (Figura 3 .13).
Un manager dispune de aceleași drepturi de vizu alizare și editare a taskurilor, precum
un angajat. Nu se dorește ca un departament să intervină asupra activității unui alt
departament, prin urmare nici managerul nu va avea dreptul de a modifica detaliile sarcinilor
asignate în alt departament decât cel pe care îl gestionează.
Acestei categorii de utilizator îi este permisă introducer ea taskurilor în sistem, fără a fi
necesară aprobarea acestora de către un utilizator cu drepturi superioare. În pagina de
adăugare a unui task, managerul va putea selecta detaliile necesare pentru a deschide o nouă
sarcină, dar nu va putea alege și depart amentul, sarcina urmând a fi asignată automat
departamentului pe care acesta îl manageriază.
Figura 3 .13 Bara de navigare a managerului

– 69 –
De asemenea, managerul este responsabil de aprobarea taskurilor introduse în
departament de angajații săi și care sunt în status pending , pentru a începe activita tea la acea
sarcină sau poate respinge propunerile angajaților dacă acesta consideră insuficient motivul
solicitat pentru deschiderea taskului.
Totodată, un manager are posibilitatea de a vizualiza ședințele planificate la care este
asignat departamentul s ău. În plus față de un angajat, acestuia îi este permisă amânarea unei
ședințe sau editarea detaliilor acesteia. De asemenea, managerul poate introduce în orar noi
ședințe la care poate adăuga și alte departamente decât al său. Această acțiune este permisă în
ideea că un manager poate propune spre dezvoltare un proiect, c are mai întâi trebuie discutat
cu membrii celorlalte echipe sau poate apărea o problemă care este răspandită în cadrul mai
multor departamente și care necesită o anumită abordare comună din partea echipelor.
Un utilizator cu drepturi de manager dispune, de asemenea, de vizualizarea de
rapoarte. Acesta se poate implica activ în soluționarea problemelor apărute, prin urmare își va
putea vizualiza și raportul individual. Desigur, nu acesta este scopul acestei secțiuni, ci
urmărirea activității și a implicării departamentului său în îndeplinirea sarcinilor. Managerul
are posibilitatea de a vizualiza procentajul de probleme sau îmbunătățiri apărute în
departamentul său într -o anumită lună a anului , cât și un raport anual al numărului de taskuri
deschise, rezolvate sau propuse în acesta . De asemenea, acesta poate analiza și descărca în
diferite formate de fișere, raportul anual al acestor număr de taskuri, dar și a mediei timpului
de lucru alocat de către departamentul pe care îl manageriază sau individual de către unul
dintre angajații acestui departament . Totodată îi este permisă vizualizarea și exportarea
rapoartelor ședințelor asignate echipei sale într -o anumită lună sau în anul curent .
3.3.3 Din pers pectiva super -userului
În cadrul platformei „Cronos”, deși un utilizat or autentificat cu drepturi de super -user
poate vizualiza istoricul și detaliile sarcinilor deschise, acesta nu se poate implica activ în
dezvoltarea proiectelor companiei. Principala responsabiliate a unui astfel de utilizator este
mentenanța platformei și gestiunea utilizatorilor. Conținutul paginilor web afișat unui
utilizator cu drepturi de super -user este redat în culoare portocalie (Figura 3.14).

Figura 3 .14 Bara de navigare a unui super -user

– 70 –
Un super -user dispune de drepturi depline asupra vizualizării sarcinilor deschise, dar
acesta nu va avea niciodată notificări deoarece nu are permisiunea de a își asigna taskuri și
nici de le edita sau introduce în aplicație . În ciuda acestui fapt, dacă acesta consideră o sarcină
aprobată sau introdusă direct în sistem de către un utilizator având conținut inadecvat sau
irelevant pentru dezvoltarea platformei, super -userul va putea elimina din sistem taskul sau
actualizările aduse acestuia . Unui utilizator cu drepturi de super -user îi este permisă, de
asemenea, vizualizarea, amânarea, mutarea sau anularea ședințelor organizate în cadrul
companiei, dar și editarea detaliilor legate de acestea.
Spre deosebire de un manager, un utilizator aparținând acestei categorii poate
introduce un nou ang ajat pe platformă în orice departament existent. De asemenea, unui
super -user îi este permis accesul în secțiunea de gestiune a drepturilor utilizatori lor
înregistrați . Din cadrul acestei secțiuni, acesta poate promova sau depromova un manager, dar
nu poat e retrograda un alt admin sau super -user și nici să își modifice singur drepturile. Unui
utilizator ce aparține acestei categorii îi permis accesul la menenanța platformei. Acesta poate
edita lista denumirilor predefinite cu care se poate introduce un task în sistem. De asemenea,
un super -user poate adăuga un nou departament, elimina unul existent sau să asigneze toate
taskurile și angajații acestuia unui alt departament.
Totodat ă un astfel de utilizator poate analiza rapoarte periodice ale activității
comp aniei. În plus față de un manager, acesta dispune și de un raport grafic care redă media
timpului alocat de fiecare departam ent în soluționarea taskurilor di ntr-o anumită lună a anului.
De asemenea, poate vizualiza un raport grafic al procentajului tipuril or de taskuri înregistrate
pe platformă într -o anumită lună, dar și un raport anual al numărului de sarcini deschise,
rezolvate sau în status pending din fiecare departament. I se permite de asemenea , descărcarea
în diferite formate de fișiere a rapoartelo r care redau tabelar media timpului de lucru alocat
soluționării taskurilor de către un utilizator sau chiar de un departament și a numărului de
sarcini asignate dintr-o anumită lună. Unui super -user îi este permisă analizarea și exportarea
rapoartelor șed ințelor stabilite anual sau lunar în cadrul companiei.
3.3.4 Din perspectiva administratorului
În cadrul platformei „Cronos”, această categorie de utilizatori este, de fapt, și cea mai
cuprinzătoare, oferind drepturi depline asupra implicării în activitatea pla tformei, gestiunii
taskurilor și a mentenanței aplicației .

– 71 –
Un angajat cu rol de administrator îmbină drepturile unui simplu angajat cu cele
ale unui super -user, considerând că un angajat care cunoaște foarte bine sistemul, îl poate
și întreți ne. Interfața web a acestei categorii d e utilizatori este redată în culoare
turcoaz (Figura 3.15).
Un administrator are drepturi depline asupra vizualizării taskurilor deschise în orice
departament, cât și editarea acestor informații sau șter gerea lor din sistem. Spre deosebire de
un super -user, acesta se poate implica activ în rezolvarea sarcinilor și poate asigna taskuri
altor departamente, angajați sau chiar lui însuși. De asemenea, acestuia i se oferă drepturi
asupra organizării sau anulăr ii ședințelor companiei.
Un astfel de utilizator poate adăuga atât noi taskuri, cât și noi utilizatori în oricare
dintre departamente le companiei . Totodată, acesta poate edita drepturile altor angajați, dar nu
ale lui însuși și nici nu poate modifica drept urile unui super -user sau un ui alt administrator.
Precum unui super -user, acestuia îi este permis accesul la gestiunea listei departamentelor sau
a descrierilor predefinite. De asemenea, un administrator poate vizualiza și descărca în diferite
formate de f ișiere, raportul întregii activități a companiei, a departamentelor sau a
utilizatorilor înregistrați pe platformă.

Figura 3 .15 Bara de navigare a adm inistrator ului

– 72 –
CONCLUZII
Aplicația „Cronos” a fost dezvoltată atingând scopul de a reprezenta un instrument
principal de organizare a l unui domeni u de afaceri, precum și de a manageria și eficientiza
activitatea anga jaților unei companii. Lucrarea de față descrie funcționalitățile de care
beneficiază un utilizator al platformei și evidențiază metodele de diminuare ale timpului de
lucru alocat de căt re angajați , întocmirii de rapoarte sau gestiunii activității unei întreprinderi .
De asemenea, platforma este structurată pe baza unei arhitecturi bine organizate, c are
permite oricărui modul integrat să fie actu alizat, modificat sau înlocuit , în funcție d e
cerințele companiei sau ale tehnologiei moderne, fără a afecta buna funcționare a celorlalte
module. Prin utilizarea framework -ului Java și a tehnologiei pe care o pune la dispoziție
serverul Apache, aplicația nu se deosebește doar prin performanța cu care interpretează
un volum mare de date, ci și printr -un mediu de dezvolatare , care permite administrarea
aceste ia, direct din interfața web, de către o persoană ale căr ei cunoștințe de programare se
încadrează la un nivel minim .
Spre deoseibire de alte aplicații implementate pentru atingerea acelor ași scopuri,
platforma dispune și de un sistem de gestiune și de notificare a detaliilor ședințe lor organizate
în cadrul companiei , prezentat într -o interfață user-friendly , accesibilă oricărei categorii de
utilizatori. De asemenea, aplicația se bazează pe un sistem eficient de notificări prin e -mail,
care înștiințează utilizatorii de orice acțiune efectuată asupra unui eveniment , ale cărui date
prezintă interes pentru aceștia. În plus, aceasta dezvoltă un modu l dedicat întocmirii de
rapoarte, pentru gestiunea activității utilizatorilor sau a departamentelor. Astfel, sunt facilitate
eforturile managerilor de a determina angajații care acordă cel mai mare interes proiectelor
companiei sau d acă aceștia sunt d epășiți de volumul prea mare de sarcini.
Ca dezvoltări ulterioare, aplicația își propune integrarea în interfața web, a unui modul
de comunicare online cu transmitere instantanee a mesajelor, altfel spuns un chat, prin
intermediul căruia angajații din dife rite departamente să poată discuta soluționarea anumitor
taskuri, fără a fi necesară utilizarea unei alte aplicații externe c are să ofere această
funcționalitate. Totodată, consider că în plus față de exportarea rapoartelor în diferite formate
de fișiere care permit tipărirea , ar fi utilă o opțiune prin care utilizatorii să poată alege
imprimarea doar a a numitor date prezentate în pagina web.

– 73 –
LISTĂ DE FIGURI
Capitolul 1
Figura 1.1 Arhitectura pe trei niveluri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Figura 1.2 Modelul arhitectural MV C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figura 1.3 Legenda diagramei entitate -relație . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figura 1.4 Diagrama entitate -relație . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Figura 1.5 Legenda diagramei UML a cazurilor de utilizare . . . . . . . . . . . . . . . . . . . . . . 19
Figura 1.6 Diagrama UML a cazurilor de utilizare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Figura 1. 7 Legenda vizibilității membrilor unei clase . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figura 1.8 Legenda tipurilor de relații a unei diagrame UML de clase . . . . . . . . . . . . . . 21
Figura 1.9 Diagrama UML de clase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
Figura 1.1 0 Diagrama de clase a pachetului controller . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figura 1 .11, Diagrama de clase a pachetului entities . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Figura 1.12 Diagrama de clase a pachetului util . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figura 1.13 Diagrama de clase a pachetului user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Capitolul 2
Figura 2.1 Exemplu de cod în Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figura 2.2 Exemplu de Qua rtz declanșat la fiecare cinci minute . . . . . . . . . . . . . . . . . . .27
Figura 2.3 Exemplu de pagină JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
Figura 2.4 Exemplu de tag JSF pentru gestiunea apelurilor Ajax . . . . . . . . . . . . . . . . . . 30
Figura 2.5 Exemplu de entitate mapată în Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figura 2.6 Conexiunea cu My SQL prin fișierul persistence.xml . . . . . . . . . . . . . . . . . . 35
Figura 2.7 Structura unui proiect Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figura 2.8 Dependențele din fișierul pom.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figura 2.9 Exemplu de document HTML5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Figura 2.10 Exemplu de stilizare cu CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figura 2.11 Exemplu de metodă jQuery în JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

– 74 –
Capitolul 3
Figura 3. 1 Formularul de înregistrare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figura 3.2 Pagina de editare a unui task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figura 3.3 Vizualizarea detaliată a unui task din perspectiva adminului . . . . . . . . . . . 56
Figura 3.4 Căutarea avansată . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figura 3.5 Filtrarea coloanelor din tabel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figura 3.6 Calend arul ședințelor planificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
Figura 3.7 Rapoartele taskurilor din perspectiva administratorului . . . . . . . . . . . . . . . 60
Figura 3.8 Raportul unui utilizator di n perspectiva administratorului . . . . . . . . . . . . . 61
Figura 3.9 Raportul ședințelor din perspectiva administratorului . . . . . . . . . . . . . . . . 63
Figura 3.1 0 Editarea descrierilor succinte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Figura 3.1 1 Conținutul paginii d e gestiune a utilizatorilor . . . . . . . . . . . . . . . . . . . . . .65
Figura 3. 12 Bara de navigare a angajatului . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Figura 3. 13 Bara de navigare a managerului . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Figura 3.14 Bara de navigare a unui super -user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
Figura 3.15 Bara de navigare a administratorului . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

– 75 –
BIBLIOGRAFIE

[1] Markus Eisele, Modern Java EE Design Patterns, E ditura O'Reilly, Octombrie 2015
[2] Christian Bauer, Gavin King, Java Persistence with Hibernate, Editura Manning , 2006
[3] Bill Dudney, Jonathan Lehr, Masteri ng Jav aServer Faces, Editura Wiley , Iunie 2004
[4] Tanuj Khare, Apache Tomcat 7 Essentials, Editura Packt Publishing, Martie 2012
[5] Boriga R adu, Cursul „Programare Avansată pe Obiecte”, Universitatea București, 2 017
[6] https://en.wikipedia.org/wiki/Unified_Modeling_Language
[7] https://en.wikipedia.org/wiki/Model -view -controller
[8] http://docs.oracle.com/javaee/6/tutorial/doc /bnbpz.html
[9] https://en.wikipedia.org/wiki/Hibernate_(framework)
[10] https://www.w3.org/standards/webdesign/htmlcss
[11] https://developer.mozilla.org/en -US/docs/Web/JavaScript/Reference