Methodological Aspects of an Approach for Verification of Object-Oriented Programs

Magdalina Todorova Faculty of Mathematics and Informatics,

Sofia University “St. Kl. Ohridski” Sofia, Bulgaria

magda@fmi.uni-sofia.bg

Abstract—Generalized nets (GN) are created as a tool for modeling and controlling real processes. The mathematical tools which GNs have make them an effective and convenient instrument for software modeling. Models of software systems can be created by means of GN; specifications of properties, connections between software modules, relations between classes and member functions of classes can be defined; properties of software systems can be proven. The paper describes an application of the GN for building models of programs, for defining specifications, describing properties and relationships between program units, for verification of object-oriented programs (OOP). An approach for verification of OOP is presented from methodological point of view. The approach is intended for research and educational purposes.

Keywords–generalized nets; modeling; object-oriented programming; verification

I. INTRODUCTION The verification and validation of program properties are

among the most important activities associated with the implementation of quality software. In recent years, intensive research has been widely conducted to develop approaches and environments for software modeling, verification and validation, which to be implemented in the software industry, as well as in training in software engineering [1, 2, 3, 4, 5, 6, 7, 8, 9 and 10]. The analysis of teaching programming effectiveness in Bulgaria, in particular in one of the most widely used – object-oriented [11, 12, 13], shows the necessity of developing educational tools that increase its efficiency. The training in application of formal methods for construction of correct software starting from the earliest courses on programming languages and software engineering, combined with creation of automated tools to support the learning process [14], are a step towards enhancing the effectiveness of the training in programming.

In the paper, an approach for verification of OOP [15] is described from methodological aspect. The approach applies the means of GN to: build models of the OOP functions to be verified; define the specifications on which to perform the verification; implement the algorithm for consistency checking. The proposed approach is suitable for teaching programming to students, starting from the beginning undergraduate courses

and continuing in master's programs in computer science and software engineering.

II. GENERALIZED NETS This section provides some basic information about

generalized nets. Their main components are the transitions. A transition of a GN is graphically presented as in Fig. 1.

Figure 1. Transition of GN with m input and n output places.

A. Definition of transition Every transition is described by a seven-tuple [16, 17]

Z = <L', L'', t1, t2, r, M, δ>,

where: • L' = {l1', l2', ..., lm'} and L'' = {l1'', l2'', ..., ln''} are

finite, non-empty sets of places. They are called respectively input and output places of the transition.

• t1 and t2 are the current time-moment of the transition’s activation and the current value of the duration of its active state;

