Software Reuse

CSE301Harry R. Erwin, PhD

University of Sunderland

ResourcesThis 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.html

• Radding, A., 1998, “Hidden Costs of Code Reuse,” http://www.informationweek.com/708/08iuhid.htm

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).

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.

Why Does Reuse Fail?

• Communications—how to make requirements reflect both programmer and business needs?

• Economics—who pays for it?• Administration—who maintains the reuse libraries?

• Politics—“rice bowls”.• Psychological—programmer resistance, NIH (“not invented here”).

• Technical—how do you organize it?(Schmidt, 2001)

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.

What do you reuse?

• GUI objects• Server-side components• Infrastructure components• Services frameworks• High-level patterns• Packaged applications

(Radding, 1998)

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

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

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

High-Level Patterns

• Will be addressed later in this module

• Support design reuse• Must be programmed or purchased

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