Among the many obstacles to efficient and sound program analysis, loops may be the most prevalent. In program analyses that traverse paths, loops introduce a variable, possibly infinite and number of paths. This study assesses the potential of a program analysis technique that analyses loops separately and replaces the loop with a summary, similar to how many analyses use summaries for interprocedural analysis. This study is conducted by comparing the path counts when loops are analysed separately to a baseline path count where loops are traversed at most once. Although the number of paths is decreased in many cases, the magnitude of the decrease is typically not sufficient for long, complex functions. In addition, loops are classified by the task they perform, analysed using the number of paths as an estimate of their complexity and further inspected for programming elements that may make loop analysis more difficult. Of the 2869 loops used in this study, 84% of the loops have fewer than ten paths and only 1.3% have more than 10 000 paths. Nearly 60% of the loops traverse arrays or strings and roughly half of the loops contain a function call.

An Enterprise JavaBeans (EJB) interceptor is a software mechanism that provides for introducing behaviour implemented as separate code into the execution of a Java application. In this way, EJB interceptors provide a clear separation of the core functionality of the bean and other concerns, such as logging or performance analysis. Despite the beauty of the idea behind the i nterceptors, developing, testing and managing dependencies introduced by the interceptors are considered to be daunting tasks. For example, the developers can specify interceptors at multiple locations and by multiple means. However, different locations and specification means influence the order of the interceptor invocation, which is governed by more than 15 different intertwined rules defined in the EJB standard. To facilitate development of EJB applications, we have designed I2SD, Interceptors to Sequence Diagrams, a tool for reverse engineering EJB applications with interceptors to unified modeling language (UML) sequence diagrams. I2SD provides the developer with a visual feedback and can be used by quality managers to obtain insights in the ways interceptors are used in their project.

Duplicated or similar source code, also known as code clones, are possible malicious ‘code smells’ that may need to be removed through refactoring to enhance maintainability. Among many potential refactoring opportunities, the choice and order of a set of refactoring activities may have distinguishable effect on the design/code quality measured in terms of software metrics. Moreover, there may be dependencies and conflicts among those refactorings of different priorities. Addressing all the conflicts, priorities and dependencies, a manual formulation of an optimal refactoring schedule is very expensive, if not impossible. Therefore an automated refactoring scheduler is necessary to ‘maximise benefit and minimise refactoring effort’. However, the estimation of the efforts required to perform code clone refactoring is a challenging task. This study makes two contributions. First, the authors propose an effort model for the estimation of code clone refactoring efforts. Second, the authors propose a constraint programming (CP) approach for conflict-aware optimal scheduling of code clone refactoring. A qualitative evaluation of the effort model from the developers’ perspective suggests that the model is complete and useful for code clone refactoring effort estimation. The authors also quantitatively compared their refactoring scheduler with other well-known scheduling techniques such as the genetic algorithm, greedy approaches and linear programming. The authors’ empirical study suggests that the proposed CP-based approach outperforms other approaches they considered.