Object-Oriented Software Reuse in Business Systems

Object-Oriented Software Reuse in Business Systems

Daniel Brandon Jr. (Christian Brothers University, USA)
DOI: 10.4018/978-1-60566-026-4.ch456
OnDemand PDF Download:
$30.00
List Price: $37.50

Abstract

“Reuse [software] engineering is a process where a technology asset is designed and developed following architectural principles, and with the intent of being reused in the future” (Bean, 1999). “If programming has a Holy Grail, widespread code reuse is it with a silver bullet. While IT has made and continues to make laudable progress in our reuse, we never seem to make great strides in this area” (Grinzo, 1998). “The quest for that Holy Grail has taken many developers over many years down unproductive paths” (Bowen, 1997). This article is an overview of software reuse methods, particularly object oriented, that have been found effective in business systems over the years.
Chapter Preview
Top

Background

Traditional software development is characterized by many disturbing but well documented facts, including:

  • Most software development projects “fail” (60%) (Williamson, 1999).

  • The supply of qualified IT professionals is much less than the demand (www.bls.gov).

  • The complexity of software is constantly increasing.

  • IT needs “better,” “cheaper,” “faster” software development methods.

Over the years, IT theorists and practitioners have come up with a number of business and technical methods to address these problems and improve the software development process and results thereof. Most notable in this sequence of techniques are CASE (computer-aided software engineering), JAD (joint application development), prototyping, 4GL (fourth generation languages), and Pair/Xtreme programming. While these methods have often provided some gains, none have provided the improvements necessary to become that “silver bullet.” CASE methods have allowed development organizations to build the wrong system even faster, “wrong” in the sense that requirements are not met and/or the resulting system is not maintainable or adaptable. JAD methods tend to waste more of everyone’s time in meetings. While prototypes can help better define user requirements, the tendency (or expectation) that the prototype can be easily extended into the real system is very problematic. The use of 4GL languages only speeds up the development of the parts of the system that were easy to make anyway, while unable to address the more difficult and time consuming portions. Pair programming has some merits but stifles creativity and often requires more time and money.

The only true “solution” has been effective software reuse. Reuse of existing proven components can result in the faster development of software with higher quality. Improved quality results from both the use of previous “tried and true” components and the fact that standards (technical and business) can be built into the reusable components (Brandon, 2000). This improved quality results in lower lifecycle maintenance costs, and since two thirds of software product lifecycle costs are in post-delivery maintenance, this cost savings aspect of reusability is the most rewarding (Schach, 2005). There are several types of reusable components that can address both the design and implementation process. These come in different levels of “granularity” and in both object oriented and non-object oriented flavors.

Key Terms in this Chapter

Framework: A software foundation that specifies how a software system is to be built. It includes standards at all levels both internal construction and external appearance and behavior.

Polymorphism: The ability of object oriented programs to have multiple implementations of the same method name in different classes in an inheritance tree. Derived classes can override the functionality defined in their base class.

Inheritance: A feature of object oriented languages that allows a new class to be derived from another class (a more general class); derived classes (more specific classes) inherit the form and functionality of their base class.

Libraries: A group of functions and/or classes stored separately from the main body of the main program; an “include” file consisting of functions and/or classes.

Encapsulation: The ability to insulate data in a class so that both data security and integrity is improved.

Function: A programming construct where code that does a particular task is segregated from the main body of a program; the function may be sent arguments and may return arguments to the body of the program.

Packages: Similar to a library, but just containing classes.

Method: A function defined inside of a class.

Composition: A new class in an objected programming language that is composed of other classes.

Interface: The specification for a method (“what” a method does); how that function is called from another program. Interfaces are provided in source form as opposed to implementations, which are secure. This allows one to use a method without regard for “how” that method is coded. It also allows multiple implementations of the same interface.

Class: A program construct representing a type of thing (abstract data type), which includes a definition of both form (information or data) and functionality (methods).

Implementation: The code placed inside of methods. For some languages this code is pre-compiled or interpreted.

Patterns: A software library for a common business scenario. A framework may be a design framework (possibly expressed in UML) or an implementation framework (possibly in C++, Java, or PHP).

Reuse: Reuse (software) is a process where a technology asset (such as a function or class) is designed and developed following specific standards, and with the intent of being used again.

Complete Chapter List

Search this Book:
Reset