veryard projects - innovation for demanding change

component-based development

frequently asked questions

concepts / notions
frequently asked questions
home / service
please read component ecosystems the context for CBD Component-Based Development (what is it, how is it similar, how is it different?) 

Component (what is it? how many have I got? always software? same as Object?)


Reuse (why important? will it happen? how measure?)

What is CBD good for?

What organizations are currently doing CBD?

Is CBD a genuine innovation, or just new terminology and hype?

How does CBD alter the software supply chain?

What is UML good for?

component based development - component-based business


Book list

CBD Concepts 

Component-Based Development

Early bicycle components (1870s)




CBD Frequently Asked Questions 

What is CBD good for?

If a software application is assembled from components, then it should be easy to reconfigure the components to support desired changes in the business process. Business processes may be improved in three ways:  
Simplification Removing one or more steps from an unnecessarily complicated process, or reducing unnecessary variety in the process. This can often by done by replacing components to produce stepwise improvements.
Integration Joining two or more previously unconnected or uncoordinated processes into a larger coordinated process This can often by done by inserting additional components to create new links.
Transformation Creating a radically new process.  Disassembling the components, and putting them back together in a new way, can often achieve this.
ISO 9126 provides a generic definition of software quality, in terms of six desirable characteristics. We can explain how CBD contributes to each of these.  
Functionality Use of pre-existing components allows faster delivery of greater functionality.
Maintainability The modular structure of a component-based solution allows individual components to be replaced easily.
Usability Use of standard components supports commonality of GUI. CBD also supports desk-top integration, which gives the user a single view of heterogeneous data.
Efficiency Performance bottlenecks can be identified, and the need for performance tuning can then usually be localized in a small number of performance-critical components. Components can be internally optimized to improve performance, without affecting their specification; components can be moved between platforms to improve performance, without affecting the functionality or usability of the application.
Reliability Given a formal and complete specification of a component, the reliability of a component comes down to the simple question: does the component provide a correct and complete implementation of its specification. The reliability of the application as a whole is a separate issue, but is clearly enhanced when the application is constructed from reliable components.
Portability The specification of a component is platform-independent. So a component can be quickly rebuilt for a new platform, without affecting any other component. (With some tools, this will often require no alteration to the internal design, merely a regeneration of the executable portion.)
Legacy code is often compared to spaghetti, but lovers of Italian food will recognize that pizza provides a much better analogy. You try to cut out a wedge of pizza, but it remains connected to the rest of the pizza by innumerable strands of elastic cheese.

In conversion projects such as Year 2000 or Euro, the task is to get the entire legacy portfolio compliant with a specific new requirement, such as four-digit dates or a change of currency. The challenge is to break this task into manageable chunks.

A chunk of legacy system makes a component. Each chunk needs to be tested and implemented separately. Clean interfaces need to be defined between the chunks, so that converted chunks can interoperate with unconverted chunks. Management will be reassured when they see a growing number of converted chunks successfully tested and incorporated into production systems.

As each chunk of legacy system is converted, it is provided with two parallel interfaces: one for communicating with unconverted chunks, and one for communicating with converted chunks.

The alternative is a very high-risk strategy: big bang conversion, where the entire legacy portfolio is converted from non-compliance to compliance in a single overnight integration test and implementation.

Component-based development is therefore the only low-risk strategy for Year 2000 and Euro conversion projects.

moreY2K and Euro

What organizations are currently doing Component-Based Development?

Is CBD a genuine innovation?

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.

How does CBD alter the software supply chain?

