UNIVERSITATEA DIN CRAIOVA

FACULTATEA DE AUTOMATICĂ, CALCULATOARE ȘI

ELECTRONICĂ

DEPARTAMENTUL DE INGINERIA
CALCULATOARELOR SI COMUNICATIILOR

PROIECT DE DIPLOMA

Ionuț Alexandru Manea

COORDONATOR ȘTIINȚIFIC

Conferentiar universitar.dr.ing, Constantin Patrășcu

Septembrie, 2022

CRAIOVA

1
 CRAIOVA

UNIVERSITATEA DIN CRAIOVA

FACULTATEA DE AUTOMATICĂ, CALCULATOARE ȘI
ELECTRONICĂ

DEPARTAMENTUL DE INGINERIA
CALCULATOARELOR SI COMUNICATIILOR

Sistem de inchirieri online cu localizare automata

Ionuț Alexandru Manea

COORDONATOR ȘTIINȚIFIC

Conferentiar universitar.dr.ing, Constantin Patrășcu

Septembrie, 2022

CRAIOVA

2
 DECLARAȚIE DE ORIGINALITATE

Subsemnatul IONUT ALEXANDU MANEA student la specializarea INGINERIA

CALCULATOARELOR SI COMUNICATIILOR din cadrul Facultății de Automatică, Calculatoare și
Electronică a Universității din Craiova, certific prin prezenta că am luat la cunoştinţă de cele prezentate
mai jos şi că îmi asum, în acest context, originalitatea proiectului meu de licenţă:

 cu titlul Sistem de inchirieri online cu localizare automata,

 coordonată de Conferentiar universitar, Constantin Patrășcu,
 prezentată în sesiunea Septembrie 2022.

La elaborarea proiectului de licenţă, se consideră plagiat una dintre următoarele acţiuni:

 reproducerea exactă a cuvintelor unui alt autor, dintr-o altă lucrare, în limba română sau prin traducere dintr-o
altă limbă, dacă se omit ghilimele şi referinţa precisă,
 redarea cu alte cuvinte, reformularea prin cuvinte proprii sau rezumarea ideilor din alte lucrări, dacă nu se
indică sursa bibliografică,
 prezentarea unor date experimentale obţinute sau a unor aplicaţii realizate de alţi autori fără menţionarea
corectă a acestor surse,
 însuşirea totală sau parţială a unei lucrări în care regulile de mai sus sunt respectate, dar care are alt autor.

Pentru evitarea acestor situaţii neplăcute se recomandă:

 plasarea între ghilimele a citatelor directe şi indicarea referinţei într-o listă corespunzătoare la sfărşitul lucrării,
 indicarea în text a reformulării unei idei, opinii sau teorii şi corespunzător în lista de referinţe a sursei originale
de la care s-a făcut preluarea,
 precizarea sursei de la care s-au preluat date experimentale, descrieri tehnice, figuri, imagini, statistici, tabele et
caetera,
 precizarea referinţelor poate fi omisă dacă se folosesc informaţii sau teorii arhicunoscute, a căror paternitate
este unanim cunoscută și acceptată.


Data, Semnătura candidatului,

07.09.2022

3
 UNIVERSITATEA DIN CRAIOVA Aprobat la
Facultatea de Automatică, Calculatoare şi data de
Electronică 06.09.2022

DEPARTAMENTUL DE INGINERIA Conf.univ.

CALCULATOARELOR SI COMUNICATIILOR dr. ing.
Constantin
Patrășcu

PROIECTUL DE DIPLOMĂ

Numele și prenumele
Ionut Alexandru Manea
studentului/-ei:

Enunțul temei: Sistem de inchirieri online cu localizare

automata

Datele de pornire:
Dezvoltarea unei aplicatii

Introducere,Scopul,Motivatia,, Arhitecturi,
Conținutul proiectului:
Implementare

Material grafic
obligatoriu:

Consultații: lunare

Conducătorul științific Conferentiar universitar.dr.ing, Constantin

(titlul, nume și Patrășcu
prenume, semnătura):

Data eliberării temei: 01.06.2022

4
Termenul estimat de
06.09.2022
predare a proiectului:

Data predării
proiectului de către
student și semnătura
acestuia: 06.09.2022

5
6
7
CUPRINS

Introducere ............................................................................................................................................................................. 9
Scopul..................................................................................................................................................................................... 9
Motivația (alegerii) lucrării .................................................................................................................................................... 9
Generalități ............................................................................................................................................................................. 9
Visual Studio Code .............................................................................................................................................................. 10
Node.js ................................................................................................................................................................................. 10
TypeScript ............................................................................................................................................................................ 10
Angular Framework : ........................................................................................................................................................... 11
Ionic ..................................................................................................................................................................................... 11
Server Securizat ................................................................................................................................................................... 11
Modul de realizare................................................................................................................................................................ 13
Arhitectura de servicii: ......................................................................................................................................................... 14
Arhitectura bazei de date:..................................................................................................................................................... 15
Arhitectura Completa: ...................................................................................................................................................... 16
Arhitectura Utilizatorilor .................................................................................................................................................. 17
Arhitectura tabelei pentru produse: .................................................................................................................................. 18
Arhitectura tabelei Orders: ............................................................................................................................................... 18
Inregistrarea utilizatorilor: ................................................................................................................................................... 19
Etape Aplicatie mobile ......................................................................................................................................................... 22
Evaluarea performantelor de sistem: .................................................................................................................................... 29
Performanta de pe front-end................................................................................................................................................. 30
Securitatea: ........................................................................................................................................................................... 31
Testarea: ............................................................................................................................................................................... 31
Concluzii: ............................................................................................................................................................................. 42
Bibliografie .......................................................................................................................................................................... 43

8
Introducere

Pentru realizarea acestui proiect a fost necesară integrarea următoarelor domenii studiate in timpul celor 2 ani de
master si in ciclul de licenta:
Programarea calculatoarelor
Baze de date
Programarea orientată pe obiecte
Rețele de calculatoare
Tehnici de securizare a informației
Arhitecturi de microcalculatoare
Tehnologii pentru servicii web
Testarea si asigurarea calitatii
Tehnologii wireless si retele mobile
Securitatea si protectia datelor
Modelarea si evaluarea performantelor.

Asemenea unui inginer am aplicat pașii principali pentru realizarea oricărui proiect:
1.Conceperea sistemului la nivel de blocuri.
2.Înțelegerea procesului.
3. Alegerea componentelor software pentru front-end, în funcție de necesitate.
4. Alegerea componentelor software pentru back-end, in functie de necessitate.
5.Integrarea acestora într-un sistem.
6.Adaptarea fiecărei componente si evaluarea performantelor.
7.Testarea tuturor pe mici module.
8.Testarea întregului sistem.

Scopul
Acest proiect a fost realizat din dorinta de a realiza a platforma sigura care sa poata fi folosita cu usurinta
si a oferi mai mult timp liber clientilor care aleg sa foloseasca aceasta platforma.

Motivația (alegerii) lucrării

Am optat pentru aprofundarea acestei teme în realizarea proiectului deoarece consider că este un
trend international în creștere și apreciez că o să ia amploare în urmatorii ani. Proiectul își propune
fixarea unor cunoștințe avansate și înțelegerea modului general de funcțioanare a acestui sistem pentru a-
mi facilita adaptarea la tehnologiile software viitoare.

Generalități
Tema propusa este o aplicatie de tip magazin online care permite utilizatorilor inchirierea unor produse

pentru o perioada determinata. Comanda se poate face fie folosind un browser de internet fie descarcand
aplicatia pe telefonul mobil.

Dupa ce clientul decide de ce produs are nevoie, procedura de finalizare comanda este foarte intuitiva si
este nevoie doar de 3 click-uri :

9
Clientul adauga produsul/produse in cos, cosul va aparea ca un cerc in partea din dreapta sus si cu

simpla apasare pe acest cos se va deschide comanda si se va genera o factura fictiva.

Daca clientul nu doreste sa se razgandeasca atunci pentru a primi comanda este nevoie de accordul de

continuare(accord de buna ingrijire a produsului, predare fara probleme). Aplicatia va prelua

coordonatele GPS de la adresa clientului si apoi va fi redirectionat catre procesatorul de plati pentru a se
completa comanda cu plata prin card folosind serviciul Stripe.

Odata avute aceste informatii in serverul de back-end se foloseste un algoritm de identificare si

optimizarea traseului catre client a unuia dintre curierii disponibili. Algoritmul ia in calcul adresa la care

se afla clientul si adresa/adresele depozitelor din care unul dintre curieri va ridica produsul pentru a-l

livra clientului final.

Visual Studio Code

Visual Studio Code este un mediu de dezvoltare care combină simplitatea unui editor de text cu ustensile
folosite în crearea aplicațiilor precum JavaScript, TypeScript, JSON, CSS și HTML și permite, de
exemplu, vizualizarea proprietăților unui obiect, semnalarea greșelilor de sintaxă sau autocompletarea. VS
Code poate fi instalat pe macOS, Windows sau Linux oferind o portabilitate completă. Acest mediu de
programare în prezentul proiect a fost folosit pentru partea de front-end, o aplicație cross-platform (web și
android) dezvoltată în Ionic și Angular.

Node.js
Node.js (Node) este o platformă de dezvoltare open source pentru executarea codului JavaScript din
partea serverului. Nodul este util pentru crearea aplicațiilor care necesită o conexiune persistentă de la
browser la server. Node.js este destinat să ruleze pe un server HTTP dedicat și să folosească un singur
thread. Aplicațiile Node.js sunt bazate pe evenimente și se execută asincron. React este un framework
utilizat la scrierea aplicațiilor mobile reale pentru iOS și Android. Prezintă un mare avantaj, respectiv
faptul că este compatibil cu ambele sisteme de operare de pe telefoane mobile iOS și Android.

TypeScript
Este un limbaj de programare open-source dezvoltat, de a cărui mentenanță se ocupă Microsoft. Odată cu
digitalizarea globală majoritatea aplicațiilor au migrat către o variantă online. Până acum câțiva ani,
majoritatea acestor aplicații au fost scrise în JavaScript, însă pe măsură ce aplicațiile deveneau din ce în ce
mai mari, din cauza arhitecturii proiectului apăreau dificultăți în dezvoltarea acestora. Cei de la Microsoft
au dezvoltat și lansat în anul 2012 limbajul de programare TypeScript care este un super set de JavaScript.
Prin superset se înțelege că orice program scris în JavaScript poate fi compilat și în TypeScript. De
asemenea, codul scris în TypeScript, la compilare este transformat în cod Java Script putând fi astfel
interpretat cu ușurință de toate web browser-ele. Unul din cele mai populare framework-uri de JavaScript,
Angular, folosește ca limbaj de programare TypeScript, fiind din ce în ce mai utilizat în dezvoltarea de
aplicații web 36

10
 Angular Framework :
Angular este un framework open-source de JavaScript dezvoltat Google care permite construirea de
pagini folosind HTML și TypeScript. Acestea se diferențiază de cele rudimentare prin faptul că datele din
interiorul lor sunt încărcate dinamic. Structura unui proiect Angular cuprinde: module, componente,
servicii, pipe-uri, directive, legături. În cadrul proiectului am folosit Angular împreună cu Ionic pentru
realizarea unei aplicații cross-platform (aplicație web și mobile). Faptul că este un framework de
actualitate și compatibil cu Ionic m-au determinat să-l utilizez.

Ionic
Ionic este un SDK, complet open-source, utilizat pentru dezvoltarea aplicațiilor mobile hibride. Cea mai
recentă versiune a fost reconstruită ca un set de Web Components, care permite aleagerea oricărui cadru
de interfață de utilizator, cum ar fi angular, React sau Vue.js. De asemenea, permite integrarea
componentelor ionice, fără niciun cadru de interfață pentru utilizatori. Ionic oferă instrumente și servicii
pentru dezvoltarea de aplicații mobile, desktop și Web progresive bazate pe tehnologii și practici moderne
de dezvoltare, utlizând tehnici Web precum CSS , HTML5 și Sass . În special, aplicațiile mobile pot fi
construite cu aceste tehnologii și apoi distribuite prin magazinele native de aplicații pentru a fi instalate pe
dispozitive folosind Cordova sau Condensator.

