component design

Pluggability

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. 

Definitions

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.

Design

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 systems.

 

Product Building

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 to components
• 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.