Refactor RQ1

src/chapter_3.md

@@ -130,6 +130,17 @@ Prima di poter classificare i commit si è reso necessaria un'ulteriore fase di
 Sono stati considerati come commit di *fix* tutti quei commit al cui interno veniva fatto riferimento a delle issues attraverso la notazione *"#"*.
 Questa operazione ha ridotto il dataset dei commit a $3321$ unità la cui distribuzione in base al tipo è riportata in @fig:count-commit.
 
+Da ogni commit sono state estratte le informazioni rilevanti per le analisi.
+In particolare è stato conservato:
+
+- Il progetto di appartenenza.
+- L'hash del commit.
+- La data del commit.
+- L'autore del commit.
+- La lista dei files modificati.
+- Le linee modificate.
+- La lista delle *issues* citate.
+
 A questo punto è stato possibile separare i *fix* di \acl{ML} da quelli generici.
 La classificazione è avvenuta attraverso la lista delle issues citate all'interno del *commit message* e sono stati considerati come commit di \ac{ML} tutti quei commit che facevano riferimento ad almeno una issue di \ac{ML}.
 
@@ -139,23 +150,38 @@ La classificazione è avvenuta attraverso la lista delle issues citate all'inter
 
 ### RQ1: come il ML e' distribuito sull'architettura dei progetti? {#sec:rq1}
 
-In questa prima analisi si è andato a verificare l'esistenza di una differenza nei files e nelle directories modificate in base al tipo di cambiamento.
+In questa prima domanda si vuole andare a capire quant'è ampia la *superficie* del progetto che viene modificata durante gli interventi di *fix*, facendo distinzione tra le correzioni che riguardano il \ac{ML} e quelle generiche.
-Per poter svolgere questa analisi è stato necessario individuare il numero totale di file modificati per *fix* generici e per i *fix* specifici del \acl{ML}.
+Inoltre si vuole anche capire quanti file importano librerie tipiche del \acl{ML}.
-A tal fine i commit sono stati raggruppati rispetto al progetto e al tipo di cambiamento (\ac{ML}, no \ac{ML}) e per ogni istanza di questo raggruppamento si è eseguito l'union set dei files modificati.
+
-Come output di questa fase si è generato per ogni progetto:
+Per poter svolgere la prima analisi analisi è stato necessario individuare il numero totale di file modificati per *fix* generici e per i *fix* specifici del \acl{ML}.
+A tal fine i commit sono stati raggruppati rispetto al progetto e al tipo di cambiamento (\ac{ML}, no \ac{ML}).
+All'interno di ogni raggruppamento si è eseguita la concatenazione della lista dei file modificati.
+Poiché non si è interessati al numero di modifiche che ha subito ogni file le liste sono state trasformate in insiemi per eliminare le ripetizioni.
+Come output di questa fase si è ottenuto per ogni progetto:
 
 - l'insieme dei file modificati per *fix* di \ac{ML}
 - l'insieme dei file modificati per fix generici
 
 Infine eseguendo l'union set tra questi due insiemi si è ottenere l'insieme totale dei files modificati durante i *fix*.
-In questo modo è stato possibile andare a valutare la percentuale di files modificati in relazione al tipo di cambiamento.
+A questo punto per ogni progetto si è calcolata la percentuale di file modificati durante interventi di *fix* di \ac{ML} (`ml_file_ratio`) e la percentuale di file modificati durante *fix* generici (`no_ml_file_ratio`).
-Attraverso la funzione di libreria Python `os.path.dirname` sono stati ottenuti i tre insiemi sopra citati anche per quanto riguarda le directories.
 
-Un'ulteriore analisi rispetto all'architettura dei progetti è stata svolta mediante gli import.
+Attraverso la funzione di libreria Python `os.path.dirname` sono stati ottenuti i tre insiemi sopra citati anche per quanto riguarda le directories.
-Attraverso uno script sono stati estratti, per ogni file, gli import utilizzati all'interno del file stesso.
+E in modo analogo si è calcolata la percentuale di directories modificate durante interventi di \acl{ML} (`ml_dirs_ratio`) e interventi generici (`no_ml_dirs_ratio`).
-A questo punto sono stati individuati i files di \acl{ML} in base agli import utilizzati.
+Queste distribuzioni sono state analizzate graficamente attraverso l'ausilio di boxplot.
-La classificazione è avvenuta utilizzando due livelli di severità; in un primo (severità *strict*) caso sono stati considerati come import di \acl{ML} solo delle librerie strettamente di \ac{ML} come ad esempio `keras`, `TernsorFlow`, `PyTorch`, ecc.
+
-Mentre in un secondo caso (severità *base*) sono state incluse anche librerie utilizzate spesso in ambito \ac{ML}, ma anche in altri ambiti, come ad esempio `pandas`, `numpy` e `scipy`.
+Per la seconda analisi si è reso necessario conoscere per ogni file la lista degli import utilizzati.
+Questa informazione è stata recuperata attraverso uno script, che dato in input un progetto restituisce la lista dei files affiancati dalla lista degli import utilizzati all'interno del file stesso.
+L'individuazione dei file di \acl{ML} è avvenuta mediante la definizione di due gruppi di librerie tipiche del \ac{ML}.
+
+- Gruppo 1: librerie specifiche del \acl{ML} come ad esempio `keras`, `TensorFlow` e `Pytorch`.
+- Gruppo 2: librerie utilizzate in ambito \ac{ML}, ma anche in altri contesti. Appartengono a questo gruppo librerie come `numpy`, `scipy` e `pandas`.
+
+Ogni file è stato classificato come di \acl{ML} o meno in base a due livelli severità.
+Nel caso della severità *base* per rientrare all'interno dei file che fanno uso di librerie di \ac{ML} bastava importare almeno una libreria contenuta in uno dei due gruppi precedentemente descritti.
+Mentre nel caso di severità *strict* era necessario importare almeno una libreria presente nel primo gruppo.
+
+Per entrambe le classificazioni si è andato a valutare a quanto ammontava la percentuale di file di \ac{ML} appartenenti ad un progetto.
+Anche i questo caso le distribuzioni sono state analizzate attraverso l'ausilio di un boxplot.
 
 ### RQ2: come sono distribuiti i bug sulle diverse fasi di ML? {#sec:rq2}