Component Based Software

Engineering
• Component-based software engineering
(CBSE) is a process that emphasizes the
design and construction of computer-based
systems using reusable software
“components ”
– “buy, don’t build”
• But a number of questions arise.
– Is it possible to construct complex systems by assembling
them from a catalog of reusable software components?
– Can this be accomplished in a cost- and time-effective
manner?
– Can appropriate incentives be established to encourage
software engineers to reuse rather than reinvent?
– Is management willing to incur the added expense
associated with creating reusable software components?
– Can the library of components necessary to accomplish
reuse be created in a way that makes it accessible to those
who need it?
– Can components that do exist be found by those who need
them?
ENGINEERING OF COMPONENT-BASED
SYSTEMS
• The process begins when a software team establishes
requirements for the system to be built using
conventional requirements elicitation techniques.
• Then, 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?
• For those requirements that are addressed
with available components, a different set of
software engineering activities commences:
– Component qualification.
– Component adaptation.
– Component composition.
– Component update.
• the term component
• 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. It 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) 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.
 THE CBSE PROCESS
• The CBSE process, however, must be
characterized in a manner that not only
identifies candidate components but also
qualifies each component’s interface, adapts
components to remove architectural
mismatches, assembles components into a
selected architectural style, and updates
components as requirements for the system
change
 DOMAIN ENGINEERING
• The intent of domain engineering is to
identify, construct, catalog, and disseminate
a set of software components that have
applicability to existing and future software in
a particular application domain. The overall
goal is to establish mechanisms that enable
software engineers to share these
components—to reuse them—during work on
new and existing systems.
• Three Major Activities
analysis, construction, and dissemination.
 The Domain Analysis Process
• The steps in the process were defined as:
1. Define the domain to be investigated.
2. Categorize the items extracted from the domain.
3. Collect a representative sample of applications in
the domain.
4. Analyze each application in the sample.
5. Develop an analysis model for the objects
• Prieto-Diaz expands the second domain analysis step
and suggests an eight-step approach to the
identification and categorization of reusable
components:
– 1. Select specific functions or objects.
– 2. Abstract functions or objects.
– 3. Define a taxonomy.
– 4. Identify common features.
– 5. Identify specific relationships.
– 6. Abstract the relationships.
– 7. Derive a functional model.
– 8. Define a domain language.
• the following set of pragmatic questions as a guide for identifying reusable
software components
• Is component functionality required on future implementations?
• How common is the component's function within the domain?
• Is there duplication of the component's function within the domain?
• Is the component hardware dependent?
• Does the hardware remain unchanged between implementations?
• Can the hardware specifics be removed to another component?
• Is the design optimized enough for the next implementation?
• Can we parameterize a nonreusable component so that it becomes reusable?
• Is the component reusable in many implementations with only minor changes?
• Is reuse through modification feasible?
• Can a nonreusable component be decomposed to yield reusable components?
• How valid is component decomposition for reuse?
 Characterization Functions
• A domain characteristic defines some generic
attribute of all products that exist within the
domain. For example, generic characteristics
might include the importance of
safety/reliability, programming language,
concurrency in processing, and many others.
• A set of domain characteristics for a reusable component can be
represented as {Dp}, where each item, Dpi, in the set represents a
specific domain characteristic. The value assigned to Dpi
represents an ordinal scale that is an indication of the relevance
of the characteristic for component p.
• A typical scale might be
1: not relevant to whether reuse is appropriate
2: relevant only under unusual circumstances
3: relevant—the component can be modified so that it can be used,
despite differences
4: clearly relevant, and if the new software does not have this
characteristic, reuse will be inefficient but may still be possible
5: clearly relevant, and if the new software does not have this
characteristic, reuse will be ineffective and reuse without the
characteristic is not recommended
• When new software, w, is to be built within
the application domain, a set of domain
characteristics is derived for it. A comparison
is then made between Dpi and Dwi to
determine whether the existing component p
can be effectively reused in application
Domain Characteristics
 Structural Modeling and Structure
Points
• Structural modeling is a pattern-based domain
engineering approach that works under the
assumption that every application domain has
repeating patterns (of function, data, and behavior)
that have reuse potential.
• Each application domain can be characterized by a
structural model (e.g., aircraft avionics systems differ
greatly in specifics, but all modern software in this
domain has the same structural model). Therefore,
the structural model is an architectural style that can
and should be reused across applications within the
domain.
• McMahon describes a structure point as “a distinct
construct within a structural model.”
• Structure points have three distinct characteristics:
1. A structure point is an abstraction that should have a
limited number of instances.
2. The rules that govern the use of the structure point should
be easily understood. In addition, the interface to the
structure point should be relatively simple.
3. The structure point should implement information hiding
by isolating all complexity contained within the structure
point itself. This reduces the perceived complexity of the
overall system.
 COMPONENT-BASED DEVELOPMENT
