Universitatea POLITEHNICA București

Facultatea Automatică şi Calculatoare

Departamentul Automatică şi Informatică Industrială

LUCRARE DE LICENŢĂ

Managementul activităţii ştiinţifice pentru

membrii unui departament universitar

Coordonator Absolvent
Grad didactic, prenume şi nume Prenume şi nume
 Anul absolvirii 2017

Cuprins (orientativ)
1. Introducere (de ex.: justificarea alegerii temei, descrierea succintă a conţinutului
fiecărui capitol)................................................................................................................ 3
1.1. Scurtă prezentare a aplicaţiilor web..........................................................................3
1.2. Scopul lucrării...........................................................................................................4
1.3. Motivaţie...................................................................................................................4
1.4. Descrierea capitolelor...............................................................................................5
2. Descrierea conceptelor teoretice pe care se bazează aplicaţia.......................................... 6
2.1. Concepte ce ţin de dezvoltarea aplicaţiilor web.........................................................6
2.1.1. Descrierea modelului client-server
2.1.2. Modelul TCP-IP
2.1.3. Protocolul HTTP
2.1.4. Principiile REST
2.1.5. Modul de funcţionare a unui server Java
2.2. Descrierea conceptului de text mining
2.2.1. Concepte generale
2.2.2. Evaluarea similarităţii dintre două documente
3. Descierea tehnologiilor folosite

2
1. Introducere
1.1 Scurtă prezentare a aplicaţiilor web

În ultimul deceniu, numeroase ramuri din domeniul tehnologiei s-au dezvoltat într-
un ritm alert, având un efect simţitor în îmbunătaţirea calităţii vieţii oamenilor.

Dacă acum ceva timp o simplă conexiune la Internet era un lux pe care nu oricine
şi-l putea permite, s-ar putea spune că în ziua de azi Internetul a devenit un element
indispensabil al vieţii de zi cu zi.

Ca un scurt istoric, anul 1990 a fost cel în care doi ingineri de la CERN au pus
temeliile serviciului World Wide Web(WWW). Acesta fusese creat cu scopul de a fi folosit
într-un mediu academic, pentru a uşura transferul de informaţii între oamenii de ştiinţa din
diverse instituţii şi universităţi.

Serviciul WWW(World Wide Web) s-a dezvoltat de-a lungul timpului în aşa
măsură încât de la simplele pagini web statice care aveau ca scop doar furnizarea de
informaţie s-a realizat o tranziţie la pagini web dinamice orientate pe interacţiunea cu
utilizatorul .

Aceste website-uri ce îşi generează conţinutul în mod dinamic în funcţie de

cerinţele utilizatorului şi îndeplinesc diverse funcţionalităţi specifice au căpatat denumirea
de aplicaţii web, termenul de aplicaţie fiind folosit pentru a denota o anumită
complexitate, pentru a se diferenţia de un simplu website care doar prezintă nişte
informaţii.

Aplicaţiile web au principalele avantaje de a putea fi accesate de pe orice dispozitiv

conectat la Internet şi de a fi independente de sistemul de operare, fapt pentru care au
devenit din ce în ce mai populare în rândurile utilizatorilor. Rând pe rând, s-au dezvoltat tot
mai multe aplicaţii ce oferă facilităţi într-o varietate largă de domenii. Câteva exemple
demne de menţionat ar fi: aplicaţiile ce permit achiziţionarea de produse online, aplicaţii
pentru stocarea documentelor în mediul online, aplicaţii pentru generarea şi editarea de
documente în diverse formate, reţelele de socializare, diverse aplicaţii destinate
divertismentului, dar nu în ultimul rând aplicaţiile destinate mediului academic.

Analizând aplicaţiile web ce se utilizează în mediul academic, se pot distinge două

mari tipuri:
● Aplicaţii destinate elevilor sau studenţilor, precum platformele de cursuri
online, platformele de vizualizare a situaţiei şcolare
● Aplicaţii destinate cadrelor didactice precum platformele de gestionare a

3
 activităţii ştiinţifice

În cadrul acestei lucări, se va dezvolta o aplicaţie web destinată mediului academic

ce presupune gestionarea activităţii ştiinţifice a membrilor unui departament din cadrul
unei facultăţi.

1.2 Scopul lucării

Obiectivul principal al acestei lucrări constă în realizarea unei aplicaţii web ce are
ca scop managementul activităţii ştiinţifice a membrilor din departamentul unei
universităţi.

Aplicaţia îşi propune să centralizeze toate articolele ştiinţifice scrise de personalul

academic ce face parte din respectivul departament, principalele ei funcţionalităţi fiind:

● Posibilitatea unui cadru didactic de a îşi crea un cont

● Posibilitatea ca odată ce un utilizator şi-a creat un cont, să îşi poată încărca
propriile lucrările ştiinţifice
● Căutare de articole în funcţie de autor(i)
● Realizarea unor statistici la nivel de individ sau departament(care este
utilizatorul cu cele mai multe articole, câte articole a încărcat un utilizator)
● Generarea unor rapoarte privind activitatea utilizatorilor(toate articolele
publicate de un autor)
● Asigurarea că nu vor exista duplicate printre lucrările încarcate

Principalul avantaj al implementării unei astfel de aplicaţii este reprezentat de

facilitarea accesului la resurse. Astfel, dacă un cadru didactic doreşte să vizualizeze un
articol ştiinţific al cărui autor este unul dintre colegii săi de departament, utilizând această
platformă, se va uşura în mod semnificativ procesul de căutare ce în mod normal ar fi
presupus mersul la bibliotecă sau utilizarea unor alte motoare de căutare specializate.

Un alt avantaj este reprezentat de faptul că la sfârşitul unui an se vor putea

vizualiza rapoarte cu privire la activitatea utilizatorilor, făcandu-se publice informaţii
precum: cine a publicat cele mai multe articole, ce articol a avut cele mai multe accesări.

1.3 Motivaţie

Pe piaţă există deja o varietate de aplicaţii destinate urmăririi activităţii ştiinţifice

pentru reprezentanţii mediului academic, fapt ce reprezintă un punct de plecare în
realizarea acestei lucrări. Desigur că aceste aplicaţii prezintă anumite părţi pozitive, dar şi
negative.

4
 Multe din functionaliţăţile lucrării ce urmează a fi dezvoltate au fost inspirate de
platforma Research Gate, diferenţa majoră fiind că aplicaţia curentă va fi restricţionată la a
fi folosită doar de membrii departamentului unei singure facultăţi, pe când Research Gate
permite înregistrarea membrilor oricărei facultaţi, indiferent de specializare, oraş, ţară.

O altă platformă ce a reprezentat un model de plecare este platforma Scopus. O

problemă majoră ce a fost însă detectată aici a fost că printre lucrările încărcate se gasesc
duplicate. Astfel, dacă un articol ştiinţific are mai mulţi autori şi unul din ei deja a încărcat
lucrarea, există posibilitatea ca un altul să o încarce din nou, fară a fi notificat. Lucrarea de
faţă îşi propune să rezolve această problemă.

De asemenea, alegerea acestei teme este motivată şi de dorinţa de a explora mai

mult acest domeniu al aplicaţiilor web ce se află în continuă dezvoltare şi va ramâne cu
siguranţă de actualitate în anii ce vor urma.

1.4 Descrierea capitolelor

În capitolul 2 sunt prezentate concepte teoretice care stau la baza dezvoltării

aplicaţiei. În prima parte sunt descrise: modelul client-server, protocolul HTTP, principiile
REST şi modul de funcţionare a unui server Java, pe când în a doua parte se regăsesc
concepte fundamentale legate de text-mining şi prezentarea unei metode de evaluare a
similarităţii între două documente.

În capitolul 3 sunt prezentate tehnologiile folosite pentru implementarea aplicaţiei:

Spring framework pentru partea de server, Angular JS pentru partea de client, MySQL
pentru baza de date.

5
2.Descrierea conceptelor teoretice pe care se bazează
aplicaţia

2.1 Concepte ce ţin de dezvoltarea aplicaţiilor web

2.1. Descrierea modelului client-server

Privind scenariul de funcţionare a unei aplicaţii web sau chiar şi al unui website
static se pot identifica două entităţi esenţiale. O primă entitate ar fi cea care solicită
anumite servicii specifice ca de exemplu o cerere de vizualizare a unui anumit fişier sau a
unei imagini şi este denumită client. Cea de a doua entitate este cea care asigură deservirea
unui răspuns către orice solictare făcută şi poartă denumirea de server. Urmând aceste
specificaţii, a fost conceput modelul arhitectural client-server, care în prezent stă la baza
implementării aplicaţiilor WWW.

Fig x.x Modelul client-server

Clientul, care poate fi reprezentat de un calculator, laptop, smartphone, tabletă,

prin intermediul unui web browser, va solicita de la server o anumită resură(un fişier
HTML, o imagine sau orice alt tip de date), acţiune ce poartă numele de trimitere a unei
cereri.

Serverul, care este o maşină de calcul specializată va înregistra cererea primită de la

client şi va decide dacă să îi răspundă sau nu cu resursa solicitată. Serverul trebuie să fie
activ non-stop pentru a putea procesa cererile clienţilor.

6
 Pot exista mai multe tipuri de servere în funcţie de funcţionalitatea pe care acestea
o îndeplinesc. Câteva exemple ar fi: server web(Apache, Microsoft Internet Information
Services), server de baze de date(MySql, Oracle, SQL Server), server pentru servicii de
mail ce foloseşte protocolul SMTP(Simple Mail Transfer Protocol).

2.1.2 Modelul TCP-IP

Pentru a fi posibilă dezvoltarea unei aplicaţii web este necesară existenţa unui
standard prin care să se asigure transmisia datelor pe Internet. În această privinţă este
utilizat modelul TCP-IP(Transmission Control Protocol- Internet Protocol), o variantă
simplificată a stivei OSI(Open Systems Interconnection), în care se regăsesc doar patru
niveluri, ci anume:

1.Accesul la mediu
2.Reţea(Internet)
3.Transport
4.Aplicaţie

Fig x.x Modelul OSI vs modelul TCP/IP [poza din Tanenbaum]

De menţionat este faptul că stiva OSI reprezintă un model pur teoretic, ce nu a fost
niciodată implementat în mod concret, în timp ce TCP-IP este modelul real pe baza căruia
se realizează transmisia datelor în cadrul Internetului.

Pentru dezvoltatorii de aplicaţii web, nivelul de interes este cel de aplicaţie. Acesta
înglobează funcţionalităţile aduse de nivelurile sesiune, prezentare şi aplicaţie propuse la
stiva OSI. De asemenea, la acest nivel sunt folosite protocoale de nivel înalt precum:
HTTP(Hypertext Transfer Protocol), DNS(Domain Name Service), SMTP(Simple Mail
Transfer Protocol), FTP(File Transfer Protocol).

7
 2.1.3. Protocolul HTTP

Pentru a se realiza comunicarea între client şi server este necesară utilizarea unui
protocol de nivel înalt, ci anume HTTP(Hypert Text Transfer Protocol), care acţionează la
nivelul aplicaţie al stivei TCP-IP.

În primă instanţă, HTTP iniţiază o conexiune TCP-IP folosind în mod implicit

portul 80, iar ulterior clientul va avea posibilitatea de a trimite cereri către server. Cum
HTTP este un protocol de tipul cerere/răspuns, pentru fiecare cerere serverul garantează
trimiterea unui răspuns.

Entităţile pe care serverul trebuie să le deservească şi pe care le gestionează poartă

denumirea de resurse, iar pentru a fi identificare în mod unic, acestora li se asignează un
URI(Uniform Resource Identifier), ce nu este altceva decât un şir de caractere în care este
precizat numele resursei şi locaţia pe server.

Un client va avea posibilitatea de a solicita efectuarea unei serii de acţiuni specifice

asupra unei resurse. Cele mai uzuale acţiuni care îi sunt premise sunt: solicitarea
informaţiilor despre o anumită resursă, solicitarea creării unei noi resurse, solicitarea
modificării unei resurse, solicitarea de ştergere a unei resurse.

Acţiunile menţionate mai sus trebuie totuşi să se integreze într-un anumit standard,
de aceea protocolul HTTP aduce o serie de metode specifice prin intermediul cărora
clientul poate interacţiona cu o resursă. Cele mai utilizate metode HTTP sunt:

 GET – serveşte o anumită resursă specificată în cadrul URL-ului

 POST – creează o nouă resursă, dar spre deosebire de GET datele nu mai sunt
transmise prin intermediul URL-ului, ci sunt încapsulate în conţinutul headerului
 UPDATE – actualizează o resursă
 DELETE – şterge o resursă

Alte exemple de metode HTTP mai puţin utilitzate: OPTIONS, CONNECT,

HEAD, TRACE.

Protocolul HTTP specifică faptul că orice metodă HTTP trebuie să aibă un anumit
format. Astfel, în cadrul unei cereri de orice tip va exista un header în care vor fi specificaţi
anumiţi parametri. Conform standardelor, headerul trebuie să conţină întotdeauna pe prima
linie metoda HTTP folosită, URI-ul şi versiunea HTTP. În prezent este folosită versiunea
1.1 care diferă de versiunea 1.0 prin faptul că este posibilă emiterea mai multor cereri şi
răspunsuri pe aceeaşi conexiune TCP, ceea ce nu era posibil la versiunea anterioară. Un
exemplu de header HTTP este redat în figura următoare:

8
 Figura x.x Exemplu de header HTTP

În exemplul de mai sus:

 prin parametrul Host se precizează ce domeniu va fi accesat

 parametrul Connection setat cu opţiunea keep-alive specifică faptul că serverul
trebuie să menţină deschisă conexiunea
 Cache-Control setează mecanismul de caching ce va fi folosit în cadrul cererii
 Parametrul Accept precizează ce tipuri media sunt permise pentru a fi primite ca
răspuns

După ce a primit cererea de la client, serverul va veni cu un răspuns, ce va fi însoţit de

un cod status specific. Există mai multe clase de statusuri, în funcţie de situaţie:

1. Clasa 2xx – statusurile ce au această formă marchează că cererea a fost finalizată cu

succes, iar clientul a primit un răspuns
2. Clasa 3xx – acest status este generat în cazul în care este necesară redirectarea
3. Clasa 4xx – semnifică faptul că a avut loc o eroare din partea clientului( Exemplu:
clientul a încercat să acceseze o resursă la care nu are acces)
4. Clasa 5xx –semnifică faptul că a avut loc o eroare pe server

2.1.4. Principiile REST

Denumirea de REST repezintă un acronim din limba engleză ce provine de la

Representational State Transfer. REST este un set de reguli bazat pe standardele HTTP
şi HTML prin care se precizează cum să fie implementate API-urile(Application
Programming Interface) aplicaţiilor web.

