From 96f66ec340d8ee25411acb003a96be0b3f4126de Mon Sep 17 00:00:00 2001 From: norangebit Date: Tue, 15 Jun 2021 14:27:04 +0200 Subject: [PATCH] Fix chapter 3 --- src/chapter_3.md | 30 ++++++++++++++++-------------- src/metadata.yaml | 2 ++ 2 files changed, 18 insertions(+), 14 deletions(-) diff --git a/src/chapter_3.md b/src/chapter_3.md index efa4575..c336ba7 100644 --- a/src/chapter_3.md +++ b/src/chapter_3.md @@ -2,28 +2,28 @@ ## Research Questions -Gli obiettivi di questa tesi illustrati nella @sec:goals sono stati racchiusi in cinque \ac{RQ} di seguito elencate. +Gli obiettivi di questa tesi illustrati nella @sec:goals sono stati racchiusi in cinque \acl{RQ} di seguito elencate. - **RQ1**: *come il \ac{ML} e' distribuito sull'architettura dei progetti?* - In questa *RQ* si vuole investigare l'architettura dei progetti. + In questa *\ac{RQ}* si vuole investigare l'architettura dei progetti. In particolare l'attenzione viene concentratala sui files e sulle directories modificate durante interventi di *issues fixing*. Obbiettivo di questa domanda è anche individuare la percentuale di files che utilizzano import riconducibili a librerie e framework di \acl{ML}. - **RQ2**: *come sono distribuiti i bug sulle diverse fasi di \ac{ML}?* Il workflow tipico per lo sviluppo di un'applicazione di \acl{ML} si compone di più fasi. - L'obiettivo di questa *RQ* è quello di individuare le fasi più critiche per quanto riguarda l'introduzione di difetti all'interno del prodotto software. + L'obiettivo di questa *\ac{RQ}* è quello di individuare le fasi più critiche per quanto riguarda l'introduzione di difetti all'interno del prodotto software. - **RQ3**: *esiste una differenza di entropy tra \ac{ML} bug e altri bug?* A partire dai lavori precedenti svolti sull'entropia di un cambiamento, si vuole capire se esiste una differenza in termini di entropia generata tra le correzioni dei difetti ascrivibili al \acl{ML} e gli altri difetti. - **RQ4**: *come varia il livello di discussione tra \ac{ML} bug e altri bug?* - Questa *RQ* riguarda il livello di discussione dei *bug*. + Questa *\ac{RQ}* riguarda il livello di discussione dei *bug*. In particolare si vuole capire se, all'interno dei progetti di \acl{ML}, i bug generici sono discussi con lo stesso livello di approfondimento di quelli specifici del \ac{ML}. - **RQ5**: *come varia il time-to-fix tra \ac{ML} bug e altri bug?* Un altro aspetto caratteristico di un *fix* è il tempo necessario per poter essere attuato. - Questa *RQ* ha lo scopo di verificare l'esistenza di differenze tra i *bug* generici e quelli di \acl{ML}. + Questa *\ac{RQ}* ha lo scopo di verificare l'esistenza di differenze tra i *bug* generici e quelli di \acl{ML}. ## Selezione dei progetti @@ -74,7 +74,7 @@ I due modelli considerati sono: - un modello *naïve Bayes* [@2021naivebayesclassifier; @harrington2012machinelearningaction]. La classificazione mediate il classificatore statico non necessita di un *labeling* manuale dei dati, ma richiede la definizione dei vocaboli tipici del \ac{ML}. -Lista dei termini caratteristici del \acl{ML} non è stata costruita da zero, ma è basata su lavori precedenti[@humbatova-2019-taxonomyrealfaults]. +Lista dei termini caratteristici del \acl{ML} non è stata costruita da zero, ma è basata sul lavoro di Humbatova *et al.* [@humbatova-2019-taxonomyrealfaults]. In questo modo tutte le issues che utilizzavano almeno un vocabolo tipico del \acl{ML} sono state classificate come issues di \ac{ML}. Nel caso del modello *naïve Bayes*, essendo questo un algoritmo di apprendimento supervisionato, si è resa necessaria una classificazione manuale delle issues. @@ -127,7 +127,7 @@ Dalla @fig:labeling-type si evince la natura minoritaria delle issues di \ac{ML} ### Classificazione dei commit {#sec:classificazione-commit} Prima di poter classificare i commit si è reso necessaria un'ulteriore fase di filtraggio in modo da poter separare i commit di *issue fixing* da quelli generici. -Sono stati considerati come commit di *fix* tutti quei commit al cui interno veniva fatto riferimento a delle issues attraverso la notazione *"#"*. +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. @@ -142,10 +142,12 @@ In particolare è stato conservato: - 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}. +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 \acl{ML}. ![Risultato della classificazione dei commit](figures/count-commit.pdf){#fig:count-commit width=80%} +\newpage + ## Metodologia ### RQ1: come il ML e' distribuito sull'architettura dei progetti? @@ -153,7 +155,7 @@ La classificazione è avvenuta attraverso la lista delle issues citate all'inter 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. Inoltre si vuole anche capire quanti file importano librerie tipiche del \acl{ML}. -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}. +Per poter svolgere la prima 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. @@ -180,7 +182,7 @@ Ogni file è stato classificato come di \acl{ML} o meno in base a due livelli se 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. +Per entrambe le classificazioni si è andato a valutare a quanto ammontava la percentuale di file di \ac{ML} appartenenti ad ogni 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? @@ -208,7 +210,7 @@ L'analisi quantitativa è avvenuta attraverso un barplot in cui venivano riporta La successiva analisi avevo lo scopo di verificare l'esistenza di una differenza tra l'entropia del *fix* rispetto alla natura di questi. L'analisi è stata svolta sia a livello di file, sia a livello di linee quindi per ogni commit del dataset è stato necessario individuare sia il numero di file che hanno subito delle modifiche, sia il numero di linee alterate, considerando in questo modo sia le aggiunte che le rimozioni. -Il dato rispetto alle linee modificate è già presente nel dataset di partenza, mentre il numero di file modificati può essere ricavato dalla lista dei files modificati nel commit. +Il dato rispetto alle linee modificate è già presente nel dataset di partenza (si veda @sec:classificazione-commit), mentre il numero di file modificati può essere ricavato dalla lista dei files modificati nel commit. Inoltre per poter calcolare la probabilità di un cambiamento è stato necessario conoscere anche il numero totale di file e di linee di ogni progetto. Questi valori sono stati calcolati attraverso la storia `git` del branch `master`[^branch-master]. @@ -224,9 +226,9 @@ Inoltre sono stati svolti dei test statistici (*ranksum* e *Cliff's delta*) per ### RQ4: come varia il livello di discussione tra ML bug e altri bug? Per rispondere a questa domanda è stato necessario andare a valutare il numero di commenti presenti all'interno di ogni issues. -Questo dato non è presente nel dataset di partenze, ma può essere ricavato a partire dalla lista delle *issues* citate. -Per ogni *issue* citata si è calcolato il numero di commenti. -Poiché un singolo commit può far riferimento a più *issues* è stato calcolato il numero di commenti medi. +Questo dato non è presente nel dataset dei commit generato inizialmente (si veda @sec:classificazione-commit), ma può essere ricavato a partire dalla lista delle *issues* citate. +Dato un commit si è considerata la lista delle *issues* citate, e per ogni *issue* citata si è calcolato il numero di commenti. +Poiché un singolo commit può far riferimento a più *issues* è stato necessario anche calcolare il numero di commenti medi. Il livello della discussione non viene determinato solo dal numero di commenti, ma anche dalla lunghezza di questi. Quindi per ogni *issue* è stato calcolato anche il numero medio di parole presenti all'interno di un commento. diff --git a/src/metadata.yaml b/src/metadata.yaml index 334212a..a7a94f5 100644 --- a/src/metadata.yaml +++ b/src/metadata.yaml @@ -41,6 +41,8 @@ acronym: long: Machine Learning - short: NLP long: Natural Language Processing + - short: RQ + long: Research Question - short: SATD long: Self-Admitted Technical Debt - short: VPS