Common use of Execution Model Clause in Contracts

Execution Model. It is convenient to conceptually assume that two versions of a program are run in parallel when considering the semantics of a change contract between two versions of a program. Recall that a change contract concerns currently only sequential programs as JML does, and the introduced parallelism is not intended to interfere with Java’s multithreading. The overall semantic rule shown in Figure 5(b) clarifies such a parallel execution model. Given two commands c1 and c2 that represent the method bodies of the previous and updated versions, respectively, we assume they are run in parallel as denoted with c1 c2. || Nonetheless, not all parallel executions c1 c2 are interesting to the users of a change contract. For example, given a change contract, ensures result== prev( result)+1, of a method m(int x), one would expect the increase of the return value only when the same integer value for parameter x is given to both versions. Roughly speaking, input equality between the two versions needs to be assumed when considering a change contract. However, naive input equality is not enough for two reasons. First, the prior parameter x may not be of a primitive type but of a subtype of Object. If this is the case, simple reference comparison is inappropriate. Second, there may be structural changes such as addition of a method parameter or a field. To address the first issue, we compare object graphs instead of object references. Conventionally, two graphs are considered isomorphic if there is a unique one-to-one correspondence between the vertexes and edges of the two graphs. If, in addition, all the one-to-one corresponding vertexes that represent primitive values of the two object graphs contain the same values, the two object graphs are considered isomorphic. We extend this notion of isomorphism to the program state level as follows. Note that a program state consists of a store σ and a heap h. ≈ 1 ( Isomorphic Program States). Two program states (σ1, h1) and (σ2, h2) are considered isomorphic to each other if, for all variables x that commonly exist in the domain of σ1 and σ2, the two object graphs that σ1(x) and σ2(x) respectively refer to are isomorphic to each other. We denote the fact that two program states (σ1, h1) and (σ2, h2) are isomorphic to each other with notation (σ1, h1) (σ2, h2). As usual in Java programs (and other object-oriented programs), the receiver of an object (i.e., this) is considered an implicit parameter of a nonstatic method, and thus this is in the domain of σ1 and σ2. Note that, in Definition 1, heaps (h1 and h2) are consulted if necessary when con- structing object graphs. As in variables, only those fields that commonly exist in h1 and ACM Transactions on Software Engineering and Methodology, Vol. 24, No. 3, Article 18, Pub. date: May 2015.

Execution Model. It is convenient to conceptually assume that two versions of a program are run in parallel when considering the semantics of a change contract between two versions of a program. Recall that a change contract concerns currently only sequential programs as JML does, and the introduced parallelism is not intended to interfere with Java’s multithreading. The overall semantic rule shown in Figure 5(b) clarifies such a parallel execution model. Given two commands c1 and c2 that represent the method bodies of the previous and updated versions, respectively, we assume they are run in parallel as denoted with c1 c2. || Nonetheless, not all parallel executions c1 c2 are interesting to the users of a change contract. For example, given a change contract, ensures result== prev( result)+1, of a method m(int x), one would expect the increase of the return value only when the same integer value for parameter x is given to both versions. Roughly speaking, input equality between the two versions needs to be assumed when considering a change contract. However, naive input equality is not enough for two reasons. First, the prior parameter x may not be of a primitive type but of a subtype of Object. If this is the case, simple reference comparison is inappropriate. Second, there may be structural changes such as addition of a method parameter or a field. To address the first issue, we compare object graphs instead of object references. Conventionally, two graphs are considered isomorphic if there is a unique one-to-one correspondence between the vertexes and edges of the two graphs. If, in addition, all the one-to-one corresponding vertexes that represent primitive values of the two object graphs contain the same values, the two object graphs are considered isomorphic. We extend this notion of isomorphism to the program state level as follows. Note that a program state consists of a store σ and a heap h. ≈ ≈ Definition 1 ( (Isomorphic Program States). Two program states (σ1, h1) and (σ2, h2) are considered isomorphic to each other if, for all variables x that commonly exist in the domain of σ1 and σ2, the two object graphs that σ1(x) and σ2(x) respectively refer to are isomorphic to each other. We denote the fact that two program states (σ1, h1) and (σ2, h2) are isomorphic to each other with notation (σ1, h1) (σ2, h2). As usual in Java programs (and other object-oriented programs), the receiver of an object (i.e., this) is considered an implicit parameter of a nonstatic method, and thus this is in the domain of σ1 and σ2. Note that, in Definition 1, heaps (h1 and h2) are consulted if necessary when con- structing object graphs. As in variables, only those fields that commonly exist in h1 and ACM Transactions on Software Engineering and Methodology, Vol. 24, No. 3, Article 18, Pub. date: May 2015.. ⇓ ⇓