An Asset-Based Approach to Improving Software Reusability

An Asset-Based Systems Development Approach to Software Reusability
Author(s): Jahangir Karimi

Source: MIS Quarterly, Vol. 14, No. 2 (Jun., 1990), pp. 179-198
Published by: Management Information Systems Research Center, University of Minnesota
Stable URL: http://www.jstor.org/stable/248776
Accessed: 07-12-2016 05:54 UTC
JSTOR is a not-for-profit service that helps scholars, researchers, and students discover, use, and build upon a wide range of content in a trusted
digital archive. We use information technology and tools to increase productivity and facilitate new forms of scholarship. For more information about
JSTOR, please contact support@jstor.org.
Your use of the JSTOR archive indicates your acceptance of the Terms & Conditions of Use, available at
http://about.jstor.org/terms
Management Information Systems Research Center, University of Minnesota is

collaborating with JSTOR to digitize, preserve and extend access to MIS Quarterly
This content downloaded from 175.45.191.252 on Wed, 07 Dec 2016 05:54:29 UTC
All use subject to http://about.jstor.org/terms
Software Reusability
An Asset-Based
Introduction
Systems
opportunity for improving software productivity
Development
Approach to
Software reusability is viewed widely as a major
(Biggerstaff and Richer, 1987; Boehm, 1987a;
Software
Horowitz and Munson, 1984; Standish, 1984). Improving software productivity is critical because
of the magnitude of software costs. These were
estimated at roughly $70 billion in 1985, and at
Reusability
(Boehm, 1988). Although in principal software
over $125 billion by 1990 for the U.S. alone

reusability is a straightforward concept, there has
not been significant progress in making it
By: Jahangir Karimi
College of Business and

Administration
University of Colorado at
Denver
1200 Larimer Street (Box 165)

Denver, Colorado 80204
practical.
Studies of software reuse are contradictory but
agree that, on average, one-half of all code from
one application is reusable in another (Biggerstaff
and Perlis, 1984; Lanergan and Grasso, 1984),

and as much as 85 percent of code is reusable
for some applications (Jones, 1984). In addition,
it is believed that software reusability plays a central role in software productivity, maintainability,
quality, portability, and standards (Bassett, 1987;
Wong, 1986). Many organizations view software

reusability as a technology that must be developed to ensure future competitiveness (Joyce,
1988; Prieto-Diaz and Jones, 1987; Swanson and
Curry, 1989).
Lack of a clear reuse strategy has been identified
as one of the major factors inhibiting widespread
software reusability (Biggerstaff and Richer, 1987).
The absence of an appropriate top-management

reuse strategy results in project managers and pro-
Abstract
Software reusability has been viewed as one of the
major opportunity areas for improving software
productivity. An overview of software reusability
research suggests that the traditionalapproach to
software development is inappropriate for the development of reusable software parts. An organizational strategy for making software reusability
practical is needed. An asset-based systems development method, based on this strategy, focuses
on the development of information assets designed to be reused. It also facilitates identifying,

representing, and classifying information assets.
Keywords: software reusability, software productivity, information systems architec-
ture, information asset, semantic
modeling, abstraction, objectoriented systems development
ACM categories: D.2, D.2.9, D.2.m, D.3.3
grammers being unmotivated to reuse software,

as well as management resistance toward allocating the up-front costs required to put software reuse
into practice (Tracz, 1987a; 1987b).

Project managers and software developers often
lack confidence in reusable software parts, and
they frequently have little incentive to mandate
software reusability. Many feel threatened that
software reuse will lead to potential cuts in their
own budgets and resources (Wong, 1986). As

noted by Wong, "in terms of software contractors,
the reuse of software may be in conflict with pro-
fit for developing, implementing, and maintaining a custom-built software application.. .there
is often resistance to change and Not-lnventedHere syndrome" (p. 7).
Project managers' emphasis has focused on
delivered lines of source code rather than on im-
proving productivity of the software development
MIS Quarterly/June 1990 179
process. This is in part due to the fact that demand for new software is increasing faster than
our ability to develop it (Boehm and Papaccio,
1988). Boehm and Papaccio report that "the U.S.
Air Force Data Systems Design Office has identified a four-year backlog of important business
data processing software functions which cannot
be implemented because of limited supply of per-
sonnel and training . ..the software backlog

creates a situation which yields a great deal of
bad software" (p. 1462). Both the project managers' short-sighted view and the software backlog
have resulted in a lack of commitment to development of the tools and training method needed to
make software reuse practical. Two factors are

likely to motivate top management to mandate
software reusability. The first is from within the
organization, where key decision makers may advocate an optimum reuse strategy. The second
is from without, where competitors' increased application of reuse may force the issue.
Programmers are also reluctant to reuse software
for a number of reasons. It is more difficult to locate,
understand, and modify existing software parts

than to create new ones, especially if the original
implementation lacks quality or is not designed for
reuse. There is a lack of emphasis on software

reuse by management/analysts, academic training courses, and traditional systems development
life cycle processes and tools. Woodfield, et al.
(1987) report that programmers untrained in reuse
have difficulty evaluating reusability of a candidate
software part.
A number of U.S. companies are reaping significant productivity increases due to cost savings
associated with software reuse (Joyce, 1988;

Prieto-Diaz and Jones, 1987; Swanson and Curry,
1989). These gains have been accomplished by

specific actions from upper management: (1) identifying reusabililty as a corporate objective for the
technical staff; (2) instituting company-wide,

organized efforts to plan for reuse; and (3)
establishing programmers' incentives for each soft-
ware part accepted for a reuse library.

Matsubara, et al. (1981) describe a Japanese software factory that has made an organized effort
toward software reusability. By making a decision
to commit to standards and to recognize software
reuse leverage, the factory has justified the cost
of developing a critical mass of reusable software
parts (Matsubara, et al., 1981).
Although reusability can be gained at different
stages of the software development process,

gaining it at the code level has long been an
ultimate objective (Mcllroy, 1969). However, efforts to achieve this have not been entirely suc-
cessful. One of the major problems concerns

understanding whether the available code needs
to be modified. This is especially important when
a user needs to extend the functionality of a
module to be reused. Biggerstaff (1989) notes
that a great deal of time is spent trying to

reconstruct the software's design from the source
code mainly because "the source code does not

