next up previous contents index
Next: Type Hierarchy Up: Component Developer (OLD) Previous: Interpretations of Required Interfaces   Contents   Index


Component Types

stable
A component type is an exterior view on a component. It attests component properties that can be observed from outside of the component, such as the provided and required roles including their associated interfaces, the component name, and a SEFF. The PCM differentiates component types on different modelling layers (which are described in section 3.2.5.1; cf. figure 3.3):

Note that implementation component types are not source code implementations, but abstractions of component implementations.

Each component type represents a different level of abstraction. Lower component levels provide more information than upper levels. The modelling layers are aligned with the component development process (c. f. section 3.3.

It is possible to follow two approaches for component type specification: top-down and bottom-up. On the one hand a top-down-approach (see [18]) of modelling is supported. The component development starts at an abstract level. Step by step component details are added, ending at lower levels of component types. There are specific guidelines the detailing process has to follow for each component type. These guidelines are expressed by the conforms-relation (c. f. section 3.2.5.3) between adjoining layers. The conforms-relation ensures to have a consistent component type definition for each component type across the type layers.

On the other hand, it is possible to follow a bottom-up-approach (see [18]). A component development process does not have to start from zero: there may be existing components. Those components can be analysed to extract component types. This leads to fully specified component types (implementation component types). The type layers then dictate how to gain higher levels of abstractions, informations that have to be abstracted away are explicitly specified.

The PCM is able to accommodate component types of different levels at the same time. This allows one to use even mixed approaches of top-down and bottom-up, as experienced developers tend to use a mixed approach.

Especially, it is possible to have a different abstraction level for each component. Detailed information for components can be added for those components only:



Subsections
next up previous contents index
Next: Type Hierarchy Up: Component Developer (OLD) Previous: Interpretations of Required Interfaces   Contents   Index
Snowball 2007-03-16