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

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.