Conventional software doctrine calls for component specifications that are:

For example, a typical discussion of the promise of reuse [Ben95] is introduced,*

It may be possible to adhere to the conventional doctrine for algorithms and data structures, or when functionality is the only property of interest. However, architectural, or system-level, components cannot in practice satisfy these criteria. Indeed, they inevitably will not, and it is impractical to try.

This paper is about what this implies and how to cope with it: why architectural specifications are insufficient, incomplete, incremental, and heterogeneous -- and how software development methods and tools must adapt in response.

Section 1 describes architectural components and explains why they cannot adhere to the conventional doctrine. Section 2 considers many of the properties that need to be specified. Section 3 sets out requirements for architectural specifications. Section 4 introduces an approach to a solution, credentials for those properties that have been specified to date.

Software architecture deals with the overall structure and properties of software systems. The most common architecture description languages (ADLs) support components, connectors, and other aspects of the system such as styles, constraints, or design rationale [ShawGar95, PerWolf92]. Although the issues raised here apply to all architectural elements, this discussion focuses on specifications of the components, which may be either primitive (i.e., written in a programming language) or composite (i.e., defined in the ADL).

The information required to use an architectural component goes beyond computational functionality to include structural properties that affect how the component can be composed with other components; extra-functional properties that describe performance, capacity, environmental assumptions, and global properties; and family properties that assert relations among similar or related components. Software development environments should accommodate an open-ended collection of tools for construction and analysis. Different tools may depend on different properties, and some tools may generate new specification information [ICSE95].

Specifications of architectural components are intrinsically incomplete because system correctness depends not only on computational functionality but on other properties as noted above [Shaw85, GarAlOck95]. It’s impractical to expect full specifications of all these properties because of the prohibitive effort required to specify a wide variety of properties, whether or not anyone will use the information. Worse, it’s impossible: the developer cannot anticipate all the aspects of the component that its users might care about. As an added complication, the degree of precision in the specification may be influenced by the tradeoff between the costs and benefits of improved precision [Shaw81]. Although completeness is impractical, it is still appropriate to expect specifications for a common core of properties, and it is reasonable for a tool to require certain properties. Reasoning with partial specifications has already received some attention [Jac94, Per95].

Specifications of architectural components must be extensible, because developers discover new kinds of dependencies as they attempt to reuse independently-developed components together. Even with the best of good faith, component developers cannot describe all the incidental ways their components may interact with the entire environment. Garlan and colleagues analyze the implicit assumptions that interfered with one instance of attempted reuse [GarAlOck95]. Not only is much important information implicit, but users have no effective way to capture information they discover for future reference.

Specifications of architectural components must be heterogeneous, because of the diversity of significant properties, as described in Section 2. It is unreasonable to expect a single notation to serve for all of them.

Thus the drivers of specification incompleteness, extensibility, and heterogeneity are

The main reason why architectural components require incomplete, extensible, and heterogeneous specifications is the diversity of facts about a component that may affect a designer’s ability to compose it with other components and achieve a correct and consistent result. This section describes three major classes of properties that augment the conventional functional properties of type, signature, and pre/post conditions.

The most significant properties for architectural design deal with the ways components interact, and hence with the ways those components can be combined into systems. Especially important is the packaging of a component, which includes the type of component and the types of interactions it is prepared to support. The choice of packaging is often largely independent of the underlying functionality, but components must be packaged in compatible ways if they are to work together smoothly. For example, unix provides both a sort system call and a sort filter; although they have the same functionality, they are far from interchangeable. Some common packagings for components and the ways they interact are:

Distinctions of this kind are now made informally, often implicitly. If the distinctions were more precise and more explicit, it would be easier to detect and eventually correct incompatibilities by analyzing the system configuration description. Such checking must address not only local compatibility (e.g., do two components expect the same kinds of interactions) but also global properties (e.g., are there loops in a data flow system?).

In addition to functionality and structure, architectural specifications must be capable of expressing extra-functional properties related to performance, capacity, environmental assumptions, and global properties such as reliability and security [MyChNix92, Shaw85, CBKA95]. Many of these additional properties are qualitative, so they may require different kinds of support from more formal specifications. These other properties include:

Some of these properties require periodic updates, especially those that assert conformance to external standards (e.g., Windows 95) that may themselves change.

The formal specifications familiar to the IWSSD community are not the most common kind. More prevalent are product descriptions such as the following, which specifies the interface between a software product and the environment required to run it [DeL95]. This specification deals with space and conformance to established standards. The functionality of the product is described (imprecisely) in associated prose and pictures.

