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 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 reengineering 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).

The B-Method is a method for the stepwise derivation of sequential programs. In this paper we show how the B-Method can be used for designing distributed systems by embedding action systems within this method. The action system formalism is designed for the construction of parallel and distributed systems in a stepwise manner within the refinement calculus. We describe how action systems are written in B AMN. We also show the correspondence between refinement rules for action systems and the proof obligations generated in the B-Method. Furthermore, we propose an extension of the B-Method to cover parallel and distributed systems. Familiarity with B AMN is assumed.

Refinement is reviewed in a partial correctness framework, highlighting in particular the distinction between its use as a specification constructor at a high level, and its use as an implementation mechanism at a low level. Some of its shortcomings as specification constructor at high levels of abstraction are pointed out, and these are used to motivate the adoption of retrenchment for certain high level development steps. Basic properties of retrenchment are described, including a justification of the operation PO, simple examples, simulation properties, and compositionality for both the basic retrenchment notion and enriched versions. The issue of framing retrenchment in the wide variety of correctness notions for refinement calculi that exist in the literature is tackled, culminating in guidelines on how to `brew your own retrenchment theory'. Two short case studies are presented. One is a simple digital redesign control theory problem, the other is a radiotherapy dos...

Program refinement usually translates an abstract specification to a highlevel language program. However, this process can be taken further by refining a high-level language `specification' to an assembler code `implementation '. It is shown how this can be done in the familiar refinement calculus framework. Several derived refinement rules for modelling program compilation are presented. Keywords: Program refinement; compilation; action systems 1 Introduction Compilation of high-level language programs to assembler code is among the oldest and most well-explored technologies in computer programming. Nevertheless, stories of production compilers containing bugs abound! Often this is merely an annoyance, but in safety-critical applications the danger of unknown compilation errors is unacceptable. One solution to this is to develop a verified, trustworthy compilation strategy for a simplified programming language. Such a strategy can then be used as a basis for either (directly)...

this paper is that the aspect-oriented programming (AOP) community should become familiar with and exploit an existing body of research in distributed systems that explores a notion called superimposition. Just as in AOP, superimposition is orthogonal to the usual breakdown into modules. Superimposition makes it possible to break the design of a system into several subtasks. One subtask is to be solved by the basic algorithm that the system has to implement. Other subtasks could insure liveness (progress of the computation), increase parallelism, take snapshots, etc. A superimposer then interleaves these separate designs into a single program operating in the same state space.

The model checking of applications of aspects is explained, by showing the stages and proof obligations when a collection of generic aspects (called a superimposition) is combined with a basic program. We assume that both the basic program and the collection of aspects have their own specifications. The Bandera tool for Java programs is used to generate input for model checkers, although any similar tool could be employed. New verification aspects and superimpositions are defined to modularize the proofs, and separate the proof-related code from the program and the aspects. This allows generating and activating a series of model checking tasks automatically each time a superimposition is applied to a basic program, achieving superimposition validation. A case study that monitors and checks an underlying bounded buffer program is presented.

Output retrenchment, a type of retrenchment in which when the retrieve relation is reestablished for an after-state, it is strengthened by a relation on outputs, is introduced and studied. The output relation balances syntactically the statements that can be made about the `successful transitions', as against the statements that can be made about the transitions that merely establish the concedes relation, in that all after-states and output values are mentioned. This leads to a cleaner treatment of most theoretical questions regarding retrenchments. Default retrenchments are introduced as are several notions that lead to stronger laws of composition for retrenchments, the tidy, neat, and fastidious retrenchments. The compositionality and associativity problems for these stronger notions are nontrivial, and compositionality and associativity are shown provided appropriate additional conditions hold. This technology is used to give a retrenchment account of elementary feature engineering, the full flexibility of which, refinement struggles to capture.

. Action systems is a formalism designed for the construction of parallel and distributed systems in a stepwise manner within the refinement calculus. In this paper we show how action systems can be derived and refined within a mechanical proof tool, the B-Tool. We describe how action systems are embedded in B-Tool. Due to this embedding we can now develop parallel and distributed systems within the B-Tool. We also show how a typical and nontrivial refinement rule, the superposition refinement rule, is formalized and applied on action systems within B-Tool. A derivation towards a distributed load balancing algorithm is given as a case study. 1 Introduction Action systems are used to construct parallel and distributed systems in a stepwise manner as described by Back et al. [2, 4]. They are often developed using a poweful program modularization and structuring method called superposition [7, 9, 2]. In superposition some new functionality is added to an algorithm in the form of additio...

Simple retrenchment is briefly reviewed in the B language of J.-R. Abrial [1] as a liberalization of classical refinement, for the formal description of application developments too demanding for refinement. This work initiates the study of the structuring of retrenchment-based developments in B by decomposition. A given coarse-grained retrenchment relation between specifications is decomposed into a family of more fine-grained retrenchments. The resulting family may distinguish more incisively between refining, approximately refining, and non-refining behaviours. Two decomposition results are given, each sharpening a coarsegrained retrenchment within a particular syntactic structure for operations at concrete and abstract levels. A third result decomposes a retrenchment exploiting structure latent in both levels. The theory is illustrated by a simple example based on an abstract model of distributed computing, and methodological aspects are considered.

Feature interaction problems are currently a major roadblock to extending and changing telephone switching systems, which have to follow market needs quickly. Such problems appear already in the requirements specifications. We avoid certain kinds of feature interactions by employing a more modular specification structure. First, we show how the details of the users' interface, like buttons and ring tones, can be encapsulated and separated from the system's functionality. Such an architecture could be realized even within the structure of the current standard for the Intelligent Network (IN). Second, we argue that the requirements for the Plain Old Telephone Service (POTS) comprehend several different concerns, and that separate requirement concerns should be separated in the specification. We employ the Functional Documentation approach [PaMa95, vSPM93, vS92a] and investigate how it can be extended to group requirement concerns, and to cover not only one but a sequence of development contracts. Our approach is related to the standard refinement approach for software development. But when we refine a specification to introduce new services, we order the refinement steps (i.e., the new required properties) by the likeliness by which they must be taken back, and we document the dependences between these steps explicitly. In the appendix, we provide a case study that applies our ideas.