|
|
|
notions of software componentryveryard projects > cbse > notions |
|
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. |
 |
Componentveryard projects > cbd notions > component |
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.
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. |
|
An outside-in definition of component concentrates on the external service interface. A component is an interface with one or more (software) implementations. | Note: you may not always be able to detect from the interface specification whether the implementation involves software at all. For example, a credit check may be carried out automatically by software, or by human intervention. Neither the customer nor the sale clerk should know the difference. |
|
An inside-out definition of component concentrates on the internal software asset. A component is a lump of software providing services through one or more interfaces. | Note: a single software asset may provide the same functionality at two or more different levels of service (typically at different prices). For example, you can pay a fraction of a cent to get a rough weather forecast, or a much higher price to get a more detailed and more accurate forecast. |
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.
|
Some people interpret the question to be whether a component always is (or includes) executable software code. For them, the interesting debate is: whether a reusable chunk of software specification, or an abstract software pattern or framework, counts as a component. | If I buy a component, what exactly am I paying for. |
|
Some people interpret the question quite differently: whether the implementation necessarily involves software at all. They may wish to specify a load of system behaviour in terms of components, before deciding which of these components will be executed as software. | If I design a piece of behaviour as a component, what design commitment have I made? |
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.
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.
 |
A detailed version of this argument can be found in Chapter 3 of my book The Component-Based Business. |
|
Encapsulationveryard projects > cbd notions > encapsulation |
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.
|
Generalization / Specializationveryard projects > cbd notions > generalization |
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.
|
Interfaceveryard projects > cbd notions > interface |
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.
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.
|
Reuseveryard projects > cbd notions > 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. |
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.
|
Further Notes on Reuse |
 |
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. |
|
There's lots more material about Software Reuse on the ComponentSource and Flashline websites. |
|
Plug'n'playveryard projects > cbd notions > plug'n'play |
|
Software Sizeveryard projects > cbd notions > software size |
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.
|
Metrics |
|
Specificationveryard projects > cbd notions > specification |
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.
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.
|
Declarative specification versus procedural specification |
|
|