• r is the transition condition which determines which tokens will transfer from the transition inputs to transition outputs. It has the form of an indexed matrix (IM)

]n,1[j];m,1[ij,i }{ ∈∈= rr

ri,j is a predicate which expresses the transfer condition from i-th input place to the j-th output place of the transition;

• M is an IM which determines the capacities of transition arcs and has the form

]n,1[j];m,1[ij,i }{ ∈∈= mM

mi,j ≥ 0 is a natural number or ∞, and sets the capacity of the arc from the i-th input place to the j-th output place;

• δ is an object having a form similar to a Boolean expression. It is called transition type. When the value of a transition type (calculated as a Boolean expression) is “true”, the transition can be activated, otherwise it cannot.

B. Definition of a generalized net A generalized net [16, 17] is ordered four-tuple

E = <<A, πA, πL, c, f, θ1, θ2>, <K, πK, θK>, <T, t0, t*>, <X, Φ, b>>,

where: - A is a set of transitions; - πA, πL and c are functions, defining the priorities of

the transitions, the priorities of the places and the capacities of the places, respectively;

- f is function that calculates the truth values of the predicates of the transition conditions;

- θ1 and θ2 are functions, which define the next time- moment for which a given transition can be activated, and the duration of the active state of a given transition, respectively;

- K is a set of GN tokens; - πK and θK are functions, which define the priorities of

the tokens and the time-moment when a given token can enter the net;

- T, t0 and t* are quantityes, which define the time-moment when the GN starts functioning, the elementary time-step, and the duration of the GN functioning;

- X is a set of all initial characteristics that the tokens can receive when they enter the net;

- Φ is a characteristic function that defines new characteristics to every token when it makes a transfer from an input to an output place of a given transition;

- b is a function, which defines the maximum number of characteristics a given token can receive.

The above definitions are not fully formalized. This

enables each researcher to define net components in a manner

consistent with the subject area that is subjected to modeling. The description of GN-models of specifications and object-oriented programs may not contain all components of the net. Algorithms for implementing the transition and GN are described in [16, 17].

III. AN APPROACH FOR VERIFICATION OF OBJECT-ORIENTED PROGRAMS

In order to ensure clarity, we will present a description of the proposed approach in the simplest case – when the object-oriented program consists of a single class and a function, which uses this class. The function will be verified according to the specification that specifies relationships between member functions of the class in the form of correct sequences of calls. The verification is done in the following steps:

A. Defineing the specification according to which the function will be verified The specification is defined as a generalized net by the

programmer who has created the class. This is done through the following methodology developed according to the requirements for construction of GN-models as described in [17]:

• Constructing the static structure of the specification

The events that can happen to an object of the class are identified. They are defined by a set of specific activities.

For example, let queue is a class implementing the data structure “queue” which is presented non-cyclically by a sequence of no more than MaxQue (MaxQue > 0) integers afront, afront+1, …, arear–1 (front and rear are pointers to the first and after the last element of the queue). A definition of the class which implements the data structure “queue” and its GN-model can be found in [15].

The following events can occur for an object of the class: - Creation of an empty queue; - Realisation of the following activities: checking whether the queue is empty, checking whether the queue is full, inserting a new element and destructing a queue; - Realisation of the following activities: checking whether the queue is empty, checking whether the queue is full, inserting a new element, deleting an element and destructing a queue; - Realisation of the activities: checking whether the queue is empty, checking whether the queue is full, deleting of an element and destructing a queue; - Realisation of the activities: checking whether the queue is empty, checking whether the queue is full and destructing a queue.

A GN transition has to be assigned to each event of the class model. For this purpose, the initial and final states of each event are defined. Any initial state is modeled by an input place of the transition. The priority and capacity of the input place are specified. Any final state is modeled by an output place of the transition. The priority, capacity and the

characteristics (which a token to be inserted in this place should acquire) are specified for the output place. The activities of an event we will also call activities of the transition, which corresponds to the event.

For example, a GN-model of the class queue consists of five transitions corresponding to the events described in the example above. We will denote them by t1, t2, t3, t4 and t5, respectively. The event to which transition t2 corresponds (graphically presented in Fig. 2) is executed after an empty queue is created. The initial state of this event “The queue is empty” corresponds to the final state of the event t1 (“Creation of an empty queue”).

The final states will present the activities: - performed checking whether a queue is empty; - performed checking whether a queue is full; - executed class destructor; - performed inserting of an element in a queue, and as a

result the queue has become full; - performed inserting of an element in a queue, and as a

result the queue is not full.

The first two of them do not change the queue. This allows they to be both initial and final states of the event. An initial state of the event (which is modeled by the transition t2) also occurs when the third event is executed (an element is deleted from the queue and as a result the queue becomes empty). Thus, the transition t2 will have 4 input {S1, S2, S3, S4} and 5 output places {S2, S3, E1, V1, U1} (Fig. 2).

The priorities of the transitions are defined. In order to do this, the connections between main activities of the events, corresponding to the transitions are analyzed.

In the example illustrating the creation of a GN-model of the class queue, the first event has the highest priority: the one which corresponds to the creation of an empty queue (transition t1). Next priority has the second event: to one allowing the inclusion of an element in an empty queue (transition t2). The third and fourth events (expressed by transitions t3 and t4), have equal priority that is lower than that of the second event. And the fifth event (corresponding to transition t5) has the lowest priority.

The capacity of each place is defined. The capacity of a GN-model of the class (the specification) place is from 0 to the number of objects in the function which will be verified according to the specification.

A logical expression, which characterizes the state in which is an object of the class, is associated with each place of a transition. This expression is called a logical state of the place. The logical states of the places are defined as conditions, under which the various events taking place in the class can be executed. All input places of a transition corresponding to a concrete event have the same logical state.

In the context of the example of class queue, the logical states of the GN-model places can be defined by means of following logical expressions:

- for the input place of transition t1 MaxQue > 0 - for the input places of transition t2 front >= 0 && front = = rear && rear < MaxQue - for the input places of transition t3 front >= 0 && front < rear && rear < MaxQue - for the input places of transition t4 front >= 0 && front < rear && rear = = MaxQue - for the input places of transition t5 front >= 0 && front = = rear && rear = = MaxQue

respectively.

• Adding the dynamic of the specification

The dynamic character of the net is determined by the tokens and the conditions of the transitions. Class objects are modeled by GN tokens. A token enters the net when an object class is created (through a constructor of the class) in the function to be verified and exits when its corresponding object is destroyed (after execution of the class destructor).

Tokens have characteristics of the type (object, place), where the parameter object is the name of the object modeled by the token, and the parameter place contains the name of the place in the net which the token occupies in a given moment of movement. Two components are implicitly included in the characteristics of the token: a data member of the class (we call them also token data), and a logical state of the place. The first component is associated with the parameter object, and the second – with the parameter place. The parameter place is used to gain information about the way the token has covered, and to indicate its place in case of an error.

Tokens priority in a GN-model of the class is determined by the transition executed in a GN-model of the function to be verified.

Net transitions are defined formally. For example, transition t2 in the above example can be partially defined as shown in Fig. 2.

Figure 2. Transition in GN-model of the class implementing a queue.

t2 = ⟨{S1, S2, S3, S4}, {S2, S3, E1, V1, U1}, t2'⟩

S4

output for t1

input for t3

input for t4 V1

t2

S1

S2

S3

U1

E1 output for t3

where t2' is the transition condition.

S2 S3 E1 V1 U1 t2' = S1 A1 A2 A3 A4 A5 S2 A1 A2 A3 A4 A5 S3 A1 A2 A3 A4 A5

S4 A1 A2 A3 A4 A5

A1 = “The member function is empty”

A2 = “The member function is full”

A3 = “The member function is an implicit class destructor”

A4 = “The member function is push” AND “Condition rear+1 = = MaxQue is true for the token data in the input places Si (i = 1, 2, 3, 4) ”

A5 = “The member function is push” AND “Condition rear+1 < MaxQue is true for the token data in the input places Si (i = 1, 2, 3, 4)”

A characteristic function Ф is defined that assigns the new characteristic to every token when it makes a transfer from an input to the corresponding output place of a given transition (under the condition of the transition).

It has the following form for the tokens which will go through transition t2 of the example above:

Φ((q(0, 0, а), S1)) = (q(0, 0, a), S2) Φ((q(0, 0, а), S1)) = (q(0, 0, a), S3) Φ((q(0, 0, а), S1)) = (q(0, 1, a), V1) Φ((q(0, 0, а), S1)) = (q(0, 1, a), U1) Φ((q(0, 0, а), S1)) = (–, E 1) Φ((q(f, r, а), Si)) = (q(f, r, a), S2) Φ((q(f, r, а), Si)) = (q(f, r, a), S3) Φ((q(f, r, а), Si)) = (q(f, r+1, a), V1) Φ((q(f, r, а), Si)) = (q(f, r+1, a), U1) Φ((q(f, r, а), Si)) = (–, E1)

for i = 2, 3 and 4, where “–” corresponds to “the object is destroyed by the class destructor”, q is an object name of the class queue, f and r correspond to front and rear of q.

• Setting the time characteristics of the specification

The temporal components T, t0 and t* of the class GN-model are defined as follows: T coincides with the time-moment in which a transition corresponding to the class constructor is executed for the first time in the function GN-model ; t0 and t* are the same as those of the function GN-model.

B. Verification of the class and the specification

1) Verification of the class

