COMPONENT-BASED

SOFTWARE ENGINEERING

Pradeep Tomar

5 February 2019 1
 Challenges to Software
Industry
More reliable software
􀁺
More efficient software

􀁺 More maintainable software

􀁺 More effective software development

5 February 2019 2
 Solution to These Challenges

REUSE

5 February 2019 3
 Why Reuse?
Minor Reason
􀁺 Design, implementation and testing are expensive
􀁺 Reuse can save design, coding and testing cost.

Major Reason
􀁺 Maintenance (two-thirds of the overall cost)

5 February 2019 4
 REUSE PRACTICE
 Application system reuse
Widely practised as software systems are implemented as
application families. COTS reuse is becoming increasingly
common.
 Component reuse
Now seen as the key to effective and widespread reuse
through component-based software engineering. However,
it is still relatively immature.
 Function reuse
Common in some application domains (e.g. engineering)
where domain-specific libraries of reusable functions have
been established.

5 February 2019 5
 Reuse Require
Generality Usable in verity of situation

Adaptability Alternate to suite may situation

Efficiency In time or space

Intutiveness Attractive for other to use

5 February 2019 6
 REUSE PROCESS

Design Search for Incorporate

Specify
system Reusable discovered
Component
Architecture Component components

5 February 2019 7
 Reuse and Maintenance

5 February 2019 8
 GOAL OF REAUSABILITY
• Goals of reuse are primarily economic.
Save cost/time/effort of redundant work, increase
productivity.
Decrease time to market.
Improve systems by reusing both the artifact and the
underlying engineering experience.
• Economic goals achieved only when units of reuse.
reach critical mass in size, capability and
uniformity.

5 February 2019 9
BENEFITS OF REUSABILITY
 Increased reliability.
• Components exercised in working systems.
 Reduced process risk.
• Less uncertainty in development costs.
 Effective use of specialists.
• Reuse components instead of people.
 Standards compliance.
• Embed standards in reusable components.
 Accelerated development.
• Avoid original development and hence speed-up
production.

5 February 2019 10
 First Generation of Software
Reuse
Structure-oriented software development
􀁺 Basic Reusable Unit –Module
􀁺 Scope –In a particular application of system
􀁺 Implicit dependency on specific technology and a
operational system environment
􀁺 Reusable function library
􀁺 Structured analysis and design approaches
􀁺 Structured programming languages and traditional testing
approaches.

5 February 2019 11
 Second Generation of Software
Reuse
Object-Oriented Software Development
􀁺 Basic Reusable Unit –Class
􀁺 Scope –In a particular domain
􀁺 Implicit dependency on specific technology and a operational system
environment
􀁺 Reusable object-oriented class library, design pattern and etc.
􀁺 Objected-oriented analysis and design approaches
􀁺 Objected-oriented programming languages and testing approaches.

5 February 2019 12
 Third Generation of Software
Reuse
Component-based software development
􀁺 Basic Reusable Unit –Component
􀁺 Scope –In any domain
􀁺 No dependency on specific technologies or specific operational
system environments
􀁺 Reusable components
􀁺 Component-based analysis, design, development, assembly and
deployment process.

5 February 2019 13
 COMPONENT-BASED
SOFTWARE ENGINEERING
• Component-Based Software Engineering (CBSE) and
Component-based development can be integrated into a
standard software process by incorporating a reuse activity in
the process.
• It emerged from the failure of object-oriented development to
support effective reuse. Single object classes are too detailed
and specific.
• Components are more abstract than object classes and can be
considered to be stand-alone service providers.
• CBSE usually involves a prototyping or an incremental
development process with components being ‘glued together’
using a scripting language

5 February 2019 14
 CBSE
CBSE is about building software through composition. Assumes
existence of components that can be readily employed under new
development

CBD is about development of component

CBD is part of CBSE activity

CBSE is based on the idea to develop software systems by

selecting appropriate off-the-shelf components and then assemble
them with a well-defined software architecture.

5 February 2019 15
 CBSE has three major
functions:
Developing software from prefabricated, reusable parts.

The ability to use those parts in other applications.

Easily maintaining and customizing those parts to produce

new functions and features.

5 February 2019 16
5 February 2019 17
 CBSE

Component Based Software Engineering has same goal for

software that Henry Ford had for automobiles.

In short the goal is to improve software Quality:

maintainability, flexibility, quality, cost, etc.

The long term goal is to enhance Software Reusability.

5 February 2019 18
 CBSE
Component-based software engineering (CBSE) is an
approach to software development that relies on software
reuse.

It emerged from the failure of object-oriented development

to support effective reuse.
Single object classes are too detailed and specific.

Components are more abstract than object classes and can

be considered to be standalone service providers.

5 February 2019 19
 COMPONENT-BASED SOFTWARE
ENGINEERINIG

