Component-based software engineering (CBSE), also called component-based development (CBD), is a style of software engineering that aims to build software out of loosely-coupled, modular components. It emphasizes the separation of concerns among different parts of a software system.
An individual software component is a software package, a web service, a web resource, or a module that encapsulates a set of related functions or data.
Components communicate with each other via interfaces. Each component provides an interface (called a provided interface) through which other components can use it. When a component uses another component's interface, that interface is called a used interface.
In the UML illustrations in this article, provided interfaces are represented by lollipop-symbols, while used interfaces are represented by open socket symbols.
Components must be substitutable, meaning that a component must be replaceable by another one having the same interfaces without breaking the rest of the system.
Components should be reusable.
Component-based usability testing should be considered when software components directly interact with users.
Components should be:
The idea that software should be componentized - built from prefabricated components - first became prominent with Douglas McIlroy's address at the NATO conference on software engineering in Garmisch, Germany, 1968, titled Mass Produced Software Components.[1] The conference set out to counter the so-called software crisis. McIlroy's subsequent inclusion of pipes and filters into the Unix operating system was the first implementation of an infrastructure for this idea.
Brad Cox of Stepstone largely defined the modern concept of a software component.[2] He called them Software ICs and set out to create an infrastructure and market for these components by inventing the Objective-C programming language. (He summarizes this view in his book Object-Oriented Programming - An Evolutionary Approach 1986.)
The software components are used in two different contexts and two kinds: i) using components as parts to build a single executable, or ii) each executable is treated as a component in a distributed environment, where components collaborate with each other using internet or intranet communication protocols for IPC (Inter Process Communications). The above belongs to the former kind, while the below belongs to the latter kind.
IBM led the path with their System Object Model (SOM) in the early 1990s. As a reaction, Microsoft paved the way for actual deployment of component software with Object linking and embedding (OLE) and Component Object Model (COM).[3] As of 2010[update] many successful software component models exist.
A computer running several software components is often called an application server. This combination of application servers and software components is usually called distributed computing. Typical real-world application of this is in, e.g., financial applications or business software.
A component model is a specification of components' properties.[4]
A classification of the existing component models is given in [4] and.[5] Examples of component models are: Enterprise JavaBeans (EJB) model, Component Object Model (COM) model, .NET model, X-MAN component model,[6] and Common Object Request Broker Architecture (CORBA) component model.
System.ComponentModel
namespace in Microsoft .NET