COMPONENT –BASED By: Monali Gandhi

DEVELOPMENT
INTRODUCTION
In the software engineering context, reuse is an idea both old and
new. Programmers have reused ideas, abstractions, and processes
since the earliest days of programming but the early approach to
reused was ad-hoc. Today, complex high-quality computer –based
systems must be built in a very short time and demand a more
organized approach to reuse.
ENGINEERING OF
COMPONENT-BASED
SYSTEMS
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?
CONTI…
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:
CONTI…
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

CONTI…
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.
THE CBSE PROCESS
A “component-based development model” was used to illustrate how a library
of reusable “candidate components” can be integrated into a typical
evolutionary process model. 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 .

The process model for component-based software engineering emphasizes

parallel tracks in which domain engineering occurs concurrently with
component-based development. Domain engineering performs the work
required to establish a set of software components that can be reused by the
software engineer. These components are then transported across a “boundary”
that separates domain engineering from component-based development.
CONTI…
Figure illustrates a typical process model
that explicitly accommodates CBSE .
Domain engineering creates a model of the
application domain that is used as a basis
for analyzing user requirements in the
software engineering flow. A generic
software architecture (and corresponding
structure points, provide input for the
design of the application. Finally, after
reusable components have been
purchased, selected from existing libraries,
or constructed (as part of domain
engineering), they are made available to
software engineers during component-
based development.
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.

Domain engineering includes three major activities—analysis,

construction, and dissemination. It can be argued that “reuse will
disappear, not by elimination, but by integration” into the fabric of
software engineering practice . As greater emphasis is placed on reuse,
some believe that domain engineering will become as important as
software engineering over the next decade.
THE DOMAIN ANALYSIS
PROCESS
We discussed the overall approach to domain analysis within the context
of object-oriented software engineering. 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.
THE DOMAIN ANALYSIS
PROCESS
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.
CONTI…
A domain language enables the specification and later construction of applications
within the domain.

Although the steps just noted provide a useful model for domain analysis, they
provide no guidance for deciding which software components are candidates for
reuse. Hutchinson and Hindley suggest 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
It is sometimes difficult to determine whether a potentially reusable
component is in fact applicable in a particular situation. To make
this determination, it is necessary to define a set of domain
characteristics that are shared by all software within a domain. 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.
CONTI…
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
 CONTI…
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 w. Table lists typical
domain characteristics that can have an
impact of software reuse. These domain
characteristics must be taken into
account in order to reuse a component
effectively.

Even when software to be engineered

clearly exists within an application
domain, the reusable components within
that domain must be analyzed to
STRUCTURAL MODELING
AND STRUCTURE POINTS
When domain analysis is applied, the analyst looks for repeating patterns in the
applications that reside within a domain. 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. Pollak and Rissman describe structural models in the following way:

Structural models consist of a small number of structural elements manifesting clear

patterns of interaction. The architectures of systems using structural models are
characterized by multiple ensembles that are composed from these model elements.
Many architectural units emerge from simple patterns of interaction among this small
number of elements.

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.
CONTI…
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. Restating this in object-oriented jargon , the size of the class
hierarchy should be small. In addition, the abstraction should recur
throughout applications in the domain. Otherwise, the cost to verify,
document, and disseminate the structure point cannot be justified.
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.
CONTI…
As an example of structure points as architectural patterns for a system,
consider the domain of software for alarm systems. This domain might
encompass systems as simple as SafeHome (discussed in earlier chapters) or as
complex as the alarm system for an industrial process. In every case, however,
a set of predictable structural patterns are encountered:

• An interface that enables the user to interact with the system.

• A bounds setting mechanism that allows the user to establish bounds on the
parameters to be measured.
• A sensor management mechanism that communicates with all monitoring
sensors.
• A response mechanism that reacts to the input provided by the sensor
management system.
• A control mechanism that enables the user to control the manner in which
monitoring is carried out.
CONTI…
Each of these structure points is integrated into a domain architecture.

It is possible to define generic structure points that transcend a number of

different application domains :

• Application front end—the GUI including all menus, panels and input and
command editing facilities.
• Database—the repository for all objects relevant to the application domain.
• Computational engine—the numerical and nonnumerical models that
manipulate data.
• Reporting facility—the function that produces output of all kinds.
• Application editor—the mechanism for customizing the application to the
needs of specific users.
COMPONENT BASED
DEVELOPMENT
Component-based development is a CBSE activity that occurs in parallel with
domain engineering. Using analysis and architectural design methods , the
software team refines an architectural style that is appropriate for the analysis
model created for the application to be built.

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
Domain engineering provides the library of reusable components
that are required for component-based software engineering. Some
of these reusable components are developed in-house, others can
be extracted from existing applications, and still others may be
acquired from third parties. Unfortunately, the existence of
reusable components does not guarantee that these components
can be integrated easily or effectively into the architecture chosen
for a new application. It is for this reason that a sequence of
component-based development activities are applied when a
component is proposed for use.
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 (e.g., performance, reliability, usability) that
are required for the application.
The interface description provides useful information about the
operation and use of a software component, but it does not provide
all of the information required to determine if a proposed
component can, in fact, be reused effectively in a new application.
CONTI…
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.
CONTI…
Each of these factors is relatively easy to assess when reusable
components that have been developed in-house are proposed. If
good software engineering practices were applied during their
development, answers to the questions implied by the list can be
developed. However, it is much more difficult to determine the
internal workings of COTS or third-party components because the
only available information may be the interface specification itself.
COMPONENT ADAPTATION
In an ideal setting, domain engineering creates a library of components that can be easily
integrated into an application architecture. The implication of “easy integration” is that (1)
consistent methods of resource management have been implemented for all components in
the library, (2) common activities such as data management exist for all components, and (3)
interfaces within the architecture and with the external environment have been implemented in
a consistent manner.

In reality, even after a component has been qualified for use within an application architecture,
it may exhibit conflict in one or more of the areas just noted. To mitigate against these
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. Like its counterpart in software
testing , 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.
CONTI…
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.

Because the potential impact of reuse and CBSE on the software industry is
enormous, a number of major companies and industry consortia3 have proposed
standards for component software:
CONTI…
OMG/CORBA. The Object Management Group has published a common
object request broker architecture (OMG/CORBA). An object request
broker (ORB) provides a variety on services that enable reusable
components (objects) to communicate with other components, regardless
of their location within a system. When components are built using the
OMG/CORBA standard, integration of those components (without
modification) within a system is assured if an interface definition language
(IDL) interface is created for every component. Using a client/server
metaphor, objects within the client application request one or more
services from the ORB server. Requests are made via an IDL or
dynamically at run time. An interface repository contains all necessary
information about the service’s request and response formats.

Microsoft COM. Microsoft has developed a component object model (COM)

that provides a specification for using components produced by various
vendors within a single application running under the Windows operating
system. COM encompasses two elements: COM interfaces (implemented
as COM objects) and a set of mechanisms for registering and passing
messages between COM interfaces. From the point of view of the
CONTI…
Sun JavaBean Components. The JavaBean component system is a portable,
platform independent CBSE infrastructure developed using the Java
programming language. The JavaBean system extends the Java applet to
accommodate the more sophisticated software components required for
component-based development. The JavaBean component system
encompasses a set of tools, called the Bean Development Kit (BDK), that
allows developers to (1) analyze how existing Beans (components) work, (2)
customize their behavior and appearance, (3) establish mechanisms for
coordination and communication, (4) develop custom Beans for use in a
specific application, and (5) test and evaluate Bean behavior.
Which of these standards will dominate the industry? There is no easy answer
at this time. Although many developers have standardized on one of the
standards, it is likely that large software organizations may choose to use all
three standards, depending on the application categories and platforms that
are chosen.
COMPONENT ENGINEERING
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.

Nothing is magical about creating software components that can be reused.

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 reusable. In this section we will
not revisit these topics. Rather, we consider the
reuse-specific issues that are complementary to solid software engineering
practices.
ANALYSIS AND DESIGN FOR
REUSE
Components are defined and stored as specification, design, and
implementation classes at various levels of abstraction with each
class being an engineered description of a product from previous
applications. The specification knowledge development knowledge
is stored in the form of reuse-suggestion classes, which contain
directions for retrieving reusable components on the basis of their
description and for composing and tailoring them after retrieval.

Automated tools are used to browse a repository in an attempt to

match the requirement noted in the current specification with those
described for existing reusable components (classes).
Characterization functions and keywords are used to help find
potentially reusable components.
CONTI…
As we have already noted, DFR requires the software engineer to apply solid
software design concepts and principles . But the characteristics of the application
domain must also be considered. Binder suggests 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 can serve as a template for the
architectural design of a new program.
Once standard data, interfaces, and program templates have been established, the
designer has a framework in which to create the design. New components that
Re-Engineering
 When we need to update the Forward Engineerin
software to keep it to the current
market, without impacting its
functionality, it is called software
re-engineering
 It is a process where the design of
software is changed and programs
are re-written
 Legacy software cannot keep
tuning with the latest technology
available in the market
 For example, initially UNIX was
developed in assembly language.
When language C came into existence,Reverse Engineering
UNIX was re-engineered in C, because
working in assembly language was
difficult.

 Reverse
Re-Engineering Cont. Engineeri
ng
 Decide what to re-engineer. Obtain
specificati
 Is it whole software or a part of it?
ons of
 Perform Reverse Engineering, in existing
order to obtain specifications of softwareProgram
existing software Restructur
 Restructure Program if required Change ing
 For example, changing function- program
oriented programs into object- and/or
oriented programs and re-structure
data as required
data
structure
 Apply Forward engineering concepts Forward
in order to get re-engineered Engineeri
software Get re- ng
engineered
software
developed
Reverse Engineering Reverse
engineering can
 The abstraction level of a extract design
reverse engineering process information from
refers to the sophistication of the source code
 As the abstraction level
design information that can be
extracted from source code increases, information will allow
easier understanding of the
 Ideally, the abstraction level program
should be as high as possible  Interactivity refers to the
 The reverse engineering process degree to which the human is
should be capable of “integrated” with automated
 Deriving procedural design tools to create an effective
representations (a low-level reverse engineering process
abstraction)
 Program and data structure  In most cases, as the
information (a somewhat higher abstraction level increases,
level of abstraction) interactivity must increase
 Object models, data flow models
(a relatively high level of abstraction)
 The directionality of the
 Entity relationship models (a high reverse engineering process is