Aplica ție de ticket -ing ș i urmă rire a task -urilor în cadrul unei corporaț ii [626216]

Universitatea “Politehnica” din București
Facultatea de Electronică, Telecomunicații și Tehnologia Informației

Aplica ție de ticket -ing ș i urmă rire a task -urilor în cadrul unei corporaț ii

Proiect de diplomă
prezentat ca cerință parțială pentru obținerea titlului de
Inginer în domeniul Electronică si Telecomunicații,
programul de studii de licență Tehnologii și Sisteme de Telecomunicații

Conducator științific Absolvent: [anonimizat]. Dan GALAȚCHI Constantin -Cătălin POSEA

2017

Listă acronime

PHP – Hypertext Preprocessor
HTML – Hypertext Markup Language
CSS – Cascading Style Sheets
HTTP – Hypertext Transfer Protocol
MVC – Model -View -Controller
DBAL – “strat” de abstractizare pentru baza de date
URL – Uniform Resource Locator
GUI – Graphic User Interface

Introducere

Această lucrare are ca scop realizarea unei aplicații web, ce are rolul de a administra si urmări task-urile
ce sunt asignate că tre u tilizatori. Ierarhia utilizatorilor este diviz ată în 3 tipuri: user, manager ș i
administrator.

Rolul de user este asignat automat c ătre un utilizator atunci c ând se înregistrează, rolul de manager este
asociat unui user de că tre administrator, iar administratorul re prezintă persoana care gestionează
activitatea din firmă. În scopul realizării acestei aplicații am utilizat următoarele tehnologii: Framework –
ul Symfony, PHP, My SQL, Jquery, Javascripts, HTML, CSS, etc.

În cadrul primului capitol se va prezenta schema bazei de date împreun ă cu constrângerile acesteia, dar
și legăturile dintre t abele. Tot aici se va prezenta ș i diagrama relațională a bazei de date .
În cel de -al doilea capitol se va discuta despre rolurile angajaților, precum si despre drepturile pe care
aceștia le au .
Cel de -al treilea capitol va cuprinde noțiuni generale despre tehnologiile utilizate,c ât și o scurtă descriere
a paginii web.
Cel de -al patrulea capitol va descrie cum a fost implementată aplicația cu ajutorul tehnologiilor descrise
în capitolul anterior, dar și interfața acesteia în funcție de rolul utilizatorilor.
În ultimul capitol se va vorbi despre concluziile ș i metodele de prevenir e a intruziunilor asupra bazei de
date.

1. Schema b azei de date cu constrângerile ș i legăturile necesare

1.1 Structura tabelelor

Baza de date a fost creată cu a jutorul framework -ului Symfony ș i aplicației XAMPP ce creea ză o
conexiune între framework ș i sql. Fiecare tabelă din baza de date reprezintă o entitate în S ymfony. În
cadrul fiecărei entități creat e, atunci câ nd i se adaugă un nou câmp ,trebuie să se specifice numele
câmpului , tipul de dată , dar și constrângerile n ecesare . În scopul realizării acestei aplicații web am folosit
baza de date ce cuprinde următoarele tabele:

1.1.1 Tabelul user

Tabelul user : reprezintă entitatea Base User din cadrul framework -ului symfony ș i este creată de către
acesta utilizând FOSUserBundle. FOSUserBundle este o componentă a acestui framework ce este
utilizată pentru a crea, modifica sau șterge useri dintr -o bază de date. Acesta creează automat entitatea
user atunci câ nd este instalat în cadrul proiectului și vine cu un număr de stul de mare de coloane î n tabel a
user. Pe lângă aceste coloane, ce su nt im plicite, se pot adăuga oricâ nd altele noi.
Structura tabelului user este următoarea :

Figura 1.1 Structura tabelului user

