FACUL TATEA DE AUTOMATICĂ ȘI CALCULATOARE DEPARTAMENTUL DE AUTOMATICĂ VIZAT, DECAN, Director DEPARTAMENT , Prof. dr. ing. Liviu MICLEA Prof. dr. ing…. [620866]

FACULTATEA DE AUTOMATIC Ă ȘI CALCULATOARE
DEPARTAMENTUL DE AUTOMATICĂ

BIBLIOTECĂ ONLINE INTERACTIVĂ

PROIECT DE DIPLOM Ă

Autor : Maria Magdalena ȘIMON

Coordonator : Prof. dr. ing. Honoriu VĂLEAN

2015

FACUL TATEA DE AUTOMATICĂ ȘI CALCULATOARE
DEPARTAMENTUL DE AUTOMATICĂ

VIZAT,

DECAN, Director DEPARTAMENT ,
Prof. dr. ing. Liviu MICLEA Prof. dr. ing. Honoriu VĂLEAN

Autor Maria Magdalen a ȘIMON

BIBLIOTECĂ ONLINE INTERACTIVĂ

1. Enunțul temei: Proiectul își propune realizarea unei biblioteci online interactive, o
combinație hibridă între bibliotecile digitale și cele tradiționale.

2. Conținutul proiectului: Pagina de Prezentare, A precier ile Coordonatorului de
Proiect, S inteza, Introducere , Obiectivele Proiectului, Studiu Bibliografic, Analiza și
Fundamentare Teoretica , Proiectare de Detaliu și Implementare , Testare și Validare
Concluzii, B ibliografie .

3. Locul documentației: Universitatea din Cluj Napoca

4. Consultanți: Prof. dr. ing. Honoriu VĂLEAN

5. Data emiterii temei: noiembrie 2014

6. Data predării: iunie 2015

Semnătura autorului ______________ _______

Semnătura coordonatorului _______________

FACULTATEA DE AUTOMATICĂ ȘI CALCULATOARE
DEPARTAMENTUL DE AUTOMATICĂ

Declarația autorului,

Subsemnatul Maria Magdalena ȘIMON , student: [anonimizat], Universitatea Tehnică din Cluj -Napoca, declar că ideile, analiza, proiectarea,
implementarea, rezultatele și concluziile cuprinse în acest proiect de diplomă constituie
efortul meu propriu, mai puțin acele elemente ce nu îmi aparțin, pe care le indic și recunosc ca
atare.
Declar de asemenea că, după știința mea, lucrarea în această formă este origin ală și nu
a mai fost niciodat ă prezentată sau depusă în alte locuri sau alte instituții decât cele indicate în
mod expres de mine.

Data: Autor: Maria Magdalena ȘIMON
Număr matricol: 21020898
Semnătura:____________

Cuprins
Cuprins

Capitolul 1 INTRODUCERE ………………………….. ………………………….. ……….. 2
1.1 Contextul Proiectului ………………………….. ………………………….. ………………………….. ….. 2
1.2 Domeniul Pro iectului ………………………….. ………………………….. ………………………….. ………………………….. ….. 2
1.3 Structura documentației ………………………….. ………………………….. ………………………….. ………………………….. . 3
Capitolul 2 OBIECTIVELE PROIECTULUI ………………………….. …………… 4
2.1 Obiective ………………………….. ………………………….. ………………………….. ………………………….. ………………….. 4
2.2 Specificații ………………………….. ………………………….. ………………………….. ………………………….. ……………….. 4
2.2.1 Specificațiile proiectului ………………………….. ………………………….. ………………………. 5
2.3 Planul Proiectului ………………………….. ………………………….. ………………………….. ………………………….. ………. 6
Capitolul 3 STUDIU BIBLIOGRAFIC ………………………….. ……………………… 7
3.1 Baze de Date ………………………….. ………………………….. ………………………….. ………………………….. ……………… 7
3.1.1 Baze de Date Relaționale ………………………….. ………………………….. ………………………. 7
3.1.2 Baze de Date NoSQL ………………………….. ………………………….. ………………………….. . 8
3.2 ASP.NET ………………………….. ………………………….. ………………………….. ………………………….. ………………….. 8
3.2.1 Visual Studio .NET ………………………….. ………………………….. ………………………….. …… 9
3.2.2 ASP.NET MVC ………………………….. ………………………….. ………………………….. ………. 10
3.3 JavaScript ………………………….. ………………………….. ………………………….. ………………………….. ……………….. 12
3.3.1 Ajax ………………………….. ………………………….. ………………………….. ……………………… 12
3.3.2 JQuery ………………………….. ………………………….. ………………………….. ………………….. 13
3.4 HTML5 ………………………….. ………………………….. ………………………….. ………………………….. …………………… 13
3.5 CSS3 ………………………….. ………………………….. ………………………….. ………………………….. ………………………. 14
3.6 Harți Google API ………………………….. ………………………….. ………………………….. ………………………….. ……… 15
3.7 Apache Solr ………………………….. ………………………….. ………………………….. ………………………….. …………….. 15
Capitolul 4 ANALIZĂ ȘI FUNDAMENTARE TEORETICĂ ………………. 17
4.1 Interacțiune Utilizator -Aplicație ………………………….. ………………………….. ………………………….. ……………… 17
4.2 Stocarea și Prelucrarea Informațiilor ………………………….. ………………………….. ………………………….. ………. 18
4.2.1 Stocare Datelor ………………………….. ………………………….. ………………………….. ……… 18
4.2.2 Prelucrarea Datelor ………………………….. ………………………….. ………………………….. . 22
4.3 Solr Search ………………………….. ………………………….. ………………………….. ………………………….. …………….. 23
4.4 Servicii Google utilizate în aplicație ………………………….. ………………………….. ………………………….. ………… 24
4.5 Tipuri de utilizatori și cazuri de utilizare ………………………….. ………………………….. ………………………….. ….. 24
4.5.1 Tipuri de utilizatori ………………………….. ………………………….. ………………………….. … 24
4.5.2 Cazuri de utilizare ………………………….. ………………………….. ………………………….. …. 25
4.6 Afișare cărți după preferințe sau starea de spirit ………………………….. ………………………….. …………………….. 32
4.6.1 Afișare cărți după preferințe ………………………….. ………………………….. ………………… 32
4.6.2 Afișare cărți după starea de spirit ………………………….. ………………………….. ………… 32
Capitolul 5 PROIECTARE DE DETALIU ȘI IMPLEMENTARE ……….. 33
5.1 Detalii de Implementare ………………………….. ………………………….. ………………………….. ………………………… 33
5.1.1 Procesul de înregistrare în aplicație ………………………….. ………………………….. …….. 33

Cuprins

5.1.2 Procesul de autentificare în aplicație ………………………….. ………………………….. ……. 34
5.1.3 Procesul de adăugare/ editare biblioteci ………………………….. ………………………….. .. 35
5.1.4 Procesul de adăugare/ editare carte ………………………….. ………………………….. …….. 37
5.1.5 Procesul de editare a profilului unui utilator ………………………….. ……………………… 38
5.1.6 Procesu l de adăugare/ editare preferință ………………………….. ………………………….. . 40
5.1.7 Procesul de returnare a cărților după stare de spirit ………………………….. …………… 41
5.2 Structura bazei de date ………………………….. ………………………….. ………………………….. ………………………….. . 42
5.2.1 Entitatea Users ………………………….. ………………………….. ………………………….. … 42
5.2.2 Entitatea Books ………………………….. ………………………….. ………………………….. … 42
5.2.3 Entit atea Library ………………………….. ………………………….. ………………………….. 43
5.2.4 Entitatea Publisher ………………………….. ………………………….. ………………………….. … 43
5.2.5 Entitatea Category ………………………….. ………………………….. ………………………….. …. 43
5.2.6 Entitatea Address ………………………….. ………………………….. ………………………….. …… 43
5.2.7 Entitatea Feelings ………………………….. ………………………….. ………………………….. ….. 43
5.2.8 Entitatea Roles ………………………….. ………………………….. ………………………….. ………. 43
5.2.9 Entitatea Authors ………………………….. ………………………….. ………………………….. …… 44
5.2.8 Entitatea History ………………………….. ………………………….. ………………………….. ……. 44
5.2.8 Entitatea UserCategoryReference ………………………….. ………………………….. ………… 44
5.2.9 Entitatea UserAuthorReference ………………………….. ………………………….. ……………. 44
Capitolul 6 TESTARE ȘI VALIDARE ………………………….. ……………………. 45
6.1 Procesul de înregistrare ………………………….. ………………………….. ………………………….. …………………… 47
6.2 Procesul de Autentificare ………………………….. ………………………….. ………………………….. ……………………….. 49
6.3 Pagina Principală ”Home” ………………………….. ………………………….. ………………………….. ………………. 50
6.4 Adaugă carte ………………………….. ………………………….. ………………………….. ………………………….. …….. 52
6.5 Adaugă Bibliotecă ………………………….. ………………………….. ………………………….. ………………………….. …… 54
Capitolul 7 CONCLUZII ………………………….. ………………………….. ……………. 55
7.1 Contribuții ………………………….. ………………………….. ………………………….. ………………………….. ………… 55
7.2 Analiza rezultatelor ………………………….. ………………………….. ………………………….. ………………………… 56
7.3 Dezvoltări ulterioare ………………………….. ………………………….. ………………………….. ………………………….. .. 56
BIBLIOGRAFIE ………………………….. ………………………….. …………………………. 57

Proiect de diplomă
2
Capitolul 1 INTRODUCERE

1.1 Contextul Proiectului

Suntem în epocă unei societăți bazate pe Tehnologia Informației și pe întrebuințările
acesteia în toate sfer ele de activitate umană. Această tehnologie este din ce în ce mai folosită
pentru înregistrarea și stocarea datelor în formă digitală
Revoluția în domeniul Tehnologiei Informației influențează toate d omeniile de
activitate. Aceasta a revoluționat până și c onceptul bibliotecilor care încearcă încet, să devina
digitale pentru a satisface cererea utilizatorilor. Noua generație , a cărei cerere de informații nu
este niciodată satisfăcută cere ca bibliotecile tradiționale să fie transformate în biblioteci
digital e interconectate .
Folosirea unei biblioteci digitale are foarte multe avantaje. De exemplu, aceasta este
accesibilă la orice oră și din orice loc cu condiț ia ca utilizatorul să aibă un calculator conectat
la internet. Un alt avantaj ar fi acela că o carte poate fi accesată de mai mulți utilizatori în
același timp.
Chiar daca bibliotecile digitale oferă foarte multe avantaje, eu consider ca acestea nu
ar trebui sa le înlocuiască definitiv pe cele tradiționale ci ar trebui sa fie o combinație î ntre
cele două . Astfel m -am decis să dezvolt o aplicație care să permită accesul online la cărțile din
mai multe biblioteci, însă lectura acestora sa fie făcută în mod tradițional, deoarece nimic nu
este mai relaxant decât să citești o carte bună î ntr-un loc liniștit.
Aplicația se bazează pe prelucrarea mai multor date care sunt preluate cu ajutorul
utilizatorilor. Aceasta are o funcționare asemănătore cu cea a unei biblioteci online, doar că
aduce câteva îmbunătățiri cum ar fi :
– recomandarea unei liste de cărți în funcț ie de preferințele utilizatorului
– fișarea unei liste de cărți în funcție de starea emoțională a utilizatorului
– păstrarea unui istoric al cărților citite
– afișarea unei harți cu locația bibliotecilor

1.2 Domeniul Proiectului

