ftp.umcs.maine.edu/2015-02-07.ftp.umcs.maine.edu.tar/ftp.umcs.maine.edu/pub/WISR/wisr7/proceedings/txt/all-papers.txt

Text File | 1995-08-17 | 637KB | 12,717 lines

Functional Representation for Reusable Components

Dean Allemang and Beat Liver

Research & Development
Swiss Telecom PTT
3000 Berne 29,Switzerland
Tel: [phone]
Email: [e-mail]

Abstract

In this research abstract we outline the framework ZD for constructing
libraries of reusable software components. The work is inspired by
functional representation of physical devices [1], but has undergone
considerable changes while being adapted to support software
engineering. The approach is a formal one, in that the semantics of the
representations is based on proofs of program correctness. This makes it
particularly easy to compare it to more `classical' software engineering
approaches.  In particular,we contrast our approach to the construction
of software libraries based on `local certifiable modules' [2]. We have
shown that while the goals of local certifiable modules constitute a
sound basis on which to build a mature software industry,
unfortunately, dedication to local certifiability constrains the grain size
of the library components too severely to allow the desired flexibility.  In
the ZD framework, we resolve this problem with a method called proviso
propagation. Local certifiable modules place the proof process at module
creation time; ordinary proofs of correctness place the proof process at
configuration time (or later).  Proviso propagation divides the proof
process - the majority of the proof is done at library creation time,
except for the proviso propagation, which is done at configuration time.
In this way, ZDretains much of the flexibility of freely combinable
modules, while retaining capability to provide provably correct software.

Keywords: Reuse, formal verification, modular design, program modeling.

Workshop Goals: Comparison of our models to requirements of other SE
methodologies.

Working Groups: Design guidelines for reuse - general, reuse and formal
methods, reuse handbook.

1   Background

Dean Allemang began his contribution to software reuse with his
dissertation in 1990. The goal of that work was to represent the
knowledge required to `understand' a program.  The work was based on
the Functional Representation work done by Chandrasekaran and
Sembugamoorthy on representing mechanical devices.  Since that time,
Dean Allemang and Beat Liver at Swiss Telecom PTT Research and
Development have extended the method described there to include
support for software configuration, diagnosis, debugging and repair. This
work will culmintate in Mr. Liver's Ph.D. dissertation, which will include
an implementation of the software modeling language ZD.

2   Position

Since the industrial revolution, most manufacture of mechanical devices
is done on the basis of the assembly-line - a large number of identical
parts are produced, and assembled into the final product. But the final
products are not all identical - there are a number of options and
models from which the customer may choose, and these impact the
manufacturing process.  Software, on the other hand,is typically done on
a custom-order basis; each piece of software is tailored to the needs of its
end users. The dream of software engineering is that the software
industry might one day have the flexibility and productivity of more
mature mechanical industries.

A common problem with mass-production of software or mechanical
devices is quality control - how do we know that the device produced
willp erform as advertised, especially in safety or security critical
situations? In order for software to be able to satisfy quality control
constraints, it is necessary that we have a reliable method for specifying
what software is to do, and of determining whether it achieves this goal.

In order to satisfy these two goalsof a mature software industry, Weide et
al [2] propose local certifiable modules. Alocal certifiable module is a
reusable piece of software,whose correctness can be verified in purely
local terms;that is, its own specification, its own code, and the
specification of the programs it calls directly. A library of such
components could be built and certified; then writing a program is
merely a matter of selecting the necessary components, com posing them
together,verifying that the specifications of services match the
specifications of requirements. The local certifiability guarantees that the
resulting composite program does what its specification promises.

2.1  ZD and Software Configuration

In order to avoid reducing all problems to a single implementation level,
software is normally understood at several levels of abstraction.This
concept is well-known to any experienced programmer, and is supported
by a number of methods in modern programming languages. This means
that a library of reusable components must also have components at
various levels of abstraction;the configuration of a new system will be
explainable at several levels simultaneously, depending on the
configuration decisions made during its construction. This means that a
representation of the specifications of reusable components as well as the
requirements will have to have a mechanism for mediating between
description languages at different levels of abstraction.

We have designed ZDafter functional modeling languages used for
describing physical devices at several levels of abstraction [1]. We have
formalized the change of abstraction levels by using the notion of
representation functions from ALPHARD [3]. Each module in ZD mediates
an explanation in some state description language (SDL). For any
implementation choice, a function maps from the abstract language to
the chosen concrete language. For example, for an array implementation
of a stack,the high-level (in terms of stack operators) expression
`empty(S)' is translated into the concrete expression `stack:top = 0'.

[Figure 1: Afunctional prototype. The prototype has services (top,square
boxed), and an implementation (middle,round box), which specifies
what it requires of other devices (bottom, square boxes again).

Figure 2: Schematic configuration of a functional decomposition - a
functional prototype - from a library of functional prototypes.
Functional prototypes from the library are shaded; figures shown in
dotted lines are to be determined; and the components new to first three
stages are shown in bold.]

A reusable component in ZD is called a functional prototype, after the
use of the term in CAD research [4]. Figure 1 show the coarse structure of
a ZD functional prototype.  On the top of the diagram is a specification
of the service provided by the prototype; in the middle is an
implementation that achieves this specification (only one is shown in
the figure, but in principle, there can be several implementations per
prototype).  Finally, each implementation specifies some requirements
for other services upon which it will call.  The requirements and the
service will not be at the same level of abstraction - thus associated with
each implementation is a representation function.

Just as in the case of local certifiable components, configuration of a
program in ZD involves making a selection of a number of such
prototypes, and matching them together,as shown in figure 2. In general,
a library user cannot expect the specifications of one service to match
the requirements of another exactly - hence we introduce `glue code' [2]
to connect them. Glue code is shown as extra implementations in the
figure.

3   Limits on Configuration

So far, there is no apparent advantage to using ZD over a system of
certifiable components - in fact, if we were to certify our functional
prototypes, the two approaches would be identical. The
primary difference between ZD and local certifiable components is that
each service specification of ZD includes a predicate called its proviso,
which specifies a context in which the use of this prototype is valid.
Unlike the specification of the prototype (or of the local certifiable
module),the proviso is not merely matched to the requirement
specification of the client program. Verification of the proviso is subject
to a more comprehensive proof mechanism. The details of how provisos
are propagated in ZD can be found in [5].

The ramifications of having a proviso that is checked at configuration
time is that features of the program that are only known at
configuration time may take part in the verification process.  Requiring
that a module be certified in advance of any possible use is quite a
severe constraint to place on a module; the use of the proviso allows this
constraint to be relaxed. Of course,this relaxation has a price - the
proviso must be proven at configuration time. The trade-off between a
too-rigid library,and intractable proviso verification is the art of writing
good reusable modules and provisos.

A short example should illustrate how this trade-off works.  Iteration is a
common action that many programs have to do over and over again.
Consider a module called passive_iterator. It takes two arguments - an
ordered set of items,and a fragment of code. The iterator runs the code
on each item in the set, and guarantees that although the order of
the set might be changed, its contents will not. A local certifiable version
of passive_iterator would be guaranteed to satisfy this specification, for
any input set and action.

If the desired action were to re-arrange the set (say, shift every
element one to the right), then an action that moves a single item could
be used. But the integrity of the set depends upon the order in which the
iterator traverses it - it is impossible to anticipate during library
construction which actions might be desired. Thus passive_iterator alone
cannot be encapsulated as a local certifiable module. Weide solves this
problem by using an active iterator instead of a passive one,and by
encapsulating the action into the specification of the reusable module
[6]. This makes for a local certifiable module, but the shift action is
already included - the client cannot decide what new ordering of the set
he wants.

ZD, on the other hand, can encapsulate a passive iterator.  Indeed there
is a condition on the action - not just any action may be used in
conjunction with the ZD passive iterator total_loop [7].  The action itself
must be instantiated from the library - along with the function
prototype for the action, a proviso for its correct use is retrieved.  In the
case of a simple action to move an item from one place to another,the
proviso requires that the target of the move be `empty'. Since each item
will be moved, checking that this proviso is satisfied is more complicated
than simply checking that it is guaranteed by the requirement
specification. In general, this involves the invocation of a theorem prover
to show that the proviso is satisfied at every iteration of the loop. In this
case, the proviso can be checked quite easily from a formal statement of
the principle of induction, without an exponential proof structure. This
process of verifying a proviso in its context is called Proviso Propagating
and Proving (PPP).

4   Comparison

The value added to local certifiable components by ZD is the capability
to buy flexibility of modules, by paying with computational
effort(theorem proving, in the worst case) at configuration time.
Modules that are local certifiable can be treated in ZD by specifying a
null proviso; even very simple provisos can buy big gains in flexibility, as
the preceding example showed.

The PPP algorithm has already been worked out and implemented, in a
system called Dudu [5] running in InterLisp on a Xerox 1108/9. Dudu
used a functional representation that preceded ZD to recognize the
difference between correct and incorrect student programs in a tutorial
setting.

In our current work we are resolving a number of the details of the ZD
formalism to specify how the connections between requirements and
specifications can be formalized, and under exactly what circumstances
a proviso must be propagated [8]. Our goal is to implement ZD in such a
way that the proviso propagation algorithm from Dudu can be rebuilt,
along with support for configuration of the form shown in figure 2.
Further applications include modeling of distributed systems [9] and
fault isolation [10].  ZD will then become a language in which function
prototypes can be written, and the details of the trade-off
betweenflexibility and design-time computational expense can be more
systematically studied,in the context of a growing library of semi-local
certifiable prototypes.

References

 [1]Sembugamoorthy, V. and Chandrasekaran, B., "Functional
Representation of Devices and Compilation of Diagnositc Problem-Solving
Systems," in Experience, Memory and Reasoning (J. Kolodner and
C.Riesbeck, eds.), pp. 47-73, Lawrence Erlbaum Associates, 1986.

 [2]B. W. Weide, W. F. Ogden, and S. H. Zweben, "Reuseable software
components," in Advances in Computers (M. C. Yovits, ed.), vol. 33,
pp.1-65, Academic Press, 1991.

 [3]W. Wulf, R. London, and M. Shaw, "Abstraction and Verification in
Alphard: Introduction to Language and Methodology," in ALPHARD: Form
and Content (M. Shaw, ed.), Computer Science Monograph, pp. 15-60,
Springer, 1981.

 [4]Y. Umeda and T.Tomiyama, "A CAD for Functional Design," in
Working Notes of the AAAI'93 Workshop "Reasoning about Function",
(Washington DC), 1993.

 [5]D. T. Allemang, Understanding Programs as Devices. PhD thesis, The
Ohio State University, 1990.

 [6]B. W. Weide, S. H. Edwards, D. E. Harms, and D. A. Lamb, "Design and
specification of iterators usingthe swapping paradigm," IEEE Transactions
on Software Engineering, vol.20, pp. 631-643, August 1994.

 [7]D. T. Allemang,"Functional Representation and Program Debugging,"
in Proc. of the 6th Knowledge-Based Software Engineering Conference,
(Syracuse, NY), IEEE Computer Society Press,1991.

 [8]B. Liver and D. T. Allemang, "AFunctional Representation for Software
Reuse and Design," Software Engineering and Knowledge Engineering, vol.
in press, 1995.  Special Issue on Evolutionary Approaches to Software
Engineering.

 [9]B. Liver, "Working-around Faulty Communication Procedures using
Functional Models," in Working Notes of the AAAI-93 Workshop
"Reasoning about Function", (Washington DC), 1993.

[10]B. Liver,"Modeling Software Systems for Diagnosis," in Working Notes
of the 5th Int. Workshop on Principles of Diagnosis, 1994.
Difference-Based Engineering

Sidney C. Bailin

CTA Incorporated
6116 Executive Boulevard, Suite 800
Rockville, MD 20852
Tel: [phone]
Email: [e-mail]

Abstract

This position paper describes a concept, Difference Based Engineering,
which is an attempt to bring reuse out of the specialty arena. I try to
reformulate the reuse concept so that it explicitly addresses the concerns
and needs of working software andsystem engineers and, even more,
managers with profit and loss responsibility.

Keywords: Deltas, case-base, engineering analysis


Workshop Goals: Stay abreast ofwhat others in the field are doing.
Promulgate a view of reuse that emphasizes evolution and the unique
characteristics of software.

Working Groups:Reuse management,organization and economics;Domain
analysis/engineering; Tools and environments

1   Background

After 8 years of research and development in domain analysis and reuse
methodology and tools, we decided to turn Capturetm into a
commercial product.  No sooner had we convinced the Board of Directors
to go for it,than the second thoughts began. This is not surprising for a
company that has thrived on Government contracts since its inception;
but it has forced us to do a continual selling job both within and outside
our company _ not on the goodness of reuse, but on whether there is
really a market for such technology. It's a tough question, and in this
position paper I summarize where it has led us.

2   Position

My basic position is that we have to stop thinking of reuse as a thing in
itself to be promoted and sold. Why? Well,because it's become a fetish,
and a lot of people are not especially turned on by it. One of the things
we did was hire a consultant to do a market analysis. He called a bunch
of people and asked them a lot of questions about their software
environment needs,and right in the middle of the questionaire he stuck
an inconspicuous question about the desirability and importance of
reuse (so that the interviewees wouldn't catch on that that was the real
topic).  Their typical answer - "Yes, reuse would be nice, Iguess, but it's
not high on the agenda." To which the knee-jerk reaction of the plug-
pullers here was, "You see, it (our productization effort) was a mistake,
let's pull the plug."

We all know that polls are skewed by the way the questions are
asked.And the problem is that this poll asked a question like,"Would you
care for an extra dollop of extra-rich high-fat chocolate syrup essence on
your sundae?"So of course the answer was, "Well, yeah, I guess, since you
offered."

But what if we ask the question in a different form, such as: "Would you
place a high priority on staying in business?"

Let me formulate this a little more soberly. We need to think of reuse as
a fundamental aspect of disciplined engineering _ and to derive from
that the "compelling reason to buy" that must be articulated when
marketing new technology [2]. One such argument might be, "You're
going broke. You're profits are down, you're laying people off, your
industry is consolidating - this technology can give you a competitive
edge,or at least competitive parity in a rapidly evolving world." I think
that's a pretty compelling reason to buy.

Of course, the devil is in the details :  To which purpose, I offer the
concept of Difference-Based Engineering (see the figure at the end of this
paper). The concept is simple: streamline the system and software
engineering process byconstructing new systems as deltas of existing
systems. A problem (i.e., a set of requirements fora system) comes in,
and the first thing the engineer asks is, "Have we done this before - do we
have a solution?" If the answer is yes, we're done. If the answer is, "Not
quite," then the next question is, "How is what we've done before
different from what we need to do now?  What approaches can we take
to adapt what we've done before? What would have to change, and what
are the implications/ramifications of making such changes?"

It is in answering these questions that the system/software engineering is
performed.The Capture tool - and reuse technology in general - is
intended to provide knowledge to help in obtaining answers to these
questions, rapidly and reliably; credibly, rather than through guess-work.

Of course,to some extent most engineering organizations and individuals
do this already. But they don't do it systematically,and therefore they
don't benefit from the labor-minimizing consequences.  The objective of
introducing a Difference-BasedEngineering process is that you no longer
build systems, you build deltas, and this becomes the institutionalized
approach.

3   Comparison

My position that reuse is really a fundamental aspect of disciplined
engineering is similar to Ruben Prieto-Diaz's at last year's reuse
conference in Rio, where he predicted the Disappearance of Software
Reuse by the year 2000 [3].

My emphasis on Darwinian survival is similar to the themes developed
by Brad Cox [1].However, his vision of a system development industry
based on "software ICs" is quite different from my
view. I maintain that software - by its very nature - is the medium in
which we tend to dump complexity and, in particular, unprecedented
requirements. To Cox (Ithink), that is a pathology in need of fixing. To
me, it is the very role of software in our society.

The Difference Based Engineering paradigm is really just an example of
the case-based reasoning paradigm first developed by Schank [4] and
now a full-fledged field of AI. For many years I have
referred to Capture as a case-based approach to domain engineering. By
coining this new term I am hoping for a slightly different emphasis - a
case-based approach to system building, in which
domain analysis plays an important role.This, to me, is the essence of
software reuse, but it tends to get lost in the forest of techniques and
tools, conferences and curricula that we develop.

4   Biography

Sidney C. Bailin is a Vice President of Engineering at CTA, Inc. where he
heads up the Software Development Automation Group.  He has worked
in the field of reuse and, more generally, automating aspects of the
software development process, for the past 10 years.  Prior to this he
worked as both a systems and a software engineer in a variety of
domains including electronic funds transfer, operating systems,
computer communications,office automation, and satellite ground
systems. His academic background is in mathematical logic, and a
principal emphasis in his current work is engineering as a reasoning
activity, and the introduction of automated reasoning into the software
development process in a way that is compatible with mainstream
software skills and practice.

References

[1]B. Cox. Planning the Software Industrial Revolution. IEEE Software,
November 1990.

[2]G. A. Moore. Crossing the Chasm: Marketing and Selling Technology
Products to Mainstream Customers. Harper Collins, 1991.

[3]R. Prieto-Diaz. The Disappearance of Software Reuse. In Third
International Conference on Software Reuse. IEEE Computer Society Press,
1994.

[4]R. Schank. Dynamic Memory: The Theory of Reminding and Learning
in Computers and People. Cambridge University Press, 1982.
Tradeoffs in Packaging Reusable Assets

Kevin M. Benner

Andersen Consulting
100 S. Wacker Dr.
Chicago, IL 60606
Email: [e-mail]

Abstract

Within a comprehensive reuseplan, one of many decisions that an
organization must make is how to package assets for reuse. When an
asset is packaged it is done be striking some balance between four
delivery vehicles: people,deliverables (i.e., any sort of work product),
tools, and processes. This position paper addresses the tradeoffs that an
organization makes when deciding how to package assets for reuse. In
general, these decisions are basedon the business environment in which
reuse will be performed and the importance that it places on each of the
following values: flexibility,productivity, speed of delivery, cost of
delivery, investment cost, evolvability over time, and distributability.
This paper will describe specific commitments that selected Andersen
Consulting organizations have made based on their business
environment.

Keywords: Reuse processes, management, economics

Workshop Goals: Learning; networking; exchanging information on recent
reuse experiences.

Working Groups: reuse process models, management andeconomics.

1   Background

CSTaRis currently leading an effort to raise the level of reuse within
Andersen Consulting using existing technology which will then prepare
the way for new reuse technology as it becomes available. The general
goal of this reuse initiative is to guide, lead, direct, cudgel, push, and
entice Solution Centers and other large development organizations (e.g.,
large regional offices) within Andersen Consulting to integrate reuse as a
fundamental part of their development and maintenance activities.  A
fundamental problem to date in achieving this end is that most
organizations are significantly preoccupied with meeting their more near
term objectives, and thus do not have the resources to dedicate toward
reorienting themselves to be more reuse-centric. The goal of this
initiative is to provide as many leverage points as possible so that
organizations can step up to reuse in a planned way,leveraging existing
knowledge on how reuse should best be accomplished. This reuse
initiative is focused on the following four broad categories of activities:
creating knowledge capital to enable reuse, partnering with organizations
to make them more reuse-centric,evaluating current and future reuse
activities, and proselytizing about reuse throughout the firm.

2   Position

2.1  Introduction

To date Ihave had the opportunity to become familiar with several
different reuse-based development efforts within the firm.  One of the
most interesting aspects of these reuse efforts is how they package assets
to enable reuse. An asset may be packaged via any combination of the
following delivery vehicles: people,deliverables (i.e.,any sort of work
product), tools, and processes.When one is creating a reusable asset,one
decides how much to rely on each of these  vehicles. This decision is
ultimately driven by a trade-off between competing delivery values.
These delivery values are: flexibility,productivity, speed of delivery, cost
of delivery, investment cost, evolvability over time, and distributability.
This paper will describe in moredetail the basic nature of these delivery
vehicles and then describe how asset packaging approaches maximize
some values at the expense of others.

2.2  Asset Packaging and Delivery Vehicles

Asset packaging is achieved by deciding some balance between
complimentary delivery vehicles.  As stated above,these vehicles are
people, deliverables, tools, and processes. People are the most important
element of asset packaging. This element is the only one which can
standalone. In fact, reuse of people and their skills has always been one
of the strengths of AC. The greatest advantage of people is their inherent
flexibility.  At the extreme,people who have some specialized knowledge
often are able to apply it to solve the problem at hand. And when the
problem is well suited to
their specialized knowledge,they are particularly effective and
productive at solving it. People also have the capacity to evolve their
knowledge over time based on previous experiences. Relative to our
delivery values,an organization relying solely on people is limited in
several ways.  Because knowledge resides within the
individual,investments to improve this knowledge is spent on the
individual whom may leave the organization thus taking the investment
with him/her. Assuming the person stays,there are still only so many
people with the knowledge,thus people become the limiting factor,
potentially limiting opportunities if their knowledge is necessary and
they are not available. Distribution of this knowledge is another issue. In
the case of knowledge held by people, its distribution is fairly limited
based on the typical bandwidth in human communication. Finally,
there is the boredom factor. If people are forced to be too specialized and
are used only to work in their specialized area, thus maximally reusing
their knowledge,they get tired of doing this and will leave or demand to
do other things. In either case, we lose the asset.

Informally, people invariably leverage their knowledge by incorporating
tools, deliverables, processes,and other people so as to reduce their work
and increase their overall productivity. Systematizing this, by making
specific organizational commitments to develop and maintain these
other delivery vehicles is an essential part of any reuse strategy.

The most common approach to systematic reuse is to focus on
deliverables (including various intermediate work products).
Characterizing what a deliverable is, is not an easy task. This is because
deliverables have several dimensions to how they are represented. What
choices one makes within each dimension greatly influences: the cost of
creating the deliverable, the utility of reusing the deliverable,and the
knowledge necessary to use the deliverable.The choices made within
these dimensions are also a critical part of ones reuse strategy since it
will effect the overall balance between the alternative delivery vehicles.
The dimensions of a deliverable are:

Formality - How formally should an asset be represented?(e.g., informal,
structured, semi-formal, and formal documents )

Lifecycle deliverable - An asset may be characterized in terms of any of
its lifecyle deliverables or intermediate work products (e.g., domain
specifications, requirement documents including use cases and scenarios,
system specifications, conceptual models, working models, designs, code,
test plans, project management plans, process models,etc.). The most
import ones for reuse are domain models, architectures, and component
specifications.

Domain specificity - What is the intended domain of the asset? How
generically has the asset been represented? Examples include specific
technicalarchitectures, industry solutions, business functions, and
product lines.

Form - How are variable and nonvariablep ortions of an asset delineated?
(e.g., black box assets, white box assets, generic assets, parameterized
assets, generated assets, informal template-like assets, etc.)

Clearly,all of our delivery values play into the decisions one makes
within the above dimensions on how to represent a deliverable.
Increased flexibility,productivity, speed of delivery, evolvability, and
distributability all come at the expense of investment costs. These
decisions though are not linear (i.e., investments in some areas will have
much higher payoffs then in others). It is critical that one look at the
business case to see where the payoffs will come. The stability of the
business environment and the variability among potential clients are
only some of the influences on which values to weight the most.

The next delivery vehicle of packaged assets is tools. Tools are a common
mechanism for embodying deep knowledge about a deliverable and how
to use it. A given deliverable by itself may not be very valuable if it is
hard to create and use. Tools can automate or assist in the use of a
deliverable asset, thus reducing the amount of knowledge one needs in
order to use it effectively.

Tools do not necessarily need to be paired with deliverables. Another
common pairing is tools and process. In this situation,tool(s) embody
deep knowledge of the process. As people use the tools, they are also
implicitly adhering to the process embodied in it.

The final delivery vehicle of packaged assets is process. One of the things
AC has always been a leader in is the application of well-defined,
repeatable processes within the software development lifecycle. This
same conceptcan be specialized to working with reusable assets.  One of
the things that an individual learns when they become a specialist is not
just deep knowledge about something, but also detailed procedural
knowledge on how to apply that knowledge. At an informal level, when
one mentors with an expert,one is both learning the knowledge of this
expert, as well as the process on how they apply it.  The process delivery
vehicle is an explicit representation of this process knowledge, which is
then available for reuse by non-experts.

2.3  Experiences with Asset Packaging

Given this general characterizationof asset packaging and the delivery
vehicles for achieving it, consider the following organizations within
Andersen Consulting and their existing reuse efforts: Utilities
Industry,Communications Industry, Denver Office, and CSCOE. In the
Utilities Industry, the principle reusable assets are various versions of
Customer /1. As a packaged asset, Customer/1 uses people and selected
deliverables as the delivery vehicles. The expertise which the Utilities
Industry is reusing based on Customer /1 was gained over time by
working on a variety of engagements. In those engagements, both the
reusable assets were created and the people who know how to use the
asset were trained (i.e.,by virtue of building the asset they were trained
in how to use it). Only a limited amount of effort was put into
generalizing deliverables to make them easier to reuse. Reuse was based
on the strong similarity of problem shared by most utilities. Because of
the similarity of problem, the solutions were potentially reusable across
utilities. Since the deliverables have not been packaged in a particularly
general form, one relies on the developers to understand what aspects of
Customer /1 can be easily changed.

This form of deliverable reuse is "clearbox" reuse [this is my term]. Clear
box reuse is a less desirable alternative to either black box or white box
reuse. Clear box reuse means that one reuses an asset by making changes
to what ever portion of its insides one needs to change in order to make
it do what you want it to do.This type of reuse is necessary when the
developers of the asset have not packaged the asset such that it provides
any guidance on what portions of it have been designed to be
customized/adapted. The danger of this type of reuse is that one could
change some portion of the asset which should not be changed (e.g.,
some hidden design assumption).  This danger is mediated by limiting
who can reuse the asset to only people who are intimately familiar with
it.  This approach also leaves one vulnerable to creating many variant
versions of the same asset thus reducing future reusability.

The pairing of these two delivery vehicles, people and deliverables,has
resulted in a packaged asset which is fairly flexible, productive, and
quick when applied to appropriate problems. The greatest limitation is
that only people who are intimately familiar with the asset can decide if
the problem is appropriate. Additionally, only these people can use the
asset effectively. Granted new people can be trained on the asset, but
this is a time consuming activity requiring multiple uses of the asset
on multiple engagements before enough knowledge is distributed to the
trainee. This is a serious problem for future Customer /1 based
engagements.

The Communications Industry tells an almost identical story on the
development and use of BPP1 and BPP2. The only difference between the
two is that the Communications Industry is creating a solution center
which will keep together people who are familiar with the reusable asset.
The intent is to both ensure necessary asset experts are available to
support the creation and use of assets, as well as provide an
environment for training future experts. This should also result in a
dedicated producer organization which supports multiple engagement
teams.

CSCOE differs from both of the above cases in several important ways.
First, CSCOE is an established solution center leveraging the expertise of
people with on-going relationships to assets developed by CSCOE. Second,
CSCOE's principle asset, UCT, is fairly mature - encapsulating a well
understood body of services (i.e.,technical architecture services). The
advantage of such maturity is that it is stable and thus presents the
opportunity to package the asset for blackbox reuse. Third, UCT is more
than just a set of reusable deliverables,it also includes tools and
processes which are integral to using UCT.

CSCOE has segmented its operations to support (1) maintenance and
enhancement of UCT and (2) utilization of UCT. The utilization projects
include: PRA, NSP, and several custom jobs.  Unique to CSCOE is its
concentration on the use of UCT as the technical architecture for all
projects.  This concentration develops specialized skills in CSCOE
personnel on how to best use UCT when building an application. Relative
to our delivery values this concentration maximizes productivity, speed
of delivery,and distribution of knowledge. Specific compromises are
made with respect to flexibility. UCT is "the technical architecture".  If a
project can not be done on the technical architecture it is not done by
CSCOE (i.e., they walk away from business,a radical concept in this firm).
An additional cost which CSCOE commits to is ongoing investment in
UCT. This investment is required to ensure that it evolves as the business
environment changes. Part of this planned evolution is a clear
articulation of what services UCT will provide. All users of UCTcan expect
these common services. Variabilities were not initially well characterized
by CSCOE, but over time CSCOE has supported selected alternative
components (e.g., UCT initially only supported one type of database and
one type of window painter, now it supports several alternatives).

The Denver Office has had a vision similar to CSCOE regarding the use of
a common technical architecture and the development and use of tools
for working within that environment.  This visionis known as the
Application Software Factory (ASF). One of the differences between the
two, besides being on a different technical architecture, is that ASF
demonstrates a more aggressive approach toward advanced tools to aid
the developer.  ASFhas made significant investments (funded by
individual engagements) to develop specialized development tools which
have had a demonstrated increase in productivity of 4-5x and an even
more dramatic improvements in reliability. Another difference between
the two is that the Denver Office has not at this time adopted the
solution center model. Without such a model,or at least some explicit
mechanism for maintaining and improving their assets,use of their assets
will become progressively more difficult as people who are familiar with
the asset move on.

2.4  Conclusion

When individual people leverage past experiences and previously created
deliverables, tools, and processes, this is referred to as ad hoc reuse.
When the organization institutionalizes the creation and use of
deliverables, tools, and processes by people with specialized skills, the
organization is on its way to performing systematic reuse.  The idea is to
make an organizational commitment to a specific balance of these four
knowledge delivery vehicles and then build up a development process
around these such that they are maximally leveraged with respect to the
delivery values the organizations values (i.e.,some specific valuation of
flexibility, productivity,speed of delivery, cost of delivery, investment
cost, evolvability overtime, and distributability). The reuse efforts
described above have adopted a particular balance.  One outstanding
issue, among many, is to develop a model of specific business
environments and these four delivery vehicles such that it can
prescriptively state what the ideal balance should really be for that
environment.

3   Comparison

In general this work is concerned with assessing the effectiveness of
current reuse practices and using this information as a first step toward
increasing the overall reuse level of an organization.  This work leverages
a variety of previous works including: [1], [2], and [3].

References

[1]"STARSConceptual Framework for Reuse Processes (CFRP)," tech. rep.,
Advanced Research Projects Agency (ARPA), 1992.

[2]V. Basili and H. Rombach, "Support for Comprehensive Reuse," Tech.
Rep. UMIACS-TR-91-23, University of Maryland, College Park, Md.,
February 1991.

[3]P. Kulton and A. Hudson, "A Reuse Maturity Model," in Proceeding of
the Fourth Annual Workshopon Software Reuse, November 1991.

4   Biography

Dr. Kevin Benner is a researcher at Andersen Consulting's Center for
Strategic Technology Research (CSTaR)Software Engineering Lab (SEL).
Within SEL, he is a leader of Andersen's reuse program to change their
development practices to be more reuse centric. Thus far,the reuse
program has focused principally on affecting Andersen's organizations,
policies, processes, and people. A secondary goal is to lay the ground
work for technology based reuse solutions as they become available.  Dr.
Benner is also co-principle investigator of the Knowledge-Based Software
Assistant Advance Development Model.  The KBSA/ADM is an effort to
integrate the latest ideas in knowledge-based software engineering into a
next generation CASE tool for object-oriented development of software
components.

Dr. Benner's research interests include: software development
environments, software reuse,specification languages, specification
development, validation and transformations.  Prior to joining CSTaR in
1993, he was a research assistant atthe University of Southern
California/Information Sciences Institute from 1988 to 1993 where he
completed his graduate degree. His work there was
within the ARIESproject and was concerned with the development and
validation of formal specifications. Prior to this he was an officer at the
Air Force's Rome Laboratory where he was the technical lead on the KBSA
program from 1985 to 1988.
Understanding OOP Language Support for Reusability

Robert Biddle and Ewan Tempero

Department of Computer Science
Victoria University of Wellington
Wellington, NEW ZEALAND
Tel: [phone]
Fax: [phone]
Email: fRobert.Biddle,[e-mail]

Abstract

Object-oriented programming (OOP)has been widely acclaimed as a
technology that will support the creation of reusable software.
However,the practical impact has so far been limited. We believe success
has been limited because of widespread misunderstandingof the way the
technology supports reusability. In this position paper,we introduce our
analysis of the connection between OOP and reusability. In particular,we
show that inheritance does support reusability, but not in the way
commonly supposed. More generally, we claim better understanding
about language support for reusable software is necessary.

Keywords: Reusability, Object-Orientation, Programming Languages

Workshop Goals: Develop Models for Reusability, Analyse and
Understand Programming Language Support

Working Groups: Reusability vs. Reuse, Reusability Support Models, Reuse
and OO Methods, Reuse Handbook

1   Background

Object-oriented programming (OOP)has been widely acclaimed as the
technology that will support the creation of reusable software [1].
However,it is also true that the amount of reusable software is not as vast
as the marketing hyperbole associated with the object-oriented
bandwagon led us to expect. So what has gone wrong?

There are many definitions of what software reuse means, but most
involve some variation of "the use of engineering knowledge or artifacts
from existing systems to build new ones" [2]. This definition
encompasses many diverse areas, from application generators, to domain
analysis, to design patterns, to classification and search, to management
[3, 4]. Our interest is in the use of existing code. In particular, we want to
establish precisely how different language features impact the reusability
of code.  As Meyer has said: "any acceptable solution must in the end be
expressible in terms of programs, and programming languages
fundamentally shape the software designers' way of thinking" [5]. We
have been looking at this issue from the point of view of specific
languages and specific features [6, 7,8] .

2   Position

We believe the lack of success of OOP is due not any particular
shortcoming in the technology,but to widespread misunderstanding of
the way the technology supports reusability.  In this position paper, we
briefly outline our analysis of the connection between object-orientation
and reusability. We begin with a discussion of what it means for software
to be reusable. While reusability is an understood aim in programming
language design,it is seldom discussed directly; we have found that
discussing it directly helps our analysis. In the next section,we discuss
the important features of OOP. We regard OOP as "design by
analogy",which we believe offers a concise, consistent,and hype-free
description of the object-oriented paradigm, and provides a foundation
forunderstanding the support of reusability. Finally we discuss the key
issue of the role of inheritance in software reusability. We show that
inheritance does support reusability,but does so in ways that are not well
understood, and not in the ways usually claimed.

2.1  Reusability and Reuse

We believe the first step to a better understanding of this topic is
recognising the distinction between software reuse and reusable software.
Software reuse is an activity that takes place afterward, when software
was initially created in the past. To best support this,reusable software
must be created beforehand in such a way that it is later easy to reuse.

It is our broad aim to better understand howto support reusability.
Towards this, we wish to analyse language structures, and also develop a
language independent model for reusability support.

We refer to the code that we want to reuse as the component,and this is
used by other code that we call the context.  For our purpose, reusable
software consists of components that can be successfully used by all
relevant contexts without change and with the minimum of effort.

A context is relevant if it can use functionality in the component.
However, the functionality may not be accessible by the context.Typical
reasons for this are: unhelpful encapsulation, namespace conflicts,and
dependence on irrelevant or inaccessible components.  A reusable
component therefore must be designed to avoid such limitations. We
refer to this property as generality.

Where a context invokes a component to make use of some
functionality,nothing but the functionality should matter. In fact,there
may be no requirement that it be provided the same way every time.
The weaker the binding between the context and the component,the
more components can be used in that context. The strength of the
binding required between the context and the component represents the
flexibility of the binding.

Finally,a context invoking a component connects two different sets of
assumptions and behaviour.  Care must be taken to prevent connections
where assumptions and behaviour are sufficiently misaligned that the
results are not well defined. Prevention of this kind of mistake requires
concern for safety.

2.2  Object-Orientation and Reusability

To best understand how OOP involves reusability,it is important to
understand just what OOP is all about. In fact,we believe there are two
elements in the foundations of OOP, one technical and the other more
philosophical.  Both have significant practical implications.

The more technical foundation of OOPconcerns an evolutionary process
in program design and programming language support.  From a
historical perspective, OOP may be seen as the confluence of various
threads of development in program design: some involving the design of
control, others involving the organisation of data. The more
philosophical foundation of OOP goes deeper,and directly addresses one
of the most fundamental issues in programming: organising complexity.
There are two key ideas involved.  The first idea is that we should design
programs by analogy.  That is, we should organise our programs using
structures like the structures in the application domain. The second idea
is that most application domains, like the real world, are commonly
regarded as structured as entities and actions on entities.

In the world of entities and actions, it is typical that both entities and
actions are involved in many different contexts.  Entities are used for
various purposes, and the same action may be applied to various
entities.  Accordingly, when we design by analogy, we are likely to use
structures that either have already been needed and designed before, or
that will needed in the future. Either way, there are obvious advantages
of reusability.

The more technical foundations of OOP also support reusability,
particularly via encapsulation.  Encapsulation means that the object is a
capsule, whereby the behaviour and state are bound together as a unit,
with the only access being the designated operations. For the object to be
reusable in different (perhaps as yet unknown) contexts, it is necessary to
make certain that the behaviour cannot be interfered with.  Moreover, it
might be useful to use the context code together with a different
implementation of the object, then the reusability of the context code is
of interest.  Accordingly it is important that the context code cannot
depend upon the implementation of the object at all, and this can be
enforced by encapsulation.

2.3  Classes

It is a big organisational step from seeing the world as consisting of
entities to seeing the world as classes of entities; it can also be a
problematic step. Every thing is distinct, but we consider many things to
have such similar operations and behaviour we regard them as mere
instances of the larger class. In the real world, however, there are many
ways to classify things,and the ways are not always consistent. Some OOP
languages allow dynamic organisation of objects into classes; others
require the programmer to deal will classification conflicts at the design
stage, and make classes explicit in the program - this typically allows
more efficient implementation. Whichever approach is taken,there are
strong organisational reasons to structure objects into classes: it fosters
reusability, because code can be written for any instance of a class,rather
then for one particular object.

2.4  Composition

Perhaps the most common way that two different entities can be
statically structured together is by composition: where one object is used
as a component part of the other. This is common in the real world,
where technology and nature build larger things using smaller things. We
model this in programs, and so OOP languages typically allow the
construction of objects by implementing them using several other
objects. This facility thus makes further use of the reusability of objects
and classes, especially because a wide variety of larger kinds of objects
can be constructed using other classes in various ways. Moreover, the end
result is the creation of more objects and classes, allowing further
reusability still.

2.5  Inheritance

One of the ways we deal with thereal world is by organising objects with
similar operations and behaviour into classes.  As discussed above,
simple classification cannot always adequately represent the necessary
complexities. One such situation occurs when there are objects that do
seem to belong in a class, except for some specialised operations and
behaviour. In the real world this leads to taxonomical hierarchies,with a
general category at the top which is then divided and sub-divided into
increasingly specialised cases.

In OOP, this kind of classification hierarchy is usually represented
directly with inheritance. This is undoubtably the most celebrated
mechanism in OOP languages,but also the most misunderstood.

The main idea is that object of a more specialised class inherits the
operations and behaviour and operations of a more basic class.  The
usual claim is that this is a big advantage because it involves
reusing the operations and behaviour of the base class. It does involves
reusing the base class, but it is not a big advantage.  After all, the base
class can be reused perfectly well by using composition.  For example, a
manager might be regarded as having a component that is an employee.

The real advantage of inheritance is gained because the new class
conforms to the interface of the base class. That is: any place an object
of the base class can be used,an object of the specialised class can too.
Accordingly,any context code that takes objects of the base class can also
be used with objects of the specialised class. For example, if a manager is
regarded as a specialised form of employee, any program that uses
employees will also work with managers. This is the real advantage of
inheritance: it makes the context code reusable.

Some OOP discussion distinguishes inheritance and polymorphism.
Inheritance can mean that objects of the specialised class conform to the
base class interface in a primitive way by ignoring any specialised
behaviour. Polymorphism then implies the extra step, where specialised
objects conform to the base class interface,but retain their specialised
behaviour.  The nature of the advantage is the same flexibility in both
cases, simply allowing lesser or greater reusability of the context code.

Inheritance and polymorphism are used to represent classification
hierarchies in the application domain, but can also play a role in
program organisation.  Where a class of objects may have several
different implementations, they can be regarded as specialised cases of
an abstractclass.  The abstract class itself has no behaviour, but specifies
an interface to which inheriting classes conform. The advantage is that
context code may then be written in terms of the abstract class, and then
used with any inheriting class. In this way the context code will be
reusable with any implementation of the class,even if several
implementations are used within one program. Abstract classes are also
the basis of Object-Oriented Frameworks [9]. In this approach, a high-
level design is written as a program that consists only of abstract classes,
and the design is applied to particular situations by providing
implementations of the abstract classes. In this way the advantages of
reusability can be extended to the program design level, as well as the
program implementation level.

2.6  OOP and Reusability Support

Earlier we outlined our working model for reusability support. In these
terms,the key features of OOP can be described as follows:

Encapsulation: ensures safety of connecting context and component, so
ensuring both are reusable elsewhere.

Composition:  allows generality in object implementation contexts, so
that the context is reusable with other component implementations, and
equivalently that components may be reusable with various contexts.

Inheritance: enables flexibility of coupling context and component, so
that the context may be reusable with components of conforming
interfaces.

These relationships between OOPand reusability have some important
implications for object-oriented design. Most importantly,program
designers hoping to achieve reusability must understand how OOP can
help deliver it. The process of object-oriented design is largely one of
class identification and class organisation. At any point in the design,it
is reasonable to consider whether, and how well, the reusability caters for
future reuse.

In particular,there are significant implications of our observations about
inheritance and reusability. Because inheritance supports reusability of
context code, programmers should take care to design context code to
take advantage of this support, and thus facilitate later reuse. We believe
this is the major implication of inheritance for program designers, but
also suspect it is not widely understood.

Throughout the design process, understanding how OOP can deliver
reusability will can illuminate attractive options, and help lead to
success.

3   Comparison

While there have been a number of discussions on reusability, very few
consider the impact of language features on the reusability of software.
Those that do tend to blur the distinction between reuse of software and
reusability of software, often using both concepts in the same sentence as
if they are synonyms [1, 10].  As a consequence,any comments that do
pertain to reusability are overlooked.

Although the distinction between software reuse and reusable software is
often confused, it is generally accepted that effort must be made in the
creation of code if it is to be made easier to reuse. This is generally
referred to as "design for reuse". Such discussions tend to focus on
general advice and heuristics for making classes more reusable[9] or
higher-level class organizations that have been found to have been useful
in the past [11]. Other efforts such as the "adaptive software"
approach [12] support reusability with strategies and tools that use
structures within the code, but that work at a level above the code.
While all these approaches are important, and offer significant assistance
in the creation of reusable code,in our own work we have been primarily
concerned with support at the programming language level.

References

 [1]B. Meyer,"Reusability: the case for object-oriented design," IEEE
Software , pp. 50-64, Mar. 1987.

 [2]W. Frakes and S. Isoda, "Success factors for systematic reuse,"
IEEESoftware, pp. 14-22, September1994.

 [3]I. Software, "Special issue on systematic reuse," September 1994.

 [4]T. J. Biggerstaff and A. J. Perlis, eds., Software Reusability, vol. 1. New
  York: ACM Press, 1989.

 [5]B. Meyer,"Genericity versus inheritance," in 1986 Object-Oriented
Programming Systems, Languages, and Applications Conference
Proceedings (N. Meyrowitz, ed.), pp. 291-405, Oct. 1986. Published as
ACM SIGPLAN Notices, 21(11), November 1986.

 [6]P.Andreae, R. Biddle, and E. Tempero, "Understanding code
reusability:Experience with C and C++," New Zealand Journal of
Computing, vol. 5, pp. 23-38, Dec. 1994.

 [7]R. Biddle, E. Tempero, and P. Andreae, "Object oriented programming
and reusability," Tech. Rep. CS-TR-95/6, Victoria University of
Wellington, 1995.

 [8]R. Biddle and E. Tempero, "Reusability and inheritance," Tech. Rep.
CS-TR-95/8, Victoria University of Wellington, 1995.

 [9]R. E. Johnson and B. Foote, "Designing reusable classes," Journal of
Object-Oriented Programming, June/July 1988.

[10]J. Micallef, "Encapsulation, reusability and extensibility in object-
oriented programming languages," Journal of Object-Oriented
Programming, pp. 12-36, April/May 1988.

[11]E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns:
Elements of Reusable Object-Oriented Software. Addison-Wesley
Professional Computing Series,Addison-Wesley, 1995.

[12]K. J. Lieberherr,I. Silva-Lepe, and C. Xiao, "Adaptive object-oriented
programming using graph-based customization," Communications of the
ACM, pp. 94-101, May 1994.

4   Biographies

Robert Biddle is a faculty member in the Computer Science department
of Victoria University of Wellington,New Zealand. He is involved in
research on software reusability,distributed systems management, and
mathematics education.  He teaches courses on object-oriented
programming, and human-computer interaction. He received a Ph.D. in
Computer Science in 1987 from the University of Canterbury in
NewZealand; previously he received B.Math and M.Math degrees from the
University of Waterloo in Canada. He has also worked as a programmer
for Bell Northern Research, Systems Dimensions, and the Government of
Canada.

Ewan Tempero is a faculty member in the Computer Science of Victoria
University of Wellington, New Zealand. His main research interest is
examining how programming languages features affect the production of
code. His current focus is the impact programming languages,
particularly object-oriented languages,have on the reusability of the
resulting code. He is also interestedin various aspects of distributed
systems. He received a Ph.D.in Computer Science from the University of
Washington in 1990.
Second Order Reusable Libraries and Meta-Rules for Component
Generation

Ted J. Biggerstaff

Microsoft Research
One Microsoft Way
Redmond, WA 98052-6399
Tel: [phone]
Email: [e-mail]

Abstract

I discuss the scaling limitations inherent in libraries of static
reusable components and motivate the difficulties by an example. I
suggest that these limitations are not solvable in the context of
today╒s programming language representations. Finally, I propose a
different kind of reuse library called a ╥second order reuse library.╙
Such libraries extend conventional libraries of static components by
the addition of ╥meta-components╙ that transform the structure of
the static components by introducing feature variations into the
static components. I will argue that second order libraries can
overcome the limitations inherent in conventional libraries of static,
concrete components. Greater detail on the organizational
characteristics required of such meta-components is provided  in
Biggerstaff 94.

Keywords: Concrete components, repositories, limitations, payoff,
scaling, generation, transformations.
Workshop Goals: To explore the notions of new representational
abstractions for reuse components and the concomitant requirement
for generative architectures to support those abstractions.
Working Groups: Domain analysis/engineering representations, or
possibly reuse and OO methods and technology.

1   Background

I organized the first workshop/conference on reuse in Newport, RI
(1983). Since then, I have done research on reuse and related topics
(e.g., design recovery) and this has resulted in a number of books,
papers and systems. Most recently, I have been working in the area
of representations that can enhance the reusability of components
and yet allow most of the reuse to happen automatically. This work
has led me to consider the limitations of the concrete representations
(i.e., mainstream programming languages) for reusable components
and to seek ways around the limitations they introduce. The concept
of second order reuse libraries, which  include transformation-based
components, arose from this work.

2   Position
2.1  Hypothesis

The first hypothesis of this paper is that structurally static reusable
components (i.e., components that allow program construction only
via the strategies of functional composition and forward refinement
based on parametric substitution) are not adequate to solve the
scaling problem [1,2]. As a consequence, classes, abstract classes,
templates, and similar mechanisms are inadequate tools for
developing reuse systems.

The second hypothesis of this paper is that meta-components a.k.a.
meta-rules1 (i.e., rules that transform and revise the design of static
components) are required to overcome the scaling problem. The
hallmark of a meta-rule, in addition to the fact that it revises the
design of a static component, is that the operational logic of a meta-
rule may be based on design information that exists outside of the
code proper, e.g., a property of a part of the application computation.
Such design information might be derivable from the code but such
derivations typically require a difficult process of inference and
often require evidential reasoning (i.e., fuzzy reasoning) and
guessing. A further hallmark is that the effect of meta-rules is often
global across one or more components.

I will use the term ╥Second Order Reuse System╙ for libraries that
contain meta-rules in addition to static components2. By implication
then, a ╥First Order Reuse System╙ is one that contains only static
components -- components that can be composed and specialized but
not architecturally revised in an automated fashion.

I will present a small example of the kind of structural revision
typical of meta-rules to motivate the need for them and to illustrate
their nature.

2.2  Problems with composition of static components

Reuse systems that are based on static components rely on several
mechanisms to create the structure of the resulting program:

Ñ Component composition: Large scale application program structures
are formulated by the assembly of the static reusable components.
This is the fundamental strategy for building up and enriching the
structure of the target program.

Ñ Forward refinement: Forward refinement is a substitution-based
strategy that rewrites the body of a component (e.g., a macro
component or a template component) by substituting the
component╒s arguments for references to the formal parameters
within the body of the component. Forward refinement is often used
to support component composition. In contrast to function calls,
forward refinement typically happens before run time and alters the
structure of the source program.

Ñ Specialization: Specialization reduces the generality of components
by pruning parameters and paths on the basis of constant or known
data values used within the program. An example of a type of
specialization is currying functions based on knowing the data value
of one of a function╒s parameters. Specialization is a kind of forward
refinement that is also a highly constrained form of partial
evaluation.

The key problem with first order reuse libraries is that all
composition, refinement, and specialization activity is localized to
predetermined areas of a target program. However, many design
features that one would like to treat as separable components are
global in their effect and transformational in their nature. That is,
they are not static components that can be locally composed, refined,
or specialized but rather they are second order components. They are
operations on static components and very often their effects need to
be felt globally over the whole target program. The exact range of
their effect cannot be determined a priori but rather is often
dependent on the structure of the application program in which they
are used. They revise and modify basic static components to
incorporate new feature variations and to coordinate global feature
variations among the (often many) affected components.

2.3  An example of the problem

The need for meta-components is illustrated by the design of a
hypothetical Integrated Development Environment (IDE3) which one
might like to build from reusable parts. IDEs are evolving toward
architectures that perform most of their operations (e.g., compiling or
program revision) incrementally. This incrementality becomes more
and more important as the size of the target programs (i.e., the
programs developed using the IDE) grow larger and larger and the
overhead associated with batch-oriented operations (e.g., compiling)
becomes more and more onerous. Such incrementality forces
customization of the IDEs╒ architectures and this customization
introduces requirements for many variations of common static
components, that is, combinatorially many variations of what is
conceptually a single abstract component. The need for such
variability makes it difficult for reuse libraries with static
components to accommodate the resulting requirements without
combinatorially exploding (i.e., providing a hand built reusable
component variant for each combination of features that might be
needed). The alternative to combinatorial explosion of the component
library is a strategy that builds all of the feature variations into
highly general components and requires run-time data to be used to
sort out which pathways out of the complex warren of possible
pathways are applicable to a specific application of the component.
Thus, only a small portion of the features are required in any specific
application context. These general components come with so much
overhead baggage that their performance typically fails to meet the
application requirements and with such mind numbing complexity
that they are difficult to maintain and change.

Neither of these options is acceptable. The software development
organization is trapped between exploding growth of their
component library and declining performance and maintainability of
their target systems. I am claiming that the way out of this trap is to
provide a small number of basic static components that capture the
general abstractions to be reused and then add to those static
components some meta-components (or meta-rules) that revise or
massage the static components to include just those features that are
needed for any given application context.

Let us look at an example of one such feature variation and analyze
the kind of meta-component needed to accommodate it. The
following example illustrates a design feature that is motivated by
IDE incrementality. This is only one of a large number of interacting
features that are motivated by incrementality in IDEs.




Figure 1 illustrates the kind of data structures typical of an IDE
system. In this case, we have two pointer attributes -- Type and
DeepType -- within the IDE data structures. These attributes
reference remote parts of a target program. DeepType is the inferred,
most basic type of the variable or expression to which it is
associated. Type is the data type as declared by the user. Various
parts of the IDE (e.g., the compiler subsystem and often the display
subsystem) will need to use these and similar attributes. Further, the
computation of such attributes for a large program is often
computationally quite expensive. Therefore, they are often computed
once and the values cached in data structures associated with the
target variables or expressions. The algorithms for performing the
costly operations (e.g., inferring the deep type from the surface type)
are known and are likely to be components in a reusable library.
However, a problem arises from using such components in the
context of an incremental IDE system. Changes made interactively by
the user from the IDE╒s editor (e.g., changing the foo typedef) may
invalidate the cached value for DeepType attribute of the expression
╥x = a + b ;╙.

Consider the following pseudo-code (a vast simplification of a real
IDE design):
1. Infer type of operands and operator of current expression;
2. Cache results in expression description;
3.  .......
4. Respond to user edit actions;
5. Use expression type information to compile expression;

Steps 1 and 2 compute the DeepTypes and cache them. This is an
expensive operation because it may have to chain through many
levels of definitions. It is typically a batch oriented operation where
the batch size may be a single function or a full .c file. Step 3 may
potentially use the DeepType for some orthogonal purpose. For
example, the display subsystem may use the DeepType information
to compute display properties of certain kinds of program structures.
Step 4 is the user interface subsystem and it services the user who
may be using the editor to change the program. For example, the
user might decide to change ╥typedef int foo╙ to ╥typedef double foo╙,
which will invalidate the DeepType value for the expression ╥x = a +
b ;╙.

Clearly, the design of this pseudo code (which ideally would be
assembled from reusable components) has to be altered to
accommodate this potential for invalidation of the deep type
attributes and it must be altered in a coordinated and global manner.
It is important to note that the property of whether or not deep
types need to be recomputed in step 5 must be determined on the
basis of the properties of steps 3 and 4 and these properties may be
very difficult to determine in any automated way. In this case,
recomputation is necessary. So, steps 1 through 5 must be revised (in
a globally coordinated way) so that some logic is introduced to deal
with the invalidation actions and then later, to recompute the deep
type values when they are needed. There are a variety of designs
(i.e., meta-rules) that might be chosen to perform this revision. For
example, an invalidation field might be introduced at the item level,
the function level, or the module level to indicate that the deep types
must be recomputed. Similarly, depending upon how much work the
invalidation code does to narrow down the specific entities that need
to have their deep types recomputed, the actual deep type
recomputation can have a broad range of complexity and
computation costs. On the one hand, it can be fairly broad and
include extra items whose deep type does not actually need to be
recomputed in order to simplify the invalidation code. Alternatively,
the recomputation code may be much more narrow and only expend
computational resources where they are really needed, at the cost of
greater complexity in the invalidation code.

In general, the variety of invalidation designs is quite wide and often
highly application specific. Consequently, it seems unlikely that any
first order reuse library (i.e., one containing only static components)
would be able to cope with the potential variety that might be
needed. Further, the invalidation feature and its design variations
are only one class of a variety of similar features that are motivated
by IDEs that emphasize incrementalism. This rich variety lends even
more weight to the argument that first order reuse libraries will not
suffice to solve the library scaling problem.
2.4  Conclusions

The conclusions from this line of reasoning are:

1.    First order reuse libraries (i.e., those containing only static,
concrete components) will fail to solve the scaling problem;
2.    Programming constructs built in conventional languages (e.g.,
abstract classes, templates, etc.) will fail to solve the scaling problem;
and
3.    Second order reusable libraries will be required to solve this
problem, i.e., libraries that provide the ability to write general
transformations to manipulate the designs of the static components
in ways that generate feature variations of the static, concrete
components.
3  Comparison
Batory et al and Neighbors [1,3] have both effectively created second
order reuse libraries with each having slightly differing emphases.
See Biggerstaff 94 [2] for a more detailed comparison. Similarly,
Kiczales et al 91 [4] have in effect produced a mechanism that is
capable of being applied to the creation of second order reuse
libraries. The emphasis of their research, however, is focused more
on allowing clean, simple abstractions without paying the price of the
implementation inefficiency that often accompanies such
abstractions. Their technique is to open up the implementation of the
compiler and allow the user to engineer high performance
implementations based on his special knowledge of his application
context.
References

[1]    Batory, D., Singhal, V., Sirkin, M. and Thomas, J. ╥Scalable
Software Libraries.╙ Symposium on the Foundations of Software
Engineering. Los Angeles, CA, December, 1993.

[2]    Biggerstaff. T.╥The Library Scaling Problem and the Limits of
Concrete Component Reuse,╙ Third International Conference on
Software Reuse, November, 1994, Rio de Janeiro, Brazil.

[3]    Neighbors, J.M. Software Construction Using Components, PhD
Dissertation, University of California, Irvine, CA, 1980.

[4]    Kiczales, G., des Rivieres, J. and Daniel G. Bobrow, The Art of the
Metaoject Protocol, MIT Press, 1991.

Biography

Ted J. Biggerstaff is Research Program Manager of the Intentional
Programming Project at Microsoft Research Laboratories. He is
responsible for exploring ways of enhancing reuse capabilities of
application development. Before coming to Microsoft, he was Director
of Design Information at MCC where he led the research and
development of the DESIRE design recovery system. Before that, he
worked for ITT's programming laboratory (on reuse) and Boeing
Computer Service's Advanced Technology and Application Division
(on CASE tools). He received a Ph.D. in Computer Science from the
University of Washington in 1976. He is a member of ACM, IEEE
Computer Society, IEEE Software magazine Industrial Advisory
Board, and the Washington Technology Center Software Review
Board.

1 I will call these components meta-components when I wish to
emphasize their component-oriented role in reuse and meta-rules
when I wish to emphasize their operational behavior.
2 For abstractly similar ideas, see [4].
3 IDEs minimally contain an editor, compiler, and debugger. An
example of an IDE is Microsoft╒s VC++.

RAMP: A Reusable Application Module Process

Eric W. Booth

Computer Sciences Corporation
System Sciences Division
7700 Hubble Drive
Lanham-Seabrook, Maryland 20706
Tel: [phone]
 Fax: [phone]
Email:  [e-mail]

Abstract
Introducing systematic software reuse into the software engineering
process often conflicts with the primary driver of delivering the current
system on schedule and within budget. Developing for reuse can
lengthen the schedule and increases the cost in the short term. However,
until making this up-front investment, an organization cannot realize
the schedule and budget benefits of developing with reuse. Resolving this
conflict requires changing the traditional view of the software
engineering to facilitate the development and evolution of what we call
Reusable Application Modules, or RAMs.

This paper presents CSC╒s RAM Process (RAMP) which is based on the best
practices among System Sciences Division╒s most successful reuse projects
and on the current research and development that is taking place
throughout the software reuse community.

Keywords: process, software engineering, life cycle

Workshop Goals: to discuss current reuse technology trends with
researchers (particularly in the area of generative systems) and to share
technology transition and insertion experiences with researchers and
fellow practitioners.

Workshop Groups: reuse process models, product-line development,
institutionalizing reuse, generative reuse systems

1 Background
As a practitioner involved in software reuse technology transfer and
insertion, I have taken part in and observed several software reuse efforts
throughout Computer Sciences Corporation (CSC) System Sciences
Division (SSD). We document each reuse success in papers, history
reports, and corporate reprints. However, to be useful for future projects,
a reuse guidebook, capturing the best practices and outlining a
comprehensive process model was required. CSC/SSD sponsored a multi-
year IR&D effort, combining our reuse ╥best practices╙ with the promising
reuse research into, Systematic Software Reuse: A Guidebook for
Developing Cost Effective Systems [1]. This position paper summarizes
one aspect of CSC╒s guidebook: the Reusable Application Module Process
(RAMP) model, comprising three separate, parallel disciplines: domain
engineering, library management, and application engineering.


CSC╒s RAMP Model: A Systematic Software Reuse Process

2 Position: RAMP Overview

CSC╒s RAMP model provides a framework for planning and managing the
parallel domain engineering and library management activities in
addition to the more standard application engineering activity. This
framework identifies and relates the objectives, activities, and products
among the three parallel disciplines. RAMP identifies the major technical
activities involved in implementing a systematic software reuse program
and provides a list of typical products from each activity. RAMP also
provides some flexibility in selecting how each activity is accomplished,
based on the availability of legacy systems, domain experts, reuse process
experts, and schedule constraints. The choices of methods, tools, and
products are specified as part of a plan developed during context
analysis.

2.1  Domain Engineering

The focus of domain engineer-ing is much broader than application
engineering, encom-passing families of systems and multiple clients.
Individual clients typically are unwilling to incur the overhead of
creating a general solution; however, they usually are willing to reap the
benefits of domain engineering (e.g., meeting 95% of their requirements
at 50% of the cost). Organizations can accom-plish this through
investment within specific business areas. However, systems may be large
and complex and the investment can be both high-cost and long-term.
High-investment and long----term return translate into high risk. Therefore,
domain engineering may be funded separate from application
engineering and the risk mitigated by adopting an evolutionary
approach to establishing a domain engineering capability.

Domain engineering , a term gaining acceptance in the industry, is a life
cycle process for evaluating current systems and determining the
potential for creating reusable assets.  The adoption of the term domain
engineering is the result of an expanding definition for the original term
domain analysis.  Domain analysis methods have expanded to include
various levels of detail and different software life cycle activities.  Some
definitions of domain analysis include aspects of domain requirements
definition, requirements analysis, and the creation of a generic design.
Other domain analysis methods even include domain implementation
as a validation activity.Therefore, the preferred term domain engineering
(DE) encompasses all life cycle activities associated with evaluating,
selecting, or creating reusable assets:

ß    Context AnalysisDefines the domain or business area of interest,
collect collect (and possibly improve upon) available resources related to
the domain, and plan the overall domain engineeringDE effort.

ß    Domain AnalysisDefine the features and capabilities of a class of
related software systems, within the domain, and develop a general set of
requirements for the ╥product family.╙1 The requirements are described
with special consideration of the commonality between systems and the
variability among systems.

ß    Domain DesignDefine the generic design(s) or software
architecture(s) of a family of systems within the domain, called domain-
specific software architecture(s)s (DSSA). This activity defines static and
dynamic properties, component architecture, and interconnection
protocols.

ß    Domain ImplementationCreate reusable source code level assets by
translating generic requirements, into a solution that fits into the
framework of one or more DSSAs. This entails mapping the domain
language into a form that implements a DSSA. It is important to note
that the ╥reusable source code level assets╙ may comprise a translator or
generator that that embodies knowledge of the DSSA and translates the
abstract domain language to the concrete third-generation language [2].

ß    Asset TestingEvaluate if the product is right (based on previous
domain products) and if it is the right product (based on domain,
business needs, and user requirements).

2.2  Library Management

Library management is the process of growing an asset (or product)
library and the process of tracking, evaluating, and maintaining a
collection of assets, or a product line. There is a tight interaction
between the domain engineering and library management efforts. For
each library management effort there are several active application
engineering projects.

While library management is an important aspect of RAMP, it is
important to emphasize that libraries are not the reuse solution, rather
they are an important component of a systematic reuse program. It is
possible to have an effective reuse program, which produces a substantial
return on investment, with relatively few numbers of components and
without any sophisticated automated library tools. The important
ingredients for success are targeting what goes into a library and how the
library╒s contents are used. Producing a reuse library is a worthless
investment, unless there has been an accompanying change in the
management and technical culture which makes the use of the library
an integral part of the software development process.

The library management effort is an iterative process, applied across
domain engineering products. The library management activities are
grouped into a 3-P model2:

ß    PopulatingControl what goes in the library. This includes defining
the process of how assets are selected for inclusion into (or removal
from) the library.

ß    PublishingControl what is allowed out of the library, but also to
±sellε the assets to the consumers. This includes establishing an efficient
capability for the consumer to locate, evaluate, and retrieve the
necessary assets and related information.

ß    PolishingControl what (and how) changes are made to the assets
and to the library tool(s). This process must include the continual
evaluation of strategic goals and the impact of change on multiple
application engineering systems, to assure that the library and its
management system can adapt quickly to a changing business
environment.

2.3  Application Engineering

Application engineering is the term used to describe the typical software
development process that is evolving to incorporate the increasing levels
and the expanding scope of software reuse. The application engineering
life cycle is the process of composing, generating, operating, and
maintaining a software system from an existing base of reusable assets.
Software systems, or applications, are engineered in the context of a
domain to satisfy a specific client═s need.

Two key reuse activities are consumption of reuse assets and the
identification of new assets that are candidates for reuse. Assets from one
or more libraries are consumed throughout the application engineering
life cycle. Reuse consumption is composing or generating one system
with assets, in contrast to domain engineering that is building assets for
multiple systems. Reuse identification occurs when assets are unavailable
to meet a client requirement. This systematic reuse consumption and
identification changes the roles, activities, inputs, constraints, and
products for each activity of the traditional software engineering life
cycle:

ß    System Requirements Definition and DesignDetermine if the system
is within an established domain, select a discrete set of requirements
from the domain model which represent a client═s needs, and allocate
those requirements to application components based on a domain
specific system architecture. Any deficiencies in the domain model are
identified.

ß    Software Requirements DefinitionFocus is on the requirements new
to the domain model and derive project specific software requirements
specifications for each new application component.

ß    Software DesignSelect a DSSA, identify the software components,
interfaces, and relationships necessary to satisfy the system requirements
and specifications.

ß    Software ImplementationTranslate the instantiation of a generic
software architecture into executable code (a high-order language (HOL),
Fourth Generation Language (4GL), or other executable solution) and to
perform initial testing.

ß    Software and System TestFormally verify each component,
subsystem, and the overall system against the software and system
requirements.

2.4  RAMP Model Summary

In software engineering, maintenance is historically defined as ±all the
other previous activities repeated.ε In this sense the RAMP model more
closely resembles software maintenance rather than software
development. However, RAMP introduces a key change in the process.
Traditional software development and maintenance are project or
system oriented; that is, the activity is focused on one instance of a
system. RAMP is concerned with developing and maintaining a class of
systems within a targeted domain. As such RAMP is fundamentally
different from both the traditional development and maintenance
processes.

3  Comparison

This view of a systematic software reuse process is an aggregation and
organization of methods and techniques developed in the reuse
community and employed on projects in SSD. For example, we have used
elements of Feature-Oriented Domain Analysis (FODA) [3] for domain
engineering, the Basic Interoperability Data Model [4] for library
management,  and concepts from DRACO [5] for application generation.
These are methods which may be employed within the context of a
systematic software reuse process. The two activities that RAMP effort
most closely resembles are the SEI╒s Model-Based Software Engineering
(MBSE) [6] and the STARS Conceptual Framework for Reuse Processes [7].

References

[1]    Booth, E.W. and Bowen, G.M, Systematic Software Reuse: Guide To
Building Cost Effective Systems, internal publication, Computer Sciences
Corporation, 1995.
[2]    Biggerstaff, T.J., ╥The Limits of Concrete Component Reuse,╙
Proceedings of the Sixth Annual Workshop on Software Reuse, Owego, NY,
Nov. 1993.
[3]    Kang, K.C., Cohen, S.G., Hess, J.A., Novak, W.E, and Peterson, A.S.,
Feature-Oriented Domain Analysis (FODA) Feasibility Study, Technical
Report CMU/SEI-90-TR-21, November 1990.
[4]    Hobbs, E.T., et al., A Basic Interoperability Data Model for Reuse
Libraries (BIDM),  Reuse Library Interoperability Group, IEEE Standards
Committee, P1420.2 Software Reuse, April 1993.
[5]    Neighbors, J. M., ╥DRACO: A Method for Engineering Reusable
Software Systems,╙ Software Reusability, eds.: T. Biggerstaff and A. Perlis,
ACM, New York, NY, 1989, pp. 295-320.
[6]    Withey, J.V., Model-Based Software Engineering (MBSE) Draft,
Technical Report CMU/SEI-93-TR-xx, Software Engineering Institute,
November 1993.
[7]    Creps, D., STARS Conceptual Framework for Reuse Processes (CRFP)
Volume I: Definition Version 3.0, Unisys STARS Technical Report STARS-
VC-A018/001/00, October 1993.

Biography

Mr. Booth is a Senior Computer Scientist at CSC in the Applied
Technology Department supporting the NASA╒s Data Systems Technology
Division's Reusable Software Library project. He works closely with SSD
Software Process Improvement Center and CSC Corporate Technology
Center to define, train, and transition systematic software reuse into
CSC╒s process. Prior to his current assignment, Mr. Booth's responsibilities
have included software development on NASA space applications,
including satellite simulators, where he developed a DSSA, a domain-
specific specification language, and an application generator. Mr. Booth
received his MS in Computer Science from Johns Hopkins University.

1 A product family is used here to refer to a set of systems which are
logically the same, but differ in order to meet specific user requirements
(cost, configurations, country, regulations, size, safety, or other
differentiating factors).
2 The 3-P model is an instance of the class of all 3-character models.

Software Reuse in High Performance Computing

Shirley Browne

University of Tennessee
107 Ayres Hall
Knoxville, TN 37996-1301
Tel: [phone]
Fax: [phone]
Email: [e-mail]

Jacki Dongarra

University of Tennessee and Oak Ridge National Laboratory
Email: [e-mail]

Geoffrey Fox

Syracuse University
Email: [e-mail]

Ken Hawick

Syracuse University
Email: [e-mail]

Tom Rowan

University of Tennessee and Oak Ridge National Laboratory
Email: [e-mail]

Abstract

Although high performance computingarchitectures in the form of
distributed memory multiprocessors have become available, these
machines have not achieved widespread use outside of academic
research environments. The slowness in adopting high performance
architectures appears to be caused by the difficulty and cost of
programming applications to run on these machines. Economical use of
high performance computing and subsequent adoption by industry will
only occur if widespread reuse of application code can be achieved. To
accomplish this goal, we propose strategies for achieving reuse of
application code across different machine architectures and for using
portable reusable components as building blocks for applications.

Keywords: high performance computing, parallel and distributed
computation, linear algebra, distributed memory multiprocessor

Workshop Goals: Advance state of reuse of parallel software

Working Groups: Tools and environments, Education

1   Background

We have been involved in the development of the Netlib mathematical
software repository (http://www.netlib.org) and of much of the reusable
software available from Netlib and the National HPCC Software Exchange
(NHSE) (http://www.netlib.org/nse/).  The NHSE is a recent effort to
construct a distributed virtual repository of all the software produced by
the High Performance Computing and Communications (HPCC) program.
As part of the NHSE, we have developed the InfoMall technology transfer
program (http://www.infomall.org/) which identifies reusable HPCC
technologies and makes them available to industry. In the area of
parallel computing, we have carried out pioneering work in
programming applications on parallel computers and in determining
how to make the resulting codes portable across different parallel
architectures.

2   Position

High performance computing involvesthe use of parallel computing
systems to solve computationally intensive applications. Some of these
applications, termed Grand Challenges, address fundamental problems
in science and engineering that have broad economic and scientific
impact.  Examples include global climate modeling,materials simulation
at the molecular level, coupled structural and airflow simulation for
aircraft, and mapping of the human genome. The computational
requirements of these problems have pushed the physical limits of how
fast processors can operate and have focused effort on increasing the
number of processors in a multiprocessor.  Consequently, emphasis is
being placed on developing parallel algorithms and software that are
scalable,meaning that they continue to perform their tasks efficiently as
the number of processors is increased.

Parallel computing will realize its full potential only if it is accepted and
adopted in the real world of industrial applications. Cost-effective
parallel computing will require that the specialized hand coding of
parallel programs gives way to widespread reuse of parallel software.
Although specialized hand coding can achieve peak performance on
thetarget architecture, a small loss in performance will be acceptable to
achieve a more productive software development environment.

Reuse of parallel software involves the following aspects:

Portability and scalability of application codes.  Because writing parallel
programs requires substantial effort and investment, it is unacceptable
to rewrite for every current and future parallel architecture. Code that is
portable and scalable, however, will run with high efficiency on almost
all current and anticipated future parallel architectures.

Use of fundamental building blocks. A large number of scientific and
engineering applications rely heavily on a small core of linear algebra
routines. Scalable, portable, efficient, and easy-to-use versions of these
routines will provide the fundamental building blocks for applications.

We propose a strategy for promoting software reuse in high performance
computing that includes the following components:

1. A classification scheme for applications thatmaps an application to a
problem class, rather than to a machine architecture, and the
development of high level software systems based on this classification.

Fox, together with other researchers,has developed a classification scheme
for applications that includes the categories synchronous,
looselysynchronous, asynchronous, and embarrassingly parallel [1]. After
a developer maps an application to a particular class, he should express
that application in a programming language that has features optimized
for that class, rather than for a particular machine architecture. Using a
language such as Fortran 77 or C enhanced with message-passing
obscures the parallelism that is inherent in a problem. Expressing a
problem in a parallel language that is nearer the problem than to the
target machine automatically enhances reuse because the resulting
program may be more easily ported to a variety of parallel machines.

2. Development of high-level parallel languages for writing scalable,
portable code.

High Performance Fortran (HPF) [2] has been agreed on as a new industry
standard data parallel language. The synchronous and embarrassingly
parallel application classes may be expressed straightforwardly in HPF.
Researchers are working on extensions to HPF to handle the irregular
structure of loosely synchronous problems[3]. HPF compilers will be able
to obtain good performance for the same code on a variety of parallel
architectures [4]. Asynchronous problems cannot be expressed in a data
parallel language and will require different algorithmic and software
support built on top of message passing.

3. Adoption of the Message Passing Interface (MPI) portable message-
passing standard.

The MPI standard defines the syntax and semantics for a core of library
routines useful for writing portable message-passing programs in Fortran
77 or C [5].  MPI forms a possible target for compilers of high-level
languages such as HPF.

4. Development of a scalable linear algebra library for distributed
memory multiprocessors.

Researchers led by Jack Dongarra at the University of Tennessee are
developing the ScaLAPACK library of subroutines for performing linear
algebra computations on distributed memory multiprocessors [6, 7].
When completed the library will contain subroutines for performing
dense, banded, and sparse matrix computations. Among the important
design goals are scalability, portability,flexibility,and easy of use. All
communication in a ScaLAPACK library routine is handled within the
distributed Level 3 Basic Linear Algebra Subroutines (BLAS) and the Basic
Linear Algebra Communication Subroutines (BLACS), so that the user is
isolated from the details of the parallel implementation. Specially
tunedversions of the BLAS and the BLACS may be implemented by the
manufacturer of a parallel architecture to achieve near peak
performance for matrix computations.

5.Dissemination of software and information related to high
performance computing via the National HPCC Software Exchange
(HPCC).

The NHSE has a software submission and review procedure that classifies
software submissions and evaluates them according to a set of criteria
that includes scope, completeness, documentation, construction,
correctness, soundness, usability, and efficiency [8]. Roadmaps to HPCC
software and technologies are being developed that will assist the user in
locating and understanding relevant reusable components. For
example,a roadmap that illustrates the use and application of the High
Performance Fortran (HPF)language has been developed
(http://www.npac.syr.edu/hpfa/).  Educational and technology transfer
materials and activities are also being undertaken by the NHSE.

3   Comparison

The Archetype Working Groupat CalTech
(http://www.etext.caltech.edu/) is developing a library of parallel
program archetypes with the aim of reducing the effort required to
produce correct and efficient parallel programs. A parallel program
archetype is a program design strategy appropriate for a restricted class
of problems. The design strategy includes the software architecture for
the problem class, archetype-specific information about how to derive a
program from its specification,methods of reasoning about correctness
and performance, suggestions for test suites, and suggestions for
performance tuning on different architectures. An archetype identifies
the common computational and communication structures of a class of
problems and provides development methods specific to those
structures. So far archetypes have been developed for mesh
computations and for spectral methods. Archetypes are proposed as an
alternative to reuse libraries. The Archetype Group argues that reuse
libraries are inadequate for parallel programming because they are
language and run-time system specific and because of difficulties with
parallel composition of library procedures. Our approach has been to
develop portable subroutine libraries in Fortran,which is the
predominant programming languagefor scientific computing, and to
isolate the applications programmer from the details of the parallel
implementation.

The High Performance C++ (HPC++) project is attempting to extend
industry stand ard object oriented software ideas to the world of
massively parallel computing
(http://www.extreme.indiana.edu/hpc++/index.html).  Parallel
extensionsto the C ++ programming language include pC++, a data
parallel programming language that combines HPF style programming
with object oriented techniques, and CC++, a task parallel extension to
C++ suited to both distributed and parallel applications. The HPC++
project is also working to extend the Object Management Group's CORBA
and IDL specifications to support application servers running on
massively parallel computers. Such extensions will support language
interoperability between C++ based parallel programming systems and
MPI implementations. Work on parallel object oriented programming
languages complements our work on data parallel problem architectures
and on high performance linear algebralibraries.  We have developed
LAPACK++, an object-oriented C++ extension of LAPACK
(http://www.netlib.org/c++/lapack++). The object oriented approach
provides an extensible framework for incorporating extensions of LAPACK,
such as ScaLAPACK++ for distributed memory architectures.

Researchers at Rice University are developing the D System,which is a set
of tools for machine-independent data parallel programming
(http://www.cs.rice.edu/fortran-tools/DSystem/DSystem.html) [9]. The
tools support development of programs in Fortran D, an abstract,
machine-independent parallel programming language. The D System
editor allows theprogrammer to interactively parallelize existing Fortran
code, and the data mapping assistant helps the programmer choose
good decompositions for data structures. Because data parallel compilers
perform aggressive program transformations, the relationship between
the source program and ob ject program may be difficult for the
programmer to understand. Thus,the D System debugging and
performance analysis tools support analysis in terms of the source
program. Fortran D is a predecessor to HPF, and features of the D System
are expected to carry over to environments for HPF and other data
parallel languages.We speculate that the D System might be extended to
support our problem classification scheme andto partially automate
selection and use of linear algebra components.

References

[1]G. Fox,R. Williams, and P. Messina, Parallel Computing Works. Morgan
Kaufmann, 1994. Accessible on-line at
http://www.infomall.org/npac/pcw/.

[2]"High Performance Fortran language specification, version 1.1," Tech.
Rep. CRPC-TR92225, High Performance Fortran Forum,Nov. 1994.
Available at http://softlib.rice.edu/CRPC/softlib/TRs_online.html.

[3]K.  Dincer,  K.  Hawick,  A.  Choudhary,  and  G.  Fox,  "High
Performance Fortran and  possible  extensions  to  support  conjugate
gradient  algorithms," Tech.  Rep.  SCCS-703,  Northeast  Parallel
Architectures  Center,  Syracuse  University. Available  at
http://www.npac.syr.edu/techreports/.

[4]Z. Bozkus, A. Choudhary, G. Fox, T. Haupt, and S. Ranka,
"CompilingHPF for distributed memory MIMD computers," Tech. Rep.
SCCS-507, Northeast Parallel Architectures Center, Syracuse University.
Available at http://www.npac.syr.edu/techreports/.

[5]J.  Dongarra,  S.  Otto, M.  Snir,  and  D.  Walker,  "An  introduction
to the  MPI stan-dard,"  Tech.  Rep.  UT-CS-95-274,  University  of
Tennessee,  Jan.  1995. Available  at http://www.netlib.org/tennessee/.

[6]J. Dongarra and D. Walker, "Software libraries for linear algebra
computation on high-performance computers," Tech. Rep. ORNL-TM-
12404, Oak Ridge National Laboratory, Aug. 1993. Available at
http://www.netlib.org/tennessee/.

[7]J. Choi, J. Demmel, I. Dhillon, J. D. S. Ostrouchov, A. Petitet, K.
Stanley, D. Walker, and R. C. Whaley, "ScaLAPACK: a portable linear
algebra library for distributed memory computers," Tech. Rep. UT-CS-95-
283, University of Tennessee, Mar.1995.  Available at
http://www.netlib.org/tennessee/.


[8]S. Browne,  J. Dongarra,  K. Kennedy,  and T. Rowan,  "Management of
the NHSE  - a  virtual,  distributed digital  library,"  in  Digital  Libraries
'95,  (Austin, Texas),  June 1995.   Also  available  as  University  of
Tennessee  Technical  Report  UT-CS-95-287  at
http://www.netlib.org/tennessee.

[9]V. Adve, A. Carle, E. Granston, S. Hiranandani, K. Kennedy, C. Koelbel,
U. Kremer, J. Mellor-Crummey, C.W. Tseng, and S. Warren, "Requirements
for data-parallel programming environments,"IEEE Transactions on
Parallel and DistributedTechnology, vol. 2, pp. 48-58, Fall 1994. Also
available at http://softlib.rice.edu/CRPC/softlib/TRs_online.html as
CRPC-TR944378-S.

4   Biographies

Shirley Browne is a Research Associate and Adjunct Professor in the
Computer Science Department at the University of Tennessee, where she
is a member ofthe Netlib Development Group. Her research interests are
in replicated database issues for a scalable information infrastructure
and in information system support for software reuse. She received a
Ph.D. in Computer Sciences from Purdue University in 1990.

Jack Dongarra holds a joint appointment as Distinguished Professor of
Computer Science in the Computer Science Department at the University
of Tennessee (UT) and as Distinguished Scientist in the Mathematical
Sciences Section at Oak Ridge National Laboratory (ORNL) under the
UT/ORNL Science Alliance Program.  He specializes in numerical
algorithms in linear algebra, parallel computing, use of advanced-
computer architectures, programming methodology, and tools for
parallel computers. Other current research involves the
development,testing and documentation of high quality mathematical
software. He was involved in the design and implementation of
the software packages EISPACK, LINPACK, the BLAS, LAPACK, ScaLAPACK,
Netlib/XNetlib, PVM/HeNCE, MPI andthe National High-Performance
Software Exchange,and is currently involved in the design of algorithms
and techniques for high performance computer architectures. He
received a Ph.D. in Applied Mathematicsfrom the University of New
Mexico in 1980.

Geoffrey Fox is an internationally recognized expert in the use of parallel
architectures and the development of concurrent algorithms.  He leads a
major pro ject to develop prototype high performance Fortran
(Fortran90D) compilers. He is also a leading proponent for the
development of computational science as an academic discipline and a
scientific method. His research on parallel computing has focused on
development anduse of this technology to solve large scale
computational problems. Fox directs InfoMall,which is focused on
accelerating the introduction of high speed communications and
parallel computing into New York State industry and developing the
corresponding software and systems industry. Much of this activity is
centered on NYNETwith ISDN and ATM connectivity throughout the state
including schools where Fox is leading developments of new K-12
applications that exploit modern technology. Fox is currently a Professor
of Computer Science and Physics at Syracuse University and director of
NPAC, The Northeast Parallel Architectures Center.He obtained his PhD
from Cambridge, England and spent 20 years at Caltech where he was
Professor and Associate Provost for educational and academic
computing.

Ken Hawick is a research scientist at the Northeast Parallel Architectures
Center (NPAC) at Syracuse University,working in the areas of
computational scienceand high performance computing, and in
information technology for industry. He formerly headed the Numerical
Simulations Group at the Edinburgh Parallel Computing Centre in
Edinburgh, Scotland.

Tom Rowan is a Collaborating Scientist in University of Tennessee's
Computer Science Department and Oak Ridge National Laboratory's
Mathematical Sciences Section. His primary research interests are in the
areas of numerical analysis and mathematical software. Much ofhis
research has focused on developing algorithms and software for
automatic detection of instability in numerical algorithms and for
optimization of noisy functions. He received his Ph.D. from the
University of Texas at Austin in 1990.
A Program Editor to Promote Reuse

Paolo Bucci

Department of Computer and Information Science
The Ohio State University
2015 Neil Avenue
Columbus, OH 43210
Tel: [phone]
Email: [e-mail]

Abstract

A software engineer's mental model of software is influenced  by many
factors, including the application, the programming language, and even
the programming environment. In particular, all programmers have to
interact with a program editor, i.e., a tool to enter, modify, and view
programs. This tool plays a role in shaping the way programmers think
of software and of the software development process. In this position
paper we explore the impact of the program editor on the programmer's
view of software, and in particular those aspects thathave direct
relevance for safe and successful software reuse.

Keywords: Programming environment, software reuse, software education,
reuse education

Workshop Goals: Learning, networking

Working Groups: Design guidelines for reuse, tools and
environments,education

1   Background

For the past decade,the Reusable Software Research Group (RSRG) at the
Ohio State University has been exploring various aspects of software
reuse, and in particular a component-based reuse technology for software
engineering. This has resulted in the RESOLVEframework, language and
discipline for component engineering [1].

Several of the ideas developed by the group have found their way into
software courses at OSU and elsewhere. Efforts are under way to redesign
and restructure the OSUsoftware curriculum to reflect the need for a
software education aimed at a modern integrated component-based view
of software engineering. The success of this new approach will depend in
part on the availability of appropriate tools to assist the programmer in
the development and composition of software systems.

This position paper describes some of the issues involved in the design of
a program editor that will be able not only to support, but also to
promote a disciplined, organized view of software that emphasizes good
"component engineering" habits.

2   Position

Program editors usually are seen by programmers as simple, somewhat
unsophisticated tools that do not (and are not expected to) provide
assistance beyond the features of, say, a text editor. In part, this is due to
the fact that most programmers form, from the beginning, a mental
model of software as plain text. They learn to program with text editors
that give them complete freedom and usually little guidance during the
processof program development, and they never consider how much
more an editor could and should provide.

In this paper, however, we take the position that a carefully designed
program editor could be quite sophisticated in providing assistance
tothe programmer. This would free programmers from uninteresting (but
essential) concerns, while appropriately guiding them towards better
programming practices and productive software reuse.

As discussed in the next sections,there are many ways in which a
program editor could support software reuse. It is important to realize,
however, that for the editor to have a real impact on software reuse,and
essentially on the way programmers think,it is necessary for the editor to
be designed with this goal in mind. Furthermore, experience with other
programming environments, such as structure editors and syntax-
directed editors, suggests that such an editor would be more likely to
succeed in its goals and to be accepted by programmers if it were used
from the beginning in the training of software engineers.  This is before
programmers have the opportunity to form in appropriate mental
models and before they learn unsafe programming habits. A well-
designed editor that truly promotes software reuse and that supports
safe, disciplined programming practices could also be useful in helping
experienced programmers make the transition from old habits to more
modern approaches to software engineering and software reuse.

Throughout this paper we will refer to a program editor (or simply an
editor) as the tool used to enter,modify, and view programs.

2.1  The editor should provide a consistent, high-level view of software

Program editors provide the programmer with a view of what software is
and how it can be manipulated. This view contributes to themental
model of software that the programmer forms while editing. The mental
model that the editor projects depends essentially on two things: the
representation used to display software components, and the kinds of
operations the editor provides to the user to manipulate, modify, and
combine components.  For example, a text editor that displays programs
as simple text,and that provides only text-editing operations, promotes a
model of software as plain text with no other structure or abstraction.

Programmers are affected by themo del of software presented by the
editor. When interacting with the editor,their thinking is inevitably
biased towards the structures they are editing and the transformations
that are allowed by the editor.

If software systems are to be constructed by explicitly combining reusable
components [2], the editor must not only allow the editing of
components, but also their retrieval and composition, and this in as
uniform and consistent away as possible. It has to make sure that
components can be reused based on their abstract specifications and
without the need to know the details of their implementation. It must
also ensure that components are reused only where appropriate.  In
other words, the editor needs to actively promote a component view of
software,as opposed to a text view of software, and it has to allow only
safe operations on components.

For the above goals to be achievable, the editor needs to present a higher-
level model of software than the currently available editors such as text
editors or syntax-directed, structure editors. It is essential that the
representation be abstract, and that the operations allowed operate at a
conceptual (and not just syntactic) level, so the programmer can clearly
see what each entity in the program does, and can think in terms
ofabstract concepts instead of syntactic units, or just sequences of
characters.

2.2  The editor should promote (even enforce) a good programming
discipline

It has been recognized that programming for reuse and with reuse
requires a disciplined approach on the part of software engineers [3].
Clearly,we want to allow programmers to think about conceptual
problems rather than spending time worrying about those aspects of
principles and guidelines that can be enforced by the editor (not to
mention syntax and other statically checkable properties of software).

The editor can be seen as a tool to guide software engineers through the
hard task of writing programs by ruthlessly pruning the space of all
possible programs, eliminating those that do not satisfy certain rules or
that do not obey certain disciplines.  In this way, the editor allows only
syntactically and static semantically correct programs. But more
importantly,it supports the user in the application of appropriate
programming disciplines. Especially during the training stage,an editor
that enforces a good programming discipline can be an invaluable tool
in teaching appropriate programming habits, from the beginning.

Existing editors vary in the amount of freedom (or lack of guidance) they
give to the programmer: from text editors that have no restrictions
(leaving the burden completely on the programmer),to syntax-directed
editors that enforce syntactic correctness of the program and possibly
include some static semantic checking.In any case, most such editors do
notconsider the possibility of helping users follow safe programming
disciplines.

2.3  The editor should support safe reuse techniques and prevent unsafe
ones

As an example of an "unsafe" (though commonly used) reuse technique,
consider source code scavenging. In most cases, programmers copy a
fragment of code and then proceed to modify the copy to make it fit the
new context and new purpose. This process is the source of many subtle
and not-so-subtle mistakes,due to lack of a full understanding of the
code being copied and of the differences in the contexts of the original
code and the copy.

The idea of copying and pasting arbitrary segments of source code is
clearly encouraged by text editors and the text mental model. However,
commonly used editors do not provide any support or guidance to assist
programmers in the safe application of this form of reuse. Part of the
problem is the fact that code scavenging is based on copying a code
fragment whenever its (textual) representation is similar to the (textual)
representation of the code that has to be written. Given this, it is almost
impossible to conceive of any assistance the editor might provide.  On
the other hand, if the editor provides a higher-level view of code, and if
it promotes source code reuse of similar conceptual units (as opposed to
syntactic units that only share similar representations), then it can
attach to the copied unit all the context information necessary to give it
a meaning,and this information can be used by the editor to guide the
programmer in adapting it to the new context.  In this way,unsafe
scavenging of text fragments can be prevented, while the safer, editor-
assisted reuse of conceptual units can be supported.

3   Comparison

Program editors have been an active area of research for over 30 years,so
there is an extensive body of literature on the subject,with many
different approaches and points of view. There is an ongoing debate
between advocates of text editors and supporters of syntax-directed,
structure editors. The common observation is that experienced
programmers are comfortable with text editing capabilities, and are not
willing to accept the restrictions imposed by structure editors; while
novices find the help and guidance provided by structure editors helpful
[4, 5]. Still others support editors that combine the characteristics of
both text and structure editors [6, 7]. Our claim here is that both text
and parse trees are inadequate models of software for effective support of
reuse; specifically, text and parse trees are too low level.

Other researchers [5, 8] have recognized the importance of the
programmer's mental model of software for the success of a syntax-
directed editor.  Theyhave speculated that the obvious lack of
popularity of existing syntax-directed,structure editing environments
among experienced programmers is due to poor design of editors,
particularly their user interface and the view of software that is
promoted.

Some researchers [9] have advocated using structure editors to reinforce
concepts of good programming methodology in novice programming
courses. However, noone seems to have taken the more pro-active
position that program editors have the potential to help shape the way
programmers learn to think about software and about how it is
developed. Hence,researchers typically advocate designing editors to
satisfy the demands ofto day's programmers, e.g., supporting text editing
features. Otherwise,experienced programmers will not use them. In
contrast,our view is that editors should be designed with the goal of
assisting,and even leading, programmers in the process of program
development. We believe that such editors could promote software reuse
and contribute positively to training in reuse.

References

[1]M. Sitaraman and B. W. Weide, eds., "Special Feature: Component-
Based Software Using RESOLVE," ACM SIGSOFT Software Engineering Notes,
vol. 19, pp. 21-67, Oct. 1 994.

[2]B. W. Weide,W. F. Ogden, and S. H. Zweben, "Reusable software
components," in Advances in Computers (M. C. Yovits, ed.), vol. 33,
Academic Press, 1991.

[3]J.Hollingsworth, Software Component Design-for-Reuse: A Language
Independent Discipline Applied to Ada.  PhD thesis, Dept. ofComputer
and Information Science, The Ohio State University, Columbus, OH, 1992.

[4]S. Dart, R. Ellison, P. Feiler, and A. Habermann, "Software Development
Environments," Computer, vol. 20, pp. 18-28, Nov. 1987.

[5]S. Min|r,"Interacting with Structure-Oriented Editors,"International
Journal of Man-Machine Studies, vol. 37, pp. 399-418, Oct. 1992.

[6]R. Waters,"Program Editors Should Not Abandon Text Oriented
Commands,"ACM SIGPLAN Notices, vol.17, pp. 39-46, July 1982.

[7]R. Bahlke and G. Snelting, "Design and Structure of a Semantic-Based
Programming Environment," International Journal of Man-Machine
Studies, vol. 37, pp. 467-479, Oct. 1992.

[8]J. Welsh and M. Toleman, "Conceptual Issues in Language-Based
Editor Design," International Journal of Man-Machine Studies, vol. 37,
pp. 419-430, Oct. 1992.

[9]D. Garlan and P. Miller, "GNOME: An Introductory Programming
Environment Based on a Family of Structured Editors," ACM SIGPLAN
Notices, vol. 19, pp. 65-72, May 1984. Proceedings of the ACM
SIGSOFT/SIGPLAN Software Engineering Symposium on Practical Software
Development Environments.

Biography

Paolo Bucci is a doctoral student in the Department of Computer and
Information Science at The Ohio State University. He received his
undergraduate degree in computer science from Universita degli Studi,
Milan, Italy in 1986,and his M.S. in computer science from Ohio State in
1989. His current research interests include software design and
reuse,programming environments, programming languages, and
education.

Mr. Bucci gratefully acknowledges financial support from the National
Science Foundation (grant number CCR-9311702) and the Advanced
Research Projects Agency (contract number F30602-93-C-0243, monitored
by the USAF Materiel Command, Rome Laboratories, ARPA order number
A714).
Design Deltas in Reusable Object-Oriented Design

Greg Butler

Centre Interuniversitaire en Calcul Mathematique Algebrique
Department of Computer Science
Concordia University
Montreal, Quebec, H3G 1M8 Canada
Tel: [phone]
Tel: [phone]
Fax: [phone]
Email:[e-mail]

with Peter Grogono, Li Li, Ra jjan Shinghal, Ono Tjandra

Department of Computer Science
Concordia University
Montreal, Quebec, H3G 1M8 Canada


Abstract

Reusable object-oriented design aims to describe and classify designs and
design fragments so that designers may learn from other peoples'
experience. Thus, it provides leverage for the design process. The field
includes software architectures, application frameworks, design patterns,
and the design of class libraries. The field is young with many open
problems that still need to be researched.  This position paper opens a
discussion on "design deltas" to describe increments of change in designs
that arise in software evolution,between versions of software,and in
adaptation during  white-box reuse.

Keywords: Reuse, design, framework, design pattern, architecture, formal
methods

Workshop Goals: Learning; networking; clarifying "design deltas";

Working Groups:reuse of designs, reuse and OOmethods, formal methods,
design guidelines for reuse _ C++

1   Background

My background in computer algebra systems is described in my WISR6
position paper [1]. These experiences convinced me that a more flexible
environment, using a single language, C++, is needed to research the
issues of software architectures and their integration for computer
algebra systems.  Also, there is a greatneed from researchers in algebraic
algorithms for a software library. Since moving to Concordia University
at the end of 1991, my research has focussed on C++ libraries and
frameworks, issues of reuse, and issues of reliability (which includes
correctness).

In the past two years I have been actively leading a discussion group at
Concordia on C++ programming and object-oriented design. These have
recently split into two discussion groups, the latter concentrating on
design patterns. Ialso teach a course on object-oriented design based on
OMT [14] that also includes material on reuse.

On the research side there is ongoing work on application frameworks for
combinatorial enumeration [6] and deductive databases [2] are in
preliminary stage of construction with the help of students: we are still
learning how to develop and document frameworks - much more
practical implementation needs to be done;

use of design patterns for development and documenting software
(especially frameworks) is the focus of several student projects, and the
discussion group on object-oriented design;

survey of reusable object-oriented designlooked at reuse of design
artifacts: how they were developed, how they were reused, and how they
were described/documented/specified and classified [7];

trends in software engineering for which there was documented empirical
evidence for their cost benefits were surveyed [3]: this included
improvements in process quality and product quality, software reuse at
the level of code component, frameworks, and application generators,
and the use of formal methods and other modeling notations;

document understanding for reverse engineering was investigated with
colleagues[5, 4] to consider whether reverse engineering of legacy systems
could benefit from knowledge extracted automatically from paper
documents: we are concentrating on data flow diagrams.

In recognition of the importance of software evolution, at the WISR7
workshop I wish to focus onhow to describe design increments and clarify
the notion of what is a "design delta".

2   Position

The conclusions from [7] contain my position on research directions in
reusable object-oriented design:

" One clear conclusion is that reusable design artifacts are the result of
evolution and iteration. This is especially true for application
frameworks and class libraries - the concrete artifacts, where all details
must be spelt out.

" Another clear conclusion is that models and notations play several
important roles. The abstract artifacts are themselves models, but even
for them the role of models and notations extends much further.

Models and notations are an aid to communication.

Models and notations improve understanding through precision,
conciseness, and visual cues.

A model or documentation template often providesa checklist of the
information needed to fully understand or reuse a design artifact. For
example, these may include:

- responsibilities of each participant;

- collaborations amongst participants;

- purpose of the artifact; and

- preconditions for applicability.

" There are many open problems for architectures, frameworks, micro-
architectures, and, to a lesser degree,for the design of class libraries. We
have broadly categorized these into problems of retrieval, understanding,
and evaluation.

" Retrieval problems are those related to the classification and
description of design artifacts,as well as the problem of enlarging our
catalogue of known reusable design artifacts.

" Each of the following is aimed towards enlarging and organizing our
knowledge of design artifacts. This provides a base from which to retrieve
design artifacts and also provides a conceptual classification scheme
that forms the basis of the attributes mentioned in retrieval queries.
Although we have seen examples of work on each of these areas in this
survey,there is much more that needs to be done still.

A taxonomy of design artifacts provides a map of the space of artifacts,
their commonality and their differences. This organizes our
knowledge,helps designers to appreciate the breadth of choices and
trade-offs, and may guide the discovery or invention of new artifacts,and
assist the development of design notations and languages.

Classification of individual artifacts according to their significant or
 distinguishing features aids our understanding of that individual
artifact and contributes to the development of the taxonomy.

Cataloguing the existing design artifacts requires assistance from industry
to release details of the design of their systems. Our understanding of
software architectures and application frameworks depends heavily on
enlarging the base of examples in the catalogue, particular to assist the
development of a taxonomy. The invention and discovery of new designs
is also a part of this open problem.

" Understanding problems are those related to reducing the effort by a
reuser to understand a design artifact and to understand how to reuse a
design artifact.

Documentation styles and standards are required to ensure that all
information needed by reusers is documented, and to present the
information to reusers in a timely fashion: that is, precisely when they
need it.

The spiral approach of patterns tailors the timing and volume of
information that a reuser of a framework is presented with. The
documentation templates for design patterns ensures that each item of
necessary information is provided, and that examples of use are also
included.

Documentation of architectures and class libraries is still in need of good
styles and standards.

Formal specification and description of design artifacts claim to provide
improved precision, conciseness, and reasoning. Each of which may
improve understanding.  Most of the work on the description of design
artifacts has been done by practitioners who do not share a  belief in the
merit of formal specifications: they used natural language and diagrams
for their documentation.  As a consequence there is only a small body of
work on how to formally specify design artifacts. There is scope for
further work in this area.

Experimental validation of claims that certain do cumentation or
specification styles do improve understanding in practice is required. All
asp ects of research into software development need a firm experimental
foundation.

" Evaluation problems include thoseof comparing design artifacts, those
concerned with the evolution of artifacts, and the problems of evaluating
design artifacts.

Metrics for design artifacts are in very short supply. The correlation
between metrics and the desirable qualities of a design also needs to be
established quantitatively. The metrics research community is large and
active so we predict that a stream of new design metrics will be
forthcoming. There is also a strong interest from practitioners who are
establishing quality assurance programmes and are collecting the
necessary data to confirm any correlation between measurement and
quality.

Specifying and describing the evolution of a design and the differences
between designs may require a notion of a "design delta" to capture the
increment of change or difference. Alternatively, evolution could be
viewed transformationally,and the increment would be a description of
the transformation. Ralph Johnson and his students call these
transformations "refactorings". Given the importance of evolution,
refinement,and iteration to design and reuse, this is a major open
problem for reusable object-oriented design. "

It is this last point: the importance of the notion of a "design delta" for
describing the evolution of a design (just as a source code delta is used
in software configuration management [16] to describe the differences
between versions of code) that I think deserves more study at WISR7.


3   Comparison

The notion of a "design delta" is related tomany existing concepts. Each
of which might help us clarify a precise definition of the notion.

Refactoring describes a reorganisation of the class hierarchy for an object-
oriented system [8] as a means of identifying reusable classes or
frameworks. Johnson and Opdyke [12, 11] have catalogued several
refactorings as transformations on the class hierarchy.

Programming-by-difference constructs a design increment by
specialisation of asuperclass. So the equation
                            design = subclass n superclass
or one can view the subclass definition alone as the "design delta".

Mixins are a purer form of programming-by-difference. A mixin is a
design increment.

Adaptation in software reuse allows controlled change via instantiation
or specialisation,and allows uncontrolled editing of source code: perhaps
editing to produce a "design delta" provides controlled white-box reuse
which lies between these two extremes.

Increments in Cleanroom software development are documented in a
construction plan that divides the system development into vertical
increments instead of the traditional horizontal breakdown into
subsystems. Each vertical increment describes a working system,though
with a subset of the behavior, and should correspond to a part of the
top-level black box and a part of the usage model and usage profile [9].

Change management   inthe PRISM software process model [10]
documents changes in staff, policies, laws, processes or systems on sheets
that record dependency, resource, and status information.

Design steps are the actions taken during design in response to the
identification of issues and their resolution via arguments for and
against in the model of Potts and Bruns [13]. Design increments are
implicit in the model as paths (sequences of arcs) relating two design
artifacts.

Re-engineering  in the most simple case at the design level involves two
designs  D and D0 for a common specification S, so although the designs
differ (by a design delta) there is a context which is invariant: the
specification of their observable behaviour.

Transformational software development maps a specification S to a
design (and eventually to an implementation) D via a sequence of
transformations f which are guaranteed to preserve semantic correctness.
A change in specification to S0 leads to a new design D0. It would be
convenient if a design increment D0 n D was f(S0 n S), however there are
two obstacles: The change in specification may require a change in the
choice of transformations; and, even if that does not occur, we would
require the incrementof change in the specification to itself  be a
specification (of something meaningful) in order to apply f.

Composition operators such as in Z schema calculus [15] can describe
increments of change in specifications as specifications. It is common Z
practice to separate the specification of typical behaviour (the
AddBirthday schema) from error-handling described in terms of
successful execution (the Success schema) and error-type (the
AlreadyKnown schema).

              RobustAddBirthdayb=(AddB irthday^ Success) _ AlreadyKnown:

References

 [1]G.Butler, Reusable reliable software components for computer algebra.
Position paper for the 6th AnnualWorkshop on Software Reuse to be held
in Owego, November 2-4, 1993.

 [2]G.Butler, Datalog and Two Groups and C++, to appear in Proceedings
of the Second International Conference on Artificial Intelligence and
Symbolic Mathematical Computing,Cambridge, UK, August 3-5, 1994.

 [3]G.Butler, Technical trends in industrial software engineering: Quality,
reuse, modelling,submitted.

 [4]G. Butler, P. Grogono, R. Shinghal, I.A. Tjandra, Analyzing the logical
structure of data flow diagrams in software documents, to appear in
Proceedings of Third International Conference on Document Analysis and
Recognition, Montreal, Canada, August 14-16, 1995.

 [5]G. Butler, P. Grogono, R. Shinghal, I.A. Tjandra, Knowledge and the
recognition and understanding of software documents, submitted.

 [6]G. Butler and C.W.H. Lam, The preliminary design of an object-
oriented framework for combinatorialenumeration, to appear in
proceedings of the Colloquium on Object Orientation in Databases and
Software Engineering, 62nd Congress of ACFAS, May 16-17, 1994,
Montreal.

 [7]G. Butler, L. Li and I.A. Tjandra, Reusable object-oriented
design,submitted.

 [8]R.E. Johnson and B. Foote, Designing reusable classes, Journal of
Object-Oriented Programming 1 (1988) 22-35.

 [9]Even-AndreKarlsson, Reuse and cleanroom, 1st European Industrial
Symposium on Clean-room Software Engineering, 26-27 October, 1993,
Copenhagen.

[10]N.H.Madhavji,Environment evolution: The PRISMmodel of changes,
IEEE Trans. Software Eng. 18, 5 (May 1992) 380-392.

[11]William F. Opdyke, Refactoring Object-Oriented Frameworks, Ph.D.
Thesis, University of Illinois at Urbana-Champaign, 1992.

[12]W.F. Opdyke adR.E. Johnson, Refactoring: An aid in designing
application frameworks and evolving object-oriented systems,
Proceedingsof the Symposium on Object-Oriented Program-ming
Emphasizing Practical Applications (SOPPA), September 1990.

[13]C. Potts and G. Bruns, Recording the reasons for design decisions,
Proceedings of the 10th International Conference on Software Engineering,
IEEE Computer Society Press, Los Alamitos, CA, 1988, pp. 418-427.

[14]J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorenson, Object-
Oriented Modelling and Design, Prentice Hall, 1991.

[15]J.M. Spivey, The Z Notation: A Reference Manual, Prentice Hall,1992.

[16]Walter F. Tichy, RCS - A system for version control, July 1985, 19
pages.

4   Biography

Gregory Butler is Associate Professor in Computer Science and a member
of Centre Interuniversitaire en Calcul Mathematique Algebrique
(CICMA)at Concordia University, Montreal,Canada. His research interests
are reusable object-oriented design, software architectures, C++ libraries
and frameworks for computer algebra systems which integrate
knowledge-based facilities. He obtained his PhD from the University of
Sydney in 1980 for work on computational group theory. He spent
1976/77 at ETH, Zurich as part of his doctoral studies, and for two years,
1979-1981, was a postdoctoral fellow at McGill and Concordia
Universities in Montreal. He was on the faculty of the Department of
Computer Science at the University of Sydney from 1981 to 1990. He has
held visiting positions at the University of Delaware and Universitat
Bayreuth.
Evolutionary Metrics Adoption Method for Reuse Adoption

Patricia Collins & Barbara Zimmer

Hewlett Packard Software Initiative
1501 Page Mill Road, Bldg. 5M
Palo Alto, CA 94303
Tel: [phone]
Email: [e-mail], [e-mail]


Abstract

Adoption of reuse metrics using an evolutionary approach is well
matched to organizational readiness for metrics in managing reuse
adoption..

In Hewlett-Packard, groups are using an evolutionary development
and delivery lifecycle [4] to manage reuse risks and to address the
very real limits in an organization's ability to adapt to changes.  We
have developed a method for reuse metrics adoption that reflects
this evolutionary approach.  The metrics identification method is a
refinement of Basili's Goal-Question-Metric paradigm.[1]  We have
extended the Goal Statement activity to include explicit alignment of
reuse goals with business goals.   The questions and metrics
identification are highly focused.  The focus is guided by the desire to
manage the risk of the reuse adoption and the limits of the
organization in adopting metrics; therefore, those questions and
metrics most likely to aid the organization in managing their reuse
risks are identified and adopted first.

 In reuse adoption and institutionalization, cultural and
organizational issues can determine the success of the effort.  For
that reason, reuse metrics can play a particularly important role in
communications for building and reinforcing partnerships, assessing
and ensuring customer satisfaction, communicating value, and
monitoring impact and progress.

Keywords: software metrics, reuse metrics, reuse management, GQM
paradigm, metrics implementation, evolutionary lifecycle

Workshop Goals: Exchange learnings in incremental reuse adoption,
including adoption models and methods, the role of metrics and
alternative means of managing reuse.

Working Groups:
Patricia:
1.    Reuse process models
2.    Domain analysis/engineering
3.    Reuse and OO methods and technology
Barbara:
1.    Reuse management, organization and economics
2.    Reuse maturity models
3.    Useful and collectible metrics

1   Background
In the HP Software Initiative, Patricia Collins served initially as a
reuse process improvement consultant, pioneering the use of domain
analysis and utilizers' needs analysis methods within HP.   While she
is still considered a corporate resource for reuse process knowledge,
she now also partners with R&D groups to develop roadmaps, plans,
and implementations for reuse adoption and institutionalization that
address reuse processes and methods, process improvement adoption
methods (including change management), reuse metrics, reusable
architecture and design methods, and organization redesign.
Barbara Zimmer has been working in partnership with several HP
R&D groups to plan and implement software metrics programs in
reuse organizations.  She has written an extensive review of software
reuse activities in HP that has been used as a valued reference by HP
groups exploring software reuse.

2   Position

For the past five years, organizations in Hewlett-Packard have been
moving from leverage of software between successive products to
systematic reuse of software among products being developed in
very close succession, or even in parallel.  The need for reuse is not
in question, since there are few proposed alternatives for achieving
the diverse business goals of these organizations.  Typically, the
move from leverage to systematic reuse is motivated by a need for
higher productivity, decreased time-to-market, increased rate of
innovation, and/or limited resources.

This paper describes a few of our specific innovations in software
metrics adoption methods. The HP Software Initiative's Evolutionary
Reuse Metrics Adoption (ERMA) Method refines the work of others in
goal, question, and metrics (GQM) identification and implementation,
as well as the management of this change (metrics adoption) in the
organization.  This paper focuses on innovations in the identification
and implementation parts of the method.

Traditionally, the GQM method has involved full enumeration of
goals, then questions whose answers can help evaluate progress
toward the goals, and then metrics that can be used to answer the
questions.  Organizations new to using metrics to manage reuse
adoption are easily overwhelmed by this exhaustive method.  This
can result in lost momentum for metrics adoption or circumventing
the GQM process entirely in favor of metrics that may contribute
nothing to managing toward their critical goals.

The ERMA method keeps the GQM process highly focused on
delivering metrics that provide information needed to manage
progress toward critical goals.  The innovations of ERMA are:
-    Explicitly state the goals as well-formed, strategic objectives
-    Identify which objectives require metrics support for progress
toward that objective to be managed.  Include reasons metrics are
critical for each goal selected.
-    Identify 1 or 2 key assessment questions for the objective(s).
The assessment questions are well formed (i.e., they align with the
well-formed objective, and the answer to the question
enables the organization to assess progress toward the objective).
-    Identify criteria for what metrics will be used (e.g.
organization's readiness, collectibility).
-    Identify 1 or 2 metrics for the question(s) deemed to be most
critical for managing reuse adoption.

The essence of our contribution is thus a pruning of the GQM
expansion process, the support for distinguishing between
assessment and understanding questions, and evolutionary
identification and implementation appropriate to incremental reuse
adoption.  In practice, we contribute significantly by facilitating the
development of well-formed objectives, an essential first step in the
GQM process. We describe these innovations through representative
examples from our experiences in reuse metrics adoption.

2.1  Goal Clarification
Establishing reuse goals that are aligned with business goals is a new
activity for HP engineering organizations.  In one organization that
was exploring the potential for designing and developing a reusable
measurement platform, the first step was to conduct a domain
analysis (DA), which  included the explicit delineation of DA goals.
We developed and delivered a domain analysis workshop that first
focused on  the overall business goals, then  aligning the reuse goals
with those business goals, and finally aligning the domain analysis
goals with the reuse and business goals .  The workshop participants
represented four related, but traditionally independent product line
organizations which develop and manufacture test equipment.

In order to understand what approach (e.g., reuse) might adequately
support a business goal, we interviewed stakeholders in each
organization who understood business and market trends, current
practices, internal and external constraints, and what was possible to
achieve. The interviews allowed us to assure the business goal
statements were aligned with the intentions of the organizations.  For
example, one organization╒s breakthrough goal was to shorten the
time-to-profit for the customer.  We explored how HP products could
impact time-to-market in the customer╒s R&D use of the equipment,
and how they could impact time-to-profit in the customer╒s
manufacturing use of the equipment.  We then brainstormed how
reuse could be focused to support this manufacturing customer, and
developed sample reuse requirements (e.g., ╥The test equipment
domain architecture must support optimized throughput in the
customer╒s manufacturing use of the equipment.╙).  Throughout this
analysis, we developed, in parallel, product development and reuse
objectives; appropriate targeted utilizers for the reusable assets;
implications for product capabilities and marketing; and assessed the
appropriateness of our objectives against constraints.

In the domain analysis workshop, we explicitly asked each of the
stakeholders to identify the product line business goals to which
their reuse initiative would contribute.   The responses included
decreased time-to-profit, decreased time-to-market, and improved
inter-product compatibility.  Using the ERMA method, we asked the
group to prioritize the business goals and explore options for which
goals would be used to guide the domain analysis project, as well as
the subsequent domain architecture and asset engineering projects.
We stated the overall reuse goal and the specific domain analysis
goals as a well-formed objectives:
-    The desired outcome is explicitly stated.
-    The attainment of the outcome is observable and assessable.
-    The statement is clearly written and readily understandable by
all stakeholders.
-    The undertaking associated with achieving the objective is
within the charter of the organization.
-    The desired outcome is aligned with the organization's business
goals.
-    The time for achieving the outcome is explicit.1

Stating goals as well-formed objectives has been a very important
and challenging task.  Most organizations are not experienced in
developing well-formed objectives. We have found that most teams
need facilitation in eliciting a statement of the objective in terms of a
desired outcome where progress toward that outcome will be
assessable.

As the next step in the ERMA method at the DA workshop, we
established questions, and then metrics for this project using the
ERMA method (discussed further in the following sections).  At a
management checkpoint for the domain analysis, the project's
objectives were presented in the context of the business goals and
the progress was assessed using the metrics.  This contributed
significantly to the organization's ability to manage their continued
investment in the DA effort.  The use of project objectives aligned
with business goals and focused metrics derived from well-formed
objectives supported the team's efforts to communicate with their
management teams from a business frame of reference.  The project
sponsors supported the reported results and recommendations.

2.2  GQM for Reuse
Another organization was frustrated in managing their investments
in reuse and their approach in communicating the value of their
efforts in developing and delivering reusable assets.  The
organization is a large, central asset production and management
group with teams for developing and evolving assets, as well as
supporting distribution and integration of the assets in products.
Because value is traditionally assessed in this organization by the
success of the HP product in the marketplace, there were no metrics
in place that would assess the value of an organization whose
contribution to products was considered indirect.

We began the reuse metrics adoption process by assisting the
organization in developing well-formed objectives for each project
and for the two departments in which these projects were being
undertaken.  At first, each project team produced a long list of
desired outcomes because they were unaccustomed to prioritizing
and pruning their list of responsibilities.  We used the strategic
business goals and overall organization objectives to prioritize and
trim the list to a critical few objectives.  Then the stakeholders
learned to restate their desired outcomes as well-formed objectives.
Using a synthesis of methods described by Basili and Grady, we
brainstormed sets of questions the group could use to assess progress
toward the objectives.  We then identified two types of questions.
Assessment questions directly inquire about progress toward the
objective.  Understanding questions assist the analyst in
understanding terminology, concepts, and implications for the
objective.  The stakeholders learned to distinguish between
assessment questions (e.g., ╥Is the time (in engineering-months) to
design a product╒s software decreasing with increased use of the
reusable framework?╙) and understanding questions (e.g., ╥What do
we mean by inter-product compatibility?╙).

2.3  Evolutionary GQM
When a sister organization approached metrics adoption, they were
just beginning a reuse initiative.  They were planning the project to
develop and deliver a reusable architecture, then a steady stream of
reusable frameworks scheduled to deliver value to product
development teams with limited resources.  With this group, we
developed a set of goals and then pursued the critical few for which
the stakeholders believed metrics might help them to manage better.
Then we developed one or two critical questions for each goal for
which management help was most needed.

This evolutionary GQM approach is based on the same principles as a
pruned search algorithm [3].  We establish a ╥cost╙ for pursuing a
particular goal, question or metrics; and attempt to get the most
return for implementing a particular metric.  The team established
criteria for pursuing one goal, question or metric over another.
These criteria (in order of priority) included that they would pursue
a path if
1.    The organization has a strong need to manage progress toward
the associated goal.
2.    The information needed to manage progress is not currently
available.
3.    Having answers to the associated assessment question would
significantly improve the organization╒s ability to manage progress
toward the goal.
4.    The cost/benefit of implementing the metric is acceptable to
the organization.

Of the important business goals for which the reuse effort was a
tactic the group identified three critical goals, for which metrics could
contribute substantially to managing progress.  Asking only one or
two key questions about each goal led them to a small set of metrics
that were feasible and would provide the data needed for analysis.
Future phases of evolutionary metrics adoption will employ the same
method to implement and utilize additional metrics.

3  Comparison
Reed [5] has reported on a metrics effort at Digital Equipment
Corporation which is similar in its goal and strategic planning
orientation and in its emphasis on communication as a critical success
factor to metrics adoption.  They do not attribute critical importance
to the cultural and organizational factors which we feel make an
incremental approach to metrics adoption imperative at HP.  Grady
[2] has documented various metrics efforts within HP which used the
GQM paradigm.  This experience base has led us to a more "pruned''
approach to the GQM tree and to a greater emphasis on alignment
with business goals.  May and Zimmer [4] discuss the benefits of
Evolutionary Product Development in managing the risks of software
development.  The method uses small incremental product releases
or builds, frequent delivery of the product to users for feedback, and
dynamic planning that can be modified in response to this feedback.
Successful implementation of this model in many HP organizations
has helped shaped the incremental approach we are using in reuse
metrics.  Basili's [1] Goal-Question-Metric model is the basis for our
approach and has been widely applied with varying results.

References

[1]    Basili, V. & Weiss, D.M. ╥A Methodology for Collecting Valid
Software Engineering Data╙, IEEE Trans. Software Engineering, Vol.
SE-10, no. 3, November 1984, pp. 728-738
[2]    Grady, B. Practical Software Metrics for Project Management
and Process Improvement, Prentice-Hall, 1992.
[3]    Lowerre, B. Pruned Search in Speech Recognition, Ph.D.
Dissertation, Carnegie-Melon University, 1994.
[4]    May, E. and Zimmer, B. Evolutionary Product Development at
Hewlett-Packard, Hewlett-Packard, 1994.
[5]    Reed, J. ╥Software Metrics and Policy Deployment╙, Proceedings
of the Applications of Software Measurement Conference╩, 1994

Biography
Patricia Collins has been at HP 15 years.  She was a speech
recognition researcher in HP Laboratories, then served as project
manager for various software systems and software engineering
environment research projects.  She has been a reuse consultant in
HP's Software Initiative for 4 years.  She holds an MSEE from
Stanford University and a BA in mathematics and philosophy from
Dickinson College.

Barbara Zimmer has been at HP 12 years.  After 6 years as a
financial/business analysis, she moved to R&D to work with the
software process assessment group.  The results of these assessments
of SW development processes in HP R&D laboratories were
instrumental in convincing HP management to launch the Software
Initiative.  Within the SWI, she has focused on technology transfer
and communications activities, including a number of internal
publications of various aspects of software development as well as a
Software Quality and Productivity Guide. Her current work focuses
on working directly with HP R&D group partners on various aspects
of software development.  She has a BA in Communications and MBA
from the University of Washington.

1 The time limit may be stated as occurring before an event, but is
often stated as being accomplished by a specific date or within a
timeframe.

Representing Domain Models Graphically

Margaret (Maggie) J. Davis

Boeing Defense & Space Group
P.O. Box 3999, MS 87-37
Seattle, WA 98124-2499
Tel: [phone]
Fax: [phone]
Email: [e-mail]

Abstract

Transitioning domain analysis to experienced systems and software
engineers would be eased by the availability of automation supporting
graphical modeling. Further,it would be even more useful if the domain
modeling seemed to be an extension to the graphical modeling the
engineers are already performing. Commercial support
(ObjectMaker,PTech) does exist for customizing a graphical modeling tool
but it is either relatively expensive to license or takes a considerable
amount of additional code. The approach taken was to put together
NASA's CLIPS and Motif in a prototype that would be suitable for
experiments integrating domain analys is with different
graphical modeling methods.

Keywords: Reuse, Domain Analysis, Graphical Representation

Workshop Goals: Learning; networking; gathering information on
successful reuse technology transitions

Working Groups: reuse process models; reuse technology transition; and
management; reuse and OO methods and technology

1   Background

Ms. Margaret (Maggie) J. Davis is the technical lead for reuse on the
Boeing STARS project, which is sponsored by ARPA under USAF contract.
Ms. Davis has served in a lead capacity on the Boeing STARSproject since
its award in 1988. Maggie is also principal investigator for a Boeing
internal research and development project promoting domain-specific
reuse awareness within the company and experimenting with
graphicalrepresentations of domain analysis models. World Wide Web
technology is being used to promote reuse awareness by providing a
forum for user questions as well as an information resource. Facilities of
NASA's CLIPSexpert systems shell and Motif are being used to create a
family of tools for graphical representation of domain models. This
family will in turn be used as the base for domain graphical modeling
trials by Boeing projects.

2   Position

2.1  Problem Description

In my experience so far,transitioning of domain analysis concepts and
techniques to experienced software or systems engineers proceeds more
smoothly if the "process" already in use is augmented rather than
replaced. These "processes" are sometimes collections of analysis and
modeling techniques known to be useful in the particular application
area of the team or sometimes are commercially-available end-to-end
software development methodologies such as P+.

Quite often these processes rely on graphical representations to
communicate results and concepts to other team members,
management, and customers. The learning curve for domain analysis
can be less steep if a way can be found to augment a team's familiar
graphical representations to include the necessary information for
domain modeling.At a minimum, differentiating commonality from
variability is required.

If a team is already performing analyses closely related to semantic
modeling, KAPTUR can be used. In the embedded software milieu of most
of Boeing's business,this is not the case. More often, entity-relationship
models, data flow, control flow, stimulus-response networks , or
architectural structures are depicted. Some teams or groups have
adopted (and adapted to their needs) object-oriented analysis methods
such as Rumbaugh or Coad defines.  Such groups are more open to
domain analysis because they have been become familiar with the is-a
concept. However,all these object-oriented analysis techniques promote
unique graphical representations,no one of which seems to include
depicting commonality versus variability explicitly.

Of the graphical models that can be encountered, software architecture
representations pose a particularly knotty problem. Unlike electronic
design, there is no standard symbology nor even a few competing defacto
standards. Worse, architecture graphical models are often created as
diagrams using whatever drawing package was at hand. The semantics
associated with each symbol shape can vary within the diagram or
across a series of diagrams that make a complete model.

As a technologist attempting to intro duce domain analysis and
modeling concepts into a group or team's way of working, it would be
extremely useful to have at one's fingertips a graphical modeling
program that worked either on a Unixor a PC platform and that
supported customization for different methods or techniques. This
customization would address three areas:

Symbol presentation characteristics,

Data attributes associated with each symbol,

Methodology semantics.

2.1.1 Symbol presentation characteristics

The symbol presentation semantics cover visual characteristics assigned
to each methodology concept to be depicted:

shape such as rectangle, oval, diamonds, lines;

style such as line thickness or fill;

size such as height and width;

whether a user-entered text string should be displayed with a symbol
instance;

whether a symbol instance can be resized by the user; and

whether a symbol instance can be reshaped such as from a square to a
rectangle.

2.1.2 Data attributes associated with each symbol

To elevate the tool from a mere drawing package to supporting graphical
modeling, it is necessary to have the ability to associate data attributes
with each symbol instance. For instance, if a symbol represented an
abstract data type, itwould be useful to associate with that symbol
dynamic characteristics such as timing and sizing expressions that could
be used in subsequent simulations predicting performance.

Besides assigning a label for prompting the user for entry of a value for
an attribute, it may also be useful to designate:

whether the user must supply a value or not;

what is the type of the attribute (text, integer, float, ...);

a range of legal values; and

a default value.

2.1.3 Methodology semantics

Methodology semantics cover checking validity of data item values at
instance creation or update, checking the validity of instance deletion,
and a set of modeling characteristics that are manifested through user
interaction with the tool.These user interaction semantics cover details
such as:

whether symbol instances can be parents of other diagrams;

whether symbols can contain, overlap, or touch other symbols; and

whether symbols must be connected to other symbols.

2.2  Approach Being Used

Commercial tools (e.g., ObjectMaker, PTech) are available that support
certain customization characteristics listed above. When licensed to
permit customization, either their cost is high or customization is a long
and involved process.  Thus, the decision was made to bring together
NASA's CLIPS with MOTIF/X Windows to create prototype suitable for
experimentation with various graphical model representations.

CLIPS is an embeddable expert system shell that provides an inference
engine and an object language. Using CLIPS thus provides an opportunity
to save individual models in  files that can be subsequently manipulated
or analyzed by other CLIPS applications. CLIPS is a lso available for Unix,
MacIntosh, and PC platforms.

MOTIF/X Windows may not have been the best choice - it was what was
at hand. It does make it possible to provide the drawing and data entry
capabilities familiar to software engineers.

2.3  Major lessons learned so far

Motif programming is tedious. Implementing dialog boxes, menus, and
buttons with Motif widgets is a fairly straightforward data definition
task. There is a large amount of detail to keep consistent. GUI builders
can help manage the detail. Neither GUI builders nor application
definition languages provide any assistance in implementing the
drawing area. Implementation of drawing, selection, sizing, shaping,
andplacement of symbols requires copious amounts of code and
knowledge of two-dimensional geometry.

Customization takes copious amounts of data. For each symbol defined,
it is necessary to provide 16 to 64 separate customization decisions.
These decisions are coded into CLIPS objects and used by the tool
framework to dynamically configure an instance of the tool family. To
simplify the customization activity that a technologist would have to
perform, a generator was constructedusing the KAMEL tool created under
the Boeing STARS project. This application of KAMEL queries the
technologist for the customization decisions for each symbol, queries the
technologist for the customization decisions that involve more than one
symbol (connection, containment, ...), and then generates from those
decisions the symbol customizations as CLIPS objects.The KAMEL
application took about 16 hours to construct where the majority of the
work involved writing the generator function. The effort was worthwhile
since it ensures all the keywords are correct and the methodology-unique
data is consistently applied. The KAMEL application also made it easier
to specify the customizations that cross symbols. All of these had been
problems when customization files were hand crafted.

Buy rather than build if at all reasonable. It has been an interesting
learning experience to discover what it means to support data-driven
customization of a graphical modeling tool frame-work. But, that effort
has consumed more resource than was expected.

3   Biography

Maggie Davis is Reuse Technology Area Lead for the Boeing
STARSprogram, participating in joint STARS activities and leading the
Boeing-specific reuse technology development.  Maggie is also principal
investigator on a Boeing internal research and development project
promoting reuse and transitioning reuse technology. Other Boeing
applied research projects Maggie has participated in include applying
object-oriented and knowledge-based techniques to the problem of
system integration testing, using graphical user interfaces to support
timing and sizing analyses, and authoring a guidebook for the Air Force
on software specification techniques. Prior to her Boeing career, Maggie
worked as a scientific and systems programmer. Maggie holds a M.S. in
Computer Science from the University of Delaware.

Measuring the benefits of Software Reuse

Prem Devanbu and Sakke Karstu

Software and Systems Research Laboratory
AT&T Bell Lab oratories
Murray Hill, NJ 07974 USA
Email: prem,[e-mail]

Abstract

How much can be saved by using existing software components when
developing software? With the increasing adoption of reuse methods and
technologies,this question becomes critical.  However, accounting for the
actual cost savings due to reuse may be difficult. It would be desirable to
measure the savings indirectly by analyzing the code for reuse of
components. The central focus of our work is the development of some
properties that (we believe) should hold of any reasonable measure of
reuse benefit. We explore the relationship between several existing
approaches to reuse measurement and these properties. We have
developed an "expanded source" measure as an indirect measure for
reuse benefit, and evaluate it theoretically, using our properties; we have
also built tools to gatherour measures and the previously proposed ones,
and done some preliminary empirical work using some public domain
windowing software.

Keywords: metrics, indirect, axioms

Workshop Goals: Learning; networking.

Working Groups:reuse process models, reuse education, application
generators.

1   Background

As reuse efforts mature,it is very important to demonstrate to
management and funding agencies that reuse makes good business sense;
to this end, it is necessary to have methods to gather and furnish clear
financial evidence of the benefits of reuse in real projects. Thus, we need
to define good metrics that capture these benefits.


We can think of reuse benefit of a project or system, as being the
normalized (percentage) financial gain due to reuse. This is an example
of an external process attribute (see [1]),concerned with an external
input (money) into the software development process. Unfortunately,the
direct measurement of the actual financial impact of reuse in a system
can be difficult. There are different types of reuse - reuse of
specifications, of design, and code.  Specification and design processes
often have informal products (such as natural language documents)
which can be quite incommensurate. Even in reuse of code, there are
different modus operandi, from the primitive "cut, shred, and paste",
to the formal, controlled language based approaches provided in
languages such as C++. In any case, to determine cost savings, one may
have to ask individual developers to estimate the financial benefit of the
code that they reused. This information may be unreliable and
inconsistent.

There has been a body of work in the area that addresses this issue: a
variety of methods for measuring the degree of reuse in a system have
been proposed [2, 3, 4, 5, 6].

2   Position

Fortunately,one of the key approaches to reuse is the use of features such
as functions and modules in modern programming languages. In this
context, one can find evidence of (some kinds of) reuse directly in the
code; thus, it may be possible to find an indirect measure of the benefits
of software (code) reuse directly in the code. Measures derivable directly
from the code are internal measures; this paper, then, is concerned with
the problem of finding an indirect, internal measure, in the code of a
system, of an external process attribute, namely, reuse benefit. Following
Weyuker [7] in the field of complexity measures, we develop some
general properties or axioms that (we argue) should apply to any
measure of reuse benefit. Although (for reasons discussed above) it is
difficult to develop a direct, external measure of reuse benefit, these
axioms give us a yardstick to evaluate candidate internal measures.

Fenton [1] categorizes software measures along two orthogonal axes. The
first is the process/product axis: a metric may measure an attribute of
software product, (e.g., quality of code), or an attribute of software
process (e.g., cost of design review meetings). Another, orthogonal axis is
the internal/external axis. A metric may measure an internal attribute
(e.g., the number of loops in a module), or an external attribute (e.g.,
maintainability of a module). Our goal is to develop a reasonable way of
measuring the actual financial impact of reusing software. By Fenton's
categorization, this is an external process attribute.  We would like to
measure reuse benefit as a normalized (we shall explain later why we
choose to normalize) measure of the degree of cost savings achieved by
adopting software reuse. Thus, we define Rb, the reuse benefit of a system
S, as follows:

                           cost-of-developing-S-without-euse  -
(1) Rb(S) =                                        cost-of-developing-S-with-reuse
                          ---------------------------------------------------------------------------------
                                            cost of S without reuse

It can often be difficult to get a reasonable direct measure of Rb. In cases
like this, software metricians have used indirect measures. For example,
the external process attribute of maintainability is often measured
indirectly1by internal product measures of complexity such as
cyclomatic complexity. Likewise,the internal product measure of software
size (in units of NCSL) is considered be a reasonable indirect measure of
the external process attribute of maintenance cost. Following this
approach, we are concerned with the development of an indirect
internal measurement of Rb, the normalized reuse benefit of a system
S,from the product, by searching the source code of S for instances of
language-based reuse such as subroutine calls. The desire for an indirect
benefit is one reason we choose a normalized measure. The relationship
of the actual benefit to the source code may be much more
implementation dependent than the normalized benefit: the actual cost
of each line of code is likely to depend much more on the project than
the relative cost for each line of code.

With such an indirect measure,there is a risk that we are not really
measuring what we seek to measure; we would therefore like to validate
our indirect measure in some way.  One approach to validating indirect
measures is to perform empirical studies.  Aparallel (or prior) approach,
proposed by Weyuker [7] and others is to enumerate some formal
properties that should hold of any measure (direct or indirect) of the
attribute in question. Weyuker used this approach to evaluate several
internal measures of complexity.  Of course, we are using this approach
differently than Weyuker: she "axiomatized2" properties of a complexity
internal measure,and evaluated several internal complexity measures
againstthese properties. We are seeking to "axiomatize" an external
measure_reuse benefit_and use these "axioms" to evaluate and develop
indirect internal measures of reuse benefit. In addition, measuring reuse
benefit is quite different from measuring complexity; thus many of her
axioms aren't relevant in our context. However,her Property 4
(implementation dependence) is critically important in measuring reuse,
and in fact, we reformulate and strengthen Property 4 in several ways
applicable specially to measures of reuse benefit. In the full paper, we
present a set of 10 axioms that formalize desirable properties of internal
metrics that seek to indirectly measure reuse benefit.

3   Related Work

There are many models and metrics is the literature that try to evaluate
the relative benefit achieved by reuse in a software system. In the full
paper, we describe 2 main types of measures: the producer-consumer
models of [8, 9, 10, 3, 6],and the reuse level measures of Frakes and Terry
[2]. The former category gives weight to the actual size (NCSL) of the
reused portion of the system. The latter suggests a reuse requency
measure that gives weight to the number of times a component is used
or reused. Both these measureshave been used in actual systems, and
theresults have been reported by the authors. The axioms we report in
[11] are applicable to both these measures,although in the case of [9]
(and in [2]) some system-specific interpretations may be needed, since
Poulin's measures involve some subjective accounting (Poulin, however
gives detailed guidance on the accounting to minimize variance). Our
properties serve as a formal framework in which these different measures
can be compared. In [11], we undertake such a comparison, and propose
a new measure that combines attractive elements from both these
categories.

Indirect measures are also used often in the physical and social sciences.
For example the attribute of temperature is measured indirectly by the
length of a mercury column in a thermometer.  We use the quotation
marks here because these are not necessarily axioms in the formal
mathematical sense, but rather a list of properties that would appear to
most people to hold of the measures in question.

4   Conclusion

This paper is concerned with the indirect measurement of the benefit of
software reuse by observing reuse occurrences in code. We have proposed
a set of desirable properties of reuse benefit measures. In the full paper
[11], we fully describe and justify these properties; we evaluate existing
measures with respect to these properties;we propose a new measure of
software reuse, which conforms more closely to our proposed properties;
we also identify some basic difficulties in measuring reuse benefit that
appear to be intractable. In addition to this theoretical evaluation,we
have constructed the tool infrastructure to gather data on our measures
and the other measures suggested in the literature by direct analysis of
ANSI C and C++ systems.We have done a pilot study using some public-
domain windowing software.We are currently pursuing cross-validation
of these internal metrics data with external process attributes. This
validation should shed some light on the appropriateness of our
axiomatization.

References

 [1]N. E. Fenton, Software Metrics: A Rigorous Approach. Chapman &
Hall, 1991.

 [2]W. Frakes and C. Terry, "Reuse level metrics," in Third International
Conference on Software Reuse, pp. 139-148, 1994.

 [3]J. J. E. Gaffney and Cruickshank, "Economic impact of software
reuse," in Fourteenth Inter-national Conference on Software Engineering,
IEEE Press, 1992.

 [4]J. Poulin,"Survey of approaches to reusability metrics," Tech. Rep. 14
March, Federal Systems Company IBM, 1994.


 [5]J. Poulin,"Measuring software reusability,"in Third International
Conference on Software Reuse, pp. 126-138, 1994.

 [6]Y.-F. Chen andB. K. a= nd Kiem-Phong Vo, "An Objective Reuse Metric:
Model   and Methodology," in Fifth European Software Engineering
Conference, 1995.

 [7]E. J. Weyuker, "Evaluating software complexity metrics," IEEE
Transacations on Software Engineering, vol. 14, no. 9, pp. 1357-1365,
1988.

 [8]T. Bollinger and S. Pfleeger, "Economics of reuse: issues and
alternatives, " Information and SoftwareTechnology, vol. 32,no. 10, pp.
643-652, 1990.

 [9]J. Poulin,J. Caruso, and D. Hancock, "The business case for software
reuse," IBM Systems Journal, vol. 32, no. 4, pp. 567-594, 1993.

[10]J. J. E. Gaffney and T. A. Durek, "Software reuse - key to enhanced
productivity: some quantitative models,"Information and Software
Technology, vol.31, no. 5, pp. 258-267, 1989.

[11]P.Devanbu and S. Karstu, "Measuring the benefits of software reuse,"
tech. rep., AT&TBell Laboratories, 1994.

5   Biography

Premkumar T. Devanbu is a member of the Software and Systems
Research Laboratory at AT&T Bell Laboratories in Murray Hill, New Jersey.
He is the creator of the GENOA/GENII system, which was used to
implement GEN++, the first widely distributed meta-analysis tool for C++
programs. His research interests include static analysis, reverse
engineering, application generators, dynamic analysis, applications of AI
to software engineering and software tools.  He received a Ph.D. in
Computer Science from Rutgers University in 1994.

Sakke Karstu is a member of the Center for Experimental Computation at
Michigan Technological University in Houghton,Michigan. He has
developed several tools with GEN++, including a reuse analyzer used in
this research and a static slicer, which is used to calculate slice based
cohesion measures. His research interests include software metrics and
their utilization in commercial software development. He received a MS
in computer science from Michigan Technological University in 1994.

A Case Study of Software Architecture Life Cycle Processes

David Dikel, Carol Terry, David Kane, Bill Loftus

Applied Expertise
1925 North Lynn Street
Suite 802
Arlington, VA 22209
Tel: [phone]
Email:[e-mail], [e-mail]
[e-mail],[e-mail]


Abstract

A growing number of technologists believe that an architecture-based
approach to software development can enable smaller teams to build
better products faster and maintain those products more effectively.
However, growing experience indicates that the primary problems to
evolving and maintaining a long-standing architecture are
organizational, not technical. Applied Expertise will conduct a case study
of Bell Northern Research's Transmission System's architecture to learn
how the organizational challenges of maintaining a software architecture
once fielded were overcome.

Keywords: architecture, product-line, organizational processes, case study

Workshop Goals: learning; networking; receiving feedback and input on
our case study.

Working Groups:reuse management, organization and economics.

1   Background

The Applied Expertise team has long-standing experience with software
reuse. Dave Dikel's 1987 case studies of commercial Ada use identified
reuse as a key driver for adopting Ada. [1] Since then, Dikel has
developed and worked with customers to implement reuse-related
operating concepts, strategies and plans for NASA, Department of Defense
and Fortune 500 clients. For example, Dikel drafted key elements of
DOD's plan for its Software Reuse Initiative (SRI), submitted to Congress
in April 1994. Dikel led a case study for the ARPA Software Technology
for Adaptable,Reliable Systems (STARS) focusing on software reuse criteria
within Bell Canada's Trillium capability model. Later AE's team,
including Carol Terry, Dave Kane and Dikel, captured and applied Bell
Canada's use of Trillium to manage risks related to software reuse.
Terryhas also published widely on software reuse metrics. Sponsored by
NASA, Dikel and Terry, both help to lead the Reuse Library
Interoperability Group (RIG), Terry as Vice Chair of TC6 and Dikel,as Vice
Chair of the Executive Board. Kanemanages the RIG Secretariat for STARS.
Kane has also performed domaim analysis for information systems.

Since the mid 80's William Loftus has also maintained an important role
in DoD's STARSprogram.  As an AE Senior Associate, Loftus helped
developed a software reuse strategy for a major Wall Street firm. Mr.
Loftus recently completed a major software re-engineering project for a
Fortune 500 firm, on time and below budget, leveraging software reuse
and object oriented programming technologies. Terry manages AE's
support to DoD's Interoperability Vision Working Group for SRI. Under
this contract, Loftus and Terry lead the design of a technical reference
model and concept of operations for reuse library interoperability for the
DoD Software Reuse Initiative.

2   Position

2.1  Problem

Architecture-based software development is an emerging technology. [2]
A growing number of technologists believe that an architecture approach
can enable smaller teams to build better products faster and maintain
those products more effectively. There is a growing body of knowledge
about how to design and build a software or systems architecture, as
evidenced in programs such as the Software Technology for Adaptable,
Reliable Systems (STARS). The STARS program has developed and
increased the maturity,visibility and viability of architecture-based
software engineering technology.

Growing experience indicates that the primary problem in
implementing, evolving and maintaining a long-standing architecture is
often organizational, not technical. [3]  Introducing an architecture-
based approach and achieving product-line reuse can require an
organization to make major changes that affect not only technology, but
its very management structure. Even though the perceived benefits of
this technology are great,the risk of moving to this technology is also
perceived as high for both managers and for the technology champions
who are driving the effort.

There are few case-studies that providedirections to use, re-use, maintain
and terminate these architectures. As a result, the organizational
problems, issues, and solutions that can be learned from the long-term
users of a software architecture are not widely known. For these and
other reasons, it is important that these long-term software architectures
be studied to learn how these organizational challenges can be overcome.

2.2  Our Work

Applied Expertise (AE) is conducting a case study to uncover the key
organizational elements in successfully evolving a product-line
architecture.  This work builds on a 1993 case study of Bell Canada's
Trillium that identified several examples of long-term, successful
software architectures within the telecommunications industry.  One
such example is Bell Northern Research (BNR) Switching Systems'
evergreen architecture. First fielded in 1975,the architecture adapted to
vast technological changes,and was used to build a range of products
from simple office switches to toll switches that serve entire countries.

AE's study will inspect BNR's Transmission product-line architecture. The
study team will develop a focused set of hypotheses from the work
ofGrady Booch, the Software Engineering Institute (SEI) and
others,consisting of the key elements necessary for successfully evolving
along-term product-line architecture. For example, one hypothesis might
be:

Successfully evolving a product-line architecture requires a ruthless focus
on simplification, clarification and minimalization. [4]

To provide depth, we plan to involve the intended audience for our
products in the design and review of the initial study by forming an
advisory group. This will increase the efficiency of our research and the
impact of the products. The advisory group includes stakeholders in
industry and government who have a strong interest and/or experience
base in using an architecture-based approach to developing software.
The group will review the initial hypotheses for the study,and will also
collaboratively review and discuss the findings of the study.

3   Comparison

Most current software architecture research efforts focus on defining and
building an architecture and the skills and tools necessary for
implementation. The Domain Specfic Software Architecture (DSSA) is a
good example ofsuch an approach. A major thrust of this effort is to use
software architectures to create applications inan automated fashion. [5]

There is a growing amount of anecdotal evidence that organizational
issues are a major obstacle to the institutionalization of softwarereuse.
There is some work that addresses these factors,including Grady Booch's
forthcoming book, Object Solutions: Managing the Object Oriented
Project. [4] However, we have found few formal case studies covering the
topic. Further,while Booch addresses software architectures in some
depth, the primary focus of his work is object-oriented project
management.

Our approach will establish new ground by investigating the
organizational issues surrounding the software architecture life-cyclewith
more structure and rigor than has been done previously.

References

[1]D. Dikel,"Tracking the use of ada in commercial applications," Tech.
Rep. 387-001-001,Ad-damax Corporation, 1987.

[2]D. E. Perry and A. L. Wolf, "Foundations for the study of software
architecture," ACMSIG-SOFT, October 1992.

[3]P. Collins,"Software reuse at hewlett-packard," 1995.

[4]G. Booch, Object Solutions: Managing the Object-Oriented Project.
unpublished, 1995.

[5]W. H. Christine Braun and T. Ruegsegger, "Domain specific software
architectures - commands and control," 1993.

4   Biography

Dave Dikel is Vice President and director of research at Applied
Expertise.He currently directs work for DoD, NASA, and industry, focusing
on software reuse, software risk management and technology transition,
including projects for the Advanced Research Projects Agency, NASA, Loral
and Hewlett-Packard. Mr. Dikel led a landmark study of Bell-Canada's
Trillium software capability model. Mr. Dikel earned international
distinction for his work in sizing and analyzing the Ada market and for
his case studies of Ada,and other emerging technologies. He founded the
ACM SIGAda Commercial Ada Users Working Group. Mr. Dikel earned a
bachelor's degree in philosophy and physical sciences at the University
of California, San Diego.

Carol Terry is a Research Engineer at Applied Expertise, Inc. where she
leads software engineering research and policy analysis for customers in
government and industry. Her current research areas are software reuse
and architecture-based development, technology transfer,and software
risk management. Ms. Terry has a master's degree in information
systems with a concentration in software engineering from Virginia
Polytechnic Institute and State University, where she achieved
distinction for research in software reuse and metrics.

David Kane isa Software Engineer at Applied Expertise. He has developed
information systems for a variety of government organizations, and has
created an innovative technology transfer workshop for Hewlett-Packard.
His research interests include risk management and software process
improvement for small organizations.  Mr.  Kane has a bachelor's degree
in computer science - mathematics from the State University of New York
at Binghamton.

William Loftus is an Applied Expertise Senior Associate. Mr. Loftus
performs major systems design, development and software reuse
assessment work for Applied Expertise. Mr.Loftus is a certified Sun
Microsystems consultant.He has given many seminars and presentations
on advanced software technology and has been published in a number of
journals. At Unisys,Mr. Loftus received several awards and
commendations for his contributions to the Unisys advance software
program and the DoDAda Command Environment (ACE). He earned a
bachelor EDs degree and a master's degree in computer science from
Villanova University.
Good Mental Models are Necessaryfor Understandable Software

Stephen H. Edwards

Dept. of Computer and Information Science
The Ohio State University
395 DreeseLab
2015 Neil Avenue
Columbus, Ohio 43210-1277
Tel: [phone]
Email:[e-mail]
URL: http://www.cis.ohio-state.edu/edwards

Abstract

People form internal mental models of the things they interact with in
order to understand those interactions. This psychological insight has
been used by the human-computer interaction (HCI) community to
build computer systems that are more intuitive for end users, but it has
not yet been applied to the problems of software designers, programmers,
and maintainers. In fact, conventional programming languages do little
to help client programmers develop good mental models of software
subsystems. The main problem is that the conventional wisdom that
software modules are merely a syn-tactic mechanism for organizing
declarations and controlling visibility is wrong. This skewed view of the
nature of software modules limits their utility as effective building-blocks
for creating large, complex software systemsthat are comprehensible to
human readers. To constitute effective building-blocks,modules must
present simple mental models to the softwa reprofessionals involved in
assembling them into larger modules,and ultimately into complete
software systems. Because a module has no real semantic denotation of
its own, there is no way for one to imagine such building-blocks as
contributing to the understandability of the software comprising them.

Keywords: Mental model, module, programming language,
understandability

Workshop Goals: Cross-fertilization of ideas with other researchers;
building on the results of WISR6; keeping abreast of other on going reuse
work; advancing the theoretical foundations of software reuse.

Working Groups: reuse and formal methods, design guidelines for reuse,
reuse and OO meth-ods, component certification.

1   Background

The Reusable Software Research Group at the Ohio State University has
been exploring the technical problems of software reuse for the past
several years, focusing on a disciplined approach to software engineering
as a possible solution. The key goal of ensuring that this discipline of
software construction will scale up to large systems has led the RSRG to
center on the concept of supporting modular reasoning or local
certifiability at the component level [1, 2,3].  In short, the client of a
reusable component or subsystem should only have to consider a
bounded amount of information (i.e., local, rather than global) when
reasoning about whether that component is the correct one to choose,
and whether it is being used correctly. A specific software discipline that
ensures that all components have this property is described by
Hollingsworth [4].

In addition to the requirement for local certifiability from a technical
perspective, however, good reusable software must also support effective
(and modular) human understanding from a psycho-logical perspective.
This position paper claims that current programming languages do not
offer any support for human understanding of programs. This claim is
further developed elsewhere by Edwards [5], where a proposed solution is
also detailed.

2   Position

In interacting with the environment, with others, and with the artifacts
of technology, people form internal, mental models of themselves and
ofthe things with which they are interacting. These models provide
predictive and explanatory power for understanding the interaction.
These statements hardly need be said, for they are consistent with all
that we have learned about cognitive processes and,within [the book
Readings in Human-Computer Interaction], represent the major
underlying conceptual theme. Nonetheless, it does not hurt to repeat
them and amplify them,for the scope of the implications of this view is
larger than one might think.
       - Donald Norman [6, p. 241]

As Donald Norman indicates, the human-computer interaction (HCI)
community has benefited from exploring the implications of mental
models. This perspective has aided their ability to create more usable,
understandable user interfaces for computer programs, as exemplified by
the popular "desk top" metaphor.

Researchers also have used the concept of mental models to examine
how programmers design new software [7][8][9] and understand existing
software [10][11]. The next logical step,as it was for the HCI community,
is to ask how focusing on mental models can help us create software that
is more usable and understandable to programmers. This is particularly
important in the coming age of "software reuse, "where software parts
will be written with the goal of being utilized by different programmers
in quite disparate contexts.  Unfortunately,asking questions about how
programming languages support the formation of effective mental
models leads one to conclude that conventional programming languages
are inadequate for constructing large, sophisticated software systems that
are "understandable."

2.1  Why Conventional Languages Fail

In short, modern programming languages have evolved from their
predecessors with the primary purpose of describing instructions to
computers.  They were never designed to help explain to people the
meaning of the software that they can describe. This has led to two
critical problems with programming languages today: modules are
considered to be purely syntactic constructs with no independent
meaning,and those parts of programs that are deemed meaningful
(usually procedures, in imperative languages) have a "hierarchically
constructed" meaning.

First,most modern programming languages have some construct that is
intended to be the primary "building-block" of complex programs. This
building-block may be called a "module,"a "package," a "structure," or a
"class." Unfortunately, these constructs are rarely given meaningful
semantic denotations. Conventional wisdom in the computer science
field indicates that these constructs are primarily for grouping related
definitions, controlling visibility, and enforcing information hiding.
For example, when speaking of module-structured languages like Ada or
Modula-2, Bertrand Meyer states:

In such languages, the module is purely a syntactic construct, used to
group logically related program elements; but it is not itself a
meaningful program element, such as a type, a variable or a procedure,
with its own semantic denotation.[12, p. 61]

In this view, there is no way forone to make such building-blocks
contribute directly to the understandability of the software comprising
them. While object-oriented languages usually give a stronger meaning to
the notion of a "class,"they also fail to provide any vision of how the
meaning of individual classes can contribute to a broader understanding
of the software systems in which they are embedded.

Second, those program elements that are given a real semantic
denotation are often given a meaning that is "hierarchically
constructed,"or synthesized. In other words, the meaning of a particular
program construct, say a procedure, is defined directly in terms of its
implementation_a procedure "means" what the sequence of statements
implementing it "means." The meaning of its implementation is defined
in terms of the meanings of the lower-level procedures that it calls. Thus,
a procedure's meaning is "constructed" from the meanings of the lower-
level program units it depends on,and the meanings of those lower-level
units in turn depend on how they are implemented,
and so on.

This simple synthesis notion of how meaning is defined bottom-up is
adequate from a purely technical perspective. It is also very effective
when it comes to describing the semantics of layered programming
constructs. Unfortunately, it is at odds with the way human beings form
their mental representations of the meaning of software parts [5].

The result of these two features of programming languages is that they
are inadequate for effectively communicating the meaning of a software
building-block to people (programmers, in particular). The semantic
denotations of programming constructs in current languages only relate
to how a program operates. They fail to capture what a program is
intended to do at an abstract level, or why the given implementation
exhibits that particular abstract behavior. In order to address these
concerns, it is necessary to assign meaning to software building-blocks, to
separatethe abstract description of a software part's intended behavior
from its implementation,and to provide a mechanism for explaining
why the implementation of the part achieves behavior consistent with
that abstract description.

2.2  Why Comments Alone are not Enough

When trying to provide simple mental models for software components,
the question ofthe effectiveness of comments arises. Thorough
commenting of a component interface can allow a software designer to
document the conceptual model of the part and pass this model on to
other professionals using that part. In addition to the possibility of
informal written descriptions of conceptual models, comments also
allowthe inclusion of formally defined behavioral specifications. Entire
specification languages, such as ANNA [13], have been designed to
support complete or partial formal specifications via structured
comments.

Unfortunately, this is really only enough to capture (most often,
informally) the external behavior advertised in a component's
specification.To truly embrace the perspective instigated by mental
models, one must also provide support for forming mental models of the
implementation of a software component, how that implementation
works, and why it gives rise to the abstract description in its
specification. Software implementations typically rely on more
information to operate correctly than is represented in the source code
alone in a conventional language [14, pp 70-74][15, pp. 47-48]. Consider
an abstract data type, where an implementation level "representation
invariant" or its equivalent is proposed to capture some of this
information. This,in addition to a model of the representation of the
exported data type and behavioral descriptions of all internally declared
operations, makes up a maintainer's mental model of a component
implementation.

Further, however, one must also account for the maintainer's mental
model of why that implementation conforms to its specification - the
basis for explaining why the behavior of the inner, more detailed mental
model can be interpreted as being consistent with that predicted from
the specification's more abstractly described cover story. This
information is usually associated with an "abstraction function,"
"abstract relation," or "type correspondence" that explains the
relationship between the representation of a given data type and its
abstract specification. Similar information must be recorded about the
relationship between module-level state variables in the
implementation and those visible in the specification.

Certainly it is possible to lay out a comprehensive plan for how to
document all of this information via structured,formal or informal
comments. Once all of this information is captured in the software
component itself, it is even possible to start asking questions about
whether the component is being used correctly:

Does this implementation actually conform to that specification?

From the client's point of view,is she using the given component
"correctly" (i.e., in accordance with its professed abstract model)?

Will a proposed maintenance change introduce new defects by violating
the expectations of the remainder of the implementation, asexpressed in
the representation invariant(s)? Will it invalidate the reasons why the
implementation currently conforms to the specification?

Unfortunately, to lay out this comprehensive commenting plan, one
mustgo to a great deal of trouble to provide a firm foundation for it.
Indeed, one must understand all of the information that must be
represented, and have a firm grasp of the theoretical underpinnings of
how valid answers to questions like those above are generated. In doing
this, the researcher steps far beyond the idea
of "simply commenting the code," and runs head on into the same
problem of how to (formally) address support for mental models in a
meaningful way.

2.3  Correcting the Deficiency

The ACTI model proposed by Edwards [5] is centered around the notion
of a "software subsystem," a generalization of the idea of a module or a
class that serves as the building-block from which software is
constructed. A subsystem can vary in grain size from a single module up
to a large scale generic architecture.  ACTI is designed specifically to
capture the larger meaning of a software subsystem in a way that
contributes to human understanding, not just the information necessary
to create a computer-based implementation of its behavior.

ACTI is not a programming language, however. It is a formal, theoretical
model of the structure and meaning of software subsystems. It has two
features that specifically address the inadequacies of conventional
languages:

1. In ACTI, software subsystems (building-blocks) have an intrinsic
meaning; they are not just syntactic constructs used for grouping
declarations and controlling visibility. This meaning encompasses an
abstract behavioral description of all the visible entities within a
subsystem.

2.The meaning of a software subsystem is not, in general, hierarchically
constructed. In fact, it is completely independent of all the alternative
implementations of the subsystem.

Thus, ACTI provides a mechanism for describing what a subsystem does,
not just how it is implemented. The meaning provided for a subsystem
is a true abstraction - a "cover story" that describes behavior at a level
appropriate for human understanding without explaining how the
subsystem is implemented. Further, ACTI provides a formally defined
mechanism, called an interpretation mapping, that captures the
explanation of why an implementation of a subsystem will give rise to
the more abstractly described behavior that comprises the meaning
attributed to the subsystem - in short, an explanation for why the cover
story works.

3   Comparison

Edwards [5] presents a thorough comparison of several programming
languages that are representative of best current practices: RESOLVE [16,
1],OBJ [17], Standard ML [18],and Eiffel [12]. As typical of current efforts,
most of these languages do little to support the formation or
maintenance of effective mental models of software parts. The complete
analysis, including a detailed check list of software structuring and
composition properties supported by some or all of these languages,
is available electronically [5]. Other efforts to provide better support for
mental models has concentrated primarily on adding (possibly
structured) comments to component specifications, the inadequacy of
which is described in Section2.2.

References

 [1]B. W. Weide, W. F. Ogden, and S. H. Zweben, "Reusable
softwarecomponents," in Advances in Computers (M. C. Yovits, ed.), vol.
33, pp.1-65, Academic Press, 1991.

 [2]B. W. Weide and J. E. Hollingsworth, "Scalability of reuse technology
to large systems requires local certifiability," in Proceedings of the Fifth
Annual Workshop on Software Reuse, October 1992.

 [3]B. W. Weide, W. D. Heym, and W. F. Ogden, "Procedure calls and local
certifiability of component correctness," in Proceedings of the Sixth
Annual Workshop on Software Reuse (L. Latour, ed.), Nov. 1993.

 [4]J.Hollingsworth, Software Component Design-for-Reuse: A Language
Independent Discipline Applied to Ada.  PhD thesis, Dept. of Computer
and Information Science, The Ohio State University, Columbus, OH, 1992.

 [5]S. Edwards, A Formal  Model  of  Software  Subsystems.  PhD  thesis,
Dept. of  Computer  and  Information  Science,  The  Ohio  State
University,  Columbus, OH,  1995. Also  available  as  technical  report
OSU-CISRC-4/95-TR14, by  anonymous FTP from ftp://ftp.cis.ohio-
state.edu/pub/tech-report/1995/TR14-DIR,  or  through  the  author's
home page.

 [6]D. A. Norman, "Some observations on mental models," in Readings In
Human-Computer Interaction: A Multidisciplinary Approach (R. M.
Baecker and W. A. S. Buxton, eds.), pp.241-244, San Mateo,CA: Morgan
Kaufmann Publishers, Inc., 1987.

 [7]R. Guindon, H.Krasner, and B. Curtis, "Breakdowns and processes
during the early activities of software design by professionals," in
Empirical Studies of Programmers (E . Soloway and S. Iyengar,eds.), pp.
65-82, Ablex, 1985.

 [8]D. B. Walz, J. J. Elam, H. Krasner, and B. Curtis, "A methodology for
studying software design teams: An investigation of conflict behaviors in
the requirements definition phase," in Empirical Studies of Programmers
(E. Soloway and S. Iyengar, eds.), pp. 83-99, Ablex, 1985.

 [9]R. L. Glass,"The cognitive view: Adifferent look at software design," in
Software Conflict: Essays on the Art and Science of Software Engineering,
pp. 25-31, Englewood Cliffs, NJ: Yourdon Press, 1991.

[10]R. W. Holt, D.A. Boehm-Davis, and A. C. Schultz, "Mental
representations of programs for student and professional programmers,"
in Empirical Studies of Programmers (E. Soloway and S. Iyengar,eds.), pp.
33-46, Ablex, 1985.

[11]D. C. Littman,J. Pinto, S. Letovsky, and E. Soloway, "Mental models
and software maintenance,"in Empirical Studies of Programmers (E.
Soloway and S. Iyengar, eds.), pp.80-98, Ablex,1986.

[12]B. Meyer, Object-Oriented Software Construction. NewYork, NY:
Prentice Hall, 1988.

[13]D. Luckham,F. W. von Henke, B. Krieg-Bruckner, and O. Owe, ANNA: A
Language for Annotating Ada Programs. New York, NY: Springer-Verlag,
1987.

[14]B. Liskov and J. Guttag, Abstraction and Specification in Program
Development. The MIT Electrical Engineering and Computer Science
Series, Cambridge, MA: MIT Press, 1986.

[15]P.Bucci, J. E. Hollingsworth, J. Krone, and B. W. Weide,
"Implementing components in RESOLVE," ACM SIGSOFT Software
Engineering Notes, vol. 19, pp. 40-52, Oct. 1994.

[16]B. W. Weide et al., "Special feature: Component-based software using
RESOLVE," ACM SIGSOFT Software Engineering Notes, vol. 19, pp. 21-67,
Oct. 1994.

[17]J. A. Goguen, "Principles of parameterized programming," in
Software Reusability, Volume I: Conceptsand Models (T. J. Biggerstaff and
A. J. Perlis, eds.), pp. 159-225, New York, NY: ACM Press,1989.

[18]R. Milner, M. Tofte, and R. Harper, The Definition of Standard ML.
Cambridge, MA: MIT Press,1990.

Biography

Stephen H. Edwards is a Senior Research Associate in the Department of
Computer and Information Science at the Ohio State University. His
research interests include formal models of software structure, software
composition, software reuse,software engineering, the use of formal
methods in programming languages,and information retrieval
technology.He is also currently the Archive Administrator for the
Reusable Software Research Group at OSU. Dr. Edwards is a recent
graduate from OSU, having received a Ph.D. in computer and
information science in March,1995.  Prior to working at OSU, he was a
research staff member at the Institute for Defense Analyses, where he
worked on software reuse activities, simulation frameworks, active
databases, and Ada programming issues.

Mr. Edwards gratefully acknowledges financial support from the National
Science Foundation (grant number CCR-9311702) and the Advanced
Research Projects Agency (contract number F30602-93-C-0243, monitored
by the USAF Materiel Command, Rome Laboratories, ARPA order number
A714).
Life Cycle Interaction in
Domain/Application Engineering

David Eichmann and Carl Irving*

Repository Based Software Engineering Program, Box 113
Research Institute for Computing and Information Systems
University of Houston - Clear Lake
2700 Bay Area Blvd.
Houston, TX 77058
Tel: [phone]
Fax: [phone]
Email: [e-mail]
WWW: http://ricis.cl.uh.edu/eichmann/
RBSE on the Web: http://rbse.jsc.nasa.gov/eichmann/rbse.html

Abstract
The interactions between the life cycles for domain engineering and
application engineering are not commonly recognized. We discuss the
nature of these interactions and how they are reflected
in a specific large reengineering project.

Keywords:  domain engineering, application engineering, software
processes, reengineering

Workshop Goals:  To obtain feedback on a collaboration and do some
technology transfer.

1   Background
1.1  Introduction
The increasing emphasis in large, government software engineering
projects on engineering domains, rather than engineering specific
systems holds a promise of reduced costs, faster fielding of systems
and a host of other anticipated benefits. However, this transition to a
new perspective on software life cycles is not without side-effects. In
particular, we have found that the separation of development into a
domain engineering cycle and an application engineering cycle is not
as clear and distinct as might be imagined.
The Repository Based Software Engineering (RBSE) project at the
Research Institute for Computing and Information Systems (RICIS)
has been working for a number of years in the area of software
reuse and more recently, in the reengineering of legacy systems as
an aspect of reuse [3]. The purpose of RBSE is the support and
adoption of software reuse through repository-based software
engineering in targeted sectors of industry, government, and
academia. The project consists of two principal activities, a repository
initiative and reuse engineering initiative. RICIS conducts research
and development for both initiatives. MountainNet operates ELSA as
the publicly accessible aspect of the repository initiative [4].
The reuse engineering initiative at RICIS focuses on the support of
specific software projects as they transition to a reuse oriented
development and maintenance paradigm. One such project is the
Reusable Object Software Engineering (ROSE) project, involving the
Rockwell Space Operations Company (RSOC) (including UNISYS as a
major subcontractor), the Software Technology Branch of the
Information Systems Directorate of NASA (NASA/STB) and the RBSE
research group. ROSE is a reengineering effort being developed to
provide an economical and effective modern implementation of the
Shuttle Flight Design and Dynamics (FDD) systems in order to
supplant the costly legacy systems which have evolved since the
early days of the Shuttle program.
The ROSE project is intended to apply modern software engineering
techniques in order to reproduce the systems╒ functionality in a
consistent object-oriented architecture and design framework. The
project applies a reuse-based dual lifecycle process in order to
achieve efficiency and consistency across the software products as a
whole.

1.2  The ROSE Lifecycle in a Nutshell
The ROSE project is a reuse-based dual-lifecycle software
development project. The ROSE lifecycle (or lifecycles, to be exact
since there are separate domain engineering and application
engineering lifecycles) is based upon a collapse of the Clear Lake
Lifecycle Model (CLLCM) [5] from eight phases to four. The
fundamental division of responsibilities between domain and
application perspectives can be summarized as follows:

The domain engineers scope the domain, identify the potential
applications and establish a common ╥domain language.╙ Domain
Analysis is composed of domain survey, business analysis, concept
development, domain scoping and domain modeling sub-phases.

Domain Design is a design effort for one common architecture to the
domain. The design process includes explicit searches for reusable
components at various levels of abstraction and provides for reverse
engineering of portions of the legacy system in order to serve as
(positive or negative) ╥inspiration.╙ The paradigm is for one
architecture to cover the domain which can then be tailored by
pruning unneeded features and grafting extensions on an application
by application basis.

Domain Implementation focuses on the implementation and testing
of the architecture components in an orderly fashion prioritized in
such a way to support the application implementation efforts.
Implementation of architecture components includes their
integration to the degree that this is possible without a complete
application.



Application Analysis is a twofold extension process of the Domain
Analysis product set. Following concept exploration of the
application, the set of requirements and models produced by the
domain engineers is pruned down to form a starting subset of the
application requirements. This set is then extended through a
requirements gathering process in order to obtain a full set of
application requirements.

Application Design is concerned with the selection of architecture
subsets that match the application requirements and constraints
followed by a design process similar to that applied during Domain
Design ╨ but only for additions and modifications to the architecture.

Application Implementation uses exactly the same process as Domain
Implementation but applied to the application-specific components
remaining to be developed. Integration testing of the application is
meant to follow-on from the testing performed during Domain
Implementation: their union forms one seamless integration activity.

The application and domain maintenance processes are designed as a
two-tiered hierarchy where the customer interacts with Application
Maintenance which in turn makes requests of the Domain
Maintenance process as needed. Both processes are similar but differ
where it comes to the impact of change requests on domain products.

ROSE is scheduled as a number of ╥delivery increments╙ where a
significant portion of the product set is delivered on a regular basis
and the project╒s performance is reevaluated. This division has
interesting effects on the evolution of the projects╒s maturity with
respect to its dual-lifecycle organization. On one hand, transitions
from one increment to the next are excellent times to implement
upgrades in lifecycle models. On the other, the relative proximity of
the next scheduled delivery make incremental changes from a
relatively conventional initial process a necessity. ROSE is evolving
towards a mature dual-lifecycle organization, having started from
more humble traditional point-solution beginnings. It should be
noted that the lifecycle presented in figure 1 is the result of the
current delivery increment╒s labors and is expected to be
institutionalized as of the next increment.
2   Position
The software lifecycle is a complex set of interrelated activities. Some
in our field claim to understand the nature of the relationships
between the phases of the lifecycle and the roles involved in
traditional ╥point-solution╙ approaches to software development.
However, newer and arguably more productive reuse-based process
models such as the ╥dual-lifecycle╙ approach to software
development where two perspectives (domain engineering and
application engineering) are employed raise new uncertainties about
the way the lifecycles (and their individual phases) fit together.

Our experience with the ROSE project has allowed us to witness the
establishment and implementation of a reuse-based dual-lifecycle
software development organization on a non-trivial scale. The choice
and tailoring of initial ╥theoretical╙ models (e.g., the CLLCM) into the
practical processes that ROSE team members use on a day-to-day
basis give insight into the structure and interactions within working
teams using this approach.

The introduction of a second lifecycle to the overall development
process introduces new ways in which the phases of the lifecycle
influence each other. The traditional ╥point-solution╙ lifecycle implies
that the various phases of the lifecycle influence each other in a
╥producer-consumer╙ sense: earlier phases produce products which
are picked-up, interpreted and transformed (╥consumed╙) by later
ones. Influences can exist when considering both products and
processes present in the lifecycles, as shown in Table 1.


Table 1: Some Process Influences with Examples
Influence    Medium    Example
Application Analysis is a consumer of Domain Analysis products
    Product    Domain requirements and models
Domain Analysis is influenced by the Application Analysis process:
The products of Domain Analysis must be compatible with adaptation
as performed by Application Analysis    Process    The initial
process employed by ROSE Domain Analysis captured requirements
as a classified ╥flat╙ set of requirements. This later evolved into a
hierarchical classification as such a structure facilitates the job of
application analysts through the manipulation of requirement
hierarchies as a whole rather than individually. The change was
directly related to the needs of the Application Analysis process.
Domain Analysis influences Domain Design as far as the expression of
variability in the domain    Product    The scope (i.e. applications)
of the requirements and constraints with the (explicit or implicit)
variability requirements captured during Domain Analysis are the
basis for the domain designers╒ use of adaptable design idioms
Application Design is a consumer of Domain Design products
    Product    Architecture design models and design feature
catalogues
Application Design influences Domain Design╒s choice of design idioms
to be compatible with the adaptation techniques it employs    Both
    The ROSE Domain Design process explicitly contains a step early
in the process to determine suitable design guidelines with respect to
the Application Design process and the expected targets. Care is
taken to include the application engineering role where possible to
ensure design adaptability.
Application Implementation is a consumer of Domain
Implementation products    Product    Coded partially or
completely integration-tested components with documentation and
test plan
Domain and Application Implementation processes influence each
other with respect to their shared task    Process    The domain and
application implementation processes are differ in their ability to
integration test implemented products. The former is constrained by
the non-availability of complete subsystems to integrate (since key
components may be application-specific) so integration and target
testing are distributed unevenly across both implementation phases
The Domain Maintenance process influences the Application
Maintenance process    Process    Since the maintenance processes
are organized as a two-tiered hierarchy, the Application Maintenance
process needs to delegate domain issues to the Domain Maintenance
process through a well-defined interface
Understanding the ways in which the processes interact and
influence each other in a dual-lifecycle software organization has the
potential for insights into the workings of domain engineering
processes as we know them and hence a better footing for improving
them.

For example, a better understanding (and a catalogue) of the design
adaptation mechanisms employed during Application Design can be
employed by domain designers to select the most suitable design
techniques and idioms in order to support these choices (what one
could call ╥meta-design patterns╙). In a practical environment, the
choice of adaptation techniques and the idioms that support them is
the result of a consensus between the domain and application
engineers. The ROSE processes exhibit early traits of such an
organization (although without the comprehensive bindings between
design techniques and their adaptability) in that domain design
activities are based upon the use of ╥design feature catalogues╙ that
record good practices (with corresponding rationale) that have been
shown to have value in the Domain Implementation and Application
Design efforts.
2.1  Discussion
Much of the current work on domain analysis and dual-lifecycle
software processes centers around the design of processes that allow
for the capture of domain information and make it available to
builders of actual applications in the domain. A characteristic of
domain products is their support for adaptation (through
composition, inheritance or ╨ if necessary ╨ modification). Domain
engineering efforts thus strive to employ consistent and effective
means to support application-specific adaptation. One of the process
designer╒s choices is to decide where these means are defined: they
can be embedded in the process, left to the application engineer╒s
choice or produced explicitly as part of domain engineering. These
three views by themselves may be a little simplistic in that processes
in the dual lifecycles have more influence on each other than implied
by a simple producer-consumer relationship.

Our views are driven by the observation of the design and enactment
of a project using the dual-lifecycle approach: ROSE. The initial
mindset of the process designers was for domain engineers to define
the domain architecture and specify the means for its adaptation ╨ a
model where consumption of products bears no influence on the
producer. In actual practice, the differences in outlook between the
domain and application engineering teams imposed a more pragmatic
compromise.

Examination of domain engineering products led to an interesting
question: what makes a domain product (analysis model, architecture
design, etc╔) ╥special╙ as opposed to the corresponding products in a
point-solution lifecycle? In many instances, we found none: although
they were the result of a different process, domain products tended
to be expressed in a manner consistent with habitual products of
their kind. This implies that domain engineering can be performed in
a manner that does not automatically entail readily apparent domain
engineering-specificity in the product set.

This led us to a closer examination of the processes, where it became
apparent that although they have separate foci, neither domain nor
application engineering operates in a vacuum. For instance, Domain
Design exhibits a pragmatic mix of influences on and by the
Application Design process: on one hand, the design features present
in the domain architecture are drawn from a feature catalog that is
passed on to application designers with instructions as to their
planned use but on the other, this catalog itself is built with input
from the application engineers. In the current state of the process,
this influence ╨ although tangible ╨ is not formalized.

These observations upon the influences that the domain and
application engineering lifecycles have upon each other do still hold
(although with different manifestations) when domain engineering-
aware notations and techniques are used. For instance, the layered
design architecture presented by Becker and DÆaz-Herrera [2] is
consistent with the culmination of an informal design feature
selection procedure similar to that in the ROSE Domain Design
process. Alternative formalisms for the representation of domain
architectures (such as the formal architectural components proposed
by Allen and Garlan [1]) present opportunities for treating some of
the interactions between lifecycles in a disciplined manner, as they
represent a common formal language for manipulating the
composition of domain products.

Identifying the interdependencies between the domain and
application engineering processes also is a step towards their
efficient management. For example, one problem that the ROSE
domain engineers have had to cope with is that the division of the
project into delivery increments precludes the analysis and modeling
of the domain as a whole, domain and application engineering are
executed in near-concurrency so that the planned increment can be
produced on time. Such a ╥condensed╙ execution of the processes
taxes the ability of the domain engineers to model the domain
broadly and for the application engineers to provide meaningful
feedback. An overall model where the domain and application
lifecycles operate in a vacuum does nothing to discourage this kind of
schedule nor to understand its inherent couplings.
References
[1]    Allen, R. and D. Garlan, ╥Formalizing Architectural Connection,╙
Proc. 16th International Conference on Software Engineering,
Sorrento, Italy, May 16-21, 1994.

[2]    Becker, M. and J. L. DÆaz-Herrera, ╥Creating Domain Specific
Libraries: a methodology and design guidelines,╙ Proc. Third
International Conference on Software Reuse, Rio de Janeiro, Brazil,
November 1-4, 1994.

[3]    Eichmann, D., ╥The Repository Based Software Engineering
Program╙ Proc. Fifth Systems Reengineering Technology Workshop,
Monterey, CA, Feb. 7-9, 1995.

[4]    Eichmann, D., M. Price, R. Terry and L. Welton, ╥ELSA and MORE:
A Library and Environment for the Web,╙ Proc. 13th Annual National
Conference on Ada Technology, Valley Forge, PA, March 13-16, 1995.

[5]    Rogers, K., M. Bishop, C. McKay, ╥An Overview of the Clear Lake
Life Cycle Model,╙ Proc. Ninth Annual National Conference on Ada
Technology, U.S. Department of Commerce, National Technical
Information Service, March 1991.
Biographies
David Eichmann is an Assistant Professor of Software Engineering at
the University of Houston - Clear Lake and Director of Research and
Development of the Repository Based Software Engineering Program
(RBSE).  Besides normal academic duties, his responsibilities include
management of a fifteen person research and development group
working in the areas of reuse repositories and reengineering. Funded
by NASA through the RICIS cooperative agreement and working
closely with Johnson Space Center╒s Software Technology Branch,
RBSE is collaborating with Rockwell Space Operations Company on the
reengineering of a major portion of the Space Shuttle Flight Analysis
and Design System.

Carl Irving is a graduate student in the Software Engineering
Program at the University of Houston - Clear Lake and a research
assistant on the RBSE project. His responsibilities include domain
modeling and process definition on the ROSE collaboration.

*    This work has been supported by NASA Cooperative
AgreementRB02A.


Software Process Reuse

Craig Hollenbach & William Frakes

Department of Computer Science
Virginia Tech
Falls Church, VA 22042
Tel: [phone]
Email: [e-mail]


Abstract
This paper describes an in-progress study of software process reuse
and reusability╤specifically how to pragmatically and systematically
standardize and replicate project-specific processes in an industrial
software environment. Our working hypothesis is that by using
domain engineering techniques, software reuse principles, process
architecture research, and process modeling mechanisms, project-
specific processes can be abstracted into reusable components that
can be  used by process engineers.

The study includes:
Ñ    a notation for recording reusable processes,
Ñ    definition of processes in an industrial environment,
Ñ    creation of a repository of these reusable processes.
Ñ    an evaluation study aimed at demonstrating the effectiveness
of our method for process reuse.  The study is based upon process
definition activities at PRC Inc. The study will measure the level of
process reuse both before and after the application of the proposed
process reuse improvement method.

1 Position

1.1  Introduction

Many software organizations are actively pursuing software process
maturity.  Often they use measures like the SEI Capability Maturity
Model to structure their process improvement initiatives.  PRC Inc.
has pursued software process maturity in various ways since 1987.
One method often cited for accelerating process improvement within
an organization is the standardization and replication of project-
specific processes from a mature software organization to immature
software organizations.  Even though it is often proposed as an
effective approach to increasing an organization's software maturity,
there have been few documented instances of process reuse within
the software process improvement program at PRC.

A  literature search showed that this situation is common in other
organizations as well.  Although there are instances of replicating
processes within organizations, there are no reports of a systematic
process reuse program.   Only one study has addressed process reuse
specifically [2], indicating that systematic process reuse is
unrealized.

One of the more daunting tasks of a process reuse program is the
development and maintenance of quality process definitions which
serve the entire organization.  To meet this need, PRC has developed
an Organization Process Definition (OPD) methodology used to define
reusable processes.  Since the scope of OPD encompasses all software
projects within PRC, we deal with a diverse set of projects and
project needs.  To serve them better, we have developed a set of
standard, generic process definitions, and have started using a
standard process to develop, maintain, and manage those definitions.
We have also created a Process Asset Library (PAL) which contains
reusable processes and process-related assets.

1.2  The PRC OPD process

The PRC OPD process is adapted from the process described at the
1994 National SEPG (Software Engineering Process Group) Meeting by
Jim Over, and on other domain analysis methodologies [1].  The OPD
process starts with PRC SEPG approval, feeds the development of
organizational training and the instantiation/tailoring of the process
and process training on PRC projects, and includes feedback from the
projects for continuous process improvement.  The process itself
includes  steps for planning, analysis, high-level design,
implementation design, implementation of process automation, and
testing and integration within the PRC process architecture.

1.3  Process Asset Library

The Process Asset Library (PAL) is a corporate resource that contains
reusable processes and process related assets from both corporate
and project levels.  It currently contains over 500 assets and uses a
WWW browser as a front-end.  A catalog of assets is maintained for
simple perusal, searching, and maintenance.  Plans are under way to
integrate the PAL with corporate metrics and tools databases.

PRC took the advice of other SPI efforts and began with a small and
simple PAL prototype.  The database was a simple file server with a
spreadsheet acting as a catalog.  Access problems, support over
multiple platforms, and the need for various application output
formats created a need for a prototype WWW browser as a front-end
interface.  We have also learned the lesson that small is beautiful in
process definition and the importance of including more software
practitioners in the definition process, as we transition from a
centralized to a de-centralized approach to process definition.

1.4  Use of the OPD process and the PAL

The PAL user base within PRC includes SEPG members at all
hierarchical levels, proposal and project startup efforts, and
members of software process improvement (SPI) working groups.
Example uses of the OPD process include peer review, developmental
CM, and subcontract management processes.

1.5  Experiments

We will run several quasi-experiments to evaluate the effectiveness
of the process reuse methods we propose.  We are collecting data,
over time, from several projects that have used the method.  This
data includes the number of reused processes and the percentage of
reused processes.  We will compare these number for projects before
and after the introduction of the reuse process methods.

References

[1]    Arango, G. (1994). Domain Analysis Methods. In W. Schaefer, R.
Prieto-Diaz, & M. Matsumoto (Eds.), Software Reusability New York:
Ellis Horwood.

[2]    Castano, S. and DeAntonellis, V. ╥Reusing Process Speicifcations╙,
in N. Prakash et. al (Eds.) Information System Development Process:
Proceedings of the IFIP WG 8.1, Working Conference on information
System Development Process, Como Italy, 1-3 Sept. 1993: North
Holland Pub..

Biographies

Craig Hollenbach is principal computer analyst at PRC, Inc.  He has
over 14 years of software engineering experience and 6 years
experience in software process improvement.  He is currently
working on software process improvement activities within PRC and
PRC's Technology Center and is chair of the Technology Center SEPG.
Craig has a B. S. degree from Lebanon Valley College and is pursuing
a M. S. in Computer Science from Virginia Tech.

Bill Frakes is associate professor and director of the computer science
program at Virginia Tech, Falls Church, and president of the Software
Engineering Guild.  He has been manager of the Software Reuse
Research Group at the Software Productivity Consortium, and
supervisor of the Intelligent Systems Research Group at Bell
Laboratories.  He is author of Software Engineering in the UNIX/C
Environment (Prentice-Hall, 1991), and Information Retrieval: Data
Structures and Algorithms (Prentice-Hall, 1992).  He is chair of the
IEEE TCSE Committee on software reuse.


Reuse Lessons Learned from Architecture and Building Systems
Integration

Marilyn T. Gaska

Loral Federal Systems-Owego
1801 State Route 17C
Owego, NY 13827
Tel: [phone]
Email: [e-mail]

Abstract

A previous position presented at the WISR6 conference by the author
([1]) compared the similarities of the OSE and COTS integration research
areas to those ofthe horizontal reuse research. This paper extends this
concept outside the computer-based systems field to draw on
comparisons to generic design and systems integration concepts from
other disciplines such as architecture. These established disciplines may
provide reusable process patterns for success to be applied to the "new"
approaches in computer-based systems design: object-oriented methods,
component-based design, and open systems.

Keywords: Horizontal Reuse, Architecture, Computer-Based Systems,
Generic Design, Patterns, Open Systems Environment (OSE)

WorkshopGoals: To learn additional concepts and technology for transfer
to industrial environment; to obtain inputs on position,particularly
related to Ph.D. Dissertation topic in Systems Science at Binghamton
University.

WorkingGroups: Technology Transfer, Reuse Management, Domain
Analysis.

1   Background

Since February 1993,the author has held the position of Reuse
Coordinator at Loral Federal Systems (LFS) in Owego,New York [2] where
she also served as the local arrangements chair for WISR6 held in Owego
in November,1993. Current reuse activities at Loral have expanded to
include LFS Group-wide responsibilities. She is also the Principal
Investigator for Open Systems Independent Research and Development
(IRAD)tasks, including a task on Object Oriented Frameworks and
Domain Specific Software Architectures for Management Information
Systems (MIS). Previous papers presented by the author have focused on
the commonalities among problems and application of solutions in the
reuse, concurrent engineering, and open systems research are as [3, 1, 4].
This analysis has broadened to comparisons with approaches in areas
outside of computer-based systems as part of the authors research
interest in design [5]. Reuse is one of the design attributes included in
this analysis.

2   Position

Reuse is a design attribute of other established disciplines such as
architecture. Architecture and building systems integration concepts can
me mapped to computer-based systems to provide new design for reuse
perspectives and lessons learned.

Systems science teaches the benefits of cross-discipline learning, which is
proposed as useful to research efforts in reuse. While [1] compared the
similarities of the OSE and COTS integration research areas to those of
the horizontal reuse research, the focus of this position paper is
application of concepts from the field of architecture. Further analysis
with respect to specific design attributes such as reuse can also provide
additional lessons already learned in other fields. Since architecture has
embraced component-based design andstandards concepts when dealing
with physical building objects,it holds promise for useful patterns for
application to parallel approaches in computer-based systems design.

2.1  Insight from Architect Alexander's Work

Christopher Alexander's frequently referenced early work [6] does not
directly address reuse concepts. Rather, conscious and indigenous /
unconscious design, analysis and synthesis, and patterns are described.
This book was followed by a six volume series [7, 8, 9, 10, 11, 12].[7]
describes the timeless way of building in terms of a genetic process for
creation of a whole organism,an analogy that has also been further
described in [13]. The framework for the pattern language described in
[8] is put in place. Patterns are similar to rules of thumb. Patterns of
events give character to a place, and are interlocked with geometric
patterns in space. These patterns are the atoms and molecules that
make up a building or town, and the language gives users the powers to
create an infinite variety of new and unique buildings appropriate to
different circumstances. Constant use and feedback keeps the patterns in
good order, and people and their feelings can't be separated from the
language. In computer-based systems,this concept can be applied to the
requirements, high-level design, detailed design or
implementation/construction phases just as they scale from regional
planning down to physical structure considerations in architecture.

A total of 253 patterns are described in [8]. However, a project may
defineits own language by selecting form those pre-defined patterns
aswell as defining additional patterns appropriate to the domain of the
project. The order in which the patterns are applied to a design will
impact the result. Application of these concepts at the University of
Oregon is described by [9]. All design and construction was guided by a
collection of communally adopted planning principles called patterns.
Other implementation principles included principles of participation,
piecemeal growth, diagnosis, coordination and organic order. [11]
describes the experience in building the Linz Cafe for an Exhibition in
accordance with the pattern language principles.

[10] define the building system in terms of the actions that are needed
to produce a building,not in terms of the physical components. The
system of operations required must have the property that each
operation can be completed by itself, secure that the operations which
follow can always be done. It is their nature to be able to adapt
themselves to the results of the operation already performed. Alexander
explains how the process is capable of allowing mass production of large
numbers of houses which are all different, without increasing cost. [12]
describes seven detailed rules of growth which include parallels for
principles of incremental design.

2.2  Building Systems Integration Perspectives

Books from the field of architecture that deal with integration theory
among subsystem components more closely parallel experiences in large
scale reuse. The remainder of this discussion will focus on a more recent
compilation of works into a handbook on building systems integration.

Rush has edited a book published by the American Institute of Architects
that proposes a model for analysis of building systems integration that
can be applied to computer-based systems design and architecture
([14]).  This model provides an understanding regarding the ease of
reuse of architectural components that parallels current experiences and
directions in computer-based systems. These include directions in open
systems, client server, commercial off the shelf (COTS) and object-
oriented design. This includes a theoretical basis for the two and three-
tier architecture of client-server computing.

Rush documents a new shorthand for a clear concept of integration that
reduces all buildings systems to a set of four overall systems- structure,
envelope, mechanical and interior. Roundtable discussion of
professionals from several disciplines resulted in a tetrahedron
interrelation diagram for the four systems. A summary of the
tetrahedron nodes and proposed parallels form computer based systems
follows:

   Architecture Tetrahedron            ProposedComputer-Based Systems
   of Major Systems                         Tetrahedron of Major Systems

ENVELOP    (Visible on exterior)       Human Computer Interface (HCI)

STRUCTURE  (Creates equilibrium    Platform (includes operating system
          necessary to allow                and network)
          building to stand)

INTERIOR   (Visible from inside)       Data Model

MECHANICAL (Services to building   Methods/functions
           and occupants)                   System/Business Logic/Rules

A proposed diagrammatic method for visible integration is used to
describe 11 possible combinations of systems,a 5 level scale of
complexity, and 6 performance mandates. The result of the process has
been called building systems integration,which is defined as the act of
creating a whole functioning building containing and including building
systems in various combinations. The success of a system, like that of
integration, is evaluated by comparison of the intention (requirements
and goals) with the result. The design for a building becomes the final
integration - an order that includes systems but is not a system itself.
The integration is complete when all of the links have been established.

Similar to Alexander's patterns, Rush identifies 19 buildings actually
built (with clients, sites, program requirements, costs andarchitects) as
case studies.  Aset of 15 generic examples are generated, each with
principal applications and advantages listed along with key integration
issues. He emphasizes that architects don't learn to design by reading
books, and that every architect's learning process is by direct experience
and takes a lifetime. The book explores building systems configurations
in the context of the criteria (requirements) by which they are selected
and available options.

In general, a client's need for a building generates a choice to either
select a building that has already been built or select an architect. This
parallels the process of selecting COTS or custom development. Similar
to software, part of the architect's responsibility / task is selecting from
existing products and services,while another part is integrating and
originating the system. On the integration continuum, maximum
integration can minimize flexibility, while complete indep endence of
parts can provide for greater interchangeability and evolution of use. In
summary, these concepts can be used to explain current developments
in computer science:

1. Ob ject-Orientation - integration of data and logic/methods

2. Client/Server - 3 tier architecture with separate HCI, logic and data
servers

3. Open Systems - platform portability, scalability and interoperability

4. Reengineering - assessing reusability and options for moving in flexible
and tightly integrated proprietary systems

5. COTS software - success of windows environment and spreadsheet
applications

6. Small vs. Large Scale Reuse - individual vs. multiple nodes of
tetrahedron impacted

2.3  Research Plans

The key issue for reuse is a systems integration issue. What is the best
architecture and system integration approach to optimize reuse? How do
software system architects best synthesize systems built apart? What are
the integration properties of the most easily reused tetrahedron nodes
and combinations? How do concurrent engineering concepts apply that
allow for design and integration of all components / disciplines so that
system behaves as unified whole and meets performance goals and
customer satisfaction?How can patterns be applied to requirements to
assure that user needs met for each particular problem?

An initial focus on user requirements has been selected to address the
need for a smooth transition into design for the new computer systems
paradigms [5]. Methodologies that support design for reuse, open
systems, COTS, and object-oriented frameworks are needed.  This analysis
will be expanded to include other disciplines beyond architecture. These
include systems science, computer science/software engineering,
management information systems, product design and manufacturing,
and science/health. Recommendations for user involvement and rapid
prototyping with OSE and COTS constraints will be applied to case
studies.

3   Comparisons

Generic design books such as [15] have drawn from the field of
architecture for many of the basic design concepts. Gause and Weinberg
focus on the requirements step with involvement of all key user
constituencies as crucial to successful design. However, application of
additional guidance drawn from architecture may provide additional
refinement to their framework for exploring requirements.

Gamma et al. have cited Alexander's Pattern Language [8] as a basis for
the "Design Patterns, Elements of Reusable Object-Oriented Software"
[16].  They give credit to Alexander and his colleagues as "the first to
propose the idea ofusing a pattern language to architect buildings and
cities." These are some of the ideas that have taken root in the object-
oriented community as a key to helping developers leverage the expertise
of other skilled architects. However,a review of the complete six volume
series by Alexander and colleagues may indicate a different intent than
what one might think of as reuse in architecture. Alexander emphasizes
user involvement in the design process [12] and customization during
application of rules within the context of a unique specific sites. He
expresses disdain for prefabricated modular components that constrain
the design customization and adaptation [10].  Care must be takenin
application of the pattern language concepts to assure that these
concerns are addressed.

Tracz and Coglianese ([17]) have focused on processes for domain
specific software architectures (DSSA). [10] proposes replacement of the
idea of a building system as a system of components to be assembled
with a step-by-step system of building operations. Comparison and
appropriate incorporation of these concepts into DSSA methodologies
may be warranted.

References

 [1]M. Gaska, "An Open Systems Perspective on Horizontal Reuse," in
Sixth Annual Workshop on Institutionalizing Software Reuse, (Owego, New
York), pp. Gaska1-7, In cooperation with the IEEE Computer Society
Technical Committee on Software Engineering, November 2-4, 1993.

 [2]M. Gaska and J. Poulin, "Institutionalizing Software Tools and
Methods," in IEEE Computer Society Workshop on Software Engineering
Technology Transfer, (Dallas, Texas), pp.143-146, April,1994.

 [3]M. Gaska, "An Open Systems Profile for Concurrent Engineering," in
Proceedings Second Workshop on Enabling Technologies (WET)-
Infrastructure Collaborative Enterprises (ICE), (Morgantown, WV), IEEE,
April 20-22, 1993.

 [4]M. Gaska, "Application of Reuse Concepts to Concurrent Engineering,"
in Proceedings from Concurrent Engineering Research and Applications
(CERA) 1994 Conference, (Johnston, PA), pp. 255-266, Concurrent
Technologies Corp., August 29-31, 1994.

 [5]M. Gaska, "General Principles of Requirements Engineering Across
Disciplines: Patterns for Application to New Approaches to Computer-
Based Systems Design,"Tech. Rep. Prospectus for Ph.D. Research,
Binghamton University, June 1994.

 [6]C.Alexander, Notes on the Synthesis of Form.Cambridge, Mass.:
Harvard University Press, 1964.

 [7]C. Alexander, The Timeless Way of Building. New York:Oxford
University Press, 1979.

 [8]C. Alexander, S. Ishikawa, M. Silverstein with M. Jacobson, I. Fiksdahl-
King, and S. Angel, A Pattern Language. New York: Oxford University Press,
1977.

 [9]C. Alexander, M. Silverstein, S. Angel, S. Ishikawa, D.Abrams, The
Oregon Experiment. New York: Oxford University Press, 1975.

[10]C. Alexander with H. Davis, J. Martinez, and D. Corner, The
Production of Houses.  New York: Oxford University Press, 1985.

[11]C. Alexander, The Linz Cafe / Das Linz Cafe. New York:Oxford
University Press, 1981.

[12]C. Alexander, H. Neis, A. Anninou, I. King, A New Theory of
UrbanDesign.  New York: Oxford University Press, 1987.


[13]D. Gause and E. Minch, "Design Processes: A State Space Perspective,"
in Praxiology: The International Annual of Practical Philosophy and
Methodology,Volume3, (Rutgers University, New Jersey), Transaction
Publishers, 1995.

[14]R. Rush, ed., The Building Systems Integration Handbook. Boston:
The American Institute of Architects,1986.

[15]D. Gause and G.Weinberg, Exploring Requirements: Quality Before
Design. New York: Dorset House,1989.

[16]E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns.
New York: Addison-Wesley, 1995.

[17]W. Tracz and L. Coglianese, "Domain Engineering Process Guidelines,"
Tech. Rep. ADAGE-IBM-92-02, IBM Federal Sector Division, March 1992.

4   Biography

Marilyn T. Gaska is an Advisory Programmer in Advanced Technology at
Loral Federal Systems in Owego, New York. Her specific background in
reuse and open systems IRAD tasks has already been described. Marilyn
also has been involved in Open Systems Environment (OSE)standards
and profiles on the Army Sustaining Base Information Services (SBIS)
contract,as well as Commercial-Off the Shelf (COTS) software integration
LFS-Owego tasks.Prior to joining the Federal Systems Integration business
area, assignments involved concurrent engineering and computer aided
design (CAD). Marilyn had experience in other fields such as health care
before joining IBM Federal Systems Company,now part of Loral, in 1987.
In addition, she is a Ph.D. candidate in the Industrial Engineering and
Systems Science Department at Binghamton University. Research in the
systems design area with Professor Donald C. Gause focuses on
application of requirements principles across disciplines to new
approaches to computer-based systems design [5]. These part-time
studies follow her second Master of Science in Advanced Technology at
Binghamton in 1985. However,she received her first Master of Science on
a Cornell Fellowship in 1979 following completion of a Bachelor of
Science degree at Cornell in 1978. She is also a member of the IEEE.
The Architecture and Processes for a Systematic OO Reuse Factory

Martin L. Griss
Hewlett Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94303
Tel: [phone]
Fax: [phone]
Email:[e-mail]

Abstract

This position paper describes the initial ideas of a new project, aimed at
developing an Objectory-based Reuse Factory. This work is a research
collaboration between Martin Griss and Ivar Jacobson, and several
colleagues at HP and Objectory. We are combining the systematic reuse
concepts of process, organization and kits, with the OO modeling and
methods of Ob jectory's system engineering (OOSE) and business
engineering (OOBE).

Keywords: OO reuse, process, organization, architecture, methods

Workshop Goals: Learning; networking; share and get feedback on initial
ideas

Working Groups:reuse process models, reuse architecture, domain-
engineering

1   Background

I have worked since 1988 in the area of systematic software process and
technology at Hewlett-Packard, in both HP Corporate Reuse practice and
in HP Laboratories research. I have described the evolution of my work at
many reuse events: WISR[Gri92, GT93], IWSR[GJK+94], SRR[GJJ+95],
SAC94[GW94 ] and OOPSLA[GAB+91 ], as wellas in other publications
[Gri93,GW95b , Gri95b,Gri95a,GW95a , GK95a].

During this time Iand several colleagues (primarily Kevin Wentzel,James
Navarro, Ruth Malan, Patricia Collins and Danielle Fafchamps) developed
the concepts and explored several consequences of domain-specific kits
and flexible software factories.  Several ideas,such as reuse handbooks,
domain-specific kit analysis frameworks and reuse maturity moels, were
refined during working groups at WISR.

Most recently, I have been exploring the integration of these ideas with
OOmethods and technology, leading to a collaboration with Ivar
Jacobson, started in Nov 1994[AG94, Gri95b, Gri95a,GJJ+ 95]. I and a
sabatical visitor (Bob Kessler, University of Utah) have been applying
these ideas to the development of an exemplary instrument systems kit,
prototyped using Lego Dacta Control Lab parts[GK95a, GK95b ]. This is
used as a test case for the Objectory modeling, and proposed for part of a
new reuse-based software engineering course for delivery at the University
of Utah.

2   Position

Object technology (OT)is believed to be crucial to achieving the long
sought after goal of widespread reuse. This goal is the most frequently
stated reason for adopting OT. Unfortunately,many people naively
equate reuse with objects, expecting it to"automatically" ensure reuse,
but often do not get much reuse[Pit93]. Based on our experience with
reuse at HP and Objectory, and with our many customers, we think that
OT as used today will not succeed in giving users reuse. Without an
explicit reuse agenda, and a systematic approach to the design and use
of reusable assets, OO reuse will not succeed. In almost all cases of
successful reuse, management support, simple architecture, a dedicated
component group, a stable domain, standards and organizational
support were the keys to success. These largely non-technical issues seem
to be more important to successful reuse than the specific language or
design methodology chosen.

We believe that this architecture/process/organization question can be
addressed systematically. Our work is exploring an exciting approach
which applies Object-oriented Business Engineering (OOBE) and concepts
of BPR to restructure a software development organization to offer reuse
at a large scale. To obtain a true systematic OO reuse process, today's OT
must be augmented with specific reuse-oriented processes,
organizationstructures, guidelines, and training. OO methods must be
extended to support domain engineering,with specific architecture and
component factoring and clustering steps. Component and framework
engineering should include explicit design and implementation
guidelines, building on a catalog of architectures, patterns, designs and
mechanisms. We need a better understanding of how to produce layered,
modular architectures. We need to determine how and when to augment
OO application frameworks with problem oriented scripting languages,
builders, and systems and component generators to produce domain-
specific kits that can handle the complexity inherent in frameworks with
large numbers of classes and methods.

Our work in progress explores how the principles of systematic
reuse[Gri95b] and reuse processes, such as captured in the CFRP[STA93a,
STA93b], can be used to augment traditional object-technology. In
particular,we have tried to apply OO methods to the description and
analysis of organization, process and reuse architecture and technology
issues.

As our OO method,we use the Use-driven approach of Ivar Jacobson. We
useOOBE[JCJO92 ] and OOSE[JEJ94] to link the reuse organization and
process with the reusable as sets (architectures, components and
frameworks). We have augmented standard Objectory with the concepts
of component systems,layered architectures,systems of interacting
systemsand component system kits.

2.1  Reuse organization and processes

We will use an OOBE model to describe the processes and organizations
used in the design and evolution of reuse-oriented organizations. Here,
use-cases are used to model the interaction of an actor (person or
external organization) with the subject organization. Use-case and
domain models (not the domain engineering model) help identify core
processes within the organization. When these models are further refined
to produce the Objectory robustness model (with interface, control and
entity objects), we are able to map these onto processes (control
objects),handlers (interface objects) and information systems (entity
objects).Factoring and subsystem packaging techniques at the OOBE
model allow us to introduce and model organizations.

This organizational or business modeling technique is applied in two
different ways:

Development organization - it is applied to the software development
organization to introduce and model reuse processes and organizations.
This use is related the Objectory notion of "development cases."

Business object extraction- it can also be used as part of the
"organizational domain engineering process" applied to some target
organization or system,to identify reusable business objects and
processes. This could be called a "business-case."

For example, we might start with a high-level of a company, and quickly
identify software development and process improvement sub-
organizations.Looking at the sub-system to subsystem interactions helps
us model the roles of people such as reuse engineer,reuse manager,
librarian, etc.

2.2  Domain engineering and component systemskits

Here we believe strongly in an incremental, architectural, domain-
specific approach.

We are modifying the robustness analysis phase of the Objectory method
to make explicit the commonality and variability required to carry out a
systematic, OOdomain engineering. We are most influenced by the ideas
of FODA[Kan90], ODM[Sim95] and Gomaa[Gom91 ]. As noted above, the
OOBE phase is most like ODM, helping identify business objects.

We have also found the need to introduce notation and methods to
support application ssystems that are built in a layered or modular way
from a combination of concrete and abstract components. Components
are sets of models (Objectory thinks of code asyet another model) related
to each other by refinement and tracebility links, and encapsulated by
interface objects (which we will call "facade objects" or "contract
objects",in the style of the pattern community[GHJV94]) based on other
Objectory work on systems of interacting systems. We see the need to add
some mechanisms for additional parameterization, in order to explicitly
capture variability, and not just use the existing "uses" and "extends",
via subclassing and aggregation.

When a component system is adorned with domain-specific methods,
tools, instructions and training, more suited to a special class of handler
( i.e, domain expert rather than s ftware engineer), we call this a
"component system kit."

3   Conclusion

We are quite excited about how well these ideas fit together, and how
easily the concepts of use-case, robustness model and devlopment case
can be extended with the OOBE and domain-engineering ideas. This work
is still in its earliest phases, but we hope to produce a more detailed
report by the end of the summer, and a tutorial for OOPSLA.

References

[AG94]  Eric Aranow and Martin L. Griss. Systematic software reuse.
(Tutorial: Object World San Francisco), July 1994.

[GAB+91] Martin L. Griss, Sam S.Adams, Howard Baetjer, Jr., Brad J. Cox,
and Adele Goldmics of software reuse (panel). In Proceedings of OOPSLA
 '91,Phoenix, Arizona, 6-11October, pages 264-270, November 1991. (Also
as SIGPLAN Notices v26, 1, Nov 1991).

[GHJV94] Erich Gamma, Richard Helm, Ralph Johnson, and John
Vlissides. Design Patterns - Elements of Reusable Object-Oriented Software.
Addison-Wesley Publishing Company, Reading, MASS, 1994. (ISBN 0-201-
63361-2).

[GJJ+95]Martin Griss, Ivar Jacobson, Chris Jette,Bob Kessler, and Doug
Lea. Panel: Systematic software reuse - objects and frameworks are not
enough.  In M. Samezadeh, editor, Proceedings of the Symposium on
Software Reuse. IEEE, April 1995.

[GJK+94] Martin L. Griss, Chris Jette, Voytek Kozaczinski, Robert Troy,
and Anthony Wasserman. Panel: Object-oriented reuse. In W. B. Frakes,
editor, Proceedings of theThird International Conference on Software
Reuse, pages 209-213, Los Alamitos, California, November 1994. IEEE
Computer Society Press.

[GK95a] Martin L. Griss and Robert R. Kessler. Visual basic does lego. In
VBITS '95. Visual Basic Programmers Journal, March 1995.

[GK95b] Martin L. Griss and Robert R. Kessler.Visual basic does lego.
Technical Report HPL-xx, HP Laboratories, April 1995.

[Gom91] Hassan Gomaa. An object-oriented domain analysis and
modeling method for software reuse. In Bruce Shriver, editor, Proceedings
of the Twenty-Fifth Hawaii International Conference on System Sciences,
pages 46-56, Los Alamitos, CA, January 1991. IEEE, Computer Society
Press.

[Gri92] Martin L. Griss. Amulti-disciplinary software reuse research
program. In Martin Griss and Larry Latour, editors, Proceedings of the 5th
Annual Workshop on Software Reuse, pages Griss-1:8. Department of
Computer Science, University of Maine, November 1992.

[Gri93] Martin L. Griss.  Software reuse:  From library to factory.  IBM
Systems Journal, 32(4):548-566, November 1993.

[Gri95a] Martin L. Griss. Software reuse:A process of getting organized.
Object Magazine, May 1995.

[Gri95b]Martin L. Griss. Software reuse: Objects and frameworks are not
enough. Object Magazine, pages 77-79, February 1995.

[GT93]  Martin Griss and Will Tracz. Wisr'92: 5th annual workshop on
software reuse working groups report.Software Engineering Notes,
18(2):74-85, April 1993.

[GW94]  Martin L. Griss and Kevin Wentzel. Hybrid domain-specific kits
for a flexible software factory. In Proceedings of SAC'94, pages 47-52, New
York, New York, March 1994. ACM.

[GW95a] Martin L. Griss and Kevin Wentzel. Hybrid domain-specific kits.
Journal of Software and Systems, September 1995. (To appear.

[GW95b] Martin L. Griss and Marty Wosser. Making reuse work at
hewlett-packard. IEEE Software, 12(1):105-107, January 1995.

[JCJO92]Ivar Jacobson, Magnis Christerson, PatrikJonsson, and Gunnar
Overgaard. Object-Oriented Software Engineering: A Use Case Driven
Approach. Addison-Wesley Publishing Company, 1992. (Revised 4th
printing, 1993).

[JEJ94] Ivar Jacobson, Maria Ericsson, and Agneta Jacobson. The Object
Advantage - Business Process Reengineering with Object Technology.
Addison-Wesley Publishing Company, Menlo Park, CA, 1994. (ISBN 0-201-
42289-1.

[Kan90] Kyo C. Kang. Feature-based domain analysis methodology. In L.
Latour, editor, Third Annual Workshop: Methods & Tools for Reuse.
CASECenter, Syracuse University, University of Maine, June 1990.

[Pit93] Matthew Pittman. Lessons learned in managing object-oriented
development. IEEE Software, 10(1):43-53, January 1993.

[Sim95] Mark A. Simos. Organization domain modelling (odm):
Formalizing the core domain modeling life cycle. In Proceedings of the
Symposium on Software Reuse, April 1995. (To appear.).

[STA93a]STARS. STARSConceptual Framework for Reuse Processes (CFRP):
Volume I - Definition. Technical Report STARS-VC-A018/001/00, Paramax,
October 1993. (Version 3.0 . See also volume II, applications.).

[STA93b]STARS.STARS Conceptual Framework for Reuse Processes (CFRP):
Volume II- Application. Technical Report STARS-VC-A018/002/00,
Paramax, September1993. (Version 1.0 . See also volume I, definition).

4   Biography

Martin L. Griss is a senior Laboratory Scientist at Hewlett-Packard
Laboratories, Palo Alto, where he researches object-oriented reuse and
measurement system kits. As HP's "reuse rabbi,"he led research on
software reuse process, tools and software factories,the creation of an HP
Corporate Reuse program,and the systematic introduction of software
reuse into HP's divisions. He was past director of the Software Technology
Laboratory and has over 20 years in software engineering research. He
was previously associate professor of computer science at the University
of Utah. He has authored numerous papers and reports on software
engineering and reuse, writes a reuse column for the Object Magazine
and is active on several reuse program committees. He has given several
half-day and full-day tutorials on systematic reuse, and object-oriented
reuse. Griss is a frequent invited or keynote speaker at numerous
executive level software symposia and workshops, discussing software
reuse as a strategic software activity.
Enhancing the Use of Domain Analysis

Ernesto Guerrieri

Digital Equipment Corporation
151 Taylor Street, TAY1-2
Littleton, MA 01460
Tel: [phone]
Fax: [phone]
Email: [e-mail]

Abstract

This position paper looks at what can be done to enhance the use of
domain analysis. The position taken is that there is a need to
standardize the representation of domain knowledge and to provide a
mechanism to disseminate this domain knowledge (at least, within the
organization that plans to benefit from domain analysis). This paper
examines several notations (i.e., Technology Books and Design Patterns)
for representing domain knowledge, and the use of the internet and
World Wide Web (WWW)for disseminating the domain knowledge.

Keywords: Software Reuse, Domain Knowledge, Technology Book, Design
Pattern, World Wide Web, WWW, HTML

Workshop Goals: Interact/discuss with others on how to institutionalize
software reuse; Advance software engineering and reuse technology;
Networking.

Working Groups: Domain analysis/engineering, Design guidelines for
reuse, Tools and environments, Reuse handbook

1   Background

Ernesto Guerrieri, while at SofTech, Inc., was the lead designer of the
RAPID (Reusable Ada Products for Information systems Development)
Library Center (RCL) tool utilized by the RAPID Center. He also co-
authored the original domain analysis method utilized within RAPID. He
also developed a domain analysis tool for capturing dynamic, multi-
dimension classification scheme vocabulary. At Digital Equipment
Corporation, he has been involved on several reuse programs as well as
investigating the reuse capabilities of the DECADMIRE product,a Rapid
Application Development (RAD)environment. Currently, he is looking
into how to introduce, unobtrusively, reuse concepts as a normal part of
the software engineering processes.

2   Position

In order to maximize the benefits of reuse, an organization needs to
embrace the concept and methods of domain analysis. This is usually
avoided due to the commitment, cost, and effort needed to perform
domain analysis. Unless we address these issues, we will continue to
narrow the scope of reuse to code and avoid benefiting from domain
analysis. How can we address and eliminate these issues? Maybe we can't
eliminate them, but, instead, incorporate some of the steps as part of
other processes that are being performed currently.

Futhermore, there have been technological advancements that have
changed how developers do their job. One such area is the information
superhighway. Another is the introduction of Design Patterns in the
Object-Oriented community. How can these simplify, enhance, or
promote the use of domain analysis?

The combination of the solutions to the above issues should help
enhance the benefits of reuse and the incorporation of reuse as a part of
the software engineering processes.

2.1  Where is the domain knowledge?

If we look at the people involved in a typical development project, we
see that  we have brought together, at appropriate times, experts from
different areas to cover different facets of the project (such as Graphical
User Interface (GUI) designers, testers, database programmers, architects,
quality assurance, project planner, etc.). Some of these expertise will be
embodied in a single individual (as if wearing multiple hats). This is
similar to the situation in house construction where one employs
electricians, plumbers, carpenters, brick layers, landscapers,interior
decorators, architects, etc. These individuals bring onto the project their
tools of their trade, their expertise, their knowledge of their domain.

As these people move from project to project,a project gains and looses
these expertise unless some of it is captured as part of the project (i.e.,
the requirement document,the design document, the development or
test plan,etc.). What is captured by the project is only an instance (or
minute piece) of the expertise of the experts that is relevant or pertinent
to the project. On the other hand, these experts draw on their knowledge
of their domain in order to provide their expertise on a given project.

Consequently, we have:

Project Domain Knowledge: This is knowledge about the development
project.It may be for a single project or for a family of similar or related
development projects.

Expertise Domain Knowledge: This is knowledge about a specific expertise
required by a development project. Note that this may include project
domain knowledge of similar or related projects.

Either type of knowledge may be vertical or horizontal depending on the
applicability of the knowledge.

How can we capture and represent these types of domain knowledge?

2.2  How is the domain knowledge represented?

Arango in [1] provides a comparative survey of published domain
analysis methods. The survey also provides a common domain analysis
process, but it does not explicitly define what is the representation of the
domain knowledge (i.e., the output from the process). Is the
classification and the data analysis modeling output the only
representation of the domain knowledge? What role does the raw data
play? What about the filtered, clarified, abstracted, and organized data?
What about the similarities and variations among applications and
systems and their relevance?

Arango describes in [2] the concept of a Technology Book as a means for
capturing design information and the domain analysis. The semantic
tags for the Technology Book include:
]
Issue

Definition

Assumption

Imported constraint

Exported constraint

Position

Design decision

Unresolved

Result

Recently, Patterns has shifted the reuse focus from code reuse to design
reuse. Under the realization that "the reason there are reoccuring
solutions is because there are reocurring problems. "A pattern is therefore
a solution to a problem in a context and are described using a form that
points out the solution, problem, and context. In [3], a Design Pattern is
a description of communicating objects and classes that are customized
to solve a general design problem in a particular context. A design
pattern keyword template used in [3] includes the following sections:

Also Known As

Motivation

Applicability

Structure

Participants

Collaborations

Consequences

Implementation

Sample Code

Known Uses

Related Patterns

Coplien in [4] utilizes the following pattern template:

Problem:

Context:

Forces:

Solution:

Resulting Context:

Design Rationale:

Whereas, the Portland Form collects and connects pattern paragraphs in
a narrative form [5]. Other pattern templates notations exist and can be
found at http://st-www.cs.uiuc.edu/users/patterns/patterns.html.  Some
examples of actual patterns are also available at this URL.

These are only a few of the possible representations for domain
knowledge. What are the advantages and disadvantages of these different
representations? Do they encompass the various aspects of domain
knowledge? How can we achieve a common representation of domain
knowledge?

2.3  How is the domain knowledge disseminated?

Today, a World Wide Web browser (such as Mosaic or Netscape) is a
constantly open icon on my workstation and represents a common
interface for accessing, among other things, documents and software that
resides locally or across the world. The homepage (.html file) represents
a set of knowledge (or references to knowledge) that are co-located based
on some relationship (i.e., person's interest,subject focus, etc.). The
concept of homepage could be used to contain domain knowledge in
some structured fashion that can be widely accessible in a read-on
 ly manner.

The technology books currently exist in a computing environment
consisting of an object-oriented database, a modeling language, a user
interface, and other ancillary tools. Currently, the design patterns exist
in publications or in text files accessible over the internet.

If we combine such tools with a standardized notation for the domain
knowledge, we would be able to disseminate within the organization and
facilitate design reuse. Are today's tools sufficient? Do we need to
standardize the notation forthe domain knowledge? Can we build on the
notations that are being proposed/utilized in communities such as the
patterns community?

3   Comparison

Other related approaches that may contribute or be relevant to this
topic are:

The Domain-Specific Kits [6, 7]

The 3C Model [8, 9, 10, 11]

The Domain-Specifoc Software Architectures (DSSA) [12,13, 14]

References

 [1]G. Arango, "Domain Analysis Methods," in Software Reusability,
pp.17-49, London, UK: Ellis Horwood, 1994.

 [2]G. Arango, E. Schoen, and R. Pettengill, "Design as Evolution and
Reuse," in Advances in Software Reuse - Selected Papers from the Second
International Workshop on Software Reusability, (Los Alamitos, CA), pp.
9-18, IEEE Computer Society Press, 1993.

 [3]E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns:
Elements of Reusable Object-Oriented Software. Addison Wesley, 1994.

 [4]J. O. Coplien,"A Development Process Generative Pattern Language,"in
Proceedings of PLoP/94 (First Annual Conference on Pattern Languages of
Programming),1994. (Also available via www address
http://www.research.att.com:80/orgs/ssr/people/cope/Patterns/Process/i
ndex. html).

 [5]P.Group, Portland Pattern Repository Homepage.  1995.  (Also
available via www address http://c2.com/ppr/index.html).

 [6]M. L. Griss, "Bus-Based Kits for Reusable Software," in Proceedings of
WISR-4, 1991.  (Also available via www address
ftp://gandalf.umcs.maine.edu/pub/WISR/wisr4/proceedings/ps/griss.ps).

 [7]M. L. Griss,"Towards Tools and Languages for HybridDomain-Specific
Kits," in Proceedings of WISR-6, 1993. (Also available via www address
ftp://gandalf.umcs.maine.edu/pub/WISR/wisr6/proceedings/ps/griss.ps).

 [8]S. Edwards,"The 3C Model of reusable Software Components," in
Proceedings of the Third Annual Workshop: Methods and Tools for Reuse,
1990.

 [9]W. Tracz, "The Three Cons of Software Reuse," in Proceedings of the
Third Annual Workshop: Methods and Tools for Reuse, (Syracuse, N.Y.),
June 1990.

[10]L. Latour and C. Meadow,  "Scaling Up the3Cs Model - A  Schema for
Extensible Generic Architectures," in Proceedings of WISR-4, 1991.  (Also
available via www address
ftp://gandalf.umcs.maine.edu/pub/WISR/wisr4/proceedings/ps/latour.ps
).

[11]M. Sitaraman, "A Uniform Treatment of Reusability of  Software
Engineering Assets," in Proceedings of WISR-5, 1992.  (Also available via
www address
ftp://gandalf.umcs.maine.edu/pub/WISR/wisr5/proceedings/ps/sitarama
n.ps).

[12]W. Tracz and L. Coglianese, "An outline for a Domain Specific
Software Architecture Engineering Process,"in Proceedings of WISR-4, 1991.
(Also available via www address
ftp://gandalf.umcs.maine.edu/pub/WISR/wisr4/proceedings/ps/tracz.ps)

[13]W.  Tracz  and  L.  Coglianese,  "A  CASE  for  Domain-Specific
Software Architectures,"  in Proceedings  of  WISR-5,  1992. (Also
available via www address
ftp://gandalf.umcs.maine.edu/pub/WISR/wisr5/proceedings/ps/tracz.ps)

[14]W.  Tracz,  S.  Shafer,  and  L.  Coglianese,  "Design  Records:   A Way
to  Organize  Domain  Knowledge,"  in  Proceedings  of  WISR-6,  1993.
(Also  available  via
ftp://gandalf.umcs.maine.edu/pub/WISR/wisr6/proceedings/ps/tracz3.ps
).

4   Biography

Ernesto Guerrieri is a principal software engineer at Digital Equipment
Corporation. He is the project leader of Digital's ACMSxp transaction pro
cessing system and the team leader of Digital's DECADMIRE application
development environment. He wasinvolved in Digital's corporate reuse
initiatives. He is also an Adjunct Associate Professor in the Software
Engineering program at Boston University. He was previously at SofTech,
Inc. where he led the development of the RAPID (Reusable Ada Packages
for Information system Development) Center Library (RCL). He received a
Ph.D. in Electrical, Computer, and Systems Engineering from Rensselaer
Polytechnic Institute in 1989.
Accelerating Successful Reuse Through the Domain Lifecycle

Scott Henninger

Department of Computer Science & Engineering
115 Ferguson Hall, CC 0115
University of Nebraska-Lincoln
Lincoln, NE  68588-0115
Tel:  [phone]
Fax:  [phone]
Email: [e-mail]

Abstract

The inability of software reuse to reach its full potential lies partially
in the product-centric way in which we view software development.
Methods are needed that help us reason about product families and
degrees of support that can be offered for problem domains.  Domain
analysis techniques help, but often far too concerned with creating
rules for domain inclusion and exclusion.  We have been working on
techniques that take a slightly different view of how increasing
levels of formality can be provided as a domain matures.  We call
this process a domain lifecycle in which knowledge evolves from
isolated problem solving instances to domain abstractions such as
models, guidelines, and checklists, to design environments that
automate significant parts of development within the domain.  We
are developing these techniques through empirical investigations of a
software development.  Currently we are in the process of
demonstrating and refining our ideas by constructing prototypes
using case-based technology to create an organizational memory for
software development practices in the organization.

Keywords:  organizational memory, domain analysis, domain-specific
software, case-based reasoning
Working Groups:  Domain analysis/engineering, Tools and
environments, Reuse process models

1  Background
My involvement in software reuse began with my dissertation which
investigated methods for creating and using repositories of reusable
components.  The major focus of this work was with CodeFinder
which supported the process of query construction and using a
connectionist-based spreading activation method for retrieval.
Empirical work with this system and subsequent involvement with a
large development organization convinced me that repository
systems are the least of the problems in software reuse.  Current
research, briefly described in this position paper, is focusing on a
process in which organizations can develop domain-oriented reusable
environments using case-based technology and domain analysis
methods.  This work is being both developed and verified through a
collaborative effort with industry.

2  Position:  An Organizational Learning Approach to Software
Development
There is a growing consensus that most successful reuse efforts have
been achieved using collections of components within well-defined
and well-understood domains.  Recognizing the importance of domain
knowledge to the development process, domain analysis techniques
have been designed to systematically identify objects and
relationships of a class of systems [2,8].  These techniques have been
shown to be useful, but suffer from defining the domain too
restrictively, burying important relationships deep in domain
taxonomies or rules of inclusion and exclusion, prohibiting flexible
identification of domains with common issues.
Another issue is that domain analysis methods have been most
successfully applied to mature domains.  Biggerstaff's rules of three
states that unless three real systems have been built in the domain,
it is unlikely that the details required for successful reuse can be
derived [10].  In many ways this is unfortunate as we are providing
the largest degree of support for those problems that require the
least amount of support.  If the domain is mature, then people with
the background and experience for the problem exist, reducing the
need for sophisticated support models.  A potentially larger return
on investment lies in support for problems that have not yet
matured, but for which some isolated solutions have been explored.
Software development and reuse support is therefore needed for
both mature and evolving domains.  Our approach is to provide the
means to support a domain lifecycle in which appropriate levels of
support is provided as a domain matures from a couple of isolated
instances to a well-understood domain with well-defined bounds.
This process is supported with case-based tools that capture problem
solving experiences within an organization to identify specific
solutions to problems faced by software developers throughout the
development lifecycle.  As experiences accumulate, the organization
collectively learns about the domains so people can begin to build a
culture based on success, avoid duplicate efforts, and avoid repeating
mistakes.  This defines an organizational learning approach to
software development [7] that naturally incorporates reuse into the
product and domain lifecycles.
Figure 1 depicts how an organizational learning approach to software
development supports the domain lifecycle.  As frequently
encountered problem domains mature from novel problems to
repeated problems to a fully mature domain, support is provided in
increasing levels of automation.  CASE tools supporting the three
main steps in the domain lifecycle are identified:
Ñ    A case-based repository collects experiences from individual
projects, tool experiences, and other artifacts generated to support
the development infrastructure of the organization.  Project
experiences and design artifacts are collected through a process of
issue management and design rationale that describes the problems
that are addressed while creating an application.  Tool experiences
are how-to advice and descriptions of problems encountered while
developers are using a tool to develop software.  This provides
solutions to organization-specific problems that are not found in
manuals.  Reusable artifacts can be in the form of procedures for
approaching a problem (process models), software modules,
specifications, requirement documents, algorithms, designs, test
suites, and other items generated in the course of a project.
Ñ    Domain abstractions are domain-specific models of design
problems, including domain models, design guidelines, value-added
reusable artifacts, domain-specific handbooks, process models, design
checklists, and other forms of knowledge.  Domain-specific
knowledge is created by a domain analyst refining knowledge
contained in the case-based repository into forms that are more
generally applicable to problems frequently encountered in the
organization.
Ñ    Domain-specific design environments automate or provide
knowledge-based support for the development of systems within a
well-established domain.  The environments are created by tool
designers using accumulated knowledge from the domain models and
specific cases and reusable artifacts in the case-based repository.


Figure 1:  Organizational Learning Support for the Domain Lifecycle.
These steps define increasing levels of automation and support
mirroring the maturity of the domains.  Problems that have yet to be
analyzed are supported by searching for similar problems in a case-
based repository of project and tool experiences.  The cases will
contain information that is specific to the original project and may
need work to apply to the current context, but at least there are
some prior experiences to help guide design decisions.  As activities
are repeated, case-based technology is employed to identify
recurring development issues and support the process of generalizing
from individual cases to domain-specific abstractions such as design
guidelines, domain models and other formal structures.  Using
handbooks, guidelines, and domain models provides a higher level of
support as the knowledge has been processed by domain analysts
into a form that is applicable to general problems in the domain.  As
the domain matures, tool designers can use the synthesized
knowledge and components to construct design environments that
automate design and provide intelligent support for mature domains
repeatedly encountered in the organization.
2.1  Support for Formal Domain Analysis
While using a case-based approach to software reuse can provide a
degree of reusability leverage [6], the main problem is that cases
tend to represent isolated problems that need to be adopted from
one set of specifics to another.  Domain analysis methods are needed
to generalize the knowledge into a more widely applicable form.
This is precisely where organizational learning comes in.  The process
of synthesizing similar cases into knowledge that is applicable to a
class of problems naturally supports the maturation of domain
knowledge.  The real issue of domain analysis is to find commonalties
among systems to facilitate reusing software or other design
artifacts.  From this perspective, domain analysis is a process of
identifying commonly occurring patterns across a number of
development efforts.  As patterns emerge, top-down domain analysis
methods can be used to formalize the patterns, facilitating domain
evolution from the identification of isolated patterns to formally
defined domain knowledge.  Identifying established patterns of
effort reduces the risk of costly domain analysis efforts by ensuring
that the cost of analysis can be amortized over many uses.
The case-based repository supports this process by allowing users to
query the repository to get a comprehensive picture of the issues
and approaches used to solve problems in the domain [7].  For
example, suppose an organization has a number of projects that have
begun to struggle with issues of backup and recovery in a client-
server architecture.  The analyst begins by querying the system with
terms such as ╥backup╙ and ╥recovery╙, finding characteristics such
as ╥Automatic backup╙, ╥File backup╙, Disaster recovery╙, ╥Backup
scheduling╙, ╥Update frequency╙ and others.  Given this information,
the analyst begins to construct facets [8] to help understand the
domain and organize the software artifacts that have accumulated
about backup and recovery issues.  The repository provides a
comprehensive and convenient mechanism for performing the
analysis.  It is precisely this kind of support for domain analysis that
is necessary to provide the kind of reference handbooks that other
engineering domain have benefited from.
2.2  Issue Tracking
Since we are advocating that the mapping from problems to tools
must be dynamically maintained to meet the changing needs of an
organization, capturing project experiences is a crucial element of our
approach.  The system must quickly reach a critical mass of
information to become an invaluable part of the design process and
maintain that usefulness by evolving with the changing needs of the
organization.  We are in the process of developing tools to support an
issue tracking methodology to monitor major issues and subproblems
that arise in the course of the project that may have implications for
subsequent projects.  By integrating our efforts at the organizational
and project levels, we hope to achieve a ╥living design memory╙ [9]
that emphasizes the development of domain knowledge, not just
capturing or acquiring what already exists.
2.3  Conclusions and Future Directions
Centering the information around a single repository through an
ongoing process of capturing project experiences can prevent the
duplication of efforts, avoid repeating common mistakes, and help
streamline the development process.  Similar projects have shown
that such a system will be used by development personnel, provided
it contains relevant, useful and up-to-date information [9].
A key question that exists for our work as well as work in the areas
of domain analysis, design rationale, and organizational memory, is
how the process of generating and using repositories of design
information can be embedded in the everyday practice of software
development so that the repository evolves with the ever-changing
goals and accomplishments of the organization [9].  Our approach
advocates using the repository to both track project progress and as
an information resources to support design and decision making.
Much more work is needed to accomplish this goal.  We are
approaching this problem in a user-centered or participatory design
method in which we deploy prototypes to collect feedback and refine
our model to fit the organization╒s needs.  Successful deployment of
this system will not only help the software development process at
UPRR, but will provide a crucial first step toward better
understanding the software development process and how it can be
improved.
3  Comparison
Our work applies techniques from artificial intelligence and human-
computer interaction to software engineering problems.  In many
respects our approach operationalizes the domain analysis
prescription to identify reusable information in the problem domain,
capture relevant information, and evolve the information to meet
current needs [2].  Efforts in the software reuse community,
especially experience factories [4] have similar concerns, although
the focus is often exclusively on re-using source code.  We wish to
take a broader view to include any significant development issue.
For example, one project at UPRR performed a study of screen
ergonomics.  While the project was eventually canceled, the screen
ergonomics report is highly regarded and has been used by other
projects.  Our objective is to provide a formalized process by which
such artifacts can be identified and disseminated for widespread use.
Design rationale techniques, which advocate a process of deliberation
in which design decisions are reached by consulting the design issues
an alternatives stored in a repository [5], have also had a significant
impact on our approach.  Our goal will be not only to capture the
rationale of why a system was designed a certain way, but also what
occurred as a result of the decision, and how future efforts of a
similar nature can be improved.
The closest efforts to ours have focused on creating corporate
repositories, often referred to as organizational memory.  Answer
Garden [1] was built to capture recurring questions in a central
database using a branching network of multiple-choice questions and
answers.  The Designer Assistant integrated a repository with
existing practices in a development organization at AT&T [9].  This
strategy not only ensured that Designer Assistant was used, but also
that it was modified as part of the development process, allowing it
to evolve with changing organization needs.  The primary difference
is that our approach uses a repository of cases, whereas the Designer
Assistant and Answer Garden are structured as an advice-giving
systems.  Part of the output of a domain analysis could be a
structured set of questions leading to a piece of advice, but putting
the knowledge in that form is labor-intensive, and it has been noted
that some users prefer a more open-ended mode of interaction,
especially when users want to find information on a subject area [9].
References
[1]    Ackerman, M.S., Malone, T.W., ╥Answer Garden:  A tool for
growing organizational memory╙, Proceedings of the Conference on
Office Information Systems, ACM, New York, 1990, pp. 31-39.
[2]    Arango, G., Domain Analysis: From Art Form to Engineering
Discipline, Proceedings Fifth International Workshop on Software
Specification and Design, (Pittsburgh, PA), ACM, pp. 152-159, 1989.
[3]    Arango, G. and Prieto-Diaz, R. Domain Analysis software system
modeling, IEEE Computer Society Press,  Los Alamos, CA, 1991.
[4]    Caldiera, G., Basili, V.R., ╥Identifying and Qualifying Reusable
Software Components╙, Computer, 24(2), Feb. 1991, pp. 61-70.
[5]    Fischer, G., Lemke, A.C., McCall, R. and Morch, A.╥Making
Argumentation Serve Design╙, Human-Computer Interaction, 6(3-4),
1991, pp. 393-419.
[6]    Fouque, G., Matwin, S. ╥A Case-Based Approach to Software
Reuse,╙ Journal of Intelligent Information Systems, 1, 1993, pp. 165-
197.
[7]    Henninger, S., Lappala, K., Raghavendran, A., ╥An Organizational
Learning Approach to Domain Analysis,╙ Seventeenth International
Conference on Software Engineering (Seattle, WA), ACM, IEEE, Los
Alamitos, CA, pp. 95-104, 1995.
[8]    Prieto-Diaz, R. ╥Implementing Faceted Classification for
Software Reuse,╙ Communications of the ACM, 35(5), May 1991.
[9]    Terveen, L.G., Selfridge, P.G., Long, M.D., ╥╘Living Design
Memory╒ - Framework, Implementation, Lessons Learned,╙ Human-
Computer Interaction, 1995 (in press).
[10]Tracz, W. Confessions of a Used Program Salesman:
Institutionalizing Software Reuse, Addison Wesley, Reading, MA,
1995.

Software Reuse - it's TEA - time!

Elke Hochmuller

Institut fur Informatik
Universitat Klagenfurt
Universitatsstr.65-67
A-9020 Klagenfurt, AUSTRIA
Tel: ++43463 2700 574
Email: [e-mail]

Abstract

Using CASE environments and utilizing software reuse are seen as
promising and mandatory means to enhance software productivity.
Unfortunately, with current technology, the combination of software
reuse and CASE environments is hardly supported. On the basis of this
observation, this position paper presents some criteria which can be
useful in evaluation and assessment of tools and environments
pretending to support software reuse.

Keywords: tool evaluation, reuse process model, institutionalizing reuse

Workshop Goals: Networking and exchanging ideas; common problem
understanding; learning about reuse experiences in practice.

Working Groups: tools and environments, reuse process models, reuse
management, organization and economics.

[TEA - Tool Evaluation and Assessment]

1   Background

Elke Hochmuller is assistant professor at the University of Klagenfurt. She
is member of Roland Mittermeir's research group which is particularly
concerned with software reuse.  Based on the software base approach, she
developed the concept for AUGUSTA- a reuse-oriented software
engineering environment for the development of Ada applications [1].
Furthermore, her Ph.D. thesis [2] contained some initial thoughts on
ideal process models as well as organizational structures of reuse-
oriented software developing companies.

In [3] E. Hochmuller and R. Mittermeir propose a reuse augmentation to
traditional process models requiring only minimal changes to an already
implemented and approved software development process (Figure 1).
This reuse process model can be considered as a meta model which can
be refined according to the particular needs of each enterprise.
Furthermore,it is rather independent of the software development
process model applied so far. Thus, a software developing enterprise
need not change all its approved methods and processes, but only enrich
its applied development process together with some inevitable changes
inits organizational structure (e.g. software library, software library
administrator). The suggested reuse process model consists of two main
subprocesses which are linked together in a "ping-pong" manner. The
first subprocess deals with the development of reusable components
according to development for reuse (DfR). These components are used
within the second subprocess which deals with (system) development
with reuse (DwR).

Figure 1: Reuse Process Model (not in text-only form)

2   Position

Software reuse cannot be institutionalized by a very radical change in
traditional software development. The integration of software reuse into
current organizational as well as process structures should take place
smoothly. On the one hand, already approved software process models
should not be thrown away but be enriched by planned software reuse.
On the other hand,this should also be true for already well known and
applied CASE tools. Thus, CASE tool vendors should focus on reuse
requirements and adopt their tools accordingly. Hence, without
demanding for completeness the following criteria (mainly resulting
from the reuse process model previously presented) are proposed to be
considered while evaluating tools regarding to their support of reuse.

1.Component Reuse

Most CASE tools implement a phase driven, forward looking development
model. Software development with reuse, however, is all but that linear.
It follows rather a "Yoyo"-approach, where design sketches are followed
by delving into the library of reusable components, evaluating some
candidate components and then solidifying the high level sketches
according to the already available integrable components. On the other
hand,one should also consider development for reuse. This has many
facets. Be it,that the development of highly generic, off-the-shelf
components is promoted, or be it that the isolation of reusable
components out of conventionally developed applications is supported.

2.Central Software Library

A central software library containing software components of high reuse
potential is an essential part of a reuse supporting CASE environment.
While a common repository, which is a prerequisite for any integrated
software engineering environment, will contain anything which has been
produced during a particular development project, this software library
should only contain components of approved quality with high
potential for interproject reuse.

3.Software Library Administrator

The CASE environment should support a new user role for the
administration of the software library. This task could be fulfilled by a
software library administrator whose competence, however, should
exceed pure administrative activities.  This person should particularly be
responsible for the certification, classification and maintenance of
software components. It is expected from a CASE tool to support the
software librarian in the relevant activities.

4.Component Certification

The inclusion of every software document into the software library
without any checks would soon flood the library with components of
little potential for reuse. Frustration of users of this library will be the
consequence. To cope with this problem, a reuse library should provide
clues on qualitative properties of components. The process of component
certification could be a single-step activity or a rather sophisticated
process depending on the specific situation of the development
organization. In any case though,the certification of the candidate
components should be supported by the CASE environment.

5.Retrieval Support and Classification Scheme

It is required from a reuse supporting CASE environment to provide best
automation of both storage and retrieval of components. In order to find
specific components contained in the software library quickly and with
acceptable effort, the software documents should be classified when they
are stored. Therefore, an adequate classification structure is necessary.


6.Adaptation Support

In case a software component which is only similar to the desired one
could be identified during a search process, a CASE tool is expected to
support the process of adaptation of such a component in order to fulfil
precisely the specification demanded. While these modifications might
encompass functional aspects as well as qualitative aspects, one might
also consider those modifications, where the internals of a
componentwould be adequate, but modifications have to be made to the
interface in order to integrate it into the application under
development.

 7.Testbeds and Instrumentation

Since component descriptions, how formal they ever might be, can
naturally not cover all aspects which might be decisive for using a
component in a new development project, a reuse supporting CASE tool
should provide for testbeds, such that retrieved candidate components
can be easily tested in isolation. In special cases,instrumentation of
components for testing specific aspects might be desirable.

8.Integration Support

After successful retrieval and adaptation of software components, they
have to be glued together in order to achieve a complete software
system. This integration of components should also be supported by the
environment. With this integration support, one has usually to
distinguish between prototype development and the more stringent
requirements for the integration of production-quality versions.

9.Maintenance Propagation

The requirement of maintenance propagation can be viewed from two
perspectives:

Vertical Maintenance Propagation

During its development process a software component passes different
stages of representation (from specification document to object code). In
addition to the need of storing all these different documents, a reuse
supporting CASE tool should provide for automatic update of all the
different representations if a particular component is changed.

Horizontal Maintenance Propagation

A reuse supporting CASE environment should also provide the possibility
to establish links between different software components of usually also
different kinds of representation.  These links should not only support
the user in navigating between related components (which would again
be another general requirementfor CASE tools) but also enable the
propagation of operations applied to a particular software component
triggering adequate operations on related components.

10.Reuse Success Evaluation

Continuous control of the reuse success can help not only the software
library administrator to react in time to reorganize the contents of the
library. It also assists potential users, which might build their estimates
on the benefit of reusing a particular component on the past "turnover"
of this component. Furthermore, management might use such statist cs
to reward project personnel for successful reuse or to encourage better
reuse by establishing specific reuse incentives. Most necessary data can
be easily collected and made available by the tool itself.

3   Comparison

A whole bunch of general requirements for CASE tools and environments
has been proposed in the literature (e.g. [4]). Full life cycle support,
integrated CASE, multiuser and teamwork support, consistency and
integrity support,evaluation support, versioning, and management
support are only some of the most important criteria in this connection.

However,as far as I know there have been no proposals covering specific
criteria for CASE environments which focus particularly on reuse aspects
in software engineering. The items presented here are far from being
complete or detailed enough but are an excellent starting point for
further research in this area. Regarding the nature of these
requirements,they rather refer to entire CASE environments in the sense
of [5] than to single CASE tools. Furthermore, the scope of the evaluation
criteria presented here lies beyond thatof evaluation requirements
tailored to reuse-specific tools (e.g. the evaluationof SoftKin [6] as a
reuse supporting tool detecting similarities at code level).

References

[1]E. Hochmuller,"Process support for software reuse with AUGUSTA," in
Proc. Software Systems in Engineering, (Houston), pp. 173-181, ASME, Jan.
1995.

[2]E.Hochmuller, AUGUSTA - eine reuse-orientierte Software-
Entwicklungsumgebung zur Erstel-lung von Ada-Applikationen. PhD
thesis, Universitat Wien, May 1992.

[3]E. Hochmuller and R. Mittermeir, "Improving the software
development process by planned software reuse,"in Proc. Re-Technologies
for Information Systems (ReTIS '95) (J. Gy|rk|s, M. Krisper, and H. C.
Mayr, eds.), (Bled, Slovenia), pp. 27-39, OCG, June 1995.

[4]A. duPlessis,"A method for case tool evaluation," Information &
Management, vol. 25, pp. 93-102, Aug. 1993.

[5]A. W. Brown,"Why evaluating case environments is different from
evaluating case tools," in Proc. Third Symposium on Assessment of
Quality Software DevelopmentTools (E. Nahouraii, ed.), (Washington,
DC), pp. 4-13, IEEE, June 1994.

[6]G. W. Hislop, "Evaluating a software reuse tool," in Proc. Third
Symposium on Assessment of Quality Software Development Tools (E.
Nahouraii, ed.), (Washington, DC), pp. 184-190, IEEE, June 1994.

4   Biography

ElkeHochmuller is assistant professor at the Department of Informatics,
University of Klagenfurt, Austria. She received her M.S. and Ph.D. degrees
from the University of Vienna in 1988 and 1992, respectively. In 1994
she left the University of Klagenfurt for halfa year and developed an
enterprise wide data model for an electric power supply company where
she became aware of the very intricate managerial, social as well as
psychological problems in practice which increased her interest in
bridging the gap between research and practice. Her research interests
cover various topics in the field of software engineering, particularly
software reuse, process modelling, CASE, and requirements engineering.
One Architecture Does Not Fit All: Micro-Architecture Is As Important As
Macro-Architecture

Joseph E. Hollingsworth

Department of Computer Science
Indiana University Southeast
New Albany, IN 47150
Tel: [phone]
Fax: [phone]
Email: [e-mail]

Bruce W. Weide

Department of Computer and Information Science
The Ohio State University
Columbus, OH 43210
Tel: [phone]
Fax: [phone]
Email: [e-mail]

Abstract

The field of study recently dubbed "software architecture" should be
split into two sub-areas: micro-architecture and macro-architecture.
Work to date under the name software architecture has concentrated
primarily on macro-architecture. But micro-architecture, a.k.a. software
component engineering, is at least of equal concern.

Keywords: Component engineering, interface design, interface
specification, patterns, software architecture

Workshop Goals: Learning, networking, discussing/debating technical
issues related to reuse

Working Groups: Reuse and formal methods, reuse and OO methods,
reusable component certification, design guidelines for reuse, education

1   Background

Economists discovered some time ago that one view of economics cannot
be made to fit all economic situations. They noticed that different
analytical techniques and models were needed when looking at
economics-in-the-small as compared to economics-in-the-large [1]. This
is not to say that one is more important than the other, or that one
deserves more or less attention. It simply admits that the understanding
and analysis of these two different classes of economic situations require
different approaches in order to capture and reason about their
fundamental properties.

Software engineers - especially those who subscribe to software
component reuse - know that software, like hardware, has (or should
have) an orderly arrangement of parts, or an "architecture" [2,3 ,4 ]. To
date, most work on software architecture has focused on exploring a
high-level view of the ways in which large systems are organized, e.g.,
domain-specific software architecture (DSSA).

2   Position

We contend that software engineers are faced with a situation similar to
that faced previously by economists: One view of software architecture
cannot be made to fit all situations. Our position is that a useful
approach to sort out the issues is to recognize a dichotomy in software
architecture like the one in economics - to separate what we wish to call
micro-architecture from macro-architecture. As with economics, this
recognition does not imply that one kind is more important than the
other, or that one deserves more or less attention. It simply admits that
the understanding and analysis of qualitatively different software
architecture situations require different approaches in order to capture
and reason about fundamental properties.

2.1  Macro-Architecturevs. Micro-Architecture

Most work in software architecture to date is what we call macro-
architecture, because it deals with a high-level view of software systems
and not with the detailed structure of the components in those systems,
much less their detailed behavior. What comprises (or should comprise)
work in micro-architecture? Micro-architecture is not synonymous with
programming-in-the-small,i.e., with statement-level issues such as the
use of structured programming techniques [5]. It also is not synonymous
with what have become known as "design patterns" [6], i.e., with
identifying, classifying, and explaining commonly-used program
structuring techniques in problem contexts.  Like the work on patterns,
micro-architecture deals with important issues between the high-level
view of software system architecture and low-level coding. But it focuses
on the details of both the structure and the behavior of component
interfaces and on the implementations of individual components, sets of
components, and how they compose and "interoperate" with each other.

At the macro-architecture level,a large system might be deemed to follow
a general structural style, e.g., "hierarchical layering of abstract data
type components". There might be some interesting things that can be
concluded about a system by knowing just this much - or perhaps a
little more - about it. But there are other interesting things about the
system that can be understood only by taking a more careful view of the
details, to ascertain precisely what design decisions have made it
possible to construct a system with a certain macro-architecture, and to
understand why components are interconnectable both structurally and
behaviorally.

2.2  Some Issues in Micro-Architecture

Micro-architecture,a.k.a. software component engineering, covers many
important issues, including but not limited to the following:

What are the best ways to achieve component composability and
interoperability, i.e., the composition of components with little or no
"glue code"? How can a component's structure and behavior be designed
so the composition restrictions it places on other components, and vice
versa, are likely to be met [7]?

What are the best ways to design a component so that certifying that it
possesses certain properties can be done just one time, i.e., when it is
checked into a component library, instead of each time it is checked out
and used in a client program [8, 9]?

What are the best ways to achieve plug-compatibility between multiple
implementations for the same abstract component, i.e., so that a client
program requires little or no modification when unplugging one
implementation and plugging in another [10]?

What component-related programming language features are needed to
best support multiple, different implementations for the same abstract
component [11, 12]?

What are the best ways to design a component so that client
programmers have control over the component's performance, i.e., can
easily tune the component with respect to space and time usage, without
changing functionality [9]?

Given a particular programming language (e.g., Ada, C++, Eiffel, ML)
which language features should be aggressively used - and which should
be avoided - when designing components to be composable, certifiable,
efficient, reusable, tunable, etc.? For example, what are the best ways to
use the enticing language mechanism of inheritance [13]?

The notion that some language features should be used, while others
should not, leads to the conclusion that even an individual software
component has architectural characteristics; and that groups of
components that are designed to be readily composable with each other
share a micro-architecture.

Here is a simple example of a very low-level micro-architecture issue. It is
well known that one of the easiest mistakes to make during the
development of code is to use a variable that has not been initialized.
Many compilers try to detect this situation and issue a warning; there
also are commercial tools that look for and warn against it (e.g., Purify).
But warnings are reactive. Languages such as C++ with its constructor
and destructor operations, and Ada95 with initialization and
finalization operations [14], permit a component designer to take a
proactive approach to this problem. Therefore, part of the micro-
architecture of a component (or group of components) in C++, for
example, lies in the consistency of use of constructor and destructor
operations.

3   Comparison

By comparison to previous adhoc work in macro-architecture and micro-
architecture,we see at least three comparative advantages to studying
software micro-architecture as an explicit question: possible development
of new programming language constructs that support a particular
micro-architecture; possible component design disciplines that
specifically prescribe which features of a particular language to use (and
howto use them), and which to avoid, when designing new components
under a particular micro-architecture; and possible less-restrictive
component design guidelines that convey general approaches to
designing components within micro-architectural families.

3.1  New Language Constructs

The example in the previous section illustrates how language support
can be provided for a micro-architectural solution to the problem
ofuninitialized variables. Advances in micro-architecture will lead to the
need for other language-supported (or language-enforced) mechanisms
that enable the design of high-quality software components [9]. Skeptics
who think the ultimate programming language already exists and that
further work in this direction is pointless should carefully consider the
fine points of debate in the creation ofAda95, an ANSI standard for C++,
Object Oriented COBOL, etc. Most of the suggested language changes
derive directly from micro-architecture considerations. Similarly,much of
the work on specification languages such as Larch, VDM, and Z deals with
the need to clearly and unambiguously specify component behavior. No
 ne of these is the last specification language we will ever need.

3.2  New Component Design Disciplines

Programming languages (at least,widely-used ones) tend to evolve slowly
and in response to well-understood needs of software engineers. While
the community explores micro-architecture issues and develops a clearer
understanding of what language support is appropriate for various
approaches, there is a need for stopgap measures. Component design
disciplines can be prescribed that, when followed, give rise to a specific,
unique, and easily identifiable micro-architecture. For example, the
RESOLVE/Ada discipline [8] includes 41 principles that very specifically
guide the software engineer when designing high-quality Ada
components.

3.3  New Design Guidelines

Design "guidelines" are less explicit than comprehensive design
disciplines. When followed, though, they too can give rise to components
that have easily identifiable micro-architectures. Some examples include
guidelines suggesting the inclusion of component iterators and how to
design them [15,16]; and the idea of recasting algorithms (e.g., sorting)
as "machines" (e.g., a sorting machine component) [17].

3.4  Conclusion

To advance the ill-defined but intuitively important field now known as
software architecture, we propose that the term be refined so there are
two separate but related subfields: micro-architecture and macro-
architecture. We base our argument on a convenient analogy with the
field of economics, and on the observation that not just large systems
but even much smaller-scale software components have their own
architectural features.  Furthermore, when viewed from this perspective,
we see opportunity for micro-architecture research to contribute to the
design of future programming languages and the individual reusable
components found in common off-the-shelf libraries.

References

 [1]G. Bach, R.Flanagan, J. Howell, L. Ferdinand, and A. Lima, Economics:
Analysis, Decision Making, and Policy. Englewood Cliffs, NJ: Prentice-Hall,
1987.

 [2]D. Garlan and M. Shaw, "An Introduction to Software Architecture,"
in Advances in Software Engineering and Knowledge Engineering, vol. 1
(V. Ambriola and G. Tortora, eds.), World Scientific,1993.

 [3]R. Prieto-Diazand G. Arango, Domain Analysis and Software Systems
Modeling. IEEE Computer Society Press, 1991.

 [4]W. Tracz, S. Shafer, and L. Coglianese, "Design Records: A Way to
Organize Domain Knowledge," in Proceedings 6th Annual Workshop on
Software Reuse, (Owego, NY), 1993.

 [5]F. deRemer and H. Kron, "Programming-in-the-Large vs. Programming-
in-the-Small," IEEE Transactions on Software Engineering, vol. SE-2, pp.
80-86, June 1976.

 [6]E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns:
Elements of Reusable Object-Oriented Software. Reading, MA: Addison-
Wesley,1995.

 [7]S. Edwards,"Common Interface Models for Reusable Software,"
International Journal of SoftwareEngineering and Knowledge Engineering,
vol. 3, pp. 193-206,June 1993.

 [8]J. Hollingsworth, "Software Component Design-for-Reuse: ALanguage
Independent Discipline Applied to Ada," Tech. Rep. OSU-CISRC-1/93-
TR01, The Ohio State University, Columbus, OH,1992.

 [9]M. Sitaraman and B. Weide, "Special Feature: Component-Based
Software Using RESOLVE," Software Engineering Notes, vol. 19, pp. 21-67,
October 1994.

[10]S. Edwards,"An Approach for Constructing Reusable Software
Components in Ada," Tech. Rep. IDA Paper P-2378, Institute for Defense
Analyses, Alexandria, VA, 1990.

[11]M. Sitaraman,"A Class of Programming Language Mechanisms to
Facilitate Multiple Implementations of the Same Specification," in
Proceedings 1992 International Conference on Computer Languages, pp.
272-281, IEEE Computer Society, April 1992.

[12]D. Dori and E.Tatcher, "Selective Multiple Inheritance," IEEE Software,
vol. 11, pp. 77-85, May, 1994.

[13]D. de Champeaux, D.Lea, and P. Faure, Object-Oriented System
Development. Reading, MA: Addison-Wesley, 1993.

[14]Ada95 Reference Manual (version 6.0) and Ada95 Rationale.
Cambridge, MA: Intermetrics, Inc.,1995.

[15]G. Booch, Software Components with Ada. Menlo Park,
CA:Benjamin/Cummings, 1983.

[16]B. Weide, S. Edwards, D. Harms, and D. Lamb, "Design and
Specification of Iterators Using the Swapping Paradigm," IEEE
Transactions on Software Engineering, vol. 20, pp. 631-643, August1994.

[17]B. Weide, W. Ogden, and M. Sitaraman, "Recasting Algorithms to
Encourage Reuse," IEEE Software, vol. 11, pp. 80-88, September 1994.

4   Biography

Joseph E. Hollingsworth is Assistant Professor of Computer Science at
Indiana University Southeast. He holds a B.S. from Indiana University
and an M.S. from Purdue University, and he earned his Ph.D. in
Computer and Information Science in 1992 from The Ohio State
University. Professor Hollingsworth also has substantial industrial
software engineering experience: at Texas Instruments working on a
command and control expert system for the Navy Commander and Chief
of the Pacific Fleet, 1984 to 1986; at Battelle Memorial Institute working
on software maintenance of the Air Force's Mission Planning System
(MSS-II), 1991 to 1992; and through Hollingsworth Solutions, developing
and marketing a number of PC-based and Mac-based software
packages,1987 to present. His latest product is a PC Windows application
developed using the RESOLVE/C++ discipline.

Bruce W. Weide is Associate Professor of Computer and Information
Science at The Ohio State University in Columbus. He received his
B.S.E.E. degree from the University of Toledo and the Ph.D. in Computer
Science from Carnegie Mellon University. He has been at Ohio State since
1978. Professor Weide's research interests include various aspects of
reusable software components and software engineering in general:
software design, formal specification and verification, data structures
and algorithms, and programming language issues. He is co-director of
the Reusable Software Research Group at OSU, which is responsible for the
RESOLVE discipline and language for component-based software. For more
information see the URL http://www.cis.ohio-state.edu/hypertext/rsrg/.

Professor Weide gratefully acknowledges financial support from the
National Science Foundation (grant number CCR-9311702) and the
Advanced Research Projects Agency (contract number F30602-93-C-0243,
monitored by the USAFMateriel Command, Rome Laboratories, ARPA
order number A714).
A Domain Framework: A Basis for Enhancing Reuse Among Domains1
Anh D. Ta

The MITRE Corporation
7525 Colshire Drive, MS-W624
McLean, VA 22102-3481
Tel:  [phone]
Fax:  [phone]
Email:  [e-mail]

Duane W. Hybertson

The MITRE Corporation
7525 Colshire Drive, MS-W624
McLean, VA 22102-3481
Tel:  [phone]
Fax:  [phone]
Email:  [e-mail]

Abstract
The software engineering discipline has matured to the point where
the notion that every new software system has substantially unique
requirements and therefore a unique solution is giving way to the
understanding that software systems within application areas (or
domains) have much in common, and that this commonality can be
exploited.  This perspective is the motivation for domain-specific
reuse (e.g., domain analysis).  But experience in applying domain
analysis indicates that defining and scoping a domain for analysis in
many cases is not straightforward.  Furthermore, there are variations
in focus, terminology, types of models, and representations among
the various methods.  It is also useful to distinguish among types of
domains such as application domains and software technology
domains.  The DoD is interested in a solution that can help define DoD
domains in a way that will identify software commonality across
existing domains and reduce arbitrary duplication.  For these
reasons, a domain framework is proposed that is intended to help
characterize domains and product lines by tapping directly into
existing informal but extensive domain knowledge to identify reuse
opportunities.  Initially, the framework will consist of a preliminary
set of definitions and factors for identifying and scoping domains as a
common front end to domain analysis.

Keywords:  domain-specific reuse, domain analysis methods, domain
framework, product line

Workshop Goals:  Advocate importance of concept of domain
framework;  obtain feedback on preliminary domain framework

Working Groups:  Domain analysis/engineering;  Reuse terminology
standards;  Reuse handbook

1   Background
The authors have been involved in software reuse projects for the
past several years.  A primary area of work has been supporting the
Department of Defense (DoD) Software Reuse Initiative (SRI).  Recent
projects include the DoD SRI Technology Roadmap [2], which is a two-
volume document that identifies critical technologies enabling reuse
and describes an implementation strategy for DoD investment in
immature technologies.  Current tasks in support of DoD SRI include
the development of a domain framework that is the subject of this
paper.  Other current reuse work includes a domain
definition/analysis task for the Navy.

2   Position
The position of this paper is that a domain framework is both needed
and feasible right now.  The two subsections that follow present the
need and a proposed solution, respectively.

2.1  Problem Context and Dimensions
The software engineering discipline has matured to the point where
the notion that every new software system has substantially unique
requirements and therefore a unique solution is giving way to the
understanding that software systems within application areas (or
domains) have much in common, and that this commonality can be
exploited [1; 8].  This understanding has shifted the focus of software
reuse to domain-specific approaches.  There are now multiple
domain analysis / engineering methods available (see [1] and [8]).
Various government R&D programs such as ARPA's Domain-Specific
Software Architectures (DSSA) [3] and STARS demonstration projects
[11], [12], and [13] have been in progress for several years.  In
addition, the integration of the domain-specific reuse approach into
software system development is being realized through several
proposed reuse-driven processes.  Currently, the two life-cycle reuse
process, consisting of Domain Engineering and Application
Engineering (e.g., see [2] or [10]), is emerging as the preferred
process.

Experience in applying domain analysis indicates that defining and
scoping a domain for analysis in many cases is not straightforward.
The scope of a domain or product line is often determined more by
the feasible scope of analysis (e.g., organization resources available)
than by the scope of an existing body of knowledge [14].  Up front
decisions that are made on selecting and bounding a domain can
significantly affect the success of the domain analysis effort and the
return on investment, yet the criteria for making these decisions are
not uniform across the methods and in some cases are addressed
only minimally.  There are many questions and issues that need to
be addressed in terms of the breadth and the maturity of a domain,
such as:

Ñ    A domain can be so ╥wide╙ that it is not homogeneous (i.e., it
has multiple models and architectures) or there are not enough
resources within an organization to analyze it
Ñ    A domain can be so ╥narrow╙ that it does not have a critical
mass of problems to solve (i.e., leverage)
Ñ    A domain can be so volatile that it is not ready for abstractions
such as domain models and architectures to be attempted
Ñ    A domain can be "inactive" in the sense that there is no market
for a domain model or architecture because no future systems are
planned or required.

Furthermore, there are variations in focus, terminology, types of
models, and representations among the various methods.  Hence,
there is a need for a common basis in capturing and conveying
domain information such that it can be used by all stakeholders.
What is needed is the following:

1.    A common basis that provides a ╥level playing field╙ for
identifying and characterizing domains independent of domain
analysis methods
2.    A set of domain identification and scoping criteria or factors
and usage guidelines to apply the factors to selected domains
3.    An inexpensive way to obtain information on reuse potential of
domains, based on available data, to help decide where and when to
invest in domain analysis
4.    A way to obtain information on reuse potential of domains
within an organization or enterprise to help define product lines (or
families of systems)
5.    Criteria for decomposing large domains into appropriate
constituent domains for analysis and acquisition support
6.    Assistance in finding commonality across multiple domains, to
help minimize overlaps and reduce acquisition cost

2.2    Ideas for a Domain Framework as a Solution
Given the objectives stated above, the proposed solution must
possess the following attributes:  (1) be comprehensive in capturing
different perspectives of domains (i.e., degree of generality), (2)
capture common terms or relations among related terms (i.e.,
unifying concepts), and (3) be method independent (i.e., usable with
multiple domain analysis methods).
The DoD is interested in a solution that can help define DoD domains
in a way that will identify software commonality across existing
domains and reduce arbitrary duplication.  MITRE is supporting the
DoD Software Reuse Initiative in developing a domain framework
intended to satisfy the objectives stated above.  Because of the
number and variety of DoD domains, this framework is expected to
have applicability beyond DoD to the software community in general.
The proposed domain framework will initially consist of two major
components:  common definitions of domain-related terms, and
domain identification and scoping factors.  Usage guidelines are also
being developed for the proposed framework to illustrate its
application for the purposes defined above.  A snapshot of the initial
two components is given below.
2.2.1    Common Definitions
In recognizing that various domain analysis methods (with their own
terms and interpretations) will be used in more detailed analysis of
domains, this component of the framework will emphasize capturing
common terms and overlap among terms defined as part of existing
methods.  Eventually, this component is intended to function as a
meta-domain dictionary containing definitions of terms and usage
context.  Preliminary sources for this effort include [1], [8], and [14],
which discuss domain analysis concepts and common themes, and [6]
and [7], which define reuse terms.

Key definitions include the following:

Domain:  A distinct functional area that can be supported by a class
of software systems with similar requirements and capabilities.  A
domain may exist before there are software systems to support it. [6]

Domain Boundary:  A frame of reference for the analysis (i.e., the set
of constraints that representing what is part of the analysis and what
is outside the analysis).  The domain boundary may change as more
knowledge about the domain is gathered. [9p37]

Product Line:  A collection of (existing and potential) products that
address a designated business area. [10]
2.2.2    Domain Identification and Scoping Factors
Before initiating a domain analysis effort there exists a notion of a
domain of interest representing some broad area (e.g., acoustic signal
processing).  Then, as part of the initial activity of a domain analysis
effort the scope of the analysis is defined by considering the context
of the domain of interest and the available resources.  This transition
in focus suggests that the proposed framework should contain factors
that contribute to developing a profile of the domain of interest and
factors that contribute to the decision on the scope of analysis.  Also,
since the software context is defined within the system context, the
proposed framework should contain both system-level and software-
level factors that play a role in defining a domain boundary.  Given
Neighbor╒s description of domain analysis as being similar to systems
analysis except that the scope of the analysis involves a set of
systems within an application area versus a single system [5],
successful techniques in bounding a problem space for system
analysis should be adopted for bounding a domain.  Hence, the
category of constraints for system analysis should be incorporated
into the proposed framework and refined for the perspectives of
domain.
Profile factors are intended to describe the domain itself and the
dominant characteristics that distinguish systems (and supporting
software) in the domain from systems not in the domain.  Decision
factors reflect the feasibility and potential benefit for an organization
or enterprise to analyze a domain.  Both of these groups of factors
can potentially be used to characterize a domain or product line not
only as it currently exists but as it might exist in the future - for
example, the evolution of a domain or the characteristics of a
proposed product line.
Table 1 shows a proposed set of framework factors organized into
these two groups (Domain Profile and Decision Support) and gives
example values or elements of each factor.2
2.2.3    Usage Guidelines
The usage guidelines for the proposed framework are currently
being developed, but some discussion of the targeted usage contexts
for the proposed framework can be given.  Although the proposed
domain framework can be used with any reuse-driven process
model, the general context of the two life-cycle reuse-driven process
model is assumed.
The target audience for the framework comprises two categories of
people:  indirect users and direct users.  Indirect users include DoD
executives (e.g., Program Executive Officers (PEOs) and Program
Managers) who make decisions on where to invest resources to
increase reuse and efficiency.  Direct users include technical
personnel who will apply the framework to scope domains,
determine reuse potential, characterize and compare domains, find
commonality across domains, and use this collected information to
support the DoD executives and managers in making their decisions.
Example:  In the context of software reuse, one objective for a PEO is
to identify commonality areas among the acquisition efforts under
his/her management and among areas of responsibility of other PEOs
so as to minimize overlap and maximize benefits within the allocated
resources.  The framework and usage guidelines can be used to
identify the boundaries of multiple domains at the PEO level while
minimizing overlap.

3   Comparison
Several domain analysis methods address some of the framework
issues in a "domain characterization" process [1].  However, our work
differs in the sense that we are attempting to capture what is
common among the methods and to extend this to concepts such as
characterizing types of domains.  Thus, our work complements
domain analysis methods.

Table 1.  Description of Identification and Scoping Factors
Profile Factor    Description    Elements
Domain Identity    High-level or defining characteristics of the domain,
and location in domain hierarchy    Ñ    Definition (name, primary
terms defined, boundary)
Ñ    Relations/context (hierarchical, historical)
Ñ    Type (application domain, software technology domain)
Functional System Requirements    Dominant functions or features of
systems in the domain    Ñ    Functions, features, objects, data,
performance, interfaces
System Characteristics    Dominant subsystems, characteristics,
constraints, and nonfunctional requirements of systems in the
domain    Ñ    Quality (reliability, etc.), design constraints,
organizational boundaries, physical boundaries, security
classifications, domain technology, domain standards, system
architectures
Software Characteristics    Dominant characteristics of software
subsystems that support the domain    Ñ    Software architectures
(types, DSSAs), languages, software technology, software standards
System Deployment    Where systems in the domain are deployed
    Ñ    Airborne, ground-based, sea-based, transportable
Decision Factor    Description    Elements
Domain Assessment    Extent to which existing domain knowledge
and experience, software assets, homogeneity, and maturity provide
reuse opportunities    Ñ    Existence and availability of expertise in
organization, availability of existing software, quality of existing
software assets, extent of similarity of systems
Ñ    Domain maturity
Market Assessment    Potential for making profitable use of domain
knowledge    Ñ    Product expectation (expected new development or
acquisition, major upgrades reengineering, consolidation/migration)
Ñ    Market expectation (current market share, expected market
growth, expected return on reuse investment)
Resource Constraints    Organization or enterprise limits on extent of
analysis and engineering possible    Ñ    Investment capital, schedule
constraints, size of available staff (knowledge engineers, domain
analysts)


References
[1]    Arango, G., 1994, ╥Domain Analysis Methods,╙ in W. Schafer, R.
Prieto-Diaz, and M Matsumoto (eds.), Software Reusability, Ellis
Horwood, Chichester, England.
[2]    DoD Software Reuse Initiative, 30 March 1995, DoD Software
Reuse Initiative Technology Roadmap; Version 2.2, Defense
Information Systems Agency, Falls Church, VA.
[3]    Hayes-Roth, Frederick, 20 October 1994, Architecture-Based
Acquisition and Development of Software:  Guidelines and
Recommendations from the ARPA Domain-Specific Software
Architecture (DSSA) Program, Teknowledge Federal Systems (TFS),
Teknowledge Corporation.
[4]    Meyer, M., and J. Utterback, Spring 1993, ╥The Product Family
and Dynamics of Core Capability,╙ Sloan Management Review, Spring
1993, pp. 29-47.
[5]    Neighbors, James M., 1980, Software Construction Using
Components, Ph.D. dissertation, Department of Information and
Computer Science, University of California, Irvine, CA, Technical
Report TR-160.
[6]    Katz, S., C. Dabrowski, K. Miles, and M. Law, December 1994,
Glossary of Software Reuse Terms, National Institute of Standards
and Technology, Gaithersburg, MD.
[7]    Peterson, A. Spencer, April 1991, ╥Coming to Terms with
Software Reuse Terminology:  A Model-Based Approach,╙ ACM
SIGSOFT Software Engineering Notes, Vol. 16, No. 2, pp. 45-51.
[8]    Prieto-DÆaz, R. and G. Arango (eds.), Domain Analysis and
Software Systems Modeling, IEEE Computer Society Press, Los
Alamitos, CA,
[9]    Prieto-Diaz, Ruben, 26 July 1991, Reuse Library Process Model,
Report No. 03041-002, Software Technology for Adaptable, Reliable
Systems (STARS) Program.
[10]Software Productivity Consortium, November 1993, Reuse-Driven
Software Processes Guidebook, SPC╨92019╨CMC, Version 02.00.03,
Software Productivity Consortium, Herndon, VA.
[11]STARS, 25 August 1994, Experience Reports: The Navy/STARS
Demonstration Project, Software Technology for Adaptable, Reliable
Systems (STARS), CDRL Number A017R.
[12]STARS, 24 February 1995, Army STARS Demonstration Project
Experience Report, Software Technology for Adaptable, Reliable
Systems (STARS), CDRL Number A011R.
[13]STARS, 8 March 1995, Space Command and Control Architectural
Infrastructure (SCAI) Air Force/STARS Demonstration Project
Experience Report., Version 2.1, Software Technology for Adaptable,
Reliable Systems (STARS), CDRL Number A011-002U.
[14]Wartik, S., and R. Prieto-DÆaz, October 1992, ╥Criteria for
Comparing Reuse-Oriented Domain Analysis Approaches,╙ Int. Journal
of Software Engineering and Knowledge Engineering, Vol. 2, No. 3, pp.
403╨431.

Bibliography
Anh Ta is a Lead Scientist in the Software Engineering Center at the
MITRE Corporation in McLean, Virginia.  Since joining MITRE he has
been providing acquisition support to various command centers
within the DoD and participated in research efforts relating to
software reuse, safety-critical software, object-oriented technology,
and COTS integration.  He was previously a member of the technical
staff at the Software Productivity Consortium involved in the
prototyping of reuse environments for the Synthesis method.  Prior
to that, he worked as a software engineer at SofTech, Inc. and
Honeywell Electro-Optics Division.  He received a B.S. in Computer
and Electronics Engineering in 1986 and a M.S. in Systems
Engineering in 1990, both from George Mason University.  He is
currently pursuing a doctorate in Information Technology at George
Mason University with special emphasis on approaches for
developing and evolving domain models.

Duane Hybertson is a Member of the Technical Staff in the Software
Engineering Center at the MITRE Corporation in McLean, Virginia.
Since joining MITRE he has been investigating software reuse
technology for the Department of Defense and software safety
standards for the Nuclear Regulatory Commission.  He was previously
a senior engineer with Lockheed on the Space Station Freedom
Software Support Environment.  Prior to that, he investigated the
synthesis approach to reuse at the Software Productivity Consortium,
where he had a two-year appointment.  He received the B.A. in
Mathematics from Northwest Nazarene College in 1970, the Ph.D. in
Educational Research Methods from New Mexico State University in
1974, and the M.S. in Computer Science from the Johns Hopkins
University in 1985.
1    This paper is based on work sponsored by the Defense
Information Systems Agency (DISA) Software Reuse Initiative (SRI)
Program.
2    These factors are based on an initial set of factors provided by
Don Reifer, Program Manager of the DoD Software Reuse Initative
(SRI).

Support for systematic reuse

Pertti Jauhiainen

Ellemtel Telecommunication Systems Laboratories
Box 1505
S-125 25 [lvsj|
Sweden
Tel: [phone]
Email: [e-mail]

Abstract

This position paper describes a surveyof the mechanisms which we at
Ellemtel Telecommunications Systems Laboratories try to integrate to
support systematic reuse in the development of telecommunication
systems. Reuse is approached from three different views, the system
technology and techniques, the development processes and the
organization point of view. The organizational structure focus on both
support for development for and with reuse, where the needed roles and
their responsibilities are defined to accomplish the benefits of systematic
reuse.

Keywords: Systematic reuse, development processes

Workshop Goals: Learning, networking

Working Groups: Reuse process models, Reuse management, Reuse
technology standards

1   Background

The implementation of systematic reuse at Ellemtel aims at supporting
in solving the forecasting problems in the development of
telecommunication systems. This through the creation of reusable
software and hardware components on different abstraction and
implementation levels, i.e. to support modularity and adaptability of
the products during development and delivery.

The systematic reuse influences the organization, system development
process, and the basic system technology of the development
organization.

2   Position

The goal is to create a reuse environment where the development and
maintenance of the system parts can be done by only a fraction of
resources in relation to the total effort required to redevelop designs in a
system product.

This kind of systematic reuse is challenging and takes time and effort to
introduce in a high technology environment as a telecommunication
development organization, but it is important to have a vision, and a
step-wise strategy to fulfil the vision.

We have defined three main areas which must cooperate to achieve
efficient support of reuse, system technology, development processes and
organizational structure.

Typical examples on system technology are for example system
architecture, system structure, use of (standardized) interface techniques
and object-oriented languages. You could say that the system technology
defines the range of candidates of reusable components.

The development process describes how reuse is performed during the
system development. The support and management of development and
the use of reusable components is integrated to be a natural part of the
system development.

An organizational structure is created where roles and responsibilities are
defined with respect to the duties of project, product and system
management, this to efficiently control the development and use of
reusable components.

2.1  System Development Process

In the system development a combination of standard development
paradigms and methods are used, e.g. object-orientation, with guidelines
and tools tightly coupled to Ericsson's AXE platform. The purpose of the
development process is to:

Collect and make visible, but also reusable, experience and knowledge in
building telecommunication systems,

Show the correct way to use the AXE platform,

Provide a common language for communication between designers,

Provide a measurable process that supports continuous improvements.

The development process or processes, depending of the type of
applications (e.g. telecommunication systems or support systems), are
built according to a common architecture and using a common
framework. All descriptions are modular and can be extended and
adapted to new situations,i.e. the processes are built to be reusable.

The development process provides a consistent chain of models that are
created and refined during a development project. The system
development process is based on such a sequence of models that describe
the successive refinement of requirements into hardware or executable
code.

The possible form of the information created during the development of
an application is defined by a information model. The concepts defined
in the information model for the support of explicit reusable software
components are,

Source Code Component, which has the purpose to encapsulate source
code information that can be used in different software items.

Object Model Component, which has the purpose to encapsulate model
and specification information for a group of object types.

The software components have an interface part and a body part, where
the different parts can be managed separately in different libraries.

Two aspects of reuse are covered in the system development process,

The development for reuse, i.e. reusable component development,

The development with reuse, i.e use of components during the system
development.

In the development of reusable components the main phases cover
domain analysis ,specification of general architectural component
requirements (frameworks), design and certification, and support
and maintenance of components.

The management of reusable components as defined in the information
model for the system development process is integrated in the general
product and design information management systems, i.e. the
components are treated as product and design information in general.

A crucial step to support reuse in the information management system is
to allow for a flexible implementation of the structure of the information
in general, i.e. to give possibilities to structure the information according
the actual product ordesign needs.

A number of formalisms is used to represent the different process
models.In general, standardized formalisms support reuse by giving the
actors in the development process a common language to describe
requirements and implementations, which then give more easily
possibilities to create components that are more understandable and
then also more reusable.

The language and tool for conceptual modelling and behaviour
specification at the analysis level in the development process is used for
describing, analysing, specifying, and validating functional requirements.
Tools used are for example Delphi and Objectory for early phases of
system development, DELOS interface description language for design
levels, and C++ for implementation level.

2.2  Organization

The implementation of reuse in the organization include,

definition of an organizational structure, i.e. to implement development
for and with reuse,

description of roles in the different organizational units in the company,

the responsibilities on those roles,

support to fulfill the responsibilities. i.e. integration in the development
process roles.

The roles identified support both the development for reuse (component
development) and the development with reuse (system development),
i.e. the roles need to support responsibility from a development and
support view.

The roles and responsibilities for reuse activities need to be divided
between line management, product and system management.

3   Biography

Pertti Jauhiainen works at Ellemtel Telecommunication Systems
Laboratories in Stockholm, Sweden, a company which developes system
platforms for telecommunication. He works at the department for
system development support systems and is responsible for
implementing support for reuse in the system development process.

He has also been project manager for Ericsson Telecom AB in the
European Commision RACE projects ARISE (A Reusable Infrastructure for
Software Engineering) and SCORE (Service Creation in an Object-oriented
Reuse Environment).

Earlier he worked at Epitec, Inc.in Framingham, Mass. in U.S.Aand Epitec
AB in Link|ping, Sweden with expert systems technology. He received a
M.Sc in Computer Science from the University of Link|ping, Sweden in
1986.
Why Doesn't the Reuse Community Talk About Reusable Software?

Ralph E. Johnson

University of Illinois
Department of Computer Science
Tel: [phone]
Email: [e-mail]
WWW: http://st-www.cs.uiuc.edu/users/johnson/

Abstract

The reuse community spends too much time talking about reusable
software in general and too little time talking about reusable software in
particular. We need to study and compare the designs of particular
reusable systems so that we can improve them (and so make reuse more
valuable) and so that we can learn the principles of reuse.

Workshop Goals: Learning; Finding kindred spirits.

Working Groups: Domain analysis/engineering; Reuse and OOmethods
and technology; Reuse handbook; Reusable architectures for business
software.

1   Background

I've been working with OO technology for 10 years, trying to see how
objects change the way we develop software, especially how it impacts
software reuse. I quickly noticed that reuse of code and small
components was not what was important, but instead reuse of design in
the form of larger components called frameworks.

A framework is a reusable design expressed as a set of abstract classes and
the way that instances of these classes interact. In one sense, the most
important thing about a framework is the interfaces that it defines.
Because a framework is made up of classes that can be represented in
programming languages, it is reusable code. But it tells you how to
decompose your program into objects, and in that sense is a design.
Moreover, most of the code reuse comes not from inheriting from the
abstract classes but from reusing concrete classes from a class library.
The concrete classes reuse the standard interfaces defined by the
framework, so they can be mixed and matched. Most of the reuse comes
from being able to mix and match components, not from being able to
define a new component using inheritance.

I've worked on a number of frameworks, including the frameworks that
come with Smalltalk-80 (VisualWorks), a framework for drawing editors
called HotDraw, a framework for operating systems called Choices, a
framework for code optimization and code generation, a framework for
music synthesis,and a framework for accounting. While none of them
have had large numbers of users (HotDraw probably has the most users,
and that is probably 50-100), most of them have had a few users outside
of my research group.

Recently I have been working on documenting the software patterns that
expert designers use. Not surprisingly, I have focused on the patterns that
OO designers use to make software more reusable.

2   Position

One of the distinguishing characteristics of computer people is the
tendency to go meta at the slightest provocation. Instead of writing
programs, we want to invent programming languages. Instead of
inventing programming languages, we want to create systems for
specifying programming languages. Instead of analyzing domains, we
want to make methods for domain analysis. And instead of writing
reusable software, or reusing software, we want to write about the
principles of software reuse.

There are many good reasons for this tendency, since a good theory
makes it a lot easier to solve particular instances of the problem. But if
you try to build a theory without having enough experience with the
problem,you are unlikely to find a good solution. Moreover, most of the
time spent building reusable software is on issues that are particular to
the problem that the software is supposed to solve, not on generic
reusability issues. We are in danger of attacking secondary problems and
ignoring the most important ones.

The software community has developed standard architectures for some
kinds of software, such as compilers, operating systems, and user
interfaces. Not surprisingly, these are the kinds of software for which we
have the best reusable software; parser generators and table-driven code
generators for compilers, and GUI frameworks and screen painters for
user interfaces. But there are a lot more people building accounting
systems or manufacturing systems than building compilers, and we have
tended to ignore applications software, even though that is the most
financially important kind. Although there are reuse success stories
among this kind of software, I believe we are only seeing a fraction of
what is possible.

Whenever a standard architecture has developed in the past, it has been
developed in a context of a community that can bring many
perspectives to bear on it. The practitioners are from companies that are
trying to build commercial software. Researchers are investigating narrow
problems within the domain of the architecture. Textbook writers are
trying to organize and systematize the material.

Why hasn't this happened with accounting software or manufacturing
software? One possible reason is that companies are afraid of losing trade
secrets. But that reason didn't keep the system software venders from
participating in conferences on compilers or operating systems. I think a
more important reason is that reseachers have ignored these topics. If
the researchers were holding exciting conferences on these
topics,practitioners would come to find out what was going on, and they
would figure out how to make the researchers want to talk to them. But
without all the members of the community, it is much harder to make
progress.

What can practitioners do to attract the attention of researchers? One
obvious technique is to support their research financially.  Another is to
helpconferences on the domain of interest get off the ground. When
organizations have their own research department, practitioners can try
to get some of the researchers interested in their problems. Regardless of
which methods are used, changing other people's behavior is always
hard.

Is it worth trying to organize groups of people working on particular
kinds of software? I think this is the only way to make good reusable
designs. To be reusable,software has to be reused in many contexts, and
there are very few companies that have the resources to do it. It can be
difficult breaking though the parochialism that effects so many
companies, but I think it is important if we are going to achieve our
goals for reuse.

3   Biography

Ralph Johnson is on the faculty of the Department of Computer Science
at the University of Illinois.  He was program chair of OOPSLA'93, and is a
coathor of "Design Patterns: Elements of Reusable Object-Oriented
Software" with Erich Gamma, Richard Helm and John Vlissides.
Putting Reuse in its Place 10X Cycle Time Reduction Plan

Rebecca L. Joos, Ph.D.

Motorola
1501 W. Shure Drive
Arlington Heights, Illinois 60004
Tel: [phone]
Email: [e-mail]

Abstract

After several years of external benchmarking and internal pilots, the
Motorola Cellular Infrastructure Group (CIG) has come to the conclusion
that the greatest benefit of reuse is cycle time reduction. With Motorola's
new campaign for 10X cycle time reduction,reuse has become the shining
hope. We have two parallel activities, PDEand SCE, that have reuse as a
common thread. PDE is a development environment for CIG's engineers
whereas SCEis a development environment for CIG's customers. In the
PDE activity reuse is one of fours key enablers (process ,architecture,
tools, and reuse). In the SCE activity reuse is the primary enabler.

Keywords: reuse, service creation environments, service independent
building block, process

Workshop Goals: learning, networking, advance state of theory and
practice of reuse

Working Groups: reuse process models, domain analysis/engineering ,
architectures

1   Background

Becky has been working on software reuse since she finished her
dissertation, "A Software Development Environment to Use and Create
Reusable Building Blocks." She has campaigned for reuse in Motorola
with training seminars, courses, and pilots.  Her current work deals with
performing domain analysis and building reusable cellular service
structures.

2   Position

2.1  PDE

We realize that reuse like other things is not the silver bullet but just one
of the techniques that we will use to produce better products faster.
Reuse must be combined with process, tools and product structure to
achieve significant gains in productivity. With this understanding the
PDE (Product Development Environment) team was established to create
an environment that supports all these areas and is building a model
similar to the megaprogramming and reuse model described by
Solderitsch and Wickman [].

The mission of the PDE activity is to achieve superior world-wide
customer satisfaction by instituting a product development environment
to successfully achieve 10X cycle time and improvement goals. The PDE
team is focusing on 4 key areas: process, architecture, tools, and reuse.

2.1.1 Process

CIG has experienced a continuous process improvement from the
recognition of process to formally assessed at SEI Level 3. A tremendous
organizational growth has also ensued (approximately 2500 software
engineers across multiple locations).

The team's goal is to make the organization Best in Class for software
processes by continuing to provide evolutionary process improvement
and introducing revolutionary improvement where needed.

2.1.2 Architecture

Initial work will be concentrated in the vertical domain of cellular
switching. External to CIG, the Motorola communication sectors are
looking at horizontal domain structures. The goal is to create a common
software (core) platform that enables rapid development and
extensibility.

2.1.3 Tools

To reap the real benefits of reuse and achieve 10X cycle time reduction, a
tool set is needed to support product design and development. The goal
of this group is to provide an integrated process-centered software
engineering environment supporting all phases of the software lifecycle.

2.1.4 Reuse

This reuse group's goal is to institute systemic architecture-centric reuse
within CIGand support reuse efforts external to the organization. The
reuse team is composed of members from each of the CIG development
groups. They are responsible for developing the reuse processes,
procedure, techniques and transferring them into their group.

2.1.5 Process

The reuse processes are one aspect of the overall development process
mentioned in section 2.1. The group is concerned with what to do to
institute reuse, as well as techniques on how to create and use reusable
software assets. These procedures and activitieswill be incorporated into
the overall development process.

2.1.6 Support

The group provides guidance and some resources i.e., people for
technology transfer,domain engineering, tool integration, repository
population and maintenance, assessment and measurements.

2.1.7 Pilot

In parallel to the PDE effort a pilot is being conducted to build and
populate a service creation repository. This effort is central to CIG's
plans for the future and will provide much insight to the reuse program.

2.1.8 SCE

Cellular providers i.e., CIG's customers, want to "invent" new services
that they can provide to their  customers faster than the competition.
This objective requires rapid design and implementation of new services.
Motorola's Service Creation Environment (SCE) will give cellular providers
the tools to develop new cellular services themselves. The ultimate goal
is to remove the developer from direct product delivery. Developers
create the building blocks that are made available to customers who
then design their own products from these reusable blocks. Development
will become a proactive activity rather than a reactive activity with
developers continually building new blocks to populate the SCE
repository.

2.1.9 SIBs

The Intelligent Network (IN)is an architectural concept for the creation
and provisioning of telecommunications services. A service independent
building block (SIB) is composed of a set of Functional Entity Actions
that either independently, or in combination with other SIBs, are used to
model service entities. SIBs are the reusable building blocks for the SCE
repository.

A reusable SIB will consist of several components:

the requirements and functional description of the SIB,

design,

code,

test suite, and

user documentation.

Each component of the SIB will be linked together and more than one SIB
may link to a particular component thus forming a network of reusable
blocks.

2.1.10 Economics

Since creating reusable SIBs will not be an easy task, one of the key
decisions will be whether or not it is financially advantageous to build
any particular SIB. Although building the initial reusable SIBs will be
more of a learning experiencethan a profit activity, subsequential SIBs
must be profitable investments.

The following metrics will be used for the business analysis of any new
reusable SIB:

cost - what will it cost to create the SIB,

use - how many products will re-use this SIB,

savings - what will this save in future developments, and, of course the
most important calculation:

profit - what did the reusable SIB earn CIG.

This will actually be a sub-pilot within the SIB pilot.  Although there are
many good metrics available, they still require a lot of qualifiable input.
A three month study will be conducted to help quantify the economic
metrics and improve our ability to estimate the use and profit of
reusable SIBs.

Some of the information needed for the metrics is obtained through
domain analyses.

2.1.11 Domain Analysis

Much of the SIB functionality already exists so the domain analysis
focused on both forward and backward analyses. This was a team effort
with the reuse team providing the analysis expertise and the
development engineers providing the domain expertise. From the
domain analysis the reuse team was able to create a reusable SIB
template that was used to produce reusable SIBs for the repository.

2.1.12 Repository

The initial repository is a WEB based system with keyword search for
retrieving components. As we create the service creation environments, it
is assumed that we will needed added security for our repository and
building blocks.

3   Comparison

Several of the leading service vendors are working on service creation
environments. Because of the competitive advantage, the vendors do not
publish their implementation details.  Since there are standard SIB
structures, I am assume that everyone is following the standards. Jeff
Poulin and Keith Werkman have implemented WEB based repositories at
IBM/Loral. Weare working with Jeff to expand our prototype.

4   Biography

Rebecca L. Joos is a Principal Staff Engineer/Scientist at the Motorola
Cellular Infrastructure Group in Arlington Heights,IL. She is leading the
effort on reusable Int elligent Network building blocks and domain
analysis. She works closely with other Motorola groups to systematically
introduce software reuse into Motorola 's software development
processes. She was previously the Software Quality Assurance Manager for
the Advanced Microcontroller Unit and RISCdivisions in the
Semiconductor Sector instituting software process and quality assurance.
Applying Lessons Learnt from Software Reuse to Other Domains

T P Kelly, B R Whittle

Rolls-Royce University Technology Centre
Systems and Software Engineering
Department of Computer Science
University of York
York, UK, YO1 5DD
Tel: [phone]
Fax: [phone]
Email: tpk/[e-mail]

Abstract

The position this paper promotes relates to the applicability of software
reuse techniques to other non-software domains: What lessons learnt
from techniques developed primarily for software reuse, can be applied
to reuse of artifacts in other disciplines? The prime motivation for this
research comes from a project attempting to apply reuse and evolution
to the arguments of a safety justification. A discussion of the issues from
this domain,as well as from more traditional domains within software
development are used as illustration. Our exploration of the issues
relating to safety arguments has led us to recognise anew that the
essential problem of reuse is one of matching contexts. Whatever the
domain we must be able to recognise and abstract the essential technical
and non-technical characteristics of the domain. The success of reuse
depends upon our ability to support, communicate and exploit the
context in which artifacts are built, used and hopefully reused. The
paper uses the examples of domain analysis and component description
to show how this problem has been tackled with software artifacts and
sets forward the motivation for domain modelling that provides a
unifying basis for component identification, storage and retrieval for any
domain.

Keywords: Software Reuse, Non-Software Domain, Context, Domain
Analysis, Component Description, Reuse Model, Domain Model

Workshop Goals: Discuss domain modelling, assess suitability of software
reuse principles to non-software domains

Working Groups: Domain Analysis / Engineering, Reuse process models,
Reuse handbook.

1   Background

Both authors work within the Rolls-Royce University Technology Centre
for Systems and Software Engineering: Rolls-Royce established this
research group within the University of York, England to examine systems
and software development issues for the high integrity control
systems,both in the aerospace and power generation industries, produced
by Rolls-Royce plc.

One of the major activities of the group has been in establishing a
successful reuse strategy within the company. This work has been
principally undertaken by Ben Whittle and has examined artifact reuse
across all phases of system development, from requirements
specifications to test plans. The work of Tim Kelly has been in extending
the concept of reuse to another costly aspect of high integrity system
production, namely safety case development. It is in this work that Tim
has been examining the applicability of ideas and techniques from
software reuse to wider domains.

2   Position

The software industry has proclaimed the benefits of reuse for some time,
for example: shorter development time, increases in reliability,
economies of scale. This has led to an increasing number of domains
being examined for their reuse potential. Candidate domains for this
scrutiny are typified by the complexity of the artifacts produced being
sufficiently great to outweigh the pickup effort associated with a
'reusable' artifact [1] and where some generality of type or application of
the artifacts is suggested. Artifacts in these domains may already be
reused on an ad-hoc basis. However, it is systematic reuse, as exemplified
in the field of software reuse, that is being seen as having potential long-
term benefit. The majority of existing reuse research has concentrated on
software and software-related artifacts. Unlike physical artifacts, software
artifacts are intangible and their concept, content and context highly
variable. Because of this, software reuse research has been forced to deal
in generalities and toaddress issues concerning reusable component
identification, support and management. Although no panacea exists,
the reuse problem has similarities across all domains and fundamental
lessons can be learnt from software reuse research. The position this
paper explores relates to the applicability of software reuse techniques to
other, non-software, domains: What lessons learnt from techniques
developed primarily for software reuse,to reuse of artifacts in other
disciplines?

Software is often generalised as a single domain. Of course this is not
strictly true, it should be considered as a large number of domains.
Authors active in software research come from a large number of
organisations in differentparts of the world. The strategies and models
they promote have been developed for their particular domain.
Therefore,these models are suitable for their domain but probably not
wholly appropriate for other domains. The exploration of reuse within
non-software domains shows the need for an approach that recognises,
supports and exploits the characteristics of the domain whether for
software or not.

2.1  Issues in Promoting Systematic Reuse

Regardless of domain, there are three issues associated with reuse:

Development for Reuse

How do we identify and develop potentially reusable assets within the
domain?

Development with Reuse

How do we abstract these assets so that they can be stored,retrieved and
reapplied in new situations?

Managing reuse

How do measure the costs and benefits, and reason about the tradeoffs
involved in reusing assets?

These three activities depend on sound modeling of the domain in
which artifacts are initially produced and applied. We focus primarily
on the first two activities given here. Management of reuse, being a vast
subject in it's own right, cannot be adequately covered in a paper of this
length.

2.1.1 Developing for Reuse

When placed in a new environment andtold to instigate reuse, what do
you do? Software reuse theory and practical experience tells us that the
first thing should be to learn something about that environment or
'domain'. In the software domain our first step is to perform a domain
analysis [2] - "The activity of identifying the objects and operations of a
class of similar systems in a particular problem domain". The same is
true for almost any domain. The resulting output from this activity
should be an appreciation of the context in which domain products are
developed and used, including:

Product aspects

Taxonomies and architecture of the products

Functional models of the products

Domain languages

Properties of the component produced

Process Aspects

Life-cycle, methods used in the development of the products

Standards used in the development of the products

Resource used in the development of the products

With domain information such as this we can start to determine those
artifacts with reuse potential, e.g. by spotting common functions or a
regular structure in the architecture of the product. It is only by
assessment of the generality of application or content of an object, based
upon their defining characteristics determined by the domain analysis,
that we can estimate future reuse potential.

Emphasis in domain analysis applied to software products has been
primarily on appreciating and modeling the technical architecture and
characteristics of the domain. To a certain extent, this has not mattered,
the reusability of basic block software components can be crudely judged
on technical content. However, inspection of the component content
cannot reveal attributes such as the development integrity level.  With
other domains such as safety arguments we require a more complete
understanding of the models, experience, assumptions and evidence on
which the argument was based in order to appreciate the extent to which
it could be usefully reapplied in a new context. In these cases, the
context defines the product to a greater extent and without it the
products purpose, generality and applicability is eroded. For example,
without knowing the assumptions on which a safety argument depends
it is impossible to determine the strength of the argument and whether
the argument can be appropriately reused in a new context.

It has been accepted that domain analysis is crucial to making the first
steps in software reuse. Further, we argue that domain analysis is
essential in any domain, provided it considers and identifies the most
pertinent of all,technical and non-technical, influences over the
potentially reusable assets in question. The domain analysis phases is
crucial to 'pinning-down' the context, and therefore generality, of the
initial development and application of components.

2.1.2 Developing with Reuse

Storage and retrieval of components is only an issue to the extent that it
influences successful application of 'reusable' component. When we wish
to reapply a component developed in one context in a new context it is
crucial that we fully understand the component domain and the
component's relationship to that domain, in order that the component
is appropriately used. For example,with a safety-critical software
component we need to determinethe extent to which it has been
developed and tested in order to justify its re-application it in a new
safety-critical context. It is therefore essential that, whatever storage and
retrieval mechanism is used, we capture or communicate a component's
relationship to its development context by abstraction and relationship
to a domain model that captures all aspects of that context.

The central concern in storage and retrieval of components is that it is
fast and intuitive to the reuse engineer. In the field of software reuse,
faceted classification schemes [3] have been suggested as an approach.
Using this method,classes of components are described by defining
faceted lists of keywords. Components are stored with, or according to,
their faceted classification by their particular grouping of keywords
selected from the 'facets'. The principal benefit of this method is the
extent which it sythesises a context in which the reusable components
can be placed; by defining facets for classification we are modeling a
context not too dissimilar to either the original or intended context. If
the principle of faceted classification schemes were extended to wider
domains,for storage and retrieval of components we would need to
recreate a context in which the component can be 'understood'. This
context should be derived from the key, technical and nontechnical,
characteristics defined in the model produced from the initial domain
analysis. Therefore, faceted scheme applied to new domains should also
capture these attributes, as exemplified by the REBOOT [4] approach.

2.2  Examples

We have argued that allthree of the fundamental concerns of reuse,
namely: starting; supporting and managing, should, for any domain, be
based upon a sound model, defining the   key characteristics of the
domain. In the field of software reuse, their has been much effort in
defining the 'best' domain analysis technique or the 'best' faceted
classification scheme. Generalising, software reuse principles to other
domains, we can see that for any domain starting,supporting and
managing reuse should be rooted from a model derived from analysis of
the domain which abstracts the original technical and nontechnical
context of the components in question.

In software reuse, we often assume a common understanding of a
components context or rely heavily upon the content of the component
to communicate that context. For example, we have a common
understanding of a particular programming language or development
method and believe that, given time, we can work our the original
purpose of a component by examining the code contained within. As the
degrees of freedom in a domain, increase and we can rely upon less of a
common understanding, modeling the domain context becomes
increasingly important. To i lustrate this point, let us imagine 3
scenarios:

Mathematical routine

With a description that says it adds two number of type integer and
returns an integer result.

Signal validation component

for a real-time systems that takes in a signal from a heat probe, validates
and range checks the signal. If the signal is outside the acceptable range
a model value is used. The software module that generates the model
value is a separate subroutine, adhering to a coding standard, that
provides a value when invoked,the value the model provides must also
be subject to the range check.

Safety case fragment which argues the reliability of a component from
evidence given in a number of safety analyses, testing and operational
evidence from similar components within the framework provided by
company, government and industry codes and standards.

In each case, when the component is reused it will form part of a system
which is to be used in a safety critical application. We need to examine
how the component meets the requirements placed upon it within the
domain and the properties of those components that are pertinent to
the domain. The software components will be used as part of the systems
itself, the safety case fragment a part of the justification that the system
is fit for its purpose, and has been developed to acceptable standards.

There are a couple of questions we need to ask:

What information do we need to know about the component?

What would existing models like the 3C model [5] or the REBOOT model
tell us about the component?

Is there any way of knowing,from a domain model or domain modeling,
the information that we will need to provide with a component in order
to reuse it?

If we are to reuse the mathematical routine in a safety critical
application it would typically be the case that the component would
have to be developed to an equivalent standard to the other
components that we were using. Thus we need to know something about
the development context of the component in order to infer the quality
of the component. In searching for a component we may wish to
prescribe standards for the components we search for; they must
conform to a given programming standard. We require that reused
components must have been developed to that standard.

In order to reuse the signal validation component we must know about
the associated hardware, the heat probe. We can use the knowledge
about the heat probe to work out what kind of model we need if we are
going to use a model value of the temperature instead. These can be
regarded as the extended technical context of the component

If we are going to reuse the safety case fragment we need to consider on
what bases the justification is founded; the model, strategy, justifications
and assumptions used need to be made explicit, and therefore, verifiable.
For the new context we need to determine whether the model of the
component, the strategy used, the justification for that strategy and the
assumptions made are still valid. For example, it is common to justify a
components claimed safety by reference to a good operational record. If
however, between the time of creating the safety case fragment and
wishing to reuse it, this operational record has been damned by
numerous accidents the original justification is invalidated. Safety case
fragments depend heavily upon their original application context. For
there to be any case for successful reuse of safety case fragments, this
context must be made explicit by means of an accurate domain model.

The REBOOT component model, faceted classes and 'reusability' measures
have been developed specifically for software components. The REBOOT
abstractions would therefore be suitable for reasoning about the software
components in our example, though possibly considered overkill for the
simple component,but would fail to capture the contextual properties of
the safety case fragment. The suitability of the 3C model depends upon
the extent to which we further subdivide the broad categories of
context,concept and content. The 3C model provides a suitable starting
point for developing domain-specific models that could be realistically
used for identification, storage and retrieval purposes. The strength of
the REBOOTmodel is that it has defined a 'generic' model' for software
component which captures most of the non-domain specific properties
of software components. The strength of the 3C model is that it is
suitably generic to be used as a basis for development of any domain
model. However, it's failure is that without further definition we are left
with vague notions of the domain with inscrutable implicit attributes.

This brief example has illustrated that different properties are required
to reason about components from different domains. While we could
attempt to reapply models unchanged from the software reuse world or
develop entirely new models, these would not be suitable for all
domains.

3   Summary of Position

The problem of reuse is one of matching contexts.  Components are
developed in one context and, hopefully, reused in another. The
decisions we take in reusing a component depend on our appreciation of
both of these contexts. We usually have a fair understanding of the
context in which we work. However, we have difficulty in appreciating a
context separated from our own.  If the context of the component isn't
recorded then we are required to assume a context ,as is commonly the
case with vanilla software reuse. We have highlighted that for some
domains ,such as safety justification, the assumption is potentially more
damaging, and the information communicated by the component
content becomes of less use.

Mathematical routines have been successfully reused for some time.
Their strength lies principally in well defined interfaces supported by the
constructs of the implementation language. The functional dependencies
and context of the component can be successfully bundled up as a neat
set of parameters and return variables. The difficulty in reusing
components such as the safety case fragment described lies in the many
dependencies and contextuality that the component possesses. We have
no well understood boundary or interface to the component. The
underlying content andstructure of the component lends no support to
defining this context. We therefore have to find a way of defining the
boundary of the component and specifying those 'parameters' of
dependency within the component's context. Between these two extremes
lie a great many domains, each with varying levels of contextuality and
support from their underlying content or technology. What is common
to these domains, is that the context of the component has to be
considered. The type and degree of context that is recorded should
depend upon the domain in which the component is developed, applied
and reapplied.

We have used the techniques of domain analysis and faceted
classification as an example of how software reuse has tackled a problem
that has to be faced in any domain,that of comprehending and
abstracting contexts. To capture the essence of these techniques
developed for software reuse and apply them to other non-software
domains we need to recognise and record the process and product
characteristics most pertinent to the initial development and
application context. The information that we require for successful
component identification, storage, retrieval and management all derives
from our comprehension of this context. By developing a single model of
this context,on a per-domain basis we will maximise understanding of
where components can be reused and be able to reason about how reuse
can 'carry value' from one context to the other.

References

[1]P. Ireland,"Why is Software Reuse so Elusive?,"in Software Reuse: The
Future, The BCS Reuse SIG 1995 Workshop, 1995.

[2]R. Prieto-Diaz, "Domain Analysis: An Introduction," ACM SIGSOFT
Software Engineering Notes, vol. 15, no.2, 1990.

[3]R. Prieto-Diaz, "Classifying software for reusability," IEEE Software, vol.
4, no. 1, pp. 6-16, 1987.

[4]J.-M. Morel,"The REBOOT Approach to Software Reuse," in Software
Reuse: The Future, The BCS Reuse SIG1995 Workshop, 1995.

[5]B. Frakes, L. Latour, T. Wheeler, "Descriptive and prescriptive aspects
of the 3Cs model,"in Proceedings of the Third Annual Workshop, Methods
and Tools for Reuse, CASE Centre Technical Report number 9014, 1990.

4   Biography

Ben Whittle graduated in Agricultural Economics from UW Aberystwyth
in 1989. He subsequently completed a masters in Computer Science.
Foremost among Mr Whittle's research interests are component reuse and
reuse education.  Mr.  Whittle is currently with the University of York, in
the working within the Rolls-Royce sponsored Systems and Software
Engineering University Technology Centre (UTC). His main task within
the UTC is the introduction of advanced reuse techniques to the
development ofreal-time systems within Rolls-Royce. Mr Whittle has
recently been elected chairman of the British Computer Society Reuse
Special Interest Group committee and was formerly the editor of the
group newsletter.

Tim Kelly graduated in Computer Science from the University of
Cambridge, England in 1994. He is a research student working within the
Rolls-Royce Systems and Software Engineering University Technology
Centre (UTC). He is investigating the development and assessment of
safety cases. In particular,he is looking at the reuse and maintenance of
safety arguments as a means of supporting evolvable safety cases. Before
joining the UTC, he was involved for a number of years with high-
integrity systems and software research within the Rolls-Royce group,
working particularly in the area of Integrated Project Software
Environments.
Deliberations of a Reusable Assets Broker


W. (Voytek) Kozaczynski

Center for Strategic Technology Research/SEL
Andersen Consulting
100 South Wacker Dr., Chicago, IL 60606
Tel: [phone]
Fax: [phone]
Email: [e-mail]


Abstract

The producer-broker-consumer (PBC) model of software reuse
assumes a middleman, the broker, between the teams (or
individuals) that create software assets and those that (re)use them.
The model╒s underlying principle is that the broker fills the gap
between teams that fight to meat deadlines, and therefore have little
time to think about potential future usefulness of their  work
product, and the future users of these products that may have not
even come to being yet. This position paper briefly examines an issue
that is at the very core of the broker╒s existence: what kind of assets
will project care to buy (after all, brokers have sell to exist) and
when is the best time to make a sale?

Keywords: Reuse process, reuse asset broker, reusable assets

Workshop goals: Learning, exchange of experiences, shopping for
ideas, verifying hypotheses

Working groups: Reuse process models, reuse management,
organization and economics

1  Background

I am directing the Software Engineering Lab (SEL) at the Center of
Strategic Technology Research (CSTaR). The mission of this applied
research group is to ╥Dramatically improve the quality and
productivity of the Andersen Consulting╒s software development
processes╙. One of the most promising ways of  achieving this mission
is via large-scale, institutionalized reuse. Because of this, the SEL has
been working on a number of projects that can be directly linked to
reuse. Until very recently, or interest concentrated mainly on
production and/or recovery of reusable code products, for example:
code understanding for recovery of reusable components, software
specifications and automatic code generation, component
specifications and component assembly environments.

While working on the projects and on transferring their results to
practice,  it became clear that reuse of software solutions is difficult
mainly because it comes late in the system development life cycle.
Reuse of relatively small-grain solutions also has relative minor
impact on projects. The most significant reuse opportunities seem to
present themselves at  the early stages of a projects, but they call for
different (than pre-packaged solutions) reusable assets.

Recently the SEL started working with a number of internal
Andersen organizations and programs to establish a function, and an
organizations associated with it, of a broker. The role of this
function/organization is to acquire, refine, package, tailor and
transfer all kinds of reusable assets.

2  Position

The context setup

Imagine the following situation:

-    A broker functions has been set up in a company that
concurrently executes a large number of software development
projects for external clients
-    The projects are independent of each other
-    The projects can be significantly different from each other in
terms of clients, domains, scope, and contractual arrangements
-    On the other hand, the projects are similar in that they deliver
systems in the same broadly understood category (let╒s say, for the
sake of this argument, logistic systems)
-    Each project team has a large degree of freedom in deciding
what is the best way of executing  its project
-    Reuse decisions are based on economics of project execution
and client satisfaction (as opposed to internal ╥arm twisting╙, for
example)
-    The company uniformly trains its employees, has an excellent
QA system, centrally tracks all projects, and strongly encourages
project teams to share experiences (even has a central functions to
facilitate such sharing, but does not award teams for it)

Now, assume further that in this setup the broker function has been
give initial monetary and human resources (which is a good
indication of the management╒s support) on the premise, that a very
significant amount of otherwise reusable assets get simply wasted
because of the disconnection (in time and space)  between their
producers and consumers. Also assume, that the management wants
to apply strictly marketing approach to the broker functions and
wants it to charge the consumers for its assets and services and
eventually become self-supported.  How should the broker invest its
initial capital and build its services and a protfolio of assets.

A ╥law╙ of diminishing opportunities

The law (strictly intuitive at this time) states that as project teams
move forward, they become less and less flexible and an opportunity
for significant impact from reuse diminishes. This is simply because:
-    Project managers, architects, designers and develpers
sucessively, through their decisions, constrain the space into which
the resable assets must be fitted, and
-    With progress of time the project decisions change from
strategic, to tactical, to operational.

The table below shows major phases of a project/system lifecycle
(the phases may be executed concurrently and allow for local
iterations) and the resusable assets that should be of interest to
project teams at each phase.

Phase    Reusabls Assets
Preliminary Requirements Acquisition and Analysis, Contrat
Negotiations    Estimation models, base development process
models, process statistics, comparative frameworks, development
cost records, architectural records, ...
Detailed Requitements Acquisition and Analysis, System
Architecteting    Domain models, systems architecures, technical
architectures, design tradeoff records , COTS solutions, ...
Prototyping and Detailed Design    Prototyping and development
envirments, system designs, component specifications, design
standards and guidelines, ...
Component Development and Testing    Rreusable components,
component designs, solution frameworks, designs patterns, reusable
code libraries, ...
System Integration and System Testing    Testing tools, testing
processes models, configuration control systems, documentation
tamplates, ...
Deployment    User training guidelines, systems support processes
models


The assets listed in the table above can be roughly divide into three
categories:

1.     Solutions that are things like designs, technical architectures,
reusable components, and other artifacts that can be put into the
new system or used to ╥shape╙its form

2.     Software tools such as design workbenches, code development
tools, tesing tools, configuration management tools, etc., and

3.     Software engineering processes and their components.

Software tools are a special category. Their main contributions are
that they: (a)  provide a common language to capture reusable
solutions (designs, architectures, code, etc.), and
(b) improve the productivity and quality of software develpment
tasks. Tools themselves, and the knowledge how to use tham
effetivaly, are very much resuable assets.

While looking at the table it is easy to notice, that most of the
software resue attention (both academic and practical) so far has
concentrated on the resue of software solutions during the phases 4
and 5 (Detailed design and Component development). Much less
attention has been given to more process oriented and less formal
assets usable in the early phases of a project.

Reuse of these ╥early process╙ asstes, however, may present a larger
opportunity for impact. Unfortunately, such reuse is also more
difficult. The software reuse field has very little experience in
capturing processes, process statistics, comparative models, software
development cost models, systems architectures, design tradeoff
records, etc. Moreover, codified experiances of such kind may be
very context-dependent. For example, what works for a software
division of a manufacturing company may not be at all applicable to
the situation described here.

The position ╥proper╙

The borker functions must be proactive. The broker team must
invest in working with project teams to capture quality assets. The
borkering process takes the form of a loop:

-> capture -> analyze -> refine -> package -> identify opportunity ->
tailor -> apply ->

There is no clear starting point in this loop -- the broker actively
works with selected projects to capture best experiences to then
tailor and ╥sell╙ them to other projects. The broker is not just a
librarian, but an informed investor.

So what shold the broker invers in? The table above suggests that is
should invest more in the process, tools and architecure-related
rather than in solution-related assets. This, howeve, brings two
interesting questions:
1. Will that be still software resue if a borker sells things like: team
management guidelines, costing models, tailored process models,
architecture records, etc., or is that a different type of reuse?, and
2. What kind of skills shoud a good broker have?

I am hoping to address thes questions at the workshop.

3  Comparison

The issues brought up here most resemble the work on Experiance
Factories lead by Dr. Vick Basili [1,2 and 3]. The major differnce
seems to be, that the work of the University of Maryland and NASA
concentrated so far on large, stable development organizations with
well-articulated software product lines. Many issues are also
common to the SEI╒s work on the Capability Maturity Model [4].

References

[1]     V. R. Basili, H.D. Rombach, Support for compehensive resue,
Software Engineering Journal, September 1991, pp. 303-316

[2]    Victor R. Basii and Scott Green, Software Process Evolution at
the SEL, IEEE Software, July 1994, pp. 58-66

[3]     Victor Basili, Frank McGarry, The Experiance Factory: How
toBuild and Run One, ICSE-16 and ICSE-17, Tutorial materials

[4]    Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, Charles V.
Webber, Capability Maturity Model, IEEE Software, July 1193, pp. 18-
27
Bibliography

Dr. Kozaczynski is the Director of the Software Engineering
Laboratory at the Andersen Consulting's Center for Strategic
Technology Research which is an applied research organization
working on multiple aspects of software development processes and
tools. He is responsibility for the research directions and coordination
of research initiatives and projects of the lab. He is also actively
involved in projects as a scientist.

His current research interests include reuse of domain-specific
architectures and components, compositional approaches to system
development, and distributed systems design. He is also interested in
application of object-oriented software development approaches and
techniques. Previously he has worked on automatic software analysis
and understanding, software re-engineering, application of AI to
software development, and database systems.

He has a MS degree in Computer Science and a PhD in Organization
and Management from the Technical University of Wroclaw, Poland.
Prior to joining Andersen Consulting he was an Associate Professor at
the Department of Information and Decision Sciences, University of
Illinois at Chicago. He has published over 20 journal and conference
papers and is a member of the Industrial Advisory Board of the IEEE
Software Magazine.

Functional Fixedness in the Design of Software Artifacts

Larry Latour
Liesbeth Dusink

University of Maine
Dept. of Computer Science
222 Neville Hall
Orono, Maine, 04469
Tel: [phone]
Fax: [phone]
Email: [e-mail]

&

Delft University of Technology
Dept. of Technical Mathematics and Computer Science
Julianalaan 132
2624 BL Delft
The Netherlands
Tel: [phone]
 Fax: [phone]
Email: [e-mail]

Abstract

A common rule of thumb to make components reusable is to "make
components generic".  But software engineers tend to design in a way
that solves the particular problem at hand, and in a way that they do
not easily see opportunities to reuse existing components. We call such
solutions "functionally fixed". Domain analysis prior to system design
can help a great deal here, but for most software engineers fighting
functional fixedness is still a constant and uphill battle.

It seems to us that designers need more experience in recognizing
functional fixedness when it is "staring them in the face", and in
generalizing functionally fixed solutions to more (re)usable artifacts. In
this paper we suggest how to uncommit design decisions from
functionally fixed designs in such a way that their essence is kept. This
uncommit process is done with the support
of:

reasoning by analogy,

stating implications,

challenging assumptions, and (of course)

previous experience/ knowledge about the domain and other domains

Keywords: Functional Fixedness, Generic software, Uncommitting Design
Decisions

Workshop Goals: To look for in-depth examples of good reusable
artifacts, to discuss with other researchers what makes them good, and to
validate/flesh out/adjust our ideas on the topic.

Working Groups: Reuse Education, Domain Analysis/engineering, Generic
Architectu
 res

1   Background

We have both been independently exploring issues of reusable artifact
design since the late 80's.  Liesbeth has been approaching the problem
from the direction of both cognitive psychology and software engineering
[3], while Larry has been taking a more "traditional" route to the
problem, relying strictly on previous software engineering literature [6].
Liesbeth has been "playing" with the concept of functional fixedness for a
good while, while Larry has been independently exploring the effects of
uncommitting design decisions.

Our combined goal has been to take the cognitive psychology term
functional fixedness and "operationalize" it. That is, we have attempted
to show what functionally fixed software artifacts look like, and in the
process to suggest how such artifacts could be avoided or undone.

2   Position

Our position is simply that the cognitive psychology people have the
right idea (functional fixedness), but that these ideas need to be
"operationalized" in the reuse domain. A prior example of a successful
"port" of an idea from another discipline is the work done by Ruben
Prieto-Diaz in exploring the concept of faceted classification in the reuse
domain ([9] - yes, boys and girls, 1987).  We introduce some of these
ideas of functional fixedness in this position paper.

2.1  Introduction

Functional fixedness concerns the "fixed" nature in which humans solve
problems [2]. Specifically, they tend to express solutions in a way that is
very specific to the problem at hand,and in a way that is somewhat
difficult to generalize to the solution of other, similar, problems. This
causes both a difficulty in seeing that existing components can be used
in one's problem solution and also a difficulty in designing reusable
components for use by others.

Our suggestions for designing for and with reuse involve systematically
uncommitting design decisions from functionally fixed solutions in ways
that the resulting solution(s) can be more easily applied to other
problem solutions and that also leave the essence of the original solution
intact.  How this method is developed is described in [5].

It seems that the following four guidelines each play a major role in
"optimizing" the uncommit process:

1. Always Challenge Assumptions: when a design decisionis made, make
clear why such a decision is made, from where it is made, and what the
properties are of the general class of design alternatives from which such
a decision is made.

2. Make Implications Clear: when a design decision is made, make clear
the other design decisions that affect the choice of this decision, and also
make clear the design decisions that are affected by this design
alternative.

3.Make Analogies Explicit: While humans express problems solutions in a
functionally fixed manner, they are very good at reasoning by analogy,
and find their fixed solutions in that way.

Analogous design decisions have a common abstract description when
uncommitted within a context and from a certain viewpoint, and these
descriptions should be made explicit.

4. Value Previous Experience/Domain Knowledge Highly: The first three
guidelines have to be followed within the context of experience, both in
the domain of interest and in the understanding and use of good
software engineering principles.  The context of experience can also
stretch to other domains of interest,e.g. knowledge about library
reservation systems can be of an advantage when designing a seat
reservation system for planes.

The "Make Analogies Explicit" bullet raises an interesting point that we
exploit. Humans do most of their "hard" reasoning by analogy in an
informal, abstract, and many times unconscious, manner.  What is left
tends only to be the functionally fixed solution as formal residue.

Part of the problem here tends to be one of awareness. Two interesting
research studies support this claim.  Maiden and Sutcliffe [8].  show in
their work that software engineers use syntactic analogy instead of
semantic analogy because they are not actually aware that they use
syntactic analogy.  When aware of the fact that one chooses by analogy
one can also reason why the analogy holds and (subsequently) come up
with the right (semantic) analogy.

Compounding the problem is that humans tend to solve just the
problem at hand with the help of analogy,and not the class of problems
of which this specific problem is a part.  This contributes to the "scale-
up" problem, in that "super-problem solutions" of which the problem
solution is a part tend to be not only solved in a functionally fixed
manner but reasoned about in that manner also.

It is interesting to note that our analysis when evaluating our
uncommitments is similar to that used by Ted Biggerstaff in his "rule of
3s".  That is,we take advantage of prior knowledge of alternatives and
their common characteristics to properly construct our "decision graph".
As we keep repeating,there is no substitute for this knowledge. The better
it is,the more complete our decision graph will be.

2.2  The 3 Views of Functional Fixedness

The definition of functional fixedness as taken from the cognitive
psychology literature does not in itself help us in an operational sense.
We need to explore the analogy between general knowledge and software
engineering knowledge in order to apply this principle. But of course we
immediately we see an analogy with reuse, where one has to use existing
components not only in one application but also in other applications.
In that case if knowledge of such components is tied closely to a former
problem solution, it becomes difficult to see the applicability of that
component to another problem. Specifically, (and paraphrasing our
cognitive psychology definition) if a component is learned for the
purposes of using it in one application then the (possibly) broad general
properties of the component are learned as perceptions of specific,
limited, functional characteristics.

In fact, by massaging the definition a little bit, and using an analogous
interpretation, we make the definition apply for reuse and software
engineering in a more general sense. In this we derive three different
"functional fixedness" definitions:

1. wrt the component: We can view functional fixedness with respect to
the component itself. That is, the component is functional fixed if it
only does one specific thing in one specific way in one specific context
only.  This relates to the genericity issue discussed earlier.

2. wrt a software engineer's view of the component: We can view
functional fixedness wrt the view a software engineer has of the
component.  That is, does the software engineer view the component as
only doing one thing in a fixed way and in a specified context,
independent of its actual level of functional fixedness? This view of
functional fixedness is the most faithful to the original cognitive science
definition.

3. wrt a software engineer's view of the problem solution: We can view
functional fixedness wrt the problem solution created by the software
engineer. That is, does the solution focus on the specific problem or class
of problems analogous to that problem solution. To some extent this
argument is recursive (not circular,since we always start somewhere),
since the problem solution itself can be considered to be a component.

Consider first the functional fixedness inherent in a component.  An
example of a component performing only one (set of) task(s) in one way,
and in one context is an abstract data type for sequences of integers.
Such an ADT can easily be generalized into an abstract data type for
sequences of any type of elements. But this generalization doesn't buy us
too much, since most software engineers can easily re-write its
implementation without invalidating the specification and
implementation constraints. Even though this generalization allows us to
use the component in more than one context, it still performs only one
set of tasks in one way.

Consider next functional fixedness from the software engineer's point of
view. Suppose we need to implement a search tree,and choose a binary
tree for the search tree structure.  Focusing primarily on this application,
we might not see that such a structure can also be used as an expression
tree in a compiler. One might argue that we don't care at this point
about expression trees for compilers.  But this is exactly the point.  We
have solidified our view of a binary tree as a search tree because of the
application, but we still have only a vague feel for a binary tree as an
expression tree in a compiler, again because of our focus on the search
tree application.

Another example of user view functional fixedness, one that we are all
too familiar with, is our frustration and inability to cope with the wide
range of features provided by our word processing/ spread sheet/ paint/
draw/ programming environment/ etc. software on our PC (which of
course we all have). We tend to assimilate this knowledge in a
functionally fixed way, learning only what we need to learn to do our
work. The above problem is compounded by the fact that in order to
properly use more complex components/sub-systems/software packages,
one has to have intimate knowledge of the usage patterns of applications
using such facilities.

Two examples, each at opposite ends of the "abstraction continuum"
come to mind.  The abstraction continuum meant here, is in terms of
the top-to-bottom layering of a complex system implementation.

One is the use by a photographer of a complex photographic image
processing package, and the other is the use by a systems programmer of
a complex device controller interface. In both cases a tremendous
amount of domain knowledge is required to use the facilities as they
were intended to be used. In the case of the image processing software,
tools to hi-light, low-light, darken, or lighten an image make little sense
to a novice, and in the case of the device controller interface, disk heads
can be destroyed in the hands of a novice. Ways to alleviate such
problems are to give courses for photographers, and provide pre-
packaged device drivers for complex devices.

Both of the first two "views" of functional fixedness focus on the
components to be reused. The third interpretation of functional
fixedness focuses on the framework, or architecture, in which
components are reused. Specifically, when designing a framework for a
problem solution, we tend to do so for that solution and not for the class
of solutions of which it is a part. But we also need to deal with
functional fixedness in the framework design of mid-size components.
Often a great deal of functional fixedness analysis of small components is
lost if they are then composed into a functionally fixed mid-sized
component framework.  As an example, a real-time feedback control
module might be designed in a functionally fixed manner without an
awareness that analogous feedback control modules are available for
reuse.  In this case the designer might not even be aware that the system
is a control system, thus not being aware of the wide variety of  analysis
methods and tools available for such systems.

The actual functional fixedness of a component is typically what most
reuse literature focuses on when considering design for reuse, and the
software engineer's view of the problem solution is typically focused on
(although in a functionally fixed way) when considering design with
reuse.  The software engineer's view of a component is typically not
considered, essentially because the literature focuses on the reuse
product and not the process.

What is also typically missed is that if one designs with reuse, the
resulting product is also a component implementation, and needs to be
analyzed with respect to design for reuse. Thus in order to achieve the
elusive "scale-up" frequently alluded to in the literature, designing with
reuse needs to always be done within the context of designing
frameworks for reuse.

2.3  An Example

2.3.1 Undoing Functional Fixedness

We now suggest how to undo functional fixedness in a component, thus
how to uncommit. This approach of uncommitting can also be done
after one stage of a top-down approach to check one's own results. We
use as an example, the tried and true Quicksort algorithm (which
we suppose is as trite an example as a stack is.  So be it.)

In this position paper we will specifically limit ourselves to one aspect of
quicksort, the internal partition algorithm.

For choices of partition algorithm we find among others:

while not done
   if pivot > a[lwb] then lwb:= lwb+1
   elsif pivot < a[upb] then upb:= upb-1
   else swap(a,lwb,upb)
   endif
end

while not done
   while pivot < a[lwb] do lwb:= lwb+1 end
   while pivot > a[upb] do upb:= upb-1 end
   swap(a,lwb,upb)
end

while pivot < a[lwb] do lwb:= lwb+1 end

while pivot > a[upb] do upb:= upb-1 end
while not done
   swap(a,lwb,upb)
   while pivot < a[lwb] do lwb:= lwb+1 end
   while pivot > a[upb] do upb:= upb-1 end
end

Triggered by the different formats, we recognize the inner while-loops as
searches for elements which are out of place. The fact that they always
appear together triggers the thought that they together are a search for
the swap-indices.  We thus rewrite the algorithm now in "pseudocode"as:

while not done
   search(swapIndices(pivot))
   if search success then swapendif
end

We now see the reason for the algorithm that starts with the search for
swap indices before starting the "not done" loop. It is optimized with
respect to checking the condition. Search failure and done are the same
test. Unfortunately, it is a "false" optimization, since the test for success
is also incorporated in the search algorithm itself.  From the perspective
of good programming style this is "ugly", since the same work as done in
the while-loop shouldn't also be done outside the loop.  From the view of
correct use of language constructs one should use a repeat as the search
is done at least once. The if-statement then returns and the
optimization is undone.

From the viewpoint of reuse this"optimization" is also ugly. It takes
more time to understand the algorithm, especially as the optimization is
not documented and is an unfamiliar usage pattern to most naive
programmers.  Furthermore, it is not really necessary that the test of
failure and done are the same. By keeping them apart, we can more
freely choose a search algorithm and a stopping criterium.

The algorithm in the form rewritten above is familiar.  Triggered by
associating the search and the search predicate we might begin to think
about filters, which leads us in turn to think about folds and maps
(knowledge from functional programming).  We suddenly see that
Partition is a map. Now the iterator has become implicit. Depending on
whether we work in place or with help structures the iterator can be of
importance.

In summary,the concepts we recognize as determining the algorithm are:
an iterator on the structure; a filter on the structure; and a map on the
structure.  Partition can be viewed as a framework for search, albeit one
with few restrictions on the search.

2.4  Summary

We have found it useful to define a more general interpretation of
"functionally fixed" than that which appears in the cognitive psychology
literature. We realized that the term itself was functional fixed, therefore
only partially applicable to our problem area. Our three-view
interpretation shifts the focus of attention and in doing so becomes a
unifying concept that aids us in focusing on the hard problems of
designing for reuse, with reuse, and scale-up.

The issue of functional fixedness is NOTto remove it, but to control it in
such a way that it captures the essence of the domain knowledge
inherent in an algorithm, not more nor less. Furthermore, this control
has to be done both during design"for reuse" and "with reuse" as they
are two sides of the same issue as stated in the previous section.
Knowing what to "fix on" in this way, and then capturing it formally is
arguably the essence of design for and design with reuse.  Since the
systematic application of the four stated guidelines can be useful in both
of these contexts, our work looks carefully at both issues, considering the
effects of each side on the other.

References

[1]H.G. Birch. The Relation of Previous Experience to Insightful Problem-
Solving. Journal of Comparative Psychology, 38:367-383, 1945.


[2]H.G. Birch and H.S.Rabinowitz. The Negative Effect of Previous
Experience on Productive Thinking.In Wason and Johnson-Laird [11],
chapter 3.

[3]Dusink,E.M. Software Engineering and Reuse. Proceedings of the Fourth
International Workshop on Software Reusability, Reston, Virginia, 1991.

[4]E.M. Dusink. Reuse is not done in a Vacuum. In Larry Latour et al.,
editor, WISR'92,5th Annual Workshop on Software Reuse, Palo Alto
California, October 26-29 1992, 1992.

[5]E.M. Dusink. The Reuse Process Refined. Technical Report to
appear,Faculty of Mathematics and Informatics, TU Delft, The
Netherlands, 1994.

[6]Latour, L., and Johnson,E. Seer: A Graphical Retrieval System for
Reusable A da Software Modules. Proceedings of the 3rd Int'l IEEE Conf. on
Ada Applications and Environments, Manchester, NH, 1988.

[7]Mitchell D. Lubars and Neil Iscoe. Frameworks versus Libraries: A
Dichotomy of Reuse Strategies.In Larry Latour et al., editor, WISR'93, 6th
Annual Workshop on Software Reuse, Owego, New York, November 2-4
1993.

[8]Neil Maiden and Alistar Sutcliffe. The Abuse of Re-use: Why Cognitive
Aspects of Software Reusability are Important, chapter 10, pages 109-113.
Workshops in Computing.  Springer Verlag, 1991.

[9]Prieto-Diaz, R., and Freeman, P. Classifying Software for Reusability.
IEEE Software,V 4 (1), 6-16, January, 1987.

[10]P.Saugstadt and K. Raaheim. Problem-Solving, Past Experience and
Availability of Functions. In Wason andJohnson-Laird [11], chapter 5.

[11]P.C. Wason and P.N. Johnson-Laird, editors. Thinking and Reasoning,
Selected Readings. Penguin Modern Psychology. Penguin Books, 1968.
The Impact Of  Technological Change On Domain Specific Software
Architectures

Sadie Legard & Bill Karakostas

C25/Main Building
Department of Computation
UMIST
Manchester
M60 1QD
United Kingdom
Email: [e-mail]


Abstract

In this position paper we argue that research into domain specific
software architectures [1] can benefit from the results of a discipline
known as technology theory which is concerned with issues such as
technological evolution. In this context a domain architecture
encompasses a complex of technologies whose role and trajectories
(possible future evolution) must be taken into account when
assessing the stability and the evolution of the architecture itself

Keywords: reuse, domain specific software architectures, reuse
management, technology theory.

Workshop Goals: to meet, discuss and refine ideas with fellow
researchers and practitioners.

Working Groups: Reuse management, organisation, economics, Useful
and collectible metrics, Domain analysis/engineering.


1   Background
Sadie Legard is about to complete a PhD in the area of software reuse
and re-engineering. During the course of her research she has been
investigating the maturation of software reuse as a technology, and
the organisational, managerial, and technological issues related to the
formulation, and subsequent introduction, of a new paradigm for
software development based on reuse principles. In her thesis, Sadie
describes Enterprise-Wide Software Reuse (EWSR) which
incorporates the Reuse Profile technique. This paper describes some
of the author's earlier work on reuse technology maturation in the
area of change (user or technology-driven) and its implications.

Dr. Karakostas has been developing industry specific architectures
for the finance and banking industry with the purpose of exploiting
such architectures in tasks such as business redesign, systems
evolution and rapid application development.

2   Position
Today there is probably only one characteristic shared by all
technological domains, namely change. Large investments together
with advances in Research and Development result in products and
technologies becoming obsolete at an ever increasing pace. Despite
this the paradigm of domain specific software architectures (DSSA)
advocates reusable and long-lived designs which must withstand the
volatility of their constituting technologies. An obvious criterion for
establishing the suitability of a domain for developing a "change
withstanding" architecture is the stability of the technologies
employed in it.  However this is not a trivial task since domains do
not usually contain single or simple technologies but complexes of
(interacting) technologies. Moreover as it will be explained in Section
2.1.3 there are many different types of technological changes; some
of them, although affecting individual components, may have no
impact on the overall stability of the domain. Additionally, change in
a technology is not always entirely unpredictable. With the exception
of radical (breakthrough) types of technological change it is
sometimes possible to accommodate change in one of the domains
constituent technologies by evolving (transforming) the domain
architecture.

In conclusion, we propose that any candidate domain for reuse
should be examined from the perspective of the set (complex) of
technologies of which it is composed, and the relationship between
them and a suitable architecture defined. In so doing a more fine
grained indication of a domain's stability from the perspective of its
component technologies can be ascertained. This information can be
used to gauge the suitability of the domain for reuse against certain
reuse strategies, or it can be used to monitor or isolate areas of
instability, for example by standardisation constraints. Dependent
upon the stability of the technology, forecasting techniques may be
applied to facilitate the creation of robust, or extensible, components.
It could also be possible to measure the impact of change on the
architecture from either new problems given by the environment or
scenarios for domain improvement to increase market share, for
example.

In the following sections an overview of technology theory is
presented.
2.1    Technology And Its Relationship To Domains
A technology is defined as the set of solution-oriented knowledge
concerned with solving practical problems. It may be embodied in
products and processes, or hardware; it may be in the form of a
technique. [2] suggests that since individual technologies typically
serve little purpose on their own they may be combined to form a
technological complex, a new technological area representing a
service or an end-product. Complexes tend to be relatively long lived
and will only change if the refinement or replacement of their
constituent technologies causes a change in the relationship between
them. Systems are described in this context as the highest level of
technological organisation and are characterised as wide ranging in
space as well as long lived in time. In addition, [3] describes a
correlation between the technical features of a product and the
service characteristics it displays. They identify similarities between
this pattern of mapping and the concept of design. Using these ideas
a domain may be conceived as a layered architecture of technologies
where there is a mapping relationship between the service
characteristics of the domain and the technologies of which it is
composed.

2.2   Technological Development And Technological Discontinuities

The process of technological development is composed of innovations,
many of which are minor improvements on, or adaptations to,
preceding innovations. An innovation will occur if it serves to
increase the existing performance level or offers an equal level of
performance but at a lower cost [4]. As a technology matures so the
emphasis will move towards cost reduction. Technological
development can be understood either in terms of a lifecycle [5] or
by technological discontinuities [6], we describe the latter, figure 1.
Technological Development.

        Era of Ferment                Era of Incremental
Change
        - Design Competition                - Elaboration of
Dominant
        - Substitution                     Design
____|_____________________________|_________________________|__
___Time
Technological             Dominant            Technological
Discontinuity 1            Design 1            Discontinuity 2

Figure 1. Technological Development (from [6])

Technologies emerge as the result of a discontinuity when either an
existing technological paradigm is no longer able to address "needs-
driven" requirements, or a breakthrough technological innovation
opens up a new seam of technical possibilities, a "technology push".
The initial phase of the lifecycle is characterised by a period of
ferment in which there is a rapid advance in the technology linked to
a high number of competing designs in the paradigm. Towards the
end of this phase the main characteristics of the dominant design
begin to emerge. A dominant design [5], also referred to as a
technological paradigm [7], is a single architecture that establishes
dominance over competing solutions in a class and has powerful
exclusion effects over which problems are possible and worth doing.
Thenceforth future evolution of the technology consists of cumulative
improvements where variation takes the form of elaborating the
retained dominant design. Although a paradigm is known by all
industry participants the technological directions which are pursued
within it, technological trajectories [4], are specific to the
organisation. The position of a product on a technology trajectory can
be said to identify its market position vis-ê-vis its competitors.

2.3  Factors Which Precipitate Change And Their Impact

There are several different kinds of problems which force change
and technological progress [2]. They are classified using [8], [9] and
[10] to be:
1. incremental: cumulative improvements to an existing dominant
design
2. micro-radical: these are changes which both disrupt and continue a
dominant design. There are 2 types:
a. modular: caused by the functional failure of an existing technology,
whilst not affecting the relationship between the technologies
themselves
b. architectural: caused by imbalances between related technologies,
though not affecting the existent design of the technologies
themselves
3. radical: occur rarely and are the result of a problem given by the
environment which is not yet solved by any technology.





Figure 2. A Classification of Technological Progress Types, adapted
from [10].

3   Comparison
We understand that the DSSA approach is an attempt, by
standardisation of requirements, to evolve and promote a dominant
design for a particular industry. To do so they have described two
refinement architectures. Structure preserving architectures based
on an object oriented layered model, are instantiated by refinement
of detail corresponding to product variation within the domain.
However, their definition of refinement and its relationship to
incremental, modular, and architectural innovation is not clear. A
second type of architecture defined is transformational,
transformational architectures are said to be both elaborated at the
same time as they are restructured and as such we suggest they are
the result of a radical innovation. Such architectures are not
supported by DSSA. Whilst architectures as layers of technology can
facilitate: incremental, modular, and architectural innovation, apart
from recognising a radical discontinuity they are unable to support it.
We qualify this, however, by saying that a discontinuity may
combine some of the technologies employed in the displaced
paradigm.

We prefer, at this stage, not to further refine the comparisons we
have made since this would involve guesses on our part. Our reason
for attending the workshop is to both clarify our understanding of
DSSA and its relationship to architectures as layers of technology and
for the purpose of feedback from other practitioners and researchers
in the field.

References
[1] Hayes-Roth, F., "Architectural-Based Acquisition and Development
of Software: Guidelines and Recommendations from the ARPA
Domain Specific Software Architecture (DSSA) Program, Teknowledge
Federal Systems, Version 2, October 20 1994.
[2] Laudan, R., "The Nature of Technological Knowledge: Are Models
of Scientific Change relevant", In R. Laudan, ED, Cognitive Change in
Technology and Science.
[3] Saviotti, P.P., Metcalfe, J.S., "A Theoretical Approach to the
Construction of Technological Output Indicators", Research Policy,
13(3), (1984), 141-51.
[4] Biondi, L., Galli, R., "Technological Trajectories", FUTURES,
July/August 1992, 580-592.
[5] Twiss, B., "Managing Technological Innovation", 4th Edition,
Pitman Publishing, 1993.
[6] Anderson, R., Tushman, M.L., "Technological Discontinuities and
Dominant Designs: A Cyclical Model of Technological Change",
Administrative Science Quarterly, 35 (1990), 604-633.
[7] Dosi, G, "Technological Paradigms and Technological trajectories",
Research Policy, 11, (1982), 147-162.
[8] Albernathy, J.M., Utterback, J.M, "Patterns of Industrial
Innovation", Technology Review, 50, (June-July 1978), 41-47.
[9] Durand, T., "Dual technological trees: Assessing the intensity and
strategic significance of technological change", Research Policy, 21,
(1992), 361-380.
[10] Henderson, R.M., Clark, K.B., "Architectural Innovation: The
Reconfiguration of Existing Product Technologies and the Failure of
Existing Firms", Administrative Science Quarterly, 35, (1990), 9-30.

Bibliography

Sadie Legard is an EPSRC-CASE PhD student in the Department of
Computation at the University of Manchester, Institute of Science and
Technology (UMIST), where she developing a paradigm for software
development based on Enterprise-Wide Software Reuse. Sadie has
worked on several collaborative projects with British
Telecommunications PLC. in the areas of domain analysis and re-
engineering, and is a member of the SER-ESPRIT project for reuse
technology dissemination in Europe. Her research interests include,
but are not limited to, software reuse, software architectures,
business and software re-engineering, the strategic role of IT,
knowledge acquisition for organisational learning, and technological
evolution.

Dr. Karakostas is a lecturer in the Department of Computation,
UMIST. He has participated in many UK and European R&D projects
on software reuse and evolution. He is currently the technical
manager of a European (ESPRIT) project on software evolution in
banks (EUROBANQUET) and also participates in a program for reuse
technology dissemination in Europe (SER). His research interests
include object oriented systems modelling, business and software re-
engineering and the application of AI to software engineering.

Applying Cluster Analysis to Software Reuse

Wayne C. Lim

1535 Fairway GreenCircle
San Jose, CA 95131
Email: [e-mail]

Abstract

Cluster analysis, a method of classifying objects based upon specific
features, has many potential benefits in software reuse. At the
Manufacturing Productivity section of Hewlett-Packard, we applied such
an analysis to a set of reusable assets and identified "include file"
configurations that would minimize the maintenance effort of such files.
In this paper,we define cluster analysis within the context of group
technology and present an example of how this analysis was applied and
utilized.

Keywords: cluster analysis, group technology, manufacturing concepts,
domain analysis.

Workshop Goals: share perspectives on managerial and organizational
aspects of reuse; profile interesting reuse academic and practitioner
experiences in upcoming book.

Working Groups: Reuse management,organization and economics; Reuse
process models; Reuse maturity models; Reuse Metrics; Reuse Strategic
Planning; Reuse Assessments.

1   Background

The purpose of group technology in manufacturing is to utilize
economies of scope by identifying and exploiting the similarities in the
partsto be manufactured and the sequence of machines that are
necessary for the processing of those parts.  Parts are classified into
families on the basis of characteristics such as size and geometry.
Machines which are used to process the part families are situated in
proximity to each other in "machine cells".

Wemmerlov and Hyer [1] highlight three ways that group technology
benefits are achieved:

By performing similar activities together, less time is wasted in changing
from one unrelated activity to the next

By standardizing closely related items or activities, unnecessary
duplication of effort is avoided

By efficiently storing and retrieving information related to recurring
problems, search time is reduced

2   Position

One of the means for family identification in group technology is cluster
analysis. Cluster analysis is "concerned with grouping of objects into
homogeneous clusters (groups) based on the object features. [2]" Cluster
analysis was applied to software reuse at the Manufacturing Productivity
(MP) section of the Software Technology Division of HP to solve a
problem concerning the maintenance of their reusable assets, called
"utilities".

The MP section produces large application software for manufacturing
resource planning. The MP reuse program started in 1983 and continues
to the present. The original motivation for pursuing reuse was to
increase the productivity of the engineers to meet critical milestones [3].
MP has since discovered that reuse also eases the maintenance burden
and supports product enhancement. Reuse was practised in the form of
reusable assets (application/architecture utilities and shared files) and
generated code. Total code size for the 685 reusable assets was 55
Thousand lines of Non-Commented Source Statements (KNCSS).The
reusable assets were written in Pascal and SPL, the Systems Programming
Language for the HP3000 Computer System. The development and target
operating system was the Multi-Programming Environment (MPEXL).

The utilities at MP are many (685 utilities) and small in size (lines of
code range from 14 to 619 Non-Commented Source Statements). In
manufacturing systems software developed by MP, a transaction
constitutes a cohesive set of activities used for inventory management
and is a subunit of the manufacturing systems software.

Within each transaction,c alls are made to the appropriate utilities as
required which are contained in an include file specific to the
transaction. However, this has led to a proliferation of different include
files since each transaction isusually created by a different engineer.
When a utility is modified, all the include files which contain this utility
need to be identified and updated with the new version. This has
resulted in a tremendous amount of effort.

In an effort to reduce the potential amount of effort required for future
updates, an analysis using cluster analysis was conducted on the use of
utilities by transactions.

First, a 13 x 11 matrix was created by designating the rows as
transactions and the columns as utilities. (Figure 1). A"1" indicates that
a transaction makes a call to the particular utility, and a "0" indicates
that a transaction does not make a call to the particular utility.

Figure 1: Input Matrix: (Rows are transactions; columns are reusable
assets)

1 0 1 0 0 0 0 0 0 0 0
0 0 1 0 0 0 0 1 0 0 1
0 0 1 0 0 0 0 1 0 0 0
0 0 0 0 0 0 0 1 0 0 1
0 0 1 0 0 0 0 0 0 0 1
0 0 1 1 0 0 0 0 0 0 1
0 0 1 0 0 0 0 0 0 0 0
0 1 0 0 1 0 1 0 0 0 1
0 1 0 0 1 0 1 0 0 0 0
0 1 0 0 1 1 1 0 1 1 1
0 1 0 1 1 1 1 0 1 1 1
0 1 0 1 0 0 1 0 0 0 1
0 1 0 1 1 0 1 0 0 0 1

Columns (Reusable assets):

1=Adj-summary-qty
2=Autobofill
3=check'store'um
4=invalid-fld-check
5=potency-inv-qty
6=prep'for'pcm
7=print-document
8=report-neg-qty
9=send'to'pcm
10=update'pcm'buff
11=write-stock-file

Rows (Transactions):

1=adjhand
2=issalloc
3=isseu
4=issord
5=issunp
6=issbo
7=move
8=recinloc
9=recinsp
10=recwo
11=recrun
12=recpopt
13=recpoit

The matrix is then used as an input file to a clustering algorithm
provided by Dr. Andrew Kusiak of the University of Iowa.

The output solution, as shown in figure 2, reorders the reusable assets
into "clusters". The results suggest that we place utilities (depicted by
the columns) 1, 3 and 8 into a single include file for transactions 1 to 7.

Utilities 2,5,6,7,9,10 should be placed into another include file for
transactions 8,9,10,11,12,and 13.

Utilities 4 and 11 can either be placed in both include files or a separate
one may be created for them.

Figure 2: Cluster Analysis Solution: (Rows are transactions; columns are
reusable assets)

                    1 1
      1 3 8 2 56 7 9 0 1 4
Row 1 1 1
    2   11             1
    3   11
    4    1            1
    5   1             1
    6   1             1 1
    7   1
    8      1 1   1     1
    9      1 1   1
   10      1 1 1 1 1 1 1
   11      1 1 1 1 1 1 1 1
   12      1     1     1 1
   13      1 1   1     1 1

Benefits of Cluster Analysis for Reuse Cluster analysis is useful in the
creation of include files with specified utilities that would reduce the
effort required to maintain the files. In our example with the MP section,
prior to cluster analysis, thirteen individual include files were
maintained; one for each transaction. By utilizing cluster analysis, we
were able to identify the commonalities and differences within the
thirteen include files and specify a core set of two include files. By
reengineering the thirteen include files into two, the number of files to
maintain can be reduced by 85

Cluster analysis also has further applications in software reuse. It may be
used to identify"families of systems" i.e. those that share the same
features. For example, we can apply cluster analysis to a matrix where
the columns depict the features of software systems/products and the
rows,the software systems/products. The analysis would cluster the
features to the software systems/products, thereby helping to identify
families of systems which share common features. This information may
be useful in determining specific reusable assets to create.

3   Comparison

Some researchers have utilized cluster analysis for the purpose of reuse
classification. For example, Maarek and Kaiser [4] describe the useof
conceptual clustering to classify software components. Taxonomies of
software components are created "by using a classification scheme based
on conceptual clustering,where the physical closeness of components
mirrors their conceptual similarity." The objects are gathered into
clusters where they are more 'similar' to each other than to the members
of other clusters.

4   Acknowledgements

My acknowledgements to Dr. Andrew Kusiak, Dr. Sylvia Kwan and Alvina
Nishimoto for their help and input to this paper.

References

[1]U. Wemmerlov and N. Hyer, Chapter 17, Handbook of Industrial
Engineering. John Wiley & Sons,1992.

[2]A. Kusiak and W. Chow, " Decomposition of Manufacturing Systems,"
IEEE Journal of Robotics and Automation, vol. 4, October 1988.

[3]A. Nishimoto,"Evolution of a Reuse Program in a Maintenance
Environment," in 2nd Irvine Software Symposium, March 1992.

[4]Y. Maarek and G. Kaiser,"Using Conceptual Clustering for classifying
reusable Ada code," in Using Ada: ACM SIGAda International Conference,
ACM Press, New York, December 1987.

5   Biography

Wayne C. Lim specializes and consults in the strategic planning,
economic, organizational, and metric issues of software reuse. His
involvement in software reuse began in 1983 as a member of the Ford
Aerospace Reuse Group researching reuse library issues. Mr. Lim
completed his MBA degree at Harvard University, graduate engineering
coursework at Stanford University, and an undergraduate degree in
mathematics from Pomona College. He is the author of a forthcoming
book, Managing Software Reuse, to be published by Prentice-Hall.
Trade-off between Flexibility and Efficiency in Recombining

Reusable Components

Beat Liver and Dean T. Allemang

Research & Development
Swiss Telecom PTT
3000 Berne 29, Switzerland
Tel. [phone] f 50 64 j 44 72 g
Email f liver j allemang [e-mail]

Abstract

We outline the framework ZD for constructing libraries of reusable
software components. The approach is a formal one, in that the
semantics of the representation is based on proofs of program
correctness. The correctness of combinations of library components is the
central issue of this paper. Modular correctness proving approaches exist
and are computationally optimal. Our position is that these approaches
are too inflexible to configure novel combinations using from library
components. In the ZD framework, we resolve this problem with a
method called proviso proving and propagating.

Keywords: Reuse, formal verification, modular design and configuration

Workshop Goals: Learning; networking; advance state of theory of
reusable position papers.

WorkingGroups: Reuse and formal methods, Reusable component
certification, Reuse and OO methods and technology

1  Background

Dean Allemang began his contribution to software reuse with his
dissertation in 1990. Since that time, he and Beat Liver at Swiss Telecom
PTT Research and Development have extended the method described
there to include support for software configuration,diagnosis, debugging
and repair [1, 2]. This work will culminate in Mr. Liver's dissertation,
whichwill include an implementation of the software modeling language
ZD.

2  Position

For configuration and design, it is very important to formally reason
about the correctness of recombinations of reusable components from a
library of such components. Note that these components are not
programs themselves, but they are functional models of programs, that is
descriptions of the function of programs.

In addition to the correctness of combinations,the computational
efficiency of proving the correctness of combinations as well as the
flexibility to recombine components is important. Our position is that:

Combining local certifiable components is computationally optimal, but
at the cost of flexibility. This flexibility can be achieved by paying with
computational effort (theorem proving, in the worst case) at
configuration time.

We are implementing our representation (described in the next section),
in which the trade-off between flexibility and design-time computational
expense can be made, so that this trade-off can be more systematically
studied, in the context of a growing library of reusable components.

3  Functional Representation ZD

Our functional representation, called ZD (that stands for
Zweckdarstellung and is pronounced`Zeddy') is a further development of
Allemang's version [3] of FR [4].

A function consists of a specification, an implementation and
requirements.

A function specification is defined as an input and output partial state
of the system being described, a partial state called additional result,
and a condition called the proviso. A function achieves the output
partial state (and the additional result), if and only if the proviso holds
in the context of use. For example, a function that moves the content of
a variable ?loc1 to the variable ?loc2 is defined by the function move of
figure 1. Using Hoare semantics [5],move's input state is P(?loc1) and its
output state P(?loc2), if the proviso empty(?loc2) is satisfied. In addition,
move achieves empty(?loc1).

The input and output state form the index of library functions. Both
partial states are described in the same state description language. A
state description language (SDL) provides the terms for partial state
descriptions, as well as the semantics of the terms. Hence, SDLs are
mathematical theories (or combinations of mathematical theories),like
STRING, INTEGER, and so on, which are used in model-oriented software
specification approaches (Resolve [6], Larch shared language [7]). In this
paper, the formal properties of SDLs are not studied, because they are
independent of ZD itself. A more detailed discussion of SDLs is given in
[3, 8].

                  DevSpecRecord
                   ParametersP;?loc1; ?loc2
                   FunSpecmove
                    If     P(?loc1)
                    ToMake P(?loc2)
                    Providedempty(?loc2)
                    AddRes empty(?loc1)

                  DevImpAssignment-Record
                   Rep(x) : x
                   Implementationmove

                              P(?loc1)

                    UsingFunction
                     "?loc2:=?loc1"

                                -?
                         P(?loc2) ^ empty(?loc1)

                      Figure 1: The Record.

The main reason for the separation between the additional result and
output state is that they might be described by different SDLs. In our
example,the concept empty() is defined by the function move, i.e., a
variable is empty if its value is moved to some other location. This
function is applicable to data records that are indestructible values.  The
function move is a reusable representation of this intention, rather than
any particular program code. Therefore, it is possible to represent in ZD
information that is usually represented in documentation, wishful
variable names, or not at all [3, 8].

A function implementation defines how its function specification is
achieved by a combination of other functions. This description takes the
form of a state-transition graph, where the states are partial state
descriptions. A transition is labeled with the function that achieves this
transition. This function is not necessarily known at implementation
construction time; the function is really a function requirement. A
function requirement is a specification of the function required by the
implementation. In contrast to a function specification, a requirement
does not have a proviso or an additional result. In figure 1,the
implementation of move is a state-transition graph with a single
transition. To be precise, ``?loc2 := ?loc1'' should be a function name
that refers to the semantic description of an assignment operation (in
Hoare semantics).

A generic device is a reusable component in ZD and consists of a device
specification, one or more device implementations, and device
requirements. A device specification specifies the function of the device.
A device implementation describes how this function is achieved using
services provided by other devices. This description requires functions of
otherdevices. The required services of another device are specified as a
device requirement.

A generic device specification consistsof a set of parameters and a set of
functions. An example is the DevSpec Record in figure 1. Devices that
maintain state information, like stacks,queues, and so on, also have a
persistent abstract state.

A generic device implementation consists of a representation function
and function implementations for the function specified in the device
specification. A representation function (Rep) [9] formalizes the change
of abstraction levels and, hence, SDLs.

The entities specification, implementation and requirement are common
in component-oriented reuse approaches, because they make it possible
to prove the correctness of a component at its construction time. In the
next section, we show how ZD enables one to trade off configuration
flexibility against computational complexity.

4  Comparison: Recombining Components

A major desiderata for a recombination method is the verification of the
correctness of a combination of software components. For this purpose,
we would like to to associate with a component its correctness proof, so
that software components as well as proofs would be reusable. The
associated correctness proof is incomplete, because the proofs associated
with subcomponents are not known at the construction time of the
component. Simply associating these partial proofs to their
corresponding components is not feasible, because proving
recombinations using these partial proofs incurs, in general, the cost of
recursive proof completion, and, hence, it is computationally
intractable.

In the sequel, we present and compare two more elaborate association
approaches  together with their implications for reuse, in particular with
respect to flexibility and efficiency. Both approaches are supported by ZD
and, hence, can be combined to achieve a better overall recombination
method.

A proof can be modularized,if one requires that the components cannot
interfere with one another [10,11, 6]. To be more precise, a module is
local certifiable if and only if the correctness of a module can be verified
solely on the basis of its specification, its implementation and the
specification of the modules used in its implementation.

Local certifiability requires that the operations of the module (the
interface) be leak-free abstractions (of the realization of the module).
This condition is only satisfiable for modules that satisfy additional
conditions [6]. Consequently, local certifiability restricts the granularity
of reusable components to modules. We call devices that represent local
certifiable modules local certifiable devices [8].

The computational complexity of proving the correctness of
recombinations of local certifiable devices is optimal, because the
correctness proof is just the combination of the correctness proofs
associated with the local certifiable devices. But, there exists a trade-off
between optimal efficiency of correctness proving and the flexibility to
recombine devices. In [8],we show that it is not feasible to build libraries
of powerful local certifiable generic devices. Local certifiability requires
the designer to anticipate, specify, and prove all possible behaviors of
such a component in advance. Consequently,the flexibility required to
produce novel configurations of library components is not supported by
local certifiable components. This missing flexibility is caused because
local certifiability eliminates not only interferences that result from
leaky abstractions but also interactions that are essential for achieving
some functions.

ZD supports contextualized devices proposed by Allemang [3].
Contextualized devices are devices that model interactions by provisos in
a reusable way. An example is the Record given infigure 1.

In contrast to local certifiable devices, contextualized devices enable one
to configure existing devices in novel ways to achieve goals not foreseen
at the time of their construction [8].This is possible, because, first, each
device specifies (by provisos and additional results) under what
conditions an interaction is acceptable but not the interaction itself;
and, second, the correctness of interactions is verifiable by proviso
proving and propagating.

This flexibility has a price. First, proviso propagating and proving is
necessary for handling interactions. This is more expensive
computationally than simply comparing function specifications, but the
successful modularization of large software indicates that such
interactions are typically local. Second, a contextualized device has to be
a `grey box', that is, a device implementation has to be provided that is
sufficient for proving provisos. In contrast, a local certifiable device has
to reveal only its requirements, so that it can be a black box. Naturally,
black boxes are preferable in a commercial setting.

Fortunately, the two granularites are complementary and both kinds of
devices can be mixed. In the case of local certifiable devices, proviso
proving and propagating is reduced to showing that the proviso of a
service is implied by the initial state of therequirement.

References

 [1]B. Liver,"Repair of communication systems by working around
failures,"Journal of Applied Artificial Intelligence, vol. 9, no. 1, pp. 81-99,
1995. Special Issue on Function-Based Reasoning Part2.

 [2]B. Liver,"Modeling software systems for diagnosis,"in Working Notes of
the 5th Int. Workshop on Principles of Diagnosis, (New Paltz, NY), 1994.

 [3]D. T. Allemang, Understanding Programs as Devices. PhD thesis, The
Ohio State University, 1990.

 [4]Sembugamoorthy, V. and Chandrasekaran, B., "Functional
Representation of Devices and Compilation of Diagnositc Problem-Solving
Systems," in Experience, Memory and Reasoning (J. Kolodner and C.
Riesbeck, eds.), pp. 47-73, Lawrence Erlbaum Associates, 1986.

 [5]C. Hoare, "An axiomatic basis for computer programming,"
Communications ACM , vol. 12, no. 10, pp. 576-580,583, 1969.

 [6]J. Hollingsworth, Software Component Design-for-Reuse: A Language
Independent Discipline Applied to Ada. PhD thesis, Dept. of Computer
and Information Science, The Ohio State University, Columbus, OH, 1992.

 [7]J. V. Guttag and J. J. Horning,Larch: Languages and Tools for Formal
Specification. Texts and Monographs in Computer Science, Berlin:
Springer, 1993.

 [8]B. Liver and D. T. Allemang,"A functional representation for software
reuse and design,"Software Engineering and Knowledge Engineering, vol.
Special Issue on Evolutionary Approaches to Software Engineering, 1995.
in press.

 [9]W. Wulf, R. London, and M. Shaw, "Abstraction and verification in
alphard:  Introduction to language and methodology," in ALPHARD:
Form and Content (M. Shaw, ed.), Computer Science Monograph, pp. 15-
60, Springer, 1981.

[10]J. Krone, The Role of Verification in Software Reusability. PhD thesis,
Dept. of Computer and Information Science, The Ohio State University,
Columbus, OH, 1988.

[11]G. W. Ernst, R. J. Hookway, J. A. Menegay, and W. F. Ogden,
"Modular verification of Ada generics," Computer Languages, vol. 16, no.
3/4, pp. 259-280, 1991.

5  Biographies

Beat Liver received the diploma in Informatics from the Swiss Federal
Institute of Technology (ETH) in Zurichin 1989 with a specialization in
communication networks, distributed systems and computer-aided tools
for VLSI. He joined the research and development directorate of the Swiss
Telecom in 1989. He is pursuing a Ph.D. on the topic of functional
models for managing communication system software. His main area of
interests are computer-aided tools for telecommunication network
management. He is also a member of the ACM, and AAAI.

Dean Allemang received his B.S from the Ohio State University, and a
M.Sc. from the University of Cambridge. He completed his Ph.D. at Ohio
State in 1990 on the topic of using Artificial Intelligence modeling
techniques to model software. Since that time, he has pursued this and
other knowledge modeling work in a series of postdoctoral appointments
in Switzerland. He is currently working at Swiss Telecom PTT research
and development on modeling telecommunications applications.
Domain Engineering - Varying Rationales & Approaches

Fred Maymir-Ducharme, PhD

USAF CARDS / Loral Defense Systems
12010 Sunrise Valley Drive, Reston VA 22091
Tel: [phone]
Fax: [phone]
Email: [e-mail]

Abstract

Systematic reuse is not for everyone. The long term benefits of a
thorough domain analysis that captures the requirements of previous, as
well as future systems within the domain - and the development of a
flexible architecture, engineered to maximize reusable components and
support the application-specific variances of the domain - may not
mean much to an organization only tasked with developing a single
system for the government. It's generally far more economical for a
contractor, for instance, to instead take the opportunistic reuse
approach and focus on the short-term gains, minimizing the reuse costs
to only those directly applicable (beneficial) to the specific system being
developed. There are two major strategies to domain engineering:
systematic and opportunistic.  These strategies vary in both costs and
benefits; hence they appeal to very different customers. Conflicts may
arise in a government-contractor relationship, even when both sides
agree on the benefits of reuse and commit themselves to implementing
reuse - because of these conflicting strategies. The intent of this position
paper is not to evaluate the two and convince the reader that one is
better than the other; but rather, to illustrate that the two have different
economic justifications and are geared towards different organizational
frames of reference. The paper also suggests combined approach, which
attempts to find a middle ground to meet the short and long term reuse
needs of government-contractor relationships. The results of this
workshop can be of considerable benefit to both,the DoD and private
industry organizations that realize the benefits of domain engineering
but don't understand the implications of selecting one
approach/method over another.

Keywords: Domain Engineering, Domain Analysis, Software Architectures,
Reuse Method(s) Selection, Business Case Analysis for Opportunistic
versus Systematic Reuse.

Workshop Goals: Identify rationales for opportunistic domain
engineering, identify rationales for systematic domain engineering
discuss whether some methods support one approach more than the
other, and develop a business case analysis template for selecting either
approach.

1   Background

The Sustaining Base Information Systems (SBIS) program has very
ambitious reuse goals - short-term goals for Loral Federal Systems, the
prime contractor, and long-term goals for the US Army Sustaining Base
Automation (SBA) program.

There are over seventy applications planned for development under the
SBISprogram, and these are envisioned to fit into approximately ten
domains. As part of a USAFComprehensive Approach to Reusable Defense
Software (CARDS)/ SBIS Partnership, Fred M-D is leading the SBIS Domain
Engineering Team efforts [1], using a hybrid of the ARPA/STARS
Organization Domain Modeling (ODM) [2] and the Defense Information
Systems, Software Reuse Program (DISA/SRP) Domain Analysis and Design
Process (DADP)[3] methods, to realize both, short-term opportunistic
reuse benefits and long-term systematic reuse benefits.

2   Position

Systematic reuse is not for everyone - having a sports car doesnt help
you get there any faster if you're stuck in rush-hour traffic. On the other
hand, if you're in Germany and in a hurry - you're better off in a Porsche
911 Turbo Carrera on the Autobahn than in a Geo Metro. There are two
major strategies to domain engineering: systematic and opportunistic.
The long term benefits of a thorough domain analysis that captures the
requirements of previous, as well as future systems within the domain -
and the development of a flexible architecture, engineered to maximize
reusable components and support the application-specific variances of
the domain - may not mean much to an organization only tasked with
developing a single system for the government. It's generally far more
economical for a contractor, for instance, to instead take the
opportunistic reuse approach and focus on the short-term gains,
minimizing the reuse costs to only those directly applicable (beneficial)
to the specific system being developed.

The two major reuse strategies - systematic and opportunistic - vary in
both costs and benefits; hence they appeal to very different customers.
Conflicts may arise in a government-contractor relationship, even when
both sides agree on the benefits of reuse and commit themselves to
implementing reuse; these may be due to conflicting reuse strategies. The
intent of this position paper is not to evaluate the two and convince the
reader that one is better than the other; but rather, to illustrate that the
two have different economic justifications and are geared towards
different organizational frames of reference. The paper suggests a
combined approach,which attempts to find a middle ground to meet the
short and long term reuse needs of government-contractor relationships.

The opportunistic approach is focused on the development of a single
system. The major focus of the (opportunistic) domain analysis (e.g.,the
DADP method) is to identifythe are as of greatest commonality within a
domain, to facilitate the search and acquisition of applicable, reusable
components. The goal is to maximize the use of existing components and
minimize the development of new components. The next step, domain
design and architecting, is driven by the goal of utilizing the maximum
number of components identified during the domain analysis and found
by searching numerous reuse libraries and repositories.

The resulting architecture is "bent and tweeked" and made to conform
to the maximum number of reusable software components as possible.
The benefits are thereby realized in short-term - maximizing the reuse of
components can save money and reduce the development time.

Alternatively,the systematic approach is focused on the development of
a family of similar systems (optimally, a product-line). Hence, the focus
is just as much on the (context-sensitive) variances between the family of
systems within the domain as on the commonalities. A more detailed
domain analysis (e.g., the ODM method) may be desired, to ensure that
the resulting domain analysis captures not only the current domain
requirements (exemplified by associated legacy systems and the specific
system being developed ),but also the anticipated future requirements of
related systems. The ensuing software architecture and domain design
are engineered to maximize the domain commonalities, and to support
application-specific variances.

A development organization (e.g.,a DoD contractor) or a program
manager (e.g., a DoD PM) may be more inclined to select the
opportunistic domain engineering approach for purely economic reasons
- the task is limited to the development of a single system, within a
given schedule and budget. The incentives and rationales for applying a
systematic domain engineering approach make more sense to an
organization such as AT&T, which has well defined domains (e.g.,
electronic switching systems) and product lines (e.g.,5ESS and 4ESS
"generics").An organization's business model must be considered when
selecting the domain engineering method(s) to be applied. In cases with
multiple organizations as stake-holders, each organization's business
model must be considered.

The SBA model described in the background section is a good example
where each organization's business model differs enough to each warrant
a different reuse approach and method. The SBA program office stands
to benefit from the systematic approach because of the size of the
program (multiple domains and over seventy applications) and the
longevity of the program (the program plans to define and develop
future sustaining base systems to meet new needs, and to extend the SBIS
applications developed to meet the evolving needs of the base in the
next several decades.) Alternatively, the development organization needs
to consider its bottom line - revenue - cost = profit. The opportunistic
approach is more appealing to the contractor for obvious reasons,as
cited earlier.

The SBIS Domain Engineering Team took several factors into
consideration in selecting the domain engineering methods to apply on
the SBISprogram. One of the factors considered was each stakeholder's
business model and strategic goals. In order to resolve the conflict
described above and attempt to present a Win/Win solution,the team
elected to select a hybrid- method approach, integrating DADP and ODM
methods. The resulting method was then tailored to meet the project-
specific needs (e.g., processes, environments and applications) of SBIS.
[1]

The DoD Software Reuse Initiative (SRI)Software Reuse Vision and Strategy
(SRVS) [4] recognizes the value of applying Domain-Specific,
Architecture-Centric, Process-Driven, Technology-Assisted techniques to
develop and maintain DoD software systems. One of the strategies of the
DoD is to change it's business model (and organizations) to better
leverage off these Reuse Technologies. By having
DoDcenters/organizations chartered to develop and manage domains (as
opposed to single systems),the government expects to develop the
necessary infrastructure and incentives to support the SRVS. As the
government undergoes this transition, it will need guidance on which
approach makes most sense and which methods will best support the
approach selected.

The results of this workshop can be of considerable benefit to both, the
DoD and private industry organizations facing similar decisions.

References

[1]"Draft SBIS Domain Engineering Project Plan, Comprehensive Approach
to Reusable Defense Software and Army Reuse Center," tech. rep., May
1995.

[2]"Organization Domain Modeling (ODM) Guidebook (Version
1.0),STARS-VC-A023/01 1/00, ARPA Software Technology for Adaptable,
Reliable Systems," tech.rep., March 1995.

[3]"Domain Analysis and Design Process, (Version 1.0), DISA/JJIEO/CIM
DISA Software Reuse Program," tech. rep., 1993.

[4]"DoD Software Reuse Initiative Vision and Strategy Office Secretary of
Defense (OSD)," tech. rep.,1992.

3   Bibliography

Dr. Maymir-Ducharme has over 15 years of software engineering
experience in industry and with the DoD. He has been involved with the
development and application of advanced software technologies since
the early 80s. He was the principal engineer on various AT&T Bell Lab's
ISDN features, served on the OSDAdvisory Board on Ada, and was
intimately involved with Ada9X as a member of the Ada Technical
Advisory Group(TAG) and ANSI Canvassers Group. Fred worked at the
SEI as a Resident Affiliate while on the ARPA STARS program, developing
process models and guidebooks for the SEI/STARS Process Asset Library
(PAL)project. He has numerous publications on Ada, Reuse and Software
Engineering.

Dr. Maymir-Ducharme worked for AT&T Bell Laboratories for several
years before transitioning to the Department of Defense. He is now with
Loral Defense Systems, working on the Air Force Comprehensive Approach
to Reusable Defense Software (CARDS) Program. Fred's most recent focus
has been on reuse technology transition, which entails the application
and adoption of Domain Engineering Technologies (e.g., concepts,
processes, methods and tools) to enhance the software engineering
discipline. Fred is the technical leadand manager of the A.F. CARDS
Partnership Implementations project, whose major thrust is to support
reuse technology transition within DoD organizations.

Dr.  Maymir-Ducharme received his BS in Computer Science from the
University of Southern California (USC) and his PhD in Computer Science
from the Illinois Institute of Technology (IIT). As an adjunct professor at
IIT, Fredtaught graduate Software Engineering and Ada courses.
Conceptual Predesign: A Platform for the Reuse of Requirements
Specifications


Heinrich C. Mayr

Institut fƒr Informatik
Universitèt Klagenfurt
Universitètsstraºe 65-67
A-9020 Klagenfurt
Email: [e-mail]

Abstract

Software reuse is not only a matter of recurring, within a software
development process, to programs, modules, class definitions, etc.
that have been stored in a software repository during former
development projects.  It also may be extended to the reuse of
"higher" software documents like (parts of) logical or conceptual
schemata or even informal requirement specifications.  In this case
reuse decisions are not only made by designers and developers but
also by end users in their role of requirements providers.  In order
to set them into a position to do so economically we introduce,
between requirements analysis and conceptual designer, an
additional phase into the information system life cycle: the so called
conceptual predesign.  It comes with a glossary model, the
vocabulary of which demands less abstraction abilities than semantic
models as they are known from methods for conceptual design, resp.
objected-oriented analysis.  The contribution will illustrate the kind
of design that is possible within such a framework.

Keywords: Conceptual design, conceptual predesign, requirements
analysis, glossary model, schema reuse, domain knowledge.
Workshop Goals: Learning about other approaches to the reuse of
results of earlier life cycle phases; a critical discussion of our
approach with expert colleagues; identifying aspects of reuse process
models and methods that are "generalizable" in the sense that they
could form the basis of a comprehensive reuse methodology.
Working Groups: Reuse process models, domain analysis/engineering,
reuse and OO methods and technology, design reuse.

1   Background

There are two main aspects of software reuse I am/was involved in
so far:

-    Component reuse on the implementation level; as may be seen
from my biography, before "coming back" to the university I was for
nearly ten years engaged in a medium sized software company
founded by myself and a colleague.  Greatest possible reuse was our
development philosophy there.  The products of this (still running)
company are branch specific multiuser information systems that are
constructed (configured and customized) on the basis of a
standardized, reuse oriented system architecture out of a module
base of actually about 6000 components.

-    Reuse of domain knowledge: Back to the university one of my
main research interests is to contribute to the definition of an object
oriented conceptual design technique that really enables a
cooperation between information providers (normally end users) and
information collectors (system analysts and/or engineers), for details
see the subsequent "position".  Within this context, reuse again is an
essential issue with substantial influences on the methodology and
process model we propose.
2   Position
Today, the notion of Software is used in a rather broad sense: It
denotes program(s System)s that are written in a specific
programming language as well as any kind of design documents
produced in earlier phases of a system development process.  As a
consequence, software reuse is not only a concern of the
implementational level but also of requirements analysis, conceptual
design and logical design.  We concentrate on the former two, that,
compared to reuse in later development phases, come with the
substantial difference that the end users/information providers have
to participate in reuse decisions.  They have to decide with respect to
their requirements, what information should be entered into the new
design, and which information should be changed or rejected.

The actual state of the art in conceptual design is that of object
oriented analysis (OOA).  There are numerous OOA techniques "on the
market" (see [3,5,6,9]) and they are mostly argued to be viable
platforms for the communication with end users.  My experiences
from many projects in several business branches show, however,
that end users are not willing or able to accept the level of
abstraction that is induced by such approaches (and that has to be
taken in order to reach the goals of conceptual design, namely
completeness and disambiguity).  Forcing them mostly leads to a
rather naive use and, thus, to rough results that have to be
completed by the analyst/designer without a chance for the end user
to judge about the validity of such completions.

Therefore, requirements analysis should be carried out on an
informal, natural language level for supplying as much information
and UoD facets as possible.  On the other hand, when using natural
language for requirements collection, designers pay a lot of work for
the mapping of natural language descriptions into the notions of a
conceptual model.

For these reasons, we propose to introduce, between requirements
collection and conceptual design, a phase that we call conceptual
predesign [7,8] that is to bridge the gap between the informal level
of requirements collection and the abstract level of conceptual
design.  Conceptual predesign again is conceptual because of the fact
that it uses a semantic model, i.e., a controlled vocabulary with
explained but not formally defined notions.  The lower level of
abstraction is gained by the choice of the particular notions of the
vocabulary and of their representation, for which we use a glossary
approach (based on the early work collected in [2]).  The main
notions are: thing, connection, operation, event, and constraint.  Note
that these notions are used in a generic sense (as is usual in semantic
modeling), i.e., have instances (extensions) in a preschema, that again
have instances in the UoD.  For each notion a glossary is introduced
with slots for a set of attributes that characterize aspects of the
notion in question.  In addition a so called sentence glossary is used
as a repository for the natural language requirement statements and
that is referenced by entries of the other glossaries.  Each of these
glossaries represents an important aspect of an UoD.

Gloassaries form a basis for communication between end user and
designer.  This function makes it possible, to use glossaries not only
for the documentation of requirements but also for the reuse of
already documented requirements:  They act as containers of
knowledge from which information can be drawn as a starting point
for discussion.

The main question is, what kind of information can be reused?  A
schema of an UoD as a whole will certainly be something that is
individual.  But pieces of that schema might be invariant within a
given application domain and thus being drawn into the new schema.

Let us assume that things like "person", "manager", "employee",
"customer", "representative", "name", "customer-number" are defined
in a UoD X and that they are invariant.  Then the designer can show
these things (i.e., their glossary entries) to the end user and ask him
if he agrees that they are part of the new schema Y.  In the same
way we might reuse connections and related information as well as
information of the other glossaries.

The connections which represent that "a customer is a person",
"manager is a person", and "an employee is a person" may also be
invariant over several UoD's.  The same is true for connections like "a
person has a name" or "customers buy products".  For the
specification of the contents of the operation glossary, it might be
important to know which operations exist, the operation structure of
these operations, just as information about the location of execution
of an operation.  Reusable kinds of information in the event glossary
are again the operations involved in an event as well as general
specifications of the pre- and postconditions of an event.

Which kinds of information are reused and to what detail this is done
is within the responsibility of the designer and his requirements
providers.  To support them, we propose a process model that starts
with an initial glossary set called "knowledge base" that is an
abstraction/generalization of glossaries from former projects.  Its
contents are the starting point of discussions with the end user, and
therefore, for information reuse.

The process model as well as the conceptual model will be presented
at the workshop.

3  Comparison
There is some work on the reuse of conceptual schemata, e.g., in the
context of Chen's entity relationship model (ERM) and its derivatives
[1,4].  As far as I know however, besides re-engineering approaches
using former requirements specifications there is no comparable
method of re-using glossaries in conceptual (pre-)design.
References

[1]    Bellizona, R., Fugini, M.G., and de Mey, V.  Reuse of
Specifications and Designs in a Development Information System,
1993.

[2]    Ceri, S. (ed.) Methodology and Tools for Database Design.  North
Holland, 1983.

[3]    Coad, P. and Yourdon, E. Object Oriented Analysis.  Prentice Hall,
1991.

[4]    Eder, J., and Welzer, T.  Meta Data Model for Database Design.
In (Marik, V., Wagner, R. eds.) Database and Expert Systems
Applications.  DEXA 93, Prague, Sept. 6-8, Springer Verlag, 1993.

[5]    Jacobson, I. Object-oriented software engineering: a use case
driven approach.  Addison-Wesley, 1993..

[6]    Kaschek, R., Kohl, C., Kop, Ch., and Mayr, C.  Characteristics of
OOA Methods and Tools.  A First Step to Method Selection in Practice.
(to appear).

[7]    Kop, Ch., and Mayr, H.C.  Reusing Domain Knowledge in
Requirements Analysis.  In (GyÜrkÜs, J. et al. eds.) Proc. Re '94, Bled,
1994, pp. 133-147.

[8]    Mayr, H.C., and Schnattler, M.  Vorkonzeptuelle und
konzeptuelle Dynamik-Modellierung.  In [SR 93], pp. 3-18.

[9]    Rumbaugh, J., Blaha, M., Premerlani, W., and Lorensen, W.
Object Oriented Modeling and Design.  Prentice Hall 1991.

Biography

Heinrich C. Mayr is Professor at the Department of Informatics of the
University of Klagenfurt.  He leads research on design methodologies
for business information systems, on information system
architectures and on computer aided support for the software
supporter.  Actually he also is the Dean of the faculty of management
sciences and informatics of the university of Klagenfurt.  He is a
member of the board of the Austrian Computer Society and he is the
speaker of the technical committee 2 (Software Technology and
Information Systems) of the German Informatics Society (GI).

Before coming to the University of Klagenfurt he was for about ten
years the managing director of a medium-sized software company in
Germany engaged in the design, development and support of turn-
key branch specific information systems.  From 83 to 84 he was
guest professor at the technical university of Munich.

He received his doctor degree in Applied Mathematics from the
University of Grenoble, France, in 1975, after having studied at the
universities of Karlsruhe and Klagenfurt.  He had teaching and
research stays at the universities of Kaiserlautern and Saarbruecken
and he worked as an assistant professor for several years at the
informatics department of the university of Karlsruhe.


(SPHINCs) : Specification Reuse via Homogeneous Interpretation of
Concepts

Walaa-Eldeen A. Mohamed

University of North London
2-16 Eden Grove
London N7 8EA, UK
Tel: [phone]
Fax: [phone]
Email: [e-mail]

Abstract

One of the essential requirements for successful software reuse is the
availability of a mechanism that allows developers to relate new
situations to old ones. The take up of specifications reuse, as a feasible
approach to software development, hinges on finding such a mechanism.
This will facilitate the matching process between new and old situations
at an early stage of the development process. Current software reuse
approaches provide very limited support to specification reuse at the
requirements analysis stage. In this research, Concepts Reuse is proposed
as a new approach to specification reuse by providing a classification
scheme that will aid the matching process. This will be developed as
part of a new paradigm for software development that supports
specifications reuse at the requirements analysis stage. The proposed
approach, named SPecification reuse via Homogeneous INterpretation Of
Concepts (SPHINCs), classifies the problem of a new system (as
documented in its requirements) under one Concept which will be
chosen from a proposed set of Concepts. Each of these Concepts
represents a category of generic-reusable specifications which were
developed for previous requirements. The proposed set of concepts
capture the common patterns of problems that regularly occur in the
description of software requiements. Each concept is an abstraction of a
generic, well-repeated, problem pattern that occurs across different
application domains. These Concepts are independent of software
implementation environments as well as application domains
knowledge.

Keywords: Specification Reuse, Concepts of Reuse.

Workshop Goals: To exhange ideas andpresent a new framework for reuse
during the requirements analysis stage of the development process.

Working Groups: Domain Analysis/Engineering.

1   Background

Recent research and practices of software reuse have raised expectations
of increasing productivity and improving quality of the software
development process. The reported success of the Japanese software
factories and the savings that they had achieved by reusing software
components have attracted much attention. However, most software
reuse efforts, including the Japanese experience, have been mainly
focused on code reuse at the implementation level.

Greater savings can be gained achieving specification reuse at the
requirements analysis stage. Research in specification reuse is scant and
reuse during the requirements analysis stage has rarely been practiced.
This research focuses mainly on this area and attempts to provide a
feasible method for reuse of requirements specifications.

The problem of specification reuse does not only involve the discipline of
Software Engineering but also stretches to reach to other disciplines such
as Cognitive Psychology, Philosophy, and Systems Theory. Although,
investigating these disciplines will be attempted carefully, the focus will
be mainly on topics related to this research.  System modelling and
problem solving are two other topics which will be investigated in
disciplines other than Software Engineering.

Diagrammatic modeling techniques are powerful media of
communicating concepts of problems and their proposed solutions. The
application of these techniques in Software Engineering and Information
Systems is still facing some obstacles.  Some of these obstacles are due to
problems inherit in their notations others are related to the nature of
the continuing evolution of the subject area. Disciplines such as
Architecture has employed diagrammatic techniques successfully to form
a common language of specifying problems within its subject area.
Diagrammatic techniques used in Architecture will be examined to
identify those factors that led to their success in communicating
architectural concepts and compare those with their counterparts in
Software Engineering and Information Systems.

2   Position

The main objective of this research is to develop a method with which
reusable requirements specifications can be identified as well as
introduced at an early stage of the development process. This method
should be flexible enough to be incorporated within the system
development process.

To achieve this objective other sub-objectives will be attempted. These
are:

Examining ways of identifying common concepts, objects, structures and
deliverables that can be reused at the analysis level.

Examining representation techniques of requirements specifications
within systems development methods in order to identify possible
techniques that could support specifications reuse or develop a new one,
if the current ones are proven inadequate.

3   Comparison

As mentioned in the previous section,the early work of reuse was targeted
towards code. The benefits gained from code reuse was constrained by
the implementation environment in which the code was initially
developed. Limitations faced code reuse include type of operating
system, language in which the reusable code was first written and
interface problems of the new system(s). The effect of some of these
limitations was reduced by the development portable programming
languages, e.g. C. However, problems such as poor documentation of
previously written code made its reuse unfeasible in many instances.

To overcome some of the problems facing code reuse attempts were
made to achieve reuse on a higher level. Unfortunately, those attempts
moved only a small step to provide not more than program designs
which were again tied to a particular environment but easier to reuse. In
some cases design specifications were reused more successfuly when they
were restricted to a particular application domain [1]. Although some
success was reported on domain analaysis research [2],[3] results were
difficult to transfer fromone application domain to another. Also, in
domain analysis the reused artefacts were only at the design level and
were not suitable to reuse at the analysis level.

The last decade has witnessed the introduction of many software
development methods (e.g. SSADM, JSD, IE) designed to overcome some
of the problems increasingly appreciated within the development
process. These methods provided a variety of frameworks and techniques
with which requirements specifications are documented, described and
modelled. CASE tools supporting some of these methods provided
repositories within which requirement specifications can be
stored and later retrieved. These repositories are considered as a
significant starting point for implementing reuse during the
requirements analysis stage.

However,current CASE tools and development methods rarely provide a
methodical and systematic approach for incorporating specifications
reuse during analysis. The reuse method (SPHINCs), proposed in this
research, will be able to identify the reuse potential of previously
developed specifications for new systems requirements.

References

[1]J. Neighbors,"The Draco Approach to Constructing Software from
Reusable Components," IEEE Transactions on Software Engineering, vol.
SE-10, pp. 564-576, September 1984.

[2]P.Hall, DomainAnalysis, in Integrated Software Reuse: Management
and Techniques, Walton, P., and Maiden, N., (editors), Ashgate, UK. 1993.

[3]R. Prieto-Diaz, "Domain Analysis for Reusability," in 'Proceedings of
COMPSAC '87, IEEE, 1987.
Software Reuse by Model Reification

F. Luis Neves and Jose N. Oliveira

Inesc Group 2361 and Dep. Informatica, Universidade do Minho
Campus de Gualtar, 4700 Braga, Portugal
Tel: 351+53-604470
Fax: 351+53-612954
Email: [e-mail];
Http: http://s700.uminho.pt/fln
Email: [e-mail];
Http: http://www.di.uminho.pt/jno

Abstract

This paper builds upon earlier work on systematically calculating
implementations from model-oriented specifications based on abstract
data types. The calculation process is called reification and is usually
done by"hand", requiring some ingenuity and time. The adoption of
model-oriented software specification encompasses the ability to classify
and compare data structures. The reification of such data models
(specifications of software data structures) also provides a powerful reuse
mechanism up to isomorphic and in equational refinements. Following
the underlying formal calculus (Sets), one can easily demonstrate that,
for instance, a certain C++ class can be implemented by the composition
of already available ones. Our aim is to develop an automatic
"reificator", based on term-rewriting theory, which is intended to take
the specification of a data structure, written in the Sets notation, and to
refine it until a collection of reusable data models are identified. We also
refer that genetic algorithms have the potential to support inequational
term-rewriting, such as is required in animating the Sets calculus. This
topic is briefly presented.

Keywords:   Software reuse, model-oriented specification, reification,
rewrite, genetic algorithms.

Workshop Goals: Learning; presenting reuse experiments.

Workshop Groups: Reuse and formal methods, tools and environments.

1    Background

The authors were involved in the Sour 1 project for comparing,
classifying and retrieving information about large software systems. Sour
attempts to improve software developers productivity by introducing
techniques for reusing pre-existing software components. Related research
on software component knowledge elicitation and classification using the
Sets reification Calculus [2, 3] is reported in [4].

2    Position

This paper sketches the idea that software reification calculi such as Sets
[2,3] can be of some help in formalizing a simple yet powerful software
reuse discipline based on a mathematical notion of a software
component. In the approach, a software component is understood as a
specification of the component's internal state space (described by set-
theoretical constructs) together with a pre-/post-condition pair for each
action which can change or observe the component's internal state. A
repository of such abstract components has been academically built up
[5] which follows a classify by state structure partial-order based on the
Sets-term instantiation ordering [4] 2.

The Sets Calculus is based on set-theory up to isomorphism.  A collection
of =-equalities forms the so-called =-Subcalculus. When partial data-
structure transformations are present, abstraction invariants arise
according to the so-called --Subcalculus. (Informally,while A = B means
that A and B are interchangeable data structures, A- B means that only B
can replace (implement) A.)

The Sets model-reification process uses the laws of these two subcalculi to
derive new data models from existing ones, with correctness warranty.

Attempts to animate the Sets Calculus have been made recently [6]. A
"reificator" is expected soon made of two fundamental components: first,
a description language for input of relevant data such as axioms, models,
type of reificationand so on; second, the "engine"of the calculus which
incorporates,in the current prototype, the hybridization of two theories:
genetic algorithms [7] and rewriting systems [8].

3    Instantiation and Reuse

The notion of instantiation is closely related with the reuse problem. It
exploits the capability of identifying expressions (in our case, Sets terms
specifying software data structures) as particular cases of others.

In this paper's setting, software reuse consists basically of applying
rewrite rules obtained directly from the Sets laws, in order to rewrite
(reify) a software model and decompose it in a collection of sub-models
which instantiate pre-existent components (see also [9] in this respect).

Sour is the acronym of Eureka 379 project "Software use andreuse" [1].
See [4] also for details on ER ("Entity-Relationship") diagram inversion
and classification using this approach.

3.1   Instantiation

We proceed to a brief illustration of our strategy, whereby an
instantiation rule will be induced from the concrete example which
follows. Suppose that we want to implement the following C++ class
which associates to each OR (Object Reference) its type and a set of
attribute values:

#define MAX_A 3               // Cardinal of _A
enum _A -OR1,OR2,OR3";
#define MAX_D 1               // Cardinal of _D
enum _D -TYPE0";
#define MAX_B 3               // Cardinal of _B
enum _B -ATT1,ATT2,ATT3";
#define MAXSTR 255            // String length
typedef char _C[MAXSTR];

class X
-
    private:
       struct
       -
           _A A;                             // A
           _D D;                             // D
           struct -_B B; _C C;" ffBtoC[MAX_B]; // B -> C
       " ffAtoDxffBtoC[MAX_A];                // A -> D x (B -> C)
    public:
       // ...
";

In Sets, data structures of this class can be expressed by instatiating the
Sets
 -term 3

                              A ,! D (B ,! C)

Now, consider the following C++ class, which is presumed to be available
in the repository 4:

class Y
-
    private:
       _A setA[MAX_A];           //2^A
       struct
       -
           _A A;                // A
           _B B;                // B
           _C C;                // C
       " AxBtoC[MAX_A*MAX_B];  // (A x B) -> C
     public:
       // ...
";

A  B denotes the cartesian product of A and B; A ,!B denotes the set of all
partial mappings from A to B. See [3] for details. As a software
component implementation, the code of this class should include all the
intrinsic functionality, which is omitted here for economy of space.

The corresponding Sets specification is the following expression: 2A  ((A
B) , ! C). >From [3] we know that

                      A ,! (B,! C) _  2A  ((A B ) ,! C)                   (1)

holds, as a particular case of instantiating D = 1 in

                 A ,! D (B ,! C)  _  (A ,! D)  ((A  B) ,! C)              (2)

that is to say 5:

       A ,! 1  (B ,!C) _   (A ,! 1)  ((A  B) ,! C)by(2)

                       _   2(A1) ((A  B) ,! C)    by law A ,! B_  2(AB)
                        =  2A  ((A  B) ,! C)      by law A  1= A

which shows that Class Y can be reused in order to implement Class X.

3.2   Reuse

The reuse concept may be compared to the resolution of a mathematic
equation (or inequation). Suppose we have the following equation

                               x + 2y z =0                                (3)

in which, given the values of y and z,we want to know the values of x
which satisfy the equation. Using some basic mathematical rules, we can
write x in function of y and z, i.e. , by rewriting (3) in the form x = f(y;z).
In the above equation, this is equivalent to having

                                x = 2y+z                                  (4)

>From this point on,we just have to use the well known arithmetical
operations to finally obtain the x value.

This is the approach we propose for reuse , in particular for data models
reuse, i.e., the notion of writing something in function of. >From the
"reificator" point of view, we will have that a set of Sets models may be
kept in a repository, which is basically a store of reusable material [10].
This is much in the tradition of the classical handbooks in Mathematics,
for example in helping to solve integral/differential equations. In the
above example, reasoning will proceed by instantiating variables y and
zin terms of available information in the repository. The striking
difference is that we are dealing with discrete mathematics, a topic
rarely found in traditional engineering curricula,which are too much
concerned with the mathematics of continuity to leave room for the
mathematics of discreteness [11]. This may explain why many
"conventional" engineers are so bad software designers.

Note that MAX_D = 1, which in Sets is equivalent to saying that _D =1.

References

 [1]Systena and S.S. Software, "Integrated SOUR Software System_Demo
Session Manual," tech. rep., SOUR Project, 1994. Ver.1.2, cflSystena & SSS,
Via Zanardelli 34 , Rome & Via Fanelli 206-16, Bari, Italy.

 [2]J. N. Oliveira, "A reification Calculus for Model-Oriented Software
Specification," Formal Aspects of Computing, Vol.2, 1-23, 1992.

 [3]J. N. Oliveira, "Software reification using the sets calculus," in Proc. of
  the BCS FACS 5th Refinement Workshop, Theory and Practice of Formal
Software Development, London, UK, pp. 140-171, Springer-Verlag, 8-10
January 1992.

 [4]J. N. Oliveira and A. M. Cruz, "Formal Calculi Applied to Software
Component Knowledge Elicitation,"Tech. Rep. C19-WP2D,
DI/INESC,December 1993. IMI Pro jectC.1.9. Sviluppo di Metodologie,
Sistemi e Servizi Innovativi in Rete.

 [5]J. N. Oliveira, Especificac"ao Formal de Programas. Univ of Minho,
1sted., 1991. Lecture Notes for the UM M.Sc. Course in Computing (in
Portuguese; incl. extended abstract in English).

 [6]F. L. Neves, J. V. Ranito, and J. N. Oliveira, "Implementation Studies
about Automatic Model Reification based on the SETS Calculus," 19?? (In
preparation).

 [7]D. E. Goldberg, Genetic Algorithms in Search, Optimization and
Machine Learning. Addison-Wesley, 1989.

 [8]G. Huet, "Confluent Reductions: Abstract Properties and Applications
to Term Rewriting Systems," Journal of the ACM, 27(4):797-821, October
1980.

 [9]J. N. Oliveira and F. S. Moura, "Can Distribution Be (Statically)
Calculated?," tech.rep., DI/INESC, 1995.(In preparation).

[10]J. N. Oliveira, A Reification Handbook. 19?? (In preparation).

[11]J. Cuadrado, "Teach Formal Methods," Byte, p. 292, December 1994.

4    Biography

F. Luis Neves holds a degree in Mathematics and Computer Science from
Minho University(1992). He is currently a research assistant at Inesc
group 2361 (Programming and Formal Methods), sited at the University
of Minho Campus, Braga, Portugal. For the last two years,he was fully
engaged in the Inesc participation in the Sour Project (EU 379). His main
interests are graphical environments, formal methods and genetic
algorithms.

Jose N. Oliveira is a senior lecturer at the Computer Science Department
of Minho University at Braga, Portugal. He obtained his Msc degree
(1980) and Phd (1984) in Computer Science from Manchester University,
UK. His main research areas are formal specification of software and
program calculi. He is also a senior member of Inesc and leader of Inesc
group 2361. He was responsible for the Inesc partnership in the Sour
project.
Refactoring Object-Oriented Software to Support Evolution and Reuse
William F. Opdyke

AT&T Bell Laboratories
2000 N. Naperville ROAD
Naperville, IL 60566-7033
Tel: [phone]
Email: [e-mail]


Abstract
Software often needs to be changed before it can be reused.  In our
research into refactoring (restructuring) object-oriented software, we
have discovered four major reasons why people are reluctant to
refactor their programs, even if they accept the reuse benefits.  We
briefly discuss our approaches for addressing each of these concerns.

Keywords:  Reuse, Object-oriented software engineering, addressing
reuse barriers.

Workshop Goals:  Learning, networking, advance state of theory of
software evolution and reuse.

Working Groups:  Reuse Process models; domain analysis/
engineering; reuse management; organization and economics; reuse
and OO methods and technology, tools and environments.

1   Background
During my years at AT&T Bell Laboratories I have been able to view
the reuse issue from several different angles.  For several years
during the mid-1980's, I worked in an applied research department
at AT&T Bell Laboratories, studying techniques for supporting large
scale, multi-year software development projects.  Then, during a four
year doctoral research assignment at the University of Illinois, I
worked with Ralph Johnson on issues regarding the process of change
for object-oriented software.  Currently I am part of an AT&T
organization planning platform developments to support a range of
telephony applications.
My doctoral research focused on refactoring object-oriented
software, to support evolution and reuse.  Refactorings are behavior-
preserving program restructurings that can be applied to, for
example, separate out parts of a program (design abstractions, reuse
components) to make the design of a program clearer and make it
easier to add new features.  Refactorings can also be applied in some
cases to reduce or eliminate redundant parts of a program.
The need for refactoring grew out of early experiences in reusing
object-oriented software, particularly in the Smalltalk community, as
discussed by Johnson and Foote in [1].  My research focused on
refactoring C++ programs [2,3,4,5,6].  Currently, research is underway
at the University of Illinois into refactoring Smalltalk programs [7].
Don Roberts and I will present a tutorial on refactoring at the
OOPSLA '95 conference at Austin.  The topics (briefly) described in
sections three and four of this position paper are addressed in much
further detail in that tutorial.
2   Position
2.1  Introduction
Software often tends to be changed before it can be reused.  Change
is inevitable, as users request new features, external interfaces
evolve and designers better understand the key elements of their
application.
Evolving software to support these changes is a tedious and error-
prone process.  This position paper focuses on the barriers that we
have encountered in our research on supporting the change process
for object-oriented software.  These barriers are relevant to the
general problem of encouraging reuse within an organization.
2.2    Applying Object-Oriented Techniques
For at least some of us, an "ideal world" would consist of only fresh
start projects, where we understood the domain, and where our
funders would pay us until we were satisfied with the results.
However, a more realistic scenerio might sound something like this:
we are asked to use/extend an existing piece of software, we have a
less-than-complete understanding of what we are doing, and we are
under schedule pressure to produce!
Should we re-write the program?  We could apply our design
experience, correct the ills of the past and, besides, it would be
creative and fun!  But, will the new program do all that the old
program did, and who will foot the development bill?
Should we copy and modify an existing piece of software?  This
might be expedient, and perhaps demonstrate reuse.  But, will we
really understand what we are using?  Might errors propagate,
programs get bloated, program designs get corrupted and the
incremental cost of change escalate?
In our refactoring research, we have investigated a middle ground:
start with the existing software base, incrementally restructure the
existing software to extract reusable abstractions and components,
clean up class interfaces and inheritance hierarchies, and prepare the
program to make subsequent additions of functionality easier.
2.3    Barriers and How We Addressed Them
Suppose you accepted (in the abstract) that there would be benefits
in refactoring your software.  Why might you still be reluctant to
refactor your program?

We have found four key reasons why people are reluctant to refactor
their software, which have implications on the general issue of
software evolution and reuse:

1.    "I don't understand how to refactor."
2.    "If the benefits are long-term, why exert the effort now?  In
the long term,  I may no longer be with the project."
3.    "Refactoring code is an overhead activity;  I'm paid to write
new features."
4.    "Refactoring might break the code."
The issue of adapting existing code to support new applications is a
difficult problem, with many technical and organization implications.
While our research primarily focused on the technical concerns,  we
kept the organization issues in mind as we proceeded in our
research.
Our approach to addressing the first two of these objections was to
characterize the refactoring process in a way that achieved both
short term and long term benefits.  We learned many insights from
studying how versions of our and others' programs evolve over time,
and learned from discussions with (and reaading the retrospectives
of) experienced developers and researchers.  From this, we defined a
taxonomy of refactorings and incremental additions of functionalities.
For example, when defining a new feature that is a variant on an
existing feature, one can define classes (usually abstract classes) that
capture the common behavior, and use subclassing to capture the
feature differences.  One benefit of this approach is that the abstract
classes not only provide a way to leverage existing code for near-
term benefits, but they may represent abstractions that will be
useful in defining additional, similar features later.
Our approach to addressing the latter two of these objections was to
provide automated assistance, to help increase the speed (i.e., reduce
the overhead) of program restructuring.  Often, it is more difficult to
determine whether a refactoring can be safely performed than it is
to perform the refactoring once it is known to be safe.  There can be
many,  sometimes subtle interdependencies within a program that
making changing any part of the program difficult.  The analysis of
program dependencies, and checking that behavior is preserved
across program restructuring, is a tedious and error-prone task and
one where automated tools can help.
2.4    Some Conclusions
In conclusion, while there are longer-term benefits that can be
achieved by making existing software more evolvable and reusable,
there are significant challenges to getting people to invest the effort
to make their software more reusable.  Learning from the past,
motivating short-term benefits, providing automating assistance and
addressing the backward compatibility (behavior preservation)
issues are all important in motivating the acceptance of reuse
approaches.  Other issues, such as reward mechanisms and the
opennesss of an organization to change, also influence the success of
reuse efforts.
3   Comparison
Casais [8] (Esprit Project) and Lieberherr et al [9] (Demeter project)
have also studied issues on restructuring object-oriented software.
Their efforts have considered issues such as increasing information
hiding [9] or eliminating redundant definitions of variables [8].  Our
focus has been upon providing a set of restructurings that clarify the
design of a program to the designer, which sometimes but not always
involves reducing code size or increasing information hiding.
Work in object-oriented database schema evolution (eg: [10] has
addressed similar issues to ours, although with a focus upon
persistant data rather than upon programs.
We applied many of the object-oriented design techniques embodied
in the CRC approach [11], albeit for redesign rather than for the up
front design task.
Some of the relationships of design patterns and refactoring are
discussed by Brian Foote and myself in [6].
References
[1]    R. E. Johnson and B. Foote. "Designing Reusable Classes." Journal
of Object-Oriented Programming, 1(2):22-35, 1988.
[2]    W. F. Opdyke and R. E. Johnson. Refactoring: An Aid in
Designing Application Frameworks and Evolving Object-Oriented
Systems.  In Proceedings of 1990 Symposium on Object-Oriented
Programming Emphasizing Practical Applications (SOOPPA '90),
Poughkeepsie, New York, September, 1990.
[3]    W. F. Opdyke.  Refactoring Object-Oriented Frameworks. Ph.D.
thesis, University of Illinois at Urbana-Champaign, 1992.  Available
as Technical Report No. UIUCDCS--R--92--1759.  Postscript:
/pub/papers/refactoring/opdyke-thesis.ps.Z on st.cs.uiuc.edu.
[4]    W. F. Opdyke and R. E. Johnson.  "Creating Abstract Superclasses
By Refactoring."  In Proceedings of CSC '93: 1993 ACM Computer
Science Conference, Indianapolis, Indiana, February, 1993.
Postscript: /pub/papers/refactoring/refactoring-superclasses.ps on
st.cs.uiuc.edu.
[5]    R. E. Johnson and W. F. Opdyke, "Refactoring and Aggregation."
In Proceedings of ISOTAS '93: International Symposium on Object
Technologies for Advanced Software, Kanazawa, Japan, November,
1993.  Postscript: /pub/papers/refactoring/refactor-aggregation.ps
on st.cs.uiuc.edu.
[6]    B. Foote and W. F. Opdyke, "Life Cycle and Refactoring Patterns
that Support Evolution and Reuse." Presented at First Conference on
Pattern Languages of Programs (PLOP '94), Monticello, Illinois,
August, 1994.  In "Pattern Languages of Programs" (James O. Coplien
and Douglas C. Schmidt, editors), Addison-Wesley, May, 1995.
[7]    R. Johnson, J. Brant, and D. Roberts, "The Design of a Refactoring
Tool." Presented at ICSE-17 Workshop on Program Transformation
for Software Evolution, Seattle, WA., April, 1995.
[8]    E. Casais.  Managing Evolution in Object Oriented Environments:
An Algorithmic Approach.  Ph.D. thesis, University of Geneva, 1991.
[9]    K. J. Lieberherr and I. M. Holland. "Assuring Good Style for
Object-Oriented Programs."  IEEE Software, pages 38-48, September,
1989.
[10]W. Kim.  Introduction to Object-Oriented Databases.  MIT Press,
1990.
[11]R. Wirfs-Brock, B. Wilkerson, and L. Weiner.  Designing Object-
Oriented Software, Prentice-Hall, 1990.
Bibliography
Bill Opdyke is a member of the technical staff at AT&T Bell
Laboratories, where he has focused on intelligent network and
decision support applications of object-oriented technology.  He is
currently involved in platform planning for telephony applications.
He is on the editorial board for an AT&T internal publication devoted
to software (and hardware) reuse issues.  Bill's doctoral research at
the University of Illinois focused on refactoring C++-based object-
oriented frameworks, supervised by Ralph Johnson.

Measuring the Level of Reuse in Object-Oriented Development

Jeffrey S. Poulin

Loral Federal Systems
MD 0210, Owego, NY 13827
Tel: [phone]
Fax: [phone]
Email: [e-mail]

Abstract

Defining what software to count as "reused" software constitutes the
most difficult and meaningful problem in reuse metrics. Experience
reports routinely report impressive reuse levels and benefits due to reuse.
However, the reader cannot trust the report without understanding what
the report counted; e.g.,modified software, ported software, generated
software,etc. To date, only one model exists for defining a consistent
method of counting and reporting software reuse. Although this model
applies equally to various development paradigms to include object-
oriented programming, this paper clarifies the model with respect to
objects and expands on issues related to object-oriented reuse metrics.

 Keywords: Software Reuse, Reuse Metrics, Object-Oriented Programming

 Workshop Goals: Learn and discuss current reuse issues and methods.

 Working Groups: Useful and collectible metrics; Domain analysis and
engineering; Software Architectures

1   Background

To date, only one model exists for defining a consistent method of
counting and reporting software reuse [1]. This model methodically
makes recommendations as to what to count as a Reused Source
Instruction (RSI). The rationale for the model applies equally to the
functional, procedural, and object-oriented (OO) paradigms because the
rationale does not depend on any paradigm-specific methods. However,
recent work in OO metrics often either fails to address this issue or the
OO work identifies the need for a common counting model. As OO
metrics mature and the community identifies the most meaningful
metrics and ranges of values for each [2],the metrics must include
consistent definitions to serve as a basis for comparing results.

2   Position

The definition of Reused Source Instruction (RSI) applies to all
programming paradigms.

3   Approach

This paper describes the three primary OO reuse methods and briefly
discusses the benefits and drawbacks of each. It compares each of these
methods to the analogous practice in traditional procedural
development. Finally, the paper presents some issues that an
organization should address when instituting reuse metrics for OO
development.

3.1  Reuse in the Object-Oriented Paradigm

Expectations of high reuse levels provide one of the most important
motivations for OOsoftware development. In fact, the OO paradigm
provides three primary ways to support reuse:

1. Classes. The encapsulation of function and data provides for their use
via multiple instantiation and in aggregation relationships with other
classes.

2. Inheritance The extension of a class into subclasses by specializing the
existing class allows subclasses to share common features.

3.Polymorphism The reduction of program complexity by providing
thesame operation on several data types via several implementations for
a common interface.

Each of these reuse approaches involves some trade-offs in terms of
application and desirability. These trade-offs include the "cleanliness" of
the reuse; in other words, whether or not each component has a
traceable heritage of evolution and consequently whether or not changes
to a component will result in changes throughout the system [3]. For
example,creating a subclass and overloading a method through
polymorphism can cause unexpected results at execution time in the
case of an unintentional name conflict. Modifying source code, whether
for the method implementation or simply the interface, will propagate
changes to all parts of the system using that method. Alternately, simple
subclassing (without polymorphism) or use of a method without
modification of source code provides for clean and safe reuse.

This view of OO reuse corresponds to the subsequent testing requirements
incurred by the implications of inheritance and polymorphism [4]. For
testing purposes, each inherited methods requires retesting and each
possible binding of a polymorphic component requires a separate test.
The extent of testing depends on the "cleanliness" of the reuse.

If the features of OOlanguages do not guarantee reuse [5],they certainly
do not guarantee good programming. In traditional procedural
development programmers should use language features such as macros,
functions, and procedures when they must repeatedly execute the same
operations. The programmer may use techniques (depending on the
implementation language) such as variable macros (a method for
overloading macro definitions) or generic packages (a method for
overloading abstract data types in Ada). We consider the use of these
language features and techniques"good programming" or "good
design."Likewise, we expect OO programmers to use the language features
at their disposal (e.g., classes, inheritance,and polymorphism) to
abstract features common to objects and to minimize the amount of
code they must write and maintain.

In traditional development, we consider a component "reused" when the
programmer avoided having to write software by means of obtaining it
from "someplace else." Within small teams or organizations, we expect
the use of macros, functions, and procedures for common functions.
Repeated calls to these components do not count as reuse; calling
components simply uses the features of procedural languages. However,
if the organization obtains the software from another organization or
product we count it as reuse.

Likewise, a small team or organization may build a class hierarchy in
which subclasses incrementally specialize the common aspects of parent
classes.  We expect subclassing, inheritance, and polymorphism in OO
development. Of course, multiple instantiations of an object do not
count as reuse for the same reason multiple calls to a function do not
count. Reuse in OO programs comes from the use of classes and methods
obtained from other organizations or products, thereby resulting in a
savings of development effort.

I call the issue of determining when an organization has saved effort by
using software from another organization or product the boundary
problem. In practice, however, boundaries become obvious due to the
structure of the organization (the people) and/or the structure of the
software (in most cases management structure maps to the software
structure). On small projects, "reused" classes come from pre-existing
class libraries, commercially licensed class libraries, or other projects. On
large projects,the many organizations working on the project will reuse
each other's software as well as reuse software from commercial sources
and reuse software perhaps developed for that purpose by a team
dedicated to building shared classes.

3.2  Issues

One issue involves counting"extra" code in a reused class. In traditional
development, generalizing a component may require additional code.
Take the case of a variable macro instantiation. Do you count reuse
based on:

1.the code produced in that instantiation.

2.the average code produced over all possible instantiations.

3.the maximum code produced of all possible instantiations.


4.the macro source code needed for that instantiation including error
checking on input parameters and environment variables.

5.the total macro source, to include code for all possible macro
instantiations and the error checking for each, in which case you may
give reuse credit for a significant amount of software the programmer
would not have written.

Likewise, generalizing objects may require additional code to support
many possible applications. Take the case of a reused class stack, which
contains numerous methods for testing the status of and manipulating
the stack. However, a developer may only need thepush and pop
methods. Do you count reuse based on:

1.code used by the developer (push, pop)

2.total code in the reused stack class.

In practice I have found that this occurrences happens rarely, in part
because other constraints (such as on object code size) restrict the
practical ability to include more code than a developer needs. In
addition to encouraging the use of pre-existing classes, this realization
supports the counting of the entire class versus trying to determine the
subset of methods actually used.

In fact, data collection affects reuse metrics because an analyst must
usually work with available or easily obtainable data. For traditional
development, the reuse analyst must know the size of each reused
component, the total size of the software,and the developers and users of
each component. Likewise,the OO analyst must know the size of each
class, the total size of the program, and all the developers and users of
each class. Currently, traditional metrics use "lines of code" for
measuring component size; although this measure holds for OO, other
measures of effort may include the total number of classes or the total
number of methods.

3.3  How to quantify reuse in OO programs

The definition of reuse and what should count as a Reused Source
Instruction (RSI)(or reused objects) applies to all programming
paradigms. The use of language features such as

1.functions, procedures, generics, and (variable) macros in the
procedural paradigm

2.classes, inheritance, and polymorphism in the OO paradigm

do not, by themselves, constitute "reuse" as much asthey represent a
particular method to solve a problem. The rationale for defining reuse in
any paradigm depends not on language features but rather on an
assessment of whether someone saved effort through the use of software
they obtained from someplace else; in short, software they did not have
to write. The solution to determining reuse levels in programs lies in the
boundary problem. Weexpect organizations to call procedures and
inherit methods that the organization developed for its own use. When
an organization avoided development by using software it obtained from
someplace else,then we say it "reused" the software.

4   Comparison

Numerous references cite reuse as a principal benefit of object-oriented
technology. Kain admits the limited availability of quantitative evidence
of reuse in object-oriented programming and observes that few
experience reports say how they measure reuse [6]. Kain cites evidence
that some reports count reuse as the use of classes and methods across
applications (as explained above) and not, for example, inheritance
within an application.  Other reports count inheritance as reuse of the
superclass; these differences prevent the comparison of OO experience
reports.

Although Kain recognizes the need to evaluate OO reuse in the context of
multiple teams and organizations (not individual programmers),
Henderson-Sellers claims reuse comes from subclassing via inheritance
and from multiple instantiations of the same class [7]. Although he
focuses on the reuse of classes from reusable class libraries, he includes
references to the reuse of classes from one project to another and from
classes built for reuse within the organization. Henderson-Sellers
discusses OO reuse economics using a simple Cost-Benefit Model but he
fails to compare the model to most other work done in the field.

References

[1]J. Poulin,"Issues in the Development and Application of Reuse Metrics
in a Corporate Environment,"in Proceedingsof the 5th International
Conference on Software Engineering and Knowledge Engineering, (San
Francisco, CA), pp. 258-262,16-18 June 1993.

[2]J. Poulin,"Panel: Metrics for Object-Oriented Software Development,"
in 6th IBM Object-Oriented Software Development Conference, (Toronto,
CAN),19-23 July 1993.

[3]A. Cockburn,"The Impact of Object-Orientation on Application
Development," IBM Systems Journal, vol. 32, no. 3, pp. 420-444, 1993.

[4]R. V. Binder, "Testing Object-Oriented Systems: A Status Report,"
Crosstalk, vol. 8, no. 4, pp. 16-20, April 1995.

[5]M. Griss, "PANEL: Object-Oriented Reuse," in Proceedings of the Third
International Conference on Software Reuse, (Rio de Janeiro, Brazil), pp.
209-213, 1-4 November 1994.

[6]J. B. Kain, "Making Reuse Cost Effective," Object Magazine, vol. 4, no.3,
pp. 48-54, June 1994.

[7]B. Henderson-Sellers, "The Economics of Reusing Library Classes,"
Journal of Object-Oriented Programming, vol. 6, no. 4, pp. 43-50, July-
August 1993.

5   Biography

Jeffrey S. Poulin, works as a Senior Programmer with Loral Federal
Systems (formally IBM Federal Systems Company) in Owego, NY. As a
member of the Advanced Technology Group, he serves as the Principal
Investigator and leader of research into new open systems standards-
compliant technologies in the areas of distributed UNIX system
management, networking, and object-oriented software development. His
responsibilities in Owego include lead architect for the LFS reuse
program, technical lead for a contract in support of reuse across the U.S.
Army,and the reuse strategy for a major Army MIS development
program.

From 1991-1993 Dr.Poulin worked in the IBM ReuseTechnology Support
Center (RTSC)where he led the development and acceptance of the IBM
software reuse metrics and return on investment (ROI) model. He also
organized, edited, contributed to, and published a complete library of
resources on the IBM Reuse Method. Active in many professional
activities, Dr. Poulin has published over 30 papers on software
measurement and reuse. In addition to serving on numerous conference
committees and panels, he chaired the IEEE Computer Society 6th
Annual Workshop on Software Reuse (WISR'93) in November, 1993. A
Hertz Foundation Fellow, Dr. Poulin earned his Bachelors degree at the
United States Military Academy at West Point and his Masters and Ph.D.
degrees at Rensselaer Polytechnic Institute in Troy, New York.
Domain-specific Software Architecture Based on a Building Block Method

Muthu Ramachandran

Software Engineering Applications Group
Philips Research Labs
Redhill RH1 5HA, UK
Email: [e-mail]
Tel: [phone]
Fax:[phone]
Email: [e-mail]

Abstract

This paper discusses a method for designing domain-specific
architectures for a family of telecommunication systems. This method
has evolved to support reusability, configurability, testability, and
conceptual integrity.

Keywords: Reuse, Building Block Method, Software Architecture

Workshop Goals: Networking

Working Groups: Reuse process models, Design guidelines for reuse,
Domain analysis, Reuse and OO methods.

1   Background

Philips Kommunication Industry (PKI)has developed a method to
describe the architectural needs for the telecommunication applications.
We, in research,took their initial working level ideas and tailored to meet
their architectural and reuse requirements. This method supports reuse
in large scale in terms of subsystems. After tailoring the concepts, criteria
and guidelines, PKI is able to achieve more than 60% reuse across the
family.

2   Position

After tailoring the method and concepts, the new method has a support
for:

1.Architectural reuse

2.Reuse guidelines for design reuse

3.Conceptual integrity

4.Design for test, which has been ignored by the reuse community

5.Reuse by a large collection of construction set (group of objects and
architecture that relate to the conceptual integrity of a family) and
architectures.

2.1  Building Blocks

Understanding the concepts behind a method is important when
considering testing of reusable software. Basically focus your test
principles based on the development concepts of a family of reusable
systems. A Building Block (BB) is a collection of reusable object classes
that represent a unit of system functionality. It is also a basic unit of a
system architecture.  Each BB's separates specification (its interfaces) and
implementation. Furthermore there are two kinds of building blocks
such as an application BB and a generic BB. Application BB's are
createdfrom existing generic BB's to achieve high granularity of reuse.
Each units of reusable components developed to achieve high granularity
of reuse as well as configurability and conceptual integrity of the system.
Configurability and conceptual integrity are the main attributes for
achieving reuse in this application family.

Our notion of quality attributes are high granularity of reuse
(subsystems, architectures and product family), configurability and
conceptual integrity, testing, and documentation.

The Building Block Development Method is a development methodology
adopted for this project. It is based on the principles of architecture-
oriented decomposition and incremental layering, in addition to object-
oriented concepts such as object class (building block), generics,
information hiding, and run-time binding. This makes this method
superior and rich in offering advanced concepts to support reuse.

This method has improved PKI productivity by more than 60% increase
in reuse across the family product line.

3   Comparison

When we compare to existing work on architectural reuse such as SEI's
work with DSSA and Loral Federal Systems, etc, we have achieved reuse
and quality by various concepts of the method [1, 2, 3].

Our guidelines on reuse and design for test are comprehensive to Booch's
notion of a reusable component.

References

[1]W. Tracz, "DSSA Frequently Asked Questions," in ACM SIGSOFT, SE
Notes, 1994.

[2]E. Mettala and M. Graham, "The domain specific software
architecture program , CMU/SEI-92-SR-9," tech. rep., June 1992.

[3]R. Hayes-Roth and W. Tracz, "DSSAtool requirements for key process
functions ,version 1.0," tech. rep., October 1993.

Biography

Dr Muthu Ramachandran is currently a senior research scientist at
Philips Research Labs, researching into reuse methods for DSSA, testing,
OO reuse. Previously he was a senior lecturer at Liverpool John Moores
University teaching specialist courses on reuse and has published more
than 30 articles on reuse. He did his doctoral thesis on development for
reuse at Lancaster University.
A Fuzzy Query Language for a Software Reuse Environment

Antonio Nestor Ribeiro

Fernando Mario Martins

Inesc/ Universidade do Minho
Campus de Gualtar, 4700 Braga, Portugal
Tel: [phone]
Fax: [phone]
Email: fanr,[e-mail]

Abstract

The effectiveness of the reuse based approach to software development is
strongly dependent on the underlying classification scheme and retrieval
mechanism. Based on the Prieto-Diaz faceted classification scheme, this
paper proposes a logical representation for software components, called
Abstract Objects (AO), and a non-strict, fuzzy comparison strategy which
is the basis of a fuzzy query language. This strategy goes beyond the
common strict comparison implemented in usual query languages
because it expands the usual comparison bounds from a strict to a fuzzy
reasoning method.  This allows to find reusable software components
which are at a certain semantical distance(similarity) from a given one.
The measurement of similarity is based on a Conceptual Graph in which
conceptual distances are defined.  The presented strategy uses Prieto-
Diaz faceted classification method. On the basis of a distance calculus
metrics the end-user is able to make queries by using both enumerative,
attributive and faceted descriptions.

Keywords: Reuse environments, fuzziness, faceted classification, querying
with uncertitude.

Workshop Goals: Learning, presenting reuse experiences

Working Groups: Reuse and formal methods, tools and environments

1   Background

Reuse is a process whereby previously found software solutions are
compared with new requirements. It is therefore mainly a comparison or
analogical process. Two different problems then arise. On one hand,
because it is not feasible to compare the "real", physical, software
components, a logical representation must be found for them and the
comparison will deal with these logical counterparts. The classification
scheme has to provide for the mapping from physical software
components to their logical representations. On the other hand, the
retrieval mechanism will be based on the devised comparison algorithm.

Since 1992 we have been involved in an Eureka software project,called
Sour (Sour is the acronym of the Eureka 379 project which stands for
"Software Use and Reuse") intended to develop a Meta-Case system based
on a software classification and reuse strategy following the Prieto-Diaz
faceted scheme.

2   Position

2.1  Introduction

This paper describes the query mechanism used in the Sour system
which used a fuzzy reasoning [1,2 ,3 ].

The Sour information model is based on an hierarchical object structure,
resembling a semantic network. The abstract objects (Sour's unit of
information) are instances of classes inheriting a set of attributes. This
encompasses the usual attributive description used in many repository-
based management systems. This attributive description doesn't support
the human reasoning flexibility because it lacks the ability to cope with
vagueness and analogy.  These properties are of great value in a context
where the user wants to find software components compliant to a set of
desired properties[4]. Combining a faceted view of the repository with a
conceptual graph relating the facets, a fuzzy reasoning mechanism over
abstract-objects was implemented. Asa consequence of this classification
strategy, the query system has to deal with both strict and fuzzy
sentences of the query language.

The query system is supported both by the conceptual graph and by the
semantical distance calculus algorithm.

In this paper we present a query language developed for the Sour system
where it is possible to support the retrieval of software components that
are similar at a given degree of similarity.

2.2  The Conceptual Graph

Fuzziness is supported in the Soursystem by using a graph in which the
possible values for the facets are related with each other through a
specified distance. The facets are the leaves of the graph and are
connected to concepts. Concepts are needed to calculate the distance
between two facets.

The Conceptual Graph, CG  f(V1; V2; d) : V1; V22 V ^d 2 1::100g, is a set
of nodes and a set of arcs weighted by the semantical distance between
the two nodes.

A path between two nodes V1 and V2, isdefined as a sequence of arcs
starting at V1 reaching V2. The distance between two nodes is calculated
by the following rule:

if a path exists between them, the distanceis given by the minimum of
the product of the weights of the arcs;

if between two nodes V1 and V2 there isn't a path between them but a
transitive successor VS may be found, let Dv1 and Dv2 be the distances
from V1 and V2 to VS. The distance between V1 and V2 is given by (Dv1+
Dv2)=2.

2.3  Query Language

The interaction between a user and the repository of reusable software
components must follow a well defined language. This language will
control both the visual layer and the access to the repository. The
mechanism of fuzzy tuning allows for the construction of queries which
result is a set of objects at a certain degree of similarity to a given object.

This degree of similarity has to be specified by the user. Given a
similarity value all the objects in the repository at a similarity measure
greater or equal will be candidates for reuse (solutions). A low similarity
level will result in a larger set of candidates. However, loose similarity
requirement will select objects needing more adaptation effort,therefore
less reusable.

If the intended similarity level is near 100% then the kind of behaviour
expected in the retrieved objects is similar to the one given by just a
strict comparison. If the similarity frontier is near 0% the retrieved
objects may not have significant resemblance with the desired result.

The query language will accept sentences where it is possible to adjust
the "grain" of similarity.

The archetype[5] of a typical query sentence is

GET ALL OBJECTS CLASS= "class" AND <Attribute Description>

being

 <AttributeDescription>=<FacDescp>  j  <AttDescp>

 <FacDesp> =   FACNAME= "facname" AND FACVALUE= "facvalue" [AND
DIST= <Dist>]

 <AttDescp> =  ATTNAME= "attname" AND ATTVALUE= "attvalue"

 <Dist> =   [1..100]

2.3.1 Terminological Discrepancy

Another problem that must be regarded is the one related to the
terminological issue. The ability for an end-user to reason about the
repository strongly dep ends on the query language [6]. It is thus
desirable to guarantee that a query sentence may be made using
different Lexical Thesaurus. The process of query synthesis will then be
preceded by a terminological standardization one. This standardization
process will be accomplished by using a Lexical Thesaurus System where
grammatical declinations and synonymous are represented.

3   Comparison

Our Meta-Case platform proposes a classification scheme based both on
faceted and coarse attributive classification. The faceted classification is
intended to be a a fine evaluator of cases in which coarser search-
methods can not provide effective hints to latter reuse. A somehow
similar strategy is proposed in Tellos[7]. Tellos also assumes two
different classification strategies. The first one consists on a predefined
set of features found adequate in order to describe objects within a given
domain. The second one assumes that objects are instances of existing
classes. Tellos reasoning is made upon a theoretical basis for the
comparison and a distance model for similarity calculus.

The approach described in [3]also assumes a faceted classification
scheme. Queries in this system are seen as templates of objects with the
desired facets values specified. The result of a query is a ranked list of
similar objects.

References

[1]R. Prieto-Diaz and P. Freeman, "Classifying Software forReusability,"
IEEE Software, vol.4, no. 1, pp. 6-16, 1987.

[2]R. Prieto-Diaz,"Implementing Faceted Classification for Software
Reuse," Communications of the ACM, vol. 34, no. 5, 1991.

[3]E. Ostertag, J. Hendler, R. Prieto-Diaz, and C. Braun, "Computing
Similarity in a Reuse Library System: An AI-Based approach," ACM
Transactions on Software Engineering and Methodology,vol. 1, pp. 205-
228, July 1992.

[4]J. N. Oliveira, "Fuzzy Object Comparison and Its Application to a Self-
Adaptable Query Mechanism," 1995. Invited paper, Sixth International
Fuzzy Systems Association World Congress.

[5]F. M. Martins and J. N. Oliveira, "Archetype-Oriented User Interfaces,"
Computer & Graphics, vol. 14, no. 1, pp.17-28, 1990.

[6]H. L. Larsen and R. R. Yager, "The use of relational thesauri for
classificatory problem solving in information retrieval and expert
systems," tech. rep., Department of Computer Science, Roskilde
University, Denmark and Machine Intelligence Institute, Iona College,
USA, 1991.

[7]G. Spanoudakis and P. Constantopoulos, "Similarity for analogical
software reuse: A conceptual modelling approach," in Advanced
Information Systems Engineering (C. Rolland, F . Bodart, and C. Cauvet,
eds.), no.685, pp. 483-503, Springer-Verlag, 1993.

Biography


Antonio Nestor Ribeiro is an assistant lecturer at the Computer Science
Department of the Minho University at Braga,Portugal. He is currently
doing his Msc thesis upon the prototyping of concurrent interaction
systems.

He is an investigator of the Inesc group 2361, called Formal Methods of
Programming, being a member of the team responsible for the Intelligent
Query Sub-system of the Sour project.

Fernando Mario Martins is a senior lecturer at the Computer Science
Department of the Minho University at Braga, Portugal. His main
research interests are human machine interface, object oriented systems
and formal methods.

He is a senior member of the Inesc group 2361. In that quality he was co-
responsible for the Sour project.
Supporting Framework Evolution with Refactorings

Don Roberts
John Brant

University of Illinois
Department of Computer Science
Tel: [phone]
Email: fdroberts,[e-mail]

Abstract

One of the major problems with reusable software is that modifications
to the interface of any component become difficult. Both the design and
code that uses the software must also be modified. Often, it is not
possible to modify all uses since the person modifying a reusable
component does not have access to every use of that component. In this
paper we discuss a method for asynchronous updating source code by
using refactorings.

Keywords:  Frameworks, Refactoring, Object-Oriented Programming and
Design, Maintenance, Software Evolution

Workshop Goals: Learning; Networking; Determining feasibility of
proposed approach.

Working Groups: Reuse management, organization and economics; Reuse
and OO methods and technology; Tools and environments

1   Background

One of the more successful approaches to producing reusable software is
the development of object-oriented frameworks for particular
application domains. Examples of this type of software include the
HotDraw framework for graphical editors [1] and the Model-View-
Controller framework for user interfaces[2].

Developing truly reusable frameworksis an iterative process. System
designers develop several related applications and extract the
commonalities, which become the key components of the framework. As
the developers derive additional applications based on the framework,
they discover shortcomings in the original design that they must correct.
We have worked with several different frameworks and have recognized
many similar transformations that are common to the framework
development process.

2   Position

Frameworks are a good way to reuse both design and code. However, as
frameworks evolve and their interfaces change, the advantages of using a
framework are lessened. Not only are the developers responsible for
performing normal maintenance activities, they must also evolve their
programs in accordance with the evolution of the framework. This adds
overhead to using the framework.

Currently, developers of frameworks take one of two approaches. In the
first approach,the developer defines the interfaces to a framework when
it is released. Once the interfaces are defined, they never change. This is
the approach taken by Microsoft's Common Object Model. Any
modifications to the framework must preserve the interface, drastically
reducing the type of evolution that can occur. The benefit of this
approach is that users of the framework do not have to update their
software whenever a new version is released.

The second approach to this problem is one adopted by ParcPlace with
their Smalltalk programming environments. In this approach, the
designer of the framework recognizes that the design will evolve and,
hopefully, improve over time. To fully allow this to occur,the interface to
the reusable code must change. The problem, of course, is that if
interfaces change, user's code must be updated. This is a time consuming
and, one might argue, unproductive task.

The paradox that arises is that users want the framework to evolve, but
they are not willing to devote the resources that are necessary to allow
their program to stay synchronized with it.

2.1  Refactoring

One technique that aids in the design of reusable frameworks is
refactoring. William Opdyke defined a refactoring as a behavior-
preserving transformation that improves the design of an object-oriented
system [3]. Typically a refactoring consists of a transformation to be
performed on the program along with a set of preconditions which, if
satisfied, ensure that the behavior of the transformed program will be
identical to the original.  Examples of refactorings range from the low-
level, such as rename a method, to the high-level, such as convert
inheritance to aggregation.

In addition to using refactorings to evolve frameworks, refactorings can
also be used to convert applications to use updated versions of the
frameworks. Currently, whenever a vendor updates a framework,
customers who use that particular framework must spend time
converting their applications that are based on the framework to work
with the new framework. But with an integrated refactoring
environment, when the vendor releases a new version of a framework,
they would also include a set of refactorings that will transform
programs based on the old framework to the new version. This would
greatly ease the transition. An automatic refactoring system might not
be able to convert the entire system since often functionality is added.
However,even if it could convert 90% of an application, this would be
90% less work that the customer would have to perform.

There are two extensions to this system that we are considering. First,
since all the transformations cannot be performed by automatic
refactorings, provide a mechanism that will notify the user of portions of
their program that must be updated to match the new framework.
Another solution to this problem is to allow the framework developer to
include non-behavior-preserving transformations in addition to the
refactorings.

3   Comparison

Kingsum Chow has presented a method to handle interface
modifications within reusable code [4]. In his paper, he defines two types
of maintenance: synchronous maintenance, which is the maintenance
activity that can be done at the time of the change to a piece of code,
and asynchronous maintenance, which are maintenance activities that
cannot be performed at the time of the change to a piece of code. If
designers change the interface to a library that is being reused,
asynchronus maintenance results.

Chow developed his ideas with C++ in mind, although his research has
not progressed to the point of a workable tool. In his approach, the
changes that must occurin the user's code are embedded within the
interface files (.h files inC++).  In our system, which was developed with
Smalltalk in mind, the refactorings are distributed separately from the
code itself. Additionally, we have not addressed the problem of
recompilation of the user's code since Smalltalk is a dynamically
compiled environment. If either Chow's or our approach is implemented
in C++, this concern must be addressed.

Ira Baxter proposed another system that is similar to ours [5].  His
system transforms designs, written in a specification language, into
executable code. To reduce the costs involved in changing a design, he
proposes that the derivation that transformed the original design be
stored along with the executable program. Then, when the design
changes, the system will reuse as many of the derivation steps from the
original transformation as possible in the new derivation, reducing the
amount of work required.

Our system performs source-to-source transformations rather than
design-to-source transformations. However, both systems consider
transformations to be first-class entities that are to be stored and
performed at an arbitrary point in the future.

References

[1]J. M. Brant, "Hotdraw," Master's thesis, University of Illinois, Jan.
1995.

[2]G. E. Krasner and S. T.Pope, "A cookbook for using the model-view-
controller user interface parface paradigm in Smalltalk-80," Journal of
Object-Oriented Programming, vol. 1, no. 3, pp. 26-49, 1988.

[3]W. F. Opdyke, Refactoring Object-Oriented Frameworks.  PhD thesis,
University of Illinois, 1992.

[4]K. Chow,"Program transformation for asynchronous software
maintenance,"in Proceedings ICSE-17 Workshop on Program
Transformation for Software Evolution (W. Griswold, ed.), April 1995.

[5]I. D. Baxter, "Design (not code!) maintenance," in Proceedings ICSE-17
Workshop on Program Transformation for Software Evolution (W.
Griswold, ed.), April 1995.

4   Biography

Don Roberts is doctoral student in the Deparment of Computer Science
at the University of Illinois. His research interests in the object-oriented
programming and design with an emphasis on refactoring. He is
currently developing a tool for automatically refactoring Smalltalk
programs. For his MS, Mr. Roberts developed register allocation
algorithms for the Typed Small talk optimizing compiler. Mr. Roberts
received both his MS (1992) and BS (1990) from the University of Illinois.

John Brant is a doctoral student in the Department of Computer Science
at the University of Illinois. His research interests are in object-oriented
programming and design. He is currently working on a business model
framework for Caterpillar, as well as a tool for automating source code
transformations. For his MS, Mr. Brant worked on the HotDraw
framework for structured drawing editors. Mr. Brant received both his MS
(1995) and BS (1992) in computer science from the University of Illinois.
Domain Modeling Techniques for Representing Commonality and
Variability:  Towards A Comparative Framework

Mark A. Simos

Organon Motives
36 Warwick Road
Watertown MA 02172
Tel: [phone]
Fax:  [phone]
Email: [e-mail]


Abstract

Domain analysis (DA) is often described as analysis of commonality
and variability across multiple systems or subsystems within a
specific application domain. Developers and practitioners of DA
methods have adopted diverse approaches to representing this
commonality and variability in explicit models. Previous attempts to
compare DA methods have focused on the methods in their entirety.
This position paper proposes a useful and tractable first step: an
initial comparative framework for commonality and variability
representation strategies in DA.

We first report on recent progress in structuring the Organization
Domain Modeling (ODM) method to allow integration of a core domain
modeling process with diverse domain modeling representations. We
then suggest some general requirements for such representations.
The proposed framework characterizes different approaches in terms
of two major attributes: relative closeness of coupling between
system and domain models, and in terms of semantic expressiveness.
We hope to use the workshop as an opportunity to collaboratively
review, refine and extend the  framework to describe advantages,
risks, and implementation issues for various approaches.

Keywords: domain modeling, domain analysis, commonality,
variability, representations, taxonomic modeling

Workshop Goals: Opportunity to work intensively with researchers
and practitioners in the field to develop useful consensus positions
that will aid progress in the field.

Working Groups: Domain analysis/engineering;
Reuse process models; Reuse terminology standards; Reuse handbook


1   Background

A major focus of the author╒s recent work has been development of a
systematic approach to domain engineering called Organization
Domain Modeling (ODM). The ODM Guidebook Version 1.0 has
recently been completed under the auspices of the ARPA STARS
Program [10]. The guidebook was developed in collaboration with
Richard Creps and Carol Klingler of Loral Defense Systems (formerly
Unisys Government Systems Group), and Larry Levine (Organon
Motives).

A key innovation of the new formulation of ODM is to identify what
we term the core domain modeling life cyle and to differentiate it
from a number of supporting methods. The core domain modeling
life cycle includes processes, workproducts and methods central and
particular to the domain engineering mission. Supporting methods
include a number of technical areas such as system engineering,
reengineering, and process modeling, and non-technical areas such as
market analysis and qualitative data acquisition methods. Each
supporting area is essential to carrying out activities that are part of
domain engineering, but involves techniques that are well-
established outside the context of domain engineering, and for which
a variety of alternative approaches are available. For example, steps
for systematically scoping domains are included in the core life cycle;
process modeling techniques, while employed in various portions of
the life cycle, are not part of the core.
Separation ofprocess and representational aspects is also
fundamental to this structure. Process aspects deal with the formal
or informal sequence of activities: planning the DA project, selecting,
scoping and defining domains, gathering domain information from
various sources, analyzing and representing domain information in
some modeling representation, and (in the latter phase of domain
engineering) using the domain model as a basis for engineering
reusable software assets for applications in the domain.
Representational aspects concern specific notations and associated
semantics for the domain model itself, and other models (e.g., process
models, system models) used at various stages in the DA process.
Separating these aspects makes ODM more flexible and adaptable to
needs of different organizations and domains, since the method can
be tailored to allow use of different representations, even multiple,
complementary representations for a single domain. Of course, these
two aspects cannot always be strictly independent; some
representations embed assumptions about the methods and
processes for their construction and vice versa.
1.2  Representations of Commonality and Variability
The taxonomic modeling supporting method is a critical technical
area that must be addressed to perform domain engineering. By
taxonomic modeling we refer, not exclusively to hierarchical and/or
inheritance-based modeling techniques, but more generally to any
representations used to model commonality and variability across
applications in the domain.
Isolating process from representational aspects of taxonomic
modeling as a supporting method area has proved one of the most
difficult parts of our restructuring effort. In our initial experience,
distinguishing system from domain modeling representations seemed
to be a major technology transfer obstacle for DA. If domain
engineering is ╥all about╙ modeling commonality and variability, how
can we characterize taxonomic modeling representations as a
supporting method?
Our experience, however, suggests that it is feasible to enforce this
separation. The major application of ODM to date has been with the
Army/STARS Demonstration Project at CECOM SED, Ft. Monmouth,
New Jersey [9, 12]. This project integrated the ODM method with use
of the Reuse Library Framework (RLF) as a domain modeling tool.
(RLF implements a structured inheritance network formalism for
domain modeling, using capabilities related to but not identical to
object-oriented modeling techniques [8].) Other small-scale pilot
projects using an ODM-based approach have been performed under
the leadership of Patricia Collins of the Hewlett-Packard Corporate
Engineering Group [3]. Within HP, some groups resisted the idea of
doing domain modeling using a structured inheritance-based
representation such as that supported by RLF. Other groups had
already shifted to an object-oriented (OO) development paradigm,
and used OO-based representations. Each project has reported
benefits to applying the ODM process model, for example, with
respect to systematic techniques for scoping and bounding domains
and documenting conceptual relations between domains. These
benefits appear to be relatively independent of the modeling
representation chosen.
We have therefore written the ODM Guidebook in a way that does
not assume use of a particular domain modeling representation, and
believe the process as documented is robust enough to support
diverse modeling approaches. We also intend to produce a more
detailed document that describes recommended practice for
performing ODM with the use of the RLF toolset. This has led to an
interest in organizing the various alternatives for domain modeling
representations themselves into a framework for comparison and
selection. In the rest of this paper, we propose an initial cut at such a
framework for taxonomic modeling representations in DA.

2   Position

Modeling commonality and variability across multiple systems is an
integral activity in domain engineering. A central issue is the ability
to model conceptual relationships (similarity, distinguishing features,
categorization) between artifacts and processes of systems that
perform analogous missions in diverse contexts. This is distinct from
the modeling of actual processing elements or data flows among
components within a given system, or higher-level operational
interactions among separate systems at the enterprise level.

2.1  Requirements

Variability. Our starting position assumes it is useful for a domain
model to document not just common but also variant features across
a set of related systems.  Some methods and informal approaches
emphasize commonality only. This approach, in some domains, can
identify high-level abstractions (e.g., generic architectures) that
encapsulate useful invariant properties. However, if the
representation formalism used is only rich enough to express
commonality, it imposes this assumption on the modelers, which may
not hold for some organizations and/or some domains.

The need for modeling commonality and variability can arise in work
products across the life cycle: in organization structure, process
models, architectures, component functionality, or dynamic models of
behavior.

Feature Binding Time Problem.  Beyond simple comparison across
systems, in domain modeling it is important to distinguish
combinations of features that must be "simultaneously satisfied" by a
single application, vs. combinations where each feature individually
must be supported by some application derivable from the domain
model.  Essentially, the notion is that a choice between variant
features can be "bound" or committed at various points within the
software engineering life cycle. Modelers must be able to distinguish
between these cases, to note connections between the same "logical"
feature as it occurs in different "binding contexts", and for the asset
base to be able to produce variant systems that implement features
at different binding times. Conventional system modeling
representations (even object-oriented representations) may have
inadequate means for distinguishing a system version that binds a
choice at implementation vs. at run time; since what is modeled as a
run-time operation in one system may appear as a design decision in
another.

A simple example would be the choice between tiled and overlapping
window protocols in a window management system. Some systems
are implemented in a way that "hard-wires" a specific  choice of tiled
or overlapping windows. Others might allow this to be  specified in a
configuration file that is read at start-up time. Still other  systems
might have a "preferences" switch that can be changed  dynamically
at run time by the user.

2.2  Proposed Framework
Having discussed some requirements, we now explore a proposed
framework for alternative techniques for representing domain
commonality and variability. The proposed framework identifies the
following approaches:
1) Use of single system models as "generic" domain models. The
system model may be interpreted as a reusable component rather
than a domain model; or it may be used as a abstract model
representing only common features. With this strategy the
representation used should be familiar and thus readily accepted by
application engineers. Different exemplar systems may have been
developed using different representations; some reverse engineering
or conversion into a common format may be necessary.
This approach can presume a domain architected with a layer of
commonality (a "core" reusable component or set of components
requiring little or no adaptation), separated from a layer tailored for
each application. Not all domains fall neatly into this style of
architectural style. In particular, this approach may fail to exploit
significant commonality in lower-level structural elements (e.g.,
components used by a large subset of applications, but not all
applications in the domain).
2) Use of multiple system models as implicit domain models. In this
approach, the perceived differences or contrasts between models
becomes the true (though implicit) domain model. There may need to
be a distinction made between "generic" models and models that
represent specific exemplar systems; but similar notations are used
for both. Tools like CTA's CAPTURE that  provide side-by-side views
of analogous system diagrams help modelers visualize these
differences [2].
Where the common/variant "divide" happens at a clear structural
boundary, hierarchical decomposition techniques can be extended to
encapsulate variability; e.g., alternative decompositions.  For
example, Yourdon data flow diagrams allow hierarchical
decomposition of process bubbles in lower level diagrams; a domain
model could include alternative decompositions of one common,
higher-level process diagram. Variability can thus be introduced at
arbitrary levels of system structure. Few conventional support tools
manage such alternatives or variants, however. (Sufficiently
sophisticated configuration management tools could represent
variant application branches and thus manage the structure of
alternatives.)
This approach does not directly provide direct ways of expressing
semantics of the relationships between system variants. In CAPTURE,
such comparative insights can be documented by annotating
application views with features, trade-offs and rationale.
3) Extensions to system representations to express variability.  This
allows for even more fine-grained representation of variability than
structural decomposition, since variants need not fall only at
hierarchical structural boundaries. That is, instead of representing a
variant via an entire diagram, embedded notations for variability
could be employed within a single diagram. For example, some
analysts utilizing the FODA method have developed extended IDEF
notations to show variant or alternative processes  [6]. One drawback
of this approach remains potentially weak or ambiguous semantics of
the extensions to the notations, especially in terms of ╥feature
binding time╙ interpretations.
5) Use of representations with built-in variability semantics.  By
utilizing already supported constructs (e.g., inheritance mechanisms)
it is possible to express commonality and variability across systems
without inventing new notation or extending new tools. This could
include entity-relationship diagrams, semantic data models, and
object-oriented techniques [4,5].
Because system notational conventions are, in effect, overloaded to
express domain semantics, developers can get confused as to what a
given representation is intended to convey.  Resolving this ambiguity
might require careful convention of use, or possible use of meta-
modeling techniques.
6) Separate  variability representations, linked with system
representations. In this approach, though semantic mechanisms such
as specialization, generalization and inheritance may be used as in OO
methods, interpretation of these relations is different than in a
system model. Notations for system and domain modeling can be
heterogenous; in fact, the domain model can reference system models
that are themselves in heterogeous notations. The representations
employed in this approach can cover a wide spectrum in formality
and semantic expressiveness; e.g., faceted classification [7], AND-OR
graphs [Kan90] and structured inheritance networks [8,9,12].
2.3  Summary
The techniques described above can be viewed within a framework
that distinguishes two attributes:
- The degree to which system and domain modeling representations
are strongly or loosely coupled (in terms of which the list above is
rank-ordered, with the strongest-coupled techniques listed first);
- Semantic expressiveness of the modeling representations.

This is just a preliminary proposal for such a framework.  We hope to
use the workshop as an opportunity to collaboratively review, refine
and extend the  framework to describe advantages, risks, and
implementation issues for various approaches.

3   Comparison

The main body of this position paper is really concerned with a
comparative framework; to ╥compare our comparison╙ to other
surveys of DA methods is a bit more difficult.  The major difference
is that we have attempted to isolate one clear area of concern for
fairly fine-grained comparison.  Most other surveys or comparisons
of DA methods have attempted to compare DA methods in their
entirety, and to make specific recommendations about selection
criteria would-be practitioners could apply [1,11]. Our approach is
complementary, in that it focuses on a much narrower area. Our
longer-range goal, however, it to synthesize a more general
comparative framework from results of several more focused efforts
for other supporting methods. The ultimate goal is to support the
core domain modeling process with a set of decision aids for
selecting, instantiating and integrating diverse supporting methods to
create robust and tailored domain engineering capabilities.

References

[1]    Arango, G., R. Prieto-Diaz: "Domain Analysis Concepts and
Research Directions." Domain Analysis and Software Systems
Modeling, ed. R. Prieto-Diaz and G. Arango, IEEE Computer Society
Press, 1991.

[2]    Bailin, S. KAPTUR: Knowledge Acquisition for Preservation of
Tradeoffs and Rationale. CTA, Rockville Maryland, 1992.

[3]    Collins, P., "Toward a Reusable Domain Analysis," Proceedings,
4th Annual Workshop on Software Reuse, Reston Virginia,  Nov 1991.

[4]    DISA/CIM Software Reuse Program. Domain Analysis and
Design Process, Version 1. Technical Report 1222-04-210/30.1, DISA
Center for Information Management, Arlington VA, March 1993.

[5]    Gomaa, H. A Domain Requirements Analysis and Specification
Method. Technical report, George Mason University, Fairfax, VA., Feb
1990.

[6]    Kang, K, S. Cohen, et al., Feature-Oriented Domain Analysis
(FODA) Feasibility Study. Technical Report CMU/SEI-90-TR-21,
Software Engineering Institute, Nov 1990.

[7]    Prieto-Diaz, R., Reuse Library Process Model. TR AD-B157091,
STARS IBM 03041-002, 1991.

[8]    Solderitsch, J., K. Wallnau, J. Thalhamer., "Constructing Domain-
Specific Ada Reuse Libraries," Proceedings, 7th Annual National
Conference on Ada Technology, March 1989.

[9]    STARS. Army STARS Demonstration Project Experience Report,
STARS-VC-A011/011/00, Dec 93.

[10]    * ibid., Organization Domain Modeling (ODM) Guidebook,
Version 1.0, Unisys STARS Technical Report STARS-VC-
A023/011/00, Advanced Projects Research Agency, STARS
Technology Center, 801 N. Randolph St., Suite 400, Arlington VA,
22203, March 1995.

[11]    Wartik, S., R. Prieto-Diaz. "Criteria for Comparing Domain
Analysis Approaches," Int'l Journal of Software Engineering and
Knowledge Engineering, Sep 1992.

[12]    Wickman, G., J. Solderitsch, M. Simos, ╥A Systematic Software
Reuse Program Based on an Architecture-Centric Domain Analysis,╙
Proceedings,  6th Annual Software Technology Conference, Salt Lake
City, Utah, April 1994.

Biography

Mark Simos has been involved with reuse and domain analysis
methods for the past decade. He is founder and principal of Organon
Motives, a consultancy specializing in software reuse training,
strategic consulting and research with particular focus on domain
engineering. As a consultant, Mr. Simos worked extensively with the
Hewlett-Packard Company and the ARPA STARS Program in
developing the Organization Domain Modeling (ODM) method, and
was a co-author of the STARS Conceptual Framework for Reuse
Processes (CFRP). Formerly a research scientist for Unisys, he was
initial technical lead for the Reuse Library Framework (RLF) toolset.
Prior to his R&D work, Mr. Simos specialized in high-end
photocomposition applications, and worked on the design and
evolution of several special-purpose programming languages for
typesetting applications. He holds an MS in Computer and
Information Science from the University of  Pennsylvania; he is also
a well-known traditional fiddler and songwriter.


Why (Not) Reuse (Typical) Code Components?

Murali Sitaraman
David Fleming
John Hopkins
Sethu Sreerama

Dept. of Statistics and Computer Science
West Virginia University
PO Box 6330
Morgantown, WV 26506-6330
Tel: [phone]
Email: fmurali, fleming, jhopkins, [e-mail]
WWW: http://www.cs.wvu.edu/resolve/resolve/public_html/index.html

Abstract

There is much debate within the reuse community regarding the
potential for productivity and quality gains from reusing different
software lifecycle artifacts.  Specifically, there is a growing belief that
gains resulting from reusing artifacts in the earlier phases in the lifecycle
(e.g., requirements/design documents) dominate the gains from reusing
ones in later phases (e.g., code). This belief is indeed true and is based
on "typical code artifact reuse" wherein key design decisions are hard-
coded in the interfaces and implementations; here ,reuse does not
necessarily translate into reusing the effort that has gone into producing
that component. In the absence of better designs, non-code artifact reuse
is from where reuse benefits could accrue. However, interfaces,
implementations, and contexts of carefully-engineered components such
as RESOLVE components are highly flexible, and reusing them results in
implicit and explicit reuse of lifecycle artifacts and the efforts in creating
them.

Keywords: code reuse, effort reuse, flexibility, interface design, hard-coded
decisions, lifecycle artifacts, parametrization

Workshop Goals: to network.

Working Groups: formal methods, role of objects in reuse, languages and
frameworks, reuse education, technology transfer.

1   Position

Typical code reuse is rightly criticized for lacking in reuse potential
because design decisions are hard-coded and efforts in creating
associated artifacts (if any) are not reused . However, when 3C "code"
component interfaces, implementations, and contexts are designed to be
reused - both for components that are small and that are large and
layered - reuse can and will result in implicit reuse of lifecycle artifacts
and the considerable efforts in creating those artifacts.

2   Background

Sitaraman has been an active member of the software reuse community
for the past several years. He has participated in WISR's regularly since
1990. He has served on WISR program committees and was the finance
chair for WISR in 1993. He was the tutorial chair for the Third
International Conference on Software Reuse. He has been on the steering
committee of the Reuse Education/Training workshop series since its
inception.

Sitaraman currently serves as the program chair of the Fourth
International Conference on Software Reuse. He is one of the principal
investigators of the RESOLVE research effort.  He has published a number
of technical papers on various aspects of reuse.  His researchis currently
funded by ARPA grant DAAH04-94-G-0002, NASA grant 7629/229/0824,
and NSF grants CCR-9204461 and DUE-9354597.

Fleming, Hopkins, and Sreerama are PhD students with topic areas in
software reuse.

2.1  Introduction

The potential in software reuse for solving the productivity and quality
problems facing the software industry has not been fully realized. The
contention of Brooks that there is "no one silver bullet" (including reuse)
[1] along with observations that relatively modest improvements have
resulted from reuse have forced the software reuse research and
practicing community to renew consideration of questions such as what
and how to reuse [2].

Some attempts to answer these questions have led to suggestions that the
potential in code component reuse is inherently limited, and hence,
reuse of other software lifecycle artifacts must be explored. It is believed
that reuse of artifacts that are produced in the earlier phases of the
software lifecycle, such as requirements definition and design artifacts,
can lead to more significant gains. In this paper, we explain that these
claims are true only when based on typical reuse of code components
that are highly inflexible and that do not necessarily result in reuse of
efforts that have gone into producing the components.

We use the term "code component" in this paper to denote a 3C-style
component that includes an interface, implementation(s), and contexts
[3, 4]. A code component may be small or large. Though we agree on the
general need for research in reuse of non-code artifacts (for example, in
[5], we have explained how the 3C framework can be generalized to
permit a uniform treatment of reusability of software engineering
artifacts), we contend that a majority of perceived limits of code
component reuse are results of ad hoc attempts to reuse relatively poor
code. Specifically, components carefully and systematically engineered,
such as those using the RESOLVE discipline [6], can overcome the
limitations. The interfaces and implementations of these components
have been carefully designed and parameterized to permit functional
and performance flexibility. Reuse of these components results in reusing
the effort that has gone into the lifecycle phases in creation and
certification of the component. Until designs with these characteristics
are identified, specified, and implemented for a concept, it is certainly
useful to try to reuse other artifacts associated with the concept.
Ultimately, however, indirect reuse of domain and lifecycle artifacts (and
the efforts that has gone into creating them) through well-designed and
systematic component reuse may be where most reuse potential is
waiting tob erealized.

The rest of the paper is organized into the following sections.  Section 2
contrasts typical code reuse with carefully-engineered code reuse, and
explains why the former is rightly criticized for its shortcomings and how
the latter remedies them. Section 3 provides a summary.

2.2  Case (against and) for (typical) code component reuse

Development of a component involves at least the following phases: (i)
problem requirements (or in general, domain) analysis, (ii) specification
design, creation, and validation, (iii) implementation design, creation,
and verification. While it is hard to quantify the effort that goes into
each of these phases in general,it is widely acknowledged that a majority
of the effort goes into analysis, design, and verification activities rather
than in actual transliteration of designs into a concrete specification or
implementation artifacts. Clearly any viable model aimed at reaping
benefits of reuse must facilitate effort reuse.

Most code components are neither designed for reuse nor do they lead to
significant effort reuse, leading to the right conclusion that their
potential is limited [2]. To illustrate the issues, we consider two
variations of a reusable part where hard-coded decisions limit its
functional and performance flexibility,and hence its reusability. We
explain that if these defects cannot be remedied, few net gains are
achieved by reusing code making a strong case for mainly reusing non-
code artifacts (e.g., design decisions). However, the section concludes by
observing that better designs can remedy the defects showing that
inflexibility is not implied by code reuse.

Issue 1: Hard-coded design decisions in the interfaces

Most object-oriented textbooks include a component for graphs. Let us
assume that some application of graphs requires finding a minimum
spanning forest (MSF) of a given graph. Normally, the graph component
would not include such an operation.  Most object-based languages, how-
ever, would permit extension of the graph component with an additional
operation (or method) Find_MSF that produces an MSF of the given
graph. If the graph component includes a sufficient set of operations, it
might be possible to implement Find_MSF without violating information
hidden in the graph component. For now, the implementation details of
Find_MSF are largely irrelevant. The effort that has gone into developing
Find_MSF is mainly in certifying its correctness; little effort has been
spent on its interface design and implementation - which is a
straightforward translation of an MSF finding algorithm.

Now consider the following evolution in the functionality requirement of
the above application or a new application: an MSF that is less than a
specified weight W is needed; if the graph does not have an MSF with
weight <= W, other actions may be needed. There are two less-than-
perfect possible solutions to this changed problem.

The first and most natural solution (from a black box reuse perspective)
is to reuse the Find_MSF operation. In this case,a complete MSF for the
given graph would be found and then its weight would be computed and
compared against W. This solution suffers from a performance penalty
because it is not always essential to compute a complete MSF to see if its
weight exceeds W. Typically, only a few, but not all edges of an MSF are
needed in determining if W is exceeded. The inflexible procedural
interface is the obstacle in satisfying the changed functional
requirements without introducing a performance penalty. In addition,
though this solution reuses the interface and the implementation of
Find_MSF (and Graph) "as is," the effort reuse is minimal: Little effort
has been invested (and hence,reused) in the informal interface design
and translation of a standard algorithm to an implementation; the
certification is probably not modular and hence,is not strictly reusable
in an altered client environment.  In summary, this solution results in
reuse of minimal effort and a performance penalty.

A second solution to the evolution problem (likely from an algorithmic
or white box reuse perspective) is to re-specify the interface, possibly with
additional parameters, and re-code the Find_MSF operation so that it is
suitable for the new situation.  While this solution provides better
performance, from a reusability perspective it has little merit. Once
interface and implementation of the Find_MSFoperation have been
altered, none of the effort that has gone into creating it including that in
the certification of the existing implementation can be reused. What is
being profitably reused here is the "algorithm" for finding an MSF of a
graph. Though the translation of the algorithm to code can in fact be
partially reused in this "white box reuse" solution, gains are
insignificant. In the absence of better solutions, the potential for concrete
code reuse, at least for the example at hand, is limited. Exploration of
reuse of other artifacts would be in order. As explained in the rest of this
section, however, there is a better design and solution to the present
problem.

In [7], we explain a solution to the spanning forest finding problem
based on the general strategy of "recasting" algorithms as objects; this
solution results in a component interface that provides functional
flexibility without introducing a performance penalty for some
applications (such as the one that needed an MSF with weight <= W).
When the large-effect spanning forest finding operation is recast, the
result is a component that provides (a family of) objects, and small-
effect operations to insert an edge, change the phase, and extract an edge
on these objects. This interface design permits a client application to
selectively retrieve only some edges of a spanning forest of an input
graph.

The interface not only hides how a spanning forest is computed, but
when it is computed. This design in turn permits alternative
implementations of the same interface with performance behaviors
suitable for different applications. When the Spanning_Forest_Machine
_Template component is reused, important among the gains are the
efforts that have gone into its formal and fully-abstract interface design.
Details can be found in [7]. If the implementation is locally certified in a
modular fashion [8, 9], then the certification effort is reusable as well.

Issue 2: Hard-Coded Design Decisions in Implementations

Supposing that a spanning forest component has been designed with an
object-based interface, we now focus our attention on implementing this
component. One class of implementations would use Kruskal algorithm
[10]. This algorithm orders the edges of a graph in a non-descending
order and then based on that order (beginning with the smallest one)
chooses edges so that they do not form a cycle. One implementation of
Spanning_Forest_Machine_Template would "hard code" the Kruskal
algorithm from scratch. Such coding would involve identifying and using
a prioritizing technique. The Kruskal-based implementation may
provide appropriate performance some clients depending on the chosen
prioritization algorithm, but may not be suitable for others. This raises
the possibility that different applications may require changing the
"prioritizing aspect" of the implementation without changing other
details. As noted earlier,any changes to the implementation will
immediately nullify all efforts that have gone into its certification with
the result that implementation reuse benefits are resulting more from
the "algorithmic and implementation design aspects" rather
than the concrete code.

The problem here is one of hard-coded implementation choice, and a
possible solution involves a component-based construction [7] of the
above implementation and constituent parameterization [11]. Rather
than implementing Spanning_Forest _Machine_Template from scratch,
it is possible to use Sorting_Machine_Template (an object-based
component that has resulted from recasting sorting) and
Equivalence_Relations_Template (an object-based component that
captures the standard equivalence relations idea). To change the
prioritizing aspect of this implementation, all that would be needed is to
change the implementation of Sorting_Machine_Template that is being
used; it is possible to allow the client to make this change and tune the
performance by making an implementation of
Sorting_Machine_Template as a performance parameter. Details of
performance parameterization are in [11].

We have focused our attention on one specific example to highlight the
issues in the paper. But the underlying strategies for flexible component
design such as recasting and performance-tuning employed here are far
more general. The abstraction facilitated by the specifications are crucial
to permit modular and local reasoning. Research into such theoretical
underpinnings and practical implementation of these ideas is crucial to
make explicit and implicit lifecycle artifact reuse and effort reuse
profitable.

3   Summary

It is rightly being observed that typical code component reuse has
limited potential. However, careful design can eliminate most critical
limitations. When a component is designed to be reused, tremendous
effort is involved indeveloping a formal and fully-abstract interface that
is flexible. Designs of implementations also require considerable thought
to avoid hard-coding key decisions; additional cost is involved if
performance behavior is of interest. Development of these components in
programming languages such as Ada and C++ also require a carefully
conceived discipline to permit local certification, among others [9].
Components designed and developed such, when reused, lead to
significant gains in productivity and quality in all lifecycle phases.

References

 [1]F. P. Brooks, "No Silver Bullet: Essence and Accidents of Software
Engineering,"IEEE Computer, vol.20, no. 4, pp. 10-19, 1987.

 [2]T. Biggerstaff, "The Library Scaling Problem and the Limits of Concrete
Component Reuse," in Procs. Third Int. Conf. on Software Reusability,Rio
de Janeiro, Brazil, pp. 102-109, IEEE Computer Society Press, 1994.

 [3]W. Frakes, L. Latour, and T. Wheeler, "Descriptive and Prescriptive
Aspects of the 3C Model - SETA Working Group Summary," in Int'l Ada
Tools and Environments Conference, Redondo Beach, CA, 1990.

 [4]W. Tracz, "Where Does Reuse Start?," ACM SIGSOFT Software
Engineering Notes, pp. 42-46, 1990.

 [5]M. Sitaraman,"A Uniform Framework for the Reusability of Software
Engineering Assets," in Fifth Annual Workshop on Software Reuse, Palo
Alto, CA,1992.

 [6]"Special Feature: Component-Based Software Using RESOLVE," ACM
SIGSOFT Software Engineering Notes, vol. 19, October 1994.

 [7]B. W. Weide, W. F. Ogden, and M. Sitaraman, "Improving Reusability
By Recasting Algorithms as Objects," IEEE Software, September 1994.

 [8]G. W. Ernst, R.J. Hookway, J. A. Menegay, and W. F. Ogden, "Modular
Verification of Ada Generics," Computer Languages, vol. 16, pp. 259-280,
1991.

 [9]J. Hollingsworth, "Software Component Design-for-Reuse: A Language-
Independent Discipline Applied to Ada; available by anonymous FTP
from acrchive.cis.ohio-state.edu in directory pub/tech-rep ort/TR1-
1993.," Tech. Rep. TR1-1993, Ph. D. Thesis, The Ohio State University,
1992.

[10]T. H. Cormen, C. E. Leiserson, and R. L. Rivest, Introduction to
Algorithms.  Cambridge, Mass.,:MIT Press, 1990.

[11]M. Sitaraman,"Performance-Parametrized Reusable Software
Components," International Journal of Software Engineering and
Knowledge Engineering, vol. 4, pp. 567- 587, October 1992.
Standardized Software Classification in the World Wide Web

Robert Haddon Terry
Margaretha Price
Louann Welton

MountainNet Inc.
2816 Cranberry Square, Morgantown, WV 26505
Tel: [phone]
Fax: [phone]
Email:frhterry,mprice,[e-mail]

Abstract

Where is the knowledge we have lost in information? T.S. Eliot

By browsing and searchingthe World Wide Web (WWW) for reusable
software, potential reusers encounter several different levels of cataloging
and classification schemes. Some software repositories use more
established methods while others use ad-hoc methods of classification. In
this position paper, we suggest having a standardized cataloging method
for WWW software repositories. Our goal is to provide potential reusers
with a readily apparent profile of repository contents, eliminating user
reliance on a full working knowledge of the specific repository
classification type. This is becoming increasingly necessary with the
proliferation of WWW software repositories and their expanding
popularity.

Keywords: Reusable software classification, World Wide Web

Workshop Goals: Start promoting a standardized classification scheme;
learn other cataloging/classification methods; listen to other ideas in
promoting the sharing of software through the WWW.

Working Groups: Reuse terminology standards, cataloging reusable
software, reuse in the WWW, reuse handbook and reuse management,
organization and economics.

1   Background

Our reuse experience is gained through the operation of the NASA
sponsored ELSA (formerly AdaNET) project, a fully functional WWW
repository.  Of ELSA's current population of 1100 assets, 670 are reusable
software.  These reusable assets are organized by class or information
type and by content through a collection hierarchy. The collections
represent facets of or subjects relevant to the Information Management,
Software Development, Mission Critical Systems and WWW Information
and Utilization domains. As software engineers/librarians in this
environment, we are directly responsible for acquiring, evaluating,
cataloging and qualifying software assets. In support of these tasks and
in an effort to support sound reuse concepts and practices, our team
participates in the identification, composition and evaluation of
proposed interoperation and reuse standards through the Reuse Library
Interoperability Group (RIG). This involvement impacts and prefaces our
assumed position with respect to reuse classification systems.

2   Position

A standard cataloging structure is necessary to fully explore the potential
represented by WWW software libraries. We are not advocating a single
classification scheme but rather, a convention or structure that provides
a descriptive overlay or reference guide to the appropriate interpretation
and utilization of classification schemes. Repositories can use all or part
of the classification standard, and they can also expand to the lower
levels of classification.

To our knowledge, groups have developed candidate interoperation
standards with respect to certification frameworks and the basic data
models.  These efforts do not satisfy or address issues inherent in
cataloging methods.

Below is a sample list of software repositories currently available on
WWW. These servers do not just contain information on their projects,
but in fact, make software assets accessible through the WWW.

Argonne National Laboratory Mathematics and Computer Science
Division (http://www.mcs.anl.gov/Projects/progtools.html)

CMU Artificial Intelligence Repository
(http://www.cs.cmu.edu/afs/cs.cmu.edu/project/airepository/ai/html/ai
r.html)

Electronic Library Services and Applications
(http://rbse.mountain.net/ELSA/elsa_lob.html)

Fortran 90 Software Repository
(http://www.nag.co.uk:70/1/nagware/Example
 s)

Guide to Available Mathematical Software(http://gams.nist.gov/)

National HPCC Software Exchange
(http://www.netlib.org/nse/home.html)

Netlib at The Univ. of Tennessee and ORNL
(http://www.netlib.org/liblist.html)

Physics Software Repository (http://icemcfd.com/cfd/CFD_codes.html)

Public Ada Library
(http://wuarchive.wustl.edu/languages/ada/pal.html)

Some of the above repositories catalog assets topically, while others
arrange holdings alphabetically. Topical classification systems are
typically presented as a hierarchy with variations given to subjective
logic or order purpose. It is further observed that the variations extend
to the inclusion of metadata or brief asset profiles. Metadata is often
delivered as a prescribed set of attributes that briefly describe asset
properties,or as separate WWW pages with no set attribute pattern. It
is also noted that several repositories offer direct asset access without
metadata. The discussion of metadata is related to classification
schemes but outside the topic of this position paper.

We propose that WWW reusable software providers choose one existing
classification scheme most suitable for cataloging reusable components.
There are several existing classification models from which to choose
(i.e.the CR classification System of theACM). Although no one scheme
can suffice in all applications, a basic cataloging structure can be
determined and is necessary in today's reuse WWW environment. A
classification scheme that is flexible enough which libraries can select
only parts of the classification structure and/or they can also expand the
lower levels of the structure for the more domain specific libraries.

3   Comparison

Software classification can be compared directly to general library
classification schemes such as the Library of Congress (LC) and Dewey
Decimal Classification (DDC).

Several participants of the Web4Lib listserv, a mailing list for issues
relating to the creation and management of library-based World-Wide
Web servers and clients, have addressed the issues of standardization of
WWW library classification schemes.  These discussions are continuing
and working groups are being proposed in their domain. The software
reuse community can start the same discussions, while also collaborating
with those decisions made by the librarians.

4   Biography

Robert Haddon Terry is a Sr. Software Engineer/Librarian in MountainNet,
Inc., for the NASA/ELSA software library. He received a B.A. (1984) degree
in Secondary Mathematics from West Liberty State College, West Liberty,
WV, and a M.S. (1988) degree in Computer Science, from West Virginia
University (WVU), Morgantown, WV. Since 1989, he has also been a
Lecturer/Researcher at WVU.

Margaretha Price is a Sr. Software Engineer/Librarian in MountainNet,
Inc., for the NASA/ELSA project. She received B.S. (1990) and M.S. (1992)
degrees in Computer Science from West Virginia University, Morgantown,
West Virginia.

Louann Welton is a technical writer for MountainNet, Inc and its
divisions. She received a B.A. in English with a specialization in Library
Science from Fairmont State College in 1983.
A Conceptual Framework
For Evaluating Domain-Specific Kits

Kevin D. Wentzel

Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94303-1126
[phone]
[e-mail]

Abstract
In a working group at WISR 6, in 1993, Martin Griss and Kevin
Wentzel led an exploration of the notion of domain-specific kits.  Kits
are comprised of compatible, domain-specific components,
frameworks and languages, supported by a variety of well-
integrated technologies and tools, such as domain-specific languages,
builders, generators and domain-tailored environments.  The
working group attempted to list what the parts of a kit could be with
the purpose of allowing evaluation of software reuse systems as kits.
The framework described and demonstrated in this paper is a result
of our continuation of the group's work.

Keywords: Reuse, kits, domain specific kits.

Workshop Goals: Understanding how an analysis of domain specific
kits can help promote successful software reuse.

Working Groups: Reuse process, Reuse artifacts, Reuse measurement
and metrics.


1   Background
Our research program at Hewlett Packard Laboratories has
performed experimental research on software reuse with the goal of
improving Hewlett Packard Company's software processes. In this
research we have learned that to get high levels of reuse and enable
rapid application construction, with consequent high levels of
benefits,  one  needs more than just code or object libraries. As part
of our  work, we have learned that careful consideration must be
given to the way reusable workproducts must be designed and
packaged. One needs to systematically deal with the careful design of
reusable architectures and components that fit together, aided by
well-integrated tools.  A result of this research program is the
concept of Domain-Specific Kits [2] and [3]. We define a domain
specific kit  as a set of compatible, reusable workproducts  (software
artifacts produced at a variety of points in the software lifecycle)
that  are architected to fit well together and are designed to make it
easy to build a set of related applications.  Our kit-oriented research
agenda includes  the development of:
A philosophy of how and when to use domain-specific kits, with
careful and useful definitions.

Processes and methods to be used by kit developers and users,
workproduct supporters and managers, such as kit-based domain
engineering, kit engineering, and application engineering.

A taxonomy  and analysis framework of kit models to allow us to
evaluate and compare different domain-specific kits, including kit-
feature selection guidelines.

A set of customizable tools and technology that can be used to define
and develop kits, including domain analysis tools, language and
generator kits, library and browsing tools, language interpreters and
compilers, software-bus services, and user-programming and
customizing language kits.

A set of case studies which illustrate the principles, the practice and
the tradeoffs, abstracting ideas from studies of reuse in several HP
divisions, existing commercial kits or  kit-like systems, and
experiences in prototyping several experimental domain-specific
kits.
2   Position
We are evaluating several kits or kit-like development environments
within a conceptual framework  to gain a deeper  understanding of
kit features and mechanisms.  This helps us explain the concept of a
domain-specific kit, evaluate potential kits for completeness,
determine the importance of the various kit elements, suggest
improvements to kit-like software development systems, and
identify candidate kit technologies.  Analysis of kit-feature
variability is a start toward a domain analysis of kit styles.

As a way to determine which were the most important aspects of
software reuse technology and to suggest the best directions for
research, we began work on a kit evaluation framework.  We applied
an early version of the framework to several reusable software
systems from libraries to highly configurable applications and looked
for correlations which indicated features important in making the
systems successful.  We presented this early framework to a working
group at the 1993 Workshop on Software Reuse [4].  Following this
test run,  we refined the model to  produce the improved and
expanded  conceptual framework described below.  This analysis
framework can be used as a reference model to allow kit designers to
pick mechanisms and styles appropriate for particular domain or
user requirements. When the model is applied to a large number of
kits, it can act as an outline for a catalog of kits.  Potential kit users
can compare kits based on the representation in the model.
2.1  A conceptual framework for evaluating domain-specific kits
A successful kit is a complex collection of many kinds of
workproducts, models and documents, which we call "kit elements."
We chose a tabular form for the analysis since it makes side-by-side
comparison of kit examples easy.  A kit is represented by two tables.
The first  is a set of general factors describing the kit being analyzed,
while the second analyzes several attributes of each element. Table 1
describes the general kit factors. These include factors which identify
the kit as well as evaluative factors which can be used to gauge the
advantages of using the kit and the overall value of the kit. Table 2
describes the assorted kit elements,  while  Table 3 describes the kit
element attributes.

While not all kits contain all elements, the use of the same set of
factors in each analysis can point out differences in kits, thereby
determining which elements are most effective in particular
situations, and suggest elements that might be added to improve a
particular kit. The attributes are standard questions to be asked
about each element.  We are interested in learning the effect these
attributes have on successful use of a kit, and also in using these
attributes to predict success in developing and using new kits. The
absence or  weakness of an element or attribute may suggest areas
for improvement and extension of the kit. Each of these items relates
to one or more questions or issues that were raised by ourselves,
divisional partners or others trying to use kits. We have come to
think of the collection and range of  answers as representing assorted
"best-in-class" options for kit elements, each of which can be
considered during kit engineering when designing a new kit.

For convenience in comparing kits, we summarize in the second kit
table the analysis of a particular kit as a 2-D matrix with the kit
elements as rows, and the attributes as columns, highlighting the
presence of, and notes about, each attribute for each kit element. We
find it important to understand and reveal where domain-specificity
is located, and how openness and extensibility are accomplished.
Notes indicate how the attributes apply to each kit element, or list
questions yet to be answered.

Table 1. Description of general kit factors

Factor    Description
Kit name    The name identifying this kit.
Kit style    How are applications built from the kit?  Are components
combined using a traditional computer language?  Are applications
designed in a domain-specific language and constructed using a
generator for that language?   Is this a hybrid kit showing a
combination of componentry and generation?  Is there a visual
builder?
Kit purpose    Application construction?  Application
customization?
Target kit user     Who is expected to use the kit: application
developers, system integrators, or end users?  What is the expected
skill level of the kit users?
Target application user     What are the characteristics of the end
users of applications developed from this kit?
Features of merit for this kit    What makes this kit valuable?
(coherence, ease of use, evaluability of results, distance from
problem space, ... ╥input compression╙)
Notes     Interoperability with other kits, sub-kits used.
Other tools     Other tools, environment features



Table  2. Description of kit elements

Kit Element    Description
components     Software components and component
documentation.
architecture    Application architecture for applications developed
from the kit.
framework     The application framework instantiates the common
portion of the application architecture,  provides common
mechanisms, services and components which shape all applications
built from the kit, and defines the API to which components and glue
must conform.
domain-specific language     In some reuse situations, a problem
oriented or domain-specific language is an appropriate kit element,
allowing application specifications to be entered in the terminology
of the domain.  There are several levels of domain-specific languages.
These domain-specific languages and the translators for them  are
often costly and difficult to develop but provide high payback.
glue language    A kit usually includes some way of connecting
components to each other and to the framework.
generator    A tool that generates kit components, glue, configurations,
parameters, or some other application specific element from
application specifications.
builder    A tool, often graphical, which allows a kit user to develop
applications by selecting and composing components, by filling in
templates, or by editing specifications.
tests    A kit may include tests of kit elements and/or developed
applications.
end user docs    A kit may include documentation for application
end users.  This can be component or tool documentation, generated
documentation, or documentation on customizing applications.
maint docs    Documentation on kit maintenance.
kit use docs    Documentation on using the kit to develop
applications.
feature set rationale    Reasons why particular features are included
or clustered in a particular way in the kit.
domain model    Graphical or textual model of the application
domain, usually a result of domain analysis.  Used in application
design and development using the kit.
generic applications    A kit may include several generic (pre-built)
applications as examples developed from the kit, or as  the bases
which application developers can modify and extend to develop
applications.


Table  3.  Description of kit element attributes
Attribute    Description
presence in the kit    Is this element a part of this kit?  Is its
absence noteworthy?
completeness    How complete is this element of the kit?  Does it
cover everything needed from it for development of the target
applications?
openness    How easily can elements or new features be added to the
kit or to the developed (sub-) applications?
domain specificity    How specific to the target application domain
is this element of the kit?
binding time    When is this element bound into the application?
source    What is the source of this element? (provided in kit,
created or generated, written by user, liked from external libraries,
etc.)
life-cycle stage    How/when this element is used? (problem, solution,
implementation, extension, element development)
2.2  Hewlett Packard Laboratories kit experiments

We have prototyped a series of small domain-specific kits to help
drive the development of our kit design, implementation
methodology, and tools. Our first kit was in the domain of to-do list
or task-list managers, using our software bus [1] for component
integration. Following a minimal domain analysis and kit design,
components were written in several languages (LISP, C++, Tcl/Tk) for
item display, definition, time management, and task-list item storage
management. Alternative components and options are selected, and
data-structures are defined, using a simple (LISP-based)
configuration language from which a complete application is
generated. An alternative to the configuration language is a
conversational rule-based tool (IBACON) which uses information
derived from our domain analysis to present application requirement
issues to the application builder.  After the application is specified in
this manner,  the kit configuration file to match the answers to the
issues is generated.
2.3  The framework applied to the To-do list manager kit
We have applied our kit analysis framework to the kit described
above.  The most important deficiency we find in this kit is in the
area of openness and completeness  The kit only covers a limited
portion of the domain but does not make it easy for  application
developers  to add their own components to their applications.  The
kit is strong in generator and builder technology where it has
offerings for users of very different backgrounds. Tables 4 and 5
summarize the kit and show how the framework is applied to a kit.

Components: A collection of software components is included.  Some
are multiple (different capabilities) versions to fit a particular
function, others are included or not included in the application
depending on features required by the application developer/user.
Components are written in a variety of programming languages: Lisp,
C, C++, Tk/Tcl, Epoch Lisp.
Framework: A software bus in included as a framework for
assembling applications using the kit.  The bus allows components to
be included anonymously making application development adding
flexibility to application construction.
Languages: The kit includes a lisp-like domain-specific language for
application specification.  It also includes IBACON, a conversational
builder which can generate the kit's language. The application is
specified in a domain specific language.  When the language is
"compiled" via the generator appropriate customizations for the
components are built, and components are selected for inclusion.
Components are "glued" together when they connect to the bus.
Environment: The kit works in the UNIX environment, however
scripts and IBACON can shield the application developer from too
much interaction with UNIX.  The IBACON tool works within the
CLIPS-5 environment but users do not need to know CLIPS-5 to use
the IBACON. A generator is included for processing the domain
specific language into component customizations and selections.
Generic Applications: A generic application is included.  It was
expected to be a test for correct installation of the kit but quickly
became the starting point for users application development.
Completeness/Openness/Extensibility:  For its limited portion of the
domain, the kit is relatively complete. However, lack of openness
makes it difficult to add anything that is missing. The kit was not
designed for openness.  One of the test users wanted to add a
component and found it difficult to do so.  Our survey of kit-like
reuse inside and outside of Hewlett-Packard company has shown us
that openness is more important than we originally thought.
Other Tools: An "Application Controller" tool gives kit developers and
sophisticated application developers much flexibility in starting-up
and shutting-down application components.  Bus monitoring tools
assist in debugging the kit and applications developed via the kit.  It
is a kit goal to eliminate the need for tools such as the bus
monitoring tools since kit users should not need detailed knowledge
of these lower level support technologies.
Notes:  This kit was developed for research and experimentation in
kit building and use techniques.  It was never expected to be used to
develop complete applications in the domain.

Table 4.  General kit factors for HP to-do list manager kit

Factor    Description
Kit name    Hewlett Packard Laboratories Prototype  To-do list
manager kit

Kit style    Components with a domain specific language or a
conversational builder to specify and generate the application.
Kit purpose    Testing kit ideas in Hewlett-Packard Laboratories.
Target kit user    System/Application programmer.
Target application user    Any computer user.
Features of merit for this kit    Application architecture makes
application development very flexible.
Notes    App-Controller and Bus Monitor tools aid in kit and
application debugging.

Table 5.  Kit elements and attributes for HP to-do list manager kit

Elements    presence            completeness       openness
    domain specificity    binding time    source    life-cycle
stage
components     sets of alternative components for critical functions
plus components for optional functions    complete enough for the
purposes of this kit.    Some components are highly customizable but
all customization is via the kit language.    specific to to-do list
management domain.    generation, application start-up time.
    Hewlett Packard Laboratories    Application specification and
execution
architecture    components communicating via a software bus
        The bus architecture supports open ness but no tools or
instructions provided.    not domain specific    primarily run time
binding
framework     bus plus expectation for components covering a
minimal set of functions        bus architecture is very open
    quite domain specific

domain spec. lang     lisp-like language    Complete for the
limited functionality of the kit.    not easily changed, no tools for
extension.     very domain specific.    compiled
    HP Labs    all
glue language    (see dsl above)
generator    Included for processing kit's domain specific language
    Complete for kit and language features    Not easily extended
    Specific for the kit.    generation and app startup.    HP Labs
    Application specification and construction.
builder    IBACON conversational builder    Covers all features of
the kit    Not easily extended.    Knowledge in IBACON is very
specific to to-do list domain    Generates kit domain specific language.
    HP Labs    Application specification
tests    Generic application included as an installation test.    Tests kit
installation only
end user docs    no
maint docs    no
kit use docs    brief manual and online documentation

feature set rationale    no
domain model    none
generic application    Generic application included with kit    Many
kit features not included in the application are included in
comments.    can be modified and saved as new application
            application specification

2.4  Summary and conclusions
This model of kits and kit analysis framework helps us identify and
characterize key elements and attributes of effective reuse kits, and
points the way for improvements in several kits we have analyzed.
The definition of domain-specific kit (components, framework, glue-
language, generic applications and tools),  generalizes previous
notions of toolkit or kit, and highlights  extensions we can make to
enhance existing kit-like systems.  For example, most object-oriented
frameworks do not systematically include either generic applications
or integrated problem-oriented  languages , generators or builders.
The analysis framework has been applied to several systems at HP
labs and in HP divisions. It has also been used by participants in the
WISR 6 reuse workshop. We believe that to effectively build, buy,
and  make use of domain specific kits, an organization must be able
to analyze and compare kits using a framework such as this one.
References
[1]    Brian W. Beach, Martin L. Griss, and Kevin D. Wentzel. Bus-
based kits for reusable software. In Proceedings of ISS'92, UCI,
Irvine, pp. 19-28, March 1992.
[2]    Martin L. Griss, Software reuse: from library to factory,  IBM
Systems Journal, 32(4), pp.1-23, November 1993.
[3]      Martin L. Griss and Kevin Wentzel, Hybrid domain-specific
kits for a flexible software factory, Proceedings of SAC'94,  pp.  47-
52,  ACM, March 1994.
[4]     Martin L. Griss and Will Tracz,  Workshop on software reuse,
Software Engineering Notes, 18(2), pp. 74-85, April 1993.
Biography
Kevin Wentzel is a project leader in the Application Engineering
Department of HP Labs' Software Technology Lab. For three years he
lead a team performing experimental research in software
engineering and domain specific reuse. Kevin's current role is leading
research on extending Object Oriented Analysis and Design methods
in toward distributed and concurrent application systems.  Kevin has
been with Hewlett-Packard for 17 years. Prior to joining HP Labs,
Kevin worked in various engineering and management roles in
several HP divisions developing software products. Kevin has BS and
MS degrees in Computer Science from the University of Wisconsin.

Reusing Requirement Specifications: Lessons Learnt

B R Whittle

Rolls-Royce University Technology Centre
Systems and Software Engineering
Department of Computer Science
University of York
York, UK, YO1 5DD
Tel: [phone]
Fax:[phone]
Email: [e-mail]

Abstract

This paper is a summary of the experience gained by introducing a
change in technology used to specify requirements for real-time systems.
Whilst some of the experiences and techniques described in this paper
are specific to the development of safety critical systems, many of the
ideas are applicable across systems in a wide range of applications.

Keywords: Software Reuse, System Reuse, Requirement Specification, Real-
time Systems.

Workshop Goals: Discuss domain modelling, assess suitability of software
reuse principles to non-software domains

Working Groups:Reuse management and Organisation, Domain Analysis
/ Engineering, Reuse Adoption and Technology Transfer.

1   Background

Ben Whittle works within the Rolls-Royce University Technology Centre
for Systems and Software Engineering: Rolls-Royce established this
research group within the University of York, England to examine systems
and software development issues for the high integrity control systems,
both in the aerospace and power generation industries, produced by
Rolls-Royce plc.

One of the major activities of the group has been in establishing a
successful reuse strategy within the company. This work has been
principally undertaken by Ben Whittle and has examined artifact reuse
across all phases of system development, from requirements
specifications to test plans.

2   Position

Detailed requirement specification is common in real-time systems.
Reuse throughout the lifecycle is necessary to achieve significant cost
savings, and there is a close relationship between the requirements, the
design and implementation, and the testing phases. i.e. reuse of the
requirements is a necessary, but not sufficient, factor, in the reuse of the
code and test scripts. This paper abstracts some of the lessons that we
have learned from changing the way that the requirements are specified
to enable reuse. There are no examples in this paper as there is not
sufficient space, however we have a paper in preparation which will
describe our experiences in more detail [1]. Successful reuse is not only a
matter of changing the requirements structure and the method that
supports it, but also of establishing a culture that supports reuse. Whilst
there are some changes to the method and the way that the
requirements are specified, the greatest effect is likely to come from the
changes in the non-technical factors. This section provides a brief resume
of our experiences both in terms of the technical and non-technical
issues.

2.1  TechnicalIssues

The techniques described in this paper have moved requirements
engineering for Rolls-Royce forward in a number of ways:

requirements are considered as groups, 'requirements components', with
the interconnection between the requirements specifically recorded.

a 'requirements component' should exhibit high cohesion and low
coupling.

wherever appropriate, customer specific detail should be abstracted
away.

for similar systems the requirements document set forms an extensible
generic structure which is used as the basis of a specification of a family
of systems.

in some cases a family of systems, or part of a family, is specified as a
 generic set of requirements and variants on that generic.

In practical terms this has meant that we have reduced the total
number of requirements on the system by removing duplication. For
example, a recent case study in the area of signal validation we
discovered that there were 17 approaches to signal validation, depending
on the specific characteristics of the hardware and combinations of
inputs. In a brain storming session with the engineers,followed by a more
careful appraisal of the results, we reduced the number of approaches to
signal validation to 5. This reduction will have a significant impact on
subsequent coding and testing timescales and costs.

2.2  Process Issues

The requirements engineering process needs to be focused on the concept
of the family of systems, rather than the bespoke system generation that
most methods support. This is a cultural change, and has involved
encouraging engineers by showing them concrete benefits through
examples. The key areas of process change are in

Planning: ensuring that the engineer knows that similar requirements
already exist,and that he must extend these requirements wherever
possible.

Project management: to ensure that reuse is properly budgeted,
measured, and managed.

Review: to ensure that the best possible use of existing components has
been made.

In addition, engineers must be encouraged to think of the activity of
adding value through developing a generic or variant, as opposed to the
creation of 'new' requirements. The reuse efforts have been gaining
momentum over the last 18 months. The total effort on reuse in that
time, both within the project and at the UTC has been approximately 2
man years. Afurther 2 man years has been spent by the project in
developing reusable components for this engine series. In response to the
actual successes on the current project and the perceived benefits for
future projects Rolls-Royce have significantly increased the proposed
effort on reuse for the next year with a particular aim of establishing a
reuse culture and developing a library of reusable requirements
components.

2.3  Management Issues

Reuse has a significant impact on the way that requirements
specification is carried out. This will be apparent in the reduced
timescales because of the change from bespoke requirements
specification to reuse and adaptation within an existing requirements
framework.  Managers must learn to exploit the reuse potential by
considering the potential impact of reuse on project timescales and
budgeting appropriately. A great deal of the management information
needed to construct the project budget, the risk and impact analysis of
changes, for example, can be used by the team leaders and requirements
engineers as a driver for the scope of the requirements engineering task
for a particular variant. Project management and budgeting must be
backed up by systematic metrics collection. Three key metrics are:

actual time/cost saving accrued to reuse

effort spent in developing reusable components

effort spent in reusing

The first metric is used by the management to benchmark reuse, to
provide a basis for evaluation of budgeting accuracy, and to provide a
baseline for future budgeting.The other two metrics provide reuse
management information that can be used to gauge the utility of
particular components. The data for these metrics is being collected at
the present time. The early stage of development of the current projects
means that no meaningful results are currently available.

2.4  Tool Support

Requirements specifications are often text based, together with tables and
diagrams as appropriate. The better text editors can cope with the
amount of elision, information hiding, etc. necessary to print a copy of a
document with a certain view. In other words it can output the generic
information plus that specific to an individual variant, without
compromising the potentially sensitive information about other
variants. The tool must also be able to handle configuration
management issues because of the use of the requirements documents on
more than one engine project.

3   Comparison

Most of the research work in the area of requirement reuse has focused at
a higher level of abstraction than the work presented in this paper. For
example work by Maiden and Sutcliffe focuses on the use of analogy [2,
3]. There are a number of reasons for the difference between our work
and the existing requirement reuse papers:


in the real-time systems domain requirement specifications tend to be
less abstract, indeed many people would consider the specifications to be
more akin to design documents. Design reuse is considered by Biggerstaff
and Richter [4].

we consider the way that we have structured the information in the
requirements documents so that it can be reused rather than considering
the type of information retrieval and use of techniques to retrieve the
information

the work described is very pragmatic, and intended to provide a basis for
leverage of reuse later in the lifecycle. i.e. reuse of the requirements is
only a partial goal.

4   Summary of Position

In the domain that we are interested in, real-time systems, we believe
that reuse of requirement specifications is necessary if we are going to
achieve reuse in later stages of the lifecycle. This working paper has
summarised the ways in which we have changed the structure of the
requirements specifications to make them more reusable. There are a
number of other factors that will enable reuse. The paper notes our
approaches and the lessons learned in trying to adopt a reuse culture.

References

[1]B. Whittle, A. Vickers, J. McDermid, R. Rimmer, P. Essam, and J. Hill,
"Structuring Requirements Specifications For Reuse," In Perparation, vol.
The authors are with the Rolls-Royce UTC, University of York and Rolls
Smiths Engine Controls Limited, 1995.

[2]N. Maiden and A. Sutcliffe, "People-Oriented Software Reuse: The Very
Thought," in[5], pp. 176-185, March 1993.

[3]A. Sutcliffe, Analogy in Software Reuse, ch. 7 of [6], pp. 129-134.
Chapman and Hall, 1992.

[4]T. Biggerstaff and C. Richter, "Reusability framework, assessment, and
directions.," IEEE Software, vol. 41, March 1987.

[5]R. Prieto-Diaz and W. Frakes, eds., proceedings of the 2nd
International Workshop on Software Reuse (REUSE'93), Lucca, Italy, IEEE
Computer Society Press, ISBN 0-8186-3130-9, March 1993.

[6]P.Hall, ed., Software reuse,reverse engineering,and re-engineering.
Chapman and Hall,1992.

5   Biography

Ben Whittle graduated in Agricultural Economics from UW Aberystwyth
in 1989. He subsequently completed a masters in Computer Science and
proceeded to study for a PhD in the area of Software Component Reuse.
Mr. Whittle is currently with the University of York, working within the
Rolls-Royce sponsored Systems and Software Engineering University
Technology Centre (UTC). His main task within the UTC is the
introduction of advanced reuse techniques to the development of real-
time systems within Rolls-Royce. Mr Whittle has recently been elected
chairman of the British Computer Society Reuse Special Interest Group
committee and was formerly the editor of the group newsletter.
How to convince the management?

Aarne H. Yla-Rotiala

Nokia Telecommunications
P.O. Box 33
02601 Espoo, FINLAND
Tel: [phone]
Email: [e-mail]

Abstract

Software reuse is a way to increase productivity and to get better quality.
It seems that reuse is often stated as a goal for improvement programs,
and that companies and other organizations feel the need to "do reuse".
The order of steps is not predetermined, but then by keeping the actual
goals - productivity, product quality, customer satisfaction - in mind one
is able to travel towards a better software engineering solution. By
improving the organization's state of the practice it is possible to finally
stumble into reuse, but without having to bleed in the process. Doing the
improvement in a planned manner with centralized resource allocations
could be in some way more efficient than this Darwinian path, but the
effect on customer-oriented and financially responsible units within a
company can be negative. The conclusion of this presentation is that "It
looks like having reuse as a goal is having the wrong goal", especially
from the management perspective. The conclusion is followed by the
question "What is wrong with this conclusion?".

Keywords: Quality, productivity, investment, management.

Workshop Goals:Practical experience exchange, counter arguments
against my position.

Working Groups: Tools and environments,Software engineering
management and economics

1   Background

I have been a practicing software engineer for several years now. As such,
I have gotten more or less acquainted with several methods to achieve
better quality and productivity. Among these methods, reuse has been
and still is one of my favorites. During my active career I have written
and used (re-)usable components, and tried to get a grasp of what reuse
is all about. So far I am in the wilderness: there seems to be little
difference between "Solid Software Engineering" and "Software Reuse".

2   Position

Motorola [1] and IBM [2] have documented successful reuse programs.
These and other efforts like STARS are specificly aimed at enhancing
reuse in the organization's software engineering process. This requires a
lot of management support and commitment, up to the CEO level.
Investments are huge, and the pay-off time is usually several years.  The
positive effect of such a program is "enhanced reuse" and "better
reusability"of the software products created in the organization.
Eventually this is believed to result in lower overall costs, better quality
and shorter time to market for new products, which are all desirable
goals. These goals - and other similar ones - are what companies are
actually looking for when they launch "quality", "productivity" or even
"reuse" programs.

Given the time-scale and investment required to start and run a
successful reuse program , it is not very likely that the average manager
is willing to authorize such a program. If the program's goal is set to
enhance reuse, the connection between the bottom line - or harder-to-
measure things like customer satisfaction - is very fuzzy at best. Fast
programs with more concrete goals are likely to be easier to accept.
Expensive initiatives that take years to complete should not focus on
only one aspect or method to achieve better quality and larger profits,
but on a holistic approach to the company's software engineering process
and environments. The chain of deduction should go the other way
round: Do something for better abstractions, create better tools, enhance
communications, educate the engineers and preach about usability on
all levels of you process and product, and eventually you'll get better
quality, faster throughput, larger profits and even more (re-)usable
software and more (re-)use of existing artifacts. My position is therefore
that "reuse" is actually a synonym for several "Good Things" in Software
Engineering, and that many software engineers and managers see it that
way, and that to achieve these "Good Things"  ne should concentrate on
good software engineering process and methodology improvement in
general.

2.1  The Case of Nokia Telecommunications

The above position stems from a few observations made at Nokia
Telecommunications.There has been an ongoing discussion about "reuse"
and the necessity of it, which actually seems to have blinded us from the
fact that in a sense we are already there.

NTC's DX 200 product's internal architecture has been under scrutiny,
and the results are being implemented. The product - and the
organization - is organized into several platforms of different abstraction
levels. New enhancements to common platforms are made partially by
applying a standard procedure for generalizing specific features created
initially for a narrow or even a customer-specific purpose. Different
system and code generators have been built over the years, and the
abstraction level for the average softare engineer is continuously getting
higher and higher. All these - a common repository or a "platform"and
the higher level tools - have been initiated as more or less independent
projects. The end result from this drive towards clear goals is actually
very similar to what is the cookbook approach toward reuse 1 . This is
the observation that deserves some attention, since the word "reuse" has
been mentioned only in the context that "we should be doing it", and
usually it has been found out that "in a sense, we are already doing it",
which revelation leads to either the conclusion that we are not doing
enough or to the question about "where is the beef in reuse - do we need
to think about it any more".

The way process and methdology enhancements have usually started is
that there has been a clear idea of what should be done and what
benefits the improvement would bring with it. Thus, on the road to the
current situation,the motivation has always been something else but
reuse - better quality, better productivity or whatever. In the tough
competition there seems to be little or no room for two-phased
improvement paths forcing the organization first to invest to reach an
intermediate state of "Great Expectations", and from there to proceed to
financial success. It is possible to justify and start large investments with
long pay-off times if the benefits are clear and large enough, but it seems
unlikely that such investments can be done if the promised benefits
have no direct consequences in the company's competitiveness. For this
reason reuse should not be stated as a goal for an improvement program,
and no company should make the error of believing that "doing reuse" is
the goal of any of its actions 2 .

2.2  Planned company-level reuse can be bad for the company

Some successful companies - including Nokia 3 - try to avoid too much
centralized control, and favor more or less independent business units
with clear customer-orientation and local authority for all business-
related issues 4 . The business units are given responsibility of their
customer accounts and products, they have precise profit goals, and
therefore they have a large amount of authority. This implies that a
company-wide program that affects the software production technology
and the software engineering processes in the profit centers could disrupt
the operations of the units. If a large-scale program is to be started, the
program should be accepted both in the headquarters and in the units.
Since the units usually have slightly different short-term and long-term
goals, creating an agreement of what should be done, who pays for it and
how much effort should be put in can be difficult.

All this implies that large-scale reuse programs can be hard to start in
some business environments. The necessary "CEO support" - or, at
business unit level, the "unit manager support" - means that the CEO or
the unit manager should start interfering with the operations of the
units or the departments, which implies that the management
philosophy has to be more or less centralized. If not, interfering with the
local authority can disrupt the smooth local operations,which is usually
not a good thing. In exceptional cases it can be done; for example, a
quality system and the ISO9000 approval must be a company-wide
effort. Implementing a similar program for an individual technique or
set of techniques like reuse in the corporate level is somewhat unlikely
since a corporate program interferes and disrupts the operations of the
units, and therefore breaks the corporatemanagement culture,which is
usually much more valuable than an independent implementation-level
technology. In the unit - or "domain" - level such a program is easier to
start, but the acceptable amount of resource expenditure is naturally
much smaller. That means that investments are smaller and that the
technology to be used must scale down, too, and that there should be a
mechanism of building software engineering infrastructure in general
and reuse technology in particular at least partially in a bottom-up
manner.

_______________________________
 1 Spend time and resources to get large common building blocks for
application developers.Build system generators if you can. Take care of
communications and quality control.
  2 Excluding companies that try to sell reuse, naturally.
  3 The CEOJorma Ollila has publicly stated that he is very happy with
the distributed decision-making in the group and finds it a valuable
asset.
  4According to the sales people of e.g. Hewlett-Packard, HP has similar
attitude towards local versus centralized decision-making.

3   Comparison with other work

This position seems to contrast the positive results from e.g. IBM and
Motorola.  The described improvement method has a similarity with the
Capability Maturity Model [3]. The difference can be only a superficial
one: what has been said here is that the goals and motives for doing
improvements should be suitable for the organization and that the goals
should offer something measurable. This is in no contrast with what has
been said in earlier work. On the other hand, the concept of having reuse
as a goal for an organization is not believed to be universally true. While
it is OK to have e.g.  reuse as the initial theme for improvement, the
goals should be connected to the company's business improvements.
While the benefits of reuse programs cannot be denied, questions and
doubts about the overall efficiency arises, and alternative what-if
scenarios 5 would be very welcome to clarify the issues.

[4] attempts to explain the problems IBM faced in the computer
industry after the introduction of the IBMPC. The given explanation can
be argued, but the authors continue to describe a "Silicon Valley model"
of high technology management, which emphasizes fast actions,
concentration on the core competence and architectural domination of
the market. The model includes emphasis on loosely coupled small
organizations with well defined interfaces, which means distributed
control and command. The text implies that such an organization is
"goo d", and claims that the pace of technology requires it or some other
adaptive and slick organizational model. True or not,the Ferguson's and
Morris's arguments have a similarity with this presentation,and it would
indeed be hard to devise a way to implement a long-range reuse program
in a fast setting they describe.

The work about e.g. system generators [5] and other implementation
level reuse technologies is in no contrast or agreement with this
observation. The issue here is why and how should one run a reuse or
other process improvement projects, not the actual steps in the potential
projects.

Work and opinions about Software Process Automation [6] are
compatible with my alleged observation. Goals need to be defined, steps
determined and results measured when one is trying to improve the
performance of the organization. What might be left unsaid is that the
organization needs to be aware of what it really needs, and should not
concentrate on secondary or technological issues, at least not if the
technology is not the business of the organization.

_______________________________5
Such scenarios are naturally error-prone, and prove little, if nothing.
They still present alternative lines of thinking, and are therefore
valuable.

References

[1]R. L. Joos, "Software reuse at motorola," IEEE Software, vol. 11,
September 1994.

[2]A. Endres, "Lessons learned in an industrial software lab," IEEE
Software, vol. 10, pp. 58-61, September 1993.

[3]M. Paulk, B. Curtis,and C. et al., "Capability Maturity Model for
Software," Tech. Rep. CMU/SEI-91-TR-24, Software Engineering
Institute/Carnegie Mellon University, Pittsburgh, Pennsylvania, August
1991.

[4]C. H. Ferguson and C. R. Morris, Computer Wars. Times Books, 1994.

[5]D. Batory, V. Singhal, J. Thomas, S. Dasari, B. Geraci, and M. Sirkin,
"The Genvoca model of software-systemgenerators," IEEE Software, vol. 11,
September 1994.

[6]A. M. Christie, Software Process Automation. Springer-Verlag, 1995.

4   Biography

Aarne H. Yla-Rotiala is a software engineer at Nokia Telecommunications.
He works at the software engineering department, and is currently
involved in a project that is developing the software engineering
environment in use at the development of DX 200 software. He received
a M.Sc from the university of Helsinkiin 1990, and is enlisted as a Ph.D
student at the department of computer science.