Software Reuse and Component-Based

Software Engineering
 Software Reuse
• 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.
 Types of Software Reuse
• Application System Reuse
– reusing an entire application by incorporation of one
application inside another (COTS reuse)
– Commercial Off-the-Shelf Software(COTS)
– 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
 Development Reuse as a Goal

Modify requirements
Outline Search for accor ding to
system reusable discovered
requirements components components

Specify system
Search for components
Architectur al
reusable based on reusable
design
components components
 Benefits of Reuse
• 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
Requirements for Design with Reuse
• You need to be able to find appropriate reusable
components
• You must be confident that that component you
plan to reuse is reliable and will behave as
expected
• The components to be reused must be documented
to allow them to be understood and modified (if
necessary)
 Reuse Problems
• Increased maintenance costs
• Lack of tool support
• Need to create and maintain a component library
• Finding and adapting reusable components
 Component-Based Software
Engineering(CBSE)
• CBSE is an approach to software development that relies
on reuse.
• CBSE emerged from the failure of object-oriented
development to support reuse effectively.
• Objects (classes) are too specific and too detailed to
support design for reuse work.
• Components are more abstract than classes and can be
considered to be stand-alone service providers.
 Component Abstractions
• Functional Abstractions
– component implements a single function (e.g. ln)
• Casual Groupings
– component is part of a loosely related entities like declarations and
functions
• Data Abstractions
– abstract data types or objects
• Cluster Abstractions
– component from group of cooperating objects
• System Abstraction
– component is a self-contained system
 Engineering of Component-Based
Systems - part 1
• Software team evoke  system requirements
• Architectural design is established
• Team determines requirements are amenable to composition
rather than construction
– Are commercial off-the-shelf (COTS) components available to implement the
requirement?
– Are internally developed reusable components available to implement the
requirement?
– Are the interfaces for available components compatible within in the
proposed system architecture?
• Team attempts to remove or modify requirements that cannot
be implemented with COTS or in-house components
 Engineering of Component-Based
Systems - part 2
• For those requirements that can be addressed with
available components the following activities take place:
– component qualification
– component adaptation
– component composition
– component update
• Detailed design activities commence for remainder of the
system
 Definition of Terms
• Component Qualification
– candidate components are identified based on services provided and means
by which consumers access them
• Component Adaptation
– candidate components are modified to meet the needs of the architecture or
discarded
• Component Composition
– architecture dictates the composition of the end product from the nature of
the connections and coordination mechanisms
• Component Update
– updating systems that include COTS is made more complicated by the fact
that a COTS developer must be involved
Commercial Off-the-Shelf Software
• COTS systems are usually complete applications
library the off an applications programming
interface (API)
• Building large systems by integrating COTS
components is a viable development strategy for
some types of systems (e.g. E-commerce or video
games)
 Reusable Components
• Tradeoff between reusability and usability
– generic components can be highly reusable
– reusable components are likely to be more complex and
harder to use
• Development costs are higher for reusable
components than application specific components
• Generic components may be less space-efficient
and have longer execution times than their
application specific analogs
 Software Maintenance

• Software maintenance is a part of the Software Development Life

Cycle. Its primary goal is to modify and update software application
after delivery to correct errors and to improve performance.

• Software is a model of the real world. When the real world changes,
the software require alteration wherever possible.

• Software Maintenance is an inclusive activity that includes error

corrections, enhancement of capabilities, deletion of obsolete
capabilities, and optimization.
 Need for Maintenance

Software Maintenance is needed for:-

•Correct errors
•Change in user requirement with time
•Changing hardware/software requirements
•To improve system efficiency
•To optimize the code to run faster
•To modify the components
•To reduce any unwanted side effects.
Types of Software Maintenance
1. Corrective Maintenance: Corrective maintenance aims to correct any remaining errors
regardless of where they may cause specifications, design, coding, testing, and
documentation, etc.

2. Adaptive Maintenance: It contains modifying the software to match changes in the ever-
changing environment.

3. Preventive Maintenance: It is the process by which we prevent our system from being
obsolete. It involves the concept of reengineering & reverse engineering in which an old
system with old technology is re-engineered using new technology. This maintenance
prevents the system from dying out.

4. Perfective Maintenance: It defines improving processing efficiency or performance or

restricting the software to enhance changeability. This may contain enhancement of
existing system functionality, improvement in computational efficiency, etc.
 Integrated change control
• Integrated change control is the process of reviewing all change
requests within a project, analyzing those requests and implementing
approved changes.
• They can also determine the effects of a proposed change before
implementation, allowing them to make better decisions for the
project.
 Formal technical review (FTR)
• Formal technical review (FTR) is a software quality control activity
performed by software engineers (and others).
• The objectives of an FTR are:
– (1) To uncover errors in function, logic, or implementation for any
representation of the software;
– (2) To verify that the software under review meets its requirements;
– (3) To ensure that the software has been represented according to
predefined standards
– (4) To achieve software that is developed in a uniform manner;
– (5) To make projects more manageable. In addition, the FTR serves as a
training ground, enabling junior engineers to observe different approaches
to software analysis, design, and implementation
• The FTR is actually a class of reviews that includes walkthroughs
and inspections
 Steps in FTR
1. The review meeting
•Every review meeting should be conducted by considering the following constraints-
•Involvement of people
•Between 3 and 5 people should be involve in the review.
•Advance preparation Advance preparation should occur but it should be very short
that is at the most 2 hours of work for each person can be spent in this preparation
•Short duration The short duration of the review meeting should be less than two hour.

2. Review reporting and record keeping

•During the FTR, the reviewer actively record all the issues that have been raised.
•At the end of meeting these all raised issues are consolidated and review issue list is
prepared.
•Finally, formal technical review summary report is produced.
3. Review guidelines
• Guidelines for the conducting of formal technical review must be established in advance.
These guidelines must be distributed to all reviewers, agreed upon, and then followed.
• For example,
• Guideline for review may include following things
• Concentrate on work product only. That means review the product not the producers.
• Set an agenda of a review and maintain it.
• When certain issues are raised then debate or arguments should be limited. Reviews
should not ultimately results in some hard feelings.
• Find out problem areas, but don’t attempt to solve every problem noted.