Licentaolesea Pdf3 [616916]

UNIV ERSIT ATEA DIN CR AIOVA
FACULT ATEA DE ȘTIINȚ E
SPECIALIZAREA INFORMATICĂ

LUCR ARE DE LICENȚĂ

Îndrumăt or științific: Absolvent: [anonimizat]. univ. dr. P opîrlan Claudiu I onuț Goreanu Olesea

CRAIOVA
2020

UNIV ERSIT ATEA DIN CR AIOVA
FACULT ATEA DE ȘTIINȚ E
SPECIALIZAREA INFORMATICĂ

APLIC AȚIE JAVA SPRING
PENTRU PL ANIFIC AREA EVENIM ENTELOR ȘI
REZERVAREA LOCAȚIIL OR

Îndrumăt or științific: Absolvent: [anonimizat]. univ. dr. P opîrlan Claudiu I onuț Goreanu Olesea

CRAIOVA

2020

Cuprins

Lista de Tabele ………………………….. ………………………….. ………………………….. ………………………….. …… 5
Lista de figuri ………………………….. ………………………….. ………………………….. ………………………….. …….. 6
Abrevieri ………………………….. ………………………….. ………………………….. ………………………….. …………… 7
Introducere ………………………….. ………………………….. ………………………….. ………………………….. ……….. 8
1 Analiza domeniului d e studiu ………………………….. ………………………….. ………………………….. ……….. 10
1.1 Imp ortanța temei ………………………….. ………………………….. ………………………….. …………………… 10
1.2 D efinirea obiectivelor ………………………….. ………………………….. ………………………….. …………….. 10
1.3 D efinirea funcți onalitățil or sist emului ………………………….. ………………………….. ………………….. 11
1.4 R evizuir ea sistemelor simil are pe piață ………………………….. ………………………….. ………………… 12
1.5 T ehnologii utiliz ate ………………………….. ………………………….. ………………………….. ………………… 14
1.5.1 J ava ………………………….. ………………………….. ………………………….. ………………………….. ………. 14
1.5.2 Fr amework-uri ………………………….. ………………………….. ………………………….. ……………….. 15
1.5.2.1 Spring Fr amework ………………………….. ………………………….. ………………………….. …….. 16
1.5.2.2 Spring B oot ………………………….. ………………………….. ………………………….. ………………. 17
1.5.2.3 Spring MVC Fr amework ………………………….. ………………………….. ………………………… 18
1.5.2.4 Spring S ecurity ………………………….. ………………………….. ………………………….. …………. 19
1.5.2.5 ORM-UL Hib ernate ………………………….. ………………………….. ………………………….. ……20
1.5.2.6 B ootstrap ………………………….. ………………………….. ………………………….. ………………….. 21
1.5.2.7 Thym eleaf ………………………….. ………………………….. ………………………….. …………………. 22
1.5.2.8 jQu ery ………………………….. ………………………….. ………………………….. ……………………… 22
1.5.3 Apache Tomcat ………………………….. ………………………….. ………………………….. ……………….. 23
1.5.4 Apache Maven ………………………….. ………………………….. ………………………….. ………………… 23
1.5.6 MySQL ………………………….. ………………………….. ………………………….. ………………………….. .24
1.5.7 J ava Database Connectivity (JDBC) ………………………….. ………………………….. ………………. 26
2 Analiza aplicației din punc t de vedere arhitectural ………………………….. ………………………….. ……… 28
2.1 C erințele sistemului ………………………….. ………………………….. ………………………….. ……………….. 28
2.2 Di agramele cazuril or de utiliz are ………………………….. ………………………….. ………………………… 30
2.3 Infr astructur a sistemului inf ormatic ………………………….. ………………………….. ……………………. 32
3 Impl ementarea sistemului ………………………….. ………………………….. ………………………….. …………….. 36
3.1 Inst alarea JDK 8 ………………………….. ………………………….. ………………………….. …………………… 36
3.2 Iniți alizarea proiectului Spring B oot ………………………….. ………………………….. ……………………. 38
3.3 M ediu d e dezvoltare integrat (Eclips e) ………………………….. ………………………….. …………………. 40
3.4 Cl asele si componentele sistemului ………………………….. ………………………….. ………………………. 41
3.5 R ealizarea bazei de date ………………………….. ………………………….. ………………………….. …………. 50

3.6 D escrierea aplicației ………………………….. ………………………….. ………………………….. ……………… 55
4 Concluzi e ………………………….. ………………………….. ………………………….. ………………………….. ……….. 62
4.1 R ealizarea obiectivelor propuse ………………………….. ………………………….. ………………………….. .62
4.2 D ezvoltări ult erioare ………………………….. ………………………….. ………………………….. ……………… 62
Bibli ografie ………………………….. ………………………….. ………………………….. ………………………….. ……….. 64

Lista de Tabele

Tabel 3. 1 – User ………………………….. ………………………….. ………………………….. …………………. 52
Tabel 3. 2 – Contact ………………………….. ………………………….. ………………………….. ……………… 53
Tabel 3. 3 – Reservation ………………………….. ………………………….. ………………………….. ……….. 53
Tabel 3. 4 – Location………………………….. ………………………….. ………………………….. ……………. 53
Tabel 3. 5 – Customer ………………………….. ………………………….. ………………………….. ………….. 54
Tabel 3. 6 – Meeting ………………………….. ………………………….. ………………………….. …………….. 54
Tabel 3. 7 – Role ………………………….. ………………………….. ………………………….. …………………. 54
Tabel 3. 8 – Users Roles ………………………….. ………………………….. ………………………….. ……….. 54
Tabel 3. 9 – Request Inf o ………………………….. ………………………….. ………………………….. ………. 55

Lista de Figuri

Figur a 1. 1 – Interfața aplicației FortunaEvenimente………………………….. ………………………….. .. 13
Figur a 1. 2 – Interfața aplicației AVANGARDE EVENTS ………………………….. …………………… 13
Figur a 1. 3 – Structur a Spring Fr amework ………………………….. ………………………….. …………….. 16
Figur a 1. 4 – Structur a Spring B oot ………………………….. ………………………….. ……………………… 17
Figur a 1. 5- Avantaje Spring B oot ………………………….. ………………………….. ………………………. 18
Figur a 1. 6 – Arhitectura Spring MVC ………………………….. ………………………….. …………………. 18
Figur a 1. 7 – Componentele implic ate în mecanismul ORM. C ele doua entități sunt p ersistate .. 21
Figur a 1. 8 – Modul d e funcți onare a JDBC ………………………….. ………………………….. …………… 27

Figur a 2. 1 – Diagrama cazurilor de utiliz are pentru Gu est ………………………….. …………………… 30
Figur a 2. 2 – Diagrama cazurilor de utiliz are pentru Administr ator ………………………….. ………… 31
Figur a 2. 3 – Diagrama cazurilor de utiliz are pentru M anager………………………….. ……………….. 32
Figur a 2. 4 – Fluxul un ei cereri HTTP în Spring MVC ………………………….. ………………………… 33

Figur a 3. 1 – Calea către JDK și JR E ………………………….. ………………………….. ……………………. 37
Figur a 3. 2 – Setarea variabilei PATH în Wind ows ………………………….. ………………………….. … 38
Figur a 3. 3 – Inițializarea proiectului cu Spring Initi alizr ………………………….. ……………………… 40
Figur a 3. 4 – Structur a proiectului ………………………….. ………………………….. ……………………….. 42
Figur a 3. 5 – Diagrama bazei de date ………………………….. ………………………….. ……………………. 51
Figur a 3. 6 – Pagina princip ala a proiectului ………………………….. ………………………….. ………….. 57
Figur a 3. 7 – Portofoliu Cli entului ………………………….. ………………………….. ……………………….. 57
Figur a 3. 8 – Forma de contact pentru cli enți ………………………….. ………………………….. …………. 58
Figur a 3. 9 – Pagina pentru cli enți ………………………….. ………………………….. ……………………….. 58
Figur a 3. 10 – Pagina cu detalii pentru fi ecare locație în parte ………………………….. ………………. 59
Figur a 3. 11 – Forma de autentificare ………………………….. ………………………….. …………………… 59
Figur a 3. 12 – Formă d e autentific are invalidă ………………………….. ………………………….. ……….. 60
Figur a 3. 13 – Vizu alizarea listei de locații cu r ol de Administr ator ………………………….. ……….. 60
Figur a 3. 14 – Vizu alizarea listei de locații cu r ol de Manager ………………………….. ………………. 61
Figur a 3. 15 – Forma de adăug are a locațiilor ………………………….. ………………………….. ………… 61

Abrevieri

POJO – Plain Old Java Object
AOP – Aspect Oriented Programming
IoC – Inversion of Control
JPA – Java Persistence API
JDBC – Sisteme de Gestiun e a Bazelor de Date
MVC – Model View Controller
LDAP – Lighw eight Dir ectory Acces Protocol
ORM – Object/ R elational Mapping
API – Applic ation Programming Int erface
CRUD – Create, Read, Upd ate, Delete
HTTP – Hypertext Tr ansfer Protocol
JSP – Java Server Pages
POM – Project Object M odel
DOM – Document Object M odel
SDLC – Software Design Lif e Cycl e
URL – Uniform R esource Locator
JDK – Java Development Kit
JVM – Java Virtu al Machine
JRE – Java Runtim e Environment
IDE – Integrated Development Environment

Goreanu Olesea
8
Introducere
Lucr area dată, care reprezintă t eza de licență, are ca scop descrierea detaliată a tezei și a
fișierului d e studiu. D escrierea începe cu analiza domeniului, pl atformelor și limb ajelor care vor
fi utiliz ate cu toate avantajele si explic ația cauzei utilizării l or.
În ultimii 10 ani, tehnologia a avut un imp act m are încercând să ușur eze cât m ai
semnific ativ vi ața oamenilor. Acum sunt p osibile cumpărăturil e online, rezervarea unui h otel sau
chiar efectuarea unei programări l a un m edic având d oar un disp ozitiv cu c onexiune la internet și
un card de credit. Trăim în epoca în care toți sunt em în c ontinuă mișc are și fiecare minut îns eamnă
bani. Astfel, obiectivul princip al al proiectului este de a oferi utiliz atorului p osibilit atea de a-și
crea evenimentul d orit într -un m od rapid și uș or cu ajutorul sp ecialiștilor în d omeniu și d e a rezerva
locația pentru eveniment fără a se deplasa la locul d orit.
Examinând m ajoritatea platformelor existente, am constatat că ele se ocupă în c ea mai mare
parte de organizarea evenimentelor nu și d e rezervarea locațiilor pentru acestea. Luând în
considerare cele observate, s-a ajuns l a concluzi a că ar fi n ecesară o aplicație compactă p entru
utiliz atori care să dețină funcți onalitățil e menționate mai sus.
În continu are se va prezenta structur a lucrării p e capitole și o descriere pentru fi ecare din
ele.
Capitolul 1- Analiza domeniului și t ehnologiile folosite în impl ementarea sistemului
În cadrul acestui c apitol sunt pr ezentate importanța, obiectivele proiectului pr opus și
funcți onalitățil e acestuia. Este prezentată o comparație a sistemului c are s-a realizat și a sistemelor
asemănăt oare disponibile în pr ezent. D e asemenea, au fost descrise tehnologiile utiliz ate pentru
realizarea aplicației web.
Capitolul 2 – Analiza aplicației din punct d e vedere arhitectural
În acest capitol sunt d escrise cerințele sistemului, respectiv arhitectura acestuia.
Capitolul 3 – Impl ementarea și utiliz area sistemului inf ormatic
În acest capitol sunt d escriși p așii necesari pentru inst alarea cu succ es a componentelor
sistemului pr ecum și m anualul de utiliz are a aplicației.

Goreanu Olesea
9
Capitolul 4 – Concluzii
Acest capitol descrie concluziil e care au fost deduse în urm a realizării acestei aplicații. D e
asemenea, vor fi d escrise și dezvoltările ulterioare care pot fi aduse proiectului.

Goreanu Olesea 1 Analiza domeniului de studiu
10
1 Analiza domeniului d e studiu
Acest capitol prezintă obiectivele și funcți onalitățil e sistemului, cât și t ehnologiile utiliz ate pentru
realizarea aplicației web.

