Component-Based Software Engineering

21.1 Component-based development

Component-based software engineering (CBSE) is an approach to software development that
relies on the reuse of entities called software components. It emerged from the failure of objectoriented development to support effective reuse. Single object classes are too detailed and
specific. Components are more abstract than object classes and can be considered to be standalone service providers. They can exist as stand-alone entities.
CBSE Essentials
Independent components specified by their interfaces.
Component standards to facilitate component integration.
Middleware that provides support for component inter-operability.
A development process that is geared to reuse.
CBSE and design principles
Apart from the benefits of reuse, CBSE is based on sound software engineering design
principles:
Components are independent so do not interfere with each other;
Component implementations are hidden;
Communication is through well-defined interfaces;
Component platforms are shared and reduce development costs.
Component standards
Standards need to be established so that components can communicate with each other and interoperate. Unfortunately, several competing component standards were established:
Suns Enterprise Java Beans

 Microsofts COM and .NET

CORBAs CCM
In practice, these multiple standards have hindered the uptake of CBSE. It is impossible for
components developed using different approaches to work together.
CBSE problems
Component trustworthiness - how can a component with no available source code be trusted?
Component certification - who will certify the quality of components?
Emergent property prediction - how can the emergent properties of component compositions
be predicted?
Requirements trade-offs - how do we do trade-off analysis between the features of one
component and another?
Components
Components provide a service without regard to where the component is executing or its
programming language
A component is an independent executable entity that can be made up of one or more
executable objects
The component interface is published and all interactions are through the published interface;
Component definitions
Councill and Heinmann
A software component is a software element that conforms to a component model and can be
independently deployed and composed without modification according to a composition
standard.
Szyperski

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.

Component as a service provider

The component is an independent, executable entity. It does not have to be compiled before it is
used with other components. The services offered by a component are made available through an
interface and all component interactions take place through that interface. The component
interface is expressed in terms of parameterized operations and its internal state is never exposed.

Component interfaces

Provides interface

Defines the services that are provided by the component to other components.
This interface, essentially, is the component API. It defines the methods that can be called by
a user of the component.
Requires interface
Defines the services that specifies what services must be made available for the component to
execute as specified.
This does not compromise the independence or deployability of a component because the
requires interface does not define how these services should be provided.
Component models
A component model is a definition of standards for component implementation, documentation
and deployment. Examples of component models are:

 EJB model (Enterprise Java Beans)

COM+ model (.NET model)
Corba Component Model
The component model specifies how interfaces should be defined and the elements that
should be included in an interface definition.

Elements of a component model

Interfaces
Components are defined by specifying their interfaces. The component model specifies how the
interfaces should be defined and the elements, such as operation names, parameters and
exceptions, which should be included in the interface definition.
Usage
In order for components to be distributed and accessed remotely, they need to have a unique
name or handle associated with them. This has to be globally unique.
Deployment
The component model includes a specification of how components should be packaged for
deployment as independent, executable entities.
Middleware support
Component models are the basis for middleware that provides support for executing components.
Component model implementations provide:
Platform services that allow components written according to the model to communicate;
Support services that are application-independent services used by different components.
To use services provided by a model, components are deployed in a container. This is a set of

interfaces used to access the service implementations.

CBSE processes
CBSE processes are software processes that support component-based software engineering.
They take into account the possibilities of reuse and the different process activities involved
in developing and using reusable components.
Development for reuse
This process is concerned with developing components or services that will be reused in
other applications. It usually involves generalizing existing components.
Development with reuse
This process is the process of developing new applications using existing components and
services.
Supporting processes
Component acquisition is the process of acquiring components for reuse or development into a
reusable component.
It may involve accessing locally- developed components or services or finding these
components from an external source.
Component management is concerned with managing a companys reusable components,
ensuring that they are properly catalogued, stored and made available for reuse.
Component certification is the process of checking a component and certifying that it meets its
specification.

CBSE for reuse

CBSE for reuse focuses on component development. Components developed for a specific
application usually have to be generalised to make them reusable. A component is most likely to
be reusable if it associated with a stable domain abstraction (business object). For example, in a
hospital stable domain abstractions are associated with the fundamental purpose - nurses,
patients, treatments, etc.
Component development for reuse
Components for reuse may be specially constructed by generalising existing components.
Component reusability
Should reflect stable domain abstractions;
Should hide state representation;
Should be as independent as possible;
Should publish exceptions through the component interface.
There is a trade-off between reusability and usability
The more general the interface, the greater the reusability but it is then more complex and
hence less usable.
Changes for reusability
Remove application-specific methods.
Change names to make them general.
Add methods to broaden coverage.
Make exception handling consistent.
Add a configuration interface for component adaptation.
Integrate required components to reduce dependencies.

 Exception handling
