Denumirea completă a programului de studii [604095]

UNIVERSITATEA BABEȘ -BOLYAI
Facultatea de Științe Economice și Gestiunea Afacerilor
Denumirea completă a programului de studii

Lucrare de licență

Absolvent: [anonimizat],
Conf. univ. dr. Liana Stanca

2019

UNIVERSITATEA BABEȘ -BOLYAI
Facultatea de Științe Economice și Gestiunea Afacerilor
Denumirea completă a programului de studii

Lucrare de licență

Gestionarea și crearea documentelor CV

Absolvent: [anonimizat],
Conf. univ. dr. Liana Stanca

2019

ii

Rezumat
Lucrarea abordează tematica creării și prezent ării unu i curriculum -vitae ( CV). Plecând de la
structura acestui tip de document, am identificat potențialele imbun ătătiri pe care le putem
aduce pentru o mai buna formatare și lizibilitate a informatiilor importante prezentate în acesta.
Pe baza un or studi i și informatii de la oamenii care lucreaza în recrutare a unor companii foarte
mari, am identificat potentiale probleme care apar foarte des în elaborarea unui astfel de
document. În plus, am integrat posibilitatea de a alege din mai multe tipuri de formate, acest
lucru fiind destul de greu de realizat folosind un editor precum Word . De asemenea, oferim o
interfata intuitiva cu previzualizarea datelor introduse de utilizator pentru a intelege modul în
care CV -ul v-a arata în momentul în care va fi downloadat.

Lucrarea este organizată după cum urmează:
Capitolul 1 – Introducere repre zintă partea introductivă a lucrării, prezentarea domeniului
din care face parte proiectul, a temei propriu -zise.
Capitolul 2 – descrie cerintele de sistem necesare dezvoltarii aplicatiei.
Capitolul 3 – prezinta modelul de dezvoltare.
Capitolul 4 – Prezentarea generală a aplicației, interfața cu utilizatorul, și modalitatea de
stocare a informațiilor și a datelor.
Capitolul 5 – Tehnologiile utilizate reprezintă o scurtă introducere a principalelor noțiuni
legate de Internet. Sunt explica te noțiuni ca Internet, protoco ale, aplicații pentru internet,
DNS, internet și extranet, servere web și aplicații web, pagini web statice și dinamice, limbaje
de markup și scripting, HTML, JavaScript. Limbajul PHP este prezentat prin descrierea
principalelor noțiuni l egate de acest limbaj. De asemenea este prezentat și modul de
dezvoltare a aplicatiilor de frontend și backend
Capitolul 6 – prezinta modul în care aplicatie poate fi utilizata de catre utilizatorii acesteia
Concluzii le prezintă opinia mea personală despre aplicația realizată și posibilitățile de
dezvoltare a aplicației.

iii
Cuprins

Introducere ………………………….. ………………………….. ………………………….. ………………………….. ………… 1
1.1 Identificarea și descrierea problemei ………………………….. ………………………….. ………………………. 2
1.2 Motivatie ………………………….. ………………………….. ………………………….. ………………………….. ……. 2
1.3 Context ………………………….. ………………………….. ………………………….. ………………………….. ………. 4
2. Cerinte de sistem ………………………….. ………………………….. ………………………….. …………………………. 7
2.1 Surse de cerințe ………………………….. ………………………….. ………………………….. ……………………….. 7
2.2 Elicitația cerințelor ………………………….. ………………………….. ………………………….. …………………… 7
2.3 Documentarea cerințelor ………………………….. ………………………….. ………………………….. …………. 10
3. Model de dezvoltare ………………………….. ………………………….. ………………………….. …………………… 14
4. Proiectare ………………………….. ………………………….. ………………………….. ………………………….. ……… 15
4.1 Proiectarea logica ………………………….. ………………………….. ………………………….. …………………… 15
4.2 Arhite ctura sistemului ………………………….. ………………………….. ………………………….. …………….. 16
5. Implementarea aplicatiei ………………………….. ………………………….. ………………………….. ……………. 18
5.1 Tehnologii utilizate ………………………….. ………………………….. ………………………….. ………………… 18
5.2 Structurarea rutelor ………………………….. ………………………….. ………………………….. ………………… 24
5.3 Tipu rile mesajelor HTTP ………………………….. ………………………….. ………………………….. ………… 26
5.4 Structura datelor ………………………….. ………………………….. ………………………….. …………………….. 26
5.5 Procese și algoritmi ………………………….. ………………………….. ………………………….. ………………… 29
5.6 Dezvoltarea aplicatiei frontend ………………………….. ………………………….. ………………………….. … 31
5.6.1 Autorizarea cererilor ………………………….. ………………………….. ………………………….. ……….. 32
5.6.2 Creare și ștergerea formularelor multiple ………………………….. ………………………….. ……….. 33
5.6.3 Adaugare poza ………………………….. ………………………….. ………………………….. ………………… 35
5.7 Dezvoltarea aplicatiei backend ………………………….. ………………………….. ………………………….. … 36
5.7.1 Autorizare ………………………….. ………………………….. ………………………….. ………………………. 37
5.7.2 Serializar ea datelor ………………………….. ………………………….. ………………………….. …………. 38
5.7.3 Generarea unui document PDF ………………………….. ………………………….. ……………………… 39
5.8 Testarea ………………………….. ………………………….. ………………………….. ………………………….. ……. 40
6. Utilizarea aplicatiei ………………………….. ………………………….. ………………………….. ……………………. 42
6.1 Desc riere ………………………….. ………………………….. ………………………….. ………………………….. ….. 42
6.2 Prezentare scenarii de utilizare ………………………….. ………………………….. ………………………….. … 43
Concluzii ………………………….. ………………………….. ………………………….. ………………………….. ………….. 47
Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. ………. 49

iv
Lista tabelelor și figurilor

Figuri:
Figura 1 – Diagrama Fishbone………………………………………………………………………………………3
Figura 2 – Schema de descompunere a obiectivelor………………………………………………………….3
Figura 3 – Use-Case Administrator………………………………………………………………………………..8
Figura 4 – Use-Case Recruiter……………………………………………………………………………………….9
Figura 5 – Use-Case Utilizator……………………………………………………………………………………….9
Figura 6 – Adăugare recruiter de administratorul aplicatiei……………………………………………..13
Figura 7 – Diagra ma de activitate pentru a trimite email unui utilizator de c ătre recruiter……14
Figura 8 – Diagrama de flux de date (DFD)………………………………………………………………….16
Figura 9 – Arhitectura pe 3 nivele………………. ……………………………………………………………….17
Figura 10 – Arhitectura aplica ție………………………………………………………………………………….18
Figura 11 – Diagrama ERD a bazei de date………. ………………………………………………………….27
Figura 12 – Arhitectura unei aplicații Angular……………………………………………………………….29
Figura 13 – Selectare și modificare poza CV………………… ………………………………………………33
Figura 14 – Flow convertire date de intrare în PDF………………………………………………………..36
Figura 15 – Căutare utilizatori………………………………………….. …………………………………………39
Figura 16 – Vizualizare utilizatori………………………………………………………………………………..40
Figura 17 – Creare și previzualizare CV……………………………………………………………………….41
Figura 18 – Trimitere CV pe email………………………………………………………………………………41

