CBSE

ap-sengfac@ncst.ernet.in
Coverage
• Reuse
• Motivation
• CBSD/CBSE vs CBD
• Terminology
• Domain Engineering
• Component Based Development
• Economies of CBSE
Reuse
• Historical aspect
– Ad hoc
– Experience
• Modern era
– Locate scope of reuse and apply
– Software Architecture, Design
Patterns, Code reuse via libraries,
Binary reuse…
Motivation
Players
• OMG
– CORBA
• Sun, Sunsoft
– EJB
• Microsoft
– COM, DCOM, ActiveX, COM+, etc.
Competition
CBSE/CBSD vs CBD
• 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 definition – as per CMU
• CBSE is concerned with the rapid
assembly of systems from
components where
– Components and frameworks have
certified properties
– These certified properties provide the
basis for predicting the properties of
system build from components
Terminology
• Components
• Objects
• Abstraction
• Interfaces/Contracts
• Component Model
• Component Framework
• COTS, Open Systems
Component – ECOOP workshop
• 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
Component – as per Szyperski
– Component is a unit of independent
deployment
• Well separated from environment and
other components
– Component is a unit of third party
composition
• Sufficiently self – contained
– Component has no persistent state
• Cannot be distinguished from copies of
itself
Component – as per CMU
• Component is an opaque
implementation of functionality
– components will remain “black boxes” to consumers.
• Subject to third – party composition
– Use should not depend upon tools or
knowledge of the component that is in the
possession of component provider
• Conformant with a component model
– CM prescribe of how component interact
with each other. Enforces design constraint
Object – as per Szyperski
• Object is unit of instantiation. It
has unique identity
• An object has state (can be
persistent)
• Object encapsulates its state and
behavior

– Component may return Object to

caller
– Component need not be OO
Abstraction
• Hide/expose required functionality
• Base for reuse
• Categories
– Black box
– White box
– Grey box
• Partial implementation details available
Interface
• Mechanism for abstraction
• Serve as contract between client and
vendor
– essentially functional requirement
• Means by which components connect
– Technically, a set of named operations that
can be invoked by client
• Direct (procedural) and Indirect (object)
interfaces
– Method dispatch.
Contract
• States what client needs to do to use
the interface
• States what the provider has to
implement to meet the services
promised by the interface
– Hoare triple {pre-condition} Operation
{post-condition}
• Doesn’t capture non – functional service
level requirements. But efforts are on.
Component Model
• Standards and conventions imposed on
developers of component
• Purpose of CM
– Enables uniform composition
– Appropriate quality attribute
– Deployment of components and applications
• Microsoft’s COM is an example of
Component model
Component Framework
• Implementations of services that
support or enforces a component
model
• Analogous to OS in certain aspects
– Components are to frameworks what
processes are to OS
• For eg: EJB specifications defines
framework of server and
containers that support EJB
Component model
Components Off The Shelf
• A commercial off-the-shelf (COTS)
product is a product, such as an
item, material, component,
subsystem, or system, sold or
traded to the general public in the
course of normal business
operations at prices based on
established catalog or market
prices
Open Systems
• An open system is a collection of
interacting software, hardware, and
human components
– designed to satisfy stated needs
– with interface specifications of its
components that are
• fully defined
• available to the public
• maintained according to group consensus
– in which the implementations of the
components conform to the interface
specifications
CBSE
• Buy, do not build philosophy
• Emphasis to composing software
system. Focus on integration rather
than implementation
– Assembly line in engineering
• Assumption: sufficient commonality
exist among large software systems to
justify developing reusable components
to exploit and satisfy commonality
CBSE Process model
• Gather requirement
• Establish architectural design
• Examine requirements to
determine what subsets are
amenable to composition
• Identify components required
• Hunt for component (in-house or
COTS)
Differences from other
processes
• Team attempts to modify or
remove system requirements that
cannot be implemented with COTS
or in-house components
• If requirement cannot be changed
or deleted, then target component
development (CBD)
 CBD Model Identify

