Conformity Behavior of Dissimilar Methods for Object Oriented

K. LOUZAOUUI Conformity behavior of dissimilar methods for object oriented constraint programming 212 Conformity Behavior of Dissimilar Methods for Object Oriented Constraint Programming

Khadija Louzaoui Khalid Benlhachmi Department of Mathematics Department of Computer Sciences Faculty of Sciences, Ibn Tofail University Faculty of Sciences, Ibn Tofail University Kenitra, Morocco Kenitra, Morocco

Abstract—This paper presents an approach for testing the number of test cases is infinite, therefore, testing is very conformity of overridden and overriding methods using expensive. So, how to select the most proper set of test cases? inheritance principle. The first objective of this work is the In practice, various techniques are used for that, some of them reduction of the test sequences by using only one generation of are based on the specification of the program under test using test data. The second result is the conformity testing of methods precondition, postcondition and invariant constraints. In this even if they are not similar: Our approach shows how the similarity partitioning can be used for testing not the similarity way the specifications by constraints in an object oriented behavior between methods but the conformity behavior of paradigm can be specified by formal languages as OCL [3] and subclasses for an object oriented model. JML [4], and are used for generating test data from formal specifications [5]. This software verification by constraints can In this work we use a mathematical modeling such as domain help for creating a mathematical modeling and building the partitioning and states graph for testing the conformity of parts of different classes of errors (equivalence partitioning). methods during inheritance operation. That is why our approach We present an approach for testing the conformity of an specifies all cases of conformity behaviors for similar and implementation from its specification [6,7] in object oriented dissimilar methods. programming. The main goal is the conformity testing of the (1) (2) Index Terms—Specification, conformity testing, robustness system :( overridden method: m , overriding method: m ) in testing, valid data, invalid data, test data generation, inheritance, inheritance operation. Indeed, the first objective is the constraint resolution. reduction of the test sequences by using only one generation of test data. The second result is the conformity testing of methods even if they are not similar [8]; The key idea is using I. INTRODUCTION directly similarity partitioning [9] for testing not the similarity Process of creating a program consists of defining a behavior between m(1) and m(2) but the conformity behavior problem, designing a program, building and analyzing [10,11] of m(1) and m(2). performances of a program. Software testing is a component of In this context, this paper introduces an optimizing this last phase, and is a way for checking if a program for approach to minimize the test sequences used for testing the specified inputs gives correctly and expected results. Software conformity of an overriding method in object oriented models. testing can be defined that as: “A process of executing a The main idea of this work is the use of a technique that program with the goal of finding errors” [1]. The goal of generates test data by exploiting the similarity partitioning. testing is systematic detection of different classes of errors by Indeed, it is important to use a mathematical modeling such as using a model of the program under test or analyzing the domain partitioning and state graph for testing the conformity internal structure of this program. So software can be tested in of methods during inheritance operation. That is why our two ways: testing software with the knowledge of the internal approach specifies all cases of conformity behavior for similar structure and coding inside the program (white box testing), the and dissimilar methods. second method is a testing based on output requirements and Most works have studied the problem of relating types and without any knowledge of the internal structure or coding in subtypes with behavioral specification in an object-oriented the program ( black box testing). paradigm. These proposed works show how the contracts are Indeed, testing means that one inspects behavior of a inherited during method overriding and how the testing process program on a finite set of test cases (a set of inputs, execution can use the formal specification. In [6,7], we have presented preconditions, and expected outcomes developed for a the definition of a formal model of constraint, illustrating the particular objective, such as to exercise a particular program relationship between preconditions, postconditions and path or to verify compliance with a specific requirement [2]) invariants of methods, and we have formalized a generic for which the evaluated inputs always exist. Theoretically, the constraint of a given individual method of class that contains all constraints into a single logical predicate. The given model