Câmpurile tabelulu i user sunt id (INT – valoare întreagă), department_id (INT – valoare întreagă) care
este cheie străină către tabelul departament , proi ect_id (INT – valoare întreagă) care la rândul său este
cheie străină către tabelul proiect , username (VARCHAR), username_canonical (VARCHAR), email
(VARCHAR), email_canonical (VARCHAR), enabled (TINYINT), salt (VARCHAR), password
(VARCHAR), last_login (DATETIME), confirmation_token (VARCHAR), password_req
(DATETIME), roles (LONGTEXT), active_flag (SMALLINT), fname (VARCHAR), lname
(VARCHAR).
Cheia prim ară a unui tabel din baza de date are valori distincte pentru toate rândurile din tabel și are
rolul de identificator unic al acestora, iar cheia străină reprezintă câmpul ce conține valorile
corespunzătoare valorilor din cheia primară a altui tabel .

– Câmpul id din tabelul user este cheie primară.
– Câmpul department_id ce poartă constrângerea de cheie străină , poate conține valorile ce se
regăsesc și în câmpul departament_id din tabelul Departament. Această valoare este null până
atunci când userul este inclus într -un department.
– Câmpurile username_canonical si email_ canonical poartă constrângerea de chei unice, deoarece
nu se pot înregistra 2 utilizat ori cu același username sau acee ași adresă de email.
– Câmpul confirmation_token poartă constrângerea de cheie unică. Acesta reprezintă jetonul de
confirmare generat fiecărui utilizator atunci când se utilizează înregistrarea prin confirmare a
adresei de email și trebuie să fie unic pentru fiecare utilizator în parte .

Tipul VARCHAR se folosește pentru șiruri de caractere de lungime variabilă. Proprietatea
AUTO_INCREMENT indică modul de formare a coloanei id.
Tipul de dată DATETIME utilizează TIMESTAMP și oferă posibilitatea de a data automat operațiile de
tip “creează ” și “update ”, implicit este format din 14 caractere pentru formatul ‘YYYYMMDDhhmmss’ ,
dar putem specifica la crearea tabelului câte caractere să conțină. Câmpurile ce au bifată coloana cu allow
nulls specifică faptul că acele câmpuri pot primi ca intrări valori de null.

1.1.2 Tabelul departamente

Tabe lul departamente este compus din câmpurile : id (INT) ce are proprietatea de AUTO_INCREMENT ,
dar și de cheie primară, nume (VARCHAR), organization_id (INT), created (DATETIME), updated
(DATETIME) și status (INT).

Figura 1.2 Structura tabelului departamente

1.1.3 Tabelul proiect

Tabelul proiect are în componența sa câmpurile id (INT) , ce este cheie primară , nume (VARCHAR),
created (DATETIME), updated (DATETIME), desc riere (VARCHAR) și status (INT).

Figura 1.3 Structura tabelului proiect

1.1.4 Tabelul task

Tabelul task este format din câmpurile : id (INT), assigned_to_id (INT) și assigned_by_id (INT) ce sunt
chei străine către tabelul user , proi ect_id (INT) este cheie străină către tabelul proiect, title (VARCHAR),
description (VARCHAR), status (INT), created_at și updated_ at car e sunt de tipul DATETIME și se
setează automat a tunci când se inserează sau se updatează un task. Câmpurile assigned_to_id și
assigned_by_id sunt chei străine și pot conține valorile ce se află în cheia primară “id” din tabelul User,
iar câmpul proiect_id este tot cheie străină ce poate conține valorile din cheia primară “proiect_id” a
tabelul ui Proiect.

Figura 1.4 Structura tabelului task

1.2 Relaționările și constrângerile tabelelor

Relaționările și constrângerile ce se fac între tabelele bazei de date se reali zează î n cadrul fiecărei entități
create în symfony. Există 4 tipuri de relaționări ce se pot realiza cu ajutorul acestuia :

1. One-To-One
2. One-To-Many
3. Many -To-One
4. Many -To-Many

În tabelul User au fost declarate 2 chei străine, ce reprezintă relaționări de tipul Many -To-One în
interiorul entității User din cadrul symfony , deoarece un utilizator poate fi inclus în mai multe
departamente sau în mai multe proiecte. Din perspectiva ta belelor departa ment sau proiect, tipul
relațion ării va fi de tipul One -To-Many, pentru că un departament sau un proiect poate fi asignat către
mai mulți utilizatori. Pe lângă aceste relaționări ce le pr imesc câmpurile departament_id ș i proi ect_id,
acestea primesc și const rângerea de a accepta null ca valoare de intrare. Codul PHP ce realizează aceste
relaționări cu alte tabele și constrângerile necesare se vor scrie î n clasa U ser și arată a stfel:

/**
* @var Departament
*
* @ORM \ManyToOne( targetEntity="LicentaBundle \Entity \Departament", inversedBy="users")
* @ORM \JoinColumn(name="departament_id", referencedColumnName="id", nullable=true)
*/
protected $departament;

/**
* @var Proiect
*
* @ORM \ManyToOne(targe tEntity="LicentaBundle \Entity \Proiect", inversedBy="users")
* @ORM \JoinColumn(name="project_id", referencedColumnName="id")
*/
protected $proiect;

Pentru a crea câmpul departament_id, mai intâi se declară tipul de variabilă, în acest caz fii nd de tipul
Departament, apoi se specifică ce tip de relaționa re va exista între tabela user ș i tabela departament ,
aceasta fiind de tipul ManyToOne. Se specific ă în paranteze entitatea țintă și proprietatea din această
entitate țintă ce se referă la obiec tul user (inversedBy = ”users”) . Apoi se vor specifica numele coloanei
din tabelă, precum și constrângerile ce intervin asupra acesteia (nullable = true , ce ne indică faptul că
această coloană poate primi valoarea null ), iar la final se va seta un nume pro prietății ce va fi asociat unui

identificator de acces (protected $departament) . În cazul celui de -al doilea câmp, procedura este aceeași
ca la departament, numai că de data aceasta ne vom referi la entitatea proiect.

Pentru ca relaționările între tabelele user, departament și proiect să fie complete t rebuie ca în clasele
Proiect și Departament să definim proprietatea “users” c e va fi de tipul One -To-Many și va arăta în felul
următor:

– În interiorul clasei Departament se va specifica tipul relaționă rii, entitatea țintă care, în cazul de
față, este User, precum și obiectul la care se referă (mappedBy = ” departament”), care a fost
declarat în clasa User :

/**
* @ORM \OneToMany(targetEntity="LicentaBundle \Entity \User", mappedBy="departament")
*/
private $users;

– În interiorul clasei Proiect se va repeta același proces, numai că de data aceasta obiectul la care
se referă users (mappedBy = “proiect”) va fi proprietatea proiect declarată în interiorul clasei
User:

/**
* @ORM \OneToMany(targetEntity="LicentaBundle \Entity \User", mappedBy="proiect")
*/
private $users;

În tabelul Task s-au definit 3 chei străine, acestea reprezintă relaționări de tipul Many -To-One ce s -au
definit în cadrul entității Task. Primele 2 chei străine le reprezintă câmpurile assigned_to_id și
assigned_by_id ce au ca entitate țintă tabelul User, deoarece un task este creat si asignat către un
utilizator, iar cea de -a treia cheie străină o repre zintă câmpul p roject_id, deoarece atunci când se creează
un task va trebui să -i corespundă unui proiect. Clasa Task va conține următoarele bucăți de cod pentru a
se putea realiza relaționările între tabelele task, user și proiect:

/**
* @ORM \ManyToOne(targetEntity="LicentaBundle \Entity \User", inversedBy="tasks")
* JoinColumn(name="assigned_to", referencedColumnName="id", nullable=false)
*/
private $assignedTo;

/**
* @ORM \ManyToOne(targetEntity="LicentaBundle \Entity \User", inversedBy="tasks")
* JoinColumn(name="assigned_by", referencedColumnName="id", nullable=false)
*/

private $assignedBy;

/**
* @var int
*
* @ORM \ManyToOne(targetEntity=" LicentaBundle \Entity \Proiect", inversedBy="tasks")
* @ORM \JoinColumn(name="project_id", referencedColumnName="id" , nullable =false )
*/
private $proiect;

Primul câmp î l reprezintă cheia st răină că tre tabelul user, care este o relaționare de ti pul Many -To-One
din perspectiva tabelului Task, deoarece un task poate fi asignat către mai mulți utilizatori, deci o să
primească ca pa rametri en titatea țintă User și obiectul de tip tasks definit î n interiorul clasei User.
Singurele constrângeri ce inter vin asupra acestui câmp din tabela task le reprezintă cheia străină si faptul
că acest câmp nu acceptă null ca valoare de intrare (pentru că atunci când se creează un task trebuie știut
de către cine a fost creat și către cine a fost asignat) . Cel de -al do ilea câmp este tot o c heie străină către
tabelul user, identică cu cea explicată mai sus, dar care se setează automat cu numele utilizatorului ce a
creat task -ul prin intermediul unui controller despre care voi discuta în alt capitol. A treia cheie străin ă
este proi ect_id care este tot o relaționare de tipul Many -To-One, deoarece pot exista mai multe task -uri
pe același proiect. Aceasta primește ca parametri entitatea țintă Proiect și obiectul de tip tasks declarat în
interiorul clasei Proiect. Constrângeri le ce intervin asupra acestui câ mp le reprezintă cheia străină ș i
faptul nu poate accepta null ca valoare de intrare (pentru că atunci când se creează un task trebuie știut
pe ce proiect este creat task -ul).
În cele din urmă, pentru ca relaționările între tabele le task, proiect și user să fie complete, trebuie
declarată proprietatea task s în interiorul tabelelor User ș i Proiect ce va fi de tipul One -To-Many, deoarece
un proiect sau un user poate fi asignat pe mai multe taskuri . Această proprietate va arăta astfel :

– În interiorul clasei User se va specifica tip ul relaționării, entitatea țintă care, în cazul de față, este
Task, precum și obiectul la care se referă (mappedBy="users") :

/**
* @ORM \OneToMany(targetEntity="LicentaBundle \Entity \Task", m appedBy="users")
*/
private $tasks;

– Din perspectiva clasei Proiect procedura este aceeași, numai că de data aceasta obiectul la care
se referă va fi ( mappedBy="proiect" ):

/**
* @ORM \OneToMany(targetEntity="LicentaBundle \Entity \Task", mappedBy="proiect")
*/
private $tasks;

1.3 Programe utlizate

XAMPP – acționează ca un web server capabil de a servi pagini dinamice utilizând limbaje de
programare ca și PHP. Este utilizat în general pentru dezvoltarea aplicațiilor web.
Acesta asigură suport pentru crearea si manipularea bazelor de date în MySQL.

HeidiSQL – este un instrument foarte folositor atunci cand se lucrează cu un server MySQL și limbajul
de programare PHP, deoarece un browser web nu se poate conecta direct la serverul MySQL. Această
conexiune între browser si baza de date se face prin intermediul limbajului de programare PHP care
poate stabili o conexiune cu baza de date si prelucra informațiile din aceasta (codul PHP ce arată cum
se creează un tabel nou în baza de date sau cum se realizează constrângerile între tabele a fost expus
mai sus la discuția despre tabele).

Symfony – în cadrul framework -ului va trebui să configurăm o conexiune cu baza de date, adică va
trebui să declarăm această conexiune în fișierul paramete rs.yml din cadrul proiectului. Mai multe
discuții despre această conexiune vor fi tratate în capitolele următoare.

1.4 Diagrama relațională a bazei de date

Figura 1.5 Diagrama relațională a bazei de date

2. Tipuri de utilizatori și drepturile acestora în cadrul aplicației

2.1 Tipuri de utilizatori

În scopul realizării acestei aplicații s -au introdus 3 tipuri de utilizatori :

– Utilizator
– Manager
– Admin istrator

1. Rolul de utilizator este asignat automat unui angajat în momentul în care acesta se înregistrează .
Drepturile pe care le au utilizatorii în cadrul aplicației se reduc la a crea , a modifica sau a
șterge un task și de a -și modifica setările personale.
2. Rolul de manager poate fi asignat unui utilizator n umai de către un administrator și reprezintă
persoana responsabilă de un departament în cadrul unei organizații . Drepturile ce îi revin
acestuia sunt de a crea, a modifica sau a șterge un proiect, dar au acces și la pagina
corespunzătoare task -urilor.
3. Rolul de administrator necesită un nume de utilizator și o parolă. Acesta are acces în orice
pagină a aplicație i, poate crea o organizație, un departament, un proiect sau un task și poate
asigna rolul de manager unui utilizator existent.

2.2 Diagrama de drep turi

Drepturile pe care le au utilizatorii în cadrul aplicației pot fi expuse și printr -o diagramă care arată în
felul următor:

Figura 2.1 Diagrama de drepturi în funcție de rolul utilizatorului

Etapele ce trebuie respectate pentru a se putea crea un task sunt următoarele :

1. Administratorul creează o organizație.
2. Administratorul creează un departament.
3. Administratorul sau managerul creează un proiect.
4. Administratorul, managerul sau userul pot crea un task acum, deoarece s -a creat un proiect, iar
un task trebuie să -i aparțină unui proiect.

2.3 Matrice a de drepturi în funcție de rolul utilizatorului

Tabelul 2.1 Matrice a de drepturi a utilizatorilor
Numele paginii Utilizator Manager Administrator
Acțiuni
Departamente
Adaugă un departament nou X
Editează un departament X
Șterge un departament X
Vezi toate departamentele X
Utilizatori
Vezi toți utilizatorii X
Șterge un utilizator X
Modifică drepturile utilizatorului X
Vezi toți utilizatorii X
Proiecte
Creează un proiect nou X X
Modifică un proiect deja existent X X
Șterge un proiect X X
Vezi toate proiectele X X
Task-uri
Adaugă un task nou X X X
Editează un task deja existent X X X
Șterge un task X X X
Vezi toate task-urile X X X
Acasă X X X

Așa cum este expus î n tabelul de mai sus, în funcție de rolul pe care utilizatorul îl deține în cadrul
firmei, acesta poate accesa numai anumite pagini. Accesul asupra fiecărei pagini se definește în fișierul
“security.yml” din cadrul proiectului symfony , unde se creează o no uă intrare numită “access_control” ,
ce necesită ca utilizatorul să fie autentificat sau nu pentru a putea accesa acest e URL -uri. Porțiunea de
cod c e stabilește aceste chestiuni legate de securitate arată astfel :

access_control:

– { path: ^/login$, role: IS_AUTHENTICATED_ANONYMOUSLY }
– { path: ^/register, role: IS_AUTHENTICATED_ANONYMOUSLY }
– { path: ^/resetting, role: IS_AUTHENTICATED_ANONYMOUSLY }
– { path: ^/departament, role: ROLE_ADMIN }
– { path: ^/user, role: ROLE_ADMIN}
– { path: ^/proiect, role: ROLE_ ADMIN }
– { path: ^/proiect, role: ROLE_MANAGER}

– Paginile de login, înregistrare și de resetare a parolei pot fi accesate de către oricine, chiar dacă
nu este înr egistrat.
– Pagina departamentelor și a utilizatorilor poate fi accesată numai de către un utilizator cu
drepturi de administrator.
– Pagina proiectelor poate fi accesată doar de către administrator si manager.
– Pagina task -urilor este accesibilă tuturor utilizatorilor aplicației, indiferent de drepturile
acestora, dacă aceștia sunt autentificați.

Mai multe detalii despre cum pot accesa utilizatorii aceste pagini și despre cum au fost create vor fi
discutate într -un capitol ulterior.

3.Tehnologii utilizate

3.1 Pagina web

Construc ția unei pagini web are la bază protocolul numit HTTP, care este un protocol rapid ce se
potrivește foart e bine cu sistemele multimedia, fiind distribuite în salturile dintre site -uri.
Web -ul are la bază pagini cu informa ții provenite de la gazde, ce rulează software de tip server web.
Web server -ul reprezintă un program ce furnizează paginile web la cerere. Spre exemplu, atunci
când un utilizator de la o anumită adresă IP solicit ă un anumit f ișier, server -ul web încearcă să obțină
fișierul respectiv și să-l trimită înapoi către utilizator. Fișierul poate fi codul sursă HTML al unei
pagini, un fișier de tip XML, o imagine,etc.

Pagina web reprezintă o resursă a spațiului web din Internet, care de obicei se regăsește în form at
HTML, dar și în a lte formate. Navigatorul afișează paginile web prin intermediul unor marcatori ,
definiți cu ajutorul li mbajului HTML , utilizați pentru a codifica pagina web cu informația ce se
dorește a fi afișată. Aceștia au diferite semnificații, de ex emplu, pot stabili modul în care va fi afișată
informația în pagină sau pot stabili legături între documente ș i fișiere.
În mod normal, o pagină web este legată de mai multe tipuri de fișiere, cum ar fi cele de tip text,
multimedia sau grafice. Denumirea că ii de acces î ntre aceste fișiere este hipertext.
În momentul în c are utilizatorul acționează prin click de mouse către o legătură, cum ar fi o imagine,
o porțiune de text, etc, navigatorul va incărca fișierul către care punctează legătura ș i îl va afișa.

Un site web reprezintă un ansamblu de informații prezentat sub forma unor pagini web, documente,
fișiere multimedia, dar si alte tipuri, între care există o cale de acces (legatură).
În momentul realizării unui site web to ate fișierele sunt păstrate, în mod uzual, într-un folder sau o
colecție de foldere pe hard disk -ul local ce trebuie să conțină software -ul, prin interme diul căruia
site-ul este transmis către navigatoarele web ale calculatoarelor conectate la Internet. Din momentul
în care site -ul este publicat, acest a se transformă din site local î n site web, interacțiunea utilizatorului
se desfășoară conform figurii 3.1.

Figura 3.1 Comunicația între navigatorul web și serverul web

3.2 Compozitorul

Compozitorul reprezintă u n instrument de linie de comandă, ce conți ne biblioteci de administrare
software care sunt scrise în limbajul PHP. Pe lângă faptul că el este un administrator de pachete (care
permite instalarea si organizarea bibliotecilor într -un mod standardizat), compozitorul detectează daca o
bibliotecă depinde de o altă bibliotecă și instalează automat toate bibliotecile necesare. Acest instrument
descarcă bibliotecile într -un folder numit “vendor/” care se află în folderul rădăcină al proiectului .
Cele mai utilizate linii de comandă ale compozitorului sunt:

– composer install: instale ază toate librăriile aflate în fișierul “composer.lock” din cadrul
proiectului
– composer update: actualizează toate librăriile la cea mai nouă versiune a acestora
– composer require <vendor/package>: instalează o nouă bibliotecă și o adaugă automat în fișier ul
“composer.json”, unde <vendor/package> reprezintă numele pachetului ce se dorește a fi instalat.
– composer update <vendor/package>: instalează sau actualizează o anume bibliotecă.

În cadrul proiectului, am folosit Compozitor ul pentru administrarea apli cației Symfony și pentru a
instala bibliotecile și pachetele necesare acesteia.

3.3 Limbajul PHP

3.3.1 Introducere în PHP

