Cuprins ………………………….. ………………………….. ………………………….. ………………………….. 1 1…. [625516]

1

Cuprins
Contents
Cuprins ………………………….. ………………………….. ………………………….. ………………………….. 1
1. Introd ucere (1.5 – 5 pagini) ………………………….. ………………………….. ……………………….. 3
2. Noțiuni t eoretice (10 -30 pagini) ………………………….. ………………………….. …………………. 3
2.1 JAVA Enterprise Edition 8 ………………………….. ………………………….. ………………….. 4
2.1.1 Generalitati ………………………….. ………………………….. ………………………….. ……… 4
Arhitectura ………………………….. ………………………….. ………………………….. ………………. 4
2.1.2 Componentele Aplicației ………………………….. ………………………….. ……………….. 6
2.1.3 Containere ………………………….. ………………………….. ………………………….. ………. 7
2.1.4 Baze de date ………………………….. ………………………….. ………………………….. ……. 7
2.1.5 Java Persistence ………………………….. ………………………….. ………………………….. .. 8
2.1.6 JavaMail ………………………….. ………………………….. ………………………….. …………. 8
2.1.7 Arhitectura conectorului Java EE ………………………….. ………………………….. ……. 8
2.1.8 Servicii de Securitate ………………………….. ………………………….. …………………….. 9
2.2 Managerul de tranzacții ………………………….. ………………………….. ……………………….. 9
2.2.1 Componentele Web ………………………….. ………………………….. …………………….. 10
2.2.2 Cerințe de tranzacție ………………………….. ………………………….. ……………………. 11
2.2.3 Suportul tranzacțional J DBC ………………………….. ………………………….. ………… 11
2.3 Resurse, denumire si injecții ………………………….. ………………………….. ………………. 12
2.3.1 Contextul denumirii ………………………….. ………………………….. ……………………. 12
2.3.2 Adnotații si injecție ………………………….. ………………………….. …………………….. 13
2.4 Persistence ………………………….. ………………………….. ………………………….. …………… 13
2.4.1 Referințe ………………………….. ………………………….. ………………………….. ……….. 13
2.4.2 Injecția persistențelor ………………………….. ………………………….. ………………….. 14

2
2.4.3 Programarea interfețelor ………………………….. ………………………….. ………………. 14
2.4.4 Declararea unei unități de persistență ………………………….. ………………………… 14
2.4.5 Responsabilități ………………………….. ………………………….. ………………………….. 15
2.5 Hibernate ………………………….. ………………………….. ………………………….. …………….. 15
2.5.1 Hibernate ca soluție a persistenței ………………………….. ………………………….. …. 16
2.5.2 Maparea ………………………….. ………………………….. ………………………….. ………… 17
2.5.3 Integrarea și configurarea ………………………….. ………………………….. …………….. 17
2.5.4 Entități, clase și denumiri ………………………….. ………………………….. …………….. 18
2.5.5 Salvarea entităților ………………………….. ………………………….. ……………………… 19
2.5.6 Încărcarea entităților ………………………….. ………………………….. ……………………. 20
2.5.7 Actualizarea entităților ………………………….. ………………………….. ………………… 21
2.5.8 Ștegerea entităților ………………………….. ………………………….. ……………………… 21
2.6 Hi bernate Query Language(HQL) ………………………….. ………………………….. ………. 22
2.6.1 UPDATE ………………………….. ………………………….. ………………………….. ………. 23
2.6.2 DELETE ………………………….. ………………………….. ………………………….. ……….. 23
2.6.3 I NSERT ………………………….. ………………………….. ………………………….. ………… 23
2.6.4 SELECT ………………………….. ………………………….. ………………………….. ……….. 24
2.7 HTML ………………………….. ………………………….. ………………………….. ………………… 24
3. Descrierea formala a aplicatie i (3 – 30 pagini) ………………………….. ……………………….. 25
3.1 Arhitectura ………………………….. ………………………….. ………………………….. …………… 25
3.2 Use case (fully dressed) ………………………….. ………………………….. …………………….. 25
4. Descrierea aplicatiei (20 – 40 pagini) ………………………….. ………………………….. ……….. 26
4.1 Administrarea ………………………….. ………………………….. ………………………….. ………. 26
5. Concluzii si dezvoltari ulterioare (1 .5 – 4 pagini) ………………………….. ……………………. 27
5.1 Concluzii ………………………….. ………………………….. ………………………….. …………….. 27
5.2 Dezvoltari ulterioare ………………………….. ………………………….. ………………………….. 27
Bibliografie ………………………….. ………………………….. ………………………….. ………………….. 28

3
Bibliography ………………………….. ………………………….. ………………………….. …………………. 28

1. Introd ucere (1.5 – 5 pagini )

Aplica ția prezentă are scop ul de a ajuta orice persoana care vrea s ă închirieze
un teren de sport. Clientul care v -a folosi aplica ția va putea c ăuta terenul disponibil î n fun cție
de timp ul lui l iber, sau în fun cție de terenul pe care vrea sa practice un sport. C lientul nu va
mai fii ne voit s ă sune mai mul ți administratori p ână c ând își va g ăsi terenul dorit. As tfel, se
simplific ă și munca administrator ilor, îș i pot verifica oricând rezerv ările care au fost
înregistra te folosind aplicația și va putea face și el or icând o rezervare .
Tehnologii uti lizate si de ce
Structura lucrarii: In capitolul 2 am realizat un rezumat al fundam teoretice ale tehn
utili. In cap 3 avem o descriere formala a apl. Cap 4 contine descrierea aplica
Actori (lista tipurilor de utilziatori – Admin, Prof, Student)
Use case (pe scurt, o lista cu ce stie sa faca aplicatia)
Ne propunem sa realziam urmatoarele:
Admin poate sa:
– sa gestiunoneze userii
– Sa reseteze parole
Student:
– Sa vada note
– Sa trimita problem e la teste
2. Noțiuni teoretice (10 -30 pagini)

4
2.1 JAVA Enterprise Edition 8
Platforma Java, Enterprise Edition (Java EE), oferă o platformă pentru
dezvoltarea aplicațiilor web. Aceste aplicații sunt de obicei semnate ca aplicații multinivel, cu
un nivel de front-end constând într -un cadru web, un nivel de mijloc care asigurară
securitățiile și a tranzacțiile, precum și un nivel de backend care oferă conectarea la o bază de
date.
Platforma Java EE definește API -urile pentru diferite componente din fiecare niv el și
furnizează, de asemenea, unele servicii suplimentare, cum ar fi d enumirea, injecția și
gestionarea resurselor care se întind pe toată platforma. Aceste componente sunt gestionate în
containere care oferă suport pentru rula re. Containerel e oferă o ve dere amplă a API -urilor
Java EE care stau la baza componentelor aplicației. Componentele aplicațiilor Java EE nu
interacționează niciodată direct cu alte componente ale aplicației Java EE. Se folosesc de
protocoalele și metodele containerului p entru intera cțiunea între ele și cu serviciile
platformei. Interpunerea unui container între componentele aplicației și serviciile Java EE
permite containerului să injecteze în mod transparent serviciile solicitate de componentă, cum
ar fi g estionarea tran zacțiilor, v erificările de securitate sau colectarea resurselor. Acest model
bazat pe container și abstractizarea resurselor permit platformei să realizeze sarcini comune
de infrastructură în locul programatorului. Fiecare componentă este d efinită separat ă care
descr ie API-ul, javadocs -urile și comportamentul de rulare preconizat.

