veryard projects - innovation for demanding change CBD home page notion finder

notions of software componentry

veryard projects > cbse > notions
on this page
software size
on other pages
veryard projects home page
cbse page
ecological model of component supply
veryard projects glossary & index
contact us
Software componentry (CBD, CBSE) is commonly described in terms of a set of notions (interface, service, encapsulation, reuse, plug-n-play). But these notions do not have a single interpretation from all perspectives. Even the notion of component itself means something different, according to whether you are talking to Java programmers or repository managers or potential purchasers.

On this page, we define these notions in the context of an ecological model of component supply

veryard projects - innovation for demanding change


veryard projects > cbd notions > component


A software component involves a relationship between a service interface (in the Supply ecosystem) and a software device (in the Device ecosystem). The device implements the interface, the interface specifies the device.

This is a many-to-many relationship. One interface may by implemented several different ways, by different devices. One device may satisfy many different specifications, describing different interfaces.

In practice, software components often fall short of this ideal definition. It may be more accurate to say that the device claims to implement the interface, while the interface tries to specify the device.


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.

How many components have I got?

That depends where you start.

Some technical experts avoid these ambiguities by producing complicated metamodels, in which the original notion of software component is decomposed into separate concepts: SERVICE INTERFACE, INTERFACE SPECIFICATION, SOFTWARE UNIT DESIGN, SOFTWARE EXECUTABLE, and so on. These metamodels are vital for the builders of tools and repositories; but they can be confusing for beginners, as the concept of software component disappears into separate conceptual fragments.

Definitions provide a basis for counting things. If you have no basis for counting something, then you have failed to define it properly. And this has consequences for other definitions as well. For example, if you don't know how many components you have, then you don't have a basis for defining and measuring software reuse.

Are components always software?

This question is frequently asked, with two entirely different intentions.

Both questions are important, and we need to be clear on both counts. My own preference is to say NO to both questions.  I prefer to use the term software component when I want to talk about a piece of software behaviour.  And I prefer to use the term executable software component when I want to be clear that the executable software is included in the package.

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.

What is a good component?

Having identified a number of different perspectives on what is a component, it follows that there are at least as many perspectives on what is a good component. In an open distributed world, there is no single value system or global intentions against which the goodness of a component - or anything else for that matter - can be evaluated. Instead, I prefer to take an ecological view.

Given a global soup of people, machines, components and other devices, components follow a Darwinian logic: the survival of the fittest. What I am prepared to say is: what are the "fitness" factors for software components - in other words, what are the ecological principles that determine which components are more likely to be widely used and referenced within a large complex ecosystem.
more A detailed version of this argument can be found in Chapter 3 of my book The Component-Based Business.

veryard projects - innovation for demanding change


veryard projects > cbd notions > encapsulation

When is a component not a component? One of the most important characteristics of a component is said to be something called encapsulation. What exactly is encapsulation? Encapsulation is not an attribute of a lump of ‘code’ that makes it into a component. It is a characteristic of a relationship between a lump of ‘code’ and a person or role. This or that control is accessible to the end-user, these workings are not directly accessible to the end-user. The diagram shows four levels of encapsulation.
Degrees of encapsulation
The unit of use is the operation. The user of a component which may be human or software) only needs to know the specification of the operation(s) being used. The user doesn’t even need to know that several operations are actually performed by a single component.

The unit of delivery is the component. The purchaser of a component needs to identify and acquire whole components.

If a component calls other components, then the availability of these other components is a precondition for a successful installation of the component. The installer, therefore, needs to know what calls are made to other components.

Most of the people who interact with a component can be satisfied with the above. Only the software engineer, charged with building, inspecting or modifying the internals of a component, needs to look inside it.
How do we resolve this apparent confusion? We observe that the different roles belong to different ecosystems. We can then characterize encapsulation as a statement about the relationship between the Service Supply ecosystem and the Device Supply ecosystem. Certain aspects of a component are not accessible within the Service Supply ecosystem, and are hidden behind the service interface.

Encapsulation can also be expressed as an approximately equivalent statement about the relationship between the Service Use ecosystem and the Device Use ecosystem.

veryard projects - innovation for demanding change

Generalization / Specialization

veryard projects > cbd notions > generalization

The generalization of a component or service has to do with the degrees of freedom.  A specialized component is adapted to a specific usage-niche. whereas a generalized component is adaptable to many different usage-niches.

