Component Based Software Engineering CBSE

Updated on June 26, 2011

Complete Comprehension

Component Based Software Engineering (CBSE) is a solution for all programmers who like to build very functional, efficient and reliable software. It is simple from its terms. It is an approach that entails gathering previously build components; align them to be integrated with each other; customize them to your need and assembling new software.

This process seems very easy, however it requires daunting challenges.

Before we understand the process of CBSE, we have to establish context (environment) in our mind from where we will be able to build this subtle perusal.

Regardless to the entity that you shall engineered, you must answer to following questions:

What is the problem that you have to solve?

What characteristics of entity are you using to solve the problem?

How will you realize the entity (and the solution)?

How will you construct the entity?

What approach will you use to uncover errors that you have made in the design and construction of entity?

How will provide support to entity when users of this entity will request you to do corrections, adaptations, and enhancements on this entity?

What is component?

You may assume that components are only written objects that must be implemented to have software work apparently.

However, it is not true.

Components are defined and stored as specification, design and implementation classes at various levels of abstraction – with each class being an engineered from a description of product of a previous application. Means, all components are used earlier and modified when comes into a library.

There are two big divisions in CBSE used components:

Commercially Off The Shelf (COTS) components

Components that are built from a scratch, because no particular component that must coexist with its other components is founded by the software team.

When we use COTS components in CBSE, we refer to one of those following categories of components:

Qualified Components: These are nontrivial, replaceable and almost independent component. Therefore, it must confer a clear function in context of a fully designed architecture.

Adapted Components: There are several COTS components that may be suitable to fit in your designed architecture. However, they may not completely fit or function properly, until you make few changes in its interface structure to have this component aligned with others. This means, by amending its interface structure, you make these components acceptable to whole system where these components must coordinate with other components and match with whole architectural design.

Component Composition: Same is true with its inner composition. For example: runtime properties for your software. Some components are very suitable, but may not match with your architectural design. This means, you must do alteration in inner codes of this component to have it agreeable with whole system. In result, this component must perform a function and bring result that is expected by your whole architectural design.

Updated Components: It is very simple. When you have updated and more functional version of a particular component is available, you must opt for the new one.

What is element of component model?

All characteristics of component are elements of components, i.e. classes and components (objects), attributes, operations and messages.

Components are values for of components. Like, chair has four legs of 16 inches, brown color and more. These are written in component.

What are operations?

Operations are written instructions for what software must perform. These are written as in component.

What are messages?

Messages that component receives from interface to perform function or give to other component to perform particular functions. Like, A component sends messages to Component B to perform such function and return the value to A component. After receiving, A component may perform its main function that A must have perform as per message received by A component from human or other component interface.

What is specification?

Specification is an encapsulation of all class, component, attributes, operation and messages in one component program. So, this is what component really is.

Data (attributes) are enclosed by its operation that manipulate this data in order to perform particular function received to perform from message. Like, find particular ratio and return the value.

What is inheritance?

Component receives attributes from its class.

However, it is not necessary to receive them all. Software engineer can add few more, reduce few or change few.

What is Domain?

Domain is the all set elements in which component is belong to. Like, brown hair people are in brown hair domain people domain; six cylinder cars are in six cylinder domain.

PROCESS OF CBSE

Process of CBSE is divided into two main parts.

Domain Engineering

Component Based Development

1. Domain Engineering

Domain Engineering deals with fundamental preparation before you go and start building components. Like, it is mentioned, life is just not a piece of cake where you can just enjoy everything ready for you to grab. Instead, you need to work as a team to build a plan first to find and utilize these raw resources; then channel them in coherent and concatenated structure and then reap benefits out of it. Same is true in software development.

Before you even begin to consider your development, you need to get thorough perusal and investigation on general area from which this particular activity is branched out from.

In this way, you will have a complete cognizance before you begin to assemble your components.

Domain Engineering consists of following activities.

Domain Analysis

Domain Model