2.1.1 Generalitati
Arhitectura
Relațiile necesare ale e lementelor arhitectura le ale platformei Java EE sunt
prezentate în figura de mai jos :

5

Aceast ă figură arată relațiile logice ale elementelor , nu este menit ă să implice
o partiționare fizică a elementelor .
Containerele, notate prin dreptunghiuri separate, sunt medii de rulare Java EE care
furnizează serviciile necesare componentelor aplicației reprezent ate în jumătatea superioară a
dreptunghiului. Serviciile furnizate sunt notate de casetele din jumătatea in ferioară a
dreptunghiului. De exemplu, clientul Container de aplicații furnizează API -uri Java Message
Service (JMS) pentru “Aplication Client ”, prec um și celelalte servicii re prezen tate. Toate
aceste servicii s unt explicate mai jos .
Săgețile reprezintă accesul necesar la alte părți ale platformei Java EE. Containerul
„Application Client ” oferă clienților aplicației acces direct la baza de date Java EE necesară

6
prin API -ul Java pentru conectivitate cu sistemele de baze de date, API -ul JDBC . Acces
similar la bazele de date este oferit paginilor JSP, aplicațiilo r JSF și servlet -urilor de către
Web Container, și la întreprinderea de fasole de către contain erul EJB.
API-urile Platfor mei Java Standard Edition (Java SE), sunt acceptate de mediile de
rulare Java EE pentru fiecare tip de componentă a aplicației.
2.1.2 Componentele Aplica ției
Mediul de rulare Java EE definește patru tipuri de componente de aplic ație pe
care trebuie să le suport e un produs Java EE:
• Aplica țiile client sunt p rograme de limbaj de pro gramare Java, care sunt de
obicei programe GUI (Interfa ță grafic ă) execut ate pe un computer desktop. Aplic ațiile client
oferă utilizatorului o experien ță similar ă cu cea a aplica țiilor native si au acces la toate
facilit ățile nivelului interme diar Java EE .
• Applet-urile sunt componente GUI care se execută de obicei într -un browser web,
dar se pot executa într -o varietate de alte aplicații sau dispozitiv e care acceptă modelul de
program are a apple t-ului. Applet -urile pot fi utilizate pentru a furniz a o interfață de utilizator
puternică pentru aplicațiile Java EE. Pagini le HTML simple pot fi de asemenea utilizate
pentru a furniza o interfață de utilizator pentru aplicațiile Java EE.
• Servlet-urile , paginile JSP , aplicațiile JSF , filtrele și ascultătorii de evenimente
web se execută de obicei într -un container web și pot răspunde la solicitările HTTP de la
clienții web. Servlet -urile, paginile JSP, aplicați ile JSF și filtrele pot fi utilizate pentru a
genera pagini HTML care sunt inter fața utiliz atorului unei aplicații. De asemenea, pot fi
utilizate pentru a genera date XML sau alte formate care sunt consumate de alte componente
ale aplicației. Servlet -urile, paginile create cu tehnol ogia JavaServer Pages sau tehnologia
JavaServer Faces, filtrele web și ascultătorii de evenimente web sunt menționate colectiv în
această specificație ca „componente web”. Aplicațiile web sunt compuse din componente
web și alt e date, cum ar fi paginile HTM L. Com ponentele web se execută într -un container
web. Un server web include un container web și alte suporturi de protocol, asistență de
securitate și așa mai departe, după cum se cere în specificațiile Java EE.
• Com ponentele En terprise JavaBeans (EJB) se execu tă într -un mediu gestionat
care acceptă tranzacții. EJB-urile conțin de obicei logica de afaceri pentru o aplicație Java
EE. EJB-urile pot furniza direct servicii web utilizând protocolul SOAP / HTTP.

7
2.1.3 Container e
Cont ainerele oferă suport pentr u rulare pentru componentele apli cației Java
EE.
Containerele oferă o vedere amplă a API -urilor Java EE care stau la baza
componentelor aplicației. Componentele aplicațiilor Java EE nu interacționează niciodată
direc t cu alte componente ale aplicației Java EE. E le folosesc protocoalele și metodele unui
container pentru interacțiunea între ele și cu serviciile platformei. Interpunerea unui container
între componentele aplicației și serviciile Java EE permite containerulu i să in jecteze în mod
transparent serv iciile solicitate de componentă, cum ar fi gestionarea tranzacțiilor, verificările
de securitate și colectarea resurselor .
O aplica ție tipică Java EE va furniza un container pentru fiecare tip de componentă a
aplicației: cont ainer client aplicație, contain er app let, container pentru component a web și
container pentru EJB .
Containerele trebuie să furnizeze un mediu de rulare compatibil cu Java, definit de
Platform a Java Standard Edition . Containerul de applet poate utiliza prod usul Java Plugin
pentru a furni za acest mediu sau îl poate furniza în mod nativ.
La baza unui container Java EE se află serv erul din care face parte. Un furnizor de
produse Java EE implementează în mod obișnuit funcționalitatea serverului Java EE utilizând
o infrastructură de procesare a tranzacțiilor existente, în combinație cu tehnologia Java SE.
Funcționalitatea clientului EE este construită de obicei pe tehnologia Java SE.
2.1.4 Baze de date
Platforma Java EE necesită o bază de date accesibilă prin API -ul JDBC pentru
stocarea date lor. Baza de date este accesibilă din componente web și din comp onente ale
aplicației client . Baza de date nu trebuie să fie acces ibilă de la appleturi. Java EE trebuie să
furnizeze o preconfigura ție, o sursă de date implicită , pentru accesul la baza de date de către
aplicație .
API-ul JDBC este API -ul care realizeaz ă conexiunea cu sistem ele de baze de date
relaționale. API -ul JDBC are două părți: o interfață la nivel de aplicație folosită de
componentele aplicației pen tru a accesa o bază de date și o interfață a f urnizorului de serv icii
pentru a atașa un dri ver JDBC la platforma Java EE. As istența pentru interfața furnizorului de
servicii nu este necesară în produsele Java EE. În schimb, driverele JDBC ar trebui să fie
ambalate ca adaptoare de re surse care utilizea ză facilitățile conector ului API pentru a

