This paper presents Accel-Bench, a benchmark suite that aims to capture the performance of accelerator-intensive programming. To the best of our knowledge, Accel-Bench is the first benchmark suite that utilizes applications that can invoke different domain kernels in their algorithm and quantifies the potential performance gain of using hardware-accelerated functions to compose programs agnostic to their domain.

The World Wide Web (WWW) technology has been widely accepted and used to build different application systems on the Internet and/or Intranet due to its advantages in networking, platform independence, distributed accesses for multiple users at different locations. We believe that this new technology is a powerful and cost effective tool to build a next generation environment for supporting software engineering practice in a software product's life cycle. The paper reports our experience on developing a Web based testing information sharing, control and management system using WWW technology. The paper also discusses its approach, basic function features, related design and implementation mechanisms. In addition, it reports the first hand useful experience and lessons in developing Web based software engineering support systems.

The object-orientated paradigm provides the power for software development but at the same time introduces some brand new problems. One of these problems is that the relationships among classes are more complex and difficult to identify than those in the traditional paradigm. This problem becomes a major obstacle for regression testing of OO software, in which the relationships among classes as well as those between test cases and classes, must be determined a priori. In this paper we propose a new method to select only a fraction of the test cases from the entire test suite to revalidate an OO software system. This method is based on the concepts of class firewall and of marking all the classes ‘touched’ by a test case. From the class firewall, we can identify all of the affected classes after a new version of software is released. Together with the markings, we can also identify all the test cases in the test suite that need to be retested after the software change. A step-by-step process is proposed to identify the relationships between classes and test cases, compute the class firewall, and select only the appropriate test cases for retesting. © 1997 John Wiley & Sons, Ltd.

Object state behavior implies that the effect of an operation on an object may depend on the states of the object and other objects. It may cause state changes to more than one object. Thus, the combined or composite effects of the object operations must be analyzed and tested. We show that certain object state behavior errors cannot be detected readily by conventional testing methods. We describe an object state test method consisting of an object state model, a reverse engineering tool, and a composite object state testing tool. The object state test model is an aggregation of hierarchical, concurrent, communicating state machines envisioned mainly for object state testing. The reverse engineering tool produces an object state model from any C++ program. The composite object state testing tool analyzes the object state behaviors and generates test cases for testing object state interactions. We show the detection of several composite object state behavior errors that exist in a well-known thermostat example.

Since polymorphism in object-orientated (OO) programming is an important feature and tool to increase the reusability and extensibility of object-orientated programs, understanding and identifying polymorphism changes and their impacts in an object-orientated program is very important in software maintenance. Although many published research articles have addressed the polymorphism feature in object-orientated programs, almost none of them have discussed software maintenance issues on identification of polymorphism change and impact. This paper proposes a formal software maintenance model for polymorphism in object-orientated programs, and discusses a systematic approach to track different polymorphism changes and their ripple effects. In addition, it reports on the implementation of a relevant tool, OOTME, and its use on two case studies.

Since class objects are the major components in object oriented (OO) programs during run time, testing the behavior of these objects become an important task in testing of object oriented programs to complement other types of testing, such as, structure testing and functional testing. To check the behavior of objects in OO programs, it is essential to check each state and each transition for every object. The paper proposes a new test model, called object state diagram, to capture and represent the dynamic behavior of objects in an OO program. The model is an extension of the existing state models, it supports basic OO features, such as class objects, inheritance, aggregation and overloading. Unlike other models, it is a concurrent, communicating state machine which has the capability of representing the object state hierarchy for a complex class object. Based on this model we address the issues and solutions to object state test strategy, test criteria and test generation.

The complexity and interdependencies of an object oriented program makes testing of such programs difficult. We present a reverse engineering based model called Object Relation Diagram (ORD), which is generated from analyzing the C++ source code of an object oriented program. An ORD is a directed graph in which the vertices represent the object classes and the edges represent the relationships among the object classes. Based on the ORD, a test strategy, called test order, for unit testing and integration testing of object oriented programs is described. The test order algorithm uses topological sorting and clusters of strongly connected subgraphs of the ORD. It computes the optimal test order in the sense that the effort required to construct the test stubs to simulate the untested classes/member functions is minimum. We show the savings of the test strategy through statistics of the InterViews library.

Acceptance testing is the determining factor in the satisfaction of the contract between the software vendor and the customer. In today's industry practice, there is a lack of a systematic method to help testers (or customers) construct, formalize, and verify acceptance testing models, and use them for automatic test case generation. This paper proposes a systematic approach to form the acceptance test model for a software system to represent its external behavior from the users' perspectives. Based on the generated test model, different rigorous acceptance test criteria are defined, and various types of acceptance testing are discussed.>

The importance of object state testing is illustrated through a simple example. We show that certain errors in the implementation of object state behavior cannot be readily detected by conventional structural testing, functional testing, and state testing. We describe an object state test model and outline a reverse engineering method for extracting object state behaviors from C++ source code. The object state test model is a hierarchical, concurrent, communicating state machine. It resembles the concepts of inheritance and aggregation in the object-oriented paradigm rather than the concept of state decomposition as in some existing models. The reverse engineering method is based on symbolic execution to extract the states and effects of the member functions. The symbolic execution results are used to construct the state machines. The usefulness of the model and of the method is discussed in the context of object state testing in the detection of a state behavior error. >

In the object-oriented (OO) paradigm, new features (such as encapsulation, aggregation, inheritance, polymorphism and dynamic binding) introduce new problems in software testing and maintenance. One of them is the difficulty of identifying the affected components (such as classes) when changes are made in object-oriented class libraries or programs. This paper discusses the types of code changes in an object-oriented class library, and provides an automated solution to identify different kinds of code changes and their impact. In addition, an OO software maintenance environment that implements the research result is described. Our experience with the environment prototype shows promising results.>