COMPONENT Lecture 1 and 2

BASED i)Building reliable

component-based

SOFTWARE software systems by

Ivica Crnkovic,
Magnus Larsson
ENGINEERING ii) Tiwari,Uk and S.
Kumar.Component

(INTRODUCTION based software

engineering methods

)
and metrics
COMPONENT-BASED DEVELOPMENT
PARADIGM
The component-based development paradigm is now an
established field of software engineering
 which from the outset focuses as much as possible on reusability
of pre-constructed code constructs and other usable or reusable
deliverables.
The component-based paradigm can be utilized with both types
of development paradigm, traditional or advanced.
In component-based paradigms, reusability can be at any level,
or with any deliverable,
whether in requirements, documentation, design construct,
coding, test cases or any similar software construct.
Key Findings
 In the component-based paradigm, the emphasis on reusability ultimately results in
a shorter development life cycle.
 Component-based development supports modularity, or componentization, which
helps control the overall design of the software and ultimately provides better
maintainability to the developed software.
 Due to the nature of componentization, the component-based paradigm supports
parallel construction of components to increase productivity in the development.
 The component-based paradigm supports reusability not only during but also after
development. Components are deposited in the repository for future use.
 Reduced development costs in comparison to other development paradigms.
 Components can be added or removed without affecting the other parts of the
software, hence it provides better scalability.
 It enhances the overall reliability of the software as pre-tested and properly
implemented components are used in development.
 It is assumed that components used in development support language
independence and vendor independence.
 It provides greater flexibility in terms of development and user interaction.
Critiques:
 Component-based development supports assembly of pre-developed
components. Assembly and integration is a major challenge in this
paradigm. No standard mechanism has been defined for the
integration of components into the software architecture. The only
mechanism available is the design document.
 Interaction among components is both crucial and time-consuming.
Interaction issues are complex and generate complexity in the overall
design of the software.
 Testing is comparatively time-consuming and costly as the concept is
based on integration and interaction of components. The main focus
is on integration testing of components.
 Components can be sourced from different vendors or from a third
party. Component quality may therefore vary, ultimately affecting the
overall quality of the developed software.
 Experts are required to identify and integrate components according
COMPONENT-BASED SOFTWARE
ENGINEERING (CBSE)
 Component-based software engineering (CBSE) is an elite form of software
engineering that offers the feature of reusability.
 Reuse of software artifacts and the process of reusability make CBSE a
specialized software development paradigm. Its philosophy is “buy, don’t
build.”
 CBSE reuses pre-constructed and available software constructs rather than
developing them from the beginning.
 The basic idea is to develop a component (including classes, functions,
methods and operations) only once and reuse it in various applications rather
than re-constructing it every time.
 Reusing pre-developed and pretested components make the development
life cycle shorter, helps to increase the reliability of the overall application
and reduces time to market
 The CBSE development paradigm is used to develop generalized
as well as specific components. Four parallel processes—new
component development, selection of preexisting components
from the repository, integration of components and control and
manage— are involved in the creation of more than one
application concurrently, as described in Figure.
 With each process there must be a feedback method to address
problems and errors arising in component selection, new
component development, interaction and integration errors
among the components, and their side effects.
 To manage all these parallel activities, there must be a control
procedure or management procedure which will not only assess
the development process but will also manage the requirement
analysis, selection of components, integration of components
and, most importantly, the quality of components submitted to
the repository for future reuse.
WHAT IS A COMPONENT?

We can find several definitions of a component in literature; however everyone

agrees that a component is a piece of software
. These definitions begin from the consideration of CBSE from different viewpoints
and focus on different aspects of software engineering such as:
 Different phases (design, implementation and run-time phases)

 Business aspects

 Architectural issues
 THE COMPONENT:
 SZYPERSKI
Szyperski defines a component precisely by enumerating its
characteristic properties as follows:

 A software component is a unit of composition with contractually specified

interfaces and explicit context dependencies only.

 A softwarecomponent can be deployed independently and is subject to

composition by third party.
IMPLICATIONS OF SZYPERSKI’S
DEFINITION
 The following implications arise as a result of Szyperski’s
definition:
 For a component to be deployed independently, a clear distinction from its
environment and other components is required.
 A component must have clearly specified interfaces.
 The implementation must be encapsulated in the component and is not
directly reachable from the environment .
THE COMPONENT: D'SOUZA AND
WILLS
 D'Souza and Wills define a component as:
A reusable part of software, which is independently developed, and
can be brought together with other components to build larger units. It
may be adapted but may not be modified.
A component can be, for example, a compiled code without a program
source, or a part of a model and/or design.
OBJECTS AND
COMPONENTS
 Szyperski
 View a component as a collection of objects,
in which the objects co-operate with each
other, and are intertwined tightly.

 D'Souza and Wills

 Assert that if a class were packaged together
with the explicitly defined interfaces which it
requires and implements, then this class
would be a component.
DESCRIBING A COMPONENT
 To be able to describe a component completely the
component should consist of the following elements:
A set of interfaces provided to, or required from the
environment.
 Anexecutable code, which can be coupled to the code of
other components via interfaces.
IMPROVING A COMPONENT

 To improve the component quality, the

following elements can be included in the
specification of a component:
 Thespecification of non-functional
characteristics
 The validation code
 Additional information
INTERFACE
SAn interface of a component can be defined

as a specification of its access point,
offering no implementation for any of its
operations.
 Advantages:
 Replace the implementation part
without changing the interface
 Add new interfaces (and
implementations) without changing the
existing implementation
DESCRIBING AN INTERFACE
 Interfaces defined in standard component
technologies using techniques such as Interface
Definition Language (IDL) are:
 Sufficient in describing functional properties
 Insufficient in describing extra-functional
properties such as quality attributes like:
 Accuracy
 Availability
 Latency
 Security
EXPORT AND IMPORT
INTERFACES
 We can distinguish two kinds of interfaces.
Components can export/import interfaces
to/from environments which may include
other components.
 An exported interface describes the
services provided by a component to the
environment.
 An imported interface specifies the services
required by a component from the
environment.
PATTERN
SPatterns definesolutions
 to recurring problems
capturing non- solutions, not just abstract
obvious
principles or strategies.

 The solutions should be proven to solve the problem rather than

being theories or speculations.

 Patterns describe relationships between deeper

system structures and mechanism.

 A component, as a reusable entity, can be seen as a realization

of some design pattern.

19
CATEGORIES OF
PATTERNS
 Patterns can be classified into three
categories:
major
 Architectural Patterns, capture the overall
structure and organization of a software system.
 Design Patterns, refine the structure and
behavior of the subsystems the
components as well as the
of exist
relationships which a between
software
them.
 Idioms,
system, and the
are low-level patterns which are
dependent
on the chosen paradigm and the
programming language used.
20
 DESIGN PATTERNS
 Design patterns are widely used in the process of designing component-based
systems in which the reusable units must be identified.

 By using design patterns, it is easier to recognize those reusable parts and

either find them in the form of pre-existing components, or develop them as
reusable units.

21
 SOFTWARE
FRAMEWORKS
 CBSE means that we build software by "putting pieces together".

 Frameworks provide the context in which the pieces can be

used.

 A framework may be seen as:

 A reusable design of a system

 A skeleton of an application which can be

customized by an application developer

22
COMPONENT FRAMEWORKS
 Frameworks in general describe a
typical and reusable situation at a
model level.

Compone
Coordination Services (transactions, nt
persistence..) Framewo
rk

 A component framework describes a

“circuit- board” with empty slots into
which components can be inserted to
create a working instance.
23
COMPONENT MODELS
 The two concepts Component Models and Component Frameworks are
sometimes intermixed.
 A component model defines a set of standards and conventions
used by the component developer.

 A component framework is a support infrastructure for the component

model.

Component
model

24
RELATIONSHIPS BETWEEN CONCEPTS

Interface that satisfies contracts

Component-type Component
Specific interface implementation

Independent Component
model
deployment

Component
Coordination Services (transactions, persistence..)
Framework

25
FRAMEWORKS AND
CONTRACTS
 Frameworks focus on the overall
properties of component compositions.
 Contracts give specifications for
relationships between concrete
components.
 Thesespecifications may be different for
