“Reuse [software] engineering is a process where a technology asset is designedand developed following architectural principles, and with the intent of being reused inthe future” [Bean, 1999]. “If programming has a Holy Grail, wide-spread code reuse is itwith a 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 HolyGrail has taken many developers over many years down unproductive paths” [Bowen,1997]

This paper reports on software reuse research (both literature research anddesign/coding research) and presents an approach for effective softwarereuse in thedevelopment of business systems. This approach is based on ObjectOriented technologyand provides for both the specification and enforcement of software reuse and corporatestandards.

BUSINESS SYSTEMS

Business software systems are typically composed of three logical portions orlayers as shown in Figure 1. The “presentation layer” involves the primary userinteraction typically via a graphical user interface (GUI). The “business logic” layerprovides database connectivity, validation, security, transaction control, and othersequencing or optimization control. This layer may be packaged by a vendor in anapplication or transaction server or written by a user. The “database layer” provides forthe manipulation of persistent data, which for most business systems today is stored in arelational database. The interface to

this process is a well defined standard applicationprogramming interface (API) like ODBC or JDBC using SQL.

NEED FOR REUSE

Today’s software development is characterized by many disturbing but welldocumented facts, including:

Most software development projects “fail” (60% [Williamson, 1997])

The supply of qualified IT professionals is much less than the demand

The complexity of software is constantly increasing

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

“Object technology promises a way to deliver cost-effective, high quality andflexible systems on time to the customer “[McClure, 1996]. “IS shops that institutecomponent-based software development reduce failure, embrace efficiency and augmentthe bottom line” [Williamson, 1997]. “The bottom line is this: while it takes time forreuse to settle into an organization–

and for an organization to settle on reuse–

you canadd increasing value throughout the process”. [Barrett, 1999] We say “object technology”not just adoptingan object oriented language (such as C++ or Java), since one can stillbuild poor, non object oriented, and non reusable software even using a fully objectoriented language.

TYPES AND APPLICATIONS OF REUSE

Radding defines several different types of reusable components [Radding, 1998]:

This article and the research behind it are concerned with the first three types of reuse.

Reusing code has several key implementation areas: application evolution,multiple implementations, standards, and new applications. The reuse of code from priorapplications in new applications has received the most attention. However, just asimportant is the reuse of code (and the technology embedded therein) within the sameapplication.

Application Evolution

Charles Darwin stated that it was not the

biggest, smartest, or fastest species thatwould survive, but the most adaptable. The same is true for application software.Applications must evolve even before they are completely developed, since theenvironment under which they operate (business, regulatory, social, political, etc.)changes during the time the software is designed and implemented. This is the traditional“requirements creep”. Then after the application is successfully deployed, there is aconstant need for change.

Multiple Implementations

Another key need for reusability within the same application is for multipleimplementations. The most common need for multiple implementations involvescustomizations, internationalization, and multiple platform support. Organizations whosesoftware

must be utilized globally may have a need to present an interface to customersin the native language and socially acceptable look and feel (“localization”). The multipleplatform dimension of reuse today involves an architectural choice in languages anddelivery platforms.

Corporate Software Development Standards

Corporate software development standards concern both maintaining standards inall parts of an application and maintaining standards across all applications. “For acomputer system to have lasting value it must exist compatibly with users and othersystems in an ever-changing Information Technology (IT) world. [Brandon, 1999] Asstated by Weinschenk and Yeo, “Interface designers, project managers, developers, andbusiness units need a common set

of look-and-feel guidelines to design and develop by.”[Weinschenk, 1995] In the area of user interface standards alone, Appendix A ofWeinschenk’s book presents a list these standards; there are over three hundred items[Weinschenk, 1997]. Many companies

today still rely on some type of printed “StandardsManuals.”

ACHIEVING EFFECTIVESOFTWARE REUSE

In most organizations, software reusability is a goal that is very elusive, as said byBahrami “a most difficult promise to deliver on”. [Bahrami, 1999]Radding stated:“Code reuse seems to make sense, but many companies find there is so much workinvolved, it’s not worth the effort. …In reality, large scale software reuse is still more theexception than the rule” [Radding, 1998]. Bean in “Reuse 101” states; the currentdecreased “hype” surrounding code reuse is likely due to three basic problems [Bean,1999]:

Reuse is an easily misunderstood concept

Identifying what can be reused is a confusing process

Implementing reuse is seldom simple or easy to understand

