Refactor chapter 3

This commit is contained in:
Raffaele Mignone 2021-06-14 17:36:05 +02:00
parent bd39451614
commit db68c4baf1
Signed by: norangebit
GPG Key ID: F5255658CB220573
2 changed files with 11 additions and 11 deletions

View File

@ -11,7 +11,7 @@ La crescente produzione di software basato sul \acl{ML} ha generato un forte imp
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. 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. 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.
## Obbiettivi della tesi ## 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. 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. 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.
@ -22,7 +22,7 @@ Infine si vuole capire se le *issues* sono trattate tutte allo stesso modo per q
Nella @sec:related-works viene svolta una panoramica sui lavori correlati. Nella @sec:related-works viene svolta una panoramica sui lavori correlati.
Nella @sec:methodology vengono presentate le *research question*, viene descritta la procedura utilizzata per la raccolta dei commit e delle issues e come queste sono state classificate. Nella @sec:methodology vengono presentate le *research question*, viene descritta la procedura utilizzata per la raccolta dei commit e delle issues e come queste sono state classificate.
Inoltre viene illustrata la metodologia di analisi impiegata per lo studio di ogni *\ac{RQ}* Inoltre viene illustrata la metodologia di analisi impiegata per lo studio di ogni *\ac{RQ}*.
I risultati delle analisi e una discussione qualitativa su alcuni *casi estremi* sono riportati nella @sec:results. I risultati delle analisi e una discussione qualitativa su alcuni *casi estremi* sono riportati nella @sec:results.
Infine la @sec:conclusions chiude questa tesi. Infine la @sec:conclusions chiude questa tesi.

View File