Server Securizat
Varianta de server prestabilită este cu protocolul HTTP/1.1 pe portul 80, care necesită foarte multe criptări
și tot nu este o variantă sigură pentru că este nevoie de o cheie și această cheie se trimite într-un mod
nesecurizat pentru prima dată așa că am ales să folosesc protocolul HTTPS, care este varianta securizată
de la HTTP,HTTPS autentifică comunicarea server-client și client-server și oferă confidențialitatea
comunicării. Toată această securitate vine cu ”costuri majore” în latență,memoria folosită la nivel de
microcontroller,puterea de procesare, încalzirea microcontroller-ului față de modul obișnuit și consumul
de energie, dar care este insesizabil. SSL/TLS este un protocol standard pentru a asigura autentificarea și
confidențialitatea datelor transmise prin conexiuni TCP.SSL este o combinație între criptografia simetrică
și cea asimetrică , în felul acesta se face un compromis între performanță și securitatea transmisiei de
date.Cu această cheie simetrică, datele sunt criptate și decriptate cu ajutorul unei chei secrete pe care o
cunosc atât serverul cât și clientul. Cea mai sigură metodă de criptare este cea asimetrică. Aceasta cere
chei criptate care pentru o securitate sporită trebuie sa aibă între 128 și 256 de biți. Orice cheie cu mai
putin de 80 de biți este considerată nesigură. Cheile sunt de două feluri: una publică și una privată. Cu cea
publică se criptează informația iar cu cea privată se decriptează . Cele 2 chei sunt în strânsă legătură și
este foarte dificil să se facă reverse-engineer . Problema cu acest protocol este dacă se dorește criptarea
tuturor informațiilor conexiunea ar pica. Exemplu: Căsuța poștală: Putem să ne imaginăm cheia publică ca
locația unde se află casuța poștală și în acest caz cheia privată va fi cheia de la căsuța poștală. Cei care știu
unde se află casuța poștală pot pune un mesaj în ea, dar numai cel care are cheia poate să citească
mesajele din ea. TLS, care este o variantă înbunatățită de la SSL folosește doar criptografia asimetrică
încă de la începutul conexiunii pentru a cripta conversația dintre server și client. Trebuie să fie de acord cu
o singură cheie pe sesiune pe care amândoi o s-o folosească pentru a cripta pachetele de date de la acel
moment înainte.Criptarea folosind o cheie distribuită se numește criptare simetrică și este mult mai puțin
11
intensivă din punct de vedere al calculului decât criptarea asimetrică. Pe tot restul comunicării dintre
server și același client se va folosi doar o cheie publică. 38 În acest fel comunicarea este foarte sigură.
Procesul prin care se stabilește conexiunea dintre server și client se numește handshake și este momentul
în care TLS ia viață. Handshake: 1.Clientul contacteză serverul și cere o conexiune sigură. Serverul
răspunde cu o listă de algoritmi de criptare pe care o cunoaște. Clientul compară acea listă cu lista proprie
, selectează un algoritm și îi trasmite server-ului decizia. 2.Apoi server-ul oferă certificatul său digital care
este un document electronic ce confirmă identitatea server-ului.În acest certificat se află și cheia publică
pe care o vor folosi cele două părți pentru comunicarea sigură. 3.Folosind cheia publică a server-ului,
clientul și server-ul stabilesc o sesiune a cheii pe care amândoi o vor folosi pentru restul conexiunii. TLS
Vulnerabilități: POODLE(Padding Oracle On Downgraded Legacy Encryction) este o vulnerabilitate de
securitate care forțează trecerea de la TLS la SSL v3,un protocol care are 15 ani vechime și care a fost
înlocuit de TLS. Această forțare are loc prin intreruperea handshake-ului dintre server și client, rezultând
reîncercarea serverului de a lua legatura cu clientul folosind versiunea precedentă a protocolului. Odată ce
trecerea a avut succes, atacatorul poate exploata vulnerabilitățile protocolului mai vechi și poate
compromite (decripta) un byte.Repetând atacul îi permite acestuia sa decripteze mai mulți bytes și poate
avea acces la informații sensibile cum ar fi cookie sau parole. Mai mult acesta poate să intercepteze și să
modifice traficul din rețea. SECURITATEA ȘI BENEFICIILE. Pentru a întelege ce este securitatea și la
ce ne folosește am ales un exemplu: 39 Două persoane comunică la distanță prin canalul “Poștă”. Aceste
persoane tratează probleme delicate care nu trebuiesc interceptate. O a treia persoană știe că aceste
persoane discută și dorește să afle care este subiectul. Pentru a face acest lucru poate intercepta scrisoarea
înainte ca aceasta să ajungă la destinatar, poate sa o citească și să o resigileze sau să o modifice. Principiul
și în cazul Securității cibernetice este aproximativ același. Securitatea cibernetică se referă la urmatoarele
aspecte: 1.Autentificarea Autentificarea presupune asigurarea că entitatea care comunică este cea care
pretinde a fi. Serviciul de autentificare este conceput pentru a se asigura autenticitatea comunicației.
Serviciul de autentificare oferă control de acces pentru sisteme verificând dacă datele de identificare ale
unui utilizator se potrivesc cu cele de acreditare dintr-o bază de date a utilizatorilor autorizați sau dintr-un
server de autentificare a datelor. Pentru a nu fi necesară autentificarea de fiecare dată când se dorește
intrarea in aplicație , sistemele protejate se bazează pe autentificarea bazată pe jeton în care autentificarea
este efectuată o dată la începutul unei sesiuni. Sistemul de autentificare emite un token de autentificare
semnat pentru aplicația utilizatorului final, iar tokenul respectiv este anexat la fiecare solicitare din partea
clientului. 2.Confidențialitatea datelor. Confidențialitatea este măsura de protecție a transmisiei datelor
printr-un canal, în cazul nostru Internet. Confidențialitatea presupune: -Criptarea informațiilor sensibile.
Criptarea este un proces prin care datele devin imposibil de citit tuturor, cu excepția celor care dețin cheia
potrivită sau parola. 3.Integritea datelor: Integritatea precum confidențialitatea se pot aplica pentru un
pachet de mesaje, un singur mesaj sau pe câmpuri selectate, dar cea mai buna metodă de secutizare este
cea totală. O conexiune folosind un serviciu de integritate a datelor se asigură că mesajele sunt transmise
și primite fară ca acestea să fie duplicate, inserate, modificate sau înlocuite.