components within one composition.

26
FRAMEWORKS AND
PATTERNS
 It is important to that
realize patterns
design and frameworks
concepts of different natures.
are distinct
 Design patterns are of a logical
representing
nature, knowledge of and
experience gained with software.
 Frameworks are of a physical nature, and are
executable software used in either the design
or the run-time phase.
27
FRAMEWORKS AND
PATTERNS
 The major differences between
design patterns and frameworks are as
follows:
 The level of abstraction of frameworks
and design patterns
 Design patterns are smaller
architectural elements than frameworks
 The level of specialization of frameworks and
design patterns.
28
 CHARACTERISTICS OF COMPONENT-BASED SOFTWARE
ENGINEERING
Some primary characteristics of CBSE are listed
Reusability: Reusability is the focal property of CBSE. Software
reusability is “the process of creating software systems from existing
software rather than building them from scratch.” Software reuse is the
process of integrating predefined specifications, design architectures,
tested code, or test plans with the proposed software.
Composability: One of the fundamental characteristics of CBSE is that
the components are the reusable, composable software entities, that is,
applications are composed of different individual components. These
individual reusable components are designed in such a way that they
can be reused in composition with other components in various
applications with minimum or no fabrication. Components are composed
of components, that is, a component is itself made up of components,
which are further made up of other components, and so on (Atkinson et
al. 2002). A component can be a part of one or more components
Shorter development cycle: The component-based development paradigm follows
the “divide, solve and conquer” approach. In this paradigm, complex and bulky
applications are divided into smaller, more manageable units or modules. Then, rather
than starting coding of a complete module from the first line, existing elements are
sought and assembled that satisfy the requirements of the module under consideration.
This increases software development speed. In addition, several modules can be
implemented concurrently, regardless of location or context. Thus, development time is
saved and the development cycle becomes shorter.
Maintainability: The effort required to add new functionalities to the application, or
modify, update or remove old features from the software, is referred to as the
maintenance. Since CBSE-based software is made up of reusable and replaceable
components, we can add, update, remove or replace components according to the
requirements of the software. Maintaining composable and independent components is
much easier than maintaining monolithic software.
 This regressive form of testing makes component-based applications more robust and
improves the quality of the product. More broadly, the effort, cost and time of testing
are noticeably reduced. Components are independently developed, deployed in various
contexts at the same time with minimal or no fabrication and integrated according to
the predefined architecture; hence, it is assumed that there are no unwanted
interactions among the components to make them unreliable. All the interaction paths
are predefined so the reliability and predictability of components is increased
Flexibility and extendibility: Software developers have the
choice of customizing ,assembling and integrating the components
from a set of available components according to their
requirements. Replaceable and composable components are easy
to add, update, modify or remove from the application without
modifying other components Error navigation and fixing are
relatively easy as it is limited to component level only.
 COMPONENTIZATION
 Componentization is the method of identifying the quantity of components in a
specific application developed through component-based development.
 Componentization addresses the issue of maintaining a balance between the number
of components and the complexity factors of the system. Essentially, the level of
componentization is equivalent to the level of requirement sufficiency.
 In determining the level of requirement sufficiency, we consider as many
components as are adequate to solve the software application’s intention. Figure
illustrates componentization vs integration cost.
 If we divide the problem into a large quantity of components providing small
functionalities, it will increase both the cost of integration and the interaction effort.
Not only the cost but also the number of interactions, the coding complexity, testing
effort and number of duplicate test cases will also increase.
 If an application is componentized with fewer components each providing a number
of functionalities, it will cost in terms of testing as well as maintenance. It is desirable
to achieve a minimum cost region so that cost and effort can be balanced against the
number of component.
COMPONENTS
 A component is an identifiable, functionally reusable unit
(element/part/piece/ package) of a larger software system.
 A component is developed independently.
 A component is delivered and deployed in a context-free
environment.
 A component interacts with other components through well-
defined interfaces to access and to provide services.
 A software component can be a replaceable, modifiable piece
of code that can be integrated with other replaceable,
modifiable components.
 TYPES OF COMPONENTS
 There are three classes of component:

Off-the-shelf components: In this category, components are pre-

