Documentul de Proiectare a Soluției Aplicației Software

Versiune 1.0
16 octombrie, 2023

Aplicație de ticketing

Echipa 1, C114A
Product Owner Ștefănescu Ștefania
Scrum Master Cioloca Paul
Developer Avrămescu Răzvan
Developer Caran Raluca
Developer Luncanu Cezica
Developer Tudor Erick
 Cuprins

1. Scopul documentului
2. Obiective
3. Conținutul documentului
4. Modelul datelor
4.1. Descrierea bazei de date
5. Modelul arhitectural și modelul componentelor
5.1. Arhitectura sistemului
5.2. Descrierea componentelor
5.3. Diagrama de clase
6. Modelul interfeţei cu utilizatorul
6.1. Ferestrele aplicaţiei
7. Elementele de testare

2
 1. Scopul documentului

Acest document este elaborat pentru a furniza un cadru detaliat si structurat

pentru proiectarea tehnica a aplicatiei noastre de ticketing. Scopul principal al
acestui document este de a descrie athitectura sistemului, componente,
module,interfete si date, oferind o imagine clasa a modului in care cerintele
functionale si nefunctionale identificate in SRS vor fi indeplinite. Prin descrierea
detaliata a arhitecturii sistemului, design-ul interfetelor, a modelului de date si a
procedurilor de securitate, SDD-ul asigura ca toate aspectele tehnice sunt abordate
in mod coeziv si conform cu viziunea si obiectivele proiectului.
Acest document urmareste sa asigure alinierea dintre designul tehnic si a
cerintelor utilizator, maximizand eficienta dezvoltarii si contribuind la succesul
general al implementarii aplicatiei de ticketing.

2. Obiective

 Definirea arhitecturii sistemului : detalierea structurii sistemului, inclusiv

arhitectura hardware si software, pentru a asigura ca aplicatia este bine
organizata.
 Descrierea componentelor si a modulelor: identificarea si descrierea
componentelor individuale ale sistemului.
 Proiectarea interfetelor de utilizator (un design orientativ).
 Modelarea bazei de date.
 Descrierea fluxurilor de lucru.
 Asigurarea performantei si scalabilitatii.
 Testarea si mentenanta.

3. Conținutul documentului

Documentul de Proiectare a Sistemului (System Design Document - SDD)

pentru aplicatia de ticketing contine cinci sectiuni principale care definesc structura
si detaliile tehnice necesare pentru realizarea si implementarea solutiei.
Capitolul 1: Scopul documentului
Acest capitol stabileste scopul si intentia SDD, introducand cititorul in
obiectivele si asteptarile echipei de proiect pentru aplicatia de ticketing.
Capitolul 2: Obiective

3
 Prezinta obiectivele specifice ale documentului, detaliind structura
sistemului si componentele cheie care vor fi folosite pentru a indeplini cerintele
functionale si nefunctionale identificate in SRS.
Capitolul 3: Continutul documentului
Ofera o imagine de ansamblu asupra structurii documentului, cu o descriere
detaliata a fiecarei parti, inclusiv modelul datelor, modelul arhitectural si modelul
componentelor.
Capitolul 4: Modelul datelor si Descrierea bazei de date
Descrie schema bazei de date si structura tabelelor care vor fi utilizate in
cadrul aplicatiei, cum ar fi utilizatori, roluri, tipuri de tickete si starea ticketelor.
Capitolul 5: Modelul arhitectural si modelul componentelor
Detaliaza arhitectura sistemului si componente specifice, cum ar fi modulul
Front-End cu framework-uri precum Angular sau React si implementarea bazata pe
JWT, modulul de Securitate, modulul de Backend folosind Spring, si modulul
Bazei de Date cu PostgreSQL.
Capitolul 6: Modelul interfetei cu utilizatorul si Ferestrele aplicatiei
Prezinta designul interfetei utilizatorului si cum vor interactiona utilizatorii
cu diferitele pagini ale aplicatiei, precum paginile de login, inregistrare si pagina
principala.
Capitolul 7: Elementele de testare
Detaliaza strategiile si metodele de testare care vor fi utilizate pentru a
asigura calitatea si performanta aplicatiei, inclusiv testarea UI, serviciilor REST,
bazei de date si stocarii de obiecte, folosind instrumente precum React Testing
Library, Jest, Swagger, Mockito, DBUnit si GitLab CI pentru automatizarea
testelor.