1
Introducere
Chiar dac ă ne cautăm primul job sau ne gandim la o schimbare în carier ă, procesul incepe cu
un CV, sau curriculum -vitae. Acest document ne poate aduce succesul sau esecul de a primi
sansă la un interviu. CV -ul este unealta principal ă cand vine vorba de a gasi un job. în cazul în
care il faci bine, vei fi chemat la interviuri f ără probleme, dar în cazul nefericit în care acesta
nu este facut cum trebuie, poti aplica la foarte multe joburi și să nu fii sunat niciodata. Fiecare
CV este diferit de la o persoana la persoana, pentru că vrei să arati de ce tu esti mai potrivit
pentru pozitia pe care aplici decat ceilalti. CV -ul este o unealta de marketing personala menita
să te “vanda” posibililor angajatori în cel mai bun mod cu putinta. Acesta ar trebui să contina
un scurt rezumat despre tine, ce abilit ăti te recomand ă pentru postul pe care aplici, ce realiz ări
ai avut pan ă în momentul de fat ă, un scurt istoric profesional și eventual ultimele forme de
invătămant absolvite. Chiar dac ă structura este flexibila și iti permite să alegi ce vrei să pui în
continutul documentului, focus -ul ar trebui să fie pe sectiunile cele mai importante ale acestuia
și să scoat ă în evident ă cele mai bune c alitati ale persoanei.
Solutia pe care o propun vine în ajutorul tuturor oamenilor care sunt în căutarea unui
job. Având la dispoziție această aplicație în mod gratuit, oricin e poate foarte usor să creeze un
CV customizat pe nevoile fiec ăruia. Desi în momentul de fat ă pe piata exist ă câteva solutii care
ar putea satisface nevoile unui segment de public, solutia noastr ă aduce mai multe imbunatatiri
și este disponibil ă în mod gratuit, indiferent de num ărul de CV -uri create. Persoanele interesate
pot ad ăuga mai multe CV -uri, de asemenea putand alege din mai multe formate predefinite,
completand cu ce sectiuni doresc și introducand oricate articole au nevoie.

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
2
1.1 Identificarea și descrierea p roblemei
În momentul de față există câteva soluții care îndeplinesc anumite funcții ale solutiei propuse,
acestea fie nu sunt gratuite, fie sunt limitate din punct de vedere functional sau vizual.
Dorinta noastra este de a acoperi un segment cât mai mare d e oameni oferind solutia noastr ă
gratuit persoanelor care doresc să își construiasc ă un CV, cât și posibilitatea de a alege dintr –
un num ăr cât mai mare de formate și design -uri.
Problema care st ă la baza solutiei propuse este c ă serviciile existente fie of eră produse
invechite, limitate din punct de vedere al optiunilor de ales, fie nu sunt implementate cu noile
cerinte în materie de tehnologie sau vin cu niste cos turi pentru utilizatorul final.
Laszlo Bock, fostul People Operations Senior Vice President al Google estimeaz ă că a
revizuit personal de -a lungul carierei mai mult de 20.000 CV -uri. Acesta spune că un
asemenea document ar trebui să contin ă cel mult 2 pagini și recomand ă ca acesta să nu
contina tot istoricul carierei sau lucruri inutile care nu adu c plus de valoare referitoare la
postul pe care se aplic ă. De asemenea acesta recomand ă folosirea formatului PDF pentru c ă
acesta își pastreaza formatarea și se vede la fel pe orice tip de sistem de operare sau
calculator.
„De multe ori vedem CV -uri într -un format downloadat de pe site -uri. Nu exist ă
niciun fel de implicare în CV -ul respectiv. Din experienta mea în recrutare, CV -ul Europass
este un format usor învechit. Se caut ă altceva. CV -ul trebuie să fie dinamic”, spune Marga
Radu, Talent Acquisition Ma nager la Microsoft. Acest lucru denot ă că pe piata exista un gol
destul de mare în solutii de creare a unui CV customizabil, cu mai multe formate, usor de
folosit și de asemenea gratuit.
1.2 Motivatie
Trebuie s ă ne gandim la un CV precum la o reclam ă în care persoana este produsul. Scopul
este ca recruiterii și companiile s ă cumpere ceea ce tu “vinzi”, adica să acorde sansa la un
interviu. Pentru a realiza acest lucru, trebuie s ă ne gandim la un CV ca la cea mai importanta
unealt ă de marketing pe care o detinem pentru a reusi. Doar simplul fapt că avem un CV nu
este indeajuns pentru a ne angaja.
Managerii de recrutare sunt atrasi de documente cu o formatare bun ă care le atrage
atentia asupra lucrurilor cele mai importante. Statistic vorbind, studiile arat ă că “8 din 10 CV –
uri sunt respinse în primele 10 secunde”. Pentru a iesi din tipare, este important ca

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
3
documentul t ău să atraga atentia cititorului inainte ca a cesta să fie aruncat în gramada de CV –
uri respinse.
Angajatorii citesc în medie un CV în doar 6 secunde. In acest timp aceștia trebuie să
fie convinsi c ă merit ă să te sune pentru un interviu. “Cand m ă uit la un CV, primul l ucru pe
care il observ este dac ă este bine organizat și formatat. Daca nu pot s ă il citesc foarte usor,
este putin probabil să ma uit la el prea mult timp”, spune Jamie Hichens, Senior Manager în
recrutare, iar Karen Whyte, de asemenea Senior Manager Recruiter spune c ă “CV-ul trebuie
să fie usor de urm ărit, nu avem foarte mult timp să descifr ăm calific ările acestuia. Cu cât un
CV este mai usor de citit și urmarit, cu atât mai bine. Formatarea simpla și consistent ă
ajută!”.
Dorim s ă acoperim neajunsurile solutiilor actuale prin implementarea unor formate
cât mai dinamice, actuale, care să fie usor citibile și să acopere o arie cât mai mare de nevoi,
cu formate simple și clare, cu sectiuni vizibil divizate cât și cu headere care capte ază atentia
cititorului. Desi pe piat ă mai exista solutii similare, acestea nu ofera o gam ă atât de variat ă de
formate. De asemenea oferind solutia gratuit, ne adres ăm unui sector mult mai mare de
potentiali utilizatori.
In figura urm ătoare voi prezenta mo tivatiile care stau la baza proiectului de dezvoltare cu
ajutorul diagramei Fishbone.

Figura 1 – Diagrama Fishbone

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
4

Figura 2 – Schema de descompunere a obiectivelor

1.3 Context
Pentru tratarea completă a cerințelor, divizăm contextul în patru fațete și anume: fațeta
subiect, fateta utilizare, fațeta IT și fațeta dezvoltare. În continuare le voi prezenta în mod
detaliat pe fiecare în parte.
Fațeta subiect
Aplicația stochează și pr elucrează date despre:
Recruiteri
Utilizatori
Date CV

Recruiteri
Recruiterii sunt entit ătile care se pot inregistra pe aplicatie și pot vedea informatii despre
utilizatorii normali, aceștia putand să ii contacteze în cazul în care vad un posibil candidat de
care au nevoie pentru compania lor.
Despre recruiteri se vor reține următoarele date: numele, numele companiei, emailul și numărul
de telefon.

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
5
Utilizatori
Utilizatorii sunt cei care se inregistrea ză pe aplicatie pentru a -si crea CV -uri. Ace știa au nevoie
de câteva date personale pe care trebuie s ă le completeze în prealabil, inainte de a putea crea
un CV, apoi av and posibilitatea de a adauga cate documente doresc.

Date CV
Datele care apartin de un CV stocheaz ă informatiile generale ale persoanei, locurile de munca,
educatia, skill -uri, hobby -uri, etc…

Fațeta utilizare
În cadrul aplicației se vor putea crea doua categorii de useri, și anume user cu drept de USER,
care va avea acces la creatorul de CV, putând face modificări asupra datelor personale și
RECRUITER care va putea s ă vadă date despre utilizatorii USER cât și să ii contacteze.
Utilizatorii cu drept de administrator doresc ca prin intermediul acestei aplicații să poată insera
în baza de date informaț ii noi, într -o manieră simplă și ușor de utilizat, astfel încât să nu fie
nevoie de cunoștiințe avansate de informatică. De asemenea se dorește să se poate modifica
datele deja existente în cadrul bazei de date, prin intermediul unei interfețe prietenoase.

Fațeta IT
Această aplicație va fi gazduită de un server poziționat în cadrul companiei.
De asemenea trebuie să existe pe server o versiune de PHP 7.2 sau mai recentă, versiune
MySQL 4.1.3 sau mai recentă și un executabil wkhtmltopdf.exe.
De asemenea pen tru ca aplicația s ă funcționeze este nevoie de utilizarea unui browser care s ă
suporte Javascript. În momentul de față compania utilizează ca și browser Google Chrome
v74 și Mozilla FireFox 28.0.0. Aceste variante de browser sunt compatibile cu aplicația, dar
se pot utiliza și versiuni mai nou apărute.

Fațeta Dezvoltare
Pentru dezvoltare se folosește limbajul PHP pe framework -ul Symfony și Doctrine, cu un
nivel de abstractizare pentru MySQL pentru partea de backend, HTML, CSS și Angular 7
pentru partea de frontend. Pentru a asigura securitatea datelor se vor folosi diverse tehnici
printre care se pot accesa diferite rute din partea de backend doar cand utilizatorii autentificați
au anumite roluri iar parolele se vor p ăstra în baza de date criptate cu un alg oritm bcrypt.
Partea de verificare a codului scris se va face utilizând PHP și MySQL instalat local cu

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
6
Xampp iar pentru a porni serverul pe care ruleaz ă Symfony se foloseste o comanda care
foloseste WebServerBundle integrat în Symfony, avand posibilitatea de a specifica un IP și
un port pe care acesta s ă ruleze, avand posibilitatea de a porni aceeasi aplicatie pe mai multe
ip-uri sau porturi. De asemenea pentru a rula aplicatia de frontend se foloseste o comand ă
pentru a porni serverul de node. Pentru partea de editare a fișierelor se va folosi PHPStorm.
Pentru anumite funcționalități se vor folosi di verse librării open source.

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
7
2. Cerinte de sistem
2.1 Surse de cerin țe
Cerințele sistemului sunt definite de către stakeholderii săi. Ace știa sunt proprietarii site -ului.
Proprietarii site -ului sunt o sursă de cerințe deoarece ei au nevoie ca afa cerea lor să se dezvolte,
iar acest lucru nu se poate întâmpla fără ca și numărul utilizatorilor să crească în mod constant.
În toată această cercetare, accentul se pune pe optimizarea modului în care un utilizator poate
utiliza aplicatia, așadar, probabil cele mai importante cerințe vin din partea acestora.
2.2 Elicita ția cerin țelor
Părțile implicate în această aplicație sunt beneficiarii și dezvoltatorul aplicației. Beneficiarii
aplicației sunt grupați în mai multe categorii de utilizatori. În funcție de rolul pe care îl joacă,
fiecare va avea beneficii și d ezavantaje.
Dezavantajele utilizatorilor normali vin din cauza faptului c ă la inceput au un numar limitat de
formate de CV -uri din care alege, pe parcurs, dezvoltatorul aplicatiei avand posibilitatea de a
adauga mai multe. De asemenea, deocamdata nu se pot seta culorile, fontul sau marimea
fontului care va aparea în PDF. Cu timpul aceste dezavantaje pot să dispară și satisfactia
utilizatorilor să creasca, adăugând aceste facilitati pe parcurs, după ce o versiune initiala este
lansata și feedbackul utilizatorilor este urmarit.
2.2.1 Interviul
Pentru o mai bună înțelegere a problemei existente se va utiliza metoda interviului. În
continuare vom prezenta lista principalelor întrebări adresate și răspunsurile relevante obținute:
1. Cine este utilizatorul site -ului?
Acest site este utilizat de către cine dorește să creeze un CV. Profil utilizatorului care foloseste
aplicatia este o persoana care doreste să aplice la un job, avand nevoie de un CV.
2. Care este problema pe care această aplicație o rezolvă?
Problema pe care aplicatia o rezolva este generearea automata și usoara a unui CV bazat pe
niste date introduse de utilizator.
3. Cine va avea acces la aplicație ?
Oricine doreste crearea acestui tip de document.
4. Cum se vor introduce și prel ucra informațiile care vor fi introduse în baza de date?
Informațiile vor fi introduse manual într -un formular, de catre utilizator, după care se vor
trimite backend -ului și apoi salva în baza de date.

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
8
5. Care considerați că este cea mai mare problemă în a cest moment?
Faptul că utilizatorii petrec timp inutil în încercarea de a face un CV utilizand niste formate
invechite, prost formatate iar mai apoi fiind necesara și convertirea lor.
6. Ce așteptări există pentru performanță/ precizie?
Drumul pana la produsul finit, adică un CV formatat ca PDF trece prin mai multe stari, dar cea
mai importanța este convertirea din HTML în PDF folosind libraria wkhtmltopdf asupra careia
noi nu avem control, deci se poate spune că așteptările țin mai mult de modul în care
dezvoltatorii acesteia contribuie la dezvolta rea și optimizarea acesteia.
2.2.2 Workshop de cerinte
Am aplicat această metodă deoarece cea mai buna sursă de cerințe după cum am mai m enționat
anterior este publicul țintă. Au fost invitați la acest workshop utilizatori interesati de crearea
unui nou CV, utilizatori dornici să își schimbe CV -ul vechi cu unul mai actual și persoane care
lucreaza în domeniul recrutarii.
În cadrul worksopul ui a fost organizată o sesiune de brainstorming și au fost aplicate câteva
chestionare descrise în metoda interviului.
În urma brainstormingului cele mai bune idei s -au transformat în următoarele cerințe:
• Design prietenos și intuitiv
• Previzualizarea CV -ului inainte de a fi downloadat
• Posibilitate de a trimite la o adresa de email CV -ul atasat
2.2.3 Modelul US E-CASE
În urma aplicării acestei metode s -au înțeles cel mai bine procesele care au loc la gestionarea
datelor pentru a crea un CV sau la procesul de gasire a unor utilizatori. Actorii principali care
interacționează cu aplicația sunt utilizatorii inregistrati cu rol de USER sau cei cu rol de
RECRUITER și administratorul aplicatiei.
În continuare voi prezenta diagrama cazurilor de utilizare pentru fiecare utilizator în
parte pentru ca acestea să fie cât mai clare.

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
9