Revue Méditerranéenne des Télécommunications Vol. 5, N° 2, June 2015 Mediterranean Telecommunication Journal K. LOUZAOUUI Conformity behavior of dissimilar methods for object oriented constraint programming 213 translates algebraically the contract between the user and the logical property of the pair (x,o) (x is the vector of parameters called method. (x=(x1 ,x2 ,…, xn)) and o is the receiver object) such that: In [8], we have developed a basic model for the concept of HxoPxoEI(,) :(,)[Q(x, o)Inv(o)], (x, o) methods similarity, the test is based only on a random c generation of input data. In [9], we have generalized the basic Where Ic is the set of instances of the class C and E the set of input vectors of m. model of similarity using analysis of partition and formal proof. In [12], the authors propose a randomly generation of Class C test data from a JML specification of class objects. They classify the methods and constructors according to their m (…) P , Q , Inv signature (basic, extended constructors, mutator, and observer) and for each type of individual method of class, a generation of {…} test data is proposed. In [13], the paper describes specially the Precondition Postcondition Invariant of C features for specifying methods, related to inheritance specification; it shows how the specification of inheritance in JML forces behavioral sub-typing. Fig. 1. Constraints of the method m( ) In [14], the authors treat the problem of types and subtypes Indeed, the invocation of a method m is generally done by with behavioral specifications in object-oriented world. They reference to an object o and consequently, m is identified by present a way of specification types that makes it convenient to the couple (x,o) . The logical implication in the proposed define the subtype relation. They also define a new notion of formula means that: each call of method with (x,o) satisfying the subtype relation based on the semantic properties of the the precondition P and the invariant before the call, (x,o) must subtype and super-type. In [15], they examine various notions necessarily satisfy the post-condition Q and the invariant Inv of behavioral sub-typing proposed in the literature for objects after the call. In the context of this work, we assume that the in component-based systems, where reasoning about the events object which invokes the method under test is valid (satisfying that a component can raise is important. the invariant of its class), thus, the objects used at the input of The work presented in this paper can reduce the number of the method under test are generated from a valid constructor. test cases by adapting the similarity partitioning [8,9] to the This justifies the absence of predicate Inv of the object o before coverage of conformity behaviors of the system (m(1), m(2)). the call to m in the formula H (Figure 2). Indeed only one generation of the test data is necessary to deduce conformity of overridden and overriding methods. m In this work we propose a conformity testing of methods even Input: P(x,o) Output: Q(x,o) Inv(o) if they are not similar and we use a graph of states for modeling the evolution of the system (m(1), m(2)) independently from the test data generation (In [10] we generate data for testing the similarity between methods, and then we generate Fig. 2. Simplified specification of a method m( ) data for testing the conformity of the original method m(1): if the methods are similar we can deduce the conformity of III. CONFORMITY TESTING AND SIMILARITY MODEL IN overriding methods; if they are not similar we are unable to INHERITANCE progress in the test process). This paper is organized as follows: in section 2 we present A. Conformity constraints the formal model of constraints based on methods The formal model of test proposed in [6,7] defines the specification, in section 3 we define the theoretical aspects of notion of method validity in a basic class and constitutes a way the conformity test process, and we show why the model of to generate test data for conformity. In a conformity test, the similarity concept is necessary, in section 4 we present how the input data must satisfy the precondition of the method under similarity partitioning can be used to define the conformity test. In this context, we are particularly interested in valid input behaviors and to generate test data during inheritance values (i.e. the pairs (x,o) that satisfy the precondition P). operation. The section 5 proposes a mathematical modeling The conformity test for a method means that if a with graph of states for the system (overridden method, precondition is satisfied at the input, the postcondition and the overriding method). Finally, in section 6 we describe our invariant must be satisfied at the output. approach with an example of conformity testing for an object In [6,7] we have defined the notion of a method conformity oriented model. when the method m always meet its constraint H:

(x , o )  E  Ic : H ( x , o )  1 II. FORMAL MODEL OF CONSTRAINT In other words:

In [6,7] we have presented the definition of a formal model  A method m is valid if: (,)x o  E  I c : If (x,o) satisfies of constraint, illustrating the relationship between the the precondition P then this (x,o) must satisfy the precondition P, the postcondition Q of a method m and the postcondition Q and the invariant Inv. invariant Inv of the class C (Figure1): this constraint H is a

(1)  A method m is invalid ( (,):(,)0xoEIHxo ) if : behavior as its original version m in the superclass relatively c to their common specification (P(1),Q(1),Inv(1)). Indeed, in this

