Component Synthesis Theory: The Problem of Scale

This position paper reviews a paradigm for determining properties of component assemblies based on blackbox component representations. Such a representation does not use subjective measures like a description of its development process, nor does it require access to the source code. However, it is not strictly specification based, because it does use properties of the code, notably results of test executions. The paper then poses an important problem for any such research: the problem of scale. Any precise analysis or synthesis procedure for a system’s properties based on its component properties will work best when the components are ‘small,’ in the sense that their detailed properties are relatively easy to measure and describe in practice. Useful systems are not small, however, and thus a system cannot be viewed as merely an extreme example of a component. Something is necessarily lost in the synthesis. When systems are to be composed of ever-larger components, which may be systems in their own right, this issue of scale becomes critical. We suggest that it is natural for the properties and theories of aggregate systems to change with the system size, and that it will be necessary to define informally and formally different kinds of ‘component’ at different levels of organization. 1 SYNTHESIS OF SYSTEM PROPERTIES FROM COMPONENT PROPERTIES A reliability theory for component-based software development appears in ICSE ‘01 [1]. That theory is an example of the ‘microscopic’ view of systems constructed from components. It considers the behavior of the components in full detail, and calculates the corresponding behavior of the system built from them. Section 2 below outlines a similar microscopic theory of system performance based on components. Using the example in section 2, this position paper describes the characteristics and issues of microscopic component-based theories, and argues that they are important in their place, but only the first part of a useful theory of software development using components. What is a Component? A discussion of component-based software engineering (CBSE) often begins with an attempt to define the ‘components’ involved. It is common to quote several published definitions, which may be at odds with each other [5]. This is not surprising, because general definitions try to encompass the full range of components, from subroutines or object-oriented classes in a library, to stand-alone, full-blown commercial products. The characteristics of this range vary widely. An O-O class is on the order of 100 lines of code and the source may be available; the interfaces are clean, precise, and well documented. A commercial product may involve millions of lines of code, and is usually available only in executable form; its interfaces will be messy and illdescribed. ‘Terminology wars’ are nothing new, and everyone is impatient with the time they waste, yet we feel compelled to agree on the subject before we begin to say something about it. The result is definitions that are useful in delineating an area (say for the purposes of describing a workshop), but are almost useless as precise technical definitions on which to base theoretical work. In order to gain agreement, conflicting technical detail must be eliminated, but this detail is required for the construction of quantitative theory. And like any new subject, component-based software engineering needs quantitative theory. In a way, the definitional problem for components supports the position of this paper: researchers can agree only on large generalities because they really wish to talk about qualitatively different things, and the way they analyze these differing entities depends on the differences.