Observation and Abstract Behaviour in Speciﬁcation and Implementation of State-based Systems

Classical algebraic speciﬁcation is an accepted framework for speciﬁcation. A criticism which applies is the fact that it is functional, not based on a notion of state as most software development and implementation languages are. We formalise the idea of a state-based object or abstract machine using algebraic means. In contrast to similar approaches we consider dynamic logic instead of equational logic as the framework for speciﬁcation and implementation. The advantage is a more expressive language allowing us to specify safety and liveness conditions. It also allows a clearer distinction of functional and state-based parts which require different treatment in order to achieve behavioural abstraction when necessary. We shall in particular focus on abstract behaviour and observation. A behavioural notion of satisfaction for state-elements is needed in order to abstract from irrelevant details of the state realisation.


Introduction
Algebraic methods have been widely used in the specification of computer systems.Algebraic specification refers to the use of algebraic semantics and equational reasoning for functional systems [1].During the last decade, algebraic methods have been used to support the more wide-spread state-based software development.Examples of state-based specification include the pre/post-condition technique originally developed by Hoare [2,3].This formal technique has found its way into various software development approaches and languages such as the UML Object Constraint Language [4] or the design-by-contract approach [5].The pre/post-condition technique can be extended or generalised in various ways [6].We shall address the more general framework of dynamic logic here, including pre-and postconditions.We shall in particular address semantic foundations for a framework for observational specification of state-based systems in this paper.This shall result in a more flexible specification and implementation framework for state-based systems.
A classical example of the usefulness of obervational specification is the realisation of a data type boolean using an implementation of a type integer.The data values needed to interpret terms formulated based on boolean constructors (e.g.true and not) form only a subset of a carrier set for integers.We expect boolean axioms only to hold within this subset.An observability predicate can declare those substructures reachable with boolean constructors as observable.Observation and behaviour oriented extensions to the algebraic specification of data types exist (e.g.[7,8,9,10,11,12,13,14]), but similar approaches to state-based specification are still lacking.We aim to provide semantical foundations for such a framework of behaviour and observation in the context of state-based systems.
We shall give an outline of our approach here.The classical notion of signatures is extended by introducing hidden, non-observable sorts representing an internal state.Semantic structures interpreting these signatures provide suitable elements.Slightly different techniques apply for defining and reasoning about functional and state-based parts.One 5th Irish Workshop on Formal Methods IWFM'01 of the most well-known approaches to these problems is the hidden algebra framework developed by the OBJ-group, see e.g.[15,16].There, an equational, behaviourally oriented framework for reasoning is established.We follow the hidden algebra approach in its basic idea: we provide signatures with a distinguished state sort, and interpret these in structures with a local state, called objects.An early version of this model has been presented in [17].Then, we deviate from the path by using concepts from modal logics to introduce a specification and reasoning framework.A dynamic logic will be used.Modal logics, such as dynamic and temporal logics, provide constructs that will allow us to specify safety as well as liveness constraints -a wider range of properties than with equational logics.Safety properties shall guarantee that unwanted things will not occur, and liveness properties should ensure that wanted things will eventually occur.These properties are in particular important in the specification of dynamic and reactive systems.Our particular interest lies in the implementation of specifications.In implementing a specification it has to be shown that the implementation satisfies the abstract requirements of the specifications.In order to allow the simpler equational reasoning to be used, we complement a dynamic logic based implementation with a refinement notion which needs equational reasoning only in proofs.We consider data and operation refinement and show how they relate to the paradigm of observational or behavioural specification, namely, that formulas need only to be true under all possible experiments (or observations).
We start with our semantic model in Section 2.Then, in Section 3, we present the dynamic logic.Section 4 introduces basic concepts for behavioural specifications.In Section 5, we look at data refinement based on behavioural abstraction.In Section 6, the operation refinement is investigated.Proofs, if they are not given here, can be found in [18].

