June 2000
Volume 2 • Number 3

Contents

Utilizing UML Diagrams for Integration
Testing of Object-Oriented Software

This article presents a method for integration testing of object-oriented (OO) software. The technique takes post-implementation diagrams based on data obtained from the implementation and uses the diagrams for integration test-case construction. The issues contributing to the difficulty of OO integration testing are reviewed and contrasted with procedurally based software. The role of integration testing during the software development life cycle is considered to the development of an approach employing the Unified Modeling Language for software design, program understanding, and defect detection.

Key words: defect categories, design issues, diagrams, process model, software development life cycle, test planning, use cases

by Gordon Skelton, Mississippi Valley Title Insurance, Annette Lerine Steenkamp, University of Detroit Mercy, Cecil D. Burge, University of Southern Mississippi

INTRODUCTION

The object-oriented (OO) paradigm is a valid model for software development (Berard 1993; Booch 1994; Martin and Odell 1998). Over the past several years a number of methods have been proposed for OO software, as well as languages supporting the OO paradigm, such as Smalltalk, Ada, Eiffel, and C++, to name a few. Each of these languages has brought various techniques for implementing OO software.

In recent years, attention has been given to the analysis and design phases of the software development life cycle and to the implementation of OO designs using the structure and syntax of specific languages. Tools have been developed that assist software developers in performing analysis and design, as well as in preserving the logical and physical models in textual and graphical formalisms. It has become possible to link an OO design to the actual code by means of CASE tools, particularly in the areas of user interfaces and data storage. Users are able to participate in designing a user interface or a data format.

There has been less progress, however, in the automatic generation of procedural code components for an application, and programmers remain responsible for writing the implementation code. It is possible to produce code automatically that supports the classes of a design. Rational Rose (Rational Corporation’s UML design tool) provides such support for software development in C++.

While the adoption of the OO paradigm for software development has increased, issues surrounding software testing have not received equal attention (McGregor and Sykes 1992; Turner and Robson 1994). Testing emphasis often lags behind other software engineering concepts. The issues of testing OO software have been addressed by (Jacobson, Booch, and Rumbaugh 1999; Jorgensen and Erickson 1994; Kung, Hsia, and Gao 1998; Binder 2000).

As with the software development, new and advanced techniques are proposed in an effort to increase the efficiency and efficacy of software testing. The benefits attributed to OO development, such as abstraction, encapsulation, inheritance, and polymorphism, have brought specific problems. Because of the level of abstraction and complexities brought on by generic programming constructs, class libraries, and templates, for example, it is challenging for designers to articulate their designs clearly so the integration testers can understand the design and properly prepare test cases. Often, the design lacks adequate detail thus leaving the test-case creator in a situation where initial test cases are less than complete.

The complexity of a design correlates with the complexity of the implementation. Obviously, as the design grows in complexity the more likely defects will be introduced in both the design and implementation. Even without a complex design, the implementation may require complicated algorithms and data structures. Complexity within a system leads to increased difficulty in maintenance. McCabe’s complexity measure (1976) is perhaps the best-known means of calculating the complexity of a program. Ideally one will work to eliminate as much complexity as possible; however, this goal will not always be accomplished. Therefore, it is helpful to have a means to analyze the final implementation.

This article presents a method for integration testing of OO software (Skelton 1999). The technique takes post-implementation diagrams based on data obtained from the implementation and uses these diagrams for integration testing and test-case construction. The issues contributing to the difficulty of OO integration testing are reviewed and contrasted with procedurally based software. The role of integration testing during the software development life cycle is considered leading to the development of an approach employing the Unified Modeling Language (UML) for software design, program understanding, and defect detection.

Appendix