By:

Gurpreet Singh(007)
Harshpreet Singh(008)
  Szyperski: (explicit context dependencies)
◦ 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.

A thing is notand
Councill a component
Heinmann: (reusable,
if it cannot be reused
independent across composition)
deployment, multiple
applications (but
◦ A software it may isbe
component a module)
a software element that conforms to a
component model
• Single-product and can be
development independently
(which deployed
does not develop and
with composed
reuse in mind),
without modification according to a composition standard.
at best, has a remote change of yielding components, if their units are
accidently developed as reusable units
•But single-product development can reuse existing components
• Development from scratch, by definition, does not reuse
• Developing with reuse / developing for reuse
– Single-product development, by definition, does not involve
development for reuse

• The day that we no longer need to develop for reuse is

– The day that the software engineering problem (software
crisis) is solved
– The day that software engineers and researchers lose their
jobs

• In the mean time, essence of CBSE: development for reuse

– Development with reuse may be used to achieve
development for reuse, but often this is not feasible
– Components are developed for reusability
• CBSE assumes the existence of 2 component development
paradigms

– Single-product development
• Top down, single architecture driven
• Planned use of components (develop only what is needed)
• All development within a single organization
• All software developed during the process

– Component market (e.g. Components Off The Shelf)

• Bottom-up (no global architecture defined)
• Use of components is opportunistic (use whatever is available)
• Component software is available when starting the project
• It results in inter-organizational reuse

• Single-product development: problems of standard software engineering

process
• Component market: problems are not so obvious. After all, this is
supposedly the goal of CBSE.
 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  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
provides for the component to
execute as specified.
 A contract specifies the interactions among components,
in terms of:
◦ The set of participating components;
◦ The role of each component through its contractual obligations;
◦ The invariant to be maintained by the components;
◦ The specification of the methods which instantiate the contract.
 A contract is comprised of:
◦ The Invariant, the global constraints which the component will
maintain;
◦ The Pre-condition, the constraints which need to be met by the client;
◦ The Post-condition, the constraints which the component promises to
establish in return.
 Patterns define recurring solutions to recurring problems capturing non-
obvious solutions, not just abstract principles or strategies.
◦ A component, as a reusable entity, can be seen as a realization of some design
pattern.

 Patterns can be classified into three major categories:

◦ Architectural Patterns, capture the overall structure and organization of a software
system.

◦ Design Patterns, refine the structure and the behavior of the subsystems ,components
of a software system, and the relationships between them.

◦ Idioms, are low-level patterns which are dependent on chosen paradigm &
programming language used.
 CBSE means that we build software by "putting pieces
together". Frameworks provide the context in which the
pieces can be used.
 A Component Framework describes a “circuit-board”
with empty slots into which components can be inserted
to create a working instance.
  A Component Model is a definition of standards for
component implementation, documentation and
deployment.
 The component model specifies how interfaces should be
defined and the elements that should be included in an
Customisation
interface definition.
Naming
convention
Elements of
component model Composition Documentation

Interface Specific Meta-data Evolution

Packaging
definition interfaces access support

Usage Deployment
Interfaces
information and use
Component model
Horizontal services

Component Transaction Resource

management management management
Concurrency Persistence Security

Platform services

Interface Exception Component

Addressing
definition management communications
 Composition involves integrating components with each other and
with the component infrastructure.

 Types of composition
o Sequential composition where the
composed components are executed in
sequence. This involves composing the
provided interfaces of each component.

o 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.

o Additive composition where the

interfaces of two components are put
together to create a new component.
  Address the problem of component incompatibility by
reconciling the 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.

An example
sensorManagement addSensor
start
removeSensor
startSensor
sensor stop Adapter Data collector stopSensor
testSensor
sensorData
getdata initialise
report
listAll
 Trust. You need to be able to trust the supplier of a
component. At best, an untrusted component may not
operate as advertised; at worst, it can breach your security.

 Requirements. Different groups of components will

satisfy different requirements.

 Validation.
◦ The component specification may not be detailed enough
to allow comprehensive tests to be developed.
◦ Components may have unwanted functionality. How can
you test this will not interfere with your application?
• Component
– Specification and collaboration is often too low level, missing many of high level
functional and non-functional requirements

• Service component
– Specified in terms of interfaces which are parts of a contract (formally describing how
provided interfaces behave with required interfaces)
• Interface behavior/obligation specified in terms of Service Level Agreement (SLA)
– Characteristics
• Large granularity (provides single business concept or process)
• Asynchronous interaction (message-based, not call-and-return)
• Interface specification behavior fully defined as a state machine of messages

• Business protocols
– Business protocol = subset of business process describing the message exchange
state machine of each party
– Challenges of designing a protocol (deadlocks, livelocks, reliability, sequencing, etc.)
– Contracts implement business protocols

• Parameterized schemas (e.g. Buyer/Seller contract, with Buy and Seller as variation points)
• Service-Oriented Architecture (SOA)
– A topology of loosely coupled, large granularity service components
– Message-based contracts (bi-directional, asynchronous)

• Web services (implementation of SOA)

– Features
• Location independent (“write once, run anywhere”)
• Internet standards (open, intranet, internet)
• True black-box (message interchange)
• No explicit programming model (connection is the common vocabulary)
– Specification (Web Service Description Language)
– Web service data semantics
• XML schemas (XMI) for data format standard
• Standard dictionary of terms
• Semantic web (data reuse framework using Resource Description
Framework – uses XML for syntax and URIs for naming)
– Web services process semantics
• Language for expressing contracts (Message Exchange Patterns)
• Business Process Execution Language (BPEL) for web services
– Specify how a group of web services work to implement a business process
 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?
 CBSE is a reuse-based approach to defining and
implementing loosely coupled components into systems.
 A component is a software unit whose functionality and
dependencies are completely defined by its interfaces.
 A component model defines a set of standards that
component providers and composers should follow.
 During the CBSE process, the processes of requirements
engineering and system design are interleaved.