home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.umcs.maine.edu
/
2015-02-07.ftp.umcs.maine.edu.tar
/
ftp.umcs.maine.edu
/
pub
/
WISR
/
wisr6
/
proceedings
/
ascii
/
yglesias2.ascii
< prev
next >
Wrap
Text File
|
1993-10-19
|
13KB
|
311 lines
Progress in Reusable Parts Libraries (or Lack Thereof )
Kathryn P. Yglesias
IBM Corporation
Mailstop P419/921
93 Myers Corner Road
Wappingers Falls, NY 12590
Tel: (914) 296-6587
Email: yglesias@vnet.ibm.com
Fax: (914) 296-6496
Abstract
Since Booch's abstract data type parts library was published in 1987, many part libraries
have become available but coverage of the domains of software remains minimal. There are
dozens of abstract data type (ADT) and graphical user interface (GUI) libraries. There are
also some libraries available to meet selected markets, especially when the libraries are built
to complement a consulting/service offering, for example those offered by Price Waterhouse or
KPMG Peat Marwick. It is difficult to ascertain why a broaderrange of general purpose libraries
and more domain-specific libraries have not been built. Some experiences with information and
software libraries indicate technology limitations and technical change as two contributors.
Keywords: reuse, reusable parts, part libraries
Workshop Goals: uncover reasons forredundancy in libraries and inhibitors to broadening
range of parts
Working Groups: all
Yglesias- 1
1 Background
Kathryn Yglesias has worked with the IBM Reuse Technology Support Center for four years. Her
areas of focus have included defining classification schemes for IBM parts; evaluation of retrieval
success; exploration of applying software reuse concepts to other software life cycle artifacts such as
process documents, user information, and designs; consultation; and planning consultation offerings
and writing standards manuals.
2 Position
2.1 Current Parts Libraries
In the information area, much of the "reusable information" is in the form of CD-ROMs. The
type information being successfully marketed includes various versions of the Bible, dictionaries
and encyclopedias, and other information typically found in the Reference section of libraries. The
templates for legal forms also have a wide audience and are more similar to software reusable parts.
Software has the ever more abundant ADT and GUI libraries. These are being packaged with
compilers, debuggers, builders, and other associated aids frequently now. These support tools
respond to the programmers' need to be able to quickly understand what a parts set (library)
contains and help using it. This is an important development in institutionalizing reuse.
The current set of parts libraries which are publically available can be summarized as containing
many (but not all) of the basics in a wide set of variations, but containing little diversity. The
IBM internal set of libraries also includes multiple variations of the standards, as well as libraries
specific to software segments or niches. A subset of the specialized parts are reusable outside of
originator's domain or product group.
2.2 Problems Encountered
Initial attempts to build parts libraries were based on a trial and error process. Many things
were tried, then iterations were made to modify the sources inhibiting success. This feedback
mechanism benefitted the developers of our most successful parts libraries of to day. In the non-
code area, proposal and process libraries were built. The proposal library taught us that having the
real experts take time to write the generic, reusable information is the only way to be successful. It
is always hard to get these people's time, butit is a truism that they are needed. Although experts
were used, some of the more technical areas written for reuse were not a reuse success. It was found
that the technology changed so rapidly that the extra cost to make the information reusable could
not be recovered before the information was no longer timely. Another problem with reusing very
technical information is that the frameworks (customer environment, terminology, etc.) change so
much that extensive editing is requiredfor reuse. Templates have proven to be the most common
components in our information libraries.
In the software/code area, some of the problems which have led to disuse of parts libraries are
change in language focus. For example, in IBM the effort to make applications portable to our
many platforms led to changing from PL-based languages to C or C++. The successfulPL libraries
were either ported or have a declining usage. Another problem area associated with languages is
Yglesias- 2
the "good" compiler "lag". By this I refer to the many Ada programs which were written and then
re-compiled and re-tested many, many times as the compiler problems were gradually resolved.
This type problem continues to occur, but to a lesser degree. However,the overhead of re-testing,
and sometimes, modifying a large set of components for every compiler release led some (especially
Ada) programmers to abandon reuse.
A newer generation of reuse problems is occuring for OO programmers as they try to reuse class
libraries built by other product groups. This class of problem offers some interesting challenges for
the next few years.
2.3 Creating Reusable Parts Libraries
The parts in a part library have been found to be more widely used whenthe parts form a col-
lection, that is, they have common structures andpurp ose. Libraries of this type may be called
"architected", which is defined as a set of related parts which (ideally) have the characteristics
described below. [1] Experience has shown that architected parts sets are more frequently reused
than unrelated collections of parts. A contributing factor is that these characteristics also reflect
the goals of good software engineering. And once the reuser becomes familiar with the structure of
the library, it is easier to know how to use any part in the library and to guess whether a needed
part is likely to exist within the library's domain.
The characteristics of these planned libraries show that they are successful because
1. the parts individually meet the technical requirements for reuse in terms of:
fflComplexity (hiding of)
fflAdaptability
fflConfigurability
fflPredictability (the level of fidelity of meeting performance and resource requirements)
2. the parts are structured to work together in the following ways:
fflExtensibility (ability to extend the domain of the architecture)
fflScaleability (ability ofarchitecture to map to implementation of increasing dimension
within the domain)
fflFunctional comp osability (ability of components to be combined with other components
in the architecture)
fflInteroperability (ability of components to be integrated with other software not in the
architecture)
3. and user considerations are met in the following ways:
fflUnderstandability
fflUsability
fflQuality (of components and supporting documentation)
fflCompatibility (with existing standards, terminology, and technology)
fflSalability (ability of architecture to reflect the requirements in the eyes of the end-user).
These characteristics can be used for software (code) and information, although some of the terms
are different than those typically used to measure "goo dness" in information. When the list is
read, terms such as, "understandability", "usability", and "quality" apply directly to information.
However, a term such such as "consistency" might be used in place of "predictability".
Yglesias- 3
The architected libraries which we have had for several years are ADTs, GUIs, graphics objects
and proposal text segments. These libraries have sustained high usage and high acceptance. It is
my belief that an understanding of the characteristics of architected libraries (and the domains) by
the developers led to the positive reuse results of these libraries.
2.4 Reusability and Your Goals
Before continuing, it may be beneficial to remember why reusability, architected libraries, and
domain analysis are being discussed. The purpose is to use an understanding of an organization's
business objectives and reuse principles to define what parts (architected sets) will most benefit
the organization by their creation and reuse.
The methods described here have been used on software projects to achieve significant cost savings
over traditional software development methods. Informal use of these methods has resulted in
similar savings in the documentation arena. A cost analysis should alwaysb e performed before
doing the domain analysis and producing the architected libraries.
2.5 Conclusions
My experiences indicate that it is possible to increase reuse with an increased number of libraries,
and that many of the libraries need to be domain specific. To successfully build domain specific
libraries, consideration of the following increases the chances for success:
fflKnow your business objectives
fflUnderstand reuse principles
fflDo a domain analysis
fflAvoid leading edge technology areas or those with a high rate of technical change
fflControl the risks associated with evolving technology (e.g., language changes).
3 Comparison
Much effort in programs such as STARS has been expended towards understanding how to capture
domain knowledge and "encapsulate" it. [2] This usually includes domain analysis which drives the
creation of domain specific parts stored in a reuse library. This approach is worthwhile, but the
visible results of such an approach are seen onlyin the government arena.
Some observations can be made when contrasting thenumber of parts available commercially and
through the government. First, in the commercial arena there must be a large enough audience
who understands reuse, is willing to use "someone else's" software, and is in the selected domain
to justify taking the part (set) to market. A second observation is that the government does
not have this constraint. A third observation is that any government organization can define its
domains without regard to how other organizations divide theirs, that is, there is no predefined need
for the guidance systems domain, for example, of one military organization to b ethe same as for
another. The consequences of these observations are that (1) it is possible for any single government
organization to make progress in their "domain",and (2) if they had to first get agreement on their
Yglesias- 4
domain (to establish a "market") with all other government organizations in the same general
business, then there would not be many parts in government libraries either.
My conclusions are that there is not enough concensus on "domains" across the software industry for
other part libraries to be developed. If there are not consistently recognized domains or segments,
then an insufficient market will exist. The problem is similar to making use of ADTs - unless the
programmer has been trained to understand and look for opportunities to use ADTs, the need for
ADTs does not exist.
My position is that it is necessary to expand the scope of our available parts libraries in an archi-
tected manner, along domain lines. This must be done if we are to sustain progress in institution-
alizing reuse. Therefore, emphasis must be placed on defining "domains" and getting concensus on
their definitions.
References
[1] "IBMReuse Methodology: Domain Analysis," tech. rep., IBM Reuse Technology Support Cen-
ter, February 1992.
[2] R. Prieto-Diaz, "Reuse Library Pro cessMo del," Tech. Rep. AD-B157091, IBM CDRL 03041-
002, STARS, July 1991.
4 Biography
Kathryn P. Yglesias is an advisorysystems analyst in the IBM Reuse Technology Support Center
where her work includes information model definition, classification evolution, and requirements
definition for corporate standards and tools. She coordinated the IBM definition of formal methods
for reusing non-code work products, especially customer documentation. Her experiences include
engineering and project management for the Space Shuttle program and customer liaison for an
internal computer systems organization. She is a member of the AIAA and Society for Software
Quality.
Yglesias- 5