Retrenching partial requirements into system definitions: a simple feature interaction case study

Abstract

In conventional model-oriented formal refinement, the abstract model is supposed to capture all the properties of interest in the system, in an as-clutter-free-as-possible manner. Subsequently, the refinement process guides development inexorably towards a faithful implementation. However, refinement says nothing about how to obtain the abstract model in the first place. In reality developers experiment with prototype models and their refinements until a workable arrangement is discovered.

Retrenchment is a formal technique intended to capture some of the informal approach to a refinable abstract model in a formal manner that will integrate with refinement. This is in order that the benefits of a formal approach can migrate further up the development hierarchy. The basic ideas of retrenchment are presented, and a simple telephone system feature interaction case study is elaborated. This illustrates not only how retrenchment can relate incompatible and partial models to a more definitive consolidated model during the development of the contracted specification, but also that the same formalism is applicable in a re-engineering context, where the subsequent evolution of a system may be partly incompatible with earlier design decisions. The case study illustrates how the natural method of composing retrenchments can give results that are too liberal in certain cases, and stronger laws of composition are derived for systems possessing suitable properties. It is shown that the methodology can encompass more ad hoc and custom-built techniques such as Zave's layered feature engineering approach to applications exhibiting a feature-oriented architecture (such as telephony).

Appendix: PHONE Development via Refinement

In this section we examine the prospects for doing at least some of the development of the telephone case study using refinement. We had better start by saying what we mean by refinement in this context.

We are working in a straightforward transition system-based framework. For this reason, notions of potential non-termination and attendant complexities, often taken into account in refinement formalisms, just do not arise: there are transitions that initiate and terminate successfully as described in an operation's transition relation, and there is nothing else. We revert to the usual convention of speaking about an abstract and a concrete system, as is prevalent in the refinement literature.

With the notational conventions we have been using up to now, we define the precondition for say an abstract operation m _A, whose transition relation is stp _mA, by:

$$pre_{m_A } \left( {u,i} \right) = \exists u',o \bullet stp_{m_A } \left( {u,i,u',o} \right)$$

(117)

(So pre _mA is just what we called dom _mA before, but we now conform to the terminology more common in refinement.)

Now we define refinement from an abstract system to a concrete system to be characterised by the following Z-refinement-like conditions:

$$ {\bf{Ops}}_A = {\bf{Ops}}_C $$

(118)

$$ pre_{m_A } \left( {u,i} \right) \wedge G\left( {u,v} \right) \Rightarrow pre_{m_C } \left( {v,i} \right) $$

(119)