8
interfața cu un produs Java EE. API -ul JDBC este inclus în Java SE, dar această specificație
include cerințe suplimentare pentru driverele de dispozitiv JDBC.
2.1.5 Java Persistence
API-ul Java Persistence este AP I-ul standard pentru gestionarea persistenței și
a mapării obiectelor / relațiilor. Acesta oferă un obiect / facilitate de mapare relațională
pentru a gestiona o bază de date relațională. API-ul Java Persis tence trebuie să fie acceptată
în Java EE. Poate f i folos it și în mediile Java SE.
2.1.6 JavaMa il
Multe aplicații necesită posibilitatea de a trimite notificări prin e -mail, astfel încât
platforma Java EE include API -ul JavaMail împreună cu furni zorul de servi cii JavaMail care
permite u nei componente a aplicației să trimită un mail . API -ul JavaMail are două părți: o
interfață la nivel de aplicație folosită de componentele aplicației pentru a trimite poștă și o
interfață a furnizorului de servicii utilizată la n ivelul Java EE SPI.
2.1.7 Arhitectura co nector ului J ava EE
Arhitectura Connector este un Java EE SPI care permite adapto arelor de resurse
accesul la Sistemele de Informații Enterprise (EIS) să fie conectate la orice prod us Java EE.
Arhitectura conectorului definește un set standard de contracte la niv el de sistem între un
server Java EE și un adaptor de resurse.
Contractele standard includ:
• Un contract de gestionare a conexiunilor care permite unui server Java EE să se
cone cteze la un EIS de bază și mai departe să permită componentelor aplicației să se
conecteze la acel EIS. Acest lucru duce la un mediu de aplicații scalabil care poate susține un
număr mare de clienți care necesită acces la sistemele EIS.
• Un contract de gestion are a tranzacțiilor între adminis tratorul de tranzacții și un EIS
care suportă accesul tranzacțional la managerii de resurse EIS. Acest contract permite unui
server Java EE să utilizeze un administrator de tranzacții pentru a gestiona tranzacțiile pe mai
mulți manageri de resurse. Acest c ontract acceptă, de asemenea, tranzacți ile care sunt
gestionate de un manager de resurse EIS , intern, fără a fi necesară implicarea unui manager
de tranzacții externe.
• Un contract de securitate care permite accesul securizat la un EIS. Acest contr act
oferă suport pentru un mediu de aplicații sigur, care reduce amenințările de secu ritate pentru
EIS și protejează informați ile valoroase gestionate de EIS .

9
• Un contract de gestionare a thread -urilor care permite unui ad aptor de resurse să
delege munca în alte thread -uri și permite serverului de ap licații să gestioneze un grup de fire
de execuție . Adaptorul de resurse poate controla contextul de securitate și contextul de
tranzacție utilizat de firul lucrător .
• Un contract care permi te unui adaptor de r esurse să livreze mesaje către altă resursă
independent de stilul specific de mesagerie . Acest contract servește, de asemenea, ca contr act
standard de conectare a furnizorului de mesaje care permite conectarea unui furnizor de
mesaje la orice server Java E E print r-un adaptor de resurse.
• Un contract care permite unui adaptor de resurse să propage un context de tranzacție
importat pe serve rul Java EE astfel încât interacțiunile sale cu serverul și orice componente
ale aplicației să facă parte din tranzacția import ată. Acest contract păstrează proprietă țile
ACID (atomicitate, consistență, iz olare, durabilitate) ale tranzacției importate.
• Un contract opțional care furnizează o interfață de comandă generică între un
program de aplicație și un adaptor de resur se.
2.1.8 Servicii de Securitate
Serviciul de autentificare și autorizare Java (JAAS) permite serviciilor să
autentifice și să aplice controale de acces utilizatoril or. JAAS i mplementează o versiune Java
a cadrului standard PAM (Pluggable Authentication Module ) și acceptă autorizarea bazată pe
utilizator. Contractul de autorizare , servicii și de furnizor Java pentru containere (JACC)
definește un contract într e un server de aplicații Java EE și un furnizor de servicii de
autorizare, care permite furnizo rilor de servi cii de autorizare să se conecteze personalizat la
orice produs Java EE. Interfața furnizorului de servicii de autentificare Java pentru containere
(JAS PIC) definește un SPI prin care furnizorii de autentificare care implementează
mecanisme de autent ificare a mesajelor pot fi integrați în containerele sau rulările de
procesare a mesajelor client sau server. API EE Security Java folosește JASPIC, dar oferă un
SPI mai ușor de utilizat pentru autentificarea utilizatorilor de aplicații web și defin ește AP I-
urile de identitate pentru autentifica re și autorizare.
2.2 Managerul de tranzacții
Un produs Java EE care include atât un container servlet cât și un container
EJB trebuie să susțină o aplicație tranzacțională care cuprinde com binații de componente de
aplicație web care accesează mai multe boabe de întreprindere în cadrul unei singure
tranzacții. Dacă produsul Java EE include și suport pentru specificația conectori lor, fiecare

10
componentă poate achiziționa, de asemenea, una sau m ai mult e conexiuni pentru a accesa
unul sau mai mulți manageri de resurse tranzacționale.
De exemplu, în figura de mai jos , arborele de apeluri pornește de la un servlet sau o
pagină JSP care ac cesează mai multe boabe de întreprindere, care la rândul lor p ot acce sa alte
boabe de întreprindere. Componentele accesează man agerii de resurse prin con exiuni.

Furnizorul de componente de aplicație specifică, folosind o combinație de API -uri de
marcare a tranzacțiilor programatice și declarative, modul în care pla tforma trebuie să
gestioneze tranzacțiile în numele aplicației.
De exemplu, aplicația poate necesita ca toate componentele din figur ă să acceseze
resurse ca parte a unei singure tranzacții. Furn izorul platformei trebuie să ofere capacitățile
tranzacție i pentru a susține un astfel de scenari u.
2.2.1 Componentele Web
Comp onentele web pot demarca tranzacțiile folosind interfața
javax.transaction.UserTransaction sau interceptorii tranzacționali, care sunt definiți în
specificația JTA. Aceștia pot accesa mai mul ți mana geri de resurs e și pot invoca mai multe