Domeniul acestui proiect este cel al calculatoarelor, dar și cel educațional deoarece
încearcă să creeze o bibliotecă hibrida, o combinație între bibliotecile tradiționale și cele
digitale.
Această aplicație va putea fi accesată atât de pe desktop cât și de pe telefonul mobil.
Benefic iile oferite de această aplicație sunt reprezentate de faptul că utilizatorii vor
avea acces la orice oră la cărțile din mai multe biblioteci, vor putea păstra un istoric al cărților
citite, vor primi o listă cu cărțile pe care ar trebui să le citească în funcție de preferințele lor și
vor putea să primească recomandări cu cărțile pe care ar trebui să le citească în funcție de
stare de spirit.

Capitolul 1
3
1.3 Structura documentaț iei

În paragrafele care urmează voi descrie pe scurt conținutul fiecărui capitol care urmează să
fie prezent în această lucrare.

Capitolul 1.Introducere :
Acest capitol acoperă introducerea cititorului în contextul și domeniul de activitate al
produsului. Tot aici se regăsește și un rezumat al conținutului prezentat în fiecare
capitol.

Capitolul 2.Obiectivele Proiectului :
Acest capitol prezintă tema propriu -zisă și detaliază obiectivele pe care acesta aplicație
trebuie să le îndeplinească.

Capitolul 3.Studiu bibliografic :
Acest capitol va conține studiul despre documentarea b ibliografică care a fost necesară
în stadiul de proiectare al acestui sistem informatic. Vom regăsi informații despre
modul în care acest gen de sistem îmbunătățește sistemele existente, despre sisteme
asemănătoare deja existente pe piață și despre tehnolo gii folosite pentru crearea
sistemului.

Capitolul 4.Analiză și fundamentare teoretic ă:
Scopul acestui capitol este de a explica principalele funcționalități ale aplicației
implementate. Aici se va descrie soluția propusă dintr -un punct de vedere teo retic –
explicații și demonstrații ale proprietăților și valoarea teoretică.

Capitolul 5. Proiectare de Detaliu și Implementare :
Capitolul aceasta împreună cu precedentul prezintă în detaliu atât implementarea cât și
analiza teoretică o proiectului .

Capitolul 6. Testare și validare :
Acest capitol este dedicat pentru testarea și validarea funcționării sistemului, dar și
explicarea datelor obținute în urma acestor teste.

Capitolul 7. Concluzii :
Aici se prezintă concluziile rezultate în urma proiectării, implementării și testării
proiectului. Vor fi prezentate argumente atât pro cât și contra ale sistemului proiectat.

Bibliografie :
La finalul lucrării se prezintă bibliografia și anexele. Referințele bibliografice
enumerate sunt ce le menționate pe parcursul lucrării.

Proiect de diplomă
4

Capitolul 2 OBIECTIVELE PROIECTULUI

2.1 Obiective
Obiectivul principal al acestui proiect este acela de definire și realizare a unei aplicații
care să permită utilizatorilor accesul online la mai multe biblioteci, dându -le posibilitatea de
a-și vizualiza istoricul și de a -și gestiona o listă cu cărțile favorite .
De asemenea, aplicația va oferi utilizatorilor opțiunea de a -și alege cărți în funcție de starea
emoționala sau în funcție de preferințe.
2.2 Specificaț ii

Acest subcapitol conține principalele specificații ale aplicației , având în vedere faptul
că pentru un proiect de tip software specificațiile reprezintă punctul de plecare.
Rolul major al acestora este reprezentat de diminuarea procentului de modificare al c erințelor
după ce dezvoltarea propriu -zisă a început .
De asemenea specificațiile au rolul de a elimina posibilele neclarități în ceea ce privește
funcționalitatea aplicației și de a evita o situație similar ă celei din F igura 2.1

Figura 2.1 Rolul Specificațiilor

Capitolul 2
5
2.2.1 Specificațiil e proiectului

Comportamentul aplicației diferă î n funcție de următorii factori:
 Utilizatorul nu este logat
 Utilizatorul este logat și are rolul de user
 Utilizatorul este logat și are rolul de admin
 Utilizatorul este logat și are rolul de superadmin

Cazu l 1- utilizator nelogat :

În acest caz utilizatorul are acces la pagina principala “Home ” a aplicației unde o să
poată realiza următoarele operații :
– Căutare unei cărți după titlu
– Filtrarea cărților în funcție de autor, categorie și nume
– Vizualizarea de taliilor despre o anumită carte, precum și biblioteca unde poate fi
găsită
– Posibilitatea de înregistrare

Cazul 2 – utilizator logat (user) :

Acest utilizator o sa poată realiza toate operațiile descrise mai sus pentru utilizatorul
nelogat, mai puțin cea de înregistrare deoarece acesta are deja un cont.
Pe lângă aceste operații , el are acces la următoarele pagini:
 “History ” unde poate realiza următoarele:
– Vizualizarea cărților citite
– Marcarea unei cărți ca fiind citită sau necitită
 “My Books ” care o să îi p ermit ă :
– Selectarea cărților în funcție de starea sa emoțională (bucurie, emoție,
tristețe)
– Selectarea cărților în funcție de preferințele sale în materie de autori,
categorii
– Adăugarea cărților la favorite
 “My Profile ” unde poate realiza următoarele:
– Editarea profilului
– Editarea preferințelor

Cazul 3 – utilizator logat ( admin) :

Acest utilizator o sa poată realiza toate operațiile descrise mai sus pentru utilizatorul
logat cu rolul de user.
Pe lângă aceste operații , el are acces la pagina “Library ” unde po ate realiza
următoarele:
– Adăugarea un or cărți noi
– Editarea cărților existente
– Ștergerea unor cărți existente

Proiect de diplomă
6

Cazul 4 – utilizator logat (superadmin) :

Acest utilizator o sa poată realiza toate operațiile descrise mai sus pentru utilizatorul
logat cu rolul de user.
Pe lângă aceste operații , el are acces la pagina “Admin ” unde poate realiza
următoarele:
– Adăugarea unei biblioteci noi
– Editarea datelor unei biblioteci existente
– Ștergerea unei biblioteci existente

2.3 Planul Proiectului

Pentru a putea reali za obiectivul setat și pentru respectarea specificațiilor vom alcătui
un plan pe care apoi o sa îl urmăm.
Acesta va avea următoarele etape:
– Etapa cerințelor
o În această etapa se vor defini cerințele și marchează începutul
proiectului

– Etapa cercetării
o Aceas tă etapa trebuie sa aibă drept rezultat studiere tehnologiilor
prezentate în Capitolul 3

– Etapa de analiză
o În această etapă se face un rezumat al informațiilor obținute în etapa
anterioară și se dezvoltă un algoritm pseudocod

– Etapa de design
o Aceasta este cea mai importantă etapă deoarece face legătura intre
partea teoretică studiata și partea practică care o sa fie implementată

– Etapa de implementare
o În această etapa cunoștințele acumulate sunt aplicate intr -un mediu
practic

– Etapa de testare
o În această et apa se verifică daca aplicația respectă specificațiile stabilite

– Etapa de culegere a rezultatelor
o Aceasta este ultima etapă în care aplicația trebuie testată intens și
comparată cu alte aplicații similare

Capitolul 3
7

Capitolul 3 STUDIU BIBLIOGRAFIC

3.1 Baze de Date

Baza de date reprezintă unul dintre instrumentele vitale în realizarea unui aplicații
software și sunt structurate astfel încât să permită stocarea și manipularea datelor în
concordanța cu operațiile de procesare a datelor.
Acest lucru poate fi observat și d in Figura 3.1 unde sunt prezentate componentele unei
aplicații web.

3.1.1 Baze de Date Relaționale

Bazele de date relaționale sunt acele baze de date în care datele, văzute ca și atribute
ale entităților reale, sunt socate în tabele și sunt legate între ele prin relații .
Modul acesta de structurare a datelor, bazat pe legături le dintre date, permite
eliminarea redundanței, astfel încât stocarea și, mai ales, modificarea unei informații se face
într-un singur loc, iar, din punct de vedere funcțional, această structură
permite regăsirea , filtrarea , ordonarea și agregarea datelor, în mod natural.
Sistemul de gestiune al bazelor de date relaționale (SGBD R) este un sistem software
complet care implementează modelul de date relațional și respectă cerințele impuse de acest
model. El este o interfață între utilizatori și baza de date . Rolul acestuia este evidențiat î n
Figura 3.2. Figura 3.1 Componentele unei aplicații web

Proiect de diplomă
8

Figura 3.2 Rolul SGBD -ului
SQL Server este un exemplu de SGBDR și este realizat de firma Microsoft. Acesta se
bazează pe SQL și rulează în arhitectura client/server.

3.1.2 Baze de Date No SQL

Bazele de date NOSQL (Not o nly SQL) reprezintă o alternativa pentru bazele d e date
relaționale și au apărut din nevoia unor companii de a manipula cantități imense de date
cărora bazele de date tradiționale pur și simplu nu le pot face față. Așa că bazele de date
NoSQL au fost proiectate pentru a stoca volume foarte mari de date în gener al fără o schemă
fixă și partiționate pe multiple servere așa cum se poate observa din Figura 3.3 .

Figura 3.3 Baze de Date NoSql

Un exemplu de baze de date NoSQl este reprezentat de Couchbase Server.
Acesta este o bază de date NoSQL bazată pe documente pentru realizarea
aplicațiilor web interactive. Couchbase oferă avantajele clasice unei soluții NoSQL, cum ar fi
flexibilitatea modelului de date, ușurința , performanța și capacitatea de a oferi disponibilitate
100%.
3.2 ASP.NET
ASP.NET este o tehnologi e Microsoft care permite crearea aplicațiilor și a
serviciilor web beneficiind de puterea platformei de dezvoltare .NET și de setul de
instrumente oferite de mediul de dezvoltarea „ Visual Studio .NET ”.
Această tehnologie suporta trei modele diferite de dezvoltare web:
– ASP.NET Wep Pages

Capitolul 3
9 – ASP.NET MVC (Model -View -Controller)
– ASP.NET Web Forms

3.2.1 Visual Studio . NET

Visual Studio .Net este un mediu de dezvoltare (IDE) pentru crearea aplicațiilor web
în ASP .NET.
Acest mediu de dezvoltare oferă următoarele caracteristici:
– Design -ul paginilor :
o Conține un layout consistent cu template, teme și skins
– Editarea codului :
o Conține un editor de cod care permite scrierea codului pentru paginile
web dinamice în Visual Basic sau C#.
o Acesta include și colorarea sintaxei
– Testarea și Debugging -ul:
o Conține un server local pentru testare și un debugger care ajută la
găsirea erorilor în programe
– Deployment:
o Conține tool -uri care permit automatizarea task -urilor caracteristice
pentru deploy ing-ul unei aplicații web pe un server
În Figura 3.4 se poate vedea interfața mediului de dezvoltare Visual Studio.

Figura 3.4 Visual Studio .NET

Proiect de diplomă
10

3.2.2 ASP.NET MVC

ASP.NET MVC este un framework de dezvoltare web pe platforma Microsoft .NET,
care oferă o modalitate de a dezvolta aplicații web bine structurate.
MVC vine de la Model -View -Controller și este un model architectural foarte popular
în ingineria software.
În Figura 3.4 este prezentata structura modelului MVC.

