FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_Pop_Laura.pdf · rezultatul propriei activita˘ti intelectuale, pe baza cercetar ilor mele ˘si

FACULTATEA DE AUTOMATICA SI CALCULATOAREDEPARTAMENTUL CALCULATOARE

APLICATIE COLABORATIVA BAZATA PE TEHNOLOGII GOOGLE

LUCRARE DE LICENTA

Absolvent: Laura-Maria POPConducator stiintific: Asis. Dr. Ing. Cosmina IVAN

2018


DECAN, DIRECTOR DEPARTAMENT,Prof. dr. ing. Liviu MICLEA Prof. dr. ing. Rodica POTOLEA

Absolvent: Laura-Maria POP

APLICATIE COLABORATIVA BAZATA PE TEHNOLOGII GOOGLE

1. Enuntul temei: Scurta descriere a temei lucrarii de licenta si datele initiale

2. Continutul lucrarii: (enumerarea partilor componente) Exemplu: Pagina de prezentare,aprecierile coordonatorului de lucrare, titlul capitolului 1, titlul capitolului 2, titlulcapitolului n, bibliografie, anexe.

3. Locul documentarii: Exemplu: Universitatea Tehnica din Cluj-Napoca, Departa-mentul Calculatoare

4. Consultanti:

5. Data emiterii temei: 1 Octombrie 2017

6. Data predarii: 9 Iulie 2018

Absolvent:

Coordonator stiintific:


Declaratie pe proprie raspundere privindautenticitatea lucrarii de licenta

Subsemnatul(a), legiti-

mat(a) cu seria nr.CNP , autorul lucrarii

elaborata ın vederea sustinerii examenului de finalizare a studiilor de licenta la Facul-tatea de Automatica si Calculatoare, Specializareadin cadrul Universitatii Tehnice din Cluj-Napoca, sesiunea a an-ului universitar , declar pe proprie raspundere, ca aceasta lucrare esterezultatul propriei activitati intelectuale, pe baza cercetarilor mele si pe baza informatiilorobtinute din surse care au fost citate, ın textul lucrarii si ın bibliografie.

Declar, ca aceasta lucrare nu contine portiuni plagiate, iar sursele bibliografice aufost folosite cu respectarea legislatiei romane si a conventiilor internationale privind drep-turile de autor.

Declar, de asemenea, ca aceasta lucrare nu a mai fost prezentata ın fata unei altecomisii de examen de licenta.

In cazul constatarii ulterioare a unor declaratii false, voi suporta sanctiunile admin-istrative, respectiv, anularea examenului de licenta.

Data Nume, Prenume

Semnatura

Lista tabelelor

5.1 Descrierea componentelor pentru Spring (back-end) . . . . . . . . . . . . . 335.2 Descrierea componentelor pentru AngularJS(front-end) . . . . . . . . . . . 33

5

Lista figurilor

3.1 Interactiunea componentelor unei aplicatii web [9] . . . . . . . . . . . . . 8

4.1 Arhitectura conceptuala a aplicatiei . . . . . . . . . . . . . . . . . . . . . . 134.2 Diagrama cazurilor de utilizare pentru utilizatorul obisnuit . . . . . . . . . 154.3 Diagrama cazurilor de utilizare pentru administrator . . . . . . . . . . . . 184.4 Pasii protocolului OAuth 2.0 [10] . . . . . . . . . . . . . . . . . . . . . . . 204.5 Pasii pentru autentificarea cu Google [11] . . . . . . . . . . . . . . . . . . 21

5.1 Diagrama de pachete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.2 Diagrama de clase pentru User . . . . . . . . . . . . . . . . . . . . . . . . . 345.3 Diagrama de secventa pentru o operatie GET . . . . . . . . . . . . . . . . 385.4 Arhitectura bazei de date . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.5 Vizualizarea evenimentelor ın aplicatia web . . . . . . . . . . . . . . . . . . 46

6.1 Testarea ın programul Postman . . . . . . . . . . . . . . . . . . . . . . . . 50

7.1 AdminPannel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.2 UserPannel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

A.1 Diagrama de clase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6

Lista fragmentelor de cod

4.1 Apelarea Maps JavaScript API folosind un API Key . . . . . . . . . . . . . 244.2 Exemplu de pom.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.1 Adnotarile folosite ın clasa User pentru maparea bazei de date prin frame-

workul Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.2 Exemplu de repository: clasa UserRepository . . . . . . . . . . . . . . . . . 365.3 User service: folosirea adnotarilor . . . . . . . . . . . . . . . . . . . . . . . 365.4 Folosirea adnotarilor pentru controller . . . . . . . . . . . . . . . . . . . . 375.5 Metoda main din clasa DibApplication prin care se porneste aplicatia . . . 375.6 Conexiunea cu baza de date ın framework-ul Spring . . . . . . . . . . . . . 395.7 Dependinte pentru Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . 395.8 Dependinta pentru MySQL Connector . . . . . . . . . . . . . . . . . . . . 405.9 Dependinte pentru JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.10 Configurarile pentru autentificarea cu Google din fisierul de configurare ap-

plication.properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.11 Prelaurea datelor de la Google . . . . . . . . . . . . . . . . . . . . . . . . . 435.12 Accesarea Google Calendars API prin JavaScript . . . . . . . . . . . . . . 445.13 Extragerea evenimentelor din Google Calendars ın functie de filtrele setate. 455.14 Trimiterea evenimentelor catre server . . . . . . . . . . . . . . . . . . . . . 465.15 Trimiterea evenimentelor catre server . . . . . . . . . . . . . . . . . . . . . 475.16 Calcularea distantei ıntre doi utilizatori . . . . . . . . . . . . . . . . . . . . 485.17 Configurea WebSockets pentru sistemul de chat . . . . . . . . . . . . . . . 495.18 Deschiderea conexiunilor in JavaScript . . . . . . . . . . . . . . . . . . . . 49

7

Cuprins

Lista tabelelor 5

Lista figurilor 6

Capitolul 1 Introducere - Contextul proiectului 11.1 Scop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Continutul lucrarii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Capitolul 2 Obiectivele Proiectului 42.1 Cerinte functionale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Cerinte non-functionale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Cerinte de resurse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Capitolul 3 Studiu Bibliografic 83.1 Dezvoltarea aplicatiilor web . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2 Aplicatii colaborative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3 Aplicatii colaborative existente . . . . . . . . . . . . . . . . . . . . . . . . 11

Capitolul 4 Analiza si Fundamentare Teoretica 124.1 Arhitectura conceptuala . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2 Cazuri de utilizare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2.1 Actori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2.2 Scenarii si diagramele cazurilor de utilizare . . . . . . . . . . . . . . 15

4.3 API-uri Google . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.3.1 Google Sign-in cu Google+ bazat pe protocolul OAuth 2.0 . . . . . 194.3.2 Google Calendars API . . . . . . . . . . . . . . . . . . . . . . . . . 214.3.3 Google Maps Platform . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.4 Google Cloud Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.4.1 Google Cloud SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.5 Tehnologiile de server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.5.1 Serviciile REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.5.2 Spring Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.5.3 WebSockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

8

4.5.4 Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.5.5 Server-ul Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.5.6 Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.6 Tehnologiile de client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.6.1 AngularJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.6.2 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Capitolul 5 Proiectare de Detaliu si Implementare 315.1 Arhitectura de detaliu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.1.1 Diagrama de pachete . . . . . . . . . . . . . . . . . . . . . . . . . . 325.1.2 Diagrama de clase . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.1.3 Diagrama de secventa . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.2 Baza de date a aplicatiei . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2.1 Arhitectura bazei de date . . . . . . . . . . . . . . . . . . . . . . . 40

5.3 Componente reprezentative . . . . . . . . . . . . . . . . . . . . . . . . . . 435.3.1 Sign-in cu Google . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.3.2 Preluarea datelor din Google Calendars . . . . . . . . . . . . . . . . 445.3.3 Transmiterea coordonatelor si calcularea distantei . . . . . . . . . . 465.3.4 Sistemul de chat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Capitolul 6 Testare si Validare 50

Capitolul 7 Manual de Instalare si Utilizare 527.1 Instalare aplicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527.2 Manual de utilizare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Capitolul 8 Concluzii 548.1 Obiective ındeplinite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548.2 Dezvoltari ulterioare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Bibliografie 56

Anexa A Diagrama de clase 58

9

Capitolul 1

Introducere - Contextul proiectului

Dezavantajul major al aplicatiilor de time management este ca nu iau in considerarefactorul social care leaga organizarea timpului de dezvoltarea personala, astfel ca ın ultimaperioada s-a pus extrem de mult accentul pe activitatile realizate si dezvoltarea ın echipa.Acest lucru se datoreaza si faptului ca de multe ori ne simtim motivati de cel de langanoi. Acest dezavantaj de a nu lua ın considerare factorul social, a fost minimizat o data cuaparitia conceptului de sisteme colaborative care sustin desfasurarea activitatilor la nivelde echipa. Aplicatia de fata vine ın ajutorul celor care vor sa isi dezvolte anumite abilitati siau nevoie de motivatie, abilitatile de lucru ın echipa si comunicare dezvoltandu-se implicit.

Varianta traditionala pentru aceasta aplicatie ar fi cursurile. Dezavantajul acestorcursuri este ca orele la care sunt ele programate sunt impuse, sunt cu plata sau pur sisimplu nu se gaseste un curs pentru domeniul dorit. Aplicatia va fi creata pentru a eliminaaceste dezavantaje, astfel ıncat utilizatorii isi vor putea alege atat persoanele cat si orelepentru a-si dezvolta anumite abilitati, aplicatia avand un avantaj major deoarece ımbinaeficienta lumii on-line cu lumea off-line, persoanele ajungand sa se cunoasca ın realitate,iar astfel se elimina dezechilibrul provocat de social-media.

Un alt avantaj al aplicatiei este ca utilizatorul ısi poate planifica timpul ın cadrulcalendarului, astfel ıncat va avea o agenda mereu la el, iar aplicatia va cauta ceilaltiutilizatori ın functie de timpul liber (adica timpul necompletat) din calendar.

Utilizatorul va putea alege dintr-o gama larga activitatile pe care le desfasara sisa se ”aboneze” la ele. Daca exista ın apropierea lui un alt utilizator care doreste acelasilucru si agendele lor se potrivesc, acestia vor fi notificati reciproc. Dupa ce s-au conectat,utilizatorii vor putea comunica printr-un sistem de chat.

1.1 Scop

Scopul principal al acestui proiect este de a construi un sistem colaborativ bazat petehnologii web si folosind solutii Google cloud, care le va oferi utilizatorilor o posibilitatede organizare a activitatilor si sarcinilor de lucru mai usoara si mai prietenoasa, prin

1

2

interactiunea cu alti utilizatori. Aplicatia va ajuta utilizatorii sa devina mai organizati,dar va avea si rolul de a-i ajuta sa ısi dezvolte anumite pasiuni, calitati sau talente ımpreunacu alti oameni care simt si gandesc la fel ca si ei.

Aplicatia va pune la dispozitie un sistem de conectare a utilizatorilor care doresc saısi dezvolte anumite hobby-uri, pasiuni sau chiar sa ınvete un lucru nou, printr-un algoritmde matching. Aceste pasiuni sau hobby-uri vor fi reprezentate ın sistem ca si wishuri. Deasemenea, dupa ce utilizatorii au fost conectati, ei vor avea posibilitatea de a lua legaturaunul cu altul printru-un sistem de chat. Pentru a acorda credibilitate utilizatorilor, acestiaısi vor putea lasa mici review-uri unul altuia ca o forma de validare a interactiunii lor, la operioada de timp aleasa arbitrar dupa ce s-au conectat si dupa ce wish-ul comun a devenitevent ın calendarul fiecaruia.

La deschiderea aplicatiei, utilizatorii vor vedea o pagina web prin care li se vacere autentificarea cu adresa de email a contului Google pentru a avea acces la serviciileaplicatiei. Dupa autentificare, fiecarui utilizator i se va afisa pagina web corespunzatoarerolului lui (administrator sau utilizator obisnuit).

Dupa ce s-a autentificat ın aplicatie, utilizatorul poate alege din lista de wish-uri, poate propune wish-uri noi, poate lasa review-uri, poate accepta conexiuni sau poateinteractiona cu alti utilizatori.

1.2 Continutul lucrarii

In cadrul acestei subsectiuni se va realiza o enumerare, dar si descrierea fiecaruicapitol care va fi prezent ın cadrul acestei lucrari:

� Capitolul 1: INTRODUCERE - CONTEXTUL PROIECTULUI - Acestcapitol descrie si leaga aplicatia de fata de un context social. De asemenea se enumerabeneficiile si avantajele aduse de sistemul care se doreste sa fie implementat.

� Capitolul 2: OBIECTIVELE PROIECTULUI - In acest capitol, vor fi discu-tate obiectivele stabilite si structurate ın cerinte functionale si cerinte nefunctionalecare vor conduce la dezvoltarea acestui sistem.

� Capitolul 3: STUDIU BIBLIOGRAFIC - In acest capitol se sintetizeaza infor-matiile obtinute prin studierea unor lucrari stiintifice care descriu concepte relevantepentru sistemul de fata, cum ar fi concepte de sisteme IT de colaborare si structura lorsau dezvoltarea aplicatiilor web. De asemenea se vor descrie abordari asemanatoarede conectare a oamenilor prin retelele de socializare.

� Capitolul 4: ANALIZA SI FUNDAMETARE TEORETICA - Acest capi-tol ıncepe cu prezentarea arhitecturii conceptuale a aplicatiei care se doreste a fiimplementata si continua cu o scurta prezentare a informatiilor despre tehnologiile,serviciile de cloud de la Google, API-urile de la Google, framework-urile de front-endsi back-end folosite pentru implementarea si dezvoltarea aplicatiei. De asemenea, se

1.2. CONTINUTUL LUCRARII 3

va prezenta motivarea alegerii facute asupra acestora subliniind avantajele si deza-vantajele fiecareia ın contextul dat.

� Capitolul 5: PROIECTARE DE DETALIU SI IMPLEMENTARE - Inacest capitol este detaliata implementarea acestui sistem prin explicarea mapariitehnologiilor pe componentele aplicatiei. De asemenea, vor fi evidentiate fluxul dedate prin diagrame de secventa, cazurile de utilizare si comunicarea dintre princi-palele componente.

