In-Depth

Components Defined

• By Bill Councill, George T. Heineman
• November 1, 2001

Group aims to create "rigorous" definitions for component development terms and standards

Portions of the following article are excerpted from Component-based Software Engineering: Putting the Pieces Together, edited by George T. Heineman and William T. Councill. Used with the permission of the editors and Addison–Wesley.

Why should anyone care about a precise definition of a software component? After all, most software engineers and programmers can define a module only vaguely, if at all, and yet they are able to do their jobs.

However, joint, precise understandings of definitions are important and more significant than we acknowledge. Consider a meeting of a prestigious group of software engineers. Each has contributed significantly to the literature on software engineering. An international standards body invited the 20 participants to a workshop and assigned them an agenda to describe the latest research in component-based metrics, as well as the direction the group believed the metrics and the component-based software engineering community should take during the next five years to ensure exacting conformity to standards. Within a two-day workshop, these efforts were hampered by the participants' complete lack of agreement on basic terms, including the name of their profession itself. Many principles were tacitly accepted, but disagreements concerning terms got in the way.

For two days, the group discussed and argued about the importance of frameworks, processes, methodologies and architecture as applied to software engineering. They formed fractious thematic clusters to dispute and defend their ever-widening perspectives concerning software engineering and the functions that architecture, components, reuse, programming languages, modeling languages, application families and education would occupy in the field. Interestingly, no one introduced the subject of engineering methodologies in software engineering. Rather than settling on one definition of software engineering, the participants dispersed like tribes from the Tower of Babel.

The workshop ended with the facilitator requesting more time from the international standards body to continue the workshop the following year. Members of the standards body read the facilitator's report of the workshop and, as a standards body, tersely reminded the facilitator to communicate this prescient excerpt from the 1968 NATO Conference on Software Engineering to the group: "The phrase 'software engineering' was deliberately chosen as being provocative, in implying the need for software manufacture to be based on the types of theoretical foundations and practical disciplines that are traditional in the established branches of engineering."

What lesson can be learned from this experience? Software engineering is a poorly defined, unregulated discipline that has adopted a professional appellation. It has adopted terms that lack meaning in other engineering disciplines, and many leaders in software engineering are against licensure or required certification of engineers. To retain the engineering label, software engineering must avoid promoting quasi-scientific or pseudo-engineering agendas. Students often graduate from computer science and software engineering academic programs without a thorough grounding in the engineering sciences.

The goal of this article is to rigorously define the core terms that describe the best practices of component-based software engineering (CBSE). We will develop and describe in detail the term software component and its constituent sub-elements to provide clear, unambiguous and rational meanings for the terms used to describe CBSE. You will find some terms used here for the first time. When non-rigorous terms are used, we rely on the engineering sciences, particularly industrial and civil engineering, which require precise definitions because of the demands for safety and public welfare inherent in their disciplines.

CBSE requires clear definitions because many terms used in the field appeared in publications without precise definitions, and were then reused without reflection or scientific review. We avoid using terms that are not rigorously defined, that are circularly referenced or that are simply descriptions of software engineering phenomena.

Our primary goal is to offer a hierarchy of definitions for the term software component that will be accepted by software engineers, computer scientists and interested readers. To achieve this goal, we draw on our experiences described in our book, Component-based Software Engineering: Putting the Pieces Together. This article is based on our ability to achieve a consensus definition with nearly 50 leading software engineering researchers, consultants and managers.

Background
We first define a set of basic terms required to explain the characteristics assigned to the definitions. Software is constructed to execute on a general-purpose von Neumann computing device (henceforth, a machine). A software element contains sequences of abstract program statements that describe computations to be performed by a machine. A software element is machine-executable if: 1. the machine directly executes the program statements, or 2. a machine-executable interpreter directly understands the program statements and the machine directly executes the interpreter.

The source code for software is the set of machine-readable files containing program statements written in a programming language. These statements are either compiled into machine-executable statements using a compiler or executed by an interpreter.

Component definition
To accurately define software component, we must first define the following terms:

• A component model is a recognized and generally accepted proprietary, national or international standard that defines specific composition and interaction standards.
• A component model implementation is the dedicated set of executable software elements required to support the execution of components that conform to the component model.
• A software component infrastructure is a set of interacting software components designed in conformance with the component model and component model implementation to ensure that a software system or subsystem constructed using those components and interfaces will satisfy clearly defined performance specifications.