A State-based Model
The main building blocks of our computational model -signatures with state, objects as the corresponding models, and an interpretation -shall be formalised in this section.The objective is to formalise the notion of an object -an algebraic entity that encapsulates a local state.
We assume a set of sorts S o r tincluding data sorts s 1 ; s 2 ; : : : and the distinguished sort state, and a set of identifiers I d .For each state signature in a class of signatures S i gwe define: a mapping sorts : S i g! P S o r twith state 2 sorts, a mapping attr : S i g! P I d with a signature siga = s 1 : : : s n !s for each attribute a 2 attr with s 1 ; : : : ; s n ; s 2 sorts , f stateg 1 the state sort state as attr !sigattr a mapping tran : S i g! P I d with a signature sigp = state s 1 : : : s m !state s for each transition p 2 tran.
Basic sorts -not including state -are typically data types used in the definition of attributes.We assume a built-in sort bool with the usual constants and functions.The set of attributes, variables (nullary functions) and other functions, forms an explicit, but still abstract state.The state itself is represented as an assignment, associating attribute identifiers with functions.These functions are the only means to inspect the state content.Transitions are parameterised state transformers, transforming one state into another, also yielding a functional result value.
Example 2.1 Sample sorts in a stack data type are the stack content stack -which shall represent the state-sortand the data type elem.The following is a signature: sorts = fstate; elem; boolg attr = ftop :! elem; is f u l l :! boolg tran = fpush : state elem !state; pop : state !stateg 1 a can be a nullary symbol, then called a state variable.
An example for an attribute is sigtop = !elem.Examples for transitions are sigpush = stackelem !stack or sigpop = stack !stack.
A hidden signature [15] is a signature with disjoint hidden and visible sorts.The signature ensures data encapsulation: a hidden signature can only be embedded into a visible one, if no new operations are added to the signature.Components and transitions depend on the state.Clearly, our state signatures are hidden signatures in the sense of [16].
A state signature morphism is a signature morphism where Sort state is the identity, and for any operation op 2 attr tran with sigop = a 1 : : : a i !b 1 : : : b j we require sig Op op = Sort a 1 : : : A signature induces a set of syntactically correct expressions, constructed by free variables and the operation names of the signature.In many-sorted signatures, a sort will be associated with each term.Let X = X s s2sorts be a sorts-sorted set of free variables.The functions 1 and 2 are projections onto the first and second component of their argument, respectively.
-terms of data sort s 2 -objects can be seen as abstract machines with operations as instructions.Initial states (and the ability to specify properties of the initial state) are essential in the context of dynamic or reactive systems.Underlying each of these models, we assume an equationally specified algebra, realising the data type(s) used in the definition of the attributes.
These algebras are static, i.e. their functions can not be changed by state transitions.-objects are extensions of these algebras.The state can also be seen as an algebra consisting of carrier sets for data sorts and functions for the attributes.The -state algebra for a -object shall be defined as the algebra consisting of carrier sets for the data sorts (excluding state) and functions for the attributes attr.The signature consists of the data sorts and attribute signatures of .This shows that -objects fit into the states-as-algebras paradigm.
A hidden algebra is an algebra which satisfies a hidden specification based on a hidden signature [15].A hidden algebra should encapsulate an algebra as a substructure (reduct) which represents the data part.Our objects are hidden algebras in this sense.
A -object involves bindings: functions are bound to attribute and transition identifiers.A state S Tof sort state can be modified by transitions.We need a substitution mechanism on states.The expression substituteS T;x7 !v substitutes in the mapping S Tthe former binding for an identifier x by a binding of x to the value val: Domain and range of S Tshall be disjoint.Then, x cannot occur in val.
A mapping v from identifiers to semantical entities is called a valuation; its inductively defined extension v for arbitrary terms is called an interpretation.Each term depends on the current state.Let S T: state be a state, i.e., an assignment2 of functions to identifiers.

vS T;x : = S Tx
The value of an identifier x is stored in S Tremember the definition of sort state: state = attr !sigattr, i.e., that the state associates attributes and functions.
v S T;a a 1 ; : : : ; a n := S Tav S T;a 1 ; : : : ; v S T;a n v S T;p S T;a 1 ; : : : ; a m := p S T;v S T;a 1 ; : : : ; v S T;a m The definition of an attribute a can be modified, thus we have to reinterpret a in each current state S T. Transitions p might modify the definition of attributes.The brackets : are used to denote the function which realises a transition symbol.
Finally, we introduce a definedness predicate: DS T;t = true, if v S T;t 6 = ?for some state S T.