(,):(,)(,)()xoEIPxoQxoIn voc       approach the implementation in the subclass must override the implementation in the super class by providing a method m(2) In [6,7], we have tested the conformity of methods in a that is similar to m(1). basic class without taking into account the inheritance This comparison can define a certain degree of relationship: the model of test generates random data at the compatibility that will make it possible to establish a logical input of a method using elements of the valid domain which relationship between the mathematical model of the basic satisfy the precondition of the method under test. This test method and the model of the overriding method in a subclass. stops when the constraint H becomes False (H(x,o)=0 )or when Consequently, in figure 4 we must have for each pair (x,o) of the maximum threshold of the test is reached with H satisfied. input : a’=a ,b’=b with a’, a ,b’, b are Boolean values. B. Constraints Propagation

We consider a method m of a class C2 which inherits from Q(1) (x,o) = a (1) the class C1 such that m overrides a method of C1. The original m Inv(1) (o) = b P(1) (x,o) method and its overriding method in the subclass C2 will be (1) (2) denoted respectively by m ,m (Figure 3). Q(1) (x,o) = a’(a’=a) (1) (1) (1) m(2)  (P ,Q , Inv ) denote respectively the precondition, Inv(1) (o) = b’(b’=b) the postcondition of the method m(1) ,and the invariant

of C1 (Figure 3). (2) (2) (2) Fig. 4. Condition of similarity  (P ,Q ,Inv ) denote respectively the precondition, (2) the postcondition of the method m ,and the invariant For each input data (x,o) of the method m(2), we associate a of C2 (Figure 3). square matrix of size 2×2 with Boolean values (0 or 1) which  (P2’,Q2’,Inv2’) denote respectively the specific represents the four possible values for the quadruplet : (a ,b, a’, precondition, postcondition of the overriding method b’) (Figure 4): (2) m , and the specific invariant of the class C2 . SimilarityEIM:0 ,1C 22   The results of this paragraph are based on the works of Liskov, Wing [16] and Meyer [17] who have studied the ab (,x o)Sim ilarity(x, o)  problem relating to types and subtypes with behavioral ab'' specification in an object-oriented paradigm. Indeed, as a result The first row (a,b) of the matrix corresponds to the original of the Liskov Substitution Principle (LSP), we have (Figure 3): method, and the second row (a’,b’) corresponds to the ( 2 )(1 )' PPP () (1) 2 overriding method (figure 4). (1) (2) ( 2 )(1 )' We deduce that m and m are similar only if: for each QQQ () (2) 2 input data (x,o) the two rows of the matrix Similarity (x,o) are ( 2 )(1 )' In vIn vIn v () (3 ) 2 identical : (a, b) = (a’,b’). The problem which arises is that the conformity test of m(2) (1) (2) Class C1 requires similarity of behaviors: if the methods m and m are not similar we are unable to progress in the test process. m(1) : (P(1),Q(1),Inv(1)) In the approach of this paper we show that the similarity of behavior is not obligatory for verifying conformity in sub Class C2 classes. So the conformity of dissimilar methods can be tested. m(2) : ( P(2), Q(2), Inv(2) ) The purpose of the next section is to generalize the model of [9,10] in order to test the conformity of an overridden and overriding methods ( m(1) and m(2)) by modifying the criteria of

(1) (1) (1) similarity partitioning (coverage of conformity behaviors). P ∨P’2 Q ∧ Q’2 Inv ∧ Inv’2

IV. CONFORMITY BEHAVIORS AND TEST DATA GENERATION IN (1) (2) Fig. 3. Constraints of m and m INHERITANCE In our approach, the specification (P(2) ,Q(2) ,Inv(2)) of m(2) is constituted by : A. Similarity partitioning and analysis of conformity behaviors (1) (1) (1)  The inherited specification (P ,Q , Inv ) from the  Definition of conformity behaviors class C1. In [9], we have used the similarity partitioning for (2)  The specific specification (P2’,Q2’,Inv2’) of m in the generating some behaviors oriented to the coverage of the first class C2. objective of similarity which considers verification of the C. Similarity model similarity behavior as main objective of test (goal is oriented similarity) in this context we have identified several behaviors We have proposed in [8,9] the definition of similarity that converge towards a checking of similarity between the (2) concept for assuring if the overriding method m has the same methods.

