The role of formal reusable frameworks

We use our experience in applying formal methods to large-scale industrial problems to argue (a) the practical importance of developing formal reusable frameworks, and (b) th e need for further research into techniques for defining and instantiating these frameworks. 1 The Value of Formal Frameworks Success in introducing formal methods into industry depends on making those methods cost-effective in the overall context of industrial software engineering practice. In the past, efforts to do this have largely focused on the problem of refi,nemeni: given a formal specification of a system, how does one construct an implementation that is correct with respect to that specification [4, 3, 71. While the use of formal refinement leads to software with many desirable properties, this application of formal techniques has not found widespread industrial use in the United States except perhaps in the areas of securityand safety-critical systems, which naturally place a high premium on correctness. In this paper we argue the need for attention to the inverse problem of abstrachon: within a given domain how does one construct formal models that can serve as reusable frameworks for a wide variety of products. While abstraction and refinement are clearly two sides of the same coin, we have found that a focus on the former can lead to highly effective use of formal methods in practical industrial software development. First, when a single specification can serve a number of distinct products, the cost of developing the framework can be amortized over those products. Second, the development of different products from the Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. @ 1990 ACM 089791-4155/90/0010-0042...$1.50 same framework can lead to a desirable uniformity across those products. Third? in many cases the reusable framework can be implemented by corresponding reusable software components. Fourth, the requirement of producing a specification that acts as a framework for several products forces the developers of that specification to strive for particularly elegant abstractions. This in turn can lead to much cleaner definitions of the fundamental concepts behind an application. Fifth, since reusing an existing framework is considerably easier than specifying it in the first place, in many cases the job of constructing the framework can be allotted to a small team of highly skilled engineers. This addresses the very real problem in industry that currently all too few software engineers are capable of producing good specifictions. Finally, at a much grander level, we can hope that by concentrating on higher-level frameworks, we may some day have libraries of formally-specified software architectures that form the basic design repertoire of every software engineer. 2 A Framework for Electronic Instruments To illustrate one of these frameworks, consider the problem of defining a simple electronic counter/timer (which measures the frequency or period of an electronic signal). In its most abstract form, such an instrument can be viewed as a mathematical function that can be applied to a Signal to produce a Measurement. The problem in defining a framework for instruments of this sort is to make such functions intellectually (and practically) manageable. Our approach has been to develop a framework in which an instrument is defined as a composition of simple functions, each component function describing some portion of the instrument’s overall functionality. To account for a user’s ability to configure the instrument we treat these components as higher order functions. The use of higher-order functions captures both Proceedings of the ACM SIGSOFT International Workshop on Formal Methods in Software DevelopI n ment. Napa, California, May 9-11, 1990. the user’s intuition of configuring an instrument and also the actual operating behavior of current implementations. The user typically sets up input parameters and then repeatedly applies the resultant functions in real-time to produce a series of measurements. Such a decomposition for a counter/timer is illustrated in Figure 1. More formally we can use the Z specification language [l] to model this architecture by defining a higher-order function for each component. For example, the Couple function is defined as follows: Coupling ::= Direct 1 Filter Couple : Coupling + Signal -+ Signal Couple Direct s = s Couple Filter s = X t l s(t) h(s) The user-supplied Coupling parameter determines whether the signal will pass through unaltered or have its DC offset filtered out of the signal. Given a value of this parameter, Couple produces a new function that maps a Signal to a Signal. In a similar way we can define the other functional components of the instrument. (A complete description of this specification appears in [5].) For example, the component DeiectCrossings is defined as follows: Slope ::= POS 1 NEG Level == Volts DetectCrossings : Level x Slope 4 Signal