A component is an abstraction that represents a locus of computation and state in a system. It roughly corresponds to a compilation unit in a conventional programming language, a process in an operating system environment, or a user-level object such as a file in a filesystem. Components behave in identifiable, distinct ways, and they also interact with other components in similarly distinct and identifiable ways. These distinctions separate components into categories, or types. A component type captures the semantics of a component's behavior, the kind of functionality it implements, its performance characteristics, and its expectations of the style of interaction with other components.
A component has a specification, called an interface, and an implementation. The interface defines the computational commitments the component can make, and constraints on the way the component is to be used. It provides the guarantees that will hold of the behavior and performance of the component. It should be possible to use the component by reference to the interface alone.
The interface defines:
Properties can be thought of as attributes of a definition which are used to further describe (i.e., specify) it. They are global assertions and constraints that apply to the definition as a whole. There are many places in UniCon where lists of properties are used to further specify a definition. In component interfaces, properties are used to specify information such as the name of the processor that a process will run on, or the priority that a process will have in the run-time environment.
The interface defines the units of association used in system composition. These are named entities called players, and they are what get connected during system composition by connectors. They are the visible points through which a component interacts, requests or provides services, or is influenced by external state or events. Players are further specified by their own property lists.
The implementation of a component describes how it is constructed. Components have either primitive implementations, or composite implementations. A primitive implementation describes a component that is implemented by some source code or data that is external to UniCon (e.g., source code of a programming language, scripts of commands of an operating system shell, or data in a file in the file system).
A composite implementation describes a configuration of components and connectors. This mechanism in UniCon allows system designers to progressively build larger subsystems from collections of smaller components or subsystems, or more abstract components from less abstract ones.
<component> :==
COMPONENT <identifier>
<interface>
<component_implementation>
END <identifier>
The properties in a <property_list> are separated by whitespace (i.e., spaces, tabs, and carriage returns). A <property_list> can be empty (in many cases), or it may contain one or more properties. A <property> is a name-value pair that specifies an attribute, an assertion, or a constraint pertaining to a definition. It is used to further specify that definition. The syntax of a property is as follows:
<interface> :==
INTERFACE IS
TYPE <component_type>
<property_list>
<player_list>
END INTERFACE
<component_type> :==
Module
| Computation
| SharedData
| SeqFile
| Filter
| Process
| SchedProcess
| General
<property> :== <name> <value>
The <name> in a property has significance in UniCon (i.e., it conveys meaningful information about a definition); the <value> associates specific information with the property name in the given context. Here, the term context refers to the given language element of the given type (e.g., player, of type GlobalDataDef). The <value> may be NULL, or it may contain a <value_part> enclosed in parentheses. The <value_part> has a syntax that is specific to the property, in a given context. There are eleven common syntaxes for the values of UniCon properties.
<name> :== <identifier>
<value> :==
EMPTY
| (<value_part>)
The set of properties that can be legally specified in a property list depends on which definition the property list further specifies. For example, the set of properties legal for an interface property list is different from the set that is legal for an implementation's property list.
The players in a <player_list>, the variants in a <variant_list>, and the statements in a <composite_statement_list> are all separated by whitespace.
<component_implementation> :==
<primitive_implementation>
| <composite_implementation>
<primitive_implementation> :==
IMPLEMENTATION IS
<property_list>
<variant_list>
END IMPLEMENTATION
<composite_implementation> :==
IMPLEMENTATION IS
<property_list>
<composite_statement_list>
END IMPLEMENTATION
Author:
Last Modified: May 12, 1996