In order to ensure reliability and quality, software systems must be tested. Testing object-oriented software is harder than testing procedure-oriented software. It involves four levels, namely the algorithmic level, class level, cluster level, and system level. We proposed a methodology TACCLE for class-and cluster- level testing. It includes an important algorithm GFT for generating fundamental equivalent pairs as class-level test cases based on axioms in a given algebraic specification for a given class. This formal methodology has many benefits. However, system analysts often find it difficult to construct axioms for algebraic specifications. In this paper, we propose a scheme to aid the construction of the left-hand sides of axioms. The scheme alleviates the difficulties of the system analysts and also helps them check the completeness, consistency, and independence of the axiom system. © 2008 IEEE.published_or_final_versionUnion Grant of Guangdong Province and
National Natural Science Foundation of China (#U0775001), Guangdong Province Science Foundation (#7010116), and by a grant of the
Youth Science Foundation of Jinan University (#51208035)

Huo, YC

Lin, T

Tse, TH

HKU Scholars Hub

Title A scheme to aid construction of left-hand sides of axioms inalgebraic specifications for object-oriented program testingAuthor(s) Huo, YC; Lin, T; Tse, THCitation Proceedings - International Conference On Computer ScienceAnd Software Engineering, Csse 2008, 2008, v. 2, p. 747-750Issued Date 2008URL http://hdl.handle.net/10722/54696Rights Creative Commons: Attribution 3.0 Hong Kong LicenseA Scheme to Aid Construction of Left-Hand Sides of Axioms in Algebraic Specifications for Object-Oriented Program Testing  Huo Yan Chen, Lin Tan Department of Computer Science Jinan University Guangzhou, 510632, P.R. China tchy@jnu.edu.cn T.H. Tse Department of Computer Science The University of Hong Kong Pokfulam, Hong Kong thtse@cs.hku.hk  Abstract—In order to ensure reliability and quality, software systems must be tested. Testing object-oriented software is harder than testing procedure-oriented software. It involves four levels, namely the algorithmic level, class level, cluster level, and system level. We proposed a methodology TACCLE for class- and cluster- level testing. It includes an important algorithm GFT for generating fundamental equivalent pairs as class-level test cases based on axioms in a given algebraic specification for a given class. This formal methodology has many benefits. However, system analysts often find it difficult to construct axioms for algebraic specifications. In this paper, we propose a scheme to aid the construction of the left-hand sides of axioms. The scheme alleviates the difficulties of the system analysts and also helps them check the completeness, consistency, and independence of the axiom system. Keywords—testing; object-oriented; algebraic specification; axiom; prototype tool I.  INTRODUCTION  Object-oriented program, despite its popularity, it also poses challenges to software testers. The testing of object-oriented programs involves four levels, namely the algorithmic level, class level, cluster level, and system level [1]. Testing at the algorithmic and system levels is similar to that for traditional programs. However, testing at the class and cluster levels require new techniques. In [2, 3, 4], we proposed a methodology TACCLE for object-oriented class- and cluster-level testing. Class-level testing is more basic. It includes generating test cases, executing test cases, and determining whether the results of execution of test cases conform to requirements.  Given an algebraic specification of a class under test, we define a fundamental pair as two equivalent ground terms generated by replacing all the variables on both sides of an axiom in the specification with normal forms. We proposed an algorithm known as GFT, for Generating Finite number of fundamental pairs as Test cases [3]. Each fundamental pair corresponds to a pair of equivalent method sequences in an implementation. If two objects resulting from the executions of two method sequences corresponding to a fundamental pair are not observational equivalent, then a failure in the implementation of the class is found and reported. GFT is based on the axioms in a given algebraic specification for the class under test. It has many benefits. Practicing system analysts and testers often find it difficult to construct equational axioms for formal specifications. If a company uses semi-formal specifications, such as timing diagrams in the case of ASM Assembly Automation Ltd. [5], we can develop an automatic tool to transform the graphic specifications into algebraic specifications, keeping the latter internal to the testing tool and transparent to the user. In this technology-transfer example, the difficulty is relaxed by constructing the algebraic axioms from the timing diagrams via the concept of communicating finite-state machines. Paper [5] reports the details of this real-life experience. On the other hand, if a company uses informal specifications, in order to apply TACCLE to testing, analysts or testers need to manually construct axioms for the algebraic specifications from the informal counterpart. This paper proposes a scheme to help analysts and testers to construct the left-hand sides of axioms in algebraic spec-ifications for object-oriented program testing. The scheme alleviates the difficulties faced by analysts and also helps them check the completeness, consistency, and independence of the constructed axiom system. The remainder of this paper is organized as follows: In Section 2, related concepts are summarized. A proposition, which is useful for the scheme, is presented in Section 3. The detail of the scheme to help analysts or testers construct the left-hand sides of axioms is presented in Section 4. The implementation and experiments of a tool to aid the scheme is presented in Section 5. Finally, some discussions and the conclusion are given in Section 6. This research is supported by a Union Grant of Guangdong Province and National Natural Science Foundation of China (#U0775001), by a grant of the Guangdong Province Science Foundation (#7010116), and by a grant of the Youth Science Foundation of Jinan University (#51208035). Lin Tan is a master degree student supervised by Huo Yan Chen. 2008 International Conference on Computer Science and Software Engineering978-0-7695-3336-0/08 $25.00 © 2008 IEEEDOI 10.1109/CSSE.2008.600747Authorized licensed use limited to: The University of Hong Kong. Downloaded on June 10, 2009 at 22:44 from IEEE Xplore.  Restrictions apply.II. THE CONCEPTS Related basic concepts have been explained in detail in [2, 3]. They include algebraic specifications, axioms, terms, rewriting, normal forms, ground terms, canonical specifications, normally equivalent, creators, constructor, transformers, observers, and fundamental pairs of equivalent terms (or simply fundamental pairs).  The following concepts and strategies are new. Definition 1. Suppose a1, a2, …, ak are axioms in an algebraic specification of a given class. Consider a new axiom ak+1: t2 = t1. There are three cases:  (i) Term t2 cannot be rewritten by any axioms in {a1, a2, …, ak} (under the appropriate condition, if any); (ii) Term t2 can be rewritten to the normal form of term t1 by some axioms in {a1, a2, …, ak} (under the appropriate condition, if any). In this case, we say that ak+1 is dependent on {a1, a2, …, ak} or ak+1 is not independent of {a1, a2, …, ak}. (iii) Term t2 can be rewritten by some axioms in {a1, a2, …, ak} (under the appropriate condition, if any), but the resulting normal form is not the same as the normal form of term t1 by using axioms in {a1, a2, …, ak}. In this case, we say that ak+1 contradicts with {a1, a2, …, ak} or that ak+1 is inconsistent with {a1, a2, …, ak}.  Obviously, If ak+1 is dependent on {a1, a2, …, ak}, then adding ak+1 to {a1, a2, …, ak} does not affect the normal form of any term. In other words, it is redundant with respect to {a1, a2, …, ak}. Thus, we have Strategy 1. If ak+1 is dependent on {a1, a2, …, ak}, then we need not add ak+1 to {a1, a2, …, ak} when constructing an algebraic specification. On the other hand, it is also obvious that if ak+1 contradicts with {a1, a2, …, ak} for a canonical specification, then after adding ak+1 to {a1, a2, …, ak}, the specification will no longer be canonical. Hence, we have Strategy 2. For a canonical specification containing axioms a1, a2, …, ak, if ak+1 contradicts with {a1, a2, …, ak}, then we should not add ak+1 to {a1, a2, …, ak} when constructing the canonical specification. Definition 2. In case (i) of Definition 1, the new axiom ak+1 is not dependent on {a1, a2, …, ak} and does not contradict with {a1, a2, …, ak}. In this case, we say that ak+1 is independent of and consistent with {a1, a2, …, ak}. Definition 3. If every ai ∈ {a1, a2, …, ak, ak+1} is independent of and consistent with {a1, a2, …, ak, ak+1} \ {ai}, then we say that {a1, a2, …, ak, ak+1} has internal independence and consistency. III. THE PROPOSITION The following proposition is useful for setting up a scheme to help construct the left-hand sides of axioms in algebraic specifications for object-oriented program testing via TACCLE. Proposition 1. Suppose t0 is a sub-term of term t. If t0 appears as the left-hand side of an axiom (under an appropriate condition, if any) in an algebraic specification of a given class C, then t cannot appear as the left-hand side of another axiom (under the same condition, if any) in the algebraic specification of C.  Proof: Let t = t0.t1. Suppose there is an axiom ai: t0 = s0 and another axiom ak: t = s. We have  ai t = t0.t1 ⇒ s0.t1 If the term s0.t1 is equivalent to the term s, then the axiom ak is dependent on {…, ai, …}, so that ak is redundant and should be deleted. Otherwise, the axiom ak contradicts with {…, ai, …} and hence ak must also be deleted.  IV. THE SCHEME The CLA scheme to aid the Construction of Left-hand sides of Axioms in algebraic specifications for object-oriented program testing via TACCLE consists of the following steps: (1)  By interacting with the requirement analyst, for a given class, determine and input the set CR of creators, the set CT of constructors or transformers, and the set OB of observers. They may contain parameters as appropriate. (2)  Let PL denote the set of preliminary left-hand sides of axioms, and let PA denote the set of preliminary axioms (or “pre-axioms” for short). Set PL = ∅; set PA = ∅. (3)  For each cr ∈ CR do { For each ob ∈ OB do { Ask analyst to give a term (including condition) as the right-hand side of a pre-axiom ax with cr.ob as the left-hand side 1, and set PA = PA ∪ {ax}; If the condition of ax is not “always true”, then iterate the previous step to constructing multiple axioms with the same left-hand side as ax but with mutually exclusive conditions; } } (4)  For each cr∈CR do { For each ct∈CT do { Ask analyst whether cr.ct is made the left-hand side of a pre-axiom; 2 If yes, { Ask analyst to give the right-hand side (including condition) to construct a pre-axiom ax;                                                             1 Such as new.empty in axiom a1 of Example 1 in [3]. Some attributes, say empty and top, may have related semantics. Thus, we need to check the consistency of their corresponding preliminary axioms a1: new.empty = true and a5: new.top = NIL. However, such kinds of consistency cannot be checked by axiom rewriting, and hence we leave the checking to step (9). 2 Such as new.pop in axiom a3 of Example 1 in [3]. 748Authorized licensed use limited to: The University of Hong Kong. Downloaded on June 10, 2009 at 22:44 from IEEE Xplore.  Restrictions apply.If the condition of ax is not “always true”, then iterate the previous step to constructing multiple axioms with the same left-hand side as ax but with mutually exclusive conditions; Check whether ax is consistent with and independent of the set PA of pre-axioms constructed; If yes, { PA = PA ∪ {ax}; 3  For every previous pre-axiom ax0 that can be derived from ax and others, set PA = PA \ {ax0}  } Else, { Ask analyst to determine whether to submit another term as the right-hand side; If submitting another one, then construct another pre-axiom ax and repeat the above process; If no more submission, then PL = PL ∪ {cr.ct}; } }, Else, skip it and set PL = PL ∪ {cr.ct}; }; }; (5)  Take a variable A of object in the given class, and set PL = PL ∪ {A} and PL0 = ∅; 4  (6)  For each X ∈ PL do { For each ct ∈ CT do { Set X = X.ct; Ask analyst whether X is made the left-hand side of a pre-axiom; 5 If yes, { Ask for the right-hand side (including condition) to construct a pre-axiom ax; If the condition of ax is not “always true”, then iterate the previous step to constructing multiple axioms with the same left-hand side as ax but with mutually exclusive conditions;                                                            3 According to Proposition 1, we do not set PL = PL ∪ {cr.ct} here. This is an example of pruning. 4 PL is for this loop, and PL0 is for the next loop.  5 Such as S.push(N).pop in a4 of Example 1 in [3], and A.debit(N) in a13 of Example 2 in [6]. Check whether ax is consistent with and independent of the set PA of pre-axioms constructed; If yes, { PA = PA ∪ {ax}; 6  For every previous pre-axiom ax0 that can be derived from ax and others, set PA = PA \ {ax0}  } Else, { Ask analyst to determine whether to submit another term as the right-hand side; If submitting another one, then construct another pre-axiom ax and repeat the above process; If no more submission, then PL = PL ∪ {cr.ct}; } }; If not or if the disjunction of conditions of all axioms (with the same left-hand side as that of ax) is not “always true”, { For each ob∈OB do { Ask analyst whether X.ob is made the left-hand side of a pre-axiom; 7 If yes, { Remind analyst that the condition of the new pre-axiom must be mutually exclusive with that of the previous pre-axioms with X as the left-hand side; Ask for the right-hand side (including condition) to construct a pre-axiom ax; If the condition of ax is not “always true”, then iterate the previous step to constructing multiple axioms with the same left-hand side as ax but with mutually exclusive conditions; Check whether ax is consistent with and independent of the set PA of pre-axioms constructed; If yes, { PA = PA ∪ {ax};  For every previous pre-axiom ax0 that can be derived from ax and others, set PA = PA \ {ax0}  } Else, {                                                            6 According to Proposition 1, we do not set PL = PL ∪ {cr.ct} here. This is another example of pruning. 7 Such as S.push(N).empty in axiom a2 of Example 1 in [3]. 749Authorized licensed use limited to: The University of Hong Kong. Downloaded on June 10, 2009 at 22:44 from IEEE Xplore.  Restrictions apply.Ask analyst to determine whether to submit another term as the right-hand side; If submitting another one, then construct another pre-axiom ax and repeat the above process; // Note here that we do not set PL0 = PL0 ∪ {X.ob} when there is no more submission; } }; Else, skip it; }; Set PL0 = PL0 ∪ {X}; }; };  }; (7)  If PL0 = ∅, go to (9); (8)  Ask analyst whether it is the end of the construction of pre-axioms; If not, {PL = PL0; PL0 = ∅; go to (6);}; (9)  By interacting with analyst, convert the set PA of pre-axioms to the set RA of required axioms by selecting, checking, uniting, refining, changing the names of parameter variables, adding, or deleting, and so on. For axioms with left-hand sides that match one another, remind analyst that the conditions must be mutually exclusive. (10) Output the set RA of the required axioms of the given class C; End the scheme.         V. IMPLEMENTATION AND EXPERIMENTS We use Visual C++ 2005 under Microsoft Windows XP to implement a semi-automatic prototype tool for the CLA scheme. The tool uses dialog framework resources and control-widget resources to realize interaction with users. Each axiom is represented by a structure AxiomItem, defined as follows: struct AxiomItem { CString m_Left;  // left-hand side of the axiom CString m_Right;  // right-hand side of the axiom CString m_Co;  // condition of the axiom AxiomItem * next;  // pointer for linked list   }; The set of axioms in an algebraic specification is denoted by a linked list of AxiomItem structures. Experiments have been conducted on various case studies, including, for example, a class Book in a library system and a class SavAcct of savings accounts in a bank system. The work has been implemented by the second author. Details are not given in this paper because of page limitation. Readers may refer to his master thesis [6] for more information. VI. DISCUSSIONS AND CONCLUSION A finite number of fundamental pairs can be generated as test cases by algorithm GFT in [3], which is based on the axioms of a given algebraic specification for a given class under test. This testing approach has many advantages. However, system analysts often find it difficult to construct axioms for algebraic specifications. This paper presents a scheme, named CLA, to help analysts or testers construct the left-hand sides of axioms in algebraic specifications. The scheme alleviates the difficulties faced by analysts and also helps them check the completeness, consistency, and independence of the constructed axiom system. The CLA scheme is based on an analysis of the patterns of left-hand sides of axioms in algebraic specifications. It uses an enumeration technique with a pruning technique based on Proposition 1. The pruning technique reduces the number of loops in executing the scheme and enhances its efficiency greatly.  The implementation and experiments for a semi-automatic tool to aid the scheme is also described in this paper. In general, for a given class, the numbers of creators, constructors and transformers, and observers are small, and the number of loops in the CLA scheme is not large when the pruning technique is employed. Thus, the CLA scheme should be effective in requirements engineering. As future work, we would like to use Prolog to develop the semi-automatic tool. This will make it easier to implement the function to check whether a new pre-axiom is consistent with and independent of the set PA of pre-axioms constructed. REFERENCES  [1] M.D. Smith and D.J. Robson, “A framework for testing object-oriented programs,” Journal of Object-Oriented Programming, vol. 5, no. 3, pp. 45–53, 1992. [2] Huo Yan Chen, T.H. Tse, and T.Y. Chen, “TACCLE: a methodology for object-oriented software testing at the class and cluster levels,” ACM Transactions on Software Engineering and Methodology, vol. 10, no. 1, pp. 56–109, 2001. [3] Huo Yan Chen, T.H. Tse, F.T. Chan, and T.Y. Chen, “In black and white: an integrated approach to class-level testing of object-oriented programs,” ACM Transactions on Software Engineering and Methodology, vol. 7, no. 3, pp. 250–295, 1998. [4] Huo Yan Chen, T.H. Tse, and Y.T. Deng, “ROCS: an object-oriented class-level testing system based on the relevant observable contexts technique,” Information and Software Technology, vol. 42, no. 10, pp. 677–686, 2000. [5] T.H. Tse, F.C.M. Lau, W.K. Chan, P.C.K. Liu, and C.K.F. Luk, “Testing object-oriented industrial software without precise oracles or results,” Communications of the ACM, vol. 50, no. 8, pp. 78-85, 2007. [6] Lin Tan, The Design and Implementation of the Semi-automatic Aid Tool for Constructing Algebraic Specification, Master's Thesis, Department of Computer Science, Jinan University, Guangzhou, China, 2008. 750Authorized licensed use limited to: The University of Hong Kong. Downloaded on June 10, 2009 at 22:44 from IEEE Xplore.  Restrictions apply.

A scheme to aid construction of left-hand sides of axioms in algebraic specifications for object-oriented program testing

http://hub.hku.hk/bitstream/10722/54696/1/ASchemetoAid_construction.pdf

A scheme to aid construction of left-hand sides of axioms in algebraic specifications for object-oriented program testing

Abstract

Similar works

Full text

Available Versions

HKU Scholars Hub