Software Architecture Development

Structure Model

Reusable Component Development

Repository Reusable Artifacts/Components

At end, this process must enable you to procure and preserve reusable components that are need for your CBSE. If you will consider to build similar kind of software in future, this process can be preserved for later use as well.

It is a complete process that will enable you to identify, construct, catalog and disseminate a set of software components. These components can also have applicability for future software also.

Therefore, it is a complete field of computer science studies and require separate specialization as well. However, if you just want to study and dedicate time enough to build your present software and future software, you may take it as intermediate level.

As peripherally, domain engineering has three kinds of activities:

Analysis

Construction

Dissemination

Understanding the Domain Analysis:

As we have already established that domain engineering is applicable to any software engineering paradigm, we must also state here that it is applicable to conventional software engineering and object oriented software engineering process as well.

Domain language will enable you to write specification and later construction of applications with a particular domain, which you have decided to analyze.

Steps that you must take in Domain Analysis are as follow:

You must define domain that must be investigated.

Categorize items extracted from the domain.

Select specific functions or objects.

Abstract functions or objects.

Define a taxonomy.

Identify common features

Identify specific relationships.

Abstract these relationships.

Derive a functional model

Derive a domain language.

Collect a representative sample of applications in the domain. Analyze each application in the sample. Develop an analysis models for objects.

Investigating Reusable Components:

As we mentioned, domain analysis will able to you write specification and construction of application in a particular domain. However, it will play not a practical part in your excavation for reusable components.

To identify that your component is fit for your needs, crafting following question and then answering them is recommended:

Is component functionally required on future implementations?

How common is the component’s function within the domain?

Is there a duplication of the component’s function within the domain?

Is the component hardware dependent?

Does the hardware remained unchanged between implementations?

Can the hardware specifics be removed to another component?

Is the design optimized enough for the next implementation?

Can we parameterize a non reusable component, so that it becomes component?

Is the component reusable in many implementations with only minor changes?

Is reuse through modification is feasible?

Can a reusable component be decomposed to yield reusable components?

How valid is decomposition of components for reuse?

Characteristics of Components

Reusable component must be applicable in a particular software development. This means, it must meet basic characteristics that are common in whole software. It is not all the time that it must be precise. However, some characteristics are essential to be the same.

Below list provides number of characteristics that needs to be considered in CBSE

Product

Requirements ability

Concurrent software

Memory constraints

Application size

User interface complexities

Programming language(s)

Safety/Reliability

Lifetime requirements

Product quality

Product reliability

Process

Process model

Process conformance

Project environment

Schedule constraints

Budget constraints

Productivity