� Capitolul 6: TESTARE SI VALIDARE - Acest capitol prezinta mijloacele siutilitarele prin care aplicatia de fata a fost testata si metodele prin care rezultateleobtinute au fost validate. De asemenea, se va prezenta simularea unor cazuri deutilizare prezentate ın Capitolul 5 pentru a ilustra comportamentul sistemului.

� Capitolul 7: MANUAL DE INSTALARE SI UTILIZARE - In acest capitolse vor prezenta detaliile pentru instalarea si rularea aplicatiei printr-un set de pasibine definiti. Mai mult, pasii vor fi reprezentati printr-un manual de utilizare.

� Capitolul 8: CONCLUZII - Acest ultim capitol, reprezinta un set de observatiiobiective facute pe baza studiului si implementarii, pentru a vedea ın ce masuraau fost atinse obiectivele propuse initial. De asemenea, sunt mentionate limitarileaplicatiei si se propune o lista cu implementari ulterioare.

Capitolul 2

Obiectivele Proiectului

Obiectivul principal al acestei lucrari este de a proiecta si implementa un sisteminformatic colaborativ sub forma unei aplicatii web, bazata ın mare parte pe tehnologiileGoogle Cloud. Aceasta aplicatie are rolul de a conecta diferite persoane, ın functie de 3criterii: distanta, timpul liber si respectiv ceea ce vor sa ınvete sau sa dezvolte.

Cerintele proiectului se structureaza ın trei parti: cerinte functionale, cerinte non-functionale si cerinte de resurse.

2.1 Cerinte functionale

Cerintele functionale necesare pentru acest proiect sunt:

1. Autentificarea cu Google - Autentificarea se efectueaza prin intermediul Google+API si redirectionarea utilizatorului spre AdminPannel sau spre UserPage, ın functiede rolul lui (daca e administrator sau nu)

2. Inregistrarea ın aplicatie - Inregistrarea automata ın baza de date la autentificareacu adresa de e-mail de la Google, ın cazul ın care utilizatorul respectiv nu exista dejaın baza de date. In baza de date se vor introduce datele furnizate de Google.

3. Editare profil - Posibilitatea utilizatorului de a-si edita profilul

4. Alegerea unui wish - Posibilitatea utilizatorului de a-si alege, dintr-o lista dedorinte pusa la dispozitie, subiectele ce doresc a fi ınvatate sau dezvoltate

5. Propunerea unui wish - Posibilitatea utilizatorului de a propune un nou subiectın lista de wishes

6. Adaugarea unui eveniment - Posibilitatea utilizatorului de a adauga un evenimentın calendarul propriu Google Calendars prin intermediul aplicatiei web

4

2.2. CERINTE NON-FUNCTIONALE 5

7. Editareea unui eveniment - Posibilitatea utilizatorului de a edita un evenimentdin calendarul propriu Google Calendars prin intermediul aplicatiei web

8. Stergerea unui eveniment - Posibilitatea utilizatorului de a sterge un evenimentdin calendarul propriu Google Calendars prin intermediul aplicatiei web

9. Conectarea utilizatorilor - Aplicatia va conecta doi utilizatori pe baza distanteiıntre cei doi, a timpului lor liber si a elementelor comune din lista de wishes

10. Acceptarea unei conexiuni - Posibilitatea utilizatorului de a accepta sau a refuzaconexiunile cu alti utilizatori propuse de aplicatie

11. Chat - Posibilitatea utilizatorului de a coresponda on-line prin intermediul unui chatcu conexiunile acceptate

12. Adaugarea review - Posibilitatea utilizatorului de a lasa un review unui alt uti-lizator

13. Moderarea review-rilor - Moderarea review-urilor lasate de utilizatorii obisnuitide catre un administrator

14. Moderarea wish-urilor - Moderarea subiectelor noi aparute ın lista de wishespropuse de utilizatorii obisnuiti, de catre un administrator

15. Blocarea sau deblocarea unui utilizator - Blocarea sau deblocarea unui utiliza-tor de catre un administrator

16. Schimbarea rolului - Schimbarea rolului de la un utilizator obisnuit la administra-tor, de catre un utilizator care este deja administrator.

2.2 Cerinte non-functionale

Cerintele non-functionale necesare pentru acest proiect sunt:

1. Scalabilitatea este proprietatea unui sistem de a-si mari sau micsora resursele ınfunctie de numarul de utilizatori, astfel ıncat sa se mentina performanta sistemului.In cazul de fata, scalabilitatea este asigurata de resursele plasate in cloud.

2. Performanta este o cerinta non-functionala extrem de importanta. Aceasta poate fiexprimata prin timpul de raspuns al aplicatiei pentru o anumita cerere. Majoritateaoperatiilor se fac pe partea de server ceea ce ınseamna ca media de raspuns pentruun client ar trebui sa fie ın jur de 2-3 secunde la o viteza medie de 30 MBps vitezade download si 6 MBps viteza de upload. De asemenea, faptul ca baza de date estestocata ın Google Cloud pe un hard-disk de tip SSD, ajuta ca interactionarea cubaza de date sa fie mult mai rapida.

6 CAPITOLUL 2. OBIECTIVELE PROIECTULUI

3. Disponibilitatea este o cerinta non-functionala definita ca si timpul ın care aplicatiaeste functionala si gata de folosit, mai exact up and running ın termeni de specialitate.Pentru acest proiect se doreste un up-time de peste 95%, astfel cazurile ın caresistemul va fi down vor fi doar din cauze exceptionale ın care se impune oprirea luisau din motive de mentenanta. Aceasta cerinta poate fi ındeplinita prin solutii decloud computing sau prin replicarea aplicatiei pe mai multe noduri pentru a rezolvaproblema unui singur punct de esec (single point of failure).

4. Utilizabilitatea este cerinta non-functionala care reprezinta usurinta cu care sis-temul este utilizat. Desi aceasta cerinta are o natura subiectiva deoarece depindemult de tipul de utilizator care foloseste aplicatia (novice sau expert), o componentafoarte importanta a acestei calitati este interfata cu utilizatorul. Aceasta trebuie safie simpla, fara a fi ıncarcata de prea mult continut, predictibila si intuitiva. Deasemenea, aplicatia trebuie sa se adapteze la diferite tipuri de dimensiuni de ecran,iar daca sistemul este ıntr-un proces de executie a unor cereri, acesta nu trebuie sase blocheze, ci trebuie sa afiseze niste mesaje clare de informare pentru utilizator.

5. Extensibilitatea este proprietatea unui sistem de a evolua si de a i se adauga functiinoi. Acest lucru este posibil foarte usor si rezulta din cuplarea slaba a componentelordin Spring si din arhitectura intuitiva. Din aceste motive si mentenanta poate fi,relativ usor de realizat.

6. Securitatea este cerinta non-functionala prin care se presupune protectia datelor sirezistenta ımpotriva atacurilor. Protectia si rezistenta sunt asigurate prin plasareabazei de date ın Google Cloud, astfel doar o aplicatie din acelasi proiect cu baza dedate o poate accesa sau accesarea ei se mai poate face pe baza de IP. De asemenea,partea de autentificare si autorizare ın aplicatie se face prin autentificarea cu contulde Google care se realizeaza cu ajutorul protocolului OAuth 2.0. Pentru transportuldatelor de la server la client (browser-ul utilizatorului) se foloseste modulul SpringSecurity care autorizeaza partea de AngularJS sa faca cereri catre back-end pe bazaunui token.

7. Recuperarea este proprietatea sistemului de a-si reveni dupa un atac sau un esec.Trebuie tot timpul luat si acest lucru ın calcul, astfel se iau ın considerare timpul derestore si timpul de backup.

2.3 Cerinte de resurse

Pentru dezvoltarea unui sistem ca cel descris anterior, va fi nevoie de urmatoareleresurse:

1. Eclipse IDE - acesta pune la dispozitie un mediu de scriere a aplicatiilor ın Javaoferind avantaje precum detectarea erorilor de sintaxa sau chiar de logica.

2.3. CERINTE DE RESURSE 7

2. Workbench 6.3 - acest IDE este folosit pentru manipularea bazelor de date.

3. Java Development Kit: jdk 1.8 - acesta contine toate ustensilele necesare pentrua proiecta, compila si rula aplicatii dezvoltate ın Java.

4. Framework-ul Spring - datorita nivelului foarte ridicat de abstractizare, a bib-liotecilor multiple si diverse si a integrarii foarte usoare cu alte tehnologii existente,acest framework faciliteaza dezvoltarea rapida a aplicatiilor. De asemenea ofera siun server Apache Tomcat built-in pentru lansarea aplicatiei.

5. Apache Maven - folosit pentru build automation. Acesta este un instrument foarteputernic de administrare a bibliotecilor si este folosit ın construirea proiectelor (lacompilare), la includerea automata a dependentelor si pentru documentatie.

6. Contul de Google - este necesar pentru a crea un proiect ın Google Cloud sipentru a putea crea instantele de SQL. De asemenea, este necesar si pentru a obtinecredentialele de folosire pentru toate API-urile mentionate ın acesta lucrare.

7. BitBucket - instrumentul folosit pentru versionarea si pastrarea sigura a codului.

Capitolul 3

Studiu Bibliografic

3.1 Dezvoltarea aplicatiilor web

O aplicatie web este definita ca un program care ruleaza pe o arhitectura client-server, folosindu-se de tehnologiile si browserele web pentru a furniza diferite servcii saupentru a ındeplini anumite sarcini. WWW (World Wide Web) a ınceput cu aplicatiiasincrone (Web 1.0), care nu interactionau deloc cu utilizatorul. Pe masura ce timpul atrecut, s-au dezvoltat o multitudine de tehnologii si framework-uri pentru ca aplicatiileweb sa devina tot mai responsive fata de utilizator si chiar sa primeasca informatii de lautilizatorii care nu sunt umani (smart gadgets). Asa s-a ajuns azi la Web 4.0, denumit siInternet of Things.

Figura 3.1: Interactiunea componentelor unei aplicatii web [9]

Pentru utilizator, o aplicatie web nu este nimic altceva decat o interfata prin care

8

3.2. APLICATII COLABORATIVE 9

are acces la niste resurse sau prin care manipuleaza resursele respective. In schema de maisus se prezinta o vedere de ansamblu a interactiunii ıntre client si server.

Serverul de web plaseaza un fisier numit WAR (Web Application Resource) sub uncontent root adica o radacina URL. Cererile care vin catre server sunt redirectionate catreresursele corespunzatoare, mai apoi returnandu-se un raspuns corespunzator cererii sauun mesaj de eroare ın caz ca cererea s-a finalizat cu esec. Resursele se ımpart ın douacategorii:

1. statice (imagini sau pagini HTML)

2. dinamice (clase JSP sau servleturi)

Din fericire, pe masura ce timpul a trecut, s-au dezvoltat o multitudine de framework-uri pentru diverse limbaje de programare web, care abstractizeaza toate aceste configurarila niveluri foarte ınalte din stiva de referinta ISO/OSI. Daca ın trecut se lucra la niveluri deretea (Network Layer) sau transport (Transport Layer), ın prezent, datorita abstractizarii,se lucreaza la nivelul de Prezentare (Presentation Layer) sau chiar la nivelul de Aplicatie(Application Layer). Deoarece se lucreaza la niveluri atat de ınalte, aceste configurari suntinvizibile pentru programator, totul reducandu-se la niste simple apeluri de functii.

Atunci cand se dezvolta o aplicatie web, cele mai importante cerinte non-functionalesunt scalabilitatea, securitatea si rezistenta la esec. Aplicatia trebuie sa fie scalabila ınresurse pentru a putea sustine o crestere brusca si consistenta de utilizatori. Securitateaeste obligatorie si vitala pentru utilizator si ın consecinta datele acestuia trebuie protejateiar ın acest domeniu, criptografia a evoluat foarte mult. De asemenea, la fel ca si scala-bilitatea si securitatea, esecul trebuie luat ın considerare. O aplicatie web poate esua, daracest lucru trebuie ascuns fata de utilizator prin afisarea de mesaje adecvate. Probabili-tatea ca o aplicatie sa esueze se poate diminua prin luarea masurilor de securitate adecvatesi stabilirea corecta a cerintelor non-functionale ınca de la proiectarea de ansamblu a apli-catiei.

3.2 Aplicatii colaborative

O aplicatie colaborativa este o aplicatie software proiectata pentru a ajuta per-soanele implicate intr-o sarcina comuna sa-si atinga obiectivele. Una dintre cele mai vechidefinitii pentru software-ul colaboriva este: ”lucrul in grup plus softoware pentru suport”(en. ”intentional group processes plus software to support them”) [7].

In ceea ce priveste nivelul de interactiune pe care aplicatiile colaborative le suporta,acestea pot fi impartite in Platforme de Editare in Timp Real (RTCE - real-time collabo-rative editing) si programe de versionare (version control) care permit editarea unui fisierde catre utilizatori intr-un mod paralel [7].

Adeseori, pentru aplicatiile colaborative se foloseste termenul de CSCW care vinede la Computer Supported Cooperative Work. Termenul de CSCW a fst dat in 1984 de

10 CAPITOLUL 3. STUDIU BIBLIOGRAFIC

catre Irene Greif si Paul M. Cashman la un workshop pentru crearea tehnologiei in a ajutaoamenii sa finalizeze anumite sarcini.

Arhitectura unei astfel de aplicatii ne indica care parti ruleaza ıntr-un mod centra-lizat si anume pe un server si care parti ruleaza descentralizat, dar conectate totusi ıntreele prin legaturi logice. Exista trei categorii pentru arhitectura unui sistem colaborativ[5], si anume:

1. Arhitectura centralizata - ın aceasta, colaborarea este administrata de un servercentral si este exact arhitectura de tip client-server.

2. Arhitectura replicata - colaborarea este sustinuta de toti utilizatorii din retea sise mapeaza perfect pe arhitectura de tip peer-to-peer

3. Arhitectura hibrida - o parte din componente ruleaza centralizat, ın timp ce altelesunt sustinute de toti utilizatorii din retea.

Sistemele de tip CSCW se pot clasifica in functie de doi factori [6], si anume:

1. Factorul temporal. Caracteristica cea mai importanta a sistemelor colaborativeeste, indiscutabil, timpul. Astfel, pot exista 4 categorii de colaborari:

