norangebit/master-thesis
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Fix chapter 3

Browse Source
This commit is contained in:
Raffaele Mignone 2021-06-15 14:27:04 +02:00
parent ff81331f6b
commit 96f66ec340
Signed by: norangebit
GPG Key ID: F5255658CB220573
2 changed files with 18 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
src/chapter_3.md
View File

@ -2,28 +2,28 @@
## Research Questions ## 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?* - **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*. 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}. 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}?* - **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. 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?* - **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. 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?* - **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}. 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?* - **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. 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 ## Selezione dei progetti
@ -74,7 +74,7 @@ I due modelli considerati sono:
- un modello *naïve Bayes* [@2021naivebayesclassifier; @harrington2012machinelearningaction]. - 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}. 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}. 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. 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} ### 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. 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. 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. 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. - La lista delle *issues* citate.
A questo punto è stato possibile separare i *fix* di \acl{ML} da quelli generici. 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%} ![Risultato della classificazione dei commit](figures/count-commit.pdf){#fig:count-commit width=80%}
\newpage
## Metodologia ## Metodologia
### RQ1: come il ML e' distribuito sull'architettura dei progetti? ### 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. 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}. 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}). 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. 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. 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. 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. 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. 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? ### 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. 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. 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. 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]. 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? ### 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. 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. 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.
Per ogni *issue* citata si è calcolato il numero di commenti. 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 calcolato il numero di commenti medi. 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. 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. Quindi per ogni *issue* è stato calcolato anche il numero medio di parole presenti all'interno di un commento.

2
src/metadata.yaml
View File

@ -41,6 +41,8 @@ acronym:
long: Machine Learning long: Machine Learning
- short: NLP - short: NLP
long: Natural Language Processing long: Natural Language Processing
- short: RQ
long: Research Question
- short: SATD - short: SATD
long: Self-Admitted Technical Debt long: Self-Admitted Technical Debt
- short: VPS - short: VPS