Hi Vadim! In fact, we are recomending files to change together without the developers/newcomer need to know about the code (structural dependencies for example), or need to make debugging to find with files could change together in a task.
We found many situations that files are changed together but there aren't any "natural" reason for that. For example, they aren't structural connected or in the same package. In such cases, it is not trivial to "find" this coupling. Thus we can recommend at least some files to be inspected by developers while they are perfoming changes. The main ideia is "avoid" the incomplete change that could causes a new bug can appeared, or avoid waisting time to inspect files/debugging system to find files to change in a issue. What do you think? All the best, Igor Wiese 2015-12-10 10:55 GMT-02:00 Vadim Kimlaychuk <va...@kickcloud.net>: > Do I understand correctly that purpose of this work is to find tightly > coupled classes automatically in order to inverse dependency later on? > > Vadim. > > > On 2015-12-10 01:31, Igor Wiese wrote: > > Hi, Cloudstack Community. >> >> My name is Igor Wiese, phd Student from Brazil. In my research, I am >> investigating two important questions: What makes two files change >> together? Can we predict when they are going to co-change again? >> >> I've tried to investigate this question on the Cloudstack project. I've >> collected data from issue reports, discussions and commits and using some >> machine learning techniques to build a prediction model. >> >> I collected a total of 141 commits in which a pair of files changed >> together and could correctly predict 60% commits. These were the most >> useful information for predicting co-changes of files: >> >> - sum of number of lines of code added, modified and removed, >> >> - number of words used to describe and discuss the issues, >> >> - number of comments in each issue, >> >> - median value of closeness, a social network measure obtained from issue >> comments, and >> >> - median value of constraint, a social network measure obtained from issue >> comments. >> >> To illustrate, consider the following example from our analysis. For >> release 4.4, the files "cloud/hypervisor/XenServerGuru.java" and >> "cloud/hypervisor/guru/VMwareGuru.java " changed together in 3 commits. In >> another 2 commits, only the first file changed, but not the second. >> Collecting contextual information for each commit made to first file in >> the >> previous release (4.3), we were able to predict all 3 commits in which >> both >> files changed together in release 4.4, and we only issued 0 false >> positives. For this pair of files, the most important contextual >> information was the number of lines of code added, removed and modified in >> each commit,the number of comments in each issue, and social network >> measures (closeness, density, constraint, hierarchy) obtained from issue >> comments. >> >> - Do these results surprise you? Can you think in any explanation for the >> results? >> >> - Do you think that our rate of prediction is good enough to be used for >> building tool support for the software community? >> >> - Do you have any suggestion on what can be done to improve the change >> recommendation? >> >> You can visit our webpage to inspect the results in details: >> http://flosscoach.com/index.php/17-cochanges/67-cloudstack [1] >> >> All the best, >> Igor Wiese >> Phd Candidate >> > > > > Links: > ------ > [1] http://flosscoach.com/index.php/17-cochanges/67-cloudstack > -- ================================= Igor Scaliante Wiese PhD Candidate - Computer Science @ IME/USP Faculty in Dept. of Computing at Universidade Tecnológica Federal do Paraná
