Detecting asynchrony and dephase change patterns by mining software repositories
Bibliographic record
Abstract
SUMMARY Software maintenance accounts for the largest part of the costs of any program. During maintenance activities, developers implement changes (sometimes simultaneously) on artifacts in order to fix bugs and to implement new requirements. To reduce this part of the costs, previous work proposed approaches to identify the artifacts of programs that change together. These approaches analyze historical data, mined from version control systems, and report change patterns, which lead at the causes, consequences, and actors of the changes to source code files. They also introduce so‐called change patterns that describe some typical change dependencies among files. In this paper, we introduce two novel change patterns: the asynchrony change pattern, corresponding to macro co‐changes (MC), that is, of files that co‐change within a large time interval (change periods) and the dephase change pattern, corresponding to dephase macro co‐changes (DC), that is, MC that always happens with the same shifts in time. We present our approach, that we named Macocha, to identify these two change patterns in large programs. We use the k‐nearest neighbor algorithm to group changes into change periods. We also use the Hamming distance to detect approximate occurrences of MC and DC. We apply Macocha and compare its performance in terms of precision and recall with UMLDiff (file stability) and association rules (co‐changing files) on seven systems: ArgoUML, FreeBSD, JFreeChart, Openser, SIP, XalanC, and XercesC developed with three different languages (C, C++, and Java). These systems have a size ranging from 532 to 1693 files, and during the study period, they have undergone 1555 to 23,944 change commits. We use external information and static analysis to validate (approximate) MC and DC found by Macocha. Through our case study, we show the existence and usefulness of these novel change patterns to ease software maintenance and, potentially, reduce related costs. Copyright © 2013 John Wiley & Sons, Ltd.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.004 | 0.018 |
| Meta-epidemiology (narrow) | 0.001 | 0.000 |
| Meta-epidemiology (broad) | 0.001 | 0.001 |
| Bibliometrics | 0.014 | 0.008 |
| Science and technology studies | 0.001 | 0.000 |
| Scholarly communication | 0.002 | 0.002 |
| Open science | 0.002 | 0.001 |
| Research integrity | 0.001 | 0.001 |
| Insufficient payload (model declined to judge) | 0.000 | 0.000 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".