how do you do it?
The ideal is to achieve 'pluggability': the ability to reconfigure
the components to cope with any variation that may be desired.
Component Based designs are about making not just one piece
of software, but a whole family of them: rather like designing
a Lego kit from which many end-products can be assembled.
What is a component, anyway? A component is something
designed to work with a variety of other components, many of
which are not known to its designer, and in configurations determined
by another designer.
A kit of components is a collection, possibly
from many sources, that are designed to the same basic architecture,
so that they can work with other members of the kit.
A component architecture (or product line architecture)
is a description of how components can be coupled, how they
interoperate, what platforms they work on. So Java Beans, MFC,
Smalltalk applications, EJB, San Francisco are all publicly-known
component architectures; any project or company can define its
own, working within its own domain.
The process of design is differentiated into three layers, which
may be performed by different people:
- Component Architecture (or "Product Line Architecture"), in which
you define the basics of how the components in the kit are coupled
together and interoperate;
- Component Design, the careful construction of components that
can function in a variety of configurations and contexts;
- Product Building, in which components are assembled to make working
The aim is to provide components that make Product Building rapid
and low-ceremony, requiring minimal construction of extra material.
So for example, the Java Swing package is a kit that requires very
little extra material to construct a wide variety of user interfaces;
San Francisco is a kit of accountancy beans that can be coupled
together to make the core of a variety of financial systems. In
each case, you might also design some of your own additional components
to meet specific needs, but you hope that the basic kit will be
sufficient for 80% of the job.
In some cases, building tools are available: for example, you
can assemble GUI components by writing software, or you can take
the easy route and use a visual builder tool, which writes the
connective software for you. VisualAge is an example of a builder
tool that ventures outside the GUI domain. Workflow systems also
come with visual flowcharting tools.
One of the things that distinguishes component design from the design
of ordinary modular systems is that the component designer doesn't
know what other components this one will be connected to: that is
up to the product builders. Component design is therefore a much
more careful process than merely modular design: you have to make
sure your component will work in a variety of contexts. Within the
package you deliver, you must include not just the component code,
but also tools that help the product builders know whether the component
is working properly, whether it is compatible with whatever they
have coupled it to.
This is the difficult bit. Fortunately, you have to do it less often
than component design or product building.
To get the flexibility to produce many variants of a basic system,
the behavioural variations between end-products must map
there must be a well-defined common language between the
components, based on a model of their domain
in distributed components, caching and other bandwidth-reducing
patterns must be employed.
For more information see
architecture — model-based architecture.
complete solutions for component design
(consultancy, courses, workshops, mentoring, seminars, development)