Component developers deposit their specifications and implementations into repositories, where they can be accessed by software architects to compose systems or by other component developers to create composite components. To provide an overview of the following section, Figure 3.1 contains an exemplary component repository, which contains most of the entities supported by the PCM.
First class entities in PCM repositories are interfaces, components, and data types. They may exist own their own and do not depend on other entities. For example, Figure 3.1 contains the interface MyInterface (upper left), which is not bound to a component. The interface contains a list of service signatures. Interfaces may also contains protocol specifications, which restrict the order of calling its services, or QoS specifications, which describe their extra-functional properties. Section 3.2.1 describes interfaces in detail.
Components may provide or require interfaces. The binding between a component and an interface is called ''provided role'' or ''required role'' in the PCM. For example, figure 3.1 contains the component A (upper), which is bound to the interface YourInterface in a providing role. Section details on the relationship between components and interfaces.
Common data types are needed in repositories, so that the signatures of service specifications refer to standardised types. In the PCM, data types can be primitive types, collection types, or composite types to build complex data structure. Figure 3.1 contains a PrimitiveDataType ''INT'' and a CollectionDataType ''INT-Array'', which only contains ''INTs'' as inner elements. Section 3.2.1 contains more information on data types.
Different types of components can be modelled in the PCM to a) reflect different development stages and b) to differentiate between basic (atomic) components and composite components. Concerning a), Figure 3.1 contains the components B, which has a ProvidedComponentType and does not contain required interfaces, C, which has a CompleteComponentType and contains no inner structure, and component D, which has an ImplementationComponentType and may contain an inner structure. Components may be refined from ProvidedComponentTypes to ImplementationComponentTypes during design.
Concerning b), component E in Figure 3.1 is a composite component. The PCM is a hierarchical component model, which allows composing new components from other components. From the outside, composite components look like basic components, as they publish provided and required interfaces. Within the composite component, they use delegation connectors to forward requests to inner components and assembly connectors to bind inner components. Composite components may also include other composite components (notice component G within component E).
For each provided service, basic components may include a mapping to required services, a so-called ServiceEffectSpecification (SEFF). It models the order in which required services are called by the provided service and may also include resource demands for computations of the service, which are needed for performance predictions. SEFFs are an abstract behavioural description of a component designed to preserve the black-box principle. Section 3.2.9 explains different types of SEFFs and their application.