PHP reprezintă un limbaj de scripting utilizat pe scară largă, realizat și distribuit în sistem Open Source,
care a fost special conceput pen tru a putea construi pagini web dinamice. Sintaxa acestuia provine din
limbaje de programare precum C, Java și Perl și prezintă avantajul de a fi ușor de învățat. PHP permite
furnizarea unui conținut web dinamic, adică un conținut ce se poate modifica de l a un minut la altul.
Spre deosebire de limbajele de scripting, precum JavaScript, PHP rulează pe serverul web, nu în browser –
ul web. În consecință, acesta poate obține accesul la fișiere, la baza de date, dar și la alte resurse ce -i sunt
inaccesibile limb ajului JavaScript.
Există trei domenii principale unde sunt folosite scripturile PHP:

– Primul domeniu îl reprezintă scripturile ce rulează pe server. Acesta este cel mai important aspect
al PHP -ului și este nevoie de trei lucruri pentru ca el să funcționeze: interpretorul PHP, un browser
web și serverul web (ce trebuie să fie pornit și să aiba o conexiune de PHP instalată). Rezultatul
programelor PHP poate fi vizualizat cu ajutorul unui browser web prin intermediul serverului
web.
– Al doilea domeni u se ocupă de scripting -ul în linia de comandă. Codul PHP poate fi rulat fără a
fi nevoie un server si de un browser web, ci doar prin intermediul interpretorului PHP. Această
metodă este folosită de obicei pentru sarcini simple de procesare a textului.
– Ultimul domeniu vizează scrierea de aplicații ce rulează de partea clientului în mod grafic (GUI).
PHP nu este cel mai folosit limbaj pentru a scrie aplicații cu ferestre pentru Windows sau alte

sisteme de operare, dar dacă se dorește folosirea unor funcți onalități mai avansate ale acestuia în
aplicațiile ce rulează de partea utilizat orului, se poate folosi PHP -GTK, care reprezintă o extensie
a PHP -ului, nedisponibilă în distribuția principală.

PHP are sintaxa foarte asemănătoare cu limbajul C, la care s -au adăugat caracteristici necesare dezvoltării
aplicațiilor web. Instrucțiunile de bază sunt următoarele: if, for, which, switch, do while. Codul PHP
poate fi inclus în fișierele HTML sau po ate fi utilizat în fisiere cu extensia “.php” ce conțin doar cod
PHP. Pentru ca acesta sa fie executat de interpretor codul trebuie să fie inclus între tagurile PHP: “<?php
//aici trebuie să se afle codul ?>”.

3.3.2 Tipuri de dată si variabile le în PHP

PHP poate suporta opt tipuri de dată :
– Patru dintre acestea sunt tipuri s calare: string, float (numere în virgulă mobilă), integer și
Boolean.
– Două tipuri sunt compuse: array și obiect.
– Două tipuri ce sunt speciale: resource și null.
Programatorul nu trebuie sa declare tipul unei variabile, este decis la rulare de către PHP, în funcție de
contextual în care variabila este folosită.
Variabilele sunt reprezentate folosind un semn “$” urmat de numele variabilei, cu mențiunea ca aceste
variabile sunt case -sensitive. PHP dispune de un număr mare de variabile implicite. Multe dintre a cestea,
nu pot fi documentate deoarece sunt dependente de serverul pe care rulează, iar unele dintre ele nu vor
fi folosite atunci când PHP rulează în linie de comandă.

3.3.3 PHP Superglobals

$_SESSION – Conține variabilele registrate unei sesiunii a script -ului.
$GLOBALS – Reprezintă o referință la fiecare variabilă care este valabilă în scopul global al script -ului.
$_SERVER – Conține variabilele setate de serverul web sau legate direct de mediul de execuție al
scriptului.
$_GET – Reprezintă variabilele ofe rite script -ului prin HTTP GET.
$_POST – Reprezintă variabilele oferite script -ului prin HTTP POST.
$_COOKIE – Reprezintă variabilele oferite script -ului prin HTTP.
$_FILES – Conține variabilele oferite script -ului prin încărcarea de fișiere folosind modul POST din
HTTP.
$_ENV – Reprezintă variabilele oferite script -ului prin mediu.
$_REQUEST – Reprezintă variabilele oferite script -ului prin mecanismele de GET, POST și COOKIE.