� Colaborarea sincronizata: are loc ıntr-o maniera structurata, iar utilizatoriicomunica ın acelasi timp (exemplu: sistemele de chat)

� Colaborarea nesincronizata: are loc cand utilizatorii lucreaza ımpreuna dartotusi separati complet unul fata de celalalt. Colaborarea are loc doar cando cere utilizatorul, altfel toata munca depusa nu afecteaza ceilalti colaboratori(exemple: forumurile sau sistemele de versionarea a codului, cum ar fi Git sauBitBucket).

� Colaborarea mixta poate fi atat sincronizata cat si nesincronizata. (exemplu:Mesageria Facebook: daca ambii utilizatori sunt on-line atunci colaborarea estesincronizata, iar daca unul dintre ei este off-line atunci colaborarea este asin-crona deoarece el va primi mesajul cand se va autentifica ın aplicatie)

� Colaborarea seriala are loc cand un utilizator trebuie obligatoriu sa faca oanumita actiune ınainte ca un alt utilizator sa poata sa ısi continue munca.(exemplu: sistemele de e-mail)

2. Factorul spatial. Acesta poate fi de doua feluri:

� Colaboratorii se afla ın acelasi loc (Same place)

� Colaboratorii se afla ın locuri diferite (Different place)

Conform sursei [5] cele mai relevante avantaje ale aplicatiilor colaborative sunturmatoarele:

3.3. APLICATII COLABORATIVE EXISTENTE 11

� faciliteaza comunicarea si anume o face mai rapida si mai clara

� permite comunicarea acolo unde altfel nu ar fi fost posibila

� reduce costurile de transport

� aduce ımpreuna multiple concepte si perspective de la diversi oameni si ıncura-jeaza oamenii sa ısi expuna ideile. Se dezvolta abilitatile de comunicare si de lucruın echipa, responsabilitatea, capacitatea de adaptare, creativitatea dar si gandireacritica si sistematica.

� aduce ımpreuna oameni care au interese comune si care altfel nu s-ar fi ıntalnitniciodata fata ın fata

� reduce timpul si costurile de coordonare a lucrului ın grup

� ıncurajeaza gandirea si rezolvarea problemelor ın comunitati

� permite noi metode de comunicare cum ar fi ınteractiunile anonime sau structurate

In ultimii ani sistemele IT colaborative au evoluat foarte mult, indiferent ca aces-tea se folosesc ıntre indivizi sau ıntre companii. Aceasta evolutie se datoreaza ın mareparte avansului tehnologic si ieftinirii tehnologiei, dar si multiplelor avantaje introdusede sistemele colaborative. Aceste sisteme au un impact ın mai multe domenii, cele maiimportante fiind: sistemele distribuite, comunicarea om-calculator, inteligenta artificiala,management si chiar si ın sociologie.

3.3 Aplicatii colaborative existente

O mare parte din aplicatiile din ziua de azi sunt considerate sisteme colaborative.Mai jos sunt prezentate cateva aplicatii colaborative dezvoltate de companii de renume:

Adobe Acrobat Acest utilitar ofera posibilitatea de revizuire sincrona sau asincrona afisierelor de tip PDF de catre mai multi utilizatori. Recent, Adobe a introdus si posibili-tatea de stocare ın cloud a fisierelor.

Atlassian Tools Atlassian ofera diferite aplicatii web bazate pe coceptul colaborativ,cele mai cunoscute fiind sistemul Jira de tracking si administrare a proiectelor si sistemulBitBucket de versionare a codului care este folosit pentru acest proiect.

Google Docs, Sheets si Slides este un serviciu de tip SaaS (Software as a Service)de stocare a fisierelor ın Cloud si dezvoltat de Google. De asemenea, permite editarea ınparalel a fisierelor de catre utilizatori.

Capitolul 4

Analiza si Fundamentare Teoretica

In acest capitol va fi prezentata arhitectura conceptuala a aplicatiei implementatesi interactiunea logica a pachetelor care reflecta arhitectura. De asemenea, vor fi descrisepe scurt tehnologiile, serviciile de cloud de la Google, API-urile de la Google, framework-urile de front-end si de back-end folosite pentru implementarea si dezvoltarea aplicatiei.Mai mult, vor fi motivate alegerile facute asupra acestora prin sublinierea avantajelor sidezavantajelor fiecareia ın contextul dat.

4.1 Arhitectura conceptuala

Dupa cum se poate vedea si ın imaginea urmatoare, arhitectura sistemului estestructurata ın doua parti: partea de front-end (adica clientul) reprezentata de framework-ul AngularJS si partea de back-end (adica serverul) reprezentata prin framework-ul Spring.

Cele doua formeaza o arhitectura de tip Client-Server iar ın interiorul fiecareia seidentifica o arhitectura de tip Layers.

Partea de aplicatie ın AngularJS comunica cu partea de server reprezentata deSpring prin obiecte de tip JSON (JavaScript Object Notation). Aceste obiecte JSONau o sintaxa care permite schimbul de date si respectiv stocarea lor. Nivelul de serviciimapeaza cererile folosite pentru server ın functii JavaScript pentru a putea fi folosite decatre celelalte niveluri. Nivelul urmator, cel de controllers, foloseste functiile din nivelulde servicii, trateaza cazurile ın care cererea catre server s-a facut cu succes sau, din contra,au aparut erori si trimite datele catre nivelul de views. Nivelul de views contine paginile ınformat HTML, care folosesc controller-ele Angular pentru a afisa date sau pentru a trimitedate catre nivelul superior.

Framework-ul de JavaScript adauga functionalitate paginii HTML prin niste atributiinumite directive. Aceste directive sunt niste extensii a DOM-ului sub forma de atributecare au prefixul data-ng- si care sunt incluse ın tag-urile HTML ale paginii.

12

4.1. ARHITECTURA CONCEPTUALA 13

Figura 4.1: Arhitectura conceptuala a aplicatiei

14 CAPITOLUL 4. ANALIZA SI FUNDAMENTARE TEORETICA

Prin nivelul de controllers din Spring se creaza servicii de tip REST care sunt mapateın nivelul de servicii din AngularJS prin URL si sunt apelate prin protocolul HTTP. Acesteservicii REST apeleaza functii din nivelul de services ın care se realizeaza atat operatiilede CRUD asupra datelor cat si operatii mai complexe. La randul lui, nivelul de servicesfoloseste functii din nivelul de repositories care mapeaza tabelele din baza de date pe claseledin nivelul entities si faciliteaza comunicarea cu baza de date.

Luand ın considerare factorii de spatiu si timp a sistemelor colaborative discutatiın capitolul anterior, aplicatia care se doreste a fi implementata va fi:

� sincrona pentru partea care va contine sistemul de chat, autentificarea, propunereasau alegerea unui wish, comentarii/review-uri si partea de administrator.

� asincrona petru restul cerintelor functionale, adica algoritmul de matching si noti-ficarile

� aplicatie de tip different place deoarece nu este nevoie ca utilizatorii sa fie ın acelasiloc pentru a folosi aplicatia.

Din punct de vedere al arhitecturii, aplicatia are o arhitectura hibrida deoarece sis-temul de chat formeaza o arhitectura replicata, sustinand comunicarea ıntre doi utilizatori,ın timp ce restul aplicatiei are o arhitectura centralizata.

4.2 Cazuri de utilizare

Cazurile de utilizare sunt o perspectiva globala asupra comportamentului si function-alitatilor oferite de aplicatie. Cerintele functionale ale sistemului pot fi translatate ın cazuride utilizare. Aceste cazuri de utilizare pot fi ımpartite ın functie de rolurile utilizatorilorın sistem.

Astfel, ın acest sub-capitol se vor prezenta actorii, diagramele cazurilor de utilizaresi analiza catorva scenarii relevante.

4.2.1 Actori

Cei doi actori posibili pentru acest sistem sunt:

1. Utilizatorul - acesta este un simplu utilizator al aplicatiei. Acesta are posibilitateade a naviga pe paginile nerestrictionate ale aplicatiei si de a folosi serviciile oferitede sistem.

2. Administratorul - are rolul de a superviza activitatea aplicatiei. Acesta modereazareview-urile si wish-urile noi introduse de catre user ın sistem, cat si blocarea saudeblocarea unui utilizator. De asemenea, acesta va avea posibilitatea de a da drepruriın plus unui utilizator obisnuit prin transformarea lui ıntr-un administrator sau, dincontra, revocarea lui.

4.2. CAZURI DE UTILIZARE 15

4.2.2 Scenarii si diagramele cazurilor de utilizare

Utilizatorul

Mai jos este prezentata diagrama cazurilor de utilizare pentru utilizatorul obisnuit:

Figura 4.2: Diagrama cazurilor de utilizare pentru utilizatorul obisnuit

CU1:

� Numele cazului de utilizare: Autentificarea cu contul de Google

� Actor principal: Utilizatorul

� Preconditii:

1. Utilizatorul detine un cont de Google

2. Utilizatorul se afla pe pagina de autentificare

� Postconditii:

1. Utilizatorul va fi ınregistrat ın baza de date a sistemului, ın cazul ın care acestaeste un utilizator nou.

� Scenariul principal (de succes):


1. Utilizatorul apasa butonul de autentificare cu contul de Google

2. Utilizatorul este redirectionat catre site-ul Google

3. Pe aceasta pagina, utilizatorul ısi introduce adresa de e-mail Google si parola

4. Google autorizeaza aplicatia DIB de a accesa datele utilizatorului

5. Utilizatorul este redirectionat catre UserPannel

� Scenarii alternative:

1. Utilizatorul nu are conexiune la internet

2. Datele introduse sunt eronate

3. Serverul Google nu este accesibil dintr-un oarecare motiv

4. Serverul aplicatiei nu este disponibil dintr-un oarecare motiv

5. Google nu autorizeaza aplicatia DIB de a accesa datele utilizatorului

CU2:

� Numele cazului de utilizare: Efectuarea unei conexiuni ıntre utilizatori

� Actor principal: Utilizatorul

� Preconditii:

1. Utilizatorul este autentificat ın aplicatie

2. Utilizatorul se afla pe pagina corespunzatoare

� Postconditii:

1. Uitilizatorul va fi conectat cu alti utilizatori


1. Utilizatorul apasa butonul de Connections din meniu

2. Serverul va cauta daca exista alti utilizatori care au cel putin un wish comuncu acesta

3. Serverul va cauta daca utilizatorii gasiti au intervale de timp liber ca si utiliza-torul principal

4. Serverul va cauta daca acesti utilizatori se afla la o distanta mai mica de 50 KMfata de utilizatorul principal

5. Serverul returneaza o lista de conexiuni posibile

6. Utilizatorul alege cu cine vrea sa se conecteze

4.2. CAZURI DE UTILIZARE 17


1. Utilizatorul nu are conexiune la internet

2. Nu sunt gasiti utilizatori compatibili cu utilizatorul principal

CU3:

� Numele cazului de utilizare: Utilizatorii comunica ıntre ei printr-un sistem dechat

� Actori principali: Utilizatorii

� Preconditii:

1. Utilizatorii sunt autentificati ın aplicatie

2. Utilizatorii au format o conexiune

� Postconditii:

1. Utilizatorii vor comunica printr-un sistem de chat


1. Utilizatorii se afla pe pagina de chat

2. Serverul deschide o conexiune de tip sockets

3. Utilizatoruii ıncep sa scrie mesaje


1. Utilizatorii nu au conexiune la internet

2. Serverul esueaza ın a deschide o conexiune de sockets

Administratorul

In figura 4.3 de mai jos se pot observa actiunile posibile pe care le poate face admin-istratorul. In cazul lui, se va prezenta ın detaliu doar un singur caz de utilizare, deoareceacestea seamana ıntre ele, iar procesul de autentificare este asemenea utilizatorului obis-nuit, singura diferenta fiind ca administratorul este redirectionat catre AdminPannel.


Figura 4.3: Diagrama cazurilor de utilizare pentru administrator

CU1:

� Numele cazului de utilizare: Moderare reviews

� Actor principal: Administratorul

� Preconditii:

1. Administratorul detine un cont cu rolul de administrator

2. Administratorul se afla pe pagina de moderare a review-urilor

� Postconditii:

1. Review-urile vor fi aprobate sau nu


1. Serverul returneaza catre browser o lista cu review-uri

2. Lista este afisata sub forma de tabel ın browser

3. Administratorul alege una dintre actiunile approve, reject sau pending

4. Modificarea este trimisa catre server

5. Statusul review-ului se schimba ın browser


1. Administratorul nu are conexiune la internet

2. Serverul aplicatiei nu este disponibil dintr-un oarecare motiv

4.3. API-URI GOOGLE 19

4.3 API-uri Google

4.3.1 Google Sign-in cu Google+ bazat pe protocolul OAuth 2.0

OAuth 2.0

OAuth 2.0 este protocolul standard pentru autorizarea accesului sau pentru a permiteaplicatiilor un acces limitat la conturile utilizatorilor pe baza serviciilor HTTP. La ora actu-ala sunt multe companii care pun la dispozitie astfel de servicii, ca de exemplu: Facebook,Google sau GitHub.

OAuth 2.0 are patru roluri:

1. Resource Owner - acesta este user-ul care autorizeaza aplicatia pentru a-i accesacontul. Aplicatia este limitata ın acces ın functie de scopul (scope) setat si anumeread sau write.

2. Client - reprezentat de aplicatia care doreste sa acceseze datele din contul utiliza-torului si care cere autorizare pentru asta

3. Resource Server - tine datele din contul utilizatorului

4. Authorization Server - verifica identitatea utilizatorului iar apoi emite un access tokecatre aplicatie

Protocolul se desfasoara ın sase pasi (figura 4.4):

1. Aplicatia cere autorizarea accesului la resursele utilizatorului

2. Utilizatorul autorizeaza cererea, iar aplicatia primeste un acord pentru autorizare(authorization grant)

3. Aplicatia cere un token de acces de la Authorization Server prin prezentarea iden-titatii proprii si a acordului de autorizare

4. Daca identitatea aplicatiei este autentificata si acordul de autorizare este valid, Au-thorization Server va emite un token de autorizare catre aplicatie. Autorizarea estefinalizata.

5. Aplicatia cere resursele de la Resource Server si ıi prezinta tokenul de acces.

6. Daca tokenul de acces este valid, atunci Resource Server va furniza resursele cerutecatre aplicatie.