Revue Méditerranéenne des Télécommunications Vol. 5, N° 2, June 2015 Mediterranean Telecommunication Journal K. LOUZAOUUI Conformity behavior of dissimilar methods for object oriented constraint programming 215 In this paper we use the same partitioning but in another context which covers the second objective of similarity test  Conformity testing of methods in inheritance (goal is oriented conformity), it means that the similarity The goal of this section is the conformity testing of the checking is considered as an intermediate step to check the overridden and overriding methods in inheritance by using the conformity of overriding methods in derived classes. Indeed behavioral analysis of similarity partitioning. we seek in this section to define behaviors which describe the The function of conformity (Figure 5) represents the notion of conformity for methods m(1) and m(2) (Table 1). relation between a set of similarity parts and the set of possible behaviors of the system (m(1),m(2)).This function can help to TABLE I. CONFORMITY BEHAVIORS OF METHODS (m(1), m(2)) implement an algorithm of conformity test of the methods m(1) and m(2) based on the similarity partitioning (Figure 6). Method Behavior Meaning We consider that the objects are generated from a valid  m(1) is in conformity with the c 1 specification (P(1) Q(1) Inv(1)) constructor of the subclass, and that the sets X, Y, Z and T are m(1)  m(1) is not in conformity with initialized to ∅ at each execution of the algorithm. The constant Nc 1 the specification (P(1) Q(1) Inv(1)) N is the test threshold (Figure 6).  m(2) is in conformity with the c 2.1 specification (P(1) Q(1) Inv(1))

 m(2) is in conformity with the 1. do{ c m(2) 2.2 specific specification (P’ ,Q’ 2. do{ 2 2 (2) ,Inv’ ) 3. for (xi in m parameter){xi=generate(Ei);} 2  m(2) is not in conformity with 4. x = (x1,x2,…,xn); Nc 2 the specification (P(2) Q(2) Inv(2)) 5. o = generate_object(C2); 6. }while (!P(1)(x,o)); 7. (x’,o’)=copy(x,o);  Analysis of similarity partitioning 8. invock’’o.m(1)(x)’’; The goal of this approach is to test the conformity of the 9. a=Q(1)(x,o);b=Inv(1)(o); (x,o)=copy(x’,o’); (1) (2) 10. invock’’o.m(2)(x)’’; system (m ,m ) using the similarity partitioning. This means (1) (1) (1) 11. a’=Q (x,o);b’=Inv (o); (x,o)=copy(x’,o’); that the conformity of the method m is not tested before the 12. …. creation of the derived class C2, which requires exploiting the 13. if ((a,b)=(1,1)&&(a’,b’)=(1,1)) similarity partition for extracting test sequences allowing both 14. X.add(x,o); to verify the conformity of m(1)and m(2). 15. elseif ((a,b)=(1,1)&&( a’,b’) ∊{(1,0),(0,1),(0,0)}) In this context, we must be interested in the behavior of the 16. Z.add(x,o); (1) (2) 17. elseif ((a’,b’)=(1,1)&&( a,b) ∊{(1,0),(0,1),(0,0)}) system (m ,m ). This defines six behaviors: (c1,c2.1), (Nc1, 18. T.add(x,o); Nc2), (c1, Nc2), (Nc1, c2.1), (c1, c2.2), (Nc1,c2.2). 19. else This leads to 4 parts X, Y, Z and T which represent the 20. Y.add(x,o); executable behaviors of conformity (Figure 5): 21. }while ( X.size( ) < N && Y.isEmpty( ) && Z.size( ) < N && T.size( ) < N ); 11 Xx oEI , / Similarity(x,o)=   c 2   11  Fig. 6. Algorithm of conformity testing