1.1 Imp ortanța temei
Tema lucrării d e licență este: ”Aplicație Java Spring p entru pl anificarea evenimentelor și
rezervarea de locații”. Pl anificarea evenimentelor este un domeniu c are a crescut în imp ortanță în
ultimii ani. Și nici nu e de mirare având în v edere multitudin ea de evenimente, corporative,
conferințe de presă, festivaluri, expoziții s au o aniversare semnific ativă a unui alt moment, care
necesită organizarea unui număr m are de persoane și sarcini, c omunic area cu m ass-media și alte
activități simil are. Planificarea unui eveniment nu este pentru c ei slabi, indif erent de tipul acestuia.
Este nevoie de profesioniști c are să reprezinte coloana vertebrală a unui eveniment realizat cu
succes. De aceea în ajutor vin organizatorii de evenimente, care fac viața mai ușoară a clienților,
în timp c e aceștia își economisesc timpul și b anii.
Scopul sist emului este de a oferi cli enților și organizatorilor de evenimente o cale de a
economisi timp. P entru pr oprietarii d e locații si organizatori este un instrum ent m anagerial
excepțional în a organiza mai bin e activitățil e și a avea un control mai bun p e evenimentele
organizate. Să aducă economii imp ortante și să c ontribui e la corelarea acțiunil or interne mult m ai
bine, de la procesul d e rezervare la satisfacția clienților. Pentru cli ent, are la dispoziție un
mecanism r apid și simplu d e a face rezervarea unui m eeting cu un organizator pentru evenimentul
său și în același timp are posibilit atea de a-și rezerva și o locație, având t oate informațiile necesare
în aplicația dată. Astfel clientul nu m ai este nevoit să pi ardă timp să c aute o locație, să s e deplaseze
la locul d at, având t otul la îndemână.

1.2 D efinirea obiectivelor
Un eveniment necesită timp și implic are la maxim, c eea ce oamenii nu -și pot permite,
deoarece trăim în epoca în care toți sunt em în c ontinuă mișc are și fiecare minut îns eamnă b ani. D e
aceea, obiectivul princip al al sist emului inf ormatic este de a oferi cli entului p osibilit atea de a
angaja un organizator de evenimente care îi va face viața mai ușoară și îl v a lipsi d e tot stresul
acumul at pe parcursul r ezervării a unei locații, etc. D e asemenea, de a oferi atât organizatorilor,
cât și pr oprietarilor de locații o modalitate mai bună d e a-și vind e serviciil e.

Goreanu Olesea 1 Analiza domeniului de studiu
11
Un obiectiv imp ortant propus este reprezentat de eficiența utilizării pr oiectului, r espectiv
interfața aplicației trebuie să fie simplă, uș or de navigat, cât m ai prietenoasă, astfel obiectivul să
fie atins. Int erfața având un r ol decisiv în aprobarea succesului aplicației.
Un alt obiectiv c are se dorește să fie realizat este reprezentat de securitate. Se dorește
evitarea accesului utiliz atorilor neautorizați la resursele aplicației. În fu ncție de rolul utiliz atorului
se restricți onează accesul la resursele aplicației, putând accesa pagini c are le pun l a dispoziție
funcți onalități s eparate. Acest obiectiv v a fi realizat prin autentific are și autorizare. Sist emul
propus tr ebuie să poată fi u tilizat de mai mult e tipuri d e utiliz atori, respectiv : Administr atorul,
Manager (angajatul), Gu est (utiliz atorul simplu).

Obiectivele generale ale sistemului inf ormatic sunt:
• Pentru a oferi clienților o abordare modernă d e rezervare unei locații pentru eveniment
• Pentru a face mai ușoară găsir ea unui organizator pentru pl anificarea unui eveniment
memorabil
• Oferă o experiență d e confort atât cli entului, cât și organizatorului d e evenimente
• Utiliz are ușoară și intuitivă a sistemului
• Colaborarea clientului/ organizatorului cu l ocațiile care prestează servicii
• Ajută cli entul l a crearea unei imagini d espre activitățil e si responsabilitățil e organizatorului
în timpul evenimentului
• Multipl e posibilități p entru cli enți de a face cunoștință cu organizatorul: prin i ntermediul
telefonului, pl atforme de socializare, face- to-face

1.3 D efinirea funcți onalitățil or sist emului
Funcți onalitățil e sistemului sunt:
• Înregistrarea unui utiliz ator(angajat) de către administr ator
• Autentific area unui utiliz ator(angajat)
• Adăug area/ștergerea/editarea locațiilor
• Vizu alizarea locațiilor detaliat
• Rezervarea locației pentru un eveniment prin int ermediul organizatorului d e evenimente
• Crearea unui f ormul ar pentru c ererea a mai mult or detalii

Goreanu Olesea 1 Analiza domeniului de studiu
12
• Rezervarea unui m eeting cu organizatorul: prin i ntermediul t elefonului, pl atforme de
socializare, face-to-face

1.4 R evizuir ea sistemelor simil are pe piață
Piața a fost cercetată în găsir ea unui sist em care va concura cu d ouă dintr e cele mai
puternice caracteristici ale acestuia:
• Vizu alizarea directă din aplicație a locațiilor (împr eună cu s erviciil e acestora) pentru
desfășur area evenimentelor.
• Rezervarea unui m eeting cu organizatorul prin dif erite metode, în d ependență d e ce-și
dorește clientul: prin int ermediul t elefonului, pl atformelor de socializare, face- to- face.
• Rezervarea unei locații dorite prin int ermediul organizatorului d e evenimente
Pentru c ercetarea de piață a fost utiliz at Google, care este un m otor de căutare pe internet.

Fortuna Evenimente
Fortuna Evenimente- este o aplicație web prin int ermediul căr eia clientul p oate apela la ei printr –
un formular, cerând inf ormațiile de care are nevoie. Fortuna Evenimente oferă servicii d e
organizare a evenimentelor și o gamă d e servicii c onexe oferite pentru evenimente. Este o aplicație
bună, dar această aplicație nu oferă toată gama de servicii, d ecât evenimente Corporate. În
comparație cu aplicația DreamEvents aceasta prezintă cât eva deosebiri:
• Nu p ermite rezervarea online a unui m eeting cu un organizator de evenimente
• Nu oferă serviciul d e rezervare a unei locații pentru evenimente
• Oferă organizarea doar la câteva tipuri d e evenimente
• Clientul nu p oate vizualiza portofoliu pentru evenimente direct în aplicație

Goreanu Olesea 1 Analiza domeniului de studiu
13
Figur a 1. 1 – Interfața aplicației FortunaEvenimente

Avangarde Events
Avangarde Events – este o aplicație web prin int ermediul cărui a clientul p oate afla detalii
despre companie, a afla cu ce fel de tipuri d e evenimente lucrează aceștia. Această aplicație
prezintă cât eva deosebiri în c omparație cu sist emul realizat:
• Cererea detaliilor doar prin t elefon sau prin scri erea unui e-mail la adresa menționată pe
pagina de contact
• Clientul nu p oate face o rezervare online a unui m eeting s au prin c ompletarea online a unui
formul ar
• Nu oferă serviciul d e rezervare a unei locații pentru evenimente
Figur a 1. 2 – Interfața aplicației AVANGARDE EVENTS

Goreanu Olesea 1 Analiza d omeniului de studiu
14
Sistemele prezentate mai sus, oferă inf ormații despre organizarea de evenimente, însă nu au
un m ecanism r apid d e a afla informațiile și de a face o rezervare pentru un m eeting. Nu este ușor
și intuitiv pr ocesul d e la momentul accesării aplicației până l a realizarea acțiunil or dorite de către
utiliz ator. Piața română nu este dezvoltată pr ea mult în d omeniul d at, în c omparație cu pi ața din
Marea Britanie sau piața americană. Analizând ofertele de aici, am constatat că m ajoritatea
organizatorilor de evenimente prestează servicii individu al, făcându -le public e pe site-uri p entru
anunțuri, c eea ce e în defavoarea clientului, căci nu are acces la prea multe informații.

1.5 T ehnologii utiliz ate
În acest subc apitol se vor descrie toate tehnologiile ce au fost utiliz ate pentru r ealizarea
sistemului.

1.5.1 J ava
Java este un limb aj de programare orientat obiect, ce s-a transformat într -un timp f oarte
scurt în un a dintr e cele mai folosite opțiuni p entru d ezvoltarea aplicațiilor. Cât eva caracteristicil e
princip ale ale limbajului sunt:
• Simplit atea: exclud e ”facilitățil e” care pot provoca scrierea unui c od neclar.
• Robustețea: datorită r enunțării l a pointeri și administr area automată a memoriei elimină
sursele de erori ce apar în pr ogramare
• Complet orientat-obiect: stilul d e programare procedural este exclus c omplet
• Portabilitatea: se poate executa pe orice sisteme de operare cum ar fi M ac Os, Wind ows,
Linux , etc.
• Securitatea: este un limb aj de programare cu o securitate ridicată datorită v erificării c odului
sursă p entru d etectarea secvențelor periculoase
În limb ajul Java conceptul d e pointer nu este, însă s e bazează pe referințe pentru a păstr a
adresele de memorie ale obiectelor. Un alt concept care nu există în J ava este de destruct or, fiind
introdus G arbage Collector-ul. D eși, m oștenirea multiplă este elimin ată, pr ogramatorul p oate
simul a acest lucru prin m oștenirea înlănțuită. Spr e deosebire de multe limbaje, Java este atât
interpretat cât și c ompilat, caracteristică c e îi redă portabilitatea. Limb ajul Java prezintă d oi pași
în pr ocesul d e compilare. Mai întâi d e toate, codul sursă este transformat în byt ecode, după c are
mașina virtu ală Java (JVM) int erpretează acest cod int ermediar. Sun Micr osystems a dezvoltat
patru ediții J ava, țintind spr e diferite medii de dezvoltare :

Goreanu Olesea 1 Analiza domeniului de studiu
15
• Java Card, pentru c arduri int eligente
• Java Micr o Edition, pentru m edii cu r esurse limitate
• Java Standard Edition, pentru st ațiile de lucru c omune
• Java Enterprise Edition, pentru aplicațiile enterprise

1.5.2 Fr amework-uri
Framework-urile sunt c orpuri m ari de coduri pr edefinite pe care le putem adăug a cu
ușurință pr opriului n ostru c od pentru a rezolva o anumită pr oblemă. Sunt r apide, eficiente și
ușoare. Putem utiliz a un fr amework apelând l a metodele sale, clasele moștenite sau alte
implementări ale modelelor de proiectare. Unele framework-uri ajută d ezvoltatorii prin r educerea
lucrului asupra configur ațiilor și a scrierii codului. Dar cât d e exact reduc acestea munc a și ne fac
eficient codurile? Pentru a înțelege acest lucru v om enumera câteva avantaje:
• Eficiență: S arcini c are în general îți i au ore și sut e de linii d e cod pentru a fi compus e, pot
fi acum efectuate în cât eva minut e cu funcții pr e-construit e. Dezvoltarea devine mult m ai
ușoară, așa că, d acă este mult m ai ușor, este mult m ai rapid și, ult erior, mai eficient.
• Securitate: Un fr amework utiliz at pe scară largă v a avea în general aplicații m ari de
securitate. Marele beneficiu este cartierul din sp atele acestui fr amework, în c are utiliz atorii
ajung, d e obicei, să fi e testeri de lungă dur ată.
• Costul r edus: C ele mai populare structuri sunt gr atuite și astfel ajută d ezvoltatorul să
codeze mai rapid. D acă codificarea se face mai repede, cheltuiala pentru cli entul fin al va
fi cu sigur anță m ai mică în fi ecare aspect, fie că este timpul s au efortul. În plus, c ostul d e
întreținere este de asemenea scăzut.
• Suport: Ca orice alt instrum ent distribuit, un fr amework includ e, în g eneral, documente, un
grup d e asistență s au forumuri online de mare comunit ate, und e puteți obține răspunsuri
rapide.
În ciud a tutur or acestor avantaje, framework-urile au unele dezavantaje, cum ar fi:
• Restricții: C omportamentul fund amental al framework-ului u p oate fi schimb at, ceea ce
indică f aptul că atunci când îl utiliz ați, vi s e cere să respectați limităril e acestuia și să lucr ați
la modul în c are este necesar. Astfel, trebuie să vă asigur ați că alegeți un fr amework care
să se potrivească n evoilor dvs.
• Codul este public: Întrucât fr amework-ul este disponibil p entru t oată lum ea, acesta este, de
asemenea, oferit p ersoanelor cu int enții pr oaste. Poate fi studi at pentru a ști cum

Goreanu Olesea 1 Analiza domeniului de studiu
16
funcți onează lucruril e și pentru a descoperi defecte care pot fi utiliz ate împotriva clienților
și a dezvoltatorilor.