State Transition Logic
Modal logics assume structures with a notion of state or time [19,20].The presented model of -objects is such a structure.Dynamic logic, a particular modal logic, is a first-order predicate logic with a notion of state, which generalises Hoare-logic.Based on these logics, we will introduce a simple dynamic logic.A proof system is not presented here, see [18] for a sound and relatively complete one for a general dynamic logic and [21] for one geared towards the use in refinement calculi.
The state transition formula !P -where is a precondition, P is a command (a term of sort state) and is a postcondition -describes a state transition axiomatically.The operator : : is called the modal box-or always-operator.
and describe properties of attributes by classical first-order formulas.The formula !P holds in a current state S Tin a -object A, if in case holds in S Tand, if P terminates, then has to hold in the following state.The second modal operator is the so-called diamond-or eventually-operator.This operator allows us to specify liveness properties.The formula P expresses that P has a terminating path after which holds.In case of determinsitic programs, it says that P will terminate and holds afterwards.For example, P true is a termination assertion.These constructs will be defined formally later on.
Example 3.1 The effect of the stack transition push can be specified by :is full() !push(st,e) top()=e If the precondition -the stack is not full -is satisfied, then executing push(st,e) on stack st has the effect that e is the new top element.is full() !push(st,e) true push should terminate if the stack is full (whatever the result might be).
Let be a state signature and X a sorts-sorted set of free variables.A -equation has the form t = s t 0 with t; t 0 2 T; X s for a data sort s.A state -equation has the form t = state t 0 with t; t 0 2 T; X state .The set of well-formed formulas WFF is the smallest set with the following properties3 : all -equations and state -equations are in WFF, if ; 2 WFF, then ! 2 WFF, if P is a command and 2 WFF, then P 2 WFF and P 2 WFF.
We define the diamond operator as follows: P := : P : An operator prev shall also be defined.The operator refers to the value of an argument variable in the previous state of the command P under consideration.Typically, the prev operator is used to specify the new value of a variable in terms of the old value, e.g.P a = preva + 1.
A specification M is a pair M = h; E i consisting of a state-based signature and a set E of well-formed formulas E WFF, including an non-modal formula Init.Init is a non-modal formula characterising the initial state of a -object.:is f u l l !pushst; e top = e top = e !pushst; e 0 ; popst top = e is f u l l !pushst; e true The state is the content of the stack, elem is the element sort.The element e shall be of sort elem and st of sort state.This example assumes that a sequence operator ; is defined on transitions.This is not a complete specification of a stack as it, for example, does not specify the effect of pop on empty stacks.
As we have seen in the example, command combinators such as the sequence ';' are useful.We define the combinators ; (sequence), + (non-deterministic choice), and (iteration): v S T;p ; q : = v 1 v S T;p ; q v S T;p+ q : = v S T;p or v S T;q -non-deterministically chosen v S T;p : = v 1 : : : 1 v S T;p ; p ; : : : ; p For two of them, we can find simple axiomatisations: p; q , p q p + q , p _ q A notion of satisfaction relates formulas and -objects.Let v be a valuation based on states and v an interpretation.Assume a -object A, a state S T2 State and a -formula .A satisfies in state S T, or A; ST j = , is defined by A; ST j = t = s t 0 i v S T;t = v S T;t 0 for a data sort s A; ST j = t = state t 0 i v 1 v S T;t ; a a 1 ; : : : ; a nc = v 1 v S T;t 0 ; a a 1 ; : : : ; a nc for all at- tribute applications A; ST j = !i : _ The class of all -objects is denoted with Obj.The models of a specification M = h; E i are denoted by their model class.
modh; E i : = fA 2 Obj j A; ST j = for all 2 E and S T2 Stateg Note that E contains an initial state condition, i.e. models are only those objects whose designated initial state satisfies that condition.Model construction not requiring closedness with respect to isomorphism is usually called loose.Here, even reachability -the no-junk property -is not required.We call this model semantics very loose.
We will also introduce notions of a model of a transition and a respective satisfaction relation.Let a transition p in M 1 be specified by 1 !p