11
boabe de întreprin dere în cadrul unei singure tranzacții. Contextul tranzacției specificat este
propagat automat către boaba întreprinderii și admi nistratorii resurselor tranzacționale.
Rezultatul propagării p oate fi supus atri butelor tranzacției cu boaba întreprinderii (de
exemplu, o b oabă poate fi solicitată să utilizeze Tranzacții gestionate de conținut).
Ascultătorii de evenimente și aplicațiile de actualizare a aplicațiilor web nu trebuie să
înceapă tranza cții fo losind int erfața sau interceptoarele tranzacției
javax.tra nsaction.UserTransaction. Filtrele Servlet pot u tiliza resurse tranzacționale în
metodele lor doFilter, dar nu ar trebui să utili zeze resurse tranzacționale în metodele oricăror
obiecte utili zate pe ntru a înf ășura obiecte de solicitare sau de răspuns.
2.2.2 Cerin țe de tranzacț ie
Platforma Java EE trebuie să îndeplinească următoarele cerințe:
• Platforma Java EE trebuie să furnizeze un obiect care să implementeze inte rfața
javax.transaction.Use rTrans action la toate componentele web. Platforma trebuie să publ ice
obiectul UserTransaction în spațiul de nume Java Naming and Directory Interface (JNDI)
disponibil pentru componentele web su b numele java: comp / UserTransact ion.
• Platforma Java EE tre buie s ă furnizeze clase care implementează interceptoarele
tranza cționale, așa cum sunt definite de specificația JTA.
• Dacă o componentă web invocă o boab ă de întreprindere dintr -un thread asoc iat cu o
tranzacție JTA, platforma Java EE trebuie să propage contex tul tranzacției cu boaba
întreprinderii. Dacă boaba întrepr inderii țintă va fi invocat ă în acest context de tranzacție sau
nu este determinat de regulile definite în specificația EJB.
• Dacă o componentă web accesează un ad ministrator de resurse tran zacționale dintr –
un thread asociat cu o tranzacție JTA, platforma Java EE trebuie să se asigure că accesul la
resursă este inclus ca parte a tranzacției JTA.
• Dacă o componentă web creează u n thread, platforma Java EE trebuie să se asigure
că thread -ul no u creat nu este asociat cu nicio tranzacție JTA .
2.2.3 Suportul t ranzac țional JD BC
Un produs Jav a EE trebuie să accepte o bază de date tehnologică JDBC ca manager
de resurse tranzacționale. Plat forma trebuie să permită accesul AP I tranzacțional JDBC de la
componente web și boabele enterprise.
Trebuie să fie posibil să a ccesați baza de date tehnol ogică JDBC din mai multe
componente ale aplicației în cadrul unei singure tranzacții. De exemplu, un s ervlet poate dori

12
să înceapă o tran zacție, să acceseze o bază de date, să invoce o boabă de întreprindere care
accesează baza de date a aceleia și tranzacții și, în final, să angajeze tranzacția.
Un produs Java EE trebuie să furnizeze un manager de tranzacț ii care este capabil să
coordoneze operațiuni de angajare în mai multe baze de date JDBC compatibile cu XA. Dacă
un driver JDBC acceptă interfețele XA ale API -ului tranzacții Java (în pachetul
javax.transaction.xa), atunci produsul EE trebuie să fie capabi l să utilizeze interfețele XA
furni zate de driverul JDBC pentr u a realiza operațiuni de angajare . Produsul Java EE poate
descop eri capacitățile XA ale driverelor JDBC prin mijloace specifice produsului, deși în
mod normal astfel de drivere JDBC ar fi livra te ca adaptoare de resurse folosind conectorul
API.

2.3 Resu rse, denumire si injecț ii
Aici vo i descrie modul în care aplicații le declară dependen țe de resursele externe și
parametrii de configurare și modul în care acele elemente sunt re prezentate în sistemul de
denumire Java EE și pot fi injectate în componente ale aplicați ei. Aceste cerințe se bazează pe
adnotări definite în sp ecificația Java Metad ate și caracteristici definite în specificația Java
Naming and Directory Interface (JNDI) .
Cerințele definite în acest capi tol abordează următoarele d ouă probleme:
• Asamblatorul de aplicații și dezvol tatorul ar trebui să poată pers onaliza
comportamentul unei aplicații fără a accesa codul sursă al aplicației. În mod obișnuit, aceasta
va impli ca specificarea valorilor parametri lor, conectarea la resurse externe ș.a. De scrierea
implementării asigură această capac itate.
• Aplicațiile tre buie să poată acc esa resurse și informații externe în mediul lor
operațional, fără să cunoască modul în care in formațiile externe sunt denumite și organizate
în acel mediu. Contextul de denumire JNDI și adnotările limbajului Java ofe ră această
capacitate.
2.3.1 Contextul denumirii
Mediul de denumire al componentei aplicației este un mecanism care permite
personaliz area logicii componentei aplicației în timpul desfășurării sau asamblării. Utilizarea
mediului componen tei aplicației permite personal izarea comp onentei aplicației fără a fi
necesară accesarea sau modificarea codului sursă al componentei aplicației.

13
Toate obiectele definite în intrări de me diu de orice fel (fie în de scriptori de
implementare, fie prin adnotări) trebuie să fie specificate pentru a f i de tip Java accesibil
componentei. Dacă obiectul este de tip java.lang.Class, obiectul Class trebuie să se re fere la o
clasă care este accesibi lă componentei. Rețineți că, în cazurile în care contai nerul poate
returna un subtip de implementare de tipul s olicitat, este posibil ca subtipul de implementare
să nu fie accesibil componentei.
2.3.2 Adnotații si injec ție
După cum este descris în secțiunil e următoare, un câmp sau o metodă a anumitor
clase de componente gestionate de containere poate fi adnotat pen tru a solicita ca intrare o
dată provenită din mediul componentei aplicației să fie injectată în clasă. Specifi cațiile pentru
diferitele container e indică ce clase sunt cons iderate clase ge stionate de containere; nu toate
clasele de un anumit tip sunt neap ărat gestionate de container.
Orice tip de resurse descrise în acest capitol pot fi injectate. De asemenea, po ate fi
solicitată injecția folosind intrări în descriptorul de implementare corespunzător fiecăruia
dintre aceste tipuri de resurse. Câmpul sau m etoda poate avea orice calificativ de acces
(public, privat, etc.). Pentru toat e clasele, cu excepția claselor principale ale clientului
aplicație i, câmpurile sau metodele n u trebuie să fie statice. Deoarece clienții aplicației
folosesc același ciclu de vi ață ca aplicațiile Java SE, nicio instanță a clasei principale a
clientului de aplicație nu este creată de cont ainerul client de aplicație. În sch imb, este
invocată metoda p rincipală statică. Pentru a sprijini injecția pentru clasa principală a
clientului aplicației, câmpurile sau metodele adnotate pentru injecție trebuie să fie stat ice.
Un câmp al unei clase poate fi ținta injecției. Câmpul nu treb uie să fie definitiv. În
mod imp licit, numele câmpului este combinat cu numele clasei și utilizat direct ca nu me în
contextul de denumire al componentei aplicației.
2.4 Persisten ce
2.4.1 Referințe
Această secțiune descrie adnotările de metadate și elemente le descriptor de
implementa re care permit co dului componentei aplicației să se refere manager ul de entit ăți
pentru o unitate de persistență folosind un nume logic numit referință unitate de persistență.
Referințele la uni tățile de persistență sunt intrări speciale în mediul componen tei aplicației.
Dezvoltatorul leagă referințele unității de persistență la manageri i de entități care sunt
configurate în conformitate cu specificația persistence.xml pentru unitatea persistență .