A software component is a distinct software element that conforms to a component model, which when independently deployed and composed according to a composition standard, interacts with other components or forms of software (such as legacy software) according to an interaction standard. The software component provides comprehensive analysis and design documentation according to then prevailing standards and operates within a software component infrastructure described by detailed performance specifications.

Component model
A component model operates on two levels. First, a component model defines how to construct an individual component. For example, Microsoft's Component Object Model (COM) requires each COM component to provide an IUnknown interface. Second, a component model can enforce global behavior on how a set of components in a component-based system will communicate and interact with each other. A component model enables composition by defining an interaction standard that promotes unambiguously specified interfaces.

A component can be composed with another component or other software element (for example, legacy code) by creating assembled or integrated connections, respectively. The component model defines the permitted mechanisms for creating assembled or integrated connections. "Plug-in compatibility" only succeeds if a component can accurately declare its expectations of the other component to which it is connected. The process of assembly may be as complicated as necessary to achieve precise specifications. We use the term assembly to include all the different forms in which components compose, such as wrapping, static and dynamic linking, and "plug-and-play."

The component model may define customization mechanisms that describe how components can be extended without modification. We treat customization as an advanced form of interaction. A component model may also define mandatory component properties, such as coding formats, documentation standards, or obligatory producer-independent interfaces.

Composition standard
For independent deployment, a component must be clearly separate from an OS and other components. Thus, the component encapsulates the necessary data and algorithms to perform its tasks. The way a component is deployed is determined by the component model and involves three steps:

1. Installing the component in preparation for its use.
2. Configuring the component and perhaps the operating system (OS) where the component will be executed to make the component available.
3. Instantiating the component for use.

The source code for a software component is the full set of machine-readable software files (containing procedures and modules) and machine-executable files (containing runtime libraries and precompiled object code) required to package the software component into a machine-readable software element. A software component may be packaged in binary form to:

• Protect the proprietary intellectual property of the software component producer.
• Decrease installation and deployment costs.
• Reduce explicit context dependencies.

The component producer will decide whether the source code should be deployed with the component. It is possible that a consumer or third-party certifier will require access to the source code.

A composition standard defines how components can be composed to create a larger structure and how a producer can substitute one component to replace another that already exists within the structure. We pattern our definition for the term composition in the "Terms" sidebar after the Reference Model of Open Distributed Processing (RM-ODP). A joint effort of international standards bodies, RM-ODP describes a supporting infrastructure that enables the integration of distribution, internetworking, interoperability and portability of applications. As well as an interface description, the component producer should provide enough descriptive documentation to enable a component consumer to assemble the component into a target application. Third-party certifiers also use the documentation to verify the process used to develop the component and ensure that the final product meets the specifications. The component producer or the third-party certifier will decide the most appropriate form for the documentation, that is, whether to store it with the component, in either source or binary format, or provide it separately. The forms of documentation that are most advantageous to component consumers are: business rules; business processes; functional requirements; nonfunctional requirements; use case scenarios; and design documentation—using UML diagrams and Object Constraint Language, including preconditions, postconditions and design contracts.

Terms

Standard—An object or quality or measure serving as a basis to which others should conform, or by which the accuracy or quality of others is judged (by present-day standards). This term includes proprietary vendor and producer standards as well as national and international standards produced by recognized standards bodies. Software element—A sequence of abstract program statements that describe computations to be performed by a machine. Interface—An abstraction of the behavior of a component that consists of a subset of the interactions of that component together with a set of constraints describing when they may occur. The interface describes the behavior of a component that is obtained by considering only the interactions of that interface and by hiding all other interactions. Interaction—An action between two or more software elements. Composition—The combination of two or more software components yielding a new component behavior at a different level of abstraction. The characteristics of the new component behavior are determined by the components being combined and by the way they are combined. —Bill Councill and George T. Heineman

Interaction standard
One underlying concept of a component is that it has clearly defined interfaces. We pattern our definition for the term interface after the object composition model for RM-ODP. An interface standard is the set of mandatory requirements employed and enforced to enable software elements to interact directly with other software elements. An interface standard declares what can comprise an interface.

A component supports a provided interface if it contains an implementation of all operations defined by that interface. The interface hides the component implementation. A component needs a required interface if the component requests an interaction defined in that interface and the component expects some other software element to support that interface. A component may be unable to provide an interface if one of its required interfaces is unfulfilled. A component should ideally deploy with descriptive information that completely specifies all provided and required interfaces.

Software elements interact with a component using its clearly defined and documented interfaces. An interaction standard defines the elements of an interface. If the component can perform its function only by interacting with other software elements, all explicit context dependencies should be specified in its documentation. An interaction standard is actually a superset of the interface standard. The interaction standard covers both direct and indirect interactions between components.

A component may have an explicit context dependency on the OS, a software component or some other software element. An interaction standard specifies the type of explicit context dependencies a component may have. Another form of explicit context dependency occurs when a component must execute on a computer with a specific clock speed to achieve its performance objective. If the component must interact with a hardware device, it uses APIs provided by the OS or an interface provided by the component model implementation. In both cases, the descriptive information for the component must clearly define the explicit context dependency. To enable reuse and interconnection of components, component producers and consumers often agree on a set of interfaces before the components are designed. These mutual agreements can lead to standardized interfaces.

Component model implementation
The component model implementation is the dedicated set of executable software elements necessary to support the execution of components within a component model. An OS could embed the component model implementation, but that would only further complicate the OS and might restrict the applicability of the component model. The component model implementation is typically a thin layer that executes on top of an OS. Multiple OSs can port this layer to ensure maximum applicability of the component model.

The interaction standard for a component model determines whether an interface must be registered with the component model implementation prior to use. Interfaces are defined by using an Interface Definition Language (IDL) and registered with an interface repository associated with the component model implementation. The composition standard for a component model determines whether a component must be registered with the component model implementation prior to its use. The component model implementation vendor may provide tools such as an IDL compiler to support component development.

The component model implementation makes it possible to execute components that conform to the component model. The OMG's Common Object Request Broker Architecture (CORBA), for example, functions in an open distributed processing system using Object Request Brokers, software applications that execute on OSs like Windows and Unix. CORBA is an open standard; that is, the OMG promotes the standard but is not a component producer that provides the component model implementation. When the producer of a component model implementation is also the designer of the component model, the component model could be proprietary.

Implementation of the definition
Searching for a term in a dictionary portends a future action. Looking up definitions should result in progression, even dynamism. The Oxford English Reference Dictionary gives the following definitions of the term define: "1. give the exact meaning of (a word etc.)"; "3. make clear, esp. in outline (well-defined image)"; "4. mark out the boundary or limits of"; and "5. (of properties) make up the total character of."

One of many current definitions of software component is simply, "Software components are binary units of independent production, acquisition, and deployment that interact to form a functioning system. They have well-defined interfaces and explicit context dependencies only." This definition does not meet our call-to-action test and is primarily descriptive.

Our definition provides the means for a methodology to assure that the hierarchical definition is implemented correctly for each software component and the composition and interaction of components within a software component infrastructure.

A master plan
In any meaningful engineering endeavor, a lead engineer or lead Component-based Software Project Manager (CBSPM) establishes the scope of the project according to a Request For Proposal (RFP), identifies the performance specs of the finished product, and determines how to validate the success of the product. In establishing the product's scope, the lead CBSPM (see the sidebar "Component-based Software Project Management") divides the work into subprojects—self-contained processes of analysis and design, managed by subproject CBSPMs, which produce elements that will be incorporated into the final design. The elements from the subprojects are customized to implement an integrated design that will satisfy the performance specs.

Component-based Software Project Management

The difference between traditional software development project management and component-based software project management is significant. Because there is a shortage of component-based software project managers (CBSPMs), existing project managers and technical staff with leadership characteristics may be trained for the new positions. I anticipate that CBSPMs will reduce the number of failed software projects attributed to software project management failures. CBSPMs should have training and expertise in the practice of the intricacies of project management as exemplified in A Guide to the Project Management Body of Knowledge (Newtown Square, Pa.: Project Management Institute, 2000). CBSPMs should also study engineering management in an accredited program offering continuing education courses. Management should require the following academic courses for most project and program managers who specialize in traditional project management activities: Measurement and metrics to demonstrate the efficiencies between pre-component development and component development, including component reuse. Component-based software analysis, including business rules and requirements elicitation, business process modeling, use case scenario modeling and development. Component-based software design. Component construction in at least one complete object-oriented language. Software testing with test harnesses, including verification activities at the end of each increment for each phase of the component-based software life cycle (CSLC). Validation activities at the putative end of the project, including user-acceptance testing, third-party testing and re-testing all defects reported during system testing and user-acceptance testing. Maintenance of black-box components—both third-party and those developed within the organization—where limited visibility is available and documentation is often unavailable. Thereafter, experience in at least two CBD projects, preferably in all component-based software life cycle phases. —Bill Councill

In CBSE and software reuse, we use the engineering term performance specification rather than requirements specification because the term foreshadows the need for decomposing a problem into sub-problems to be solved, while requirements are often global in scope and cannot be reused easily.

A performance specification defines the functional requirements for a product, the environment in which it must operate, and any interface and interchangeability requirements. It provides criteria for verifying compliance, but it does not state methods for achieving results.

In the field of software engineering, the master software development plan created by the lead CBSPM ensures the success of the project and its subprojects.

A master software development plan describes the methods adopted by the lead software engineer or CBSPM for a system's composition and interaction. It is conceptual and defines the boundaries of the system, its elements, interactions, and constraints on these elements and interactions. The master plan is a global design that identifies discrete and manageable subprojects.

Description
The lead CBSPM and the team of subproject CBSPMs (component project teams or CPTs) are responsible for ensuring the success of the project by adapting existing models to fit the software under development. Traditional professional engineering practices require that the processes necessary for each project are determined by the lead CBSPM based upon the performance specifications of the project. While nationally or internationally prescribed organizational processes are helpful—such as the Software Engineering Institute's Capability Maturity Model and the International Standards Organization (ISO) 9001—the lead CBSPM is responsible for the project and subprojects. Lead CBSPMs and subproject CBSPMs are also responsible for compliance with laws and regulations, as well as industry standards. The realization of a comprehensive and frequently complex master software development plan results in the design of a software component infrastructure. The component infrastructure embodies the design decisions and trade-offs of the project. The lead CBSPM ensures that descriptive documentation is developed that precisely describes the compositions and interactions among components in the software component infrastructure.

Through increasingly detailed design, the component infrastructure is refined and a component model is selected. The final implemented components in the infrastructure will conform to this component model. The component model implementation enables the interaction and composition of the components in the software component infrastructure. The component project team may select an existing component model, design and implement a proprietary component model, or develop a component model implementation for an existing component model. The component model implementation will support the execution of the components in the software component infrastructure. CBSPMs do not work in isolation; they rely on the judgment of the analysis, design, construction and test teams. So their choices are based on best practices, according to the professional assessments of the CBSPMs—as influenced by the various teams—to satisfy the original design goals of the system within budget and staffing constraints.

The CPT may choose to design a software component infrastructure that includes components conforming to different component models. In this case, the lead CBSPM must ensure the interoperability of the respective component model implementations of these component models.

Because of the different types of performance specifications a system must satisfy (such as efficiency, use of resources, and integration with legacy data), software engineers, analysts and designers benefit from "visualizing" any proposed software system from a variety of viewpoints. The software component infrastructure that supports the master software development plan can be analyzed from multiple viewpoints to evaluate global performance requirements.

The big picture
Figure 1 demonstrates the relationships among the master software development plan and the components, models, model implementations and infrastructures. The lead engineer is responsible for selecting the component model that can best implement the logical design as described by the software component infrastructure created for the master software development plan. The design elements produced by the subprojects must interact effectively to achieve the overall project goal, and software engineers must determine how to map the logical elements into physical components. The RM-ODP viewpoints can help engineers make successful decisions for the producer or consumer. This makes the implementation of the system an engineering endeavor.

Figure 1: The big picture of CBSE

A graphical overview of the master software development plan and all its elements.

Consider a component producer that has won a competitive bid for designing and deploying a component-based general ledger system. The lead CBSPM first decomposes the project into its constituent subprojects, such as inventory, accounts receivable and merchandise distribution. The business or contracting organization may already have a legacy inventory system. So a subproject CBSPM is assigned to the design of a component that wraps the legacy system and provides an interface that conforms to the component model used by the other system components. Then the lead CBSPM schedules a design inspection with everyone involved in the initial design to verify that all components interact and integrate logically according to the master plan.

The component infrastructure in Figure 1 is the result of the design process followed by the CPT, as well as the analysis and design teams. Through increasingly detailed refinement, the software component infrastructure is implemented to form the basis for the desired software system.

Conclusion
The aim of this article was to provide a precise definition of the term software component and its sub-elements that could be used today to develop software components. If you are deciding to make the transition to component technology, these definitions will be even more useful. CBSE is a challenge for even experienced software project team members because of the lack of rigorous definitions, the use of confusing and circular definitions, and descriptions passing for definitions. This article also tried to reengineer the Tower of Babel and produce a consensus definition of software component—one that is meaningful to technicians and managers.

Achieving these definitions is more than an academic exercise; it is a necessary step in defining the emerging field of CBSE. Please send your comments to us at www.cbseng.com or e-mail us directly.