Figura 4.4: Pasii protocolului OAuth 2.0 [10]

Google Sign-in

Deoarece aceasta aplicatie va fi dezvoltata prin tehnologiile Google, autentificarea uti-lizatorului ın aplicatie se va face printr-un cont de Google+ cu ajutorul email-ului uti-lizatorului primit de la Google. Autentificarea cu Google se face automat prin protocolulOAuth 2.0, partile Authorization Server si Resource Server fiind deja implementate pepartea de Google. Authorization Server si Resource Server sunt invizibile pentru dezvolta-tor, ele formand un API ımpreuna.

Pentru a putea folosi acest serviciu, este nevoie de un cont valid de Google si deactivarea serviciilor de cloud. Dupa activarea serviciilor este necesara crearea unui proiectpentru care Google va da autorizatiile si de activarea taxarii acestui proiect. Pasul urmatore de a activa, ın cadrul proiectului creat, urmatoarele API-uri necesare procesului deautentificare:

� Gmail API

� Analytics API

� Google+ API

Dupa ce aceste API-uri au fost activate, aplicatia trebuie ınregistrata tot ın cadrulproiectului. Acest lucru se realizeaza specificand:

� Numele aplicatiei


� URL-ul aplicatiei (poate fi si un URL de localhost)

� URL-ul de redirectionare sau callback (la fel, poate fi si un URL de localhost)

Figura 4.5: Pasii pentru autentificarea cu Google [11]

Daca Google autorizeaza aplicatia, acesta va emite un Client ID si un Client Secretnumite si client credentials. Client ID este un string expus public si folosit de catre APIpentru a identifica aplicatia si pentru a construi URL-ul de autorizare care este prezentatutilizatorului, adica formularul de log-in ın care i se cere email-ul si parola contului deGoogle. Client Secret este folosit pentru a autentifica identitatea aplicatiei de catre APIatunci cand aplicatia cere acces pentru resursele din contul utilizatorului. Client Secrettrebuie pastrat privat ıntre aplicatie si API.

Dupa ce utilizatorul s-a logat folosind email-ul si parola contului de Google, apli-catia primeste un obiect de tip JSON care contine datele utilizatorului, cum ar fi: nume,prenume, limba, tara de provenienta, URL-ul catre poza de profil etc. Acest obiect de tipJSON este salvat ın Java ca Principal Object si este gasit sub pachetul java.security.Principal.

4.3.2 Google Calendars API

API-ul Calendar de la Google este un serviciu pentru programatori sub forma deAPI REST care poate fi accesat explicit prin apeluri clasice HTTP sau prin librariile puse


la dispozitie de catre Google. Acest API pune la dispozitie majoritatea functionalitatilora interfetei web a acestui serviciu.

Concepte de bazaFiecare utilizator este asociat cu un calendar principal si un numar (zero sau mai multe)

de alte calendare pe care le poate accesa. Utilizatorii pot crea evenimente (events) sipot invita (invite) alti utilizatori. Un utilizator poate partaja calendarul sau cu un altutilizator sau cu un grup de utilizatori. De asemenea, un utilizator poate participa la toateevenimentele din calendarele care sunt partajate cu el, cu conditia ca aceste evenimentesa fie setate ca fiind publice.

Resursele API-uluiCalendarele Google contin sapte resurse care pot fi accesate:

1. Events - Un eveniment din calendar contine informatii precum titlu, data si ora deınceput, data si ora de sfarsit si participanti. Evenimentele pot fi de doua feluri:evenimente singulare (care apar o singura data) si evenimente recurente (care serepeta de un numar de ori, la o perioada de timp stabilita de utilizator)Event col-lection este resursa din calendar care contine toate resursele de tip event pentru unanumit calendar.

2. Calendar - Acesta este definit ca o colectie de evenimente. Fiecare calendar areasociat metadate, ca de exemplu: fus orar sau o descriere. CalendarCollectionscontine toate resursele de tip calendar pentru toate calendarele existente.

3. Calendar List - Prin aceasta resursa se reprezinta o lista a tuturor calendarelor aunui utilizator. Pentru acesta resursa, metadata contine specificatii ın plus, ca deexemplu: culoarea sau notificarile pentru evenimentele noi. CalendarListCollectioncontine toate resursele de tipul calendar list pentru un anumit utilizator.

4. Setting - Aceasta resursa reprezinta o preferinta a utilizatorului, ca de exemplu:fusul orar a utilizatorului. O singura preferinta a utilizatorului reprezinta o sin-gura resursa setting. Setting collection contine toate resursele de tip setting ale unuiutilizator.

5. ACL - Access Control reprezinta o regula dupa care se ofera/garanteaza acces laun anumit calendar, unui utilizator sau unui grup de utilizatori. O singura regulade acces reprezinta o singura resursa ACL. ACL collection contine toate resursele detip ACL a unui calendar.

6. Color Aceasta resursa reprezinta un set de culori disponibile ımpartite ın douagrupuri: culori pentru evenimente si culori pentru calendare.


7. Free/Busy - Timpul pentru care a fost organizat evenimentul ıntr-un calendar esteconsiderat busy, iar timpul din calendar pentru care nu exista evenimente este consid-erat free. Aceasta resursa permite interogarea calendarului pentru perioadele liberesau ocupate ale unui utilizator.

Google Calendar API aduce un avantaj pentru implementarea acestui sistem, inprimul rand pentru ca are integrare cu framework-ul Spring. De asemenea permite cererilede tip REST si nu ın ultimul rand, ofera o serie de facilitati organizate ın resurse, usor deınteles si utilizat.

4.3.3 Google Maps Platform

Google Maps Platform este un serviciu pentru programatori. Acest serviciu fa-ciliteaza ıncorporarea hartilor Google ın pagini web si aplicatii mobile sau chiar extragereadatelor puse la dipozitie de Google Maps, ca de exemplu coordonatele utilizatorului.

Platforma se ımparte ın trei categorii, fiecare categorie cuprinzand mai multe API-uri, ın functie de nevoile aplicatiei care se doreste implementata:

1. Maps

� Maps JavaScript API

� Maps SDK for Android

� Maps SDK for iOS

� Maps Static API

� Street View API

� Maps URLs

� Maps Embed API

2. Routes

� Directions API

� Distance Matrix API

� Roads API

3. Places

� Places API

� Places SDK for Android

� Places SDK for iOS

� Places Library, Maps JavaScript API


� Geocoding API

� Geolocation API

� Time Zone API

Pentru aceasta implementare s-a ales Maps JavaScript API din categoria Maps.

Maps JavaScript APIAcest API permite customizarea hartilor cu continutul dorit si afisarea grafica a hartilor

pe paginile web. Acest lucru se realizeaza prin apelarea unui URL specificat ın documen-tatia Maps JavaScript API, folosindu-ne de un API Key, ca ın exemplul de mai jos:

1 <s c r i p t async de f e r2 s r c=”https : //maps . g oog l e ap i s . com/maps/ api / j s ?key=YOUR API KEY&ca l l ba ck=

initMap ”>3 </ s c r i p t>

Fragmentul de cod 4.1: Apelarea Maps JavaScript API folosind un API Key

Pentru a obtine un API Key este nevoie de a activa Maps API din Google CloudPlatform Console. Pasul urmator e de a cere o cheie pentru acest API din meniul Creden-tials.

S-a ales acest API deoarece este foarte bine documentat cu exemple, este usor defolosit, este ın continua dezvoltare si ofera toate functionalitatile necesare aplicatiei carese doreste a fi implementata si anume:

� preluarea coordonatelor din browserul utilizatorului

� plasarea utilizatorilor conectati pe harta

� afisarea hartilor ın browser

4.4 Google Cloud Platform

GCP este o colectie de computere, hard-disk-uri si masini virtuale, toate acesteafiind organizate ın centre de date Google. Aceasta distributie a resurselor ofera mai multebeneficii, inclusiv redundanta ın caz de esec si reducerea latentei prin localizarea resurselormai aproape de client.

Serviciile oferite de Google pentru cloud computing s-au imbunatatit si inmultit pemasura ce anii au trecut, ın prezent oferind servicii de stocare, compute, networking siBigData.

Pentru a putea accesa aceste servicii este nevoie de un cont Google valid si activareafacturarii pe acest cont prin furnizarea unui card bancar.

Serviciile oferite de GCP au caracteristica de ”pay per use” si anume, clientul platesteın functie de cate resurse foloseste.

4.5. TEHNOLOGIILE DE SERVER 25

Din aceasta platforma s-au ales serviciile de Cloud SQL si serviciul de Credentialspentru obtinerea si administrarea cheilor API necesare pentru autentificarea cu contul deGoogle a utilizatorului si pentru accesarea Maps JavaScript API.

4.4.1 Google Cloud SQL

Google Cloud SQL este un serviciu web care permite operarea bazelor de dateMySql. Bazele de date stocate ın Cloud SQL pot fi accesate de aplicatii gazduite peGoogle Compute Engine sau Google App Engine si de catre aplicatii externe prin IP sauSSL.

Pentru aplicatia descrisa anterior s-a ales acest serviciu pentru stocarea bazei dedate deoarece:

� toate datele stocate ın Cloud SQL se cripteaza automat

� datele ın-transit sunt, de asemenea, criptate automat

� se cere autorizarea explicita a clientului pentru orice conexiune care nu este trecutaın lista de autorizari

� ısi face cate o replica/back-up automat de doua ori pe zi

� este scalabila

4.5 Tehnologiile de server

In continuare, se vor descrie pe scurt tehnologiile care au fost folosite pentru parteade server, modul ın care ele se ımbina si motivele pentru care acestea au fost alese

4.5.1 Serviciile REST

REST este un acronim pentru Representation State Transfer si este un stil arhi-tectural. Prin tehnologia REST se face posibila proiectarea unor servicii web orientatepe resursele disponibile din sistem si de asemenea, face posibila accesarea acestor resurseprin intermediul protocolului HTTP. Fata de serviciile web SOAP sau RPC, REST reducefoarte mult complexitatea.

Arhitectura REST este construita sub forma arhitecturii Client-Server. Prin folosireaserviciilor web de tip REST, Clientul are acces la resurse prin accesarea unui URI(Uniform Resources Identifiers). Resursele pot avea diferite formate, ca de exemplu:plain text, XML, media, dar cel mai folosit format ın ziua de azi este JSON. DeoareceREST comunica prin protocolul HTTP, resursele sunt accesate prin metode HTTP, celemai uzuale fiind:

� GET - metoda HTTP folosita pentru a accesa o resursa de pe server


� POST - metoda HTTP folosita pentru a crea o noua resursa pe server sau pentru aactualiza o resursa existenta de pe server

� DELETE - metoda HTTP folosita pentru a sterge o resursa de pe server

O parte din cele mai importante avantaje a serviciilor REST sunt:

� este stateless

� ofera scalabilitate

� este mult mai simplu de folosit si ınteles fata de serviciile de tipul SOAP sau RPC

� fata de serviciile mentionate anterior, permite ca resursele sa aiba diferite formate(fata de SOAP, de exemplu, care permite doar formate XML), printre care si formatulJSON acesta fiind procesat mult mai rapid

� este performant

� este folosit de marile companii, ca de exemplu Google, Facebook sau Amazon. In-clusiv toate API-urile de la Google folosite pentru acest proiect sunt accesate princereri de tip REST

Pentru sistemul descris anterior, serviciile REST vor fi implementate prin inter-mediul controlerelor REST din framework-ul Spring. Aceste servicii REST vor fi apelatede clientul implementat ın framework-ul AngularJS prin serviciul predefinit $http.

4.5.2 Spring Framework

Spring este un framework open-source pentru dezvoltarea aplicatiilor ın Java. Acestaeste un container simplu IoC (Inversion of Control) bazat pe injectarea dependentelor (”De-pendency Injection”) si care promoveaza dezvoltarea bazata pe POJO-uri (Plain Old JavaObjects). Framework-ul Spring este structurat ın mai multe module:

Deoarece Spring se bazeaza pe cuplarea slaba a modulelor, acestea pot fi folositeindependent unele fata de altele. Pentru acest sistem s-au folosit urmatoarele:

� Spring Boot foloseste un model complet nou de dezvoltare a aplicatiilor complexe.Mai mult, deoarece evita anumiti pasi de configurare, procesul de dezvoltare a apli-catiei este mult mai rapid.

� Spring Security este un modul extrem de puternic ın ceea ce priveste autentificareasi controlul accesului. Ofera integrari cu mai multe protocoale de securitate, printrecare si OAuth 2.0, care este folosit pentru implementarea acestui sistem.

4.5. TEHNOLOGIILE DE SERVER 27

� Spring Data JPA ofera o modalitate consistenta de acces la date prin intermediereaoperatiilor asupra bazei de date. De asemenea, acest modul al Spring Boot, oferasi functionalitati de generare a bazei de date pe baza claselor sau de mapare a uneibaze de date existente pe clasele din modelul orientat pe obiect si chiar de validarea schemelor bazelor de date.

S-a ales framework-ul Spring pentru implementarea acestei aplicatii deoarece oferalibrarii gata implementate pentru Google Cloud, este compatibil cu Hibernate si are modulede securitate incluse.

4.5.3 WebSockets

WebSockets este un protocol definit ca si o comunicare bidirectionala (full duplex)intre clienti si servere, ceea ce inseamna ca ambele parti comunica si efectueaza schimb dedate in acelasi timp. Deoarece comunicarea full duplex intre clienti si servere se realizeazaprintr-o singura conexiune TCP, websockets se bazeaza pe conceptul de handshake.

Acest protocol standardizat a fost proiectat pentru ca browserele web sa poatacomunica cu serverul sau alti clienti fara a fi nevoie de a deschide mai multe conexiuni.Avantajul acestui protocol este ca poate sa tina deschis canalul de comunicare intre serversi client (browserul) pana cand una dintre parti decide sa inchida conexiunea.

Protocolul WebSockets a fost ales pentru a implementa sistemul de chat al aplicatieideoarece este simplu de folosit datorita librariilor de integrare din Java.

4.5.4 Hibernate