$$\begin{array}{*{20}c} {{G{\left( {u,v} \right)} \wedge stp_{{m_{C} }} {\left( {v,i,v',o} \right)} \Rightarrow } \aftergroup \hfill} \\ {{{\;\;\;\left( {\exists u' \bullet stp_{{m_{A} }} {\left( {u,i,u',o} \right)} \wedge G{\left( {u',v'} \right)}} \right)}} \aftergroup \hfill} \\ \end{array} $$

(120)

Note that we are being strict here about I/O. The inputs and outputs must be identical at the two levels of abstraction. This is in line with viewing refinement as an implementation mechanism which can silently replace an abstract model with an implementation, without the user's awareness. (Also it finesses a couple of minor logical niggles.)

What are now the prospects of doing, for example, the PHONE to PHONE _CF development step via refinement? Immediately we say nil, because (118) is violated by the additional table management operations of PHONE _CF . Let us agree to ignore this for the sake of not falling at the first fence. We next examine one model for PHONE that has prospects for refinement.

PHONE′

In this system the state space is just as for the original PHONE model:

$$ \eqalign{ & calls:NUM \rightarrowtailbar NUM\;{\rm{ where}} \cr & \;\;\;dom\left( {calls} \right) \cap rng\left( {calls} \right) = \emptyset \cr} $$

(121)

The two operations, connect _n and break _n , look like:

$$ \eqalign{ & calls\;{\textrm{-}}\!\left( {i,connect_n ,o} \right)\!\textrm{-}\raisebox{1pt}{\small${>}$}\;calls'\;{\rm{ where}} \cr & \;\;\;{\rm{free}}\left( n \right) \wedge {\rm{free}}\left( i \right) \wedge \left( {n \ne i} \right) \wedge \cr & \;\;\;o = OK \wedge calls' = calls \cup \left\{ {n \mapsto i} \right\} \cr} $$

(122)

$$ \eqalign{ & calls\;{\textrm{-}}\!\left( {break_n } \right)\!\textrm{-}\raisebox{1pt}{\small${>}$}\;calls'\;{\rm{ where}} \cr & \;\;\;{\rm{busy}}\left( n \right) \wedge calls' = \left\{ n \right\} \leftsubtractoper calls \rightsubtractoper \left\{ n \right\} \cr} $$

(123)

Note that this differs from PHONE in that the specification of connect _n has nothing corresponding to the 'else' clause of (6). It is thus a partial operation since in the ${{\rm{busy}}{\left( i \right)} \vee {\left( {n = i} \right)}}$ case we are outside the precondition of connect _n . Some stratagem like this is forced on us, however, because if PHONE _CF 's connect _CF,n operation is to be a valid refinement of connect _n , then up to the latitude permitted by the retrieve relation (which will continue to be (23) and thus effectively affords no latitude whatsoever), the actions of connect _CF,n and connect _n must agree in the ${{\rm{busy}}{\left( i \right)} \vee {\left( {n = i} \right)}}$ case should they both be defined, otherwise (120) will fail. This effect is rendered even more acute when we remember that, in refinement, outputs must agree.

Unfortunately this kind of partiality of operations is not acceptable in a high-level model that purports to capture a coherent set of user requirements, and is a manifestation of the model incompleteness described in the Introduction. User requirements at this level must express a defensively drawn and complete model, as it is quite unreasonable to assume that users can flawlessly adhere to the need to never call a connect _n operation from a before-state/input combination for which there exists no connect _n transition.

(It is thus clear that model incompleteness is unavoidably a user-level or meta-level issue, not deducible from the mathematics of the model alone. For example, whereas it is certainly the case that there are never any connect _n transitions when busy(n) holds, this is not a symptom of model incompleteness due to the different significance of n and i at user level—users accept that it is semantically self-contradictory to expect a transition in the busy(n) case.)

Since this refinement attempt has spawned some unsatisfactory features, we give an alternative construction, exploiting non-determinism rather than partiality this time.

PHONE′′

In this system the state space is just as before:

$$\eqalign{ & calls:NUM \rightarrowtailbar NUM\;{\rm where} \cr & \;\;\;dom\left( {calls} \right) \cap rng\left( {calls} \right) = \emptyset \cr} $$

(124)

The operations connect _n and break _n this time look like:

$$ \eqalign{ & calls\;{\textrm{-}}\!\left( {i,connect_n ,o} \right)\!\textrm{-}\raisebox{1pt}{\small${>}$}\;calls'\;{\rm{where}} \cr & \;\;\;{\rm{free}}\left( n \right) \wedge \cr & \;\;\;{\rm{if}}\;{\rm{free}}\left( i \right) \wedge \left( {n \ne i} \right) \cr & \;\;\;{\rm{then}}\;o = OK \wedge calls' = calls \cup \left\{ {n \mapsto i} \right\} \cr & \;\;\;{\rm{else}}\;{\rm{either }}\;o = NO \wedge calls' = calls \cr & \;\;\;{\rm{or}}\;o = OK \wedge \left\{ n \right\} \leftsubtractoper calls' = calls \cr} $$

(125)

$$ \eqalign{ & calls\;{\textrm{-}}\!\left( {break_n } \right)\!\textrm{-}\raisebox{1pt}{\small${>}$}\;calls'\;{\rm{where}} \cr & \;\;\;{\rm{busy}}\left( n \right) \wedge calls' = \left\{ n \right\} \leftsubtractoper calls \rightsubtractoper \left\{ n \right\} \cr} $$

(126)

In this version of events, in the ${{\rm{busy}}{\left( i \right)} \vee {\left( {n = i} \right)}}$ case, the operation connect _n has the capacity to non-deterministically connect to some unspecified location.⁹ The non-determinism is resolved in the refinement to PHONE _CF (still using the same retrieve relation), in which the connect _CF,n operation specifies when and where a connection can be made in the ${{\rm{busy}}{\left( i \right)} \vee {\left( {n = i} \right)}}$ case.

The abstract operation is now total, overcoming the objection in the previous version. However, the price for this is the non-deterministic else clause in (125). For sure, the PHONE′′ model is a more abstract entity than the PHONE _CF model, but when one asks the question as to what extent PHONE′′ deserves to be called a specification of the POTS model in the sense that PHONE′′ captures a coherent set of functional requirements of the POTS system the answer is less than satisfactory. Is the specific non-determinism present in PHONE′′ a requirement of the POTS model? The answer is surely that it is not. The PHONE′′ model was specifically construed to withhold those features from PHONE _CF that could neatly be reinstated by the definition of refinement that we are using; i.e. it was reverse engineered from PHONE _CF . Thus the abstract and concrete levels have become entangled in this development, and vestiges of properties of the envisaged lower-level model have had to migrate to the higher-level one in order to satisfy the exigencies of refinement. This is the kind of reverse engineering we alluded to in the Introduction; and while it might not be too problematic in such a small example, in larger systems it can become a serious nuisance. The pollution of the perspicuity of the higher-level models, arising from the forced incorporation of very specific perspectives on inappropriate lower-level detail forced upwards by the demands of refinement, can merely serve to bring an otherwise blameless refinement-based specification development methodology into disrepute among designers.

Thus refinement based-developments of the evolution of a more complex specification from a simpler one (each of which captures a coherent set of functional requirements of the system at a suitable level of abstraction) are replete with difficulties. We have illustrated these just in the case of the PHONE to PHONE _CF development step; however, extending the same approach to the other parts of the feature interaction case study would simply cause the illustrated difficulties to proliferate.