Figure 3.4 gives an overview on all component types defined in the Palladio Component Model. In particular the inheritance structure (at the left) and the conforms-relations between the component type layers are shown. It should be mentioned that the conforms-relations are helper constructs to simplify the explanation of the inter component type layer semantics; they are not part of the meta-model, (cf. section 4.1) but can be manifested in constraints. Though the conforms-relation is shown as an association, component types of lower layers do not reference upper layers. Rather two component types automatically are part of a conforms-relation if they fulfil the conditions explained below. So the conforms-relation is comparable to a derived attribute.
Further more there are two conforms-relations: one between (provided type and complete type) and one between (complete type and implementation type). The conforms-relations are defined on the meta-model, but apply to model instances. More details on the conforms-relations are given in section .
The left side of the figure shows a simplified meta-model, while the right side shows a model instance structure. On the one hand the meta-model defines an inheritance structure (in the sense of adding features) between component types, on the other hand the meta-model is the part to explain the conforms-semantics with. The conforms-relation is a relation defined for the meta-model classes - for example using OCL-constraints (see [21]), while instances of the conforms-relation apply to model classes.
As pointed out above, at the model instance the conforms-relation is implicitly available only, because the association between different component types is derived, based on the constraints expressed in the meta-model. If for example a complete type conforms to a provided type this is not an explicitly modelled association. The complete type conforms to the provided type just because the conforms-conditions are fulfilled.
It should be mentioned that we consider basic and composite components as the full set of possible implementation types. Hence the implementation type is an abstract component type. Therefore no model instances of the implementation type exist. Instead basic or composite components are used.