### TABLE 1: Proofs of the Competitive Exclusion Principle.

2003

Cited by 3

### Table 6. Measures satisfying the proposed principles

"... In PAGE 15: ... Summarized results are shown in Table 6. In Table6 , the P1 to P5 columns describe the proposed principles, and a measure that satisfies a principle is indicated by the bullet symbol (i.... In PAGE 15: ...Mathematical proofs were derived for each measure satisfying principles P1 to P5 in Table6 . However, due to space limitations, we only provide a few proofs that are illustrative of the methods used, and representative of the complete work which is described in [35].... ..."

Cited by 2

### Table 3. Measures satisfying the proposed principles

2000

"... In PAGE 5: ... Summarized results are shown in Ta- ble 3. In Table3 , the P1 to P5 columns describe the proposed principles, and a measure that satis es a prin- ciple is indicated by the bullet symbol (i.... In PAGE 5: ...Mathematical proofs were derived for each measure satisfying principles P1 to P5 in Table3 . However, due to space limitations, we only provide a few proofs that are illustrative of the methods used, and representa- tive of the complete work which is described in [15].... ..."

Cited by 4

### Table 9. Steps of the Proof of the ALU

"... In PAGE 19: ... To solve this problem, we decomposed the principle proof into many sub-proofs. This is done by considering sub-systems of the ALU and by adding components to that sub-sys- tem until getting the full representation of the ALU (see Table9 and Figure 5). Table 9 describes the steps that we used to make the proof of the implication between the hardware specification of the ALU and its behavioral specification.... In PAGE 19: ... This is done by considering sub-systems of the ALU and by adding components to that sub-sys- tem until getting the full representation of the ALU (see Table 9 and Figure 5). Table9 describes the steps that we used to make the proof of the implication between the hardware specification of the ALU and its behavioral specification. In the first step, we considered a sub-system of the ALU containing the base unit of the arithmetic and logic operations and the selection of the first input Y.... ..."

### Table 4. Fragment of the proof system

2006

"... In PAGE 30: ... Fragment of the proof system C Proof System The proof system used in this paper is based on the proof system developed in [17, 18, 25]. Some example axioms and rules are given in Table4 . These ax- ioms express reasoning principles that can be justifled using complexity-theoretic reductions, information-theoretic arguments, and asymptotic calculations.... ..."

Cited by 1

### Table 3. Fragment of the proof system

"... In PAGE 5: ... 4 Proof System The proof system used in this paper is based on the proof system developed in [7, 8, 2]. Some example axioms and rules are given in Table3 ; the full presen- tation is deferred to the extended version of this paper. These axioms express reasoning principles that can be justifled using complexity-theoretic reductions, information-theoretic arguments, and asymptotic calculations.... ..."

### Tables 4, 5 and 6 lists the typical CRL axioms and rules for interaction between data and processes. The axioms for summation are denoted by SUM, the axioms for the conditional by COND and the rules for the booleans by BOOL. Beside the axioms and rules mentioned above, CRL incorporates two other important proof prin- ciples. First, it supports an principle for induction not only on data but also on data in processes. The second principle is RSP (Recursive Speci cation Principle) taken from [BW90] extended to processes with data. Informally, it says that each guarded recursive speci cation has at most one solution.

1994

Cited by 14

### Table 1. Proof Obligations for Re nements

"... In PAGE 3: ... The \Five Theory Model quot; can be illustrated as follows: W R S P M Environment System Generally speaking, the proof obligations are to show that the theories in ques- tion are consistent and that, under appropriate assumptions: { the domain knowledge W, supplemented by the speci cations S, satis es the requirements R, and { the programming platform M, with its programming P, implements the speci cations. The precise statement of these obligations in Higher-Order Logic is given in the section on designations below ( Table1 ) because it depends crucially on distinguishing variables (representing events and state) that are controlled by the environment (like a person taking a telephone o -hook) from those that are controlled by the system (like causing a telephone to ring). Details about our re nement principles can be found in [4].... In PAGE 7: ... Notice that the domain knowledge and the requirements cannot reference those variables controlled by the system and hidden from the envi- ronment, and that the speci cation can only reference those variables visible to both the system and the environment. Suppressing the arguments, the ultimate theorems we wish to hold are given in Table1 . Formulas (1) and (2) are con- sistency properties and (3) is the correctness of the implementation relative to the domain knowledge and requirements.... In PAGE 15: ...those mentioned above, and we have proved the equivalence of the two speci ca- tions. We have also proved that the speci cation which covers all cases, including those that cannot arise, satisies the reduction theorem given by formulae (4) and (5) in Table1 . Using the equivalence of the speci cation under domain knowl- edge, we then showed the simpli ed speci cation also sati ed formulae (4) and (5).... In PAGE 17: ... The value of then connected(t1; t2) follows simply from the connections for t1; t2 and then alerting(t) is true for any on-hook phone t whenever there is an asking phone.To verify the implementation we need to prove (6) from Table1 for our system (M; P) and speci cation (S). In reactive modules, every module variable must have a value in each round, regardless of input.... ..."

