A Hierarchical Measure for Software Complexity

Download Report

Transcript A Hierarchical Measure for Software Complexity

Reviewing Recent ICSE Proceedings For:
(ICSE 2008 & 2007)





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

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,
o
o
o
o
using a monitoring plug-in
Convert the changes of the program to first-class
change operations
Stores the changes in a repository for later use
Record higher-level changes such as refactorings
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
 Atomic
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
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 higherlevel 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 Metric Graph
•

It follows the evolution of one or more structural
metrics on one or more projects
The Change List
•

The launcher allows us to load the model of a
system in the environment
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