Overview

The chapter describes component-based software engineering (CBSE) as a process that emphasizes the design and construction of computer-based systems using reusable software components. This has the potential advantage of delivering highly reliable software products in a very short time. CBSE encourages the use of predictable architectural patterns and standard software infrastructures that improve overall product quality. CBSE encompasses two parallel engineering activities, domain engineering and component-based development. Domain engineering explores the application domain with the specific intent of finding functional, behavioral, and data components that are candidates for reuse and places them in reuse libraries. Component-based development elicits requirements from the customer and selects an appropriate architectural style to meet the objectives of the system to be built. The next steps are to select potential components for reuse, qualify the components to be sure they fit the system architecture properly, adapt the components if they must be modified to integrate them, then integrate the components into subsystems within the application. Custom components are engineered only when existing components cannot be reused. Formal technical reviews and testing are applied to ensure the quality of the analysis model and the design model. The resulting code is tested to uncover errors in the newly developed software.

Engineering of Component-Based Systems

• Software team elicits requirements for system to be built
• Architectural design is established
• Team determines which of the requirements are amenable to composition rather than construction

• 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 in the proposed system architecture?

• Team attempts to remove or modify requirements that cannot be implemented with COTS or in-house components?
• For those requirements that can be addressed with available components the following activities take place:

• component qualification - candidate components are identified based on services provided and means by which consumers access them
• component adaptation - candidate components are modified to meet the needs of the architecture or discarded
• component composition - architecture dictates the composition of the end product from the nature of the connections and coordination mechanisms
• component update - updating systems that include COTS is made more complicated by the fact that a COTS developer must be involved

• Detailed design activities commence for remainder of the system

Domain Engineering

• Domain analysis

• define application domain to be investigated
• categorize items extracted from domain
• collect representative applications from the domain
• analyze each application from sample
• develop an analysis model for objects

• Domain model
• Software architecture development
• Structural model

• consists of small number of structural elements manifesting clear patterns of interaction
• architectural style that can be reused across applications in the domain
• structure points are distinct constructs within the structural model (e.g. interface, control mechanism, response mechanism)

• Reusable component development (new software components must be developed and integrated with existing software components)
• Repository of reusable artifacts or components

Structure Point Characteristics

• Abstractions with limited number of instances within an application and recurs in applications in the domain
• The rules governing the use of a structure point should be easily understood and structure point interface should be simple
• The structure point should implement information hiding by isolating all complexity contained within the structure point itself

Component-Based Development

• Analysis
• Architectural design

• component qualification
• component adaptation
• component decomposition

• Component engineering
• Testing

• Iterative component update

Component Adaptation Techniques

• White-box wrapping (integration conflicts removed by making code-level modifications to the code)
• Grey-box wrapping (used when component library provides a component extension language or API that allows conflicts to be removed or masked)
• Black-box wrapping (requires the introduction of pre- and post-processing at the component interface to remove or mask conflicts)

Component Composition Infrastructure Elements

• Data exchange model (similar to drag and drop type mechanisms should be defined for all reusable components, allow human-to-software and component-to-component transfer)
• Automation (tools, macros, scripts should be implemented to facilitate interaction between reusable components)
• Structured storage (heterogeneous data should be organized and contained in a single data structure rather several separate files)
• Underlying object model (ensures that components developed in different languages are interoperable across computing platforms)

Representative Component Standards

• Object Management Group (OMG) CORBA (common object request broker architecture)
• Microsoft COM (component object model)
• Sun JavaBeans Component System

Classifying and Retrieving Components

• Describing reusable components

• concept - what the component does
• content - how the concept is realized
• context - specifies conceptual, operational, and implementation features of the software component within its domain of application

• Library indexing methods

• uncontrolled indexing vocabularies (syntax free, no restrictions)
• enumerated classification (hierarchical listing of the domain objects grouped by class relations)
• faceted classification (based on 1 to 8 basic descriptive features from the application domain)
• attribute-value classification (similar to faceted classification using unlimited number of fixed terms)

• Reuse environment elements

• component database capable of storing software components and classification information to allow their retrieval
• library management system to allow access to database
• software component retrieval system that enables client software to retrieve components and services from library server

• CBSE tools that support integration of reused components into a new design or implementation

Economics of Reuse

• Quality -- with each reuse additional component defects are identified and removed which improves quality.
• Productivity -- since less time is spent on creating plans, models, documents, code, and data the same level of functionality can be delivered with less effort so productivity improves.
• Cost -- savings projected by estimating the cost of building the system from scratch and subtracting the costs associated with reuse and the actual cost of the software as delivered.
• Cost analysis using structure points -- can be computed based on historical data regarding the costs of maintaining, qualification, adaptation, and integrating each structure point.
• Reuse metrics can be computed for CBSE