On the surface, CBSE seems quite similar to conventional or object-oriented software engineering. The process begins when a software team e...
On the surface, CBSE seems quite similar to conventional or object-oriented software engineering. The process begins when a software team establishes requirements for the system to be built using conventional requirements elicitation techniques. An architectural design is established, but rather than moving immediately into more detailed design tasks, the team examines requirements to determine what subset is directly amenable to composition, rather than construction. That is, the team asks the following questions for each system requirement:
• Are commercial off-the-shelf (COTS) components available to implement the requirement?
• Are internally developed reusable components available to implement the requirement?
• Are the interfaces for available components compatible within the architecture of the system to be built?
The team attempts to modify or remove those system requirements that cannot be implemented with COTS or in-house components. If the requirement(s) cannot be changed or deleted, conventional or object-oriented software engineering methods are applied to develop those new components that must be engineered to meet the requirement(s). But for those requirements that are addressed with available components, a different set of software engineering activities commences:
Component qualification. System requirements and architecture define the components that will be required. Reusable components (whether COTS or in-house) are normally identified by the characteristics of their interfaces. That is, “the services that are provided, and the means by which consumers access these services” are described as part of the component interface. But the interface does not provide a complete picture of the degree to which the component will fit the architecture and requirements. The software engineer must use a process of discovery and analysis to qualify each component’s fit.
Component adaptation.We noted that software architecture represents design patterns that are composed of components (units of functionality), connections, and coordination. In essence the architecture defines the design rules for all components, identifying modes of connection and coordination. In some cases, existing reusable components may be mismatched to the architecture’s design rules. These components must be adapted to meet the needs of the architecture or discarded and replaced by other, more suitable components.
Component composition. Architectural style again plays a key role in the way in which software components are integrated to form a working system. By identifying connection and coordination mechanisms (e.g., run-time properties of the design), the architecture dictates the composition of the end product.
Component update. When systems are implemented with COTS components, update is complicated by the imposition of a third party (i.e., the organization that developed the reusable component may be outside the immediate control of the software engineering organization).
Brown and Wallnau suggest the following possibilities:
• Component—a nontrivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture.
• Run-time software component—a dynamic bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered in run time.
• Software component—a unit of composition with contractually specified and explicit context dependencies only.
• Business component—the software implementation of an “autonomous” business concept or business process.
In addition to these descriptions, software components can also be characterized based on their use in the CBSE process. In addition to COTS components, the CBSE process yields:
• Qualified components—assessed by software engineers to ensure that not only functionality, but performance, reliability, usability, and other quality factors conform to the requirements of the system or product to be built.
• Adapted components—adapted to modify (also called mask or wrap) [BRO96] unwanted or undesirable characteristics.
• Assembled components—integrated into an architectural style and interconnected with an appropriate infrastructure that allows the components to be coordinated and managed effectively.
• Updated components—replacing existing software as new versions of components become available.
Because CBSE is an evolving discipline, it is unlikely that a unifying definition will emerge in the near term.