developed, pre-tested and can be reused without any modification. Off-
the-shelf components are either made available by the third party or
selected from the repository. Components residing in the repository are
constructed by the developers of the organization as part of previously
developed software. Off-the-shelf components are like black-box
components, as the developers can use or reuse them without reference
to the idiosyncrasies and internal details of that component. As their
code and internal structure are not available, interfaces of such
components should be self-descriptive, that is, their interaction details
must be defined in their interfaces. These components can be deployed
in a context-free environment without making any change or
modification. Off-the shelf components are also known as commercial off-
the-shelf (COTS) components.
Adaptable components: Components in this category are assembled with
existing software artifacts including application requirements, architectural
design, available code or pre-built test cases with small or large
modifications. We can divide adaptable components into two broad classes:
fully qualified components and partially qualified components. This division
is based on the degree of modifiability of the component. Fully qualified
components need no alteration or a minimum amount of alteration. They can
be reused at their maximum extent with minimum modification. The
modification requirement depends on the current application requirement.
Partially qualified components need a greater degree of alteration. These
components can be reused in the application under consideration with major
modifications.
New components: New components are those that are engineered by the
organization’s developers from the first line of code to the last, considering
the requirement specification of the specific software application. New
components are developed when neither off-the-shelf nor adaptable
components satisfy the requirements of the software system. In CBSE,
components are developed in such a way that they can be reused in various
applications. Newly developed components are submitted to the repository
for future use.
 CHARACTERISTICS OF
COMPONENTS
 To gain as well as to provide valuable information, components require
fundamental properties: interfaces, services and deployment techniques.
three

Interface: To provide and to access information and services, components require

some sort of intermediary between them, that is, an interface. An interface is a
medium which defines how a component can interact with other components. It
states the communication structure, limits and parameters and also describes the
form and structures of the result.
In CBSE, developers use interfaces to assemble and create interactions among the
dependent and independent components. Interfaces define the mode of coupling
between two or more components. The signature (data type, count) of
corresponding parameters and the nature of the communication among the
components decide the type and mode of coupling. Components use interfaces to
pass the control sequence from one component to others, to acquire and provide
files and data, and to transmit instructive information to each other. When
components are integrated through various coupling techniques to contribute their
services and functionalities to the whole system, the interface is the medium that
provides the method of interaction among these components
Services: To survive in a system, every component must have to provide
some desired and defined service (set of services) or functionality (set of
functionalities). In component- based software systems, the service
specifies a component’s role in the system.
 When developers select a component from the repository, one of the basic
selection criteria is the service that it will provide to other components and
to the system. In addition, when components are stored in the repository,
the basic aim is to reuse their services in future applications. A
component’s service consists not only of its functional behavior but also of
the functional procedures that would be assembled with other pre-existing
components
 In the context of CBSE, it is clear that

• Services must have some specific and defined purpose,

• Services should exhibit robust behavior,
• Services should be reliable,
• Services should exhibit efficiency in terms of performance and
adaptability.
 Deployment Techniques: In component-based development, components are
deployable units. Therefore, it is necessary to have a deployment technique for
every component. Deployment techniques are the methods through which a
component is customized for the purpose of its implementation. If component’s
source code is available, customization is achieved through its executable code,
or otherwise through its interface.
 Deployment techniques conform to the syntax and semantics of the language in
which the component was developed. In the context of black-box and context-
free components, generally internal details are not available with the
component. In such cases, interfaces play a major role in the deployment. To
make deployment effective, interfaces must be robust and reliable.

When a large and complex system is to be developed, it is divided into

comparatively small manageable pieces. In component-based systems,
components represent these small pieces. Components are replaceable,
modifiable pieces of code that can be integrated with other replaceable,
modifiable components. To address the requirements of the system, it is essential
to partition and modularize these requirements. Modularization must be done in
such a way that each component represents a specific requirement (or set of
requirements)
COMPONENT REPOSITORY
In CBSE, reusability not only applies at the time of development but is also maintained after
development. When components are developed by the development team, developed/
contracted by the third party or purchased, they must be stored in the repository for future
use. The repository is the component database which contains the following:
a. Coding of the component
b. Metadata of the component
c. Components interface
d. Other information about the component
Repositories need to be regularly maintained to ensure their consistent efficiency. Repository
maintenance is one of the major concerns in CBSE. Some major issues associated with
component repositories are as follows:
a. Identifying useful and outdated components to update the repository.
b. Updating components, that is, elimination of outdated components and inclusion of new
components in the repository.
c. Updating component metadata and other information.
d. Keeping different versions as well as updating versions of the same components without
duplication or ambiguity.
COMPONENT SELECTION

 The selection of appropriate components for the proposed software is crucial in many respects.
