Academia de Studii Economice din București [600504]

Academia de Studii Economice din București
Facultatea de Cibernetică, Statistică și Informatică
Economică

LUCRARE DE LICENȚĂ

SISTEM TRANSPARENT DE URM ĂRIRE A
PROCESELOR DE SERVICE AUTO

Coordonator științific :
Lect. univ. dr. Andrei TOMA
Absolvent: [anonimizat]
2015

Cuprins

Introducere ………………………….. ………………………….. ………………………….. ………………………….. …………………………. 3
1. Situația actuală a platformelor de tip Service CRM din România ………………………….. ………………………….. ….4
2. Prezentarea principalelor tehnologii folosite în aplicația Service CRM ………………………….. ……………………… 5
2.1 Paradigma MV C ………………………….. ………………………….. ………………………….. ………………………….. ………….. 5
2.2 JavaServer Faces ………………………….. ………………………….. ………………………….. ………………………….. …………. 7
2.3 SpringSecurity ………………………….. ………………………….. ………………………….. ………………………….. ………….. 11
2.4 Modelu l de date ………………………….. ………………………….. ………………………….. ………………………….. ………. 15
2.5 JPA ………………………….. ………………………….. ………………………….. ………………………….. …………………………. 16
2.6 Mecanismul de efectuare al tranzacțiilor ………………………….. ………………………….. ………………………….. …. 18
2.7 Tomcat ………………………….. ………………………….. ………………………….. ………………………….. ……………………. 19
3. Prezentarea aplicației Service CRM ………………………….. ………………………….. ………………………….. …………… 20
4. Direcții viitoare de dezvoltare ………………………….. ………………………….. ………………………….. ………………….. 28
Concluzii ………………………….. ………………………….. ………………………….. ………………………….. ………………………….. . 29
Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. ……………………….. 30
Anexe ………………………….. ………………………….. ………………………….. ………………………….. ………………………….. ….. 31

3
Introducere

Sistemul transparent de urm ărire al proceselor de service auto reprezint ă un mijlo c de
monitorizare al stadiului în care se află un autovehicul aflat î n reparaț ii la un moment dat.
În perioada contemporană timpul este din ce în ce mai limitat , iar acest luc ru conduce că tre
nevoia de acces rapid la informaț ie.
Procesul actual de interacțiune al clienț ilor cu furnizorii de servicii din sfera auto este anev oios.
În prezent se utilizează, î n principal , apelul telefonic ori întâ lnirile directe la sediul service -ului auto
pentru a obține informaț ii cu privire la stadiul unei lucră ri.
Numărul automobilelor și al șoferilor este în continuă expansiune, p robabilita tea producerii
tamponă rilor ori accidentelor este ridicată, în special î n ora șele mari , unde aglomerația ș i agitația
șoferilor sunt principalii factori î n producerea de evenimente rutiere. Acest lucr u conduce indubitabil la
un număr foarte mare de interven ții.
De asem enea, pentru companiile care dețin flote de mașini, conceptul prezentat în lucrarea de
față reprez intă un instrument foarte util deoarece permite o urmărire simultană a unui număr mai mare
de mașini aflate î n service.
Această aplicaț ie este un instrumen t flexibil de informare a clienților și angajaților companiilor
ce oferă acest tip de servicii.
Este un sistem facil ce permite monitorizarea ș i, în acelaș i timp , fluidizarea unui proces care î n
acest moment este gre u accesibil, și anume accesul la informații despre starea curentă a unui automobil.
Reducerea costurilor este urmarită de toate compan iile si clienții acestora. Prin soluția descrisă
în continuare se va urmari și acest fapt. De asemenea, timpul pierd ut pentru furnizarea de informaț ii
prin mijloace clasice va fi eficientizat.
În ceea ce privește clientul, acesta simte în permanență nevoia de a ști că autom obilul său este
în siguranță. Această aplicație va satisface și nevoia menționată anterior, clientul putând avea acces la
informații o ricând doreș te prin si mpla accesare a browser -ului de I nternet.
Accesul angajaț ilor companiei din structuril e de conducere nu va fi limitat. A stfel, managerii
departamentelor ș i administratorul site -ului vor avea acces la toate datele stocate.
Toate aces te idei conduc la necesitatea găsirii unei soluț ii, iar aceasta este conceptul d e sistem
de urmă rire al proceselor de service auto.

4
1. Situația actuală a platformelor de tip Service CRM din România

În prezent, în Româ nia nu este implementat un sistem de urmă rire la niciuna din companiile ce
oferă servicii de reparaț ii a automobilelor.
Acest concept de aplicație este, dincolo de utilitatea ș i flexibil itatea oferită, o idee inovatoare ce
vine să aducă un element de noutate într -un domeniu care cel puțin până în momentul de față
funcționează dupa cutume învechite.
Producătorii mari de automobile caută să ofere clienților servicii cât mai complete ș i de calitate
din punct de vedere tehnic după vâ nzarea automobilului.
O mare parte din profitul aces tora vi ne din serviciile post -vânzare , însă de multe ori se î ntâmplă
ca imaginea serviciul oferit, deși calitativ, să sufere din cauza unei comunică ri defectuase între
furnizorul de servicii ș i client.
Această soluție vine să îmbunătățească nivelul de satisfacție al clienților prin elementul de
noutate ș i inovatie.
În compania unde va funcț iona, sistemul va oferi istoricul reparaț iilor și toate informaț iile
aferente.
În prezent acest istoric poate fi accesat la consilierul de vânzări sau î n cartea de service pe care
orice posesor de mașină o deț ine.
Acest sistem este î nvechit și anevoios, proprietarul fiind nevoit să acceseze informația î n format
fizic ori să se deplaseze la sediul unde a efectuat reparaț ia.
Dacă reparația a avut loc în diferite perioade de timp, informaț ia se poate pierde. De asemenea ,
suportul fizic poate suferi distrugeri , iar odată cu acestea se pot pierde informații care î ntr-un anumit
punct pot fi extrem de necesare.
Toate a ceste elemente de noutate vin să ofere clienților și companii lor producă toare de
automobile ori furnizoare de servicii de repara ții a automobilelor o unealtă perfectă î n simplificarea
unui proces care , deși este funcț ional , începe să devină anevoios odată cu expansiunea unui domeniu
vast, cum este cel al automobilel or.

