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: