Utilizzo di \cref in tutto il documento

chapters/1 - Introduzione.tex

@@ -24,7 +24,7 @@ \subsection{DevOps}
 	\label{fig:devops-process}
 \end{figure}
 
-Il modello illustrato nella figura \ref{fig:devops-process} rappresenta il ciclo di vita del software secondo la filosofia DevOps. La disposizione delle fasi, configurata in modo da evocare il simbolo dell'infinito, simboleggia il concetto di continuità fondamentale per questa filosofia. Questo concetto è introdotto all'interno del flusso mediante un altro pilastro: l'\textit{automazione}. Grazie all'automazione, gli sviluppatori possono delegare compiti complessi o ripetitivi a sistemi esterni configurando tre componenti chiave: un evento, un'azione e il risultato atteso. Quando si verifica un evento specifico, un'entità esterna esegue un insieme di azioni predeterminate, il cui successo o fallimento viene determinato dal confronto con il risultato atteso. A livello pratico, ciò è ottenuto mediante l'utilizzo di server o più generalmente infrastrutture cloud complesse.
+Il modello illustrato nella \cref{fig:devops-process} rappresenta il ciclo di vita del software secondo la filosofia DevOps. La disposizione delle fasi, configurata in modo da evocare il simbolo dell'infinito, simboleggia il concetto di continuità fondamentale per questa filosofia. Questo concetto è introdotto all'interno del flusso mediante un altro pilastro: l'\textit{automazione}. Grazie all'automazione, gli sviluppatori possono delegare compiti complessi o ripetitivi a sistemi esterni configurando tre componenti chiave: un evento, un'azione e il risultato atteso. Quando si verifica un evento specifico, un'entità esterna esegue un insieme di azioni predeterminate, il cui successo o fallimento viene determinato dal confronto con il risultato atteso. A livello pratico, ciò è ottenuto mediante l'utilizzo di server o più generalmente infrastrutture cloud complesse.
 
 L'automazione dunque garantisce l'esecuzione dei processi in modo consistente e permette di concentrare le risorse del team sullo sviluppo, eliminando quindi l'intervento umano da compiti ripetitivi e passibili di errori. Una delle pratiche più diffuse, concetto rilevante della filosofia DevOps, è la costruzione di una pipeline di \ac{cicd}.
 
@@ -85,4 +85,4 @@ \subsection{Obiettivi}
 	\caption{Diagramma dei casi d'uso dallo sviluppatore all'utente}
 	\label{fig:use-case-diagram}
 \end{figure}
-Nella \Cref{fig:use-case-diagram} sono rappresentati gli scenari di utilizzo da parte degli utenti finali e degli sviluppatori. In particolare, lo sviluppatore introduce nuovo codice all'interno del repository del progetto e successivamente l'esecuzione della pipeline determina se è necessario il rilascio di una nuova versione. In caso di esito positivo, i pacchetti di installazione sono generati. Questi, una volta distribuiti, consentiranno agli utenti di introdurre il software nel proprio sistema.
+Nella \cref{fig:use-case-diagram} sono rappresentati gli scenari di utilizzo da parte degli utenti finali e degli sviluppatori. In particolare, lo sviluppatore introduce nuovo codice all'interno del repository del progetto e successivamente l'esecuzione della pipeline determina se è necessario il rilascio di una nuova versione. In caso di esito positivo, i pacchetti di installazione sono generati. Questi, una volta distribuiti, consentiranno agli utenti di introdurre il software nel proprio sistema.

chapters/2 - Scenario.tex

