Specializarea: Informatică [617284]
UNIVERSITATEA „LUCIAN BLAGA” DIN SIBIU
FACULTATEA DE
Ș
TIIN
Ț
E
Specializarea: Informatică
LUCRARE DE LICEN
Ț
Ă
Coordonator
ș
tiin
ț
ific
Prof.univ.dr. Mircea Neam
ț
u
Absolvent: [anonimizat]
2018
UNIVERSITATEA „LUCIAN BLAGA” DIN SIBIU
FACULTATEA DE
Ș
TIIN
Ț
E
Specializarea: Informatică
Java Data Encryption
Applied on HR Management
System
Coordonator
ș
tiin
ț
ific
Prof.univ.dr. Mircea Neam
ț
u
Absolvent: [anonimizat]
2018
Hito
Application
Coordonator
ș
tiin
ț
ific
Prof.univ.dr. Mircea Neam
ț
u
Absolvent: [anonimizat]
2018
D
eclarație pentru conformitate asupra originalită
ț
ii operei
ș
tiin
ț
ifice
Cuprins
//TODO – content with inner links
Motto:”
Manage people not human resorces
”
Abstract
Scopul
nostru
în
lucrarea
de
fa
ț
ă
este
de
a
oferi
solu
ț
ii
la
probleme
actuale
de
pe
pia
ț
a
IT.
Implementarea
proiectului
urmăre
ș
te
optimizarea
procesului
de
administrare
al
angaja
ț
ilor,
gestiunea
individuala
a
fiecărui
angajat,
eficientizarea
procesului
de
recrutare,
cre
ș
terea eficien
ț
ei între angaja
ț
i, cât
ș
i simplificarea procesului de pontaj.
Este
important
să
accentuăm
faptul
că
solu
ț
ionarea
a
venit
în
urma
unor
probleme
întâmpinate
în
via
ț
a
reala
în
domeniul
IT.
Proiectul
urmăre
ș
te
un
concept
simplu
de
utilizat,
practic
ș
i
eficient.
El
este
structurat
pe
capitole,
încercând
sa
acopere
problemele
cât
ș
i
solu
ț
ia
lor împreuna cu dezvoltarea idei de bază, arhitectura, tehnologiile, utilizarea, etc.
Hito
este
o
solu
ț
ie
software
pentru
administrarea
oamenilor,
conceput
pentru
afaceri
de
nivel
mic
ș
i
mediu .
Proiectul
satisface
cerin
ț
ele
administrative,
cât
ș
i
pe
cele
ale
angaja
ț
ilor.
Hito
este
un
software
stabil,
proeminent
ș
i
u
ș
or
de
folosit
care
permite
echipelor
de HR
ș
i al angaja
ț
ilor să lucreze mai eficient în ceea ce prive
ș
te timpul
ș
i resursele.
Hito
urmăre
ș
te
integrarea
printr-o
interfa
ț
ă
grafică
a
funcționalităților
care
vin
în
ajutorul
echipelor
de
dezvoltare
software,
a
celor
de
la
HR,
cât
ș
i
a
altor
departamente
din
interiorul
unei
firme
de
IT;
dar
solu
ț
ii
la
procese,
ce
la
momentul
actual
se
fac
fizic
de
către
o
persoană.
Prin
defini
ț
ie
“Hito”
(
人
)
,
înseamnă
oameni,
provenit
din
limba
japoneză,
acest
supranumi pune într-un singur cuvânt o întreagă viziune.
Trecând
din
nou
în
revistă
factorii,
puteam
observa
cum
ca,
proiectul
Hito
se
adresează
exclusiv
firmelor
de
nivel
mic
ș
i
mediu,
din
zona
IT.
Ideea
acestui
proiect
pleacă
de la probleme reale, care au fost observate de-a lungul anilor de activitate în acest domeniu.
La
procesul
de
realizare
al
acestui
proiect,
s-a
ț
inut
cont
de
standardele
existente
în
domeniu.
În
ceea
ce
urmează
o
să
prezentăm
structura
proiectului.
O
să
prezentăm
pe
scurt
lista de capitole ale lucrării ordonate cronologic.
Cel
dintâi
capitol
cuprinde
introducerea
în
sfera
proiectului,
oferind
informa
ț
ii
generale,
alcătuite
pe
subcapitole.
În
primul
subcapitol
oferă
detalii
legate
de
zona
unde
se
încadrează proiectul, cât
ș
i introducerea lui în context.
În
primul
subcapitol
identificam
problemele
ș
i
solu
ț
ia
găsita
la
prima
problemă
identificată; procesul de administrare al angaja
ț
ilor.
Al
doilea
subcapitol
cuprinde
gestiunea
individuală
a
fiecărui
angajat.
De
ce
exista
această problemă, cum o putem rezolva
ș
i ce solu
ț
ie ave pentru acest factor.
Subcapitolul
trei
îmbră
ț
i
ș
ează
conceptul
de
eficientizare
al
procesului
de
recrutare.
Subcapitol în care se prezintă solu
ț
ia găsita la problema enun
ț
ată.
Ultima
parte
din
primul
capitol
poarta
numele
de
“We
work
for
the
future”,
ce
reprezintă
un
rezumat
al
cercetării
de
fa
ț
ă
asupra
aplica
ț
iei
existente,
ș
i
domeniul
în
care
se
încadrează aplica
ț
ia Hito.
În
treilea
subcapitol
găsim
procedeul
prin
care
se
îmbunătă
ț
e
ș
te
colaborarea
unei
echipe.
Al
patrulea
subcapitol
con
ț
ine
elaborarea
procesului
de
time
tracking,
enun
ț
area
problemei, solu
ț
ia lui, cât
ș
i întrebarea de ce am dori a
ș
a ceva în interiorul unei firme de IT.
În
capitolul
doi,
avem
prezentarea
arhitecturii
aplica
ț
iei,
structurată
de
asemenea
pe
subcapitole.
Hito
este
compus
din
server
ș
i
aplica
ț
ia
web.
Complexitatea
arhitecturii
serverului, necesita cuno
ș
tin
ț
e despre modul în care se crează o a stfel de la nivel “enterprize”.
Al
treilea
capitol
este
edificat
din
tehnologiile
studiate
ș
i
folosite
pentru
a
putea
efectua
lucrarea.
Tehnologiile
sunt
descrise
individual
pentru
a
veni
în
sprijinul
lectorului,
ajutând-ul
să
în
ț
eleagă
rolul
fiecărei
tehnologii,
întrebuin
ț
area
lor,
cât
ș
i
pentru
a
făuri
o
viziunea
în
legătură
cu
modul
de
utilizare
a
acestora.
Accentuăm
faptul
ca
fiecare
tehnologie
în parte este gratuită
ș
i se încadrează în cele mai folosite pentru astfel de proiecte.
Capitolul I
Introducere
1.1 Contextul proiectului
În
contextul
actual,
timpul
joacă
un
rol
esen
ț
ial
în
productivitate.
Nevoia
de
a-l
administra
corect
este
esen
ț
ială
pentru
buna
desfă
ș
urare
a
lucrurilor.
În
acest
sens
tehnologia
joacă
un
rol
important.
Tehnologia
modernă
sprijină
această
nevoie,
prin
aplica
ț
ii
orientate
spre
anumit
func
ț
ionalit ă
ț
i.
Tehnologia
acordă
posibilitatea
de
îmbunătă
ț
i,
simplifica
ș
i
eficientiza diverse activită
ț
i zilnice.
Problema
acestor
servicii,
a
aplica
ț
ilor
deja
existente,
constă
în
timpul
ce
se
acordă
acestora,
fapt
ce
duce
la
timp
pre
ț
ios
pierdut
oferit
diverselor
activită
ț
i,
ce
pot
să
fie
reduse
ca
ș
i
timp
de
execu
ț
ie.
Timpul
acordat
sarcinilor
de
zi
cu
zi,
poate
să
fie
folosit
în
alte
scopuri.
În
domeniul
IT,
totul
este
gândit
la
timp,
astfel
el
joaca
un
rol
important
pe
parcursul
unei zile.
Ceea
ce
vrem
să
spunem
este
că
majoritatea
serviciilor
de
genul
au
o
interfa
ț
ă
complicată,
în
unele
cazuri
cu
multe
elemente
ce
nu
reprezinta
utilitate
pentru
toate
cazurile,
greu
de
folosit
ș
i
ce
necesită
timp
pentru
completarea
lor.
Problema
de
bază
este
că
în
sinea
lor,
ele
sunt
gândite
ș
i
implementate
pentru
produc
ț
ie,
ca
ele
să
servească
o
gamă
cât
mai
largă
de
clien
ț
i.
Datorita
acestui
lucru
se
pierde
esen
ț
a
ș
i
se
ajunge
la
povară
din
punct
de
vedere
al
unui
angajat
de
a
realiza
acest
“task”.
Ele
nu
sunt
făcute
“user
friendly”
pentru
cel
ce
o
utilizează,
astfel
elanul
de
la
începutul
zilei
scade
datorită
acestui
lucru.
Acesta
este
un
factor
negativ
ce
î
ș
i
lasă
amprenta
asupra
angajatului
pe
timpul
zilei,
afectând
astfel
productivitatea.
Este
cunoscut
tuturor
faptul
că
în
via
ț
a
trebuie
făcute
ș
i
lucrurile
ce
displac,
ș
i
activită
ț
i
ce
sunt
făcute
doar
pentru
că,
acesta
este
sistemul,
sau
pentru
că
a
ș
a
trebuie.
Întrebarea
este
de
ce
nu
am
face
acele
lucruri
cu
drag?
de
ce
să
nu
eliminam
partea
neplăcută
din ea
ș
i să avem ceva efi cient, simplu
ș
i prompt?
De
la
aceste
întrebări
existen
ț
iale
a
ș
putea
spune
a
plecat
conceptul
implementat
în
proiectul
Hito.
De
ce
sa
nu
avem
rezolvări
la
probleme
care
aparent
sunt
rezolvate,
dar
rezolvarea
lor
nu
este
una
din
unghiul
potrivit?
De
ce
nu
am
optimiza
deja
o
solu
ț
ie,
dacă
exista una mai bună?
În
contextul
în
care
potrivit
INS
(Institutul
Na
ț
ional
de
Statistică)
83,6
%
din
popula
ț
ia
României
lucrează
în
sectorul
privat.
Autorii
mai
multor
studii
recente
pe
o
perioada
de
6
ani
(2011-2016),
au
ajuns
la
concluzia
că
în
România
la
nivel
na
ț
ional
pe
perioada
specificată
numărul
firmelor
de
IT
a
crescut
cu
50
%
de
la
9.823
la
14.339
cu
previziunea
că
numărul
o
sa
fie
depă
ș
ească
17.000
la
finalul
anului
2017.
Peste
100.000
de
români
lucrează
pe
pia
ț
a
IT,
ceea
ce
înseamna
peste
6
%
din
PIB-ul
ț
ării.
Astfel
putem
concluziona
din
această
statistică
că
peste
100.000
de
români
se
confruntă
zilnic
cu
probleme
comune, indiferent de sectorul în care î
ș
i dezvoltă activitate în IT.
Ceea
ce
urmăre
ș
te
aceasta
aplica
ț
ie
este
de
a
oferi
divers e
solu
ț
ii
la
probleme
diferite
întâlnite zi de zi de oamenii din interiorul unei firme, de la “CEO” la “Developer”.
1.1.1 Administrarea angaja
ț
ilor
In
companii
de
mărime
medie
sau
mare,
în
momentul
în
care
se
dore
ș
te
o
informa
ț
ie
specifică
pentru
un
anumit
angajat
(contract,
concediu,
etc.)
este
nevoie
ca
echipa
de
la
HR,
să
caute
fizic
într-o
mul
ț
ime
de
documente
oficiale
ș
i
hârtii
pentru
a
găsi
ș
i
a
avea
acces
la
informa
ț
ie.
Aces t
lucru
durează
deseori
mult,
în
cazul
în
care
angajatul
are
o
vechime
destul
de
mare
în
firma
dar
nu
numai.
În
cazul
firmelor,
în
fiecare
lună
se
fac
sute,
poate
zeci
de
documente
oficiale.
Atunci
când
se
cere
ceva
din
acele
documente,
pe
lângă
metoda
clasică, care este ineficientă, se pierde timp, care poate să fie dedicat altui cauze.
Este
important
sa
accentuăm
faptul
că
clauza
enun
ț
ată
nu
descurajează
sistemul
clasic
de
stocare
a
datelor
dintr-o
firmă,
ci
se
dore
ș
te
îmbunătă
ț
irea
lui
cu
ceva
mult
mai
eficient
ș
i
productiv.
Ceea
ce
vrem
să
spunem
este
că
o
modalitate
de
a
ridica
ș
tacheta
acestui
nivel
este
printr-un
modul,
după
cum
spune
ș
i
titlul
“administrează
angaja
ț
ii”.
Corect
spune
administrează
informa
ț
ia
angaja
ț
ilor,
datele
despre
ei
într-o
firmă.
Este
de
în
ț
eles
că
acest
concept se aplică
ș
i la adm inistrarea firmei în sine nu doar a angaja
ț
ilor.
Solu
ț
ia
acestei
probleme
de
a
stoca
informa
ț
ia
în
mod
clasic,
urmată
apoi
de
căutarea
fizică, o putem emite după cum urmează.
Prin
conceptul
implementat
al
acestui
modul
“Administrarea
angaja
ț
ilor”
se
dore
ș
te
stocarea
tuturor
informa
ț
iilor
despre
un
angajat
într-un
mediu
digital.
Acest
concept
se
aplica
ș
i
firmei
în
sine.
Astfel
stocarea
obi
ș
nuită
o
reducem
doar
ca
ș
i
arhivă.
Astfel
o
să
avem
arhiva
clasică
a
tuturor
documentelor,
dar
(
ș
i
aici
se
explică
avantajul
de
a
stoc
digital)
având
o
stocare
digitala
automat
avem
o
gestiune
mult
mai
buna,
mai
rapida,
dintr-un
singur
loc
a
informa
ț
iei. Astfel lucrur ile decurg mult mai repede
ș
i mai fluent.
Consideram
că
este
important
să
accentuăm
faptul
că
problema
descrisă
provine
din
realitate. Un exemplu scurt ar putea clarifica conceptul de fată.
Avem
o
firmă
de
nivel
mic
ce
tinde
este
spre
mediu.
Pe
parcursul
anilor
de
activitate,
se
strâng
dosare
cu
mii
de
foi
la
activ.
Cu
timpul
firma
devine
mare,
cu
un
număr
mare
de
angaja
ț
i.
Problema
vine
în
momentul
în
care
se
dore
ș
te
o
anumită
informa
ț
ie
dintr-un
an
specificat
sau
se
dore
ș
te
să
se
ș
tie
tot
istoricul
unui
angajat
în
acea
firmă
sau
luăm
în
considerare
un
control
din
partea
statului.
Aici
intervine
problema
de
gestiune.
Informa
ț
ia
este multă, ceea ce denotă că este nevoie timp destul de lung pentru verificare unor date.
Prin
implementarea
conceptului,
pe
lângă
stocarea
eficace,
avem
ș
i
op
ț
iunea
de
a
cauta
în
tot
amalgamul
de
informa
ț
ie.
astfel
ceea
ce
dura
extrem
de
mult,
se
poate
reduce
la
doar câteva minute.
Acest
modul
facilitează
digitalizarea
informa
ț
iei
firmei
care
mai
apoi
poate
să
fie
modificată,
actualizată,
ș
tearsă,
printată
sau
copiată
cu
o
eficien
ț
ă
mult
mai
mare
ș
i
cu
un
cost
semnificativ mai mic decât administrarea acelora
ș
i date în format fizic.
Astfel
că
datele
în
format
fizic
sunt
păstrate,
dar
doar
ca
ș
i
arhivă.
Totul
fiind
digitalizat.
1.1.2 Gestiunea individuală a fiecărui angajat
Acest
modul
urmăre
ș
te
ca
fiecare
angajat
să
de
ț
ină
un
cont
de
utilizator
specific
lui,
în
care
să
se
găsească
informa
ț
ii
personale
ș
i
informa
ț
ie
ce
ț
ine
de
locul
de
muncă.
Prin
asta
angajatul se poate gestiona singur.
Astfel
fiecare
persoană
are
un
cont
de
utilizator
personal.
În
acest
cont
se
găse
ș
te
informa
ț
ie
ce
poate
să
fie
modificată
de
angajat,
cât
ș
i
informa
ț
ie
ce
este
fixă
care
nu
poate
să
fie modificată sau
ș
tearsă .
Scopul
acestui
modul
din
aplica
ț
ie
este
acela
de
a
avea
informa
ț
ia
într-un
singur
loc,
care în prezent se află în diverse locuri, fie ele digitale sau stocare clasică.
Am
clarificat
faptul
că
informa
ț
ia
este
diversă
ș
i
personalizată
pentru
fiecare
utilizator.
Acum
să
ne
îndreptăm
aten
ț
ia
asupra
unor
elemente
informative
ce
sunt
în
acest
modul.
Suntem
în
totalitate
de
acord
asupra
faptului
că
o
parte
din
informa
ț
ie
nu
trebuie
să
fie
accesibilă
spre
modificare
sau
ș
tergere
de
către
angajat.
Astfel
dăm
spre
exemplu
func
ț
ia
de
ț
inută de angajat sau de partamentul în care activează.
Modulul
standard
sugerează
că
o
mare
parte
din
informa
ț
ie
este
modificabilă.
Pentru
a
oferi
o
imagine
de
ansamblu,
trecem
prin
următoarele
caracteristici.
Utilizatorul
are
o
sec
ț
iune
unde
se
află
informa
ț
ia
personală,
cum
este
numele,
adresa,
numărul
de
telefon,
adresa
de
email.
Un
alt
lucru
esen
ț
ial
este
o
rubrică,
cu
documentele
oficiale
ce
ț
in
de
acel
angajat.
Aici
trecem
spre
exemplu
contractul,
actele
semnate
de
acel
angajat,
adeverin
ț
ele
etc.
Toate
o
să
fie
într-un
istoric.
În
cazul
în
care
este
nevoie
de
ceva,
informa
ț
ia
este
u
ș
or
accesibilă.
Alt
lucru
de
remarcat
este
faptul
că
angajatul
nu
o
să
mai
fie
nevoie
să
î
ș
i
calculeze
zilele
de
concediu
rămase,
deoarece
acelea
o
să
fie
afi
ș
ate
automat,
iar
în
cazul
în
care
se
solicită
prin
cerere
aprobată,
respectivele
zile
să
fie
reduse
automat.
(această
caracteristică
se
împlete
ș
te cu un alt modu l, care îl tratăm pu
ț
in mai târziu).
O
altă
caracteristică
reprezintă
un
istoric
al
proiectelor
în
care
a
lucrat
respectivul
angajat,
cât
ș
i
o
listă
cu
proiectele
active.
Aici
putem
vorbi
ș
i
de
o
repartizare
pe
proiecte
ș
i
ore lucrate. Astfel avem orele lucrate pe fiecare proiect.
Ideea
acestui
modulului
vine
de
la
o
necesitate
în
via
ț
a
reală.
Pentru
a
gestiona
mult
mai eficace persoanele dintr-o firmă, o astfel de caracteristică ajută extraordinar de mult.
Modulul
prezentat
vine
atât
în
ajutorul
angajatului,
a
echipei
de
la
HR
cât
ș
i
a
CEO-ului.
Implementarea
conceptului
elimină
nevoia
de
a
gestiona
informa
ț
ia
fizica
prin
intermediul hârtiilor.
1.1.3 Eficientizarea procesului de recrutare
O altă temă ce este cuprinsă în acest studiu este recrutarea viitorilor angaja
ț
i.
Este
cunoscut
tuturor
faptul
că
în
momentul
în
cadrul
un
interviu,
există
momente
de
pauză
în
convorbirea
dintre
poten
ț
ialul
angajat
ș
i
cel
ce
recrutează.
Ț
inem
în
calcul
că
există
posibilitatea
a
mai
multor
interviuri
în
aceia
ș
i
zi
sau
pe
parcursul
a
unui
ș
ire
de
zile
(pentru
recrutor),
atât
pentru
angajare,
“internship”
sau
“training”.
Astfel
avem
câteva
probleme
ce
urmează să fie enun
ț
ate.
Pentru
a
putea
da
un
răspuns,
trebuie
sa
aruncăm
o
privire
mai
amănun
ț
ită
asupra
factorilor problematici.
Primul
lucru
de
remarcat
este
faptul
că
cel
ce
pune
întrebările
eventualului
angajat
este
nevoit
să
noteze
ceea
ce
se
spune
pentru
a
putea
analiza
ulterior
datele
pentru
un
verdict.
Astfel există mereu o pauză între întrebarea recrutorului
ș
i răspunsul celui intervievat.
Se
crează
pauze
în
convorbire,
lucru
ce
duce
la
momente
de
lini
ș
te,
care
nu
pot
sa
fie
evitate,
ceea
ce
duce
la
o
lini
ș
te
bizară
pentru
persoanele
implicate.
Acesta
este
un
mod
clasic
de a realiza un interviu, care este pe atât de ineficient pe cât
ș
i consumator de timp.
Trecând
din
nou
în
revistă
factorii
anteriori
am
putea
spune
că
fiecare
persoană
care
a
trecut printr-un interviu se poate să spună că a întâmpinat problema enun
ț
ată.
A
doua
problemă
reflectă
nevoia
de
a
lua
noti
ț
e
pe
baza
acelui
interviu.
Astfel
acest
factor
este
strâns
legat
de
primul,
find
precursorul
lui.
Datorita
faptului
că
scopul
unui
interviu
este
acela
de
a
analiza
datele
ce
reies
din
urma
lui,
pentru
a
putea
vedea
dacă
persoana respectivă se potrive
ș
te cu postul
ș
i cu principiile
ș
i valorile companiei.
Pe
lângă
faptul
că
procesul
notări
crează
problema
pauzelor
în
discu
ț
ie,
făcând
discu
ț
ia
să
nu
mai
fie
fluentă,
aceasta
necesită
ș
i
timp
îndelungat
după
interviu
spre
a
analiza
acela
date,
pentru
un
răspuns.Astfel
timpul
acordat
unui
astfel
de
“task”
este
dublat
sau
în
unele cazuri chiar triplat.
S-a
conceput
această
analiză
pentru
a
putea
identifica
o
solu
ț
ie
în
acest
cazuri.
Conceptul din spate este unul simplu, curat
ș
i eficient spre rezolvarea acestor probleme.
Solu
ț
ia
ambelor
probleme
se
axează
pe
cel
ce
face
recrutarea.
Astfel
oferim
anumite
caracteristici
ce
optimizează
procesul
cât
ș
i
reduce
durata
de
timp.
Modulul
în
cauză
ajută
recrutorul
să
se
concentreze
pe
discu
ț
ia
cu
posibilul
angajat
decât
a
lua
noti
ț
e.
Astfel
implementarea
unor
interfe
ț
e
grafice
inteligente
care
necesită
doar
câteva
click-uri
în
schimbul
noti
ț
elor.
Astfe l
se
elimină
pauzele
din
discu
ț
ie
datorita
acestor
interfe
ț
e,
ceea
ce
face totul fluent, ca
ș
i pe o discu
ț
ie.
Recrutorul
are
posibilitatea
de
a
încărca
CV-ul
în
modul
pentru
a
avea
acces
la
el
oricând,
prin
asta
se
elimină
nevoia
de
a
avea
multiple
programe
deschise
ș
i
necesitatea
de
a
administra
programele,
ce
ș
i
unde
se
află.
Men
ț
ionăm
faptul
că
recrutorul
are
posibilitatea
de
a
face
modele
specifice
fiecărui
post,
care
apoi
find
utilizate
în
func
ț
ie
de
context.
Aceste
modele pot fi apoi modificate în func
ț
ie de schimbări sau necesitate.
Pentru
a
în
ț
elege
mai
bine
acest
concept,
dăm
câteva
exemple
de
astfel
de
interfe
ț
e
pentru
transparen
ț
a
serviciului.
Un
exemplu
constă
acordarea
de
stele
pentru
un
anumit
răspuns. (3 stele din 5)
.
Alt
exemplu
constă
în
acordarea
unui
calificativ
răspunsului
sau
prin
bifarea
unei
liste
cu
tehnologii
cunoscute,
limbaje
de
programare
etc.Însumând
totul
în
câteva
cuvinte,
putem
spune
că
procesul
interfe
ț
elor
grafice
suprimă
numeroase
greută
ț
i
ce
ț
in
de
procesul
în
sine, urmat de analiza informa
ț
iei.
1.1.4 Eficien
ț
a între angaja
ț
i
Pentru
a
răspunde
la
această
afirma
ț
ie,
trebuie
să
aruncăm
o
privire
mai
amănun
ț
ită
asupra
procesului
din
spatele
unei
cereri
de
concediu
ș
i
cum
lipsa
acestui
modul
lezează
demersul unui proiect.
În
marea
majoritate
a
firmelor,
angajatul
trebuie
să
discute
cu
team
leader-ul,
apoi
cu
personalul
de
la
resurse
umane,
ca
după
cererea
să
fie
aprobată
sau
nu
de
persoana
de
la
conducere.
Astfel
fiecare
angajat
trebuie
sa
comunice
echipei
din
care
face
parte,
ziua/zilele
de
concediu.
Asta
pentru
a
se
putea
ț
ine
cont
de
ele,
pentru
buna
desfă
ș
urare
a
proiectului.
Men
ț
ionăm
că
un
angaja t,
poate
să
fie
implicat
în
mai
multe
proiecte,
nu
doar
în
unul
,
ceea
ce
complică
lucrurile.
Simplul
fapt
de
a
uita
să
specifici
perioada
concediului,
sau
de
a
nu
se
tine cont de ea, poate aduce probleme cu respectiva echipă
ș
i astfel proiectului în sine.
Îmbră
ț
i
ș
ăm
cu
căldură
ideea
conformă
căreia
fiecare
problema
ori
cât
de
mica,
mare,
semnificativa
sau
mai
pu
ț
in
importanta,
poate
să
facă
diferen
ț
a
în
cadrul
unei
echipe,
a
dezvoltării proiectului
ș
i eficien
ț
a echipei.
Prin
implementarea
acestui
modul
dorim
să
eficientizăm
atât
procesul
în
sine
cât
ș
i
să
îmbunătă
ț
im
comunicare a
între
angaja
ț
i.
Se
dore
ș
te
eliminarea
necesita
ț
i
de
a
“
ț
ine
minte”
când
ș
i în ce perioadă cin eva este în concediu sau notarea acestui lucru.
Datorită
acestui
modul,
eficien
ț
a
activită
ț
ilor
cre
ș
te,
iar
asta
duce
la
o
mai
bună
comunicare a angaja
ț
ilor.
Ideea
din
spate
este
de
a
putea
aplica
cererile
de
concediu
online,
iar
asta
elimină
necesitatea
de
a
face
totul
fizic,
(astfel
totul
se
întâmplă
online)
cererea
fiind
trimisă
din
interiorul
modulului
spre
team
leader,
echipei
de
la
resurse
umane
sau
spre
persoana/persoanele ce se ocupă de acest lucru.
Conceptul
nu
se
opre
ș
te
aici
însă.
După
aprobarea
cererii
de
concediu,
angajatul
(care
are deja un cont de utilizator) are posibilitatea de a vedea bilan
ț
ul zilelor de concediu rămase.
Alt
lucru
de
important
este
faptul
că
cererile
aprobate
sunt
sincronizate
în
calendarul
fiecărui
angajat,
astfel
fiecare
echipă
poate
să
urmărească
ș
i
să
vadă
concediul
fiecărui
membru al echipei în calandrul comun al echipei.
În
linii
mari
modulul
prezentat
se
concentrează
asupra
problemelor
comune
în
cadrul
echipelor
ș
i al proiectelor .
1.1.5 Pontaj
Pontajul
reprezintă
urmărirea
timpului
ș
i
a
ceea
ce
a
fost
realizat
în
acel
interval.
Prin
acest
lucru
se
poate
urmări
activitatea
unui
angajat,
ceea
ce
face,
la
ceea
ce
lucrează,
la
ce
a
lucrat sau orele de lucru.
La
momentul
de
fa
ț
ă,
serviciile
de
pontaj
sunt
implementate
la
scara
largă,
asta
înseamna
că
o
singură
aplica
ț
ie
trebuie
să
servească
cât
mai
multe
firme
de
pe
pia
ț
ă.
Problema
este
că
lucru
acesta
vine
în
defavoarea
firmelor,
care
au
nevoie
de
ceva
specific
în
domeniul
de
lucru
al
firmei.
Ceea
ce
se
implementează
nu
satisface
necesitatea,
ci
necesitatea
se
pliază
după
ceea
ce
exista
deja
implementat
pe
un
caz
general.
Multe
firme
folosesc
acela
ș
i
serviciu la cerin
ț
e diferite .
Dorim
ca
ceea
ce
implementăm
să
satisfacă
necesită
ț
ile
specifice
ș
i
nu
necesitatea
să
fie
par
ț
ial
rezolvată.
Nu
se
dore
ș
te
rezolvarea
ei,
specific
pe
necesitatea
firmei.
Acest
modul
este orientat pentru a satisface domeniul IT în general.
Modulul
oferă
posibilitatea
de
pontaj
pentru
a
se
ț
ine
cont
de
timpul
în
cadrul
companiei.
Contorizarea
timpului
înregistrat
de
utilizatori
pentru
fiecare
activitate
în
parte.
Fiecare
utilizator
are
posibilitatea
de
a-
ș
i
introduce
singur
informa
ț
ii
despre
proiecte,
activitatea
desfă
ș
urată,
durata
de
timp
la
fiecare
“task”/proiect,
cât
ș
i
detalii
specifice
de
implementare,
noti
ț
e
sau
explica
ț
i.
Astfel
se
poate
vedea
câte
ore
au
fost
alocate
fiecărui
proiect în parte pentru fiecare firmă, ce “task-uri” au fost rezolvate, cât
ș
i noti
ț
ele memorate.
Astfel
se
poate
avea
un
raport
asupra
activită
ț
ii
angajatului,
având
numărul
de
ore
totale,
cât
ș
i
orele
dedica te
fiecărui
proiect
în
parte.
Modulul
include
posibilitatea
de
a
putea
introduce intervalul orar asupra activită
ț
ii zilnice.
Este
important
să
accentuăm
că
datele
introduse
de
utilizator
sunt
apoi
prelucrate
ș
i
transformate
în
rapoarte
ș
i
statistici
pentru
a
reduce
timpul
acordat
birocra
ț
iei,
cât
ș
i
procesarea acesteia de către cineva pentru a realiza rapoarte.
Func
ț
ionalitatea
urmăre
ș
te
ca
timpul
acordat
înregistrări i
fiecărei
activită
ț
i
să
fie
cât
mai
pu
ț
in,
să
fie
în
acela
ș
i
timp
eficient,
iar
asta
să
conducă
la
realizarea
rapoartelor,
a
statisticelor automat pe baza celor scrise.
Putem
concluziona
ș
i
afirma
faptul
că
metoda
descrisă
permite
economisirea
de
energie, care poate sa fie îndreptată spre alte activită
ț
i.
1.2 Ideea
ș
i scopul proiectului
Proiectul
a
plecat
de
la
dorin
ț
a
de
a
îmbunătă
ț
i
gestionarea
resurselor
umane.
Problemele
prezentate,
produc
un
anume
impediment
pe
parcursul
activită
ț
ii
unei
firme.
Fapte
ce
pun
un
obstacol
în
calea
realizării
unor
inten
ț
ii,
ce
aparent
nu
constituie
o
problema
ș
i
care
se
rezolva
într-un
timp
scurt,
sau
cel
pu
ț
in
a
ș
a
sunt
clasificate
la
început.
Acest
lucru
se
întâmplă
deoarece
nu
sunt
lua
ț
i
în
calcul
to
ț
i
factori
implica
ț
i.
S-a
ajuns
aici
pentru
că
nimeni
nu
este
interesat
de
a
oferi
ceva
ce
rezolva
o
anume
problema,
ce
satisface
o
arie
de
necesită
ț
i,
ci
în
schimb
se
merge
pe
variante
vagi,
ce
sunt
aplicabile
în
multe
cazuri,
astfel
totul se rezuma la câ
ș
tig
ș
i nu la dorin
ț
a de a rezolva problemele actuale în totalitatea lor.
Fiecare
solu
ț
ie
găsită,
rezolvă
anumite
probleme,
însă
solu
ț
ia
Hito
este
concepută
pentru
a
aduna
cele
mai
bune
solu
ț
ii
într-un
singur
loc.
Avem
astfel
o
varietate
de
“solu
ț
ii”
care
de
ș
i
aparent
rezolv ă
o
problemă
(sau
mai
multe),
în
sinea
lor
ea,
este
rezolvată
doar
par
ț
ial.
Astfel
dificultatea
persistă,
ceea
ce
afectează
elementele
unei
firme,
de
ș
i
doar
par
ț
ial,
obstacolul
tot
exista,
el
rămâne
acolo.
Întrebarea
a
fost
pusa
în
felul
următor:
De
ce
sa
nu
rezolvăm
problemele
în
întregime?,
De
ce
nu
am
putea
avea
următorul
concept,
spre
a
rezolva exact următoarele dificultă
ț
i?
Proiectul
“Hito”
a
pornit
de
la
aceste
întrebări
de
bază.
Proiectul
după
cum
spune
ș
i
numele
lui,
este
conceput
de
la
început,
implementat
ș
i
realizat
pentru
oameni.
Pentru
a
simplifica
munca,
problemele
ș
i
procesele
ce
pot
sa
fie
atât
simplificate,
cât
ș
i
eficientiza-te.
Proiectul
urmăre
ș
te
omul,
nu
firma.
O
companie
cre
ș
te
prin
oameni,
de
aici
deducem
logic
că,
pentru
a
simplifica
procese
ce
ț
in
de
sistem
ș
i
pentru
a
eficientiza
compania,
problema
trebuie
privită
astfel
încât
să
ajutăm
pe
aceia
care
fac
ca
acel
sistem
să
existe
ș
i
nu
structura
în
sine. Rezolvând astfel problemele oamenilor, se poate vorbi de o cre
ș
tere a companiei.
Un
alt
punct
al
proiectului
a
fost
faptul
că,
aceste
sarcini
necesitau
timp
îndelungat,
timp
care
ar
putea
să
fie
dedicat,
direc
ț
ionat
spre
alte
lucruri.
Aceste
sarcini,
au
nevoie
de
mult
timp
alocat
lor,
protocolul
fiind
prea
lung,
ineficient
ș
i
consumator
de
energie.
Putem
avea
ca
ș
i
exemplu
birocra
ț
ia.
Uneori
se
consumă
zeci
de
ore
lunar
pentru
realizarea
unor
cerin
ț
e
care
în
propor
ț
ie
de
80-90
%
sunt
asemănătoare
ceea
ce
face
ca
productivitatea
să
scadă
datorită
ineficien
ț
ei
prin
care
se
înfăptuiesc
ele
momentan.
Avem
ca
ș
i
exemple
problemele
deja
enun
ț
ate
anterior.
Se
dore
ș
te
rezolvarea
acestor
probleme,
prin
implementarea mai multor servicii care să vina în ajutorul angajatului.
Toate
aceste
argumente
indică
faptul
că
problemele
există,
sunt
reale.
Solu
ț
ia
o
avem,
iar
aceasta
este
“Hito”.
Ra
ț
ionamentele
expuse
demonstrează
de
ce
considerăm
“Hito”
important, valoros cât
ș
i o solu
ț
ie viabilă.
1.3 Solu
ț
ii existente în domeniul proiectului – State of the art
Pentru a putea pune în lumina avantajele proiectului “Hito”, a fost nevoie de crearea
unui studiu de pia
ț
ă asupr a serviciilor deja existente în domeniul prezentat, acest lucru
ajutând la conturarea unui proiect distinct.
Studiul
pie
ț
ei
reprezintă
colectarea
informa
ț
iilor
de
pe
pia
ț
ă,
în
func
ț
ie
de
ce
informa
ț
ii
sunt
necesare ,
dezvoltatorul
abordează
cercetarea
privind
cererea,
oferta
sau
mediul
înconjurător
de
pe
pia
ț
a
respectivă
.
Cercetarea
tine
cont
de
poten
ț
ialii
concuren
ț
i
de
1
pia
ț
ă,
care
sunt
ofertele
lor,
politica
comerciala
ș
i
felul
în
care
se
rela
ț
ionează
ei
la
client.
(viziunea
lor
despre
necesită
ț
ile
clien
ț
ilor).
Subliniem
faptul
că
este
important
să
clarificăm
publicul
la
care
se
adresează
aceste
servicii.
“Hito”
se
încadrează
doar
firmelor
din
domeniul
IT (acesta nu este construit pentru a satisface o gama larga de clien
ț
i, ci specific o ramură).
1
Defini
ț
ia unui studiu de pia
ț
ă:
http://www.studii-piata.ro/definitie.htm
(data accesării: 20.03.2018)
Studiul
de
pia
ț
ă
se
formează
prin
strângerea
ș
i
analizarea
informa
ț
iilor
referitoare
la
clien
ț
i,
competitori
ș
i
pia
ț
ă.
Studiul,
construit
în
manieră
profesională
constituie
funda
ț
ia
unui
plan
de
afaceri,
lansarea
unui
produs
sau
a
unui
serviciu,
etc.
Studiul
este
construit
din
mai
multe
etape.
Exista
patru
etape
în
cardul
unui
studiu
de
pia
ț
ă:
încadrarea
proiectului,
colectarea informa
ț
iilor, a naliza informa
ț
iilor
ș
i redactarea raportului studiului.
2
În
prima
etapă
se
stabile
ș
te
contextul
în
care
se
încadrează
proiectul
studiului.
În
cazul
proiectului
Hito,
contextul
se
rezumă
la
mul
ț
imea
serviciilor
care
oferă
modulele
prezentate,
într-o forma simplă, u
ș
or de utilizat,
ș
i cu un design modern.
În
a
doua
etapă
se
realizează
o
colectare
a
informa
ț
iilor
ce
sunt
disponibile
atât
pe
internet
(site-uri
web),
cât
ș
i
căr
ț
i,
articole,
etc.
Pentru
a
săvâr
ș
i
o
analiză
bună
a
pie
ț
ei,
este
nevoie
de
foarte
mare
aten
ț
ie
având
în
vedere
pia
ț
a
vastă.
Datorita
contextului
în
care
se
încadrează
Hito,
căutările
au
fost
făcute
pe
internet
(diverse
site-uri),
fie
ele
site-urile
concuren
ț
ei,
topuri
(clasamente),
articole
care
prezentau
diferite
func
ț
ionalită
ț
i,
diverse
servicii
sau
aplica
ț
ii.
Acest
studiu
a
fost
efectuat
pentru
a
găsi
modele
deja
existente,
care
se
încadrează în context.
Etapa
a
trei
a
studiului
este
de
a
analiza
informa
ț
iile
găsite
detaliat,
de
a
crea
statistici,
chestionare,
pentru
a
compara
rezultatele
cu
necesitatea
(dacă
este
cazul),
etc.
Analiza
a
fost
realizată
din
punct
de
vedere
al
producătorului,
al
creatorului,
dar
ș
i
din
perspectiva
clientului,
sunt
foarte
important
aceste
punctul
de
vedere,
deoarece
se
dore
ș
te
să
se
ofere
clientului
ceea
ce
î
ș
i
dore
ș
te.
Astfel
structurăm
serviciile
găsite
în
două
feluri:
În
primul
punct avem dezavantaje existente în serviciile deja existente.
Primul
serviciu
găsit
a
fost
unul
destul
de
bun
din
punct
vedere
al
func
ț
ionalită
ț
i-lor.
3
Problema
a
fost
sesizată
în
momentul
în
care,
un
utilizator
cu
cont
în
serviciu,
nu
are
posibilitatea
de
a
ș
-i
administra
el
informa
ț
ia
personală.
Totul
trebuia
predefinit,
astfel
utilizatorul
nu
are
nici
un
“feature”.
(reamintim
faptul
că
îl
modulul
Hito,
se
dore
ș
te
ca
utilizatorul
să
î
ș
i
admini streze
singur
informa
ț
ia
personală
din
interiorul
cont-ului,
existând
un
procent
al
informa
ț
iei
ce
este
static).
Este
considerat
un
dezavantaj
pentru
că
acest
lucru
rezumă
munca
la
o
singură
persoana
responsabilă.
Alt
lucru
dezavantajos
în
serviciul
în
cauză
este
faptul
că
este
creat
pentru
o
gama
larga,
astfel
există
func
ț
ionalită
ț
i
care
nu
o
să
fie
folosite
de
to
ț
i
clien
ț
ii.
Utilizând
serviciul
pentru
a
testa
func
ț
ionalită
ț
i-le
oferite,
se
poate
observa
un
minus
în
departamentul
de
recrutare.
Recrutorul
are
sec
ț
iunea
cu
posturile
vacante,
o
lista
cu
fiecare
care
a
aplicat
pe
un
anume
post;
iar
totul
se
opre
ș
te
aici.
Spre
deosebire,
Hito,
oferă
interfe
ț
e
grafice
pentru
a
ajuta
recrutorul
în
procesul
de
interviu.
Totu
ș
i
un factor de apreciat îl consideră design-ul aplicat serviciului, este unul simplist
ș
i elegant.
Trecând din nou în revistă factorii putem spune că următoarele doua
servicii
găsite,
4
5
sunt considerate dezavantajoase, cât
ș
i greu de folosit, încărcate grafic, totul fiind greu de
identificat, oferind clientului confuzie
ș
i nu transparen
ț
a
ș
i simplitate pentru astfel de servicii
2
Etapele unui studiu de pia
ț
a:
http://www.studii-piata.ro/etape.htm
(data accesării: 20.03.2018)
3
OrangeHRM:
https://www.orangehrm.com/
(accesat la data de 20.03.2018)
4
Mystaff :
http://www.smartree.com/portfolios/administrare-personal/
(data accesării: 20.03.2018)
5
Wizrom:
http://www.wizrom.ro/ro/
(data accesării: 20.03.2018)
complexe. Remarcăm
ș
i faptul că lipsa unui design actual face ca totul să fie considerat un
serviciu abandonat (datorită lipsei actualizărilor).
Analizând alte serviciu
, putem concluziona faptul că de
ș
i avem un front-end modern,
6
structura modulelor este unul greu de citit
ș
i de în
ț
eles. Avantajul design-ului modern este
anulat de ineficien
ț
a struc turilor implementate.
Un exemplu interesant avem în caracteristicile serviciului
următor: posibilitatea de a
7
folosi sistemul de supraveghere pentru a stabili la cât a fost realizată de fapt pontarea, cine
intra în clădire, astfel se poate stabili dacă cine a intrat fraudulos. Un concept interesant, dar
poate nu atât de practic în totalitatea lui. Afirmam acest lucru, pentru ca în cazul dat, cineva
trebuie să verifice toate pe înregistrare datele. Acest lucru constituie o muncă istovitoare,
chiar
ș
i în cazul unei firm e mici, nici nu se pune problema de o firma mare, cu un poten
ț
ial de
sute de angaja
ț
i.
Ca
ș
i ultim exemp lu, avem serviciul
următor, care se apropie cel mai mult de
8
conceptul Hito. Având module similare cu cele prezentate în cadrul serviciului Hito, cu un
design modern
ș
i simplist , acest serviciu se poate remarca cu u
ș
urin
ț
ă ca find liderul
competi
ț
iei cu Hito. Cele doua servicii se disting (Hito având avantaj în defavoarea
serviciului) prin faptul că, Hito oferă modulele într-un singur serviciu. Competi
ț
ia oferă
clientului module separate (evident cu preturi pe fiecare modul), care fac ca serviciul sa fie
stângaci. Astfel se poate vedea o tehnică de marketing, pentru a atrage cât mai mult capital,
prin vânzarea de mai multor module aceluia
ș
i client. Hito nu urmăre
ș
te capitalul, ci
rezolvarea problemelor. Având totul într-un singur loc,înseamnă stabilitate, nefiind necesar
alt modul pentru a rezolva probleme din acela
ș
i domeniu.
A patra etapă, ultima, constă în raportul studiului care reflectă analiza, cu avantaje
ș
i
dezavantaje. În general aceste rezultate se pot prezenta
ș
i oral, având rol de a crea o discu
ț
ie
pe baza acestei cercetări. Luând în considerare cele prezentate mai sus, putem concluziona că
pe pia
ț
ă nu exista serviciu care să satisfacă suficient de bine dorin
ț
a
ș
i necesitatea domeniului
IT.
9
6
Optimoo:
(data accesării: 20.03.2018)
7
SVTech:
(data accesării: 20.03.2018)
8
Colorful:
https://www.colorful.hr/
(data accesării: 20.03.2018)
9
Defini
ț
ia unui studiu de pia
ț
ă:
http://www.studii-piata.ro/definitie.htm
(data accesării: 30.03.2018)
Capitolul II
Arhitectura aplica
ț
iei
Aplica
ț
ia
Hito
are
ca
ș
i
scop
oferirea
de
solu
ț
ii
simple,
u
ș
or
de
folosit,
intuitive
ș
i
orientate
spre
un
caz
particular.
Aplica
ț
ia
î
ș
i
extinde
aria
doar
pentru
companiile
de
nivel
mediu.
La
baza
solu
ț
iei
Hito
stau
modulele
special
gândite
ș
i
implementate
astfel
încât
fiecare
utilizator
are
sau
nu
o
acces
la
anumite
module,
astfel
interfa
ț
a
nu
este
confuză
ș
i
ocupată
de
tot
felul
de
func
ț
ionalită
ț
i
ce
nu
ajută
utilizatorul,
(probabil
nici
nu
are
nevoie
de
ele),
iar
asta
produce un anumit nivel de confuzie în utilizare.
Hito
se
poate
fi
împăr
ț
ită
în
două
păr
ț
i
mari:
Aplica
ț
ia
client,
dezvoltată
pentru
a
servi
ca
ș
i
aplica
ț
ie
web
(pentru
portabilitate),
fiind
implementată
cu
Angular
6,
cea
de
a
doua
parte
este
aplica
ț
ia
server
care
aduce
ș
i
gestionează
informa
ț
iile
care
urmează
a
fi
afi
ș
ate
pe
interfa
ț
a
client,
în
func
ț
ie
de
utilizator
(drepturi,
etc.),
iar
la
baza
serverului
stă
limbajul
de
programare Java.
2.1 Arhitectura serverului
Aplica
ț
ia
server
necesită
o
bază
de
date
capabilă
să
se
adapteze
la
schimbări
arhitecturale,
care
să
se
integreze
cu
alte
tehnologii
pentru
a
crea
un
server
u
ș
or
de
administrat
.
Astfel,
pentru
gestionarea
ș
i
acumulare a
de
informa
ț
ii,
oferite
de
serviciile
web,
o
bază
de
date
a
fost
constituită
pentru
a
suporta
acest
flux.
Serviciul
web
din
cardul
serverului,
prin
apeluri
HTTP,
returnează
un
fi
ș
ier
cu
informa
ț
ie
într-un
format,
cele
mai
des
folosite
sunt
JSON
ș
i
XML.
Structura
serverului
este
bazată
pe
standardele
de
tip
enterprise,
care
presupune
împăr
ț
irea
func
ț
ionalită
ț
i-lor
fără
a
crea
dependin
ț
e
una
de
cealaltă,
folosindu-se
de
interfe
ț
e,
în caz contrat erorile de compilare nu se pot evita.
Structura
arhitecturală
a
aplica
ț
iei
Hito
este
constituita
din
3
păr
ț
i
după
cum
se
vede
în
Figura
2.1;
ș
i
anume:
pachetul
de
servicii
(Service
Layer),
pachetul
de
func
ț
ionalitate/logică
(Business
Layer)
ș
i
pache tul
de
date
(Data
Layer).
A
patra
parte,
există,
ș
i
ea
este
comună
sau
inclusă celor trei păr
ț
i men
ț
ionate anterior.
Nivelul
de
servicii
(Service
Layer)
este
pentru
a
prelua
sursele,
ca
apoi
să
ofere
utilizatorului
informa
ț
iile
specifice
drepturilor
lui.
Acest
nivel
include
interfe
ț
e
pentru
comunicare,
parte
de
securitate,
autorizare
ș
i
validare.
În
cadrul
acestui
nivel
se
implementează
securitatea
serverului,
ea
fiind
compusă
din
autentificare
ș
i
autorizare.
Atunci
când
se
accesează
aplica
ț
ia,
utilizatorul
trimite
la
server
un
request
cu
datele
introduse
de
client,
care
urmează
să
fie
validate
de
server
(asta
dacă
se
trece
de
verificarea
din
client
pentru
a
nu
face
un
request
la
server
cu
nici
o
informa
ț
ie
de
validare).
Autentificarea
este
realizată
o
singură
dată
pentru
o
sesiune,
pentru
un
utilizator
anume,
o
a
doua
autentificare
este
necesară
doar
dacă
utilizatorul
se
deconectează
ș
i
dore
ș
te
a
se
loga
iară.
Exista
în
acest
nivel
ș
i o parte de validar e care verifica parametrii de intrare a serviciilor.
Al
doilea
nivel
arhitectural
(Business
Layer)
este
cel
ce
se
ocupă
de
logica
serverului.
Acest
nivel
transmite
datele
între
nivelul
superior
(Service
Layer)
ș
i
nivelul
de
date
(Data
Layer).
Îl
putem
considera
ca
o
punte
de
legătura
între
nivelele
serverului.
Acest
nivel
prelucrează
datele
primite
din
nivelele
superior
ș
i
inferior.
Informa
ț
ia
transmisă
la
nivelul
de
servicii
(Service
Layer)
este
sub
format
JSON
sau
XML.
Serverul
este
bazat
pe
acest
nivel,
lipsa
lui
face
ca
serverul
sa
nu
poată
comunica,
iar
func
ț
ionalitatea
lui
să
nu
existe.Serverul
poate
interpreta
informa
ț
ia,
iar
pentru
fiecare
utilizator,
se
aduc
datele
specifice
lui
după
drepturile setate în baza de date.
Nivelul
trei
al
arhitecturii
este
reprezentat
de
partea
de
date
sau
nivelul
de
informa
ț
ie
(Data
Layer).
Prima
componentă
a
acestui
nivel
reprezintă
entită
ț
ile
(Data
Entities),
rolul
lor
este
de
a
memora
o
perioadă
limitată
de
timp
informa
ț
ia.
Entită
ț
ile
acestea
sunt
obiecte
care
au
proprietă
ț
i
însu
ș
ite,
de
regula
private,
iar
acestea
se
pot
accesa
prin
metode
specifice
(cu
getter
ș
i
setter).
Aceste
entită
ț
i
sunt
utilizate
de
componen ta
următoare,
ș
i
anume
de
componentele
de
accesare
a
datelor
(Data
Access
Object
–
pe
scurt
DAO).
Informa
ț
iile
din
entită
ț
i,
într-o
bază
de
date,
sunt
salvate
prin
crearea
unei
cereri
(al
unui
query)
care
con
ț
ine
fiecare
coloană
cât
ș
i
proprietătiile
entită
ț
ilor.
Folosind
tehnolog ia
Hibernate,
se
men
ț
ionează
doar
entitatea
care
trebuie
salvată
sau
actualizată
sau
referin
ț
a
pentru
entitatea
care
se
caută,
Figura 2.1
Arhitectura serverului
iar
Hibernate
face
totul,
automat,
în
loc
ca
dezvoltatorul
să
fie
nevoie
să
facă
el
manual
aceste
lucruri.
Ultimul
nivel
este
cel
comun,
pentru
toate
nivelele
serverului.Toate
cele
trei
nivele
sunt
din
punct
de
vedere
arhitectural
independente,
au
însă
elemente
comune,
elemente
care
se
folosesc
în
fiecare
nivel
fără
a
crea
dependen
ț
ă
între
nivele,
aceasta
este
cunoscută
ș
i
sub
denumirea
de
“Cross
Cutting”.
În
cadrul
proiectului
Hito,
acest
nivel
are
denumirea
de
“sefer-commons”.
Un
sub-nivel
al
Cross
Cutting
este
“Exception
Management”
care
reprezintă
sistemul
de
excep
ț
ii,
conceput
pentru
a
putea
crea
excep
ț
ii
personalizate.
Prin
acest
lucru
se
pot
trata
excep
ț
iile
care
pot
apărea
în
cadrul
serverului.
Un
alt
mod
de
utilizare
reprezinta
avantajul
de
a
putea
crea
o
excep
ț
ie
sau
o
sumedenie
de
excep
ț
ii,
iar
atunci
când
se
aruncă
o
astfel
de
excep
ț
ie,
se
poate
transmite
pe
front-end
(aplica
ț
ia
client),
un
mesaj,
o
avertizare,
mesaj
de
eroare,
etc.
Un
exemplu
de
excep
ț
ie
este
atunci
când
în
formularul
de
logare
nu
se
introduc
ambele
câmpuri
sau
dacă
informa
ț
ia
nu
este
găsita
la
nivelul
bazei
de
date.
Figura 2.2
Obiect de transfer date (DTO)
Pentru
a
crea
obiecte
care
î
ș
i
însu
ș
esc
proprietă
ț
i
ale
entită
ț
ilor,
(datorită
modelului
de
date
de
complex),
folosim
conceptul
de
DTO
(Data
Transfer
Object)
pentru
a
putea
realiza
un
transfer
de
date.
DTO-urile
creat
sunt
folosite
pentru
a
încapsula
datele
care
doresc
să
fie
trimise
unui
alt
model
sau
nivel
al
aplica
ț
iei.
Figura
2.3
prezintă
procesul
unui
obiect
de
tip
DTO.
În
cadrul
unei
interfe
ț
e,
fiecare
apel
este
valoros,
în
momentul
în
care
se
accesează
aplica
ț
ia
de
la
distan
ț
ă
pentru
anumite
date.
Pentru
a
fluidiza,
trebuie
ca
numărul
de
apeluri
sa
fie
cât
mai
mic
posibil.
În
figura
2.2
observăm
faptul
că
dacă
obiectele
sunt
compuse,
automat
scade
numărul
de
apeluri.
În
dreapta
avem
doua
obiecte
în
rela
ț
ie
una
cu
cealaltă.
Pentru
a
avea
obiecte
mai
pu
ț
ine
(pentru
transfer),
s-a
creat
un
obiect
care
con
ț
ine
proprietă
ț
iile
ambelor
obiecte.
Putem
a
face
o
mică
compara
ț
ie
între
obiecte le
de
transfer
ș
i
obiectele
de
acces
(DAO
–
Data
Access
Object),
putem
privi
totul
din
perspectiva
compozi
ț
iei.
Astfel
putem
spune
că
DTO-urile
con
ț
in
doar
proprietă
ț
i
cu
accesori,
fără
metode
care
trebuiesc
testate,
când
obiectele
de
alte
tipuri
cum
sunt DAO-urile, trebuie testate temeinic.
Figura 2.3
Obiect de transfer date (DTO)
Ultima
parte
din
nivelul
commons,
denumit
“utilities”,
după
cum
putem
vedea
în
Figura
2.1,
cuprinde
necesită
ț
i
care
se
folosesc
în
alte
păr
ț
i
din
arhitectura
serverului.
Spre
exemplu,
avem
utilitatea
care
verifică
dacă
o
valoare
este
nulă
sau
dacă
valoare
are
spatii
goale, acestea să fie eliminate.
2.1 Arhitectura clientului Angular
Hito
este
implementat
astfel
încât,
acesta,
să
fie
cât
mai
simplu,
intuitiv
de
folosit
pentru
utilizator.
În
Angular
6,
UI-ul
unei
aplica
ț
ii
este
un
arbore
al
componentelor
sale.
Arhitectura
este
formată
astfel
încât
informa
ț
ia
este
recep
ț
ionată
de
la
un
serviciu
web
ș
i
afi
ș
ată utilizatorului pe in terfa
ț
ă.
Clientul
Angular
implementează
o
arhitectură
Component
Based
Architecture,
care
simplifică
func
ț
ionalitate a
din
front-end.
Arhitectura
“Component
Based”
oferă
avantaje
similare
cu
Object-Oriented
Model
(OOM).
Componentele
au
o
coeziune
ridicată,
fiecare
componenta
con
ț
ine
numai
elemente
cu
func
ț
ionalitate
asemănătoare.
Ele
sunt
de
asemenea
bine
încapsulate
ș
i
slab
cuplate
(loosly
coupled).
Astfel
API-ul
este
“clean”
ș
i
nu
dezvăluie
starea componentelor interne.
Avantajele acestei arhitecturi este reprezentată de faptul că este:
●
reutilizabilă
:
în
cazul
în
care
trebuie
să
expunem
aceea
ș
i
func
ț
ionalitate
în
mai
multe
locuri
din
aplica
ț
ie,
în
cazul
unei
componente
spre
exemplu,
care
face
deja
acest
lucru,
o
putem
folosi
în
toată
aplica
ț
ia,
acolo
unde
este
nevoie.
Prin
asta
economisim
timp
ș
i o sa avem o aplica
ț
ie mai consistentă.
●
testabilitate
:
este
mult
mai
u
ș
or
testarea
unei
componente
cu
un
API
bine
definit
ș
i
un
set restrâns de responsabilită
ț
i, decât o aplica
ț
ie nestructurată.
●
lizibilitate
:
componentele
bine
încapsulate
sunt
mult
mai
u
ș
or
de
în
ț
eles
decât
o
aplica
ț
ie
slab
structurată.
Când
componentele
sunt
aranjate
într-o
structura
adecvata
a
pachetelor, codul devine u
ș
or de citit.
●
mentenabilitate
:
componentele
dintr-un
sistem
loosly
coupled
pot
fi
u
ș
or
înlocuite
cu
implementări alternative.
Pentru
a
în
ț
elege
mai
bine
oferim
un
exemplu.
În
Figura
2.2.1,
avem
o
structura
a
unei
aplica
ț
ii.
Aplica
ț
ia
este
de
fapt
un
arbore
de
componente,
după
cum
am
spus.
Aplica
ț
ia
este
“order-app”,
care
găzduie
ș
te
alte
doua
componente:
“menu-list”
ș
i
“order-summary”.
Componenta
“menu-list”
implementează
func
ț
ionalitatea
unei
liste
de
meniuri,
acestă
componentă
nu
se
ocupă
specific
de
partea
logică
din
spatele
unui
meniu
individual.
Acest
lucru
este
delegat
componentei
“meal”.
Componenta
“meal”
are
chiar
componente
mai
specializate
care
se
ocupă
de
func
ț
ionalită
ț
i,
cât
ș
i
comportamentul
elementelor
de
coeziune,
cum
ar
fi
informa
ț
iile
nutri
ț
ionale.
Componenta
“meal”
este
reutilizată
în
“menu-list”
sau
“meal-of-the-day”.
Analizând
ace
ș
ti
factori,
putem
lua
o
concluzie
u
ș
oară
asupra
întrebării
“de ce arhitectura aceasta?”.
Figura 2.2.1
Component Based Architecture
Capitolul III
Tehnologii folosite
Conceptul
de
tehnologie
poate
sa
fie
definit
ca
pa
ș
ii
urma
ț
i
asupra
unei
materii
prime
care
are
ca
scop
realizarea
unui
produs.
Provine
din
limba
greacă,
unde
cuvântul
este
“tekhnologia”,
cuvânt
compus
din
“tekhne”
care
semnifică
“meserie
sau
artă”
ș
i
“logos”
care
înseamnă
“cuvânt”.
Specific
programării,
tehnologia
este
în
ț
eleasă
prin
crearea
unui
algoritm
sau
prin
combinarea
unora
deja
existen
ț
i pentru a ajunge la un produs final, definit ca
ș
i produs software.
La
nivel
de
business,
proiectele
sunt
stabilite
pas
cu
pas,
astfel
după
ce
arhitectura
este
definita,
se
aleg
tehnologiile
care
o
să
fie
folosite
pentru
realizarea
proiectului
final.
Ele
trebuie
sa
fie
compatibile cu ceea ce se dore
ș
te. Tehnologiile folosite trebuie să satisfacă cerin
ț
ele arhitecturii.
3.1 Java
Java
este
un
limbaj
de
programare,
orientat-obiect,
puternic
tipizat,
conceput
de
10
către
James
Gosling
la
Sun
Microsystems
(acum
filială
Oracle)
la
începutul
anilor
ʼ
90,
fiind
lansat
în
1995.
Cele
mai
multe
aplica
ț
ii
distribuite
sunt
scrise
în
Java.
Noile
evolu
ț
ii
tehnologice
permit
utilizarea
sa
ș
i
pe
dispozitive
mobile
gen
telefon,
smartphone,
smartwatch,
smartTV, aplicatii desktop etc.
Un
avantaj
considerabil
privind
limbajul
Java
este
faptul
că
o
aplicatie
compilată,
rulează
pe
orice
sistem
unde
avem
instalată
o
masina
virtuala,
pe
scurt
JVM
(Java
Virtual
Machine).
Avantaj
pe
care
nu-l
găsim
la
alte
limbaje
de
programare.Compilarea
surselor
se
face
printr-un
format
standard,
denumit
cod
de
octeti,
care
este
intermediar
între
codul
ma
ș
ină
ș
i codul sursă.
Ca
ș
i
construc
ț
ie,
limbajul
este
format
pe
un
set
de
dezv oltare,
prescurtat
JDK
(Java
Development
Kit).
Acest
set
ofera
programatorului
sursele
necesare
pentru
a
crea
o
aplicatie
Java
sau
framework-uri.
Setul
con
ț
ine
pachete
de
clase
care,
pentru
a
putea
sa
fie
folosite,
trebuie
importate
în
proiect.
Java
con
ț
ine
un
pachet
numit
java.lang
care
cuprinde
elementele
de bază ale limbajului, iar importarea lui nu este necesară.
3.1.1 Limbajul de programare Java
Bazat
pe
OOP
(object-oriented
programming),
concept
ce
a
apărut
la
finalul
anilor
‘50,
inceputul
aniilor
‘60.
Ca
ș
i
concept,
OOP-ul
sta
la
baza
a
doua
sau
mai
multe
obiecte
care
comunica
intre
ele
printr-un
mesaj.
Obiectul
în
Java
este
caracterizat
prin
stare
ș
i
comportament.
În
Java
obiectele
sunt
create
prin
instan
ț
ierea
unei
clase,
cu
alte
cuvinte
prin
crearea
unei
instan
ț
e
a
unei
clase.
Crearea
unui
obiect
presupune
trei
lucruri:
declararea
obiectului,
instantierea
ș
i
ini
ț
ializarea.
Declararea
obiectului
se
face
după
un
anumit
format
ce
10
Defini
ț
ia lmbajului de programare Java:
https://ro.wikipedia.org/wiki/Java_(limbaj_de_programare)
(data accesării: 30.04.2018)
trebuie
respectat.
Astfel
avem
sintaxa,
care
spune
ca
un
obiect
trebuie
sa
aibă
“NumeClasă
numeObiect”.
Declarăm
numele
de
clasă
“Firmă
angajat”.
Instantierea
se
realizează
prin
intermediul
operatorului
new
si
are
ca
efect
crearea
efectivă
a
obiectului
cu
alocarea
spa
ț
iului
de
memorie
corespunzător.
Avem
astfel:
angajat
=
new
Firmă
();.
Partea
de
ini
ț
ializare
se
execută
prin
intermediul
constructorului
clasei
respective.
Firmă()
este
un
apel
către
constructorul
clasei
Firmă
care
este
responsabil
cu
ini
ț
ializarea
obiectului.
Initializarea
se
poate
face
ș
i
cu
anumiti
parametri,
cu
condi
ț
ia
să
existe
un
constructor
al
clasei
respective
care
să
accepte
parametrii
respectivi.
angajat
=
new
Firmă(0,
0,
100,
200);
O
metodă
poate
avea
mai
multe
tipuri
de
parametrii
de
intrare
ș
i
un
singur
tip
de
parametru
de
ie
ș
ire,
printre
care
este
ș
i
“void”
care
nu
returnează
nimic.
Ca
parametru
de
ie
ș
ire
se
poate
pune
ș
i
un
obiect
generic,
în
cazul
limbajului
Java
se
poate
folosi
“Object”
care
este
extins
de
toate
obiectele
Java
“by
default”.
Obiectele
sunt
compuse
din
proprietă
ț
i
si
metode
care
asigura
comunicarea
între
ele.
În
momentul
în
care
este
apelata
o
metodă
a
unui
obiect,
se
trimite
un
mesaj
acelui
obiect, prin care se transmite o comandă.
În
Java
există
patru
tipuri
de
clase:
Interfe
ț
ele
duc
conceptul
abstract
un
pas
mai
departe.
Se
poate
considera
că
o
interfa
ț
ă
este
o
clasă
abstractă
pură,
ea,
permite
programatorului
să
stabilească
o
"formă"
pentru
o
clasă:
numele
metodelor,
lista
de
argumente,
valori
intoarse,
dar
fără
nicio
implementare.
O
interfa
ț
ă
poate
con
ț
ine
câmpuri
dar
acestea
sunt
în
mod
implicit
static
ș
i
final.
Interfa
ț
a
este
folosită
pentru
a
descrie
un
protocol
între
clase,
o
clasă
care
implementează
o
interfa
ț
ă
va
implementa
metodele
definite
în
interfa
ț
ă.
Astfel
orice
cod
care
folose
ș
te
o
anumită
interfa
ț
ă
ș
tie
ce
metode
pot
fi
apelate
pentru
acea
interfa
ț
ă.
Pentru
a
crea
o
interfa
ț
ă
folosim
cuvantu l
cheie
“interface”
în
loc
de
“class”.
La
fel
ca
în
cazul
claselor,
interfa
ț
a
poate
fi
declarată
public
doar
dacă
este
definită
într-un
fi
ș
ier
cu
acela
ș
i
nume
ca
ș
i
interfa
ț
a.
Dacă
o
interfa
ț
ă
nu
este
declarată
public
atunci
specificatorul
ei
de
acces
este
package-private.
Pentru
a
defini
o
clasă
care
este
conformă
cu
o
interfa
ț
ă
anume
folosim
cuvantul
cheie
“implements”.
Această
rela
ț
ie
este
asemanatoare
cu
mo
ș
tenirea,
cu
diferen
ț
a
că
nu
se
mo
ș
tene
ș
te
comportamentul,
ci
doar
"interfa
ț
a".
Pentru
a
defini
o
interfa
ț
ă
care
mo
ș
tene
ș
te
altă
interfa
ț
ă
folosim
cuvântul
cheie
“extends”.
După
ce
o
interfa
ț
ă
a
fost
implemen tată,
acea
implementare
devine
o
clasa
obi
ș
nuită
care
poate
fi
extinsă
prin mostenire.
Al
doilea
tip
de
clasă
este
clasa
abstractă
care
con
ț
ine
atât
metode
cu
implementare,
dar
si
metode
care
nu
sunt
implementate.
Stabilim
o
interfa
ț
ă
comuna
pentru
a
putea
crea
functionalitate
diferita
fiecărui
subtip
ș
i
pentru
a
ș
ti
ce
anume
au
clasele
derivate
în
comun.
O
clasă
cu
caracteristicile
enumerate
mai
sus
se
nume
ș
te
abstractă.
În
momentul
în
care
se
crează
o
clasă
abstractă,
se
dore
ș
te
manipularea
unui
set
de
clase
printr-o
interfa
ț
ă
comună,
reutilizarea
unor
serii
de
metode
si
membrii
din
aceasta
clasă
în
clasele
derivate.
Metodele
suprascrise
în
clasele
derivate
vor
fi
apelate
folosind
dynamic
binding
(late
binding).
Acesta
este
un
mecanism
prin
care
compilatorul,
în
momentul
în
care
nu
poate
determina
implementarea
unei
metode
în
avans,
lasă
la
latitudinea
JVM-ului
(masinii
virtuale)
alegerea
implementării
potrivite,
în
func
ț
ie
de
tipul
real
al
obiectului.
Acestă
legare
a
implementării
de
numele
metodei
la
momentul
executiei
sta
la
baza
polimorfismului.
Nu
există
instan
ț
e
ale
unei
clase
abstracte,
aceasta
exprimând
doar
un
punct
de
pornire
pentru
definirea
unor
instrumente
reale.
De
aceea,
crearea
unui
obiect
al
unei
clase
abstracte
este
o
eroare,
compilatorul Java semnaland eroare în acest caz.
Al
treilea
tip
de
clasă
este
clasa
normală
care
nu
are
modificatorul
“abstract”
sau
“interface”.
Execu
ț
ia
constructorului,
este
diferen
ț
a
majoră
dintre
clasele
“interface”,
“abstract”
ș
i
clasele
norm ale.
Prin
constructor
se
poate
crea
un
obiect
de
acea
clasă.
Clasele
normale pot avea doar metode cu implementare.
Ultimul
tip
de
clasă
este
cea
de
tip
“Enum”.
O
enumerare,
sau
“enum,”
este
pur
ș
i
simplu
un
set
de
constante
pentru
reprezentarea
valori.
Un
“enum”
este
de
fapt
un
tip
de
clasă,
care
se
poate
declara
ca
fiind
clasă
inetrnă
sau
exterioară.
Putem
declara
variabile
de
tip
enum
ș
i
să
ob
ț
inem
siguran
ț
a
tipurilor
ș
i
verificarea
la
compilare.
Fiecare
valoare
declarată
este
o
instan
ț
ă.
Tipul
“enum”
poate
sa
fie
implicit
public,
static
ș
i
final.
Enum-urile
sunt
folosite
în
general
pentru
a
specifica
cuvinte
care
nu
se
modifică,
un
exemplu
ar
fi
numele
lunilor
unui
an.
Instan
ț
ierea
se
face
utilizănd
operatorul
new.
Cu
ajutorul
ma
ș
inii
virtuale
(JVM), aplicatia poate sa ruleze pe mai multe dispozitive separate.
Caracteristici
principale
ale
limbajului
Java:
Un
prim
punct
este
faptul
ca
limbajul
este
complet
orientat
pe
obiecte,
eliminând
astfel
programarea
procedurală,
iar
principiile
OOP
sunt
respectate:
mo
ș
tenirea,
încapsularea,
polimorfismul
ș
i
abstractizarea.
Accentuăm
ceea
ce
am
explicat
anterior,
ș
i
anume
faptul
că
o
aplicatie
scrisă
în
Java
poate
sa
fie
rulată
pe
orice
sistem
de
operare,
fie
el
Windows,
Linux
sau
OS
ori
Solaris.
Astfel
accentuăm
portabilitatea
de
care
dă
dovadă
acest
limbaj.
Scrierea
unui
cod
confuz
de
multe
ori
rezultă
de
la
supraîncărcarea
operatorilor
ș
i
mo
ș
tenirea
multiplă,
Java
eliminând
astfel
de
caracteristici,
rezultând
într-un
limbaj
avantajos,
ce
poate
fi
definit
prin
simplitate.
Putem
caracteriza
limbajul
Java
ș
i
prin
duritate,
prin
duritate,
în
ț
elegem
eliminarea
pointerilor,
administrarea
automată
a
memoriei,
elementele
ce
nu
se
folosesc
sunt
eliminate
de
un
mecanism,
care
rulează
în
fundal
denumite
“Garbage
collector”,
astfel
posibilele
surse
de
erori
fiind
eliminate.
java
se
mai
poate
defini
ca
un
limbaj
sigur.
Securitatea
din
cardul
limbajului
permite
verificarea
dinamică
a
codului
pentru
a
detecta
secven
ț
ele
periculoase,
impune
unele
regului
stricte
pentru
rularea
proceselor
la
distan
ț
ă,
astfel
se
alcătuie
ș
te
un
mecanism
strict
de
securitate
a
programelor.
Atunci
când
se
rulează
o
aplicatie,
nu
se
depinde
de
arhitectura
fizică
a
ma
ș
inii
pe
care
rulează,
prin
acest
fapt
se
dore
ș
te
a
se
contura
neutralitatea
arhitecturală.
3.1.2 Platforme de lucru Java
După
cum
am
văzut
până
acuma,
limbajul
de
programare
Java
este
unul
complex,
care
a
fost
folosit
pentru
dezvoltarea
unor
tehnologii
care
pot
rezolva
probleme
dintre
cele
mai
diverse.
Astfel
a
venit
ideea
de
a
face
sec
ț
iuni
speciale
pentru
fiecare,
împăr
ț
ite
în
platforme
de
lucru,
care
con
ț
in
librării
ș
i
alte
unitare
complexe
pentru
a
rezolva
unele
cerin
ț
e
ale
utilizatorilor. Avem astfel:
3.1.2.1 J2SE (Java Standard Edition)
J2SE
permite
dezvoltarea
de
aplica
ț
ii
Java
ș
i
rularea
lor
pe
desktop
ș
i
server.
Oferă
bogate
interfe
ț
e
“UI”
(User
Interface),
performan
ț
ă,
versatilitate,
portabilitate
si
securitate.
Platforma
este
oferita
de
Oracel.
Platforma
oferă
ș
i
posibilitatea
de
aplica
ț
ii
standard
sau
appleturi.
Applet
fiind
o
mini
aplica
ț
ie
care
este
de
obieci
unitară.
Este
inclusă
ș
i
tehnologia
Java
Web
Start
care
oferă
o
modalitate
foarte
accesibilă
pentru
lansarea
ș
i
instalarea
locală
a
programelor
Java
direct
de
pe
web,
oferind
o
solu
ț
ie
simplă
pentru
distribu
ț
ia
ș
i
actualizarea
aplica
ț
ilor Java.
3.1.2.2 J2ME (Java Micro Edition)
J2ME
este
platforma
destinata
robustă,
flexibilă
pentru
aplicatiile
care
rulează
pe
un
telefon
sau
pe
dispozitive
embedded:
telefoane
mobile,
boxe,
blu-ray,
discuri,
dispozitive
digitale media, module M2M, printere etc.
3.1.2.3 J2EE (Java Enterprise Edition)
J2EE
este
numele
anterior,
numele
actual
fiind
schimbat
la
Java
EE.
Arhitectura
oferă
servicii
care
simplifică
cele
mai
multe
probleme
pe
care
un
dezvoltator
le-ar
întâlni
atunci
când
construiesc
o
aplicatie
moderna,
în
cele
mai
multe
cazuri
printr-un
API,
astfel
se
facilitează
utilizarea
simplificată
a
popularelor
“design
patterns”
ș
i
best
practices
pentru
insdustrie.
Aceste
API-uri
sunt
complex,
ce
face
dezvoltarea
de
aplica
ț
ii
medii
sau
mari.
Platforma este apar
ț
ine de Oracel si permite crearea de aplicatii server.
3.1.3 JDBC
Java
Database
Connectivity,
sau
pe
scurt
JDBC,
este
o
aplicatie
cu
interfa
ț
ă
programabilă,
sau
API.
Acest
APi
define
ș
te
cum
un
utilizator
poate
accesa
baza
de
date.
JDBC-ul
este
o
tehnologie
bazata
pe
Java,
ce
faciliteaza
conexiunea
la
o
bază
de
date.
Aceasta
tehnologie
face
parte
din
platforma
JSE,
ce
apar
ț
ine
de
Oracle.
Pentru
a
lucra
cu
baza
de date, se folose
ș
te un pa chet numit java sql.
Utilizând
JDBC
este
accesibil
să
transmitem
secven
ț
e
SQL
către
baze
de
date
11
rela
ț
ionale,
nu
trebuie
să
scriem
un
set
de
clase
pentru
fiecare
bază
de
date
accesată.
Având
în
vedere
aceasta
ș
i
faptul
ca
Java
este
un
limbaj
portabil,
putem
observa
un
mare
avantaj
în
ceea ce prive
ș
te utilizarea acestora.
JDBC
oferă
trei
funcționalități:
Reprezinta
un
mediu
de
conectare
între
aplica
ț
ie
ș
i
baza de date. Poate executa secven
ț
e SQL
ș
i să prelucreze date.
Java
este
usor
de
folosit,
fiind
un
limbaj
bun
de
a
dezvolta
o
aplicatie
cu
baza
de
date,
iar
avantajul
de
a
comunica
cu
baza
de
date
ce
vine
cu
JDBC-ul
fac
ca
totul
sa
fie
un
pachet
excelent.
Deoarece
la
baza
Hito
avem
o
bază
de
date
foarte
stufoasă,
conectarea
la
ea
este
importantă, la fel cum este si prelucrarea datelor.
11
Lucrul cu baze de date in Java:
http://upm.ro/intranet/ecalin/cd_educational/cd/javac/cap6.htm
(data
accesării: 30.04.2018)
3.2 Angular 6
Angular,
cunoscut
ș
i
ca
Angular2+
sau
Angular
v2,
este
un
limbaj
bazat
pe
TypeScript.
Este
o
platformă
pentru
aplica
ț
ii
web,
open-source
(sursă
deschisă),
dedicata
pentru
dezvoltarea
de
front-end.Limbajul
a
fost
conceput
de
aceea
ș
i
echipă
din
cadrul
companiei gigant Google, care a dezvoltat precedent AngularJS.
3.2.1 Diferen
ț
ele dintre Angular
ș
i AngularJS
Angular
nu
are
un
concept
de
“domeniu
de
aplicare”
sau
controlere,
în
schimb
folose
ș
te
o
ierarhie
a
componentelor
ca
principală
caracteristică
arhitecturală.
Angular
are
o
sintaxă
diferită
fa
ț
ă
de
alte
tehnologii,
exemplificăm
prin
sintaxa
“{()}”,
unde
“{}”
este
definita
prin
proprietate
de
legate,
iar
“()”
este
reprezentat
de
evenimentul
de
legare.
Modularitatea reprezinta alt avantaj, deoarece multe func
ț
ii de bază s-au mutat în module.
Angular
recomandă
utilizarea
limbajului
TypeScript
dezvoltat
de
Microsoft,
care
introduce
ș
i
el
alte
avantaje,
de
pildă
programarea
bazată
pe
OOP
(Object
Oriented
Programming),
scriere
statică
ș
i
genericitate.TypeScript
este
un
superset
de
ECMAScript
6
(ES6)
ș
i
este
compatibil
cu
ECMAScript
5
(cunoscut
ca
ș
i
JavaScript).
Amintim
faptul
că,
Angular,
se
încarcă
dinamic,
compilează
ș
abloanele
în
mod
asyncron,
înlocuie
ș
te
controalele
ș
i
$scope
(din
AngularJS )
cu
componente
ș
i
directive.
O
componenta
este
o
directivă
cu
un
ș
ablon. Angular se folose
ș
te
ș
i de clase, iar redirec
ț
ionările iterative sunt furnizate de RxJS.
3.2.1.1 Versiunea 2.0.0
Angular
2
a
fost
anun
ț
at
la
conferin
ț
a
ng.Europa
22-23
Octombrie
2014.
Modificările
drastice
ale
versiunii
2.0
a
creat
controversă
în
rândul
dezvoltatorilor.
In
anul
2015,
angular
trece de la alfa la beta, iar primul release a fost în 2016, la 14 septembrie.
3.2.1.2 Versiunea 4.0.0
În
decembrie
2016,
Angular
4
este
oficial
anun
ț
at.
Motivul
pentru
care
versiunea
3.0.0
este
sărită,
îl
reprezinta
faptul
că,
pachetul
“router”
nu
a
fost
aliniat
versiunii,
care
a
fost
deja
distribuita
ca
v3.3.0.
Astfel
lansarea
a
fost
în
data
de
23
martie
2017.
Versiunea
este
compatibilă
cu
Angular
2.
Versiunea
4.0.0,
sufera
o
u
ș
oară
schimbare,
făcându-se
un
update
la
versiunea
4.3,
care
vine
cu
modificări
minore.
Spre
exemplu,
se
introduce
HTTPClient,
un
pachet
mult
mai
puternic
ș
i
u
ș
or
de
folosit
pentru
a
face
solici tări
HTTP.
Se
introduc
noi
cicluri
de
via
ț
ă
ale
routerului
pentru
“Guards”
ș
i
“Resolvers”.
Pentru
evenimente
noi:
GuardsCheckStart,
GuardsCheckEnd,
ResolveStart,,
ResolveEnd,
se
alătură
setului
existent
al evenimentelor din cadrul ciclului de via
ț
ă, cum ar fi NavigationStart.
3.2.1.3 Versiunea 5.0.0
Angular
5
a
fost
lansat
pe
1
noiembrie
2017.
Îmbunătă
ț
irile
majore
în
Angular
5
includ
suport
pentru
aplica
ț
ii
web
progresive,
un
optimizator
de
construc
ț
ie
ș
i
îmbunătă
ț
iri
legate de proiectarea materialelor.
3.2.1.4 Versiunea 6.0.0
Lansata
pe
4
mai
2018.
Aceasta
este
o
versiune
majoră
concentrată
mai
pu
ț
in
asupra
cadrului
care
sta
la
bază
(framework),
ș
i
mai
mult
asupra
lan
ț
ului
de
instrumente
(toolchain)
ș
i
asupra
facilitării
mi
ș
cării
rapide
cu
Angular
în
viitor,
cum
ar
fi:
ng
update,
ng
add,
elemente
angular,
materiale
angular
+
componente
CDK,
componente
de
pornire,
spa
ț
ii
de
lucru
CLI,
suport
pentru
bibliotecă,
furnizorii
de
Shakable
Tree,
îmbunătă
ț
iri
de
performanta
ale animatiilor
ș
i RxJS v6 .
3.2.1.5 Versiuni viitoare
Angular
7
va
apărea
în
septembrie
sau
octombrie
2018.
Fiecare
versiune
este
de
a
ș
tepat
să
fie
înapoi-com patibilă
(backwards
compatible)
cu
eliberarea
prealabilă.
Compania
Google a promis să facă upgrade-uri de doua ori pe an.
Figura 3.2.1
Architecture of an Angular application
Angular
este
caracterizat
si
avantajat,
de
faptul
că
se
poate
folosi
atât
pe
mobil
cât
ș
i
pe
desktop
pentru
dezvoltare,
astfel
se
poate
creea
aplicatii
pe
multiple
platforme.
Angular
reprezinta
viteza
ș
i
perfo rman
ț
ă.
Cu
acest
limbaj
se
poate
construi
rapid
funcționalități
cu
modele
simple,
declarative.
Angular
este
folosit
de
milioane
de
oameni.
Este
un
limbaj
nou,
puternic
ș
i de durată.
Stadiul
dezvoltarii
este
unul
activ,
codul
sursă,
poate
să
fie
găsit
într-un
repository
pe
platforma
GitHub.
Ultima
versiune
stabilă
a
fost
lansată
pe
data
de
3
mai
2018.
În
cadrul
proiectul Hito, Angular 6 a fost folosit pentru a implementa aplica
ț
ia web.
3.2.2 TypeScript
Prin
defini
ț
ie,
TypeScript
este
JavaScript
pentru
dezvoltarea
aplica
ț
iilor.
TypeScript
este
un
limbaj
puternic,
orientat
pe
obiecte
ș
i
limbaj
ce
poate
să
fie
compilat.
Limbajul
a
fost
proiectat
de
Anders
Hejlsberg
(designerul
C#)
la
Microsoft.
TypeScript
este
atât
un
limbaj,
cât
ș
i
un
set
de
instrum ente.
TypeScript
este
un
superset
tastat
de
JavaScript,
compilat
în
limbajul
de
programare
JavaScript.
Putem
spune
că
TypeScript
este
de
fapt
JavaScript
cu
câteva
caracteristici
suplimentare.
TypeScript
include
ș
i
ES6,
care
vine
cu
lambda,
iteratori,
bucle for/of, generatoare de tip Python, reflec
ț
ie.
Figura 3.2.2.1
Structura TypeScript
Enumerăm două dintre caracteristicile TypeScript:
TypeScript este transpilat
TypeScript
este
transpilat
în
JavaScript
la
runtime.
TypeScript
adoptă
blocurile
de
bază
din
JavaScript.
Pentru
a
putea
utiliza
TypeScript,
sunt
necesare
cuno
ș
tin
ț
e
minime
de
JavaScript.
Transpilarea
este
efectuată
în
browser,
iar
TypeScript
este
interpretat
ca
ș
i
JavaScript.
Acest
lucru
este
realizat
pentru
că
browserele
nu
suportă
TypeScript,
ci
doar
HTML,
CSS
ș
i
JavaScript.
TypeScript suportă alte biblioteci JS
Textul
compilat
poate
fi
consumat
din
orice
cod
JavaScript.
TypeScript
poate
reutiliza
toate
framework-urile, instrumentele
ș
i bibliotecile JavaScript existente.
3.2.2.1 TypeScript
ș
i ECMAScript
Specifica
ț
ia
ECM AScript
este
o
specifica
ț
ie
standardizată
a
unui
limbaj
de
scripting.
12
Există
ș
ase
edi
ț
ii
ale
ECMA-262
publicate.
Versiunea
6
a
standardului
este
codificată
"Harmony". TypeScript este aliniat cu specifica
ț
ia ECMAScript6.
12
TypeScript:
https://www.tutorialspoint.com/typescript/typescript_overview.htm
(data accesării:
02.06.2018)
Figura 3.2.2.1
Componentele limbajului TypeScript
TypeScript
adoptă
caracteristicile
de
bază
ale
limbajului
din
specifica
ț
ia
ECMAScript5,
adică
specifica
ț
ia
oficială
pentru
JavaScript.
Caracteristicile
limbajului
TypeScript,
cum
ar
fi
modulele
ș
i
orientarea
bazată
pe
clasă,
sunt
în
conformitate
cu
specifica
ț
ia
EcmaScript
6.
În
plus,
TypeScript
cuprinde,
de
asemenea,
caracteristici
cum
ar
fi
genericitate
ș
i adnotări de tip care nu fac parte din specifica
ț
ia EcmaScript6.
Pentru
a
în
ț
elege
mai
bine
de
ce
TypeScript
constituie
un
avantaj,
putem
afirma
cu
încredere
faptul
ca
acest
limbaj
este
cu
mult
în
fa
ț
a
altor
limbaje
de
acest
gen.
TypeScript
este
cu
mult
superior
fa
ț
ă
de
CoffeeScript
sau
limbajul
de
programare
Dart,
prin
faptul
ca
TypeScript
extinde
JavaScript.
CoffeeScript
sau
Dart
sunt
limbaje
noi
în
sine
care
necesită
un
mediu de execu
ț
ie specifi c limbii. Beneficiul lui TypeScript include:
Compilarea
TypeScript
oferă
func
ț
ia
de
verificare
a
erorilor,
va
compila
codul
ș
i
va
genera
erori
de
compilare
dacă
va
găsi
erori
de
sintaxă.
Acest
lucru
ajută
la
eviden
ț
ierea
erorilor
înainte
ca
scriptul să fie rulat.
Strong Static Typing
Limbajul
vine
cu
o
op
ț
iune
de
“static
typing
and
type
inference
system”
prin
TLS
(TypeScript
Language
Service).
Acest
lucru
constituie
alt
avantaj
al
acestui
limbaj,
spre
exemplu
dacă
o
variabilă
este
declarată
fără
tip,
aceasta
poate
fi
dedus
de
TLS
pe
baza
valorii
sale.
Acceptă defini
ț
ii de tip
Accepta
defini
ț
ii
de
tip
pentru
bibliotecile
JavaScript
existente.
Fi
ș
ierul
DefinitionScript
(cu
extensia
.d.ts
)
oferă
defini
ț
ii
pentru
bibliotecile
JavaScript
externe.
Prin
urmare,
codul
TypeScript poate con
ț
ine aceste biblioteci.
Suportă programarea orientată pe obiecte (OOP)
TypeScript
suportă
concepte
de
programare
orientate
pe
obiecte
,
cum
ar
fi
clase,
interfe
ț
e,
mo
ș
tenire etc.
3.2.3 HTML 5
HTML
este
un
limbaj
de
marcare
folosit
pentru
a
crea
pagini
web.
Acest
pagini
pot
să
fie
afi
ș
ate
într-un
brows er
(navigator).
HTML
este
abrevierea
de
la
“HyperText
Markup
Language”
ș
i
este
folos it
pentru
prezentarea
informa
ț
iilor
(paragrafe,
fonturi,
tabele
etc.)
decât
descrierea
semanticii
documentului.
Extensia
fi
ș
ierelor
este
deductivă,
ș
i
anume
“.html”
ș
i
“.htm”.Limbajul
a
fost
dezvoltat
de
World
Wide
Web
Consortium
&
WHATWG,
iar
tipul
formatului
fiind
un
limbaj
de
marcare.
Limbajul
a
fost
extins
din
SGML,
apoi
extins
în
XHTML.
Amintim
faptul
că
acest
limbaj
de
marcare
urmează
anumite
standarde,
specifice
lui,
ș
i
anume
standardele
ISO/IEC
15445,
W3C
HTML
ș
i
HTML
Living
Standard.
Lansarea
limbajului
a
fost
în
urma
cu
25
de
ani,
în
anu
1993.
Ultima
actualizare
este
pe
data
de
14
decembrie 2017.
HTML5
introduce
un
număr
de
noi
elemente
ș
i
atribute
care
reflectă
utilizarea
tipică
13
a
unui
site
modern.
Unele
dintre
ele
sunt
semantic
înlocuite
cu
utilizări
comune
de
blocuri
generice
<div>
ș
i
de
elem ente
inline
<span>,
de
exemplu
<nav>
–
block
de
navigatie
în
site,
<footer>
–
în
mod
normal
se
referă
la
partea
de
jos
a
unei
pagini
web
sau
la
ultima
linie
de
cod
HTML
sau
<audio>
ș
i
<video>
în
loc
de
<object>.
Unele
elemente
depreciate
din
HTML
4.01
au
fost
ș
terse,
inclu siv
nevinovatul
element
de
prezentare
<font>
ș
i
<center>,
al
căror
efect
este
realizat
cu
CSS
(Cascading
Style
Sheets).
Se
pune
astfel
accent
pe
importan
ț
a
DOM scripting (e.g. JavaScript) în comportamentul web.
HTML5
aduce
scripting-ul
API
(Application
Programming
Interfaces).
Interfa
ț
a
14
existentă
document
object
model
(DOM)
este
extinsă
de
fapt
cu
caracteristici
noi,
documentate. Sunt noi API-uri, cum ar fi:
●
Elementul canvas pentru modul de desen 2D
●
Timed media playback (mod de redare media cronometrat)
●
Offline storage database (offline web applications)
●
Editare de documente
●
Drag-and-drop
●
Mesagerie Cross-document
●
Managementul de istorie a browserului
●
MIME type
ș
i protocolul de manipulare a înregistrărilor
●
Microdata
În
cadrul
proiectului
Hito,
HTML5
a
fost
utilizat
pentru
paginile
din
aplica
ț
ia
client,
împreuna cu alte limbaje dedicate dezvoltării pe web.
3.2.4 SCSS
SCSS
(Syntactically
Cascading
Style
Sheets)
,
cunoscut
ș
i
ca
SASS
(Syntactically
Awesome
Style
Sheets),
este
o
extensie
la
CSS
(Cascading
Style
Sheets).
Pe
scurt,
SCSS
extinde
CSS
cu
multe
concepte
utile,
cum
ar
fi
reguli
sau
mixuri
imbricate,
ș
i
vă
permite
de
asemenea
să
defini
ț
i
variabile
ș
i
să
folosi
ț
i
construc
ț
ii
de
programare
simple
(cu
bucle
for)
în
foile
de
stil
CSS.
Un
compilator
SCSS
transformă
fi
ș
ierele
SCSS
în
CSS
3
pentru
a
le
trimite
către
browser.
SCSS
este
o
implementare
de
notare
CSS
bazată
pe
s
expresie.
Acesta
este
u
ș
or modificat
ș
i extinde implementarea originala a WebIt.
Exemplificăm
avantajul
SCSS
printr-un
exemplu
simplu.
Dacă
avem
fi
ș
iere
CSS
mari
sau
complicate
sau
dacă
se
dore
ș
te
vreodată
ca
ceva
anume
să
fie
modificat,
modificarea
se
face
doar
variabilei
în
cauză
ș
i
nu
peste
tot
în
fi
ș
ier,
spre
exemplu
valori
de
culori
sau
familii
13
HTML5:
https://ro.wikipedia.org/wiki/HTML5
(data accesării: 01.06.2018)
14
HTML5:
https://ro.wikipedia.org/wiki/HTML5
(data accesării: 01.06.2018)
de
fonturi
etc.
Ca
ș
i
sintaxă
SCSS
folose
ș
te
pentru
delimitarea
blocurilor
de
instruc
ț
iuni
“{
}”, pe când SASS nu folose
ș
te astfel de delimitări.
SASS
permite
să
fie
definite
variabile.
Variabilele
încep
cu
semnul
de
dolar
(
$
).
Variabila de atribuire se face cu doua puncte ( : ). SASS Script acceptă patru tipuri de date:
●
Numere (inclusiv unită
ț
i)
●
String-uri (cu sau fără citate)
●
Culori
●
Booleane
Variabilele
pot
să
fie
argumentate
sau
rezultate
din
una
sau
mai
multe
func
ț
ii
disponibile. În timpul transpilării, valorile sunt inserate în documentul CSS de ie
ș
ire.
În
Figura
3.2.2
avem
un
codul
scris
în
stil
SCSS,
cu
delimitarea
blocurilor
de
instruc
ț
iuni.
Figura 3.2.2
SCSS style
În
Figura
3.2.3
avem
codul
în
stil
SASS,
fără
delimitare
a
blocurilor
de
instruc
ț
iuni
prin acolade “{ }”.
Figura 3.2.3
SASS style
Acest
două
variante
au
să
fie
transpilate
în
variantă
de
CSS,
acest
lucru
se
poate
observa
în
Figura 3.2.4.
Figura 3.2.4
compilare în CSS
3.2.5 Bootstrap 4
Bootstrap
este
o
tehnologie
cu
sursă
deschisă
(open-source)
pentru
proiectarea
de
15
site-uri
web
ș
i
aplica
ț
ii
web.
Bootstrap
este
o
librărie
pentru
partea
de
aplica
ț
ii
front-end.
Componentele
Bootstrap
sunt
create
din
CSS
ș
i
JavaScript,
astfel
atunci
când
sunt
folosite,
ele,
sunt
utilizate
în
HTML.
La
utilizarea
unei
componente,
este
încărcat
automat
un
fi
ș
ier
CSS
ș
i
op
ț
ional
librării
JS.
Spre
deosebire
de
multe
cadre
web,
se
referă
numai
la
dezvoltarea
front-end-ului.
Bootstrap,
ini
ț
ial
numit
Twitter
Blueprint,
a
fost
dezvoltat
de
Mark
Otto
ș
i
Jacob
Thornton
la
Twitter
ca
un
cadru
pentru
a
încuraja
coeren
ț
a
între
instrumentele
interne.
Lansarea
lui
Bootstrap
a
fost
pe
data
de
19.
august
2011,
în
urmă
cu
6
ani.
Ultima
actualizare
a
fost
în
data
de
30.
aprilie.
2018,
cu
versiunea
4.1.1.
Bootstrap
a
fost
scris
în
HTML,
CSS,
JavaScript
ș
i pu
ț
in de SASS.
Printre
caracteristicile
de
bază
ale
lui
Bootstrap
putem
aminti
următoarele:
Bootstrap
3
acceptă
cele
mai
recente
versiuni
ale
browserului
Google
Chrome
,
Firefox
,
Internet
Explorer
,
Opera
ș
i
Safar i
(cu
excep
ț
ia
Windows).
Suportă
în
plus
la
IE8
ș
i
la
ultima
versiune
de
suport
extins
pentru
Firefox
(ESR).
Încă
de
la
2.0,
Bootstrap
suportă
designul
web
receptiv.
Aceasta
înseamnă
că
aspectul
paginilor
web
se
ajustează
dinamic,
ț
inând
cont
de
caracteristicile
dispozitivului
utilizat
(desktop,
tabletă,
telefon
mobil).
Începând
cu
versiunea
3.0,
Bootstrap
a
adoptat
o
filosofie
de
proiectare
mobilă
,
subliniind
în
mod
implicit
designul
receptiv. Versiunea 4.0 alpha a adăugat suportul Sass
ș
i flexbox .
Începând
cu
Bootstrap
4,
Sass
este
folosit
în
loc
de
Less
pentru
foile
de
stil.
Fiecare
componentă
Bootstrap
constă
din
declara
ț
ii
CSS
ș
i,
în
unele
cazuri,
ș
i
cod
JavaScript.
Enumerăm faptul că Bootstrap are:
15
Bootstrap:
https://en.wikipedia.org/wiki/Bootstrap_(front-end_framework)
(data accesării:
02.06.2018)
●
Stiluri
Bootstrap
oferă
un
set
de
foi
de
stil
care
oferă
defini
ț
ii
de
stil
de
bază
pentru
toate
componentele
HTML
cheie.
Acestea
oferă
un
aspect
uniform
ș
i
modern
pentru
formatarea
textului, a tabelelor
ș
i a elementelor de formă.
●
Componente reutilizabile
În
plus
fa
ț
ă
de
elemente le
HTML
obi
ș
nuite,
Bootstrap
con
ț
ine
ș
i
alte
elemente
de
interfa
ț
ă
utilizate
în
mod
obi
ș
nuit.
Componentele
sunt
implementate
ca
ș
i
clase
CSS,
care
trebuie
aplicate anumitor elemente HTML dintr-o pagină.
●
Componente JavaScript
Bootstrap
vine
cu
mai
multe
componente
JavaScript
sub
formă
de
pluginuri
jQuery.
Acestea
oferă
elemente
suplimentare
de
interfa
ț
ă
pentru
utilizator,
cum
ar
fi
casetele
de
dialog,
butoanele
ș
i
carus ele.
Ele
extind,
de
asemenea,
func
ț
ionalitatea
anumitor
elemente
de
interfa
ț
ă
existente,
inclus iv,
de
exemplu,
o
func
ț
ie
de
auto-completare
pentru
câmpurile
de
intrare.
În
versiunea
1.3
,
sunt
acceptate
următoarele
pluginuri
JavaScript:
modal,
dropdown,
scrollspy, tab, tooltip, popover, alertă, buton, restrângere, carusel
ș
i typeahead.
3.2.5 ng-Bootstrap
Ng-Bootstrap
(Angular
Bootstrap)
este
un
set
de
componente
ș
i
directive
care
16
împachetează
cea
mai
recentă
versiune
de
Bootstrap
(v4.1.1).
Acest
lucru
facilitează
utilizarea
aplica
ț
iei
Bootstrap
în
aplica
ț
iile
Angular.
Singure le
dependen
ț
e
cerute
sunt:
Angular
5+
este
necesar
pentru
a
putea
utiliza
ng-bootstrap
ș
i
Bootstrap
CSS
de
la
versiunea
4.0.0
în
sus.
Ng-Bootstrap
depinde
de
CSS-ul
Bootstrap,
dar
nu
necesită
dependin
ț
e
Bootstrap
JS
ș
i
jQuery.
Prin
urmare
bootstrap.js
sau
bootstrap.min.js,
nu
sunt
necesare
pentru
buna
func
ț
ionare
a
unui
proiect.
Obiectivul
ng-bootstrap
este
de
a
înlocui
complet
implementarea
JavaScript
pentru
componente.
Nu
trebuie
incluse
nici
dependin
ț
e
cum
ar
fi
propper.js.
Acestea
nu
sunt
necesare
ș
i
ar
putea
interfera
cu
codul
ng-bootstrap.
Ng-Bootstrap
este
suportat
de
către
browsere,
iar
echipa
din
spatele
tehnologiei
lucrează
pentru
a
păstra
ng-bootstrap
la
acelea
ș
i
versiuni
suportate
de
Bootstrap
4
ș
i
Angular.
Ace
ș
ti
factori
face
din
această
tehnologie
un
aliat
puternic
pentru
dezvoltarea
de
aplica
ț
ii
sau
de
site-uri
web.
Codul
este testat automat pe toate browserele acceptate.
Ng-Bootstrap
de
ț
ine
componente
deja
create,
prin
folosirea
de
ș
abloane,
iar
prin
asta
se
pot
customiza
după
preferin
ț
e
ș
i
nevoi.
Printre
aceste
compon ente
se
numără:
Accordion,
Alert,
Buttons,
Carousel,
Datepicker,
Dropdown,
Modal,
Pagination,
Popover,
Progressbar,
Rating,
Tabs,
Timepicker,
Tooltip,
Typeahead.
Tehnologia
include
ș
i
API-uri.
Spre
exemplu
avem:
NgbAccordion,
NgbPanel,
NgbPanelTitle,
NgbPanelContent,
NgbPanelChangeEvent,
NgbAccordionConfig.
Avantajul
acestei
librării,
este
că
elimină
dependin
ț
e
jQuery
sau
JavaScript,
folosind
componente
ș
ablon fără a ceste dependin
ț
e.
16
ng-bootstrap:
https://alligator.io/angular/ng-bootstrap/
(data accesării: 02.06.2018)
3.3 MySQL
Baza
de
date
reprezinta
un
domeniu
fără
de
care
un
serviciu
ce
se
respecta
nu
poate
să
existe.
Astfel
baza
de
date
reprezintă
o
parte
din
creierul
unei
serviciu,
sau
a
unei
aplica
ț
ii,
fără
de
care
informa
ț
ia
nu
poate
să
fie
stocată.
Procesata
sau
nu
informa
ț
ia,
la
închiderea
aplica
ț
iei/serviciului,
sau
atunci
când
este
nevoie
să
fie
procesată
altă
informa
ț
ie,
ceea
ce
a
fost
precedent
se
pierde,
deoarece
nu
există
spațiu
de
stocare.
Putem
astfel
spune
că
baza
de
date
este
un
instrument
fundamental
pentru
organizarea
informa
ț
iei.
Conceptul
a
plecat
de
la
dorința
de
a
putea
stoca
informa
ț
ie
vastă,
într-un
mediu
controlat,
organizat,
care
facilitează
căutarea
ș
i regăsirea rapid ă prin intermediul calculatorului.
Pentru
organizare,
bazele
de
date
folosesc
tabele.
Informa
ț
ia
fiind
reprezentată
sub
forma
lor.
Tabelul
este
un
obiect,
iar
proprietă
ț
ile
obiectului
sunt
reprezentate
prin
coloanele
tabelului.
Ca
ș
i
alte
platfo rme,
bazele
de
date
pot
sa
fie
stocate
sub
diferite
forme;
avem
astfel
stocare
offline
ș
i
online,
putând
fiind
accesate
prin
re
ț
ele
locale,
remote
(distan
ț
ă)
sau
prin
Internet. Calitatea unei baze de date este dată de patru criterii definitorii:
1.
volumul de informa
ț
ie
ș
i domeniul de interes ce se dore
ș
te a fi acoperit;
2.
facilitățile de interogare;
3.
timpul de access;
4.
grafica ecranului;
MySQL
este
cel
mai
popular
SGBD
open-source,
fiind
o
componentă
cheie
a
stivei
17
LAMP
(Linux,
Apache,
MySQL,
PHP).
Produs
de
compania
MySQL
AB
ș
i
distribuit
sub
Licen
ț
a
Publică
Genera lă
GNU,
MySQL
este
un
sistem
de
gestiune
a
bazelor
de
date
relationale.
Limbajul
de
programare
PHP
folose
ș
te
cel
mai
mult
acest
SGBD,
însă
poate
fi
folosit de orice limbaj de programare major.
Administrarea
unei
baze
de
date
MySQL
se
poate
realiza
prin
linia
de
comanda
sau
se
poate
descărca
de
pe
internet
MySQL
Workbench
care
permite
prin
interfe
ț
e
grafice
utilizarea
structurii
de
tabele,
astfel
imaginea
de
ansamblu
fiind
mult
mai
clară,
accesibila
ș
i
intuitivă
considerat
un
avantaj
în
defavoarea
administrării
de
la
linia
de
comandă
(de
ș
i
acest
lucru nu este valabil întotdeauna).
Respectarea celor patru forme de normalizare este de prim ordin
:
18
●
Prima
formă
:
Într-o
bază
de
date
rela
ț
ională,
entitățile
diferite
trebuie
stocate
în
tabele
diferite.
Nimic
nu
trebuie
sa
fie
aleator
în
organizarea
bazei
de
date.
Fiecare
entitate
trebuie
pusă
la
locul
ei.
Recomandat
este
ca
pentru
fiecare
entitate să se creeze un tabel separat.
●
A
doua
formă
:
A
doua
formă
de
normalizare
presupune
că
pentru
fiecare
rând
sau înregistrare într-un tabel, trebuie să existe un identificator unic, un index.
●
A
treia
formă
:
O
tabelă
este
în
a
treia
formă
de
normalizare
dacă
și
numai
dacă
se
găsește
în
a
doua
formă
de
normalizare
și,
în
plus,
câmpurile
care
nu
17
MySQL:
https://ro.wikipedia.org/wiki/MySQL
(data accesării: 12:05.2018)
18
Tutoriale SQL:
http://www.techit.ro/tutorial_sql2.php
(data accesării: 12.05.2018)
sunt
chei
primare
sunt
independente
unul
de
altul,
în
sensul
că
nici
un
câmp
să
nu
să
fie
obținut
prin
aplicarea
unei
funcții
asupra
valorii
altor
câmpuri
(câmpurile
care
nu
sunt
chei
primare
sunt
independente
între
ele
și
depind
numai de cheia primară).
3.4 Hibernate framework
În
linii
mari
,
pentru
servicii
medii
sau
mari,
informa
ț
ia
automat
devine
una
voluminoasă,
iar
o
bază
de
date
este
o
necesitate,
care
nu
tine
loc
de
discu
ț
ie.
Deoarece
informatia
în
procente
foarte
mari,
este
reutilizată,
stocarea
ei
în
tabele,
ajuta
la
o
gestiune
mai
bună.Tabelele
din
baza
de
date
con
ț
in
coloane
pentru
a
structura
informa
ț
ia.
Baza
de
date
în
sinea
ei
este
independenta
de
aplica
ț
ie,
iar
pentru
a
se
face
conexiunea
între
cele
două,
este
folosit
un
conector,
apoi
prin
acest
conector,
aplica
ț
ia
poate
face
cereri
către
baza
de
date.
Informa
ț
ia se cite
ș
te coloana cu coloană, totul fiind salvat într-un obiect, transim serviciului.
Diferen
ț
a
dintre
reprezentarea
datelor
în
baza
de
date
ș
i
modelarea
lor
în
obiecte
poate
cauza
diverse
erori
atunci
când
se
lucrează
cu
un
software
orientat
pe
obiect
ș
i
cu
baze
de
date rela
ț
ionale.
Hibernate
este
o
biblioteca
ORM
(Object-Relational
Mapping)
pentru
limbajul
Java,
19
utilă
pentru
maparea
modelului
orientat
pe
obiecte
peste
bazele
de
date
relationale.
Principalul
atu
al
acestei
librării
este
faptul
că
oferă
o
solu
ț
ie
rapida,
de
înaltă
performan
ț
ă,
independentă de tipul bazei de date folosite pentru modelarea obiectelor unei baze rela
ț
ionale.
Această
tehnologie
este
gratuită
ș
i
open
source
(sursă
deschisă),
distribuită
sub
licen
ț
a
GNU
Lesser
General
Public
License.
Principala
caracteristica
a
Hibernate
este
maparea
între
clasele
Java
ș
i
tabelele
bazelor
de
date
precum
ș
i
între
tipurile
de
date
Java
ș
i
SQL.
Hibernate
pune la dispozitie posibilitatea redactarii de query-uri si data-retrieval.
Pentru
maparea
claselor
Java
pe
tabele
dintr-o
baza
de
date
relațională,
este
folosit
un
fi
ș
ier
XML
(Extensible
Markup
Language)
sau
prin
adnotări
Java.
Men
ț
ionăm
faptul
că
nu
se
poate
folosi
ambele
variante,
ci
se
alege
una
dintre
acestea.
În
cazul
în
care
se
folose
ș
te
configurare
XML,
Hibernate
poate
genera
un
schelete
de
cod
pentru
clasele
presistente.
În
cazul
adnotărilor
Java
acest
lucru
nu
este
necesar.
HIbernate
este
capabil
să
folosească
oricare
dintre
cele
două
variante
prezentate
pentru
a
men
ț
ine
scheme
unei
baze
de
date.
Tehnologia
Hibernate
oferă
posibilitatea
de
a
realiza
rela
ț
ii
one-to-one
(unu-la-unu)
sau
many-to-many
(mul
ț
i-la-mul
ț
i).
Realizarea
de
asocieri
reflexive
între
un
obiect
ș
i
mai
multe
instance,
prin
rela
ț
ie de tip unu-la-mul
ț
i (one-to-many).
Hibernate
oferă
ș
i
suportă
pentru
POJOs
(Plain
Old
Java
Objects).
Conven
ț
ia
de
nume
pentru
clasele
POJO
este
JavaBeans
pentru
getter
ș
i
setter,
iar
pentru
câmpurile
interne
se
recomandă
să
aibă
modificator
de
acces
privat.
Una
dintre
cerin
ț
ele
pentru
a
o
clasă
să
fie
persistentă,
este
dată
de
existen
ț
a
constructorului
din
oficiu
(default)
fără
argument,
Hibernate
se
va
folosi
de
acesta
pentru
a
crea
obiecte
utilizând
Java
Reflection.
Constructorul
are
posibilitatea
de
a
fi
private,
dar
pachetul
său,
vizibilitatea
trebuie
să
permită
generarea
de
19
Hibernate framework:
http://elf.cs.pub.ro/idp/laboratoare/lab-08
(data accesării: 12:05:2018)
proxy-uri
la
runtime
si
de
asemenea
accesarea
datelor
fără
folosirea
de
metode
de
bytecode
instrumentation.
Colec
ț
iile
de
date
sunt
stocate
în
obiecte
Java,
spre
exemplu
putem
aminti
de
Set
ș
i
List.
În
Java
5
sunt
introduse
genericele
care
sunt
suportate
de
Hibernate.
Începând
cu
Hibernate 3 se folosesc metode de generare lazy a colec
ț
iilor.
Pentru
obiectele
înrudite
se
pot
configura
opera
ț
ii
în
cascada
de
la
unul
la
altul.
De
20
exemplu,
un
obiect
de
tip
Album
poate
fi
configurat
ca
opera
ț
iile
de
save
ș
i/sau
delete
aplicate pe această clasă să se apeleze în cascada pe obiectele copil de tip Track.
Figura 3.4.1
Persistarea obiectelor în baza de date
În
Figura
3.4.1
avem
reprezentat
în
cod
Java
,
implementarea
unui
obiect
ce
are
mai
multe
proprietă
ț
i,
de
tip
client.
Fiecare
utilizator
pe
lângă
“nume”,
“parolă”,
ș
i
alte
date
din
tabele
“user”,
acesta
are
reprezentat
în
tabela
“employee”
alte
date
cu
caracter
individual.
“Employee”
este
tot
un
obiect,
care
de
ț
ine
proprietă
ț
i,
ce
sunt
legate
de
un
anumit
utilizator.
Aceste
doua
tabele,
“user”
ș
i
“employee”
sunt
legate
între
ele,
print-ro
legătură
one-to-one.
Prin
genericitate,
un
employee
de
ț
ine
un
user.
Folosind
adnotarea
“@Table”,
este
specificat
faptul
că,
în
baza
de
date
există
un
tabel
cu
acela
ș
i
nume
ca
ș
i
numele
dat
clasei
Java.
În
caz
contrar,
dacă
numele
dat
clasei
Java
nu
este
corespunde
cu
numele
dat
tabelei
din
baza
de
date, este folosită adnotarea “@Table(name =”numele dat tabelei)”
.
20
Despre Hibernate:
https://www.todaysoftmag.ro/article/73/analiza-mecanismului-object-relational-mapping-orm-cu-exem
plificari-hibernate
(data accesării: 12.05.2018)
3.5 Spring framework
Pentru
a
simplifica
codul
aplicatiilor
scrise
în
limbajul
de
programare
Java,
se
utilizează
platforma
Spring.
Spring
poate
să
fie
folosit
în
orice
serviciu
bazat
pe
Java.
Folosit
în
mare
parte
pentru
platforma
Java
EE,
este
considerat
mult
mai
eficient
pentru
modelul
Enterprise Java Beans (EJB).
Serviciile
Enterprise
se
folosesc
de
acest
framework
pentru
a
putea
folosi
obiecte
standard
ale
limbajului
Java
(POJO).
Se
elimină
necesitatea
unui
produs
care
să
sus
ț
ină
EJB-ul,
cum
este
un
server
de
aplica
ț
ii
(application
server),
folosindu-se
doar
containere
de
servle
ț
i cum este Tomcat , ceea ce aduce un plus de mobilitate.
Ca
ș
i
structura,
Spring
se
folose
ș
te
de
un
număr
însemnat
de
module.
Avantajul
consta
în
faptul
că
utilizatorul
folose
ș
te
doar
funcționalitățile
dorite,
nefiind
afectate
de
restul.
Un
serviciu,
este
testat
mult
mai
u
ș
or
dacă
acesta
este
scris
cu
ajutorul
Spring,
acest
framework
con
ț
ine
unele
avantaje
care
fac
ca
procesul
să
fie
simplificat.
Dependin
ț
ele
sunt
usor injectabile pentru că se folose
ș
te obiecte java în containere de tip Bean.
Spring
framework
este
gândit
pentru
crearea
de
aplicatii
web,
numit
ș
i
Spring
Web
MVC
(Model-View-Controller),
venind
cu
avantaje
în
compara
ț
ie
cu
alte
framework-uri
de
acest
gen,
cum
este
Struts,
restlet,
Dropwizard
etc.
Totodată
Spring
oferă
o
interpretare
a
erorilor
tehnice
în
excep
ț
ii
consistente,
u
ș
or
de
înțeles
ș
i
bine
structurate.
Erori
ce
pot
surveni
de la JDBC, HIbernate, etc.
Din
func
ț
iile
specifice
fac
parte
IOC
(Inversion
of
Control)
ș
i
DI
(Dependency
21
Injection).
IOC
este
o
tehnică
ce
ț
ine
strict
de
programarea
orientată
pe
obiecte,
în
care
crearea
obiectelor
se
face
la
execu
ț
ia
aplica
ț
iei
de
către
un
obiect
de
asamblare.
În
programarea
orientată
obiect
sunt
câteva
tehnici
pentru
a
implementa
inversarea
controlului,
ce-a
mai
utilizată
fiind
injectarea
dependin
ț
elor.
Cand
se
scriu
aplica
ț
ii
Java
complexe,
clasele
trebuie
sa
fie
cat
mai
independente
pentru
a
putea
fi
reutilizate
ș
i
pentru
a
putea
fi
testate independent.
Caracteristicile de bază al acestui framework sunt:
22
●
Tehnologii
de
bază:
injec
ț
ia
de
dependin
ț
e,
evenime nte,
resurse,
i18n,
validări,
legare de date, conversie de tip, SpEL, AOP
●
Testare:
obiecte mock, TestContext framweork, Spring MVC Test, WebTestClient
●
Accesul la date:
tranzac
ț
ii, suport DAO, JDBC, ORM, XML
●
Integrare:
remoting,
JMS,
JCA,
JML,
e-mail,
tasks
(sarcini),
scheduling
(programări), cache
●
Limbi:
Kotlin, Groovy, limbaje dinamice
Cerin
ț
ele minime pentru functionare sunt date pentru fiecare versiune de Spring. Astfel avem:
●
JDK 8+ pentru Spring Framework 5.x
21
Spring Framework Overview:
https://docs.spring.io/spring/docs/current/spring-framework-reference/overview.html
(data accesării:
13.05.2018 )
22
Spring Framework:
https://projects.spring.io/spring-framework/
(data accesării: 13.05.2018)
●
JDK 6+ pentru Spring Framework 4.x
●
JDK 5+ pentru Spring Framework 3.x
3.6 Maven
Maven
este
un
produs
de
build
ș
i
management
al
proiectelor,
scris
în
limbaju
Java.
Acesta
este
sub
licen
ț
a
celor
de
la
Apache
Software
Foundation.
Acest
soft
este
pentru
gestionarea
proiectelor
software.
Func
ț
ionalită
ț
ile
sale
principal e
sunt
descrierea
procesului
de
build
al
softwareului,
cât
ș
i
descrierea
dependințelor
acestuia.
Conceptul
ce
stă
la
baza
lui
este
acela
de
POM
(Project
Object
Model).
POM-ul
stă
la
baza
acestui
software,
care
de
fapt
este
un
fi
ș
ier
de
tip
XML,
ce
con
ț
ine
configurarea
folosită
pentru
construirea
proiectului.
Fi
ș
ierul
XML
descrie
proiectul
care
urmează
să
fie
build-uit,
dependin
ț
ele
acestuia
sau
ale
modulelor
ș
i
componente lor
de
care
depinde,
ordinea
în
care
se
execută
build-ul,
directoarele
ș
i
plug-in-urile
necesare.
Maven
descarcă
dinamic
bibliotecile
Java,
din
unul
sau
mai
multe
repository-uri.
Fără
îndoială
că
Maven
este
unul
dintre
cele
mai
cunoscute
builder-e,
singur
competitor
al
său
este
Ant,
care
este
tot
un
software
al
celor
de
la
Apache.
Avantajul
Maven
consta
în
faptul
că
acest
software,
pe
lângă
faptul
că
este
orientat
spre
procesare,
compilare
ș
i
împachetare,
testare
ș
i
distribuire,
ș
i
capacitatea
de
a
face
build,
fa
ț
ă
de
Ant,
el
poate
si
rula
ș
i
genera rapoarte sau posibilitatea de a oferi comunicarea între membrii unei echipe de lucru.
Caracterizat
ca
o
modalitate
de
a
gestiona
proiectele
software,
dela
care
vine
si
denumirea
de
“project
management
tool”,
Maven
poate
să
ofere
facilitatea
de
a
dezvolta
aplica
ț
ii
mari,
la
care
contribuie
mai
multe
persoane
(echipe),
care
pot
folosi
păr
ț
i
din
alte
proiecte
de
software,
si
care
pot
genera
rapoarte
ș
i
site-uri
Web.
Versiunea
curentă,
a
ajuns
la
varianta stabilă 3.5.3, lansata în data de 8 martie 2018, la bază fiind tot un XML.
Folosit
în
cadrul
aplica
ț
iei
de
server,
Maven
este
utilizat
pentru
crearea
structurii
proiectului.
Structura
este
întemeiată
pe
module
Maven,
care
sunt
independente,
singura
legătură
între
ele
este
de
a
înoda
dependin
ț
ele
între
ele.
De
asemenea
este
folosit
pentru
adăugarea
dependin
ț
elor
externe,
cum
ar
fi
sistemul
de
logare
a
erorilor
“Log4j”
sau
sistemul
de
testare
a
codului
“JUnit”.
Jos
putem
observa
structura
de
directoare,
creată
autonom
de
Maven, pentru un proiect Java.
Figura 3.6.1
Maven auto-generated directory structure
3.7 Servicii REST
Serviciul
REST
(Representational
State
Transfer)
este
un
stil
arhitectural
care
define
ș
te
un
set
de
const rângeri
ș
i
proprietă
ț
i
bazate
pe
HTTP.
Serviciul
Web
este
aplica
ț
ia
software
care
este
accesibilă
pe
Internet,
astfel
accesând
un
astfel
de
serviciu
de
fapt,
se
accesează
o
adresă
URL,
accesibilă
prin
protocolul
HTTP.
Serviciile
Web
care
respectă
23
stilul
arhitectural
REST
sau
cele
mai
performante
servicii
web
asigură
interoperabilitatea
între
sistemele
informatice
de
pe
Internet
.
Serviciile
web
compatibile
cu
REST
permit
sistemelor
solicitante
să
acceseze
ș
i
să
manipuleze
reprezentările
textuale
ale
resurselor
web
utilizând
un
set
uniform
ș
i
predefinit
de
opera
ț
iuni
fără
stat
.
Alte
tipuri
de
servicii
web,
cum
ar
fi
serviciile
web
SOAP
,
expun
propriile
seturi
de
opera
ț
ii
arbitrare.
REST
nu
reprezinta
o
tehnologie
nouă,
ci
diferita
lui
utilizare
îl
oferă
avantajul.
REST
este
un
mod
de
a
folosi
comenzile HTTP ca API pentru aplicatia client.
Serviciul
REST
consideră
datele
ș
i
opera
ț
iile
oferite
ca
ș
i
resurse,
accesibile
prin
URL.
(Uniform
Resource
Identifiers).
Protocolul
HTTP
este
folosit
pentru
a
schimba
resurse
între
clien
ț
i
ș
i
server
printr-o
interfa
ț
ă
standard
ș
i
protocolul
de
transfer.
Resursele
unei
aplica
ț
ii
au
adresa
de
forma:
http://host/
<appcontext>/resources.
Ca
ș
i
exemplu
putem
da
adresa:
http://localhost:8080/hito-server/rest/login
.
Dintre
toate,
cele
mai
multe
se
folosesc
de
următoarele
patru
metode
HTTP
pentru
definirea
serviciilor
RESTful:
GET,
POST,
PUT,
DELETE.
Exista
ș
i
metodele
HEAD
ș
i
OPTIONS
însă
acestea
sunt
folosite
mai
pu
ț
in.
GET
face
citirea
unei
resurse,
fără
a
o
23
REST:
https://en.wikipedia.org/wiki/Representational_state_transfer
(data accesării: 19.05.2018)
modifica,
opera
ț
ia
nu
se
utilizează
pentru
crearea
de
resurse.
POST
folose
ș
te
upload-ul
unei
noi
resurse,
de
a
crea
sau
de
a
modifica,
execu
ț
iile
repetate
pot
avea
însă
efecte
distincte.
Pentru
a
crea
o
noua
resursă,
iar
execu
ț
iile
repetate
să
aibă
ca
ș
i
efect
o
singura
execu
ț
ie,
se
utilizează
metoda
PUT.
DELETE,
după
cum
specifică
ș
i
numele
are
rolul
de
a
realiza
ș
tergerea unei resurse, iar execu
ț
ia repetată având acela
ș
i efect ca una singură.
Conceptul
de
REST
a
fost
introdus
pentru
prima
dată
în
2000,
de
Roy
Fielding.
În
24
continuare sunt câteva aspecte importante legate de REST.
Este
un
stil
architectural
simplu
bazat
pe
standarde
Web
ș
i
HTTP
(câ
ș
tigând
teren
în
fa
ț
a
unor
model
e
ca
ș
i
SOAP).
Tratarea
erorilor
se
face
conform
tratării
erorilor
în
protocolului
HTTP.
Este
o
arhitectură
scalabilă
datorită
separării
de
responsabilită
ț
i
între
client
ș
i
server.
De
exemplu,
responsabilitatea
unui
client
este
să
men
ț
ină
starea
unui
utilizator,
în
timp
ce
serverul
nu
men
ț
ine
nici
o
stare,
dar
este
resposabil
de
managementul
datelor.
De
asemenea
între
request-uri
serverul
nu
trebuie
să
se
men
ț
ină
starea
clientului
(stateless).
Clien
ț
ii
pot
folosi
tehnici
de
caching
pentru
cre
ș
trea
performan
ț
ei
ș
i
scalabilită
ț
ii
unei
solu
ț
iei.
Partea
de
server
poate
să
con
ț
ină
mai
multe
nivele,
fără
ca
modificări
ale
acestora
să
afecteze
în
vreun
fel
clien
ț
ii.
Aceasta
abordare
ar
putea
duce
la
o
separare
de
responsabilități
a
diferitelor
nivele,
ca
de
exemplu:
load
balancing,
securitate,
stocarea
datelor,
caching
de
resurse.
Resursele
pot
avea
diferite
reprezentări
(JSON,
XML,
definit
de
user,
etc),
folosirea
lor
determinându-se
conform
protocolului
HTTP
(de
exemplu
folosind
HTTP Headers).
În
Java,
suportul
pentru
servicii
RESTful
se
nume
ș
te
Java
API
for
Restful
Web
Services
(JAX-RS)
ș
i
este
definit
de
JSR
311.
JAX-RS
se
bazează
foarte
multe
pe
adnotări.
Jersey este o implementare open source a JAX-RS.
24
Servicii REST:
https://www.todaysoftmag.com/article/81/restful-web-services-folosind-jersey
(data
accesării: 19.05.2018)
Figura 3.7.1
Arhitectura REST
25
De
fiecare
dată
când
este
transmisă
o
cerere
(request)
către
server
pentru
accesarea
unui
URL,
serverul
trimite
un
cod
drept
răspuns
la
cererea
făcută.
Există
mai
multe
tipuri
de
coduri
generate
în
func
ț
ie
de
execu
ț
ia
cererii,
acestea
fiind
form ate
din
3
cifre,
prima
cifră
fiind
în
intervalul
(1-5),
de
forma
1xx
sau
2xx,
etc..
Codurile
care
încep
cu
1xx
sunt
coduri
de
informare
“cerere
inregistrata”,
“se
continuă
procesul”,
etc.
2xx
sunt
coduri
de
confirmare
a
succesului
ac
ț
iunii:
“Cer erea
a
fost
primită,
în
ț
eleasă,
acceptată
ș
i
îndeplinită
cu
succes”.
Răspunsul
de
forma
3xx
este
un
cod
de
redirectionare,
utilizatorul
trebuie
să
îndeplinească
criterii
suplimentare
pentru
îndeplinirea
cererii.
Codul
de
forma
4xx
este
pentru
erorile
provenite
de
la
clien
ț
i,
cele
mai
cunoscute
coduri
întâlnite
de
către
utilizatorii
internetului,
codurile
de
tipul
4xx
arată
că
utilizatorul
a
întâmpinat
o
problemă.
În
cele
din
urma,
răspunsurile de forma 5xx au ca
ș
i sursă o problemă cauzată de server.
Un
exemplu
de
request
se
poate
vedea
în
Figura
3.7.1
unde
un
client
trimite
unui
server
prin
intermediul
HTTP
un
request
de
tip
GET.
Se
poate
observa
că
între
client
ș
i
resurse
este
serverul,
find
singurul
care
are
acces
direct
la
resurse.
Răspunsul
primit
de
la
server
are
codul
200,
asta
înseamnă
că
cererea
a
fost
procesată
cu
succes,
iar
formatul
răspunsului sau formatul in care au fost returnate resurse este de tip XML.
25
Creating a simple REST:
https://shareurcodes.com/blog/creating%20a%20simple%20rest%20api%20in%20php
(data
accesării: 10.05.2018)
Figura 3.7.2
Request serviciu REST
26
3.7.1
Jersey framework
Jersey
RESTful
Web
Services
framework
este
un
cadru
open
source
pentru
27
dezvoltarea
serviciilor
Web
RESTful
în
Java.
Oferă
suport
pentru
API
–
urile
JAX-RS
ș
i
serve
ș
te
drept
implement are
de
referin
ț
ă
JAX-RS
(JSR
311
&
JSR
339).
Acest
framework
a
fost
dezvoltat
de
către
Oracle,
ultima
versiune
stabilă
fiind
lansata
la
data
de
septembrie
2017.
Jersey
framework
este
un
sistem
cross-platform
pentru
OS-uri.
Fiind
un
framework
dedicat
pentru
java,
acesta
este
disponibil
pentru
Java
6
sau
alte
versiuni
mai
mari.
Acesta
vine sub licen
ț
a CDDL ve rsiunea 1.1
ș
i GPL v2.
Jersey
framework
este
mai
mult
decât
implementarea
referin
ț
elor
JAX-RS.
Jersey
28
oferă
propriul
API
care
extinde
setul
de
instrumente
JAX-RS
cu
func
ț
ii
suplimentare
ș
i
utilitare
pentru
a
simplifica
în
continuare
serviciile
RESTful
ș
i
dezvoltarea
clientului.
Jersey
expune,
de
asemenea,
numeroase
SPI-uri
de
extensie,
astfel
încât
dezvoltatorii
să
extindă
Jersey pentru a se potrivi cel mai bine nevoilor lor.
3.7.2
Restlet
Restlet
poate
crea
vizual
ș
i
execut
cereri
API
unice,
precum
ș
i
scenarii
complexe.
29
Permite
automatizarea
executării
testelor
ș
i
a
scenariilor
API-ului
cu
pluginul
CI
/
CD.
Clientul
Restlet
este
cel
mai
popular
client
REST
disponibil
ca
extensie
Chrome.
Se
actualizează
în
mod
automat,
poate
fi
deschis
în
una
sau
mai
multe
file
ale
browserului
ș
i
are
o
pictogramă
convenabilă
pentru
bara
de
instrumente.
Prin
aceasta
extensie
Chrome,
a
fost
26
RESTful Java:
https://crunchify.com/how-to-create-restful-java-client-with-jersey-client-example/
(data accesării: 19.05.2018)
27
Jersey:
https://en.wikipedia.org/wiki/Project_Jersey
(data accesării: 10.06.2018)
28
Jersey framework:
https://jersey.github.io/
(data accesării: 10.06.2018)
29
Restlet:
https://restlet.com/modules/client/
(data accesării: 10.06.2018)
testat
constant
aplica
ț
ia
server,
cât
ș
i
aplica
ț
ia
client,
pentru
a
testa
în
principiu
func
ț
ionalitatea
de
auten tificare
ș
i
pentru
a
verifica
dacă
reque st-urile
HTTP
func
ț
ionează
corect.
Prin
asta
se
poate
verifica
ș
i
dacă
cele
doua
aplica
ț
ii
func
ț
ionează
corect
una
cu
cealaltă.
Un
alt
avantaj
este
faptul
că,
în
caz
de
erori,
se
poate
identifica
mult
mai
u
ș
or
dacă
eroarea este din aplica
ț
ia client sau server.
3.8 Criptografie
Criptografia
reprezintă
o
ramură
a
matematicii
care
se
ocupă
cu
securizarea
30
informa
ț
iei
ș
i
cu
autentificarea
ș
i
restric
ț
ionarea
accesului
într-un
sistem
informatic.
Termenul
criptografie
este
compus
din
cuvintele
de
origine
greacă
kryptós
(ascuns)
ș
i
gráfein
(a
scrie).
Scopul
criptografiei
este
de
a
proteja
informa
ț
iile
transmise
fără
să
poată
fi
citite
ș
i
în
ț
elese decât de către per soanele cărora le sunt adresate.
Originea
criptografiei
provine
încă
din
antichitate,
astfel
putem
afirma
că
ea
este
o
ș
tiin
ț
ă
veche,
născută
din
necesitate,
scopul
(atunci
dar
ș
i
în
prezent)
este
de
a
codifica
informa
ț
ia pentru a nu fi în
ț
eleasă de persoane neautorizate.
În
prezent
criptarea
datelor,
în
procentaj
mare
este
folosită
la
nivelul
digital.
Un
studiu
realizat
de
Digital
Universe
Study,
IDC
ANALYZE
THE
FUTURE
ș
i
Internet
World
Stats,
arată
că
la
nivel
mondial
(anul
2017
–
ultima
analiză)
procentul
utilizatorilor
este
de
4,157
miliarde
sau
54,4%
din
popula
ț
ia
planetei.
Analizând
în
detaliu,
putem
afla
din
studiul
celor
de
la
DOMO,
că
în
fiecare
zi
sunt
generate
“2.5
quintillion
bytes”
echivalentul
a
2,5
milioane
de
TB
(terabytes).
Aceste
date
sunt
generate
de
utilizatori
ai
diferitelor
platforme
de
socializare,
site-uri
de
ș
tiri,
aplica
ț
ii
mobile,
internet-ul
cooki e-uri,
e-mail-uri,
site-uri
de
vânzări
online,
bănci,
spitale,
centre
de
cercetare,
agen
ț
ii
guvernamentale,
poli
ț
ie,
armată,
iar
recent
o
parte
îi
este
atribuita
tehnologiei
blockchain
ș
i
a
proiectelor
bazate
pe
această
tehnologie
ș
i lista poate c ontinua.
Având
în
vedere
informa
ț
ia
prezentată,
se
poate
trage
o
concluzie
de
ce
criptografia
reprezintă
un
avantaj
în
lumea
digitală.
Informa
ț
ia
“sensibilă”
trebuie
protejată
pentru
a
nu
avea
acces
la
el
fiecare
utilizator
al
internetului.
în
acest
sens
au
fost
implementa
ț
i
diver
ș
i
algoritmi
de
criptare
a
datelor,
pentru
a
codifica
datele
ș
i
a
face
ca
ele
să
nu
poată
fi
în
ț
elese
sau
citite,
iar
în
cazul
în
care
cineva
ob
ț
ine
fraudulos
informa
ț
ie,
aceasta
nu
poate
să
fie
decodificată
ș
i
citită
pentru
că
nu
se
cunoa
ș
te
metoda
de
a
decripta
informa
ț
ia
(asta
cazul
majoritar
al
algoritmilor
de
criptare).
Algoritmi
de
criptare
sunt
complec
ș
i
din
punct
de
vedere matematic, iar o decodificare necesită timp îndelungat.
Spre
exemplu
avem
criptare
înlăn
ț
uită,
criptare
simetrică
(DES,
AES,
MARS,
IDEA,
RC
2
/4/
5
/6,
Blowfish,
Twofish,
Threefish,
Serpent),
criptare
asimetrică
(Diffie-Hellman,
RSA,
Elliptic
Curve),
criptarea
cu
chei,
criptare
cu
hash-uri,
criptarea
BASE
64,
HEX,
MD5,
MD6,
semnătură
digitală,
stenografie,
sisteme
de
criptare
polialfabetice,
sisteme
mixte,
generatoare
pseudoaleatoare,
metoda
transpozi
ț
iei,
metoda
substitu
ț
iei
etc.
Lista
este
una
însemnată, acest domeniu este unul vast
ș
i stufos, cu un trecut bogat.
30
Codarea/decodarea datelor:
http://codare-date.cpf.ro/index.php
(data accesării: 22.05.2018)
În
cadrul
proiectului
Hito,
au
fost
utilizat
protocolul
SSL
(Secure
Socket
Layer)
ș
i
algoritmul
criptografic SHA-3 (Secure Hash Algorithm 3).
3.8.1 SSL (Secure Socket Layer)
Secure
Sockets
Layer
(SSL)
este
o
tehnologie
standard
de
securitate
pentru
stabilirea
unei
legături
criptate
(link)
între
un
server
ș
i
un
client,
de
obicei
un
server
web
(website/client)
ș
i
un
browser,
un
server
de
po
ș
tă
electronică
ș
i
un
client
de
po
ș
tă
electronică
(ex: Outlook).
SSL
permite
transmiterea
sigură
a
informa
ț
iilor
sensibile,
cum
ar
fi
numerele
căr
ț
ilor
de
credit,
numerele
de
securitate
socială
ș
i
datele
de
conectare
(autentificare).
În
mod
normal,
datele
trimise
între
browsere
ș
i
serverele
web
sunt
trimise
în
text
simplu
sau
clar,
lăsându-vă
datele
vulnerabile
la
interceptarea.
Dacă
un
atacator
este
capabil
să
intercepteze
toate
datele
trimise între un browser
ș
i un server web, ace
ș
tia pot vedea
ș
i utiliza aceste informa
ț
ii.
Mai
exact,
SSL
este
un
protocol
de
securitate.
Protocoalele
descriu
modalitatea
de
utilizare
a
algoritmilor.
În
acest
caz,
protocolul
SSL
determină
variabilele
de
criptare
atât
pentru
link,
cât
ș
i
pentru
datele
transmise.
Toate
browserele
au
capacitatea
de
a
interac
ț
iona
cu
serverele
web
securizate
utilizând
protocolul
SSL.
Cu
toate
acestea,
browserul
ș
i
serverul
au
nevoie
de
ceea
ce
se
nume
ș
te
un
certificat
SSL
pentru
a
putea
stabili
o
conexiune
securizată.
3.8.2 SHA-3 (Secure Hash Algorithm 3)
SHA-3
este
cel
mai
recent
membru
al
familiei
Secure
Hash
Algorithm,
lansat
de
31
NIST
pe
5
august
2015.
SHA-3
este
un
subset
al
primitivei
criptografice
Keccak,
proiectat
de
Guido Bertoni, Joan Daemen, Michaël Peeters
ș
i Gilles Van Assche.
Keccak
se
bazează
pe
o
abordare
nouă,
denumită
construc
ț
ie
burete.
Construc
ț
ia
de
burete
se
bazează
pe
o
func
ț
ie
aleatorie
largă
sau
o
permutare
aleatorie
ș
i
permite
introducerea
("absorb
ț
ia"
în
terminologia
bure
ț
ilor)
a
oricărei
cantită
ț
i
de
date
ș
i
ie
ș
irea
("stoarcerea")
a
oricărei
cantită
ț
i
de
date,
în
timp
ce
ac
ț
ionează
ca
o
func
ț
ie
pseudorandom
cu
privire la toate intrările anterioare. Acest lucru conduce la o mare flexibilitate.
Familia
SHA-3
a
rutinelor
hash
generează
semnale
aproape
unice
de
224-bi
ț
i,
256-bi
ț
i,
384-bi
ț
i
sau
512
bi
ț
i
(28-
/
32-
/
48-
/
64-octe
ț
i)
pentru
un
text.
Un
hash
criptografic
(numit
"digest")
este
un
fel
de
"semnătură"
pentru
un
text
sau
un
fi
ș
ier
de
date.
Hash
algoritmii
sunt
în
general
utili
în
lumea
comunica
ț
iilor
electronice.
Transformă
un
mesaj
digital
într-un
scurt
mesaj
"digest"
pentru
a
fi
utilizat
în
semnăturile
digitale
ș
i
în
alte
aplica
ț
ii.
31
SHA-3:
https://en.wikipedia.org/wiki/SHA-3
(data accesării: 23.05.2018)
3.9 Log4j 2 framework
Log4j
este
o
bibliotecă
Java
(API)
specializată
în
logarea
de
mesaje
în
aplica
ț
ii.
La
nivelul
său
de
bază,
log4j
înlocuie
ș
te
System.out.println.
Biblioteca
a
fost
scrisa
de
Ceki
Gülcü,
dar
acuma
este
un
proiect
ce
apar
ț
ine
de
Apache
Software
Foundation.
Versiunea
ini
ț
iala
a
fost
lansată
cuma
17
ani,
pe
data
de
08.ianuarie.2001,
iar
ultima
actualizare
a
avut
loc
în
18.noiembrie.2017,
cu
versiunea
2.10.0.
Platforma
de
lucru
este
JVM
(Java
Virtual
Machine),
fiind
scrisă
în
limbajul
Java,
cu
licen
ț
a
Apache
License
2.0.
Log4j
suportă
publicarea
de
mesaje
pe
mai
multe
nivele,
avem
astfel:
TRACE,
DEBUG,
INFO,
WARN,
ERROR,
FATAL.
Framework-ul
a
fost
atât
de
folositor
încât
a
fost
portat
ș
i
pe
limbile
C,
C++, C#, Perl, Python, Ruby
ș
i Eiffel.
Cu
log4j
este
posibilă
activarea
înregistrării
în
timpul
executării
fără
modificarea
32
aplica
ț
iei
binare.
Pachetu l
log4j
este
conceput
astfel
încât
aceste
declara
ț
ii
să
rămână
în
codul
expediat
fără
a
suferi
un
cost
de
performan
ț
ă
ridicat.
Logarea
comportamentului
poate
fi
controlată
prin
editarea
unui
fi
ș
ier
de
configurare,
fără
a
atinge
aplica
ț
ia
binară.
Logging-ul
furnizează
dezvoltatorului
un
context
detaliat
pentru
e
ș
ecurile
aplica
ț
iilor.
Pe
de
altă
parte,
testarea
asigură
asigurarea
calită
ț
ii
ș
i
încrederea
în
aplica
ț
ie.
Logarea
ș
i
testarea
nu
trebuie
confundate.
Ele
sunt
complementare.
Atunci
când
logarea
este
folosită
cu
în
ț
elepciune,
se
poate dovedi a fi un instrument esen
ț
ial.
Una
dintre
trăsăturile
distinctive
ale
log4j
este
no
ț
iunea
de
mo
ș
tenire
în
logger.
Folosind
o
ierarhie
logger
este
posibil
să
se
controleze
care
declara
ț
ii
log
sunt
extrase
cu
granularitate
arbitrar
fină,
dar
ș
i
o
mare
u
ș
urin
ț
ă.
Acest
lucru
ajută
la
reducerea
volumului
de
ie
ș
iri
înregistrate
ș
i
a
costului
înregistrării.
Obiectivul
ie
ș
irii
jurnalului
poate
fi
un
fi
ș
ier,
un
OutputStream,
un
java.io.Writer,
un
server
log4j
la
distan
ț
ă,
un
daemon
de
la
Unix
Syslog
la
distan
ț
ă sau multe alte
ț
inte de ie
ș
ire.
Un
alt
avantaj
important
al
Log4j
este
că
pot
fi
setate
diferite
niveluri
de
logare.
33
Nivelurile
sunt
ierarhice
ș
i
sunt
după
cum
urmează:
TRACE,
DEBUG,
INFO,
WARN,
ERROR
ș
i
FATAL.
Dacă
seta
ț
i
un
anumit
nivel
de
jurnal,
mesa jele
vor
fi
înregistrate
pentru
acel
nivel
ș
i
pentru
toate
nivelurile
de
deasupra
acestuia,
ș
i
nu
pentru
niciun
nivel
de
jurnal
sub
acesta.
De
exemplu,
dacă
nivelul
de
jurnal
este
setat
la
EROARE,
ve
ț
i
înregistra
mesaje
care
sunt
erori
ș
i
letale.
Dacă
nivelul
dvs.
de
jurnal
este
setat
la
INFO,
ve
ț
i
înregistra
mesaje
care
sunt
info,
warn,
error
ș
i
fatal.
De
obicei,
atunci
când
vă
dezvolta
ț
i
pe
ma
ș
ina
locală
(localhost),
este
bine
să
seta
ț
i
nivelul
jurnalului
la
DEBUG,
iar
atunci
când
implementa
ț
i
o
aplica
ț
ie
web,
trebuie
să
seta
ț
i
nivelul
jurnalului
la
INFO
sau
mai
mare,
astfel
încât
să
nu
vă
umple
ț
i jurnalele de eroar e cu depana
ț
i mesajele.
32
Logging Services:
https://logging.apache.org/log4j/1.2/
(data accesării: 02.06.2018)
33
AVAJAVA Web Tutorials:
http://www.avajava.com/tutorials/lessons/what-is-log4j-and-how-do-i-use-it.html
(data accesării:
02.06.2018)
3.10 Eclipse (software)
Eclipse
este
un
mediu
de
dezvoltare
integrat,
pe
scurt
IDE,
utilizat
în
programarea
34
pe
calculator
ș
i
este
cel
mai
utilizat
Java
IDE.
Acesta
con
ț
ine
un
spa
ț
iu
de
lucru
de
bază
ș
i
un
sistem
de
plug-in
extensibil
pentru
personalizarea
mediului.
A
fost
scris
majoritar
în
limbajul
Java,
lansat
în
urmă
cu
16
ani,
pe
data
de
7.noiembrie
2001,
principalul
său
scop
este
de
a
putea
dezvolta
aplica
ț
ii
în
Java.
Cu
toate
acestea,
sistemul
permite
ca
prin
cadrul
unor
plug-in-uri,
să
se
poată
scrie
aplica
ț
ii
în
alte
limbaje
de
programare,
spre
exemplu:
ABAP,
C,
C++,
C#,
JavaScript,
PHP,
Python,
Ruby,
plus
alte
19
limbaje.
IDE-ul
este
suportat
pe
diverse
OS-uri
(Operating
System),
de
exemplu:
Linux,
macOS,
Solaris,
Windows.
Ultima
versiunea
stabilă
este
denumita
“Oxygen
3”,
actualizată
în
urma
cu
două
luni,
pe
data
de
30.martie.2018. Versiunea Oxygen 3, a fost utilizată pentru dezvoltarea proiectului Hito.
Eclipse
suportă
dezvoltarea
pentru
Tomcat
,
GlassFish
ș
i
multe
alte
servere
ș
i
este
adesea
capabilă
să
instaleze
serverul
necesar
(pentru
dezvoltare)
direct
din
IDE.
Acesta
suportă
depanarea
la
distan
ț
ă,
permi
ț
ând
unui
utilizator
să
vadă
variabilele
ș
i
să
treacă
prin
codul
unei
aplica
ț
ii
care
rulează
pe
serverul
ata
ș
at.
Proiectul
Eclipse
Web
Tools
Platform
(WTP)
este
o
extensie
a
platformei
Eclipse
cu
instrumente
pentru
dezvoltarea
aplica
ț
iilor
Web
ș
i
Java
EE.
Acesta
include
editori
sursă
ș
i
grafică
pentru
o
varietate
de
limbi,
exper
ț
i
ș
i
aplica
ț
ii
încorporate
pentru
a
simplifica
dezvoltarea
ș
i
instrumente
ș
i
API-uri
pentru
a
sprijini
implementarea, rularea
ș
i testarea aplica
ț
iilor.
3.10.1 Checkstyle
Checkstyle
este
un
instrument
de
analiză
statică
a
codului
utilizat
în
dezvoltarea
de
35
software
pentru
a
verifica
dacă
codul
sursă
Java
respectă
regulile
de
codare.
Dezvoltat
ini
ț
ial
de
Oliver
Burn
în
2001,
este
sus
ț
inut
de
o
echipă
de
mai
mul
ț
i
dezvoltatori
din
întreaga
lume.
Versiunea
8.10
este
ce-a
mai
stabilă
ș
i
actualizată,
care
vizează
limbajul
Java
8.
Stilul
de
programare
adoptat
pentru
un
proiect
de
dezvoltare
software,
poate
ajuta
la
respectarea
bunele
practici
de
programare
care
îmbunătă
ț
esc
calitatea
codului,
lizibilitatea,
reutilizare,
ș
i
de
a
reduce
costurile
de
dezvoltare.
Verificările
efectuate
se
limitează,
în
principal,
la
prezentare
ș
i
nu
analizea ză
con
ț
inutul
ș
i
nu
confirmă
corectitudinea
sau
caracterul
complet
al
programului.
În
practică,
poate
fi
dificil
să
se
respecte
toate
constrângerile
legate
de
stil,
dintre
care
unele
ar
putea
dăuna
dinamicii
etapelor
de
programare;
a
ș
adar,
poate
fi
util
să
fie
stabilit ce nivel de verificare este necesar pentru un anumit tip de program.
Checkstyle
define
ș
te
un
set
de
module
disponibile,
fiecare
dintre
acestea
oferind
reguli
de
verificare
cu
un
nivel
de
stricte
configurabil
(obligatoriu,
op
ț
ional
etc.).
Fiecare
regulă
poate
ridica
notificări,
avertismente
ș
i
erori.
De
exemplu,
checkstyle
poate
examina:
comentariile
Javadoc
pentru
clase,
atribute
ș
i
metode,
denumirea
conven
ț
iilor
de
atribute
ș
i
metode,
limita
numărului
de
parametri
de
func
ț
ii,
lungimi
ale
liniilor,
prezen
ț
a
titlurilor
obligatorii,
utilizarea
importurilor
de
pachete,
a
claselor,
a
modificatorilor
de
domeniu
ș
i
a
34
Eclipse:
https://en.wikipedia.org/wiki/Eclipse_(software)#Architecture
(data accesării: 04.06.2018)
35
Checkstyle:
https://en.wikipedia.org/wiki/Checkstyle
(data accesării: 05.06.2018)
blocurilor
de
instruc
ț
iuni,
spa
ț
iile
dintre
unele
caractere,
bune le
practici
de
construc
ț
ie
a
clasei, multiple măsurători de complexitate , printre care
ș
i expresii.
Checkstyle
este
construit
într-un
fi
ș
ier
JAR
care
poate
rula
în
interiorul
unui
Java
VM
sau
ca
Apache
Ant.
Se
poate
integra,
de
asemenea,
într-un
IDE
sau
alte
instrumente.
Un
plug-in
Checkstyle
poate
oferi
noi
func
ț
ionalită
ț
i,
cum
ar
fi:
supraîncărcarea
sintaxei
de
colorare
sau
decora
ț
iuni
în
editorul
de
cod,
decorează
exploratorul
de
proiect
pentru
a
eviden
ț
ia
resursele
care
prezintă
probleme,
adăugă
avertismente
ș
i
ie
ș
iri
de
erori
la
ie
ș
iri.
Astfel,
dezvoltatorul
poate
accesa
direct
păr
ț
ile
de
cod
eviden
ț
iate
de
Checkstyle.Ca
ș
i
concluzie
putem
spune
scurt
că
checkstyle
este
un
instrument
de
dezvoltare
care
ajută
36
programatorii să scrie cod Java care să respecte un standard de codificare.
3.11 Visual Studio Code
V
isual
Studio
Code
este
un
editor
de
cod
sursă,
u
ș
or,
puternic,
care
rulează
pe
37
desktop
ș
i
este
disponibi l
pentru
Windows,
MacOS
ș
i
Linux.
Dispune
de
suport
încorporat
pentru
JavaScript,
TypeScript
ș
i
Node.js
ș
i
are
un
ecosistem
bogat
de
extensii
pentru
alte
limbi
(cum
ar
fi
C
++,
C
#,
Java,
Python,
PHP,
Go)
ș
i
runtime
(cum
ar
fi
.NET
ș
i
Unity).
Acesta
a
fost
dezvoltat
în
cadrul
Microsoft.
VS,
de
la
prescurtarea
lui,
este
n
editor
stabil
ș
i
u
ș
or
de
folosit.
Acesta
include
suport
pentru
debugging
(depanare),
încorporează
Git,
eviden
ț
iază
sintaxa,
completare
automată
în
cadrul
codului,
fragmente
(snippets),
ș
i
refactorizarea
codului.
De
asemenea,
este
personalizabil,
astfel
încât
utilizatorul
poate
schimba
tema
editorului
,
comenzile
rapide
de
la
tastatură
ș
i
preferin
ț
ele.
VS
este
open-source
, de
ș
i descărcarea se face sub licen
ț
ă de proprietar.
Visual
Studio
este
bazat
pe
Electron,
un
framework
care
este
utilizat
pentru
a
38
implementa
aplica
ț
ii
desktop
în
Node.js,
care
rulează
pe
schema
motorului
Blink.
De
ș
i
folose
ș
te
framework-ul
Electron,
acest
software
nu
utilizează
Atom,
ș
i
folose
ș
te
în
acela
ș
i
timp
aceea
ș
i
componentă
a
editorului
(codificat
“Monaco”)
utilizată
în
Visual
Studio
Team
Service
denumită
anterior
Visual
Studio
Online.
În
sondajul
de
analiză
realizat
de
Stack
Overflow
2018,
acest
editor
a
ie
ș
it
pe
locul
unu
în
cardul
celor
mai
folosite
editoare
pentru
dezvoltare,
34.9%
din
75,398
de
participan
ț
i.
Visual
Studio
este
un
editor
relativ
nou
în
acest
domeniu,
el
a
fost
lansat
în
urma
cu
3
ani,
pe
data
de
29.aprilie.2018.
Este
un
editor
des
actualizat,
ultima
actualizare
a
avut
loc
în
data
de
4.mai.2018,
cu
versiunea
1.23.
Editorul
a
fost
scris
în
TypeScript,
JavaScript
ș
i
CSS.
In
câteva
cuvinte
putem
caracteriza
acest
editor
ca
unul
puternic,
u
ș
or
de
folosit,
având
nevoie
de
resurse
pu
ț
ine,
oferind
numeroase
avantaje
într-un
mediu
bine
structurat
ș
i
stabil.
Acest
IDE
a
fost
utilizat
in
cadrul
proiectului
Hito
pentru aplica
ț
ia client (fro nt-end).
36
Checkstile:
http://checkstyle.sourceforge.net/
(data accesării: 05.06.2018)
37
Visual Studio Code Official Documentation:
https://code.visualstudio.com/docs
(data accesării:
05.06.2018)
38
Visual Studio Cod:
https://en.wikipedia.org/wiki/Visual_Studio_Code
(data accesării: 06.06.2018)
3.12 WildFly
WildFly,
cunoscut
ș
i
ca
JBoss
AS
(Application
Server),
sau
pur
ș
i
simplu
JBoss,
este
39
un
server
de
aplica
ț
ii
scris
de
JBoss,
o
filială
a
Red
Hat
Inc.
WildFly
este
scris
în
Java
ș
i
implementează
specifica
ț
ia
Java
Platform,
Enterprise
Edition
(Java
EE).
WildFly
este
un
server,
care
poate
să
ruleze
pe
mai
multe
platforme.
Acesta
este
un
software
gratuit,
open-source,
în
conformitate
cu
cerin
ț
ele
din
GNU
Lesser
General
Public
License
(LGPL),
versiunea
2.1.
La
20.noiembrie.2014,
JBoss
Application
a
fost
redenumit
WildFly.
Comunitatea
JBoss
ș
i
alte
produse
Red
Hat
JBoss,
precum
JBoss
Enterprize
Application
Platform
nu
au
fost
redenumite.
Prima
versiunea
a
fost
lansată
în
2006,
ultima
versiunea
stabilă
este
versiunea
WildFly
13.0.0.
WildFly
este
o
aplica
ț
ie
server.
Serverul
de
aplica
ț
ii
40
JBoss
ac
ț
ionează
ca
o
alternativă
open-source
la
solu
ț
ii
precum
IBM
WebSphere
ș
i
SAP
NetWeaver.
Acesta
se
bazează
în
principal
pe
API-ul
Enterprise
JavaBeans
al
Sun
Microsystems
pentru
func
ț
ionalitate.
Wildfly
este
un
server
de
aplica
ț
ii
Java
servlet,
aplica
ț
ia
oferă
o
stivă
completă
Java
EE,
inclusiv
Enterprise
JavaBeans,
plus
multe
alte
tehnologii
care
sunt
utile
pentru
dezvoltare.
Ca
majoritatea
sistemelor
dezvoltate
pe
EJB,
acesta
este
conceput
pentru
a
permite
dezvoltatorilor
să
se
concentreze
în
primul
rând
asupra
arhitecturii
business
a
serverului,
mai
degrabă
decât
să
fie
preocupat
în
programare
ș
i
codificare
inutile
pentru
a
conecta
diferitele
păr
ț
i
de
lucru.
Serverul
Wildfly
a
fost
utilizat
în
proiectul
Hito
pentru a putea face deploy (lansa) la aplica
ț
ia server Hito în cadrul acestuia.
3.13 Version Control
Sistemele
de
control
al
versiunilor
(Version
Control)
reprezintă
o
categorie
de
41
instrumente
software
care
ajută
o
echipă
software
să
gestioneze
schimbările
codului
sursă
în
timp.
Software-ul
de
control
al
versiunilor
ț
ine
eviden
ț
a
fiecărei
modificări
a
codului
într-un
tip
special
de
bază
de
date.
În
cazul
în
care
se
face
o
gre
ș
eală,
dezvoltatorii
pot
întoarce
ceasul
ș
i
pot
compara
versiunile
anterioare
ale
codului
pentru
a
ajuta
la
remedierea
gre
ș
elii,
minimizând întreruperea tuturor membrilor echipei.
Este
aplicată
cu
predilec
ț
ie
în
42
programare,
cu
scopul
de
a
păstra
versiuni
succesive
ale
codului
sursă
al
unui
program
de
calculator.
O
solu
ț
ie
ar
fi
arhivarea
separată
ș
i
completă
a
fiecărei
versiuni
a
programului
într-o
bază
de
date
(pe
un
purtător
de
date
extern),
dar
această
metodă
ar
necesita
în
general
prea
mult
spa
ț
iu
de
mem orie.
În
locul
ei
se
utilizează
tehnici
speciale,
care
reduc
memoria
totală
necesară
ș
i
care
facilitează
reconstruc
ț
ia
„în
zbor”,
la
cerere,
a
oricărei
versiuni
din
istoria programului.
39
WildFly:
https://en.wikipedia.org/wiki/WildFly
(data accesării: 06.06.2018)
40
Future Hosting:
https://www.futurehosting.com/blog/jboss-vs-tomcat-choosing-a-java-application-server/
(data
accesării: 06.06.2018)
41
Bitbucket:
https://www.atlassian.com/git/tutorials/what-is-version-control
(data accesării: 06.06.2018)
42
Controlul versiunulor:
https://ro.wikipedia.org/wiki/Controlul_versiunilor
(data accesării: 06.06.2018)
3.13.1 Git
Git
este
un
sistem
revision
control
care
rulează
pe
majoritatea
platformelor,
inclusiv
43
Linux,
POSIX,
Windows
ș
i
OS
X.
Ca
ș
i
Mercurial,
Git
este
un
sistem
distribuit
ș
i
nu
între
ț
ine
o
bază
de
date
comună.
Este
folosit
în
echipe
de
dezvoltare
mari,
în
care
membrii
echipei
ac
ț
ionează
oarecum
independent
ș
i
sunt
răspândi
ț
i
pe
o
arie
geografică
mare.
Git
este
dezvoltat
ș
i
între
ț
inut
de
Junio
Hamano
ș
i
Linus
Torvalds,
fiind
publicat
sub
licen
ț
ă
GPL
ș
i
este
considerat
un
software
open-source.
Ultima
versiunea
stabilă
este
versiunea
2.17.1
din
data
de
22.mai.2018.Starea
de
dezvoltare
a
git
este
activă,
lucrându-se
la
îmbunată
ț
iri.
Git
a
fost scris în C, Bourne Shell
ș
i Perl. Git este un revision control.
În
cadrul
proiectului
Hito,
a
fost
folosită
tehnologia
Git
prin
serviciul
BitBucket,
iar
pentru
a
putea
avea
un
control
mai
rapid,
a
fost
folosită
aplica
ț
ia
de
desktop
“GitHub
Desktop
App”
prin
care
se
pot
adăuga
într-o
listă
diverse
“repository”,
pentru
diverse
proiecte.
Prin
aceasta
se
gestionează
mai
eficient
un
repository
pe
cloud,
iar
nevoia
de
a
face
commit
ș
i
“push”
(fetch
origin)
din
linie
de
comandă
dispare.
De
ș
i
este
o
aplica
ț
ie
GitHub,
aceasta
se
poate
conecta
ș
i
la
depoz ite
din
cadrul
serviciului
BitBucket.
GitHub
Desktop
App
a
fost
ales
în
schimbul
SourceTree,
din
cadrul
Atlassian,
datorita
faptului
că
UI-ul
este
simplu,
intuitiv
ș
i
u
ș
or de folosit.
3.13.3 BitBucket
Bitbucket
este
un
serviciu
de
găzduire
a
depozitului
de
control
al
versiunilor
web
44
de
ț
inut
de
Atlassian,
pentru
codul
sursa
ș
i
proiecte
de
dezvoltare
care
folosesc
sisteme
de
control
al
reviziei
de
tip
Mercurial
(începând
cu
lansarea)
sau
Git
(din
octombrie
2011).
Bitbucket
oferă
atât
planuri
comerciale,
cât
ș
i
conturi
gratuite.
Acesta
oferă
conturi
gratuite
cu
un
număr
nelimitat
de
depozite
private
(care
pot
avea
până
la
cinci
utilizatori
în
cazul
conturilor
gratuite)
începând
cu
luna
septembrie
2010.
Bitbucket
se
integrează
cu
alte
software-uri
Atlassian
cum
ar
fi
Jira
,
HipChat
,
Confluence
ș
i
Bambus.
Este
similar
cu
GitHub,
care
utilizează
în
primul
rând
Git.
De
asemenea
BitBucket
utilizează
Git
nativ.
Bitbucket
comercializează
în
mod
tradi
ț
ional
serviciile
sale
dezvoltatorilor
profesioni
ș
ti
cu
cod software propriu privat, mai ales de când a fost achizi
ț
ionat de Atlassian în 2010.
În
septembrie
2016,
Bitbucket
a
anun
ț
at
că
a
ajuns
la
5
milioane
de
dezvoltatori
ș
i
900.000
de
echipe
pe
platforma
sa.
Bitbucket
are
3
modele
de
implementare:
Cloud,
Bitbucket
Server
ș
i
Data
Center.
Acesta
este
disponibil
pe
diverse
limbi,
printre
care:
engleză,
rusă,
germană,franceză,
chineză
etc.
BitBucket
a
fost
creat
de
Jesper
Noehr,
fiind
lansat
în
2008,
în
urmă
cu
10
ani.
BitBucket
a
fost
utilizat
în
cadrul
proiectului
Hito
pentru
a
păstra
versiunile
aplica
ț
iilor
într-un
mediu
sigur,
din
care
se
poate
face
oricând
un
“pull”
pentru
a
reveni la o versiune anterioară.
43
Git:
https://ro.wikipedia.org/wiki/Git
(data accesării: 06.06.2018)
44
BitBucket:
https://en.wikipedia.org/wiki/Bitbucket
(data accesării: 06.06.2018)
3.13 JIRA
Jira
este
un
software
produs
de
către
Atlassian,
scopul
său
fiind
de
a
putea
urmări
45
task-urile,
bug-urile,
problemele,
dar
ș
i
administrarea
proiectului,
din
cadrul
unei
echipe.
Numele
său
vine
de
la
denumirea
japoneză
“Gojira”,(nume
dat
monstrului
Godzilla)
fiind
o
trunchiere
a
numelui.
Acest
software
a
fost
lansat
în
urma
cu
16
ani,
în
anul
2002.
Conform
unui
studiu
realizat,
Jira
este
cel
mai
ultilizat
tool
pentru
administrare.
Jira
este
un
proiect
ce
este
constant
actualizat,
ultima
actualizare
a
fost
pe
data
de
24
aprilie
2018.
A
fost
scris
în
limbajul
Java,
iar
ca
ș
i
compatibilitate,
cross-platform
(atât
pe
OS-uri,
cât
ș
i
pe
46
smartphone-uri)
este
un
punct
ce
îl
define
ș
te.
Utilizarea
lui
este
sub
licen
ț
a.
În
cadrul
Jira
găsim panouri scrum, panouri kanban, agile reporting cât
ș
i planificarea lor.
Capitolul IV
Detalii de implementare
4.1 Aplica
ț
ia server
Aplicatia
Hito,
con
ț
ine
atât
o
aplica
ț
ie
server,
cât
ș
i
una
client
cu
interfa
ț
a,
realizată
în
Angular
6.
Aplica
ț
ia
server
prelucrează
informa
ț
ia.
o
structurează,
face
legătura
cu
baza
de
date
ș
i
o
ș
i
stochează
în
DB.
În
prima
versiune
a
aplicatiei
a
fost
realizată
implementarea
functionalită
ț
ii
de
autenti ficare
în
aplicatie,
pe
baza
verificări
informa
ț
iei
în
baza
de
date
ș
i
în
server.
În
cadrul
nivelului
rest,
al
serverului,
există
verificări
pentru
orice
utilizator
ce
dore
ș
te
a
se
autentifica
pe
interfa
ț
ă,
iar
în
cazul
în
care
utilizatorul
respectiv
există,
se
realizeaza
autentificarea.
În
caz
contrar
se
trimite
ca
ș
i
răspuns
spre
aplica
ț
ia
client
un
cod
de
eroare
ș
i
un mesaj corespunzător în format JSON (JavaScript Object Notation).
Înainte
de
a
trece
prin
acele
verificări,
trebuie
satisfăcută
o
condi
ț
ie
if,
care
verifică
dacă
valoarea
datelor
(din
field-urile
de
la
formularul
de
login)
este
egală
cu
null
sau
dacă
există
spa
ț
ii
goale,
dacă
condi
ț
ia
nu
este
satisfăcută,
este
returnat
un
true,
caz
în
care
se
continuă
cu
verificările
din
blocul
de
if.
În
caz
contrar,
este
întors
un
false,
iar
condi
ț
ia
if
nu
intra
în
blocul
cu
instruc
ț
iuni
ș
i
întoarce
ceea
ce
are
pe
else,
adică
un
cod
de
eroare
ș
i
un
mesaj, acestea fiind trimise la aplicatia client.
Aplica
ț
ia
server
a
fost
dezvoltată
prim
limbajul
de
programare
Java,
iar
ca
ș
i
IDE,
a
fost
întrebuin
ț
at
Eclipse.
Pentru
a
lucra
structurat
ș
i
automat,
a
fost
folosit
framework-ul
Maven, de altfel o necesitate în cazul proiectelor cu o arhitectura modulară.
45
Jira (software):
https://en.wikipedia.org/wiki/Jira_(software)
(data accesării: 14:06.2018)
46
Jira:
https://ro.atlassian.com/software/jira
(data accesării: 14.06.2018)
F
igura 4.1.1
Modulele Hito
Primul
modul
din
aplica
ț
ia
server
este
“hito-parent”.
Modulul
acesta
are
rol
de
a
administra
toate
dependin
ț
ele
externe
din
cadrul
proiectului.
În
acest
modul
sunt
declarate
toate
versiunile
folosite
în
proiect,
iar
în
pom-urile
din
fiecare
modul
sunt
doar
declarare,
însă
fără
versiune,
versiunea
este
luată
din
pom-ul
din
modulul
parent.
Acest
modul
este
folosit
ș
i
în
momentul
în
care
se
face
build
fiecărui
modul
din
proiect.
Fiecare
modul
în
parte
este
legat
de
acest
modul
părinte,
de
la
care
îi
vine
ș
i
numele.
După
cum
se
poate
vedea
în
Figura
4.1.2
există
ș
i
un
modul
“hito ”
de
tip
pom.
În
acest
modul
se
află
un
fi
ș
ier
pom
în
care
este
specificată ordinea în care este realizat un build-ul proiectului
ș
i versiunea aplica
ț
iei.
F
igura 4.1.2
Hito Parent
Al
doilea
modul
din
cadrul
serverului
este
modulul
“commons”
(hito-commons),
pe
care
îl
putem
vedea
în
Figura
4.1.1.
Acesta
con
ț
ine
elementele
comune
la
nivel
de
aplica
ț
ie
server.
Păr
ț
inle
comune
sunt
obiecte
care
ajută
la
transferul
datelor
dintre
un
modul
ș
i
altul/altele.
Excep
ț
ii
comune,
care
ajută
la
eventualele
erori
ce
pot
apărea
la
nivel
de
server,
spre
a
îmbunătă
ț
î
calita tea
serverului
ș
i
a
nu-l
putea
bloca.
În
cazul
proiectului
Hito,
excep
ț
iile
sunt
folosite
pentru
a
transmite
un
mesaj
de
eroare
la
aplica
ț
ia
client,
care
o
afi
ș
ează
pe
interfa
ț
ă,
sau
pentru
logarea
lor
într-un
fi
ș
ier
extern.
Acest
module
con
ț
ine
ș
i
un
pachet
de
utilită
ț
i,
existe n
ț
ă
lui
este
datorita
faptului
ca
avem
elemente
ce
sunt
folosite
de
câteva
ori
în
aplica
ț
ie,
care
nu
apar
ț
in
de
o
categorie
anume.
Modulul
este
împachetat
ca
ș
i
format
JAR
(Java
Archive).
O
reprezentare
a
modulului
commons
avem
în
Figura
4.1.2.
De
acest
modul
se
folosesc
ș
i
modulele
“hito-persistence”,
“hito-business”
ș
i
“hito-rest-api”,
după cum se observă în Figura 4.1.3.
F
igura 4.1.3
Hito Commons
Modulul
trei,
ce
poartă
denumirea
de
“hito-persistence”,
sau
nivelul
de
persisten
ț
ă.
Rolul
acestui
modul
este
de
a
crea
legătura
dintre
baza
de
date
ș
i
aplica
ț
ie.
În
cadrul
acestui
nivel
se
execută
select-urile
din
baza
de
date
pentru
anumite
date,
ce
trebuiesc
în
nivelele
superioare,
select-urile
pentru
meniurile
ș
i
o
submeniurile
aplica
ț
iei,
datele
din
tabele,
etc.
Tot
în
cadrul
acestui
nivel,
sunt
executate
modificările,
ș
tergerile,
modificările
sau
actualizările
datelor
pentru
baza
de
date,
înregistrarea
unui
user,
etc.,
date
ce
vin
din
aplica
ț
ia
client
(informa
ț
ia
primită
de
server
din
front-end).
Modulul
face
legătura
la
o
bază
de
date
MySQL, iar pentru persisten
ț
ă, este utilizat framework-ul Hibernate.
Figura 4.1.4
Hito persistence annotation
Privind la Figura 4.1.4, puteam vedea ca pe linia cu numărul 23 avem o adnotare
“@Entity”, această adnotare are rol de punte între baza de date
ș
i aplica
ț
ia. La linia 24 avem
o adnotare “@Table(name = ”user”)”, care clarifica faptul că există în DB o tabela cu acest
nume, “user”. În cazul în care nu exista variabile “name” cu parametru,
ș
i este specificat doar
“@Table”, atunci, este căutat în baza de date o tabela cu numele entită
ț
ii. În cazul Hito,
entitatea UserDO are în clasă un “id”, care corespunde coloanei “id” din DB. Câmpurile
definite cu adnotarea “@Column” reprezintă coloanele tabelei “user” din baza de date.
Figura 4.1.5
Hito Persistence
Modulul patru al aplica
ț
iei este denumite business, iar în cadrul Hito, poartă numele
de “hito-business”, Figura 4.1.5. În cadrul acestui nivel, este implementată toată logica din
spatele serverului. Nivelul folose
ș
te Spring framework pentru a nu duplica codul folosit.
Nivelul procesează informa
ț
ia primită
ș
i întoarce un răspuns nive lelor, răspuns ce o să fie
trimis clientului pe interfa
ț
ă. Acest nivel, putem spune că este nivelul în care este luată
decizia pentru logica de func
ț
ionare din server.
F
igura 4.1.6
Hito Business
Modulul
cinci,
numit
“hito-rest_api”
este
strict
destinat
serviciului
web.
La
baza
serviciilor
implementate,
stă
arhitectura
RESTful.
Aceste
servicii
deservesc
o
ruta
anume
din
cadrul
aplica
ț
iei
client.
În
momentul
în
care
un
utilizator
dore
ș
te
să
se
autentifice
în
aplica
ț
ia
client,
(pe
pagina
de
login),
ruta
paginii
(“http://localhost:8080/hito-server/rest/auth/”),
accesează
serviciul
de
pe
server,
din
cadrul
nivelului
de
serviciu,
la
clasa
ce
implementează
ruta
accesată.
Fiecare
rută
răspunde
unui
serviciu
separat
(în
majoritatea
cazurilor).
Serviciul
ș
tie
ce
anume
trebuie
să
facă
în
momentul
în
care
a
fost
făcut
un
request
pe
ruta
respectivă
ș
i
ce trebuie să întoarcă ca
ș
i răspuns aplica
ț
iei client. Aplica
ț
ia client, spre exemplu efectuează
F
igura 4.1.7
Hito rest-api
un
request
de
tip
HTTP
spre
server,
pe
o
anumita
rută.
Împreună
cu
acel
request
HTTP,
sunt
trimise
ș
i
datele
de
care
serviciul
are
nevoie
pe
server.
Aceste
date
sunt
trimise
la
nivelul
business.
Acest
lucru
este
vizibil
în
Figura
4.1.6.
Răspunsul
primit
este
memorat
în
cadrul
unui
obiect
de
transfer,
pe
scurt
DTO,
obiect
ce
urmează
sa
fie
parsat
aplica
ț
iei
client,
sub
format
JSON.
Format
ce
este
în
ț
eles
de
către
aplica
ț
ia
client.
Acest
format
JSON,
este
interpretat de client, iar mesajul este afi
ș
at pe UI utilizatorului.
F
igura 4.1.8
Structura modulelor Maven
Modulul cu numărul
ș
ase, este “hito-web_server”, după cum arată schema modulelor Maven,
în Figura 4.1.7, este de tipul “war” (Web Archive). Rolul acestui modul este de a împacheta
aplica
ț
ia cu extensia “war ”, facem acest lucru pentru a putea realiza un deploy aplica
ț
iei pe
un server, în cazul proiectului Hito, pe serverul WildFly.
//TODO
F
igura 4.1.9
Hito web_server
În
fi
ș
ierul
“web.xml”,
Figura
4.1.8,
avem
setările
pentru
framework-ul
Spring
ce
este
folosit
în
aplica
ț
ie.
Pe
liniile
14-16
este
pornit
efectiv
contextul
Spring
pe
server.
Între
liniile
18-30,
este
declarat
servletul
de
Spring,
prin
acest
lucru
se
specifică
unde
este
serviciul
web,
urmând
ca acesta să fie pornit automat atunci când este făcut deploy pe server.
F
igura 4.1.10
Configurări din cadrul serverului
4.1 Aplica
ț
ia Angular
Aplica
ț
ia
Angular
este
implementată
astfel
încât
ea
sa
interac
ț
ioneze
cu
utilizatorul.
Astfel
aplica
ț
ia
client
preia
date
de
la
un
serviciu
web,
aflat
pe
aplica
ț
ia
server,
ș
i
o
afi
ș
ează
utilizatorului pe UI.
Ca
ș
i
structură,
interfe
ț
ele
din
aplica
ț
ie
sunt
în
componente
separate
una
de
cealaltă,
după
cum
se
poate
vedea
în
Figura
4.1.1
(datorită
faptului
că
există
multe
componente
separate,
în
Figura
4.1.1
a
fost
decupată
doar
o
parte
spre
exemplificare).
Un
lucru
de
remarcat
este
faptul
că
interfe
ț
ele
suportă
redimensionarea,
astfel
aplica
ț
ia
este
utilizabilă,
atât
de
pe
smartphone,
tabletă
sau
web,
aplica
ț
ia
are
un
design
bazat
pe
“Responsive
Web
Design”.
Interfe
ț
ele
au
fost
implementate,
utilizând
ce-a
mai
noua
ș
i
stabilă
versiune,
Angular
6.
Aplica
ț
ia
client,
implementează
o
arhitectură,
care
la
baza
ei
permite
dezvoltatorului
să
reutilizeze sau să modifice mediul destul de u
ș
or, fără a afecta toată aplica
ț
ia.
Luând
aceste
lucruri
în
considerare,
avem
componenta
“top-bar”
ș
i
“side-panel”
care
sunt
refolosite
în
toată
aplica
ț
ia,
cu
remarca
că
există
doua
componente
“topbar”
dar
în
păr
ț
i
diferite,
iar
ele
nu
interac
ț
ionează
una
cu
cealaltă.
Acestea
se
află
în
directorul
“shared”,
“side-panel”
ș
i
“topbar”
în
“shared”
la
nivel
de
aplica
ț
ie,
iar
al
doilea
“topbar”,
în
“shared”
din
cadrul
modului
auth.
Fiecare
componentă
con
ț
ine
patru
fi
ș
iere:
una
cu
extensia
“.html”
în
care
se
află
ș
ablonul
paginii
web,
alt
fi
ș
ier
cu
extensia”.scss”
ce
con
ț
ine
cod
SCSS
care
la
runtime
este
transpilat
în
CSS,
acest
fi
ș
ier
se
ocupa
cu
stilizarea
ș
ablonului,
altul
cu
“.spec.ts”
în
care
sunt
realizate
teste
pentru
componente
respectivă,
iar
în
final
un
fi
ș
ier
cu
extensia
“.ts”
în care se afla logica (business logic) din cadrul componentei.
F
igura 4.1.1
Hito Component’s
Ceea
ce
face
ca
“auth”
sa
fie
un
modul
este
faptul
ca
are
fi
ș
ier
cu
extensia
“.module”.
În
fi
ș
ierul
“auth-routing. module.ts”
sunt
specificate
rutele
componentei/componentelor
dacă
este
cazul.
În
acest
fi
ș
ier
sunt
importate
din
angular
module
sau
func
ț
ionalită
ț
i
de
care
au
nevoie
componentele,
sunt
importate
de-asemenea
ș
i
componentele
propriu-zise.
Ca
ș
i
componentele,
exista
un
fi
ș
ier
“auth.module.spec.ts”
în
care
se
pot
verifica
anumite
func
ț
ionalită
ț
i.
Fi
ș
ierul
“auth.module.ts”
este
special
prin
faptul
că
aici
este
locul
unde
sunt
declarate
ca
ș
i
import-ur i
toate
componentele
din
modul,
sau
func
ț
ionali
ț
ă
ț
ile
din
Angular,
acestea
sunt
importate
în
“@NgModule”
ca
ș
i
“imports”,
iar
toate
componentele
sunt
declarate
tot
în
“@NgModule”
la
“declarations”,
urmând
ca
clasa
să
fie
exportată.
Structura
prezentata a fost utilizată la o mare parte din componentele create.
În
Figura
4.1.2,
putem
vedea
arhitectura
aplica
ț
iei
client.
Fiecare
modul
con
ț
ine
una
sau
mai
multe
componente,
un
layer
pentru
rute
(locul
unde
sunt
instan
ț
iate
respectivele
componente),
un
layer
de
logică
(service’s),
o
sec
ț
iune
de
con
ț
inut
comun
ș
i
reutilizabil
(shared)
la
nivel
de
modul.
Pot
exista
de
la
una
la
n
componente.
Fiecare
componentă
con
ț
ine
structura
deja
prezentată
anterior.
Un
ș
ablon,
un
fi
ș
ier
de
stilizare
ș
i
un
o
componentă
în
cadrul
căreia
se
fac
request-uri
de
tip
REST
spre
server.
După
cum
se
poate
vedea
în
diagramă,
pot
exista
mai
multe
module
în
cadrul
acelea
ș
i
aplica
ț
ii.
Modulele
sunt
de
fapt
funcționalitățile
aplica
ț
iei.
La
nivel
de
aplica
ț
ie
avem
un
director
cu
func
ț
ionalită
ț
i
comune,
utilizate
de
module
ș
i
este
opusul
modulului
Core,
astfel
aici
avem
instan
ț
e
noi,
fără
singletons.
Modulul
“MAIN
APPLICATION”,
există
separat
de
toate
datorita
faptului
că
fiecare
aplica
ț
ie
Angular
necesi tă
un
modul
de
main,
de
unde
aplica
ț
ia
să
fie
rulată.
Nivelul
de
“CORE”
este
folosit
pentru
a
separa
func
ț
ionalitatea
disponibilă
pentru
toate
celelalte
nivele.
În
cadrul
acestui
nivel,
se
află
doar
singleton-uri,
astfel
ca
tot
acelea
ș
i
instan
ț
e,
a
serviciilor
din Core să fie folosite în toată aplica
ț
ia.
F
igura 4.1.2
Hito Architecture
Ceea
ce
înseamnă
că,
modulul
Core
trebuie
importat
doar
de
Main
App
Module,
iar
în
rest
să
fie
importate
doar
func
ț
ionalită
ț
i
specifice
din
Core
Mod ule
(services
spre
exemplu).
Diferenta
dintre
acest
layer
ș
i
nivelul
de
Shared,
constă
în
faptul
că
la
nivelul
de
Shared,
este
creată
o
nouă
instan
ț
ă
pentru
fiecare
modul/caracteristica
(feature)
a
aplica
ț
iei
care
o
folose
ș
te.
Capitolul V
Utilizarea Aplica
ț
iei
Scopul
Hito
este
acela
de
a
veni
în
ajutorul
utilizatorului
în
activitatea
de
zi
cu
zi
a
acestuia.
Prin
func
ț
ionali tatea
lui,
Hito
livrează
unui
utilizator
(în
func
ț
ie
de
drepturi)
exact
ceea
ce
are
nevoie.
Astfel
avem
un
design
aerisit,
simplu,
intuitiv
ș
i
cel
mai
important
rapid
ș
i
func
ț
ional.
Hito
oferă
multe
avantaje
atunci
când
timpul
este
limitat,
iar
unele
lucruri
necesita
aten
ț
ie
ș
i
nu
pot
să
fie
amânate.
Reducerea
timpului
de
îndeplini re
a
unei
sarcini,
este
de
fapt
un
câ
ș
tig,
pentru
utilizato r,
timp
pe
care
îl
poate
dedica
altor
sarcini
mult
mai
semnificative.
După
cum
este
prezentat
la
început,
Hito
are
6
module
ce
se
ramifică
în
cadrul
domeniului
IT,
vezi Figura 5.1.
F
igura 5.1
Hito Application Module
Informa
ț
ia
afi
ș
ată
pe
UI,
vine
de
pe
serverul
aplica
ț
iei.
Aplica
ț
ia
dezvoltată
în
Angular
6
devine
client
pentru
un
serviciu
web
de
pe
server,
server
ce
a
fost
structurat
ș
i
dezvoltate
în
cadrul
companiei.
Utilizatorul,
interac
ț
ionează
cu
serviciul
web
de
pe
server,
prin
rutele
definite,
care
accesate,
trimit
serverului
un
request
pentru
ruta
respectivă.
Serverul
a
fost
conceput
astfel
încât,
informa
ț
ia
ce
urmează
sa
fie
trimisă
ca
ș
i
răspuns
pe
UI,
să
fie
anexata
unui
obiect,
iar
acesta
să
fie
trimis
spre
client,
în
cazul
de
fa
ț
ă
aplica
ț
ia
Angular.
În
partea de client, acel obiect este în
ț
eles
ș
i utilizat pentru informa
ț
ia de pe interfe
ț
e.
5.1 Descrierea Aplica
ț
iei
Aplica
ț
ia
clientul
este
implementată
având
un
design
intuitiv,
care
atrage,
dar
în
acela
ș
i
timp
un
design
simplu.
Pe
prima
pagina
a
aplica
ț
iei
avem
autentificarea
utilizatorilor.
Ț
inând
cont
ca
Hito
este
o
aplica
ț
ie
destinată
firmelor,
nu
este
nevoie
ca
un
utilizator
să
aibă
nevoia
de
a
se
înregistra.
Partea
de
înregistrare
este
făcută
în
baza
de
date,
iar
utilizatorul
are
posibilitatea
doar
de
a
face
logarea
în
aplica
ț
ie.
În
Figura
5.1.1
avem
prima
pagină
a
aplica
ț
iei.
F
igura 5.1.1
Hito
login page
În
partea
dreapta
sus,
avem
un
buton
denumite
“Help”
în
care
este
afi
ș
at
utilizatorului
informa
ț
ii
adi
ț
ionale
despre
ceea
ce
reprezintă
Hito.
În
cadrul
formularului
de
logare,
avem
o
singura
op
ț
iune
data
utilizatorului.
Aceea
de
schimbarea
parolei
în
cazul
în
care
aceasta
este
uitată.
Când
facem
click
pe
“Forgot
your
password?”
utilizatorul
este
redirec
ț
ionat
spre
o
alta
pagină în care avem resetarea parolei. În Figura 5.1.2 avem pagina de resetare.
F
igura 5.1.2
Hito
reset page
În
cadrul
acestei
pagini
avem
ca
ș
i
input,
adresa
de
e-mail
a
utilizatorului.
Butonul
de
trimitere
(“SEND”)
este
dezactivat
până
în
câmpul
de
input
este
introduse
caractere
ce
au
pettern-ul
“@gsdgroup.net”.
Dacă
condi
ț
ia
este
satisfăcută,
butonul
devine
activ,
putând
astfel să fie trimise pe adresa utilizatorului detalii ce privesc resetarea parolei. Figura 5.1.3
F
igura 5.1.3
Hito
reset password instructions
Vedem
că
avem
datele
sunt
introduse
corect,
iar
butonul
de
trimitere
este
activ.
Atunci
când
este
apăsat,
utilizatorul
este
în
ș
tiin
ț
at
că
instruc
ț
iunile
de
resetarea
parolei
au
fost, trimise printr-un mesaj afi
ș
at pe UI. Figura 5.1.4
F
igura 5.1.4
Hito
reset password
Avem
ș
i o redirec tare spre pagina de login, prin “Back to login page”. Revenind la
pagina de logare, prezentăm următoarele feature. Validarea informa
ț
iei înainte de a face
request cu datele introduse spre server. Dacă butonul de “LOGIN” este apăsat, iar câmpuri nu
a fost introdu absolut nimic, request-ul către server nu este făcut, iar un mesaj este afi
ș
at
utilizatorului.
F
igura 5.1.5
Hito login validation
La
fel
este
ș
i
în
cazul
în
care
doar
într-un
câmp
sunt
introduse
date.
Am
specificat
faptul
ca
interfe
ț
ele
sunt
intuitive.
Dacă
privim
atent,
la
fiecare
câmp
din
aplica
ț
ie
avem
un
label
în
care
este
specificat
ce
anume
este
acel
field,
sau
mai
exact
ce
date
se
pot
introduce.
Pe
lângă
astea
iconi
ț
ele
din
cadrul
aplica
ț
iei
sunt
ș
i
ele
de
real
ajutor,
ele
au
fost
special
alese
pentru a face interfe
ț
ele u
ș
or de folosit. Figura 5.1.5.
Există
validări
în
cadrul
serverului
unde
este
verificat
dacă
exista
sau
nu
utilizatorul
introdus
pe
interfa
ț
a.
în
cazul
în
care
nu
există
acel
utilizator
sau
date
introduse
sunt
invalide,
este trimis un mesaj ce este afi
ș
at pe interfa
ț
ă. În Figura 5.1.6 avem acest lucru prezentat.
Figura 5.1.6
Validation Messages form server
Dacă
cerin
ț
ele
sunt
îndeplinite,
iar
utilizatorul
este
autentificat,
acesta
este
redirec
ț
ionat
spre
pagina
de
“dashboard”.
Ț
inem
sa
subliniem
faptul
că
rutele
aplica
ț
iei
nu
pot
să
fie
accesate
fără
a
exista
un
utilizator
autentificat,
existent
pe
sesiune.
Dacă
se
încearcă
accesarea unei rute fără a fi logat, utilizatorul este redirec
ț
ionat spre pagina de autentificare.
Fiecărui
utilizator
are
anumite
drepturi
la
anumite
module
ale
aplica
ț
iei.
Avem
în
DB
fiecare
utilizator
cu
drepturile
lui
pe
anumite
module.
Iar
la
autentificare,
utilizatorului
îi
sunt
aduse
din
Db
lista
cu
meniurile
la
care
are
acces.
în
Figura
5.1.6
avem
utilizatorul
“admin”
care
are
drepturi
peste
tot
în
aplica
ț
ie,
după
logare,
acesta
este
redirec
ț
ionat
spre
pagina
de
dashboard,
având
toate
modulele
aplica
ț
iei.
În
cadrul
paginii
de
dashboard
(afi
ș
ată
to
ț
i
utilizatorilor) avem o mica prezentare a Hito.
F
igura 5.1.7
Hito admin rights
Remarcăm
faptul
că
în
col
ț
ul
din
stânga
sus
avem
numele
utilizatorului
logat
ș
i
op
ț
iunea
de
dropdown.
Figura
5.1.8.
La
“Profile”
după
cum
spune
ș
i
numele
avem
profilul
utilizatorului,
cu
datele
lui.
//TODO
diagram.
La
“Logout”
avem
op
ț
iunea
de
a
ie
ș
i
din
aplica
ț
ie, fiind redirec
ț
ionat la pagina de login, iar utilizatorul est e scos din sesiune.
Figura 5.1.8
Admin user options
În
cadrul
listei
de
meniuri,
avem
posibilitatea
de
a
afi
ș
a
doar
iconi
ț
ele
modulelor.
Figura 5.1.9.
Figura 5.1.9
Menu bar option
Deoarece
lista
cu
meniuri
con
ț
ine
module
cu
submeniuri
avem
implementate
două
variante.
Una
în
care
meniu
este
full,
iar
la
meniul
cu
submeniuri,
la
click
pe
acel
meniu,
o
să
fie afi
ș
ate
ș
i restul de submeniuri sub meniul selectat. Figura 5.1. 10.
Figura 5.1.10
Menu with submenus
Lista
are
un
feature
în
care
la
hover
pe
anumit
meniu,
acesta
î
ș
i
schimba
culoarea
ș
i
iconi
ț
a.
Puteam
vedea
asta
ș
i
în
Figura
5.1.10
unde
la
click
sau
hover
pe
meniul
“Reports”,
modulul
î
ș
i
schimba
culoarea
din
gri
în
albastru,
iar
textul
ș
i
iconi
ț
a
se
schimba
ș
i
ele
în
alb.
A
doua
variantă
este
atunci
când
lista
de
module
este
restrânsă
doar
la
iconi
ț
ele
meniurilor,
la
hover
pe
anumit
module,
dacă
acesta
are
submeniuri,
să-i
fie
afi
ș
ate
într-un
dropdown
automat.
În
Figura 5.1.11 puteam vedea acest lucru.
Figura 5.1.11
Reports submenus
Pentru
a
fi
de
ajutor
ș
i
în
cadrul
acestui
meniu,
pe
lângă
acest
lucruri
a
fost
implementat
ș
i
ca
atunci
când
este
hover
pe
un
anumit
buton,
meniu,
submeniu,
etc.
săgeata
de pe ecran sa î
ș
i schimbe înfă
ț
i
ș
area.
Revenind
la
ideea
ca
utilizatori
au
drepturi
diferite,
exemplificăm
în
Figurile
5.1.12
ș
i
Figura 5.1.13 alte două cazuri în care lista de meniuri este diferita în func
ț
ie de utilizator.
Figura 5.1.12
Normal User Module List
În
Figura
5.1.10
avem
cazul
utilizatorilor
ce
sunt
angaja
ț
i
pe
post
de
dezvoltatori.
Ace
ș
tia
au
acces
la
“dashboard”,
“employees”,
“leave
&
time
off”
ș
i
la
“time
tracking”.
în
Figura 5.1.11 avem cazul utilizatorilor angaja
ț
i pe un pot de HR.
Figura 5.1.13
HR User Module List
După cum vedem utilizatorul de tip HR, are drepturi
ș
i la modulul cu Reports, care
are submeniuri aferente.
//TODO responsive on smartphones and tablest
Bibliografie
[1] Defini
ț
ia unui studiu d e pia
ț
ă: http://www.studii-piata.ro/defin itie.htm (data accesării:
20.03.2018)
[2] Etapele unui studiu de pia
ț
a: http://www.studii-piata.ro/etape.htm (data accesării:
20.03.2018)
[3] OrangeHRM: https://www.orangehrm.com/ (accesat la data de 30.03.2018)
[4] Mystaff : http://www.smartree.com/portfolios/administrare-personal/ (data accesării:
20.03.2018)
[5] Wizrom: http://www.wizrom.ro/ro/ (data accesării: 20.03.2018)
[6] Optimoo: http://www.optimoo.ro/ (data accesării: 20.03.2018)
[7] SVTech: http://www.svtech.ro/software-pontaj/ (data accesării: 20.03.2018)
[8] Colorful: https://www.colorful.hr/ (data accesării: 20.03.2018)
[9] Defini
ț
ia unui studiu d e pia
ț
ă: http://www.studii-piata.ro/defin itie.htm (data accesării:
30.03.2018)
[10] Defini
ț
ia lmbajului d e programare Java:
https://ro.wikipedia.org/wiki/Java_(limbaj_de_programare) (data accesării: 30.04.2018)
[11] Lucrul cu baze de date in Java:
http://upm.ro/intranet/ecalin/cd_educational/cd/javac/cap6.htm (data accesării: 30.04.2018)
[12] TypeScript: https://www.tutorialspoint.com/typescript/typescript_overview.htm (data
accesării: 02.06.2018)
[13] HTML5:https://ro.wikipedia.org/wiki/HTML5 (data accesării: 01.06.2018)
[14] HTML5:https://ro.wikipedia.org/wiki/HTML5 (data accesării: 01.06.2018)
[15] Bootstrap: https://en.wikipedia.org/wiki/Bootstrap_(front-end_framework) (data
accesării: 02.06.2018)
[16] ng-bootstrap: https://alligator.io/angular/ng-bootstrap/ (data accesării: 02.06.2018)
[17] MySQL: https://ro.wikipedia.org/wiki/MySQL (data accesării: 12:05.2018)
[18] Tutoriale SQL: http://www.techit.ro/tutorial_sql2.php (data accesării: 12.05.2018)
[19] Hibernate framework: http://elf.cs.pub.ro/idp/laboratoare/lab-08 (data accesării:
12:05:2018)
[20] Despre Hibernate:
https://www.todaysoftmag.ro/article/73/analiza-mecanismului-object-relational-mapping-orm
-cu-exemplificari-hibernate (data accesării: 12.05.2018)
[21] Spring Framework Overview:
https://docs.spring.io/spring/docs/current/spring-framework-reference/overview.html (data
accesării: 13.05.2018 )
[22] Spring Framework: https://projects.spring.io/spring-framework/ (data accesării:
13.05.2018)
[23] REST: https://en.wikipedia.org/wiki/Representational_state_transfer (data accesării:
19.05.2018)
[24] Servicii REST:
https://www.todaysoftmag.com/article/81/restful-web-services-folosind-jersey (data
accesării: 19.05.2018)
[25] Creating a simple REST:
https://shareurcodes.com/blog/creating%20a%20simple%20rest%20api%20in%20php (data
accesării: 10.05.2018)
[26] RESTful Java:
https://crunchify.com/how-to-create-restful-java-client-with-jersey-client-example/ (data
accesării: 19.05.2018)
[27] Jersey: https://en.wikipedia.org/wiki/Project_Jersey (data accesării: 10.06.2018)
[28] Jersey framework: https://jersey.github.io/ (data accesării: 10.06.2018)
[29] Restlet: https://restlet.com/modules/client/ (data accesării: 10.06.2018)
[30] Codarea/decodarea datelor: http://codare-date.cpf.ro/index.php (data accesării:
22.05.2018
[31] SHA-3: https://en.wikipedia.org/wiki/SHA-3 (data accesării: 23.05.2018)
[32] Logging Services: https://logging.apache.org/log4j/1.2/ (data accesării: 02.06.2018)
[33] AVAJAVA Web Tutorials:
http://www.avajava.com/tutorials/lessons/what-is-log4j-and-how-do-i-use-it.html (data
accesării: 02.06.2018)
[34] Eclipse: https://en.wikipedia.org/wiki/Eclipse_(software)#Architecture (data accesării:
04.06.2018)
[35] Checkstyle: https://en.wikipedia.org/wiki/Checkstyle (data accesării: 05.06.2018)
[36] Checkstile: http://checkstyle.sourceforge.net/ (data accesării: 05.06.2018)
[37] Visual Studio Code Official Documentation: https://code.visualstudio.com/docs (data
accesării: 05.06.2018)
[38] Visual Studio Cod: https://en.wikipedia.org/wiki/Visual_Studio_Code (data accesării:
06.06.2018)
[39] WildFly: https://en.wikipedia.org/wiki/WildFly (data accesării: 06.06.2018)
[40] Future Hosting:
https://www.futurehosting.com/blog/jboss-vs-tomcat-choosing-a-java-application-server/
(data accesării: 06.06.2018)
[41] Bitbucket: https://www.atlassian.com/git/tutorials/what-is-version-control (data
accesării: 06.06.2018)
[42] Controlul versiunulor: https://ro.wikipedia.org/wiki/Controlul_versiunilor (data
accesării: 06.06.2018)
[43] Git: https://ro.wikipedia.org/wiki/Git (data accesării: 06.06.2018)
[44] BitBucket:https://en.wikipedia.org/wiki/Bitbucket (data accesării: 06.06.2018)
[45] Jira (software): https://en.wikipedia.org/wiki/Jira_(software) (data accesării: 14:06.2018)
[46] Jira: https://ro.atlassian.com/software/jira (data accesării: 14.06.2018)
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Specializarea: Informatică [617284] (ID: 617284)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.