ftp.umcs.maine.edu/2015-02-07.ftp.umcs.maine.edu.tar/ftp.umcs.maine.edu/pub/WISR/wisr4/proceedings/detex/sijtsma.detex

Text File | 1992-04-05 | 15KB | 329 lines

 [12pt] article






  Software Reuse Research at KSLA
  Ben A. Sijtsma

Koninklijke/Shell--Laboratorium, Amsterdam
(Shell Research B.V.)
P.O. Box 3003, 1003 AA Amsterdam, The Netherlands
e-mail:    [e-mail]






This paper briefly discusses the research efforts aimed at providing
reuse technology for the Laboratory. Some characteristic properties
of software development at the Laboratory are considered and their
influence on software reuse are presented. We conclude with an outline
of our approach to domain analysis.

  0.3in

   Keywords:  repository construction, domain analysis



 * Introduction
The research on software reuse at Koninklijke/Shell--Laboratorium, Amsterdam
(KSLA) has two main goals:

  to establish the characteristic properties that
an effective reuse repository for a department in the Laboratory
should possess, and
  to define a process by which such a repository can be created.


These goals are not, of course, unique (cf.  ).
However, they imply some
important and not so obvious side conditions we have not encountered
in other research efforts. These side conditions will be discussed
later on.  First, please bear with us while we make some remarks on
the goals in order to provide some insight into what we mean by
them.

By the characteristic properties of an effective reuse repository we
do not only mean technical properties such as the component
classification mechanism, tools for component retrieval and the kind
of version management, but also more ``managerial'' ones such as the
quality control process and incentive schemes.  Characteristic
properties should therefore be taken in the widest possible sense.

There is a surprisingly large number of issues that needs to be
addressed before any repository can be constructed
(see  ). We will give two
examples. First, it is generally agreed that a repository containing
only code components has limited benefits
( ); design or even requirement
reuse is expected to have a higher pay-off potential.
There is a practical question-mark, however: source code
has a natural representation, but what (formal) language is
used to represent designs? There are many possible choices, but little
is known about their effectiveness in transporting knowledge from the
author of a design to a possible reuser.

The other example is the issue of white-box reuse versus black-box
reuse: in the case of black-box reuse the reuser cannot change a code
component, whereas in the white-box case he or she has the possibility
to change it.  The advantages of black-box reuse are that (1) the
documentation does not need to be written or rewritten (it is already
there), (2) the understanding of the program during maintenance or bug
fixing is facilitated and (3) more support can be given in the event
of an error being found in a component.  The advantages of white-box
reuse are that the likelihood that a component can be (partially)
reused increases and that partial reuse is more effective than writing
from scratch.  Although many advocate white-box reuse,
in this instance, too,
it is not yet clear what the most
cost-effective alternative is or, more generally, what the
essential factors that are determine which alternative to take.

The second goal takes the reuse technology a step further than the
first. The intention of the second goal is to make the construction
of an effective repository a clearly defined and manageable task.
Moreover, it should make it a    repeatable  effort,    not
relying on reuse researchers. A great deal of effort has already been
put in this topic, see, for example,   .

For the second goal, totally different, but nevertheless related,
issues than for the first goal need to be addressed.  For example: a
characteristic property will be the way in which domain knowledge is
represented.  For the second goal it will be necessary to describe the
process of acquiring such knowledge.  Another example concerns the
components.  For the first goal it is sufficient to know that a
component can be a piece of source code or a piece of design (or
 ).  A question that needs to be answered for the second goal is
how components are constructed.  Are they developed from scratch or
are they to be found in the existing software (salvaging)?  If the
latter is the case, the question arises as to what kind of tools,
techniques, and methods are needed.  Furthermore, little is yet known
about which alternative is in the long run economically the most
attractive: development for reuse or software salvaging.

In the remainder of this paper we will discuss some important
properties of software development at the Laboratory, our approach
to fulfill the goals as stated in the foregoing, and we will
conclude with some remarks.

 * The Laboratory Environment