Methodology as defined in [18] is used. A class invariant, as well as a precondition and a postcondition of each member function are defined for the class. If a member function uses operators for a cycle, an invariant and loop termination condition are defined for each one of them [19].

A formal verification of the class is performed by defining a theorem as a Hoare triple for each member function of the class. The proof of the theorem can be realized by using the technique of the transforming predicates [19], as well as with the help of some of the systems for automatic proof of theorems, such as HOL [20], Isabelle [21], Coq [22], etc.

2) Verification of the specification

This step is realised as it is proved that the class GN-model (the specification) corresponds to the implementation of the class. It is verified whether all paths through which a token can go, starting from the input place of the net, are correct. The verification is done by proving the following requirements [15]:

i) If the logical state of an arbitrary input place of a transition is true, then the preconditions of all member functions of the class, describing all possible activities to the transition, are also true

This requirement can be formally presented by the implication

logical state of place R => precondition of the member function f

where R is an arbitrary input place of a transition, and f is a member function of the class, specifying an activity defined by the corresponding to the transition event.

For example, for transition t2 of the example above, the following implications must be in force

front >= 0 && front = = rear && rear < MaxQue => precondition of the member function f

where f is a member function empty, full or push.

ii) In each place of the net of the class (specification) the invariant of the class holds

This requirement can be formally represented by the implication

logical state of place R => class_Inv

where R is an arbitrary input place of a transition, and class_Inv is the class invariant.

iii) For each a transition, all Hoare triples of the type are true

