Component-Based Software Engineering (CBSE) or Component-Based Development (CBD) -

Component-Based Software Engineering (CBSE) also known as Component-Based Development (CBD) is a branch of software engineering that emphasizes separation of concerns (SoC) in the wide range functionality available through a given software system. It is a reuse-based approach to defining, implementing, and composing loosely coupled components in systems. This practice also aims to bring a broad degree of benefits in both the short and long term, for the software itself, and for the organizations that sponsor such software.

Software engineers consider the components as part of the initial platform for service orientation. Components play this role, for example, in web services, and more recently, in service-oriented architectures (SOA), whereby a component is converted by the web service into a service and subsequently inherits other features beyond those of an ordinary component.

Components can produce or consume events and can be used for event-driven architectures (EDA).

Component Definition and Characteristics

An individual software component is a software package, a web service, or a module that encapsulates a set of related (or data) functions.

All system processes are placed in separate components in such a way that all data and functions within each component are semantically related (just as with class contention). Because of this principle, the components are often said to be modular and cohesive.

With respect to coordination throughout the system, the components communicate with each other via interfaces. When a component provides services to the rest of the system, it adopts a provided interface that specifies the services that other components can use, and how they can do so. This interface can be seen as a component signature - the client does not need to know about the component's internal operations (its implementation) to make use of it. This principle results in components referred to as encapsulated. The UML illustrations in this article represent the interfaces provided, with a lollipop symbol attached to the outer edge of the component.

However, when a component needs to use another component in order to function, it adopts a used interface that specifies the services it needs. In the UML illustrations in this article, the interfaces used are represented by an open socket symbol attached to the outer edge of the component. 
A simple example of several software components - represented within a hypothetical holiday reservation system represented in UML 2.0.

Another important attribute of the components is that they are replaceable, so one component can substitute for another (at design time or execution time), if the successor component meets the requirements of the initial component (expressed through the interfaces). Therefore, the components can be replaced by an updated version or an alternative without breaking the system in which they operate.

As a general rule of thumb for engineers replacing components, component B can immediately replace component A if component B provides at least component A provides and uses no more than component A uses.

Software components often take the form of objects (non-classes) or collections of objects (object-oriented programming), in a certain binary or textual form, adhering to a certain interface description language (IDL) of so that the component can exist autonomous of other components in a computer.

When a component must be accessed or shared through execution contexts or network links, techniques such as serialization or marshalling are often employed to send the component to its destination.

Reusability is an important feature of a high-quality software component. Programmers must design and deploy software components in a way that various programs can reuse. In addition, when software components interact directly with users, the component-based usability test should be considered.

It takes significant effort and awareness to write a software component that is effectively reusable. The component needs to be:

  • fully documented
  • thoroughly tested
  • rugged - with a comprehensive check for the validity of the entry
  • able to return appropriate error messages or return codes
  • designed with awareness that it will be put into unanticipated uses

In the 1960s, programmers built libraries of scientific subroutines that were reusable in a wide array of engineering and scientific applications. Although these subroutine libraries reused well-defined algorithms effectively, they had limited application domain. Commercial sites routinely created application programs from reusable modules written in assembler, COBOL, PL / 1, and other second- and third-generation languages, using both system and user application libraries.

By 2010, modern reusable components encapsulate data structures and algorithms that are applied to data structures. This is based on previous theories of objects, architectures, frameworks and software design patterns, and the extensive theory of object-oriented programming and object-oriented design of all of these. It asserts that software components, such as the idea of ​​hardware components, used, for example, in telecommunications, can ultimately be made interchangeable and reliable. On the other hand, it is argued that it is a mistake to focus on independent components instead of the framework (without which the component would not exist).

The idea that software should be componentized - constructed of prefabricated components - first became prominent with Douglas McIlroy's speech at the NATO conference on software engineering in Garmisch, Germany, 1968, entitled Mass Produced Software Components (mass-produced software components). The conference was proposed to address the so-called software crisis. McIlroy's subsequent inclusion of pipes and filters in the Unix operating system was the first implementation of an infrastructure for this idea.

Differences with Object Oriented Programming

Those who propose object-oriented programming (OOP) maintain 2 different positions to model the software:

1) that software must be written according to a mental model of the real or imaginary objects they represent. OOP and related disciplines of object-oriented analysis and object-oriented design are focused on modeling real-world interactions and attempt to identify "nouns" and "verbs" in requirements-gathering meetings for those concepts are programmed directly into classes and methods, which can be used in more humanly readable forms, ideally by end users as well as programmers coding for those end users. This way of thinking about the OOP is rather an illusion, historically has not given good results.

2) that a requirements survey must first be carried out with the stakeholders (customers, end users, etc.) and then the system should be modeled in business use cases that are then divided into user use cases, which are directly implementable in 3 layers: visual presentation objects, service objects and persistence objects, there may be more layers depending on the needs of the application.

By contrast, component-based software engineering makes no such assumption, and instead expresses that developers must build the software by sticking together prefabricated components - such as in the fields of electronics or mechanics. Some even talk about modularized systems as software components as a new programming paradigm.

Some argue that early computer scientists made this distinction, with Donald Knuth's theory of literary programming assuming optimistically that there was a convergence between intuitive and formal models, and Edsger Dijkstra's theory in The Cruelty of Really Teaching Computer Science (the cruelty of actually teaching computer science), which indicated that programming was simply, and only, a branch of mathematics.

In both ways, this notion has led to many scholarly debates [weasel words] about the pros and cons of the two approaches and possible strategies for bringing the two together. Some consider the various strategies not as competitors, but as descriptions of the same problem from different points of view.


A computer running several software components is often called an application server. Using this combination of application servers and software components is usually called distributed computing. The usual real-world application of this is for example the application or business software.


A component model is a definition of standards for implementation, documentation, and component deployment. Examples of component models are: the Enterprise Java Beans (EJB) model, the COM + model (.NET model), the Corba component model. The component model specifies how the interfaces and elements to be included in an interface definition should be defined.

Business Object Technologies

Component-based frameworks for specific domains
Earth System Modeling Framework (ESMF)
Component Oriented Programming
Packages defined by the OSGi service platform
Common Component Architecture (CCA) - Common Components Architecture Forum, Scientific Component Software / HPC
TASCS - SciDAC Center for Technology for Advanced Scientific Software Software (Center for Technology for the Advancement of Scientific Software of Components)
Eiffel programming language
Enterprise JavaBeans from Sun Microsystems (now Oracle)
Flow-based programming
Fractal component model of ObjectWeb
Midgard and PHP MidCOM components framework
Oberon, Component Pascal, and BlackBox Component Builder
rCOS Component-based model management design method designed from UNU-IIST
ObjectWeb SOFA component system
The System.ComponentModel Namespace in the Microsoft .NET
Unity3D developed by Unity Technologies
ONE of the office suite
Borland Visual Component Library (VCL) and Component Library for Cross Platform (CLX) and the similar free Lazarus LCL library.
Microsoft Visual Basic Extension, OCX / ActiveX / COM, and DCOM
XPCOM from Mozilla Foundation
Composite document technologies
Active Documents in Oberon System and BlackBox Component Builder
Bonobo (component model), a part of GNOME
KPart, KDE composite document technology
Object linking and embedding (OLE)
Distributed Computing Software Components
.NET Remoting from Microsoft
9P Distributed protocol developed by Plan 9, and used by Inferno and other systems.
CORBA and the CORBA Component Model of the Object Management Group
D-Bus of the organization
KDE DCOP (obsolete)
DCOM and later versions of COM (and COM +) from Microsoft
DSOM and IBM's IBM System Object Model (now decommissioned)
ICE from ZeroC
Sun Java EE
Universal Network Objects (UNO) from
Web services
Representational State Transfer
Zope by Zope Corporation
Genetic programming emphasizes separation of algorithms from data representation
Interface description languages ​​(IDLs)
Open Service Interface Definitions (OSIDs)
Some parts of COM and CORBA
Platform-Independent Component Modeling Language
SIDL - Scientific Interface Definition Language
Some parts of the language of Babel. Scientific programming language interoperability system (SIDL and Babel are CCA core technology and SciDAC TASCS Center - see above.)
SOAP IDL from the World Wide Web Consortium (W3C)
XML-RPC, the predecessor of SOAP
Inversion of Control (IoC) and Plain Old C ++ / Java Object framework components (POCO / POJO)
Pipes and filters
Unix operating system