1.5.2.1 Spring Fr amework
Spring Fr amework este o platforma Java open-source care oferă un sup ort vast pentru
crearea unei infr astructuri d e dezvoltare a aplicațiilor Java. Spring structur ează pr ogramul și
legăturil e între entități, ușurând lucrul pr ogramatorului. Spring p ermite crearea funcți onalității
programului utilizând P OJOs (“Pl ain Old Java Object”) adică structur a standartă a limbajului și
adăug area serviciil or enterprise fără a crea un conflict într e acestea[1].
Sprin g este un Fr amework constituit din aproximativ 20 d e module acestea fiind diviz ate
în grupuri p e baza scopului acestora: Core Container, Dată Access/Int egration, W eb, AOP (Aspect
Oriented Programming), Instrum entation, și T est .

Figur a 1. 3 – Structur a Spring Fr amework

Spring este bazat pe principiul inv ersion of control (IoC)[2] care are scop inv ersia fluxului
tradițional de executare a programului astfel fluxul pr ogramului fiind s etat de framework. Într -un
program obișnuit p rogramatorul singur h otărășt e în ce ordine vor fi apelate metodele, pe când în
unul c ontrolat de framework pr ogramatorul d efinește și impl ementează m etodele rulând d oar

Goreanu Olesea 1 Analiza domeniului de studiu
17
funcți a princip ală a framework-ului acesta singur apelând m etodele definite de către dezvoltator
atunci când este nevoie de ele.
Inversion of control este folosit p entru a spori modularitatea programului( s epararea
funcți onalității pr ogramului în m odule independente) și p entru a-l face extensibil.
Avantajele Spring -Framework[3]:
• Template predefinite pentru utiliz area diferitor tehnologii ca JDBC, Hib ernate, JPA etc.
• Ușor de testat.
• Lightw eight d atorită impl ementării P OJO.
• Ușor de dezvoltat aplicații JavaEE datorită D ependency Inj ection.

1.5.2.2 Spring B oot
Spring B oot reprezintă o extensie a Spring fr amework c are permite elimin area
configur arilor de nivel inferior, acestea fiind făcut e automat prin alegerea unor opțiuni d e către
programator la initiarea aplicației. În Spring c ore framework este nevoie de configur at totul d e
sinestatator cum ar fi d escript orii XML, p e când Spring B oot rezolvă această pr oblemă[4].

Figur a 1. 4 – Structur a Spring B oot

Spring B oot ne permite accelerarea creării un ei aplicații web, acesta analizând c onfigurăril e
setate de către programator și inj ectează toate dependențele necesare pentru s atisfacerea cerințelor
acestuia. Spring B oot oferă posibilități simpl e de introducere a modulelor prin p om.xml fil e, prin

Goreanu Olesea 1 Analiza domeniului de stu diu
18
Spring Inti alizr și d e pe site-ul oficial, permițând ușur area lucrului pr ogramatorului, acesta având
nevoie să se asigur e doar de funcți onalitatea programului.
Avantajele de bază a Spring B oot framework sunt auto-configur area, ind ependența și
autonomia acestuia de a lua decizii p entru a face o aplicație cât m ai optimiz ată.
Spring B oot este independent și oferă posibilit atea de a integra toate serviciil e automat. De
exemplu el nu are nevoie de un server container aparte în care să fie plasată aplicația, acesta oferind
unul implicit, rulândul l a startul aplicației. Spring B oot este amplasat în vârful Spring Fr amework-
ului acesta fiind c apabil să ofere toate funcți onalitățil e acestuia ușor integrându -le în pr oiect
scutind pr ogramatorul d e setarea infrastructurii oferind m ai mult timp p entru d ezvoltarea
funcți onalului d e bază.

Figura 1. 5- Avantaje Spring B oot

1.5.2.3 Spring MVC Fr amework
Framework-ul Spring MVC[5] este utiliz at pentru a crea aplicații w eb flexibile, datorită
componentelor și arhitecturii M odel-View-Controller. Acesta, impl ementează de asemenea, toate
caracteristicil e de bază ale unui Spring Fr amework, cum ar: inv ersiun ea controlului, inj ecția
dependenței, etc. Spring MVC oferă o soluție demnă d e a utiliz a MVC în Spring Fr amework cu
ajutorul Disp atcherServlet. În acest caz, Disp atcherServlet este o clasă care prim ește cererea
primită și o mapează cu r esursa potrivită, cum ar fi C ontroloarele, Modelele și Vizu alizăril e.
Spring W eb Model View Controller cuprind e patru componente princip ale așa cum s e arată
în figur a de mai jos:

Figur a 1. 6 – Arhitectura Spring MVC

Goreanu Olesea 1 Analiza domeniului de studiu
19

• Model – Modelul conține datele de bază ale aplicației. Datele pot fi, fi e un singur obiect,
fie un grup d e obiecte.
• Controler – Conține logica de afaceri a unei aplicații. Put eți utiliz a adnotarea @Controller
pentru a marca clasa ca Controller.
• View – Practic, Vi ew este utiliz at pentru a reprezenta informațiile într-un anumit f ormat.
• Front Controller – În Spring W eb MVC, cl asa Disp atcherServlet funcți onează ca controlor
frontal.

1.5.2.4 Spring S ecurity
Spring S ecurity[6] este un fr amework care permite unui pr ogramator să impună r estricții
de securitate aplicațiilor Web bazate pe Spring prin c adrul c omponentelor JEE. Pe scurt, este o
bibliotecă care poate fi utiliz ată, extinsă p entru a personaliza în funcți e de nevoile programatorului.
Deoarece este un m embru al aceleiași familii Spring, m erge ușor mână în mână cu Spring W eb
MVC. D omeniul princip al de operare este de a gestiona autentific area și autorizarea la nivelul
solicitării W eb, pr ecum și l a nivelul inv ocării m etodei. Poate că, c el mai mare avantaj al acestui
framework este că este puternic, d ar foarte personalizabil în impl ementarea sa. Deși urm ează
convenția Spring în c eea ce privește configur ația, programatorii pot alege între prevederile
implic ite sau personalizarea acesteia în funcți e de nevoile lor.
Spring S ecurity operează pe două domenii m ajore: autentific are și autorizare.
Autentific area înseamnă că, în timp c e accesați anumit e resurse restricți onate, utiliz atorul
este de fapt persoana potrivită p entru a face acest lucru. Există d ouă pr ocese pentru a vă asigur a
că utiliz atorul este autentic: id entific area și verificarea. De exemplu, un utiliz ator este autentific at
prin num ele de utiliz ator și p arola, care sunt d e obicei stocate într-o bază d e date; LD AP
(Lightw eight Dir ectory Access Pr otocol, un pr otocol ușor pentru accesarea serviciil or directoare);
sau CAS (Serviciu d e autentific are centrală, un singur pr otocol de conectare pentru W eb). Spring
Security a solicitat, de asemenea, o interfață pentru a codifica parola pentru a o face mai sigură.
Autorizarea determină întind erea dreptului utiliz atorului d e a accesa resurse restricți onate.
Se asigură că un utiliz ator este permis să acceseze numai acele părți ale resursei pentru c are acesta
a fost autorizat să le utiliz eze. De exemplu, un utiliz ator ADMIN are acces nelimitat la proprietățile
aplicației și le poate schimb a sau manipul a – în bin e sau în rău. Un UTILIZ ATOR normal sau un
utiliz ator GU EST, p e de altă parte, are acces mai controlat și nu beneficiază de aceleași drepturi

Goreanu Olesea 1 Analiza domeniului de studiu
20
ca și utiliz atorul ADMIN. Aceasta se numește autorizarea rolului utiliz atorului. În orice aplicație
Web, acest lucru s e realizează prin s ecuritate bazată pe URL. Spring oferă filtr e pentru a asigur a
rolul de securiz are a unei aplicații. D ar, securitatea bazată pe URL nu este un m ecanism f oarte
inteligent și d e multe ori poate fi utiliz ată gr eșit. Utiliz atorii dăunăt ori pot manipul a adresa URL
și pot avea acces la o metodă care este destinată de fapt unui utiliz ator administr ativ. D eoarece,
într-un sist em bazat pe URL, inv ocările de acces la metode restricți onate sunt trimis e prin hyp er-
linkuri, este destul d e ușor să r e-creezi aceeași metodă de invocare de pe URL și să o trimiți
serverului. S erverul p oate executa în m od național operațiile restricți onate fără a verifica rolul
utiliz atorului c are a invocat solicitarea. Prin urm are, pentru a rezolva această pr oblemă, Spring
oferă securitate la nivel de metodă. Acest lucru îns eamnă că d oar anumiți utiliz atori autorizați pot
invoca metode restrâns e și pur și simplu r e-crearea URL -ului și trimit erea către server nu l e va
executa.

1.5.2.5 ORM-UL Hib ernate
Hibernate ORM[7] este un object-relational mapping fr amework pentru limb ajul Java.
Acesta oferă un fr amework pentru m aparea unui model de domeniu orientat pe obiect la o bază de
date relațională. Hib ernate rezolvă pr obleme de impedanță n epotrivir e la obiect-relaționale prin
înlocuirea bazei de date directă, b aza de date persistentă accesează obiectele de nivel înalt cu
funсții d e manipul are. Hib ernate este un software gratuit c are este distribuit sub lic ența GNU
(Lesser General Publiс). Prim a versiun e a fost realizată în anul 2001. V ersiun ea cea mai actuală la
moment este Hibernate ORM 5.0.2.
Caracteristic a princip ală a Hibernate-ului este maparea din cl ase Java la tabele de baze de
date și maparea de la Java data types la SQL d ata types. Hib ernate oferă, de asemenea interogarea
de date și facilități d e recuperare.
Procesul automat de stocare a obiectelor într -o bază d e date relațională folosind un
framework ORM, c onstă în m aparea obiectelor la tabelele corespunzăt oare, asocierea dintr e ele
fiind d escrisă f olosind m etadata. Un fr amework ORM c omplet includ e următ oarele funcți onalități:
• un API pentru operațiile CRUD (cr eate, read, upd ate, delete) aferente claselor persistente;
• un limb aj pentru sp ecificarea interogărilor adresând cl asele persistente și atribut ele
acestora;
• un m od care să faciliteze definirea metadata pentru m apările dintr e obiect și t abelă;

Goreanu Olesea 1 Analiza domeniului de studiu
21
• o abordare consistentă a tranzacțiilor, a metodelor de stocare a datelor ("c aching") și a
asocierilor dintr e clase;
• tehnici d e optimiz are în funcți e de natura aplicației.
Componentele implic ate în mecanismul d e ORM sunt pr ezentate în figur a de mai jos.

Figur a 1. 7 – Mecanismul ORM

1.5.2.6 B ootstrap
Bootstrap este un fr amework front-end care este dezvoltat pentru a sprijini cr earea de site-
uri și aplicații web din amice. Este unul dintr e cele mai preferate framework-uri fr ont-end, d eoarece
are ca scop ușurarea dezvoltării w eb. Bootstrap este compatibil cu aproape toate browserele de
ultimă v ersiun e, cum ar fi Int ernet Explorer, Google Chrome, Opera, Firefox și S afari. Sup orta
designul w eb receptiv și ajustează din amic aspectul p aginilor web, luând în c onsiderare
caracteristicil e dispozitivului utiliz at. Acest framework este format din ș abloane de design b azate
pe HTML și CSS p entru div erse componente de interfață.
Avantajele Bootstrap-ului sunt:
• Viteza de dezvoltare
• Sensibilit ate
• Ușor și p ersonalizabil
• Structuri și stiluri r esponsive
• O bună d ocumentare și sup ort comunit ar
• O mulțim e de șabloane gratuite și profesionale, teme și plugin -uri W ordPress

Goreanu Olesea 1 Analiza domeniului de studiu
22
1.5.2.7 Thym eleaf
Thym eleaf[8] este un m otor de șabloane ce oferă mult e caracteristici c are sunt util e în
special în m ediile web. Acesta poate fi utiliz at pentru pr ocesarea documentelor HTML s au XML
non-web (date XML, d e exemplu) s au alte tipuri d e șabloane care nu sunt d estinate a fi trimis e
prin HTTP (d e exemplu, c onținut t ext / e-mail HTML).
De asemenea, Thym eleaf oferă o integrare plăcută cu Spring MVC prin di alectul său
SpringSt andard (inclus în p achetele thym eleaf-spring3, thym eleaf-spring4 și thym eleaf-spring5),
dar integrarea Spring este complet opțională și di alectul st andard este de fapt destinat să fi e utiliz at
fără Spring.
Thym eleaf fiind uș or de utiliz at, este cunoscut c a fiind c ea mai bună alternativă a paginilor de
vizualizare JSP(J ava Server Pages) și este inclus implicit în p achetul de start al Spring B oot spring –
boot-starter-web, ceea ce sublini ază încur ajarea dezvoltatorilor pentru a utiliz a Thym eleaf.

