Aplicație web pentru crearea unui profil vocațional [610714]

UNIVERSITATEA DIN BUCREȘTI
FACULTATEA DE MATEMATICĂ ȘI INFORMATICĂ
DOMENIUL CALCULATOARE ȘI TEHNOLOGIA INFORMAȚIEI

LUCRARE DE LICENȚĂ
Aplicație web pentru crearea unui profil vocațional

COORDONATOR ȘTIINȚIFIC:
Conf. univ. dr. Ana Cristina Dăscă lescu

ABSOLVENT: [anonimizat] – Valentin Rezmeriță

București, 2018

1

DECLARAȚIE PRIVIND ORIGINALITATEA ȘI
AUTENTICITATEA

(de completat)

2
Abstract

Momentul î n care un elev de liceu decide la ce facultate va dori să studieze este un
moment de o importanț ă majoră. Vocația pe care elevul o va alege poate fi definitorie pentru
întreaga sa viață, iar o schimbare în acest sens (reconversie profesională) poate fi, uneori,
imposibilă.
De aceea consider că este foarte important ca astfel de decizii să fie luate în cunoștință
de cauză; elevul trebuie să se cunoască pe sine, să știe cu un factor de certitudine cât mai mare
că va face ceea ce îi place și că domeniul ales i se potrivește. Trebuie să fie informat cu privire
la mersul lu crurilor din domeniul respectiv și să fie capabil să realizeze o analiză obiectivă cu
privire la compatibilitatea personalității sale cu cerințele domeniului.
CollegeFindr este o aplicație care vi ne în ajutorul elevilor aflați î n fața unui astfel de
moment. Această aplicație sugerează c ea mai potrivită facultate pentru un utilizator pe baza
răspunsurilor la î ntrebarile testului. Desigur, răspunsul este pur orientativ și nu trebuie
considerat ca unul cu acuratețe mare.

The moment when a high school student: [anonimizat], as a change in this matter is sometimes impossible.
Having this in mind, I consider that it is very important to take these decisio ns with a
massive knowledge background; the student: [anonimizat], he must be certain
that what he chose is what he likes to do and that a career in this field suits him well. He must
be informed about the insights of that field and he must b e able to do an impartial analysis
regarding the compatibility of his personality with the domain he chose.
CollegeFindr is an application designed to aid the students that have to take this kind o
decisions. It suggests the most suitable college for the user based on the answers to the quiz
questions. It is, indeed, a suggestion and it must not be taken as granted.

3
CUPRINS
LISTA FIGURILOR ………………………….. ………………………….. ………………………….. ………………………….. …………. 5
INTRODUCERE ………………………….. ………………………….. ………………………….. ………………………….. ………………. 8
1 TEHNOLOGII UTILIZATE ………………………….. ………………………….. ………………………….. ……………….. 10
1.1 ANGULAR ………………………….. ………………………….. ………………………….. ………………………….. …………. 10
1.1.1 AngularJS vs. Angular ………………………….. ………………………….. ………………………….. ……………….. 10
1.1.2 Arhitectura unei aplicații Angular ………………………….. ………………………….. ………………………….. … 11
1.1.2.1 Module ………………………….. ………………………….. ………………………….. ………………………….. ………………. 11
1.1.2.2 Componente ………………………….. ………………………….. ………………………….. ………………………….. ……….. 12
1.1.2.3 Servicii ………………………….. ………………………….. ………………………….. ………………………….. ………………. 13
1.1.2.4 Pagini HTML (View) ………………………….. ………………………….. ………………………….. ……………………….. 13
1.1.3 TypeScript ………………………….. ………………………….. ………………………….. ………………………….. ……. 14
1.2 JAVA ………………………….. ………………………….. ………………………….. ………………………….. ……………….. 14
1.3 SPRING ………………………….. ………………………….. ………………………….. ………………………….. …………….. 16
1.3.1 Spring Boot ………………………….. ………………………….. ………………………….. ………………………….. ….. 17
1.3.2 Spring Security ………………………….. ………………………….. ………………………….. ………………………….. 20
1.3.2.1 Autentificare bazată pe JWT ………………………….. ………………………….. ………………………….. ……………… 20
1.3.3 Spring Data JPA ………………………….. ………………………….. ………………………….. ………………………… 23
1.4 JPA CRITERIA API ………………………….. ………………………….. ………………………….. …………………………. 25
1.5 HIBERNATE ………………………….. ………………………….. ………………………….. ………………………….. ………. 26
1.6 MAVEN ………………………….. ………………………….. ………………………….. ………………………….. …………….. 28
1.7 BAZA DE DATE ………………………….. ………………………….. ………………………….. ………………………….. ….. 29
1.7.1 Oracle ………………………….. ………………………….. ………………………….. ………………………….. ………….. 29
1.7.2 Utilizator al bazei de date și stabilirea conexiunilor ………………………….. ………………………….. …….. 30
1.8 PROLOG ………………………….. ………………………….. ………………………….. ………………………….. ……………. 31
1.8.1 Sistem Expert ………………………….. ………………………….. ………………………….. ………………………….. .. 31
2 ARHITECTURA APLICAȚI EI ………………………….. ………………………….. ………………………….. …………… 33
2.1 ARHITECTURI SOFTWARE FRECVENTE ………………………….. ………………………….. ………………………….. .. 33
2.2 CLIENT -SERVER ………………………….. ………………………….. ………………………….. ………………………….. … 33
2.3 CLIENT -SERVER PE TREI NIVELU RI ÎN COLLEGE FINDR ………………………….. ………………………….. ……… 33
2.4 ARHITECTURA BAZEI DE DATE ………………………….. ………………………….. ………………………….. ………….. 35
2.5 ARHITECTURA SERVICIUL UI WEB ………………………….. ………………………….. ………………………….. ……… 37
2.5.1 Ierarhia de clase ………………………….. ………………………….. ………………………….. …………………………. 38
2.6 ARHITECTURA APLICAȚIE I-CLIENT ………………………….. ………………………….. ………………………….. ……. 41
2.7 CAZURI DE UTILIZARE ………………………….. ………………………….. ………………………….. …………………….. 41
2.7.1 Înregistrare ………………………….. ………………………….. ………………………….. ………………………….. …… 42
2.7.2 Autentificare ………………………….. ………………………….. ………………………….. ………………………….. …. 42
2.7.3 Editare profil ………………………….. ………………………….. ………………………….. ………………………….. … 43

4
2.7.4 Efectuarea testului ………………………….. ………………………….. ………………………….. ……………………… 43
2.7.5 Administrare ………………………….. ………………………….. ………………………….. ………………………….. …. 44
3 MANUAL DE UTILIZARE AL APLICAȚIEI ………………………….. ………………………….. ………………….. 45
3.1 AUTENTIFICARE ………………………….. ………………………….. ………………………….. ………………………….. … 46
3.2 ÎNREGISTRARE ………………………….. ………………………….. ………………………….. ………………………….. …… 47
3.3 DASHBOARD ………………………….. ………………………….. ………………………….. ………………………….. ……… 48
3.4 MENIU DE NAVIGARE ………………………….. ………………………….. ………………………….. ……………………… 51
3.5 PAGINA DE PROFIL ………………………….. ………………………….. ………………………….. ………………………….. 52
3.6 PAGINA DE TEST ………………………….. ………………………….. ………………………….. ………………………….. … 54
3.7 ADMINISTRARE ………………………….. ………………………….. ………………………….. ………………………….. …. 56
3.7.1 Administrarea soluțiilor ………………………….. ………………………….. ………………………….. ………………. 56
3.7.2 Administrarea întrebărilor ………………………….. ………………………….. ………………………….. …………… 58
3.7.3 Administrarea regulilor ………………………….. ………………………….. ………………………….. ………………. 59
4 CONCLUZII ………………………….. ………………………….. ………………………….. ………………………….. …………… 61
BIBLIOGRAFIE ………………………….. ………………………….. ………………………….. ………………………….. …………….. 63

5
LISTA FIGURILOR
Fig. 1.1 Arhitectura unei aplicații Angular. ………………………….. ………………………….. …………. 11
Fig. 1.2 Exemplu de modul din aplicația CollegeFindr în care sunt declarate toate componentele
din cadrul modulului și legăturile cu alte module sau servicii ………………………….. …………….. 12
Fig. 1.3 Exemplu de componentă din aplicația CollegeFindr în care am injectat serviciul
DashboardService și am definit șablonul HTML dashboard.component.html …………………… 12
Fig. 1.4 Exemplu de serviciu din aplicația CollegeFindr în care am injectat un alt serviciu,
CrudService, și am definit metode care vor apela componenta de back -end a aplicației …….. 13
Fig. 1.5 Exemplu de cod din fișierul dashboard.component.html în care sunt afișate datele
definite in componenta DashboardComponent prin intermediul directivelor
Angular(*ngFor, *ngIf, {{}} ) ………………………….. ………………………….. ………………. 14
Fig. 1.6 Indexul TIOBE Programming Community – rating de popularitate a limbajelor de
programare ………………………….. ………………………….. ………………………….. …………………………. 15
Fig. 1.7 Utilizarea Spring Boot în CollegeFindr adnotând cu @SpringBoot Application clasa
principală ………………………….. ………………………….. ………………………….. ………………………….. .. 18
Fig. 1.8 Exemplu de controller în aplicația CollegeFindr ………………………….. …………………… 19
Fig. 1.9 Exemple de metode din contr oller ………………………….. ………………………….. ………….. 19
Fig. 1.10 Exemplu de adnotări de validare a câmpurilor unui obiect ………………………….. …… 20
Fig. 1.11 Schema de autentificare bazata pe JWT ………………………….. ………………………….. … 21
Fig. 1.12 Implementarea Spring Security, specificarea filtrului de autentificare și a căilor
exceptate ………………………….. ………………………….. ………………………….. ………………………….. … 21
Fig. 1.13 Filtrul de autentificare pe baza unui JWT ………………………….. ………………………….. . 22
Fig. 1.14 Exemplu de creare a unui bean pentru funcții hash, Bcrypt ………………………….. ….. 22
Fig. 1.15 Exemplu de u tilizare a funcției hash pe parole ………………………….. ……………………. 22
Fig. 1.16 Exemplu de parole stocate criptat în baza de date ………………………….. ……………….. 23
Fig. 1.17 Exemplu de autori zare selectivă în back -end ………………………….. ………………………. 23
Fig. 1.18 Exemplu de autorizare selectivă în front -end ………………………….. ……………………… 23
Fig. 1.19 Exemplu de configurare a Sprin g Data JPA în aplicația CollegeFindr ……………….. 24
Fig. 1.20 Exemplu de definire a unui depozit JPA în aplicația CollegeFindr …………………….. 24
Fig. 1.21 Exemple de interogări utilizând Spring Data JPA ………………………….. ……………….. 24
Fig. 1.22 Exemplu de interfață pentru definirea interogărilor complexe ………………………….. . 25
Fig. 1.23 Exemplu de implementare a clasei în care construim interogări complexe ………….. 25