Components are often designed in families, sharing assumptions about such things as division of responsibilities, data encoding and protocols. A large family of systems may have constraints on collections of components that must be used together. It may also be important for a specification to express not only the properties of the instance at hand, but also a larger envelope of capability that could be achieved by, for example, modifying setup parameters of changing inheritance relations.

Component specifications play two roles:

These roles are roughly analogous to the formal and actual parameters of procedures--they serve both to define the capability envelope of a required component and the actual capability of an instance. Just as actual and formal parameters of procedures differ in detail, so do the requirement and implementation specifications of components.

To address this problem, we propose the notion of credentials: incremental, evolving specifications. Credentials may be viewed as property lists, or lists of <attribute, value> pairs. Credentials must include

Credentials must be an integral part of the software definition, so that they are supported by the CASE environment and updated in tandem with the code. The associated tools must support operations including

The UniCon architecture description language [SDKRYZ95] supports the bare bones of this proposal. UniCon specifications are given in the form of property lists; the set of attributes is open-ended; and particular attributes are required for certain checks and tools. Current development will add credibility values for attributes and make explicit the set of notations (including "uninterpreted") for values of attributes.

The work reported here has been heavily influenced by an ongoing collaboration with the Composable Systems Group at Carnegie Mellon University, particularly on discussions with David Garlan, Greg Zelesnik, and Rob DeLine. It draws on material presented at the 1995 Dagstuhl in Software Architecture and in a special volume of Lecture Notes in Computer Science. It was sponsored by the Wright Laboratory, Aeronautical Systems Center, Air Force Materiel Command, USAF, and the Advanced Research Projects Agency, under grant F33615-93-1-1330 and by a grant from Siemens Corporation. It represents the views of the author and not of Carnegie Mellon University or any of the sponsoring institutions.

[Ben95] Douglas W. Bennett. The promise of reuse. Object Magazine, vol 4, no 8, January 1995, pp. 32-40.

[CBKA95] Paul Clements, Len Bass, Rick Kazman, and Gregory Abowd. Predicting software Quality by architecture-level evaluation. In Proc Fifth International Conf on Software Quality, October 1995

[DeL95] DeLorme Mapping Company. The product originally cited is no longer on the market. A similar product specification appears at http://www.delorme.com/quads/requirements.htm.

[GarAlOck95] David Garlan, Robert Allen, and John Ockerbloom. Architectural Mismatch, or Why it’s hard to build systems out existing parts. Proc 17th International Conf on Software Engineering (ICSE-17), April 1995.

[ICSE95] David Garlan. Report of ICSE-17 Software Architecture Workshop, to appear ACM SIGSOFT Software Engineering Notes, 1995.

[Jac94] Daniel Jackson. Structuring Z Specifications with Views. Carnegie Mellon University Technical Report CMU-CS-94-126.

[MyChNix92] John Mylopoulos, Lawrence Chung, and Brian Nixon. "Representing and Using Nonfunctional Requirements: A Process-Oriented Approach. IEEE Transactions on Software Engineering, vol 18, no 6, June 1992.

[Per95] Dewayne E. Perry. System Compositions and Shared Dependencies. Unpublished manuscript, January 1995.

[PerWolf92] Dewayne E. Perry and Alexander L. Wolf, Foundations for the study of software architecture. ACM SIGSOFT Software Engineering Notes, vol 17, no 4, pp. 40-52, October 1992.

[Shaw 85] Mary Shaw. What Can We Specify? Questions in the domains of software specifications. In Proc Third International Workshop on Software Specification and Design, pp. 214-215, August 1985.

[ShawGar95] Mary Shaw and David Garlan. Software Architecture: Perspectives on an Emerging Discipline.Prentice Hall, 1995, to appear 1995.

[SDKRYZ95] Mary Shaw, Robert DeLine, Daniel V. Klein, Theodore L. Ross, David M. Young, Gregory Zelesnik. Abstractions for Software Architecture and Tools to Support Them. IEEE Tr on Software Engineering, May 1995.

[ZarWing95] A.M. Zaremski and J.M. Wing, "Specification Matching of Software Components." Proc. of SIGSOFT Foundations of Software Engineering, October 1995 (to appear).

____________
*Note that this description comes from the applications community, not the formal methods community.

Brought to you by the Composable Software Systems Research Group in the School of Computer Science at Carnegie Mellon University.