1.5.2.8 jQu ery
jQuery este unu fr amework popular de JavaScript. Acesta simplifică sint axa pentru a ușura
navigarea într-un d ocument și îmbunătăți pr ocesele asupra arborelui D OM (D OM este o
reprezentare a structurii arborelui a tutur or elementelor unei pagini W eb). Abordarea modulară a
framework-ului jQu ery permite crearea unor put ernice pagini w eb din amice și aplicații W eb.
Principiil e dezvoltării cu jQu ery sunt:
• Separarea JavaScript și HTML
• Securitate și claritate: jQu ery pr omovează securitit atea și claritatea cu caracteristici pr ecum
funcții „înlănțuit e” și num e de funcții sh orthand.
• Elimin area incompatibilitățil or într e browser: M otoarele JavaScript ale diferitelor
browsere diferă uș or, astfel încât c odul J avaScript c are funcți onează pentru un br owser să
nu funcți oneze pentru altul. C a și alte seturi d e instrum ente JavaScript, jQu ery se ocupă d e
toate aceste inconsistențe de tip br owser și oferă o interfață consistentă c are funcți onează
în dif erite browsere.
• Extensibilit ate: evenimente, elemente și metode noi pot fi adăug ate cu ușurință și apoi
reutiliz ate ca plugin.

Goreanu Olesea 1 Analiza domeniului de studiu
23
1.5.3 Apache Tomcat
Apache Tomcat, cun oscut și sub d enumir ea de Tomcat Server este un C ontainer Java
Servlet sau un c ontainer web, care oferă funcți onalitatea extinsă p entru a interacționa cu Servlets
Java, impl ementând în același timp m ai mult e specificații tehnice ale platformei Java: JavaServer
Pages (JSP), J ava Expression Language (Java EL) și W ebSocket. Este o alegere populară pentru
dezvoltatorii web care construi esc și m ențin sit e-uri w eb și aplicații din amice bazate pe platforma
software Java. Apache Tomcat a fost lansat cu 3 c omponente:
• Catalina- implementează sp ecificațiile Sun Micr osystems p entru s ervlet și J avaServer
Pages (JSP).
• Coyote- este o componentă “C onnector” ce suportă pr otocolul HTTP c a și server web.
Acesta permite servletului să acționeze ca un server web ce oferă pagini http.
• Jasper- este motorul JSP al lui T omcat

1.5.4 Apache Maven
Maven[9] este un instrum ent de gestionare și înț elegere a proiectelor care oferă dezvoltatorilor
un cadru c omplet al ciclului d e viață. Un pr ogramator poate automatiza aproape într-un timp scurt
infrastructur a de construir e a proiectului, d eoarece Maven folosește un layout de directoare
standard și un ciclu d e viață de construir e implicit.
Maven simplifică și st andardizează pr ocesul d e construir e a proiectului. G estionează perfect
compilarea, distribuți a, documentația, colaborarea în echipă și alte sarcini. M aven cr ește
reutiliz abilitatea și are grijă d e majoritatea sarcinil or legate de construir e.
Structur a și conținutul pr oiectului M aven sunt d eclarate într-un fiși er XML, p om.xml, d enumit
Model Object Object (P OM), c are este unitatea fundamentală a întregului sist em M aven.
Caracteristicil e princip ale ale Maven-ului sunt:
• Configur are simplă a proiectului
• Utiliz are consecventă în t oate proiectele
• Mod simplu d e a construi pr oiecte în care sunt ascuns e detalii inutil e
• Managementul d ependenței, inclusiv actualizarea automată
• Posibilit atea de a gestiona mai mult e proiecte simult an
• Descărc area dinamică a bibliotecilor și plug -in-urilor Java necesare din d epozitele Maven

Goreanu Olesea 1 Analiza domeniului de studiu
24
1.5.6 MySQL
O bază de date proiectată corespunzăt or furniz ează acces la informații pr ecise, actualizate.
Deoarece o proiectare corectă este esențială pentru atingerea scopurilor utilizării un ei baze de date,
investiția în timpul n ecesar învățării principiil or unei bun e proiectări este esențială. Pr oiectarea
unei baze de date reprezintă un pr oces ce implică d ezvoltarea și rafinarea structurii un ei baze de
date pe baza cerințelor formulate de către beneficiarul bazei de date și a cerințelor deduse pe baza
efectuării analizei domeniului c e urmează a fi modelat.[10]
Princip alul obiectiv urmărit l a proiectarea unei baze de date este asigur area consistenței,
integrității și pr eciziei datelor. Dacă pr oiectul un ei baze de date este incorect este foarte greu de
extras informațiile necesare, fiind p osibilă obținerea de informații false.
Obiectivele generale de proiectare sunt:
• baza de date trebuie să înm agazineze datele necesare obținerii de informații descrise în faza
de analiză a cerințelor precum și orice interogare ce poate fi pusă l a un m oment dat de către
utiliz ator;
• tabelele trebuie să fi e construit e corect și eficient; fi ecare tabel din b aza de date
reprezentând o singură entitate și fiind c ompus din câmpuri distinct e, păstrând o
redund anță minimă a datelor, fiecare înregistrare dintr -un tabel putând fi id entific ată cu
ajutorul un ei valori unic e;
• integritatea datelor se impun e la nivel de tabel, câmp, r elație; aceste nivele de integritate
ajută l a garantarea faptului că structuril e de date împreună cu v alorile acestora sunt v alide
și precise în orice moment;
• baza de date trebuie să sup orte regulile specifice domeniului p e care îl modelează; d atele
trebuie să ofere informație validă și pr ecisă, având t ot timpul înț eles;
• la proiectarea bazelor de date trebuie să se prevadă dezvoltările viitoare; structur a bazei de
• date trebuie să fie ușor de modificat sau extins odată cu m odificarea cerințelor impus e.
Este greu de realizat toate aceste obiective permanent, dar un pr oiect corect al unei baze de
date trebuie să aibă în v edere obținerea cât m ai rapidă a rezultatelor. Aplicarea tehnicil or de
proiectare conduc e la obținerea următ oarelor beneficii:
• structur a bazei de date este ușor de modificat și g estionat deoarece modificăril e efectuate
asupra unui câmp s au tabel nu afectează alte câmpuri s au tabele ale bazei de date;
• datele sunt uș or de modificat deoarece modificarea valorii unui câmp d intr-un tabel nu
afectează valorile altor câmpuri din același sau alte tabele ale bazei de date; mai mult d ecât

Goreanu Olesea 1 Analiza domeniului de studiu
25
atât, o proiectare corectă a unei baze de date va duce la păstr area unei redund anțe minim e
a datelor;
• informațiile sunt uș or de extras deoarece se pot crea cu ușurință int erogări d acă tabelele
sunt c orect alcătuit e iar relațiile sunt st abilite în mod corespunzăt or;
• aplicațiile create de utiliz ator sunt uș or de proiectat și g estionat.

Planificarea bazei de date reprezintă c ontrolul activitățil or ce permit r ealizarea efectivă și
eficientă a etapelor de proiectare a unei baze de date. În acest sc op se realizează următ oarea
documentație:
• identific area scopului b azei de date;
• obiectivele bazei de date (identific area fiecărei activități individu ale ce trebuie suportată
de baza de date).

Proiectarea bazei de date cuprind e următ oarele trei etape:
• proiectarea conceptuală a bazei de date;
• proiectarea logică a bazei de date;
• proiectarea fizică a bazei de date.
Proiectarea conceptuală reprezintă pr ocesul d e construir e a unui m odel al informațiilor utiliz at
în cadrul unui d omeniu d e interes, ind ependent de toate considerațiile fizice. Proiectarea logică
reprezintă pr ocesul de constituir e a unui m odel al informațiilor utiliz at la modelarea unui d omeniu
de interes bazat pe un anumit m odel specific d e date (de exemplu, m odelul relațional), dar
independent de orice alte considerații fizic e. Proiectarea fizică r eprezintă pr ocesul d e descriere a
implementării b azei de date pe mediile secund are de stocare. Sunt d escrise structuril e de stocare
și metodele de acces utiliz ate pentru a obține un acces eficient la date.
Strategiile de proiectare a bazelor de date:
• de sus în j os: se pornește cu cel mai înalt niv el de abstractizare după c are urmează rafinarea
(de exemplu, s e stabilesc entitățil e, după c are se formează subcl asele, iar apoi se adaugă
atribut ele);
• de jos în sus: s e pornește cu abstractizăril e de bază, după c are urmează combin area acestora
(de exemplu, atribut ele se grupează formând entități). În acest fel se pot forma concepte
elementare, colecții d e concepte elementare, scheme;

Goreanu Olesea 1 Analiza domeniului de studiu
26
• din int erior spre exterior: este o formă sp ecială de proiectare de jos în sus c are se axează
pe un set central de concepte (se selectează cele mai imp ortante concepte, schema inițială,
se creează sch emele intermediare din c are se deduce apoi schema finală);
• mixtă: s e pornește mai întâi cu pr oiectarea de sus în j os, urm ată de proiectarea dinspr e
interior spre exterior sau de jos în sus.
Pentru pr oiectarea bazei de date s-a folosit pl atforma ”MySQL W orkbench”, c are este o
programă d e administr are a BD MySQL. Este un instrum ent de acces server open-source cu
platformă d eschisă c a fiind c el deal doilea produs c el mai descărc at de pe site-ul MySQL. Acesta
este un instrum ent vizu al complex pentru arhitecții d e baze de date și oferă m odelarea datelor,
dezvoltarea SQL și instrum entele de administr are complete pentru c onfigur area serverului,
administr area utiliz atorilor, formarea copiilor de rezervă și mult e altele. MySQL W orkbench este
disponibil p e Windows, Linux și M ac OS X.
MySQL W orkbench oferă instrum ente vizuale pentru cr earea, executarea și optimiz area
interogărilor SQL. Editorul SQL furniz ează evidențierea sintaxelor color, auto-completarea,
reutiliz area fragmentelor SQL și ist oricul execuției SQL. P anoul de conexiuni b aze de date permite
dezvoltatorilor să g estioneze cu ușurință c onexiunil e standard de baze de date, inclusiv MySQL
Fabric. Object Br owser ( navigatorul de obiecte ) oferă acces inst antaneu la schema bazei de date
și la obiecte.

1.5.7 J ava Database Connectivity (JDBC)
JDBC (J ava Database Connectivity)[11] este o interfață standard SQL d e acces la baze de date.
JDBC este constituită dintr -un set de clase si int erfețe scrise în Java, furnizând m ecanism e standard
pentru pr oiectanții aplicațiilor de baze de date. Folosind JDBC este ușor să s e transmită s ecvențe
SQL cătr e baze de date relaționale. Cu alte cuvint e, nu este necesar să scri em un pr ogram pentru
a accesa o bază de date Oracle, alt program pentru a accesa o baza de date Sybase și așa mai
departe. Este de ajuns să scri em un singur pr ogram folosind API-ul JDBC și acesta va fi capabil
să trimită s ecvențe SQL b azei de date dorite. Bin eînțeles, scriind c odul sursă în J ava, ne este
asigur ată portabilitatea programului. D eci, iată doua motive puternice care fac combin ația Java –
JDBC d emnă d e luat în s eamă.

Goreanu Olesea 1 Analiza domeniului de studiu
27
Folosind JDBC, un pr ogram poate:
• Stabili c onexiuni cu dif erite sisteme de baze de date;
• Executa comenzi (SQL) p entru a crea, actualiza, manipul a datele și a recepționa
rezultate;
• Inspecta și manipul a meta-datele bazei de date.
JDBC este doar un API care permite programului să int eracționeze cu un sist em de gestiun e a
bazelor de date. Serverul de baze de date trebuie sa existe separat: Java DB (f ost Apache Derby)
sau MySQL.
Interfețele și clasele pentru JDBC s e găsesc în p achetul java.sql. O aplicație JDBC utiliz ează
unul s au mai mult e drivere din p achetul java.sql c are sunt utiliz ate de către clasa DriverManager.
Driverele sunt sp ecifice bazelor de date, deci pentru fi ecare tip d e bază de date se utiliz ează un
driver special. În aceeași aplicație putem lucr a cu baze de date diferite, deci implicit si cu m ai
multe drivere. Put em avea nevoie de un driv er care comunic a cu o bază de date Oracle aflata la
distanță și d e un altul c are reprezintă l egătur a spre driverul ODBC l ocal și c omunică cu un s erver
SQL. În aplicații comunic ația cu o bază de date necesită următ orii pași:
• Se apelează la DriverManager cerand un driv er specific p entru b aza de date;
• Driverul sp ecific cr eează legătura cu baza de date și returnează un obiect de tip C onnection;
• Cu ajutorul obiectului d e tip C onnection se creează un obiect St atement care conține și o
cerere SQL cătr e baza de date;
• Obiectul St atement returnează rezultatele într-un obiect ResultS et.