În cadrul aplicaţiei dezvoltate, nivelul client şi nivelul server vor fi implementate

folosind principiile REST.

Conceptele fundamentale REST:

 resursă
 reprezentare

9
 O resursă este o entitate care are o anumită însemnătate în aplicaţie. Potrivit
principiilor REST fiecare resursă trebuie să aibă un URL(Uniform Resource Locator) care
este unic.

Conceptul de reprezentare se referă la reprezentarea unei resurse. Atunci când

clientul face o cerere HTTP asupra unei resurse, serverul îi returnează ca răspuns un
document ce are semnificaţia de reprezentare a stării resursei.

O resursă poate avea mai multe stări, iar starea într-un anumit moment este
cunoscută doar de server. Clientul poate totuşi să ceară schimbarea stării resursei prin
intermediul unei cereri HTTP. De asemenea o resursă poate avea mai multe
reprezentări(cazul documentelor ce sunt disponibile în mai multe limbi).

2.1.5. Modul de funcţionare a unui server Java

Aşa cum a fost prezentat până acum, o aplicaţie web este construită pe modelul
client-server. La prima vedere, principiul este unul simplu de înteles, funcţia principală a
serverului fiind aceea de a trata cererile venite de la clienţi, însă mecanismul din spatele
acestui proces este unul mai complex.

Pentru a înţelege mai bine contextul, se va pleca de la prezentarea funcţiei pe care o

are un web server. Acesta este responsabil doar cu servirea resurselor statice(pagini statice
HTML, imagini, alte tipuri de fişiere), nu cunoaşte nimic legat de logica aplicaţiei. Deci,
dacă un client va face o cerere în care va solicita altceva decât servirea de conţinut static,
cum ar fi efectuarea unor calcule, web serverul nu va şti cum să îi răspundă. Din acest
motiv este necesară existenţa unei terţe părţi către care web serverul să paseze aceste cereri
pe care nu este capabil să le trateze. În cazul aplicaţiilor care nu folosesc Java acest
program ajutător poartă numele de CGI(Common Gateway Interface).

În cazul aplicaţiilor web Java Enterprise tratarea cererilor ce presupun şi generarea

de conţinut dinamic este realizată de către Servlet-uri. Acestea sunt nişte clase speciale ce
extind clasa HttpServlet şi înglobează logica aplicaţiei ce ţine de trimiterea unui anumit
răspuns către client, în funcţie de cererea efectuată. Fără existenţa Servlet-urilor, serverul
web ar fi capabil doar de servirea resurselor statice.

Pentru ca Servlet-urile să poată fi folosite într-o aplicaţie Java este necesară

existenţa unui Servlet Container. Acest Servlet Container este integrat în serverul web şi
are rolul de a gestiona ciclul de viaţă al Servlet-urilor. Deci, serverul web comunică în mod
direct doar cu Servlet Containerul, nu are acces la Servlet-uri. Atunci când serverul web
înregistrează o cerere ce trebuie tratată în mod dinamic, trimite un mesaj către Servlet
Container care se va ocupa în continuare de cerere. Acesta va crea un obiect de tipul
HttpServletRequest şi un obiect de tipul HttpServletResponse în cadrul aceluiaşi thread şi
apoi în funcţie de un fişier de configurare XML va decide către ce Servlet să trimită mai

10
departe cererea. Unul dintre principalele avantaje ale folosirii Servlet-ului este că acesta
poate fi accesat simultan de mai multe thread-uri.

Fig x.x Arhitectura unui server web ce conţine un Servlet Container

Chiar dacă principala funcţionalitate a CGI-ului şi a Servlet-ului este aceeaşi, între

cele două există anumite deosebiri din urma cărora se concluzionează că Servlet-ul aduce o
serie de avantaje. Principala deosebire este că un CGI, pentru fiecare cerere venită de la
client va deschide un nou proces, în timp ce în cazul Servlet-urilor se va deschide un nou
thread, ceea ce este mai puţin consumator de resurse. O altă deosebire este aceea că
Servlet-ul fiind scris în Java este portabil şi independent de platformă.

Unul dintre cele mai cunoste servere web ce oferă o implementare pentru Servlet
Container este Tomcat, un server open-source licenţiat de cei de la Apache. Alte exemple
de servere ce rulează pe un mediu Java: Glassfish, Jetty, Wildfly.

2.2 Descrierea conceptului de text mining

2.2.1 Concepte generale

Întrucât această lucrare conţine şi o parte de procesare de text, în acest capitol se

vor prezenta câteva concepte esenţiale ce ţin de text mining.

Conceptul de text-mining se referă la totalitatea procedeelor ce se aplică asupra

unui text nestructurat cu scopul final de a extrage din el informaţie utilă.

Text-miningul s-a născut din necesitatea procesării unor volume mari de date ce nu
sunt reprezentate într-o formă standard de tip tabel în care informaţia este structurată pe
rânduri şi coloane. În această categorie se încadrează documentele Word, documentele
PowerPoint, documentele în format PDF, în care textul nu este organizat într-o manieră
uniformă.

În vederea implementării unui algoritm ce presupune text-mining sunt necesare

cunoştinţe din mai multe domenii precum: data-mining, machine learning, statistică,
procesare de limbaj natural.

11
 Pentru a realiza text-mining, în primul rând este necesară colectarea documentelor
text ce urmează a fi procesate şi analizate.

Următoarea etapă constă în parsarea de text. Aici se va face împărţirea textului în

termeni de sine stătători, mai exact cuvinte. Cum un document poate conţine mii de
cuvinte, este necesă o analiza a textului pentru a se extrage doar acele cuvinte cheie,
relevante pentru a descrie conţinutul documentului. Mai departe, aceste cuvinte cheie vor fi
adăugate într-un dicţionar care va avea înregistrări de forma termen:număr_de_apariţii.
Acest dicţionar este util pentru a determina frecvenţa de apariţie a unui cuvânt.

Etapa ulterioară parsării unui document constă în înglobarea dicţionarelor pentru

toate documentele pentru a crea o matrice în care vor fi stocaţi toţi termenii cheie obţinuţi
din toate documentele, precum şi numarul lor de apariţii pe fiecare document în parte.
Acest procedeu mai poartă numele de indexare.

Un exemplu de astfel de matrice poate fi:

Termen Document 1 Document 2 Document 3 Document 4

carte 2 0
limbaj 1 3
programare 6 4
utilitate 3 2
variabile 4 3
procesare 1 0
Tabel 2.1 Exemplu de matrice
5 1
3 2
2 5
5 2
1 5
3 1

Această matrice este esenţială în căutarea după termeni cheie, deoarece astfel se pot
determina foarte uşor documentele în care se găseşte un anumit cuvânt. În cazul în care
această matrice nu ar fi creată şi s-ar face o căutare cuvânt cu cuvânt în toate documentele
existente, procesul ar fi foarte consumator de timp şi ar putea dura ore întregi în funcţie
dimensiunea documentelor sau numărul lor. Această metodă ne asigură însă un timp de
răspuns foarte rapid, fiind tehnica de bază utilizată la motoarele de căutare.

2.2.2 Evaluarea similarităţii dintre două documente

Cum unul dintre obiectivele principale ale acestei lucrări este evitarea stocării de
documente duplicate, în acest capitol se va prezenta teoria din spatele tehnicii de evaluare a
similarităţii dintre doua documente.

12
 Pentru a se putea calcula gradul de similaritate între documente este necesară
organizarea datelor folosind modelul vectorial. Utilizarea modelului vectorial presupune că
toate entităţile cu care se operează vor fi reprezentate sub forma de vector, într-un spaţiu
vectorial n-dimensional. Entităţile pot fi documente text sau interogări.

Dacă avem mai multe documente pentru care s-a calculat matricea de frecvenţă a
apariţiei termenilor, atunci dimensiunea spaţiului vectorial va fi dată de numărul de linii ale
matricii, adică de numarul de cuvinte cheie selectate.

Pentru exemplificare se va considera că numarul documentelor ce au fost indexate

este 3 şi dimensiunea spaţiului vectorial este tot 3. Notăm cei 3 termeni cu T1, T2, T3,
aceştia reprezentând un set de vectori liniar independenţi ce formează o bază vectorială.

Pentru a transpune cele 3 documente în spaţiul vectorial obţinut din cei trei termeni
va trebui să construim, pentru fiecare document, un vector format din 3 elemente, astfel: pe
prima poziţie vom avea numărul de apariţii al lui T1, pe a doua poziţie numărul de apariţii
al lui T2, analog pentru T3 . Cei 3 vectori obţinuţi(E1, E2, E3) vor fi apoi reprezentaţi în
spaţiul vectorial determinat de T1, T2, T3.

Fig x.x Reprezentarea vectorilor

Algoritmul prezentat mai sus se poate generaliza pentru un spaţiu vectorial n-

dimensional, ceea ce se şi întâmplă în practică.

Având documentele reprezentate în această formă vectorială, problema de

determinare a similarităţii dintre două documente poate fi abordată acum prin două
metode:

 calculul distanţei euclidiene dintre cele două puncte

 calculul cosinusului unghiului dintre cei doi vectori

13
 În cazul procesării clasice de text este utilizată cea de a doua variantă.

Cosinusul dintre cei doi vectori sau similaritatea se calculează după următoarea
formulă:

unde a si b sunt 2 vectori de dimensiune n.

Valorile cosinusului sunt numere reale ce aparţin intervalului [0, 1].

Pentru documente complet distincte similaritatea va fi foarte aproape de 0, iar pentru

documente identice va lua valoarea 1.

3.Descrierea tehnologiilor folosite

Odată ce specificaţiile unui proiect au fost stabilite, etapa următoare în dezvoltare

constă în alegerea tehnologiilor ce urmează a fi folosite. Desigur, în acest proces trebuie
luaţi în considerare diverşi factori ce ţin de aplicaţie în sine. La final programatorul este cel
care va decide ce anume este prioritar: ca aplicaţia să fie dezvoltată într-un timp cât mai
scurt, ca aplicaţia să fie scalabilă şi uşor de integrat în alte medii, ca aplicaţia să fie foarte
bine securizată şi de aici va decide ce tehnologie se pretează cel mai bine.

Alte aspecte ce ar mai trebui luate în considerare la alegerea tehnologiilor este ca

acestea să aibă o documentaţie amplă şi să fie utilizate la scară largă. De asemenea, un plus
l-ar reprezenta faptul ca tehnolgiile să fie open-source.

Termenul de open-source provine din limba engleză şi se referă la faptul că, pentru
un anumit proiect, codul sursă este disponibil integral în mediul online. Mai mult, la
proiectele open-source poate contribui oricine atâta timp cât reuşeşte să aducă o
îmbunătăţire sau să rezolve o problemă anterioară.

În ultimii ani, în sfera tehnologiilor web s-au dezvoltat o mulţime de proiecte open-
source care au căpătat amploare şi acum sunt folosite ca şi tehnologii de bază în
companiile software.

Pentru implementarea acestei aplicaţii s-a urmărit ca tehnologiile folosite să fie

open-source, să aibă o documentaţie consistentă şi să permită dezvoltarea unei aplicaţii
scalabile şi sigure.

14
 Mai jos este prezentată o schemă cu principalele tehnologii utilizate, ce urmează a
fi detaliate în capitolele următoare.

Fig x.x Principalele tehnologii utilizate la dezvoltarea aplicaţiei

Pe langă tehnologiile principale prezentate mai sus s-au mai folosit biblioteci open-
source de Java(PDFBox şi Apache Lucene), un tool care se ocupă cu managementul
dependenţelor proiectului(Apache Maven) şi un framework de testare unitară(JUnit).

3.1 Spring framework

Pentru dezvoltarea părţii de back-end s-a folosit frameworkul Spring scris în

limbajul de programare Java.

Spring este un framework ce a fost conceput în anul 2002 ca o alternativă la alte

tehnologii Java precum EJB(Enterprise Java Beans) sau appleturi. Reprezintă o colecţie de
clase şi interfeţe compilate sub formă de fişiere JAR.

Datorită multitudinii de funcţionalităţi pe care le oferă, a uşurinţei de utilizare şi a

faptului că este open-source, Spring a dobândit o popularitate imensă printre programatorii
Java devenind cel mai utilizat framework folosit pentru dezvoltarea aplicaţiilor web.

Principiile de bază ale frameworkului Spring sunt:

1.Utilizarea de POJOs(Plain Old Java Objects)
2. Utilizarea unui mecanism de management al dependenţelor între obiecte

Utilizarea de POJOs în cadrul frameworkului Spring

15
 Prin definiţie, POJOs sunt nişte obiecte Java construite în aşa fel încât să nu
depindă de clase sau interfeţe definite în cadrul frameworkului.

Alte frameworkuri anterioare Springului îi impuneau programatorului să extindă

anumite clase sau să implementeze anumite interfeţe. Acest lucru reducea din scalabilitatea
şi flexibilitatea codului, făcându-l şi mai dificil de urmărit şi înţeles.

Într-o aplicaţie Spring sunt utilizate cu precădere POJO-urile, iar pentru a semnala
faptul că unele clase definite de programator depind de alte clase sau interfeţe interne
frameworkului se folosesc adnotări specifice.

Mecanismul de management al dependeţelor între obiecte

Orice aplicaţie este construită din mai multe clase ce pot interacţiona între ele prin
relaţii de moştenire sau agregare.

Relaţia de agregare presupune ca o clasă sa aibă printre atributele sale un obiect de

tipul altei clase. În acest caz, pot exista situaţii în care un obiect agregat va fi strict
dependent de un obiect din cadrul clasei din care face parte, instanţa acestuia fiind creată
direct în constructor.

Ca şi exemplu se poate considera urmatoriul scenariu:

Principiul de management al dependenţelor în Spring presupune ca în

implementarea unei relaţii de agregare, obiectul agregat să fie trimis ca parametru în
constructor. Astfel, constructorul pentru clasa Persoana va fi definit astfel:

Alegând o variantă de implementare în care dependenţele sunt injectate, se va

beneficia de următoarele avantaje:

16
 ● simplificarea procesului de testare
● codul devine mai uşor de reutilizat
● obiectele injectate vor avea propriul lor ciclu de viaţă
● în cadrul Spring, la crearea unui obiect, dependinţele sunt gestionate de către
framework

3.1.2 Componentele frameworkului Spring

Frameworkul Spring este alcătuit din aproximativ 20 de module ce pot fi importate

în cadrul unui proiect Java ca şi JAR-uri externe. Acestea sunt împărţite, după
funcţionalitate în: module pentru partea de web, module pentru manipularea şi accesul la
date, module de AOP(Aspect Oriented Programming), module de testare.

Pentru asigurarea funcţionalităţilor aplicaţiei, în cadrul acestui proiect au fost

folosite următoarele module:

 Spring Core
 Spring Boot
 Spring MVC(Model-View-Controller)
 Spring Data JPA
 Spring Security