1 0   0 1   0 0         (1) (2) 0 0   0 0   0 0  V. GRAPH OF STATES FOR THE SYSTEM (m ,m )   0 0   0 0   0 1   Y x, o  E  I / Similarity(x,o)        In this section we propose a mathematical modeling of the c 2 1 0 0 1 1 0       (1) (2) conformity states of a system (m ,m ) and the transition 1 0   1 0   0 1         between states by using a graph of states. Indeed for any 0 1 1 0 0 1       system of methods (m(1),m(2)) we can associate a graph G that  1  11  111 describes all conformity states: each vertex of G represents a Zx oEI , / Similarity(x,o),,    c 2    (1) (2)  1 00  100  state of the system (m ,m ) and each edge between two vertices represents a transition from the first state to the second  1  00  100 Tx oEI , / Similarity(x,o),,   c 2    state.  1  11  111  A. Graph of executable States Definition (c1, c2.1) X A state of conformity for the system (m(1),m(2)) is a value of

Y (Nc1, Nc2) the quadruplet (x, y, z, t), where x = card (X), y = card (Y), z = card (Z) and t = card (T) are respectively the sizes of the parts Z (c1, Nc2) X, Y, Z and T in the current iteration of the algorithm of test T (Nc1, c2.1) data generation. We denote by x , y , z and t respectively the sizes of the 0 0 0 0 sets X, Y, Z and T at the end of execution. We define 3 cases for each part X, Y, Z and T: Fig. 5. Classes of conformity behaviors

 X (respectively Y, Z or T) is saturated if the size of X = contradiction with the behavior (c1, c2.1) (Size (Z)≠0) and size N (N is the test threshold). We set x = N. (T) ≠ 0), these test sequences induce behaviors (c1, Nc2) and  X (respectively Y, Z or T) is not empty if the size of X (Nc1, c2.1). ≠0. We set x = 1. The contradictory and executable States show that the test  X (respectively Y, Z or T) is empty if the size of X = 0. threshold N does not cover all system behaviors. These states We set x = 0. can limit the flaws and inadequate of test threshold. In the context of this definition there are 81 possible states This is an important way to correct the errors due to choice of for the quadruplet (x, y, z, t) where x, y, z and t are in {0,1, N}. threshold N. We can distinguish two main types of states: B. Examples of graph states 1) Not contradictory and executable States:  State1: The family of the following states (x0,1,z0,t0) (0,0,0,0) (N,0,0,0) where x0,z0 and t0 are in {0,1} is called State1. This state characterizes the conformity behavior (Nc1,Nc2) 0 k 4 for the system (m(1),m(2)) (Figure 5 and 6). (1,0,0,0) (c1,c2.1)  State2: The family of the following states (x0,0,N,0)