u t 4 Observational Specification
Let us look at notions of behavioural and observational specification now.We briefly present some basic constructs used in the majority of observational algebraic specification, see e.g.[11,13,14,16].
Definition 4.1 Let be any signature.A -context is a -term, which contains exactly one special variable z s for each sort s.The variables z s are used as meta-variables for terms of a specific sort.c t : = c z s =t for t : s The variable z s can be substituted by t in the term c.
This shall be illustrated by a stack example.
Example 4.1 topz shall be a context with special variable z.Then, the equation poppushs; e = s does not need to hold, only the application of the observational context to the equation: toppoppushs; e = tops poppushs; e and s substitute z.
In our approach, we would model push and pop as procedures, since they modify the state, here the stack.top would be an attribute.
top = e !seqpushe 0 ; pop top = e This guarantees that only observations on the state using top are relevant.This is already behaviourally oriented.We have also defined a behavioural satisfaction for equations on state.
The standard equality can be generalised in observational approaches: two terms shall be considered equal, if they cannot be distinguished through observations.An observational predicate Obscan be applied to any terms that denote carriers.There is an observational subset for each carrier set.Then the specification M -as in Example 3.2 -is an implementation of N, i.e.N !I M. The specification M is more specific since it defines the behaviour for full stacks.
We will consider implementations later on in Section 6.In order to prove correct implementations in behavioural settings, for example context induction can be applied.The induction is based on the application of observational contexts to ground terms, see work by Hennicker and Bidoit [10,14] and also work on co-induction, e.g.[16].

Data Refinement
Our notion of satisfaction is already defined on the idea of observational behaviour (cf.Section 3).Internal properties of the state are invisible.They can only be inspected by attributes.The notion of observation is in particular important if implementation is taken into consideration.In implementation, concepts are realised whose properties are not relevant with respect to some abstract specification.Still, implementations shall be considered correct if they satisfy some abstract observational behaviour.
Considering the process of implementing and refining specifications and the necessity of proving the correctness of those, we find that we need means to abstract from implementation details in order to prove that implementations show the same observational behaviour as the specifications.We have used a very loose semantics for specifications, i.e. not all carrier elements need to be representable by terms, i.e. are reachable.We have ignored reachability in order to obtain a widely defined notion of models.Non-reachable elements will be accepted, since they do not influence the behaviour of models.This allows the implementation of specifications based on libraries of existing standard implementations (for example basic data types), which might not match specifications exactly.Due to this requirement, the very loose semantics approach is sensible.The principle problem with models including non-reachable elements -that structural induction based on the syntactic structure is not possible -can be countered by using the Obspredicate.

Example 5.2 With the formula
Obs ftrue;f alse;notgint t !notnott = t we specify that notnott = t shall only hold (and needs to be proved) in a substructure reachable with true, f a l s e and not.
We can verify in the substructures defined through the Obs-predicate.Another use of the Obs-predicate shall be introduced.Obscan be used to define constructors.The term 'observational' indicates that more than reachability is aimed at.Observability allows to relax a correctness condition for implementations.The predicate Obs 0 can be defined for every subsignature 0 of .Obs 0 t shall express that a carrier element v S T;t can be denoted by a 0 -ground term: Obs 0 t iff 9t 0 2 T 0 : v S T;t = v S T;t 0 for t : s and any state S T Since we are talking about reachability or observability in the context of sorts or specific operation symbols, we offer three forms to describe the signature 0 of the predicate Obs 0 : 0 : any subsignature 0 of a given signature , s : a sort s indicating that only elements of this sort are relevant, fop1;:::;opngs : a list of selected operation symbols of a given sort s.
We have seen an example of the last form -which is the most general form -in Examples 5.1 and 5.2.An example for the second form can be found in Example 5.3.
We introduce two abbreviations.Firstly, a relativised universal quantification 8x : s: Obs x ! or short 8x : : : for all elements holds or they are not reachable, i.e., hold for all reachable elements.Secondly, a relativised existential quantification 9x : s: Obs x^ or short 9x : : : there are observable element for which holds.With Obs 0 and = 0 we model reachability.With A Obs we shall denote the observable '-subobject for a -object A: a 2 Obs A 0 s iff 9t 2 T 0 s with a = v S T;t for s 6 = state and any state S T This is a standard definition based on elements reachable via ground terms of the subsignature.We construct the observable subobject as follows: A Obs s := Obs A 0 s for data sorts s 2 sorts , f stateg, A Obs state := Obs A 0 state for sort state, op Obs A := op A jObs5 for any operation op 2 attr tran, S T Obs := S Tfor S T2 A Obs state .