### Table 1. Proof Obligations for Re nements

"... In PAGE 3: ... The \Five Theory Model quot; can be illustrated as follows: W R S P M Environment System Generally speaking, the proof obligations are to show that the theories in ques- tion are consistent and that, under appropriate assumptions: { the domain knowledge W, supplemented by the speci cations S, satis es the requirements R, and { the programming platform M, with its programming P, implements the speci cations. The precise statement of these obligations in Higher-Order Logic is given in the section on designations below ( Table1 ) because it depends crucially on distinguishing variables (representing events and state) that are controlled by the environment (like a person taking a telephone o -hook) from those that are controlled by the system (like causing a telephone to ring). Details about our re nement principles can be found in [4].... In PAGE 7: ... Notice that the domain knowledge and the requirements cannot reference those variables controlled by the system and hidden from the envi- ronment, and that the speci cation can only reference those variables visible to both the system and the environment. Suppressing the arguments, the ultimate theorems we wish to hold are given in Table1 . Formulas (1) and (2) are con- sistency properties and (3) is the correctness of the implementation relative to the domain knowledge and requirements.... In PAGE 15: ...those mentioned above, and we have proved the equivalence of the two speci ca- tions. We have also proved that the speci cation which covers all cases, including those that cannot arise, satisies the reduction theorem given by formulae (4) and (5) in Table1 . Using the equivalence of the speci cation under domain knowl- edge, we then showed the simpli ed speci cation also sati ed formulae (4) and (5).... In PAGE 17: ... The value of then connected(t1; t2) follows simply from the connections for t1; t2 and then alerting(t) is true for any on-hook phone t whenever there is an asking phone.To verify the implementation we need to prove (6) from Table1 for our system (M; P) and speci cation (S). In reactive modules, every module variable must have a value in each round, regardless of input.... ..."

### Table 2. Proof rules for vertical implementation

"... In PAGE 7: ... If dom ; = ?, we write ` t v u r or simply t v r u. Anumber of proof rules for v r are given in Table2 . We rst discuss the case for closed terms;; i.... In PAGE 8: ... In R 12 , nally, the synchronisation set A of the speci cation is re ned in the im- plementation;; moreover, there is a restriction on the re nement function, which will be discussed below in more detail. There are some side conditions in Table2 whose rationale is not immediately obvious. In particular, the re nement function is constrained to be A-preserving in the rule for hiding (R 9 ), and distinct and preserving in the rule for parallel composition (R 12 ).... In PAGE 8: ... Assume A = C = fa;; bg and let r: a 7 ! a;; b;; b 7 ! b. Then the rules of Table2 allow the following derivation: (R 6 ) a v r a;; b (R 6 ) b v r b (R 8 ) a;; b v r a;; b;; b (R 9 ) (a;; b)=a v id (a;; b;; b)=a;; b (R 2 ) (a;; b)=a (a;; b;; b)=a;; b However, (a;; b)=a gives rise to a non-deadlocking term when substituted for x in x jj b b, whereas (a;; b;; b)=a;; b does not. This contradicts the requirement that preserves deadlock freedom.... In PAGE 9: ...! c;; a and b 7 ! c;; b. The rules of Table2 then allowtoderive((a+d)jj a;;b (b+d))=a;; b ((c;; a+d)jj a;;b;;c (c;; b+d))=a;; b;; c. The left hand term contains no deadlock, whereas the righthand term has a -transition to the deadlocked state (1;; b jj b;;c;;d 1;; d)=b;; c;; d.... In PAGE 9: ... [15]) seems inapplicable. 4 Vertical bisimulation Wenow come to the de nition of an actual vertical implementation relation that satis es the derivation rules of Table2 . We build on the principles of observation congruence.... In PAGE 10: ... 6, it follows that vertical bisimilarityuptoid equals ob- servation congruence. Furthermore, the rules in Table2 are sound for . r , To formalise this, we write x .... In PAGE 11: ... r satis es all the rules in Table 2. Note that, although Table2 gives no recipe for deriving implementations from speci cations, in many cases, one particular implementation can be obtained through the syntactic substitution of all abstract actions by their re nements. Abstraction.... ..."