Hibernate ORM este un framework care ajuta la obtinerea persistentei ın bazele dedate. Hibernate mapeaza bazele de date orientate pe obiect (ODBMS) pe bazele de daterelationale (RDBMS), mai exact clasele entitati definite ın Java vor fi ın stransa legaturacu tabelele din baza de date MySQL, persistenta observandu-se ın faptul ca o operatiefacuta ın Java se va reflecta ın baza de date ıntr-un mod persistent dincolo de durata deviata a JVM-ului (Java Virtual Machine).

Hibernate se foloseste de POJOs (Plain Old Java Objects) care ımpreuna cu fisierelede mapare asigura comunicarea cu baza de date. Termenul de Plain Old Java Objects serefera la clasele simple din Java care nu au rol de business si sunt folosite doar ca entitati.

Astfel, Hibernate permite mapari flexibile ıntre obiectele din Java prin fisiere detip XML sau, mai nou, prin adnotari. Pentru acest sistem, se foloseste maparea cu ad-notari, deoarece astfel configurarile se fac automat si sunt invizibile pentru dezvoltator, iaradnotarile sunt intuitive ca de exemplu: @Table, @Column, s.a.m.d.

4.5.5 Server-ul Tomcat

Serverul Apache Tomcat este un server HTTP si deci functioneaza conform modelu-lui request-replay. Acesta este un container servlet de Java open-source pentru aplicatiile


web, el avand o arhitectura modulara.Tomcat implementeaza cateva concepte specifice Java EE, ca de exemplu Java

Servlets, Java Server Pages (JSP) sau WebSockets. Arhitectura serverului Tomcat estestructurata pe mai multe niveluri si anume (de sus ın jos): nivelul de cluster, nivelulcontext, nivelul de gazduire si nivelul motor.

S-a ales Apache Tomcat pentru aceasta aplicatie deoarece este deja integrat ınSpring Boot si deci nu necesita configurari si pentru ca ofera un mediu HTTP pur Java.

4.5.6 Maven

Maven este un utilitar foarte puternic de automatizare pentru includerea depen-dentelor si pentru documentare, ın mare parte folosit pentru Java. Acest utilitar se bazeazape conceptul de POM (ProjectObject Model). POM este un fisier XML care centralizeazainformatia, ca mai apoi, pe baza lui sa se poata construi, compila, raporta si documentaproiectul ın cauza.

Maven se desfasoara ın doua etape si anume:

1. descrie modul ın care softul este construit (ın exemplul de mai jos este jar)

2. descrie dependintele acestuia si le include automat fara sa fie nevoie de interventiaumana. Acest lucru se realizeaza prin tag-urile <parent> si <dependency>. In tag-ul <plugin> se specifica care versiune de Maven se executa, ın exemplul de jos fiindvorba de versiunea pentru Spring Boot, dar exista si alte alternative (de exemplu,pentru lansarea aplicatiei pe Google Cloud, exista o versiune de Maven specializatapentru asta).

1 <?xml ve r s i on=”1 .0 ” encoding=”UTF−8”?>2 <p ro j e c t xmlns=”ht tp : //maven . apache . org /POM/4 . 0 . 0 ”3 xmlns :x s i=”ht tp : //www.w3 . org /2001/XMLSchema−i n s t anc e ”4 xs i : s chemaLocat ion=”ht tp : //maven . apache . org /POM/4 . 0 . 0 h t tp : //maven .

apache . org /xsd/maven−4 . 0 . 0 . xsd ”>5 <modelVersion>4 . 0 . 0</modelVersion>6

7 <groupId>app . dib</groupId>8 <a r t i f a c t I d>dib</ a r t i f a c t I d>9 <ve r s i on>0.0.1−SNAPSHOT</ ve r s i on>

10 <packaging>j a r</packaging>11 <name>dib</name>12 <d e s c r i p t i o n>This i s ”Do I t Better ” Pro j e c t</ d e s c r i p t i o n>13 <author>Pop Laura−Maria</ author>14 <parent>15 <groupId>org . springframework . boot</groupId>16 <a r t i f a c t I d>spr ing−boot−s t a r t e r−parent</ a r t i f a c t I d>17 <ve r s i on>2 . 0 . 1 .RELEASE</ ve r s i on>18 <r e l a t i v ePa th /> < !−− lookup parent from r epo s i t o r y −−>19 </ parent>

4.6. TEHNOLOGIILE DE CLIENT 29

20 <dependenc ies>21 <dependency>22 <groupId>org . springframework . boot</groupId>23 <a r t i f a c t I d>spr ing−boot−s t a r t e r−web</ a r t i f a c t I d>24 </dependency>25 < !−−−some other dependenc ies here−−>26 <dependenc ies>27 <bu i ld>28 <p lug in s>29 <plug in>30 <groupId>org . springframework . boot</groupId>31 <a r t i f a c t I d>spr ing−boot−maven−plug in</ a r t i f a c t I d>32 </ p lug in>33 </ p lug in s>34 </ bu i ld>35 </ p r o j e c t>

Fragmentul de cod 4.2: Exemplu de pom.xml

Am ales Maven ca si sistem de automatizare a includerii dependintelor si a compilariideoarece urmeaza niste standarde, este open-source, are o comunitate mare si este simplude utilizat. De asemenea, ofera o structura consecventa si consistenta a proiectului ceeace face modificarile ulterioare mai usor de obtinut.

4.6 Tehnologiile de client

4.6.1 AngularJS

AngularJS este un framework open-source dedicat pentru front-end si se bazeaza ınıntregime pe JavaScript. In mare pare, AngularJS, este mentinut de Google.

Prin acest framework structural pentru aplicatii web, se permite utilizarea coduluiHTML ca si un template ce poate fi extins, folosindu-se de sintaxele speciale de tipul ”data-ng-”. Prin AngularJS se poate manipula DOM-ul (Document Object Model) documentuluiHTML, fara a fi nevoie de interventia propriu-zisa a dezvoltatorului.

AngularJS are o arhitectura MVW si anume Model-View-Whatever, unde What-ever poate ınsemna Controller, Directive sau Unit Test. Prin acest pattern customizat sepermite o interpretare si structurare mult mai flexibila a aplicatiei.

AngularJS are cateva caracteristici principale:

� Rutare - reprezinta conceptul de tranzitie ıntre view-uri si de a asocia un controllerunui view.

� Directive - sunt atributele ce se insereaza ın tag-urile HTML. La nivel de detaliu,directivele sunt markere pentru elementele din DOM, iar prin acestea se personal-izeaza documentul HTML. AngularJS dispune de numeroase directive predefinite:data-ng-app, data-ng-show, data-ng-if, s.a.m.d.


� Data Binding - reprezinta sincronizarea automata a datelor dintre model si view

� Servicii - sunt obiectele din cadrul aplicatiei client care sunt instantiate o singuradata (dar pot fi folosite ın multiple parti) si ofera anumite servicii, cel mai cunoscutfiind $http prin care se apeleaza serviciile REST de pe partea de server. Serviciul$http este unul predefinit, dar dezvoltatorul are posibilitatea de a-si crea propriileservicii customizate.

� Controller - este reprezentat de o functie ın JavaScript care este asociata unui anu-mit scope, care la randul lui este folosit ıntr-un anumit view. Controller-ul este unintermediar ıntre servicii si view-uri, el preluand date de la servicii si afisandu-le ınview sau preluand date din formularele din view si trimitandu-le la servicii ca maiapoi acestea sa ajunga pe server pentru a putea fi procesate.

� Filtre - sunt un set de atribute sau caracteristici care se aplica pe o lista. Dupaacest proces, rezulta o lista noua care contine doar obiectele care au atributele saucaracteristicile respective.

� Scope - obiectele care au declarat ca atribut scope pot fi vazute atat ın controller catsi ın view. Este folosit, ın principal, pentru a trimite datele de la controller la viewsi invers.

4.6.2 Bootstrap

Bootstrap este un framework de CSS pentru stilizarea mai rapida si mai usoara acodului HTML pentru pagini web prin specificarea unor valori pentru proprietatile vizualesi anume: font-color, border, padding, s.a.m.d.

Ideea care sta la baza acestui framework este ca ımparte pagina ın 12 coloane,elementele fiind mult mai usor de amplasat ın pagina. Aceste coloane au fost introdusepentru a rezolva problema ecranelor de mici dimensiuni, astfel existand cinci clase demarimi: xs (telefoane), sm (tablete), md (desktop-uri), lg si xl (desktop-uri cu rezolutiifoarte mari). De asemenea, Bootstrap pune la dispozitie si cateva teme gata facute pentrua usura procesul de stilizare si transformare a codului.

Acest framework a fost ales deoarece creste extrem de mult stilizarea paginilor,ofera un design placut, are elemente predefinite si prin adnotarile de tipul ” media queries”paginile devin responsive deoarece elementele se redimensioneaza si reaseaza ın pagina ınfunctie de marimea ecranului. Un alt factor important este ca Bootstrap este compatibilcu toate browserele moderne: Google Chrome, Mozilla, Internet Edge, Safari si Opera.

Capitolul 5

Proiectare de Detaliu siImplementare

In acest capitol se va descrie implementarea celor mai importante procese din sistemcat si fluxul de date ın aplicatie prin evidentierea diagramelor de clase, de deployment, depachete si cazurile de utilizare. De asemenea, se vor identifica actorii, se vor analiza catevascenarii si se va descrie baza de date. Mai mult, se vor explica maparea tehnologiilor pecomponentele sistemului si comunicarea ıntre aceste componente.

5.1 Arhitectura de detaliu

Pentru dezvoltarea acestui sistem s-au folosit pattern-urile arhitecturale Layers pen-tru a structura logica de implementare pe partea de server si MVC pentru partea de client.Sistemul este format din patru componente: serverul reprezentat de framework-ul Spring,clientul reprezentat de AngularJS, baza de date din Cloud SQL si API-urile Google.

In ceea ce priveste partea de server, se pot identifica patru layere din punct devedere logic: Entities care ofera date tuturor celorlalte 3 niveluri, Repositories apeleazabaza de date si ofera informatii nivelului de servicii, Services care se foloseste de nivelulde repositories pentru a face rost de date, prelucreaza aceste date si le ofera nivelului decontrollers, iar Controllers se foloseste de datele prelucrate de servicii si le trimite maideparte catre AngularJS prin expunerea unor servicii REST.

Componenta AngularJS formeaza aplicatia client. Prin intermediul acesteia se re-alizeaza apeluri de tip REST catre server pentru a afisa datele cerute de utilizator saupentru a procesa datele introduse de acesta. Arhitectura clientului este MVC si astfelModelul reprezinta starea aplicatiei si datele comunicate spre view de catre controller sauinvers prin directive sau direct. View ıncorporeaza paginile HTML si reprezinta partea deafisare si interpretare a expresiilor specifice AngularJS. Controllerul reprezinta logica decontrol si captarea evenimentelor. In controller se proceseaza datele ınainte de a fi trimisecatre server sau catre model.

31

32 CAPITOLUL 5. PROIECTARE DE DETALIU SI IMPLEMENTARE

A treia componenta care comunica cu serverul este baza de date din Cloud SQLPlatform, iar a patra componenta a sistemului o reprezinta API-urile de la Google caresunt apelate prin URL-uri configurate ın fisierele de setare pentru framework-ul Spring sauın variabile de configurare ın AngularJS.

Componenta Spring are nevoie de urmatoarele librarii pentru a putea functiona: de-pendinta pentru Spring Boot 2.0.1(se adauga ca si parent) - este ultima versiune de SpringBoot si libraria Starter Web care se foloseste pentru serverul built-in Apache Tomcat.In continuare, librariile Starter Security si Starter OAuth2 se folosesc pentru generareatoken-ului si autentificarea cu protocolul OAuth 2.0. Spring JPA este libraria care imple-menteaza metodele de comunicare si manipulare a bazei de date si este folosita ın claseledin pachetul dib.repo

5.1.1 Diagrama de pachete

In figura 5.1 de mai jos se evidenteaza fluxul de date ıntre pachetele aplicatiei careare loc ıntre sase pachete:

Figura 5.1: Diagrama de pachete

5.1. ARHITECTURA DE DETALIU 33

Tabelul 5.1: Descrierea componentelor pentru Spring (back-end)

Componenta Pachet Descriere

Repositories dib.repo Acest pachet contine repositories care facposibil accesul si operatiile pe baza de date

Entities dib.models Acest pachet reprezinta maparea proiectu-lui pe baza de date. Fiecare entitate dinbaza de date are un corespondent ıntr-o clasadin acest pachet si fiecare rand din baza dedate are un corespondent ıntr-un atribut dinaceste clase.

Services dib.services Acest pachet reprezinta layer-ul de businesslogic al aplicatiei. In clasele din acest pachetse efectueaza atat operatii de CRUD cat sioperatii mai complexe.

Controllers dib.controllers Acest pachet expune functionalitatile apli-catiei ıntr-un API astfel ıncat sa poata ges-tiona apelurile HTTP REST.

Pentru componenta AngularJS prin care s-a realizat interfata cu utilizatorul, seidentifica urmatoarele pachete:

Tabelul 5.2: Descrierea componentelor pentru AngularJS(front-end)

Componenta Pachet Descriere

Views views Contine paginile HTML ale aplicatiei.Aceste pagini sunt populate cu obiecteleJavaScript

Controllers controllers Contine obiectele JavaScript care populeazafisierele HTML din pachetul views cu rezul-tatele obtinute dupa apelul functiilor din pa-chetul services

Services services Contine scripturile de JavaScript care leagaaplicatia de front-end cu aplicatia de back-end. Acest lucru se realizeaza prin apeluriHTTP (obiectul $http in JavaScript).

5.1.2 Diagrama de clase

In figura 5.2 se evidentiaza legaturile intre clasele care tin de user, dar o diagramacompleta a claselor este prezentata in figura A.1 din Anexa A.


Figura 5.2: Diagrama de clase pentru User

Desi ın baza de date sunt opt tabele, ın pachetul dib.models exista doar sapteclase, deoarece prin frameworkul Hibernate tabelele care rezolva o relatie many to manysunt vazute ca un set de obiecte ın Java. Singura exceptie aici o face User Conversationdeoarece, pe langa cheile straine, contine si alte date care se doresc a fi manipulate.

Astfel, pentru fiecare entitate din baza de date, exista un cvintuplu de clase sianume clasa de tip POJO care reprezinta entitatile, clasa de repository, clasele de servicii:


interfata si implementare si clasa de controllere prin care se expun serviciile REST.Clasa User este folosita de toate celelalte, ea fiind o entitate si reprezentand maparea

