diff --git a/src/chapter_1.md b/src/chapter_1.md index f6710ce..6c6d563 100644 --- a/src/chapter_1.md +++ b/src/chapter_1.md @@ -9,13 +9,21 @@ Tra questi sicuramente possiamo annoverare: riconoscimento di immagini, diagnosi La crescente produzione di software basato sul \acl{ML} ha generato un forte impulso anche per quanto riguarda la ricerca. 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. +In letteratura non mancano studi atti ad evidenziare le differenze tra progetti di \ac{ML} e progetti classici. +Ne tanto meno confronti dei progetti rispetto alle dipendenze e alle librerie utilizzate. + +Molti studi sono, invece, incentrati sulle problematiche legate allo sviluppo di applicazioni di \acl{ML}. +In alcuni casi l'analisi è stata svolta per librerie specifiche, in altri casi il focus è stato puntato sulle discussioni di *StackOverflow*. +In altri casi ancora l'attenzione è stata rivolta su problematiche specifiche come quella del \ac{SATD} [@liu2021exploratorystudyintroduction]. + +Anche il seguente lavoro si concentra sui difetti riscontrati all'interno delle applicazioni di \acl{ML}. +In questo caso però la ricerca di differenze è legata agli interventi di *issue fixing* relativi al \ac{ML} rispetto ad interventi di correzione generici. ## 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. -Si vuole anche scoprire se sono presenti delle fasi del processo di sviluppo che sono più critiche. +Si vuole anche scoprire se sono presenti delle fasi del processo di sviluppo che sono più critiche di altre. Infine si vuole capire se le *issues* sono trattate tutte allo stesso modo per quanto riguarda il livello di discussione e il tempo necessario alla loro risoluzione. ## Struttura della tesi diff --git a/src/chapter_2.md b/src/chapter_2.md index 51cd51f..bf36857 100644 --- a/src/chapter_2.md +++ b/src/chapter_2.md @@ -1,32 +1,175 @@ # Stato dell'arte {#sec:related-works} -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.). +## Confronto tra progetti di ML e progetti generici -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. +Nello studio di Gonzalez *et al.* [@gonzalez2020statemluniverse10] ci vengono presentate le principali differenze tra i repository di \acl{ML} e i progetti classici. +I dati per lo studio sono stati recuperati attraverso l'\ac{API} messa a disposizione di GitHub attraverso la quale è stato possible collezionare i dati associati a 9325 progetti open source così raggruppati: -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. +- 5224 progetti legati all'\ac{AI} e al \ac{ML} divisi a loro volta in: + - 700 tools e framework + - 4524 applicazioni +- 4101 progetti generici -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. +Gli aspetti considerati dallo studio sono molteplici e di varia natura. +Una prima analisi è stata condotta rispetto alla nascita dei vari repositories. +In questo modo è stato possibile individuare nel 2017 l'anno del *boom* dei repositori di \ac{AI} & \ac{ML}. +Infatti questo è stato il primo anno in cui sono stati creati più progetti legati al \acl{ML} rispetto a quelli generici. -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}. +Una seconda analisi ha permesso di capire come varia la partecipazione ai vari progetti. +Per poter svolgere questa analisi i contributori sono stati divisi in: -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. +- esterni: i loro contributi sono limitati ad aprire *issues* e commentare le discussioni. +- interni: oltre a svolgere i compiti precedentemente elencati devono anche aver chiuso delle issues o eseguito dei commit sul progetto. + +In base a questa divisione si è visto come il tools di \acl{ML} hanno un numero di contributori interni superiore rispetto ai progetti generici. +Quest'ultimi pero hanno una maggiore partecipazione esterna. +Se invece l'analisi viene svolta considerando unicamente gli autori dei commit si scopre che i progetti generici mediamente hanno più *contributors*, ma i top 4 repositories con più committer sono tutti legati al mondo del \ac{ML}. + +Un'ulteriore analisi è stata svolta anche per quanto riguarda il linguaggio con cui sono stati realizzati i vari progetti. +Sia nel caso delle applicazioni che nei tools di \acl{ML} il linguaggio più popolare è Python, mentre la seconda posizione varia. +Nel caso del tools questa è occupata da C++, mentre nelle applicazioni dai Notebook Jupyter. +Nei progetti generici invece Python occupa solo la terza posizione in quanto popolarità e le prime due sono occupate da JavaScript e Java. + +## Analisi in base al framework utilizzato + +Nello studio di Han *et al.* [@han2020empiricalstudydependency] sono stati considerati 1150 progetti GitHub così distribuiti: + +- 708 progetti che dipendono da `TensorFlow`. +- 339 progetti che dipendono da `PyTorch`. +- 103 progetti che dipendono da `Theano`. + +Per poter classificare i progetti manualmente gli autori hanno considerato il nome del progetto, la descrizione, le label e il contenuto del readme. +La classificazione è avvenuta sia rispetto all'obiettivo del progetto sia rispetto al dominio applicativo. +Come obiettivi dei progetti sono stati considerati: + +- *Competitions*: progetti realizzati per la partecipazione a delle competizioni o sfide. +- *Learning & Teaching*: progetti realizzati per libri e/o tutorial o per esercitarsi. +- *Paper Experiments*: progetti realizzati al fine di ricerca. +- *Software Development*: comprende librerie, plug-in, tools ecc.a +- *Other* + +La classifica delle librerie più utilizzate è rimasta sostanzialmente invariata per tutte le categorie; il primo posto è occupato da `TensorFlow` seguito da `PyTorch` e `Theano`. +L'unica eccezione riguarda i progetti realizzati a fini di ricerca. +In questo caso `TensorFlow` e `PyTorch` sono in posizioni invertite. +Anche per quanto riguarda la classificazione rispetto al dominio applicativo la situazione è costante. +Infatti, indipendentemente dalla libreria utilizzata, il progetti più frequenti sono quelli che hanno a che fare con video e immagini e con il \ac{NLP}. + +Un'ulteriore \ac{RQ} è andata a valutare il tipo di dipendenza, facendo distinzione tra dipendenze dirette e indirette. +Per tutte è tre le librerie si è visto che è molto più probabile avere una dipendenza diretta che indiretta. +`PyTorch` è la libreria che più frequentemente è importata direttamente, mentre `Theano` ha una probabilità di essere importata direttamente quasi uguale a quella di essere importata indirettamente. + +Un ulteriore analisi è stata condotta per individuare quanto frequentemente i progetti aggiornano le loro dipendenze o eseguono dei downgrade. +In questo caso si è visto che il progetti basati su `TensorFlow` e `PyTorch` aggiornano le proprie dipendenze molto più frequentemente rispetto ai progetti basati su `Theano`. +Mentre il tasso di downgrade è sostanzialmente equivalente. +Nel caso dei progetti che dipendono da `TensorFlow` la maggior parte dei downgrade viene spiegata dalla volontà di non utilizzare la nuova \ac{API} introdotta nella versione 2.0 della libreria. +Sempre analizzando la versione della libreria utilizzata si è visto che i progetti basati su `Theano` sono quelli che utilizzano più frequentemente l'ultima versione disponibile della libreria. + +In un altro lavoro di Han *et al.* [@han2020whatprogrammersdiscuss] il focus si sposta sugli argomenti di discussione e su come questi variano in base al framework utilizzato. +In questo caso all'interno dei dataset non sono rientrati unicamente i dati recuperati da GitHub, ma anche le discussioni su *StackOverflow*. + +Questo studio ha permesso di evidenziare differenze e similitudini per quanto riguarda le discussioni che si generano intorno ai tre framework di interesse. +In particolare emerge che le fasi più discusse sono quelle di *model training* e di *preliminary preparation*. +Mentre la fase meno discussa è quella di *model tuning*. +Per quanto riguarda le differenze, dallo studio, emerge che `TensorFlow` e `PyTorch` hanno topic di discussione totalmente confrontabili. +Oltre ai topic citati precedentemente, per questi framework, si discute molto anche della *data preparation*. +Mentre la discussioni riguardanti `Theano` sono quasi esclusivamente concentrate sul *model training*. + +Da questi due studi è possibile evince sicuramente una forte somiglianza per quanto riguarda `TensorFlow` e `PyThorch`. +La principale differenza viene riscontrata per quanto riguarda i campi di applicazione, con `TensorFlow` che viene generalmente preferito fatti salvi gli ambiti di ricerca. +Mentre `Theano` presenta molte diversità sia per quanto riguarda gli impieghi che le discussioni. + +## Analisi dei progetti di ML multi-linguaggio + +Lo studio di Grichi *et al.* [@grichi2020impactmultilanguagedevelopment] si concentra sui sistemi *multi-linguaggio*. +In questo caso si vuole capire se i sistemi di \ac{ML} sono più soggetti all'essere realizzati attraverso linguaggi diversi. +Inoltre analizzando le pull request realizzate in più linguaggi si vuole capire se queste sono accettate con la stessa frequenza di quelle mono linguaggio e se la presenza di difetti è equivalente. + +L'analisi è stata svolta su 27 progetti open source hostati su GitHub. +I progetti sono poi stati classificati in tre categorie: + +- Cat I: include 10 sistemi di \acl{ML} *multi-linguaggio*. +- Cat II: include 10 sistemi generici *multi-linguaggio*. +- Cat III: include 7 sistemi di \acl{ML} *mono-linguaggio*. + +Successivamente sono state scaricate le \acl{PR} di ogni progetto considerato. +Le \ac{PR}s sono state categorizzate per individuare le quelle accettate e quelle rifiutate. +Inoltre le \acl{PR} sono state categorizzate anche il base al numero di linguaggi utilizzati. +In questo modo è stato possibile individuare le \ac{PR} *mono-linguaggio* e quelle *multi-linguaggio*. +Infine per ogni \ac{PR} è stato individuato il tempo necessario alla sua accettazione o chiusura e i difetti introdotti dalla \acl{PR}. + +Per quanto riguarda la percentuale di linguaggi di programmazione utilizzati i progetti della categoria I e II sono comparabili. +La principale differenza riguarda i tipi di linguaggi utilizzati. +Nel caso dei progetti *multi-linguaggio* di \acl{ML} l'accoppiata più comune è Python e C/C++. +Mentre nel caso dei progetti generici la coppia più comune è data da Java e C/C++. +I progetti della categoria I e II sono paragonabili anche rispetto al numero di \ac{PR}s e \ac{PR}s *multi-linguaggio*. + +Lo studio ha evidenziato come all'interno dei progetti di \acl{ML} le \acl{PR} *mono-linguaggio* sono accettate molto più facilmente rispetto a quelle *multi-linguaggio*. +Inoltre anche nel caso in cui queste vengano accettate, il tempo necessario alla loro accettazione è maggiore. +Inoltre si è visto anche che rispetto alle \ac{PR}s *multi-linguaggio* non esistono differenze in base all'introduzione di *bug* tra i progetti della categoria I e II. +Mentre le \acl{PR} che includono un singolo linguaggio sembrano essere più affette da *bug* nel caso dei sistemi di \acl{ML}. + +## Problematiche caratteristiche del ML + +In letteratura sono presenti anche lavori che si concentrano sull'analisi delle problematiche e dei *bug* riscontrati all'interno di applicazioni di \acl{ML}. +Nello studio di Zhang *et al.* [@zhang2018empiricalstudytensorflow] l'attenzione è rivolta unicamente alle problematiche correlate a `TensorFlow`. +Per lo studio sono stati recuperati dei *bug* di `TensorFlow` sia da progetti su GitHub (88 elementi) sia da quesiti su *StackOverflow* (87 elementi). + +Gli autori dello studio, per poter individuare la causa dei *bug* e i loro sintomi hanno dovuto analizzare manualmente gli elementi del dataset. +Nel caso di *bug* discussi su *StackOverflow* le informazioni sono state recupera della discussione. +Mentre nel caso dei *bug* recuperati da GitHub le informazioni sono state recuperate tramite lo studio dell'intervento di *fix* e il messaggio associato ad esso. + +In questo modo è stato possibile individuare quattro sintomi: + +- *Error*: durante l'esecuzione viene sollevato un errore riconducibile a `TensorFlow`. +- *Low Effectiveness*: il programma presenta dei valori di *accuracy*, *loss* ecc. estremamente scadenti. +- *Low Efficiency*: il programma viene eseguito troppo lentamente. + +Per quanto riguarda le cause è stato possibile individuarne sei: + +- *Incorrect Model Parameter or Structure*: il *bug* è riconducibile ad un cattivo utilizzo dei parametri del modello o alla sua struttura. +- *Unaligned Tensor*: si verifica ogni qual volta la *shape* dell'input non corrisponde con quella attesa. +- *Confusion with TensorFlow Computation Model*: in questo caso i *bug* si verificano quando gli utenti non sono pratici del modello computazionale utilizzato da `TensorFlow`. +- *TensorFlow \ac{API} Change*: il *bug* dipende da un cambiamento nell'\ac{API} di `TensorFlow`. +- *TensorFlow \ac{API} Misuse*: in questo caso il *bug* è riconducibile ad un utilizzo scorretto dell'\ac{API} di `TensorFlow`. +- *Structure Inefficiency*: questa categoria può essere vista come una versione più *soft* della prima categoria. +Infatti in questo caso il problema nella struttura non genera un errore ma solo delle inefficienze. + +Anche lo studio di Humbatova *et al.* [@humbatova-2019-taxonomyrealfaults] ha come obbiettivo l'analisi delle problematiche legate al \acl{ML}. +In questo caso però la visione è più ampia e non si limita ad una singola libreria. +Inoltre in questo caso lo scopo ultimo del lavoro è la costruzione di una tassonomia per le problematiche di \ac{ML}. + +Anche in questo caso il dati sono stati recuperati sia da *StackOverflow* che da GitHub. +Inoltre per questo studio è stata anche svolta un'intervista a 20 persone tra ricercatori e sviluppatori nel campo del \acl{ML}. +Partendo da questi dati è stata costruita una tassonomia attraverso un approccio *bottom-up*. +La tassonomia si compone di 5 categorie *top-level*, 3 delle quali sono state divise in sotto categorie. + +Tra le categorie di primo livello ci sono: + +- *Model*: in questa categoria rientrano tutte le problematiche che riguardano la struttura e le proprietà del modello. +- *Tensors & Inputs*: rientrano in questa categoria tutti i problemi rispetto alla *shape* dei dati e al loro formato. +- *Training*: questa categoria è la più ampia della tassonomia. + Rientrano in questa categoria la qualità e il preprocessing dei dati utilizzati per l'apprendimento, il *tuning* degli *hyperparametri*, la scelta della funzione di perdita più appropriata ecc. +- *GPU Usage*: in questa categoria ricadono tutti i problemi nell'uso della \ac{GPU}. +- *API*: rientrano in questa categoria tutti i problemi generati da un non corretto utilizzo dell'\ac{API} del framework di \acl{ML}. + +Come si può notare, fatta salva la specificità del primo lavoro, esiste una forte similitudine tra le categorie di problemi individuate dai due lavori. + +## Argomenti di discussione tipici del ML + +Nello studio di Bangash *et al.* [@bangash2019whatdevelopersknow] viene svolta un analisi degli argomenti riguardanti il \acl{ML} discussi più frequentemente dagli sviluppatori. +In questo caso, a differenza dello studio di Han *et al.* [@han2020whatprogrammersdiscuss] discusso precedentemente, non viene svolta alcuna distinzione in base alla libreria utilizzata. +Inoltre questo studio utilizza unicamente informazioni recuperate da *StackOverflow*, mentre l'altro lavoro univa le domande di *StackOverflow* alla discussione generata all'interno dei repositories di GitHUb. + +In questo caso il topic più frequentemente discusso riguarda la presenza di errori all'interno del codice. +Seguono discussioni rispetto agli algoritmi di apprendimento e al training dei dati. +Lo studio ha evidenziato anche come molte discussioni riguardano librerie e framework di \acl{ML} come ad esempio `numpy`, `pandas`, `keras` ecc. +Tutte queste discussioni sono state inserite nel topic *framework*. + +Altri lavori[@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. +## Entropia di un cambiamento + 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. diff --git a/src/metadata.yaml b/src/metadata.yaml index a7a94f5..718aab7 100644 --- a/src/metadata.yaml +++ b/src/metadata.yaml @@ -37,10 +37,14 @@ acronym: long: European Council for Nuclear Research - short: DL long: Deep Learning + - short: GPU + long: Graphics Processing Unit - short: ML long: Machine Learning - short: NLP long: Natural Language Processing + - short: PR + long: Pull Request - short: RQ long: Research Question - short: SATD