Spring Core este modulul ce stă la baza frameworkului şi oferă funcţionalităţile de

bază precum posibilitatea de injectare a dependinţelor şi utilizarea de bean-uri.

Spring Boot este un modul ce uşurează foarte mult munca programatorului. În

cazul în care nu se foloseşte Spring Boot este necesar să se configureze aplicaţia prin
intermediul unor fişiere XML speciale sau direct din cod. În cadrul Spring, totuşi,
configurarea proiectului este foarte anevoioasă şi necesită foarte multe cunoştinţe. Spring
Boot, odată importat în proiect, vine cu o configuraţie implicită, astfel încât programatorul
se poate concentra acum mai mult pe funcţionalitatea aplicaţiei decât pe configurarea ei.

Spring MVC(Model-View-Controller) este un modul esenţial ce trebuie utilizat în

dezvoltarea de aplicaţii web. Este construit pe baza design patternului MVC.

MVC este un model arhitectural ce se referă la cum trebuie structurată o aplicaţie la

nivel de cod şi este folosit în general la implementarea aplicaţiilor web. Cele 3 componente
de bază sunt:/

 Modelul –folosit pentru manipularea şi modelarea resurselor aplicaţiei. Reprezintă

în mod conceptual o entitate, ce are mai multe atribute. Se poate face o analogie cu
noţiunea de tabel întalnită în domeniul bazelor de date
 Controllerul –se ocupă de logica aplicaţiei, de interacţiunea între modele. În
principal, fiecare controller va avea desemnată o anumită rută şi va servi toate
cererile făcute la acea rută

17
  View-ul –are ca rol funcţia de afişare a datelor preluate de la controller

Principala caracteristică a Spring MVC este că dispune de un servlet global, numit

DispatcherServlet ce are rolul de a împărţi cererile către controllere.

Astfel, în imaginea de mai jos se observă cum o cerere este mai întâi tratată de un
Front Controller care o redirecţionează către controllerul ce trebuie să servească răspunsul.

Răspunsul este trimis înapoi către Front controller, ce îl va trimite ulterior către
view pentru a fi randat corespunzător.

Fig x.x Fluxul unei cereri în Spring MVC

Spring Data JPA este un modul prin care se realizează interacţiunea aplicaţiei cu
baza de date. Oferă suport atât pentru baze de date relaţionale, cât şi pentru cele
nerelaţionale.

Lucrul cu baza de date se face acum la un nivel abstractizat. În Spring Data JPA
fiecărui tabel din baza de date îi corespunde acum un repository, ce este implementat prin
intermediul unei interfeţe care va extinde o interfaţă pusă la dispoziţie de Spring. Există
două interfeţe de bază ce pot fi utilizate: CrudRepository şi JpaRepository, ce trebuie să fie
parametrizate corespunzător.

Interfaţa CrudRepository pune la dispoziţie funcţionalităţile de bază CRUD(Create-

Read-Update-Delete) pentru o resursă.
În figura x.x este prezentat o parte din codul sursă pentru interfaţa CrudRepository,
care conţine următoarele metode:
1. Save –salvează o entitate în baza de date

18
 2. findOne –returnează o entitate în funcţie de id
3. findAll – returnează toate înregistrările dintr-un tabel
4. count – returnează numărul total al înregistrărilor dintr-un tabel
5. delete –şterge o înregistrare din baza de date
6. exists – verifică existenţa unei entităţi în baza de date

n
Fig x.x Codul sursă pentru interfaţa CrudRepository

Astfel, prin extinderea interfeţei CrudRepository, programatorul va avea la

dispoziţie în mod implicit toate metodele prezentate mai sus şi va putea efectua operaţii
CRUD asupra resurselor, fără a fi nevoie să mai scrie interogări clasice în limbajul SQL.

De asemenea, există posibilitatea definirii unor interogări particulare folosind JPQL

(Java Persistence Query Language), un limbaj de interogare specific Java a cărui sintaxă
este asemanătoare cu cea SQL.

Spring Security este modulul responsabil pentru securitatea aplicaţiei. Oferă

suport în ceea ce priveşte autentificarea si autorizarea.

Autentificarea este procesul prin care se stabileşte dacă un utilizator este cine
pretinde. În general, autentificarea se face prin intermediul unui formular de login, în care
utilizatorul îşi introduce username-ul şi parola, iar sistemul de securitate stabileşte
validitatea lor.

Autorizarea sau controlul accesului constă în procesul prin care se stabileşte dacă,
odată autentificat, un utilizator are sau nu permisiunea de a efectua o anumită acţiune
asupra aplicaţiei. Aşa cum este binecunoscut, o aplicaţie poate avea mai multe tipuri de
utilizatori, dintre care cele mai cunoscute roluri sunt cele de ADMIN şi USER. Autorizarea
este necesară pentru a se determina ce permisiuni îi sunt atribuite fiecărui rol.

19
 Spring Security este construit pe baza unui mecanism ce foloseşte un lanţ de
filtre.Astfel, dacă un utilizator face o cerere pentru a accesa o resursă protejată, până ca
cererea lui să ajungă la Servlet, acesta va trece printr-o serie de filtre ce pot fi responsabile
cu: redirecţionarea către un formular de login, verificarea usernameului şi a parolei,
generarea de mesaje de eroare.

3.2 Apache PDFBox

Apache PDFBox este o bibliotecă open-source scrisă în Java ce permite lucrul cu

documente în format PDF. Funcţionalităţile de bază sunt:
 extragerea textului dintr-un document PDF
 generarea de documente PDF
 împărţirea unui document PDF în mai multe documente
 îmbinarea mai multor documente în unul singur
 aplicarea unei semnături digitale pe un document PDF

În cadrul acestei aplicaţii, această bibliotecă a fost folosită pentru a extrage

conţinutul text al articolelor ştiinţifice ce sunt încărcate pe platformă.

3.3 Apache Lucene

Deoarece lucrarea presupune şi o parte de text-mining pentru a evita încărcarea de

articole duplicate, a fost necesară o bibliotecă ce pune la dispoziţie un API ce facilitează
lucrul cu documentele text.

Apache Lucene este o bibliotecă Java a cărei principală funcţionalitate este aceea
de a indexa documente ce conţin text şi de a facilita procesul de regăsire a informaţiilor.

Scopul unui index este de a optimiza viteza de răspuns atunci când se fac căutari
asupra unei colecţii foarte mari de documente.

Lucene foloseşte tehnica de indexare inversă, adică îşi creează un dicţionar de

cuvinte în care vor exista toţi termenii cheie ce au fost extraşi din documentele indexate şi
fiecărui termen i se asociază o listă cu documentele în care acesta se regăseşte. În acest fel
este accelerată căutarea după cuvinte cheie.

Înainte de indexarea unui document, programatorul are posibilitatea de a îi ataşa

mai multe câmpuri în care să reţină anumite informaţii, de exemplu conţinutul text al
documentului, numele, un ID.

Clasa IndexWriter este responsabilă pentru indexarea propriu-zisă a documentelor.

20
Cu o instanţă a acestei clase se poate crea sau modifica un index deja existent. Fişierele
index vor fi apoi stocate într-un anumit director specificat de programator.

Odată indexate, operaţia de bază ce se poate realiza asupra documentelor este cea
de căutare. Pentru acest lucru avem disponibile clasele IndexSearcher şi IndexReader.
Pentru a deschide directorul în care este stocat indexul este necesară o instanţă a clasei
IndexReader, iar pentru a face interogări asupra indexului se foloseşte clasa IndexSearcher.

3.4 Tehnologii folosite pentru realizarea interfeţei cu utilizatorul

Deoarece interfaţa unei aplicaţii web este afişată într-un browser, este necesară
utilizarea unor tehnologii care să poată fi interpretate de browser. Principala tehnologie de
acest tip este cea HTML(HyperText Markpup Language) care pentru expunerea
conţinutului în pagină utilizează taguri ce au caracter de metadate.

O pagină descrisă doar prin intermediul limbajului HTML este implicit statică, nu
permite nicio interacţiune cu utilizatorul, nu face posibilă generarea de conţinut dinamic şi
nu poate implementa niciun fel de logică de control în ceea ce priveşte afişarea datelor.
Această limitare a tehnologiei HTML a fost rezolvată prin introducerea unui limbaj de
programare care să poată fi interpretat de browser şi să asigure servirea de conţinut
dinamic la interacţiunea cu utilizatorul. Acest limbaj poartă denumirea de Javascript şi a
apărut în anul 1995, având ca şi principale caracteristici faptul că este independent de
platformă şi orientat obiect.

3.4.1 Limbajul Javascript

Limbajul Javascript este principala tehnologie ce face posibilă realizarea unei

interfeţe dinamice pentru o pagină web.

La încărcarea unei pagini web în browser, acesteia i se generează un

DOM(Document Object Model) ce are forma unui arbore în care rădacina este tagul
<html> , iar frunzele pot fi reprezentate de restul tagurilor HTML existente.

Dacă utilizarea limbajului HTML permite doar afişarea de conţinut static (text sau
fotografii), prin JavaScript este posibilă modificarea DOM-ului la interacţiunea cu
utilizatorul.

O serie de exemple de utilizare a limbajului Javascript în cadrul unei aplicaţii web

ar putea fi: validarea formularelor înainte ca acestea să fie procesate pe server, realizarea
de animaţii, asocierea unor acţiuni pentru anumite evenimente (spre exemplu ce se
întâmplă când un utilizator apasă o anumită tastă sau trece cu mouse-ul peste un anumit
obiect), generarea de anumite alerte către utilizator, asigurarea comunicării între client si
server prin intermediul requesturilor AJAX.

21
 Javascript a fost iniţial utilizat doar la dezvoltarea aplicaţiilor pe partea de client,
însă ulterior a început să fie folosit şi ca limbaj de programare pe server, odată cu apariţia
frameworkului Node.js.

Pentru a fi uşurată munca programatorilor, în JavaScript au fost scrise o varietate de

framework-uri, cele mai utilizate fiind: AngularJS, React, Backbone, Ember.

Pentru realizarea acestei lucrări s-a ales să se folosească AngularJS.

3.4.2. Angular JS

Angular JS este un framework open-source de Javascript ce introduce noi concepte

în programarea client-side. Este constuit pe baza design patternului MVC(Model View
Controller).

Pentru a utiliza Angular JS, framework-ul trebuie importat în fişierul HTML aferent
paginii principale a aplicaţiei, care prin convenţie poartă denumirea de index.html .

Principala noutate adusă de Angular este extinderea sintaxei limbaului HTML prin
utilizarea unor atribute specifice în cadrul tag-urilor clasice. Aceste atribute poartă
denumirea de directive. Angular vine cu propriile sale directive, dar dacă este necesar,
programatorul îsi poate defini la rândul său altele. Un exemplu de astfel de directivă este
ng-app care iniţializează o aplicaţie de tip Angular.

Fişierele HTML care încorporează şi sintaxă specifică Angular poartă denumirea de

template-uri. Angular JS dispune de un compilator care scanează template-ul, recunoaşte
directivele Angular, le interpretează corespunzător, iar rezultatul final este view-ul, adică
ceea ce vede utilizatorul.

Unul din principalele avantaje aduse de Angular JS este acela că oferă sincronizare
automată între datele din model şi cele din view, concept cunoscut sub numele de data-
binding. Astfel, fiecare modificare adusa modelului va fi imediat înregistrată în view şi
viceversa prin intermediul unor watchere care vor monitoriza starea variabilelor.

În procesul de data-binding mai intervin alte două elemente foarte utilizate în

Angular, ci anume controllerul şi scope-ul. În general, fiecărui template i se asociază un
controller, prin intermediul căruia datele din model pot deveni disponibile în view. Cu toate
acestea, datele din model trebuie să existe şi într-un scope, deoarece controllerul şi
directivele nu au referinţe una către cealaltă, ci către scope.

Un alt concept cu care se lucrează în Angular este acela de service. În general, în

cadrul unui service se vor defini funcţii ce pot fi reutilizate. Pentru a face disponibile
funcţiile din cadrul unui service într-un controller, service-ul se va injecta în

22
controller.Angular are la bază un mecanism de injectare a dependinţelor prin care sunt
gestionate legăturile dintre componente.

Aplicaţiile web realizate cu Angular sunt aplicaţii de tipul SPA(Single Page

Application). Necesitatea introducerii acestui concept în programarea web s-a născut din
dorinţa de a i se oferi utilizatorului o experienţă cât mai plăcută la navigare.

Ideea de bază la aplicaţiile de tip SPA este că întreg conţinutul este integrat într-o
singură pagină. Toate fişierele auxiliare necesare, cum ar fi scripturile Javascript sau
fişierele CSS sunt acum încărcate o singuă data. La o aplicaţie clasică, organizată în mai
multe pagini, fiecare accesare de pagină presupunea încărcarea fişierelor JavaScript şi CSS
aferente, acest proces determinând creşterea timpului de răspuns. Aplicaţiile SPA
reprezintă o soluţie prentru rezolvarea acestei probleme.

La aplicaţiile SPA paginile sunt înlocuite de stări. Navigarea într-o aplicaţie

presupune acum doar tranziţia între aceste stări. De exemplu, dacă un utilizator doreşte să
acceseze o anumită componentă a unui meniu de navigare, nu se va reîncărca întreaga
pagină, ci se va randa doar view-ul corespunzător acelei stări. În general, fiecărei stări îi
corespunde un template, iar când utilizatorul doreşte să acceseze o stare, template-ul
asociat se va compila şi va rezulta astfel view-ul.

O aplicaţie de tip SPA va avea un singur URL, iar stările vor fi marcate prin
caracterul special #.

3.4.3 Bootstrap

Chiar dacă punctul forte al unei aplicaţii constă în funcţionalitate, nu ar trebui

ignorate detaliile legate de aspect. În cazul unei aplicaţii web, la tehnologiile HTML şi
Javascript care vor asigura afişarea corespunzatoare a informaţiilor în pagină, este necesară
utilizarea unei a treia tehnologii folosită la stilizare, tehnologie ce poartă denumirea de
CSS(Cascading Style Sheets).

În perioada incipientă a aplicaţiilor web se utilizau doar fişiere CSS externe pentru
realizarea designului unei pagini, însă pe parcurs au apărut diverse frameworkuri care îşi
propun să uşureze munca programatorului în acest sens, cele mai cunoscute fiind Bootstrap
şi Foundation.

Pentru acest proiect s-a ales să se folosească Bootstrap.

Bootstrap este un framework open-source de CSS, HTML şi Javascript ce a fost

dezvoltat de către compania Twitter, fiind iniţial utilizat doar intern. Este folosit exclusiv
pentru stilizarea interfeţelor grafice cu utilizatorul în cadrul aplicaţiilor web.