Lemma 5.1
The observable 0 -subobject of A is a 0 -object.
Proof: Follows from the definition of a -object and observable -subobjects.2 Satisfaction with respect to observable substructures can be expressed by: A Obs ; S T j = Obs 0 t iff DS T;t for t 2 T 0 Lemma 5.2 Let A be model of a specification ; E and let t be a -term of sort s.Then: A; ST j = Obs 0 t iff 0 and v S T;t 2 Obs A 0 s Proof: Follows from the definitions of the satisfaction of Obsand observable subobjects. 2 In order to illustrate how to implement a data type, we use the data type set, which shall be implemented based on an existing model of tuples.The implementation shall be formalised through model class inclusion, i.e., M 0 implements The resulting set specification will still be an abstract specification.
We will implement sets of natural numbers on tuples of integers.In the set of integers, only natural numbers shall be observable.The example illustrates the main application of the observability predicate: to realise a specification using another, existing one.Examples are the realisation of boolean values on a data type integer or sets on a data type list/tuple.This allows a developer to realise a specification based on suitable, existing library components.Typically, the boolean or set terms (generated by their constructors) are only interpreted in subsets of the integer or list carriers, respectively.
With the Obspredicate, we can declare these subsets as observable and reason within these substructures.The technique can also be used to define export interface for existing specifications (e.g., restricting the set of constructors).
The definition of the Obspredicate has been illustrated using familiar data sort specification and implementation so far; the sort state has been excluded.The predicate Obs state for sort state works in the same way as Obs s for data sorts s.Applied to states it would express the reachability or observability of states, i.e., whether there is a path from an initial state to the state under consideration.
The technique of observation-based specification can also be applied to the sort state.Instead of applying the Obs predicate to constructors of data types such as boolean or set -as in the previous example -we can also use constructors of sort state.Applied to the stack object that has been specified in previous examples, these constructors would be a constant empty stack and the push and pop operations.We could realise a stack on a list object.There might be a executable implementation for a list object specification in some component library.We assume a list object specification with the usual operations (head, tail, a list constructor, concatenation) for this example.This describes the implementation of stacks in terms of lists more explicitly.

Operation Refinement
An implementation between two specifications M and M 0 , M !I M 0 shall be defined based on model class inclusion, i.e. we require M o d M 0 M o d M. Model class inclusion formally captures the idea of making design decisions: there are less models if requirements are added or strengthened 6 .Model class inclusion guarantees that properties established for a specification are preserved in an implementation.We have not used the M o d OBS -construction introduced in Section 4 here, instead we use the variant from Section 3. As we have already pointed out, this incorporates the concept of observation.How to develop a more substantial refinement approach is described in [21].Technical details of this section including proofs can be found in [18].
An inference rule shall be introduced.The consequence rule helps to prove pre/postcondition specifications: ! 0 ; !P ; 0 ! 0!P 0 This rule will be useful in the definition of a constructive variant of an implementation relation, called refinement, between specifications.
Example 6.1 Consider the following formula: :is f u l l !pushst; e top = e Then the formula true !pushst; e top = e ^:is empty is a consequence of the first formula, since top = e ^:is empty !top = e and :is f u l l !true.The postcondition is strengthened and the precondition is weakened.
We define a few other relations between specifications.Let p 1 ; p 2 be transitions with the same signature and p1 !p 1 p1 and p2 !p 2 p2 be their respective specifications.This is usually called the vertical composition property -a useful property for implementation relations.
In order to relate the two relations !I and !R , we assume the three simplifications.
There are no explicit invariants inv7 .They will be associated to transition definitions: reformulate !P to !P ^inv.
There are only transition specifications, i.e. box-and diamond operators and equations on sort state.Attributes are specified by normal first-order formulas and can be treated as invariants.
Every transition is defined by only one formula -as justified in Lemma 6.2 below.
The following lemma needs the expressiveness of the base logic as a prerequisite -this shall be assumed here.In [18] Section 3.4, we have addressed the question of expressiveness in this context.A similar lemma can be derived for the diamond-operator.Lemma 6.2 Any set of formulas f i !P i j i = 1 ; : : : ; n g can be transformed into a formula !P , which holds iff all formulas i !P i hold.
There is a related requirement for the equational specification of hidden algebras, see [15], saying that equations on data sorts are not allowed in that framework.Any such equation has to be asserted and proved separately.
We have already seen that the refinement is compositional, i.e., the refinement between specifications depends on the refinement between the constituent transitions -by definition.The following lemma shows that the implementation is compositional in the same way.Carrier sets, the state S T, and functions interpreting state observers do not need to be considered.
Lemma 6.3 Let M 1 ; M 2 be specifications with sigM 1 sigM 2 under the assumptions specified above.If for all transitions t 2 transigM 1 the inclusion mod tr M2 t mod tr M1 t holds, then modM 2 j sigM1 modM 1 , or M 1 !I M 2 .Now, we state the essential theorem of this section, i.e., that the refinement is a specialisation of the implementation.Theorem 6.1 Let M 1 ; M 2 be specifications under the assumptions specified above.Then it holds: The proof relies essentially on the compositionality of the underlying relations on transitions.
This theorem allows us to prove an implementation using the refinement.The refinement is a good approximation to the implementation since the only cases excluded are models which contain functions which do not terminate, formulas (describing states) that cannot be satisfied, and preconditions that describe states unreachable by transitions.
The refinement is only based on two non-modal first-order implications.Standard equational reasoning can be applied here.

