Guards, Preconditions, and Refinement in Z

  • Ralph Miarka
  • Eerke Boiten
  • John Derrick
Conference paper
Part of the Lecture Notes in Computer Science book series (LNCS, volume 1878)

Abstract

In the common Z specification style operations are, in general, partial relations. The domains of these partial operations are traditionally called preconditions, and there are two interpretations of the result of applying an operation outside its domain. In the traditional interpretation anything may result whereas in the alternative, guarded, interpretation the operation is blocked outside its precondition.

In fact these two interpretations can be combined, and this allows representation of both refusals and underspecification in the same model. In this paper we explore this issue, and we extend existing work in this area by allowing arbitrary predicates in the guard.

To do so we adopt a non-standard three valued interpretation of an operation by introducing a third truth value. This value corresponds to a situation where we don’t care what effect the operation has, i.e. the guard holds but we may be outside the precondition.

Using such a three valued interpretation leads to a simple and intuitive semantics for operation refinement, where refinement means reduction of undefinedness or reduction of non-determinism. We illustrate the ideas in the paper by means of a small example.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

References

  1. 1.
    J.-R. Abrial. The B-Book: Assigning Programs to Meanings. Cambridge University Press, 1996.Google Scholar
  2. 2.
    Jonathan P. Bowen, Andreas Fett, and Michael G. Hinchey, editors. ZUM’ 98: The Z Formal Specification Notation, Proceedings of the 11th International Conference of Z Users. Lecture Notes in Computer Science 1493. Springer Verlag, Berlin Heidelberg New York, September 1998.Google Scholar
  3. 3.
    H. Doornbos. A relational model of programs without the restriction to Egli-Milner constructs. In E.-R. Olderog, editor, PROCOMET’ 94, pages 357–376. IFIP, 1994.Google Scholar
  4. 4.
    Clemens Fischer. CSP-OZ: A Combination of Object-Z and CSP. Technical Report TRCF-97-2, Universität Oldenburg, Fachbereich Informatik, PO Box 2503, 2611 Oldenburg, Germany, April 1997. Online: http://theoretica.Informatik.Uni-Oldenburg.DE/~fischer/techreports.html (last access 10/01/2000).Google Scholar
  5. 5.
    Clemens Fischer. How to Combine Z with Process Algebra. In Andreas Fett, and Michael G. Hinchey, editors. ZUM’ 98: The Z Formal Specification Notation, Proceedings of the 11th International Conference of Z Users. Lecture Notes in Computer Science 1493. Springer Verlag, Berlin Heidelberg New York, September 1998 Bowen et al. [2], pages 5–23.CrossRefGoogle Scholar
  6. 6.
    Eric C. R. Hehner. A practical theory of programming. Springer Verlag, 1993.Google Scholar
  7. 7.
    Eric C. R. Hehner. Specifications, programs, and total correctness. Science of Computer Programming, 34(3):191–205, July 1999. Online http://www.elsevier.com/cas/tree/store/scico/sub/1999/34/3/563.pdf (last access: 09/05/2000).
  8. 8.
    C. A. R. Hoare and He Jifeng. Unifying Theories of Programming. Prentice Hall, 1998.Google Scholar
  9. 9.
    Mark B. Josephs. Specifying reactive systems in Z. Technical Report PRG-19-91, Programming Research Group, Oxford University Computing Laboratory, 1991.Google Scholar
  10. 10.
    K. Lano, J. Bicarregui, J. Fiadeiro, and A. Lopes. Specification of Required Nondeterminism. In John Fitzgerald, Cliff B. Jones, and Peter Lucas, editors, FME’97: Industrial Applications and Strengthened Foundations of Formal Methods (Proc. 4th Intl. Symposium of Formal Methods Europe, Graz, Austria, September 1997), Lecture Notes in Computer Science 1313, pages 298–317. Springer-Verlag, September 1997.Google Scholar
  11. 11.
    J. M. Spivey. The Z Notation: A Reference Manual. Prentice-Hall International Series in Computer Science. Prentice-Hall International (UK) Ltd., 2nd edition, 1992. Online: http://spivey.oriel.ox.ac.uk/~mike/zrm/index.html (last access 26/07/1998).
  12. 12.
    M.W.A. Steen, H. Bowman, J. Derrick, and E.A. Boiten. Disjunction of LOTOS specifications. In T. Mizuno, N. Shiratori, T. Higashino, and A. Togashi, editors, Formal Description Techniques and Protocol Specification, Testing and Verification: FORTE X / PSTV XVII’ 97, pages 177–192, Osaka, Japan, November 1997. Chapman & Hall. Online: http://www.cs.ukc.ac.uk/pubs/1997/350 (last access: 20/01/2000).
  13. 13.
    Ben Strulo. How Firing Conditions Help Inheritance. In Jonathan P. Bowen and Michael G. Hinchey, editors, ZUM’95: The Formal Specification Notation, Lecture Notes in Computer Science 967, pages 264–275. Springer Verlag, 1995.Google Scholar
  14. 14.
    Ian Toyn. Z Notation: Final Committee Draft, CD 13568.2, August24 1999. Online: http://www.cs.york.ac.uk/~ian/zstan/ (last access 09/05/2000).
  15. 15.
    S. H. Valentine. Inconsistency and Undefinedness in Z-A Practical Guide. In Andreas Fett, and Michael G. Hinchey, editors. ZUM’ 98: The Z Formal Specification Notation, Proceedings of the 11th International Conference of Z Users. Lecture Notes in Computer Science 1493. Springer Verlag, Berlin Heidelberg New York, September 1998 Bowen et al. [2], pages 233–249.CrossRefGoogle Scholar

Copyright information

© Springer-Verlag Berlin Heidelberg 2000

Authors and Affiliations

  • Ralph Miarka
    • 1
  • Eerke Boiten
    • 1
  • John Derrick
    • 1
  1. 1.Computing LaboratoryUniversity of KentCanterburyUK

Personalised recommendations