Reusable Component-Specification Pairs

Attaching Specifications to Objects and Components Figure 1. Elements of an Object-Specification Pair Problem Statement An object-specification pair defines a set of behaviors can be offered by a component/object. Object/component descriptions must be at least multi-input multi-output (MIMO). Otherwise they aren't useful. Interface Specification Together, the pre- and post-conditions, and satisfaction of the input requirements constitute a contract. Role of Pre- and Post-Conditions in Contract for Object Usage (Source: A.R. Newton, "Notes on Interface-Based Design," EECS, UC Berkeley). Networks of communicating objects are created by stitching together objects that have compatible I/O characteristics and pre- and post-conditions. Research and Development Issues Input and Output How to use XML/RDF to model ports, port attributes, and flows (e.g., signals, energy) to varying levels of complexity? How to design a hierarchy of port classes? How to model engineering and physical constraints -- convervation of flow, energy, force? Pre- and Post-Conditions How to use XML/RDF to model pre- and post-conditions for object/module use? We'd like to write these rules in a manner that enables tools like Jess and MANDARAX to evaluate compatibility of pre- and post-conditions. Design of "Component Blocks" and Glue Logic How much functionality of the "component blocks" needs to be known in order for: (1) the glue logic to work, and (2) system-level verification procedures to work?

Section 4-1: June, 2003.