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