Specification, Implementation, and Deployment of Components

Many different concepts, definitions, and specifications lie behind attempts to successfully manage component-based development.

Contracts. The interface semantics can be achieved through contracts. A contract lists the global constraints that the component will maintain (the invariant). For each operation within the component, a contract also lists the constraints that must be met by the client (the pre-condition), and that the component promises to establish in return (the post-condition). The pre-condition, the invariant, and the post-condition constitute the specification of a component’s behavior.

Figure 1 illustrates a UML metamodel for semantic specification of a component [4]. In this metamodel, a component is determined by its interface (which provides or requires services) and by constraints. Each interface consists of a set of operations. In addition, a set of pre-conditions and post-conditions is associated with each operation. Pre- and post-conditions often depend on the state maintained by the component. Finally, a set of invariants is associated with an interface.

Beyond the specification of the behavior of a single component, contracts can also be used to specify interactions among groups of components [7]. However, they are then employed in a slightly different manner. A contract specifies the interactions among components in terms of:

• the set of participating components;
• the role of each component through its contractual obligations, such as type obligations, which require the component to support certain variables and an interface, and causal obligations, which require the component to perform an ordered sequence of actions, including sending messages to the other components;
• the invariant to be maintained by the components; and
• the specification of the methods that instantiate the contract.

Specifying Extrafunctional Properties. Extrafunctional properties determine the overall behavior of a component, but cannot be expressed through standard interfaces. Examples of extrafunctional properties are time properties (latency, worst-case execution time), reliability, robustness, and availability. Some research efforts have addressed the specification of extrafunctional properties by generalizing the term interface (and accordingly the component specification). Arsanjani et al. [1] define manners, the governing behavior of a reuse element such as classes, subsystems, and components within a given context. Thus, when a component receives a message or has registered interest in an event, the component’s manners ensures that the component responds within the semantics appropriate for its current context by checking its state, constraining the rules or flow that apply within the given context and activating extrafunctional aspects (that have often been represented as metadata). Manners cover a wide spectrum, ranging from business analysis expression of business rules assigned to a reuse element to a grammar-oriented object design specification based on a domain-specific language for a business. Manners of components provide the services for self-description, dynamic configuration, and dynamic collaboration. A component can be queried for its manners within a given processing context.

A similar approach to generalizing the interface specification is the Analytical Model [6] that comprises standard component technologies with the constructive (functional) interface, and Analysis Technology that specifies the analytic interface. The analytic interface specifies extrafunctional properties of components, and provides techniques for deriving, thus predicting extrafunctional properties of the component assemblies.