From db68c4baf10c5fa4c1ce54e37429b0976c60260a Mon Sep 17 00:00:00 2001 From: norangebit Date: Mon, 14 Jun 2021 17:36:05 +0200 Subject: [PATCH] Refactor chapter 3 --- src/chapter_1.md | 4 ++-- src/chapter_3.md | 18 +++++++++--------- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/src/chapter_1.md b/src/chapter_1.md index 8250968..e63d35d 100644 --- a/src/chapter_1.md +++ b/src/chapter_1.md @@ -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. 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. 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: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. Infine la @sec:conclusions chiude questa tesi. diff --git a/src/chapter_3.md b/src/chapter_3.md index 2410316..886214d 100644 --- a/src/chapter_3.md +++ b/src/chapter_3.md @@ -2,7 +2,7 @@ ## 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?* @@ -49,7 +49,7 @@ Alla fine di questa seconda fase il numero di progetti è sceso a trenta. ## 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. -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. 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. @@ -64,8 +64,8 @@ Con il processo precedentemente illustrato è stato possibile recuperare: ### 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. -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. +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. 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. 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. -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: @@ -112,9 +113,9 @@ Mentre le performance del primo modello sono state valutate sull'intero dataset. \label{fig:labeling} \end{figure} -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. -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. +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. +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 | |-----------|------------------------|-------------| @@ -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. 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%} +