{ logical state of place R' && ri,j} Bodyf

{ logical state of place R′′}

where R' and R′′ are input and output places of the transition, ri,j is the condition of token transfer from R' to R′′ and

ri,j = Member function is f && pi,j

For example, for transition t2 of the example above, if the token is in the input place S1 and the condition A4 of the transition holds, then the following Hoare triple must be true

{front >= 0 && front = = rear && rear < MaxQue && A4} Bodypush

{front >= 0 && front < rear && rear = = MaxQue}

The truth of these requirements, combined with the class verification, ensures the correctness of the execution of all transition sequences in the class GN-model [15].

C. Construction of a generalized net model of the function to be verified

The construction of this model does not follow the methodology described in [16]. To any operator used in the function, a transition or a GN-element containing several transitions is juxtaposed. One transition is juxtaposed to the operators: input/output, assignment and to calls to function or member function of a class. GN-elements containing several transitions are juxtaposed to conditional operators and loop operators.

A GN-element with a structure of type below is mapped to the conditional operator if (B) stat1; else stat2;

where

t1 = ⟨{S1, …}, {S2, S3}, r1⟩

.........1

321 BBS

SSr

¬=

A GN-element with a structure of type below is mapped to the loop operator while (B) stat;

where

t2 = ⟨{S1, S4}, {S2, S3}, r2⟩

BBSBBS

SSr

¬¬

=

4

1

322

Similarly, GN-elements corresponding to the other conditional and loop operators are defined. If a transition performs an execution of a member function of a class, a name

of the object, by which the member function is activated, is related to it.

D. Checking if the GN-model of the function satisfies the specification For this purpose, both GN-models of the function and of

the specification are executed in parallel. An algorithm which performs the check is described by a generalized net in [23]. The execution begins by function GN-model execution. A token without characteristics is activated in the input place of this model. Then the token is transferred from place to place of the function net until it reaches an input place of a transition, corresponding to the execution of a member function of the class. If the member function is not a class constructor, an error in the function definition has occurred. The execution of the nets is over. If the member function is a constructor of the class, a new token without characteristic is activated at the input place of the specification GN-model. The transitions of both GNs, corresponding to the execution of the constructor, are executed in parallel. As a result, the tokens are transferred to the corresponding output places for the executed transitions, and characteristics of the type (name_of_a_token, name_of_a_ place_in_GN_model_of_the_ function) and (name_of_a_token, name_of_a_place_in_GN_ model_of_the_specification) are respectively attributed. The names of the two tokens are the same, and are identical to the name of the defined object. The last action is repeatedly performed at each transition of the function net corresponding to the execution of a constructor. Each token created has a period of activity starting from the execution of a transition, corresponding to a class constructor, and ending after the execution of a transition, corresponding to the class destructor. The check whether the specification GN-model corresponds to the function GN-model continues by the function model execution. The possibilities are:

- The place is an input of a transition r of the function GN-model, which performs an action, not associated with the class Then, the transition r is executed if it is possible. All

tokens are transferred from the input to the corresponding output place of the transition. Their respective tokens in the class GN-model do not change their places.

- The place is an input of a transition r of the function GN-model, which performs an action, associated with an execution of a member function of the class, different from a constructor If the member function associated with r is activated for

the object p of the class, and if there is no token with the name p in the input place, the transition r will not be executed. An error has occurred, which is interpreted as “The used object p is not defined”. Otherwise, the transition r will be executed if:

- The condition of the transition r holds, and - Exactly one of the transition conditions (in the specific-

ation net) with an input place containing the token named p holds.

t2 Representation

of stat

Representation of the operator

after while

S1 S2

S3

S4

t1

Representation of stat1

Representation of stat2 ...

S1 S2

S3

The second condition can be treated as a permission for an execution of the call to a member function of the function, in order the call to a member function to be correct. If the transition r is performed, the transition of the specification net is also executed. As a result, all tokens of the function net are transferred to an output place of the transition (according to the conditions of the transition). The token with name p of the specification GN changes its place according to the conditions of the transition related to it. The other tokens of this net do not change their places.

- The place is an input for transition r of the function GN-model, which executes a class constructor This case has been discussed at the beginning of the

section.

If the performance of both models ended normally (did not reach impossible transition), the function satisfies the specific-ation, according to which it is being verified. Otherwise, the implementation of the function is not correct. The location in function where the error has occurred can be found through the characteristics of the token which reached impossible transition and the reasons for it – through the condition of the transition.

IV. CONCLUSION An approach for formal verification of object-oriented

programs is discussed from a methodological point of view in the article. This approach integrates the concept of „design by contract” with approaches for verification of the type theorem proofs and model consistency check. It is intended for research and educational purposes. A program environment which implements the approach and an educational framework for its application are under development. The author believes that this way university students in the beginning of their training in computer science and software engineering could be introduced to using methods for formal program verification.

ACKNOWLEDGMENT The paper is supported by Grant “Software modeling –

theoretical, applied and methodological aspects” from Sofia University Research Fund - 2012.

REFERENCES [1] D. Berberova and B. Bontchev, “Testing software based on design by

contract”, 4th Int. Bulgarian-Greek Conference - Computer Science'2008, Kavala, Greece, 18-19 September, 2008, vol.2, pp. 437-442.

[2] V. Pavlov, B. Borisov, S. Ilieva, and D. Petrova-Antonova, “Framework for Testing Service Compositions”, 12th International Symposium on Symbolic and Numeric Algorithms for Scientific Computing Timisoara, Romania, September, 2010, pp. 246-252.

[3] S. Ilieva, V. Pavlov, and I. Manova, “A Composable Framework for Test Automation of Service-Based Applications”, 7th International Conference on the Quality of Information and Communications Technology (QUATIC), Porto, Portugal, 2010, pp. 286-291.

[4] V. Dimitrov, “Toward Semantic Specification of WS-BPEL”, Fourth International Conference on Information Systems & Grid Technologies, 28-29 May 2010, Sofia, pp. 164-183.

[5] V. Dimitrov, “Formal Semantic of WS-BPEL,” Fifth International Conference on Information Systems & Grid Technologies, 27-28 May 2011, Sofia, pp. 180-199.

[6] B. Bonchev and M. Iliev. “Modeling and Analyzing of Concurrent Systems with ETN”, Proc. of WP&DP, ISBN 0 444 89157 9, Sofia, April 16-19 1991, North Holland, Elsevier Publ., 1992, pp. 307-321.

[7] B. Bonchev, “Hierarchical Modeling of Parallel Systems with Extended Timed Nets”, Petri Nets Newsletter Journal, ISSN 0931–1084, Bonn, No. 40, December 1991, pp. 8-16.

[8] http://mtc.epfl.ch/software-tools/blast/index-epfl.php (last visited on 10.02.2012).

[9] http://www.uppaal.com/ (last visited on 10.02.2012). [10] http://nusmv.fbk.eu/ (last visited on 10.02.2012). [11] I. Donchev and E. Todorova, “Operations with Objects and

Communication between Objects in Teaching Object-oriented Programming”, Proceedings of The Sixth International Conference “Internet–Education–Science”, Vinnytsia, Ukraine, October 7–11, 2008, pp. 106-109, (in Russian).

[12] I. Donchev and E. Todorova,”Polymorphism in Object-oriented Programming Course – Didactic Aspects”, Proceedings of The Sixth International Conference “Internet–Education–Science”, Vinnytsia, Ukraine, October 7–11, 2008. pp. 110-113, (in Russian).

[13] I. Donchev and E. Todorova, “Object-Oriented Programming in Bulgarian Universities’ Informatics and Computer Science Curricula”, Informatics in Education, Vol. 7, No. 2, 2008, Institute of Mathematics and Informatics, Vilnius, pp. 159-172.

[14] A. Semerdzhiev, T. Trifonov, and M. Nisheva, “Automated Tools for Assisting the Educational Process in Informatics,” International Conference on Application of Information and Communication Technology in Economy and Education ICAICTEE–2011, Sofia, Bulgaria, December 2-3, 2011, pp. 429-434, (in Bulgarian).

[15] M. Todorova, “Construction of Correct Object-Oriented Programs via Building there Generalized Nets Models”, Annual of “Informatics”, Section of the Union of Scientists in Bulgaria, vol. 4, pp. 1-28, (in Bulgarian).

[16] K. Atanassov, On Generalized Nets Theory, Prof. Marin Drinov Academic Publishing House, Sofia, 2007.

[17] K. Atanassov, Generalized Nets, World Scientific, Singapore, 1991. [18] B. Meyer, Object-Oriented Software Construction, 2-nd ed., ISE Inc.

Santa Barbara, California, 1997. [19] D. Gries, The Science of Programming, Springer–Verlag, Berlin and

New York, 1981. [20] http://www.cl.cam.ac.uk/research/hvg/HOL/ (last visited on 10.02.2012) [21] http://isabelle.in.tum.de/ (last visited on 10.02.2012) [22] http://coq.inria.fr/ (last visited on 10.02.2012) [23] M. Todorova, “Model Checker of Object-Oriented Programs Based on

Generalized Nets”, In Proceedings of IWIFSGN'2011 Recent Developments in Fuzzy Sets, Intuitionistic Fuzzy Sets, Generalized Nets and Related Topics. Foundations and Applications, Warsaw, Poland, September 30, 2011, pp. 309-319.