Figura 3 – Use-Case Administrator

Figura 4 – Use-Case Recruiter

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
10

Figura 5 – Use-Case Utilizator
2.3 Documentarea cerin țelor
Cerințele obținute în procesul de elicitație se împart în mai multe categorii precum cerințe
utilizator, cerințe funcționale, cerințe nefuncționale și cerințe specifice.

Cerințele utilizator reprezintă fraze în limbaj natural care descriu serviciile pe care se
dorește să le ofere sistemul și totodată constrângeri de operare. Acestea au fost extrase din
work -shopul de cerințe și din răspunsurile obținute în urma utilizării metodei interviului.
Cerințele funcționale descriu serviciile ce trebuie să fie oferite de sistem, modul
acestuia de a reacționa și comportamentul lui în situații particulare.
În urma metodelor aplicate s -au extras următoarele cerințe funcționale:
• Înregistrare utilizatori: Aplicația trebuie să pună la dispoziție un formular de înregistrare al
utilizatorilor, iar la acest formular poate avea acces oricine doreste să se inregistreze pe site.
Există mai multe tipuri de utilizatori și procesul de înregistrare trebuie să se facă asemănator
pentru fiecare.
• Autentificare utilizatori: Utilizatorii trebuie să se autentifice cât mai simplu atunci când doresc
să folosească aplicația și atunci vor completa doar un câmp pentru email și unul pentru parolă.
• Adăugare date CV: Odată creat i, utilizatorii pot să creeze CV adaugand date despre joburile
anterioare, educatie, limbi vorbite, skill -uri, etc…

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
11
• Căutare utilizatori: Fiecare recruiter poate căuta utilizatori care si -au creat CV după niste
criterii selectate de acestia
Cerințele nefu ncționale reprezintă constrânderi de timp, constrângeri ale procesului
de dezvoltare, standardele ce trebuie să le respecte, etc.
Tot în cerințele nefuncționale se încadrează cerințele calitative. Pentru utilizatori, sistemul
trebuie să fie disponibil de p e orice dispozitiv și browser de navigare în orice moment al zilei.
Aplicația trebuie să fie eficientă și scalabilă, adică să poată funcționa în parametri normali în
cazul accesului concurențial al unui număr mare de utilizatori și să execute cererile prim ite
într-un timp cât mai scurt și fără erori. Pe lângă toate aceste cerințe aplicația trebuie să aibă un
design și o structură intuitivă, ușor de utilizat și orice operație să fie realiza tă într -un număr de
pași redus.
Pentru dezvoltatori aplicația trebuie să fie portabilă, ușor de întreținut și bine structurată
pentru dezvoltări ulterioare.

Sectiune Continut
Identificator UC1
Nume Inregistrare
Autor Tomsa Alex
Versiune 0.1
Prioritate Ridicata
Criticitate Ridicata
Sursa Utilizatori
Stakeholder responsabil Tomsa Alex
Nivel Sistem
Descrierea scopului Posibilitatea ca un vizitator al aplicatiei să își
creeze un cont
Preconditie –
Postconditie Cont creat
Relatia cu alte cazuri de utilizare Nu exista

Sectiune Continut
Identificator UC2
Nume Login (autentificare)
Autor Tomsa Alex
Versiune 0.1
Prioritate Ridicata
Criticitate Ridicata
Sursa Utilizatori

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
12
Stakeholder responsabil Tomsa Alex
Nivel Sistem
Descrierea scopului Posibilitatea ca utilizatorii să acceseze profilul
Preconditie Existenta unui cont inregistrat
Postconditie Utilizatorul este logat
Relatia cu alte cazuri de utilizare Nu exista

Sectiune Continut
Identificator UC3
Nume Adaugare date CV
Autor Tomsa Alex
Versiune 0.1
Prioritate Ridicata
Criticitate Ridicata
Sursa Utilizatori
Stakeholder responsabil Tomsa Alex
Nivel Sistem
Descrierea scopului Posibilitatea ca utilizatorii să introduca date
pentru a crea un CV
Preconditie Existenta unui cont inregistrat
Postconditie Previzualizarea a cum va arata documentul
PDF
Relatia cu alte cazuri de utilizare Nu exista

Sectiune Continut
Identificator UC4
Nume Cautare utilizatori
Autor Tomsa Alex
Versiune 0.1
Prioritate Ridicata
Criticitate Ridicata
Sursa Utilizatori
Stakeholder responsabil Tomsa Alex
Nivel Sistem
Descrierea scopului Posibilitatea ca recruiterii să caute utilizatori
după anumite criterii
Preconditie Existenta unui cont inregistrat
Postconditie Utilizatorii sunt gasiti
Relatia cu alte cazuri de utilizare Nu exista

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
13
2.3.1 Procese și activitati
Principalele activități ale unei astfel de aplicații sunt: adăugarea/editarea de
recruiteri/utilizatori, contactarea unui utilizator de catre un recruiter, generarea de CV,
trimiterea acestuia la o adresa de email.
Activitatea de adăugare recruiter îi revine administratorului aplicației. Procesele de
adăugare se realizează aproape identic pentru toate cazurile de utilizare, singurul lucru care
diferă este informația ce trebuie adăug ată în formularele de adăugare.

Figura 6 – Diagrama de activitate pentru a adauga un recruiter de administratorul aplicatiei

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
14

Figura 7 – Diagrama de activitate pentru a trimite email unu i utilizator de catre recruiter
3. Model de dezvoltare
Modelul de dezvoltare incremental combină modelul secvențial cu cel bazat pe prototipuri.
Se va folosi acest model deoarece acesta este cel mai potri vit în cazul unor aplicații care
evoluează în timp. La utilizarea acestui model, prima versiune reprezintă o aplicație
funcțională care îndeplinește funcțiile de bază dorite. Clientul testează aplicația și în funcție
de feedback -ul primit se va dezvolta ur mătoarea versiune. Aplicația se construiește pas cu
pas, iar la terminarea fiecărei etape se adaugă noul cod la codul precedent.
Acest model de implementare este avantajos deoarece:
• Sistemul este dezvoltat și livrat după ce este stabilită arhitectura ace stuia.
• În timp se pot adăuga noi cerințe și specificații la fiecare pas.

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
15
• Utilizatorii pot să interacționeze cu aplicația chiar dacă aceasta nu este complet terminată.
• Fiecare pas poate fi dezvoltat cu un număr variabil de dezvoltatori
• Este avantajo s la aplicațiile care au deadline fix ce nu poate fi amânat deoarece se pot
renunța la anumiți pași.
Dezavantaje:
• De obicei, programele nu se preteaza evoluției fi ind fragile la modificări
• Erorile de proiectare sunt mai dificil de rezolvat
• Clientul p oate observa ce se poate realiza și cere mai multe îmbunătățiri așteptându -se să nu
plătească mai mult
• În cazul unei erori nedepistate aceasta se poate propaga în ansamblul aplicației. La
prototipurile finale este mai greu de depistat o eroare deoarece c odul este din ce în ce mai
mult și verificare se re alizează într -un timp mai lung.
4. Proiectare
4.1 Proiectarea logica
În cadrul acestui proiect, prelucrarea datelor la nivel de sistem este centralizată. Utilizând o
bază de date centralizată este posibilă reducerea redundanței datelor memorate, administrarea
și exploatarea ei devine mult mai facilă, și de asemenea evitarea inconsistenței datelor
memorate (atunci când există mai multe copii ale aceleiași date este posibil ca prin
actualizarea numai a unora dintre ele, să avem valori diferite pentru una și aceeași dată),
asigurând securitatea și integ ritatea datelor .
Diagrama de flux de date (DFD) al unui sistem este o tehnică de analiză structurată ce
prezintă circuitul datelor și are ca și obiectiv monitorizarea transferului de date între
procesele de prelucrare.
În următoarea diagramă este prezentat fluxul de date la nivel general pentru tipurile de
utilizatori ai aplicatiei (utilizatori normali și recruiteri). Astfel, se pot observa depozitele de
date, procesele care au loc și fluxurile de date care se realizează în cadrul fiecărui proces.
Principalele depozite de date sunt utilizatorii și datele unui CV -ul în care se stochează
informațile care se doresc a fi afisate în documentul PDF.

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
16

Figura 8 – Diagrama de flux de date (DFD)
4.2 Arhitectura sistemului
Deoarece la bază avem o aplicatie web, arhitectura sistemului este de tip client -server pe trei
niveluri. Aceasta este cea mai folosită arhitect ură în cazul aplicațiilor web.
O arhitectura multi nivel presupune interpunerea intre cele doua nivele din modelul
clasic, a unuia sau a mai multor alte nivele. De fapt, ceea ce se face este separa rea logicii
programului de cea legata de baza de date. în acest fel, se poate castiga independenta fata de
baza de date. De obicei. aplicatiile multi -nivel sunt divizate în trei straturi, după cum se poate
observa și din figura de mai jos.

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
17

