Truth vs Knowledge: The Difference Between What a Component Does and What We Know It Does

Author: Mary Shaw

Proceedings of the 8th International Workshop on Software Specification and Design, pp. 181-185, 1996.

Download the Postscript, PDF, or view HTML.


Conventional doctrine holds that specifications are sufficient, complete, static, and homogeneous. For system-level specifications, especially for software architectures and their components, conventional doctrine often fails to hold. This can happen when properties other than functionality are critical, when not all properties of interest can be identified in advance, or when the cost of creating specifications is significant. That is, the conventional doctrine often fails for practical software components. Specifications for real software must be incremental, extensible, and heterogeneous. To support such specifications, our notations and tools must be able to extend and manipulate structured specifications. In the UniCon architecture description language, we are introducing credentials, a property-list form of specification that supports evolving heterogeneous specifications and their use with system-building and analysis tools.

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

[Last modified 14-Oct-1999.
Mail suggestions to the