where x0 in {0,1} is called State2. This state characterizes the conformity behavior (c1,Nc2) for the Fig. 7. GraphVI. with 3 states system (m(1),m(2)) (Figure 5 and 6).  State3: The family of the following states (x0,0,0,N) where x0 in {0,1} is called State3. This state (0,0,0,0) (1,0,1,0) (N,0,1,1) characterizes the conformity behavior (Nc1,c2.1) for the i 0 e3 system (m(1),m(2)) (Figure 5 and 6).

 State4: The state (N,0,0,0) is called State4. This state (Nc1,Nc2) s characterizes the conformity behavior (c1,c2.1) for the (1,0,1,1) (1) (2) system (m ,m ) (Figure 5 and 6). k These 4 states are final states: they correspond to the end of (1,0,0,0) the algorithm execution for a test data generation. These states are represented by the sinks vertices in the graph of states. Fig. 8. Graph with 5 states We define in the following some intermediate states that VII. REFERENCES characterize any iterations of the algorithm: The source vertex of the graph characterizes the initial state and the sink vertex characterizes the final state of the system TABLE II. INTERMEDIATE STATES OF (m(1),m(2)) (m(1),m(2)). State 0 : (0,0,0,0) State p : (0,0,0,1) The state graph in figure 7 consists of three vertices: The State i : (1,0,1,0) State q : (0,0,1,0) source vertex 0 which represents the initial state of the system (1) (2) State j : (1,0,0,1) State r : (0,0,1,1) (m ,m ) where all parts X,Y,Z and T are empty. State k : (1,0,0,0) State s : (1,0,1,1) The vertex k which represents the intermediate state k of (1) (2) the system (m ,m ) where the part X is not empty 2) Contradictory and executable States (k=(1,0,0,0)). The system can maintain this state for several iterations.  State e1: The family of the following states (x0,0,N,1) The sink vertex 4 which represents the final state 4 of the where x0 in {0,1} is called State e1. system (m(1),m(2)) where the part X is saturated  State e : The family of the following states (x ,0,1,N) 2 0 (State4=(N,0,0,0)). This state is essential and indicates the final where x in {0,1} is called State e . 0 2 behavior of conformity (c , c ) for the system (m(1),m(2)).  State e : The state (N,0,1,1) is called State e . 1 2.1 3 3 The state graph in figure 8 consists of 5 vertices: The states e , e and e characterize the conformity behavior 1 2 3  The source vertex 0 which represents the initial state of (Nc ,Nc ) for the system (m(1),m(2)) (Figure 5 and 6). 1 2 the system (m(1),m(2)).  State f : The state (N,0,0,1) is called State f . This state 1 1  The vertex k which represents the intermediate state characterizes the conformity behavior (Nc ,c ) for the 1 2.1 k=(1,0,0,0) of the system (m(1),m(2)). system (m(1),m(2)) (Figure 5 and 6).  The vertex i which represents the intermediate state  State f : The state (N,0,1,0) is called State f . This state 2 2 i=(1,0,1,0) of the system (m(1),m(2)) where the part Z is characterizes the conformity behavior (c ,Nc ) for the 1 2 not empty. The system can maintain this state for system (m(1),m(2)) (Figure 5 and 6). several iterations. The states ei and fi are inconsistent with the principle of the constant N of test limit but they are possible and executable by  The vertex s which represents the intermediate state s=(1,0,1,1) of the system (m(1),m(2)) where the part T the algorithm of test data generation. For example, the state e3 has become not empty. The system can maintain this = (N,0,1,1) indicates that the behavior (c1, c2.1) is dominant (size (X)=N) but there are some test sequences which are in state for several iterations.

 The sink vertex e3 which represents a final state of the system (m(1),m(2)) where the part X is saturated, Z and T P(2)(x,o) : P(1)(x,o) are not empty (e3=(N,0,1,1)). This state is essential and (2) indicates the final behavior of conformity (Nc1, Nc2) (2) Q (x,o): [(balance(o(a)) = (1) (2) Withdraw : for the system (m ,m ). The state e3 can strengthen (balance(o(b)) - x1)) ∨ (balance(o(a)) = (P(2)⇒(Q(2) ⋀ Inv(2))) the threshold N of test (N is insufficient in this (balance(o(b)) - (1+InterestRate)× x1))] contradictory case). Inv(2)(o): (balance(o) ≥ 0) ⋀ VI. EVALUATION (0 < InterestRate (o) ≤ 0.3) We illustrate this approach with an example of conformity test of methods withdraw(1) and withdraw(2) defined in classes Fig. 12. Specification of withdraw(2) Account1 and Account2 (figure 9 and 10). The test data generation of methods (withdraw(1), withdraw(2)) is based on the similarity partitioning by executing 1. class Account1 the conformity test algorithm (figure 6). 2. { Table3 illustrates an example of random generation in the 3. protected double bal; /*bal is the account balance*/ following conditions: 4. public Account1(double x1){ 5. this.bal=x1;}  The parameter x1 and the account balance (the field: bal) 6. public Account1 (Account x1){…} are generated in the interval ]-200,200 [.The threshold of 7. … test N (The maximum size of a part): N=100. 8. public void withdraw (int x1){  The parts X, Y, Z and T are initialized to ∅ for each 9. this.bal=this.bal - x1;} 10. } execution of the algorithm.

Fig. 9. Method withdraw (1) of Account1 TABLE III. TEST DATA GENERATION