Related Work
Our work is clearly motivated by observational and behavioural extensions to the algebraic specification approach, in particular by work from Bidoit, Broy, Hennicker, and Wirsing [7,8,9,10,11,12,13,14].Wirsing and Broy introduce ultra loose semantics, allowing behavioural abstractions by a notion of relativised quantification.This compares to the introduction of relativised quantifications 8x : : and 9x : : here in Section 5. Bidoit and Hennicker's approach is based on a partial observational equality.Our concepts are similar to ideas of using an explicit observability predicate as presented by Hennicker in [8,11].We have adapted some of his ideas to the context of state-based specification and dynamic logic.Some detailed comparisons have been made in Section 5.
Other techniques of refinement and implementation for algebraically specified systems are based on a strategy of applying different implementation, restriction and other specificaton-building operations, see [9] Chapter 8 or [22].
We have tried to capture the idea of implementation or refinement in a single construct.
The idea of using modal logics as logics for state-based specification and implementation is not new.A few examples include the specification language COLD [23,24] or the Modal Action Logic [25,26] and successive work [27,28].
Recently, modal logics have also been used in the context of coalgebras.An example is [29], where coalgebras are used to define the semantics for object-oriented programming supported by a modal logic.Coalgebras can generalise transition systems, and modal logics are a natural choice to capture this in a logic.The approach taken by the developers of hidden algebras [15,16] -on which our semantical structures are based -follow the same direction.
We have used a dynamic logic, i.e., a modal logic that makes commands explicit.Modalities are indexed by commands.Another form of modal logics -temporal logics -are also suitable for the specification and development of state-based systems.In particular TLA (the Temporal Logic of Actions) [30,31] offers advanced concepts for implementation and refinement.We have chosen a dynamic logic since it provides the more adequate theory for the support of the pre/post-condition technique.
Finally, we shall briefly address our own related work.The basic formal framework -excluding observational aspects -is presented in [18].Two of our papers extend the ideas of operation refinement: [21] presents refinement ideas for the ASM (Abstract State Machines) notation, [32] is based on the idea of refinement as the matching technique for component composition.

Conclusions
We have presented a framework for specifying and developing state-based systems based on the idea of behavioural reasoning and observational implementation.In contrast to related approaches we have used a dynamic logic instead of an equational logic.Modal logics give us more expressive power in the specification of dynamic and reactive systems.The principle disadvantage of reasoning about implementations with the more complex modal logics is compensated using an equationally oriented refinement notion and the definition of observable substructures.One of our objectives is to develop an extension of the pre/post-condition technique for state-based systems, which would allow an improved technique to be used in component-based development approaches considering non-determinism and liveness besides the safety-specification of the classical pre-and postcondition technique.It allows us to use equational reasoning to prove dynamic systems using a refinement inference rule a the key tool.
We have seen that a behavioural notion of implementation is needed for state-based specification where we want to abstract from the realisation of the state itself.Observation is a useful tool in the realisation of specifications based on existing libraries of execuatble components.Our notion of satisfaction for the modal operators and equations on the state sort satisfy this requirement.Our data refinement notion is observational, based on the idea of relativisation.
We can specify dynamic state-based systems solely using modal constructors and equations of sort state.In most situations implementations can be proved using the equational refinement relation.A further step in improving the implementation of abstract specifications on predefined standard models might be using congruences to express that certain elements of the implementation shall be considered equivalent, or observationally equal.Ideas from Hennicker and Bidoit might be suitable.

Example 5 . 3
With Obs int zero and Obs int n !Obs int succn we define the constructors zeroand succ for natural numbers.
Sort b 1 : : : Sort b j for appropriate i; j, where Sort is a mapping on sorts and Op a mapping on attributes and transition identifiers.A subsignature 0 can be embedded into a signature by an embedding signature morphism.