3.3.4 Framework -urile PHP:

Pentru a se realiza dezvoltarea rapidă a aplicațiilor web, comunitatea PHP a dezvoltat o serie de
framework -uri web. Cele mai utilizate și populare dintre acestea sunt: CodeIgniter, CakePHP, Laravel,

Symfony, Yii, Zend, etc. În următoarea secțiune a acestui capitol vom discuta despre Symfony,
framework pe care l -am ales pentru dezvoltarea acestei aplicații.

3.4 Framework -ul Symfony:

3.4.1 Introducere în Symfony

Symfony are la baz ă limbajul PHP ce a fost descris în secțiunea anterioară . Acest framework a apărut
în anul 2005, este open source și a devenit unul dintre cele mai populare cadre de lucru PHP datorită
multiplelor avantaje, dar și a bunei documentații [1].

Arhitectura MVC este compusă din 3 nivele:
-Primul nivel îl reprezintă modelul (nivelul datelor) care conține partea de business lo gic și
interacțiunea cu baza de date.
-Cel de -al doilea nivel îl reprezintă view-ul (interfața utilizator) , acesta este responsabil de
interacțiunea cu utilizatorul și conține template engine -ul.
-Ultimul nivel este controller -ul (gestiunea interacțiunilor) și reprezintă o bucată de cod ce apelează
modelul în scopul obținerii de date ce urmează a fi transmise view -ului pentru a putea fi redate
utilizatorului.
Avantajele utilizării acestui ti p de arhitectură sunt următoarele : poate fi scrisă u șor și timpul de execuție
este mic. Acesta prezintă însă și dezavantaj ul inexistențe i unei verificări de eroare (dacă conexiune a cu
baza de date se întrerupe) .

ORM reprezintă o modalitate de programare ce face posibilă acc esarea și gestionarea datelor făr ă ca
programatorii să fie interesați de sursa acestora. Rolul ORM -ului este de a crea o conexiune î ntre limbajul
orientat pe obiecte cu câmpurile din baza de date, care să fie fiabilă ș i de durată.

Entitatea este o clasă în care sunt descrise coloanele un ei tabele ș i include metodele de setare și afișare
ale acestora. Această entitate poate fi generată î n 2 moduri: utilizând comanda “php bin/console
generate:doctrine:entity ” direct în terminal sau poate fi generată manual. În ambele situații, valorile
corespunzătoare coloan elor din baza de date trebuie s ă aibă o denumire, trebuie specificat tipul de dată
(ex: integer, s tring, float, etc) asociat fiecă reia, dar și da că acestea vor fi unice sau dacă pot accepta și
valori de null.

Rela țiile între aceste entități sunt de 4 tipuri:

1. One-To-One
2. One-To-Many
3. Many -To-One
4. Many -To-Many

Aceste relaționări trebuie să apară în fișierele de tipul “NumeEntitate.php” și se folosesc pentru a crea
chei străine sau chei primare în SQL. Spre exemplu, dacă avem o enitate numită Angajat și o entitate
numită Proiect, relaționarea o să fie de tipul One -To-Many din perspectiva ang ajatului, iar din
perspectiva proiectului o să fie de tipul Many -To-One.

CRUD
Utilizând comanda “php bin/console generate:doctrine:crud” în terminal, symfony va genera un
controller de baz ă pentru o anumită entitate. Acest c ontroller permite executarea celor 5 operații de bază
asupra unui model: afișează toate înregistrările de tipul entității respective, arată o anumită înregistrare
identificată după cheia primară, creează o nouă înregistrare, editează o înregistrare deja existent ă în baza
de date ș i șterge o înregistrare existen tă în tabel. Pe lângă aceste metode , de citire, adăugare, editare ș i
ștergere, CRUD -ul generează și paginile HTML de bază , corespunzătoare fiecărei metode în parte, care
pot fi modificate ulterior după bunul plac.

3.4.2 Structur a folderelor