An important
issue that is related to our environment is that the Laboratory is
   not  a software production environment.  Software is not an end
in itself. At the Laboratory, software is mainly written to
explore  a problem and/or solution. The primary aim of the researcher
is generally to gain insight into a physical process.  The software is
only a means to express and test ideas. Hence much software has a
very short lifetime, ranging from a few hours to a few days.
Regularly, though, the software developed during research is used for a long
time, especially software that has resulted at the end of a research
effort. In such a case the software is a vehicle that transports
knowledge from the Laboratory to other parts of the company.

Although it might seem that, in such an environment, there is little
opportunity for reuse, it has nevertheless been observed that many
pieces of functionality are implemented time and again. In our efforts
we hope to find ways to locate and capture these pieces.

The software is written by researchers who are experts in their
fields, say, physics and chemistry, but who have received little or no
training in software development. This has severe repercussions on
several aspects of the repository. First of all, we have to limit
ourselves in the use of formal languages. We cannot use a formal
language, such as Z or predicate calculus, to specify the source text
components. Such a formalism would not be understood easily and it
would hinder possible reuse severely. Similarly,
we cannot use a very formal language to describe
designs and properties of data structures and a transformational
approach (see e.g. ) to software reuse is also not a viable option.
In the end it means that we cannot use formal languages the researcher
is not familiar with, unless these are supported to the extent that
the formal aspects become hardly noticeable.

The fact that experts in the field are generally not experts in
software development influences the domain analysis particularly.
Experts in the field eloquently explain the technical difficulties
they have solved, but are much less able to explain how their
solutions are implemented. For example, they could describe a Fortran
subroutine by stating that it is needed by another one that computes,
say, mixing in a reactor.
Moreover, one could say that their
translation of the concepts in the domain to objects in the software
is often not up to modern software development standards.
For example, the concept of abstract data types is unknown to many.

It goes perhaps without saying, that in the Laboratory the researchers
do not follow standard, or even common, software development methods.
This implies that a great deal of attention must be given to let
researchers reuse software. We expect, unless great care is taken, that
the ``not-invented-here'' syndrome will be a major problem. The
``Programmers's Viewpoint'' as presented in   maps
rather too well on researchers in the Laboratory.

 * Our approach

Apart from the well-known motivations for reusing software, productivity and
quality, another one also plays a role.
The average employee works in a research job for about five
years and then moves on to another, most likely non-research, job.
This implies that there is a high staff turnover. It is believed that
the results of the domain analysis could be very useful in bringing
new employees up to date with the activities of a department.


We have elected to study the construction of a repository for a
department in the Laboratory rather than one for the whole Laboratory.


The areas in which research is performed are quite diverse.
To develop a single repository
for the whole Laboratory was therefore, in our opinion, unrealistic.
We do expect, however, that
repositories for different departments will overlap, and we hope to
devise mechanisms that will enable possible reusers to look over the
boundaries of the repositories without becoming lost in the sheer
quantity of components.

The repository will not only contain source code but designs and
code templates as well. We also intend to provide links to the software
that was used to test the various components. The 3Cs model
(see  ) will be used
to define the structure of a reusable component.

A case study was started one of whose goals was to construct a
repository for a department.
It was decided to start this case study with a domain
analysis. A priori it was decided that the ``deliverables''of the
domain analysis consists of the following three items:

  a glossary of terms
In this glossary the concepts and objects of the domain will be
defined and their interrelationships recorded. It is expected that
many terms in the glossary will have a counterpart in software. It is
particularly important to have a clear view of the interrelationships
between the terms, because these interrelationships indicate the
likely interactions between the software counterparts. As such they
(partially) determine the interface of the software components. The
glossary also provides important information for the classification of
the components.