12
Modul de realizare

Pentru acesta am realizat o aplicatie pentru vanzarea de jocuri de societate folosind rest api-uri integrate in
partea de back-end realizata in ASP.NET care lucreaza foarte usor cu un server-ul mysql. Cateva dintre
aceste servicii sunt: Autentificarea autilizatorilor, inregistrarea conturilor acestora si scrierea informatiilor
in baza de date, crearea , serviciul de creare a jocului de societate, editarea , stergerea si postarea
acestora in interfata utilizatorului, serviciul de like , dislike pentru a obtine si un feed-back din partea
clientului , serviciul de creare order si punerea order-elor in tab-ul de istoric al utilizatorului. Pe langa
toate acestea se mai adauga si serviciul de plata.

Inregistrarea si autentificarea utilzatorilor se va face folosind framework-ul Entity care are anumite
campuri deja gandite pentru inregistrare , precum hash-ul parolei, confirmare cont ,etc . La acestea se vor
mai adauga informatiile de Audit pentru a avea si o evidenta cu privire la data crearii, autentificarii,
modificarii sau stergerii.

Crearea jocurilor se va face dupa un model ,asadar cand administratorul doreste sa creeze un nou joc
acesta trebuie sa respecte toate formatele parametrilor si totodata sa completeze toate campurile
obligatorii. Pentru un update de informatii se va trece doar parametrul care necesita modificat, stergerea se
va face dupa Id.

13
Arhitectura de servicii:

14
Arhitectura bazei de date:

15
Arhitectura Completa:

Arhitectura tabelei destinata userului:

16
Arhitectura Utilizatorilor

17
Arhitectura tabelei pentru produse:

Arhitectura tabelei Orders:

18
Inregistrarea utilizatorilor:
Se face dupa un model de request si acesta este:

Acest model se aplica functiei “Register” care practic va lua ca parametrii ce se afla in model.

O data ce in request-ul de tip POST sunt introduce aceste date ele vor popula baza de date cu ajutorul
IdentityDbContext avand ca parametru modelul IdentityUser + Informatiile de Audit

19
Ca pas urmator trebuie configurata baza de date , trebuie specificata calea catre unde se va genera baza de
date, apoi se creaza tabele respective.

Partea de documentatie pentru request-ul de POST descrie foarte bune cum se poate realiza inregistrarea
utilizatorilor cu success.

Pe partea clientului lucrurile stau in felul urmator.

Serviciul de inregistrare arata asa si foloseste libraria de HttpClient pentru a avea acces la functiile de
REST.

Iar acest serviciu este folosit in pagina destinata logarii de unde se apeleaza acest serviciu impreuna cu
parametrii username,userEmail si parola.

20
Practic se verifica daca parolele sunt identice si daca aceasta conditie este adevarata user-ul este directionat
catre pagina de login , dupa care se apeleaza Api-ul si informatiile sunt stocate in baza de date daca statusul
request-ul este 200 OK.

M-ai jos am ilustrat cum arata un raspuns 200 OK.

Acesta este principiul pe care functioneaza si restul requesturilor. Mai multe informatii gasiti in codul
sursa pe care il voi atasa la finalul documentului.

21
Etape Aplicatie mobile

Pentru a realiza aplicația mobilă a fost necesar:

1.Instalare Visual Studio Code

2.Instalare Node.js

1.Angular este un cadru complet nou și este scris în Typescript.

Deoarece browserul nu înțelege Typescript JS (adică, .ts), a trebuit să le compilez în JavaScript simplu,
adică .js.

Am descărcat și instalat Node.js de pe site-ul oficial. Folosind “command prompt” am instalat și

configurat Ionic cu ajutorul câtorva linii de comanda ilustrate mai jos

. npm install -g cordova ionic ionic start RentProducts

ionic generate page login

Pentru a nu fi nevoit să scriu dependețele pentru aplicație manual, am utilizat comenzi pentru a genera
paginile și serviciile.

Ulterior am putut să compilez un proiect gol.

ionic generate page register

ionic generate page login

ionic generate tabs

ionic generate page card-modal

ionic generate service token-interceptor

ionic generate service auth

ionic generate service register

ionic generate service order

22
Un proiect Ionic prezintă o parte de front-end și o parte de back-end. Partea de front-end este scrisă în
HTML5, iar partea de back-end este scrisă în TypeScript.

Pentru autententificarea utilizatorilor este nevoie de înregistrarea acestuia. Crearea contului se face prin
completarea unui formular de tipul celui atașat mai jos.

23
Pagina de login:

24
Tab-ul de localizare:

25
Aplicatia este construita din 3 tab-uri principale :

Acestea sunt :

Profil

Produse

Verifica

In tab-ul verifica se poate prelua adresa de la care se face request-ul

26
Tab-ul cu produse:

27
Tab-ul istoricul comenzilor:

28
 Evaluarea performantelor de sistem:

În general evaluarea performanțelor presupune: fiabilitatea, scalabilitatea, performanța și

securitatea.

Fiabilitatea – Aplicatia multi client – server este una fiabilila care poate rula non-stop cu ajutorul
platformelor oferite de diverse unelte de deploy precum Azure de la Microsoft sau AWS de la Amazon.

In momentul de fata aplicatia ruleaza doar local deoarece perioda subscriptiei gratis a expirat.

