What is a CBSE process? What are the steps in CBSE?

The component based software engineering or CBSE process is nowadays gaining a new high in the field of software engineering. But still many of us are not aware of this development process. 

This article focuses up on the component based software engineering process as well as the steps involved in it. More commonly the component based software engineering process is known as “CBD” or component based development. 

About Component Based Software Engineering (CBSE) Process

- The CBSE process is treated as an individual branch of the software engineering that primarily emphasis up on the separation of concerns with respect to the wide ranging functionality that are present throughout a software system or application.

- This approach to software development can be thought of as a reuse based approach and is used for defining, implementing and composing the independent components that are loosely coupled in to the given software system or application. 

- With such a practice, an equally wide ranging degree of benefits is brought about in the software system both for the short term and the long term and also for the organizations that are involved with the production of that software system or application. 

- The components of the software system are considered to be a part of the platform where the development process begins by many of the software engineers. 

- The components are often converted in to services and are granted further characteristics that make it different from an ordinary component. 

- For example, this happens in SOA or service oriented architectures. 

- In other cases, the components are used to consume or produce events that cab be later used for EDA or events driven architecture. 

- An individual software component can be considered to be one of the following things:

1. Software package
2. Web service
3. Module encapsulating a set of related functions.

Principle behind CBSE Process

- All the processes of the software system or application are placed in to separate components so that the data remains safe and intact and separated from other dissimilar kinds of data. 

- There is a semantic relation between the data and the functions placed inside the components.

- It is this principle that grants the components the property of modular cohesiveness. 

- The co- ordination among components is facilitated via the interfaces of the components or modules.

- Whenever it is the turn of a software system or component to offer a service to the whole of the other system or application, it makes use of the provided interface specifying the service that can be utilized by the other components and how it is to be utilized is also instructed by that interface only. 

- This interface can be called as the signature of that particular component to which it belongs.

- One of the best things about the CBSE process is that the client need not have the knowledge about the inner working of the components in order to make use of it.

Steps involved in CBSE process

1. The first step is all about the creation of an interface specification using an IDL (interface definition language).

2. The second step deals with the creation of a component specification which consists of member functions and interfaces.

3. At this step the complete control of the development process is in the hands of the developers and the traceability metrics are based up on the CBSE principles.

4. Unit testing of the components using a test harness for making the entire process automated.

5. Component integration testing

With the CBSE process, the developers can make changes to a specific component easily as long as they adhere to their interfaces. 

Domain Engineering in CBSE process

The CBSE process encompasses two concurrent sub-processes - domain engineering and component based development.
The intent of domain engineering is to identify, construct, catalog, and disseminate a set of software components that have applicability to existing and future software in a particular application domain. The overall goal is to establish mechanisms that enable software engineers to share these components—to reuse them.

The overall approach to domain analysis is often characterized within the context of object-oriented software engineering. The steps in the process are defined as follows:
- Define the domain to be investigated.
- Categorize the items extracted from the domain.
- Collect a representative sample of applications in the domain.
- Analyze each application in the sample and define analysis classes.
- Develop an analysis model for the classes.

Some of the domain characteristics are as follows :
- It is sometimes difficult to determine whether a potentially reusable component is applicable in a particular situation. A set of domain characteristics may be defined to make this determination.
- A domain characteristic is shared by all software within a domain. It defines generic attribute of all products that exist within the domain. E.g., generic characteristics might include: the importance of safety/reliability, programming language, concurrency in processing.

Examples of application domains are:
* Air traffic control systems
* Defense systems
* Financial market systems

Domain engineering begins by identifying the domain to be analyzed. This is achieved by examining existing applications and by consulting experts of the type of application you are aiming to develop. A domain model is then realized by identifying operations and relationships that recur across the domain and therefore being candidates for reuse. This model guides the software engineer to identify and categorize components, which will be subsequently implemented.

One particular approach to domain engineering is Structural Modelling. This is a pattern-based approach that works under the assumption that every application domain has repeating patterns. These patters may be in function, data, or behaviour that have reuse potential.

Software Components

Components are the software units that are context independent, both in the conceptual and the technical domain. A component contain a self-contained entity that exports functionality to its environment and also imports functionality from its environment using well defined and open interfaces. Components may support their integration into the surrounding by providing mechanics such as configuration functionality.

