What factors are considered during component qualification in component based development?

Component based development is now becoming a common practice nowadays for re- using the validated software components of the already existing software systems or applications as a measure to shorten the development periods and enhance the quality of the software system or application.

The component based development focus on the development of new software systems by selection of the software components within the system architecture. Furthermore, the component based development has been known to accelerate the productivity of the development process and reduce the project costs. 

However, the success of the component based development depends on the suitability of the components chosen for the development of the new software. In this article we have discussed about the factors that should be considered during the component qualification in component based development. 

Due to some factors like increasing complexity and continuous change, it is required that the software should be changed to make the both ends meet. As a consequence, the software system or applications becomes more and more complex which means more and more errors. Assembling pre- existing software components not only increases the maintainability of the systems but also lends it more flexibility. Moreover, the system is assembled rapidly. It would not be wrong to call a component an independent entity intact with a complete functionality.

Process of Component Qualification

- Component qualification is a process that involves determination of the suitability of the component for being re- used in the next software system or application to be built. 

- This process of component qualification often comes to a great help whenever there is a competition for the products in the market.

- There are numerous factors that should be considered while counting for the qualification of a software component. 

Factors Considered during Component Qualification

- The most important factors are of the functionality and services that are being provided by the software component. 

- The factors also consist of many other aspects like those mentioned below:

1. Standards that have been used to develop the software component.
2. Quality aspects like usability, reusability and component reliability and so on.

- The components should have been developed under some standards and provide functions common to most of the different software systems and applications should be qualified.

- Further, the qualified components should exhibit the property of re- usability to a high extent. 

- Components form high level aggregations of the smaller software pieces. 

- All these components together provide a black box building approach which encapsulates the implementation detail from the development environment and is re- usable with the interfaces.

- For a component to be qualified, the component should have been developed in such a way that it is able to connect to a software component during the run time of the system. 

- Or we can say that in order to be qualified, the component should exhibit the quality of independent deployment. 

- This is necessary because this approach makes use of the resources. 

- The component qualification is one of the development activities that are under taken by the component based software development. The other three activities are:

1. Component adaptation
2. Assembling components
3. System evolution

- All the above mentioned three activities follow up after the component qualification. 

-The components that are required are defined by the system architecture and requirements. - The characteristics of the component interfaces usually form the basic criteria for their qualification even though the degree of fitness of the component in requirements and architecture is not provided by the interface. 

- Interface here means the services that are provided by the component and the means through which these are accessed by the consumers. 

Component Based Development (CBD)

Component-based development is a CBSE activity that occurs in parallel with domain engineering. Using analysis and architectural design methods discussed earlier, the software team refines an architectural style that is appropriate for the analysis model created for the application to be built. Once the architecture has been established, it must be populated by components that are available from reuse libraries and/or are engineered to meet custom needs.

For those requirements that are addressed with available components, the following software engineering activities must be done:
- Component qualification : It examines reusable components. These are identified by characteristics in their interfaces, i.e. the services provided, and the means by which consumers access these services. This does not always provide the whole picture of whether a component will fit the requirements and the architectural style. This is a process of discovery by the software Engineer. This ensures a candidate component will perform the function required, and whether it is compatible or adaptable to the architectural style of the system. The three important characteristics looked at are performance, reliability and usability.

- Component adaptation : It is required because very rarely will components integrate immediately with the system. Depending on the component type, different strategies are used for adaptation or wrapping. The most common approaches are:
* White box wrapping : The implementation of the component is directly modified in order to resolve any incompatibilities. This is, obviously, only possible if the source code is available for a component, which is extremely unlikely in the case of COTS.
* Grey box wrapping : This relies on the component library providing a component extension language or API that enables conflicts to be removed or masked.
* Black box wrapping : This is the most common case, where access to source code is not available, and the only way the component can be adapted is by pre/post processing at the interface level.
It is the job of the software engineer to determine whether the effort required to wrap a component adequately is justified, or whether it would be “cheaper” to engineer a custom component which removes these conflicts.

- Component composition : The component composition is a task assembles qualified, adapted, and engineered components to populate the architecture established for an application. To accomplish this, an infrastructure must be established to bind the components into an operational system. The infrastructure provides a model for the coordination with one another and performs common tasks. Among the many mechanisms for creating an effective infrastructure is a set of four “architectural ingredients” that should be present to achieve component composition.
* Data exchange model: Mechanism that enables users and applications to interact and transfer data. The data exchange mechanisms not only allow human-to-software and component-to-component data transfer but also transfer among system resources.
* Automation: A variety of tools, macros, and scripts should be implemented to facilitate interaction between reusable components.
* Structured storage: Heterogeneous data contained in a “compound document” should be organized and accessed as a single data structure, rather than a collection of separate files.
* Underlying object model: The object model ensures that components developed in different programming languages that reside on different platforms can be interoperable.

- Component update : When systems are implemented with COTS components, update is complicated by the imposition of a third party. The organization that developed the reusable component may be outside the immediate control of the software engineering organization.