Scalabilitatea reprezintă un indicator ce măsoară cât de bine se comportă sistemul dacă

dimensiunea problemei pentru care el a fost proiectat să o rezolve crește. Pentru ca acest indicator să
devină unul concret este necesar să se stabilească ce poate să crească.

Avand in vedere ca dimensiunea necesara in momentul de fata pentru stocarea datelor este una
destul de mica (aproximativ 117 MB ) aplicatia ruleaza foarte bine.

Mai jos se pot vedea indicatorii de performanta cum ar fi CPU,Memory load si numarul de
evenimente in unitatea de timp in care serverul este pornit.

29
Performanta:

Performanta de pe front-end.

Asa cum se poate vedea in partea de jos indicatorii importanti de pe partea de front-end au valori foarte
bune ce determina o funtionare foarte buna .

Timpii de raspuns sunt de ordinul catorva milisecunde ceea ce confera fluiditate.

30
Securitatea:

Inregistrarea , Autentificarea si autorizarea s-a realizat prin intermediul pachetului UserManager pus la
dispozitie de Microsoft.

Dupa autentificare utilizatorul primeste un token de autorizare care expira dupa 10 minute. In tot acest
timp respectivul utilizator poate realiza evenimente in interiorul aplicatiei folosind respectivul token.

Daca token-ul nu este recunoscut atunci utlizatorul nu va mai avea permisiuni.

Testarea:
Testarea poate fi realizata foarte usor datorita arhitecturii sistemului iar principala unealta folosita a fost
Postman.

Portabilitatea

Reprezinta ușurința cu care o aplicație poate fi executată pe diverse platforme hardware și

software, de obicei este dependentă de tehnologia folosită pentru implementare;

Aplicatia poate fi portata cu usurinta, singurul impediment in acest fel ramand costul unui
subscriptii.

Integrarea este un indicator care măsoară ușurința cu care sistemul poate fi incorporat într-un
context de aplicații mai larg. De multe ori valoarea unei aplicații poate fi mărită dacă funcționalitatea sau
datele produse de aplicație pot fi folosite în alte moduri decât cele care au fost prevăzute de cel care a
proiectat aplicația. Cele mai folosite strategii de integrare sunt cele la nivelul datelor sau cele realizate
printr-o interfață API. Integrarea la nivelul datelor se poate realiza prin stocarea și manipularea datelor în
așa fel încât alte aplicații să le poată accesa. De exemplu, poate să fie suficient să se folosească o baza de
date relaționată pentru stocarea datelor

Aplicatia realizata integreaza MySql pentru a stoca si reprezenta datele pentru utlizitori.

31
 Etapele de realizare ale produselor software

1) Dezvoltarea unui produs software presupune etape de analiză, proiectare, scriere, testare,
debugging și mentenanță a codului sursǎ al programelor. Dezvoltarea unui produs software poate fi
folosită pentru a face referire la programarea calculatoarelor, însa într-un sens mai extins reprezintă
totalitatea activitaților de realizare ale unui produs software (= programarea calculatorarelor) ideal într-un
proces planificat și structurat. Scopul final este de a obține o soluție software eficientă și care poate evolua
în timp.

2) Etapele de realizare ale unui produs Implementarea, testarea, verificarea și validarea

produsului software sunt cele mai importante etape de realizare ale unui produs software. Pentru
înțelegerea lor este însă nevoie de cunoasterea tuturor etapelor. Deși sunt considerate etape separate, intre
ele există o puternică relație de interdependență.

2.1) Analiza cerințelor Analiza cerințelor este prima etapă a ciclului de realizare a unui produs în
care se stabilesc cerințele aplicației, pornind de la cerințele utilizatorului final, se identifică funcțiile
viitorului produs software precum și datele implicate. Această etapă răspunde la întrebarea ce se va realiza
prin dezvoltarea produsului software.

2.2) Proiectarea arhitecturii software Proiectarea reprezintă acea etapă a ciclului de realizare a
unui produs în care se stabilește modul de realizare a cerințelor identificate în etapa de analiză, adică
trebuie să raspundă la întrebarea cum se vor realiza aceste cerințe atât la nivel global cât și la nivel de
detaliu. Această etapă pornește deci de la cerințele și specificațiile definite anterior și continuă cu
detalierea și transformarea acestora până la definirea structurii unei soluții care să fie reprezentată folosind
un limbaj grafic, textual sau mixt. Proiectul astfel obținut trebuie să poata fi utilizat mai departe la
construirea sau elaborarea produsului software (codificare, testare, integrare).

2.3) Implementarea codului Implementarea codului reprezintă scrierea textului folosind formatul
și sintaxa unui limbaj de programare ales. Codul este special conceput pentru a facilita munca unui
programator, astfel oferin posibilitatea acestuia să specifice operațiile ce vor fi realizate de către
calculator. Odată ce un program a fost realizat el va fi convertit în cod binar numit cod mașină, care poate
apoi fi citit si executat.

2.4) Compilarea si interpretarea Compilarea reprezintă o metodă prin care calculatorul

convertește codul sursă scris într-un limbaj de programare (de cele mai multe ori un limbaj de nivel înalt
cum ar fi c++, Java) într-un limbaj de nivel jos (cod mașină sau assembler). În urma realizării acestei
operații se obține un fișier executabil ce poate fi înțeles și rulat de către mașina sau mașinile pentru care a
fost conceput.

Interpretorul reprezintă o metodă prin care mașina convertește codul sursă în cod mașină la
momentul în care acesta este rulat. Interpretorul poate fi un program care fie execută codul sursă direct,
fie transformă codul inițial într-un cod intermediar, iar acesta va fi încărcat pentru execuție, fie

32
interpretează codul care anterior a fost compilat de către un compilator care face parte din sistemul de
interpretare.

Fiecare din cele 2 variante are avantajele si dezavantajele sale. Spre exempul un compilator este
mai rapid în momentul execuției, însa interpretorul folosește principiul mașinii virtuale care oferă
avantajul siguranței datelor.