Planning
Search
Risk Lib
Customer Analysis
Communication Construct
nth iteration

Build
Component
Customer
Evaluation
Engineering Update
construction Lib
& Releases
 Reusable
Domain S/W Arch
Component
Analysis Development
Development
Repository
Domain Structural Reusable
Domain Model Model Artifacts/
Engineering Components

Component Component
Qualification Update
Component
Adaptation
Architectural Application
Analysis Component
Design Software
Adaptation

Component Based Component Testing

Development Engineering
Domain engineering
• Goes parallel to CBD in CBSE Process
model
• Intent 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
• Paves path for future reuse
Domain Engineering activities
• Analysis
• Construction
• Dissemination
Domain Analysis
• Software Domain analysis is the
identification, analysis, and
specification of common
requirements from a specific
application domain, typically for
reuse on multiple projects within
same domain
– Firesmith
 Domain Analysis

Ttaxonomies
Technical Literature

Existing app Reuse Std

Domain
Sources of
Domain Functional Analysis
Domain Cust. Survey
Analysis Model Model
Knowledge
Expert adv Domain
Language
Current/Future
Requirements
Analysis
• Steps to identify and categorize
– Select specific functions/ objects
– Abstract functions/objects
– Define a taxonomy
– Identify common features
– Identify specific relationships
– Abstract relationships
– Derive a functional model
– Define a domain language
Analysis – considerations
• 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
Cont…
• Does the H/W remain unchanged
between implementations
• Can the H/W specifics be removed to
another components
• Is the design optimized enough for the
next implementations
• Can we parameterize a non – reusable
components so that it becomes
reusable
Cont…
• Is the component reusable in may
implementations with only minor
changes
• Is reuse through modification feasible
• Can a non – reusable component be
decomposed to yield reusable
components
• How valid is component decomposition
for reuse
Domain characteristics
• Sometimes difficult to determine
whether a potential candidate
component is applicable in particular
situation.
– Need to define set of domain characteristics
that are shared by all software in this
domain
• A domain characteristic defines some
generic attribute of all products that
exist within the domain
Domain Characteristics
• A set of Domain Characteristics can be
represented by {Dp} where each item
Dpi, in the set represents a specific
domain characteristics.
• Value assigned to Dpi represents an
ordinal scale that is an indication of the
relevance of the characteristics for
component p
– Eg: Not Relevant, Relevant under
circumstances, Relevant but need
adaptation, Clearly relevant, etc
Domain Characteristics
• When new software, w, is to be built
within the application domain, a set of
domain characteristics are derived for
it. A comparison between Dpi and Dwi is
made to determine whether component
p can be effectively used in application
W.
• Eg of Domain Characteristics
– Wrt to Product: Requirement stability,
memory constraints, saftey/ reliability etc.
Structural modeling
• Structural modeling is a pattern-
based domain engineering
approach that works under the
assumption that every application
domain has repeating patterns
that have reuse potential
Structural Model
• Consist of a small number of structural
elements manifesting clear pattern of
interaction.
• Architecture of systems using structural
model are characterised by multiple
ensembles that are composed from
these model elements.
• Many architectural units emerge from
simple patterns of interaction among
this small number of elements
– Pollak and Rissman
Structure points
• Structure point is an abstraction that
should have limited number of
instances. The abstraction should recur
throughout applications in the domain.
Otherwise cost to verify, document and
disseminate structure points cannot be
justified
• Rules to govern structure points should
be easily understood. In addition, the
interface to structure point should be
simple
Cont…
• Structure point should implement
information hiding by isolating all
complexity contained within the
structure point itself. This reduces the
perceived complexity of the overall
system
• Eg of Structure points
– Application front end, Database, editor etc
– Domain specific: in case of alarm system,
Structure points may be sensor mgmt
mechanism, response mechanism etc.
Component Engineering
• Activities to do if component
available against requirement
– Component qualification
– Component adaptation
– Component composition
– Component update
Component Qualification
• System requirements and architecture
define the components that will be
required
• Components understood by
characteristic of their interfaces.
– Interfaces provide limited knowledge about
degree of fit for component within system
architecture against requirements
• Those that qualify functional
requirement should further be assessed
for performance, reliability, usability etc
(non-functional) requirements
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
– Will exhibit the quality characteristics
required for the application
Component Qualifications –
Factors
• Application Programming interface
• Development and integration tools
required
• Runtime Resource usage
– Memory, storage etc
• Service requirements
– Dependencies on OS, other
components
Cont…
• Security features
– Access control, authentication
protocol
• Exception handling
• Misc
– Design assumption by vendor. For eg.
Use of certain algorithm (grey box)
Component adaptation
• Software architecture represents design
pattern that are composed of
component connections, and
coordination.
• Component that mismatch against
architecture design rules, must be
adapted to meet the needs of
architecture
– Parameterised. Customizable
– Wrapper
Component adaptation
• Ideally, domain engineering
creates library of components that
can be easily integrated into
application architecture
– Consistency in interfacing with
architecture, environment etc
– Data management included etc
• However conflicts, incompatibilities
may arise
Component wrapping
• White box wrapping
– Assumes knowledge of code. Modify
code (may lead to maintenance
probs)
• Grey box wrapping
– Depends more on component library,
model for provision of extension
language. Seek facility to mask or
disable conflict
• Black box wrapping
– Add “in house” Pre and post
Wrapping
• Generally wrapping means
maintenance issues in case of new
releases
• Trade off issue
– Effort to wrap component
– Effort to create custom component
– Manage variants, versions
Component Composition
• Architectural style decide rules for
integration of components to form
a working system
– Identifies connection and coordination
mechanisms
Component Composition
• Integration of available
components (qualified, adapted,
engineered) to populate the
architecture established for the
system
• Infrastructural requirements
– Component Model, Framework
– Service requirements
• Data exchange model, Automation,
structured storage, underlying object
model
Composition
• Industrial standards for Model and
Framework
– J2EE architecture
– .NET Framework
– CORBA
– OpenDoc
– SOM
Component update
• Replace existing software as new
version of components become
available
– CM issues
• When systems are implemented with
COTS, update is complicated by the
imposition of third party. The
organization that developed the
reusable component may be outside the
immediate control of the software
engineering organisation
Component Engineering
• Building of components
• Development issues are identical
to traditional mode, except
– Essence on reusability
• Abstraction, functional independence
– Shift concern from domain to generic
modules
Analysis and Design for reuse
• Standard data
– Application domain should be investigated
and standard global data structures should
be identified. All design components can be
characterized to make use of standard DS
• Standard interface protocols
– Intra modular interfaces
– External interfaces
• Human
• Non – human
Got interfaces. Now what?
• Interfaces would define set of
operations required by client (modules,
human, non – human)
• Team identifies service provider. In this
case component
• Direct Interfaces - Directly provide
procedural interface to traditional
libraries
• Indirect interfaces – indirection involved
when using class libraries
Interfaces as contract
• What clients needs to do to use
“interface”
• What provider has to implement to
meet the services promised by
“interface”
• Client establish precondition before
calling operation
– Provider relies on precondition.
• Provider establish post condition
– Client relies on post condition
Describing reuse components
• Describe using 3Cs
– Concept, Content and Context
• Concept
– Description of what component does. Learn
interface
• Content
– Describes how concept is realised
• Context
– Places component within domain of
applicability
Comp Repository
• Maintain library of component
available by transforming 3C
model into concrete schema
• Three methodologies
– Library and information science
– Artificial intelligence method
– Hypertext system
Library and Information Science
method
• Commonly used
• Further three classification
– Enumerated classification
– Faceted Classification
– Attribute – value classification
Enumerated Classification
• Component described by a defined
hierarchical structure in which
classes and varying levels of
subclasses are defined.
Components would be at leaf node
• Easy to understand and use but
lacks flexibility
Faceted Classification
• Domain area is analyzed and a set
of basic descriptive features is
identified. These features, facets,
are then prioritized by importance
and connected to a component
• Set of facets describing a
component is called facet
descriptor
Facet Description
• Facet can describe
– Function of component
– Data manipulated
– Context in which component can be
applied
• Facet Descriptor: {Function,
object type, system type}
– Eg {DeviceControl, C++, Real Time
System}
Facet benefits
• Keywords can be linked
– Thesaurus building
• Searching is intelligent than the
enumerated classification search
Attribute – value classification
• Variant of faceted classification
– A set of attributes is defined for all
components in domain area. Values
are then assigned to these attributes
in same way in faceted classification
• It differs from faceted by
– No limit on number of attributes
– Attributes are not assigned priorities
– Thesaurus functions not used
Economies of CBSE
• Cost/benefit analysis for
component reuse
– Estimate cost metrics by comparing/
estimating when reused
• Alternate methodologies
– Cost analysis using structure points
– Reuse metrics
Impact on quality, productivity,
cost
• Quality
– Reduction in defect rate considering
that component is improvised
iteratively
– Measured in defects per KLOC
• Productivity
– Less time spent on creating plan,
model, develop (one time job per
version)
– 30 – 50% reuse can result in 25 – 40%
productivity improvement
Cont…
• Cost associated with re use include
domain analysis, domain
architecture development, etc.
– Cs Cost if developed from scratch
– Cr Cost associated with reuse
– Cd Actual cost of S/W as delivered
Cost analysis using structure
points
• Structure points are reusable but their
qualification, adaptation, integration
and maintenance cost is nontrivial
• Assess historical data
– Collect cost for each instance of usage
• Overall effort = Enew + Equal + Eadapt + Eint
– New (new comp), qual (qualify comp), adapt
(adapt comp), int(integrate comp)
Reuse Metrics
• Rb(S) = [Cnoreuse – Creuse] / Cnoreuse
– Rb is benefit associated with reuse within
System S
– Cost no reuse/reuse cost of developing
system S with no reuse/reuse
0 ≤ Rb(S) ≤ 1
• For OO Systems, reuse leverage is
– Rlev = OBJreused / OBJbuilt
– OBJ Reuse/built is number of object
reused/built
Reuse Metrics
• Commonality of a Component
• Reuse Threshold of a Component
– (minimum number of times a reusable
component must be reused for ROI)
• Reuse Merit of a Component
– (reusability of a component relative to the
average reusability of a similar component)
• Reuse Creation Cost of a Component
– (cost of purchasing the component +
identifying it via domain analysis +
preparing it for reuse)
Reuse metrics
• Reuse Usage Costs of a Component
– (costs of finding, understanding,
modifying/specializing and integrating the
reusable component)
• Reuse Maintenance Cost of a
Component
– (costs of supporting a reusable component)
• Degree of Commonality of a System or
Business Area
– (proportion of a system's / Business Area's
common components)
 Reuse Metrics
Reuse metrics
• Degree of Reusability of a System or
Business Area
– (proportion of a system's / Business Area's
components are reusable)
• Reuse Target Level of a System
(Business Area or Corporation)
– minimum proportion of a system that is
reusable.
• Reuse Merit of a System (or Business
Area)
– the proportion of a system (or Business
Area's components) that is reusable relative
to the avg. proportion for a system in one
References
• Component Software. Beyond OO
Programming
– Clemens Syzperski
• Software Reusability – Volume I &
II
– Ted Biggerstaff & Alan Perlis
• Software Engineering. Practitioner
approach
– Pressman
Web References
• SEI, CMU articles
– http://www.sei.cmu.edu/publications/docum
– http://www.sei.cmu.edu/opensystems/faq.h
– http://www.sei.cmu.edu/cbs/index.html
• Misc
– CACM June 2003 and Oct 2002 issue