You are on page 1of 9

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)

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

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”