Grinzo also list several reasons and observations on the problem of reuse [Grinzo, 1998],other than for some “difficult to implement but easy to plug-in cases” such as GUIwidgets: a “nightmare of limitations and bizarre incompatibilities”, performanceproblems, “thorny psychological issues” involving programmers’ personalities, marketcomponents that are buggy and difficult to use, fear of entrapment, component size,absurd licensing restrictions, or lack of source code availability.

Some organizations try to promote software reusability by simply publishingspecifications on class libraries that have been built for other in house applications or thatare available via third parties, some dictate some type of reuse, and other organizationsgive away some type of “bonus” for reusing the class libraries of others. [Bahrami, 1999]

But more often than not, these approaches typically do not result in much success.

“It’s becoming clear to some who work in this field that large-scale reuse of coderepresents a major undertaking” [Radding, 1998]. “ An OO/reuse discipline entails morethan creating and using class libraries. It requiresformalizing

the practice of reuse”[McClure, 1996].

Based upon both our literature research herein and experimental

implementations,it was concluded that there were two key components toformalizing an effectivesoftware reuse practice

both within an application development and for new applications.These components were:

1. Defining a specific Information Technology

Architecture within whichapplications would be developed and reuse would apply

2. Defining a very specific object oriented “Reuse Foundation” that would beimplemented within the chosen IT architecture

IT Architecture

“If you want reuse to succeed, you need to invest in the architecture first“[Radding, 1998]. “Without an architecture, organizations will not be able to build or evento buy consistently reusable components.” In terms of IT architectures for businesssystems, there are historically several types as: Central Computer, File Services, Two orThree Tier Client Server, and Two or Three Tier Internet (Browser) based. Varioustransaction processing and database vendors have their own “slants” on these basicapproaches, which may depend upon howbusiness logic and the database are distributed.

It was decided to base our implementation research and development on the lastof these categories as shown in Figure 2. Only vendor independent and “open”architectures would be used. The “multiple platform” dimension of reusability would behandled by using Java and Java generated HTML. Internet based applications arebecoming the preferred way of delivering software based services within an organization(Intranets), to the worldwide customer base via browsers and “net appliances” (Internet),and between business (Extranets).

The presentation layer is represented by browser windows using HTML or JavaApplets. The HTML is a static container for the Java Applet or is dynamically generatedby a Java Servlet.The business logic layer is in the form of Java Servlets running on theinformation (Internet) server. The database, typically running on a separate server, isaccessed via JDBC from the Servlets (or even from the Applets if a “type 4” pure JDBCdriver was

used).

Object Oriented Reuse Foundation

As has been concluded by several authors, “A reuse effort demands a solidconceptual foundation” [Barrett, 1999]. The foundation used here is shown in Figure 3,and is called the “Object Oriented Reuse Foundation” [OORF]. It is based on the keyobject oriented principles of inheritance and composition. By establishing thisfoundation, an organization can effectively begin to obtain significant reusability sinceprogrammers must inherit their class from one of theestablished classes and they mustonly compose their class of the established pre-built components.

In the design of Figure 3, an application is composed of a number of ApplicationWindows. Each of these is derived from the Standard Window (or from another windowwhich was derived from the Standard Window) and is associated with a table or view inthat database. The Application Window implements the Standards interface. TheApplication Window is composed of screen fields, which use a specific screen item andare bound to a column of the database table/view. Each screen item implements theStandards and also implements the GUIWidget interface. The GUIWidget interfacedefines the functions that all screen items provide (such as: requestFocus, setText,getText, isValid, etc.). The screen items can be from the Java AWT, Java Swing, or thirdparty class libraries as long as these class library sources have been extended to use thedata in the Standards. The Standards interface defines all the standards used throughoutthe system including: fonts, colors, styles, sizes, initial states, icons, etc.

While Figure 3 shows the conceptual OORF, there would typically be aninheritance hierarchy of Standard Windows including forms, tables, etc. Screen Itemswould be a

hierarchy also for the different types of these widgets such as textboxes, radiobuttons, choice buttons, etc. Each application could also create an inheritance hierarchyof application windows.

Figure 4 shows a generated application window which provides navigation andupdate support for a selected database table including automatic lookup of definedforeign keys to maintain referential integrity. The reusability for this example was 95%,that is 95% of the lines of code were already in the OORF. For the applicationsimplemented thusfar, all obtained reusability of over 90%.