Software components can also be characterized based on their use in the CBSE process. In addition to COTS components, the CBSE process yields :
- Qualified components: Assessed by software engineers to ensure that not only functionality, but also performance, reliability, usability, and other quality factors conform to the requirements of the system/product to be built.
- Adapted components: Adapted to modify (wrapping) unwanted or undesired characteristics.
- Assembled components: integrated into an architectural style and interconnected with an appropriate component infrastructure that allows the components to be coordinated and managed effectively.
- Updated components: replacing existing software as new versions of components become available.

Software Component :
A software component simply cannot be differentiated from other software elements by the programming language used to implement the component. The difference lies in how software components are used.

Component model :
A component model defines specific interaction and composition standards. A component model implementation is the dedicated set of executable software elements required to support the execution of components that conform to the model. The standards have to contain a set of elements or services which are shown in the following alignment :
- Interfaces: Specification of component behavior and properties; definition of Interface Description Languages (IDL).
- Naming: Global unique names for interfaces and components.
- Meta data: Information about components, interfaces, and their relationships; APIs to services providing such information.
- Interoperability: Communication and data exchange among components from different vendors, implemented in different languages.
- Customization: Interfaces for customizing components.
- Composition: Interfaces and rules for combining components to create larger structures and for substituting and adding components to existing structures.
- Evolution Support: Rules and services for replacing components or interfaces with newer versions.
- Packing and Deployment: Packing implementation and resources needed for installing and configuring a component.

Reuse of Components :
The main purpose of software components is software reuse. The main types of software reuse are white-box reuse and black-box reuse. White-box reuse means that the source of a software component is fully available. Black-box reuse is based on the principle of information hiding. Software components are reused in general through black-box reuse. Components hide the inner working as much as possible.

Component Based Software Engineering (CBSE)

Component based software engineering (CBSE) offers inherent benefits in software quality, developer productivity, and overall system cost. And yet, many roadblocks remain to be overcome before the CBSE process model is widely used throughout the industry. The benefits of object-oriented design and component-based development seem obvious:
- Reusing software saves money in the development phase of software projects, i.e., the more components you reuse, the less software you have to build.
- The more applications in which you use a given component, the more valuable that component becomes.
- Reusable components enable application developers to customize applications without high costs and long development cycles.
- Reused software components have fewer bugs because they are used more often, and errors are uncovered and corrected along the way.

Why CBSE?
The goal of component-based software engineering is to increase the productivity, quality, and time-to-market in software development thanks to the deployment of both standard components and production automation. One important paradigm shift implied here is to build software systems from standard components rather than "reinventing the wheel" each time. This requires thinking in terms of system families rather than single systems. CBSE uses Software Engineering principles to apply the same idea as OOPs to the whole process of designing and constructing software systems. It focuses on reusing and adapting existing components, as opposed to just coding in a particular style. CBSE encourages the composition of software systems, as opposed to programming them.
CBSE should, in theory, allow software systems to be more easily assembled, and less costly to build. Although this cannot be guaranteed, the limited experience of adopting this strategy has shown it to be true. The software systems built using CBSE are not only simpler to bold and cheaper – but usually turn out to be more robust, adaptable and updateable.
CBSE allows use of predictable architectural patterns and standard software architecture leading to a higher quality end result.

The CBSE Process :
CBSE is in many ways similar to conventional or object-oriented software engineering. A software team establishes requirements for the system to be built using conventional requirements elicitation techniques. An architectural design is established. Here though, the process differs. Rather than a more detailed design task, the team now examines the requirements to determine what subset is directly amenable to composition, rather than construction. For each requirement, the team will ask:
- Are commercial off-the-shelf (COTS) components available to implement the requirement?
- Are internally developed reusable components available to implement the requirement?
- Are the interfaces for available components compatible within the architecture of the system to be built?
The team will attempt to modify or remove those system requirements that cannot be implemented with COTS or in-house components. The CBSE process identifies not only candidate components but also qualifies each components’ interface, adapts components to remove architectural mismatches, assembles components into selected architectural style, and updates components as requirements for the system change.
There are two processes that occur in parallel during the CBSE process. These are:
* Domain Engineering
* Component Based Development