CBSE = COA + COD + COP + COM

COA : COMPONENT ORIENTED ANALYSIS

COD : COMPONENT ORIENTED DEVELOPMENT
COP : COMPONENT ORIENTED PROGRAMMING
COM : COMPONENT ORIENTED MANAGEMENT

5 February 2019 20
 Component-Based Software
Engineering
• Based on systematic reuse where systems are integrated from
existing components or COTS (Commercial-off-the-shelf)
systems.
• Process stages
• Component analysis;
• Requirements modification;
• System design with reuse;
• Development and integration.
• This approach is becoming increasingly used as component
standards have emerged.

5 February 2019 21
 CBSE AND CBSE PROCESSES
CBSE is a branch of software engineering which emphasizes the
separation of concerns in respect of the wide-ranging functionality
available throughout a given software system.

Two processes occur in parallel during the CBSE process:

Domain Engineering

CBD Processes.

5 February 2019 22
 CBSD AND CBSD PROCESSES
Component-based software development is an emerging discipline that
promises to take software engineering into a new era. Building on the
achievements of object-oriented software construction, CBD aims to deliver
software engineering from a cottage industry into an industrial age for
Information Technology, wherein software can be assembled from
components, in the manner that hardware systems are currently constructed
from kits of parts.

The CBSD consists of two separate but related processes

Development for Reuse

Development with Reuse

5 February 2019 23
 COMPONENT-BASED
SOFTWARE ENGINEERINIG
Development for Reuse
From Scratch

Development with Reuse

Development with modification
Development without modification

5 February 2019 24
 Development for Reuse
• Define and classify client requirement with the help of application,
interface, and support.

• Search repository for reusable and testable components that support the
requirements.

• Analyse candidate component to ensure there is an acceptable match

between them and the requirements.

• Develop CBS on standard component model.

• Incorporate the reuse methodology into system development life cycle.

5 February 2019 25
 Development with Reuse
• The process of defining requirement for a CBS.

• The process of partitioning software requirements into logical components

or “sub-systems”.

• The process of replacing abstract design components with “concrete” off-

the-shelf components.

• The verification process is intended to ensure that there is an acceptable

match between the software component used to build the software and the
software being built.

5 February 2019 26
 CBSE takes different approaches from
the conventional software reuse
• Component should be able to plug and play with other component so that
component can be composed at run-time without compilation.

• Component should separate the interface from the implementation and hide
the implementation.

• Component is designed on a pre-defined architecture so that they can

interoperate with other component.

• Component interface should be standardized so that they can be developed

by multiple developers and widely reused across the corporations.

• Component can be acquired and improved by getting feedback from users

and end users.

5 February 2019 27
 CBSE Essentials
Independent components specified by their interfaces.

Component standards to facilitate component integration.

Middleware that provides support for component inter-

operability.

A development process that is geared to reuse.

5 February 2019 28
 ADVANTAGES
OF
COMPONENT-BASED SOFTWARE DEVELOPMENT
• Application softwares can be developed more quickly.

• Results are of higher quality and more reliable.

• Cheaper than traditional development.

• Help in reusability of Core functionality of software.

• Encapsulates Organizational best practices.

• Flexibility in choice of tools and languages.

5 February 2019 29
 SOFTWARE COMPONENT
Components provide a service without regard to
where the component is executing or its
programming Language.
• A component is an independent executable entity that can be
made up of one or more executable objects.
• The component interface is published and all interactions are
through the published interface.

Components can range in size from simple functions

to entire application systems.

5 February 2019 30
 COMPONENT
A component is a nontrivial, nearly independent, and replaceable part of a
system that fulfills a clear function in the context of a well-defined architecture.

Software component are binary units of independents production, acquisition

and deployment that interact to form a functioning system.

A component is a unit of compositions with contractually specified interfaces

and explicit context dependencies only. A software component can be deployed
independently and is subject to composition by third parties

5 February 2019 31
 COMPONENT
A component is a .NET class
Shell …… Interface

White …… Code example, this is a .NET component

public class MyClass

Yolk ……. Data {
public string GetMessage( )
{
return "Hello";
}
}

5 February 2019 32
 JAVA Components are
Classes

Interfaces

5 February 2019 33
 COMPONENT
The term component is probably one of the most overloaded and therefore most
confusing terms in modern software engineering, and the .NET documentation has its
fair share of inconsistency in its handling of this concept. The confusion arises in
deciding where to draw the line between a class that implements some logic, the
physical entity that contains it (typically a DLL), and the associated logic used to
deploy and use it, including type information, security policy, and versioning information
(called the assembly in .NET). A component is a .NET class. For
example, this is a .NET component:

public class MyClass

{
public string GetMessage( )
{
return "Hello";
}
}

5 February 2019 34
 COMPONENT