@@ -13,7 +13,7 @@ \subsection{Alchemist}
 
 \imagesource{figures/alchemist-metamodel.pdf}{https://alchemistsimulator.github.io/explanation/metamodel/}{Il meta-modello di Alchemist}{.9}{alchemist-metamodel}
 
-Il software si presenta come un simulatore, perciò per comprendere il suo utilizzo è necessario introdurre il concetto di simulazione in ambito scientifico. Per simulazione si intende un modello della realtà, costruito secondo le regole di un analista, sviluppato per consentire la valutazione dello svolgersi di una serie di eventi in un ambiente definito. Mediante la definizione delle entità e le regole che coinvolgono il modello studiato, l'analista attraverso Alchemist crea e osserva simulazioni atte a modellare interazioni tra agenti autonomi in ambienti dinamici: ossia scenari di \textit{aggregate} e \textit{nature-inspired computing}. Il meta-modello di Alchemist descrive gli elementi e le relazioni con cui l'utente finale è capace di costruire simulazioni di scenari complessi; come si può notare dalla \Cref{fig:alchemist-metamodel}, le entità in gioco sono ispirate ai fondamenti della chimica. 
+Il software si presenta come un simulatore, perciò per comprendere il suo utilizzo è necessario introdurre il concetto di simulazione in ambito scientifico. Per simulazione si intende un modello della realtà, costruito secondo le regole di un analista, sviluppato per consentire la valutazione dello svolgersi di una serie di eventi in un ambiente definito. Mediante la definizione delle entità e le regole che coinvolgono il modello studiato, l'analista attraverso Alchemist crea e osserva simulazioni atte a modellare interazioni tra agenti autonomi in ambienti dinamici: ossia scenari di \textit{aggregate} e \textit{nature-inspired computing}. Il meta-modello di Alchemist descrive gli elementi e le relazioni con cui l'utente finale è capace di costruire simulazioni di scenari complessi; come si può notare dalla \cref{fig:alchemist-metamodel}, le entità in gioco sono ispirate ai fondamenti della chimica. 
 
 \paragraph{Architettura} Un aspetto importante per lo svolgimento del progetto è l'architettura del software in oggetto, la quale deve soddisfare i requisiti posti inizialmente. In questo contesto il framework propone una struttura consona, in quanto è realizzato mediante linguaggi JVM-based, più precisamente Java e Kotlin, e utilizza un'architettura modulare ed estendibile, sinonimo di robustezza. 
 

chapters/4 - Design.tex

@@ -19,7 +19,7 @@ \section{Architettura e macrostruttura}
 	\label{fig:activity-interaction-diagram}
 \end{figure}
 
-Nello schema in \Cref{fig:activity-interaction-diagram} si fa riferimento ad un generico evento come segnale di avvio della pipeline. Nell'ambito \ac{cicd} l'evento corrisponde spesso alla pubblicazione di nuovo codice nel repository, in modo da generare un processo di integrazione continua del software.
+Nello schema in \cref{fig:activity-interaction-diagram} si fa riferimento ad un generico evento come segnale di avvio della pipeline. Nell'ambito \ac{cicd} l'evento corrisponde spesso alla pubblicazione di nuovo codice nel repository, in modo da generare un processo di integrazione continua del software.
 
 \section{Configurazione del build system}
 
@@ -33,7 +33,7 @@ \section{Configurazione del build system}
 \subsection{Lo strumento jpackage}\label{sec:design-jpackage}
 Lo strumento \ac{cli} \textit{jpackage} offre un'interfaccia munita di diverse opzioni per configurare e personalizzare a piacimento i pacchetti in output. Esistono parametri generici, compatibili con tutte le piattaforme, e parametri specifici che vanno a modificare attributi particolari alla tipologia di pacchetto in output scelta. Uno dei motivi che ha portato alla scelta di \textit{jpackage} rispetto ad altri software è la capacità di includere autonomamente una \textit{runtime-image} di Java, ossia una \ac{jre} ridotta di dimensioni all'interno del pacchetto. La combinazione di una \textit{runtime-image} e degli archivi Java (JAR) necessari all'esecuzione dell'applicazione costituiscono l'\textit{application-image}: un pacchetto self-contained che include l'applicazione, assieme una \ac{jvm} e alle librerie necessarie per eseguire quell'applicazione sulla piattaforma di destinazione.
 
-\paragraph{Application image} Alchemist è un progetto modulare e ogni modulo è distribuito in un archivio JAR specifico. Come descritto nella documentazione\footnote{https://alchemistsimulator.github.io/howtos/preparation/jar/index.html} il software predispone due modalità di utilizzo stand-alone attraverso l'esecuzione degli archivi Java. La prima modalità consiste nell'inclusione dei singoli moduli richiesti come \textit{classpath} del processo di esecuzione. La seconda modalità sfrutta l'archivio denominato ``full", ossia un \textit{fat-jar} contenente tutti i moduli e tutte le dipendenze necessarie all'esecuzione del software in tutte le sue parti. In ottica di ridurre le dimensioni del pacchetto e velocizzare il processo di impacchettamento, jpackage costruirà l'\textit{application-image} utilizzando quest'ultimo. Il risultato di un'installazione corretta è differente a seconda della piattaforma di destinazione del pacchetto, nella figura \ref{fig:application-image-folder-structure} è raffigurata l'organizzazione dei file del software installato in un sistema Linux.  
+\paragraph{Application image} Alchemist è un progetto modulare e ogni modulo è distribuito in un archivio JAR specifico. Come descritto nella documentazione\footnote{https://alchemistsimulator.github.io/howtos/preparation/jar/index.html} il software predispone due modalità di utilizzo stand-alone attraverso l'esecuzione degli archivi Java. La prima modalità consiste nell'inclusione dei singoli moduli richiesti come \textit{classpath} del processo di esecuzione. La seconda modalità sfrutta l'archivio denominato ``full", ossia un \textit{fat-jar} contenente tutti i moduli e tutte le dipendenze necessarie all'esecuzione del software in tutte le sue parti. In ottica di ridurre le dimensioni del pacchetto e velocizzare il processo di impacchettamento, jpackage costruirà l'\textit{application-image} utilizzando quest'ultimo. Il risultato di un'installazione corretta è differente a seconda della piattaforma di destinazione del pacchetto, nella \cref{fig:application-image-folder-structure} è raffigurata l'organizzazione dei file del software installato in un sistema Linux.  
 
 \begin{figure}
 	\centering
@@ -46,7 +46,7 @@ \subsection{Lo strumento jpackage}\label{sec:design-jpackage}
 
 Il programma jpackage, come illustrato nella sezione \ref{sec:packaging}, non è \textit{cross-platform}, ciò significa che la generazione dei pacchetti deve essere eseguita su una macchina ospitante il sistema operativo di destinazione dei pacchetti richiesti. Per quanto lo strumento cerchi di unificare i diversi ambienti, ogni tipologia di pacchetto specialmente se di piattaforme diverse presenta limiti e caratteristiche differenti. Per questa ragione il task deve prevedere l'utilizzo di parametri differenti a seconda del sistema operativo sottostante.
 
-\subsection{Design finale} Il design ultimo è raffigurato nella figura \ref{fig:gradle-jpackage-scheme}. 
+\subsection{Design finale} Il design ultimo è raffigurato nella \cref{fig:gradle-jpackage-scheme}. 
 
 \begin{figure}[htb]
 	\centering
@@ -71,7 +71,7 @@ \section{Pipeline}
 	\caption{Diagramma dell'attività illustrante il flusso attraverso i ruoli delineati}
 	\label{fig:workflow-roles-summary}
 \end{figure}
-L'interazione dei processi nella pipeline è raffigurato nella \Cref{fig:workflow-roles-summary}. L'\textbf{inizializza\-zio\-ne} trova spazio al primo posto e la sua esecuzione è strettamente necessaria per il proseguimento del flusso. L'\textbf{assemblaggio} e \textbf{build} sono eseguiti parallelamente mentre i \textbf{test} devono inevitabilmente dipendere dalla fase di assemblaggio per poter verificare l'output prodotto da quest'ultimo. Il \textbf{rilascio} infine, richiede che tutte le fasi descritte precedentemente siano eseguite con successo. I ruoli concernenti il lavoro descritto da questo elaborato sono: assemblaggio, test e rilascio.
+L'interazione dei processi nella pipeline è raffigurato nella \cref{fig:workflow-roles-summary}. L'\textbf{inizializza\-zio\-ne} trova spazio al primo posto e la sua esecuzione è strettamente necessaria per il proseguimento del flusso. L'\textbf{assemblaggio} e \textbf{build} sono eseguiti parallelamente mentre i \textbf{test} devono inevitabilmente dipendere dalla fase di assemblaggio per poter verificare l'output prodotto da quest'ultimo. Il \textbf{rilascio} infine, richiede che tutte le fasi descritte precedentemente siano eseguite con successo. I ruoli concernenti il lavoro descritto da questo elaborato sono: assemblaggio, test e rilascio.
 
 \subsection{Interazione con il Build System}
 
@@ -85,7 +85,7 @@ \subsection{Interazione con il Build System}
 	\label{fig:activity-diagram-job}
 \end{figure}
 
-Come raffigurato nella figura \ref{fig:pipeline-activity-diagram}, la pipeline ottenuta inserisce nuovi job adibiti all'assemblaggio e al test dei processi. L'assemblaggio coinvolge tre unità di esecuzione operanti in runner differenti, adibiti alla pacchettizzazione del software nelle tipologie supportate. I job di test racchiudono all'interno le verifiche di validità dei pacchetti generati precedentemente e simula ove possibile la distribuzione del software.
+Come raffigurato nella \cref{fig:pipeline-activity-diagram}, la pipeline ottenuta inserisce nuovi job adibiti all'assemblaggio e al test dei processi. L'assemblaggio coinvolge tre unità di esecuzione operanti in runner differenti, adibiti alla pacchettizzazione del software nelle tipologie supportate. I job di test racchiudono all'interno le verifiche di validità dei pacchetti generati precedentemente e simula ove possibile la distribuzione del software.
 \begin{figure}[htb]
 	\centering
 	\includegraphics[width=1\linewidth]{figures/pipeline-result.pdf}