From the user side, we are interested in the adaptability of the assembled solution.  Does this mean we have an automatic preference for using adaptable (i.e. more generalized) components?  Not necessarily. (An alternative strategy is to use cheap and easily replaceable (throwaway) components.

Generalized components may cost more to develop, and this cost may be passed on to the user. However, generalized components can sometimes be cheaper, because they have a much larger potential market, and the production costs can be shared across a larger base.  Generalized components may also cost more to operate, because their complexity has a negative effect on performance and usability.

Obviously we don't want to incur the cost of degrees of freedom that are not relevant to our business, so we need some way of judging whether the generalization is potentially useful and relevant.

veryard projects - innovation for demanding change


veryard projects > cbd notions > interface

Interfaces and specifications

A musical keyboard provides an interesting example of a standard interface. When I press a particular sequence of keys, I expect an instrument to respond with a particular sequence of notes. Many different instruments provide the same interface: pianos, harpsichords, organs and synthesizers. Some music software has a virtual implementation of the same interface: it provides a visual display of the same pattern of keys, but these keys are pressed with mouse clicks rather than directly with the fingers.

But there are also important differences between the various implementations of this interface. Some instruments are powered by electricity. This means that a complete specification of the interface includes the precondition <instrument is switched on>. On a piano, the keys also control the volume and duration of the note. On an organ, the keys control the duration of the note but the volume is controlled elsewhere. On a harpsichord or a toy piano, you get the same short note however long you hold down the key. On some toy pianos, you only get one note at a time however many keys you press.

Thus the piano interface satisfies one specification that is common to other keyboard instruments, but it also satisfies another specification that is unique to pianos.

This simple example demonstrates that there is an important difference between the interface and the specification of the interface.

Quality of service

Much of the discussion of software component specification focuses on the so-called functional requirements.

Equally important to the user are the so-called non-functional requirements, including performance (or response time), reliability (or uptime) and cost.

These requirements are not usually part of the interface, but they will often be part of the specification.

veryard projects - innovation for demanding change


veryard projects > cbd notions > reuse

What is reuse?

material Much of the time, we are talking about the reuse of software components and related artefacts. However, the reuse agenda extends to many other types of knowledge and intellectual property.
purpose The desired outcome is to achieve economies of scale in software development and management -- thus reuse amounts to a conservation of energy.
form At some level of abstraction, reuse takes the form of the same solution to the same problem.
process Reuse is an exercise in knowledge management.

Why is reuse important?

Some people prefer to speak about software economies of scale. This is certainly important, if software organizations wish to survive in an increasingly competitive world.

Reuse of software assets primarily makes sense within the Device Supply ecosystem, although it also has relevance within the Device Use ecosystem.

Within Device Supply, reuse equates to economies of scale in software development and maintenance. Within Device Use, reuse equates to economies of scale in software procurement and operation, which is not the same thing. These impact the Service ecosystems only indirectly, to the extent that they affect service variety, cost and quality of service.

Within the Service ecosystems, a different notion of reuse can be focused on the commonality of services and interfaces. In order to exchange word processing documents with my friends and associates, I need a common exchange format. It ought not to matter to me what version of what word processing product they are using, as long as the formats match. I can certainly send faxes to people without knowing what fax machine they have.

Is reuse really going to happen this time around?

CBD offers a multiple focus of reuse 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: 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.

more Further Notes on Reuse
cbdi forum Visit the CBDiForum site for lots more material about software reuse. Silver and gold members should read recent issues of Interact, which contain Lawrence Wilkes' extended reports on Component Management and Reuse.
more There's lots more material about Software Reuse on the ComponentSource and Flashline websites.

veryard projects - innovation for demanding change


veryard projects > cbd notions > plug'n'play

The very metaphor of plugging and playing means that we are in the Device Use ecosystem. This notion has no meaning in the other three ecosystems. Plugging usually implies unplugging. But unplugging is not always as easy as plugging, and sometimes there are bits left behind. Notoriously, there are some components that appear to be plug and play -- but once played they are almost impossible to eliminate from the system (without reconfiguring from scratch), and may interfere with attempts to use rival products.

veryard projects - innovation for demanding change

Software Size

veryard projects > cbd notions > software size

Software size is a metric describing software artefacts, including components (i.e. component implementations).

Why does software size matter?  Because it's one of the main ways of estimating effort, value and productivity.

This is important in several contexts.

more Metrics

veryard projects - innovation for demanding change


veryard projects > cbd notions > specification

A specification is a description of behaviour. It may also be regarded as an acceptance test criterion - a satisfactory component must pass this test.

It is nearly always possible to add something meaningful to a description, without contradicting it. This is particularly true for so-called non-functional requirements. Thus for example the response time or reliability requirement may be made more stringent.

If you have a lump of software that satisfies a given specification, and you now want it to satisfy a tighter specification, what do you need to do? Sometimes nothing - it may already satisfy the stronger specification.

And tightening the specification doesn't necessarily alter the interface either.

Is it a good thing to make a specification tighter, more stringent? Not always. It may reduce the tolerance to alternative implementations, reduce the number of available devices satisfying the specification, and thus reduce the ability to plug-n-play.
more Declarative specification versus procedural specification

veryard projects - innovation for demanding change

[home page]

[contact us]

This page last updated on December 3rd, 2001
Copyright © 1999-2001 Veryard Projects Ltd
in asssociation with 
antelope projects
CBDi Forum