of state sort state
sorts over X s are variables x 2 X s ; every aa 1 ; : : : ; a n for a 2 attr 2 sorts over X s are identifiers st to denote the state; and every projection 1 pst; a 1 ; : : : ; a m for p 2 tran with p : state s 1 : : : s m !state s, st : state and a i : s i .Example 2.3 A -term of data sort bool is is f u l l .A -terms of state sort state are popst or pushst; e. T s we denote the set of ground -terms of sort s.With T; X s we denote the set of -terms of sort s including variables.A term of sort state is also called a command. With Example 3.2 A specification M = h; E i for a stack consists of: 1 and in M 2 by 2 !p 2 .Then mod tr M p denotes models of a transition p, i.e. those functions which interpret a transition p in a model of a specification M. Let A 2 modM, p 2 mod tr M p and p 2 transigM.Then the satisfaction j = tr is defined as follows: p j = tr holds, if A j = holds for all objects A 2 modM which interpret p by p .With the previous two definitions, we get the following property for two -formulas ; specifying a transition p by !p : p 2 mod tr M p iff p j = tr !p Proof: Obvious.
[8,10,11]ational -context is a -context with observational sort.For instance topz would be an observational -context, if the sort of top t for a suitable t is a observational sort.The notion of a context can also be defined for the state-based setting.A term c 2 T; X s2S fstateg is called context over , if c contains exactly one z s 2 Z = fz s js 2 S f stategg.A context over z s shall be called observational, if s is not the sort state.An observational subalgebra A; Obs A is the subalgebra of A that contains only those elements denotable by ground terms defined as observable.The observational satisfaction j = OBS is defined by: A; Obs A j = OBS t = t 0 if A j = c t = c t 0 for all observational contexts c.Hennicker[8,10,11]defines an observational predicate Obst for term t 2 T; X which holds in a -algebra A; Obs A -or A; Obs A j = OBS Obst -if for all valuations v : X !A the interpretation of t by v is element of the observational subalgebra A; Obs A .i.e. v t 2 Obs A .Models are consequently defined by: M o d OBS M : = fA 2 Alg OBS j A j = OBS for all 2 Eg for equal signatures of M and M 0 .Example 4.3 Define a specification N = h; F i with : sorts = fstate; elem; boolg attr = ftop :! elem; is f u l l :! boolg tran = fpush : state elem !state; pop : state !stateg Example 5.1 Standard models of the data type Integer can be used to implement a specification of boolean values.By applying an observational predicate Obs Obs ftrue;f alse;notgint i we want to express that only the carrier elements of a carrier set Integer for sort int reachable by true, f a l s e and not are observable.These could for example be the numbers 0 and 1.All other numbers are unreachable (with boolean constructors), and therefore not observable.
In other approaches, e.g.Hennicker's work, contexts are used to defined observable constructs.Here, we use subsignatures.
It shall be assumed that SET and TUPLE are generic specifications which can be instantiated with element types such as NAT or INT.The operations set insert and empty set shall be the constructors, i.e. they denote the same reachable carriers as the whole set of operations of the signature.Only those set elements are observable which can be reached via ground terms based on zeroand succ.These are the natural numbers.The axioms have to hold only for them.This is of importance if we implement on standard models of predefined types such as Integer.Obs fzero;succgint i holds, if v S T;i is element of the subset reachable by zeroand succ for any state S T. Thus, SET(NAT) by TUPLE(INT) is a correct implementation of a specification SET(NAT) with operations set insert, set delete, empty set and the usual set axioms and set elements which are natural numbers that obey the Peano axioms.These are still abstract specifications, i.e., proof obligations if an executable version is derived.
The implementation p 1 !I tr p 2 holds, if every function interpreting p 2 in a -model which satisfies p2 !p 2 p2 is also interpretation of p 1 in a -model which satisfies p1 !p 1 p1 .The implementation M 1 !I M 2 holds iff M o d M 2 M o d M 1 for equal signatures of M and M 0 .The refinement relation p 1 !R tr p 2 holds, if Dp 1 ^Dp 2 and p1 !p2 ^p2 !p1 hold.The consequence rule and Example 6.1 illustrate this.We will assume terminating operations for this definition such that by execution of the operations the postcondition can always be established.Let M 1 and M 2 be specifications.The refinement relation M 1 !R M 2 holds, if for all p 2 tran M1 the relation p M1 !R tr p M2 holds.