Reviewing Recent ICSE Proceedings For:

Defining and Continuous Checking of Structural Program Dependencies

Automatic Inference of Structural Changes for Matching across Program Versions

SpyWare: a change-aware development toolset

An empirical study of software developers' management of dependencies and changes

Tracking Code Clones in Evolving Software

(ICSE 2008 & 2007)

Dependencies between program elements need to be modeled from different perspectives:• Architectural• Design• Implementation

Codify these different perspectives on the permitted dependencies in a software system

Detect violations continuously and incrementally as software evolves

Proposes an approach that uses declarative queries to group source elements into overlapping ensembles

The dependencies between these ensembles are also specified as logic queries

The approach has been integrated into the incremental build process of Eclipse

Ensures continuous checking, using an engine for tabled and incremental evaluation of logic queries

Constraints on structural dependencies:

• Constraints on dependencies between layers in a layered architecture (architectural level)

• Only factory classes can access constructors of product classes (design level)

• Field access only through getters and setters (implementation level)

Ensemble denotes any logical grouping of code elements affected by a structural dependency constraint to be expressed

Module-centric visibility mechanisms supported by programming languages are insufficient for expressing constraints on structural dependencies

They lack two properties, that ensembles posess:• Ensembles can be defined orthogonal to the

module system of the implementation language

• Ensembles can share members

Motivation: change must be put in the center

SpyWare: a toolset which tracks the changes that a developer performs on a program as they happen

Stores these first-class changes in a repository

Offers the recorded information for possible productivity-enhancing IDE extensions

Software must be continuously tailored to fit new or updated requirements

Historical information of software systems is useful for several applications:o CCVisu: Automatic Visual Software Decompositiono Finding common error patterns by mining software

revision historieso Mining Version Histories to Guide Software Changeso Mining Software Repositories for Traceability Links

The evolutionary information mostly used suffers from several problems

SpyWare aims at capturing changes as they happen at the level of program entities

The tool chain monitors changes as they happen in the IDE to have a finer granularity of changes

Sequence of first-class change operations rather than a sequence of successive versions

Features:

o Monitor developer activity as it happens in the IDE, using a monitoring plug-in

o Convert the changes of the program to first-class change operations

o Stores the changes in a repository for later useo Record higher-level changes such as refactoringso Generate part or the whole of the system at any

point in time

Features:

o Access the change history of any package, class, instance variable, method, or statement defined in the system

o Show the differences between two states of the program, using color-coding to reflect the type of changes

o Measure the extent of changes using structural metrics and the type of changes that were performed

Features:

o Visualize how the system was changed with metrics, graphs, and interactive visualizations

o Generalize concrete changes to the system to reusable program transformations

o Access all of its functionality from the IDE, rather than a stand-alone tool, to ease its usage

Atomic

Composite

o CreationCreates a node n for an entity of a given type t

o AdditionAdds a node n as a child of a given parent p

o RemovalRemoves a node n from the childs of its parent p

Atomic

o Property changeChanges value v of property p of node n

o InsertionInserts node n at location m as a child of (method) parent p

o DeletionDeletes a node n from location m in the children of the given parent p

Atomic

Atomic Composite

o Developer ActionA unit of change from a developer’s viewpoint

o RefactoringA behavior-preserving automatic code transformation

o Development SessionIt aggregates all changes done during a single development session

View the history of a software system as the sum of change operations

Represent programs as domain specific entities rather than text files

Consider a software system as an evolving abstract syntax tree (AST)

Each AST entity has a change history containing all changes applied to it

Change Operations represent the transition from one state of the evolving system to the next

They are executable: A change operation c applied to the state n of the program yields the state n+1 of the program

Atomic changes are, at the finest level, operations on the program’s AST

Atomic change operations are executable, and can be undone

Representing the entire evolution of a system only by its atomic modifications is overwhelming

They abstract change operations into higher-level composite changes

Example: moving a class from package A to package B consists in removing it from A and adding it to B

The Change Repository: Changes are captured as they happen in the IDE and are stored in the repository

The Launcher• The launcher allows us to load the model of a

system in the environment The Metric Graph

• It follows the evolution of one or more structural metrics on one or more projects

The Change List• Lists all the changes done to a part or the whole

system, in a hierarchy from sessions, ..., up to atomic changes

The View Browser• It shows the code of the system at a specific date