Software component

Components allow software developers to assemble software with reliable parts rather than writing code for every aspect. It makes implementation more like factory assembly than custom building.

Desirable attributes of a component include but are not limited to:

• Cohesive , encapsulates related functionality

• Reusable

• Robust

• Substitutable , can be replaced by another component with the same interface

• Documented

• Tested

Some components are built in-house by the same organization or team building the software system. Some are third-party, developed elsewhere and assembled into the software system.

For large-scale systems, component-based development encourages a disciplined process to manage complexity.

Some components conform to a framework technology that allows them to be consumed in a well-known way. Examples include: CORBA, COM, Enterprise JavaBeans, and the .NET Framework.

Component design is often modeled visually. In Unified Modeling Language (UML) 2.0 a component is shown as a rectangle, and an interface is shown as a lollipop to indicate a provided interface and as a socket to indicate consumption of an interface.

The idea of reusable software components was promoted by Douglas McIlroy in his presentation at the NATO Software Engineering Conference of 1968. (One goal of that conference was to resolve the so-called software crisis of the time.) In the 1970s, McIlroy put this idea into practice with the addition of the pipeline feature to the Unix operating system.

Brad Cox refined the concept of a software component in the 1980s. He attempted to create an infrastructure and market for reusable third-party components by inventing the Objective-C programming language.

IBM introduced System Object Model (SOM) in the early 1990s.

Microsoft introduced Component Object Model (COM) in the early 1990s. Microsoft built many domain-specific component technologies on COM, including Distributed Component Object Model (DCOM), Object Linking and Embedding (OLE), and ActiveX.