Management Information Systems Research Center, University of Minnesota MIS Quarterly
Management Information Systems Research Center, University of Minnesota MIS Quarterly
Your use of the JSTOR archive indicates your acceptance of the Terms & Conditions of Use, available at
http://about.jstor.org/terms
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
Development
Approach to
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
University of Colorado at
Denver
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
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
fit for developing, implementing, and maintaining a custom-built software application.. .there
is often resistance to change and Not-lnventedHere syndrome" (p. 7).
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
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-
A number of U.S. companies are reaping significant productivity increases due to cost savings
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.
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
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
it is difficult to match detailed specifics. The sucinformation (Biggerstaff and Richer, 1987; Prietocess of the Japanese software factory, which also
because (1) design activities introduce 50 percent An approach by Neighbors (1984) advocates usto 60 percent of all defects during the develop- ing 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
system. But to do this the design of the intermediate abstraction levels must be an integral
part of the software design process.
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
Two recent developments allowing for representation of software parts in parameterized and factored forms are the Ada programming language
and object-oriented approaches.
tance mechanism. Class (type) inheritance promotes code and design reuse because the code
shared by several classes can be placed in its com-
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
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-
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
Organizational
Strategic Plan
Information
Assets
Application
Assets
Data
Assets
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
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
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.
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-
Integration can be done at several levels: subsystem (module); functional (application); and
operational mode (decision support, administra-
a semantic model of
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
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-
Financial Systems
c s-Aon Support Oe AdIs-A
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
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.
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;
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
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
model shown in Figure 3. The focus is on identifying all processes that are fundamentally different; once the primary processes are identified
identified.
Primary
Acceptance of
Business
Processes
Account
Establishment of
Terms of Account
^^^^><v s- ^^.^Is-Part-of
Is-Part-of
Appllcatlo n Loan _
Categorle. s Account
Account Account
MIS Quarterly/Jun
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
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-
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
Is-Part-of
Is-Part-of
Accept Usage
of Credit Card;
Get Credit Check
Accept
Demand-Deposit
Account
Set Checking
Open
Account
Terms;
Issue Checks;
Set Charges;
Accept Calculate
Deposit Interest;
Pay
Checks
Balance
Set Limit;
Set Fees
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
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)
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
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
Loan Demand-Deposit
Application
Account Account
Categories
Task
Tas s k Payment
Categories
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
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
Task Category
(Credit)
Application
Categories
Verify Date,
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-
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
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
INPUT:
Account
Amount
Date
READ Account
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
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
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-
Credit
Properties:
Account Number, Account Balance
Interest Rate, Date, Payment
Functions:
Credit
Credit Demand-
Loan Account
Functions:
Deposit Account
Functions:
Calculate Interest,
Charges
Subtract Interest,
Charges From
Payment Yielding
Principal Payment
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
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
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;
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-
The economics of software reuse vary significantly with the problem domain and the development
The proposed method is based on data and process modeling, which allows easy integration of
this method with the structured analysis and data
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
ported. Currently, CASE development environments do not support code reusability or the use
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.
Summary and
Conclusions
(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.
43-57.
References
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
Neighbors, J.M. "The DRACO Approach to Constructing Software From Reusable Components," IEEE Transactions on Software
564-574.
pp. 23-31.
Smith, J.M. and Smith, D.C. "Data Base Abstractions: Aggregation and Generalization," ACM
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.
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
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.
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