This document discusses various aspects of component design, development, testing, and assembly. It states that component design relies on environmental specifications from frameworks and object models. It recommends using rapid application development methods to capture requirements within a working system. Component testing is noted as one of the most demanding aspects, requiring systematic approaches and tool support. The document also discusses using modeling tools to help guide and document the component construction process, and in some cases to generate components from models. It describes how assembly tools can be used to instantiate and connect component instances visually, even if the runtime is not visual. The importance of automating the assembly process and being able to repeat it for new component versions is also highlighted.

1. BY
Kalaivani.V
B.Tech IT

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. Reference:-
Clemens Szyperski, “Components Software: Beyond
Object-Oriented Programming”

9. THANK YOU