Software Reuse

1
Software Reuse

• CSE301
• Harry R. Erwin, PhD
• University of Sunderland

2
Resources

• This lecture is about how to think critically
  about reuse.
• Martin, R. C., 2003, Agile Software Development,
  Prentice-Hall.
• Schmidt, D. C., 2003, Why software reuse has
  failed and how to make it work for you,
  http//www.cs.wustl.edu/schmidt/reuse-lessons.htm
  l
• Radding, A., 1998, Hidden Costs of Code Reuse,
  http//www.informationweek.com/708/08iuhid.htm

3
Why Reuse Software?

• What we most need are systems that are
• Portable
• Flexible
• Extensible
• Predictable
• Efficient
• Reliable
• (Schmidt, 2003)
• Software meeting these qualities is hard to
  develop (and even harder to develop for reuse).

4
Software Economics and Reuse

• Highly skilled software professionals are rare
  and expensive (12,000/person-month (PM)
  including overhead).
• Productivity is low for essential and critical
  systems development (100-320 lines of code per
  PM).
• Modern systems are large (100-10000 PM) and
  costly (1M-100M).
• Reuse can reduce these costs by three to
  ten-fold.
• However, initially developing the software for
  reuse triples (x3) the cost. (Radding, 1998)
• So reuse has a delayed payoff.

5
Why Does Reuse Fail?

• Communicationshow to make requirements reflect
  both programmer and business needs?
• Economicswho pays for it?
• Administrationwho maintains the reuse libraries?
• Politicsrice bowls.
• Psychologicalprogrammer resistance, NIH (not
  invented here).
• Technicalhow do you organize it?
• (Schmidt, 2001)

6
What is Reuse?

• Components, frameworks, and applications are what
  you reuse.
• Components are self-contained instances of
  abstract data types that can be plugged together
  to create complete applications.
• Frameworks are integrated collections of classes
  that support the following
• System infrastructure
• Middleware integration
• Enterprise applications
• Both live in packages.

7
What do you reuse?

• GUI objects
• Server-side components
• Infrastructure components
• Services frameworks
• High-level patterns
• Packaged applications
• (Radding, 1998)

8
GUI Object Reuse

• Easy to achieve
• Often requires no code development
• Improves quality and consistency
• Implications good practice, but not a big cost
  driver, so does not save much money

9
Server-Side Components

• Reusable business logic
• Significant potential for pay-back
• Require extensive front-end analysis and design
• Have to be provided an architectural foundation
• Require protection as trade secrets
• Become obsolete fairly rapidly

10
Infrastructure Components and Services Frameworks

• Provide standards-based generic services for
  transaction processing, messaging, security, and
  database access
• Require extensive analysis and design and complex
  programming
• Often available as commercial off-the-shelf
  (COTS)
• Make versus buy decision

11
High-Level Patterns

• Will be addressed later in this module
• Support design reuse
• Must be programmed or purchased

12
Packaged Applications

• Guaranteed reuse
• Not necessarily a close match to the user
  requirements, so customization may be required
• Locks the customer into the vendor, which is good
  for the vendor but not so good for the customer
• End of life issues, as well