pe baza de date. Deoarece este folosita de Hibernate pentru a mapa baza de date, claselede tip POJO implementeaza clasa Serializable din java.io.Serializable.

Aceasta clasa este recunoscuta de restul claselor si de Hibernate ca si entitate prinfolosirea adnotarilor de tip @Entity, @Table ın interiorul careia se specifica numele tabeleidin baza de date si adnotarea @Column ın interiorul careia se specifica numele campuluidin baza de date pe care il reprezinta. Prin adnotarile @Id si @Field se indica faptul caacea coloana este cheie primara ın tabela sau un simplu camp.

Pentru relatiile de one-to-many sau many-to-many se folosesc adnotarile speciale@OneToMany si @ManyToMany. Deoarece Hibernate foloseste obiectele de tip JSONpentru mapare, este nevoie de a specifica prin adnotarea @JsonManagedReference referintacatre campul de legatura din cealalta clasa, ın caz contrar, se va forma o bucla infinita deserializare ın obiectul de tip JSON.

1 @Indexed2 @Entity3 @Table (name = ”USER”)4 pub l i c c l a s s User implements java . i o . S e r i a l i z a b l e {5 pr i va t e s t a t i c f i n a l long ser ia lVers ionUID = 1L ;6

7 @Id8 @GeneratedValue ( s t r a t e gy = GenerationType . IDENTITY)9 @Column(name = ”u s e r i d ”)

10 pr i va t e long u s e r i d ;11

12 @Field13 @Column(name = ”family name ”)14 pr i va t e St r ing family name ;15

16 \\some other d e c l a r a t i o n s17

18 @OneToMany( f e t ch = FetchType .EAGER, mappedBy = ”u s e r i d ” , cascade =CascadeType .ALL)

19 @JsonManagedReference ( va lue = ”u s e r i d e v en t s ”)20 pr i va t e Set<Event> events = new HashSet<Event>(0) ;21 }

Fragmentul de cod 5.1: Adnotarile folosite ın clasa User pentru maparea bazei de dateprin frameworkul Hibernate

Pentru a putea pune la dispozitie metodele de manipulare a bazei de date, clasaUserRepository mosteneste clasa generica JpaRepository<T,ID> din libraria Spring JPA,unde parametrul T reprezinta entitatea pe care se doreste sa se efectueze operatiile cu bazade date, ın cazul acesta, T se va ınlocui cu User, iar ID-ul reprezinta tipul id-ului entitatiisi anume tipul long pentru aceasta aplicatie.

Spring JPA pune la dispozitie metode simple de CRUD pentru baza de date, precummetodele save() sau delete(), dar din cauza relatiei de mostenire, permite si declararea de


metode customizate. Acest lucru este posibil prin folosirea adnotarii @Query si folosireaunui limbaj de interogare asemanator cu SQL. Pentru a putea fi recunoscuta ca si clasa derepository de catre celelalte clase, UserRepository.java se adnoteaza cu @Repository.

In fragmentul de cod 5.2 se poate observa clasa de repository pentru User, ın carese creaza si o interogare customizata pentru cautarea utilizatorului dupa email.

1 @Repository2 pub l i c i n t e r f a c e UserRepos itory extends JpaRepository<User , Long> {3 @Query( ” s e l e c t u from User u where u . emai l = : emai l ”)4 pub l i c User LogIn (@Param( ”emai l ”) S t r ing emai l ) ;5 }

Fragmentul de cod 5.2: Exemplu de repository: clasa UserRepository

Clasa UserService implementeaza interfata UserInterface si instanteaza obiecte detip repository prin care apeleaza metodele gata implementate din Spring JPA pentru ma-nipularea bazei de date.

Prin folosirea adnotarii @Autowired se realizeaza injectarea dependintelor (depen-dency injection). Acest lucru ınseamna ca, prin ajutorul adnotarii @Autowired se ”in-jecteaza” toate bean-urile folosite ın bean-ul proiectului. Un bean este un obiect instantiat,asamblat si manipulat de container-ul Spring IoC.

Clasa UserService este recunoscuta de restul aplicatiei ca fiind un serviciu prinadnotarea @Service.

1 @Service2 pub l i c c l a s s UserServ i ce implements Us e r In t e r f a c e {3

4 @Autowired5 UserRepos i tory use r r epo ;6

7 @Override8 pub l i c User addUser ( User u) {9 Timestamp d created = new Timestamp ( System . cur rentT imeMi l l i s ( ) ) ;

10 u . s e tDate c r ea t ed ( d created ) ;11 u . setDate updated ( d created ) ;12 u . se t I s admin ( f a l s e ) ;13 u . setBlocked ( f a l s e ) ;14 use r r epo . save (u) ;15 re turn u ;16 }17 }

Fragmentul de cod 5.3: User service: folosirea adnotarilor

In exemplul 5.3 se instanteaza un obiect de tip UserRepository dupa care se folosestemetoda save(object) pentru a salva utilizatorul ın baza de date.

Clasele UserController si DibApplication apeleaza metodele din clasa UserServicesi le asociaza un URI.


Ele sunt adnotate cu @RestController pentru putea a fi recunoscute ca si serviciiREST, iar prin adnotarea @RequestMapping() se specifica URI-ul controlerului.

Mai departe, fiecarei metode din controller i se va specifica un URI prin aceeasiadnotare. In @RequestMapping(), pe langa calea spre metoda, se specifica si tipul cereriisi anume GET, POST sau PUT.

In antetul metodei se pot specifica variabilele din URI in cazul in care acesteaexista, iar acest lucru se realizeaza prin adnotarea @PathVariable(”variable”) sau continutulasteptat ımpreuna cu cererea prin adnotarea @RequestBody.

Astfel, ın 5.3, se instanteaza un obiect de tip UserService si se foloseste pentrureturnarea tuturor utilizatorilor din baza de date ıntr-o lista. Serviciul REST descris maijos se apeleaza folosind URL-ul http://localhost:8080/user/findAll.

1 @RestContro l ler2 @RequestMapping ( ”/ us e r s ”)3 pub l i c c l a s s Use rCont ro l l e r {4

5 @Autowired ( r equ i r ed = true )6 pr i va t e UserServ i ce u s e r s e r v i c e ;7

8 @RequestMapping ( va lue = ”/ f i ndA l l ” , method = RequestMethod .GET)9 pub l i c L i s t<User> f i ndA l lUse r ( ) {

10 re turn u s e r s e r v i c e . f i ndA l lUs e r s ( ) ;11 }12 }

Fragmentul de cod 5.4: Folosirea adnotarilor pentru controller

Clasa DibApplication este clasa care porneste aplicatia. Aceasta contine metodamain() si este adnotata cu @SpringBootApplication pentru a putea fi recunoscuta ca siclasa principala.

De asemenea, contine si adnotarile @EnableAutoConfiguration si @RestControllerdeoarece DibApplication.java implementeaza autentificarea cu contul de Google prin pro-tocolul OAuth 2.0 si redirectioneaza utilizatorul la pagina web potrivita ın functie de rolullui.

1 pub l i c s t a t i c void main ( St r ing [ ] a rgs ) {2 Spr ingAppl i ca t ion . run ( DibAppl icat ion . c l a s s , a rgs ) ;3 }

Fragmentul de cod 5.5: Metoda main din clasa DibApplication prin care se pornesteaplicatia

5.1.3 Diagrama de secventa

In figura 5.3 este prezentata o diagrama de secventa pentru o operatie simpla deGET:


Figura 5.3: Diagrama de secventa pentru o operatie GET

Pasii de procesare din diagrama sunt:

1. Browser-ul trimite o cerere HTTP care contine metoda GET pentru a obtine wish-ulcu id-ul 1. Acest lucru se ıntampla apeland URL-ul: http://locahost:8080/wish/find/1.Acest URL este compus din urmatoarele:

� HTTP: este protocolul folosit

� localhost: reprezinta adresa serverului (ın acest caz localhost sau 127.0.0.1)

� 8080: portul pe care ruleaza aplicatia

� wish/find/1: aceasta adresa este mapata la resursa din aplicatie prin serverulde web. Acest lucru este posibil prin controlerele REST expuse de server

2. Controlerul WishController instantiaza o resursa de tip WishService si apeleazametoda findWish(1) la care este mapat URL-ul

3. Obiectul de tipul UserService este apelat cu metoda getWishById(1) si se instanteazaun obiect de tipul WishRepository pentru a gasi wish-ul cu id-ul 1 ın baza de date

5.2. BAZA DE DATE A APLICATIEI 39

4. Prin obiectul de tipul WishRepository se apeleaza metoda findById. Aceasta metodafoloseste o interogare predefinita

5. WishRepository extrage un obiect de tip entitate care contine valorile din baza dedate

6. O entitate de tip Wish este returnata catre WishRepository

7. O entitate de tip Wish este returnata catre WishService

8. WishService returneaza entitatea de tip Wish catre WishController

9. Intr-un mod transparent pentru programator, framework-ul Spring cheama JacksonConverter pentru a converti obiectul de tip Wish ıntr-un obiect de tip JSON. Obiectulastfel convertit este trimis catre browser

10. Browser-ul primeste obiectul de tip JSON si ıl afiseaza.

5.2 Baza de date a aplicatiei

Pentru baza de date a aplicatiei se foloseste platforma Cloud SQL de la Google, iartestarea se realizeaza prin IDE-ul MySQL Workbench.

Pentru accesarea bazei de date din framework-ul Spring este nevoie de crearea uneiconexiuni ın fisierul application.properties. Conexiunea este descrisa de IP-ul si portul lacare raspunde baza de date, numele ei, utilizatorul si parola prin care ea este accesata.

1 ## Spring DATASOURCE ( DataSourceAutoConfiguration & DataSourcePropert ie s )2 sp r ing . datasource . u r l = jdbc : mysql : // 35 . 1 98 . 6 5 . 6 5 : 3 306/ dib db ? autoReconnect=

true&useUnicode=true&characterEncoding=UTF−8&al lowMult iQuer i e s=true&useSSL=f a l s e

3 sp r ing . datasource . username = root4 sp r ing . datasource . password = 1234

Fragmentul de cod 5.6: Conexiunea cu baza de date ın framework-ul Spring

Pe langa stabilirea conexiunii, este nevoie si de includerea dependintelor in fisierulpom.xml.

1. Hibernate - librariile sunt folosite la maparea tabelelor din baza de date pe entitatiledin pachetul dib.models:

1 <dependency>2 <groupId>org . h ibe rnate</groupId>3 <a r t i f a c t I d>hibernate−search−eng ine</ a r t i f a c t I d>4 <ve r s i on>5 . 9 . 1 . F ina l</ ve r s i on>5 </dependency>6 <dependency>7 <groupId>org . h ibe rnate</groupId>


8 <a r t i f a c t I d>hibernate−search−orm</ a r t i f a c t I d>9 <ve r s i on>5 . 9 . 1 . F ina l</ ve r s i on>

10 </dependency>11 <dependency>12 <groupId>org . hsqldb</groupId>13 <a r t i f a c t I d>hsqldb</ a r t i f a c t I d>14 <scope>runtime</ scope>15 </dependency>16

Fragmentul de cod 5.7: Dependinte pentru Hibernate

2. MySQL - este nevoie de includerea dependintei pentru MySQL Connector deoareceprin aceasta se va realiza conectarea la baza de date din Google Cloud SQL:

1 <dependency>2 <groupId>mysql</groupId>3 <a r t i f a c t I d>mysql−connector−java</ a r t i f a c t I d>4 </dependency>5

Fragmentul de cod 5.8: Dependinta pentru MySQL Connector

3. JSON - libraria care contine dependintele de mai jos permite serializarea datelorıntre Cloud SQL si Hibernate sau transformarea lor ın obiecte de tip JSON. Acesteasunt folosite si de catre Hibernate (intern), dar si pentru comunicarea cu aplicatiaclient.

1 <dependency>2 <groupId>com . f a s t e rxml . jackson . core</groupId>3 <a r t i f a c t I d>jackson−annotat ions</ a r t i f a c t I d>4 </dependency>5 <dependency>6 <groupId>com . f a s t e rxml . jackson . core</groupId>7 <a r t i f a c t I d>jackson−databind</ a r t i f a c t I d>8 </dependency>9

Fragmentul de cod 5.9: Dependinte pentru JSON

5.2.1 Arhitectura bazei de date

In acest sub-capitol se va prezenta arhitectura bazei de date, se vor descrie tabelelesi campurile relevante ale acestora.

5.2. BAZA DE DATE A APLICATIEI 41

Figura 5.4: Arhitectura bazei de date

Baza de date a aplicatiei contine 8 tabele:

1. USERS: contine urmatoarele campuri: user id, family name, given name, email,photo, phone, country, city, is admin, blocked, date created, date updated. Cheiastraina a acestui tabel o reprezinta campul user id. Majoritatea datelor din aceastatabela sunt completate sau actualizate in momentul in care utilizatorul se autentificacu contul de Google.

2. WISH: are urmatoarele campuri: wish id, count evt, wish name, status, user author id,date created, date updated. Cheia primara a acestui tabel este wish id. Cheia strainaeste campul user author id care face legatura cu tabela USERS si reprezinta uti-lizatorul care a propus wish-ul respectiv. Prin campul count evt se numara de cateori un wish a devenit eveniment ın calendarul unui utilizator.

3. USER WISH este tabela care face legatura ıntre tabelele WISH si USERS princheile straine user id si wish id, cheia primara a acestei tabele fiind user wish id.


4. REVIEW este tabela in care se memoreaza aprecierile lasate de un utilizator altuiutilizator. Aceasta tabela are urmatoarele campuri: review id, user id reviewer,user id reviewed, text review, status, date created, date updated. Cheia primara estereprezentata de review id, iar cheile straine ale acestei tabele sunt user id reviewer,user id reviewed care fac legatura cu tabela USERS si reprezinta utilizatorul carelasa un review si respectiv cel care primeste un review.

5. EVENTS TB este tabela care tine evenimentele din contul de Google Calendarsal utilizatorului. Aceasta tabela contine urmatoarele campuri: event id, event date,event name, user id, date created, date updated. Campul user id este cheia strainacare face legatura cu tabela USERS, cheia primara fiind event id.