Figura 3.4 Structura Modelului MVC
– Model -ul:
o reprezintă informația aplicației software. De exemplu, dacă se dezvoltă
un blog modelul poate fi alcătuit din post -uri și comentarii. Î n alt
context termenul de model se p oate referi la un view -model (acesta
specifică modul de reprezentare a informației în interfaț a)
o acesta manipulează operațiunile logice și de utilizare de informație
pentru a rezul ta o formă ușor de înțeles.
– View -ul:
o este rep rezentarea vizuala a modelulu i în diferite context e. De obicei
este r ăspunsul trimis (HTM L) browser -ului pentru a fi afiș at. În cazul
blogului u n exemplu ar fi pagina care afișează post-urile.
– Controller -ul:
o este coordonatorul care face legătura dintre view și model. El este
responsab il cu procesarea informațiilor, acțiunile asupra modelului și
tot el trebuie să decidă ce acțiune trebuie efectuata ș i ce view trebuie
afișat. Continuând exemplul blogului, controll erul trebuie să preia cele
mai recente commen t-uri pentru un post (modelul) și să le trimită view –
ului pentru afiș are.

Capitolul 3
11

3.2.2.1 ASP.NET MVC Dependency Injection

În programarea orientate pe obiecte (POO) , obiectele lucrează împreună în colaborare
cu modelul. În mod normal această colaborare generează dependențe între obiecte și
componente, managementul acestora devenind din ce în ce mai dificil pe măsură ce
complexitatea acestora crește. Acest lucru este evidențiat și în Figura 3.5.

O soluție pentru realizarea automată a acestor depende nțe este reprezentată de
“Dependency Injection ” (DI).
Aceasta se referă la injectarea automată a dependențelor și este realizată de obicei de o
component ă a framework -ului care trimite constructorului parametrii necesari și setează
proprietățile obiectelor.
Avantajele folosirii modelului de i njectarea a depende nțelor sunt următoarele :
– Reducerea cuplajelor dintre clase
– Creșterea codului reutilizabil
– Îmbunătățirea mentena nței codului
– Îmbunătățirea testării aplicației

3.2.2.2 Microsoft Unity

Microsoft Unity este o componentă care realizează i njectarea automată a
dependențelor și care poate fi ușor integrată într -o aplicație ASP .Net MVC .
Această componentă permite înregistrarea dependențelor logice într -un loc separat numit
container.
Microsoft Unity are un Framework care lucrează în spate și care rezolvă dependențele
apelând clasele și serviciile înregistrate.
. Figura 3.5 Dependența dintre obiecte

Proiect de diplomă
12
3.3 JavaScript

JavaScript nu are nici o legătură cu Java, deși este un limbaj care are sintaxa
asemănătoare cu cea a limbajelor Java, C#, C++, etc.
JavaScript este un limbaj în care nu trebuie specificat tipul variabilelor atunci când sunt
create. Codul JavaScript este rulat de către browser.
Browserele rețin î n memorie o reprezentare a paginilor web sub forma unui arbore de obiecte,
iar scripturile JavaScript au acces la aceste obie cte pentru a le putea citi și manipula . Acest
arbore poarta denumirea de “Document Object Model ” (DOM )
Utilizarea principal ă a JavaScript -ului este în scriptarea paginilor web . Programatorii
web pot îngloba în paginile HTML script -uri pentru diverse activități cum ar fi verificarea
datelor introduse de utilizatori sau crearea de meniuri și alte efecte animate.

3.3.1 Ajax
Ajax (Asynchronous JavaScript and XML ) este o tehnică de a crea pagini web rapide
și dinamice.
AJAX îi permite unei pagini să se updateze asincron prin schimbarea un ei cantități
mici de date cu un server. Aceasta înseamnă ca este posibil sa se updateze parți dintr -o pagină
web fără a reîncărca întreaga pagină.
Paginile web clasice , (care nu folosesc AJAX) trebuie sa reîncarce întreg daca au loc
modificări .
În Figura 3.6 este evidențiat modul în care funcționează AJAX -ul.

Figura 3.6 Apeluri AJAX

Capitolul 3
13

3.3.2 JQuery

JQuery este o librărie JavaScript, "scrie puțin , fa mult", rapidă și bogata în
caracteristici.
Scopul acesteia este acela de a face utilizarea JavaScript -ului mult mai ușoara în website.
JQuery ia o grămadă de funcții care necesită multe linii de cod JavaScript și le
comprimă în metode care pot fi apelate într -o singură linie de cod.
De asemenea, JQuery simplifică foarte mult lucrurile complicate din JavaScri pt, cum ar fi
apelurile AJAX și manipularea DOM -ului.
Librăria JQuery are următoarele caracteristici:
– Manipularea elementelor HTML și a DOM -ului
– Manipularea CSS
– Manipularea evenimentelor pentru elementele HTML
– Efecte și animații
– AJAX
– Utilități
3.4 HTML 5

HTML (HyperText Markup Language) este un limbaj bazat pe marcaje folosit pentr u
randarea conținutul paginilor web în browser . Marcajele ajută la realizarea unei sintaxe care
îi specifică browser -ului modul în care să afișeze pagina web.
HTML separă ”conținutul” (cuvinte , imagini , audio, video, etc) de "prezentare "
(instrucțiuni de afișare pen tru fiecare conținut ). Afișarea elementelor din pagină este dictată
de ”tag -uri”, astfel fiecare element are un tag de început de forma ”< >” și unul de sfârșit “<
/>”.
Fața de versiunile anterioare HTML5 aduce noi caracteristici sintactice . Aceste
noutăț i sunt proiectate pentru a facilita includerea și manipularea în web a conținuturilor
multimedia și grafice.
În Figura 3.7 este prezentată structura de bază a unui fișier HTML

Figura 3.7 Structura unui fișier HTML

Proiect de diplomă
14

3.5 CSS3

CSS ( Cascading Style Sheets ) definește m odul în care sunt afișate elemen tele HTML.
Stilurile pot fi atașate elementelor HTML prin folosirea unor fișiere externe sau în cadrul
aceluiași document, prin elementul <style> și/sau atributul style .
CSS are o sintaxă simpla și folosește un număr de cuvinte din limba engleză care
specific ă numele numeroaselor proprietăți .
Un fișier CSS este alcătuit dintr -un set de reguli. Fiecare regulă sau set de reguli este
alcătuită din unul sau mai mulți selectori și un bloc de declarație a proprietățilo r.
În CSS, selectorii sunt folosiți pentru a preciza căror elemente HTML să li se aplice stilurile
respective.

Acești selectori pot fi aplicați:
– Tuturor elementelor de un anumit tip (de exemplu paragrafelor <p> )
– Elementelor specificate după atribute, în particular:
o id: un identificator unic al documentului
o clasă : un identificator care grupează elemente multiple din document
Ultima variantă este CSS3. Aceasta este împărțită în module păstrând vechea
specificație CSS dar aducând și module noi.
În Figura 3 .8 este prezentat modul în care se definesc proprietăți CSS.

Figura 3.8 Definirea proprietăților CSS

Capitolul 3
15

3.6 Harți Google API

API (Application Programming Interface) este reprezintă un set de metode și tool-uri
folosite pentru realizarea aplicațiilor sof tware.
Hărțile Google sunt un serviciu dezvoltat de Google care oferă harți și poate fi accesat atât
de pe deskt op cât și de pe telefonul mobil . Acesta oferă vederi din satelit, imaginile străzilor ,
vederi panoramice precum și informații despre trafic . Hărțile Google oferă și un API care
permite harților să fie incluse în alte aplicații web.
API-ul pentru Hârțile Google este gratis atât tim p cat site -ul care îl folosește este public și nu
generează mai mult de 25 000 de cereri pentru harți într -o zi. Site -urile care nu îndeplinesc
aceste cerințe pot cumpara serviciul de Harți Google, varianta business.
Aceste imagini nu sunt updatate în tim p real , dar totuși nu sunt mai vechi de trei ani.
În Figura 3.7 este reprezentata o hartă din Cluj.

3.7 Apache Solr

Solr este o platformă open source scrisă î n Java, de la Apache Lucen e.
Caracteristicile principale includ căutarea textului, indexarea în timp real, integrarea bazelor
de date, manipulare documentelor și a bazelor de date NoSQL
Asigurând căutarea distribuită și replicare indecșilor , Solr este foarte scalabil și tolerant l a
erori . Solr este cel mai popular motor de căutare .
Solr rulează ca un server de căutare a textului de sine stătător . Acesta folosește librăria
de căutare Lucene Java pentru indexarea și căutarea textelor și pune la dispoziție un API care Figura 3.7 Hartă Google din Cluj

Proiect de diplomă
16
îl face să fie folosit de către cele mai populare limbaje de programare. Configurarea acestui
server permite să fie folosit de mai multe tipuri de aplicații fără cod Java și are un plugin care
poate fi cu stomizat.
Solr are și o interfața grafica pentru administrator de unde se poate realiza indexarea și
se pot modifica configurările fără a scrie cod efectiv. De asemenea se poate urmării activitatea
și se pot crea nuclee noi.
În Figura 3.8 este reprezentat un print -screen al acestei interfețe .

Figura 3.8 Interfața Solr

Capitolul 4
17
Capitolul 4 ANALIZĂ ȘI FUNDAMENTARE
TEORETICĂ

4.1 Interacțiune Utilizator -Aplicație

Pentru utilizarea aplicației avem nevoie de trei componente importante:
1. utilizatorul
2. dispozitivul mobil sau desktop -ul care trebuie să suporte aplicația
3. accesul la internet (fără acesta aplica ția nu ar putea funcționa )
Prin utilizarea serviciilor de furnizarea a internetului, aplicația va putea comunica cu serviciile
de stocarea a informație i, dar și cele furnizate de Google (Harți Google).
Funcționalitatea aplicației și legătura dintre componentele menționate mai sus este
evidențiată în Figura 4.1.

Figura 4.1 Diagrama Aplicației

Proiect de diplomă
18

4.2 Stocarea și Prelucrarea Informațiilor
4.2.1 Stocare Datelor

O componentă esențiala pentru orice aplicație software este reprezentată de baza de
date care trebuie sa poată fi accesata în orice moment și care trebuie să stocheze informațiile
pentru o gestiune și prelucrare ușoara a acestora.
Acea stă aplicație folosește o bază de date relaționala și una NoSQL.
4.2.1.1 Baza de Date Relațională

Această bază de date conține informații esențiale atât despre utilizatori cât și despre
cărțile și bibliotecile folosite.
Aici se întâlnesc mai multe tipuri de tabele .

1. Tabele care conțin informații despre utilizator

o Tabela Users
 Aceasta conține informații introduse de utilizator în momentul în care
acesta își face cont în aplicație (email, password, etc)
 Datele din această tabelă sunt necesare pentru a acce sa anumite pagini
din aplicație deoarece utilizatorul trebuie să se logheze

o Tabela Roles
 Această tabelă conține informații referitoare la rolul utilizatorului în
aplicație
 Utilizatorul poate avea rolul de ”SuperAdmin”, ”Admin” sau ”User”

o Tabela AuthorPre ference
 Aceasta conține preferințele utilizatorului în materie de autori
 Preferințele se setează accesând pagina ”My Account” din meniu și
este accesibilă tuturor utilizatorilor logați
 În funcție de aceste preferințe pe pagina ”My Books” o să apară o listă
de cărți noi apărute scrise de autorul respectiv și care fac parte din
categoriile setate ca fiind preferate

o Tabela CategoryPreference
 Tabela aceasta se aseamănă cu cea precedentă, diferența fiind ca aici se
stochează referințele utilizatorulu i în funcți e de categoriile că rților
 Aceste categorii apar și pe pagina principală unde se poate face o