According to
(Philippe Krutchen, Rational Software)
A component is a nontrivial, nearly independent,
and replaceable part of a system that fulfills a
clear function in the context of a well-defined
architecture. A component conforms to and
provides the physical realization of a set of
interfaces.

5 February 2019 35
 COMPONENT
According to
(Gartner Group)
A runtime software component is a dynamically
bindable package of one or more programs
managed as a unit and accessed through
documented interfaces that can be discovered at
runtime.

5 February 2019 36
 COMPONENT
According to
(Clemens Szyperski )

A software component is a unit of composition

with contractually specified interfaces and explicit
context dependencies only. A software component
can be deployed independently and is subject to
third-party composition.

5 February 2019 37
 COMPONENT
According to
(Wojtek Kozaczynski, SSA)
A business component represents the software
implementation of an “autonomous” business concept or
business process. It consists of the software artifacts
necessary to express, implement, and deploy the concept
as a reusable element of a larger business system.

5 February 2019 38
 Components could be classified
into five different forms
Component Specification

Component Interface

Component Implementation

Installed Component

Component Object

5 February 2019 39
 INSTALLED COMPONENT
The installed form is an installed (or deployed) copy of a
component implementation.

A component implementation is deployed by registering

it with the runtime environment.

This enables the runtime environment to identify the

installed component to use when creating an instance of
the component or when running one of its operations.

5 February 2019 40
 COMPONENT OBJECT
A component object is an instance of an installed
component.
This is a runtime concept. Similar to OOP, a component
object in COP is an object with its own data and a unique
identity, which performs the implemented behavior.

An installed component may have multiple component

objects (which require explicit identification) or a single
one (which may be implicit).

5 February 2019 41
COMPONENT SPECIFICATION
This form represents the specification of a unit of
software that describes the behavior of a set of
component objects and defines a unit of implementation.

Behavior is defined as a set of interfaces.

A component specification is realized as a component

implementation.

5 February 2019 42
 COMPONENT INTERFACE

The interface form presents a definition of a set of

behaviors that can be offered by a component object.

5 February 2019 43
 COMPONENT
IMPLEMENTATION
The implementation form is a realization of component
specification, which is independently deployable.

This means it can be installed and replaced independently

of other components. It does not mean that it is
independent of other components – it may have many
dependencies.

It does not necessarily mean that it is a single physical

item, such as a single file.

5 February 2019 44
 Component Characteristics

5 February 2019 45
 Component Characteristics

5 February 2019 46
 STEPS IN COMPONENT-BASED
SOFTWARE DEVELOPMENT PROCESS
• Find components which may be used in the system.
• Select the components which meet the requirements of the
system.
• Alternatively, create a proprietary component to be used
in the system.
• Adapt the selected components so that they suit the
existing component model or requirement specification.
• Compose and deploy the components using a framework
for components. Replace earlier with later versions of
components.

5 February 2019 47
 CBSE: CHALLENGES
• Trusted components
• Component certification
• Composition predictability
• Requirements management and component selection
• Development models
• Long-term management of component-based systems
• Component configurations
• Dependable systems and CBSE
• Tool support

5 February 2019 48
 Lifecycle of a Component
based System

5 February 2019 49
 COMPONENT-ORIENTED
PROGRAMMING
Component-oriented programming enables
programs to be constructed from prebuilt
software components, which are reusable, self-
contained blocks of computer code.
These components have to follow certain
predefined standards including interface,
connections, versioning, and deployment.

5 February 2019 50
 COMPONENT-ORIENTED
PROGRAMMING
Component-oriented application comprises a collection of
interacting binary application modules that is, its components
and the calls that to bind them.

Component-enabling technologies such as COM, J2EE,

CORBA, and .NET provide the “plumbing” or infrastructure
needed to connect binary components in a seamless manner, and
the main distinction between these technologies is the ease with
which they allow you to connect those components.

5 February 2019 51
 COMPONENT-ORIENTED
PROGRAMMING
Others may be highly specialized and developed specifically for
the application. An application implements and executes its
required business logic by gluing together the functionality
offered by the individual components.

Component-enabling technologies such as COM, J2EE,

CORBA, and .NET provide the “plumbing” or infrastructure
needed to connect binary components in a seamless manner, and
the main distinction between these technologies is the ease with
which they allow you to connect those components.

5 February 2019 52
 COMPONENT-ORIENTED
PROGRAMMING
Component-oriented programming promotes black box reuse
instead, which allows you to use an existing component without
caring about its internals, as long as the component complies
with some predefined set of operations or interfaces.

Instead of investing in designing complex class hierarchies,

component-oriented developers spend most of their time
factoring out the interfaces used as contracts between
components and clients.

5 February 2019 53
 COP vs. OOP
 Object Oriented Programming = Polymorphism + (Some) Late
Binding + (Some) Encapsulation + Inheritance

Java uses late-binding to support polymorphism; which means the

