Refinements and Product Line Architectures

Abstract

Models of software are generally too low level, exposing classes, methods, and objects as the focal point of discourse in software design and implementation. This makes it very difficult, if not impossi- ble, to reason about software architectures (also known as “application designs”); to have simple, elegant, and easy to understand speciffications of applications; and to be able to design or critique software designs automatically given a set of high-level requirements. These problems come to the forefront in the area of product-line ar- chitectures. The goal is to build families of related applications from components. Ideally, one should have simple ways to specify a particu- lar application (its design and implementation) and differentiate it from others. It must be possible to reason about an application in terms of its components, in order to differentiate “bad” designs from “good” designs. And it should be possible to optimize designs automatically given a set of constraints. For all this to be possible, it is necessary that components en- capsulate individual features that can be shared by many applications in a product-line. Knowing that a component/feature is present (or absent) provides critical knowledge about the behavior of an application. How- ever, expressing individual features as individual components requires a concept of encapsulation that is quite different from that offered by conventional component technologies - e.g., CORBA, COM, and Java Packages. In this presentation, I will outline a model of software that has been demonstrated in many different domains by several researchers over the last decade. The core ideas are programs are values and building blocks (what others call “components”) are functions that take a program as input and produce a new program as output —the new program is the in- put program with an additional feature. Such functions are refinements; they add new capabilities to a program. Function composition (which corresponds to component composition) follows the age-old precepts of step-wise refinement - the idea of progressively building programs by adding one detail or feature at a time. The difference between our version of step-wise refinement and traditional work is the scale: our refinements impact many classes of an application. Moreover, expressing software design and implementation in this manner is conducive to optimization: applications are modeled as equations, which are compositions of func- tions. Equation optimization can be accomplished through rewrite rules that capture equivalence relationships between interchangeable functions (components).