Add related works

src/chapter_1.md

@@ -9,13 +9,21 @@ Tra questi sicuramente possiamo annoverare: riconoscimento di immagini, diagnosi
 
 La crescente produzione di software basato sul \acl{ML} ha generato un forte impulso anche per quanto riguarda la ricerca.
 L'attenzione non è stata puntata unicamente sullo studio di nuovi modelli e architetture, ma anche sul processo di sviluppo di questi prodotti per andare a valutare i vari problemi da un punto di vista ingegneristico.
-Il seguente lavoro si muove proprio in questo solco e ha lo scopo di studiare come le componenti di \ac{ML} sono distribuite sull'architettura dei sistemi, ma anche di capire se esistono delle differenze tra gli interventi di *issue fixing* doviti a problematiche di \acl{ML} e quelli generici.
+In letteratura non mancano studi atti ad evidenziare le differenze tra progetti di \ac{ML} e progetti classici.
+Ne tanto meno confronti dei progetti rispetto alle dipendenze e alle librerie utilizzate.
+
+Molti studi sono, invece, incentrati sulle problematiche legate allo sviluppo di applicazioni di \acl{ML}.
+In alcuni casi l'analisi è stata svolta per librerie specifiche, in altri casi il focus è stato puntato sulle discussioni di *StackOverflow*.
+In altri casi ancora l'attenzione è stata rivolta su problematiche specifiche come quella del \ac{SATD} [@liu2021exploratorystudyintroduction].
+
+Anche il seguente lavoro si concentra sui difetti riscontrati all'interno delle applicazioni di \acl{ML}.
+In questo caso però la ricerca di differenze è legata agli interventi di *issue fixing* relativi al \ac{ML} rispetto ad interventi di correzione generici.
 
 ## Obbiettivi della tesi {#sec:goals}
 
 Questo studio vuole verificare la presenza di differenze, all'interno di progetti di \acl{ML}, rispetto a come sono trattate le *issues* legate a tematiche di \ac{ML} e quelle generiche.
 In particolare si vuole capire come la risoluzione di queste problematiche va ad impattare sull'architettura, sia in termini di moduli modificati sia in termini di entropia generata.
-Si vuole anche scoprire se sono presenti delle fasi del processo di sviluppo che sono più critiche.
+Si vuole anche scoprire se sono presenti delle fasi del processo di sviluppo che sono più critiche di altre.
 Infine si vuole capire se le *issues* sono trattate tutte allo stesso modo per quanto riguarda il livello di discussione e il tempo necessario alla loro risoluzione.
 
 ## Struttura della tesi

src/chapter_2.md

@@ -1,32 +1,175 @@
 # Stato dell'arte {#sec:related-works}
 
-In questo lavoro[@gonzalez2020statemluniverse10] sono stati studiati mediante tecniche di statistica descrittiva $9325$ progetti.
-I progetti sono stati distinti tra sistemi di \ac{ML}, a loro volta suddivisi in framework ($700$ elementi) e applicazioni ($4524$ elementi), e sistemi generici ($4101$ elementi).
-Gli aspetti considerati per l'analisi sono vari, si va dalla distribuzione dei contributi, a loro volta divisi tra interni ed esterni, fino all'analisi dei linguaggi più utilizzati, passando per un'analisi sulla popolarità dei vari repositories.
-Inoltre vengono valutate anche le differenze per quanto riguarda le interazioni collaborative (discussioni, review, ecc.).
+## Confronto tra progetti di ML e progetti generici
 
-In altri lavori[@han2020empiricalstudydependency] il focus è stato puntato sulla gestione delle dipendenze dei progetti di \acl{ML}.
-In questo caso si va a valutare le eventuali differenze in base al framework utilizzato.
-Le librerie considerate nello studio sono: `TensorFlow`, `PyTorch` e `Theano`.
-Mentre eventuali differenze sono state ricercate rispetto agli obbiettivi del progetto (tutorial/libri, applicativi, ricerca), il dominio applicativo, la popolarità, la frequenza di aggiornamento delle dipendenze e i motivi degli aggiornamenti.
+Nello studio di Gonzalez *et al.* [@gonzalez2020statemluniverse10] ci vengono presentate le principali differenze tra i repository di \acl{ML} e i progetti classici.
+I dati per lo studio sono stati recuperati attraverso l'\ac{API} messa a disposizione di GitHub attraverso la quale è stato possible collezionare i dati associati a 9325 progetti open source così raggruppati:
 