Personal (related to software developer's ability)

Motivation

Education

Experience/Training

application domain

process

platform

language

Development team productivity

Structure Modeling and Structure Points

The structural model is an architectural style that can and shall be reused across application with the domain.

Structural modeling is a pattern-based domain engineering approach that works under the assumption that every application domain has repeating pattern (of function, data and behavior) that have reuse potential.

Structure point is a “distinct construct within a structural model.”

Structure point has three basic characteristics:

Structure point is an abstraction that should have a limited number of instances. In addition, the structure must resort within domain throughout the application.

The rules that govern the structure point must be easily understood. In addition, the interface to the structure point must be relatively simple.

The structure point shall implement information hiding by isolating all complexity contained within structure point itself. This reduces the perceived complexity of the overall system.

2. COMPONENT BASED DEVELOPMENT

Once, you have established the architecture, you must populate this by components that are:

A. are available from reuse libraries and/or

B. are engineered to meet custom needs.

Before integrating these components into a well established structure, you must qualify and adapt them first. This means, when you acquire them, you must engineer them. Once, engineered, theses components are “composed” integrated into an architecture template and tested thoroughly.

Component Qualification, Adaptation, and composition

Eventually, you will build a library of reusable components before you start consider to integrate them into a well defined structure. Some of these reusable components are manufactured in house, other can be extracted from existing application, and still may be acquired from third parties.

However, the existence of reusable components does not guarantee that these components can be integrated easily or effectively into the architecture chosen for new application. It is for this reason that a sequence of component-based development activities are applied when a component is proposed for use.

Component Qualification

First you go for qualification to see that do you really have to do some modification to a candidate component or not. Therefore, component qualification ensures that a candidate component will perform the function required; will properly fit into a designed architecture style that is specified for the system; and, will exhibit the quality characteristics (e.g.; performance, reliability and usability) that are required for the application.

This means, merely interface description is not enough. Albeit, interface description does provide useful information about the operation and use of a software component.

To ensure that a candidate component can be integrated efficiently into a new application, following factors must be considered:

Embedded design assumptions, including the use of specific numerical or non-numerical algorithms.

Exception handling.

Answer to these implied questions are easy to find if good engineering practices are applied during the development. However, must keep in mind that you may lack specifications on COTS or third party components.

Component Adaptation

Here now we have to compare ideal situation with real situation. As we know that real situation is not always the ideal.

Ideal Situation

Library of components that are easily integrated into application architecture. The implication of “easily integration” is that

consistent methods of resource management are implemented for all components in the library.

common activities such as data management exist for all components, and

interfaces within the architecture and with the external environment have been implemented in a consistent manner.

Real Situation

A component may exhibit one of conflicts with three situations that are aforementioned, even though it qualifies initially.

To mitigate these conflicts, an adaptation technique called component wrapping is often used. This technique is further three styles to use.

White Box Wrapping

It is applied when software team has full access to the internal design and code for the component (often not the case when COTS components are used). White box wrapping examines the internal processing details of the component and makes code level modifications to remove any conflict.

Gray Box Wrapping

Gray Box Wrapping uses component extension language or API that enables the conflicts to be removed or masked. However, your build component library must contain component extension language or API to have you use Gray Box Wrapping.

Black Box Wrapping

It requires the introduction to pre- and post processing at the component interface. Black Box Wrapping uses pre- and post processing at interface to remove or mask conflicts. However, the software team must determine whether the effort required to adequately wrap is justified or whether software engineering team shall engineer a custom component (designed to eliminate the conflicts encountered) instead.

Component Composition

The component composition task consists of assimilation of qualified, adapted and engineered components. You do this by populating the designed architecture, which you have established for an application.

To accomplish this you must establish infrastructure to bind the components into an operational system. The infrastructure (usually a library of specialized components) provides a model for the coordination of components and specific services that enable components to coordinate with one another and perform common tasks.

Four Main Architectural Ingredients

Among many mechanisms of effective infrastructure, following “Four main architectural ingredients” are essential:

Data Exchange Model

Mechanisms that enable users and applications to interact and transfer data (e.g., drag and drop, cut and paste) must be defined for reusable components. The data exchange mechanisms not only allow human-to-software and component-to-component data transfer but also transfer among system resources (e.g.; dragging a file to a printer icon for output).

Automation

You must implement variety of tools, macros, and scripts to facilitate interaction between reusable components.

Structured Storage

You must organize heterogeneous data (e.g., graphical data, voice/video text, and numerical data) contained in a “component document.” Also, you must be able to access this heterogeneous data as a single data structure, rather than separate files. “Structured data maintains a descriptive index of nesting structures that applications can freely navigate to locate, create, or edit individual data contents as directed by the end user.”

Underlying Object Model

To achieve this, you must create an object model that defines a standard for component interoperability.

The object model ensures that components developed in different programming languages and resided at different platforms can be interoperable. This means, objects must be capable of communicating across the network. To achieve this, the object model defines the standard for component interoperability.

Standards for Component Interoperability

Number of major companies and industry consortia have proposed standards for component software:

OMG/COBRA

The object management group has published a common object request broker architecture (OMG/COBRA). An object request broker (ORB) provides a variety on services that enable reusable components (objects) to communicate with other components, regardless of their location with a system. When components are build using the OMG/COBRA standard, integration of those components (without modification) within a system is assured if an interface definition language (IDL) interface is created for every component. Using a client/server metaphor, objects within the client application request one or more services from the ORB server. Requests are made via an IDL or dynamically at a run time. An interface repository contains all necessary information about the service’s request and response format.

Microsoft Com

Microsoft has developed a component object model (COM) that provides a specification for using components produced by various vendors within a single application within a single application running under the Windows operating system.

COM encompasses two elements: COM interfaces (implemented as COM objects) and a set of mechanisms for registering and passing messages between COM interfaces. From the point of view of the application, “the focus is not on how [COM objects are] implemented, only on fact that the object has an interface that it registers with the system, and that it uses the component system to communicate with other COM objects.”

Sun JavaBeans Components

The JavaBeans component system is a portable, platform independent CBSE infrastructure developed using the java programming language. The JavaBean system extends the Java applet to accommodate the more sophisticated software components required for the component based development. The JavaBean component system encompasses set of tools, called the Bean Development Kit (BDK), that allows developers to:

analyze how existing beans (components) work,

customize their behavior and appearance.

establish mechanisms for coordination and communication.

develop custom Beans for use in a specific application, and

test and evaluate Beans behavior.

Component Engineering

As mentioned above, there some times when acquired components are not enough complete the whole architecture. You may not find few components that must be required in your software. Therefore, you need to develop new components.

Since, your newly developed components must be members of in-house library, they must be developed for as reusable also.

Reusable components can have concept of abstraction, have hidden from other objects, have functional independence, sometimes refined, sometimes restructured, must have object oriented method, have software quality assurance (SQA), tested and have correctness verifications.

Analysis and Design of Reuse

Once, you have created a complete library for reuse, you must analyze and design models in which these components must work. It is not a linear process, instead a recursive one. You may have not complete components in your library. After this analysis, you may be able to find that you need more components.

In this analysis, you will create data, functional and behavioral models to describe that what a particular application must accomplish. To describe these models in written form, you must have to have specifications of them. To cover this coherent work of these models and specification, you will have to have complete requirements for whole software.

As it is described above, components are defined and stored as specification, design and implementation classes at various levels of abstraction – with each class being an engineered from a description of product of a previous application. Means, all components are used earlier and modified when comes into a library.

The specification knowledge –development knowledge- is stored in the form of reuse-suggestion classes, which contains directions for retrieving reusable components on the basis of their description and for composing and tailoring them after their retrieval.

Ideally, when analyzing , you must be able to find elements that point to reusable components. As we mentioned earlier, it is not a piece of a cake all the time. This means, you may not find any of above mentioned components in ready to use format or easy to find location. The one of focus required problems is when you are looking for a “specification matching.”

To resolve this problem, you use automated tools to browse a repository in an attempt to match the requirement noted in the current specification with those described for existing reusable components (classes). --- means, you find components with automated tools for particular specification.

Once, you use automated tools, there are two possibilities. One, specification matching may yield you a component or components. If this is the case, you can extract these components from reuse library and use them in your designed system. Two, if designed components are not found, you have to engineer them by using convention or Object Oriented method.

Design for Reuse

If there is a case when you have to engineer a new component, you must have solid foundation on software design concepts and principles. Also, you must have cognizance over domain characteristics as well.

There are following three fundamental efforts that must be done at first:

Standard data: you must investigate application domain and must identify standard global structures (e.g.; file structures or complete data base). You must characterized designed components as well, so you can use these standard data structures.

Standard Interface Protocol: you must establish three levels of protocols. 1) the nature intramodular interfaces 2) the design of external technical (nonhuman) interfaces, and the human/machine interface.

Program Templates: The structure model can serve as a template for architectural design of a new program.

Once, you will establish standard data, interfaces and program templates, you will have a frame work in which you can create the design. New components that confirm to this framework have a higher probability for subsequent reuse.