6. CONVERSATION: contine urmatoarele campuri: conversation id, conversation name,date created, date updated. Cheia primara a acestui tabel o reprezinta campul con-versation id. Campul conversation name va fi dat ın functie de wish-ul pe care uti-lizatorii ıl discuta. Campul date created este data la care a fost ınceputa conversatia,iar campul date updated va fi reprezentat de data crearii ultimului mesaj.

7. USER CONVERSATION este tabela de legatura ıntre tabelele USERS si CON-VERSATION. Cheia straina pentru aceasta tabela este reprezentata de campuluser conversation id, iar campurile conversation id si user id reprezinta cheile straineale tabelelor USERS si respectiv CONVERSATION astfel formandu-se legaturaıntre cele doua tabele.

8. MESSAGE: contine urmatoarele campuri: message id, user conversation id, msg text,date created. Campul message id este cheia primara a tabelei, iar cheia straina estereprezentata de campul user conversation id astfel ıncat se realizeaza legatura cutabela USER CONVERSATION. Campul msg txt reprezinta mesajul pe care ilscrie user-ul ın conversatie, iar date created reprezinta data si ora la care acest mesajeste scris. Mesajul nu poate fi modificat ulterior.

Proiectarea bazei de date respecta practicile bune pentru construirea unei bazede date, astfel ıncat cheile sunt toate de tipul INT si se autogenereaza, deci nu existaposibilitatea de a avea chei duplicate. De asemenea, toate tabelele au chei primare pentrua putea fi indexate chiar si cele care rezolva relatiile many-to-many, numele sunt sugestivesi toate campurile date created si date updated sunt de tipul TIMESTAMP.

Statusul ın tabelele REVIEW si WISH poate fi schimbat doar de administratorla fel si campurile is admin si blocked din tabela USER.

Tabelele CONVERSATION, USER CONVERSATION si MESSAGE de-servesc modulul de chat al aplicatiei, iar tabelele WISH, USER WISH si EVENTS TBdeservesc algoritmul de conectare al utilizatorilor.

Campurile date created, date updated reprezinta data la care a fost creat un anumitcamp si respectiv ultima data la care acesta a fost actualizat.

5.3. COMPONENTE REPREZENTATIVE 43

Baza de date se afla ın forma normala 2 (2NF) deoarece nu exista dependentetranzitive sau chei compuse.

5.3 Componente reprezentative

5.3.1 Sign-in cu Google

Primul pas ın realizarea autentificarii cu Google este de a obtine un CLIENT IDsi un CLIENT SECRET. Acest lucru se face din meniul Credentials din consola GoogleCloud. Pentru a obtine un aceste date este nevoie de a specifica un URL dinspre care vinecererea si un URL de redirectionare, acestea fiind http://localhost:8080 si respectivhttp://localhost:8080/login.

Dupa ce aceste date au fost furnizate, Google va oferi un CLIENT ID si un CLIENTSECRET. Aceste informatii sunt introduse ulterior ın fisierul de configurare application.propertiesa framework-ului Spring, ımpreuna cu setarile pentru autentificarea cu protocolul OAuth2.0 si forma de interogare a utilizatorului.

1 ################### Sign−in with Google Conf igurat ion ###############2 s e c u r i t y . oauth2 . c l i e n t . c l i e n t I d =427377158773−

u6a fd l 683 j 59a2q2g t f s kv l 988 s r td8 t . apps . goog l eu s e r conten t . com3 s e c u r i t y . oauth2 . c l i e n t . c l i e n t S e c r e t=xGXpFTHYqkCjLXDQr8HzpjLC4 s e c u r i t y . oauth2 . c l i e n t . accessTokenUri=https : //www. goog l e ap i s . com/oauth2/v3/

token5 s e c u r i t y . oauth2 . c l i e n t . u se rAuthor i za t i onUr i=https : // accounts . goog le . com/o/

oauth2/auth6 s e c u r i t y . oauth2 . c l i e n t . tokenName=oauth token7 s e c u r i t y . oauth2 . c l i e n t . authent icat ionScheme=query8 s e c u r i t y . oauth2 . c l i e n t . c l i entAuthent i cat ionScheme=form9 s e c u r i t y . oauth2 . c l i e n t . scope=p r o f i l e emai l

Fragmentul de cod 5.10: Configurarile pentru autentificarea cu Google din fisierul deconfigurare application.properties

DibApplication.java este clasa care se ocupa de autentificare si este adnotata cu@EnableAutoConfiguration pentru a permite folosirea obiectelor de tipul OAuth2Authenticationcare returneaza utilizatorul autentificat. Metoda care se ocupa efectiv de autentificareeste public String user(OAuth2Authentication authentication, HttpServletRe-quest request). Aceasta este mapata la URI-ul ”/app” prin adnotarea @RequestMap-ping(”/app”).

Dupa ce utilizatorul si-a introdus datele in formular, iar Google a autorizat aplicatiaDIB de a accesa datele utilizatorului, informatiile acestuia sunt returnate prin apelareametodelor din obiectul OAuth2Authentication si sunt retinute ıntr-un LinkedHashMap:

1 LinkedHashMap<Str ing , Object> p r op e r t i e s = (LinkedHashMap<Str ing , Object>)au then t i c a t i on . getUserAuthent i cat ion ( ) . g e tDe t a i l s ( ) ;

Fragmentul de cod 5.11: Prelaurea datelor de la Google


Dupa ce datele au fost preluate ın LinkedHashMap, se interogheaza baza de datefolosind functia FindByEmail descrisa ın portiunea de cod 5.2 pentru a verifica dacautilizatorul este nou sau a mai fost autentificat ın trecut.

In cazul ın care acesta este gasit ın baza de date, adica el a mai fost autentificat ıntrecut, se verifica daca datele lui s-au modificat de la ultima sesiune ınregistrata pe site.Daca datele s-au modificat, ele se actualizeaza ın baza de date si dupa aceea utilizatorulse salveaza ıntr-o sesiune de tipul HttpServletRequest. Daca datele nu au fost modificate,atunci doar se salveaza ın sesiune.

Pentru cazul ın care utilizatorul este nou, el se salveaza ın baza de date cu informati-ile furnizate de Google si i se deschide o sesiune. De precizat ca ın momentul ın care unutilizator nou este ınregistrat ın sistem, atributele isBlocked si isAdmin se seteaza automatca fiind false, adica utilizatorul nu este blocat si nu este admin. Doar un alt administratorpoate sa ıi schimbe aceste atribute ale utilizatorului nou ınregistrat.

Dupa ce aceste actiuni sunt facute, pentru utilizatorii deja existenti se verifica dacaei sunt blocati, iar ın cazul ın care isBlocked este setat la true, utilizatorul este redirectionatcatre o pagina prin care este anuntat ca are contul blocat. In caz contrar, se verifica dacaacesta este administrator sau nu si este redirectionat catre AdminPannel sau, respectivUserPannel.

Utilizatorii noi sunt redirectionati automat catre UserPannel.

5.3.2 Preluarea datelor din Google Calendars

La fel ca si pentru autentificarea cu Google, este nevoie de un CLIENT ID si unCLIENT SECRET. Acestea se obtin identic modului descris anterior. In plus, pentruaccesarea acestui API este nevoie de un API KEY. In aceeasi sectiune de Credentials dinGoogle Console se cere un API KEY si totodata se specifica si un nume pentru aceasta.

Preluarea datelor din Google Calendar se face pe partea de client deoarece este mairapid pentru utilizator, urmand ca dupa afisarea evenimentelor ın calendar, acestea sa fietrimise catre partea de server pentru a putea fi procesate.

De data aceasta, datele de autentificare sunt specificate ın variabile JavaScript, eleurmand sa fie folosite ın functia de preluare a evenimentelor. Functia handleClientLoad()realizeaza autentificarea prin protocolul OAuth 2.0. si apeleaza functia initClient.

1 var CLIENT ID = ’427377158773-g4negabau7if0ikb4pcs68kvjpohf86t.apps.

googleusercontent.com’ ;2 var API KEY = ’AIzaSyBy -xmN55JlTABiSZpAC3IEPyN5zAvctKA’ ;3 var DISCOVERY DOCS = [ "https://www.googleapis.com/discovery/v1/apis/calendar

/v3/rest" ] ;4 var SCOPES = "https://www.googleapis.com/auth/calendar.readonly" ;5

6 function handleCl ientLoad ( ) {7 gapi . load (’client:auth2’ , i n i t C l i e n t ) ;8 }

Fragmentul de cod 5.12: Accesarea Google Calendars API prin JavaScript


Pentru a evita supra-ıncarcarea aplicatiei, se vor ıncarca doar evenimentele dinultimul an. Acest lucru se face folosind tipul Date() si apeland functia getFullYear().Inainte de a se face extragerea efectiva a evenimentelor se seteaza anumiti parametri defiltrare. In cazul de fata acesta sunt:

� calendarId - este setat la ”primary”, asta ınsemnand ca se va afisa calendarul prin-cipal al utilizatorului, fara evenimentele din alte calendare care i-au fost partajate.

� timeMin - reprezinta timpul de start de la care ıncepe sa se extraga evenimentele.Acesta este setat la ziua curenta - un an.

� showDeleted - setat la false, deoarece nu intereseaza evenimentele care au foststerse de catre utilizator.

� maxResults - reprezinta numarul maxim de evenimente care pot fi extrase. Estesetat la valoarea de 2500.

� orderBy - dicteaza ordinea dupa care sunt extrase evenimentele. In cazul de fatasunt extrase cronologic.

Este de notat ca, lista de filtre este mult mai vasta, dar s-a considerat ca doaracestea sunt esentiale. Lista completa se gaseste ın referinta [13].

Dupa ce aceste filtre au fost setate, evenimentele sunt extrase ıntr-o lista. Listaeste mai departe trimisa catre view. Afisarea este facuta pe luna, iar pentru vizualizareacalendarului s-a folosit libraria de JavaScript FullCalendar.

1 gapi . c l i e n t . ca l endar . events . l i s t ({2 ’calendarId’ : ’primary’ ,3 ’timeMin’ : l a s tYear . toISOStr ing ( ) ,4 ’showDeleted’ : false ,5 ’singleEvents’ : true ,6 ’maxResults’ : 2500 ,7 ’orderBy’ : ’startTime’

8 }) . then ( function ( re sponse ) {9 var events = response . r e s u l t . i tems ;

10 i f ( events . l ength > 0) {11 var ca lendarEvents = [ ] ;12 f o r ( i = 0 ; i < events . l ength ; i++) {13 var event = events [ i ] ;14 ca lendarEvents . push ({15 t i t l e : event . summary ,16 s t a r t : event . s t a r t . date ,17 end : event . end . date18 }) ;19 }20 $ (’#calendar’ ) . f u l lCa l enda r ({21 defaultView : ’month’ ,22 events : ca lendarEvents


23 }) ;24 }25 }) ;

Fragmentul de cod 5.13: Extragerea evenimentelor din Google Calendars ın functie defiltrele setate.

Lista de evenimente este transmisa catre server pentru procesare prin apelul $http,folosind metoda POST.