2.5) Documentarea În general documentarea se referă la procesul de a oferi dovezi. Documentarea

software sau documentarea codului sursă reprezintă text scris care exprimă modul de implementare al
programului, modul de folosire al acestuia, informații legate de testarea programului, modificări aduse
unei noi versiuni sau orice alte informații legate de programul respectiv. Există diferite tipuri de
documente: - Documente de cerințe software; - Documente de arhitectură și design; - Documente tehnice;
- Documente ale utilizatorului.

2.6) Integrarea Integrarea se referă la faptul că un modul poate fi integrat în interiorul unui alt
modul mai complex, sau că un modul mai complex poate fi realizat din mai multe module simple. Prin
integrare, datele sau informațiile oferite la ieșire de primul modul pot fi folosite de către un al doilea
modul ca valori de intrare cu condiția ca ambele module să respecte acelasi format la ieșire, respectiv
intrare.

2.7) Testarea software Testarea software reprezintă o investigatie dirijată în scopul de a obține
informații legate de calitatea produsului software realizat în etapele anterioare.

2.8) Debugging Debugging-ul reprezintă o metodă prin care se detectează și se elimina bug-urile
(erorile) unui program (sau, general vorbind, în orice componentă electronică), în scopul de a-l face să
funcționeze pe măsura așteptărilor. Aparent debug este echivalent cu testarea, însă prin termenul de debug
se intelege testarea, descoperirea cauzelor de eroare și rezolvarea acestor erori.

Debuggingul este puternic dependent de modul în care codul este implementat. Principala
problemă este aceea că orice modificare adusă codului poate să ducă la modificarea funcționalității
întregului program. Astfel este foarte important modul în care codul este realizat pentru a facilita
rezolvarea unor astfel de buguri. De aceea este necesară respectarea unor reguli de scriere a liniilor de cod
cum ar fi: coupling, încapsularea datelor, cohesion.

2.9) Verificarea și validarea software Verificarea asigură că produsul e construit în concordanță

cu cerințele, specifcațiile și standardele specificate. Validarea asigură că produsul va fi utilizabil pe piață.
2.10) Mentenanța Odată lansat pe piață un produs software nu înseamnă că este lipsit de erori. Mai mult,
deși produsul este funcțional, pot fi aduse înbunătățiri ulterioare. Astfel dupa apariția versiunii inițiale
procesele de implementare, testare, debug pot fi continuate.

2.11) Specificarea Specificarea (spec) reprezintă un set explicit de cerințe ce trebuiesc satisfacute
de un material, produs, sau serviciu. Astfel putem spune că specificarea reprezintă un

33
 Testarea reprezintă o etapă importantă în procesul de realizare a produselor software. Ponderea
cheltuielilor cu testarea reprezintă între 30% şi 50% din totalul cheltuielilor pentru dezvoltarea unei
aplicaţii software.

Tehnicile şi metodele moderne de elaborare a produselor software acordă o importanţă deosebită

efortului de înlăturare a erorilor de analiză, proiectare şi programare prin folosirea unor mijloace evoluate
de testare.

Testarea – etapă a ciclului de dezvoltare software

Proiectarea aplicaţiilor software de dimensiuni mari, dezvoltată în cadrul unei echipe, nu se face
trecând direct la implementarea programului, ci urmează etape bine stabilite. Procesul de dezvoltare
al aplicaţiilor software este alcătuit din următoarele etape: specificarea cerinţelor, analiză, proiectare,
implementare, testare şi întreţinere. În figura 1 este prezentat grafic modelul clasic de dezvoltare software
.

Figura 1 – Modelul clasic de dezvoltare software

34
 Ce este testarea regresiva?

Ori de câte ori dezvoltatorii își schimbă sau își modifică software-ul, chiar și o mică modificare
poate avea consecințe neașteptate. Testarea regresiva este testarea aplicațiilor software existente pentru a
ne asigura că o modificare sau o adăugare nu a afectat nicio funcționalitate existentă. Scopul său este de a
gasi erori care ar fi putut fi introduse accidental într-o nouă versiune sau de a elibera candidatul și de a se
asigura că erorile eradicate anterior continuă să rămână moarte. Executând din nou scenarii de testare care
au fost inițial scriptate atunci când problemele cunoscute au fost rezolvate pentru prima dată, ne putem
asigura că orice modificări noi aduse unei aplicații nu au dus la o regresie sau au cauzat eșecul
componentelor care funcționau anterior. Astfel de teste pot fi efectuate manual pe proiecte mici, dar în
majoritatea cazurilor repetarea unei suite de teste de fiecare dată când se face o actualizare este prea
consumatoare de timp și complicată pentru a fi luată în considerare, deci este de obicei necesar
un instrument automat de testare .

35
 Testarea de regresie este un tip specific de testare software-ului pentru a stabili că o modificare
recentă în software-ul sau setările programului nu afectează în mod negativ funcțiile existente.

Testul complet sau parțial al cazurilor de test efectuate anterior sunt efectuate din nou în timpul
testării de regresie. Astfel putem determina că funcționalitățile aprobate anterior sau cele existente
funcționează încă bine după modificare.

Aceste teste sunt făcute pentru a se asigura că noile modificări nu au efecte secundare negative
asupra funcționalității existente. Scopul este că vechiul cod va funcționa în continuare după ce au fost
făcute schimbări.

Necesitatea testelor de regresie:

Testarea prin regresie este necesară dacă există:

Modificările cerințelor și ale codului software sunt adaptate la această necesitate.

O nouă funcție adăugată software-ului.

Repararea erorilor și erorilor de procesare.

Rezolvarea problemelor de preformanță.

Tehnici de încercare prin regresie

Întreținerea software-ului se referă la îmbunătățiri, corecții de eroare, optimizare și eliminarea

funcțiilor existente ale software-ului. Aceste modificări pot determina funcționarea incorectă și
neobservată a software-ului. Testarea prin regresie este necesară pentru a stabili acest lucru. Testele de
regresie pot fi efectuate folosind următoarele tehnici:

1. Testați totul din nou