14
Cerințele din această secțiune se aplică numai produselor Java EE care includ suport
pentru API Persistence Java.
2.4.2 In jecția persisten țelor
Un câmp sau o metodă a unei componente a aplicației po at fi adnotat ă cu adnotarea
PersistenceUnit. Elementul n ume specifică numele sub care poate fi localizată fabrica de
gestionare a entității (entity manager factory) pentru unitatea de persistență la car e se face
referire în contextul de den umire JNDI. Elementul opțional UnitName specifică numele
unității de pers istență așa cum este declarat în fi șierul persistence.xml care definește unitatea
de persistență.
2.4.3 Programarea inter fețelo r
Furnizorul de co mponente de aplicație trebuie să utilizeze referințele unității de
persistență pentru a obține referințe la fab ricile de manageri de entitate astfel:
• Alocați o intrare în mediul componentei aplicației la referința unității de persistență.
Se recomandă ca furnizorul de componente de aplicație să organizeze toate referinț ele de
unități de persistență din java: comp / env / persistență subcontextul m ediului componentei.
• Căutați fabrica de manager de entitate pentru unitatea de persistență di n mediul
componentei aplicației folosind JNDI.
• Invocați metoda corespunzătoare din fabrica managerului de entitate pentru a obține
o instanță a managerului de entitate.
2.4.4 Decl ararea un ei unit ăți de persistenț ă
Deși o referință a unității de persisten ță este o intrare în mediul componentei
aplicației, furnizorul de componente de aplicație nu trebuie să utilizeze un element d e intrare
pentru a -l declara .
În sc himb, dacă adnotările de metadate nu sunt utilizate, furnizorul de componente de
aplicație treb uie să declare toate referințele de unități de persistență din descriptorul de
implementare folosind elementele de persistence -unit-ref. Acest lucru permite asamblorului
sau dezvol tatorului să descopere toate referințele la unitățile de persistență utiliza te de o
componentă a aplicației. Intrările descriptorului de implementare pot fi de asemenea utilizate
pentru a specifica inje ctarea unei referințe a unei unităț i de persistență într -o componentă a
aplicației.
Fiecare element persistence -unit-ref descrie o referință din fabrică a unui singur
manager de entitate pentru unitatea de persistență. Elementul persisten ce-unit-ref con stă din

15
descrierea opțională și elemen tele persistență -nume -unitate și elementul obligatoriu –
persistență -unitate -ref.
Elementul persi stence-unit-ref-name conține numele intrării utilizate în codul
componentei aplicației. Elementul persisten ce-unit-name este n umele unității de persistență,
așa cum este specificat în fișierul persistence.xml pentru unitatea persistență.
2.4.5 Responsabili tăți
Programa torul folosește instrumente de implementare pentru a lega o referință de
unitate de persistență la fabrica de manager de entitate configurată pentru unitatea de
persistență în mediul operațional țintă.
Programatorul trebuie să efectueze următo arele sarci ni pentru fiecare referință de
unitate de persistență declarată în adnotările metadate lor sau descriptorul de implementare:
•Trebuie legată referința unității de persistență la o fabrică de administrator de entități
configurată pentru unitatea d e persistență care există în mediul operațional. Programatorul
poate folosi, de exemplu, mecanismul JNDI LinkRef pentru a crea o legătură simbolică cu
numele JND I propriu -zis al fabricii managerului de entitate .
• Dacă numele unității de persistență este s pecificat, programatorul ar trebui să lege
referința unității de persistență la fabrica managerului de entitate pentru unitatea de
persistență specificată ca țin tă.
• Trebuie sc furnizate orice informații suplimentare de configurare de care are nevoie
fabri ca de manager de entitate pentru gestio narea unității de persistență .

2.5 Hibernate
În lumea noastră ideală, ar fi banal să luăm orice ob iect Java și să îl persistăm în baza
de date. Să nu fie nevoie de nici o codificare specială pentru a realiza acest lu cru, nu ar
rezulta nici o penalitate de performanță, iar rezultatul ar fi total portabil. Să nu exista surprize
neplăcute , nicio muncă suplimentară pentru corelarea clasei cu tabelele din baza de date și
fără probleme de performanță.
Hibernate se apropie re marcabil de acest lucru, cel puțin în comparație cu
alternativele , dar, din păcate, există fișiere de configurare care să creeze și proble me de
performanță subtile de luat în considerare. Cu toate acestea, Hibernate își atinge scopul
fundamental – vă permi te să stocați obiecte java normale în baza de date. Figura următoare
arată modul în care Hibernate se încadrează în aplicația dvs. între c odul client și baza de date.

16

Termenul comun pentru persistența directă a obiectelor Java este maparea relațională
dintre obiecte – adică maparea obiectelor din Java către entitățile relaționale dintr -o bază de
date.
Obiectele pot fi ori ce obiect Java. Hi bernarea vă permite să persistați obiectele cu
foarte puține constrângeri.
2.5.1 Hibernate ca s oluție a persistenței
Hibernate abordează o mulțime d in puncte le persitenței sau ameliorează o parte din
durere acolo unde nu se poate, așa că vom aborda punctel e la rândul lor.
Hibernarea nu necesită să mapați un obiect într-o singură masă. Un obiect poate fi
construit dintr -o selecție de coloane de tabel sau mai multe obiecte pot fi persistate într -o
singură tabelă .
Hibernate sprijină di rect relațiile de moșteni re și alte diferite relații dintre clase.
Deși există o anumită performanță în timp ce Hibernate pornește și prelucrea ză
fișierele sale de configurare, în general este perceput ca un instrument rapid. Acest lucru este

17
foarte greu de cuantificat și, într -o oarecare măsură, slaba reputație a boabelor de entitate s -ar
fi putut câștiga mai puțin din propriile defecțiuni decât din greșelile celor care proiectează și
implementează astfel de aplicații. Ca și în cazul tuturor întrebărilor de performanță, trebuiesc
efectua te teste.
În Hibernate este posibil, dar nu este necesar, specificarea mapărilor la momentul
implementării.
Hibernate folosește obiecte care pot fi generalizate foarte ușor și în mod natural
pentru utilizare în alte aplicații. Nu există dependență d irectă de bibliotecile Hibernate, astfel
încât obiectele p ot fi folosite în orice caz care nu necesit ă persistență .
Hibernate nu prezintă probleme la manipularea obiectelor serializabile .
Orice obiect Java care poate fi persistat într -o bază de date este u n candidat pentru
persistența Hibernate. Prin urmare, Hibernate este un înlocuitor natural pentru soluții ad hoc
sau c a motor de persistență pentru o aplicație care nu a incorporat încă o persistență a bazei
de date. Mai mult, alegând persistența Hibernate , nu vă legați de decizii de proiectare
specifice pentru obiectele din aplicația dvs.
2.5.2 Mapar ea
Hibernate are nevo ie de ceva care să -i spună coresponden ța dintre tabele și obiecte . În
limbajul Hibernat e, aceasta se numește mapare. Mapările pot fi furni zate fie prin adnotări
Java, fie printr -un fișier de mapare XML. Eu m -am concentra t pe utilizarea adnotărilor,
deoarec e putem marca direct clasele obiec telor Java. Constatăm că folosirea adnotărilor ne
oferă o imagine clară a codului și a ceea ce încercăm să realizăm. Hibernate abordează
configurar ea iniția l prin excepție pentru adnotări – dacă suntem satisfăcuți de valor ile
implicite pe care Hibernate n i le furnizează, nu este necesar să le furnizăm explicit ca
adnotări. De exemplu, Hibernate folosește num ele clasei obiectulu i ca valoare implicită a
tabelei bazei de date la care se realizează hărțile obiectului.
2.5.3 Integrarea și configurarea
Prim ii pași necesari:
1. Identificați obiectele care au o reprezentare a bazei de date.
2. Identificați care sunt propr ietățile acelor obiecte care trebuie persistate .
3. Adnotați fiecare dintre obiecte pentru a mapa proprietățile obiectulu i Java în
coloane le dintr -un tabel de baze de date .