1 $http . post ( c on f i g .API URL + ’/events/insertAll/’ , {2 events3 }

Fragmentul de cod 5.14: Trimiterea evenimentelor catre server

Serviciul REST expus de server este mapat la URI-ul /events/insertAll, astfel,ın obiectul $http se va apela URL-ul http://localhost:8080/events/insertAll. Acestaprimeste ca body o lista de evenimente si le introduce ın sistem. In clasa de serviciu se facverificari pentru a nu introduce un eveniment de doua ori.

In figura 5.5 este afisat rezultatul vizibil pentru utilizator la extragerea eveni-mentelor:

Figura 5.5: Vizualizarea evenimentelor ın aplicatia web

5.3.3 Transmiterea coordonatelor si calcularea distantei

Coordonatele utilizatorului sunt preluate din browser folosind geolocation si functiade JavaScript getCurrentPosition. Aceasta are ca si parametru position, iar latitudinea si


longitudinea se acceseaza folosind atributele parametrului position prin position.coords.latitudesi respectiv position.coords.longitude. Acestea sunt transmise mai departe catre serverpentru a putea fi folosite si procesate ın metoda care conecteaza doi utilizatori.

Trimiterea lor catre server se face tot prin obiectul $http din JavaScript si folosindmetoda POST prin URL-ul http://localhost:8080/users/update/{id}. URI-ul /user-s/update/{id} este mapat la metoda UpdateUser din UserController.java folosind metodelede injectare descrise ın portiunea de cod 5.4.

Mai jos este prezentata portiunea de cod care preia coordonatele din browser-ulclientului si le trimite la server:

1 i f ( nav igator . g e o l o c a t i on ) {2 nav igator . g e o l o c a t i on . ge tCurrentPos i t i on ( function ( p o s i t i o n ) {3 $http . post (’/users/update/’ + vm. user . u s e r id , {4 coordX : po s i t i o n . coords . l a t i t ude ,5 coordY : po s i t i o n . coords . l ong i tude6 } , {7 withCredent i a l s : true8 }) . then ( function ( re sponse ) {9 conso l e . l og ("coordinates updated" ) ;

10 } , function ( re sponse ) {11 conso l e . l og ("error updating coordinates" ) ;12 }) ;13

14 }) ;15 }

Fragmentul de cod 5.15: Trimiterea evenimentelor catre server

Controllerul REST apeleaza metoda updateUser din UserService.java si deoarece ınaceasta se fac verificari pentru atributele utilizatorului, adica daca s-au schimbat fata dece este ın baza de date sau daca sunt nule, nu este nevoie de a trimite tot obiectul usercatre server. Ca si id se trimite vm.user.user id si anume utilizatorul din sesiune.

Aceste coordonate se trimit catre server de fiecare data cand se reıncarca paginauser.html adica UserPannel, iar acest lucru se ıntampla deoarece se doreste ca locatia uti-lizatorului sa fie cat se poate de mult mai aproape de cea adevarata (mai ales daca acestase afla ın miscare) pentru ca metoda care realizeaza conexiunea sa dea rezultate cat maiexacte.

Coordonatele astfel salvate vor servi metodei de conectare a utilizatorilor si anumeMatchUsers din UserService.java.

Pentru a calcula distanta ıntre doi utilizatori avand ca si parametri de intrare lon-gitudinea si latitudinea pozitiilor acestora se foloseste algoritmul Harvesian.

Algoritmul Harvesian [16] calculeaza, pe baza longitudinii si latitudinii, cea maiscurta distanta de-a lungul suprafetei pamantului. Rezultatul este o distanta exprimataın metri. Formulele pentru algoritmul Harvesian sunt:


a = sin2(ϕ2 − ϕ1

2) + cosϕ1 ∗ cosϕ2 ∗ sin2(

λ2 − λ12

)

b = 2 ∗ atan2(√a,√

1− a)

c = R ∗ b

Acestea fiind spuse, calcularea distantei ın Java este prezentata ın fragmentul decod 5.16 unde se poate observa si corespondenta ıntre variabile:

1 double R = 6371000; //meters2 double dLat = Math . toRadians ( la t2−l a t 1 ) ;3 double dLng = Math . toRadians ( lng2−lng1 ) ;4 double a = Math . s i n ( dLat /2) * Math . s i n ( dLat /2) +5 Math . cos (Math . toRadians ( l a t 1 ) ) * Math . cos (Math . toRadians ( l a t 2 ) ) *

6 Math . s i n (dLng/2) * Math . s i n (dLng/2) ;7 double b = 2 * Math . atan2 (Math . s q r t ( a ) , Math . s q r t (1−a ) ) ;8 f l o a t d = ( f l o a t ) (R * b) ;

Fragmentul de cod 5.16: Calcularea distantei ıntre doi utilizatori

5.3.4 Sistemul de chat

Pentru ca doi utilizatori sa poata comunica ıntre ei, acestia trebuie sa fie conectati.Aceste verificari sunt facute la accesarea meniului de Chat de catre utilizator si alegereaunui alt utilizator pentru a ıncepe conexiunea.

Pe server, sistemul de chat contine 6 clase:

1. Message.java - clasa entitate

2. MessageRepository.java - mosteneste JpaRepository pentru folosirea operatiilorautogenerate pe baza de date

3. MessageInterface - definirea operatiilor posibile pentru mesaje

4. MessageService.java - clasa care implementeza operatiile din MessageInterface siintroduce mesajele in baza de date sau extrage diferite date pentru validare din tabelamessage

5. MessageController - contine metoda getMessage pentru preluarea unui mesaj simapeaza aceasta resursa la URI-ul /chat/message

6. WebSocketConfiguration - este clasa de configurare pentru WebSockets. Aceastaeste adnotata cu @EnableWebSocketMessageBroker si mosteneste clasa AbstractWeb-SocketMessageBrokerConfigurer. In aceasta clasa se seteaza end-point-urile conex-iunii ca fiind anumite URI-uri, specificandu-se ca socket-urile sunt deschise prin


JavaScript, folosind metoda withSockJS, mai exact i se specifica serverului ca vaprimi mesaje doar de la /chat-messaging.

1 @EnableWebSocketMessageBroker2 pub l i c c l a s s WebSocketConfiguration extends

AbstractWebSocketMessageBrokerConfigurer {3 pub l i c void conf igureMessageBroker ( MessageBrokerRegistry c on f i ) {4 c on f i . enableSimpleBroker ( ”/ chat ”) ;5 c on f i . s e tApp l i c a t i o nDe s t i n a t i onPr e f i x e s ( ”/app ”) ;6 }7 pub l i c void reg i s terStompEndpoints ( StompEndpointRegistry r e g i s t r y ) {8 r e g i s t r y . addEndpoint ( ”/chat−messaging ”) . withSockJS ( ) ;9

10 }11 }

Fragmentul de cod 5.17: Configurea WebSockets pentru sistemul de chat

Pe partea de client, exista doua fisiere, cel de HTML care afiseza interfata graficaa sistemului de chat si fisierul ın JavaScript care deschide conexiunile sub forma de Web-Sockets, comunicand ın acelasi timp cu serverul.

Fisierul chat.js contine functia connect() care deschide o conexiune catre end-point-ul/chat-messaging dupa care se apeleaza functia getMessage prin URI-ul chat/messages’sise parseaza mesajul primit. Mesajul este afisat utilizatorului pentru a-l informa daca s-arealizat conexiunea sau nu.

1 function connect ( ) {2 var socke t = new SockJS (’/chat-messaging’ ) ;3 stompClient = Stomp . over ( socke t ) ;4 stompClient . connect ({} , function ( frame ) {5 conso l e . l og ("connected: " + frame ) ;6 stompClient . sub s c r i b e (’/chat/messages’ , function ( re sponse ) {7 var data = JSON. parse ( re sponse . body ) ;8 draw ("left" , data . message ) ;9 }) ;

10 }) ;11 }

Fragmentul de cod 5.18: Deschiderea conexiunilor in JavaScript

In pagina web destinata sistemului se pun la dispozitie 3 butoane pentru utilizator:

1. CONNECT - apeleaza functia connect() descrisa ın portiunea de cod 5.18 pentrua se realiza conexiunea cu utilizatorul ales.

2. SEND - apeleaza metoda send() care trimite mesajul.

3. DISCONNECT - apeleaza metoda disconnect() care opreste conexiunea.

Pentru a putea trimite mesaje, utilizatorul trebuie sa apese pe butonul CONNECTmai ıntai pentru a se realiza conexiunea, altfel va primi un mesaj de eroare.

Capitolul 6

Testare si Validare

Obiectivul acestui capitol este de a prezenta modalitatile de testare si validare alecomponentelor aplicatie. Testarea aplicatiei a fost impartita ın doua: testarea pentruback-end si testarea pentru front-end.

Pentru testarea de back-end s-a folosit programul PostMan. S-au testat toate URL-urile serviciilor REST din aplicatie, pentru a ma asigura ca acestea functioneaza corect sinu se pot accesa fara token-ul generat de SpringSecurity. De asemenea, acesta valideazasi conexiunea cu baza de date a aplicatiei.

Figura 6.1: Testarea ın programul Postman

De asemenea, s-a folosit si metoda de testare black-box. Aceasta reprezinta testareafunctionalitatilor implementate conform specificatiilor stabilite. La testarea black-box,nu se are acces la cod ci doar la interfata grafica. Astfel s-au testat functionalitatile ınpagina web, s-a verificat daca aplicatia raspunde conform cerintelor, daca afiseaza mesajelecorecte, daca trimite catre paginile corespunzatoare si daca informeaza corect despre erori.

50

51

Un alt utilitar folosit pentru testarea rutelor formate ın AngularJS a fost LinkScan.Acest program cauta ın aplicatie link-urile orfane sau cele care nu duc nicaieri.

Pentru partea de front-end s-au folosit cateva utilitare de validare:

� HTML Validator [17] - valideaza sintaxa documentului HTML.

� Link checkers [18] - valideaza link-urile aplicatiei

� CSS Validator [19] - valideaza sintaxa

� Quint for JS [20]- valideaza fisierele JavaScript

De asemenea, s-au testat formularele de introducere a datelor, corectitudinea lorsi faptul ca ele valideaza datele introduse de utilizator si astfel accepta doar date corectintroduse.

Capitolul 7

Manual de Instalare si Utilizare

7.1 Instalare aplicatie

Pentru a instala aplicatia trebuie parcursi urmatorii pasi:

1. se decarca si se instaleaza versiunea 8 de Java: https://java.com/en/download/

2. se descarca si se instaleaza o versiune de Eclipse: http://www.eclipse.org/downloads/

3. din IDE-ul eclipse, se da click pe File -> New -> Project -> Maven -> ExistingMaven Project si se alege fisierul de pe CD.

4. se intra pe Google Console Cloud utilizand emailul... si parola...

5. se seleacteaza din meniu Cloud SQL -> Authorization

6. ın fereastra deschisa se introduce IP-ul public folosit de router-ul pe care ıl folosestecalculatorul si se apasa ”Save”

7. din Eclipse: click dreapta pe clasa DibApplication.java din pachetul app.dib.dib sise selecteaza Run as -> Java Application

8. se acceseaza URL-ul http:localhost:8080

7.2 Manual de utilizare

Dupa ce s-a accesat URL-UL specificat ın ultimul pas din sectiunea anterioara seva dechide o pagina de autentificare cu Google:

� pentru rolul de administrator se introduc emailul si parola specificate ın pasul 4din sectiunea anterioara

52

7.2. MANUAL DE UTILIZARE 53

Figura 7.1: AdminPannel

� pentru rolul de utilizator se va introduce un cont personal de Google

Figura 7.2: UserPannel

Capitolul 8

Concluzii

In acest capitol se detaliaza functionalitatile implementate, obiectivele care au fostatinse pe parcursul implementarii si se propun o serie de dezvoltari ulterioare.

8.1 Obiective ındeplinite

Sistemul care a fost implementat si-a ındeplinit obiectivele de a fi o aplicatie carepoate conecta oamenii bazandu-se pe criteriile de timp, distanta si hobby-uri. Acest lucrua fost posibil prin urmarirea cu strictete a cerintelor functionale descrise ın capitolul 2,astfel aplicatia este capabila de a prelua evenimentele din Google Calendar, de a calculadistanta ıntre utilizatori si de a-i conecta ın functie wish-uri. De asemenea, utilizatorii potsa propuna si sa ısi aleaga wish-uri.

Un alt obiectiv important care a reusit sa fie implementat este sistemul de chat.Utilizatorii au posibilitatea de a purta conversatii online cu persoanele cu care au fostconectate prin intermediul aplicatiei.

Cel de al trei-lea obiectiv implementat este functionalitatea de administrator. Acestapoate modera review-urile si wish-urile noi aparute ın sistem prin aprobarea sau revocarealor. De asemenea poate bloca sau debloca un utilizator si poate oferi sau revoca drepturilede administrator unui utilizator.

Cerintele non-functionale au fost si ele ındeplinite, asfel ca recuperarea si scalabili-tatea sunt oferite de platforma Cloud SQL, securitatea este asigurata prin folosirea proto-colului OAuth 2.0, iar din punct de vedere al utilizabilitatii, interfata este prietenoasa siintuitiva.

8.2 Dezvoltari ulterioare

Deoarece aceasta aplicatie a fost realizata bazandu-se pe conceptul de extensibili-tate, ea poate fi usor dezvoltata ın viitor. O parte din aceste dezvoltari ulterioare ar puteafi:

54

8.2. DEZVOLTARI ULTERIOARE 55

� Dezvoltarea unei aplicatii mobile care sa ofere aceleasi functionalitati ca si interfataweb. Acest ucru se poate face relativ usor prin accesarea serviciilor REST dejaconstruite pe partea de server.

� Mutarea aplicatiei pe o platforma de cloud. Cea mai indicata este Google AppEngine, deoarece toate API-urile folosite pentru implementarea acestei aplicatii aufost de la Google.

� Afisarea hartii conexiunilor pentru un utilizator.

� Afisarea unor rapoarte pentru administrator (ca de exemplu numarul utilizatorilornoi pe luna).

� Crearea unui serviciu platit prin care lectorii sa poata sa ısi gasesca studenti pentrucursurile lor.

Bibliografie

[1] S.P.T. Krishnan and Jose L. Ugia Gonzales, Building Your Next Big Thing with GoogleCloud Platform - A Guide for Developers and Enterprise Architects, 1st ed. Apress,Jun 15, 2015.

[2] Murali Dodda and Vara Prasad Nulu, A complete Guide to Google Cloud Platform,1st ed. 2016.

[3] K. Siva Parasad Reddy, SpringBoot Learn By Example, 1st ed. Leanpub, Jul 30, 2016.

[4] Phillip Webb, Dave Syer, Josh Long, Stephane Nicoll, Rob Winch, Andy Wilkinson,Marcel Overdijk, Christian Dupuis, Sebastien Deleuze, Michael Simons, Vedran Pavi,Jay Bryant and Madhura Bhave, Spring Boot Reference Guide - 2.0.2.RELEASE,1st ed. 2018. [Online]. Available: https://doc.lagout.org/programmation/spring-boot-reference.pdf

[5] Marek Mrazik, Computer Supported Cooperative Work, 2007.

[6] V.M.R. Penichet, I. Marin, J.A. Gallud, M.D. Lozano, R. Tesorieroa, A ClassificationMethod for CSCW Systems, 2007.

[7] ”Collaborative software” [Online]. Available:https://en.wikipedia.org/wiki/Collaborative software

[8] ”Computer-supported cooperative work” [Online]. Available:https://en.wikipedia.org/wiki/Computer-supported cooperative work

[9] I. Anghel, Curs: Dezvoltarea Aplicatiilor Web, 2018.

[10] ”An Introduction to OAuth 2” [Online]. Available:https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

[11] ”Using OAuth 2.0 to Access Google APIs | Google Identity Platform | Google Devel-opers” [Online]. Available: https://developers.google.com/identity/protocols/OAuth2

[12] ”Google Cloud SQL Overview” [Online]. Available:https://cloud.google.com/docs/overview/

56

BIBLIOGRAFIE 57

[13] ”Parametri de filtrare a evenimentelor” [Online]. Available:https://developers.google.com/calendar/v3/reference/events/list

[14] ”Tutorial: Preluarea datelor din Google Calendar prin JavaScript” [Online]. Available:https://developers.google.com/calendar/quickstart/js

[15] ”Libraria JavaScript pentru afisarea calendarului” [Online]. Available:https://fullcalendar.io/

[16] ”Algoritmul Harvesian de calculare a distantei bazat pe longitudine si latitudine”[Online]. Available: https://www.movable-type.co.uk/scripts/latlong.html

[17] ”Validatorul HTML” [Online]. Available: http://validator.w3.org/

[18] ”Validatorul pentru link-uri” [Online]. Available: https://validator.w3.org/checklink

[19] ”Validatorul pentru CSS” [Online]. Available: http://jigsaw.w3.org/css-validator

[20] ”Validatorul pentru JavaScript” [Online]. Available: https://qunitjs.com/

Anexa A

Diagrama de clase

In figura A.1 este prezentata diagrama de clase a aplicatiei. Ea a fost aranjata peniveluri:

� Primul nivel: interfete

� Al doilea nivel: repositories

� Al treilea nivel: servicii

� Al patrulea nivel: entitatile

58

59

Figura A.1: Diagrama de clase

Documents

FACULTATEA DE AUTOMATICA SI˘ CALCULATOARE …users.utcluj.ro/~civan/thesis_files/2018_Pop_Laura.pdf · rezultatul propriei activita˘ti intelectuale, pe baza cercetar ilor mele ˘si