Figura 9 – Arhitectura pe 3 nivele
Cele trei nivele ale arhitecturii cu trei nivele, pornind de la nivelul bazei de date, sunt:
• Nivelul de date (Data): Este compus dintr -o baza de date gestionata de un SGBD și care
poate contine pe langa date și logica de procesare sub forma de proceduri stocate.
• Nivelul de logica programului (Business Logic): Este stratul în care s unt inglobate diversele
module de prelucrare (containere și componente soft). Serverul (serverele) utilizat în acest
strat are rolul de a furniza un mediu de viata potrivit pentru acestea. De exemplu, serverul
poate furniza un serviciu de acces la baza de date, permitand componentelor sale să salveze și
să incarce date din nivelul de Date.
• Nivelul de prezentare (Presentation): Are rolul de a prezenta informatia la client, de obicei
fiind reprezentat de un browser.
Avantajele unei aplicatii multi -nivel ar fi urmatoarele:
• Modificarea bazei de date se poate face cu usurinta, deoarece clientii nu mai acceseaza
direct baza de date, ci un nivel intermediar care va face legatura cu baza de date. Deci o
modificare a bazei de date va duce doar la modificari al e nivelului intermediar, fara a necesita
vreo modificare la partea aplicatiei client.
• Modificarea logicii de prezentare (business) este usor de realizat, deoarece nu este nevoie de
recompilarea clientului.
• Partile vitale ale aplicatiei pot fi protejate folosind programe de protectie (firewalls)
amplasate intre nivelul de prezentare și nivelul de logica programului.
• Resursele pot fi reutilizate în mod eficient exploatand faptul ca, de obicei, clientii fac alte
lucruri pe langa utilizarea de resurse, ca de exemplu utilizarea interfetei grafice.

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
18
Aplicația este găzduită pe un server, care primește cererea clientului, o procesează și
îi trimite înapoi informațiile cerute. Rolul serverului este acela de a furniza servicii și resurse
clienților. Clientul rule ază pe o stație de lucru și este cel care efectuează cereri și
recepționează date de la server. Clientul comunică cu serverul printr -o rețea de calculatoare
(internet) efectuând un schimb de informații. În cadrul acestei arhitecturi flexibilitatea este
mult îmbunătățită deoarece cele trei componente (clientul, serverul și sistemul de baze de
date) pot fi oricare înlocuite fără să afecteze celelalte componente.

