IET Software
Volume 7, Issue 3, June 2013
Volumes & issues:
Volume 7, Issue 3
June 2013
-
- Author(s): Árpád Beszédes and Dawn Lawrie
- Source: IET Software, Volume 7, Issue 3, p. 129 –130
- DOI: 10.1049/iet-sen.2013.0084
- Type: Article
- + Show details - Hide details
-
p.
129
–130
(2)
- Author(s): Eric Larson
- Source: IET Software, Volume 7, Issue 3, p. 131 –149
- DOI: 10.1049/iet-sen.2012.0048
- Type: Article
- + Show details - Hide details
-
p.
131
–149
(19)
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.
- Author(s): Serguei Roubtsov ; Alexander Serebrenik ; Aurelién Mazoyer ; Mark G.J. van den Brand ; Ella Roubtsova
- Source: IET Software, Volume 7, Issue 3, p. 150 –166
- DOI: 10.1049/iet-sen.2012.0056
- Type: Article
- + Show details - Hide details
-
p.
150
–166
(17)
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.
- Author(s): Minhaz Fahim Zibran and Chanchal Kumar Roy
- Source: IET Software, Volume 7, Issue 3, p. 167 –186
- DOI: 10.1049/iet-sen.2012.0058
- Type: Article
- + Show details - Hide details
-
p.
167
–186
(20)
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.
Guest Editorial
Program analysis too loopy? Set the loops aside
I2SD: reverse engineering Sequence Diagrams from Enterprise Java Beans with interceptors
Conflict-aware optimal scheduling of prioritised code clone refactoring
Most viewed content
Most cited content for this Journal
-
Progress on approaches to software defect prediction
- Author(s): Zhiqiang Li ; Xiao-Yuan Jing ; Xiaoke Zhu
- Type: Article
-
Systematic review of success factors and barriers for software process improvement in global software development
- Author(s): Arif Ali Khan and Jacky Keung
- Type: Article
-
Empirical investigation of the challenges of the existing tools used in global software development projects
- Author(s): Mahmood Niazi ; Sajjad Mahmood ; Mohammad Alshayeb ; Ayman Hroub
- Type: Article
-
Feature extraction based on information gain and sequential pattern for English question classification
- Author(s): Yaqing Liu ; Xiaokai Yi ; Rong Chen ; Zhengguo Zhai ; Jingxuan Gu
- Type: Article
-
Early stage software effort estimation using random forest technique based on use case points
- Author(s): Shashank Mouli Satapathy ; Barada Prasanna Acharya ; Santanu Kumar Rath
- Type: Article