Components should not handle exceptions themselves, because each application will have its
own requirements for exception handling.
Rather, the component should define what exceptions can arise and should publish these as
part of the interface.
In practice, however, there are two problems with this:
Publishing all exceptions leads to bloated interfaces that are harder to understand. This may
put off potential users of the component.
The operation of the component may depend on local exception handling, and changing this
may have serious implications for the functionality of the component.

Legacy system components

Existing legacy systems that fulfill a useful business function can be re-packaged as
components for reuse.
This involves writing a wrapper component that implements provides and requires interfaces
then accesses the legacy system.
Although costly, this can be much less expensive than rewriting the legacy system.
Reusable components
The development cost of reusable components may be higher than the cost of specific
equivalents. This extra reusability enhancement cost should be an organization rather than a
project cost.

 Generic components may be less space-efficient and may have longer execution times than
their specific equivalents.
Component management
Component management involves deciding how to classify the component so that it can be
discovered, making the component available either in a repository or as a service, maintaining
information about the use of the component and keeping track of different component versions.
A company with a reuse program may carry out some form of component certification before the
component is made available for reuse.
Certification means that someone apart from the developer checks the quality of the
component.

CBSE with reuse

CBSE with reuse process has to find and integrate reusable components.
When reusing components, it is essential to make trade-offs between ideal requirements and the
services actually provided by available components.
This involves:
Developing outline requirements;
Searching for components then modifying requirements according to available functionality.
Searching again to find if there are better components that meet the revised requirements
Composing components to create the system

Component identification issues

 Trust: You need to be able to trust the supplier of a component. At best, an un-trusted component
may not operate as advertised; at worst, it can breach your security.
Requirements: Different groups of components will satisfy different requirements.
Validation:
The component specification may not be detailed enough to allow comprehensive tests to be
developed.
Components may have unwanted functionality. How can you test this will not interfere with
your application?
Component validation
Component validation involves developing a set of test cases for a component (or, possibly,
extending test cases supplied with that component) and developing a test harness to run
component tests.
The major problem with component validation is that the component specification may not
be sufficiently detailed to allow you to develop a complete set of component tests.
As well as testing that a component for reuse does what you require, you may also have to check
that the component does not include any malicious code or functionality that you dont need.
Ariane launcher failure validation failure?
In 1996, the 1st test flight of the Ariane 5 rocket ended in disaster when the launcher went out of
control 37 seconds after takeoff.
The problem was due to a reused component from a previous version of the launcher (the Inertial
Navigation System) that failed because assumptions made when that component was
developed did not hold for Ariane 5.
The functionality that failed in this component was not required in Ariane 5.
Component composition

 The process of assembling components to create a system

Composition involves integrating components with each other and with the component
infrastructure.
Normally you have to write glue code to integrate components.
Types of composition
Sequential composition: where the composed components are executed in sequence. This
involves composing the provides interfaces of each component.
Hierarchical composition: where one component calls on the services of another. The provides
interface of one component is composed with the requires interface of another.
Additive composition: where the interfaces of two components are put together to create a new
component. Provides and requires interfaces of integrated component are a combination of
interfaces of constituent components.
Interface incompatibility
Parameter incompatibility: where operations have the same name but are of different types.
Operation incompatibility: where the names of operations in the composed interfaces are
different.
Operation incompleteness: where the provides interface of one component is a subset of the
requires interface of another.
Adaptor components
Address the problem of component incompatibility by reconciling the interfaces of the
components that are composed.
Different types of adaptor are required depending on the type of composition.
An address Finder and a mapper component may be composed through an adaptor that strips the
postal code from an address and passes this to the mapper component.
Composition through an adaptor

 The component postCodeStripper is the adaptor that facilitates the sequential composition of
addressFinder and mapper components.
The Object Constraint Language
The Object Constraint Language (OCL) has been designed to define constraints that are
associated with UML models.
It is based around the notion of pre and post condition specification common to many formal
methods.

Summary

Process Improvement
CMMI
CBSE
CBSE problems
Component models
Middleware support
CBSE processes
CBSE for reuse