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 Decomposition o Finding common error patterns by mining software revision histories o Mining Version Histories to Guide Software Changes o 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 use o Record higher-level changes such as refactorings o 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 Creation Creates a node n for an entity of a given type t o Addition Adds a node n as a child of a given parent p o Removal Removes a node n from the childs of its parent p  Atomic

o Property change Changes value v of property p of node n o Insertion Inserts node n at location m as a child of (method) parent p o Deletion Deletes a node n from location m in the children of the given parent p  Atomic

 Atomic  Composite o Developer Action A unit of change from a developer’s viewpoint o Refactoring A behavior-preserving automatic code transformation o Development Session It 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