Andy Evans

An Improved Recipe for Specifying Reactive Systems in Z

How can a reactive system be specified in Z without having to use additional formalisms such as CSP or temporal logic? The conventional wisdom is that it cannot. Notations like Z and VDM traditionally describe a system as an abstract data type. Hence they concentrate on the static system behaviour: that is why they define operations using state before and state after. However, it seems clear that in order to specify a reactive system, dynamic behaviour must be described otherwise concurrent or real-time properties cannot be specified. It is this aspect which is entirely missing from conventional Z and VDM specifications. During the late eighties, Duke et al [DHKR88, DS89] provided a partial solution to this problem. They showed how a conventional Z specification could be augmented with an additional specification describing its reactive behaviour. Their approach was to informally introduce a relation, OP, to represent all the possible before and after states of the operations of the system being specified. The behaviour of the system was then formalised as the history of state and operation executions resulting from the repeated application of O P (with concurrent operations arbitrarily ordered). Unfortunately, the specification approach they adopted was partially informal, and was oriented towards one specific example. The aim of this paper is to show that this promising approach can be greatly improved and extended upon to the point where it can provide a practical method for specifying reactive systems in Z. It also adds to work originally presented in [Eva96b]. The four extensions made are:

A Formal Basis for Specifying Object Behaviour

In an earlier article [BE95] we outlined a project for formalizing some of the key concepts of object orientation (OO) as defined in the OMG’s (Object Management Group) core object model. Since OO is premised on interoperability and compatibility it is important that central aspects of the OO perspective provide a consistent basis for development and augmentation. In effect the OO world needs to have standards not only in the sense that there has to be some basis for effective but constrained development, reducing uncertainty and risk [95B]; but also because the essence of OO is cross-platform compatibility and reuse. The OMG’s core object model is one attempt to present a set of self-sufficient and consistent concepts which can act as a firm basis for the interdependence and further development of OO products and services. There are alternative approaches to the core object model, some of which may prove to be complementary; but given the size and visibility of the 0MG it is likely that some version or variant of the core object model will continue to figure in the OO world. OO demands universality and compatibility in some form, and it is more likely that it will be formed and sustained through a standard founded on cross-industry agreement than by monopoly or overwhelming cartel.

Fundamental approaches to software engineering

Plato believed in a “pure” reality, where ideas existed in their perfection into eternity. What we perceive as reality, he claimed, is merely a flawed shadow of this ideal world. Many mathematicians find this view appealing since it is precisely this universe of ideas that is the subject of their exploration and discovery. The computer, and more specifically, software, seem perfectly suited to this viewpoint. They allow us to create our own reality, one in which we can simply ignore the underlying physics, forget the tyranny of inertial mass, the drudgery of dealing with machinery that leaks or parts that do not quite fit. But, can we? Even in the ideal world with infinite resources, we have discovered that there are limits to computability. However, the situation with computers and software is much more dire than mere limits on what can be computed. As computers today play an indispensable part of our daily lives we find that more and more of the software in them needs to interact with the physical world. Unfortunately, the current generation of software technologies and practices are constructed around the old Platonic ideal. Standard wisdom in designing software encourages us to ignore the underlying technological platform D after all, it is likely to change in a few years anyway D and focus exclusively on the program “logic”. However, when physical distribution enters the picture, we find that mundane things such as transmission delays or component failures may have a major impact on that logic. The need to deal with this kind of raw physical “stuff” out of which the software is constructed has been relegated to highly specialised areas, such as real-time programming. The result is that we are singularly unprepared for the coming new generation of Internet-based software. Even languages that were nominally designed for this environment, such as Java, are lacking in this regard. For example, it has no facility to formally express that a communication between two remote parts must be performed within a specified time interval. In this talk, we first justify the need to account for the physical aspects when doing software design. We then describe a conceptual framework that allows us to formally specify and reason about such aspects. In particular, it requires that we significantly expand the concept of type as currently defined in software theory.