The Definition and Specification of Components

We have a general idea of what a component is, but because, in the software context, what we know as components have so many varied forms, functions and characteristics, (as source code modules, parts of an architecture, parts of a design, binary deployable executables, etc.), there is a correspondingly large number of definitions of a component. This part outlines different definitions of software components and other concepts related to component-based software development. A component has many different parts which must be specified for many different purposes and there is a consequent need for different specification techniques. It is not only the component which must be specified, the environment in which the component is intended to function must also be specified to prevent its misuse or unintended use. Functional, operational, quality and design specifications are examples of different types of component specifications. The description of a component is not easy if it is not clear what a component is. Thus, a well-formulated and clearly understood definition of the component concept is needed.

In the first chapter Basic Concepts in Component-Based Software Engineering, Ivica Crnkovic, Brahim Hnich, Torsten Jonsson and Zeynep Kiziltan present the basic definitions of terms related to component specification and operation: interface, contract, framework, and pattern and the relations between them. A component is a reusable unit of deployment and composition which is accessed through an interface. An interface specifies the access points to a component. The component specification can be achieved through contracts which make sure certain conditions hold true during the execution of a component within its environment. A framework describes a large unit of design with defined relationships between participants of the framework. The last term discussed is patterns which define recurring solutions to recurring problems on a higher abstract level. Patterns enable reuse of the logical solutions and have proven very useful. The chapter describes these terms and discusses relations between them.

The second chapter Specification of Software Components, written by Frank Lüders, Kung-Kiu Lau and Shui-Ming Ho, describes various techniques for component specification. A component is specified by its interface, which must consist of a precise definition of the component's operations and context dependencies. In the existing component models the specification is focused on the syntactic aspects of the interface. The chapter also discusses other specification techniques which use UML and the Object Constraint Language and in which a component implements a set of interfaces. Each interface consists of a set of operations with associated pre-/post-conditions and invariants. The pre-conditions define which conditions must be satisfied before the operation begins, and the post-conditions define which conditions will be valid after the execution of the operation. The invariants are the states which must remain valid during and after the execution of the operation. This type of specification gives more accurate information about the component behavior. Finally the chapter discusses the extra-functional characteristics of a component, (for example reliability), which are not covered by these types of specifications and which are matters of current research interest.