6
Fig. 1.24 Exemplu de definire a unui depozit ce reunește interogările nou definite și operațiile
clasice CRUD ………………………….. ………………………….. ………………………….. ……………………… 25
Fig. 1.25 Exemplu de creare a interogărilor complexe utilizând Criteria API ……………………. 26
Fig. 1.26 Traducerea în SQL a interogării creat e cu Criteria API ………………………….. ……….. 26
Fig. 1.27 Exemplu de folosire a adnotărilor oferite de Hibernate pentru maparea entităților . 27
Fig. 1.28 Ex emplu de configurare Maven în care specificăm grupul, artifactul, versiunea
aplicției și părintele de la care va moșteni alte configurații (în cazul de față, vrem sa obținem
configurații pentru un proiect Spring Boot) ………………………….. ………………………….. …………. 28
Fig. 1.29 Exemplu de includere a depenențelor pentru Spring Boot, Spring Security, Spring
Data JPA, JWT în aplicație prin intermediul fișierului pom.xml procesat de Maven …………. 29
Fig. 1.30 Utilizatorul creat pentru aplicația ColegeFindr ………………………….. ……………………. 30
Fig. 1.31 Configurațiile pentru acces la baza de date din fișierul application.yml ……………… 30
Fig. 1.32 Exemplu de reguli și fapte folosite de sistemul expert ………………………….. …………. 32
Fig. 1.33 Exemplu de soluție a sistemului expert ………………………….. ………………………….. …. 32
Fig. 2.1 Arhitectura client -server pe 3 niveluri a aplicației CollegeFindr ………………………….. 34
Fig. 2.2 Diagrama entitate -relație a bazei de date ………………………….. ………………………….. …. 36
Fig. 2.3 Ieraria de clase din serviciul web ………………………….. ………………………….. ……………. 38
Fig. 2.4 Exemplu clasic de ierarhie de clase ………………………….. ………………………….. ………… 39
Fig. 2. 5 Ierarhie de clase pentru comunicarea cu prolog (partea 1) ………………………….. ……… 40
Fig. 2.6 Ierarhie de clase pentru comunicara prolog (partea 2) ………………………….. ……………. 40
Fig. 2.7 Ierarhia de componente a aplicației -client ………………………….. ………………………….. .. 41
Fig. 2.8 Diagrama UML pentru înregistrare ………………………….. ………………………….. ………… 42
Fig. 2.9 Diagrama UML pentr u autentificare ………………………….. ………………………….. ……….. 42
Fig. 2.10 Diagrama UML pentru editarea profilului ………………………….. ………………………….. 43
Fig. 2.11 Diagrama UML pentru începerea testului ………………………….. ………………………….. . 43
Fig. 2.12 Diagrama UML pentru continuarea testului ………………………….. ……………………….. 44
Fig. 2.13 Diagrama UML pentru administrare ………………………….. ………………………….. ……… 44
Fig. 3.1 Formularul de autentificare ………………………….. ………………………….. ……………………. 46
Fig. 3.2 Formularul de autentificare – erori ………………………….. ………………………….. ………….. 46
Fig. 3.3 Formularul de înregistrare în aplicație ………………………….. ………………………….. …….. 47
Fig. 3.4 Formularul de înregistrare în aplicație – erori ………………………….. ………………………. 47
Fig. 3.5 Pagina principa lă – dashboard ………………………….. ………………………….. ……………….. 48
Fig. 3.6 Mesaj utilizator nou ………………………….. ………………………….. ………………………….. …. 48
Fig. 3.7 Tabel cu toate testele efectuate de utilizator ………………………….. …………………………. 49

7
Fig. 3.8 Detalii ale unui test ………………………….. ………………………….. ………………………….. ….. 50
Fig. 3.9 Meniu de navigare utilizator normal ………………………….. ………………………….. ……….. 51
Fig. 3.10 Meniu de navigare administrator ………………………….. ………………………….. ………….. 51
Fig. 3.11 Pagina de profil a utilizatorului ………………………….. ………………………….. …………….. 52
Fig. 3.12 Mesaje de informare la edi tarea profilului ………………………….. ………………………….. 53
Fig. 3.13 Pagina de test – informare ………………………….. ………………………….. ……………………. 54
Fig. 3.14 Panou întrebare ………………………….. ………………………….. ………………………….. ……… 54
Fig. 3.15 Panou soluții ………………………….. ………………………….. ………………………….. ………….. 55
Fig. 3.16 Panou solutii – sistmeul expert nu are solutii ………………………….. ………………………. 55
Fig. 3.17 Pagina de administrare – inform ații generale ………………………….. ………………………. 56
Fig. 3.18 Tabelul de administrare a soluțiilor ………………………….. ………………………….. ………. 56
Fig. 3.19 Fereastra de editare a unei soluții ………………………….. ………………………….. ………….. 57
Fig. 3.20 Informații pentru administrarea soluțiilor ………………………….. ………………………….. . 58
Fig. 3.21 Tabelul de administrare a întrebărilor ………………………….. ………………………….. …… 58
Fig. 3.22 Fereastra de editare a unei întrebări ………………………….. ………………………….. ………. 58
Fig. 3.23 Informații pentru administrarea întrebărilor ………………………….. ……………………….. 59
Fig. 3.24 Tabelul de administrare a regulilor ………………………….. ………………………….. ……….. 59
Fig. 3.25 Fereastra de editare a unei reguli ………………………….. ………………………….. ………….. 60
Fig. 3.26 Informa ții pentru administrarea regulilor ………………………….. ………………………….. .. 60

8
INTRODUCERE
După cum am menționat în Abstract , CollegeFindr este o aplicație web menită să ajute
elevii în procesul de decizie cu privire la alegerea facultății. Acest moment este fo arte important
pentru definirea carierei unui elev și de aceea cunoașterea de sine, în primul rând, și cunoașterea
domeniului ales, în al doilea rând, sunt două aspecte foarte importante.
CollegeFindr este o aplicație care rezolvă parțial prima dintre ce le două probleme
expuse anterior, iar această lucrare de licență are ca scop prezentarea aplicației și a
implementării acesteia. Obiectivul final este conștient izarea importanței cunoașterii de sine
când este vorba despre a lua o decizie care are impact di rect asupra vieții individului.
Implementarea acestei aplicații este destul de generalistă, permițând schimbarea
scopului algoritmului. Cu alte cuvinte, aceasta poate fi configurată în așa fel încât ea să ofere
utilizatorului alt „cel mai potrivit lucru” . Pentru a reconfigura scopul aplicației este necesar ca
datele din baza de date și regulile folosite de algoritm sa fie schimbate. Acest lucru reprezintă
un avantaj competitiv major deoarece astfel de flexibilitate este destul de greu de obținut.
Pentru elevul care probabil a luat decizia pe jum ătate, avantajul utilizării acestei aplicații
este obținerea unei „opinii secunde”. Este posibil ca aplicația să îi ofere o soluție pe care
utilizatorul a luat -o în considerare, sau din contră, să îi ofere o soluți e dintr -un areal distinct la
care elevul nu s -a gândit, caz în care este demonstrată ipoteza că astfel de decizii trebuiesc luate
în cunoștință de cauză și cu noașterea de sine este importantă.
Pe piață există alte aplicații care au scop similar cu cel al aplicației CollegeFindr: aflarea
unei facultăți potrivite. Două dintre aceste aplicații sunt Education Finder și The College Fair .
Diferența constă î n faptul că acestea propun o listă de facultăți, iar utilizatorii pot introduce
diverse filtre pentru a raf ina căutarea pană la cel mai mic detaliu cum ar fi: țara, mediul (într -o
metropolă, într -un oraș mic, etc.), taxe de școlarizare, notele de admitere , domeniu, rata de
promovabilitate, etc. Acestea oferă, de asemenea , multe informații prețioase despre facul tatea
respectivă. Astfel de aplicații nu rezolvă însă problema de fond: aflar ea facultății care i se
potriveș te elevului cel mai bine, și nu cea care cr ede elevul că i se potrivește; n u rezolv ă
problema cunoașterii de sine.
Consider că utilitatea unei apl icații precum CollegeFindr este evidentă: poate cel mai
sugestiv scenariu de utili zare ar fi integrarea acesteia î n liceele din România. Împreună cu alte
programe de orientare și educare profesională a elevilor, beneficiile unei astfel de acțiuni la

9
nivel național ar fi semnificative: un număr cât mai mare de elevi vor urma facultățile potrivite
lor, ceea ce s -ar putea traduce într -un procentaj mai mic de abandon î n facultate, un număr cât
mai m are de studenți bine pregătiți î n domeniul ales care se angajea ză după terminarea facultății
sau chiar din timpul facultății și sunt ferici ți la locul lor de muncă și nu în ultimul rând,
reducerea ratei șomajului .
Din punct de vedere structural, p rezenta lucrare este împărțită în patru capitole:
1. Tehnologii utilizate – În acest capitol sunt descrise limbajele, utilitarele , framework –
urile și alte tehnologii care au fost utilizate în implementarea aplicației. De asemenea,
sunt date și secvențe de cod reprezentative pentru modul de implementare a acestor
tehnologii în ap licația descrisă.
2. Arhitectura aplicației – Acest capitol c onține detalii de arhitecturare: descrierea
părților componente ale aplicației și a modului de comunicare între ele .
3. Manual de utilizare – În acest capitol s unt detaliate interfața grafică și funcți onalitățile
aplicaț iei prin capturi de ecran din aplicație.
4. Concluzii – Prezentarea concluziilor finale asupra aplicației, procesului de dezvoltare a
acesteia și descrierea direcțiilor viitoare de dezvoltare.

10
1 TEHNOLOGII UTILIZATE
Acest capitol este menit să descrie fiecare tehnologie folosită pentru dezvoltarea
aplicației, iar acolo unde este cazul se va detalia modul de utilizare (implementare/integrare)
efectivă a acestor tehnologii în aplicație.
1.1 ANGULAR
Pentru dezvoltarea aplicației client, am a les să utilizez Angular 5, o platforma ce
utilizează limbajul de programare TypeScript. Versiunea 5 a platformei Angular a fost lansată
la 1 Noiembrie 2017, iar ultima versiune ce poate fi utilizată este Angular 6, lansată la 4 Mai
2018.
Framework -ul Angular are sursa deschisă (open -source) și este proiectat pentru a crea
cu ușurină componentele de front -end a le aplicațiilor web subforma unor Aplicații cu o Singură
Pagină (SPA – Single Page Application) . Acesta a fost conceput și implementat de o echipă de
inginer i software din cadrul Google, numită Angular Team. Platforma Angular reprezintă o
refactorizare completă a framework -ului predecesor, AngularJS (care utiliza JavaScript) , creat
de aceeași echipă. L a această reconstrucție din temelii a platformei s-a angaja t și o numeroasă
comunitate de dezvoltatori independenți și corporații.
1.1.1 AngularJS vs. Angular
Reprezintă o greșeală stabilirea unei relații de echivalență între framework -urile
AngularJS și Angular (prin Angular ne referim la versiunile 2+ ale platformei) deoarece
diferențele dintre cele două entități sunt majore:
 Angular folosește conceptul de „componentă” drept atom al arhitecturii unui proiect și
a renunțat complet la controlere (controller). O componentă reprezintă o directivă care
are un șablon (templa te).
 Directivele din AngularJS, ng-model pentru stabilirea unei legături în două sensuri
(two-way binding) și ng-bind pentru stabilirea unei legături într -un singur sens (one –
way binding) au fost înlocuite în Angular de construcțiile „[ ]” respectiv „[( )] ”. Cu alte
cuvinte, „[ ]” este folosit pentru stabilirea legăturilor între proprietăți (propery binding),
iar „( )” este folosit pentru stabilirea legăturilor cu evenimente (event binding).

11
 Modularitatea reprezintă un alt avantaj al Angular; multe dintre f uncționalitățile
nucleului au fost împărțite în diverse module fapt ce s -a reflectat într -o viteză de
execuție a nucleului mult mai mare.
 Odată cu lansarea Angular a apărut și o unealtă foarte utilă, Angular CLI. Aceasta
permite crearea cu ușurință a compo nentelor din proiect și a dependen țelor acestora
(scaffolding). Spre exemplu, crearea unei componente în proiectul Angular prin
intermediul Angular CLI va genera atât fișierul TypeScript (conține logica și calculele
din spatele unei pagini), cât și fișiere le HTML și CSS (folosite pentru a afișa în pagină
variabile calculate în fișierul TypeScript). De asemenea este creat și un fișier de testare
automată (automated tests) pentru fișierul TypeScript.
1.1.2 Arhitectura unei aplicații Angular