-In altri casi[@grichi2020impactmultilanguagedevelopment] ancora l'attenzione è stata rivolta alla natura *multi-linguaggio* tipica delle soluzioni di \acl{ML} e all'impatto che ciò ha sul sistema.
-In questo caso sono stati considerati, tra progetti mono-linguaggio e multi-linguaggio, $27$ repository open source.
-Per quanto riguarda l'analisi sono stati presi in considerazione la percentuale di pull request accettate, il tempo necessario per accettare una pull request e la propensione nell'introdurre i *bug* all'interno delle pull request.
+- 5224 progetti legati all'\ac{AI} e al \ac{ML} divisi a loro volta in:
+  - 700 tools e framework
+  - 4524 applicazioni
+- 4101 progetti generici
 
-In letteratura sono presenti anche molti lavori che si concentrano sull'analisi delle problematiche e dei *bug* riscontrati all'interno di applicazioni di \acl{ML}.
-In alcuni casi lo studio[@zhang2018empiricalstudytensorflow] è stato svolto in maniera specifica per una singola libreria.
-Nello specifico sono state considerate $87$ domande postate su *StackOverflow* in relazione a bug di `TensorFlow` e $82$ commit, selezionati da $11$ progetti su *GitHub*.
-Lo studio aveva l'obiettivo di individuare i sintomi e le cause scatenati di questi difetti e individuare le sfide per l'individuazione e la localizzazione di questi.
+Gli aspetti considerati dallo studio sono molteplici e di varia natura.
+Una prima analisi è stata condotta rispetto alla nascita dei vari repositories.
+In questo modo è stato possibile individuare nel 2017 l'anno del *boom* dei repositori di \ac{AI} & \ac{ML}.
+Infatti questo è stato il primo anno in cui sono stati creati più progetti legati al \acl{ML} rispetto a quelli generici.
 
-In altri casi[@humbatova-2019-taxonomyrealfaults] l'attenzione non è stata rivolta ad una libreria specifica, ma si è cercato di definire una tassonomia delle problematiche che fosse però generale per tutti i framework e le applicazioni di \ac{ML}.
-Anche in questo caso i dati per lo studio sono stati recuperati sia da *GitHub* che da *StackOverflow*.
-Altre volte ancora l'analisi[@liu2021exploratorystudyintroduction] è stata mirata su alcuni aspetti specifici come l'introduzione e la rimozione di \ac{SATD} all'interno di progetti che fanno uso di \ac{DL}.
+Una seconda analisi ha permesso di capire come varia la partecipazione ai vari progetti.
+Per poter svolgere questa analisi i contributori sono stati divisi in:
 
