Retrenchment and the Mondex Electronic Purse

Some of the success stories of model based refinement are recalled, as well as some of the annoyances that arise when refinement is deployed in the engineering of large systems. The way that retrenchment attempts to alleviate such inconveniences is reviewed. The Mondex Electronic Purse formal development provides a highly credible testbed for examining how real world refinement difficulties can be treated via retrenchment. The contributions of retrenchment to integrating the real implementation with the formal development are surveyed, and the extraction of commonly occurring ‘retrenchment patterns’is suggested. 1 Refinement: Pros and Cons Model based refinement is well known as the standard technique for progressing abstract system designs towards implementations. The abstract designs are typically expressed in a modelling language permitting the maximum of expressivity, abstraction, mathematical rigour, and succinctness, without concern for executability. The lower level models lean increasingly towards the actual capabilities of real computing devices, and the algorithms that they must utilise. There are a number of specific formulations of model based refinement, which can differ as regards particular technical details, but which share the same overall strategy for establishing the correctness of an implementation: namely that for every run of the concrete system, there must be a run of the abstract system which maintains the desired notion of correct correspondence between them. Among the more well known techniques we can mention Z [25, 32, 17], B [1, 24, 20], VDM [13, 19, 7], RAISE [15, 31] and ASM [10, 8, 22, 23]. Besides being well established in the academic sphere, refinement has had notable successes on the industrial front in recent years. We can cite the Mondex Purse [29, 30] and Multos Operating System [28, 27] for Z, the MÉTÉOR project [6] and numerous other railway system projects in France and elsewhere for B, and a number of language definitions and language abstract machine definitions for ASM [26, 9, 16]. Despite these undoubted successes, practitioners have known for some time that when refinement is used as the sole means of progressing from an abstract model to a concrete one, then certain difficulties can plague the development process due to the exacting nature of typical refinement proof obligations. This is not a technical difficulty with refinement, rather it is a manifestation of human inclination to view certain things as abstractions/concretisations of the same phenomenon, that some given refinement formalism does not permit to be so viewed. Since the human notion of abstraction is inevitably imprecise, and the mathematical notion of abstraction pertaining to any specific refinement formalism is de facto extremely precise, some dislocation between the two is bound to occur sometimes. Usually, if the scale of the problem is small, this dislocation can be overcome easily enough. Frequently it is sufficient to make some small adjustment to one or other of an abstract/concrete pair of models to bring them into line. However, when the problem size is large, such manipulations can become prohibitive; this may be on grounds of sheer cost, or on more prosaic grounds. For large problems, there are usually stakeholders other than the refinement specialists involved, who ‘own’ the models in question, and they may simply not agree to changes in the models as suggested by the refinement specialists, regardless of the latters’ protestations. Thus the human aspects of the development milieu become paramount. This is nothing more than a corollary of the fact that the construction of large systems is an engineering problem, and not purely a problem in formal system construction. The key desiderata in the two domains are just different. A simple and commonly occurring example arises with natural number arithmetic. Implementable whole numbers are invariably finite. So arithmetic always generates within-bounds and out-of-bounds cases. If there are n different quantities in the model, then for a typical operation there will be one all-within-bounds case, and easily of the order of n out-of-bounds cases1 of various flavours to consider in the model. In the system specification, the syntactic descriptions of the latter can often swamp that of the single all-within-bounds case, which is the one of most interest. For such reasons it is often desirable to idealise the arithmetic and use unbounded naturals at the abstract level; these cause no exceptions. Unfortunately in the overwhelming majority of refinement formalisms there is no refinement from unbounded naturals to bounded ones that handles a sensible selection of the operations that are normally needed.