Component design rests on the environmental specifications – usuallygiven 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 workingcomponent system.The same environment is used to prototype a component, within acharacteristic environment, and implement the component.
Support for the construction of models (typically in UML) and supportingfurther 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 businessconcepts 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 themarketing position of RAD tools.
Component testing toolsTesting of components is possibly the single most demanding aspect ofcomponent technology.By definition, components can only be tested in a few, hopefully representative,configurations.Systematic approaches to testing of components are needed, and intense toolsupport for this purpose is likely to be required.
Faced with the extreme difficulties of component testing, two strategiesseem advisable.The first strategy is to avoid errors statically wherever possible.The second strategy is to make sure that components are deployed in such away that faults leave logged traces.In this way, a failure in a production component system can at least betraced.
Component assembly toolsComponents are assembled by instantiating and connecting component instancesand customizing component resources.While component instances at runtime may or may not correspond to visualentities, it is useful to assume that all component instances have a visualrepresentation at assembly-time. It is then possible to use powerful document-centric builder tools to assemblecomponents, even if the runtime environment is a server or batch one.JavaBeans is a component standard that explicitly distinguishes between assemblytime and runtime and that allows component instances to look and behave differentlyduring assembly-time and runtime.
An important aspect often overlooked by current “builder tools” is thatassembly itself needs to be automated.Software assembly is different from hardware assembly in that it is notnecessary 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 thatthe assembly process can be repeated – only modified where necessary to live with or take advantage of the new component versions.