Iteration x O Size(X) Size(Y) Size(Z) Size(T) 1. class Account2 extends Account1 1 2. { 1 105 Account2(146,0.02) 1 0 0 0 3. private double InterestRate; 2 37 Account2(87,0.13) 2 0 0 0 4. public Account2(double x1,double x2){ 3 133 Account2(141,0.16) 2 0 1 0 5. super(x1); 4 52 Account2(61,0.25) 2 0 2 0 6. this.InterestRate = x2; 5 Account2(110,0.12) 2 0 3 0 7. … } … … … … … … … 8. public void withdraw (int x1){ 42 84 Account2(89,0.09) 2 0 40 0 9. super.withdraw (x1); 43 73 Account2(93,0.21) 3 0 40 0 10. if (x1>bal) 44 67 Account2(71,0.18) 3 0 41 0 11. this.bal=this.bal – (this.InterestRate)*x1; … … … … … … … 12. InterestRate=InterestRate /2; 80 89 Account2(92,0.13) 3 0 77 0 13. } 81 141 Account2(188,0.17) 4 0 77 0 14. } 82 115 Account2(134,0.22) 4 0 78 0 … … … … … … … (2) Fig. 10. Method withdraw of Account2 101 147 Account2(163,0.26) 4 0 97 0 The constraints H(1) and H(2) of the methods withdraw(1) and 102 74 Account2(157,0.1) 5 0 97 0 withdraw(2) in an algebric specification are illustrated in figures 103 81 Account2(88,0.22) 5 0 98 0 104 107 Account2(115,0.14) 5 0 99 0 11 and 12 (x = x1, o(a) et o(b) are respectively the object o after 105 49 Account2(68,0.17) 6 0 99 0 (State_after) and before (State_before) the method call) : 106 165 Account2(183,0.25) 6 0 100 0

The state graph of the system (withdraw(1), withdraw(2)) is P(1)(x,o): ( 0 ≤ x ≤ balance(o)) as follows (figure 13):

(1) Withdraw : (1) Q (x,o): (balance(o(a) ) ≤ balance(o(b) )) (0,0,0,0) 102 edges (P(1)⇒(Q(1)⋀ Inv(1)))

0 i Inv(1)(o): (balance(o) ≥ 0)

(1,0,1,0) 2 Fig. 11. Specification of withdraw(1) (1,0,N,0) k

(1,0,0,0)

Fig. 13. State graph of (withdraw(1), withdraw(2))

