Transformation of Applicative Specifications into Imperative ...
Transformation of Applicative Specifications into Imperative ... Transformation of Applicative Specifications into Imperative ...
CHAPTER 7. CORRECTNESS OF TRANSFORMATION RULES for all (ve1, x, ve2) ∈ Value A ∗ (te1×tv×te2): mOP (f)(vearg)([ ]) ≡ case m ′ OP (f)(vearg)([ v ↦→ dv ]) of ⊥ → ⊥, ((ve1, ve2), [ v ↦→ dv ′ ]) → ((ve1, dv ′ , ve2), [ ]) end Note that dom [v ↦→ dv] = dom [v ↦→ dv ′ ] = {v}. Explanation: mOP (f) returns chaos if m ′ OP (f) returns chaos. Otherwise mOP (f) returns the same result as m ′ OP (f), but with the actual value dv ′ of v included. When evaluating m ′ OP (f) a store s = [v ↦→ dv] is kept reflecting the actual value dv of v. This value is altered during the evaluation of f, since f is a generator. 3. Combined observer and generator f : te1 × tv × te2 ∼ → te3 × tv × te4 σ f : te1 × te2 ∼ → read v write v te3 × te4 for all (ve1, x, ve2) ∈ Value A ∗ (te1×tv×te2), (ve3, x, ve4) ∈ Value A ∗ (te3×tv×te4): mOP (f)(ve1, x, ve2)([ ]) ≡ case m ′ OP (f)(ve1, ve2)([ v ↦→ x ]) of ⊥ → ⊥, ((ve3, ve4), [ v ↦→ x ′ ]) → ((ve3, x ′ , ve4), [ ]) end Explanation: mOP (f) returns chaos if m ′ OP (f) returns chaos. Otherwise mOP (f) returns the same result as m ′ OP (f), but with the actual value of x ′ of v included. When evaluating m ′ OP (f) a store s = [v ↦→ x] is kept reflecting the actual value x of v. This value is altered during the evaluation of f, since f is a generator. Model Category Composition is defined the obvious way. Identities are defined such that a model is mapped to itself. Model Functor The functor Mod : Sign → Cat is a functor that maps Sign to the category Mod(Σ) of Σ-models and maps each signature morphism σ : Σ → Σ ′ in Sign to the model morphism Mod(σ) : Mod(Σ ′ ) → Mod(Σ) which is described above. 66
Satisfaction Relation 7.5. EXAMPLE Then the satisfaction relation |=Σ must be defined, such that the satisfaction condition can be formulated. The dynamic semantics of mRSL value expressions was defined in [Lin04]. This should be extended to cover the whole subset of RSLI. Proof of Satisfaction Condition The last step is to prove that the satisfaction condition holds. The satisfaction condition is proved in [Lin04] for the institution of mRSL. Most likely this can be carried over to the institution of RSLI. If this is the case the transformation rules are correct. This means that the transformation of an applicative RSL specification into an imperative RSL specification using the transformation rules will be a correct development step. 7.5 Example The following simple example illustrates the ideas of this chapter. First an applicative specification A_SPEC is defined: Specification 7.1 – Applicative specification A_SPEC scheme A_SPEC = class type T = Bool value f : T → T f(x) ≡ ∼ x end A_SPEC can be regarded as a signature Σ and a sentence e. The signature Σ = 〈A, OP, V 〉 of A_SPEC is defined as follows: • A = [T ↦→ Bool], reflecting the type of T • OP = [f ↦→ T → T ], reflecting the type of the function f • V = [ ], as there are no variable definitions in A_SPEC The sentence is defined as e =∀ x : T • f(x) ≡ ∼ x Then the model m = 〈mA, mOP , sinit〉 of A_SPEC can be defined: 67
- Page 32 and 33: CHAPTER 3. TERMINOLOGY Example 3.5
- Page 34 and 35: CHAPTER 3. TERMINOLOGY 18
- Page 36 and 37: CHAPTER 4. CONSTRAINTS further deve
- Page 38 and 39: CHAPTER 4. CONSTRAINTS of interest.
- Page 40 and 41: CHAPTER 4. CONSTRAINTS 24
- Page 42 and 43: CHAPTER 5. TRANSFORMABILITY scheme
- Page 44 and 45: CHAPTER 5. TRANSFORMABILITY 28
- Page 46 and 47: CHAPTER 6. TRANSFORMATIONS 6.2.1 Tr
- Page 48 and 49: CHAPTER 6. TRANSFORMATIONS Example
- Page 50 and 51: CHAPTER 6. TRANSFORMATIONS Applicat
- Page 52 and 53: CHAPTER 6. TRANSFORMATIONS object A
- Page 54 and 55: CHAPTER 6. TRANSFORMATIONS type T =
- Page 56 and 57: CHAPTER 6. TRANSFORMATIONS where ge
- Page 58 and 59: CHAPTER 6. TRANSFORMATIONS Ranged s
- Page 60 and 61: CHAPTER 6. TRANSFORMATIONS ✄ end
- Page 62 and 63: CHAPTER 6. TRANSFORMATIONS Value In
- Page 64 and 65: CHAPTER 6. TRANSFORMATIONS ✄ sche
- Page 66 and 67: CHAPTER 6. TRANSFORMATIONS A case e
- Page 68 and 69: CHAPTER 6. TRANSFORMATIONS is due t
- Page 70 and 71: CHAPTER 6. TRANSFORMATIONS 6.4.4 Tr
- Page 72 and 73: CHAPTER 6. TRANSFORMATIONS 56
- Page 74 and 75: CHAPTER 7. CORRECTNESS OF TRANSFORM
- Page 76 and 77: CHAPTER 7. CORRECTNESS OF TRANSFORM
- Page 78 and 79: CHAPTER 7. CORRECTNESS OF TRANSFORM
- Page 80 and 81: CHAPTER 7. CORRECTNESS OF TRANSFORM
- Page 84 and 85: CHAPTER 7. CORRECTNESS OF TRANSFORM
- Page 86 and 87: CHAPTER 7. CORRECTNESS OF TRANSFORM
- Page 88 and 89: CHAPTER 8. SPECIFICATIONS The rewri
- Page 90 and 91: CHAPTER 8. SPECIFICATIONS RSL speci
- Page 92 and 93: CHAPTER 8. SPECIFICATIONS The FUNC
- Page 94 and 95: CHAPTER 8. SPECIFICATIONS out, that
- Page 96 and 97: CHAPTER 8. SPECIFICATIONS construct
- Page 98 and 99: CHAPTER 8. SPECIFICATIONS 8.4.1 Mor
- Page 100 and 101: CHAPTER 8. SPECIFICATIONS PRECOND_T
- Page 102 and 103: CHAPTER 8. SPECIFICATIONS if length
- Page 104 and 105: CHAPTER 8. SPECIFICATIONS subtypes.
- Page 106 and 107: CHAPTER 8. SPECIFICATIONS 8.5.2 Cha
- Page 108 and 109: CHAPTER 8. SPECIFICATIONS axiom [ m
- Page 110 and 111: CHAPTER 8. SPECIFICATIONS Specifica
- Page 112 and 113: CHAPTER 8. SPECIFICATIONS the lack
- Page 114 and 115: CHAPTER 9. IMPLEMENTATION OF THE TR
- Page 116 and 117: CHAPTER 9. IMPLEMENTATION OF THE TR
- Page 118 and 119: CHAPTER 9. IMPLEMENTATION OF THE TR
- Page 120 and 121: CHAPTER 9. IMPLEMENTATION OF THE TR
- Page 122 and 123: CHAPTER 9. IMPLEMENTATION OF THE TR
- Page 124 and 125: CHAPTER 9. IMPLEMENTATION OF THE TR
- Page 126 and 127: CHAPTER 10. EXAMPLES OF TRANSFORMAT
- Page 128 and 129: CHAPTER 10. EXAMPLES OF TRANSFORMAT
- Page 130 and 131: CHAPTER 10. EXAMPLES OF TRANSFORMAT
CHAPTER 7. CORRECTNESS OF TRANSFORMATION RULES<br />
for all (ve1, x, ve2) ∈ Value A ∗ (te1×tv×te2):<br />
mOP (f)(vearg)([ ]) ≡<br />
case m ′ OP (f)(vearg)([ v ↦→ dv ]) <strong>of</strong><br />
⊥ → ⊥,<br />
((ve1, ve2), [ v ↦→ dv ′ ]) → ((ve1, dv ′ , ve2), [ ])<br />
end<br />
Note that dom [v ↦→ dv] = dom [v ↦→ dv ′ ] = {v}.<br />
Explanation: mOP (f) returns chaos if m ′ OP (f) returns chaos. Otherwise<br />
mOP (f) returns the same result as m ′ OP (f), but with the actual<br />
value dv ′ <strong>of</strong> v included. When evaluating m ′ OP (f) a store s = [v ↦→ dv]<br />
is kept reflecting the actual value dv <strong>of</strong> v. This value is altered during<br />
the evaluation <strong>of</strong> f, since f is a generator.<br />
3. Combined observer and generator<br />
f : te1 × tv × te2 ∼ → te3 × tv × te4<br />
σ<br />
<br />
f : te1 × te2 ∼ → read v write v te3 × te4<br />
for all (ve1, x, ve2) ∈ Value A ∗ (te1×tv×te2), (ve3, x, ve4) ∈ Value A ∗ (te3×tv×te4):<br />
mOP (f)(ve1, x, ve2)([ ]) ≡<br />
case m ′ OP (f)(ve1, ve2)([ v ↦→ x ]) <strong>of</strong><br />
⊥ → ⊥,<br />
((ve3, ve4), [ v ↦→ x ′ ]) → ((ve3, x ′ , ve4), [ ])<br />
end<br />
Explanation: mOP (f) returns chaos if m ′ OP (f) returns chaos. Otherwise<br />
mOP (f) returns the same result as m ′ OP (f), but with the actual<br />
value <strong>of</strong> x ′ <strong>of</strong> v included. When evaluating m ′ OP (f) a store s = [v ↦→ x]<br />
is kept reflecting the actual value x <strong>of</strong> v. This value is altered during<br />
the evaluation <strong>of</strong> f, since f is a generator.<br />
Model Category<br />
Composition is defined the obvious way. Identities are defined such that a<br />
model is mapped to itself.<br />
Model Functor<br />
The functor Mod : Sign → Cat is a functor that maps Sign to the category<br />
Mod(Σ) <strong>of</strong> Σ-models and maps each signature morphism σ : Σ → Σ ′ in Sign<br />
to the model morphism Mod(σ) : Mod(Σ ′ ) → Mod(Σ) which is described<br />
above.<br />
66