Eerke Albert Boiten

Refinement in Z and Object-Z

operation terminates possibly after any internal evolution then the concrete operation terminates after some internal evolution. Finally, in correctness every possible state after the concrete operation must be related by R to a possible state after the abstract operation, except that now after means an arbitrary number of internal operations may occur before and after the abstract operation. Although we do not have to check conditions for internal operations, the requirements on the observable operations mean that each concrete internal operation simulates zero (i.e., skip) or one or more abstract internal operations. Thus it is a useful sanity check to verify that R 1 eop; =? :3 AState • R 1 IntA for all concrete internal operations (i.e., for i E K). The absence of any requirements on internal operations does not mean that the rules allow arbitrary weakenings of their preconditions. The circumstances when preconditions can be weakenings are governed by what observable operations are present in the abstract specification, and the correctness rules for observable operations prevent the arbitrary weakening of preconditions of internal operations. Turning to the condition that prevents divergence, note that although internal operations decrease the variant E, there are no constraints on observable operations, which are allowed to increase the variant. This means that an internal operation can be invoked an infinite number of times, but not in an infinite sequence between observable operations. The conditions D1 and D2 are stronger than necessary: we could relax them to require only that divergence was reduced (rather than eliminated) in the concrete specification. We discuss this in Section 11.6 below. Defining the abbreviation (called the weak version of an operation Op) OPw to mean Int ~ Op ~ Int for an observable Op, we can rewrite the three refinement conditions as V eState • elnitw =? :3 AState • Alnitw 1 R V A State; eState. pre A Op 1 R =? pre eop V AState; eState; eState • pre AOp 1 R 1 eopw =? :3 AState • R 1 AOpw To see the rules in practice let us revisit the examples that we introduced earlier. Example 11.2.2. If we look at Timed2D1 from Example 11.0.1 we see that it is not a weak refinement of 2D because the internal operation Tick1 can introduce divergence, i.e., it breaks the divergence criteria D1 and D2. In a similar way the Plane specifications from Example 11.1.2 are not related by weak refinement because the internal operations introduce divergence. However, Timed2D2 is a valid weak refinement of 2D. To see this note first that there are no internal operations in 2D. Secondly, we note that 262 11. Weak Refinement Tick2 does not change the effect of any other variable apart from clock, and therefore does not alter the effect of the observable operations. This means that the conditions on the observable operations hold. Although we do not have to verify the correctness of Tick2 it does indeed hold since R 1 Tick2 => :3 2D • 52D 1 R. The divergence criteria in this case are also trivial (N being the set WF). 0 Example 11. 2. 3. Another variant of the two-dimensional world 2D is the following specification where the effect of Move is non-deterministic to the observer, but determined elsewhere by the internal operation SetNext. The Boolean nextset is manipulated in such a way that Move and SetNext can only happen alternately. 2Det ________________ __ x, y, nextx, nexty : Z nextset : bool Init __________ _ 2Det X = 01 y = 0 --,nextset fYhere _________ _ 52Det x!,y!: Z x! = x 1 y! = y MoveDet ____________ _ L12Det nextset 1 --,nextset x = nextx 1 y = nexty SetNext ________ _ L12Det x = x 1 y = y --,nextset 1 nextset Here the internal operation SetNext is a refinement of skip when the obvious simulation is used. However, MoveDet (a partial operation) can only be a refinement of the total operation Move when the simulation does not relate concrete states outside pre MoveDet to any abstract states, i.e., those concrete states (where --,nextset) are unreachable. From the fact that the concrete initialisation requires --,nextset we must then conclude that this description is not a standard refinement of 2D. However, this specification is a weak refinement of the original 2D system. To see this first calculate Int. Doing so we find it evaluates to 52Det V SetNext. Initialisation then requires (using the identity retrieve on 2D) V 2Det • (x = 01 y = 0) => :3 2D • (x = 01 y = 0) which is trivial, as are the conditions upon fYhere. For the Move operation applicability requires that R => pre(Int ~ MoveDet) This is again trivial since the predicate of pre(Int g MoveDet) evaluates to true. For correctness we need 11.2 Weak Refinement 263 Int ~ MoveDet ~ Int => Move Finally, we note there is no divergence since any two occurrences of SetNext have to be separated by an observable MoveDet. 0 11.2.3 Further Examples Here are two further examples which are more complicated than the ones we have looked at so far. Example 11.2.4. We describe a small aspect of a time service mechanism which is concerned with the synchronisation between clocks in a distributed system. We are given a finite set of NODES where each node has a type (either slave or master), and has an associated time given by its clock. In the fragment we look at here we are interested in the setting of the clocks when the master node has counted down to 1. When this happens the clock on the master node is set to a special value syncfreq and the clocks on the other nodes are set to a watchdog value. The watchdog value is the time-out period used by slave nodes, and the sync_freq value is the time-out period used by the master node. The system is constrained to ensure that watchdog is greater than sync_freq. In our initial description the process is specified as a single observable Tick operation. Tick is composed of two parts: Dec decreases the timer if the clock has not reached 1, and if it has Set sets the timers and the types. [NODES] NTYPE ::= master I slave PHASEA ::= idle I completed syncfreq, watchdog : N syncfreq < watchdog ATS ____________________________________ ___ typeA : NODES -t NTYPE timerA : NODES -t N1 phaseA : PHASEA phaseA = completed => 31 n : NODES. typeA(n) = master InitA ______________________ _ FATS phaseA = idle 264 11. Weak Refinement DecA ____________________________________________ ___ LlATS n?: NODES phaseA = idle timerA(n?) > 1 timerA = timer A EB {n? H timerA (n?) I} typeA = typeA phaseA = phaseA SetA ____________________________________________ ___ LlATS n?: NODES phaseA = idle typeA(n?) = master timer A (n?) = 1 timerA = {(n, m) ! (n = n? / m = sync_freq)V (n::j:. n? / m = watchdog)} typeA = {(n, s) ! (n = n? / s = master) V (n ::j:. n? / s = slave)} phaseA = completed TickA == DecA V SetA We refine this description to one in which the observable TickA operatioJ is decomposed into an observable Ticke operation and an internal Updat operation. The Ticke operation deals with the settings of the master nod and the Update completes the process by visiting each remaining node iJ turn. To describe this we introduce a new updating state, and record the se of nodes that we have visited. PHASEe ::= idle! updating! completed CTS ______________________________________________________ ___ typee : NODES -+ NTYPE timere : NODES -+ Nl visited: JP> NODES phasee : PHASEe phasee = completed =} visited = NODES [nite ____________________________________________ _ CTS visited = 0 phasec = idle 11.2 Weak Refinement 265 The concrete Dec part of the operation is essentially the same as the abstract version, but in Set we mark the node as visited and enter an updating phase. Decc ____________________________________________ __ LlCTS n?: NODES phasec = idle timerc(n?) > 1 timerc = timerc EEl {n? M timerc(n?) -I} typec = typec phasec = phasec visited = visited Setc __________________________________________ ___ LlCTS n?: NODES phasec = idle typec(n?) = master timerc(n?) = 1 timerc = timerc EEl {n? M syne_freq} typec = typec phasec = updating visited = {n?} Tiekc == Deec V Setc In an updating phase the internal Update operation can be applied. This visits one more node and is applicable until all the nodes have been visited. Update __________________________________________ _ LlCTS phasec = updating :3x: NODES. (x .;. visited / visited = visited U {x} / timerc = timerc EEl {x M watchdog} / typec = typeC EEl {x M slave} ) visited = NODES ~ phasec = completed visited f:. NODES ~ phasec = phasec The concrete description is a weak refinement of the abstract. 266 11. Weak Refinement To see this first note that the variant that guarantees no divergence is E = #( NODES visited). Thus the correctness of the refinement depends on the eventual implementation of the given type NODES by a finite type. Next note that Update is only applicable in the updating phase, this means that the internal operation does not playa role in the initialisation or applicability conditions. To verify these we need to write down the retrieve relation the following will suffice. R ________________________________________ __ ATS CTS phaseA = idle {:} phasec = idle phasec E {updating, completed} ::} phaseA = completed phasec E {idle, completed} ::} typec = typeA / timerc = timerA phasec = updating::} visited <l typec = visited <l typeA phasec = updating::} visited <l timerc = visited <l timer A The retrieve relation expresses the idea that in an updating phase typec and typeA will be equal on visited (and similarly for timer). Since visited increases and NODES is finite, the approximation eventually terminates. With this retrieve in place initialisation and applicability follow. For correctness we note that Update plays no part until the clock reaches 1, when it has it is easy to see that Tickc ~ Int has the same effect as TickA. 0 Example 11.2.5. At an abstract level the process of delivering email can be considered

Viewpoint consistency in ODP

Open Distributed Processing (ODP) is a joint ITU/ISO standardisation framework for constructing distributed systems in a multi-vendor environment. Central to the ODP approach is the use of viewpoints for specification and design. Inherent in any viewpoint approach is the need to check and manage the consistency of viewpoints. In previous work we have described techniques for consistency checking, refinement, and translation between viewpoint specifications, in particular for LOTOS and Z/Object-Z. Here we present an overview of our work, motivated by a case study combining these techniques in order to show consistency between viewpoints specified in LOTOS and Object-Z.

A Formal Framework for Viewpoint Consistency

Multiple Viewpoint models of system development are becoming increasingly important. Each viewpoint offers a different perspective on the target system and system development involves parallel refinement of the multiple views. Viewpoints related approaches have been considered in a number of different guises by a spectrum of researchers. Our work particularly focuses on the use of viewpoints in Open Distributed Processing (ODP) which is an ISO/ITU standardisation framework. The requirements of viewpoints modelling in ODP are very broad and, hence, demanding. Multiple viewpoints, though, prompt the issue of consistency between viewpoints. This paper describes a very general interpretation of consistency which we argue is broad enough to meet the requirements of consistency in ODP. We present a formal framework for this general interpretation; highlight basic properties of the interpretation and locate restricted classes of consistency. Strategies for checking consistency are also investigated. Throughout we illustrate our theory using the formal description technique LOTOS. Thus, the paper also characterises the nature of and options for consistency checking in LOTOS.

Relational Concurrent Refinement

Refinement in a concurrent context, as typified by a process algebra, takes a number of different forms depending on what is considered observable. Observations record, for example, which events a system is prepared to accept or refuse. Concurrent refinement relations include trace refinement, failures–divergences refinement, readiness refinement and bisimulation. Refinement in a state-based language such as Z, on the other hand, is defined using a relational model in terms of the input–output behaviour of abstract programs. These refinements are normally verified by using two simulation rules which help make the verification tractable. This paper unifies these two standpoints by generalising the standard relational model to include additional observable aspects. These are chosen in such a way that they represent exactly the notions of observation embedded in the various concurrent refinement relations. As a consequence, simulation rules for the tractable verification of concurrent refinement can be derived. We develop such simulation rules for failures–divergences refinement and readiness refinement in particular, using an alternative relational model in the latter case.

Testing refinements of state-based formal specifications

A specification provides a concise description of a system, and can be used as both the benchmark against which any implementation is tested, and also as a means to generate tests. Formal specifications have potential advantages over informal descriptions because they offer the possibility of reducing the costs of testing by automating part of the testing process. This observation has led to considerable interest in developing test generation techniques from formal specifications, and a number of different methods have been derived for state‐based formalisms such as Z, B and VDM. However, after tests have been derived from a formal specification, the specification might be refined further before it is implemented, and therefore a mechanism is needed to relate the abstract tests to the refined implementation.

Constructive consistency checking for partial specification

Partial specification is a method of specifying complex systems in which the system is described by a collection of specifications, each approaching the system from a different viewpoint. The specification notation Z is often advocated as a suitable language for this style of specification. For collections of partial specifications to be meaningful, they need to be consistent, i.e. they should not impose contradictory requirements. This paper addresses how the consistency between partial specifications in Z can be checked, by constructing unifications, i.e. least common refinements, of viewpoint specifications.

Viewpoint Consistency in Z and LOTOS: A Case Study

Specification by viewpoints is advocated as a suitable method of specifying complex systems. Each viewpoint describes the envisaged system from a particular perspective, using concepts and specification languages best suited for that perspective.

Non-atomic Refinement in Z

This paper discusses the refinement of systems specified in Z when we relax the assumption that the refinement will preserve the atomicity of operations. Data refinement is a well established technique for transforming specifications of abstract data types into ones which are closer to an eventual implementation. To verify a refinement a retrieve relation is used which relates the concrete to abstract states and allow the comparison between the data types to be made on a step by step basis by comparing an abstract operation with its concrete counterpart. A step by step comparison is possible because the two abstract data types are assumed to be conformal, i.e. there is a one-one correspondence between abstract and concrete operations, so each abstract operation has a concrete counterpart. In this paper we relax that assumption to discuss refinements where an abstract operation is refined by, not one, but a sequence of concrete operations. Such non-conformal or nonatomic refinements arise naturally in a number of settings and we illustrate our derivations with a simple example of a bank accounting system.

Consistency and Refinement for Partial Specification in Z

This paper discusses theoretical background for the use of Z as a language for partial specification, in particular techniques for checking consistency between viewpoint specifications. The main technique used is unification, i.e. finding a (candidate) least common refinement. The corresponding notion of consistency between specifications turns out to be different from the known notions of consistency for single Z specifications. A key role is played by correspondence relations between the data types used in the various viewpoints.

Specifying and Refining Internal Operations in Z

Abstract. An important aspect in the specification of distributed systems is the nrole of the internal (or unobservable) operation. Such operations are not part of the interface to the environment (i.e. the user cannot invoke them), however, they are essential to our understanding and correct modelling of the system. In this paper we are interested in the use of the formal specification notation Z for the description of distributed systems. Various conventions have been employed to model internal operations when specifying such systems in Z. If internal operations are distinguished in the specification notation, then refinement needs to deal with internal operations in appropriate ways.Using an example of a telecommunications protocol we show that standard Z refinement is inappropriate for refining a system when internal operations are specified explicitly. We present a generalisation of Z refinement, called weak refinement, which treats internal operations differently from observable operations when refining a system. We discuss the role of internal operations in a Z specification, and in particular whether an equivalent specification not containing internal operations can be found. The nature of divergence through livelock is also discussed.