Fix generale

bibliography.bib

@@ -75,3 +75,10 @@ @article{Pianini_2013
 	month=aug, 
 	pages={202–215} 
 }
+
+@misc{Destri_2016,
+	 url={http://www.giuliodestri.it/documenti/D06_StoriaSviluppoSoftware.pdf},
+	 title={I processi di sviluppo software: La Storia},
+	 author={Destri, Giulio},
+	 year={2016}
+} 

chapters/1 - Introduzione.tex

@@ -7,7 +7,7 @@ \section{Contesto}
 Con l'avvento di internet il concetto di software come un entità sviluppata e finita ha completamente cessato di esistere. Mediante la rete è diventato semplice ed efficiente distribuire un programma e fornire un ulteriore supporto attraverso aggiornamenti evolutivi e correttivi. Il fenomeno è cresciuto tanto da aver dato luce alla pratica del rilascio di applicazioni deliberatamente non complete, le quali attraverso il feedback degli utenti evolvono verso un prodotto finito. Il manifesto agile ha introdotto la cultura di emettere frequenti rilasci di nuove versioni del software, rendendo la distribuzione un punto cardine all'interno del ciclo di vita di esso. Dietro lo sviluppo rapido di nuove funzionalità è necessario il rilascio di queste altrettanto velocemente, la filosofia DevOps nasce per soddisfare questa esigenza.
 
 \subsection{DevOps}
-La metodologia DevOps (termine nato dalla contrazione di ``Development" ed ``Operations") si è formata intorno al 2008 con l'idea chiave di unire il team di sviluppo ed il team operativo. Il principale catalizzatore di questo concetto è stata la necessità di affrontare inefficienze nelle fasi del ciclo di vita del software. Differentemente dalla metodologia agile, DevOps è un movimento culturale che esprime attraverso tre pilastri il suo obiettivo:
+La metodologia DevOps (termine nato dalla contrazione di ``Development" ed ``Operations") si è formata intorno al 2008 con l'idea chiave di unire il team di sviluppo ed il team operativo. Il principale catalizzatore di questo concetto è stata la necessità di affrontare inefficienze nelle fasi del ciclo di vita del software. Differentemente dalla metodologia agile, DevOps è una filosofia di sviluppo software che esprime attraverso tre pilastri il suo obiettivo:
 
 \begin{itemize}
 	\item il \textbf{flusso}, il miglioramento del flusso di lavoro lungo l'intero processo di produzione, ciò significa ottimizzare il processo dall'idea, fino alla generazione di valore con il software in produzione.
@@ -22,7 +22,6 @@ \subsection{DevOps}
 	\includegraphics[width=.8\linewidth]{figures/devops-process.png}
 	\caption{Le fasi della metodologia DevOps}
 	\label{fig:devops-process}
-	%https://italiancoders.it/introduzione-al-devops/
 \end{figure}
 
 Il modello illustrato nella figura \ref{fig:devops-process} rappresenta la visione del ciclo di vita del software per la filosofia DevOps. La posizione delle fasi così configurata in modo da rappresentare il simbolo dell'infinito è utilizzata per simboleggiare il concetto di continuità che la metodologia utilizza. Essa è introdotta 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 pipeline di \ac{cicd}.
@@ -31,11 +30,6 @@ \subsection{DevOps}
 
 \paragraph{Continuous delivery} La distribuzione rappresenta l'insieme di operazioni finalizzate alla consegna del software agli utenti finali. Questo processo estende l'integrazione continua e si preoccupa di garantire la disponibilità costante di un artefatto di build pronto per il rilascio. L'effettivo rilascio di una nuova versione del software può avvenire in modo automatico oppure manualmente da parte dello sviluppatore. La filosofia DevOps fornisce linee guida e non regole rigide, lasciando al team di sviluppo il compito di progettare ed integrare un flusso adeguato alle necessità del progetto.
 
-% \subsection{Installazione del software}
-% La forma, cos'è un pacchetto software instllante, autocontenuto, aggiornamento del software, i package manager ed il loro    ruolo
-% L'importanza del come si distribuisce il software
-% Quanto capillarmente
-
 \subsection{Un software complesso: Alchemist}\label{sec:alchemist}
 Alchemist\cite{Pianini_2013} è un framework di simulazione open-source sviluppato dall'Università di Bologna, progettato per modellare elementi di programmazione pervasiva. Per comprendere l'ambito del progetto è 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. Lo svolgimento di una simulazione avviene all'interno di un arco di tempo discreto suddiviso in unità di tempo predefinite definite come \textit{step}. Alchemist, consente di creare, osservare ed analizzare simulazioni atte a modellare interazioni tra agenti autonomi in ambienti dinamici: ossia scenari di \textit{aggregate} e \textit{nature-inspired computing}. Una rappresentazione del meta-modello, ossia le entità e relazioni configurabili, è raffigurata nella \cref{fig:alchemist-metamodel}.
 

chapters/2 - Analisi.tex

@@ -15,7 +15,7 @@ \section{Requisiti}
 
 Le funzionalità richieste si possono classificare in due gruppi distinti: il primo contiene tutto ciò che concerne l'esperienza dell'utente finale, mentre il secondo descrive le funzionalità dal punto di vista degli sviluppatori e contributori di Alchemist. Di seguito il primo gruppo.
 \begin{itemize}
-	\item \textbf{Pacchettizzazione}: il simulatore deve essere distribuito in pacchetti auto-contenuti, ossia comprendenti di tutto il necessario per l'utilizzo di esso.
+	\item \textbf{Pacchettizzazione}: il simulatore deve essere distribuito in pacchetti \textit{self-contained}, ossia contenenti l'intera applicazione, e più specificatamente nell'ambito \ac{jvm}, integranti un \ac{jre} adibito all'esecuzione.
 	\item \textbf{Multi-piattaforma}: Alchemist deve essere installabile sui maggiori sistemi operativi in circolazione come Windows, MacOS e le principali distribuzioni Linux.
 	\item \textbf{Plug and play}: l'installazione non deve richiedere configurazioni complesse, l'applicativo deve essere pronto all'uso non appena installato.
 \end{itemize}
@@ -47,7 +47,7 @@ \section{Pacchettizzazione}\label{sec:packaging}
 
 \subsection{Soluzioni}
 
-Nell'ottica di semplificare la configurazione di questo processo lo strumento selezionato deve supportare le tre principali piattaforme descritte nei requisiti precedentemente. Tra gli strumenti analizzati due molto differenti si sono distinti, vale a dire: \textit{jpackage}, comando disponibile nel \ac{jdk} dalla versione 14, adibito alla produzione di pacchetti auto-contenuti con \ac{jre} integrata e \textit{GraalVM}, un \ac{jdk} sviluppato da Oracle che fornisce un compilatore \ac{jit} e \ac{aot} per java. 
+Nell'ottica di semplificare la configurazione di questo processo lo strumento selezionato deve supportare le tre principali piattaforme descritte nei requisiti precedentemente. Tra gli strumenti analizzati due molto differenti si sono distinti, vale a dire: \textit{jpackage}, comando disponibile nel \ac{jdk} dalla versione 14, adibito alla produzione di pacchetti self-contained con \ac{jre} integrata e \textit{GraalVM}, un \ac{jdk} sviluppato da Oracle che fornisce un compilatore \ac{jit} e \ac{aot} per java. 
 
 Il termine \ac{jit} descrive il comportamento normale di ogni \ac{jvm}: il \textit{java compiler} traduce il programma ad alto livello in \textit{bytecode} ed in seguito la \ac{jvm} trasforma il bytecode in linguaggio macchina per l'architettura specifica dinamicamente. In contrasto la tecnica \ac{aot} ricorda i linguaggi di programmazione compilati, ovvero la compilazione è statica ed avviene prima dell'esecuzione del programma. Il compilatore \ac{aot} chiamato ``Native Image", consente di compilare un programma java (ed altri linguaggi di programmazione) ottenendo in output un eseguibile nativo per ogni piattaforma. Quest'ultimo inoltre porta con sè diversi vantaggi come: un minor costo in risorse CPU e memoria, tempi di avvio minori e dimensioni ridotte rispetto un normale programma java distribuito con un \ac{jre}. La compilazione \ac{aot} però ha dei requisiti, uno di questi fondamentale è la \textit{closed world assumption}: ossia ogni parte di codice raggiungibile in esecuzione lo deve essere anche in fase di build. Ciò accade perché native image svolge un analisi statica del codice, alcune funzionalità come la reflection oppure il caricamento dinamico non sono supportate e richiedono una soluzione alternativa.
 
@@ -125,7 +125,7 @@ \subsection{Package manager}
 
 \paragraph{Windows e winget} Discorso differente vale per Windows, ove fino a poco tempo fa non era previsto alcun package manager ufficiale pre-installato. Gli utenti usualmente installano software attraverso pacchetti distribuiti in siti web ad-hoc, store non ufficiali o attraverso il Microsoft Store, gli sviluppatori invece, per sfruttare tutti i benefici della gestione a pacchetti utilizzano package-management system di terze parti. Solamente nel settembre 2020 è nato ``winget": package-management system open-source sviluppato da Microsoft, il quale supporta pacchetti di installazione EXE, MSIX e MSI. Il repository dei pacchetti è accessibile pubblicamente ed è possibile mediante richieste di contribuzione e previa approvazione, pubblicare pacchetti all'interno di esso.
 
-\paragraph{Pacchetti containerizzati} Un'altra tipologia sono i pacchetti detti containerizzati, ovvero eseguiti all'interno di ambienti separati con un accesso limitato al sistema. Questa caratteristica fornisce due principali vantaggi: la possibilità per una applicazione di usare la propria versione desiderata di librerie di sistema senza creare conflitti e la trasparenza all'utente nell'accesso alle risorse di sistema, garantendo un livello aggiuntivo di sicurezza. È il caso dei pacchetti \textit{snap}, pacchetti auto-contenuti considerati universali perché compatibili con una notevole quantità di distribuzioni Linux. Quest'ultimi sono disponibili ed installabili all'interno dello ``SnapStore", l'unico repository compatibile ed ufficiale.
+\paragraph{Pacchetti containerizzati} Un'altra tipologia sono i pacchetti detti containerizzati, ovvero eseguiti all'interno di ambienti separati con un accesso limitato al sistema. Questa caratteristica fornisce due principali vantaggi: la possibilità per una applicazione di usare la propria versione desiderata di librerie di sistema senza creare conflitti e la trasparenza all'utente nell'accesso alle risorse di sistema, garantendo un livello aggiuntivo di sicurezza. È il caso dei pacchetti \textit{snap}, pacchetti self-contained considerati universali perché compatibili con una notevole quantità di distribuzioni Linux. Quest'ultimi sono disponibili ed installabili all'interno dello ``SnapStore", l'unico repository compatibile ed ufficiale.
 
 \paragraph{Analisi rispetto ai requisiti}
 Nell'ottica di soddisfare il requisito multi-piat\-ta\-for\-ma del progetto è necessario analizzare le piattaforme di destinazione elencate. Data la natura closed-source di Windows e MacOs, i due sistemi operativi non richiedono particolari attenzioni dato che le tipologie di pacchetti generabili da jpackage sono sufficienti ed ufficialmente supportate. Linux al contrario è notevolmente frammentato, ogni distribuzione è libera di utilizzare il package management system preferito o di inventare una tipologia di pacchetto completamente nuova. Purtroppo non esistono statistiche ufficiali riguardo la diffusione delle distribuzioni, molte di esse si basano su stime o utilizzano dati non attendibili. Dall'altro lato analizzando i pacchetti generabili da jpackage possiamo trarre delle conclusioni.

chapters/3 - Design.tex

@@ -21,7 +21,7 @@ \section{Architettura e macrostruttura}
 
 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{Build system}
+\section{Configurazione del build system}
 
 Il ruolo principale del \textit{build system} è quello di esporre un \textit{task} adibito alla generazione dei pacchetti. Il task dovrà soddisfare i seguenti requisiti:
 \begin{itemize}
@@ -31,7 +31,7 @@ \section{Build system}
 \end{itemize}
 
 \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 autocontenuto che include l'applicazione, assieme una \ac{jvm} ed alle librerie necessarie per eseguire quell'applicazione sulla piattaforma di destinazione.
+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} ed alle librerie necessarie per eseguire quell'applicazione sulla piattaforma di destinazione.
 
 \paragraph{Application image} Alchemist è un progetto modulare ed 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. La posizione ed organizzazione dei file è differente a seconda della piattaforma di destinazione del pacchetto, il risultato dell'installazione in un ambiente Linux è descritto nella figura \ref{fig:application-image-folder-structure}.  
 
