By Topic

Software Engineering, IEEE Transactions on

Issue 10 • Date Oct. 2005

Filter Results

Displaying Results 1 - 14 of 14
  • [Front cover]

    Publication Year: 2005 , Page(s): c1
    Save to Project icon | Request Permissions | PDF file iconPDF (104 KB)  
    Freely Available from IEEE
  • [Inside front cover]

    Publication Year: 2005 , Page(s): c2
    Save to Project icon | Request Permissions | PDF file iconPDF (75 KB)  
    Freely Available from IEEE
  • Guest Editorial: Special Issue on Software Maintenance and Evolution

    Publication Year: 2005 , Page(s): 801 - 803
    Cited by:  Papers (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (88 KB) |  | HTML iconHTML  

    In systems developed without aspect-oriented programming, code implementing a crosscutting concern may be spread over many different parts of a system. Identifying such code automatically could be of great help during maintenance of the system. First of all, it allows a developer to more easily find the places in the code that must be changed when the concern changes and, thus, makes such changes less time consuming and less prone to errors. Second, it allows the code to be refactored to an aspect-oriented solution, thereby improving its modularity. In this paper, we evaluate the suitability of clone detection as a technique for the identification of crosscutting concerns. To that end, we manually identify five specific crosscutting concerns in an industrial C system and analyze to what extent clone detection is capable of finding them. We consider our results as a stepping stone toward an automated "aspect miner” based on clone detection. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • On the use of clone detection for identifying crosscutting concern code

    Publication Year: 2005 , Page(s): 804 - 818
    Cited by:  Papers (29)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (736 KB) |  | HTML iconHTML  

    In systems developed without aspect-oriented programming, code implementing a crosscutting concern may be spread over many different parts of a system. Identifying such code automatically could be of great help during maintenance of the system. First of all, it allows a developer to more easily find the places in the code that must be changed when the concern changes and, thus, makes such changes less time consuming and less prone to errors. Second, it allows the code to be refactored to an aspect-oriented solution, thereby improving its modularity. In this paper, we evaluate the suitability of clone detection as a technique for the identification of crosscutting concerns. To that end, we manually identify five specific crosscutting concerns in an industrial C system and analyze to what extent clone detection is capable of finding them. We consider our results as a stepping stone toward an automated "aspect miner" based on clone detection. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Refactoring the aspectizable interfaces: an empirical assessment

    Publication Year: 2005 , Page(s): 819 - 832
    Cited by:  Papers (14)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1424 KB) |  | HTML iconHTML  

    Aspect oriented programming aims at addressing the problem of the crosscutting concerns, i.e., those functionalities that are scattered among several modules in a given system. Aspects can be defined to modularize such concerns. In this work, we focus on a specific kind of crosscutting concerns, the scattered implementation of methods declared by interfaces that do not belong to the principal decomposition. We call such interfaces aspectizable. All the aspectizable interfaces identified within a large number of classes from the Java Standard Library and from three Java applications have been automatically migrated to aspects. To assess the effects of the migration on the internal and external quality attributes of these systems, we collected a set of metrics and we conducted an empirical study, in which some maintenance tasks were executed on the two alternative versions (with and without aspects) of the same system. In this paper, we report the results of such a comparison. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • An experimental investigation of formality in UML-based development

    Publication Year: 2005 , Page(s): 833 - 849
    Cited by:  Papers (35)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1448 KB) |  | HTML iconHTML  

    The object constraint language (OCL) was introduced as part of the Unified Modeling Language (UML). Its main purpose is to make UML models more precise and unambiguous by providing a constraint language describing constraints that the UML diagrams alone do not convey, including class invariants, operation contracts, and statechart guard conditions. There is an ongoing debate regarding the usefulness of using OCL in UML-based development, questioning whether the additional effort and formality is worth the benefit. It is argued that natural language may be sufficient, and using OCL may not bring any tangible benefits. This debate is in fact similar to the discussion about the effectiveness of formal methods in software engineering, but in a much more specific context. This paper presents the results of two controlled experiments that investigate the impact of using OCL on three software engineering activities using UML analysis models: detection of model defects through inspections, comprehension of the system logic and functionality, and impact analysis of changes. The results show that, once past an initial learning curve, significant benefits can be obtained by using OCL in combination with UML analysis diagrams to form a precise UML analysis model. But, this result is however conditioned on providing substantial, thorough training to the experiment participants. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Analyzing the evolutionary history of the logical design of object-oriented software

    Publication Year: 2005 , Page(s): 850 - 868
    Cited by:  Papers (24)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1480 KB) |  | HTML iconHTML  

    Today, most object-oriented software systems are developed using an evolutionary process model. Therefore, understanding the phases that the system's logical design has gone through and the style of their evolution can provide valuable insights in support of consistently maintaining and evolving the system, without compromising the integrity and stability of its architecture. In this paper, we present a method for analyzing the evolution of object-oriented software systems from the point of view of their logical design. This method relies on UMLDiff, a UML-structure differencing algorithm, which, given a sequence of UML class models corresponding to the logical design of a sequence of system code releases, produces a sequence of "change records" that describe the design-level changes between subsequent system releases. This change-records sequence is subsequently analyzed from the perspective of each individual system class, to produce the class-evolution profile, i.e., a class-specific change-records' sequence. Three types of longitudinal analyses - phasic, gamma, and optimal matching analysis - are applied to the class-evolution profiles to recover a high-level abstraction of distinct evolutionary phases and their corresponding styles and to identify class clusters with similar evolution trajectories. The recovered knowledge facilitates the overall understanding of system evolution and the planning of future maintenance activities. We report on one real-world case study evaluating our approach. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Checking inside the black box: regression testing by comparing value spectra

    Publication Year: 2005 , Page(s): 869 - 883
    Cited by:  Papers (10)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (984 KB) |  | HTML iconHTML  

    Comparing behaviors of program versions has become an important task in software maintenance and regression testing. Black-box program outputs have been used to characterize program behaviors and they are compared over program versions in traditional regression testing. Program spectra have recently been proposed to characterize a program's behavior inside the black box. Comparing program spectra of program versions offers insights into the internal behavioral differences between versions. In this paper, we present a new class of program spectra, value spectra, that enriches the existing program spectra family. We compare the value spectra of a program's old version and new version to detect internal behavioral deviations in the new version. We use a deviation-propagation call tree to present the deviation details. Based on the deviation-propagation call tree, we propose two heuristics to locate deviation roots, which are program locations that trigger the behavioral deviations. We also use path spectra (previously proposed program spectra) to approximate the program states in value spectra. We then similarly compare path spectra to detect behavioral deviations and locate deviation roots in the new version. We have conducted an experiment on eight C programs to evaluate our spectra-comparison approach. The results show that both value-spectra-comparison and path-spectra-comparison approaches can effectively expose program behavioral differences between program versions even when their program outputs are the same, and our value-spectra-comparison approach reports deviation roots with high accuracy for most programs. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Studying the fault-detection effectiveness of GUI test cases for rapidly evolving software

    Publication Year: 2005 , Page(s): 884 - 896
    Cited by:  Papers (78)  |  Patents (2)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1056 KB) |  | HTML iconHTML  

    Software is increasingly being developed/maintained by multiple, often geographically distributed developers working concurrently. Consequently, rapid-feedback-based quality assurance mechanisms such as daily builds and smoke regression tests, which help to detect and eliminate defects early during software development and maintenance, have become important. This paper addresses a major weakness of current smoke regression testing techniques, i.e., their inability to automatically (re)test graphical user interfaces (GUIs). Several contributions are made to the area of GUI smoke testing. First, the requirements for GUI smoke testing are identified and a GUI smoke test is formally defined as a specialized sequence of events. Second, a GUI smoke regression testing process called daily automated regression tester (DART) that automates GUI smoke testing is presented. Third, the interplay between several characteristics of GUI smoke test suites including their size, fault detection ability, and test oracles is empirically studied. The results show that: 1) the entire smoke testing process is feasible in terms of execution time, storage space, and manual effort, 2) smoke tests cannot cover certain parts of the application code, 3) having comprehensive test oracles may make up for not having long smoke test cases, and 4) using certain oracles can make up for not having large smoke test suites. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Empirical validation of object-oriented metrics on open source software for fault prediction

    Publication Year: 2005 , Page(s): 897 - 910
    Cited by:  Papers (165)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1640 KB) |  | HTML iconHTML  

    Open source software systems are becoming increasingly important these days. Many companies are investing in open source projects and lots of them are also using such software in their own work. But, because open source software is often developed with a different management style than the industrial ones, the quality and reliability of the code needs to be studied. Hence, the characteristics of the source code of these projects need to be measured to obtain more information about it. This paper describes how we calculated the object-oriented metrics given by Chidamber and Kemerer to illustrate how fault-proneness detection of the source code of the open source Web and e-mail suite called Mozilla can be carried out. We checked the values obtained against the number of bugs found in its bug database - called Bugzilla - using regression and machine learning methods to validate the usefulness of these metrics for fault-proneness prediction. We also compared the metrics of several versions of Mozilla to see how the predicted fault-proneness of the software system changed during its development cycle. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Small Errors in "Toward Formalizing Domain Modeling Semantics in Language Syntax'

    Publication Year: 2005 , Page(s): 911
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (31 KB) |  | HTML iconHTML  

    A recent paper on domain modeling had State Charts with semantic errors. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • [Advertisement]

    Publication Year: 2005 , Page(s): 912
    Save to Project icon | Request Permissions | PDF file iconPDF (328 KB)  
    Freely Available from IEEE
  • TSE Information for authors

    Publication Year: 2005 , Page(s): c3
    Save to Project icon | Request Permissions | PDF file iconPDF (75 KB)  
    Freely Available from IEEE
  • [Back cover]

    Publication Year: 2005 , Page(s): c4
    Save to Project icon | Request Permissions | PDF file iconPDF (104 KB)  
    Freely Available from IEEE

Aims & Scope

The IEEE Transactions on Software Engineering is interested in well-defined theoretical results and empirical studies that have potential impact on the construction, analysis, or management of software. The scope of this Transactions ranges from the mechanisms through the development of principles to the application of those principles to specific environments. Specific topic areas include: a) development and maintenance methods and models, e.g., techniques and principles for the specification, design, and implementation of software systems, including notations and process models; b) assessment methods, e.g., software tests and validation, reliability models, test and diagnosis procedures, software redundancy and design for error control, and the measurements and evaluation of various aspects of the process and product; c) software project management, e.g., productivity factors, cost models, schedule and organizational issues, standards; d) tools and environments, e.g., specific tools, integrated tool environments including the associated architectures, databases, and parallel and distributed processing issues; e) system issues, e.g., hardware-software trade-off; and f) state-of-the-art surveys that provide a synthesis and comprehensive review of the historical development of one particular area of interest.

Full Aims & Scope

Meet Our Editors

Editor-in-Chief
Matthew B. Dwyer
Dept. Computer Science and Engineering
256 Avery Hall
University of Nebraska-Lincoln
Lincoln, NE 68588-0115 USA
tseeicdwyer@computer.org