23
 Bootstrap vine cu o serie de clase CSS predefinite astfel încât aplicaţiile să aibă un
design uniform şi plăcut. Aceste clase se pot aplica pe elemente HTML precum formulare,
tabele, meniuri de navigare, butoane, div-uri.

Fig x.x Exemplu de stilizare cu clase Bootstrap

Odată cu dezvoltarea tehnologiei şi apariţia a tot mai multor dispozitive de tip

smartphone sau tabletă ce au ecrane cu rezoluţii mici, a apărut şi necesitatea ca o aplicaţie
web să aibă un design responsive. Acest lucru se referă la faptul că aranjarea elementelor în
pagină se modifică în funcţie de rezoluţia dispozitivului de pe care este vizualizată
aplicaţia. Bootstrap se adresează acestei probleme venind cu un sistem de împărţire a
paginii pe doisprezece coloane, iar cel ce realizează aplicaţia are posibilitatea de defini
numărul de coloane pe care un element să le ocupe în funcţie de rezoluţie. Ca şi exemplu, o
secţiune poate ocupa doar jumătate de pagină pe un monitor cu o rezoluţie mare, dar la
tranziţia pe un dispozitiv smartphone poate ocupa întreaga pagină. Acest lucru se
realizează foarte simplu doar prin ataşarea unor clase tagului HTML respectiv.

3.5. Apache Maven

Apache Maven este un tool ce a fost dezvoltat cu scopul de a facilita managementul

proiectelor software în Java în ceea ce priveşte dependinţele cu alte module sau biblioteci.

În cadrul oricărui proiect Maven va exista un fişier de configurare în format XML

ce prin convenţie poartă denumirea de POM(Project Object Model). La construirea
proiectului, Maven va citi acest fişier de unde va extrage informaţiile necesare pentru
configurarea proiectului.

Principala problemă rezolvată de Maven este aceea a dependinţelor unui proiect.

În general, proiectele complexe Java depind de multe JAR-uri externe ce sunt stocate local
şi din această cauză pot apărea inconvenienţe la portarea pe alte maşini. Maven introduce
un nou standard, ci anume acela de a include aceste dependinţe în cadrul fişierului
pom.xml. În acest fel, când programatorul îşi va defini o anumită dependinţă, Maven va
accesa repository-ul central şi va descarca local toate JAR-urile necesare.

24
 Fig x.x Exemplu de declarare a unei dependinţe Maven

O altă funcţionalitate importantă oferită de Maven este aceea de a genera automat o

structură de directoare specifică unui anumit tip de proiect. La crearea unui proiect Maven,
programatorul poate selecta dintr-o listă de arhetipuri cum ar fi quickstart, site, web-app şi
în funcţie de arhetipul selectat se va crea o structura de foldere corespunzatoare.

Fig x.x Lista arhetipurilor implicite oferite de Maven

În cadrul acestui proiect s-a utilizat Maven pentru adăugarea modulelor necesare
frameworkului Spring(Spring Boot, Spring Data Jpa, Spring Security) şi a altor biblioteci
externe precum PDFBox şi Apache Lucene. Referitor la modulele Spring, odată declarată
versiunea de framework folosită în fişierul de configurare, Maven se va asigura ca şi restul
modulelor vor fi compatibile, eliminând riscul anumitor incompatibilităţi.

3.6.Hibernate

Deoarece mediul de dezvoltare folosit în cadrul aplicaţiei este Java, adică un limbaj
de programare strict orientat pe obiect, iar baza de date folosită este una relaţională este
necesară utilizarea unei tehnologii care să realizeze maparea entităţilor reprezentate sub
formă de obiect şi a celor sub formă de tabelă. Tehnologia prin intermediul căreia se
realizează acest lucru poartă denumirea de Hibernate.

Hibernate este un framework ORM folosit pentru mediile de dezvoltare Java.

Termenul de ORM vine din limba engleză şi înseamnă Object/Relational Mapping.

Este o tehnică prin care datele reprezentate într-o formă orientată pe obiect sunt mapate cu
datele reprezentate într-o bază de date relaţională şi viceversa.

25
 Necesitatea utilizării unui ORM provine din faptul că între datele reprezentate sub
formă de clase Java şi cele dintr-o bază de date relaţională apar incompatibilităţi în ceea ce
priveşte tipurile de date şi mai ales relaţiile între entităţi. În cadrul programării orientate pe
obiecte, o relaţie între entităţi poate fi bidirecţională, în timp ce la bazele de date, relaţiile
între tabele sunt definite prin intermediul cheilor străine. Un tabel copil va păstra o coloană
de tip cheie străină în care va face referinţă la cheia primară a tabelului părinte, dar în
tabelul părinte nu se regăseşte nicio referinţă la tabelul copil, deci din acest punct de vedere
relaţia este unidirecţională.

Pentru a putea realiza o legătură între cele două modalităţi de reprezentare a datelor,
Java a introdus un standard care poartă numele de JPA, iar Hibernate este un framework ce
implementează acest standard.

Hibernate acţionează practic ca şi un intermediar între aplicaţia Java şi baza de

date. Aplicaţia Java va folosi API-ul pus la dispoziţie de Hibernate pentru a efctua diverse
operaţii specifice SQL(creare/actualizare/ştergere tabele, adăugare/ ştergere date,
interogări).

3.7. MySQL

Pentru a putea stoca informaţia într-o bază de date şi a putea interacţiona cu aceasta
este necesară utilizarea unui sistem de gestiune a bazelor de date.

MySQL este un sistem de gestiune a bazelor de date(SGBD) folosit la construcţia,

definirea şi manipularea bazelor de date relaţionale.

MySQL este unul dintre cele mai populare SGBD-uri deoarece este open-source,
oferă API-uri pentru o varietate mare de limbaje de programare(PHP, Java, C#, C++, C,
Ruby, Python) , funcţionează pe o multitudine de platforme.

3.8. JUnit

În dezvoltarea oricărui proiect, etapa de testare este cea prin care se asigură
calitatea produsului livrat, de aceea aceasta nu trebuie neglijată. Metodele de testare
manuală permit într-adevăr detecţia erorilor de funcţionare într-un procent destul de mare,
însă întotdeauna este recomandat să se realizeze şi o testare automată.

JUnit este un framework de testare folosit pentru limbajul Java. Este utilizat la
scrierea testelor unitare, adică teste ce verifică funcţionalitatea corectă a unei componente
de sine stătătoare(clasă sau metodă).

26
 Se bazează pe folosirea de adnotări printre care cea de bază este @Test care se trece
înaintea semnăturii unei metode pentru a semnaliza că acea metodă va fi rulată ca şi test.
Procedeul este unul simplu, pentru a testa o anumită metodă se vor defini nişte date de
intrare şi outputul care este aşteptat în urma introducerii acelor date. Dacă outputul metodei
coincide cu cel aşteptat, atunci testul a rulat cu success, altfel este semnalată o eroare în
logica metodei.

4. Detalii despre implementarea aplicaţiei

4.1 Motivarea alegerii tehnologiilor

Pentru alegerea tehnologiilor s-au avut în vedere mai multe aspecte. S-a urmărit în
primul rând să se folosească tehnologii de actualitate, cât mai utilizate în companiile ce
dezvoltă produse software. În al doilea rând, au fost alese tehnologii open-source ce au o
comunitate largă de programatori.

S-a ales Java ca limbajul principal utilizat pentru partea de server din următoarele
considerente:

- este un limbaj strict orientat pe obiect și astfel se poate beneficia la maxim de

utilizarea unor tehnici OOP precum încapsularea, moștenirea, abstractizarea și
polimorfismul
- este independent de platformă, un cod Java odată compilat se va comporta la fel pe
orice sistem de operare
- are un mecanism propriu de management al memoriei, numit garbage collector,
astfel programatorul nu mai trebuie să își pună problema alocării și dezalocării
memoriei, deoarece ciclul de viață al obiectelor este monitorizat intern
- dispune de cele mai bune mecanisme de securitate
- dispune de o multitudine de biblioteci și API-uri open-source(pentru acest proiect s-
au folosit PDFBox și Apache Lucene)

Ca şi framework pentru partea de server s-a ales Spring deoarece este cel mai
cunoscut framework Java folosit la dezvoltarea aplicaţiilor web, este open-source, are o
documentaţie foarte bună şi complexă ce cuprinde explicaţii însoţite de exemple de cod,
fiind împărţit în aproximativ 20 de module, fiecare modul adresându-se unei funcţionalităţi
distincte. De asemenea, în cadrul Spring este folosit un mecanism de management al
dependenţelor între obiecte care conduce la un cod mai uşor de reutilizat şi de testat.

Frameworkul ales pentru partea de client este Angular JS, deoarece este open-
source, oferă sincronizare automată între datele din model şi cele din view(data-binding) şi
dispune de un mecanism de management asemanător Spring ce gestionează ciclul de viaţă

27
al obiectelor.De asemenea, aplicaţiile Angular fiind de tip SPA asigură un timp de răspuns
mai rapid pentru cererile HTTP.

Ca şi framework folosit pentru stilizarea aplicaţiei s-a ales Bootstrap din principalul
motiv că prin utilizarea claselor de CSS predefinite în cadrul acestui framework se
micşorează timpul necesar realizării unei interfeţe grafice care să aibă design responsive.
De asemenea, frameworkul este open-source, uşor de integrat în proiect şi are o
documentaţie foarte bună.

4.2. Arhitectura aplicaţiei

Când vorbim despre arhitectura unei aplicaţii ne referim practic la un model

abstractizat prin care sunt reprezentate componentele de bază ale aplicaţiei şi modul în care
acestea interacţionează.

Alegerea unui anumit tip de arhitectură depinde foarte mult de complexitatea

problemei ce trebuie rezolvată. O arhitectură prost aleasă poate duce la scrierea de cod
redundant, greu de înţeles şi ineficient sau la probleme în ceea ce priveşte perfomanţa. O
aplicaţie de scară largă necesită un grad mare de scalabilitate, deoarece pe parcurs mai pot
fi adăugate noi funcţionalităţi sau aplicaţia poate fi integrată în cadrul altor aplicaţii. Deci,
problema alegerii arhitecturii este una esenţială încă din fazele incipiente ale dezvoltării.

De-a lungul timpului, arhitecţii software au venit cu diverse modele de arhitecturi

dintre care, printre cele mai populare se află cele care presupun împărţirea aplicaţiei pe mai
multe niveluri(layers). Fiecare nivel va avea o funcţionalitate bine definită şi se va folosi
de servicii definite de nivelul inferior. Din punct de vedere al numărului de niveluri, avem
următoarele tipuri de aplicaţii:

 pe un singur nivel sau monolitice – avem un singur nivel responsabil pentru

interfaţa grafică, logica din spatele aplicaţiei şi eventual manipularea de date
 pe mai multe niveluri – în funcţie de cerinţe vom avea două sau mai multe
niveluri

Această tehnică de împărţire a aplicaţiei pe mai multe niveluri este folosită la

dezvoltarea produselor software deoarece îi permite unui programator să înteleagă cum
lucrează un singur nivel fară a cunoaste în mod detaliat cum funcţionează cele din spate.
Acest lucru este esenţial în cadrul proiectelor la care lucrează mai multe persoane, fiecare
cu responsabilităţi diferite. Cu toate acestea, divizarea pe mai multe niveluri nu se
dovedeşte întotdeauna cea mai buna soluţie, iar în situaţiile în care avem prea multe
niveluri complexitatea aplicaţiei va creşte şi pot apărea de asemenea probleme de
performanţă.

În cazul aplicaţiilor web este întotdeauna necesară existenţa a cel puţin două
niveluri.Cel mai cunoscut exemplu este reprezentat chiar de modelul client-server, în care

28
pe partea de client avem interfaţa cu utilizatorul şi pe partea de server logica aplicaţiei şi
procesarea datelor. Este important de notat faptul că în terminologia din limba engleză
atunci când se face referire la arhitecturi multi-nivel se face adesea confuzia între termenii
layer şi tier. O arhitectură multi tier implică faptul că nivelurile rulează pe maşini diferite,
dar în cazul multi layer nivelurile se pot afla şi pe aceeaşi maşină.

În cadrul acestei aplicaţii, am ales să folosesc o arhitectură pe trei niveluri, ci anume:

 nivelul client
 nivelul server
 nivelul de date

Fig x.x Reprezentarea arhitecturii pe trei niveluri

Nivelul client sau prezentare este cel cu care utilizatorul poate interacţiona în mod
direct prin intermediul interfeţei grafice afişate în browser. Este responsabil cu afişarea
datelor, monitorizarea acţiunilor utilizatorului, trimiterea de cereri HTTP către server şi
afişarea de răspunsuri. După cum se poate observa şi în schema de mai sus, nivelul client
comunică în mod direct cu nivelul server printr-un API, însă nu are acces la nivelul de date.

Aplicaţia de la nivelul client este un Single Page Application(SPA) bazată pe

tehnologia Angular JS.

La nivelul server rezidă logica aplicaţiei. Principalele operaţii care au loc aici sunt:
procesarea cererilor HTTP venite de la client, realizarea conexiunii cu baza de date şi
efectuări de operaţii de tip CRUD(creare, citire, modificare şi stergere) asupra
înregistrărilor din tabele. Acest nivel joacă rol de intermediar între client şi date şi este
implementat folosind tehnologia Spring.

29
 La nivelul de date se află o bază de date relaţională implementată folosind sistemul
de gestiune a bazelor de date MySQL. Acest nivel nu este în niciun fel conştient de
existenţa nivelurilor superioare şi poate exista independent.

În cazul aplicaţiei dezvoltate, cele trei niveluri rulează pe aceeaşi maşină, însă
acestea pot funcţiona la fel şi în cazul mutării lor pe maşini diferite.

4.3.Considerente legate de proiectarea bazei de date

Atunci când un proiect necesită stocarea şi apoi regăsirea informaţiei, cea mai
indicată metodă de a realiza acest lucru este prin utilizarea unei baze de date. Astfel, există
două mari tipuri de baze de date şi fiecare este folosit în funcţie de cerinţele aplicaţiei:

 relaţionale – informaţia este modelată sub formă de tabele, bazându-se pe concepte

de algebră relaţională
 non-relaţionale – este un concept mai nou, aducând avantaje în ceea ce priveşte
memorarea unui volum foarte mare de informaţii, dar dezavantajul principal este că
acest tip de baze de date nu a fost standardizat

Întrucât proiectul are ca scop principal managementul articolelor ştiinţifice prin

stocarea unor informaţii specifice despre acestea sau realizarea de diverse interogări pe
diferite criterii este necesar ca aplicaţia să aibă în spate o bază de date. Ca şi metodă de
implementare s-a ales proiectarea unei baze de date relaţionale, deoarece acestea au fost
standardizate prin intermediul limbajului SQL(Structured Query Language).