Proper and accurate selection of components makes the software economic, helps to shorten
development time, increases reliability and makes the overall development much smoother.
 However, in order to select one component from a number that are available with similar
intentions, selection and verification criteria are needed. At present the only criteria available
for component selection are the customer requirements. Developers generally look for a
component that fits into the software design without considering other selection parameters.
Apart from the requirements, major issues in component selection are:
a. Selection based on the level or degree of reusability of components.
b. Selection based on the reliability issues of the component.
c. Selection based on the increased/decreased level of complexity in the overall software.
d. Selection based on the component testing efforts.
e. Selection based on the scope of maintenance of the component.
f. Selection based on the scope of scalability in the component
 COMPONENT
INTERACTION
 In component-based software development, interaction among components is necessary as they
are integrated to provide features and functionalities for the proposed software.
 Components are designed to interact with each other according to the requirements of the
software. Component interaction is not only necessary but plays a crucial role in the design of the
software architecture. Components are assumed to be context independent, language
independent and vendor independent. Researchers have used various methods, including graph
theory notation, to show the interaction among components. UML includes component interaction
diagrams to denote such interactions. Some fundamental issues with the interaction of
components are as follows:
a. Interactions among components generate complexity in the software. The aim is to reduce
interaction complexity among components.
b. It is necessary to define the interaction mechanism, parameters or methods among components.
c. There is a need for common interfaces to make an interaction between two components.
d. Interaction of components invokes integration-related issues including integration testing and
regression testing.
e. Interaction can introduce new software errors which may increase the testing and debugging
schedule and cost.
f. Appropriate and well-defined metrics are needed to assess these interactions so that the
contribution of components can be justified.
 COMPONENT DEPENDENCY
 Interaction and integration among components create dependencies among them.
 Components depend on each other for functionalities and services. Component
dependency governs the level of coupling among the components. As the
dependency increases, interaction among components will also increase. These
interaction dependencies generate complexity in the software architecture.
Components can be dependent on each other for various reasons, including:
i. Dependency due to data sharing
ii. Temporal dependency
iii. Dependency due to controlling the flow of execution
iv. Sharing of the same state or state dependency
v. Dependency due to providing input or due to receiving output
vi. Context dependency
vii. Interface dependency
Major issues in the context of component dependencies are as follows:
a. Dependency among components should be kept to a minimum if it
cannot be eliminated completely.
b. Notation of dependency in the design of software should be
unambiguous.
c. Presentation of dependency in the implementation of software
should be clearly defined.
d. There should be clearly defined and appropriate metrics to assess
the dependency among components.
e. Dependencies generate complexity overheads in the overall
software architecture . Extra care is required to implement and assess
component dependencies.
COMPONENT
COMPOSITION
 Composition defines the capability of the component to be integrated with other components.
Composition among components results in component-based software. The property of
composability defines the usability of the component in the software. It is one of the
fundamental properties of the component. Overall behavior of the software depends on the
flexibility or rigidity of the components in respect of composability.
 Composition allows the component to behave according to the structure of the design. The
composition of a component is its individual property. In component-based software
development, components are assumed to be self-composable as well as composable
independently.
 Some basic issues regarding component composition are:

a. Composability state, that is, local or global, should be clearly defined.

b. Composing one component with other components should not affect the properties of those
components.
c. No standard method or technique is available for composability of a component. Defining a
methodology to fit all the components in the software is a big challenge.
d. Specific components require specific interfaces. In such cases, the number of interfaces
becomes an overhead in terms of cost and complexity.
e. Semantics of the components should be containable so that the process of composition is
easier