Licență

Aplicat ie pentru tip arirea etichetelor de origine [614177]

Byadmin ianuarie 1, 2024

UNIVERSITATEA DIN PITES ¸TI
FACULTATEA DE MATEMATIC ˘A-INFORMATIC ˘A
DOMENIUL DE LICENT ¸ ˘A INFORMATIC ˘A
LUCRARE DE LICENT A
Aplicat ie pentru tip arirea etichetelor de origine
Dacia, Renault si Nissan
Coordonator:
lect. univ. dr. MIROIU Maria
Absolvent: [anonimizat]-Lucia C alc^ i (Tic a-Diaconu)
{ 2013 {

Cuprins
1 Tehnologii folosite 5
1.1 Arhitectura N-Tier . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.1 Sisteme tradit ¸ionale de g˘ azduire . . . . . . . . . . . . . . . 5
1.1.2 Sisteme distribuite . . . . . . . . . . . . . . . . . . . . . . 6
1.1.3 Modelul Client/Server . . . . . . . . . . . . . . . . . . . . 7
1.1.4 Modelul Client/Server distribuit . . . . . . . . . . . . . . . 8
1.1.5 Comunicarea ˆ ıntre procese . . . . . . . . . . . . . . . . . . 9
1.1.6 Beneﬁciile modelului Client/Server . . . . . . . . . . . . . 9
1.1.7 Arhitectura Client/Server 2-Tier. . . . . . . . . . . . . . . 10
1.1.8 Arhitectura Client/Server 3-Tier. . . . . . . . . . . . . . . 12
1.1.9 Framework-ul 3-Tier pentru aplicat ¸iile cu baze de date pe
WWW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2 Introducere ˆ ın Struts Web Framework . . . . . . . . . . . . . . . . 18
1.2.1 Ce sunt framework-urile aplicatiiei . . . . . . . . . . . . . 18
1.2.2 Tehnologiile ˆ ımputernicite . . . . . . . . . . . . . . . . . . 19
1.2.3 Struts, v˘ azut de sus . . . . . . . . . . . . . . . . . . . . . . 24
1.2.4 S˘ a ne uit˘ am ˆ ınapoi . . . . . . . . . . . . . . . . . . . . . . 30
1.2.5 Ce am facut . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2 Fundamente – MySQL si WASCE 34
2.1 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.1.1 Scurt˘ a introducere . . . . . . . . . . . . . . . . . . . . . . 34
2.2 WASCE IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.2.1 Introducereˆ ın o WebSphere Application Server Community
Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.2.2 Familia de aplicat ¸ii server WebSphere . . . . . . . . . . . . 36
2.2.3 T ¸inta utilizatorilor Community Edition . . . . . . . . . . . 37
2.2.4 Componente ale Community Edition . . . . . . . . . . . . 38
2.2.5 Instalare Community Edition . . . . . . . . . . . . . . . . 39
2.2.6 Dezvoltarea cu Community Edition . . . . . . . . . . . . . 41
2.2.7 Lucrul cu baze de date . . . . . . . . . . . . . . . . . . . . 41
2

CUPRINS 3
3 Aplicat ie: Procesul de etichetare al pieselor de schimb 43
3.1 Descrierea aplicat ¸iei . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1.1 Motivul aplicat ¸iei . . . . . . . . . . . . . . . . . . . . . . . 43
3.2 Logarea ˆ ın aplicat ¸ie . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3 Ecranul principal . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.4 Paginile alpicat ¸iei . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.4.1 Securitate – Utilizatori . . . . . . . . . . . . . . . . . . . . 46
3.4.2 Securitate – Roluri . . . . . . . . . . . . . . . . . . . . . . 47
3.4.3 Securitate – Tipuri iesire . . . . . . . . . . . . . . . . . . . 47
3.4.4 Securitate – Tipuri imprimante . . . . . . . . . . . . . . . 48
3.4.5 Gestiune – Intr˘ ari etichete . . . . . . . . . . . . . . . . . . 50
3.4.6 Gestiune – Ie¸ siri etichete imprimate . . . . . . . . . . . . . 51
3.4.7 Gestiune – Ie¸ siri etichete neimprimate . . . . . . . . . . . 53
3.4.8 Gestiune – Rebut . . . . . . . . . . . . . . . . . . . . . . . 54
3.4.9 Gestiune – Stoc . . . . . . . . . . . . . . . . . . . . . . . . 55
3.4.10 Imprimare . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Introducere
Aceast˘ a lucrare de licent ¸˘ a este proiectul de stagiu din cadrul Grupului Renault
Romˆ ania.
ˆIn cadrul stagiului am ˆ ınv˘ at ¸at s˘ a pun ˆ ın practic˘ a cuno¸ stint ¸ele dobˆ andite ˆ ın cei
trei ani de facultate, dar ¸ si lucruri noi sau de aprofundare cum ar ﬁ lucrul ˆ ın
echip˘ a, respectarea termenelor limit˘ a, respectarea programului de lucru, colabo-
rarea ¸ si comunicarea ˆ ın echip˘ a.
ˆIn primul capitol am prezentat tehnologiile folosite ˆ ın cadrul aplicat ¸iei: arhi-
tectura 3-tier (stratul de enterprise, cel al aplicat ¸iei ¸ si cel al clientlui) ¸ si despre
Struts, precum ¸ si o mic˘ a aplicat ¸ie cu Struts.
ˆIn capitolul doi am discutat despre MySQL, un program de baze de date ¸ si
despre WASCE IDE, mediul de dezvoltare al aplicat ¸iei.
ˆIn ultimul capitol prezint aplicat ¸ia ˆ ın detaliu.
4

Capitolul 1
Tehnologii folosite
1.1 Arhitectura N-Tier
1.1.1 Sisteme tradit ionale de g azduire
Un sistem central de procesare (Mainframe) care asigur˘ a toate procesele. Ter-
minalele locale sunt responsabile pentru aﬁ¸ sarea ¸ si pentru intr˘ arile de la tastatur˘ a
de c˘ atre utilizator ¸ si capabilit˘ at ¸i de vizualizare. Terminalele locale nu dispun de
capabilit˘ at ¸i inteligente de procesare.
Figura 1.1: Sistemul Non-Client-Server
Serverul de ﬁ¸ siere ¸ si procesul de recuperare sunt asigurate de c˘ atre File Server.
Procesarea textului ¸ si de prelucrarea calculului tabelar sunt furnizate de stat ¸iile
de lucru PC.
5

6 CAPITOLUL 1. TEHNOLOGII FOLOSITE
1.1.2 Sisteme distribuite
Atˆ at datele ¸ si procesarea tranzact ¸iilor sunt divizate ˆ ıntre unul sau mai multe
calculatoare conectate printr-o ret ¸ea, ﬁecare calaculator jucˆ and un rol speciﬁc ˆ ın
sistem.
Asigur˘ a datele pe toate site-urile ˆ ıntr-un sistem distribuit, reﬂect˘ a ¸ si face
schimb˘ ari oriunde ˆ ın sistem.
Figura 1.2: Sisteme distribuite

1.1. ARHITECTURA N-TIER 7
1.1.3 Modelul Client/Server
Completeaz˘ a sistemele distribuite. R˘ aspunde limit˘ arilor g˘ asite ˆ ın cele dou˘ a
modele de g˘ azduire a datelor de procesare.
1.Modelul tradit ¸ional de g˘ azduire mainframe, ˆ ın care un singur mainframe
asigur˘ a accesul datelor share-uite c˘ atre mai multe terminale.
2.Modelul ret ¸ea local˘ a (LAN), ˆ ın care mai multe sisteme izolate acceseaz˘ a un
ﬁ¸ sier server care nu asigur˘ a o putere central˘ a de procesare.
Asigur˘ a integrarea datelor ¸ si a serviciilor. Application Processing este asigu-
rat˘ a de mai multe straturi:
1.DB Server,
2.Serverul aplicat ¸iei,
3.Stat ¸ia de lucru la calculator.
Figura 1.3: Modelul Client/Server 3-Tier

8 CAPITOLUL 1. TEHNOLOGII FOLOSITE
1.1.4 Modelul Client/Server distribuit
Procesarea aplicat ¸iei este asigurat˘ a de toate straturile ret ¸elei:
1.Mainframe,
2.Serverul aplicat ¸iei,
3.Stat ¸iile de lucru.
Multiplele baze de date trebuie s˘ a suporte cereri distribuite de date, s˘ a suporte
volume mari, ˆ ıncarcare echilibrat˘ a ¸ si scalabilitate (extensibilitate). Necesit˘ a o
ret ¸ea de administrare ¸ si managementul aplicat ¸iei extinse.
Figura 1.4: Model de sistem distribuit Client/Server

1.1. ARHITECTURA N-TIER 9
1.1.5 Comunicarea ^ ntre procese
Bazat˘ a pe serverul de calcul client/server. Procesul client comunic˘ a cu procesul
server. Fiecare proces ˆ ındepline¸ ste funct ¸ii separate. Datele sunt pasate ˆ ıntre
procese, folosind funct ¸iile IPC(Inter-process Communication).
Figura 1.5: Comunicarea ˆ ıntre procese
1.1.6 Beneciile modelului Client/Server
Divizeaz a procesele aplicat iei c˘ atre multiple ma¸ sini:
{Datele non-critice ¸ si funct ¸iile sunt procesate la client
{Funct ¸iile critice sunt procesate pe server
Optimizeaz a stat ia de lucru a clientului pentru datele de intrare ¸ si
prezentare (de ex. graﬁce ¸ si suportul mouse)
Optimizeaz a serverul pentru procesarea datelor ¸ si stocarea lor (de ex.
cantitate m˘ arit˘ a de memorie ¸ si spat ¸iu pe disc)
Scalarea pe orizontal a – Multiple servere, ﬁecare avˆ and capabilit˘ at ¸i ¸ si
putere de procesare, pot ﬁ ad˘ augate la procesele de ˆ ınc˘ arcare distribuite
Scalarea pe vertical a – Poate ﬁ mutat pe ma¸ sini mai puternice, cum ar
ﬁ minicomputer sau un mainframe pentru a lua avantajul unor sisteme mai
mari ¸ si mai performante
Reduce repetarea datelor – Datele stocate pe server pentru ﬁecare client
reduce volumul datelor duplicate pentru aplicat ¸ie

10 CAPITOLUL 1. TEHNOLOGII FOLOSITE
1.1.7 Arhitectura Client/Server 2-Tier.
Are dou˘ a componente esent ¸iale:
1.Un calculator Client ¸ si
2.Un server de BD.
2-Tier considerente:
Programul client acceseaz˘ a direct baza de date
{Necesit˘ a o schimbare de cod pentru o alt˘ a baz˘ a de date
{Volum mare de traﬁc datorat transportului de date
Programul client execut˘ a aplicat ¸ia logic˘ a
{Limitat de capacitatea proces˘ arii a stat ¸iei de lucru a clientului (me-
morie, procesor)
{Necesit˘ a codul aplicat ¸iei pentru a ﬁ distribuit˘ a ﬁec˘ arei stat ¸ii de lucru
a clientilor.
Figura 1.6: Arhitectura Client/Server 2-Tier

1.1. ARHITECTURA N-TIER 11
Arhitectura 2-Tier – Pro si Contra
Avantaje Dezavantaje
Probleme de dezvoltare: Probleme de dezvoltare:
Structur˘ a simpl˘ a
U¸ sor de ˆ ıntret ¸inut ¸ si de instalatNormele complexe ale aplicat ¸iei
sunt greu de implementat ˆ ın serverul
bazei de date – necesit˘ a mai mult cod
pentru client
Normele complexe ale aplicat ¸iei
sunt greu de implementat ˆ ın
aplicat ¸ia client ¸ si au performante
slabe
Schimb˘ arile logicii de afacere nu
sunt aplicate ˆ ın mod automat de un
server – schimb˘ arile necesit˘ a un nou
software pe partea de client pentru
a ﬁ distribuite ¸ si instalate
Nu este portabil la alte platforme
server de BD
Performant ¸a: Performant ¸a:
Performant ¸a adecvat˘ a pentru vo-
lume mici c˘ atre medii ale mediilor
de dezvoltare
Logica afacerii ¸ si a bazei de
date sunt ﬁzic aproape, care ofer˘ a
performant ¸e superioarePerformant ¸˘ a inadecvat˘ a pentru
mediile cu volum mediu spre ˆ ınalt,
de vreme ce serverul bazei de date
este solicitat s˘ a efectueze logica a-
facerii. Aceasta ˆ ıncetine¸ ste viteza
operat ¸iunilor BD pe serverul BD.

12 CAPITOLUL 1. TEHNOLOGII FOLOSITE
1.1.8 Arhitectura Client/Server 3-Tier.
Arhitectura client/server 3-tier are trei componente esent ¸iale:
1.un PC client
2.o aplicat ¸ie server
3.un server al bazei de date
3-Tier considerente:
Programul client cont ¸ine doar logica de prezentare
{Mai putine resurse necesare pentru stat ¸ia de lucru a clientului
{Dac˘ a locat ¸ia BD se schimb˘ a, clientul nu modiﬁc˘ a nimic
{Mai putin cod de distribuit stat ¸iei de lucru a clientului
Un server gestioneaz˘ a mai multe cereri de client
{Mai multe resurse disponibile pentru programul server
{Reduce traﬁcul de date pe ret ¸ea
Figura 1.7: Arhitectura 3-Tier general˘ a

1.1. ARHITECTURA N-TIER 13
Architectura 3-Tier Pro si Contra
Avantaje Dezavantaje
Probleme de dezvoltare: Probleme de dezvoltare:
Normele aplicat ¸iei complexe sunt
usor de implementat ˆ ın serverul de
aplicat ¸ie
Logica afacerii oﬀ-ˆ ınc˘ arcate de
la serverul BD ¸ si client, care
ˆ ımbun˘ at˘ at ¸e¸ ste performant ¸a
Schimb˘ arile logicii de afaceri
este automat realizat˘ a de server –
schimb˘ arile necesit˘ a doar un nou
software pentru noua aplicat ¸ie server
pentru a ﬁ instalate
Logica aplicat ¸iei server este porta-
bil˘ a cu alte platforme de BD ˆ ın vir-
tutea aplicat ¸iei softwareStructur˘ a mult mai complex˘ a
Mai diﬁcil de ˆ ıntret ¸inut ¸ si de insta-
lat
Performant ¸a: Performant ¸a:
Performant ¸˘ a superioar˘ a pentru
volume medii c˘ atre ˆ ınalte ale medi-
ilor de dezvoltareSepararea ﬁzic˘ a a serverelor de
aplicat ¸ii, care cont ¸in funct ¸ii ale
logicii afacerii, de serverele de BD,
care contin BD, poate afecta mode-
rat performant ¸a

14 CAPITOLUL 1. TEHNOLOGII FOLOSITE
1.1.9 Framework-ul 3-Tier pentru aplicat iile cu baze de
date pe WWW
Abstract. WWW (World Wide Web) este ˆ ın prezent tehnologia dominant˘ a
pentru desfasurarea de aplicat ¸ii telematice, precum ¸ si pentru aplicat ¸iile corpo-
rative pe intranet. Aceasta se bazeaz˘ a pe un model slab de funct ¸ionare care
cauzeaz˘ a probleme importante ˆ ın adaptarea mo¸ stenirii ¸ si a aplicat ¸iilor conexe. O
serie de probleme legate de portare de sisteme cum ar ﬁ DBMS-uri (DataBase
Management System) de la WWW sunt investigate. Practicile care au fost apli-
cate sunt revizuite.
Propun o arhitectur˘ a bazat˘ a pe CORBA care funct ¸ioneaz˘ a ˆ ın spatele unui
server WWW. Baza de date legat˘ a de operat ¸iuni este efectuat˘ a dinamic ˆ ın timp
ce obiectele respective sunt persistente, manipulate pe hit-uri apart ¸inˆ and aceleia¸ si
sesiuni.
ˆIn prezent, internetul este privit ca o tehnologie foarte promit ¸˘ atoare ¸ si este
folosit˘ a foarte mult pentru dezvoltarea de aplicat ¸ii pe internet ¸ si intranet. Acest
sistem de informat ¸ii client / server det ¸ine un mare succes ˆ ın standardizarea de
comunicare ˆ ıntre client ¸i (browsere) ¸ si serverele cu informat ¸ii.
HTTP ( Hypertext Transfer Protocol) este un set de reguli destul de
simple, optimizate pentru sisteme hipermedia distribuite ˆ ın ret ¸elele de arie larg˘ a.
Serverul WWW ˆ ındepline¸ ste ﬁecare cerere individual˘ a de informat ¸ii indepen-
dente de la cele anterioare. Problema este dubl˘ a. ˆIn afar˘ a de handicapul de
performant ¸˘ a care funct ¸ioneaz˘ a slab pe WWW, serverele WWW nu au nici o
modalitate de a asocia ”logic” cereri conexe, precum ¸ si ment ¸inerea de informat ¸ii
pentru ele, ca parte a unei ”sesiuni de utilizator”.
Handicapul de performant˘ a este atribuit faptului c˘ a HTTP are nevoie de o
nou˘ a conexiune TCP pentru ﬁecare cerere pe care le deserve¸ ste. Dezavanta-
jele HTTP – combinat ¸iile TCP (Transmission Control Protocol) au fost cuan-
tiﬁcate ¸ si mai multe propuneri noi au fost f˘ acute pentru a depa¸ si handicapul de
performant ¸˘ a.
ˆIn ceea ce prive¸ ste al doilea pliu al problemei HTTP, o metod˘ a de portare
a aplicat ¸iilor statefull la WWW a fost propus˘ a. Ea se bazeaz˘ a pe un server
de traducere, o component˘ a software care acceseaz˘ a interfat ¸a original˘ a a unui
sistem de mo¸ stenire declan¸ sat de c˘ atre browser-ul WWW. Serverul Traducere
interpreteaz˘ a ie¸ sirea cerere destinat˘ a unui terminal convent ¸ional (de exemplu,
IBM 3270, VT100) la codul HTML.
Pe direct ¸ia invers˘ a, transmit ¸˘ atoarele de traducere Server creaz˘ a cererea HTTP
emis˘ a de c˘ atre browser-ul la interfat ¸a original˘ a a sistemului de mo¸ stenire. Con-
form taxonomiei middleware WWW, serverele de traducere sunt clasiﬁcate ca
”Gateway Interface”. Serverul de traducere nu se ocup˘ a bine de insert ¸ii sau ac-
tualiz˘ ari de informat ¸ii. Mai mult, dependent ¸a de ﬁ¸ siere de specialitate, denumite
scheme, face ca propagarea de modiﬁc˘ ari de aplicare a WWW sa ﬁe destul de
diﬁcil˘ a.

1.1. ARHITECTURA N-TIER 15
Gateway-urile RDBMS (Relational DataBase Management System) au atras
interesul comunit˘ at ¸ii WWW ˆ ın ultimii ani. Problemele asociate cu desfaturarea
de gateway-uri de baze de date sunt:
portabilitatea ˆ ıntre sisteme,
generalitate,
conformitatea cu standardele de performant ¸˘ a,
precum ¸ si funct ¸ionarea dinamic˘ a.
A fost propus un cadru pentru implementarea bazelor de date de pe WWW.
Principalele caracteristici ale acestui cadru au fost generalitatea ¸ si conformitatea
cu standardele existente. Avantajele unei arhitecturi noi, client/server pentru
desfa¸ surarea de aplicat ¸ii de baze de date WWW au fost evaluate ˆ ıntr-o serie de
experimente, prin utilizarea unui pinger HTTP.
Se propune o nou˘ a arhitectur˘ a, bazat˘ a pe Java pentru dezvoltarea de aplicat ¸ii
de baze de date statefull. Arhitectura ˆ ıncearc˘ a s˘ a depa¸ seasc˘ a multe dintre pro-
blemele raportate ˆ ın paragrafele anterioare. V˘ a prezint o component˘ a software
specializat˘ a numit˘ a dispenser . Dispenser-ul aloc˘ a ﬁre de execut ¸ie c˘ atre aplicat ¸ia
bazei de date pentru utilizatorii activi ¸ si t ¸ine evident ¸a utiliz˘ arii acestora. ˆIn
aceast˘ a arhitectur˘ a, exist˘ a o mapare unu-la-unu ˆ ıntre subiectele de aplicare ¸ si
ﬁele de execut ¸ie ale sesiunii. Stimulii din browsere ajung la baza de date prin
Java Servlets. Servlet-ul comunic˘ a cu baza de date prin CORBA.
Arhitectura sugerat˘ a adopt˘ a un sistem 3-tier, a¸ sa cum se arat˘ a in Figura (1.8).
Nivelul de mijloc cuprinde:
un server WWW,
un motor de execut ¸ie Servlet,
Object Request Broker (ORB)
¸ si obiectele CORBA (Common Object Request Broker Adapter) implemen-
tate care comunic˘ a cu baza de date
Acest nivel presupune un client/server de asociere in care client ¸ii sunt Java
Servlets (Javasoft Servlet API 2.0). Rolul server-ului este atribuit de o combinat ¸ie
ˆ ıntre dispenser ¸ si ﬁrele de execut ¸ie a bazei de date Java.
Java Servlets au fost adoptat ¸i pentru c˘ a ace¸ stia sunt capabili de a ment ¸ine
sesiunea de tracking ˆ ıntre diferite cereri HTTP de la aceia¸ si utilizatori. Aceasta
necesit˘ a un server WWW, care poate gestiona cererile de Servlet. Orice server
care are un motor Servlet, practic, se ˆ ıncadreaz˘ a ˆ ın arhitectura, dar alegerea a
fost cea a serverului Web Apache, ˆ ımpreuna cu modul de JServ destinat pentru
sust ¸inerea execut˘ arii Servlet-ului.
ˆIn partea serverul din nivelul de mijloc, CORBA IDL a fost utilizat pentru a
speciﬁca interfet ¸ele de componente. Interfet ¸ele descrise ˆ ın middleware sunt dou˘ a:

16 CAPITOLUL 1. TEHNOLOGII FOLOSITE
dispenser-ul
¸ si ﬁrul de baze de date (dbthread).
Dispenser-ul are o grupare de ﬁre de execut ¸ie c˘ atre baza de date, ﬁecare
ment ¸inˆ and o conexiune la sistemul de baze de date care stau la baz˘ a. Firele
de execut ¸ie c˘ atre bazele de date vin la dispozit ¸ia client ¸ilor cu ajutorul dispenser-
ului.
Fiecare ﬁr de execut ¸ie de date din grupare are, la rˆ andul s˘ au, un obiect-
conexiune ˆ ımpachetat care realizeaz˘ a comunicarea efectiv˘ a cu sistemul de baze de
date. Obiectul ˆ ımpachetat prime¸ ste cereri de la ﬁrele de execut ¸ie de la bazele de
date ¸ si returneaz˘ a rezultate relevante. Atˆ at dispenser cˆ at ¸ si ﬁrele de execut ¸ie ale
bazei de date au un set de metode care sunt puse la dispozit ¸ie, prin intermediul
ORB, clientilor. Dispenser-ul are metode pentru rezervarea ¸ si eliberarea unui ﬁr
de execut ¸ie c˘ atre baza de date, ˆ ın timp ce ﬁrul de execut ¸ie include metode pentru
accesarea informat ¸iilor det ¸inute ˆ ın baza de date. DBMS (DataBase Management
System) folosit ˆ ın implementarea aplicat ¸iei a fost MySQL.
Figura 1.8: Arhitectura propus˘ a
Pe partea de client a arhitecturii din nivelul de mijloc, Servlet-ul invoc˘ a o
parte din ORB, ˆ ın scopul de a localiza ¸ si a comunica cu dispozitivul ¸ si ﬁrele de
execut ¸ie ale bazei de date. Partea de server cont ¸ine o instant ¸˘ a a dispenser-ului ¸ si
mai multe instant ¸e de ﬁre de execut ¸ie de baze de date.
Dispenser-ul, ˆ ın rutine sale de init ¸ializare, ˆ ın afar˘ a de crearea pool-ului de ﬁre
de exceut ¸ie de baze de date, export˘ a un nume in Orb Name Service ¸ si creeaz˘ a un
ﬁr de execut ¸ie numit Invalidator. Numele exportat este util atunci cˆ and Servlet-ul
vrea sa localizeze Dispenser-ul pentru prima data (prin intermediul ORB Name
Service). Firul de execut ¸ie invalidator previne sesiunile de a t ¸ine ˆ ınchise obiectele
bazei de date, ˆ ın timp ce este inactiv˘ a, pentru o lung˘ a perioad˘ a de timp.
Ori de cˆ ate ori o cerere ajunge la serverul aplicat ¸iei de bazei de date, Servlet-ul
relevant folose¸ ste API-ul sesiunii, ﬁe pentru a identiﬁca o sesiune existent˘ a sau

1.1. ARHITECTURA N-TIER 17
de a genera una nou˘ a. ˆIn primul caz, contextul sesiunii (p˘ astrat pe partea de
Servlet), cont ¸ine o trimitere la ﬁrul de execut ¸ie al bazei de date care se ocup˘ a,
de fapt, de sesiunea curent˘ a. ˆIn funct ¸ie de cerere, Servlet-ul invoc˘ a o metod˘ a
adecvat˘ a ˆ ın ﬁrul de execut ¸ie de date. Pentru a veriﬁca dac˘ a ﬁrul este ˆ ınca ˆ ın
manipularea acestei sesiuni, Servlet-ul ˆ ınainteaz˘ a propriul ID de sesiune la ﬁrul
de execut ¸ie. ˆIn ultimul caz (de exemplu, o nou˘ a sesiune context este creat˘ a),
Servlet-ul contacteaz˘ a dispenser-ul pentru a rezerva un ﬁr de execut ¸ie c˘ atre baza
de date pentru a gestiona sesiunea curent˘ a, iar apoi invoc˘ a metoda adecvat˘ a ˆ ın
ﬁrul de execut ¸ie recent atribuit.
Firul de execut ¸ie al bazei de date are un vector intern cu toate cursoarele
bazei de date deschise (ResultSets-uri in JDBC API), impreun˘ a cu un pointer
care se aﬂ˘ a la ultima deschis˘ a (toate operat ¸iunile de baze de date sunt efectuate
prin intermediul JDBC). Ori de cˆ ate ori o declarat ¸ie SQL este trimis˘ a la ﬁrul de
execut ¸ie, ˆ ın cazul ˆ ın care acesta este o instruct ¸iune SELECT, cursorul recent des-
chis se adaug˘ a la sfˆ ar¸ situl vectorului ¸ si indicatorul este schimbat cu aceasta (a se
vedea Figura(1.9)). Pe de alt˘ a parte, atunci cˆ and sose¸ ste o declarat ¸ie goal˘ a, cur-
sorul indicat este utilizat ˆ ın scopul de a aduce urm˘ atoarele rezultate (extragerea
rˆ and-cu-rˆ and). ˆIn cele din urm˘ a, atunci cˆ and sose¸ ste o cerere de cursor, ﬁrul de
execut ¸ie ˆ ınchide ultimul cursorul al vectorului, schimbˆ and indicatorul la cursorul
anterior ¸ si returnˆ and rezultatele cursorului anterior care a fost ultimul trimis. Ar
trebui subliniat faptul c˘ a persistent ¸a cursoarelor a¸ sa cum este descris˘ a mai sus,
ˆ ındepline¸ ste ment ¸inerea st˘ arii urm˘ arite ˆ ın mediul Web.
Figura 1.9: Vectorul cursorului deschis
Rezultatele operat ¸iilor din baza de date sunt integrate, de c˘ atre ﬁrul de execut ¸ie
al bazei de date,ˆ ıntr-un tablou bidimensional de ¸ siruri de caractere ¸ si trimisˆ ınapoi
la Servlet-ul adecvat, prin ORB. Acest tablou are, practic, o serie de ˆ ınregistr˘ ari
preluate de c˘ atre RDBMS.
Invalidator-ul veriﬁc˘ a pool-ul de ﬁre de execut ¸ie al bazei de date, ˆ ın scopul
de a localiza cele care au fost accesate ˆ ınainte de o anumit˘ a limit˘ a de timp.
Aceast˘ a perioad˘ a de timp ofer˘ a o indicat ¸ie clar˘ a de timp ˆ ın care sistemul server
ar trebui s˘ a anticipeze o nou˘ a cerere de la acela¸ si browser. Dup˘ a aceast˘ a perioad˘ a,
Invalidator consider˘ a clientul inactiv ¸ si returneaz˘ a ﬁrul de execut ¸ie la pool-ul de
ﬁre de execut ¸ie disponibile.

18 CAPITOLUL 1. TEHNOLOGII FOLOSITE
1.2 Introducere ^ n Struts Web Framework
Struts este un cardu open-source care extinde Java Servlet API ¸ si folose¸ ste arhi-
tectura MVC (Model, View, Controller). Aceasta permite crearea intret ¸inut˘ a,
extensibil˘ a a aplicat ¸iilor web ﬂexibile bazate pe tehnologii standard, cum ar
ﬁ JSP, JavaBeans, pachete de resurse ¸ si XML (Extensible Markup Language).
Cˆ and se utilizaz˘ a Struts, cadrul ofer˘ a un servlet controler, ActonServlet, care
este deﬁnit in libr˘ ariile Struts care sunt incluse ˆ ın IDE, ¸ si care este automat
ˆ ınregistrat˘ a ˆ ın descriptorul de desfa¸ surare web.xml . ActionServlet-ul folose¸ ste
un ﬁ¸ sier struts-config.xml pentru a mapa cererile primite de la obiectele de
act ¸iune Struts, ¸ si instant ¸iaz˘ a orice obiect ActionForm ascociat cu act ¸iunea de a
stoca temporar datele din formular. Obiectul Action proceseaz˘ a cererile utilizˆ and
metoda sa de executare, ˆ ın timp ce face uz de toate datele stocate ˆ ın form bean.
Odat˘ a ce obiectul Action proceseaz˘ a o cerere, acesta stocheaz˘ a date noi (de e-
xemplu, ˆ ın form bean, sau ˆ ıntr-un result bean separat), ¸ si transmite rezultatele
la vizualizarea corespunzatoare.
1.2.1 Ce sunt framework-urile aplicatiiei
Un framework este o aplicat ¸ie reutilizabil˘ a, semi-complet˘ a care poate ﬁ spe-
cializat˘ a pe producerea de aplicat ¸ii comune. Aplicat ¸iile software ruleaz˘ a pe cal-
culatoare asem˘ an˘ atoare, a¸ steapt˘ a intr˘ ari de la dispozitive asem˘ an˘ atoare, ie¸ siri
c˘ atre display-uri ¸ si salvarea datelor pe hard disk-uri. Dezvoltatorii lucreaz˘ a cu
aplicat ¸ii pe calculatoarele desktop coventionale, obi¸ snuindu-se cu seturile de tool-
uri ¸ si cu mediile de dezvoltare care se balanseaz˘ a ˆ ıntre aplicat ¸ii. Framework-urile
aplicat ¸iilor construite pe aceea¸ si structur˘ a le asigur˘ a dezvoltatorilor o structur˘ a
reutilizabil˘ a care le serve¸ ste asemeni unei fundat ¸ii pentru produsele proprii. Un
framework asigur˘ a dezvoltatorilor un set de componente coloan˘ a vertebral˘ a care
au urm˘ atoarele caracteristici:
sunt cunoscute c˘ a lucreaz˘ a bine ˆ ın alte aplicat ¸ii,
sunt gata s˘ a ﬁe utilizate ˆ ın urm˘ atorul proiect,
pot ﬁ folosite de celelalte echipe din organizat ¸ie.
Alte tipuri de framework-uri
Ideea unui framework nu se aplic˘ a doar aplicat ¸iilor ci ¸ si componentelor ei.
Unele cadre au fost legate de un mediu de dezvoltare proprietar. Putem utiliza
orice mediu de dezvoltare cu Struts:
Visual Age pentru Java
JBuilder

1.2. INTRODUCERE ^IN STRUTS WEB FRAMEWORK 19
Eclipse
Emacs
Textpad.
Toate sunt alegeri populare ˆ ın rˆ andul dezvoltatorilor de Struts. Dac˘ a se poate
folosi cu Java, ˆ ıl putem folosi cu Struts.
1.2.2 Tehnologiile ^ mputernicite
Aplicat ¸iile dezvoltate cu Struts sunt bazate pe un num˘ ar de tehnologii ˆ ım-
puternicite. Aceste componente nu sunt speciﬁce Struts ¸ si stau la baza ﬁec˘ arei
aplicat ¸ii web pe Java. Unul din motive pe care dezvoltatorii folosec framework-
uri ca Struts este c˘ a ascunde detaliile nepl˘ acute din spatele acronimelor cum ar ﬁ
HTTP, CGI ¸ si JSP. Ca un dezvoltator pe Struts, nu trebuie un alfabet de guru,
ci ni¸ ste cuno¸ stint ¸e de baz˘ a ale tehnologiilor care ajut˘ a la inventarea unor solut ¸ii
creative ale problemelor ˆ ın¸ sel˘ atoare.
Hypertext Transfer Protocol (HTTP)
Protocoalele diplomatice sunt concepute pentru a evita neˆ ınt ¸elegerile ¸ si pen-
tru a ment ¸ine negocierile. ˆIn mod similar, atunci cˆ and computerele trebuie s˘ a
vorbeasc˘ a, ele urm˘ aresc, de asemenea, un protocol oﬁcial. Protocolul deﬁne¸ ste
modul de transmitere de date ¸ si cum s˘ a-l decodeze odat˘ a ce ajunge. Aplicat ¸iile
web folosesc Hypertext Transfer Protocol (HTTP) pentru a transmite datele ˆ ıntre
browserul care ruleaz˘ a pe calculator ¸ si aplicat ¸ia care ruleaz˘ a pe server.
Multe aplicat ¸ii server comunic˘ a utilizˆ and alte protocoale decˆ at HTTP. Une-
le dintre acestea ment ¸in o legatur˘ a permanent˘ a ˆ ıntre computere. Serverul de
aplicat ¸ii ¸ stie exact care este conectat ˆ ın orice moment ¸ si poate spune cˆ and o
conexiune este scazut˘ a. Pentru c˘ a ei ¸ stiu starea pentru ﬁecare conexiune ¸ si iden-
titatea ﬁec˘ arei persoane care o folose¸ ste, acestea sunt cunoscute ca protocoale
statefull .
Prin contrast, HTTP este cunoscut ca un protocol stateless . Un server HTTP
va accepta orice solicitare din partea oric˘ arui client ¸ si va oferi ˆ ıntotdeauna un
anumit tip de r˘ aspuns, chiar dac˘ a r˘ aspunsul este doar de a spune nu. F˘ ar˘ a
costurile de negociere ¸ si ment ¸inerea unei conexiuni, protocoale stateless se pot
ocupa de un volum mare de cereri. Acesta este un motiv pentru care Internetul
a fost ˆ ın masur˘ a pentru a se scala la milioane de calculatoare.
Un alt motiv pentru care HTTP a devenit un standard universal este sim-
plitatea sa. O cerere HTTP arat˘ a ca un document text obi¸ snuit. Acest lucru
l-a f˘ acut usor de folosit pentru aplicat ¸ii care fac cereri HTTP. Se poate trimite
o solicitare HTTP de mˆ ana, folosind un utilitar standard, cum ar ﬁ Telnet. ˆIn
cazul ˆ ın care raspunsul HTTP vine inapoi, este, de asemenea, ˆ ın text simplu pe
care dezvoltatorii ˆ ıl pot citi.

20 CAPITOLUL 1. TEHNOLOGII FOLOSITE
Prima linie din cererea HTTP cont ¸ine metoda, urmat˘ a de locat ¸ia resurselor
solicitate ¸ si versiunea de HTTP. Zero sau mai multe cereri HTTP urmez˘ a linia
init ¸ial˘ a. Antetele HTTP ofer˘ a informat ¸ii suplimentare la server. Aceasta pot
include tipul de browser ¸ si versiunea, tipuri de documente acceptabile, ¸ si cookie-
urile browser-ului, pentru a numi doar cˆ ateva. Dintre cele sapte metode cerere,
GET ¸ si POST sunt de departe cele mai populare.
Dupa ce serverul a primit cererea, se va emite un r˘ aspuns HTTP. Prima linie
din r˘ aspuns se nume¸ ste linia de stare ¸ si poart˘ a versiunea protocolul HTTP, un
statut numeric, ¸ si o scurt˘ a descriere a statutului. ˆIn urmatoarea linie de stare,
serverul va returna un set de r˘ aspunsuri antet HTTP care lucreaz˘ a ˆ ıntr-un mod
similar cu anteturile cerere.
A¸ sa cum am ment ¸ionat, HTTP nu p˘ astreaz˘ a informat ¸ii de stare ˆ ıntre cereri.
Serverul ˆ ınregistreaz˘ a cererea, trimite r˘ aspunsul, ¸ si merge mai departe pentru ce-
rerea urm˘ atoare. ˆIn timp simplu ¸ si eﬁcient, un protocol stateless este problematic
pentru aplicat ¸ii dinamice care au nevoie de a urm˘ ari utilizatorii lor.
Cookie-urile ¸ si rescrierea URL-ului sunt dou˘ a metode comune pentru a urm˘ ari
utilizatori ˆ ıntre cereri. Un cookie este un pachet special de informat ¸ii de pe
computerul utilizatorului. Rescrierea URL-ului stocheaz˘ a o referire special˘ a la
adresa paginii pe care un server Java ˆ ıl poate utiliza pentru a urm˘ ari utilizatorii.
Pe cont propriu, un server web standard HTTP nu face traﬁc ˆ ın cont ¸inut
dinamic. Se folose¸ ste ˆ ın principal cererea de a localiza un ﬁsier ¸ si apoi revine c˘ atre
ﬁ¸ sierul de r˘ aspuns. Fi¸ sierul este de obicei formatat folosind Hypertext Markup
Language (HTML) deoarece browser-ul web poate formata ¸ si aﬁ¸ sa. Pagina HTML
include adesea link-uri c˘ atre alte pagini web ¸ si poate aﬁ¸ sa orice num˘ ar de alte
avantaje, cum ar ﬁ imagini ¸ si clipuri video. Utilizatorul face clic pe un link pentru
a face o alt˘ a cerere, iar procesul ˆ ıncepe din nou. Serverele web standard se ocup˘ a
destul de bine de cont ¸inutul static ¸ si de imagini, dar au nevoie de o mˆ an˘ a de
ajutor pentru a oferi utilizatorilor un r˘ aspuns personalizat, dinamic.
Cont inutul static de pe Internet vine direct din ﬁ¸ siere text sau date, cum ar
ﬁ ﬁ¸ siere HTML sau JPEG. Aceste ﬁ¸ siere pot ﬁ modiﬁcate din cˆ and ˆ ın cˆ and, dar
acestea nu sunt modiﬁcate ˆ ın mod automat atunci cˆ and sunt solicitate de c˘ atre un
browser web. Cont inutul dinamic , pe de alt˘ a parte, este generat vioi, de obicei,
ca r˘ aspuns la o cerere individualizat˘ a ˆ ıntr-un browser.
Common Gateway Interface (CGI)
Primul standard utilizat pe scar˘ a larg˘ a pentru producerea de cont ¸inut dinamic
a fost Common Gateway Interface (CGI). CGI utilizeaz˘ a caracteristicile sistemu-
lui de operare standard, cum ar ﬁ variabilele standard de de intrare ¸ si de ie¸ sire
pentru a crea o punte, sau gateway , ˆ ıntre serverul web ¸ si alte aplicat ¸ii de pe
ma¸ sina gazd˘ a. Celelalte aplicat ¸ii se pot uita la cererea trimis˘ a c˘ atre ei de serverul
web ¸ si pot crea un r˘ aspuns personalizat.
Cˆ and un server web prime¸ ste o cerere, care este destinat˘ a pentru un program

1.2. INTRODUCERE ^IN STRUTS WEB FRAMEWORK 21
CGI, ruleaz˘ a acest program ¸ si ofer˘ a programul cu informat ¸ii de la cererea de
intrare. Programul CGI ruleaz˘ a ¸ si trimite product ¸ia sa inapoi la server. Atunci
serverul web transmite r˘ aspunsul la browser.
CGI deﬁne¸ ste un set de convent ¸ii cu privire la informat ¸iile pe care le va trece
ca ¸ si variabile de mediu ¸ si modul ˆ ın care se a¸ steapt˘ a intr˘ arile ¸ si ie¸ sirile standard,
pentru a ﬁ utilizate. Cum ar ﬁ HTTP, CGI este ﬂexibil ¸ si usor de implementat,
¸ si un numar mare de programe CGI au fost scrise.
Principalul dezavantaj al CGI-ului este c˘ a trebuie s˘ a ruleze o copie nou˘ a a
programului CGI pentru ﬁecare cerere. Acesta este un proces relativ costisitor,
care pot ˆ ıncarca site-uri de mare volum ˆ ın care mii de cereri sunt deservite pe
minut. Un alt dezavantaj este faptul c˘ a programele CGI tind s˘ a ﬁe dependente
de platform˘ a. Un program CGI scris pentru un sistem de operare nu poate rula
pe un altul.
Java servlets
Platforma Java Servlet Sun se adreseaz˘ a direct celor dou˘ a dezavantaje princi-
pale ale programelor CGI. ˆIn primul rˆ and, servlet-urile ofer˘ a o performant ¸˘ a mai
bun˘ a ¸ si utilizarea resurselor de programe CGI convent ¸ionale. ˆIn al doilea rˆ and,
scrie o dat˘ a, natura run-anywhere de Java ˆ ınseamn˘ a c˘ a servlet-urile sunt porta-
bile ˆ ıntre sistemele de operare care au o ma¸ sin˘ a virtual˘ a Java(JVM – Java Virtual
Machine).
Un servlet arat˘ a ¸ si se simte ca un server web ˆ ın miniatur˘ a. El prime¸ ste o cerere
¸ si red˘ a un r˘ aspuns. Dar, spre deosebire de serverele web convent ¸ionale, interfat ¸a
de programare a aplicat ¸iilor servlet (API) este special conceput˘ a pentru a ajuta
dezvoltatorii Java s˘ a creeze aplicat ¸ii dinamice.
Servlet-ul, ˆ ın sine, este pur ¸ si simplu o clas˘ a Java care a fost compilat˘ a ˆ ın cod
binar, la fel ca orice alt obiect Java. Servlet-ul are acces la un API bogat de
servicii HTTP speciﬁce, dar este ˆ ınc˘ a doar un alt obiect Java care ruleaz˘ a ˆ ıntr-o
aplicat ¸ie ¸ si poate inﬂuent ¸a toate celelalte beneﬁcii Java.
Pentru a oferi acces la servlet serverelor web convent ¸ionale, servlet-urile sunt
conectate ˆ ın containere . Containerul servlet este ata¸ sat la serverul web. Fiecare
servlet poate declara de ce modele de URL ¸ si-ar dori s˘ a se ocupe.
Dar, spre deosebire de programele CGI, un nou servlet nu este creat pentru
ﬁecare cerere. Odat˘ a containerul instant ¸iaz˘ a servlet-ul, se va crea un nou ﬁr
de execut ¸ie pentru ﬁecare cerere. Firele de execut ¸ie Java sunt mult mai put ¸in
costisitoare decˆ at procesele server utilizate de programe CGI.
Dezvoltatorii pe servlet pot utiliza metoda init() pentru a det ¸ine trimiteri
la resursele costisitoare, cum ar ﬁ conexiuni de baze de date sau EJB Home
Interfaces, astfel ˆ ıncˆ at acestea pot ﬁ partajate ˆ ıntre cereri.
Din moment ce servlet-urile sunt multithread, dezvoltatorii servlet trebuie s˘ a
aiba o grij˘ a deosebit˘ a pentru a ﬁ siguri c˘ a servlet ¸ii lor sunt thread-safe.

22 CAPITOLUL 1. TEHNOLOGII FOLOSITE
JavaServer Pages
ˆIn timp ce Java servlets sunt un pas mare de la programele CGI, ele nu sunt
un leac universal. Pentru a genera r˘ aspunsul, dezvoltatorii sunt ˆ ınc˘ a blocat ¸i cu
folosirea declarat ¸iilor println pentru a face HTML. Cod care arat˘ a ca
out.println("<P>One line of HTML.</P>");
out.println("<P>Another line of HTML.</P>");
Exist˘ a biblioteci care ajut˘ a la generarea HTML, dar aplicat ¸iile devin tot mai
complexe, dezvoltatorii Java sfˆ ar¸ sind prin a ﬁ aruncat ¸i ˆ ın rolul de designeri de
pagini HTML.
ˆIn acela¸ si timp, avˆ and ˆ ın vedere posibilitatea de a alege, majoritatea manage-
rilor de proiect prefer˘ a s˘ a ˆ ımpart˘ a echipa de dezvoltare ˆ ın grupuri specializate.
Le place ca designerii HTML s˘ a lucreze la prezentare, ˆ ın timp ce dezvoltatorii
Java lucreaz˘ a la logica de afaceri.
Pentru a rezolva aceast˘ a problem˘ a, Sun a apelat la ideea de a folosi pagini
de server pentru a combina scripting-ul ¸ si tehnologiile templating ˆ ıntr-o singur˘ a
component˘ a. Pentru a construi JSP-uri, dezvoltatorii ˆ ıncep prin crearea de pagini
HTMLˆ ın acela¸ si mod vechi, folosind aceea¸ si sintax˘ a veche HTML. Pentru a aduce
cont ¸inut dinamic ˆ ın pagin˘ a, dezvoltatorul poate pune, de asemenea, elemente
JSP scripting pe pagin˘ a. Elementele de scripting sunt tag-uri, care ˆ ıncapsuleaz˘ a
logica, care este recunoscut˘ a de c˘ atre JSP. De exemplu, pentru a aﬁ¸ sa data ultimei
modiﬁc˘ ari pe pagin˘ a, dezvoltatorul ar plasa urm˘ atorul cod ˆ ın pagin˘ a:
<B>This page was accessed at <%= new Date() %></B>
Exist˘ a trei tipuri diferite de elemente de scriptare:
expresii
scriptlets
declarat ¸ii
Element Scop
Expresii Cod Java, prins ˆ ıntre <%= ¸ si %>, folosit pentru a evalua declarat ¸iile
limbajul Java ¸ si inserarea rezultatului ˆ ın ie¸ sirea servlet-ului
Scriptlest Cod Java, prins ˆ ıntre <%= ¸ si %>de multe ori folosite pentru a crea
cont ¸inut dinamic
Declarat ¸ii Cod Java, prins ˆ ıntre <%!¸ si%>, folosit pentru a adauga cod ˆ ın
corpul de clas˘ a servlet

1.2. INTRODUCERE ^IN STRUTS WEB FRAMEWORK 23
Pentru a ﬁ vazut˘ a ca o pagin˘ a JSP, ﬁ¸ sierul trebuie s˘ a ﬁe salvat cu extensia
.jsp. Cˆ and un client cere pagina JSP, containerul traduce pagina ˆ ıntr-un ﬁ¸ sier
cod surs˘ a pentru un servlet Java ¸ si compileaz˘ a sursa ˆ ıntr-o clasa Java, la fel cum
ar face dac˘ a ar scrie un servlet de la zero. La rulare, recipientul poate veriﬁca,
de asemenea, de la data ultimei modiﬁc˘ ari a ﬁ¸ sierului JSP ˆ ın ﬁ¸ sierul clas˘ a. Dac˘ a
ﬁ¸ sierul JSP s-a schimbat de cˆ and a fost compilat, containerul va retraduce ¸ si va
reconstrui pagina din nou. Cel mai important lucru de ret ¸inut este c˘ a o pagin˘ a
JSP este de fapt doar un servlet. Tot ceea ce se poate face cu un servlet, se poate
face cu un JSP.
JSP tags
Elementele de scripting sunt doar una dintre cele dou˘ a modalit˘ at ¸i de a ge-
nera cont ¸inut dinamic JSP. Scriptlet ¸ii sunt rapizi, u¸ sori ¸ si puternici, dar cer ca
dezvoltatorii s˘ a amestece cod Java cu HTML. O alternativ˘ a popular˘ a este de a
utiliza tag-uri JSP.
Tag-urile JSP sunt amestecate cu HTML ¸ si pot ﬁ folosite ca ¸ si ˆ ın cazul ˆ ın care
acestea au fost tag-uri HTML obi¸ snuite. O singur˘ a etichet˘ a JSP poate reprezenta
zeci de declarat ¸ii Java, dar tot dezvoltatorul trebuie s˘ a ¸ stie cum introduce tag-ul.
Codul de programare este ascuns ˆ ıntr-un ﬁ¸ sier de clas˘ a Java.
Pentru a utiliza acela¸ si cod pe o alt˘ a pagin˘ a, dezvoltatorul trebuie doar s˘ a
introduc˘ a din nou tag-ul. Tag-urile JSP ofer˘ a refolosirea mult mai bine decˆ at
scriptlet ¸ii ¸ si pot ﬁ mai u¸ sor de folosit pentru dezvoltatorii de pagini, deoarece
acestea arat˘ a ca tag-urile HTML familiare.
Un num˘ ar de biblioteci precompilate de JSP tag-uri sunt disponibile, care
vor efectua funct ¸ionalit˘ at ¸i utile pentru dezvoltatori. Printre acestea este noua
bibliotec˘ a standard JSP tag (JSTL). Acest nou standard ofer˘ a o bogat˘ a bibliotec˘ a
de tag-uri JSP reutilizabile.
Struts funct ¸ioneaz˘ a bine cu bibliotecile JSTL ¸ si alte tag-uri accesibile publicu-
lui, precum ¸ si orice s-ar putea scrie singur.
JavaBeans
JavaBeans sunt clase Java care respect˘ a un set de modele de design care le
face mai u¸ sor de utilizat, cu instrumente de dezvoltare ¸ si alte componente.
Modelele de design JavaBean ofer˘ a acces la starea intern˘ a a bean-ului, prin
dou˘ a metode:
accessors – folosite pentru a citi starea unui JavaBean;
mutators – folosite pentru a schimba starea unui JavaBean.
Mutators sunt ˆ ıntotdeauna precedate de set, urmat de numele propriet˘ at ¸ii.
Primul caracter din numele propriet˘ at ¸ii trebuie s˘ a ﬁe majuscul˘ a. Valoarea retur-
nat˘ a este ˆ ıntotdeauna void; modiﬁc˘ a doar valorile de proprietate, ele nu le pot

24 CAPITOLUL 1. TEHNOLOGII FOLOSITE
prelua. Mutator-ul, pentru o proprietate simpl˘ a, preia doar un singur parametru
ˆ ın semnatura sa, care poate ﬁ de orice tip. Mutators sunt de multe ori poreclit ¸i
setters dup˘ a preﬁxul lor. Exemplu:
public void setAge(Double age)
Un model de design similar este utilizat pentru a crea semnatura metodei
accesor. Metodele accesor sunt ˆ ıntotdeauna precedate de get, urmat de numele
propriet˘ at ¸ii. Primul caracter din numele propriet˘ at ¸ii trebuie s˘ a ﬁe majuscul˘ a. Va-
loarea returnat˘ a se va potrivi cu parametrul metodeiˆ ın mutator-ul corespunz˘ ator.
Nu este surprinz˘ ator, accessors sunt adesea numit ¸i getters . Exemplu:
public Double getAge()
Sun a introdus JavaBeans pentru a lucra cu componente GUI, dar ele sunt
acum folosite de ﬁecare aspect de dezvoltare Java, inclusiv aplicat ¸ii web. Cˆ and
inginerii Sun au dezvoltat clase de extensie a tag-ului JSP, le-au proiectat pentru
a lucra cu JavaBeans. Datele dinamice pentru o pagin˘ a pot ﬁ trecute ca un Java-
Bean, ¸ si tag-ul JSP poate folosi apoi propriet˘ at ¸ile de bean pentru a personaliza
ie¸ sirea.
Model 2
Caietul de sarcini Model 2, descris ca o arhitectur˘ a care utilizeaz˘ a servlet-uri
¸ si pagini JSP ˆ ımpreun˘ a ˆ ın aceea¸ si aplicat ¸ie. Termenul de Model 2 a disp˘ arut de
la versiuni mai tˆ arzii, dar acesta r˘ amˆ ane ˆ ın uz popular printre dezvoltatori web
Java.
ˆIn conformitate cu Model 2, servlet se ocup˘ a de acces la date ¸ si ﬂuxul de
navigat ¸ie, ˆ ın timp ce paginile JSP se ocup˘ a de prezentare. Model 2 le permite
dezvoltatorilor Java ¸ si HTML s˘ a lucreze ﬁecare pe cont propriu la o parte a
aplicat ¸iei.
Cadrul Struts se bazeaz˘ a pe arhitectura Model 2. Acesta ofer˘ a un servlet con-
troler pentru a gestiona ﬂuxul de navigat ¸ie t ¸i clase speciale pentru a ajuta accesul
la date. O important˘ a bibliotec˘ a personalizat˘ a este la pachet cu framework-ul
care-l face pe Struts u¸ sor de utilizat, cu pagini JSP.
1.2.3 Struts, v azut de sus
Struts folose¸ ste arhitectura Model 2. ActionServlet din Struts controleaz˘ a
ﬂuxul navigat ¸iei. O alt˘ a clas˘ a Struts, Action, este folosit˘ a pentru a accesa clasele
de business. Cˆ and ActionServlet-ul prime¸ ste o cerere de la container, folose¸ ste
URI (sau ”cale”/”path”) pentru a determina ce Action va manevra cererea. Un
Action poate valida intr˘ arile ¸ si accesa stratul de business pentru a primi informat ¸ii
de la baza de date sau de la alte servicii de date.

1.2. INTRODUCERE ^IN STRUTS WEB FRAMEWORK 25
Pentru a valida intr˘ arile sau a le folosi pentru a aduce la zi baza de date, Action
trebuie s˘ a ¸ stie care valori au fost supuse spre examinare. Cu atˆ at mai bine decˆ at
a fort ¸a Action-ul pentru a trimite aceste valori ˆ ın afara cererii, ActionServlet-ul
le leag˘ a ˆ ıntr-un JavaBean. Intr˘ arile de bean-uri sunt subclase a clasei Action-
Form din Struts. ActionServlet-ul poate determina ce ActionForm folose¸ ste prin
aruncarea unei priviri la calea cererii, ˆ ın acela¸ si fel cum Action-ul a fost selectat.
Un ActionForm extinde org.apache.struts.action.ActionForm .
Fiecare cerere HTTP trebuie s˘ a r˘ aspund˘ a cu un r˘ aspuns HTTP. De obicei,
un Action Struts nu expediaz˘ a ci ˆ ınainteaz˘ a cererea c˘ atre o alt˘ a resurs˘ a, cum ar
ﬁ o pagina JSP. Struts ˆ ınzestreaz˘ a o clas˘ a ActionFroward care poate ﬁ folosit˘ a
pentru a stoca calea paginii sub un nume logic. Cˆ and a fost completat˘ a logica de
afacere, Action-ul selecteaz˘ a ¸ si returneaz˘ a un ActionForward c˘ atre servlet. Apoi
servlet-ul folose¸ ste calea stocat˘ a ˆ ın obiectul ActonForward pentru a apela pagina
¸ si a completa r˘ aspunsul.
Struts leag˘ a aceste detalii ˆ ıntr-un obiect ActionMapping. Fiecare ActionMap-
ping este relatat pe o cale speciﬁc˘ a. Cand calea este cerut˘ a, servlet-ul reface
obiectul ActionMapping. Maparea spune servlet-ului care dintre Action, Action-
Forms ¸ si ActionForwards s˘ a foloseasc˘ a.
Toate aceste detalii, Action, ActionForms, ActionForwards, ActionMappings
¸ si cˆ ateva alte lucruri sunt declarate ˆ ın ﬁ¸ sierul struts-conﬁg.xml. ActionServlet-
ul cite¸ ste acest ﬁ¸ sier la ˆ ınceput ¸ si creaz˘ a conﬁgurat ¸ia bazei de date. ˆIn timpul
rul˘ arii, Struts refer˘ a obiectele create cu ﬁ¸ sierul de conﬁgurat ¸ie, nu ﬁ¸ sierul ˆ ın sine.
Figura (1.10) ilustreaz˘ a cum aceste componente se contopesc.
Figura 1.10: Struts, v˘ azut de sus
Crearea unei simple aplicat ii
Dezvoltatorii ¸ si multi dintre noi ˆ ınv˘ at ¸˘ am prin exemple. Voi alc˘ atui o alpicat ¸ie
web funct ¸ional˘ a simpl˘ a. Aceasta va memora username-uri ¸ si parole.

26 CAPITOLUL 1. TEHNOLOGII FOLOSITE
Struts – Concret
Prima aplicat ¸ie Struts va ﬁ o simpl˘ a aplicat ¸ie de ˆ ınregistrare. Utilizatorului i
se va aﬁ¸ sa un ecran de ˆ ınregistrare care va cont ¸ine trei cˆ ampuri: username, parol˘ a
¸ si conﬁrmarea parolei. O ˆ ınregistrare cu succes necesit˘ a ca cele dou˘ a parole s˘ a ﬁe
identice. Dac˘ a ˆ ınregistrarea este cu succes, controloul coboar˘ a c˘ atre o pagin˘ a care
spune succesful! . Dac˘ a nu sunt identice, atunci pagina va spune failure . Acest
exemplu simplu este proiectat pentru a demonstra urm˘ atoarele:
Crearea de form-uri HTML
Capturarea intr˘ arilor dintr-un form HTML
Procesarea intr˘ arilor
Schimbarea controlului bazat pe intr˘ ari dinamice
Pentru a completa aplicat ¸ia, va ﬁ nevoie de a crea:
un ActionForm
un Action
ﬁ¸ sierul struts-conﬁg.xml
trei pagini.
Crearea ActionForm-ului
Un ActionForm este un JavaBean care extinde org.apache.struts.Action
Form . Acest obiect capteaz˘ a intr˘ arile din cˆ ampuri ¸ si le trimite prin request. Cˆ and
un browser web submite un form, creaz˘ a parametri ˆ ın request pentru ﬁecare
cˆ amp al form-ului. ActionForm-ul are o proprietate corespondent˘ a pentru ﬁecare
cˆ amp din HTML form. ActionServlet-ul potrive¸ ste parametrii ˆ ın cerere cu cu
propriet˘ at ¸i de pe ActionForm. Cˆ and corespund, ActionServlet apeleaz˘ a metoda
setter din proprietate ¸ si ˆ ıi paseaz˘ a valoarea din request.
ˆIn exemplul prezentat, cˆ ampul username din HTML form va avea nevoie de o
metod˘ a setUsername(String) . La fel ¸ si pentru password1 ¸ si password2. Aceste
metode sunt responsabile de popularea variabilelor, instant ¸e ascunse ˆ ın interiorul
RegisterForm-ului JavaBean. Codul surs˘ a este ar˘ atat ˆ ın Notarea (1.1). Se creaz˘ a
o clas˘ a RegisterForm.java care cont ¸ine codul aﬁ¸ sat ˆ ın Notarea (1.1).

1.2. INTRODUCERE ^IN STRUTS WEB FRAMEWORK 27
Notarea 1.1 :RegisterForm.java
package app ;
import org . apache . s t r u t s . a c t i o n . ;
p u b l i c c l a s s RegisterForm e x t e n d s ActionForm f
p r o t e c t e d S t r i n g username ;
p r o t e c t e d S t r i n g password1 ;
p r o t e c t e d S t r i n g password2 ;
p u b l i c S t r i n g getUsername ( ) fr e t u r n t h i s . username ; g;
p u b l i c S t r i n g getPassword1 ( ) fr e t u r n t h i s . password1 ; g;
p u b l i c S t r i n g getPassword2 ( ) fr e t u r n t h i s . password2 ; g;
p u b l i c v o i d setUsername ( S t r i n g username ) ft h i s .
username = username ; g;
p u b l i c v o i d setPassword1 ( S t r i n g password ) ft h i s .
password1 = password ; g;
p u b l i c v o i d setPassword2 ( S t r i n g password ) ft h i s .
password2 = password ; g;
g
Crearea RegisterAction-ului
Un Action este o clas˘ a Java care extinde org.apache.struts.Action . Acesta
populeaz˘ a ActionForm-ul apoi ˆ ıl paseaz˘ a c˘ atre Action. Un Action este, ˆ ın gene-
ral, responsabil de validarea intr˘ arilor, accesarea informat ¸iei de business ¸ si deter-
minarea c˘ arui ActionForward s˘ a returneze servlet-ul. Cre˘ am o clas˘ a RegisterAc-
tion.java care cont ¸ine urm˘ atorul cod:
Notarea 1.2 :RegisterAction.java
package app ;
import org . apache . s t r u t s . a c t i o n . ;
import j a v a x . s e r v l e t . http . ;
import j a v a . i o . ;
p u b l i c c l a s s R e g i s t e r A c t i o n e x t e n d s Action f
p u b l i c ActionForward perform ( ActionMapping mapping ,
ActionForm form , H t t p S e r v l e t R e q u e s t req ,
H t t p S e r v l e t R e s p o n s e r e s ) f
// 1
RegisterForm r f = ( RegisterForm ) form ;
S t r i n g username = r f . getUsername ( ) ;
S t r i n g password1 = r f . getPassword1 ( ) ;
S t r i n g password2 = r f . getPassword2 ( ) ;
// 2

28 CAPITOLUL 1. TEHNOLOGII FOLOSITE
i f ( password1 . e q u a l s ( password2 ) ) f
t r y f
// 3
U s e r D i r e c t o r y . g e t I n s t a n c e ( ) . s e t U s e r ( username ,
password1 ) ;
r e t u r n mapping . f i n d F o r w a r d (" s u c c e s s ") ;
g
catch ( U s e r D i r e c t o r y E x c e p t i o n e ) f
r e t u r n mapping . f i n d F o r w a r d (" f a i l u r e ") ;
g
g
// 4
r e t u r n mapping . f i n d F o r w a r d (" f a i l u r e ") ;
g
g
La 1 intrarea ActionForm-ului este pasat˘ a c˘ atre RegisterForm. Apoi putem ex-
trage username, password1 ¸ si password2. Dac˘ a cele dou˘ a parole corespund la
2, se adaug˘ a utilizatorul ˆ ın UserDirectory la 3 ¸ si se returneaz˘ a ActionForward-
ul asociat cu success . UserDirectory este o clas˘ a ajutatoare care ˆ ınregistreaz˘ a
username-urile ¸ si parolele ˆ ıntr-un ﬁ¸ sier de propriet˘ at ¸i standard. Altfel, se re-
turneaz˘ a ActionForward-ul failure la 4. Cˆ and se creaz˘ a ﬁ¸ sierul struts-conﬁg la
pasul urm˘ ator, se speciﬁc˘ a obiectele ActionForward care reprezint˘ a success sau
failure .
Crearea sierului de congurat ie
Acest ﬁ¸ sier cont ¸ine detaliile de care ActionServlet-ul are nevoie pentru a ma-
nevra cererile f˘ acute din aplicat ¸ie. ˆIn primul rˆ and, adaug˘ a /register pentru
atributul path ˆ ın elementul <action> . ActionServlet-ul folose¸ ste dinainte URI-
ul prin containerul web pentru a selecta corect clasa Action. Acest URI este
potrivit cu atributul path dintr-un ActionMapping. ˆIn acest caz, calea dat˘ a de
cerere trebuie s˘ a corespund˘ a cu /register dup˘ a eliminarea vreunui suﬁx sau
preﬁx. Preﬁxul sau suﬁxul este, de obicei, /do/ sau.do.ˆIn exemplul de fat ¸˘ a,
acesta va ﬁ .do. Cˆ and URI are o extensie .do, containerul ¸ stie s˘ a trimit˘ a ce-
rerea c˘ atre ActionServlet-ul nostru. Struts taie automat extensia, a¸ sa c˘ a nu e
nevoie s˘ a o includ aici. Urm˘ atorul pas este de a ad˘ auga: registerForm atribu-
tului name din elementul <action> . Acest element folose¸ ste atributul name pen-
tru a indic˘ a ce bean din ActionForm va ﬁ creat de ActionServlet ¸ si populat de
cˆ ampurile submitted. Apoi, ad˘ aug˘ am: app.RegisterAction atributului type ˆ ın
elementul <action> . Acest atribut este folosit de ActionServlet pentru a iden-
tiﬁca Action-ul folosit pentru procesarea cererii. ˆIn acest punct, ˆ ıntr-un element
<forward> , se adaug˘ a success ˆ ın atributul name ¸ si/success.html ˆ ın atributul
path .ˆIn ﬁnal, se adaug˘ a failure atributului name ¸ si /failure.html atributu-
luipath ale altor tag-uri <forward> . Aceste elemente vor crea obiectele Action-

1.2. INTRODUCERE ^IN STRUTS WEB FRAMEWORK 29
Forward-ul pe care le voi folosi pentru a modiﬁca ﬂuxul de control al aplicat ¸iei.
Elementul <forward> deﬁne¸ ste asociat ¸iile ˆ ıntre denumirile logice folosite ˆ ın Reg-
isterAction.
Notarea 1.3 :struts-conﬁg.xml
<txml v e r s i o n ="1.0" encoding="ISO 8859 1" t>
<!DOCTYPE s t r u t s c o n f i g PUBLIC
"//Apache Software Foundation //DTD S t r u t s C o n f i g u r a t i o n 1.0//
EN"
" http :/ / j a k a r t a . apache . org / s t r u t s / dtds / s t r u t s c o n f i g 10 . dtd" >
<s t r u t s c o n f i g >
<form beans>
<form bean name="r e g i s t e r F o r m " type="app . RegisterForm
"/>
</form beans>
<a c t i o n mappings >
<a c t i o n path="/ r e g i s t e r " type="app . R e g i s t e r A c t i o n "
name="r e g i s t e r F o r m" >
<forward name="s u c c e s s " path="/ s u c c e s s . html"/ >
<forward name=" f a i l u r e " path="/ f a i l u r e . html"/ >
</a c t i o n >
</a c t i o n mappings >
</ s t r u t s c o n f i g >
Framework-ul folose¸ ste ﬁ¸ sierul struts-config.xml ca un descriptor de de-
ployment. Acesta nepermite crearea ¸ si schimbarea ActionMapping-ul asociat cu
calea f˘ ar˘ a a recompila clasa Java. Se poate modiﬁca ¸ si, cum paginile sunt legate,
f˘ ar˘ a a modiﬁca template-ul JSP.
Crearea paginilor
Pasul ﬁnal este crarea paginilor succes.html ,failure.html ¸ siregister.jsp .
Notarea 1.4 :success.html
<HTML>
<HEAD>
<TITLE>SUCCESS </TITLE >
</HEAD>
<BODY>
R e g i s t r a t i o n succeeded !
<P><A h r e f =" r e g i s t e r . j s p " >t r y anothert </A></P>
</BODY>
</HTML>

30 CAPITOLUL 1. TEHNOLOGII FOLOSITE
Notarea 1.5 :failure.hml
<HTML>
<HEAD>
<TITLE>FAILURE </TITLE >
</HEAD>
<BODY>
R e g i s t r a t i o n f a i l e d !
<P><A h r e f =" r e g i s t e r . j s p " >t r y againt </A></P>
</BODY>
</HTML>
Notarea 1.6 :register.jsp
<% @ t a g l i b u r i ="/WEB INF/ s t r u t s form . t l d " p r e f i x ="form " % >
<form : form a c t i o n=" r e g i s t e r . do" >
UserName: <form : t e x t p r o p e r t y="username"/ ><br>
e n t e r password : <form : password p r o p e r t y="password1"/ ><br>
ree n t e r password : <form : password p r o p e r t y="password2"/ ><br
>
<form : submit v a l u e=" R e g i s t e r "/ >
</form : form >
ˆIn acest moment, aplicat ¸ia cu Struts este gata. O voi ˆ ıncerca.
Figura 1.11: Aplicat ¸ia Register
1.2.4 S a ne uit am ^ napoi
Acum fac un conspect asupra la ceea ce-am f˘ acut, cum a lucrat ¸ si de ce e
nevoie pentru a construi o aplicat ¸ie Struts.
1.2.5 Ce am facut
Pentru a monta aplicat ¸ia Register am creat urm˘ atoarele:
RegisterForm – ActionForm
RegisterAction – Action

1.2. INTRODUCERE ^IN STRUTS WEB FRAMEWORK 31
trei pagini
{pagina de ˆ ınregistrare
{pagina de succes
{pagina de esec
ﬁ¸ sierul struts-config.xml
Cum a mers
Se acceseaz˘ a din browser http://localhost:8080/register/register.jsp . Se intro-
duc username-ul ¸ si parola, apoi click Register. Browser-ul posteaz˘ a cont ¸inutul
form-ului ca o cerere HTTP. Containerul vede ce cerere va ﬁ fost trimis˘ a c˘ atre
o cale ˆ ınregistrat˘ a ˆ ın ActionServlet-ul din Struts. Aceast˘ a cerere este, apoi,
ˆ ınaintat˘ a c˘ atre ActionServlet ¸ si procesat˘ a de RegisterAction. RegisterAction-ul
valideaz˘ a intr˘ arile ˆ ınainte de a returna un ActionForward de succes sau e¸ sec.
Figura 1.12: Arhitectura aplicat ¸iei Register
Uitˆ andu-m˘ a la register.jsp din Notarea (1.6) observ c˘ a form submite c˘ atre
URI-ul /register . Dar dac˘ a m˘ a uit la pagina care este submis˘ a voi vedea c˘ a
aceasta este trimis˘ a c˘ atre register.do . Tag-ul form-ului Struts adaug˘ a suﬁxul
.do. Cˆ and prime¸ ste o cerere, primul lucru pe care ActionServlet-ul ˆ ıl face este s˘ a
veriﬁce map˘ arile corespunz˘ atoare path-ului. Map˘ arile sunt JavaBean-uri create
de Struts prin citirea ﬁ¸ sierului struts.config.xml . Se poate vedea c˘ a am creat
maparea pentru calea /register , ˆ ın Notarea (1.3), folosind acest element:
<action
path="/register"
type="app.RegisterAction"
name="registerForm"
input="/register.jsp">
Apoi, ActionServlet-ul veriﬁc˘ a dac˘ a proprietatea name este asociat˘ a cu maparea:

32 CAPITOLUL 1. TEHNOLOGII FOLOSITE
<action
path="/register"
type=" app.RegisterAction"
name="registerForm"
input="/register.jsp">
Maparea /register speciﬁc˘ a un form bean prin numele registerForm -ului.
Servlet-ul folose¸ ste acest nume pentru a se uita la obiectul ActionFormBean-ul
corespondent. Tipul speciﬁcat de form bean este folosit pentru a crea obiectul
ActionForm:
<form-beans>
<form-bean
name="registerForm"
type="RegisterForm"/>
</form-beans>
<action-mappings>
<action
path="/register"
type=" app.RegisterAction"
name="registerForm"
input="/register.jsp">
<forward
name="success"
path="/success.html"/>
<forward
name="failure"
path="/failure.html"/>
</action>
</action-mappings>
ˆIn acest caz, servlet-ul va folosi clasa RegisterForm
<form-beans>
<form-bean
name="registerForm"
type="app.RegisterForm"/>
</form-beans>
Odat˘ a ce RegisterForm este instant ¸iat˘ a, ActionServlet-ul va ˆ ıncerca s˘ a apeleze
metodele setter din RegisterForm pentru orice intrare din cˆ ampurile din cerere.
ˆIn exemplul de fat ¸˘ a, acestea sunt: setUsername ,setPassword1 ,setPassword2 .
Dac˘ a o metod˘ a setter nu exist˘ a pentru un paramentru de intrare, atunci acel
parametru este ignorat. Atributul type al obiectului ActionMapping este numele

1.2. INTRODUCERE ^IN STRUTS WEB FRAMEWORK 33
clasei pe care ActionServlet-ul ˆ ıl folose¸ ste pentru a instant ¸ia un ActionForm. ˆIn
acest caz, acesta va folosi obiectul RegisterAction pe care l-am creat. Metoda
perform a obiectului RegisterAction este invocat˘ a ¸ si a adoptat o referint ¸˘ a c˘ atre
RegisterForm, care a fost creat ¸ si populat ˆ ın etapa anterioar˘ a:
<action
path="/register"
type="app.RegisterAction"
name="registerForm"
input="/register.jsp">
<forward
name="success"
path="/success.html"/>
<forward
name="failure"
path="/failure.html"/>
</action>
ˆIn funct ¸ie de rezultatul metodei perform , (a se vedea Listarea 1,2), una dintre
cele dou˘ a ActionForward-uri este returnat˘ a. Metoda findForward() ˆ ı¸ si folose¸ ste
singurul parametru String pentru a gasi un obiect forward care se potrive¸ ste cu
proprietatea name . Proprietatea path este folosit˘ a de c˘ atre ActionServlet pentru
a determina care dintre pagini ar trebui completate pentru r˘ aspuns:
<forward
name="success"
path="/success.html" />
<forward
name="failure"
path="/failure.html" />

Capitolul 2
Fundamente – MySQL si WASCE
2.1 MySQL
2.1.1 Scurt a introducere
O baz˘ a de date este o aplicat ¸ie separat˘ a, care stocheaz˘ a o colect ¸ie de date.
Fiecare baz˘ a de date are una sau mai multe API-uri distincte pentru crearea,
accesarea, administrarea, c˘ autarea ¸ si replicarea datelor pe care le det ¸ine. ˆIn
zilele noastre se folosesc sisteme de management al bazelor de date relat ¸ionale
(RDBMS) pentru a stoca ¸ si manageria un volum imens de date. Aceasta se
nume¸ ste baz˘ a de date relat ¸ional˘ a, deoarece toate datele sunt stocate ˆ ın diferite
tabele ¸ si relat ¸iile sunt stabilite folosind chei primare sau a altor chei cunoscute
sub numele de chei externe. Un sistem de management de baze de date (RDBMS)
este un software care:
permite s˘ a punem ˆ ın aplicare o baz˘ a de date cu tabele, coloane, ¸ si indici,
garanteaz˘ a integritatea referent ¸ial˘ a ˆ ıntre rˆ anduri de diferite tabele,
actualizeaz˘ a indicii automat,
interpreteaz˘ a o interogare SQL ¸ si combin˘ a informat ¸iile din diferite tabele.
Terminologia RDBMS
ˆInainte de a trece la explicarea sistemulului de baze de date MySQL, voi revizui
cˆ ateva deﬁnit ¸ii legate de baze de date.
Baz a de date : O baz˘ a de date este o colect ¸ie de tabele, cu date aferente.
Tabel : Un tabel este o matrice cu date. Un tabel ˆ ıntr-o baz˘ a de date arat˘ a
ca o foaie de calcul simplu.
34

2.1. MYSQL 35
Coloan a : O coloan˘ a (element de date) cont ¸ine date doar de un singur tip,
de exemplu, coloana CodPo¸ stal.
R^ and : Un rˆ and (intrarea sau ˆ ınregistrarea) este un grup de date ˆ ınrudite.
Redundant a : Stocarea de date de dou˘ a ori, redundant pentru a face sis-
temul mai repede.
Cheie primar a : O cheie primar˘ a este unic˘ a.
Cheie extern a : O cheie extern˘ a este PIN-ul de leg˘ atur˘ a ˆ ıntre dou˘ a tabele.
Cheie compus a : O cheie compus˘ a (cheie compozit) este o cheie care
const˘ a din mai multe coloane.
Index : Un index ˆ ıntr-o baz˘ a de date seam˘ an˘ a cu un indice de la partea din
spate a unei c˘ art ¸i.
Integritate referent ial a : Integritatea referent ¸ial˘ a se asigur˘ a c˘ a o valoare
cheie extern˘ a arat˘ a ˆ ıntotdeauna un rˆ and existent.
MySQL Database
MySQL este un RDBMS rapid, u¸ sor de utilizat, folosit pentru multe ˆ ıntreprin-
deri mici ¸ si mari. MySQL este dezvoltat, comercializat, ¸ si sust ¸inut de MySQL
AB, care este o companie suedez˘ a. MySQL a devenit atˆ at de popular, din mai
multe motive bune.
MySQL este lansat sub o licent ¸˘ a open-source.
MySQL este un program foarte puternic. Se ocupa de un subset mare de
funct ¸ionalit˘ at ¸i a pachetelor de baze de date mai scumpe ¸ si puternice.
MySQL funct ¸ioneaz˘ a pe mai multe sisteme de operare ¸ si cu mai multe
limbaje, inclusiv PHP, Perl, C, C + +, Java, etc.
MySQL act ¸ioneaz˘ a foarte rapid ¸ si funct ¸ioneaz˘ a bine chiar ¸ si cu seturi mari
de date.
MySQL suport˘ a baze de date mari, de pˆ an˘ a la 50 de milioane de rˆ anduri sau
mai multe ˆ ıntr-un tabel. Fi¸ sierul limit˘ a de dimensiune implicit˘ a pentru un
tabel este de 4GB, dar se poate cre¸ ste (ˆ ın cazul ˆ ın care sistemul de operare
se poate descurca) la o limit˘ a teoretic˘ a de 8 milioane de terabytes (TB).

36 CAPITOLUL 2. FUNDAMENTE – MYSQL S I WASCE
2.2 WASCE IDE
2.2.1 Introducere^ n o WebSphere Application Server Com-
munity Edition
IBM WebSphere Application Server Community Edition (Community Edition)
este un membru al familiei Application Server IBM WebSphere. Community Edi-
tion este o aplicat ¸ie pe o platform˘ a server Java Enterprise Edition (Java EE) con-
struit˘ a pe Apache Geronimo, proiect server de aplicat ¸ii open source Apache Soft-
ware Foundation. Comunitatea care foloseste Community Edition este format˘ a
din tot felul de oameni ¸ si companii, care proiecteaz˘ a, dezvolt˘ a, implementeaz˘ a,
sau utilizezeaz˘ a solut ¸ii Java EE.
2.2.2 Familia de aplicat ii server WebSphere
ˆIn funct ¸ie de nevoi, familia WebSphere Application Server include edit ¸ii diferite,
care variaz˘ a ˆ ın capacitate ¸ si scalabilitate. A¸ sa cum se arat˘ a ˆ ın Figura (2.1), ˆ ın
primul rˆ and ˆ ın familie, la colt ¸ul din stˆ anga jos este Community Edition. A¸ sa
cum am ment ¸ionat, Community Edition este un server de aplicat ¸ie u¸ sor putˆ and
ﬁ utilizat ˆ ın dezvoltare, testare, sau pe product ¸ie pentru a rula aplicat ¸ii Java EE.
Pentru o companie mic˘ a, Community Edition este cea mai bun˘ a alegere, atˆ at din
punct de vedere tehnic cˆ at ¸ si economic. Community Edition este liber pentru a ﬁ
desc˘ arcat si utilizat. Poate ﬁ instalat ¸ si s˘ a-l rulat ˆ ıntr-o perioad˘ a scurt˘ a de timp.
Figura 2.1: Familia aplicat ¸iilor WASCE

2.2. WASCE IDE 37
2.2.3 T inta utilizatorilor Community Edition
Community Edition este ideal pentru:
dezvoltatorii de aplicat ¸ii care necesit˘ a standarde Java EE server pentru
aplicat ¸ii server Java EE, ¸ si care doresc s˘ a se concentreze pe aplicat ¸iile de
baz˘ a de afaceri bazate pe servicii de pre-integrate;
administratorii de sistem care au nevoie de un mediu standard ¸ si ﬂexibil de
administrare ¸ si scalabilitate;
furnizori independent ¸i de software (ISV) ¸ si alte tipuri de furnizori de solut ¸ii
care doresc s˘ a ˆ ımpacheteze sau ˆ ıncorporeze o aplicat ¸ie Java Server EE full-
featured, ca parte din solutiile lor;
intreprinderile mici ¸ si mijlocii care au nevoie de o aplicat ¸ie server entry-level
Java EE cu suport de clas˘ a mondial˘ a pentru aplicat ¸iile ¸ si operat ¸iunile lor;
departamentele de companii care au nevoie de o product ¸ie pe un mediu
Java EE far˘ a cheltuirea bugetului;
pasionat ¸ii de Java EE ¸ si cei de tehnologia de ultim˘ a or˘ a care doresc s˘ a
experimenteze tehnologii open source;
elevii, profesorii ¸ si alt ¸i utilizatori academici care doresc o aplicat ¸ie server
Java EE extrem de versatil˘ a pentru predare, cursuri, proiecte ¸ si cercetare.

38 CAPITOLUL 2. FUNDAMENTE – MYSQL S I WASCE
2.2.4 Componente ale Community Edition
Apache Geronimo reune¸ ste tehnologiile de comunitate open source mai larg˘ a
pentru a sprijini stiva Java EE. De exemplu: Apache Tomcat, ActiveMQ, Tranql,
OpenEJB ¸ si a¸ sa mai departe. Apache Geronimo folose¸ ste licent ¸a Apache, este
extrem de personalizabil, ¸ si este condus de comunitate. Figura (2.2) prezint˘ a
componentele Community Edition.
Figura 2.2: Componente ale Community Edition
Din ﬁgur˘ a se poate vedea c˘ a CE este alc˘ atuit din:
Nucleul Apache Geronimo , ofer˘ a un cadru pentru ad˘ augarea de alte
servicii, cum ar ﬁ serviciile personalizate de afaceri;
Componente de v^ arf de care dezvoltatorii au nevoie, cum ar ﬁ servicii
web, securitate, ¸ si de mesagerie, sunt integrate ¸ si testate cu Community
Edition, astfel incˆ at dezvoltatorii nu trebuie s˘ a i¸ si fac˘ a griji in privint ¸a
oric˘ arei lucrari de integrare personalizate sau probleme de compatibilitate;
Consola de administrator , instrument puternic care permite dezvolta-
torilor s˘ a deﬁneasc˘ a conexiuni Tomcat (HTTP, HTTPS, AJP), pool-uri de
baze de date ¸ si domenii de securitate, f˘ ar˘ a nici o codiﬁcare sau repornire a
serverului.
ˆIn urm˘ atorul tabel se aﬂ˘ a o scurt˘ a descriere a componentelor integrate majore
ˆ ın Community Edition:

2.2. WASCE IDE 39
Componente Descriere
Apache Geronimo ker-
nelUn proiect open source Java EE 5 server care ofer˘ a fun-
damentul pentru Community Edition
Apache Derby Un server mic incorporat cu baze de date, amprenta
potrivit˘ a pentru proiecte foarte mici ¸ si simple.
Apache Tomcat Un container Web-tier, care este utilizat ˆ ın imple-
mentarea de referint ¸˘ a pentru tehnologiile Java Servlet
¸ si JavaServer Pages
Apache OpenJPA O implementare a persistent ¸ei API Java
WebSphere Applica-
tion Server Commu-
nity Edition Server
Adapter (Eclipse
plug-in)Un plug-in utilizat pentru dezvoltarea, implementarea
¸ si depanarea aplicat ¸iilor Java EE ˆ ın Eclipse IDE.
JVM support Asistent ¸˘ a IBM JVM ¸ si compatibil cu Sun Java VM
2.2.5 Instalare Community Edition
Desc arcarea
Se descarc˘ a de la http://www.ibm.com/developerworks/downloads/ws/wasce/ .
Figura 2.3: Pagina de descarcare WASCE
Community Edition poate rula pe Linux, UNIX sau Windows ¸ si este foarte u¸ sor
de instalat. El nu are limite de acordare a licent ¸elor ˆ ın ceea ce prive¸ ste resursele
hardware care le putet ¸i utiliza. Instalarea Community Edition este forma˘ at din
trei etape de baz˘ a:
1.desc˘ arcarea Community Edition,
2.instalarea unui Java Runtime Environment (JRE), ¸ si

40 CAPITOLUL 2. FUNDAMENTE – MYSQL S I WASCE
3.instalarea Community Edition.
Figura (2.4) ilustreaz˘ a pa¸ sii de urmat pentru a ˆ ıncepe cu Community Edi-
tion. Se poate obt ¸ine cea mai recent˘ a versiune a Community Edition accesˆ and
http://www.ibm.com/developerworks/downloads/ws/wasce/ a¸ sa cum se arat˘ a ˆ ın
Figura (2.3)
Figura 2.4: Pa¸ sii pentru a porni cu Community Edition
Validarea instal arii
ˆIn scopul de a ne asigura c˘ a Community Edition a fost instalat corect, se
porne¸ ste serverul Community Edition ¸ si se lanseaz˘ a consola de administrare. Pe
Windows se porne¸ ste serverul Community Edition de la Start – >Programe –
>IBM WebSphere – >Application Server Community Edition – >se porne¸ ste
serverul. O fereastr˘ a negr˘ a, a¸ sa cum se arat˘ a ˆ ın Figura (2.5) va aparea ¸ si va aﬁ¸ sa
o list˘ a de mesaje. Acest lucru poate dura cˆ ateva minute.
Figura 2.5: Pornirea server-ului
Dup˘ a ce se aﬁ¸ seaz˘ a mesajul ”Server started”, se merge ˆ ınapoi la acela¸ si me-
niu Windows ¸ si se selecteaz˘ a consola administrativ˘ a. Aceasta va porni Consola
administrativ˘ a ˆ ın browser-ul situat la https://localhost:8443/console .
Figura 2.6: Consola server-ului

2.2. WASCE IDE 41
Pentru conectare la consola administrativ˘ a, utilizatorul implicit este system
iar parola este manager . Cˆ and se face clic pe Login, ar trebui s˘ a se vad˘ a fereastra
principal˘ a Administrative Console.
2.2.6 Dezvoltarea cu Community Edition
Figura (2.7) ofer˘ a o privire de ansamblu despre dezvoltarea cu Community
Edition. ˆIn partea dreapt˘ a a ﬁgurii, un dezvoltator creeaz˘ a o aplicat ¸ie Java EE
folosind Eclipse ¸ si implementeaz˘ a folosind WEP pe server Community Edition
ar˘ atat ˆ ın mijlocul ﬁgurii. JSP-uri sau Servlets create ¸ si stocate ˆ ın containerul de
Web ˆ ın Community Edition pot ﬁ apoi accesate prin intermediul HTTP de c˘ atre
un client Web aﬁ¸ sate ˆ ın partea dreapt˘ a a ﬁgurii.
Figura 2.7: Dezvoltare cu Community Edition
2.2.7 Lucrul cu baze de date
Community Edition conectarea la baze de date
Figura (2.7) ofer˘ a o imagine de ansamblu a procesului de urmat pentru a accesa
o baz˘ a de date.
Figura 2.8: Conectare la Baza de date

42 CAPITOLUL 2. FUNDAMENTE – MYSQL S I WASCE
Pe partea dreapt˘ a (1), un administrator de baze de date (DBA) creeaz˘ a o
baz˘ a de date ¸ si o ˆ ıncarc˘ a cu date. Apoi, ˆ ın (2), conﬁgureaz˘ a DBA ¸ si ˆ ınregistreaz˘ a
aceast˘ a surs˘ a de dateˆ ın Community Edition Java Naming ¸ siˆ ın Directory Interface
(JNDI).
Pe partea stˆ ang˘ a, atunci cˆ and clientul Web solicit˘ a unele pagini care necesit˘ a
acces la baza de date, corespunzatoare JSP / servlet la (3) se va efectua mai
intˆ ai o c˘ autare JNDI pentru a g˘ asi sursa de date ˆ ınregistrate, ¸ si va crea apoi un
obiect de conexiune pentru a obt ¸ine acces baza de date cum este descris ˆ ın (4).
Obiectele de conectare sunt puse ˆ ın comun de c˘ atre serverul Community Edition
pentru reutilizare, aplicare, iar datele pot ﬁ accesate prin intermediul JDBC ˆ ın
(5).
Pa sii pentru a lucra cu o baz a de date ^ n Community Edition
Pentru a dezvolta o aplicat ¸ie web cu acces la baza de date ˆ ın Community
Edition, etapele tipice sunt:
1.crearea unei baze de date;
2.conﬁgurarea ¸ si implementarea unui pool de baze de date prin intermediul
consolei administrative Community Edition;
3.executarea declarat ¸iilot SQL pentru a ˆ ınc˘ arca unele date prin pool-ul de
date.

Capitolul 3
Aplicat ie: Procesul de etichetare
al pieselor de schimb
3.1 Descrierea aplicat iei
3.1.1 Motivul aplicat iei
Aceast˘ a aplicat ¸ie reprezint˘ a proiectul ˆ ın cadrul unui stagiu de practic˘ a la uzina
Dacia Group Renault Romˆ ania.
Are ca scop realizarea unei aplicat ¸ii web, multilimb˘ a, securizat˘ a (cu IPN,
Parol˘ a ARCA) ¸ si cu ﬂuxul de gestiune al etichetelor. Aplicat ¸ia numit˘ a EPR
– Aplicat ¸ie tip˘ arire etichete – are ca obiective:
1.securizarea aplicat ¸iei prin IPN ¸ si parol˘ a,
2.reducerea timpului de introducere a datelor prin implementarea modulului
de gestiune al etichetelor ¸ si oferirea unui raport general ˆ ın ceea ce prive¸ ste
etichetele – exportul ˆ ın Excel ¸ si
3.imprimarea etichetelor.
Aplicat ¸ia se conecteaz˘ a la o baz˘ a de date proprie ¸ si la dou˘ a externe (ARCA ¸ si
MOCO).
Produsele Renault Group reprezint a, pentru sectorul automobil, elementul e-
sent ial pentru imaginea de brand. ^In fapt, Renault se confrunt a cu fenomenul de
contrafabricat ie si piraterie. Renault Group folose ste etichetele securizate Renault
ca un semn distinctiv care permite s a certice provenient a produselor. Caracte-
ristica acestei etichete este s a det in a elemente securizate care s a fac a imposi-
bil a realizarea unei falsic ari sau contrafabricat ii. Aceste elemente sunt incluse
la timpul ambal arii si nu au nevoie de introducerea altor intervent ii sau imple-
ment ari particulare. Toate piesele Renault necesit a aplicarea unei etichete securi-
zate. Aceast a etichet a este lipit a ^ n josul pachetului sau pe o parte c^ and produsul
43

44 CAPITOLUL 3. APLICAT IA
nu este ^ mpachetat (except ie dac a exist a un angajament scris din partea Renault
Group).
Motivul cererii aplicat ¸iei este, cu sigurant ¸˘ a, necesitatea aplicat ¸iei. Fiecare
etichet˘ a necesit˘ a o identitate unic˘ a ˆ ın companie ¸ si un user identiﬁcat aferent
etichetei tip˘ arite.
Prin gestionarea etichetelor, se dore¸ ste a se memora traseul acestora de la
intrarea pˆ ana la imprimarea, sau distrugerea lor. Prin aceast˘ a aplicat ¸ie, se va
simpliﬁca ¸ si se va reduce timpul de munc˘ a celor care lucreaza la Centrul de Piese
de Schimb (CPS) de la Oarja, oferindu-le posibilitatea de a realiza electronic ¸ si
automat o mare parte din activit˘ at ¸i.
3.2 Logarea ^ n aplicat ie
Un administrator va crea cˆ ate un proﬁl pentru ﬁecare angajat care va urma s˘ a
foloseasc˘ a aplicat ¸ia, format din IPN (un fel de ID) ¸ si parol˘ a, care vor ﬁ introduse
ˆ ın prima pagin˘ a (Figura (3.1)). Aceste dou˘ a cˆ ampuri sunt obligatorii.
Figura 3.1: Pagina de logare
Dup˘ a completarea acestor dou˘ a cˆ ampuri, utilizatorul se poate loga. Dac˘ a cele
dou˘ a intr˘ ari din cˆ ampuri sunt ˆ ınregistrate ˆ ın baza de date ca ﬁind un utilizator
cu dreptul de a intra ¸ si a folosi aplicat ¸ia, iar IPN-ul ¸ si parola sunt corecte, atunci
se va deschide aplicat ¸ia, putˆ and lucra ˆ ın ea.

3.3. ECRANUL PRINCIPAL 45
3.3 Ecranul principal
Administratorul ofer˘ a acces utilizatorilor doar la anumite pagini. ˆIn partea
din dreapta, sus, se poate vedea numle utilizatorului. Tot de aici, acesta se poate
deloga, sau schimba limba: romˆ an˘ a, francez˘ a, englez˘ a. Meniul principal este
alc˘ atuit din:
Securitate
{Useri
{Roluri
{Tipuri ie¸ siri
{Tipuri imprimante
Gestiune
{Intr˘ ari etichete
{Ie¸ siri etichete imprimate
{Ie¸ siri etichete neimprimate
{Rebut
{Raport stoc etichete
Imprimare
Figura 3.2: Aplicat ¸ia

46 CAPITOLUL 3. APLICAT IA
3.4 Paginile alpicat iei
3.4.1 Securitate { Utilizatori
Se pot vizualiza utilizatorii ˆ ınregistrat ¸i, se pot ad˘ auga noi utilizatori, modiﬁ-
carea st˘ arii (dac˘ a este utilizator activ sau nu), modiﬁcarea drepturilor pe anumite
pagini (doar administratorul are acces la toate paginile aplicat ¸iei). ˆIn partea de
sus exist˘ a un ﬁltru prin intermediul c˘ aruia se poate c˘ auta dup˘ a:
ipn,
nume.
Aferent ﬁltrelor, va exista un buton de C autare ¸ siReset (pentru a reseta ﬁltrul
de c˘ autare). Rezultatul se va aﬁ¸ sa ˆ ıntr-un tabel paginat, cu 10 ˆ ınregistr˘ ari pe
pagin˘ a.
Structur˘ a:
Nume – numele utilizatorului – 25 caractere alfa-numerice; cˆ amp obligato-
riu.
IPN – id-ul utilizatorului – 10 caractere alfa-numerice; cˆ amp obligatoriu.
Email -– e-mailul utilizatorului – 50 caractere alfa-numerice; cˆ amp obliga-
toriu.
Rol — rolul utilizatorului selectat din list˘ a.
Stare -– checkbox – activ / inactiv.
Opt ¸iuni:
Adaug a date – se va deschide o fereastr˘ a ˆ ın care se vor completa cˆ ampurile
descrise ˆ ın structur˘ a. Exist˘ a posibilitatea de a:
{Salva datele noi introduse, prin ap˘ asarea butonului Salvare .
{Renunt ¸area la completarea ˆ ınregistr˘ arii ¸ si ˆ ıntoarcerea ˆ ın fereastra prin-
cipal˘ a.
Modic a o intrare selectat˘ a – se va deschide o fereastr˘ a ˆ ın care vor ap˘ area
completate cˆ ampurile descrise ˆ ın structur˘ a, corespunz˘ atoare intr˘ arii selec-
tate. Exist˘ a posibilitatea de a:
{Salva datele noi introduse, prin ap˘ asarea butonului Salvare .
{Renunt ¸area la completarea ˆ ınregistr˘ arii ¸ si ˆ ıntoarcerea ˆ ın fereastra prin-
cipal˘ a.
S terge o intrare selectat˘ a – se va deschide o fereastr˘ a ˆ ın care vor ap˘ area
completate cˆ ampurile descrise ˆ ın structur˘ a, corespunz˘ atoare intr˘ arii selec-
tate.

3.4. PAGINILE ALPICAT IEI 47
3.4.2 Securitate { Roluri
ˆIn aceasta fereastr˘ a vor putea introduce noi roluri pentru utilizatori. Se poate
vizualiza rolurile ˆ ınregistrate, se pot ad˘ auga, modiﬁca sau ¸ sterge.
Structur˘ a:
Denumire – denumirea rolului – 45 caractere alfa-numerice; cˆ amp obligato-
riu.
Descriere – descrierea rolului – 70 caractere alfa-numerice; cˆ amp opt ¸ional.
Stare -– checkbox – activ / inactiv.
Drepturi -– checkbox – se aleg din list˘ a.
Opt ¸iuni:
Adaug a date – se va deschide o fereastr˘ a ˆ ın care se vor completa cˆ ampurile
descrise ˆ ın structur˘ a. Exist˘ a posibilitatea de a:
{Salva datele noi introduse, prin ap˘ asarea butonului Salvare .
{Renunt ¸area la completarea ˆ ınregistr˘ arii ¸ si ˆ ıntoarcerea ˆ ın fereastra prin-
cipal˘ a.
Modic a o intrare selectat˘ a – se va deschide o fereastr˘ a ˆ ın care vor ap˘ area
completate cˆ ampurile descrise ˆ ın structur˘ a, corespunz˘ atoare intr˘ arii selec-
tate. Exist˘ a posibilitatea de a:
{Salva datele noi introduse, prin ap˘ asarea butonului Salvare .
{Renunt ¸area la completarea ˆ ınregistr˘ arii ¸ si ˆ ıntoarcerea ˆ ın fereastra prin-
cipal˘ a.
S terge o intrare selectat˘ a – se va deschide o fereastr˘ a ˆ ın care vor ap˘ area
completate cˆ ampurile descrise ˆ ın structur˘ a, corespunz˘ atoare intr˘ arii selec-
tate.
3.4.3 Securitate { Tipuri iesire
ˆIn aceasta fereastr˘ a se pot introduce noi tipuri de ie¸ sire pentru etichete. Se
pot vizualiza tipurile ˆ ınregistrate, ad˘ auga ¸ si modiﬁca.
Structur˘ a:
Denumire (RO) – denumirea ˆ ın RO a tipului de ie¸ sire – 45 caractere alfa-
numerice; cˆ amp obligatoriu.
Denumire (EN) – denumirea ˆ ın EN a tipului de ie¸ sire – 45 caractere alfa-
numerice; cˆ amp obligatoriu.

48 CAPITOLUL 3. APLICAT IA
Denumire (FR) – denumirea ˆ ın FR a tipului de ie¸ sire – 45 caractere alfa-
numerice; cˆ amp obligatoriu.
Cˆ ampuri -– checkbox – se aleg din list˘ a.
Opt ¸iuni:
Adaug a date – se va deschide o fereastr˘ a ˆ ın care se vor completa cˆ ampurile
descrise ˆ ın structur˘ a. Exist˘ a posibilitatea de a:
{Salva datele noi introduse, prin ap˘ asarea butonului Salvare .
{Renunt ¸area la completarea ˆ ınregistr˘ arii ¸ si ˆ ıntoarcerea ˆ ın fereastra prin-
cipal˘ a.
Modic a o intrare selectat˘ a – se va deschide o fereastr˘ a ˆ ın care vor ap˘ area
completate cˆ ampurile descrise ˆ ın structur˘ a, corespunz˘ atoare intr˘ arii selec-
tate. Exist˘ a posibilitatea de a:
{Salva datele noi introduse, prin ap˘ asarea butonului Salvare .
{Renunt ¸area la completarea ˆ ınregistr˘ arii ¸ si ˆ ıntoarcerea ˆ ın fereastra prin-
cipal˘ a.
3.4.4 Securitate { Tipuri imprimante
ˆIn aceasta fereastr˘ a se pot introduce noi tipuri de ie¸ sire pentru etichete. Se
pot vizualiza tipurile ˆ ınregistrate, ad˘ auga ¸ si modiﬁca.
Structur˘ a:
Denumire – denumirea imprimantei – 45 caractere alfa-numerice; cˆ amp obli-
gatoriu.
Opt ¸iuni:
Adaug a date – se va deschide o fereastr˘ a ˆ ın care se vor completa cˆ ampurile
descrise ˆ ın structur˘ a. Exist˘ a posibilitatea de a:
{Salva datele noi introduse, prin ap˘ asarea butonului Salvare .
{Renunt ¸area la completarea ˆ ınregistr˘ arii ¸ si ˆ ıntoarcerea ˆ ın fereastra prin-
cipal˘ a.
Modic a o intrare selectat˘ a – se va deschide o fereastr˘ a ˆ ın care vor ap˘ area
completate cˆ ampurile descrise ˆ ın structur˘ a, corespunz˘ atoare intr˘ arii selec-
tate. Exist˘ a posivilitatea de a:
{Salva datele noi introduse, prin ap˘ asarea butonului Salvare .
{Renunt ¸area la completarea ˆ ınregistr˘ arii ¸ si ˆ ıntoarcerea ˆ ın fereastra prin-
cipal˘ a.
Set ari

3.4. PAGINILE ALPICAT IEI 49
Set ari
Dup˘ a ce am introdus o imprimant˘ a, aici se vor putea introduce set˘ arile pentru
aceasta. Structur˘ a:
L˘ at ¸ime etichet˘ a – 4 caractere numerice; cˆ amp obligatoriu.
ˆIn˘ alt ¸ime etichet˘ a – 4 caractere numerice; cˆ amp obligatoriu.
ˆIn˘ alt ¸ime etichet˘ a (cu margine) – 4 caractere numerice; cˆ amp obligatoriu.
Abscis˘ a cod bare – 4 caractere numerice; cˆ amp obligatoriu.
Ordonat˘ a cod bare – 4 caractere numerice; cˆ amp obligatoriu.
Abscis˘ a cod reper – 4 caractere numerice; cˆ amp obligatoriu.
Ordonat˘ a cod reper – 4 caractere numerice; cˆ amp obligatoriu.
Abscis˘ a denumire – 4 caractere numerice; cˆ amp obligatoriu.
Ordonat˘ a denumire – 4 caractere numerice; cˆ amp obligatoriu.
Abscis˘ a unitate de vˆ anzare – 4 caractere numerice; cˆ amp obligatoriu.
Ordonat˘ a unitate de vˆ anzare – 4 caractere numerice; cˆ amp obligatoriu.
Abscis˘ a t ¸ar˘ a de origine – 4 caractere numerice; cˆ amp obligatoriu.
Ordonat˘ a t ¸ar˘ a de origine – 4 caractere numerice; cˆ amp obligatoriu.
Tip ie¸ sire – tipul etichetei – Mare; Mic˘ a.
Opt ¸iuni:
Adaug a date – se va deschide o fereastr˘ a ˆ ın care se vor completa cˆ ampurile
descrise ˆ ın structur˘ a. Exist˘ a posibilitatea de a:
{Salva datele noi introduse, prin ap˘ asarea butonului Salvare .
{Renunt ¸area la completarea ˆ ınregistr˘ arii ¸ si ˆ ıntoarcerea ˆ ın fereastra prin-
cipal˘ a.
Modic a o intrare selectat˘ a – se va deschide o fereastr˘ a ˆ ın care vor ap˘ area
completate cˆ ampurile descrise ˆ ın structur˘ a, corespunz˘ atoare intr˘ arii selec-
tate. Exist˘ a posivilitatea de a:
{Salva datele noi introduse, prin ap˘ asarea butonului Salvare .
{Renunt ¸area la completarea ˆ ınregistr˘ arii ¸ si ˆ ıntoarcerea ˆ ın fereastra prin-
cipal˘ a.

50 CAPITOLUL 3. APLICAT IA
3.4.5 Gestiune { Intr ari etichete
ˆIn aceast˘ a fereastr˘ a se introduc etichetele care intr˘ a ˆ ın stoc. Aici se pot vizual-
izaˆ ınregistr˘ arile, ad˘ auga noiˆ ınregistr˘ ari, modiﬁcarea acestora, precum ¸ si exportul
lor ˆ ın Excel. ˆIn partea de sus exist˘ a un ﬁltru prin intermediul c˘ aruia se poate
c˘ auta dup˘ a:
un anumit document,
un interval,
de la o anumit˘ a dat˘ a,
dup˘ a o anumit˘ a dat˘ a.
Aferent ﬁltrelor, va exista un buton de C autare ¸ siReset (pentru a reseta ﬁltrul
de c˘ autare). Rezultatul se va aﬁ¸ sa ˆ ıntr-un tabel paginat, cu 10 ˆ ınregistr˘ ari pe
pagin˘ a.
Structur˘ a:
IPN – id-ul user-ului conectat – preluat automat; 10 caractere alfa-numerice;
cˆ amp obligatoriu.
Data intrare – data sistemului – cu posibilitate de modiﬁcare; tip dat˘ a;
cˆ amp obligatoriu.
Document -– codul documentului aferent setului de role primit – init ¸ializat
manual; 15 caractere alfa-numerice; cˆ amp opt ¸ional.
Cantitate role -– num˘ arul de role intrate – init ¸ializat manual; 5 caractere
numerice; cˆ amp obligatoriu.
Cantitate etichete/rol˘ a -– num˘ arul de etichete aferent ﬁec˘ arei role – init ¸ializat
manual; 5 caractere numerice; cˆ amp obligatoriu.
Cantitate etichete — calculat automat ca produsul ˆ ıntre Cantitate role ¸ si
Cantitate etichete/rol˘ a; 10 caractere numerice, implicit cˆ amp obligatoriu.
Acest cˆ amp apare doar ˆ ın tabelul de aﬁ¸ sare al ˆ ınregistr˘ arilor.
Tip -– selectat din lista de tipuri etichet˘ a (Mare / Mic˘ a, byDefault Mare)
Total intr˘ ari – apare doar ˆ ın pagina de aﬁ¸ sare a ˆ ınregistr˘ arilor.
Opt ¸iuni:
Adaug a date – se va deschide o fereastr˘ a ˆ ın care se vor completa cˆ ampurile
descrise ˆ ın structur˘ a. Exist˘ a posibilitatea de a:
{Salva datele noi introduse, prin ap˘ asarea butonului Salvare

3.4. PAGINILE ALPICAT IEI 51
{Renunt ¸area la completarea ˆ ınregistr˘ arii ¸ si ˆ ıntoarcerea ˆ ın fereastra prin-
cipal˘ a
Modic a o intrare selectat˘ a – se va deschide o fereastr˘ a ˆ ın care vor ap˘ area
completate cˆ ampurile descrise ˆ ın structur˘ a, corespunz˘ atoare intr˘ arii selec-
tate. Exist˘ a posibilitatea de a:
{Salva datele noi introduse, prin ap˘ asarea butonului Salvare
{Renunt ¸area la completarea ˆ ınregistr˘ arii ¸ si ˆ ıntoarcerea ˆ ın fereastra prin-
cipal˘ a
Export Excel
3.4.6 Gestiune { Ie siri etichete imprimate
ˆIn aceast˘ a fereastr˘ a se introduc etichetele imprimate. Aici se pot vizualiza
ˆ ınregistr˘ arile, ad˘ auga noi ˆ ınregistr˘ ari, modiﬁcarea acestora, precum ¸ si exportul
lor ˆ ın Excel. ˆIn partea de sus exist˘ a un ﬁltru prin intermediul c˘ aruia se poate
c˘ auta dup˘ a:
un anumit document,
un interval,
de la o anumit˘ a dat˘ a,
dup˘ a o anumit˘ a dat˘ a.
dup˘ a un anumit tip de ie¸ sire
dup˘ a tipul etichetei
Aferent ﬁltrelor, va exista un buton de C autare ¸ siReset (pentru a reseta ﬁltrul
de c˘ autare). Rezultatul se va aﬁ¸ sa ˆ ıntr-un tabel paginat, cu 10 ˆ ınregistr˘ ari pe
pagin˘ a.
Structur˘ a:
IPN – id-ul user-ului conectat – preluat automat; 10 caractere alfa-numerice;
cˆ amp obligatoriu.
Data imprimare -– data sistemului – cu posibilitate de modiﬁcare; tip dat˘ a;
cˆ amp obligatoriu.
Referint ¸˘ a – aferent˘ a piesei pentru care utilizatorul va imprima eticheta –
initializat manual; 18 caractere alfa-numerice; cˆ amp obligatoriu.
Serie ˆ ınceput – init ¸ializat manual; 20 caractere alfa-numerice; cˆ amp obliga-
toriu.

52 CAPITOLUL 3. APLICAT IA
Serie sfˆ ar¸ sit – init ¸ializat manual; 20 caractere alfa-numerice; cˆ amp obliga-
toriu.
Cantitate – num˘ arul de etichete imprimate – init ¸ializat manual; 5 caractere
numerice; cˆ amp obligatoriu.
Tip ie¸ sire -– selectat din lista de tipuri ie¸ siri.
ˆIn funct ¸ie de tipul ie¸ sirii se activeaz˘ a urm˘ atoarele:
{Nume primitor – persoana care semneaz˘ a, din cadrul ﬁrmei Renault,
c˘ a a primit etichetele pentru trimiterea c˘ atre destinatar – init ¸ializat
manual; 20 caractere; cˆ amp opt ¸ional.
{Document — codul documentului aferent setului de role primit –
init ¸ializat manual; 15 caractere alfa-numerice; cˆ amp opt ¸ional.
{Destinatar — ﬁrma c˘ atre care se trimite setul de etichete – init ¸ializat
manual; 20 caractere alfa-numerice; cˆ amp opt ¸ional.
{Motiv recondit ¸ionare — descrierea motivului recondit ¸ion˘ arii – init ¸ializat
manual; 20 caractere alfa-numerice; cˆ amp opt ¸ional.
Tip — selectat din lista de tipuri etichet˘ a (Mare / Mic˘ a, byDefault Mare)
Total ie¸ siri – apare doar ˆ ın pagina de aﬁ¸ sare a ˆ ınregistr˘ arilor.
Opt ¸iuni:
Adaug a date – se va deschide o fereastr˘ a ˆ ın care se vor completa cˆ ampurile
descrise ˆ ın structur˘ a. Exist˘ a posibilitatea de a:
{Salva datele noi introduse, prin ap˘ asarea butonului Salvare
{Renunt ¸area la completarea ˆ ınregistr˘ arii ¸ si ˆ ıntoarcerea ˆ ın fereastra prin-
cipal˘ a
Modic a o intrare selectat˘ a – se va deschide o fereastr˘ a ˆ ın care vor ap˘ area
completate cˆ ampurile descrise ˆ ın structur˘ a, corespunz˘ atoare intr˘ arii selec-
tate. Exist˘ a posibilitatea de a:
{Salva datele noi introduse, prin ap˘ asarea butonului Salvare
{Renunt ¸area la completarea ˆ ınregistr˘ arii ¸ si ˆ ıntoarcerea ˆ ın fereastra prin-
cipal˘ a
Export Excel

3.4. PAGINILE ALPICAT IEI 53
3.4.7 Gestiune { Ie siri etichete neimprimate
ˆIn aceast˘ a fereastr˘ a se introduc etichetele care ies din stoc. Aici se pot vizualiza
ˆ ınregistr˘ arile, ad˘ auga noi ˆ ınregistr˘ ari, modiﬁcarea acestora, precum ¸ si exportul
lor ˆ ın Excel. ˆIn partea de sus exist˘ a un ﬁltru prin intermediul c˘ aruia se poate
c˘ auta dup˘ a:
un anumit document,
un interval,
de la o anumit˘ a dat˘ a,
dup˘ a o anumit˘ a dat˘ a.
Aferent ﬁltrelor, va exista un buton de C autare ¸ siReset (pentru a reseta ﬁltrul
de c˘ autare). Rezultatul se va aﬁ¸ sa ˆ ıntr-un tabel paginat, cu 10 ˆ ınregistr˘ ari pe
pagin˘ a.
Structur˘ a:
IPN – id-ul user-ului conectat – preluat automat; 10 caractere alfa-numerice;
cˆ amp obligatoriu.
Data ie¸ sire — data sistemului – cu posibilitate de modiﬁcare; tip dat˘ a; cˆ amp
obligatoriu.
Document -– codul documentului aferent setului de role primit – init ¸ializat
manual; 15 caractere alfa-numerice; cˆ ampul nu este obligatoriu.
Destinatar — ﬁrma c˘ atre care se trimite setul de etichete – init ¸ializat man-
ual; 20 caractere alfa-numerice; cˆ ampul obligatoriu.
Serie ˆ ınceput – init ¸ializat manual; 20 caractere alfa-numerice; cˆ amp obliga-
toriu.
Serie sfˆ ar¸ sit – init ¸ializat manual; 20 caractere alfa-numerice; cˆ amp obliga-
toriu.
Cantitate – num˘ arul de role – init ¸ializat manual; 5 caractere numerice; cˆ amp
obligatoriu.
Nume primitor – persoana care semneaz˘ a, din cadrul ﬁrmei Renault, c˘ a a
primit etichetele pentru trimiterea c˘ atre destinatar; init ¸ializat manual; 20
caractere; cˆ amp opt ¸ional.
Tip — selectat din lista de tipuri etichet˘ a (Mare / Mic˘ a, byDefault Mare)
Total ie¸ siri – apare doar ˆ ın pagina de aﬁ¸ sare a ˆ ınregistr˘ arilor.

54 CAPITOLUL 3. APLICAT IA
Opt ¸iuni:
Adaug a date – se va deschide o fereastr˘ a ˆ ın care se vor completa cˆ ampurile
descrise ˆ ın structur˘ a. Exist˘ a posibilitatea de a:
{Salva datele noi introduse, prin ap˘ asarea butonului Salvare
{Renunt ¸area la completarea ˆ ınregistr˘ arii ¸ si ˆ ıntoarcerea ˆ ın fereastra prin-
cipal˘ a
Modic a a unei intrari selectate – se va deschide o fereastr˘ a ˆ ın care vor
ap˘ area completate cˆ ampurile descrise ˆ ın structur˘ a, corespunz˘ atoare intr˘ arii
selectate. Exist˘ a posibilitatea de a:
{Salva datele noi introduse, prin ap˘ asarea butonului Salvare
{Renunt ¸area la completarea ˆ ınregistr˘ arii ¸ si ˆ ıntoarcerea ˆ ın fereastra prin-
cipal˘ a
Export Excel
3.4.8 Gestiune { Rebut
ˆIn aceast˘ a fereastr˘ a se introduc etichetele care sunt rebuturi. Aici se pot
vizualiza ˆ ınregistr˘ arile, ad˘ auga noi ˆ ınregistr˘ ari, modiﬁcarea acestora, precum ¸ si
exportul lor ˆ ın Excel. ˆIn partea de sus exist˘ a un ﬁltru prin intermediul c˘ aruia se
va putea c˘ auta dup˘ a:
un anumit document,
un interval,
de la o anumit˘ a dat˘ a,
dup˘ a o anumit˘ a dat˘ a.
Aferent ﬁltrelor, va exista un buton de C autare ¸ siReset (pentru a reseta ﬁltrul
de c˘ autare). Rezultatul se va aﬁ¸ sa ˆ ıntr-un tabel paginat, cu 10 ˆ ınregistr˘ ari pe
pagin˘ a.
Structur˘ a:
IPN – id-ul user-ului conectat – preluat automat; 10 caractere alfa-numerice;
cˆ amp obligatoriu.
Data ie¸ sire — data sistemului – cu posibilitate de modiﬁcare; tip dat˘ a; cˆ amp
obligatoriu.
Serie ˆ ınceput – init ¸ializat manual; 20 caractere alfa-numerice; cˆ amp obliga-
toriu.

3.4. PAGINILE ALPICAT IEI 55
Serie sfˆ ar¸ sit – init ¸ializat manual; 20 caractere alfa-numerice; cˆ amp obliga-
toriu.
Cantitate – num˘ arul de role – init ¸ializat manual; 5 caractere numerice; cˆ amp
obligatoriu.
Tip -– selectat din lista de tipuri etichet˘ a (Mare / Mic˘ a, byDefault Mare)
Total rebuturi – apare doar ˆ ın pagina de aﬁ¸ sare a ˆ ınregistr˘ arilor.
Opt ¸iuni:
Adaug a date – se va deschide o fereastr˘ a ˆ ın care se vor completa cˆ ampurile
descrise ˆ ın structur˘ a. Exist˘ a posibilitatea de a:
{Salva datele noi introduse, prin ap˘ asarea butonului Salvare
{Renunt ¸area la completarea ˆ ınregistr˘ arii ¸ si ˆ ıntoarcerea ˆ ın fereastra prin-
cipal˘ a
Modic a o intrare selectat˘ a – se va deschide o fereastr˘ a ˆ ın care vor ap˘ area
completate cˆ ampurile descrise ˆ ın structur˘ a, corespunz˘ atoare intr˘ arii selec-
tate. Exist˘ a posibilitatea de a:
{Salva datele noi introduse, prin ap˘ asarea butonului Salvare
{Renunt ¸area la completarea ˆ ınregistr˘ arii ¸ si ˆ ıntoarcerea ˆ ın fereastra prin-
cipal˘ a
Export Excel
3.4.9 Gestiune { Stoc
Din aceast˘ a fereastr˘ a se aﬂ˘ a stocul etichetelor. Aici se poate vizualiza totalul
ˆ ınregistr˘ arilor pentru ﬁecare tip precum ¸ si exportul raportului ˆ ın Excel. ˆIn partea
de sus exist˘ a un ﬁltru prin intermediul c˘ aruia se poate c˘ auta dup˘ a:
tipul etichetei,
un interval,
de la o anumit˘ a dat˘ a,
dup˘ a o anumit˘ a dat˘ a.
Aferent ﬁltrelor, va exista un buton de C autare ¸ siReset (pentru a reseta ﬁltrul
de c˘ autare). Rezultatul se va aﬁ¸ sa ˆ ıntr-un tabel.
Structur˘ a:
Stoc reportat

56 CAPITOLUL 3. APLICAT IA
Intr˘ ari etichete
Ie¸ siri etichete neimprimate
Ie¸ siri etichete imprimate – se va aﬁ¸ sa un tabel ˆ ın care vor ﬁ ˆ ınregistr˘ arile
prntu ﬁecare tip de ie¸ sire
Rebuturi
Stoc etichete – se calculeaz˘ a: Stoc reportat + Intr˘ ari etihete – Ie¸ siri etichete
imprimate – Iet ¸iri etichete neimprimate.
Opt ¸iuni:
Export Excel

3.4. PAGINILE ALPICAT IEI 57
3.4.10 Imprimare
Este activitatea prin intermediul c˘ areia se realizeaz˘ a imprimarea etichetelor.
Activitatea se va deschide in momentul accesarii butonului Imprimare ce se
reg˘ ase¸ ste ˆ ın meniul aplicat ¸iei web. Este reprezentat˘ a din:
Referint ¸a piesei, pozit ¸ionat˘ a pe orizontal˘ a prin trei cˆ ampuri.
{primul grup – 4 cifre; cˆ amp obligatoriu;
{al doilea grup – 3 cifre; cˆ amp obligatoriu;
{al treilea grup – 3 cifre; cˆ amp obligatoriu;
Cantitate: 3 caractere numerice; cˆ amp obligatoriu;
Tip eticheta: Mare, Mic˘ a;
Buton Anulare: moment ˆ ın care toate cˆ ampurile se reinit ¸ializeaz˘ a automat;
Buton Conﬁrmare: moment ˆ ın care aplicat ¸ia prezint˘ a dou˘ a situat ¸ii:
{referint ¸a c˘ autat˘ a ˆ ın baza de date MOCO nu este introdus˘ a corect ¸ si
atunci va ap˘ area un mesaj de eroare ˆ ın care se va semnala c˘ a referint ¸a
nu exist˘ a;
{refeint ¸a c˘ autat˘ a exist˘ a ˆ ın baza de date MoCo, astfel se va deschide
o nou˘ a activitate ˆ ın care putem previzualiza eticheta ¸ si anume Pre-
vizualizare.
Previzualizare
Este activitatea prin intermediul c˘ areia se realizeaz˘ a previzualizarea etichetei
ˆ ınainte de a se realiza imprimarea. Activitatea va putea ﬁ vizualizat˘ a prin inter-
mediul unui pop-up. Se vor evident ¸ia utm˘ atoarele:
Cod de bare referint ¸˘ a – reprezentare graﬁc˘ a cod de bare al referint ¸ei.
Referint ¸a – cod alfa-numeric de 10 caractere, ce contine referint ¸a introdus˘ a
f˘ ar˘ a nici o separare a caracterelor, de exemplu 829CJ45B7R.
descriere referint ¸˘ a ˆ ın funct ¸ie de limba aleas˘ a de aﬁ¸ sare a aplicat ¸iei – 30 de
caractere.
unitatea de vˆ anzare referint ¸˘ a (Preluat din MoCo pe baza codului reper) —
tipul: Xnumeric; 5 caractere.
t ¸ara de origine referint ¸˘ a (Preluat din MoCo pe baza codului reper) — Made
In . . . ; 20 de caractere.

58 CAPITOLUL 3. APLICAT IA
Buton de Anulare: moment ˆ ın care se ˆ ıntoarce ˆ ın ecranul anterior, ”Impri-
mare” ¸ si toate cˆ ampurile se reinit ¸ializeaz˘ a automat.
Buton de Conﬁrmare: se execut˘ a imprimarea.
Dup˘ a ce s-a executat imprimarea, se va deschide o pagin˘ a unde se vor insera
urm˘ atoarele date:
Tip ie¸ sire – format dintr-o list˘ a ce va cont ¸ine init ¸ial:
{OT SAPR,
{Reconditionare,
{Transfer;
ulterior ˆ ın aceast˘ a list˘ a pot ap˘ area ¸ si alte tipuri de ie¸ siri ˆ ın funct ¸ie de ce
creaz˘ a administratorul sau user-ul ˆ ın partea de tipuri ie¸ siri ale aplicat ¸iei –
15 caractere; cˆ amp obligatoriu.
IPN — preluat din ARCA – aferent user-ului conectat – init ¸ializat automat;
10 de caractere alfa-numerice; cˆ amp obligatoriu.
Data — data sistemului – init ¸ializat automat; 10 caractere; cˆ amp obligato-
riu.
Raferint ¸a -– aferent˘ a piesei pentru care utilizatorul va imprima eticheta –
init ¸ializat automat; 18 caractere alfa-numerice; cˆ amp obligatoriu.
Cantitate -– cantitatea de etichete pe care utilizatorul a imprimat-o – ini-
t ¸ializat˘ a automat dar cu posibilitate de modiﬁcare, ˆ ın cazul ˆ ın care num˘ arul
de etichete imprimate nu a fost cel stabilit init ¸ial; 5 caractere; numerice;
cˆ amp obligatoriu.
Seria de ˆ ınceput — init ¸ializat˘ a manual — 15 caractere alfa-numerice; cˆ amp
obligatoriu.
Seria de sfˆ ar¸ sit – init ¸ializat˘ a manual — 15 caractere alfa-numerice; cˆ amp
obligatoriu.
Nume Primitor – persoana din cadrul ﬁrmei Renault, care semneaz˘ a c˘ a a
primit etichetele ˆ ıntr-o eventual˘ a trimitere c˘ atre destinatar — init ¸ializat
manual; 20 de caractere; cˆ ampul este opt ¸ional.
Document -– codul documentului aferent setului de etichete pe care ˆ ıl va
prelua primitorul – init ¸ializat manual -– 15 caractere alfa-numerice; cˆ ampul
este opt ¸ional.

3.4. PAGINILE ALPICAT IEI 59
Motiv recondit ¸ionare -– descrierea motivului recondit ¸ion˘ arii – init ¸ializat
manual ˆ ın momentul ˆ ın care tipul ie¸ sirii este Reconditionare, altfel nu se va
putea accesa; 20 de caractere; alfa-numerice; cˆ ampul este opt ¸ional.
Destinatar -– ﬁrma c˘ atre care se trimite setul de etichete – init ¸ializat manual
ˆ ın momentul ˆ ın care tipul ie¸ sirii este Transfer, altfel nu se va putea accesa;
20 de caractere; cˆ ampul este opt ¸ional.
Eticheta mare imprimat˘ a este aceasta:

60 CAPITOLUL 3. APLICAT IA
(a) Pentru previzualizare
(b) Pentru imprimare
Figura 3.3: Eticheta mare
(a) Pentru previzualizare
(b) Pentru imprimare
Figura 3.4: Eticheta mic˘ a

Anexe
Figura 3.5: Baza de date a aplicat ¸iei
61

62
Figura 3.6: Aplicat ¸ia

63
Figura 3.7: Diagrama intr˘ ari etichete
Figura 3.8: Diagrama ie¸ siri etichete imprimate

64
Figura 3.9: Diagrama ie¸ siri etichete neimprimate
Figura 3.10: Diagrama etichete rebut

Bibliograe
[1]Channu Kambalyal, 3-Tier Architecture ,
http://channukambalyal.tripod.com/NTierArchitecture.pdf
[2]Ted Husted, Cedric Dumoulin, George Franciscus, David Winterfeldt, Struts
in Action – Building web applications with the leading Java framework , Ed.
Manning Publications, 2003.
[3]Jiang Lin Quan, Dai Xuan, Wang Lei,Juliano Marcos Martins, Chi Run Hua,
Xia Ming, Tang Ying, Raul F. Chong, GETTING STARTED WITH Web-
Sphere ApplicationServerCommunity Edition , Ed. IBM Corporation, 2010.
65

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: Aplicat ie pentru tip arirea etichetelor de origine [614177] (ID: 614177)

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.

Licență

Actualitatea temei:

Introducere Actualitatea temei: Infertilitatea constituie o problemă medico-socială de importanță majoră pentru toate țările lumii, inclusiv pentru Republica Moldova. Conform datelor OMS 10-15% din cupluri suferă de infertilitate. Studii recente arată o creștere considerabilă a ratei infertilității în ultimii ani. Se consideră că actualmente mai mult de 25% din cupluri suferă de infertilitate. Principalii factori…

Read More Actualitatea temei:
Licență

2.1. Particularități ale abordării prin comparații de piață Abordarea prin piață mai este cunoscută în domeniul evaluării patrimoniului imobiliar și… [609140]

2.1. Particularități ale abordării prin comparații de piață Abordarea prin piață mai este cunoscută în domeniul evaluării patrimoniului imobiliar și sub numele de comparație directă sau comparația vânzărilor. Această abordare reprezintă procesul prin care se obțin indicații despre valoarea proprietății imobiliare s ubiect. Aceste indicații se obțin prin compararea proprietății imobiliare subiect cu proprietăți similare…

Read More 2.1. Particularități ale abordării prin comparații de piață Abordarea prin piață mai este cunoscută în domeniul evaluării patrimoniului imobiliar și… [609140]
Licență

Guida Turistica della Campania [305823]

[anonimizat] e Angelo Cavallari Editore CDS Introduzione Un ringraziamento a tutti coloro che hanno aiutato la stesura del testo in particolare all’Avvocato Ludovica Cofrancesco. Storia d’Italia e della Campania Capitolo I Le origini del nome Campania indicano l’area di pertinenza della città di Capua e vanno ricercate nella conformazione piana del territorio. [anonimizat], ovvero pianura…

Read More Guida Turistica della Campania [305823]
Licență

Medicina de dezastru sau Managementul medical al [617265]

Medicina de dezastru sau Managementul medical al dezastrului, o noua specialitate medicala Postat la data de 16 decembrie 2010 in categoria Ideile mele MEDICINA DE DEZASTRU sau MANAGEMENTUL MEDICAL AL DEZASTRULUI, O NOUĂ SPECIALITATE MEDICALĂ Autori Prof. dr. Dan Mănăstireanu Disciplina – Medicină de Dezastru Specializare complementară – Master în Medicina de dezastru Facultatea de…

Read More Medicina de dezastru sau Managementul medical al [617265]
Licență

Direcția ID N IFR CREDIS [613067]

Universitatea din București Facultatea de Psihologie și Științele Educației Direcția ID N IFR CREDIS Pedagogia Învățământului Primar și Preșcolar PORTOFOLIU EVALUARE DIDACTICA DOMENIULUI ARTE EDUCAȚIE PLASTICÃ Profesor, lector univ.dr. Voicu Gabriela Studentã, Petroiu (Gheorghe) Diana Nicoleta București, 2018 CUPRINS 1. Amintiri din școala primarã – Eseu 2. Clasa mea și copilul meu – Eseu 3….

Read More Direcția ID N IFR CREDIS [613067]
Licență

Liulcenco Alexandra , SPM [629819]

Elaborat de: Liulcenco Alexandra , SPM Temă de casă Etică și Integritate Academică Esența unui plan de afaceri Definire, funcții și avantaje Galați 2018 2 Conceptul de plan de afaceri Profitabilitatea unei afaceri, indifer ent de mărimea acesteia , constituie scopul major al oricărui proprietar, dar – în același timp – și proba finală de…

Read More Liulcenco Alexandra , SPM [629819]