• Once the architecture has been established, it must be
populated by components that
(1) are available from reuse libraries and/or
(2) are engineered to meet custom needs.
• Hence, the task flow for component-based development
has two parallel paths .
– When reusable components are available for potential
integration into the architecture, they must be qualified and
adapted.
– When new components are required, they must be engineered.
• The resultant components are then “composed”
(integrated) into the architecture template and tested
thoroughly
Component Qualification, Adaptation,
and Composition
• Component Qualification
– Component qualification ensures that a candidate
component will perform the function required,
will properly “fit” into the architectural style
specified for the system, and will exhibit the
quality characteristics
• Among the many factors considered during component
qualification are
• Application programming interface (API).
• Development and integration tools required by the component.
• Run-time requirements, including resource usage (e.g., memory
or storage), timing or speed, and network protocol.
• Service requirements, including operating system interfaces and
support from other components.
• Security features, including access controls and authentication
protocol.
• Embedded design assumptions, including the use of specific
numerical or nonnumerical algorithms.
• Exception handling
Component Adaptation
• To mitigate against any conflicts, an adaptation technique called
component wrapping is often used. When a software team has full access
to the internal design and code for a component (often not the case when
COTS components are used) white-box wrapping is applied. White-box
wrapping examines the internal processing details of the component and
makes code-level modifications to remove any conflict.
• Gray-box wrapping is applied when the component library provides a
component extension language or API that enables conflicts to be
removed or masked.
• Black-box wrapping requires the introduction of pre- and postprocessing
at the component interface to remove or mask conflicts.
The software team must determine whether the effort required to
adequately wrap a component is justified or whether a custom
component (designed to eliminate the conflicts encountered) should be
engineered instead.
Component Composition
• The component composition task assembles qualified,
adapted, and engineered components to populate
the architecture established for an application. To
accomplish this, an infrastructure must be established
to bind the components into an operational system.
The infrastructure (usually a library of specialized
components) provides a model for the coordination of
components and specific services that enable
components to coordinate with one another and
perform common tasks.
Among the many mechanisms for creating an effective infrastructure is a set
of four “architectural ingredients” that should be present to achieve
component composition
• Data exchange model. Mechanisms that enable users and applications to
interact and transfer data (e.g., drag and drop, cut and paste) should be
defined for all reusable components. The data exchange mechanisms not
only allow human-to-software and component-to-component data
transfer but also transfer among system resources (e.g., dragging a file to
a printer icon for output).
• Automation. A variety of tools, macros, and scripts should be
implemented to facilitate interaction between reusable components.
• Structured storage. Heterogeneous data (e.g., graphical data,
voice/video, text, and numerical data) contained in a “compound
document” should be organized and accessed as a single data structure,
rather than a collection of separate files. “Structured data maintains a
descriptive index of nesting structures that applications can freely
navigate to locate, create, or edit individual data contents as directed by
the end user”.
• Underlying object model. The object model ensures that components
developed in different programming languages that reside on different
platforms can be interoperable. That is, objects must be capable of
communicating across a network. To achieve this, the object model
defines a standard for component interoperability
 Component Engineering
• As we noted earlier in this chapter, the CBSE process
encourages the use of existing software components.
However, there are times when components must be
engineered. That is, new software components must be
developed and integrated with existing COTS and in-house
components. Because these new components become
members of the in-house library of reusable components,
they should be engineered for reuse.
• Design concepts such as abstraction, hiding, functional
independence, refinement, and structured programming,
along with object-oriented methods, testing, SQA, and
correctness verification methods, all contribute to the
creation of software components that are
 Analysis and Design for Reuse
• a number of key issues that form a basis for design for reuse:
• Standard data. The application domain should be investigated and
standard global data structures (e.g., file structures or a complete
database) should be identified. All design components can then be
characterized to make use of these standard data structures.
• Standard interface protocols. Three levels of interface protocol
should be established: the nature of intramodular interfaces, the
design of external technical (nonhuman) interfaces, and the
human/machine interface.
• Program templates. The structure model (Section 27.3.3) can
serve as a template for the architectural design of a new program
 CLASSIFYING AND RETRIEVING
COMPONENTS
• Now, consider a large component repository.
Tens of thousands of reusable software
components reside in it. But how does a
software engineer find the one she needs? To
answer this question, another question arises:
How do we describe software components in
unambiguous, classifiable terms? These are
difficult questions, and no definitive answer
has yet been developed..
Describing Reusable Components
• the 3C model—concept, content, and context
 The Reuse Environment