filtrare a cărților după ele, iar adăugarea lor la preferințe se face din
pagina ”My Account”
 La fel ca și în cazul a utorilor preferați, pe pagina ”My Books” list a de
cărți ”recomandată” pentru utilizator este influențată de aceste
preferințe
o Tabela History

Capitolul 4
19  Această tabela reține informații despre istoricul utilizatorului în
aplicație, mai exact informații referitoare la cărțile citite sau la cele pe
care acesta le -a adăugat la lista celor pe care ar vrea să le citească
 Acest e informații pot fi vizualizate pe pagina ” History” iar adă ugarea
și editarea lor se face din aceeași pagina sau de pe pagina principală
unde utilizatorul poate sa adauge o carte la lista favori tă sau la lista
cărților citite
 Tot în această pagină o sa fie afiș ată o hartă cu bibliotecile de la care a
împrumutat cărți utilizatorul

2. Tabele care conțin informații despre biblioteci

o Tabela Library
 În această tabelă se stochează informații referitoar e la bibliotecile
adăugate în aplicație
 Adăugare bibliotecilor noi sau editarea celor existente se face din
pagina ”Library” care este accesibilă doar SuperAdmin -ului
 Informațiile stocate sunt referitoare la adminu -ul fiecărei biblioteci și la
adresa acest eia
 În funcție de adresa bibliotecilor, în pagina principală fiecare carte va
avea atașată o hartă unde o sa se poată localiza biblioteca unde poate fi
găsită

o Tabela Address
 Aici sunt memorate toate informațiile referitoare la adresele
bibliotecilor sau a utilizatorilor
 Aceste informații pot fi editate sau adăugate fie din pagina ”Libraries”
în cazul bibliotecilor, fie din pagina de înregistrare sau ”My Account”
în cazul utilizatorilor

3. Tabele care conțin informații despre cărți

o Tabela Book
 Această tabel ă stochează informațiile referitoare la cărți
 Datele respective sunt adăugate în pagina ”Add Book” de către
administratorii fiecărei biblioteci și sunt afișate pe pagina principală și
pe pagina ”My Books”

o Tabela Author
 Aici sunt stocate date despre autori
 Acestea su nt adăugate în momentul în care se adaugă o carte nouă în
cazul în care au torul respectiv nu există deja î n baza de date
 Pe pagina principală cărțile pot fi filtrate după autori

o Tabela Category
 În aceasta tabela se stochează categoriile de cărț i
 Ca și în cazul autorilor, pe pagina prin cipala cărțile pot fi filtrate î n
funcție de categorii

Proiect de diplomă
20
 Categoriile noi sunt adăugate în momentul în care se adaugă o carte
nou care face parte dintr -o categorie ce nu există în baza de date

o Tabela Publisher
 Aici s unt stocate date despre editura cărților
 Sunt adăugate atunci când se adaugă o carte nouă de la o editură care
nu există în baza de date

o Tabela Feelings
 Această tabela con ține stările emoționale în funcț ie de care pe pagina
”My Books” utilizatorul primeșt e recomandări cu cărțile care se
potrivesc stării respective
 Fiecărei stări din aceasta tabelă îi corespunde un document JSON stocat
în CouchBase care ajută la determinarea cărților potrivite

Sistemul de gestiune al bazelor de date folosit este SQL Server , iar î n Figura 4.2 este
prezentată diagrama bazei de date SQL.

Figura 4.2 Diagrama Bazei de Date

Capitolul 4
21
4.2.1.2 Baza de NoSQL

Pentru determinarea cărților care se potrivesc unei anumite stări emoționale, care
apare pe pagina ”My Books” atunci când utilizat orul este logat, am folosit o baza de date
NoSQL, deoarece aceasta permite stocarea fișierelor astfel, pentru fiecare stare am stocat un
fișier în format JSON.
Baza de date folosita este CouchBase, care are o interfața ușor de folosit. Aici mi -am
definit un nou bucket (o nouă colecție de documente) numit ”Books” și am adăugat
documentele respective.
Aceste documente JSON conțin o serie de cuvinte cheie asociate unei anumite stări,
iar fiecare carte are definite unul sau mai multe cuvinte cheie.
Dacă aș fi optat pentru o bază de date relaționala ar fi trebuit sa am mai multe tabele cu relația
1 la 1 pentru a realiza toate combinațiile ”stare emoțională – caracteristica a unei cărți”

În Figura 4.3 este un print -screen al interfeței CouchBase.

Figura 4. 3 Interfața CouchBase

Proiect de diplomă
22

4.2.2 Prelucrarea Datelor

Pentru prelucrarea datelor am folosit Enity Framework 5. Acesta este un framework
Object/ Relational Mapping (ORM) care permite dezvoltatorilor web sa acceseze datele din
bazele de date relaționale .
Acesta generează entități și obiecte pe baza tabelelo r din baza de date și returnează aceste date
sub forma de obiecte sau colecții de obiecte ce pot fi manipulate în aplicație . Această operație
se numește mapare.
Acest framework pune la dispoziț ie mecanisme pentru efectuarea operațiilor CRUD
(CREATE, READ, UPDATE, DELETE) asupra obiectelor , iar interogările la baza de date se
pot scrie foarte ușor folosind LINQ.
În Figura 4.4 este evidențiat modul în care tabelele sunt transformate în obiecte și
invers folosi nd Entity Framework.

Figura 4.4 Entity Framework

Capitolul 4
23

4.3 Solr Search

Pentru funcționalitatea de search din pagina principala ”Home” am folosit un motor de
căutare și anume Solr deoarece avem de -a face cu o baza de date destul de mare .
Motorul de că utare Solr este folosit pentru căutarea rapida a cărților după nume, dar ține cont
și de celelalte care pot fi setate și anume au tori, categorii , glosar și pagin are.
Motivul pentru care această platforma efectuează căutarea rapid se datorează faptului
că Solr nu căuta textul direct ci un index al acestuia. Este ca și cum în loc să cauți intr -o carte
un cuvânt în fiecare pagină , îl cauți doar în cuprins.
Solr stochează acești indecși într-un director numit index din directorul data.
Un index este alcătuit din unul sau mai multe documente, iar un document este alcătuit
din unul sau mai multe câmpuri . Făcând corespondenț a cu o baza de date relaționala, unui
document îi corespunde un rând dintr -un tabel, iar unui câmp îi corespunde o coloana dintr -un
tabel.
Adăugarea documentelor în Solr se numește indexare. Aceasta poate fi de doua tipuri:
1. Indexare totala:
– toate datele dintr -un anumit tabel sunt adăugate în Solr pentru indexare

2. Indexare parțiala:
– Sunt indexate doar datele introduse sau updatate de la ultima indexare, acest
lucru este specificat în query -ul pentru indexarea parțială

După ce datele au fost indexate, se pot face interogări pentru acestea folosind HTTP
GET și primind drept răspuns un document JSON, XML, CSV au binar.
În Figura 4.5 este exemp lificat modul în care interacționează aplicația cu serverul Solr.

Figura 4.5 Diagrama de interacțiun e aplicație – server Solr

Proiect de diplomă
24

4.4 Servicii Google utilizate în aplicație

Aplicația foloseș te serviciul Google Maps pentru a ajuta utilizatorul să găse ască
biblioteca cea mai apropiată de locația lui, spec ificată î n momentul înregistrării în aplicație.
În baza de date este stocată atât locația utilizatorului câ t și a bibliotecilo r, iar fiecare carte are
atașată o hartă care îl ajută pe utilizator să aleagă biblioteca cea mai apropiată de el.
Principala funcționalitate pe care am folosit -o în aceasta aplicație este aceea de afișare
a unei harți cu datele oferite de serviciul Google Maps, dar pe baza aceste harți se pot efectua
mai multe operații precum afișarea poziției utilizatorului, a bibliotecilor.
Pe lăngă acestea există și posibilitatea schimbării modulu i de vizualizare a datelor (Earth,
Satelite sau Street View) .
Pentru a folosi acest serviciu în aplicație am folosit JQuery și este necesară conex iunea
la serviciile oferire de Google așa cum se poate observa din Figura 4.6 .

Figura 4.6 Comunicație între aplicație și serviciile Google

4.5 Tipuri de utilizatori și cazuri de utilizare

4.5.1 Tipuri de utilizatori

Pentru această aplicație este n ecesară definirea mai multor tipuri de utilizatori
deoarece trebuie să existe o persoană care să administreze bibliotecile (acesta o să aibă rol de
”SuperAdmin”), o persoana responsabila cu managementul cărților pentru fiecare biblioteca
(aceasta o sa aibă rol de ”Admin”) și utilizatorii normali (aceștia au rol de ” User ”).
De asemenea, aplicația poate fi utilizată și de persoane care nu se înregistrează , dar acestea o
să aibă acces limitat.

Capitolul 4
25 O să existe un singur utilator de tipul ”SuperAdmin” definit în baz a de date de la
început, mai mulți utilizatori de tip ”Admin” adăugați de ”SuperAdmin ” și mai mulți
utilizatori de tip ”User” care s -au înregistrat în aplicație.

4.5.2 Cazuri de utilizare

Am definit aceste cazuri de utilizare pentru a descrie fluxul de lucru al operațiilor pe
care utilizatorul aplicației va trebui să îl îndeplinească pentru a ajunge la rezultatul dorit.
Astfel mai jos sunt explicate toate cazurile de utilizare pentru fiecare tip de utilizator pornind
de la utilizatorul cu rolul cel mai p uțin complex , adică utilizatorul nelogat la cel cu rolul cel
mai complex (”SuperAdmin”).

Cazul 1
Nume caz de utilizare :
Înregistrarea utilizatorului

Actor principal:
Toate categoriile de utilizatori

Părțile implicate și obiectivele lor:
1. Utilizator ul care nu este înregistrat în sistem
2. Aceasta dorește să își creeze un cont

Precondiții:
Disponibilitatea sistemului la cererea de înregistrare

Postcondiții:
Înregistrarea să fie efectuată cu succes

Scenariu de succes:
1. Persoana accesează website -ul.
2. Apasă butonul de înregistrare.
3. Persoana completează câ mpurile din formular .
4. Apasă butonul de înregistrare .
5. Utilizatorul este înregistrat cu succes , este logat și redirectat la
pagina principală .
Extensii:
a. Utilizatorul introduce date greșite :
– Aplicația avertizează utilizatorul despre datele introduse
greșit
b. Utilizatorul renunță la înregistrare:
– Aplicația anulează stadiul înregistrării , formularul este
închis iar utilizatorul rămâ ne pe pagina principală .

Cazul 2
Nume caz de utilizare :
Logarea uti lizatorului

Actor principal:
Utilizatorii care au deja un cont

Proiect de diplomă
26

Părțile implicate și obiectivele lor:
Utilizatorul care dorește să se logheze
Precondiții:
Disponibilitatea sistemului la cererea de autentificare

Postcondiții:
Autentificare să fie efec tuată cu succes

Scenariu de succes:
1. Persoana accesează website -ul.
2. Apasă butonul de Log In.
3. Introduce emailul și parola.
4. Apasă butonul de Log In.
5. Utilizatorul se loghează cu succes și este redirectat la pagina
principală
Extensii:
a. Utilizatorul introduce date greșite:
– Aplicația avertizează utilizatorul despre datele introduse
greșit
b. Utilizatorul renunță la autentificare :
– Sistemul anulează cererea de autentificare, iar formularul
este închis și utilizatorul rămâne pe pagina principală.

Cazul 3
Nume caz de utilizare :
Vizualizarea, căutarea și filtrarea cărților