18
4. Creați schema bazei de date utilizând instrumentul de export a schem ei, utilizați o
bază de date existentă sau creați -vă schema proprie i baze de date .
5. Adăugați bibliotecile Java Hibernate la classpath -ul aplicației .
6. Creați un fișier de configurare Hibernate XML care indică baza de date și clasele
dvs. mapate .
7. În aplicația Java, creați un ob iect de configur are Hiberna te care face referire la
fișierul dvs. de configurare XML.
8. De asemenea, în aplicația Java, construiți un obiect Hibernate SessionFactory din
obiectul Configu ration.
9. În cele din urmă, preluați obiectele Hibernate Session din Sessi onFactory și scrieți
logica de acces la date pentru aplicația dvs. (cr eați, recuperați, actualizați și
ștergeți) .

Înainte de a crea session factory , Hibern ate trebuie s ă știe unde găsește informațiile de
mapare care să definească modul în care clasele dvs . Java se raportează la tabelele bazei de
date. Hibernate necesită, de asemenea, un set de setări de configurare, care sunt furnizate de
obicei ca fișier de proprietăți J ava standard denumit hibernate.properties sau ca fișier XML
numit hibernate.cfg.xml.
Vă recomandăm să folosiți formatul XML. Acest lucru vă permite să specificați
locația informațiilor de mapare din fișie rele de configurare , aceste informații fiind furnizate
automat de Hibernate prin clasa Configuration.
2.5.4 Entit ăți, clase și denumiri
Entitățile reprezintă obiecte Java cu mapări care le permit să fie stocate în baza de
date. Mapările indică modul în car e câmpurile și proprietățile obiectului trebuie sc stocate în
tabelele bazei de date. Cu toate acestea, este posibil să doriți ca obiectele de un anumit tip să
fie reprezentate în două moduri diferite în baza de date. De exemplu, am putea avea o clasă
Java pentru utilizatori, dar două tabele diferite în baza de date care stochează utilizatorii.
Aceasta poate să nu fie cea mai bună proiectare a bazei de date, dar probleme similare sunt
frecvente în sistemele moștenite. Alte sisteme care nu pot fi ușor modific ate pot depinde de
proiectarea bazei de date existente, iar Hibernate este suficient de puternic pentru a acoperi
acest scenariu. În acest caz, cum alege Hibernate care să îl folosească?
Un obiect reprezentând o entitate va avea un tip normal de clasă Java . De asemenea,
va avea un nume de entitate. În mod implicit, numele entității va fi același cu numele tipului

19
de clasă. Aveți opțiunea, to tuși, de a schimba acest lucru prin mapări și, astfel, să distingeți
obiectele de același tip care sunt mapate în tabe le diferite. Prin urmare, există metode în API –
ul sesiunii care necesită furnizarea unui nume de entitate pentru a determina maparea
cores punzătoare. Dacă se omite acest lucru, fie se datorează faptului că nu este necesară o
astfel de distincție, fie pentr u că, pentru comoditate, metoda presupune cel mai comun caz ,
adică numele entității este același cu numele clasei – și duplică funcționa litatea alt ei metode
mai specific ă care p rimește numele enitit ății ex plicit.
Hiberna te necesită ca toate entitățile să a ibă un identificator, care reprezintă coloana
(cheile) principală a tabelului la care va fi persistat. Atunci când o entitate persistă, Hi bernate
îi poate atribui automat un identificator adecvat, sau un utilizator adecvat poate fi în mod
explicit atribuit de acesta .
De obicei, entitatea va furniza un câmp sau proprietate identificator , iar Hiber nate va
folosi această valoare pentru a corela entitățile din memorie cu cele persistente în tabelele
bazei de date. Cu toate acestea, dacă nu există un astfel de c âmp sau proprietate disponibil
(cum se va întâmpla probabil cu codul moștenitor), Hibernate însuși poate gestiona valoarea
identificatorul ui intern. Tipul identificatorului trebuie definit în informațiile de mapare .
Entitățile pot conține referințe la alte entități – fie direct ca proprietate sau câmp, fie
indirect, printr -o colecție de un fel (tab louri, seturi, liste etc.). Aceste asociații sunt
reprezentate folosind relații cheie străine în tabelele de bază.
Când doar una din perechile de entități conține o referință la cealaltă, asocierea este
unidirecțională. Dacă asocierea este reciprocă, atunci este denumită bidirecțională.
2.5.5 Salv area entităților
Crearea unei instanțe a unei clase pe care ați mapat -o cu o mapare Hibernate nu
persistă automat obiect ul bazei de date. Până să salvați în mod explicit obiectul cu o sesiune
Hibernate validă, obiectul este tranzitoriu, ca ori ce alt obiect J ava. În Hibernate, folosim una
dintre metodele de sa ve() din interfața Session pentru a stoca un obiect tranzitor în b aza de
date, astfel :

public Serializable save(Ob ject obj) throws Hibern ateEx ception
public S erializable save(String enityName, Object obj ) throws Hibernate Exception

Ambele metode save () iau ca argument o referință tranzit ivă a obiectului (care nu
trebu ie să fie nulă). Hibernate se așteaptă să găsească o mapare (fie adnotări, fie mapare

20
XML) pentru clasa obiectului tranzit iv – Hibernate nu poate persista obiecte nemarcate
arbitrare. Dacă ați mapat mai multe entități într -o clasă Java, puteți specifica ce entitate
salvați (Hibernate nu ar ști dacă am specifica doar numele clasei Java) cu argumentul
entityName.
Nu este potrivit să salvați un obiect care a fost deja persistat. În egală măsură, nu este
adecvat să actualizați un obiect tranzitor. Dacă este impo sibil sau inco mod să determinați
starea obiectului din codul aplicației dvs., puteți utiliza metoda saveOrUpdate (). Hibernate
folosește i dentificatorul obiectului pentru a determina dacă introduceți un nou rând în baza de
date sau actualizați un rând exis tent.
Odată ce un obiect este într -o stare persistentă, Hibernate gestionează actualizări ale
bazei de date însăși pe măsură ce schimbați câmpurile și proprietățile obiectului.
2.5.6 Încărcarea entităților
Interfața Session din Hibernate oferă mai multe m etode de load() pentru încărcarea
entitățil or din baza de date. Fiecare metodă de load() necesită cheia principală a obiectului ca
identif icator .
În plus față de ID, Hibernate trebuie să știe și ce clasă sau nume de entitate să
folosească pentru a găsi obi ectul cu acel ID. În cele din urmă, va trebui să aruncați obiectul
returnat prin load () la clasa dorită. Metodele de load() de bază sunt următoarele:

public Object load(Class theClass, Serializab le id) throws HibernateEx ception
public Obje ct load(String entityName , Seriali zable id) th rows HibernateException
public void load(Object obj,Serializable id) throws Hibernate Exception

Ultima meto dă load () ia un obiect ca argument. Obiectul ar trebui să fie de aceeași
clasă cu obiectul pe care doriți să îl încăr cați și ar trebui să fie gol. Hibernate va popula acel
obiect cu obiectul pe care l -ați solicitat. Considerăm că această sintaxă este oare cum confuz ă
atunci când este pusă în aplicații, deci nu avem tendința de a o folosi singură.
Celelalte metode de load() iau un mod de blocare ca argument. Modul de blocare
specifică dacă Hibernate ar trebui să caute în memoria cache a obiectului și care ni vel d e
blocare a bazei de date Hibernate ar trebui să folosească pentru rândul (sau rândurile) de date
care reprezintă acest obiect. Dezvoltatorii Hibernate susțin că Hibernate va alege de obicei
modul de blocare corect pentru dvs., deși am văzut situații în ca re este important să alegeți

21
manual blocarea corectă. În plus, baza de date poate alege propria strategie de bloc are – de
exemplu, blocarea unei tabele întregi și nu a mai multor rânduri dintr -o tabelă.
Nu ar trebui să folosiți o metodă de load() decâ t dacă sunteți sigur că obiectul există.
Dacă nu sunteți sigur, atunci utilizați una dintre metodele get (). Metodele l oad() vor arunca o
excepție dacă ID -ul unic nu se găsește în baza de date, în timp ce metodele get () vor întoarce
doar o referință nulă.
La fel ca load(), metodele get () iau un identificator și fie un nume de entitate, fie o
clasă. Există, de asemene a, dou ă metode get () care iau un mod de blocare ca argument.
Metodele get () sunt următoarele:
public Object get(Class class, Serializable id) t hrow s Hibernate Exception
public Object get(String en tityName , Serializable id) th rows Hibernate Exception
public Object get(Class class,Serializable id, LockMo de loc kMode )
throws Hi bernateE xception
public Object get (String EntityName, Serializable id, Lock Mode lockMode)
throws HibernateException

2.5.7 Actualiza rea entit ăților
Hiberna te persistă automat în modificările b azei de date aduse obiectelor persistente.
Dacă o proprietate se schimbă pe un obiect persistent, sesiunea Hibernate asociată va face
coad a modificării pentru persistență la baza de date folosind SQL. Din perspectiva
dezvoltatorului, nu trebuie să faceți n icio lucrare pentru a stoca aceste modificări, cu excepția
cazului în care doriți să forțați Hibernate să comită toa te modificările din co adă. Puteți, de
asemenea, să stabiliți dacă sesiunea este murdară și trebuie sc făcute modificări. Când
efectuați o tra nzacție Hibernate, Hibernate va avea grijă de aceste detalii pentru dvs.
2.5.8 Ștegerea entităților
Pentru a permite eliminarea comodă a e ntităților din baza de date, interfața Session
oferă o metodă de delete ():
public void delete(Object ob j) throws Hiber nateException

Această met odă ia un obiect persistent ca argument. Argumentul poate fi, de
asemenea, un obiect tranzitoriu cu identificato rul setat la id -ul obiectului care trebuie șters.
În cea mai simplă formă, în care pur și simplu ștergeți un obiect fă ră asocieri cu alte
obiecte , acest lucru este simplu; dar multe obiecte au asocieri cu alte obiecte. Pentru a

22
permite acest lucru, Hiberna te poate fi configurat astfel încât să permită ștergerea cascadat ă
de la un obiect la obiectele sale asociate.
De exem plu, luați în considerare situ ația în care aveți un părinte cu o colecție de
obiecte „copil ” și doriți să le ștergeți pe toate. Cel mai si mplu mod de a gestiona acest lucru
este de a utiliza atributul cascad e pe elementul colecției din maparea Hibernate. D acă setați
atributul cascade să fie delete sau all, ștergerea va fi în cascadă la toate obiectele asociate.
Hibernate se va ocupa de șterg erea acestora – ștergerea părintelui șterge rea obiectel or
asociate.
Hibernate acceptă, de asemenea, ștergeri în masă, în care aplicația d vs. execută o
instrucțiune DELETE HQL împotriva bazei de date. Acestea sunt foarte utile pentru ștergerea
mai multor ob iecte simultan, deoarece fiecare obiect nu trebuie să fie încărcat în memorie
pentru a fi șters.
2.6 Hibernate Query L anguage( HQL )
Deși majoritatea instrumentelor ORM și bazelor de date de obiect oferă un limbaj de
interogare a obiectelor, HQL -ul lui Hiber nate se evidențiază ca fiind complet și ușor de
utilizat. Deși puteți utiliza instrucțiuni SQL direct cu Hibernate , este recomandat să utiliz ăm
HQL (sau criterii) ori de câte ori este posibil, pentru a evita dificultățile de portabilitate a
bazei de date ș i pentru a profita a strategiilor de generare SQL . În plus față de avantajele sale
tehnice față de SQL tradițional, HQ L este un limbaj de interogare mai compact decât SQL,
deoarece poate utiliza informațiile de relație definite în mapările Hibernate .
HQL e ste un limbaj de interogare orientat pe obiecte care oferă puterea SQL în timp
ce profită de maparea și memorarea în c ache a relației de obiecte a lui Hibernate. Dacă portați
o aplicație existentă la Hibernate, puteți utiliza facilitățile SQL native ale Hi bernate pentru a
executa SQL în baza de date. Funcționalitatea SQL este utilă și pentru executarea
instrucțiunilor SQL care sunt specifice unei baze de date date și care nu au echivalente în
HQL.
Puteți activa jurnalul SQL pentru Hibernate, ia r Hibernate v a înregistra SQL -ul
generat pe care îl execută în baza de date. Dacă adăugați un comentariu la un obiect de
interogare HQL, Hibernate va afișa un comentariu în jurnalul de lângă instrucțiunea SQL –
acest lucru ajută la urmărirea instrucțiu nilor SQL înapoi la HQL în aplicați e.