Pentru a proiecta o bază de date ce modelează informaţiile într-un mod coerent

trebuie să se cunoască foarte bine domeniul, mai precis care sunt entităţile cu care se
lucrează, care sunt relaţiile între ele şi ce proprietăţi semnificative pentru fiecare entitate
trebuie să fie memorate.În cazul acestei aplicaţii, principalele informaţii ce vor fi modelate
şi memorate sunt cele ce ţin de utilizatori şi articole ştiinţifice.

Modelarea informaţiilor legate de utilizatori

Întrucât aplicaţia este bazată pe autentificare, este necesară memorarea

informaţiilor despre utilizatorii ce îşi creează cont. S-au identificat o serie de date esenţiale
ce trebuie cunoscute despre fiecare utilizator în parte, ci anume: nume, prenume, numele
de utilitzator, e-mailul, parola, poziţia ocupată în cadrul facultăţii şi tipul contului.
Aplicaţia permite crearea a două tipuri de conturi, ci anume cel de USER şi cel de ADMIN.
Ca urmare, s-a ales ca structura tabelului în care sunt stocaţi utilizatorii să fie cea
prezentată în imaginea de mai jos:

30
 Fig x.x Tabelul în care sunt stocaţi utilizatorii

Ca şi constrângeri definite în acest tabel, se pot identifica următoarele:

 constrângere de tip cheie primară pentru câmpul id

 constrângere de tip UNIQUE pentru câmpurile username şi email
 constrângere de tip NOT NULL pentru toate câmpurile
 constrângere de tip CHECK pentru câmpul tip_cont, acesta poate lua doar valorile
USER şi ADMIN

Diferenţa dintre contul de tip USER şi cel ADMIN este că ADMIN-ul are
permisiuni extinse faţă de USER, fiind cel care se ocupă cu gestiunea conturilor de USER,
mai exact poate vizualiza informaţii despre toţi utilizatorii înregistraţi şi poate genera o
serie de rapoarte privind activitatea lor. Ca şi o alternativă a proiectării acestei constrângeri
s-ar fi putut opta pentru crearea unui tabel separat TIP_CONT în care să fie stocate toate
tipurile de cont disponibile cu un id asociat, iar în tabelul utilizatorilor să existe o cheie
străină care face referire, prin id, la tipul de cont din tabelul TIP_CONT. Această variantă
ar fi necesitat o operaţie de join între cele două tabele care ar fi crescut costul unei
interogări şi nu ar fi fost justificată de faptul că un utilizator poate avea doar un tip de cont.

Modelarea informaţiilor legate de articolele ştiinţifice

În cazul unui articol ştiinţific, utilizatorii aplicaţiei trebuie să aibă disponibile

următoarele informaţii: titlul articolului, autorii, un scurt rezumat al articolului(abstract),
cine a fost utilizatorul ce a încărcat articolul, data la care acesta a fost încărcat, de câte ori
articolul a fost descărcat, cuvinte cheie introduse de cel care încarcă articolul, indecşi ce
identifică în mod unic un articol, ci anume WOS(Web of Science) şi DOI(Digital Object
Identifier). De asemenea, la nivel de server, trebuie să se cunoască şi numele fişierului sub
care a fost încărcat articolul.

Aplicaţia permite încărcarea a patru tipuri de articole, despre care trebuie să fie
stocate informaţii specifice:
 articolul este o carte scrisă în totalitate de un autor sau un grup de autori: editura,
ISBN, ISSN, ediţia, anul publicării
 articolul este un capitol dintr-o carte ce aparţine mai multor autori: titlul cărţii,
numele tuturor autorilor, numele editorilor, numele capitolului, paginile la care
poate fi găsit articolul, ISBN, ISSN, editura, anul publicării

31
  articolul a fost prezentat în cadrul unei conferinţe: numele, locaţia şi data
conferinţei
 articolul a fost publicat într-un jurnal ştiinţific sau o revistă: nume jurnal/revistă,
număr jurnal/revistă, volum jurnal /revistă, paginile la care poate fi găsit articolul,
data apariţie jurnal/revistă

Cerinţele prezentate au fost modelate sub formă tabelară astfel:

Fig x.x
Se observă cum tabelul Articol are un câmp id_tip_articol, ce este o cheie străină ce
face legătura cu tabelul Tip_Articol. Tabelele Detalii_Carte_Capitol,
Detalii_Jurnal_Revistă, Detalii_Carte_Completă şi Detalii_Conferintă împart aceeaşi cheie
primară cu cea a tabelului Articol, marcând o relaţie de tipul one-to-one.

Pentru cuvintele cheie ataşate fiecărui articol a fost necesară crearea unui tabel Tag
cu câmpurile id şi denumire. Astfel, un articol poate avea mai multe tag-uri şi un tag se
poate regăsi la mai multe articole. Acest tip de relaţie se numeşte many-to-many şi se
rezolvă prin crearea unui tabel intermediar, articol_tag, ce va conţine o cheie primară
compusă din cheile primare ale tabelelor Articol şi Tag.

Fig x.x Reprezentarea relaţiei dintre Articol şi Tag

32
 De asemenea, este necesar ca pentru fiecare articol să se ştie ce utilizator l-a
încărcat. Acest lucru este rezolvat prin crearea unei relaţii de tipul one-to-many între
tabelele Articol şi User, astfel pentru fiecare articol există o constrângere de tipul cheie
străină prin care se face referire la id-ul utilizatorului ce a încărcat articolul.

Pentru coautorii unui articol vor exista două situaţii, dacă un coautor este sau nu
înregistrat pe platformă. Dacă are deja cont, relaţia de tipul many-to-many leagă tabelele
User şi Articol prin tabelul coautorUser_articol. Cea de a doua situaţie, în care un coautor
nu are cont este rezolvată prin crearea unui nou tabel Autor_fara_cont, iar între acest tabel
şi Articol se face legătura de tip many-to-many prin tabelul Articol_coautorFaraCont.

Fig x.x Relaţii prin care se determină coautorii unui articol

Aplicaţia conţine şi o funcţionalitate prin care un utilizator poate adăuga la favorite

diverse articole. Acest lucru se realizează prin crearea unei relaţii de tip many-to-many
între tabelele User şi Articol, legătura făcându-se prin intermediul tabelului
User_articolFavorit.

Fig x.x

Maparea obiectelor Java cu tabelele din baza de date

Întrucât limbajul de programare în care a fost implementată aplicaţia este Java,

adică un limbaj strict orientat obiect, a fost necesară maparea între obiectele Java şi
tabelele din baza de date. Acest lucru s-a realizat prin intermediul frameworkului
Hibernate.

Primul pas constă în scrierea claselor Java şi determinarea relaţiilor dintre acestea.
Hibernate funcţionează pe baza unor adnotări specifice, un fel de metadate, care se

33
ataşează unei clase, unui atribut sau unei metode. După ce au fost scrise clasele cu
adnotări, la rularea programului codul va genera tabelele respective, inclusiv relaţiile dintre
acestea în baza de date relaţională, ce a fost definită în fişierul de configurare. Singura
condiţie de funcţionare este ca baza de date să existe, dar ea nu va conţine niciun tabel,
acestea vor fi generate prin intermediul codului Java.

În figura de mai jos se află o reprezentare UML a claselor prin intermediul cărora s-
au generat tabelele. Pentru simplificarea schemei s-au omis unele atribute, care se regăsesc
însă în formă completă în reprezentările schematice ale bazei de date(fig x.x , fig x.x, fig
x.x). Prin linie dreaptă sunt marcate relaţiile de asociere între clase.

Fig x.x Clasele Java ce corespund tabelelor din baza de date.

Adnotările folosite
Hibernate pune la dispoziţie o gamă largă de adnotări, însă cele care au fost folosite
în acest proiect sunt următoarele:
 @Entity – marchează faptul că o clasă va reprezenta o tabelă de sine stătătoare în
baza de date şi se va pune întodeauna înainte de declarea unei clase
 @Column – marchează faptul că un atribut va reprezenta o coloană într-o tabelă şi
se poate parametriza în funcţie de necesităţi(se poate specifica dacă valorile din
acea coloană pot fi sau nu nule, dacă trebuie să fie unice)
 @Id –este o adnotare ce marchează faptul că unul din atributele clasei va avea rol
de cheie primară
 @OneToOne – este folosită pentru a marca o relaţie de tipul one-to-one
 @OneToMany – este folosită pentru a marca o relaţie de tipul one-to-many
 @ManyToMany –este folosită pentru a marca o relaţie de tipul many-to-many

34
 Pentru rezolvarea relaţiilor one-to-one, one-to-many, many-to-many Hibernate va
interpreta adnotările corespunzătoare care sunt ataşate unor atribute din clasele Java şi va
crea constrângeri de tip cheie străină sau va genera tabele de legătură. Pentru a înţelege mai
bine cum funcţionează aceste adnotări, în continuare se vor oferi nişte exemple pentru
fiecare tip de relaţie în parte.

a. Relaţia de tip one-to-one

Pentru exemplificare se consideră relaţia one-to-

one dintre Articol şi Carte_Capitol. În Java, aceasta a fost
implementată ca fiind o relaţie unidirecţională, adică
numai în clasa CarteCapitol va exista o referinţă către
clasa Articol. Astfel, clasa CarteCapitol va conţine un atribut de tipul Articol, marcat cu
adnotarile @OneToOne şi @MapsId(prin care se specifică faptul că cele două tabele au
aceeşi cheie primară).

b. Relaţia de tip one-to-many

Se va exemplifica relaţia one-to-many dintre Articol şi User(un utilizator poate

încărca mai multe articole, un articol aparţine unui singur utilizator). Aceasta este o relaţie
bidirecţională, întrucât ambele clase conţin referinţe una către alta.

În clasa User avem următoarea bucată de cod:

În clasa Articol:

Clasa User joacă aici rolul de părinte al relaţiei. Prin intermediul atributului fetch
setat cu valoarea FetchType.EAGER , atunci când datele despre un User vor fi solicitate se
vor primi şi datele despre toate articolele încărcate de acel utilizator. Prin mappedBy se
specifică numele atributului din clasa care completează relaţia. Atributul orphanRemoval
setat cu valoarea true specifică faptul că atunci când un utilizator va fi şters vor fi şterse şi
toate înregistrările din tabelul Articol care au ca şi cheie străină id-ul utilizatorului.

c. Relaţia de tip many-to-many

Se va exemplifica relaţia many-to-many dintre User şi Articol prin care un utilizator

poate adăuga la favorite diverse articole. Aceasta este tot o relaţie bidirecţională.

35
 Bucata de cod de mai sus se regăseşte în clasa User. Se observă ca relaţia many-to-
many este cea mai complicată de până acum, deoarece necesită foarte multe adnotări. Prin
intermediul adnotării @JoinTable se specifică numele tabelului de legătura, iar prin
adnotarea @JoinColumn se vor menţiona coloanele corespunzătoare celor două tabele care
vor forma cheia primară compusă a tabelului de legătura. În acest caz, cheia primară este
compusă din id-ul utilizatorului şi id-ul articolului.

3.Accesul la baza de date

Modulul prin care se face legătura între partea de server şi baza de date este Spring
Data JPA. Acesta asigură posibilitatea de introducere a noi înregistrări în tabele şi de
definire a unor interogări. Modalitatea prin care se realizează acest lucru este prin definirea
unor interfeţe Java aferente fiecărei clase ce a fost adnotată cu @Entity.

Aceste interfeţe trebuie să extindă interfaţa JpaRepository, parametrizată cu numele

clasei respective şi tipul de date al id-ului. În exemplul de mai sus, prin extinderea
interfeţei JpaRepository se asigură accesul la nişte metode prin care se pot realiza operaţii
de: salvare a unei înregistrări în baza de date, returnare a tuturor elementelor de tipul
CarteCapitol, returnare a unei înregistări pe baza de id, ştergere a unei înregistrări pe baza
de id. De asemenea, există posibilitatea de a se defini şi alte tipuri de interogări, marcate
prin adnotarea @Query, folosind-use limbajul JPQL(Java Persistence Query Language),
foarte asemănator cu SQL.

În exemplul de mai sus este definită o interogare prin care se obţine id-ul maxim
din tabelul Tag.

În continuare, pentru a putea accesa datele primite de aceste Repository-uri, există

un nivel superior, cel de servicii, în care se va injecta un obiect de tipul
CarteCapitolRepository (acest lucru se face prin folosirea adnotării @Autowired) prin
intermediul cărora se vor accesa metodele specificate mai sus.

36
 În exemplul de mai sus este accesată metoda care returnează un obiect de tipul
CarteCapitol, făcând căutare dupa id.

4.Asigurarea securităţii bazei de date

În momentul în care se lucrează cu o bază de date devine esenţială adoptarea unor

politici pentru menţinerea securitătăţii. În acest subcapitol se va discuta despre securitatea
într-un mediu MySql, însă multe dintre concepte sunt valabile şi pentru alte medii, cum ar
fi Oracle.

Indiferent de sistemul de gestiune folosit, pentru ca o persoană să aibă acces la baza

de date, aceasta trebuie să deţină un cont de utilizator. Fiecărui cont îi sunt asociate apoi o
serie de permisiuni, prin care se precizează ce acţiuni asupra bazei de date poate efectua
utilizatorul respectiv. Principalele tipuri de permisiuni disponibile sunt următoarele:

 CREATE - unui utilizator i se acordă dreptul de a crea noi tabele

 DROP - unui utilizator i se acordă dreptul de a şterge tabele
 SELECT - unui utilizator i se permite să facă interogări asupra bazei de date
 DELETE – unui utilizator i se acordă dreptul de a şterge înregistrări
 GRANT OPTION – un utilizator va avea dreptul să acorde sau să şteargă din
permisiunile altor utilizatori

La crearea unui nou cont de utilizator se vor preciza şi permisiunile acestuia. Pentru
menţinerea confidenţialităţii şi integrităţii datelor este recomandat ca utilizatorilor să le fie
restricţionat accesul şi să li se ofere permisiuni doar pentru citire. De asemenea, un alt
lucru ce trebuie luat în considerare este faptul că parola unui utilizator trebuie să fie dificil
de spart, deoarece o parolă slabă poate reprezenta o vulnerabilitate considerabilă.

La nivel intern, mai pot apărea vulnerabilităţi din cauza utilizării unor setări
implicite ale sistemului de gestiune a bazei de date. În acest caz, se recomandă consultarea
documentaţiei, deoarece aceste setări pot să difere în funcţie de versiunea de MySql
utilizată. De asemenea, portul implicit pe care rulează MySql, adică 3306, ar trebui să fie
modificat pentru a putea preveni o potenţială încercare de conexiune la acest port din afară.

37
 La nivel de aplicaţie web, unul dintre cele mai frecvente atacuri asupra unei baze de