decision as to which of the many methods should be used is
deferred until runtime "
Java's use of late-binding which allows you to declare an
object as one type at compile-time but executes based on the actual
type at runtime "
 Component-Oriented Programming = Polymorphism + (Really)
Late Binding + (Real, Enforced) Encapsulation + Interface
Inheritance + Binary Reuse

5 February 2019 54
 COP vs. OOP
COP is interface-based, while OOP is object-based.
COP is a packaging and distribution technology, while
OOP is an implementation technology.
COP supports high-level reuse, while OOP supports low-
level reuse.
COP, in principle, can be written in any language, while
OOP is bound to OO languages.
COP has loosely coupled components, while OOP has
tightly coupled objects dependent on each other through
inheritance implementation.
5 February 2019 55
 COP vs. OOP
COP has large granularity components, while OOP has objects
as fine-grained units of composition.

COP supports multiple interfaces, and interface-oriented design,

while OOP does not provide clear relationship of interfaces
among superclasses and subclasses.

COP supports more forms of dynamic binding and dynamic

discovery, while OOP provides limited support for object
retrieval and runtime composition mechanisms.

COP has better mechanisms for third-party composition, while

OOP has limited forms of connectors (method invocation).
5 February 2019 56
 COP vs. OOP
COP provides more support for higher-order services (security,
transactions, etc.), while OOP has limited sets of supported
services such as security, transactions, and so on.

COP components are designed to obey rules of the underlying

component framework, while OOP objects are designed to obey
OO principles.

5 February 2019 57
 Principles of Component-Oriented
Programming
Separation of interface and implementation
Binary compatibility
Language independence
Location transparency
Concurrency management
Version control
Component-based security

5 February 2019 58
 Separation of interface and
implementation
The fundamental principle of component-oriented programming
is that the basic unit in an application is a binary-compatible
interface.

The interface provides an abstract service definition between a

client and the object.

This principle contrasts with the object-oriented view of the

world that places the object rather than its interface
at the center.

5 February 2019 59
 Separation of interface and
implementation
An interface is a logical grouping of method definitions that acts
as the contract between the client and the service provider.

Each provider is free to provide its own interpretation of the

interface—that is, its own implementation.

The interface is implemented by a black-box binary component

that completely encapsulates its interior. This principle is known
as separation of interface from implementation.

5 February 2019 60
 BINARY COMPATIBILITY
Another core principle of component-oriented programming is
binary compatibility between client and server.
Traditional object-oriented programming requires all the parties
involved—clients and servers—to be part of one monolithic
application.
During compilation, the compiler inserts the address of the
server entry points into the client code.
Component-oriented programming revolves around packaging
code into components, i.e., binary building blocks.
This binary compatibility is the basis for the contract between
the component and the client. As long as the new version
of the component abides by this contract, the client isn’t affected.

5 February 2019 61
 BINARY COMPATIBILITY
Changes to the component code are contained in the binary unit
hosting it; you don’t need to recompile and redeploy the clients.

However, the ability to replace and plug in new binary versions

of the server implies binary compatibility between the client and
the server, meaning that the client’s code must interact at runtime
with exactly what it expects as far as the binary layout in
memory of the component entry points.

5 February 2019 62
LANGUAGE INDEPENDENCE

Unlike traditional object-oriented programming, in component-

oriented programming, the server is developed independently of
the client. Because the client interacts with the server only at
runtime, the only thing that binds the two is binary compatibility.

5 February 2019 63
LANGUAGE INDEPENDENCE
Language independence means exactly that: when you
develop and deploy components your choice of
programming language should be irrelevant.

Language independence promotes the interchangeability

of components, and their adoption and reuse.

.NET achieves language independence through an

architecture and implementation called the Common
Language Runtime (CLR)

5 February 2019 64
LOCATION TRANSPARENCY
A component-based application contains multiple binary
components.

These components can all exist in the same process, in different

processes on the same machine, or on different machines on a
network.

Recently, with the advent of web services, components can also

be distributed across the Internet.

5 February 2019 65
LOCATION TRANSPARENCY
The underlying component technology is required to
provide a client with location transparency, which
allows the client code to be independent of the actual
location of the object it uses.

Location transparency means there is nothing in the

client’s code pertaining to where the object executes.
The same client code must be able to handle all cases of
object location

5 February 2019 66
CONCURRENCY MANAGEMENT
A component developer can’t possibly know in advance all the possible ways
in which a component will be used and particularly whether it will be
accessed concurrently by multiple threads.

The safest course is for you to assume that the component will be used in
concurrent situations and to provide some mechanism inside the
component for synchronizing access.

However, this approach has two flaws. First, it may lead to deadlocks; if
every component in the application has its own synchronization
lock, a deadlock can occur if two components on different threads try to
access each other.
Second, it’s an inefficient use of system resources for all components
in the application to be accessed by the same thread.

