Reasoning about real-time repetitions: terminating and nonterminating

Hayes, Ian J.

doi:10.1016/s0167-6423(02)00024-2

Cited by 17 publications

(16 citation statements)

References 18 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Ongoing enhancements to the real-time refinement calculus have addressed reasoning about non-terminating loops [Hay02] and improved the modelling of parallel processes [PH02], and it is fully expected that corresponding extensions can also be made to our real-time Program Refinement Tool.…”

Section: Resultsmentioning

confidence: 99%

“…In fact, the actual case study performed in the Program Refinement Tool was slightly more complicated and placed an upper bound on the number of periods. (Technically, the predicate above prevents the specification statement from ever terminating, which is handled in the timed refinement calculus by a distinguished specification statement [Hay02], but we ignore this complication here.) As is typical for high-level specifications of whole process behaviours, all references to timed-trace variables such as u and e in both of the above predicates are explicitly indexed with absolute times-there are no free references to starting time τ 0 or finishing time τ .…”

Section: Refining Parallel Componentsmentioning

confidence: 99%

“…Recently, the calculus was extended to handle timing requirements, as well as functional ones [Hay02,HU01,Hay00,Hay98]. However, the timing extensions introduce considerable complexity to the theory and cannot be accommodated by existing tools.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

The Variety of Variables in Automated Real-Time Refinement

2003

View full text Add to dashboard Cite

Abstract. The refinement calculus is a well-established theory for deriving program code from specifications. Recent research has extended the theory to handle timing requirements, as well as functional ones, and we have developed an interactive programming tool based on these extensions. Through a number of case studies completed using the tool, this paper explains how the tool helps the programmer by supporting the many forms of variables needed in the theory. These include simple state variables as in the untimed calculus, trace variables that model the evolution of properties over time, auxiliary variables that exist only to support formal reasoning, subroutine parameters, and variables shared between parallel processes.

show abstract

Section: Resultsmentioning

confidence: 99%

Section: Refining Parallel Componentsmentioning

confidence: 99%

See 1 more Smart Citation

The Variety of Variables in Automated Real-Time Refinement

2003

View full text Add to dashboard Cite

show abstract

“…There are circumstances when time is important, called real-time or reactive programming. And theories have been invented [1], and new ones are still being invented [3], to reason about execution time. An entire logic, called temporal logic, was invented to specify and reason about timing.…”

Section: Utp Without Mementioning

confidence: 99%

Retrospective and Prospective for Unifying Theories of Programming

Hehner

2006

Unifying Theories of Programming

View full text Add to dashboard Cite

This paper presents a personal account of developments leading to Unifying Theories of Programming, and some opinions about the direction the work should take in the future. It also speculates on consequences the work will have for all of computer science. UTP and meMy introduction to formal methods was the book a Discipline of Programming [2] by Edsger Dijkstra in 1976. I wrote a small contribution in a paper named do considered od [14] in that same year. In that paper I proposed recursive refinement as a way of composing programs, and a different way of generating the sequence of approximations for loop semantics that is more general than the one in Dijkstra's book, applying to all looping constructs, including general recursion.It was standard in semantics work then (and for some people, it remains so today) to use a meaning function (sometimes written as double square brackets) that maps program text to its meaning. In Dijkstra's book, he used the wp function to map a program text and postcondition to a precondition. If S is some program text, and R is a postcondition, then wp(S, R) is the exact precondition for execution of 1 S to terminate and establish postcondition R . In my 1976 paper, I made the The English meaning of "precondition" is "something that is necessary 1 beforehand". Dijkstra was using it to mean "something that is sufficient beforehand". In Dijkstra's use, the "weakest precondition" wp was the weakest sufficient condition, i.e. the necessary and sufficient condition. To avoid misusing the word "precondition", I am saying "exact precondition" to mean the condition that is both necessary and sufficient.

show abstract

“…Section 8 generalises this further to allow the expression of reactive properties of traces of the program variables over time; this model corresponds to the real-time refinement calculus [11][12][13][14][15]. Figure 1 summarises the relationships between the models graphically.…”

Section: Introductionmentioning

confidence: 99%

Unifying Theories of Programming That Distinguish Nontermination and Abort

Hayes

Dunne

Meinicke

2010

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract. In this paper we focus on the relationship between a number of specification models. The models are formulated in the Unifying Theories of Programming of Hoare and He, but correspond to widely used specification models. We cover issues such as partial correctness, total correctness, and general correctness. The properties we use to distinguish the models are these:-whether they allow the specification of assumptions about the initial state outside of which no guarantees are given about the behaviour of the program, i.e., the program may "abort"; -whether a specification may allow or even require nontermination as a valid (non-aborting) outcome; and -whether they allow the expression of tests or enabling conditions, outside of which the program has no possible behaviour. When considering termination, we consider both an abstract model, which only distinguishes whether a program terminates or not, as well as models that include a notion of time: either abstract time representing a notion of progress or realtime.

show abstract

Reasoning about real-time repetitions: terminating and nonterminating

Cited by 17 publications

References 18 publications

The Variety of Variables in Automated Real-Time Refinement

The Variety of Variables in Automated Real-Time Refinement

Retrospective and Prospective for Unifying Theories of Programming

Unifying Theories of Programming That Distinguish Nontermination and Abort

Contact Info

Product

Resources

About