Aceasta este una dintre metodele de testare a regresiei, unde toate cazurile de testare din setul de
testare existent trebuie repetate. Acest lucru este foarte scump deoarece costă mult timp și resurse. Dacă
există un proiect, timpul și banii pentru acest lucru probabil că nu sunt chiar calculați în buget.

2. Selecția testului de regresie

În loc să executați din nou testul complet, este mai bine să selectați o parte din setul de test care
trebuie rulat.

Cazurile de testare selectate pot fi clasificate ca cazuri de testare reutilizabile sau cazuri de testare
depășite.

Clasele de testare reutilizabile pot fi utilizate în cicluri consecutive de regresie.

Exemplele de cazuri depășite nu pot fi utilizate în cicluri consecutive.

36
 3. Prioritizarea cazurilor de testare

Acordați prioritate anumitor cazuri de testare. În funcție de impactul asupra proceselor de afaceri,
sunt alese funcțiile critice și frecvent utilizate. Selectarea cazurilor de testare bazate pe prioritate va reduce
considerabil impactul testelor de regresie asupra proiectului.

Selectarea cazurilor de testare pentru testele de regresie

În practică, un număr mare de erori software raportate se datorează remedierilor de ultim moment.
Aceste remedii provoacă efecte secundare nedorite. De aceea, selectarea cazurilor potrivite de testare
pentru testele de regresie este o artă și nu atât de simplă. Teste eficiente de regresie se pot face prin
selectarea următoarelor cazuri de testare:

Testați cazuri care au descoperit frecvent erori în trecut.

Funcționalitate mai vizibilă pentru utilizatori.

Cazurile de testare care reprezintă cele mai importante caracteristici ale software-ului.

Testați cazurile de funcționalitate care sunt adesea și recent ajustate.

Toate cazurile de testare a integrării.

Toate cazurile complexe de testare.

Limita cazurilor de test.

Exemplu de cazuri de încercare de succes.

Exemplu de cazuri de încercare pentru eșecuri anterioare.

Teste de regresie și managementul configurației

Gestionarea configurației în timpul testelor de regresie este necesară într-un mediu Agile, unde
codul este în mod constant schimbat. Luați în considerare următoarele pentru a asigura testarea efectivă a
regresiei:

Gestionează codul testat pentru regresie folosind un instrument de gestionare a configurației.

Trebuie împiedicată implementarea modificărilor software sau ale setărilor în timpul testelor de
regresie. Codul testului de regresie trebuie să fie imun la schimbările de la dezvoltatori.

Baza de date utilizată pentru testele de regresie trebuie izolată. Nu se pot face modificări în baza
de date.

Diferența dintre testarea din nou și testarea regresiei

Retestarea înseamnă testarea din nou a funcționalității pentru a se asigura că eroarea a fost
corectată. Dacă nu este rezolvată, dezvoltatorul trebuie să o privească din nou. Dacă este rezolvată,
mesajul de eroare poate fi închis.

37
 Testarea prin regresie este mai degrabă o testare a integrării. Aceasta înseamnă că trebuie, de
asemenea, să testați piese personalizate în timpul proiectelor și lansărilor. Stabiliți dacă modificarea nu are
nicio influență asupra acestor părți ale software-ului.

Provocări în testele de regresie

Iată principalele provocări în timpul testelor de regresie:

Cu serii de regresie succesive, seturile de teste devin destul de mari. Datorită constrângerilor de
timp și buget, nu este posibilă efectuarea testului de regresie completă.

Reduceți numărul sesiunilor de testare în timp ce atingeți acoperirea maximă a testelor.

Determinarea momentului și frecvenței testelor de regresie. Este testat după fiecare modificare
sau la fiecare actualizare de construcție sau după o serie de corecții de erori sau prin lansare?

Concluzie

O strategie eficientă de regresie economisește o organizație atât timp, cât și bani. Conform unui
studiu de caz la bănci, testarea de regresie economisește până la 60% la corecțiile de erori (găsite în
timpul testării de regresie) și 40% la buget.

Testarea de integrare

Procesul de integrare al sistemului implică construirea unui sistem din componentele sale și testarea
sistemului rezultat pentru a releva orice defecte cauzate de interacțiunile între componente. Aceste
componente pot fi componente gata făcute, componente reutilizabile ce au fost adaptate pentru un tip
particular de sistem sau componente nou-dezvoltate. Pentru multe sisteme de mari dimensiuni, toate cele
trei tipuri de componente au șanse mari să fie utilizate. Testarea de integrare verifică faptul că aceste
componente funcționează împreună, sunt apelate corect și transferă datele corecte la momentele de timp
dorite prin interfețele lor.

Integrarea sistemului implică identificarea grupurilor de componente care oferă o capabilitate a

sistemului și integrarea acestora prin adăugarea de cod ce le permite funcționarea împreună. Uneori, se
dezvoltă întâi un schelet al sistemului, la care se adaugă componente. Acest tip de integrare se
numeste top-down. Alternativ, se pot integra întâi componentele de infrastructură ce oferă servicii
comune, precum accesul la rețea și la baza de date și apoi se pot adăuga componentele funcționale. Acest
tip de integrare se numește bottom-up. În practică, pentru multe sisteme se folosește o combinație a celor
două abordări. În cazul ambelor tipuri de integrare, este necesar cod adițional pentru a simula alte
componente și a permite sistemului să ruleze.

38
 O problemă majoră în cadrul testării de integrare o reprezintă localizarea erorilor. Interacțiunile
între componentele sistemului sunt complexe și atunci când se descoperă rezultate eronate, se poate
dovedi dificilă indentificarea originii defectului. Pentru a ușura localizarea erorilor, este de preferat o
abordare incrementală, pornind de la integrarea unei configurații minimale a sistemului și testarea
acesteia. Se adaugă apoi componente la aceasta configurație și se testează dupa fiecare iterație.

În exemplul din Fig. 3, A, B, C și D sunt componente iar elementele de la T1 la T5 sunt seturi de