contain much of the original design information
... such informtion has existed only in the minds
of expert software engineers or application domain specialists" (p. 39). Tracz (1988) and Wong
(1986) also suggest that ad hoc reuse is more difficult than preplanned reuse. In fact, ad hoc reuse
attempts often fail.
Subroutine libraries and numerical computation

routines are relatively successful cases of code
reuse. According to Horowitz and Munson (1984),
there are specific reasons for the success of the
approach: (1) the limited and identifiable routine
functionality offered by a few parameters that af-
fect routine operation in a well-defined manner;

(2) the utility of the routines in a new application
regardless of the language used; and (3) the wellunderstood routine domains that allow the identi-
fication of standard functions and/or data types

that are reusable in related applications.
There are limited payoffs associated with reusing code, especially undocumented or unstructured code, relative to the cost of the resources
required to adapt the code to a new implementation and to new application requirements. This
limit is also defined by the functionality or performance considerations of a new application.
Considering that only about 15 percent of software development effort is devoted to coding in
best project practices (Boehm, 1987b), the code
reusability payoffs quickly reach a maximum due
to the limited efforts usually spent on coding and
the amount of code that can be reused.
Reusability at the design stage emphasizes reuse

at the time of analysis and design, not after the
implementation has been completed. A number
of studies suggest that design for reusability is
the only way software designers can approach
an order-of-magnitude increase in productivity or
quality (Biggerstaff and Richer, 1987). Lanergan
180 MIS Quarterly/June 1990
and Grasso (1984) report that by standardizing

and reusing design information and logic structures, a 50 percent gain in productivity is achieved
in the development environment. Reuse potential is enhanced at the design level because implementation decisions reduce generality of the
design information. Modules become less
reusable the more specific they become because
Overview of Software
Reusability Research
Previous research has shown that the adaptability
or reuse potential of a software part depends
largely on the degree to which the domain
analysis is performed to understand application

domains and gather reusable analysis and design
it is difficult to match detailed specifics. The sucinformation (Biggerstaff and Richer, 1987; Prietocess of the Japanese software factory, which also
Diaz, 1987; Tracz, 1987b). The domain analysis

is necessary to identify common concepts, e.g.,
development process and products, is also atobjects, operations and the relationships, that will
tributed to design-level reusability (Matsubara, et
form the basis for creating reusable software
al., 1981). The software parts are designed at the
parts. Exploiting such a knowledge of a particular
outset with reuse in mind.
application domain has also been associated with
software productivity improvements (Boehm,
Reusability at the design level is viewed as more
1987).
advocates the formalization of the software
important than reusability at the code level
because (1) design activities introduce 50 percent An approach by Neighbors (1984) advocates usto 60 percent of all defects during the developing domain analysis to identify sets of common
ment phase (Pressman, 1987), and (2) the cost concepts in a particular application domain; in
of fixing or reworking software in the earlier this approach, common concepts are recorded
phases of software life cycle is much smaller (by using a domain-specific language. Neighbors
factors of 50 to 200) than in later phases (Boehm, suggests that each domain yields a different do1988). Because at the design level there are more main representation language. The common condefects introduced and less costs associated with
cepts are given to a domain designer who
removing those defects than at the code level,
specifies implementation for these concepts in
a huge productivity gain is achievable by develop-
ment of high-quality reusable design parts.
terms of other concepts already identified in that

domain. System requirements for a new applica-
Technical problems associated with reusability

at either design and/or code levels are due to a
lack of methodologies and tools for: (1) identify-
tion are considered in light of concepts already

identified. By developing several systems for the
same domain, a reuse of the domain analysis is
achieved. However, as detailed by Horowitz and
ing reusable software parts; (2) representing

design information successfully; (3) classifying
parts and implementation of an easily accessible, interactive parts catalogue; (4) translating
and/or re-customizing of parts into an implemen-
tation language, and (5) composing parts into a

final system.
This article proposes a strategy for improving
software reusability within an organization. The
strategy is for long-term organizational strategic
advantage rather than short-term systems devel-
opment objectives. Also proposed is a method

to reduce the scope of technical problems. The
following overview of software reusability research highlights how the proposed method extends and supports previous software reusability
research and how it differs from the previous ap-
proaches. The proposed method and comparative

review should be of special interest to practitioners
and researchers.
Munson (1984), this approach is inherently limited

by a potential growth in domain languages, each
of which must be mastered simultaneously.
Fischer (1987) also emphasizes the importance

of domain analysis and domain-related abstractions in making reuse and redesign possible. He
suggests the need for an intelligent design environment that keeps track of the levels of abstrac-
tions in a software design process. The levels of

abstractions are generated throughout the entire
process, from determination of system level requirements until implementation at the language
level. Such an intelligent system facilitates reuse
and redesign by allowing the user to change intermediate abstractions to form a slightly different
system. But to do this the design of the intermediate abstraction levels must be an integral
part of the software design process.
Studies have shown that the reuse potential of a

software part depends largely on the degree to
which the identified part, called a building block,

is parameterized to facilitate the customizing pro-
cess (Kaiser and Garian, 1987; Lenz, et al., 1987).

A semantic representation system allowing the
representation of reusable design information in
factored form has been recommended (Biggerstaff
and Richer, 1987; Prieto-Diaz and Freeman, 1987).
development. The user decides which data types

are needed and provides a full set of operations
for each needed type. A difficult decision in

systems development using either Ada or objectoriented languages is determining which data type
is needed. Making the decision correctly is very
important; it affects the reusability, maintainabili-
Two recent developments allowing for representation of software parts in parameterized and factored forms are the Ada programming language
and object-oriented approaches.
ty, and extensibility of the parts (systems) that are
Ada is a programming language designed to
development strategy for identifying reusable

design information is described. Differences be-
facilitate reusability. Ada reusability guidelines
are structured to include design for reuse,

