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 machines. 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 the method is discussed in the context of object state testing in the detection of a state behavior error. 1 Introduction ...

Types of code changes in an object oriented library are described. A formal model for capturing and inferencing on the changes to identify affected classes is described. The model consists of three types of diagrams: the object relation diagram (ORD), the block branch diagram (BBD), and the object state diagram (OSD). An ORD describes the inheritance, aggregation, and association relationships between the classes of a C++ library. A BBD describes the control structure and interfaces of a member function. And an OSD describes the state behavior of a class. Unlike in modeling, these diagrams are automatically generated from code and facilitate understanding and changing a C++ library. An OO software maintenance environment that implements the research result is described. Our experience with the environment prototype shows promising results.

Because of the growing importance of object-oriented programming, a number of testing strategies have been proposed. They are based either on pure black-box or white-box techniques. We propose in this paper a methodology to integrate the black- and white-box techniques. The black-box technique is used to select test cases. The white-box technique is mainly applied to decide whether two objects resulting from the program execution of a test case are observationally equivalent. It is also used to select test cases in some situations. We define the concept of a fundamental pair as a pair of equivalent terms that are formed by replacing all the variables on both sides of an axiom by normal forms. We prove that an implementation is consistent with respect to all equivalent terms if and only if it is consistent with respect to all fundamental pairs. In other words, the testing coverage of fundamental pairs is as good as that of all possible term rewritings, and hence we need only concentrate on the testing of fundamental pairs. Our strategy is based on mathematical theorems. According to the strategy, we propose an algorithm for selecting a finite set of fundamental pairs as test cases. Given a pair of equivalent terms as a test case, we should then determine whether the objects that result from executing the implemented program are observationally equivalent. We prove, however, that the observational equivalence of objects cannot be determined using a finite set of observable contexts (namely, operation sequences ending with an observer function) derived from any black-box technique. Hence we supplement our approach with a "relevant observable context" technique, which is a white-box technique, to determine the observational equivalence. The relevant observable contexts are constructed from a Data Member Relevance Graph, which is an abstraction of the given implementation for a given specification. A semi-automatic tool has been developed to support this technique.

The complexity and interdependencies of an object-oriented program makes testing of such programs difficult. In this paper, we present a reverse engineering based model called Object Relation Diagram (ORD), which is generated from analyzing the C++ source code of an objectoriented 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. 1 Introduction The object-oriented (OO) paradigm is rapidly expandi...

Many authors have implied dependency cycles are widespread among the classes of object-oriented software systems. Proponents of the design principle Avoid cyclic dependencies among modules have argued such cycles are detrimental to certain software quality attributes (e.g., understandability, testability, reusability, buildability and maintainability). In this paper we present the first significant empirical study of cycles among the classes of 78 open- and closed-source Java applications. We find that, of the applications comprising enough classes to support such a cycle, around 45 % have a cycle involving at least 100 classes and around 10 % have a cycle involving at least 1000 classes. We present further empirical evidence to support the contention these cycles are not due to intrinsic interdependencies between particular classes in a domain. Finally, we attempt to gauge the refactoring burden to break all these cycles using the concept of a minimum edge feedback set. 1.

Many software engineering tools and techniques rely on graphical representations of software, such as control flow graphs, program dependence graphs, or system dependence graphs. To apply these tools and techniques to object-oriented software, we cannot necessarily use existing graphical representations of procedural software. Representations of object-oriented software, like those for procedural software, must depict individual procedures (methods) and entire programs; however, they must also depict classes and their interactions, and account for the effects of inheritance, polymorphism, and aggregation. These representations should facilitate the use of existing program analysis tools and techniques, rather than requiring us to create new techniques. A system for constructing and managing these representations should take advantage of the code reuse inherent in object-oriented software, by reusing representational components. In this paper, we describe a coherent family of graphical ...

This paper surveys the existing slicing techniques for object-oriented programs. Many commercial objectoriented programs are concurrent in nature. Concurrency is typically implemented in the form of multithreading or message passing using sockets or both. We therefore review the available techniques in slicing of concurrent object-oriented programs. Another trend that is clearly visible in object-oriented programming is client-server programming in a distributed environment. We briefly review the existing techniques for slicing of distributed object-oriented programs.

Software testing incurs a considerable expense when developing software systems. Software testing requires voluminous test data to demonstrate that “few ” errors exist. If the process of software testing could be carried out automatically, then the testing efficiency would increase and the cost of software development would be significantly reduced. This paper describes an automated approach to the testing of object-oriented programs. The approach uses a statebased testing method. The method refers to statecharts and state/transition trees to generate test data files and inspection trees (IT) automatically. Inspection trees can parse test results files, which are produced after the programs have been tested using test data files. This allows us to determine whether the programs under test are error-free or not. Moreover, the first speciality of the Method for Automatic Class Testing (MACT) is that it can automatically generate various inspection trees from statecharts. MACT stores the expected results of the tested class in an inspection tree. The expected results are produced from a statechart. Therefore, reducing the work necessary to be done by testers is the second speciality of MACT.

Because of the growing importance of object-oriented programming, a number of testing approaches have been proposed. Frankl et al. propose the application of the functional approach, using algebraic specifications for the generation of test cases and the validation of methods. Given a specification, Frankl et al. propose that equivalent terms should give observably equivalent objects, and offer general heuristics on the selection of equivalent terms for testing. Their guidelines, however, are only supported by limited empirical results, do not have a theoretical basis, and provide no guarantee of effectiveness. In this paper, we define the concept of a fundamental pair as a pair of equivalent terms which are formed by replacing all the variables on both sides of an axiom by normal forms. We prove that an implementation is consistent with respect to all equivalent terms if and only if it is consistent with respect to all fundamental pairs. In other words, the testing coverage of fundamental pairs is identical to that of all equivalent terms, and hence we need only concentrate on the testing of fundamental pairs. Our strategy is mathematically based, simple, and much more efficient. Furthermore, it underscores the usefulness of axiom-based specifications.

In this paper we describe a taxonomy of object-oriented classes that catalogs each class in an application according to the characteristics of that class, including the properties of the data attributes and routines as well as the relationships with other classes. Our taxonomy is motivated by the fact that the current research literature contains no formal methodology for capturing the characteristics of a class. To illustrate the advantages of the taxonomy, we apply it to the problem of choosing implementation-based testing techniques and, more importantly, we show that our taxonomy can expose characteristics of a class that remain uncovered by the chosen testing technique. 1