By: Harshpreet Singh(ME Software Engg.

1st yr ) Thapar University

Szyperski:

A software component is a unit of composition with contractually specified

(explicit context dependencies)

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

Councill and Heinmann: (reusable, independent deployment, composition)

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.

A thing is not a component if it cannot be reused across multiple applications (but it may be a module)

Single-product development (which does not develop with reuse in mind), 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 interoperability)

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 for the component to execute as specified.

provides

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 interface definition.
Cu stomis ation Naming conv en tio n Co mp ositio n Sp ecif ic interfaces Meta-data acces s Do cu men tatio n Pack ag ing Ev olution s upp or t

Elements of component model

Interface defin ition

Interfaces

Us ag e informatio n Co mp onent mo del

Deploy ment and u se

Ho rizo ntal services Co mpo nent management Co ncurrency Tran saction management Pers is ten ce Reso urce management Secu rity

Platform s ervices Ad dres sing Inter face defin ition Exception management Co mpo nent communicatio ns

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. where the interfaces of two components are put together to create a new component.

o Additive composition

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
s en sorManagement s tart s en sor s to p Ad ap ter s en sorData Data co llector addSen so r removeSens or s tartSens or s to pSens or tes tSen so r initialise rep or t lis tAll

getdata

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.