4
 4. Modelul datelor

4.1. Descrierea bazei de date

Modelul bazei de date este format din tabele inter-relationale ca in figura de

mai jos:

Schema bazei de date cuprinde urmatoarele tabele:

Users_roles - retine rolurile utilizatorilor

Id - identificatorul numeric al rolului
Type - denumirea rolului

Users - retine informatii despre fiecare utilizator al aplicatiei

Id - identificatorul numeric al utilizatorului
Username - username-ul prin intermediul caruia utilizatorul isi va accesa contul
Password - parola prin intermediul careia utilizatorul isi va accesa contul
First_name - prenumele utilizatorului
Last_name - numele utilizatorului
Email - adresa de email a utilizatorului
Role_id - referinta catre identificatorul rolului utilizatorului(din tabela Users_roles)
Register_time - data si ora la care utilizatorul si-a creat contul

Tickets_types - retine categoria din care poate face parte un ticket

Id - identificatorul numeric al tipului ticket-ului
5
Type - numele categoriei

Tickets_state - retine starea in care se poate afla ticket-ul

Id - identificatorul numeric al statusului ticket-ului
State - numele starii

Tickets
Id - identificatorul numeric al ticket-ului
User_id - referinta catre identificatorul user-ului care a depus ticket-ul(din tabela
Users)
Category_id - referinta catre identificatorul categoriei ticket-ului(din tabela
Tickets_types)
Descriere - descrierea problemei pentru care a fost depus ticket-ul
State_id - referinta catre identificatorul starii ticket-ului(din tabela Tickets_state)
Worker_id - referinta catre identificatorul worker-ului care a preluat ticket-ul(din
tabela Users)
Privacy - o valoare booleana care va indica daca ticket-ul este privat sau nu
Creating_time - data si ora la care s-a creat ticket-ul
Rating - o nota pe care o poate da user-ul care a depus ticket-ul in functie de cat de
satisfacut a fost de raspuns
Response_time - data si ora la care s-a raspuns la ticket

Tickets_comments
Id_ticket - referinta catre identificatorul ticket-ului la care a fost lasat
comentariu(din tabela Tickets)
Id_user - referinta catre identificatorul user-ului care a lasat comentariul(din tabela
Users)
Comment - comentariul lasat la ticket
Time - data si ora la care a fost lasat comentariul

5. Modelul arhitectural și modelul componentelor

6
 5.1. Arhitectura sistemului

5.2. Descrierea componentelor

 Modulul Front-End
-Framework-uri Utilizate: Angular sau React, în funcție de preferințele
echipei și cerințele proiectului.
-Implementare bazată pe JWT (JSON Web Tokens) pentru autentificarea și
autorizarea utilizatorilor.
-Submodule:
o Autentificare JWT: Implementarea unui sistem de autentificare care
utilizează JWT pentru a asigura securitatea sesiunilor utilizatorilor.
o Componente de UI: Crearea unei interfețe utilizator atrăgătoare și
intuitive, adaptată la nevoile utilizatorilor.
o Comunicarea cu Backend: Realizarea cererilor HTTP către serviciile
REST, pentru a interacționa cu backend-ul aplicației.

 Modulul de Securitate
-Validarea Inputurilor: Asigurarea că toate datele introduse de utilizatori sunt
validate corespunzător pentru a preveni atacurile și erorile.

7
  Modulul de Backend - Rest Service
-Utilizarea Spring: Crearea unei aplicații robuste folosind Spring
Framework.
-Submodule:
o Controller Rest: Gestionarea cererilor și răspunsurilor HTTP.
o Autentificare și Autorizare: Utilizarea Spring Security pentru
validarea JWT-urilor.
o Integrarea cu Baza de Date: Folosirea Spring Data JPA pentru
interacțiunea cu baza de date PostgreSQL.
o Gestionarea Excepțiilor: Asigurarea că toate erorile sunt gestionate
corespunzător.

 Modulul Baza de Date

-Utilizarea PostgreSQL: Implementarea unei baze de date relaționale
robuste.
-Submodule:
o Schema Bazei de Date: Definirea tabelelor și relațiilor.
o Optimizare: Implementarea procedurilor stocate, triggerelor și view-
urilor pentru a optimiza performanța.

 Modulul de Stocare