@@ -103,8 +103,7 @@ \subsection{Repository}
 Le funzioni sono eseguite nel seguente ordine: (i) prepare, eseguita appena dopo che è stato scaricato ed estratto il pacchetto indicato nella sorgente, (ii) pkgver, utilizzata per stabilire la versione del pacchetto se questa non è già stata impostata direttamente, (iii) build, i comandi necessari a compilare il software (se necessario), (iv) check, verifica che gli step precedenti siano stati eseguiti correttamente ed infine (v) package, l'installazione dei file nel filesystem. Nell'ambito di questo progetto solamente la funzione \textit{package} è necessaria in quanto il pacchetto sorgente contiene il software pronto per essere eseguito, la funzione dunque si occupa di posizionare i file nel sistema.
 Per non modificare direttamente il filesystem del computer installante, \texttt{makepkg} crea due directory \textit{pkg} e \textit{src}. All'interno di src, esso estrae il pacchetto e tutto il suo contenuto, mentre pkg consiste in un ambiente che simula il filesystem del sistema. In fase di installazione sarà il package manager a replicare la struttura della directory pkg nel filesystem del sistema installante.
 
-%%LOOK AT ME
-I pacchetti all'interno dell'\ac{aur} consistono in repository \textit{git} contenenti il PKGBUILD ed altri file di configurazione opzionali, il processo di pubblicazione dunque è simile a qualsiasi progetto con un sistema di version control: la creazione di un commit e la pubblicazione di esso.
+I pacchetti all'interno dell'\ac{aur} consistono in repository \textit{git} contenenti il PKGBUILD ed altri file di configurazione opzionali, il processo di pubblicazione dunque è simile a qualsiasi progetto con un sistema di version control attraverso quindi: la creazione di un commit e la pubblicazione di quest'ultimo.
 
 \paragraph{Winget}\label{chap:winget} Il package manager winget presenta una struttura simile, un pacchetto è formato da diversi file \textit{manifest} i quali descrivono i meta-dati del pacchetto nel linguaggio YAML. A differenza del PKGBUILD, non ci sono script e non esistono funzioni, l'intera configurazione è descrittiva e non presenta la possibilità di inserire comandi da eseguire pre o post installazione. I file manifest si distinguono in: manifesto della versione, contenente dettagli identificativi del pacchetto, il manifesto delle impostazioni locali, il quale descrive la configurazione per uno specifico locale, ed il manifesto dell'installer, contenente l'URL dove reperire il pacchetto installante ed altre informazioni specifiche. Per semplificare il processo di creazione e pubblicazione dei pacchetti, Microsoft prevede l'utilizzo di uno script ``wingetcreate" che guida l'utente nella scelta dei parametri. Questo inoltre si presta ad essere utilizzato all'interno di pipeline \ac{cicd} per aggiornare pacchetti già presenti.