• No se han encontrado resultados

Agregador de compres per a PIMES

N/A
N/A
Protected

Academic year: 2023

Share "Agregador de compres per a PIMES"

Copied!
79
0
0

Texto completo

(1)

Agregador de compres per a PIMES

Lluís Torroja Fontanet Grau d’Enginyeria Informàtica Java EE

Albert Grau Perisé Santi Caballe Llobet

Gener 2023

(2)

Aquesta obra està subjecta a una llicència de R e c o n e i x e m e n t - N o C o m e r c i a l -

(3)
(4)

Llicències alternatives (triar alguna de les següents i substituir la de la pàgina anterior)

A) Creative Commons:

Aquesta obra està subjecta a una llicència de R e c o n e i x e m e n t - N o C o m e r c i a l - SenseObraDerivada 3.0 Espanya de Creative Commons

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-CompartirIgual 3.0 Espanya de Creative Commons

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial 3.0 Espanya de Creative Commons

Aquesta obra està subjecta a una llicència de Reconeixement-SenseObraDerivada 3.0 Espanya de Creative Commons

Aquesta obra està subjecta a una llicència de Reconeixement-CompartirIgual 3.0 Espanya de Creative Commons

Aquesta obra està subjecta a una llicència de Reconeixement 3.0 Espanya de Creative Commons

B) GNU Free Documentation License (GNU FDL)

Copyright © 2023 Lluís Torroja Fontanet.

Permission is granted to copy, distribute and/or modify this document under the terms of the

(5)

or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back- Cover Texts.

A copy of the license is included in the section entitled "GNU Free Documentation License".

C) Copyright

© Lluís Torroja Fontanet

Reservats tots els drets. Està prohibit la reproducció total o parcial d'aquesta obra per qualsevol mitjà o procediment, compresos la impressió, la reprografia, el microfilm, el tractament informàtic o qualsevol altre sistema, així com la distribució d'exemplars mitjançant lloguer i préstec, sense l'autorització escrita de l'autor o dels límits que autoritzi la Llei de Propietat Intel•lectual.

(6)

FITXA DEL TREBALL FINAL

Títol del treball: Agregador de compres per a PIMES Nom de l’autor: Lluís Torroja Fontanet

Nom del consultor/a: Albert Grau Perisé Nom del PRA: Santi Caballe Llobet Data de lliurament (mm/aaaa): 01/2023

Titulació o programa: Grau d’Enginyeria Informàtica Àrea del Treball Final: Java EE

Idioma del treball: Català

Paraules clau microserveis, single-page application (spa), docker

Resum del Treball (màxim 250 paraules): Amb la finalitat, context d’aplicació, metodologia, resultats i conclusions del treball

Aquest projecte vol encarar la problemàtica de preus que ens afecta a tots, però de manera especial, a les petites i mitjanes empreses (PIMES), que conformen el teixit econòmic del nostre país.

La unió fa la força. Basant-nos en aquesta idea, volem proposar una aplicació que faciliti l'agrupació de petites comandes - de restaurants, bars i petits comerços - en grans encàrrecs comercials, obtenint, al cap i a la fi, unes millors condicions de compra i sobretot de preu. La mida importa.

Per a realitzar aquesta aplicació caldrà estudiar quines funcionalitats haurà de proveir, quins tipus d'usuaris (i el volum d'aquests) n'hauran de fer ús, i quines característiques - model de dades, lògica de negoci i arquitectura - caldrà implementar i com.

Començant amb un disseny en cascada inicial, anirem organitzant les tasques i refinant els resultats parcials assolits tot aplicant metodologies àgils, amb taulers Kanban i sprints Scrum de dues setmanes.

El resultat final de tot el procés serà una aplicació web, àgil i intuïtiva, que s'adapti a les canviants càrregues de treball, donant servei a les funcionalitats planificades, sense perdre qualitat en el servei prestat.

(7)

Abstract (in English, 250 words or less):

This project aims to address the price problem that affects us all, but especially small and medium-sized enterprises (SMEs), which make up the economic fabric of our country.

Unity is strength. Based on this idea, we want to propose an application that facilitates the grouping of small orders - from restaurants, bars and small businesses - in large commercial orders, obtaining, at the end of the day, better purchasing conditions and above all, better prices. Measurement matters.

To realize this application, it will be necessary to study which functionalities it will have to provide, which types of users (and the volume of these) will have to make use of it, and which features - data model, business logic and architecture - will have to be implemented and how.

Starting with an initial waterfall design, we will organize the tasks and refine the partial results achieved by applying agile methodologies, with Kanban boards and two-week Scrum sprints.

The end result of the whole process will be a web application, agile and intuitive, that adapts to changing workloads, serving the planned functionalities, without losing quality in the service provided.

(8)

Índex

1. Introducció ...1

1.1 Context i justificació del treball ...1

1.2 Objectius del treball ...1

1.2.1 Objectius generals ...2

1.2.2 Objectius específics ...2

1.2.3 Objectius personals i didàctics ...2

1.3 Enfocament i mètode seguit ...3

1.4 Planificació del treball ...3

1.5 Breu sumari de productes obtinguts ...6

1.6 Breu descripció dels altres capítols de la memòria ...6

2. Especificació dels requisits del sistema ...8

2.1 Requisits funcionals ...9

2.2 Requisits no funcionals ...10

2.3 Model casos d’ús ...10

2.4 Fitxes casos d’ús ...12

2.4.1 Registre d’un comprador al sistema ...12

2.4.2 Registre d’un comercial al sistema ...13

2.4.3 Identificar-se al sistema (login) ...13

2.4.4 Sortir del sistema (logout) ...13

2.4.5 Modificar dades d’usuari d’un comprador ...14

2.4.6 Cerca d’un producte per nom i/o descripció ...14

2.4.7 Llistar productes d’una categoria ...14

2.4.8 Consultar la informació d’un producte ...15

2.4.9 Marcar / Desmarcar un producte com a favorit ...15

2.4.10 Llistar productes favorits ...16

(9)

2.4.12 Consultar la informació d’una oferta ...16

2.4.13 Realitzar petició de compra ...17

2.4.14 Llistar peticions de compra ...17

2.4.15 Cancel·lar petició de compra ...17

2.4.16 Llistar històric de compres ...18

2.4.17 Gestionar categories (alta, consulta, modi. i esborrat) ...18

2.4.18 Gestionar productes (alta, consulta, modi. i esborrat) ...19

2.4.19 Gestionar proveïdor (alta, consulta, modi. i esborrat) ....20

2.4.20 Gestionar ofertes (alta, consulta, modi. i esborrat) ...20

2.4.21 Confirmar peticions de compra ...21

2.4.22 Avisos d’últimes ofertes ...21

2.5 Diagrames UML processos centrals del sistema ...22

2.6 Diagrama de classes ...23

3. Anàlisis i disseny de l’arquitectura ...24

3.1 Arquitectura global ...24

3.2 Arquitectura frontend ...25

3.3 Arquitectura backend ...26

3.3.1 Subsistemes, serveis, microserveis ...26

3.3.2 API Gateway ...28

3.3.3 JWT ...28

3.3.4 Comunicació entre microserveis ...29

3.3.4.1 Messaging ...29

3.3.5 Infraestructura ...30

3.3.6 Diagrama resum arquitectura, eines i frameworks ...31

4. Disseny relacional de la base de dades ...33

5. Implementació ...38

5.1 Frontend ...38

5.1.1 VueJS ...38

5.2 Backend ...40

(10)

5.2.1 Spring Boot ...40

5.2.2 API Gateway ...42

5.2.3 JWT ...43

5.2.3.1 Autenticació ...44

5.2.3.2 Autorització ...45

5.2.3.3 CORS ...48

5.2.4 Comunicació entre microserveis ...48

5.2.4.1 Kafka ...48

5.2.5 Infraestructura ...50

5.2.5.1 Config server ...51

5.2.5.2 Zipkin ...51

5.2.5.3 ELK ...52

5.2.5.4 Docker i Docker Compose ...54

5.2.5.5 Azure ...56

6. Pantalles de mostra ...58

7. Conclusions ...60

8. Glossari ...61

9. Bibliografia ...66

(11)

Llista de figures

Fig 1: Planificació inicial ...4

Fig 2: Evolució planificació inicial ...5

Fig 3: Tasques sprint 2 (Happy Path) ...5

Fig 4: Panell Kanban estat treball ...6

Fig 5: Casos d’ús del mòdul d’autenticació i autorització. ...10

Fig 6: Casos d’ús del mòdul de catàleg de productes. ...11

Fig 7: Casos d’ús del mòdul d’ofertes de productes. ...11

Fig 8: Casos d’ús del mòdul de compres. ...12

Fig 9: Diagrama seqüència petició de compra ...22

Fig 10: Diagrama estats petició de compra ...22

Fig 11: Diagrama de classes ...23

Fig 12: Arquitectura client-servidor de 3 capes (MVC) ...24

Fig 13: Descomposició per subdominis ...27

Fig 14: Microservei i Spring Boot ...27

Fig 15: Api gateway i subdominis ...28

Fig 16: Fluxe JWT token ...29

Fig 17: Comunicació asíncrona, Messaging ...30

Fig 18: Diagrama resum disseny arquitectura ...31

Fig 19: Disseny relacional de la base de dades en monòlit ...33

Fig 20: Distribució entitats entre subsistemes ...34

Fig 21: Model dades subsistema AuthAuth ...34

Fig 22: Model dades subsistema Catàleg ...35

Fig 23: Model dades subsistema Compres ...36

Fig 24: Model dades subsistema Ofertes ...36

Fig 25: App agregador-compres en execució ...38

Fig 26: State management pattern ...39

Fig 27: Estructura directoris Vue JS ...40

(12)

Fig 28: Estructura directoris Microserveis ...41

Fig 29: Codi RestController, Service i Entity (ex: Afegir categoria) 42 Fig 30: Codi redireccions gateway a microserveis finals ...43

Fig 31: Codi obtenció endpoint destí ...43

Fig 32: Codi general autenticació ...44

Fig 33: Codi generació del token ...45

Fig 34: Codi on s’intercepta crida REST i se’n verifica el token ...46

Fig 35: Codi on s’intercepta crida REST i se’n verifica el token ...46

Fig 36: Codi amb anotació @UsuariToken ...47

Fig 37: Codi per obtenir les dades de l’usuari del token ...47

Fig 38: Codi gestió CORS ...48

Fig 39: Topic kafka ...48

Fig 40: Codi missatge Kafka producer ...49

Fig 41: Codi configuració producer ...49

Fig 42: Codi missatge Kafka consumer ...50

Fig 43: Codi configuració consumer ...50

Fig 44: Codi configuració servidor de configuracions ...51

Fig 45: Vista del projecte git amb els fitxers de propietats i branques ...51

Fig 46: Vista traça log zipkin ...52

Fig 47: Stack ELK dockeritzat ...53

Fig 48: Crear index a kibana per poder cercar logs ...53

Fig 49: Vista Kibana de cerca ...54

Fig 50: Azure registre imatges docker ...56

Fig 51: Azure imatges ...57

Fig 52: Azure contenidors ...57

Fig 53: Azure agregador de compres ...57

Fig 54: Productes ...58

Fig 55: Detall Producte ...58

(13)

Fig 56: Petició compra ...59

Fig 57: Agrupació de compres ...59

Fig 58: Avis compra formalitzada ...59

(14)

1. Introducció

1.1 Context i justificació del treball

Anys 2022 - 2023. El món està en crisis. Una crisi que té molts factors desencadenants, a la majoria dels quals no hi podem plantar cara, per magnitud i complexitat.

D'entre els factors causants i conseqüències de la crisi, veiem la possibilitat de poder abastar-ne un en particular, un dels que causa més perjudicis al teixit econòmic del país i a les butxaques dels ciutadans. La pujada de preus de productes, matèries primeres i subministraments varis.

Catalunya i la seva àrea d'influència es caracteritza per un teixit econòmic conformat per milers de petits i mitjans negocis, PIMES. Un model d'èxit, en creació de riquesa i ocupació, que perdura,, però que està en perill. I com sempre passa, no podem esperar gran cosa de les administracions, no només per decisions polítiques qüestionables, sinó sobretot per la seva lentitud d'adaptació als problemes del món real.

Les grans empreses, hòldings... poden afrontar aquesta problemàtica amb més eines. Ja sigui per la seva influència en sectors de poder, pel seu múscul financer o per la seva gran capacitat de compra, cosa que e l s p e r m e t n e g o c i a r u n e s c o n d i c i o n s c o m e r c i a l s m o l t favorables, inabastables per les petites i mitjanes empresa.

Per tal d'omplir aquests buits legislatius, i aquest 'mercat' tan desigual, proposem ajudar les nostres PIMES, amb la creació d'una aplicació que permeti agrupar petites compres en grans comandes.

Aquesta aplicació presentaria als nostres potencials clients, molts petits compradors, una sèrie d'ofertes comercials, prèviament negociades pels nostres experts en grans comptes.

L'agrupació de petites compres, una vegada satisfessin les condicions de l'oferta a la qual estiguessin adscrites, resultaria en una gran comanda, amb unes condicions comercials més avantatjoses i competitives.

1.2 Objectius del treball

Els objectius del treball els dividim en objectius de caràcter general, comuns a tot treball que reflecteixi l'adquisició i posada en practica dels coneixements adquirits durant la carrera. A objectius específics del nostre TFG, i a objectius de caràcter més personals i didàctics.

(15)

1.2.1 Objectius generals

‣ Capacitat per analitzar un problema, dissenyar-ne una solució i implementar-ne el sistema que el dugui a la pràctica.

‣ Planificar les tasques necessàries per afrontar un projecte d'aquesta magnitud. Prioritzant-les i distribuint-les en el temps, un període de temps concret i limitat

‣ Fer un seguiment de la feina feta, i de les fites assolides. Detectant desviacions que es puguin produir, i replanificant en conseqüència.

‣ Reforçar la destresa per adaptar-se a noves tecnologies i entorns, tot actualitzant les competències professionals.

‣ Innovar i generar noves idees.

‣ Treballar la capacitat de comunicació escrita en l'àmbit acadèmic i professional.

1.2.2 Objectius específics

‣ Crear una aplicació web intuïtiva i accessible a tota mena de client, independent dels seus coneixements informàtics.

‣ Permetre als nostres clients la cerca àgil dels productes i serveis oferts.

‣ Accedir a les ofertes comercials negociades per aquests productes, i adscriure-s'hi amb una petició de compra.

‣ Permetre al nostre STAFF de comercials, la gestió de les ofertes disponibles pel client final.

‣ Permetre al nostre STAFF d’administradors, la gestió de les dades mestres del sistema.

‣ Comunicar als nostres clients la confirmació de les peticions de compra que satisfacin la demanda necessària.

‣ Comunicar als nostres clients les últimes ofertes incorporades al sistema.

1.2.3 Objectius personals i didàctics

‣ Adquirir experiència en tecnologies frontend, concretament en un framework JS, en aquest cas un single page application en VueJS.

‣ Aprofundir el coneixement en sistemes distribuïts, concretament en l’arquitectura de microserveis. Adoptant els beneficis que ens aporten, i bregant amb els desafiaments que ens presenten per crear una API REST tot aplicant patrons de disseny com ara: [1]

• Decompose by subdomain,

