What ingredients are necessary to achieve component composition?

Component based software development or CBSD is nowadays becoming a very common practice when it comes to re- using the already existing practice components that have already been validated. This practice has shortened the development cycle gradually and has enhanced the quality of the software products or artifacts. This approach of software development is focussed up on the development of new software systems and applications through the selection and assembling components that belonged to the pre- existing software components. 

Furthermore, CBSD development methodology helps to:

1. Accelerates the productivity of the software development
2. Reduces the overall development cost
3. Reduces maintenance efforts
4. Enhances flexibility
5. Enhances maintainability
6. Assembles system rapidly
7. Reduces the time to market

Usually no wear and tear occurs to the software system but there is a need to change or modify the software in accordance with the changes in business needs and complexity. Since the system keeps on acquiring more and more complexity, and hence more and more errors are introduced. 

This whole concept of component based software development is based up on components and the success of this development approach is highly affected by the composition of the software components that are being used.

What is a Component?

- A component as we know can be defined as a re- usable unit of deployment which has its access through a graphical user interface. 

- Component can be thought of as an independent entity that possesses its own complete functionality that can be distributed separately and shows no problem in upgrading from time to time. 

- Certain standards have been defined according to which the components are developed and are re- used. 

- Smaller pieces of software are aggregated at a high level and this aggregation is what that forms a component.  

Types of ingredients in Component Based Software Development

1. An ideal component consists of the implementation detail obtained from the environment that can be re used by the interfaces of those components. This is essential as re- usability of the components is very much important for the component based software development.
2. The second most important ingredient is the service or functionality that is to be provided by the component.
3. Quality aspects like predictability, component reliability, usability and so on.
4. The composition of the components requires meta information regarding the interfaces of the components and properties so as to support the tools during the process of the component composition. This meta information is obtained from the implementation/ interface repositories, type libraries or introspection or dedicated info classes etc.

Different Means of Component Composition

- Though the implementation inheritance works for most of the object oriented frame works, it does not prove useful for the component composition.

- The composition of the components takes place on a binary level. 

- There are 4 means of component composition:

1. Scripting or glue languages
2. Component frame works
3. System languages
4. Visual programming

All the above mentioned means have their own advantages and disadvantages but, they all are considered to be useful when used in combination. 

- Mostly scripting languages like tcl, visual basic etc are used for component composition rather than using system languages like java, Pascal, C++ etc. 

- The scripting languages are found convenient for this purpose because they are intended for plugging components together operating on a high abstraction level as compared to the system languages. 

- The component composition requires an equivalent object oriented frame work called component frame work and in this the glue code between the classes is predefined for a specific application domain. 

The COCOMO II (Constructive Cost Estimation Model) Model

COCOMO II is an extension to the COCOMO model. COCOMO II takes into account new development processes, increased flexibility in software development, need for decision making with incomplete information and new data about projects.

COCOMO II is really three different models :
- The Application Composition Model used for prototyping.
- The Early Design Model used when requirements are available but design has not yet started.
- The Post-Architecture Model used once the system architecture has been designed.

COCOMO II models require sizing information. Three different sizing options are available as part of the model hierarchy i.e. object points, function points, and lines of source codes.
The application composition model uses object points which is an indirect software measure that is computed using counts of the number of screens, reports and components likely to be required to build the application.

DIFFERENCES BETWEEN COCOMO I AND COCOMO II

- COCOMO I requires software size in KDSI as an input, but COCOMO II is based on KSLOC.
- COCOMO I provides point estimates of effort and schedule, but COCOMO II provides likely ranges of estimates.
- In COCOMO II, the estimation equation exponent is determined by five scale factors instead of three.
- Data points in COCOMO I: 63 and COCOMO II: 161.
- COCOMO II adjusts for software reuse and re-engineering but COCOMO I made little accommodation for these factors.

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.