• Software component reuse must be supported by an
environment that encompasses the following
elements:
– A component database capable of storing software
components and the classification information necessary
to retrieve them.
– A library management system that provides access to the
database.
– A software component retrieval system (e.g., an object
request broker) that enables a client application to retrieve
components and services from the library server.
– CBSE tools that support the integration of reused
components into a new design or implementation.
 ECONOMICS OF CBSE
• Impact on Quality, Productivity, and Cost
• Quality. In an ideal setting, a software
component that is developed for reuse would be
verified to be correct and would contain no
defects. In reality, formal verification is not
carried out routinely, and defects can and do
occur. However, with each reuse, defects are
found and eliminated, and a component’s quality
improves as a result. Over time, the component
becomes virtually defect free.
• Productivity. When reusable components are
applied throughout the software process, less
time is spent creating the plans, models,
documents, code, and data that are required
to create a deliverable system. It follows that
the same level of functionality is delivered to
the customer with less input effort. Hence,
productivity is improved.
• Cost: The net cost savings for reuse are
estimated by projecting the cost of the project
if it were developed from scratch, Cs, and
then subtracting the sum of the costs
associated with reuse, Cr, and the actual cost
of the software as delivered, Cd
The costs associated with reuse, Cr, include
• Domain analysis and modeling.
• Domain architecture development.
• Increased documentation to facilitate reuse.
• Support and enhancement of reuse components.
• Royalties and licenses for externally acquired
components.
• Creation or acquisition and operation of a reuse
repository.
• Training of personnel in design and construction for
reuse.
 Cost Analysis Using Structure Points
• A software designer (or system engineer) can develop
an architecture for a new application, system, or
product by defining a domain architecture and then
populating it with structure points. These structure
points are either individual reusable components or
packages of reusable components.
• Even though structure points are reusable, their
qualification, adaptation, integration, and
maintenance costs are nontrivial. Before proceeding
with reuse, the project manager must understand the
costs associated with the use of structure points
• Since all structure points (and reusable
components in general) have a past history,
cost data can be collected for each. In an ideal
setting, the qualification, adaptation,
integration, and maintenance costs
associated with each component in a reuse
library is maintained for each instance of
usage. These data can then be analyzed to
develop projected costs for the next instance
of reuse.
• As an example, consider a new application, X,
that requires 60 percent new code and the
reuse of three structure points, SP1, SP2, and
SP3. Each of these reusable components has
been used in a number of other applications
and average costs for qualification,
adaptation, integration, and maintenance are
available.
• To estimate the effort required to deliver X, the following
must be determined: overall effort = Enew + Equal + Eadapt
+ Eint
– where Enew = effort required to engineer and construct new
software components
– Equal = effort required to qualify SP1, SP2, and SP3.
– Eadapt = effort required to adapt SP1, SP2, and SP3.
– Eint = effort required to integrate SP1, SP2, and SP3.
• The effort required to qualify, adapt, and integrate SP1,
SP2, and SP3 is determined by taking the average of
historical data collected for qualification, adaptation, and
integration of the reusable components in other
applications.
 Reuse Metrics
• The benefit associated with reuse within a
system S can be expressed as a ratio
– Rb(S) = [Cnoreuse – Creuse]/Cnoreuse
• where Cnoreuse is the cost of developing S with no
reuse.
• Creuse is the cost of developing S with reuse.
• It follows that Rb(S) can be expressed as a
nondimensional value in the range
– 0 ≤ Rb(S) ≤ 1
• A general measure of reuse in object-oriented
systems, termed reuse leverage ,is defined as
– Rlev = OBJreused/OBJbuilt
where
– OBJreused is the number of objects reused in a
system.
– OBJbuilt is the number of objects built for a
system.
 Summary
• Component-based software engineering offers inherent benefits in
software quality, developer productivity, and overall system cost.
• In addition to software components, a variety of reusable artifacts can be
acquired by a software engineer. These include technical representations
of the software (e.g., specifications, architectural models, designs),
documents, test data, and even processrelated tasks
• The CBSE process encompasses two concurrent subprocesses—domain
engineering and component-based development. The intent of domain
engineering is to identify, construct, catalog, and disseminate a set of
software components in a particular application domain.
Component-based development then qualifies, adapts, and integrates
these components for use in a new system.
• Classification schemes enable a developer to find and retrieve reusable
components and conform to a model that identifies concept, content, and
context.
• The economics of software reuse are addressed by a single question: Is it
cost effective to build less and reuse more?