• Database per Service, Service per Container,

• Acces Token, API gateway,

• Comunicació sincrona RPI o asincrona per mssatgeria,

• Distributed Tracing, Log aggregattion

‣ Experimentar amb la comunicació asíncrona entre components via missatges (Kafka).

‣ Millorar la destresa i habilitats necessàries per treballar amb la plataforma de virtualització a nivell de sistema operatiu Docker.

(16)

‣ Adquirir coneixements pel que fa a deployar una aplicació al núvol, en el nostre cas Azure.

‣ Utilitzar una eina de gestió i seguiment de treball com Jira.

1.3 Enfocament i mètode seguit

En primer lloc, voldria destacar que tot i existir aplicacions semblants a la nostra, l'objectiu sempre ha estat crear un producte des de zero, ja que e n t e n c q u e é s l a m a n e r a m é s a d i e n t d e c o n d e n s a r i reflectir l'aprenentatge adquirit al llarg de la formació d'enginyeria. I al mateix temps, és un procediment que maximitza la consolidació de les habilitats adquirides, i l'aprenentatge de noves.

Per tal d'afrontar aquest repte he combinat la clàssica metodologia de desenvolupament de software, de cicle en cascada, amb una metodologia àgil, principalment amb taulers Kanban i també amb sprints d'Scrum de dues setmanes.

L'estructura de l'assignatura ens aboca a començar amb un cicle de vida en cascada, per poder entregar a terme l'especificació dels requisits i l'anàlisi del sistema a crear. Cal tenir ben definit tot el problema, i de manera concloent; abans de començar la fase de desenvolupament.

Ja en la fase de desenvolupament he vist la possibilitat d'introduir una metodologia àgil, per una millor organització i seguiment de la feina.

L'estratègia d'utilitzar metodologies àgils també respon, per una banda, al fet que avui en dia estan entre les tecnologies més demandades en ofertes laborals TIC [2], i per un altre a les implicacions de treballar amb tecnologies desconegudes, que requereixen un aprenentatge suficient en un període curt de temps.

Per tal d'implementar el sistema, ens hem anat posant fites parcials, i les he anat refinant fins a arribar al producte final.

Hem començat realitzant petites POCs de les tecnologies més desconegudes. Hem seguit amb la implementació de fluxos d'execució i dissenys (UI) senzills (happy path). Finalitzant amb el tractament d'errors, fluxos d'execució i regles de negoci més complexos, i dissenys més professionals.

Cada una de les fases ha tingut la seva part de proves i QA, tot i que s'ha dedicat un període final específic per confirmar la integració de tots els subsistemes.

1.4 Planificació del treball

La planificació inicial del TFG s’ajusta al calendari d’entrega de les PACs, tenint en compte una dedicació setmanal d’entre 15 i 20 hores.

(17)

Fig 1: Planificació inicial

Aquesta planificació inicial era flexible, per poder afrontar les eventualitats que poguessin sorgir al llarg del temps, ja fos per dificultats sobrevingudes, desviacions en les fites parcials, apropament de les dates clau, etc. (Les fites dels sprints definits aglutinen un conjunt de funcionalitats preparades per una demostració.)

Tasques Esforç Període

Planificació 11 dies 29/09/2021 - 09/10/2022

Requeriments alt nivell 9 dies 29/09/2021 - 09/10/2022

Stack tecnològic 2 dies 29/09/2021 - 09/10/2022

Entrega PAC1 (Fita) 09/10/2022

Especificació i Disseny tècnic 28 dies 10/10/2021 - 06/11/2021

Casos d’Ús 17 dies 10/10/2022 - 30/10/2022

Diagrames UML 2 dies 10/10/2022 - 30/10/2022

Arquitectura, Components Classes

Seqüencia i altres

Disseny base de dades 2 dies 10/10/2022 - 30/10/2022

Prototipus pantalles 7 dies 31/10/2022 - 06/11/2022

Entrega PAC2 (Fita) 06/11/2022

Implementació i Testing 57 dies 8/10/2021 - 21/10/2021

Sprint 1 (Set up) 7 dies 07/11/2022 - 13/11/2022

Sprint 2 (Happy path) 21 dies 14/11/2022 - 04/12/2022 Sprint 3 (Alternative path) 14 dies 05/12/2022 - 18/12/2022 Sprint 4 (Refinaments, proves i QA) 15 dies 19/12/2022 - 02/01/2023

Entrega PAC3 (Fita) 02/01/2023

Memòria i Presentació 18 dies 03/01/2023 - 20/01/2023

Memòria 13 dies 03/01/2023 - 15/01/2023

Presentació virtual 5 dies 16/01/2023 - 20/01/2023

Entrega PAC4 (Fita) 20/01/2023

Font propia

(18)

La part de la planificació inicial que ha sofert més canvis, ha estat com es preveia, la d'implementació i testing. La definició dels sprints en aquesta primera planificació era genèrica, perquè no teníem tancat l'abast de les funcionalitats del producte final.

La gestió de les tasques s'ha fet amb JIRA, eina que ens ha permès controlar l'evolució del treball, mantenint una comunicació fluida i en temps real d'aquesta evolució, amb el tutor.

Tal com mostra la següent imatge, l'evolució del treball ha patit una progressió a l'alça en el nombre de tasques a mesura que s'anaven detectant necessitats no detectades. Podem descobrir també una petita davallada a mitjan desembre. Acordada amb el tutor, prioritzant objectius acadèmics i descarta'n tasques de menys valor.

Fig 2: Evolució planificació inicial

La següent imatge mostra un sprint amb totes les tasques involucrades.

Fig 3: Tasques sprint 2 (Happy Path)

Font propia

(19)

Per últim, mostrem el panell Kanban de l’estat del treball avui mateix.

Aquesta imatge pretent ser una mostra de la utilització i funcionalitat d’aquesta eina.

Fig 4: Panell Kanban estat treball

Els detalls de tota la evolució del TFG es poden consultar a JIRA [3]

1.5 Breu sumari de productes obtinguts

‣ Memòria del projecte.

‣ Presentació virtual (vídeo + diapositives).

‣ Demostració funcional del producte final (vídeo).

‣ Codi font (Arxiu zip, repositori de codi [4] i repositori de configuracions [5]).

1.6 Breu descripció dels altres capítols de la memòria

A continuació detallem la resta de continguts que conformen el projecte global.

‣ Especificació dels requisits del sistema (Capítol 2):

• Llistat de les funcionalitats que ha d’oferir el nostre producte i per a qui (Requisits funcionals), i principals indicadors tinguts en compte per mesurar el bon funcionament d’aquest (Requisits no funcionals).

Font propia

(20)

• Descripció detallada de les funcionalitats del producte.

Inclou les fitxes dels casos d'ús llistats anteriorment, i diagrames UML dels processos centrals i més complexes del sistema.

‣ Anàlisis i disseny de l’arquitectura del sistema (Capítol 3):

• Disseny d’alt nivell de l’estructura del sistema, d’acord amb els requisits, restriccions i objectius plantejats.

• Disseny relacional del model de dades.

• Eines i frameworks utilitzats.

• Disseny relacional de la base de dades (Capítol 4):

• Comparant el model monolític amb el model distribuït per microserveis.

‣ Implementació (Capítol 5):

• Procediments necessaris per configurar l’entorn de desenvolupament.

• Estructura i organització del codi utilitzat.

• Mostres de codi d’especial interès.

‣ Mostra pantalles (Capítol 6):

• Demostració visual del funcionament del producte amb pantalles i fluxos d’execució.

(21)

2. Especificació dels requisits del sistema

Una vegada plantejades les línies generals del projecte, entrarem en una fase d’aprofundiment de conceptes, relatius a l’especificació, l'anàlisi i el disseny de l’aplicació a implementar. [11]