date poartă denumirea de SQL Injection. Indiferent de mediul de baze de date folosit,
există riscul ca un cod nu foarte bine scris să îi ofere unui atacator posibilitatea de a
executa un astfel de atac.

Dacă aplicaţia conţine formulare prin intemediul cărora se generează interogări

asupra bazei de date, un atac de tip SQL Injection poate fi realizat prin introducerea unei
ghilimele într-o casetă de text, după care se va adăuga o altă interogare ce va conţine o
clauză WHERE în care condiţia va fi evaluată întotdeauna ca fiind adevărată. În acest fel,
atacatorul poate să obţină informaţii la care în mod normal nu ar fi avut acces(de exemplu
poate selecta toate parolele şi numele de utilizator dintr-o tablelă în care sunt stocaţi
utilizatorii). În acest caz, aplicaţiile cele mai vulnerabile sunt cele unde interogările se fac
prin concatenare de şiruri de caractere.

Ca şi modalităţi de prevenire ale acestui atac se poate opta pentru validarea textului
introdus de utilizator pentru a verifica dacă acesta conţine sau nu ghilimele şi utilizarea de
cereri parametrizate.

În cazul acestei aplicaţii, prevenirea se face prin utilizarea cererilor parametrizate,

adică legarea variabilelor, în locul concatenării intrucţiunilor SQL. Astfel, dacă un atacator
introduce o clauză SQL maliţioasă, la execuţia interogării aceasta va fi interpretată ca şi un
parametru după care se face o căutare, iar rezultatul cererii va fi nul.

Pentru o asigurare şi mai puternică a securităţii se pot implementa şi validări asupra

câmpurilor introduse de utilizator. Astfel, dacă vor fi trimise cuvinte spefifice limbajului
SQL cum ar fi SELECT, DELETE sau semne de punctuaţie precum ghilimele sau punct şi
virgulă, i se poate semnala utilizatorului că textul introdus nu este valid.

Ca şi o a treia opţiune pentru protecţia asupra atacurilor de tip SQL Injection,

MySql Enterprise Edition vine cu un modul de securitate care deţine un firewall destinat
detectării şi blocării acestor atacuri. Ca şi dezavantaj al acestei soluţii s-ar putea menţiona
costul ridicat, pe când primele două soluţii sunt implementate doar la nivel de cod, nu
necesită niciun cost suplimentar.

5.Optimizarea căutărilor în baza de date

În condiţiile în care asupra unei baze de date se realizează un număr mare de

operaţii de inserare şi regăsire a datelor, un parametru ce prezintă interes este timpul de
acces, care se doreşte a fi cât mai mic. În funcţie de modul de organizare a datelor în
tabele(dacă tabelele sunt ordonate după un anumit câmp sau nu) se modifică şi timpul de
acces.

O tabelă va fi în general ordonată după câmpul cheie primară. Acest lucru nu este
eficient în cazul în care se fac multe interogări după alte câmpuri, deoarece datele nefiind

38
într-o ordine logică, căutarea se va face liniar, înregistrare cu înregistrare, timpul de acces
devenind astfel foarte mare.

Ca şi soluţie la această problemă se poate considera crearea de fişiere secvenţiale

indexate prin care se va realiza o ordonare logică a înregistrărilor unei tabele, în funcţie de
alt câmp, diferit de cheia primară. Astfel, asupra indexului, se vor putea aplica algoritmi de
căutare binară, ce vor reduce semnificativ timpul de acces.

În funcţie de căutările care se vor face, în cazul acestei aplicaţii se pot defini indecşi
pentru diverse câmpuri cum ar fi titlul unui articol, numele autorilor. Cu toate acestea,
definirea indecşilor va fi necesară doar în cazul în care baza de date a atins un număr foarte
mare de înregistrări, altfel ar ocupa spaţiul pe disc într-un mod ineficient.

4. Detalii despre implementarea aplicaţiei

4.1 Motivarea alegerii tehnologiilor

Pentru alegerea tehnologiilor s-au avut în vedere mai multe aspecte. S-a urmărit în
primul rând să se folosească tehnologii de actualitate, cât mai utilizate în companiile ce
dezvoltă produse software. În al doilea rând, au fost alese tehnologii open-source ce au o
comunitate largă de programatori.

S-a ales Java ca limbajul principal utilizat pentru partea de server din următoarele
considerente:

- este un limbaj strict orientat pe obiect și astfel se poate beneficia la maxim de

utilizarea unor tehnici OOP precum încapsularea, moștenirea, abstractizarea și
polimorfismul
- este independent de platformă, un cod Java odată compilat se va comporta la fel pe
orice sistem de operare
- are un mecanism propriu de management al memoriei, numit garbage collector,
astfel programatorul nu mai trebuie să își pună problema alocării și dezalocării
memoriei, deoarece ciclul de viață al obiectelor este monitorizat intern
- dispune de cele mai bune mecanisme de securitate
- dispune de o multitudine de biblioteci și API-uri open-source(pentru acest proiect s-
au folosit PDFBox și Apache Lucene)

Ca şi framework pentru partea de server s-a ales Spring deoarece este cel mai
cunoscut framework Java folosit la dezvoltarea aplicaţiilor web, este open-source, are o
documentaţie foarte bună şi complexă ce cuprinde explicaţii însoţite de exemple de cod,
fiind împărţit în aproximativ 20 de module, fiecare modul adresându-se unei funcţionalităţi

39
distincte. De asemenea, în cadrul Spring este folosit un mecanism de management al
dependenţelor între obiecte care conduce la un cod mai uşor de reutilizat şi de testat.

Frameworkul ales pentru partea de client este Angular JS, deoarece este open-
source, oferă sincronizare automată între datele din model şi cele din view(data-binding) şi
dispune de un mecanism de management asemanător Spring ce gestionează ciclul de viaţă
al obiectelor.De asemenea, aplicaţiile Angular fiind de tip SPA asigură un timp de răspuns
mai rapid pentru cererile HTTP.

Ca şi framework folosit pentru stilizarea aplicaţiei s-a ales Bootstrap din principalul
motiv că prin utilizarea claselor de CSS predefinite în cadrul acestui framework se
micşorează timpul necesar realizării unei interfeţe grafice care să aibă design responsive.
De asemenea, frameworkul este open-source, uşor de integrat în proiect şi are o
documentaţie foarte bună.

4.2. Arhitectura aplicaţiei

Când vorbim despre arhitectura unei aplicaţii ne referim practic la un model

abstractizat prin care sunt reprezentate componentele de bază ale aplicaţiei şi modul în care
acestea interacţionează.

Alegerea unui anumit tip de arhitectură depinde foarte mult de complexitatea

problemei ce trebuie rezolvată. O arhitectură prost aleasă poate duce la scrierea de cod
redundant, greu de înţeles şi ineficient sau la probleme în ceea ce priveşte perfomanţa. O
aplicaţie de scară largă necesită un grad mare de scalabilitate, deoarece pe parcurs mai pot
fi adăugate noi funcţionalităţi sau aplicaţia poate fi integrată în cadrul altor aplicaţii. Deci,
problema alegerii arhitecturii este una esenţială încă din fazele incipiente ale dezvoltării.

De-a lungul timpului, arhitecţii software au venit cu diverse modele de arhitecturi

dintre care, printre cele mai populare se află cele care presupun împărţirea aplicaţiei pe mai
multe niveluri(layers). Fiecare nivel va avea o funcţionalitate bine definită şi se va folosi
de servicii definite de nivelul inferior. Din punct de vedere al numărului de niveluri, avem
următoarele tipuri de aplicaţii:

 pe un singur nivel sau monolitice – avem un singur nivel responsabil pentru

interfaţa grafică, logica din spatele aplicaţiei şi eventual manipularea de date
 pe mai multe niveluri – în funcţie de cerinţe vom avea două sau mai multe niveluri

Această tehnică de împărţire a aplicaţiei pe mai multe niveluri este folosită la

dezvoltarea produselor software deoarece îi permite unui programator să înteleagă cum
lucrează un singur nivel fară a cunoaste în mod detaliat cum funcţionează cele din spate.
Acest lucru este esenţial în cadrul proiectelor la care lucrează mai multe persoane, fiecare
cu responsabilităţi diferite. Cu toate acestea, divizarea pe mai multe niveluri nu se

40
dovedeşte întotdeauna cea mai buna soluţie, iar în situaţiile în care avem prea multe
niveluri complexitatea aplicaţiei va creşte şi pot apărea de asemenea probleme de
performanţă.

În cazul aplicaţiilor web este întotdeauna necesară existenţa a cel puţin două
niveluri.Cel mai cunoscut exemplu este reprezentat chiar de modelul client-server, în care
pe partea de client avem interfaţa cu utilizatorul şi pe partea de server logica aplicaţiei şi
procesarea datelor. Este important de notat faptul că în terminologia din limba engleză
atunci când se face referire la arhitecturi multi-nivel se face adesea confuzia între termenii
layer şi tier. O arhitectură multi tier implică faptul că nivelurile rulează pe maşini diferite,
dar în cazul multi layer nivelurile se pot afla şi pe aceeaşi maşină.

În cadrul acestei aplicaţii, am ales să folosesc o arhitectură pe trei niveluri, ci anume:

 nivelul client
 nivelul server
 nivelul de date

Fig x.x Reprezentarea arhitecturii pe trei niveluri

Nivelul client sau prezentare este cel cu care utilizatorul poate interacţiona în mod
direct prin intermediul interfeţei grafice afişate în browser. Este responsabil cu afişarea
datelor, monitorizarea acţiunilor utilizatorului, trimiterea de cereri HTTP către server şi
afişarea de răspunsuri. După cum se poate observa şi în schema de mai sus, nivelul client
comunică în mod direct cu nivelul server printr-un API, însă nu are acces la nivelul de date.

Aplicaţia de la nivelul client este un Single Page Application(SPA) bazată pe

tehnologia Angular JS.

41
 La nivelul server rezidă logica aplicaţiei. Principalele operaţii care au loc aici sunt:
procesarea cererilor HTTP venite de la client, realizarea conexiunii cu baza de date şi
efectuări de operaţii de tip CRUD(creare, citire, modificare şi stergere) asupra
înregistrărilor din tabele. Acest nivel joacă rol de intermediar între client şi date şi este
implementat folosind tehnologia Spring.

La nivelul de date se află o bază de date relaţională implementată folosind sistemul

de gestiune a bazelor de date MySQL. Acest nivel nu este în niciun fel conştient de
existenţa nivelurilor superioare şi poate exista independent.

În cazul aplicaţiei dezvoltate, cele trei niveluri rulează pe aceeaşi maşină, însă
acestea pot funcţiona la fel şi în cazul mutării lor pe maşini diferite.

Nivelul server

1.Prezentarea arhitecturii la nivel de server

Nivelul server este nivelul de mijloc al aplicației, care realizează legătura între baza
de date și interfața cu utilizatorul. Tot aici este implementată logica de control care stă la
baza tuturor funcționalităților aplicației iar principalul său rol este de a intercepta toate
cererile venite din partea clientului şi de a genera un răspuns corespunzator.

Ca şi principale funcţionalităţi implementate la nivel de server se va prezenta

modul în care sunt tratate cererile HTTP venite de la client, metoda de încărcare a unui
articol şi procesul de autentificare.

Acest nivel a fost implementat bazându-se pe tehnologia Spring framework și

urmărește principiile REST de dezvoltare a unei aplicații web. În implementare s-a urmărit
un șablon standard recomandat pentru aplicațiile Java Enterprise și anume o împărțire
ierarhică a claselor, pe trei niveluri:
• Un nivel de interfeţe Java prin care se realizează comunicarea cu baza de date
• Un nivel intermediar care oferă o implementare pentru metodele definite la nivelul
interfeţelor
• Un nivel superior prin care se vor intercepta cererile HTTP trimise de client

42
 Avantajele utilizării acestui şablon de implementare constau în faptul că aplicaţiei i
se oferă scalabilitate, funcţionalităţile vor fi mult mai bine delimitate şi de asemenea codul
va fi mult mai uşor de modificat şi reutilizat.

Pe lângă cele trei niveluri principale ce comunică între ele, ar mai trebui menționat
și nivelul cel mai de jos, al claselor prin care sunt modelate entitățile principale ale
aplicației, marcate cu adnotarea @Entity. Acestea au fost prezentate în capitolul anterior în
care s-a discutat despre baza de date.

Nivelul inferior este cel care asigură legătura cu baza de date și este alcătuit din
interfețe ce extind interfața JpaRepository, parametrizate cu numele clasei, ce este mapată
cu un tabel în baza de date și tipul de date al cheii primare. Fiecărei clase îi va corespunde
o interfață marcată cu adnotarea @Repository.

Fiecare interfaţă de tip @Repository va avea asociată o clasă al cărui rol este de a
oferi o implementare pentru metodele interfeţei şi de a verifica validitatea datelor primite
pentru a le trimite mai departe către ultimul nivel. Clasele de acest tip sunt marcate prin
adnotarea @Service.

Pentru cele două niveluri, @Repository şi @Service a fost ilustrat un exemplu de

implementare în capitolul despre baza de date, secţiunea Accesul la baza de date.

Ultimul nivel este cel care interceptează cererile HTTP venite de la client și
generează un răspuns corespunzator, folosind instanțe ale claselor de tip @Service. Aceste
clase sunt marcate cu adnotarea @Controller.

Întrucât clasele de tip @Controller sunt cele care asigură comunicarea cu clientul,
urmând principiile REST, acestea trebuie să fie identificate în mod unic prin intermediul
unui URL. Fiecare resursă, adică tabelă din baza de date va avea asociată câte o clasă
@Controller şi prin convenţie URL-ul prin care este identificată această clasă va purta
denumirea resursei. Există două modalităţi de definire a acestui URL:

 la nivel de clasă
 la nivel de metodă

În ambele cazuri, definirea URL-ului se face folosind adnotarea

@RequestMapping. În cazul în care URL-ul este definit pe clasă acesta se va comporta ca
o rădăcină, deci pentru accesarea tuturor metodelor va trebui să se precizeze mai întâi
URL-ul de bază.

Metodele ce se definesc în clasele de tip @Controller vor fi metode de tip

HTTP(GET, POST, DELETE). Ca şi exemplificare de implementare se va folosi clasa
@Controller asociată resurselor de tip utilizator.

43
 Astfel, pentru clasa UserController s-a definit calea rădăcină “ /user”.

Pentru a exemplifica modul în care interacţionează cele trei niveluri se va oferi un

exemplu pentru resursa de tip utilizator, mai exact metoda prin care se vor returna toţi
utilizatorii înregistraţi în baza de date.

În clasa de tip controller va exista un atribut de tipul AppUserService, unde

AppUserService este o clasa de tip @Service.

