Component-based software engineering

An example of two components expressed in UML 2.0. The checkout component, responsible for facilitating the customer's order, requires the card processing component to charge the customer's credit/debit card (functionality that the latter provides).

Component-based software engineering (CBSE), also known as component-based development (CBD), is a branch of software engineering that emphasizes the separation of concerns in respect of the wide-ranging functionality available throughout a given software system. It is a reuse-based approach to defining, implementing and composing loosely coupled independent components into systems. This practice aims to bring about an equally wide-ranging degree of benefits in both the short-term and the long-term for the software itself and for organizations that sponsor such software.

Software engineering practitioners regard components as part of the starting 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 further characteristics beyond that of an ordinary component.

All system processes are placed into separate components so that all of the data and functions inside each component are semantically related (just as with the contents of classes). Because of this principle, it is often said that components are modular and cohesive.

With regard to system-wide co-ordination, components communicate with each other via interfaces. When a component offers services to the rest of the system, it adopts a provided interface that specifies the services that other components can utilize, and how they can do so. This interface can be seen as a signature of the component - the client does not need to know about the inner workings of the component (implementation) in order to make use of it. This principle results in components referred to as encapsulated. The UML illustrations within this article represent provided interfaces by 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 that it needs. In the UML illustrations in this article, used interfaces are represented by an open socket symbol attached to the outer edge of the component.

A simple example of several software components - pictured within a hypothetical holiday-reservation system represented in UML 2.0.

Another important attribute of components is that they are substitutable, so that a component can replace another (at design time or run-time), if the successor component meets the requirements of the initial component (expressed via the interfaces). Consequently, components can be replaced with either an updated version or an alternative without breaking the system in which the component operates.

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

Software components often take the form of objects (not classes) or collections of objects (from object-oriented programming), in some binary or textual form, adhering to some interface description language (IDL) so that the component may exist autonomously from other components in a computer. In other words, a component acts without changing its source code. Although, the behavior of the component's source code may change based on the application's extensibility, provided by its writer.

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

Reusability is an important characteristic of a high-quality software component. Programmers should design and implement software components in such a way that many different programs can reuse them. Furthermore, component-based usability testing should be considered when software components directly interact with users.

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

In the 1960s, programmers built scientific subroutine libraries that were reusable in a broad array of engineering and scientific applications. Though these subroutine libraries reused well-defined algorithms in an effective manner, they had a limited domain of application. 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.

Brad Cox of Stepstone largely defined the modern concept of a software component.[4] 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 former kind, while the below belongs to later kind.

Proponents of object-oriented programming (OOP) maintain that software should be written according to a mental model of the actual or imagined objects it represents. OOP and the related disciplines of object-oriented analysis and object-oriented design focus on modeling real-world[citation needed] interactions and attempting to create "nouns" and "verbs" that can be used in more human-readable ways, ideally by end users as well as by programmers coding for those end users.

Component-based software engineering, by contrast, makes no such assumptions, and instead states that developers should construct software by gluing together prefabricated components - much like in the fields of electronics or mechanics. Some peers[who?] will even talk of modularizing systems as software components as a new programming paradigm. Example for possible paradigm: many experts feel adaptable to evolving needs is more important than reuse, since 80% of software engineering deals with maintaining or releasing new versions. So it is desirable to build complex system by assembling highly cohesive loosely coupled large components, where cost of redesigning each of such adoptable components (or replacing by a better component) must be minimized.

In both forms, this notion has led to many academic debates[weasel words] about the pros and cons of the two approaches and possible strategies for uniting the two. Some[who?] consider the different strategies not as competitors, but as descriptions of the same problem from different points of view.[citation needed]

One approach to creating component-based software using object-oriented programming is interface-based programming. However, interface-based programming does not inherently support distributed systems, and many computer systems are inherently distributed in the 21st century. Interface-based programming in the OOP sense may be extended to distributed systems with distributed component object models; however, many have argued in recent years that REST APIs or the actor model are more suitable approaches.

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.

^"Dijkstra, Wybe Edsger". Encyclopedia.com. Retrieved 2011-07-29. In his view, the key to a good computing science program was to consider it as a branch of mathematics.

^Donald E. Knuth (September 1983). "Literate Programming"(PDF). Literate Programming/The Computer Journal. p. 15. Retrieved 2011-07-29. Thus, WEB may be only for the subset of computer scientists who like to write and to explain what they are doing. My hope is that the ability to make explanations more natural will cause more programmers to discover the joys of literate programming, because I believe it’s quite a pleasure to combine verbal and mathematical skills; but perhaps I’m hoping for too much. The fact that at least one paper has been written that is a syntactically correct ALGOL 68 program22 encourages me to persevere in my hopes for the future. Perhaps we will even one day find Pulitzer prizes awarded to computer programs.

^MASH defines assets as people, property and information and management as monitoring, control and configuration. Presented at the 2013 IEEE IoT conference in Mountain View MASH includes a full IDE, Android client and runtime. "MASH YouTube channel"

^A component-oriented approach is an ideal way to handle the diversity of software in consumer electronics. The Koala model, used for embedded software in TV sets, allows late binding of reusable components with no additional overhead. [1]

^Component model for embedded devices like TV developed by Philips based on paper by van Ommering, R.: Koala, a Component Model for Consumer Electronics Product Software [2]