next up previous contents index
Next: Context Influences Up: Context Previous: Context   Contents   Index

Motivation

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].

Figure 2.8: Influences on quality
Image modell
Factors influencing the QoS attributes of a component can be classified into four main categories as shown in figure 2.8:
  1. The implementation of the component, e.g. the selection of an algorithm.
  2. The quality of required services, e.g. calling a slow or a fast service will result in a different performance for the provided service perceived by a user.
  3. The runtime environment the component is deployed in. This includes the hardware and system software like the operating system and middleware platforms.
  4. The usage of the component, e.g. if the component has to serve many requests per time span it is more likely to slow down.

With these four categories of influences we can define the quality of a provided service $ s$ 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:

$\displaystyle q_{impl} : \mathcal{P}(s) \times \mathit{DR} \times \mathit{UP} \to Q
$

where $ \mathcal{P}(s)$ the domain of the set of external services used by service $ s$, $ DR$ specifies the deployment relationship defining which component and connector is deployed on which part of the execution environment and $ UP$ describes the usage profile. As a result, the function yields a value in the domain of the investigated quality metric $ Q$.


next up previous contents index
Next: Context Influences Up: Context Previous: Context   Contents   Index
Snowball 2007-03-16