2 Position

One of the most striking differences between typical physical systems and software systems is the difficulty involved in replacing one component with another, and predictably achieving a desired effect. For example, consider a common table lamp whose components are a base, a switched socket, an electrical cord, a shade, and a bulb. We can change the behavior of the lamp simply by replacing one light bulb with another (say, of different wattage) and we have no trouble predicting what effect will be observed. Why can't component-based software be maintained in a similar way? Simply and gently put, software engineers generally do not know how to build software in which the behavioral effects of changes are localized. This is not to say it is impossible or unknown how to do this; quite the contrary. In fact, we hereby assume when discussing software systems the use of a component-based software design discipline and framework -- such as the RESOLVE approach [SW94] -- in which it is technically and practically possible to reason modularly about the behavioral effects of software changes in general, and component substitution in particular [EHMO91,EHO94,Hey95,Gib97].

A central problem in the maintenance of a component-based system is the ability to understand the meaning of a component. Consider a software system implemented in C++. For a typical operational program component , such as a class, ``meaning'' generally is taken to be the operational behavior arising from the component at run time. However, there are at least two other kinds of artifacts involved in modern component-based software systems:

• specifications of operational program components, such as Larch [GH93], RESOLVE, or $\mathcal{Z}$ [Spi88] formal specifications, which are used to record the required or intended functionality of operational program components; and
• templates , or generic (parameterized) components, such as Ada generic packages, C++ class templates, or RESOLVE realization modules, which are instantiated to generate what amount to operational program components.

Although specifications and templates do not have behaviors in the same sense as ordinary operational components, they must and do have meanings. What are these meanings, and how are they related to the meanings of operational program components? Software systems are symbolic entities so the standard notion of semantics makes these questions sensible. Other physical systems are not symbolic, but like software systems they do exhibit behaviors -- and their design documents are symbolic. Is there a way to develop a mathematical modeling framework for system behavior that applies equally well to physical systems and to software systems? Such a framework should prove useful, for instance, in dealing with formal models of embedded systems, where the physical system being controlled and the software inside it must be analyzed and/or designed together. It also should help illuminate deeper connections between well-engineered physical systems and well-engineered software systems.

Our position is:

There is a rather straightforward and general framework for integrating two related notions: modeling the behavior of systems, and modeling the meanings of various artifacts associated with those systems (including specifications and templates).

We focus attention here on component-based software systems, generally leaving to the reader the challenge of making the leap to other physical systems -- with only the slightest hints from us as to how to do so. During workshop discussions we hope to be able to pursue these connections.