-Submodule:
o Bucket Management: Crearea și gestionarea bucketurilor pentru
diferite tipuri de date.
o Integrarea cu Backend-ul: Asigurarea unei conexiuni fluente între
stocarea de date și backend.
o Back-Up & Recuperare: Implementarea unor soluții de backup și
restaurare a datelor.

 Modulul de Infrastructură și Implementare

-Utilizarea Kubernetes (k8s) pentru orchestrarea containerelor.
-Submodule:
o Configurarea Clusterelor: Setarea și optimizarea clusterelor
Kubernetes.
o Deployment: Implementarea și desfășurarea aplicațiilor.
o Load Balancing: Asigurarea distribuției echilibrate a traficului către
aplicații.
o Logging: Monitorizarea și înregistrarea activităților sistemului.

8
 o Automatizare CI/CD: Implementarea unor pipeline-uri de integrare și
livrare continuă pentru a facilita dezvoltarea rapidă și eficientă.

 Modulul de Testare
-Utilizarea GitLab CI: Implementarea unui sistem de integrare continuă
pentru testarea codului.
-Submodule:
o Teste de Securitate: Verificarea aplicației împotriva vulnerabilităților
de securitate.
o Teste Unitare: Asigurarea funcționării corecte a fiecărei componente
în parte.
o Teste de Automatizare: Utilizarea testelor automate pentru a
eficientiza procesul de testare.
o Teste de Performanță: Evaluarea aplicației sub diferite condiții de
încărcare pentru a asigura stabilitatea și scalabilitatea.

5.3. Diagrama de clase

Diagrama UML de mai jos a claselor care vor fi implementate, descrie

componentele si relatiile dintre acestea.

9
 6. Modelul interfeței cu utilizatorul

6.1. Ferestrele aplicației

Prima pagina a site-ului web va pune la dispozitie optiunile de Login, Register si
Guest.

Daca se va selecta optiunea de “Login”, pagina de Login va arata astfel.

Pentru a merge mai departe la “Home”, dupa completarea campurilor
“Username” si “Password”, se va apasa butonul de “continue” din coltul din
dreaptajos.

10
 Daca se va selecta optiunea “Register”, pagina de Register va arata astfel.
Pentru a merge mai departe la “Home, dupa completarea campurilor “Full Name”,
”Username”, ”Email”, “Password”, se va apasa butonul de “continue” din coltul
din dreapta jos.

Daca se va selecta optiunea “Guest”, pagina de Guest va arata astfel. Pentru

a merge mai departe la “Home”, dupa completare campului “Email”, se va apasa
butonul de “continue” din coltul din dreapta jos.
11
 Pagina de Home va expune toate intrebarile (de la cele mai recente) care
sunt publice pe site. In partea din dreapte vor fi intrebarile la care s-a raspuns cel
mai recent, in plus vor mai fi afisate si topicurile cele mai intalnite in cadrul
intrebarilor.
In partea din stanga se va gasi o lista care va fi universala pentru restul
paginilor web, pentru o selectie mai rapida.

12
 7. Elemente de testare

 Web UI
-Testare: uilizarea React Tesing Libray si Jest pentru a simula
interactiunea utilizatorilor si pentru a verifica corectitudinea randarii
aplicatiei. Testarea autentificarii JWT pentru simulari de cereri si raspunsuri
valide si invalide.
-Teste unitare
 REST Service
-Testare: Utilizarea Swagger pentru a testa si valida endpoint-urile
REST. Folosirea Mockito pentru a simula logica aplicatiei si pentru a testa
serviciul fara a depinde de baza de date sau de alte servicii externe
-Teste unitare
 Database:
-Testare:Folosirea DBUnit pentru a popula baza de date cu date de test
si pentru a valida interogarile.
-Teste unitare
 Object Storage(MinIO)
-Testare:Scrierea de teste unitare pentru a valida operatiunile de
upload si download zle fisierelor, verificarea integritatii datelor si a
permisiunilor de acces.

Automatizarea testelor: configurarea unui pipeline in GitLab CI pentru a

automatiza testarea unitara , integrarea si testele de performanta. Pipeline-ul va rula
testele la fiecare push in repository, asigurand faptul ca modificarile nu afecteaza
negativ componentele existente.

13