Software Component

The definition used in this thesis is given by Szyperski et al. (2002) in their book on component-based software engineering.

Definition: Software Component (Szyperski et al.,2002) A software component is a unit

of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties. The following paragraphs explain the basic parts of the definition of a software com- ponent in more detail, i.e., contractually specified interfaces, explicit context dependen- cies, independent deployment, and third-party composition.

Contractually Specified Interfaces Components solely use interfaces to collaborate

with their environment, i.e., any accessible component service has to be part of an in- terface provided by the component. These interfaces need to be contractually specified which refers to the design-by-contract principle introduced byMeyer(1997). This princi- ple introduces a contractual relationship between some software entity requiring a service offered by some other entity. If the client fulfils a set of preconditions when requesting

a service, the server guarantees the service’s postconditions. Interface contracts may ex- ist on different levels of abstraction. For example,Beugnard et al.(1999) lists signatures, protocols, synchronization constrains, or Quality of Service requirements as abstraction levels.

Explicit Context Dependencies A component has explicit context dependencies only. As a

consequence the component has to specify what it expects from the environment in which it is used. Many of the component models (cf. section2.1.4) use the concept of required interfaces to enable the specification of services required by a component.

Independent Deployment A component has to be deployable independently of other

components. Note, that this defines the smallest software entity which can be regarded as a component: A software entity which can not be further divided into smaller entities that are independently deployable is a basic component.

Third-Party Composition Components are subject to third-party composition, i.e., their

creator is not necessarily the person who composes them. This characteristic is inspired by an engineering principle of building software applications in a distributed way. On the one hand, there are creators of software components. They are supposed to be experts for the functionality a component offers. Hence, they realise the functionality of components, specify provided and required interfaces, and finally, put them into repositories from which other developers retrieve them for composition.

The person composing two or more components is often called assembler. The assem- bler is responsible for connecting required with provided interfaces to fulfil the needs of the component. In so doing, the composite structure gets functionality based on its con- stituting components. A major assumption often made in this process is that the creator of the component and the assembler only communicate using the component’s specifica- tion. More information on this idea of dividing the development tasks among different developer roles can be found in section2.1.2.

Discussion Even if the cited definition of a software component is the one which is cited

commonly, there are still several issues remaining with this definition which are discussed in the remainder of this section.

Cheesman and Daniels (2000) raised the issue of having no means to differentiate a

component’s development stage. Hence, they suggest to differentiate component specifi- cation, implementation, deployment, and run-time stages. In the specification stage only a component specification is available, e.g., a set of interfaces the component should pro-

vide. In the implementation stage, the specification has been implemented using some programming language, i.e., the component’s code offers the specified interfaces. When put in an execution environment, such an implemented component becomes a deployed component which finally gets instantiated and executed at run-time. Szyperski et al.

(2002) require a component to have no (externally) observable state. In the classification introduced, this puts components on the type or specification level.

Another issue is the usage of the term ”component” in many different computer sci- ence areas with different semantics. Even Szyperski accepts the fact, that (software) com- ponent is a term used with various meanings. He comments on this situation by giving a definition, which only captures the most basic common characteristic of all definitions and can be derived by the origin of the word component: ”Components are for composi- tion [...]. Beyond this trivial observation, much is unclear.” (Szyperski et al.,2002).

A final issue stems from the lack of precision of the definition which renders it useless to decide whether something is a software component or not. For example, a component has to specify it context explicitly. As context is a term which is unclear without further explanations, it remains unclear which elements should be contained in such a context specification. It is commonly accepted to include the set of services required from other components in the context by the means of required interfaces. However, besides the required interfaces there can be additional dependencies to the context. For example, a specific execution environment (e.g., operating system and its services, middleware platform, virtual machine, etc.) might be needed to execute the component. A context model respecting these additional factors has been proposed byBecker et al.(2006c) and is presented in more detail in section3.2.2.