Figur a 1. 8 – Modul d e funcți onare a JDBC

Goreanu Olesea 2 Analiza aplicației din punct de vedere arhitectural
28

2 Analiza aplicației din punct d e vedere arhitectural
Proiectarea software-ului este un pr oces de transformare a cerințelor utiliz atorului într -o
formă adecvată, c are ajută pr ogramatorul în c odificarea și impl ementarea software-ului.
Proiectarea software-ului este primul p as în SDLC (S oftware Design Lif e Cycl e), care mută
concentrarea din d omeniul pr oblemei în d omeniul s oluției.
Acesta este capitolul în c are sistemul este analizat folosind di agrama cazurilor de utiliz are,
pentru a obține o imagine mai clară a sistemului. Sunt d escrise cerințele sistemului și infr astructur a
acestuia.

2.1 C erințele sistemului
Vorbind d espre ciclul d e viață al unui pr ogram, unul dintr e nivelurile de bază care trebuie
luate în considerare este specificarea cerințelor cătr e sistem. Acoperirea acestui punct ajută
dezvoltatorul să d etermine funcți onalitatea pe care sistemul o va avea pentru impl ementarea
viitoare. De obicei, cerințele super se schimbă în p erioada de dezvoltare, este însă esențial să l e
stabilim p e cele de bază încă d e la început. D e fapt, apar versiuni n oi ale sistemului, d eoarece
testarea inițială ridică anumit e semne de întrebare, astfel următ oarea versiun e a produsului vin e cu
unele cerințe revizuit e. Unul dintr e cele mai imp ortante lucruri p e care ar trebui să l e poată face
aplicația este să răspundă l a datele solicitate de utiliz ator.

→ Atribut ele sistemului s oftware
Atribut ele sistemului s oftware sunt utiliz ate pentru a evalua performanța unui sist em
informatic impl ementat. Mai jos sunt enumerate cerințele pentru pr oiectul r ealizat:
• Utiliz abilitate
Interfața aplicației trebuie să fie cât m ai simplă, astfel încât un utiliz ator nou să p oată folosi
aplicația fără să c onsult e un m anual de utiliz are. Designul int erfeței grafice, intuitivit atea acesteia,
dar și pl asarea elementelor în locații sp ecifice, familiar utiliz atorului, r eprezintă elemente esențiale
pentru o utiliz are preferată de utiliz ator. O aplicație cu o interfață pri etenoasă, uș or de învăț at, de
navigat și c are face ca obiectivul să fi e atins r apid, este dorită d e utiliz ator în d efavoarea unei
aplicații cu mult e funcți onalități, d ar care nu beneficiază de o interfață corespunzăt oare. Interfața
are un rol decisiv e în aprobarea succesului aplicației.

Goreanu Olesea 2 Analiza aplicației din punct de vedere arhitectural
29
• Extensibilit ate
Această pr oprietate a sistemului măs oară cât d e ușor se pot adăug a noi funcți onalități
aplicației. Impl ementarea sistemului a fost realizată astfel încât d ezvoltările viitoare să poată fi
făcut e cu ușurință și să nu d egradeze modul d e funcți onare existent. Adăug area de noi
funcți onalități s e realizează uș or în c adrul pr oiectelor bine structur ate.
• Accesibilit ate
Accesibilit atea este reprezentată de modul simplu în c are se poate accesa aplicația. Datorită
faptului c a sistemul r ealizat este o aplicație web, se poate accesa foarte ușor prin int ermediul unui
browser web, astfel utiliz atorului îi este necesară o conexiune la internet si un br owser web pentru
a putea utiliz a aplicația.
• Disponibilit ate
Această cerință este reprezentată de momentele în care sistemul p oate fi utiliz at. Aplicația
poate fi disp onibilă p ermanent, astfel încât utiliz atorii să p oată folosi aplicația în orice moment
doresc. P entru a putea accesa aplicația este necesar să existe conexiune la internet.
• Securitate
Cea mai imp ortantă c erință este securitatea, presupun e protecția împotriva atacurilor.
Utiliz atorii înr egistrați vor avea parole criptate în baza de date, fiecare utiliz ator înregistrat în
sistem are posibilit atea de a se autentific a și a utiliz a aplicația cu dr epturi limit ate în funcți e de
rolul său.
• Performanța
Performanța ca și indic ator de calitate reprezintă o măsură c are definește volumul d e procesări
pe care o aplicație trebuie să le poată realiza pe o unitate de timp s au termenul c are trebuie respectat
pentru fin alizarea corectă a unei aplicații. Sist emul r ealizat prezintă un timp d e răspuns scurt p entru
procesarea datelor, o rată de utiliz are ridicată și o utiliz are scăzută a resurselor sist emului.
Performanța este necesară pentru a putea asigur a utilizarea și funcți onarea în condiții optime a
sistemului. S -a pus accent pe implementarea unui sist em care comunică în timp r eal cu cli entul.

→ Cerințele de performanță
Pentru o experiență m ai bună a utiliz atorului, impl ementarea aplicației trebuie să fi e
realizată cu atenție, prin aplicarea următ oarelor cerințe:

Goreanu Olesea 2 Analiza aplicației din punct de vedere arhitectural
30
• Scalarea ușoară a aplicației
• Scalarea ușoară a bazei de date
• Interogări minim e asupra bazei de date
• Folosirea redusă a resurselor RAM și CPU

2.2 Di agramele cazuril or de utiliz are
Diagramele cazurilor de utiliz are sunt d e obicei denumit e diagrame de comportament
utiliz ate pentru a descrie un set de acțiuni (c azuri d e utiliz are) pe care un anumit sist em sau sist eme
(subi ect) ar trebui s au le pot efectua în colaborare cu unul s au mai mulți utiliz atori externi ai
sistemului ( actori). Fi ecare caz de utiliz are ar trebui să ofere rezultate observabile și valoroase
actorilor sau altor părți int eresate ale sistemului. În figur a de mai jos este prezentată diagrama
cazurilor de utiliz are pentru cli ent cu privi re la posibilitățil e pe care le are accesând sist emul.
Aceasta descrie mai mult e acțiuni pr ecum ”Vizu alizarea locațiilor”, ”C ererea informațiilor
adiționale” , ”Vizu alizarea detaliată a unei locații” , și ”R ezervarea unui m eeting cu un
organizator”.

Figura 2. 1 – Diagrama cazurilor de utiliz are pentru Gu est

Goreanu Olesea 2 Analiza aplicației din punct de vedere arhitectural
31

Sistemul oferă și un p anou de administr are pentru utiliz atorii cu r ol de administr atori.
Această administr are este descrisă în figur a de mai jos. În această figură este prezentat
comportamentul administr atorului f ață de sistem. În primul rând, acesta se poate autentific a în
sistem cu cr edențialele sale de autentific are. Odată logat, acesta are posibilit atea să execute câteva
acțiuni, pr ecum: ” Adăug area/ editarea/ ștergerea angajaților”, ” Adăug area/ editarea/ ștergerea
locațiilor”, ”Vizu alizarea locațiilor”, ”Vizu alizarea angajaților”, ”Vizu alizarea rezervăril or
meeting-urilor”, ”Vizu alizarea rezervăril or locațiilor”, ”Vizu alizarea/ Procesarea cererilor făcut e
pentru inf ormații adiționale” .

Figur a 2. 2 – Diagrama cazurilor de utiliz are pentru Administr ator

De asemenea, sistemul pun e la dispoziție un panou de administr are și pentru angajați, care
au rolul d e manager în sist em. Aceștia au mai puține drepturi d ecât un administr ator, însă m ai
multe decât un simplu utiliz ator. Acesta autentificându -se în sist em, are posibilit atea să facă
următ oarele acțiuni: ” Adăug area/ editarea/ ștergerea locațiilor”, ”Vizu alizarea locațiilor”,

Goreanu Olesea 2 An aliza aplicației din punct de vedere arhitectural
32
,”Vizu alizarea rezervăril or meeting-urilor”, ”Vizu alizarea rezervăril or locațiilor”, ”Vizu alizarea/
Procesarea cererilor făcut e pentru inf ormații adiționale”.

Figur a 2. 3 – Diagrama cazurilor de utiliz are pentru M anager

2.3 Infr astructur a sistemului inf ormatic
Infrastructur a sistemului v a fi proiectat conform m odelului d e proiectare a sistemelor
bazate pe arhitectura Spring MVC (M odel View Controller). În figur a de mai jos este prezentat
fluxul un ei cereri HTTP în aplicația Java folosind fr amework-ul Spring MVC:

Goreanu Olesea 2 Analiza aplicației din punct de vedere arhitectural
33

Figur a 2. 4 – Fluxul un ei cereri HTTP în Spring MVC

Procesarea unei solicitări HTTP d e Spring MVC s e face în felul următ or:
Când c ererea părăs ește browserul, p oartă inf ormații despre ceea ce solicită util izatorul. C el
puțin, c ererea va purta adresa URL s olicitată. D ar poate transporta și date suplim entare, cum ar fi
informațiile transmis e într-un formular de către utiliz ator.
Prim a oprire în călăt oriile solicitării este la Disp atcherServlet Spring. L a fel ca majoritatea
framework-urilor web bazate pe Java, direcționăm c analele Spring MVC printr -un servlet de
control frontal. Un c ontroler frontal este un m odel de aplicație web comun în c are un singur s ervlet
delegă responsabilitatea pentru o solicitare către alte componente ale unei aplicații pentru a efectua
procesarea efectivă. În c azul Spring MVC, Disp atcherServlet este controlerul fr ontal. Sarcina
Disp atcherServlet este de a trimit e cererea către un controler Spring MVC. Un c ontroler este o
componentă Sp ring c are procesează solicitarea. Dar o aplicație obișnuită p oate avea mai mult e
controlere, iar Disp atcherServlet are nevoie de ceva ajutor pentru a decide la ce controlor să trimită

Goreanu Olesea 2 Analiza aplicației din punct de vedere arhitec tural
34
cererea. Prin urm are, Disp atcherServlet consultă un a sau mai mult e mapări de gestionare pentru a
afla unde va fi următ oarea oprire a cererii. M aparea operatorului acordă o atenție deosebită adresei
URL p e care o solicită atunci când i a decizia sa. După c e a fost ales un c ontroler adecvat,
Disp atcherServlet trimit e cererea către controlorul ales. La controler, cererea renunță l a sarcina sa
utilă (inf ormațiile transmis e de utiliz ator) și așteaptă cu răbd are în timp c e controlorul pr elucrează
aceste informații. (D e fapt, un c ontrolor bin e proiectat efectuează în sin e puțin s au deloc
prelucrarea și delegă în schimb r esponsabilitatea pentru l ogica de afaceri unui a sau mai mult or
obiecte de serviciu.) L ogica efectuată de un controlor are adesea drept rezultat unele informații
care trebuie să fie reduse utiliz atorului și afișate în br owser. Această inf ormație este denumită
model. Dar trimit erea informațiilor brut e către utiliz ator nu este sufici entă – trebuie formatată într –
un format ușor de utiliz at, de obicei HTML. P entru aceasta, informațiile trebuie să fie date unei
vizualizări, d e obicei o pagină J avaServer (JSP) s au ca în cazul pr oiectului d at, pagina Thym eleaf.
Unul dintr e ultim ele lucruri p e care le face un controlor este să împ acheteze datele modelului și să
identific e numele unei vizu alizări c are ar trebui să r edea ieșirea. Apoi trimit e cererea, împr eună cu
numele modelului și vizu alizarea, înapoi la Disp atcherServlet. Pentru c a controlorul să nu fi e
cuplat la o anumită vizu alizare (view), num ele vizualizării tr ansmis e la Disp atcherServlet nu
identifică dir ect un JSP sp ecific. Nu sug erează nici măc ar neapărat că vi ew este un JSP. În schimb,
poartă doar un num e logic c are va fi folosit pentru a căuta vizualizarea efectivă c are va produce
rezultatul. Disp atcherServlet consultă un r ezolvator view pentru a mapa numele vizualizării logice
cu o implementare specifică a vizualizării, c are poate fi sau nu un JSP. După c e Disp atcherServlet
știe care vizualizare va face rezultatul, jobul c ererii este aproape terminat. Oprirea sa finală este la
implementarea etapei view, de obicei un JSP, unde furniz ează datele modelului. L ocul d e muncă
al cererii este finalizat. View va folosi datele modelului p entru a face o ieșire care va fi redusă
clientului d e către obiectul d e răspuns.

Fluxul p e scurt a unei cereri HTTP în aplicația Java creată folosind fr amework-ul Spring MVC:
• Clientul trimit e o solicitare HTTP cătr e o anumită adresă URL
• Disp atcherServlet Spring MVC prim ește solicitarea
• Transmit c ererea către un anumit c ontroler, în funcți e de adresa URL s olicitată folosind
adnotările @Controller și @RequestMapping.
• Spring MVC C ontroller returnează apoi un num e și un m odel de vedere logic l a
Disp atcherServlet.

Goreanu Olesea
35
• Disp atcherServlet consultă r ezolvatorii d e vizualizări până când este determinată
vizualizarea efectivă a randamentului
• Disp atcherServlet contactează vizu alizarea aleasă (cum ar fi Thym eleaf, JSP) cu d atele
modelului și r ealizează ieșirea în funcți e de datele modelului
• Ieșirea redată este returnată cli entului c a răspuns

Goreanu Olesea 3 Implementarea sistemului
36
3 Impl ementarea sistemului
În acest capitol, proiectul este analizat din punct d e vedere al impl ementării. Aici vor fi
descrise toate clasele și componentele implic ate, modul în c are comunică într e ele, ce limbaj de
programare și framework-uri au fost utiliz ate în acest proiect.

3.1 Inst alarea JDK 8
Java Development Kit (JDK) este unul dintr e cele trei pachete tehnologice de bază utiliz ate
în pr ogramarea Java, împr eună cu JVM (J ava Virtu al Machin e) și JR E (Java Runtim e Environment).
Aceste componente diferă într e ele și sunt c onectate în felul următ or:
• JVM este componenta platformei Java care execută pr ograme;
• JRE este partea Java de pe disc c are creează JVM;
• JDK p ermit e dezvoltatorilor să cr eeze programe Java care pot fi executate și rul ate de JVM
și JR E;
Dezvoltatorii n oi în J ava confundă adesea Java Development Kit și J ava Runtim e
Environment. Distincți a este că JDK este un p achet de instrum ente pentru d ezvoltarea de
software bazat pe Java, în timp c e JRE este un p achet de instrum ente pentru rul area codului J ava.
JRE poate fi utiliz at ca o componentă autonomă pentru a rula pur și simplu pr ograme Java,
dar este, de asemenea, o parte a JDK. JDK n ecesită un JR E, deoarece rularea programelor Java
face parte din d ezvoltarea acestora.
Pachetul JDK 8 s e va descărc a de pe site-ul oficial al Oracle, pentru v ersiun ea de Wind ows
x64. În ainte de instalare a JDK s e va verifica dacă m așina dezvoltatorului înd eplinește
următ oarele cerințe minim e de procesor, sp ațiu pe disc și m emorie.
Când s e va executa instalatorul JDK, utiliz atorul v a avea la dispoziție selecția a trei componente:
Development Tools, Source Code si Public JR E, dintr e care poate instala unul s au pe toate trei.
Pentru c azul pr oiectului d at se va selecta valoarea implicită.
Instalarea opțiunii “D evelopment Tools” va oferi JDK -ul corespunz ator. Inst alarea “Source
Code” conține sursele pentru cl asele public e din API-ul Java. Includ erea acestei opțiuni v a
permit e dezvoltatorului să f acă referire la codul sursă l a construir ea aplicațiilor. A treia opțiun e

Goreanu Olesea 3 Implementarea sistemului
37
“Public JR E” va face ca JDK și JR E să fi e entități s eparate: JRE-ul public p oate fi folosit d e alte
programe pentru a executa programe Java și poate fi inst alat separat de JDK.
Se vor inst ala toate cele trei componente cu s etările implicit e pentru fi ecare. După
realizarea acestui lucru, JDK și JR E vor fi inst alate în locațiile implicit e pentru fi ecare sistem de
operare. În c azul pr oiectului d at, pe Wind ows, c alea către acestea va fi:
C:\Program Fil es\Java

Figur a 3. 1 – Calea către JDK și JR E

Rămân e decât s etarea variabilei PATH în Wind ows. P entru aceasta se va merge în
Environment V ariables în Wind ows și s e va adăug a la PATH c alea către mapa bin din m apa cu
JDK. În c adrul sist emului d at va fi: C:\Program Fil es\Java\jdk1.8.0_241 \bin.

Goreanu Olesea 3 Implementarea sistemului
38

Figur a 3. 2 – Setarea variabilei PATH în Wind ows

Acești pași sunt imp ortanți pentru s etarea mediului d e scriere și rul area aplicațiilor în J ava.

3.2 Iniți alizarea proiectului Spring B oot
Spring Initi alizr este un instrum ent w eb furniz at de Serviciul W eb Piv otal. Cu ajutorul
Spring Initi alizr, put em genera cu ușurință structur a proiectului Spring B oot. De asemenea oferă
un API extensibil p entru cr earea de proiecte bazate pe JVM.
Acesta mai oferă dif erite opțiuni p entru pr oiect, c are sunt exprim ate într-un m odel de
metadate. Modelul de metadate ne permit e să configurăm list a dependențelor acceptate de JVM
și versiunil e de platformă, etc. Acesta servește metadatele sale într-un m od cun oscut c are oferă
asistența necesară cli enților terți.
Pentru a crea un pr oiect Spring B oot avem m ai mult e opțiuni, pr ecum ar fi:

Goreanu Olesea 3 Implementarea sistemului
39
• Folosind iniți alizatorul Spring.i o;
• Folosind un ID E precum Eclips e și un pr oiect simplu M aven;
• Folosind suit a Spring T ool Suit e;
• Folosind CLI (C ommand-lin Int erface);
La inițializarea proiectului p entru sist emul d at, s-a folosit iniți alizatorul Spring.i o ce se află la
adresa https://st art.spring.i o/[12].
Înainte de a crea un pr oiect, d ezvoltatorul tr ebuie să înț eleagă int erfața grafică a
platformei. Int erfața Spring Initi alizr are următoarele componente:
• Project – definește tipul pr oiectului. Put em cr ea fie un pr oiect M aven, fie Gradle. Pentru
proiectul d at s-a ales opțiun ea Maven.
• Language – Spring Initi alizr oferă opțiun ea dintr e trei limb aje: Java, Kotlin si Gr oovy.
Evident, p entru proiectul d at s-a rămas la opțiun ea implicită J ava;
• Spring B oot – dezvoltatorul v a selecta versiun ea de Spring B oot. Cea mai recentă v ersiun e
lansată la moment este 2.3.1;
• Project Metadata – conține informațiile legate de proiect, cum ar fi Gr oup, Artifact etc.
Group indică num ele pachetului. Artifact denum ește num ele aplicației. Num ele implicit
al Group este com.example, iar pentru Artifact este demo;
• Name – este identic cu Artifact;
• Descripti on – se poate adăug a o descriere a proiectului;
• Package Name – este simil ar cu num ele de Group;
• Packaging – dezvoltatorul are opțiun ea de a alege tipul d e ambalare a proiectului. P entru
proiectul d at s-a rămas la opțiun ea implicită J ar;
• Java – se va folosi pentru a alege versiun ea de JVM c are se va utiliz a pentru d ezvoltarea
proiectului. P entru sist emul d at va fi Java 8;
• Dependencies – dependențele sunt c olecția de artefacte pe care le putem adăug a la
proiectul n ostru.
În im aginea de mai jos se vor afișa configur ațiile de bază cu c are a fost iniți alizat proiectul.
Însă aceste configur ații pot fi m odific ate chiar și după iniți alizarea proiectului și încărc area
acestuia în ID E.

Goreanu Olesea 3 Implementarea sistemului
40

Figur a 3. 3 – Inițializarea proiectului cu Spring Initi alizr

După c e s-au intr odus c onfigur ațiile dorite, se va genera și descărc a proiectul d e pe
platformă. D ezvoltatorului îi rămân e să dezarhiveze fișierul primit c a să extragă m apa cu pr oiect
și să -l imp orteze în ID E ca un pr oiect existent M aven.

3.3 M ediu d e dezvoltare integrat (Eclips e)
Un m ediu d e dezvoltare integrat [13] este o aplicație software care oferă facilități c omplete
programatorilor de comput er pentru d ezvoltarea de software.
Mediile de dezvoltare integrate sunt c oncepute pentru a maximiz a productivit atea
programatorului prin furniz area de componente strâns e cu int erfețe de utiliz ator simil are. IDE-
urile prezintă un singur pr ogram în c are se realizează toată dezvoltarea. Acest program oferă în
mod obișnuit mult e caracteristici p entru autorizarea, modificarea, compilarea, impl ementarea și
depanarea software-ului. Unul dintr e obiectivele IDE este de a reduce configur ația necesară pentru
a împărți m ai mult e utilități d e dezvoltare, în loc să ofere același set de funcții c a și o unitate de
coeziune. Reducerea timpului d e configur are poate crește productivit atea dezvoltatorilor, în
cazurile în care învăț area utilizării ID E este mai rapidă d ecât int egrarea manuală a tutur or
instrum entelor individu ale. Integrarea mai strânsă a tutur or sarcinil or de dezvoltare are potențialul
de a îmbunătăți pr oductivit atea generală, dinc olo de a ajuta doar cu s arcini d e configur are. De

Goreanu Olesea 3 Implementarea sistemului
41
exemplu, c odul p oate fi analizat continuu în timp c e este editat, oferind f eedback inst antaneu când
sunt intr oduse erori de sintaxă. Aceasta poate învăț a rapid un limb aj de programare nou și
bibliotecile sale asociate.

Eclips e IDE
Pentru pr oiect a fost utiliz at Eclipse IDE. Este un instrum ent care permite deschid erea,
editarea, construir ea, rularea și depanarea celor mai mult e tipuri d e aplicații.
Eclipse IDE, dezvoltat și într eținut d e Fund ația Eclipse, a fost lansat pentru prim a dată în
2000. D e atunci a fost folosit pentru c onstruir ea a sute de mii d e aplicații software. Fund ația a
lansat mai mult e ediții. Enterprise Edition (EE) fiind un a dintr e aceste ediții din Eclips e oferă o
gamă l argă d e caracteristici p erformante. Acesta este motivul p entru c are aceasta este foarte
populară în rândul d ezvoltatorilor.
Caracteristici ch eie ale Eclips e IDE pentru J ava EE:
• Permite dezvoltatorilor să utiliz eze Servlet, Java Server Pages (JSP) și instrum ente similare
pentru d ezvoltarea de soluții d e tip enterprise.
• Este cea mai potrivită cu v ersiun ea Java Enterprise Edition, care este special concepută
pentru a construi aplicații web și enterprise.
• Dacă utiliz ați acest ID E pentru a dezvolta o aplicație enterprise în Java, această v ersiun e
oferă o gamă largă d e pluginuri c are vor extind e funcți onalitatea aplicației.
• Platforma este compatibilă cu o serie de instrum ente de dezvoltare software, inclusiv
Spring.
• Eclipse IDE acceptă o gamă v astă d e formate de fișiere.

3.4 Cl asele si componentele sistemului
După cum s -a mai menționat mai sus, în arhitectura Spring MVC, d ezvoltatorii sunt
responsabili în m are parte pentru d ezvoltarea a patru componente majore ale sistemului:
• Model;
• View;
• Controller;
O practică bună d e dezvoltare este aranjarea claselor pe pachete în dependență d e rolul și
funționalitatea acestora. În c ontinu are se vor da exemple de clase și pachete care alcătui esc

Goreanu Olesea 3 Implementarea sistemului
42
componentele menționate anterior împr eună cu structur a generală a proiectului și organizarea pe
pachete a claselor.

Figur a 3. 4 – Structur a proiectului

Goreanu Olesea 3 Implementarea sistemului
43

Proiectul c onține opt pachete de clase. Structur a generală a acestui pr oiect este dată de Maven, ce
are specific d e exemplu păstr area codului sursă cu t estele unitare într-un arbore aparte de codul
sursă cu cl ase sau faptul că conține fișierul pom.xml .
Pachetul com.spring. eventspl anner conține clasa princip ală cu m etoda main cu ajutorul căr eia
dezvoltatorul rul ează aplicația ca pe o simplă aplicație Java.
Codul sur să al clasei cu m etoda main():
@SpringB ootApplic ation
public class EventsPl annerApplic ation {

public static void main(String[] args) {

SpringApplication.run(EventsPlannerApplication.class, args);

}
}