Figura 10 – Arhitectura aplicatie
5. Implementarea aplicatiei
5.1 Tehnologii utilizate
În procesul de dezvoltare al sistemului am folosit PHP (pe framework -ul Symfony v4.2.8),
MySQL, Javascript (pe framework -ul Angular 7), HTML și CSS.
Am ales să dezvolt aplicația în limbajul de programare PHP datorită simplitatii și
usurintei de a -l folosit pe ntru o aplicatie web, iar introducerea unui framework precum
Symfony, care aduce foarte multe functionalitati din alte limbaje de programare și vine deja
pregatit cu o serie de plugin -uri, metode și functii, asigurand totodata și securitate fara a mai
fi nevoie de a depune extra efort pentru a face toate aceste lucruri de la zero este unul din
principalele motive pentru aceasta alegere. De asemenea, framework -ul are o documentatie

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
19
foarte bine detaliata, cu exemple de implementare și un numar foarte mare de contributori
care lucreaza zi de zi la dezvolta rea acestuia.
Aplicația a fost dezvoltată folosind PHPStorm versiunea EAP gratuita pe sistemul de
operare Windows 10 Ultimate versiunea pe 64 biți. Baza de date folosită este MySQL.
Pentru ca aplicația să fie cât mai atractiva și dinamica pentru utilizator, cât și pentru
multiplele functionalitati care vin peste functiile Javascript native, am ales să folosesc
Angular V.7 pentru partea de frontend, impreuna cu HTML și CSS, folosind de asemenea un
design responsive.
HTML (HyperText Markup Language) este un limbaj de marcare utilizat pentru
afișarea paginilor web în browser. A apărut în anul 1991 și a fost inițial conceput doar pentru
formatare de text. În prezent oferă posibilitatea manipulării de imagini, sunet și video, dar și
integrarea cu alte tehnologii (CSS, JavaScript, PHP). Avantajele HTML sunt:
• Reprezintă documente independente de platformă
• Posibilitatea introducerii legăturilor cu alte documente
• Permite inserare de elemente grafice și sunet
• Oferă suport pentru StyleSheets, astfel se pot utiliza stiluri scrise în CSS pentru formatarea
elementelor din cadrul paginii.
CSS (Cascade StyleSheet) este folosit pentru formatarea elementelor vizuale din
cadrul paginilor web. Principalul avantaj al CSS reprezintă faptul că permite definirea de
stiluri externe (în cadrul unui fișier extern) care va fi inclus în pagina care va folosi stilurile
respective. Printre avantajele acestui limbaj se numără și faptul că formatarea este introdusă
într-un sing ur loc pentru tot documentul, putând fi aplicată mai multor elemente din cadrul
paginii, respectiv editarea rapidă a etichetelor.
PHP (PHP Hypertext Preprocessor) este un limbaj de scripting server -side, fiind
utilizat pentru crearea de pagini web dinamice. A fost creat de Rasmus Lerdorf în încercarea
de a-și personaliza propria pagină web. Denumirea sa inițială a fost Personal Home Page, însă
ulterior limbajul a f ost perfecționat, utilitatea și caracteristicile sale s -au dezvoltat, iar
denumirea a fost schimbată în Hypertext Preprocessor. Preprocesarea se referăla faptul că
datele sunt interpretate de către serverul web înainte de a afișa cod HTML. PHP este
indepen dent de platformă și poate rula pe orice sistem de operare. Principalele caracteristici
ale limbajului sunt:

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
20
• Simplicitate: este un limbaj simplu de folosit, fiind cel mai popular limbaj utilizat pentru
crearea de pagini web dinamice;
• Eficiență: este un limbaj orientat obiect, iar acest lucru ajută la mărirea productivității
întrucât codul va putea fi reutilizat, un programator putând folosi module create de un altul
fără a fi nevoie să cunoască detalii specifice de implementare al codului;
• Portabilita te: aplicațiile scrise în PHP pot fi rulate pe orice sistem de operare;
• Open Source: poate fi folosit de către oricine fără a fi nevoit să plăt ească ceva.
MySQL este sistemul ales pentru aceasta aplicatie pentru gestionarea datelor.
MySQL este un sistem de gestiune a bazelor de date relațional, produs de compania suedeză
MySQL AB și distribuit sub Licență Publică Generală GNU. Este cel mai popular SGBD
open -source la ora actuală, fiind o componentă cheie a stivei LAMP (Linux, Apache,MySQL,
PHP). Deși este folosit foarte des împreună cu limbajelel de programare JAVA,PHP, cu
MySQL se pot construi aplicații în orice limbaj major. Există multe scheme API disponibile
pentru MySQL ce permit scrierea aplicațiilor în numeroase limbaje de programare pentru
accesare a bazelor de date MySQL, cum are fi: C, C++, C#, Borland Delphi, Java, Perl, PHP,
Python, FreeBasic, etc., fiecare dintre acestea folosind un tip spefic API. O interfață de tip
ODBC denumită MyODBC permite altor limbaje de programare ce folosesc această
interfață,să interacționeze cu bazele de date MySQL cum ar fi ASP sau Visual Basic.În multe
cărți de specialitate este precizat faptul că MySQL este mult mai ușor deinvățat și folosit
decât multe din aplicațiile de gestiune a bazelor de date .
Din punct de ve dere hardware, aplicația a fost dezvoltată pe un laptop Asus TUF cu
următoarea configurație: Processor Intel(R) Core(TM) i7 -8750H CPU @ 2.20GHz, 2201
Mhz, 6 Core(s), 8GB RAM.
WkHtmlToPDF
WKHTMLTOPDF este un utilitar open -source care se ruleaza din linia de comanda și
converteste un fisier HTML în PDF. Acesta foloseste motorul de randare Qt Webkit
(https://wiki.qt.io/Qt_WebKit) care randeaza pagini web și executa și codul Javascript din
acestea.
SwiftMailer
SwiftMailer se integreaza usor în orice apl icatie scrisa în PHP și ofera un mod elegant de a
trimite emailuri printr -o abordare orientata -obiect cu o multitudine de functionalitati. Acesta

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
21
este de asemenea și cea mai folosita solutie pentru aplicatiile care folosesc framework -ul
Symfony pentru ca i ntegrarea și configurarile sunt foarte facile.
Doctrine
Doctrine este un set de librarii PHP menit în a oferi persistenta datelor și maparea obiectelor
intr-un sistem care foloseste o baza de date. Doctrine ORM, care este utilizat în acest proiect,
vine preinstalat în framework -ul Symfony și este inspirat din Hibernate din Java. Doctrine
ofera un nivel de abstractizare a acesului la baza de date, acceptand majoritatea tipurilor
cunoscute de baze de date relationale sau chiar și NoSQL.
Acesta creaza o baza de obiecte virtuala care se pot folosi mai apoi pentru a extrage,
salva sau modifica anumite entitati. De asemenea unul din avantajele principale este ca ofera
securitatea datelor, interfata sa transformand în query -uri securizate toate request -urile spre
baza de date.
NGX -Image -Cropper
NGX -Image -Cropper este un plugin pentru aplicatia de frontend care ofera posibilitatea de a
face crop la o imagine, oferind mai multe optiuni prin care utilizatorul poate alege cum să
arate imaginea finala pe care o va atasa CV -ului.
Protocolul HTTP
Hypertext Transfer Protocol, pe scurt HTTP, este un protocol la nivelul aplicație care stă la
fundația comunicației în World Wide Web. Hypertext reprezintă un set de obiecte care
construiesc conexiuni între noduri prin leg ături logice, hyperlinks. HTTP este protocolul care
permite tra nsferul unor astfel de obiecte.
HTTP este un protocol de tip cerere -răspuns în modelul arhitectural client -server. Un
client, cel mai des un web browser, trimite o cerere HTTP către un server w eb, care întoarce
un răspuns. Acest răspuns conține o stare al completării cererii și, în caz de succes, informația
cerută.
Resursele HTTP sunt identificate și localizate pe rețea prin Uniform Resource Locators
(URLs) folosind schema http U RI definită în RFC 3986 astfel:
<nume_schema> : <porțiunea_ierarhică> [ ? <query> ] [ # <fragment> ]

În cazul HTTP numele schemei este http. Partea ierarhică începe cu un dublu forward
slash "//", urmat de un nume al autorității, care poate fi un nume de dom eniu sau un ip, urmat

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
22
apoi de un port opțional, precedat de ":". După autoritate urmează un path construit ca o
succesiune de segmente, asemănător unei structuri de directoare, caracterul separator fiind
"/". Porțiunea de query este opțională, începe cu "? " și conține informație adițională care nu
este ierarhică, ci organizată tipic prin perechi de tip <cheie>=<valoare>, cu perechile separate
prin ";" sau "&". Partea fragmentului este de asemenea opțională, începe cu "#" și conține o
directivă către o resur să secundară, cel mai des un atribut id al resursei principale, așa cum se
întâmplă în cazul documentelor HTML.
HTTP definește nouă metode care indică acțiunea dorită asupra resursei accesate.
Aceste nouă m etode sunt: HEAD, GET, POST, PUT , DELETE, TRACE, O PTIONS,
CONNECT și PATCH. Cele mai utilizate sunt cele de GET, prin care se citește resursa, și
cele de POST, PUT și DELETE, prin care se modifică resursa. Metodele safe (sigure) sunt
considerate cele prin care se intenționează doar citirea informației, fă ră modificarea stării
serverului. Acestea sunt HEAD, GET, OPTIONS și TRACE. Metodele idempotente sunt cele
asupra cărora mai multe cereri identice ar trebui să aibă același efect. Acestea sunt POST și
DELETE.
O cerere HTTP conține următoarele :
• o linie d e request, spre exemplu GET /avatar/my_picture.jpg HTTP/1.1 care formulează o
cerere pentru resursa /avatar/my_picture.jpg de la server.
• headere http, cum ar fi Content -Typ, Accept , etc.
• o linie goală
• un corp al mesajului, opțional
Un răspuns HTTP co nține următoarele:
• linie de status (spre exemplu HTTP/1.1 200 OK, care indică finalizarea cu succes a cererii
clientului). Un status 3xx indică necesitatea unei redirectari, 4xx și 5xx sunt statusuri de
eroare (4xx – eroare la client, 5xx – eroare la serv er).
• headere HTTP, cum ar fi Content -Type: text/html
• o linie goală
• un corp al mesajului, opțional
Antetele HTTP sunt perechi "cheie: valoare", scrise în clear -text și separate prin succesiunea
de caractere carriage return (CR) și line feed (FD). Aceste headere definesc parametrii de
operare a unei tranzacții HTTP.

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
23
Servicii Web RESTful
Representational State Transfer (REST) reprezintă un stil arhitectural bazat pe standardele
web și pe protocolul HTTP, pentru sisteme distribuite că World Wide Web. REST s -a
evidențiat în ultimii ani ca modelul de design predominant al web -ului, datorită s implității
sale. REST a fost descris în 2000 de Roy Fielding, în lucrarea sa de doctorat.
Într-o arhitectură bazată pe REST, totul este o resursă. O resursă este accesată printr -o
interfață comună bazată pe metodele standard HTTP. Într -o arhitectură REST, există tipic un
server REST care asigură accesul la resurse și clienți REST care accesează sau modifică
resursele. Fiecare resursă ar trebui să suporte operațiile standard HTTP (GET, POST, PUȚ,
DELETE). Resursele sunt identificat e prin ID -uri globale – URIuri.
"Limbajul" REST este bazat pe substantive și verbe și pune accentul pe lizibilitate.
Spre deosebire de SOAP, REST nu necesită parsare XML și nu necesită un header al
mesajului de la/către un service provider, ceea ce duce la reducerea bandwidth -ului c onsumat.
REST are și o altă metodologie de manipulare a erorilor: în timp ce SOAP poate avea mesaje
definite de eroare, REST necesită folosirea mecanismelor HTTP de error handling .
Stilul arhitectural REST impune anumite direcții de luat în considerare la realizarea
designului, implementarea componentelor individuale fiind la discreția dezvoltatorului:
• Client -server – o interfață uniformă separă clienții de servere. Separarea preocupărilor
înseamnă că, spre exemplu, clienții nu se ocupă de stocarea datel or, așa cum serverul nu se
ocupă cu interfața utilizatorilor sau cu starea clienților. Astfel, serverele și clienții pot fi
dezvoltați independent, interfața rămânând constantă.
• Stateless – acest principiu asigură că niciun context al clientului nu este memorat pe server
între cereri. Fiecare cerere efectuată conține toate informațiile necesare, și orice informație de
stare a sesiunii este stocată pe client. Aceasta este o caracteristică de rezistență la erori a
serverelor.
• Cacheable – clienții pot reți ne în cache răspunsurile. O memorie cache bine întreținută poate
îmbunătăți scalabilitatea și performanța sistemului, prin reducerea numărul de cereri de la
clienți la server.
• Layered – un client nu -și poate da seama prin interfata comună dacă este conec tat direct la
server sau la un proxy intermediar. Servere intermediare pot îmbunătăți scalabilitatea
sistemului prin load -balancing sau prin partajarea unei memorii cache.
• Code on demand (opțional) – serverele pot să extindă temporar funcționalitatea cli entului
prin transferul codului – exemple fiind Java applets sau limbajele client -side scripting ca
JavaScript.

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
24
Un serviciu RESTful se bazează pe metodele HTTP și pe conceptele arhitecturii
REST. Acesta definește tipic un URI de baza pentru resurse și tipu rile MIME suportate
(XML, Text, JSON, Protocol Buffers, etc) și setul de operații HTTP. Aceste metode standard
sunt:
• GET – definește un acces la citirea unei resurse, fără efecte secundare. Resursa nu este
niciodata alterată în urma unei cereri GET.
• PU T – crează o nouă resursă, trebuie să fie idempotentă.
• DELETE – șterge o resursă; operația trebuie să fie idempotentă, o repetare a cererii nu
trebuie să producă efecte suplimentare primei cereri.
• POST – actulizează resursa exist entă sau crează o nouă resursă.
5.2 Accesarea resurselor pe baza URL și a protocolului HTTP
Aplicația se bazează pe o arhitectură client -server, având în centru un server cu următoarele
roluri:
• stochează datele pe care utilizatorii le salveaza despre profilul lor cât și despre datele lor de
pe un CV ;
• centralizează feedbackului primit de la clienți, stocând toate tipurile de feedback;
• răspunde la cereri de la utilizatori ;
• rulează executabilul wkthmltopdf.exe pentru convertirea documentelor HTML în PDF
Pentru implementarea serverului am ales o soluție de web service, datorită existenței
unor soluții multiple de frameworkuri astfel de servicii și datorită simplității accesării
resurselor, prin Uniform Resource Locator.
5.2 Structurarea rutelor
Bundle -ul FOSRestBundle de la Symfony este folosit pentru stocarea resurselor http și oferă
posibilitatea setării la rulare a unui URL de bază, la care serverul web poate fi accesat. În
cazul de fata, URL -ul de baza al serverului este format dintr -un IP și un port. În cazul stației
pe care rulează serverul, acest URL are forma http:// 127.0.0.1:8000/. În cazul clienților,
aceștia vor avea posibilitatea accesării serverului prin ip -ul public al acestuia, care se setează
indepenent de ser ver la rularea acestuia, în funcție de setările ruterului wireless care asigură
comunicația. FOSRestBundle permite crearea unor clase de tip controller , care asigura
comunicarea cu clientul și pentru care se definește prin a dnotarea @ Rest porțiunea de URL
care se adăugă URL -ului de baza al serverului. O ad notare de tipul @ Rest("/user") aplicată în

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
25
cazul unei clase va face disponibilă resursa http la adresa http:// 127.0.0.1:8000 /api/user, în
cazul accesului de pe mașina locală care rulează serverul, spre ex empl u dintr -un browser rulat
local.
Pentru aceasta aplicație , am definit mai mult tipuri de URL -uri, în funcție de resursele
accesate. Acestea sunt prezentate în continuare prin porțiunea caracteristică resursei, care se
adăugă adresei de bază:
• /user: o resursa de tip DELETE la care au acces utilizatorii pentru a -si sterge contul
• /user/profile – o resursa de tip REST cu metodele GET și PATCH pentru a -si modifica și
vizualiza datele contului
• /user/password – resursa de tip PATCH pentru a -si modifica parola
• /user/cvs – o resursa de tip GET unde utilizatorii își pot vedea CV -urile create
• /register – metoda utilizata pentru inregistrare
• /login_check – metoda utilizata pentru login
• /users/search – metoda utilizata de recruiteri pentru a căuta utilizatori cu mai multi
parametrii de tip query
• /users/search – metoda utilizata de recruiteri pentru a căuta utilizatori cu mai multi
parametrii de tip query
• /builder/cv/{id} – o resursa de tip REST pe care utilizatorii o apeleaza pentru a modifica
datel e unui CV
• /knp/download/{id} – o resursa de tip GET pe care utilizatorii o apeleaza pentru a -si
downloada sub forma de PDF un CV
• /cv/{id}/email – o resursa de tip POST pe care utilizatorii o apeleaza pentru a -si trimite CV –
ul pe o adresa de email

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
26
5.3 Tipurile mesajelor HTTP
Pentru transmiterea diferitelor mesaje HTTP între client și server, am folosit setarea antetului
Content -Type al mesajului http. Următoarele tipuri au fost folosite pentru definirea
conținutului:
• application/json: deoarece partea de backend este un API care foloseste atât arhitectura
REST, toate apelurile la rutele definite mai sus se fac folosind headerul “Content -Type:
application/json”
• application/pdf: această setare e folosită pentru downloadarea unui CV . Prin interpretarea
corectă acestui mesaj http, clientul preia conținutul binar și îl scrie într -un fișier de tip pdf
5.4 Structura datelor
Asupra tabelelor sunt executate instrucțiuni de manipulare a datelor pentru a obține
rezultatele care vor duce la îndeplin irea obiectivelor aplicației. Relațiile dintre acestea se
bazează pe cheile primare și secundare din fiecare tabelă, fiind necesar ca tipul de date a cheii
secundare să fie același cu cel al cheii primare. Datele sunt inițializate în funcție de tipul de
date definit.
CV_DATA
Cheie Nume coloana Tip
PK id Varchar(36)
FK user_id Varchar(36)
full_name Varchar(128)
job_title Varchar(128)
summary Text
email Varchar(64)
phone Varchar(64)
address Varchar(255)
template Varchar(64)
avatar Varchar(64)

USERS
Cheie Nume coloana Tip
PK Id Varchar(36)
email Varchar(64)
password Varchar(64)

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
27
full_name Varchar(128)
role Varchar(64)

EXPERIENCE
Cheie Nume coloana Tip
PK id Varchar(36)
FK cv_id Varchar(36)
job_title Varchar(128)
company Varchar(128)
description Text
start datetime
end datetime

EDUCATION
Cheie Nume coloana Tip
PK id Varchar(36)
FK cv_id Varchar(36)
school Varchar(128)
degree Varchar(128)
city Varchar(128)
description Text
start datetime
end datetime

SKILL
Cheie Nume coloana Tip
PK id Varchar(36)
FK cv_id Varchar(36)
skill Varchar(64)
level Varchar(36)

LANGUAGE
Cheie Nume coloana Tip
PK id Varchar(36)
FK cv_id Varchar(36)
language Varchar(64)
level Varchar(36)

TITLUL LUCRĂRII – EVENTUAL PRESCURTAT PENTRU A SE ÎNCADRA PE UN SINGUR RÂND
28
WEBSITE
Cheie Nume coloana Tip
PK id Varchar(36)
FK cv_id Varchar(36)
label Varchar(64)
link Varchar(64)

HOBBY
Cheie Nume coloana Tip
PK id Varchar(36)
FK cv_id Varchar(36)
hobby Varchar(64)

CUSTOM_SECTION
Cheie Nume coloana Tip
PK id Varchar(36)
FK cv_id Varchar(36)
title Varchar(64)
description Text

29

Figura 11 – Diagrama ERD a baz ei de date
5.5 Procese și algoritmi
Algoritmul de căutare are o importanță majoră pentru business -ul aplicatiei, întrucât căutarea
posibililor candidati care intrunesc unele seturi de criterii este cel mai important pentru
recruiter. Prin intermediul acestui algoritm se dorește cău tarea candidatilor stocati în baza de
date, pe baza unor cerinte exacte furnizate de către recruiteri. Se introduc criteriile după care
se dorește să se facă căutarea, astfel algoritmul de cautare verifică dacă datele introduse
există și nu sunt invalide, după care parcurge toată tabela cu utilizatori și verfică datele în
functie de criiterile de cautare alese. Dac ă se gasesc utilizatori, atunci aceștia vor fi pusi într -o
listă pentru a putea fi returnati intr -un răspuns.

30

Acesta este codul în Doctrine care caută utilizatorii după mai multe criterii, cum ar fi titlul
job-ului, companiile pentru care a lucrat, skill -uri sau limbi vorbite cât și keyword -uri folosite
în descrieriile job -urilor sau educatiilor anterioare. Acesta este transformat de Doctrine în cod
SQL care apoi se ruleaz ă pe baza de date, codul formatat în SQL fiind acesta:

31
5.6 Dezvoltarea aplica ției frontend
Pentru dezvoltarea aplicatiei frontend s -a folosit Angular versiunea 7 impreun ă cu HTML și
CSS. Angular este un framework de dezvoltare web open -source bazat pe limbajul
TypeScript. Proi ectul este dezvoltat de e chipa Angular de la Google și de o comunitate de
utilizatori individuali și companii. Angular este o rescriere completă, de către aceeași echipă,
a frame workului AngularJS.
Inițial, versiunea rescrisă a AngularJS a fost numită "Angular 2" de echipă, însă acest
lucru a provocat confuzie printre dezvoltatori. De aceea, echipa a anunțat că "AngularJS" se
va referi la versiunile 1.X și "Angular" (fără "JS") la versiunile 2 și ulterioare.
Angular nu are conceptul de domeniu de vizibilitate (în engleză "scope") sau
controlere, ci utilizează o ierarhie de componente ca principală caracteristică arhitecturală.
Angular are o sintaxă diferită pentru expresii, ce se concentrează pe "[ ]" pentru con ectarea
proprietăților și pe "( )" pe ntru conectarea evenimentelor .
Modularitate – mare parte din funcționalitatea frameworkului a fost mutată în module
Angular recomandă folosirea limbajului TypeScript, ce ar e următoarele proprietăți:
Programare orientată pe obiecte folosind clase
Tipare statică, Programare generică .
TypeScript este un supraset al ECMAScript 6 (ES6), fiind c ompatibil cu ECMAScript
5 (JavaScript). Angular include și noutățile din ES6: Programar e lambda, Iteratori, Reflecție,
Încărcare dinamică, Compilare asincronă a template -urilor.

32

Figura 1 2 – Arhitectura unei aplicații Angular. Principalele blocuri sunt module, componente,
template -uri, metadate, legături de date, directive, servicii și injecții de dependențe.
5.6.1 Autorizarea cererilor
AuthGuard este o protecție pentru rute utilizată pentru a împiedica accesul utilizatorilor
neautorizați la rutele restricționate . Aceasta se realizeaza prin implementarea interfeței
CanActivate care permite autorizatorului să decidă dacă o rută poate fi activată cu metoda
canActivate (). Dacă metoda retu rnează "true" , ruta este activată (permiteți -i utilizatorului să
continue), în caz contrar dacă metoda returnează "false " ruta este blocată.
AuthGuard utilizează serviciul de autentificare pentru a verifica dacă utilizatorul este
logat. D acă este logat (ad ica are un jwt token salvat în localStorage) , return ează "true" din
metoda canActivate(), altfel returnează false și redirecționează utilizatorul la pagina de
logare .
export class JwtInterceptor implements HttpInterceptor {
intercept (request: HttpRequest< any>, next: HttpHandler): Observable<HttpEvent< any>> {
const token = UserService. getCurrentToken ();
if (token) {
request = request. clone ({
setHeaders : {
Authorization : `Bearer ${token} `
}
});
}

return next. handle (request) ;

33
}
}
Error Interceptor -ul interceptează răspunsurile http de la api pentru a verifica dacă
exist a erori. Dacă există , un răspuns 401 (Not Authorized) est e aruncat , iar utilizatorul este
deconectat automat din aplicație, toate celelalte erori sunt re -aruncate pentru a fi prinse de
serviciul de apelare, astfel încât o alertă să poată fi afișată utilizatorului.
Este implementat folosind clasa HttpInterceptor introdusă în Angular 4.3 ca parte a
noului HttpClientModule. Prin extinderea clasei HttpInterceptor se poate crea un interceptor
personalizat pentru a prinde toate răspunsurile de eroare de la server într -o singură locație.
export class ErrorInterceptor implements HttpInterceptor {
constructor (private userService : UserService , private router : Router) { }

intercept (request: HttpRequest< any>, next: HttpHandler): Observable<HttpEvent< any>> {
return next. handle (request). pipe(catchError (err => {
if (err.status === 401) {
this.userService .logout ();
this.router .navigate (['/guest' ]);
}
const error = err. error .message || err. statusText ;

return throwError (error) ;
}));
}
}
5.6.2 Creare și ștergerea formulare lor multiple
Pentru formularul de adaugare a datelor am folosit "reactive forms " din Angular.
Formularele "reactive forms" facilitează un stil de programare care favorizează gestionarea
explicită a datelor care circulă între un model de date non -UI (de obicei preluat de la un
server) și un model de formular orientat UI care păstrează stările și valorile controalelor
HTML pe ecran . Formularele “reactive” oferă ușurința utilizării modelelor reactive, testării și
validării.
Cu ajutorul formulalelor reactive, se creaza un arbore de obiecte de inputuri în clasa
componentei și se leaga de elementele native din formular din template -ul componente i.
Cu ajutorul acestora se creeaza și se manipuleaza inputurile formularului direct în
clasa componen ta. Deoarece clasa componenta are acces imediat atât la modelul de date, cât
și la structura d e control al formularului, se pot adauga valori de date în controlerele

34
formularului și se pot prelua datele formularului introduse de utilizator . Componenta poate
“observa ” schimbările în starea de control a formei și poate reacționa la aceste modificări.
Un avantaj al lucrului cu obiectele formularului este faptul că actualizările valorilor și
valabilității sunt întotdeauna sincrone și sub controlul developerului . Nu se pot întâlni
problemele de sincronizare care uneori afectează o formă bazată pe șablon și formele reactive
pot fi mai uș or de testat.
Codul afisat în structura HTML a unei componente arata precum în snippet -ul de cod
alaturat.
<div formArrayName ="educations" >
<div class ="panel panel -default" *ngFor ="let control of cvBuilder .controls ['educations' ].controls ;
let i = index ">
<div class ="panel -heading float -right" >
<span class ="delete -forever -text" > Delete {{cvBuilder .value .educations[i].degree }} </span>
<mat -icon (click) ="deleteEducation (i)" class ="delete_forever text –
danger" >delete_forever </mat -icon>
</div>
<div class ="clearfix" ></div>
<app -education [addEducationForm] ="cvBuilder .controls ['educations' ].controls[i] "></app –
education>
</div>
<button mat-stroked -button color ="primary" (click) ="addNewEducation ()">New
Education </button>
</div>

Acesta afiseaz ă toate subformularele reactive de tip „education” care apartin unui
formular p ărinte. Acesta este un subformular de tip „array”, de aceea se poate itera pe toate
controle rele acestuia utilizand iteratorul specific Angular *ngFor .
De asemenea , pentru a ad ăuga un control nou în view, se apasa butonul „New Education”
care apeleaza metoda „addNewEducation” prezentata mai jos:
protected addNewEducation (): void {
const arrayControl = this.cvBuilder .get('educations' ) as FormArray ;
const newGroup = this.formBuilder .group ({
school : [null, Validators. required ],
degree : [null, Validators. required ],
city : [null],
start : [new Date()] ,
end : [new Date()] ,
description : [null, Validators. maxLength (2048 )]
});
arrayControl. push (newGroup) ;
}

35
Pentru a sterge un control din view -ul unei componente, se apas ă iconita de delete,
care apeleaz ă metoda „deleteEducation” și care va sterge controler -ul formularului de pe
pozitia precizata, precum în codul de mai jos:
protected deleteEducation (index: number ): void {
const arrayControl = this.cvBuilder .get('educations' ) as FormArray ;
arrayControl. removeAt (index) ;
}
5.6.3 Adaugare poza

Pentru ad ăugarea și manipularea unei fotografii în CV, s -a folosit libraria NGX -Image –
Cropper. A ceasta permite functia de „crop” aplicat ă unei fot ografii selectate de utilizator, cât
și mai multe optiuni pe care developerul le poate aplica în functie de necesit ătile pe care
fotografia final ă trebuie să le indeplineasc ă pentru o calitate și un contrast cât mai b une.
<image -cropper
[imageChangedEvent] ="imageChangedEvent "
[maintainAspectRatio] ="true"
[aspectRatio] ="1 / 1"
[resizeToWidth] ="150"
[cropperMinWidth] ="150"
[onlyScaleDown] ="true"
[roundCropper] ="false "
format ="png"
outputType ="file"
(imageCropped) ="imageCropped ($event) ">
</image -cropper>

In momentul în care utilizatorul d ă click pe inputul cu fotografia, acestuia i se
deschide o fereastra de tip modal care permite selectarea unei fotografii din computerul
acestuia . Dup ă ce utilizatorul a selectat o fotografia, aceasta se deschide în fereastra modal ă
iar deasu pra ei apare un chenar selectabil pe care utilizatorul il poate modifica pan ă în
momentul în care acesta este multumit de alegere.

36

Figura 13 – Selectare și modificare poza CV
5.7 Dezvoltarea aplicatiei backend
Pentru dezvoltarea aplicatiei frontend s -a folosit Symfony versiunea 4.2.8, MySQL pentru
salvarea datelor în baza de date , JWT token pentru autorizare a cererilor spre rute și
WKHTMLTOPDF pentru generarea de documente PDF.
Symfony este unul din cele mai populare frameworkuri PHP . Un fra mework este similar cu o
bibliotecă și/sau o aplicație, însă are în plus următoarele caracteristici determinante:
• inversion of control (IOC) : fluxul datelor în program nu mai este dictat de apelant ci de
framework

37
• comportament implicit : chiar și atunci când nu este implemen tat nimic, framework -ul oferă
un comportament implicit funcțional
• extensibilitate : framework -urile pot fi extinse prin suprascrierea metodelor din obiectele
prezente în codul framework ului. Codul frameworkului nu trebuie modif icat, în schimb,
trebuie folosită moștenirea și adăugarea de componente noi pentru extinderea funcționalității.
Proiectele în Symfony sunt împărțite în aplicații, care la rândul lor sunt împărțite în
module. Modulele sunt legate de modele reale de date, pr ezente în baza de date. Folosin d
fișierele de configurare ale proiectului și utilitarul din linie de comandă pus la dispoziție de
Symfony se definește legătura la baza de date, se explicit ă configur ări ale fiec ărui bundle
inclus în aplicatie specific pentr u fiecare environmnent pe care ruleaz ă aplicatia, se generează
tabele sau date și modulele aferente fiecărei entitati definit e în proiect.
5.7.1 Autorizare

Deoarece aplicatia de backend este un API, acesta este stateless și nu păstreaz ă datele intre
cereri. Deoarece este nevoie de autorizare pentru cererile spre API, am ales în acest scop
JWT Tokens. JSON Web Token (JWT) este un standard (RFC 7519) care definește un mod
compact și autonom pentru transmiterea sigură a informațiilor între diferite sisteme ca obiect e
JSON. Aceste informații pot fi verificate și de încredere deoarece sunt semnate digital. JWT –
urile pot fi semnate folosind un cod secret (cu algoritmul HMAC) sau o pereche de chei
publice / private utilizând RSA sau ECDSA.
Se poate spune că unul dintre cele mai mari cazuri de utilizare pentru JWT este
autorizarea. Putem genera un token JWT în backend care este specific unui utilizator, să
trimitem acest token către frontend și apoi frontendul poate trimite ace st token împreună cu
cererile de accesare a rutelor API protejate.
Tokenurile JWT pot avea un timp de expirare. Ele pot fi, de asemenea, generate fără
expirare, însă cele mai bun e practic i indica faptul ca acestea trebuie să aiba un timp de
expirare . Acest lucru va micsora pericolul ca un token să fie furat și utilizat pentru a accesa
rutele.
Atunci când se generează un token JWT, se foloseste un cod secret pentru a genera
tokenul. Doar serverul ar trebui să știe acest cod secret. Dacă cineva ar modifica datele
conținute în tokenul JWT, serverul nu mai poate decodifica tokenul și nu mai poate autoriza

38
cererea. Asta înseamnă că serverul poate avea încredere în orice JWT pe care îl poate decoda
și verifica.

5.7.2 Serializarea datelor
Pentru a permite o cât mai buna decuplare a codului de la request și pana la prelucrarea
datelor, în Symfony este posibil ă folosirea asa numitor „param converters” care se definesc
ca niste a dnotări în controller și care presupun convertirea parametrilor din cerere în obiecte
inainte ca acestea să ajung ă la metoda din controller. Mai apoi, în metoda din controller avem
acces la un obiect creat în „param converter” f ără a mai fi nevoie a con strui aici obiecte.
Principalul avantaj folosit aici este c ă datele se pot va lida, serializa sau manipula
inainte ca acestea să ajunga în metodele din controller, simplificand dificultatea codului
existent aici.
Luand ca exemplul SearchUsersConverter, care se apeleaza în momentul în care un
recruiter doreste să caute utilizatori după anumite criterii, acesta preia datele din query
salvandu -le intr -un array, iar mai apoi le serializeaza (folosind libraria jms/serializer) intr-un
obiect, denumit SearchUserDto (DTO=Data Transfer Object) care mai apoi este folosit în
controller pentru a prelua datele intr -un mod mai usor și convenabil.

39
public function apply (Request $request , ParamConverter $configuration ): bool
{
$query = $request ->query ->all();
try {
$searchUsers = $this ->serializer ->fromArray ($query , SearchUserDto:: class );
} catch (\Exception $e) {
throw new UnprocessableEntityHttpException( 'Data sent is not valid!' );
}

$param = $configuration ->getName ();
$request ->attributes ->set($param , $searchUsers );

return true;
}

5.7.3 Generarea unui document PDF

Pentru convertirea datelor introduse de utilizator în format PDF s -a folosit utilitarul
WKHTMLTOPDF .exe care permite convertirea unui document HTML în PDF. Utilizatorul
introduce niste date în formular, le salveaz ă, apoi cere downloadarea documentului PDF.
Cererea se trimite rutei din aplicatia backend, care ia datele din baza de date corespunzatoare
CV-ului cerut, selecteaz ă template -ul HTML pe baza campului „template” d in baza de date,
construieste template -ul cu datele și mai apoi trimite cererea serviciului WKHTMLTOPDF.
Acesta salveaza HTML -ul templateului intr -un fisier temporar în cache -ul aplicatiei, face
conversia în PDF, după care sterge fisierul temporar și returneaz ă un răspuns cu headerul
„Content -type: application/pdf” care permite downloadarea documentului PDF.

40
Figura 14 – Flow convertire date de intrare în PDF

5.8 Testarea

Toolurile de testare automată din ziua de azi oferă o alternativă la metodele de testare
manuală, deoarece testele sunt executate rapid și în mod repetat. Mai mult, rezultatele testelor
pot fi comparate automat cu rezultatele comportamentului așteptat, iar diferențele pot fi astfel
evidențiate. Testarea automată presupune u n efort inițial. Beneficiile viitoare sunt
semnificative deoarece se traduc în stabilitate mărită. PHPUnit este un tool util pentru
testarea automată a aplicațiilor web, fiind foarte ușor și rapid de instalat.
În contextul actual, livrarea rapidă pe piață este crucială, iar erorile și bugurile nu sunt
foarte tolerate. Prin urmare, este important să se livreze produse de calitate. Deoarece
asigurarea calității nu este un obiectiv principal din cauza unor constrângeri precum timpul,
costul, resursele, acest a spect este doar parțial acoperit în munca efectivă. Consecința
imediată este o experiență negativă a utilizatorului.
Testare manuală are probleme de fiabilitate, deoarece este laborioasă și înceată. De
exemplu, până când se descoperă un bug, se vor uita de taliile importante care trebuie
reproduse. De asemenea, rezultatele testelor manuale ar trebui să fie bine documentate de
tester pentru a funcționa ca reper pentru alți testeri. Din aceste motive, testarea este o
disciplină în cadrul căreia automatizarea p oate ajuta cu adevărat.
Prin comparație cu testarea manuală, testarea automată aduce mai multe îmbunătățiri
la procesul de dezvoltare de software cum ar fi calitate software îmbunătățită: testele
automate repetabile și consistente fac mai ușoară livrarea d e software de calitate,
documentatia imbunatatita sau timpul redus pentru testare, testele odata create pot fi rulate de
mai multe ori fara costuri suplimentare, fiind și mai rapide decat cele manuale.
In continuare se va prezenta modul în care PHPUnit a fost integrat în aplicatie precum
și adaugarea unor teste și rularea lor.
Pentru inceput se instaleaza pachetul „symfony/phpunit -bridge” care contine
PHPUnit, pe aplicatia de backend. Se creaza configurarile specifice pentru mediul de test,
deoa rece aici se lucreaza cu date de test. Deoarece vom testa functional mai multe rute care
necesita autorizare, se va crea un client care are adaugat JWT token -ul în header pentru a

41
putea accesa rutele și a nu primi eroare 401 Unauthorized. Codul pentru crea rea clientului
este adaugat intr -un „trait” pentru că poate fi adaugat în mai multe clase de test, nefiind
nevoie a copia codul în toate clasele.
protected function createAuthenticatedClient ($username = user, $password = pass)
{
$client = static ::createClient ();
$client ->request (
'POST' ,
'/login_check' ,
[],
[],
['CONTENT_TYPE' => 'application/json' ],
json_encode([
'username' => $username ,
'password' => $password ,
])
);

$data = json_decode( $client ->getResponse ()->getContent (), true );

$client = static ::createClient ();
$client ->setServerParameter ('HTTP_Authorization' , sprintf( 'Bearer %s' , $data ['token' ]));

return $client ;
}
Acesta efectueaza o cerere de tip POST la ruta de login pentru a primi tokenul iar mai
apoi il adauga în headerul HTTP_Authorization pentru ca cererile să fie autorizate.
In continuare se creaza clasele de test. Pentru fiecare clasa creata în proiect, se adauga
o clasa de test noua care intr -un mediu favorabil, va acoperi toate cazurile posibile pe care
clasa le poate avea. Clasele de test trebuie să implementeze clasa abstracta WebTestCase în
cazul testelor functionale sau Test Case în cazul testelor unitare.
O me toda de test pe controllerul UserController care caută toti utilizatorii care
vorbesc limba engleza se poate crea în felul urmator:
/**
* @return void
*/
public function testShowAllUsersThatSpeakEnglish (): void
{
$language = 'engleza' ;
$client = $this ->createAuthenticatedClient ();
$client ->request ('GET' , '/api/users/search?language=' . $language );
$result = json_decode( $client ->getResponse ()->getContent ());

self::assertCount (2, $result );
}

42
Metodele statice „assert” sunt cele care confirm ă că datele din r ăspuns corespund unei
valori asteptate . Pentru exemplul de mai sus, stim că exista 2 utilizatori care au completat
CV-urile cu limba engleza și deci testul va trece.
1. Se mai cre ează incă 2 metode de test; una pentru a confirma că numărul total
de utilizatori este 4 și incă o metoda pentru a afisa toti utilizatorii care au titlul
jobului „java developer ” și care vorbesc limba german ă. Pentru aceast ă
metod ă se creeaz ă un utilizator nou cu aceste campuri și mai apoi se confirm ă
că datele utilizatorului sunt cele asteptate.
Pentru a rula testele și a vedea daca acestea au fost create corect, se ruleaza comanda
„php bin/phpunit” iar dac ă acestea au trecut, se va afisa un mesaj precum:

6. Utilizarea aplicatiei
6.1 Descriere
Aplicația permite utilizatorilor normali să creeze CV -uri iar recruiterilor să vizualizeze date
despre utilizatori, date prezente în documentele create de acestia . Scopul principal al
aplicației este să permită utilizatorilor crearea unui CV customizabil bazat pe ce informatii
doresc aceștia să afiseze pe el . În plus, utilizatorii pot selecta din mai multe formate pe care le
pot previzualiza în timp real, cu inform atiile actualizate în ecranul de previzualizare.
O altă facilitate a aplicației este posibilitatea de trimitere a CV -ului direct pe o adresa
de email specificata de utilizator .
Pentru recruiteri, aceștia au posibilitatea de a căuta utilizatori ai aplicatiei bazat pe
mai multe criterii, aceștia find afisati în cazul în care criteriile se regasesc pe datele
completate pentru CV -uri.

43
6.2 Prezentare scenarii de utilizare
Pentru exemplificarea scenariilor de utilizare, vom presupune mai intai că avem un utilizator
cu rol de recruiter (ROLE_RECRUITER) care doreste să caute niste utilizatori bazat pe mai
multe criterii, pentru un post de “php developer ” pe care recruiteaza. Presupunem că
utilizatorul este deja logat.

Figura 15 – Cautare utilizatori

Acesta este ecranul unde utilizatorul intră pentru a initia o c ăutare. Dup ă completarea
criteriilor de c ăutare, se apasa butonul „Search” care initiaza o cerere spre ruta de c ăutare a
utilizatorilor, care mai apoi caută în baza de date după criteriile completate.

44

Figura 16 – Vizualizare utilizatori
In ecranul de vizualizare a liste de utilizatori, un recruiter poa te vedea numele și data
la care s-au inregistrat, statusul utilizatorului precum și 2 butoane de actiune, unul pentru a
downloada cv -urile utilizatorului și unul pentru a -i trimite email la adresa salvat ă de acesta în
cont.
Pentru un utilizator care doreste să creeze un CV, cu ROLE_USER, cea mai
importanta facilitate pe care o ofera aplicatia este ace ea de a crea un CV. Formularele și
previzualizatorul de CV -uri este prezentat pe aplicatie după cum urmeaza în screenshotul
urmator:

45

Figura 17 – Creare și previzualizare CV
Acesta include pe partea stang ă un formular cu toate datele pe care acesta le poate
introduce în CV, template -ul pe care il poate alege cât și o poza pentru formatele care accepta
acest lucru. Pe partea dreapta este previzualizatorul care afiseaza în timp real modul în care
CV-ul va ara ta în momentul în care utilizatorul il va downloada. Deasupra acestuia exista 3
butoane cu ajutorul carora se poate salva, downloada sau trimite pe email CV -ul. în
momentul în care utilizatorul apas ă pe butonul „Save”, datele introduse în formular vor fi
trimise la server pentru a fi salva în baza de date iar mai apoi butonul va deveni inactiv pan ă
cand utilizatorul nu modifica din nou datele din formular. Butonul „Email” va deschide o
fereastra de tip popup peste ecran care va permite utilizatorului definirea unei adrese de email
unde să fie trimis CV -ul ca și atasament, acesta fiind prezentat mai jos:

46
Figura 18 – Trimitere CV pe email
Zona de administrare a profilului unui utilizator este prezentata mai jos. Aceasta
include un formular pe care utilizatorul poate să își modifice numele și adresa de email, un
buton care redirectioneaza pe o pagina unde utilizatorul își poate salva parola, o lista a CV –
urilor create pan ă acum cu un buton care duce la zona de editare a documentului cât și un
buton care permite stergerea contului impreun ă cu toate datele legate de contul ace stuia.

Figura 19 – Vizualizare date profil

47

Concluzii
Dezvoltarea aplicației a necesitat utilizare a multor cunoștințe practice și teoretice învățate în
facultate, cum ar fi: protocoale de comunicații, programare și design orientate obiect, baze de
date sau ingineria programelor. În plus, au fost necesare acumularea unor cunoștințe teoretice
noi, cât și învățarea utilizării unor tehnologii noi.
Dezvoltarea serverului mi -a permis să studiez arhitectura RESTful pentru servicii web
și să învăț să implementez un astfel de serviciu folosind framework -ul Symfony și
comunicarea prin intermediul unui API de la aplicatia client . Prin studierea diverselor
exemple am ales să implementez un design ierarhic al claselor resursa http, și o clasă de
stocare a datelor, accesibilă din toate resursele serverului. De asemenea, am folosit elemente
de detaliu ale protocolului http, cum ar fi metodele specifice protocolului și headerul de
Content -Type, care mi -au permis să trimit diferite tipuri de date în pa chetele http.
Din punct de vedere al clientului, am învățat concepte importante de programare pe
frameworkul Angular . Pentru a realiza cererile HTTP de la aplicatia client către API, am
explorat modulul angular -http, prin care dezvoltatorului i se o feră toate mecanismele necesare
crearii de cereri și primirii de raspuns în diferite tipuri de raspuns. Comunicația între client și
server mi -a lăsat la alegere conceper ea diverselor tipuri de mesaje, serializate în mod diferit ,
care alcătuiesc protocolul aplicației.
În viitor, aplicația poate fi dezvoltată, pentru a permite diverse facil ități noi. În primul
rând, se poate integra logarea și inregistrarea cu o retea sociala precum Facebook , pentru o
mai usoara utilizare a aplicatiei . De asemenea se pot adauga butoane noi în pagina de
previzualizare a CV -ului pentru a printa documentul sau pentru a face share pe o retea sociala
sau alte canale media.
Alte îmbunătățiri care pot fi adu se aplicației sunt: o interfata mai informativă a
aplicației, care să descrie modul de utilizare a aplicatiei pentru utilizatori , devoltarea unu i
sistem de plata pentru recruiteri pentru a monetiza aplicatie, permitand accesul acestora în
baza unui abonament lunar să a unei placi unice de acces care să permita cautarea
utilizatorilor , posibil itatea adaugarii mai multor tipuri de sectiuni în CV sau a unui sistem de
Drag & Drop a sectiunilor care să permita mutarea libera a acestora unde doreste utilizatorul,
oferind astfel posibilitatea unei customizar i mai bune a documentului . De asemenea, ar fi util
de implementat mai multe template -uri din care utilizatorii să poata alege sau posibilitatea

48
modific ării culorii textului, alegerea fontului și a mărimii acestuia și a alinierii spatierii în
document.

49

Bibliografie
*** Cum să scrii un CV – Ghid complet : https://resumegenius.com/how -to-write -a-resume
*** Acesta este exact ceea ce managerii și recrutorii căuta când citesc un CV:
https://www.glassdoor.com/blog/scanning -resumes/
*** 6 seconds este timpul mediu de citire a unui CV: https://www.linkedin.com/pulse/six -seconds –
average -time-spent -reading -resume -andrew -j-friedman/
*** 5 mari greseli pe care managerul de recrutare de la Go ogle le vede pe un CV tot timpul:
https://www.themuse.com/advice/5 -huge -resume -mistakes -googles -head -of-hr-sees-all-the-time
*** Cum să scrii un CV: Recomandari pentru 2019: https://www.cv -library.co.uk/career –
advice/cv/how -to-write -a-cv-tips/
*** CV Europass – tot ce trebuie să stii: https://cariera.ejobs.ro/cv -europass -de-ce-nu-mai-este-la-
moda/
*** Testarea automata a aplicatiilor web: https://www.todaysoftmag.ro/article/2254/casperjs -testarea –
automata -a-aplicatiilor -web
*** Considerații privind arhitectura aplicațiilor Web, SummerIs : http://itransfer.space/consideratii –
privind -arhitectura -aplicatiilor -web/