5 February 2019 67
CONCURRENCY MANAGEMENT
The underlying component technology must provide a
concurrency management service—way for components to
participate in some application-wide synchronization
mechanism, even when the components are developed
separately.

In addition, the underlying component technology should allow

components and clients to provide their own synchronization
solutions for fine-grained control and optimized performance.

5 February 2019 68
 VERSIONING SUPPORT
Component-oriented programming must allow clients and
components to evolve separately.

Component developers should be able to deploy new versions

(or just fixes) of existing components without affecting existing
client applications.

Client developers should be able to deploy new versions of the

client application and expect it to work with older versions of
components.

5 February 2019 69
 VERSIONING SUPPORT
The underlying component technology should support
versioning, which allows a component to evolve along
different paths, and for different versions of the same
component to be deployed on the same machine, or side
by side.

The component technology should also detect

incompatibility as soon as possible and alert the client.

5 February 2019 70
 COMPONENT-BASED
SECURITY
In component-oriented programming, components are developed
separately from the client applications that use them.

Component developers have no way of knowing how a client

application or end user will try to use their work.

A benign component could be used maliciously to corrupt data

or transfer funds between accounts without proper authorization
or authentication.

5 February 2019 71
 COMPONENT-BASED
SECURITY
Similarly, a client application has no way to know whether it’s
interacting with a malicious component that will abuse the
credentials the client provides.

In addition, even if both the client and the component

have no ill intent, the end application user can still try to hack
into the system or do some other damage

5 February 2019 72
Components Represent Decomposition and Abstraction

Reusability Should Be Achieved at Various Levels

Component-Based Software Development Increases the Software

Dependability

Component-Based Software Development Could Increase the

Software Productivity

Component-Based Software Development Promotes Software

Standardization

5 February 2019 73
 Components Represent
Decomposition and Abstraction
To solve the complex problem in computer science we use
“divide and conquer.”
One major idea in component-based software development is to
create software modules that are themselves self-contained and
independently deployable.
Thus different developers will be able to work on different
components independently, without needing much
communication among themselves, and yet the components will
work together seamlessly.
In addition, during software maintenance phase, it will be
possible to modify some of the components without affecting all
of the others.

5 February 2019 74
 Domain Engineering
and
Component Engineering

5 February 2019 75
 Developing Components for
Reuse
• Components may constructed with the explicit goal to allow
them to be generalized and reused

• Component reusability should strive to

• reflect stable domain abstractions
• hide state representations
• be independent (low coupling)
• propagate exceptions via the component interface

5 February 2019 76
 Domain Engineering - part 1
• 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

5 February 2019 77
 Domain Engineering - part 2
• 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
• Repository of reusable components is created

5 February 2019 78
 What is Domain Engineering?
Domain Engineering (DE) is the activity of collecting, organizing, and
storing past experience in building systems or parts of systems in a
particular domain in the form of reusable assets, as well as providing an
adequate means for reusing these assets when building new system with
the following:
retrieval, qualification, dissemination, adaptation, assembly, and so on.
Steps:
• Domain Analysis

• Domain Design

• Domain Implementation

5 February 2019 79
 Domain Engineering
• The intent of domain engineering is to identify, construct,
catalogue, 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.

5 February 2019 80
 Domain Characteristics
• It is sometimes difficult to determine whether a potentially
reusable component is applicable in a particular situation. A
set of domain characteristics may be defined to make this
determination.

• A domain characteristic is shared by all software within a

domain. It defines generic attribute of all products that exist
within the domain. E.g., generic characteristics might include:
the importance of safety/reliability, programming language,
concurrency in processing.

5 February 2019 81
 Software Development
based on DE
Domain Engineering

Domain System Family

Domain
Architecture
knowledge Domain Model Domain Domain
Analysis Design Implem.
Domain-specific
New Requirements
languages
Components
Generators

Custom Custom
New Requirements
Design Development
Customer
Needs
Requirements Product Integration
Analysis Features Configuration Product and Test
Product
Configuration

Application Engineering
5 February 2019 82
 A guide for identifying reusable
components
• Is the component functionality required on future
implementation?

• 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?

5 February 2019 83
 A guide for identifying
reusable components
• Does the hardware remain unchanged between
implementations?
• Can the hardware specifics be removed to another
components?
• Is the design optimized enough for the next
implementation?
• Can we parameterize a non-reusable components so
that it becomes reusable?

5 February 2019 84
 A guide for identifying
reusable components
• Is the component reusable in many implementations
with only minor changes?
• Is reuse through modification feasible?
• Can a non-reusable component be decomposed to yield
reusable components?

5 February 2019 85
 Domain Engineering’s
Components
Domain Engineering Process Component Main Purpose

Domain Analysis Domain analysis defining a set of reusable,

configurable requirements for the systems in
the domain

Domain Design Developing a common architecture for the

system in the domain and devising a
production plan

Domain Implementation Implementing the reusable assets, for example,

reusable components, domain-specific
languages, generators, a reuse infrastructure,
and a production plan

5 February 2019 86
 Domain Analysis
• Purpose:
• Select and define the domain of focus
• Collect the relevant domain information and integrate it
into a coherent domain model

• Sources of domain information:

• Existing systems, domain experts, textbooks,
experiments.....

5 February 2019 87
 The domain analysis process
• An 8 step approach to the identification and categorisation of
reusable components
• select specific functions/objects
• abstract functions/objects
• define a taxonomy
• identify common features
• identify specific relationships
• abstract the relationships
• derive a functional model
• define a domain language
5 February 2019 88
 Domain Model
• A domain model is an explicit representation of the common and the
variable properties of the system in a domain, the semantics of the
properties and domain concepts, and the dependencies between the
variable properties
• Domain model’s components:
• Domain Definition
• Defines:
• the scope of a domain and existing systems;
• rationale for including or excluding a given system.
• Domain Lexicon
• Domain vocabulary
• Concept models
• Concept’s descriptions (object diagrams, interaction, state….)
• Feature models

5 February 2019 89
 Domain Design and Domain
Implementation
• Purpose:
• To develop an architecture for the family of systems in
the domain and to devise a production plan

• Input – Application Engineering

5 February 2019 90
 Concepts
• Domain
• Infinite
• Domain as the “real world”
• An area of knowledge or activity characterized by a set of concepts and
terminology understood by practitioners in that area
• Domain as a set of systems
• knowledge “real world” + How to build software systems
• Domain: An area of knowledge
• Scoped to maximize the satisfaction of the requirements of its
stakeholders
• Includes a set of concepts and terminology understood by practitioners in
that area
• Includes the knowledge of how to build software systems in that area

5 February 2019 91
 Domain Scope and Scoping
• Horizontal scope
• How many different systems are in the domain?

• Vertical scope
• Which parts of these systems are in the domain?

• Encapsulated x Diffused domains

5 February 2019 92
 Component Engineering
For those requirements that are addressed with
available components, the following software
engineering activities must be done:
• Component qualification
• Component adaptation.
• Component composition.
• Component update.

5 February 2019 93
 Component Engineering
• Component engineering focuses on how to build quality
reusable software components.

• Though CBSE encourages the use of existing components, in

many cases building new components becomes a must to
enhance the component library.

• To create software components involves the integration of the

following techniques

5 February 2019 94
 Component Engineering
• Abstraction
• Hiding
• Functional independence
• Refinement
• Structured programming
• Object-oriented methods
• Testing
• SQA and correctness verification

5 February 2019 95
 Definition of Terms
• 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

5 February 2019 96
 Component qualification--
Definition
• 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) required for the
application.

5 February 2019 97
 Component qualification--
Factors to be considered
• 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 be reused
effectively in a new application.
• Among the many factors considered during
component qualification are:
• Application programming interface (API)

5 February 2019 98
 Component qualification--
Factors to be considered
• 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

5 February 2019 99
 Component Adaptation
• Software architecture represents design patterns that
are composed of components connections, and
coordination. In some cases, existing reusable
components may be mismatched to the architecture’s
design rules. These components must be adapted to
meet the needs of the architecture or discarded and
replaced by other more suitable components.
• For example, some components are configurable
through parameterisation.

5 February 2019 100

 Component adaptation--ideal
situation
• In an ideal setting, domain engineering creates a library of
components that can be easily integrated into application
architecture. The implication of “easy integration” is:
• that consistent methods of resource management have
been implemented for all components in the library;
• that common activities such as data management exist for
all components, and
• that interfaces within the architecture and with the
external environment have been implemented in a
consistent manner.

5 February 2019 101

 Component adaptation--
wrapping
• In reality, even after a component has been qualified for use in
an application architecture, it may exhibit conflicts in one or
more of the areas.

• To mitigate these conflicts, an adaptation technique called

“component wrapping” is often used.

5 February 2019 102

 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

5 February 2019 103

 Component Composition
• The process of assembling components to create a system.

• Composition involves integrating components with each

other and with the component infrastructure.

• Normally you have to write ‘glue code’ to integrate

components.

5 February 2019 104

 Composition Trade-offs
• When composing components, you may find conflicts
between functional and non-functional requirements,
and conflicts between the need for rapid delivery and
system evolution.
• You need to make decisions such as:
• What composition of components is effective for delivering
the functional requirements?
• What composition of components allows for future change?
• What will be the emergent properties of the composed
system?

5 February 2019 105

 Component Composition
Infrastructure Elements - part 1

• 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

5 February 2019 106

 Component Composition
Infrastructure Elements - part 2

