Ch t 19.

Chapter 19
Component-Based Software Engineering
Objectives

• To explain
T l i that
th t CBSE is
i concerned d with
ith developing
d l i standardized
t d di d
components and composing them into applications
• To describe components and component models
• T show
To h principal
i i l activities
ti iti iin CBSE process
• To discuss approaches to component composition and problems that
may arise

Konkuk University 273

Component Based Development
Component-Based

• Component-based
C t b d software
ft engineering
i i (CBSE) is
i an approach
h to
t
software development that relies on software reuse.
– Emerged from the failure of object-oriented development to support effective
reuse
– Single object classes are too detailed and specific to reuse.

• Components are more abstract than object classes and can be

considered to be stand-alone service providers.

Konkuk University 274

CBSE Essentials

• CBSE essentials
i l
– Independent components specified by their interfaces
– Component standards to facilitate component integration
– Middleware that provides support for component inter-operability
– Development process that is geared to reuse

• Apart from the benefits of reuse, CBSE is based on sound software

g g design
engineering g pprinciples
p
– 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.

Konkuk University 275

CBSE Problems

• C
Component trustworthiness
hi
– How can a component with no available source code be trusted?

• Component certification
– Who will certify quality of the 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?

Konkuk University 276

Components

• Components
C t provide
id a service
i without
ith t regard
d to
t where
h the
th componentt is
i
executing or what its programming language is.
- 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.

Councill and Heinmann:

A software component is a software element that conforms to a co
mponent model and can be independently deployed and compose
d without modification according to a composition standard.

Szyperski:
A software component is a unit of composition with contractually s
pecified interfaces and explicit context dependencies only. A softwa
re component can be deployed independently and is subject to co
mposition by third-parties.

Konkuk University 277

Characteristics of Components

Characteristics Description
Component standardisation means that a component that is used in a CBSE process has to
Standardized conform to some standardised component model. This model may define component interfaces,
component meta-data
meta data, documentation,
documentation composition and deployment.
deployment

A component should be independent – it should be possible to compose and deploy it without

Independent having to use other specific components. In situations where the component needs externally
provided services, these should be explicitly set out in a ‘requires’ interface specification.

For a component to be composable, all external interactions must take place through publicly
Composable defined interfaces. In addition, it must provide external access to information about itself such
as its methods and attributes.

To be deployable,
deployable a component has to be self
self-contained
contained and must be able to operate as a
stand-alone entity on some component platform that implements the component model. This
Deployable
usually means that the component is a binary component that does not have to be compiled
before it is deployed.

Components have to be fully documented so that potential users of the component can decide
Documented whether or not they meet their needs. The syntax and, ideally, the semantics of all component
interfaces have to be specified.

Konkuk University 278

Component Interface

• P id interface
Provides i f
– Defines the services that are provided by the component to other
components
• Requires
i iinterface
f
– Defines the services that specifies what services must be made available for
the component to execute as specified.

Requires interface Provide interface

Defines the services Defines the services

from the component’s Component that are provided
environment that it by the component
uses to other components

Konkuk University 279

Example: A Data Collector Component Interface

Requires interface Provides interface

addSensor
e o eSe so
removeSensor
sensorManagement
M t
star tSensor
Data collector stopSensor
sensorData testSensor
initialize
report
li tAll
listAll

Konkuk University 280

Component Model

• Component model
C d l is
i ad
definition
fi i i off standards
d d ffor component
implementation, documentation and deployment.
– EJB model (Enterprise Java Beans)
– COM+ model (.NET model)
– CORBA component Model
• Component model specifies how interfaces should be defined and the
elements that should be included in the interface definition.

Elements of component models Customisation

Naming
convention

Composition Documentation

Interface Specific Meta-data Evolution

Packaging
definition interfaces access support

Usage Deployment
I t f
Interfaces
information and use
Component model
Konkuk University 281
Middleware Support

• Middl
Middleware provides
id supportt for
f executing
ti components.
t
– Component models are the basis of middleware.
• Component model implementations provide
– Platform services : allow components written according to the model to communicate
– Horizontal services : application-independent services used by different components
• Container
– A set of interfaces used to access the service implementations
– To use services provided by a model

Horizontal services

Component Transaction Resource

management management management

C
Concurrency Persistence S
Security
it

Platform services

Inter face Exception Component

Addressing
definition management communications
Konkuk University 282
Component Development for Reuse

• Components
C t developed
d l d for
f a specific
ifi application
li ti usually
ll h
have tto b
be
generalized to make them reusable.
• A component is most likely to be reusable if it associated with a stable
domain abstraction (business object)
object).
– In a hospital, stable domain abstractions are associated with the fundamental
purpose - nurses, patients, treatments, etc.

• Component reusability
– Should reflect stable domain abstractions
– Should hide state representation
p
– Should be as independent as possible
– Should publish exceptions through the component interface

• Trade-off between reusability and usability

– The more general the interface, the greater the reusability.
– But it is then more complex and hence less usable.

Konkuk University 283

Cost of Reusable Component

• The development
Th d l cost off reusable
bl components may be
b higher
hi h than
h the
h
cost of specific equivalents.

• Generic components may be less space-efficient and may have longer

execution times than their specific equivalents.

• This extra reusability enhancement cost should be an organization cost