For reasons explained above, we will use natural language to document
the components. To avoid some of the ambiguities that arise in natural
language documentation, the author of the documentation is allowed
to use only the technical terms that are listed in the glossary
with the same meaning.  So the glossary will become a constant ``terms
of reference'' or context for the reader of the documentation.
This will facilitate the ease of understanding.
  a list of characteristic problems
We hope to find components in the large amount of available software
or, to be precise, we hope to adapt pieces of existing software such
that they become components. The list of characteristic problems is a
first step in gaining a grip on the available software and forms a
first classification mechanism for it.
  one or more solution strategies for every characteristic
problem
An example of a characteristic problem is a phase equilibrium
computation. In such a computation there is a mixture of chemical
substances, a pressure and a temperature. A phase equilibrium
computation entails the computation of the number of phases and their
compositions. Such a problem can be solved in many different ways:
using different models, different numerical methods, etc. The purpose
of this ``deliverable'' is to have a relatively abstract description
of each solution. The solution strategies will enable us to further
classify the existing software and enable us to abstract away from any
specific details of one implementation. This should help us to
construct truly reusable components.


Although the domain was not large,
already early in the domain analysis phase it was observed that
it would require a substantial effort. That the Laboratory is not
a software production environment and the researchers not professional
software developers hindered the analysis substantially.
Since a full domain analysis would take probably too long, we are
considering to follow the approach as given in  .

Notwithstanding the above observation,
the domain knowledge representation is much more an open problem than
the domain analysis. We are still actively looking for a good
``tool.'' Due to the technical environment a great deal of technical
notation exists. We need to have a way to be able to capture such
notation, since it would facilitate the understanding of components a
great deal. Therefore, we consider a hypertext-like environment in
which it is possible to define cards using   a viable option.
Furthermore, this hypertext-like environment should provide support
for layered semantic networks. Such networks will be used to record
the ``deliverables'' of the domain analysis.

 * Concluding Remarks

We have described some of the problems we are facing in constructing a
repository for a department in our Laboratory. The nature of our
environment forces us to use natural languages to describe and/or
specify components. We see the domain analysis as the important step
in the construction of an effective reuse repository. The process
to arrive at a repository will be an adaptation of the process
described in  . The process for domain analysis
is still being developed; our starting point was an approach
presented in  .

We have just started a case study and we have a long way to go before
software reuse is institutionalised software reuse.


   99

Biggerstaff, T.J., Richter, C.
   Reusability Framework, Assessment, and Directions.
IEEE Software, Vol. 4, Nr. 2, March, 1987.

Boyle, J.M.
   Program Reusability through Program Transformation.
IEEE Transactions on Software Engineering, Vol. SE-10, Nr. 5, September,
1984.

Frakes, B., Latour, L., Wheeler, T.
   Descriptive and Prescriptive Aspects of the 3Cs Model -- SETA
Working Group Summary --
In: Proceedings of the Third Annual Workshop: Methods   Tools for Reuse,
CASE Center, Syracuse University, June, 1990.

Oddy, G.
   Software Reuse at G-MRC.
In:  , pp. 30 - 35.

Prieto-Diaz, R.
   Making Software Reuse Work: An Implementation Model.
In:  , pp. 86 - 92.

Prieto-Diaz, R.
   Domain Analysis for Reusability.
Proceedings of COMPSAC'87, 1987, pp. 23 - 29.

Prieto-Diaz, R., Sch  a fer, W., Cramer, J., and Wolf, S. (eds.)
Proceedings of the First International Workshop on
Software Reusability, Dortmund, Germany, July 3-5, 1991.
SWT-Memo Nr. 57, University Dortmund, Germany.

Tracz, W.
   RMISE Workshop on Software Reuse Meeting Summary.
In:  , pp. 41 - 53.

Tracz, W.
   Software Reuse: Emerging Technology.
The Computer Society of the IEEE, 1988, ISBN 0-8186-4846-3.

Tracz, W.
   Software Reuse: Motivators and Inhibitors.
Proceedings of COMPCON S'87, 1987, pp. 358 - 363.