From 5c8637b5f12a3a844d3ec13c3452408e9302f0b7 Mon Sep 17 00:00:00 2001 From: norangebit Date: Mon, 14 Jun 2021 17:43:32 +0200 Subject: [PATCH] Add methodology --- src/chapter_3.md | 58 +++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 57 insertions(+), 1 deletion(-) diff --git a/src/chapter_3.md b/src/chapter_3.md index 886214d..f3fad1c 100644 --- a/src/chapter_3.md +++ b/src/chapter_3.md @@ -1,4 +1,4 @@ -# Metodologia {#sec:methodology} +# Costruzione del dataset e metodologia {#sec:methodology} ## Research Questions @@ -135,3 +135,59 @@ La classificazione è avvenuta attraverso la lista delle issues citate all'inter ![Risultato della classificazione dei commit](figures/count-commit.pdf){#fig:count-commit width=80%} +## Metodologia + +### 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. +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}. +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: + +- 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. +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 uno script sono stati estratti, per ogni file, gli import utilizzati all'interno del file stesso. +A questo punto sono stati individuati i files di \acl{ML} in base agli import utilizzati. +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`. + +### RQ2: come sono distribuiti i bug sulle diverse fasi di ML? {#sec:rq2} + +Come illustrato nella @sec:classificazione-commit per poter determinare la natura di un *issue fix* si è fatto ricorso alla classificazione delle *issues* ad esso associate. +La maggior parte delle *issues* è stata classificata automaticamente, ma è stato comunque necessario classificarne una porzione in modo manuale per poter avere un train/test set. +Come detto precedentemente, nel caso delle *issues* classificate a mano, oltre all'individuazione della tipologia (\ac{ML}, non \ac{ML}) è stata individuata anche la fase in cui il problema si palesava (si veda @sec:classificazione-issues). +Questo dato aggiuntivo presente su alcune issues è stato *proiettato* anche sulla classificazione dei commit di *fix* per andare a valutare come questi sono distribuiti sulle varie fasi. + +### RQ3: esiste una differenza di entropy tra ML bug e altri bug? {#sec:rq3} + +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. + +Inoltre per poter valutare l'entità del 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]. +Per ogni commit sono stati individuati i file aggiunti ($+1$) e rimossi ($-1$) in modo tale da poter calcolare il delta-cambiamento del commit. +Eseguendo la somma di questo delta su tutti i commit si è ottenuto il numero totale di file del progetto. +In modo analogo si è proceduto anche per quanto riguarda le linee. + +[^branch-master]: Oltre al branch `master` è stato considerato anche il branch `main` diventato molto comune dopo le proteste del movimento Black Lives Matter e il branch `master-V2` unico branch utilizzato da un progetto. + +### RQ4: come varia il livello di discussione tra ML bug e altri bug? {#sec:rq4} + +Per rispondere a questa domanda è stato necessario andare a valutare il numero di commenti presenti all'interno di ogni issues. +Poiché un singolo commit può far riferimento a più issues è stato considerato il numero di commenti medi. + +A questo punto si è cercato di capire se al maggior numero di commenti è associata effettivamente una maggiore quantità di informazioni scambiate. +Per svolgere questa analisi si è partiti dal presupposto che la quantità di informazioni scambiate sia proporzionale al numero di parole utilizzate nel commento. +Quindi per ogni *issue* è stato calcolato il numero medio di parole presenti all'interno di un commento. + +### RQ5: come varia il time-to-fix tra ML bug e altri bug? {#sec:rq5} + +In quest'ultima analisi si vuole andare a valutare se c'è differenza nel tempo necessario per eseguire il *fix*. +Per valutare questo parametro è stato necessario estrarre da ogni *issue* la data di apertura e di chiusura e calcolare i giorni che intercorrono tra queste. +