5
2. Prezentarea principalelor tehnologii folosite în aplicația Service CRM

2.1 Paradigma MVC

Dezvoltarea aplicațiilor web ocupă în momentul de față un segment extrem de important al
domeniului programării în general.
Numarul extrem de mare de aplicații a rezultat în necesitatea standardizării. Pe cale de
consecință, au apărut design pattern -urile și arhitecturile web. Una dintre cele mai populare modalități
de structurare a aplicațiilor web (și nu numai) este reprezent at de paradigma MVC – Model View
Controller.
MVC se referă la ”secționarea” diferitelor aspecte ale unei aplicații și atribuirea acestora
diferitelor layer -e, (Model, View respectiv Controller). Această ”atribuire” se realizează prin
identificarea diferit elor arii ale unei aplicații și dezvoltarea componentelor corespunzătoare.
Așadar, elementele MVC:
 Model – reprezintă acel segment al aplicațiilor unde sunt structurate componentele ce au
legătură cu datele (cu segmentul persistenței). Spre exemplu, într -o aplicație dezvoltată în Java,
în ”segmentul” model rezidă clase ce comunică cu baza de date (spre exemplu clase DAO –
Data Access Object, clase al căror scop constă în obținerea datelor de la mecanismul de
persistență – indiferent care ar fi acesta (bază de date, fisiere CSV, fisiere XML ș.a.m.d.) – și
persistarea acestora), clase ORM (Object Relational Mapping, cum este și cazul proiectului de
față, acesta utilizând pe scara largă suportul ORM oferit de JPA – Java Persistency API).
Totodată, în acest laye r se pot găsi clase service, ce permit controller -ului (i.e. nivelului
superior) comunicarea cu modelul printr -un layer de abstractizare (nu este necesar coupling -ul
controller -ului de model).
 Controller – ”layer” -ul numit ”Controller” agreghează și ”comun ică” cu elementele din Model.
În segmentul controller -ului se află business logic -ul aplicației. Acesta poate lua ”decizii”
referitoare la ce componente urmează a fi apelate, ce view urmează a fi returnat utilizatorului,
De asemenea, acesta ”trimite” infor mații la nivelul superior (i.e. la View).
 View – acest din urmă layer este componenta cea mai ”evidentă” din punctul de vedere al
utilizatorului. View -ul agreghează informațiile primite de la Controller și le ”trimite”
utilizatorului.

6
Pattern -ul arhitectural MVC poate fi îmbinat cu o serie de design pattern -uri în vederea asigurării
implementării codului într -o manieră eficientă și corectă. Spre exemplu, componente DAO se pot
ocupa de ”comunicarea” cu baza de date, pentru a oferi un layer de abstr actizare și a izola Controller -ul
de Model.

Figura 2.1.1

Diagrama UML de secvență prezentată mai sus prezintă un caz de utilizare a pattern -ului DAO
mai sus menționat. Codul client interacționează cu un obiect DAO. Acesta, la rândul său, comunică cu
alte componente. Datoria sa este de a face legătura la o sursă de date (i.e. un obiect de tip DataSource
după cum se poate observa din figura de mai sus) și de a returna datele sub o formă sau alta (spre
exemplu, folosind un data transfer object, comunicând c u un ResultSet). Comunicarea cu un obiect de
tip ResultSet este specifică aplicațiilor Java ce utilizează JDBC pentru a realiza legătura și suportul

7
pentru persistență cu un SGBDR (Sistem de Gestiune al Bazelor de Date Relațional). În cazul aplicației
curente, suportul de persistență este realizat prin intermediul JPA. Așadar, clasele DAO comunică cu o
instanță de tip EntityManager.
Odată ce instanța DAO este creată, codul client poate obține informații de la aceasta.
Această separare este necesară în ve derea micșorării coupling -ului între componente. Noțiunea
de coupling se referă la legăturile dintre componente și la măsura în care modificarea unei componente
atrage după sine modificarea componentelor ”dependente”. În vederea maximizării calității codul ui,
coupling -ul trebuie să fie cât mai mic. Două componente între care legăturile sunt păstrate la un minim
se numesc ”loosly coupled”.
Alături de loose coupling, în contextul dezvoltării software, o trăsătură importantă pe care
trebuie să o prezinte oric e aplicație este high cohesion -ul. Noțiunea de high cohesion se referă la
măsura în care elementele unei componente sunt consistente cu aceasta. Spre exemplu, într -un context
OOP, o clasa numită AuthenticationService ar prezenta toate motivele pentru a con ține o metodă
numită login(..), însă nu ar avea prea mult sens adăugarea unei metode ce returnează maximul unui
vector în această clasă. Pe scurt, cohesion -ul se referă la măsura în care elementele unei clase își au
rostul în acea clasă.
Model View Controller reprezintă un pattern arhitectural. Respectarea principiilor impuse de
acesta rezultă în mărirea șanselor dezvoltării unei aplicații în care coupling -ul să tindă către o valoare
minimă iar high cohesion -ul să aibă o valoare mai mare.

2.2 JavaServer Faces

