1.2 Contemporary components

The software components of today have the same overarching goal as the components advocated in years past: making it possible to encapsulate discrete functionality into reusable entities. The concept has evolved considerably since the late 1960s, and today, some or all of the following should be true for a contemporary component:

• A component stands alone. As such, a component should not have been produced for any one project, and should prove itself useful in a multitude of projects (Vigder 2001). From an economic point of view, Szyperski et al. (2002) estimate that a component needs to be used in three distinct project before it breaks even. As a stand-alone entity, a component may be deployed to an end-user’s system separately from the programs that make use of it. A component should not be tied to a specific programming environment or language.

• A component is encapsulated. The inner workings of a component are hidden, meaning that a component may only be accessed in carefully controlled ways (Sommerville 2007). This enables information hiding on a high level, in the tradition of Parnas (1972). A component is thus used without relying on its source code, which is known as black box reuse (as opposed to white box reuse). The use of black box reuse is said to stimulate the move from monolithic systems to modular ones (Szyperski et al. 2002:xxii).

• A component is customizable. Components should make it possible to customize their behavior, enabling them to be used in a variety of contexts.

• A component is documented. Aside from including developer documentation, Szyperski et al. (2002:470) suggest that the documentation should be machine-readable, making it possible to store it as part of component catalogs, which can be searched through in pursuit of suitable components. The documentation should include the component’s requirements on the underlying platform and on other components—in other words, its dependencies.

• A component is certified. Some commentators, such as Booch et al. (2001) and Bachmann et al. (2000), have suggested that in order for components to be truly trustworthy, they need to be certified to conform to rigorous standards set by neutral, third-party organizations.

Software components are meant to enable reuse, making it possible for developers to glue interoperable software parts together (this is often referred to as composition). As a result, it is thought that software components create new roles in the software industry, that of component writers and component assemblers (Vitharana 2003; Szyperski et al. 2002:495). The former category is made up of skilled programmers, working with existing tools and languages, while the latter category is comprised of people with a different set of skills. Component assemblers need not use the same tools and languages used by component writers, and may instead use scripting languages in conjunction with visual designers to put together complete solutions.¹

Components that can be reused by many different software projects lend themselves well to being sold on a market.² In other engineering industries, a component market enables buyers to choose from a wide variety of components that can be integrated into their products, making possible complex products that would have been hard for a single company to realize alone. Some proponents of software components believe that the same kind of market is sustainable for software parts. Ivar Jacobson, one of the founders of the Unified Modeling Language (UML), writes the following in a foreword to a book on software components (Heineman and Councill 2001a):

I dream that we will get a component marketplace where different players can work. Some will play the role of selling components; others will buy components. [...] In the coming years, we will be able to revolutionize the production of software and then bring my final dream to fruition [...].