1.3 Defining a software component

Software components are notoriously hard to define (Olsen 2006). Many concepts have been graced with the “component” designation over the years, and far from all are compatible with the view taken in this thesis. By contrast, the object concept is comparatively well-defined—objects encapsulate state and behavior.¹ There is sufficient consensus on this definition that it is enshrined in a general-purpose dictionary (Merriam-Webster 2009a):

[An object is] a data structure in object-oriented programming that can contain functions as well as data, variables, and other data structures.

The same dictionary has only a generic definition of the word “component”—a component is simply “a constituent part,” that is, something that is part of a greater whole (Merriam-Webster 2009b). Mathiassen et al. (2001), in a book on object-oriented analysis and design, offer a somewhat more stringent definition:

[A component is] a collection of program parts that constitutes a whole and has well-defined responsibilities.

While this definition is compatible with the software components of this thesis, it is very broad. Applied to software, the algorithms listed in the algorithms section of Communications of the ACM in the 1960s would qualify. McIlroy (1969) emphatically rejected the notion that these algorithms could qualify as components.

Two works provide more precise definitions that are used in this thesis. Szyperski et al. (2002:41), whose book “Component Software: Beyond Object-Oriented Programming” is one of the more influential in the field and one which is cited frequently in this thesis, offer this definition:

A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.

Heineman and Councill (2001a:7), whose book “Component-Based Software Engineering: Putting the Pieces Together” is a collection of articles related to this field, offer this definition:

[A software component is] a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard.

These two definitions capture the essence of how software components should be used. They are light on technical details, though. For the purposes of this thesis, the following pragmatic definition is adopted in addition to the above definitions:

A software component is a container of instantiable classes, as understood in the field of object-oriented programming. A component has an identity at runtime, but no observable state. Different versions of a component may co-exist at runtime.

In their books, both Szyperski et al. and Heineman and Councill make provisions for components that are not object-oriented. Szyperski et al., in particular, stress that a component may be implemented using a procedural or functional language. This thesis takes the position that, at least from the outside, a component is a container of classes—a class superstructure. Supporting this position, Aleksy et al. (2005:6) state that “component technology [...] is conceptually still built upon the ideas and technologies of object-orientation.” This view does not preclude a component implementation from being written in a procedural language, or from using the services of a functional language, but from the outside, a software component is object-oriented.

An alternative view of the component concept is that a component is a stateful entity that is placed on a form in a visual designer, its behavior customized through visual means. A push button in those environments, for instance, may thus be referred to as a “component.” Others hold that a component is little more than a class, or a class “plus stuff” (Venners and Eckel 2003). These views are not compatible with the view adopted by this thesis.

Footnotes

1. Beyond this fundamental accord, there is considerable room for diversity. In most traditions, objects are created from blueprints called classes, but in some, they are cloned from other objects serving as prototypes. Also, object-oriented languages differ in their degree of support for classes to inherit the implementation of other classes, and if so, whether they are substitutable for the classes they inherit from.