Increasing automation and maturity of tools Existing CASE and OO vendors are starting to move into the CBD marketplace, and there are some exciting new players as well. Use of the current tools still demands considerable manual effort. Shells and interfaces often have to be built by hand, and the matching of component requirements is poorly supported. Over the next couple of years, we can expect the tools to become more powerful and easy to use, covering a greater range of the CBD processes. This will enable still greater productivity and scaleability.
Greater differentiation of software work Each advance in software engineering makes it more difficult for the software engineer to remain a true generalist. Some software engineers will become specialist component engineers, deploying formal methods to create and verify robust and widely reusable software components. Others will concentrate on satisfying local business requirements, designing context-sensitive and user-friendly interfaces.
From component scarcity to component abundance A lot of the discussion of component-based development today is based on the premise that good components are scarce. A lot of the techniques are based on this mindset of component scarcity. However, if CBD takes off, we will quickly move into a world of component abundance. Indeed, we may even get into a world of component pollution, in which it becomes an antisocial act to overpublish redundant components.
Increasing variety while decreasing variation Standard components that can be configured in countless ways. For a business using CBD effectively, this establishes the possibility of mass customization, whereby the business can respond flexibly to the needs of individual customers, without losing economies of scale and scope. 
moresoftware supply chain
The discussion of component-based development often concentrates on the creation of components and their assembly into applications, but there are several other important processes to consider.  
Creation Building new components, (re)using available stuff where possible.
Assembly Building applications from components.
Publication This is the act of making a component available to a defined public. There may be nested publics - thus a component may be published internally, or to beta customers, before it is published to the entire marketplace. Alternatively, a beta version of a component may be made freely available for a limited time period, and then withdrawn, to encourage people to pay for the commercial release. Publication usually involves some form of publicity. This is part of the publication process, and not an optional extra.
Dissemination The word originally refers to the process by which a plant spreads its seeds. Some plants launch their seeds into the wind or pop them into the air, others use animals or birds to carry their seeds great distances. Some seeds fall on stony ground, some seeds lie dormant in dry sands for many seasons until the rains come. Similarly, some components may be tossed around by the random winds of the Internet, while others may be safely carried to fertile application ground. The original developer of the component cannot know - but may try to influence - how and when and where and by whom and for what purpose the component may be used.
Matching A would-be component user is looking for a component. Perhaps with a definite specification; perhaps only with a rough idea of what is needed. Meanwhile the component publisher is looking to maximize the use of a given component. To focus either on the searching process or on the publication process is to see only half the picture. We should rather think of this as a matching process, in which the user and publisher collaborate. This collaboration may be initiated either by the user (demand-pull) or by the publisher (supply-push).
Requirements How do we know what we want to do?
Architecture How do we balance structure with flexibility?
Investment Who pays for an organization to get into component-based development? Not only are new tools and skills required, but the acquisition and verification of the components themselves may incur an upfront cost. 

Either this comes from the budget of a single development project - in which case it will be expected to payback within this project.

Or it comes from some central infrastructure budget - in which case there are other management issues to address.

Procurement To what extent do traditional software procurement processes conflict with CBD?
Security To verify the security of your information and systems, you may need to look inside the components you are using, and it may be important to know their physical location. According to CBD purists, we aren't supposed to be able to do this.
Feature Interaction How do I know that two components I want to use might conflict in ways I don't yet know about? (This is a problem already widely studied in the telecoms world, and is now starting to become relevant for software engineers.)
Testing A component may be expected to satisfy many different requirements, in many different contexts. The original developer of the component may be unaware of the uses to which the component may be put. So how can it be adequately tested?

For a more detailed discussion of this issue, CLICK HERE.

Configuration Management Many organizations aren't very good at keeping track of a few large applications. How are they going to keep track of a vast number of much smaller components?
Tools What tools do I really need? And how do I make effective use of them?

What is UML good for?

Display the boundary of a system Illustrate the boundary of a system Represent the static structure of a system Model the behaviour of a system Reveal the physical implementation architecture Extend your functionality
Use Case Diagrams Collaboration Diagrams 

Sequence Diagrams

Class Diagrams State Transition Diagrams Component Diagrams

Deployment Diagrams



[Source: Rational Corporation]

Recommended reading

veryard projects - innovation for demanding change veryard projects is an active member of the SCIPIO Consortium and the CBD forum.

We provide consultancy and training to user and vendor organizations.

Please contact us to discuss your requirements.

This page updated May 19th, 1999.
Copyright © 1997, 1998, 1999 Richard Veryard