Professional Documents
Culture Documents
Component-Based Software Engineering Pradeep Tomar: 5 February 2019 1
Component-Based Software Engineering Pradeep Tomar: 5 February 2019 1
Component-Based Software Engineering Pradeep Tomar: 5 February 2019 1
SOFTWARE ENGINEERING
Pradeep Tomar
5 February 2019 1
Challenges to Software
Industry
More reliable software
More efficient software
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
5 February 2019 6
REUSE PROCESS
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
5 February 2019 15
CBSE has three major
functions:
Developing software from prefabricated, reusable parts.
5 February 2019 16
5 February 2019 17
CBSE
5 February 2019 18
CBSE
Component-based software engineering (CBSE) is an
approach to software development that relies on software
reuse.
5 February 2019 19
COMPONENT-BASED SOFTWARE
ENGINEERINIG
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.
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.
5 February 2019 23
COMPONENT-BASED
SOFTWARE ENGINEERINIG
Development for Reuse
From Scratch
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.
5 February 2019 25
Development with Reuse
• The process of defining requirement for a CBS.
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.
5 February 2019 27
CBSE Essentials
Independent components specified by their interfaces.
5 February 2019 28
ADVANTAGES
OF
COMPONENT-BASED SOFTWARE DEVELOPMENT
• Application softwares can be developed more quickly.
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.
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.
5 February 2019 31
COMPONENT
A component is a .NET class
Shell …… Interface
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:
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 )
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.
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.
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.
5 February 2019 42
COMPONENT INTERFACE
5 February 2019 43
COMPONENT
IMPLEMENTATION
The implementation form is a realization of component
specification, which is independently deployable.
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.
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.
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.
5 February 2019 53
COP vs. OOP
Object Oriented Programming = Polymorphism + (Some) Late
Binding + (Some) Encapsulation + Inheritance
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.
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.
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.
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.
5 February 2019 62
LANGUAGE INDEPENDENCE
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.
5 February 2019 64
LOCATION TRANSPARENCY
A component-based application contains multiple binary
components.
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.
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.
5 February 2019 68
VERSIONING SUPPORT
Component-oriented programming must allow clients and
components to evolve separately.
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.
5 February 2019 70
COMPONENT-BASED
SECURITY
In component-oriented programming, components are developed
separately from the client applications that use them.
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.
5 February 2019 72
Components Represent Decomposition and Abstraction
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
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.
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.
5 February 2019 81
Software Development
based on DE
Domain Engineering
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?
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
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
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
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?
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.
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.
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.
• 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
A A
A B
B B
• Microsoft COM
• Sun javaBean
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.
• Requires interface
• Defines the services that specifies what services must
be made available for the component to execute as
specified.
• 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.
Platfo rm services
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.
dataflow,
and structure
Pradeep Tomar
5
2/5/2019
February 2019 143