• 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

5 February 2019 107

 Types of Composition
• Sequential composition where the composed components
are executed in sequence. This involves composing the
provides interfaces of each component.

• Hierarchical composition where one component calls on

the services of another. The provides interface of one
component is composed with the requires interface of
another.

• Additive composition where the interfaces of two

components are put together to create a new component.

5 February 2019 108

 Types of Composition

A A

A B

B B

(a) (b) (c)

5 February 2019 109

 Component Composition
• Architectural style again plays a key role in the way in
which software components are integrated to form a
working system.

• By identifying connection and coordination

mechanisms (e.g., run-time properties of the design),
the architecture dictates the component of the end-
product.

5 February 2019 110

 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 (usually a library of

specialized components) provides a model for coordination of
components and specific services that enable components to
coordinate with each other and perform common tasks.

5 February 2019 111

 Component Composition
• 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 mechanism should cover:

5 February 2019 112

 Component Composition
• human-to-software data transfer
• component-to-component data transfer, and
• data 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.

5 February 2019 113

 Component Composition
• Structured storage. Heterogeneous data contained in a
compound document should be organized and accessed as a
single data structure.

• Underlying object model. The object model ensures that

components developed in different programming languages
that reside on different platforms can be interoperable. I.e.,
objects must be capable of communicating across network.

5 February 2019 114

 Component Composition
• Most popular existing industrial standards for
component software include:
• OMG/CORBA

• Microsoft COM

• Sun javaBean

5 February 2019 115

 Component Update
• When systems are implemented with COTS
components, update is complicated by the imposition
of a third party. The organisation that developed the
reusable component may be outside the immediate
control of the software engineering organisation.

5 February 2019 116

 Classification of Components
• Software components can also be characterised 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 also
performance, reliability, usability, and other quality
factors conform to the requirements of the
system/product to be built.

5 February 2019 117

 Classification of Components
• Adapted Components —adapted to modify (wrapping)
unwanted or undesired characteristics.
• Assembled Components —integrated into an architectural
style and interconnected with an appropriate component
infrastructure that allows the components to be coordinated
and managed effectively.
• Updated Components —replacing existing software as
new versions of components become available.

5 February 2019 118

 The CBSE process
• The CBSE process includes to identify candidate
components, to qualify each component’s interface, to
adapt components to remove architectural mismatches, to
assembly components into a selected architectural style,
and to update 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.

5 February 2019 119

 The CBSE process
Domain Engineering

Domain Software Reusable

Analysis Architecture Component
Development Development

Repository
Domain Structural
Reusable
Model Model Artifacts/
Component
s

Component-Based
Development Component Component
Qualification Update
Architectural
Design Component
Analysis Adaptation Application
Software

Component
Composition

Component
5 February 2019 120
Engineering Testing
 CBSE Essentials
• Independent Components specified by their
interfaces.
• Component Standards to facilitate component
integration.
• Middleware that provides support for
component inter-operability.
• A Development Process that is geared to reuse.

5 February 2019 121

 CBSE and Design Principles
• Apart from the benefits of reuse, CBSE is based on sound
software engineering design principles:

• Components are independent so do not interfere with

each other;
• Component implementations are hidden;
• Communication is through well-defined interfaces;
• Component platforms are shared and reduce
development costs.

5 February 2019 122

 CBSE Problems
• Component trustworthiness - how can a component with
no available source code be trusted?
• Component certification - who will certify the quality of
components?
• Emergent property prediction - how can the emergent
properties of component compositions be predicted?
• Requirements trade-offs - how do we do trade-off analysis
between the features of one component and another?

5 February 2019 123

 Components
• Components provide a service without regard
to where the component is executing or its
programming language
• A component is an independent executable entity
that can be made up of one or more executable
objects;
• The component interface is published and all
interactions are through the published interface;

5 February 2019 124

 Component Definitions
• Councill and Heinmann:
• A software component is a software element that conforms
to a component model and can be independently deployed
and composed without modification according to a
composition standard.
• Szyperski:
• A software component is a unit of composition with
contractually specified interfaces and explicit context
dependencies only. A software component can be deployed
independently and is subject to composition by third-parties.

5 February 2019 125

 Component as a Service
Provider
• The component is an independent, executable entity. It does
not have to be compiled before it is used with other
components.

• The services offered by a component are made available

through an interface and all component interactions take
place through that interface.

5 February 2019 126

 Component Interfaces
• Provides interface
• Defines the services that are provided by the component
to other components.

• Requires interface
• Defines the services that specifies what services must
be made available for the component to execute as
specified.

5 February 2019 127

 Component Interfaces

Re quire s inte rfa ce Pro vides in te rfa ce

Defin es the services Defin es the services
fromthe component’s Co mpo nent th at are p rov ided
env iro nment th at it by the comp on en t
uses to oth er compo nen ts