Actor principal:
Toate categoriile de utilizatori

Părțile implicate și obiectivele lor:
3. Utilizatorul care dorește să vizualizeze/caute/filtrez e cărțile
disponibile
Precondiții:
Disponibilitatea sistemului la acțiunea de vizualizare și search

Postcondiții:
Datele sa fie returnate cu succes

Scenariu de succes:
1. Persoana accesează website -ul.
2. Folosește funcționalitatea de search .
3. Folosește pagi narea .
4. Aplică anumite filtre.

Capitolul 4
27
Cazul 4
Nume caz de utilizare :
Editarea profilului utilizatorului

Actor principal:
Utilizatorii care au cont

Părțile implicate și obiectivele lor:
1. Utilizatorul care este autentificat în website
2. Aceasta dorește să își editeze informațiile personale

Precondiții:
Disponibilitatea sistemului la cererea de editare

Postcondiții:
Editarea să fie efectuată cu succes

Scenariu de succes:
1. Persoana accesează website -ul.
2. Se loghează în aplicație .
3. Accesează pagina ”My Account”
4. Editează câ mpurile din formular.
5. Apasă butonul de salvare .
6. Modificările sunt salvate cu succes.
Extensii:
a. Utilizatorul introduce date greșite:
– Aplicația avertizează utilizatorul despre datele introduse
greșit
b. Utilizatorul renunță la editare :
– Sistemul anulează stadiul editării , utilizatorul este redirectat
la pagina principală

Cazul 5
Nume caz de utilizare :
Adăugarea /editarea unei biblioteci

Actor principal:
Utilizator ul de tip ”SuperAdmin”

Părțile implicate și obiectivele lor:
1. Utiliza torul de tip ”SuperAdmin” autentificat în website
2. Aceasta dorește să adauge sau să editeze o bibliotecă

Precondiții:
Disponibilitatea sistemului la cererea de adăugare / editare

Postcondiții:
Adăugarea / editarea să fie efectuată cu succes

Proiect de diplomă
28
Scenariu de succes:
1. Persoana accesează website -ul.
2. Se loghează în aplicație.
3. Accesează pagina ” Library ”
4. Apasă butonul de Add sau Edit
5. Completează/ e ditează câmpurile din formular.
6. Apasă butonul de salvare.
7. Modificările sunt salvate cu succes.
Extensii:
a. Utilizato rul introduce date greșite:
– Aplicația avertizează utilizatorul despre datele introduse
greșit
b. Utilizatorul renunță la editare:
– Sistemul anulează stadiul adăugării /editării , utilizatorul este
redirectat la pagina ”Library”.

Cazul 6
Nume caz de utilizar e :
Adăugarea /editarea unei cărți

Actor principal:
Utilizatorul de tip ” Admin ”

Părțile implicate și obiectivele lor:
a. Utilizatorul de tip ” Admin ” autentificat în website
b. Aceasta dorește să adauge sau să editeze o carte

Precondiții:
Disponibilitatea sistemului la cererea de adăugare / editare

Postcondiții:
Adăugarea / editarea să fie efectuată cu succes

Scenariu de succes:
1. Persoana accesează website -ul.
2. Se loghează în aplicație.
3. Accesează pagina ” Admin ”
4. Apasă butonul de Add sau Edit
5. Completează/ edi tează câmpurile din formular.
6. Apasă butonul de salvare.
7. Modificările sunt salvate cu succes.
Extensii:
a. Utilizatorul introduce date greșite:
– Aplicația avertizează utilizatorul despre datele introduse
greșit
b. Utilizatorul renunță la editare:
– Sistem ul anulează stadiul adăugării /editării , utilizatorul este
redirectat la pagina ” Admin ”.

Capitolul 4
29
Cazul 7
Nume caz de utilizare :
Adăugarea /editarea unei cărți la favorite sau history

Actor principal:
Utilizator ii care au un cont

Părțile implicate și obiec tivele lor:
a. Utilizatorul autentificat în website
b. Aceasta dorește să își adauge sau să își editeze lista cărților
favorite și istoricul

Precondiții:
Disponibilitatea sistemului la cererea de adăugare / editare

Postcondiții:
Adăugarea / editarea să fie efe ctuată cu succes

Scenariu de succes:
1. Persoana accesează website -ul.
2. Se loghează în aplicație.
3. Accesează pagina ” History ”
4. Apasă butonul de Add sau Edit
5. Completează/ editează câmpurile din formular.
6. Apasă butonul de salvare.
7. Modificările sunt salvate cu suc ces.
Extensii:
a. Utilizatorul introduce date greșite:
– Aplicația avertizează utilizatorul despre datele introduse
greșit
b. Utilizatorul renunță la editare:
– Sistemul anulează stadiul adăugării /editării , utilizatorul
rămâne pe pagina ”History”.

Cazul 8
Nume caz de utilizare :
Adăugarea /editarea unei preferințe

Actor principal:
Utilizatorii care au cont

Părțile implicate și obiectivele lor:
a. Utilizatorul autentificat în website
b. Aceasta dorește să adauge sau să editeze o preferință în materie de
autori sau categoriile cărților

Precondiții:
Disponibilitatea sistemului la cererea de adăugare / editare

Proiect de diplomă
30
Postcondiții:
Adăugarea / editarea să fie efectuată cu succes

Scenariu de succes:
1. Persoana accesează website -ul.
2. Se loghează în aplicație.
3. Apasă b utonul ”Preferences”
4. Completează/ editează câmpurile din formular.
5. Apasă butonul de salvare.
6. Modificările sunt salvate cu succes.
Extensii:
a. Utilizatorul introduce date greșite:
– Aplicația avertizează utilizatorul despre datele introduse
greșit
b. Ut ilizatorul renunță la editare:
– Sistemul anulează stadiul adăugării /editării , utilizatorul este
redirectat la pagina principală .

Cazul 9
Nume caz de utilizare :
Vizualizarea detaliilor unei cărți

Actor principal:
Toate tipurile de utilizatori

Părțil e implicate și obiectivele lor:
a. Utilizatorul care dorește să vizualizeze detaliile unei cărți

Precondiții:
Disponibilitatea sistemului la cererea de vizualizare

Postcondiții:
Vizualizarea să fie efectuată cu succes

Scenariu de succes:
1. Persoana accesea ză website -ul.
2. Selectează o carte
3. Detaliile despre cartea respe ctivă sunt afișate î ntr-un fancy box.
Extensii:
a. Nu există detalii:
– Aplicația avertizează utilizatorul despre faptul că nu există
detalii

Cazul 10
Nume caz de utilizare :
Selectarea cărților în funcție de starea emoțională

Actor principal:

Capitolul 4
31 Toți utilizatorii care au cont

Părțile implicate și obiectivele lor:
a. Utilizatorul care dorește să vizualizeze cărți asociate unei stări
emoționale

Precondiții:
Disponibilitatea sistemului la c ererea de vizualizare

Postcondiții:
Trimiterea și vizualizare datelor să fie efectuată cu succes

Scenariu de succes:
1. Persoana accesează website -ul.
2. Se autentifica
3. Accesează pagina ”My Books” din meniu
4. Selectează o stare
5. Apare o listă cu cărțile potrivit e pentru starea respectivă.
Extensii:
a. Nu există cărți asociate stării respective:
– Aplicația avertizează utilizatorul despre faptul că nu există
cărți asociate cu starea aleasă

Cazul 11
Nume caz de utilizare :
Vizualizarea cărților în funcție de preferințele setate

Actor principal:
Toți utilizatorii care au cont

Părțile implicate și obiectivele lor:
a. Utilizatorul care dorește să vizualizeze cărți recomandate pentru
preferințele lui

Precondiții:
Disponibilitatea sistemului la cererea de vizuali zare

Postcondiții:
Trimiterea și vizualizare datelor să fie efectuată cu succes

Scenariu de succes:
1. Persoana accesează website -ul.
2. Se autentifica
3. Accesează pagina ”My Books” din meniu
4. Apare o listă cu cărțile potrivite pentru preferințele lui
Extensii:
a. Nu există preferințe setate:
– Aplicația avertizează utilizatorul despre faptul că nu există
preferințe setate

Proiect de diplomă
32

4.6 Afișare cărți după preferințe sau starea de spirit
4.6.1 Afișare cărți după preferințe

Aceast ă aplicație oferă o funcționalitate cu aj utorul că reia uti lizatorul va fi informat
dacă au ap ărut cârti care îl interesează .
Pentru determinarea acestor cârti, există o pagină unde utilizatorul conectat poate să își
adauge preferințe în materie de autori și categorii. Astfel în funcție de aceste preferințe, î n
pagina ”My Books” o să îi apară o listă cu cărțile pe care ar trebui să le citească.
4.6.2 Afișare cărți după starea de spirit

Altă funcționalitate interesantă a acestei aplicații este reprezentată de faptul că un
utilizator poate să își aleagă starea de spirit și în funcție de aceasta o să primească o ser ie de
cărți pe care ar trebui să le citească .
În vederea realizării acestei funcționalități s-a folosit o lista de cuvinte che ie setate
pentru fiecare carte î n parte și o listă de cuvinte cheie asociat e unei stă ri anume.
Legătura dintre acestea se face folosind o baza de date NoSql și anume CouchBase

Capitolul 5
33

Capitolul 5 PROIECTARE DE DETALIU ȘI
IMPLEMENTARE

5.1 Detalii de Implementare

5.1.1 Procesul de înregistrar e în aplicație

Pentru procesul de înregistrare în aplicație trebuie efectuați anumiți pași . Aceștia sunt
descriși î n diagrama din Figura 5.1 .

Figura 5.1 Diagrama process de înregistrare
Această aplicație este realizată î n ASP .Net MVC, iar pentru pro cesul de înregistrare
am folosit următoarele clase și view -uri:

Pentru Model :

– În acest caz modelul este reprezentat de clasa UserModel
– Conține următoarele proprietăți :
o email, nume, prenume, parolă, confirmare parolă, data nașterii, adresă,
telefon, ge n, precum și o proprietate pentru mesajele de eroare pentru
cazul în care există deja un utilizator cu aceeași adresă de email sau a
intervenit o eroare de server.

Proiect de diplomă
34
Pentru Controller :

– În acest caz controllerul folosit este AccountController
– Acesta conține o metodă ”Register” de tip HttpGet care returnează formularul de
înregistrare și una HttpPost care se ocupă cu înregistrare a efectivă
– În cazul în care datele au fost introduse corect, acestea o să apeleze clasa UserBus
care o sa convertească modelul de pe view la un modelul User din DAL (Data
Acces s Layer) care o să salvează modificările în baza de date folosind Entity
Framework , iar după ce înregistrarea este salvată, utilizatorul este logat automat în
aplicație , în caz contrar se afișează mesajele de er oare corespunzătoare
– La înregistrare fiecare utilizator primește rolul ”User”

Pentru View :

– View -ul folosit este un PartialView ”Register” și este afișat într -o fancy box
– Acest view conține formularul de înregistrare care este un formular AJAX, iar
validarea datelor se face prin JavaScript în funcția ”OnBegin” specifică form -ului

5.1.2 Procesul de autentificare în aplicație

Pentru procesul de înregistrare în aplicație trebuie efectuați anumiți pași. Aceștia sunt
descriși în diagrama din Figura 5. 2.

Figura 5.2 Diagramă proces de autentificare
Pentru procesul de autentificare am folosit urmă toarele clase și view -uri:

Pentru Model :

Capitolul 5
35