23
2.6.1 UPDATE
UPDATE modifică detaliile obiectelor existente în baza de date. Entitățile din
memor ie nu vor fi actualizate pentru a reflecta modificările rezultate din emiterea de
declarații UPDATE. Sinta xa declarației UPDATE:
UPDATE [from] p ath [[ AS] alias] [ … ]
SET property = value [ … ]
[WHERE expresieLogic ă]
path este numele complet calificat a l entității sau entităților. Alias poate fi utilizat
pentru a prescurta referințele la anu mite entități sau proprietățile lor și trebuie u tilizate atunci
când numele de proprietăți utilizate în interogare ar fi în alt mod ambiguu.
Valorile din p roper ty sunt numele proprietăților entităților enumerate în calea
FROM.
2.6.2 DELETE
DELETE elimină din baza de date detaliile obiectelor existente. Entitățile din
memorie nu vor fi actualizate pentru a reflecta modificările rezultate din declarațiile
DELETE. Acest l ucru înseamnă, că regulile cascadei Hibernate nu vor fi respectate pentru
ștergerile efectua te cu HQL. Cu toate acestea, dacă ați specific at ștergeri în cascadă la nivelul
bazei de date (direct sau prin Hibernate folosind adnotarea @OnDelete), baza de date va
elimina în continuare rândurile copil. Această abordare a ștergerii este de obicei denum ită
„ștergere în vrac”, deoarece este cea mai eficientă modalitate de a elimina un număr mare de
entități din baza de date. Sintaxa declarației DELETE:
DELETE [FROM ] path [[AS] alias ]
[WHERE expresieLogic ă]
2.6.3 INSERT
O comandă INSERT în HQL nu poate fi folosit ă pentru a insera direct entități
arbitrare, poate fi utilizat ă doar pentru a insera entități construite din informațiile obținute din
interogările SELECT ( spre deosebire de SQL obișnuit, în care o comandă INSERT poate fi
folosită pentru a insera date arbitrare într -un tabel. ca valori de inse rare selectate din alte
tabele ). Sintaxa declarației INSERT:
INSERT pa th (property [ … ])
Select
Path este numele une i entități. În property sunt numele proprietăților entităților listate
în calea FROM a interogării SELECT încorporate.

24
2.6.4 SELECT
Un HQL SELECT este folosit pentru a interoga baza de date pentru clase și
proprietățile acestora. Aceasta este foarte mult u n rezumat al puterii expresive complete a
query -urilo r HQL SELECT .Sintaxa declarației SELECT:
[SELECT [DISTINCT] property [ … ]]
FROM pa th [[AS] alias ] [ … ]
WHERE e xpresieLogic ă
GROUP BY property [ … ]
HAVING expresieLogic ă
ORDER BY property [ ASC | DESC ] [ … ]

Path este numele complet al unei entități. Numele alias pot fi utilizate pentru a
prescurta referințele la anumite entități sau proprietățile lor și trebuie sc utilizate atunci când
numele de proprietăți utilizate în interogare ar fi în alt m od ambiguu.
Property sunt numele proprietăților entităților enumerate în calea FROM.
2.7 HTML
În termeni simpli, un document HTML este un fișier text simplu care este codat
folosind Hypertext Markup Language (HTML), astfel încât să apară frumos formatat în tr-un
browser Web. Ce însea mnă f iecare cuv ânt în parte :
-Hipertext : text pe care faceți clic pentru a sari de la un document la altul. Aceasta
este o referire la capacitatea paginilor Web de a se conecta între ele.
-Markup : etichete care aplică convenții d e formatare și formatare a textului simplu.
Literal, textul simplu este „marcat” cu etichete .
-Language : face referi re la faptul c ă HTML este considerat un limbaj de programare.
Când oamenii se gândesc la programarea computerului, de obicei se gândesc să sc rie
un program compilat. Un limbaj de pro gramare compilat rulează codul de programare care
poate fi citit de oameni printr -un program care îl convertește într -un fișier executabil (de
obicei cu o extensie .exe sau .com), care este apoi distribuit utilizato rilor. În schimb, HTML
este un limbaj de programare interpretat. Asta înseamnă că programul este distribuit în format
citibil de către utilizatori, iar programul în care este deschis are grijă să -l ruleze. Codul
HTML pentru paginile Web se află în fișiere. De fiecare dată când deschideți browserul Web
se va deschide o pagină Web, acesta procesează codul HTML în fișier.

25
3. Descrierea formala a aplicatiei (3 – 30
pagini)
3.1 Arhitectura
3.2 Use case (fully dressed)
– Name – A clear verb/noun or actor/verb/noun descriptor that communicates the scop e
of the use case.
– Brief Description – A brief paragraph of text describing the scope of the use case.
– Actors – A list of the types of users who can engage in the activities described in the
use case. Actor names shoul d not correspond to job titles.
– Precon ditions – Anything the solution can assum e to be true when the use case
begins.
– Basic Flow – The set of steps the actors t ake to acc omplish the goal of the use case. A
clear description of what the system does in respo nse to each user action.
– Alternate Flo ws – Capture the le ss common user/system interactions, such as being
on a new computer and answering a security qu estion.
– Exception Flows – The things that can happen that prevent the user from achieving
their goal, su ch as providing an incorrect username and password.
– Post Conditions – Anything that must be true when the use case is complete.
3.3 Mockups
3.3.1 fereas tra de a dmin

Figura 3.1 – fereastra admin

26
4. Descrierea aplicatiei (20 – 40 pagini)
4.1 Administrarea

Dupa logare . La accesarea optinuii cor espunzatoare, apar a urmatoarea fereastra :

Figura 4.1 –admin
Se observa ca…
La apasarea butonului Sterge se ex ecuta ur matoarea s ecventa:
"name": "Win32",
"includePath": [
"${workspaceFolder}"
],
"defines" : [
"_DEBUG",
"UNICODE"
],
"intelliSenseMod e": "msvc -x64",
"browse": {
"path": [
"${workspac eFolder} ",
"C:\\MinGW \\lib\\gcc\\mingw32 \\6.3.0 \\include \\c++"
],
"limitSymb olsToIncludedHeaders": true,
"databaseFilename": ""
}

27
5. Concluzii si dezvoltari ulterioare (1.5
– 4 pagini)

5.1 Concluzii
Cand am inceput sa lucr am la apli catie ne -am propus urmatoarele (coipiezi de la
introducere) si am reusit urma tyoarele:
– Ce am facut din lista initiala
– Ce NU a m facut din lista
– Ce am facut in plus
5.2 Dezvoltari ulterioare

Chiar daca aplicatia si -a dovedit utilitatea, ar trebui sa mai ada ugam urmatoarele
facilitati:
– Chestii de facut in viitor

28

Bibliografie

Bibli ography
A., P. (2017). introducerfe in ANSI C++. Sibiu: ULBS.