|
Frequently
Asked Questions
What is Component-Based Development?
Component-Based Development claims to offer a radically new approach to the
design, construction, implementation and evolution of software applications.
Software applications are assembled from components from a variety of sources;
the components themselves may be written in several different programming languages
and run on several different platforms.
Is Component-Based Development an extension of conventional software development,
or an alternative to it?
We regard CBD as an extension to conventional software development and management.
In other words, what CBD is saying is that we satisfy SOME of the requirements
using components, but we may also satisfy some of the requirements using other
(conventional) techniques. Conventional development is then a special case of
CBD, which lacks some of the techniques and opportunities (and of course the
benefits) that characterize full CBD. We then get a spread of possibilities,
from conventional development at one end, and extreme componentization at the
other end. One of the key questions to be addressed by a designer is how far
does it make sense to componentize in a particular situation.
What is a component?
A typical definition of software component runs something like this: A component
is something that can be deployed as a black box. It has an external specification,
which is independent of its internal mechanisms.
What is common to many such definitions of software component is the notion
that a component has an inside and an outside, and a relationship
between the two. There is also an implied context for the relationship.
The inside of a software component is a lump of software satisfying
such-and-such properties. It is a device, artefact or asset,
which can be managed to achieve reuse.
The outside of a software component is an interface satisfying such-and-such
properties. It provides a service or commodity to human agents
or other software artefacts.
The relationship between inside and outside is described using such
concepts as specification, implementation, or encapsulation.
The context for the relationship states how the software is to be managed
and used, within a defined process for software development and maintenance.
If the context is not stated (and it usually isn't), then concepts such as encapsulation
and reuse are ambiguous.
Are components the same as objects?
Components inherit much of the characteristics of objects in the OO paradigm.
But the component notion goes much further than the OO object notion. OO reuse
usually means reuse of class libraries in a particular OO programming language
or environment. You have to be conversant with SmallTalk or Java, to be able
to reuse a SmallTalk or Java class. You can reuse a component without even knowing
which programming language or platform it uses internally. The same specification
may be implemented in several different ways. Furthermore, as the specification
is a description of the behaviour of a component, and the behaviour may be described
in several ways, the same component may satisfy many different specifications.
Why is reuse important?
Reuse is important because it yields software economies of scale. If
software organizations wish to survive in an increasingly competitive world,
then they need to acknowledge the increasing economies of scale achieved by
their competitors, and respond appropriately to it.
However, reuse as traditionally understood is only one of several alternative
ways of achieving economies of scale in software production and deployment.
A narrow definition of reuse may be unduly restrictive.
Is reuse really going to happen this time around?
CBD offers a multiple focus of reuse
- External component libraries
- Inhouse component infrastructure
- Mining components from legacy systems
Of these, it is the legacy mining that seems to offer the greatest chance of
genuine economies of scale.
How do we measure reuse?
There are at least three possible ways of defining software reuse:
- Static reuse can be defined in terms of the number of source code
references to my component, or the number of software items that refer to
my component. Static reuse generates application benefit, in terms of faster
development and/or easier maintenance
- Deployment reuse can be defined in terms of the number of consumers
with access to services provided directly or indirectly by my component.
- Dynamic reuse can be defined in terms of the frequency of execution
of my component.
Business benefit comes from high levels of deployment reuse and dynamic reuse.
This can often be achieved without high levels of static reuse. However, a lot
of software engineering is focused on static reuse.
What organizations are currently doing Component-Based
Development?
Relatively few organizations have started doing CBD seriously. It is being
adopted faster in some industries than others - notably insurance and other
financial sectors, and telecoms. Many other organizations are holding a watching
brief - they are attending industry and vendor briefings, or joining the CBD
Forum, but have not yet started doing CBD seriously.A number of large software
vendors have made a major commitment to Component-Based Development, including
Forte, IBM, Microsoft, SAP, Sterling and Sun.
How does CBD differ from previous approaches and technologies?
At first sight, Component-Based Development might seem to be little more than
a fashionable new label for some traditional software ideas: modular programming
and subroutine libraries. Even in the 1960s, these ideas promised high levels
of software reuse (although this was rarely achieved). But to the extent that
CBD is a genuine innovation, this is to be found in its approach to legacy systems:
some of the most significant potential cost-savings associated with CBD involve
extracting (or ‘mining’) components from existing code. It is perhaps this element
of CBD that arouses the greatest scepticism, and offers the greatest potential
rewards.
Request
more Information
|
