One of the most important arguments for component-based software development is the black-box reuse of components. Components are developed by third party vendors, who sell their products to multiple clients. Therefore, component developers cannot make assumptions on the underlying middleware, operating system, and or, in other words, the context the component will be used in. Szyperski defines a software component as ``a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to a composition by third parties'' [].
This definition emphasises the importance of context dependencies and their explicit definition. However, it remains vague what is actually part of the context beyond the relationships defined by the provided and required interfaces of a component. One of those undefined dependencies is the underlying hardware that influences QoS attributes of a component, like performance and reliability. Especially for QoS predictions, knowledge about such dependencies to the context is needed in addition to functional specifications, like behavioural protocols [13] and service effect specifications [14].
Factors influencing the QoS attributes of a component can be classified into four main categories as shown in figure 2.8:
With these four categories of influences we can define the quality of a provided service of a concrete component as a function of the varying influences.
The implementation of the component's service is considered as a constant as it does not depend on its context but is fixed by the component developer. Thus, the QoS of a component can be defined as a function of the remaining parameters, which are determined during its allocation, assembly and usage: