Engineering Principles for CBSE

There are principles for the development of components to support component integration. Some of important component-engineering principles are discussed below.

Domain Orientation: Software reuse may be the most effective ways of increasing productivity and reducing maintenance as well as development cost of software. To achieve successful software reuse, commonalities of related systems must be discovered and represented in a form that can be exploited in developing similar systems. Domain orientation is one such approach. It attempts to discover commonalities of systems in an application or a technical area (i.e., a domain) and then develop models or components that can be used in developing systems in the domain. This approach will help evolving an application as well as developing a family of applications.

Although domain orientation is believed to be the key element in achieving successful CBSE, most domain-oriented engineering technologies are still in their infant stage. There are many technical issues that must be resolved before we can mature these technologies.

Separation of Concerns: This engineering principle is one of the key engineering principles supporting CBSE. Components must be designed so that each performs a unique singular function. Also, each functional component must be designed independent of the interface mechanisms it employs to communicate with other components. This principle implies that selection of a particular functional component or an interface method/mechanism does not impose any restriction on selection of other components.

Abstract Virtual Machine Interface: Interface of a component must be designed as a virtual machine. A component must provide a complete, non-redundant (i.e., minimal) interface. The interface must also hide internals (i.e., implementation decisions) of the components so that different implementations can be made for the component.

Postponement of Context Binding: In the design of components, we need to strive for the development of "context free" components focusing only on the core functionality. To the extent it is possible, binding with particular contextual parameters such as data type, storage size, implementation algorithms, communication methods, operating environment, etc. should be postponed until the component integration time when performance optimization is made.

Design Reuse: For component-based software integration to happen, design (i.e., component development context) must be shared and reused among the potential users. That is, design reuse must happen before component reuse. An architectural design shows the allocation of functionality to components and, for a component integration, reuse of the underlying architecture based on which components were developed must occur.

Hierarchically Layered Architecture: Architectures and code components must be designed for maximum flexibility in composing components. Figure 2 includes a layered architecture model [4] which separates application task-oriented components, which do controlling and activity coordination, from functional components, which do mostly computations. Implementation techniques that are commonly used in the domain are separated from the functional components as implementation techniques can change for the same functions. Data communication models (e.g., message queue, task synchronization) are also separated from the technologies that implement various communication models. This architecture model allows postponement of the binding of particular implementation techniques until the component integration time when performance considerations are made.