Component design and implementation tools

BY Kalaivani.V

B.Tech IT

Component design rests on the environmental specifications –

usually given by a component framework and an underlying

component (or object) model.

Ideally, component development should use rapid application

development

(RAD) methods to capture requirements quickly within a

working component system.

The same environment is used to prototype a component,

within a

characteristic environment, and implement the component.

Support for the construction of models (typically in UML) and

supporting

further metadata can help guide the component construction

process.

At a minimum, such models help in documenting an effort.

In practically relevant cases

such as components representing relatively straightforward

business

concepts in the presence of evolved application servers

components can actually be generated from their models with

little further input from developers.

Where this approach succeeds, modeling and generator tools can

take the marketing position of RAD tools.

Component testing tools

Testing of components is possibly the single most demanding aspect

of component technology.

By definition, components can only be tested in a few, hopefully

representative, configurations.

Systematic approaches to testing of components are needed, and

intense tool support for this purpose is likely to be required.

Faced with the extreme difficulties of component testing, two

strategies seem advisable.

The first strategy is to avoid errors statically wherever possible.

The second strategy is to make sure that components are

deployed in such a

way that faults leave logged traces.

In this way, a failure in a production component system can at

least be traced.

Component assembly tools

Components are assembled by instantiating and connecting

component instances and customizing component resources.

While component instances at runtime may or may not correspond to

visual entities, it is useful to assume that all component instances have

a visual representation at assembly-time.

It is then possible to use powerful document-centric builder tools to

assemble

components, even if the runtime environment is a server or batch one.

JavaBeans is a component standard that explicitly distinguishes

between assembly time and runtime and that allows component

instances to look and behave differently during assembly-time and

runtime.

An important aspect often overlooked by current “builder tools”

is that assembly itself needs to be automated.

Software assembly is different from hardware assembly in that

it is not necessary to assemble individual instances repeatedly –

the entire assembled product can instead be cloned.

However, a different aspect of assembly processes also still

holds for software assembly.

If future versions of components become available, then it is

important that the assembly process can be repeated –

only modified where necessary to live with or take advantage

of the new component versions.

Reference:-

Clemens Szyperski, “Components

Software: Beyond Object-Oriented

Programming”

THANK YOU