Results 1 
3 of
3
Simulating file operations: an exercise in calculational data refinement. Memorandum AB66
 Eindhoven University of Technology
, 1997
"... This note was written as an exercise in calculating with abstract data type specifications, both from the user’s point of view and from the implementer’s. We have chosen an example that is wellknown to anyone who has ever struggled to convert programs involving ISO Pascal file operations to some no ..."
Abstract

Cited by 1 (1 self)
 Add to MetaCart
(Show Context)
This note was written as an exercise in calculating with abstract data type specifications, both from the user’s point of view and from the implementer’s. We have chosen an example that is wellknown to anyone who has ever struggled to convert programs involving ISO Pascal file operations to some nonstandard Pascal version – an experience by now familiar to a sizable proportion of the earth’s population. In order to derive a solution to this problem, we regard ISO Pascal files as an abstract data type, disregarding the fact that Pascal compilers will not support this. We specify this abstract data type by giving a model, i.e. we define a number of variables of mathematically wellunderstood types in terms of which the operations on ISO Pascal files can be described. Let a component type T be given. Our model consists of four variables, namely P: T ∗ S: T ∗ (the file prefix, consisting of the items already read) (the file suffix, consisting of the items not yet read) Q: {in, out} (whether the file is opened for input or for output) B: T ∪ {⊥} (the file buffer) The values of these four variables are not quite independent: they are linked by the type invariant Q = out ⇒ S = [ ]. (1) In the ISO Pascal definition, the file buffer is a public variable: client variables may inspect its value, but are also allowed to perform explicit assignments to it. In our abstract data type, we shall model this by adding operations Getbuffer and Setbuffer whose effects are those of inspection and assignment respectively. The value ⊥ (pronounced ‘bottom’) is added because the ISO Pascal standard sometimes requires the buffer to become undefined. The abstract data type for ISO Pascal files is defined by listing its operations and specifying these by pre and postconditions in terms of the four variables P, S, Q, B. The operations are: Rewrite pre: true post: P = [ ] ∧ S = [ ] ∧ Q = out ∧ B = ⊥ Reset pre: true post: P = [ ] ∧ S = P • ++ S • ∧ Q = in ∧ B = Hd.S Put pre: Q = out ∧ B � = ⊥ post: P = P • ++ [B•] ∧ S = [ ] ∧ Q = out ∧ B = ⊥ Get pre: Q = in ∧ S � = [] post: P = P • ++ [Hd.S•] ∧ S = Tl.S • ∧ Q = in ∧ B = Hd.S Setbuffer(E) pre: def.E
ModelBased Specification
, 2000
"... Introduction Procedures in an imperative programming language are specified by means of a precondition and a postcondition, expressed in the procedure's parameters and any global variables that are referenced. A simple way of looking at methods in objectoriented languages, suggested by early ..."
Abstract
 Add to MetaCart
(Show Context)
Introduction Procedures in an imperative programming language are specified by means of a precondition and a postcondition, expressed in the procedure's parameters and any global variables that are referenced. A simple way of looking at methods in objectoriented languages, suggested by early implementations, is to regard these as procedures with one special parameter that is written before the method name in method calls. This parameter is not explicitly present in the method's definition, but can be retrieved via the keyword this or self. The specification style suggested by this view is the use of pre and postconditions expressed in both this and the method's explicit parameters. Here the question arises what kind of assertions are permitted about the state of this and other objects among the parameters. The simplest way to view object types, as made explicit in Oberon2 [13], is as a special kind of record t
1 Two approaches to the use of initial values
, 2000
"... Consider a statespace Ω. Traditionally, we characterize statements over Ω by a pair of predicates over Ω: the Hoare triple notation signifies {U} S {V} (1) [U ⇒ wp.S.V], where the brackets denote universal quantification over Ω. For many purposes, however, it is more practical to use a convention wh ..."
Abstract
 Add to MetaCart
(Show Context)
Consider a statespace Ω. Traditionally, we characterize statements over Ω by a pair of predicates over Ω: the Hoare triple notation signifies {U} S {V} (1) [U ⇒ wp.S.V], where the brackets denote universal quantification over Ω. For many purposes, however, it is more practical to use a convention where the postcondition V is not a predicate over Ω but rather over Ω × Ω • , where Ω • is a disjoint copy of Ω. Let us call this an extended predicate, as opposed to a plain predicate that is defined over Ω. If x is the coordinate vector of Ω and x • that of Ω • , extended predicates contain both x and x •. The idea is that x • is used to record the initial value of x. For instance, a statement that squares the value of x may be specified as {true} S {x = x 2 •}. A similar notation is used, for instance, in the postcondition notation of the Eiffel programming language [5] (where x • is called old x) and in the OCL specification language [7] (where x • is called x@pre). Its usefulness lies in the fact that it shortens specifications by doing away with the need for most specification variables, without having to drag in the full apparatus of the relational calculus. The extent to which this simple expedient cleans up formulae becomes clear if we observe that the classical criterion for repetition termination [2, (9, 28)] 〈 ∀τ:: {P ∧ B ∧ t = τ} S {P ∧ t < τ} 〉 can now be shortened to {P ∧ B} S {P ∧ t < t•}. (2) As suggested by these examples, the intention may be captured by considering x • as a specification variable and implicitly extending the precondition with a conjunct x = x •. In other words, (1) may be defined for extended V by 〈 ∀x •:: [U ∧ x = x • ⇒ wp.S.V] 〉 , (3) AB71 2 where the brackets still quantify over Ω. Some applications of this approach were demonstrated in [3]. A slightly different way of formalizing initial values, used in [4, page 22], is to consider statements over Ω × Ω • as well. That makes x • into an ordinary coordinate of the state space; in the interpretation of (1), S is then prefixed implicitly with an assignment statement x •: = x. This suggests that the meaning of (1) for extended V may alternatively be given by [U ⇒ wp.(x •: = x; S).V] ′ , (4) where the primed brackets quantify over Ω × Ω •.