This document discusses software component reuse and architectures to support it. It describes the importance of reuse for reducing costs and development time. Two main architectures are product-line architectures and COTS (commercial off-the-shelf) architectures. Product-line architectures allow developing a collection of similar components from shared assets to build a product line. COTS architectures support reuse through buying existing third-party software components. The document also discusses challenges of COTS reuse related to limited information and testing of third-party components.

1. ARCHITECTURE SUPPORT
FOR COMPONENT REUSE
Chand Anand : 2K11/SE/020
Rishabh Harit : 2K11/SE/060
Swati Kandhari : 2K11/SE/079

2. Hyderabad
Bangalore
Gurgaon
INDEX
• What is Software Reuse?
• Types of Software Reuse
• Importance of Software Reuse
• Types of Architecture to support Software Reuse
• Product – Line Architecture
• COTS Architecture

3. • In most engineering disciplines, systems are designed by
composition (building system out of components that have
been used in other systems).
• Software engineering has focused on custom development
of components.
• To achieve better software quality, more quickly, at lower
costs, software engineers are beginning to adopt systematic
reuse as a design process

4. • Application System Reuse
• reusing an entire application by incorporation of one
application inside another (COTS reuse)
• development of application families (e.g. MS Office)
• Component Reuse
• components (e.g. subsystems or single objects) of one
application reused in another application.
• Function Reuse
• reusing software components that implement a single
well-defined function.

5. • Increased Reliability
• components already 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 custom development and speed up delivery

6. • Product – Line : It identifies an abstract set of requirements
that cover all applications you want to build in the domain;
provides software engineering methods for creating a
collection of similar components from a shared set of
software assets using a common means of production.
• The products can be managed as a group, planning the whole
set consistently, allocating funding and developers to several
of the products at the same time and advertising the
products as a set, highlighting their common and varying
features.

7. • Product-line CBSE delivers the promise of large-scale
software reuse by promoting the use of software
components built by commercial vendors or in-house
developers.
• While examining different applications in the same product-
line or problem domain, comparison among applications is
done on the basis of their features.
• A feature is a product characteristic that users and customers
view as important in describing and distinguishing members
of the product-line. A feature can be:
• a specific requirement
• a selection among optional or alternative
requirements

8. • A product-line can be built around the set of reusable
components by analysing the products to determine the
common and variable features using a technique called
domain analysis.
• Domain analysis is a technique to systematically extract
features from existing or planned members of a product-line.
• This is followed by development of a product structure and
implementation strategy around a set of reusable
components that can be composed to implement several
different products.

9. • Reduce significantly the cost and time-to-market of
enterprise software systems by allowing the systems to be
built by assembling reusable components rather than from
scratch.
• Enhance the reliability of enterprise software systems
because each reusable component has gone through several
review and inspection stages in the course of its original
development and previous use; and because CBSE relies on
explicitly defined architecture and interfaces.

10. • Improve the maintainability of enterprise software systems
by allowing new (higher) quality components to replace old
ones.
• Enhance the quality of enterprise software systems by
allowing application-domain experts to develop components,
and software engineers specialized in component-based
software development to assemble the components and
build enterprise software systems.

11. • IBM SanFrancisco project which delivers application
frameworks and Java Bean components is based on Product –
Line Architecture.

12. • One way of approaching the issue of reuse is to develop
systems by a Component-Based Software Engineering, CBSE,
paradigm: assembling software systems from components.
• COTS : Reusing components made for earlier products as an
approach to new system development is a promising way of
achieving the instantaneous development and system
improvements. The possibility to buy software components
from component vendors, so called Commercial-Off-The-
Shelf, COTS, components.

13. A middleware is a layer of software that separates application
software from system software and other types of run-time
environment specific software. The two most known
middleware solutions and de-facto standards are:
• Object Management Group’s (OMG) Common Object
Request Broker Architecture (CORBA).
• Microsoft’s Component Object Model (COM).

14. • Using COTS Components can save valuable development
time, but insight in the COTS component functionality and
properties must be evaluated for its intended use.
• In order to integrate a COTS component in a system, the
developers must consider relevant properties of the
component like operational limitations, temporal behavior,
preconditions, robustness and many forms of underlying
assumptions on the intended environment.
• To determine its properties, extensive testing of the
component may be necessary.

15. • Functionality is instantly accessible to the developer.
• Components may be less costly than those developed in-
house.
• The component vendor may be an expert in the particular
area of the component functionality.

16. • Industrial competition for delivering more reliable systems in shorter
time frames.
• A demand for larger and more complex software solutions, which often
can not be effectively implemented in a timely manner by a single
software development organization.
• Increase in availability of reusable COTS components.
• Increased degree of standard compliance among COTS software
products that enables reduction of product integration time.
• Increasing research in better software component “packaging”
techniques and approaches.
• Increasing recognition that software reuse is one of the most important
means to achieve better software solutions with minimum
development cost.

17. • Often, only a brief description of its functionality is provided
with a COTS component.
• A component, often, carries no guarantee of adequate
testing for the intended environment.
• There is no, or only a limited description of the quality of the
component and the quality must be assessed in relation to its
intended use.
• The developer, typically, does not have access to the source
code of the component.

18. • Assure COTS components are applied within their intended
profile.
• Understand and document how the COTS components
behave in a faulty situation.
• Use guidelines and tools to deal with supplier changes and
upgrades of the COTS component.
• Determine if future releases of the COTS component are
backward compatible.
• Investigate what development procedure has been used and
if it complies with any reliability standards.