Conclusione della relazione.

I futuri commit saranno solo correttivi.

.gitignore

@@ -175,6 +175,9 @@ acs-*.bib
 *.snm
 *.vrb
 
+#draw.io
+*.drawio
+
 # changes
 *.soc
 
@@ -513,6 +516,8 @@ luac.out
 ### TeX ###
 
 !**/assets/img/*.pdf
+!**/assets/img/*.eps
+**/assets/img/*-eps-converted-to.pdf
 # *.ps
 # *.eps
 # *.pdf

relazione/src/FERRON_relazione.bib

-% Encoding: UTF-8
-
-@Software{msaccess,
-  author  = {{Microsoft Corporation}},
-  title   = {\emph{Microsoft Access}},
-  type    = {software},
-  url     = {https://office.microsoft.com/access},
-  urldate = {2020-08-25},
-}
-
-@Software{joomla,
-  author  = {{OSM Development Team}},
-  title   = {\emph{Joomla!}},
-  type    = {software},
-  url     = {https://www.joomla.org/},
-  urldate = {2020-08-26},
-}
-
-@Software{wordpress,
-  author  = {Mullenweg, Matt},
-  title   = {\emph{WordPress}},
-  type    = {software},
-  url     = {https://wordpress.org/},
-  urldate = {2020-08-26},
-}
-
-@Software{wpscan,
-  author  = {{wpscanteam}},
-  title   = {\emph{wpscan}},
-  type    = {software},
-  url     = {https://wpscan.org/},
-  urldate = {2020-09-01},
-}
-
-@Software{adobemagento,
-  author  = {{Adobe Inc.}},
-  title   = {\emph{Magento}},
-  type    = {software},
-  url     = {https://magento.com/},
-  urldate = {2020-09-01},
-}
-
-@Book{Sommerville2017,
-  author    = {Sommerville, Ian},
-  title     = {Ingegneria del software},
-  isbn      = {9788891902245},
-  publisher = {Pearson Italia},
-  address   = {Milano Torino},
-  year      = {2017},
-}
-
-@Comment{jabref-meta: databaseType:biblatex;}

relazione/src/FERRON_relazione.cfg

@@ -2,7 +2,7 @@
 \StrutturaDi{Dipartimento di }
 \struttura{Scienze e Innovazione Tecnologica}
 \NomeElaborato{Relazione per la prova finale}
-\titolo{Sviluppo di una piattaforma \textenglish{e-commerce} per la vendita di mobili metallizzati}
+\titolo{Sviluppo di una piattaforma \ecommerce per la vendita di mobili metallizzati}
 %\renewcommand{\NomeCorsoDiStudi}{\textbf{Corso di Laurea in}}
 \corsodistudi{Informatica}
 \candidato{Lorenzo \textsc{Ferron}}

relazione/src/FERRON_relazione.tex

@@ -5,11 +5,12 @@
 
 \ProvidesFile{FERRON_relazione.tex}
 \documentclass[%
-a4paper,%
 corpo=11.5pt,%
 tipotesi=triennale,%
 evenboxes,%
-draft,%
+%draft,%
+libro,% uncomment to print PDF
+%cucitura=4mm,%
 twoside
 ]{toptesi}
 
@@ -19,13 +20,14 @@ twoside
 	\Author[it-IT]{Lorenzo Ferron}
 	\Title[it-IT]{Sviluppo di una piattaforma e-commerce per la vendita di mobili metallizzati}
 	\Language{it-IT\sep en-US}
-	\Keywords{}
-	\Subject[it-IT]{}
-	\Copyright[it-IT]{Di pubblico dominio}
+	\Keywords{e-commerce\sep architecture\sep data layer\sep presentation layer\sep business layer\sep requirements\sep Bachelor's Degree\sep italian}
+	% If you don’t know what to use for the Subject, you can use the Title again in this field.
+	\Subject[it-IT]{Sviluppo di una piattaforma e-commerce per la vendita di mobili metallizzati}
+	\Copyright[en-US]{WTFPL Version 2}
 	\Copyrighted{False}
 	%\Publisher{}
 \end{pdfxmetadata}
-\usepackage[a-2b]{pdfx}
+\usepackage[x-4]{pdfx} %option x-4 for print, a-2b for archive (also display)
 
 \errorcontextlines=9% more information on the console in case of errors
 
@@ -37,7 +39,18 @@ twoside
 \SetLanguageKeys{italian}{indentfirst=false}
 
 \usepackage[figuresright]{rotating}
-\usepackage{enumitem, microtype}
+\usepackage{pgf-umlsd, enumitem, microtype}
+
+% new command for adding a distance option for threads as well
+% \newthread[color][distance]{id}{title}
+\RequirePackage{xargs}
+\renewcommandx{\newthread}[4][1=gray!30, 2=0.2]{
+	\newinst[#2]{#3}{#4}
+	\stepcounter{threadnum}
+	\node[below of=inst\theinstnum,node distance=0.8cm] (thread\thethreadnum) {};
+	\tikzstyle{threadcolor\thethreadnum}=[fill=#1]
+	\tikzstyle{instcolor#3}=[fill=#1]
+}
 
 \AfterEndPreamble{%
 	\input{preamble/my-macros.tex}
@@ -47,16 +60,21 @@ twoside
 \usepackage[%
 backend=biber,%
 style=numeric-comp,%
+datamodel=software,%
 citestyle=numeric,%
 sorting=nty,%
 urldate=long,%
 dateabbrev=false,%
+abbreviate=false,%
 natbib
 ]{biblatex}
+\usepackage{software-biblatex}
 \AfterEndPreamble{\input{preamble/workarounds/issue-1041.tex}}
-\addbibresource{FERRON_relazione.bib}
+\addbibresource{references.bib}
 
 \usepackage[italian]{cleveref}
+\Crefname{section}{Paragrafo}{Paragrafi}
+\Crefname{subsection}{Paragrafo}{Paragrafi}
 
 \unless\ifcsname ver@hyperref.sty\endcsname\usepackage{hyperref}\fi
 \hypersetup{%
@@ -72,7 +90,7 @@ natbib
 \includeonly{%
 	contents/introduzione/introduzione,%
 	contents/introduzione-al-lavoro/introduzione-al-lavoro,%
-	contents/metodologie-strumenti-utilizzati/metodologie-strumenti-utilizzati,%
+	contents/strumenti-utilizzati/strumenti-utilizzati,%
 	contents/lavoro-svolto/lavoro-svolto,%
 	contents/conclusioni/conclusioni,%
 }
@@ -96,11 +114,12 @@ natbib
 	\include{contents/introduzione/introduzione}
 	\include{contents/introduzione-al-lavoro/introduzione-al-lavoro}
 	\include{contents/lavoro-svolto/lavoro-svolto}
-	\include{contents/metodologie-strumenti-utilizzati/metodologie-strumenti-utilizzati}
+	\include{contents/strumenti-utilizzati/strumenti-utilizzati}
 	\include{contents/conclusioni/conclusioni}
 
 	\backmatter
 
+	\phantomsection
 	\printbibliography[heading=bibintoc]
 
 \end{document}
\ No newline at end of file

relazione/src/contents/abstract.tex

 % !TeX encoding = UTF-8
 % !TeX root = ../FERRON_relazione.tex
 
+L'azienda Trimar S.r.l., presso cui si è svolto lo stage, aveva la necessità di migliorare la propria piattaforma di \ecommerce, per affermarsi maggiormente in un mercato sempre più digitale e non limitandosi a quello di una semplice azienda di provincia.
+Una prima fase ha riguardato l’analisi della piattaforma preesistente.
+Questa analisi ha evidenziato la presenza di gravi problemi sia di sicurezza sia strutturali, dovuti principalmente alla poca esperienza del personale che inizialmente l'aveva configurata e poi gestita.
+Si è quindi deciso di abbandonare la preesistente piattaforma e facendo tesoro dell'esperienza e della conoscenza maturate nel settore dal committente si è sviluppata una piattaforma \textit{ad hoc}, piuttosto che ripiegare su una già confezionata, che avrebbe richiesto l'acquisizione di nuove conoscenze, senza però aver garanzia di soddisfare tutte le necessità aziendali.
+%Negli ultimi anni, ma soprattutto in questo, i negozi \textenglish{on-line} sono diventati indispensabili, tanto che ognuno di noi ha almeno un'\textenglish{applicazione} sul proprio \textenglish{smartphone}, per rimanere sempre aggiornato sullo stato di un ordine.
+%In questi \textenglish{\textit{store}} virtuali si acquista di tutto: da Amazon a eBay, che offrono un'eterogeneità di prodotti, a Zalando, che punta sull'abbigliamento; nessun prodotto è escluso e tutti i gusti sono soddisfatti.
+%Così vista l'enorme moltitudine di \ecommerce, si è ben pensato che uno in più non avrebbe guastato.
+
+Nella mia relazione andrò a dettagliare come questa nuova piattaforma è stata sviluppata e le motivazioni alla base delle scelte progettuali effettuate.
+In particolare, descriverò i requisiti raccolti, per poi passare a una dettagliata analisi dell’architettura, illustrando come siano state affrontate le problematiche di efficienza e sicurezza.
+Per concludere analizzerò quali aspetti del progetto realizzato possano prevedere ulteriori migliorie.
\ No newline at end of file

relazione/src/contents/conclusioni/conclusioni.tex

@@ -3,4 +3,33 @@
 
 \chapter{Conclusioni e sviluppi}
 \label{ch:conclusioni}
-\graphicspath{{contents/conclusioni/assets/img/}}
+\graphicspath{{contents/conclusioni/assets/img/}}
\ No newline at end of file
+
+Nella corso della trattazione sono state affrontate una buona parte delle scelte progettuali, di sicurezza ed efficienza fatte.
+Al lettore attento non sarà sfuggito, che tra tutti gli argomenti trattati, non si è fatto nessun accenno all'amministrazione della piattaforma, tanto che non figura nemmeno tra i requisiti funzionali riportati nella \Cref{subsec:i-requisiti}.
+L'azienda ha ritenuto che tale funzionalità non fosse immediatamente necessaria, posticipando in un secondo momento la sua implementazione.
+Si noti che tutte le operazioni che saranno assolte dal lato amministrativo della piattaforma possono, per il momento, essere svolte manualmente, anche se questo può comportare inconsistenza dei dati.
+Ad esempio all'utente dovrà essere inviata manualmente un'\textenglish{e-mail} per informarlo che il suo ordine è stato spedito.
+Prima di questa operazione l'amministratore avrà inserito la data di spedizione dell'ordine e il codice del corriere per tracciarlo sulla base di dati, anche questo sarà svolto manualmente con l'utilizzo di un \textenglish{software} per l'amministrazione di \textenglish{database} come \prog{\mbox{phpMyAdmin}}~\cite{phpmyadmin}.
+In ogni caso l'accesso all'amministrazione della piattaforma deve avvenire all'interno dell'\textenglish{intranet} e non avrà bisogno di richiedere una password, perché l'amministratore è unico.
+Se si manifestasse la necessità di dover accedere a questa funzionalità dalla rete esterna, sarà sempre possibile farlo attraverso una VPN\@.
+
+Oltre all'amministrazione, vi sono altre funzionalità che non sono state implementate, ma sono state previste nella fase di progettazione, una fra tutte è l'internazionalizzazione della piattaforma.
+Essa permetterebbe di raggiungere un mercato molto più ampio di clienti non solo in Italia.
+Inoltre risulta comoda anche per quei clienti, che vivono in Italia, ma hanno difficoltà a comprendere la lingua.
+In particolare, tale funzionalità richiederebbe la traduzione delle pagine, una conversione in tempo reale dei prezzi nella valuta corrente e la scelta del paese in cui spedire l'ordine, ovvero seguendo uno stile simile a quello di AliExpress.
+Si noti che per quanto riguarda la base di dati, essa è perfettamente in grado di trattare caratteri non latini, come quelli cirillici o gli ideogrammi, vista la codifica scelta (\Cref{subsec:schema-logico-fisico}).
+Inoltre per agevolare la traduzione delle pagine, sono stati creati file \texttt{.properties} che contengono coppie \mbox{chiave-valore}, in cui il valore è un messaggio che sarà mostrato all'utente.
+L'aggiunta di una nuova lingua richiederebbe la creazione di nuovi file \texttt{.properties} e la conseguente traduzione delle coppie \mbox{chiave-valore}, così facendo non sarà necessaria alcuna modifica dei file JSP, che faranno sempre riferimento alle stesse chiavi.
+In più il sistema potrebbe determinare il paese in cui spedire la merce basandosi sull'indirizzo IP oppure estraendolo dall'\texttt{Accept-Language}, ma in ogni caso lasciando sempre all'utente la possibilità di modifica.
+
+Al crescere del mercato si potrebbe verificare una crescita degli accessi alla piattaforma, il che richiederebbe una replicazione dei componenti mostrati in \Cref{fig:architecture}.
+In tale situazione sarebbe necessario conoscere per ogni utente il suo \textenglish{cookie} di sessione, quindi bisognerà prevedere una modifica della base di dati, in maniera da poter legare l'utente al proprio \textenglish{cookie}.
+
+Per concludere si illustra un difetto di implementazione nel salvataggio del carrello, infatti questa operazione avviene solo nel momento in cui la sessione di navigazione viene distrutta, ovvero quando risulta scaduta o si è eseguito il \textenglish{logout}.
+Tuttavia l'esperienza ci insegna che generalmente l'utente non esegue tale azione, esso preferisce chiudere la pagina di navigazione, ma così facendo il carrello non sarà \textbf{immediatamente} salvato sulla base di dati.
+Quindi se di lì a poco l'utente riesegue l'accesso non troverà il carrello come lo aveva lasciato.
+Purtroppo tale difetto è portato da una considerazione di prestazioni, infatti  per correggerlo basterebbe che il salvataggio avvenisse ogni qualvolta si fa una modifica sul carrello.
+Ad ogni modo se questa operazione risulta frequente, si rischia di avere un gran numero di scritture sulla base di dati.
+
+Si potrebbe infine passare a uno sviluppo più rapido, senza cambiare linguaggio, ma utilizzando un \textenglish{framework} come Spring~\cite{spring}, che nonostante faccia uso di \mbox{Tomcat}, rende più agevole e compatta l'implementazione perché fornisce un gran numero di annotazioni, le quali fanno inteso uso della riflessione di Java.
\ No newline at end of file

relazione/src/contents/introduzione-al-lavoro/introduzione-al-lavoro.tex

@@ -5,7 +5,7 @@
 \label{ch:introduzione-al-lavoro}
 \graphicspath{{contents/introduzione-al-lavoro/assets/img/}}
 
-Abbiamo già detto che lo scopo del lavoro è stato quello di realizzare una piattaforma per l'\textenglish{e-commerce}.
+Abbiamo già detto che lo scopo del lavoro è stato quello di realizzare una piattaforma per l'\ecommerce.
 Questo termine, entrato nell'uso quotidiano, rende l'idea di ciò che si voleva ottenere, ma non rende giustizia al lavoro svolto, anzi lo minimizza.
 Per questo motivo, prima di trattare gli aspetti concreti del lavoro, sarà necessaria una panoramica riguardo i requisiti funzionali e non desiderati.
 
@@ -16,17 +16,16 @@ In particolare nel corso del capitolo, oltre ai requisiti, si prenderanno in esa
 
 All'inizio il sistema informatico era fruibile attraverso il software \prog{Access}~\cite{msaccess} con cui era stato realizzato.
 Per esigenze puramente aziendali esso non era esposto all'esterno dell'\textenglish{intranet}.
-Questa situazione è perdurata fino a quando grandi aziende del commercio elettronico, come Amazon ed eBay, non sono diventate competitor delle più piccole; urgerva quindi la necessità di mettere a disposizione una piattaforma indipendente e dedicata, fu scelto \prog{Joomla}~\cite{joomla}.
+Questa situazione è perdurata fino a quando grandi aziende del commercio elettronico, come Amazon ed eBay, non sono diventate competitor delle più piccole; urgeva quindi la necessità di mettere a disposizione una piattaforma indipendente e dedicata, fu scelto \prog{Joomla}~\cite{joomla}.
 Negli stessi anni prendeva anche piede una tipologia di \textenglish{cloud computing}, il \textenglish{Software as Service} (SaaS), che delega l'installazione e la manutenzione del server e dei servizi a terzi, lasciando all'utente la sola configurazione dell'applicazione pagata; si veda anche \cite{Sommerville2017}.
 Il difficile uso dell'applicazione portò a un nuovo cambiamento e venne acquistato un nuovo servizio, sempre con le stesse modalità.
 Si trattava di \prog{WordPress}~\cite{wordpress}.
 
-\prog{WordPress} non nasce per siti dedicati all'e-commerce, ma per blog.
+\prog{WordPress} non nasce per siti dedicati all'\ecommerce, ma per blog.
 Tuttavia, essendo \textenglish{open source} è possibile creare o installare \textenglish{plugin} per adattarlo a qualsiasi esigenza.
 L'uso dei \textenglish{plugin} sembra offrire all'utente, anche alle prime armi, un buon punto di partenza per sviluppare la propria piattaforma, ma questo meccanismo nasconde dei difetti.
-In primo luogo, ogni \textenglish{plugin} è indipendente dagli altri, ciò non toglie che ve ne siano alcuni tra di loro compatibili e anche raccomandati dagli stessi sviluppatori.
-Ad ogni modo si verifica spesso l'effetto opposto, ovvero l'incompatibilità, che può portare a un peggioramento dell'usabilità della piattaforma da parte dei clienti e del gestore.
-In secondo luogo, molti \textenglish{plugin} sono sviluppati in lingua inglese e, soprattutto per quelli meno conosciuti, non esiste una traduzione oppure è incompleta; ancora una volta i clienti e il gestore, che non padroneggiano la lingua, si trovano in difficoltà.
+In primo luogo, ogni \textenglish{plugin} è indipendente dagli altri, il che porterebbe a pensare all'assenza di problemi inerenti la compatibilità, ma non è così, infatti spesso l'incompatibilità può portare a un peggioramento dell'usabilità della piattaforma da parte dei clienti e del gestore.
+In secondo luogo, molti \textenglish{plugin} presentano maschere in lingua inglese e, soprattutto per quelli meno conosciuti, non esiste una traduzione oppure è incompleta; ancora una volta i clienti e il gestore, che non padroneggiano la lingua, si trovano in difficoltà.
 Inoltre, le poche conoscenze riguardo la sicurezza informatica possono portare a esporre la cartella \file{wp-content/plugins} verso l'esterno, da cui è possibile conoscere i \textenglish{plugin} installati.
 Pur avendo evitato questo problema, spesso non si effettuano gli aggiornamenti dei \textenglish{plugin}, i quali possono ancora essere scoperti da \textenglish{software} come \prog{wpscan}~\cite{wpscan}, che permette anche di conoscere le vulnerabilità della versione corrente, se non aggiornata, e di fatto aiutare l'attaccante nel suo intento.
 Infine l'uso di \textenglish{plugin} per modellare la base di dati, attraverso la definizione di metadati, può risultare difficile al gestore che si trova a dover completare differenti campi di cui a volte non conosce il significato; questo fatto si verifica di frequente qualora il \textenglish{plugin} abbia una scarsa o inesistente documentazione, ma anche quando questa è in inglese.
@@ -57,59 +56,76 @@ L'uso delle storie utente si è dimostrato particolarmente efficace -- le person
 Inoltre possono essere utili per facilitare la comunicazione tra sviluppatore e committente, coinvolgendo maggiormente quest'ultimo nella fase di deduzione dei requisiti.
 Una volta che il committente avrà indicato l'ordine di priorità per le storie, potrà essere creato il primo \textenglish{sprint backlog} selezionando gli elementi dal \textenglish{product backlog} e completandolo entro uno \textenglish{sprint}.
 Per esigenze di tempo, ma anche per mantenere aggiornato il committente, si è fissata la durata dello \textenglish{sprint} a una settimana, al termine della quale avvenivano incontri ``a distanza'' dove si mostrava il lavoro fin lì svolto.
-Questi momenti di incontro erano anche occasione per revisionare il \textenglish{product backlog} ed eventualmente cambiare la priorità delle storie utente o variare i requisiti. In \Cref{fig:scrum} è illustrato il processo Scrum, per approfondimenti si veda \cite{Sommerville2017}.
+Questi momenti di incontro erano anche occasione per revisionare il \textenglish{product backlog} ed eventualmente cambiare la priorità delle storie utente o variare i requisiti.
+In \Cref{fig:scrum} è illustrato il processo Scrum, per approfondimenti si veda \cite{Sommerville2017}.
 \begin{figure}[t]
 	\centering
-	\includegraphics[width=0.7\linewidth]{scrum.png}
-	\caption[Il ciclo degli sprint di Scrum]{Il ciclo degli sprint di Scrum}
+	\includegraphics[width=.7\linewidth]{scrum.png}
+	\caption[Il ciclo degli sprint di Scrum]{Il ciclo degli sprint di Scrum (trattato da \cite{Sommerville2017}).}
 	\label{fig:scrum}
 \end{figure}
 
 \subsection{I requisiti}
 \label{subsec:i-requisiti}
 
-Concludiamo il capitolo dedicando questo paragrafo ai requisiti, che saranno ripresi in dettaglio nel \Cref{ch:lavoro-svolto} per analizzarne le eventuali problematiche e le idee implementative.
-
-Cominciamo dai requisiti funzionali espressi come requisiti dell'utente, cioè con un linguaggio naturale e un alto livello di astrazione.
+Concludiamo il capitolo dedicando questa sezione ai requisiti, che saranno ripresi in dettaglio nel \Cref{ch:lavoro-svolto} per analizzarne le eventuali problematiche e le idee implementative.
 
+Cominciamo dai requisiti funzionali espressi, per semplicità, come requisiti dell'utente, cioè con un linguaggio naturale e un alto livello di astrazione.
 \begin{enumerate}
 [%
 	label=RF\arabiczeropad{*}{2},
 	format=\bfseries\upshape\sffamily
 ]
-	\item Ogni prodotto deve avere uno \textenglish{\textit{Stock Keep Unit}} (SKU): un identificativo univoco all'interno del magazzino.
-	Inoltre deve avere un nome, un'immagine, una descrizione, un prezzo base da listino e una categoria o sottocategoria di appartenenza, ad esempio per poter esprimere ``un tavolo in acciaio'' o ``una sedia in acciaio''.
+	\item\label{itm:product} Ogni prodotto deve avere uno \textenglish{\textit{Stock Keep Unit}} (SKU): un identificativo univoco all'interno del magazzino.
+	Inoltre deve avere un nome, un'immagine, una descrizione, un prezzo base da listino e una categoria di appartenenza, ad esempio ``tavolo in acciaio'' o ``sedia in acciaio''.
 
 	\item Ogni prodotto deve mostrare una media delle proprie valutazioni complessive.
 
 	\item L'utente deve essere avvertito qualora il prodotto sia recentemente stato aggiunto.
 
-	\item Il prodotto può essere personalizzato a piacere dal cliente, la personalizzazione ne determina l'aumento o meno del prezzo.
+	\item\label{itm:customization} Il prodotto può essere personalizzato a piacere dal cliente, la personalizzazione ne determina l'aumento o meno del prezzo.
 	Anche in questo caso deve essere possibile una visualizzazione del prodotto personalizzato che si vorrà acquistare.
 
-	\item Per ogni prodotto, se disponibile, deve essere acquistabile ogni suo ricambio.
+	\item\label{itm:part} Per ogni prodotto, se disponibile, deve essere acquistabile ogni suo ricambio.
+
+	\item\label{itm:part-isa-product} Un ricambio è un prodotto.
+
+	\item\label{itm:category} Ogni categoria deve poter contenere nessuna, una o più sottocategorie indipendentemente dalla presenza di prodotti al suo interno.
+
+	\item Le categorie devono avere un nome e deve essere possibile indicare all'utente quelle create di recente.
+
+	\item Il cliente può essere sia un'azienda sia un privato.
 
-	\item La registrazione di un nuovo cliente richiede \emph{solamente} un'\textenglish{e-mail} e una password.
-	Al termine della procedura l'\textenglish{account} deve essere attivato dall'apposito link inviato all'\textenglish{e-mail} del nuovo \emph{potenziale} acquirente.
+	\item\label{itm:sign-up} La registrazione di un nuovo cliente richiede \textbf{solamente} un'\textenglish{e-mail} e una password.
+	Al termine della procedura l'\account deve essere attivato dall'apposito link inviato all'\textenglish{e-mail} del nuovo \textbf{potenziale} acquirente.
 
-	\item Qualora l'account non venga attivato l'utente, pure essendo registrato, non avrà alcun privilegio rispetto ad uno non registrato.
+	\item\label{itm:privileges} Qualora l'\account non venga attivato l'utente, pure essendo registrato, non avrà alcun privilegio rispetto ad uno non registrato.
 
 	\item Il cliente deve poter, in un secondo momento, completare il proprio profilo.
 
-	\item Il \textenglish{form} di completamento del profilo utente richiede nome, cognome e codice fiscale, per poter intestare la fattura, inoltre dal codice fiscale è possibile estrarre la data di nascita, eventualmente utile per promozioni mirate basate sul compleanno.
-	Inoltre deve essere richiesto l'inserimento di almeno un indirizzo e un numero di telefono, da poter fornire al corriere.
-	Tutti i dati, compresa l'\textenglish{e-mail}, devono poter essere modificabili.
+	\item Il cliente durante il completamente del suo profilo deve registrare almeno un indirizzo e un numero di telefono, da poter fornire al corriere.
+	Tutti i dati del profilo, compresa l'\textenglish{e-mail}, devono poter essere modificabili.
+
+	\item Il \textenglish{form} di completamento del profilo di un privato richiede nome, cognome e codice fiscale, per poter intestare la fattura, inoltre dal codice fiscale è possibile estrarre la data di nascita, eventualmente utile per promozioni mirate basate sul compleanno.
+
+	\item L'azienda è da considerasi come un utente, l'\textenglish{e-mail} che fornirà potrebbe anche essere quella del responsabile degli acquisti.
+	In ogni caso anche per l'azienda deve essere previsto un \textenglish{form} apposito, che richieda la partita IVA, necessaria per intestare le fatture e il nome dell'azienda.
+	Inoltre deve essere presente almeno uno tra PEC e codice univoco, utili per la fatturazione elettronica.
 
-	\item L'accesso all'account utente deve poter essere effettuabile attraverso l'\textenglish{e-mail} e la password fornite in fase di registrazione.
+	\item\label{itm:login} L'accesso all'\account utente deve poter essere effettuabile attraverso l'\textenglish{e-mail} e la password fornite in fase di registrazione.
 
-	\item Il prodotto deve poter essere visibile prima di entrare di fatto in commercio, in tal modo l'utente interessato, registrato o meno, potrà fare richiesta di notifica via \textenglish{e-mail}, che sarà inviata non appena il prodotto diventerà acquistabile.
+	\item Il prodotto deve poter essere visibile anche prima di entrare di fatto in commercio, in tal modo l'utente interessato, registrato o meno, potrà fare richiesta di notifica via \textenglish{e-mail}, che sarà inviata non appena il prodotto diventerà acquistabile.
 	Un discorso analogo vale per i prodotti esauriti, ma non ritirati.
 
-	\item I prodotti ritirati devono essere consultabili, per poter reperire se necessario ricambi, ma non sarà possibile acquistarli né vederne il prezzo.
+	\item I prodotti ritirati devono essere consultabili, per poter reperire se necessario ricambi, ma non sarà possibile acquistarli né vederne il prezzo, tuttavia vi si potrà lasciare una recensione.
+	Questo perché un cliente potrebbe voler comunque esprimere il suo apprezzamento.
 
-	\item L'utente, registrato o non, potrà effettuare ricerche o sfogliare il catalogo dei prodotti, in cui verrà mostrato il prezzo base da listino.
+	\item\label{itm:substitutes} Ogni prodotto ritirato deve poter indicare quali sono i suoi sostituti, se presenti.
 
-	\item Alla selezione di un articolo o alla visualizzazione del carrello al cliente deve essere mostrato l'imponibile tassato.
+	\item L'utente, registrato o non, potrà effettuare ricerche o sfogliare il catalogo dei prodotti.
+	In entrambi i casi verrà mostrato il prezzo base da listino e sarà possibile ordinare i prodotti per prezzo o per nome.
+
+	\item Al cliente deve essere mostrato l'imponibile tassato alla selezione di un articolo o alla visualizzazione del carrello .
 
 	\item Il cliente deve essere informato qualora la quantità del prodotto scenda sotto un numero prefissato di unità.
 
@@ -119,11 +135,11 @@ Cominciamo dai requisiti funzionali espressi come requisiti dell'utente, cioè c
 
 	\item Qualora nel carrello recuperato vi fossero articoli ritirati o esauriti, l'utente deve essere avvertito e il totale deve essere aggiornato di conseguenza, ovvero senza tenere conto di questi articoli.
 
-	\item Prima di procedere all'acquisto, è logico che il profilo utente risulti completo in ogni sua parte.
+	\item\label{itm:profile} Prima di procedere all'acquisto, è logico che il profilo utente risulti completo in ogni sua parte.
 
 	\item\label{itm:payment} L'acquisto di un prodotto avviene per mezzo di carta di credito oppure PayPal.
 
-	\item La ricerca nel catalogo può includere termini contenuti sia nel nome del prodotto sia nelle sua descrizione.
+	\item\label{itm:search} La ricerca nel catalogo può includere termini contenuti sia nel nome del prodotto sia nelle sua descrizione.
 
 	\item Qualsiasi utente, registrato o non, può visualizzare le recensioni lasciate da altri.
 	In particolare deve poter ordinarle per ``più recenti'' oppure per gradimento crescente o decrescente.
@@ -132,11 +148,10 @@ Cominciamo dai requisiti funzionali espressi come requisiti dell'utente, cioè c
 
 	\item L'utente può recensire il prodotto non più di una volta.
 
-	\item L'inserimento di una recensione richiede, qualora non sia già stato fatto, il completamento dell'account.
+	\item L'inserimento di una recensione richiede, qualora non sia già stato fatto, il completamento dell'\account.
 
-	\item Nel completare il \textenglish{form} per la recensione l'utente potrà specificare opzionalmente un titolo, una valutazione complessiva e, ovviamente, la recensione stessa.
+	\item\label{itm:review} Nel completare il \textenglish{form} per la recensione l'utente potrà specificare opzionalmente un titolo, una valutazione complessiva e, ovviamente, la recensione stessa.
 
-	\item Le categorie devono avere un nome e deve essere possibile indicare all'utente quelle create di recente.
 \end{enumerate}
 
 Infine, di seguito sono riportati i requisiti non funzionali.
@@ -147,6 +162,12 @@ label=RNF\arabiczeropad{*}{2},
 format=\bfseries\upshape\sffamily
 ]
 
-\item
+\item L'interfaccia utente sarà grafica.
+\item Il codice sarà scritto in Java e si eseguirà su \mbox{Tomcat}.
+\item Il database utilizzato sarà MySQL\@.
+\item Lo sviluppo inizia a fine giugno 2020 e la consegna è prevista per metà agosto 2020.
+\item\label{itm:pci-dss} Rispettare lo standard PCI~DSS\@.
+\item Rispettare il GDPR\@.
+\item Le date saranno memorizzate nel formato AAAA/MM/GG\@.
 
 \end{enumerate}
\ No newline at end of file

relazione/src/contents/introduzione/introduzione.tex

@@ -5,3 +5,27 @@
 \label{ch:introduzione}
 \graphicspath{{contents/introduzione/assets/img/}}
 
+Fino a qualche decennio fa piccole aziende, specializzate nella realizzazione di uno o più prodotti, erano conosciute solo attraverso il passaparola dei pochi fidati clienti.
+Nonostante soddisfacessero una limitata richiesta, esse riuscivano a coprire tutte le spese di produzione e ad avere un buon ritorno economico.
+Oggi, però, la situazione è ben diversa.
+In un mercato sempre più ``digitale'', che accorcia le distanze tra chi vende e chi compra, solo le aziende che si rinnovano possono sopravvivere.
+Viviamo in oltre in una società frenetica, in cui le aziende devono rispondere alle esigenze di un cliente, che magari vuole un prodotto particolare, a un prezzo contenuto, con un'alta qualità, ma senza dover effettuare una lunga ricerca.
+Tutto ciò è possibile su una piattaforma \ecommerce, per esempio i clienti lasciano recensioni sulla base delle quali, opportuni algoritmi possono indirizzare la ricerca di un utente, garantendo un certo grado di qualità ad un prezzo contenuto, indicato dal cliente attraverso un filtro.
+
+In questa situazione si trovò anche la Trimar S.r.l.\ di Frugarolo, attiva nella produzione di sedie e tavoli da interno ed esterno fin dal 1982.
+L'azienda si impegnò fin da subito nella digitalizzazione del processo di vendita, ma con scarsi risulti.
+Si aveva quindi la necessità di avere un \ecommerce il più aderente possibile alle esigenze dell'azienda e dei suoi clienti.
+Questa necessità portò alla collaborazione, che vide la nascita della piattaforma descritta in queste pagine.
+
+In particolare nel \Cref{ch:introduzione-al-lavoro} si discuterà dell'approccio che si è seguito in preparazione al lavoro, in cui si illustrerà il \textenglish{software} presente e le sue limitazioni, il perché si è scelta una soluzione \textit{ad hoc}, la metodologia del processo di sviluppo e infine i requisiti funzionali e non individuati.
+
+Dopo aver contestualizzato il progetto, nel \Cref{ch:lavoro-svolto} si passerà a trattare il lavoro vero e proprio.
+Si analizzerà da prima l'architettura scelta e poi, sulla base di quest'ultima, si articolerà tutto il capitolo.
+In particolare si affronteranno, per ogni livello dell'architettura, le scelte progettuali fatte e le problematiche annesse.
+Si partirà da una descrizione astratta del problema e si arriverà fino al livello di presentazione dei dati all'utente.
+Ci si scusa in anticipo se non tutte le scelte saranno trattate, ma si promette di mostrare quelle più interessanti e ricercate, nella speranza che il lettore non si annoi troppo.
+
+Giunto al \Cref{ch:strumenti-utilizzati}, il lettore conoscerà meglio gli strumenti utilizzati, alcuni già incontrati nel capitolo precedente.
+
+Infine nell'ultimo capitolo, il \ref{ch:conclusioni}, verranno proposte e commentate alcune migliorie, che potrebbero far parte della fase di manutenzione migliorativa del progetto.
+Per ogni possibile miglioramento si illustrerà uno o più modi di procedere nel realizzarlo, ovviamente sarà solo un'analisi teorica, la quale tralascerà le problematica che potrebbero sorgere.
\ No newline at end of file

relazione/src/contents/lavoro-svolto/contents/architecture.tex

+% !TeX encoding = UTF-8
+% !TeX root = ../../../FERRON_relazione.tex
+
+\section{Architettura}
+\label{sec:architettura}
+
+La scelta dell'architettura è stata fatta sulla base di quattro fattori: il numero di viste giornaliere, i costi per l'\textenglish{hosting} della piattaforma, la staticità dei prodotti dell'azienda e la semplicità.
+Considerate queste esigenze, l'architettura più appropriata era quella \textenglish{client-server} a tre livelli, come mostrata in \Cref{fig:architecture}.
+
+Uno dei vantaggi di questa architettura è quello di poter aggiungere controlli su tutti i livelli, avendo la sicurezza di avvisare l'utente appena si verifica un errore senza dover arrivare fino alla base di dati.
+In secondo luogo si ha la garanzia che qualora un controllo dovesse mancare su un livello, interviene quello sottostante, non pregiudicando le qualità dell'applicazione (tra cui l'integrità dei dati).
+Tuttavia, una tale situazione potrebbe ancora accadere solo se non fosse previsto un dato controllo su nessuno dei livelli.
+
+Dalla \Cref{fig:architecture} salta all'occhio una netta separazione tra la logica dell'applicazione, rappresentata dall'\textenglish{application server}, e la base di dati.
+Separando i componenti abbiamo la possibilità di replicarli (\textenglish{scaling out}) e raggrupparli (\textenglish{clustering}) come in \Cref{fig:load-balancing}, per permettere un miglior \textenglish{load balancing}, qualora ci sia un aumento delle visite, e un maggior \textenglish{fault tolerant}.
+Inoltre si è ritenuto che tale architettura risultasse maggiormente intuitiva per l'utente rispetto ad una a microservizi, anche se quest'ultima è ormai diventata più diffusa per via dell'alto grado di manutenibilità.
+\begin{figure}[t]
+	\centering
+	\includegraphics[width=.5\linewidth]{load-balancing.pdf}
+	\caption{Esempio di \textenglish{scaling out}.}
+	\label{fig:load-balancing}
+\end{figure}
+In particolare permette l'aggiunta di nuove funzionalità o il miglioramento di quelle esistenti, semplicemente sostituendo o espandendo uno dei microservizi.
+Tuttavia l'azienda, non essendo di grosse dimensioni, non punta a un continuo rinnovamento, essa preferisce espandere la sua cerchia di clienti, rimando coerente con quelli più fedeli.
+Ecco che quindi si presenta un modello molto statico soprattutto nel campionario di prodotti forniti.
+
+Di seguito si illustra brevemente quali sono le interazioni tra \textenglish{client} e \textenglish{server}.
+\begin{enumerate}
+	\item Il \textenglish{(thin) client}, per esempio un \textenglish{browser}, apre una connessione verso il \textenglish{web server}, al quale invia una richiesta in HTTPS e si mette in attesa (sincronismo).
+	\item Il \textenglish{web server} ricevuta la richiesta la passa al \textenglish{web container}.
+	Quest'ultimo l'analizza e se necessario recupera i dati dal \textenglish{database}, li manipola e genera dinamicamente la pagina da presentare all'utente.
+	\item La richiesta soddisfatta viene nuovamente passata al \textenglish{web server}, che la rinvia al mittente con l'appropriato stato HTTP impostato dal livello precedente per indicare la presenza o meno di errore.
+	\item Il \textenglish{client} mostra all'utente la pagina.
+	\item Il \textenglish{client} o il \textenglish{server} possono scegliere se terminare la connessione oppure mantenerla aperta per ulteriori richieste.
+\end{enumerate}
+\begin{figure}[t]
+	\centering
+	\includegraphics[width=\linewidth]{architecture.pdf}
+	\caption{Architettura client-server a tre livelli.}
+	\label{fig:architecture}
+\end{figure}
+Il tipo di architettura appena descritto si adatta molto bene a qualsiasi \textenglish{application server}\footnote{Si è generalizzato un po' troppo con questo termine, infatti \mbox{Tomcat} non soddisfa tutti i requisiti di un \textenglish{application server} come si vedrà nel \Cref{ch:strumenti-utilizzati}.} basato su JavaEE, compreso Tomcat.
+Inoltre è usato anche dalle piattaforme di e-commerce SaaS, come \prog{Magento}.
+Tuttavia aziende come Amazon usano un'architettura a microservizi.
+Tale scelta comporta avere tanti team quanti i microservizi; ogni team deve essere un \textit{\textenglish{two-pizza team}}, ovvero deve avere un numero di membri che possano essere sfamati con solo due pizze.
+Questa filosofia consente un rapido sviluppo, tralasciando lunghe riunioni di progetto, proprio perché il personale è limitato.
+Amazon, infatti afferma che può far passare una modifica dalla fase di \textenglish{deployment} a quella di produzione ogni $11,6$ secondi.
+Per maggiori dettagli su queste architetture si faccia riferimento a \cite{Richardson2019}.
+
+Nel seguito del capitolo si dedicherà una sezione per ciascuno dei livelli presentati in \Cref{fig:architecture}.
\ No newline at end of file

relazione/src/contents/lavoro-svolto/contents/business-layer.tex

+% !TeX encoding = UTF-8
+% !TeX root = ../../../FERRON_relazione.tex
+
+\section{Business layer}
+\label{sec:business-layer}
+
+Questo livello occupa il ruolo di collante tra ciò che è mostrato all'utente e i dati che saranno manipolati.
+La mole di dati che lo attraversa richiede di essere gestita in maniera efficiente e sicura.
+Vista l'importanza di questi aspetti, non gli si poteva non dedicare una sezione.
+
+In particolare saranno soprattutto discusse le problematiche di sicurezza che sono sorte, le loro soluzioni e quale impatto sulle prestazioni hanno portato queste ultime.
+Infine non mancherà la discussione di un problema di concorrenza, che è sempre presente nelle piattaforme \ecommerce.
+%\subsection{ORM}
+% TODO: argomenti da trattare:
+%				- spiegare la semantica per mappare;
+%				- come operariamo: la riflessione
+%				- chec cos'è la riflessione?
+
+\subsection{Accounting}
+\label{subsec:accounting}
+
+In questa sezione esamineremo il \textenglish{login} e la registrazione.
+Partiamo da quest'ultima.
+
+La registrazione consiste nel completamento di un \textenglish{form} richiedente un'\textenglish{e-mail} e una \textenglish{passphrase} di almeno 8 caratteri.
+Così facendo si suggerisce all'utente di usare una frase piuttosto che una parola come \textenglish{password}, per facilitarne il ricordo.
+
+Prima di poter inviare la richiesta di registrazione il cliente è tenuto ha completare il reCAPTCHA proposto, la cui risposta sarà allegata alla richiesta.
+In particolare si è usato il reCAPTCHA versione 2, il quale propone una sfida all'utente ovvero selezionare le immagine che contengono oppure no un determinato oggetto.
+È d'obbligo specificare la versione usata, perché Google ha sviluppato ben tre versioni differenti.
+Nella prima, oramai deprecata, viene richiesto all'utente di inserire il testo che legge, esattamente come l'originale sistema CAPTCHA\@.
+Al contrario nell'ultima versione non viene proposta sfida all'utente, anzi gli viene assegnato un punteggio stabilito in base all'interazione con il sito \textenglish{web}.
+L'utilità del reCAPTCHA è di evitare registrazioni fatte da \textenglish{bot}, realizzabili, per esempio, con librerie e strumenti messi a disposizione dal progetto Selenium~\cite{selenium}.
+Inoltre si prevengono attacchi \textenglish{distributed denial of service} (DDoS).
+
+Verificato lato server la risposta del reCAPTCHA, si passa al controllo dell'\textenglish{e-mail}, sfruttando i \textenglish{Mail eXchanger (MX) record}.
+In particolare si scorpora il dominio dall'\textenglish{e-mail}, usando come separatore il carattere ``\verb|@|'', si ottiene la lista degli MX \textenglish{record}, che risolvo quel dominio, e si verifica che non sia vuota.
+Qualora tale lista fosse vuota si restituisce un errore all'utente.
+Si noti che tale controllo non assicura l'esistenza della casella di posta sul dato dominio, pertanto è possibile creare \account con \textenglish{e-mail} basata su domini reali, ma caselle di posta inesistenti.
+Tuttavia tale problema può essere ovviato controllando che l'\textenglish{e-mail} di conferma dell'\account arrivi a destinazione.
+In caso contrario è possibile eliminare l'\account appena creato.
+
+Qualora tutti i controlli passassero si può procedere con l'effettiva memorizzazione\linebreak dell'\account sulla base di dati.
+Quest'operazione implica il salvataggio della \textenglish{passphrase} in maniera sicura.
+In primo luogo bisogna considerare che l'utente generalmente riutilizza le stesse \textenglish{password}, per tale motivo è necessario prevedere un meccanismo che non renda visibile la \textenglish{password} né agli utenti legittimi, come ai manutentori della base di dati, né a un potenziale malintenzionato, che ottiene illecitamente l'accesso.
+Per fare ciò si utilizza una funzione di derivazione della chiave, che presa in ingresso una \textenglish{passphrase} restituisce una chiave crittografica.
+Si è scelto come algoritmo PBKDF2~\cite{Moriarty2017}, il quale, oltre alla \textenglish{passphrase}, prende in input una stringa casuale (il \textenglish{salt}), il numero di iterazioni, la lunghezza in bit della chiave derivata e la funzione pseudocasuale da applicare, nel nostro caso HMAC\@.
+Tale meccanismo impedisce sia un attacco a forza bruta sia a dizionario, in effetti tali attacchi risultano più difficili all'aumentare del numero di iterazioni.
+Oltre a questi attacchi, il \textenglish{salt} garantisce l'impossibilità di precalcolare le chiavi corrispondenti alle password più probabili (\textenglish{rainbow attack}) e non necessita di essere mantenuto segreto.
+Infatti sul \textenglish{database} le credenziali saranno memorizzate nella forma \verb|salt$iterationCount$encodedCredential|.
+
+Effettuata la registrazione l'utente può fare il \textenglish{login}.
+Il \textenglish{form} che mette a disposizione questa funzionalità richiede un'\textenglish{e-mail} e una \textenglish{password}, come da \ref{itm:login}.
+Dall'\textenglish{e-mail} si ricercano le credenziali crittografate, che vengono usate per validare la \textenglish{password} fornita.
+Qualora l'\textenglish{e-mail} non corrisponda a nessun \account, viene comunque derivata una chiave dalla password fornita, prima di restituire l'errore.
+Questo non è lavoro inutile, ma previene i \textenglish{timing attack}, ovvero l'attaccante non può dedurre alcuna informazione utile basandosi sul tempo di risposta della richiesta.
+Inoltre effettuando il \textenglish{login} vi è un \textenglish{refresh} del valore del \textenglish{cookie} di sessione (\textenglish{\texttt{JSESSIONID}}), in tal modo si prevengono \textenglish{session fixation attack}.
+
+Infine si vuol far presente che qualora l'accesso venga sbagliato per 5 volte consecutive, non sarà permesso accedere per 5 minuti.
+Anche questa misura è stata adottata per evitare attacchi a forza bruta, infatti ogni 5 tentativi vi è un lasso di tempo che rallenta sensibilmente il processo di attacco.
+
+\subsection{Il problema della cache}
+\label{subsec:il-problema-della-cache}
+
+Le pagine che richiedono un autenticazione non devono poter essere visibili una volta effettuato il \textenglish{logout}.
+Tuttavia i \textenglish{browser}, per necessità di efficienza, salvano in \textenglish{cache} le pagine visitate.
+Questo comporta la possibilità di recuperare dalla cronologia, le pagine, che richiedono autorizzazione nonostante si sia fatto il \textenglish{logout}.
+Per impedire questo comportamento, il \textenglish{browser} non dovrebbe memorizzare le pagine sensibili in \textenglish{cache}.
+Ciò può essere realizzato impostando opportunamente gli \textenglish{header} HTTP di tali pagine.
+Più precisamente, prima che la risposta giunga al \textenglish{client} vi è un filtro (vedi \Cref{ch:strumenti-utilizzati}) che inserisce nell'\textenglish{header} i seguenti valori:
+\begin{verbatim}
+	Cache-Control: no-cache, no-store, must-revalidate
+	Pragma: no-cache
+\end{verbatim}
+A questo punto qualora una pagina, che necessita di autenticazione, venga nuovamente richiesta, non essendo trovata nella \textenglish{cache}, sarà inviata dal \textenglish{server}, che potrà fare gli opportuni controlli.
+Per tanto pagando un piccolo prezzo in termini di prestazioni, si ha una maggiore sicurezza.
+
+\subsection{XSS}
+\label{subsec:xss}
+
+Abbiamo già detto che la descrizione di un prodotto e il corpo di una recensione sono editabili attraverso un editor WYSIWYG (vedi \Cref{subsec:schema-concettuale}), il cui principale vantaggio è quello di essere percepito, da parte dell'utente, come un qualunque \textenglish{word processor}, nascondendo l'HTML e il CSS di cui fa uso.
+Per gli utenti più esperti è comodo lavorare direttamente con questi linguaggi.
+
+Così facendo però, è possibile inserire all'interno dell'HTML, codice JavaScript, che verrebbe salvato sul \textenglish{database} e mandato in esecuzione ogni volta che la pagina, che lo contiene, fosse recuperata.
+L'editor diventa un veicolo per sferrare un attacco \textenglish{cross-site scripting} (XSS) da parte di malintenzionati, perciò bisogna evitarlo.
+La soluzione adotta è stata quella di ripulire (\textenglish{\textit{sanitize}}), con la libreria AntiSamy~\cite{antisamy}, i testi contenenti codice HTML, da potenziale codice JavaScript.
+
+\subsection{IDOR}
+\label{subsec:idor}
+
+Abbiamo mostrato l'uso intensivo delle chiavi surrogate (vedi \Cref{fig:eer}), che permettono di individuare efficientemente l'oggetto di interesse.
+Viene naturale pensare di esporre tali chiavi agli utenti della piattaforma, per esempio inserendole all'interno dell'URL\@.
+Tale approccio è chiamato \textenglish{Insecure Direct Object Reference} (IDOR).
+Pur non costituendo un problema di sicurezza diretta, l'attaccante potrebbe stabilire il \textenglish{pattern} su cui una chiave primaria si basa e sferrare un \textenglish{enumeration attack}, il cui scopo sarebbe ottenere l'accesso ai dati con quel formato di chiave.
+
+Per proteggersi da questo attacco, piuttosto che mostrare le chiavi in chiaro, basterebbe esporre una loro trasformazione difficilmente reversibile (\textenglish{one-way}).
+Per questa ragione ogni chiave esposta prima è stata concatenata con un \textenglish{pepper}, ovvero un \textenglish{salt} fisso, e successivamente passata a una funzione SHA-256.
+Si è scelta tale funzione, piuttosto che SHA-512, perché si voleva identificatori brevi, ma robusti.
+
+Tuttavia la soluzione proposta necessita di calcolare ogni volta, per ogni richiesta, la funzione \textenglish{hash}, dato che i valori non cambiano, si è usata una struttura dati per conservare l'associazione tra chiave e identificatore calcolato.
+Tale struttura non ammette duplicati ed è condivisa tra tutti i \textenglish{thread} di una data servlet (vedi \Cref{ch:strumenti-utilizzati}), in maniera tale che tutti ne possano beneficiare senza allocare ulteriore spazio.
+In particolare la struttura dati scelta è una \texttt{BiMap} implementata da Guava~\cite{guava}.
+
+\subsection{Concorrenza}
+\label{subsec:concorrenza}
+
+Cosa succede se due utenti acquistano contemporaneamente lo stesso prodotto, ma la quantità totale richiesta è superiore alle scorte in magazzino?
+Questo sarà il problema affrontato nella sezione.
+
+Il comportamento desiderato sarebbe quello in cui uno solo dei due utenti effettua l'ordine, mentre l'altro viene rimandato alla pagina del carrello per essere avvisato della quantità insufficiente.
+Questo comportamento può essere ottenuto usando le transazioni.
+Una transazione è un lotto atomico di operazioni, nel quale o tutte le operazioni sono portate a termine oppure non lo è nessuna (\textenglish{rollback}).
+Prima di creare effettivamente l'ordine, una transazione pone un \textenglish{lock} sui prodotti della tabella \textenglish{\texttt{product}} che si vogliono acquistare, al fine di poter eseguire le \textenglish{query} per decrementarne le quantità.
+Se durante tale operazione dovesse giungere un nuovo ordine, in cui tutti i prodotti sono in quantità sufficiente, ma che comprende, anche solo parzialmente, gli stessi articoli dell'ordine in processamento, questo sarebbe trattenuto fino al completamento dell'operazione precedente.
+Una volta che l'ordine è in attesa di pagamento (per maggiori dettagli si veda \Cref{ch:strumenti-utilizzati}), quello nuovo può essere processato, tuttavia è possibile che un prodotto non sia più in quantità sufficiente, perché già venduto nell'ordine precedente.
+Ricordando che esistono controlli ad ogni livello (vedi \Cref{sec:business-layer}), all'atto del decremento della quantità si avrà la violazione del vincolo sulla base di dati per cui \verb|quantity >= 0|.
+Questo fatto terminerebbe il processamento della transazione e l'utente sarebbe reindirizzato al carrello, da cui gli spetterà scegliere quale azione intraprendere.
+
+Anche se le quantità fossero sufficienti è ancora possibile, che la transazione non sia completata.
+Un ordine prima di essere creato deve essere pagato, quindi il lato server riceve i dati del metodo di pagamento, li processa e se nessun errore viene sollevato finalizza la transazione (\textenglish{commit}) scrivendo gli aggiornamenti delle quantità.
+Un semplice meccanismo, ma che presenta un difetto, infatti durante il processamento della transazione (monetaria) il \textenglish{lock} sulle righe della tabella \textenglish{\texttt{product}} è ancora presente, per tanto nessun altro ordine, che abbia, anche solo parzialmente, gli stessi articoli, può essere processato.
+Tale fatto si potrebbe ripercuotere sulle prestazioni, ecco perché si è cercato di ridurre la quantità di computazione tra il lancio della transazione e la sua finalizzazione.
+Ad esempio si è dichiarato ed eventualmente inizializzato le variabili necessarie prima di lanciare la transazione, in modo tale che queste operazioni non fossero eseguite quando il \textenglish{lock} era attivo, garantendone però la presenza qualora vi si faccia riferimento.
+
+Qualora non si usassero le transazioni, le \textenglish{query} verrebbero eseguite non appena possibile, ma tale comportamento porterebbe ad uno stato di inconsistenza e nessun ordine sarebbe realmente evaso.
\ No newline at end of file

relazione/src/contents/lavoro-svolto/contents/data-layer.tex

+% !TeX encoding = UTF-8
+% !TeX root = ../../../FERRON_relazione.tex
+
+\section{Data layer}
+\label{sec:data-layer}
+
+Cominciamo la nostra analisi dell'architettura dal primo livello che si è progettato, quello della base di dati.
+Questo livello si occupa dell'elaborazione dei dati, più specificatamente li memorizza, li manipola se necessario, ma soprattutto li recupera efficientemente.
+
+\subsection{Schema concettuale}
+\label{subsec:schema-concettuale}
+
+La prima fase della progettazione di questo livello è stata la definizione di uno schema concettuale, come illustrato dal diagramma \textenglish{Entity-Relationship} (ERD) nella \Cref{fig:er}.
+%La sintassi del diagramma è semplice e scarna.
+%Le entità sono modellate attraverso rettangoli, rappresentano oggetti del nostro d~ominio e possono essere specializzate attraverso una freccia di generalizzazione.
+%Ogni entità ha uno o più attributi modellati da un pallino vuoto collegato ad essa e rappresentanti una sua proprietà; qualora il pallino fosse pieno esso risulterebbe un identificatore.
+%Le associazioni tra entità sono rappresentate mediante dei rombi, che possono avere attributi.
+%Infine un'entità può essere identificata esternamente attraverso una relazione.
+%Questa sintassi permette di descrivere il problema graficamente tralasciando la soluzione, il comportamento delle entità o gli aspetti fisici riguardanti la base di dati, ma ponendo attenzione alla normalizzazione.
+%Andiamone ad esaminare alcune delle scelte progettuali fatte.
+
+Per modellare il \ref{itm:category} è stato necessario utilizzare un'associazione ricorsiva nella quale si esprime il fatto che una categoria può avere nessuna o più di una sottocategoria.
+Inoltre la ricorsività dell'associazione esprime il fatto che una sottocategoria è a sua volta una categoria, che però potrebbe non essere discendete di nessun altra.
+Per tali ragioni si è prevista l'opzionalità (cardinalità \texttt{(0,1)}) sul ramo inferiore dell'associazione \texttt{\textenglish{includes}}.
+
+\begin{sidewaysfigure}[p]
+	\centering
+	\includegraphics[width=\linewidth]{er.pdf}
+	\caption{Schema ER del progetto.}
+	\label{fig:er}
+\end{sidewaysfigure}
+
+Osservando l'entità \texttt{\textenglish{product}} si nota la presenza di due attributi \texttt{\textenglish{description}} e\linebreak \verb|description_no_html|, perché sono \textbf{entrambi} necessari?
+La ragione deriva dal \ref{itm:search}, infatti la ricerca, compiuta dal \textenglish{database}, non deve prendere in considerazione gli eventuali \textenglish{tag} HTML presenti nella descrizione del prodotto.
+Quest'ultima, richiesta dal \ref{itm:product}, è stata modellata come un testo HTML, perché si vuole lasciare all'amministratore la possibilità di descrivere al meglio il prodotto, attraverso un editor WYSIWYG\@.
+L'uso di un tale editor è stato fatto anche per inserire la recensione come richiesto dal \ref{itm:review}.
+
+Al prodotto è collegata l'entità \verb|product_image|, la quale descrive una sua particolare ``configurazione''.
+Ogni configurazione ha un immagine visibile all'utente (attributo \verb|url|), un testo alternativo all'immagine (\verb|htmlcontent|) e il prezzo (\verb|options_value_price|).
+Quest'ultimo è calcolato come incremento rispetto al \texttt{\textenglish{price}} del prodotto, entrambi sono memorizzati come riportati dal listino prezzi, ovvero scorporati dalle tasse e senza sconti.
+Si noti inoltre che il prodotto senza alcuna personalizzazione corrisponde alla ``configurazione'' base, per la quale vale \verb|options_value_price = 0|.
+
+Consideriamo ora il \ref{itm:part} e il \ref{itm:part-isa-product}.
+Per modellarli è stata usata l'associazione ricorsiva \texttt{\textenglish{comprises}}, per tanto è opportuno specificare i ruoli a cui i due rami dell'associazione si riferiscono.
+Un prodotto può avere uno o più ricambi, ma anche nessuno perché potrebbe essere esso stesso un ricambio; tutto ciò è modellato con la cardinalità \texttt{(0,N)}.
+Di conseguenza un ricambio sarà usato in almeno un prodotto, fatto che si è modellato usando la cardinalità \texttt{(1,N)}.
+Questo discorso può essere riproposto anche per i prodotti che sostituiscono quelli ritirati (\ref{itm:substitutes}), come si vede nell'associazione \texttt{\textenglish{substitutes}}.
+
+L'ultimo requisito che prenderemo in considerazione è il \ref{itm:payment}, il quale viene modellato con le entità \verb|credit_card| e \verb|sale_order| e la loro associazione.
+Esaminando \verb|sale_order| si nota che non vi è un attributo per il costo totale dell'ordine, piuttosto si è deciso di separare il costo totale della merce dal costo delle tasse.
+Questa scelta è stata fatta perché le tasse imposte possono variare con il tempo e quindi si è preferito scorporarle dal prezzo totale, che può essere ancora ottenuto dalla somma di \verb|subtotal_price| e \verb|tax_price|.
+Andando ad esaminare il requisito più nel dettaglio è necessario precisare cosa viene memorizzato qualora il pagamento sia effettuato con una carta di credito oppure PayPal.
+Nel primo caso ci sarà \textbf{sempre} un riferimento ai dati della carta di credito, memorizzati separatamente rispetto all'ordine.
+Questo significa che qualora vengano fatti più acquisti con la stessa carta di credito da parte di uno stesso cliente, essa sarà memorizzata nuovamente ogni volta.
+Tale scelta porterebbe a pensare a uno spreco di memoria, tuttavia questa è la soluzione ideale per non dover gestire le carte di credito di un cliente, ma richiedere solo i dati in fase di pagamento.
+Alcuni dei dati che vengono conservati, dopo essere stati processati, sono il \textenglish{\textit{Primary Account Number}} (PAN) troncato, ma generalmente composto da 16 cifre, la data di validità e il titolare; tutti nel rispetto del PCI~DSS~\cite{PSSC2018}, come richiesto dal \ref{itm:pci-dss}.
+Tale standard non ammette la memorizzazione, anche cifrata, di dati sensibili di autenticazione, quale per esempio il \textenglish{\textit{Card Validation Code}} o \textenglish{\textit{Value}} (CVC o CVV), usato per respingere transazioni fraudolente.
+In particolare la troncatura del PAN può essere fatta mantenendo le prime sei cifre oppure le ultime quattro; al contrario il mantenimento dell'intero PAN deve essere ben documentato e motivato.
+
+Nel caso di PayPal non vi è alcun riferimento alla carta di credito usata.
+In entrambi i casi la buona riuscita o meno del pagamento sarà riportata da \verb|settled_at| o \verb|error_msg|, che sono mutualmente esclusivi.
+
+Infine si tiene a precisare che non tutti i requisiti funzionali sono stati qui discussi, perché molti sono immediati dato il diagramma ER\@.
+Inoltre si è deciso di introdurre nel diagramma requisiti funzionali non espressi (vedi per esempio entità \texttt{\textenglish{newsletter}}), che però non facendo parte dello sviluppo concordato non sono stati realizzati.
+Tale scelta è stata fatta per eventuali espansioni della piattaforma durante la fase di manutenzione.
+
+\subsection{Schema logico e fisico}
+\label{subsec:schema-logico-fisico}
+
+Terminato il diagramma ER non si è ancora in grado di realizzare ``fisicamente'' il \textenglish{database}, prima è necessaria una ristrutturazione del diagramma.
+Tale operazione è utile per ridurre il livello di astrazione, infatti vi sono costrutti che non possono essere direttamente rappresentati da un \textenglish{database} relazione, n'è un esempio la generalizzazione.
+
+Il diagramma ristrutturato è stato realizzato con l'uso di \prog{\mbox{MySQL} Workbench}, prende il nome di diagramma ER esteso (EERD) ed è mostrato in \Cref{fig:eer}.
+Seppur la ristrutturazione poteva mantenere la stessa sintassi usata nel diagramma ER, lo strumento utilizzato propone come linguaggio di modellazione dei dati IDEF1X\@.
+Inoltre permette una facile generazione del codice per la definizione della base di dati, motivo per cui nel seguito, durante le osservazioni sul diagramma, se ce ne sarà la necessità, si tratteranno anche alcuni aspetti dello schema fisico.
+
+Ad un primo sguardo del diagramma ristrutturato salta all'occhio che non sono state scelte come chiavi primarie tutti gli identificatori usati nell'ERD, in alcuni casi si sono preferite chiavi surrogate di tipo intero.
+Per cui si è deciso di non utilizzare, come chiavi primarie, identificatori stringa o esterni, ma comunque mantenendo i vincoli di \texttt{\textenglish{NOT NULL}} e \texttt{\textenglish{UNIQUE}}.
+
+Riprendendo le associazioni ricorsive si nota che sono state modellate attraverso una chiusura transitiva, come mostrato dalle tabelle \texttt{\textenglish{category}}, \verb|product_has_update| e \linebreak\verb|product_has_part|.
+Una chiusura transitiva permette di decomporre una gerarchia, come quella delle categorie e sottocategoria.
+Nel caso specifico delle categorie si è associata ad ogni sottocategoria un genitore (vedi \verb|parent_id|), che assume il valore \texttt{NULL} qualora la sottocategoria sia una categoria.
+Una chiusura transitiva può essere anche realizzata con una tabella esterna, utile per modellare le associazione \texttt{N:M}.
+Pur essendo piuttosto naturali, le chiusure transitive non possono essere attraversate facilmente dal linguaggio SQL/92, che manca di costrutti appropriati ed è quindi non completo.
+Tuttavia tale problema non si pone perché, si è fatto uso di un linguaggio di programmazione universale come Java.
+
+Abbiamo già descritto l'entità \verb|product_image|, dicendo che l'\texttt{url} contiene l'indirizzo dell'immagine raffigurante la configurazione del prodotto scelta dal cliente.
+Dal diagramma ristrutturato notiamo che la colonna omonima è una stringa di al massimo 2083 caratteri, tale limite è stato scelto basandosi sulla lunghezza gestibile da un vecchio \textenglish{browser} come \prog{Internet Explorer 10}.
+In realtà gli RFC non specificano nessun limite particolare, ma è buona norma rimanere sotto i 2000 caratteri.
+
+Tutti gli attributi decimali sono stati modellati con il tipo \verb|DECIMAL(15,4)|, il quale indica che la parte intera è lunga 15 cifre, mentre quella decimale 4.
+
+Si consideri il \ref{itm:privileges}, per modellarlo si è utilizzato l'attributo \verb|is_valid| dell'entità \texttt{\textenglish{login}}, che può assumere i valori \texttt{\textenglish{true}} o \texttt{\textenglish{false}}.
+Un cliente che non ha confermato la propria \textenglish{e-mail}, come richiesto dal \ref{itm:sign-up}, avrà \verb|is_valid = false|.
+Gli utenti in questa condizione possono essere rimossi da un apposito evento, visto che non avendo completato il profilo non hanno potuto fare alcun acquisto (vedi \ref{itm:profile}), per tanto è indifferente la loro permanenza sulla base di dati.
+Si ricorda che un evento è una procedura o funzione memorizzata sullo schema di un \textenglish{database}, che può essere eseguito periodicamente e automaticamente.
+Si tiene a precisare che l'eliminazione di un cliente consiste nel slegare le tabelle \texttt{\textenglish{customer}} e \texttt{\textenglish{login}}, ponendo \verb|login_id = NULL| quando un \textenglish{record} della tabella \texttt{\textenglish{login}} viene rimosso, ovvero il vincolo di chiave esterna sull'eliminazione è \texttt{SET NULL}.
+Così facendo l'utente non potrà più accedere ai suoi dati, ma l'azienda proprietaria della piattaforma potrà esaminare lo \textbf{storico} delle vendite, compresi gli indirizzi apposti alle bolle di spedizione.
+
+Se si osserva attentamente il diagramma ristrutturato si noterà la presenza della tabella \verb|user_role|, ma tale nome non compare all'interno del diagramma ER, perché questa tabella è necessaria al funzionamento di \mbox{Tomcat}.
+Tuttavia permette di distinguere se un cliente loggato è un'azienda oppure un privato, nel diagramma ER questa distinzione è fatta sulla base della generalizzazione (completa ed esclusiva).
+
+Un altro aspetto importante è la codifica usata dallo schema della base di dati, ovvero \verb|utf8mb4_0900_as_cs|, il quale è basato sulla codifica Unicode 9.0 e gestisce sia gli accenti (\textit{\textenglish{accent sensitive}}) sia la differenza tra maiuscole e minuscole (\textit{\textenglish{case sensitive}}).
+Tale codifica è utile nel caso in cui la piattaforma voglia affermarsi anche in un mercato internazionale.
+
+In conclusione si ricorda che sullo schema della base di dati si sono definiti due utenti con privilegi differenti per manipolare i dati.
+\begin{sidewaysfigure}[p]
+	\centering
+	\includegraphics[width=\linewidth]{eer.eps}
+	\caption{Schema EER del progetto.}
+	\label{fig:eer}
+\end{sidewaysfigure}
\ No newline at end of file

relazione/src/contents/lavoro-svolto/contents/presentation-layer.tex

+% !TeX encoding = UTF-8
+% !TeX root = ../../../FERRON_relazione.tex
+
+\section{Presentation layer}
+\label{sec:presentation-layer}
+
+Siamo ormai giunti al livello che impaginerà i dati richiesti e attraverso cui l'utente potrà effettuare le operazioni finora descritte.
+Vista la natura grafica del livello, non è opportuno presentare i componenti grafici che si sono usati.
+Per tale ragione ci limiteremo agli aspetti più significativi.
+
+\subsection{Infinite Scrolling}
+\label{subsec:infinite-scrolling}
+
+Cosa accadrebbe se si richiedesse di visionare la pagina di un prodotto, che contiene un numero elevato di recensioni?
+Per quanto finora detto, il \textenglish{client} visualizzerà tutte le recensioni.
+Tuttavia tale approccio rischierebbe di portare l'utente alla sindrome di \textenglish{Hourglass}, ovvero vi sarebbe una lunga fase di caricamento prima che la pagina diventi navigabile.
+Il comportamento ideale sarebbe che all'inizio si visualizzino solo una parte delle recensioni e qualora l'utente ne voglia leggere altre lo richiede esplicitamente.
+Per questo motivo è stata introdotta la tecnica di \textenglish{infinite scrolling}.
+
+Più precisamente, alla prima richiesta della pagina del prodotto, il lato \textenglish{server} recupera le prime 5 recensioni più recenti.
+Qualora si vogliano maggiori recensioni è sufficiente \textbf{cliccare} il pulsante apposito, il quale ne recupera altre 5, se presenti, e le aggiunge, secondo l'ordinamento richiesto, a quelle già impaginate.
+Si noti che il \textenglish{server} non recupera tutte le recensioni con la prima richiesta e poi le pagina di 5 in 5, perché un tale approccio porterebbe un elevato consumo di spazio e un rallentamento nel primo recupero.
+La scelta di quante recensioni recuperare è una preferenza a discapito dell'amministratore.
+
+\subsection{L'input di un'e-mail}
+\label{subsec:l'input-di-e-mail}
+
+Un campo input per un'email si può semplicemente realizzare in HTML con \linebreak\verb|<input type="email">|, tuttavia questo approccio presenta un difetto.
+Se si va ad esaminare la \textenglish{regular expression} utilizzata da tale campo, ci si accorge che ammette valori \textbf{non accettabili} per una piattaforma di pubblico dominio, come quella qui descritta, infatti è possibile indicare come dominio dell'\textenglish{e-mail} \texttt{localhost}.
+Si è allora definita una nuova regola di validazione, con una \textenglish{regular expression} più stringente da applicare al \textenglish{tag} \texttt{input}.
+È stato possibile definire tale regola, perché tutte le validazioni lato \textenglish{client} sono state eseguite da un \textenglish{plugin} di \mbox{jQuery}~\cite{jquery}, chiamato \mbox{jQuery} \textenglish{Validation}~\cite{jqueryvalidation}.
+Nonostante questa accortezza, si è comunque effettuato il controllo lato \textenglish{server}, perché il lato \textenglish{client} può essere sempre aggirato.
+Anche in questa occasione, non c'è alcuno spreco di risorse, infatti l'utente sarà immediatamente informato che l'\textenglish{e-mail} inserita non è valida, senza dover attendere la risposta del lato \textenglish{server}.
+
+Si coglie l'occasione per far notare al lettore come sono state modellate le colonne \texttt{\textenglish{e-mail}} all'interno delle tabelle \texttt{\textenglish{login}} e \texttt{\textenglish{notification}} nella \Cref{fig:eer}, ovvero con \texttt{VARCHAR(254)}.
+Il numero scelto deriva dal fatto che il \texttt{\textenglish{Path}}, all'interno dell'\textenglish{header} di un'\textenglish{e-mail}, non può essere più lungo di 256 caratteri, come riportato da \cite{Klensin2008} e dall'\textit{errata-corrige} di \cite{Klensin2004}.
+Tale lunghezza considera, oltre alla \textenglish{mailbox}, le parentesi angolari (\texttt{<},\texttt{>}) presenti nel \texttt{\textenglish{Path}}, che ovviamente sono state sottratte.
+Un discorso analogo vale anche per la PEC presente nella tabella \texttt{business} della stessa figura.
+
+\subsection{\mbox{XRegExp}}
+\label{subsec:xregexp}
+
+Anche la validazione dei nomi e/o cognomi viene effettuata a livello \textenglish{client}, prima di essere inviata al \textenglish{server}.
+In generale tali validazioni devono assicurarsi che non vi siano né caratteri speciali né numeri, ma solo caratteri alfabetici, senza distinzione tra quelli cirillici e gli ideogrammi.
+Nelle \textenglish{regular expression} di POSIX per indicare questo gruppo di caratteri viene utilizzata la classe \verb|[:alpha:]|, che non è ancora supportata nativamente dagli interpreti di JavaScript, per questo motivo la definizione della regola in \mbox{jQuery} \textenglish{Validation} è stata fatta servendosi della libreria XRegExp~\cite{xregexp}.
\ No newline at end of file

relazione/src/contents/lavoro-svolto/lavoro-svolto.tex

@@ -4,6 +4,7 @@
 \chapter{Lavoro svolto}
 \label{ch:lavoro-svolto}
 \graphicspath{{contents/lavoro-svolto/assets/img/}}
+\inputpath{{contents/lavoro-svolto/}}
 
 Abbiamo finora visto i dettagli astratti alla base del lavoro, senza però illustrarne alcuna idea di soluzione; è pertanto giunto il momento di farlo.
 
@@ -11,14 +12,9 @@ Questo capitolo si aprirà con una panoramica dell'architettura scelta e prosegu
 In particolare si descriverà e commenterà da prima il livello riguardante il \textenglish{database}, successivamente si tratterà il ``cervello'' del progetto l'\textenglish{application server} e infine si darà spazio, anche se marginalmente, al livello di presentazione.
 
 Durante l'analisi si farà riferimento ad alcuni dei requisiti funzionali più interessanti esposti nel \Cref{ch:introduzione-al-lavoro}, al fine di mostrare al lettore quanta progettazione è richiesta dietro una banale descrizione in linguaggio naturale.
+Si farà inoltre riferimento ad alcuni aspetti tecnici degli strumenti utilizzati senza però entrare nel dettaglio, essi saranno ripresi nel \Cref{ch:strumenti-utilizzati}.
 
-\section{Architettura}
-\label{sec:architettura}
-
-
-\begin{sidewaysfigure}
+\input{contents/architecture.tex}
+\input{contents/data-layer.tex}
+\input{contents/business-layer.tex}
+\input{contents/presentation-layer.tex}
\ No newline at end of file
-	\centering
-	\includegraphics[width=1\linewidth]{eer.pdf}
-	\caption{Schema EER del progetto}
-	\label{fig:eer}
-\end{sidewaysfigure}
\ No newline at end of file