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).
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
References
Y. Smaragdakis, Implementing Large-Scale Object-Oriented Components, Ph.D. dissertation, September 1999, The Department of Computer Sciences, The University of Texas at Austin.
D. Batory, C. Johnson, B. MacDonald, and Dale von Heeder, Achieving Extensibility Through Product-Lines and Domain-Specific Languages, In Proceedings of the Int. Conference on Software Reuse, Vienna, Austria, 2000.
D. Batory and S. O’Malley. The Design and Implementation of Hierarchical Software Systems with Reusable Components, ACM Trans. Soft. Eng. and Method., 1(4):355–398, October 1992.
Author information
Authors and Affiliations
Editor information
Editors and Affiliations
Rights and permissions
Copyright information
© 2000 Springer-Verlag Berlin Heidelberg
About this paper
Cite this paper
Batory, D. (2000). Refinements and Product Line Architectures. In: Taha, W. (eds) Semantics, Applications, and Implementation of Program Generation. SAIG 2000. Lecture Notes in Computer Science, vol 1924. Springer, Berlin, Heidelberg. https://doi.org/10.1007/3-540-45350-4_2
Download citation
DOI: https://doi.org/10.1007/3-540-45350-4_2
Published:
Publisher Name: Springer, Berlin, Heidelberg
Print ISBN: 978-3-540-41054-6
Online ISBN: 978-3-540-45350-5
eBook Packages: Springer Book Archive