Aquest capítol inclou:

‣ Anàlisi de requisits,

‣ Model de casos d’ús i actors

‣ Fitxes de casos d’ús

‣ Diagrama de classes general i altres diagrames UML de suport que assegurin una bona definició i comprensió del sistema.

L’aplicació projectada d’Agregador de compres per a PIMES, ha de donar resposta a diferents tipus d’usuari.

En primer lloc, cal pensar en l’usuari general o usuari no registrat. Aquest tipus d’usuari ha de poder navegar per l’aplicació i fer cerques de productes, amb un accés limitat a la informació d’aquests, però suficient per fer-se una idea del contingut i les oportunitats que li pot oferir l’aplicació.

En segon lloc, tindrem el tipus d'usuari comprador, l'usuari més important en qui voldríem convertir tot usuari no registrat. Un comprador podrà accedir als continguts de l'aplicació sense restriccions. Podrà mantenir una llista de productes favorits, podrà consultar-ne les ofertes i fer peticions de compra individuals.

En tercer lloc, tenim el tipus d'usuari comercial. Aquest tipus d'usuari formarà part de l'STAFF de l'equip que gestionarà l'aplicació final. Com a especialista en grans comptes, s'encarregarà de mantenir la informació de les ofertes comercials negociades amb els proveïdors de productes i serveis de la seva confiança, i el més important, s'encarregarà de llançar el procés de confirmació de les peticions de compra dels diversos compradors, tot agregant-les en una gran comanda. Satisfent les condicions de l'oferta comercial a la qual s'haurien adscrit.

Finalment, l'administrador. Amb la tasca de mantenir les dades mestres del sistema, registrar els comercials, i assegurar el bon funcionament de l'aplicació.

(22)

2.1 Requisits funcionals

A continuació llistem de manera més detallada, totes les funcionalitats que ha d’oferir l’aplicació. Per cada una de les funcionalitats s’identifiquen els actors que en faran ús: Administrador (A), Comercial (CM), Comprador (CP), Usuari no registrat (UNR)

‣ Registre d’un comprador al sistema (UNR)

‣ Registre d’un comercial al sistema (A)

‣ Identificar-se al sistema (login) (A, CM, CP)

‣ Sortir del sistema (logout) (A, CM, CP)

‣ Modificar dades d’usuari d’un comprador (CP)

‣ Cerca d'un producte per nom i/o descripció (A, CM, CP, UNR)

‣ Llistar productes d’una categoria; Els productes estaran organitzats en categories a manera de catàleg de productes. (A, CM, CP, UNR)

‣ Consultar la informació d’un producte (A, CM, CP)

‣ Marcar / Desmarcar un producte com favorit (CP)

‣ Llistar productes favorits (CP)

‣ Llistar ofertes d'un producte. (CP)

‣ Consulta la informació d'una oferta (CP)

‣ Realitzar petició de compra (CP)

‣ Llistar peticions de compra (CP)

‣ Cancel·lar petició de compra (CP)

‣ Llistar històric de compres (CP)

‣ Gestionar les categories (alta, consulta, modificació, esborrat) (A)

‣ Gestionar els productes (alta, consulta, modificació, esborrat) (A)

‣ Gestionar els proveïdors (alta, consulta, modificació, esborrat) (CM)

‣ Gestionar les ofertes (alta, consulta, modificació, esborrat) (CM)

‣ Confirmació de peticions de compra (A - C)

‣ Avisos d’últimes ofertes (CM - C)

Cal puntualitzar que l’actor A - C o CM - C, indica que la funcionalitat es compartida. La desencadena l’Administrador (A) o el comercial (CM), però que és el comprador (C) qui rebrà un missatge o avís, si escau, del resultat.

(23)

2.2 Requisits no funcionals

Dels nombrosos indicadors existents per mesurar el bon funcionament d’un sistema, incidirem especialment, en el nostre cas, en els següents:

‣ UX (Experiència d'usuari): La interfície i funcionament del sistema ha de ser clar, àgil i intuïtiu. L'èxit de l'aplicació rau a aplanar al màxim la corba d'aprenentatge del seu funcionament.

‣ Seguretat i privacitat: Necessitem tenir un control d'accés fiable, per tal d'assegurar la privacitat de les dades. Tot usuari ha de poder veure només les seves pròpies dades. Considerem com a dades més sensibles, les relatives a les característiques de les compres fetes pels nostres usuaris compradors. Cal fer incís també, en què en les següents fases del projecte, s'afegiran sistemes de pagament, incrementant així, la quantitat de dades confidencials a mantenir.

‣ Rendiment: L'aplicació ha de ser ràpida amb temps de resposta curts. Un funcionament àgil afavoreix l'adaptació, la satisfacció i la fidelitat de l'usuari final, que és per qui treballem en definitiva.

‣ Escalabilitat: En previsió d’un gran volum d’usuaris, per poder assegurar el rendiment d’aquest plantegem un sistema fàcilment redimensionable.

2.3 Model casos d’ús

A continuació, agrupem les funcionalitats o requisits funcionals esmentats, en els mòduls o subsistemes plantejats, mostrant els actors que en faran ús. (Al capítol tercer, en el disseny de l'arquitectura del sistema es detallarà l’estructura modular aquí de citada)

Fig 5: Casos d’ús del mòdul d’autenticació i autorització.

Font propia

(24)

Fig 6: Casos d’ús del mòdul de catàleg de productes.

Font propia

Fig 7: Casos d’ús del mòdul d’ofertes de productes.

Font propia

(25)

Fig 8: Casos d’ús del mòdul de compres.

Font propia

2.4 Fitxes casos d’ús

En aquest apartat, aprofundim en l’explicació dels casos d’ús esmentats, prestant atenció en aquells casos especialment complexes. Vegeu prototipus de pantalles esmentats al següent apartat d’aquest document.

2.4.1 Registre d’un comprador al sistema

Registrar-se com a comprador al sistema

Descripció Obtenir usuari de perfil comprador per operar amb el sistema.

Actors Usuari no registrat Casos d’ús

relacionats Cap.

Pre-condició Sense usuari de perfil comprador al sistema.

Flux principal 1. Entrem dades de registre, parant especial atenció en les dades d’adreça electrònica i password.

Post-condició Obtenim un usuari de perfil comprador per operar amb el sistema.

Alternatives i

excepcions S’informa de qualsevol altre error/excepció ocorregut.

Canvis respectes

PACS anteriors Tenı́em previst utilitzar una fase de confirmació de registre amb un link enviat per mail, però d’acord amb el tutor s’ha descartat per altres assolir altres objectius.

(26)

2.4.2 Registre d’un comercial al sistema

2.4.3 Identificar-se al sistema (login)

2.4.4 Sortir del sistema (logout)

Registre d’un comercial al sistema

Descripció Donar d’alta un usuari de perfil comercial al sistema.

Actors Administrador Casos d’ús

relacionats Cap.

Pre-condició Funcionalitat similar al registre d’un comprador al sistema, substituint el perfil comprador per perfil comercial.

Flux principal Post-condició Alternatives i excepcions

Identificar-se al sistema (login)

Descripció Autenticació al sistema.

Actors Administrador, Comercial i Comprador Casos d’ús

relacionats Registre d’un comprador al sistema.

Registre d’un comercial al sistema.

Pre-condició Tenir credencials per accedir al sistema.

Flux principal 1. Introduı̈m credencials.

2. El sistema autentica les credencials.

Post-condició Se’ns presenta la vista del sistema d’acord amb el perfil associat a les credencials entrades.

Alternatives i

excepcions Si les credencials introduı̈des no són correctes mostrem error.

Els administradors es registren en la instal·lació del sistema.

Sortir del sistema (logout)

Descripció Finalitzar sessió d’usuari.

Actors Administrador, Comercial i Comprador Casos d’ús

relacionats Identificar-se al sistema. (login) Pre-condició Usuari autenticat al sistema Flux principal 1. Seleccionem opció de logout.

2. El sistema finalitza la sessió de l’usuari.

Post-condició Se’ns presenta la vista del sistema d’acord amb el perfil

Sortir del sistema (logout)

(27)

2.4.5 Modificar dades d’usuari d’un comprador

2.4.6 Cerca d’un producte per nom i/o descripció

2.4.7 Llistar productes d’una categoria

Alternatives i

excepcions S’informa de qualsevol error/excepció ocorregut.

Sortir del sistema (logout) Sortir del sistema (logout)

Modificar dades d’usuari d’un comprador

Descripció Permet modificar o corregir les dades d’un usuari comprador.

Actors Comprador

Casos d’ús

relacionats Identificar-se al sistema. (login)

Pre-condició Usuari logat al sistema amb perfil comprador.

Flux principal 1. Seleccionem opció editar dades d’usuari.

2. Modifiquem les dades que es poden modificar com ara el nom comercial o la activitat econòmica.

3. Acceptem canvis efectuats.

Post-condició Dades de l’usuari modificades.

Alternatives i

excepcions No es pot modificar l’adreça de correu electrònic.

S’informa de qualsevol altre error/excepció ocorregut.

Cerca d’un producte per nom i/o descripció

Descripció Permet cercar els productes que ofereix el sistema.

Actors Administrador, Comercial, Comprador i Usuari no registrat

Casos d’ús

relacionats Cap.

Pre-condició Cap. Part pública del sistema.

Flux principal 1. Introduı̈m el nom i/o la descripció del producte que volem trobar.

2. Acceptem criteris de cerca introduı̈ts.

Post-condició El sistema llista els productes coincidents amb els criteris de cerca introduı̈ts.

Alternatives i

excepcions S’informa de qualsevol error/excepció ocorregut.

Llistar productes d’una categoria

Descripció Permet llistar els productes d’una categoria.

Llistar productes d’una categoria

(28)

2.4.8 Consultar la informació d’un producte

2.4.9 Marcar / Desmarcar un producte com a favorit

Actors Administrador, Comercial, Comprador i Usuari no registrat.

Casos d’ús

relacionats Cap

Pre-condició Cap. Part pública del sistema.

Flux principal 1. Seleccionem una de les categories de productes que ens ofereix el sistema.

2. Acceptem categoria seleccionada.

Post-condició El sistema llista els productes de la categoria seleccionada.

Alternatives i

excepcions S’informa de qualsevol error/excepció ocorregut.

Llistar productes d’una categoria Llistar productes d’una categoria

Consultar la informació d’un producte

Descripció Permet veure tota la ‘fitxa’ d’informació d’un producte.

Actors Administrador, Comercial, Comprador Casos d’ús

relacionats Identificar-se al sistema. (login)

Cerca d'un producte per nom i/o descripció.

Llistar productes d’una categoria.

Pre-condició Usuari logat al sistema amb perfil administrador, comprador o comercial amb una vista de Productes llistats.

Flux principal 1. Seleccionem un dels productes llistats, i en demanem més informació.

Post-condició El sistema mostra la fitxa completa del producte.

Alternatives i

excepcions S’informa de qualsevol error/excepció ocorregut.

Marcar / Desmarcar un producte favorit

Descripció Permet marca / desmarcar un producte com a favorit.

Actors Comprador

Casos d’ús

relacionats Consultar la informació d’un producte.

Pre-condició Usuari logat al sistema amb perfil comprador, amb un producte seleccionat.

Flux principal 1. Marquem o desmarquem un producte com a favorit.

2. Acceptem modificació feta.

Post-condició Producte seleccionat com a favorit o pel contrari desseleccionat per l’usuari logat.

Alternatives i S’informa de qualsevol error/excepció ocorregut.

(29)

2.4.10 Llistar productes favorits

2.4.11 Llistar ofertes d’un producte

2.4.12 Consultar la informació d’una oferta

Llistar productes favorits

Descripció Permet llistar els productes favorits d’un usuari.

Actors Comprador

Casos d’ús

relacionats Identificar-se al sistema. (login)

Pre-condició Usuari logat al sistema amb perfil comprador.

Flux principal 1. Seleccionem l’opció de llistar els productes favorits.

Post-condició El sistema llista els productes favorits de l’usuari logat.

Alternatives i

excepcions S’informa de qualsevol error/excepció ocorregut.

Llistar ofertes d’un producte

Descripció Permet llistar les ofertes d’un producte.

Actors Comprador

Casos d’ús

relacionats Consultar la informació d’un producte.

Pre-condició Usuari logat al sistema amb perfil comprador amb un producte seleccionat.

Flux principal 1. Seleccionem l’opció de llistar ofertes del producte seleccionat.

Post-condició El sistema llista les ofertes del producte seleccionat.

Alternatives i

excepcions S’informa de qualsevol error/excepció ocorregut.

Consultar la informació d’una oferta

Descripció Permet veure tota la ‘fitxa’ d’informació d’una oferta.

Actors Comprador

Casos d’ús

relacionats Llistar ofertes d’un producte.

Pre-condició Usuari logat al sistema amb perfil comprador amb una vista llista d’ofertes d’un producte.

Flux principal 1. Seleccionem una de les ofertes llistades, i en demanem més informació.

Post-condició El sistema mostra la fitxa completa de la oferta.

Consultar la informació d’una oferta

(30)

2.4.13 Realitzar petició de compra

2.4.14 Llistar peticions de compra

2.4.15 Cancel·lar petició de compra

Alternatives i

excepcions S’informa de qualsevol error/excepció ocorregut.

Consultar la informació d’una oferta Consultar la informació d’una oferta

Realitzar petició de compra

Descripció Permet realitzar una petició de compra.

Actors Comprador

Casos d’ús

relacionats Llistar ofertes d'un producte.

Pre-condició Usuari logat al sistema amb perfil comprador amb la vista del llistat d’ofertes d’un producte.

Flux principal 1. Seleccionem una oferta, i indiquem comprar.

2. Indiquem la quantitat de producte.

3. Acceptem petició de compra.

Post-condició Petició de compra generada Alternatives i

excepcions S’informa de qualsevol error/excepció ocorregut.

Llistar peticions de compra

Descripció Permet llistar les peticions de compra fetes.

Actors Comprador

Casos d’ús

relacionats Identificar-se al sistema. (login)

Pre-condició Usuari logat al sistema amb perfil comprador.

Flux principal 1. Seleccionem l’opció de llistar les peticions de compra fetes.

Post-condició El sistema llista les peticions de compra de l’usuari logat.

Alternatives i

excepcions S’informa de qualsevol error/excepció ocorregut.

Cancel·lar petició de compra

Descripció Permet cancel·lar una petició de compra feta.

Actors Comprador

Cancel·lar petició de compra

(31)

2.4.16 Llistar històric de compres

2.4.17 Gestionar categories (alta, consulta, modi. i esborrat)

Casos d’ús

relacionats Llistar peticions de compra.

Pre-condició Usuari logat al sistema amb perfil comprador amb la vista del llistat de peticions de compra.

Flux principal 1. Seleccionem una petició de compra de la llista.

2. Rebutgem compra

Post-condició Petició de compra eliminada Alternatives i

excepcions S’informa de qualsevol error/excepció ocorregut.

Cancel·lar petició de compra Cancel·lar petició de compra

Llistar històric de compres

Descripció Permet mostrar les compres realitzades per l’usari logat

Actors Comprador

Casos d’ús

relacionats Identificar-se al sistema. (login)

Pre-condició Usuari logat al sistema amb perfil comprador.

Flux principal 1. Seleccionem l’opció de llistar l’històric de compres Post-condició El sistema llista les compres realitzades per l’usuari

logat Alternatives i

excepcions S’informa de qualsevol error/excepció ocorregut.

Gestionar categories (alta, consulta, modificació, esborrat)

Descripció Consulta, Alta, Modificació i Esborrat de categories.

Actors Administrador Casos d’ús

relacionats Identificar-se al sistema. (login)

Pre-condició Usuari logat al sistema amb perfil administrador.

Gestionar categories (alta, consulta,

modificació, esborrat)

(32)

2.4.18 Gestionar productes (alta, consulta, modi. i esborrat)

Flux principal Consulta

1. Seleccionem l’operació de consultar categories.

2. Mostra llista de categories.

Alta

1. Seleccionem l’operació d’alta d’una categoria, opció

presentada a la llista de categories.

2. Informem les dades de la nova categoria.

3. Acceptem l’operació d’alta.

4. Mostrem la llista de categories amb la nova categoria.

Modificació

1. Seleccionem la categoria que vulguem modificar de la llista de categories.

2. Modifiquem les dades de la categoria.

3. Acceptem l’operació de modificació.

4. Mostrem la llista de categories amb les dades modificades de la categoria seleccionada.

Esborrat

1. Seleccionem la categoria que vulguem esborrar de la llista de categories.

2. Acceptem l’operació d’esborrat.

3. Mostrem la llista de categories sense la categoria eliminada.

Post-condició El procés de consulta, alta, modificació o esborrat finalitza correctament.

Alternatives i

excepcions No podem esborrar una categoria composta per un o més productes.

S’informa de qualsevol altre error/excepció ocorregut.

Gestionar categories (alta, consulta, modificació, esborrat)

Gestionar categories (alta, consulta, modificació, esborrat)

Gestionar productes (alta, consulta, modificació, esborrat)

Descripció Consulta, Alta, Modificació i Esborrat de productes.

Actors Administrador Casos d’ús

relacionats Identificar-se al sistema (login)

Pre-condició Usuari logat al sistema amb perfil administrador.

Flux principal Operativa similar a la de gestió de categories Post-condició El procés de consulta, alta, modificació o esborrat

finalitza correctament.

Gestionar productes (alta, consulta,

modificació, esborrat)

(33)

2.4.19 Gestionar proveïdor (alta, consulta, modi. i esborrat)

2.4.20 Gestionar ofertes (alta, consulta, modi. i esborrat)

Alternatives i

excepcions No podem esborrar un producte que sigui favorit d’algun comprador o que estigui involucrat en alguna oferta concreta. En aquests casos que no podem

esborrar, indicarem una data de fi de vigència anterior a la data de fi de vigència de les seves ofertes.

S’informa de qualsevol altre error/excepció ocorregut.

Gestionar productes (alta, consulta, modificació, esborrat)

Gestionar productes (alta, consulta, modificació, esborrat)

Gestionar proveïdors (alta, consulta, modificació, esborrat)

Descripció Consulta, Alta, Modificació i Esborrat de proveı̈dors.

Actors Comercial

Casos d’ús

relacionats Identificar-se al sistema (login)

Pre-condició Usuari logat al sistema amb perfil comercial.

Flux principal Operativa similar a la de gestió de categories Post-condició El procés de consulta, alta, modificació o esborrat

finalitza correctament.

Alternatives i

excepcions No podem esborrar un proveı̈dor que estigui involucrat en alguna oferta concreta. En aquests casos que no podem esborrar, indicarem una data de fi de vigència posterior a la data de fi de vigència de les seves ofertes.

S’informa de qualsevol altre error/excepció ocorregut.

Gestionar ofertes (alta, consulta, modificació, esborrat)

Descripció Consulta, Alta, Modificació i Esborrat d’ofertes.

Actors Comercial

Casos d’ús

relacionats Identificar-se al sistema (login)

Pre-condició Usuari logat al sistema amb perfil comercial.

Flux principal Operativa similar a la de gestió de categories Post-condició El procés de consulta, alta, modificació o esborrat

finalitza correctament.

Gestionar ofertes (alta, consulta, modificació,

esborrat)

(34)

2.4.21 Confirmar peticions de compra

2.4.22 Avisos d’últimes ofertes

Alternatives i

excepcions No podem esborrar una oferta que estigui involucrada en alguna petició de compra. En aquests casos que no podem esborrar, indicarem una data de fi de vigència posterior a la data de fi de vigència de les seves peticions de compra.

S’informa de qualsevol error/excepció ocorregut.

Gestionar ofertes (alta, consulta, modificació, esborrat)

Gestionar ofertes (alta, consulta, modificació, esborrat)

Confirmació de peticions de compra

Descripció Confirma peticions de compra.

Actors Administrador com a llançador i comprador com a receptor

Casos d’ús

relacionats Cap.

Pre-condició Cap.

Flux principal 1. Recorrem les peticions de compra de cada oferta vigent.

2. Calculem si l’agregat de peticions de compra satisfà

els requisits de l’oferta.

3. En cas afirmatiu es formalitzen les peticions de compra, informant-ne els compradors.

Post-condició Peticions de compra confirmades o no, en funció dels requisits de les ofertes.

Alternatives i

excepcions S’informa de qualsevol error/excepció ocorregut.

Canvis respectes

PACS anteriors Tenı́em previst realitzar un procés batch com a

llançador del procés, però s’ha descartat per qüestions de temps.

Avisos d’últimes ofertes

Descripció Permet mantenir els compradors informats de les darreres ofertes dels seus productes favorits.

Actors Comercial com a llançador i com,prador com a receptor Casos d’ús

relacionats Cap.

Pre-condició Cap.

Avisos d’últimes ofertes

(35)

2.5 Diagrames UML processos centrals del sistema

La realització d’una petició de compra, i la confirmació d’aquesta, són els processos centrals del nostre sistema. En mostrem un diagrama de seqüència i un d’estats, per tal d’aclarir visualment, els conceptes presentats en les fitxes dels casos d’ús corresponents.

Fig 9: Diagrama seqüència petició de compra

Font propia

Fig 10: Diagrama estats petició de compra

Font propia

Flux principal 1. El sistema detecta quan una oferta es donada d’alta o se’n modifiquen les condicions.

2. S’avisa a tots el compradors interesats (Oferta d’un producte favorit)

Post-condició Avisos enviats.

Alternatives i

excepcions S’informa de qualsevol error/excepció ocorregut.

Avisos d’últimes ofertes

Avisos d’últimes ofertes

(36)

2.6 Diagrama de classes

Punt de vista de la informació del sistema.

Fig 11: Diagrama de classes

Font propia

Font propia

‣ Les entitats Comercial, Administrador i Comprador hereten la informació de l'entitat Usuari.

‣ Un Comprador pot realitzar de 0 a N peticions de compra / ordres de compra.

‣ Una Oferta es pot referir de 0 a N peticions de compra / ordres de compra.

‣ Un Comercial gestiona de 0 a N Ofertes.

‣ Un Proveïdor es pot referir de 0 a N Ofertes.

‣ Un Producte es pot referir de 0 a N Ofertes.

‣ Un Producte pertany a una Categoria.

‣ Un Producte pot ser Favorit de 0 a N Comprador.

‣ Un Comprador pot tenir de 0 a N productes Favorits.

(37)

3. Anàlisis i disseny de l’arquitectura

Una vegada completada la fase d’aprofundiment de conceptes, relatius a l’especificació, entrarem en la fase d’anàlisi i disseny de l’arquitectura, del sistema amb les tecnologies involucrades. [9] [10]

3.1 Arquitectura global

El nostre sistema estarà compost a grans trets per un frontal web (client lleuger) [13] i una part servidora que exposarà els seus serveis al frontal web a través d’una API definida. La comunicació es farà mitjançant crides REST.

Aquest primer nivell arquitectònic segueix una estructura client-servidor de tres capes, que seguirà el patró Model-Vista-Controlador (MVC).

Fig 12: Arquitectura client-servidor de 3 capes (MVC)

Font propia

El patró MVC proposa, independentment de les tecnologies que s’utilitzin, la separació dels components que conformen el sistema a desenvolupar, en tres capes principals: model vista i controlador. Descriu també com es relacionen aquestes capes per tal de mantenir una estructura ordenada, clara i amb un mínim d’acoblament.

El model conté les entitats que representen el domini del s i s t e m a , i s ’ e n c a r r e g a d e l s m e c a n i s m e s de persistència necessaris per a l’emmagatzematge i recuperació de dades. El model manté en tot moment l’estat del conjunt de dades del domini.

Els components de la vista són els responsables de generar la interfície del sistema amb l’exterior. La vista és una representació de l’estat del model en un moment concret i en el context d’una acció determinada

El controlador modela els processos de negoci, i s’encarrega de dur a terme tot el processament necessari per atendre les peticions de l'usuari, generalment activades des de la vista,

(38)

interactuant, si és necessari, amb el model, consultant-ne l’estat o actualitzant-lo.

3.2 Arquitectura frontend

El frontend (Vista) de la nostra aplicació estarà conformat per un frontal web o client lleuger. Un client lleuger delega tota la càrrega de gestió de regles de negoci i gestió de dades a la part servidora, responsabilitzant- se essencialment de la capa de presentació.

Els avantatges dels clients lleugers són nombrosos, especialment en l'estalvi de costos en infraestructura (costat client) i en la gestió d’aquesta. A més de ser sistemes molt flexibles.

La delegació de la càrrega de processament en el servidor i en la xarxa, que comporta un client lleuger com el nostre, és perfectament assumible, ja que en el nostre cas, es compondrà d’un seguit de regles de negoci senzilles que no requeriran gran potència de processament, ni grans volums d’informació a gestionar, per cada usuari, que no requerirà grans amplades de banda.

És per tot l'anterior que ens decantem per un client web com a client lleuger.

El món de les pàgines web ha millorat molt els últims anys en terme d'experiència d'usuari, fent-les més dinàmiques, i interactives.

Per aconseguir-ho s'han portat funcionalitats del costat servidor al costat client amb javascript. L'augment d'aquestes funcionalitats al costat client n'ha augmentat també la complexitat, és per això que els desenvolupadors han començat a recolzar-se en el que s'anomena frameworks frontend. D'entre els més populars que hi ha actualment, Angular, React i VueJS, triem aquest últim.

El fet de triar VueJS, respon no només a la voluntat d'aprendre noves t e c n o l o g i e s , s i n ó t a m b é a l f e t q u e é s l ' ú n i c d e l s 3 grans frameworks frontend que no té una gran empresa al darrere. El fet d'haver-se fet forat entre la comunitat denota que els motius del seu èxit són fonamentalment la utilitat i el valor real pels desenvolupadors.

Cal destacar també que VueJS s'anuncia com un framework progressiu, és a dir, és un framework que ens permet crear tota classe de desenvolupaments. De components senzills que implementen una part determinada d'una aplicació web, a aplicacions frontend completes com la nostra.

Vuejs implementa una arquitectura de components que permet dividir les aplicacions en blocs de funcionalitats independents que es poden utilitzar com una base de peces reutilitzables per construir grans aplicacions. També en destaca la possibilitat de crear vistes reactives, és a dir VueJS permet actualitzar l'HTML i el CSS quan canvien les dades de l'aplicació, sense que el desenvolupador hagi de propagar manualment aquests canvis.

(39)

En resum, l'arquitectura frontal de la nostra aplicació s'implementarà amb una SPA o Single Page Application amb VueJS, pels avantatges presentats d'un client lleuger i en particular pels de Vue. Dotant la nostra solució d'una interfície semblant a les de les aplicacions tradicionals de PC, interfícies plenament conegudes i acceptades per tothom, però amb un aspecte més modern.

3.3 Arquitectura backend

Aspirem a tenir una aplicació senzilla i minimalista però amb pretensions d’arribar a tenir un gran volum d'usuaris. Amb tot això, volem anar incorporant novetats al sistema, en fases posteriors del projecte.

Escurçant els terminis d’entrega i reduint al màxim, el Time-to-Marquet (TTM).

Per poder abastar aquests dos grans objectius hem pensat en una arquitectura de microserveis, un estil arquitectònic que estructura una aplicació en un conjunt de serveis fàcilment mantenibles, testejables, serveis dèbilment acoblats, deployables de manera independent i fàcilment escalables.

3.3.1 Subsistemes, serveis, microserveis

U n d e l s p r i m e r s p a s s o s a a d o p t a r u n a a r q u i t e c t u r a de microserveis consisteix en descompondre l'aplicació o producte final en serveis.

Per tal de fer aquesta descomposició, ens recolzarem en el patró de descomposició per subdomini [1], on cada subdomini seria una part del negoci objectiu. Aquests subsistemes o serveis serien:

‣ Catàleg: Subsistema encarregat del manteniment de dades mestres del sistema relatives a categories i productes.

‣ Ofertes: Subsistema encarregat del manteniment de dades mestres del sistema relatives a proveïdors i de les ofertes negociades amb aquests.

‣ Compres: Subsistema encarregat de la gestió de les peticions de compres, l’agregació d’aquestes i de la seva confirmació o consolidació en una gran compra.

(40)

Fig 13: Descomposició per subdominis

Font propia

Aquesta descomposició afavoreix els patrons SRP (Single Responsability Principle), i CCP (Common Closure Principle) de disseny OOD (object-oriented design).

Cada subsistema detectat en aquesta fase, s'implementarà, a manera d’un microservei standalone, amb Spring Boot, seguint un model de 3 capes, on la capa de presentació serà la API exposada (Un

@RestController que capturarà les crides rebudes), la capa de negoci serà el cos dels serveis implementats (Serveis), i una capa d'accés a b a s e d e d a d e s , b a s a d a e n S p r i n g D a t a i e n l'especificació JPA (Repositori). Cal destacar que cada microservei serà el propietari d'un subdomini del model de dades del sistema, que compartirà, si cal, amb d'altres microserveis, a través de funcions exposades en la seva API.

Fig 14: Microservei i Spring Boot

Font propia

(41)

3.3.2 API Gateway

Cada Per sobre d’aquests subsistemes hi afegirem un mòdul que s’ocuparà de les tasques transversals d’autenticació i autorització que implementarà el patró API Gateway [1], actuant com a únic punt d’entrada al sistema que s’encarregarà d'encaminar les peticions als serveis finals.

Fig 15: Api gateway i subdominis

Font propia

Les tasques d'autenticació i autorització es recolzaran en tokens JWT.

A q u e s t a t e c n o l o g i a e n s p e r m e t m a n t e n i r u n n i v e l l d e seguretat adequat amb un alt nivell de desacoblament entre subsistemes en evitar l'ús de sessions i variables compartides. Amb aquest enfocament, cada crida o interacció amb el sistema es gestionarà exclusivament amb la informació que aporti, independentment de les altres crides que hi pugui haver. És el que anomenarem una aplicació stateless.

3.3.3 JWT

JWT és una tecnologia oberta i estàndard, especialment útil per l'autenticació d'una API i per l'autorització de recursos protegits. Per representar la identitat de l'usuari en l'intercanvi de crides i respostes s'utilitza el que s'anomena JSON Web Tokens.

Tal com mostrem en la següent imatge, aquest token és generat pel servidor, després d'autenticar les credencials de l'usuari. Les següents crides al sistema incorporaran aquest token per comprovar la legitimitat de la crida i controlar els recursos protegits del sistema als que pugui accedir.

(42)

Fig 16: Fluxe JWT token

Font https://www.vaadata.com/blog/jwt-tokens-and-security-working-principles-and-use-cases/

3.3.4 Comunicació entre microserveis

Els serveis que componen el nostre sistema sovint necessiten col·laborar entre ells per poder donar resposta a les peticions rebudes.

Aquesta col·laboració es pot fer amb crides REST síncrones (RestTemplate) i amb missatgeria asíncrona.

La comunicació síncrona afegeix un grau d'acoblament entre serveis que no sempre és desitjable.

La missatgeria asíncrona evita aquest acoblament, a expenses d’una complexitat major en el sistema.

Combinarem ambdos mètodes de comunicació per motius didàctics.

3.3.4.1 Messaging

La comunicació asíncrona amb missatges, ens permet triar entre diferents estils de comunicació com ara request/response (Un servei envia un missatge a un destinatari, esperant una prompta resposta), notifications (Un remitent envia un missatge a un destinatari sense esperar resposta) o publish/subscribe (Un servei publica un missatge a zero o més destinataris).

Aquesta manera de comunicar serveis, evoca al patró de event- driven programming, un paradigma basat en events, on els subsistemes estan escoltant a si arriba un senyal (missatge) que acaba desencadenant una acció a realitzar.

El funcionament d'aquests sistemes de missatgeria requereix un sistema (servidor) anomenat broker (Kafka [14] en el nostre cas) que permet una

(43)

(consumers) de missatges, organitzats en categories o fluxos de dades (topic)..

Fig 17: Comunicació asíncrona, Messaging

Font https://developerexperience.io/articles/kafka

Utilitzarem la comunicació asíncrona, en el nostre cas, per enviar notificacions als compradors, informant-los d'una nova oferta donada d'alta d'un dels seus productes favorits, o de la confirmació d'una petició de compra pendent.

3.3.5 Infraestructura

‣ Per poder gestionar la configuració dels diferents microserveis, pels diferents entorns, de manera centralitzada, utilitzarem el patró Externalized Configuration on els serveis que conformen el nostre sistema, recuperaran les seves propietats de configuració, del servidor Spring Cloud Config Server.

‣ Per poder entendre i seguir el flux de les crides al nostre sistema, crides que sovint s'expandeixen entre diferents serveis, utilitzarem el patró Distributed Tracing. Aquest patró utilitza un identificador únic per cada sol·licitud externa, que englobarà les diferents crides internes que la componguin. Aquest id únic serà gestionat per Spring Cloud Sleuth, que configurarà els components Spring, perquè recullin informació de les crides i l'enviïn a un servidor (Zipkin [18]) que recollirà i mostrarà visualment la traça definida per aquestes crides identificant l'ordre i latència d’aquestes.

‣ L'aplicació consisteix en diversos components executant-se en diverses màquines virtuals o físiques. Com que les peticions sovint s'estenen entre diversos components, cada un amb els seus propis logs, caldrà un sistema que agregui aquests diferents logs en un sol lloc, per tractar-los de manera centralitzada. Aquest patró s'anomena Log aggregation, i es pot implementar amb plataformes com ara ELK [19] (Elasticsearch, Logstash y Kibana) o (AWS Cloud Watch)

(44)

‣ Per facilitar el desplegament de tot el sistema a una altra màquina o al núvol, encapsularem tots els serveis I servidors en contenidor Docker.

3.3.6 Diagrama resum arquitectura, eines i frameworks

Una vegada presentats els components més importants del sistema, en detallem com queden relacionats:

Fig 18: Diagrama resum disseny arquitectura

Font propia

Puntualitzacions del diagrama:

‣ Els serveis Catàleg, Compres, Ofertes i API Gateway són contenidors Docker implementats amb Spring Boot.

‣ Els servidors Configserver, Zipkin i ELK són servidors d'infraestructura, que formen part del backend, i que es comuniquen directament amb els quatre serveis anteriors.

‣ Els serveis Catàleg, Compres, Ofertes es connecten entre ells via missatges Kafka i via crida directa REST en funció de l'operativa concreta.

(45)

Eïnes i frameworks:

‣ Frontend (Single Page Application)

• IDE Visual Studio Code

• Vue3, Vuetify (Components visuals)

• Volar (Vue Language features per IDE)

‣ Backend (Microserveis)

• IDE IntelliJ IDEA

• Java 17, última LTS release per la API/BackEnd

• SpringBoot 2.7.4

• Spring 5.3.22

• SpringCloud 2021.0.4

• Configserver: gestor de configuracions. Cada entorn d’execució (Desenvolupament, Preproducció, Producció) carrega la seva configuració específica.

• Zipkin: Gestió de traces distribuïdes (Permet veure la seqüència de crides entre microserveis, i les latències que hi hagi)

• ELK: Gestió de logs distribuïts (Cada microserveis té el seu log, amb ELK podem agrupar-ho en un sol lloc)

• Kafka JMS: Comunicació asíncrona entre serveis.

‣ Plataforma execució:

• Docker/DockerCompose

• AZURE

‣ Base de dades:

• PostgreSQL 14.5

‣ Altres:

• Maven 3.8.6

• GitHub

(46)

4. Disseny relacional de la base de dades

A continuació mostrem el disseny relacional de la base de dades que tindríem en un backend estructurat en forma de monòlit que tingués accés al model de dades global. [15]

Fig 19: Disseny relacional de la base de dades en monòlit

Font propia

Tenint en compte que hem definit que cada subsistema serà propietari d'una part del model de dades global, mostrarem la distribució de les entitats proposades en cada un dels subsistemes presentats.

(47)

Fig 20: Distribució entitats entre subsistemes

Font propia

Finalment, mostrem els quatre dissenys relacionals de les bases de dades, un per de cada subsistema.

Cal destacar que aquelles relacions en un model de monòlit, que es podien controlar a nivell de base de dades, ara s'hauran de controlar amb regles de negoci.

(Ex: el comercial_id que hi ha a la taula Oferta, ja no pot ser una FK o clau forana al pertanyer a 2 models de dades diferents desconnectats, I haurà de ser una regla de negoci que mantingui la consistència dels diferents models de dades, ja que una Oferta està en el model de dades Ofertes, i un comercial en el model de dades AuthAuth)

Fig 21: Model dades subsistema AuthAuth

Font propia

(48)

Fig 22: Model dades subsistema Catàleg

Font propia

Referencias

Documento similar

Si oblida el seu usuari, és possible recuperar-lo si encara pot accedir al correu electrònic amb el qual va crear aquest usuari. Per a això prema sobre l'enllaç “ No recorde la

-l\llarga|ida Ma Ramis Sastre, representant del GOB -Luís Martín Abati, representant de PROlNBA -Joan Cerdà Ripoll, representant del COAIB -Àngels Fermoselle Paterna,

Per poder entendre bé el conflicte que es va crear entre Villanueva de Castellón i Castelló de la Ribera parlem amb Antoni Vizcaino, el primer alcalde que va

We have created this abstract to give non-members access to the country and city rankings — by number of meetings in 2014 and by estimated total number of participants in 2014 —

En relació amb l’efectivitat del tractament, a partir de les proves T per a la comparació de les mitjanes de les puntuacions pre i posttractament, es constata

Maribel: Hay algunos productos de control biológico que se basan en la síntesis de una toxina que combate a los patógenos. En estos casos se podría verter directamente la toxina

Aquest usuari tindrà perfil “Supervisor” dins de l’aplicació EDIFICANT, cosa que li permetrà realitzar totes les funcions relacionades amb

Classificació operativa de productes i servicis POLÍTIQUES DE COMPRES: TIPOLOGIA. DE PRODUCTES I GESTIÓ