Adnotarea @Autowired este specifică frameworkului Spring şi prin utilizarea ei pe

un câmp al unei clase ne vom asigura că ciclul de viaţă al obiectului respectiv va fi
gestionat automat. În mod normal, un atribut al unei clase trebuie să primească o valoare
atunci când este apelat constructorul clasei respective, însă în acest caz clasa nu conţine
niciun constructor cu parametri, iar obiectul de tip appUserService poate fi utilizat direct,
fără a fi instanţiat în mod explicit. Acest exemplu ilustrează mecanismul de management al
dependenţelor între obiecte oferit de Spring.

Metoda de tip GET care returnează toate resursele de tip utilizator:

Se observă cum pentru metoda getAllUsers(), adnotarea @RequestMapping este

parametrizată şi cu atributul method prin care se specifică tipul metodei HTTP folosite, în
acest caz fiind o metodă de tip GET. Calea asociată acestei metode va fi /user/all. Metoda
returnează un obiect de tipul ResponseEntity, care în cazul în care există utilizatori
înregistraţi va întoarce o listă cu aceştia şi va seta header-ul astfel încât răspunsul primit de
client va avea codul 200 OK. Dacă lista de utilizatori este vidă clientul va primi un răspuns
cu statusul 204 NO_CONTENT.

Clasa AppUserService va avea la rândul ei un câmp de tipul AppUserRepository, ce

este o interfaţă ce implementează interfaţa JpaRepository.

44
 Metoda getAllUsers() returnează o listă cu toţi utilizatorii, făcând apel la o metodă
pusă la dispoziţie de interfeţele Spring de tip JpaRepository, metoda findAll().

În acest punct, poate apărea o întrebare legată de utilitatea claselor de tip @Service,
întrucât metodele din interfeţele @Repository pot fi accesate şi de la nivelul claselor
@Controller.

În primul rând, utilizarea unui nivel intermediar de service realizează o separare

mai bună între logica ce ţine de accesul la date şi logica aplicaţiei web(adică tratatea
cererilor) ce este implementată de obicei în controller. Clasele de tip service conţin cod
reutilizabil, mai ales în scenariul în care aplicaţia implementată trebuie să aibă şi o variantă
de web şi o variantă de desktop/dispozitiv mobil. Astfel, primele două niveluri vor putea
rămâne la fel, modificându-se doar clasele de la nivelul superior, ce ţin de logica aplicaţiei.

În al doilea rând, existenţa unor clase @Service facilitează şi procesul de testare

automată. Dacă interfeţele @Repository ar fi fost utilizate direct de controller, atunci ar fi
fost mai greu de verificat că interogările asupra bazei de date returnează rezultate corecte,
deoarece metodele din clasele de tip controller sunt mai complexe şi presupun mai mult
decât efectuarea unor operaţii asupra bazei de date. În cazul acestei aplicaţii, testele unitare
JUnit au fost scrise pentru clasele de tip service.

2.Prezentarea metodei pentru încărcarea de fişier

Cea mai complexă metodă şi cea pe care se bazează întreaga aplicaţie este metoda
pentru încarcarea unui articol, care este reprezentat sub formă de fişier PDF. Această
metodă are rolul de a valida fişierul, verificând întâi dacă acesta a mai fost încărcat ulterior
şi în caz contrar de a îl salva în baza de date, împreună cu toate informaţiile
corespunzatoare introduse de utilizator.

Pentru determinarea similarităţii dintre două documente s-a folosit biblioteca open-
source Apache Lucene şi pentru extragerea conţinutului text din fişierele PDF s-a folosit o
altă bibliotecă open-source, PDFBox.

Metoda de încărcare a articolului poate fi apelată la URL-ul /upload şi este o

metodă HTTP de tip POST.

45
 Antetul metodei:

Metoda primeşte ca parametri titlul articolului, care este de tipul String, adică un şir
de caractere, fişierul încărcat, ce este reprezentat sub forma unui obiect de tipul
MultipartFile şi un parametru de tipul HttpServletRequest în care sunt încapsulate restul
informaţiilor despre articol ce sunt trimise în cererea de tip POST.

Ca şi prim pas, în corpul metodei se va determina care este utilizatorul logat ce a

trimis cererea, prin intermediul obiectului de tip HttpServletRequest. Mai departe, se
extrage numele fişierlui PDF şi se verifică dacă printre fişierele salvate pe server mai există
un fişier salvat sub acelaşi nume. Această verificare este necesară deoarece în cazul în care
se va încărca un fişier al cărui nume deja există, cand se va efectua operaţia de salvare a
noului fişier pe server, conţinutul celui de al doilea fişier îl va suprascrie pe primul. Astfel,
dacă acel nume de fişier este deja folosit, la sfarşitul numelui noului fişier se va adauga
cifra 2. După ce se va face redenumirea, fişierul va fi salvat într-un folder de pe server.

Mai departe, din fişierul PDF se va extrage conţinutul text utilizandu-se biblioteca
PDFBox. Pentru acest lucru s-a creat o clasă denumită PDFBoxUtils ce va conţine o
metodă de extragere a textului. Salvarea în prealabil a fişierului PDF, înainte de verificarea
pentru duplicate a fost necesară deoarece metoda PDFBox prin care se încarcă un fişier
cere ca parametru o cale, deci fişierul nu ar fi putut fi procesat dacă nu era salvat pe server.

După ce s-a obţinut conţinutul text al unui fişier PDF acesta se va indexa folosind
Apache Lucene. Atunci când un document este indexat cu Lucene i se atribuie un ID
intern, problema majoră cu acest ID fiind că se generează în mod aleator şi nu este
persistent, se poate modifica după fiecare adăugare a unui nou document la index. Acest
lucru poate însă fi rezolvat, deoarece la indexarea unui document de tip text, programatorul
mai poate adăuga şi alte informaţii suplimentare pentru identificare, deci se poate adăuga
un alt ID care să fie persistent şi care să poată fi generat după o anumită regula(de exemplu
auto-incrementare). S-a ales ca acest ID să corespundă cu ID-ul din baza de date.

În continuare, în metoda de încărcare se extrage ID-ul maxim din tabelul de articole

salvate în baza de date(reprezentând ID-ul ultimului articol care a fost salvat) şi se
incrementează cu 1. Folosind acest ID, documentul este apoi indexat. Indexarea
documentului curent este necesară deoarece dacă documentul nu este adăugat la index,
acesta nu poate fi comparat cu restul documentelor. După acest pas, se va calcula
similaritatea cosinus dintre documentul curent şi restul documentelor ce au fost indexate.

46
 Pentru calcularea similarităţii cosinus a fost implementată clasa CosineSimilarity.
Apache Lucene are implementată o metodă care primeşte ca parametru ID-ul intern al unui
document indexat şi returnează vectorul de frecvenţă a apariţiei termenilor. Având în
vedere faptul că ID-ul intern nu este mereu acelaşi a fost necesar ca înainte de fiecare
indexare să se determine corespondenţa dintre ID-ul dat de programator(care coincide cu
cel din baza de date) şi cel dat aleator de Lucene. Acest lucru s-a realizat prin calcului unei
structuri de date de tip HashMap ce conţine perechi de tipul cheie-valoare unde cheia este
ID-ul extern şi valoarea este ID-ul intern. Acest HashMap se va calcula înainte de fiecare
indexare.

După obţinerea vectorilor de frecvenţă pentru cele două documente se va calcula

similaritatea cosinus folosindu-se următoarea formulă:

În cod, aceasta este implementată astfel:

Vectorii v1 şi v2 reprezintă vectorii de frecvenţă şi vor fi calculaţi în constructorul

clasei.

Din punct de vedere teoretic, dacă două documente sunt identice atunci
similaritatea cosinus trebuie să ia valoarea 1. Pentru comparare s-a ales însă pragul de 0.97
pentru că în urma rulării câtorva teste pe documente identice rezultatul nu a fost întodeauna
1 şi a atins şi valori de 0.98 sau 0.99.

Dacă în urma comparării s-a gasit un document identic, atunci fişierul ce urma să
fie încărcat va fi şters din folderul în care a fost salvat şi din index, iar metoda îi va returna
un răspuns clientului cu mesajul că documentul ce se vrea a fi încărcat deja există.

Dacă nu se găseşte niciun document similar atunci metoda merge mai departe
pentru determinarea restului informaţiilor necesare pentru ca articolul să fie salvat în baza
de date. Astfel, în continuare, utilizând parametrul de tip HttpServletRequest se vor
determina: care sunt coautorii articolului, care sunt tagurile introduse de utilizator, ce tip de
articol a fost încărcat, informaţiile specifice pentru fiecare tip de articol. La final, după ce
au fost stabilite toate relaţiile se va efectua operaţia de scriere în baza de date, iar către
client va fi trimis un mesaj prin care se specifică dacă articolul a fost încărcat cu succes sau
nu.

47
 Mai jos este ilustrată o diagrama de activităţi care prezintă principalii paşi pentru
metoda de încărcare de fişier:

Fig x.x Diagrama de activităţi pentru metoda de încărcare de fişier

3.Autentificarea

Autentificarea este un mecanism de securitate prin care se verifică dacă un

utilizator este cine pretinde în momentul în care acesta îşi introduce credenţialele(numele
de utilizator şi parola) pentru a putea accesa anumite servicii oferite de o aplicaţie.

În aplicaţia implementată, mecanismul de autentificare se bazează pe folosirea unui

JWT(JSON Web Token). Această metodă nu implică salvarea stării utilizatorului logat pe
server, precum alte metode(sessions sau cookies) şi de aceea a devenit tot mai utilizată în
ultimii ani.

Un JSON Web Token este un şir de caractere ce a fost obţinut prin criptare cu o
cheie secretă, folosindu-se un algoritm specific. Este alcătuit din trei părti:

48
 ● header
● payload (parte ce conţine informaţie utilă)
● semnătură

Iniţial, headerul este reprezentat sub formă de fişier JSON şi poate conţine
informaţii despre algoritmul de criptare folosit (HMAC, SHA256, RSA) sau tipul
tokenului(în cazul de faţa JWT). Apoi, pentru a obţine prima parte a tokenului, headerul
este encodat în forma Base64 pentru a transforma toate datele in simboluri ASCII.

Partea de payload va conţine informaţii despre utilizatorul ce este autentificat cum

ar fi username-ul acestuia, dar şi despre token, de exemplu, cât timp este valabil. Payload-
ul va fi apoi encodat în forma Base64 şi va forma a doua parte a tokenului.

Pentru semnătură se vor lua headerul encodat, payloadul encodat şi asupra lor se va
face o criptare folosindu-se o cheie secretă şi un algoritm de criptare specific. Se va obţine
astfel a treia parte a tokenului.

Pentru autentificare, utilizatorul îşi va trimite username-ul şi parola, serverul va

verifica dacă sunt valide şi va genera un JSON Web Token. Acest token va fi adăugat în
header-ul tuturor cererilor HTTP ce vor urma să fie facute de utilizatorul logat şi când
acesta va solicita accesul la resurse protejate, serverul va verifica doar validitatea
tokenului.

Avantajul adus de această metodă este că prin folosirea tokenului nu se va mai crea
un tabel în baza de date pentru a salva starea utilizatorului, ceea ce implică mai puţine
interogări la fiecare cerere, deci un timp de răspuns mai rapid.

Pentru implementarea autentificării s-a folosit modulul Spring Security ce oferă

suport pentru autentificare şi controlul accesului. Pentru a beneficia de securitatea pusă la
dispoziţie de acest modul este necesară implementarea unei clase de configurare ce extinde
clasa de bază WebSecurityConfigurerAdapter.

În clasa de configurare este esenţial să se suprascrie metoda configure prin care se

specifică ce tipuri de cereri vor fi permise fară ca utilizatorul să fie înregistrat şi ce tipuri
de cereri sunt permise pe tip de utilizator. Spring Security oferă posibilitatea definirii unor
grupuri de utilizatori, în cazul acestei aplicaţii cele două grupuri fiind USER şi ADMIN.
Controlul accesului se va face pe bază de URL. Pentru fiecare tip de utilizator se vor
specifica URL-urile metodelor la care îi este permis accesul.

49
 Astfel, toate cererile ce vor începe cu calea /auth şi vor avea ca scop logarea sau
crearea de cont le vor fi permise tuturor utilizatorilor. Pentru URL-ul /user/all ce apelează
metoda GET din controller-ul dedicate resursei utilizator s-a restricţionat accesul, doar
utilizatorii cu rolul de ADMIN vor avea permisiune. În acest fel se asigură securizarea
resurselor aplicaţiei, iar în cazul în care un client va face o cerere pentru care nu este
autoritzat serverul va genera un răspuns cu codul 401 UNAUTHORIZED.

De asemenea, în clasa de configurare trebuie să fie definită şi o metodă prin care se

specifică unde sunt stocate datele de autentificare, adică numele de utilizator şi parolele
aferente. În cazul acesta datele vor fi stocate în tabelul User, iar metoda va avea acces la
acest tabel.

Pentru implementarea autentificării pe bază de JSON Web Token a fost necesară

implementarea unei clase TokenUtils ce conţine metode pentru: generare de token,
validare, determinarea numelui de utilizator pe baza tokenului, data la care tokenul a fost
creat, data la care tokenul expiră.

De asemenea, este necesară şi implementarea unei clase de tip filtru ce extinde

clasa UsernamePasswordAuthenticationFilter. Clasa conţine o metodă denumită doFilter ce
are ca parametri un obiect de tipul ServletRequest şi un obiect de tipul ServletResponse.
Această metodă va înregistra toate cererile venite către server, va verifica header-ul pentru
a valida token-ul, iar în caz că acesta este valid va delega cererea mai departe către
controllerul responsabil, în caz contrar va genera un răspuns prin care se va specifica faptul
că utilizatorul nu este autentificat.

Nivelul client

Nivelul client este cel care permite realizarea interfeţei grafice ce poate fi
vizualizată din browser. Pentru implementare s-au folosit următoarele tehnologii:

 Angular JS – framework pentru limbajul Javascript

 CSS – limbaj utilizat pentru stilizarea paginilor web
 Bootstrap – framework de CSS
 HTML – limbaj de marcare static folosit pentru a declara structura unei pagini

Frameworkul Angular JS stă la baza implementării unei aplicaţii dinamice. Aşa

cum a fost prezentat şi în partea teoretică, o aplicaţie dinamică este o aplicaţie ce îi permite

50
utilizatorului să trimită către server cereri de tip HTTP(în principal GET, POST, PUT) şi de
asemenea să asigure afişarea răspunsului primit. Angujar JS conlucrează foarte bine cu
limbajul HTML întrucât conţine nişte componente specifice numite directive, ce pot fi
integrate în sintaxa HTML în scopul îndeplinirii anumitor funcţionalităţi.

În continuare se va prezenta cum este realizată interacţiunea dintre Angular JS şi