rather than a project cost.

Konkuk University 284

Legacy System Components

• Existing
E i i llegacy systems that
h fulfill
f lfill a useful
f lbbusiness
i ffunction
i can b
be re-
packaged as components for reuse.
– Involve writing a wrapper component that implements provides and requires
i t f
interfaces t access the
to th legacy
l system
t
– Although costly, this can be much less expensive than rewriting the legacy
system.

Konkuk University 285

CBSE Process

• When reusing
Wh i components,t it is
i essential
ti l to
t make
k trade-offs
t d ff b
between
t
ideal requirements and the services actually provided by available
components.
– Developing outline requirements
– Searching for components then modifying requirements according to
available functionality
– Searching again to find if there are better components that meet the revised
requirements

Modify requirements
Outline system Identify candidate according to
requirements components discovered
components

Compose
Architectural Identify candidate
components
p to
design components
create system

Konkuk University 286

Component Identification Issues

• T t
Trust
– You need to be able to trust the supplier of a component.
• At best, an un-trusted component may not operate as advertised.
• At worst, it can breach your security.
security

• Requirements
– Different g
groups
p of components
p will satisfyy different requirements.
q

• Validation
– Component
p specification
p mayy not be detailed enough
g to allow
comprehensive tests to be developed.
– Components may have unwanted functionality. How can you test this will not
interfere with your application?

Konkuk University 287

Component Composition

• P
Process off assembling
bli components to create a system
– Involve integrating components with each other and with the component
infrastructure
– Normally
N ll have
h t write
to it ‘glue
‘ l code’
d ’ to
t integrate
i t t components t

• Types of composition
– Sequential composition
• Where the composed components are executed in sequence
• 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
• The interfaces of two components are put together to create a new component

Konkuk University 288

Types of Composition

Konkuk University 289

Interface Incompatibility

• P
Parameter i
incompatibility
ibili
– Operations have the same name but are of different types.
• Operation incompatibility
– Names of operations in the composed interfaces are different.
• Operation incompleteness
– Provides interface of one component is a subset of the requires interface of another.

string location(string pn)

phoneDatabase (string command)
string owner (string pn)
addressFinder
string propertyType (string pn)

displayMap (string postCode, scale)

mapDB (string command)

mapper printMap (string postCode, scale)

Konkuk University 290

Adaptor Component

• Address the
Add h problem
bl off component iincompatibility
ibili b by reconciling
ili the
h
interfaces of the components that are composed.
– Different types of adaptor are required depending on the type of composition.

• An addressFinder and a mapper component may be composed through

an adaptor that strips the postal code from an address and passes this
to the mapper component.

address = addressFinder.location (phonenumber) ;

postCode = postCodeStripper.getPostCode
postCodeStripper getPostCode (address) ;
mapper.displayMap(postCode, 10000)

Konkuk University 291

Adaptor for Data Collector Component

sensorManagement addSensor
start
removeSensor
startSensor
stop
sensor Adapter Data collector stopSensor
testSensor
sensorData
getdata iinitialise
i i li
report
listAll

Konkuk University 292

Interface Semantics

• Have to rely
H l on component documentation
d i to decide
d id if syntactically
i ll
compatible interfaces are actually compatible

• Object Constraint Language (OCL)

– Define constraints that are associated with UML models.
– Based around the notion of p pre and post
p condition specification
p - similar to
the approach used in Z.

-- The context keyword names the component to which the conditions apply
context addItem

-- The preconditions specify what must be true before execution of addItem

pre: PhotoLibrary.libSize() > 0
PhotoLibrary.retrieve(pid) = null

-- The postconditions specify what is true after execution

post: libSize () = libSize()@pre
p ()@p + 1
PhotoLibrary.retrieve(pid) = p
PhotoLibrary.catEntry(pid) = photodesc

context delete

pre: PhotoLibrary.retrieve(pid) <> null ;

post: PhotoLibrary.retrieve(pid) = null

PhotoLibrary.catEntry(pid) = PhotoLibrary.catEntry(pid)@pre
PhotoLibrary.libSize() = libSize()@pre - 1
Konkuk University 293
Trade Offs in Composition
Trade-Offs

• Wh composing
When i components, you may find
fi d
– Conflicts between functional and non-functional requirements
– Conflicts between the need for rapid delivery and system evolution

• You need to make decisions such as

– What composition
p of components
p is effective for delivering
g the functional
requirements?
– What composition of components allows for future change?
– What will be the emergent properties of the composed system?

(a) Data Data Repor t

collection g
management generator Repor t

Data
(b) Data base
collection
Repor t
Konkuk University 294
Summary

• CBSE is
i a reuse-based
b d approach h to
t defining
d fi i andd implementing
i l ti loosely
l l
coupled components into systems.
• A component is a software unit whose functionality and dependencies
are completely defined by its interfaces.
interfaces
• A component model defines a set of standards that component
providers and composers should follow.
• Component composition is the process of ‘wiring’
wiring components together
to create a system.
• When composing reusable components, you normally have to write
adaptorss to reconcile
adapto eco c e different
d e e t component
co po e t interfaces.
te aces.
• When choosing compositions, you have to consider required functionality,
non-functional requirements and system evolution.

Konkuk University 295

Konkuk University 296