parameterization, and domain analysis. There
have been extensive efforts by industry groups
and research consortiums to realize software
developed using this approach (Halbert and

O'Brien, 1987).
In the next section, an asset-based system
tween this strategy and the traditional application

development are highlighted. This is followed by
a description of a method for identifying information assets based on this strategy. Domain analysis
and domain-related abstractions are the key

reuse with Ada (Tracz, 1987c). However, as sugfeatures used to identify reusable design informagested by Tracz (1987c), proposing a method for
developing software based on reusable parts tion.
is The method identifies the commonality
among processes and datatypes and identifies aplanguage-independent; this is still an open area
for research.
propriate types. These are the keys for developObject-oriented approaches seem to be the most
promising methods for generating reusable software parts and composing systems (Meyer, 1987;
Tracz 1987a; 1987b). Instead of building software
modules by focusing on functions or detailed processing steps and sending datatypes between the
resulting modules, these approaches use data

types as the base for modularization and defining
objects. In an object-oriented approach, the data

types and their operations are grouped together
as objects (types). Functions are performed by
sending messages to the objects.
Inheritance is a key feature in an object-oriented
approach toward reusability (Meyer, 1987; 1988;
Stroustrup, 1988). With inheritance, new types
(object-classes) may be defined by extension,

specialization, and combination of previously
defined types. The commonality between types is
made explicit and is exploited by using the inheri-
tance mechanism. Class (type) inheritance promotes code and design reuse because the code
shared by several classes can be placed in its com-
mon superclass, and new classes can start with

the code available in the superclass. The management of the composition of data types is achieved
through object classes and class inheritance
mechanisms.
ing reusable software parts using either functional
or object-oriented approaches.
An Asset-Based Systems
Development Strategy
The asset-based systems development strategy
proposed in this article emphasizes reusability at
the design level rather than at the code level. It
plans for software reuse at the organizational level
through an integrated approach to systems

development.
Figure 1 represents an asset-based systems

development strategy. This strategy takes into account how the organizational strategic plan must
derive the information systems strategic plan

which, in turn, determines the information systems
architecture (ISA) components. In this article,

these components are called information systems
assets. The ISA planning, modeling, and design
activities are viewed as a means for proactive planning for the assimilation of technology in the
organization (Devlin and Murphy, 1988; Karimi,
1988; Wardle, 1984; Zachman, 1987). This results
in improved efficiency and effectiveness of the in-
formation systems resources.
Data types and typing, i.e., identifying new typesThe strategy shown in Figure 1 is different from
in relation to already defined types, are the majortraditional application-based systems develop-
organizing principles in object-oriented systemsment strategies (see Guimaraes, 1985) in many
Organizational
Strategic Plan
Information Syst( ems Information Systems

Architecture
Strategic Plan
Information
Assets
Application
Assets
Data
Assets
Figure 1. Asset-Based Systems Development Strategy

ways; there are differences in planning, organizalong-term goals to short-term systems develoption, administration, and control of information
ment objectives.
resources. Such astrategy is needed because the

traditional, application-oriented approach to
system development is inappropriate for develop-
ing reusable software parts. The traditional approach fails to focus on: (1) planned reuse; (2)
system development from an integrated perspective; and (3) long-term organizational strategic advantage. The strategy in Figure 1 requires moving
away from traditional, stand-alone applications
development toward an integrated approach that
views systems development from an organizational perspective. It makes long-term commitments to organizational needs and translates
The proposed strategy is an extension of the concept of information assets taken from the datadriven or data-oriented concepts proposed by the
National Bureau of Standards Fifth Database
Workshop, as reported in Appleton (1986a). The

NBS proposed five data assets: acquisition, storage, manipulation, retrieval, and distribution.
Based on this strategy two distinct types of information assets are identified that are useful for im-
proving application software reusability. These are
application assets and data assets.
Application assets refer to design components/
To identify information assets, the data and pro-
abstractions, e.g., logic structures, repeated many

times across applications. By identifying and stan-
cesses making up the ISA need to be integrated
dardizing these abstractions and defining them

logically in a single place, the potential for redundancy at both design and code levels is addressed
suggests an approach for such an integration
priorto implementation. When the design information is not identified and defined logically across
applications in an integrated manner, it cannot be
constructed and maintained in a single place; it
cannot be reused.
Data assets are associated with application

assets. They capture objects, classes of objects,
operations, and relationships in application
assets as semantic data models. This knowledge
captures the meaning of the application assets
and encompasses the implicit and explicit restric-
tions placed upon objects, operations, and relationships associated with the application assets.
Capturing semantic knowledge associated with
the application assets makes it possible to implement, reuse, and maintain application software easily by using vocabularies that relate
directly to the meaning of the applications.
Although the concepts of asset and asset development are not new (Appleton, 1986b), proposing a method for identifying design abstractions
to create information assets has not been ad-
at an organizational level. Inmon (1984; 1986)
process. Extending on Inmon's approach, the

following method can be used for identifying information assets: (1) identify the scope of integra-
tion; (2) build a semantic model of the scope; (3)

identify application and task categories; and (4)
identify application and data assets. These steps
are detailed below in an example adopted from
Inmon (1986).
Identifying the scope of

integration
The scope of integration is defined as a statement
of which data and processes requirements are

to be included in the integration process and
which are to be excluded. Determining the "right
scope" is a strategic decision. It consists of

balancing the long-range and short-term goals of
the organization and distinguishing what can be

done from what would be nice to do.
Integration can be done at several levels: subsystem (module); functional (application); and
operational mode (decision support, administra-
tive, operational). Each scope of integration
dressed before. As Appleton (1986a) notes, the

should contain only one operational mode, but
traditional approach to software development not
scope of integration may cover broad functional
only ignores information assets and assets delines. For example, operational systems are
velopment but also does not take into account
usually separate from administrative systems.
the possibility of reusing assets. Appleton states
further that the development of data assets is still
"black magic" in most projects. He advocates

Building
a semantic model of
that a project team define assets during planning

the scope
and that new system requirements be defined in
Both a top-down and bottom-up analysis should
terms of existing assets.
be used in any integrated modeling process. A
bottom-up analysis assures that all details are accounted for; but alone it cannot guarantee identification of major components and the inherent
Information Assets
structure of the system. In contrast, a top-down
analysis alone cannot guarantee that all details
The method proposed allows identification of the
of processes and data are represented.
commonality among data and process types, the
bases for identifying information assets. By idenSemantic modeling techniques are viewed as
tifying commonality at the organizational level,
ways of integrating and formalizing information
multiple development and maintenance efforts
systems requirements (Hull and King, 1987; Potare avoided. At the applications design level
ter and Trueblood, 1988). The important result
redundancies are consolidated and information
of semantic model research is the development
assets are constructed and maintained once,
of mechanisms for representing the structural
even though they may exist physically in multiaspects of business data using objects, attriple applications at the implementation level.
butes, type constructors for building complex
A Method for Identifying
types, and IS-A relationships (e.g., IS-A type-of,

IS-PART-OF, IS-INSTANCE-OF).
In semantic modeling any concept or thing is first
identified as an object; the objects are then

organized into object-types or classes. Relationships between objects are viewed using different
abstraction mechanisms; generalization, aggregation, or classification (Smith and Smith, 1977).
In generalization, similar objects are abstracted
into higher-level object-types via the ISA/SUBSET-OF relationship. This allows a
designer to view similar objects relative to a more
generic object. In aggregation, an object is

related to its sub-components via IS-PART-OF
relationship. This allows a designer to model an
abstract object based on the properties or attributes of the object. Aggregation, therefore, in-
volves specifying the structural components of

an object. In classification, specific instances of
object-type are related to a higher-level objecttype via the IS-INSTANCE-OF relationship.
the subtypes are defined from these in a topdown fashion.
As an example, assume the financial system of

a bank is chosen as the scope of integration to
be decomposed according to lines of internal

organization of the bank as shown in Figure 2.
The semantic modeling of this scope, however,
emphasizes the business of the corporation

rather than the organizational structure of the cor-
poration; the mechanism used to relate the object types concerns function of the types. In
Figure 2 the IS-A relationships are undirected
and, like knowledge representation in artificial in-
telligence, when using semantic networks each

object is represented by a node.
In decomposition the intent is to select common
processes at each level of decomposition by
In semantic modeling of the scope of integration,
generalization abstractions. However, as shown

in Figure 2, at each level of decomposition (e.g.,
commercial, retail) each activity has functions
unique to itself. For this reason, retail banking
is subdivided further. The decomposition stops
the goal is to ensure that all major objects are

represented and appropriately related to each
at the point of lowest functional distinction; that

is, at the point at which the functional activities
other. Semantic modeling with a top-down

analysis is similar to a decomposition process in
which the base object types are defined first and
cannot be subdivided into a lower set of distinc-
tive functions. Decomposition stops at the car

loans and the signature loans because the subac-
Financial Systems
c s-Aon Support Oe AdIs-A
Decision Support Operational Adminis strative
Commercial Retail Payoll Persnnel nsuance Employee

Benefit
General Mining Farm Timber Demand-Deposit Loan Time-Deposit Credit Card
A A A A Account Account Account Account

Loans Cash Loans Cash Loans Cash Loans Cash Home Car Signature Passbook Certificate
Mgmt Mgmt Mgmt Mgmt of Deposit
Money Market Assets Zero Balance Fixed Variable
Figure 2. Generalization Abstractions of the Financial Systems of
tivities of these activities, e.g., interest loan

calculations, are not useful to distinguish between a car loan and a signature loan.
Semantic modeling is done at the data level. On
the data view side, entity-relationship diagrams
(ERDs) are derived for the scope of integration
(Chen, 1976). The most fundamental difference
between an ER model representation and the

representation above is the absence of the IS-A
relationship in the ER representation. Also, in the
ER model the use of attributes and relationships
is restricted; attributes may be defined on both

object-types and relationships; relationships are
given a name and are viewed as entities them-
selves. Relationships in an ER model can be

viewed as aggregation abstractions.
In building the global ERD, as with the generalization hierarchy in Figure 2, emphasis is on selecting common entities. In Figure 2, operational
systems could be divided into two separate
mercial and the retail business of the bank. The
entities and relationships within the scope of integration are consolidated using generalization/
aggregation abstractions to construct the global
ERD represented in Figure 3.
Figure 3 illustrates a global ERD representing the
financial activities that occur inside the bank.
Management of an account is the highest level

of abstraction within the scope of integration. In
this context, "account" can be either an extension of the bank's money or resources to an individual or enterprise with the expectation of
repayment, i.e., a loan, or it can be the acceptance of money by the bank for steward-ship,
e.g., a savings deposit. The global ERD is useful
to identify (1) relevant data inside the scope of
the integration; (2) the primary business of the
corporation at the highest level of abstraction;
and (3) application and task categories.
ERDs: a commercial ERD and a retail ERD.
Identifying application and
ERD is constructed that reflects both the com-
same level of abstraction as the global ERD
task categories
However, because of the commonality of entities
and processes in the two modes of operation,
Primary
one business processes are identified at the
Figure 3. Global ERD for a Retail Business of a Bank
model shown in Figure 3. The focus is on identifying all processes that are fundamentally different; once the primary processes are identified
they are defined and the processing cycle is
identified.
As shown in Figure 4, the primary business pro-
cesses common to the global ERD are accep-
tance of account, establishment of terms of

account between bank and the customer, transaction against account (e.g., payment, credit),
and account-related calculations. Using aggregation abstractions for each of the primary business
processes, the functional activities (application
categories) of the bank are identified. Four application categories representing the bank's four
major accounts are: loan, demand-deposit, timedeposit, and credit card.
Both loan and time-deposit accounts are forms

of "managing accounts." While the bank may
manage other types of accounts (e.g., trust accounts), the major bank accounts are included
in the application categories. Also, more specific
banking services, such as interest payment, in-
terest collection, and activity charges can be
classified as a subset of the four basic accounts

identified.
Using aggregation abstractions, the application

categories are expanded to subactivities. Figure
5 shows the subactivities of each application

category.
For each application category (e.g., loan), unique
subactivities (e.g., get credit check), and common
subactivities across application categories (e.g.,
accept payment), are identified. Unique subac-
tivities account for minor differences between the
Primary
Acceptance of
Business
Processes
Account
cessing cycle. They are not considered to be part

of the primary business of the corporation and
are ignored during identification of application
and task categories.

Common subactivities are repeated in many application categories. These subactivities are con-
solidated across application categories by

generalization abstractions in order to form the
two generic task categories shown in Figure 6:
credit and payment. Using classification abstractions, generic task categories are related to application categories, as shown in Figure 7.
Using aggregation abstractions, task categories

are decomposed to detail subtask level in order
to identify the common processes of each task
category. The relationships of each application
category to the task categories and to the common processes at a lower level of abstraction are
shown in Figure 8.
Identifying application assets

The common processes for each task category
are the basis for reusable design information.
Table 1 relates the application categories to the
credit task category and the common processes.
As shown in Table 1, the common processes

serve the same concepts across application
categories; their detailed processing steps,
however, are slightly different at the implementation level.
The standardized forms of the design information

are the information assets that can be reused
Establishment of
Transaction Account Related
Terms of Account
Against Account Calculations
^^^^><v s- ^^.^Is-Part-of
Is-Part-of
Appllcatlo n Loan _
Categorle. s Account
application categories that are most often related

to errors and exceptions that are a part of the pro-
Demand-Deposit _ Time-Deposit _ Credit Card

Account
Account Account
Figure 4. Primary Business Processes and A
MIS Quarterly/Jun
Figure 5a. Sub-Activities of Each Application Category
across applications. By standardizing the definition of this design information, multiple implementation and maintenance efforts are
avoided across applications. Standardization of
the design information for the purposes of application assets representation and classification
can be done using either functional or objectoriented approaches. The selection of a particular
approach is influenced highly by the represen-
tation and implementation languages already
used in the organization and the organization's

plans for future use of those languages.
Functional Approach
The functional approach to standardizing common processes can be achieved by specifying in-
put, output, and detail-processing steps. The

generalized application assets (common processes) comprise the code skeleton common to
Credit Card Account
Is-Part-of
Is-Part-of
Accept Usage
of Credit Card;
Get Credit Check
Set Credit Card Pay Calculate
Accept
Terms; Merchant Interest; Payment

Set Rates;
Set Charges; Charges Balance
Issue Cards
Demand-Deposit
Account
Set Checking
Open
Account
Terms;
Issue Checks;
Set Charges;
Accept Calculate
Deposit Interest;
Pay
Checks
Balance
Set Limit;
Set Fees
Figure 5b. Sub-Activities of Each Application Category

all specific applications. The related application
program can be constructed by specifying those
parts that have been left open in the generic application asset. In Figure 9, the representations
of "verify date" and "amount of payment" are
given in a pseudocode style using the functional
approach. From this representation it is easy to
see how pseudocode specification can be translated into a programming language.
For classification purposes, generalization/

specialization rules can be specified for each task
category. These specialization rules can consist
of rules for constants, procedures, and interfaces,
s-A
Is-A
Accept Pay
Deposit Merchant
(Time- (Credit
Deposit) Card)
Pay Loaned
Amount
(Loan)
Accept
Deposit
(DemandDeposit)
Payment
AK~
Is-A
Accept
Payment
(Loan)
s-A
Pay Accept
Withdrawl Payment
(Time- (Credit
Deposit) Card)
Pay Checks
(Demand-
Deposit)
Figure 6. Generic Task Category Derived Using Generalization Abstractions
Demand-Deposit
Loan
Account
Account
Time-Deposit
Credit Card
Account
Account
Credit
Is-A
s-A
Credit Credit
Credit Loan
Credit
Card
Demand-DepositCredit
Time-Depo
Account
Account
Account
Account
Figure 7. Relationships Among Application Categories, the Generic Task

Category Credit, and Its Subsets
Loan Demand-Deposit
Application
Account Account
Categories
Task
Tas s k Payment
Categories
Time-Deposit Credit Card

Account Account
Credit
Is-Part-of
Retreive
Credit
Common Verify Date, Verify
form
Amount of of Credit
Processes Credit
Credit
Calculate
Amount, Interest,
Interest Rate Charges
Record
Credit
Payment
Figure 8. Relationships Among Application Categories, Task Categories, and Common Pro
Table 1. Design Information for the Task Category Credit
Task Category
(Credit)
Application
Categories
Verify Date, Calculate

Amount of Verify Form Interest, Record
Credit of Credit Charges Payment
Verify Date, Verify Form Calculate Record
Loan Amount of of Credit Interest, Payment
Account Credit on Loan on Loan Charges on on Loan

Loan
Verify Date, Calculate

Demand-Deposit Amount of Verify Form Interest,
Account Credit on of Credit on Charges on 0
Demand-Deposit Demand-Deposit Demand-Deposit

Account
Verify Date,
Time-Deposit Amount of Verify Form

Account Credit on of Credit
Time-Deposit on Time-Deposit 0J
Verify Date,
Credit Card Amount of
Account Credit on
Credit Card 0 0 0
paradigm. As of
me
but each task category oriented
requires specification
of appropriate
different properties by fication
a specialization
rule. Mit-da
to be
a major problem
for
termeir and Oppitz (1987)
demonstrate
the feas-
ibility of building a software

opment.
base
In management
the example,
Credit
IS-INSTANCE-OF
system that contains design
information
for task
categories;
they are the
or application categories.
This information
is sup
10 i
reused by completing it task
with category.
different Figure
specializaof the object-orient
tion rules for each tasktation
or application
instance.
Credit task category.
Object-Oriented Approach
Each type (e.g., credit l
The inheritance mechanism represents what is

(i.e., Credit) from which
called an IS-A relation in the semantic modeling
(methods) (e.g., verify am
technique. However, by inheriting methods (i.e.,
internal structure (i.e., sto
operations among types rather than attributes),
instance variables such as
focus is on capturing behavioral rather than structype (class) can add to op
tural aspects of application domains.
it can redefine inherited
The proposed method identifies
abstract
type cannot
delete data
the in
types useful for implementation
in the object-l
different object-oriented
INPUT:
Account
Amount
Date
Ttype-transaction type(loan, time-deposit, demand-deposit, credit card)

Transfer to (*)
Special handling authorization

OUTPUT:
Valid account (y/n)

Valid amount (y/n)
Valid date (y/n)
Valid transfer (y/n)*
Valid transaction (y/n)
*optional, depending on activity

PROCESSING:
SET Valid account, Valid amount, Vaild date, Valid transfer,

Valid transaction to n
READ Account
IF Account valid and existing

Valid account=y
IF Date vaild-83<=yr<=88; 1<=mo<= 12; 1 <=day <=31

Valid date=y
IF Amount valid-0< =Amount < =10,000
& Special handling # 'bb'

Valid amount =y
IF Transfer to # 'bb'
RETRIEVE Transfer to Account
IF Transfer to Account Valid and Existing

Valid transfer =y
IF Valid account =y
IF Valid amount =y
IF Vaild date =y
Valid transaction =y
IF Transfer to # 'bb'
IF Valid Transfer =y
Valid transaction =y
Figure 9. A Functional View for the Verify Date and Amount of Payment Application Asset
degrees of control over what can be inherited and
the type but it omits some or all of the implemen-
what can be overridden.
tations of those operations. Supertypes, therefore, characterize the functionality that is

Operations have two subparts: interface and imcommon to all of their subtypes.
plementation. The interface defines the external
characteristics of operations (i.e., name, type of
Among the difficult technical problems
arguments operations takes, messages to which
associated with designing reusable module strucan object can respond), and the implementationtures is the need to take into account the commonalties existing between groups of related data
of the operation (i.e., actual code). Often a superand process types. The proposed method actype describes the interface to the operations of
counts for identification of these commonalties.
By defining common processes as far up in the

IS-A hierarchy as possible, definitions can be
shared, without redefinition, by the greatest
operation with more than one data type without

having to specify which type should be applied.
These key features allow a design to be parameterized, represented, and developed in factored
number of descendant classes (subtypes). In
form.
By subtyping, commonality between types is accounted for in supertypes. Also, subtypes that
recognize details and differences between types
are created. A subtype is, therefore, a specialization of the supertype; conversely a supertype is
a generalization of its subtypes. A mistake common among novice object-oriented programmers
is avoided: typing is not used to represent ag-
Identifying data assets
short, definitions can be reused.
gregation abstractions (Halbert and O'Brien,

1987).
Data assets are defined as semantic knowledge

associated with application and task categories.
They are the implicit and explicit restrictions
placed on objects, operations, and relationships
within the application domain. By extracting this
knowledge and defining it using semantic modeling techniques and tools (Borgida, 1985; Hull and
King, 1987; Potter and Trueblood, 1988), the

knowledge is standardized. It becomes reusable
among several applications. As a result, the
Object-oriented languages, by providing facilities

to redefine the operations within a type and by
supporting dynamic binding, facilitate reusabili-
the form of data sssets rather than being embed-
ty and flexibility in software development.

Dynamic binding allows the user to request an
ded in the constraints and procedures involved

in disparate applications.
meanings of application assets are captured in
Credit
Properties:
Account Number, Account Balance
Interest Rate, Date, Payment
Functions:
Verify Date, Amount of Credit

Verify Form of Credit
Retrieve Credit Amount, Interest Rate
Calculate Interest, Charges

Record Payment
Credit
Credit Demand-
Loan Account
Functions:
Deposit Account
Functions:
Calculate Interest,
Charges
Subtract Interest,
Charges From
Payment Yielding
Principal Payment
Credit Time- Credt Credit

Deposit Account Card Account
Functions:
Functions:
Calculate Interest,
Charges
Calculate Interest,
Charges
Calculate Interest,
Charges
Subtract Charges
Add Interest to
Subtract Interest,
From Balance
Balance
Charges From
Payment Yielding
Principal Payment
Credit Payment to
Credit Payment to
Account Balance
Account Balance
Subtract Principal
Payment From
Payment From
Balance
Balance
Subtract Principal
Figure 10. A Graphical Representation of an Object
Oriented Development for the Credit Task Category
Figure 11 shows a partial credit data asset

specification in a generic form that illustrates the
data asset concept. It should be noted, however,

that a number of semantic models are incorporated into programming languages; some of these
languages allow direct translation of a semantic
model from graphical form to language syntax.
Although the syntax varies widely among these
languages, they all support various forms of

abstractions. In fact, extensive support for data
abstractions is a key distinction between these
languages and data dictionary directory systems.
Also, these languages are not intended to be a
DBMS; they are designed to support program-
ming languages that encompass data manage-
ment facilities based on semantic models.

OBJECT-TYPE: Loan
HAS-ATTRIBUTES:
Acct-number: INTEGERS;
Acct-balance: REAL;
Interest-rate: REAL;
Date: INTEGERS;
Payment-amount: REAL;
Credit-amount: REAL;
IS-A Credit;
IS-A Payment;
END-OBJECT-TYPE
OBJECT-TYPE: Credit
HAS-ATTRIBUTES:
Transaction-type: STRING;
Form-of-payment: STRING;
Interest-charges
DERIVATION: CALCULATION()
Acct-balance * Interest-rate
Principal-payment
DERIVATION: CALCULATION ()
Payment-Interest-charges
Acct-balance
DERIVATION: CALCULATION ()
Acct-balance-Principal-payment
IS-A Credit-Loan;
IS-A Credit-Demand-Deposit
IS-A Credit-Time-Deposit
IS-A Credit-Credit card;
IS-INSTANCE-OF Loan;
IS-INSTANCE-OF Demand-Deposit;
IS-INSTANCE-OF Time-Deposit;
IS-INSTANCE-OF Credit card;
Capturing structural aspects of application asse

in the form of data assets makes this knowled
accessible and reusable in similar but different
software development efforts. This results

ultimately in eliminating some of the cost and
rework currently experienced in software development projects.
Management, Economic,
and Integration Issues
The asset-based systems development strategy
and the proposed method require a corporate infrastructure that encourages and rewards software reuse. It requires that top management
understands the critical role of software reuse;
it requires participation of project management
and software experts in strategic information
systems planning. These are essential requirements if top management is to address non-tech-
nical issues (e.g., legal and proprietary rights,

compensation for the developers of reusable
parts, internal cost apportionment methods for
purchasing reusable parts, etc.) associated with
software reuse. These are equally as important
as the technical issues.
The economics of software reuse vary significantly with the problem domain and the development
technology employed within an organization

(Barnes, et al., 1987). Before software reuse
starts to pay off, it requires an up-front investment
in establishing and maintaining a library of

reusable parts. The cost of establishing such a
library varies depending on the library size and
the tools used to populate, organize, access, and
maintain the library. Widespread software reuse
also requires experience in budgeting, schedul-
ing, and managing a software development

library.
The proposed method is based on data and process modeling, which allows easy integration of
this method with the structured analysis and data
modeling techniques. Furthermore, the CASE

(computer aided software engineering) development environments support both data and pro-
cess modeling tools (Chikofsky, 1988). These

development environments allow for manage-
ment of the integration of data and process
models that use a central data dictionary.

Through common notation that promotes standardization of documentation and development
Figure 11. A Partial Specification for the Credit
Data Asset
techniques, reuse of existing subsystems is supEND-OBJECT-TYPE
ported. Currently, CASE development environments do not support code reusability or the use
Barnes, B., Durek, T., Gaffney, J. and Pyster, A.
of expert systems technology to generate applica-
Software Reuse," Software Productivity Consortium, Reston, VA, June 1987, pp. 1-12.
Basset, P.G. "Frame-Based Software Engineering," IEEE Software (4:4), July 1987, pp. 9-15.
tions from rule-based specifications; CASE

development environments also need to develop
support tools for object-oriented software

development.
Summary and
Conclusions
This article has reviewed and extended recent
"A Framework and Economic Foundation for
Biggerstaff, T. "Design Recovery for

Maintenance and Reuse," IEEE Computer
(22:6), July 1989, pp. 36-48.
Biggerstaff, T. and Perlis, A. "Forward: Special
Issue on Software Reusability," IEEE Trans-
actions on Software Engineering (10:5),
research on software reusability. It promotes the September 1984, pp. 474-476.

view that the traditional approach to software
Biggerstaff, T. and Richer, C. "Reusability
development lacks focus on (1) planned reuse; Framework, Assessment, and Directions,"
(2) system development from an integrated IEEE Software (4:2), March 1987, pp. 41-48.
perspective; and (3) long-term organizational straBoehm, B.W. "Improving Software Productivity,"
tegic advantages. Yet these are critical to making IEEE Computer (20:9), September 1987a, pp.
software reusability practical.
This article emphasizes an organizational

strategy for software reusability. An asset-based
systems development method based on this

strategy is also presented. The proposed method
requires the integration of data and process

modeling through the use of semantic modeling
techniques and tools. Such an integration

eliminates redundancy in data and process
definition within the scope of integration. Remov-
ing such redundancies results in elimination of

multiple development and maintenance efforts.
It also permits commonalties among data and
processes, which are the bases for software
reusability, and the identification and development of application assets and data assets. The
method emphasizes reusability at the design

rather than at the code level; it supports both
functional and object-oriented systems development approaches.
As reusability technology matures, organizations
will be pressured to adopt the new technology.
Inability to respond to this challenge in a timely
manner could preclude future competitiveness of
many organizations.
43-57.
Boehm, B.W. "Industrial Software Metrics Top
10 List," IEEE Software (4:5), September

1987b, pp. 84-85.
Boehm, B.W. and Papaccio, P.N. "Understanding and Controlling Software Costs,"
IEEE Transactions on Software Engineering
(14:10), October 1988, pp. 1462-1477.
Borgida, A. "Features of Languages for the
Development of Information Systems at the
Conceptual Level," IEEE Software (2:1),

January 1985, pp. 63-72.
Chen, P.P. "The Entity-Relationship Model:
Toward a Unified View of Data," ACM Trans-
actions on Database Systems (1:1), March

1976, pp. 9-36.
Chikofsky, E.J. "Software Technology People
Can Really Use," IEEE Software (5:2), March
1988, pp. 8-10.
Devlin, B.A. and Murphy, P.T. "An Architecture
for a Business and Information System," IBM
Systems Journal (27:1), 1988, pp. 60-80.

Fischer, G. "Cognitive View of Reuse and
Redesign," IEEE Software (4:4), July 1987,
pp. 60-72.
Guimaraes, T. "A Study of Application Program
Development Techniques," Communications
of the ACM (28:5), May 1985, pp. 494-499.

Halbert, D.G. and O'Brien, P.D. "Using Types
and Inheritance in Object-Oriented Programming," IEEE Software (4:5), September 1987,
Appleton, D.S. "Information Asset Manage- pp. 71-79.
ment," Datamation, February 1, 1986a, pp. Horowitz, E. and Munson, J.B. "An Expensive
71-76.
View of Reusable Software," IEEE TransacAppleton, D.S. "Very Large Projects," Datama- tions on Software Engineering (10:3),
September 1984, pp. 477-487.
tion, January 15, 1986b, pp. 63-69.
References
Hull, R. and King, R. "Semantic Data Base

Modeling: Surveys, Applications, and Research Issues," ACM Computing Surveys
(19:3), September 1987, pp. 201-260.
Inmon, W.H. Integrating Data Processing
Systems, In Theory and in Practice, Prentice-Hall, Englewood Cliffs, NJ, 1984.
Inmon, W.H. Information Systems Architecture:
A System Developer's Primer, Prentice-Hall,
Englewood, Cliffs, NJ, 1986.
Jones, T.C. "Reusability in Programming: A

Survey of the State of the Art," IEEE Transac-
tions on Software Engineering (10:5),

September 1984, pp. 488-493.
Joyce, E.J. "Reusable Software: Passage to Productivity?" Datamation, September 15, 1988,
pp. 97-102.
Kaiswer, G.E. and Garian, D. "Melding Software
Systems from Reusable Building Blocks,"

IEEE Software (4:4), July 1987, pp. 17-24.
Karimi, J. "Strategic Planning for Information
Systems: Requirements and Information
Engineering Methods," Journal of Management Information Systems (4:4), Spring 1988,
pp. 5-24.
Lanergan, R.G. and Grasso, C.A. "Software

Engineering with Reusable Designs and
Code," IEEE Transactions on Software
Engineering (10:5), September 1984, pp.

498-501.
Neighbors, J.M. "The DRACO Approach to Constructing Software From Reusable Components," IEEE Transactions on Software
Engineering (10:5), September 1984, pp.
564-574.
Potter, W.D. and Trueblood, R.P. "Traditional,

Semantic, and Hyper-Semantic Approaches
to Data Modeling," IEEE Computer (21:6),
June 1988, pp. 53-63.

Pressman, R.S. Software Engineering: A Practitioner's Approach, Second Edition, McGrawHill, New York, NY, 1987.
Prieto-Diaz, R. "Domain Analysis for Reusability," Proceedings of COMPSAC 87, Tokyo,

Japan, October 1987.
Prieto-Diaz, R. and Freeman, P. "Classifying

Software for Reusability," IEEE Software (4:1),
January 1987, pp. 6-16.

Prieto-Diaz, R. and Jones, G. "Breathing New
Life into Old Software," GTE Journal of
Science and Technology (1:1), Spring 1987,
pp. 23-31.
Smith, J.M. and Smith, D.C. "Data Base Abstractions: Aggregation and Generalization," ACM
Transactions on Data Base Systems, June

1977, pp. 105-133.
Standish, T.A. "An Essay on Software Reuse,"
IEEE Transactions on Software Engineering
(10:5), September 1984, pp. 494-497.
Stroustrup, B. "What is Object-Oriented ProLenz, M., Schmid, H.A. and Wolf, P.F. "Software
gramming?" IEEE Software (5:3), May 1988,
Reuse Through Building Blocks," IEEE Softpp. 10-20.
ware (4:4), July 1987, pp. 34-42.
Swanson, M.E. and Curry, S.K. "Results of an
Matsubara, T., Sasaki, O., Nakajim, K.,
Asset Engineering Program," Information and
Takezawa, K., Yamamoto, S. and Tanaka, T.
Management (16:4), 1989, pp. 207-216.
Tracz, W. "Software Reuse: Motivation and In"SWB System: A Software Factory," in Software Engineering Environments, H. Hunke
hibitors," Proceedings of COMPCON 87, San
(ed.), North-Holland Publishing Company,
Francisco, CA, February 1987a, pp. 358-363.
Amsterdam, 1981, pp. 305-318.
Tracz. W. "RMISE Workshop on Software Reuse
Mcllroy, M.D. "Mass Produced Software ComMeeting Summary," Proceedings of the
ponents," Proceedings of 1969 NATO ConRocky Mountain Institute for Software Engiference on Software Engineering, Garmitch,
neering, Boulder, CO, October 14-16,1987b,
Germany, 1969, pp. 89-98.
pp. 1-12.
Meyer, B. "Reusability: The Case for ObjectTracz, W. "Ada Reusability Efforts-A Survey of
Oriented Design," IEEE Software (4:2), March
the State of the Practice," Proceedings of the
1987, pp. 50-64.
Fifth National Conference on Ada Technology
Meyer, B. Object-Oriented Software Construcand Fourth Washington ADA Symposium,
tion, Prentice-Hall, Englewood Cliffs, NJ,
Washington, D.C., March 1987c, pp. 35-44.
1988.
Tracz, W. "Software Reuse Myths," ACM
Mittermeir, R.T. and Oppitz, M. "Software Bases

SIGSOFT (13:1), January 1988, pp. 17-21.
for the Flexible Composition of Application Wardle, C. "The Evolution of Information
Systems," IEEE Transactions on Software
Systems Architecture," Proceedings of the
Fifth International Conference on Information
Engineering (13:4), April 1987, pp. 440-460.
Systems, Tucson, AZ, November 1984, pp.

205-217.
and Ph.D. degrees from the University of Arizona,

Tucson. His research interests include informa-
tion systems management, strategic planning for

Wong, W. "Management Overview of Software
information systems, information systems modelReuse," Technical Report PB87-109856/XAB,
National Bureau of Standards, Gaithersburg,
ing, analysis and design, and software engineerMD, 1986.
ing. Recently he was invited by the National
Academy of Science and the Chinese Review
Woodfield, S.N., Embley, D.W. and Scott, D.T.
Commission of the Chinese University Develop"Can Programmers Reuse Software," IEEE
ment Project to teach a class in systems analysis
Software (4:4), July 1987, pp. 52-59.
Zachman, J.A. "A Framework for Information
and design to a group of Chinese faculty
members at Fudan University in Shanghai, PeoSystems Architecture," IBM Systems Journal
(26:3), 1987, pp. 276-292.
About the Author

Jahangir Karimi is assistant professor of
ple's Republic of China. He has published in

IEEE Transactions of Software Engineering,
Communications of the ACM, MIS Quarterly,
Journal of Management Information Systems,
and a number of conference proceedings. Dr.
Karimi is a member of the Association for Com-
management information systems at the Univer- puting Machinery, the Computing Society, and
sity of Colorado at Denver. He received his M.S. the Society for Information Management.

An Asset-Based Approach to Improving Software Reusability

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

An Asset-Based Approach to Improving Software Reusability

Uploaded by

Copyright:

Available Formats

An Asset-Based Systems Development Approach to Software Reusability

Author(s): Jahangir Karimi

Management Information Systems Research Center, University of Minnesota is

opportunity for improving software productivity

Software reusability is viewed widely as a major

(Biggerstaff and Richer, 1987; Boehm, 1987a;

(Boehm, 1988). Although in principal software

over $125 billion by 1990 for the U.S. alone

not been significant progress in making it

By: Jahangir Karimi

College of Business and

1200 Larimer Street (Box 165)

and Perlis, 1984; Lanergan and Grasso, 1984),

Wong, 1986). Many organizations view software

The absence of an appropriate top-management

on the development of information assets designed to be reused. It also facilitates identifying,

ture, information asset, semantic

modeling, abstraction, objectoriented systems development

ACM categories: D.2, D.2.9, D.2.m, D.3.3

grammers being unmotivated to reuse software,

into practice (Tracz, 1987a; 1987b).

own budgets and resources (Wong, 1986). As

Project managers' emphasis has focused on

delivered lines of source code rather than on im-

proving productivity of the software development

MIS Quarterly/June 1990 179

sonnel and training . ..the software backlog

make software reuse practical. Two factors are

understand, and modify existing software parts

reuse. There is a lack of emphasis on software

associated with software reuse (Joyce, 1988;

1989). These gains have been accomplished by

technical staff; (2) instituting company-wide,

ware part accepted for a reuse library.

Although reusability can be gained at different

stages of the software development process,

cessful. One of the major problems concerns

that a great deal of time is spent trying to

code mainly because "the source code does not

Subroutine libraries and numerical computation

fect routine operation in a well-defined manner;

fication of standard functions and/or data types

Reusability at the design stage emphasizes reuse

180 MIS Quarterly/June 1990

and Grasso (1984) report that by standardizing

or reuse potential of a software part depends

largely on the degree to which the domain

analysis is performed to understand application

Diaz, 1987; Tracz, 1987b). The domain analysis

important than reusability at the code level

cepts are given to a domain designer who

removing those defects than at the code level,

specifies implementation for these concepts in

a huge productivity gain is achievable by develop-

ment of high-quality reusable design parts.

terms of other concepts already identified in that

Technical problems associated with reusability

tion are considered in light of concepts already

ing reusable software parts; (2) representing

tation language, and (5) composing parts into a

opment objectives. Also proposed is a method

proaches. The proposed method and comparative

Munson (1984), this approach is inherently limited