Pachetul com.spring. eventspl anner.config conține clase pentru c onfigur area aplicației cum ar fi
clasa de configur are pentru DemoSecurityC onfig ce are cu funcți onalitate interceptarea și
autorizarea cererilor HTTP.
Pachetul com.spring. eventspl anner.controller conține clasele Controller și reprezintă c omponenta
Controller din arhitectura MVC.
Exemplu d e clasă Controller:
@Controller
@RequestMapping("/locations")
public class LocationController {

@Autowired
priv ate LocationService locationService;

@GetMapping("/list")
public String listL ocations(Model theModel) {

List<Location> locations = locationService.findAll();

theModel.addAttribute("locations", locations);

return "/locations/locations-list";
}

@GetMapping("/add")
public String addLocation(Model theModel) {

String img = (String) th eModel.asMap().get("locationName");

Location theLocation = new Location();

Goreanu Olesea 3 Implementarea sistemului
44
if(img!= null) {
theLocation.setImg(img);
}
theModel.addAttribute("location", theLocation);

return "/locations/location-form";
}

@GetMapping("/update")
public String updateLocation(@RequestParam("locationId") int theId,
Model theModel) {

Location theLocation = locationService.findById (theId);
theModel.addAttribute("location", theLocation);

return "/locations/location-form";
}

@PostMapping("/save")
public String saveLocation(@ModelAttribut e("location") Location
theLocation) {

locationService.save(theLocation);

return "redirect:/locations/list" ;
}

@GetMapping("/delete")
public String deleteLocation(@RequestParam("locationId") int theId) {

locationService.deleteById(theId);

return "redirect:/locations/list" ;
}

}

Pachetul com.spring. eventspl anner.service reprezintă str atul Service dintr e Controller și D AO din
infrastructur a sistemului si are ca funcți onalitate procesarea și manipul area datelor ce le prim ește
din D AO. Practica cea mai bună s e consideră a fi ca fiecare clasă Service să impl ementeze o
interfață.
Exemplu d e interfață Service:
public interface LocationServic e {

public List<Location> find All();

public Location findById (int theId);

public void save(Location theLocation);

public void deleteById(int theId);
}

Goreanu Olesea 3 Implement area sistemului
45