JavaServer Faces reprezintă tehnologia de facto în dezvoltarea segmentelor controller / view ale
aplicațiilor web în Java.
Odată cu apariția celei de a doua versiuni a framework -ului JSF, facelet -urile au devenit soluția
de templating preferată. În continuare, este posibilă utilizarea modalităților mai îmbătrânite de
proiectare a view -ului (e.g. utilizarea paginilor JSP tradiț ionale). Cu toate acestea, backwards
compatibility -ul nu reprezintă un punct central al framework -ului JSF. Spre exemplu, multe
implementări ale JSF (cum ar fi cazul PrimeFaces, utilizat în cadrul proiectului de față) nu mai sprijină
dezvoltarea bazată pe pagini JSP tradiționale (utilizarea PrimeFaces implica necesitatea utilizării
facelet -urilor).
În esență, facelet -urile reprezintă fișiere XML cu extensia .xhtml. Sa considerăm următorul
exemplu:

8
<?xml version="1.0" encoding ="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:ui ="http://java.sun.com/jsf/facelets"
xmlns:p="http://primefaces.org/ui"
xmlns:sec ="http://www.springframework.org/security/tags"
xmlns:c="http://java.sun.com/jstl/core" >

<h:head>
</h:head>

<h:body>

<f:view>

<h:form rendered ="true">
…
</h:form>

</f:view>
</h:body>
</html>

Segmentul de cod de mai sus prezintă un code snippet dintr -un facelet al proiectului actual. Se
poate vedea sintaxa specifică fișierelor XML (definirea namespace -urilor, utilizarea prefixelelor,
deschiderea și înciderea elementelor ș.a.m.d.). De asemenea, se poate observa prefixarea elementelor
HTML head si body. Acest lucru este necesar în vederea utilizării corecte a mecanismului de
templating bazat pe facelets.

Să considerăm un exemplu de pagină JSP cu suport pentru JavaServer Faces:

<%@ page language ="java" contentType ="text/html; charset=ISO -8859-1"
pageEncoding ="ISO-8859-1"%>
<%@ taglib prefix="f" uri="http://java.sun.com/jsf/core" %>
<%@ taglib prefix="h" uri="http://java.sun.com/jsf/html" %>
<html>
<head>
<link href="<%=request.getContextPath() %>/css/default.css"
rel="stylesheet" type="text/css" >

<link
href="<%=request.getContextPath() %>/css/ui-lightness/jquery -ui-1.10.4.custom.css"
rel="stylesheet" type="text/css" >

<script src="<%=request.getContextPath() %>/js/jquery -1.10.2.js" ></script>
<script

9
src="<%=request.getContextPath() %>/js/jquery -ui-1.10.4.custom.js" ></script>

<title>ServiceCRM </title>
</head>
<body>

<script type="text/javascript" >
$(document).ready( function () {$(
"#j_id_jsp_1866133695_2 \\:data_Estimare_Finalizare_Operatie" )
.datepicker({
dateFormat : 'dd/mm/yy'
});
});
</script>
<f:view>

<h:form rendered ="true">
…
</h:form>

</f:view>
</body>
</html>

