Dependency Tracking Using Version History

1
Dependency Tracking Using Version History
Referenced Papers and Related Work on

• Presented by
• Ashgan Fararooy

2
Possible Related Papers

• Automatic Inference of Structural Changes for
  Matching Across Program Versions
• An Approach to Software Evolution Based on
  Semantic Change
• Understanding source code evolution using
  abstract syntax tree matching
• Recomposition - Coordinating a Web of Software
  Dependencies
• Identifying the Semantic and Textual Differences
  Between Two Versions of The Program
• Visualizing and Querying Software Structures

3
Automatic Inference of Structural Changes for
Matching Across Program Versions

• Miryung Kim,
• David Notkin,
• Dan Grossman

4
Abstract

• Goal Mapping code elements in one version of a
  program to corresponding code elements in another
  version
• A fundamental building block for many software
  engineering tools
• Tools that match code elements or identify
  structural changes (refactorings and API
  changes)
• Version merging tools
• Regression testing tools
• Profile propagation tools

5
Abstract

• Two important limitations of such tools
• Having difficulty disambiguating among many
  potential matches or refactoring candidates
• Hard to analyze their outcome due to an
  unstructured representation of results
• Proposed approach to overcome these limitations
• Represent structural changes as a set of
  high-level change rules
• Automatically infer likely change rules and
  determines method-level matches based on the rules

6
Motivation

• Interest in mining software repositories is
  demanding more effective and systematic matching
  techniques
• The unstructured, usually lengthy, list of
  matches or refactorings may prevent the result of
  existing tools from being broadly used in mining
  software repository research

7
Background

• To match code elements, the differences between
  two programs must be identified
• Computing semantic differences is undecidable
• Tools typically approximate matching via
  syntactic similarity
• Existing refactoring reconstruction tools look
  for code changes that match a predefined set of
  refactoring patterns
• Problem either too many refactoring candidates
  or no candidates

8
Change Rules

• Question Given two versions of a program, what
  changes occurred with respect to a particular
  vocabulary of changes?
• A change vocabulary characterizes the
  applications for which the matching results can
  be used
• For example, diff defines a change vocabulary
  in terms of delete, add, and move line

9
Change Rules

• The paper introduces a change vocabulary with the
  goal of representing groups of related
  homogeneous changes precisely
• The core of their change vocabulary is a change
  rule consisting of a quantifier and a scope to
  which a low-level transformation applies
• For all x in (scope - exceptions),t(x), where t
  is a transformation, scope is a set of code
  elements, and exceptions is a subset of scope
• Their change vocabulary describes structural
  changes at or above the level of a method header

10
Change Rules

• Transformation Samples

11
Change Rules

• Change Rule Samples
• All methods whose class name either includes Plot
  or JThermometer changed their package name from
  chart to chart.plot

12
Change Rules

• Change Rule Samples
• All methods that match the chart.Plot.getRange()
  pattern take an additional ValueAxis argument,
  except the getVerticalRange method in the
  MarkerPlot class

13
Rule-based Matching

• The paper defines a matching between two versions
  of a program by a set of change rules
• The scope of one rule may overlap with the scope
  of another rule as some methods undergo more than
  one transformation
• The inference algorithm ensures that it infers a
  set of rules such that the application order of
  rules does not matter
• The methods that are not matched by any rules are
  deleted or added methods

14
Applications of Change Rules

• Bug Finding
• Assisted Documentation
• API Evolution Analysis
• API Update
• Identifying Related Changes

15
Evaluation Conclusion

• By applying their tool to several open source
  projects, the authors show that it identifies
  matches that are difficult to find using other
  approaches
• They also show their approach produces more
  concise results than other approaches
• They claim their approach is the first to
  automatically infer structural changes and
  represent them concisely as a set of rules

16
Recomposition Coordinating a Web of Software
Dependencies

• Rebecca E. Grinter

17
Abstract

• Revisiting the concept of "recomposition
• All the work that development organizations do
  to make sure that their product fits together and
  into a broader environment of other technologies
• Technologies, such as Configuration Management
  (CM) systems, can ameliorate some of a software
  development teams need to engage in
  recomposition
• Technological solutions do not scale to address
  other kinds of recomposition needs

18
Summary

• The paper focuses on various organizational
  responses to the need for recomposition
• Describes how those responses are manifested in
  the day-to-day communications and
  responsibilities of individuals throughout the
  organization
• Highlights how changes in an organization
  complicate recomposition

19
Conclusion

• The paper concludes with a discussion of
• three features of software development
• work that are revealed by recomposition
• The affects of environmental disturbances on
  development work
• The types of dependencies that require
  recomposition
• The images of organizations required to manage
  the recomposition

20
Thank you