diff --git a/src/chapter_1.md b/src/chapter_1.md index b47dec3..892124f 100644 --- a/src/chapter_1.md +++ b/src/chapter_1.md @@ -11,60 +11,11 @@ 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. -## Opere correlate +## Struttura della tesi -In questo lavoro[@gonzalez2020statemluniverse10] sono stati studiati mediante tecniche di statistica descrittiva $9325$ progetti. -I progetti sono stati distinti tra sistemi di \ac{ML}, a loro volta suddivisi in framework ($700$ elementi) e applicazioni ($4524$ elementi), e sistemi generici ($4101$ elementi). -Gli aspetti considerati per l'analisi sono vari, si va dalla distribuzione dei contributi, a loro volta divisi tra interni ed esterni, fino all'analisi dei linguaggi più utilizzati, passando per un'analisi sulla popolarità dei vari repositories. -Inoltre vengono valutate anche le differenze per quanto riguarda le interazioni collaborative (discussioni, review, ecc.). - -In altri lavori[@han2020empiricalstudydependency] il focus è stato puntato sulla gestione delle dipendenze dei progetti di \acl{ML}. -In questo caso si va a valutare le eventuali differenze in base al framework utilizzato. -Le librerie considerate nello studio sono: `TensorFlow`, `PyTorch` e `Theano`. -Mentre eventuali differenze sono state ricercate rispetto agli obbiettivi del progetto (tutorial/libri, applicativi, ricerca), il dominio applicativo, la popolarità, la frequenza di aggiornamento delle dipendenze e i motivi degli aggiornamenti. - -In altri casi[@grichi2020impactmultilanguagedevelopment] ancora l'attenzione è stata rivolta alla natura *multi-linguaggio* tipica delle soluzioni di \acl{ML} e all'impatto che ciò ha sul sistema. -In questo caso sono stati considerati, tra progetti mono-linguaggio e multi-linguaggio, $27$ repository open source. -Per quanto riguarda l'analisi sono stati presi in considerazione la percentuale di pull request accettate, il tempo necessario per accettare una pull request e la propensione nell'introdurre i *bug* all'interno delle pull request. - -In letteratura sono presenti anche molti lavori che si concentrano sull'analisi delle problematiche e dei *bug* riscontrati all'interno di applicazioni di \acl{ML}. -In alcuni casi lo studio[@zhang2018empiricalstudytensorflow] è stato svolto in maniera specifica per una singola libreria. -Nello specifico sono state considerate $87$ domande postate su *StackOverflow* in relazione a bug di `TensorFlow` e $82$ commit, selezionati da $11$ progetti su *GitHub*. -Lo studio aveva l'obiettivo di individuare i sintomi e le cause scatenati di questi difetti e individuare le sfide per l'individuazione e la localizzazione di questi. - -In altri casi[@humbatova-2019-taxonomyrealfaults] l'attenzione non è stata rivolta ad una libreria specifica, ma si è cercato di definire una tassonomia delle problematiche che fosse però generale per tutti i framework e le applicazioni di \ac{ML}. -Anche in questo caso i dati per lo studio sono stati recuperati sia da *GitHub* che da *StackOverflow*. -Altre volte ancora l'analisi[@liu2021exploratorystudyintroduction] è stata mirata su alcuni aspetti specifici come l'introduzione e la rimozione di \ac{SATD} all'interno di progetti che fanno uso di \ac{DL}. - -Noi lavori precedentemente discussi l'analisi è stata svolta su dati recuperati dalla storia dei repositories e in alcuni casi recuperando informazioni aggiuntive da piattaforme di discussione online. -Altri lavori[@bangash2019whatdevelopersknow; @han2020whatprogrammersdiscuss; @alshangiti2019whydevelopingmachine] invece hanno analizzato unicamente le discussioni su *StackOverflow* per andare a capirne il contenuto. -Lo scopo di questi studi è quello di individuare le fasi più critiche del processo di sviluppo e capire quali sono gli argomenti che gli sviluppatori discutono più frequentemente. - -Altri studi[@hassan2009predictingfaultsusing] ancora hanno traslando il concetto di entropia[@shannon1948mathematicaltheorycommunication] utilizzato nella teoria della comunicazione per andare a valutare la complessità del processo di cambiamento del software. -Andando, inoltre, ad evidenziare come la complessità del processo possa essere utilizzata per predire i *faults* all'interno dei prodotti software con risultati migliori rispetto alle metriche di complessità del software. - -## Research Questions - -Questo studio ha l'obiettivo di dare una risposta a queste cinque domande: - -- **RQ1**: *come il \ac{ML} e' distribuito sull'architettura dei progetti?* - - In questa *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. -- **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*. - 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}. +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}* +I risultati delle analisi e una discussione qualitativa su alcuni *casi estremi* sono riportati nella @sec:results. +Infine la @sec:conclusions chiude questa tesi.