Common use of Change Contract Checking Clause in Contracts

Change Contract Checking. To support dynamic checking of change contracts, we use our custom compiler, an extension of OpenJML [Cok 2014]. When we compile a Java source file, say C.java, its corresponding change contract file, C.scc, is also looked up. If this change contract exists, the resulting class file C.class is instrumented with this change contract. Recall that a change contract is satisfied if the previous and updated versions satisfy, respectively, the update condition and the change condition of this change contract. Accordingly, we instrument the previous and updated versions differently. For example, only at the previous version do we need store in the disk the boolean value of the update condition of a given change contract. To align isomorphic inputs between the two versions, the two instrumented sys- tems, when encountered with the target method during the run, convert input states (i.e., the states of parameters and the receiver) into XML graphs using XStream6. Such XML graphs can be viewed as object graphs, the data format we assumed for 6▇▇▇▇://▇▇▇▇▇▇▇.▇▇▇▇▇▇▇▇.▇▇▇/. ACM Transactions on Software Engineering and Methodology, Vol. 24, No. 3, Article 18, Pub. date: May 2015. input isomorphism in Section 3.2. Those two XML graphs of the previous and the up- dated versions are compared to check input isomorphism. We used XMLUnit7 for this comparison. In addition to input states, the values of prev expressions are also stored in the disk while running the instrumented system of the previous version. Afterwards, the instrumented system of the updated version uses these prestored values to replace \prev expressions.

Change Contract Checking. To support dynamic checking of change contracts, we use our custom compiler, an extension of OpenJML [Cok 2014]. When we compile a Java source file, say C.java, its corresponding change contract file, C.scc, is also looked up. If this change contract exists, the resulting class file C.class is instrumented with this change contract. Recall that a change contract is satisfied if the previous and updated versions satisfy, respectively, the update condition and the change condition of this change contract. Accordingly, we instrument the previous and updated versions differently. For example, only at the previous version do we need store in the disk the boolean value of the update condition of a given change contract. To align isomorphic inputs between the two versions, the two instrumented sys- tems, when encountered with the target method during the run, convert input states (i.e., the states of parameters and the receiver) into XML graphs using XStream6. Such XML graphs can be viewed as object graphs, the data format we assumed for 6▇▇▇▇://▇▇▇▇▇▇▇.▇▇▇▇▇▇▇▇.▇▇▇/. ACM Transactions on Software Engineering and Methodology, Vol. 24, No. 3, Article 18, Pub. date: May 2015. Change Contracts 18:19 input isomorphism in Section 3.2. Those two XML graphs of the previous and the up- dated versions are compared to check input isomorphism. We used XMLUnit7 for this comparison. In addition to input states, the values of prev expressions are also stored in the disk while running the instrumented system of the previous version. Afterwards, the instrumented system of the updated version uses these prestored values to replace \prev expressions.