HTML.
În primul rând, pentru a putea utiliza Angular în cadrul unei aplicaţii, trebuie
importată biblioteca în cadrul unui fişier HTML care prin convenţie este denumit
index.html şi este fişierul HTML aferent paginii principale pe care se încarcă întreaga
aplicaţie. De asemenea, aici vor fi declarate şi restul fişierelor Javascript sau CSS ce sunt
folosite în cadrul aplicaţiei.

Următorul pas este de a realiza un fişier de configurare în care este declarată o

instanţă de aplicaţie Angular. Aici se precizează numele aplicaţiei, precum şi modulele
Angular de care va avea nevoie aplicaţia(în cazul de faţă s-au folosit modulele ui.router,
lr.upload, ngMaterial şi ui.bootrap).

Mai departe, tot în acest fişier sunt declarate stările aplicaţiei, întrucât o aplicaţie
Angular nu va conţine pagini propriu-zise. Declararea stărilor se face cu ajutorul modului
ui.router.

Mai sus este reprezentat un exemplu de declarare a stării default a aplicaţiei. Pentru
declararea unei stări trebuie precizate numele, url-ul şi fişierul HTML aferent.

În cadrul fişierului index.html instanţa de aplicaţie Angular este declarată utilizând

directiva ng-app urmată de numele aplicaţiei. Se observă că directivele Angular au sintaxa
unor atribute HTML.

Logica propriu-zisă a aplicaţiei este implementată în nişte fişiere denumite

controllere. În general, fiecare stare va avea asociat şi un controller. Pentru a declara un
controller se foloseşte următoarea sintaxă:

Funcţia aferentă controllerului este parametrizată cu nişte variabile predefinite în

cadrul Angular, rolurile lor fiind următoarele:

51
  $scope – este o variabilă prin intermediul căreia datele din controller pot fi vizibile
în cadrul fişierului HTML
 $http – este un serviciu oferit de Angular prin intermediul căruia se realizează
cererile HTTP
 $state – este o variabilă ce permite accesarea stării curente(a fost utilizată pentru a
realiza o operaţie de refresh asupra unei stări)

În cadrul controllerului se vor declara variabile ce vor fi trimise apoi pentru a fi

randate în fişierul HTML. Toate variabilele ce se vor a fi vizibile în fişierul HTML vor fi
denumite după forma $scope.numeVariabilă. Pentru a putea fi accesate în HTML se va
folosi doar numeVariabilă, nu mai este nevoie de declararea prefixului $scope.
Pentru a face legătura între un controller şi un fişier HTML se va folosi directiva
ng-controller. De obicei controllerul se va asocia unui tag ce cuprinde conţinutul întregii
pagini.

O altă directivă Angular foarte des folosită este ng-repeat. Aceasta are rolul unui
for, parcurgând toate elementele dintr-o variabilă de tip vector. În exemplul de mai jos
variabila users este un vector ce conţine informaţii despre toţi utilizatorii ce şi-au creat cont
pe aplicaţie şi a fost obţinută în urma unei cereri HTTP la adresa “user/all” ce apelează
metoda existentă pe server. În controller aceasta are denumirea de $scope.users în timp ce
în fişierul HTML poate fi accesată doar cu denumirea users.

Expresiile de tip Angular din afara directivelor vor fi marcate cu {{expresie}}. În

cazul de faţă expresia user.nume va afişa numele utilizatorului curent doar daca va fi scrisă
între acolade.

În cazul completării formularelor, pentru sincronizarea datelor din HTML cu cele

din controller se foloseşte directiva ng-model. Aceasta este asociată tag-urilor HTML ce
sunt utilizate pentru completarea formularelor şi anume <input> , <select> .

Angular JS poate fi utilizat şi în cazul validării formularelor. Tag-urilor de tip input

le sunt asociate nişte stări de tipul valid/invalid, completat/necompletat,
modificat/nemodificat. Pentru a verifica dacă titlul introdus este valid şi câmpul nu a fost
lăsat necompletat se va folosi următoarea sintaxă:

O altă directivă Angular folosită în cadrul aplicaţiei este ng-click. Aceasta se

asociază de obicei unui element de tip buton, dar poate fi utilizată şi pe alte componente,

52
având rolul de a preciza ce se va întâmpla când utilizatorul dă click cu mouseul pe
compnenta respectivă. În general este parametrizată cu o funcţie ce se va regăsi în cadrul
controllerului.
5. Descrierea aplicaţiei realizate

În urma procesului de implementare, produsul rezultat este o aplicaţie web

funcţională ce îndeplineşte în mare parte toate obiectivele de bază ce au fost precizate în
introducerea lucrării. Acest capitol va conţine o prezentare detaliată a tuturor
funcţionalităţilor aplicaţiei cu explicaţii însoţite de capturi de ecran.

Aplicaţia implementată conţine următoarele funcţionalităţi:

 Înregistrare cont de utilizator şi autentificare

 Posibilitatea unui utilizator de a încărca un articol ştiinţific sub forma unui fişier
PDF
 Asigurarea că la încărcarea unui articol acesta nu este deja existent în baza de date
 Clasificarea articolelor în funcţie de tipul acestora, astfel un articol poate
reprezenta: o carte, un capitol dintr-o carte, o prezentare în cadrul unei conferinţe,
un articol prezent în cadrul unei reviste ştiinţifice sau jurnal ştiinţific
 Căutări după diverse criterii cum ar fi: tip articol, autor, cuvinte cheie sau anul
publicării
 Generarea de rapoarte privind activitatea utilizatorilor: ce utilizator a încărcat cele
mai multe articole, ce utilizator are cele mai multe articole descărcate, ce utilizator
a încărcat cele mai multe articole de un anumit tip
 Sortarea utilizatorilor în funcţie de numărul de articole publicate

Aplicaţia conţine următoarele secţiuni:

1. Secţiunea dedicată înregistrării şi autentificării

2. Secţiunea dedicată încărcării unui articol
3. Secţiunea dedicată căutării
4. Secţiunea dedicată profilului unui utilizator
5. Secţiunea dedicată utilizatorului de tip ADMIN

1.Secţiunea dedicată înregistrării şi autentificării

În primul rând, pentru ca un utilizator să aibă acces la funcţionalităţile aplicaţiei

este necesar ca acesta să îşi creeze un cont. În acest scop a fost creat un formular de
înregistrare ce conţine următoarele câmpuri: nume, prenume, nume de utilizator, parolă,
email, poziţia ocupată în cadrul facultăţii.

Odată creat, contul va putea fi imediat utilizat şi utilizatorul se va putea autentifica.

La autentificare, în cazul introducerii unei combinaţii greşite de nume de utilizator şi
parolă, utilizatorul va primi mesajul “Combinatia de username si parola este incorecta”.

53
 2.Secţiunea dedicată încărcării unui articol

Fig x.x Formularul de încărcare articol

Pentru a încărca un articol , utilizatorul trebuie să completeze un formular în care

va introduce informaţii despre articolul respectiv. Vor exista nişte câmpuri care trebuie
completate indiferent de tipul articolului, mai exact: titlu, WOS, DOI, abstract, coautori,
tag-uri. Odată selectat tipul articolului, se va deschide o nouă fereastră în care vor fi
completate informaţii specifice, astfel:

 pentru articolele de tip carte completă: editură, ediţie, an apariţie, ISSN, ISBN
 pentru articolele de tip capitol: titlu cărţii din care face parte capitolul, numele
capitolului, lista completă de autori ai cărţii, lista editorilor cărţii, editura, ediţia,
anul apariţiei cărţii, ISSN, ISBN, paginile la care se găseşte capitolul
 pentr articolele de tip conferinţă: numele conferinţei, locaţia, data
 pentru articolele de tipul jurnal/revistă: numele publicaţiei, numărul, volumul, data
apariţie, ISSN, ISBN, paginile la care se regăseşte articolu

Pentru a adăuga un coautor există două posibilităţi: adăugarea unui coautor ce are deja
creat un cont sau adăugarea unui coautor ce nu are cont.

54
 Fig x.x Formularul pentru adăugare coautori

În cazul adăugării unui coautor ce are deja cont, utilizatorul îi va putea selecta
numele dintr-o listă derulantă şi pentru a salva alegerea făcută va apăsa pe butonul Adauga
coautor. Pentru a finaliza cu adăugarea coautorilor se va apăsa butonul Finalizare.

Pentru adăugarea unui coautor ce nu are cont, utilizatorul are la dispoziţie o casetă
de text în care va introduce numele integral al coautorului.

Utilizatorul are posibilitatea de a adăuga mai multe tag-uri pentru articol.

Denumirea unui tag trebuie să aibă cel puţin 3 caractere. Tag-urile vor fi introduse pe rând
într-o casetă de text şi după introducerea fiecărui tag se va apăsa butonul Adauga tag.

Fig x.x Adăugarea tag-urilor

În afară de câmpurile folosite pentru adăugarea de coautori şi tag-uri pentru
articole, restul câmpurilor sunt obligatorii şi în cazul necompletării lor butonul de încărcare
va fi inactiv.

În situaţia în care procesul de încărcare a articolului a fost finalizat cu succes,

utilizatorul va primi mesajul „Articolul a fost încărcat cu succes”. Dacă articolul deja
există atunci încărcarea lui nu va fi permisă şi utilizatorul va primi mesajul „Articolul deja
a fost încărcat”.

Un utilizator va avea pagina sa de profil în care vor putea fi vizualizate toate

articolele încărcate de acesta, precum şi articolele adăugate la favorite.

Aplicaţia conţine şi o arhivă cu toate articolele ce au fost încărcate, ordonate

alfabetic. Pe pagina dedicată arhivei un utilizator are posibilitatea de a face căutare după
titlu prin intermediul unei casete de text.

3.Secţiunea dedicată căutării

Secţiunea dedicată căutării conţine un formular care îi permite utilizatorului să

realizeze căutări în funcţie de următoarele criterii: tip articol, titlu, autor, tag, an apariţie.

55
 Fig x.x Formularul de căutare articol

Utilizatorul va avea afişate şi instrucţiuni de căutare şi anume:

 trebuie selectat un singur tip de articol

 în cazul necompletării unui câmp acesta nu va fi luat în considerare
 pentru autor se vor lua în considerare doar combinaţiile de forma nume-prenume
 în cazul în care se face căutare după titlu, trebuie introdus un titlu complet
 căutarea se va face după toate câmpurile ce au fost completate

De asemenea, aplicaţia mai conţine şi o secţiune dedicată căutării după autor, în

care utilizatorul va putea alege din lista tuturor autorilo ce şi-au creat cont pe platformă.

4.Secţiunea dedicată profilului unui utilizator

Fiecare utilizator va avea o secţiune dedicată profilului său. Această secţiune va

conţine: detaliile despre utilizator(nume, prenume, nume utilizator, funcţie), articolele
încărcate, precum şi articolele marcate ca şi favorite.

5.Secţiunea dedicată utilizatorului de tip ADMIN

Secţiunea dedicată utilizatorului de tip ADMIN conţine două pagini: o pagină în

care este afişată întreaga listă de utilizatori şi o pagină dedicată rapoartelor.

Pagina dedicată listei de utilizatori conţine o afişare de tip tabelar în care se

regăsesc informaţii precum nume, prenume, nume de utilizator, email, funcţie. Pentru
fiecare utilizator, administratorul poate vedea următoarele statistici: numărul total de
articole ce au fost încărcate din fiecare tip, numărul total de descărcări pentru articolele
încărcate de utilizatorul respectiv. Pentru uşurinţa căutării există o casetă de text în care
administratorul poate căuta un utilizator după nume.

56
 Fig x.x Fereastra de statistici pentru un utilizator

Secţiunea de rapoarte este împărţită în două părţi:

 rapoarte per utilizator
 rapoarte per grup de utilizatori

În cazul rapoartelor per utilizator, se pot vizualiza următoarele:

 utilizatorul cu cele mai multe articole încărcate
 utilizatorul cu cele mai multe articole descărcate
 utilizatorul cu cele mai multe articole de un anumit tip
 utilizatorul cu cele mai multe articole încărcate într-un an

Fig x.x Rapoarte per utilizator

Pentru a vizualiza utilizatorul cu cele mai multe articole de un anumit tip, există o
casetă derulantă din care se poate selecta tipul articolului.

În cazul utilizatorului cu cele mai multe articole încărcate într-un an în caseta de

text se va introduce anul după care se face căutarea.

57
 Secţiunea pentru rapoarte per grup de utilizatori permite sortarea utilizatorilor în
funcţie de articolele încărcate şi descărcate. Este pusă la dispoziţie o listă derulantă din
care se poate selecta criteriul de sortare dorit. Rezultatele vor fi afişate apoi într-o formă
tabelară, în ordine descrescătoare.

Cel de-al doilea raport constă în afişarea tuturor utilizatorilor care au încărcat un
articol de un anumit tip. Pentru acest lucru se va selecta din lista derulantă tipul articolului
şi rezultatele vor fi afişate tot într-o formă tabelară.

Fig x.x Rapoarte per grup de utilizatori

58
7.Bibliografie

1. Randy Connoly, Ricardo Hoar (2015). Fundamentals of Web Development

2. Leonard Richardson, Mike Amundsen (2013). RESTful Web APIs
3. Craig Walls (2015). Spring in Action, fourth edition
4. Ion Lungu, Ileana Tănase. (2001). Modelul vectorial de organizare a datelor Revista
Informatică Economică, nr. 1(17)/2001
5. E. Garcia (2015). Cosine similarity tutorial
6. Dorin Cârstoiu(2009). Baze de date
7. Andrew S. Tanenbaum (2003). Reţele de calculatoare, ediţia a patra
8. Documentaţie Spring Framework http://docs.spring.io/spring/docs/current/spring-
framework-reference/htmlsingle/ Accesat:2017
9. Bryan Basham, Kathy Sierra, Bert Bathes (2008). Head First Servlets & JSP
10. Documentaţie Spring Security https://docs.spring.io/spring-
security/site/docs/current/reference/htmlsingle/ Accesat:2017
11. Documentaţie Angular JS https://docs.angularjs.org/guide Accesat:2017
12. Vlad Mihalcea(2015). High Performance Java Persistence
13. What’s in a HTTP request? http://rve.org.uk/dumprequest Accesat:2017
14. Documentaţie PDFBox https://pdfbox.apache.org/ Accesat:2017

Sun GlassFish Message Queue 4.4 Technical Overview. Documentaţie Oracle (2010).
http://docs.oracle.com/cd/E19587-01/821-0028/6nl41ccpg/index.html Accesat: 2015.
7. Verhenneman, G. (2009). Cameras in your living room, the next step in e-homecare?
European Journal of ePractice, No.8, Decembrie 2009, pag. 68-76, ISSN: 1988-625X

59