Fig. 1.1 Arhitectura unei aplicații Angular.
La baza unei aplicații Angular stau așa numitele NgModule s. O aplicație reprezintă o
colecție de cel puțin un NgModule, numit modulul rădăcină – AppModule (root module)
folosit pentru pornirea aplicației . Un modul este compus, la rândul lui, din cel puțin o
componentă , numită componenta rădăcină.
1.1.2.1 Module
Modulele din Angular definesc un context de compilare pentru componentele din cadrul
acelui modul și asociază acestora servicii . Împre ună, aceste entități și legăturile dintre ele
formează unități funcționale.

12
Organizarea codului în această manieră ușurează munca în aplicații complexe cu multe
funcționalități și facilitează reutilizarea codului. Un modul poate importa funcționalități di n alte
module și poate exporta funcționalități către alte module.

Fig. 1.2 Exemplu de modul din aplicația CollegeFindr în care sunt declarate toate componentele din cadrul
modulului și legăturil e cu alte modu le sau servicii
În exemplul de mai sus am prezentat modulul rădăcină al aplicației. În acest modul sunt
definite componentele AppComponent (componenta rădăcină), LoginComponent și
RegisterComponent . De asemenea, aceasta importă, printre altele, și modulul
HomeModule care este implementat de mine (acesta are o structură similară) și conține toate
paginile și funcționalitățile ce pot fi accesate doar dacă utilizatorul este logat .
1.1.2.2 Componente
Componentele reprezintă cea mai mică unitate arhitecturală a unei a plicații Angular și
este necesar ca o aplicație să conțină cel puțin o componentă, componenta rădăcină.
Fiecare componentă dintr -o aplicație Angular trebuie sa definească o clasă care să
conțină logica și datele afișate în paginile HTML (view). Componente le pot folosi servicii
(service) unde sunt implementate funcționalități independente de componenta sau pagina
respectivă; astfel obținem un nou nivel de modularizare și reutilizare a codului.

Fig. 1.3 Exemplu de componentă din aplicația CollegeFindr în care am injectat serviciul DashboardService și
am definit șablonul HTML dashboard.comp onent.html

13
Decoratorul @Component aplicat unei clase o identifică drept componentă și va
defini, de asemenea, șablonul HTML și metadatele specifice componentei.
1.1.2.3 Servicii
Serviciile definesc funcționalități care nu sunt strâns legate de o anumită componentă,
ci mai degrabă funcționalități care pot fi utilizate în mai multe componente. Astfel,
responasbilitățile sunt împărțite; componentele nu vor cere date de la server în mod direct, ci
aceste acțiuni vor fi delegate serviciilor.

Fig. 1.4 Exemplu de servi ciu din aplicația CollegeFindr î n care am injectat un alt serviciu, CrudServi ce, și am
definit metode care vor apela componenta de back -end a aplicației
Clasele decorate cu @Injectable sunt identificate drept servicii și astfel sunt
generate metadate necesare realizării injectării dependențelor. Injectarea dependențelor (DI –
Depe ndency Injection) este conceptul care ajută la separarea responsabilităților și
modularizarea codului.
1.1.2.4 Pagini HTML (View)
Paginile HTML sunt definite în cadrul componentelor Angular și sunt folosite pentru a
afișa datele calculate de către componenta în s ine. De asemenea, pentru acestea putem defini și
fișiere de definire a stilulilor din pagină (fișiere CSS – Cascading Style Sheets).
Acestea sunt fișiere care conțin etichete HTML obișnuite, dar în care putem injecta
anumite variabile ale căror valori sun t calculate de către componentă și putem stabili ce funcții
să se apeleze atunci când se realizeaz ă o acțiune pe un elemnt HTML (ex. Click pe un buton).
Aceste funcții sunt definite în componentă și sunt scrise în limbajul TypeScript.

14

Fig. 1.5 Exemplu de cod din fișierul dashboard.component.html în care sunt afișate datele definite in
componenta DashboardComponent prin intermediul directivelor Angular (*ngFor, *ngIf, {{}})
1.1.3 TypeScript
Însăși platforma Angular a fost scrisă utilizânt limbajul TypeScript al celor de la
Microsoft, iar dezvoltatorii platformei Angular recomandă de asemenea utilizarea limbajului
TypeScript pentru dezvoltarea aplicațiilor.
Acesta este un limbaj de programare cu sursă deschisă (open -source) creat de către
Microsoft. TypeScript este o extensie a limbajului JavaScript ceea ce înseamnă că orice
program JavaScript vali d este și un program TypeScript v alid. Codul sursă scris în TypeScript
va fi convertit în JavaScript de către un transpila tor.
Acest limbaj folosește paradigme de programare precum programarea structurată,
programarea orientată pe obiecte . Exemple de cod scris în limbajul TypeScript pot fi găsite in
figurile 3, 4 și 5.
1.2 JAVA
Serviciul web al acestei aplicații (API – Applica tion Programming Interface) a fost
dezvoltat utilizând limbajul de programare Java. Versiunea folosită este Java SE (Standard
Edition) 8, lansată în producție la 18 Martie 2014.

15
Java este un limbaj de programare orientată pe obiecte a cărui primă versiun e a fost
lansată în anul 1995. Conceptul acestui limbaj de programare a existat î ncă de la inceputul
anilor ’90 și a fost avansat și implementat de către James Gosling în cadrul Sun Microsystems.
Este cunoscut faptul că Java este unul dintre cele mai folo site limbaje de programare la
nivel global. Acesta este utilizat de aproximativ 10 milioane de programatori, iar platforma Java
rulează pe 15 miliarde de dispozitive pe mapamond. Acestor cifre se adaugă și cele 5 milioane
de studenți care învață Java.
Aceste lucruri sunt demonstrate de un index de popularitate al limbajelor de programare
realizat de compania olandeză TIOBE, bazat pe căutările efectuate de utilizatori în motoarele
de căutare. Într -o reprezentare grafică, precum cea de mai jos, se poate dist inge clar diferența
de popularitate dintre limbajul Java și celelalte limbaje.

Fig. 1.6 Indexul TIOBE Programming Community – rating de popularitate a limbajelor de programare
Java este un limbaj de programa re securizat, simplu de scris și de citit, iar cea mai
importantă calitate a sa este portabilitatea. Programele scrise în limbajul Java pot rula pe orice
tip de platformă sau sistem de operare fiind independent de mediul în care rulează datorită
faptului c ă acestea folosesc o Mașină Virtuală Java (JVM – Java Virtual Machine). Se poate
obține un astfel de nivel de portabilitate (spre deosebire de limbajele mai vechi precum C)
deoarece codul sursă, scris in fișiere cu extensia .java, este compilat de către co mpilatorul javac
intr-un cod de octeți intermediar (bytecode) și sunt create fișiere cu extensia .class. Codul de
octeți rezultat este interpretat de către mașina virtuală și transformat în cod executabil (cod
mașină).

16
Deși Java este un limbaj de programa re derivat din predecesorii săi C și C++ care
suportă atât lucrul cu tipuri de date primitive, cât și cu obiecte, diferențele sunt foarte mari. Spre
exemplu, java nu mai conține atât de multe facilități de nivel jos precum C și C++, i ar tipurile
de date pr imitive, î n Java sunt înfășurate într -o clasa numită „wrapper” care oferă o serie de
funcționalități și operații cu tipul de date respectiv. O diferență majoră este apariția
compilatoarelor î n timp real (JIT – Just In Time) care compilează codul de octeți în cod mașină
la runtime.
De asemena, Java folosește un instrument automat de management al memoriei numit
Garbage Collector. După cum am spus mai devreme, Java oferă mai puține funcționalități de
nivel jos; programatorul poate decide când să se creeze un obiect prin operația de instanțiere,
însă nu poate decide când să se elibereze memoria ocupată de acel obiect. Lucrul acesta este
făcut automat de către Garbage Collector atunci când nu mai există nicio referință către obiectul
respectiv.
1.3 SPRING
Spring este un framework cu sursă deschisă (open -source) dezvoltat de către compania
Pivotal Software a cărui utilizare este cel mai adesea asociată cu aplicațiile scrise în limbajul
Java. Această asociere s -a realizat în ciuda faptului că platforma în sine nu im pune niciun model
de programare specific. Utilizarea Spring în rândul aplicațiilor Java a ajuns până în acel punct
în care a înlocuit API -ul Enterprise JavaBeans (EJB).
Framework -ul Spring reprezintă, de fapt, un proiect care a ajuns la o complexitate
colosală și î ncorporează acum mai multe module, iar termenul Spring are diverse conotații în
funcție de contextul în care este folosit. A folosi Spring într -o aplicație nu înseamnă a folosi
întreaga platformă; aplicațiile pot alege ce module din Spring să fol osească. Printre cele mai
importante funcționalități amintim:
 Spring Inversion of Control Container – Inversion of Control este un principiu care
spune că blocuri de cod dintr -o aplicație sunt rulate de către o platformă generică. În
contextul unei aplica ții dezvoltate cu sprijinul platformei Spring, obiectele care
formează „scheletul” aplicației se numesc beans , iar containerul IoC este cel care este
responsabil de managementul ciclului lor de viață. Configurarea acestor bean -uri se
poate defini atât prin utilizarea fișierelor XML, cât și utilizând adnotări Java.

17
 Mecanismul de injectare a dependen țelor (DI – Dependency Injection) – este un
mecanism pr in care se realizează legături î ntre bean -uri fără de care aplicația nu va
funcționa . Marele avantaj al ace stui mecanism este separarea responsabilităților și
modularizarea codului.
 Framework -ul de acces la baza de date – este menit să reducă din configurările pe care
un dezvoltator ar trebui să le facă atunci când aplicația are nevoie de acces l a o bază de
date. Acesta asigură suport pentru și se integrează foarte ușor cu alte framework -uri de
acces la baza de date precum: JPA (Java Persistence API), JDBC, Hibernate, etc.
 Programarea orientată pe aspecte (AOP – Aspect Oriented Programming) – acest
framework din cadrul Spring manageriază funcționalități cu o întindere pe toată
aplicația cu scopul de a le separa de logica aplicației: tratarea erorilor, validarea
obiectelor, managementul tranzactiilor, etc.
 Spring Security – acest modul conține mecanisme de filtrar e, autentificare și autorizare
a cererilor primite de serviciul web .
Acestea sunt doar câteva dintre funcționalitățile framework -ului Spring, însă le -am
detaliat doar pe acestea deoarece sunt cele folosite în dezvoltarea aplicației CollegeFindr.
Configurar ea framework -ului Spring nu este ceva ce se realizează ușor, iar mulți
programatori se împotmolesc de multe ori în astfel de lucruri. Problema pe care o întâlnim aici
și trebuie rezolvată este convenție înainte de configurare (convention -over-configuration ).
Aceasta e ste o paradigmă în domeniul dezvoltării software folosită intensiv de către
framework -uri și are ca scop minimizarea deciziilor pe care programatorii trebuie să le ia atunci
când folosește framework -ul respectiv. Este o graniță destul de fin ă aici, totuși, deoarece
dezvoltatorii trebuie să aibă în continuare flexibilitate în utilizarea framework -ului.
1.3.1 Spring Boot
Soluția propusă de Spring pentru astfel de probleme este Spring Boot, o implementare
a conceptului de convenție înainte de config urare (convention -over-configuration).
Folosirea Spring Boot î ntr-o aplicație web conferă un avantaj m ajor datorită faptului că
acest a configureaza mediul Spring cu valori impli cite, dar care pot fi ușor supr ascrise și
personalizate în funcție de nevoile programatorului. Astfel, devine foarte ușor să creă m și să
pornim o aplicație; Spring Boot are încorporat și un server Tomcat pentru rulare locala – deci
nu este nevoie s ă o publicăm aplicația undeva pentru a o putea accesa.