Se poate observa natura mult mai permisivă a JSP -urilor ”tradiționale” în comparație cu facelet –
urile. Segmentul de cod prezentat conține directive (e.g. folosirea directivei JSP
<%= request.getContextPath() %>/ în vederea obținerii path -ului la care este de ploy-ata aplicația web).
Utilizarea scriptlet -urilor de acest tip nu este posibilă în mult mai standardizatele facelet -uri. De
asemenea, se poate observa utilizarea relaxată a semnelor mai mic respectiv mai mare, elemente care
într-un document XML tradițio nal ar trebui escapate și includerea codului JavaScript fără prea multe
probleme.
În cazul de față, funcționalitatea obținută prin utilizarea librăriei jQuery (dupa cum se poate
observa din codul de mai sus) poate fi înlocuită cu ajutorul PrimeFaces, care pun la dispoziție o gamă
largă de componente UI.
Cu toate acestea, utilizarea fac elet-urilor nu este extrem de restrictivă. Spre exemplu, versiunea
a doua a JSF pune la dispoziție o modalitatea de integrare cu JSTL.
Facelet -urile și JSP -urile reprezintă componenta JSF referitoare la view. Alături de un view,
JSF pune la dispoziția pro gramatorului un mijloc de a interacționa cu diferite backing bean -uri.
Metodele acestora pot fi apelate și diferitele lor atribute pot fi făcute disponibile view -ului. De
asemenea, este posibilă specificarea unui anumit scope pe care un bean îl poate avea. Spre exemplu:
RequestScope (un bean de acest tip este construit de fiecare dată când o nouă cerere este făcută – cand
sosește un request de la client), ViewScope (un bean ce are acest scope este instanțiat pentru a lucra cu

10
un anumit view – cu un anumit f acelet și eligibil pentru garbage collection de fiecare d ată când alt view
este randat), SessionScope (bean -urile cu acest scope sunt instanțiate pe întreaga sesiune – fiecărui
utilizator îi este asociată o sesiune. Odată cu distrugerea acesteia, bean -ul respectiv devine eligibil
pentru procesul de garbage collection).
JSF pune la dispoziție programatorului o altă funcționalitate extrem de utilă – posibilitatea
injectării unui bean în alt bean. Există o limitare: bean -urile trebuie să fie compatibile ca sco pe. Nu este
posibilă, spre exemplu, injectarea unui bean cu scope Request într -un bean cu scope Session.
În cadrul aplicației, în momentul în care o nouă operație este adăugată unui anumit contract în
interiorul clasei OperatieDetailsController, este neces ară apelarea unei metode din alt controller (i.e.
UserController) în vederea împrospătării atributelor pentru randarea ce are să urmeze. În vederea
realizării acestui obiectiv, instanța bean -ului corespunzător controller -ului ”userController” este
injectat ă prin Dependecy Injection în bean -ul controller actual (”operatieDetailsController”):
@ManagedBean (name = "operatieDetailsController" )
@SessionScoped
public class OperatieDetailsController {

// avem nevoie de acces la userController pentru a refresh -ui datele acestuia
@ManagedProperty (value="#{userController}" )
UserController userController ;

Segmentul de cod de mai sus infățișează definirea unui bean (a se observa adnotările atașate
clasei, adnotări specifice JSF 2) cu numele ”operatieDetailsController” și injectarea în acesta a unei
instanțe de tip UserController (este vorba de bean -ul ”userController”). A se remarca faptul că POJO -ul
este a dnotat cu @SessionScoped.
Definiția UserController:

@ManagedBean (name = "userController" )
@SessionScoped
public class UserController {
…
Se poate observa numele acestui bean. De remarcat este faptul că primul bean
(”operatieDetailsController”) se referă la instanța acestui bean prin numele său (”userController”). De
asemenea, amândouă bean -urile prezintă un scope pe durata întregii sesiuni, fiind astfel compatibile și
făcând posibilă injectarea unei instanțe în cealaltă.
În cadrul clasei OperatieDetailsController este posibilă astfel apelarea metodelor obiectului
userController. De asemenea, datorită faptului că dependency injection -ul a fos t utilizat, nu este
necesară nicăieri instanțierea acestui obiect. Container -ul se ocupă de acest task.

11
Facelet -urile pot utiliza Expression Language pentru a mapa diferite proprietăți ale view -ului la
componentele corespunzătoare din bean -ul asociat.
<h:form rendered ="true">
…
<h:inputText value="#{userController.utilziatorDeAdaugat.cnp}" >
</h:inputText >
Segmentul de cod prezentat mai sus este preluat dintr -un facelet. userController reprezintă o
instanță a unui bean. utilizatorDeAdaugat reprezintă o instanță a unui obiect. Între acesta și clasa
UserController este o relație de has -a: atributul utilizatorDeAdaugat este o instanță a clasei Users în
interiorul UserController. Atributul cnp este, la rândul său, un field (de data aceasta de tip String) în
interiorul clasei Users. În vederea accesării acestora de către view, este necesară definirea getter -ilor și
a setter -ilor ( consistent cu arhitectura JavaBeans ). În momentul în care utilizatorul va submite form -ul,
atributele din controller vor fi populate cu valorile din formular:

Înainte de introducerea JSF 2, maparea bean -urilor și proprietățior acestora se făcea exclusiv în
fișierul de configurare (faces -config.xml). Cea de a doua versiune a framework -ului a introdus
posibilitatea mapărilor a cestora prin intermediul adnotărilor.

2.3 SpringSecurity

SpringSecurity reprezintă o sub -componenta a framework -ului SpringFramework. Datorită
arhitecturii modulare a acestuia, o componentă poate fi folosită independent de alta. De exemplu, un
programator poate alege utilizarea Spring AOP fără a fi necesară înca rcarea altor module (cum ar fi
Spring web MVC ș.a.m.d.).
Un avantaj al SpringSecurity este reprezentat de posibilitatea implementării politicilor de
securitate fine -grained. Cu alte cuvinte, este posibilă configurarea în detaliu a politicii de autentifica re /
autorizare. Configurarea securității poate merge până la nivelul metodelor. Spre exemplu, este posibilă
configurarea securității astfel încât, în momentul în care un utilizator autentificat dar fără destul
drepturi încearcă să acceseze o anumită pagin ă ce rezultă în apelarea unei anumite metode în

12
controller -ul (sau în layer -ele inferioare), o excepție să fie aruncată și utilizatorul redirecționat către o
pagină de eroare.
În vederea utilizării suportului Spring Security în vederea asigurării securității în contextul unei
aplicații web, este necesară configurarea SpringFramework și a Spring web MVC în deployment
descriptor -ul aplicației (i.e. web.xml)
În cazul de față, configurarea aplicației se face prin intermediul fișierelor XML. Declararea
acestora se face într -un fișier web.xml în elementul context -param. Odată încarcate aceste fișiere,
politica de securitate specificată în fișierul XML applicationContext -security.xml poate fi aplicată.
Să considerăm fișierul
<?xml version="1.0" encoding ="UTF-8"?>
<beans:beans xmlns="http://www.springframework.org/schema/security"
xmlns:beans ="http://www.springframework.org/schema/beans"
xmlns:xsi ="http://www.w3.org/2001/XMLSchema -instance"
xmlns:security ="http://www.springframework.org/schema/security"
xsi:schemaLocation ="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring -beans-3.0.xsd
http://www.springframework.org/schema/security
http://www.springframework.org/schema/security/spring -security -3.0.xsd" >

<global-method-security jsr250-annotations ="enabled"
secured-annotations ="enabled" pre-post-annotations ="enabled" />

<security:http auto-config="true">
<security:intercept -url pattern="/secure/**"
access="ROLE_ADMIN" />
<security:intercept -url pattern="/faces/**" access="ROLE_ADMIN" />
<security:form -login login-page="/login.htm"
default-target-url="/secure/protectedpage.htm"
authentication -failure-url="/authenticationerror.htm"
/>

<logout invalidate -session="true" logout-success-url="/login.htm"
logout-url="/j_spring_security_logout" />
</security:http >

<security:authentication -manager>
<security:authentication -provider >
<security:jdbc -user-service
data-source-ref="dataSource"

users-by-username -query="
select username,password, enabled
from users where username=?"

authorities -by-username -query="
select u.username, ur.ROLE from users u, user_roles ur
where u.username = ur.username and u.user name =? " />
</security:authentication -provider >

13
</security:authentication -manager>

<beans:bean id="dataSource"
class="org.springframework.jdbc.datasource.DriverManagerDataSource" >

<beans:property name="driverClassName" value="com.mysql.jdbc.Driver" />
<beans:property name="url"
value="jdbc:mysql://localhost:3306/servicecrm" />
<beans:property name="username" value="root" />
<beans:property name="password" value="1234" />
</beans:bean >

</beans:beans >

Se poate observa că acest fișier XML face uz de scheme XML în vederea stabilirii validității
fișierului XML în cauză.
Configurarea securității se realizează prin intermediul elementelor http, respectiv
authentication -manager ale namespace -ului security. P rin intermeidul elementului intercept -url sunt
configurate URL -urile la care au acces numai anumiti utilizatori. Se poate observa garantarea accesului
pe baza unui rol pe care un utilizator îl poate sau nu avea. În acest caz, accesului în URL -urile /faces și
/secure, respectiv în sub -path-urile acestora, este permis utilizatorilor ce au rolul ROLE_ADMIN sau
ROLE_USER .
De asemenea, se poate observa stabilirea paginilor la care utilizatorul urmează să fie redirectat
în urma unui logout.
În vederea integrării acestor URL -uri în aplicație, un controller Spring este definit:

@Controller
public class NavigationController {

@RequestMapping ("welcome" )
public ModelAndView welcome() {
ModelAndView mav = new ModelAndView( "welcome" );
return mav;
}

@RequestMapping ("login")
public ModelAndView login() {
ModelAndView mav = new ModelAndView( "autorizare/login" );
System.out.println( "Returning mav" );
return mav;
}
@RequestMapping ("authenticationerror" )
public ModelAndView error() {
ModelAndView mav = new ModelAndView( "autorizare/authenticationerror" );
return mav;
}

@RequestMapping ("secure/protectedpage" )

14
public ModelAndView securedPage(HttpServletRequest request,
HttpServletResponse response) {
ModelAndView mav = new ModelAndView( "secured_content/protected -page");
return mav;
}
}
Anotarile @RequestMapping corespund unui anumit URL. O analogie poate fi făcută cu
tradiționalii Servlets (@WebServlet("/admin/ServletAdmin")). Cu toate acestea, spre deosebire de
aceștia din urmă, este posibilă configurarea mult mai în detaliu a mapărilor URL -metodă. În funcție de
obiectul întors de către o metodă a controller -ului, user -ul este redirectat către un anumit view. Rolul
acestui controller este de a pune la dispoziție SpringSecurity posibilitatea de a trimite utilizatorul către
o anumită pagin ă (e.g. în cazul unui login eșuat, utilizatorul este trimis către o pagină de eroare).
Informațiile referitoare la utilizatori (respectiv la parolele acestora și la rolurile pe care aceștia
le au) sunt stoace în baza de date. După cum se poate observa, ele mentul authentication -manager
dispune de un sub -element numit jdbc -user-service. Acesta permite editarea unui anumit query sub
forma unui atribut, query ce trebuie să returneze numele utilizatorului, rolul (select u.username,
ur.ROLE from users u, user_rol es ur where u.username = ur.username and u.username =?) acestora și
parola (select username,password, enabled from users where username=?). Se poate observa utilizarea
unui JOIN în cazul primului query, JOIN unind tabele user_roles, respectiv users.
Consi stent cu tradiția de Dependency Injection a SpringFramework, se poate observa declararea
unui bean responsabil cu conectarea la sursa de date (în cazul de față, fiind vorba de conectarea la o
instanță a SGBD -ului MySQL).
Script -ul DDL executat în vederea creării tabelelor ”responsabile” cu securitatea:
CREATE TABLE `user_roles` (
`user_role_id` int(11) NOT NULL AUTO_INCREMENT,
`username` varchar(45) NOT NULL,
`ROLE` varchar(45) NOT NULL,
PRIMARY KEY (`user_role_id`),
UNIQUE KEY `uni_username_role` (`ROLE`,`username`),
KEY `fk_username_idx` (`username`),
CONSTRAINT `fk_username` FOREIGN KEY (`username`) REFERENCES `users` (`username`)
);

CREATE TABLE `users` (
`cnp` varchar(240) DEFAULT NULL,

15
`email` varchar( 240) DEFAULT NULL,
`username` varchar(45) NOT NULL,
`password` varchar(45) NOT NULL,
`nume` varchar(50) DEFAULT NULL,
`prenume` varchar(50) DEFAULT NULL,
`enabled` tinyint(4) NOT NULL DEFAULT '1',
PRIMARY KEY (`username`)
);
Se observa inserare a datelor în cele două tabele, folosind username -ul pe post de Primary Key
în tabelul users, respectiv stabilirea unui Foreign Key în cel de -al doilea tabel ce referențiază Primary
Key-ul din primul.

2.4 Modelul de date

Datele și domain modelul poate fi foarte bine reprezentat printr -o diagrama ER:

Figura 2.4.1

16
Figura de mai sus reprezintă diagrama EER (Enhanced entity –relationship model) a bazei de
date a aplicației. Se pot observa relațiile dintre diferitele entități. Tabelele users, respectiv user_roles
îndeplinesc rolul persistării informațiilor referitoare l a procesul de autentificare / autorizare.

2.5 JPA

Un număr foarte mare de framework -uri destinate lucrului cu layer -ul de persistență au apărut.
Acestea se adresează tuturor tehnologiilor de persistare, nu numai celor bazate pe SGBD -uri. Spre
exemplu, Java pune la dispoziție API -uri precum JAXB (Java And XML Binding – soluție dedicată
marshaling -ului datelor din clase în fișiere XML) ce se adresează și altor tehnologii în afară de bazele
de date. Cu toate acestea, bazele de date relaționale reprezintă u nele dintre cele mai utilizate și frecvent
întâlnite mecanisme de persistare a datelor. Cel mai adesea este vorba de sisteme de gestiune a bazelor
de date relaționale. Cu toate acestea, numeroase proiecte apelează la utilizarea bazelor de date NoSQL
în ved erea persistării datelor.
În cazul proiectului actual a fost ales SGBDR -ul MySQL, datorită popularității, comunității
largi de utilizatori și avantajelor bazelor de date ”tradiționale” în general (suport pentru executarea
tranzacțiilor și izolarea acestor a, securitate etc.).
Tehnologiile Java de lucrul cu bazele de date sunt consistente cu ”tradiția” Java în care
portabilitatea este pe primul loc. JDBC pune la dispoziție numeroase Drivere ce pot fi utilizate pentru a
comunica cu un anumit SGBD. Schimbarea acestuia este transparentă, iar query -urile scrise de
programator sunt universal valabile.

17

Figura 2.5.1

Cu toate acestea , există numeroase neajunsuri prezentate de JDBC. Până la introducerea Java 7,
JDBC îl confrunta pe programator cu numeroase probleme. Una dintre acestea era reprezentată de
arhitectura excepțiilor – utilizarea SQLException (de tip checked – programatorul era forțat să o
capteze sau sa o arunce mai departe ) în vederea lucrului cu toate situațiile excepționale ce ar putea să
apară în lucrul cu SGBD -ul. Aceasta prezenta un mesaj de eroare specific bazei de date în cauză.
De asemenea, scrierea query -urilor putea fi relativ complicată.
Tehnologiile ORM au apă rut pentru adresa multe neajunsuri ale abordării ”tradiționale”. În
cazul paradigmei JDBC, una dintre potențialele probleme consta în lipsa de experiență pe care
numeroși programatori o au în lucrul cu SQL. Aceștia sunt mai degrabă obișnuiți a lucra cu cla se,
iererhii de clase, obiecte ș.a.m.d.
Tehnologiile ORM se concentrează pe mijloacele de mapare ale tabelelor din baza de date cu
clase. Acest aspect prezintă numeroase avantaje. Acestea nu sunt specifice exclusiv limbajului de
programare Java, tehnolog ii ORM fiind dezvoltate și suportate de majoritatea limbajelor de programare
populare.
Aplicația curentă folosește JPA (Java Persistency API) în vederea lucrului cu instanța MySQL.
JPA pune la dispoziția programatorului un mijloc de a micșora ”prăpastia” d intre domain model și
codul aplicației, reprezentând tabelele din baza de date sub forma POJO -urilor (Plain Old Java Object) .

18
Mecanismul de mapare se bazează pe anotări (Java Annotations). Anotările permit claselor să
păstreze ”aspectul” tradițional de PO JO-uri, oferind metadatele necesare interpretării acestora de către
mecanismul de persistență utilizat. O abordare similară ar fi fost utilizarea fișierelor XML, cu toate
acestea, deși această modalitate ar fi prezentat posibiltatea evitării ”poluării” cla selor Java cu anotări,
nu ar fi dispus de posibilitatea verificărilor efectuate la compilare.
Informațiile generale referitoare la setările bazei de date sunt specificate în fișierul
persistency.xml. Acesta este specific oricărei aplicații ce utilizează JPA ca mecanism principal de
realizare a persistenței datelor. Fisierul persistency.xml are ”res ponsabilitatea” configurării contextului.
JPA pune la dispoziția programatorului interfața EntityManager. Prin intermediul unei instanțe de acest
tip, programatorul poate lucra cu obiectele asociate tabelelor, executând statement -uri DML.
Există mai mulți provideri ce pun la dispoziție implementări ale EntityManager. Schimbarea de
la un persistency provider la altul este extrem de simplă. În cazul aplicației de față, a fost utilizat
EclipseLink (org.eclipse.persistence.jpa.PersistenceProvider ) în vederea o feririi unei implementări
pentru EntityManager.

2.6 Mecanismul de efectuare al tranzacțiilor

În contextul utilizării JPA ca soluție de persistență, există două modalității principale de
efectuare a tranzacțiilor: tranzacții locale, respectiv tranzacții globale. În fișierul de configurare al
aplicației (persistency.xml), se poate observa următoare declarație:
<persistence -unit name="ServiceCRM" transaction -type="RESOURCE_LOCAL">
Aceasta sugerează că tranzacțiile vor fi de tip local (i.e. locale resursei) . Motivul alegerii acestui
tip de tranzacție constă în lipsa necesității utilizării JTA (Java Transaction API). Nu este necesară
efectuarea tranzacțiilor complexe, pe mai multe instanțe de SGBD -uri, implicând diferite tipuri de
resurse ș.a.m.d. De asemenea, utilizarea tranzacțiilor globale ar implica necesitatea JTA, ceea ce ar fi
rezultat în declararea datelor conexiunii la baza de date prin intermediul JNDI, legând astfel aplicația
de un anumit server (i.e. configurarea JNDI diferă de la server la server – spre exemplu, utilizarea
fișierelor specifice de configurare în tomcat este diferită de configurarea JNDI în cazul serverului web
GlassFish). Așadar, toate tranzacțiile fiind de tip resource -local, este posibilă portarea mai ușoara a
aplicați ei.
JPA reprezintă un API extrem de configurabil. Numeroase opțiuni pot fi specificate în fișierul
persistency.xml (e.g. configurarea nivelului de logare este posibilă prin simpla declarare a unui nou
element XML și a atributelor corespunzătoare acestuia: <property name="eclipselink.logging.level"

19
value="FINEST"/> Se poate observa configurarea nivelului de logging corespunzător providerului ce
implementează EntityManager, EclipseLink. Această opțiune este specifică acestui provider).
Fișierul de configur are are rolul centralizării informațiilor, atât a celor referitoare la datele de
conectare la baza de date, cât și a celor referitoare la clasele incluse în procesul de mapare:
<persistence -unit name="ServiceCRM" transaction -type="RESOURCE_LOCAL">
<provi der>org.eclipse.persistence.jpa.PersistenceProvider</provider>
<class>ro.silviu.model.ContactClient</class>
<class>ro.silviu.model.Contract</class>
<class>ro.silviu.model.Operatie</class>
<class>ro.silviu.model.Users</class>
<class>ro.silviu.model.UserRoles</class>

<properties>
<property name="eclipselink.target -server" value="None"/>
<property name="javax.persistence.jdbc.driver" value="com.mysql.jdbc.Driver"/>
<property name="javax.persistence.jdbc.url"
value="jdbc:mysql://localhost:3306/servicecrm"/>
<property name="javax.persistence.jdbc.user" value="root"/>
<property name="javax.persistence.jdbc.password" value="1234"/>
</properties>
</persistence -unit>

2.7 Tomcat

Ca server web, am ales utilizarea Apache Tomcat, datorită simplității prezentate de acesta.
Tomcat reprezintă un server web ”lightweight”, un așa -numit Servlet container. Acesta nu dispune de
profilurile complexe Enterprise puse la dispoziție de servere pr ecum GlassFish, WebLogic, WebSphere
ș.a.m.d.
Aplicațiile dezvoltate cu scopul de a fi deployate pe acest server prezintă un nivel de
portabilitate mult mai ridicat. Spre exemplu, utilizarea unui server precum GlassFish sau Oracle
Weblogic ar fi facilitat utilizarea paradigmei Enterprise (e.g. utiliza rea tehnologiei EJB – Enterprise
Java Beans), facilitând astfel efortul de dezvoltare, însă ar fi limitat (dacă nu chiar eliminat) POJO -uri
mapate
Date conectare la baza
de date

20
posibilitatea deploy -ului pe un servlet container (cum ar fi Jetty, Tomcat ș.a.m.d.). O aplicație ce
rulează pe Tomcat are ma ri șanse de a fi portată ulterior pe un Enterprise Server, însă inversul nu este
întotdeauna adevărat.
Există anumite elemente ce pot îngrădi posibilitatea de portare, chiar dacă un servlet container
simplu este utilizat. Spre exemplu, în contextul utiliză rii autentificării bazate pe form -uri, aceasta ar
implica definirea utilizatorilor și a rolurilor acestora conform constrângerilor specifice acestui server.
Cu toate acestea, după cum este cazul aplicației curente, această limitare este evitată, datorită f olosirii
SpringSecurity, ce permite definirea utilizatorilor și rolurilor într -o manieră portabilă, ce permite
deploy -ul pe orice server. Acesta reprezintă un alt motiv în spatele alegerii API -ului SpringSecurity în
vederea asigurării suportului pentru aut entificare și autorizare.

3. Prezentarea aplicației Service CRM

Aplicația Service CRM a fost realizată cu ajutorul mediului de dezvoltare ECLIPSE. Am ales
acest IDE deoarece îți pune la dispoziție extrem de multe tool -uri pentru dezvoltarea de aplicații web de
nivel mediu/enterprise. De asemenea, acesta include o serie de componente
ce îi permit utilizatorului să creeze și să manipuleze o bază de date , respectiv un server Apache Tomcat
direct din mediul de lucru .

Primul pas pe care user -ul trebuie să -l facă este să navigheze la pagina principală a aplicației și
să se autentifice pentru a obține accesul la sistem.

21

Figura 3.1 – Pagina de autentificare
Dupa ce se loghează, utilizatorul – client este redirecționat către o pagină unde poate vizualiza
operațiile curente ce se efectuează asupra autovehiculului său , precum și toate contractele pe care le -a
avut încheiate cu firma de service .

Figura 3.2 – Pagina principală user -client

22
În cazul unui utilizator administrator, acesta poate vedea toate ope ratiile la care este asignat.
După cum se poate observa și în captura de ecran de mai jos, user -ul din cadrul firmei are la dispoziție
mai multe opțiuni de navigare.

Figura 3.3 – Pagina principală user -admin
În cadrul secțiunii de administrare a utilizatorilor, pagina principală conține un tabel cu toți
utilizatorii din cadrul platformei, precum și un formular de adăugare a utilizatorilor .

Figura 3.4 – Lista utilizatori

23
După crearea unui cont nou, este necesară navigarea către pagina de editar e a utilizatorului
pentru a i se acorda un rol, altfel acesta nu se poate autentifica pe platformă.

Figura 3.5 – Editare utilizator
Odată adăugat un utilizator – client, putem să îi adăugăm un contract prin intermediul secțiunii
de vizualizare a unui user.

Figura 3.6 – Adăugare contract la utilizator

24

În pagina de contracte se pot asigna contracte atât utilizatorilor – clienți, cât și angajaților.

Figura 3.7 – Pagina de contracte
În cadrul oricărui contract există posibilitatea de a adăuga una sau mai multe operații ce
contribuie la atingerea scopului primar. Odată ce data de finalizare este depășită, operația va fi marcată
ca fiind „Finalizată” , iar până atunci se va afișa mesajul „În derulare”.

Figura 3.8 – Detalii contract

25
În cazul în care se modifică termenul de finalizare a unei operații sau costurile aferente, aceste
date pot fi modificate din pagina de editare a unei operații.

Figura 3.9 – Editare operație
Datele se vor actualiza automat și în cadrul paginii unui contract.

Figura 3.10 – Actualizare date pagina contract

26
Odată cu revenirea la pagina principală a site -ului ( secțiunea „Pagina mea” ), se poate observa
faptul că a fost actualizată lista de contracte ata șată unui utilizator.

Figura 3 -11 – Pagina principala după adăugarea unui contract
Utilizatorul – administrator are și posibilitatea de a gestiona numărul de piese din stoc.

Figura 3.12 – Pagina gestiune piese

27

În ceea ce privește user -ul client, acesta poate să vizualizeze, pe lângă contractele pe care le -a
avut încheiate cu firma de service , și toate operațiile ce s -au desfășurat în cadrul fiecăruia.

Figura 3.13 – Detalii contract client

28

4. Direcții viitoare de dezvoltare

Aplicația de față reprezintă doar o implementare de bază a unui sistem transparent de urmă rire
al proceselor de service auto. Pentru introducerea acesteia la un nivel mai înalt sunt necesare o serie de
îmbunătățiri, atât pe partea funcțională, cât și la nivel de interfață :
1) Includerea unui cronometru pentru fiecare operațiune în parte din cadrul unui contract: astfel
utilizatorul va ști cu aproximație cât timp va dura procesul de reparație și va putea observa
dacă apar întârzieri.
2) Adăugarea unei secțiuni de comenta rii ale mecanicilor pentru fiecare contract în parte: astfel
utilizatorul va fi ținut la curent cu stadiul reparațiilor și eventuale probleme ce au fost
întâmpinate. De asemenea, utilizatorii din cadrul firmei vor putea să ceară informații de la
clienți în cazul în care se descoperă piese ce ar trebui înlocuite cât mai repede, altele decât
cele planificate .
3) Posibilitatea de a atașa imagini la anumite operațiuni – includerea acestei funcționalități va
ajuta la construirea unei imagini mai bune a înt regului p roces.
4) Accesul clientului la aplicatie se va realiza cu ajutorul numă rului de înmatriculare – username
și ultimele 6 cifre ale codului numeric personal – parolă . De asemenea, dacă un client are mai
multe automobile în reparaț ie acesta va primi câte un cont pentru fiecare autoturism .
5) Includerea unei secțiuni de documente atașate la fiecare contract : astfel, dacă firma de service
are nevoie de mai multe acte din partea clientului, acesta va avea posibilitatea de a le încărca
pe platformă, atât de pe c alculator, cât și de pe telefonul mobil.
De asemenea, de -a lungul procesului de îmbunătățire al aplicației se va urmă ri și realizarea unei
interfețe câ t mai p rietenoase, astfel încât interacțiunea clientului cu platforma va fi facilă, indiferent de
nivelul cunoștințelor sale î n domeniul informatic.