teste incorporate în sistem. T1, T2 și T3 sunt rulate inițial pe un sistem compus din componenta A si
componenta B ( sistemul minimal ). Dacă apar defecte, acestea sunt corectate. Componenta C este
integrată și T1, T2, T3 sunt repetate pentru a asigura că nu au apărut interacțiuni neprevăzute cu A și B.
Daca apar probleme în aceste teste, cel mai probabil sunt cauzate de interacțiunea cu noua componentă.
Sursa problemei este localizată, astfel simplificând descoperirea și repararea defectului. Setul T4 este rulat
pe sistem. În final, componenta D este integrată și testată utilizând testele deja existente și setul T5.

Când se planifică integrarea, trebuie decis între ordinea integrării și ordinea componentelor. În
cazul în care clientul este implicat în procesul de dezvoltare și decide ce funcționalitate trebuie inclusă la
fiecare iterație a sistemului, integrarea sistemului se axează pe prioritățile clientului. În alte abordări ale
dezvoltării, când sunt integrate componente gata făcute și componente dezvoltate special, clientul nu este
implicat și echipa de integrare decide prioritățile.

În astfel de cazuri, o regulă generală este integrarea prioritară a componentelor care

implementează funcționalitatea cea mai des utilizată. Astfel, cele mai utilizate componente vor fi testate
cel mai mult. În practică însă, implementarea funcționalităților de sistem poate fi impărțită pe mai multe
componente și pentru a testa o capabilitate nouă, vor trebui integrate multiple componente diferite.
Testarea poate dezvălui erori în interacțiunile dintre aceste componente și alte părți ale sistemului, iar
repararea se poate dovedi dificilă, deoarece un întreg grup de componente care implementează o
funcționalitate a sistemului vor trebui schimbate. Mai mult, integrarea și testarea unei noi componente

39
poate schimba tiparul interacțiunilor între componente care au fost deja testate. Pot apărea defecte care nu
au fost expuse în testele efectuate pe configurația mai simplă.

Astfel, la integrarea unei noi iterații, este important să se ruleze și testele din iterațiile anterioare
precum și noile teste necesare pentru a verifica noua funcționalitate a sistemului. Rularea unui set existent
de teste se numește testare de regresie. Daca aceasta expune probleme, trebuie verificat dacă problemele
survin din iterația anterioară și pe care noua iterație le-a expus, sau dacă acestea sunt cauzate de
incrementul de funcționalitate adăugat.

Testarea de regresie este în mod evident un proces costisitor și este impractic fără automatizare. În
combinație cu un framework de testare precum JUnit, testele pot fi rulate în mod automat.

Testarea intregului sistem (testarea de lansare).

Testarea la lansare este procesul de testarea a unei versiuni a sistemului care va fi distribuită
clienților. Principalul obiectiv al acestui proces este de creștere a încrederii dezvoltatorului în capacitatea
sistemului de a întruni cerințele. Pentru a demonstra faptul că sistemul întrunește cerințele, trebuie arătat
că acesta oferă funcționalitatea, performanța și fiabilitatea specificată și că nu cedează în condiții de
utilizare normală.

Testarea la lansare este de obicei un proces de tip “black-box”, în care testele sunt derivate din
specificațiile sistemului. Sistemul este tratat ca o cutie neagră, al cărei comportament poate fi determinat
numai prin studierea intrărilor și ieșirilor sale. Alt nume folosit este cel de testare funcțională, deoarece
tester-ul urmărește doar funcționalitatea și nu și implementarea software-ului.

40
 Fig. 4 ilustrează modelul unui sistem în testarea funcțională. Tester-ul oferă intrări către
componentă sau sistem și examinează ieșirile corespunzătoare. Daca ieșirile nu sunt cele prezise ( ieșirile
sunt în setul Oe), testul a detectat o problema cu produsul.

Atunci când se testează versiuni ale sistemului, trebuie încercat să se “strice” software-ul, alegând
cazuri de test care se află în setul Ie din Fig. 4, adică intrări care au o probabilitate ridicată de a genera
erori de sistem( ieșiri în setul Oe).

Există un set de reguli care crește probabilitatea ca testele de defecte să aibă succes:

Se aleg intrări care forțează sistemul să genereze toate mesajele de eroare

Se proiectează intrări care cauzează depășirea bufferelor de intrare

Se repetă aceeași intrare sau set de intrări în repetate rânduri

Se forțează generarea de ieșiri eronate

41
Se forțează rezultatele calculelelor să fie prea mari sau prea mici

Tool-uri de testare folosite:

Postman

Swagger

Concluzii:

Aplicația dezvoltată poate fi folosită de către orice persoană având o interfață pentru utilizator intuitivă. Necesită logarea
o singură dată. Adminstratorul deține informații importante despre starea de funcționare a sistemului. Astfel, la cea mai
mică nesincronizare va ști că există o problemă.
Sistemul este gândit la număr nelimitat de utilizatori. Aceștia pot avea configurații diferite în funcție de dorința fiecăruia.

Siguranța datelor utilizatorilor este foarte importantă și de aceea, între client și server se află o conexiune sigură de tipul
TLS. Intrarea în aplicație are reguli foarte stricte. În felul acesta se asigură o securitate sporită în ceea ce privește
integritatea datelor.

Problemele întâmpinate au fost de natură software.

Software:
Am avut neclarități în a folosi JSON. Este un format nou pentru mine și mi-a luat mult timp
pentru al înțelege. Am avut probleme în ceea ce privește formatul bazei de date și cum se folosește.

42
Bibliografie
1.[CNS]Cryptography and Network Security ediția a 4-a ,William Stallings.
2.[IF]Ionic Framework
3. [Hur20] – B. Hurezeanu, Rețele de calculatoare, Note de curs, 2020, F.A.C.E.U.C.V.
4.[NC09]- Criptografie, Nicolae Constantinescu ,Editura Academiei Romane,2009

Codurile sursa se gasesc pe github la link-urile

https://github.com/ManeaAlex23/STORE/tree/main Server
https://github.com/ManeaAlex23/BoardGames Client

43