Topics

OO vs CASE

Software development is hard. There are two principle paradigms intended to make it easier. CASE (Computer Assisted Software Engineering) systems seeks to exploit common patterns and machine generate explicit code to handle each process. Object Oriented systems seek to exploit common patterns and handle each process by reusing those common patterns. Correctness and reliability are vital to the success of software systems. A common strategy to ensure these is to test the system after development. The two principle development paradigms offer different strategies.

The CASE strategy is to machine test each process explicitly just as each process was generated explicitly. Test engineers compose scripts after development by which the test machine verifies system processes. This approach is supported by the tools SQR Robot, Mercury, et. al. and their attendant script language.

The Object Oriented strategy is to verify interactions between system components and test a few explicit cases. Test engineers would, during development, maintain dependencies between system components and determine a small set of explicit tests to be conducted in order to verify interactions. This approach is supported by Rational et. al. and UML (Unified Modeling Language).

The CASE approach seems simpler on its face and is fully supported by a wide variety of products(vendor activity is one reason for the popularity of this approach even in Object Oriented systems). It has several drawbacks: the testing effort is heavily backend loaded so little value is added to the development effort, composing test scripts is itself a development effort with all its attendant problems, the number of permutations of processes are huge and only a tiny fraction of them and the underlying interactions are validated.

Despite the apparent complexity and softness of the Object Oriented approach it has many advantages: the testing effort is more evenly balanced and begins in earnest during analysis, the interactions maintained by the test engineers are of great value to the analysis and development efforts, quality knowledge of the system's interaction promotes reuse throughout the enterprise further reducing costs, the underlying interactions and thereby all of the processes are much more thoroughly validated with less effort.