Joines and Roberts (1998) have stated that “An object-oriented simulation (OOS) consists of a set of objects that interact with each other over time” (p. 141). Indeed assessing the accuracy of a procedural paradigm is a difficult task, it is even harder under the object-oriented paradigm (OOP), particularly since OOP induces various challenges and complexities as stated by Balci (1997), which are “The dynamic and diverse patterns of interactions among groups of objects, nonsequential representation, the partition of the model structure in inheritance and aggregation relationships, and the incremental and iterative nature of model development” (p. 138).
As such, many methodologies have been suggested to test object-oriented software, which can be utilized to test object-oriented simulation systems, one such strategy has been suggested by Pezz and Young (2004) that “Include three main phases: intra-class, inter-class, and system and acceptance testing.” Within this context, intraclass testing deals with classes in isolation and includes testing of abstract classes, selection of test cases from the ancestors’ test suite, and testing state-dependent behavior of the class under test, while, interclass testing applies to clusters of classes to be tested incremen-tally, considering class interactions, polymorphic calls, and exception handling. System-and-acceptance testing considers the software as a whole independently from its internal structure and relies on traditional system and acceptance-testing techniques.
Along those lines, Balci (1997) has developed taxonomy of VV&T techniques (see Figure 7) that classified the VV&T techniques into three categories: conventional, specific, and adaptive. Moreover, the taxonomy defined 77 V&V techniques and 38 V&V techniques for object-oriented simulation, noting that most of the techniques are derived from the software-engineering world and modified to the needs of object-oriented simulation systems.
Within this context, conventional techniques refer mainly to VV&T techniques used in the object-oriented simulation without any adaptation to OOP, which is further classified as: informal, static, dynamic, and formal categories, highlighting the fact that such categories were previously discussed in the chapter. Likewise, adaptive techniques, the second category in the taxonomy, which refers to techniques that were adapted to object-oriented theory including: adequacy criteria-based testing, class testing by pointer examination, data flow testing which includes (flow-graph-based class testing, hierar-Figure 7. A taxonomy of verification and validation techniques for object-oriented simulation models (Balci, 1997, p. 140)
V&V Techniques for Object-Oriented Simulation Models
Conventional
Adequacy Criteria-Based Testing Class Testing by Pointer Examination Data Flow Testing Flattened Regular Expression Testing
Technique (FREE Approach) PACT Strategy for Component Testing State Testing
chical data-flow testing, intraclass data-flow testing), domain-dependent testing, ex-tended data-flow analysis, fault-based testing, hypothesis-based testing, model-based testing, and three-view model testing, which includes object-model testing, functional-model testing, and dynamic-functional-model testing.
Finally, specific techniques, the third category in the taxonomy, are newly created based on object-oriented formalism and used for object-oriented software. It should be taken into consideration that those techniques are algebraic specification-based testing, ASTOOT testing strategy, DAISTISH testing strategy, DAISTS testing strategy, class firewall technique, component certification technique, flattened regular expression testing, technique (FREE approach), FOOT testing strategy, identity method, set and examine method, inheritance method, inheritance testing, hierarchical incremental test-ing, repeated inheritance testtest-ing, integration testtest-ing, composition-based integration testing, incremental integration testing, interaction testing, object-integration testing, propagation-based integration testing, wave front integration testing, method sequence testing, modifier sequence testing, modular type/subtype verification, PACT strategy for component testing, state testing, state-based functional testing, state-based testing, object state testing, and graph-based class testing.
Within this context, Balci (1997) has classified DAISTS as a specific technique from the algebraic specification-based testing. Furthermore, Gannon McMullin, and Hamlet (1981) has stated that data-abstraction implementation, specification, and testing system (DAISTS) “permits a program implementing an abstract data type to be augmented with specification axioms and test cases to explore the consistency of axioms and implementation” (p. 212).
In the same token, Balci (1997) has classified ASTOOT as a specific technique from the algebraic specification-based testing . Furthermore, Doong and Frankl (1994) has stated that a set of tools for object-oriented testing (ASTOOT) “includes an interactive specification-based test-case-generation tool and a tool that automatically generates test drivers. For any class C, ASTOOT can automatically generate a test driver, which in turn automatically executes test cases and checks their results. Additionally, when an algebraic specification for C is available, ASTOOT can partially automate test generation.
Thus the system allows for substantial automation of the entire testing process” (p. 102).
Likewise, Balci (1997) has classified Daistish as a specific technique from the algebraic specification-based testing . Hughes and Stotts (1996) have distinguishably described Daistish as follows:
Daistish is a tool that performs systematic algebraic testing similar to Gannon’s DAISTS tool. However, Daistish creates effective test drivers for programs in languages that use side effects to implement ADTs; this includes C++ and most other object-oriented languages. The functional approach of DAISTS does not apply directly in these cases. (p. 1)
It is worth mentioning, however, that Hughes and Stotts (1996) have compared Daistish to ASTOOT as follows:
Daistish differs from ASTOOT by using Guttag-style algebraic specs (functional notation), by allowing aliasing of type names to tailor the application of parameters in test cases, and by retaining the abilities of DAISTS to compose new test points from existing ones. Daistish is a Perl script, and is compact and practical to apply. (p. 1) Additionally, the class firewall, denoted CFW(X) for a class X, is the set of classes grouped within specific techniques that could be affected by changes to class X and thus, that should be retested when class X is changed (Labiche, Thévenod, Fosse, Waeselynck, & Durand 2000)
Furthermore, model-based testing relies on execution traces of behavior models, most importantly since they are used as test cases for an implementation: input and expected output. This complements the ideas of model-driven testing (Pretschner, 2005).
In addition, Balci (1997) has categorized hierarchical incremental class testing as a specific inheritance test, Harrold, McGregor, and Fitzpatrich (1992) has explained the process of a hierarchical incremental class test as follows:
1. First, a base class is tested by testing each member function individually and then testing the interactions among the member functions.
2. The test suite, execution information, and association between the member func-tions and test cases is saved in a testing history.
3. Then, when a subclass is defined, the testing history of its parent, the definition of the modifier and the inheritance mapping of the implementation language are used to derive the testing history for the subclass.
4. The subclass’s testing history indicates which attributes to (re)test in the subclass and which of the parent’s test cases can be reused.
Moreover, specification fault-based testing is one of the adaptive VV&T techniques, as Richardson, O’Malley, and Tittle (1989) have stated “The goal of spec/fault-based testing is to detect faults in the specification by revealing specification failures or to detect coding faults that are due to misunderstanding the specification by revealing implementation failures” (p. 89). Based on Richardson‘s description, formal specification language is needed to use such technique.
Binder (1995) has identified that FREE (flattened regular expression) is a state-based testing technique, as Balci (1997) has classified FREE as a specific VV&T technique, furthermore, Binder has stated FREE “technique can detect four kinds of bugs: missing transition, incorrect transition, incorrect output actions, and incorrect states.” (Xu, Xu,
& Nygard, 2005). As Xu et al. explain, FREE uses the generation of a transition tree from a state model, then, transition test sequences are transcribed from the tree, thus, FREE shows that the specifications are satisfied.
Furthermore, Unified Modeling Language (UML) has been used in building simulation systems by many, such as: Carr and Balci (2000), Lendermann, Gan, and McGinnis (2001), Ramakrishnan, Lee, and Wysk (2002), and even IBM (2005) advertises such an idea.
Moreover, Linzhang et al. (2004) has stated that: “As a semi-formal modeling language, UML is widely used to describe analysis and design specifications by both academia and industry, thus UML models become the sources of test generation naturally”, highlight-ing the fact that UML’s advantage in this case “is that they provide a convenient basis for selecting tests” (Offutt & Abdurazik, 1999).