@ -2,7 +2,7 @@
## Research Questions ## Research Questions
Questo studio ha l'obiettivo di dare una risposta a queste cinque domande: Gli obiettivi di questa tesi illustrati nella @sec:goals sono stati racchiusi in cinque \ac{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?*
@ -49,7 +49,7 @@ Alla fine di questa seconda fase il numero di progetti è sceso a trenta.
## Fetch di issues e commit ## Fetch di issues e commit
Una volta individuati i progetti da analizzare si è reso necessario recuperare l'intera storia dei progetti e le issues ad essi associate. Una volta individuati i progetti da analizzare si è reso necessario recuperare l'intera storia dei progetti e le issues ad essi associate.
Per entrambe le operazioni è stato utilizzato il tool *perceval*[@duenas2018percevalsoftwareproject]. Per entrambe le operazioni è stato utilizzato il tool *perceval* [@duenas2018percevalsoftwareproject].
Nel caso delle issues, essendo queste informazioni non direttamente contenute all'interno del repository `git`, è stato necessario utilizzare nuovamente l'\ac{API} di GitHub. Nel caso delle issues, essendo queste informazioni non direttamente contenute all'interno del repository `git`, è stato necessario utilizzare nuovamente l'\ac{API} di GitHub.
Poiché le chiamate associate ad un singolo *token* sono limitate nel tempo si è scelto di configurare *perseval* in modo tale da introdurre in automatico uno ritardo ogni qualvolta veniva raggiunto il limite. Poiché le chiamate associate ad un singolo *token* sono limitate nel tempo si è scelto di configurare *perseval* in modo tale da introdurre in automatico uno ritardo ogni qualvolta veniva raggiunto il limite.
Inoltre il codice è stato dispiegato su un \ac{VPS} in modo da poter eseguire il fetch senza che fosse necessario mantenere attiva una macchina fisica. Inoltre il codice è stato dispiegato su un \ac{VPS} in modo da poter eseguire il fetch senza che fosse necessario mantenere attiva una macchina fisica.
@ -64,8 +64,8 @@ Con il processo precedentemente illustrato è stato possibile recuperare:
### Classificazione delle issues {#sec:classificazione-issues} ### Classificazione delle issues {#sec:classificazione-issues}
Al fine di poter eseguire un confronto tra i *fix* di \ac{ML} e quelli *generici* è stato necessario classificare sia le issues che i commit. Al fine di poter eseguire un confronto tra i *fix* di \ac{ML} e quelli *generici* è stato necessario classificare sia le issues che i commit.
Per quanto riguarda i primi si è scelto di attuare una classificazione basata sul testo, in particolare considerando il titolo e il corpo della issue, ma escludendo i commenti di risposta in modo da non rendere i dati troppo rumorosi.
Il numero elevato di elementi non rende praticabile una classificazione manuale per cui si è optato per una classificazione automatica. Il numero elevato di elementi non rende praticabile una classificazione manuale per cui si è optato per una classificazione automatica.
Per quanto riguarda i primi si è scelto di attuare una classificazione basata sul testo, in particolare considerando il titolo e il corpo della issue, ma escludendo i commenti di risposta in modo da non rendere i dati troppo rumorosi.
A tal fine sono stati implementati ed analizzati due classificatori, uno supervisionato e uno non supervisionato. A tal fine sono stati implementati ed analizzati due classificatori, uno supervisionato e uno non supervisionato.
I due modelli considerati sono: I due modelli considerati sono:
@ -79,8 +79,9 @@ In questo modo tutte le issues che utilizzavano almeno un vocabolo tipico del \a
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.
A tal scopo è stato eseguito un campionamento stratificato in base al progetto di provenienza di $376$ issues che sono state divise tra due lettori e labellate. A tal scopo è stato eseguito un campionamento stratificato in base al progetto di provenienza di $376$ issues che sono state divise tra due lettori e labellate.
La label delle *issues* è stata determinata andando analizzare il titolo, il corpo e i commenti associati alla *issue*.
Durante il labeling si scelto di classificare ulteriormente le issue di \ac{ML} al fine di individuare anche la fase in cui il problema si è palesato. Durante il labeling si scelto di classificare ulteriormente le issue di \ac{ML} al fine di individuare anche la fase in cui il problema si è palesato.
La definizioni delle varie fasi è avvenuta partendo da un lavoro di *Microsoft*[@amershi-2019-softwareengineeringmachine]. La definizioni delle varie fasi è avvenuta partendo dal lavoro di Amershi *et al.* [@amershi-2019-softwareengineeringmachine] realizzato nei laboratori di *Microsoft*.
Le fasi considerate sono: Le fasi considerate sono:
@ -112,9 +113,9 @@ Mentre le performance del primo modello sono state valutate sull'intero dataset.
\label{fig:labeling} \label{fig:labeling}
\end{figure} \end{figure}
Al fine di poter confrontare i due modelli sono state utilizzate le metriche di precision e recall. Al fine di poter confrontare i due modelli sono state utilizzate le metriche di *precision* e *recall*.
Com'è possibile notare dai valori riportati in @tbl:confronto-modelli-classificazione-issues, il modello basato sulla lista di vocaboli è leggermente più preciso del modello bayesiano, ma presenta una recall decisamente più bassa. Com'è possibile notare dai valori riportati in @tbl:confronto-modelli-classificazione-issues, il modello basato sulla lista di vocaboli è leggermente più preciso del modello bayesiano, ma presenta una *recall* decisamente più bassa.
Dalla @fig:labeling-type si evince la natura minoritaria delle issues di \ac{ML} rispetto alle issues generiche, per questo motivo si è scelto di preferire il modello naïve Bayes in modo da perdere quante meno istanze possibili anche a costo di sacrificare leggermente la precisione. Dalla @fig:labeling-type si evince la natura minoritaria delle issues di \ac{ML} rispetto alle issues generiche, per questo motivo si è preferito il modello naïve Bayes in modo da perdere quante meno istanze possibili anche a costo di sacrificare leggermente la precisione.
| | Classificatore statico | naïve Bayes | | | Classificatore statico | naïve Bayes |
|-----------|------------------------|-------------| |-----------|------------------------|-------------|
@ -132,6 +133,5 @@ Questa operazione ha ridotto il dataset dei commit a $3321$ unità la cui distri
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 \ac{ML}.
\newpage
![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%}