Exemplu d e clasă Service:
@Servic e
public class LocationServic eImpl impl ements LocationService {

@Autowired
priv ate LocationRepository locationRepository;

@Overrid e
public List<Location> find All() {
return locationRepository.findAll();
}

@Overrid e
public Location findById (int theId) {
Optional<Location> result =
locationRepository.findById (theId);

Location theLocation = null;
if (result.isPresent()) {
theLocation = result.get();
} else {
throw new Runtim eException("Did not find L ocation id –
" + theId);
}
return theLocation;
}

@Overrid e
public void save(Location theLocation) {
locationRepository.save(theLocation);
}

@Overrid e
public void deleteById(int theId) {
locationRepository.deleteById(theId);
}

}

Pachetul com.spring. eventspl anner.dao conține clasele și int erfețele ce au ca rol extragerea și
salvarea datelor în b aza de date. Acest pachet reprezintă str atul D AO reprezentat în infr astructur a
sistemului inf ormatic. C a și în c azul cl aselor Service, e o practică bună c a clasele DAO să
implementeze o interfață.

Goreanu Olesea 3 Implementarea sistemului
46

Exemplu int erfață DAO:
public interface UserDao {

public User findByUs erName(String us erName);

public void save(User user);

public List<User> find All();

public void deleteById(Long theId);

public User findById (Long id);

}

Exemplu cl asă DAO:
@Repository
public class UserDaoImpl impl ements UserDao {

@Autowired
priv ate EntityManager entityManager;

@Overrid e
public User findByUs erName(String th eUserName) {
Session currentSession = entityManager.unwrap(Session.class);

Query<User> theQuery = curr entSession.createQuery("from User
where userName=:uName", User.class);
theQuery.setParameter("uName", theUserName);
User theUser = null;
try {
theUser = theQuery.getSingleResult();
} catch (Exception e) {
theUser = null;
}

return theUser;
}

@Overrid e
public void save(User theUser) {
Session currentSession = entityManager.unwrap(Session.class);

currentSession.saveOrUpdate(theUser);
}

@Overrid e
public List<User> find All() {

Session currentSession = entityManager.unwrap(Session.class);

Goreanu Olesea 3 Implementarea sistemului
47
Query<User> theQuery = curr entSession.createQuery("from User",
User.class);

List<User> users = theQuery.getResultList ();

return users;
}

@Transactional
@Suppr essWarnings("unchecked")
@Overrid e
public void deleteById(Long theId) {

entityManager.joinTransaction();
Session currentSession = entityManager.unwrap(Session.class);

Query<User> theQuery = curr entSession.createQuery("delete from
User where id =: uId" );
theQuery.setParameter("uId", theId);
theQuery.executeUpdate();

}

@Overrid e
public User find ById(Long id) {

Session currentSession = entityManager.unwrap(Session.class);
Query<User> theQuery = curr entSession.createQuery("from User
where id=:uId" , User.class);
theQuery.setParameter("uId", id);
User theUser = theQuery.getSingleResult();

return theUser;
}

}

Pachetul com.spring. eventspl anner.model reprezintă c omponenta Model și conține clasele ce
reprezintă m odelele sistemului.
Exemplu d e model:
@Entity
@Table(name="request_info")
public class InfoRequest {

@Id
@GeneratedValue(strategy=GenerationType.IDENTITY)
@Column(name="id")
priv ate int id;

@Column(name="email")
priv ate String email;

@Column(name="phone_nr")

Goreanu Olesea 3 Implementarea sistemului
48
priv ate int phoneNr;

@Column(name="event_date", columnDefinition = "DATE")
@DateTimeFormat(pattern = "dd-MM-yyyy")
priv ate LocalDate eventDate;

@Column(name="nr_guests")
priv ate int nrGuests;

@Column(name="message")
priv ate String m essage;

@ManyToOne(fetch = FetchType.LAZY, cascade= {CascadeType.PERSIST,
CascadeType.MERGE,
CascadeType.DETACH, CascadeType.REFRESH})
@JoinColumn(name="location_id")
priv ate Location location;

public InfoRequest() {}

public InfoRequest(String n ame, String email, int phoneNr, LocalDate
eventDate, int nrGuests, String m essage) {
super();
this.email = email;
this.phoneNr = phoneNr;
this.eventDate = eventDate;
this.nrGuests = nrGuests;
this.message = message;
}

public InfoRequest(String n ame, String email, int phoneNr, LocalDate
eventDate, int nrGuests, String m essage,
Customer customer, Location location) {
super();
this.email = email;
this.phoneNr = phoneNr;
this.eventDate = eventDate;
this.nrGuests = nrGuests;
this.message = message;
this.location = location;
}

public int getId() {
return id;
}

public void setId(int id) {
this.id = id;
}

public String getEmail() {
return email;
}

public void setEmail(String email) {
this.email = email;
}

Goreanu Olesea 3 Implementarea sistemului
49
public int getPhoneNr() {
return phoneNr;
}

public void setPhoneNr(int phoneNr) {
this.phoneNr = phoneNr;
}

public LocalDate getEventDate() {
return eventDate;
}

public void setEventDate(LocalDate eventDate) {
this.eventDate = eventDate;
}

public int getNrGu ests() {
return nrGuests;
}

public void setNrGu ests(int nrGuests) {
this.nrGuests = nrGuests;
}

public String getMessage() {
return message;
}

public void setMessage(String m essage) {
this.message = message;
}

public Location getLocation() {
return location;
}

public void setLocation(Location location) {
this.location = location;
}

@Overrid e
public String toString() {
return "InfoRequest [id=" + id + ", email=" + email + ",
phoneNr=" + phoneNr + ", eventDate="
+ eventDate + ", nrGuests=" + nrGuests + ",
message=" + message + ", location=" + location + "]";
}

}

Pachetul com.spring. eventspl anner.storage conține clasele și int erfețele responsabile pentru
încarcarea și salvarea fișierelor în sist em.
Pachetul com.spring. eventspl anner.validation conține clasele și anotațiile personalizate pentru
validarea campuril or modelelor.

Goreanu Olesea 3 Imple mentarea sistemului
50
Componenta View este reprezentată d e mapa templates ce se află p e calea
src/m ain/resources și conține paginile Thym eleaf.
3.5 R ealizarea bazei de date
Baza de date conține o colecție de date necesare pentru funcți onarea și utiliz area aplicației
web. În baza de date sunt st ocate informații care sunt n ecesare aplicației pentru a-și înd eplini
obiectivul princip al. Aplicația utiliz ează o bază de date care conține nouă tabele.
Aceste tabele conțin inf ormații despre utiliz atori, locații, r ezervări, c ontacte, etc. În
imaginea de mai jos sunt r eprezentate tabelele și asocierile binare dintr e ele.
Constrâng erile folosite pentru t abelele din b aza de date sunt următ oarele:
• NOT NULL – o coloană nu p oate avea valoarea NULL
• UNIQU E – toate valorile dintr -o coloană su nt dif erite
• PRIM ARY K EY – este o cheie prim ară care are rolul de a identific a unic o entitate și nu
pot conține valori NULL.
• FOREIGN K EY – este o cheie străină, c are reprezintă o relație cu o altă tabelă.

Goreanu Olesea 3 Implementarea sistemului
51
Figur a 3. 5 – Diagrama bazei de date

Tipuril e de relații ce pot exista între tabele sunt:
• Asocierea ”unul- la- unul” (one- to- one)
Într-o relație unu-la-unu, fi ecare înregistrare din primul t abel poate avea o singură
înregistrare potrivită în al doilea tabel și fi ecare înregistrare din al doilea tabel poate avea o singură
înregistrare potrivită în primul t abel. Această relație nu este comună, d eoarece, de cele mai mult e
ori, inf ormațiile asociate în acest mod se stochează în același tabel. O relație unu-la-unu p oate fi
utilizată pentru a diviz a un tabel cu mult e câmpuri, p entru a izola o parte dintr -un tabel din m otive
de securitate sau pentru a stoca informații care se aplică num ai pentru un subs et al tabelului

Goreanu Olesea 3 Implementarea sistemului
52
princip al. Când s e identifică o astfel de relație, ambele tabele trebuie să partajeze un câmp c omun;
se notează cu 1:1.
• Asocierea ”unul- la- multe” (one- to- many)
Este asocierea prin c are unui element din primul t abel îi c orespund unul s au mai mult e
elemente din al doilea tabel și inv ers, unui element din al doilea tabel îi c orespund e un singur
element din primul t abel; se notează cu 1:N.
• Asocierea ”multe- la- multe” (many-to-many)
Este asocierea prin c are unui element din primul t abel îi c orespund unul s au mai mult e
elemente din al doilea tabel, si r eciproc; se notează cu M:N.
Lista tabelelor care au fost dezvoltate pentru aplicația dată:
• user
• customer
• contact
• reservation
• location
• meeting
• request_inf o
• role
• users_roles

→ Tabela user – în această tabelă sunt înr egistrați utiliz atorii aplicației și se rețin inf ormații
utile despre aceștia. În m omentul în c are administr atorul cr eează un c ont nou, datele introduse
vor fi s alvate în baza de date. Fiecare utiliz ator are un id entific ator unic p e baza cărui a poate
fi găsit în b aza de date. Există r elații într e acest tabel și t abele users_roles, m eeting,
reservation.
Tabel 3. 1 – User
Câmpuri Descriere
1 id Identific ator unic
2 username Num ele utiliz atorului f olosit la autentific are în sist emul inf ormatic
3 password Parola utiliz atorului p e care o folosește la autentific area în sist em
4 first_n ame Prenumele utiliz atorului
5 last_name Num ele utiliz atorului

Goreanu Olesea 3 Implementarea sistemului
53
6 email Adresa de e-mail a utiliz atorului
7 address Adresa utiliz atorului/ organizatorului
8 phone_nr Numărul d e telefon a utiliz atorului
9 Image Num ele imaginii atribuit e unui utiliz ator

→ Tabela contact conține următ oarele informații:
Tabel 3. 2 – Contact
Câmpuri Descriere
1 id Identific ator unic
2 name Num ele clientului
3 email Adresa de email a clientului
4 phone_nr Numărul d e telefon
5 event_typ e Tipul d e eveniment
6 event_date Data evenimentului
7 message Mesajul cli entului

→ Tabele reservation conține următ oarele informații:
Tabel 3. 3 – Reservation
Câmpuri Descriere
1 id Identific ator unic
2 order_date Data rezervării
3 ceremony_typ e Tipul evenimentului
4 nr_gu ests Numărul d e oaspeți
5 music_includ ed Muzic a inclusă
6 kitch en_includ ed Bucătări e inclusă
7 cuisin e Tipul bucătări ei
8 details Detalii adiționale
9 payment_method Metoda de plată
10 payment_st atus Statutul plății

→ Tabela location conține următ oarele informații:
Tabel 3. 4 – Location
Câmpuri Descriere
1 id Identific ator unic
2 name Num e locație
3 address Adresa locației
4 max_gu ests Numărul m axim d e oaspeți
5 price_per_guest Prețul pentru un oaspete
6 own_kitch en Bucătări e proprie
7 own music Muzică pr oprie
8 ceremony_typ es Tipul c eremoniei
9 cuisin e Tipul bucătări ei

Goreanu Olesea 3 Implementarea sistemului
54
10 modify_m enu Meniu m odificat
11 special _menu Meniu special
12 payment_m ethod Metoda de plată
13 descripti on Descrierea locației

→ Tabela customer conține următ oarele informații:
Tabel 3. 5 – Customer
Câmpuri Descriere
1 id Identific ator unic
2 first_n ame Prenumele clientului
3 last_name Num ele clientului
4 phone_nr Numărul d e telefon
5 email Adresa de e-mail
6 address Adresa de domiciliu

→ Tabela meeting conține următ oarele informații:
Tabel 3. 6 – Meeting
Câmpuri Descriere
1 id Identific ator unic
2 location_name Num ele locației und e va avea loc întâlnir ea
3 date_time Data întâlnirii

→ Tabela role conține următ oarele informații:
Tabel 3. 7 – Role
Câmpuri Descriere
1 id Identific ator unic
2 name Num ele rolului utiliz atorului

→ Tabela users_roles conține următ oarele informații:
Tabel 3. 8 – Users Roles
Câmpuri Descriere
1 user_id Identific ator unic p entru us er ce face legătur a cu câmpul ”id” din
tabelul ”us er”
2 role_id Identific ator unic p entru r olul utiliz atorului în sist em ce face
legătur a cu câmpul ”id” din t abelul ”r ole”

→ Tabela request_inf o conține următ oarele informații:

Goreanu Olesea 3 Implementarea sistemului
55
Tabel 3. 9 – Request Inf o
Câmpuri Descriere
1 id Identific ator unic
2 name Num ele clientului
3 email Adresa de e-mail
4 phone_nr Numărul d e telefon
5 event_date Data evenimentului
6 nr_gu ests Numărul d e oaspeți

3.6 D escrierea aplicației
Analizând pr odusul din p erspectiva avantajelor, acest proiect reprezintă o modalitate
rapidă și uș oară pentru utiliz ator de a planifica un eveniment cu ajutorul unui organizator de
evenimente și de a rezerva o locație pentru d esfășur area acestuia. Aplicația la fel oferă atât
organizatorilor de evenimente, cât și pr oprietarilor de locații posibilit atea de a oferi servicii m ai
calitative și mai eficiente clienților săi.
Princip alele obiective ale acestui pr oiect sunt:
• Utiliz are ușoară și intuitivă a aplicației de către utiliz atori
• Posibilit atea de rezervare a unei întâlniri într e cele două părți (cli ent-organizator de
evenimente)
• Vizu alizarea locațiilor (restaurante, hoteluri) împr eună cu t oate serviciil e oferite de
acestea direct din aplicație
• Rezervarea locației dorite pentru eveniment prin int ermediul organizatorului, c eea ce
economisește timp atât cli entului cât și organizatorului
• Sistemul oferă posibilit atea organizatorilor și pr oprietarilor de locații sa-și presteze
serviciil e întru -un m od modern

Actorii sist emului
Aplicația suportă mult e tipuri d e utiliz atori. Fi ecare utiliz ator moștenește drepturil e
ierarhic ale utiliz atorului inf erior. Sist emul are trei tipuri d e utiliz atori:
• Administr ator
• Manager (angajații)
• Guest (utiliz atorul simplu)

Goreanu Olesea 3 Implementarea sistemului
56
Primul utiliz ator, cel care creează contul, este administr atorul. Acest tip d e utiliz ator are
control deplin atât asupra angajaților adăug ați în aplicație cât și asupra setărilor contului. Având
acces la toată aplicația, administr atorul poate face următ oarele acțiuni:
• Autentific are în sist em
• Adăug area angajaților
• Ștergerea angajaților existenți în li sta sistemului
• Editarea unui angajat existent în listă
• Adăug area locațiilor
• Ștergerea locațiilor existente
• Editarea unei locații existente
• Vizu alizarea rezervăril or realizate pentru l ocații
• Vizu alizarea rezervăril or realizate pentru m eeting-uri
• Vizu alizarea și procesarea cererilor de informații trimis e de către clienți
Angajatul, având r olul de manager, are mai puțin e drepturi d ecât un administr ator, dar
mai mult e decât un utiliz ator simplu. Acesta autentificându -se în sist em, are posibilit atea să facă
următoarele acțiuni:
• Adăug area locațiilor
• Editarea unei locații existente
• Rezervarea unei locații
• Vizu alizarea rezervăril or pentru l ocații
• Vizu alizarea cererilor de informații
• Vizu alizarea rezervăril or pentru întâlniri
Guest, fiind un utiliz ator simplu are posibilit atea să facă următ oarele acțiuni:
• Vizu alizarea paginii cu l ocațiile oferite
• Vizu alizarea fiecărei locație în parte împreună cu t oate serviciil e oferite de aceasta
• Rezervarea unei întâlniri cu un organizator de evenimente
• Completarea unei cereri pentru inf ormații adiționale

Utiliz area aplicației
La accesarea aplicației, utiliz atorul va ateriza pe pagina princip ală.

Goreanu Olesea 3 Implementarea sistemului
57

Figur a 3. 6 – Pagina princip ala a proiectului

De asemenea, aici se află și un ele elemente informative, cum ar fi p ortofoliu cu unii cli enți
ai companiei:

Figur a 3. 7 – Portofoliu Cli entului

Goreanu Olesea 3 Implementarea sistemului
58

Pe pagina princip ală se mai află și f orma de contact pentru cli enți:

Figur a 3. 8 – Forma de contact pentru c lienți

Pentru a vedea locațiile disponibile, utiliz atorul v a utiliz a linkul Locations din m eniul d e
navigare:

Figur a 3. 9 – Pagina pentru cli enți

Goreanu Olesea 3 Implementarea sistemului
59

Pe pagina dată, utiliz atorul are opțiun ea de a vizualiza fiecare locație în parte cu detaliile
specifice. Pentru asta utiliz atorul va folosi but onul Details.

Figur a 3. 10 – Pagina cu detalii pentru fi ecare locație în parte

Pentru autentific area în sist em, utiliz atorul va trebui să intr oducă d atele corecte în
următ oarea formă:

Figur a 3. 11 – Forma de autentific are

Goreanu Olesea 3 Implementarea sistemului
60

Figur a 3. 12 – Formă d e autentific are invalidă

Vizu alizarea listei de locații cu r ol de Administr ator (rolul și accesul):

Figur a 3. 13 – Vizu alizarea listei de locații cu r ol de Administr ator

Goreanu Olesea 3 Implementarea sistemului
61

Vizu alizarea listei de locații cu r ol de Manager (rolul și accesul):
Figur a 3. 14 – Vizu alizarea listei de locații cu r ol de Manager

Adăug area locațiilor noi:

Figur a 3. 15 – Forma de adăug are a locațiilor

Goreanu Olesea 4 Concluzie
62
4 Concluzi e
În cadrul acestui c apitol se vor prezenta realizăril e și obiectivele care au fost atinse prin
acest proiect, pr ecum și o descriere a eventualelor dezvoltări ult erioare.

4.1 R ealizarea obiectivelor propuse
Scopul acestei lucrări a fost de a analiza și proiecta o platformă p entru pl anificarea online
a evenimentelor și rezervarea locațiilor pentru d esfășur area acestora.
Pentru cr eare unui pr odus c alitativ care să răspundă c erințelor utiliz atorilor a fost luat în
calcul f eedbak-ul și experiența în acest domeniu al mai mult or persoane care au putut să d escrie
care sunt gr eutățil e de a organiza un eveniment în R omâni a. Analiza sistemelor existente în
capitolul unu, a permis observarea situației la moment. Lips a sistemelor în c are utiliz atorul poate
vizualiza locațiile pentru eveniment dir ect din aplicație și a face rezervarea prin int ermediul
organizatorului său, îngr eunează pr ocesul.
Sistemul impl ementat a reușit să -și atingă t oate obiectivele princip ale, astfel încât să ofere
tutur or utiliz atorilor, atât cli enților cât și organizatorilor o experiență plăcută d e utiliz are. Un
obiectiv imp ortant atins este reprezentat de eficiența utilizăr ii sist emului, d atorită int erfeței grafice
simpl e, ușor de înțeles și n avigat. Un alt obiectiv atins este reprezentat de securitatea sistemului.
Acesta a fost realizat prin autentific area și autorizarea utiliz atorului.
În fin al, se poate de concluzi onat faptul că sist emul r ealizat oferă utiliz atorilor posibilit atea
de a-și desfășur a mai ușor activitățil e legate de eveniment și l ocații, economisind timp și b ani, și
de a obține performanțe mai bun e datorită acestuia.

4.2 D ezvoltări ult erioare
În viit or, aplicația poate fi dezvoltată, pentru a permite diverse facilități n oi. În c ontinu area
se vor descrie îmbunătățiril e care pot fi aduse sistemului.
O primă îmbunătățir e care poate fi adusă sist emului este reprezentată de adăug area unui
chat online prin int ermediul cărui a clienții v or put ea comunic a direct cu organizatorul d e
evenimente. Astfel, ar fi mult m ai modernă int eracțiun ea dintr e aceste două părți și ar ușur a munc a
organizatorilor.

Goreanu Olesea
63
O altă p osibilit ate de dezvoltare ulterioară este reprezentată de adăug area mai mult or
servicii p entru cli enți, oferindu -le acestora posibilit atea de a-și alege amănunțit t oate detaliile,
cum ar fi: fl orile, decorațiunil e, etc. Astfel, clienții prin int ermediul aplicației vor avea posibilit atea
de a-și organiza mai amănunțit evenimentul.
O a treia îmbunătățir e a sistemului este reprezentată de un ch ecklist p entru organizatorii de
evenimente. Deoarece planificarea și organizarea unui eveniment necesită multă muncă, str ategie
și atenție, un ch ecklist ar fi bin evenit în organizarea, productivit atea și creativitatea mai efectivă a
lucruril or.

Goreanu Olesea Bibliografie
64
Bibli ografie

[1] Spring Fr amework – [Resursă electronică, accesată la data de: 12/05/2020],
https://www.j ournaldev.com/
[2] Sp ring Fr amework – [Resursă electronică, accesată la data de: 12/05/2020]
https:// en.wikip edia.org/wiki/Inv ersion_of_control
[3] Spring Fr amework – [Resursă electronică, accesată la data de: 12/05/2020]
https://www.j avatpoint.com/spring -tutorial
[4] Spring B oot – [Resursă electronică, accesată la data de: 16/05/2020]
https://d ocs.oracle.com/en/java/javase/14/
[5] Spring MVC – [Resursă electronică, accesată la data de: 28/05/2020]
https://www.tut orialspoint.com/spring/spring_w eb_mvc_f ramework.htm
[6] Spring S ecurity. – [Resursă electronică, accesată la data de: 28/05/2020]
https://spring.i o/projects/spring -security#l earn
[7] Hib ernate – [Resursă electronică, accesată la data de: 8/06/2020]
https://www.ud emy.c om/course/spring -hibernate-tutorial/
[8] Thyml eaf – [Resursă electronică, accesată la data de: 8/06/2020]
https://www.thym eleaf.org/
[9] M aven – [Resursă electronică, accesată la data de: 8/06/2020]
https://www.tut orialspoint.com/maven/maven_overview.htm
[10] MySQL . Informație generală – [Resursă electronică, accesată la data de: 12/06/2020]
https://www.mysql.c om/products/w orkbench/
[11] Arhitectura JDBC – [Resursă electronică, accesată la data de: 12/06/ 2020]
https://c orejava25hours.c om/2016/10/27/jdbc/
[12] Iniți alizarea proiectului Spring B oot- [Resursă electronică, accesată la data de: 12/06/2020]

Goreanu Olesea Bibliografie
65
https://st art.spring.i o/
[13] M ediu d e dezvoltare integrat. – [Resursă electronică, accesată la data de: 12/06/2020]
https:// en.wikipedia.org/w/ind ex.phptitl e=Integrated\%20d evelopment\%20environment&%20 ol
did=834326950