18
Folosirea Spring Boot se reduc e astfel, la adnotarea clasei principale (cea care conține
metoda principală (main)) cu @SpringBootApplication, iar metoda main să apeleze
metoda run a clasei SpringApplication căreia îi pasează ca argumente clasa principală a
aplicației și argumentele pri mite de metoda main.

Fig. 1.7 Utilizarea Spring Boot în CollegeFindr adnotând cu @SpringBootApplication clasa principală
@SpringBootApplication este echivalentă cu utilizarea următoarelor trei
adnotări:
 @EnableAutoConfiguration – Spring va adăuga configurările necesare cu
valorile implicite .
 @ComponentScan – va scana întreg pachetul specificat pentru a crea bean -uri pentru
clasele adnotate cu un stereotip echivalent cu @Component .
 @Configuration – permite de zvoltatorilor să definească bean -uri proprii sau să
importe alte fișere de configurare .
Pentru a expune puncte de acces peste protocolul HTTP în serviciul web creat trebuie
să specificăm care sunt clasele care joacă rol de controler. Pentru asta, Spring Bo ot pune la
dispoziție adnotarea @RestController , un stereotip cu ajutorul căruia Spring va ști că acea
clasă poate manipula cereri făcute peste HTTP.
De asemenea, trebuie specificate căi (paths – URL) prin intermediul adnotării
@RequestMapping astfel încâ t cererile HTTP către calea respectivă să fie procesate de
anumite controlere. Împreună cu definirea unei mapări și a unui verb HTTP la nivel de metodă,
cererile pot fi direcționate precis.
În următorul exemplu ( Fig. 1.8 Exemplu de controller în aplicația CollegeFindr , clasa
DashboardController este considerată controller de către Spring deoarece conține
adnotarea @RestController . Mai mult decât atât, cererile care vor conține ca și cale de
bază /dashboard , for fi direcționate căt re acest controller, și deoarece metoda
getDashboardForUser este adnotată la rândul ei cu @GetMapping fără a mai adauga o

19
cale suplimentară față de cea de bază, cererile de tip GET pe calea /dashboard vor fi
procesate de această metodă.
Tot în acest exem plu putem observa cum se poate realiza injectarea dependențelor în
componentele unei aplicații: câmpul privat dashboardService adnotat cu @Autowired
este un alt bean din aplicație care va fi injectat în controller de către către containerul Inversion
of Co ntrol al Spring -ului.

Fig. 1.8 Exemplu de controller în aplicația CollegeFindr
Voi exemplifica în continuare alte modalități de a folosi adnotările de mapare puse la
dispoziție de framework -ul Spring . În plu s, sunt exemplificate și utilizări ale adnotărilor prin
intermediul cărora definim ce date poate primi metoda respectivă și adnotări pentru a indica
framework -ului Spring AOP să valideze anumiți parametri.

Fig. 1.9 Exemple de metode din controlle r
 @RequestBody – specifică tipul de date care poate fi trimis serviciului în corpul
cererii.
 @PathVariable – specifică tipul de date care poate fi trimis serviciului prin
intermediul căii; o cale definită /questions/{ questionId} va accepta cereri
care au în URL un număr în locul {questionId} , convertit mai apoi la tipul Long .

20
 @Valid – este o adnotare care folosește Programarea Orientată pe Aspecte (AOP) în
sensul în care, în cazul unei cereri pe calea respectiva, cerer ea va fi interceptată de un
proxy și va fi trimisă către un validator înainte a intra în metoda respectivă (înainte de
începe execuția metodei). P arametrul respectiv va fi validat în co ncordanță cu restricțiile
impuse .

Fig. 1.10 Exemplu de adnotări de validare a câmpurilor unui obiect
1.3.2 Spring Security
Framework -ul Spring Securi ty oferă funcționalități de prot ejare a aplicațiilor împotriva
accesării conținutului de către persoane neautorizate . Funcționalitățile oferite de acesta sunt atât
autentificarea, cât și autorizarea cererilor. Framework -ul poate fi configurat în așa fel încât să
poată îndeplini cerințe personalizate.
În materie de autentificare, Spring Security asigură suport pentru o varietate largă de
scheme de autentificare. Ac este scheme de autentificare fie sunt create de părți terțe, fie sunt
dezvoltate de organisme acr editate, fie reprezintă o schemă proprie.
Pentru aplicația CollegeFindr am ales utilizare schemei de autentificare bazată pe JWT
(JSON Web Token) .
1.3.2.1 Autentificare bazată pe JWT
JWT (JSON Web Token) este un standard ce definește o metodă de a transmite p rin
intermediul obiectelor JSON a datelor sensibile , peste rețea. Securitatea constă în faptul că
aceste a conțin o semnătură digitală (r ealizată fie printr -o schemă de criptare cu cheie secretă
precum HMAC, fie prin intermediul unei scheme de criptare cu perechi de chei public -secret
precum RSA).
Un JWT reprezintă o structură de trei părți separate printr -un punct:
header.payload.signatu re. Acesta este creat atunci când un utilizator trimite credențialele

21
pentru autentificare către server. Server -ul verifică existența utilizatorului și corectitudinea
datelor, generează și trimite tokenul înapoi către aplicația -client.
Aceasta din urmă poa te stoca token -ul primit în depozitul local pentru a -l utiliza în cereri
ulterioare cu scopul de a se autentifica. Mai precis, va trebui să construiască, cu ajutorul schemei
Bearer o valoare de tipul Bearer <token> pe care o va pune în header -ul Authorizat ion.
Ulterior, la fiecare nouă cere, server -ul va verifica existența unui token în header -ul
Authorization și verifică tokenul primit în vederea validării sau invalidării cererii de acces la
resurse.

Fig. 1.11 Schema de autentificare bazata pe JWT
Pentru a obține o filtrare a cererilor venite spre serviciul web și o protecție a datelor
aplicației este necesar să configurăm contextul Spring în așa fel încât să aplice un filtru de
autentificare pe fiecare cerer e. Opțional, se pot menționa căi pentru care nu se va aplica acest
filtru.

Fig. 1.12 Implementarea Spring Security, specificarea filtrului de autentificare și a căilor exceptate

22

Ulterior, filtrul trebuie să poată extrage token -ul din header -ul cererii și să îl valideze.

Fig. 1.13 Filtrul de autentificare pe baz a unui JWT
De asemenea, tot în materie de securitate, parolele utilizatorilor nu sunt stocate în clar
în baza de date; pentru acest lucru am folosit o funcție hash din framework -ul Spring Security
numită BCrypt. Pentru a utiliza această funcționalitate este necesar să definim manual un bean
de tipul PasswordEncoder care să instanțieze un encoder de tipul Bcrypt .

Fig. 1.14 Exemplu de creare a unui bean pentru funcții hash, Bcrypt
Acest bean poate fi injectat în alte componente și putem folosi metoda encode() a acestui
obiect pentru a aplica funcția hash pe pa role, spre exemplu, la crearea unui nou cont de
utilizator.

Fig. 1.15 Exemplu de utilizare a funcției hash pe parole

23

Fig. 1.16 Exemplu de parole stocate criptat în baza de date
O altă funcționalitate foarte importantă legată de securitatea aplicației este protejarea
punctelor de acces din serviciul web, în așa fel încât chiar dacă cineva încearcă să acceseze
resurse protejate apelând direct serviciul web să nu r eușească. Acest lucru este obținut prin
intermediul adontării @PreAuthorize din framework -ul Spring Security.

Fig. 1.17 Exemplu de autorizare selectivă în back -end
Ca o măsură de siguranță suplimentară, aces t lucru este realizat și în aplicația Angular
prin intermediul unui așa -numit Guard care verifică nivelul de autoritate a utilizatorului logat.

Fig. 1.18 Exemplu de autorizare selectivă în front -end
1.3.3 Spring Da ta JPA
În descrierea generică a framework -ului Spring am menționat că una dintre
funcționalitățile importante este framework -ul de acces la baza de date. Această tehnologie
permite definirea unor interfețe speciale numite depozite prin intermediul cărora putem interoga
si manipula datele din baza de date. Scopul Spring D ata JPA este de a reduce codul redundant
și irelevant necesar implementării unui nivel de acces la baza de date.
Modulul JPA din Spring Data permite crearea de bean -uri pentru depozitele n oastre prin
utilizarea interfeței predefinite JpaRepository .

24
Primul pas este de a configura contextul Spring în așa fel încât să putem utiliza aceste
depozite. Acest lucru se realizează prin adnotarea cu @EnableJpaRepositories a clasei
de configurare (o clasă de configurare poate fi orice clasă care este adnotată cu
@Configuration ).

Fig. 1.19 Exemplu de configurare a Spring Data JPA în aplicația CollegeFindr
Apoi, pentru a defini un depozit JPA este necesar să definim o interfață Java care să
extindă interfața predefinită JpaRepository <T, ID> (care va fi specializată în funcție de
tipul obiectelor manipulate). Deoarece JpaRepository extinde interfața
CrudReporitory , vom beneficia și de toate operațiile CRUD (Create, Read, Update,
Delete) deja implementate. Mai mult decât atât, framework -ul spring va crea și un bean pentru
această interfață, ceea ce înseamnă că o vom putea injecta în alte componente.

Fig. 1.20 Exemplu de definire a unui depozit JPA în aplicația CollegeFindr
Avantajul major pentru care am folosit această tehnologie este ușurința cu care se pot
scrie interogările. Spring Data JPA poate translata numele unor metode în interogări SQL
utilizând câtev a cuvinte cheie: And, Or, IsAfter, Before, C ontains, Exists, IsIn, Like, etc.

Fig. 1.21 Exemple de interogări utilizând Spring Data JPA
Totuși, pot apărea inconveniențe atunci când este necesar să definim in terogări mai
complexe; fie numele metodelor for arăta destul de urât, fie framework -ul nu poate face
operațiile dorite. Soluția Spring Data JPA pentru această problemă este așa numitul native
query. Scrierea unei astfel de interogări se realizează prin adn otarea metodei din depozit cu
@Query și introducerea interogării în SQ L ca parametru pentru adnotare.
Am integrat această tehnologie în cadrul aplicației datorită utilității prezentate, însă
pentru a defini interogări mai complexe nu am folosit interogăril e native pentru a nu introduce
cod SQL în sursa aplicației, ci am recurs la a utiliza API -ul JPA Criteria.

25
1.4 JPA CRITERIA API
La nivel general, JPA (Java Persistence API) reprezintă un pachet de metode ce pot fi
utilizate pentru a manipula date relaționale în aplicații Java. În mod concre t, Criteria API
asigură o metodă alternativă de a defini interogări către baza de date. Interogările astfel scrise
pot fi construite dinamic, de o complexitate mare, iar structura lor nu este cunoscută decât la
runtime.
Pentru a crea ast fel de interogări este necesar să definim o structură de clase specială,
după cum urmează:
 O interfață simplă care să conțin ă definițiile metodelor în care vor fi scrise interogările.
Este important ca numele ace steia să aibă sufixul Custom.

Fig. 1.22 Exemplu de interfață pentru definirea interogărilor complexe
 O clasă care să implementeze interfața anterior definită și să suprascrie metodele ei. În
această clasă definim și un manager de entităț i și îi asociem un context de persistență.

Fig. 1.23 Exemplu de implementare a clasei în care construim interogări complexe
 Definim o interfață care va extinde interfața în care am specificat definițiile meto delor
pentru crearea interogărilor complexe. De asemenea, putem extinde si
CrudRepository , spre exemplu, pentru a avea la dispoziție si operații CRUD asupra
bazei de date. Spring va crea un bean pentru această interfață și aceasta poate fi injectată
acum î n alte componente pentru a utiliza interogările nou definite.

Fig. 1.24 Exemplu de definire a unui depozit ce reunește interogările nou definite și operațiile clasice CRUD
În continuare voi arăta cum se pot crea interogări folosind Criteria API:

26

Fig. 1.25 Exemplu de creare a interogărilor complexe utilizând Criteria API
Codul Java de mai sus reprezintă o interogare ce realizează operația de JOIN peste trei
tabele pentru a selecta anumite date. Traducerea în limbaj SQL a acestei interogări, ținând cont
de numele de tabele utilizate în aplicație, este următoarea:

Fig. 1.26 Traducerea în SQL a interogării create cu Cr iteria API
1.5 HIBERNATE
A integra o aplicație scrisă după modelul orientat -obiect cu o baz ă de date relațională
poate fi destul de anevoios și consumator de timp. Probleme apar atunci când tipurile de date
ale obiectelor din program nu se potrivesc cu tipuri le de date ale bazei de date. Atunci când este
vorba despre o aplicație Java, este recomandată folosire unei tehnologii care să fie compatibilă
cu specificațiile Java Persistence API (JPA) .
Hibernate este soluția celor de la Red Hat pentru astfel de probl eme în aplicații Java;
este un Object/Relational Mapper (ORM). Cu alte cuvinte, framework -ul are mecanisme prin
care mapează obiecte Java peste tabele din baza de date și tipuri de date Java peste tipuri de
date SQL.

27
Până la versiunea 5.2, Hibernate oferea și soluții de interogare a bazelor de date prin
intermediul Hibernate Criteria API, însă această funcționalitate nu mai este menținută de către
echipă și este recomandată utilizarea JPA Criteria API descrisă anterior.
Mapările explicate anterior se pot re aliza atât prin adnotări la nivel de clasă sau câmp al
clasei, cât și prin fișiere de configurare XML, însă este recomandată prima opțiune.
Câteva dintre adnotările puse la dispoziție de Hibernate și utilizate în aplicație sunt:
 @Entity – identifică și ma pează drept entitate a baezei de date clasa adnotată.
 @Table – specifică numele efectiv al tabelului din baza de date.
 @Id – marchează câmpul adnotat drept cheie primară.
 @GeneratedValue – asigură o strategie de generare a valorilor pentru câmpul
adnotat.
 @SequenceGenerator – definește un generator de valori pentru cheia primară
 @Column – specifică numele efectiv al coloanei peste care este mapat câmpul adnotat.
 @ManyToOne – specifică o relație de tipul many -to-one.
 @OneToMany – specifică o relație de tipul one-to-many.

Fig. 1.27 Exemplu de folosire a adnotărilor oferite de Hibernate pentru maparea entităților

28
1.6 MAVEN
Pentru automatizarea build -ului în aplicația CollegeFindr am folosit o soluție software
oferită de Apache Software Foundation.
Maven este o unealtă ce tratează două probleme întâlnite în crearea de programe
software: descrierea modului în care se face build -ul și descrierea dependențelor aplicației în
cauză. Aceasta este, poate , cea mai folosită un ealtă de acest tip în proiectele Java. Maven are la
bază conceptul de Project Object Model (POM) prin intermediul căruia putem configura și
rezolva problemele dscrise anterior.

Fig. 1.28 Exemplu de configura re Maven în care specificăm grupul, artifactul, versiunea aplicției și părintele de
la care va moșteni alte configurații (în cazul de față, vrem sa obținem configurații pentru un proiect Spring
Boot)
Mai precis, Maven folosește un fișier XML, cu numele st andard pom.xml , în care
introducem detalii despre aplicație (nume, versiune, grup, artefact, etc.), strategia de build și
dependențele aplicației.
Atunci când vrem să folosim alte librării în aplicația noastră Java, integrarea lor nu este
un lucru tocmai ușor sau eficient deoarece acest lucru ar însemna includerea lor manual în toate
aplicațiile care au nevoie de acea librărie și, în plus, este dific il să ținem pasul cu ultima versiune
a librăriei respective. Maven dispune de o soluție automată de mangement al dependențelor,
descărcând librăriile specificate în fișierul pom.xml din depozitul MvnRepository sau din alte
depozite. Tot ce trebuie să facă programatorul este să adauge dependențele necesare în fișierul
pom.xml ; restul cade în sarcina Maven.

29

Fig. 1.29 Exemplu de include re a depenențelor pentru Spring Boot, Spring Security, Spring Data JPA , JWT în
aplicație prin intermediul fișierului pom.xml procesat de Maven
Utilizarea Maven în aplicația CollegeFindr a făcut ca procesele de build și management
al dependențelor să se desfășoare rapid, sigur și eficient.
1.7 BAZA DE DATE
Pentru a gestiona datele maip ulate de aplicație și relațiile dintre acestea, am ales un
sistem de gestiune a bazelor de date oferit de compania Oracle.
1.7.1 Oracle
Oracle Database (Oracle DB) este un sistem de gestiune a bazelor de date relaționale
(Oracle RDBMS) dezvoltat în 1977 de cătr e o echipă de dezvoltatori condusă de Larry Ellison.
Bazele de date Oracle sunt cele mai folosite baze de date de acest tip din întreaga lume și sunt
recunoscute pentru s iguranța oferită datelor stocate, posibilitățile de scalare, procesarea datelor
în tra nzacții online (OLTP – Online Transaction Processing), stocarea unor volume de date
masive (DW – Data Warehousing) și combinații de astfel de procese. Sistemul este contstruit
după modelul bazelor de date relaționale, iar datele stocate pot fi accesate de oricine sau pot fi
protejate, sistemul permițând, de asemenea, să definească drepturi de acces asupra datelor.

30
Datele pot fi accesate și manipulate prin intermediul unui limbaj de interograre
structurat (SQL – Structured Quert Language). Acest limbaj est e folosit pentru manipularea
datelor structurate precum cele stocate în baze de date relaționale.
1.7.2 Utilizator al bazei de date și stabilirea conexiunilor
Pentru crearea tabelelor și accesarea manuală a datelor am folosit o soluție software
oferită tot de O racle, Sql Developer , ceea ce a făcut munca cu baza de date mult mai ușoară și
plăcută.
După cum am spus, SGBD -ul Oracle permite și crearea de utilizatori și stabilirea
privilegiilor de acces. Pentru aplicația CollegeFindr am creat un utilizator pentru baz a de date,
din motive evidente de securitate.

Fig. 1.30 Utilizatorul creat pentru aplicația ColegeFindr
Stabilirea conexiunii din aplicație către baza de date este realizată de către Spring.
Acesta are nevo ie de un driver Oracle ca DataSource , compatibil cu API -ul de acces la baza de
date, JDBC (Java Database Connectivity), pentru a stabili această conexiune .
De asemenea aplicația trebuie să cunoască locația bazei de date, numele de utilizator cu
care se co nectează și parola contului asociat. Pentru managementul conexiunilor am folosit
Hikari Connection Pool , ceea ce a optimizat performanțele de acces la baza de date prin
stabilirea și reutilizarea conexiunilor.

Fig. 1.31 Configurațiile pentru acces la baza de date din fișierul application.yml

31
1.8 PROLOG
La începutul lucrării am menționat existența unui algoritm care oferă ca răspuns
facultatea cea mai potrivită pentru elev pe baza raspunsurilor la o serie de într ebări.
Acest lucru a fost posibil utilizând un alt fel de limbaj de programare, care folosește
paradigma de programare logică și este asociat adesea cu inteligența artificială. Logica unui
program prolo g este structurată în jurul definirii unor relații r eprezentate ca fapte și reguli.
Prolog este unul dintre primele limbaje de programare logică și este utilizat și astăzi în
construirea sistemelor expert, demonstrarea teoremelor, planificare automată, ș.a.
Persoana recunoscută pentru conducerea acțiunil or în direcția dezvoltării acestui limbaj
este Alain Colmerauer la începutul anilor ’70, iar domeniul pentru care a fost conceput este cel
de procesare a limbajului natural.
Pentru a obține ceea ce mi -am propus ca scop al acestei aplicații a fost necesar să creez
un sistem exper t.
1.8.1 Sistem Expert
Scopul unui sistem expert este acela de a simula gândirea unei persoane experte într -un
anumit domeniu. Acesta trebuie să fie capabil să ia anumite decizii în funcție de faptele pe care
le cunoaște într -un anumit moment. Sistemele expert au reprezentat primele aplicații de
inteligență artificială în adevăratul sens al cuvântului .
Sistemele expert sunt proiectate, în general, pentru a rezolva probleme complexe car e,
de altfel, ar fi extrem de dificil de rezolvat p rin programe scrise după paradigma progarmării
procedurale. Acestea se chidează după reguli de tipul daca -atunci și sunt compuse din două
mari componente: mecanismul de inferență și baza de cunoștințe ; baza de cunoștințe reprezintă
mulțimea faptelor și reg ulilor cunoscute de sistemul expert, iar mecanismul de inferență aplică
regulile definte pe faptele cunoscute pentru a deduce noi fapte.
Regulile, faptele și scopul sistemului expert sunt stocate în fișiere text simple pe care le
va citi pentru a le stoc a în memoria programului. Acestea sunt scrise într -un limbaj destul de
apropiat limbajului uman, iar sistemul expert îl va interpreta și va extrage datele necesare.

32

Fig. 1.32 Exemplu de reguli și fapte folosi te de sistemul expert
Soluțiile sistemului expert sunt de asemenea stocate într -un fișier și vor fi selectate în
funcție de abrevierea lor pentru a fi afișate utilizatorului.

Fig. 1.33 Exemplu de soluție a s istemului expert

33
2 ARHITECTURA APLICAȚIE I
În ziua de astăzi exisă o multitudine de modele arhitecturale care pot fi aplicate în
dezvoltarea soluțiilor software. Pentru a alege cel mai potrivit tip de arhitectură, astfel încât
aplicația să funcționeze efici ent și sigur, o analiză a cerințelor și a resurselor de care dispune
echipa de dezvoltare este obligatorie.
2.1 ARHITECTURI SOFTWARE FRE CVENTE
O arhitecrură a unei aplicații web reprezintă o strategie de implementare a logicii de
business și trebuie să defin ească modul în care componentele aplicației comunică între ele. Voi
enumera în continuare câteva dintre cele mai folosite arhitecturi software:
 Arhitectură client -server pe N niveluri
 Arhitectură cu coadă de mesaje
 Arhitectură de tip publică -subscrie
 Arhitectură de tip broker
 Arhitectură cu coordonator de procese
 Arhitectură MVC (Model – View – Controller)
 Arhitectură cu microservicii
 Arhitectură P2P (Peer -to-Peer)
2.2 CLIENT -SERVER
Arhitectura client -server este caracteristică aplicațiilor distribuite în car e rolurile sunt
separate în două categorii: aplicații care oferă resurse la cerere (server) și aplicații care fac creri
către server (client). Întotdeauna, clienții vor fi cei care inițiază o sesiune de comunicare cu un
server, niciodată invers, iar comuni carea se face, de cele mi multe ori, peste o rețea; cazurile în
care atât clientul cât și server -ul rulează pe același sistem sunt foarte puține.
2.3 CLIENT -SERVER PE TREI NIVELURI ÎN COLLEGE FINDR
Arhitecturile client -server pot fi definite pe mai multe nivelu ri între care există o
comunicare strânsă. La modul general, o astfel de arhitectură se numește arhitectură pe N
niveluri (n -tire). În astfel de cazuri responsabilitățile se separă mai adânc și obținem o decuplare
puternică. Cel mai folosit mod el este cel pe 3 niveluri, prezent și în aplicația CollegeFindr.

34

Fig. 2.1 Arhitectura client -server pe 3 niveluri a aplicației CollegeFindr
Aplicația în discuție în prezenta lucrare a fost împărțită în trei niveluri a c ăror
responsbilitate este după cum urmează:
 Nivelul 1, de prezentare, este cel care definește interfața aplicației ca întreg cu
utilizatorii finali. Pentru acest lucru am implementat o aplicație separată pentru partea
de front -end utilizând framework -ul An gular. Beneficiile acestei alegeri au fost
discutate în capitoul II. Tehnologii utilizate , subcapitolul Angular . Printre
resposabilitățile acestei aplicații sunt: formularea de cereri către server în vederea
obținerii datelor necesare, afișarea datelor înt r-o manieră prietenoasă cu utilizatorii,
trimiterea de date introduse de utilizatori către server și efectuarea unor validări
preliminare asupra lor.
 Nivelul 2 , al logicii de business, este nivelul la care se realizează procesarea și validarea
intensivă a datelor. Tot la acest nivel se realizează și autentificarea utilizatorilor, astfel
încât să nu oferim acces la datele aplicației unor persoane nedorite. Nivelul 2, în cazul
de față este compus din două co mponente care comunică strâns: serviciul web Java cu
Spring Boot și algoritmul Prolog al sistemului expert. Trebuie notată o observație
importantă: sistemul expert nu comunică direct nici cu baza de date și nici cu aplicația

35
Angular din Nivelul 1 , ci întotdeauna prin intermediul API -ului Java ; acesta este, deci,
punctul central de acces la aplicație. Serviciul web împreună cu sistemul expert rulează
pe un server separat , accesibil clienților.
 Nivelul 3, al bazei de date, este nivelul care oferă acces la datele aplicației. La aces t
nivel se introduc noi mecan isme de validare și securizare a datelor. Mai exact, datele și
relațiile dintre ele pot fi validate la acest nivel prin definirea unor constrângeri pe
coloanele tabelelor. În materie de securitate, datele sunt protejate prin crearea tabelelor
în schema unu i utilizator și oferirea drepturilor de acces și manipulare doar acelui
utilizator. Câteva informații suplimentare legate de aces t subiect se regăsesc și în
secțiunea Utilizator al bazei de date și stabilirea conexiunilor din subcapitolul Baza de
Date al capitolului II. Tehnologii utilizate. Baza de date rulează pe un server separat,
de baze de date, accesibil seviciului web din Nivelul 2.
Abordarea unei astfel de arhitecturi prezintă câteva avantaje importante care m -au
motivat să utilizez acest model arhi tectural:
 Un avantaj important legat de securitatea aplicației este faptul că se poate controla foarte
bine accesul la baza de date, eliminându -se riscul pătrunderii persoanelor neautorizate
în datele aplicației. Dacă am fi eliminat Nivelul 2, cel în care este definit serviciul web,
ar fi însemnat că aplicația client ar fi trebuit să dețină credențialele de conectare la baza
de date ceea ce ar fi diminuat nivelul de securitate al aplicației; dacă cineva ar fi reușit
să citească fișierele sursă prind decompi lare, sau alte metode, ar fi obținut și
credențialele de conectare la baza de date.
 Oferă posibilități de extindere prin crearea de noi aplicații client pentru alte sisteme sau
platforme (alte platforme web, mobile, desktop, etc.)
 Asigură o cuplare slabă î ntre client și restul arhitecturii: o schimbare la nivel de bază de
date sau serviciu web ar implica doar schimbarea bazei de date respectiv serviciului web
(sau ambele dacă situația o impune) dar nu și schimbarea clienților.
2.4 ARHITECTURA BAZEI DE DATE
Voi prezenta în continuare arhitectura bazei de date folosite de aplicație și câteva
explicații succinte în legătură cu aceasta.

36

Fig. 2.2 Diagrama entitate -relație a bazei de date
După cum se poate observa în Fig. 2.2, baza de date este formată din 5 tabele principale
și 2 tabele de legătură, unul dintre ele neavând nicio legătură cu niciun alt tabel:
 APPLICATION_USERS – este tabela în care sunt stocați untilizatorii aplicației; o
intrare în această tabelă reprezintă un utilizator al aplcației. Pentru utilizatori am definit
următoarele câmpuri: AU_ID – un identificator unic, AU_USERNAME – numele de
utilizator cu care se poate autentifica în aplicație (este unic pentru fiecare utilizator) ,
AU_PASSWORD – parola cu care se poate autentifica în aplicație,
AU_FIRST_NAME, AU_LAST_NAME, AU_EMAIL – diverse date personale,
AU_AUTHORYTY – un câmp cu ajutorul căruia stabilim nivelul de autoritate al
utilizatorului.
 QUIZZES – stochează testele care a u fost făcute de -a lungul timpului de către
utilizatori: QZ_ID – identificator uni c, QZ_DATE data la care s -a făcut testul,
QZ_U_ID – id-ul utilizatorului care a făcut testul (cheie străină către
APPLICATION_USERS).
 QUESTIONS – tabela care stochează întreb ările ce pot apărea într -un test: Q_ID –
identificatorul unic, Q_TEXT – întrebarea efectivă, Q_ANSWER_OPTIONS – un șir

37
de variante de răspuns posibile pentru întrebarea respectivă, Q_SHORTHAND_NAME
– o prescurtare sugestivă a întrbării , utilizată de sistem ul expert.
 QUIZZ_STRUCTURES – o tabelă de legătură între QUIZZES și QUESTIONS care
mapează testele efectuate cu întrebările care au fost pus e în acel test rezolvându -se astfel
relația many -to-many apărută între cele două tabele: „un test trebuie să conțină una sau
mai multe întrebări, iar o întrebare poate apărea în unul sau mai multe teste”.
 SOLUTIONS – tabela în care regăsim soluțiile posibile ale sistemului expert.
Câmpurile acestei tabele conțin diverse informații despre facultățile din sistem: numele
universității, numele facultății, al specializării, descriere, adresă către pagina web a
facultății, etc.
 QUIZZ_RESULTS – este o tabelă de legătură între SOLUTIONS și QUIZZES menită
să rezolve relația many -to-many apărută între aceste două entități: „o solu ție poate
apărea într -unul sau mai multe teste, iar un test poate oferi una sau mai multe soluții”.
 APPLICATION_RULES – această tabelă stochează regulile utilizate de sistemul expert
și de aceea nu este definită nicio relație cu alte entități. AR_PREMISES – premisele
unei reguli (condițiile), AR_CONCLUSION – concluzia unei reguli.
2.5 ARHITECTURA SERVICIUL UI WEB
Așa cum am explicat și exemplificat de-a lungul lucrării, pentru partea de back -end am
implementat o aplicație separată care să joace rolul de server. Această aplicație este un serviciu
web care se conformează stilului arhitectural REST (REpresentational State Transfer).
REST reprezintă un stil arhitectural pentru servicii web ce definește o serie de
proprietăți și constrângeri pe care un serviciu web trebuie să le satisfacă astfel încât acesta să
fie clasificat drept serviciu web RESTful (RESTful API). La baza acestui concept stă protocolul
web HTTP care oferă o serie de operații care pot fi efectuate: GET, POST, PUT, DELETE, etc.
(numite verbe HTTP). Serviciile web RESTful trebuie să ofere resurse pe care alte aplicații să
le poată manipula și accesa prin intermediul unui identificator unic (URL – Uniform Resource
Locator). La rândul său, serviciul web va răspunde cu o reprezentare textuală a resursei
respective (sau rezultatul oper ației inițiate) într -un anumit format: HTML, XML, JSON, etc. În
mod uzual este folosit formatul JSON (JavaScript Object Notation).
Constrângerile impuse de stilul arhitectural REST sunt:
 Aplicația trebuie să fie de tip clien t-server.

38
 Orice cerere trimisă spre procesare către API trebuie să conțină toate informațiile
necesare; serviciul web nu trebuie să rețină informații despre starea clientului.
 Trebuie să se memoreze în cache anumite informații/răspunsuri, astfel încât
interacțiunile dintre clienți și server să fie cât mai puține.
 Un client nu trebuie să știe dacă acesta este conectat direct la server sau dacă a intervenit
o parte terță (load balancer) între aceștia.
 Clienții și server -ul trebuie s ă folosească o interfață co mună: identificarea resurselor
cerute și acțiunilor efectuate prin URI (Uniform Resource Identifier) și verbe HTTP ,
modificarea resurselor de către client dacă are o reprezentare a acesteia (diferită față de
reprezentarea internă a server -ului), trimiterea unor mesaje clare către clienți și
posibilitatea de a trimite link -uri dinamice către clienți (care nu cunosc logica și
dinamica serviciului).
Aplicația CollegeFindr respectă aceste condiții și folosește URL -uri unice împreună cu
verbele HTTP GET, POST, P UT, DELETE pentru accesarea si manipularea resurselor și
formatul JSON pentru comunicarea între componente.
2.5.1 Ierarhia de clase
De-a lungul capitolului Tehnologii utilizate am dat și exemple de clase și dependen țe
între acestea. Datorită faptului că am folosit framew ork-ul Spring pentru injectarea
dependen țelor, toate clasele din aplicație sunt strâns interdependente, iar distrugerea uneia
dintre ele duce la distrugerea întrgului context; clasele formează relații de c ompoziție. Ierarhia
de clase peste întregul proiect este stufoasă deoarece a fost nevoie de crearea unui număr
semnificativ de clase .

Fig. 2.3 Ieraria de clase din serviciul web

39
Explicarea ierarhiei de clase prezentată mai sus ar fi destul de greoaie, însă am
exemplificat printr -o diagramă generată de IDE -ul IntelliJ IDEA a mploarea dependențelor,
pentru a avea o imagine de ansamblu.
Voi oferi, totuși, un exemplu clasic de ierarhie/ dependen țe între clase ce se găsește în
majoritate a serviciilor web, până la aplicațiile enterprise: o irarh ie pe trei niveluri formată dintr –
o clasă de tip controller care oferă puncte de acces în aplicație, o clasă de tip service care
implementează logica aplicației și o clasă de ti p depozit care oferă căi de interacțiune cu baza
de date. Deoarece tabela pentru stocarea regulilor nu are definite relații cu alte entități în baza
de date, ierarhia generată în acest caz este asemănătoare cu cea exemplificată mai devreme.
Există o difere nță minimă, totuși: componenta de acces la baza de date trebuie să extindă
componenta predefinită în framework -ul Spring Data JPA pentru a beneficia de metodele deja
implementate de acces și manipulare a datelor.

Fig. 2.4 Exemplu clasic de ierarhie de clase
În aplicaț ia CollegeFindr lucrurile pot lua o turnură destul de „nefastă”. Voi exemplifica,
pentru a demonstra complexitatea, ierarhia pentru clasele necesare comunicării dintre serviciul
web și programul prolog:

40

Fig. 2.5 Ierarhie de clase pentru comunicarea cu prolog (partea 1)

Fig. 2.6 Ierarhie de clase pentru comunicara prolog (partea 2)

41
2.6 ARHITECTURA APLICAȚIE I-CLIENT
Aplciația -client, fiind o aplicație Angular, nu reprezintă altceva decât o ierarhie de
module, componente și servicii a căror implementare și orchestrare reprezintă funcționalitățile
aplicației. În capitolul Tehnologii utilizate , subcapitolul Angular conține mai multe detalii
despre ceea ce presupune implementarea unei aplicații angular și secvențe de cod sugestive din
aplicație.

Fig. 2.7 Ierarhia de componente a aplicației -client

2.7 CAZURI DE UTILIZARE
În cele ce urmează voi prezenta sub forma unor diagrame UML (Unified Modeling
Language) cazurile de utilizre ale aplicației.

42
2.7.1 Înregistrare

Fig. 2.8 Diagrama UML pentru înregistrare
În cazul înregistrării, utilizatorul trebuie sa introducă datele pentru a crea un cont. Datele
vor fi validate de către server, iar dacă acestea sunt valide sau contul nu există deja, înregistrarea
se realizează cu succes. Altfel, se trimite un mesaj de eroare.
2.7.2 Autentificare

Fig. 2.9 Diagrama UML pentru autentificare
Pentru autentificare, utilizatorul va încerca să acceseze aplicația folosind un set d e
credențiale nume de utilizator – parolă . Acestea vor fi validate de către server, iar dacă validarea
a eșuat sau utilizatorul este inexistent, se va trimite un mesaj de eroare. Mai mult decât atât, în
acest caz va trebui să se înregistreze.

43
2.7.3 Editare profi l

Fig. 2.10 Diagrama UML pentru editarea profilului
Un utilizator poate să își actualizeze datele cu care s -a înregistrat (nume, prenume și
adresă de email) sau își poate schimba parola. Pentru aceasta va tr ebui să acceseze pagina
profilului său și să introducă noile date. Acestea vor fi validate și serverul va trimite un mesaj
de eroare în caz de invalidare. Evident, utilizatorul nu își poate actualiza datele dacă nu este
autentificat.
2.7.4 Efectuarea testului

Fig. 2.11 Diagrama UML pentru începerea testului
Funcționalitatea -cheie a aplicației este testul de aflare a facultății potrivite. Pentru a
începe un test este obligatoriu ca utilizatorul să fie autentificat. Dacă acesta este autentificat,
server -ul va trimite următoarea întrebare și se va continua testul.

44

Fig. 2.12 Diagrama UML pentru continuare a testului
Odată început, testul trebuie continuat prin răspunderea la întrebările trimise succesiv
de server. După fiecare răspuns, server -ul va trimite înapoi către client o nou ă întrebare.
2.7.5 Administrare

Fig. 2.13 Diagrama UML pentru administrare
Utilizatorii care au rol d e administrator au drepturi suplimentare de editare a
conținutului aplicației (întrebările, regulile și soluțiile folosite de sistemul expert) și de generare
a fișierului de configurare a sistemului expert. Ace știa pot iniția oricare dintre acțiunile
menți onate prin introducerea de date, validarea lor fiind sarcina server -ului. Evident, utilizatorii
trebuie să fie autentificați pentru a realiza aceste acțiuni și, în plus, să aibă nivelul de autoritate
care îi permite să efectuee astfel de operațiuni .

45
3 MANUA L DE UTILIZARE AL APLICAȚIEI
Așa cu m am mai menționat până acum, a plicația CollegeFindr este o aplicație destinată
elevilor de liceu din ani terminali ce urmează să aleagă facultatea la care vor studia în
continuare. Scopul aplicației este de a -i ajuta pe elevi în procesul decizional oferindu -le o
sugestie de facultate pe care ar putea -o urma pe baza unor informații obținute de la utilizator
sub forma unor răspunsuri la întrebări.
Aplicația înglobează un algoritm de sistem expert , acesta fiind cel care anal izează
informațiile primite de la utilizatori prin intermediul unui test . Acest test constă dintr -o serie de
întrebări cu un set predefinit de variante de răspuns la care utilizatorul trebuie să răspundă. În
plus, utilizatorul poate răspunde la întrebări c u un anumit factor de certitudine a cărui valoare
este cuprinsă între 0 și 100 care va influența cursul decizional. Utilizatorul mai dispune și de
două variante de răspuns predefinite, „nu știu” (regulile algoritmului nu vor lua în considerare
acel răspuns) și „nu contează” (algoritmul va considera că toate condițiile în care este implicat
atributul al cărui valoare se încearcă a se obține prin răspunsul la întrebarea respectivă sunt
adevărate) pentru a -i oferi posibilitatea de a nu răspunde la anumit întreb ări; aceste răspunsuri
infunețează, de asemenea, deciziile sistemului expert. Întrebările pe care utilizatorul le va primi
sunt alese dinamic de către sistemul expert, ceea ce înseamnă că este posibl ca utilizatorul să
nu primească aceleași întrebări în de cursul a două teste distincte.
Aplicația oferă și câteva funcționalități de administrare a conținutului pentru utilizatori i
care au drepturi speciale. Acești utilizatori au titlul de administratori și au posibilitatea de a
administra întrebările, soluțiile și regulile folosite de sistemului expert; pot adăuga, edita și
șterge aceste elemente. Însă pentru ca noile configurații să aibă efect și să fie folosite de sistemul
expert trebuie reconstruite fișierele cu noile elemente – o altă funcționalitate specifi că
administratorilor. Utilizatorii care administrează conținutul aplicației trebuie să fie foarte atenți
când operează modificări asupra întrebărilor, soluțiilor și a regulilor, deoarece dacă se introduce
o eroare în aceste elemente, întreaga funcționare a sistemului expert este pusă în pericol.
De asemenea, orice utilizator își poate actualiza datele personale sau își poate schimba
parola contului, iar prima pagină a aplicației este una de tip dashboard în care sunt afișate câteva
date statistice legate de utilizarea aplicației CollegeFindr.
Toate aceste funcționalități sunt disponibile doar dacă utilizatorii sunt autentificați în
aplicație, cee a ce înseamnă că, evident, primii pași sunt de creare a unui cont și autentificare.

46
3.1 AUTENTIFICARE

Fig. 3.1 Formularul de autentificare

Fig. 3.2 Formularul de autentificare – erori
Autentificarea în aplicație se realizează prin intermediul unui formula r într-o pagină
specia lă pentru aut entificare . Dacă utilizatorul care încearcă să acceseze aplicația cu un cont
inexistent (sau doar a tastat greșit), acesta va primi un mesaj care să îl informeze despre acest
lucru. De asemenea, utilizatorul are la dispoziție și un link către pagina de înregistrare pentru
a-și crea un cont.

47
3.2 ÎNREGISTRARE

Fig. 3.3 Formularul de înregistrare în aplicație

Fig. 3.4 Formularul de înregistrare în aplicație – erori
Crearea unui cont pentru a accesa aplicația se realizează, de asemenea, prin intermediul
unui formular înt r-o pagină dedicată în care utilizatorul trebuie să introducă, obligatoriu,
numele, prenumele, numele de utilizator și o parolă pe care treb uie să o confirme din motive
de securitate. Opțional, acesta poate introduce și o adresă de email. Numele de utilizator este
unic și dacă deja există un cont asociat numelui de utilizator ales, utilizatorul va fi informat.

48
3.3 DASHBOARD

Fig. 3.5 Pagina principală – dashboard
După autentificarea cu succes, utilizatorii vor fi redirecționați către pagina principală a
aplicației – un dashboard în care le sunt prezentate câteva date statistice: numărul de teste
efectu ate în total, numărul de teste efectuate de către aceștia , clasamente cu cele mai populare
soluții la nivel global și în testele lor.

Fig. 3.6 Mesaj utilizator nou
Un utilizator nou, care nu a făcut niciun t est în aplicație va vedea un astfel de mesaj în
rubrica pentru clasamentul celor mai populare soluții în testele utilizatorilor.

49

Fig. 3.7 Tabel cu toate testele efectuate de utilizator
De asemenea, tot în p agina principală, utilizatorii vor vedea un tabel cu toate testele
efectuate de către aceștia, împreună cu data la care a fost făcut testul. Pentru fiecare test din
tabel există și un buton care navighează către o pagină î n care sunt afișate detalii despre testul
respectiv.

50

Fig. 3.8 Detalii ale unui test
În pagina în care sunt prezentate detaliile unui test putem vedea setul de întrebări care
au fost puse și răspunsurile utilizatorului împreună cu factorii de certitudine. De asemenea,
există și o rubrică în care se oferă din nou detalii despre soluțiile date de sistemul expert în cazul
respectiv.

51
3.4 MENIU DE NAVIGARE

Fig. 3.9 Meniu de navigare utilizator normal
Utilizatorii au la dispoziție un meniu de navigare menit să îi ajute să acceseze paginile
de interes pentru aceștia. Meniul aflat în colțul din dreapta -sus al paginii poate fi accesat făcând
click pe numele utilizatorului și oferă posibilitatea de a naviga către pagina de profil a
utilizatorului sau de a ieși din cont , redirecționând către pagina de autentificare. Meniul aflat în
stânga paginii conține căi de nagivare din orice pagină către dashboard, pagina de test sau
pagina de profil.

Fig. 3.10 Meniu de navigare administrator
Administratorii aplicației au la dispoziție o secțiune specială de administrare a
conținutului aplicației care poate fi accesată prin intermediului intrării Administrare din meniul
aflat în stânga paginii. Această parte a meniului nu este vizibilă utilizatorilor normali.

52
3.5 PAGINA DE PROFIL

Fig. 3.11 Pagina de profil a utilizatorului
Pagina de profil a utilizatorului îi oferă acestuia posibi litatea de a -și actualiza datele
personale sau de a -și schimba parola. Aceste acți uni sunt separate, schimbarea parolei făcându –
se independent de editarea datelor personale.

53

Fig. 3.12 Mesaje de informar e la editarea profilului
Datele introduse de către utilizator vor fi validate de către server și va trimite mesaje
elocvente utilizatorului, precum cele prezentate mai sus.

54
3.6 PAGINA DE TEST

Fig. 3.13 Pagina de test – informare

Fig. 3.14 Panou întrebare

55

Fig. 3.15 Panou soluții

Fig. 3.16 Panou solutii – sistmeul expert nu are solutii
În secțiunea dedicată testului, prima pagină care apare este una informativă. Această
pagină conține informații legate de modul în care se desfășoară un test, de variantele de răspuns,
folosirea factorului de certitudine și modul de afișare a s oluțiilor (vezi Fig. 3.13). După
efectuarea unui click pe butonul din această pagina, testul va începe și va fi afișată prima
întrebare a testului (vezi Fig. 3.14). În pano ul de întrebări vor apărea textul întrebării, variantele
de răspuns și câmpul pentru factorul de certitudine. Utilizatorul trebuie să aleagă o variantă de
răspuns, iar făcând click pe butonul Următoarea întrebare aceasta va fi trimisă serviciului web
pentr u a o procesa. În continuare va fi afișată următoarea întrebare sau, dacă au fost găsite
soluții, un panou cu soluții (vezi Fig. 3.15). Dacă nu a fost găsită nicio soluție, utilizatorul va
primi mesajul Sistemul ex pert nu are soluții (vezi Fig. 3.16).

56
3.7 ADMINISTRARE

Fig. 3.17 Pagina de administrare – informații generale
Modulul de admini strare conține mai multe pagini, iar funcți onalitățile sunt separate
astfel: o pagină de administrare a soluțiilor, o pagină de administrare a întrebărilor și o pagină
de administrare a regulilor sistemului expert. Există, în plus, funcționalitatea prin care se
generează fișierele de fonfigurație. În cele ce urmează voi detalia paginile de administrare.
3.7.1 Administrare a soluții lor

Fig. 3.18 Tabelul de administrare a soluțiilor

57

Fig. 3.19 Fereastra de editare a unei soluții
În pagina de administrare a soluțiilor sunt prezentate în formă tabelară toate soluțiile
sistemului expert (vezi Fig. 3.18). Pentru fiecare soluție sunt disponibile operațiunile de editare
și șterger e. Pentru editare va fi afișată o fereastră modală ce conține un formular a cărui câmpuri
sunt presetate c u valorile atributelor soluției ce pot fi modificate (vezi Fig. 3.19).
Pentru a adăuga o soluție, administra torii au la dispoziție butonul Adaugă o nouă soluție
în partea de sus a tebelului. Va apărea o fereastră modală cu un formular pentru adăugarea unei
soluții precum cea din Fig. 3.19.

58

Fig. 3.20 Informații pentru administrarea soluțiilor
Utilizatorii vor avea la dispoziție și un panou în care le sunt prezentate câteva informații
importante legate de administrarea soluțiilor.
3.7.2 Administrarea întrebărilor

Fig. 3.21 Tabelul de administrare a întrebărilor

Fig. 3.22 Fereastra de editare a unei întrebări

59

Fig. 3.23 Informații pentru administrarea întreb ărilor
Pagina de editare a întrebărilor are un aspect similar cu cea de administrare a soluțiilor:
toate întrebările folosite de sistemul expert sunt afișate într -un tabel (vezi Fig. 3.21) ce oferă
posibilități de editare și ștergere pentru fiecare intrare a tabelului. În cazul editării va fi afișată
o fereastră modală cu un formular ale cărui câmpuri sunt precompletate cu valorile atributelor
întrebării respective ( vezi Fig. 3.22). Adăugarea unei noi întrebări se realizează tot printr -un
formular similar celui din fereastra de editare care apare la apăsarea butonului Adaugă o nouă
întrebare.
De asemenea în pagină este afișat și un panou de informații legate de administrarea
întrebărilor (vezi Fig. 3.23).
3.7.3 Administrarea regulilor

Fig. 3.24 Tabelul de administrare a regulilor

60

Fig. 3.25 Fereast ra de editare a unei reguli

Fig. 3.26 Informații pentru administrarea regulilor
Pagina de administrare a regulilor folosite de algoritm este similară celor prezentate
până acum (paginile de administrare a sol uțiilor și întrebărilor): soluțiile sunt afișate într -un
tabel care oferă posibilități de editare și ștergere a intrărilor din tabel (vezi Fig. 3.24). Fereastra
de editare este similară celor prezentate mai devreme : o fereastră modală cu un formular a cărui
câmpuri sunt precompletate cu valorile acelor atribute (vezi Fig. 3.25). Adăugarea unei reguli
se face de asemenea printr -o fereastră similară celei de editare , cu un formular de adăugare, în
care administratorul trebuie să introducă regula după un format clar stabilit și explicat în panoul
de informații pentru administrarea regulilor (vezi Fig. 3.26).
Este foarte important să se r especte informațiile prezentate în panourile de informare
din paginile destinate administrării elementelor precedent menționate si explicate. Motivul este
acela că regulile, întrebările și soluțiile sunt folosite de algoritmul sistemului expert, iar o
greșeală strecurată în acțiunile de administrare poate produce efecte devastatoare la rularea
sistemului expert cu valori eronate introduse de utilizator.

61
4 CONCLUZII
Având în vedere aspectele prezentate în această lucrare, legat de implementarea și
funcționalit atea aplicației CollegeFindr, am observat că aceasta este o aplicație web al cărei
scop este oferirea ca sugestie a unei facultăți de urmat pentru un elev în an terminal de liceu
efectuând testul din aplcație. Această sugestie este mai mult decât bine -venită având în vedere
importanța acestui moment: momentul în care elevul trebuie să se hotărască asupra domeniului
de urmat. O alegere pripită, făcută în necunoștinț ă de cauză poate însemna un drum anevoios
în carieră sau o viață nefericită.
Dezvoltarea acest ei aplicații a necesitat folosirea și integrarea împreună a unui număr
considerabil de tehnologii din domenii diverse și orchestrarea cu grijă a componentelor
aplicației astfel încât să obțin fiabilitate, flexibilitate , scalabilitate și performanță. Desigu r,
procesul de implementare a funcționalităților în aplicație nu a fost unul ușor și lipsit de
incidente, dar cu siguranță am învățat concepte noi și am înțeles mai bine anumite noțiuni
tehnice rezolvând aceste probleme; consider că problemele c are apar în astfel de situații sunt o
parte firească a procesului de învățare.
În ceea ce privește direcțiile de expansiune viitoarea, î n mod cert, sunt foarte multe
funcționalități care ar trebui să fie introduse în aplicație astfel încât aceasta să devină mult mai
atractivă și mult mai practică; aplicația prezentată în acea stă lucrare reprezintă o bază solidă
pentru o aplicație de succes.
Reiterând ideea exprimată în introducere, cel mai potrivit domeniu în care această
aplicație poate fi folosită este sistemul educ ațional din România. Beneficiile unei astfel de
acțiuni au fost explicate în introducere, însă pentru o integrare a aplcației la un asemenea nivel
este necesară efectuarea unui studiu riguros de către o echipă de oameni profesioniști din
domeniile psiholog iei și al orientării profesionale pentru a defini cele mai bune reguli și
întrebări , pe care să le folosească algoritmul de inteligență artificială integrat , astfel încât
soluțiile oferite să fie cât mai apropiate de adevăr.
O funcționalitate cheie pentru această aplicație ce ar trebui implementată se referă la
posibilitatea oferirii unei demonstrații pentru alegerile făcute, astfel încât, utilizatorii să afle
care a fost raționamentul din spatele sugestiilor făcute de către sistemul expert. În acest fel,
utilizatorii vor căpăta puț in mai multă încredere în aplicație văzând că este capabilă să ofere
justificări pentru alegerea făcută.

62
Din punct de vedere tehnic, având în vedere că am abordat o arhitectură client -server pe
trei niveluri, va fi foarte ușor ca această aplicație să fie i ntrodusă și pe piața aplicațiilor mobile;
este necesar doar să fie create aplicații pentru platformele mobile, iar serviciul web existent va
putea fi folosit în continuare. Astfel se va acapara, probabil, 99% din piață, făcând aplicația
disponibilă atât ut ilizatorilor de telefoane mobile, cât și celor care preferă aplicațiile web.
O altă funcționalitate de o importanță majoră, care va face ca aplicația să fie folosită la
nivel internațional, este introducerea mai multor limbi. Momentan, aceasta poate fi fol osită doar
în lima română.
De asemenea, cu toate că soluția testului din aplicație conține și un link către site -ul web
al facultății respective, de unde putem afla informații despre facultatea respectivă, consider că
ar fi foarte util ca această aplicație să înglobeze și un set mai mare de informații despre facultăți,
eventual date istorice despre note, taxe și alte date statistice. Astfel, utilizatorii vor avea o vedere
de ansamblu asupra facultății respective și este, de asemenea, mult mai eficient decât să
navigheze către pagina de internet a facultății pentru a căuta informații de interes.
După cum am mai menționat în lucrare, am încercat să implementez aplicația la un nivel
cât mai generalist. Acest lucru a fost parțial obținut și poate fi îmbunătățit. În acest sens, o altă
direcție de dezvoltare este generalizarea aplicației de o așa natură încât arhitectura să poată fi
folosită pentru implementarea altor aplicații de sugestie a „celui mai potrivit lucru”.
Pentru a administra cât mai bine o aplicație î n care sunt integrate și funcționalitățile
menționate în paragrafele anterioare, consider că este de o utilitate maximă implementarea unei
aplicații separate pentru administrarea aplicației. Motivele sunt diverse: de la securitate, un
aspect foarte import ant în aplicațiile de nivel enterprise, până la funcționalitate și performanță,
în sensul separării volumului de muncă de aplicația propriu -zisă.
În concluzie, având în vedere funcționalitățile care au fost prezentate de -a lungul acestei
lucrări, odată cu atingerea obiectivelor setate mai devreme, CollegeFindr are șanse mari să
devină o aplicație cunoscută și utilizată la scară mare.

63
BIBLIOGRAFIE
1. https://play.goo gle.com/store/apps/details?id=com.it.educationfinder&hl=en_US –
accesat 2018
2. https://itunes.apple.com/us/app/the -college -fair/id990111320?mt=8 – accesat 2018
3. https://www.jetbrains.com/idea/features/ – accesat 2018
4. https://www.jetbrains.com/idea/features/#developer -ergonomics – accesat 2018
5. https://en.wikipedia.org/wiki/Angular_(application_platform) – accesat 2018
6. https://gorrion.io/blog/angularjs -vs-angular/ – accesat 2018
7. https://angular.io/guide/architecture – accesat 2018
8. https://angular.io/guide/architecture#whats -next – accesat 2018
9. https://go.java/index.html?intcmp=gojava -banner -java-com – accesat 2018
10. https://www.tiobe.com/tiobe -index// – acces at 2018
11. https://en.wikipedia.org/wiki/Java_(programming_language) – accesat 2018
12. https://docs.spring.io/spring/docs/5.1.0.BUILD -SNAPSHOT/spring -framework –
reference/overview.html#overview – accesat 2018
13. https://en.wikipedia.org/wiki/Spring_Framewo rk – accesat 2018
14. https://en.wikipedia.org/wiki/Inversion_of_control – accesat 2018
15. https://docs.spring.io/spring -boot/docs/current –
SNAPSHOT/reference/htmlsingle/#using -boot-using -springbootapplication –
annotation – accesat 2018
16. https://docs.spring.io/spring -boot/docs/current –
SNAPSHOT/reference/htmlsingle/#getting -started -first-application -annotations –
accesat 2018
17. https://docs.spring.io/spring –
security/site/docs/5.0.5.RELEASE/reference/htmlsingle/#what -is-acegi -security –
accesat 2018
18. https://jwt.io/introduction/ – accesat 2018
19. https://docs.spring.io/spring -data/jpa/docs/current/reference/html/#repositories
20. https://docs.spring.io/spring –
data/jpa/docs/1.3.0.RELEASE/reference/html/jpa.repositories.html – accesat 2018
21. https://docs.spring.io/spring -data/jpa/docs/current/reference/html/#repository -query –
keywords – accesat 2018

64
22. https://docs.spring.io/spring –
data/jpa/docs/1.3.0.RELEASE/reference/html/jpa.repositories.html#jpa.query –
methods.at -query – accesat 2018
23. https://en.wikipedia.org/wiki/Java_Persistence_API – accesat 2018
24. https://www.objectdb.com/java/jpa/query/criteria – accesat 2018
25. http://docs.jboss.org/hibernate/orm/5.3/quickstart/html_single/#preface – accesat 2018
26. https://docs.jboss.org/hibernate/orm/5.2/userguide/html_single/Hibernate_User_Guide
.html#appendix -legacy -criteria – accesat 2018
27. http://doc s.jboss.org/hibernate/orm/5.3/quickstart/html_single/#tutorial_annotations –
accesat 2018
28. https://en.wikipedia.org/wiki/Apache_Maven – accesat 2018
29. https ://maven.apache.org/ – accesat 2018
30. https://www.techopedia.com/definition/8711/oracle -database – accesat 2018
31. https://en.wikipedi a.org/wiki/SQL – accesat 2018
32. https://www.stubbornjava.com/posts/database -connection -pooling -in-java-with-
hikaricp – accesat 2018
33. https://en.wikipedia.org/wiki/Prolog – accesat 2018
34. https://en.wikipedia.org/wiki/Expert_system – accesat 2018
35. https://en.wikipedia.org/wiki/Git – accesat 2018
36. https://seesparkbox.com/foundry/api_testing_with_postman – accesat 2018
37. https://en.wikipedia.org/wiki/Software_architecture – accesat 2018
38. http://www.aut.upt.ro/staff/diercan/data/PSSC/curs -13.pdf – accesat 2018
39. https://en.wikipedia.org/wiki/Client%E2%80%93server_model – accesat 2018
40. https://en.wikipedia.org/wiki/Multitier_architecture – accesat 2018
41. https://stackoverflow.com/questions/671118/what -exactly -is-restful -programming –
accesat 2018
42. https://en.wikipedia.org/wiki/Representational_state_transfer#Architectural_constraint
s – accesat 2018