29

Concluzii

Prin prezenta lucrare am dorit să subliniez necesitatea implementării unui sistem transparent de
urmă rire al proceselor de service auto , precum și să demonstrez că introducerea unei astfel de platforme
în orice firmă de service ar putea aduce multiple beneficii, atât clienților, cât și angajaților companiei .
La baza realizării acestei lucrări a stat și faptul că, în urma cercetări amănunțite, am constatat că
în România nu există, la ora actuală , nici un fel de platformă electronică de gestiune a proceselor din
cadrul unui service auto, în condițiile în care marea majoritate a companiilor au multe dintre procesele
interne transpuse în mediul electronic.
Pentru dezvoltarea platformei din cadrul ac estei lucrări am optat să folosesc tehnologii le Java
datorită flexibilității și a ușurinței de utilizare, precum și a numeroaselor tool – uri pe care dezvoltatorii
le au la dispoziție.
La începutul construirii acestei aplicații Web a trebuit să aleg între a mă axa strict pe crearea de
facilități pentru clienți sau a realiza o platformă dedicată atât angajaților, cât și persoanelor din afara
firmei. În final am decis că abordarea cea mai bună ar fi să construiesc ceva pentru ambele părți din
cadrul procesulu i.
Astfel, pentru salariații firmei am realizat o secțiune de gestiune a utilizatorilor și a contractelor
atașate fiecăruia. De asemenea, angajații pot să gestioneze operațiile ce vor fi incluse în fiecare
contract, precum și stocurile de piese.
În ceea ce privește user -ul client, acesta poate doar să vizualizeze contractele sale, precum și
lista de operațiuni aferentă unui contract.
În concluzie, pot spune că realizarea acestei lucrări m -a ajutat foarte mult să mă dezvolt din
punct de vedere profesional și sper că voi putea aplica cu succes tot ceea ce am învățat din construirea
acestei platforme și la un nivel enterprise.

30

Bibliografie

ARTICOLE ȘI DOCUMENTE ONLINE
1. http://docs.spring.io/spring -security/site/docs/3.0.x/reference/ns -config.html
2. http://www.mkyong.com/tutorials/spring -security -tutorials/
3. https://en.wikipedia.org/wiki/Spring_Security
4. https://en.wikipedia.org/wiki/Apache_Tomcat
5. http://www.tomcatexpert.com/blog/2011/10/19/understanding -apache -tomcat -getting –
started
6. http://www.tutorialspoint.com/jsf/
7. https://en.wikipedia.org/wiki/JavaServer_Faces
8. http://www.javatpoint.com/jsp -tutorial
9. http://www.tutorialspoint .com/jpa/
10. https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

31

Anexe

Anexa 1

32

Anexa 2

Anexa 3