– În acest caz modelul este reprezentat de clasa LoginModel
– Conține următoarele proprietăți :
o email, parolă, precum și o proprietate pentru mesajele de eroare pentru
cazul în care parola nu corespunde adresei de email respective, email -ul
nu există în baza de date sau a intervenit o eroare de server.

Pentru Controller :

– Controllerul folosit este AccountController
– Acesta conține o metodă ”Login” de tip HttpGet care returnează formularul de
autentificare și una HttpPost care se ocupă cu logarea efectivă
– În cazul în care datele au fost introduse corect, acestea o să apeleze o metodă din
clasa UserBus care apelează DAL (Data Ac cess Layer) pentru a vedea dacă în
baza de date există user -ul cu email -ul și parola respectivă. În cazul în care acesta
există, utilizatorul este logat automat în aplicație prin setarea informațiilor în
sesiune, în caz contrar se afișează mesajele de eroa re corespunzătoare
– Informațiile setate în sesiune sunt: Id, Email și Rolul utilizatorului (acesta din
urmă este folosit pentru a vedea ce pagini trebuie să îi apară

Pentru View :

– View -ul folosit este un PartialView ”Login” și este afișat într -o fancy box
– Acest view conține formularul de autentificare , acesta este un formular AJAX, iar
validarea datelor se face prin JavaScript în funcția ”OnBegin” specifică form -ului

5.1.3 Procesul de adăugare/ edi tare biblioteci

Pentru procesul de adăugare/ editare a unei biblioteci trebuie efectuați anumiți pași.
Aceștia sunt descriși în diagrama din Figura 5.3.

Pentru procesul de adăugare/editare bibliotecă am folosit următoarele clase și view –
uri:
Figura 5.3 Diagramă proces de adăugare/editare a unei biblioteci

Proiect de diplomă
36
Pentru Model :

– În acest caz modelul este reprezentat de clasa Libra yModel
– Conține următoarele proprietăți :
o nume, adresă, administrator, precum și o proprietate pentru mesajele de
eroare pentru cazul în care a intervenit o eroare de server.
– Administr atorul este ales din lista de useri din baza de date
– Pentru validarea d atelor de pe model se folosește Data Annotation cu ajutorul
căreia am specificat validare pentru fiecare câmp (în acest caz toate câmpurile
formularului sunt obligatorii și nu au nevoie de o validare custom)

Pentru Controller :

– Controllerul folosit este L ibrary Controller
– Acesta conține o metodă ” Library ” de tip HttpGet care returnează formularul de
adăugare/ editare a unei biblioteci și una HttpPost care se ocupă cu prelucrarea
datelor
– În cazul în care datele au fost introduse corect, acestea o să apeleze o metodă din
clasa LibraryBus care apelează DAL (Data Access Layer) pentru a salva
modificările dorite în baza de date, iar utilizatorul este redirectat la pagina
”Library” unde poate vedea lista cu toata bibliotecile existente, în caz contrar se
afișează m esajele de eroare corespunzătoare
– În momentul în care un utilizator este ales administrator pentru o bibliotecă rolul
acestuia se schimba în cel de ”Admin”
– Pentru adăugarea țarii din care face parte biblioteca am folosit o listă de țari
populata cu date di n baza de date , am făcut acest lucru pentru a evita salvare
informațiilor redundante și a împiedica adăugare unei țări care nu există
– Aceste modificări pot fi făcute doar de ”SuperAdmin”

Pentru View :

– Se folosește un view în care sunt afișate toate biblio tecile sub forma de tabel
– Acest view folosește layout -ul principal
– În momentul selectării butonului de edit sau adăugare a unei biblioteci,
utilizatorul este redirectat la o altă pagină care conține formularul de
adăugare/editare
– Această pagina folosește J query pentru a popula o lista cu autocomplete cu
utilizatorii salvați în baza de date, dar și o listă cu toate țările folosită pentru
adresă bibliotecii
– Pentru câmpul ”Cod Poștal” se folosește o funcție care împiedică utilizatorul să
introducă alte caracte re în afară de cifre
– și acest formular este tot de tipul AJAX, dar validarea datelor nu se face Client –
Side folosind JavaScript, ci Server -Side în controller folosind proprietatea ”IsValid” a
modelului trimis .

Capitolul 5
37

5.1.4 Procesul de adăugare/ edi tare carte

Pentru procesul de adăugare/ editare a unei cărții trebuie efectuați anumiți pași.
Aceștia sunt descriși în diagrama din Figura 5.4.
Se folosesc următoarele clase și view -uri:

Pentru Model :

– În acest caz modelul este reprezentat de clasa BookModel
– Conțin e următoarele proprietăți :
o Titlu, bibliotecă, autor, editură, cod ISBN, c ategorie, imagine copertă,
fișier preview, anul apariției, cuvinte cheie, descriere , precum și o
proprietate pentru mesajele de eroare pentru cazul în care a intervenit o
eroare de server sau fișierele nu corespund tipului precizat .
– Pentru validarea datelor de pe model se folosește Data Annotation cu ajutorul
căreia am specificat validare pentru fiecare câmp (în acest caz toate câmpurile
formularului sunt obligatorii și nu au nevoie de o validare custom)
– Pe lângă aceste validări , cele două fișiere uploadate mai au o validare pentru
extensia lor

Pentru Controller :

– Controllerul folosit este Book Controller
– Acesta conține o metodă ”Books” de tip HttpGet care returnează pagină ce conț ine
lista cu toate cărțile de la o anumita bibliotecă , o altă metodă de Tip HttpGet care
Figura 5.4 Diagramă process de adaugare/ editare a unei cărți

Proiect de diplomă
38

returnează formularul de adăugare/editare al unei cărți și una HttpPost care se
ocupă cu prelucrarea datelor
– În cazul în care datele au fost introduse corect, acestea o să apeleze o metodă din
clasa Book Bus care apelează DAL (Data Access Layer) pentru a salva modificările
dorite în baza de date, iar utilizatorul este redirectat la pagina ” Books ” unde poate
vedea lista cu toata cărțile existente, în caz contrar se afișea ză mesajele de eroare
corespunzătoare
– Pentru adăugarea autorului cărții respective am folosit o listă de autori populată cu
date din baza de date, iar în cazul î n care autorul nu exista acesta se salvează în
baza de date
– Același lucru este făcut și pentru categoria din care face parte cartea și editura
acesteia
– Am făcut acest lucru pentru a evita salvare informațiilor redundante
– Tot aici are loc salvarea unor fișiere pe disc (coperta cărții, imaginea thumbnail și
preview -ul cărții)
– Aceste modificări pot fi făcute doar de utilizatorii de tip ”Admin ”

Pentru View :

– Se folosește un view în care sunt afișate toate cărțile sub forma de tabel
– În momentul selectării butonului de edit sau adăugare a unei cărți, utilizatorul este
redirectat la o altă pagină care conț ine formularul de adăugare/editare
– Această pagina folosește Jquery pentru a popula o lista cu autocomplete cu
autorii, categoriile și editurile salva te în baza de date
– Pentru câmpul ” An apariție ” se folosește o funcție care împiedică utilizatorul să
introd ucă alte caractere în afară de cifre
– Acest formular este de tipul HTML , deoarece trebuie să suporte încărcare a de
fișiere
5.1.5 Procesul de editare a profilului unui utilator

Pentru acest proces trebuie efectuați pașii descriși în diagrama din Figura 5. 5.
Figura 5.5 Diagramă process editarea profilului

Capitolul 5
39
Pentru procesul de editare a profilului am folosit următoarele clase și view -uri:

Pentru Model :

– În acest caz modelul este reprezentat de clasa UserModel
– Conține următoarele proprietăți :
o email, nume, prenume, parolă, data nașterii, adresă, telefon, gen, precum
și o proprietate pentru mesajele de eroare pentru cazul în care există deja
un utilizator cu aceeași adresă de email sau a intervenit o eroare de
server.
– Pentru validarea datelor de pe model se folosește Data Annotation cu ajutorul
căreia am s pecificat validare pentru fiecare câmp (în acest caz toate câmpurile
formularului sunt obligatorii și nu au nevoie de o validare custom)

Pentru Controller :

– Controllerul folosit este AccountController
– Acesta conține o metodă ”EditProfile” de tip HttpGet c are returnează formularul
de editare al pofilului și una HttpPost care se ocupă cu prelucrarea datelor
– În cazul în care datele au fost introduse corect, acestea o să apeleze o metodă din
clasaUserBus care apelează DAL (Data Access Layer) pentru a salva mod ificările
dorite în baza de date, iar utilizatorul este redirectat la pagina principală, în caz
contrar se afișează mesajele de eroare corespunzătoare

Pentru View :

– Se folosește un view în care sunt afișate toate i nformațiile despre utilizatorul
conectat
– Acest view folosește layout -ul principal
– Această pagina folosește Jquery pentru a popula o lista drop -down pentru anii,
una pentru lunile anului și una pentru zile: la eventul de ”OnChange” aceste liste
se updatează astfel încât sa nu conțină date eronate cum ar fi luna Februarie să
aibă 28 de zile în anii bisecți
– Lista țărilor este de asemenea populată folosind JQuery în momentul încărcării
pagini
– Pentru câmpul ”Cod Poștal” și ”Telefon” se folosește o funcție care împiedică
utilizatorul să introducă alt e caractere în afară de cifre
– Acest formular este de tipul AJAX, iar validarea datelor se face Client -Side
folosind JavaScript în funcția ”OnBegin”
– Pentru câmpurile acestui formular validarea nu constă doar în verificarea ca
acestea sa fie completate, ci s e verifica și formatul adresei de email, al telefonului
și a parolei(aceasta trebuie să aibă între 6 -8 caractere și sa conțină și cifre)

Proiect de diplomă
40

5.1.6 Procesul de adăugare/ edi tare preferință

Pentru procesul de adăugare/ editare a unei preferințe trebuie efectuați anumiți pași.
Aceștia sunt descriși în diagrama din Figura 5.6.

Figura 5.6 Diagrama process adăugare/ editare preferințe

Pentru procesul de adăugare/ editare preferințe am folosit următoarele clase și view -uri:

Pentru Model :

– În acest caz modelul este reprezentat de clasa PreferenceModel
– Conține următoarele proprietăți :
o utilizator, o listă cu autorii preferați, o listă cu categoriile favorite
precum și o proprietate pentru mesajele de eroare pentru cazul în care
intervenit o eroare de se rver.
– Pentru validarea datelor de pe model se folosește Data Annotation cu ajutorul
căreia am specificat validare pentru fiecare câmp (în acest caz toate câmpurile
formularului sunt obligatorii și nu au nevoie de o validare custom)

Pentru Controller :

– Controllerul folosit este PreferenceController

Capitolul 5
41 – Acesta conține o metodă ”Preference” de tip HttpGet care returnează lista
preferințelor setate, o metoda ”HandlePreference” de tip HttpGet care returnează
formularul de adăugarea/ editarea preferințelor și una Ht tpPost care se ocupă cu
prelucrarea datelor
– În cazul în care datele au fost introduse corect, acestea o să apeleze o metodă din
clasa PreferenceBus care apelează DAL (Data Access Layer) pentru a salva
modificările dorite în baza de date, iar utilizatorul e ste redirectat la pagina
”Preference” unde poate vedea lista cu toata preferințele setate, în caz contrar se
afișează mesajele de eroare corespunzătoare

Pentru View :
– Se folosește un view în care sunt afișate preferințele utilizatorul conectat
– Acest view folosește layout -ul principal
– Pe lângă acest view mai exista unul care conține formularul de adăugare/editare
preferințe, acesta apare atunci când utilizatorul apasă butonul de add/edit
preferințe
– Această pagina folosește Jquery pentru a popula o lista cu autocomplete pentru
autori și una pentru categorii
– În cazul în care un autor sau o categorie nu există în baza de date acestea sunt
adăugate
– Acest formular este de tipul AJAX, iar validarea datelor se face Client -Side
folosind JavaScript în funcția ”OnBegi n”
– Pentru câmpurile acestui formular validarea nu constă doar în verificarea ca
acestea sa fie completate, ci se verifica și formatul adresei de email, al telefonului
și a parolei (aceasta trebuie să aibă între 6 -8 caractere și sa conțină și cifre)

5.1.7 Procesul de returnare a cărților după stare de spirit

Această funcționalitate poate fi folosită de către utilizatorii logați și poate fi accesată
din pagina ”My Books”.
Pentru acest proces s -au folosit următoarele clase și view -uri:

Pentru Model:

– În acest caz modelul este reprezentat de clasa FeelingsModel
– Acesta conține o lista de feelings (obiect format din nume și id)

Pentru Controller:

– Se folosește UtilController
– Acesta conține o metodă care returnează un parțial view ce conține o listă de
feelings din baza de date și o metodă care updatează cărțile în funcție de starea
selectată
– Lista de cărți returnată în funcție de stare se de termină folosind cuvintele cheie
definite pentru fiecare carte în parte încercând să le identificăm cu o stare anu me
– Listele de cuvinte cheie care corespund unei stări de spirit sunt stocate în
CouchBase sub forma unor documente JSON

Proiect de diplomă
42
– Aceste documente sunt părsate și mapate pe modelul de mai sus

Pentru View:

– Se folosește Partial View -ul ”Feelings” care afișează o listă de feeling -uri
– La selectarea unei stări, se face un call cu AJAX care updatează cărțile afișate

5.2 Structura bazei de date
Așa cum am precizat și în capitolul anterior, baza de date va fi formată din mai multe
tabele în care o sa fie stocate și actualizate date.
Între aceste tabele exista și legături de tipul many -to-many deoarece fiecare
înregistrare depinde de alte înregistrări. Datorita acestui lucru a fost necesară introducerea
unor tabele ajutătoare pentru a putea face comunicarea între tabele să fie cât mai rapidă și cât
mai corecta , evitându -se apariția dependințelor funcționale și parțiale și tranzitive pentru ca
baza de date să se fie a 3-a forma normala (3NF).

5.2.1 Entitatea Users

În această tabelă se stochează informațiile despre un anumi t user. Principala coloană
este Id -ul userului care reprezintă și cheia primara, adică identificatorul unic al unui utilizator.
Acesta este auto -incrementabil. Un alt câmp important și unic este emailul care este folosit,
împreună cu parola, în procesul de autentificare în aplicație. Nu pot exista doi utilizatori care
să aibă aceeași adresă de email. Parola este criptată folosind un algoritm MD5 din motive de
securitate.
Celelalte câmpuri (nume, prenume, adresă, data nașterii) sunt folosite în scop
informa țional. Adresa utilizatorului este folosită pentru afișarea locației pe hartă și se salvează
într-o tabelă separată, iar aici se adaugă drept cheie străină .
Un alt câmp important din această tabela se referă la rolul utilizatorului. În funcție de acesta
utilizatorul poate avea acces sau nu la anumite funcționalități ale aplicației. Și acesta este
salvat într -o tabelă separată, iar aici se adaugă o cheie străină .

5.2.2 Entitatea Books

În această tabelă se stochează informațiile despre o anumită carte. Principala coloană
este Id -ul cărții care reprezintă și cheia primara, adică identificatorul unic al unei cărții.
Acesta este auto -incrementabil. Un alt câmp unic este ISBN -ul.
Datele referitoare autorului sunt memorate în altă tabelă, pentru evitarea datelor redun dante și
aici se păstrează doar cheia străină . Același lucru este valabil și pentru categoria și editură.
Pe lângă aceste câmpuri, mai există încă două pentru stocarea imaginilor și a preview –
ului.

Capitolul 5
43
5.2.3 Entitatea Library

În această tabelă se stochează inf ormațiile despre o a numita bibliotecă. Principalul
câmp este Id -ul bibliotecii care reprezintă cheia primară, adică identificatorul unic.
Acesta este auto -incrementabil.
Celelalte câmpuri sunt informative, iar adresa este de asemenea păstrată într-o tab elă
diferită. Adresa unei biblioteci este folosită pentru a ajuta utilizatorul să își formeze o părere
despre locația acesteia.

5.2.4 Entitatea Publisher

În această tabelă se stochează informațiile despre o anumita editură. Principalul câmp
este Id -ul editurii care reprezintă cheia primară, adică identificatorul unic.
Acesta este auto -incrementabil.
Aceasta este folosită pentru eliminarea datelor redundante din entitatea ”Books”.

5.2.5 Entitatea Category

În această tabelă se stochează informațiile de spre o anumita categorie. Principalul
câmp este Id -ul categoriei care reprezintă cheia primară, adică identificatorul unic.
Acesta este auto -incrementabil.
Aceasta este folosită pentru eliminarea datelor redundante din entitatea ”Books”.

5.2.6 Entitate a Address

În această tabelă se stochează informațiile despre o anumita categorie. Principalul
câmp este Id -ul adresei care reprezintă cheia primară, adică identificatorul unic.
Acesta este auto -incrementabil.
Aceasta este folosită pentru eliminarea dat elor redundante din entitatea ”Books” și
”Users”.

5.2.7 Entitatea Feelings

În această tabelă se stochează informațiile despre o anumita stare de spirit. Principalul
câmp este Id -ul, care reprezintă cheia primară, adică identificatorul unic.
Acesta este auto-incrementabil.
Această entitate are un corespondent și în baza de date NoSql, CouchBase. Acolo
pentru fiecare înregistrare din această tabelă exista un definit un document JSON al cărui Id
are aceeași valoare cu cea din câmpul ”Feeling”
5.2.8 Entit atea Roles

În această tabelă se stochează informațiile despre rolurile unui utilizator. Principalul
câmp este Id -ul, care reprezintă cheia primară, adică identificatorul unic. Acesta este auto –
incrementabil.

Proiect de diplomă
44
Această entitate se folosește pentru eliminare a datelor redundante din tabela ”Users”.

5.2.9 Entitatea Authors

În această tabelă se stochează informațiile despre autori. Principalul câmp este Id -ul,
care reprezintă cheia primară, adică identificatorul unic.
Acesta este auto -incrementabil.
Această entitate se folosește pentru eliminarea datelor redundante din tabela ”Books”.

5.2.8 Entitatea History

În această tabelă se stochează informațiile despre istoricul unui utilizator. Principalul
câmp este Id -ul, care reprezintă cheia primară, adică identif icatorul unic.
Acesta este auto -incrementabil.
Această entitate conține o referință către tabelă ”Books” și una către tabela ”Users”.

5.2.8 Entitatea UserCategoryReference

În această tabelă se stochează informațiile despre preferințele unui utilizator în materie
de categoria cărților . Principalul câmp este Id -ul, care reprezintă cheia primară, adică
identificatorul unic.
Acesta este auto -incrementabil.
Această entitate a fost adăugată pentru a elimina relația many -to-many dintre tabela
”Users” și tabela ”Category”.

5.2.9 Entitatea UserAuthorReference

În această tabelă se stochează informațiile despre preferințele unui utilizator în materie
de autorii cărților. Principalul câmp este Id -ul, care reprezintă cheia primară, adică
identificatorul unic.
Acesta este auto -incrementabil.
Această entitate a fost adăugată pentru a elimina relația many -to-many dintre tabela
”Users” și tabela ”Author”.

Capitolul 6
45

Capitolul 6 TESTARE ȘI VALIDARE

În acest capitol se va face o scurtă introducere în domeniul testării, i ar mai apoi se vor
prezenta rezultatele experimentale obținute de -a lungul analizelor dezvoltării acestei aplicații.
Fiecare aplicație software trebuie să fie testata pentru a nu exista bug -uri . Procesul de
testare poate fi manual sau automat.
Acum exista o tendința din ce în ce mai mare să se apeleze la testarea automata pentru o mai
bună acoperire a testelor.
Testarea automata are atât avantaje cât și dezavantaje.
Printre principalele dezavantaje întâlnim :
Testarea automată este costisitoare
Ideal este s ă se facă testare asistată de calculator și nu testare automată complet
Dezvoltarea testelor este dezvoltare software, deci este nevoie de cineva cu cunoștințe
în acest domeniu
Testele trebuie să fie făcute în concordanta cu specificațiile aplicației
Manag eri au în general o părere greșita despre acest tip de testare
Principalele avantaje sunt:
Test case -urile sunt rulate automat
Ajută la rularea testelor pe configurații diferite
Timpul de testare este scăzut
În Figura 6.1 se poate vedea fluxul datelor în testarea automata:

Figura 6.1 Fluxul datelor în testarea automată

Proiect de diplomă
46

Modul de raportare al bug -urilor

1. Ciclu de viața al unui bug
Acest ciclu este descris în Figura 6.2 din momentul în care acesta este raportat și până în
momentul în care acest a este rezolvat și implicit închis.

Figura 6.2 Ciclu l de viață al unui bug

2. Prioritate/ Severitate
Prioritate: grijile referitoare la modul în care acest bug poate afecta aplicația din punct
de vedere al business -ului.
Severitate: grijile referitoare la modul în care acesta afectează funcționalitatea
aplicației.
Exemple:
Prioritate ridicată și severitate scăzută:
– Logo -ul companiei nu este afișat în website
Prioritate ridicată și severitate ridicată:
– În cazul unui magazin online, după ce se efectueaz ă plata se primește un mesaj
de eroare
Prioritate scăzuta și severitate ridicată:
– Exista un bug în aplicație, dar apare foarte rar
Prioritatea scăzuta și severitate scăzuta:
– Un mesaj din aplicație nu conține textul așteptat .

În cazul meu, am optat pen tru testarea manuală, iar în continuare v oi prezenta pe rând
funcționalitățile implementate, scoțând în eviden ță atât scenariile de succes cât și cele
eronate.

Capitolul 6
47

6.1 Procesul de înregistrare

Una din principalele funcționalități ale acestei aplicații este repr ezentată de
înregistrarea unui utilizator î n baza de date. În vederea realizării acestui lucru, a fost cr eat un
formular care conține câmpuri în care utilizatorul trebuie să introducă date valide.
În vederea înregistrării cu succes, utilizatorul va trebui să îndeplinească anumite
condiții :

A. Utilizatorul va trebui sa completeze toate câmpurile din formular, în caz contrar
un mesaj va fi afișat pe ecran atenționându -l ce câmp a rămas necomplet at așa
cum se vede în Figura 6.3

B. Una dintre cele mai important e condiții ca înregistrarea să se facă cu succes este
aceea ca utilizatorul să aibă conexiune la internet, deoarece datele completate
trebuie să fie salvate intr -o baza de date și asta este posibil doar prin intermediu
internetului

C. Utilizatorul va trebu i sa completeze corect câmpurile formularului, în caz contrar
va fi afișat un mesaj de eroare corespunzător . Aceste mesaje se împart în două
categorii :

 Client -side, validările care se ocupă cu verificarea formatului datelor
introduse în input -uri, acestea se realizează folosind JavaScript și nu necesită
efectuarea unui request la server. Figura 6. 3 Mesaje de eroare pentru câmpuri goale

Proiect de diplomă
48

Pentru partea de register aceste mesaje sunt:
– Parola și confirmarea parolei nu coincid
– Parola nu are între 6 și 8 caractere și nu conține nicio cifră
– Adresa de email nu este validă
– Codul poștal nu are 6 cifre
– Telefonul nu are 10 cifre

În Figura 6.4 se poate vedea modul în care apar aceste mesaje

 Server -side, validările care se ocupă cu consistența datelor din baza de date ,
și care implica un request la server .
În aplicația noastră , la partea de înregistrarea se realizează server -side
validarea adresei de email deoarece, aceasta este considerata unică și este
folosită la partea de autentificare în aplicație.
Astfel în momentul înregistrării se face un query la b aza de date pentru a se
verifica daca adresa de email introdusă a mai fost utilizata, în acest caz
apare un mesaj de eroare de forma:
– Adresa de email trebuie să fie unică

Figura 6.4 Validate client -side

Capitolul 6
49

În Figura 6.5 se poate observa acest mesaj de eroare.

Figura 6.5 Validar e server -side pentru register

6.2 Procesul de Autentificare
O altă funcționalitate importanta a acestei aplicații este cea de login, deoarece doar un
utilizator logat are acces la partea de ”My Books”, ”My History” și/sau managementul
bibliotecilor , resp ectiv cel al cărților .
Pentru autentificarea cu succes, datele introduse de utilizator trebuie să treacă cele
două tipuri de validări :
A. Validările client -side:
– Username -ul și parola trebuie să fie completate
– Daca nu sunt complete o să apăra un mesaj de er oare corespunzător

În figura 6.6 se poate observa acest lucru:

Proiect de diplomă
50

Figura 6.6 Validare client -side pentru login

B. Validări server -side:
– Se face un request la server și se verifică daca în baza de date există un
utilizator cu emailul și parola respectivă
– În cazul în care utilizatorul nu există se va afișa un mesaj de eroare
În Figura 6.7 se poate observa acest lucru:

Figura 6. 7 Validări server -side pentru login
În cazul în care autentificarea are loc cu succes, utilizatorul este redirectat la pagina
principală.
6.3 Pagina Principală ”Home”
În Figura 6.8 se poate vedea pagina principală.

Capitolul 6
51

Figura 6. 8 Pagina principală

După cum se poate vedea în imaginea de mai sus, pagina principală include mai multe
funcționalități:
A. Glosar
– Sunt afișate toate literele din alfabet
– Atunci când se selectează o literă, cărțile sunt filtrate după nume și
o să apară doar cele care încep cu litera respectivă

B. Filtrare după autori
– Pe pagina principală exista un textbox cu autocomplete
– Lista pe care o folosește autocomplete -ul este lista autorilor din
baza de date
– În momentul în care se alege un autor, o să apară doar cărțile scrise
de acel autor

C. Filtrare după categorie
– În partea stângă a acestei pagini există o lista de categorii
– Această listă este de fapt lista categoriilor din baza de date
– În momentul în care se alege o categorie, cărțile vor fi filtrate în
funcție de aceasta
D. Search
– Tot în această pagină este prezentă și funcționalitatea de search
– În momentul în care userul tastează un nume în acel câmp, vor fi
afișate doar cărț ile cu numele respectiv
– Funcționalitatea de search ține cont și de celelalte filtre enumerate
și descrise mai sus
E. Paginare
– Având în vedere că în baza de date există multe cărți este necesară
și funcționalitatea de paginare

Proiect de diplomă
52

Această pagină, practic conține o listă cu toate cărțile din baza de date. În momentul în
care se selectează o anumită carte se deschide un fancy box cu detaliile despre aceasta,
precum și coperta cărții.
În această pagina nouă care conține mai multe detalii despre o anumită carte, în
momentul în care utilizatorul este logat o sa îi apară un link care o sa îl redirecteze la o pagină
unde o sa poată efectua următoarele lucruri:
– Va putea vizualiza o hartă care îi va arăta atât locația lui, cât și locația
bibliotecilor unde se găsește carte a respectivă
– Va putea adaugă această carte la lista cărților favorite sau la lista cărților pe
care dorește să le citească sau le -a citit deja
– Va putea vizualiza și un mic preview al acesteia
În cazul în care utilizatorul nu este logat , acesta va vedea doa r descrierea și coperta
cărții, așa cum se poate observa în Figura 6. 9.

6.4 Adaugă carte
Pagina Add Book este accesibilă doar utilizatorului de tip admin, care poate să adauge
sau să editeze cărți.
Pentru ca o carte să fie adăugată cu succes, utilizato rul trebuie să completeze c orect
toate câmpurile. Din nou e xista cele doua tipuri de validări :

A. Validarea client -side p oate fi observată din Figura 6.10
Figura 6.9 Pagina de detalii

Capitolul 6
53

Figura 6.10 Validare client -side add book

B. Validarea server -side este folosită în acest caz pentru verificarea fișierelor
încărcate.
– Utilizatorul trebuie să încarce coperta și preview -ul cărții,
– În cazul în care unul din aceste fișiere nu este încărcat va apărea un
mesaj de eroare corespunzător după cum s e poate observa și în
Figura 6.11

Figura 6. 11 Validare server -side add book
– În cazul în care utilizatorul a încărcat aceste fișiere , dar nu în
formatul care trebuie o să îi apară un mesaj de eroare deoarece
fișierele nu au extensia potrivită
– Acest lu cru se poate vedea în Figura 6.12

Proiect de diplomă
54

Figura 6.1 2 Validare server -side add book

6.5 Adaugă Bibliotecă

Pagina de adăugare de bibliotecă este accesibilă doar utiliz atorului d e tip SuperAdmin .
Acesta este singurul care poate adăuga sau edita datele despre o bibliotecă .
Pentru ca modificările să fie sa lvate cu succes, utilizatorul trebuie să completeze câmpurile
după cum urmează:
– Trebuie să adauge numele bibliotecii
– Trebuie să selecteze țara din care face parte
– Trebuie sa adauge județul
– Trebuie să adauge orașul
– Trebuie sa adauge adminul
– Adminul trebuie să fie ales selectând un utilizator existent din baza de date
În cazul în care aceste câmpuri nu sunt completate corect vor apărea mesajele de eroare
corespunzătoare. În acest caz validarea este făcută server -side.
Un caz în care nu toate câmpurile au fo st completate poate fi observat în Figura 6.13 ,
unde singurul câmp completat a fost cel corespunzător țării.

Capitolul 7
55

Figura 6.13 Validare server -side adaugă bibliotecă

Capitolul 7 CONCLUZII

7.1 Contribuții
Obiectivul acestei lucrări a fost acela de a dezvolta o bibliotecă hibridă, o combinaț ie
între bibliotecile digitale și cele tradiționale.
Pe lângă obiectivul principal, aplicația aduce ceva nou în comparație cu o simplă bibliotecă
online, în sensul că pe lângă partea în care utilizatorul este interesat de anu mite cărți și
accesează aplicația pentru a le căuta și aplicația la râ ndul ei vine cu propuneri personalizate
despre ce ar trebui sa citească utilizatorul. Astfel putem să o numim bibliotecă interactivă.
Implementarea propusă se bazează pe ASP .NET MVC și folosește o bază de date
relațională și una de tip NoSql bazată pe documente.
Caracteristicile acestei aplicații care o fac sa fie interactiva sunt:
– Returnarea unei liste de cărți în funcție de starea de spirit, adică de exemplu
daca utilizatorul este îndrăgostit o să îi fie recomandate cărți de dragoste
– Returnarea unei liste de cărți în funcție de preferințele utilizatorului.
Utilizatorul o să primească lista de cărți noi apărute care fac parte dintr -o

Proiect de diplomă
56
anumită categorie setata ca drept categorie preferată sau sunt scrise de autorii
preferați
O altă funcționalitate care vine în ajutorul utilizatorului, îndemnând -ul să citească cât mai
mult, este partea de gestionarea a istoricului. Acesta poate să vadă ce cărți a citit, de la ce
bibliotecă au fost și cât de mult i -au plăcut. Tot aici poate să adauge cărțile pe care ar trebui
sau ar vrea să le citească, iar apoi să le marcheze citite sau necitite în funcție de caz.
Folosirea serviciului Google Maps ajută utilizatorul să își formeze o părere despre
locațiile unde poate găsi o anumită carte, scoțând în evidență biblioteca cea mai apropiată de
acesta.
O altă caracteristică a acestei aplicații este căutarea din pagina principală care
folosește motorul de căutare Solr pentru o căutarea mult mai rapidă, având în v edere că baza
de date este destul de mare.

7.2 Analiza rezultatelor

Realizarea caracteristicilor enumerata și descrise mai sus a fost realizată cu succes.
Aplicația a fost testată manual și așa cum am prezentat și în secțiunea de testare există mulți
factor i care pot duce la nefuncționarea corectă aplicației și de aceea trebuiesc îndepliniți
anumiți pași pentru o bună funcționalitate a sistemului dezvoltat.
Primul pas și cel mai important este reprezentat de condiția ca utilizatorul să fie
conectat la intern et. Nu contează daca folosește un desktop sau un devic e mobil, deoarece
aplicația este responsive, adică se adaptează în funcție de rezoluție și de agentul folosit.
Pe lângă această primă condiție , pentru a realiza mai multe operații din această aplicație
utilizatorul trebuie sa fie autentificat, deci aceasta trebuie să se înregistreze. În capitolul
precedent am prezentat modul în care utilizatorul trebuie să completeze formularele și tipul de
date pe care trebuie sa îl folosească pentru a realiza orice ac țiune cu succes, adică pentru a
trece atât validările client -side cât și cele server -side.

7.3 Dezvoltări ulterioare

Din puncte de vedere al funcționalităților noi adăugate și gândindu -ne la o bibliotecă
hibridă dar interactivă, acasă aplicație ar pu tea fi îmbunătățită în sensul de a fi mult mai
interactivă și mai utilă utilizatorului.
În primul rând aceasta ar putea avea o pagina noua de notificări, astfel în momentul în
care apare o carte nouă care se încadrează în preferințele utilizatorului, aces ta ar trebui să
primească un email în care să fie informat , iar atunci când se loghează în aplicație să poată
vedea notificările respective.
O altă metodă de îmbunătățire , care ar veni în ajutorul utilizatorului, ar fi aceea în care
acesta ar putea vota c ărțile și ar putea vedea votul și părerea altor utilizatori despre cartea
respectivă.
O ultima funcționalitate la care m -am gândit și care ar putea fi implementată ar fi un
forum sau un spațiu în care utilizatorii sa poată comunica între ei și să aibă posibilitatea să se
grupeze în funcție de preferințele setate.

Capitolul 7
57

BIBLIOGRAFIE
57 BIBLIOGRAFIE

[1] Apache Solr Documentation, http://lucene.apache.org/solr/
[2] Christian Wenz, Programmi ng Asp.NET AJAX, 2007
[3] Dependency Injection Documentation, ASP.NET MVC 4 Dependency Injection
[4] Glenn Johnson, Programming in HTML5 with Ja vascript and CSS3
[5] Google Maps API Documentation , http://code.google.com/apis/maps/documentation/
[6] Ileana Popescu, Base de date relaționale: proiectare și impleme ntare, Editura
Universității din București, 1996
[7] Jeffrey Palermo, Jimmy Bogard, Eric Hester, Mattheu Hinze, Jeremy Skinner, ASP
.NET MVC4 In Action
[8] M. C Brown, Martin C. Brown, Getting Started with CouchBase Server
[9] NoSql Documentation, http://nosql -database.org/