-Noi lavori precedentemente discussi l'analisi è stata svolta su dati recuperati dalla storia dei repositories e in alcuni casi recuperando informazioni aggiuntive da piattaforme di discussione online.
-Altri lavori[@bangash2019whatdevelopersknow; @han2020whatprogrammersdiscuss; @alshangiti2019whydevelopingmachine] invece hanno analizzato unicamente le discussioni su *StackOverflow* per andare a capirne il contenuto.
+- esterni: i loro contributi sono limitati ad aprire *issues* e commentare le discussioni.
+- interni: oltre a svolgere i compiti precedentemente elencati devono anche aver chiuso delle issues o eseguito dei commit sul progetto.
+
+In base a questa divisione si è visto come il tools di \acl{ML} hanno un numero di contributori interni superiore rispetto ai progetti generici.
+Quest'ultimi pero hanno una maggiore partecipazione esterna.
+Se invece l'analisi viene svolta considerando unicamente gli autori dei commit si scopre che i progetti generici mediamente hanno più *contributors*, ma i top 4 repositories con più committer sono tutti legati al mondo del \ac{ML}.
+
+Un'ulteriore analisi è stata svolta anche per quanto riguarda il linguaggio con cui sono stati realizzati i vari progetti.
+Sia nel caso delle applicazioni che nei tools di \acl{ML} il linguaggio più popolare è Python, mentre la seconda posizione varia.
+Nel caso del tools questa è occupata da C++, mentre nelle applicazioni dai Notebook Jupyter.
+Nei progetti generici invece Python occupa solo la terza posizione in quanto popolarità e le prime due sono occupate da JavaScript e Java.
+
+## Analisi in base al framework utilizzato
+
+Nello studio di Han *et al.* [@han2020empiricalstudydependency] sono stati considerati 1150 progetti GitHub così distribuiti:
+
+- 708 progetti che dipendono da `TensorFlow`.
+- 339 progetti che dipendono da `PyTorch`.
+- 103 progetti che dipendono da `Theano`.
+
+Per poter classificare i progetti manualmente gli autori hanno considerato il nome del progetto, la descrizione, le label e il contenuto del readme.
+La classificazione è avvenuta sia rispetto all'obiettivo del progetto sia rispetto al dominio applicativo.
+Come obiettivi dei progetti sono stati considerati:
+
+- *Competitions*: progetti realizzati per la partecipazione a delle competizioni o sfide.
+- *Learning & Teaching*: progetti realizzati per libri e/o tutorial o per esercitarsi.
+- *Paper Experiments*: progetti realizzati al fine di ricerca.
+- *Software Development*: comprende librerie, plug-in, tools ecc.a
+- *Other*
+
+La classifica delle librerie più utilizzate è rimasta sostanzialmente invariata per tutte le categorie; il primo posto è occupato da `TensorFlow` seguito da `PyTorch` e `Theano`.
+L'unica eccezione riguarda i progetti realizzati a fini di ricerca.
+In questo caso `TensorFlow` e `PyTorch` sono in posizioni invertite.
+Anche per quanto riguarda la classificazione rispetto al dominio applicativo la situazione è costante.
+Infatti, indipendentemente dalla libreria utilizzata, il progetti più frequenti sono quelli che hanno a che fare con video e immagini e con il \ac{NLP}.
+
+Un'ulteriore \ac{RQ} è andata a valutare il tipo di dipendenza, facendo distinzione tra dipendenze dirette e indirette.
+Per tutte è tre le librerie si è visto che è molto più probabile avere una dipendenza diretta che indiretta.
+`PyTorch` è la libreria che più frequentemente è importata direttamente, mentre `Theano` ha una probabilità di essere importata direttamente quasi uguale a quella di essere importata indirettamente.
+
+Un ulteriore analisi è stata condotta per individuare quanto frequentemente i progetti aggiornano le loro dipendenze o eseguono dei downgrade.
+In questo caso si è visto che il progetti basati su `TensorFlow` e `PyTorch` aggiornano le proprie dipendenze molto più frequentemente rispetto ai progetti basati su `Theano`.
+Mentre il tasso di downgrade è sostanzialmente equivalente.
+Nel caso dei progetti che dipendono da `TensorFlow` la maggior parte dei downgrade viene spiegata dalla volontà di non utilizzare la nuova \ac{API} introdotta nella versione 2.0 della libreria.
+Sempre analizzando la versione della libreria utilizzata si è visto che i progetti basati su `Theano` sono quelli che utilizzano più frequentemente l'ultima versione disponibile della libreria.
+
+In un altro lavoro di Han *et al.* [@han2020whatprogrammersdiscuss] il focus si sposta sugli argomenti di discussione e su come questi variano in base al framework utilizzato.
+In questo caso all'interno dei dataset non sono rientrati unicamente i dati recuperati da GitHub, ma anche le discussioni su *StackOverflow*.
+
+Questo studio ha permesso di evidenziare differenze e similitudini per quanto riguarda le discussioni che si generano intorno ai tre framework di interesse.
+In particolare emerge che le fasi più discusse sono quelle di *model training* e di *preliminary preparation*.
+Mentre la fase meno discussa è quella di *model tuning*.
+Per quanto riguarda le differenze, dallo studio, emerge che `TensorFlow` e `PyTorch` hanno topic di discussione totalmente confrontabili.
+Oltre ai topic citati precedentemente, per questi framework, si discute molto anche della *data preparation*.
+Mentre la discussioni riguardanti `Theano` sono quasi esclusivamente concentrate sul *model training*.
+
+Da questi due studi è possibile evince sicuramente una forte somiglianza per quanto riguarda `TensorFlow` e `PyThorch`.
+La principale differenza viene riscontrata per quanto riguarda i campi di applicazione, con `TensorFlow` che viene generalmente preferito fatti salvi gli ambiti di ricerca.
+Mentre `Theano` presenta molte diversità sia per quanto riguarda gli impieghi che le discussioni.
+
+## Analisi dei progetti di ML multi-linguaggio
+
+Lo studio di Grichi *et al.* [@grichi2020impactmultilanguagedevelopment] si concentra sui sistemi *multi-linguaggio*.
+In questo caso si vuole capire se i sistemi di \ac{ML} sono più soggetti all'essere realizzati attraverso linguaggi diversi.
+Inoltre analizzando le pull request realizzate in più linguaggi si vuole capire se queste sono accettate con la stessa frequenza di quelle mono linguaggio e se la presenza di difetti è equivalente.
+
+L'analisi è stata svolta su 27 progetti open source hostati su GitHub.
+I progetti sono poi stati classificati in tre categorie:
+
+- Cat I: include 10 sistemi di \acl{ML} *multi-linguaggio*.
+- Cat II: include 10 sistemi generici *multi-linguaggio*.
+- Cat III: include 7 sistemi di \acl{ML} *mono-linguaggio*.
+
+Successivamente sono state scaricate le \acl{PR} di ogni progetto considerato.
+Le \ac{PR}s sono state categorizzate per individuare le quelle accettate e quelle rifiutate.
+Inoltre le \acl{PR} sono state categorizzate anche il base al numero di linguaggi utilizzati.
+In questo modo è stato possibile individuare le \ac{PR} *mono-linguaggio* e quelle *multi-linguaggio*.
+Infine per ogni \ac{PR} è stato individuato il tempo necessario alla sua accettazione o chiusura e i difetti introdotti dalla \acl{PR}.
+
+Per quanto riguarda la percentuale di linguaggi di programmazione utilizzati i progetti della categoria I e II sono comparabili.
+La principale differenza riguarda i tipi di linguaggi utilizzati.
+Nel caso dei progetti *multi-linguaggio* di \acl{ML} l'accoppiata più comune è Python e C/C++.
+Mentre nel caso dei progetti generici la coppia più comune è data da Java e C/C++.
+I progetti della categoria I e II sono paragonabili anche rispetto al numero di \ac{PR}s e \ac{PR}s *multi-linguaggio*.
+
+Lo studio ha evidenziato come all'interno dei progetti di \acl{ML} le \acl{PR} *mono-linguaggio* sono accettate molto più facilmente rispetto a quelle *multi-linguaggio*.
+Inoltre anche nel caso in cui queste vengano accettate, il tempo necessario alla loro accettazione è maggiore.
+Inoltre si è visto anche che rispetto alle \ac{PR}s *multi-linguaggio* non esistono differenze in base all'introduzione di *bug* tra i progetti della categoria I e II.
+Mentre le \acl{PR} che includono un singolo linguaggio sembrano essere più affette da *bug* nel caso dei sistemi di \acl{ML}.
+
+## Problematiche caratteristiche del ML
+
+In letteratura sono presenti anche lavori che si concentrano sull'analisi delle problematiche e dei *bug* riscontrati all'interno di applicazioni di \acl{ML}.
+Nello studio di Zhang *et al.* [@zhang2018empiricalstudytensorflow] l'attenzione è rivolta unicamente alle problematiche correlate a `TensorFlow`.
+Per lo studio sono stati recuperati dei *bug* di `TensorFlow` sia da progetti su GitHub (88 elementi) sia da quesiti su *StackOverflow* (87 elementi).
+
+Gli autori dello studio, per poter individuare la causa dei *bug* e i loro sintomi hanno dovuto analizzare manualmente gli elementi del dataset.
+Nel caso di *bug* discussi su *StackOverflow* le informazioni sono state recupera della discussione.
+Mentre nel caso dei *bug* recuperati da GitHub le informazioni sono state recuperate tramite lo studio dell'intervento di *fix* e il messaggio associato ad esso.
+
+In questo modo è stato possibile individuare quattro sintomi:
+
+- *Error*: durante l'esecuzione viene sollevato un errore riconducibile a `TensorFlow`.
+- *Low Effectiveness*: il programma presenta dei valori di *accuracy*, *loss* ecc. estremamente scadenti.
+- *Low Efficiency*: il programma viene eseguito troppo lentamente.
+
+Per quanto riguarda le cause è stato possibile individuarne sei:
+
+- *Incorrect Model Parameter or Structure*: il *bug* è riconducibile ad un cattivo utilizzo dei parametri del modello o alla sua struttura.
+- *Unaligned Tensor*: si verifica ogni qual volta la *shape* dell'input non corrisponde con quella attesa.
+- *Confusion with TensorFlow Computation Model*: in questo caso i *bug* si verificano quando gli utenti non sono pratici del modello computazionale utilizzato da `TensorFlow`.
+- *TensorFlow \ac{API} Change*: il *bug* dipende da un cambiamento nell'\ac{API} di `TensorFlow`.
+- *TensorFlow \ac{API} Misuse*: in questo caso il *bug* è riconducibile ad un utilizzo scorretto dell'\ac{API} di `TensorFlow`.
+- *Structure Inefficiency*: questa categoria può essere vista come una versione più *soft* della prima categoria.
+Infatti in questo caso il problema nella struttura non genera un errore ma solo delle inefficienze.
+
+Anche lo studio di Humbatova *et al.* [@humbatova-2019-taxonomyrealfaults] ha come obbiettivo l'analisi delle problematiche legate al \acl{ML}.
+In questo caso però la visione è più ampia e non si limita ad una singola libreria.
+Inoltre in questo caso lo scopo ultimo del lavoro è la costruzione di una tassonomia per le problematiche di \ac{ML}.
+
+Anche in questo caso il dati sono stati recuperati sia da *StackOverflow* che da GitHub.
+Inoltre per questo studio è stata anche svolta un'intervista a 20 persone tra ricercatori e sviluppatori nel campo del \acl{ML}.
+Partendo da questi dati è stata costruita una tassonomia attraverso un approccio *bottom-up*.
+La tassonomia si compone di 5 categorie *top-level*, 3 delle quali sono state divise in sotto categorie.
+
+Tra le categorie di primo livello ci sono:
+
+- *Model*: in questa categoria rientrano tutte le problematiche che riguardano la struttura e le proprietà del modello.
+- *Tensors & Inputs*: rientrano in questa categoria tutti i problemi rispetto alla *shape* dei dati e al loro formato.
+- *Training*: questa categoria è la più ampia della tassonomia.
+  Rientrano in questa categoria la qualità e il preprocessing dei dati utilizzati per l'apprendimento, il *tuning* degli *hyperparametri*, la scelta della funzione di perdita più appropriata ecc.
+- *GPU Usage*: in questa categoria ricadono tutti i problemi nell'uso della \ac{GPU}.
+- *API*: rientrano in questa categoria tutti i problemi generati da un non corretto utilizzo dell'\ac{API} del framework di \acl{ML}.
+
+Come si può notare, fatta salva la specificità del primo lavoro, esiste una forte similitudine tra le categorie di problemi individuate dai due lavori.
+
+## Argomenti di discussione tipici del ML
+
+Nello studio di Bangash *et al.* [@bangash2019whatdevelopersknow] viene svolta un analisi degli argomenti riguardanti il \acl{ML} discussi più frequentemente dagli sviluppatori.
+In questo caso, a differenza dello studio di Han *et al.* [@han2020whatprogrammersdiscuss] discusso precedentemente, non viene svolta alcuna distinzione in base alla libreria utilizzata.
+Inoltre questo studio utilizza unicamente informazioni recuperate da *StackOverflow*, mentre l'altro lavoro univa le domande di *StackOverflow* alla discussione generata all'interno dei repositories di GitHUb.
+
+In questo caso il topic più frequentemente discusso riguarda la presenza di errori all'interno del codice.
+Seguono discussioni rispetto agli algoritmi di apprendimento e al training dei dati.
+Lo studio ha evidenziato anche come molte discussioni riguardano librerie e framework di \acl{ML} come ad esempio `numpy`, `pandas`, `keras` ecc.
+Tutte queste discussioni sono state inserite nel topic *framework*.
+
+Altri lavori[@alshangiti2019whydevelopingmachine] invece hanno analizzato unicamente le discussioni su *StackOverflow* per andare a capirne il contenuto.
 Lo scopo di questi studi è quello di individuare le fasi più critiche del processo di sviluppo e capire quali sono gli argomenti che gli sviluppatori discutono più frequentemente.
 
+## Entropia di un cambiamento
+
 Altri studi[@hassan2009predictingfaultsusing] ancora hanno traslando il concetto di entropia[@shannon1948mathematicaltheorycommunication] utilizzato nella teoria della comunicazione per andare a valutare la complessità del processo di cambiamento del software.
 Andando, inoltre, ad evidenziare come la complessità del processo possa essere utilizzata per predire i *faults* all'interno dei prodotti software con risultati migliori rispetto alle metriche di complessità del software.
 

src/metadata.yaml

@@ -37,10 +37,14 @@ acronym:
     long: European Council for Nuclear Research
   - short: DL
     long: Deep Learning
+  - short: GPU
+    long: Graphics Processing Unit
   - short: ML 
     long: Machine Learning
   - short: NLP 
     long: Natural Language Processing
+  - short: PR
+    long: Pull Request
   - short: RQ
     long: Research Question
   - short: SATD