Revue Méditerranéenne des Télécommunications Vol. 5, N° 2, June 2015 Mediterranean Telecommunication Journal K. LOUZAOUUI Conformity behavior of dissimilar methods for object oriented constraint programming 218 Proceedings of the ECOOP'2002 Work-shop on Integration and Using another generation where the test threshold is 1000 Transformation of UML models (WITUML'2002), 2002. (10.N) we will have the same state graph (independence of the [6] Khalid Benlhachmi, and M.Benattou, ”Génération de Données graph). We note in this example that the system (withdraw(1), de Test de Conformité à partir d’une Spécification Formelle par withdraw(2)) changes from the initial state 0 to the intermediate Analyse des Partitions et Classification”, In Proceedings of the state k = (1,0,0,0): The system maintains this state for one International Workshop on information technologies and communication (WOTIC’11), Octobre 13-15 (2011), iteration and then is moved from the state k to the intermediate Casablanca, Morocco. state i = (1,0,1,0). (1) (2) [7] Khalid Benlhachmi, and M.Benattou, and Jean-louis The system (withdraw , withdraw ) maintains the state Lanet.“Génération de Données de Test Sécurisé à partir d’une i = (1,0,1,0) for 102 iterations. In the end the system goes to Spécification Formelle par Analyse des Partitions et the final state: State2 = (1,0, N, 0). Classification”. In Proceedings of the International Conference In the sink vertex the system (withdraw(1), withdraw(2)) has on Network Architectures and Information Systems Security (1) the behavior (c1, Nc2). Therefore, the method withdraw (SAR-SSI 2011) ,May 18-21,2011,La rochelle ,France. Pages conforms to its specification (P(1),Q(1),Inv(1)) and the overriding 143-150. method withdraw(2) does not meet the same specification [8] Khalid Benlhachmi, and M.Benattou. “A Formal Model of (P(1),Q(1),Inv(1)). Similarity Testing for Inheritance in Object-Oriented Software”. Finally it is possible to conclude that the overriding method In Proceedings of the 2012 edition of the IEEE International withdraw(2) does not meet its specification (P(2),Q(2),Inv(2)). Conference (CIST’2012), October 24-26,2012, Fez, Morocco. Pages 38-42. VII. CONCLUSION [9] Khalid Benlhachmi, and M.Benattou. “Similar Behaviors and Conformity Testing in Inheritance for an Object Oriented Model This paper introduces an approach to reduce the test ”, In the International Journal on Computer Science and sequences used for testing the conformity of an overriding Information Systems, Vol 9, No 1, (2014). Pages 30-42. method during inheritance operation in object oriented models. [10] Khalid Benlhachmi, and M.Benattou, “A Formal Model of The key idea of this work is the use of a technique that Conformity Testing of Inheritance for Object Oriented generates test data by exploiting the similarity partitioning. Constraint Programming”, In the International Journal of Indeed, the main result of this work is the conformity Software Engineering and Its Applications, Vol 7, No 5, verification of similar and dissimilar methods using similarity September (2013). Pages 209-220. partitioning. [11] Khalid Benlhachmi, and M.Benattou, “A Formal Model of We present firstly the conformity behaviors of overridden Conformity and Security Testing of Inheritance for Object and overriding methods, and we show how the use of existing Oriented Constraint Programming”, In Journal of Information similarity partitioning can make the generation of the test data Security, Vol 4, No 2, April (2013). Pages 113-123. during inheritance less expensive. Secondly, we present how it [12] Yoonsik Cheon and Carlos E. Rubio-Medrano. “Random Test is possible to exploit the graph of states for testing the Data Generation for Java Classes Annotated with JML conformity behaviors in subclasses. Specifications”, In Proceedings of the 2007 International Our future works are oriented to develop and generalize the Conference on Software Engineering Research and Practice, Volume II, June 25-28, 2007, Las Vegas, Nevada, pages 385- formal model of conformity as defined in this paper for 392 introduce the concept of methods robustness in inheritance [13] Gary T.Leavens, “JML’s Rich,Inherited Specification for based on the partition of invalid domains. Behavioral Subtypes”, Department of Computer Science Iowa State University , August 11,2006. VIII. REFERENCES [14] Barbara H. Liskov and J. M. Wing , “A behavioral notion of subtyping”, MIT Laboratory for Computer Science, Carnegie [1] Guide to the “Software Engineering Body of Knowledge, Mellon University, ACM Transactions on Programming Swebok” – A project of the IEEE Computer Society Languages and Systems,Vol 16. No 6, November 1994, Pages Professional Practices Committee, 2004. 1811-1841. [2] IEEE, “IEEE Standard Glossary of Software Engineering [15] Gary T.Leavens , Krishna Kishore Dhara , “Concepts of Terminology” (IEEE Std 610.12-1990), Los Alamitos, CA: Behavioral Subtyping and a Sketch of their Extension to IEEE Computer Society Press, 1990. Component-Based Systems”, In G. T. Leavens and M. [3] B. K. Aichernig and P. A. P. Salas. “Test case generation by Sitaraman, editors, Foundations of Component-Based Systems OCL mutation and constraint solving”, In Proceedings of the ,2000. International Conference on Quality Software, Melbourne, [16] Liskov, B. H. and J. Wing.“Behavioral subtyping using Australia, September 19-20, 2005, pages 64–71, 2005. invariants and constraints”, Technical Report CMU CS-99-156, [4] F. Bouquet, F. Dadeau, B. Legeard, and M. Utting. “Symbolic School of Computer Science, Carnegie Mellon University, July animation of JML specifications”, In International Conference 1999. on Formal Methods, volume 3582 of LNCS, pages 75– 90. [17] Meyer, B. “Object-oriented Software Construction”. Prentice Springer-Verlag, July 2005. Hall, 1988. [5] Mohammed Benattou, Jean-Michel Bruel, and Nabil Hameurlain. “Generating Test Data from OCL Specification”, In

Revue Méditerranéenne des Télécommunications Vol. 5, N° 2, June 2015 Mediterranean Telecommunication Journal