5 February 2019 128

 Component Models
• A component model is a definition of standards for component
implementation, documentation and deployment.
• Examples of component models
• EJB model (Enterprise Java Beans)
• COM+ model (.NET model)
• CORBA Component Model
• The component model specifies how interfaces should be defined
and the elements that should be included in an interface definition.

5 February 2019 129

 Component Models
• The component model illustrates the software components
that will be used to build the system.

• These may be built up from the class model and written from
scratch for the new system, or may be brought in from other
projects and 3rd party vendors.

• Components are high level aggregations of smaller software

pieces, and provide a 'black box' building block approach to
software construction.

5 February 2019 130

 Elements of a Component
Model
Custo misation
Naming
con ven tion
Co mpo sitio n Do cumentatio n

In terface Specific M eta-data Ev olution

Packagin g
definition in terfaces access supp or t

Usage Deploy men t

In terfaces
in formatio n and use
Co mpo nent mo del

5 February 2019 131

 Interface Incompatibility
• Parameter incompatibility where operations have the same
name but are of different types.

• Operation incompatibility where the names of operations

in the composed interfaces are different.

• Operation incompleteness where the provides interface of

one component is a subset of the requires interface of
another.

5 February 2019 132

 Middleware Support
• Component models are the basis for middleware that
provides support for executing components.
• Component model implementations provide:
• Platform services that allow components written according to
the model to communicate;
• Horizontal services that are application-independent services
used by different components.
• To use services provided by a model, components are
deployed in a container. This is a set of interfaces
used to access the service implementations.

5 February 2019 133

 Component Model Services
Ho rizon tal services

Co m po nent Transactio n Reso urce

m anagem ent m anagem ent m anagem ent

Co ncurrency Persistence Security

Platfo rm services

In terface Ex cep tio n Co m po nent

Addressing
definition m anagem ent com m unicatio ns

5 February 2019 134

 Frameworks
• Frameworks are sub-system designs containing a collection of
abstract and concrete classes along with interfaces between
each class

• A sub-system is implemented by adding components to fill in

missing design elements and by instantiating the abstract
classes

• Frameworks are reusable entities

5 February 2019 135

 Framework Classes

• System Infrastructure Frameworks

• support development of systems infrastructure elements like
user interfaces or compilers
• Middleware Integration Frameworks
• standards and classes that support component communication
and information exchange
• Enterprise Application Frameworks
• support development of particular applications like
telecommunications or financial systems

5 February 2019 136

 Frameworks
• In frameworking, the software engineer might have a sketchy idea
about components for reuse. On the other hand, as frameworks
comprise sets of components that express a design for a family of
related applications.

• A framework could be viewed as a generic structure that provides a

skeleton for producing software in a certain application domain.

• Frameworking attempts to identify components and establish

interrelationships perceived important within the application
domain

5 February 2019 137

 Frameworks
Identification of components may arise from the well-known functionality common to that
application domain, usually in the form of semantic relationships between components.

Consider, for example, the application domain of airline reservation systems; typical entities of
these systems are - seats, flights, crews and passengers; and interrelationships can be - reserve a
seat, assign a crew to a flight, schedule a flight and so on.

So, there are important relationships among these entities, which can be organized into a
framework according to their semantic meaning in that application domain.

Building software by using frameworking is faster and easier than starting from scratch, although
frameworks will not be as generally useful outside their application domain because they contain
domain-dependent components.

Within the proposed life cycle model, the main result of the frameworking phase should be the
reuse of software components already developed and the classification of components to form
new frameworks.

5 February 2019 138

 Extending Frameworks

• Generic frameworks need to be extended to create

specific applications or sub-systems
• Frameworks can be extend by
• defining concrete classes that inherit operations from abstract
class ancestors
• adding methods that will be called in response to events
recognized by the framework
• Frameworks are extremely complex and it takes time
to learn to use them (e.g. DirectX or MFC)

5 February 2019 139

 Component Abstraction
Component abstraction is a technique that groups related low-level
constants of a planning problem into more abstract entities called
abstract components or, shorter, components.

The idea is similar to how humans can group features connected

through static relationships into one more abstract unit.

For example, a robot that carries a hammer could be considered a

single component, which has mobility as well as maintenance skills.
Such a component can become a permanent object in the
representation of the world, provided that no action can invalidate the
static relation between the robot and the hammer.

5 February 2019 140

 Component Abstraction
• Component abstraction is a two-step procedure:

• Build the problem's static graph, which models

permanent relationships between constant symbols of a
problem.

• Build abstract components with a clustering procedure.

Formally, an abstract component is a connected
subgraph of the static graph.

5 February 2019 141

Component Abstraction Level
behavior,

dataflow,

and structure

5 February 2019 142

 THANKS

Pradeep Tomar

5
2/5/2019
February 2019 143